digitalmars.D - Rant of the day
- Rumbu (4/4) Jan 25 2021 After 1 year or something, I tried D again.
- 12345swordy (4/8) Jan 25 2021 It seems that we can do better on the syntax error checking
- Adam D. Ruppe (11/12) Jan 25 2021 F.d(4): Error: no property Free for type GC, did you mean
- Rumbu (13/27) Jan 25 2021 These error messages are a common effort of Visual D and dmd.
- matheus (5/7) Jan 25 2021 Here I got:
- Imperatorn (2/6) Jan 25 2021 Curious, why didn't u want to use new/delete/destroy?
- Rumbu (25/35) Jan 25 2021 iport std.mmfile;
- H. S. Teoh (12/38) Jan 25 2021 [...]
- Tove (3/8) Jan 25 2021 Fully agree... it was brought up ages ago, I was living in the
- H. S. Teoh (26/34) Jan 25 2021 I'd submit a PR for it, but based on the discussion in bugzilla, it
- aberba (2/15) Jan 25 2021 Yeah, dub is totally okay.
- H. S. Teoh (20/26) Jan 25 2021 Dub is OK as a package manager, but I have serious difficulty with using
- Q. Schroll (3/10) Jan 25 2021 If you do a PR and I remember looking for it, I'll test it on my
- Paolo Invernizzi (6/20) Jan 26 2021 I think that sooner or later the problem of evolving Phobos
- rikki cattermole (24/24) Jan 25 2021 Corrected example:
- Steven Schveighoffer (5/8) Jan 26 2021 This. GC is for memory cleanup, but not necessary to cleanup resources.
- Rumbu (5/14) Jan 26 2021 I took the example from an unittest, assuming that people writing
- Paul Backus (11/14) Jan 26 2021 Phobos code varies a lot in terms of quality and best-practice
- Steven Schveighoffer (3/21) Jan 26 2021 https://github.com/dlang/phobos/pull/7770
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 2021
12345swordy <alexanderheistermann gmail.com> 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/DlackXpIt seems that we can do better on the syntax error checking front. Did you submit a bug report for this already? -Alex
Jan 25 2021
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 2021
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: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)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 2021
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 2021
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/DlackXpCurious, why didn't u want to use new/delete/destroy?
Jan 25 2021
On Monday, 25 January 2021 at 18:48:46 UTC, Imperatorn wrote:On Monday, 25 January 2021 at 15:07:02 UTC, Rumbu 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. }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/DlackXpCurious, why didn't u want to use new/delete/destroy?
Jan 25 2021
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 2021
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 TFully agree... it was brought up ages ago, I was living in the delusion that someone had fixed it by now... alas.
Jan 25 2021
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=9501Fully 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 2021
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:Yeah, dub is totally okay.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=9501Fully agree... it was brought up agesAt 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,
Jan 25 2021
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:[...]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.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 2021
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 2021
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 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.[...][...][...]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. [...]
Jan 26 2021
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 2021
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 2021
On Tuesday, 26 January 2021 at 15:16:01 UTC, Steven Schveighoffer wrote:On 1/25/21 9:55 PM, rikki cattermole 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#L673Note: 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 2021
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#L673Phobos 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 2021
On 1/26/21 12:06 PM, Rumbu wrote:On Tuesday, 26 January 2021 at 15:16:01 UTC, Steven Schveighoffer wrote:https://github.com/dlang/phobos/pull/7770 -SteveOn 1/25/21 9:55 PM, rikki cattermole 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/fb7bfb2ba5a581cafb9e85ced8f8d67aab35f4 2/std/mmfile.d#L673Note: 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.
Jan 26 2021