Re: DDT 0.7.0 released
On Thu, 2013-08-15 at 20:20 +0100, Bruno Medeiros wrote: A new version of DDT - D Development tools is out. The major change is the new parser which is updated to the latest version of D, and is much more robust than the previous one. Full changelog/info here: https://groups.google.com/d/msg/ddt-ide/z9ggxfCKR6M/3YrkjusZRfYJ Note that Juno and Kepler versions of Eclipse are not supported if they contain DLTK. If you wanna use Juno/Kepler, download a package without DLTK. Supported for the latest versions of DLTK will be added in the future. I assume the Eclipse updates URL is http://updates.ddt.googlecode.com/git/ -- 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: DDT 0.7.0 released
On 2013-08-15 21:20, Bruno Medeiros wrote: A new version of DDT - D Development tools is out. The major change is the new parser which is updated to the latest version of D, and is much more robust than the previous one. Full changelog/info here: https://groups.google.com/d/msg/ddt-ide/z9ggxfCKR6M/3YrkjusZRfYJ Note that Juno and Kepler versions of Eclipse are not supported if they contain DLTK. If you wanna use Juno/Kepler, download a package without DLTK. Supported for the latest versions of DLTK will be added in the future. I downloaded the standard version of Kepler. Then I followed the installation instructions. But after the restart I don't see anything related to DDT/D in the preferences. -- /Jacob Carlborg
Re: DDT 0.7.0 released
On 16/08/2013 11:12, Russel Winder wrote: On Thu, 2013-08-15 at 20:20 +0100, Bruno Medeiros wrote: A new version of DDT - D Development tools is out. The major change is the new parser which is updated to the latest version of D, and is much more robust than the previous one. Full changelog/info here: https://groups.google.com/d/msg/ddt-ide/z9ggxfCKR6M/3YrkjusZRfYJ Note that Juno and Kepler versions of Eclipse are not supported if they contain DLTK. If you wanna use Juno/Kepler, download a package without DLTK. Supported for the latest versions of DLTK will be added in the future. I assume the Eclipse updates URL is http://updates.ddt.googlecode.com/git/ Yes, I forgot to mention the update site URL changed since last release. -- Bruno Medeiros - Software Engineer
Re: DDT 0.7.0 released
On Fri, 2013-08-16 at 13:08 +0200, Jacob Carlborg wrote: […] I downloaded the standard version of Kepler. Then I followed the installation instructions. But after the restart I don't see anything related to DDT/D in the preferences. I installed into Juno which seems to work fine, I have no idea whether DLTK is installed or not. However on starting, I get the following on the console: = Mmrnmhrm INITIALIZING = The single biggest problem with Eclipse is the annual upgrade marathon. Since nothing carries over from one installation to another you have to go through the whole rigmarole to install all the extras, every year. I wonder whether to stay with Juno and ignore Kepler. -- 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: DDT 0.7.0 released
On 16/08/2013 12:08, Jacob Carlborg wrote: On 2013-08-15 21:20, Bruno Medeiros wrote: A new version of DDT - D Development tools is out. The major change is the new parser which is updated to the latest version of D, and is much more robust than the previous one. Full changelog/info here: https://groups.google.com/d/msg/ddt-ide/z9ggxfCKR6M/3YrkjusZRfYJ Note that Juno and Kepler versions of Eclipse are not supported if they contain DLTK. If you wanna use Juno/Kepler, download a package without DLTK. Supported for the latest versions of DLTK will be added in the future. I downloaded the standard version of Kepler. Then I followed the installation instructions. But after the restart I don't see anything related to DDT/D in the preferences. Very strange! (that it completes the install, but doesn't start properly) Let me see your configuration log, it's at: Help About Eclipse Installation Details Configuration And also the Error log, it's at View Error Log on that same dialog. -- Bruno Medeiros - Software Engineer
Re: DDT 0.7.0 released
On 16/08/2013 13:03, Russel Winder wrote: The single biggest problem with Eclipse is the annual upgrade marathon. Since nothing carries over from one installation to another you have to go through the whole rigmarole to install all the extras, every year. I wonder whether to stay with Juno and ignore Kepler. If you add the update site for the new Eclipse release (for example http://download.eclipse.org/releases/kepler for Kepler) to your current installation, and run the Check for Updates it should update Eclipse and retain all the extra plugins you have installed. (it should update all Eclipse projects that are part of the Kepler release, basically nearly all projects that hosted at Eclipse.org) It's a bit annoying that this isn't done automatically in some way, yes. And also annoying that the update site for new releases is not easily found on the Eclipse website either. -- Bruno Medeiros - Software Engineer
Re: DDT 0.7.0 released
On 15/08/2013 20:20, Bruno Medeiros wrote: A new version of DDT - D Development tools is out. The major change is the new parser which is updated to the latest version of D, and is much more robust than the previous one. Full changelog/info here: https://groups.google.com/d/msg/ddt-ide/z9ggxfCKR6M/3YrkjusZRfYJ Note that Juno and Kepler versions of Eclipse are not supported if they contain DLTK. If you wanna use Juno/Kepler, download a package without DLTK. Supported for the latest versions of DLTK will be added in the future. Seems like the raw HTTP file view of Git repositories in Google Code hosting is down at the moment. This mean the update site is not accessible: http://updates.ddt.googlecode.com/git/ - fails with a 404 error If you wanna use the update site in the meanwhile, you can get it as a zip from: http://updates.ddt.googlecode.com/archive/aa309c6726c8e8d7635100a34abbad51542ebc9a.zip I've opened an issue with Google Code, as I've seen this happen several times, a bit more often than it should IMO: http://code.google.com/p/support/issues/detail?id=30947 -- Bruno Medeiros - Software Engineer
Re: DDT 0.7.0 released
On Fri, 2013-08-16 at 14:19 +0100, Bruno Medeiros wrote: […] If you add the update site for the new Eclipse release (for example http://download.eclipse.org/releases/kepler for Kepler) to your current installation, and run the Check for Updates it should update Eclipse and retain all the extra plugins you have installed. (it should update all Eclipse projects that are part of the Kepler release, basically nearly all projects that hosted at Eclipse.org) Having backed everything up (which means creating about 6 replicas for me), I took the plunge and s/4.2/4.3/ s/juno/kepler/ for all my update sites and updated. It appears to have done the needful. Thanks for this, it has saved many hours of swearing. It's a bit annoying that this isn't done automatically in some way, yes. And also annoying that the update site for new releases is not easily found on the Eclipse website either. Bit annoying amounts to a mega-understatement :-) Now I just have to remove all the jars that are no longer needed. Why doesn't Eclipse garbage collect it's local cache? -- 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: DDT 0.7.0 released
On 15/08/2013 20:25, Andrei Alexandrescu wrote: On 8/15/13 12:20 PM, Bruno Medeiros wrote: A new version of DDT - D Development tools is out. The major change is the new parser which is updated to the latest version of D, and is much more robust than the previous one. Full changelog/info here: https://groups.google.com/d/msg/ddt-ide/z9ggxfCKR6M/3YrkjusZRfYJ Note that Juno and Kepler versions of Eclipse are not supported if they contain DLTK. If you wanna use Juno/Kepler, download a package without DLTK. Supported for the latest versions of DLTK will be added in the future. Cool! I noticed that no screenshot linked from https://code.google.com/p/ddt/wiki/Features loads. Andrei I've updated the Features wiki with new screenshots, and revised the text to be more clear: http://code.google.com/p/ddt/wiki/Features (like removing the A JDT-like project model references which actually doesn't mean anything to people who are not familiar with JDT) Found a bug in the meanwhile, the DDoc viewer is not rendering $(D) DDoc macros. -- Bruno Medeiros - Software Engineer
Re: DDT 0.7.0 released
On 8/16/13 12:14 PM, Bruno Medeiros wrote: I've updated the Features wiki with new screenshots, and revised the text to be more clear: http://code.google.com/p/ddt/wiki/Features (like removing the A JDT-like project model references which actually doesn't mean anything to people who are not familiar with JDT) Looking good! Should I shoot a post to reddit on Monday? Andrei
Re: DDT 0.7.0 released
W dniu 16.08.2013 15:32, Bruno Medeiros pisze: On 15/08/2013 22:07, Piotr Szturmaj wrote: W dniu 15.08.2013 21:20, Bruno Medeiros pisze: A new version of DDT - D Development tools is out. The major change is the new parser which is updated to the latest version of D, and is much more robust than the previous one. Full changelog/info here: https://groups.google.com/d/msg/ddt-ide/z9ggxfCKR6M/3YrkjusZRfYJ Note that Juno and Kepler versions of Eclipse are not supported if they contain DLTK. If you wanna use Juno/Kepler, download a package without DLTK. Supported for the latest versions of DLTK will be added in the future. Cool! It doesn't work with nodeclipse so it must be uninstalled (this may be done after installing DDT). Then it seems to be working, but user should setup DMD paths manually if he's on Linux like me (I'm on Ubuntu 12.10). Paths for DMD should be set up to /usr/bin/dmd for executable and /usr/include/dmd/druntime/import, /usr/include/dmd/phobos for libraries. What do you mean manually? If you add a compiler installation by pointing to the DMD compiler executable at /usr/bin/dmd then the library paths should be filled automatically. I've pointed path to the DMD compiler executable but the library paths weren't filled automatically. Maybe it's a bug? (eclipse CDT Kepler) You still have to manually add the compiler installation by pointing to the DMD compiler executable, yes. I guess that step could be automated too, in Linux.
Re: D reaches 1000 questions on stackoverflow
On Thursday, 15 August 2013 at 02:30:42 UTC, Jonathan M Davis wrote: On Wednesday, August 14, 2013 22:56:30 Andre Artus wrote: As with many things it depends on what you want to achieve. Answering on SO is as much about establishing awareness as it is about answering the question. For a newcomer to D StackOverflow may be their first port of call, if questions go unanswered, or are answered after long delays, then the likelihood of the person persisting with D is diminished. I answer questions on SO all the time, but I rarely ask anything there, and I never ask anything D-related there. Of course, if my question is D-related, I'm much more likely to _have_ to ask my question here to get a good answer anyway just based on how many people would even know the answer, simply because I know enough that anything I asked would be much more likely to be esoteric and/or require in-depth knowledge. The experts are all here, and only a small portion of them are on SO. In any case, I'd say that in general, asking your question on SO gives it more visibility to those outside of the core D community, but you're more likely to get a good answer here than there, because there are more people here, and this is where the experts are. - Jonathan M Davis First off, thank you so much for answering questions on SO. Answers there come up higher in Google search results than questions here, and several of your answers have been very helpful to me. There are others that answer, who I'm also grateful for, but your name always sticks out to me when I see an answer there. It's true though that there are much better answers (and questions) here than on SO, and I'm beginning to shift my search from Google to the forum search, but this isn't something a newcomer will know to do, especially since many other languages put more emphasis on SO.
Re: Ironclad C++
On Friday, 16 August 2013 at 05:48:12 UTC, Kagamin wrote: On Friday, 9 August 2013 at 17:00:53 UTC, deadalnix wrote: It is ambiguous if the inout of the function passed as parameter stand for the function passed as parameter or the function you pass the parameter to. See my explanation, how inout works and why your example ignores semantics of inout: http://forum.dlang.org/post/jenapjffdszqqclyx...@forum.dlang.org Dude I've read that. Your definition isn't helping in any way to resolve the ambiguity we are talking about here, and so the only reasonable assumption I can make at this point is that you didn't understood how the presented cases were ambiguous. Right now you are losing your time and ours, by explaining us something we already know.
Re: Ideas for a brand new widget toolkit
Andrei Alexandrescu wrote: On 8/15/13 12:42 PM, Adam D. Ruppe wrote: On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote: I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases. You're probably using bloated apps! I'm using my crappygui.d on remote X and it works quite well. Of course it is mostly rectangles of solid colors :) I also just tried creating an OpenGL window remotely, and it performed reasonably well too, drawing some colorful triangles. I think I'll add some minimal support for creating opengl contexts to simpledisplay.d, that's useful stuff. The X Window System is slow by design, particularly when used over a network (regardless how fast). There are various proxies and alternate remoting protocols that avoid its inherent latencies. At work we use OpenNX. If we are discussing X's shortcomings: why don't we use something like http://wayland.freedesktop.org/ which will (hopefully) become next big standard and which addresses many of X's flaws? -- Marek Janukowicz
[OT] Bret Victor's Talk at DBX, The Future of Programming
A very interesting talk done as if we were in the mid-70's discussing the future of programming in 40 years time (meaning today). http://vimeo.com/71278954 The main message is how fast technology changes and how developers resist to change specially in the presence of dogmas. -- Paulo
Re: Mixin overload sets
On Wednesday, 14 August 2013 at 17:35:28 UTC, BLM768 wrote:
The current behavior of placing identically-named functions
from separate mixins into separate overload sets works well
most of the time, but there are cases when the functions should
be in the same overload set, and the aliasing required to allow
overloading can quickly get tedious and clutter the namespace
where the mixins are used, especially if the mixins define
multiple functions.
mixin template someMixin(Args ...) {
void abc(Args) {};
void def(int, Args);
}
struct HasMixins {
mixin someMixin!int mixinInt;
alias mixinInt.abc abc;
alias mixinInt.def def;
mixin someMixin!float mixinFloat;
alias mixinFloat.abc abc;
alias mixinFloat.def def;
//and so on...
}
It would be nice if we had a more concise way to pull all of
the duplicate functions into a single overload set. I can think
of two ways to handle this:
1. Introduce a new syntax.
struct HasMixins {
//One possible syntax:
alias mixin someMixin!int this;
alias mixin someMixin!float this;
//etc.
}
HasMixins hm;
hm.abc(3f); //Would call HasMixins.abc(float)
2. Automatically place functions that come from different
instances of the same mixin template into the same namespace.
struct HasMixins {
mixin someMixin!int;
mixin someMixin!float;
}
HasMixins hm;
hm.abc(3f); //Would call HasMixins.abc(float)
mixin template someOtherMixin {
void abc() {};
}
struct HasOtherMixins {
mixin someMixin!int;
mixin someMixin!float;
mixin someOtherMixin;
}
HasOtherMixins hm2;
hm2.abc(3f); //error
Thoughts?
You can put those functions into HasOtherMixins by using alias.
struct HasOtherMixins {
...
alias someMixin!int.abc abc;
alias someMixin!float.abc abc;
alias someOtherMixin abc;
}
Re: Mixin overload sets
On Friday, 16 August 2013 at 07:48:52 UTC, QAston wrote:
On Wednesday, 14 August 2013 at 17:35:28 UTC, BLM768 wrote:
The current behavior of placing identically-named functions
from separate mixins into separate overload sets works well
most of the time, but there are cases when the functions
should be in the same overload set, and the aliasing required
to allow overloading can quickly get tedious and clutter the
namespace where the mixins are used, especially if the mixins
define multiple functions.
mixin template someMixin(Args ...) {
void abc(Args) {};
void def(int, Args);
}
struct HasMixins {
mixin someMixin!int mixinInt;
alias mixinInt.abc abc;
alias mixinInt.def def;
mixin someMixin!float mixinFloat;
alias mixinFloat.abc abc;
alias mixinFloat.def def;
//and so on...
}
It would be nice if we had a more concise way to pull all of
the duplicate functions into a single overload set. I can
think of two ways to handle this:
1. Introduce a new syntax.
struct HasMixins {
//One possible syntax:
alias mixin someMixin!int this;
alias mixin someMixin!float this;
//etc.
}
HasMixins hm;
hm.abc(3f); //Would call HasMixins.abc(float)
2. Automatically place functions that come from different
instances of the same mixin template into the same namespace.
struct HasMixins {
mixin someMixin!int;
mixin someMixin!float;
}
HasMixins hm;
hm.abc(3f); //Would call HasMixins.abc(float)
mixin template someOtherMixin {
void abc() {};
}
struct HasOtherMixins {
mixin someMixin!int;
mixin someMixin!float;
mixin someOtherMixin;
}
HasOtherMixins hm2;
hm2.abc(3f); //error
Thoughts?
You can put those functions into HasOtherMixins by using alias.
struct HasOtherMixins {
...
alias someMixin!int.abc abc;
alias someMixin!float.abc abc;
alias someOtherMixin abc;
}
Ah, I just saw you did that in the beginning of the post. I blame
missing that to writing this early in the morning :)
Re: Migrating dmd to D?
Brad Anderson e...@gnuk.net wrote in message news:vdiwuykbulxauiabw...@forum.dlang.org... On Thursday, 15 August 2013 at 14:11:02 UTC, Daniel Murphy wrote: Suliman bubnenk...@gmail.com wrote in message news:htihsekthjkyhqazu...@forum.dlang.org... Does anybody work on port D to D? I've done quite a lot of work on it since dconf. The progress of making the C++ source 'conversion compatible' is shown here: https://github.com/D-Programming-Language/dmd/pull/1980 So all of those changes were just done by hand, right? Have the other DDMD labeled pull requests just been you cherry-picking from that branch? Yes. The porting program is here: https://github.com/yebblies/magicport2 I am currently able to convert the C++ source to D, then build that into a compiler capable of building itself, druntime, phobos (with unittests), and passing the test suite on win32. So what's left is basically cleaning it all up and fine tuning it so it's good enough for the actual transition? Mostly, yes.
Re: Migrating dmd to D?
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.91.1376592874.1719.digitalmar...@puremagic.com... On Thu, Aug 15, 2013 at 08:19:06PM +0200, Brad Anderson wrote: On Thursday, 15 August 2013 at 14:11:02 UTC, Daniel Murphy wrote: [...] I am currently able to convert the C++ source to D, then build that into a compiler capable of building itself, druntime, phobos (with unittests), and passing the test suite on win32. So what's left is basically cleaning it all up and fine tuning it so it's good enough for the actual transition? Whoa. This is good news! So you're saying we already have a working D compiler written in D (albeit autoconverted from C++), and all that remains is for some cleanup + performance tuning? Yep, all the fun parts are done and the rest should be fairly tedious.
Re: Migrating dmd to D?
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:kuj10l$194l$1...@digitalmars.com... On 8/15/13 7:10 AM, Daniel Murphy wrote: Suliman bubnenk...@gmail.com wrote in message news:htihsekthjkyhqazu...@forum.dlang.org... Does anybody work on port D to D? I've done quite a lot of work on it since dconf. The progress of making the C++ source 'conversion compatible' is shown here: https://github.com/D-Programming-Language/dmd/pull/1980 The porting program is here: https://github.com/yebblies/magicport2 I am currently able to convert the C++ source to D, then build that into a compiler capable of building itself, druntime, phobos (with unittests), and passing the test suite on win32. Did you have a chance to measure the speed of the Double-D compiler? Andrei Last time I measured there was a ~20% performance hit. The D version throws away all the recent work done on tuning the internal allocator, and uses the GC for all allocations (with collections turned off). I suspect a large chunk of the extra time comes from that.
Re: Migrating dmd to D?
On Friday, August 16, 2013 18:54:41 Daniel Murphy wrote: Yep, all the fun parts are done and the rest should be fairly tedious. LOL. I guess that that's kind of where I am with splitting std.datetime. It's basically done code-wise, but now I have to fix all of the documentation, which is no fun at all. :) - Jonathan M Davis
Re: Migrating dmd to D?
Kagamin s...@here.lot wrote in message news:iceiqyqtdsippewge...@forum.dlang.org... Isn't the resulting D code is still one 70k-line file? ~92k Putting the code into multiple files is trivial, but until we've done some major refactoring it won't start to resemble the original source organisation. ( see https://github.com/D-Programming-Language/dmd/pull/2356 for some discussion )
Re: Migrating dmd to D?
On Friday, 16 August 2013 at 09:28:13 UTC, Daniel Murphy wrote: Kagamin s...@here.lot wrote in message news:iceiqyqtdsippewge...@forum.dlang.org... Isn't the resulting D code is still one 70k-line file? ~92k Putting the code into multiple files is trivial, but until we've done some major refactoring it won't start to resemble the original source organisation. ( see https://github.com/D-Programming-Language/dmd/pull/2356 for some discussion ) Looking forward DMD!D The D compiler that compiles itself at compile time :-)
Re: GPGPUs
On Fri, 2013-08-16 at 04:21 +0200, Atash wrote: […] Clarifying question: At what level is this interest pointed at? Is it at the level of assembly/IL and other scary stuff, or is it at creating bindings that are cleaner and providing more convenient tools? Assembly language and other intermediate languages is far from scary but not really what is proposed, which was intended to be standards compliant, with the current standard being OpenCL. There is a place for assembly language level working but there are others who do that to realize the standards giving us a C linkage API. 'Cuz I'm seeing a lot of potential in D for a library-based solution, handling kernel code similar to how CUDA does (I think the word is 'conveniently'), 'cept with OpenCL or whatever lower-level-standard-that-exists-on-more-than-just-one-company's-hardware and abuse of the import() expression coupled with a heavy dose of metaprogramming magic. CUDA has a huge tool chain designed as much to ensure lock in to C, C++ and NVIDIA as to make computations easier for end users. OpenCL is (was?) Apple's vision for API access to the mixed CPU and GPGPU hardware it envisaged, and which is now rapidly being delivered. Intel chips from now on will always have one or more GPGPU on the CPU chips. They label this the many core approach. The core (!) point here is that processor chips are rapidly becoming a collection of heterogeneous cores. Any programming language that assumes a single CPU or a collection of homogeneous CPUs has built-in obsolescence. So the question I am interested in is whether D is the language that can allow me to express in a single codebase a program in which parts will be executed on one or more GPGPUs and parts on multiple CPUs. D has support for the latter, std.parallelism and std.concurrency. I guess my question is whether people are interested in std.gpgpu (or some more sane name). -- 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: Migrating dmd to D?
On Aug 16, 2013 10:55 AM, BS slackov...@gmail.com wrote: On Friday, 16 August 2013 at 09:28:13 UTC, Daniel Murphy wrote: Kagamin s...@here.lot wrote in message news:iceiqyqtdsippewge...@forum.dlang.org... Isn't the resulting D code is still one 70k-line file? ~92k Putting the code into multiple files is trivial, but until we've done some major refactoring it won't start to resemble the original source organisation. ( see https://github.com/D-Programming-Language/dmd/pull/2356 for some discussion ) Looking forward DMD!D The D compiler that compiles itself at compile time :-) I suspect we won't be able to do that efficiently until Don starts speeding up CTFE. ;-) Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: GPGPUs
On Friday, 16 August 2013 at 10:04:22 UTC, Russel Winder wrote: [...] The core (!) point here is that processor chips are rapidly becoming a collection of heterogeneous cores. Any programming language that assumes a single CPU or a collection of homogeneous CPUs has built-in obsolescence. So the question I am interested in is whether D is the language that can allow me to express in a single codebase a program in which parts will be executed on one or more GPGPUs and parts on multiple CPUs. D has support for the latter, std.parallelism and std.concurrency. I guess my question is whether people are interested in std.gpgpu (or some more sane name). It seems to me that you are describing something similar to C++ AMP, which is a high level, language specific solution to GPGPU problem.
Re: Migrating dmd to D?
Iain Buclaw ibuc...@ubuntu.com wrote in message news:mailman.100.1376649733.1719.digitalmar...@puremagic.com... On Aug 16, 2013 10:55 AM, BS slackov...@gmail.com wrote: On Friday, 16 August 2013 at 09:28:13 UTC, Daniel Murphy wrote: Kagamin s...@here.lot wrote in message news:iceiqyqtdsippewge...@forum.dlang.org... Isn't the resulting D code is still one 70k-line file? ~92k Putting the code into multiple files is trivial, but until we've done some major refactoring it won't start to resemble the original source organisation. ( see https://github.com/D-Programming-Language/dmd/pull/2356 for some discussion ) Looking forward DMD!D The D compiler that compiles itself at compile time :-) I suspect we won't be able to do that efficiently until Don starts speeding up CTFE. ;-) Well, the compiler could always invoke the compiler (while compiling the compiler) to compile the compiler, thus vastly improving the speed of ctfe.
Re: Migrating dmd to D?
On 08/16/2013 12:42 PM, Iain Buclaw wrote: I suspect we won't be able to do that efficiently until Don starts speeding up CTFE. ;-) Using, of course, only CTFE-able language constructs.
Re: Pointer alignments in the type system?
On 16 August 2013 04:39, bearophile bearophileh...@lycos.com wrote:
The XMM registers I am using are efficient when you feed them memory from
arrays aligned to 16 bytes, as the D GC produces. But the YMM registers
used by the AVX/AVX2 instructions prefer an alignment of 32 bytes. And the
Intel Xeon Phi (MIC) has XMM registers that are efficient when the arrays
are aligned to 64 bytes.
When I am not using SIMD code, and I want a small array of little
elements, like an array of 10 ushorts, having it aligned to 16 bytes is a
waste of space (despite helps the GC reduce the fragmentation).
I'd argue that if you're alloc-ing many instances of 10 short's
independently on the heap, then you're probably doing it wrong.
If you're only doing it once or twice, then it's not a significant waste of
memory as you say.
So I have written a small enhancement request, where I suggest that arrays
for YMM registers could be allocated with an alignment of 32 bytes:
http://d.puremagic.com/issues/**show_bug.cgi?id=10826http://d.puremagic.com/issues/show_bug.cgi?id=10826
This shouldn't be an enhancement request, it should be the rule.
__vector()'s should be intrinsically aligned to their sizeof. If they are
not, it should be a bug.
Having the array alignments in the D type system could be useful. To be
backward-compatible you also need a generic unknown alignment (like a void*
for alignments), so you can assign arrays of any alignment to it, it could
be denoted with '0'.
Some rough ideas:
import core.simd: double2, double4;
auto a = new int[10];
static assert(__traits(alignment, a) == 16);
auto b = new int[128]32;
static assert(__traits(alignment, b) == 32);
auto c1 = new double2[128];
auto c2 = new double4[64];
static assert(__traits(alignment, c1) == 16);
static assert(__traits(alignment, c2) == 32);
void foo1(int[]32 a) {
// Uses YMM registers to modify a
// ...
}
void foo2(int[] a)
if (__traits(alignment, a) == 32) {
// Uses YMM registers to modify a
// ...
}
void foo3(size_t N)(int[]N a) {
static if (N = 32) {
// Uses YMM registers to modify a
// ...
} else {
// ...
}
}
The thing is, a/b/c1/c2 is really just: struct { size_t length; T *ptr; }
Those symbol names just refer to the dynamic array struct... It doesn't
make a lot of sense to query the alignment of those symbols.
__traits(alignment, s) would == sizeof(size_t) every time.
I've thought about this sort of thing many times before... but I'm not
convinced. I still think it falls over with the possibility of slicing, and
separate compilation.
The thing you're asking for is alignment of the base of the array, not
alignment of elements within the array or alignment of the dynamic array
structure its self.
Alignment of the base of the array isn't really expressible as part of the
type. It's just a request to the allocator.
I use a mallocAligned() function in C. Sadly, I think this is one of the
mistakes of a discreet 'new' operator, which has a syntax that doesn't lend
its self to arbitrary parameters.
Re: GPGPUs
On Fri, 2013-08-16 at 12:41 +0200, Paul Jurczak wrote: […] It seems to me that you are describing something similar to C++ AMP, which is a high level, language specific solution to GPGPU problem. C++ AMP may be an open specification but it only targets DirectX. But the ideas behind it are very sensible, use closures and internal iteration with library support to drive the compiler to construct the required kernels. Today you have to download the kernel to the attached GPGPU over the bus. In the near future the GPGPU will exist in a single memory address space shared with all the CPUs. At this point separately downloadable kernels become a thing of the past, it becomes a compiler/loader issue to get things right. -- 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: Have Win DMD use gmake instead of a separate DMMake makefile?
On 08/13/2013 12:48 AM, H. S. Teoh wrote: But you're missing the bigger picture. What I envision is that this D build tool will go beyond merely building DMD/druntime/Phobos. If it's successful, it can become the *standard* D build tool for all D programs. Having a standard D build tool will go a long way in making D programs portable and easy to install, besides freeing us from a dependency on make. Can I suggest then that you write such a tool _first and foremost_ as a build system for arbitrary D programs (or preferably, arbitrary programs without reference to the language...)? Then, if it gets uptake, proves a success, etc., we can consider whether it makes sense for the core D stuff. The thing is that at the end of the day, make may have its problems but it is a well understood tool that is readily accessible to many developers and across platforms. It also means that the build system is not dependent on one or two D hackers, who might fall under a bus, get a new job, whatever. I really don't see the benefits of accepting the maintenance burden for a custom build system, with all the potential bottlenecks that introduces, compared to focusing on the things that really matter -- frontend, runtime, and standard library.
Re: Ideas for a brand new widget toolkit
On Thursday, 15 August 2013 at 18:35:22 UTC, Joakim wrote: I've only done X11 forwarding over ssh, both WAN and LAN, it was incredibly laggy in both cases. As Andrei and I have pointed out, NX does a much better job of things. If nothing else, read the explanation of how it works-- there are perceptual subtleties to this that aren't apparent at first glance: http://www.nomachine.com/documents/NX-XProtocolCompression.php What is the latency or bandwidth threshold that X11 needs? They talk a bit about this in the above link, too. -Wyatt
Re: GPGPUs
On 08/16/2013 12:04 PM, Russel Winder wrote: I guess my question is whether people are interested in std.gpgpu (or some more sane name). Yes, I'd be interested, particularly if it's possible to produce a GPGPU solution that is much more user-friendly than the current C/C++ options. I think this could have a good deal of importance for scientific simulation and other similarly demanding computational tasks.
Re: Ideas for a brand new widget toolkit
On Thursday, 15 August 2013 at 18:52:21 UTC, H. S. Teoh wrote: You need to run ssh -C, otherwise it just goes uncompressed plus the overhead of encrypting/decrypting each packet. SSH compression is something of a worst-case scenario for compressing remote X traffic. As a fun aside, for X forwarding on LAN I find -c arcfour offers better performance. -C just slows things down. But yeah, it's not exactly fast. Definitely can't play FPS's over it. :) This... I was going to say it's pretty much impossible, but thinking about it, I'm not so sure. X forwarding uses indirect rendering, which has never given me good performance, but it MAY be possible on modern hardware with good bandwidth, clever compression, and client-side prediction (Something like Frankensteining NX, GGPO, VirtualGL, and ICER together?). Probably not for FPS, so much, but a lot of other semi-realtime applications. Fundamentally, you have to deal with getting a frame up inside of 33 milliseconds, however you do it, and input latency somewhere in the same apartment block as 50ms (else people hem and haw like you wouldn't believe). OnLive, for how they hilariously over-promised on infrastructural matters, looked to have some pretty interesting tech underneath; but they claim to have relied heavily on custom ASICs to pull it off. -Wyatt
Re: Ideas for a brand new widget toolkit
On Friday, 16 August 2013 at 07:19:09 UTC, Marek Janukowicz wrote: If we are discussing X's shortcomings: why don't we use something like http://wayland.freedesktop.org/ I don't have it installed on my computer! I do have X though. BTW, my minigui.d (previously crappygui.d) is moving along at a decent pace. Now has menus too, yay! I decided to use native widgets on Windows after all, when applicable. It looks better and automatically handles focus, hotkeys, etc. It still uses a simple automatic layout function though, so you just add children to the window and it figures out the sizes. On X though, I'm still doing it all myself, keeping it small (and fast on remote X! lol). So far, the minigui.d is 1100 lines long. I think I can do everything I want to do in between 2000 and 3000 lines. The test program on windows is 370 KB, no outside dependencies built with dmd, and the only modules it needs are my simpledisplay.d and color.d, though I might have it depend on eventloop later too. (It is about the same size using custom widgets too; calls to Rectangle() and LineTo(), via simpledisplay.d's ScreenPainter, aren't significantly bigger than calls to CreateWindow()). Anyway though, I'll probably post this to my github at some point over the weekend. There isn't much to it but IMO that's the best feature. The other D gui libs I've tried are all just too complex for me.
Re: Ideas for a brand new widget toolkit
On Thursday, 15 August 2013 at 20:09:34 UTC, Jonas Drewsen wrote: * SDL for input - would be awesome to get rid of this by using some of AdamRuppes work maybe. heh, I'm *almost* to the point where I can replace SDL for my own little games. I ported stb_truetype.h to D earlier in the week, I have some joystick input code and sound output code laying around, and once simpledisplay.d gets OpenGL context creation (probably tomorrow), that'll be almost everything I use there! Anyway though, as I write my minigui.d, I'm finally finishing simpledisplay.d's input events. (Previously, I only used that module as a quick image display thing, and the only events I was really interested in was basic click and key presses, 'a', 's', pressed, etc. But now I'm trying to write a little Text Edit control, so it needs a lot more detail.) Anyway, I'm fixing a lot of input bugs this weekend, so if you want to give simpledisplay.d a try next week, it might be useful to you then.
Re: Mixin overload sets
On Friday, 16 August 2013 at 07:48:52 UTC, QAston wrote:
You can put those functions into HasOtherMixins by using alias.
struct HasOtherMixins {
...
alias someMixin!int.abc abc;
alias someMixin!float.abc abc;
alias someOtherMixin abc;
}
Actually, that syntax only works for regular templates, not
mixins. Trying it with a mixin template gives an error. It's also
not very useful when mixing in several methods from the same
template.
However, the first solution I suggested could be expanded to
support that type of syntax:
struct HasMixins {
alias mixin someMixin!int.abc abc;
//etc.
}
I'm starting to lean toward the first option as the more
correct solution because it's more flexible and follows the
principle of least surprise. If it's decided that this would be
an acceptable addition to the language, I could try to cobble a
pull request together. I don't have any experience with the DMD
codebase, but it might be a good introductory project for me...
Tuple/TypeTuple etc.
Denis has been complaining about this for ages and I think it's worth doing something about. Definitions: std.typecons.Tuple A bit like python's tuples. It's a heterogeneous collection of runtime values with compile-time determined types. std.typetuple.TypeTuple A heterogeneous *compile-time* collection of types, expressions and aliases. Problems: TypeTuple isn't just a typetuple, it's an everythingtuple. It's a terrible name that is confusing to newcomers (and even to people who've used D a lot but not delved in to the CT capabilities so much). TypeTuple looks too much like Tuple. It's a totally different concept but the names are too similar. Possible solutions: 1) rename TypeTuple in-place to something better. This is not a real option as it would break far too much code. 2) Introduce a new tuple constructor with a new name, and deprecate TypeTuple 2a) A whole new module, leaving std.typetuple as effectively an alias to the new module. Denis has a pull for this[1], which also adds new tuple constructors specialised for expressions. I like Denis' pull request. It fixes the problem in a backwards compatible manner. However - as Jonathan points out in the comments - the naming is still a problem. GenericTuple, ExpressionTuple etc. all sound like they could be related to std.typecons.Tuple So, we need a new name: Sequence, ArgList or ParamList are possible suggestions. A possible complete path to getting this sorted, using Sequence as an example: 1) Create a new module like in Denis' PR, called std.sequence and containing the template Sequence, equivalent to current std.typetuple.TypeTuple 1a) optional: include specific templates like TypeSequence and ExpressionSequence. 2) Leave std.typetuple as an alias to the new module, including alias TypeTuple = Sequence; Deprecate it. 3) std.traits.isTypeTuple becomes isTypeSequence and isExpressionTuple becomes isExpressionSequence. Deprecated aliases from the old names are left for compatibility. 4) Change phobos over to using std.sequence (note that this is not required immediately, as there is 100% backwards compatibility). The only remaining headache would be people getting confused by dmd spewing out complaints about tuple(blah, blah, blah), but that's a relatively minor concern. P.S. please note that deprecating is not breaking, per se. Deprecations are just warnings by default. Also, although having compatibility aliases floating around is annoying, it's an unfortunate necessity if one wants to change things while not breaking everyone's code. I think it's a model we're going to have to get used to in order to be both flexible and reliable. [1] https://github.com/D-Programming-Language/phobos/pull/780
Can we get a forum section devoted to documentation?
I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate.
Re: Tuple/TypeTuple etc.
John Colvin:
Possible solutions:
My vote is for solution n.5:
Add the built-in t{} syntax to denote all kind of tuples.
Bye,
bearophile
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 16:08:42 UTC, bearophile wrote:
John Colvin:
Possible solutions:
My vote is for solution n.5:
Add the built-in t{} syntax to denote all kind of tuples.
This. With an exception of I don't care what syntax is.
There has been a thread in D.learn by Ali recently
http://forum.dlang.org/post/kuk8uc$30th$1...@digitalmars.com - it
pretty much highlights there we have plenty issues with the very
behavior of TypeTuple, not only naming.
I know we are very reluctant to do language changes but this
continues to do more and more damage to the language - it
requires extra costs to maintain Phobos properly, confuses
newcomers and complicates language specification itself as new
corner cases get attention.
What was the general attitude to http://wiki.dlang.org/DIP32 ?
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 16:08:42 UTC, bearophile wrote:
John Colvin:
Possible solutions:
My vote is for solution n.5:
Add the built-in t{} syntax to denote all kind of tuples.
Bye,
bearophile
There was no number 5...
A builtin syntax would be cool, I agree.
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate. I like this idea. Currently improving the docs is often blocked by the fact that only very few people for every different topic exist who know exactly what is the intended and proper behavior to be documented. And you mostly get that information only in some random bugzilla reports. Having a common place to discuss it can be a good foundation towards solid formal spec.
Re: Tuple/TypeTuple etc.
On Fri, Aug 16, 2013 at 06:08:36PM +0200, bearophile wrote:
John Colvin:
Possible solutions:
My vote is for solution n.5:
Add the built-in t{} syntax to denote all kind of tuples.
[...]
This can be part of the solution, but by itself is not good enough,
because the so-called typetuple and std.typecons.Tuple are NOT the
same thing. They are completely unrelated types, in fact incompatible
concepts, and we need some way to indicate that they aren't the same
thing. Otherwise they will continue to cause confusion.
The so-called typetuple (what dmd calls a tuple) is a compile-time
construct that can contain types, aliases, compile-time values, etc.,
that only exist at compile-time. On the contrary, std.typecons.Tuple is
a runtime object that contains a sequence of values stored in memory (it
has nothing to do with what dmd calls a tuple). The two are NOT the
same thing.
I think a good start is to call them by different names. The word
tuple is just too overloaded right now, and using the same term to
refer to two incompatible things is just formula for endless confusion.
Sequence is OK, but risks confusion with std.range.sequence. Is there
a better word for it? Maybe an acronym -- CTS (compile-time sequence)?
T
--
Guns don't kill people. Bullets do.
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate. Related: http://forum.dlang.org/post/bxqyiyohbodlxypxg...@forum.dlang.org
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate. It is pretty easy to make minor corrections to the documentation through the GitHub repo. I made such a correction myself to a glaring documentation error recently. My first ever open source contribution, but hopefully many more to come in the future. I often thought, like yourself, that improving the D documentation would be a good way to contribute. Having a forum to vet ideas would be very nice. I find the D documentation is sorely lacking in example code, and high level descriptions of modules (thinking more of Phobos here) and having a forum to say Here is some 'description/example code' I want to add to the Phobos docs, would be a good way for less experienced developers to start contributing. Such a forum would be a good way to get some feedback before getting to the point of pushing your changes to the Repo.
Re: Can we get a forum section devoted to documentation?
On 8/16/13 9:22 AM, Dicebot wrote: On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate. I like this idea. Currently improving the docs is often blocked by the fact that only very few people for every different topic exist who know exactly what is the intended and proper behavior to be documented. And you mostly get that information only in some random bugzilla reports. Having a common place to discuss it can be a good foundation towards solid formal spec. Just use this forum and plant e.g. [dox] in the title. Andrei
Re: Pointer alignments in the type system?
Manu: I'm not sure about the warning, it doesn't really sound right to me. Maybe it would be useful... or maybe it would be annoying. A cast is a cast, it is a deliberate act of reinterpretation... the user needs to take some responsibility in this case. OK. What happens if you do: int[16] a = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]; auto va = cast(int4[])a[1..$]; // ?? .. the offset breaks the alignment. (and now it's too short) If you use a[16..$] or a[32..$] then the compiler knows statically that the slice has kept the 16 bytes alignment. If you use a[i..$] where i is a run-time value, then the compiler assumes the worst, that a is aligned to 4 bytes. A kind of cast could be used to force the compiler assume a certain pointer/array has a certain alignment (better languages could allow you to write a proof of such alignment, but this is not possible in D, unless you add something like the Microsoft Z3 solver inside the compiler). Yes, kinda like I was saying above. It might be fine if you are explicit with align() statements, but whenever you are sharing pointers between link units, how can you ever retain the information the compiler needs? The title of this thread is Pointer alignments in the type system, that means that the static information of the alignment is kept with the type of the pointers/arrays (including dynamic arrays). In D you can use int[3] across link units because the length is part of the static information of the array. To make things back-ward compatible you need a don't know alignment, that is like the void* type for pointers, or maybe for the minimum alignment you could just use the natural alignment of the type. See some my successive posts for some examples. I think it's a mistake to make it work in some cases and not others. I agree. My proposal is to make them always work (unless you destroy the static information with a cast or a runtime-valued slicing). Runtime functions like idup etc are supposed to keep and transmit the alignment information. So for this reason, I maintain that the user just needs to take responsibility for their casts... In D we have a good static type system, unlike for example in Python2. One of the points of a static type system is to keep some static information, to use it to enforce certain invariants statically, and avoid some bugs and offer performance. SIMD programming works more efficiently with certain alignments. In my opinion it's not too much hard to retain such alignment information and avoid certain bugs statically, and produce fast code. Having a static type system and not using it is a waste. This means this a will has a standard aliment of 16: auto a = new int[128]; static assert(__traits(alignment, a) == 16); this b has a statically knwn alignment of 4: auto b = a[i .. $]; static assert(__traits(alignment, b) == 4); auto b2 = cast(align(16))b; static assert(__traits(alignment, b2) == 16); This c has a statically known alignment of 16: auto c = a.dup; static assert(__traits(alignment, c) == 16); auto d = new align(32) int[128]; // A possible syntax. static assert(__traits(alignment, d) == 32); // Other possible syntax: auto d2 = new int[128] align(32); auto d3 = new int[128]32; auto e = d[64..$]; static assert(__traits(alignment, e) == 32); align(32) int[128] f; static assert(__traits(alignment, f) == 32); Bye, bearophile
Re: Can we get a forum section devoted to documentation?
On Fri, Aug 16, 2013 at 06:29:40PM +0200, Craig Dillabaugh wrote: On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. +1. I would like for there to be a section were people interested in working on the docs can collaborate. +1. I would subscribe to that. It is pretty easy to make minor corrections to the documentation through the GitHub repo. I made such a correction myself to a glaring documentation error recently. My first ever open source contribution, but hopefully many more to come in the future. I often thought, like yourself, that improving the D documentation would be a good way to contribute. Having a forum to vet ideas would be very nice. We badly, badly, need people to work on the documentation. One of the major complaints I heard from a friend about D is that the docs are very poor. Coders tend to be very bad at writing docs, because we understand our own code too well -- our perception is unconsciously colored by hidden assumptions that newbies don't know about, which makes the docs hard to understand. Writing docs for others' code is better, though. :) I find the D documentation is sorely lacking in example code, +1. I think *every* Phobos function needs at least one code example, at least in principle. It may sound redundant to experienced D coders, but such redundancy is very important for somebody who's learning the language for the first time. and high level descriptions of modules (thinking more of Phobos here) Most Phobos modules suffer from this problem. The first paragraph often just says something to the effect of this is module X (we already know that) and it contains Y, Z, W (we can see that already). Very unhelpful. We need descriptions of: 1) What: what this module does -- from the high-level view. 2) Why: why do we need this module in the first place? why should we care? 3) When: when this module might be useful. Give some example applications that might benefit from this module. 4) How: example code to demonstrate how this module can help you in your code. 5) Where: overview of module contents (or, where to find stuff). A lot of Phobos docs currently just dump a long unnavigable list of symbols declared, with no high-level organization of them. This makes it nigh impossible to find what you're looking for unless you already know where it is. We should at least group things into logical sections / categories, and put these categories near the top where it's easier to find what you're looking for (std.range, while not perfect, is a good example of how this can help navigate the module). and having a forum to say Here is some 'description/example code' I want to add to the Phobos docs, would be a good way for less experienced developers to start contributing. Such a forum would be a good way to get some feedback before getting to the point of pushing your changes to the Repo. +1. You can also just submit pull requests to update the docs; it's a good way to get feedback from the core Phobos devs. A large number of Phobos modules badly need a documentation facelift. I've tried to improve std.range before -- I can't say it's perfect but it's certainly a lot better than what it used to be. But too many Phobos modules aren't even at that level yet. We really need to fix that if we want wider adoption of D. Also needed is somebody to read through related parts of the docs, and catch contradictory parts (e.g., the terminology confusion between http://dlang.org/tuple.html, http://dlang.org/phobos/std_typecons.html, and http://dlang.org/phobos/std_typetuple.html). In any case, I think I talk too much about it. Let's get the documentation pull requests going!! And start the docs discussion group. T -- The early bird gets the worm. Moral: ewww...
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 16:36:16 UTC, Andrei Alexandrescu wrote: Just use this forum and plant e.g. [dox] in the title. Andrei Why prefer less structured and inconvenient approach to an organized one? :) digitalmars.D is not that quite these days and discussing formal spec definitions sounds like an important goal, worth dedicated forum block.
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 16:53:47 UTC, H. S. Teoh wrote: +1. /snip s/\+1/\+2/ to everything. Might encourage me to get back to my own doc stuff. -Wyatt
Re: Can we get a forum section devoted to documentation?
On 8/16/13 10:12 AM, Dicebot wrote: On Friday, 16 August 2013 at 16:36:16 UTC, Andrei Alexandrescu wrote: Just use this forum and plant e.g. [dox] in the title. Andrei Why prefer less structured and inconvenient approach to an organized one? :) digitalmars.D is not that quite these days and discussing formal spec definitions sounds like an important goal, worth dedicated forum block. The converse risk is balkanization. We already have subgroups that are effectively dead, for which similar arguments were made in the past. Andrei
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate. It would be perfect to get D version of http://www.dotnetperls.com/
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 17:41:19 UTC, Andrei Alexandrescu wrote: The converse risk is balkanization. We already have subgroups that are effectively dead, for which similar arguments were made in the past. Problem with current subgroups is that they are created on topic basis, not to solve some specific problems. Such groups become useless once person who is the driving force behind the relevant project stops using it. I'd probably favor deleting such obsolete groups (dtl, dwt, debugger?) but it is a different topic. Documentation group has clear target audience (newcomers with questions/proposals about the spec + ones willing to contribute to dlang.org) and very specific problem to solve (most non-trivial documentation changes are impossible without prior discussion). In that sense I think bugzilla is a more appropriate place for such discussions but it is not as visible and newbie-friendly as forum group.
Re: Can we get a forum section devoted to documentation?
On 8/16/13 10:56 AM, Dicebot wrote: On Friday, 16 August 2013 at 17:41:19 UTC, Andrei Alexandrescu wrote: The converse risk is balkanization. We already have subgroups that are effectively dead, for which similar arguments were made in the past. Problem with current subgroups is that they are created on topic basis, not to solve some specific problems. Such groups become useless once person who is the driving force behind the relevant project stops using it. I'd probably favor deleting such obsolete groups (dtl, dwt, debugger?) but it is a different topic. Documentation group has clear target audience (newcomers with questions/proposals about the spec + ones willing to contribute to dlang.org) and very specific problem to solve (most non-trivial documentation changes are impossible without prior discussion). The argument is built from a mistaken angle. Thinking of doing some work on docs in the future, let's create a group for docs! Things should happen organically, i.e. creating a specialized group should follow a need substantiated by increased volume of specialized discussion in the general group. At this point there is nothing in that vein. Andrei
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 16:28:29 UTC, H. S. Teoh wrote: I think a good start is to call them by different names. The word tuple is just too overloaded right now, and using the same term to refer to two incompatible things is just formula for endless confusion. Sequence is OK, but risks confusion with std.range.sequence. Is there a better word for it? Maybe an acronym -- CTS (compile-time sequence)? T Typetuple allows random access to elements, so maybe array is better than sequence. Compile-Time annotation is very nice as it explicitly states the usage and capabilities of the construct. Also - the acronym is already known thanks to CT-FE.
Re: Tuple/TypeTuple etc.
On 08/16/2013 09:27 AM, H. S. Teoh wrote: The so-called typetuple (what dmd calls a tuple) is a compile-time construct that can contain types, aliases, compile-time values, etc., that only exist at compile-time. They are all symbols, right? And symbols live only at compile time. ... Sequence is OK, but risks confusion with std.range.sequence. Is there a better word for it? Maybe an acronym -- CTS (compile-time sequence)? SymbolTuple it is! :) Ali
Re: Can we get a forum section devoted to documentation? [dox]
H. S. Teoh wrote: Most Phobos modules suffer from this problem. The first paragraph often just says something to the effect of this is module X (we already know that) and it contains Y, Z, W (we can see that already). Very unhelpful. We need descriptions of: 1) What: what this module does -- from the high-level view. 2) Why: why do we need this module in the first place? why should we care? 3) When: when this module might be useful. Give some example applications that might benefit from this module. 4) How: example code to demonstrate how this module can help you in your code. 5) Where: overview of module contents (or, where to find stuff). A lot of Phobos docs currently just dump a long unnavigable list of symbols declared, with no high-level organization of them. This makes it nigh impossible to find what you're looking for unless you already know where it is. We should at least group things into logical sections / categories, and put these categories near the top where it's easier to find what you're looking for (std.range, while not perfect, is a good example of how this can help navigate the module). These are all excellent suggestions. I believe that adopting this approach would improve the usability immensely. Is there a way to break the pages into a more of a hierarchy, so that documentation for each module doesn't have to be on one page? Perhaps a DDOC Section could indicate the category? Getting into working on the documentation seems to not be as easy as it ought to be. I am talking about the macro system, which is easy enough to grok once you have seen enough examples of it, but there is a shortage of guidance for the noob. I think a good place to start is with the creation of a README file on GitHub. This file should at the very least: - Explain how the documentation source is organized, i.e. dependency on Phobos, etc. - What the different make targets are, and * what tools are required to build each target, * a link to where to find each tool - Point to a page explaining a little about DDOC. - What the vetting process is - Where to discuss or propose ideas for additions or changes - A link to content guidelines based on what H. S. Teoh listed above.
Re: Tuple/TypeTuple etc.
On Fri, Aug 16, 2013 at 11:10:28AM -0700, Ali Çehreli wrote: On 08/16/2013 09:27 AM, H. S. Teoh wrote: The so-called typetuple (what dmd calls a tuple) is a compile-time construct that can contain types, aliases, compile-time values, etc., that only exist at compile-time. They are all symbols, right? And symbols live only at compile time. ... Sequence is OK, but risks confusion with std.range.sequence. Is there a better word for it? Maybe an acronym -- CTS (compile-time sequence)? SymbolTuple it is! :) [...] +1, I like this! I still don't like the use of tuple, but I think symbol makes it abundantly clear what these things are. I vote for SymbolTuple. T -- Живёшь только однажды.
Re: Can we get a forum section devoted to documentation? [dox]
On Friday, 16 August 2013 at 18:09:04 UTC, Andrei Alexandrescu wrote: On 8/16/13 10:56 AM, Dicebot wrote: On Friday, 16 August 2013 at 17:41:19 UTC, Andrei Alexandrescu wrote: The converse risk is balkanization. We already have subgroups that are effectively dead, for which similar arguments were made in the past. Problem with current subgroups is that they are created on topic basis, not to solve some specific problems. Such groups become useless once person who is the driving force behind the relevant project stops using it. I'd probably favor deleting such obsolete groups (dtl, dwt, debugger?) but it is a different topic. Documentation group has clear target audience (newcomers with questions/proposals about the spec + ones willing to contribute to dlang.org) and very specific problem to solve (most non-trivial documentation changes are impossible without prior discussion). The argument is built from a mistaken angle. Thinking of doing some work on docs in the future, let's create a group for docs! Things should happen organically, i.e. creating a specialized group should follow a need substantiated by increased volume of specialized discussion in the general group. At this point there is nothing in that vein. Andrei I understand were you are coming from. And, while I currently feel that it's a bit of a catch-22 situation, I think it is worth at least trying out your suggestion of marking document related threads with [dox].
Re: Tuple/TypeTuple etc.
On 08/16/2013 11:21 AM, H. S. Teoh wrote: On Fri, Aug 16, 2013 at 11:10:28AM -0700, Ali Çehreli wrote: On 08/16/2013 09:27 AM, H. S. Teoh wrote: The so-called typetuple (what dmd calls a tuple) is a compile-time construct that can contain types, aliases, compile-time values, etc., that only exist at compile-time. They are all symbols, right? And symbols live only at compile time. ... Sequence is OK, but risks confusion with std.range.sequence. Is there a better word for it? Maybe an acronym -- CTS (compile-time sequence)? SymbolTuple it is! :) [...] +1, I like this! I still don't like the use of tuple, Same here: tuple is confusing. :/ I also thought about SymbolList but then it doesn't go well with random accessing its elements. but I think symbol makes it abundantly clear what these things are. I vote for SymbolTuple. Me too! :p Ali
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 16:28:29 UTC, H. S. Teoh wrote: This can be part of the solution, but by itself is not good enough, because the so-called typetuple and std.typecons. Key point is that having proper built-in syntax for type/expression tuples obsoletes the need in TypeTuple and it can be deprecated completely.
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 18:10:29 UTC, Ali Çehreli wrote: On 08/16/2013 09:27 AM, H. S. Teoh wrote: The so-called typetuple (what dmd calls a tuple) is a compile-time construct that can contain types, aliases, compile-time values, etc., that only exist at compile-time. They are all symbols, right? And symbols live only at compile time. Not really. At least as far as my understanding goes, for example, integer literals are not symbols. Symbols usually uniquely identify something (and are possibly emitted to object files) and this is not the case for compile-time tuple elements. Symbols are most closely related to `alias` parameters (it does have inconsistencies of its own though).
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 18:09:04 UTC, Andrei Alexandrescu wrote: The argument is built from a mistaken angle. Thinking of doing some work on docs in the future, let's create a group for docs! Things should happen organically, i.e. creating a specialized group should follow a need substantiated by increased volume of specialized discussion in the general group. At this point there is nothing in that vein. That is a good point.
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 16:19:51 UTC, Dicebot wrote:
Add the built-in t{} syntax to denote all kind of tuples.
This. With an exception of I don't care what syntax is.
/snip
What was the general attitude to http://wiki.dlang.org/DIP32 ?
I don't like the t. I'd prefer just using parentheses, but I
think there were readability problems that caused the DIP to end
up with:
Basic () syntax, perhaps the cleanest, but can't be used:
Though there's nothing else written about that.
The DIP itself, though, looks pretty good.
-Wyatt
Re: Can we get a forum section devoted to documentation? [dox]
On 8/16/13 10:56 AM, Dicebot wrote: it. I'd probably favor deleting such obsolete groups (dtl, dwt, debugger?) but it is a different topic. Archive, don't delete. On Friday, 16 August 2013 at 18:25:02 UTC, Andre Artus wrote: I understand were you are coming from. And, while I currently feel that it's a bit of a catch-22 situation, I think it is worth at least trying out your suggestion of marking document related threads with [dox]. For the future, the convention of most mailing lists I've seen is to put the braced tag at the front so you know what it's about immediately. :) -Wyatt
[dox] Fixing the lexical rule for BinaryInteger
The documentation on the lexical rules for BinaryInteger (http://dlang.org/lex.html#BinaryInteger) has a few issues: BinaryInteger: BinPrefix BinaryDigits The nonterminal BinaryDigits, does not exist. BinaryDigitsUS: BinaryDigitUS BinaryDigitUS BinaryDigitsUS The construction for BinaryDigitsUS currently allows for the following: _(_)*, e.g. 0b_, 0b__, 0b___ etc. Which is clearly not allowed by the compiler. I have put up a change on GitHub [1], but there is a clear problem. The DMD compiler allows for any of the following (reduced cases): a. 0b__1 b. 0b_1_ c. 0b1__ Whereas my change disallows the second case (b), but is in line with how the other integers are specified. This is a specification problem (limitation of BNF), not an implementation problem. In plain English one would just say that the BinaryDigitsUS sequence should contain at least one BinaryDigit character. I'm busy working on the HexadecimalInteger, which has related issues. 1. https://github.com/andre-artus/dlang.org/blob/LexBinaryDigit/lex.dd
[dox] Fixes to HexadecimalInteger and other issues spawing from HexLetter
In the documentation (http://dlang.org/lex.html#HexadecimalInteger) as it currently stands the HexLetter is specified as including the underscore, which in a strict interpretation means that the following escape sequences are allowed: \x__ (from \x HexDigit HexDigit) \u (from \u HexDigit HexDigit HexDigit HexDigit) \U (from \U etc.) I have changed this and also specified HexDigitUS as it was left out. You can find the changes on my GitHub repo, here: https://github.com/andre-artus/dlang.org/commit/291c2742b0a779d3aa6b678ceb0273e9aa82d8f9 It has the same issue as BinaryInteger in that it does not allow the first and last character to be an underscore.
Re: Can we get a forum section devoted to documentation? [dox]
On Friday, 16 August 2013 at 18:12:57 UTC, Andre Artus wrote: Is there a way to break the pages into a more of a hierarchy, so that documentation for each module doesn't have to be on one page? Perhaps a DDOC Section could indicate the category? Are you familiar with DDOX? http://vibed.org/temp/d-programming-language.org/phobos/index.html
Re: Tuple/TypeTuple etc.
On Friday, August 16, 2013 18:08:36 bearophile wrote:
John Colvin:
Possible solutions:
My vote is for solution n.5:
Add the built-in t{} syntax to denote all kind of tuples.
Since the built-in tuples / std.typetuple.TypeTuple and std.typecons.Tuple
are fundamentally different, I don't see how you could possibly combine the two
in a single syntax. You'd need different syntaxes for each one.
- Jonathan M Davis
Re: Request for editor scripting help
OK, I got dotComplete working in Vim, but I can't get the parenComplete calltips. Which cursor position should I give? The left-paren? The last character of the function name? Right after the left-paren? I can't seem to get any to work...
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 19:19:19 UTC, Jonathan M Davis wrote: Since the built-in tuples / std.typetuple.TypeTuple and std.typecons.Tuple are fundamentally different, I don't see how you could possibly combine the two in a single syntax. You'd need different syntaxes for each one. The fact that std.typetuple.TypeTuple and built-in ones are different is most inconvenient thing in all this situation. They should be the same and TypeTuple removed as redundant.
Re: Can we get a forum section devoted to documentation? [dox]
On Friday, 16 August 2013 at 19:12:46 UTC, Mr. Anonymous wrote: On Friday, 16 August 2013 at 18:12:57 UTC, Andre Artus wrote: Is there a way to break the pages into a more of a hierarchy, so that documentation for each module doesn't have to be on one page? Perhaps a DDOC Section could indicate the category? Are you familiar with DDOX? http://vibed.org/temp/d-programming-language.org/phobos/index.html I have not yet had the time to look into it, but I fear that it would be of little use if it's not the official way of doing docs. Although it may be the preferred option for private projects or projects not directly connected to the main D ecosystem. There is already quite a lot of fragmentation making it quite an effort to find out what the one true path[1] is. 1. I realize that there isn't truly such a thing, but an opinionated starting point is of great help to noobs. The major feature to popularize Ruby on Rails when it first kicked off was, in my opinion, the on rails part. You had a very clear indication of where to start, and what the best/accepted/expected practices are. Once you have accustomed yourself to the language and framework you can find ways to go crashing through the bushes if you feel the need to do so.
Re: Can we get a forum section devoted to documentation?
On Friday, August 16, 2013 10:41:19 Andrei Alexandrescu wrote: The converse risk is balkanization. We already have subgroups that are effectively dead, for which similar arguments were made in the past. Plus, if one of the main complaints with regards to the documentation is that only a few people know the correct behavior for each of the various items which need to be documented, splitting off into your own group where those people probably won't even be isn't very helpful. - Jonathan M Davis
Re: Can we get a forum section devoted to documentation? [dox]
On Friday, 16 August 2013 at 18:41:57 UTC, Wyatt wrote: On 8/16/13 10:56 AM, Dicebot wrote: it. I'd probably favor deleting such obsolete groups (dtl, dwt, debugger?) but it is a different topic. Archive, don't delete. On Friday, 16 August 2013 at 18:25:02 UTC, Andre Artus wrote: I understand were you are coming from. And, while I currently feel that it's a bit of a catch-22 situation, I think it is worth at least trying out your suggestion of marking document related threads with [dox]. For the future, the convention of most mailing lists I've seen is to put the braced tag at the front so you know what it's about immediately. :) -Wyatt Duly noted. I have done so in my subsequent posts (which are waiting for comments, hint, hint)
Re: Can we get a forum section devoted to documentation? [dox]
On Friday, 16 August 2013 at 19:27:58 UTC, Andre Artus wrote: On Friday, 16 August 2013 at 19:12:46 UTC, Mr. Anonymous wrote: On Friday, 16 August 2013 at 18:12:57 UTC, Andre Artus wrote: Is there a way to break the pages into a more of a hierarchy, so that documentation for each module doesn't have to be on one page? Perhaps a DDOC Section could indicate the category? Are you familiar with DDOX? http://vibed.org/temp/d-programming-language.org/phobos/index.html I have not yet had the time to look into it, but I fear that it would be of little use if it's not the official way of doing docs. Although it may be the preferred option for private projects or projects not directly connected to the main D ecosystem. There is already quite a lot of fragmentation making it quite an effort to find out what the one true path[1] is. 1. I realize that there isn't truly such a thing, but an opinionated starting point is of great help to noobs. The major feature to popularize Ruby on Rails when it first kicked off was, in my opinion, the on rails part. You had a very clear indication of where to start, and what the best/accepted/expected practices are. Once you have accustomed yourself to the language and framework you can find ways to go crashing through the bushes if you feel the need to do so. It's planned as the official way of doing docs. There are pull request for it, but it's going nowhere for the past several months. A related thread: http://forum.dlang.org/thread/dsnpggjmndaxiusfq...@forum.dlang.org
Re: Tuple/TypeTuple etc.
On Friday, August 16, 2013 21:23:26 Dicebot wrote: On Friday, 16 August 2013 at 19:19:19 UTC, Jonathan M Davis wrote: Since the built-in tuples / std.typetuple.TypeTuple and std.typecons.Tuple are fundamentally different, I don't see how you could possibly combine the two in a single syntax. You'd need different syntaxes for each one. The fact that std.typetuple.TypeTuple and built-in ones are different is most inconvenient thing in all this situation. They should be the same and TypeTuple removed as redundant. But TypeTuple and the built-in ones _aren't_ different. TypeTuple is an alias for the built-in ones that's required because of the lack of syntax for declaring them on their own. TypeTuple could just have easily been called BuiltInTuple (and would probably have been better named as such, even though that name isn't exactly great). It's std.typecons.Tuple which is different. Adding a syntax for TypeTuple, making TypeTuple redundant would be great, but Bearophile seems to be arguing that having some sort of tuple syntax would make it so that we don't need TypeTuple and Tuple, which is wrong, because they're different. If you're creating a new syntax in the language for one of them, you only get rid of the need for one of them in the library, not both. The idea of a universal tuple (like Bearophile seems to be looking for) makes no sense given the differences between the built-in tuples and Tuple. - Jonathan M Davis
Re: Request for editor scripting help
On Friday, 16 August 2013 at 19:21:53 UTC, Idan Arye wrote: OK, I got dotComplete working in Vim, but I can't get the parenComplete calltips. Which cursor position should I give? The left-paren? The last character of the function name? Right after the left-paren? I can't seem to get any to work... It should work if you call it when the cursor is directly after the left paren.
Re: GPGPUs
On Friday, 16 August 2013 at 12:18:49 UTC, Russel Winder wrote: On Fri, 2013-08-16 at 12:41 +0200, Paul Jurczak wrote: […] Today you have to download the kernel to the attached GPGPU over the bus. In the near future the GPGPU will exist in a single memory address space shared with all the CPUs. At this point separately downloadable kernels become a thing of the past, it becomes a compiler/loader issue to get things right. I'm iffy on the assumption that the future holds unified memory for heterogeneous devices. Even relatively recent products such as the Intel Xeon Phi have totally separate memory. I'm not aware of any general-computation-oriented products that don't have separate memory. I'm also of the opinion that as long as people want to have devices that can scale in size, there will be modular devices. Because they're modular, there's some sort of a spacing between them and the machine, ex. PCIe (and, somewhat importantly, a physical distance between the added device and the CPU-stuff). Because of that, they're likely to have their own memory. Therefore, I'm personally not willing to bank on anything short of targeting the least common denominator here (non-uniform access memory) specifically because it looks like a necessity for scaling a physical collection of heterogeneous devices up in size, which in turn I *think* is a necessity for people trying to deal with growing data sets in the real world. Add because heterogeneous compute devices aren't *just* GPUs (ex. Intel Xeon Phi), I'd strongly suggest picking a more general name, like 'accelerators' or 'apu' (except AMD totally ran away with that acronym in marketing and I sort of hate them for it) or 'something-I-can't-think-of-because-words-are-hard'. That said, I'm no expert, so go ahead and rip 'mah opinions apart. :-D
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 19:29:46 UTC, Jonathan M Davis wrote: On Friday, August 16, 2013 10:41:19 Andrei Alexandrescu wrote: The converse risk is balkanization. We already have subgroups that are effectively dead, for which similar arguments were made in the past. Plus, if one of the main complaints with regards to the documentation is that only a few people know the correct behavior for each of the various items which need to be documented, splitting off into your own group where those people probably won't even be isn't very helpful. - Jonathan M Davis It is disheartening to think that the people with potential for the most valuable contributions or insight will be avoiding discussions regarding the documentation. But I fear you are correct. I have admittedly not been around here for long, but haven't seen too many discussions focused on documentation (other than to bemoan/defend DDOC, which in itself seems not to do much towards improving the actual documentation). I have proposed a changes to the documentation before but it's obviously less interesting than the optimal way to decelerate an automobile. English is not my mother tongue, and I am not always confident that I have expressed myself in the manner I intended. It's difficult to make sure that one does not just directly translate idiomatic expressions from your mother tongue that don't make sense to others. I'm happy to follow the convention proposed by Andrei. Although I fear it lacks discoverability for newcomers. Perhaps over time we can build enough interest in the documentation to warrant a more focused approach.
Re: GPGPUs
The core (!) point here is that processor chips are rapidly
becoming a
collection of heterogeneous cores. Any programming language
that assumes
a single CPU or a collection of homogeneous CPUs has built-in
obsolescence.
So the question I am interested in is whether D is the language
that can
allow me to express in a single codebase a program in which
parts will
be executed on one or more GPGPUs and parts on multiple CPUs. D
has
support for the latter, std.parallelism and std.concurrency.
I guess my question is whether people are interested in
std.gpgpu (or
some more sane name).
CUDA, works as a preprocessor pass that generates c files from
.cu extension files.
In effect, to create a sensible environment for microthreaded
programming, they extend the language.
a basic CUDA function looking something like...
__global__ void add( float * a, float * b, float * c) {
int i = threadIdx.x;
c[i] = a[i] + b[i];
}
add 1, 10 ( ptrA, ptrB, ptrC );
Their is the buildin variables to handle the index location
threadIdx.x in the above example, this is something generated by
the thread scheduler in the video card/apu device.
Generally calls to this setup has a very high latency, so using
this for a small handful of items as in the above example makes
no sense. In the above example that would end up using a single
execution cluster, and leave you prey to the latency of the pcie
bus, execution time, and latency costs of the video memory.
it doesn't get effective until you are working with large data
sets, that can take advantage of a massive number of threads
where the latency problems would be secondary to the sheer
calculations done.
as far as D goes, we really only have one build in microthreading
capable language construct, foreach.
However I don't think a library extension similar to
std.parallelism would work gpu based microthreading.
foreach would need to have something to tell the compiler to
generate gpu bytecode for the code block it uses, and would need
instructions on when to use said code block based on dataset size.
while it is completely possible to have very little change with
function just add new property @microthreaded and the build in
variables for the index position/s, the calling syntax would need
changes to support a work range or multidimensional range of some
sort.
perhaps looking something like
add$(1 .. 10)(ptrA,ptrB,ptrC);
a templated function looking similar
add!(float)$(1 .. 10)(ptrA,ptrB,ptrC);
[dox] List of Phobos documentation improvement candidates (Was: Re: Can we get a forum section devoted to documentation? [dox])
On Fri, Aug 16, 2013 at 08:25:00PM +0200, Andre Artus wrote: On Friday, 16 August 2013 at 18:09:04 UTC, Andrei Alexandrescu wrote: [...] Things should happen organically, i.e. creating a specialized group should follow a need substantiated by increased volume of specialized discussion in the general group. At this point there is nothing in that vein. [...] I understand were you are coming from. And, while I currently feel that it's a bit of a catch-22 situation, I think it is worth at least trying out your suggestion of marking document related threads with [dox]. Alright, I'll start. Here's a list of Phobos modules that need some documentation facelist. For fairness' sake, I gleaned these from: http://dlang.org/phobos-prerelease/index.html as opposed to the docs for the official release, so that they closer reflect what things will look like at the next D release. 1) The above page itself needs work. Right now it's just a very spotty incomplete list of seemingly-random pieces of Phobos. It looks like the relic from a bygone era before Phobos docs had a navbar on the left; so my first thought would be to kill off that incomplete module list (leave that to the navbar). My second thought would be to group the modules under more logical categories so that newbies would know which modules tend to be used together (e.g., std.algorithm and std.range tend to be used together a lot IME). 2) std.algorithm: the state of the current docs is not bad, but could use some improvement. The first paragraph could be expanded to explain what this module is all about. The part about string lambdas (2nd paragraph) may need to be tagged with a note about possible deprecation, judging from discussions in the other thread. If not, at the very least the code example should show how to use the new lambda syntax: sort!((a,b) = a b)(...); I'm not sure what to make of the cheat sheet, as it seems to repeat most of the table of links at the top of the page. But maybe it's good for short code snippets to remind you how to use each function, so maybe it can be left alone for now. 3) std.array: desperately needs a more detailed explanation at the top to explain why this module is even needed (newbies would wonder: doesn't D have built-in arrays? Why do we need this module then?). Not enough code examples. 4) std.ascii: unhelpful description. Why do we even need this module when D uses UTF-8 by default? When should we use this module and when should we use std.uni? Also, needs an overview of what this module provides (string constants, character categorization, case conversions). 5) std.base64: unhelpful description. Doesn't explain what is base-64 and why we should care. What are the applications of base-64 anyway? Who would want to use this stuff? Without more details, a newcomer wouldn't know. 6) std.bigint: badly needs more code examples, with explanations. 7) std.bitmanip: needs more explanation about what this module is, why we need it, etc.. Needs categorization of what is provided (bitfields, endianness-related functions, anything else). 8) std.compiler: need code examples of how to use the stuff here. Maybe using version blocks. Maybe sample music composed in D_major... oh wait. Wrong forum. :-P 9) std.complex: needs more code examples. Maybe a little more explanation about what's going on with built-in types and why those will be replaced. 10) std.concurrency: needs higher-level module description, like what's the use of low-level messaging systems. Need to provide adequate context for where/when this module should be used. Needs to link to other doc pages that discuss threads, processes, etc.. 11) std.container: badly needs a better description. The table of operations with complexity guarantees needs a bit more explanation about what this all means. Maybe a link to somewhere (wikipedia perhaps) that explains the concept of complexity and why it matters. Also, need an overview of what containers are provided and example code on how to use them. 12) std.conv: the one-line description is cute, but inadequate. Need code examples on common usage. Need to explain in more detail how to make user-defined types usable with to!() (e.g., need to define opCast, ctor requirements, etc.). Need module overview about what's provided (to, octal, parse, emplace). Need code examples. 13) std.csv: Not bad, but could use an overview of module contents with links to each main function/struct (ala std.algorithm / std.range). 14) std.datetime: Not bad. It would be nice to add links to actual functions/types in the module overview. 15) std.encoding: needs more code examples. Overview of module contents. 16) std.exception: needs higher-level overview of what's in this module, with categorized functions/types. Code examples for assertThrown co., as well as explanations of why we need them. 17) std.file: needs more code examples. Module contents overview. 18) std.format: there are a lot of good
Re: [dox] Fixing the lexical rule for BinaryInteger
I've been doing some work with the language grammar specification. You may find these resources useful: http://d.puremagic.com/issues/show_bug.cgi?id=10233 https://github.com/Hackerpilot/DGrammar/blob/master/D.g4
Re: GPGPUs
On Friday, 16 August 2013 at 19:55:56 UTC, luminousone wrote:
The core (!) point here is that processor chips are rapidly
becoming a
collection of heterogeneous cores. Any programming language
that assumes
a single CPU or a collection of homogeneous CPUs has built-in
obsolescence.
So the question I am interested in is whether D is the
language that can
allow me to express in a single codebase a program in which
parts will
be executed on one or more GPGPUs and parts on multiple CPUs.
D has
support for the latter, std.parallelism and std.concurrency.
I guess my question is whether people are interested in
std.gpgpu (or
some more sane name).
CUDA, works as a preprocessor pass that generates c files from
.cu extension files.
In effect, to create a sensible environment for microthreaded
programming, they extend the language.
a basic CUDA function looking something like...
__global__ void add( float * a, float * b, float * c) {
int i = threadIdx.x;
c[i] = a[i] + b[i];
}
add 1, 10 ( ptrA, ptrB, ptrC );
Their is the buildin variables to handle the index location
threadIdx.x in the above example, this is something generated
by the thread scheduler in the video card/apu device.
Generally calls to this setup has a very high latency, so using
this for a small handful of items as in the above example makes
no sense. In the above example that would end up using a single
execution cluster, and leave you prey to the latency of the
pcie bus, execution time, and latency costs of the video memory.
it doesn't get effective until you are working with large data
sets, that can take advantage of a massive number of threads
where the latency problems would be secondary to the sheer
calculations done.
as far as D goes, we really only have one build in
microthreading capable language construct, foreach.
However I don't think a library extension similar to
std.parallelism would work gpu based microthreading.
foreach would need to have something to tell the compiler to
generate gpu bytecode for the code block it uses, and would
need instructions on when to use said code block based on
dataset size.
while it is completely possible to have very little change with
function just add new property @microthreaded and the build in
variables for the index position/s, the calling syntax would
need changes to support a work range or multidimensional range
of some sort.
perhaps looking something like
add$(1 .. 10)(ptrA,ptrB,ptrC);
a templated function looking similar
add!(float)$(1 .. 10)(ptrA,ptrB,ptrC);
We have a[] = b[] * c[] - 5; etc. which could work very neatly
perhaps?
Re: Can we get a forum section devoted to documentation?
On Friday, August 16, 2013 21:57:01 Andre Artus wrote: It is disheartening to think that the people with potential for the most valuable contributions or insight will be avoiding discussions regarding the documentation. But I fear you are correct. There's a difference between avoiding discussions and searching after them. If a discussion occurs in a list that they're already subscribed to, they're a lot more likely to read it and contribute to it than they are to go and subscribe to yet another list. - Jonathan M Davis
Re: Tuple/TypeTuple etc.
On Fri, Aug 16, 2013 at 03:35:40PM -0400, Jonathan M Davis wrote: [...] Adding a syntax for TypeTuple, making TypeTuple redundant would be great, but Bearophile seems to be arguing that having some sort of tuple syntax would make it so that we don't need TypeTuple and Tuple, which is wrong, because they're different. If you're creating a new syntax in the language for one of them, you only get rid of the need for one of them in the library, not both. The idea of a universal tuple (like Bearophile seems to be looking for) makes no sense given the differences between the built-in tuples and Tuple. [...] This is why I don't like the term tuple. It's using a single word to describe apples and oranges. It gives you the wrong idea that there's some kind of underlying, unifying thing common to both, but there isn't! We really need to start using different terms to refer to them, otherwise the confusion will only continue. If I could roll back time, I'd rename std.range.Tuple to std.range.AnonStruct, because that's what it is -- an anonymous struct that you put together on-the-spot by stringing a bunch of values together. It has nothing to do with what DMD calls a tuple (except that compile-time tuples, or CT-tuples, are used to implement it, but that's an irrelevant implementational detail). But I don't have a time machine, sad to say, and there's also precedent for tuple in other languages in relation to what std.range.Tuple does, so I'm expecting tuple will stick in this case. Which leaves the compile-time thingies in need of a new, DIFFERENT name. Ali's suggestion, SymbolTuple, is nice, but still has that dreaded tuple in it, which still suggests some kind of conflation with std.range.Tuple. I think we should avoid any name containing tuple for these things. What about SymbolList? (maybe TypeList, but it's misleading because it isn't restricted to types alone; plus I want to avoid sequence in order to prevent the same confusion with std.range.sequence). Or maybe we should call them tuplets with a T (as in quintuplet). Or compile-time tuplets (CT-tuplets), to distinguish them from Tuples. The diminutive -t ending being a reference to the fact that they are compile-time-only constructs, hence not full-fledged Tuples. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 17:45:35 UTC, Suliman wrote: On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate. It would be perfect to get D version of http://www.dotnetperls.com/ That's pretty cool. It would be good to have something like that for D, or a Ninety-Nine D Problems, or a Try-D, or an update to http://en.wikibooks.org/wiki/D. I'm wiling to work towards those goals. There are a number of good articles and other D materials strewn around the web, perhaps we can find place to include or link to them from dlang.org.
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 19:35:56 UTC, Jonathan M Davis wrote: But TypeTuple and the built-in ones _aren't_ different. TypeTuple is an alias for the built-in ones that's required because of the lack of syntax for declaring them on their own. That is intention but not implementation. There some cases where you can simply enumerate stuff via comma but can't use TypeTuple. There are cases where you can use TypeTuple but can't express the same thing with any built-in syntax. Recent discoveries on topic in bugzilla and digitalmars.learn have really frustrated me and I have considered myself somewhat experienced D user. Adding a syntax for TypeTuple, making TypeTuple redundant would be great, but Bearophile seems to be arguing that having some sort of tuple syntax would make it so that we don't need TypeTuple and Tuple.. Does he? I missed that from his comments. bearophile, is that true? :) std.typecons.Tuple should be left untouched, of course, because it serves important goal - constructing a type (as module name suggests), something that can be used in ABI realm. It can make use of better integration with built-in tuples but it is a distinct topic.
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 20:22:49 UTC, H. S. Teoh wrote: ... Term tuple comes from math and means ordered set of elements. In that sense anonymous struct with unnamed fields _is_ a tuple and I thing std.typecons.Tuple is the place where naming is fine. It is re-using the term for compile-time entity of the language that causes confusion. While it matches the mathematical definition of tuple too, its practical meaning for language is much more than that and naming should express it.
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 20:12:20 UTC, Jonathan M Davis wrote: On Friday, August 16, 2013 21:57:01 Andre Artus wrote: It is disheartening to think that the people with potential for the most valuable contributions or insight will be avoiding discussions regarding the documentation. But I fear you are correct. There's a difference between avoiding discussions and searching after them. If a discussion occurs in a list that they're already subscribed to, they're a lot more likely to read it and contribute to it than they are to go and subscribe to yet another list. - Jonathan M Davis I am using the web interface to the forums, so I must admit I did not think how other users may need to jump through additional hoops. I was thinking about it in the fashion of how web-based forums normally operate, were a separate section could advance discoverability, but I can see how this can be counterproductive given a significant number of email only users.
Re: Tuple/TypeTuple etc.
I was just thinking about the whole Tuple situation today. I think I might write up a quick, somewhat-related post. As for TypeTuple, I agree that it is not a good name at all for what it does. It confused me endlessly when I first started learning D. There are still corner cases where it's not at all obvious what's going on. See Ali's thread in D.Learn about assigning a TypeTuple to an enum. Things got weird. I think in Andrei's Modern C++ book there was a similar concept called Type Lists. That's still not a great name, as TypeTuple can contain more than just types. Maybe ExpressionList/ExprList?
Re: Can we get a forum section devoted to documentation?
On Fri, Aug 16, 2013 at 04:12:11PM -0400, Jonathan M Davis wrote: On Friday, August 16, 2013 21:57:01 Andre Artus wrote: It is disheartening to think that the people with potential for the most valuable contributions or insight will be avoiding discussions regarding the documentation. But I fear you are correct. There's a difference between avoiding discussions and searching after them. If a discussion occurs in a list that they're already subscribed to, they're a lot more likely to read it and contribute to it than they are to go and subscribe to yet another list. [...] Good point. Though I have to say, actually reading Phobos code to figure out what it does is actually much less scary than it sounds. It's orders of magnitude better than, say, reading the source code of Glibc. Thanks to D's superior syntax and other readability features, Phobos code actually reads like normal application code for the most part. It's not that hard to understand at all. I can't say the same for things like Glibc (or ncurses -- I tried reading that once and my eyes bled). And when that fails (there are some places where it isn't obvious what the code is doing), there's always the copy-paste-modify method: copy Phobos code into a temporary file, wrap a main() around it, and run it yourself to see what it does. Again thanks to D's readability and modularity features, for the most part this will actually work painlessly. In fact, you can even copy, say, std.algorithm.find into /tmp/test.d, then import std.algorithm at the top so that any subfunctions or subtemplates that it calls will automatically resolve back to the Phobos code, but when main() calls find(), your copy of find() gets used instead because the local module gets higher preference when resolving overloads. Then you can modify your copy of find() to your heart's content and observe what it does, etc.. Man I love D... Try doing that with glibc or ncurses code, for example, and ... well, let's just say you *don't* want to try this at home, you may be scarred for life. :-P T -- Let X be the set not defined by this sentence...
Re: Tuple/TypeTuple etc.
On Friday, August 16, 2013 22:30:11 Dicebot wrote: On Friday, 16 August 2013 at 20:22:49 UTC, H. S. Teoh wrote: ... Term tuple comes from math and means ordered set of elements. In that sense anonymous struct with unnamed fields _is_ a tuple and I thing std.typecons.Tuple is the place where naming is fine. It is re-using the term for compile-time entity of the language that causes confusion. While it matches the mathematical definition of tuple too, its practical meaning for language is much more than that and naming should express it. In addition, the built-in tuples are not at all what most programmers think about when they think about tuples. Tuples are supposed to be nestable, whereas the built-in tuples are always flat. So, if anything, it's calling the built-in tuples tuples which is the problem. Sequence seems to be a semi- popular suggestion for a better term whenever it comes up, but that poses its own set of difficulties. - Jonathan M Davis
Re: Can we get a forum section devoted to documentation?
On Fri, Aug 16, 2013 at 10:24:55PM +0200, Andre Artus wrote: On Friday, 16 August 2013 at 17:45:35 UTC, Suliman wrote: On Friday, 16 August 2013 at 16:07:59 UTC, Andre Artus wrote: I would like to contribute to the D ecosystem, but as I'm still in the learning process I do not want to get my sticky fingers all over someones nice clean code. I have poured over the documentation and see that there are a few low-hanging fruit that I would like to pluck. So I have decided to do so. I would like for there to be a section were people interested in working on the docs can collaborate. It would be perfect to get D version of http://www.dotnetperls.com/ That's pretty cool. It would be good to have something like that for D, or a Ninety-Nine D Problems, or a Try-D, or an update to http://en.wikibooks.org/wiki/D. I'm wiling to work towards those goals. There are a number of good articles and other D materials strewn around the web, perhaps we can find place to include or link to them from dlang.org. I think wiki.dlang.org is a good place to put little gems like this. It allows easy community effort to edit, and serves as a central place for people to go when they want to find example D code for a particular task. Vladimir has been very kind to offer hosting for wiki.dlang.org, so let's make use of it. T -- Век живи - век учись. А дураком помрёшь.
Re: Can we get a forum section devoted to documentation?
On Friday, 16 August 2013 at 20:12:20 UTC, Jonathan M Davis wrote: On Friday, August 16, 2013 21:57:01 Andre Artus wrote: It is disheartening to think that the people with potential for the most valuable contributions or insight will be avoiding discussions regarding the documentation. But I fear you are correct. There's a difference between avoiding discussions and searching after them. If a discussion occurs in a list that they're already subscribed to, they're a lot more likely to read it and contribute to it than they are to go and subscribe to yet another list. - Jonathan M Davis I just noticed when posting my previous reply to you that it connected to an NNTP server (I normally context switch on anything that takes more than a fraction of a second, so I have not seen it before). So I guess that many forum users interface via a newsreader. That's seriously old-school.
Re: Tuple/TypeTuple etc.
On 08/16/2013 01:38 PM, Meta wrote: See Ali's thread in D.Learn about assigning a TypeTuple to an enum. I think it was captaindet's enum and tuples thread that was specifically about enum and TypeTuple: http://forum.dlang.org/post/ku21fk$oqc$1...@digitalmars.com Ali
Re: Can we get a forum section devoted to documentation?
On Fri, Aug 16, 2013 at 10:52:11PM +0200, Andre Artus wrote: [...] I just noticed when posting my previous reply to you that it connected to an NNTP server (I normally context switch on anything that takes more than a fraction of a second, so I have not seen it before). So I guess that many forum users interface via a newsreader. That's seriously old-school. Actually, there are several things going on here: the forums themselves are hosted on NNTP servers, but IIRC very few members actually use NNTP directly. Instead, some proportion use the SMTP mailing list gateway (which runs mailman, which has a long-unfixed issue which sometimes rewrites the wrong message IDs, causing threads to break), and others use the web interface on dlang.org. But you know what's *really* old-school? IPv4, which was drafted in 1981. And a large segment of the internet still uses it. :) (And that's in spite of doomsday predictions about IPv4 address space exhaustion -- IPv6 adoption is still slow in many parts of the world in spite of the address exhaustion having already taken place.) T -- Frank disagreement binds closer than feigned agreement.
A Discussion of Tuple Syntax
Awhile ago Kenji posted this excellent dip
(http://wiki.dlang.org/DIP32) that aimed to improve tuple syntax,
and described several cases in which tuples could be
destructured. You can see his original thread here:
http://forum.dlang.org/thread/mailman.372.1364547485.4724.digitalmar...@puremagic.com,
and further discussion in this thread:
http://forum.dlang.org/thread/dofwinzpbcdwkvhzc...@forum.dlang.org.
It seemed that there was a lot of interest in having syntax
somewhat like what is described in Kenji's DIP, but it didn't
really go anywhere. There is this pull on Github
(https://github.com/D-Programming-Language/dmd/pull/341), but it
uses the (a, b) syntax, which has too much overlap with other
language constructs. Andrei/Walter didn't want to merge that pull
request without a full consideration of the different design
issues involved, which in retrospect was a good decision.
That said, I'd like to open the discussion on tuple syntax yet
again. Tuples are currently sorely underused in D, due in large
part to being difficult to understand and awkward to use. One
large barrier to entry is that fact that D has not 1, not 2, but
3 different types of tuples (depending on how you look at it),
which are difficult to keep straight.
There is std.typecons.Tuple, which is fundamentally different
from std.typecons.TypeTuple in that it's implemented as a struct,
while TypeTuple is just a template wrapped around the compiler
tuple type. ExpressionTuples are really just TypeTuples that
contain only values, and aren't mentioned anywhere except for in
this article: http://dlang.org/tuple.html, which frankly creates
more confusion than clarity.
A good, comprehensive design has the potential to make tuples
easy to use and understand, and hopefully clear up the unpleasant
situation we have currently. A summary of what has been discussed
so far:
- (a, b) is the prettiest syntax, and it also completely
infeasible
- {a, b} is not as pretty, but it's not that bad of an
alternative (though it may still have issues as well)
- #(a, b) is unambiguous and would probably be the easiest
option. I don't think it looks too bad, but some people might
find it ugly and noisy
- How should tuples be expanded? There is the precedent of an
expand() method of std.typecons.Tuple, but Kenji liked tup[]
(slicing syntax). So with a tuple of #(1, a, 0.0), tup[0..2]
would be an expanded tuple containing 1 and a. On the other
hand, Bearophile and Timon Gehr preferred that slicing a tuple
create another closed tuple, and to use expand() for expansion.
So tup[] would create a copy of the tuple, and tup[0..2] would
create a closed tuple eqvivalent to #(1, a). I don't have any
particular preference in that regard.
- Timon Gehr wanted the ability to swap tuple values, so #(x, y)
= #(y, x) would be allowed. Kenji was against it, saying that it
would introduce too many complications.
- There was no consensus on the pattern matching syntax for
unpacking. For example, #(a, _) = #(1, 2) only introduces one
binding, a, into the surrounding scope. The question is, what
character should go in the place of _ to signify that a value
should not be bound? Some suggestions were #(a, $), #(a, @), #(a,
?). I personally think #(a, ?) or #(a, *) would be best, but all
that's really necessary is a symbol that cannot also be an
identifier.
Also up for debate was nested patterns, e.g., #(1, 2, #(3, 4,
#(5, 6))). I don't think there was a consensus on unpacking and
pattern matching for this situation. One idea I saw that looked
good:
* Use ... to pattern match on the tail of an
expressions, so take the above tuple. The pattern #(1, ?, ...)
would match the two nested sub-tuples. Or, say, #(1, 2, 3) could
be matched by #(1, 2, 3), #(1, ?, 3), #(1, ...), etc. You
obviously can't refer to ... as a variable, so it also becomes
a useful way of saying don't care for multiple items, e.g.,
#(a, ...) - only bind the first item in the tuple. We can play
around with this to get a few other useful constructs, such as
#(a, ..., b) - match first and last, #(..., b) - match last,
etc.
Assuming the ... syntax for unpacking, it would be useful to
name the captured tail. For example, you could unpack #(1, 3,
#(4, 6)) into #(a, b, x...), where a = 1, b = 3, x = #(4, 6).
Similarly, #(head, rest...) results in head = 1, rest = #(2, #(4,
6)). I think this would be very useful.
- Concatenating tuples with ~. This is nice to have, but not
particularly important.
One thing that I think was overlooked, but would be pretty cool,
is that a tuple unpacking/pattern matching syntax would allow us
to unpack/pattern match just about anything that you can make a
tuple of in D. Combine this with the .tupleof property, and
things get interesting... Maybe. There is one possible problem:
.tupleof returns a TypeTuple, and it's not at all clear to me
how, if at all, TypeTuple would work with the proposed
Re: Tuple/TypeTuple etc.
On Friday, 16 August 2013 at 20:56:49 UTC, Ali Çehreli wrote: On 08/16/2013 01:38 PM, Meta wrote: See Ali's thread in D.Learn about assigning a TypeTuple to an enum. I think it was captaindet's enum and tuples thread that was specifically about enum and TypeTuple: http://forum.dlang.org/post/ku21fk$oqc$1...@digitalmars.com Ali Ah, sorry, my mistake. I thought you had that thread for some reason. I'm probably thinking of something else.
Re: Tuple/TypeTuple etc.
On 08/16/2013 02:11 PM, Meta wrote: On Friday, 16 August 2013 at 20:56:49 UTC, Ali Çehreli wrote: I think it was captaindet's enum and tuples thread that was specifically about enum and TypeTuple: http://forum.dlang.org/post/ku21fk$oqc$1...@digitalmars.com Ali Ah, sorry, my mistake. I thought you had that thread for some reason. No, that's ok. That thread taught me a lot about TypeTuples. :) Ali
