www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Rant of the day

reply Rumbu <rumbu rumbu.ro> writes:
After 1 year or something, I tried D again.

Do you know what happens if you write GC.Free insead of GC.free?

27 lines of code, 26 errors.

https://imgur.com/a/DlackXp
Jan 25
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
 After 1 year or something, I tried D again.

 Do you know what happens if you write GC.Free insead of GC.free?

 27 lines of code, 26 errors.

 https://imgur.com/a/DlackXp
It seems that we can do better on the syntax error checking front. Did you submit a bug report for this already? -Alex
Jan 25
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
 Do you know what happens if you write GC.Free insead of GC.free?
F.d(4): Error: no property Free for type GC, did you mean core.memory.GC.free? There's gotta be something more to it on your end. My guess is some other import with a function called Free that is triggering all this ugliness. D's error messages do suck. Bigger problem with GC.free is it might not do what you think it does, be warned: https://issues.dlang.org/show_bug.cgi?id=21550 If you GC.malloc, it good, but if you `new int[]` then try to `GC.free` it is a silent no-op.
Jan 25
parent Rumbu <rumbu rumbu.ro> writes:
On Monday, 25 January 2021 at 16:11:28 UTC, Adam D. Ruppe wrote:
 On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
 Do you know what happens if you write GC.Free insead of 
 GC.free?
F.d(4): Error: no property Free for type GC, did you mean core.memory.GC.free? There's gotta be something more to it on your end. My guess is some other import with a function called Free that is triggering all this ugliness. D's error messages do suck. Bigger problem with GC.free is it might not do what you think it does, be warned: https://issues.dlang.org/show_bug.cgi?id=21550 If you GC.malloc, it good, but if you `new int[]` then try to `GC.free` it is a silent no-op.
These error messages are a common effort of Visual D and dmd. Sincerely I am not keen to investigate further, but if this is the first sight for a new user, he'll run. I just made myself a new computer and tried to install everything I had in the past. Among other things, of course I had some hope for D after a year of ignoring each other :) VS Code plugin completely failed - debugger error and CMake takes over Dub. Unusable. Tried Visual D, 20+ errors. First contact. (On the GC: I have a MmFile class and I need to force it to close the mapped file, I don't know another way of deterministic call of the destructor except `scoped` but it's not the case)
Jan 25
prev sibling next sibling parent matheus <matheus gmail.com> writes:
On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
 ...Do you know what happens if you write GC.Free insead of 
 GC.free?
Here I got: main.d(8): Error: no property 'Free' for type 'GC', did you mean 'free'? Matheus.
Jan 25
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
 After 1 year or something, I tried D again.

 Do you know what happens if you write GC.Free insead of GC.free?

 27 lines of code, 26 errors.

 https://imgur.com/a/DlackXp
Curious, why didn't u want to use new/delete/destroy?
Jan 25
parent reply Rumbu <rumbu rumbu.ro> writes:
On Monday, 25 January 2021 at 18:48:46 UTC, Imperatorn wrote:
 On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu wrote:
 After 1 year or something, I tried D again.

 Do you know what happens if you write GC.Free insead of 
 GC.free?

 27 lines of code, 26 errors.

 https://imgur.com/a/DlackXp
Curious, why didn't u want to use new/delete/destroy?
iport std.mmfile; struct Database { this(string filename) { this.filename = filename; file = new MmFile(filename, MmFile.Mode.read, 0, null); } ~this() { if (file) { destroy(file); GC.free(&file); } } } //somewhere in code: { Database db = Database("somefile"); .... //here at the end of scope I want to be sure that file map is closed. }
Jan 25
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 25, 2021 at 07:53:11PM +0000, Rumbu via Digitalmars-d wrote:
[...]
 iport std.mmfile;
 
 struct Database
 {
     this(string filename)
     {
         this.filename = filename;
         file = new MmFile(filename, MmFile.Mode.read, 0, null);
     }
 
     ~this()
     {
         if (file)
         {
             destroy(file);
             GC.free(&file);
         }
     }
 }
 
 //somewhere in code:
 {
     Database db = Database("somefile");
     ....
     //here at the end of scope I want to be sure that file map is closed.
 }
[...] Honestly, I think std.mmfile should either be refactored to be a struct with defined lifetime (i.e., with a dtor), or the class should have a .close method for explicitly closing the mapping. Relying on a GC-collected object to reclaim a resource (in this case a mmap mapping) is an anti-pattern that should be expunged from Phobos. https://issues.dlang.org/show_bug.cgi?id=9501 T -- Meat: euphemism for dead animal. -- Flora
Jan 25
parent reply Tove <tove fransson.se> writes:
On Monday, 25 January 2021 at 20:07:04 UTC, H. S. Teoh wrote:
 Relying on a GC-collected object to reclaim a resource (in this 
 case a mmap mapping) is an anti-pattern that should be expunged 
 from Phobos.

 	https://issues.dlang.org/show_bug.cgi?id=9501


 T
Fully agree... it was brought up ages ago, I was living in the delusion that someone had fixed it by now... alas.
Jan 25
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 25, 2021 at 09:26:28PM +0000, Tove via Digitalmars-d wrote:
 On Monday, 25 January 2021 at 20:07:04 UTC, H. S. Teoh wrote:
 Relying on a GC-collected object to reclaim a resource (in this case
 a mmap mapping) is an anti-pattern that should be expunged from
 Phobos.
 
 	https://issues.dlang.org/show_bug.cgi?id=9501
[...]
 Fully agree... it was brought up ages ago, I was living in the
 delusion that someone had fixed it by now... alas.
I'd submit a PR for it, but based on the discussion in bugzilla, it probably won't go through, because (1) changing from a class to a struct will break pretty much *every* usage of it in existing code, and we're oh so afraid of breaking changes these days even if it's all for the better; (2) the anticipated back-n-forth on the ensuing PR discussion will probably wear me out and make me walk away as quickly as I approached. Based on Andrei's and others' sentiment expressed within the past year or two, probably a more viable approach is to create a new mmfile API. Say std.mmfile2, or just have a new struct-based version of Mmfile alongside the current class, that has better semantics and better reflects today's language. (From the looks of it, std.mmfile was written in an earlier era where D still had a more class-centric, Java-like outlook, with one or two things bolted on afterwards but not really changing the core implementation.) I'm wary of submitting this to Phobos, though, because the current PR process is a gigantic timesink and time is something I do not have enough of. At this point, a dub package or some other external module is probably a better bet. I'd try my hand at a standalone 1-file replacement for std.mmfile, but I've zero Windows dev experience so it will only be Posix-compatible. T -- Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.
Jan 25
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 25 January 2021 at 22:00:48 UTC, H. S. Teoh wrote:
 On Mon, Jan 25, 2021 at 09:26:28PM +0000, Tove via 
 Digitalmars-d wrote:
 On Monday, 25 January 2021 at 20:07:04 UTC, H. S. Teoh wrote:
 Relying on a GC-collected object to reclaim a resource (in 
 this case a mmap mapping) is an anti-pattern that should be 
 expunged from Phobos.
 
 	https://issues.dlang.org/show_bug.cgi?id=9501
[...]
 Fully agree... it was brought up ages
At this point, a dub package or some other external module is probably a better bet. I'd try my hand at a standalone 1-file replacement for std.mmfile,
Yeah, dub is totally okay.
Jan 25
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 25, 2021 at 10:44:41PM +0000, aberba via Digitalmars-d wrote:
 On Monday, 25 January 2021 at 22:00:48 UTC, H. S. Teoh wrote:
[...]
 At this point, a dub package or some other external module is
 probably a better bet.  I'd try my hand at a standalone 1-file
 replacement for std.mmfile,
Yeah, dub is totally okay.
Dub is OK as a package manager, but I have serious difficulty with using it as a build system. It just goes against the grain of how I usually work, and has fundamental limitations with what I usually need to do, and so I have not invested much effort into it. My current inclination is along the lines of Adam Ruppe's single-file, self-contained, dependency-free module that you can literally just copy into your workspace and use right away. Over the years I've come to question the sacred cow of code reuse and the dependency hell it often entails (solving NP-complete problems, for example, should be something your program helps the user to do, not something that you have to do as a prerequisite to compiling/using the program!), and now prefer alternative approaches that involve simpler and more uniformly composable artifacts. (Of course, if anybody wants to add dub support to my code, I'm more than happy to accept patches.) T -- Marketing: the art of convincing people to pay for what they didn't need before which you fail to deliver after.
Jan 25
prev sibling next sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 25 January 2021 at 22:00:48 UTC, H. S. Teoh wrote:
 [...] I'm wary of submitting this to Phobos, though, because 
 the current PR process is a gigantic timesink and time is 
 something I do not have enough of.

 At this point, a dub package or some other external module is 
 probably a better bet.  I'd try my hand at a standalone 1-file 
 replacement for std.mmfile, but I've zero Windows dev 
 experience so it will only be Posix-compatible.
If you do a PR and I remember looking for it, I'll test it on my Windows machine.
Jan 25
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 25 January 2021 at 22:00:48 UTC, H. S. Teoh wrote:
 On Mon, Jan 25, 2021 at 09:26:28PM +0000, Tove via 
 Digitalmars-d wrote:
 [...]
[...]
 [...]
I'd submit a PR for it, but based on the discussion in bugzilla, it probably won't go through, because (1) changing from a class to a struct will break pretty much *every* usage of it in existing code, and we're oh so afraid of breaking changes these days even if it's all for the better; (2) the anticipated back-n-forth on the ensuing PR discussion will probably wear me out and make me walk away as quickly as I approached. [...]
I think that sooner or later the problem of evolving Phobos should be tackled by the gatekeepers, providing at least a policy for incremental improvements. I personally have a toe in that cold water, as a really simple PR, and it's stalled from ages waiting exactly for that.
Jan 26
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
Corrected example:

import std.mmfile;

struct Database {
     string filename;
     MmFile file;

     this(string filename) {
         this.filename = filename;
         file = new MmFile(filename, MmFile.Mode.read, 0, null);
     }

     ~this() {
         if (file) {
             import core.memory : GC;
             destroy(file);
             GC.free(cast(void*)file);
         }
     }
}

//somewhere in code:
void main(string[] args) {
     Database db = Database(args[0]);
}

Note: you did not need to call GC.free. The destroy would have 
guaranteed unmapping internally. GC.free would only remove the class 
instance memory itself.
Jan 25
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/25/21 9:55 PM, rikki cattermole wrote:

 Note: you did not need to call GC.free. The destroy would have 
 guaranteed unmapping internally. GC.free would only remove the class 
 instance memory itself.
This. GC is for memory cleanup, but not necessary to cleanup resources. If you are calling GC.free in your code, likely you are doing something wrong. -Steve
Jan 26
parent reply Rumbu <rumbu rumbu.ro> writes:
On Tuesday, 26 January 2021 at 15:16:01 UTC, Steven Schveighoffer 
wrote:
 On 1/25/21 9:55 PM, rikki cattermole wrote:

 Note: you did not need to call GC.free. The destroy would have 
 guaranteed unmapping internally. GC.free would only remove the 
 class instance memory itself.
This. GC is for memory cleanup, but not necessary to cleanup resources. If you are calling GC.free in your code, likely you are doing something wrong. -Steve
I took the example from an unittest, assuming that people writing phobos libs are way smarter than me :) https://github.com/dlang/phobos/blob/fb7bfb2ba5a581cafb9e85ced8f8d67aab35f412/std/mmfile.d#L673
Jan 26
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 26 January 2021 at 17:06:41 UTC, Rumbu wrote:
 I took the example from an unittest, assuming that people 
 writing phobos libs are way smarter than me :)


 https://github.com/dlang/phobos/blob/fb7bfb2ba5a581cafb9e85ced8f8d67aab35f412/std/mmfile.d#L673
Phobos code varies a lot in terms of quality and best-practice adherence. This unit test in particular was written 14 years ago [1], and has not meaningfully changed since then, except to replace the deprecated `delete` keyword with `destroy` + `GC.free`. [2] It is probably safe to assume that it would be different if it were written from scratch today. [1] https://github.com/dlang/phobos/commit/6b069176ba798e3652a1ec5b04c0deea0f4f861f [2] https://github.com/dlang/phobos/commit/9d8cb9fda2013d9cb69e67a3a726067f78875346
Jan 26
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 1/26/21 12:06 PM, Rumbu wrote:
 On Tuesday, 26 January 2021 at 15:16:01 UTC, Steven Schveighoffer wrote:
 On 1/25/21 9:55 PM, rikki cattermole wrote:

 Note: you did not need to call GC.free. The destroy would have 
 guaranteed unmapping internally. GC.free would only remove the class 
 instance memory itself.
This. GC is for memory cleanup, but not necessary to cleanup resources. If you are calling GC.free in your code, likely you are doing something wrong.
I took the example from an unittest, assuming that people writing phobos libs are way smarter than me :) https://github.com/dlang/phobos/blob/fb7bfb2ba5a581cafb9e85ced8f8d67aab35f4 2/std/mmfile.d#L673
https://github.com/dlang/phobos/pull/7770 -Steve
Jan 26