Re: std.path review: second update
On Monday 01 August 2011 22:55:02 Jonathan M Davis wrote: On Tuesday 02 August 2011 05:41:11 Jesse Phillips wrote: On Mon, 01 Aug 2011 20:50:21 +, Jonathan M Davis wrote: st my pragmatic, Windows-sentric view of things :) The problem with that is that then you _can't_ have something like foo..bar. Granted, that's not a normal thing to do, but it would be problematic if it ever happened. You can, you just wouldn't build it with these functions. And frankly if you are using these then you probably wouldn't want foo..bar and wouldn't care that it ended up foo.bar or foo..bar. You just want the proper extension on the proper name, which is what you'd get. The primary danger I see with using null for no extension and empty for . is assert(extension(file.) == extension(file)); That could cause problems for any program that actually runs into a file which ends with a .. Now, if Linux, Windows, and Mac OS X all prevent files ending in a dot (which I seriously doubt), then it isn't really an issue. Having the difference between null and empty does make it possible to distinguish if you start doing stuff like I disagree, that assertion should pass. They both have the same extension. If you really want to know if a file name ends in a dot, assert(file.[$-1] == .); I just don't see a case where you'd be dealing with these too files and care to know the extension is explicitly empty or umm just empty. The main issue that I see is that it becomes too easy to have a program think that the names of two files are identical if you're dealing with their pieces instead of their whole. Granted, this is not exactly a normal situation, but I'd much prefer to have it handled cleanly so that programs that get into such a situation don't end up being buggy rather than declaring that two items which aren't identical as being equal. Actually, I suppose that I could sum up my take on it by saying that if the two aren't absolutely identical, they shouldn't be treated as equal. file. and file do _not_ have the same extension. One has an empty extension whereas the other has none. Most stuff won't care about the difference, in which case it probably won't care whether extension(file.) == extension(file) or not (in fact, all it probably care about is whether the extension is a particular extension or not). But stuff which _does_ care about the difference _will_ care whether extension(file.) == extension(file). It _won't_ want them to be equal. In general, I don't like the idea of null and empty being conflated - they're two separate things. It's bad enough that arrays act that way in D. There's no need to propagate it to file extensions as well. - Jonathan M Davis
Re: What library functionality would you most like to see in D?
Am 02.08.2011, 04:48 Uhr, schrieb Adam D. Ruppe destructiona...@gmail.com: I've been thinking about a minimalist drawing library for phobos - just basic 2d stuff, but with easy enough hooks to add more (native api events and handles. Nobody is likely to agree on a widget set, but basic drawing functions give a little usability with pretty small cost. I had a decent start a month or two ago but have since stalled out as my schedule became more ridiculous. I used a few drawing APIs: Delphi/Win32, Java2D, HTML5 Canvas, Gtk+ and recently Cairo. If there was a drawing API in Phobos I wish it was like Cairo. While some basic APIs have some special ability (like shadows in the HTML canvas) they often lack some essential functions. Java2D offers a lot, but I consider it bloated, YMMW. When I was writing a tool I came to need more and more advanced features: - fonts and text drawing - clipping - scaling (part of matrix manipulation) - transparency - measuring of the extents of what is about to be drawn I was using GtkD, the D wrapper for Gtk and Gtk lacked a lot of this. Fortunately Gtk comes with Cairo bindings which offered all that. This is just one example and just me, but I really think Cairo's API is very well designed, similar to Java2D and HTML5 Canvas and would be my reference for a drawing API in D. It doesn't need to offer bezier curves and anti-aliasing in the first version, but the idea of filling and stroking shapes or drawing surfaces that can be rendered into each other are kind of a standard now that can be built upon :) - Marco
Re: std.path review: second update
Am 01.08.2011, 22:50 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
The problem with that is that then you _can't_ have something like
foo..bar.
I used to have a library of sound files when I was young. Some of them
were spoken sentences and I named the files according to what was said.
While I couldn't use a question mark I did use ! and .
If I was torturing someone, he wouldn't be allowed to sit..wav
With Explorer hiding the known extension it looked fine. The .NET way is
fine for the general case, but I learnt that a file only has an extension
when the file name doesn't end with the dot. So I'd expect the semantics
to be
setExtension('I am a file name', 'bar') == 'I am a file name.bar'
setExtension('I am a file name.', 'bar') == 'I am a file name..bar'
setExtension('I am a file name', '.bar') == 'I am a file name.bar'
setExtension('I am a file name.', '.bar') == 'I am a file name..bar'
Re: dmd installer clobbers PATH on Windows (sometimes)
On Mon, Aug 1, 2011 at 6:35 PM, Vladimir Panteleev vladi...@thecybershadow.net wrote: On Mon, 01 Aug 2011 20:58:08 +0300, Brad Anderson e...@gnuk.net wrote: there is no way (that I know of) to look at what your PATH was before it was destroyed and the PATH is often updated by installers (as it is with dmd). If you haven't rebooted your machine yet - Windows stores a backup copy of the system registry hives for the last known good configuration boot feature. These copies are stored in C:\Windows\Repair (XP and before) or C:\Windows\System32\config\**RegBack (Vista and after). You will not be able to access these files directly, though - you'll need to use a tool or risk a poweroff and boot from another OS. Once you have a readable copy, you can mount the hives to an empty key in your registry with RegEdit. PATH is located at HKEY_LOCAL_MACHINE\SYSTEM\**CurrentControlSet\Control\**Session Manager\Environment (though you won't see CurrentControlSet in the mounted hive, it's a symbolic link of sorts to one of the ControlSetXXX keys). -- Best regards, Vladimir mailto:vladimir@**thecybershadow.netvladi...@thecybershadow.net I'll try this. Thanks for the tip. Regards Brad Anderson
Re: What library functionality would you most like to see in D?
On 2011-08-01 21:03, Jim Hewes wrote: I didn't mean to criticize the D compiler installation, which seems to install pretty well on Windows. That is, after you install it you're ready to go without additional setup or needing to install other things. I was referring more to the peripheral projects and also just to open source in general. Ok. If DWT is the standard GUI in the same sense that MFC is for Microsoft C++, then I thought it would be nice if it were included in the installer for the D compiler. It could be an optional feature during installation. But if you do choose to install it, then right after installation you should immediately be able to build included sample GUI code projects. There is no standard GUI for D. Well, actually, as I think it says on the wiki is that DWT is the standard GUI library, but that's referring to an older, windows only, version of DWT. DWT works with D2 (Phobos) as well. It's statically linked so the hello world application gets quite large. But that's because it pulls in a lot of the library, meaning even if you start using other parts of the library it won't increase the size of the executable at the same rate. Yeah, the main GUI library page on the wiki says that it works with Phobos, but the Windows installation guide says to download Tango. So I wasn't sure it was really updated to support Phobos. Thanks, I will try to check it out next weekend. Jim I guess the DWT project page could use some updating. -- /Jacob Carlborg
Re: What library functionality would you most like to see in D?
On 2011-08-01 23:35, Nick Sabalausky wrote: Johann MacDonaghjohann.macdonagh...@spam.gmail.com wrote in message news:j1501g$tbs$1...@digitalmars.com... 1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework. Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff 2. DWT fixed up and merged into Phobos. That'd certainly be nice. That would be an enormous addition (in code) to Phobos. I would guess that the code base of DWT, for just one platform, is larger than the whole Phobos. -- /Jacob Carlborg
Re: Still cannot build Phobos from git
On 2011-08-02 00:29, Nick Sabalausky wrote: My instinctual reaction to pop-ins (I **HATE**, **HATE**, **HATE** pop-ins - they're even *worse* than pop-ups) is to curse, disable JS, and reload. The resulting page, allegedly, shows all downloads, but the non-tag ones are missing from it. Just as you, I'm not a big fan of JS. But I learn what pages that I use that need JS to work properly and enable it for them. Of course, in this case, I did actually read what was on the pop-in before going all Nick on it, but it wasn't remotely clear to me that Download source, Download .tar.gz or Download .zip really meant current head (actually, I didn't even suspect that it might have meant that - I didn't know what the hell they were referring to and I didn't want to assume.) Ok, I see. -- /Jacob Carlborg
Re: std.path review: second update
Am 02.08.2011, 08:02 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
file. and file do _not_ have the same extension. One has an empty
extension whereas the other has none.
Still I would expect a get extension function to return the empty string
for both. Why is that so? As Wikipedia states the interpretation depends
on the filesystem (or maybe on the originating OS, but you can use ext3 on
Windows and NTFS on Linux nowadays).
But others seem to have problems as well:
Trailing dots disappear in Samba:
http://lists.samba.org/archive/rsync/2002-September/003636.html
On Windows files ending in a dot cannot be deleted:
http://cygwin.com/ml/cygwin/2004-01/msg00848.html
http://blog.dotsmart.net/2008/06/12/solved-cannot-read-from-the-source-file-or-disk/
Mozilla Linux cannot open files ending in a dot:
https://bugzilla.mozilla.org/show_bug.cgi?id=149586
The file extension is what is following the last dot.
On Windows it cannot be empty, thus 'foo.' will be an inaccessible file.
Yet 'foo..bar' is perfectly fine, which is causing us trouble now, since
'foo.' is 'foo..bar' stripped from its extension, but 'foo.' itself -
while valid on Posix - is an ambiguous name in Windows.
Camp A thinks:
- it has no extension as long as the dot isn't followed by one
- changing the extension must result in 'foo..ext'
- getExtension should never return null, but be either '' or include the
dot as in '.ext'
- disassembling and reassembling a filename by string concatenation should
return the original filename in all cases
Camp B thinks:
- no dot = no extension, otherwise what follows the dot is the extension
- changing the extension must result in 'foo.ext'
- getExtension returns null if no dot is found, an empty string if the
file ends in a dot or otherwise what is following the dot
- disassembling and reassembling a filename isn't a portable process
I started at camp A, but now I'm really caught in the middle. Their
arguments make as much sense.
Funny enough even Sun avoided file extension methods in their Java File
class, so I checked Python for that matter:
os.path.splitext ( foo.bar ) - '.bar'
os.path.splitext ( foo. ) - '.'
os.path.splitext ( foo ) - ''
Although there is no routine to change the extension, the obvious approach
would result in changeExt('foo.', '.bar') == 'foo.bar'.
This is what Jonathan prefers and I agree with this solution now that I
made up my mind. It's just inconvenient that by this convention you cannot
change the extension of 'Keep my dot.' in a way that the result is 'Keep
my dot..ext'.
Re: std.path review: second update
On Tuesday 02 August 2011 10:19:54 Marco Leise wrote:
Am 02.08.2011, 08:02 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
file. and file do _not_ have the same extension. One has an empty
extension whereas the other has none.
Still I would expect a get extension function to return the empty string
for both. Why is that so? As Wikipedia states the interpretation depends
on the filesystem (or maybe on the originating OS, but you can use ext3 on
Windows and NTFS on Linux nowadays).
But others seem to have problems as well:
Trailing dots disappear in Samba:
http://lists.samba.org/archive/rsync/2002-September/003636.html
On Windows files ending in a dot cannot be deleted:
http://cygwin.com/ml/cygwin/2004-01/msg00848.html
http://blog.dotsmart.net/2008/06/12/solved-cannot-read-from-the-source-file-
or-disk/
Mozilla Linux cannot open files ending in a dot:
https://bugzilla.mozilla.org/show_bug.cgi?id=149586
The file extension is what is following the last dot.
On Windows it cannot be empty, thus 'foo.' will be an inaccessible file.
Yet 'foo..bar' is perfectly fine, which is causing us trouble now, since
'foo.' is 'foo..bar' stripped from its extension, but 'foo.' itself -
while valid on Posix - is an ambiguous name in Windows.
Camp A thinks:
- it has no extension as long as the dot isn't followed by one
- changing the extension must result in 'foo..ext'
- getExtension should never return null, but be either '' or include the
dot as in '.ext'
- disassembling and reassembling a filename by string concatenation should
return the original filename in all cases
Camp B thinks:
- no dot = no extension, otherwise what follows the dot is the extension
- changing the extension must result in 'foo.ext'
- getExtension returns null if no dot is found, an empty string if the
file ends in a dot or otherwise what is following the dot
- disassembling and reassembling a filename isn't a portable process
I started at camp A, but now I'm really caught in the middle. Their
arguments make as much sense.
Funny enough even Sun avoided file extension methods in their Java File
class, so I checked Python for that matter:
os.path.splitext ( foo.bar ) - '.bar'
os.path.splitext ( foo. ) - '.'
os.path.splitext ( foo ) - ''
Although there is no routine to change the extension, the obvious approach
would result in changeExt('foo.', '.bar') == 'foo.bar'.
This is what Jonathan prefers and I agree with this solution now that I
made up my mind. It's just inconvenient that by this convention you cannot
change the extension of 'Keep my dot.' in a way that the result is 'Keep
my dot..ext'.
Except that that's two extensions, which shouldn't pose a problem.
Actually, that raises the argument that we should have an addExtension
function. After all, files such as file.tar.gz are quite common (on Linux at
least), and std.path should be able to handle files with multiple extensions.
IIRC, on the whole both the old std.path and the new std.path handle multiple
extensions fairly well, but I don't think that either the old std.path or the
new std.path has a function which handles the case where you want to add an
extension to a file regardless of whether it already has an extension.
- Jonathan M Davis
Re: std.path review: second update
People with herpes are not alone now! Because you have herpesanddating.net It helps people with herpes in all aspects.
Re: Still cannot build Phobos from git
On 2011-08-02 00:55, Walter Bright wrote: On 7/27/2011 1:34 PM, bearophile wrote: Dmitry Olshansky: My recipe on Windows: I presume it has tens of quite different kinds of ways to fail :-) This is what I see: You need to use Digital Mars make, the one that comes with dmd: http://www.digitalmars.com/ctg/make.html Now why doesn't the Digital Mars make come with dmd? -- /Jacob Carlborg
Re: What library functionality would you most like to see in D?
On 2011-08-02 00:34, Andrei Alexandrescu wrote: On 8/1/11 4:35 PM, Nick Sabalausky wrote: Johann MacDonaghjohann.macdonagh...@spam.gmail.com wrote in message news:j1501g$tbs$1...@digitalmars.com... 1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework. Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff 2. DWT fixed up and merged into Phobos. That'd certainly be nice. Interesting. What platforms does DWT work on? What is the general community opinion on integrating it within Phobos? Is there anyone willing to take on this task? Thanks, Andrei Windows and Linux (GTK) 32bit. I'm in the middle of porting the Mac OS X version. These are the platforms that SWT supports: Windows 32/64bit Windows CE Linux 32/64bit and PPC64 Solaris 10 x86 and Sparc HPUX IA64_32 AIX PPC/64 Mac OS X 32/64bit Graphics systems used: Windows - win32 Posix - GTK2 Mac OS X - Cocoa I would be willing to take on this task, but it's not a priority I have right now. If anyone else wants to do it I have no problems with that. It would probably be best if at least three people did the integration, ,one for windows, one for linux and one for osx, and work close together for any non-platform specific code. I'm using Mac OS X as my main system. BTW, the Mac OS X specific code could really benefit from Michel Fortin's Objective-C fork of DMD. -- /Jacob Carlborg
Re: DWT in Phobos? was [Re: What library functionality would you most like to see in D?]
On 2011-08-02 01:48, Jesse Phillips wrote: Andrei Alexandrescu Wrote: On 8/1/11 4:35 PM, Nick Sabalausky wrote: Johann MacDonaghjohann.macdonagh...@spam.gmail.com wrote in message 2. DWT fixed up and merged into Phobos. That'd certainly be nice. Interesting. What platforms does DWT work on? What is the general community opinion on integrating it within Phobos? Is there anyone willing to take on this task? Thanks, Andrei I think DWT for D2 worked with Windows and Linux (tested on). The port is very Java style, it doesn't have a D layer to make it work nicely with ranges (err last time I used it 3 yrs ago). All the packages are org.eclipse... The library itself is huge and the port isn't complete. How would the ranges be used in a GUI library? It probably isn't a good idea to bring it into Phobos since it needs to be easy to keep up with SWT development. However it might be reasonable to take DWT, mold it into a D like library and continue development separate from SWT. I don't know if that is easier than developing a D2 GUI library from scratch, but having such a library in Phobos is probably a *great* idea. -- /Jacob Carlborg
Re: Still cannot build Phobos from git
On 02.08.2011 12:46, Jacob Carlborg wrote: On 2011-08-02 00:55, Walter Bright wrote: On 7/27/2011 1:34 PM, bearophile wrote: Dmitry Olshansky: My recipe on Windows: I presume it has tens of quite different kinds of ways to fail :-) This is what I see: You need to use Digital Mars make, the one that comes with dmd: http://www.digitalmars.com/ctg/make.html Now why doesn't the Digital Mars make come with dmd? It does on Windows. -- Dmitry Olshansky
Re: What library functionality would you most like to see in D?
On 02-08-2011 01:51, Piotr Szturmaj wrote: Jonathan M Davis wrote: I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis 1. Cryptography (I already wrote all SHA hash implementations and HMAC, they will be open sourced under Boost license, I'm also working on Rijndael/AES impl.) some of the proposed namespaces (just thinking loud): std.crypto.cipher - block and stream ciphers std.crypto.hash - message digests (SHA1, RIPEMD, ...) std.crypto.mac - message auth codes like HMAC, CMAC, UMAC std.crypto.mode - block cipher modes like CBC, GCM, ... std.crypto.padding - padding schemes std.crypto.pki - asymmetric cryptography (RSA), PKI std.crypto.x509 - certificate support Sounds good to me! - Alex
Re: What does C++ do better than D? - StackOverflow.com
Am 02.08.2011, 01:51 Uhr, schrieb Walter Bright
newshou...@digitalmars.com:
I've talked to many people who use logical const extensively in C++, and
really want it. If you dig down into what's happening, you'll find that
logical const isn't actually supported by C++. It's a convention.
There's simply nothing in the language that enforces that convention.
The reason logical const does not work with const in D is because D
actually enforces const semantics, and relies on that enforcement.
Since logical const is a convention in C++ anyway, you can have logical
const in D, too. Just put in a comment:
struct S /* This struct is logical const */
{ ... }
and then follow the convention just as you would with C++.
Const in C++ is not powerful - it's simply a fraud - and the two get
confused.
I can understand the point of view of the compiler developer and I don't
question that D const has advantages. It is definitly good to have
transitive const in some use cases. Until today I didn't even know about
logical const. But the more I think about it and its applications it looks
like a valuable feature.
I'm a typical OOP programmer and I generally avoid pointers where possible
and use encapsulation - that is - mark methods and data fields private.
But there are these strong cases where you cannot afford to have the usual
transitive const. Instead you really want a high-level logical const. One
that makes no sense to the compiler and is a 'fraud'. That is in OOP you
give away a const reference to some object, meaning that the outside world
cannot modify it logically. The encapsulated inner state though should not
be affected by this.
The example with the Matrix class is an excellent example. Here the
programmer wants to make sure that the owner of the Matrix can safely give
away that Matrix object without having to worry that the logical state
changes, i.e. the mathematical representation changes. This is the
'caching' use case.
Another one I've found is object composition:
http://en.wikipedia.org/wiki/Object_composition#UML_notation
The motor in your car: If the car is a const reference the motor has to be
protected by that as well (composition).
But if I call car.getVendor() I expect the mutable instance of the vendor
object to call car.getVendor().buy(car.getModel(), 10) for my company's
car pool.
On this higher level C++ gives the form of logical protection for the
'caching' case that I need as an OO programmer.
- Marco
Re: What does C++ do better than D? - StackOverflow.com
== Quote from Marco Leise (marco.le...@gmx.de)'s article
Am 02.08.2011, 01:51 Uhr, schrieb Walter Bright
newshou...@digitalmars.com:
I've talked to many people who use logical const extensively in C++, and
really want it. If you dig down into what's happening, you'll find that
logical const isn't actually supported by C++. It's a convention.
There's simply nothing in the language that enforces that convention.
The reason logical const does not work with const in D is because D
actually enforces const semantics, and relies on that enforcement.
Since logical const is a convention in C++ anyway, you can have logical
const in D, too. Just put in a comment:
struct S /* This struct is logical const */
{ ... }
and then follow the convention just as you would with C++.
Const in C++ is not powerful - it's simply a fraud - and the two get
confused.
I can understand the point of view of the compiler developer and I don't
question that D const has advantages. It is definitly good to have
transitive const in some use cases. Until today I didn't even know about
logical const. But the more I think about it and its applications it looks
like a valuable feature.
I'm a typical OOP programmer and I generally avoid pointers where possible
and use encapsulation - that is - mark methods and data fields private.
But there are these strong cases where you cannot afford to have the usual
transitive const. Instead you really want a high-level logical const. One
that makes no sense to the compiler and is a 'fraud'. That is in OOP you
give away a const reference to some object, meaning that the outside world
cannot modify it logically. The encapsulated inner state though should not
be affected by this.
The example with the Matrix class is an excellent example. Here the
programmer wants to make sure that the owner of the Matrix can safely give
away that Matrix object without having to worry that the logical state
changes, i.e. the mathematical representation changes. This is the
'caching' use case.
Another one I've found is object composition:
http://en.wikipedia.org/wiki/Object_composition#UML_notation
The motor in your car: If the car is a const reference the motor has to be
protected by that as well (composition).
But if I call car.getVendor() I expect the mutable instance of the vendor
object to call car.getVendor().buy(car.getModel(), 10) for my company's
car pool.
On this higher level C++ gives the form of logical protection for the
'caching' case that I need as an OO programmer.
- Marco
The problem as I see it is that D has two separate concepts that are conflated:
const and immutable. In fact, I'd argue that immutable shouldn't even exist in
its
current standalone state but should rather be part of an ownership system a-la
Bartosz' suggested annotation system.
In the context of single threaded programs const mustn't be transitive.
E.g.
class Foo { int a; ... }
class Bar { Foo foo; ...}
void func(const Bar b);
void gunc(immutable Bar b);
func should be able to change b.foo.a but not b.foo (foo is head-const or
final)
gunc however will enforce transitivity and will not allow to change b.foo.a
In the context of multi-threaded programs, casting const(T) to an immutable(T)
would require locking/synchronization in order to preserve correctness.
To conclude, Instead of D's current model where both T and immutable(T) can be
up-casted to const(T) I'm suggesting
T - const(T) -(locked)- immutable(T)
In addition, compile-time manifest consts via enum should be removed in favor
of
immutable.
Re: pi benchmark on ldc and dmd
The post says they did dmd -O. They did not mention -inline -noboundscheck -release. There may be extra flags that are required. Walter Bright Wrote: http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98 Anyone care to examine the assembler output and figure out why?
Re: What library functionality would you most like to see in D?
On 8/2/11, Marco Leise marco.le...@gmx.de wrote: Am 02.08.2011, 04:48 Uhr, schrieb Adam D. Ruppe destructiona...@gmail.com: I've been thinking about a minimalist drawing library for phobos - just basic 2d stuff, but with easy enough hooks to add more (native api events and handles. Nobody is likely to agree on a widget set, but basic drawing functions give a little usability with pretty small cost. I had a decent start a month or two ago but have since stalled out as my schedule became more ridiculous. I used a few drawing APIs: Delphi/Win32, Java2D, HTML5 Canvas, Gtk+ and recently Cairo. If there was a drawing API in Phobos I wish it was like Cairo. While some basic APIs have some special ability (like shadows in the HTML canvas) they often lack some essential functions. Java2D offers a lot, but I consider it bloated, YMMW. When I was writing a tool I came to need more and more advanced features: - fonts and text drawing - clipping - scaling (part of matrix manipulation) - transparency - measuring of the extents of what is about to be drawn I was using GtkD, the D wrapper for Gtk and Gtk lacked a lot of this. Fortunately Gtk comes with Cairo bindings which offered all that. This is just one example and just me, but I really think Cairo's API is very well designed, similar to Java2D and HTML5 Canvas and would be my reference for a drawing API in D. It doesn't need to offer bezier curves and anti-aliasing in the first version, but the idea of filling and stroking shapes or drawing surfaces that can be rendered into each other are kind of a standard now that can be built upon :) - Marco Johannes Pfau is working on a D2 wrapper for Cairo: https://github.com/jpf91/cairoD Unlike gtkD the bindings are Boost licensed, so I think one could make a small trivial windowing library with Cairo drawing and put that into Phobos. Of course the user would have to install either Gtk itself or the Cairo DLLs from the Gtk website before they can use the code.
Re: Still cannot build Phobos from git
I think DM make is only used on Windows, and GNU make is used on Linux. Just compare the win32 makefile to the Posix makefile, it's a world of a difference.
Re: What does C++ do better than D? - StackOverflow.com
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article On 8/1/11 7:56 PM, Brad Roberts wrote: On Mon, 1 Aug 2011, Peter Alexander wrote: On 1/08/11 7:29 PM, Kagamin wrote: Walter Bright Wrote: Now on reddit! http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_t han_d/ C++ has a better thought out type system. Nice joke. http://blog.llvm.org/2011/05/c-at-google-here-be-dragons.html Please read my note at the end. I believe D (probably) has a better type system. It just wasn't very well though out. I believe many aspects of D's type system were added in without fully exploring the ramifications they had on other parts of the language. There are at least two pieces of evidence which support my belief: 1. The fact that you can't copy const struct objects containing reference types. 2. The fact that the root object still isn't const correct. C++ has some questionable choices for its type system, but it generally doesn't prevent you from getting work done. You're mixing state of implementation with design of the type system. Easy enough to conflate, but still a conflation of issues. Don't get me wrong, that there's QOI issues still is a real problem. I'd also agree that it's in the top 10 list of real problems. I don't know that I'd make it #1 on the list, though. Please don't ask me what my #1 issue is, it varies from week to week. :) Until the QOI issues are worked out, or at least reduced significantly, it's not clear that we'll be able to make any strong statements about the quality of the design. Later, Brad Good point, particularly when you compare it with the QOI issues in C++ as it was maturing. And the design, too. There were times when e.g. nobody knew when an object ought to be destroyed. Andrei Here's the thing: Unless you're developing a D compiler, there's no difference between a QoI issue and a language design issue. An issue is an issue, whether the fix is to change the design or to change the compiler. In my opinion, there's very little point in discussing a language's merit without discussing the tools. A design without an implementation has no worth. As Steve Yegge likes to say, a language's popularity is all about the tools. What's more constructive? Judging a language based on the Digital Mars Hypothetical Future D compiler, or based on DMD, GDC and LDC? What's the point of saying that a language has no flaws, but there are no implementations of that language?
Re: What does C++ do better than D? - StackOverflow.com
Peter Alexander: What's the point of saying that a language has no flaws, but there are no implementations of that language? The task of inventing a flawless language is much more difficult than actually implementing it (but the latter may take more time), so I think there is a point. -Timon
Re: pi benchmark on ldc and dmd
Am 02.08.2011, 05:38 Uhr, schrieb Adam D. Ruppe destructiona...@gmail.com: I was waiting over an hour just for gcc+gdc to compile! In the time it takes for gcc's configure script to run, you can make clean, build dmd, druntime and phobos. Make sure you disable bootstrapping. Compiling gdc works pleasantly fast for me. Try compiling it on Windows, that's what I call slow.
Re: std.path review: second update
On 08/02/2011 01:02 AM, Jonathan M Davis wrote: Actually, I suppose that I could sum up my take on it by saying that if the two aren't absolutely identical, they shouldn't be treated as equal. file. and file do _not_ have the same extension. One has an empty extension whereas the other has none. I agree. A simple solution is to make the dot part of the extension. So extension(file.) returns . and extension(file) returns the empty string (be it null or not). Problem solved. One nice side effect is that concatenating the base and the extension gives back the name. Andrei
Re: What does C++ do better than D? - StackOverflow.com
On 08/02/2011 07:26 AM, Peter Alexander wrote: Here's the thing: Unless you're developing a D compiler, there's no difference between a QoI issue and a language design issue. An issue is an issue, whether the fix is to change the design or to change the compiler. In my opinion, there's very little point in discussing a language's merit without discussing the tools. A design without an implementation has no worth. As Steve Yegge likes to say, a language's popularity is all about the tools. Fair point. It's just good to to use the right terminology. Otherwise if you say bad design that's forever. Insufficient implementation is transitory. What's more constructive? Judging a language based on the Digital Mars Hypothetical Future D compiler, or based on DMD, GDC and LDC? What's the point of saying that a language has no flaws, but there are no implementations of that language? Probably the worse mistake is saying that the language has a flaw because its implementation has one. Andrei
Re: std.path review: second update
On Tue, Aug 2, 2011 at 8:57 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 08/02/2011 01:02 AM, Jonathan M Davis wrote:
Actually, I suppose that I could sum up my take on it by saying that if
the
two aren't absolutely identical, they shouldn't be treated as equal.
file. and file do _not_ have the same extension. One has an empty
extension
whereas the other has none.
I agree. A simple solution is to make the dot part of the extension. So
extension(file.) returns . and extension(file) returns the empty
string (be it null or not). Problem solved.
One nice side effect is that concatenating the base and the extension gives
back the name.
For what it is worth. This also matches how std.log deals with
extensions. Well, std.log leaves it up to the user to include the
period ('.').
/++
Specifies the extension for the name of log files.
The default value is $(D .log).
+/
@property string fileNameExtension(string extension)
{
return _fileNameExtension = extension;
}
Wider tuple design discussion
Walter has asked for a more global vision on tuples before implementing their unpacking, so need to show the discussion here again: http://d.puremagic.com/issues/show_bug.cgi?id=6365#c26 Walter: My main reservation about this is not that I can see anything obviously wrong about it, but I am nervous we are building a special case for tuples. I think any expansion of tuple support should be part of a more comprehensive design for tuples. If we grow tuple support by adding piecemeal special cases for this and that, without thinking about them more globally, we are liable to build ourselves into a box we can't get out of. I can give examples in other languages that did this - the most infamous being the great C idea of conflating arrays and pointers. It seems to be a great idea in the small, but only much larger experience showed what a disastrous mistake it was. We should step back and figure out what we want to do with tuples in the much more general case. More stuff I've written: http://d.puremagic.com/issues/show_bug.cgi?id=6367 http://d.puremagic.com/issues/show_bug.cgi?id=6383 A global design for tuples in D was right what I have tried to avoid, because I have thought that Andrei was against a full tuple built-in design and that generally there was not so much desire for large changes in D2 now. With that syntax sugar suggestion I have tried to find the simpler and more essential D change that allows me to use tuples in a more handy way. Now I'm back to the start. And I still fear that a better and more comprehensive tuple design will be refused in D. So I fear there is no way out: if you design a minimal change Walter fears of corner cases and myopic design, and if you design a comprehensive tuple, it risks being a too much big change for this stage of D evolution. In both cases the end result is of not having good enough tuples in D. In the end Walter is right. Better to not have built-in support for tuples than having some wrongly designed built-in syntax sugar for tuples. So let's think about the only viable alternative, a wider design, and hope. When you design something you need first of all to think about what your tool will be used for. Tuples are used all the time in functional-style languages, usually once every line of code or so. In Python and Haskell I use them all the time. In D I already use tuples, but they are not so handy. Tuples are not essential in D. You are able to write large programs without tuples. But they are sometimes handy, especially if you use a more functional-style programming. Tuples do have some disadvantages. Their fields often are anonymous, this goes against the typical well defined style of D/Java/Ada programs, where you know the name of what you are using. So tuples are better if you use them locally, or if they have only few items. Long tuples become hard to use because you risk forgetting what each field is, so the most common tuples have between 2 and 5 items. In Python you are also allowed to define a tuple with zero items, and a tuple with one item, but in my experience they are not so useful (in Python you sometimes use longer tuples made of items of the same type, because you are using them essentially as immutable arrays. This is considered not pythonic). D tuples allow a name for the fields, this is useful at usage point, because instead of a [2] you use (example) .isOpen, that's more descriptive. A tuple isn't an object, it's more like a record, it's almost like a more handy POD. So tuples are data structures that you use with code (functions) that they don't contain. OOP design is against this. But I am not fond of pure OO design. There are many situations where you want something more handy, more functional style, or more in abstract data structure-style. Python, D, Scala and other languages recognize this. In some languages (like Python) tuples are immutable, while in D they are the opposite, you currently can't give them immutable fields. In D tuples are values, while in Python they are used by kind of reference (by name). In functional languages you can't how they managed, because there is referential transparency (so even if there is a reference, it's invisible. So the compiler is free to implement them as it wants, and optimize as much as it can). In some languages tuples are managed with a nominal type system, while in most other situations they are managed by a structural type system (that means that two tuples are seen of different type only if the types of their fields differ). (Time ago I have even suggested a @structural attribute to be used in the Phobos code that defines D tuples). There are many operations you want to perform on tuples, the most basic ones are: 0) define the type of a tuple 1) create a tuple 2) copy a tuple 3) Read a tuple field 4) Write a tuple field 5) Unpack tuple fields into variables, this is useful in 3 or more different situations: 5.1)
Re: Wider tuple design discussion
On 2011-08-02 13:15:52 +, bearophile bearophileh...@lycos.com said: A tuple isn't an object, it's more like a record, it's almost like a more handy POD. So tuples are data structures that you use with code (functions) that they don't contain. Actually, that's up to debate in my opinion. Andrei's Tuple in phobos is a struct, so it's a POD like you say. Walter's tuples in the language are just collections of variables. A language tuple does not have an address in itself, it essentially has one address per field. This actually makes tuple packing/unpacking very efficient across function calls (because there's no real packing/unpacking taking place), but it makes it impossible to take the address of a tuple. We need a way to make those two concepts work together, I think that's the hard part. Tuples do have some disadvantages. Their fields often are anonymous, this goes against the typical well defined style of D/Java/Ada programs, where you know the name of what you are using. So tuples are better if you use them locally, or if they have only few items. Long tuples become hard to use because you risk forgetting what each field is, so the most common tuples have between 2 and 5 items. Named tuple elements in a language tuple will be implemented when/if someone implement named arguments, something I might do eventually. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: What does C++ do better than D? - StackOverflow.com
On 08/01/2011 09:29 PM, Andrei Alexandrescu wrote: I know how to fix the design (in fact the implementation, the design is sound). It's just ever so difficult to find the time to prioritize for it. This sounds familiar to I have discovered a truly remarkable proof which this margin is too small to contain.
Re: What should be reterned by std.array.replaceFirst
On Sat, 30 Jul 2011 07:29:54 +0800, zhang wrote: I tested std.array.replaceFirst with the code belown: string s1 = abc bcf; string s2 = s1.replaceFirst(bc, ee); writefln(%s\n%s, s1, s2); and got s2 is aee. Should it be aee bcf? Is it a bug, or just it is that? Thanks. -- Zhang bitwo...@qq.com I'd say, bug file it. http://d.puremagic.com/issues/ Has filed a bug and offerd a patch, see here http://d.puremagic.com/issues/show_bug.cgi?id=6428 -- Zhang bitwo...@qq.com
Re: pi benchmark on ldc and dmd
LDC builds in under a half hour, even on my underpowered ARM SoC, so I don't see how you could be having trouble there. Building dmd from the zip took 37 *seconds* for me just now, after running a make clean (this is on Linux). gdc and ldc have their advantages, but they have disadvantages too. I think the people saying abandon dmd don't know the other side of the story. Basically, I think the more compilers we have for D the better. gdc is good. ldc is good. And so is dmd. We shouldn't abandon any of them.
Re: Wider tuple design discussion
On Tue, 02 Aug 2011 15:15:52 +0200, bearophile bearophileh...@lycos.com
wrote:
5.1) The most basic one is unpacking a tuple locally, inside a function.
5.2) Another common situation is unpacking a small tuple inside a
foreach statement, when you iterate on a collection of tuples.
I would argue these two are the most important ones.
5.3) Another usage (quite common in Haskell and similar languages) is to
unpack a tuple in the signature of a function. Haskell even allows to
give names at the same time to both fields and to the whole tuple.
This is less important, I think.
Other operations are:
6) Slice a tuple like a Python/D array: tup[1..3]. (This is already
supported in D, but you can't use the normal slice syntax, you need to
use tup.slice!(1, 3) ).
7) Concat two or more tuples (using ~ and ~= operators).
Note that ~= cannot work, as the result of the concatenation has a
different type than the left hand side. (Unless, of course, the right hand
side is the empty tuple :-)
5.3) This is already possible in D using the typetuple coming from a
tuple using the (undocumented?) .tupleof. But this has the problem of
losing some safety, this compiles with no errors:
import std.typecons;
void bar(int i, string s) {}
void main() {
auto t1 = tuple(1, foo);
bar(t1.tupleof);
auto t2 = tuple(1);
auto t3 = tuple(foo);
bar(t2.tupleof, t3.tupleof);
}
This is because of the conflation of TypeTuple (the compiler thing) and
Tuple (the sane type thing). That code works because .tupleof is a
TypeTuple.
We need this functionality because of things like
std.traits.ParameterTypeTuple (or indeed Tuple itself uses a TypeTuple
internally).
The built in compiler tuple could use a new name, badly, to disperse the
confused situation with sane tuples. AliasSequence or something :-)
In Python there are more features similar to the point (5). Yo are
allowed to unpack a dynamic array too into variables, and even a lazy
generator. This is so handy and useful that I have suggested to allow
the same thing in D too:
http://d.puremagic.com/issues/show_bug.cgi?id=6383
I think that as well as tuples, any range should be unpackable, and I
think it should be implemented via syntactic rewrite.
Translate this:
auto (a, rest...) = myRange;
into
static assert (isInputRange!myRange);
assert (!myRange.empty);
auto a = myRange.front;
myRange.popFront;
rest = myRange;
Equivalently with bidirectional ranges, and any number of unpacked
elements.
I wonder how the auto(...) syntax works with existing variables. For
example, in python:
a, b = b, a # swap!
Re: Wider tuple design discussion
Michel Fortin: We need a way to make those two concepts work together, I think that's the hard part. I think they are incompatible. Bye, bearophile
Re: DWT in Phobos? was [Re: What library functionality would you most like to see in D?]
On Tue, 02 Aug 2011 10:49:45 +0200, Jacob Carlborg wrote: The port is very Java style, it doesn't have a D layer to make it work nicely with ranges (err last time I used it 3 yrs ago). All the packages are org.eclipse... The library itself is huge and the port isn't complete. How would the ranges be used in a GUI library? Well, not much thought has gone into it, but I'm thinking list displays could take ranges and provide a range interface. But maybe a ranges laziness is of no benefit and array() isn't so bad. I suppose working with Phobos containers would be a better example. I should probably look at using DWT again. I started used DFL because I needed a dependencyless Windows library for D2 and DWT wasn't there yet, and in general it is pretty big...
Re: What does C++ do better than D? - StackOverflow.com
On Tue, 02 Aug 2011 14:17:29 +0300, person per...@email.com wrote:
The problem as I see it is that D has two separate concepts that are
conflated:
const and immutable. In fact, I'd argue that immutable shouldn't even
exist in its
current standalone state but should rather be part of an ownership
system a-la
Bartosz' suggested annotation system.
The way const and immutable work in D is something essential, one is
mostly useless without the other.
I think people have a few misconceptions regarding how they work.
fun1(const Bar b1); // you can pass both mutable and immutable, but after
you enter here it treats b1 just like fun2 treats its argument b2.
fun2(immutable Bar b2); // you can pass only immutable
In the context of single threaded programs const mustn't be transitive.
E.g.
class Foo { int a; ... }
class Bar { Foo foo; ...}
void func(const Bar b);
void gunc(immutable Bar b);
func should be able to change b.foo.a but not b.foo (foo is head-const
or final)
gunc however will enforce transitivity and will not allow to change
b.foo.a
Wouldn't that be just going right back to C++ const system, (well i think
it is also what you want)?
Also the main purpose of const in D is providing a immutable environment
for both mutable and immutable types.
In the context of multi-threaded programs, casting const(T) to an
immutable(T)
would require locking/synchronization in order to preserve correctness.
To conclude, Instead of D's current model where both T and immutable(T)
can be
up-casted to const(T) I'm suggesting
T - const(T) -(locked)- immutable(T)
In addition, compile-time manifest consts via enum should be removed
in favor of
immutable.
AFAIR that wasn't possible, enum states it is a compile time constant
unlike immutable.
I think we should drop const in our discussions when we mean immutable.
Its use in C++ is too broad and sometimes not applicable in D.
Re: What library functionality would you most like to see in D?
On Sun, 31 Jul 2011 14:51:17 +0300, Peter Alexander peter.alexander...@gmail.com wrote: - Fast vector math library suitable for games. Speed is mostly up to the compilers' ability to optimize, especially inlining in this case. We already have math libraries and there are one in the works for phobos, if they are not enough for you please everyone state your requirements.
Re: What does C++ do better than D? - StackOverflow.com
== Quote from so (s...@so.so)'s article
On Tue, 02 Aug 2011 14:17:29 +0300, person per...@email.com wrote:
The problem as I see it is that D has two separate concepts that are
conflated:
const and immutable. In fact, I'd argue that immutable shouldn't even
exist in its
current standalone state but should rather be part of an ownership
system a-la
Bartosz' suggested annotation system.
The way const and immutable work in D is something essential, one is
mostly useless without the other.
I think people have a few misconceptions regarding how they work.
fun1(const Bar b1); // you can pass both mutable and immutable, but after
you enter here it treats b1 just like fun2 treats its argument b2.
fun2(immutable Bar b2); // you can pass only immutable
I know how const/immutable currently works in D. I was suggesting it has
problems.
In the context of single threaded programs const mustn't be transitive.
E.g.
class Foo { int a; ... }
class Bar { Foo foo; ...}
void func(const Bar b);
void gunc(immutable Bar b);
func should be able to change b.foo.a but not b.foo (foo is head-const
or final)
gunc however will enforce transitivity and will not allow to change
b.foo.a
Wouldn't that be just going right back to C++ const system, (well i think
it is also what you want)?
Also the main purpose of const in D is providing a immutable environment
for both mutable and immutable types.
I'm not suggesting going back to C++ (which sucks). I'm suggesting that
handling an immutable environment in D should be different.
In the context of multi-threaded programs, casting const(T) to an
immutable(T)
would require locking/synchronization in order to preserve correctness.
To conclude, Instead of D's current model where both T and immutable(T)
can be
up-casted to const(T) I'm suggesting
T - const(T) -(locked)- immutable(T)
In addition, compile-time manifest consts via enum should be removed
in favor of
immutable.
AFAIR that wasn't possible, enum states it is a compile time constant
unlike immutable.
I think we should drop const in our discussions when we mean immutable.
Its use in C++ is too broad and sometimes not applicable in D.
enum is a *hack* required only to circumvent the current linker.
There is nothing in the language design that requires this. The /correct/
solution
would be to use immutable and let the tool-chain figure out that memory is only
required if you take the address of that immutable.
Re: What library functionality would you most like to see in D?
On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts bra...@slice-2.puremagic.com wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad I agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Re: What library functionality would you most like to see in D?
2011/8/2 so s...@so.so On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts bra...@slice-2.puremagic.com wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad I agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not! If a GUI library were included in Phobos, that would make D a much better competitor against C#. That's why I hope such an inclusion would be possible in the future. I see why it might not be possible, though.
Re: What library functionality would you most like to see in D?
On Tue, 02 Aug 2011 06:10:29 +0300, bearophile bearophileh...@lycos.com wrote: - I'd also like a std.image module to load and save images in png, gif, jpeg, ppm, bmp. This is a very common need, even more common than a GUI toolkit, and there are far less ways to load a PNG than to create the API of a GUI toolkit. Wrapper over http://nothings.org/stb_image.c and no license issue. Sean Barrett wouldn't mind Boost i think. Though i am not sure it serves the general needs.
Re: What library functionality would you most like to see in D?
On Tue, Aug 2, 2011 at 5:45 PM, Jacob Carlborg d...@me.com wrote: On 2011-08-01 23:35, Nick Sabalausky wrote: Johann MacDonaghjohann.macdonagh...@spam.gmail.com wrote in message news:j1501g$tbs$1...@digitalmars.com... 1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework. Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff 2. DWT fixed up and merged into Phobos. That'd certainly be nice. That would be an enormous addition (in code) to Phobos. I would guess that the code base of DWT, for just one platform, is larger than the whole Phobos. -- /Jacob Carlborg Not sure what point adding these kinds of things to phobos would serve. As far as I can see it all you're going to do is discourage alternative implementations and encourage people to code before thinking about their own requirements. And for that you've made phobos significantly larger and harder to maintain.
Re: What library functionality would you most like to see in D?
Am 02.08.2011, 17:35 Uhr, schrieb Jimmy Cao jcao...@gmail.com: 2011/8/2 so s...@so.so On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts bra...@slice-2.puremagic.com wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad I agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not! If a GUI library were included in Phobos, that would make D a much better competitor against C#. That's why I hope such an inclusion would be possible in the future. I see why it might not be possible, though. Why is it so important that the GUI library is included in the std library? Unless it is like Delphi, VisualBasic others that it comes with a GUI designer and an IDE I personally find it ok to look for the best library for your project on the internet (small Windows-only, cross-platform, ...) :)
Re: What library functionality would you most like to see in D?
On 2011-07-31 07:27, Jonathan M Davis wrote: I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis Some kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar. -- /Jacob Carlborg
Re: What library functionality would you most like to see in D?
Am 02.08.2011, 17:38 Uhr, schrieb so s...@so.so: On Tue, 02 Aug 2011 06:10:29 +0300, bearophile bearophileh...@lycos.com wrote: - I'd also like a std.image module to load and save images in png, gif, jpeg, ppm, bmp. This is a very common need, even more common than a GUI toolkit, and there are far less ways to load a PNG than to create the API of a GUI toolkit. Wrapper over http://nothings.org/stb_image.c and no license issue. Sean Barrett wouldn't mind Boost i think. Though i am not sure it serves the general needs. Are you serious?! : QUICK NOTES: Primarily of interest to game developers and other people who can avoid problematic images and only need the trivial interface JPEG baseline (no JPEG progressive) PNG 8-bit only [...] I don't mind missing support for exotic varieties like um... RGB JPEG, but I think this file lacks too much support to be 'standard'. It fits well for what is described in the notes though.
Re: Wider tuple design discussion
Michel Fortin wrote: On 2011-08-02 13:15:52 +, bearophile bearophileh...@lycos.com said: A tuple isn't an object, it's more like a record, it's almost like a more handy POD. So tuples are data structures that you use with code (functions) that they don't contain. Actually, that's up to debate in my opinion. Andrei's Tuple in phobos is a struct, so it's a POD like you say. Walter's tuples in the language are just collections of variables. In fact they're collections of symbols, which can be types, variables, or values... A language tuple does not have an address in itself, it essentially has one address per field. This actually makes tuple packing/unpacking very efficient across function calls (because there's no real packing/unpacking taking place), but it makes it impossible to take the address of a tuple. We need a way to make those two concepts work together, I think that's the hard part. Tuples do have some disadvantages. Their fields often are anonymous, this goes against the typical well defined style of D/Java/Ada programs, where you know the name of what you are using. So tuples are better if you use them locally, or if they have only few items. Long tuples become hard to use because you risk forgetting what each field is, so the most common tuples have between 2 and 5 items. Named tuple elements in a language tuple will be implemented when/if someone implement named arguments, something I might do eventually.
Re: What does C++ do better than D? - StackOverflow.com
On 8/2/11 8:59 AM, Jeff Nowakowski wrote: On 08/01/2011 09:29 PM, Andrei Alexandrescu wrote: I know how to fix the design (in fact the implementation, the design is sound). It's just ever so difficult to find the time to prioritize for it. This sounds familiar to I have discovered a truly remarkable proof which this margin is too small to contain. I wish anything about immutability was nearly as remarkable as Fermat's last theorem :o). Andrei
Re: What library functionality would you most like to see in D?
On 8/2/11 10:25 AM, so wrote: On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts bra...@slice-2.puremagic.com wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad I agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not! I think a small and simple GUI would be the worst of all worlds. Andrei
Re: pi benchmark on ldc and dmd
On 02/08/2011 00:40, Walter Bright wrote: http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98 Anyone care to examine the assembler output and figure out why? I was talking to David Nadlinger the other day, and there was some sort of codegen bug causing things to massively outperform dmd and clang with equivalent code - it's possible this is the cause, I don't know without looking though. He may be able to shed some light on it. -- Robert http://octarineparrot.com/
Re: Wider tuple design discussion
On 02-08-2011 16:28, bearophile wrote: Michel Fortin: We need a way to make those two concepts work together, I think that's the hard part. I think they are incompatible. Bye, bearophile I'm not sure it would make much sense to actually allow low-level operations on tuples. They're meant to be a language abstraction, and freely taking the address of them seems useless in practice and really just smells like array pointers (or similar) to me. - Alex
Re: pi benchmark on ldc and dmd
On 8/2/11 7:34 PM, Robert Clipsham wrote: On 02/08/2011 00:40, Walter Bright wrote: Anyone care to examine the assembler output and figure out why? I was talking to David Nadlinger the other day, and there was some sort of codegen bug causing things to massively outperform dmd and clang with equivalent code - it's possible this is the cause, I don't know without looking though. He may be able to shed some light on it. Nope, this turned out to be a bug in my program, where some memory chunk used as test input data was prematurely garbage collected (that only surfaced with aggressive compiler optimizations, which is why I suspected a compiler bug). David
Re: What library functionality would you most like to see in D?
On 02-08-2011 18:44, Jacob Carlborg wrote: On 2011-07-31 07:27, Jonathan M Davis wrote: I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis Some kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar. Perhaps a curses binding of some sort? - Alex
Re: What library functionality would you most like to see in D?
On 2011-08-02 19:45, Alex Rønne Petersen wrote: On 02-08-2011 18:44, Jacob Carlborg wrote: Some kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar. Perhaps a curses binding of some sort? - Alex Something like that. -- /Jacob Carlborg
Re: What library functionality would you most like to see in D?
On Tue, Aug 2, 2011 at 11:34 AM, Marco Leise marco.le...@gmx.de wrote: Am 02.08.2011, 17:35 Uhr, schrieb Jimmy Cao jcao...@gmail.com: 2011/8/2 so s...@so.so On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts bra...@slice-2.puremagic.com wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad I agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not! If a GUI library were included in Phobos, that would make D a much better competitor against C#. That's why I hope such an inclusion would be possible in the future. I see why it might not be possible, though. Why is it so important that the GUI library is included in the std library? Unless it is like Delphi, VisualBasic others that it comes with a GUI designer and an IDE I personally find it ok to look for the best library for your project on the internet (small Windows-only, cross-platform, ...) :) You're right, it's probably not that important. I guess it's most important that a cross-platform GUI library can simply be easily installed and set up (with some sort of D package manager).
Re: What library functionality would you most like to see in D?
Plus that would tie any updates to the GUI with DMD releases. Bad idea!
Re: What library functionality would you most like to see in D?
Jonathan M Davis Wrote: I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis I'm nearing completion on an arbitrary-precision floating point library, along with implementations of decimal32, decimal64 and decimal128 structs. Paul
Re: What does C++ do better than D? - StackOverflow.com
Andrei Alexandrescu Wrote: Mentioning these to the outside blows the issues out of proportion and conveys the wrong message to someone coming anew to D. Well, from my point of view the very question Is there anything C++ does better than D implies C++'s inferiority and the answers become a pointless nerd talk about how to write a cross-platform code in assembler or how to extend metadata in standard C++.
Re: pi benchmark on ldc and dmd
On 8/2/2011 5:00 AM, Jason House wrote: The post says they did dmd -O. They did not mention -inline -noboundscheck -release. There may be extra flags that are required. Often when I see benchmark results like this, I wait to see what the actual problem is before jumping to conclusions. I have a lot of experience with this :-) The results could be any of: 1. wrong flags used (especially by inexperienced users) 2. the benchmark isn't measuring what it purports to be (an example might be it is actually measuring printf or malloc speed, not the generated code) 3. the benchmark is optimized for one particular compiler/language by someone very familiar with that compiler/language and it exploits a particular quirk of it 4. the compiler is hand optimized for a specific benchmark, and the great results disappear if anything in the source code changes (yes, this is dirty, and I've seen it done by big name compilers) 5. the different benchmarks are run on different computers 6. the memory layout could wind up arbitrarily different for the different compilers/languages, resulting in different performance due to memory caching etc.
Re: What library functionality would you most like to see in D?
Am 02.08.2011 01:51, schrieb Piotr Szturmaj: Jonathan M Davis wrote: I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis 1. Cryptography (I already wrote all SHA hash implementations and HMAC, they will be open sourced under Boost license, I'm also working on Rijndael/AES impl.) some of the proposed namespaces (just thinking loud): std.crypto.cipher - block and stream ciphers std.crypto.hash - message digests (SHA1, RIPEMD, ...) std.crypto.mac - message auth codes like HMAC, CMAC, UMAC std.crypto.mode - block cipher modes like CBC, GCM, ... std.crypto.padding - padding schemes std.crypto.pki - asymmetric cryptography (RSA), PKI std.crypto.x509 - certificate support Maybe http://www.dsource.org/projects/dcrypt could be used. Cheers, - Daniel
Re: pi benchmark on ldc and dmd
I think I have it: 64 bit registers. I got ldc to work
in 32 bit (didn't have that yesterday, so I was doing 64 bit only)
and compiled.
No difference in timing between ldc 32 bit and dmd 32 bit.
The disassembly isn't identical but the time is. (The disassembly
seems to mainly order things differently, but ldc has fewer jump
instructions too.)
Anyway.
In 64 bit, ldc gets a speedup over dmd. Looking at the asm
output, it looks like dmd doesn't use any of the new registers,
whereas ldc does. (dmd's 64 bit looks mostly like 32 bit code with
r instead of e.)
Here's the program. It's based on one of the Python ones.
import std.bigint;
import std.stdio;
alias BigInt number;
void main() {
auto N = 1;
number i, k, ns;
number k1 = 1;
number n,a,d,t,u;
n = 1;
d = 1;
while(1) {
k += 1;
t = n1;
n *= k;
a += t;
k1 += 2;
a *= k1;
d *= k1;
if(a = n) {
t = (n*3 +a)/d;
u = (n*3 +a)%d;
u += n;
if(d u) {
ns = ns*10 + t;
i += 1;
if(i % 10 == 0) {
debug writefln (%010d\t:%d, ns, i);
ns = 0;
}
if(i = N) {
break;
}
a -= d*t;
a *= 10;
n *= 10;
}
}
}
}
=
BigInt's calls aren't inlined, but that's a frontend issue. Let's
eliminate that by switching to long in that alias.
The result will be wrong, but that's beside the point for now. I
just want to see integer math. (this is why the writefln is debug
too)
With optimizations turned on, ldc again wins by the same ratio -
it runs in about 2/3 the time - and the code is much easier to look
at.
Let's see what's going on.
The relevant loop from DMD (64 bit):
===
L47:inc qword ptr -040h[RBP]
mov RAX,-028h[RBP]
add RAX,RAX
mov -010h[RBP],RAX
mov RAX,-040h[RBP]
imulRAX,-028h[RBP]
mov -028h[RBP],RAX
mov RAX,-010h[RBP]
add -020h[RBP],RAX
add qword ptr -030h[RBP],2
mov RAX,-030h[RBP]
imulRAX,-020h[RBP]
mov -020h[RBP],RAX
mov RAX,-030h[RBP]
imulRAX,-018h[RBP]
mov -018h[RBP],RAX
mov RAX,-020h[RBP]
cmp RAX,-028h[RBP]
jl L47
mov RAX,-028h[RBP]
lea RAX,[RAX*2][RAX]
add RAX,-020h[RBP]
mov -058h[RBP],RAX
cqo
idivqword ptr -018h[RBP]
mov -010h[RBP],RAX
mov RAX,-058h[RBP]
cqo
idivqword ptr -018h[RBP]
mov -8[RBP],RDX
mov RAX,-028h[RBP]
add -8[RBP],RAX
mov RAX,-018h[RBP]
cmp RAX,-8[RBP]
jle L47
mov RAX,-038h[RBP]
lea RAX,[RAX*4][RAX]
add RAX,RAX
add RAX,-010h[RBP]
mov -038h[RBP],RAX
inc qword ptr -048h[RBP]
mov RAX,-048h[RBP]
mov RCX,0Ah
cqo
idivRCX
testRDX,RDX
jne L109
mov qword ptr -038h[RBP],0
L109: cmp qword ptr -048h[RBP],02710h
jge L137
mov RAX,-018h[RBP]
imulRAX,-010h[RBP]
sub -020h[RBP],RAX
imulEAX,-020h[RBP],0Ah
mov -020h[RBP],RAX
imulEAX,-028h[RBP],0Ah
mov -028h[RBP],RAX
jmp L47
===
and from ldc 64 bit:
L20:add RDI,2
inc RCX
lea R9,[R10*2][R9]
imulR9,RDI
imulR8,RDI
imulR10,RCX
cmp R9,R10
jl L20
lea RAX,[R10*2][R10]
add RAX,R9
cqo
idivR8
add RDX,R10
cmp R8,RDX
jle L20
cmp RSI,0270Fh
jg L73
Re: What library functionality would you most like to see in D?
On 8/1/2011 5:51 PM, Brad Roberts wrote: I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. Also, remember, we did try to endorse a standard gui library for D a while back. It was a disaster on every front.
Re: What does C++ do better than D? - StackOverflow.com
On 8/2/2011 3:18 AM, Marco Leise wrote: On this higher level C++ gives the form of logical protection for the 'caching' case that I need as an OO programmer. My point is C++ simply does not give that protection. The protection is there only by *convention*. It is not a language feature.
Re: pi benchmark on ldc and dmd
On Tue, Aug 2, 2011 at 7:08 AM, Adam D. Ruppe destructiona...@gmail.comwrote: LDC builds in under a half hour, even on my underpowered ARM SoC, so I don't see how you could be having trouble there. Building dmd from the zip took 37 *seconds* for me just now, after running a make clean (this is on Linux). gdc and ldc have their advantages, but they have disadvantages too. I think the people saying abandon dmd don't know the other side of the story. Basically, I think the more compilers we have for D the better. gdc is good. ldc is good. And so is dmd. We shouldn't abandon any of them. For the record, I'm fine with the current arrangement and just playing devil's advocate here: So far, you've outlined that GDC takes a while to build and the build processes for GDC and LDC are inconvenient as the only disadvantages they have. LDC took about 3 minutes on a Linux VM on my laptop, and since it has proper incremental build support through CMake, I don't really see that qualifying as a disadvantage. The only people that really need to regularly build compilers are the folks that work on them, and that's why we have incremental builds. Now, DMD does have speed on its side. It doesn't have debugging support (you have to jump through hoops on Windows and Linux is just a joke), binary and object file compatibility (even GDC has more going for it on Windows than DMD does), platform compatibility (outside x86 and x86_64), name recognition (I'm a college student, and people look at me funny when I mention Digital Mars), shared library support, and acceptance in the Linux world. The reason I use GDC for pretty much all my development is that it has all those things, and the reason I think it's worth playing devil's advocate and really considering the current situation is that GDC and LDC get all this for free by wiring up the DMD frontend to a different backend. The current state of affairs is certainly maintainable, but I think it's worth some thought as to whether it would be better in the long run if we started officially supporting a more accepted backend. My example would be Go, which got all sorts of notice when gccgo became important enough to get into the GCC codebase. I'm not saying DMD is terrible because it isn't. I'm just saying that there are a lot of benefits to be had by developing a more mature compiler on top of GCC or LLVM, and that we should consider whether that's a goal we should be working more towards.
Re: What library functionality would you most like to see in D?
Jacob Carlborg d...@me.com wrote in message news:j18dfe$20rj$1...@digitalmars.com... Windows and Linux (GTK) 32bit. I'm in the middle of porting the Mac OS X version. These are the platforms that SWT supports: Windows 32/64bit Windows CE Linux 32/64bit and PPC64 Solaris 10 x86 and Sparc HPUX IA64_32 AIX PPC/64 Mac OS X 32/64bit It does Solaris, HPUX, and AIX, but not BSD??
Re: pi benchmark on ldc and dmd
On Aug 2, 11 20:00, Jason House wrote: The post says they did dmd -O. They did not mention -inline -noboundscheck -release. There may be extra flags that are required. Walter Bright Wrote: http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98 Anyone care to examine the assembler output and figure out why? Let dmd have an '-O' flag to as a synonym of '-O -inline -noboundscheck -release' so people won't miss the extra flags in benchmarks. [/joke]
Re: What library functionality would you most like to see in D?
Alex Rønne Petersen xtzgzo...@gmail.com wrote in message news:j19d45$pt5$1...@digitalmars.com... On 02-08-2011 18:44, Jacob Carlborg wrote: Some kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar. Perhaps a curses binding of some sort? Maybe for linux, but it should be cross-platform and therefore use the Win API for that stuff on Windows. (For some bizarre reason, ANSI display support was removed from approx Win2k onward.)
Re: pi benchmark on ldc and dmd
On the flags: I did use them, but didn't write it all out and tried to make them irrelevant (by avoiding functions and arrays). But, if the same ones are passed to each compiler, it shouldn't matter anyway... the idea is to get an apples to apples comparison between the two D implementations, not to chase after a number itself.
Re: std.path review: second update
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2046.1312274305.14074.digitalmar...@puremagic.com... Actually, that raises the argument that we should have an addExtension function. We do: ~
Re: What library functionality would you most like to see in D?
There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls. Btw I've tried using WinAPI for console coloring, it's so damn clumsy to use. -_-
Re: pi benchmark on ldc and dmd
On 8/2/2011 12:49 PM, Adam D. Ruppe wrote: So I'm pretty sure the difference is caused by dmd not using the new registers in x64. The other differences look trivial to my eyes. dmd does use all the registers on the x64, but it seems to not be enregistering here. I'll have a look see.
Re: pi benchmark on ldc and dmd
== Quote from KennyTM~ (kenn...@gmail.com)'s article On Aug 2, 11 20:00, Jason House wrote: The post says they did dmd -O. They did not mention -inline -noboundscheck -release. There may be extra flags that are required. Walter Bright Wrote: http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98 Anyone care to examine the assembler output and figure out why? Let dmd have an '-O' flag to as a synonym of '-O -inline -noboundscheck -release' so people won't miss the extra flags in benchmarks. [/joke] -Ofast sounds better. ;)
Re: pi benchmark on ldc and dmd
On Tue, Aug 2, 2011 at 1:31 PM, Iain Buclaw ibuc...@ubuntu.com wrote: == Quote from KennyTM~ (kenn...@gmail.com)'s article On Aug 2, 11 20:00, Jason House wrote: The post says they did dmd -O. They did not mention -inline -noboundscheck -release. There may be extra flags that are required. Walter Bright Wrote: http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98 Anyone care to examine the assembler output and figure out why? Let dmd have an '-O' flag to as a synonym of '-O -inline -noboundscheck -release' so people won't miss the extra flags in benchmarks. [/joke] -O9001 will make the Redditors happy. -Ofast sounds better. ;)
Re: pi benchmark on ldc and dmd
Adam D. Ruppe:
Here's the program. It's based on one of the Python ones.
The D code is about 2.8 times slower than the Haskell version, and it has a
bug, shown here:
import std.stdio, std.bigint;
void main() {
int x = 100;
writefln(%010d, x);
BigInt bx = x;
writefln(%010d, bx);
}
Output:
000100
100
The Haskell code I've used:
-- Compile with: ghc --make -O3 -XBangPatterns -rtsopts pidigits_hs.hs
import System
pidgits n = 0 % (0 # (1,0,1)) where
i%ds
| i = n = []
| True = (concat h ++ \t: ++ show j ++ \n) ++ j%t
where k = i+10; j = min n k
(h,t) | k n = (take (n`mod`10) ds ++ replicate (k-n) ,[])
| True = splitAt 10 ds
j # s | na || r+n=d = k # t
| True = show q : k # (n*10,(a-(q*d))*10,d)
where k = j+1; t@(n,a,d)=ks; (q,r)=(n*3+a)`divMod`d
j(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1)
main = putStr.pidgits.read.head = getArgs
Bye,
bearophile
Re: pi benchmark on ldc and dmd
On 8/2/2011 12:49 PM, Adam D. Ruppe wrote: So I'm pretty sure the difference is caused by dmd not using the new registers in x64. The other differences look trivial to my eyes. When I compile it, it uses the registers: L2E:inc R11 lea R9D,[00h][RSI*2] mov R9,R9 mov RCX,R11 imulRCX,RSI mov RSI,RCX add RDI,R9 add R8,2 mov RDX,R8 imulRDX,RDI mov RDI,RDX mov R10,R8 imulR10,RBX mov RBX,R10 cmp RDI,RSI jl L2E lea RAX,[RCX*2][RCX] add RAX,RDX mov -8[RBP],RAX cqo idivR10 mov R9,RAX mov R9,R9 mov RAX,-8[RBP] cqo idivR10 mov R12,RDX mov R12,R12 add R12,RSI cmp RBX,R12 jle L2E lea R14,[R14*4][R14] add R14,R14 add R14,R9 mov R14,R14 inc R13 mov RAX,R13 mov RCX,0Ah cqo idivRCX testRDX,RDX jne LBD xor R14,R14 LBD:cmp R13,02710h jge LE3 mov RDX,RBX imulRDX,R9 sub RDI,RDX imulR10D,RDI,0Ah mov RDI,R10 imulR12D,RSI,0Ah mov RSI,R12 jmp L2E All I did with your example was replace BigInt with long.
Re: pi benchmark on ldc and dmd
Walter Bright wrote:
All I did with your example was replace BigInt with long.
hmm this is my error, but might be a bug too.
Take that same program and add some inline asm to it.
void main() {
asm { nop; }
[... the rest is identical ...]
}
Now compile it and check the output. With the asm, I get the
output I posted. If I cut it out, I get what you posted.
My error here is when I did the obj2asm the first time, I added
an instruction inline so I could confirm quickly that I was in
the right place in the file. (I cut that out later but forgot to
rerun obj2asm.)
Re: pi benchmark on ldc and dmd
On 02.08.2011 22:36, Andrew Wiley wrote: On Tue, Aug 2, 2011 at 1:31 PM, Iain Buclaw ibuc...@ubuntu.com mailto:ibuc...@ubuntu.com wrote: == Quote from KennyTM~ (kenn...@gmail.com mailto:kenn...@gmail.com)'s article On Aug 2, 11 20:00, Jason House wrote: The post says they did dmd -O. They did not mention -inline -noboundscheck -release. There may be extra flags that are required. Walter Bright Wrote: http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98 Anyone care to examine the assembler output and figure out why? Let dmd have an '-O' flag to as a synonym of '-O -inline -noboundscheck -release' so people won't miss the extra flags in benchmarks. [/joke] -O9001 will make the Redditors happy. -Ofast sounds better. ;) How about replacing -w with -9001? http://en.wikipedia.org/wiki/ISO_9001#Contents_of_ISO_9001
Re: pi benchmark on ldc and dmd
Ok.. I'm pretty sure that's a bug I discovered the other day in the
initilization code of asm blocks. I've already got a fix for it and will
be sending a pull request shortly.
The asm semantic code calls the 32bit initialization code of the backend
unconditionally, which is just wrong.
On Tue, 2 Aug 2011, Adam D. Ruppe wrote:
Walter Bright wrote:
All I did with your example was replace BigInt with long.
hmm this is my error, but might be a bug too.
Take that same program and add some inline asm to it.
void main() {
asm { nop; }
[... the rest is identical ...]
}
Now compile it and check the output. With the asm, I get the
output I posted. If I cut it out, I get what you posted.
My error here is when I did the obj2asm the first time, I added
an instruction inline so I could confirm quickly that I was in
the right place in the file. (I cut that out later but forgot to
rerun obj2asm.)
Re: pi benchmark on ldc and dmd
https://github.com/D-Programming-Language/dmd/pull/287
Before pulling this, though, the current win32 compilation failure should
be fixed to avoid compounding problems:
https://github.com/D-Programming-Language/dmd/pull/288
Later,
Brad
On Tue, 2 Aug 2011, Brad Roberts wrote:
Ok.. I'm pretty sure that's a bug I discovered the other day in the
initilization code of asm blocks. I've already got a fix for it and will
be sending a pull request shortly.
The asm semantic code calls the 32bit initialization code of the backend
unconditionally, which is just wrong.
On Tue, 2 Aug 2011, Adam D. Ruppe wrote:
Walter Bright wrote:
All I did with your example was replace BigInt with long.
hmm this is my error, but might be a bug too.
Take that same program and add some inline asm to it.
void main() {
asm { nop; }
[... the rest is identical ...]
}
Now compile it and check the output. With the asm, I get the
output I posted. If I cut it out, I get what you posted.
My error here is when I did the obj2asm the first time, I added
an instruction inline so I could confirm quickly that I was in
the right place in the file. (I cut that out later but forgot to
rerun obj2asm.)
Re: What does C++ do better than D? - StackOverflow.com
Am 02.08.2011, 21:46 Uhr, schrieb Walter Bright newshou...@digitalmars.com: On 8/2/2011 3:18 AM, Marco Leise wrote: On this higher level C++ gives the form of logical protection for the 'caching' case that I need as an OO programmer. My point is C++ simply does not give that protection. The protection is there only by *convention*. It is not a language feature. Hmm yes, that cannot be argued. But you can go with the undefined behaviour resulting in casting away const in D. Isn't that the same category? And do you sometimes think Hey you guys can just use C++ or Java if you think D is wrong! ? I hope not. I enjoy looking into an evolving language and discuss it and I've written a DOS animated GIF viewer and an MD5 hasher in assembly. So I like being close to the silicon from time to time when I'm not trying to hail the OOP gods.
Re: pi benchmark on ldc and dmd
Am 02.08.2011, 22:35 Uhr, schrieb bearophile bearophileh...@lycos.com: pidgits n = 0 % (0 # (1,0,1)) where i%ds | i = n = [] | True = (concat h ++ \t: ++ show j ++ \n) ++ j%t where k = i+10; j = min n k (h,t) | k n = (take (n`mod`10) ds ++ replicate (k-n) ,[]) | True = splitAt 10 ds j # s | na || r+n=d = k # t | True = show q : k # (n*10,(a-(q*d))*10,d) where k = j+1; t@(n,a,d)=ks; (q,r)=(n*3+a)`divMod`d j(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1) main = putStr.pidgits.read.head = getArgs Is this Indonesian cast to ASCII? :p
Re: pi benchmark on ldc and dmd
Am 02.08.2011, 22:38 Uhr, schrieb Walter Bright newshou...@digitalmars.com: L2E:inc R11 lea R9D,[00h][RSI*2] mov R9,R9 ... mov R9,RAX mov R9,R9 ... mov R12,RDX mov R12,R12 ... lea R14,[R14*4][R14] add R14,R14 add R14,R9 mov R14,R14 ... Any reason for all those mov x,x 's?
Re: dmd installer clobbers PATH on Windows (sometimes)
On 8/1/2011 1:58 PM, Brad Anderson wrote: The NSIS script used to update the environment variable (EnvVarUpdate) has the following warning [1]: Warning this code will replace paths rather than append if the existing path exceeds the maximum string length in the NSIS build you are using. Some setup crash can also occurs. The default maximum string length is 1024. There is a special build of NSIS [2] which has a larger maximum string length (8192) that would help avoid this problem. There is also a patch [1] for EnvVarUpdate that detects if the PATH will be overwritten instead of appended to and tells the user to update their PATH manually. I've seen this issue complained about before online but hadn't experienced it myself until recently. It can be a rather frustrating problem to experience as restoring your PATH isn't trivial because there is no way (that I know of) to look at what your PATH was before it was destroyed and the PATH is often updated by installers (as it is with dmd). [1] http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries#Warning [2] http://nsis.sourceforge.net/Special_Builds Regards, Brad Anderson Thanks for looking this up. This *has* happened to me, and I've seen a few posts on reddit where this happened to someone else as well.
Re: What library functionality would you most like to see in D?
On 8/1/2011 8:51 PM, Brad Roberts wrote: Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad After reading through this thread I now agree with you. I do think we need: 1. Ability to quickly install DWT (D package manager) 2. Links and documentation on d-p-l.org That way it's sort of the official GUI library, but we're not tying up Phobos development with this gigantic code base. Do you think this is a good idea? I think having some official GUI makes D more competitive with C#. It also allows IDE tools to start targeting designers for a particular library. What about wxWidgets? It has C bindings making the wrappers easy. There's already wxD (http://wxd.sourceforge.net/), but I'm not sure how mature it is.
Re: What library functionality would you most like to see in D?
On 8/1/2011 5:35 PM, Nick Sabalausky wrote: Johann MacDonaghjohann.macdonagh...@spam.gmail.com wrote in message news:j1501g$tbs$1...@digitalmars.com... 1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework. Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Ah nice, I knew he was working on a web framework but I wasn't sure about database support. Perhaps we should start taking a look at it, making it Phobos-like, and create bindings for a set of databases.
Re: pi benchmark on ldc and dmd
Marco Leise: Am 02.08.2011, 22:35 Uhr, schrieb bearophile bearophileh...@lycos.com: pidgits n = 0 % (0 # (1,0,1)) where i%ds | i = n = [] | True = (concat h ++ \t: ++ show j ++ \n) ++ j%t where k = i+10; j = min n k (h,t) | k n = (take (n`mod`10) ds ++ replicate (k-n) ,[]) | True = splitAt 10 ds j # s | na || r+n=d = k # t | True = show q : k # (n*10,(a-(q*d))*10,d) where k = j+1; t@(n,a,d)=ks; (q,r)=(n*3+a)`divMod`d j(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1) main = putStr.pidgits.read.head = getArgs Is this Indonesian cast to ASCII? :p I agree it's very bad looking, it isn't idiomatic Haskell code. But it contains nothing too much strange (and the algorithm is the same used in the D code). This is formatted a bit better, but I don't fully understand it yet: import System (getArgs) pidgits n = 0 % (0 # (1, 0, 1)) where i % ds | i = n = [] | True = (concat h ++ \t: ++ show j ++ \n) ++ j % t where k = i + 10 j = min n k (h, t) | k n = (take (n `mod` 10) ds ++ replicate (k - n) , []) | True = splitAt 10 ds j # s | n a || r + n = d = k # t | True = show q : k # (n * 10, (a - (q * d)) * 10, d) where k = j + 1 t@(n, a, d) = k s (q, r) = (n * 3 + a) `divMod` d j (n, a, d) = (n * j, (a + n * 2) * y, d * y) where y = (j * 2 + 1) main = putStr . pidgits . read . head = getArgs The Shootout site (where I have copied that code) ranks programs for the performance and their compactness (using a low-performance compressor...), so there you see Haskell (and other languages) programs that are sometimes too much compact and often use clever tricks to increase their performance. In normal Haskell code you don't find those tricks (this specific program seems to not use strange tricks, but on the Haskell Wiki page about this problem (http://www.haskell.org/haskellwiki/Shootout/Pidigits ) you see several programs that are both longer and slower than this one). The first working implementation of a C program is probably long and fast enough, while the first working implementation of a Haskell program is often short but not so fast. Usually there are ways to speed up the Haskell code. My experience of Haskell is limited, so usually when I write some Haskell my head hurts a bit :-) The higher level nature of Python allows me to implement working algorithms that are more complex, so sometimes the code ends being faster than C code, where you often avoid (at a first implementation) too much complex algorithms for fear of too much hard to find bugs, or just too much long to write implementation. Haskell in theory allows you to implement complex algorithms in a short space, and safely. In practice I think you need lot of brain to do this. Haskell sometimes looks like a puzzle language to me (maybe I just need more self-training on functional programming). Bye, bearophile
Re: What library functionality would you most like to see in D?
On 8/1/2011 8:51 PM, Brad Roberts wrote: Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad After reading through this thread I now agree with you. I do think we need: 1. Ability to quickly install DWT (D package manager) 2. Links and documentation on d-p-l.org That way it's sort of the official GUI library, but we're not tying up Phobos development with this gigantic code base. Do you think this is a good idea? I think having some official GUI makes D more competitive with C#. It also allows IDE tools to start targeting designers for a particular library. What about wxWidgets? It has C bindings making the wrappers easy. There's already wxD (http://wxd.sourceforge.net/), but I'm not sure how mature it is. I see no need for an official GUI. If there were an obvious winner, then maybe, but there isn't. And as Walter pointed out, apparently there was a previous attempt at endorsing a GUI library as the standard GUI library for D in the past and that went quite badly. Having a package management tool for D would definitely help, and maybe some of the more major D projects should be listed on the official site so that it's easier for people to know about them and find them. But trying to make a particular GUI library official is not a good idea IMHO. What we need is for it to be easier to find and use major D projects such as GUI toolkits for D not to try and put them in the standard library so that it's easier for people to find them. - Jonathan M Davis
Re: What library functionality would you most like to see in D?
Johann MacDonagh wrote: Perhaps we should start taking a look at it, making it Phobos-like, and create bindings for a set of databases. In my collection, I have (kinda crappy) implementations of my interface for mysql, postgres, sqlite and most recently ODBC. Since they all use C libs though, I'm not really completely sure on if they are license compatible with phobos. And, of course, I'm happy with a minimal set of features; I'm happy enough with strings since it's better than PHP, so mission accomplished. (I also have a lot of other code. Check out the readme in my github for a listing of many of them.)
Re: What library functionality would you most like to see in D?
On 8/1/2011 5:50 PM, Jonathan M Davis wrote: On 7/31/2011 11:32 PM, Walter Bright wrote: On 7/31/2011 6:29 PM, Johann MacDonagh wrote: Basically, you give it some string (string, wstring, or dstring), and it gives you a range of tokens back. The token has the type, a slice of the input that corresponds to the token, line / column, and a value (e.g. an integer constant). I suggest making the input a range. So, the reason I didn't do this initially was to make slicing a lot easier. It could easily be changed to any kind of input range of characters. However, it looks like something that's not a direct port of DMD isn't worthwhile. Some adjustment can be made. It _does_ need to have a range-based API, and some changes are inevitable in order to do that. But the changes to the basic logic need to be minimal. The thing is that it can be an input range _and_ take advantage of slicing with the use of static ifs in the appropriate places. If hasSlicing!Range is true, then you can have a static if branch for slicing it. If it's a narrow string then you can use another branch. And if it's neither, then it won't get the advantages of slicing. It complicates the code somewhat, but the proper use of Phobos functions which deal with it for you should help. In any case, the point is that we need to port dmd's lexer over to D, changing it enough to give it a range-based interface (so it'll take a range of dchars but return a range of tokens) but avoiding changing more than necessary so that it's easy to port changes and fixes back and forth between it and dmd's front end. - Jonathan M Davis Ok, I'll work on that this weekend. I'll do as close to a port as possible while stripping out anything that doesn't make sense and D-ifying the code a little bit. It will accept anything that isInputRange!R isSomeChar!(ElementEncodingType!R) and return an input range of tokens. I've already looked through quite a bit of the lexer.c source while writing my other lexer, and the port should be easy (famous last words).
Re: What library functionality would you most like to see in D?
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.2068.1312316161.14074.digitalmar...@puremagic.com... There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls. Hmm, see that's the problem, the ANSI escape codes don't really exist in Win2K+: http://en.wikipedia.org/wiki/ANSI_escape_code#Windows_and_DOS Granted, that doesn't cite any sources, unfortunately. But my experience porting the download progress bar in DVM to Windows supports what that Wikipedia article says. I had to rip out the escape codes and just use carriage-return (without line-feed). Although I suppose it's possible there are non-ANSI escape codes that I'm not aware of. Btw I've tried using WinAPI for console coloring, it's so damn clumsy to use. -_- I've never used it, but I don't doubt that. The WinAPI can be pretty clumsy in general (due in no small part to being so C-centric).
Re: What library functionality would you most like to see in D?
On 8/2/2011 7:39 PM, Adam Ruppe wrote:
Johann MacDonagh wrote:
Perhaps we should start taking a look at it,
making it Phobos-like, and create bindings for a set of databases.
In my collection, I have (kinda crappy) implementations of my
interface for mysql, postgres, sqlite and most recently ODBC.
Since they all use C libs though, I'm not really completely sure
on if they are license compatible with phobos. And, of course, I'm
happy with a minimal set of features; I'm happy enough with strings
since it's better than PHP, so mission accomplished.
(I also have a lot of other code. Check out the readme in my github
for a listing of many of them.)
Sounds like a good starting point. I've also written some code for
allowing LINQ style queries in D. You'd be able to do something like:
auto x = new SqliteConnection(mydata.db);
foreach(y; x.MyTable.where(someField 10))
{
// y is a wrapper around Variant[string] with some opDispatch magic
writeln(to!string(y.MyField));
writeln(to!int(y.SomeOtherField));
}
There were other things you could chain, such as:
x.MyTable.startAt(20).limit(10).where(blah).select(somefield,
sometingElse);
You'd also be able to do something like
x.MyTable.select!MyStruct();
which would pull field names out of struct fields, and return a range of
structs rather than something that has to go through the Variant[string]
stuff.
It's just a prototype for now, I have a working POC for sqlite3 (however
it doesn't support the where clause ;) ), but it might be something
useful for quickly prototyping code that deals with databases.
Would you mind if I take some of your ideas and come up with a proposal
for the D community to talk about? Then we can discuss licensing issues
with various databases systems.
Re: What does C++ do better than D? - StackOverflow.com
On 8/2/2011 3:00 PM, Marco Leise wrote: Hmm yes, that cannot be argued. But you can go with the undefined behaviour resulting in casting away const in D. Isn't that the same category? Not exactly: 1. Undefined behavior is just that, undefined. In C++, it is defined behavior and must be supported. 2. In safe mode in D, you cannot cast away const.
Re: What library functionality would you most like to see in D?
Johann MacDonagh wrote:
On 8/2/2011 7:39 PM, Adam Ruppe wrote:
Johann MacDonagh wrote:
Perhaps we should start taking a look at it,
making it Phobos-like, and create bindings for a set of databases.
In my collection, I have (kinda crappy) implementations of my
interface for mysql, postgres, sqlite and most recently ODBC.
Since they all use C libs though, I'm not really completely sure
on if they are license compatible with phobos. And, of course, I'm
happy with a minimal set of features; I'm happy enough with strings
since it's better than PHP, so mission accomplished.
(I also have a lot of other code. Check out the readme in my github
for a listing of many of them.)
Sounds like a good starting point. I've also written some code for
allowing LINQ style queries in D. You'd be able to do something like:
auto x = new SqliteConnection(mydata.db);
foreach(y; x.MyTable.where(someField 10))
{
// y is a wrapper around Variant[string] with some opDispatch magic
writeln(to!string(y.MyField));
writeln(to!int(y.SomeOtherField));
}
There were other things you could chain, such as:
x.MyTable.startAt(20).limit(10).where(blah).select(somefield,
sometingElse);
You'd also be able to do something like
x.MyTable.select!MyStruct();
which would pull field names out of struct fields, and return a range of
structs rather than something that has to go through the Variant[string]
stuff.
It's just a prototype for now, I have a working POC for sqlite3 (however
it doesn't support the where clause ;) ), but it might be something
useful for quickly prototyping code that deals with databases.
Would you mind if I take some of your ideas and come up with a proposal
for the D community to talk about? Then we can discuss licensing issues
with various databases systems.
Nice! Please also take a look on https://github.com/pszturmaj/ddb.
Re: What library functionality would you most like to see in D?
Johann MacDonagh wrote: Would you mind if I take some of your ideas and come up with a proposal for the D community to talk about? Of course, go ahead! You might also want to look up Piotr Szturmaj's database code. He has some nice Postgres code including a D struct - db table ORM thingy.
Re: What library functionality would you most like to see in D?
On 8/2/2011 8:02 PM, Nick Sabalausky wrote: I've never used it, but I don't doubt that. The WinAPI can be pretty clumsy in general (due in no small part to being so C-centric). And backwards compatibility. Nothing like using the BlahExEx() functions ;)
Re: What library functionality would you most like to see in D?
On 8/2/2011 8:22 PM, Adam D. Ruppe wrote: Johann MacDonagh wrote: Would you mind if I take some of your ideas and come up with a proposal for the D community to talk about? Of course, go ahead! You might also want to look up Piotr Szturmaj's database code. He has some nice Postgres code including a D struct - db table ORM thingy. Yep, he posted above ;). Do you know of any other database interfaces people have been working on? I'll make this my next priority after porting the D lexer.
Re: What does C++ do better than D? - StackOverflow.com
On 2/08/11 2:29 AM, Andrei Alexandrescu wrote: Overall I feel Peter's post on stackexchange did more bad than good (of course that doesn't mean he had the right; I'm just writing this under the hypothesis he meant well and he'd be interested ). Within the confines of the community, discussing such issues is welcome and healthy. Mentioning these to the outside blows the issues out of proportion and conveys the wrong message to someone coming anew to D. It's interesting that you've brought up the issue of the message being sent out about D, because I feel it is exactly the opposite: it's far too positive. Everyone seems to only talk about all the cool features in D and seem to ignore all the issues that exist. I first came to D precisely because I had heard about all the cool features: the nice template syntax, uniform function call syntax (what's happening with that btw?), CTFE etc. Of course, as soon as I tried to use those features I found out that they existed only in the specification, not in the implementations. I quit using D shortly afterwards out of frustration that the language wasn't what was advertised to me. I only came back after seeing Tomasz' work (which turned out to be in D1, but it sparked my interest again). It's hard to quantify whether my post has had a negative or positive impact on the language, but I believe honesty and openness are good things. People coming anew to D shouldn't be misled into thinking that it has no issues (as I was -- no one mentioned the implementation issues). I believe a disappointed user is much worse than missed user. Plus, C++'s type system is marred by issues, so the statement has correctness issues to start with. Const is a mix of storage type and type qualifier; even most experts have no idea about that, and the minority of experts who do know about the distinction have difficulty figuring which is in effect when. Type deduction with functions and const is essentially a collection of special cases. Pointer to member functions have a type, but it can't be named, spelled, or used. Functions taking char* still accept string literals (compilers increasingly override that, but the rule is in the standard for C's sake). There is no way to convert a void* to a pointer to function, meaning all dynamic loading facilities must operate outside the standard. There is no way to specify or figure out alignment. Slicing polymorphic objects is legit. And so on and so forth. Now this is very interesting and a perfect example of the point I'm trying to make about implementations being more important than specifications. You say there is no way to convert a void* to a function pointer inside the standard. Who cares? It works in the implementations. You say there's no way to specify or figure out alignment? Yes there is: compiler extensions. Wrap them in a macro and you're good to go. These problems with C++ that you've listed are imaginary problems that only exist in theory. In real world C++ they are solved problems. Do you know what will happen once (for example) alignment is standardised? Nothing. People will keep their compiler specific macros because they'll probably need to support pre-C++0x implementations. Maybe they'll add some extra macro conditions to support C++0x compilers and in 10 years time maybe they'll drop support for old compilers. It's funny that you argue that a bad language design last forever while a bad implementation is transitory. From what I can see, it appears to be the other way round. Just look at the Boost library. It still has code to handle compilers without partial specialisation support, and code to work around various other implementation specific behaviour. C++ (the language) is changing, but those bad implementations are still in use. How many websites still need to support IE6? I hope this illuminates the point I am trying to make.
Re: What library functionality would you most like to see in D?
Johann MacDonagh wrote: Do you know of any other database interfaces people have been working on? Not off the top of my head.
Re: What does C++ do better than D? - StackOverflow.com
Peter Alexander: It's interesting that you've brought up the issue of the message being sent out about D, because I feel it is exactly the opposite: it's far too positive. Everyone seems to only talk about all the cool features in D and seem to ignore all the issues that exist. ... It's hard to quantify whether my post has had a negative or positive impact on the language, but I believe honesty and openness are good things. People coming anew to D shouldn't be misled into thinking that it has no issues (as I was -- no one mentioned the implementation issues). I believe a disappointed user is much worse than missed user. I agree. Andrei (and others) were not listing the bad sides enough. A bit more transparency is better even in discussions outside this newsgroup. It's dangerous to give false hopes. Bye, bearophile
Re: What library functionality would you most like to see in D?
On 8/3/11, Nick Sabalausky a@a.a wrote: Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.2068.1312316161.14074.digitalmar...@puremagic.com... There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls. Hmm, see that's the problem, the ANSI escape codes don't really exist in Win2K+: Yes that's why I said there was a project that brought them back. I can't recall the name though :/
Re: pi benchmark on ldc and dmd
On 8/2/2011 3:23 PM, Trass3r wrote: Any reason for all those mov x,x 's? No. They'll get removed shortly. I see three problems with dmd's codegen here: 1. those redundant moves 2. failing to merge a couple divides 3. replacing a mul with an add/lea I'll see about taking care of them. (2) is the most likely culprit on the speed.
Re: What library functionality would you most like to see in D?
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.2071.1312335864.14074.digitalmar...@puremagic.com... On 8/3/11, Nick Sabalausky a@a.a wrote: Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.2068.1312316161.14074.digitalmar...@puremagic.com... There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls. Hmm, see that's the problem, the ANSI escape codes don't really exist in Win2K+: Yes that's why I said there was a project that brought them back. I can't recall the name though :/ Oh, I thought you meant it used them internally.
