Re: [OT] My C++ talk at GoingNative 2013
On 2013-09-10 14:54, Olivier Grant wrote: First of all, I very much enjoyed the talk. It was as interesting as it was entertaining. Yes, I enjoyed it as well. I do have a question regarding the talk's section on devirtualization. As a language that imposes virtual methods for classes, how well does D play when it comes to devirtualization? And on a side note, does D have a different way of implementing virtual methods than most C++ compilers do? In D it seems that currently the preferred way to compile a project is to compile all the source at once using RDMD or similar. Isn't that a great opportunity for full program analysis to do devirtualization? -- /Jacob Carlborg
Re: DUB 0.9.17/0.9.18 have been released + now on code.dlang.org
Same here with chromium on a win7 64. 2013/9/13 growler growler...@gmail.com On Friday, 13 September 2013 at 00:56:27 UTC, Craig Dillabaugh wrote: On Thursday, 12 September 2013 at 21:30:38 UTC, Craig Dillabaugh wrote: On Thursday, 12 September 2013 at 21:06:22 UTC, Kapps wrote: On Thursday, 12 September 2013 at 18:01:43 UTC, Craig Dillabaugh wrote: Currently any attempt to access the precompiled binaries, eg: http://code.dlang.org/files/**dub-0.9.18-linux-x86_64.tar.gzhttp://code.dlang.org/files/dub-0.9.18-linux-x86_64.tar.gz returns 500 - Internal Server Error. Internal error information: object.Exception@../../../opt/**vibe/source/vibe/inet/message.** d(352): Enforcement failed ./dub-registry(pure @safe bool std.exception.enforce!(bool).**enforce(bool, lazy const(char)[], immutable(char)[], ulong)+0x6b) [0x5e31ab] ./dub-registry(void vibe.inet.message.**InetHeaderMap.remove(**immutable(char)[])+0x182) [0x744dfa] ./dub-registry(void vibe.http.fileserver.sendFile(**vibe.http.server.**HTTPServerRequest, ... Try a different browser. I had this issue when using curl / wget, but it worked with Firefox. Failed with Firefox, Opera, and Chromium. Maybe it is something with my PC, will try again from another PC. Same problem with Opera/Chrome from my home PC (Windows 7). My previous attempts were from my Linux machine at the office where I tried Firefox/Opera/Chromium. I am the only one experiencing this? Craig I'm getting this also on a windows PC from a Chrome browser.
Re: [OT] My C++ talk at GoingNative 2013
On Friday, 13 September 2013 at 06:24:26 UTC, Jacob Carlborg wrote: On 2013-09-10 14:54, Olivier Grant wrote: First of all, I very much enjoyed the talk. It was as interesting as it was entertaining. Yes, I enjoyed it as well. I do have a question regarding the talk's section on devirtualization. As a language that imposes virtual methods for classes, how well does D play when it comes to devirtualization? And on a side note, does D have a different way of implementing virtual methods than most C++ compilers do? In D it seems that currently the preferred way to compile a project is to compile all the source at once using RDMD or similar. Isn't that a great opportunity for full program analysis to do devirtualization? No because export is ill defined. But it definitively should.
Re: [OT] My C++ talk at GoingNative 2013
On Wednesday, 11 September 2013 at 05:27:35 UTC, Olivier Pisano wrote: On Monday, 9 September 2013 at 16:43:54 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/1m1izv/goingnative_2013_writing_quick_code_in_c_quickly/ Andrei This talks are amazing. I learned a lot. Thank you all guys for your dedication and pedagogy. BTW, I really liked your face during the 'Ask us anything' panel, when STL talked about Garbage Collection! There is 2 ask us anything. Can you tell us which one and approximately when ?
Re: DUB 0.9.17/0.9.18 have been released + now on code.dlang.org
Sorry for that. It was introduced by my workaround for the GZIP issue. Works again now. I'll look into a proper fix today. Am 13.09.2013 08:41, schrieb Mathias Lang: Same here with chromium on a win7 64. 2013/9/13 growler growler...@gmail.com mailto:growler...@gmail.com On Friday, 13 September 2013 at 00:56:27 UTC, Craig Dillabaugh wrote: On Thursday, 12 September 2013 at 21:30:38 UTC, Craig Dillabaugh wrote: On Thursday, 12 September 2013 at 21:06:22 UTC, Kapps wrote: On Thursday, 12 September 2013 at 18:01:43 UTC, Craig Dillabaugh wrote: Currently any attempt to access the precompiled binaries, eg: http://code.dlang.org/files/__dub-0.9.18-linux-x86_64.tar.gz http://code.dlang.org/files/dub-0.9.18-linux-x86_64.tar.gz returns 500 - Internal Server Error. Internal error information: object.Exception@../../../opt/__vibe/source/vibe/inet/message.__d(352): Enforcement failed ./dub-registry(pure @safe bool std.exception.enforce!(bool).__enforce(bool, lazy const(char)[], immutable(char)[], ulong)+0x6b) [0x5e31ab] ./dub-registry(void vibe.inet.message.__InetHeaderMap.remove(__immutable(char)[])+0x182) [0x744dfa] ./dub-registry(void vibe.http.fileserver.sendFile(__vibe.http.server.__HTTPServerRequest, ... Try a different browser. I had this issue when using curl / wget, but it worked with Firefox. Failed with Firefox, Opera, and Chromium. Maybe it is something with my PC, will try again from another PC. Same problem with Opera/Chrome from my home PC (Windows 7). My previous attempts were from my Linux machine at the office where I tried Firefox/Opera/Chromium. I am the only one experiencing this? Craig I'm getting this also on a windows PC from a Chrome browser.
Re: [OT] My C++ talk at GoingNative 2013
I do have a question regarding the talk's section on devirtualization. As a language that imposes virtual methods for classes, how well does D play when it comes to devirtualization? And on a side note, does D have a different way of implementing virtual methods than most C++ compilers do? In D it seems that currently the preferred way to compile a project is to compile all the source at once using RDMD or similar. Isn't that a great opportunity for full program analysis to do devirtualization? It may be a trend, but I hope it will never become D's official approach, because it doesn't scale. This would left out all the people that use the object-file based approach (and related tools, like Makefiles), which is dominant in the Linux world, and is required in some cases (limited hardware, distributed compiling, or simply huge projects).
Re: Updates to D graph library
On Thursday, 12 September 2013 at 20:11:30 UTC, Joseph Rushton Wakeling wrote: Hello all, Today I pushed a number of major (and breaking) changes to the master repository of the D graph library. I've provided a brief summary on my blog, which also describes how to revise any programs to work with the new code: http://braingam.es/2013/09/d-graph-library-updates/ I hope that these changes don't unduly inconvenience anyone currently using the library. My own take was that it's worth it in terms of moving to a generic design and offering some new higher-performance graph data structures, which I'll be describing in more detail some time soon. Feedback on the new code is welcome. I would also like to offer thanks to all the nice people on D.learn who contributed useful ideas that helped with this update :-) Thanks best wishes, -- Joe Do you have any plans to change license from GPLv3 to something more liberal like Boost, MIT or BSD? Without this it's impossible to use your library for commercial purposes.
Re: Updates to D graph library
On Friday, 13 September 2013 at 07:49:49 UTC, ilya-stromberg wrote: Do you have any plans to change license from GPLv3 to something more liberal like Boost, MIT or BSD? Without this it's impossible to use your library for commercial purposes. The licence is GPLv3+ because the code is closely influenced by igraph, which is GPLv3-licensed. It's not like there's copy-pasting, but it's not clean-room either, so offering a permissive licence might put users in an invidious situation if the igraph authors chose to make an issue of it. Unlikely, but better safe than sorry. If anyone wants to use it in a commercial application the best thing probably to let me know and I can discuss with the igraph authors. I will probably do so anyway once the library is more feature-complete, less out of concern for commercial apps than in order not to be incompatible with other free licenses.
Re: Updates to D graph library
On Friday, 13 September 2013 at 08:20:38 UTC, Joseph Rushton Wakeling wrote: On Friday, 13 September 2013 at 07:49:49 UTC, ilya-stromberg wrote: Do you have any plans to change license from GPLv3 to something more liberal like Boost, MIT or BSD? Without this it's impossible to use your library for commercial purposes. The licence is GPLv3+ because the code is closely influenced by igraph, which is GPLv3-licensed. It's not like there's copy-pasting, but it's not clean-room either, so offering a permissive licence might put users in an invidious situation if the igraph authors chose to make an issue of it. Unlikely, but better safe than sorry. If anyone wants to use it in a commercial application the best thing probably to let me know and I can discuss with the igraph authors. I will probably do so anyway once the library is more feature-complete, less out of concern for commercial apps than in order not to be incompatible with other free licenses. I see. You can use Boost Graph Library (BGL) as a initial point. It's under Boost license that allows commercial usage. http://www.boost.org/doc/libs/1_54_0/libs/graph/doc/index.html Also, it would be nice to have graph library in Phobos in a future, and in that case module must be under Boost license. But yes, you can try to contact igraph authors - maybe they let you change the license.
Re: Updates to D graph library
On Friday, 13 September 2013 at 08:45:45 UTC, ilya-stromberg wrote: I see. You can use Boost Graph Library (BGL) as a initial point. It's under Boost license that allows commercial usage. http://www.boost.org/doc/libs/1_54_0/libs/graph/doc/index.html I'm aware of the BGL, but I didn't find it a very nice design. I was also influenced by the fact that among colleagues who work with the various graph libraries, none of them seem to favour it -- whereas igraph seems both popular and high-performing (I believe it can scale to larger data size than any other solution out there). But of course I may revisit that in future. Also, it would be nice to have graph library in Phobos in a future, and in that case module must be under Boost license. Understood, although I never particularly saw Dgraph as being a Phobos candidate, it feels a bit too specialized. My impression is that graph libraries tend in practice to sprawl out into massive constructions, rather too extended for something like a standard library. But if the core functionality is something people are interested in for Phobos, then again, I'm happy to open up the licensing discussion. I'm sure that the igraph authors would be supportive.
Re: DUB 0.9.17/0.9.18 have been released + now on code.dlang.org
On Friday, 13 September 2013 at 07:30:36 UTC, Sönke Ludwig wrote: Sorry for that. It was introduced by my workaround for the GZIP issue. Works again now. I'll look into a proper fix today. Am 13.09.2013 08:41, schrieb Mathias Lang: Same here with chromium on a win7 64. 2013/9/13 growler growler...@gmail.com mailto:growler...@gmail.com On Friday, 13 September 2013 at 00:56:27 UTC, Craig Dillabaugh wrote: On Thursday, 12 September 2013 at 21:30:38 UTC, Craig Dillabaugh wrote: On Thursday, 12 September 2013 at 21:06:22 UTC, Kapps wrote: On Thursday, 12 September 2013 at 18:01:43 UTC, Craig Dillabaugh wrote: Currently any attempt to access the precompiled binaries, eg: http://code.dlang.org/files/__dub-0.9.18-linux-x86_64.tar.gz http://code.dlang.org/files/dub-0.9.18-linux-x86_64.tar.gz returns 500 - Internal Server Error. Internal error information: object.Exception@../../../opt/__vibe/source/vibe/inet/message.__d(352): Enforcement failed ./dub-registry(pure @safe bool std.exception.enforce!(bool).__enforce(bool, lazy const(char)[], immutable(char)[], ulong)+0x6b) [0x5e31ab] ./dub-registry(void vibe.inet.message.__InetHeaderMap.remove(__immutable(char)[])+0x182) [0x744dfa] ./dub-registry(void vibe.http.fileserver.sendFile(__vibe.http.server.__HTTPServerRequest, ... Try a different browser. I had this issue when using curl / wget, but it worked with Firefox. Failed with Firefox, Opera, and Chromium. Maybe it is something with my PC, will try again from another PC. Same problem with Opera/Chrome from my home PC (Windows 7). My previous attempts were from my Linux machine at the office where I tried Firefox/Opera/Chromium. I am the only one experiencing this? Craig I'm getting this also on a windows PC from a Chrome browser. Thanks. Works for me now.
Re: VisualD now on github.com/d-programming-language
On 9/13/13, Rainer Schuetze r.sagita...@gmx.de wrote: I have converted the documentation to DDoc. Here's the result: http://rainers.github.io/visuald/visuald/StartPage.html I'm not sure if I mentioned this before, but I have to comment on the following section: ``` Library search path not passed to linker Even though Visual D allows to set a library search path, this does not work with the default installation of DMD. Optlink, the linker used by DMD, only accepts the path in the LIB environment variable.. ``` Doesn't the -L+ switch work for you? I've documented it here: http://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows#Passing_search_directories_for_static_library_files_to_Optlink
Re: VisualD now on github.com/d-programming-language
On 9/13/13, Rainer Schuetze r.sagita...@gmx.de wrote: I have converted the documentation to DDoc. Here's the result: http://rainers.github.io/visuald/visuald/StartPage.html Looks sweet! Btw, I suggest making that picture in the lower-right clickable so you can zoom in to get the full resolution picture.
Re: VisualD now on github.com/d-programming-language
On 9/13/2013 1:01 PM, Rainer Schuetze wrote: I have converted the documentation to DDoc. Here's the result: http://rainers.github.io/visuald/visuald/StartPage.html Very nice!
Re: VisualD now on github.com/d-programming-language
On 13.09.2013 22:31, Andrej Mitrovic wrote: On 9/13/13, Rainer Schuetze r.sagita...@gmx.de wrote: I have converted the documentation to DDoc. Here's the result: http://rainers.github.io/visuald/visuald/StartPage.html I'm not sure if I mentioned this before, but I have to comment on the following section: ``` Library search path not passed to linker Even though Visual D allows to set a library search path, this does not work with the default installation of DMD. Optlink, the linker used by DMD, only accepts the path in the LIB environment variable.. ``` Doesn't the -L+ switch work for you? I've documented it here: http://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows#Passing_search_directories_for_static_library_files_to_Optlink -L+libpath\ does not work if you also want to pass resource or def file. -L always appends the arguments to the end of the command line, but the library paths must be added before the ',' that separates libraries and resource file. Actually, that paragraph is out of date, because Visual D can now call optlink separately and will do this if you have specified additional library paths.
Re: extern(C) declaration inside function
On Friday, 13 September 2013 at 02:46:22 UTC, Luís Marques wrote: On Tuesday, 10 September 2013 at 13:41:14 UTC, Luís Marques wrote: Is this a bug? *bump* This is invalid in C, so not manglable. when you use extern C in this context, you mean calling convention.
Format of .stringof, defined or not defined?
I just hit a problem in my serialization library, Orange, being
integrated as std.serialization. The format of .stringof changed in git
HEAD. Now, the question is should the format of .stringof be defined and
reliable or not defined at all? Either way, this should be clearly
stated in the documentation, which it's currently not.
Below is what's changed. It's managed to stay unchanged for the last 6-7
years.
Before the change:
struct Foo
{
int a;
}
static assert(Foo.tupleof[0].stringof == (Foo).a);
After the change:
static assert(Foo.tupleof[0].stringof == a);
--
/Jacob Carlborg
Re: Format of .stringof, defined or not defined?
On Friday, 13 September 2013 at 07:06:27 UTC, Jacob Carlborg
wrote:
I just hit a problem in my serialization library, Orange, being
integrated as std.serialization. The format of .stringof
changed in git HEAD. Now, the question is should the format of
.stringof be defined and reliable or not defined at all? Either
way, this should be clearly stated in the documentation, which
it's currently not.
Below is what's changed. It's managed to stay unchanged for the
last 6-7 years.
Before the change:
struct Foo
{
int a;
}
static assert(Foo.tupleof[0].stringof == (Foo).a);
After the change:
static assert(Foo.tupleof[0].stringof == a);
Funny. I just ran into that with msgpack-d in my project... So
that's two libraries broken.
Re: Format of .stringof, defined or not defined?
On 2013-09-13 09:11, Brian Schott wrote: Funny. I just ran into that with msgpack-d in my project... So that's two libraries broken. I guess __traits(identifier, Foo.tupleof[0]) is more reliable than .strinfof. But it would be nice to once and for all get an official agreement on this issue. -- /Jacob Carlborg
Re: dub: should we make it the de jure package manager for D?
On Thursday, 12 September 2013 at 20:18:35 UTC, Jonathan M Davis wrote: On Thursday, September 12, 2013 22:02:15 w0rp wrote: On the subject of YAML. I've tried it out a few times. The syntax for JSON can be described in 1-2 pages, on json.org's front page. The syntax for YAML requires a 50-100 page document to describe. That should be enough to tell you not to use it. While, I agree in principle, I would point out that what's on json.org is oversimplified and is not a valid spec. You really need to read the RFC if you want to get it right, and that has about 9 pages of actual content: http://www.ietf.org/rfc/rfc4627.txt?number=4627 So, you're comparing a basic explanation of JSON to a full-on spec for YAML. Now, the YAML 1.2 spec does have about 77 pages of actual content: http://yaml.org/spec/1.2/spec.pdf So, you're not completely off base in your comparison (YAML _is_ way more complicated), but to properly specify JSON requires a lot more pages than your post indicates. - Jonathan M Davis That's a much more fair comparison. Thanks.
Re: Move VisualD to github/d-programming-language ?
On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright wrote: Recent threads here have made it pretty clear that VisualD is a critical piece of D infrastructure. (VisualD integrated D usage into Microsoft Visual Studio.) Allow me to support this idea, however to suggest that also add a cross-platform IDE/plug-in. This is important for the Linux world. Current choices are DDT, for Eclipse and Mono-D, for MonoDevelop. I would vote for the two for the time being and see how things develop. Official endorsement should increase their visibility, their use and, why not, patches. In the future, they could also be integrated in the installer. I would also suggest to move DDT on github (Mono-D is already there). All these, of course, only if respective authors agree. I kindly ask them to provide their POV. BTW, kudos to Alexander Bothe and Bruno Medeiros. For the record, I am a heavy user of Eclipse/CDT on Linux, and my colleagues are almost all users of the same, albeit some of them on Windows. I could testify for the popularity of IDEs in some environments, particularly for Eclipse CDT (although I would prefer to have Eclipse and CDT written in D or C/C++, not in Java, but this is life...).
Re: Format of .stringof, defined or not defined?
On Friday, 13 September 2013 at 07:06:27 UTC, Jacob Carlborg
wrote:
I just hit a problem in my serialization library, Orange, being
integrated as std.serialization. The format of .stringof
changed in git HEAD. Now, the question is should the format of
.stringof be defined and reliable or not defined at all? Either
way, this should be clearly stated in the documentation, which
it's currently not.
Below is what's changed. It's managed to stay unchanged for the
last 6-7 years.
Before the change:
struct Foo
{
int a;
}
static assert(Foo.tupleof[0].stringof == (Foo).a);
After the change:
static assert(Foo.tupleof[0].stringof == a);
Aye, I had my own code break from this change as well (though it
was a very easy fix in my case). I really prefer the new format
however. Including the type made reading people's code very
confusing with the random T.tupleof[T.stringof + 3 .. $] if you
didn't understand the exact format. That being said, this is
something that's commonly enough used that it should be defined
whether or not the format could be relied upon.
SDL vs. YAML
Am 11.09.2013 18:14, schrieb Brad Anderson: On Wednesday, 11 September 2013 at 14:11:11 UTC, John Colvin wrote: Why not YAML? It's cleaner than JSON and is very widely known. YAML is nice but can be surprisingly tricky to write by hand sometimes (especially for people not used to significant whitespace). Here's the discussion about JSON vs. YAML vs. SDL on the dub forum: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/ I have to admit that looking at the examples *now* leaves me with a strong distaste for YAML. That wasn't the case in the beginning, but now, after not having looked at any YAML document since then and even with only the simplest syntax constructs used, it just looks confusing to me. Some points that stand out: - Built-in field names and user defined dictionary key (can) look the same and can be quite confusing (my initial reaction to the sub-package: line in the example was Hmm.. what kind of command is *that*?) - Indentation based scoping is much less explicit than braces. Someone who has never seen the format may well think that it's just visual formatting and has to read up on it first. - It still has the deep nesting of the JSON format - The complexity of the specification is a bit of a turn-off, too Having said that, YAML for sure is a nice format for many things and considerably more powerful in some areas than f.ex. SDL, but here I think the focus should be on the most concise and intuitive textual representation and IMO SDL does a better job there. More advanced features of YAML, if needed, can also easily be simulated with SDL.
Re: Not with the scene…
On Wed, 2013-09-11 at 14:56 +0200, Sönke Ludwig wrote: […] Regarding the dub music genre, it has to be said that although it is the root for dubstep and in turn ... brostep, it's usually not really comparable result-wise and I have a strong desire to avoid putting the word step somewhere in proximity of DUB ;) Perhaps this is the last word on the dubstep issue :-) http://www.mazbox.com/synths/dubstep/ -- 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 signature.asc Description: This is a digitally signed message part
Re: Thread-Multiplexing for D
Am 12.09.2013 19:55, schrieb Sean Kelly: On Sep 12, 2013, at 8:34 AM, Bienlein jeti...@web.de wrote: About thread-multiplexing... You find a lot in Google when searching for socket multplexing, but not when searching for thread-multiplexing. Maybe I coined the term myself (don't know any more) when reading the section here: http://golang.org/doc/effective_go.html#goroutines Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management. The trick in D is that because statics are thread-local by default, any multiplexed app like this that expects its static data to remain consistent across calls is likely to fail. I've mentioned fiber-local storage here in the past, but it's a tricky problem. But I think it's one that we will need to sort out for things like this to work as the user expects them to. Until we have something built-in, I've implemented a template based solution for task local storage (same as fiber local storage, but the lifetime is different as fibers get recycled for consecutive tasks): http://vibed.org/api/vibe.core.core/TaskLocal
Re: dub: should we make it the de jure package manager for D?
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote: We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project. We're considering making dub the official package manager for D. What do you all think? Several remarks (I'm a dub newbie, so it is mostly conditional stuff) : - Can we manage repositories ? For instance can I use my company repo instead of code.dlang.org ? Can I use several repositories with some kind of priorisation ? - How does the tool handle several version of a package ? - What is the process to get some code on code.dlang.org ? We must settle something if this have to go official. - What is the dependance management strategy used ? How does it resolve conflicts ?
druntime, templates and traits
One of the issues of druntime is that is that almost everything in it is resolved at runtime. This is good because it avoids bloat. However, it also means we run into 2 regular issues: 1. Performance (small issue). A lot of code that should be otherwise fast is slower than it could be, since druntime will check, at runtime, if postblit is needed, if destruction should be done. For example, if you dup a string by hand, you can do it 50% faster than what druntime does. 2. Inference. This is an odd one. Currently, the function that operate on arrays (reserve, dup, length) etc... may or may not be @safe or pure. Or nothrow. The problem is that we really can't do anything about it. duping a string is obviously nothrow, but if you dup something with a postblit, then it might not be (nor safe). These issues kind of keep popping up in phobos, and we will have to address them sooner or later. The current state of affairs is a kind of status quo of its wrong, inconsistent, but maybe OK most of the time. For example, dup is not nothrow, yet it is safe and pure. Reserve is nothrow, yet assumeSafeAppend is not. Reserve may actually call postblit, but not assumeSafeAppend. The solution (I think) would be to partially templatize d-runtime. We can keep most of what is in rt/lifetime.d, but statically split it into smaller chunks, which could be piloted with more accuracy via a templated manager. For now, if we could make a change as simple as no postblit = safe pure nothrow, and fast guaranteed/postblit = not safe, not pure, may throw, then it would already be a big win (IMO). I had started toying around with this, and the main and immediate challenge I ran into is the integration of templates. The 2 issues are: 1. All templates must be in object.d, or the compiler won't see it. 2. A simple (and needed) trait like hasElaborateCopyConstructor requires a good third of both typetuple.d and traits.d. functionAttributes is pretty simple though (I think). So the two challenges are: 1. If we integrate a large amount of template code, where would it go? 2. How will we deal with not having massive code duplication? I'm mostly looking to start a discussion on this, and for guidance, ideas, on where to start.
Re: Thread-Multiplexing for D
13-Sep-2013 13:57, Sönke Ludwig пишет: Am 12.09.2013 19:55, schrieb Sean Kelly: On Sep 12, 2013, at 8:34 AM, Bienlein jeti...@web.de wrote: About thread-multiplexing... You find a lot in Google when searching for socket multplexing, but not when searching for thread-multiplexing. Maybe I coined the term myself (don't know any more) when reading the section here: http://golang.org/doc/effective_go.html#goroutines Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management. The trick in D is that because statics are thread-local by default, any multiplexed app like this that expects its static data to remain consistent across calls is likely to fail. I've mentioned fiber-local storage here in the past, but it's a tricky problem. But I think it's one that we will need to sort out for things like this to work as the user expects them to. Until we have something built-in, I've implemented a template based solution for task local storage (same as fiber local storage, but the lifetime is different as fibers get recycled for consecutive tasks): http://vibed.org/api/vibe.core.core/TaskLocal I do hope O(n) is a typo and it should be O(1). Anyhow what n stands here for? -- Dmitry Olshansky
Re: druntime, templates and traits
monarch_dodra: So the two challenges are: 1. If we integrate a large amount of template code, where would it go? How much large it is? 2. How will we deal with not having massive code duplication? Go developers accept a little amount of duplication. But in your case a solution could be just to deprecate and later remove the Phobos code that you put in object.d. Bye, bearophile
Re: Thread-Multiplexing for D
Am 12.09.2013 16:57, schrieb Bienlein: Ah! Cool :-). They are saying that they are using libevent, see http://vibed.org/features#performance. I see... Although only shitty software comes from my country such as SAP, this is a company that seems to develop some cool stuff. So I hope that D will also pop up in job ads over here some day ;-). -- Bienlein I too hope that this will happen one day, but I fear that the company is still in its infancy :) * BTW there is at least one company (sociomantic) in Germany with an office in Berlin that uses D. * disclaimer: I might be affiliated with vibe.d and that company ;)
Re: Thread-Multiplexing for D
Am 13.09.2013 12:57, schrieb Dmitry Olshansky: 13-Sep-2013 13:57, Sönke Ludwig пишет: Am 12.09.2013 19:55, schrieb Sean Kelly: On Sep 12, 2013, at 8:34 AM, Bienlein jeti...@web.de wrote: About thread-multiplexing... You find a lot in Google when searching for socket multplexing, but not when searching for thread-multiplexing. Maybe I coined the term myself (don't know any more) when reading the section here: http://golang.org/doc/effective_go.html#goroutines Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management. The trick in D is that because statics are thread-local by default, any multiplexed app like this that expects its static data to remain consistent across calls is likely to fail. I've mentioned fiber-local storage here in the past, but it's a tricky problem. But I think it's one that we will need to sort out for things like this to work as the user expects them to. Until we have something built-in, I've implemented a template based solution for task local storage (same as fiber local storage, but the lifetime is different as fibers get recycled for consecutive tasks): http://vibed.org/api/vibe.core.core/TaskLocal I do hope O(n) is a typo and it should be O(1). Anyhow what n stands here for? Indeed, stupid typo.
Re: Thread-Multiplexing for D
On Friday, 13 September 2013 at 11:06:35 UTC, Sönke Ludwig wrote: BTW there is at least one company (sociomantic) in Germany with an office in Berlin that uses D. And they are hiring ;)
Re: Thread-Multiplexing for D
Am 13.09.2013 12:57, schrieb Dmitry Olshansky: 13-Sep-2013 13:57, Sönke Ludwig пишет: Am 12.09.2013 19:55, schrieb Sean Kelly: On Sep 12, 2013, at 8:34 AM, Bienlein jeti...@web.de wrote: About thread-multiplexing... You find a lot in Google when searching for socket multplexing, but not when searching for thread-multiplexing. Maybe I coined the term myself (don't know any more) when reading the section here: http://golang.org/doc/effective_go.html#goroutines Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management. The trick in D is that because statics are thread-local by default, any multiplexed app like this that expects its static data to remain consistent across calls is likely to fail. I've mentioned fiber-local storage here in the past, but it's a tricky problem. But I think it's one that we will need to sort out for things like this to work as the user expects them to. Until we have something built-in, I've implemented a template based solution for task local storage (same as fiber local storage, but the lifetime is different as fibers get recycled for consecutive tasks): http://vibed.org/api/vibe.core.core/TaskLocal I do hope O(n) is a typo and it should be O(1). Anyhow what n stands here for? n would be the number of variables declared. There is a linear initialization cost and in the naive predecessor implementation, an AA with Variants was used to store the values, which is why I've mentioned efficiency at all.
D Ranges
A short report on component programming and ranges.
A lot of my code deals with transforming and reformatting input,
e.g. text is split into sentences and words for grammatical
parsing (part of speech) and phonetic transcriptions. I'm using D
ranges and component programming and I'm quite happy with
one-liners like
foreach
(bySentence().byWord().byWhateverFormat().byReformatAgain()) {
// Whatever
}
The code is much easier to maintain, neater and more efficient
within each component.
Sometimes, however, I wonder how I should design my ranges. It is
hard to decide whether to use them as pure pipes or semi-output
ranges. Semi because they're not sinks as defined by put() but
still they can hold data (an array of reformatted strings for
example) that could be accessed by using Range.data. I'm not sure
as regards best practice and whether or not I'm wasting
resources by storing data internally. On the other hand, it might
be handy to have access to the data stored internally. Does
anyone have a rough guide to D ranges? Like Case 1: Use XYZ, Case
2: Use ZYX etc.
(I've read this tutorial http://ddili.org/ders/d.en/ranges.html,
and I'd like to thank Ali for that! It helped me a lot.)
Another issue I've come across is how to integrate CP and ranges
into an OO framework. I figure that ranges are good work horses,
but it makes sense to keep the overall logic in an OO fashion. Or
could it be that D's structs and ranges will replace OOP as we no
it (a class-free system).
Re: dub: should we make it the de jure package manager for D?
Am 13.09.2013 12:00, schrieb deadalnix: On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote: We've been experimenting with http://code.dlang.org for a while and things are going well. In particular Sönke has been very active about maintaining and improving it, which brings further confidence in the future of the project. We're considering making dub the official package manager for D. What do you all think? Several remarks (I'm a dub newbie, so it is mostly conditional stuff) : - Can we manage repositories ? For instance can I use my company repo instead of code.dlang.org ? Can I use several repositories with some kind of priorisation ? It supports specifying a list of registries that is searched linearly for packages in its config file (or as a command line argument) - I think I still need to document that, though. The registry currently supports only GitHub and Bitbucket repositories to source packages from, but that can be easily extended by implementing the Repository interface. - How does the tool handle several version of a package ? In the current registry implementation, git tags of the form vX.Y.Z[postfix] are taken as the available versions. When specifying dependencies it's then possible to use relational operators to specify a range of acceptable versions, of which the newest is used. Things like the version pinning mechanism proposed by Jacob can still improve things in this area. - What is the process to get some code on code.dlang.org ? We must settle something if this have to go official. My idea (the status quo) is to keep that as open as possible. Anyone can register an account and register his/her repository. Package names are reserved on a first-come-first-serve basis. This process would then be augmented with community votes, automatic package deprecation and sporadic moderation to keep everything clean in the long term. - What is the dependance management strategy used ? How does it resolve conflicts ? There are basically three areas where things can conflict AFAICS: - Accepted version ranges for packages that are referenced by multiple other packages: Here the best version that satisfies all given ranges is used if possible, otherwise error out - Selected configuration for a package: This is resolved to the first possible set of configurations if possible, otherwise error out (this is a bit more complex due to the platform playing a role in configuration selection) - Conflicts in code (i.e. module/package name clashes) - This is currently not handled, but there have been discussions about that topic: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1/
Re: dub: should we make it the de jure package manager for D?
On Friday, 13 September 2013 at 11:55:42 UTC, Sönke Ludwig wrote: - What is the process to get some code on code.dlang.org ? We must settle something if this have to go official. My idea (the status quo) is to keep that as open as possible. Anyone can register an account and register his/her repository. Package names are reserved on a first-come-first-serve basis. This process would then be augmented with community votes, automatic package deprecation and sporadic moderation to keep everything clean in the long term. I think AUR (Arch Linux Repository) model is very successful one and worth paying attention to when it comes to source packages. Other than voting it also has `out-of-date` flagging by users which helps to noticed abandoned packages fast. There is also small group of trusted users who processes requests for package ownership transfer / package merging via mail list. Any suspicious / malicious package get processed in a similar way. Other than that it is very anarchic environment and still works damn well - AUR package count is now more than 40 000 and Arch Linux is pretty young distro.
Re: Move VisualD to github/d-programming-language ?
On 2013-09-13 09:46, eles wrote: For the record, I am a heavy user of Eclipse/CDT on Linux, and my colleagues are almost all users of the same, albeit some of them on Windows. I could testify for the popularity of IDEs in some environments, particularly for Eclipse CDT (although I would prefer to have Eclipse and CDT written in D or C/C++, not in Java, but this is life...). SWT, the widget toolkit used by Eclipse, is already ported to D (DWT). In addition to that several other Eclipse related projects are ported to D, although not up to date. https://github.com/d-widget-toolkit/dwt There's an old abandon IDE project, called Poseidon, which uses a really old version of DWT. It looks quite similar to Eclipse: http://dsource.org/projects/poseidon http://dsource.org/projects/poseidon/wiki/Screenshots -- /Jacob Carlborg
Re: druntime, templates and traits
On 2013-09-13 12:26, monarch_dodra wrote: I had started toying around with this, and the main and immediate challenge I ran into is the integration of templates. The 2 issues are: 1. All templates must be in object.d, or the compiler won't see it. Do you know why that is? Can they be put in a separate module but imported by object.d? 2. A simple (and needed) trait like hasElaborateCopyConstructor requires a good third of both typetuple.d and traits.d. functionAttributes is pretty simple though (I think). Can't we move some of the traits to druntime? std.traits would publicly import the ones which were moved. So the two challenges are: 1. If we integrate a large amount of template code, where would it go? It depends on where it needs to be used. Some suggestions: * core.traits|typetuple * rt.util.traits|typetuple 2. How will we deal with not having massive code duplication? Move to druntime? Phobos already depends on it. -- /Jacob Carlborg
Re: Move VisualD to github/d-programming-language ?
On Friday, 13 September 2013 at 12:24:06 UTC, Jacob Carlborg wrote: On 2013-09-13 09:46, eles wrote: SWT, the widget toolkit used by Eclipse, is already ported to D (DWT). In addition to that several other Eclipse related projects are ported to D, although not up to date. https://github.com/d-widget-toolkit/dwt There's an old abandon IDE project, called Poseidon, which uses a really old version of DWT. It looks quite similar to Eclipse: http://dsource.org/projects/poseidon http://dsource.org/projects/poseidon/wiki/Screenshots Thank you, but for the time being we're not there. However, the goal is not to rewrite Eclipse in D, but having DDT and Mono-D endorsed officially, to provide a Linux alternative to the VisualD.
Re: SDL vs. YAML
On 2013-09-13 10:22, Sönke Ludwig wrote:
I have to admit that looking at the examples *now* leaves me with a
strong distaste for YAML. That wasn't the case in the beginning, but
now, after not having looked at any YAML document since then and even
with only the simplest syntax constructs used, it just looks confusing
to me.
Some points that stand out:
- Built-in field names and user defined dictionary key (can) look the
same and can be quite confusing (my initial reaction to the
sub-package: line in the example was Hmm.. what kind of command
is *that*?)
- Indentation based scoping is much less explicit than braces. Someone
who has never seen the format may well think that it's just visual
formatting and has to read up on it first.
- It still has the deep nesting of the JSON format
- The complexity of the specification is a bit of a turn-off, too
Having said that, YAML for sure is a nice format for many things and
considerably more powerful in some areas than f.ex. SDL, but here I
think the focus should be on the most concise and intuitive textual
representation and IMO SDL does a better job there. More advanced
features of YAML, if needed, can also easily be simulated with SDL.
Here's a lightly modified version of the YAML example:
name: my-package
description: A package for demonstration purposes
dependencies:
vibe-d: =0.7.13
sub-package: { version: ~master}
configurations:
# command line version
- name: console
targetType: executable
versions: ConsoleApp
# Win32 based GUI version
- name: gui
targetType: executable
versions: UseWinMain
libs-windows: [gdi32, user32]
I have used the inline format for sub-package and libs-windows. I'm
also assuming it's possible to use a single value instead of an array
for versions.
Don't know about SDL, but YAML allow you to have references, like this:
configurations:
# command line version
- name: console console
targetType: executable
versions: ConsoleApp
libs-windows: [gdi32, user32]
# Win32 based GUI version
- name: gui
: *console
versions: UseWinMain
--
/Jacob Carlborg
Re: druntime, templates and traits
On Friday, 13 September 2013 at 10:26:35 UTC, monarch_dodra wrote: 1. Performance (small issue). A lot of code that should be otherwise fast is slower than it could be, since druntime will check, at runtime, if postblit is needed, if destruction should be done. For example, if you dup a string by hand, you can do it 50% faster than what druntime does. Yes, this is pitfall of D design. 2. Inference. This is an odd one. Currently, the function that operate on arrays (reserve, dup, length) etc... may or may not be @safe or pure. Or nothrow. The problem is that we really can't do anything about it. duping a string is obviously nothrow, but if you dup something with a postblit, then it might not be (nor safe). Yes, this is pitfall of D design. These issues kind of keep popping up in phobos, and we will have to address them sooner or later. The current state of affairs is a kind of status quo of its wrong, inconsistent, but maybe OK most of the time. They are systematically popping up because of systematical language features (D is statically typed language with little runtime supported). For example, dup is not nothrow, yet it is safe and pure. Reserve is nothrow, yet assumeSafeAppend is not. Reserve may actually call postblit, but not assumeSafeAppend. The solution (I think) would be to partially templatize d-runtime. We can keep most of what is in rt/lifetime.d, but statically split it into smaller chunks, which could be piloted with more accuracy via a templated manager. It depends on how do you want to templatize it. Due to separate compilation model it is impossible to know beforehand (when you provide phobos library together with druntime) which types will be used. For now, if we could make a change as simple as no postblit = safe pure nothrow, and fast guaranteed/postblit = not safe, not pure, may throw, then it would already be a big win (IMO). I had started toying around with this, and the main and immediate challenge I ran into is the integration of templates. The 2 issues are: 1. All templates must be in object.d, or the compiler won't see it. 2. A simple (and needed) trait like hasElaborateCopyConstructor requires a good third of both typetuple.d and traits.d. functionAttributes is pretty simple though (I think). Yes, this is pitfall of D design. I'm mostly looking to start a discussion on this, and for guidance, ideas, on where to start. I doubt that the problems you raised are solvable in general case with current runtime capabilities. While it still may be possible to tackle some of them, D design (separate compilation model, type system, templates, how pure, @safe, nothrow are defined) would prevent you from fixing these problems.
Re: D Ranges
Chris:
A short report on component programming and ranges.
A lot of my code deals with transforming and reformatting
input, e.g. text is split into sentences and words for
grammatical parsing (part of speech) and phonetic
transcriptions. I'm using D ranges and component programming
and I'm quite happy with one-liners like
foreach
(bySentence().byWord().byWhateverFormat().byReformatAgain()) {
// Whatever
}
In most cases today you are free to omit those ():
foreach (bySentence.byWord.byWhateverFormat.byReformatAgain) {
Bye,
bearophile
Re: D Ranges
On Friday, 13 September 2013 at 13:31:18 UTC, bearophile wrote:
In most cases today you are free to omit those ():
foreach (bySentence.byWord.byWhateverFormat.byReformatAgain) {
Bye,
bearophile
...but you shouldn't if you care about readability (leave at
least the last pair in the line) :P
Re: extern(C) declaration inside function
On 9/10/13, l...@luismarques.eu@puremagic.com \Luís.Marques wrote:
When you declare an extern(C) function inside a D function it
seems to continue to use D's name mangling, which is unexpected
for me. For instance:
void main()
{
extern(C) void foo(int);
foo(42);
}
I was going to suggest using pragma(mangle, ...) as a workaround
(using a git-head compiler), but actually it won't work here because
this pragma can only be used in module-scope. Apparently there's a
difference between a pragma declaration and pragma statement, I'm not
sure why we have this split.
Re: D Ranges
On Friday, 13 September 2013 at 13:42:07 UTC, Dicebot wrote:
On Friday, 13 September 2013 at 13:31:18 UTC, bearophile wrote:
In most cases today you are free to omit those ():
foreach (bySentence.byWord.byWhateverFormat.byReformatAgain) {
Bye,
bearophile
...but you shouldn't if you care about readability (leave at
least the last pair in the line) :P
It also helps other people (and me) to realize that it actually
_does_ something and doesn't just return a value. Often (not
always of course), if you omit the brackets it returns a value
without doing anything. But that's just a personal convention I
might abandon further down the road.
Re: D Ranges
On Friday, 13 September 2013 at 13:42:07 UTC, Dicebot wrote:
On Friday, 13 September 2013 at 13:31:18 UTC, bearophile wrote:
In most cases today you are free to omit those ():
foreach (bySentence.byWord.byWhateverFormat.byReformatAgain) {
Bye,
bearophile
...but you shouldn't if you care about readability (leave at
least the last pair in the line) :P
That is my gideline as well. Keep at least the last one.
Re: SDL vs. YAML
On 9/13/13, Sönke Ludwig slud...@outerproduct.org wrote: Here's the discussion about JSON vs. YAML vs. SDL on the dub forum: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/ Can we specify values on multiple lines? E.g. this line: libs-windows gdi32 user32 To somehow use multi-line instead: libs-windows gdi32 user32 Even if we have to use the slash key for continuation (like in some languages) it would be useful to have, since it's then easy to quickly comment out a value by commenting out the entire line (well I have a key shortcut to quickly comment/uncomment a line, I'd like to be able to use it.).
Re: Top Github Languages for 2013 (so far)
On Friday, 6 September 2013 at 15:28:53 UTC, sclytrack wrote: On Tuesday, 3 September 2013 at 13:13:11 UTC, Elvis wrote: http://adambard.com/blog/top-github-languages-for-2013-so-far/ Well D is now a bit higher on tiobe, position 22 (August 2013). It has been, for a very long time, on position 36. Is there any push of getting vibed and gtkd in ubuntu before the LTS release? Well D is now position 39 (September 2013)!
Re: Top Github Languages for 2013 (so far)
On Friday, 13 September 2013 at 15:38:16 UTC, Zhouxuan wrote: On Friday, 6 September 2013 at 15:28:53 UTC, sclytrack wrote: On Tuesday, 3 September 2013 at 13:13:11 UTC, Elvis wrote: http://adambard.com/blog/top-github-languages-for-2013-so-far/ Well D is now a bit higher on tiobe, position 22 (August 2013). It has been, for a very long time, on position 36. Is there any push of getting vibed and gtkd in ubuntu before the LTS release? Well D is now position 39 (September 2013)! http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Re: SDL vs. YAML
Am 13.09.2013 17:03, schrieb Andrej Mitrovic: On 9/13/13, Sönke Ludwig slud...@outerproduct.org wrote: Here's the discussion about JSON vs. YAML vs. SDL on the dub forum: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/ Can we specify values on multiple lines? E.g. this line: libs-windows gdi32 user32 To somehow use multi-line instead: libs-windows gdi32 user32 Even if we have to use the slash key for continuation (like in some languages) it would be useful to have, since it's then easy to quickly comment out a value by commenting out the entire line (well I have a key shortcut to quickly comment/uncomment a line, I'd like to be able to use it.). Both of these should work: libs-windows \ gdi32 \ user32 libs-windows gdi32 libs-windows user32
Re: druntime, templates and traits
On Sep 13, 2013, at 5:35 AM, Jacob Carlborg d...@me.com wrote: On 2013-09-13 12:26, monarch_dodra wrote: I had started toying around with this, and the main and immediate challenge I ran into is the integration of templates. The 2 issues are: 1. All templates must be in object.d, or the compiler won't see it. Do you know why that is? Can they be put in a separate module but imported by object.d? Yes.
Re: SDL vs. YAML
Am 13.09.2013 14:48, schrieb Jacob Carlborg:
Here's a lightly modified version of the YAML example:
name: my-package
description: A package for demonstration purposes
dependencies:
vibe-d: =0.7.13
sub-package: { version: ~master}
configurations:
# command line version
- name: console
targetType: executable
versions: ConsoleApp
# Win32 based GUI version
- name: gui
targetType: executable
versions: UseWinMain
libs-windows: [gdi32, user32]
I have used the inline format for sub-package and libs-windows. I'm
also assuming it's possible to use a single value instead of an array
for versions.
That does indeed improve it. But I still think that the multitude of
formatting options can be confusing and it takes more artistic skills to
get a nice result than with a single clean way to format.
Don't know about SDL, but YAML allow you to have references, like this:
configurations:
# command line version
- name: console console
targetType: executable
versions: ConsoleApp
libs-windows: [gdi32, user32]
# Win32 based GUI version
- name: gui
: *console
versions: UseWinMain
That's where IMO it gets hairy. It's for sure a highly useful feature,
but also completely impossible to understand without consulting the
documentation. SDL doesn't have direct support, but it would be possible
build some kind of custom functionality if it proves useful.
Something like:
def somevar=somevalue
libs $somevar
or
template sometemplate {
libs gdi32 user32
}
configuration gui {
mixin sometemplate
}
Re: Not with the scene…
On Sep 13, 2013 9:53 AM, Russel Winder rus...@winder.org.uk wrote: On Wed, 2013-09-11 at 14:56 +0200, Sönke Ludwig wrote: […] Regarding the dub music genre, it has to be said that although it is the root for dubstep and in turn ... brostep, it's usually not really comparable result-wise and I have a strong desire to avoid putting the word step somewhere in proximity of DUB ;) Perhaps this is the last word on the dubstep issue :-) http://www.mazbox.com/synths/dubstep/ Someone should port to D. In fact that's one thing I'd definitely would like to start a case for - using D in audio processing (eg: effects, synths :-) Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: SDL vs. YAML
On 9/13/13, Sönke Ludwig slud...@outerproduct.org wrote: Both of these should work: libs-windows \ gdi32 \ user32 libs-windows gdi32 libs-windows user32 Great!
Re: druntime, templates and traits
On Fri, Sep 13, 2013 at 03:20:10PM +0200, Maxim Fomin wrote:
On Friday, 13 September 2013 at 10:26:35 UTC, monarch_dodra wrote:
1. Performance (small issue). A lot of code that should be
otherwise fast is slower than it could be, since druntime will
check, at runtime, if postblit is needed, if destruction should be
done. For example, if you dup a string by hand, you can do it
50% faster than what druntime does.
Yes, this is pitfall of D design.
I don't see what this has to do with D design. It's just a quality of
implementation issue, isn't it?
2. Inference. This is an odd one. Currently, the function that
operate on arrays (reserve, dup, length) etc... may or may not be
@safe or pure. Or nothrow. The problem is that we really can't do
anything about it. duping a string is obviously nothrow, but if
you dup something with a postblit, then it might not be (nor
safe).
Yes, this is pitfall of D design.
It's just a matter of taking care of the details. Dup'ing an array
involves allocating a new array (pure @safe nothrow) and copying
elements over (purity/safety/nothrowness depends on postblit). So there
should be two versions of dup, reserve, etc., one for arrays whose
elements can be copied in a pure/safe/nothrow way, one for arrays where
the safety/etc. of copying elements depends on safety/etc. of the
element postblits.
The latter can be taken care of with attribute inference. So for
example, we could do something like this:
T[] dup(T)(T[] array) pure @safe nothrow
if (!hasElaborateCopyConstructor!(T[]))
{
// To reduce template bloat, forward to static function
// that does bitwise copying.
return simpleDupImpl(array.ptr, array.size, T.sizeof);
}
T[] dup(T)(T[] array) /* attributes inferred at compile-time */
if (hasElaborateCopyConstructor!(T[]))
{
// This part is pure @safe nothrow
T[] copy = simpleDupImpl(array.ptr, array.size, T.sizeof);
// This part's purity/safety/nothrowness inherits from
// postblit's characteristics.
callPostblits!T(copy);
}
These issues kind of keep popping up in phobos, and we will have
to address them sooner or later. The current state of affairs is a
kind of status quo of its wrong, inconsistent, but maybe OK most
of the time.
Yeah this is one thing that irks me about D. It works superbly -- for
the most part. But when you hit something outside the most part, then
it's a cascade of troubles and roadblocks, one leading to the other. We
really need to dig into all these details and straighten them out,
otherwise it's going to be a big source of frustration to potential D
adopters.
They are systematically popping up because of systematical language
features (D is statically typed language with little runtime
supported).
And how do you propose we address that?
For example, dup is not nothrow, yet it is safe and pure.
Reserve is nothrow, yet assumeSafeAppend is not. Reserve may
actually call postblit, but not assumeSafeAppend.
Why is assumeSafeAppend not nothrow? If it were up to me, I'd say that
if for whatever reason safe append can't be done (i.e. the assumption is
invalid) and we detect it, we should assert(0), since the code is
obviously not prepared to deal with this case by virtue of calling
assumeSafeAppend in the first place. Throwing an Exception makes no
sense in this case -- it's not something you can handle.
The solution (I think) would be to partially templatize d-runtime.
We can keep most of what is in rt/lifetime.d, but statically split
it into smaller chunks, which could be piloted with more accuracy
via a templated manager.
It depends on how do you want to templatize it. Due to separate
compilation model it is impossible to know beforehand (when you
provide phobos library together with druntime) which types will be
used.
Right, so we use templates for the front-end that interface directly
with user types, but the real work is done by static backend functions.
There will be a different backend function to deal with each different
category of cases, and the front-end templates will just forward to the
most appropriate one.
For now, if we could make a change as simple as no postblit =
safe pure nothrow, and fast guaranteed/postblit = not safe, not
pure, may throw, then it would already be a big win (IMO).
I had started toying around with this, and the main and immediate
challenge I ran into is the integration of templates. The 2 issues
are:
1. All templates must be in object.d, or the compiler won't see
it.
public import is your friend. :)
2. A simple (and needed) trait like hasElaborateCopyConstructor
requires a good third of both typetuple.d and traits.d.
functionAttributes is pretty simple though (I think).
Yes, this is pitfall of D design.
How is this a
Re: D Ranges
On Friday, 13 September 2013 at 14:39:29 UTC, Chris wrote:
On Friday, 13 September 2013 at 13:42:07 UTC, Dicebot wrote:
On Friday, 13 September 2013 at 13:31:18 UTC, bearophile wrote:
In most cases today you are free to omit those ():
foreach (bySentence.byWord.byWhateverFormat.byReformatAgain) {
Bye,
bearophile
...but you shouldn't if you care about readability (leave at
least the last pair in the line) :P
It also helps other people (and me) to realize that it actually
_does_ something and doesn't just return a value. Often (not
always of course), if you omit the brackets it returns a value
without doing anything. But that's just a personal convention I
might abandon further down the road.
Since most ranges in std.algorithm are lazy they are usually not
doing anything but setting a few members and returning a new
range, often without having even touched the input range.
Thinking about it I think I may start using () to denote eager
versus lazy ranges in my UFCS chains.
Re: druntime, templates and traits
On Friday, 13 September 2013 at 17:02:24 UTC, H. S. Teoh wrote: For example, dup is not nothrow, yet it is safe and pure. Reserve is nothrow, yet assumeSafeAppend is not. Reserve may actually call postblit, but not assumeSafeAppend. Why is assumeSafeAppend not nothrow? If it were up to me, I'd say that if for whatever reason safe append can't be done (i.e. the assumption is invalid) and we detect it, we should assert(0), since the code is obviously not prepared to deal with this case by virtue of calling assumeSafeAppend in the first place. Throwing an Exception makes no sense in this case -- it's not something you can handle. Well, by your own conclusion, it doesn't throw :D It either just works, or it errors out. No exceptions. I had started toying around with this, and the main and immediate challenge I ran into is the integration of templates. The 2 issues are: 1. All templates must be in object.d, or the compiler won't see it. public import is your friend. :) What I'm getting so far from this conversation, is we should move select foundation blocks of typetuple/traits from phobos, into druntime. the phobos libraries would then publicly import their druntime counterparts. Then object.d would import core/traits.d and core/typetuple.d (or whatever). Why public import btw? Wouldn't that expose the functions in traits/typetuple to *all* D code? That seems like a bad idea... One of the problems though is that we'd want to try to keep those core/traits libraries as light as possible, since they'd be pretty much imported 99% of the time. Another issue to solve is that the above would work well for say, reserve. However, dup (afaik) is hardwired by the compiler to call the druntime function _adDupT. SO we'd have to change that if we even *hope* for it to infer anything.
Re: druntime, templates and traits
On Fri, Sep 13, 2013 at 07:47:32PM +0200, monarch_dodra wrote: On Friday, 13 September 2013 at 17:02:24 UTC, H. S. Teoh wrote: For example, dup is not nothrow, yet it is safe and pure. Reserve is nothrow, yet assumeSafeAppend is not. Reserve may actually call postblit, but not assumeSafeAppend. Why is assumeSafeAppend not nothrow? If it were up to me, I'd say that if for whatever reason safe append can't be done (i.e. the assumption is invalid) and we detect it, we should assert(0), since the code is obviously not prepared to deal with this case by virtue of calling assumeSafeAppend in the first place. Throwing an Exception makes no sense in this case -- it's not something you can handle. Well, by your own conclusion, it doesn't throw :D It either just works, or it errors out. No exceptions. Right, so how come assumeSafeAppend isn't marked nothrow? I had started toying around with this, and the main and immediate challenge I ran into is the integration of templates. The 2 issues are: 1. All templates must be in object.d, or the compiler won't see it. public import is your friend. :) What I'm getting so far from this conversation, is we should move select foundation blocks of typetuple/traits from phobos, into druntime. the phobos libraries would then publicly import their druntime counterparts. Either that, or factor std.traits in terms of a small number of fundamental primitives, and move those primitives into druntime. Then object.d would import core/traits.d and core/typetuple.d (or whatever). Why public import btw? Wouldn't that expose the functions in traits/typetuple to *all* D code? That seems like a bad idea... This was in response to your question about why stuff must be in object.d(i) otherwise it won't be seen. If it's only needed internally, then a public import is not necessary, but if you want stuff to be imported by default into all programs, but don't want to bloat object.di, then public import is the solution. I've thought before, about splitting up object_.d into more manageable chunks. Public imports would allow us to do this in a transparent, backwards-compatible way. One of the problems though is that we'd want to try to keep those core/traits libraries as light as possible, since they'd be pretty much imported 99% of the time. Yes, that's why I said above that we should distill the stuff we need from std.traits into their barest essentials, and put those in druntime. Then std.traits itself can add more user conveniences around these primitives. Another issue to solve is that the above would work well for say, reserve. However, dup (afaik) is hardwired by the compiler to call the druntime function _adDupT. SO we'd have to change that if we even *hope* for it to infer anything. Oh joy, more compiler magic. Let me know when you figure out how to extricate it from the compiler, since it will probably be useful in extricating AA's from the compiler as well. ;) OTOH, another approach, since the compiler already hardcodes this stuff, is to make the *compiler* infer attributes for .dup. That might actually be easier than trying to move compiler-hardcoded stuff into druntime. (The downside is that you'll have to work with C++... :-P) T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney
Re: D Ranges
On Friday, 13 September 2013 at 17:35:21 UTC, Brad Anderson wrote:
On Friday, 13 September 2013 at 14:39:29 UTC, Chris wrote:
On Friday, 13 September 2013 at 13:42:07 UTC, Dicebot wrote:
On Friday, 13 September 2013 at 13:31:18 UTC, bearophile
wrote:
In most cases today you are free to omit those ():
foreach (bySentence.byWord.byWhateverFormat.byReformatAgain)
{
Bye,
bearophile
...but you shouldn't if you care about readability (leave at
least the last pair in the line) :P
It also helps other people (and me) to realize that it
actually _does_ something and doesn't just return a value.
Often (not always of course), if you omit the brackets it
returns a value without doing anything. But that's just a
personal convention I might abandon further down the road.
Since most ranges in std.algorithm are lazy they are usually
not doing anything but setting a few members and returning a
new range, often without having even touched the input range.
Thinking about it I think I may start using () to denote eager
versus lazy ranges in my UFCS chains.
This reminds me, I have to check whether my ranges are lazy
enough (like myself).
Re: druntime, templates and traits
On Friday, 13 September 2013 at 18:01:30 UTC, H. S. Teoh wrote: On Fri, Sep 13, 2013 at 07:47:32PM +0200, monarch_dodra wrote: On Friday, 13 September 2013 at 17:02:24 UTC, H. S. Teoh wrote: For example, dup is not nothrow, yet it is safe and pure. Reserve is nothrow, yet assumeSafeAppend is not. Reserve may actually call postblit, but not assumeSafeAppend. Why is assumeSafeAppend not nothrow? If it were up to me, I'd say that if for whatever reason safe append can't be done (i.e. the assumption is invalid) and we detect it, we should assert(0), since the code is obviously not prepared to deal with this case by virtue of calling assumeSafeAppend in the first place. Throwing an Exception makes no sense in this case -- it's not something you can handle. Well, by your own conclusion, it doesn't throw :D It either just works, or it errors out. No exceptions. Right, so how come assumeSafeAppend isn't marked nothrow? Oh. Right. I understood you backwards. In that case, it's not nothrow simply because it hasn't been made that way yet. On topic: https://github.com/D-Programming-Language/druntime/pull/553 - Me trying to make assumeSafeAppend nothrow, and learn how druntime works. Another issue to solve is that the above would work well for say, reserve. However, dup (afaik) is hardwired by the compiler to call the druntime function _adDupT. SO we'd have to change that if we even *hope* for it to infer anything. Oh joy, more compiler magic. Let me know when you figure out how to extricate it from the compiler, since it will probably be useful in extricating AA's from the compiler as well. ;) OTOH, another approach, since the compiler already hardcodes this stuff, is to make the *compiler* infer attributes for .dup. That might actually be easier than trying to move compiler-hardcoded stuff into druntime. (The downside is that you'll have to work with C++... :-P) T Hum. I wouldn't mind starting with reserve, and see from there what the best thing to do for dup/idup is from there (including just making it a free function in object ?) An added plus about making it an actual UFCS in object.d, is that we'll be able to (correctly) write it as myArray.dup(). It's not a property god damn it!
Re: [OT] Which IDE / Editor do you use?
vim
Re: [OT] Which IDE / Editor do you use?
gvim
Re: [OT] Which IDE / Editor do you use?
Sublime 3 on OSX
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. Mono-D
Re: [OT] Which IDE / Editor do you use?
On 9/13/13, Namespace rswhi...@googlemail.com wrote: Just out of interest. Scite: http://www.scintilla.org/SciTE.html I use it because it's easy to configure, starts fast, loads big files fast (compared to e.g. Sublime text), it seems to not break on any funky new git-head version of D, and it's open-source.
[OT] Which IDE / Editor do you use?
Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD.
Re: [OT] Which IDE / Editor do you use?
Geany http://www.geany.org/
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. Kate on Linux, Notepad++ on Windows.
Re: [OT] Which IDE / Editor do you use?
vim and gvim on linux.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:51:34 UTC, Peter Alexander wrote: Sublime 3 on OSX No IDE?
Re: [OT] Which IDE / Editor do you use?
On 13-9-2013 21:48, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. Notepad++. I've installed Visual Studio Shell + Visual-D but haven't used it much yet.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 20:07:51 UTC, Namespace wrote: On Friday, 13 September 2013 at 19:51:34 UTC, Peter Alexander wrote: Sublime 3 on OSX No IDE? No, I'm on OSX and Visual Studio is the only IDE I find bearable. All the others I've tried are clunky and slow with little benefits (XCode, Eclipse, MonoDevelop) I haven't tried Mono-D in a while though, so maybe I'll give it another go.
Re: [OT] Which IDE / Editor do you use?
On Fri, 13 Sep 2013 20:02:02 +, Justin Whear wrote: vim and gvim on linux. Unix is my IDE.
Re: [OT] Which IDE / Editor do you use?
i've used mono-d (and might switch back when it is compatiple with recent xamarin api), but switched to Sublime 3 recently. could you share your plugins/configs? i also use scite a lot.
Re: [OT] Which IDE / Editor do you use?
On 9/13/2013 1:29 PM, Walter Bright wrote: MicroEmacs https://github.com/DigitalMars/med https://github.com/DigitalMars/me BTW, one veery nice thing about ME is I can run it from a remote console window. Also, it works exactly the same on every machine/operating system I've owned (ok, I never ported it to the ipod) - DOS, OS/2, Unix, Linux, every Windows flavor, various notebook computers, etc.
Re: [OT] Which IDE / Editor do you use?
On Fri, 13 Sep 2013 21:48:15 +0200 Namespace rswhi...@googlemail.com wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. Programmer's Notepad 2 (Windows-only though :( ) On Linux I've just been getting by with Kate and mcedit, mainly because I haven't really looked into other stuff there yet.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. gvim, with no GUI elements, ultisnips for D snippets, YouCompleteMe for fuzzy completion, and soon DCD for D-aware completion. And various non-D related plugins and custom mappings. Good because I can have e.g. 9 80-column files on the screen at the same time (looking like a grid), and load a session with tens of files almost instantly.
Re: [OT] Which IDE / Editor do you use?
MicroEmacs https://github.com/DigitalMars/med https://github.com/DigitalMars/me
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 20:38:00 UTC, Walter Bright wrote: BTW, one veery nice thing about ME is I can run it from a remote console window. Yea, that's a big reason I use vim too. I do a lot of my work through remote connections and having my trusty editor available with good speed and resumeability where I left off (thanks to gnu screen) is a huge nice thing.
Re: [OT] Which IDE / Editor do you use?
Textadept with DCD. Also, Unix is my IDE.
Re: [OT] Which IDE / Editor do you use?
On 9/13/13 1:37 PM, Walter Bright wrote: On 9/13/2013 1:29 PM, Walter Bright wrote: MicroEmacs https://github.com/DigitalMars/med https://github.com/DigitalMars/me BTW, one veery nice thing about ME is I can run it from a remote console window. Also, it works exactly the same on every machine/operating system I've owned (ok, I never ported it to the ipod) - DOS, OS/2, Unix, Linux, every Windows flavor, various notebook computers, etc. No syntax highlighting... Andrei
Re: Not with the scene…
On Fri, 13 Sep 2013 09:50:52 +0100 Russel Winder rus...@winder.org.uk wrote: On Wed, 2013-09-11 at 14:56 +0200, Sönke Ludwig wrote: […] Regarding the dub music genre, it has to be said that although it is the root for dubstep and in turn ... brostep, it's usually not really comparable result-wise and I have a strong desire to avoid putting the word step somewhere in proximity of DUB ;) Perhaps this is the last word on the dubstep issue :-) http://www.mazbox.com/synths/dubstep/ I always knew one day I'd see DSP done in JS, and there it is! I'm torn - on one had it's an affront to good software engineering, but OTOH, it's so damn cool in a high-precision PI in DOS batch sort of way :)
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 20:44:52 UTC, Adam D. Ruppe wrote: On Friday, 13 September 2013 at 20:38:00 UTC, Walter Bright wrote: BTW, one veery nice thing about ME is I can run it from a remote console window. Yea, that's a big reason I use vim too. I do a lot of my work through remote connections and having my trusty editor available with good speed and resumeability where I left off (thanks to gnu screen) is a huge nice thing. Do you actually write significant amounts of code on remote machines? I'm struggling to find a reason to do that.
Re: [OT] Which IDE / Editor do you use?
On Fri, 13 Sep 2013 22:44:51 +0200 Adam D. Ruppe destructiona...@gmail.com wrote: On Friday, 13 September 2013 at 20:38:00 UTC, Walter Bright wrote: BTW, one veery nice thing about ME is I can run it from a remote console window. Yea, that's a big reason I use vim too. I do a lot of my work through remote connections and having my trusty editor available with good speed and resumeability where I left off (thanks to gnu screen) is a huge nice thing. I find vim/emacs confusing, so when I do remote text editing over ssh (or on a machine without a GUI) I like to use mcedit. It does still have some weirdness (copy-paste is a little odd), but it's the closest I've found to a GUI-like editor in text mode. Although if the physical machine I'm on happens to be Linux, I usually prefer to just connect via sshfs and then use whatever GUI-based editor I'd normally use. I love sshfs, I wish Windows had it.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 20:35:41 UTC, Zoadian wrote: i've used mono-d (and might switch back when it is compatiple with recent xamarin api), but switched to Sublime 3 recently. could you share your plugins/configs? i also use scite a lot. Ops, it seems I confused Mono-D - Xamarin. I use Xamarin 4.0.12 with D Plugin from Alexander. I have, besides git, no other Plugins installed. I use Xamarin for developing on Dgame or Demo/Games for it and Sublime/Notpad++ for smaller files.
Re: [OT] Which IDE / Editor do you use?
On Fri, Sep 13, 2013 at 09:48:15PM +0200, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. vim. T -- Stop staring at me like that! You'll offend... no, you'll hurt your eyes!
Re: [OT] Which IDE / Editor do you use?
On Fri, Sep 13, 2013 at 08:38:49PM +, Justin Whear wrote: On Fri, 13 Sep 2013 20:02:02 +, Justin Whear wrote: vim and gvim on linux. Unix is my IDE. +1, I like that!! :) I'm gonna hafta start saying that from now on, whenever people ask me about IDEs. T -- Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.
Re: [OT] Which IDE / Editor do you use?
On Fri, Sep 13, 2013 at 01:40:02PM -0700, Andrei Alexandrescu wrote: On 9/13/13 1:37 PM, Walter Bright wrote: On 9/13/2013 1:29 PM, Walter Bright wrote: MicroEmacs https://github.com/DigitalMars/med https://github.com/DigitalMars/me BTW, one veery nice thing about ME is I can run it from a remote console window. Also, it works exactly the same on every machine/operating system I've owned (ok, I never ported it to the ipod) - DOS, OS/2, Unix, Linux, every Windows flavor, various notebook computers, etc. No syntax highlighting... [...] Syntax highlighting hurts my eyes. I've been using vim in black-on-white for more than a decade now. (Well, more accurately, black on an almost fully saturated off-white, but that's irrelevant.) T -- Doubt is a self-fulfilling prophecy.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 20:58:06 UTC, H. S. Teoh wrote: On Fri, Sep 13, 2013 at 08:38:49PM +, Justin Whear wrote: On Fri, 13 Sep 2013 20:02:02 +, Justin Whear wrote: vim and gvim on linux. Unix is my IDE. +1, I like that!! :) I'm gonna hafta start saying that from now on, whenever people ask me about IDEs. T notepad++ on windows. kate on linux. Though I do *try* to learn vim (as in, be efficient with it, not quite there yet).
Re: [OT] Which IDE / Editor do you use?
On Fri, 13 Sep 2013 22:46:45 +0200, Peter Alexander wrote: On Friday, 13 September 2013 at 20:44:52 UTC, Adam D. Ruppe wrote: On Friday, 13 September 2013 at 20:38:00 UTC, Walter Bright wrote: BTW, one veery nice thing about ME is I can run it from a remote console window. Yea, that's a big reason I use vim too. I do a lot of my work through remote connections and having my trusty editor available with good speed and resumeability where I left off (thanks to gnu screen) is a huge nice thing. Do you actually write significant amounts of code on remote machines? I'm struggling to find a reason to do that. I don't write a lot of code remotely aside from the infrequent quickfix on our testing server. But I do quite a bit of editing of configurations on remote boxes; because vim is installed by default in linux, it's just matter of cloning my vim bundle (https://github.com/jwhear/vim- bundle.git) into my home directory on the remote machine and boom, my full install complete with plugins.
Re: [OT] Which IDE / Editor do you use?
On Fri, Sep 13, 2013 at 10:46:45PM +0200, Peter Alexander wrote: On Friday, 13 September 2013 at 20:44:52 UTC, Adam D. Ruppe wrote: On Friday, 13 September 2013 at 20:38:00 UTC, Walter Bright wrote: BTW, one veery nice thing about ME is I can run it from a remote console window. Yea, that's a big reason I use vim too. I do a lot of my work through remote connections and having my trusty editor available with good speed and resumeability where I left off (thanks to gnu screen) is a huge nice thing. Do you actually write significant amounts of code on remote machines? I'm struggling to find a reason to do that. I do. I prefer to keep code in a single place, i.e., on my PC, so when I'm away from my desk (travelling, house-sitting for my mother-in-law, etc.), I use GNU screen over ssh. Screen, especially, lets me continue the same coding session in the little bits of free time I have here and there (start coding in the morning, pause to get to work, work on work, resume coding during lunch break, get back to work, resume while waiting for long work-related build to finish, go back to work, resume at mother-in-law's house while waiting for people to show up for dinner, pause to have dinner, resume after dinner while waiting for wife to walk the dog, etc.). One of the most complex algorithms I've ever implemented for a personal project (C++ at the time) was all done over ssh from my mother-in-law's while house-sitting for her. T -- If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
Re: [OT] Which IDE / Editor do you use?
mostly geany with bud/build so i don't need any project files but can easily tackle small and medium sized projects. i love the way how bud tracks down all imports, (can) clean up after compilation, and handles different sets of options in option groups - and geany does the rest one of my projects might grow big enough to benefit from a full-fledged IDE, probably MonoD as this project is multi-platform. otherwise VisualD as VS is more stable than monodevelop. i played with both but in general, i find those big IDEs to awkward to deal with for small projects. /det
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 20:46:46 UTC, Peter Alexander wrote: Do you actually write significant amounts of code on remote machines? I'm struggling to find a reason to do that. Yeah, I'd say about half my time is spent on a remote computer, generally my laptop. All my files and programs are on my desktop, but I'm not always there. Sometimes I just want to sit in an other room or in the yard, but often (several hours a day, almost every day) I'm at a friend's house keeping an eye on their kids. Since the kids almost take care of themselves, I bring my laptop and continue to do my computer work from there too.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 20:51:50 UTC, Nick Sabalausky wrote: I'd normally use. I love sshfs, I wish Windows had it. I actually shelled out... I think $20 a few years ago, for a program called ExpanDrive on Windows, which connects via ssh to my Linux box and presents it as a windows drive. Pretty cool, it works fairly well and is a nice supplement to putty.
Re: [OT] Which IDE / Editor do you use?
Sublime Text 3
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. Mainly VisualD and for linux Mono-D. Mono-D have a great auto completion.
Re: Not with the scene…
On Friday, 13 September 2013 at 16:27:11 UTC, Iain Buclaw wrote: On Sep 13, 2013 9:53 AM, Russel Winder rus...@winder.org.uk wrote: On Wed, 2013-09-11 at 14:56 +0200, Sönke Ludwig wrote: […] Regarding the dub music genre, it has to be said that although it is the root for dubstep and in turn ... brostep, it's usually not really comparable result-wise and I have a strong desire to avoid putting the word step somewhere in proximity of DUB ;) Perhaps this is the last word on the dubstep issue :-) http://www.mazbox.com/synths/dubstep/ Someone should port to D. In fact that's one thing I'd definitely would like to start a case for - using D in audio processing (eg: effects, synths :-) Regards Me too. Unfortunately the whole pro-audio plugin industry is completely wrapped around steinbergs little finger, doing everything as VSTs in c++.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 21:09:40 UTC, H. S. Teoh wrote: I do. I prefer to keep code in a single place, i.e., on my PC, so when I'm away from my desk (travelling, house-sitting for my mother-in-law, etc.), I use GNU screen over ssh. The headers of your messages tell me that you probably do email the same way I do too: keep it all on the home computer and ssh in with mutt! (I use the website for replying to D postings though, since the mailing list interface I find unreliable for outgoing messages.)
Re: [OT] Which IDE / Editor do you use?
Ubuntu Linux with: - gvim compiled with the breakindent patch (that I had to patch myself for the vim source I checked out) for nicely wrapped and indented long lines (mostly used outside D programming). - xfce4-terminal - rdmd for simple programs, - gnu make when interfacing with C/C++. On 09/13/2013 09:48 PM, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD.
Re: [OT] Which IDE / Editor do you use?
On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote: Just out of interest. I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD. GNU Emacs
