Re: [dub] Error: module `main` from file source\main.d is specified twice on the command line
On 2018-06-22 21:41, Anonymouse wrote: I'm trying to set up AppVeyor to build and test my project. After some dancing to get a 64-bit dmd.exe in there (which should really be included in the 7z in 2018) everything seems like it should work, but compiling with dub build fails. dub test works but claims that it's excluding main.d twice. Everything just works locally. appveyor.yml: https://github.com/zorael/kameloso/blob/b278468eb69f221c0db6b96274cec2b0fd25612f/appveyor.yml#L92 dub.json: https://github.com/zorael/kameloso/blob/b278468eb69f221c0db6b96274cec2b0fd25612f/dub.json#L8 Slightly summarized: $ dub test -c cygwin # ...excluded main.d twice but worked $ dub build -c cygwin Performing "debug" build using dmd for x86_64. requests 0.7.4: building configuration "std"... kameloso 1.0.0-rc.1+commit.322.gb278468e: building configuration "cygwin"... Error: module `kameloso.main` from file source\kameloso\main.d is specified twice on the command line dmd failed with exit code 1. Job log: https://ci.appveyor.com/project/zorael/kameloso/build/job/kd6lqu2kxg4vxqmv dub.json does have a mainSourceFile entry, so I thought to remove that, but if I do it breaks dub test with "only one `main` allowed". $ dub test -c vanilla Executable configuration "vanilla" of package kameloso defines no main source file, this may cause certain build modes to fail. Add an explicit "mainSourceFile" to the package description to fix this. Generating test runner configuration 'kameloso-test-vanilla' for 'vanilla' (executable). Excluding package.d file from test due to https://issues.dlang.org/show_bug.cgi?id=11847 Performing "unittest" build using dmd for x86_64. kameloso 1.0.0-rc.1+commit.316.gc9216fa3: building configuration "kameloso-test-vanilla"... source\kameloso\main.d(744,6): Error: only one `main`, `WinMain`, or `DllMain` allowed. Previously found `main` at C:\Users\appveyor\AppData\Local\Temp\1\dub_test_root-5d1d92fa-e527-43b0-a181-184253ffcc9d.d(45,12) dmd failed with exit code 1. Job log: https://ci.appveyor.com/project/zorael/kameloso/build/1.0.0-rc.2.143/job/8tox3hym32leik7u What can I do? It might be this issue [1], should be fixed in the latest version of Dub. [1] https://github.com/dlang/dub/issues/1454 -- /Jacob Carlborg
Re: What is the point of nothrow?
On Thursday, 21 June 2018 at 19:52:25 UTC, Jonathan M Davis wrote: On Thursday, June 21, 2018 13:16:28 wjoe via Digitalmars-d-learn wrote: On Wednesday, 20 June 2018 at 12:22:33 UTC, Kagamin wrote: > Do you know how to extract information from it on an > unfamiliar OS? Reading stack trace is easier and > self-evident. Counter question: How do you develop for an unfamiliar OS with unfamiliar tools in the first place ? The concept of a debugger and a memory dump is fundamentally the same on every OS I know or care about just as much as the D error implementation doesn't care about niche cases. Of course you can debug your applications via print to console if you feel that this is productive enough and ignore the bugs you can't fix that way. Simply having a stack trace would be plenty in many cases, and if you're primarily developing an a different OS from the one the user was on when the error occurred, getting a stack trace may allow you to see what the problem is and fix it without setting up a debugger on the OS that the user was running (which could be a huge timesaver if you don't normally use that That is if that other OS provides the means to print one and the user is skilled enough to relay that info to the developer. There's apparently no other option. Because as I learned here that installing your own crash handler, for instance, which writes this stack trace to a file and submits a crash report to the developer, is not possible. Additionally, you might end up empty handed in case of a daemon since best practice in this domain is to close stdin/out/err to prevent them to litter the terminal with output and/or they may be runnig headless and this kind of output would never be seen. OS). That being said, the optimal solution is likely printing out the error message and stack trace, and then giving a coredump (or the OS' equivalent) at the point of the failure. Then if the message and stack trace are enough, you're good to go, and if you need the coredump to get more detailed information, then you have it. - Jonathan M Davis Those who are comfy rarely see the needs of others. My attempt in this regard was to show how it feels like not to have that info.
Redundant "g" flag for regex?
I get the same output with or without "g" flag at line 6: https://run.dlang.io/is/9n7iz6 So I don't understand when I have to use "g" flag.
why explicitly use "flags" in regex does not work?
I got "Error: undefined identifier flags" in here: https://run.dlang.io/is/wquscz Removing "flags =" works.
Re: why explicitly use "flags" in regex does not work?
On Saturday, 23 June 2018 at 12:20:10 UTC, biocyberman wrote: I got "Error: undefined identifier flags" in here: https://run.dlang.io/is/wquscz Removing "flags =" works. I kinda found an answer. It's a bit of a surprise anyway: https://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org?page=1 Long story short, "named" parameter function calling still does not work. IHO, this goes against the readability tendency of D. And I still don't know how if I want to do this: auto func(string a = "a", string b = "b", string c = "c") { write("a: ", a, " b: ", b, " c: ", c); } void main() { func(); func(b ="B"); // Changes default for b only func(c = "C"); // Changes default for c only }
Re: [dub] Error: module `main` from file source\main.d is specified twice on the command line
On Saturday, 23 June 2018 at 08:10:08 UTC, Jacob Carlborg wrote: On 2018-06-22 21:41, Anonymouse wrote: What can I do? It might be this issue [1], should be fixed in the latest version of Dub. [1] https://github.com/dlang/dub/issues/1454 Thanks.
Re: why explicitly use "flags" in regex does not work?
On Saturday, 23 June 2018 at 12:50:17 UTC, biocyberman wrote: On Saturday, 23 June 2018 at 12:20:10 UTC, biocyberman wrote: I got "Error: undefined identifier flags" in here: https://run.dlang.io/is/wquscz Removing "flags =" works. I kinda found an answer. It's a bit of a surprise anyway: https://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org?page=1 Long story short, "named" parameter function calling still does not work. Indeed and i'm surprised you didn't know that. The topic has been discussed several times and will be again in the next weeks and months since there are 2 DIP for the feature: [1] https://github.com/dlang/DIPs/pull/123 [2] https://github.com/dlang/DIPs/pull/126
Re: Redundant "g" flag for regex?
On Saturday, 23 June 2018 at 12:17:08 UTC, biocyberman wrote: I get the same output with or without "g" flag at line 6: https://run.dlang.io/is/9n7iz6 So I don't understand when I have to use "g" flag. My bet is that Regex results in D are lazy so "g" doesn't make sense in this context however I'm able to see an effect with "match": match("12000 + 42100 = 54100", regex(r"(?<=\d)(?=(\d\d\d)+\b)", "")).writeln; match("12000 + 42100 = 54100", regex(r"(?<=\d)(?=(\d\d\d)+\b)", "g")).writeln; matchFirst would be like without "g" matchAll would be like with "g"
Re: Redundant "g" flag for regex?
On Saturday, 23 June 2018 at 13:45:32 UTC, Basile B. wrote: On Saturday, 23 June 2018 at 12:17:08 UTC, biocyberman wrote: I get the same output with or without "g" flag at line 6: https://run.dlang.io/is/9n7iz6 So I don't understand when I have to use "g" flag. My bet is that Regex results in D are lazy so "g" doesn't make sense in this context however I'm able to see an effect with "match": match("12000 + 42100 = 54100", regex(r"(?<=\d)(?=(\d\d\d)+\b)", "")).writeln; match("12000 + 42100 = 54100", regex(r"(?<=\d)(?=(\d\d\d)+\b)", "g")).writeln; matchFirst would be like without "g" matchAll would be like with "g" I should have read the doc more thoroughly: https://dlang.org/phobos/std_regex.html#match Delegating the kind of operation to "g" flag is soon to be phased out along with the ability to choose the exact matching scheme. So case closed for me
Re: Undo in D
On Saturday, 23 June 2018 at 01:58:31 UTC, DigitalDesigns wrote: Is there any idiomatic undo designs in D that give a more natural implementation than the standard techniques? - The "stuff to undo" can be a forward range ("save" primitive, + assignable from a stored state) - The manager can be an output range of the "stuff to undo" ``` struct UndoManager(Undoable, Storage) if (isForwardRange!Undoable && isOutputRange!(Storage, Undoable)) { Storage storage; Undoable undoable; size_t position; this(Storage storage, Undoable undoable) {} void push(){ storage.put(undoable.save()); length++;} /* etc */ } ``` So that the UndoMgr is reusable with any Undoable and Storage that implement the right primitives. But well, you can do that with any PL that have basic generics, e.g C# or FreePascal. The key is to have a nice generic interface. IRL it's probably more complicated than my example. Storage must probably be a RandomAccessRange or have more specific primitives. Now, **and this is D specific / D idiomatic**, to this can be applied the "design by introspection". UndoManager can allow more or less advanced features, depending on the primitives implemented by Storage and Undoable. Technically this is done at compile-time using __traits(hasMember), typically.
Re: How do I filter out this type?
On Friday, 22 June 2018 at 17:20:03 UTC, Steven Schveighoffer wrote: On 6/22/18 1:07 PM, Dr.No wrote: static if(is(typeof(__traits(getMember, B, field) == A[]))) static if(is(typeof(__traits(getMember, B, field)) == A[])) Note the slight change in parentheses. -Steve oh, I'm a bit embarrassed. haha Thanks anyway!
Re: Undo in D
On Saturday, 23 June 2018 at 14:06:08 UTC, Basile B. wrote: On Saturday, 23 June 2018 at 01:58:31 UTC, DigitalDesigns wrote: Is there any idiomatic undo designs in D that give a more natural implementation than the standard techniques? - The "stuff to undo" can be a forward range ("save" primitive, + assignable from a stored state) - The manager can be an output range of the "stuff to undo" ``` struct UndoManager(Undoable, Storage) if (isForwardRange!Undoable && isOutputRange!(Storage, Undoable)) { Storage storage; Undoable undoable; size_t position; this(Storage storage, Undoable undoable) {} void push(){ storage.put(undoable.save()); length++;} /* etc */ } ``` So that the UndoMgr is reusable with any Undoable and Storage that implement the right primitives. But well, you can do that with any PL that have basic generics, e.g C# or FreePascal. The key is to have a nice generic interface. IRL it's probably more complicated than my example. Storage must probably be a RandomAccessRange or have more specific primitives. Now, **and this is D specific / D idiomatic**, to this can be applied the "design by introspection". UndoManager can allow more or less advanced features, depending on the primitives implemented by Storage and Undoable. Technically this is done at compile-time using __traits(hasMember), typically. Actually i did one once for an hex editor and i think this couldn't be applied. Typically a position, a command and a data are the member of a change, not the whole stuff. The generic abstraction should be changed to handle such a thing: struct UndoItem(Position, Command) { Position position; // e.g offset in doc or coordinate, etc Command command; // e.g an enum ubyte[] data; } About the Storage, i think that a linked list is better. No need to templatize it then. From this there's no thing possible that's very idiomatic in the design. Somrething like this old shitty stuff : https://github.com/BBasile/LLClasses/blob/master/LLClasses.d#L5701 but with a better abtraction (linked code is more or less the translation of what i did in Delphi years before). So finally we come back to a simple generic stuff: struct UndoMgr(Position, Command) { List!(UndoItem!(Position, Command)) items; /* stupid method there - insert - undo - redo - compact - clear */ } nothing D specific, you can do that in C# or in FreePascal. UndoRedo is a simple thing, too much abstraction could make the thing abstruse. But maybe this is what you look for, something utterly complex to fill your emptiness.
Re: Undo in D
On Saturday, 23 June 2018 at 01:58:31 UTC, DigitalDesigns wrote: Is there any idiomatic undo designs in D that give a more natural implementation than the standard techniques? There is the solution above, but there I've implemented something similar in Diamond. It's a little bit different concept since it's based on "snapshot" types which basically is a type that keeps snapshots of its values and thus you can change the state of it. They're used for transactions within Diamond, which could show-case how to use them. http://diamondmvc.org/docs/data/#transactions But a quick example would be from the docs: ``` import diamond.data; auto value = new Snapshot!int; value = 100; value = 200; value = 300; value = 400; import std.stdio : writefln; writefln("%d %d %d %d %d", value[0], value[1], value[2], value[3], value); // Prints: 100 200 300 400 400 ``` For more information also see: http://diamond.dpldocs.info/diamond.data.snapshot.Snapshot.html
DerelictVorbis and string pointer
Hello D community! I'm developing an application that must work on audio especially playback Ogg files. So I took library DerelictVorbis [0] testing basic functions like `ov_fopen`. The tests were successful so I decided to implement core components of the application using D and Derelict libraries. Today I encountered a problem, the `ov_fopen` returns -1 instead of 0. It means that something goes wrong and the file that is pointed by a string is not opened. I figured out it so there is the error is not occurred when a file path is pointed by a string variable from CLI input arguments but it is occurred when the path is pointed by a string variable filled dynamically (for example file path is read from another file). Here code goes public import derelict.vorbis; public import derelict.vorbis.file; void main(string[] args) { DerelictVorbis.load(); DerelictVorbisFile.load(); OggVorbis_File _ovFile; immutable filepath = args[1]; import std.file; import std.string; string filepath2 = "./name.txt".readText.strip; assert(filepath2 == filepath); int res = ov_fopen(filepath2.ptr, &_ovFile); // res == -1 // int res = ov_fopen(filepath.ptr, &_ovFile); // res == 0 assert(res == 0, "ov_fopen returns %d".format(res)); } Actually I get it worked replacing `string filepath2` by `char[] filepath2` but filepath is string still and it works correctly. So what detail The devil is in? Is there an issue in DerelictVorbis or in compiler. Don't I know something about implementation of strings or pointers in D? Thanks in advance! DMD 2.080 DerelictVorbis 2.0.0-beta.2 [0] https://github.com/DerelictOrg/DerelictVorbis
Re: DerelictVorbis and string pointer
On Sunday, 24 June 2018 at 01:26:48 UTC, ANtlord wrote: Actually I get it worked replacing `string filepath2` by `char[] filepath2` but filepath is string still and it works correctly. It doesn't work
Re: DerelictVorbis and string pointer
On 24/06/2018 1:26 PM, ANtlord wrote: Hello D community! I'm developing an application that must work on audio especially playback Ogg files. So I took library DerelictVorbis [0] testing basic functions like `ov_fopen`. The tests were successful so I decided to implement core components of the application using D and Derelict libraries. Today I encountered a problem, the `ov_fopen` returns -1 instead of 0. It means that something goes wrong and the file that is pointed by a string is not opened. I figured out it so there is the error is not occurred when a file path is pointed by a string variable from CLI input arguments but it is occurred when the path is pointed by a string variable filled dynamically (for example file path is read from another file). Here code goes public import derelict.vorbis; public import derelict.vorbis.file; void main(string[] args) { DerelictVorbis.load(); DerelictVorbisFile.load(); OggVorbis_File _ovFile; immutable filepath = args[1]; import std.file; import std.string; string filepath2 = "./name.txt".readText.strip; assert(filepath2 == filepath); int res = ov_fopen(filepath2.ptr, &_ovFile); // res == -1 // int res = ov_fopen(filepath.ptr, &_ovFile); // res == 0 assert(res == 0, "ov_fopen returns %d".format(res)); } Actually I get it worked replacing `string filepath2` by `char[] filepath2` but filepath is string still and it works correctly. So what detail The devil is in? Is there an issue in DerelictVorbis or in compiler. Don't I know something about implementation of strings or pointers in D? Thanks in advance! DMD 2.080 DerelictVorbis 2.0.0-beta.2 [0] https://github.com/DerelictOrg/DerelictVorbis So where exactly is the null byte for the C string?
Re: DerelictVorbis and string pointer
On Sunday, 24 June 2018 at 01:43:41 UTC, ANtlord wrote: On Sunday, 24 June 2018 at 01:26:48 UTC, ANtlord wrote: Actually I get it worked replacing `string filepath2` by `char[] filepath2` but filepath is string still and it works correctly. It doesn't work Vorbis is a C library, so you need to null terminate your string using toStringz. The reason why the one from the command line works is because it is already null terminate.
Re: Is HibernateD dead?
On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote: Last commit on https://github.com/buggins/hibernated was almost a year ago So what is the status of HibernateD?Should I use it if I need an ORM? Or would I risk unpatched security risks? Okay... wall of text. TLDR: project definition / future of HibernateD?; prospects of an OGM layer integration (personally interested in Neo4j)? I've been thinking of trying to implement an OGM (Object-graph mapping; i.e. NoSQL) for Neo4j in D as I'd love using it for a project of mine. The question is, whether it should be a separate project or whether something like this could be integrated with HibernateD. I've taken a look at Hibernate ORM and OGM. There OGM is a separate project leveraging a lot of ORMs capabilities. I'm still in the process of diving deeper into Hibernate's ORM/OGM documentation(/implementation) to get an idea of how it all works. I'm not particularly experienced with it. One question that arises in respect to HibernateD is: What is the purpose of HibernateD? The README states "HibernateD is ORM for D language (similar to Hibernate)". I guess there are two Extremes: A. Replicate the structure of Hibernate into D, in a way porting it 1:1, B. Implement an ORM from scratch. Both approaches would be impractical for the following reasons: contra A. An exact replica would leave no room for optimizations or creating a more D-idiomatic library, contra B. Creating a completely new solution and interface would miss out on leveraging what Hibernate already "knows". Further, Hibernate users might love seeing a familiar interface they can work with. Option B wouldn't deserve the name "HibernateD".. This solely highlights that the project's purpose/description might need some more explanation. A small look into the code reveals that the approach leans towards implementing the component structure of Hibernate (such as dialects, a Hibernate(D) basic type system, ...). I'd guess this would be the most practical approach: Leverage Hibernate's insights into what components are required to implement an ORM(/OGM) (Dialects, Hibernate(D) types, annotations, Persistence Strategies, ...) and find D-idiomatic ways for implementation. Any space for optimization should naturally be capitalized on. A complete 1:1 replica does not seem practical as for example I've stumbled across the "@Immutable" annotation in the Hibernate documentation. As there is the "immutable" qualifier in D, through introspection, this quality could be deduced from entities/members. This leads to thinking that solutions tailored towards D need to be found and therefore deviation from Hibernate sounds reasonable. I am in no way an expert in ORMs (I just started reading Hibernate's ORM documentation) and I have no idea what other ORMs are out there (D or non-D). However, Hibernate seems quite popular (and it offers a Neo4j OGM interface) and the fact that it exists for D (at least in a "starting positition") caught my attention. What do you think? Especially bauss, Matthias and singingbush, as you seem motivated to move the project forward. Maybe Vadim also has a standpoint : ).
Re: DerelictVorbis and string pointer
On Sunday, 24 June 2018 at 01:54:52 UTC, Nicholas Wilson wrote: On Sunday, 24 June 2018 at 01:43:41 UTC, ANtlord wrote: On Sunday, 24 June 2018 at 01:26:48 UTC, ANtlord wrote: Actually I get it worked replacing `string filepath2` by `char[] filepath2` but filepath is string still and it works correctly. It doesn't work Vorbis is a C library, so you need to null terminate your string using toStringz. The reason why the one from the command line works is because it is already null terminate. It works! Thank you!
Can I parse this kind of HTML with arsd.dom module?
This is the module I'm speaking about: https://arsd-official.dpldocs.info/arsd.dom.html So I have this HTML that not even parseGarbae() can del with: https://hostname.com/?file=foo.png&foo=baa";>G! There is this spaces between "href" and "=" and "https..." which makes below code fails: string html = get(page, client).text; auto document = new Document(); document.parseGarbage(html); Element attEle = document.querySelector("span[id=link2]"); Element aEle = attEle.querySelector("a"); string link = aEle.href; // <-- if the href contains space, it return "href" rather the link let's say the page HTML look like this: Hello, dear world! https://hostname.com/?file=foo.png&foo=baa";>G! I know the library author post on this forum often, I hope he see this help somehow to make it work. But if anyone else know how to fix this, will be very welcome too!