www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What library functionality would you most like to see in D?

reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jul 30 2011
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1978.1312090051.14074.digitalmars-d puremagic.com...
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?

Off the top of my head: curl and xml
Jul 30 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 31 July 2011 01:53:25 Nick Sabalausky wrote:
 "Jonathan M Davis" <jmdavisProg gmx.com> wrote in message
 news:mailman.1978.1312090051.14074.digitalmars-d puremagic.com...
 
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?

Off the top of my head: curl and xml

Fortunately, both of those are in the works. A curl wrapper is more or less ready for review as I understand it, so it could be in Phobos fairly soon, but I have no idea where the new std.xml stands. - Jonathan M Davis
Jul 30 2011
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 31-07-2011 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

Here's a bunch of ideas, listed in no particular order... -- * Native code generation: I know this is quite a stretch for the standard library, but one thing I'm kind of missing at the moment is a uniform way to generate native machine code. This could be a useful piece of functionality for any application that takes code and just-in-time compiles it, in order to subsequently execute it. It could even be abstract enough to be reused as a general-purpose code generation library for executable files. I'm sure compiler/interpreter/VM writers alike would find this useful; I know I would. I'm currently in the process of writing a compiler infrastructure which will be capable of spitting out x86(-64) executable files, as well as executing code right in memory. In order to do this, I have to implement a code generation library for all of x86(-64); this is not a problem, but I'm sure others have had to do this before me (and will in the future). Standard facilities for this would make compiler engineering in D much easier. All this being said, this would probably be scarcely used and thus might not deserve much priority; I'm sure there are other things in much greater need of work at the moment. I just wanted to put this out there, at least. If this is something that would be desirable for the standard library, I would have no problem writing it for Phobos rather than my specific project. * Concurrency: Another thing I'd like to see is a better way of doing message-passing. Since D threads are, effectively, OS threads, spawning lots of actors is not as cheap as one would like. I'd like some way to spawn lightweight threads that integrate with std.concurrency so that actor systems can be modeled naturally (a la Erlang), rather than throwing several actors into one thread. I'm not sure how heavy fibers are in D, but perhaps it could be implemented on top of those? It would be even more awesome if std.concurrency was expanded to actually support distributed message-passing in some way; even heavyweight threads would be acceptable as long as the system could scale horizontally. * GPU/graphics: Standard library support for OpenGL and OpenCL would be a great way to make D more accessible for GPU-oriented programmers, I would think. Wrapping these libraries would probably be rather trivial. DirectX could of course be wrapped too, but I suppose a cross-platform interface would be better. * Configuration: AFAIK, D has no standard way of doing configuration at the moment. I don't know whether people see this as a problem or not. On one hand, just asking some configuration parser to fetch values for you is very convenient, but on the other hand, people might not like having some sort of "official D configuration format". Personally, the former seems appealing to me, as configuration parsing is the last thing I want to work on in my projects. ;) * Cryptography: D could definitely use more implementations of cryptographic algorithms. Wrapping OpenSSL might be a wise thing to do. * Compiler interface: Some primitive sort of interface to invoke the compiler on a set of files with certain options could be useful to invoke child processes with code compiled on the fly. This would of course demand that DMD is installed, but I don't think that's a problem for apps where doing this in the first place is a good idea. * Lexing and parsing: Standard facilities for these tasks could be very useful. Perhaps D could get its own dlex and dyacc or some such tools. Personally, I prefer sticking to LL(1), but LALR is generally more convenient and flexible, and thus I'd suggest something YACC/ANTLR-like. (I know this doesn't have much to do with Phobos per se, but I figured I'd mention it.) * Asynchronous sockets: For high-performance servers, asynchronous sockets utilizing functionality such as IOCP on Windows is important. * Audio/video: Interfaces to a library such as Libav could be included in Phobos. * Serialization: Some kind of serialization library could be useful. It could probably use compile-time reflection to figure out what kind of code to generate for a type, although my knowledge in D's CTR is not really sufficient to judge this. -- Personally, what I'd like to see done first would be native code generation, concurrency, and cryptography. - Alex
Jul 30 2011
next sibling parent reply Anders Ahlström <admin antoarts.com> writes:
== Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s article
 Here's a bunch of ideas, listed in no particular order...
 ...
 * Configuration:

 AFAIK, D has no standard way of doing configuration at the moment. I
 don't know whether people see this as a problem or not. On one hand,
 just asking some configuration parser to fetch values for you is very
 convenient, but on the other hand, people might not like having some
 sort of "official D configuration format". Personally, the former seems
 appealing to me, as configuration parsing is the last thing I want to
 work on in my projects. ;)

I'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files? AFAIK, D supports XML already, which can be used for configuration files, but sometimes something simpler can be convenient.
Jul 31 2011
parent reply Mirko Pilger <pilger cymotec.de> writes:
 I'm new to D, but I guess I might be able to develop some sort of configuration
 file library (supporting reading and writing values etc.). Do you guys have
some
 sort of preferences or should I just go with standard INI files?

maybe boost::property_tree could be of some inspiration here: http://www.boost.org/doc/libs/1_47_0/doc/html/property_tree.html
Jul 31 2011
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 31-07-2011 11:30, Anders Ahlstr�m wrote:
 I'm new to D, but I guess I might be able to develop some sort of configuration
 file library (supporting reading and writing values etc.). Do you guys have
some
 sort of preferences or should I just go with standard INI files?

 AFAIK, D supports XML already, which can be used for configuration files, but
 sometimes something simpler can be convenient.


On 31-07-2011 11:44, Mirko Pilger wrote:
 I'm new to D, but I guess I might be able to develop some sort of
 configuration
 file library (supporting reading and writing values etc.). Do you guys
 have some
 sort of preferences or should I just go with standard INI files?

maybe boost::property_tree could be of some inspiration here: http://www.boost.org/doc/libs/1_47_0/doc/html/property_tree.html

That seems like a good idea! As the doc page suggests, we could store configuration in XML, JSON, INI, or whatever people would want to use in their application. Phobos AFAIK has facilities for JSON and XML. Not sure about INI, though. - Alex
Jul 31 2011
next sibling parent reply Anders Ahlström <admin antoarts.com> writes:
== Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s article
 On 31-07-2011 11:30, Anders Ahlstr�m wrote:
 I'm new to D, but I guess I might be able to develop some sort of configuration
 file library (supporting reading and writing values etc.). Do you guys have
some
 sort of preferences or should I just go with standard INI files?

 AFAIK, D supports XML already, which can be used for configuration files, but
 sometimes something simpler can be convenient.


 I'm new to D, but I guess I might be able to develop some sort of
 configuration
 file library (supporting reading and writing values etc.). Do you guys
 have some
 sort of preferences or should I just go with standard INI files?

maybe boost::property_tree could be of some inspiration here: http://www.boost.org/doc/libs/1_47_0/doc/html/property_tree.html

configuration in XML, JSON, INI, or whatever people would want to use in their application. Phobos AFAIK has facilities for JSON and XML. Not sure about INI, though. - Alex

The property tree is independent of the underlying format, isn't it? What is needed is a property tree, and then a bunch of parsers each returning a property tree and being able to write it back to disk. The property tree doesn't even have to know if it is an INI file or an XML file it is editing, which is kind of cool, and flexible.
Jul 31 2011
parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 31-07-2011 12:09, Anders Ahlstr�m wrote:
 == Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s article
 On 31-07-2011 11:30, Anders Ahlstr�m wrote:
 I'm new to D, but I guess I might be able to develop some sort of configuration
 file library (supporting reading and writing values etc.). Do you guys have
some
 sort of preferences or should I just go with standard INI files?

 AFAIK, D supports XML already, which can be used for configuration files, but
 sometimes something simpler can be convenient.


 I'm new to D, but I guess I might be able to develop some sort of
 configuration
 file library (supporting reading and writing values etc.). Do you guys
 have some
 sort of preferences or should I just go with standard INI files?

maybe boost::property_tree could be of some inspiration here: http://www.boost.org/doc/libs/1_47_0/doc/html/property_tree.html

configuration in XML, JSON, INI, or whatever people would want to use in their application. Phobos AFAIK has facilities for JSON and XML. Not sure about INI, though. - Alex

The property tree is independent of the underlying format, isn't it? What is needed is a property tree, and then a bunch of parsers each returning a property tree and being able to write it back to disk. The property tree doesn't even have to know if it is an INI file or an XML file it is editing, which is kind of cool, and flexible.

Yes, indeed. It would be interesting, though, if we could utilize D's compile-time reflection to generate the parsing code instead of reading values by hand. Suppose I have some configuration like: class MainConfig { string ip; int port; class UserConfig { int accessLevel; string password; } UserConfig[string] usernameToConfigMappings; } It would be nice if I could then say: Config config = new XmlParser().ReadTree!MainConfig(); and it would automagically figure out how to map the resulting data to an instance of MainConfig. The config file could look like this in XML: <node name="ip">127.0.0.1</node> <node name="port">65535</node> <child name="usernameToConfigMappings"> <node name="joe"> <node name="accessLevel">1234</node> <node name="password">asdf</node> </node> <node name="alice"> ... </node> ... </child> or something like that, if I'm reading the property trees docs right... - Alex
Jul 31 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-07-31 11:57, Alex Rønne Petersen wrote:
 That seems like a good idea! As the doc page suggests, we could store
 configuration in XML, JSON, INI, or whatever people would want to use in
 their application. Phobos AFAIK has facilities for JSON and XML. Not
 sure about INI, though.

 - Alex

It's easy to do a simple config module that's probably would be enough for quite many uses. Just serialize an associative array. My serialization library (Orange) already supports multiple formats (although I've only implemented XML). -- /Jacob Carlborg
Jul 31 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-07-31 08:47, Alex Rønne Petersen wrote:
 * GPU/graphics:

 Standard library support for OpenGL and OpenCL would be a great way to
 make D more accessible for GPU-oriented programmers, I would think.
 Wrapping these libraries would probably be rather trivial. DirectX could
 of course be wrapped too, but I suppose a cross-platform interface would
 be better.

Have a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.
 * Configuration:

 AFAIK, D has no standard way of doing configuration at the moment. I
 don't know whether people see this as a problem or not. On one hand,
 just asking some configuration parser to fetch values for you is very
 convenient, but on the other hand, people might not like having some
 sort of "official D configuration format". Personally, the former seems
 appealing to me, as configuration parsing is the last thing I want to
 work on in my projects. ;)

XML or JSON could be used for this.
 * Cryptography:

 D could definitely use more implementations of cryptographic algorithms.
 Wrapping OpenSSL might be a wise thing to do.

 * Compiler interface:

 Some primitive sort of interface to invoke the compiler on a set of
 files with certain options could be useful to invoke child processes
 with code compiled on the fly. This would of course demand that DMD is
 installed, but I don't think that's a problem for apps where doing this
 in the first place is a good idea.

 * Lexing and parsing:

 Standard facilities for these tasks could be very useful. Perhaps D
 could get its own dlex and dyacc or some such tools. Personally, I
 prefer sticking to LL(1), but LALR is generally more convenient and
 flexible, and thus I'd suggest something YACC/ANTLR-like.

 (I know this doesn't have much to do with Phobos per se, but I figured
 I'd mention it.)

I think someone is working on this.
 * Asynchronous sockets:

 For high-performance servers, asynchronous sockets utilizing
 functionality such as IOCP on Windows is important.

 * Audio/video:

 Interfaces to a library such as Libav could be included in Phobos.

 * Serialization:

 Some kind of serialization library could be useful. It could probably
 use compile-time reflection to figure out what kind of code to generate
 for a type, although my knowledge in D's CTR is not really sufficient to
 judge this.

I'm currently working on this: http://dsource.org/projects/orange/ There's a release available, but now I'm completely rewriting the library to support more types. D could use some better runtime reflection do better support serialization.
 --

 Personally, what I'd like to see done first would be native code
 generation, concurrency, and cryptography.

 - Alex

-- /Jacob Carlborg
Jul 31 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related libraries.

That looks nice. Are there any plans for OpenCL support?
 I think someone is working on this.

I know of the Goldie project. Is this it?
 I'm currently working on this: http://dsource.org/projects/orange/
 There's a release available, but now I'm completely rewriting the library to
support more types. D could use some better runtime reflection do better
support serialization.

That looks like it's exactly what I had in mind. It would be great if something like that could make it into Phobos itself so it's more readily accessible for users. - Alex
Jul 31 2011
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 31-07-2011 12:24, Jonathan M Davis wrote:
 On Sunday 31 July 2011 12:01:02 Alex Rønne Petersen wrote:
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related libraries.

That looks nice. Are there any plans for OpenCL support?
 I think someone is working on this.

I know of the Goldie project. Is this it?

Off and on, I've been working on porting dmd's lexer to D for Phobos, but I've had enough else going on, that I haven't gotten much done on it of late. And there is some controversy on the matter, because Andrei and others want a lexer/parser generator in Phobos rather than a hand-written lexer and parser. Both are of value though. So, I don't know what we'll end up with in the end. I'm not aware of anyone working on a lexer or parser generator for Phobos though. Goldie is the closest to that sort of thing that there is at the moment. I think that Jacob was referring to my efforts to port the dmd lexer though. - Jonathan M Davis

A generator is what I had in mind - it would allow users to more easily approach parsing, I think. Hand-written parsers have a much greater learning curve. I do agree on both ideas though; a built-in parser for D would probably be pretty useful to have for extracting information from D source code. An interesting exercise would be generating a lexer/parser via CTFE and mixins. :) Perhaps we don't really need dlex/dyacc tools if we could do something like that. - Alex
Jul 31 2011
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 31-07-2011 12:36, Jonathan M Davis wrote:
 On Sunday 31 July 2011 12:28:29 Alex Rønne Petersen wrote:
 On 31-07-2011 12:24, Jonathan M Davis wrote:
 On Sunday 31 July 2011 12:01:02 Alex Rønne Petersen wrote:
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related libraries.

That looks nice. Are there any plans for OpenCL support?
 I think someone is working on this.

I know of the Goldie project. Is this it?

Off and on, I've been working on porting dmd's lexer to D for Phobos, but I've had enough else going on, that I haven't gotten much done on it of late. And there is some controversy on the matter, because Andrei and others want a lexer/parser generator in Phobos rather than a hand-written lexer and parser. Both are of value though. So, I don't know what we'll end up with in the end. I'm not aware of anyone working on a lexer or parser generator for Phobos though. Goldie is the closest to that sort of thing that there is at the moment. I think that Jacob was referring to my efforts to port the dmd lexer though. - Jonathan M Davis

A generator is what I had in mind - it would allow users to more easily approach parsing, I think. Hand-written parsers have a much greater learning curve. I do agree on both ideas though; a built-in parser for D would probably be pretty useful to have for extracting information from D source code. An interesting exercise would be generating a lexer/parser via CTFE and mixins. :) Perhaps we don't really need dlex/dyacc tools if we could do something like that.

The idea behind the hand-written D lexer (and eventually parser) for D is that it follows the implementation of the compiler's front-end, and so using it to process D code will have the same result as running the compiler. It obviously doesn't scale beyond D itself. If you have a lexer generator and/or parser parser generator, then you can get it to generate a lexer or parser for any grammar that you want. So, it covers a different use case - which is why both are of value. Personally, I'd probably want to write a parser by hand anyway, since there are definite advantages in doing so, but there's no reason why Phobos shouldn't have a generator for that for those who want it. Someone still needs to write it though. - Jonathan M Davis

It's something I wouldn't mind having a look into. I think we could do some awesome magic with CTFE/mixins to do it all inside the D language, using no external tools, but I'm not sure. I'll have to dig into the implementations of existing lexers/parsers first and wee how it could be done. - Alex
Jul 31 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-07-31 12:36, Jonathan M Davis wrote:
 The idea behind the hand-written D lexer (and eventually parser) for D is that
 it follows the implementation of the compiler's front-end, and so using it to
 process D code will have the same result as running the compiler. It obviously
 doesn't scale beyond D itself.

I would really hope that the compiler itself could be built on top of the font end that will hopefully end up in Phobos. Then they would always be in sync and produce correct results. -- /Jacob Carlborg
Jul 31 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-07-31 12:24, Jonathan M Davis wrote:
 On Sunday 31 July 2011 12:01:02 Alex Rønne Petersen wrote:
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related libraries.

That looks nice. Are there any plans for OpenCL support?
 I think someone is working on this.

I know of the Goldie project. Is this it?

Off and on, I've been working on porting dmd's lexer to D for Phobos, but I've had enough else going on, that I haven't gotten much done on it of late. And there is some controversy on the matter, because Andrei and others want a lexer/parser generator in Phobos rather than a hand-written lexer and parser. Both are of value though. So, I don't know what we'll end up with in the end. I'm not aware of anyone working on a lexer or parser generator for Phobos though. Goldie is the closest to that sort of thing that there is at the moment. I think that Jacob was referring to my efforts to port the dmd lexer though. - Jonathan M Davis

Yes, exactly, I was referring to your port of the DMD lexer. I really hope that it ends up in Phobos and hoping that DMD can gradual take advantage of the lexer (and hopefully a whole front end) in Phobos. -- /Jacob Carlborg
Jul 31 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-07-31 12:01, Alex Rønne Petersen wrote:
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related libraries.

That looks nice. Are there any plans for OpenCL support?
 I think someone is working on this.

I know of the Goldie project. Is this it?

I was referring to Jonathan's port of the DMD lexer.
 I'm currently working on this: http://dsource.org/projects/orange/
 There's a release available, but now I'm completely rewriting the
 library to support more types. D could use some better runtime
 reflection do better support serialization.

That looks like it's exactly what I had in mind. It would be great if something like that could make it into Phobos itself so it's more readily accessible for users. - Alex

Yes, I think so as well. -- /Jacob Carlborg
Jul 31 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-07-31 12:01, Alex Rønne Petersen wrote:
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related libraries.

That looks nice. Are there any plans for OpenCL support?

Not officially that I know of, I know someone is working on OpenCL bindings, don't remember who. -- /Jacob Carlborg
Jul 31 2011
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 7/31/2011 7:01 PM, Alex Rønne Petersen wrote:
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related libraries.

That looks nice. Are there any plans for OpenCL support?

Yes, eventually. But I make no promises as to win. I work on Derelict at a snail's pace. If someone contributed a binding, it would get in a lot quicker!
Jul 31 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:j1395t$13bo$1 digitalmars.com...
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 I think someone is working on this.

I know of the Goldie project. Is this it?

I'm very interested in doing what I can to make Goldie suitable for what people need. Are there any particular shortcomings you see with it?
Aug 01 2011
prev sibling parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/31/2011 5:57 AM, Jacob Carlborg wrote:
 * Lexing and parsing:

 Standard facilities for these tasks could be very useful. Perhaps D
 could get its own dlex and dyacc or some such tools. Personally, I
 prefer sticking to LL(1), but LALR is generally more convenient and
 flexible, and thus I'd suggest something YACC/ANTLR-like.

 (I know this doesn't have much to do with Phobos per se, but I figured
 I'd mention it.)

I think someone is working on this.

I've started on a port of DMD's lexer (not really a port ;) ): https://github.com/jmacdonagh/phobos/compare/master...std.lang.d.lexer 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). Some features I'm planning: 1. Support D1 and D2. 2. Warnings and errors returned in the tokens. For example, if you use an octal constant for D2 code, it will correctly return an integer constant token with some kind of warning flag set and a message. In terms of errors, if the lexer hits "0xz012", it will return an error token for the slice "0xz" and then start lexing an integer constant "012". No exceptions, easy peasy. 3. CTFEable. Although I'll probably have to wait till the next DMD release. 4. Support any kind of character range. Not sure if people want to lex something that's not a string/wstring/dstring. I'm glad this was brought up. I remember Walter's post last year asking for this module, but the conversation seemed to kill the idea. I started on this just for the fun of it, but then doubted whether Phobos wanted it. I feel that a hand written lexer / parser is going to be faster than something generated, but maybe I'm old fashioned. Anyway, Jim, if you want to do this I can move on to something else. If you want, I can continue on. I didn't see a branch in your repo so I'm not sure what you've done.
Jul 31 2011
next sibling parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/31/2011 9:31 PM, Andrej Mitrovic wrote:
 Btw why not take DDMD's lexer.d and start from there?

I wasn't sure how up-to-date DDMD was when I started. Plus, I thought a fresh look at a lexer using D2 features rather than a straight port would be a little cleaner. For example, instead of that huge switch statement for all the operators, I have a mixin that generates that huge switch statement based on an array of operator strings: https://github.com/jmacdonagh/phobos/compare/master...std.lang.d.lexer#L0R506 I may end up using "borrowing" some code from DDMD ;)
Jul 31 2011
prev sibling next sibling parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/31/2011 9:29 PM, Johann MacDonagh wrote:
 Anyway, Jim, if you want to do this I can move on to something else. If
 you want, I can continue on. I didn't see a branch in your repo so I'm
 not sure what you've done.

Derp. I meant to say "Jonathan".
Jul 31 2011
prev sibling next sibling parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/31/2011 9:56 PM, Jonathan M Davis wrote:
 If we do a hand-written lexer of D for Phobos, it really should be a fairly
 direct port of the dmd front-end. It should be _somewhat_ D-ified as
 appropriate, (and the API should definitely be properly range-based and all
 that), but the implementation needs to be fairly close to dmd itself so that
 it's easy for someone to port changes and fixes back and forth between the two.
 Otherwise, they're going to get out of sync fairly easily. If we're not going
 to do a direct port, then we might as well just do the template-based lexer
 generator that Andrei and others would really like to see (which we should
 still do, but I think that the hand-written lexer is nowhere near as valuable
 if it's not a direct port of dmd's lexer).

Yeah, I get the point, but I feel that I could port most trivial changes from DMD's lexer to lexer.d. The layout of the code is different, of course, but I'm borrowing most of the lexing logic from DMD. Plus with unittests, I think we could ensure things are lexing the same.
 Also, I see _zero_ value in making it support D1. If it's for D2's standard
 library, then what's the point of it lexing D1? That just complicates the
 lexer for what is essentially a legacy product. And given that the differences
 between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather
 complicated to try and do a direct port which covers both D1 and D2. It would
 probably be easier if the two were completely separate.

Well, it doesn't appear that there are that many lexical differences between D1 and D2. A few operators, a few keywords, D2 supports a few different string constants, etc... I wanted this to be usable by IDEs. Do we not want to support D2 for development? I could certainly make this D2 only.
 As for what I've done so far, I'd have to go look. I haven't touched it in a
 couple of months, I expect. There has been a lot of other stuff that I've
 needed to do, and Andrei was trying to discourage such an implementation the
 last time that I brought it up. So, I haven't exactly been in a rush to get it
 done. I'd like to do it, but I've been rather busy.

Well, if Andrei wants to flex the power of D2's templates / etc... with a parser generator then maybe we should go down that route. Andrei, what do you think? Would the lexer/parser be generated at compile time or a a regular tool that would generate the appropriate D files?
 So, if you really want to work on a potential D lexer for Phobos, that's fine,
 but I really think that it needs to be a rather direct port, and that doesn't
 sound like what you've been doing.

 - Jonathan M Davis

If we decide to scrap my idea and go a more generic route, I'd probably start working on a standard database interface. I'd like to see D become a little more web framework friendly, and a nice generic database interface is definitely a start. So, Andrei, what do you think about a lexer / parser in Phobos? Generic or a straight port?
Jul 31 2011
next sibling parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/31/2011 10:34 PM, Jonathan M Davis wrote:
 I can tell you right now that he wants a generic, template-based lexer /
 parser generator rather than a hand-written solution. He doesn't like the idea
 of the hand-written solution. And I definitely think that we should have a
 template-based lexer / parser generator. The question is whether it's also
 worth having a hand-written port of the dmd front-end's lexer and parser to
 Phobos so that we can have on official lexer and parser in Phobos which parse D
 the same way that the compiler does.

 - Jonathan M Davis

I see. In that case, my hybrid solution doesn't solve either problem ;) I'll keep my code in that branch and start on something new.
Jul 31 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-01 04:38, Johann MacDonagh wrote:
 On 7/31/2011 10:34 PM, Jonathan M Davis wrote:
 I can tell you right now that he wants a generic, template-based lexer /
 parser generator rather than a hand-written solution. He doesn't like
 the idea
 of the hand-written solution. And I definitely think that we should
 have a
 template-based lexer / parser generator. The question is whether it's
 also
 worth having a hand-written port of the dmd front-end's lexer and
 parser to
 Phobos so that we can have on official lexer and parser in Phobos
 which parse D
 the same way that the compiler does.

 - Jonathan M Davis

I see. In that case, my hybrid solution doesn't solve either problem ;) I'll keep my code in that branch and start on something new.

I think you should continue on your lexer, we need a hand-written lexer/parser in Phobos, preferably a port of the DMD front end. -- /Jacob Carlborg
Aug 01 2011
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/31/2011 09:28 PM, Johann MacDonagh wrote:
 Well, if Andrei wants to flex the power of D2's templates / etc... with
 a parser generator then maybe we should go down that route. Andrei, what
 do you think? Would the lexer/parser be generated at compile time or a a
 regular tool that would generate the appropriate D files?

Until we have fully integrated, EASY to use, and FAST lexer and parser generators, we haven't yet proven the power of CTFE technology. I don't have the time to embark on such a project for the time being. Andrei
Jul 31 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-01 04:34, Jonathan M Davis wrote:
 I can tell you right now that he wants a generic, template-based lexer /
 parser generator rather than a hand-written solution. He doesn't like the idea
 of the hand-written solution. And I definitely think that we should have a
 template-based lexer / parser generator. The question is whether it's also
 worth having a hand-written port of the dmd front-end's lexer and parser to
 Phobos so that we can have on official lexer and parser in Phobos which parse D
 the same way that the compiler does.

 - Jonathan M Davis

I think it's absolutly worth having a hand-written port of the DMD front end in Phobos. -- /Jacob Carlborg
Aug 01 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jul 31 2011
parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
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.
Aug 01 2011
parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
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).
Aug 02 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-01 03:56, Jonathan M Davis wrote:
 If we do a hand-written lexer of D for Phobos, it really should be a fairly
 direct port of the dmd front-end. It should be _somewhat_ D-ified as
 appropriate, (and the API should definitely be properly range-based and all
 that), but the implementation needs to be fairly close to dmd itself so that
 it's easy for someone to port changes and fixes back and forth between the two.
 Otherwise, they're going to get out of sync fairly easily. If we're not going
 to do a direct port, then we might as well just do the template-based lexer
 generator that Andrei and others would really like to see (which we should
 still do, but I think that the hand-written lexer is nowhere near as valuable
 if it's not a direct port of dmd's lexer).

In the long run I hope that this won't be necessary, I'm hoping that DMD will use the lexer from Phobos.
 Also, I see _zero_ value in making it support D1. If it's for D2's standard
 library, then what's the point of it lexing D1? That just complicates the
 lexer for what is essentially a legacy product. And given that the differences
 between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather
 complicated to try and do a direct port which covers both D1 and D2. It would
 probably be easier if the two were completely separate.

 As for what I've done so far, I'd have to go look. I haven't touched it in a
 couple of months, I expect. There has been a lot of other stuff that I've
 needed to do, and Andrei was trying to discourage such an implementation the
 last time that I brought it up. So, I haven't exactly been in a rush to get it
 done. I'd like to do it, but I've been rather busy.

In this case I really don't think that you should listen to Andrei.
 So, if you really want to work on a potential D lexer for Phobos, that's fine,
 but I really think that it needs to be a rather direct port, and that doesn't
 sound like what you've been doing.

 - Jonathan M Davis

-- /Jacob Carlborg
Aug 01 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-01 10:21, Jonathan M Davis wrote:
 On Monday 01 August 2011 10:12:17 Jacob Carlborg wrote:
 On 2011-08-01 03:56, Jonathan M Davis wrote:
 If we do a hand-written lexer of D for Phobos, it really should be a
 fairly direct port of the dmd front-end. It should be _somewhat_
 D-ified as appropriate, (and the API should definitely be properly
 range-based and all that), but the implementation needs to be fairly
 close to dmd itself so that it's easy for someone to port changes and
 fixes back and forth between the two. Otherwise, they're going to get
 out of sync fairly easily. If we're not going to do a direct port, then
 we might as well just do the template-based lexer generator that Andrei
 and others would really like to see (which we should still do, but I
 think that the hand-written lexer is nowhere near as valuable if it's
 not a direct port of dmd's lexer).

In the long run I hope that this won't be necessary, I'm hoping that DMD will use the lexer from Phobos.
 Also, I see _zero_ value in making it support D1. If it's for D2's
 standard library, then what's the point of it lexing D1? That just
 complicates the lexer for what is essentially a legacy product. And
 given that the differences between D1 and D2 in dmd's lexer are covered
 with #ifdefs, it would be rather complicated to try and do a direct
 port which covers both D1 and D2. It would probably be easier if the
 two were completely separate.

 As for what I've done so far, I'd have to go look. I haven't touched it
 in a couple of months, I expect. There has been a lot of other stuff
 that I've needed to do, and Andrei was trying to discourage such an
 implementation the last time that I brought it up. So, I haven't
 exactly been in a rush to get it done. I'd like to do it, but I've been
 rather busy.

In this case I really don't think that you should listen to Andrei.

Well, when I have multiple things on my plate, and Andrei has a major disagreement with one, I'm less likely to focus on that one. It's also one which takes quite a bit of time and focus, whereas there is other stuff which I can do in smaller chunks of time without needing as much focus. So, I haven't worked on it as much. I should probably remedy that, but there's quite a lot that I've been trying to get done. So, yes. I intend to do it in spite of Andrei's opinion on the matter, but lately I've been focusing on other stuff which needs doing. - Jonathan M Davis

Fair enough. -- /Jacob Carlborg
Aug 01 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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

I personally would like to see DWT (GUI library, http://dsource.org/projects/dwt) in a more finished state. These are things that need work: * Finishing the Mac OS X port * Update to later SWT versions * Fixing bugs * Port to 64bit Any help is much appreciated. Currently DWT is a low priority for me. -- /Jacob Carlborg
Jul 31 2011
parent reply Jim Hewes <jimhewes gmail.com> writes:
On 7/31/2011 3:01 AM, Jacob Carlborg wrote:
 I personally would like to see DWT (GUI library,
 http://dsource.org/projects/dwt) in a more finished state. These are
 things that need work:

 * Finishing the Mac OS X port
 * Update to later SWT versions
 * Fixing bugs
 * Port to 64bit

 Any help is much appreciated. Currently DWT is a low priority for me.

I agree with this one. I'll tell you why, hopefully without getting too long-winded. :-) I've just been a lurker here and although I like the D language haven't really used it seriously yet. Where I work, we use Visual Studio C++ for the main product. It's highly unlikely that would just get switch to using D. But we also write various small utilities and test programs that we use internally. These are almost all written in C++ with MFC. I have never been a fan of MFC. (Even from the beginning I preferred Borland's ObjectWindows.) But it has some advantages. It's a common, almost standard GUI that comes with VS and to some extent is integrated with VS. Using MFC I can produce single-file EXEs with a GUI that can be easily passed around the company internally. I can tell users to just grab one EXE, copy it to your computer and run it. Very easy for people. My point here is that these little applications are not critical and so they could be written in any language. In my company, this would be the best way for a new language to make inroads. I've written one or two utility apps in C# and haven't had any complaints. For my job I work on Windows, though I try not to be an O/S fanboy and try to treat all platforms with equal credibility. But I guess one of my peeves about open source and Linux (which seem to go together) is that for any target goal there are a hundred half-finished, abandoned projects. I assume this is because people don't get paid to do it and so once they get tired of it they move on to other more interesting things. I can't depend on that or sell it to my colleagues. Take a look at the GUI page on the D wiki. There are a lot of projects, but almost all of them seem to be either in alpha or beta stage or are abandoned. Further, in every project, each developer usually chose to use some different array of tools that I need to download and install in my computer just to build his project. This gets kind of annoying on Windows. I've recently downloaded the QtD binding to take a look because Qt seem to be a pretty popular cross-platform library. I was able to build it and then also build a couple of the sample projects, although I haven't really spent time with it beyond that. It seems that not only is a Hello World program a 1.7MB executable, but I think I would also need to distribute the libcpp_core.dll and libcpp_gui.dll files with it for a total of about 17MB. QtD looks like a lot of good work and I don't mean to knock it here. I just mean to say that in contrast what would be nice is a “standard” GUI written in D that could be statically linked and would be not too large. I confess I have not tried the existing DWT yet, mostly since I just didn't want to also download Tango. Jim
Jul 31 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-07-31 21:06, Jim Hewes wrote:
 On 7/31/2011 3:01 AM, Jacob Carlborg wrote:
 I personally would like to see DWT (GUI library,
 http://dsource.org/projects/dwt) in a more finished state. These are
 things that need work:

 * Finishing the Mac OS X port
 * Update to later SWT versions
 * Fixing bugs
 * Port to 64bit

 Any help is much appreciated. Currently DWT is a low priority for me.

I agree with this one. I'll tell you why, hopefully without getting too long-winded. :-) I've just been a lurker here and although I like the D language haven't really used it seriously yet. Where I work, we use Visual Studio C++ for the main product. It's highly unlikely that would just get switch to using D. But we also write various small utilities and test programs that we use internally. These are almost all written in C++ with MFC. I have never been a fan of MFC. (Even from the beginning I preferred Borland's ObjectWindows.) But it has some advantages. It's a common, almost standard GUI that comes with VS and to some extent is integrated with VS. Using MFC I can produce single-file EXEs with a GUI that can be easily passed around the company internally. I can tell users to just grab one EXE, copy it to your computer and run it. Very easy for people. My point here is that these little applications are not critical and so they could be written in any language. In my company, this would be the best way for a new language to make inroads. I've written one or two utility apps in C# and haven't had any complaints.

That's understandable.
 For my job I work on Windows, though I try not to be an O/S fanboy and
 try to treat all platforms with equal credibility. But I guess one of my
 peeves about open source and Linux (which seem to go together) is that
 for any target goal there are a hundred half-finished, abandoned
 projects. I assume this is because people don't get paid to do it and so
 once they get tired of it they move on to other more interesting things.
 I can't depend on that or sell it to my colleagues. Take a look at the
 GUI page on the D wiki. There are a lot of projects, but almost all of
 them seem to be either in alpha or beta stage or are abandoned. Further,
 in every project, each developer usually chose to use some different
 array of tools that I need to download and install in my computer just
 to build his project. This gets kind of annoying on Windows.

I fully agree with that and it's annoying. The wiki page could probably use some cleanup. About the tools, I'm working on a package manager for D that will ease installation of D libraries, tools and application. I and at least one other person is working on a build tool with the hope that we can all agree on one standard built tool for D.
 I've recently downloaded the QtD binding to take a look because Qt seem
 to be a pretty popular cross-platform library. I was able to build it
 and then also build a couple of the sample projects, although I haven't
 really spent time with it beyond that. It seems that not only is a Hello
 World program a 1.7MB executable, but I think I would also need to
 distribute the libcpp_core.dll and libcpp_gui.dll files with it for a
 total of about 17MB. QtD looks like a lot of good work and I don't mean
 to knock it here. I just mean to say that in contrast what would be nice
 is a “standard” GUI written in D that could be statically linked and
 would be not too large. I confess I have not tried the existing DWT yet,
 mostly since I just didn't want to also download Tango.

 Jim

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. -- /Jacob Carlborg
Aug 01 2011
parent reply "Jim Hewes" <jimhewes gmail.com> writes:
"Jacob Carlborg" <doob me.com> wrote in message 
news:j15kug$1v62$1 digitalmars.com...
 On 2011-07-31 21:06, Jim Hewes wrote:

 For my job I work on Windows, though I try not to be an O/S fanboy and
 try to treat all platforms with equal credibility. But I guess one of my
 peeves about open source and Linux (which seem to go together) is that
 for any target goal there are a hundred half-finished, abandoned
 projects. I assume this is because people don't get paid to do it and so
 once they get tired of it they move on to other more interesting things.
 I can't depend on that or sell it to my colleagues. Take a look at the
 GUI page on the D wiki. There are a lot of projects, but almost all of
 them seem to be either in alpha or beta stage or are abandoned. Further,
 in every project, each developer usually chose to use some different
 array of tools that I need to download and install in my computer just
 to build his project. This gets kind of annoying on Windows.

I fully agree with that and it's annoying. The wiki page could probably use some cleanup. About the tools, I'm working on a package manager for D that will ease installation of D libraries, tools and application. I and at least one other person is working on a build tool with the hope that we can all agree on one standard built tool for D.

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. 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.
 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
Aug 01 2011
parent Jacob Carlborg <doob me.com> writes:
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
Aug 02 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
I would like to see something similar to Boost Graph Library for D.
Jul 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 31 July 2011 12:01:02 Alex R=C3=B8nne Petersen wrote:
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related libraries=


=20
 That looks nice. Are there any plans for OpenCL support?
=20
 I think someone is working on this.

I know of the Goldie project. Is this it?

Off and on, I've been working on porting dmd's lexer to D for Phobos, b= ut I've=20 had enough else going on, that I haven't gotten much done on it of late= . And=20 there is some controversy on the matter, because Andrei and others want= a=20 lexer/parser generator in Phobos rather than a hand-written lexer and p= arser.=20 Both are of value though. So, I don't know what we'll end up with in th= e end.=20 I'm not aware of anyone working on a lexer or parser generator for Phob= os=20 though. Goldie is the closest to that sort of thing that there is at th= e=20 moment. I think that Jacob was referring to my efforts to port the dmd = lexer=20 though. - Jonathan M Davis
Jul 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 31 July 2011 12:28:29 Alex R=C3=B8nne Petersen wrote:
 On 31-07-2011 12:24, Jonathan M Davis wrote:
 On Sunday 31 July 2011 12:01:02 Alex R=C3=B8nne Petersen wrote:
 On 31-07-2011 11:57, Jacob Carlborg wrote:
 Have a look at Derelict: http://dsource.org/projects/derelict/
 It wraps OpenGL, OpenAL and other game/multimedia related librari=




=20
 That looks nice. Are there any plans for OpenCL support?
=20
 I think someone is working on this.

I know of the Goldie project. Is this it?

Off and on, I've been working on porting dmd's lexer to D for Phobo=


 but I've had enough else going on, that I haven't gotten much done =


 it of late. And there is some controversy on the matter, because An=


 and others want a lexer/parser generator in Phobos rather than a
 hand-written lexer and parser. Both are of value though. So, I don'=


 know what we'll end up with in the end. I'm not aware of anyone wor=


 on a lexer or parser generator for Phobos though. Goldie is the clo=


 to that sort of thing that there is at the moment. I think that Jac=


 was referring to my efforts to port the dmd lexer though.
=20
 - Jonathan M Davis

A generator is what I had in mind - it would allow users to more easi=

 approach parsing, I think. Hand-written parsers have a much greater
 learning curve.
=20
 I do agree on both ideas though; a built-in parser for D would probab=

 be pretty useful to have for extracting information from D source cod=

=20
 An interesting exercise would be generating a lexer/parser via CTFE a=

 mixins. :) Perhaps we don't really need dlex/dyacc tools if we could =

 something like that.

The idea behind the hand-written D lexer (and eventually parser) for D = is that=20 it follows the implementation of the compiler's front-end, and so using= it to=20 process D code will have the same result as running the compiler. It ob= viously=20 doesn't scale beyond D itself. If you have a lexer generator and/or parser parser generator, then you = can get=20 it to generate a lexer or parser for any grammar that you want. So, it = covers=20 a different use case - which is why both are of value. Personally, I'd probably want to write a parser by hand anyway, since t= here=20 are definite advantages in doing so, but there's no reason why Phobos s= houldn't=20 have a generator for that for those who want it. Someone still needs to= write=20 it though. - Jonathan M Davis
Jul 31 2011
prev sibling next sibling parent reply simendsjo <simendsjo gmail.com> writes:
On 31.07.2011 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

From the top of my head, in no particular order: * xml * csv * ini * logging * database interface * serialization * parsing / easier to create external dsl's - antlr port? * smtp * uri - a complete uri implementation, not the simple validation that exists now * wsdl - far from everything is REST * ftp (this is perhaps included with curl?) * globalization - languages, number formats etc. * gui - perhaps not best done in phobos, but it's difficult to get up and running to say the least.. * html producer * html parser * cgi/fastcgi * cryptography * oauth And some windows specifics: * "complete" win32 bindings - move the win32 project to etc/c/win32? * better com integration (like http://dsource.org/projects/juno)
Jul 31 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-07-31 13:13, simendsjo wrote:
 - Jonathan M Davis

From the top of my head, in no particular order: * serialization

Orange: http://dsource.org/projects/orange/ There are already a quite usable version available. But now I'm currently rewriting most of the library to support more types, among other things.
 * gui - perhaps not best done in phobos, but it's difficult to get up
 and running to say the least..

DWT: http://dsource.org/projects/dwt Needs: * Bug fixes * Finish the Mac OS X port * Update to later SWT versions * Port to 64bit * More developers -- /Jacob Carlborg
Jul 31 2011
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 31/07/2011 06: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

Async I/O. -- Robert http://octarineparrot.com/
Jul 31 2011
prev sibling next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 31/07/11 6:27 AM, 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

My wish list: - A good allocator model and integration with standard containers - Fast vector math library suitable for games.
Jul 31 2011
parent reply Brian Hay <bhay construct3d.com> writes:
On 31/07/2011 9:51 PM, Peter Alexander wrote:
 My wish list:

 - A good allocator model and integration with standard containers
 - Fast vector math library suitable for games.

+1 vector math lib.
Jul 31 2011
parent filgood <filgood somewhere.net> writes:
On 31/07/2011 22:15, Brian Hay wrote:
 On 31/07/2011 9:51 PM, Peter Alexander wrote:
 My wish list:

 - A good allocator model and integration with standard containers
 - Fast vector math library suitable for games.

+1 vector math lib.

phobos after GSOC project) also: standard database lib (including bindings for postgresql, sqlite, etc) gui lib (DWT2?) thanks, filgood
Aug 01 2011
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s article
 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 could really use a linear algebra library, but the GSoC project I'm mentoring is oriented towards creating one and it's now close to usable. (I'd like to thank Cristi Cobzarenco for doing a great job on his GSoC project so far.) Next in line would be high-level MPI wrappers, like boost::mpi, or something functionally similar, like a std.concurrency that works across multiple address spaces. std.parallelism works great for SMP parallelism (which is what it was designed to do), but sometimes I want an easy way to parallelize stuff across address spaces, too.
Jul 31 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 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.

This is not a complete list, I have surely forgotten some interesting things. Some things in modules already present: - Few more higher order functions like amap/afilter/table, something to build an associative array, a redesigned max/min, ecc; - Few more math functions like isLog2, intSqrt, intCubeRoot, etc; - Lazy permutations, combinations, etc; - Few more handy collections, like a stack, deque, hashSet, treeSet, growable circular queue, Union-Find; - Maybe even Range Minimum Query; - Two or three more types of Heaps (like the Fibonacci one); - A very lazy prime number generator range; - A flexible tagged pointer (a struct); - A hierarchical manual memory allocator; - Few more functionalities for std_bitmanip.BitArray and std.bitmanip.bitfields; - Weak references; - A prettyPrinter function; - Tuple slicing and joining; - Some standard exceptions; - In Bugzilla I have some enhancement requests where sometimes I have added the code for a new functions I'd like to be added. Few new modules: - std.graphics: small graphics module, useful for simple quick things and to define a standard basic interface for other graphic D libraries; - std.image: module to read and write png, jpeg, gif, bmp, ppm images; - std.graph: Graph module, with some useful algorithms (BFS, shortest path, connected components, etc). This is also useful to fix an API for external graph packages too; - std.geometry: A small geometry module with very fast 2D, 3D and 4D vectors (for 3D graphics, games, etc), convex hull algorithm, polygon centroid algorithm, to avoid reinventing the wheel every day; - std.operator: standard operators as functions, to be used with higher order functions; - std.icollections: few immutable collections, to be used in parallel code or for safety. Maybe they need their own module. Tools added to the standard distribution: - A statistical profiler like http://h3.gd/code/xfProf/ Bye, bearophile
Jul 31 2011
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:j13mhm$1prf$1 digitalmars.com...
 - std.image: module to read and write png, jpeg, gif, bmp, ppm images;

That'd be very nice to have in phobos.
Aug 01 2011
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/30/2011 10:27 PM, Jonathan M Davis wrote:
 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?

Better Unicode support. http://training.perl.com/OSCON2011/index.html
Jul 31 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Some template/mixin functions which ease generating C or C++ bindings.
Same goes for DLLs.
Jul 31 2011
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Jul 31, 11 13: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

1. An officially endorsed XML *and* HTML library that supports Xpath. Preferably with an interface as easy to use as Python's lxml. I don't know how long the current std.xml will stay, if it's upon rewrite please do consider supporting Xpath (or CSS3 selector). (lxml is based on libxml2 and libxslt which are MIT license and may not be compatible with Boost; lxml's source code itself is in BSD) 2. More containers, including: - std.container.HashTable (or allow void[T] in the language). - std.container.List (doubly linked list) - std.container.Deque - std.container.IntervalSet - std.container.Trie (or PatriciaTrie) - Adaptors to RedBlackTree and HashTable, making it a Set, Dictionary (map) and CountedSet (bag/multiset). - Ordered associative array 3. A std.variant.Algebraic that does not rely on typeid (like C++'s Boost.Variant). 4. Wrapper to GSL (= GNU Scientic Library, GPL of course). 5. Unicode normalization (the NFKD stuff) and other Unicode support, preferably as a wrapper to ICU (non-restrictive license: http://source.icu-project.org/repos/icu/icu/trunk/license.html). 6. Rational numbers (std.fraction?). 7. Serialization library (yes I know there's Orange). 8. Support for CSV and plist 9. More pure/ safe/const :)
Jul 31 2011
prev sibling next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
--20cf3054a57b3bcf4504a965919b
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jul 31, 2011 at 6:13 AM, simendsjo <simendsjo gmail.com> wrote:

 On 31.07.2011 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

From the top of my head, in no particular order: * xml * csv * ini * logging * database interface * serialization * parsing / easier to create external dsl's - antlr port? * smtp * uri - a complete uri implementation, not the simple validation that exists now * wsdl - far from everything is REST * ftp (this is perhaps included with curl?) * globalization - languages, number formats etc. * gui - perhaps not best done in phobos, but it's difficult to get up and running to say the least.. * html producer * html parser * cgi/fastcgi * cryptography * oauth And some windows specifics: * "complete" win32 bindings - move the win32 project to etc/c/win32? * better com integration (like http://dsource.org/projects/**juno<http://dsource.org/projects/juno> )

FTP, HTTP, and SMTP are the protocols that are included in etc.curl. --20cf3054a57b3bcf4504a965919b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sun, Jul 31, 2011 at 6:13 AM, simends= jo <span dir=3D"ltr">&lt;<a href=3D"mailto:simendsjo gmail.com">simendsjo g= mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">On <a href=3D"tel:31.07.2011%2007" value=3D"+13107201107"= target=3D"_blank">31.07.2011 07</a>:27, Jonathan M Davis wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I think that it would be useful to query the community for what piece of<br=

e to<br> see. For instance, there is no official logging framework in D or any 3rd p= arty<br> libraries which do it AFAIK. So, that could be one type of functionality th= at<br> you may like to see. Now, there is a prospective implementation for std.log= <br> which shouldn&#39;t be all that far away from being reviewed, so listing th= at here<br> wouldn&#39;t be all that useful, since it&#39;s on its way. But what other = major<br> functionality do you miss in D that other languages&#39; that you use have<= br> available in their libraries?<br> <br> My hope here would be that we could get some good ideas going here such tha= t<br> we have can have a better idea what type of functionality it would be<br> particularly useful to be working on for Phobos or 3rd party D libraries fo= r<br> the community, and maybe it&#39;ll even get some people to actually go and = work on<br> these ideas so that we can improve the libraries that we have to work with = in<br> D. We can always use more help, and we definitely need a richer library<br> ecosystem for D. But even just discussing ideas could be of benefit.<br> <br> So, what major functionality which we don&#39;t currently have would you li= ke to<br> see in either Phobos or in a 3rd party library so that you could use it in<= br> your D programs?<br> <br> - Jonathan M Davis<br> </blockquote> <br></div>
From the top of my head, in no particular order:<br>

* csv<br> * ini<br> * logging<br> * database interface<br> * serialization<br> * parsing / easier to create external dsl&#39;s - antlr port?<br> * smtp<br> * uri - a complete uri implementation, not the simple validation that exist= s now<br> * wsdl - far from everything is REST<br> * ftp (this is perhaps included with curl?)<br> * globalization - languages, number formats etc.<br> * gui - perhaps not best done in phobos, but it&#39;s difficult to get up a= nd running to say the least..<br> * html producer<br> * html parser<br> * cgi/fastcgi<br> * cryptography<br> * oauth<br> <br> And some windows specifics:<br> * &quot;complete&quot; win32 bindings - move the win32 project to etc/c/win= 32?<br> * better com integration (like <a href=3D"http://dsource.org/projects/juno"= target=3D"_blank">http://dsource.org/projects/<u></u>juno</a>)<br></blockq= uote><div><br></div><div><br></div><div>FTP, HTTP, and SMTP are the protoco= ls that are included in etc.curl.</div> </div><br> --20cf3054a57b3bcf4504a965919b--
Jul 31 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Btw why not take DDMD's lexer.d and start from there?
Jul 31 2011
prev sibling next sibling parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/31/2011 1:27 AM, 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

My top 3: 1. Database interface. Should support sqlite, mysql, postgres, etc... 2. DWT fixed up and merged into Phobos. 3. Some kind of web framework.
Jul 31 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Johann MacDonagh" <johann.macdonagh.no 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.
Aug 01 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/1/11 4:35 PM, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no 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
Aug 01 2011
next sibling parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Andrei Alexandrescu Wrote:

 On 8/1/11 4:35 PM, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no 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. 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.
Aug 01 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-02 01:48, Jesse Phillips wrote:
 Andrei Alexandrescu Wrote:

 On 8/1/11 4:35 PM, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no 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
Aug 02 2011
prev sibling next sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Mon, 1 Aug 2011, Andrei Alexandrescu wrote:

 On 8/1/11 4:35 PM, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no 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

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
Aug 01 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/1/11 7:51 PM, Brad Roberts wrote:
 On Mon, 1 Aug 2011, Andrei Alexandrescu wrote:

 On 8/1/11 4:35 PM, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no 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

I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard.

Python has something and as far as I can tell people are fine with that. Andrei
Aug 01 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Aug 01 2011
parent reply Jos van Uden <user domain.invalid> writes:
On 2-8-2011 4:48, Adam D. Ruppe wrote:
 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.

+1 I'd very much like to see this implemented.
Aug 04 2011
parent reply Mehrdad <wfunction hotmail.com> writes:
More powerful regexes (like in .NET).

The current one is pretty much unusable due to lack of support for
Unicode, and lacks lots of important features (named captures come to
mind).
Aug 04 2011
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 04.08.2011 19:50, Mehrdad wrote:
 More powerful regexes (like in .NET).

 The current one is pretty much unusable due to lack of support for
 Unicode, and lacks lots of important features (named captures come to
 mind).

I'm working on a replacement engine as GSOC project, both named captures and modern Unicode support are implemented. I plan to wrap up a public beta by the next week, to get some early feedback. In terms of speed in general it seems to be on par with PCRE, but I haven't done any pattern-specific tuning (which PCRE surely does). I looked over all what .NET supports, and right now new engine has support for the most of it's syntactic riches (including character set operations) albeit with slightly different syntax. Exceptions: (?(expression)yes| no) which looks like a hack, (?# comment) and setting flags in midair (?im). I'll definitely add free spacing syntax mode (see perl) and setting flags though. Anyway, if you are wondering if I missed any other cool regex feature, just ask :) -- Dmitry Olshansky
Aug 04 2011
parent Mehrdad <wfunction hotmail.com> writes:
On 8/4/2011 10:23 AM, Dmitry Olshansky wrote:
 On 04.08.2011 19:50, Mehrdad wrote:
 More powerful regexes (like in .NET).

 The current one is pretty much unusable due to lack of support for
 Unicode, and lacks lots of important features (named captures come to
 mind).

I'm working on a replacement engine as GSOC project, both named captures and modern Unicode support are implemented. I plan to wrap up a public beta by the next week, to get some early feedback. In terms of speed in general it seems to be on par with PCRE, but I haven't done any pattern-specific tuning (which PCRE surely does). I looked over all what .NET supports, and right now new engine has support for the most of it's syntactic riches (including character set operations) albeit with slightly different syntax. Exceptions: (?(expression)yes| no) which looks like a hack, (?# comment) and setting flags in midair (?im). I'll definitely add free spacing syntax mode (see perl) and setting flags though. Anyway, if you are wondering if I missed any other cool regex feature, just ask :)

Aug 04 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Brad Roberts:
 I don't think that any gui library belongs in phobos because there's
 essentially no agreement about what cross-platform library is standard.

Python has something and as far as I can tell people are fine with that.

The situation is quite complex, some notes: - CPython indeed has a GUI toolkit in the standard distribution, it's not native, it's a whole different interpreter with its GUI toolkit (Tcl-Tk), with a thin Python wrapper around it (tkinter). Despite looking like a card castle this somehow works and some people (like me) use this GUI toolkit to write simple GUIs. Scientific programs sometimes enjoy such simple GUIs. - For a lot of time the GUIs created with tkinter didn't look native at all (the GUI were almost ugly (recently Tk has improved a lot on this, now it looks much more native)). And Tk despite having some qualities (efficiency, compactness, flexibility and more), was also limited and "strange" in its usage (it's like working with soft rubber). So people that want to create serious GUIs for Python programs never use tkinter. They use GTK, Wx and lately Qt. So using Python as comparison point for D GUI toolkits in the std library is not the best thing to do, because in a sense the Python std library GUI toolkit is not used by serious people. - I like the idea of having a wide D standard library. But GUI toolkits are large, and they change a lot with time, so I accept to have them as external libraries. - Delphi has a good enough built-in GUI toolkit, and people use it a lot. I have used it plenty. This seems a better comparison point for D. - I'd like a simple graphics module in Phobos, to show simple graphics. It's handy in many situations, and it's useful to establish *standard D-wide* method/function names to plot a point, a line, circle, box, ecc. The same names can later appear in non-Phobos GUI toolkits. - 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. Bye, bearophile
Aug 01 2011
prev sibling next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Brad Roberts wrote:

 On Monday, August 01, 2011 7:31:13 PM, Andrei Alexandrescu wrote:
 On 8/1/11 7: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.

Python has something and as far as I can tell people are fine with that. Andrei

It has something _in the base library_? It has wrappers for all/most of the popular libraries? The standard distributions install some combination of those? I don't use python so I'm ill equipped to discuss, but my guess is that it's not the first but rather the last.

It only has a wrapper for the Tkinter (from Tcl/Tk). I don't think a lot of people use it for serious stuff, it's kinda ancient. A lot of people use the Qt bindings though - these are not in the standard library.
Aug 02 2011
prev sibling parent user <user office.com> writes:
 I don't think that any gui library belongs in phobos because there's
 essentially no agreement about what cross-platform library is standard.

Python has something and as far as I can tell people are fine with that. Andrei

You guys have no idea, how much its hurting D. At my work place, we wanted to quickly develop a small gui tool, considered python and D, guess which we picked? pyhton, just because tkInter comes packaged with python, even though it sucks. Now tkInter in python became the official gui lib for such tools! -Sai
May 09 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/2/11 10:25 AM, so wrote:
 On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts
 <braddr 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
Aug 02 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Aug 02 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-02 21:48, Walter Bright wrote:
 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.

Yes, that was very unfortunate that basically when you announced DWT (the old one) as the standard GUI library the development stopped. -- /Jacob Carlborg
Aug 02 2011
prev sibling next sibling parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
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.
Aug 02 2011
prev sibling next sibling parent reply Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Jimmy Cao wrote:

 2011/8/2 so <so so.so>
 
 On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts <
 braddr 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

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.

I really doubt that. You don't get to really compete with C# until D runs on .NET and perhaps even until microsoft adopts it. I don't think a standard gui lib will make any difference.
Aug 02 2011
parent KennyTM~ <kennytm gmail.com> writes:
On Aug 3, 11 13:53, Lutger Blijdestijn wrote:
 Jimmy Cao wrote:

 2011/8/2 so<so so.so>

 On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts<
 braddr 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

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.

I really doubt that. You don't get to really compete with C# until D runs on .NET and perhaps even until microsoft adopts it. I don't think a standard gui lib will make any difference.

There was a D.net (which seems no longer updated), and when D runs on .NET, the language can use all .NET libraries like WinForms and WPF immediately, and there's no need to have another GUI lib. (And why D needs to compete against C#?)
Aug 03 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-02 19:58, Jimmy Cao wrote:
 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).

I think that would make most sense. -- /Jacob Carlborg
Aug 02 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-02 00:34, Andrei Alexandrescu wrote:
 On 8/1/11 4:35 PM, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no 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
Aug 02 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Jacob Carlborg" <doob 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??
Aug 02 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-02 21:57, Nick Sabalausky wrote:
 "Jacob Carlborg"<doob 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??

I'm just listing was officially supported with binary releases. I don't see a reason why GTK on BSD wouldn't work. -- /Jacob Carlborg
Aug 02 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-01 23:35, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no 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
Aug 02 2011
prev sibling parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 8/1/2011 5:35 PM, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no 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.
Aug 02 2011
parent reply Adam Ruppe <destructionator gmail.com> writes:
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.)
Aug 02 2011
parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
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.
Aug 02 2011
next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
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.
Aug 02 2011
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
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.
Aug 02 2011
parent reply Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
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.
Aug 02 2011
parent Adam D. Ruppe <destructionator gmail.com> writes:
Johann MacDonagh  wrote:
 Do you know of any other database interfaces people have been working on?

Not off the top of my head.
Aug 02 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 01 August 2011 03:31:41 Andrej Mitrovic wrote:
 Btw why not take DDMD's lexer.d and start from there?

It's a possibility but has 2 downsides to it. 1. Due to licensing issues, you have to get permission from the ddmd developers. The front-end is LGPL IIRC, not Boost. Walter gave permission to port the lexer from the front-end to D and make it Boost, but that doesn't hold for the ddmd code, which was taken from dmd's front-end and ported by other folks. So, their permission would be required. It's not necessarily a big deal, but it is something that needs to be dealt with. 2. To really do it right, you need to understand how it works. Personally, I think that doing all the work of porting it is going to help a _lot_ in gaining that understanding. If all you do is take and adjust the ddmd code, then you don't gain that understanding. So, ddmd's source code definitely could be used as the base for Phobos' D lexer, but I haven't taken the time to deal with #1, and because of #2, I find it very valuable to do the porting myself. I haven't gotten very far on of it of late though. Taking ddmd and adjusting would probably be faster, but as a maintainer of the result, it would be harder to maintain just because I wouldn't understand it as well. - Jonathan M Davis
Jul 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 31 July 2011 21:29:31 Johann MacDonagh wrote:
 On 7/31/2011 5:57 AM, Jacob Carlborg wrote:
 * Lexing and parsing:
 
 Standard facilities for these tasks could be very useful. Perhaps D
 could get its own dlex and dyacc or some such tools. Personally, I
 prefer sticking to LL(1), but LALR is generally more convenient and
 flexible, and thus I'd suggest something YACC/ANTLR-like.
 
 (I know this doesn't have much to do with Phobos per se, but I figured
 I'd mention it.)

I think someone is working on this.

I've started on a port of DMD's lexer (not really a port ;) ): https://github.com/jmacdonagh/phobos/compare/master...std.lang.d.lexer 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). Some features I'm planning: 1. Support D1 and D2. 2. Warnings and errors returned in the tokens. For example, if you use an octal constant for D2 code, it will correctly return an integer constant token with some kind of warning flag set and a message. In terms of errors, if the lexer hits "0xz012", it will return an error token for the slice "0xz" and then start lexing an integer constant "012". No exceptions, easy peasy. 3. CTFEable. Although I'll probably have to wait till the next DMD release. 4. Support any kind of character range. Not sure if people want to lex something that's not a string/wstring/dstring. I'm glad this was brought up. I remember Walter's post last year asking for this module, but the conversation seemed to kill the idea. I started on this just for the fun of it, but then doubted whether Phobos wanted it. I feel that a hand written lexer / parser is going to be faster than something generated, but maybe I'm old fashioned. Anyway, Jim, if you want to do this I can move on to something else. If you want, I can continue on. I didn't see a branch in your repo so I'm not sure what you've done.

If we do a hand-written lexer of D for Phobos, it really should be a fairly direct port of the dmd front-end. It should be _somewhat_ D-ified as appropriate, (and the API should definitely be properly range-based and all that), but the implementation needs to be fairly close to dmd itself so that it's easy for someone to port changes and fixes back and forth between the two. Otherwise, they're going to get out of sync fairly easily. If we're not going to do a direct port, then we might as well just do the template-based lexer generator that Andrei and others would really like to see (which we should still do, but I think that the hand-written lexer is nowhere near as valuable if it's not a direct port of dmd's lexer). Also, I see _zero_ value in making it support D1. If it's for D2's standard library, then what's the point of it lexing D1? That just complicates the lexer for what is essentially a legacy product. And given that the differences between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather complicated to try and do a direct port which covers both D1 and D2. It would probably be easier if the two were completely separate. As for what I've done so far, I'd have to go look. I haven't touched it in a couple of months, I expect. There has been a lot of other stuff that I've needed to do, and Andrei was trying to discourage such an implementation the last time that I brought it up. So, I haven't exactly been in a rush to get it done. I'd like to do it, but I've been rather busy. So, if you really want to work on a potential D lexer for Phobos, that's fine, but I really think that it needs to be a rather direct port, and that doesn't sound like what you've been doing. - Jonathan M Davis
Jul 31 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Are you sure it's LGPL? There's two licenses AFAIK, GPL and Artistic.
I'm not seeing any mention of LGPL in the code.
Jul 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 01 August 2011 04:03:11 Andrej Mitrovic wrote:
 Are you sure it's LGPL? There's two licenses AFAIK, GPL and Artistic.
 I'm not seeing any mention of LGPL in the code.

It could be GPL. I don't remember whether it's GPL or LGPL, but it doesn't really matter as far as Phobos goes. It needs to be Boost for Phobos, and Walter gave his permission to port dmd's lexer over to D with the Boost license, and no such permission has been given from the ddmd guys. Now, I haven't asked for it yet either. It hasn't been high enough on my priority list to deal with that yet, and I want to do the majority of the port myself to ensure that I understand it. Looking at ddmd and possibly copying some of what it did would be helpful, so I'd like to get the permission thing sorted out with ddmd if possible. I just haven't taken the time to do it. Regardless, the point is that dmd and ddmd are not under Boost - regardless of whether they're under GPL or LGPL - and without permission from the appropriate copyright holders, a port can't be moved to Boost. - Jonathan M Davis
Jul 31 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Licenses are the greatest code smell.
Jul 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 31 July 2011 22:28:51 Johann MacDonagh wrote:
 On 7/31/2011 9:56 PM, Jonathan M Davis wrote:
 If we do a hand-written lexer of D for Phobos, it really should be a
 fairly direct port of the dmd front-end. It should be _somewhat_
 D-ified as appropriate, (and the API should definitely be properly
 range-based and all that), but the implementation needs to be fairly
 close to dmd itself so that it's easy for someone to port changes and
 fixes back and forth between the two. Otherwise, they're going to get
 out of sync fairly easily. If we're not going to do a direct port, then
 we might as well just do the template-based lexer generator that Andrei
 and others would really like to see (which we should still do, but I
 think that the hand-written lexer is nowhere near as valuable if it's
 not a direct port of dmd's lexer).

Yeah, I get the point, but I feel that I could port most trivial changes from DMD's lexer to lexer.d. The layout of the code is different, of course, but I'm borrowing most of the lexing logic from DMD. Plus with unittests, I think we could ensure things are lexing the same.
 Also, I see _zero_ value in making it support D1. If it's for D2's
 standard library, then what's the point of it lexing D1? That just
 complicates the lexer for what is essentially a legacy product. And
 given that the differences between D1 and D2 in dmd's lexer are covered
 with #ifdefs, it would be rather complicated to try and do a direct
 port which covers both D1 and D2. It would probably be easier if the
 two were completely separate.

Well, it doesn't appear that there are that many lexical differences between D1 and D2. A few operators, a few keywords, D2 supports a few different string constants, etc... I wanted this to be usable by IDEs. Do we not want to support D2 for development? I could certainly make this D2 only.
 As for what I've done so far, I'd have to go look. I haven't touched it
 in a couple of months, I expect. There has been a lot of other stuff
 that I've needed to do, and Andrei was trying to discourage such an
 implementation the last time that I brought it up. So, I haven't
 exactly been in a rush to get it done. I'd like to do it, but I've been
 rather busy.

Well, if Andrei wants to flex the power of D2's templates / etc... with a parser generator then maybe we should go down that route. Andrei, what do you think? Would the lexer/parser be generated at compile time or a a regular tool that would generate the appropriate D files?
 So, if you really want to work on a potential D lexer for Phobos, that's
 fine, but I really think that it needs to be a rather direct port, and
 that doesn't sound like what you've been doing.
 
 - Jonathan M Davis

If we decide to scrap my idea and go a more generic route, I'd probably start working on a standard database interface. I'd like to see D become a little more web framework friendly, and a nice generic database interface is definitely a start. So, Andrei, what do you think about a lexer / parser in Phobos? Generic or a straight port?

I can tell you right now that he wants a generic, template-based lexer / parser generator rather than a hand-written solution. He doesn't like the idea of the hand-written solution. And I definitely think that we should have a template-based lexer / parser generator. The question is whether it's also worth having a hand-written port of the dmd front-end's lexer and parser to Phobos so that we can have on official lexer and parser in Phobos which parse D the same way that the compiler does. - Jonathan M Davis
Jul 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 31 July 2011 22:28:51 Johann MacDonagh wrote:
 On 7/31/2011 9:56 PM, Jonathan M Davis wrote:
 If we do a hand-written lexer of D for Phobos, it really should be a
 fairly direct port of the dmd front-end. It should be _somewhat_
 D-ified as appropriate, (and the API should definitely be properly
 range-based and all that), but the implementation needs to be fairly
 close to dmd itself so that it's easy for someone to port changes and
 fixes back and forth between the two. Otherwise, they're going to get
 out of sync fairly easily. If we're not going to do a direct port, then
 we might as well just do the template-based lexer generator that Andrei
 and others would really like to see (which we should still do, but I
 think that the hand-written lexer is nowhere near as valuable if it's
 not a direct port of dmd's lexer).

Yeah, I get the point, but I feel that I could port most trivial changes from DMD's lexer to lexer.d. The layout of the code is different, of course, but I'm borrowing most of the lexing logic from DMD. Plus with unittests, I think we could ensure things are lexing the same.
 Also, I see _zero_ value in making it support D1. If it's for D2's
 standard library, then what's the point of it lexing D1? That just
 complicates the lexer for what is essentially a legacy product. And
 given that the differences between D1 and D2 in dmd's lexer are covered
 with #ifdefs, it would be rather complicated to try and do a direct
 port which covers both D1 and D2. It would probably be easier if the
 two were completely separate.

Well, it doesn't appear that there are that many lexical differences between D1 and D2. A few operators, a few keywords, D2 supports a few different string constants, etc... I wanted this to be usable by IDEs. Do we not want to support D2 for development? I could certainly make this D2 only.

Phobos for D2 is for D2, not D1. Mixing D1 into the mix complicates things. If it's easy to tell the lexer to lex D1 or D2 without negatively impacting performance and without seriously impacting the implementation, then we can support D1. But personally, I don't think that it's worth the extra complication. The compiler separates them with ifdefs, which isn't going to work as well in Phobos. You'd probably end up having to use templates and static ifs to deal with the differences. It can be done, but I don't think that it's worth the gain. The lexer is complicated enough as it is. - Jonathan M Davis
Jul 31 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 31 July 2011 22:18:51 Andrei Alexandrescu wrote:
 On 07/31/2011 09:28 PM, Johann MacDonagh wrote:
 Well, if Andrei wants to flex the power of D2's templates / etc... with
 a parser generator then maybe we should go down that route. Andrei, what
 do you think? Would the lexer/parser be generated at compile time or a a
 regular tool that would generate the appropriate D files?

Until we have fully integrated, EASY to use, and FAST lexer and parser generators, we haven't yet proven the power of CTFE technology. I don't have the time to embark on such a project for the time being.

We need to have all of the dmd and Phobos developers in triplicate. Then maybe we could actually get everything done that we'd like to get done... Well, at least the change to github has better enabled commmunity support outside of the primary developers. So, even if still don't get it everything done that we'd like to, we're at least doing much better. - Jonathan M Davis
Jul 31 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 01.08.2011, 05:31 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 We need to have all of the dmd and Phobos developers in triplicate. Then  
 maybe we could actually get everything done that we'd like to get done...

From reading what some C++ folks think is 'forced' on them in D (making common things easy vs a low level structure covering all exotic use cases) and my experience with the RedBlackTree (it is fast but, couldn't be created empty as I am used to from other language libraries) I think it is not just about getting things done, but about brainstorming in advance. When we use containers, what use cases do we have? Programmer A wants to be able to easily switch the container implementation from an array list to a sorted tree, B requires pure speed without the overhead of virtual functions and a class hierarchy. Either A or B give in, there is room for both in Phobos or either A or B go and (re)write the containers. I believe this discussion has been here already, but I wasn't reading the list at that time. :) So what I want to say is, before someone starts writing the code for a parser generator, try to make a list of use cases. I don't say every use case must be covered, but it would be great, if there were 'entry points' for others to implement what they need. A common example is a sorted set that sorts by the natural ordering of elements, but can be augmented with a comparator function. So far we have the - general idea of a lexer/parser - a D source code parser I'd be very exited to see a CTFE solution to building a parser *g*, you know just for the awe of it. If that works out and it turns out that it is actually quite fast it *could* be used to write a D parser from definitions. But the point that you would want to keep close to the C source of DMD is strong. I wanted to write a disk cleanup tool for Linux that uses a simple special script language basically using list operations (like list all java processes -> list all files in directory x containing any processes pid -> protect them from deletion). The format consists keywords that can open new blocks that again contain other keywords, so I ended up writing parse functions for each block type. I'd go with a complete AST here instead of the linear list of tokens that has been proposed. If I wrote a syntax highlighter then the AST would not be of much use. So this could be two use cases to cover. Comments?
Aug 01 2011
prev sibling next sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
streams and network programming is most desirable, this also impacts other 
libraries. 

Another big one is async programming. Some kind of unified, higher level 
framework to deal with this could be a huge help - it's a hard problem.

It's interesting to see that in .NET a lot of new stuff concerning async 
programming is coming out, suggesting that the (many) existing patterns are 
considered inadequate. In C# 5, async operations will be a language level 
feature with the async/await keywords. There is also the reactive extensions 
library for async streams: http://msdn.microsoft.com/en-us/data/gg577609. 
Most interesting about this one is how easy it is to compose async 
operations.
Aug 01 2011
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 01 August 2011 10:12:17 Jacob Carlborg wrote:
 On 2011-08-01 03:56, Jonathan M Davis wrote:
 If we do a hand-written lexer of D for Phobos, it really should be a
 fairly direct port of the dmd front-end. It should be _somewhat_
 D-ified as appropriate, (and the API should definitely be properly
 range-based and all that), but the implementation needs to be fairly
 close to dmd itself so that it's easy for someone to port changes and
 fixes back and forth between the two. Otherwise, they're going to get
 out of sync fairly easily. If we're not going to do a direct port, then
 we might as well just do the template-based lexer generator that Andrei
 and others would really like to see (which we should still do, but I
 think that the hand-written lexer is nowhere near as valuable if it's
 not a direct port of dmd's lexer).

In the long run I hope that this won't be necessary, I'm hoping that DMD will use the lexer from Phobos.
 Also, I see _zero_ value in making it support D1. If it's for D2's
 standard library, then what's the point of it lexing D1? That just
 complicates the lexer for what is essentially a legacy product. And
 given that the differences between D1 and D2 in dmd's lexer are covered
 with #ifdefs, it would be rather complicated to try and do a direct
 port which covers both D1 and D2. It would probably be easier if the
 two were completely separate.
 
 As for what I've done so far, I'd have to go look. I haven't touched it
 in a couple of months, I expect. There has been a lot of other stuff
 that I've needed to do, and Andrei was trying to discourage such an
 implementation the last time that I brought it up. So, I haven't
 exactly been in a rush to get it done. I'd like to do it, but I've been
 rather busy.

In this case I really don't think that you should listen to Andrei.

Well, when I have multiple things on my plate, and Andrei has a major disagreement with one, I'm less likely to focus on that one. It's also one which takes quite a bit of time and focus, whereas there is other stuff which I can do in smaller chunks of time without needing as much focus. So, I haven't worked on it as much. I should probably remedy that, but there's quite a lot that I've been trying to get done. So, yes. I intend to do it in spite of Andrei's opinion on the matter, but lately I've been focusing on other stuff which needs doing. - Jonathan M Davis
Aug 01 2011
parent reply Heywood Floyd <soul8o8 gmail.com> writes:
- DBs
- Incremental GC (for real-time apps)
- Code examples!!! ..in the docs, applies to all libs, please..
Aug 01 2011
parent Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Heywood Floyd Wrote:

 - Code examples!!! ..in the docs, applies to all libs, please..

vote++ The language and library reference docs work well for learning what's possible but not at how to make it happen. TDPL is better, but it isn't really a "cookbook" either. The good news is that anyone can contribute to a set of code examples. Adding these shouldn't add to the workload of the "senior" developers. In fact learners should probably be the main contributors because they're the ones who notice what's missing. Suggest perhaps we create a page to invite contribution to code examples. There is already a "Tech Tips" page -- may be revive that. Paul
Aug 01 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 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
Aug 01 2011
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
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 2. Easy to use non-GC threads for soft real time support. Non-GC threads must not be suspended by the GC and they must support some kind of reliable communication with normal (GC) threads. This should be similar to IPC, where there's no shared memory between GC and non-GC threads. Consider running two separate programs, one written in D with GC support and one written in plain C. These programs communicate with each other using some IPC mechanism. The latter is never suspended. The whole point is to make equivalent of this configuration in a single executable using mixture of GC and non-GC threads.
Aug 01 2011
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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
Aug 02 2011
prev sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
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
Aug 02 2011
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Monday, August 01, 2011 7:31:13 PM, Andrei Alexandrescu wrote:
 On 8/1/11 7: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.

Python has something and as far as I can tell people are fine with that. Andrei

It has something _in the base library_? It has wrappers for all/most of the popular libraries? The standard distributions install some combination of those? I don't use python so I'm ill equipped to discuss, but my guess is that it's not the first but rather the last.
Aug 01 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 02.08.2011, 04:48 Uhr, schrieb Adam D. Ruppe  
<destructionator 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
Aug 01 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/2/11, Marco Leise <Marco.Leise gmx.de> wrote:
 Am 02.08.2011, 04:48 Uhr, schrieb Adam D. Ruppe
 <destructionator 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.
Aug 02 2011
prev sibling next sibling parent Jesse Phillips <jessekphillips+d gmail.com> writes:
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...
Aug 02 2011
prev sibling next sibling parent so <so so.so> writes:
On Sun, 31 Jul 2011 14:51:17 +0300, Peter Alexander  
<peter.alexander.au 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.
Aug 02 2011
prev sibling next sibling parent so <so so.so> writes:
On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts  
<braddr 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!
Aug 02 2011
prev sibling next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
--20cf3054a827bc7fa104a98781e8
Content-Type: text/plain; charset=ISO-8859-1

2011/8/2 so <so so.so>

 On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts <
 braddr 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

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. --20cf3054a827bc7fa104a98781e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/8/2 so <span dir=3D"ltr">&lt;so so.so&gt;</span><br><div class=3D"gmai= l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">On Tue, 02 Aug 2= 011 03:51:56 +0300, Brad Roberts &lt;<a href=3D"mailto:braddr slice-2.purem= agic.com" target=3D"_blank">braddr slice-2.puremagic.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I don&#39;t think that any gui library belongs in phobos because there&#39;= s<br> essentially no agreement about what cross-platform library is standard.<br> Pick any random 10 gui developers about what library they used (assuming<br=

I&#39;d<br> be shocked if you get a clear enough majority to suggest 1 that&#39;d make = a<br> big set of people happy.<br> <br> Sorry, the gui library landscape just doesn&#39;t approach being obvious<br=

<br> My 2 cents,<br> Brad<br> <br> </blockquote> <br></div> I agree, GUIs (and other huge libraries that everyone has their own favorit= e) don&#39;t belong standard library. Other languages get away with it beca= use they are either platform themselves or support only one platform.<br> Another reason not to include them to the standard library, remember phobos= has rules (we might need to change many things).<br> But if we have something small, simple and cross-platform somewhere, why no= t!<br> </blockquote></div><div><br></div><div>If a GUI library were included in Ph= obos, that would make D a much better competitor against C#. =A0That&#39;s = why I hope such an inclusion would be possible in the future. =A0I see why = it might not be possible, though.</div> --20cf3054a827bc7fa104a98781e8--
Aug 02 2011
prev sibling next sibling parent so <so so.so> writes:
On Tue, 02 Aug 2011 06:10:29 +0300, bearophile <bearophileHUGS 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.
Aug 02 2011
prev sibling next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
--20cf3071ca2c07a16e04a9879c9b
Content-Type: text/plain; charset=ISO-8859-1

2011/8/2 so <so so.so>

 On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts <
 braddr 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

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. --20cf3071ca2c07a16e04a9879c9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/8/2 so <span dir=3D"ltr">&lt;so so.so&gt;</span><br><div class=3D"gmai= l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">On Tue, 02 Aug 2= 011 03:51:56 +0300, Brad Roberts &lt;<a href=3D"mailto:braddr slice-2.purem= agic.com" target=3D"_blank">braddr slice-2.puremagic.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I don&#39;t think that any gui library belongs in phobos because there&#39;= s<br> essentially no agreement about what cross-platform library is standard.<br> Pick any random 10 gui developers about what library they used (assuming<br=

I&#39;d<br> be shocked if you get a clear enough majority to suggest 1 that&#39;d make = a<br> big set of people happy.<br> <br> Sorry, the gui library landscape just doesn&#39;t approach being obvious<br=

<br> My 2 cents,<br> Brad<br> <br> </blockquote> <br></div> I agree, GUIs (and other huge libraries that everyone has their own favorit= e) don&#39;t belong standard library. Other languages get away with it beca= use they are either platform themselves or support only one platform.<br> Another reason not to include them to the standard library, remember phobos= has rules (we might need to change many things).<br> But if we have something small, simple and cross-platform somewhere, why no= t!<br> </blockquote></div><div><br></div><div>If a GUI library were included in Ph= obos, that would make D a much better competitor against C#. =A0That&#39;s = why I hope such an inclusion would be possible in the future. =A0I see why = it might not be possible, though.</div> --20cf3071ca2c07a16e04a9879c9b--
Aug 02 2011
prev sibling next sibling parent Josh Simmons <simmons.44 gmail.com> writes:
On Tue, Aug 2, 2011 at 5:45 PM, Jacob Carlborg <doob me.com> wrote:
 On 2011-08-01 23:35, Nick Sabalausky wrote:
 "Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> =C2=A0wrote in me=


 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-languag=


 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 tha=

 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= .
Aug 02 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 02.08.2011, 17:35 Uhr, schrieb Jimmy Cao <jcao219 gmail.com>:

 2011/8/2 so <so so.so>

 On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts <
 braddr 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

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, ...) :)
Aug 02 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 02.08.2011, 17:38 Uhr, schrieb so <so so.so>:

 On Tue, 02 Aug 2011 06:10:29 +0300, bearophile  
 <bearophileHUGS 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.
Aug 02 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Aug 02 2011
parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
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.

- Alex
Aug 02 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
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.

- Alex

Something like that. -- /Jacob Carlborg
Aug 02 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rønne Petersen" <xtzgzorex 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.


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.)
Aug 02 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-02 22:01, Nick Sabalausky wrote:
 "Alex Rønne Petersen"<xtzgzorex 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.


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.)

Actually when I think about it I've written a simple library like that in C++ for a school project. I wonder if I still have it somewhere. -- /Jacob Carlborg
Aug 02 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2011 1:15 PM, Andrej Mitrovic wrote:
 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. -_-

I've used this for 25 years now. http://www.digitalmars.com/rtl/disp.html
Aug 04 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/5/2011 11:12 AM, Andrej Mitrovic wrote:
 On 8/4/11, Walter Bright<newshound2 digitalmars.com>  wrote:
 I've used this for 25 years now.

 http://www.digitalmars.com/rtl/disp.html

That's freaking great. And it's already in snn.lib. However this doesn't work on Linux, right?

Right, though porting it wouldn't be hard.
 Works great in D on win32. Thanks W.

Aug 06 2011
prev sibling next sibling parent Jimmy Cao <jcao219 gmail.com> writes:
--0023541876f88537d604a9897eda
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Aug 2, 2011 at 11:34 AM, Marco Leise <Marco.Leise gmx.de> wrote:

 Am 02.08.2011, 17:35 Uhr, schrieb Jimmy Cao <jcao219 gmail.com>:

  2011/8/2 so <so so.so>
  On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts <
 braddr 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

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!

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). --0023541876f88537d604a9897eda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 2, 2011 at 11:34 AM, Marco Leise <span dir=3D"ltr">&lt;<a href= =3D"mailto:Marco.Leise gmx.de">Marco.Leise gmx.de</a>&gt;</span> wrote:<br>= <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Am 02.08.2011, 17:35 Uhr, schrieb Jimmy Cao &lt;<a href=3D"mailto:jcao219 g= mail.com" target=3D"_blank">jcao219 gmail.com</a>&gt;:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"> 2011/8/2 so &lt;so so.so&gt;<br> <br> </div><div><div></div><div class=3D"h5"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts &lt;<br> <a href=3D"mailto:braddr slice-2.puremagic.com" target=3D"_blank">braddr sl= ice-2.puremagic.com</a>&gt; wrote:<br> <br> =A0I don&#39;t think that any gui library belongs in phobos because there&#= 39;s<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> essentially no agreement about what cross-platform library is standard.<br> Pick any random 10 gui developers about what library they used (assuming<br=

I&#39;d<br> be shocked if you get a clear enough majority to suggest 1 that&#39;d make = a<br> big set of people happy.<br> <br> Sorry, the gui library landscape just doesn&#39;t approach being obvious<br=

<br> My 2 cents,<br> Brad<br> <br> <br> </blockquote> I agree, GUIs (and other huge libraries that everyone has their own<br> favorite) don&#39;t belong standard library. Other languages get away with = it<br> because they are either platform themselves or support only one platform.<b= r> Another reason not to include them to the standard library, remember phobos= <br> has rules (we might need to change many things).<br> But if we have something small, simple and cross-platform somewhere, why<br=

<br> </blockquote> <br></div></div><div class=3D"im"> If a GUI library were included in Phobos, that would make D a much better<b= r> competitor against C#. =A0That&#39;s why I hope such an inclusion would be<= br> possible in the future. =A0I see why it might not be possible, though.<br> </div></blockquote> <br> Why is it so important that the GUI library is included in the std library?= Unless it is like Delphi, VisualBasic &amp; others that it comes with a GU= I 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, ...) = :)<br> </blockquote></div><br><div><br></div><div>You&#39;re right, it&#39;s proba= bly not that important.</div><div>I guess it&#39;s most important that a cr= oss-platform GUI library can simply be easily installed and set up (with so= me sort of D package manager).</div> --0023541876f88537d604a9897eda--
Aug 02 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Plus that would tie any updates to the GUI with DMD releases. Bad idea!
Aug 02 2011
prev sibling next sibling parent Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
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
Aug 02 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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. -_-
Aug 02 2011
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.2068.1312316161.14074.digitalmars-d 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).
Aug 02 2011
parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
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 ;)
Aug 02 2011
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 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
Aug 02 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/3/11, Nick Sabalausky <a a.a> wrote:
 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.2068.1312316161.14074.digitalmars-d 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 :/
Aug 02 2011
parent "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.2071.1312335864.14074.digitalmars-d puremagic.com...
 On 8/3/11, Nick Sabalausky <a a.a> wrote:
 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message
 news:mailman.2068.1312316161.14074.digitalmars-d 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.
Aug 02 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'll find the damn thing, gimme a day. :p
Aug 02 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
There's pdcurses which apparently works on Windows. It's public
domain. I'm not sure if this is the one that supports ASCII escape
codes though. And I haven't tested it.

Home: http://pdcurses.sourceforge.net/
Binaries: http://gnuwin32.sourceforge.net/packages/pdcurses.htm
Aug 03 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
This is interesting:

http://openil.sourceforge.net/

In particular that news post from 2010. Apparently the author might
consider changing the license if there's interest in it.
Aug 03 2011
prev sibling next sibling parent Graham Fawcett <fawcett uwindsor.ca> writes:
On Thu, 04 Aug 2011 15:50:18 +0000, Mehrdad wrote:

 More powerful regexes (like in .NET).
 
 The current one is pretty much unusable due to lack of support for
 Unicode, and lacks lots of important features (named captures come to
 mind).

Just a thought -- libpcre is a very popular RE library, available under BSD. It has UTF-8 support, though not support for other Unicode encodings. Google's pcrecpp wrapper might be a source of inspiration. Would a PCRE wrapper be suitable for Phobos? Graham
Aug 04 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 04.08.2011, 18:42 Uhr, schrieb Graham Fawcett <fawcett uwindsor.ca>:

 On Thu, 04 Aug 2011 15:50:18 +0000, Mehrdad wrote:

 More powerful regexes (like in .NET).

 The current one is pretty much unusable due to lack of support for
 Unicode, and lacks lots of important features (named captures come to
 mind).

Just a thought -- libpcre is a very popular RE library, available under BSD. It has UTF-8 support, though not support for other Unicode encodings. Google's pcrecpp wrapper might be a source of inspiration. Would a PCRE wrapper be suitable for Phobos? Graham

I wonder what the general consensus is on wrappers. Berkley Sockets are good, since all supported OSs implement that API somehow. But GUI, PCRE and others need libraries installed. In my perfect world there would be wrappers, but they would work with corresponding libraries on Windows and Posix bases OSs. The idea of package dependencies is just not wide-spread in the Windows world and installing pcre, gtk, cairo, ... together with D on Windows seems clumsy to me :D If these libraries aren't available on Windows then the second best is a unique D implementation. If D was Linux only then I'd agree. I could understand if others say that the D installer for Windows could install those libraries as well. Just my 2 cents
Aug 04 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/4/11, Walter Bright <newshound2 digitalmars.com> wrote:
 I've used this for 25 years now.

 http://www.digitalmars.com/rtl/disp.html

That's freaking great. And it's already in snn.lib. However this doesn't work on Linux, right? Works great in D on win32. Thanks W.
Aug 05 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
--20cf307cffd687df4404a9d119fe
Content-Type: text/plain; charset=ISO-8859-1

product(), combinations(), permutations(), etc, are missing from Phobos.

--20cf307cffd687df4404a9d119fe
Content-Type: text/html; charset=ISO-8859-1

product(), combinations(), permutations(), etc, are missing from Phobos.<br>

--20cf307cffd687df4404a9d119fe--
Aug 06 2011
prev sibling next sibling parent reply albatroz <rmcjustino gmail.com> writes:
Nice to have, a command-line parser.

Jonathan M Davis wrote:
 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

Aug 06 2011
parent simendsjo <simendsjo gmail.com> writes:
On 06.08.2011 19:01, albatroz wrote:
 Nice to have, a command-line parser.

http://www.d-programming-language.org/phobos/std_getopt.html ?
Aug 06 2011
prev sibling next sibling parent reply Mehrdad <wfunction hotmail.com> writes:
A readText() function that would read a text file (**and** autodetect 
its encoding from its BOM) would be of great help.
Aug 07 2011
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 07.08.2011 12:09, Mehrdad wrote:
 A readText() function that would read a text file (**and** autodetect 
 its encoding from its BOM) would be of great help.

http://d-programming-language.org/phobos/std_file.html#readText -- Dmitry Olshansky
Aug 07 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/7/11 5:08 AM, Dmitry Olshansky wrote:
 On 07.08.2011 12:09, Mehrdad wrote:
 A readText() function that would read a text file (**and** autodetect
 its encoding from its BOM) would be of great help.

http://d-programming-language.org/phobos/std_file.html#readText

I think we could and should change readText to do the BOM trick. It's been on my mind forever. Andrei
Aug 07 2011
prev sibling parent Mehrdad <wfunction hotmail.com> writes:
On 8/7/2011 3:21 AM, Jonathan M Davis wrote:
 On Sunday 07 August 2011 14:08:06 Dmitry Olshansky wrote:
 On 07.08.2011 12:09, Mehrdad wrote:
 A readText() function that would read a text file (**and** autodetect
 its encoding from its BOM) would be of great help.

http://d-programming-language.org/phobos/std_file.html#readText

What Mehrdad wants is a way to read in a file with an encoding other than UTF-8, UTF-16, or UTF-32, have it autodetect the encoding by reading the file's BOM, and then convert it it to whatever encoding is that the character type that readText is using uses.

about Unicode, but I think it should be auto-detected, not based on the template parameter. On 8/7/2011 6:21 AM, Andrei Alexandrescu wrote:
 I think we could and should change readText to do the BOM trick. It's 
 been on my mind forever.

hastily written (no error checking or whatever), and (3) doesn't work for UTF-16 BE (although it works for LE), and (4) only returns the result in UTF-8. It's a starting point, though. An added bonus is the fact that it actually looks at the file data as well, so the heuristic is rather nice. pragma(lib, "advapi32.lib"); extern(Windows) BOOL IsTextUnicode(in void* pBuffer, int cb, int* lpi); string readText(const(char)[] name) { auto data = cast(char[])file.read(name); int test = 0xFFFF; if (IsTextUnicode(data.ptr, data.length, &test)) { return (cast(wchar[])(test & 0x00088 ? data[2 .. $] : data)).toUTF8(); } else { return (data.startsWith([0xEF, 0xBB, 0xBF]) ? data[3 .. $] : data).toUTF8(); } }
Aug 07 2011
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Mehrdad" <wfunction hotmail.com> wrote in message 
news:j1lh84$2n2j$1 digitalmars.com...
A readText() function that would read a text file (**and** autodetect its 
encoding from its BOM) would be of great help.

http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/util/io.d#L24 I agree a function like that needs to be in Phobos, though.
Aug 07 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 07 August 2011 14:08:06 Dmitry Olshansky wrote:
 On 07.08.2011 12:09, Mehrdad wrote:
 A readText() function that would read a text file (**and** autodetect
 its encoding from its BOM) would be of great help.

Well the name is here, dunno if it meets your expectations: http://d-programming-language.org/phobos/std_file.html#readText

D (and Phobos in general) assumes that char in UTF-8, wchar is UTF-16, and dchar is UTF-32. You're going to get an exception thrown pretty quickly if you're trying to use those types with values that don't match those encodings. As such, readText assumes that the file is in whatever encoding the character type is that it's instantiated with. So, if you try and read in a file which doesn't match the character encoding of the character type that you're using (which is char by default), you're going to get a UtfException. What Mehrdad wants is a way to read in a file with an encoding other than UTF-8, UTF-16, or UTF-32, have it autodetect the encoding by reading the file's BOM, and then convert it it to whatever encoding is that the character type that readText is using uses. readText doesn't currently do anything of the sort. At this point, dealing with anything which has an encoding other than UTF-8, UTF-16, or UTF-32 is problematic in D. std.encoding helps, but it's not necessarily all that good (Andrei considers it a failed experiment which either needs to be redesigned or removed). So, one of the things that still needs to be figured out for Phobos is how to better handle encodings other than UTF-8, UTF-16, and UTF-32. For the most part, other encodings are likely to be dealt with only when reading or writing I/O while UTF-8, UTF-16, and UTF-32 are dealt with inside of D programs, but we still need to fix things so that we can readily deal with I/O that isn't UTF-8, UTF-16, or UTF-32. - Jonathan M Davis
Aug 07 2011
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 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?

Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games). -- Simen
Aug 10 2011
next sibling parent simendsjo <simendsjo gmail.com> writes:
On 10.08.2011 19:02, Simen Kjaeraas wrote:
 On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:

 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?

Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games).

Second the full OS bindings. etc\c\win32 would be really nice. You'll not get cross platform support, but at least you have it handy.
Aug 10 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-10 19:02, Simen Kjaeraas wrote:
 On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:

 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?

Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games).

Phobos already have an XML module, although not very good. For OpenGL bindings there is Derelict: http://www.dsource.org/projects/derelict -- /Jacob Carlborg
Aug 10 2011
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sun, 31 Jul 2011 15:49:42 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:

 - std.operator: standard operators as functions, to be used with higher  
 order functions;

Nice idea. So simple yet so useful. -- Simen
Aug 10 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Simen Kjaeraas:

 Nice idea. So simple yet so useful.

It's not an original idea, it's essentially a Phobos version of this Python standard library :-) http://docs.python.org/library/operator.html Bye, bearophile
Aug 10 2011
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Tue, 02 Aug 2011 20:04:40 +0200, Paul D. Anderson  
<paul.d.removethis.anderson comcast.andthis.net> wrote:

 I'm nearing completion on an arbitrary-precision floating point library,  
 along with implementations of decimal32, decimal64 and decimal128  
 structs.

Awesome. -- Simen
Aug 10 2011
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 11 Aug 2011 08:58:28 +0200, Jacob Carlborg <doob me.com> wrote:

 On 2011-08-10 19:02, Simen Kjaeraas wrote:
 On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis
 <jmdavisProg gmx.com> wrote:

 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?

Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games).

Phobos already have an XML module, although not very good. For OpenGL bindings there is Derelict: http://www.dsource.org/projects/derelict

I know. As far as I can see, D is a good option for indie gamedevs and hobbyists who want to try their hand at making games. For that reason, a 'batteries included' version would be a good idea, IMO. -- Simen
Aug 11 2011