Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 19:41:57 UTC, Remo wrote: For Vector example this works pretty well this way. But my main problem is more complicated. extern(C) int init(ref CWrapper p); extern(C) void free(ref CWrapper p); struct CWrapper { //some data that must be the same at C side. Data m_data; this() { init(&this); } ~this() { free(&this); } } How to do something like this in D ? Using class appears for me to be wrong direction. 1) Please comment after previous speaker, not before. You can't avoid default struct constructor problem if functions which you call in constructors are not at least CTFEable because you would need to call them if you wish to define default struct constructor. Since this is not your case, you can do: 2) You can use static OpCall, Voldemort type or alias this. In case of alias this it looks like: extern(C) int printf(const char*, ...); extern(C) int init(CWrapper* p) { printf("init\n"); return 0; } extern(C) void d_free(CWrapper* p) { printf("free\n"); } struct Data { void do_something(){} } struct CWrapper { //some data that must be the same at C side. Data m_data; bool m_init; /*this(int) { init(&this); }*/ ~this() { d_free(&this); } Data get() { if (!m_init) init(&this); return m_data; } alias get this; } void main() { CWrapper cw; cw.do_something(); } In case of Voldermort struct some struct is defined inside function, so the only way (in theory) to create an instance is to call that function. It is inconviniet but guarantees that you will not have non initialzed structs (in theory). extern(C) int printf(const char*,...); auto make_struct() { struct Data{} struct CWrapper { extern(C) int m_init(CWrapper* p){ return 0; } extern(C) void m_free(CWrapper* p){ printf("free\n");} //some data that must be the same at C side. Data m_data; this(int) { m_init(&this); } ~this() { m_free(&this); } } return CWrapper(0); } void main() { auto x = make_struct(); } 4) Please do not define free() function.
Re: Struct constructor, opCall mess.
On Tuesday, 25 February 2014 at 06:06:22 UTC, Jesse Phillips wrote: On Monday, 24 February 2014 at 20:35:54 UTC, Remo wrote: This looks like D2 is still in Beta stadium and not really ready for production use !? If someone thinks that C++ was production ready in 1998, just go and try a C++ compiler from this time.
Re: What does q{...} mean?
On Monday, 24 February 2014 at 18:40:14 UTC, monarch_dodra wrote: Also, a "qstring" can only contain valid D tokens ("token string"). If your mixin string does not adhere some the base D syntaxic rules, you'll get a compilation error. In particular, you'll need balanced bracing/parenthesising, and correctly formed tokens. And even with all these rules, it still works great for other languages like Lua.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 20:35:54 UTC, Remo wrote: This looks like D2 is still in Beta stadium and not really ready for production use !? I believe it is ready for production, but you can't expect it to be ready in all cases. Mostly its lack of readiness isn't because of the language though. For example it isn't ready for production Android/iOS development, because it hasn't been done yet. It isn't ready for Epic to write Unreal 5 Engine in it. However if Valve believed in D I'd say it was ready for them to take on the challenge and write Source 2 in D.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 23:34:51 UTC, Remo wrote: Where I can find more info about 'D's move semantics'? Apparently it is not the same as rvalue reference and move semantics in C++11 ? Here is the place I know of: http://dconf.org/2013/talks/cehreli.html
Re: Strange behaviour with -profile
On Sunday, 23 February 2014 at 20:46:47 UTC, Jesse Phillips wrote: On Sunday, 23 February 2014 at 08:32:50 UTC, Danny Arends wrote: I have a medium sized project at: https://github.com/DannyArends/DaNode it compiles fine with the normal build switches I used: $ rdmd --build-only -O -gc -release -w danode/server.d if I compile with the -profile switch, I get a weird error: $ rdmd --build-only -O -gc -release -profile -w danode/server.d "Warning: statement is not reachable" I thought DMD provided an error if you tried to optimize with debug symbols. -O should not be used with -gc, -g, or -profile Maybe that will address the problem. While I think my advice is still correct, I can't seem to find the combination which caused a compiler message: dmd -g -O -profile -release -debug -inline test.d Also found that dub will do the same odd mix of switches: ["profile", "optimize", "inline", "debugInfo"] Debug and optimize just don't make sense together, and profile needs debug symbols I thought.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 21:06:03 UTC, monarch_dodra wrote: On Monday, 24 February 2014 at 17:15:10 UTC, Remo wrote: So what is proper/best way to mimic default constructor for struct ? Honestly, you can't, and you shouldn't try either. There "used" to be the static opCall that allowed: auto a = T(); But: a) This is being phased out: If T has a constructor, it will seize to compile. b) It's not "default": "T a;" will still compile, but not construct. The feedback I've been getting is that the "correct" way to guarantee construction is to do it via a named factory pattern. You disable the this(), so as to "force" initialization, and make the constructors private. You'll get something along the lines of: T a; //Nope. T a = T(); //Nope T a = T.build(); //OK! T a = T(1, 2); //Nope! T a = T.build(1, 2); //OK! T a = T.init; //OK! Special explicit requrest for non-initialisation. With D's move semantics and (N)RVO, there should be 0 overhead to do this. Thanks, I will try to make this this way and look how well it will work. But it could complicate connection from C++ to D and back. Where I can find more info about 'D's move semantics'? Apparently it is not the same as rvalue reference and move semantics in C++11 ?
Re: What does q{...} mean?
Gary Willoughby wrote: > I keep seeing this syntax used a bit and i'm stumped to what it > means. What is it? > > enum foo = q{ > // ??? > }; q{} string literals (so-called "token strings") are a nice D feature - D garantees that tokens in between brackets are valid D tokens. This makes them perfect for storing D source code. They are quite useful for string mixins for an example. -- http://dejan.lekic.org
Re: Unused mmap library comes as deprecation warning on compile
On 02/24/2014 12:20 PM, Tolga Cakiroglu wrote: > I have about 12 different separate programmes. While compiling only one > of them, it gives as warning as below: > > /usr/include/dmd/phobos/std/mmfile.d(344): Deprecation: alias > core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use > core.sys.linux.sys.mman for non-POSIX extensions It is a compilation message generated by druntime/src/core/sys/posix/sys/mman.d: static import core.sys.linux.sys.mman; deprecated("Please use core.sys.linux.sys.mman for non-POSIX extensions") alias MAP_ANON = core.sys.linux.sys.mman.MAP_ANON; So, phobos/std/mmfile.d imports a module that has been deprecated by druntime: private import core.sys.posix.sys.mman; Create a bug report or pull request ;) so that it imports the correct mman. Ali
Re: Programming to Interfaces simplification
On Mon, 24 Feb 2014 16:24:00 -0500, Frustrated wrote: On Monday, 24 February 2014 at 18:59:32 UTC, Steven Schveighoffer wrote: On Mon, 24 Feb 2014 11:36:50 -0500, Frustrated wrote: http://dpaste.dzfl.pl/c25655e2dfe9 The code above simplifies using interfaces as the programming object. It allows one to program the derived classes as if they were not part of an abstraction by mapping the abstracted virtual methods to concrete methods. e.g., class WindowsGui : iGui { WindowsButton _button; @property WindowsButton button(WindowsButton b) { return (_button = b); } mixin(Fixup!(WindowsGui, iButton, WindowsButton)); } instead of class WindowsGui : iGui { WindowsButton _button; @property iButton button(iButton b) { assert(cast(WindowsButton)b !is null, `Invalid object type dependency mismatch! Type: `~b.classinfo.name~` Type Expected: WindowsButton`); auto bb = cast(WindowsButton)b; // do work with bb. } } Nice work! One problem with the template is that b.classinfo.name returns the interface instead of the actual class. Hm... classinfo (now typeid) should get the most derived type from an instance. This may be a factor of it being an interface instance vs. a class instance. A simple test: Stevens-MacBook-Pro:~ steves$ cat testinterface.d import std.stdio; interface I { } class C : I { } void main() { I i = new C; writeln(typeid(i).name); writeln(typeid(cast(Object)i).name); } Stevens-MacBook-Pro:~ steves$ ./testinterface testinterface.I testinterface.C Looks like that is the case. Note that classinfo is not part of the language any more, and will likely be deprecated. typeid is the correct mechanism to get the TypeInfo of a derived class. I'm thinking this is incorrect, typeid should get the derived class type IMO. It shouldn't be that difficult or costly for the compiler to do. Thanks. Now the correct type is known. One could, for example, look for wrappers/adapters/etc to get a linuxbutton into a windowsbutton(if so desired, throw a well informed error, etc. Hopefully though, now you see the point. It is a runtime contract that you make since you can't specify it at compile time(since D doesn't supports it). Always have seen the point, it is why I suggested this solution. Unfortunately the main downside is the vtable is twice as big. Final or static methods could be used for this. If the compiler could manage such a system it could do the job better. (There would be no extra functions needed and the calls would be faster) First, the vtable is not per-instance, so it doesn't detract too much from the solution. Second, the concrete function does not need to be virtual, make it final, and it won't add to the vtable. The issue is this: I want to program to interfaces(requiring the class(WindowsGui) to use base interfaces(iButton) to satisfy the interface. The problem is this compile time contract is to generic and makes coding the classes more verbose. The mixin reduces the verbosity and provides a runtime contract(we enforce it using asserts in this case). The benefit of the mixin is that coding WindowsGui is simpler and more direct and it's dependency on WindowsButton(not iButton) is known at compile time(But enforced at runtime by assert). Would you not agree? Everything else is essentially identical. I have written such libraries before (I had an OS abstraction library in C++), it's not always pretty. -Steve
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 15:19:06 -0500, Hugo Florentino wrote: > On Mon, 24 Feb 2014 19:08:16 + (UTC), Justin Whear wrote: >> >> Specifically std.regex.splitter[1] creates a lazy range over the input. >> You can couple this with lazy file reading (e.g. >> `File("mailbox").byChunk (1024).joiner`). >> >> > Would something like this work? (I cannot test it right now) > > auto themailbox = args[1]; > immutable uint chunksize = 1024 * 64; > static auto re = regex(`\n\nFrom .+@.+$`); > auto mailbox; > auto mail; > while (mailbox = File(themailbox).byChunk(chunksize).joiner) != EOF) { >mail = splitter(mailbox, re); > } > > If so, I have a couple of furter doubts: > > Using splitter actually removes the expression from the string, how > could I reinsert it to the beginning of each resulting string in an > efficient way (i.e. avoiding copying something which is already loaded > in memory)? > > I am seeing the splitter fuction returns a struct, how could I > progressively dump to disk each resulting string, removing it from the > struct, so that so that it does not end up having the full mailbox > loaded into memory, in this case as a struct? > > Regards, Hugo The code you've posted won't work, primarily because you don't need to loop over the file-reading range, nor will it ever "return" EOF. Also, if you don't actually want to remove the regex matches, you can just use the matchAll function. Here's some _untested_ sample code to set you on the right track. import std.algorithm, std.range, std.stdio, std.regex; void main(string[] args) { auto mailboxPath = args[1]; immutable size_t chunksize = 1024 * 64; auto re = regex(`\n\nFrom .+@.+$`); // you might want to try using ctRegex auto mailStarts = File(mailboxPath).byChunk(chunksize).joiner .matchAll(re); } This code won't actually do any work--no data will be loaded from the file (caveat: the first chunk might be prefetched, not sure), no matches will actually be performed. If you use `take(10)` on the mailStarts variable, the code will load only as much of the file (down to the granularity of chunksize) as is needed to find the first 10 instances of the regular expression. The regex matches will not copy, but rather provide slices over the data that is in memory. And, thinking about this further, you don't want to use my code either-- partly because byChunk reuses its buffer, partly because the functions in std.regex provide slices over the input data. I think what you'll want to do is: load the data from File chunk-by-chunk lazily, scan each chunk with the regex, if you don't find a match, copy that data into an "overlap" buffer and repeat, if you do find a match then the contents of the overlap buffer + the slice up to the current match is one mail, rinse and repeat. You should be able to encapsulate all of this in clean, lazy range, but I don't have the time right now to work out if it can be done by simply compositing existing functions from Phobos. Justin
Re: Programming to Interfaces simplification
Fixed code with all combination examples: (again, only WindowsButton works with WindowsGui and same for LinuxGui... but the classes don't use iButton like they should!!! Oh, they break the contract!! End of the world!) http://dpaste.dzfl.pl/02ee45225303 Output: Trying WindowsButton with WindowsGui! Do(): WindowsButton WindowsButton.foo(): I'm an extra WindowsButton feature! ...WindowsButton works in WindowsGui! Trying LinuxButton with WindowsGui! Invalid object type dependency mismatch! Type: f324.LinuxButton Type Expected: WindowsButton Trying WindowsButton with LinuxGui! Invalid object type dependency mismatch! Type: f324.WindowsButton Type Expected: LinuxButton Trying LinuxButton with LinuxGui! Do(): LinuxButton ...LinuxButton works in LinuxGui!
Re: Programming to Interfaces simplification
On Monday, 24 February 2014 at 18:59:32 UTC, Steven Schveighoffer wrote: On Mon, 24 Feb 2014 11:36:50 -0500, Frustrated wrote: http://dpaste.dzfl.pl/c25655e2dfe9 The code above simplifies using interfaces as the programming object. It allows one to program the derived classes as if they were not part of an abstraction by mapping the abstracted virtual methods to concrete methods. e.g., class WindowsGui : iGui { WindowsButton _button; @property WindowsButton button(WindowsButton b) { return (_button = b); } mixin(Fixup!(WindowsGui, iButton, WindowsButton)); } instead of class WindowsGui : iGui { WindowsButton _button; @property iButton button(iButton b) { assert(cast(WindowsButton)b !is null, `Invalid object type dependency mismatch! Type: `~b.classinfo.name~` Type Expected: WindowsButton`); auto bb = cast(WindowsButton)b; // do work with bb. } } Nice work! One problem with the template is that b.classinfo.name returns the interface instead of the actual class. Hm... classinfo (now typeid) should get the most derived type from an instance. This may be a factor of it being an interface instance vs. a class instance. A simple test: Stevens-MacBook-Pro:~ steves$ cat testinterface.d import std.stdio; interface I { } class C : I { } void main() { I i = new C; writeln(typeid(i).name); writeln(typeid(cast(Object)i).name); } Stevens-MacBook-Pro:~ steves$ ./testinterface testinterface.I testinterface.C Looks like that is the case. Note that classinfo is not part of the language any more, and will likely be deprecated. typeid is the correct mechanism to get the TypeInfo of a derived class. I'm thinking this is incorrect, typeid should get the derived class type IMO. It shouldn't be that difficult or costly for the compiler to do. Thanks. Now the correct type is known. One could, for example, look for wrappers/adapters/etc to get a linuxbutton into a windowsbutton(if so desired, throw a well informed error, etc. Hopefully though, now you see the point. It is a runtime contract that you make since you can't specify it at compile time(since D doesn't supports it). In any case the mixin needs some work and testing. Would just like to get the proper class name for the type. It is, at the very least, a proof of concept. Unfortunately the main downside is the vtable is twice as big. Final or static methods could be used for this. If the compiler could manage such a system it could do the job better. (There would be no extra functions needed and the calls would be faster) The issue is this: I want to program to interfaces(requiring the class(WindowsGui) to use base interfaces(iButton) to satisfy the interface. The problem is this compile time contract is to generic and makes coding the classes more verbose. The mixin reduces the verbosity and provides a runtime contract(we enforce it using asserts in this case). The benefit of the mixin is that coding WindowsGui is simpler and more direct and it's dependency on WindowsButton(not iButton) is known at compile time(But enforced at runtime by assert). Would you not agree? Everything else is essentially identical.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 17:15:10 UTC, Remo wrote: So what is proper/best way to mimic default constructor for struct ? Honestly, you can't, and you shouldn't try either. There "used" to be the static opCall that allowed: auto a = T(); But: a) This is being phased out: If T has a constructor, it will seize to compile. b) It's not "default": "T a;" will still compile, but not construct. The feedback I've been getting is that the "correct" way to guarantee construction is to do it via a named factory pattern. You disable the this(), so as to "force" initialization, and make the constructors private. You'll get something along the lines of: T a; //Nope. T a = T(); //Nope T a = T.build(); //OK! T a = T(1, 2); //Nope! T a = T.build(1, 2); //OK! T a = T.init; //OK! Special explicit requrest for non-initialisation. With D's move semantics and (N)RVO, there should be 0 overhead to do this.
Re: What does q{...} mean?
On 2/24/14, 12:40, monarch_dodra wrote: Also, a "qstring" can only contain valid D tokens ("token string"). If your mixin string does not adhere some the base D syntaxic rules, you'll get a compilation error. In particular, you'll need balanced bracing/parenthesising, and correctly formed tokens. Oh, I did not know that. Interesting.
Re: Struct constructor, opCall mess.
Also please take a look at those: https://d.puremagic.com/issues/show_bug.cgi?id=7066 There may be some others I've missed; the sheer amount and unresolved state is terrifying. IMHO Issue 7066 is not a bug but a feature. Of course it could be handled i a bit more safe way. This looks like D2 is still in Beta stadium and not really ready for production use !?
Unused mmap library comes as deprecation warning on compile
I have about 12 different separate programmes. While compiling only one of them, it gives as warning as below: /usr/include/dmd/phobos/std/mmfile.d(344): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use core.sys.linux.sys.mman for non-POSIX extensions I used `grep` tool to see any of my library files or programme code have any use of this library. grep mmap -r Result is that binary files of all 12 different programmes have mmap in them. I wondered maybe a Phobos or druntime uses it. Used grep in `/usr/include/dmd` folder as well. As far as I see in the file list, unless mmap is directly imported, no other file uses it. The only thing different about that specific programme is that it uses "curl". Does anyone know why that deprecation message is seen while it is not used anywhere? Because that executable gives following error on GDB, and I am thinking that maybe that is its problem. Program received signal SIGUSR1, User defined signal 1. [Switching to Thread 0x2aaab1387700 (LWP 3418)] 0x2b97df7d in poll () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) quit
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 19:08:16 + (UTC), Justin Whear wrote: Specifically std.regex.splitter[1] creates a lazy range over the input. You can couple this with lazy file reading (e.g. `File("mailbox").byChunk (1024).joiner`). Would something like this work? (I cannot test it right now) auto themailbox = args[1]; immutable uint chunksize = 1024 * 64; static auto re = regex(`\n\nFrom .+@.+$`); auto mailbox; auto mail; while (mailbox = File(themailbox).byChunk(chunksize).joiner) != EOF) { mail = splitter(mailbox, re); } If so, I have a couple of furter doubts: Using splitter actually removes the expression from the string, how could I reinsert it to the beginning of each resulting string in an efficient way (i.e. avoiding copying something which is already loaded in memory)? I am seeing the splitter fuction returns a struct, how could I progressively dump to disk each resulting string, removing it from the struct, so that so that it does not end up having the full mailbox loaded into memory, in this case as a struct? Regards, Hugo
Re: Struct constructor, opCall mess.
Fortunately? Yes I think it is. Of course it could be made a more safe in some way. I think the big advantage of D is that it has 'bridge' to C and C++. This way it appears to be easy to port some C++ code to D. And it appears to be easy to interconnect C++ and D code. (via Dll for example) @disable this() Yes this is possible. But then why it is not possible to use something like this ? @default this(); For Vector example this works pretty well this way. But my main problem is more complicated. extern(C) int init(ref CWrapper p); extern(C) void free(ref CWrapper p); struct CWrapper { //some data that must be the same at C side. Data m_data; this() { init(&this); } ~this() { free(&this); } } How to do something like this in D ? Using class appears for me to be wrong direction. On Monday, 24 February 2014 at 18:13:02 UTC, Stanislav Blinov wrote: On Monday, 24 February 2014 at 17:15:10 UTC, Remo wrote: Well fortunately it seems to be possible to override init property. Fortunately? I think not. It's an abomination that, IMO, has to be annihilated. Recently Andrei suggested adding more explicit semantics to .init that may give some leeway in this matter, although this was concerning classes and non-null default values, so it may not concern structs at all. Regardless, my advice - don't try to override .init, i.e. don't invite trouble into your code :) But it still does not called at struct construction. http://melpon.org/wandbox/permlink/9EvcdzKUKoufqbJa Yup. So what is proper/best way to mimic default constructor for struct ? Don't do it. Default construction for struct *is* initialization of its fields. If you want to do something other that initialize fields - create a function and call it explicitly. D is not C++, don't expect it to behave identically. To make it easier when porting code, you can always temporarily @disable this() so the compiler will stop whenever you'd use your "special" default construction in C++. As you've mentioned, the code from your example doesn't need any special default constructors at all, this will work just fine: struct Vector(T) { T x = 0, y = 0, z = 0; this(T v) { x = y = z = v; } this(T x, T y, T z) { this.x = x; this.y = y; this.z = z; } } unittest { Vector!double v; auto v2 = Vector!double(1); auto v3 = Vector!double(1,2,3); assert(v.x == v.y && v.y == v.z && v.z == 0); assert(v2.x == v2.x && v2.y == v2.z && v2.z == 1); assert(v3.x == 1 && v3.y == 2 && v3.z == 3); } Also please take a look at those: https://d.puremagic.com/issues/show_bug.cgi?id=3438 https://d.puremagic.com/issues/show_bug.cgi?id=6080 https://d.puremagic.com/issues/show_bug.cgi?id=7066 https://d.puremagic.com/issues/show_bug.cgi?id=7597 https://d.puremagic.com/issues/show_bug.cgi?id=8816 https://d.puremagic.com/issues/show_bug.cgi?id=8817 https://d.puremagic.com/issues/show_bug.cgi?id=10413 https://d.puremagic.com/issues/show_bug.cgi?id=11307 There may be some others I've missed; the sheer amount and unresolved state is terrifying.
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 14:17:14 -0500, Hugo Florentino wrote: On Mon, 24 Feb 2014 14:00:09 -0500, Steven Schveighoffer wrote: std.regex I should have explained myself better. I have already used regular expressions a couple of times. My doubt here is how parse the file progressively, not loading it completely into memory. OK, I did not understand that. If this can be done solely with std.regex, please clarify futher I'm not completely sure, Justin may have a solution. I was thinking in using byLine, but for that, I see first I must use something like: auto myfile = File(usermbox); Doesn't that load the whole file into memory? I do know the answer to this, and it's no. File wraps a C FILE * buffered file. -Steve
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 19:08:16 + (UTC), Justin Whear wrote: Specifically std.regex.splitter[1] creates a lazy range over the input. You can couple this with lazy file reading (e.g. `File("mailbox").byChunk (1024).joiner`). Interesting, thanks.
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 14:00:09 -0500, Steven Schveighoffer wrote: std.regex I should have explained myself better. I have already used regular expressions a couple of times. My doubt here is how parse the file progressively, not loading it completely into memory. If this can be done solely with std.regex, please clarify futher I was thinking in using byLine, but for that, I see first I must use something like: auto myfile = File(usermbox); Doesn't that load the whole file into memory? Regards, Hugo
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 14:00:09 -0500, Steven Schveighoffer wrote: > On Mon, 24 Feb 2014 13:52:45 -0500, Hugo Florentino > wrote: > >> Hello, >> >> Can you point me to an efficient way to parse a text file and split it >> by certain expression (for example, `\n\nFrom\ .+@.+$`), copying what >> has already been read to a separate file, and so on till the end of the >> file? >> >> I am trying to implement a mailbox to maildir format conversion >> application in D, but I would like to avoid loading each mbox >> completely into memory. >> >> Regards, Hugo > > std.regex > > -Steve Specifically std.regex.splitter[1] creates a lazy range over the input. You can couple this with lazy file reading (e.g. `File("mailbox").byChunk (1024).joiner`). Justin
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 13:52:45 -0500, Hugo Florentino wrote: Hello, Can you point me to an efficient way to parse a text file and split it by certain expression (for example, `\n\nFrom\ .+@.+$`), copying what has already been read to a separate file, and so on till the end of the file? I am trying to implement a mailbox to maildir format conversion application in D, but I would like to avoid loading each mbox completely into memory. Regards, Hugo std.regex -Steve
Re: Programming to Interfaces simplification
On Mon, 24 Feb 2014 11:36:50 -0500, Frustrated wrote: http://dpaste.dzfl.pl/c25655e2dfe9 The code above simplifies using interfaces as the programming object. It allows one to program the derived classes as if they were not part of an abstraction by mapping the abstracted virtual methods to concrete methods. e.g., class WindowsGui : iGui { WindowsButton _button; @property WindowsButton button(WindowsButton b) { return (_button = b); } mixin(Fixup!(WindowsGui, iButton, WindowsButton)); } instead of class WindowsGui : iGui { WindowsButton _button; @property iButton button(iButton b) { assert(cast(WindowsButton)b !is null, `Invalid object type dependency mismatch! Type: `~b.classinfo.name~` Type Expected: WindowsButton`); auto bb = cast(WindowsButton)b; // do work with bb. } } Nice work! One problem with the template is that b.classinfo.name returns the interface instead of the actual class. Hm... classinfo (now typeid) should get the most derived type from an instance. This may be a factor of it being an interface instance vs. a class instance. A simple test: Stevens-MacBook-Pro:~ steves$ cat testinterface.d import std.stdio; interface I { } class C : I { } void main() { I i = new C; writeln(typeid(i).name); writeln(typeid(cast(Object)i).name); } Stevens-MacBook-Pro:~ steves$ ./testinterface testinterface.I testinterface.C Looks like that is the case. Note that classinfo is not part of the language any more, and will likely be deprecated. typeid is the correct mechanism to get the TypeInfo of a derived class. I'm thinking this is incorrect, typeid should get the derived class type IMO. It shouldn't be that difficult or costly for the compiler to do. -Steve
Parsing and splitting textfile
Hello, Can you point me to an efficient way to parse a text file and split it by certain expression (for example, `\n\nFrom\ .+@.+$`), copying what has already been read to a separate file, and so on till the end of the file? I am trying to implement a mailbox to maildir format conversion application in D, but I would like to avoid loading each mbox completely into memory. Regards, Hugo
Re: Does opSlice work with immutable values?
On Monday, 24 February 2014 at 17:11:20 UTC, Joseph Cassman wrote: The const/immutable language spec page states that mutable and immutable are implicitly convertible to const. Never thought about this in the other direction though. And from what I understand, the const keyword added to a function makes the this pointer const. Can't see exactly why this works but it does. Implicit conversion from immutable to const is exactly what's happening. It's not going the other direction. The this pointer is passed to the method via a hidden parameter. Qualifiers like const on methods really apply to that hidden this parameter. Then, when you call a const method on an immutable object, you really put an immutable object into a const parameter. And that's fine, because immutable implicitly converts to const. In code: struct S { void m() const {} } immutable S s; s.m(); is something like this behind the scenes: struct S {} void m(ref const S hidden_this) {} immutable S s; m(s);
Re: What does q{...} mean?
On Monday, 24 February 2014 at 17:47:55 UTC, 1100110 wrote: On 2/24/14, 11:06, Gary Willoughby wrote: On Monday, 24 February 2014 at 11:53:00 UTC, anonymous wrote: On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote: On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote: I keep seeing this syntax used a bit and i'm stumped to what it means. What is it? enum foo = q{ // ??? }; http://dlang.org/lex.html#DelimitedString It's a token string though, not a delimited string. See the section "Token Strings" on that page. What are they used for? Simpler for creating code at compile time? It allows IDE syntax highlighting and code completion to work with strings that are going to be mixed in. You don't have to use it, in fact there's no difference between this and a normal string. It's just nicer. Well... it's more than just "looking" nicer: there *are* some differences: For starters, a token string has no "terminating" character: You won't have to chose between " or `: It'll simply end with the "last" }. This means that if your mixin-string contains some strings itself, which itself contains quotes, you should have no problems with it. EG: auto code = q{ foreach(i; 0 .. 10) { writefln(`"hello" %s`, i); } }; Notice how there is nothing special denoting the last "}" as "end of string": It's *just* the end of string because it is the closing brace. The only times I've had "issues" is if you plan to use the "qstring" inside a format (*awesome* for generating code), and the generated code itself contains a formatted write, in which case, you'll need to escape the % => auto code = q{ foreach(i; 0 .. %s) { writefln("hello: %%s", i); } }; mixin(format(code, 10)); Also, a "qstring" can only contain valid D tokens ("token string"). If your mixin string does not adhere some the base D syntaxic rules, you'll get a compilation error. In particular, you'll need balanced bracing/parenthesising, and correctly formed tokens.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 17:15:10 UTC, Remo wrote: Well fortunately it seems to be possible to override init property. Fortunately? I think not. It's an abomination that, IMO, has to be annihilated. Recently Andrei suggested adding more explicit semantics to .init that may give some leeway in this matter, although this was concerning classes and non-null default values, so it may not concern structs at all. Regardless, my advice - don't try to override .init, i.e. don't invite trouble into your code :) But it still does not called at struct construction. http://melpon.org/wandbox/permlink/9EvcdzKUKoufqbJa Yup. So what is proper/best way to mimic default constructor for struct ? Don't do it. Default construction for struct *is* initialization of its fields. If you want to do something other that initialize fields - create a function and call it explicitly. D is not C++, don't expect it to behave identically. To make it easier when porting code, you can always temporarily @disable this() so the compiler will stop whenever you'd use your "special" default construction in C++. As you've mentioned, the code from your example doesn't need any special default constructors at all, this will work just fine: struct Vector(T) { T x = 0, y = 0, z = 0; this(T v) { x = y = z = v; } this(T x, T y, T z) { this.x = x; this.y = y; this.z = z; } } unittest { Vector!double v; auto v2 = Vector!double(1); auto v3 = Vector!double(1,2,3); assert(v.x == v.y && v.y == v.z && v.z == 0); assert(v2.x == v2.x && v2.y == v2.z && v2.z == 1); assert(v3.x == 1 && v3.y == 2 && v3.z == 3); } Also please take a look at those: https://d.puremagic.com/issues/show_bug.cgi?id=3438 https://d.puremagic.com/issues/show_bug.cgi?id=6080 https://d.puremagic.com/issues/show_bug.cgi?id=7066 https://d.puremagic.com/issues/show_bug.cgi?id=7597 https://d.puremagic.com/issues/show_bug.cgi?id=8816 https://d.puremagic.com/issues/show_bug.cgi?id=8817 https://d.puremagic.com/issues/show_bug.cgi?id=10413 https://d.puremagic.com/issues/show_bug.cgi?id=11307 There may be some others I've missed; the sheer amount and unresolved state is terrifying.
Re: Does opSlice work with immutable values?
On Monday, 24 February 2014 at 17:24:18 UTC, Ali Çehreli wrote: On 02/24/2014 09:11 AM, Joseph Cassman wrote: > the const keyword added to a [member] function makes the this pointer > const. Can't see exactly why this works but it does. const means "I will not modify data through this reference". Since there is not issue with modification, it can refer to mutable and immutable data. Ali P.S. It would be great if you could show the issue on a minimal code example. I tried to look at your original code but found it to be too long. Sorry... :) Thanks for the explanation. Yeah, wasn't sure whether the entire context would be better than providing a meaningless reduced code example. :P See what I can do. Joseph
Re: What does q{...} mean?
On 2/24/14, 11:06, Gary Willoughby wrote: On Monday, 24 February 2014 at 11:53:00 UTC, anonymous wrote: On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote: On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote: I keep seeing this syntax used a bit and i'm stumped to what it means. What is it? enum foo = q{ // ??? }; http://dlang.org/lex.html#DelimitedString It's a token string though, not a delimited string. See the section "Token Strings" on that page. What are they used for? Simpler for creating code at compile time? It allows IDE syntax highlighting and code completion to work with strings that are going to be mixed in. You don't have to use it, in fact there's no difference between this and a normal string. It's just nicer.
Re: Does opSlice work with immutable values?
On 02/24/2014 09:11 AM, Joseph Cassman wrote: > the const keyword added to a [member] function makes the this pointer > const. Can't see exactly why this works but it does. const means "I will not modify data through this reference". Since there is not issue with modification, it can refer to mutable and immutable data. Ali P.S. It would be great if you could show the issue on a minimal code example. I tried to look at your original code but found it to be too long. Sorry... :)
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 14:14:43 UTC, Tobias Pankrath wrote: On Monday, 24 February 2014 at 13:56:01 UTC, Remo wrote: Hi, right now I am truing to figure out how the constructors behave in D2. Question 1: why it is not possible to create custom ctor for struct? The design of D relies on the fact that every type has a T.init property that is known to the compiler and used when in C++ the default ctor would get called. In constructors you can rely on (this == T.init), for example. You need to pick one T.init or default constructors and D picked T.init. Well fortunately it seems to be possible to override init property. But it still does not called at struct construction. http://melpon.org/wandbox/permlink/9EvcdzKUKoufqbJa So what is proper/best way to mimic default constructor for struct ?
Re: Does opSlice work with immutable values?
On Monday, 24 February 2014 at 11:37:43 UTC, anonymous wrote: Mark opSlice const then. That did it. Thanks. The const/immutable language spec page states that mutable and immutable are implicitly convertible to const. Never thought about this in the other direction though. And from what I understand, the const keyword added to a function makes the this pointer const. Can't see exactly why this works but it does. Anyways appreciate the help. Joseph
Re: What does q{...} mean?
On Monday, 24 February 2014 at 11:53:00 UTC, anonymous wrote: On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote: On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote: I keep seeing this syntax used a bit and i'm stumped to what it means. What is it? enum foo = q{ // ??? }; http://dlang.org/lex.html#DelimitedString It's a token string though, not a delimited string. See the section "Token Strings" on that page. What are they used for? Simpler for creating code at compile time?
Re: What does q{...} mean?
>>> On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote: I keep seeing this syntax used a bit and i'm stumped to what it means. What is it? enum foo = q{ // ??? }; >> It's a token string though, not a delimited string. See the >> section "Token Strings" on that page. For Gary: the main use is that your IDE / Editor probably does not know about it and hence does not highlight/colour it as a string. If you put to-be-mixed-in code inside this token string, it'll be highlighted as code in editor. It helps catching stoopid mistakes like writing 'imutable i = foo();'.
Programming to Interfaces simplification
http://dpaste.dzfl.pl/c25655e2dfe9 The code above simplifies using interfaces as the programming object. It allows one to program the derived classes as if they were not part of an abstraction by mapping the abstracted virtual methods to concrete methods. e.g., class WindowsGui : iGui { WindowsButton _button; @property WindowsButton button(WindowsButton b) { return (_button = b); } mixin(Fixup!(WindowsGui, iButton, WindowsButton)); } instead of class WindowsGui : iGui { WindowsButton _button; @property iButton button(iButton b) { assert(cast(WindowsButton)b !is null, `Invalid object type dependency mismatch! Type: `~b.classinfo.name~` Type Expected: WindowsButton`); auto bb = cast(WindowsButton)b; // do work with bb. } } (note the check and the cast are required for all usages of iButton if one wants to treat it as a WindowsButton. By using the mix, no checks and no casts are required. Much cleaner looking and less verbose code results, which is the whole point.) One problem with the template is that b.classinfo.name returns the interface instead of the actual class. In the example on dpaste, b.classinfo.name returns iButton, the base interface of LinuxButton. I want to display the actual class name that causes the problem(LinuxButton trying to be used where a WindowsButton goes). Obviously the Fixup template is not robust nor optimized for all cases but should handle most.
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 13:08:52 UTC, Mengu wrote: On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. Perhaps we have to fix the online docs to underline this. Bye, bearophile what's the difference? Well for anything that does not have indirections eg numbers / chars and structs without classes/arrays/pointers in them. Then the two functions are equivalent. So: int[] first = uninitializedArray!(int[])(n); int[] second = minimallyInitializedArray!(int[])(n); Both first and second contain garbaged values. int*[] third = uninitializedArray!(int*[])(n); int*[] forth = minimallyInitializedArray!(int*[])(n); The third array contains garbage but all elements in forth are initialized to null. I assume this behavior is this way since an int with a garbage value is not as bad as a garbage pointer dereference into memory. The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. True but uninitializedArray corresponds to = void semantics for all arrays. minimallyInitializedArray is safer though so i guess it should be used. Wouldn't it be nice to have some kind of syntactic sugar for this similar to what we have for static arrays? BTW: Why isn't simply the following allowed? int n = 3; int[n] = void; Is it too easy to confuse with static array syntax? I don't like this, since it would be wierd from an allocation view point. How is int[n] allocated? Is it the GC? Is it alloca? Can i overide the allocation mechanism? Does the allocated array behave the same as a static array? (it gets destroyed if it goes out of scope) I think it gets a little confusing and also personally i don't want more hidden memory allocations. We already have alot of those.
Re: Scalability in std.parallelism
On Sun, 2014-02-23 at 22:55 -0800, Ali Çehreli wrote: […] > On my quad-core Intel I get the following (I have two actual cores, four > hyperthreads): > > 3.14159 took 441[ms] > 3.14159 took 878[ms] > Speedup 1.99093 > -5.80829e+09 took 98[ms] > -5.80829e+09 took 328[ms] > Speedup 3.34694 > > I am not an expect at all but it looks like the first test cannot take > advantage of hyperthreading but the second one can to some degree. I'm fairly sure I don't agree with this hypothesis. Two cores with hyperthreads generally means a maximum speed up of 2 with optimized native code. So for me the first one looks fine whereas the second one seems to indicate a problem in std.parallelism. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Scalability in std.parallelism
On Sat, 2014-02-22 at 16:21 +, "Nordlöw" wrote: > In the following test code given below of std.parallelism I get > some interesting results: > > when compiled as > > dmd -release -noboundscheck -O -inline -w -wi -wi > ~/Work/justd/t_parallelism.d -oft_parallelism > > My scalability measures says the following > > 3.14159 took 221[ms] > 3.14159 took 727[ms] > Speedup 3.28959 > -5.80829e+09 took 33[ms] > -5.80829e+09 took 201[ms] > Speedup 6.09091 > > Why do I get a larger speed for a simpler map function? > Shouldn't it be the opposite? I'm not sure just now, but it is an interesting issue. On my 7 year old twin 2.33GHz Xeon, I get: 3.14159 took 128[ms] 3.14159 took 860[ms] Speedup 6.71875 -5.80829e+09 took 28[ms] -5.80829e+09 took 302[ms] Speedup 10.7857 > I've always read that the more calculations I perform on each > memory access the better the speedup... Not necessarily, it depends on the caches and lots of other fun things. > Anyhow the speedups are great! > > I'm sitting on a Intel Quad core with 8 hyperthreads. As anyone involved in native code CPU-bound benchmarking will tell you, hyperthreads are generally a waste of time. So on your machine I'd expect a "flat out" speed up of 4 on your machine, 8 on mine. Virtual machines, e.g. JVM and PVM, can sometimes do interesting things that make hyperthreads useful. > Sample code follows: Hey, I recognize the core of this code, it's my π by quadrature example. Sadly π is not well approximately by -5.80829e+09 :-) I shal tinker with this a bit as I want to understand why the speed up is greater than the number of cores. It implies overhead in one of the algorithms. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 13:56:01 UTC, Remo wrote: Hi, right now I am truing to figure out how the constructors behave in D2. Question 1: why it is not possible to create custom ctor for struct? The design of D relies on the fact that every type has a T.init property that is known to the compiler and used when in C++ the default ctor would get called. In constructors you can rely on (this == T.init), for example. You need to pick one T.init or default constructors and D picked T.init.
Struct constructor, opCall mess.
Hi, right now I am truing to figure out how the constructors behave in D2. Question 1: why it is not possible to create custom ctor for struct? I know this is not really necessary because you can initialize fields like this. struct S{ int i = 1; } But this is a big problem if one tries to port C++ code to D2 and default ctor call some important initialization code. Question 2: is there a way to mimic compiler generated ctor (that work in CTFE)? Question 3: why it is possible to call static opCall like this? VectorC v5 = v4(1.0); Right now opCall seems to be better as this(...) because it work in CTFE but because of unwanted calls this is not well at all. Question 4: why this(...) does not work in CTFE mode? Here is highly simplified test code. http://melpon.org/wandbox/permlink/ofvNby99mKqOBQBf I am asking this because I am learning D2 now by porting and warping/connecting some big C++ (C++11) project to D2.
Re: Non-Initialized Dynamic Arrays Construction
Mengu: what's the difference? After you have read the online docs of both function what's your best guess of an answer? Bye, bearophile
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. Perhaps we have to fix the online docs to underline this. Bye, bearophile what's the difference?
Re: Non-Initialized Dynamic Arrays Construction
On 2/24/14, bearophile wrote: > The OP wants minimallyInitializedArray. uninitializedArray is > only for special situations. There needs to be a ddoc-ed sample demonstrating *exactly* what the difference between minimallyInitializedArray and uninitializedArray is.
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 12:08:31 UTC, Nordlöw wrote: On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. Wouldn't it be nice to have some kind of syntactic sugar for this similar to what we have for static arrays? BTW: Why isn't simply the following allowed? int n = 3; int[n] = void; Is it too easy to confuse with static array syntax? to me, it also looks like you are creating an array of ints, and trying to void it's reference. I honestly don't like the look of it either. Something like "auto arr = new float[n].void" would fit better, but still looks horrible IMO :)
Re: Non-Initialized Dynamic Arrays Construction
On 02/24/2014 01:08 PM, "Nordlöw" wrote: On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. Wouldn't it be nice to have some kind of syntactic sugar for this similar to what we have for static arrays? BTW: Why isn't simply the following allowed? int n = 3; int[n] = void; Is it too easy to confuse with static array syntax? Seems very dangerous. If n is available at compile-time it's a static array, else it's dynamic..?
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. Wouldn't it be nice to have some kind of syntactic sugar for this similar to what we have for static arrays? BTW: Why isn't simply the following allowed? int n = 3; int[n] = void; Is it too easy to confuse with static array syntax?
Re: What does q{...} mean?
On Monday, 24 February 2014 at 11:53:00 UTC, anonymous wrote: On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote: On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote: I keep seeing this syntax used a bit and i'm stumped to what it means. What is it? enum foo = q{ // ??? }; http://dlang.org/lex.html#DelimitedString It's a token string though, not a delimited string. See the section "Token Strings" on that page. Yeah right. It's hard to find quick the right anchors...
Re: What does q{...} mean?
On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote: On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote: I keep seeing this syntax used a bit and i'm stumped to what it means. What is it? enum foo = q{ // ??? }; http://dlang.org/lex.html#DelimitedString It's a token string though, not a delimited string. See the section "Token Strings" on that page.
Re: What does q{...} mean?
On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote: I keep seeing this syntax used a bit and i'm stumped to what it means. What is it? enum foo = q{ // ??? }; http://dlang.org/lex.html#DelimitedString
What does q{...} mean?
I keep seeing this syntax used a bit and i'm stumped to what it means. What is it? enum foo = q{ // ??? };
Re: Does opSlice work with immutable values?
On Monday, 24 February 2014 at 07:02:00 UTC, Joseph Cassman wrote: I have a custom number type in the works here (https://github.com/joichiro/kuttaka/commit/a226d3368a64ae63b0c256c4f4a4ede375a5cee8). The test code for opSlice works in this commit. However, when I change the auto to immutable (on line 308) I get the following error (a similar error occurs for const): src/bcd.d(309): Error: mutable method kuttaka.bcd.BcdSingle.opSlice is not callable using a immutable object src/bcd.d(310): Error: mutable method kuttaka.bcd.BcdSingle.opSlice is not callable using a immutable object src/bcd.d(311): Error: mutable method kuttaka.bcd.BcdSingle.opSlice is not callable using a immutable object Failed: ["dmd", "-unittest", "-v", "-o-", "src/bcd.d", "-Isrc"] How can I get immutable to work here? My thinking is that opSlice is creating a new object here so the sliced object should be allowed to be const or immutable. Mark opSlice const then.
Re: Non-Initialized Dynamic Arrays Construction
TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. Perhaps we have to fix the online docs to underline this. Bye, bearophile
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 11:11:44 UTC, Nordlöw wrote: Is it possible void construct a dynamic array such as b in int n = 3; auto b = new float[n]; similar to what we do with static arrays as in int[3] c = void; http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want.
Non-Initialized Dynamic Arrays Construction
Is it possible void construct a dynamic array such as b in int n = 3; auto b = new float[n]; similar to what we do with static arrays as in int[3] c = void;
Re: Scalability in std.parallelism
On Saturday, 22 February 2014 at 16:21:21 UTC, Nordlöw wrote: In the following test code given below of std.parallelism I get some interesting results: Don't forget that "n.iota.map" is returning a lazily evaluated range. Std.parallelism might have to convert the lazy range to a random access range (i.e. an array,) before it can schedule the work. If I add ".array" after the map call (e.g. auto nums = n.iota.map!piTerm.array;) I get numbers closer to the ideal for test2. Now we compare the differences between test1 and test2: test1 is reducing doubles and test2 is reducing ints. I believe that the reason for the difference in speed up is because you have hyper threads and not true independent threads. Hyper threads can contend for shared resources in the CPU (e.g. cache and FPU.) On my computer, forcing the nums to be a range of doubles in test2 causes the speed up to drop to approximately the same as test1. Regards.
Re: IFTI with value / template value parameter shadowing
On Sunday, 23 February 2014 at 11:49:26 UTC, Marc Schütz wrote: There's no IFTI here. IFTI is about inferring a template argument (= type) from the type of a function argument. Your template argument is a value, not a type, so there's nothing to infer. There is the value. In IFTI_Type, the compiler understands that the 'T' in the parameter list is the same as the 'T' in the TemplateArgumentList. For example this code compiles (from bug #4986): - struct Foo(int n, int m) { void bar(int m2)(Foo!(m2, n) arg) {} } void main( )( ) { Foo!(3,2) f; Foo!(3,3) g; f.bar(g); } - So the compiler can deduce a value argument from a type, but not from a value known at compile time. Not sure what you want to achieve. Do you want IFTI_Value(6) to be instantiated as IFTI_Value!6(6)? In this case, just leave the runtime parameter out: Yeah that works, and actually I agree that passing a value both in the parameters and template argument seems silly / odd at first sight. But there can be valid reasons to do so. I came accross this example while trying to shift a runtime argument to compile time while keeping source-level compatibility in a library. In addition it looks like template parameter are not considered while looking if a symbol with shadow another one. I didn't find anything on the bugtracker but (this)[https://d.puremagic.com/issues/show_bug.cgi?id=6980], but it's only related. I believe it works exactly as intended. The short form for template functions is just syntactic sugar for: template IFTI_Value(int n) { int IFTI_Value(int n) { return n; } } This means that the function (runtime) parameter n is declared in the inner scope, and is thus expected to shadow the template parameter n in the outer scope. I have to give it a second read but IIRC the TDPL was pretty much saying that shadowing is not legal in D.
Re: Scalability in std.parallelism
I am not an expect at all but it looks like the first test cannot take advantage of hyperthreading but the second one can to some degree. Yes, that is my hypothesis aswell :) Thx
Re: Scalability in std.parallelism
Don't rely on dmd when making raw performance tests. On my machine (i3-2100, two cores): dmd2 -O -release -inline 3.14159 took 368[ms] 3.14159 took 713[ms] Speedup 1.9375 -5.80829e+09 took 61[ms] -5.80829e+09 took 201[ms] Speedup 3.29508 ldc2 -O3 -release 3.14159 took 360[ms] 3.14159 took 718[ms] Speedup 1.99444 -5.80829e+09 took 0[ms] -5.80829e+09 took 0[ms] Speedup -nan ldc2 -O3 -release -vectorize -vectorize-loops 3.14159 took 193[ms] 3.14159 took 721[ms] Speedup 3.73575 -5.80829e+09 took 0[ms] -5.80829e+09 took 0[ms] Speedup -nan