Re: Build It And They Will Not Come
On Tuesday, 18 August 2015 at 19:35:02 UTC, Walter Bright wrote: Here's the pattern that works a lot better: 1. spend hundreds if not thousands of hours developing something really cool Check! 2. spend 10 minutes writing the announcement to D.announce. Be sure to include: who, what, where, when, why, and how Check! 3. someone posts it to reddit Wait, what? They did? 4. post the who, what, where, when, why and how on reddit AS SOON AS POSSIBLE after the reddit link appears. Stuff on reddit has a VERY SHORT shelf life. If it doesn't get action within a couple hours, it fades into oblivion. Identify yourself as the author, say AMA. The first one to post a comment tends to spark and set the tone for the discussion. Oh man, I'm like two days too late for that. goto 7? 5. check back on reddit once an hour or so for the next day, answer questions Whoa. I don't have time for that! 6. * ??? 7. profit! Fingers crossed! -Lars
Re: ∅MQD messaging library v1.0 released
On Tuesday, 18 August 2015 at 19:35:56 UTC, Walter Bright wrote: On 8/16/2015 2:22 AM, Lars T. Kyllingstad wrote: I am happy to announce the (somewhat overdue) release of ∅MQD v1.0! https://www.reddit.com/r/programming/comments/3hgg00/mqd_d_library_for_zeromq_v10_released/ Lars, please post an AMA there. After the present thread didn't garner much attention the first couple of days, I kind of stopped following it, and didn't catch up on it until now. I guess that reddit thread is long dead now. :( Lars
Re: ∅MQD messaging library v1.0 released
On Tuesday, 18 August 2015 at 20:44:25 UTC, Suliman wrote: Lars, did you thought about full port? I read post of etcimon about his Botan lib. He eventual decided to rewrite original lib from C++ to D to make code more easier maintainable. I considered it, yes, but it is a *lot* more work, and I think the wrapper solution turned out rather nice. The ZMQ API is pretty "wrappable", and I don't expect it to become much more complex in the future either. The big changes these days seem to be in the ZMQ guys' own high-level wrapper library, CZMQ, rather than in ZMQ core. Recently, I've played around with the idea of making a pure D implementation of Scalable Protocols, which was created by Martin Sustrik, one of the original ZMQ authors. He invented SP and the reference implementation, nanomsg (http://nanomsg.org), partly as kind of a do-over for some things he considered design mistakes in ZMQ. SP seems "cleaner" and more principled than ZMQ in many ways. So many fun projects, so little time... Lars
SciD has a new home
As of today, the main SciD repository will be hosted under the DlangScience organisation on GitHub: https://github.com/DlangScience/scid SciD is a collection of freely usable numerical routines for, among other things, - numerical integration (quadrature) and differentiation - nonlinear equation solving (one- and multidimensional) - (a little bit of) linear algebra With this move, I hope more people will discover the library, find it useful, and even contribute to it. Documentation: https://dlangscience.github.io/scid Dub package: http://code.dlang.org/packages/scid -Lars
Re: ∅MQD messaging library v1.0 released
On Sunday, 16 August 2015 at 12:53:39 UTC, Nick Sabalausky wrote: Cool. I haven't actually used ZeroMQ yet, but it's something I've had my eye on. If you want to look into it, I heartily recommend the ZeroMQ Guide: http://zguide.zeromq.org/ In addition to being a comprehensive and well-written (entertaining, even) user's guide for ZeroMQ, it contains a lot of good information and advice on how to build distributed software systems in general. I have translated the examples for the first few chapters to D. You'll find them in the "examples" subdirectory of the ∅MQD repo. -Lars
∅MQD messaging library v1.0 released
I am happy to announce the (somewhat overdue) release of ∅MQD v1.0! ∅MQD is a D library that wraps the low-level C API of the ∅MQ (aka. ZeroMQ) messaging framework. It is a rather thin wrapper that maps closely to the C API, while providing modern D features that make the framework safer, easier and more pleasant to use. (In other words, ∅MQD is not just a plain C binding(*)!) Code: https://github.com/kyllingstad/zmqd Dub package: http://code.dlang.org/packages/zmqd API docs: https://kyllingstad.github.io/zmqd/zmqd_v1.0.html This version works with ∅MQ v4.x, and has 100% support for all ∅MQ v4.0 functionality. A few small ∅MQ 4.1 features are missing, but support for those will be added in an upcoming 1.1 release in the not-too-distant future. Before use, please have a look at the README, specifically the section "A word of caution about the C library bindings". The ∅MQ guys have introduced some ABI incompatibilities in recent versions, so it it important that the D-to-C bindings match the library version you have installed. -Lars (*) If plain C bindings are what you want, check out Deimos/ZeroMQ: https://github.com/D-Programming-Deimos/ZeroMQ http://code.dlang.org/packages/zeromq ∅MQD depends on these bindings, so I try to keep them up to date with stable ∅MQ releases.
∅MQD 1.0.0-alpha released - now with full ∅MQ 4.0 support
∅MQD is a D library that wraps the low-level C API of the ∅MQ (aka. ZeroMQ) messaging framework. It is a rather thin wrapper that maps closely to the C API, while making it safer, easier and more pleasant to use. The API is designed to feel familiar to existing ∅MQ users, yet natural to D users. With this release, the latest stable ∅MQ version (4.0.x) is supported in full, including the new security mechanisms. I'm going to let it linger in the alpha release stage for a while, in the hope that you guys will try it out and give me some feedback and bug reports. Please let me know of any issues via the GitHub issue tracker. For more information, check out the following links. GitHub/README: https://github.com/kyllingstad/zmqd API docs: https://kyllingstad.github.io/zmqd/zmqd.html DUB package:http://code.dlang.org/packages/zmqd
Re: Adam D. Ruppe's "D Cookbook" now available!
On Friday, 30 May 2014 at 11:48:57 UTC, Chris wrote: There's _always_ something you can learn, even if you think you know it all. Like the fact that you can @disable this() for a struct, even though you can't implement it. I didn't know that, but I have the perfect use case for it (and it's one which has bothered me for a long time). Thanks, Adam!
Re: ∅MQD, a ∅MQ wrapper for D
On Friday, 24 January 2014 at 19:20:26 UTC, Justin Whear wrote: Now that I think of it, you also need to find a scheme for indicating which events you want to listen for. Which means either a simple pairing type (socket, event mask) or a getopt-style interface. I have suggested a few possible poll APIs here: https://github.com/kyllingstad/zmqd/issues/3 Comments are very welcome.
Re: ∅MQD, a ∅MQ wrapper for D
On Friday, 24 January 2014 at 18:59:54 UTC, Justin Whear wrote: Nicely done. It looks like you haven't wrapped the poll functionality at all, something that I use in most of my 0MQ programs. Thanks! I'm glad that you mention zmq_poll(); I've been wondering how to deal with that. It's slightly more low-level than the other functions, since it also deals with standard OS file descriptors, and I'd rather not expose OS-level stuff in ∅MQD more than strictly necessary. Do you ever use that functionality, or do you just poll ∅MQ sockets? Lars
∅MQD, a ∅MQ wrapper for D
∅MQD is a D library that wraps the low-level C API of the ∅MQ messaging framework. It is a rather thin wrapper that maps closely to the C API, while making it safer, easier and more pleasant to use. The API is designed to feel familiar to existing ∅MQ users, yet natural to D users. For more information, check out the following links. GitHub/README: https://github.com/kyllingstad/zmqd API docs: http://kyllingstad.github.io/zmqd DUB package:http://code.dlang.org/packages/zmqd A while ago, I posted an RFC about this on the digitalmars.D forum. I've since incorporated some of the suggestions I got and made a few additions, and I now deem the library ready for release. It hasn't seen a lot of serious field testing yet, though, so there are surely a few bugs lurking in there. Therefore, I am calling this the first beta release, and encourage you to report any issues you encounter here: https://github.com/kyllingstad/zmqd/issues
Re: dmd 2.063 released with 260 bugfixes and enhancements
On Thursday, 30 May 2013 at 15:25:39 UTC, Steven Schveighoffer wrote: On Thu, 30 May 2013 11:16:28 -0400, Andrei Alexandrescu wrote: For the full story, mosey to the redesigned changelog: http://dlang.org/changelog.html Holy changelog! That is awesome. Please send kudos to whoever took the time to create that. That would be Andrej Mitrovic. I agree, he's done a great job with it! It took a really long time to load, though. It's like the whole internet is stopping by to gaze in awe upon our beautiful changelog. :) Lars
Re: Unmanaged - a D framework on github
On Sunday, 17 March 2013 at 15:20:04 UTC, Jakob Ovrum wrote:
For different kinds of memory, you should simply use a
different allocator. For example, here's a rough approximation
of a pair of functions using malloc/free for class allocation:
T alloc(T)() if(is(T == class))
{
enum size = __traits(classInstanceSize, T);
auto p = enforceEx!OutOfMemoryError(malloc(size));
return emplace!T(p[0 .. size]);
}
I know this was just a rough example, but I just wanted to point
this out: It is not a good idea to use enforceEx() here, since
a) it uses new to allocate memory for the exception, and b) you
shouldn't try to allocate at all when you're out of memory. :)
Use core.exception.onOutOfMemory() to signal an allocation
failure instead. It throws a pre-allocated OutOfMemoryError.
Lars
Re: You crapper encounter...
On 26/02/12 11:24, Jonathan M Davis wrote: On Sunday, February 26, 2012 11:05:33 simendsjo wrote: On Sun, 26 Feb 2012 06:57:21 +0100, torhu wrote: On 26.02.2012 01:34, Andrei Alexandrescu wrote: Had a good chuckle: http://buztech.org/read-d-programming-ebooks-lesson-1-getting-started.htm l Andrei Did they use Google translate to translate it to Chinese and then back again? That's the worst I've ever seen. At first, I thought the site was some sort of auto-generated content to fool users to see the ads :) I know that there's at least one site out there which will generate random research papers for you, but even those are way better than this, because that sort of thing takes real, valid sentences and puts them together in way that its AI thinks will sound good (and the result with the research papers is stuff that sounds good until you start trying to figure out what it actually means) Someone actually managed to get a paper like this accepted to a conference. :) http://pdos.csail.mit.edu/scigen/ -Lars
Re: Inheriting purity DDJ blog by Walter on reddit
On 23/02/12 18:27, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/q2pmd/inheriting_purity_in_the_d_programming_language/ Is it just me, or has reddit started becoming a lot more positive towards D lately? A year ago almost every discussion ended up getting hijacked by trolls spreading FUD. -Lars
Re: D Conference 2012 - Sep 26-29 at the Banker's Suite and Ballroom in Astoria, Oregon
On 24/02/12 19:13, Jonathan M Davis wrote: Is this the first one of these, or has it just been a few years since the last one? http://d.puremagic.com/conference2007/index.html -Lars
libexif bindings in Deimos
A couple of years ago I ported the libexif C headers to D for a hobby project. The project itself never went anywhere, but I did complete the bindings. I have cleaned them up a bit and uploaded them to Deimos in the hope that they may be useful for someone else: https://github.com/D-Programming-Deimos/libexif libexif is a freely available (LGPL) library for reading and writing EXIF metadata from and to image files. For more information, see the libexif home page, http://libexif.sourceforge.net/ or the Wikipedia page on the EXIF format: https://en.wikipedia.org/wiki/Exif -Lars
Re: dmd 1.070 and 2.055 release
On Thu, 08 Sep 2011 11:49:55 -0700, Jonathan M Davis wrote:
> On Thursday, September 08, 2011 17:52:37 Andrej Mitrovic wrote:
>> Ok cool, my DWin project successfully compiles. The WinAPI bindings are
>> missing extern(Windows) specifiers for its function aliases and 2.055
>> seems to enforce this now, so that api will have to be updated. The
>> only thing that's bothering me is the notices, there's just too many of
>> them.
>>
>> For example this:
>>
>> import std.stdio;
>> import std.path;
>>
>> void main()
>> {
>> writeln(curdir.rel2abs);
>> }
>>
>> turns into this:
>> Notice: As of Phobos 2.055, std.path.rel2abs has been scheduled for
>> deprecation in February 2012. Please use absolutePath instead. Notice:
>> As of Phobos 2.055, std.path.isabs has been scheduled for deprecation
>> in February 2012. Please use isAbsolute instead. Notice: As of Phobos
>> 2.055, std.path.getDrive has been scheduled for deprecation in February
>> 2012. Please use driveName instead. Notice: As of Phobos 2.055,
>> std.path.join has been scheduled for deprecation in February 2012.
>> Please use buildPath instead. Notice: As of Phobos 2.055,
>> std.path.rel2abs has been scheduled for deprecation in February 2012.
>> Please use absolutePath instead. Notice: As of Phobos 2.055,
>> std.path.isabs has been scheduled for deprecation in February 2012.
>> Please use isAbsolute instead. Notice: As of Phobos 2.055,
>> std.path.getDrive has been scheduled for deprecation in February 2012.
>> Please use driveName instead. Notice: As of Phobos 2.055, std.path.join
>> has been scheduled for deprecation in February 2012. Please use
>> buildPath instead.
>>
>> That is just unacceptable imho.
>
> At present, the only way to get rid of them is to fix your code so that
> it doesn't use the functions which are scheduled for deprecation.
> Improvements to the deprecated keyword have been in discussion to
> improve the situation. e.g.
>
> https://github.com/D-Programming-Language/dmd/pull/345
What we could do in the meantime is to introduce the following at the top
of the modules that uses the "soft deprecation" mechanism:
version (NoSoftDeprecation) { } else version = SoftDeprecation;
Then, we could write the deprecation messages like this:
version(SoftDeprecation) pragma(msg, "Notice: As of ...");
and people could silence the compiler with -version=NoSoftDeprecation.
Even better, we could define a mixin somewhere that includes the above,
as well as a template containing a standardised deprecation message.
That way, each module only needs to have something like this at the top:
mixin (softDeprecationStuff!"std.path");
-Lars
Re: DVM - D Version Manager 0.3.0 (including support for Windows)
On Sun, 17 Jul 2011 22:10:39 +0200, Jacob Carlborg wrote: > I just released a new version of DVM, 0.3.0. Now with support for > Windows :), thanks to Nick Sabalausky. For installation instructions > see: https://bitbucket.org/doob/dvm Cool! This is a great tool, very useful. -Lars
Re: DVM - D Version Manager 0.2.0
On Tue, 17 May 2011 23:15:42 +0200, Jacob Carlborg wrote: > I just released a new version of DVM, 0.2.0. For installation > instructions see: https://bitbucket.org/doob/dvm > > Changelog: > > Version 0.2.0 > > New/Change Features > * 64bit version now available on Linux * It's now possible to update > an already existing DVM installation * Added an option for installing > 32bit compilers, useful on 64bit > platforms > * Added support for the new structure of the DMD zip, appeared in > version 1.068 and 2.053 > * Added a "current" wrapper which points to the current compiler * > Added an option for specifying a default compiler * Better compatible > between different shells * Added support for installing Tango > * Added support for installing 64bit compilers (default on 64bit > platforms) > * The fetch/install command now shows progress when downloading. > Thanks to jdrewsen. > * Added support for the new structure of the DMD zip, appeared in > version 1.067 and 2.052. > * Added a changelog. > > Bugs Fixed > * RDMD now has executable permission > * Exit if the DVM executable cannot be found * Always remove the temp > path > * Don't use "exit" in the DVM shell script * Added dmd.conf patch for > druntime as well. * Fixed: DMD2 was incorrectly handled. * Bump > version number. > > > Sorry, still no version for Windows. I've seen another application that > does the same but for Ruby, on Windows, so now I know it should be > possible at least. I just installed DVM, and it seems like a very useful tool. It works pretty well, but I ran into an issue for which I created a bug report: https://bitbucket.org/doob/dvm/issue/5/invalid-character-in-dvm-env-files Also, I have some suggestions for features you may want to add in the future. I'll add enhancement requests for these. Thanks for making a nice tool! -Lars
Re: Short article on std.parallism
On Sun, 29 May 2011 18:18:14 -0700, Jeremy Wright wrote: > I implemented bucket sort in D to demonstrate how easy it is to use > std.parallelism. I welcome any feedback. > > http://www.codestrokes.com/archives/116 Nice article. :) A tip to make the code even more terse: You can replace taskPool.parallel () with parallel(). The latter just forwards to the former. (See the last item of the std.parallelism docs.) -Lars
Re: Digital Mars has been accepted for Google Summer of Code 2011
On Fri, 18 Mar 2011 15:01:38 -0500, Andrei Alexandrescu wrote: > We have just got word from Google - Digital Mars has been accepted as a > mentoring organization for Google Summer of Code 2011. This is fantastic news! :) -Lars
Re: Plot2kill 0.2
On Sat, 05 Mar 2011 13:31:22 -0500, dsimcha wrote: > On 3/5/2011 1:27 PM, Lars T. Kyllingstad wrote: >> Does this mean that it can save to vector formats now, or just that you >> intend to add that functionality? EPS would be awesome, because it's >> pretty much the only thing you can use directly with LaTeX. (Yes, >> pdfLaTeX accepts many other formats, but many scientific journals still >> require you to provide EPS figures.) >> >> Of course, one can usually convert losslessly between the various >> vector formats, but it would be most convenient if Plot2kill could save >> directly to EPS, PDF and SVG. >> >> -Lars > > ? Plot2kill (the GTK version) has been able to save to EPS, SVG, > PDF, PNG, JPEG and BMP since I switched the GTK port to use the Cairo > backend last July. (The DFL port can only do BMP and PNG.) If this is > a killer feature for you, I apologize for not publicizing it more back > then. I've been eating my own dogfood since then. All of the graphs in > my Ph.D. proposal and a publication manuscript I'm working on are > Plot2Kill rendered and saved in vector formats. Oh, I didn't know that. That's very cool! I can't remember seeing an announcement of this feature from you, nor did I expect the feature to be there, so I guess I just didn't look that closely for it. :) -Lars
Re: Plot2kill 0.2
On Sat, 05 Mar 2011 13:09:15 -0500, dsimcha wrote: > I've done some major updating of my Plot2kill plotting library lately, > such that I thought it was worth posting an announcement and calling it > version 0.2. Cool! :) I'll be sure to try it out. > [...] > > For those who aren't familiar with it, Plot2kill supports both gtkD and > DFL. I've put the DFL port in maintenance mode. It still works, but I > won't be backporting any of the GUI-specific changes anytime soon. This > is mostly because DFL has a few key limitations that would make this > port second-rate compared to the GTK port no matter what. The most > important ones are lack of support for non-Windows OS's and lack of an > easy way to save in vector formats. Furthermore, DFL has bit rotted > such that it doesn't even compile without some modifications on DMD > 2.052. Does this mean that it can save to vector formats now, or just that you intend to add that functionality? EPS would be awesome, because it's pretty much the only thing you can use directly with LaTeX. (Yes, pdfLaTeX accepts many other formats, but many scientific journals still require you to provide EPS figures.) Of course, one can usually convert losslessly between the various vector formats, but it would be most convenient if Plot2kill could save directly to EPS, PDF and SVG. -Lars
Re: dmd 1.067 and 2.052 release
On Fri, 18 Feb 2011 02:18:55 -0800, Walter Bright wrote: > Now with 64 bit Linux support! (Though expect problems with it, it's > brand new.) > > > http://www.digitalmars.com/d/1.0/changelog.html > http://ftp.digitalmars.com/dmd.1.067.zip > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.052.zip 64-bit compiler, new date/time module AND a bunch of bug fixes -- is it christmas already? :) Fantastic work, guys! -Lars
Re: New web newsreader - requesting participation
On Thu, 03 Feb 2011 17:16:58 +, Adam Ruppe wrote: > Eric Poggel wrote: >> I hate to mention this in light of Adam's work, but Reddit is open >> source--why not run our own deployment of it for D? > > I *really* dislike tree style interfaces. I find them incredibly hard to > navigate. > > Of course, I'm fairly unlikely to use the web interface much anyway > (whether mine or someone else - I prefer my mail client most the time), > but still, it would be nice if it didn't suck. > > Anyway, I did a little more work on my thing this morning: > > http://arsdnet.net/d-web-site/nntp/thread-index?newsgroup=digitalmars.D > > There's now [Tree] and [Linear] links on the right to view the whole > thread at once. > > > Any ideas on how to improve that? I copied a few basic elements of > reddit style sites, but I'm thinking that view works best for very short > messages. I agree. Subject, author and date should be shown in a tree view, but you should never display more than one message body at a time. The average message on this forum is far too long for that. -Lars
Re: DVM - D Version Manager
On Tue, 25 Jan 2011 08:48:25 -0500, Steven Schveighoffer wrote: > On Tue, 25 Jan 2011 08:32:42 -0500, Lars T. Kyllingstad > wrote: > > >> Does it look in the executable directory on Linux too? If so, does >> that take precedence over /etc/dmd.conf and environment variables? > > http://www.digitalmars.com/d/2.0/dmd-linux.html#dmd_conf Ah, thanks. I'll RTFM next time. ;) -Lars
Re: DVM - D Version Manager
On Tue, 25 Jan 2011 08:22:40 -0500, Steven Schveighoffer wrote: > On Tue, 25 Jan 2011 03:22:22 -0500, Lars T. Kyllingstad > wrote: > >> On Tue, 25 Jan 2011 09:14:06 +0100, Don wrote: >> >>> Nick Sabalausky wrote: >>>> "Jacob Carlborg" wrote in message >>>> news:ihkvrr$1l02$1...@digitalmars.com... >>>>> I've created a tool that installs and manages D compilers and >>>>> different versions. >>>>> >>>>> Description: >>>>> >>>>> DVM allows you to easily download and install D compilers and manage >>>>> different versions of the compilers. When you switch D compiler with >>>>> the "use" command the compiler will only be available in the current >>>>> shell. This allows you to have one version of the compiler in one >>>>> shell and another version in another shell. For example, have a D1 >>>>> version in one shell and a D2 version in another. >>>>> >>>>> The tool is available at bitbucket: https://bitbucket.org/doob/dvm >>>>> The wiki contains installation and usage instructions: >>>>> https://bitbucket.org/doob/dvm/wiki/Home >>>>> >>>>> Platforms: currently only Posix >>>>> >>>>> >>>> Yay! That sounds great! >>>> >>>> This is the second thing this week that I'd been intending to do and >>>> have been thrilled to be beaten to the punch :) >>>> >>>> You can bet I'll take a crack at porting it to >>>> windows...uhhh...assuming I can find the time...heh ;) >>>> >>>> >>>> >>> FWIW, I just copy all the versions of dmd into olddmd/dmd2051, etc, >>> and then use a trivial batch file. (Uses junction from sysinternals to >>> make a symlink). >>> --- >>> @junction c:\dmd c:\olddmd\dmd%1 > nul @if not errorlevel 0 echo don't >>> have version %1 --- >>> eg, usedmd 2051 >> >> Won't the script have to somehow set the import and library paths as >> well, so that DMD finds its corresponding druntime/phobos versions? > > No, dmd uses the config file in the same directory as the exe. This > config file contains those paths. Ah, forgot about dmd.conf. I always install DMD in the /usr/local tree and define DFLAGS as an environment variable. Does it look in the executable directory on Linux too? If so, does that take precedence over /etc/dmd.conf and environment variables? -Lars
Re: DVM - D Version Manager
On Tue, 25 Jan 2011 09:14:06 +0100, Don wrote: > Nick Sabalausky wrote: >> "Jacob Carlborg" wrote in message >> news:ihkvrr$1l02$1...@digitalmars.com... >>> I've created a tool that installs and manages D compilers and >>> different versions. >>> >>> Description: >>> >>> DVM allows you to easily download and install D compilers and manage >>> different versions of the compilers. When you switch D compiler with >>> the "use" command the compiler will only be available in the current >>> shell. This allows you to have one version of the compiler in one >>> shell and another version in another shell. For example, have a D1 >>> version in one shell and a D2 version in another. >>> >>> The tool is available at bitbucket: https://bitbucket.org/doob/dvm The >>> wiki contains installation and usage instructions: >>> https://bitbucket.org/doob/dvm/wiki/Home >>> >>> Platforms: currently only Posix >>> >>> >> Yay! That sounds great! >> >> This is the second thing this week that I'd been intending to do and >> have been thrilled to be beaten to the punch :) >> >> You can bet I'll take a crack at porting it to >> windows...uhhh...assuming I can find the time...heh ;) >> >> >> > FWIW, I just copy all the versions of dmd into olddmd/dmd2051, etc, and > then use a trivial batch file. (Uses junction from sysinternals to make > a symlink). > --- > @junction c:\dmd c:\olddmd\dmd%1 > nul @if not errorlevel 0 echo don't > have version %1 --- > eg, usedmd 2051 Won't the script have to somehow set the import and library paths as well, so that DMD finds its corresponding druntime/phobos versions? -Lars
Re: dmd 1.066 and 2.051 release
On Tue, 21 Dec 2010 00:38:17 -0800, Walter Bright wrote: > This is another bug fix release. > > http://www.digitalmars.com/d/1.0/changelog.html > http://ftp.digitalmars.com/dmd.1.066.zip > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.051.zip Awesome! :) This is the release that finally makes pure and nothrow usable! Also, I'm very thrilled about the changes to the math stuff, in particular the addition of std.mathspecial. ...for which the documentation seems to be missing, by the way. -Lars
Re: blip 0.5
On Wed, 17 Nov 2010 23:42:49 +0100, Fawzi Mohamed wrote: > I am happy to announce blip 0.5 > > http://dsource.org/projects/blip > > why 0.5? because it works for me, but hopefully it will work for others > too, and 1.0 will be a release with more contributors... > > Blip is a library that offers > > * N-dimensional arrays (blip.narray) that have a nice interface to > lapack (that leverages the wrappers of baxissimo) > * 2,3 and 4D vectors, matrixes and quaternions from the omg library > of h3r3tic > * multidimensional arrays, with nice to use wrappers to blas/lapack * > a testing framework that can cope both with combinatorial and > random testing > this means that you can define an environment (be it struct or > class, maybe even templatized) > and then define generators that create one such environment (see > blip.rtest.BasicGenerators) > then you can define testing functions that will receive newly > generated environments and do the tests > * serialization (blip.serialization) that supports both json format, > that can be used also for input files and an > efficient binary representation > * MPI parallelization built on the top of mpi, but abstracting it > away (so that a pure tcp implementation is possible), > for tightly coupled parallelization > * a Distribued Objects framework that does rpc via proxies > (blip.parallel.rpc) > * a simple socket library that can be used to connect external > programs, even if written in fortran or C (for a weak parallel coupling) > * a coherent and efficient io abstraction > > But what might be most interesting is. > > * SMP parallelization (blip.parallel.smp) a numa aware very flexible > framework > > a parallelization framework that can cope well with both thread like and > data like parallelism, integrated with libev to offer efficient socket > i/o and much more. > > An overview of blip is given in > http://dsource.org/projects/blip/wiki/BlipOverview > The parallelization is discussed in > http://dsource.org/projects/blip/wiki/ParallelizationConcepts > finally to install it see > http://dsource.org/projects/blip/wiki/GettingStarted > > enjoy > > Fawzi This looks pretty good. Too bad it's only for D1. I'll be keeping an eye out for a D2 version in the future. ;) -Lars
Re: dmd 1.065 and 2.050 release
On Fri, 29 Oct 2010 10:35:27 -0700, Walter Bright wrote: > This is primarily a bug fix release. > > http://www.digitalmars.com/d/1.0/changelog.html > http://ftp.digitalmars.com/dmd.1.065.zip > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.050.zip I would like to point out that the table in the documentation for std.container is still messed up. Walter, could this be because you are building the docs using win32.mak? When I build with posix.mak it looks fine. -Lars
Re: dmd 1.065 and 2.050 release
On Fri, 29 Oct 2010 10:35:27 -0700, Walter Bright wrote: > This is primarily a bug fix release. > > http://www.digitalmars.com/d/1.0/changelog.html > http://ftp.digitalmars.com/dmd.1.065.zip > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.050.zip Thanks to all contributors for yet another good release. My personal favourites this time must be the relaxed purity rules (yay, now I can actually use pure), the improvements to Tuple (finally, proper indexing!), and the fixing of bug 4465 (which may seem trivial, but which I've been running into several times a day for a long time). -Lars
Re: First big PITA in reallife D project
On Tue, 19 Oct 2010 12:45:28 +0200, Stephan wrote: > Hey guys I wanted to discuss my first major depressing experience with D > in a reallife project. > > First off here is the according bug report : > http://d.puremagic.com/issues/show_bug.cgi?id=4951 > > I have to mention that it was by far not the first bug i encountered in > D but it has never been such a PITA. I spent hours and hours of > searching, rewriting and crawling my code for the cause of this issue. > Just to finally find out that it was not my code but some bug in > druntime. > > What i do: > I spawn multiple threads all periodically connecting to some webservers > waiting for the request to finish. Every request is totally independent > of the others. There is no data sharing in my code. Now i have a > protocol that makes my process send one last important request when > shutting down. For a clean shut down i wanted to make sure that all the > other threads are shut down first. That way the final request of the > process is the very last. So i wait for every thread to finish their > request and stop them. > BUT it wont work like that. AFTER i stopped all other threads some > strange behavior of druntime makes every creation of an InternetAddress > instance (internally trying to resolve host) impossible (throws an > exception). Additionally even if the Internet Addresses were created > upfront the TcpSockets wont connect but throw. I have no idea what the > heck is going on inside of the druntime that could cause this but in my > opinion it makes designing a big server environment pretty much > impossible because it would mean that i cannot let any of my user > generated threads exit unless i want to shutdown completely anyway. > > Perhaps one side note: I am testing and having these issues under > Windows. > > > I have never been so tempted to use another language while coding in D > as i was this time and that makes me sad. > > > - Stephan Hi! This newsgroup is meant for announcements. It would be great if you could repost this message in the main newsgroup, digitalmars.D. Thanks for the bug report, by the way! -Lars
Re: New home page
On Thu, 07 Oct 2010 08:56:07 -0400, Nick Sabalausky wrote: > "Stephan Soller" wrote in message > news:i8k8k9$230...@digitalmars.com... >> On 07.10.2010 11:02, Nick Sabalausky wrote: >>> >>> Not explicitly as far as I'm aware, but then neither does HTML aside >>> from URLs. And the PDF format does have provisions for files/data of >>> arbitrary types to be embedded into it. So that could be used to embed >>> HTTP URLs, or >>> any other form of network-oriented links, or any other >>> application-related >>> information/instructions/data you want. Then you could build >>> CSS/JS/CGI-like >>> stuff on top of all that. And all of a sudden "PDF-readers" become a >>> really >>> shitty application platform just like what happened with HTML and web >>> browsers. >>> >>> >> Interesting point of view. So PDF basically equals to HTML in that >> regard. Never thought about it that way but you're probably right. :) >> >> > Well, they were both created as document formats ;) > > >>> I usually like to minimize bitmapped stuff on pages too, just because >>> it's >>> simpler, it can still get acceptable results, and I'm no artist ;) >>> But then >>> when the client has a design they want it to look like and it includes >>> things that can only be done as images, well, then I just don't have >>> the energy or patience to try to talk them out of it - I'll just toss >>> in whatever I need to to make it work, even if that means tables, and >>> be done >>> with it. >>> >>> >> If I get a design from a client I do that to. I don't use tables but >> most often a combination of floats and relative/absolute positioning >> but usually with quite a lot of images in it. Even if they don't have a >> finished design arguing about it often is a lost cause anyway. However >> for my own personal project (or in case I have to do the design myself) >> these new CSS techniques come in quite handy (if the environment allows >> it...). >> >> I used it for my [personal website][1] and it was quite handy. The only >> images are the header image, icons and the background gradient. The >> gradient only because I was to lazy to look up the proper properties >> and do some cross browser testing (not sure if Opera support gradient >> yet though). >> >> [1]: http://arkanis.de/ >> >> > Not to complain, just FYI, this is what that page looks like for me: > > http://www.semitwist.com/download/arkanis1.png > http://www.semitwist.com/download/arkanis2.png > http://www.semitwist.com/download/arkanis3.png > > Interestingly, if I turn JS on, than it'll look a lot better *until* it > finishes loading, at which point it goes back to looking just like those > screenshots. I don't think the look has anything to do with JS. It looks perfectly fine on my computer, even with JS off. Here's a quote from another part of Stephan's web page, where he writes about the arkandis.de design itself: "This project also builds upon the new HTML5 semantic tags and uses CSS3 styles for almost everything in its design. Box shadows, rounded corners, transparency, HSL-colors, table positioning, etc. This page shows to a good degree what's possible if you ditch the old browsers and use the new stuff." I guess you haven't ditched the old browsers, then. ;) -Lars
Re: New home page
On Wed, 06 Oct 2010 01:36:24 -0400, Nick Sabalausky wrote: > "Walter Bright" wrote in message > news:i8gj1i$28h...@digitalmars.com... >> Stewart Gordon wrote: >>> Indeed, here are just a few things I hate to bits about CSS: >> >> Sure, but we're kind of stuck with it. While we can invent a new >> programming language, I don't think that inventing a new browser markup >> language is going to get any traction without convincing Microsoft, >> Google, and Apple to all get on board. > > Microsoft would never know it existed. > > Goggle would steal it and re-invent a crappy version of it. > > Apple would put a note in their developer-license-agreement prohibiting > it. > > Sun would release a whitepaper that attempted to explain why it wasn't > needed, but in their attempt they would accidentally make it clear it > was a good idea after all. > > Oracle would create a not-terrible-but-not-great version of it and have > their salesmen spend a couple million each convincing middle and upper > managers to pay twenty million for it each. Most of them would fall for > it. > > Sony would form a committee to investigate the feasibility of > introducing DRM capabilities into it. > > No one would ever notice if IBM did or didn't do anything with it. > > Hobbyist developers would flock towards a newly-created alternate > version that seemed simpler at first glance, but was much slower and > really just made it easier to introduce subtle bugs. > > W3C would form a committee to standardize it. Their early > recommendations would combine the worst aspects of all the various > versions. The final draft would be nearly identical to the early drafts, > but wouldn't be finalized until the original committee's grandchildren > were in retirement facilities. > > Adobe would create a mediocre, bloated, yet passable > child-window-fiesta-of-an-app to deal with it and charge hundreds for > it. It would be enormously popular. > > The people formerly from JASC would create a great alternative to > Adobe's offering at a reasonable price, and after no one bought it they > would kill it off by selling the rights to the dying carcass of some > formerly-relevant corporation. > > Corel...ah ha ha ha ha! Corel...That's a joke that doesn't need a > punchline. > > Hasbro Interactive would buy the rights to one of the older versions, > and sue any individuals and small businesses that had anything similar. > Then they would sell the rights. > > Steve Yegge will have something to say about it, but no one will know or > care what it is because by the time they finish reading his post the > universe will have ended. But he'll still maintain that his long-winded > approach was "good marketing". :D
Re: d.vim 0.20
On Mon, 30 Aug 2010 14:08:15 -0400, Jesse Phillips wrote: > There is a new version of the D syntax file for Vim. This is version > 0.20 and is available at > > http://www.vim.org/scripts/script.php?script_id=379 > > * Added missing keywords for D 2.0 compiler 2.047 * Added special > highlighting of known versions/scopes/annotations (thanks to Shougo > Matsushita) > > * Added highlighting of ASM Op Codes in asm blocks. > > I highly suggest you drop this latest version into your syntax folder > ~/.vim/syntax Linux and ~/_vimfiles/syntax Windows (where ~ is users > directory, not documents). > > I am the new maintainer of this file so please direct any comments, > suggestions, patches my way at jesse.k.phillip...@gmail.com Great, thanks! :) -Lars
Re: dmd 1.063 and 2.048 release
On Mon, 16 Aug 2010 23:33:26 +0900, Jordi wrote: > On 08/16/2010 04:11 PM, Don wrote: >> Brad Roberts wrote: >>> On 8/15/2010 12:54 PM, Walter Bright wrote: Nick Sabalausky wrote: > This may be a pain to do, but you could narrow it down from the > other direction: recompile DMD from various trunk revisions between > 2.046 and 2.047 > and see which actual commit created the problem. Try mixing/matching the compiler & Phobos to see which one of those caused the issue. >>> >>> While I agree that it's worth trying a bisection -- it's generally >>> really quick >>> and easy to do (the compiler and libraries build rather fast -- about >>> a minute >>> for me). It can be a very useful technique for finding where bugs were >>> introduced. >>> >>> That said, it's likely to be rather difficult for this release due to >>> the number >>> of fixes in the compiler that the library requires and for the periods >>> during >>> which the two didn't work together. >>> >>> Do try it.. worst case is you've wasted a little bit of time. Best >>> case you've >>> found the cause of the bug. >>> >>> Later, >>> Brad >> >> The latest compiler should work with the old Phobos, except that it >> will complain about the a&b==c bugs. That's simple to do, it just >> involves copying the 2.048 compiler onto the 2.047 release. Knowing if >> it is the compiler or Phobos/druntime would be an enormous help. > > Found it. It took me 7 iterations of binary search across the svn > repositories for dmd, druntime and phobos. The commit causing the issue > is 505 in dmd. It is related to structs returning *this, which indeed i > do in my maths structs. > > Now, i don't know if the bug is in dmd or in my code, but i suspect that > something is being treated as a reference when it shouldn't. Should i > add an issue even if i am not sure? Since DMD 2.021, 'this' for structs _is_ a reference. -Lars
Re: dmd 1.063 and 2.048 release
On Wed, 11 Aug 2010 00:15:07 -0700, Walter Bright wrote: > This is probably the last FreeBSD 7 release for D1. The next will be for > FreeBSD 8! > > http://www.digitalmars.com/d/1.0/changelog.html > http://ftp.digitalmars.com/dmd.1.063.zip > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.048.zip This is a great release. Bug fixes galore! -Lars
Re: Plot2Kill 0.02
On Tue, 20 Jul 2010 13:29:40 +, Lars T. Kyllingstad wrote: > On Tue, 20 Jul 2010 12:37:23 +, dsimcha wrote: >> Yea, it wouldn't be terribly hard (actually, it would be quite easy >> since I wouldn't need to get all the GUI stuff right) to port Plot2kill >> to a GUI-less drawing framework, if one existed that a decent D >> binding/wrapper. I'm guessing that at best, I'd find a binding to some >> low-level C API if I looked, though. > > I'd start with the cairo wrappers in gtkD, if I were you. Now I see Rory has already suggested this. -Lars
Re: Plot2Kill 0.02
On Tue, 20 Jul 2010 12:37:23 +, dsimcha wrote: > == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article >> On Tue, 20 Jul 2010 11:37:30 +, dsimcha wrote: >> > == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s >> > article >> >> Even if you SSH into it, you can still run GUI apps remotely using X >> >> forwarding. But if you're saying that the machine doesn't have X >> >> installed at all (do those still exist?), I have no suggestions. >> >> -Lars >> > >> > That, or you want to run the job as a batch job via nohup and have >> > your plots appear in some directory the next day. >> Ah, I see. I guess the solution which would be most flexible in the >> long run would be to make the GUI abstraction "abstract enough" that it >> isn't limited to GUIs -- sort of like gnuplot does with its notion of >> 'terminals'. Then backends could be created for writing to various >> file formats. But that's probably quite a lot of work. I started using >> Plot2Kill "for real" at work today, BTW, and it works very well. Now, >> if someone made a CAS library for D, I would never again have to reach >> for any tool other than vim and dmd... ;) -Lars > > Yea, it wouldn't be terribly hard (actually, it would be quite easy > since I wouldn't need to get all the GUI stuff right) to port Plot2kill > to a GUI-less drawing framework, if one existed that a decent D > binding/wrapper. I'm guessing that at best, I'd find a binding to some > low-level C API if I looked, though. I'd start with the cairo wrappers in gtkD, if I were you. To quote the Wikipedia page: "cairo is a software library used to provide a vector graphics-based, device-independent API for software developers. It is designed to provide primitives for 2-dimensional drawing across a number of different backends." > In the meantime, to prepare for such a possibility, I should probably > refactor some stuff to completely separate the drawing logic from the > GUI logic, i.e. Figure should not inherit from DrawingArea, but should > instead have a toWidget() method that returns a DrawingArea subclass > that has-a Figure that is automatically drawn onto it. To me, at least, it isn't obvious where to draw the line between frontend and backend. You want to hit the sweet spot between DRY and maximum flexibility. For instance: Does a backend expose a set of drawing primitives and let the frontend do the drawing, or does it take the raw data and the plot configuration and draw the plot itself? Or perhaps a three-layered solution would be better? Suggestion: Frontend: Takes input data and a description of the desired output, selects middle layer and backend accordingly. Middle layers: vector: Draws vector graphics on backends that expose vector drawing primitives. raster: Draws raster graphics on backends that expose raster drawing primitives. trivial: Just passes the raw data to some backend. Backend: - For the vector middle layer you'd have on-screen, SVG, EPS, etc. - For the raster middle layer you'd have GIF, PNG, etc. - For the trivial middle layer you could have just about anything. -Lars
Re: Plot2Kill 0.02
On Tue, 20 Jul 2010 11:37:30 +, dsimcha wrote: > == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article >> Even if you SSH into it, you can still run GUI apps remotely using X >> forwarding. But if you're saying that the machine doesn't have X >> installed at all (do those still exist?), I have no suggestions. -Lars > > That, or you want to run the job as a batch job via nohup and have your > plots appear in some directory the next day. Ah, I see. I guess the solution which would be most flexible in the long run would be to make the GUI abstraction "abstract enough" that it isn't limited to GUIs -- sort of like gnuplot does with its notion of 'terminals'. Then backends could be created for writing to various file formats. But that's probably quite a lot of work. I started using Plot2Kill "for real" at work today, BTW, and it works very well. Now, if someone made a CAS library for D, I would never again have to reach for any tool other than vim and dmd... ;) -Lars
Re: Plot2Kill 0.02
On Sun, 18 Jul 2010 22:44:27 +, dsimcha wrote: > == Quote from BLS (windev...@hotmail.de)'s article >> Next, Do you have any ideas about zooming ? (zooming a plotting region) >> ? > > This can already be done programmatically (see Figure.xlim() and > Figure.ylim()), but is not exposed yet via the default plot window GUI. > This will be exposed when I decide how I want to expose it. The most > obvious answer is dragging, but the question then becomes, how do you > zoom back out? How about the mouse wheel? That's always the first thing I try. -Lars
Re: Plot2Kill 0.02
On Tue, 20 Jul 2010 03:22:37 +, dsimcha wrote: > == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article >> > Yea, I tried to use it on *nix today and realized that. This will >> > get fixed soon. >> > In addition to the typo, I forgot that getting a font can return >> > null. I have no >> > idea why it works on Windows. Anyhow, I'll make platform-specific >> > default fonts (using core X11 fonts on *nix and properly spelled >> > Verdana on Windows) and as a last resort, if the default font doesn't >> > exist, I'll make it just not render text instead of crashing the >> > program. >> So that was why it kept going SEG-V on me! I tried it out earlier >> today, but didn't have time to investigate too much. It works fine >> now, and I have the demo window up and running. Will definitely use >> for serious work tomorrow. ;) >> -Lars > > Fixed. http://dsource.org/projects/scrapple/changeset/772 Cool, thanks! :) > I fired up my barely-used Linux partition for this. I knew it would > come in handy. I also kludged around the weird text cutoff bugs that > only appear on Linux. (I don't want to say I fixed it because I didn't > address the root cause and I don't know what the root cause is. My best > guess is that on Linux the font measurements are slightly off.) > > The most serious bug now, IMHO, is that there's no way to save plots to > a file from a machine with console-only access, such as a supercomputer > that you SSH into. I don't know how to fix this. Calling Main.init() > on a machine with no windowing system borks everything. Does anyone > have any suggestions on how to fix this? Even if you SSH into it, you can still run GUI apps remotely using X forwarding. But if you're saying that the machine doesn't have X installed at all (do those still exist?), I have no suggestions. -Lars
Re: Plot2Kill 0.02
On Mon, 19 Jul 2010 17:51:29 +, dsimcha wrote: > == Quote from Johannes Pfau (s...@example.com)'s article >> On 18.07.2010 22:36, dsimcha wrote: >> > I've successfully ported dflplot to gtkD and gotten it to the point >> > where it works in every way (except speed/memory use; gtkD is a >> > little slow/resource hungry) at least as well as the original DFL >> > version. Now that I can't call it dflplot anymore because it >> > supports multiple GUI libs, I'm calling it Plot2Kill. The status of >> > the DFL version hasn't changed since I originally posted about >> > dflplot. Here's what works and what needs work, with respect to the >> > gtkD version wherever there's a difference: >> > >> > Working: Histograms, bar plots, scatter plots, line plots, QQ plots, >> > ROC curves, heat maps, subplot windows, error bars, rotated text, >> > programmatic saving in raster formats, interactive saving from >> > default plot window (right-clicking brings up a save dialog), zooming >> > in on a single figure from subplot window (double-click on the figure >> > to zoom in). >> > >> > Needs work: Documentation needs improvement and needs to be put up >> > somewhere (will happen once I get my own dsource project, as opposed >> > to Scrapple), saving in vector formats, Cairo port, zooming in on >> > areas within a single figure via the GUI (can be done >> > programmatically), customizability of look and feel of figures >> > (things like fonts, colors, margins, line styles, etc.), general >> > refactoring from "make it work" to "make it right" stage. >> > >> > I would say that there will probably not be too many breaking changes >> > (at the source level) to the basic API, i.e. creating a figure and >> > showing it in a default plot window, but the more advanced stuff that >> > you'd care about if you want to integrate plots into your own GUI is >> > likely to be refined via breaking changes. A stable ABI will >> > probably never happen because it constrains the evolution of the >> > project too much. >> > >> > Code: >> > >> > http://dsource.org/projects/scrapple/browser/trunk/dflplot/Porting >> > >> > Demo figure (created and saved programmatically, no longer a >> > screenshot): >> > >> > http://cis.jhu.edu/~dsimcha/plot2killGTK.png >> > >> > How to build: Install gtkD, and then just compile all of the .d >> > files with to a library with -version=gtk. It doesn't matter if you >> > pass in the DFL files when building the GTK version because all the >> > irrelevant code will be version-statemented out. >> > >> > Please let me know if this works properly on OS's besides Windows. >> > I've only tested it on Windows, although GTK is cross-platform and I >> > only used the high-level gtkD functionality in this lib, so I don't >> > see why it wouldn't work on any other OS with gtkD support. >> Tested on Linux. Works generally fine, nice work. Screenshot: >> http://i.imgur.com/6XS1W.png There's one problem though: >> You use a "veranda" font. I don't know whether that's a typo and you >> meant "Verdana" or maybe there is a font called "veranda". But you >> never check whether the font becomes null, and so it crashes here (in >> Size measureText(string text, Font font)) if I don't change the fonts. >> It's not a big deal, I just wanted to let you know, so you can fix it >> at some point in time. > > Yea, I tried to use it on *nix today and realized that. This will get > fixed soon. > In addition to the typo, I forgot that getting a font can return null. > I have no > idea why it works on Windows. Anyhow, I'll make platform-specific > default fonts (using core X11 fonts on *nix and properly spelled Verdana > on Windows) and as a last resort, if the default font doesn't exist, > I'll make it just not render text instead of crashing the program. So that was why it kept going SEG-V on me! I tried it out earlier today, but didn't have time to investigate too much. It works fine now, and I have the demo window up and running. Will definitely use for serious work tomorrow. ;) -Lars
Re: dflplot 0.01
On Sat, 10 Jul 2010 20:51:15 +, dsimcha wrote: > BTW, since my attachment didn't actually get attached, I've put up the > latest screenshot, produced from my demo/testing function, at: > > http://cis.jhu.edu/~dsimcha/dflplot.png Wow, I'd say that's looking pretty polished already. :) I think it's great that you've done this, it brings D another step closer to being a versatile numerics language. I'm looking forward to the day this becomes available for *NIX too. -Lars
Re: This just in: authorless TDPL becomes collector's edition
On Tue, 01 Jun 2010 12:59:32 -0500, Andrei Alexandrescu wrote: > Due to a pretty odd mistake at the printer, the first 1000 copies of > TDPL will not have the name of the author on their cover. (The name > still appears on the back cover and the spine.) > > The history of printing is rife with rare printing mistakes that have > become collector's editions. Preorder now to be among the first 1000 > readers who get the authorless TDPL edition. I received my collector's edition yesterday, and I'm telling you, with all this hype, it had better be worth something in 40 years' time. ;) I got it just in time, too. I'm going to Canada for a conference tomorrow, and it'll be perfect reading material during the long flight across the Atlantic. I've read the first two chapters already, and I have to say it's a thoroughly enjoyable read. The examples are good, the colloquial style makes the material more interesting (as if it wasn't interesting to begin with!), and the rapid-fire puns are delivered in style. ;) Well done! -Lars
Re: D rpm packages for Linux
On Thu, 24 Jun 2010 21:26:09 -0500, Ellery Newcomer wrote: > On 06/24/2010 08:40 PM, Andrei Alexandrescu wrote: >> On 06/24/2010 03:44 PM, Ellery Newcomer wrote: >>> On 06/24/2010 12:09 PM, Walter Bright wrote: D rpm packages now available http://www.digitalmars.com/d/download.html thanks to Jordi Sayol. >>> >>> Also, what about hosting a yum repository? >> >> Is that the thing that allows me to insert a line in the Synaptic >> repositories and then benefit of integration goodies? I'd love >> something like that. >> >> Andrei > > Ummm.. maybe? > > Yum is a package manager built on top of rpm, essentially red hat's > counterpart to apt-get. I think the idea is each version of dmd as an > rpm lives in the yum repository, and as new versions are released, the > yum will semi-automatically upgrade the user's install. > > The nice thing about it is the user doesn't have to go around looking > for the download each time the next release of dmd comes out, although > they do have to initially configure their system. Typically, the > repository host provides a downloadable rpm which performs that action. > > I don't know that it would be particularly useful for synaptic based > linuxen (Andrei, see what you've got me doing?) though. Guess we'd have > to make a synaptic repo too. Synaptic supports both deb and RPM package repositories. -Lars
Re: layout wiki4d - part 2
On Tue, 08 Jun 2010 22:22:50 +0200, Matthias Pleh wrote: > It seems, variant b) is the winner. > I've updated to b) with the font and font-size form c) and some minor > changes. > I hope you love it. > Enoy > > greets > Matthias Looks good. :) Thanks for taking the time to do it! -Lars
Re: layout wiki4d - part 2
On Sun, 06 Jun 2010 19:14:01 +0200, Matthias Pleh wrote: > Ok, > as already mentioned in the old thread I have set up a testpage to make > the suggested (and some other minor) changes. So we should decide, which > layout we should use for the wiki. > > a) the old one > b) the current > http://www.prowiki.org/wiki4d/wiki.cgi > c) the testpage > http://www.prowiki.org/wiki4d/wiki.cgi?MatthiasPleh/TestPage > d) some other layout, anybody want create, I think both b) and c) look good, but if I had to choose, I'd go with b). I'd use a sans-serif font for the headings, though, like in c). -Lars
Re: dmd 1.059 and 2.044 release
On Sun, 02 May 2010 14:28:25 -0700, Walter Bright wrote: > Highlights are the improved gdb support, better error messages, better > json support, unittest changes, and a number of nuisance compiler bugs > fixed. > > http://www.digitalmars.com/d/1.0/changelog.html > http://ftp.digitalmars.com/dmd.1.059.zip > > > http://www.digitalmars.com/d/2.0/changelog.html > http://ftp.digitalmars.com/dmd.2.044.zip > > Thanks to the many people who contributed to this update! Great release. :) The unittest feature is my favourite this time. I see that the new std.complex has been included in this release, but also that mention of it was removed from the changelog. It's a breaking change, so it should be listed. Also, std.gregorian made it into this release, but is not mentioned in the changelog. -Lars
Re: MessagePack for D released
On 04/27/2010 06:54 PM, tama wrote: On Tue, 27 Apr 2010 21:27:35 +0900, Lars T. Kyllingstad wrote: Phobos should definitely have a serialisation module, and this seems to me like a good candidate. I haven't tried the code myself, but it looks very clean and the examples are nice. Thanks! I consider it a huge plus that it uses an existing format that already has APIs for a bunch of programming languages. I agree. At first, I checked several serialization libraries. As a result, I select MessagePack with all things considered. Other libraries and Specs seem to be large and complex. Two questions: The packer can write to an arbitrary ubyte output range, but it seems the unpacker is limited to ubyte[] arrays. Would it be possible to unpack from an arbitrary input range? No. Unpacker is possible to do so if D has integrated stream. For your information, Other implementation(e.g. Java) uses InputStream. It doesn't seem to support the real type. It this a limitation of the MessagePack format or just an oversight? Even if the format doesn't directly support 80-bit floats, it should be possible to wrap them somehow. Good point. MessagePack doesn't define real type(80-bit float) because some languages don't have real. But MessagePack has free format space, so some implementation can support language-specific format. real has environment-dependent problem. This problem causes loss of precision. Unpacker can't be responsible for this problem. OK? I will try to implement real support. For systems where real is 64 bits it may be possible to use an 80-bit std.numeric.CustomFloat as an intermediate step between the stored data and the 64-bit type. -Lars
Re: I made std.time for Phobos, please review my code.
On 04/27/2010 04:58 PM, bearophile wrote: Steven Schveighoffer: I like what you've done. It's very similar to what was done in Tango. I hate to ask this, but I just want to verify that you did not base your code on Tango, especially since you have used Tango. In D2 the runtime of Phobos and Tango have being merged, so all D programmers can install both libs. So the two libs must have distinct contents. So I'm for removing the time module from Phobos, and keep only the Tango one. So this module is waste of time, and efforts have to be redirected in improving or rewriting the time module of Tango. Othrwise in D2 it will happen the same mess it's happend in D1, where you have two partially duplicated libs. All D2 programmers will want to install both libs, and they will not desire to choose what time lib to use. One time lit is enough. I don't think anyone should have to install an extra library just to figure out what time it is. -Lars
Re: MessagePack for D released
On 04/25/2010 02:20 PM, Masahiro Nakagawa wrote: I release a serialization library for Phobos(D2). Project repository: http://www.bitbucket.org/repeatedly/msgpack4d MessagePack is a binary-based serialization spec. See official site for details: http://msgpack.sourceforge.net/ Some application replace JSON with MessagePack for performance improvement. msgpack4d ver 0.1.0 has an equal features with reference implementation. * Zero copy serialization / deserialization * Stream deserializer * Support some D features(Range, Tuple) Currently, Phobos doesn't have a real serialization module(std.json lacks some features) I hope Phobos adopts this library for serialization(std.msgpack or std.serialization?). Phobos should definitely have a serialisation module, and this seems to me like a good candidate. I haven't tried the code myself, but it looks very clean and the examples are nice. I consider it a huge plus that it uses an existing format that already has APIs for a bunch of programming languages. Two questions: The packer can write to an arbitrary ubyte output range, but it seems the unpacker is limited to ubyte[] arrays. Would it be possible to unpack from an arbitrary input range? It doesn't seem to support the real type. It this a limitation of the MessagePack format or just an oversight? Even if the format doesn't directly support 80-bit floats, it should be possible to wrap them somehow. -Lars
Re: Visual D released
Rainer Schuetze wrote: Hello, I'd like to announce the initial release of Visual D, a Visual Studio package providing both project management and language services for integration of the D programming language into Visual Studio. Here are some features: * Project management o all DMD command line options accessible o support for resource compiler o custom build commands o pre/post custom build steps o automatic dependency generation o automatic link between dependent projects o integrates cv2pdb for seamless debugger integration o new project templates * Language Service o syntax highlighting o simple word-completion o import statement completion o goto definition (using JSON file from compilation) o smart indentation o highlight/jump-to matching braces o code snippets * Supported Visual Studio versions o VS 2005, VS 2008 o with some limitations: VS.NET 2003, VS 2010 * Easy installer for hassle-free installation Wow, this is awesome! I have a feeling this will make a BIG contribution when it comes to attracting people to D, not to mention keeping them here. :) And for the fun and frustration: Visual D is completely written in D. One shouldn't underestimate how important this last point is. -Lars
Re: dmd 1.058 and 2.043 release
bearophile wrote:
Thank you for the release and your work, and thank you to Don for all the bug
fixes.
I will need some more time to test this release better. In the meantime, is it
possible to use BigInts into an AA? This gives a Range violation:
import std.bigint: BigInt;
void main() {
BigInt[BigInt] aa;
aa[BigInt(1)]++;
}
Bye,
bearophile
Could this have anything to do with BigInt not having a toHash() function?
-Lars
Re: Decimal Arithmetic module available
Michael Rynn wrote: On Tue, 16 Mar 2010 12:41:25 +1100, Daniel Keep wrote: BCS wrote: ... Maybe we need a std.arithmetic.* for all the "a little more than just a number" types. Phobos with subpackages?! Blasphemy! That's what those filthy Tango heathens do and everyone knows that's just morally WRONG. (Yes, I know about std.c.*.) Then all of Java must be wrong too? Yes. ;) The list of std modules is getting a bit too long. Maybe a tree structure would work. After all it is for a programming language. I have the impression that a lot of the Phobos modules in D2 are relics from D1 that will be removed in due time. Another idea would be to make another root, like dlang. or lang. Having std. in front of nearly makes it a piece of superflous, redundent information. There are many roots more to choice from, and maybe it be nice to have the root module path be more informative? Why is 'std.' more redundant than Java's 'java.'? -Lars
Re: April 13th: Presenting D at the Beijing Linux User Group
Lionello Lunesu wrote: On 10-3-2010 10:07, Andrei Alexandrescu wrote: Lionello Lunesu wrote: On 10-3-2010 8:35, Walter Bright wrote: Lionello Lunesu wrote: I'll be presenting the D Programming Language at the next monthly BLUG meeting. It'll mostly be for people who haven't heard of D yet. There'll be a fair chunk of D1 in there, but I'm hoping to touch some of D2's new features as well. Awesome! (I'm fairly new to 'presenting stuff' in general, so all tips are highly welcomed.) I've noticed that things seem to go better if the presenter tries to engage the audience by asking them questions thereby inviting more of a group discussion, as opposed to just reading the slides to them. Good tip, thanks. I'm wondering: should I do the 'scrolling HTML', in true D style? The lazy part of me says yes :)) I suggest not. When you'll be more experienced you'll be able to make-do even with the white board, but for now focus on preparing good slides and rehearsing them. Hmm, yes. Walter's advice is good. Plus: make sure through rehearsing that your material fits within the allotted time. Well, I noticed that most other presentations I've attended did indeed go over time and not by a small amount either. So, apparently it's very hard to stay within a certain time? Or, once you're standing there and 'get in the zone' you forget about the time? I think it's rather that when you're preparing your slides, and reading them to yourself, you do it a lot faster than when you're actually doing the presentation. I try to use 2 minutes per slide as a rule of thumb. -Lars
Re: dmd 1.057 and 2.041 release
Steven Schveighoffer wrote: On Mon, 08 Mar 2010 14:27:36 -0500, Andrei Alexandrescu wrote: bearophile wrote: Andrei Alexandrescu: $(LI std.conv: changed the default array formatting from "[a, b, c]" to "a b c") That's a regression!!! (And I think in the past it was [a,b,c] instead of [a, b, c], because it's better to save some screen space, it costs a lot!). Sorry, this stays. The idea behind the change is to make 'to' a minimalistic function that makes minimum assumptions (e.g. the comma may be a decimal point in some languages, so is [1,2] in a German locale an array of double with one value or two? etc. The canonical "to" prints values separated by one space. Why one space? It's the most neutral thing I could think of. Why no brackets? Because of minimalism. You can very easy add them if you want them. What about an array of strings with spaces in them? Or an array of arrays? Is there at least a way to force 'to' to format the way you want? auto s = to!string([1,2,3], "[", ", ", "]"); -Lars
Re: dmd 1.057 and 2.041 release
Walter Bright wrote: Lots of meat and potatoes here, and a cookie! (spelling checker for error messages) http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.057.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.041.zip Thanks to the many people who contributed to this update! It seems array literals have become dynamic arrays, but I can't find any mention of that in the change log. pragma(msg, typeof([1,2,3]).stringof); // Prints "int[3u]" with DMD 2.040 // Prints "int[]" with DMD 2.041 -Lars
Re: dmd 1.057 and 2.041 release
Simen kjaeraas wrote: Walter Bright wrote: Lots of meat and potatoes here, and a cookie! (spelling checker for error messages) http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.057.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.041.zip Thanks to the many people who contributed to this update! I don't know what to find more awesome with this update - possibly the operator overloading. Thanks a bunch, guys! I just noticed that Steven Schveighoffer's array append patch made it into this release. That ranks pretty high on the awesome scale too. :) -Lars
Re: dmd 1.057 and 2.041 release
Walter Bright wrote: Lots of meat and potatoes here, and a cookie! (spelling checker for error messages) http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.057.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.041.zip Thanks to the many people who contributed to this update! This is great, thank you! I'm especially looking forward to playing with the new operator overloading method. :) -Lars
Re: Tango 0.99.9 Kai released
Nick Sabalausky wrote: "bearophile" wrote in message news:hktvfk$1i5...@digitalmars.com... Nick Sabalausky: How do you ever get to 1.0 then? Is that a serious question? The answer: for example at release 0.275.1, that is when you want, when you think the software is good enough to be called 1.0. But the tango team is ready for the next release to be 1.0. Should they wait for 0.100 or 0.101 or something before going to 1.0? I think what he means is this: If you look at the Tango release history, the version numbers are ... 0.7 0.8 0.9 0.95 0.96 0.97 0.98 0.99 0.99.1 ... 0.99.9 and so on, asymptotically approaching 1.0, instead of the (arguably) more common 0.1 0.2 ... 0.9 0.10 0.11 ... 0.99 0.100 0.101 ... 0.whatever 1.0 The question was why they chose the scheme they did, and there really is no need for any answer other than "because they felt like it". Fun fact: TeX version numbers asymptotically approach pi, while METAFONT version numbers approach e. :) -Lars
Re: New vim d.vim syntax highlighting script
Jason Mills wrote: I have uploaded a new d.vim syntax highlighting script to vim.org. Get it at http://www.vim.org/scripts/script.php?script_id=379. Updated to D versions 1.053 and 2.039. + Merged Kirk McDonald's version 0.17 updates (http://paste.dprogramming.com/dplmb7qx?view=hidelines), including delimited strings, token strings, here strings, and some new keywords. + Merged Jesse K. Phillips' patch for some keywords and attributes (annotations). + Added some missing keywords. This is great. Thanks! :) -Lars
Re: SciD: the humble beginning
dsimcha wrote: We've got the beginnings of a good matrix/numerics lib in your work. I believe that my dstats lib would provide just about all the statistical functionality a good scientific lib would need, and I'm getting close to declaring it beta-quality. I'd say based on a quick look at what scipy has that we also need the following for a credible full-fledged scientific lib: dstats has actually been kind of an inspiration for me. I've never used it, because I don't do any statistics, but I've looked through the API docs and the examples, and I really like the interface. Machine learning, i.e. classification and clustering. (I'd probably be qualified to write that and was halfway thinking of breaking ground on it over Christmas break. However, I'm not committing to this yet, so if someone else already has a work in progress, let me know. Also, there's a Java machine learning library called Weka that I've used before. It's very complete but the API is painful and it's GPL, so IDK if it'd be worth it to port to D.) Optimization. (A few people have tried but IDK if they've actually gotten far off the ground with it.) Basic image I/O and processing. Plotting. I've considered doing this a few times, but I've decided it needs to be put off until D2 is stable and the GUI toolkits for it are reasonably stable. One layer of instability (D2 itself) is workable, but two layers (D2 and the GUI libs) is not. A few things that can be added to the list: - special functions - Fourier transforms - Monte Carlo methods - series - least-squares fitting - differential and integral equations There is a good chance that I will need the latter for work just after the holidays, in which case I'll write it myself. I'll add the above lists to the project home page. -Lars
Re: SciD: the humble beginning
dsimcha wrote: == Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article I've just created a new dsource project and uploaded my collection of numerical routines. You can find it here: http://www.dsource.org/projects/scid Hopefully others will find it useful as well. Most of the code is written with a "get it to work - NOW" philoshophy, and as such there is a lot of potential for improvement and polish, not least when it comes to performance. I am aware of this, so there is really no need to benchmark it against established scientific libraries quite yet. ;) More routines will be added as I write them (which is usually when I need them for work), and the existing ones will be polished whenever I have time to do so. Huge thanks to Bill Baxter for letting me use his BLAS and LAPACK bindings! Requirements: DMD 2.037 BLAS and LAPACK libraries -Lars This looks absolutely terrific given that it's a work in progress and all. I agree that we shouldn't be too obsessed with performance yet because: 1. **Make it work**, make it right, make it fast. We can always optimize it later provided that there aren't any ridiculously bad design decisions. A lot of the code is ported from 20-30 year old (i.e. extremely well tested) FORTRAN code, so any performance gains would be a bonus provided by the D language itself, and most likely not in the algorithms. Also, if you spot any ridiculously bad design decisions, let me know. ;) 2. At least some of the time people (myself included) would rather a nice API and decent performance than an ugly API (read: a straight Fortran or C API) and lightening quick performance. Yeah, that's what I think too. And, the way it is now, people who for some reason want to use the old-style api can just access the scid.ports functions directly. We've got the beginnings of a good matrix/numerics lib in your work. I believe that my dstats lib would provide just about all the statistical functionality a good scientific lib would need, and I'm getting close to declaring it beta-quality. I'd say based on a quick look at what scipy has that we also need the following for a credible full-fledged scientific lib: Machine learning, i.e. classification and clustering. (I'd probably be qualified to write that and was halfway thinking of breaking ground on it over Christmas break. However, I'm not committing to this yet, so if someone else already has a work in progress, let me know. Also, there's a Java machine learning library called Weka that I've used before. It's very complete but the API is painful and it's GPL, so IDK if it'd be worth it to port to D.) Optimization. (A few people have tried but IDK if they've actually gotten far off the ground with it.) Basic image I/O and processing. Plotting. I've considered doing this a few times, but I've decided it needs to be put off until D2 is stable and the GUI toolkits for it are reasonably stable. One layer of instability (D2 itself) is workable, but two layers (D2 and the GUI libs) is not. I agree with all of this. Here's a piece of advice to anyone who wants to try their hand at these and other things: There are a LOT of established and *extremely* well-tested numerical libraries lying around on the internet, and many of them are in the public domain. Instead of spending a lot of time re-inventing the wheel (I've tried it), port some old code and try to improve on it when you get it working. Here are a few starting points: http://www.netlib.org/ http://gams.nist.gov/ And I forgot to say in my original announcement: I welcome contributors with open arms. I have no intention of making this a one-man show. If you want to contribute or participate in some way, let me know. -Lars
SciD: the humble beginning
I've just created a new dsource project and uploaded my collection of numerical routines. You can find it here: http://www.dsource.org/projects/scid Hopefully others will find it useful as well. Most of the code is written with a "get it to work - NOW" philoshophy, and as such there is a lot of potential for improvement and polish, not least when it comes to performance. I am aware of this, so there is really no need to benchmark it against established scientific libraries quite yet. ;) More routines will be added as I write them (which is usually when I need them for work), and the existing ones will be polished whenever I have time to do so. Huge thanks to Bill Baxter for letting me use his BLAS and LAPACK bindings! Requirements: DMD 2.037 BLAS and LAPACK libraries -Lars
Re: dmd 1.053 and 2.037 release
Don wrote:
Don wrote:
Lars T. Kyllingstad wrote:
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks to the numerous people who contributed to this update.
Thanks, guys! This is a pretty awesome release. :) I especially like
that opPow made it in, and also the changes to std.math look very
useful.
I have one question regarding the latter: What exactly is supposed to
happen when I run the example in the FloatingPointControl
documentation? Is the program supposed to crash with some informative
error message, or do I have to do something to catch the exception?
Currently, nothing out of the ordinary happens when I run it on my
computer -- y just becomes NaN when x is NaN.
Aargh, the example's wrong. DMD optimizes the assignment into a blit.
Try setting y = x*2.
I take that back. The example is correct. This code...
-
import std.math;
void main()
{
real x;
FloatingPointControl fpctrl;
fpctrl.enableExceptions(FloatingPointControl.severeExceptions);
double y = x*3.0;
}
results in:
object.Error: Invalid Floating Point Operation
However, it seems that the compiler is no longer creating variables of
type double and float as signalling NaNs. That's a bug.
OK, thanks for explaining. :)
-Lars
Re: dmd 1.053 and 2.037 release
Don wrote: Walter Bright wrote: Probably the biggest thing is opDispatch! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.053.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.037.zip Many thanks to the numerous people who contributed to this update. I just noticed: I don't see @property in the changelog anywhere, but it's now in the spec. @safe, @trusted, @system aren't there either. Do @safe, @trusted and @system actually do anything yet? It seems @property now enforces the "0 or 1 parameter" constraint, but one can still use property syntax to call n...@property functions. -Lars
Re: dmd 1.053 and 2.037 release
Walter Bright wrote: Probably the biggest thing is opDispatch! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.053.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.037.zip Many thanks to the numerous people who contributed to this update. Thanks, guys! This is a pretty awesome release. :) I especially like that opPow made it in, and also the changes to std.math look very useful. I have one question regarding the latter: What exactly is supposed to happen when I run the example in the FloatingPointControl documentation? Is the program supposed to crash with some informative error message, or do I have to do something to catch the exception? Currently, nothing out of the ordinary happens when I run it on my computer -- y just becomes NaN when x is NaN. -Lars
Re: Code Poet, an IDE for D
Lars T. Kyllingstad wrote: Jeremie Pelletier wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell and had a hard time linking garbage collected D objects to C++ reference counted objects without adding complex overhead. So after spending two weeks on these failed attempts, I jumped back into C++ after two years of almost only writing D code, this time using boost, and boy is that library sweet! Here is the (very simple) website of the project, with a screenshot of the program so far, the content is hard coded for now to test the custom editor painting routines. http://codepoet.sourceforge.net Jeremie Though I don't use an IDE myself, I think this is great. It is often mentioned on the NG that one of the things keeping people away from D is the fact that there are so few IDEs with good D support. Are you strictly targeting Windows, or will this be available for other platforms as well? Forget it, I see you've already answered this in another post. :) -Lars
Re: Code Poet, an IDE for D
Jeremie Pelletier wrote: It's been some time since I last posted to this newsgroup, I've been quite busy these past weeks! Among other things, I started writing an IDE for D from scratch and opened a SourceForge project for it a few minutes ago, I'll also open a dsource project to link to the sf one in the following days. At first I tried to code it in D using wxD but soon found out the limitations of these bindings, then I tried to write my own wxWidgets bindings which worked great until i realized I was leaking memory like hell and had a hard time linking garbage collected D objects to C++ reference counted objects without adding complex overhead. So after spending two weeks on these failed attempts, I jumped back into C++ after two years of almost only writing D code, this time using boost, and boy is that library sweet! Here is the (very simple) website of the project, with a screenshot of the program so far, the content is hard coded for now to test the custom editor painting routines. http://codepoet.sourceforge.net Jeremie Though I don't use an IDE myself, I think this is great. It is often mentioned on the NG that one of the things keeping people away from D is the fact that there are so few IDEs with good D support. Are you strictly targeting Windows, or will this be available for other platforms as well? -Lars
Re: Metaprogramming in D : Some Real-world Examples
Jacob Carlborg wrote:
On 11/10/09 01:27, Bill Baxter wrote:
On Mon, Nov 9, 2009 at 4:09 PM, Walter Bright
wrote:
Looks like Bill Baxter is giving a presentation on D Nov. 18!
http://www.nwcpp.org/
Yep, that's right, and I'd be quite grateful to you smart folks here
if you could share your meta-programming favorites with me! If
you've got a real-world example of meta-programming in D that you
think is particularly handy, then please send it my way
I'm looking for small-but-useful things that are easy to explain, and
make something easier than it would be otherwise. Things like places
where static if can save your butt, or loop unrolling, and passing
code snippets to functions like in std.algorithm.
Things like a compile-time raytracer or regexp parser (though quite
cool!) are not what I'm after. Too involved for a short talk.
--bb
This is invaluable to me, which makes it possible to do some form of
duck typing at compile time:
static if (is(typeof({
/* does this compile */
})))
There are forces at work (Don, that is) attempting to get rid of that
very construct and replace it with something better:
http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_Replace_traits_and_is_typeof_XXX_with_a_magic_namespace_._99914.html
In my humble opinion, is(typeof({...})) is an ugly creature. I really
don't think it should be put under a spotlight as a good example of D
metaprogramming. If anything, please use __traits(compiles, {...}) instead.
-Lars
Re: parallelFuture
Andrei Alexandrescu wrote: Christopher Wright wrote: Andrei Alexandrescu wrote: dsimcha wrote: Again, code: http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d Docs: http://cis.jhu.edu/~dsimcha/parallelFuture.html What license is the library under? Andrei Boost. I suppose you didn't want to look at the source in case the license wasn't sufficiently liberal, but it's easy enough to scan through the module's doc comments for a license block, without reading the source code. I actually did take a look but couldn't visually find the license block at the beginning or end of the code, sorry. Now I see it's a bit below the beginning. Great - it would be cool if we could adapt this for Phobos. I'm hoping Sean (who is fleshing out his messaging API) and David could find ways to integrate their work. I was actually going to suggest just that. :) I definitely think this deserves a place in Phobos. The parallel foreach alone covers a lot of use cases for multithreaded code in the simplest way. -Lars
Re: parallelFuture
dsimcha wrote:
I've created an alpha release of parallelFuture, a high-level parallelization
library for D2. Right now, it has a task pool, futures, parallel foreach, and
parallel map.
Here's the (IMHO) coolest example:
auto pool = new ThreadPool();
// Assuming we have a function isPrime(), print all
// prime numbers from 0 to uint.max, testing for primeness
// in parallel.
auto myRange = iota(0, uint.max);
foreach(num; pool.parallel(myRange)) {
if(isPrime(num)) {
synchronized writeln(num);
}
}
The interface is there and it seems to work, although it has not been
extensively stress tested yet. Some of the implementation details could
admittedly use some cleaning up, and I would appreciate help from some
threading gurus on improving my queue (right now it's a naive synchronized
singly-linked list) and getting condition mutexes to work properly. (Right
now, I'm using atomic polling followed by sleeping for 1 millisecond in a lot
of places. It's a kludge, but it seems to work reasonably well in practice.)
The code is at:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d
The docs are at:
http://cis.jhu.edu/~dsimcha/parallelFuture.html
Very nice! Parallelisation for us ordinary folks. :) I tried your
isPrime example, which was very cool. I can't wait to try the library in
a real application.
I often have a situation where I have a set of grid points, and I do
(mostly) separate calculations on each grid point. Your library should
allow me to do calculations on several grid points in parallel, with
minimal changes to my code.
Is there some particular reason why you have capitalised the F in the
file name, but not in the module name?
-Lars
Re: dmd 1.047 and 2.032 releases
Walter Bright wrote: This will probably be the last OSX 10.5 release, the next should be 10.6. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.047.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.032.zip Many thanks to the numerous people who contributed to this update. This is great! I can't wait to try out the compiler's new CTFE capabilities. :) Thanks, Walter, Don, Andrei, and other contributors, for putting in all the hard work! -Lars
Re: dmd 1.046 and 2.031 releases
Ary Borenszweig wrote: のしいか (noshiika) escribió: Thank you for the great work, Walter and all the other contributors. But I am a bit disappointed with the CaseRangeStatement syntax. Why is it case 0: .. case 9: instead of case 0 .. 9: With the latter notation, ranges can be easily used together with commas, for example: case 0, 2 .. 4, 6 .. 9: And CaseRangeStatement, being inconsistent with other syntaxes using the .. operator, i.e. slicing and ForeachRangeStatement, includes the endpoint. Shouldn't D make use of another operator to express ranges that include the endpoints as Ruby or Perl6 does? I agree. I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away. When the discussion first came up in the NG, I was a bit sceptical about Andrei's suggestion for the case range statement as well. Now, I definitely think it's the best choice, and it's only because I realised it can be written like this: case 1: .. case 4: // do stuff Even though it's the same as case 1: .. case 4:, and even though adding those two newlines is just a visual change, it leaves (to me, at least) no doubt that this is an inclusive range even though the .. operator is used, simply because what I would otherwise write is: case 1: case 2: case 3: case 4: // do stuff Also: Thanks for a great release, Walter, Andrei, Don, Sean and everyone else! (Who else are involved in core development of D2, by the way?) I am liking this language better and better the more I use it. And now, to convince the rest of the scientific community that FORTRAN must go... -Lars
A (very) simple build/install/remove script
On the off chance that anyone is interested, I've attached a small, very simple, Bash script I've made that takes care of building, installing and uninstalling small and simple D libraries. Just put it somewhere in your path, mark it as executable, and off you go. :) Note that it only works with DMD. It assumes a straightforward library structure. As an example, say you have a library "foo" consisting of, say, the modules foo.bar and foo.baz. These should then be located in the files foo/bar.d and foo/baz.d. Then, from foo/'s parent directory, type the following commands. To build the library (it will be located in .dlib/libfoo.a afterwards): dlib build foo To install the library and sources to /usr/local: sudo dlib install foo To remove the library and sources again: sudo dlib remove foo To remove dlib's hidden working dir: dlib clean I made the script for my own, personal use. Though it ain't exactly DSSS, I hope that someone else will find it useful as well. :) -Lars The usual disclaimer follows: You use this script at your own risk. Under no circumstances shall the author be held responsible for any consequences of your use of the script. #!/bin/bash # Simple library build script. # # Author: Lars T. Kyllingstad, pub...@kyllingen.net # Licence:WTFPL # Disclaimer: You use this script at your own risk. Under no # circumstances shall the author be held responsible # for any consequences of your use of the script. ME=`basename "$0"` # Change to suit your preferences PREFIX="/usr/local" WRKDIR=".$ME" # Read arguments CMD="$1" shift SRCDIR="$1" shift DMDOPTS="$@" # Locate source files and directories LIBFILE="lib$SRCDIR.a" LIBPATH="$WRKDIR/$LIBFILE" HDRDIR="$WRKDIR/$SRCDIR" # Locate target directories SYSLIBDIR="$PREFIX/lib" SYSINCDIR="$PREFIX/include/d" # If no arguments are given, show help if [ -z "$CMD" ]; then echo "Usage:" echo " $ME build [DMD options] -- Build a library" echo " $ME install-- Install a library" echo " $ME remove -- Uninstall a library" echo " $ME clean -- Clean up after build process" exit fi # Operation: Remove temporary directory if [ "$CMD" == "clean" ]; then rm -r "$WRKDIR" exit fi # Check if a library name is given. if [ -z "$SRCDIR" ]; then echo "$ME: $CMD which library?" exit fi # Operation: Remove installed library. if [ "$CMD" == remove ]; then rm "$SYSLIBDIR/$LIBFILE" rm -r "$SYSINCDIR/$SRCDIR" exit fi # Find source files. if [ ! -d "$SRCDIR" ]; then echo "$ME: source directory '$SRCDIR' not found." exit 1 fi SOURCES=`find $SRCDIR | grep '\.d$' | grep -v '\.svn'` # Operation: Install library and include files. if [ "$CMD" == "install" ]; then if [ ! -f "$LIBPATH" ]; then echo "$ME: library file '$LIBFILE' not found." exit 1 fi mkdir -p -m 0755 "$SYSLIBDIR" "$SYSINCDIR" install -p -m 0644 "$LIBPATH" "$SYSLIBDIR" cp -r $HDRDIR "$SYSINCDIR" exit fi # Operation: Build library. if [ "$CMD" == "build" ]; then dmd $SOURCES -lib -od$WRKDIR -of$LIBFILE $DMDOPTS cp -r --parents $SOURCES "$WRKDIR/" exit fi echo "$ME: invalid command: $CMD" exit 2
Re: dmd 2.029 release
Andrei Alexandrescu wrote: Lars T. Kyllingstad wrote: Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip This is looking very nice! I want to switch from D1 to D2, but... I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work? I would kill for a 64-bit Linux DMD. [...] Who does one have to kill to get a 64-bit compiler around here? :) But seriously, now that the language itself is stabilising, I would consider this a major priority for further development of DMD. 64 bits is the (immediate) future. -Lars
Re: dmd 2.029 release
Walter Bright wrote: This is a major revision to Phobos, including Andrei's revolutionary new range support. http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.029.zip This is looking very nice! I want to switch from D1 to D2, but... I don't want to sound greedy or anything, and I know others have asked for this before, but is making a 64-bit Linux version of DMD a lot of work? I admit I don't know much about these things, and what I'm going to say next may not make sense at all, but here goes: x86-64 is just a superset of x86, right? Wouldn't it be possible, as a first step in the direction of a full-fledged x86-64 compiler, to simply make one that uses the same instruction set as the current DMD, but, I dunno, marks the executable as 64-bit (or something like that)? Specialisation and optimisation for the 64-bit architecture could then come at a later point in time. I know it is possible to run the 32-bit compiler (and the executables it produces) on a 64-bit operating system, but it isn't possible to link against 64-bit libraries. This means that one has to install and maintain 32-bit versions of all the libraries one wants to use, and those are, in general, not available through the repositories of most 64-bit distros. -Lars
