Re: DConf 2013 Day 3 Talk 4: LDC by David Nadlinger
Great talk! Regarding the ci.lycus.org fleet, credit should definitely go to Adam Wilson (C# to D talk) and Kelly Wilson (same person who was present in the pie chart) too for providing many of the machines hooked up to the master node. The fleet doesn't do a whole lot of work most of the time, so if you have a project that 1) has a sane build system; 2) you're willing to respond to build failures on; 3) and is 'significant' enough, feel free to email me and I'll see what I can do. (By 'significant' I mean has enough impact to be useful for a reasonable amount of D programmers. This is of course pretty subjective, but we have to be a bit conservative about how many projects we add so that we don't end up having lots of stalled builds in the queue.)
Re: Getting ready for 2.061
On 22-12-2012 06:11, Jonathan M Davis wrote: On Friday, December 21, 2012 17:12:47 Andrei Alexandrescu wrote: We plan to start building a new release on Sunday evening. To do so (pursuant to the embryonic process we're putting in place), at that time we'll create a new branch called staging for each of dmd, druntime, and phobos. All contributors - over the weekend please ping reviewers on what you believe are pull requests with a high importance*urgency product. Once we branch into staging, pull requests will only be merged into master. https://github.com/D-Programming-Language/dmd/pull/1287 really should be resolved prior to 2.061, or we're going to be introducing a compiler flag (-di) which we're probably then going to turn around and deprecate (and making deprecations warn by default instead of giving you an error will be _huge_ step forward in our ability to manage deprecations without breaking people's code). - Jonathan M Davis +1 to this. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Objects in a Templated World
On 30-10-2012 19:23, Jesse Phillips wrote: I've written an article which goes over templates and objects. http://nascent.freeshell.org/programming/D/objectTemplate.php On a similar note I've republished _Learning to Program Using D_. Not a whole lot of change on the content front. Some expansions on existing chapters and a few fillers were added. Still very unfinished at around 50 pages. http://nascent.freeshell.org/programming/D/LearningWithD/ I include a generated PDF and a pre.tex file. What is probably of more interest to others writing D books in Latex is I have a program which handles building running and capturing output for the final tex file. It is very picky about formatting and can't handle file includes and probably many other fancy Latex options but it is mine so :P https://github.com/JesseKPhillips/listings-dlang-extractor And finally code uses the listings package, for which I have provided a style file to handle highlighting. https://github.com/JesseKPhillips/dlang-latex-listings I think you should cover C#. It allows virtual generic methods in its implementation of reified generics by relying on the JIT. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Blog post: Demystifying Garbage Collectors
http://xtzgzorex.wordpress.com/2012/10/11/demystifying-garbage-collectors/ Essentially an explanation of garbage collection for the layman programmer. Though, it does assume some familiarity with C and memory management. It's an abstract article not particularly specific to any GC implementation, but I figured I'd post it here anyway in case anyone's interested. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: GC vs. Manual Memory Management Real World Comparison
On 05-09-2012 13:03, Benjamin Thaut wrote: I rewrote a 3d game I created during my studies with D 2.0 to manual memory mangement. If I'm not studying I'm working in the 3d Engine deparement of Havok. As I needed to pratice manual memory management and did want to get rid of the GC in D for quite some time, I did go through all this effort to create a GC free version of my game. The results are: DMD GC Version: 71 FPS, 14.0 ms frametime GDC GC Version: 128.6 FPS, 7.72 ms frametime DMD MMM Version: 142.8 FPS, 7.02 ms frametime GC collection times: DMD GC Version: 8.9 ms GDC GC Version: 4.1 ms As you see the manual managed version is twice as fast as the garbage collected one. Even the highly optimized version created with GDC is still slower the the manual memory management. You can find the full article at: http://3d.benjamin-thaut.de/?p=20#more-20 Feedback is welcome. Kind Regards Benjamin Thaut Is source code available anywhere? Also, I have to point out that programming for a garbage collected runtime is very different from doing manual memory management. The same patterns don't apply, and you optimize in different ways. For instance, when using a GC, it is very recommendable that you allocate up front and use object pooling - and most importantly, don't allocate at all during your render loop. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: GC vs. Manual Memory Management Real World Comparison
On 05-09-2012 13:19, Benjamin Thaut wrote: Am 05.09.2012 13:10, schrieb Alex Rønne Petersen: Is source code available anywhere? Also, I have to point out that programming for a garbage collected runtime is very different from doing manual memory management. The same patterns don't apply, and you optimize in different ways. For instance, when using a GC, it is very recommendable that you allocate up front and use object pooling - and most importantly, don't allocate at all during your render loop. The sourcecode is not aviable yet, as it is in a repository of my university, but I can zip it and upload the current version if that is wanted. But it currently does only support Windows and does not have any setup instructions yet. I do object pooling in both versions, as in game developement you usually don't allocate during the frame. But still in the GC version you have the problem that way to many parts of the language allocate and you don't event notice it when using the GC. Just to clarify, I'm into 3d engine developement since about 7 years now. So I'm not a newcomer to the subject. Kind Regards Benjamin Thaut Sure, I just want to point out that it's a problem with the language (GC allocations being very non-obvious) as opposed to the nature of GC. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: GC vs. Manual Memory Management Real World Comparison
On 05-09-2012 14:07, Benjamin Thaut wrote:
Am 05.09.2012 14:00, schrieb Alex Rønne Petersen:
Sure, I just want to point out that it's a problem with the language (GC
allocations being very non-obvious) as opposed to the nature of GC.
Thats exactly what I want to cause with this post. More effort should be
put into the parts of D that currently allocate, but absolutley don't
have to. Also the statement You can use D without a GC is not quite as
easy as the homepage makes it sound.
Very true. I've often thought we should ship a GC-less druntime in the
normal distribution.
My favorite hidden allocation so far is:
class A {}
class B : A{}
A a = new A();
B b = new B();
if(a == b) //this will allocate
{
}
Where's the catch? From looking in druntime, I don't see where the
allocation could occur.
Kind Regards
Benjamin Thaut
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: GC vs. Manual Memory Management Real World Comparison
On 05-09-2012 13:03, Benjamin Thaut wrote: I rewrote a 3d game I created during my studies with D 2.0 to manual memory mangement. If I'm not studying I'm working in the 3d Engine deparement of Havok. As I needed to pratice manual memory management and did want to get rid of the GC in D for quite some time, I did go through all this effort to create a GC free version of my game. The results are: DMD GC Version: 71 FPS, 14.0 ms frametime GDC GC Version: 128.6 FPS, 7.72 ms frametime DMD MMM Version: 142.8 FPS, 7.02 ms frametime GC collection times: DMD GC Version: 8.9 ms GDC GC Version: 4.1 ms As you see the manual managed version is twice as fast as the garbage collected one. Even the highly optimized version created with GDC is still slower the the manual memory management. You can find the full article at: http://3d.benjamin-thaut.de/?p=20#more-20 Feedback is welcome. Kind Regards Benjamin Thaut BTW, your blog post appears to have comparison misspelled. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Dmitry Olshansky Passes GSoC Final Evaluation
On 24-08-2012 20:49, Andrei Alexandrescu wrote: On 8/24/12 2:44 PM, Dmitry Olshansky wrote: On 24-Aug-12 19:50, Andrei Alexandrescu wrote: Hi everybody, I'm happy to announce that Dmitry has passed GSoC's final evaluation. Going forward he and I will focus on integrating his work within Phobos. This should have technically occurred during the allocated time itself, but it's not like Dmitry will run away with the money :o). Thanks for your faith in me :o) Please join me in congratulating Dmitry. And Dmitry, let's get going with the integration. It would be great if we can get help from compiler hackers, as I've collected some gems on my first attempt to merge it that may very well stall the process: http://d.puremagic.com/issues/show_bug.cgi?id=8412 http://d.puremagic.com/issues/show_bug.cgi?id=8348 And this one makes all isXXX impure atm: http://d.puremagic.com/issues/show_bug.cgi?id=8446 I elevated all these bugs to blocker status. BTW I wonder which is higher - P1 or P5? Andrei They mean priority, so P1 would be highest. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Antti-Ville Tuuainen Passes GSoC Final Evaluation
On 23-08-2012 15:21, Rory McGuire wrote: On Thu, Aug 23, 2012 at 2:51 PM, dsimcha dsim...@yahoo.com mailto:dsim...@yahoo.com wrote: Basically, the idea is to store information about what is and isn't a pointer at the pool level instead of at the block level. My attempt from a long time ago at precise heap scanning, and Antti-Ville's first attempt, stored meta-data at the end of every allocated block. This worked well for large arrays, but was terribly inefficient for smaller allocations and made the GC code even messier than it already is. The overhead was a fixed (void*).sizeof bits per block. Now, each pool has a bit array that contains one bit for every possible aligned pointer. The overhead is always 1 bit for every (void*).sizeof bytes no matter how large or small the block is. Am I correct in thinking that this is still single threaded stop the world? Yes, but parallelization of the mark phase is fairly trivial, and something we should probably look into. The GC will probably always be STW unless we get compiler support for inserting GC barriers. Any chance of the code being documented extensively in the hopes that it would encourage participation/experimentation? Thanks for all the work you guys have put in. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Antti-Ville Tuuainen Passes GSoC Final Evaluation
On 23-08-2012 16:47, dsimcha wrote: On Thursday, 23 August 2012 at 14:38:19 UTC, Alex Rønne Petersen wrote: Yes, but parallelization of the mark phase is fairly trivial, and something we should probably look into. Ironically, Antti-ville's original proposal involved parallelization. This was scrapped because after rtinfo was added, we agreed that precise heap scanning was more important and looked newly feasible. Oh, I agree it's more important. The GC is reasonably fast as-is, but has severe issues with false pointers. Parallel marking is just in the nice to have category. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
On 14-08-2012 09:25, Paulo Pinto wrote: On Monday, 13 August 2012 at 22:07:51 UTC, Alex Rønne Petersen wrote: On 13-08-2012 23:58, Andrej Mitrovic wrote: On 8/13/12, Walter Bright newshou...@digitalmars.com wrote: I've thought many times about adding a D feature that allows one to specify use this random character string instead of the identifier as the symbol name when writing the object file, but never got around to it. Isn't that what .def files are for? Or maybe this is only used for DLLs? That's a Windows-ism. Actually it existed already in VMS and Aix before Windows adopted it. Fair enough, though the point I wanted to make was more that it's too platform-specific to be a general tool for achieving this. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
On 13-08-2012 23:43, Walter Bright wrote: On 8/13/2012 2:37 PM, Alex Rønne Petersen wrote: I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough. You could do it with a pragma or something. It's always going to look ugly, though. With some help from Iain, I managed to hack something together: https://github.com/D-Programming-Language/dmd/pull/1085 -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
On 14-08-2012 14:00, Daniel Murphy wrote: Alex Rønne Petersen a...@lycus.org wrote in message news:k0bs29$1bpl$1...@digitalmars.com... On 13-08-2012 23:34, Walter Bright wrote: On 8/13/2012 12:41 PM, Sean Kelly wrote: I've thought many times about adding a D feature that allows one to specify use this random character string instead of the identifier as the symbol name when writing the object file, but never got around to it. I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough. Pretty easy. I can't remember why I wanted this in the first place, maybe trying to interface with c longs? It probably needs updating (being over a year old) but the code is trivial. https://github.com/yebblies/dmd/pull/new/pragma_mangle Thanks for the link! I hacked something together before I saw your post and it looks surprisingly similar (though my version is a bit more lenient in what it allows in symbol names and how many declarations it can affect): https://github.com/D-Programming-Language/dmd/pull/1085 -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
On 13-08-2012 23:34, Walter Bright wrote: On 8/13/2012 12:41 PM, Sean Kelly wrote: Strangely,libc on OSX is very backwards-compatible. To the point where buggy functions were preserved as-is and updated versions exported via weird labels linked by the compiler using some evil macro code. Needless to say, D unfortunalely links to the buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler. An easy way is to write a .c file for druntime that accepts the call to the buggy function and calls the un-buggy one. That way the magic macros will work. I've thought many times about adding a D feature that allows one to specify use this random character string instead of the identifier as the symbol name when writing the object file, but never got around to it. I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
On 13-08-2012 23:58, Andrej Mitrovic wrote: On 8/13/12, Walter Bright newshou...@digitalmars.com wrote: I've thought many times about adding a D feature that allows one to specify use this random character string instead of the identifier as the symbol name when writing the object file, but never got around to it. Isn't that what .def files are for? Or maybe this is only used for DLLs? That's a Windows-ism. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: First working Win64 program!
On 11-08-2012 10:16, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a heluva lot
more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
return 0;
}
-
dmd -c -m64 hello.d
cl hello.obj
hello
hello world!
This is fabulous news!
One question: Will the 32-bit tool chain also be able to use the MSVC
runtime and linker eventually? It would make things /a lot/ easier if
both bitnesses used the same tool chain.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: 2.060 on reddit
On 04-08-2012 04:57, Jonathan M Davis wrote: On Saturday, August 04, 2012 04:44:12 Alex Rønne Petersen wrote: It's been discussed a time or two that we should have an incubator project for Phobos where potential Phobos modules go to be used and ironed out before actually being reviewed for inclusion in Phobos. But it's never materialized. Someone(s) would have to organize it and manage it, and no one has done so. - Jonathan M Davis I thought this was the idea of etc.* all along... Someone may have suggested that at some point, but that's not the way that it's used at all. Well: http://dlang.org/phobos/index.html etc This is the root of a hierarchy of modules mirroring the std hierarchy. Modules in etc are not standard D modules. They are here because they are experimental, or for some other reason are not quite suitable for std, although they are still useful. If nobody's against it, we should definitely get the ball rolling. I don't think that anyone's really against it, and it's not like it really needs to be official. The Phobos review process can be the same that it's been. There would just be a place for future Phobos stuff to be publicly tinkered with and allowed to evolve through usage rather than just designing everything up front as has often been the case with Phobos modules. The problem is that someone actually needs to step up and make it happen. Well, what actually needs to be done? When can something be submitted for etc.* rather than std.*? Etc... - Jonathan M Davis -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: 2.060 on reddit
On 04-08-2012 04:42, Jonathan M Davis wrote: On Saturday, August 04, 2012 02:37:07 Stefan Scholl wrote: bearophile bearophileh...@lycos.com wrote: Caligo: When are allocators going to be ready? Direct experience shows me that once things are in Phobos, it's not easy to fix their interface/API. Andrei fears of breaking Go's solution are experimental packages. You can always use them, but you know that they will change and at some time will be in antother namespace/directory. It's been discussed a time or two that we should have an incubator project for Phobos where potential Phobos modules go to be used and ironed out before actually being reviewed for inclusion in Phobos. But it's never materialized. Someone(s) would have to organize it and manage it, and no one has done so. - Jonathan M Davis I thought this was the idea of etc.* all along... If nobody's against it, we should definitely get the ball rolling. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: dmd 1.075 and 2.060 release
On 02-08-2012 21:40, Peter Alexander wrote:
Nice update, but broke Derelict2 :-(
Regression: delegates with default arguments are broken (worked in 2.059)
void foo(void delegate(int x = 0) fun)
{
fun(); // Error: expected 1 function arguments, not 0
}
I think it was decided that this was not a regression, if memory serves.
I believe the reasoning was that default parameters on delegates just
don't make sense in the general case, so it wasn't worth fixing.
I could be wrong. I can't seem to find the relevant bug. Anyone?
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: dmd 1.075 and 2.060 release
On 02-08-2012 21:18, 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.075.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.060.zip Unfortunately ran into a couple of regressions (though nothing major). One is here (and is fairly trivial to work around): http://j.mp/MftNLG Another one, which I haven't quite worked out a reduction of, is that the 'result' here is being claimed by DMD to be an undefined identifier: https://github.com/lycus/mci/blob/master/src/mci/vm/code.d#L59 I just commented out the postcondition there for now. Will try to create a useful reduction later today. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: dmd 1.075 and 2.060 release
On 02-08-2012 21:48, Alex Rønne Petersen wrote: On 02-08-2012 21:18, 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.075.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.060.zip Changelog is not updated? It's updated now, but now the page just seems completely misrendered. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: dmd 1.075 and 2.060 release
On 02-08-2012 23:25, Walter Bright wrote: On 8/2/2012 1:08 PM, Alex Rønne Petersen wrote: Unfortunately ran into a couple of regressions (though nothing major). Please join the beta program! I usually do, but didn't really get the time to try it out this release. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Pull freeze
On 01-08-2012 01:05, Jonathan M Davis wrote: On Tuesday, July 31, 2012 18:55:33 Nick Sabalausky wrote: Along those lines, I really think dmd-beta should me moved to the newsgroups. Granted, I am biased since I hate mailing lists. But moving it to NG means: - Consistency with the rest of the D traffic. - Easier to find/discover/subscribe. - Easier to follow the branches of discussion: Not everyone's email client does threading, but it's standard on NG readers. - We get forum.dlang.org integration and the associated visibility and google/bing-ability basically for free. I didn't realize that beta was any different from the rest (I always use the mailing list). It _is_ part of forum.dlang.org already though. - Jonathan M Davis Yeah, but in e.g. Thunderbird you get a nifty overview of lists on the NG in a side bar which makes for super easy navigation. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Pull freeze
On 29-07-2012 13:11, Jacob Carlborg wrote: On 2012-07-29 08:08, Andrei Alexandrescu wrote: Due to the upcoming release, there will be no regular pull walk-through tomorrow. Thanks for the growing rate of contribution, and let's resume the ritual next Sunday. Andrei Again, we _need_ to start using branches. Amen. There is no reason master should be frozen due to a release being made. The way we do releases is completely backwards: We freeze master, do the release, and *then* make a tag in Git. It should be the other way around, but replace tag with branch. The current release model may have seemed like a good idea during SVN times, but we're using Git now. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Visual D 0.3.33 uses a server for parsing and semantic analysis
On 20-06-2012 00:20, Rainer Schuetze wrote: Hi, Visual D 0.3.33 has just been released. The biggest improvement is the move of the parser and the semantic analysis into a local COM server process, so that the IDE is no longer suffering from stalls caused by garbage collections on more than small amounts of memory. Very nice! Some other, not so spectacular changes include * debugger project settings now stored in solution options file, not in project file I love you!!! You have no idea how annoying that could get sometimes... * cv2pdb: new version 0.25 that supports VS2012 * cv2pdb: exposed command line options in the project options * intellisense tool tip now shows enumerator value * version highlighting now supports the version(V): syntax * tweaked vsi2d to also convert the Windows 8 SDK and VS2012 SDK * various improvements to parser and semantic analysis The full list of changes is at http://www.dsource.org/projects/visuald/wiki/VersionHistory Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005-11 as well as the free Visual Studio Shells. The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald The source code is now also available on github: https://github.com/rainers/visuald Rainer Does this work with the VS 2012 RC? -- Alex Rønne Petersen a...@lycus.org http://lycus.org
libgc-d version 1.1 released
http://blog.lycus.org/2012/06/libgc-d-version-11-released.html As with libffi-d, version 1.0 was never announced here due to letting the library mature a bit first. It should now be ready for actual use (we use it in our virtual machine in Lycus). libgc-d is pretty much just a binding; no fancy wrappers exist here. The only actual D code in libgc-d consists of the new pointer reachability and hiding helpers. The blog post only lists changes since 1.0. Here are the actual changes since I first announced the project's existence: * Support for libgc's typed GC API. * Support for building with D 2.0 versions of the GDC compiler. * Support for building with D 2.0 versions of the LDC compiler. * New Waf-based build system. * GC initialization fixes in the test suite. * Added a helper function for marking pointer reachability. * Added helper functions to hide/reveal pointers for disappearing links. Note that the library has not been tested on Windows and has no build system in place for that platform either. We may look into this later if we decide that Windows support is something we care about. But patches welcome, of course! ;) If you encounter any issues with the library, please open an issue on the GitHub issue tracker. Enjoy! -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: dpj for Windows
On 20-05-2012 05:53, Nick Sabalausky wrote: dnewbier...@myopera.com wrote in message news:qufvdhexcdzabuzqr...@forum.dlang.org... dpj is a mini-ide for the D programming language. http://my.opera.com/run3/blog/2012/05/20/dpj That's a good start! Not bad. Is it written in D? A few notes: - It's much faster to just pass all the files to dmd at once and compile/link all in one step. So, instead of this: dmd -wi -c a.d -ofoutput\a.d dmd -wi -c b.d -ofoutput\b.d dmd -ofa.exe output\a.obj output\b.obj Just do this: dmd -wi -ofa.exe -odoutput a.d b.d It's a lot faster, plus in my experience compiling separately can sometimes lead to linking problems (somehting to do with how dmd handles templates, I think). Compiling it all in one go can be really slow for small edits in large projects, though. - To support things like ldc, gdc and dvm (via ldmd, gdmd, dvm-current-dc.bat, etc...), the config file should take a path to the actual exe or bat (such as dmd.exe) the users wants to run, instead of just the path to dmd.exe. So like dmd_path=C:\D\dmd2\windows\bin\dmd.exe insetad of dmd_path=C:\D\dmd2\windows\bin - The first couple times I made a new project I got some error about it not being able to copy a template. But then it seemed to work ok anyway. I don't remember exactly what it said, and it doesn't seem to be happening anymore (don't know why) so I can't check. - It *seems* to start up with a default blank project, but you can't use it. You still have to go to File-New project. That's a little confusing. - It'd be good to be able to select and copy the text in the compilation panel at the bottom. - It'd be intuitive to be able to add files to a project by right-clicking D source files or whatever and then have Add file(s)... in a drop-down menu. - More features and configurability with both building and interface would be nice to have in later versions, ie more bells and whistles ;) I love that the interface is super-fast, light on memory, and uses the native system controls. And the automatic build management and Help links are really nice to have. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Introducing vibe.d!
On 27-04-2012 16:50, Sean Kelly wrote: In _d_throw call abort(). That'll give you a core file. On Apr 26, 2012, at 11:13 PM, Sönke Ludwigslud...@outerproduct.org wrote: Am 27.04.2012 04:19, schrieb Andrei Alexandrescu: On 4/26/12 3:30 PM, Jesse Phillips wrote: On Thursday, 26 April 2012 at 22:05:29 UTC, Robert Clipsham wrote: On 26/04/2012 21:46, Sönke Ludwig wrote: vibe.d This looks awesome! Also on reddit: http://www.reddit.com/r/programming/comments/su9la/vibed_asynchronous_io_that_doesnt_get_in_your_way/ and hacker news: https://news.ycombinator.com/item?id=3896197 Now look what you did, you killed it. Are the Vibe people on this? Though the intent is very nice, this is not looking great right now. Andrei It's back up now and I've made a small watchdog script to avoid this in the future. The problem is that I'm currently using a vibe based reverse proxy instead of nginx and it rarely has an uncaught exception that unfortunately has never been logged with stack trace. I wish I could have made this part rock solid before going live but someone else annouced it before me so it was too late. Why don't we make that some kind of function in druntime? like setAbortOnThrow(bool) or whatever. -- - Alex
Re: Jumping on the bandwagon - DDCPU-16
On 22-04-2012 20:12, Marco Leise wrote: Am Sun, 22 Apr 2012 11:55:35 +0200 schrieb Bernard Helyerb.hel...@gmail.com: https://github.com/bhelyer/DDCPU-16 DDCPU-16 is a D implementation of Notch's (of Minecraft fame) DCPU-16, a fictional 16 bit CPU for his upcoming game, 0x10c. More info at http://0x10c.com, including specs. You'll see a grand total of two source files, and one is only really there for my testing. The only interesting module is dcpu16.cpu, which contains a class CPU with two public methods of note: load(ushort[]) to load code and run(int) to run it for a minimum number of cycles. The CPU code is completely freestanding, with no dependencies (even on Phobos) and is @safe ready, and pure where possible. Manu is planning on hooking up some virtual hardware to it (which is described in basic form elsewhere). No real reason for this, just needed something to fill a Sunday. I've only tested it to the extent that I've stepped through Notch's example in the spec (the one loaded in main.d) and verified that works, but I'm sure there'll be more bugs lurking. If you find the bugs that I'm sure are still lurking, create an issue on GitHub. -Bernard. Haha, just today I watched a video about it and thought DCPU .. well if that isn't a call for action ;) Unfortunately Java has a native unsigned 16-bit data type (char). Otherwise Notch would probably have chosen D for writing 0x10^c. ;) As with Minecraft, I like the vision and technical realisation, but I wouldn't pay for and play them. I'm sure you had fun writing the CPU simulator. We wrote one (as a class project) at a vocational school a while back - in Java. It was for an 8086 and I did the CPU core logic. Most functions could be classified (like logical OR/XOR/..., accesses regs,mem,...) but for the rest I didn't find any pattern and called the corresponding class (translated) ThenAMiracleHappens, referring to the well known comic: http://blog.wisefaq.com/wp-content/uploads/2008/05/amoh-small.jpg It was spiced with a two lines long ternary operator :? expression and no further comments. :D I think the fact that you have to use 'char' as 'ushort' in Java says enough about the language and VM. ;) /me runs -- - Alex
Re: Pull requests processing issue
On 18-04-2012 11:00, Trass3r wrote: I think the problem of ~100 open pull requests needs to be faced better. People that see their patches rot in that list probably don't feel rewarded enough to submit more patches. So true. I won't do any further work if it's in vain anyway. Also I regularly have to rebase my one cause of conflicts, which is annoying. I really wonder what Walter's doing. Is he still running the whole testsuite instead of relying on the autotester? Just looking at the auto tester, there seems to be tons of stuff that can readily be merged... -- - Alex
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: 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: 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 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 2.059 ??
On 12-04-2012 20:49, Alvaro wrote: The changelog mentions DMD 2.059 as released on April 1, 2012, but there is no link to it. Is it released? http://dlang.org/changelog.html It's not released yet. This is why listing the next release on that page is a bad idea... -- - Alex
Re: GDC goes github
On 18-03-2012 13:39, Iain Buclaw wrote: Morning All, I have created a new GDC project on github, where I hope people will help contribute and continue development of the compiler there. https://github.com/gdc-developers I've been told to cue Walter asking to rename the organisation to D-Programming-GDC. :o) I have also bought a new server, and will be getting a site up in due course. http://dgnu.org/ http://gdcproject.org/ Regards Iain. Great news! This will make it a lot easier to send patches. -- - Alex
Re: It's official: The D Programming Language will participate to GSoC 2012!
On 16-03-2012 21:04, alex wrote: On Friday, 16 March 2012 at 19:06:01 UTC, Andrei Alexandrescu wrote: On 3/16/12 1:32 PM, Steven Schveighoffer wrote: On Fri, 16 Mar 2012 14:24:38 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Just got the acceptance message. This is great news! If you consider being a mentor, please apply as described in http://dlang.org/gsoc2012.html. Thanks! You really think Google summer of code is going to sponsor development of iPhone compatibility? :) Not that I wouldn't welcome this with open arms... They accepted our application and we have considerable freedom to choose our projects. Andrei Congratulations! Concerning projects, what about my Mono-D project - I am a student actually, so I really would like to contribute to D community by going on with developing this IDE (plugin), just with the difference that I'm also doing it for the GSoC event? I mean, plenty of stuff (like relatively nice code completion [yeah, advertising oneself sucks, I know]) has been done so far - but another plenty of things are left to-do, so why not doing them within those 3 months? :) http://mono-d.alexanderbothe.com https://github.com/aBothe/Mono-D I think you just need to find someone who can mentor the project and there'd be no problem in doing this at all. -- - Alex
Re: Pegged, From EBNF to PEG
On 13-03-2012 17:17, Dmitry Olshansky wrote:
On 12.03.2012 17:45, bls wrote:
On 03/13/2012 04:28 AM, Dmitry Olshansky wrote:
On 12.03.2012 16:43, bls wrote:
On 03/10/2012 03:28 PM, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
Just WOW!
Nice to have on your WIKI would be a EBNF to PEG sheet.
Wirth EBNF Pegged
A = BC. A - B C
A = B|C. A - C / C
Maybe A - B / C. And even then it's not exactly equivalent if the
grammar was ambiguous.
Imagine: B - a, C - aa
PEG is pretty new to me. Can you elaborate a bit ?
PEG defines order of alternatives, that is pretty much like a top-down
recursive descent parser would parse it. Alternatives are tried from
left to right, if first one fails, it tries next and so on.
In an example I give B is always picked first and so C is never ever
looked at.
Somewhat less artificial example:
Literal - IntL| FloatL
FloatL - [0-9]+(.[0-9]+)?
IntL - [0-9]+
If you change it to: Literal - FloatL| IntL then integer literals would
get parsed as floating point.
My mistake.. cleaned up stuff..
Pegged Wirth EBNF
Sequence
A - B C A = BC.
B or C
A - B / C A = B|C.
Zero or one B
A - B? A = [B].
Zero or more Bs
A - B* A = {B}.
One or more Bs
A - B+ Not available
PEG description of EBNF
EBNF - Procuction+
Production - Identifier '=' Expression '.'
Expression - Term ( '|' Term)*
Term - Factor Factor*
Factor - Identifier / Literal / '[' Expression ']' / '{' Expression '}'
/ '(' Expression ')'
lowerCase - [a-z]
upperCase - [A-Z]
Identifier - (lowerCase / upperCase) (lowerCase / upperCase)*
Why not:
Identifier - [a-zA-Z]+
That was an illustrative example from the Pegged docs. But yeah, you
should just use a range; reads nicer.
Literal - (' .+ ') / ('' .+ '')
This needs escaping. Plain '.+' in pattern asks for trouble 99% of time.
Still not sure if this is correct. Especially :
Term - Factor Factor*
Another thing I never really understand is the production order, In
other words : Why not top down ..
Start :
lowerCase - [a-z]
upperCase - [A-Z]
Identifier - (lowerCase / upperCase) (lowerCase / upperCase)*
End :
EBNF - Procuction+
where End is Root..
In fact grammars are usually devised the other way around, e.g.
Start:
Program - ...
Ehm... what the whole program is exactly ? Ok, let it be Declaration*
for now. What kind of declarations do we have? ... and so on. Latter
grammars get tweaked and extended numerous times.
At any rate production order has no effect on the grammar, it's still
the same. The only thing of importance is what non-terminal considered
final (or start if you are LL-centric).
TIA, Bjoern
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 08:22, Philippe Sigaud wrote: On Sun, Mar 11, 2012 at 00:34, Alex Rønne Petersenxtzgzo...@gmail.com wrote: Admittedly I have not heard of PEGs before, so I'm curious: Is this powerful enough to parse a language such as C? I think so. But you'd have to do add some semantic action to deal with typedefs and macros. Oh, I should have mentioned I only meant the actual language (ignoring the preprocessor). Why do you need semantic actions for typedefs though? Can't you defer resolution of types until after parsing? People parsed Java and Javascript with them. I personnally never used Pegged for more than JSON and custom formats, but I intend to try the D grammar. -- - Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
Question: Are the generated parsers, AST nodes, etc classes or structs?
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
By the way, bootstrap.d seems to fail to build at the moment:
../pegged/utils/bootstrap.d(1433): found ':' when expecting ')'
following template argument list
../pegged/utils/bootstrap.d(1433): members expected
../pegged/utils/bootstrap.d(1433): { } expected following aggregate
declaration
../pegged/utils/bootstrap.d(1433): semicolon expected, not '!'
../pegged/utils/bootstrap.d(1433): Declaration expected, not '!'
../pegged/utils/bootstrap.d(1466): unrecognized declaration
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 16:02, Alex Rønne Petersen wrote:
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
By the way, bootstrap.d seems to fail to build at the moment:
.../pegged/utils/bootstrap.d(1433): found ':' when expecting ')'
following template argument list
.../pegged/utils/bootstrap.d(1433): members expected
.../pegged/utils/bootstrap.d(1433): { } expected following aggregate
declaration
.../pegged/utils/bootstrap.d(1433): semicolon expected, not '!'
.../pegged/utils/bootstrap.d(1433): Declaration expected, not '!'
.../pegged/utils/bootstrap.d(1466): unrecognized declaration
Also, I have sent a pull request to fix the build on 64-bit:
https://github.com/PhilippeSigaud/Pegged/pull/1
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 18:06, Philippe Sigaud wrote: On Sun, Mar 11, 2012 at 00:34, Alex Rønne Petersenxtzgzo...@gmail.com mailto:xtzgzo...@gmail.com wrote: [Parsing C?] I think so. But you'd have to do add some semantic action to deal with typedefs and macros. Oh, I should have mentioned I only meant the actual language (ignoring the preprocessor). OK. I admit I downloaded the C spec online, but was a bit taken aback by the size of it. mot of it was the definition of the standard library, but still... Why do you need semantic actions for typedefs though? Can't you defer resolution of types until after parsing? Yes, that the way I'd do it. But some people seem to want to do it while parsing. Maybe it blocks some parsing, if the parser encounter an identifier where there should be a type? Hm, I don't *think* C has such ambiguities but I could well be wrong. In any case, if it can handle the non-ambiguous case, that's enough for me. :) -- - Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 18:19, Philippe Sigaud wrote: Hm, I don't *think* C has such ambiguities but I could well be wrong. In any case, if it can handle the non-ambiguous case, that's enough for me. I wanted to tackle D this week, but I might as well begin with C :) Do you happen to have any handy and readable EBNF grammar for C? At least for D, I have dlang.org http://dlang.org. Yep, see: http://ssw.jku.at/Coco/ (C.atg) Coco/R is more or less EBNF. -- - Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 18:17, Philippe Sigaud wrote:
By the way, bootstrap.d seems to fail to build at the moment:
../pegged/utils/bootstrap.d(1433): found ':' when expecting ')'
following template argument list
../pegged/utils/bootstrap.d(1433): members expected
../pegged/utils/bootstrap.d(1433): { } expected following aggregate
declaration
../pegged/utils/bootstrap.d(1433): semicolon expected, not '!'
../pegged/utils/bootstrap.d(1433): Declaration expected, not '!'
../pegged/utils/bootstrap.d(1466): unrecognized declaration
Hmm, it compiled for me a few hours ago. I'll see if I broke something
while pushing.
I'll also try to make the whole grammar-modification process easier.
Since users can modify Pegged own grammar, I might as well make that
fluid and easy to do.
I'll put the Pegged grammar as a string in a separate module and create
a function that does the rest: modify the string, it will recompile the
entire grammar for you.
Is bootstrap.d currently essential to actually use Pegged?
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
Hm, since ' is used in the grammar of Pegged, how do I express it in my
grammar spec? Is there a predefined rule for it, or is \' supposed to work?
--
- Alex
Re: Pegged, a Parsing Expression Grammar (PEG) generator in D
On 11-03-2012 00:28, Philippe Sigaud wrote:
Hello,
I created a new Github project, Pegged, a Parsing Expression Grammar
(PEG) generator in D.
https://github.com/PhilippeSigaud/Pegged
docs: https://github.com/PhilippeSigaud/Pegged/wiki
PEG: http://en.wikipedia.org/wiki/Parsing_expression_grammar
The idea is to give the generator a PEG with the standard syntax. From
this grammar definition, a set of related parsers will be created, to be
used at runtime or compile time.
Usage
-
To use Pegged, just call the `grammar` function with a PEG and mix it
in. For example:
import pegged.grammar;
mixin(grammar(
Expr - Factor AddExpr*
AddExpr - ('+'/'-') Factor
Factor - Primary MulExpr*
MulExpr - ('*'/'/') Primary
Primary - Parens / Number / Variable / '-' Primary
Parens - '(' Expr ')'
Number ~ [0-9]+
Variable - Identifier
));
This creates the `Expr`, `AddExpr`, `Factor` (and so on) parsers for
basic arithmetic expressions with operator precedence ('*' and '/' bind
stronger than '+' or '-'). `Identifier` is a pre-defined parser
recognizing your basic C-style identifier. Recursive or mutually
recursive rules are OK (no left recursion for now).
To use a parser, use the `.parse` method. It will return a parse tree
containing the calls to the different rules:
// Parsing at compile-time:
enum parseTree1 = Expr.parse(1 + 2 - (3*x-5)*6);
pragma(msg, parseTree1.capture);
writeln(parseTree1);
// And at runtime too:
auto parseTree2 = Expr.parse( 0 + 123 - 456 );
assert(parseTree2.capture == [0, +, 123, -, 456]);
Features
* The complete set of PEG operators are implemented
* Pegged can parse its input at compile time and generate a complete
parse tree at compile time. In a word: compile-time string (read: D
code) transformation and generation.
* You can parse at runtime also, you lucky you.
* Use a standard and readable PEG syntax as a DSL, not a bunch of
templates that hide the parser in noise.
* But you can use expression templates if you want, as parsers are all
available as such. Pegged is implemented as an expression template, and
what's good for the library writer is sure OK for the user too.
* Some useful additional operators are there too: a way to discard
matches (thus dumping them from the parse tree), to push captures on a
stack, to accept matches that are equal to another match
* Adding new parsers is easy.
* Grammars are composable: you can put different
`mixin(grammar(rules));` in a module and then grammars and rules can
refer to one another. That way, you can have utility grammars providing
their functionalities to other grammars.
* That's why Pegged comes with some pre-defined grammars (JSON, etc).
* Grammars can be dumped in a file to create a D module.
More advanced features, outside the standard PEG perimeter are there to
bring more power in the mix:
* Parametrized rules: `List(E, Sep) - E (Sep E)*` is possible. The
previous rule defines a parametrized parser taking two other parsers
(namely, `E` and `Sep`) to match a `Sep`-separated list of `E`'s.
* Named captures: any parser can be named with the `=` operator. The
parse tree generated by the parser (so, also its matches) is delivered
to the user in the output. Other parsers in the grammar see the named
captures too.
* Semantic actions can be added to any rule in a grammar. Once a rule
has matched, its associated action is called on the rule output and
passed as final result to other parsers further up the grammar. Do what
you want to the parse tree. If the passed actions are delegates, they
can access external variables.
Philippe
Admittedly I have not heard of PEGs before, so I'm curious: Is this
powerful enough to parse a language such as C?
--
- Alex
Enhanced D syntax highlighting for Sublime Text 2
https://github.com/alexrp/st2-d I plan to have it merged into ST2 proper if I can somehow get in touch with the dev(s)... -- - Alex
Re: Our second mentor: Alex Rønne Petersen
On 04-03-2012 21:52, Andrei Alexandrescu wrote: Please join me in welcoming Alex Rønne Petersen as a mentor! We believe he will bring great expertise and value to our ranks. Andrei Thanks :) In case anyone is wondering, I applied primarily to mentor any possible projects on MCI: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas#ManagedCompilerInfrastructureMCI -- - Alex
Re: D in Academia
On 03-03-2012 20:02, Chuck Allison wrote: FYI: TDPL is a required text for CS 4450, Analysis of Programming Languages, at Utah Valley University starting Fall 2012. We'll study ML and D (and Prolog if time allows). Wow, that's great news! -- - Alex
libgc-d: Binding to the Boehm-Demers-Weiser C/C++ GC
Hi, libgc-d is a binding to the libgc garbage collection library (also known as the Boehm-Demers-Weiser GC). This library is primarily useful in the D world for programming language implementations and virtual machines, as D has a built-in GC (though, nothing stops you from using libgc-d for your normal allocations). https://github.com/lycus/libgc-d It's still very much alpha quality. I've only done some small, silly tests, but everything *seems* to work. See README.md for limitations, build instructions, etc. Note also that this binding is just that - a binding. It doesn't provide any high-level wrappers around libgc. Feedback welcome. :) -- - Alex
Re: D to Javascript converter (a hacked up dmd)
On 01-03-2012 19:04, Ary Manzana wrote: On 2/29/12 2:34 PM, Alex Rønne Petersen wrote: On 29-02-2012 18:32, Andrei Alexandrescu wrote: On 2/26/12 9:51 PM, Adam D. Ruppe wrote: https://github.com/downloads/adamdruppe/dtojs/dtojs.zip [snip] That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei Avoiding writing JS directly in web apps comes to mind. I think it's cool you can convert D to JS, but I don't see why anyone would want to do it. 1. JS is a superior language: variables are dynamic and are not bound to just one single type during their lifetime. JS objects can store any property. You're arguing with a crowd gathered around a statically typed language. I think we can predict what this argument will lead to. :) 2. JS funcions are much easier to write (no need to declare types) and also to pass around (no need to write ). If you'd like to annotate variables, you could use Closure: https://developers.google.com/closure/compiler/docs/js-for-compiler See the above. 3. With JS you don't have to compile and run your code (well, I guess you could make something smart in D for that). ? The D - JS converter just translates it. It's no different from running e.g. the CoffeeScript compiler. 4. If you write JS you can debug it in the browser. No need to track back to the original source code. Valid argument. Maybe we can make the D - JS converter help in some way here? 5. If you don't like JS syntax or verbosity, you can use CoffeeScript, which is just a syntax rewriter, not a language/paradigm shift: http://coffeescript.org/ Don't even get me started on the horrible features in CoffeeScript. The guy who wrote the language literally had no clue what he was doing (he admitted to reading some make your own language book), and it isn't much better than JavaScript in terms of odd behavior and weird design decisions. 6. Javascript objects have some built-in properties that are different from D. So implementing those in D would make their performance worse (but you can always hard-code those functions into the compiler and translate them directly to their JS equivalent). Can you be a little more specific here? The good thing about writing in D is that you could probably get some IDE for autocompletion and such. You might also like to type things instead of using dynamic types. To be fair, excellent JS IDEs exist already; Visual Studio has great JS auto-completion, and ReSharper enhances it a lot too. -- - Alex
Re: D to Javascript converter (a hacked up dmd)
On 29-02-2012 18:32, Andrei Alexandrescu wrote: On 2/26/12 9:51 PM, Adam D. Ruppe wrote: https://github.com/downloads/adamdruppe/dtojs/dtojs.zip [snip] That's interesting. So the idea is to make an entire subset of D convertible to Javascript? What use cases do you have in mind? Andrei Avoiding writing JS directly in web apps comes to mind. -- - Alex
Re: GoingNative 6: The D Episode with Walter Bright and Andrei Alexandrescu
On 23-02-2012 07:51, Walter Bright wrote: On 2/22/2012 7:51 PM, bearophile wrote: Andrei says that some new languages suffer because they have a poor implementation, because creating the base for a language is a lot of work. Today this is issue is much less of a problem, new languages are implemented on the JavaVM, Using the JVM forces your program into Java semantics. For example, there are no structs in the JVM bytecode. No pointers, either. Nor unsigned types. Your new language is fairly boxed in to being a rehash of Java semantics. I still cannot fathom how the Scala guys thought using the JVM was a good idea. DotNetVM. Cristi's D compiler on .NET had large problems because array slicing was not expressible in the .NET intermediate code. It's not nearly as bad as the JVM in that regard, but it's still limited. I assume the problem here was the .ptr property? I can't think of anything else about array slices that would be problematic in CIL. System languages are implemented with LLVM. That works if your language is expressible as C, because LLVM is a C/C++ back end. If your language has different semantics (like how Go does stacks), using LLVM can be a large problem. I don't think that's true. D, Rust, C# (CIL in general), Cray, ActionScript, Python, Java, Lua, Haskell, and many others have been compiled with LLVM successfully. LLVM is very much engineered for C and C++, but it has many other features that those languages don't make use of at all (see for example the precise GC support; and this is not even something Apple uses, as their Obj-C GC is conservative). There is also the language-specific support for OCaml's precise stack maps. Also, LLVM has segmented stacks on x86 these days. That said, LLVM is definitely not as easy to use for managed languages as it is for systems/native languages. So, while the design of LLVM certainly is driven by Clang primarily, it's not as if they don't welcome non-C family features. Note that early C++ compilers suffered badly when they were forced into using C back ends, because C++ wanted new features (like COMDATs) which are not expressible in C and so not supported by C back ends. Ditto for any language feature that needs something in the back end that C/C++ doesn't need. Regarding the comparison between dynamic languages like Python or Ruby and D: what Andrei has said is not fully fair. A simple common scripting task: read the lines of a text file and put them in a hash. This is probably faster in Python compared to D. I am willing to write a benchmark too, if asked. That would be comparing library code, not language code. Much of Python's implementation is in C, not Python. Regarding what Walter has said, that most of the code of D applications will be @safe: if safe code gets (or has to get) so common as he says, then it will be good for the D compiler to learn some tricks to avoid (optimize away) array bound tests in some cases. I looked into this years ago. Very little of array bounds checking can be optimized away. I've been working on optimizers for 25 years now, including a native code generating Java compiler, and I do know a few things about how to do arrays. In Mono, we found that ABC removal was actually beneficial in some code; consider for example allocating small static arrays locally and indexing them with constants (or very simple expressions). Clang has some pretty good ideas, like the spell checker on undefined identifiers. But others talked about in the spiel at GoingNative have been in compilers for 30 years. -- - Alex
Re: GoingNative 6: The D Episode with Walter Bright and Andrei Alexandrescu
On 24-02-2012 05:06, Jeff Nowakowski wrote: On 02/23/2012 11:57 AM, Alex Rønne Petersen wrote: I still cannot fathom how the Scala guys thought using the JVM was a good idea. It gave them a good garbage collector (an area that has held D's performance back for years), a large library via Java compatibility, and a population of users to appeal to. Scala probably wouldn't have succeeded if it was just another object-oriented language without ties to the JVM. They could have used the CLI. Both MS.NET and Mono have good garbage collectors, and Mono in particular has SIMD intrinsics, an LLVM back end, etc. I've heard a lot of people complain that Scala doesn't run on .NET. -- - Alex
Re: Visual D 0.3.30 released: Code completion from semantic analysis on the horizon
On 07-01-2012 15:41, Rainer Schuetze wrote: Hi, I'd like to announce the release of a new version of Visual D. Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005-2010 and 11 as well as the free Visual Studio Shells. Highlights of this version 0.3.30 include - syntax highlighting improvements regarding scope(guard), __ctfe, is, in and predefined versions - added checkbox for options -gs and -property to project configuration - debugger and build improvements - experimental: code completion and tool tips from semantic analysis of source code See http://www.dsource.org/projects/visuald/wiki/VersionHistory for a full list of changes. The code completion from semantic analysis is not complete yet, but I think it can already be very helpful. You'll have to enable it explicitly in the D Language options due to it's experimental status. The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald Have fun, Rainer Great news! How should the new experimental code completion be triggered, exactly? - Alex
Re: dmd 2.057 release
On 03-01-2012 08:49, Caligo wrote: Considering the rate at which bugs are being discovered and fixed, would it be possible to shorten the release cycle, say, every 2-3 weeks instead of 1-2 months? Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. - Alex
Re: dmd 2.057 release
On 03-01-2012 15:56, Robert Clipsham wrote: On 03/01/2012 14:49, Alex Rønne Petersen wrote: On 03-01-2012 08:49, Caligo wrote: Considering the rate at which bugs are being discovered and fixed, would it be possible to shorten the release cycle, say, every 2-3 weeks instead of 1-2 months? Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. - Alex Beta releases are made weeks before an actual release for testing on this mailing list: http://lists.puremagic.com/cgi-bin/mailman/listinfo/dmd-beta Web interface: http://dfeed.kimsufi.thecybershadow.net/discussion/group/dmd-beta I mean something weekly or bi-weekly. Beta releases are only made very close to the actual release. - Alex
Re: dmd 2.057 release
On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. - Alex
Re: dmd 2.057 release
On 03-01-2012 20:25, Walter Bright wrote: On 1/3/2012 10:55 AM, Alex Rønne Petersen wrote: On 03-01-2012 19:47, Walter Bright wrote: On 1/3/2012 6:49 AM, Alex Rønne Petersen wrote: Perhaps some kind of experimental releases would be better. It could help getting new features out to the community (and thus tested) faster. We call them betas g. But anyone can pull the latest from github and use it, many do. That's not very practical for most users. Some kind of ready-to-download builds would be much better. As others suggested, the auto-tester publishing builds for download would be ideal. Using a nightly build is not very practical for most users, either, probably the same group. I don't know. There are many things in DMD that are far from bug-free, and some people would like to actually use those features. So when fixes are committed, it'd be nice to just be able to switch to a nightly build. We have to bear in mind that while D itself is fairly mature, it is still very much an evolving language, and thus, as is the compiler. For this reason, sticking to a stable release is not always practical. - Alex
Re: libffi-d: D binding to libffi
Hi Andrej, Sorry for the late response (for some reason, my news reader had marked this thread as read). There's a few DLL's floating around for libffi, however none of them seem to have the symbol ffi_prep_cif_var which seems to be needed for variadic functions. I can version variadic support out and compile your bindings, the tests will work fine on win32. I've also tried compiling libffi on my own but had no success. ffi_prep_cif_var doesn't seem to be available in any Windows builds (Cygwin, MinGW, or otherwise) of libffi for whatever reason. I'll version it out on Windows for now, as you suggested. I haven't managed to get a MinGW build of libffi working so far, but I did manage to get one working under Cygwin. Build libffi like this: $ ./configure --enable-static=yes --enable-shared=no $ make Now you should have i686-pc-cygwin/.libs/libffi.a. You'll also need your Cygwin installation's libgcc.a: $ cd i686-pc-cygwin/.libs $ ar -r libffi.a /lib/gcc/i686-pc-cygwin/4.5.3/libgcc.a Now you need to convert the .a to an OMF .lib. You'll need objconv.zip from this page: http://www.agner.org/optimize/ $ objconv -fomf -nu libffi.a libffi.lib libffi.lib should now be linkable with DMD. (I long for the day DMD doesn't use OMF.) I can make a pull with the import lib, the DLL (it's only 99KB), and the versioned out sections, if you'd like that. I prefer keeping the binaries out of Git for various portability, licensing, etc issues. That being said, I think we could upload .libs/.dlls as downloads on the GitHub page. The question is whether we should put .libs or .dlls there? Personally, I think .libs are easier to work with when using DMD. Thanks for the input! - Alex
Re: libffi-d: D binding to libffi
On 15-12-2011 09:14, Alex Rønne Petersen wrote: Hi Andrej, Sorry for the late response (for some reason, my news reader had marked this thread as read). There's a few DLL's floating around for libffi, however none of them seem to have the symbol ffi_prep_cif_var which seems to be needed for variadic functions. I can version variadic support out and compile your bindings, the tests will work fine on win32. I've also tried compiling libffi on my own but had no success. ffi_prep_cif_var doesn't seem to be available in any Windows builds (Cygwin, MinGW, or otherwise) of libffi for whatever reason. I'll version it out on Windows for now, as you suggested. I haven't managed to get a MinGW build of libffi working so far, but I did manage to get one working under Cygwin. Build libffi like this: $ ./configure --enable-static=yes --enable-shared=no $ make Now you should have i686-pc-cygwin/.libs/libffi.a. You'll also need your Cygwin installation's libgcc.a: $ cd i686-pc-cygwin/.libs $ ar -r libffi.a /lib/gcc/i686-pc-cygwin/4.5.3/libgcc.a Now you need to convert the .a to an OMF .lib. You'll need objconv.zip from this page: http://www.agner.org/optimize/ $ objconv -fomf -nu libffi.a libffi.lib libffi.lib should now be linkable with DMD. (I long for the day DMD doesn't use OMF.) I can make a pull with the import lib, the DLL (it's only 99KB), and the versioned out sections, if you'd like that. I prefer keeping the binaries out of Git for various portability, licensing, etc issues. That being said, I think we could upload .libs/.dlls as downloads on the GitHub page. The question is whether we should put .libs or .dlls there? Personally, I think .libs are easier to work with when using DMD. Thanks for the input! - Alex Correction: It seems as though that function has disappeared on my Linux system! It has most probably been deprecated entirely, so I have just removed it from libffi-d. - Alex
libffi-d: D binding to libffi
Hi folks, Since I needed a way to call arbitrary C functions dynamically (while knowing their pointer + signature), I decided to write a binding to libffi for D. https://github.com/lycus/libffi-d There is heavy focus on simplicity: It is composed of 3 enums (FFIType, FFIStatus, FFIInterface), one alias (FFIFunction), and one function (ffiCall). The API is fairly self-describing, so I haven't really spent a whole lot of time on docs. For examples, see the tests sub-directory (please also read 'info libffi'). Known limitations: * No access to the closure API. * No access to the 'raw' API (which is undocumented in libffi anyway). Known issues: * Detection of soft float ABIs is not currently done (due to limitations in most D compilers). * ABI overriding for some rare Unix ABIs is not currently possible. * Currently no good way to actually use the library on Windows. Anyone who knows their stuff about DMD and DLLs on Windows, please do contribute. ;) If you run into any issues, please throw a test case at the GitHub issue tracker and I'll look into it. Enjoy! - Alex
Re: Release: MinGW GCC 4.6.1 GDC 1.070/2,.055
On 06-12-2011 02:46, Trass3r wrote: Why is D1 still the default? Because this is the first release where I felt D2 was capable of being the default and I forgot about it until writing the post. It also requires some reworking of the changes that enable dual compilers. but why is there a zip version anyway? I posted with a zip extension in the original post, so rather than letting everyone get an 404 error, I just uploaded a zip file. I see. btw, is there something like gdmd for Windoze too? That would be very helpful, indeed! I don't feel like rewriting all of my makefiles to use GDC's parameter syntax. ;) - Alex
Re: D Addin for MonoDevelop on Linux
On 06-12-2011 07:06, alex wrote: 1) Code completion can be enabled via adding phobos library paths etc. to the compiler configuration(s). There's a tutorial how to do this in the 'Getting Started' section of the project site. That did the trick, thanks! 2) You can add per-project (both linker and compiler) parameters. Extra include paths and library references, of course. Oh wow, completely missed the relevant section in project options. Oops! 3) Yes. Great! - Alex
Re: D Addin for MonoDevelop on Linux
On 05-12-2011 20:35, alex wrote:
Hi everyone,
I just want to announce the first alpha release of Mono-D.
FYI, Mono-D is a MonoDevelop AddIn which provides code completion/refactoring
features and project management for D.
So, you'll be able to enjoy comfort-features also on non-windows systems!
Just check out http://mono-d.sourceforge.net
Please feel free to leave comments/critics etc. on that blog!
Hm, it doesn't seem like the add-in uses smart indentation. For example:
void main()
{hit enter
doesn't indent as it normally would in e.g. the C# add-in. Is this a bug
or just not supported yet?
- Alex
Re: gl3n - linear algebra and more for D
On 03-12-2011 23:36, David wrote:
Am 03.12.2011 22:32, schrieb Kiith-Sa:
David wrote:
Hello,
I am currently working on gl3n - https://bitbucket.org/dav1d/gl3n - gl3n
provides all the math you need to work with OpenGL, DirectX or just
vectors and matrices (it's mainly targeted at graphics - gl3n will never
be more then a pure math library). What it supports:
* vectors
* matrices
* quaternions
* interpolation (lerp, slerp, hermite, catmull rom, nearest)
* nearly all glsl functions (according to spec 4.1)
* some more cool features, like templated types (vectors, matrices,
quats), cool ctors, dynamic swizzling
And the best is, it's MIT licensed ;). Unfortunatly there's no
documentation yet, but it shouldn't be hard to understand how to use it,
if you run anytime into troubles just take a look into the source, I did
add to every part of the lib unittests, so you can see how it works when
looking at the unittests, furthermore I am very often at #D on freenode.
But gl3n isn't finished! My current plans are to add more interpolation
functions and the rest of the glsl defined functions, but I am new to
graphics programming (about 4 months I am now into OpenGL), so tell me
what you're missing, the chances are good that I'll implement and add
it. So let me know what you think about it.
Before I forget it, a bit of code to show you how to use gl3n:
vec4 v4 = vec4(1.0f, vec3(2.0f, 3.0f, 4.0f));
vec4 v4 = vec4(1.0f, vec4(1.0f, 2.0f, 3.0f, 4.0f).xyz)); // dynamic
swizzling with opDispatch
vec3 v3 = my_3dvec.rgb;
float[] foo = v4.xyzzzwzyyxw // not useful but possible!
glUniformMatrix4fv(location, 1, GL_TRUE, mat4.translation(-0.5f, -0.54f,
0.42f).rotatex(PI).rotatez(PI/2).value_ptr); // yes they are row major!
mat3 inv_view = view.rotation;
mat3 inv_view = mat3(view);
mat4 m4 = mat4(vec4(1.0f, 2.0f, 3.0f, 4.0f), 5.0f, 6.0f, 7.0f, 8.0f,
vec4(...) ...);
struct Camera {
vec3 position = vec3(0.0f, 0.0f, 0.0f);
quat orientation = quat.identity;
Camera rotatex(real alpha) { orientation.rotatex(alpha); return this; }
Camera rotatey(real alpha) { orientation.rotatey(alpha); return this; }
Camera rotatez(real alpha) { orientation.rotatez(alpha); return this; }
Camera move(float x, float y, float z) {
position += vec3(x, y, z);
return this;
}
Camera move(vec3 s) {
position += s;
return this;
}
@property camera() {
//writefln(yaw: %s, pitch: %s, roll: %s,
degrees(orientation.yaw), degrees(orientation.pitch),
degrees(orientation.roll));
return mat4.translation(position.x, position.y, position.z) *
orientation.to_matrix!(4,4);
}
}
glUniformMatrix4fv(programs.main.view, 1, GL_TRUE,
cam.camera.value_ptr);
glUniformMatrix3fv(programs.main.inv_rot, 1, GL_TRUE,
cam.orientation.to_matrix!(3,3).inverse.value_ptr);
I hope this gave you a little introduction of gl3n.
- dav1d
I looked at your project yesterday (found it on derelict forums)
and it looks really good. Currently I'm using my own code for
vectors/matrices but a dedicated library could be better.
My comments:
Not sure if DMD will do a good job optimizing your code atm
(probably no way around this but to wait - uglifying the code would serve
no purpose)
In the future, SSE support would be nice (maybe will be easier to do
if we
ever get SSE intrinsics)
Seems like most of the code is in linalg.d - wouldn't it be more
maintainable
to have it separated for each struct, and then public import it
through one
module for easy usage?
I'm doing a lot of 2D work, and could use at least a rectangle/aabbox
struct
(if I use your lib, I'll implement rectangles on top of it anyway).
Some other structs might also be useful (3D aabbox, circle, sphere?)
Although, if you want to be as close to GLSL as possible, this might
not be a good idea.
Most D projects are under the Boost license.
If you want to get this to Phobos,
(I'd like something like this in Phobos :P)
I recommend using that license
(IANAL, but I don't see much difference between MIT and Boost)
The GLSL style is good if you want it as close to GLSL as possible,
but it'd be good to have more D-style aliases (again hinting at Phobos).
(Personally I'd probably use the GLSL style, though)
Hi,
Thanks for your feedback. SSE is planed, but it will be the last step,
optimization at the end. Well gl3n shouldn't be the bottleneck anyways,
because it's normally the GPU.
I've already thought about splitting linalg into 3 different files (also
it was suggested by some people), but I dont like how D(md) handles
imports, something like this would be cool:
import gl3n.linalg.matrix;
import gl3n.linalg.vector;
import gl3n.linalg.quaternion;
import gl3n.linalg; // this would import
gl3n.linalg.matrix/vector/quaternion publically
Like __init__.py in Python, unfortunatly this isn't supported (yet?).
It is also planed to add some useful stuff for graphics programming,
like as you
Re: gl3n - linear algebra and more for D
On 04-12-2011 14:22, David wrote:
Am 04.12.2011 14:16, schrieb Alex Rønne Petersen:
On 03-12-2011 23:36, David wrote:
Am 03.12.2011 22:32, schrieb Kiith-Sa:
David wrote:
Hello,
I am currently working on gl3n - https://bitbucket.org/dav1d/gl3n -
gl3n
provides all the math you need to work with OpenGL, DirectX or just
vectors and matrices (it's mainly targeted at graphics - gl3n will
never
be more then a pure math library). What it supports:
* vectors
* matrices
* quaternions
* interpolation (lerp, slerp, hermite, catmull rom, nearest)
* nearly all glsl functions (according to spec 4.1)
* some more cool features, like templated types (vectors, matrices,
quats), cool ctors, dynamic swizzling
And the best is, it's MIT licensed ;). Unfortunatly there's no
documentation yet, but it shouldn't be hard to understand how to use
it,
if you run anytime into troubles just take a look into the source, I
did
add to every part of the lib unittests, so you can see how it works
when
looking at the unittests, furthermore I am very often at #D on
freenode.
But gl3n isn't finished! My current plans are to add more
interpolation
functions and the rest of the glsl defined functions, but I am new to
graphics programming (about 4 months I am now into OpenGL), so tell me
what you're missing, the chances are good that I'll implement and add
it. So let me know what you think about it.
Before I forget it, a bit of code to show you how to use gl3n:
vec4 v4 = vec4(1.0f, vec3(2.0f, 3.0f, 4.0f));
vec4 v4 = vec4(1.0f, vec4(1.0f, 2.0f, 3.0f, 4.0f).xyz)); // dynamic
swizzling with opDispatch
vec3 v3 = my_3dvec.rgb;
float[] foo = v4.xyzzzwzyyxw // not useful but possible!
glUniformMatrix4fv(location, 1, GL_TRUE, mat4.translation(-0.5f,
-0.54f,
0.42f).rotatex(PI).rotatez(PI/2).value_ptr); // yes they are row
major!
mat3 inv_view = view.rotation;
mat3 inv_view = mat3(view);
mat4 m4 = mat4(vec4(1.0f, 2.0f, 3.0f, 4.0f), 5.0f, 6.0f, 7.0f, 8.0f,
vec4(...) ...);
struct Camera {
vec3 position = vec3(0.0f, 0.0f, 0.0f);
quat orientation = quat.identity;
Camera rotatex(real alpha) { orientation.rotatex(alpha); return
this; }
Camera rotatey(real alpha) { orientation.rotatey(alpha); return
this; }
Camera rotatez(real alpha) { orientation.rotatez(alpha); return
this; }
Camera move(float x, float y, float z) {
position += vec3(x, y, z);
return this;
}
Camera move(vec3 s) {
position += s;
return this;
}
@property camera() {
//writefln(yaw: %s, pitch: %s, roll: %s,
degrees(orientation.yaw), degrees(orientation.pitch),
degrees(orientation.roll));
return mat4.translation(position.x, position.y, position.z) *
orientation.to_matrix!(4,4);
}
}
glUniformMatrix4fv(programs.main.view, 1, GL_TRUE,
cam.camera.value_ptr);
glUniformMatrix3fv(programs.main.inv_rot, 1, GL_TRUE,
cam.orientation.to_matrix!(3,3).inverse.value_ptr);
I hope this gave you a little introduction of gl3n.
- dav1d
I looked at your project yesterday (found it on derelict forums)
and it looks really good. Currently I'm using my own code for
vectors/matrices but a dedicated library could be better.
My comments:
Not sure if DMD will do a good job optimizing your code atm
(probably no way around this but to wait - uglifying the code would
serve
no purpose)
In the future, SSE support would be nice (maybe will be easier to do
if we
ever get SSE intrinsics)
Seems like most of the code is in linalg.d - wouldn't it be more
maintainable
to have it separated for each struct, and then public import it
through one
module for easy usage?
I'm doing a lot of 2D work, and could use at least a rectangle/aabbox
struct
(if I use your lib, I'll implement rectangles on top of it anyway).
Some other structs might also be useful (3D aabbox, circle, sphere?)
Although, if you want to be as close to GLSL as possible, this might
not be a good idea.
Most D projects are under the Boost license.
If you want to get this to Phobos,
(I'd like something like this in Phobos :P)
I recommend using that license
(IANAL, but I don't see much difference between MIT and Boost)
The GLSL style is good if you want it as close to GLSL as possible,
but it'd be good to have more D-style aliases (again hinting at
Phobos).
(Personally I'd probably use the GLSL style, though)
Hi,
Thanks for your feedback. SSE is planed, but it will be the last step,
optimization at the end. Well gl3n shouldn't be the bottleneck anyways,
because it's normally the GPU.
I've already thought about splitting linalg into 3 different files (also
it was suggested by some people), but I dont like how D(md) handles
imports, something like this would be cool:
import gl3n.linalg.matrix;
import gl3n.linalg.vector;
import gl3n.linalg.quaternion;
import gl3n.linalg; // this would import
gl3n.linalg.matrix/vector/quaternion publically
Like __init__.py in Python, unfortunatly this isn't supported (yet
Re: Xinok Sort - December 2011
On 01-12-2011 14:26, Steven Schveighoffer wrote: On Wed, 30 Nov 2011 20:45:19 -0500, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Add @property to front/back/popFront/popBack/empty/save. Also popFront/popBack need to be void return type. popFront/popBack need not be @property. -Steve Anything that mutates the state of an object or does something that's significantly more expensive than retrieving a field should not be a property. This is something I still have gripes with in the language itself (see array.dup). I think it's completely broken that such design is encouraged. - Alex
Re: The book Programming in D is in beta
On 14-11-2011 08:00, Ali Çehreli wrote: I have been translating my Turkish D book D Programlama Dili to English under the title Programming in D. I have decided to make its current state available online: http://ddili.org/ders/d.en/index.html I will make more chapters available as they get translated. As the book is for the novice programmer, the chapters that have been translated so far will not be very interesting to you. For that reason, I have decided to skip a number of chapters and translate two from the later ones as well: Exceptions: http://ddili.org/ders/d.en/exceptions.html Ranges: http://ddili.org/ders/d.en/ranges.html I hadn't known that my English was so poor. :) Please be patient; the text is being edited by an expert English speaker and will continuously be updated as it gets corrected. I welcome any feedback at acehr...@yahoo.com and of course here. Thank you, Ali This is great news! We definitely need more literature on D. - Alex
Re: Visual D 0.3.28 released: debugger improvements and inline help
On 25-10-2011 21:52, Rainer Schuetze wrote: Hi, Visual D is a Visual Studio package providing both project management and language services for the D programming language. It works with Visual Studio 2005, 2008 and 2010 as well as the free Visual Studio Shells. This release features some useful updates to the mago debugger and language and runtime library help through F1: * mago debugger: fixed crashes, display of local, TLS and global variables, workaround for bad line number debug info * cv2pdb: fixed patching of autoexp.dat when the install path contained spaces * improvements to the syntax parser * fixed building phobos browse information * F1 searches language and phobos documentation for help on identifier * added highlighting of asm block, using new colors Visual D Register/Mnemonic and Disabled/Token String variants The previous version was not announced here, but contained a few improvement worth mentioning: * improved smart reindention * pasting a full line or more now causes automatic reindentation * new option to show demangled symbols in the Error List Full version history can be found here: http://www.dsource.org/projects/visuald/wiki/VersionHistory The Visual D installer can be downloaded from its website at http://www.dsource.org/projects/visuald Rainer As always, thanks for an awesome release! - Alex
