Re: Error: function std.stdio.setmode is not accessible from module a
On Thursday, 3 November 2016 at 08:04:45 UTC, Jonathan M Davis wrote: [...] Thank you for a detailed clarification about setmode availability. I'll think more about how to proceed with it, and whether I should request it in druntime. I will try to make a bug report about deprecation. Thanks! Kirill
Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays
On 11/3/16 11:48 PM, safety0ff wrote: On Thursday, 3 November 2016 at 13:19:17 UTC, Steven Schveighoffer wrote: So technically, the freelist is still needed. In case I wasn't clear in my previous post: We can't use a freelist because it breaks safety. Yes, you can't use a free-list when removing nodes. AA used to actually free the memory, but that was decided against long ago. There are so many possibilities if we just move to a templated type. -Steve
Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays
On Thursday, 3 November 2016 at 13:19:17 UTC, Steven Schveighoffer wrote: So technically, the freelist is still needed. In case I wasn't clear in my previous post: We can't use a freelist because it breaks safety.
Re: not callable error
On Friday, 4 November 2016 at 02:28:17 UTC, bluphantom91 wrote: Hello, I am trying to finish up a group project but I am running into a small problem. I keep getting an error about fgetc not being callable. The purpose of my program is to count the number of characters in a file. Any bit of help is appreciated! Here's my code: import std.stdio; import std.file; import std.string; Since you're using the C library stdio functions, you should import core.stdc.stdio
Calling std.variant.visit from a pure function
As a learning exercise, I'm writing a simple AST evaluator for arithmetic expressions in D. (See https://gist.github.com/ckirkendall/2934374) In order to get a feel for functional programming in D, I decided to try and implement my solution in a functional style, using algebraic data types and pure functions. Here's the code: import std.variant; import std.typecons; enum Op { Plus, Minus, Times, Div } alias Expr = Algebraic!( double, string, Tuple!(Op, "op", This*, "lhs", This*, "rhs") ); double eval(Expr expr, double[string] env) pure { return expr.visit!( (double x) pure => x, (string v) pure => env[v], (Tuple!(Op, "op", Expr*, "lhs", Expr*, "rhs") bop) pure { final switch (bop.op) with (Op) { case Plus: return eval(*bop.lhs, env) + eval(*bop.rhs, env); break; case Minus: return eval(*bop.lhs, env) - eval(*bop.rhs, env); break; case Times: return eval(*bop.lhs, env) * eval(*bop.rhs, env); break; case Div: return eval(*bop.lhs, env) / eval(*bop.rhs, env); break; } } )(); } When I compile this (using DMD 2.069 on Debian Linux), I get an error saying that I can't call visit from a pure function. This is surprising, since all visit does (in theory) is call the provided functions, and all of _them_ are pure. My question is, is this an unavoidable limitation of visit's implementation, or is there a way to work around this?
not callable error
Hello, I am trying to finish up a group project but I am running into a small problem. I keep getting an error about fgetc not being callable. The purpose of my program is to count the number of characters in a file. Any bit of help is appreciated! Here's my code: import std.stdio; import std.file; import std.string; void main() { FILE *file; char ch; int charCount,wordCount,input; //File file = File("test.txt","w"); //input=fscanf(file, "%ch",); //file.writeln("hello"); //string s = file.readln(); file=fopen("test,txt","r"); while(!file.eof()) { /*string line = chomp(file.readln()); wordCount++; writeln(wordCount);*/ ch = getc(file); charCount++; } file.close(); }
Re: CTFE Status
On Thu, 03 Nov 2016 15:44:20 +, Marc Schütz wrote: > On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote: >> I intend to keep the current implemntation around as a fallback. >> For things that are used rarely. >> like floating point and others :) > > Is that a good idea? It means that there will be tons of really complex > code that is rarely if ever used and therefore gets no testing... I think the intent is that the current implementation will always be used for specific features, not that the compiler will attempt to run CTFE with the bytecode version and resort to the previous implementation if something goes wrong.
Re: Release D 2.072.0
On Friday, 4 November 2016 at 00:42:48 UTC, Johan Engelen wrote: On Thursday, 3 November 2016 at 15:51:22 UTC, Steven Schveighoffer wrote: Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items. My question is: any cycle is invalid? nevermind, I found this: https://dlang.org/spec/module.html#order_of_static_ctor
Re: Release D 2.072.0
On Thursday, 3 November 2016 at 15:51:22 UTC, Steven Schveighoffer wrote: Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items. My question is: any cycle is invalid? -Johan
Re: If Statement with Declaration
On Thursday, 3 November 2016 at 22:32:17 UTC, Stefan Koch wrote: On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote: So I was thinking of a way of extending if statements that have declarations. The following being as example of the current use of if statements with declarations: [...] Just Introduce another block { int i = someFunc(); if (i >= 0) { ... } } // i is not visible here Introducing a block is not intuitive and cause an identation. As a reference, C++17 has adopted a proposal about this, and extended to switch: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html
Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays
On Thursday, 3 November 2016 at 21:00:56 UTC, Yuxuan Shui wrote: How about let the user provide the memory block when they calls reserve()? I'd love to see this type of option almost everywhere.
Re: If Statement with Declaration
On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote: So I was thinking of a way of extending if statements that have declarations. The following being as example of the current use of if statements with declarations: [...] Just Introduce another block { int i = someFunc(); if (i >= 0) { ... } } // i is not visible here
If Statement with Declaration
So I was thinking of a way of extending if statements that have declarations. The following being as example of the current use of if statements with declarations: if(int* weDontPollute = someFunc()) { // use weDontPollute } That's great and all, but it only works by checking if the variable evaluates to true or false. Which is fine for a pointer but otherwise useless for anything else, like integers where zero is usually valid input (index for array). So currently the only way to do something like this in the language, that i've found, is to use a for statement. for(int i = someFunc(); i >= 0;) { // use i break; } Not that ideal to use a for statement. It makes it hard to read and if the break condition isn't there it might very well be an infinite loop. So I was thinking of some sort of syntax like this: if(int i = someFunc(); i >= 0) { // use i } Thoughts on this sort of feature?
Re: fPIC Error
On Thursday, 3 November 2016 at 06:11:48 UTC, rikki cattermole wrote: Took me a while to replicate your build environment but it looks like a false alarm. rikki@debian:/tmp/test$ dmd test.d rikki@debian:/tmp/test$ file test test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0a6394b9ec9b82e07440ab62cd71932f0ab568d1, not stripped rikki@debian:/tmp/test$ ./test Edit source/app.d to start your project. rikki@debian:/tmp/test$ cat /etc/dmd.conf ; ; dmd.conf file for dmd ; ; dmd will look for dmd.conf in the following sequence of directories: ; - current working directory ; - directory specified by the HOME environment variable ; - directory dmd resides in ; - /etc directory ; ; Names enclosed by %% are searched for in the existing environment and inserted ; ; The special name %@P% is replaced with the path to this file ; [Environment32] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so [Environment64] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so Thanks for looking at it and confirming you are seeing the same thing. I am no expert, but after some additional research I think I see what is going on. From what I read the gcc -fPIC option creates a shared library, while gcc -fPIE option creates an executable. You can also create a dual purpose file that is a shared library and is also executable by creating a shared library if that file also contains a main function (that might be oversimplified a little bit). Looking at the dmd documentation, it only has a -fPIC option, there is no -fPIE option, which has the following description: generate Position Independent Code (which is used for building shared libraries). So, if I am understanding everything correctly because dmd only has -fPIC, the only option is to create a dual purpose file that is both a shared library and executable.
Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays
On Wednesday, 2 November 2016 at 03:36:42 UTC, Andrei Alexandrescu wrote: [snip] * The implementation cannot use Phobos' allocator because it's in druntime. How about let the user provide the memory block when they calls reserve()? Please share your thoughts. Thanks, Andrei
[Issue 9094] GC not collecting under Windows
https://issues.dlang.org/show_bug.cgi?id=9094 Jesse Phillipschanged: What|Removed |Added Status|RESOLVED|REOPENED CC||jesse.k.phillip...@gmail.co ||m Resolution|WONTFIX |--- --- Comment #4 from Jesse Phillips --- I'm having this issue with Windows 64bit on 30MB files, and it appears is also affecting zip extraction of similar size. I'm reopening so the issue can be re-evaluated considering this isn't just a 32bit + gigabyte file issue. Does anyone have a suggestion for manually releasing the expanded data when using std.zip.ZipArchive.expand() on a ArchiveMember? --
Re: What is the simplest way of doing @nogc string concatenation?
On 11/3/16 2:54 PM, Gary Willoughby wrote: What is the simplest way of doing @nogc string concatenation? Where does it go? For instance, this should work: auto newstr = "hello, ".chain("world"); -Steve
Re: What is the simplest way of doing @nogc string concatenation?
On Thursday, November 03, 2016 18:54:14 Gary Willoughby via Digitalmars-d- learn wrote: > What is the simplest way of doing @nogc string concatenation? std.range.chain is the closest that you're going to get with actual strings. Dynamic arrays require the GC to do concatenation, because they have to allocate a new string. Now, you can do stuff like char[] mallocConcat(const(char)[] lhs, const(char)[] right) { immutable len = lhs.length + right.length; return (cast(char*)malloc(len))[0 .. len]; } But then you have to worry about keeping track of that memory allocation somehow so that you free it appropriately later. Similarly, if you're dealing with some sort of maximum string size, you could have static array somewhere that you assign to and slice, but then you have to have somewhere appropriate for that static array to live - which is simple enough if you're just going to operate on it and then let it go away but is much harder if you actually want to pass the slice around like a normal string. Really, if you want to be doing actual string concatenation without the GC and have it be sane, you need a string type which handles its own memory - presumably using malloc. Concenation with dynamic arrays really needs the GC - particularly in light of the fact that dynamic arrays are not reference counted. In general though, I'd suggest trying to use chain and operating on ranges rather than creating an actual string to operate on. And if you want to avoid the whole auto-decoding thing in the process, you can combine it with std.utf.byCodeUnit. - Jonathan M Davis
What is the simplest way of doing @nogc string concatenation?
What is the simplest way of doing @nogc string concatenation?
Re: is there "this"?
On Thursday, November 03, 2016 09:40:11 Steven Schveighoffer via Digitalmars-d-learn wrote: > On 11/2/16 4:43 AM, Jonathan M Davis via Digitalmars-d-learn wrote: > > On Wednesday, November 02, 2016 02:42:01 Konstantin Kutsevalov via > > > > Digitalmars-d-learn wrote: > >> I tested already and it really works, thank you. > >> I asked that because I tried once to use "this" in past but I got > >> error. So I asked on some forum "how to get property of class?" > >> and peoples said that I may use just a name of property. So I > >> thought that there isn't "this" word. > > > > I don't know why you were having trouble before, but I think that most > > people never use an explicit this unless they need to, so plenty of > > folks > > would have just told you to remove the this from you code, especially if > > it worked without. > > In the case of the original post, however, you *need* to use this.value, > as the parameter masks the member of the same name. Using 'this' removes > ambiguity. > > This is a typical pattern seen in many languages. Often the intuitive > name of a member is the same name as you want for the parameter of the > constructor. Yeah. That's the only reason that I ever use the this pointer/reference. - Jonathan M Davis
Re: Compilation phobos errors with DMD 2.071,2.072 or dub
Really? This issue is here on forum many times, can you pleas read last few post? Just by name. Sent from my Samsung device. Original message From: Ozan (ONS) via Digitalmars-d-learnSent: 03/11/2016 15:55:24 To: digitalmars-d-learn@puremagic.com Subject: Compilation phobos errors with DMD 2.071,2.072 or dub Hi, with a fresh Ubuntu 16.10 installation using "Hello, World" I got a list of following errors like: /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(thread_256_713.o): relocation R_X86_64_32 against symbol `_D6object9Throwable7__ClassZ' can not be used when making a shared object; recompile with -fPIC Example: Using dmd 2.071 and dub; dub init appName; compile appName with dub. Or direct with dmd What I'm missing? Any hints? Thanks & Regards, Ozan
Re: CTFE Status
On Thursday, 3 November 2016 at 15:44:20 UTC, Marc Schütz wrote: On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote: I intend to keep the current implemntation around as a fallback. For things that are used rarely. like floating point and others :) Is that a good idea? It means that there will be tons of really complex code that is rarely if ever used and therefore gets no testing... Passing the whole test-suite is as good as it gets.
Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!
On Thursday, 3 November 2016 at 12:19:09 UTC, Sönke Ludwig wrote: Does "if (!_ctfe) assert(false);" work, too? That would also protect against accidential mistakes. Doesn't seem like it. { assert(false); return; } works (in reducing compile time) but generates "statement is not reachable" warnings for the return statement.
[Issue 16660] Deprecate/Remove Optlink as Default Linker on Windows
https://issues.dlang.org/show_bug.cgi?id=16660 --- Comment #1 from Martin Krejcirik--- Well, -m32 doesn't require VC installed, that's major point. --
Re: CTFE Status
On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote: I intend to keep the current implemntation around as a fallback. For things that are used rarely. like floating point and others :) Is that a good idea? It means that there will be tons of really complex code that is rarely if ever used and therefore gets no testing...
Re: Release D 2.072.0
On 10/31/2016 03:27 AM, Martin Nowak wrote: > Glad to announce D 2.072.0. NB: Current release notes are outdated and wrong about `-transition=safe` flag. It was completely repurposed in stable branch (https://github.com/dlang/dmd/pull/6183) but somehow changes to release notes there do not propagate to released changelog. signature.asc Description: OpenPGP digital signature
Compilation phobos errors with DMD 2.071,2.072 or dub
Hi, with a fresh Ubuntu 16.10 installation using "Hello, World" I got a list of following errors like: /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(thread_256_713.o): relocation R_X86_64_32 against symbol `_D6object9Throwable7__ClassZ' can not be used when making a shared object; recompile with -fPIC Example: Using dmd 2.071 and dub; dub init appName; compile appName with dub. Or direct with dmd What I'm missing? Any hints? Thanks & Regards, Ozan
Re: Release D 2.072.0
On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote: On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote: I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor... Maybe after this: https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368 ddmd.attribs was removed https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15 and it was also part of the cycle. Thanks for the detective work. I wonder where the bug is: in 2.071 or in 2.072 :)
[Issue 16654] hashOf returns different hashes for the same string value
https://issues.dlang.org/show_bug.cgi?id=16654 Steven Schveighofferchanged: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- As I determined in that thread, note that core.internal.hash.hashOf does not do the same thing as object.hashOf. It hashes only the bits of the given type. I can't think of a single valid reason for hashing the pointer and length of an array instead of the contents of the array. I don't know the right answer here, but at the very least hashOf isn't documented or understood properly. --
[Issue 16654] hashOf returns different hashes for the same string value
https://issues.dlang.org/show_bug.cgi?id=16654 --- Comment #2 from Steven Schveighoffer--- (In reply to Steven Schveighoffer from comment #1) > As I determined in that thread, note that core.internal.hash.hashOf does not > do the same thing as object.hashOf. It hashes only the bits of the given > type. It being object.hashOf. core.internal.hash.hashOf does a more reasonable thing. --
Re: Release D 2.072.0
On 11/2/16 8:36 AM, Johan Engelen wrote: On Tuesday, 1 November 2016 at 16:40:42 UTC, Andrei Alexandrescu wrote: On 11/01/2016 11:41 AM, Johan Engelen wrote: On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD 2.071.2 for CI testing. :( Is there somebody working on that bug? Thanks. -- Andrei LDC built with DMD 2.072.0 gives the following error when run: object.Error@src/rt/minfo.d(356): Cyclic dependency between module ddmd.traits and ddmd.cond ddmd.traits* -> ddmd.attrib -> ddmd.cond* -> ddmd.expression -> ddmd.traits* The issue is that DDMD has cycles, always has. But the cycle detection was broken. This is now fixed in 2.072. An unfortunate side effect from having broken cycle detection since 2011 is that many projects will now detect cycles. 2.072 is going to break a lot of code that was already "broken". I use scare quotes because likely the code is just fine, but the cycle detection is so broad that it's easy to get caught in the net. The best answer is to somehow do better cycle detection (e.g. determine if there really are dependencies that break with cycles). We have some ideas, but nothing has been fleshed out yet. -Steve
Re: is there "this"?
On 11/2/16 4:43 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Wednesday, November 02, 2016 02:42:01 Konstantin Kutsevalov via Digitalmars-d-learn wrote: I tested already and it really works, thank you. I asked that because I tried once to use "this" in past but I got error. So I asked on some forum "how to get property of class?" and peoples said that I may use just a name of property. So I thought that there isn't "this" word. I don't know why you were having trouble before, but I think that most people never use an explicit this unless they need to, so plenty of folks would have just told you to remove the this from you code, especially if it worked without. In the case of the original post, however, you *need* to use this.value, as the parameter masks the member of the same name. Using 'this' removes ambiguity. This is a typical pattern seen in many languages. Often the intuitive name of a member is the same name as you want for the parameter of the constructor. -Steve
Re: Benchmarking Time Unit
On 11/3/16 9:03 AM, Steven Schveighoffer wrote: On 11/1/16 6:55 PM, Nordlöw wrote: On Tuesday, 1 November 2016 at 20:54:34 UTC, Steven Schveighoffer wrote: MonoTime has about 5-10 % fluctuations on my laptop. Is this as good as it gets? This is not clear. What is this a percentage of? It percentage of execution time. 15 ms +- 2 ms 2ms variance is not horrendous or unexpected on a non-realtime system. Put another way, this is not a symptom of MonoTime having issues. -Steve
Re: Is the following code legal?
On 11/2/16 11:17 AM, Adam D. Ruppe wrote: On Wednesday, 2 November 2016 at 14:21:32 UTC, Shachar Shemesh wrote: The D documentation (https://dlang.org/spec/hash-map.html) leaves this not defined. The foreach statement is defined to not allow it: http://dlang.org/spec/statement.html#ForeachStatement "The aggregate must be loop invariant, meaning that elements to the aggregate cannot be added or removed from it in the NoScopeNonEmptyStatement." That's only for builtins. Obviously, there are cases where it can work, and it needs to be defined by the aggregate/range. I think the documentation should be updated to reflect that. To answer the original question, it's not valid with the current implementation AFAIK. I don't think we should define ever that it is valid, even if we have an implementation that supports it, as this restricts our implementation to always supporting it. I'll point at my dcollections library as an example where the currently iterated value can be removed: https://github.com/schveiguy/dcollections/blob/master/concepts.txt#L81 I think Java also allows this, and C++ allows this. -Steve
Re: Release D 2.072.0
On Thursday, 3 November 2016 at 12:17:29 UTC, Sönke Ludwig wrote: Am 03.11.2016 um 06:58 schrieb Andre Pany: Temp-folder builds are only done if the special shebang invocation syntax is used (i.e. "dub file.d Building with "dub --single file.d" should build normally. This was the case within the thread, too. Has anything changed since then? Unfortunately yes, the behavior of dub included in dmd 2.072 is not as expected (windows & linux). /+ dub.sdl: name "app" +/ void main(){} dub --single app.d Running ..\..\..\..\..\Users\abcdef\AppData\Local\Temp\.dub\build\app-~master\application-debug-windows-x86-dmd_2072-A4FA96FDE8C9353FB025486E4835F2E0\app.exe Same behavior for dub build --single app.d Kind regards André
Re: https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays
On 11/1/16 11:36 PM, Andrei Alexandrescu wrote: Our student Alex has been looking at this and I wanted to open the floor for a bit of discussion before we embark on an implementation. Last time I looked our associative arrays were arrays of singly-linked lists. It follows that in order to implement reserve() we'd need a freelist allocator approach, which preallocates a bunch of nodes in a single contiguous block of memory. They have changed. Collisions are now handled via finding the next available slot in the array. However, elements of the array are still pointers to entries. So technically, the freelist is still needed. But I'm not sure preallocating into a contiguous block is the best approach. People don't expect a hashtable to hold onto all the memory it has used in the past when you remove most of the elements. In dcollections, I let the allocator take care of the details of allocation. I think the best thing to do is to preallocate the array at least (so no rehashing occurs during additions of nodes), and then move towards a templated solution that can use a custom allocator for tuning the performance/memory usage tradeoff. -Steve
Re: hashOf()
On Thursday, 3 November 2016 at 13:11:41 UTC, Steven Schveighoffer wrote: On 11/2/16 12:14 PM, Márcio Martins wrote: [...] You are not the only one: https://forum.dlang.org/post/nv85ou$gi5$1...@digitalmars.com Note, I wholly disagree with the idea that hashOf(arr) hashes the pointer and length elements. I get why it does, and get what the charter of hashOf is. But nobody expects it. IMO, hashOf should fail to compile on types that contain pointers, including arrays. In fact, I'm thinking hashOf shouldn't even be available in object. It's completely inconsistent with all other forms of hashing a type (which use typeinfo, opHash, etc.). It's too low-level, and should be accessible only via an import. -Steve That's what I'd expect as well. The hashOf() in core.internal.hash is useful, and it works intuitively, IMO, so if one is implicitly imported it should be that one...
Re: hashOf()
On 11/2/16 12:14 PM, Márcio Martins wrote: There are 2 hashOf() definitions, one in object.d and one in core.internal.hash.d If you include core.internal.hash, you cannot call hashOf() anymore, because it conflicts with the implicit import in object.d, this is annoying in itself... The bigger issue though, is that they have different semantics: import core.internal.hash : hashOfInt = hashOf; void main() { string moo = "moo"; assert(moo.hashOfInt == moo.idup.hashOfInt); // ok - hashes moo.ptr[0..moo.length] assert(moo.hashOf == moo.idup.hashOf); // fail - hashes [0..moo.sizeof] } Did anyone else fall into this trap? You are not the only one: https://forum.dlang.org/post/nv85ou$gi5$1...@digitalmars.com Note, I wholly disagree with the idea that hashOf(arr) hashes the pointer and length elements. I get why it does, and get what the charter of hashOf is. But nobody expects it. IMO, hashOf should fail to compile on types that contain pointers, including arrays. In fact, I'm thinking hashOf shouldn't even be available in object. It's completely inconsistent with all other forms of hashing a type (which use typeinfo, opHash, etc.). It's too low-level, and should be accessible only via an import. -Steve
[Issue 16624] std.path.setExtension ddoc comment is strangely formated
https://issues.dlang.org/show_bug.cgi?id=16624 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9d1fc0750bec03cf1e9cc1fdbbefa8828ae0d418 [TRIVIAL, DDOC] fix issue 16624 - setExtension ddoc comment is strangely formated https://github.com/dlang/phobos/commit/bf2550fbc51c3080fd9e730140d1061048053ebc Merge pull request #4886 from BBasile/issue16624 [TRIVIAL, DDOC] fix issue 16624 - setExtension ddoc comment is strang… --
Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!
On 2016-11-03 04:43, Vladimir Panteleev wrote: As it turns out, DMD will codegen all functions, even templated ones when they're instantiated, whether they're called by something or not. With metaprogramming-heavy code, it's easy to run into some optimizer performance corner cases, however this may make an impact regardless. I guess the compiler assumes that a function can end up in a library and be called by some other program. Sounds like a whole program analysis/optimization would be required. Or if the compiler is invoked as building an executable it can assume it can avoid generating code for unused functions? To me it sounds like a @ctfe attribute would be useful. The compiler could enforce that functions annotated with @ctfe will only contain code that can be CTFE-able, can only be called in a CTFE context and will not generate any code. -- /Jacob Carlborg
Re: Benchmarking Time Unit
On 11/1/16 6:55 PM, Nordlöw wrote: On Tuesday, 1 November 2016 at 20:54:34 UTC, Steven Schveighoffer wrote: MonoTime has about 5-10 % fluctuations on my laptop. Is this as good as it gets? This is not clear. What is this a percentage of? It percentage of execution time. 15 ms +- 2 ms 2ms variance is not horrendous or unexpected on a non-realtime system. -Steve
[Issue 16660] New: Deprecate/Remove Optlink as Default Linker on Windows
https://issues.dlang.org/show_bug.cgi?id=16660 Issue ID: 16660 Summary: Deprecate/Remove Optlink as Default Linker on Windows Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: sprink.nore...@gmail.com It doesn't make sense to have Optlink as the default linker for 32-bit. It doesn't use the format of the platform and it can't link 64-bit programs. You have two different linkers being used by default. At the very least -m32mscoff should be the default and there should be a flag switch to use Optlink. It's an old linker that has some obscure bugs that won't be fixed. Replacing it with another linker that supports OMF (not sure there is one) could be an option, but even then I think COFF should still be the default. --
[Issue 5243] dmd -run potentially removes user files
https://issues.dlang.org/show_bug.cgi?id=5243 Eduard Staniloiuchanged: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Eduard Staniloiu --- I am marking this as resolved. I've reproduced the steps from Leandro's report, but the issue is not present anymore; the test file containing very important data is not erased. Then I tested the following piece of code: // test.d void main(string[] args) { writeln(args[0]); } Running $ dmd -run test.d outputs: /tmp/dmd_runnUHV2q As you can see, dmd -run now builds the code in /tmp/ and runs it from there. All of the above have been tested using the following dmd version: DMD64 D Compiler v2.073.0-devel-ab9d712 --
[Issue 16659] Clarify mutating while iterating rules
https://issues.dlang.org/show_bug.cgi?id=16659 --- Comment #2 from Andrei Alexandrescu--- See also: http://forum.dlang.org/thread/nvcspd$1ttj$1...@digitalmars.com --
Re: __traits(getMember)
On Wednesday, 2 November 2016 at 19:49:24 UTC, Jacob Carlborg wrote: On 2016-11-02 17:30, Márcio Martins wrote: Can we get a getMember and a getOverloads that won't check for visibility or anything else? __traits appears really powerful, but every-time I try to use it for anything other than a toy example or very simple serialization, it seems like everything falls apart due to some detail... and I end up having to hack it up with string mixins and static if(is(typeof(() { some_code; }))). For serialization, where you most likely only need to access the fields, you can use .tupleof which will bypass the protection. @Jonathan I am on 2.072.0, but good to know it's coming. @Jacob Thanks, that's good to know!
[Issue 16659] Clarify mutating while iterating rules
https://issues.dlang.org/show_bug.cgi?id=16659 Andrei Alexandrescuchanged: What|Removed |Added Assignee|nob...@puremagic.com|alexandru.razva...@gmail.co ||m --
[Issue 16659] Clarify mutating while iterating rules
https://issues.dlang.org/show_bug.cgi?id=16659 Andrei Alexandrescuchanged: What|Removed |Added Assignee|alexandru.razva...@gmail.co |nob...@puremagic.com |m | --- Comment #1 from Andrei Alexandrescu --- Alex, I'm passing this to you since you've already looked at AAs a bit. --
Re: Code signing to help with Windows virus false positives
On 11/3/16 7:34 AM, Ethan Watson wrote: Turns out we have some good contacts at F-Secure though. So I can see about getting the problem fixed at the detection level - and because of the way the security community operates, that knowledge should flush across to things like Windows Defender. That would be awesome. Thanks! -- Andrei
[Issue 16659] Clarify mutating while iterating rules
https://issues.dlang.org/show_bug.cgi?id=16659 Andrei Alexandrescuchanged: What|Removed |Added CC||and...@erdani.com Assignee|nob...@puremagic.com|alexandru.razva...@gmail.co ||m --
Re: Release D 2.072.0
Am 03.11.2016 um 06:58 schrieb Andre Pany: On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. http://dlang.org/download.html This is the release ships with the latest version of dub (v1.1.0), comes with lots of phobos additions and native TLS on OSX. See the changelog for more details. http://dlang.org/changelog/2.072.0.html -Martin Thanks for the new release. There is an issue with this Dub version, which is as far as I understand a bug. While building/running a single source file project (dub information included in D source file) the artifacts are created in a temporary folder instead of the source file folder. This makes the single file functionality in dub more or less not usable for me, as you cannot influence the behavior. http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/13012/ Kind regards André Temp-folder builds are only done if the special shebang invocation syntax is used (i.e. "dub file.d --single file.d" should build normally. This was the case within the thread, too. Has anything changed since then?
Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!
Am 03.11.2016 um 04:43 schrieb Vladimir Panteleev: For each function that is only called during compilation (e.g. for code generation), at the top add: if (!__ctfe) return; That's it. For one project, this brought compilation time (with optimizations) from over an hour down to seconds! As it turns out, DMD will codegen all functions, even templated ones when they're instantiated, whether they're called by something or not. With metaprogramming-heavy code, it's easy to run into some optimizer performance corner cases, however this may make an impact regardless. Does "if (!_ctfe) assert(false);" work, too? That would also protect against accidential mistakes.
Re: Code signing to help with Windows virus false positives
http://imgur.com/5DnCWYw One of our guys just tried compiling and running a simple Hello World program. F-Secure jumped right in. Code signing the compiler isn't enough. It's been a persistent problem around here with DMD generated binaries that F-Secure will pick it up. Needless to say, if this happens out in the wild with one of our games you won't want me to paste a single line from the feedback we'll get about the game not working. Turns out we have some good contacts at F-Secure though. So I can see about getting the problem fixed at the detection level - and because of the way the security community operates, that knowledge should flush across to things like Windows Defender.
Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!
On 11/3/16 5:20 AM, Andrei Alexandrescu wrote: On 11/02/2016 11:43 PM, Vladimir Panteleev wrote: For each function that is only called during compilation (e.g. for code generation), at the top add: if (!__ctfe) return; That's it. For one project, this brought compilation time (with optimizations) from over an hour down to seconds! As it turns out, DMD will codegen all functions, even templated ones when they're instantiated, whether they're called by something or not. With metaprogramming-heavy code, it's easy to run into some optimizer performance corner cases, however this may make an impact regardless. That's interesting. cc Dmitry, perhaps adding that to ctRegex would be helpful. -- Andrei For ctRegex it's hardly applicable as it reuses the same code for run-time and compile-time version. --- Dmitry Olshansky
Re: CTFE Status
On Thursday, 3 November 2016 at 00:02:46 UTC, Stefan Koch wrote: No need for prayer. I am trying my best to be doing solid engineering work. Neither god nor the devil will paly any role. Got it.
Re: Speed up compilation of CTFE-heavy programs with this One Weird Trick!
On Thursday, 3 November 2016 at 03:43:06 UTC, Vladimir Panteleev wrote: For each function that is only called during compilation (e.g. for code generation), at the top add: if (!__ctfe) return; That's it. For one project, this brought compilation time (with optimizations) from over an hour down to seconds! As it turns out, DMD will codegen all functions, even templated ones when they're instantiated, whether they're called by something or not. Sounds like an issue. Although, I almost think a @noctfe tag which would refuse to compile/use code during CTFE, or in effect add that line at the beginning to functions invisibly. Obviously having functions only voluntarily used for CTFE would be a pain. having a section Opt Out after a certain point seems more useful, and would require far less work for the programmers.
Re: Error: function std.stdio.setmode is not accessible from module a
On Thursday, November 03, 2016 03:25:31 Kirill Kryukov via Digitalmars-d- learn wrote: > Thanks for the explanation, Jonathan! OK, I'll try adding my own > binding for the time being, and submit a feature request. > > I guess this does not count as regression since it was > undocumented, as you say. Although I would have thought it was a > documentation deficiency instead. Working, not obviously wrong > code stopped working without an alternative method available. > Perhaps it's OK if it can be added to druntime the future. It's a C binding, and there aren't supposed to be any public C bindings in Phobos outside of etc.c, and even that is pretty much a legacy thing, since bindings for 3rd party projects would normally go in deimos now. So, it's clear that it was accidental that setmode was public, and any time that you use a symbol that doesn't have a ddoc comment on it, you risk that your code will break later, even if that symbol really should have been private or package. It's not in the documentation, so it's an implementation detail and not part of the Phobos API. And there has been some recent work to make sure that undocumented symbols are either properly documented or made private or package, so anyone using undocumented symbols from Phobos definitely runs a risk of their code breaking, as you experienced. > Also I am confused by it being both deprecation and error. I > thought that deprecation message was just a warning about > something that will stop working in the future, and the code > should still compile. However in this case dmd first informs me > that something is deprecated (it's not clear what exactly is > deprecated). And then immediately fails with an error, on the > same function call. Is it another separate diagnostic issue, or > is it working as intended? That part is definitely weird. I don't know what's going on there exactly, but it probably relates to how private symbols used to be considered for stuff like function overloading just like public symbols, and the access level was only considered after that (meaning that private symbols could cause symbol conflicts), whereas that was fixed a release or two back. But I don't think that the symbol is actually completely invisible now like that deprecation warning implies, just not considered in overloading. But I don't know. Regardless, it's a diagnostic issue separate from setmode specifically. You can reproduce it easily enough with just creating a module with a private symbol and trying to use it in a module that imports it. So, that may very well merit a bug report. It's certainly not how deprecation warnings normally work, and I don't know under what circumstances you could get that warning without the error. The only time that I'm sure there's a difference is when there's a symbol conflict with a private symbol, and previously, you would have gotten an error, whereas now, you wouldn't, so there's nothing to warn about, just an error that went away. - Jonathan M Davis
Re: Is the following code legal?
On 02/11/16 16:52, Andrei Alexandrescu wrote: We should render it defined, and document it as such. Could you please create an issue and I'll have someone look at it. Thanks! -- Andrei https://issues.dlang.org/show_bug.cgi?id=16659
[Issue 16659] New: Clarify mutating while iterating rules
https://issues.dlang.org/show_bug.cgi?id=16659 Issue ID: 16659 Summary: Clarify mutating while iterating rules Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: shac...@shemesh.biz Consider the following program: int[int] hash; .. foreach( key, ref value; hash ) { if( value>12 ) hash.remove(key); } There is no reference in https://dlang.org/spec/hash-map.html whether this is legal or not (i.e. - removing an element from the hash while iterating it). According to http://dlang.org/spec/statement.html#ForeachStatement, this seems forbidden (in which case it needs to be documented in the first link), but a forum discussion seemed to gravitate toward needing to allow this (as C++ does, at least since C++14). --
Re: Linus' idea of "good taste" code
On Thursday, 3 November 2016 at 06:11:08 UTC, Joakim wrote: On Sunday, 30 October 2016 at 10:04:02 UTC, Patrick Schluter wrote: On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote: It is not worth it, the web is dying. I was stunned to see this chart of mobile web usage in the US: https://mobile.twitter.com/asymco/status/777915894659964928 This isn't some third-world country with mostly 2G usage, the web numbers in those places are much worse. Combined with mobile passing even TV for time spent, there is no point in wasting time porting D to a dying platform. Yes, because outside of web on mobile nothing else exists... bwahahahah Pretty soon it won't: https://mobile.twitter.com/asymco/status/793401867053195264 Even that chart shows a flattening to an asymptote not a linear trend. This means desktop will maube go a little bit down but it won't disappear. What people often forget is that professional office PC will never be completely replaced by mobile. What also happens in that branch (i.e. in office environment) is still a continuation to replace PC application by browser applications. This means that still focussing on good web solutions server or client side is a good investment in any case. On Sunday, 30 October 2016 at 16:35:54 UTC, Laeeth Isharc wrote: And wouldn't the changes to runtime and phobos be quite similar for both dmd and ldc? I don't see how the work flow would be any different as a language user whether you used an LDC with wasm back end, or dmd with similar. The changes to druntime and phobos wouldn't depend on the compiler used, but it is difficult to test unless you have a compiler with working codegen, so that usually comes first. You can go ahead and make changes to druntime- not much has to be done for phobos, as the idea is to encapsulate platform-specific code in druntime, though a minority of phobos does call platform-specific APIs- based on the spec or available headers, but you won't know if it will work well till you can run it. Joakim - native on mobile is so much better (setting aside having to deal with Apple or Google) but I guess the browser isn't going away on the desktop for a while yet. I'm actually a heavy web user, have been for almost a quarter-century (though I don't use webapps, mostly reading), which is why that chart was so surprising to me. While native mobile apps are usually more responsive, they are not ideal for reading, as I'm not going to install and load up The Verge's app, or an app for every other news site, every time. The problem for the desktop browser is that the desktop is going away, as the linked tweet above shows. No it is not. Linear extrapolation of an incomplete chart is almost always erroneous. I went from using a FreeBSD desktop and a dumbphone five years ago to an Android smartphone and two Android tablets today, ie no desktop or laptop since my ultrabook died late last year. In my household, we went from using two smartphones, two PC laptops, and a Mac laptop four years ago to three smartphones, three Android tablets, and a Mac laptop today. This is a shift that is happening in most households, as a PC overserves most and a mobile device will do. Many D users are power users who cling to old tech like the desktop and the web, so they are missing this massive wave going on right now. I myself missed the death of the mobile web, as I'm such a heavy user. still bwahahaha, web technology will stay a bit longer, panicking is a bit premature yet.
Re: Linus' idea of "good taste" code
On Sunday, 30 October 2016 at 10:04:02 UTC, Patrick Schluter wrote: On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote: It is not worth it, the web is dying. I was stunned to see this chart of mobile web usage in the US: https://mobile.twitter.com/asymco/status/777915894659964928 This isn't some third-world country with mostly 2G usage, the web numbers in those places are much worse. Combined with mobile passing even TV for time spent, there is no point in wasting time porting D to a dying platform. Yes, because outside of web on mobile nothing else exists... bwahahahah Pretty soon it won't: https://mobile.twitter.com/asymco/status/793401867053195264 On Sunday, 30 October 2016 at 16:35:54 UTC, Laeeth Isharc wrote: And wouldn't the changes to runtime and phobos be quite similar for both dmd and ldc? I don't see how the work flow would be any different as a language user whether you used an LDC with wasm back end, or dmd with similar. The changes to druntime and phobos wouldn't depend on the compiler used, but it is difficult to test unless you have a compiler with working codegen, so that usually comes first. You can go ahead and make changes to druntime- not much has to be done for phobos, as the idea is to encapsulate platform-specific code in druntime, though a minority of phobos does call platform-specific APIs- based on the spec or available headers, but you won't know if it will work well till you can run it. Joakim - native on mobile is so much better (setting aside having to deal with Apple or Google) but I guess the browser isn't going away on the desktop for a while yet. I'm actually a heavy web user, have been for almost a quarter-century (though I don't use webapps, mostly reading), which is why that chart was so surprising to me. While native mobile apps are usually more responsive, they are not ideal for reading, as I'm not going to install and load up The Verge's app, or an app for every other news site, every time. The problem for the desktop browser is that the desktop is going away, as the linked tweet above shows. I went from using a FreeBSD desktop and a dumbphone five years ago to an Android smartphone and two Android tablets today, ie no desktop or laptop since my ultrabook died late last year. In my household, we went from using two smartphones, two PC laptops, and a Mac laptop four years ago to three smartphones, three Android tablets, and a Mac laptop today. This is a shift that is happening in most households, as a PC overserves most and a mobile device will do. Many D users are power users who cling to old tech like the desktop and the web, so they are missing this massive wave going on right now. I myself missed the death of the mobile web, as I'm such a heavy user.
Re: fPIC Error
Took me a while to replicate your build environment but it looks like a false alarm. rikki@debian:/tmp/test$ dmd test.d rikki@debian:/tmp/test$ file test test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0a6394b9ec9b82e07440ab62cd71932f0ab568d1, not stripped rikki@debian:/tmp/test$ ./test Edit source/app.d to start your project. rikki@debian:/tmp/test$ cat /etc/dmd.conf ; ; dmd.conf file for dmd ; ; dmd will look for dmd.conf in the following sequence of directories: ; - current working directory ; - directory specified by the HOME environment variable ; - directory dmd resides in ; - /etc directory ; ; Names enclosed by %% are searched for in the existing environment and inserted ; ; The special name %@P% is replaced with the path to this file ; [Environment32] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/i386-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so [Environment64] DFLAGS=-I/usr/include/dmd/phobos -I/usr/include/dmd/druntime/import -L-L/usr/lib/x86_64-linux-gnu -L--export-dynamic -fPIC -defaultlib=libphobos2.so
Re: Release D 2.072.0
On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote: Glad to announce D 2.072.0. http://dlang.org/download.html This is the release ships with the latest version of dub (v1.1.0), comes with lots of phobos additions and native TLS on OSX. See the changelog for more details. http://dlang.org/changelog/2.072.0.html -Martin Thanks for the new release. There is an issue with this Dub version, which is as far as I understand a bug. While building/running a single source file project (dub information included in D source file) the artifacts are created in a temporary folder instead of the source file folder. This makes the single file functionality in dub more or less not usable for me, as you cannot influence the behavior. http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/13012/ Kind regards André