Re: CTFE output is kind of weired
On Sat, Jul 08, 2017 at 03:09:09PM -0700, Ali Çehreli via Digitalmars-d-learn wrote: > On 07/08/2017 02:29 PM, Andre Pany wrote: > > > I use assert(false, tmp) to see the content of variable tmp as it > > seems there is no other way in CTFE. > > A more natural way is pragma(msg), which you can use in main in this > case: [...] Unfortunately, pragma(msg) can only be used *after* CTFE has finished. It's not possible to print the message *during* CTFE. Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine that should alleviate this limitation. T -- There is no gravity. The earth sucks.
Re: rdmd vs dmd WRT static constructors
On Sunday, 9 July 2017 at 03:11:17 UTC, Mike Parker wrote: On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote: To include stat1.d and stat2.d in the compilation, you'll either have to import them in statmain.d or use the --extra-file command line switch: rdmd --extra-file=stat1.d --extra-file=stat2.d statmain.d Okay, got it... thanks Mike.
Re: rdmd vs dmd WRT static constructors
On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote: $ rdmd statmain.d stat1.d stat2.d // outputs nothing... Bug or intended behaviour? rdmd takes the first D file you give it, follows its import tree, and compiles all the modules found there. Anything on the command line after the first source file is treated as a command line argument to the generated program. So stat1.d and stat2.d are never compiled. You'll see if you modify your main function to output the args that it will print the file names you passed. To include stat1.d and stat2.d in the compilation, you'll either have to import them in statmain.d or use the --extra-file command line switch: rdmd --extra-file=stat1.d --extra-file=stat2.d statmain.d
rdmd vs dmd WRT static constructors
RDMD does not behave the same as DMD WRT static constructors. The following example, extracted form Mike Parker's "Learning D", does not produce the same result: // stat1.d module stat1; import std.stdio; static this() { writeln("stat1 constructor"); } // stat2.d module stat2; import std.stdio; static this() { writeln("stat2 constructor"); } // statmain.d void main() { } $ rdmd statmain.d stat1.d stat2.d // outputs nothing... $ dmd statmain.d stat1 stat2 $ ./statmain // outputs... stat1 constructor stat2 constructor Bug or intended behaviour? Thanks, Andrew
Re: CTFE output is kind of weired
On Saturday, July 8, 2017 10:12:29 PM MDT Era Scarecrow via Digitalmars-d- learn wrote: > On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote: > > app.d(17):called from here: test("1234\x0a5678\x0a") > > > > I wrote the source code on windows with a source file with \r\n > > file endings. > > But the console output has only the character X0a. In addition > > not the content of tmp is shown but the full content with the > > slice information [4..10]. > > > > Is this the intended behavior? > > The escape sequence says it's hex, and 0a translates to 10, and > 0d is 13; \r\n is usually a 13,10 sequence. So from the looks of > it the \r is getting stripped out. > > Funny story as i understand it, \r and \n both have very > specific meanings to old printers in the old days. \r for > carriage-Return, and \n for New-line. DOS may have used it, but > \r more-or-less has no use for newlines and printers today. It used to matter for terminals as well. With respect to those ancient time, what Windows does with line endings with \r\n is the most correct, but at this point, it's just a pointless extra character. AFAIK, no other OS expects \r\n now. Everything that's *nix-based uses only \n. Unfortunately, web formats such as http still use \r\n though, because they're based on the original Internet Message Fomat standard (e-mail really), and it's old enough that it mattered when it was written. LOL. As I understand it, the old Macs before Mac OS X actually just used \r, so twent years ago, depending on your OS, you had to deal with \n, \r, or \r\n for line endings. Yuck. > Curious when using writeln, all newlines seem to have \r > sequences added. So i suppose it's one of those things that i > never needed to think about really. Only if you're on Windows. It's what printf and friends do there too (and IIRC, writeln still uses printf underneath the hood). C and UNIX pretty much came into being together, and thus both use \n as the line ending - though given when they were created, I expect that the distinction between \n and \r\n still mattered on UNIX systems occasionally. I don't know though. Now though, no *nix system is going to be doing anything with \r for line endings. - Jonathan M Davis
Re: The Nullity Of strings and Its Meaning
Just saw that my first example was wrong, it should read 1 void main () 2 { 3import std.uri; 4string a = ""; 5assert (a); 6auto s = a.decodeComponent; 7assert (s); 8 } The non-nullity was not preserved. Only the second assert fails. On Saturday, 8 July 2017 at 18:39:47 UTC, ag0aep6g wrote: On 07/08/2017 07:16 PM, kdevel wrote: null is one specific array. It happens to be empty, but that doesn't really matter. `foo is null` compares with the null array. It doesn't check for emptiness. Conversion to bool also compares with null. The concept of emptiness is unrelated. But why? What is the intended use of converting a string (or any other dynamic array) to bool? In Issue 17623 Vladimir pointed out, that in the case of strings there may be a need to store an empty D-string which also is a NUL-terminated C-String. It would be sufficient if the ptr-Value would convert for checking if there is a valid part of memory containing the NUL byte. Moreover everything I've written about strings is also valid for e.g. dynamic arrays of doubles. Here there are also two different kinds of empty arrays which compare equal but are not identical. I see no purpose for that. I wonder if this distinction is meaningful and---if not---why it is exposed to the application programmer so prominently. "Prominently"? It only shows up when you convert to bool. The conversion to bool (in a bool context) is part of the interface of the type. The interface of a type *is* prominently exposed. You only get surprised if you expect that to check for emptiness (or something else entirely). As mentioned I was surprised, that the non-nullity did not pass thru decodeComponent. The spec isn't very clear there. What does "the same array elements" mean for empty arrays? Mathematically that's easily answered: https://en.wikipedia.org/wiki/Universal_quantification#The_empty_set (mkdir) Using DMD v2.073.2 the first expression terminates the programm with a segmentation fault. With 2.074.1 the program prints : Bad address : No such file or directory I find that a bit confusing. That looks like a bug/oddity in mkdir. null is as valid a string as "". It shouldn't give a worse exception message. But the message for `""` isn't exactly good, either. Of course the directory doesn't exist, yet; I'm trying to create it! I would expect the same error message (ENOENT) in both cases. The EFAULT in the first case occurs if you invoke POSIX mkdir with NULL as first argument.
Re: The Nullity Of strings and Its Meaning
On Saturday, July 8, 2017 5:16:51 PM MDT kdevel via Digitalmars-d-learn wrote: > Yesterday I noticed that std.uri.decodeComponent does not > 'preserve' the > nullity of its argument: > > 1 void main () > 2 { > 3import std.uri; > 4string s = null; > 5assert (s is null); > 6assert (s.decodeComponent); > 7 } > > The assertion in line 6 fails. This failure gave rise to a more > general > investigation on strings. After some research I found that one > "cannot implicitly convert expression (s) of type string to bool" > as in > > 1 void main () > 2 { > 3string s; > 4bool b = s; > 5 } > > Nonetheless in certain boolean contexts strings convert to bool > as here: > > 1 void main () > 2 { > 3import std.stdio; > 4string s; // equivalent to s = null > 5writeln (s ? true : false); > 6s = ""; > 7writeln (s ? true : false); > 8 } > > The code prints > > false > true > > to the console. This lead me to the insight, that in D there are > two > distinct kinds of empty strings: Those having a ptr which is null > and > the other. It seems that this ptr nullity not only determines > whether > the string compares equal to null in an IdentityExpression [1] > but also > the result of the above mentioned conversion in the boolean > context. > > I wonder if this distinction is meaningful and---if not---why it > is > exposed to the application programmer so prominently. > > Then today I found this piece of code > > 1 void main () > 2 { > 3string s = null; > 4string t = ""; > 5assert (s is t); > 6 } > > which, according to the wording in [1] > >"For static and dynamic arrays, identity is defined as > referring to > the same array elements and the same number of elements." > > shall succeed but its assertion fails [2]. I anticipate the > implementation compares the ptrs even in the case of zero > elements. > > A last example of 'deviant behavior' I found is this: > > 1 import std.stdio; > 2 import std.file; > 3 void main () > 4 { > 5string s = null; > 6try > 7 mkdir (s); > 8catch (Exception e) > 9 e.msg.writeln; > 10 > 11s = ""; > 12try > 13 mkdir (s); > 14catch (Exception e) > 15 e.msg.writeln; > 16 } > > Using DMD v2.073.2 the first expression terminates the programm > with a > segmentation fault. With 2.074.1 the program prints > > : Bad address > : No such file or directory > > I find that a bit confusing. > > [1] https://dlang.org/spec/expression.html#identity_expressions > [2] https://issues.dlang.org/show_bug.cgi?id=17623 A dynamic array in D is essentially struct DynamicArray(T) { size_t length; T* ptr; } That's not _exactly_ what it is at the moment (it actually does stuff with void* rather than templates unfortunately), but essentially, that's what it is and what it behaves like. In the case of dyanamic arrays, null is a dynamic array whose ptr is null and whose length is 0. The empty property for arrays checks whether the length of the array is 0. So, any array with a length of 0 (regardless of its ptr) is considered empty. The is expression checks for bitwise equality. So, arr is null checks for whether the array has a null ptr and a 0 length. In _most_ circumstances, that's equvialent to checking that the array's ptr is null, but if you do something screwy with unitialized memory, then you could end up with a ptr value of null and a non-zero length, and arr is null would be false. The == expression, on the other, hand checks that the elements are equal. So, it does something similar to if(lhs.length != rhs.length) return false; for(size_t i = 0; i < lhs.length; ++i) { if(lhs.ptr[i] != rhs.ptr[i]) return false; } return true; So, if the lengths are 0, no iterating happens, and the two arrays are considered equal. This means that a null array is equal to any other empty array, regardless of the value of ptr. It's also why I would consider arr == null to be a code smell. IMHO, if you want to check for empty, then you should use the empty property or check length directly, since those are clear about your intent, whereas with arr == null you always have the question of whether they should have used an is expression or whether they were simpy checking for an empty array. If you understand all of this, it is perfectly possible to write code which treats null arrays as distinct from empty arrays. However, it's _very_ easy to get into a situation where you have an empty array rather than a null one. Pretty much as soon as you do anything to a null array other than pass it around or compare it, trusting that it's still null can get error-prone. And that's why a number of folks think that it's just plain error-prone to try and treat null arrays as special - but some folks who understand
Re: CTFE output is kind of weired
On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote: app.d(17):called from here: test("1234\x0a5678\x0a") I wrote the source code on windows with a source file with \r\n file endings. But the console output has only the character X0a. In addition not the content of tmp is shown but the full content with the slice information [4..10]. Is this the intended behavior? The escape sequence says it's hex, and 0a translates to 10, and 0d is 13; \r\n is usually a 13,10 sequence. So from the looks of it the \r is getting stripped out. Funny story as i understand it, \r and \n both have very specific meanings to old printers in the old days. \r for carriage-Return, and \n for New-line. DOS may have used it, but \r more-or-less has no use for newlines and printers today. Curious when using writeln, all newlines seem to have \r sequences added. So i suppose it's one of those things that i never needed to think about really.
Re: CTFE output is kind of weired
On 07/08/2017 02:29 PM, Andre Pany wrote: > I use assert(false, tmp) to see the content of variable tmp as it seems > there is no other way in CTFE. A more natural way is pragma(msg), which you can use in main in this case: string test(string s) { string tmp = s; tmp = tmp[4..$]; return tmp; } enum foo = `1234 5678 `; void main() { enum bar = test(foo); pragma(msg, bar); } > The output is kind of weired: > app.d(6): Error: "1234\x0a5678\x0a"[4..10] > app.d(17):called from here: test("1234\x0a5678\x0a") Yes, looks pretty weird. :) I remember issues related to Unicode characters, which may be fixed by now, but the [4..10] part is news to me. Ali
CTFE output is kind of weired
Hi, I use assert(false, tmp) to see the content of variable tmp as it seems there is no other way in CTFE. The output is kind of weired: app.d(6): Error: "1234\x0a5678\x0a"[4..10] app.d(17):called from here: test("1234\x0a5678\x0a") I wrote the source code on windows with a source file with \r\n file endings. But the console output has only the character X0a. In addition not the content of tmp is shown but the full content with the slice information [4..10]. Is this the intented behavior? string test(string s) { string tmp = s; tmp = tmp[4..$]; assert(false, tmp); return tmp; } enum foo = `1234 5678 `; void main() { enum bar = test(foo); } Kind regards André
Re: Application settings
I use protocol buffers (using dproto) for this, storing my settings in either text or wire format. Advantages: type-safety with fwd/backward compatibility (unlike json which requires dynamic field access, eg with dproto you get errors at compile time instead of runtime), supports comments (although can be done w preprocessor on json config file), supports more types than json (especially binary without needing to base64 encode). On Sat, Jul 8, 2017 at 11:35 AM, Seb via Digitalmars-d-learnwrote: > On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote: >> >> On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote: >>> >>> On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote: On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote: > > [...] "best" always depends on your specific use case. I use json files via asdf [1] [1] https://github.com/tamediadigital/asdf >>> >>> >>> >>> Seems like quite a heavy package for what I need. I just want to write a >>> AA to disk and load it, ultimately. >> >> >> Then I would go with INI, because you'll ultimately just have key-value >> pairs. >> >> https://code.dlang.org/packages/baussini (Pretty old but should still work >> just fine.) > > > There is also inifiled: https://github.com/burner/inifiled (used for > Dscanner for example)
Faster alternatives to std.xml
What's the fastest XML-parser on code.dlang.org? Are there any benchmarks that show performance improvements compared to std.xml?
Re: The Nullity Of strings and Its Meaning
On 07/08/2017 07:16 PM, kdevel wrote: The assertion in line 6 fails. This failure gave rise to a more general investigation on strings. After some research I found that one "cannot implicitly convert expression (s) of type string to bool" as in [...] Nonetheless in certain boolean contexts strings convert to bool as here: 1 void main () 2 { 3import std.stdio; 4string s; // equivalent to s = null 5writeln (s ? true : false); 6s = ""; 7writeln (s ? true : false); 8 } Yeah, that's considered "explicit". Also happens with `if (s)`. The code prints false true to the console. This lead me to the insight, that in D there are two distinct kinds of empty strings: Those having a ptr which is null and the other. It seems that this ptr nullity not only determines whether the string compares equal to null in an IdentityExpression [1] but also the result of the above mentioned conversion in the boolean context. Yup. Though I'd say the distinction is null vs every other array, not null vs other empty arrays. null is one specific array. It happens to be empty, but that doesn't really matter. `foo is null` compares with the null array. It doesn't check for emptiness. Conversion to bool also compares with null. The concept of emptiness is unrelated. Maybe detecting empty arrays would be more useful. As far as I know, there's no killer argument either way. Changing it now would break code, of course. Personally, I wouldn't mind if those conversions to bool just went away. It's not obvious what exactly is being checked, and it's not hard to be explicit about it with .ptr and/or .length. But as Timon notes, that has been attempted, and it broke code. So it was reverted, and that's that. I wonder if this distinction is meaningful and---if not---why it is exposed to the application programmer so prominently. "Prominently"? It only shows up when you convert to bool. You only get surprised if you expect that to check for emptiness (or something else entirely). And you don't really have a reason to expect that. You can easily avoid the issue by being more explicit in your code (`arr.ptr is null`, `arr.length == 0`/`arr.empty`). Then today I found this piece of code 1 void main () 2 { 3string s = null; 4string t = ""; 5assert (s is t); 6 } which, according to the wording in [1] "For static and dynamic arrays, identity is defined as referring to the same array elements and the same number of elements." shall succeed but its assertion fails [2]. I anticipate the implementation compares the ptrs even in the case of zero elements. The spec isn't very clear there. What does "the same array elements" mean for empty arrays? Can two arrays refer to "the same array elements" but have different lengths? It seems like "referring to the same array elements" is supposed to mean "having the same value in .ptr" without mentioning .ptr. The implementation obviously compares .ptr and .length. A last example of 'deviant behavior' I found is this: 1 import std.stdio; 2 import std.file; 3 void main () 4 { 5string s = null; 6try 7 mkdir (s); 8catch (Exception e) 9 e.msg.writeln; 10 11s = ""; 12try 13 mkdir (s); 14catch (Exception e) 15 e.msg.writeln; 16 } Using DMD v2.073.2 the first expression terminates the programm with a segmentation fault. With 2.074.1 the program prints : Bad address : No such file or directory I find that a bit confusing. That looks like a bug/oddity in mkdir. null is as valid a string as "". It shouldn't give a worse exception message. But the message for `""` isn't exactly good, either. Of course the directory doesn't exist, yet; I'm trying to create it!
Re: Application settings
On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote: On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote: On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote: On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote: [...] "best" always depends on your specific use case. I use json files via asdf [1] [1] https://github.com/tamediadigital/asdf Seems like quite a heavy package for what I need. I just want to write a AA to disk and load it, ultimately. Then I would go with INI, because you'll ultimately just have key-value pairs. https://code.dlang.org/packages/baussini (Pretty old but should still work just fine.) There is also inifiled: https://github.com/burner/inifiled (used for Dscanner for example)
Re: The Nullity Of strings and Its Meaning
On 08.07.2017 19:16, kdevel wrote: I wonder if this distinction is meaningful Not nearly as much as it would need to be to justify the current behavior. It's mostly a historical accident. and---if not---why it is exposed to the application programmer so prominently. I don't think there is a good reason except backwards-compatibility. Also see: https://github.com/dlang/dmd/pull/4623 (This is the pull request that restored the bad behaviour after it had been fixed.)
The Nullity Of strings and Its Meaning
Yesterday I noticed that std.uri.decodeComponent does not 'preserve' the nullity of its argument: 1 void main () 2 { 3import std.uri; 4string s = null; 5assert (s is null); 6assert (s.decodeComponent); 7 } The assertion in line 6 fails. This failure gave rise to a more general investigation on strings. After some research I found that one "cannot implicitly convert expression (s) of type string to bool" as in 1 void main () 2 { 3string s; 4bool b = s; 5 } Nonetheless in certain boolean contexts strings convert to bool as here: 1 void main () 2 { 3import std.stdio; 4string s; // equivalent to s = null 5writeln (s ? true : false); 6s = ""; 7writeln (s ? true : false); 8 } The code prints false true to the console. This lead me to the insight, that in D there are two distinct kinds of empty strings: Those having a ptr which is null and the other. It seems that this ptr nullity not only determines whether the string compares equal to null in an IdentityExpression [1] but also the result of the above mentioned conversion in the boolean context. I wonder if this distinction is meaningful and---if not---why it is exposed to the application programmer so prominently. Then today I found this piece of code 1 void main () 2 { 3string s = null; 4string t = ""; 5assert (s is t); 6 } which, according to the wording in [1] "For static and dynamic arrays, identity is defined as referring to the same array elements and the same number of elements." shall succeed but its assertion fails [2]. I anticipate the implementation compares the ptrs even in the case of zero elements. A last example of 'deviant behavior' I found is this: 1 import std.stdio; 2 import std.file; 3 void main () 4 { 5string s = null; 6try 7 mkdir (s); 8catch (Exception e) 9 e.msg.writeln; 10 11s = ""; 12try 13 mkdir (s); 14catch (Exception e) 15 e.msg.writeln; 16 } Using DMD v2.073.2 the first expression terminates the programm with a segmentation fault. With 2.074.1 the program prints : Bad address : No such file or directory I find that a bit confusing. [1] https://dlang.org/spec/expression.html#identity_expressions [2] https://issues.dlang.org/show_bug.cgi?id=17623
problem overloading functions with complex enum type
import std.stdio; enum A : int { a, b }; enum B : int { a, b }; enum AS : string[2] { a = ["1","2"], b = ["3","4"] }; enum BS : string[2] { a = ["5","6"], b = ["7","8"] }; void func(A a) { writeln("A"); } void func(B b) { writeln("B"); } void funcs(AS a) { writeln("AS"); } void funcs(BS b) { writeln("BS"); } void test() { func(A.a); // no compiler error funcs(AS.a); // compiler error: matches both funcs(AS) and funcs(BS) } void main(string[] args) { } In the above code, the function with the simple enum type argument can be overloaded, but the function with the complex enum type argument cannot be overloaded. Is this a bug? Thx. Eric
Re: Finding source of typeid use
On Saturday, 8 July 2017 at 08:56:17 UTC, Rainer Schuetze wrote: On 08.07.2017 07:55, Nicholas Wilson wrote: On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote: On 08/07/2017 2:35 AM, Nicholas Wilson wrote: On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote: My library is generating a typeid from somewhere. e.g. typeid(const(Pointer!(cast(AddrSpace)1u, float))) [...] It seems to be coming from the need to hash the type, goodness knows why, which explains why I only get the const variety. https://github.com/dlang/druntime/blob/master/src/object.d#L253 Maybe? No, the culprit is https://github.com/dlang/druntime/blob/master/src/object.d#L1128 but IDK why it is being generated in the first place since nothing I wrote relies on being able to hash it. I suspect this is generated while building the hash function for your Pointer struct in buildXtoHash in ddmd/clone.d. Hmm, I found needToHash(StructDeclaration sd) which enumerates the fields If a field is a struct recurse, makes sense if the struct has an alias this, which Pointer does, generate a typeinfo, with a note to see https://issues.dlang.org/show_bug.cgi?id=14948 / dmdPR 5001.
Re: Finding source of typeid use
On 08.07.2017 07:55, Nicholas Wilson wrote: On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote: On 08/07/2017 2:35 AM, Nicholas Wilson wrote: On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote: My library is generating a typeid from somewhere. e.g. typeid(const(Pointer!(cast(AddrSpace)1u, float))) [...] It seems to be coming from the need to hash the type, goodness knows why, which explains why I only get the const variety. https://github.com/dlang/druntime/blob/master/src/object.d#L253 Maybe? No, the culprit is https://github.com/dlang/druntime/blob/master/src/object.d#L1128 but IDK why it is being generated in the first place since nothing I wrote relies on being able to hash it. I suspect this is generated while building the hash function for your Pointer struct in buildXtoHash in ddmd/clone.d.
Re: Double value is rounded to unexpected value: 2.5 -> 2 instead of 3
Thanks, that was what was happening.
Re: Finding source of typeid use
On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote: On 08/07/2017 2:35 AM, Nicholas Wilson wrote: On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote: My library is generating a typeid from somewhere. e.g. typeid(const(Pointer!(cast(AddrSpace)1u, float))) [...] It seems to be coming from the need to hash the type, goodness knows why, which explains why I only get the const variety. https://github.com/dlang/druntime/blob/master/src/object.d#L253 Maybe? No, the culprit is https://github.com/dlang/druntime/blob/master/src/object.d#L1128 but IDK why it is being generated in the first place since nothing I wrote relies on being able to hash it.