Re: too early for D2 and too late for D1
On 4/18/11 4:00 AM, Adam D. Ruppe wrote: jasonw wrote: If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now. My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future. Please do so! :-) I'm very curious about this.
Re: too early for D2 and too late for D1
On Apr 18, 11 07:34, David Nadlinger wrote: On 4/18/11 12:34 AM, Daniel Gibson wrote: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw This should probably be mentioned at the bitbucket wiki. Ah, sorry, this was a side effect of QtD currently being in limbo between Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just replaced the Bitbucket Wiki frontpage with a link to DSource until someone finds time to properly migrate all the contents – the patch was not the only dead link… As for the patch itself, it is more or less just a quick hack to be able to access e.g. the module a declaration is in, which is needed for some parts of the enum handling code – Max Samukha knows the details. It should also be noted that you don't necessarily need to patch DMD if your application builds fine without the patch. David The patch is now integrated into dmd :) https://github.com/D-Programming-Language/dmd/commit/2e261cd640e5266c569ad224ffbfe229a0315d97
Re: too early for D2 and too late for D1
"David Nadlinger" wrote in message news:ioftkj$2811$1...@digitalmars.com... > On 4/18/11 12:34 AM, Daniel Gibson wrote: > https://bitbucket.org/qtd/repo/wiki/Home and > > https://bitbucket.org/qtd/repo/wiki/DmdPatch I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch >>> http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw >> >> This should probably be mentioned at the bitbucket wiki. > > Ah, sorry, this was a side effect of QtD currently being in limbo between > Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just > replaced the Bitbucket Wiki frontpage with a link to DSource until someone > finds time to properly migrate all the contents - the patch was not the > only dead link. > > As for the patch itself, it is more or less just a quick hack to be able > to access e.g. the module a declaration is in, which is needed for some > parts of the enum handling code - Max Samukha knows the details. > I've had need for a feature like that, too. Luckily in my case, I only needed to get the name of the current module (within some mixed-in code), so I was able to hack my way through with a dummy var and some mangle/demangle gymnastics. I definitely agree that a more general "get module of symbol" is needed.
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 23:54:30 +0200 Ulrik Mikaelsson wrote: > My view, is the D community right now are thinking long and hard about > their own needs, and less of the needs of their users. (For a > language, the application programmer IS the user.) Maybe even rightly > so, getting things language-wise right from the start IS important! > However, if it is desirable to attract developers that want to use D > for productivity right now, there are a lot of practical issues that > needs addressing, rough edges to smoothen, and hardly any of them lie > in the language itself. I agree. Shortly after I joined this place, Walter sent a post listing different ways how community can help D. Here it is: * Write articles about D and post them online in various forums * Go through bugzilla and submit patches for bugs * Provide D interfaces (.di files) to popular C libraries * Integrate D support for your favorite editor * Write convoluted code to try and break the compiler * Contribute to the GDC and LDC projects *Write library modules for an area that you know well Interestingly enough, it's not listed 'write general-purpose application in D...so that others can see D is useful for writing practical applications' and that just the way I thought I could contribute :-) Anyway, enough talk. I wish all success to D2 so that we might consider it as viable alternative for our project(s) in not so distant future. Bye... ;) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 21:49:34 + (UTC) Iain Buclaw wrote: > There should be little reason why the compiler won't build/work sweet > as roses - as no one's tested though, there may be some gaps in the C > bindings that trigger static asserts, throw undefined identifier > errors, or evoke some wacky occurrences in runtime. The guy on #D.gdc told me he was able to build dmd on 64bit FreeBSD, but the 'application' crashes due to GC. (He, according to his own words, wanted to use D, but went back to C.) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: GDC Compile Error
>> I'm not sure if this is the best place to put this question, but since I'm
guessing people here have managed to get GDC to compile D2, I thought I'd ask:
> D.gnu is the best place for GDC issues and questions.
Ah okay cool. I'll post the code here since you asked but I'll post things there
next time, thanks. :)
>> Does anyone have any ideas how to fix it?
> This is an issue with the way GDC currently handles TLS for MinGW. It
> currently
uses GCC emulation to handle TLS.
Yeah, I've run into TLS problems quite a few times before, so I guess this was
to
be expected.
>> The command line I ran was:
>> gdc -v2 -o "Temp.exe" "Temp.d"
> Is it possible for you to post the contents of Temp.d?
Sure. It's a file I keep handy on my desktop for writing single-use
programs/scripts. :) (Too bad we can't have "global statements" in D, otherwise
we
could easily script with it...)
// Temp.d
private import std.algorithm, std.array, std.base64, std.bigint, std.bind,
std.bitmanip, std.compiler, std.complex, std.concurrency, std.container,
std.conv,
std.cpuid, std.ctype, std.demangle, std.encoding, std.exception, std.file, file
=
std.file, std.format, std.functional, std.getopt, std.intrinsic, std.iterator,
std.math, std.md5, std.metastrings, std.mmfile, std.numeric, std.outbuffer,
std.path, std.process, std.random, std.range, std.regex, std.regexp, std.stdio,
std.cstream, std.stream, std.string, std.system, std.traits, std.typecons,
std.typetuple, std.uni, std.uri, std.utf, std.variant, std.c.fenv, std.c.locale,
std.c.math, cprocess = std.c.process, std.c.stdarg, std.c.stddef, cstdlib =
std.c.stdlib, cstring = std.c.string, ctime = std.c.time, std.c.wcharh,
std.windows.charset;
private import core.atomic, core.bitop, core.cpuid, core.dll_helper,
core.exception, core.memory, core.runtime, cstdio = core.stdc.stdio,
core.stdc.wchar_, core.sys.windows.windows, core.thread, core.vararg;
void main(string[] args) { }
Re: GDC Compile Error
On 4/17/2011 11:09 PM, %u wrote: I'm not sure if this is the best place to put this question, but since I'm guessing people here have managed to get GDC to compile D2, I thought I'd ask: D.gnu is the best place for GDC issues and questions. Does anyone have any ideas how to fix it? This is an issue with the way GDC currently handles TLS for MinGW. It currently uses GCC emulation to handle TLS. The command line I ran was: gdc -v2 -o "Temp.exe" "Temp.d" Is it possible for you to post the contents of Temp.d?
GDC Compile Error
I'm not sure if this is the best place to put this question, but since I'm guessing people here have managed to get GDC to compile D2, I thought I'd ask: So I just downloaded GDC from https://bitbucket.org/goshawk/gdc/downloads/gcc-4.5.2-tdm-1-gdc-r546-20110417.zip and also TDM's GCC from http://tdm-gcc.tdragon.net/download and attempted to compile a D file with it, and I ran into errors. When I tried compiling a D file (without -static), I got these errors: C:\[...]\ccIiRY15.o:Temp.d:(.data+0xa0): undefined reference to `_D3std1c6wcharh12__ModuleInfoZ' c:/mingw32/bin/../lib/gcc/mingw32/4.5.2/../../../libgphobos2.a(dll_helper.o): In function `D4core10dll_helper18dll_process_attachFT4core3sys7windows7windows6HANDLEbZb': C:\msys\1.0\home\venix\tdm\gdc-d2\dev\build\gcc-tdm32\mingw32\libphobos/../../../../src/gcc-4.5.2/libphobos/core/dll_helper.d:359: undefined reference to `_tls_callbacks_a' C:\msys\1.0\home\venix\tdm\gdc-d2\dev\build\gcc-tdm32\mingw32\libphobos/../../../../src/gcc-4.5.2/libphobos/core/dll_helper.d:359: undefined reference to `_tlsend' C:\msys\1.0\home\venix\tdm\gdc-d2\dev\build\gcc-tdm32\mingw32\libphobos/../../../../src/gcc-4.5.2/libphobos/core/dll_helper.d:359: undefined reference to `_tlsstart' Does anyone have any ideas how to fix it? The command line I ran was: gdc -v2 -o "Temp.exe" "Temp.d" Thank you!
Re: link from a dll to another function in another dll?
On Sun, 17 Apr 2011 16:09:02 -0400, maarten van damme wrote: Hello everyone, this is my second post in the digitalmars.d newsgroup and I hope it gets as good support and suggestions as my first post :) I'm playing around with the d programming language and am trying out some exotic things you normally would write in c++. Right now I'm trying to 'intercept' all calls from a program to a dll by renaming that dll and writing my own in d. In c++ you would write in the header file: #pragma comment(linker, "/export:exportfunction=nameofotherdll.dll.destinationfunction,@location") How could one write this in the d programming language? Asuming this has to be done with the pragma(lib,...) function but I don't really know how. thanks in advance, Maarten I don't know of an automated way of doing this is D. pragma(lib,...) exists, but it simply loads a specified static library. (i.e. to simplify linking/ project setup, etc). Personally, I'd just export extern(C)/extern(System) functions toa DLL, and link in a manually define the renamed DLL using a .def file and implib.
Re: too early for D2 and too late for D1
On 4/18/11 12:34 AM, Daniel Gibson wrote: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw This should probably be mentioned at the bitbucket wiki. Ah, sorry, this was a side effect of QtD currently being in limbo between Bitbucket (DVCS hosting) and DSource (wiki, issue tracker). I just replaced the Bitbucket Wiki frontpage with a link to DSource until someone finds time to properly migrate all the contents – the patch was not the only dead link… As for the patch itself, it is more or less just a quick hack to be able to access e.g. the module a declaration is in, which is needed for some parts of the enum handling code – Max Samukha knows the details. It should also be noted that you don't necessarily need to patch DMD if your application builds fine without the patch. David
Re: too early for D2 and too late for D1
On 4/17/2011 3:27 PM, Andrej Mitrovic wrote: http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw Got it, tanks!
Re: too early for D2 and too late for D1
Am 18.04.2011 00:27, schrieb Andrej Mitrovic: > On 4/18/11, Walter Bright wrote: >> On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote: >>> On Sun, 17 Apr 2011 13:45:06 -0700 >>> Walter Bright wrote: >>> I'd also like to know which bugzilla entry has that patch! >>> >>> See: >>> >>> https://bitbucket.org/qtd/repo/wiki/Home and >>> >>> https://bitbucket.org/qtd/repo/wiki/DmdPatch >> >> I clicked around that for a while, but can't seem to find the patch file >> dmd.dmd-version.patch >> >> > http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw This should probably be mentioned at the bitbucket wiki.
Re: too early for D2 and too late for D1
On 4/18/11, Walter Bright wrote: > On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote: >> On Sun, 17 Apr 2011 13:45:06 -0700 >> Walter Bright wrote: >> >>> I'd also like to know which bugzilla entry has that patch! >> >> See: >> >> https://bitbucket.org/qtd/repo/wiki/Home and >> >> https://bitbucket.org/qtd/repo/wiki/DmdPatch > > I clicked around that for a while, but can't seem to find the patch file > dmd.dmd-version.patch > > http://www.dsource.org/projects/qtd/attachment/wiki/DmdPatch/dmd.2.046.patch?format=raw
Re: too early for D2 and too late for D1
On 4/17/2011 1:54 PM, jasonw wrote: Walter Bright Wrote: On 4/17/2011 1:46 PM, jasonw wrote: I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal. Are you talking about static linking, or using shared libraries? I mentioned static binaries, but I meant statically linked binaries. So yes, a situation where everything, including the standard library, is statically linked. Many D features, such as the GC, are simply going to require a significant amount of code in the library. It is possible to cut down the library size if you are willing to eschew some features.
Re: too early for D2 and too late for D1
On 4/17/2011 1:55 PM, Gour-Gadadhara Dasa wrote: On Sun, 17 Apr 2011 13:45:06 -0700 Walter Bright wrote: I'd also like to know which bugzilla entry has that patch! See: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch I clicked around that for a while, but can't seem to find the patch file dmd.dmd-version.patch
Re: too early for D2 and too late for D1
> 2011/4/17 Gour-Gadadhara Dasa > > > On Sun, 17 Apr 2011 15:11:43 -0500 > > > > Andrew Wiley wrote: > > > Frankly, if your definition of "not ready" is that the compiler isn't > > > packaged for you, D isn't the right community to begin with. > > > > First of all, there is no 64bit compiler for FreeBSD. I was > > researching about gdc and Iain Buclaw told me (on IRC) that there > > might be problem with dmd runtime on FreeBSD. > > > > Moreover, "QtD requires a patched dmd compiler.", so I simply do not > > have time to fight such things. > > I just want to add one thing. I am, too, trying to develop "real" open > source applications in my free time, as well as practical closed > source applications at work. > > The problem I have been facing even since the start, and are still > facing, is that even if _I_ can be motivated to overcome these > hurdles, I cannot expect everyone else to feel the same motivation for > a new "obscure" C-like language. > * At work, I have a hard time explaining to my co-workers why they > need 3 hand-rolled, "this particular version" of compilers and > libraries they've never heard of, just to compile my simple 200-line > Mpeg analyzer. > * At my free time it's even worse. Finding people able and willing to > spend some time on MY pet project for free is hard enough in itself. > Explaining to them why they must first spend an afternoon dealing with > dependencies drive away the few that got past the first criteria. > > My view, is the D community right now are thinking long and hard about > their own needs, and less of the needs of their users. (For a > language, the application programmer IS the user.) Maybe even rightly > so, getting things language-wise right from the start IS important! > However, if it is desirable to attract developers that want to use D > for productivity right now, there are a lot of practical issues that > needs addressing, rough edges to smoothen, and hardly any of them lie > in the language itself. It's normal to have to deal with a new toolchain when dealing with a new programming language. It doesn't matter how mature a programming language and its toolchain are; if you're not familiar with it, then you have some learning to do. That's true of any programming language. Now, that's obviously a hurdle, but it's one that you always have to deal with when dealing with a new programming language, no matter how good it is or isn't. It's true that if the language were more mature, it would probably be easier to install and set up the compiler and standard libraries (particularly since Linux distros would then be set up to just install them all properly if you tell it to install the appropriate package or packages), but there are _always_ issues with getting someone to use a new language. As for improvements to D, its libraries, and its toolchain, those improvements _are_ happening. All you have to do is look at the changelog to see that work is being done. However, there are only so many people involved, and it takes time. So, no, in many ways, D is not ready for prime time, but it's getting there. D is very useable at this point, but there's a still a lot of work to be done for it, and whether it'll do what you're looking for and do it well enough depends entirely on what you're trying to do. GUI applications would be one area where it's definitely behind, but GUI libraries are one of the hardest and most complicated types of libraries out there, so they're likely to be behind. We'll get there, but it takes time. D continues to improve, but it still has a ways to go. But if you're willing to put up with its issues as it matures, it's well worth using. - Jonathan M Davis
Re: too early for D2 and too late for D1
2011/4/17 Gour-Gadadhara Dasa > > On Sun, 17 Apr 2011 15:11:43 -0500 > Andrew Wiley wrote: > > > Frankly, if your definition of "not ready" is that the compiler isn't > > packaged for you, D isn't the right community to begin with. > > First of all, there is no 64bit compiler for FreeBSD. I was > researching about gdc and Iain Buclaw told me (on IRC) that there > might be problem with dmd runtime on FreeBSD. > > Moreover, "QtD requires a patched dmd compiler.", so I simply do not > have time to fight such things. > I just want to add one thing. I am, too, trying to develop "real" open source applications in my free time, as well as practical closed source applications at work. The problem I have been facing even since the start, and are still facing, is that even if _I_ can be motivated to overcome these hurdles, I cannot expect everyone else to feel the same motivation for a new "obscure" C-like language. * At work, I have a hard time explaining to my co-workers why they need 3 hand-rolled, "this particular version" of compilers and libraries they've never heard of, just to compile my simple 200-line Mpeg analyzer. * At my free time it's even worse. Finding people able and willing to spend some time on MY pet project for free is hard enough in itself. Explaining to them why they must first spend an afternoon dealing with dependencies drive away the few that got past the first criteria. My view, is the D community right now are thinking long and hard about their own needs, and less of the needs of their users. (For a language, the application programmer IS the user.) Maybe even rightly so, getting things language-wise right from the start IS important! However, if it is desirable to attract developers that want to use D for productivity right now, there are a lot of practical issues that needs addressing, rough edges to smoothen, and hardly any of them lie in the language itself.
Re: too early for D2 and too late for D1
== Quote from Gour-Gadadhara Dasa (g...@atmarama.net)'s article > --Sig_/Ckct3lX7w5hlz_Hd5UDhpMB > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > On Sun, 17 Apr 2011 15:11:43 -0500 > Andrew Wiley wrote: > > Frankly, if your definition of "not ready" is that the compiler isn't > > packaged for you, D isn't the right community to begin with. > First of all, there is no 64bit compiler for FreeBSD. I was > researching about gdc and Iain Buclaw told me (on IRC) that there > might be problem with dmd runtime on FreeBSD. Emphasis on the word 'might' O:) There should be little reason why the compiler won't build/work sweet as roses - as no one's tested though, there may be some gaps in the C bindings that trigger static asserts, throw undefined identifier errors, or evoke some wacky occurrences in runtime.
Re: too early for D2 and too late for D1
"Adam D. Ruppe" wrote in message news:iofgtn$1ifg$1...@digitalmars.com... > jasonw wrote: >> If you want to build some fortune 500 website from scratch, D >> doesn't deliver the functionality you need right now. > > My clients and I would disagree :-) > > I've been using D, almost exclusively, to write business websites > for quite a while now. There's a lot of big advantages there over > more traditional web languages. I'm hoping to write up an article > detailing some of it in the near future. Yea. Java and C# might be more mature than D right now, but D is just such a better langauge anyway (IMO) that I find D's immaturity to be a huge improvement over Java/C#'s limitations. As far as the maturity of PHP though...PHP has *never* been anything that even remotely resembed "mature" (or "stable" for that matter), and I don't believe for a second that it ever will be. It is popular, heavily used, and has a big ecosystem, but it's like a metropolitan city that's built in a really big playground sandbox using silly putty instead of mortar. It's like VB or COBOL: A toy that businesses have mistaken for a serious langauge.
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 22:44:20 +0200 Andrej Mitrovic wrote: > But you've opened this topic because D2 is not ready, and now you want > to switch to Python 3 which might not be ready yet as well? E.g. see: > python3wos.appspot.com Fortunately, Python comes with the big "batteries included" so that besides pyQt & pytz, no need for anything else. Moreover, the majority of stuff from the above list is Plone, Zope & Django stuff which we do not care about. Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On 04/17/2011 03:00 PM, Adam D. Ruppe wrote: jasonw wrote: If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now. My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future. Don't forget the iPad2 contest... Andrei
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 13:45:06 -0700 Walter Bright wrote: > I'd also like to know which bugzilla entry has that patch! See: https://bitbucket.org/qtd/repo/wiki/Home and https://bitbucket.org/qtd/repo/wiki/DmdPatch Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
Walter Bright Wrote: > On 4/17/2011 1:46 PM, jasonw wrote: > > I'd like to hear your comments about the 32-bit D2 and minimal executables > > issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 > > kilobytes. DMD should have some switch (-embedded) which leaves out all the > > cruft I don't need. I'd like to use the cool new features and start with > > this > > kind of minimal executables. 0.5 - 50 kilobyte range is optimal. > > Are you talking about static linking, or using shared libraries? I mentioned static binaries, but I meant statically linked binaries. So yes, a situation where everything, including the standard library, is statically linked.
Re: too early for D2 and too late for D1
On 4/17/2011 1:34 PM, Gour-Gadadhara Dasa wrote: Moreover, "QtD requires a patched dmd compiler.", so I simply do not have time to fight such things. I'd also like to know which bugzilla entry has that patch!
Re: too early for D2 and too late for D1
On 4/17/2011 2:37 PM, Gary Whatmore wrote: In every young language community the first users have to make sacrifices and build the ecosystem. That's how it goes. While I'm not endorsing the rude tone of the rest of this post, this is an extremely good point. According to Wikipedia, Python is about 8 years older than D. I imagine that 8 years ago people were saying the same things about Python that they say about D now. Back then, everyone was using Perl for Python's niche and probably (I wasn't a programmer back then) saying how Python's ecosystem is too immature, Perl is good enough despite its warts, there's so much existing code written in it, etc. There will always be a tradeoff between using the latest and greatest language that the ecosystem hasn't caught up with yet and using an older language with tons of legacy baggage, bad-in-hindsight or outdated design decisions and great, mature tools and libraries. D is strongly in the former category. Java and C++ are in the latter. Python is somewhere in between. Ironically, unlike the real trolls we deal with, Gour seems to understand this. All he's saying is that D2 does not embody the tradeoff he wants to make right now.
Re: Temporarily disable all purity for debug prints
On Sun, Apr 17, 2011 at 3:30 PM, dennis luehring wrote:
> On 11.04.2011 23:27, bearophile wrote:
>>
>> From what I am seeing, in a D2 program if I have many (tens or more) pure
>> functions that call to each other, and I want to add (or activate) a
>> printf/writeln inside one (or few) of those functions to debug it, I may
>> need to temporarily comment out the "pure" attribute of many functions
>> (because printing can't be allowed in pure functions).
>>
>> As more and more D2 functions become pure in my code and in Phobos,
>> something like a -disablepure compiler switch (and printf/writeln inside
>> debug{}) may allow more handy debugging with prints (if the purity is well
>> managed by the compiler then I think disabling the pure attributes doesn't
>> change the program output).
>>
>> Bye,
>> bearophile
>
> sounds a little bit like the need to see an private/protected part of an
> interface in unittest scenarios - just to be able to test it in a
> whitebox-testing without changing the attributes of the productive-code
Isn't this already there because "private" makes things visible to all
other code in the same module?
Re: too early for D2 and too late for D1
On 4/17/2011 1:46 PM, jasonw wrote: I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal. Are you talking about static linking, or using shared libraries?
Re: too early for D2 and too late for D1
Walter Bright Wrote: > On 4/17/2011 1:27 PM, Daniel Gibson wrote: > > 1. Phobos and druntime is statically compiled in. On a really limited > > embedded platform you wouldn't use Phobos anyway, but write your own > > standardlib and runtime that suit your needs (it's not like anybody > > would use full C++ with STL on such a platform. Well, probably not even > > C++ at all or only a very limited subset). > > On 16 bit DOS computers, you can't use C++ STL or even exception handling. I'd like to hear your comments about the 32-bit D2 and minimal executables issue. If I use dietlibc and gcc, the minimal (static) binary is about 0.2 kilobytes. DMD should have some switch (-embedded) which leaves out all the cruft I don't need. I'd like to use the cool new features and start with this kind of minimal executables. 0.5 - 50 kilobyte range is optimal.
Re: too early for D2 and too late for D1
On 4/17/11, Gour-Gadadhara Dasa wrote: > Well, I believe that 2.7 is, similar to D1, dead-end, while 3.x is the > future, as D2. ;) But you've opened this topic because D2 is not ready, and now you want to switch to Python 3 which might not be ready yet as well? E.g. see: python3wos.appspot.com I know a year or two ago there was a severe lack of libraries for Py3. Maybe things are better now, but I haven't checked. It's your call. :)
Re: too early for D2 and too late for D1
On 4/17/2011 1:27 PM, Daniel Gibson wrote: 1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset). On 16 bit DOS computers, you can't use C++ STL or even exception handling.
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 15:11:43 -0500 Andrew Wiley wrote: > Frankly, if your definition of "not ready" is that the compiler isn't > packaged for you, D isn't the right community to begin with. First of all, there is no 64bit compiler for FreeBSD. I was researching about gdc and Iain Buclaw told me (on IRC) that there might be problem with dmd runtime on FreeBSD. Moreover, "QtD requires a patched dmd compiler.", so I simply do not have time to fight such things. > D has libraries, it's just a matter of downloading, building, and > reporting bugs rather than installing, reading a book, and firing up > the UI designer. They're rough, but they're there. Can you name me some serious GUI application using e.g. QtD & sqlite database badck-end written in D2? > I'm (and I think I can say we're) sad to see you go, and hopefully > you'll look to D in the future, but in the present, choose the right > tool for the job. It's unwise to do anything else. /me nods > (Unless you're a college student with too much time on his hands, but > I'm pretty sure that's not your situation) Right. I'm not college student, want to program in my free time and desire to write open-source application instead of building ecosystem for what I anyway do not have required skills. :-) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On 4/17/2011 1:00 PM, Adam D. Ruppe wrote: I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future. Hopefully in time for the D article contest!
Re: Temporarily disable all purity for debug prints
On 11.04.2011 23:27, bearophile wrote:
From what I am seeing, in a D2 program if I have many (tens or more) pure functions that
call to each other, and I want to add (or activate) a printf/writeln inside one (or few)
of those functions to debug it, I may need to temporarily comment out the
"pure" attribute of many functions (because printing can't be allowed in pure
functions).
As more and more D2 functions become pure in my code and in Phobos, something
like a -disablepure compiler switch (and printf/writeln inside debug{}) may
allow more handy debugging with prints (if the purity is well managed by the
compiler then I think disabling the pure attributes doesn't change the program
output).
Bye,
bearophile
sounds a little bit like the need to see an private/protected part of an
interface in unittest scenarios - just to be able to test it in a
whitebox-testing without changing the attributes of the productive-code
we need a solution for both
Re: too early for D2 and too late for D1
Caligo Wrote: > On Sun, Apr 17, 2011 at 2:52 PM, jasonw wrote: > > Gour-Gadadhara Dasa Wrote: > > > >> Well, http://d-programming-language.org/ page says: "D is a multi- > >> paradigm programming language that combines a principled approach > >> with a focus on *practicality*." and in my case I've *practical* need to > >> write GUI app. > > > > That's certainly true, if you think of the potential D2 provides. In 5 -- > > 20 years D will be a serious contestant and mature implementations beat C++ > > and traditional languages in many domains. Currently DMD produces much > > slower executables especially for high performance computing so you would > > be a total idiot to use D if the project time frame is less than 2 years. > > > > If you want to build some fortune 500 website from scratch, D doesn't > > deliver the functionality you need right now. The PHP/Java/C# platforms > > have hundreds of millions worth funding backing them. > > > > If you build a desktop application, D isn't the best choice, but you can > > still argue to your boss to use it instead because of your personal > > "productivity" issues. There's no other logical reason to use D instead of > > C++/Qt or some other mature GUI toolkit. > > > > Bloated executables aren't suitable for embedded platforms either, but in > > 10 -- 20 years we will have a D compiler that targets platforms with less > > than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler > > for very small 32-bit embedded devices in 5 years. > > > > 5 to 20 years? 10 to 20 years? How do you come up with those big and > depressing numbers? I'd like to be more optimistic, but I'm comparing the development to projects such as LLVM. The ultimate performance goal isn't static. The leading compilers and languages are getting better so the goal is also going higher with every new release of GCC, Fortran compilers, and LLVM. Don't get me wrong, D is already much faster than many "toy" languages. Faster than Java and C# in some applications. What's relevant is that the C/C++/Fortran users will only switch if D provides concrete performance improvements over their *existing* toolchains. It has taken LLVM several years and they're not yet even on par with GCC in all benchmarks. The web application issue depends on the amount of libraries. It's a community issue. The main embedded issue is code bloat. Nobody has come up with a proof of concept solution to typeinfo and template bloat. It's impossible to think it will be solved without proof of concept in less than 5 years. You disagree?
Re: too early for D2 and too late for D1
Am 17.04.2011 21:52, schrieb jasonw: > Gour-Gadadhara Dasa Wrote: > >> Well, http://d-programming-language.org/ page says: "D is a multi- >> paradigm programming language that combines a principled approach >> with a focus on *practicality*." and in my case I've *practical* need to >> write GUI app. > > That's certainly true, if you think of the potential D2 provides. In 5 -- 20 > years D will be a serious contestant and mature implementations beat C++ and > traditional languages in many domains. Currently DMD produces much slower > executables especially for high performance computing so you would be a total > idiot to use D if the project time frame is less than 2 years. *Much* slower? Really? What benchmarks are you citing? > > If you want to build some fortune 500 website from scratch, D doesn't deliver > the functionality you need right now. The PHP/Java/C# platforms have hundreds > of millions worth funding backing them. > > If you build a desktop application, D isn't the best choice, but you can > still argue to your boss to use it instead because of your personal > "productivity" issues. There's no other logical reason to use D instead of > C++/Qt or some other mature GUI toolkit. > > Bloated executables aren't suitable for embedded platforms either, but in 10 > -- 20 years we will have a D compiler that targets platforms with less than 4 > MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very > small 32-bit embedded devices in 5 years. Do you really think in "10 -- 20 years" somebody will care of your code runs in an embedded platform with only 4MB of RAM+ROM? Memory etc is so cheap that these platforms will get more powerful. Why should it take so long to have such a compiler? On the one hand: Why are D executables so "bloated"? 1. Phobos and druntime is statically compiled in. On a really limited embedded platform you wouldn't use Phobos anyway, but write your own standardlib and runtime that suit your needs (it's not like anybody would use full C++ with STL on such a platform. Well, probably not even C++ at all or only a very limited subset). 2. Garbage from templates/CTFE. You just could use less templates and stuff for your embedded platform.. also I think this will be fixed soon(ish). Don just fixed many things in CTFE, maybe this already fixes bloat, but I'm not sure. So how long could it take until there's "a D compiler that targets platforms with less than 4 MB of RAM+ROM"? I'd say anywhere between right now and never. Maybe someone already decided to develop such a compiler and told nobody yet (right now). Or someone starts now or soon and has it ready in a year or two. If nobody is interesting in developing such a compiler, we'll never have one. So: It will be there once somebody develops it. If he takes LDC or GDC (or maybe even DMD) as a basis maybe something like that could be done relatively fast (if the team is big enough and has time etc). As mentioned before, Phobos would probably not be used on such platforms, so there's no need to wait for Phobos to become more mature/complete until developing such a compiler. Cheers, - Daniel
Re: "Try it now"
On Sun, Apr 17, 2011 at 3:01 PM, Walter Bright wrote: > On 4/17/2011 12:36 PM, Andrei Alexandrescu wrote: >> >> I think adding the text to the "Running...\n" as soon as you get the >> request >> should help. > > Or: > > "Please wait while the D-9000 computer boots..." > Or "Must DESTROY John Connor!" The console background is green on black over here on the Chrome 12 dev build, so there's definitely something browser specific going on. And let me join the list of people saying this is friggin awesome. Thanks, Adam!
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 15:52:36 -0400 jasonw wrote: > If you build a desktop application, D isn't the best choice, but you > can still argue to your boss to use it instead because of your > personal "productivity" issues. There's no other logical reason to > use D instead of C++/Qt or some other mature GUI toolkit. In my case, I'm going to write desktop application and there is no 'boss' - it's going to be open-source. :-) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
On Sun, Apr 17, 2011 at 4:37 AM, Gour-Gadadhara Dasa wrote: > > Hello! > > My first post to this newsgroup was a little bit more than 6 months ago > and today I've decided to leave D and use C(P)ython + Qt for our > open-source project of writing multi-platform desktop application. > > The D community is very nice and supportive, Walter, Andrei & co. are > working hard, but, imho, D is not ready (yet). > > Recently, after switching from Linux to (Free)PC-BSD I even lost > ability to have working compiler on x86_64 (none of the compilers is > available in ports). Frankly, if your definition of "not ready" is that the compiler isn't packaged for you, D isn't the right community to begin with. > The crucial thing is that D's ecosystem is simply > not ready for day-to-day GUI programming and there is no clear roadmap > so that one can anticipate when to expect that something will be done. The problem with ecosystems is that there is never a roadmap unless your development follows the Microsoft model, where everything is benevolently dictated. That works, but D isn't Microsoft. > > Let me say, that I really like what D has on its plate, but language > needs libraries to be successful, otherwise it is only promise-land. D has libraries, it's just a matter of downloading, building, and reporting bugs rather than installing, reading a book, and firing up the UI designer. They're rough, but they're there. > > I've become tired for programming language's ecosystem to become > mature...waited too long with Haskell and arrived to D hoping it is > more pragmatic for day-to-day usage, but the situation seems even > worse...Yeah, I know...I arrived at the wrong time during D1 --> D2 > transition... > > That's, why I believe that the mantra in the subject, which I coined > in IRC the other day, holds true. > > I'm thankful to all the members of this group for every piece of > advice and input I received, as well to Andrei (his book is on my > shelf - I even put it in the hardcover), but I want to code my project > *today*, have plenty of (GUI) choices, lot of docs, tools and clear > roadmap where the certain projects are going. > > I hope I might re-evaluate D2 sometime in the future for some other > project... > I'm (and I think I can say we're) sad to see you go, and hopefully you'll look to D in the future, but in the present, choose the right tool for the job. It's unwise to do anything else. (Unless you're a college student with too much time on his hands, but I'm pretty sure that's not your situation)
link from a dll to another function in another dll?
Hello everyone, this is my second post in the digitalmars.d newsgroup and I hope it gets as good support and suggestions as my first post :) I'm playing around with the d programming language and am trying out some exotic things you normally would write in c++. Right now I'm trying to 'intercept' all calls from a program to a dll by renaming that dll and writing my own in d. In c++ you would write in the header file: #pragma comment(linker, "/export:exportfunction=nameofotherdll.dll.destinationfunction,@location") How could one write this in the d programming language? Asuming this has to be done with the pragma(lib,...) function but I don't really know how. thanks in advance, Maarten
Re: too early for D2 and too late for D1
On Sun, Apr 17, 2011 at 2:52 PM, jasonw wrote: > Gour-Gadadhara Dasa Wrote: > >> Well, http://d-programming-language.org/ page says: "D is a multi- >> paradigm programming language that combines a principled approach >> with a focus on *practicality*." and in my case I've *practical* need to >> write GUI app. > > That's certainly true, if you think of the potential D2 provides. In 5 -- 20 > years D will be a serious contestant and mature implementations beat C++ and > traditional languages in many domains. Currently DMD produces much slower > executables especially for high performance computing so you would be a total > idiot to use D if the project time frame is less than 2 years. > > If you want to build some fortune 500 website from scratch, D doesn't deliver > the functionality you need right now. The PHP/Java/C# platforms have hundreds > of millions worth funding backing them. > > If you build a desktop application, D isn't the best choice, but you can > still argue to your boss to use it instead because of your personal > "productivity" issues. There's no other logical reason to use D instead of > C++/Qt or some other mature GUI toolkit. > > Bloated executables aren't suitable for embedded platforms either, but in 10 > -- 20 years we will have a D compiler that targets platforms with less than 4 > MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very > small 32-bit embedded devices in 5 years. > 5 to 20 years? 10 to 20 years? How do you come up with those big and depressing numbers? I personally think within 2 to 4 years there is going to be an explosion of software written in D.
Re: "Try it now"
On 4/17/2011 12:36 PM, Andrei Alexandrescu wrote: I think adding the text to the "Running...\n" as soon as you get the request should help. Or: "Please wait while the D-9000 computer boots..."
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 21:45:59 +0200 Andrej Mitrovic wrote: > For what it's worth, the examples from Mark's book still compile with > Python 2.7 and the latest PyQt bindings. And PyQt itself comes with > examples that are stored in Python\lib\site-packages\pyqt4\examples\ . > I don't think a lot has changed that breaks backward-compatibility > since the book was published. Mark has provided examples for Python 3. > I don't really know what benefits you would have from Python 3.x, I > think 2.7 got some 3.x features backported to that version as well.. Well, I believe that 2.7 is, similar to D1, dead-end, while 3.x is the future, as D2. ;) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: "Try it now"
On 4/17/2011 11:22 AM, Adam D. Ruppe wrote: new version of javascript up: http://arsdnet.net/d-web-site/std_algorithm2.html Adam, this is really awesome work! Some trivial nits: 1. The output window is offset 3 or 4 pixels to the left of the source window. 2. The source window has a 1 pixel box around it. The output window has a two pixel border on the left and top sides only. This makes it look out of place. 3. The lime-green-on-white text in the output window is a little hard to read comfortably. Perhaps a darker green? I'm running IE9 in case these issues are browser specific.
Re: too early for D2 and too late for D1
jasonw wrote: > If you want to build some fortune 500 website from scratch, D > doesn't deliver the functionality you need right now. My clients and I would disagree :-) I've been using D, almost exclusively, to write business websites for quite a while now. There's a lot of big advantages there over more traditional web languages. I'm hoping to write up an article detailing some of it in the near future.
Re: "Try it now"
Andrei Alexandrescu wrote: > Oh, and I think learning git/github is a huge net gain outside of > any particular project. I warmly recommend it. Yeah, I've used git before on the command line, but never the website. I'll admit though that for my typical project, my idea of source control is commenting and/or remembering how many times to hit undo in the editor... But when I dive into this, most the change is trivial - the script and server side program do almost all the work. But I'd like to at the least fix some invalid html in std.ddoc too. Both browser scripts and my D dom module are able to figure it out anyway, but it'd be nice if the HTML was more well formed and maybe using better semantic tags/classnames.
Re: Stroustrup on C++0x + JSF++ coding standard
Caligo: > Besides, how long are they going to continue to add crap to > C++, or "improve" it, while retaining backward compatibility? >From the things they are adding and changing in Fortran today, I think at >least some more decades :-) Bye, bearophile
Re: "Try it now"
KennyTM~ wrote: > There are some minor styling bugs. I've only tested it on Chrome 10. Oh, I see it too. Fixed.
Re: too early for D2 and too late for D1
Gour-Gadadhara Dasa Wrote: > Well, http://d-programming-language.org/ page says: "D is a multi- > paradigm programming language that combines a principled approach > with a focus on *practicality*." and in my case I've *practical* need to > write GUI app. That's certainly true, if you think of the potential D2 provides. In 5 -- 20 years D will be a serious contestant and mature implementations beat C++ and traditional languages in many domains. Currently DMD produces much slower executables especially for high performance computing so you would be a total idiot to use D if the project time frame is less than 2 years. If you want to build some fortune 500 website from scratch, D doesn't deliver the functionality you need right now. The PHP/Java/C# platforms have hundreds of millions worth funding backing them. If you build a desktop application, D isn't the best choice, but you can still argue to your boss to use it instead because of your personal "productivity" issues. There's no other logical reason to use D instead of C++/Qt or some other mature GUI toolkit. Bloated executables aren't suitable for embedded platforms either, but in 10 -- 20 years we will have a D compiler that targets platforms with less than 4 MB of RAM+ROM. I find it unlike that we have a reliable D compiler for very small 32-bit embedded devices in 5 years.
Re: too early for D2 and too late for D1
For what it's worth, the examples from Mark's book still compile with Python 2.7 and the latest PyQt bindings. And PyQt itself comes with examples that are stored in Python\lib\site-packages\pyqt4\examples\ . I don't think a lot has changed that breaks backward-compatibility since the book was published. I don't really know what benefits you would have from Python 3.x, I think 2.7 got some 3.x features backported to that version as well..
Re: GC for pure functions -- implementation ideas
Jason House wrote: Don Wrote: Tomek Sowiñski wrote: I'm far from being a GC expert but I think Java having identified such cases with escape analysis just puts locally allocated objects on the stack. That works for the non-leaky function itself, but it doesn't help for the functions it calls. It'd reduce the use of the pure heap to leaky pure functions called from pure functions. If I understood the original proposal correctly, this would reduce how frequently pure functions have to manipulate the pure stack. I haven't thought through the exception handling case, so I may be completely wrong! It would definitely help a lot. It just wouldn't catch everything. It seems fairly difficult though. I was originally assuming the return type of a pure function was enough to determine if it wasn't leaky, You also have parameters passed by reference. but now I'm thinking only pure nothrow functions can be non-leaky. That might make the stack allocation optimization too rare to be worthwhile? It might. Although as I mentioned, you can deep-dup any exceptions onto the normal gc heap, at the moment they are caught. That deep-dup is not performance critical, and in most cases, the dup is simple. But the worst case is, the entire pure heap needs to be copied. It might turn out to be too complicated to be worthwhile, limiting the scheme to pure nothrow functions. Nontheless I think pure nothrow functions will be pretty common. Basically, my contribution is this: the compiler can easily work out, for each function, whenever it has entered and exited a non-leaky pure function. It can make a call into the GC whenever this happens. This gives the GC many more potential strategies.
Re: "Try it now"
On 04/17/2011 02:29 PM, Adam D. Ruppe wrote: Andrei Alexandrescu wrote: Adam, could you please put together a pull request on github? I've gotta figure out how that works... Oh, and I think learning git/github is a huge net gain outside of any particular project. I warmly recommend it. Andrei
Re: "Try it now"
On Apr 18, 11 02:22, Adam D. Ruppe wrote: new version of javascript up: http://arsdnet.net/d-web-site/std_algorithm2.html There are some minor styling bugs. I've only tested it on Chrome 10. For Example: code blocks: 1. Press "Try Now", then "Cancel" - the code block becomes bold. 2. Click "Try Now" again - the "Cancel" is now in the other line For non-Example: code blocks: 1. The "Try Now" button appear below the code. 2. Click "Try Now" and "Cancel" moves the button above the code. Also, I suggest the try-now examples should allow using a different piece of code than the one shown. For instance, the introductory code (the sort one) of the std.algorithm module clearly shows what the module does, but it absolutely useless for Try-Now. The result is "Program ran successfully.", so what? The user should be able to see how the array is sorted, how to provide a custom predicate, etc., and thus writeln's need to be placed after the 3 sorts. This can't be automated by Javascript. I like the w3schools approach (except the new window part), where the main page shows a concise example to let people understand how the feature is used, and the "Try it yourself" link provides a complete program with human-readable output.
Re: "Try it now"
On 04/17/2011 02:35 PM, Adam D. Ruppe wrote: bearophile wrote: I suggest to add a spinning circle for the compilation wait (see Ideone site too). Am I actually the only person in the world who *hates* those things? I might add it later though. I think adding the text to the "Running...\n" as soon as you get the request should help. Andrei
Re: "Try it now"
bearophile wrote: > I suggest to add a spinning circle for the compilation wait (see > Ideone site too). Am I actually the only person in the world who *hates* those things? I might add it later though.
Re: "Try it now"
On 04/17/2011 02:29 PM, Adam D. Ruppe wrote:
Andrei Alexandrescu wrote:
Adam, could you please put together a pull request on github?
I've gotta figure out how that works...
I'd also appreciate if you sent my way a simple script that scrapes
the HTML for all sample code so we can work on making them work.
Heh, what a coincidence. I just wrote a quick one now:
http://arsdnet.net/d-web-site/extractexamples.d
It's cgi so you can see the output here, but it's trivial to
change, very short program. Fetch my dom library here
http://arsdnet.net/d-web-site/arsd/dom.d
Example output:
http://arsdnet.net/d-web-site/extractexamples
It puts in some generic imports, an empty main, and wraps
everything in unittest {}.
Looking good. Hmmm, I think we should just compile code as it is, no
hidden artifacts. Then that adds some syntactic noise. Not sure what the
best balance is.
Andrei
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 13:51:49 -0500 Caligo wrote: > And I don't think GUI programming is the first reason people come to > D. Well, http://d-programming-language.org/ page says: "D is a multi-paradigm programming language that combines a principled approach with a focus on *practicality*." and in my case I've *practical* need to write GUI app. :-) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: "Try it now"
Andrei Alexandrescu wrote: > One more thing: make sure you solve potential cross-site scripting > that may occur I don't think any are possible - I always escape input and output, and if something does get through, it's on a different domain so the browser's cross domain restriction will keep it from getting too bad. (Indeed, these restrictions made the auto-resize a real pain in the ass!) > and prepare for seeing a fair amount of extra traffic. Naturally.
Re: "Try it now"
Andrei Alexandrescu wrote:
> Adam, could you please put together a pull request on github?
I've gotta figure out how that works...
> I'd also appreciate if you sent my way a simple script that scrapes
> the HTML for all sample code so we can work on making them work.
Heh, what a coincidence. I just wrote a quick one now:
http://arsdnet.net/d-web-site/extractexamples.d
It's cgi so you can see the output here, but it's trivial to
change, very short program. Fetch my dom library here
http://arsdnet.net/d-web-site/arsd/dom.d
Example output:
http://arsdnet.net/d-web-site/extractexamples
It puts in some generic imports, an empty main, and wraps
everything in unittest {}.
Re: "Try it now"
On 04/17/2011 02:00 PM, bearophile wrote: Adam D. Ruppe: new version of javascript up: http://arsdnet.net/d-web-site/std_algorithm2.html I suggest to add a spinning circle for the compilation wait (see Ideone site too). Probably we're good to go without that, but it'll help once the traffic increases :o). Some comments on the code examples: [snip] Since you already made a pass, I suggest you write a few pull requests on github that make examples work. Thanks, Andrei
Re: "Try it now"
On 04/17/2011 01:22 PM, Adam D. Ruppe wrote: new version of javascript up: http://arsdnet.net/d-web-site/std_algorithm2.html Great. I think this looks adequate now and ready for integration into d-programming-language.org. Adam, could you please put together a pull request on github? I'd also appreciate if you sent my way a simple script that scrapes the HTML for all sample code so we can work on making them work. Thanks, Andrei
Re: "Try it now"
On 04/17/2011 01:22 PM, Adam D. Ruppe wrote: new version of javascript up: http://arsdnet.net/d-web-site/std_algorithm2.html One more thing: make sure you solve potential cross-site scripting that may occur, and prepare for seeing a fair amount of extra traffic. In the long run we'll prepare d-programming-language.org to handle the examples itself. Thanks, Andrei
Re: too early for D2 and too late for D1
On Sun, 17 Apr 2011 20:26:49 +0200 Andrej Mitrovic wrote: > Gour, please disregard the troll above. :-) > If you're going with Python and Qt, I'd wholeheartedly recommend this > book: http://www.qtrac.eu/pyqtbook.html Yeah...I just got reply from Mark if he is planning 2nd ed. or the first one is still not obosolete. > Making GUIs with PyQT is dead simple. And Nokia already has that new > LGPL(I think?)-licensed binding in place - http://www.pyside.org. I know about, although I may try with PyQt due to py3k support. > So your decision might not be bad at all. Well, it's not ideal, but some kind of compromise. > What type of desktop app are you building? Does it need to be > very-high performance? Vedic astrology program. Performance *might* be issue, although we'll use Swiss Ephmeris C-library and try to compensate possible lack of speed by using Cython. > Python itself isn't too bad with Qt, I don't think it was slow in > any way the last time I used it. Thank you for kind words. ;) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: too early for D2 and too late for D1
I'm not defending other languages, I'm recommending them. I'm also recommending D when its appropriate. But nobody is forced to use just one programming language. I use at least half a dozen languages throughout my average week; C, C++, Python, Delphi (rarely), D, AHK, batch (hehe, ok that one doesn't count :p), some ASM which I'm just playing around with for now, and probably other languages. Gour doesn't have to quit D, he can use some time-out for a while and see what Python has to offer. In the meantime the D ecosystem will likely grow. Now, these arguments aside, onto the technical side of things. You could build a GUI in Python and then link to D via callback functions. It shouldn't be a problem with either Python's ctypes or Cython, whichever might be easier to use. Python+Qt has been stable for a long while now, so it's really not a bad choice as a GUI language. And it has good documentation and books to learn from, and plenty of example code too. I'm not sure what that would do to performance (linking Python with D), but then again I don't know what type of desktop app Gour is building. On the other hand, I've seen Python being used in a realtime app that is linked with C++. For example Ableton Live (a fairly popular music sequencer) uses the Boost C++ Python binding for a big part of their application. They use it to interface with various MIDI and sequencing hardware, and various hardware manufacturers develop their own Ableton-specific Python scripts that add support to their special hardware so it works nicely in Ableton Live. I believe they might also be using Python to run their GUI, but I can't be sure since I've only heard that offhand from some people commenting about it. Now, there's a Python binding project for D1, PyD, with exception support and various other nice things. I don't know whether anyone will work on a D2 version. But from looking at its source it doesn't look *too* complicated. In fact there's a good part of that code seems to be implementation of common functions which were missing in D1 Phobos, but are here in Phobos2. So maybe it wouldn't be too hard to port that to D2 some day. But I don't know the details.
Re: too early for D2 and too late for D1
On 4/17/2011 11:18 AM, Gary Whatmore wrote: One thing, go hang yourself. We[...] Gour-Gadadhara Dasa has done nothing to merit such inexcusable rudeness. I appreciate his polite and thoughtful post about why D is not the right solution for his needs at this time.
Re: "Try it now"
Adam D. Ruppe:
> new version of javascript up:
> http://arsdnet.net/d-web-site/std_algorithm2.html
I suggest to add a spinning circle for the compilation wait (see Ideone site
too).
Some comments on the code examples:
- The second example for reduce(), the example of group() and minCount(), the
third example of remove() need tuple
- The example of uninitializedFill, initializeAll and schwartzSort contain
dummy ... code
- The filter() example gives Error: incompatible types caused by:
auto small = filter!("a < 3")(arr);
assert(small == [ 1, 2 ]);
- Splitter() example gives another Error: incompatible types
- the first and second examples of find() gives a import conflict error
- The third find() example doesn't find tuple and gives a missing overload error
- The example of endsWith() gives algorithm.d(3127): Error: no property 'empty'
for type 'char'
- findAdjacent() lacks an auto p = ...
- balancedParens() gives an assert error
- The example of equal() gives a approxEqual error and more
- levenshteinDistance() gives Error: static assert "Bad binary function
q{toupper(a) == toupper(b)}. You need to use a valid D expression using symbols
a of type dchar and b of type dchar."
- levenshteinDistanceAndPath() gives a algorithm.d(3975): Error: undefined
identifier Range, did you mean alias Range1?
- The window formatting of bringToFront() seems wrong
- The second and third bringToFront() examples lack SList
- The 4th and 5th examples of remove() give an assert error
- The topN() example doesn't find "less"
- completeSort() gives some problems, maybe it can't find assumeSorted()
- makeIndex() example gives a template error
- topNCopy() example gives an error, maybe it's wrong
- setIntersection() example asserts statically
- largestPartialIntersection() and largestPartialIntersectionWeighted() can't
find Tuple
Thank you for reminding me how hugely useful is the Python doctests module :-)
Bye,
bearophile
Re: too early for D2 and too late for D1
D2 is ready. There are some compiler bugs that might cause problems, but they will go away hopefully soon. And I don't think GUI programming is the first reason people come to D.
Re: Stroustrup on C++0x + JSF++ coding standard
pfff... I really don't know what to say about C++0x. Everyday I fall more in love with D. To know that I'll have to spend time learning all the new things in C++ just depresses me. Sure, there are some nice features, but I rather spend that time on improving my D and Python. Life is too short, and I don't want take the abuse from C++ anymore. Besides, how long are they going to continue to add crap to C++, or "improve" it, while retaining backward compatibility?
Re: GC for pure functions -- implementation ideas
Don Wrote: > Tomek Sowiñski wrote: > > I'm far from being a GC expert but I think Java having identified such > > cases with escape analysis just puts locally allocated objects on the stack. > > That works for the non-leaky function itself, but it doesn't help for > the functions it calls. It'd reduce the use of the pure heap to leaky pure functions called from pure functions. If I understood the original proposal correctly, this would reduce how frequently pure functions have to manipulate the pure stack. I haven't thought through the exception handling case, so I may be completely wrong! I was originally assuming the return type of a pure function was enough to determine if it wasn't leaky, but now I'm thinking only pure nothrow functions can be non-leaky. That might make the stack allocation optimization too rare to be worthwhile?
Re: too early for D2 and too late for D1
Andrej Mitrovic Wrote: > Gour, please disregard the troll above. > > If you're going with Python and Qt, I'd wholeheartedly recommend this > book: http://www.qtrac.eu/pyqtbook.html > Making GUIs with PyQT is dead simple. And Nokia already has that new > LGPL(I think?)-licensed binding in place - http://www.pyside.org. So > your decision might not be bad at all. > > What type of desktop app are you building? Does it need to be > very-high performance? Python itself isn't too bad with Qt, I don't > think it was slow in any way the last time I used it. W-T-F, why are you defending *other* languages? In every young language community the first users have to make sacrifices and build the ecosystem. That's how it goes. If we keep telling them Python is a better choice, nobody will implement the badly needed libraries.
Re: std.parallelism: Naming?
Dmitry Olshansky Wrote: > On 16.04.2011 22:39, dsimcha wrote: > > I'm reconsidering the naming of std.parallelism. The name is catchy, > > but perhaps too general. std.parallelism currently targets SMP > > parallelism. In the future it would be nice for Phobos to target SIMD > > parallelism and distributed message passing parallelism, too. These > > might belong in different modules. Then again, std.smp or > > std.multicore or something just doesn't sound as catchy. SIMD would > > probably just be array ops and stuff. Distributed message passing > > would probably be absorbed by std.concurrency since the distinction > > between concurrency and parallelism isn't as obvious at this level and > > std.concurrency is already the home of message passing stuff. Please > > comment. > > I'm inclined to go with std.parallelism, the name is so cute :). > On the serious side of it, I think SIMDs really belong to compiler > internals and std.intrinsics. > And any message passing should most likely go into std.concurency, even > though that lives some scenarios somewhat on the edge of two (parallelism). I'd vote for std.parallel.smp and std.parallel.simd. But Phobos does not support deep nested package names, which is good. Otherwise the naming would be a hell on earth just like Java or Tango.
Re: too early for D2 and too late for D1
Am 17.04.2011 20:18, schrieb Gary Whatmore: > Gour-Gadadhara Dasa Wrote: > > One thing, go hang yourself. We don't like loser talk from people who only > waste our time. Everyone agrees here D2 is the right tool for the job. Why > did you come here to rant about D? > > - G.W. Do you have a split personality or why do you write "we"?
Re: too early for D2 and too late for D1
Gour, please disregard the troll above. If you're going with Python and Qt, I'd wholeheartedly recommend this book: http://www.qtrac.eu/pyqtbook.html Making GUIs with PyQT is dead simple. And Nokia already has that new LGPL(I think?)-licensed binding in place - http://www.pyside.org. So your decision might not be bad at all. What type of desktop app are you building? Does it need to be very-high performance? Python itself isn't too bad with Qt, I don't think it was slow in any way the last time I used it.
Re: GC for pure functions -- implementation ideas
Don wrote: >>> The problem is, that inside a non-leaky pure function the general case >>> for dynamic >>> allocations might be just as complicated as in other parts of the program. > > Yes, but that only matters if that function is both extremely > memory-inefficient AND long-lived. In which case you can fall back to > the normal GC (or even a dedicated pure GC). I don't think you ever lose > anything. I think this idea has potential, I was only pointing out that maybe the compiler should identify such garbage creating functions and use the normal GC for them by default. It is not really a valid option to only restrict the size of the pure heap (or even just the amount it can grow per call frame) and then fall back to the normal GC, because a non-leaky pure function that behaves nicely may also need a lot of memory. Fawzi Mohamed wrote: > Having several pools is also what is needed to remove the global lock in > malloc, so that is definitely the way to go imho. I agree. I don't like the fact that at the GC suspends all running threads while collecting. But Hardware will probably be evolving towards Core-local RAM (several _physical_ pools) anyways.
Re: "Try it now"
new version of javascript up: http://arsdnet.net/d-web-site/std_algorithm2.html
Re: too early for D2 and too late for D1
Gour-Gadadhara Dasa Wrote: One thing, go hang yourself. We don't like loser talk from people who only waste our time. Everyone agrees here D2 is the right tool for the job. Why did you come here to rant about D? - G.W.
Re: "Try it now"
On Wed, Apr 13, 2011 at 07:37:08PM -0500, Andrei Alexandrescu wrote: > This is very close already! Two things if you get to work on this for > the weekend: Try it now: http://arsdnet.net/d-web-site/std_algorithm2.html Getting the console window to resize was a bit of a trick.. actually, the most painful part of the whole thing, by far! I think it's a hack too, to get around cross domain restrictions but it works for me.
Re: GC for pure functions -- implementation ideas
On 2011-04-17 05:22:10 -0400, Fawzi Mohamed said: All this comes back again to having several pools, showing how useful such a primitive is. Speaking of rethinking the GC and its primitives, is there a way currently to tell the GC to track pointers to a manually allocated block and assign a callback for when the GC wants that block to be finalized and deallocated? I'm kinda going to need that if I am to bring decent garbage-collected Objective-C objects in D. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: compile phobos into 64bit -- error!
On 4/17/11, Don wrote: > In this particular case, what's happened is that one of the largest > structural problems inside the compiler has been fixed. This fixed a > dozen of the nastiest bugs in Bugzilla.. That sounds delicious! :>
Re: Twitter hashtag for D?
On 04/16/11 22:41, Spacen Jasset wrote: So what do people currently use for C and C++ then? Not sure, but both #cpp and #cplusplus seem to be popular. As for D, I think we have settled down in #d_lang.
Re: GC for pure functions -- implementation ideas
Fawzi Mohamed wrote: On 16-apr-11, at 22:49, Timon Gehr wrote: [...] The problem is, that inside a non-leaky pure function the general case for dynamic allocations might be just as complicated as in other parts of the program. Yes, but that only matters if that function is both extremely memory-inefficient AND long-lived. In which case you can fall back to the normal GC (or even a dedicated pure GC). I don't think you ever lose anything. indeed, this is exactly what I wanted to write, yes in some cases, one can get away with simple stack like, or similar but it breaks down very quickly. In fact GC were introduced by functional languages, because they are kind of needed for them, already that should hint to the fact that functional, or pure languages are not intrinsically easier to collect. I find that *impossible* to believe. Note also that you are equating "functional" = "pure" in the D sense, which is not true. Firstly, functional languages generate *enormous* amounts of garbage. D does not. Secondly, non-leaky pure functions are rare in functional programming languages. I think we are in new territory here. What can be useful is allowing one to add a set of pools, that then can be freed all at once. Having several pools is also what is needed to remove the global lock in malloc, so that is definitely the way to go imho. Then one can give the control of these extra pools to the programmer, so that it is easy use a special pool for a part of the program and then release a lot of objects at once. Even then one should put quite some thought into it (for example about static/global objects that might be allocated for caching purposes). A strictly pure function returning a value without pointers gives guarantees, but as soon as some caching (even behind the scenes) goes on, then things will fail. If a separate pool is used consistently for cached or shared objects one should be able to allow even caching. All this comes back again to having several pools, showing how useful such a primitive is. Fawzi
"C Craft" notes
I am having some troubles with D newsgroups. Through Reddit I've found a kind of little online book, 13 HTML pages, about C and other languages: http://www-cs-students.stanford.edu/~blynn/c/index.html >Instead, I was enchanted by Eiffel, a language so clean that its sterile. I >became a rabid Eiffel zealot, even trying to prove its superiority in a >programming contest. Long time no C. Then during grad school, I ported one of >my pet projects from Eiffel to C. I forget why. Normally I'd mix C and Eiffel >to talk to the graphics library, but perhaps I had tired of writing glue code. >I slowly awoke from a dream, or more accurately, a mild nightmare. My C code >also worked, except it was faster. It was more concise, which in turn made it >easier to maintain. It was... better.< I think that using higher level languages has trained him to understand and use some abstractions. Later he's able to implement them in C too. The pages also link a short article about Fortran, that says: http://www.ibiblio.org/pub/languages/fortran/ch1-2.html >Fortran 90 allows explicit pointers restricted to point only to variables >declared with the "target" attribute, thus facilitating automatic >optimizations.< >Fortran disallows aliasing of arguments in procedure-call statements (CALL >statements and FUNCTION references), all passed argument lists must have >distinct entries. Fortran disallows also aliasing between COMMON (global) >variables and dummy arguments. These restrictions allows better compiler >optimizations.< The pages explain why Haskell lazy lists are a very good idea, useful and handy for many situations. I agree with the author, they are very different from D/Python lazy ranges. Some of the things the author desires in an improved C language (I have omitted several already present in D): >- Multiple return values: After writing the first version of a function, often >I want to have the function return more data, such as an error code or >diagnostic data. Im forced to add an extra pointer parameter, somehow encode >it into the return value, or define a one-off tuple struct. Multiple return >values would be much simpler. - Flexible array ranges: Arrays indexed from ranges other than [0..N-1] sometimes better fit the problem at hand, for example, an array of triangular numbers. The venerable "Numerical Recipes in C" advocates this hack: float b[4], *bb = b - 1; The elements of b can supposedly be referred to as bb[1] through bb[4]. Unfortunately, section 6.5.6 of the C99 standard appears to state the results are undefined, though it may work for many compilers. - Reflection: The previous wish is a form of reflection. Full reflection may be difficult to add to C, but I wonder how far one can go. - Overflow: I sometimes wish there were a way to detect overflow from basic arithmetic operations. - The conventions for symbol visibility should be reversed, that is, public exposure should be opt-in, not opt-out. Similarly for static versus extern functions. Bitwise AND and OR should have higher precedence.< Flexible array ranges: they introduce some extra complexity (when you read some code you can't just assume an array starts from zero, you have to take a look at the array type definition or declaration), but in some cases they simplify the code and maybe make it less bug-prone. You write: int['a' ... 'z'] arr; arr['f']++; Instead of something like: int[cast(int)'z' - 'a' + 1] arr; arr['f' - 'a']++; This feature seems less useful if you are using larger Unicode characters. Converting to D routines written in older 1-based languages is another usage, but probably not important enough. Module symbols visibility: in D with "private" you are to turn module names (gloabal alias, global variable, global function, global class, template, ecc) private when you import the module from another one. But indeed it's easy to forget to add "private" to things you don't want to get imported. Reversing the situation (and requiring "public" for the names you want to let other modules see) seems a safer default. -- The last page is about Go language, and it links to a document of comments about Go (November 2009, not up to date): http://www.math.bas.bg/bantchev/misc/on-go.html Some of the things this "on-go" article says about Go, that I partially like: > i++ is allowed, and ++i is not. Pike says 'the postfix version is more > traditional'. > Assignments of all kinds, including ++ and --, are statements, not > expressions. > There is no , (comma) operator. (The need for it has been to a great extent > obviated by multiple assignment, but still.) > Bitwise operator &^, 'bit clear': like & with a (bitwise) negated argument. > Bitwise negation itself is absent Bye, bearophile
Re: compile phobos into 64bit -- error!
David Wang wrote: Hi, all, I've download the latest dmd & druntime & phobos from gitHub.com; I copied them into a "32bit" folder and a "64bit" folder; I combined them separately into 32bit version and 64bit. 1). 32bit for dmd & druntime & phobos -- passed. 2). 64bit for dmd & druntime -- passed; but phobos -- failed. Please view the info as follows: A 'live' development checkout is not guaranteed to work. For one thing, development on Phobos and on the compiler is independent, and changes can be made simultaneously to both. To maximize your chances of getting a functional build, look at the D autotester before you download from github. http://d.puremagic.com/test-results/index.ghtml Additionally, any problems should be reported on the development mailing lists, not here. In this particular case, what's happened is that one of the largest structural problems inside the compiler has been fixed. This fixed a dozen of the nastiest bugs in Bugzilla, but also exposed some problems in Phobos and in the test suite. It'll probably be another day or so before everything is fully stable again.
too early for D2 and too late for D1
Hello! My first post to this newsgroup was a little bit more than 6 months ago and today I've decided to leave D and use C(P)ython + Qt for our open-source project of writing multi-platform desktop application. The D community is very nice and supportive, Walter, Andrei & co. are working hard, but, imho, D is not ready (yet). Recently, after switching from Linux to (Free)PC-BSD I even lost ability to have working compiler on x86_64 (none of the compilers is available in ports). The crucial thing is that D's ecosystem is simply not ready for day-to-day GUI programming and there is no clear roadmap so that one can anticipate when to expect that something will be done. Let me say, that I really like what D has on its plate, but language needs libraries to be successful, otherwise it is only promise-land. I've become tired for programming language's ecosystem to become mature...waited too long with Haskell and arrived to D hoping it is more pragmatic for day-to-day usage, but the situation seems even worse...Yeah, I know...I arrived at the wrong time during D1 --> D2 transition... That's, why I believe that the mantra in the subject, which I coined in IRC the other day, holds true. I'm thankful to all the members of this group for every piece of advice and input I received, as well to Andrei (his book is on my shelf - I even put it in the hardcover), but I want to code my project *today*, have plenty of (GUI) choices, lot of docs, tools and clear roadmap where the certain projects are going. I hope I might re-evaluate D2 sometime in the future for some other project... Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: GC for pure functions -- implementation ideas
On 16-apr-11, at 22:49, Timon Gehr wrote: [...] The problem is, that inside a non-leaky pure function the general case for dynamic allocations might be just as complicated as in other parts of the program. indeed, this is exactly what I wanted to write, yes in some cases, one can get away with simple stack like, or similar but it breaks down very quickly. In fact GC were introduced by functional languages, because they are kind of needed for them, already that should hint to the fact that functional, or pure languages are not intrinsically easier to collect. What can be useful is allowing one to add a set of pools, that then can be freed all at once. Having several pools is also what is needed to remove the global lock in malloc, so that is definitely the way to go imho. Then one can give the control of these extra pools to the programmer, so that it is easy use a special pool for a part of the program and then release a lot of objects at once. Even then one should put quite some thought into it (for example about static/global objects that might be allocated for caching purposes). A strictly pure function returning a value without pointers gives guarantees, but as soon as some caching (even behind the scenes) goes on, then things will fail. If a separate pool is used consistently for cached or shared objects one should be able to allow even caching. All this comes back again to having several pools, showing how useful such a primitive is. Fawzi
