Re: Revamp of CandyDOC
On 2012-04-12 22:53, Jonas Drewsen wrote: The outline and package panes should be combined IMHO. Perhaps something like (ascii art): --- + atk Component --- MyClass getStruct contains ... ... FooClass setBar ... --- Where clicking on atk would show all atk packages. Clicking on + show all packages etc. The lower section is simply showing the currenly selected package. /Jonas That would list all packages and all symbols in the current module? I think the list can be quite long as it currently is. Adding all the packages as well will make it even longer. -- /Jacob Carlborg
Re: dmd 1.074 and 2.059 release
On 04/12/2012 10:53 PM, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. And UFCS really works! :) FibonacciSerisi().take(5).cycle().take(20).writeln(); I have to update some chapters... ;) Ali
Re: dmd 1.074 and 2.059 release
On Thu, 12 Apr 2012 23:35:40 -0700 Ali Çehreli acehr...@yahoo.com wrote: I have to update some chapters... ;) Oh noes...when we'll get new ones. :-) Sincerely, Gour -- Those who are on this path are resolute in purpose, and their aim is one. O beloved child of the Kurus, the intelligence of those who are irresolute is many-branched. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: dmd 1.074 and 2.059 release
2.059 is red I'm drunk too It's friday night thank you too ... Not sure if that means I should drink more or less. Gonna go with more, my spelling is way to good.
Re: dmd 1.074 and 2.059 release
On Friday, 13 April 2012 at 08:02:09 UTC, Bernard Helyer wrote: 2.059 is red I'm drunk too It's friday night thank you too ... Not sure if that means I should drink more or less. Gonna go with more, my spelling is way to good. Well nopw I' m more drunk. 2.059 is workfing fine. :D GOOD JOIB WALTER! :D And evweryone else. Kenji especially.
Re: Native GTK bindings v2
Le dimanche 01 avril 2012 à 21:23 +0200, Artur Skawina a écrit :
What's new?
- Now, in addition to
GLib, GModule, GObject, Gio, GdkPixbuf, Pango, PangoCairo, PangoFT, Gdk,
Atk and Gtk+
there are also bindings for
Clutter, ClutterX11, Cogl, CoglPango and Mx.
- Struct inheritance. No more need for container.add(vbox.widget);, you
can
write that as just container.add(vbox);, the compiler will do all the
work
to check if the 'vbox' is somehow derived from 'widget', and convert the
pointer by itself.
This works not only for struct Widget {}; struct VBox { Widget widget;
... };,
but also for struct Widget {}; struct VBox { Widget* widget; ... };.
You can extend built-in widgets and still use them with the std APIs.
- Objects can now be constructed as gtk.VBox(0, 0);
the old way, ie gtk.VBox.new_(0, 0); still works.
- All methods that take a (char*) pointer now also silently accept D strings;
casting to (char*) and/or calling toStringz are no longer necessary. It
will
be done implicitly every time you try to pass a D string; you can still
pass
a (char*) to avoid the copy.
- GTK (GObject) interfaces supported.
- Better error messages when registering signal callbacks (the messages
given by
the compiler when a template instantiation fails are not very helpful and,
as
it typically happens via several alias levels, were often just confusing).
- Some 64-bit fixes (I don't have a 64-bit GTK stack ATM, so there could be
more problems around).
- The pre-generated D modules were built using newer library versions
(still GTK2, only the glib version is newer than that).
- New examples: Clutter and Mx. Trivial, but enough to get you started.
A D GTK app now looks like this:
http://repo.or.cz/w/girtod.git/blob/refs/heads/master:/example_gtk.d
doesn't need a single cast (other than for skipping the string copies, using
(void*) library APIs and object lookup tricks, all of which could be avoided,
but I intentionally didn't do this in the example), looks much better than
the equivalent C version would and couldn't be done any more efficiently in C
(assuming same compiler middle/backend and ignoring the string differences, as
for most cases these don't matter. The convenience makes up for the few extra
copies and these can be avoided in every case where performance really
matters).
The code is here: http://repo.or.cz/w/girtod.git
The easiest way to try the bindings is probably to check out the gtk2
branch,
copy the gtk2 directory to your app directory and import from there.
The girtod tool used to generate the D modules lives in the master branch.
When used with different lib versions than the ones I tried it on, it may need
a few tweaks; sometimes new types appear or move between the libs, new weird
or
broken introspection data shows up etc.
artur
PS. Are there any sane Cairo D binding out there? (What's sane? Well, if
there's a class in there somewhere then it's not sane)
why use your library instead https://github.com/gtkd-developers/GtkD
why do not contribute to this project?
Re: Dscience
Le samedi 10 mars 2012 à 22:46 +0100, george a écrit : On Friday, 2 March 2012 at 12:27:06 UTC, bioinfornatics wrote: Dear, I have do a D 2 port to my dscience project: https://gitorious.org/dscience/dscience Any help are welcome It would be interesting if you would hook up with the guys at Open Bioinformatics Foundation (http://www.open-bio.org/wiki/Main_Page) and if your project migrated to Github. :) In first sorry for delay i was not seen your message. Yes i can move to github. I had choose gitoriouse bbecause he is near to github but it is full open source not github. If you are always ok i can do the move
Re: Dscience
Le lundi 12 mars 2012 à 18:42 +0100, Paul D. Anderson a écrit : On Friday, 2 March 2012 at 12:27:06 UTC, bioinfornatics wrote: Dear, I have do a D 2 port to my dscience project: https://gitorious.org/dscience/dscience Any help are welcome I'm willing to help but I've got a couple of other things I need to get out the door first. But I will take a look and see if there is some low-hanging fruit that I can work on. Paul In first sorry for delay i was not seen your message. I am open to add any work. Thanks for your help
Re: dmd 1.074 and 2.059 release
On 2012-04-13 10:02, Bernard Helyer wrote: 2.059 is red I'm drunk too It's friday night thank you too ... Not sure if that means I should drink more or less. Gonna go with more, my spelling is way to good. The answer to that question is always more :) -- /Jacob Carlborg
Re: Video: Walter Bright D at Lang.NEXT 2012
On 04/12/2012 01:04 AM, Walter Bright wrote: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The-D-Programming-Language and on Reddit: http://www.reddit.com/r/programming/comments/s5492/the_d_programming_language_walter_bright_langnext/ DMD actually implements pure as 'no reading or writing of mutable free variables' instead of 'no reading or writing of mutable static variables'. Is that going to change?
Re: dmd 1.074 and 2.059 release
On Friday, 13 April 2012 at 05:54:26 UTC, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Great news! Congrats to everyone involved! You should update the Downloads Tools page so I can mark DMD as out-of-date on the Arch Linux repo.
Re: dmd 1.074 and 2.059 release
On 13-04-2012 07:53, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Hooray! *Waits for .debs...* -- - Alex
Re: Revamp of CandyDOC
Hi! Thanks for the feedback, I'll have a go at fixing the problems. As for IE issues, I only tested it with IE9. As for the older IE versions, well, developers are the target users of the documentation. And they are usually tech savvy people so I would expect that they use reasonably up to date browsers. It would be nice if at least it functions correctly in IE8, but I don't have it on my machine. Is there a way to test it without installing it on the system(I don't want it to replace IE9 basically)? On Wednesday, 11 April 2012 at 22:34:40 UTC, Andrej Mitrovic wrote: Also: Not jumping to the Outline pane every time a different package is selected (OR it should memorize the position of the scrollbar). This is especially annoying in e.g. gtkd: http://gtkd.mikewey.eu/src/cairo/Surface.html Whenever I click on another package it jumps to the outline view, and if I go back I can't figure out where I was because the scrollbar resets. Yeah, that's annoying indeed. I will implement ajax partial reloading of the document content. That will preserve the state of the left pane.
Re: dmd 1.074 and 2.059 release
Strive to make toHash, toString, opEquals and opCmp functions pure, nothrow, const and @safe. Soon, this will become a requirement. man, that's a lot of decorations. This kind of thing makes me thing we should have opposites: impure, maythrow, mutable, and @system. And virtual, while I'm at it. Then it might be a lil easier to just go module lots.of.decorations; pure: const: @safe: nothrow: and undecorate as needed. We seem to be moving in this kind of direction.
Re: dmd 1.074 and 2.059 release
On Friday, 13 April 2012 at 05:54:26 UTC, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Please also make a tag on the Github tools repo so I can update the Arch package.
Re: dmd 1.074 and 2.059 release
On 4/13/12, Walter Bright newshou...@digitalmars.com wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/2.0/changelog.html Damn. One could spend a good hour or so reading the bug fixes. Awesome. Does anyone have a comparison to the previous release? E.g. how many bugs were fixed vs newly opened.
Re: dmd 1.074 and 2.059 release
On 13-04-2012 18:47, Adam D. Ruppe wrote: Strive to make toHash, toString, opEquals and opCmp functions pure, nothrow, const and @safe. Soon, this will become a requirement. man, that's a lot of decorations. This kind of thing makes me thing we should have opposites: impure, maythrow, mutable, and @system. And virtual, while I'm at it. Then it might be a lil easier to just go module lots.of.decorations; pure: const: @safe: nothrow: and undecorate as needed. We seem to be moving in this kind of direction. I agree wholeheartedly... -- - Alex
Re: Revamp of CandyDOC
On 13/04/2012 17:41, Eldar Insafutdinov wrote: It would be nice if at least it functions correctly in IE8, but I don't have it on my machine. Is there a way to test it without installing it on the system(I don't want it to replace IE9 basically)? http://browsershots.org/ - Just check the browsers you want to test with. Of course it needs to be a world visible site for this to work. (There's a select none option at the bottom after all the checkboxes) -- Robert http://octarineparrot.com/
Re: Revamp of CandyDOC
It would be nice if at least it functions correctly in IE8, but I don't have it on my machine. Is there a way to test it without installing it on the system(I don't want it to replace IE9 basically)? http://utilu.com/IECollection/
Re: Revamp of CandyDOC
On Friday, 13 April 2012 at 06:26:27 UTC, Jacob Carlborg wrote: On 2012-04-12 22:53, Jonas Drewsen wrote: The outline and package panes should be combined IMHO. Perhaps something like (ascii art): --- + atk Component --- MyClass getStruct contains ... ... FooClass setBar ... --- Where clicking on atk would show all atk packages. Clicking on + show all packages etc. The lower section is simply showing the currenly selected package. /Jonas That would list all packages and all symbols in the current module? I think the list can be quite long as it currently is. Adding all the packages as well will make it even longer. It would only list the path to the package that the current module is in (top part of the listview). Each package name in the path is clickable. If a package name is clicked the bottom part of the listview will show the available modules and subpackages of that package. The top part is updated to show the path to the clicked package only. If a module is clicked the its content is listed in the bottom part of the list and the top part of the list includes the module name in the path. Since the style of D is to have flat hierarchies the top part of the view would probably have path with a max of three package names. May the can even be collapsed from: packA packB packC to packA.packB.packB in order to take up less space. Hope it makes sense. /Jonas
Re: Revamp of CandyDOC
On 2012-04-13 18:41, Eldar Insafutdinov wrote: Hi! Thanks for the feedback, I'll have a go at fixing the problems. As for IE issues, I only tested it with IE9. As for the older IE versions, well, developers are the target users of the documentation. And they are usually tech savvy people so I would expect that they use reasonably up to date browsers. It would be nice if at least it functions correctly in IE8, but I don't have it on my machine. Is there a way to test it without installing it on the system(I don't want it to replace IE9 basically)? Microsoft provides Virtual Box images with different version of IE installed: http://www.microsoft.com/download/en/details.aspx?displaylang=enid=11575 -- /Jacob Carlborg
Re: Video: Walter Bright D at Lang.NEXT 2012
On 4/13/2012 7:25 AM, Timon Gehr wrote: On 04/12/2012 01:04 AM, Walter Bright wrote: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The-D-Programming-Language and on Reddit: http://www.reddit.com/r/programming/comments/s5492/the_d_programming_language_walter_bright_langnext/ DMD actually implements pure as 'no reading or writing of mutable free variables' instead of 'no reading or writing of mutable static variables'. Is that going to change? no
Re: dmd 1.074 and 2.059 release
Adam D. Ruppe destructiona...@gmail.com wrote in message news:oznqhjdcwecwmjmyc...@forum.dlang.org... Strive to make toHash, toString, opEquals and opCmp functions pure, nothrow, const and @safe. Soon, this will become a requirement. man, that's a lot of decorations. Must be time for a party! This kind of thing makes me thing we should have opposites: impure, maythrow, mutable, and @system. And virtual, while I'm at it. My bikeshed is painted: !pure !nothrow !const Then it might be a lil easier to just go module lots.of.decorations; pure: const: @safe: nothrow: and undecorate as needed. We seem to be moving in this kind of direction. I like it.
Re: dmd 1.074 and 2.059 release
On 13/04/2012 22:10, Nick Sabalausky wrote: !nothrow nonothrow. May as well drop nothrow and use !throw if we're doing that! -- Robert http://octarineparrot.com/
Re: dmd 1.074 and 2.059 release
On 4/14/12, Robert Clipsham rob...@octarineparrot.com wrote: On 13/04/2012 22:10, Nick Sabalausky wrote: !nothrow nonothrow. May as well drop nothrow and use !throw if we're doing that! Might as well rename it to something else. It's called nothrow, but it can actually throw a Throwable, but not an Exception. Quite an odd naming if you ask me.
Re: dmd 1.074 and 2.059 release
On 13/04/2012 23:30, Andrej Mitrovic wrote: On 4/14/12, Robert Clipshamrob...@octarineparrot.com wrote: On 13/04/2012 22:10, Nick Sabalausky wrote: !nothrow nonothrow. May as well drop nothrow and use !throw if we're doing that! Might as well rename it to something else. It's called nothrow, but it can actually throw a Throwable, but not an Exception. Quite an odd naming if you ask me. It can't throw a Throwable, just an error! Maybe we should introduce a maybe keyword! void myFunc() pure @maybe !throw @maybe !const; Maybe @maybe needs to be negateable too... void myFunc() !@maybe pure @maybe !throw @maybe !const; -- Robert http://octarineparrot.com/
Re: dmd 1.074 and 2.059 release
On 4/14/12, Robert Clipsham rob...@octarineparrot.com wrote:
It can't throw a Throwable
Well now I'm confused. According to TDPL p307:
nothrow promises that the function won't throw an Exception. The
function is still allowed to throw the graver Throwable class.
And yet this is an error:
nothrow void foo() {
throw new Throwable();
}
void main() { }
test.d(6): Error: object.Throwable is thrown but not caught
test.d(4): Error: function test.foo 'foo' is nothrow yet may throw
So who is the outlier here?
Re: dmd 1.074 and 2.059 release
On 14-04-2012 01:49, Andrej Mitrovic wrote:
On 4/14/12, Robert Clipshamrob...@octarineparrot.com wrote:
It can't throw a Throwable
Well now I'm confused. According to TDPL p307:
nothrow promises that the function won't throw an Exception. The
function is still allowed to throw the graver Throwable class.
And yet this is an error:
nothrow void foo() {
throw new Throwable();
}
void main() { }
test.d(6): Error: object.Throwable is thrown but not caught
test.d(4): Error: function test.foo 'foo' is nothrow yet may throw
So who is the outlier here?
That sounds like an error in TDPL. AFAIK nothrow means may only throw
Error.
--
- Alex
Re: dmd 1.074 and 2.059 release
On 4/12/2012 10:53 PM, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Changelogs, deb files, and http://dlang.org/download.html are all updated now.
Re: dmd 1.074 and 2.059 release
On 4/14/12, Alex Rønne Petersen xtzgzo...@gmail.com wrote: That sounds like an error in TDPL. AFAIK nothrow means may only throw Error. But Error is a subclass of Throwable.
Re: dmd 1.074 and 2.059 release
On Saturday, April 14, 2012 02:13:45 Andrej Mitrovic wrote: On 4/14/12, Alex Rønne Petersen xtzgzo...@gmail.com wrote: That sounds like an error in TDPL. AFAIK nothrow means may only throw Error. But Error is a subclass of Throwable. A nothrow function cannot throw anything derived from Exception. It _can_ throw types derived from Error. Normally, no one should be using exception types which aren't derived from Exception or Error. So, this should be a complete non-issue. It looks like TDPL lists Throwable as throwable in nothrow functions (so, basically any Throwable which is _not_ derived from Exception), whereas the compiler specifically makes Error throwable but disallows throwing Throwable. Honestly, it probably doesn't really matter which it is. Certainly, it won't matter in good code, since I'm pretty sure there's no valid reason for throwing anything which is not derived from Exception or Error. But clearly TDPL and the compiler need to be brought in line with one another (either by changing TDPL or changing the compiler). I'd be inclined to go with TDPL on this one, but I don't see how it matters all that much, since it shouldn't impact any real world code either way. - Jonathan M Davis
Re: dmd 1.074 and 2.059 release
On Friday, 13 April 2012 at 05:54:26 UTC, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Not Found The requested URL /dmd.2.059.dmg was not found on this server. Can I play too please.
Re: dmd 1.074 and 2.059 release
This program doesn't work.
import std.stdio;
void main() {
writeln(1);
}
I get this:
C:\jpro\dpro2\smalldmd dmd59.d
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
dmd59.obj(dmd59)
Error 42: Symbol Undefined _D3std3utf6toUTF8FNaNbNfJG4awZAa
--- errorlevel 1
C:\jpro\dpro2\small_
Is it to do with qualifiers?
Thanks for any help.
-joelcnz
Re: dmd 1.074 and 2.059 release
Never mind, I installed wrong, I was still was using 58's lib files. -joelcnz
Re: dmd 1.074 and 2.059 release
On 04/13/2012 05:47 PM, Tyro[17] wrote: On Friday, 13 April 2012 at 05:54:26 UTC, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Not Found The requested URL /dmd.2.059.dmg was not found on this server. Can I play too please. The 64-bit .deb file worked fine on my Ubuntu system: http://dlang.org/download.html Ali
Re: dmd 1.074 and 2.059 release
On 4/13/2012 5:47 PM, Tyro[17] wrote: The requested URL /dmd.2.059.dmg was not found on this server. Hmm, I overlooked that one.
Re: dmd 1.074 and 2.059 release
On 14-04-2012 02:13, Andrej Mitrovic wrote: On 4/14/12, Alex Rønne Petersenxtzgzo...@gmail.com wrote: That sounds like an error in TDPL. AFAIK nothrow means may only throw Error. But Error is a subclass of Throwable. Which is why I said it's probably an error in TDPL. :P -- - Alex
Re: dmd 1.074 and 2.059 release
On 14-04-2012 03:45, Alex Rønne Petersen wrote: On 14-04-2012 02:13, Andrej Mitrovic wrote: On 4/14/12, Alex Rønne Petersenxtzgzo...@gmail.com wrote: That sounds like an error in TDPL. AFAIK nothrow means may only throw Error. But Error is a subclass of Throwable. Which is why I said it's probably an error in TDPL. :P I.e. nothrow specifically lets you throw anything deriving from Error, nothing else. Anywhere else, you can throw whatever derives from Throwable. -- - Alex
Re: dmd 1.074 and 2.059 release
Gah, I just ruined by night by actually trying to use this release. 78 lines of template instantiation error spam on code that worked perfectly on 2.058 :( Including such gems as: .../phobos/std/conv.d(244): Error: template std.conv.toImpl does not match any function template declaration and .../phobos/std/conv.d(244): Error: template std.conv.toImpl matches more than one template declaration, /home/me/d/dmd2/linux/bin32/../../src/phobos/std/conv.d(1034):toImpl(T,S) if (!isImplicitlyConvertible!(S,T) is(S == enum) isSomeString!(T)) and /home/me/d/dmd2/linux/bin32/../../src/phobos/std/conv.d(1155):toImpl(T,S) if (isIntegral!(S) isSigned!(S) isSomeString!(T)) and .../phobos/std/conv.d(244): Error: template std.conv.toImpl does not match any function template declaration They all seem to be enum - string related. std.conv rox, but it is one very fragile baby :( It breaks often, and is always a pain to figure out why.
Re: dmd 1.074 and 2.059 release
On 4/13/2012 7:24 PM, Adam D. Ruppe wrote: Gah, I just ruined by night by actually trying to use this release. Sorry about that, but the beta has been out for a week and a half, and we fixed every reported regression since 2.058. The best I can suggest is to file a bug report and we'll try to figure out what went wrong.
Re: dmd 1.074 and 2.059 release
On Fri, Apr 13, 2012 at 12:53 AM, Walter Bright newshou...@digitalmars.com wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Awesome. Thanks for all the hard work guys. P.S. I just noticed the 'Fork D on Github' on the download page; The red looks sexy.
Re: Video: Walter Bright D at Lang.NEXT 2012
On Wednesday, 11 April 2012 at 23:05:20 UTC, Walter Bright wrote: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The-D-Programming-Language and on Reddit: http://www.reddit.com/r/programming/comments/s5492/the_d_programming_language_walter_bright_langnext/ :) So if I got this timeline right in Native Panel Herb unintentionally takes a jab at D trying to keep the dynamic languages happy by saying, and it is a mistake [...], that one tool is can subsume the other. -16:10 context at 13:45 Then the next day, you're presenting D wanting to cover Modeling Power, Modern Convenience (programer productivity) and efficiency. Both your's and Andrei's presentations were great and suplemented each other nicely. I think Andrei did better at going over the syntax used to describe things, but I think there is some expectation people won't be wanting to know every detail about the language (well, except that they did as there was a question for each unique part of the syntax)
Re: dmd 1.074 and 2.059 release
On Saturday, 14 April 2012 at 01:23:14 UTC, Ali Çehreli wrote: On 04/13/2012 05:47 PM, Tyro[17] wrote: On Friday, 13 April 2012 at 05:54:26 UTC, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Not Found The requested URL /dmd.2.059.dmg was not found on this server. Can I play too please. The 64-bit .deb file worked fine on my Ubuntu system: http://dlang.org/download.html Ali However I cannot download the .dmg file on my MAC OS X system. The link: http://dlang.org/dmd.2.059.dmg does not work. and the file in question is not available on the ftp site http://ftp.digitalmars.com/dmd.2.059.dmg Andrew
Re: dmd 1.074 and 2.059 release
On Saturday, 14 April 2012 at 01:34:25 UTC, Walter Bright wrote: On 4/13/2012 5:47 PM, Tyro[17] wrote: The requested URL /dmd.2.059.dmg was not found on this server. Hmm, I overlooked that one. Any idea of when it will be available? And by the way, thank you and everyone else for all your hard work. Andrew
Re: dmd 1.074 and 2.059 release
Tyro[17] nos...@home.com wrote in message news:rjhmnaxxiglqftwxh...@forum.dlang.org... On Friday, 13 April 2012 at 05:54:26 UTC, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Not Found The requested URL /dmd.2.059.dmg was not found on this server. Can I play too please. You can still use the zip, that includes all platforms.
Re: dmd 1.074 and 2.059 release
On Saturday, 14 April 2012 at 02:24:29 UTC, Adam D. Ruppe wrote: Gah, I just ruined by night by actually trying to use this release. 78 lines of template instantiation error spam on code that worked perfectly on 2.058 :( I think I've finally narrowed down the cause of seas of errors appearing in unrelated code: http://d.puremagic.com/issues/show_bug.cgi?id=7904
Re: Measuring the page generation of the forum
On Friday, 13 April 2012 at 02:25:19 UTC, Somedude wrote: Well, it's not really urgent. It's fast enough. Still, collecting statistics over time would have been nice, so that one could analyse the general behaviour of the GC, for instance, by getting an idea of the standard deviation and maximum response time over weeks of use. Such statistics wouldn't be very meaningful due to the highly varying server load, caused by a large number of other websites and services running on the same machine. But I have experienced a response of several seconds once, I don't know where this comes from (although it's most likely one of your reasons). Long page loads are caused by a combination of high server load + RAM cache misses + SQLite queries that require a lot of seeks. I'm quite sure this is the case. BTW, could you repost the source code address ? Thx. There is a link to the source code on the Help page. Oh, I just saw you wrote the max page generation was around 50 ms. When there are no cache misses, yes.
Re: Foreach Closures?
On 2012-04-13 06:50, Matt Peterson wrote: On Thursday, 12 April 2012 at 06:46:53 UTC, Jacob Carlborg wrote: I'm pretty sure that the JSON output can _never_ be enough for what we want to do. I agree with that, nothing will quite be the same as a full compiler-as-a-library (CAAL?). But in the meantime, there is a working compiler now, and isn't it better to get some kind of IDE-like functionality sooner rather than waiting for a long time with nothing? When you say there is a working compiler now, which on is you referring to. DMD, LDC, GDC, SDC or any other? As far as I know neither DMD, LDC or GDC is usable as a library. I have no experience of SDC and don't know in what state it is. But I guess we would have to do some investigation and figure out what the best to do this would be. BTW, there are already IDE's with some kind of frontends available. MonoD, VisualD, Descent (now old) and possibly others. -- /Jacob Carlborg
Re: Measuring the page generation of the forum
On Friday, 13 April 2012 at 03:24:19 UTC, Jesse Phillips wrote: I'm pretty sure it is the NG itself. Every news reader I've used has shown some form of hiccup If you try making a post under a heavy load you'll get a nice page telling you the load and what it needed to be. Long page loads are caused by a combination of high server load + RAM cache misses + SQLite queries that require a lot of seeks. Network operations, including fetching new posts from the NG and posting to the NG, are asynchronous, and never block web requests.
Re: Foreach Closures?
* Jacob Carlborg d...@me.com [2012-04-13 08:40:39 +0200]: On 2012-04-13 06:50, Matt Peterson wrote: I agree with that, nothing will quite be the same as a full compiler-as-a-library (CAAL?). But in the meantime, there is a working compiler now, and isn't it better to get some kind of IDE-like functionality sooner rather than waiting for a long time with nothing? When you say there is a working compiler now, which on is you referring to. DMD, LDC, GDC, SDC or any other? As far as I know neither DMD, LDC or GDC is usable as a library. I have no experience of SDC and don't know in what state it is. But I guess we would have to do some investigation and figure out what the best to do this would be. BTW, there are already IDE's with some kind of frontends available. MonoD, VisualD, Descent (now old) and possibly others. I think he means that while there isn't a suitable CaaL, there are working compilers that can be improved to supply enough information to atleast start on IDE integration, even if it isn't as robust or efficient as an actual library. From what I can tell, LDC would probably be the best for the kind of code analysis an IDE would need, since it is has an LLVM backend. SDC would be good too, but SDC is probably the best one to try to move towards adding this functionality. -- James Miller
D Compiler as a Library
Having a D compiler available as a library will (at least) give these
benefits:
1. Can be used by an IDE: D is statically typed and so an IDE can
benefit a lot from this. The features Descent had, as far as I remember,
were:
1.1. Outline
1.2. Autocompletion
1.3. Type Hierarchy
1.4. Syntax and semantic errors, showing not only the line number
but also column numbers if it makes sense
1.5. Automatic import inclusion (say, typing writefln and getting a
list of modules that provide that symbol)
1.6. Compile-time view: replace auto with the inferred type, insert
mixins into scope, rewrite operator overloads and other lowerings (but
I'm not sure this point is really useful)
1.7. Determine, given a set of versions and flags, which branches
of static ifs are used/unused
1.8. Open declaration
1.9. Show implementations (of an interface, of interface's method
or, abstract methods, or method overrides).
1.10. Propose to override a method (you type some letters and then
hit some key combination and get a list of methods to override)
1.11. Get the code of a template when instantiated.
2. Can be used to build better doc generators: one that shows known
subclasses or interface implementation, shows inherited methods, type
hierarchy.
3. Can be used for lints and other such tools.
As you can see, a simple lexer/parser built into an IDE, doc generator
or lint will just give basic features but will never achieve something
exceptionally good if it lacks the full semantic knowledge of the code.
I'll write a list of things I'd like this compiler-as-library to have,
but please help me make it bigger :-)
* Don't use global variables (DMD is just thought to be run once, so
when used as a library it can just be used, well, once)
* Provide a lexer which gives line numbers and column numbers
(beginning, end)
* Provide a parser with the same features
* The semantic phase should not discard any information found while
parsing. For example when DMD resolves a type it recursively resolves
aliasing and keeps the last one. An example:
alias int foo;
alias foo* bar;
bar something() { ... }
It would be nice if bar, after semantic analysis is done, carries
the information that bar is foo* and that foo is int. Also that
something's return type is bar, not int*.
* Provide errors and warnings that have line numbers as well as column
numbers.
* Allow to parse the top-level definitions of a module. Whit this I
mean skipping function bodies. At least Descent first built a the
outline of the whole project by doing this. This mode should also allow
specifying a location as a target, and if that location falls inside a
function body then it's contents are returned (useful when editing a
file, so you can get the outline as well as semantic info of the
function currently being edited, which will never affect semantic in
other parts of the module). This will dramatically speed up the editor.
* Don't stop parsing on errors (I think DMD already does this).
* Provide a visitor class. If possible, use visitors to implement
semantic analysis. The visitor will make it super easy to implement
lints and to generate documentation.
Re: std library hooks
No comment... I'm also finding that I really need an assert hook. The default assert implementation is not useful to me, and just crashes my programs (exceptions when interacting with C is problematic). I'd like to route runtime asserts through my own system. A simple backend hook would sort me out here too.. Does anyone know any existing way to do the stuff I'm talking about here? If not, what do people think about the possibility of putting hook register functions into druntime? On 9 April 2012 03:59, Manu turkey...@gmail.com wrote: So one thing that almost every major middleware provides, is an interface to hook your own allocation and filesystem callbacks under the hood, to allow integration with your potentially complex technology. In my industry, memory and filesystem hooks are non-negotiable. We can't use any middleware that does not provide them. Traditionally, we have a problem with the C library, and many core C libs which depend heavily on the CRT. Almost all games engines have to wastefully rewrite large portions of the CRT, just to implement the appropriate memory and filesystem interface, and some super handy common libs are lost to us due to lack of this foresight. So this in mind, many of the goodies in phobos are currently unusable to us (although fortunately source is available). Has it ever been considered to allow hooks into the backends of those systems which could be registered at runtime? It would be simple to provide an API where you could register the filesystem primitives, which all standard libraries would then magically route through (huzzah!). A primitive malloc/free hook would be nice to have too, that way we can direct memory to the appropriate locations, and keep mem stats along with the the rest of the system. It's not uncommon to malloc the entire heap on boot, and implement our own heap management through our own API's. Obviously system functions would fail to allocate memory in this environment... Having these hooks in phobos would also lift this burden off of library developers (usually only added on request with a few months turn around time, which is no good for project scheduling), and it would never prevent us access to those libraries where the developers never considered our use case.
Re: std library hooks
On 04/13/2012 12:47 PM, Manu wrote: No comment... I'm also finding that I really need an assert hook. The default assert implementation is not useful to me, and just crashes my programs (exceptions when interacting with C is problematic). I'd like to route runtime asserts through my own system. A simple backend hook would sort me out here too.. Does anyone know any existing way to do the stuff I'm talking about here? If not, what do people think about the possibility of putting hook register functions into druntime? On 9 April 2012 03:59, Manu turkey...@gmail.com mailto:turkey...@gmail.com wrote: So one thing that almost every major middleware provides, is an interface to hook your own allocation and filesystem callbacks under the hood, to allow integration with your potentially complex technology. In my industry, memory and filesystem hooks are non-negotiable. We can't use any middleware that does not provide them. Traditionally, we have a problem with the C library, and many core C libs which depend heavily on the CRT. Almost all games engines have to wastefully rewrite large portions of the CRT, just to implement the appropriate memory and filesystem interface, and some super handy common libs are lost to us due to lack of this foresight. So this in mind, many of the goodies in phobos are currently unusable to us (although fortunately source is available). Has it ever been considered to allow hooks into the backends of those systems which could be registered at runtime? It would be simple to provide an API where you could register the filesystem primitives, which all standard libraries would then magically route through (huzzah!). A primitive malloc/free hook would be nice to have too, that way we can direct memory to the appropriate locations, and keep mem stats along with the the rest of the system. It's not uncommon to malloc the entire heap on boot, and implement our own heap management through our own API's. Obviously system functions would fail to allocate memory in this environment... Having these hooks in phobos would also lift this burden off of library developers (usually only added on request with a few months turn around time, which is no good for project scheduling), and it would never prevent us access to those libraries where the developers never considered our use case. http://dlang.org/phobos/core_exception.html deprecated void setAssertHandler(errorHandlerType h); Why is it deprecated?
Re: Precise GC
On Sunday, 8 April 2012 at 12:02:10 UTC, Alex Rønne Petersen wrote: This sounds important to me. If it is also possible to do the work with generated tables, and not calling thousands of indirect functions in someone's implementation, it would be nice to reserve that possibility. Indirect function calls in hot loops make me very nervous for non-x86 machines. Yes, I agree here. The last thing we need is a huge amount of kinda-sorta-virtual function calls on ARM, MIPS, etc. It may work fine on x86, but anywhere else, it's really not what you want in a GC. What's the problem with virtual calls on ARM?
Re: Starting with D(2)
Le mardi 10 avril 2012 à 19:00 +0200, Lars Johansson a écrit : Hey all, I do not find a better suited forum or blog to ask some newbie questions. I read some about D. Some years ago I actually wrote some small D1/tango programs just for fun. Now I like to start do some more serious stuff with D2. But there are some things bugging me. It seems there is a blood feuds among D and tango communities. This looks bad, and something I do not like. But more important I can not find good documentation how to install D2 with tango and phobos2. There are probably other useful libraries, where do I find them and how do I install them. I'm primarily looking for a Windows install. I managed to install D (dmd and probably phobos2) some examples do not even compile, so I probably didn't do a successful install. I appreciate if someone can give some advice. Fedora 17 provides all you want. I think fedora give the easier way to use D. In repository you will found: - D compiler: ldc2 - standard library: phobos - GUI binding: gtkd - Game library: Derelict - other library: Tango In more fedora provides geany tag for each library, with these tags you will get autocompletion
Re: std library hooks
On 13 April 2012 14:07, Timon Gehr timon.g...@gmx.ch wrote: On 04/13/2012 12:47 PM, Manu wrote: No comment... I'm also finding that I really need an assert hook. The default assert implementation is not useful to me, and just crashes my programs (exceptions when interacting with C is problematic). I'd like to route runtime asserts through my own system. A simple backend hook would sort me out here too.. Does anyone know any existing way to do the stuff I'm talking about here? If not, what do people think about the possibility of putting hook register functions into druntime? On 9 April 2012 03:59, Manu turkey...@gmail.com mailto:turkey...@gmail.com wrote: So one thing that almost every major middleware provides, is an interface to hook your own allocation and filesystem callbacks under the hood, to allow integration with your potentially complex technology. In my industry, memory and filesystem hooks are non-negotiable. We can't use any middleware that does not provide them. Traditionally, we have a problem with the C library, and many core C libs which depend heavily on the CRT. Almost all games engines have to wastefully rewrite large portions of the CRT, just to implement the appropriate memory and filesystem interface, and some super handy common libs are lost to us due to lack of this foresight. So this in mind, many of the goodies in phobos are currently unusable to us (although fortunately source is available). Has it ever been considered to allow hooks into the backends of those systems which could be registered at runtime? It would be simple to provide an API where you could register the filesystem primitives, which all standard libraries would then magically route through (huzzah!). A primitive malloc/free hook would be nice to have too, that way we can direct memory to the appropriate locations, and keep mem stats along with the the rest of the system. It's not uncommon to malloc the entire heap on boot, and implement our own heap management through our own API's. Obviously system functions would fail to allocate memory in this environment... Having these hooks in phobos would also lift this burden off of library developers (usually only added on request with a few months turn around time, which is no good for project scheduling), and it would never prevent us access to those libraries where the developers never considered our use case. http://dlang.org/phobos/core_**exception.htmlhttp://dlang.org/phobos/core_exception.html deprecated void setAssertHandler(**errorHandlerType h); Why is it deprecated? Awesome, I missed that. Although it sucks it's deprecated, what's the intended alternative? Now if I could only have more of those for malloc/free, and fopen/close/read/write/seek etc.
Re: D Compiler as a Library
Le 13/04/2012 11:58, Ary Manzana a écrit :
Having a D compiler available as a library will (at least) give these
benefits:
1. Can be used by an IDE: D is statically typed and so an IDE can
benefit a lot from this. The features Descent had, as far as I remember,
were:
1.1. Outline
1.2. Autocompletion
1.3. Type Hierarchy
1.4. Syntax and semantic errors, showing not only the line number but
also column numbers if it makes sense
1.5. Automatic import inclusion (say, typing writefln and getting a list
of modules that provide that symbol)
1.6. Compile-time view: replace auto with the inferred type, insert
mixins into scope, rewrite operator overloads and other lowerings (but
I'm not sure this point is really useful)
1.7. Determine, given a set of versions and flags, which branches of
static ifs are used/unused
1.8. Open declaration
1.9. Show implementations (of an interface, of interface's method or,
abstract methods, or method overrides).
1.10. Propose to override a method (you type some letters and then hit
some key combination and get a list of methods to override)
1.11. Get the code of a template when instantiated.
2. Can be used to build better doc generators: one that shows known
subclasses or interface implementation, shows inherited methods, type
hierarchy.
3. Can be used for lints and other such tools.
As you can see, a simple lexer/parser built into an IDE, doc generator
or lint will just give basic features but will never achieve something
exceptionally good if it lacks the full semantic knowledge of the code.
I'll write a list of things I'd like this compiler-as-library to have,
but please help me make it bigger :-)
* Don't use global variables (DMD is just thought to be run once, so
when used as a library it can just be used, well, once)
* Provide a lexer which gives line numbers and column numbers
(beginning, end)
* Provide a parser with the same features
* The semantic phase should not discard any information found while
parsing. For example when DMD resolves a type it recursively resolves
aliasing and keeps the last one. An example:
alias int foo;
alias foo* bar;
bar something() { ... }
It would be nice if bar, after semantic analysis is done, carries the
information that bar is foo* and that foo is int. Also that
something's return type is bar, not int*.
* Provide errors and warnings that have line numbers as well as column
numbers.
* Allow to parse the top-level definitions of a module. Whit this I mean
skipping function bodies. At least Descent first built a the outline of
the whole project by doing this. This mode should also allow specifying
a location as a target, and if that location falls inside a function
body then it's contents are returned (useful when editing a file, so you
can get the outline as well as semantic info of the function currently
being edited, which will never affect semantic in other parts of the
module). This will dramatically speed up the editor.
* Don't stop parsing on errors (I think DMD already does this).
* Provide a visitor class. If possible, use visitors to implement
semantic analysis. The visitor will make it super easy to implement
lints and to generate documentation.
SDC have a lot of theses, and I proposed a similar stuff for its
evolution. I think it is easier for SDC than it is for dmd considering
the codebase of both.
Re: Precise GC
On 13 April 2012 15:53, Kagamin s...@here.lot wrote: On Sunday, 8 April 2012 at 12:02:10 UTC, Alex Rønne Petersen wrote: This sounds important to me. If it is also possible to do the work with generated tables, and not calling thousands of indirect functions in someone's implementation, it would be nice to reserve that possibility. Indirect function calls in hot loops make me very nervous for non-x86 machines. Yes, I agree here. The last thing we need is a huge amount of kinda-sorta-virtual function calls on ARM, MIPS, etc. It may work fine on x86, but anywhere else, it's really not what you want in a GC. What's the problem with virtual calls on ARM? No other processors have branch prediction units anywhere near the sophistication of modern x86. Any call through a function pointer stalls the pipeline, pipelines are getting longer all the time, and PPC has even more associated costs/hazards. Most processors can only perform trivial binary branch prediction around an 'if'. It also places burden on the icache (unable to prefetch), and of course the dcache, both of which are much less sophisticated than x86 aswell. Compiler can't do anything with code locality (improves icache usage), since the target is unknown at compile time... there are also pipeline stalls introduced by the sequence of indirect pointer lookups preceding any virtual call. Virtuals are possibly the worst hazard to modern CPU's, and the hardest to detect/profile, since their cost is evenly spread throughout the entire code base, you can never gauge their true impact on your performance. You also can't easily measure the affect of icache misses on your code, suffice to say, you will have MANY more in virtual-heavy code. While I'm at it. 'final:' and 'virtual' keyword please ;)
Re: Precise GC
On 2012-04-13 16:54:28 +0300 Manu turkey...@gmail.com wrote: While I'm at it. 'final:' and 'virtual' keyword please ;) Hmmm, I thought we decided that was a good idea, anybody in the know if this going to happen or not? -- James Miller
Re: Precise GC
On Friday, 13 April 2012 at 13:54:39 UTC, Manu wrote: No other processors have branch prediction units anywhere near the sophistication of modern x86. Any call through a function pointer stalls the pipeline, pipelines are getting longer all the time, and PPC has even more associated costs/hazards. Most processors can only perform trivial binary branch prediction around an 'if'. It also places burden on the icache (unable to prefetch), and of course the dcache, both of which are much less sophisticated than x86 aswell. Allocation of small aggregated objects usually involves allocation of several equally small objects of different types in a row, so they sit one after another in heap and gc will visit them in a row every time calling function different from the previous time, so to x86 processor it would result in constant misprediction: AFAIK x86 processor caches only one target address per branch (ARM caches a flag?). And icache should not suffer in both cases: once you prefetched the function, it will remain in the icache and be reused from there the next time.
Re: What about x64 windows?
On Wednesday, 11 April 2012 at 16:18:21 UTC, Kai Nacke wrote: You can compile and run LDC2 on Windows x64. The major problem is missing support for SEH64 exception handling in the used LLVM compiler framework. https://github.com/ldc-developers/ldc Kai Does it support at least DWARF exceptions?
Re: Foreach Closures?
On 2012-04-13 11:28, James Miller wrote: I think he means that while there isn't a suitable CaaL, there are working compilers that can be improved to supply enough information to atleast start on IDE integration, even if it isn't as robust or efficient as an actual library. From what I can tell, LDC would probably be the best for the kind of code analysis an IDE would need, since it is has an LLVM backend. SDC would be good too, but SDC is probably the best one to try to move towards adding this functionality. -- James Miller I don't know if it would be much difference between LDC, GDC and DMD since they all use the same frontend. And it's the frontend that is the most important part, not the backend. -- /Jacob Carlborg
Re: std library hooks
Because no one used it. Sounds like I may need to un-deprecate it for 2.060. On Apr 13, 2012, at 4:07 AM, Timon Gehr timon.g...@gmx.ch wrote: On 04/13/2012 12:47 PM, Manu wrote: No comment... I'm also finding that I really need an assert hook. The default assert implementation is not useful to me, and just crashes my programs (exceptions when interacting with C is problematic). I'd like to route runtime asserts through my own system. A simple backend hook would sort me out here too.. Does anyone know any existing way to do the stuff I'm talking about here? If not, what do people think about the possibility of putting hook register functions into druntime? On 9 April 2012 03:59, Manu turkey...@gmail.com mailto:turkey...@gmail.com wrote: So one thing that almost every major middleware provides, is an interface to hook your own allocation and filesystem callbacks under the hood, to allow integration with your potentially complex technology. In my industry, memory and filesystem hooks are non-negotiable. We can't use any middleware that does not provide them. Traditionally, we have a problem with the C library, and many core C libs which depend heavily on the CRT. Almost all games engines have to wastefully rewrite large portions of the CRT, just to implement the appropriate memory and filesystem interface, and some super handy common libs are lost to us due to lack of this foresight. So this in mind, many of the goodies in phobos are currently unusable to us (although fortunately source is available). Has it ever been considered to allow hooks into the backends of those systems which could be registered at runtime? It would be simple to provide an API where you could register the filesystem primitives, which all standard libraries would then magically route through (huzzah!). A primitive malloc/free hook would be nice to have too, that way we can direct memory to the appropriate locations, and keep mem stats along with the the rest of the system. It's not uncommon to malloc the entire heap on boot, and implement our own heap management through our own API's. Obviously system functions would fail to allocate memory in this environment... Having these hooks in phobos would also lift this burden off of library developers (usually only added on request with a few months turn around time, which is no good for project scheduling), and it would never prevent us access to those libraries where the developers never considered our use case. http://dlang.org/phobos/core_exception.html deprecated void setAssertHandler(errorHandlerType h); Why is it deprecated?
Re: D Compiler as a Library
On Friday, 13 April 2012 at 13:08:51 UTC, deadalnix wrote: SDC have a lot of theses, and I proposed a similar stuff for its evolution. I think it is easier for SDC than it is for dmd considering the codebase of both. I think we've got the lexer and parser completely separate from most of the rest of the codebase (like the codegen), due to repeated requests from people who wanted to use these parts for IDEs and other tools. I've yet to see anyone actually go through with using it though, possibly because there is no documentation for a lot of it. Documenting these parts fully into something of a public API and then putting it online is definitely on the todo list. Perhaps there would be more motivation to do this rather than work on something else if someone actually tried using SDC in their project instead of just talking about it, so it's kind of a catch-22. That said, the parser is currently evolving alongside the codegen. When we want to start implementing new parts of the language, we iteratively add it to the parser, hence it's not complete. It's very easy to work with though and it's mostly a menial task (although it's kind of fun to produce beautiful parser errors :P). Anyway, for anyone interested, you can find us on Github and #d.sdc on FreeNode.
Re: opHash??
On Wed, Apr 11, 2012 at 09:01:41AM -0500, Andrei Alexandrescu wrote: On 4/10/12 11:10 PM, H. S. Teoh wrote: On Tue, Apr 10, 2012 at 06:49:07PM -0700, Jonathan M Davis wrote: On Tuesday, April 10, 2012 18:44:40 H. S. Teoh wrote: TDPL, p.117, last para: ... For a user-defined type to be used as a key in an associative array, it must define two special methods, opHash and opCmp. Really? I thought the convention was toHash (TDPL, p.205). So, which is it? Which *should* it be? To me, it seems utterly arbitrary that classes should use toHash whereas non-class user-defined types should use opHash. Shouldn't we make it consistent across the board? I expect that opHash was a mistake and that there should be an errata for that line on page 117: http://erdani.com/tdpl/errata/ [...] Actually, I looked, but it wasn't listed. Andrei? Is this an error? Most likely! [...] So this should be added to the errata, then? T -- In theory, there is no difference between theory and practice.
Re: opHash??
On 4/13/12 12:15 PM, H. S. Teoh wrote: So this should be added to the errata, then? I'm on it. Andrei
Re: opHash??
On Fri, Apr 13, 2012 at 01:07:39PM -0500, Andrei Alexandrescu wrote: On 4/13/12 12:15 PM, H. S. Teoh wrote: So this should be added to the errata, then? I'm on it. [...] Speaking of which, are you planning at some point to publish a second edition to TDPL? Maybe after the language settles down a bit more? Just curious. T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Re: opHash??
On 4/13/12 1:16 PM, H. S. Teoh wrote: On Fri, Apr 13, 2012 at 01:07:39PM -0500, Andrei Alexandrescu wrote: On 4/13/12 12:15 PM, H. S. Teoh wrote: So this should be added to the errata, then? I'm on it. [...] Added errata with credit. http://erdani.com/tdpl/errata Speaking of which, are you planning at some point to publish a second edition to TDPL? Maybe after the language settles down a bit more? Just curious. New edition == major changes New printing == small changes, errata fixes I think we'll go with a new printing soon. Andrei
Re: Starting with D(2)
I have self-made installation of D2 lang (32 bit, dmd2 compiler, phobos2) that includes dsss, gtk/gtkd, opengl, libxml, iconv, gtksourceview libs. Some examples must be manually updated, but compiles properly. Installation is zip archive with above packages and one *.bat file that sets an valid environment variables. It's work good on Win 64 server edition. At the moment it lets me develop serious applications. The best two books at start are The D Programming Language and Fundation of Gtk+ Develpment. On Tuesday, 10 April 2012 at 17:00:40 UTC, Lars Johansson wrote: Hey all, I do not find a better suited forum or blog to ask some newbie questions. I read some about D. Some years ago I actually wrote some small D1/tango programs just for fun. Now I like to start do some more serious stuff with D2. But there are some things bugging me. It seems there is a blood feuds among D and tango communities. This looks bad, and something I do not like. But more important I can not find good documentation how to install D2 with tango and phobos2. There are probably other useful libraries, where do I find them and how do I install them. I'm primarily looking for a Windows install. I managed to install D (dmd and probably phobos2) some examples do not even compile, so I probably didn't do a successful install. I appreciate if someone can give some advice.
Re: D Compiler as a Library
On 2012-04-13 11:58, Ary Manzana wrote:
Having a D compiler available as a library will (at least) give these
benefits:
1. Can be used by an IDE: D is statically typed and so an IDE can
benefit a lot from this. The features Descent had, as far as I remember,
were:
1.1. Outline
1.2. Autocompletion
1.3. Type Hierarchy
1.4. Syntax and semantic errors, showing not only the line number but
also column numbers if it makes sense
1.5. Automatic import inclusion (say, typing writefln and getting a list
of modules that provide that symbol)
1.6. Compile-time view: replace auto with the inferred type, insert
mixins into scope, rewrite operator overloads and other lowerings (but
I'm not sure this point is really useful)
Sure it is, it's very usable.
1.7. Determine, given a set of versions and flags, which branches of
static ifs are used/unused
1.8. Open declaration
1.9. Show implementations (of an interface, of interface's method or,
abstract methods, or method overrides).
1.10. Propose to override a method (you type some letters and then hit
some key combination and get a list of methods to override)
1.11. Get the code of a template when instantiated.
2. Can be used to build better doc generators: one that shows known
subclasses or interface implementation, shows inherited methods, type
hierarchy.
3. Can be used for lints and other such tools.
As you can see, a simple lexer/parser built into an IDE, doc generator
or lint will just give basic features but will never achieve something
exceptionally good if it lacks the full semantic knowledge of the code.
I'll write a list of things I'd like this compiler-as-library to have,
but please help me make it bigger :-)
* Show generated documentation for symbols both on hover and in the
autocompletion list
* Show source for symbols
* Import organizer (or what to call it). Remove unused imports and add
missing ones
* Code formatting
* Fix it/quick fix. Button for automatically fixing simple errors
* Syntax and semantic highlighting :)
* Refactoring
I can also think about a lot of features that is usable if you also have
a GUI builder in the IDE.
* Don't use global variables (DMD is just thought to be run once, so
when used as a library it can just be used, well, once)
* Provide a lexer which gives line numbers and column numbers
(beginning, end)
* Provide a parser with the same features
* The semantic phase should not discard any information found while
parsing. For example when DMD resolves a type it recursively resolves
aliasing and keeps the last one. An example:
alias int foo;
alias foo* bar;
bar something() { ... }
It would be nice if bar, after semantic analysis is done, carries the
information that bar is foo* and that foo is int. Also that
something's return type is bar, not int*.
* Provide errors and warnings that have line numbers as well as column
numbers.
* Allow to parse the top-level definitions of a module. Whit this I mean
skipping function bodies. At least Descent first built a the outline of
the whole project by doing this. This mode should also allow specifying
a location as a target, and if that location falls inside a function
body then it's contents are returned (useful when editing a file, so you
can get the outline as well as semantic info of the function currently
being edited, which will never affect semantic in other parts of the
module). This will dramatically speed up the editor.
* Don't stop parsing on errors (I think DMD already does this).
* Provide a visitor class. If possible, use visitors to implement
semantic analysis. The visitor will make it super easy to implement
lints and to generate documentation.
This is a great start and as I've said elsewhere, this would be so cool
and usable to have.
--
/Jacob Carlborg
Re: std library hooks
On 2012-04-13 17:26, Sean Kelly wrote: Because no one used it. Sounds like I may need to un-deprecate it for 2.060. Yes, please. There are now several people that want to use it. But does the compiler handles this correctly? I think you previously mentioned something about this. -- /Jacob Carlborg
Re: D Compiler as a Library
On 2012-04-13 15:10, deadalnix wrote: SDC have a lot of theses, and I proposed a similar stuff for its evolution. I think it is easier for SDC than it is for dmd considering the codebase of both. I would guess so as well, although I have no experience of SDC. -- /Jacob Carlborg
Re: D Compiler as a Library
On 2012-04-13 17:25, Jakob Ovrum wrote: I think we've got the lexer and parser completely separate from most of the rest of the codebase (like the codegen), due to repeated requests from people who wanted to use these parts for IDEs and other tools. Cool. I've yet to see anyone actually go through with using it though, possibly because there is no documentation for a lot of it. Documenting these parts fully into something of a public API and then putting it online is definitely on the todo list. Perhaps there would be more motivation to do this rather than work on something else if someone actually tried using SDC in their project instead of just talking about it, so it's kind of a catch-22. That's always a problem. That said, the parser is currently evolving alongside the codegen. When we want to start implementing new parts of the language, we iteratively add it to the parser, hence it's not complete. It's very easy to work with though and it's mostly a menial task (although it's kind of fun to produce beautiful parser errors :P). Anyway, for anyone interested, you can find us on Github and #d.sdc on FreeNode. How does it compare to DMD, does it implement the whole language yet? -- /Jacob Carlborg
Re: D Compiler as a Library
Jacob Carlborg wrote: How does it compare to DMD, does it implement the whole language yet? https://github.com/bhelyer/SDC It lists feature support.
Re: What about x64 windows?
On Wednesday, 11 April 2012 at 14:14:33 UTC, Kagamin wrote: On Wednesday, 11 April 2012 at 12:45:08 UTC, Davita wrote: Hi guys. Is there a going development on x64 compiler for windows? Or D won't support x64 at all? Thanks https://bitbucket.org/goshawk/gdc/downloads That link is outdated. New repository for GDC is: https://github.com/D-Programming-GDC/GDC
Re: D Compiler as a Library
I think we've got the lexer and parser completely separate from most of the rest of the codebase (like the codegen), due to repeated requests from people who wanted to use these parts for IDEs and other tools. Still some things to learn from Clang though. e.g. it still directly builds an AST instead of using some kind of interface. btw, why do you use exceptions for compiler errors instead of a cheaper and more sophisticated system? I've yet to see anyone actually go through with using it though, possibly because there is no documentation for a lot of it. Yep, no comments anywhere :/
Re: std library hooks
On Friday, 13 April 2012 at 19:28:39 UTC, Jacob Carlborg wrote: On 2012-04-13 17:26, Sean Kelly wrote: Because no one used it. Sounds like I may need to un-deprecate it for 2.060. Yes, please. There are now several people that want to use it. But does the compiler handles this correctly? I think you previously mentioned something about this. Seconding this. I really need it as well.
Re: std library hooks
On Apr 13, 2012, at 12:28 PM, Jacob Carlborg d...@me.com wrote: On 2012-04-13 17:26, Sean Kelly wrote: Because no one used it. Sounds like I may need to un-deprecate it for 2.060. Yes, please. There are now several people that want to use it. But does the compiler handles this correctly? I think you previously mentioned something about this. DMD requires that you throw from the assert handler (at least when you compile with the -release flag or similar). That limitation is the other reason I deprecated the assert handler, but I imagine there are plenty of uses for it that exit with a throw.
Re: std library hooks
On 4/13/2012 4:07 AM, Timon Gehr wrote: http://dlang.org/phobos/core_exception.html deprecated void setAssertHandler(errorHandlerType h); Why is it deprecated? Never found a use for it.
Re: std library hooks
On 4/13/2012 6:07 AM, Manu wrote: Awesome, I missed that. Although it sucks it's deprecated, what's the intended alternative? Now if I could only have more of those for malloc/free, and fopen/close/read/write/seek etc. For a static library, you can hijack anything simply by providing your own implementation of it. The linker will prefer your version.
Re: std library hooks
On Friday, 13 April 2012 at 21:29:37 UTC, Walter Bright wrote:
On 4/13/2012 4:07 AM, Timon Gehr wrote:
http://dlang.org/phobos/core_exception.html
deprecated void setAssertHandler(errorHandlerType h);
Why is it deprecated?
Never found a use for it.
All I want, and I can guarantee that this is what Manu wants as
well, is the ability to squeeze an asm { int 3; } or equivalent
so that I can drop into my debugger at the point of assertion
failure before the stack unwinds.
Re: opHash??
On Friday, April 13, 2012 13:23:00 Andrei Alexandrescu wrote: I think we'll go with a new printing soon. But then I'll have to buy another copy! ;) Though trying to get your hands on the new printing once it comes out will probably be a bit hard for a while, because the odds of getting a copy of the first printing instead are likely to be fairly high at first. - Jonathan M Davis
Re: opHash??
On 4/13/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: New printing == small changes, errata fixes Be sure to sneak in the lambda syntax as an errata fix. ;-)
Re: std library hooks
On 4/13/2012 5:14 PM, Francois Chabot wrote:
On Friday, 13 April 2012 at 21:29:37 UTC, Walter Bright wrote:
On 4/13/2012 4:07 AM, Timon Gehr wrote:
http://dlang.org/phobos/core_exception.html
deprecated void setAssertHandler(errorHandlerType h);
Why is it deprecated?
Never found a use for it.
All I want, and I can guarantee that this is what Manu wants as well, is the
ability to squeeze an asm { int 3; } or equivalent so that I can drop into my
debugger at the point of assertion failure before the stack unwinds.
all assert(exp) does when it trips is call a function in the library. If you
provide your own version of that function, the one in the library won't be
linked in.
Re: Measuring the page generation of the forum
On Friday, 13 April 2012 at 08:09:09 UTC, Vladimir Panteleev wrote: On Friday, 13 April 2012 at 03:24:19 UTC, Jesse Phillips wrote: I'm pretty sure it is the NG itself. Every news reader I've used has shown some form of hiccup If you try making a post under a heavy load you'll get a nice page telling you the load and what it needed to be. Long page loads are caused by a combination of high server load + RAM cache misses + SQLite queries that require a lot of seeks. Network operations, including fetching new posts from the NG and posting to the NG, are asynchronous, and never block web requests. I use the split-thread view, I haven't had long page loads so maybe I've miss understood what he means by a hiccup. But I have seen it take time to retrieve a message and display it to me. I would expect a page could be considered loading if it is still waiting on fetching the post from the NG.
Re: Measuring the page generation of the forum
On Saturday, 14 April 2012 at 03:31:29 UTC, Jesse Phillips wrote: I use the split-thread view, I haven't had long page loads so maybe I've miss understood what he means by a hiccup. But I have seen it take time to retrieve a message and display it to me. I would expect a page could be considered loading if it is still waiting on fetching the post from the NG. All posts are stored in a local SQLite database. Posts are retrieved from the NG when the program starts, and as they are posted (a listening connection is kept open). If a message is listed in the forum, then it is already in the local database.
Definitive list of storage classes
I'd like to know which modifiers are considered to be storage classes. The term seems to be used on a lot more than actually qualifies (including using the term for the type qualfiers: const, immutable, and shared), and even the documentation uses it on stuff that I wouldn't have thought would be considered storage classes, because they have no effect on how variables are stored or linked (e.g. synchronized). Someone asked about it on stackoverflow, and my explanation is not as good as it should be simply because I can't find a definitive list anywhere: http://stackoverflow.com/questions/10150510/what-are-the-storage-classes-in-d - Jonathan M Davis
Re: FormatSpec struct
* Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net [2012-04-13 07:50:31 +0200]: I'm trying to add formatted output to my decimal arithmetic module. Decimals should format like floating point, using 'E', 'F' and 'G', etc. I would expect a format string like %9.6e to parse as width = 9, precision = 6, using exponential notation. In std.format there is a FormatSpec struct that looks as if it will do the parsing for me. As far as I can tell the usage is: auto spec = std.format.FormatSpec!char(9.6e); writeln(fmtspec = , fmtspec); But it doesn't do what I think it should do. The output of the method is: fmtspec = address = 1637116 width = 0 precision = 2147483646 spec = s indexStart = 0 indexEnd = 0 flDash = false flZero = false flSpace = false flPlus = false flHash = false nested = trailing = 9.6e The width field should be 9, the precision field should be 6, and the spec field should be 'e'. Instead it seems to disregard the input string and return a default FormatSpec, with only the 'trailing' field populated, containing the input. What am I missing here? I've tried variations -- %9.6e, s, %s, etc, but the input is always relegated to the trailing field. Paul Hey Paul, so some investigation has led me to believe that FormatSpec is really just for internal usage. The documentation is a bit misleading (to the point of being possibly completely false). FormatSpec, AFAICT, is essentially just a parser for the standard format specifier, but its not very clear as to proper usage. I'm going to try to improve it and submit a pull request, until then looking at the source code for std.format should give you some idea of how to best use it. -- James Miller
Re: Sampling algorithms for D
On 13.04.2012 1:48, Joseph Rushton Wakeling wrote:
On 12/04/12 21:54, bearophile wrote:
for( t=recordsRemaining-1; t=limit; --t)
y2 *= top--/bottom--;
Generally packing mutation of variables inside expressions is quite
bad style. It makes code less easy to understand and translate, and
currently it's not defined, just as in C (it will be defined, but it
will keep being bad style).
OK. There's one other that should be a point of concern, where I have
return currentRecord++;
... in one function; I've added a selectedRecord variable to get round
this.
I believe it's something that reasonable people may disagree on. To me
it's perfectly easy to see what return x++; does. So is arr[i++] = ...,
so is arr1[i++] = arr2[j++]. But the downward loops look hairy all the
time ;)
Also in D there is (I hope it will not be deprecated)
foreach_reverse(), maybe to replace this for().
or use some std.range primitives ( I think iota does a [begin, end) range)
foreach( x ; iota(recordRemaining-1, limit+1, -1)){
y2 *= top--/bottom--;
}
[snip]
--
Dmitry Olshansky
Re: Sampling algorithms for D
On 13.04.2012 2:50, Joseph Rushton Wakeling wrote: On 12/04/12 23:34, Dmitry Olshansky wrote: Aye, and in general community does appreciate any enhancements via pull requests on github: https://github.com/D-Programming-Language OK, I'll see what I can do. I'd like to discuss and refine the design a bit further before making any pull request -- should I take things over to the Phobos mailing list for this ... ? I'm no authority but there is this d.D newsgroup which is perfectly fine for this kind of thing. A lot of nice people just don't (have time to) mess with unwashed masses in D.learn :) -- Dmitry Olshansky
Re: FormatSpec struct
* James Miller ja...@aatch.net [2012-04-13 19:16:48 +1200]: * Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net [2012-04-13 07:50:31 +0200]: I'm trying to add formatted output to my decimal arithmetic module. Decimals should format like floating point, using 'E', 'F' and 'G', etc. I would expect a format string like %9.6e to parse as width = 9, precision = 6, using exponential notation. Hey Paul, so some investigation has led me to believe that FormatSpec is really just for internal usage. The documentation is a bit misleading (to the point of being possibly completely false). FormatSpec, AFAICT, is essentially just a parser for the standard format specifier, but its not very clear as to proper usage. I'm going to try to improve it and submit a pull request, until then looking at the source code for std.format should give you some idea of how to best use it. -- James Miller So I made the pull request, the documentation you need to read is here: https://github.com/Aatch/phobos/commit/cda3c079ee32d98a017f88949c10097840baa075 Hopefully it helps. -- James Miller
Re: Sampling algorithms for D
On 13/04/12 01:44, bearophile wrote:
final size_t select(ref UniformRNG urng)
in {
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
} body {
...
}
OK. I'm confused by these asserts, because if I go beyond what is acceptable by
calling select() even after I've collected a complete sample, no error is
thrown. e.g. if I put in place a function:
void sampling_test_simple(SamplerType, UniformRNG)
(size_t records, size_t samples, ref UniformRNG urng)
{
auto s = new SamplerType(records,samples,urng);
while(s.sampleRemaining 0) {
write(\trecord selected: , s.select(urng), .);
write(\trecords remaining: , s.recordsRemaining, .);
writeln(\tstill to sample: , s.sampleRemaining, .);
}
// Let's see if we can bust this ...
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
}
(... see current GitHub code: https://github.com/WebDrake/SampleD )
It doesn't make any difference if I compile with -debug enabled:
gdmd -debug -oftest sampled.d
Re: Sampling algorithms for D
Dmitry Olshansky:
I believe it's something that reasonable people may disagree on.
To me it's perfectly easy to see what return x++; does.
I agree that return x++; is not too bad for a human reader, but code with
mutation inside expressions (mostly written by other people) has caused me tons
of troubles (and the semantics of ++ and -- are as much undefined in D as in C,
still). So I usually kit it with fire as soon as I see it.
I'd like to modify the -- and ++ to make them return void. I think Go is
designed like that.
or use some std.range primitives ( I think iota does a [begin, end) range)
foreach( x ; iota(recordRemaining-1, limit+1, -1)){
y2 *= top--/bottom--;
}
Only if you don't care a lot for the performance of that specific loop. (DMD is
sometimes not even able to optimize foreach() loops as well as for() loops. Go
figure what it does on iota()).
Bye,
bearophile
Re: Sampling algorithms for D
Joseph Rushton Wakeling:
final size_t select(ref UniformRNG urng)
in {
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
} body {
...
}
OK. I'm confused by these asserts,
What's confusing? I don't understand. It's contract-based programming, the code
is essentially the same as before:
http://dlang.org/dbc.html
Bye,
bearophile
Re: Library search path on Windows?
On 13-04-2012 05:25, Jesse Phillips wrote: On Friday, 13 April 2012 at 01:10:40 UTC, Alex Rønne Petersen wrote: How do I pass a library search path to DMD on Windows? I would love to know too! Only place I found was to edit sc.ini sorry. It seems that -L+path does the trick... I only found that after scavenging the wiki. -- - Alex
Re: Sampling algorithms for D
On 13/04/12 13:10, bearophile wrote: What's confusing? I don't understand. It's contract-based programming, the code is essentially the same as before: http://dlang.org/dbc.html No, I understand the principle; I just don't understand why the code is running without errors being displayed when I violate the bounds of those asserts.
Re: GUI library
On Sunday, 25 March 2012 at 15:59:21 UTC, Jacob Carlborg wrote: On 2012-03-25 17:22, Kevin Cox wrote: I would reccomend Qt as well. You will get native cross-platform widgets with great performance. I am not sure how far QtD is but I know it once had a lot of development on it. I don't think Qt is uses the native drawing operations on Mac OS X. Qt does support native drawing operations on Mac OS X since 4.5.0, when it switched from Carbon to Cocoa as its backend. More info here[1] and here[2]. [1]: http://labs.qt.nokia.com/2007/06/21/wwdc-qt-carbon-64-bit-and-other-buzzwords/ [2]: http://labs.qt.nokia.com/2008/03/03/qtmac-cocoa-port-alpha-released/ - Rizo
Re: GUI library
On Sunday, 25 March 2012 at 15:14:04 UTC, Jacob Carlborg wrote: It would also be possible to use Cocoa, as you do with Objective-C, but that wouldn't be very practically. There's also a DMD fork that directly supports interfacing with Objective-C: http://michelf.com/projects/d-objc/ Why do you say that the usage of Cocoa through the D-ObjC bridge would not be very practical? What are the possible limitations? - Rizo
Avoid compile time evaluation
If I have something like: static int var = myFunction(); dmd will evaluate myFunction() at compile time. If it can't, it gives me a compile error, doesn't it? If I'm not wrong, static force this. If i don't use static, dmd will try to evaluate myfunction() at compile time, and if it can't, myfunction() will be executed at runtime, right? So I have a code like this: ... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... ... static int var = myVeryVeryComplexFunction(); If i have to work to some code before my complex function, every time I have to re-compile code, it takes a lot because dmd evalute at compile time myVeryVeryComplexFunction() also if i don't use static. Does a keyword to force runtime evaluation exists? I can't find any documentation (neither on static used in this way, any link?)... My dirty way to do this is to edit myVeryVeryComplexFunction() adding a writeln() (or something similar) to function body.
Re: Avoid compile time evaluation
On Fri, 13 Apr 2012 14:52:05 +0200, Andrea Fontana nos...@example.com wrote: If I have something like: static int var = myFunction(); dmd will evaluate myFunction() at compile time. If it can't, it gives me a compile error, doesn't it? If I'm not wrong, static force this. Indeed. If i don't use static, dmd will try to evaluate myfunction() at compile time, and if it can't, myfunction() will be executed at runtime, right? No. static or enum forces evaluation at compiletime, otherwise it's runtime. Conceivably, the compiler could try running every function at compile-time as an optimization, but that would completely destroy the nice compilation times we like to brag about, and likely also break a lot of code. So I have a code like this: ... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... ... static int var = myVeryVeryComplexFunction(); If i have to work to some code before my complex function, every time I have to re-compile code, it takes a lot because dmd evalute at compile time myVeryVeryComplexFunction() also if i don't use static. Does a keyword to force runtime evaluation exists? I can't find any documentation (neither on static used in this way, any link?)... See above. Runtime evaluation is the default, and compile-time needs to be forced.
