Vote started for std.uni
Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org
Re: Vote started for std.uni
On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote: Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ?
DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ Enjoy! Discuss!! Vote!!! Andrei
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This link on the YouTube page seems to not be online: http://dconf.org/2013/talks/lucarella.pdf Bye, bearophile
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 .. but it's not clear to me how useful this is for fork emulation or similar. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Visual D 0.3.36 released - support for Alex Bothe's semantic analysis, LDC and profiling
On 16/05/2013 17:58, Ali Çehreli wrote: On 05/16/2013 03:08 AM, Bruno Medeiros wrote: On 14/05/2013 06:45, TommiT wrote: Notice that alias this = id is not supposed to be valid syntax. Huh, what's this about? DMD does not seem to recognize it, but it's listed in the grammar. Is it an upcoming feature or is the grammar out of date? When the other use of alias has been changed from alias int NewName; // weird syntax to alias NewName = int; // welcome syntax 'alias this' has also been inadvertently changed from alias memberFunc this;// still valid syntax to alias this = memberFunc; // buggy syntax It has been a recent bug which has quickly been reverted. Here is a past discussion: http://forum.dlang.org/thread/aaflopktcjmljxdno...@forum.dlang.org Ali Ah I see. I was about to ask why was it put in the grammar documentation then, but it seems it is no longer there for the online version of the documentation: http://dlang.org/declaration.html#AliasThisDeclaration It is still present in the documentaton of the 2.062 DMD download though, hence my confusion. :S (I was looking at the download doc) -- Bruno Medeiros - Software Engineer
Re: Vote started for std.uni
20-May-2013 12:15, deadalnix пишет: On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote: Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? At compile-time? The short answer is it should be possible but not quite yet. The long answer is: enum myA = unicode.alphabetic.toTrie!4; --- Error: CTFE internal error: unsupported assignment this = p uni.d(1841):called from here: this.data.opAssign((Uint24Array!(GcPolicy) __ctmp6762 = 0; , __ctmp6762).this(flattened)) uni.d(6742):called from here: (InversionList!(GcPolicy) __ctmp6477 = 0; , __ctmp6477).this(decompressIntervals(compressed)) --- So I forgot to reduce a bug it seems (or maybe I filed it). Another reason is that will be quite slow to compile (in the current setting). That's why all of tables in new std.uni were precomputed by constructing at run-time and serializing to source. This is actualy one of things I'd love to push as a separate feature Phobos-wide: serialization of objects to CTFE-able/mixin-able source code. Some of these done in std.uni weren't clean enough to fit into a public interface. Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ? I dunno. Technically I see no problem with std.unicode except that we have to patch old code and some ~1.5 year of painfully slow deprecation and for what? If the chief benefit of renaming is aesthetics then I'd rather pass. If we make it as part of restructuring of std.* that is long overdue then I'm fine but it's a discussion in its own. We should probably split the discussion-while-voting in a separate thread in D.d. -- Dmitry Olshansky
Re: Vote started for std.uni
On Monday, 20 May 2013 at 08:15:48 UTC, deadalnix wrote: On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote: Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? Anyway, as long as this is implementable, this have my vote. Second thing, it is probably too late, but let's ask anyway. Is that possible to rename the thing as std.unicode ? Please place this in the vote thread, or it will not be counted when I get to tallying.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Mon, 20 May 2013 08:50:25 -0400 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ Torrents up, as well as links: http://semitwist.com/download/misc/dconf2013/
Re: mysql-native: Seamlessly supports Phobos-only sockets
On Fri, 17 May 2013 02:08:05 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: If you want to use Phobos sockets, you can do it two ways: 1. Pass -version=MySQLN_NoVibeD to the compiler. This will completely eliminate all dependencies on Vibe.d (and remove all Vibe.d capabilities, naturally) and automatically use Phobos sockets. Everything else will be exactly the same (But see the caveat below). Since it makes a lot more sense for the default to be *no* external dependencies, I've flipped it around: By default, mysql-native is now Phobos-only and does *not* depend on Vibe.d (or any other third party lib). To enable the optional Vibe.d support (which also makes Vibe.d sockets the default instead of Phobos sockets, although you can explicitly choose either at runtime), then include the following compiler flag: -version=Have_vibe_d That flag above will be included automatically if you compile using DUB, and your project uses Vibe.d.
Re: mysql-native: Seamlessly supports Phobos-only sockets
Since it makes a lot more sense for the default to be *no* external dependencies, I've flipped it around: That's great thanks for your work on this.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote: On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 .. but it's not clear to me how useful this is for fork emulation or similar. R Fork isn't needed at all really in the technique described, this is all that's needed: - Map a copy of the memory using copy-on-write - Run some code concurrently It just happens that fork does both of these things, but you can equally well do the two things using separate calls. In fact you should be able to avoid the deadlock issue by not using fork but just remapping some shared memory using copy on write. The GC can exist in a separate thread which pauses itself after every run. To run the GC it's then just a case of: - stop the world - copy registers to stack - remap shared memory using COW - resume the world - resume the GC thread And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Monday, 20 May 2013 at 22:52:33 UTC, Diggory wrote: And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly. Copy on WRITE usually don't happen on immutable memory.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Tuesday, 21 May 2013 at 00:00:13 UTC, deadalnix wrote: On Monday, 20 May 2013 at 22:52:33 UTC, Diggory wrote: And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly. Copy on WRITE usually don't happen on immutable memory. I never said it did... I said that when using fork the immutable memory must be mapped into the new process, when using a thread it does not since threads share the same address space.
Re: Vote started for std.uni
On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote: 20-May-2013 12:15, deadalnix пишет: On Monday, 20 May 2013 at 06:19:29 UTC, Jesse Phillips wrote: Please cast your vote for std.uni at: http://forum.dlang.org/post/zczqphzzqnxvjflle...@forum.dlang.org Overall it looks great. I have one question l is it possible to build tries at runtime using CTFE ? At compile-time? The short answer is it should be possible but not quite yet. The long answer is: enum myA = unicode.alphabetic.toTrie!4; As long as it is doable, that sound good to me. Another reason is that will be quite slow to compile (in the current setting). That's why all of tables in new std.uni were precomputed by constructing at run-time and serializing to source. I understand. To me a caching compiler is the solution here, but that is kind of off topic. I dunno. Technically I see no problem with std.unicode except that we have to patch old code and some ~1.5 year of painfully slow deprecation and for what? If the chief benefit of renaming is aesthetics then I'd rather pass. If we make it as part of restructuring of std.* that is long overdue then I'm fine but it's a discussion in its own. We should probably split the discussion-while-voting in a separate thread in D.d. The problem wth that kind of naming convention is that names do not convey as much meaning. This can be an issue as the library get larger and larger, because you got to remember every single name and can't rely too much on autocompletion. uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.
Re: Vote started for std.uni
On Tuesday, 21 May 2013 at 01:25:54 UTC, deadalnix wrote: On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote: 20-May-2013 12:15, deadalnix пишет: uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever. I support renaming to std.unicode; In the long run, std.uni is just unexpressive.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote: On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 Yes, basically. I can't find where I've read that mapping COW memory from within the same process is only supported on NT versions. However, doing it from within the same process is not practical anyway, since that would imply at least halving the address space.
Re: DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella
On Tuesday, 21 May 2013 at 04:26:18 UTC, Vladimir Panteleev wrote: On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote: On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On reddit: http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/ This may be the Windows Copy On Write feature mentioned in the QA at the end: http://support.microsoft.com/kb/103858 Yes, basically. I can't find where I've read that mapping COW memory from within the same process is only supported on NT versions. However, doing it from within the same process is not practical anyway, since that would imply at least halving the address space. Either way, at least on windows the separate process would have to be persistent as creating a new process has a lot more overhead attached to it than on posix systems. Implicitly creating a child process is also something a D programmer might not want, again this is more windows specific where processes do not have the same strict hierarchy as on posix. On 64-bit systems there shouldn't be a problem with address space, and even on 32-bit systems, the objects which take up the vast majority of the address space are usually arrays of primitive types which don't need to be scanned by the GC. Certainly for 64-bit systems I think it's worth at least doing some performance comparisons, and I think using a thread will turn out to be more efficient. If it turns out that there are merits to both options then having a GC option to use a process or a thread might make sense.
