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 reply "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
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 Ahlstrm <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 Ahlstrm <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.




 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


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




 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


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


=20
 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
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
parent reply 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=








es.

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

 I think someone is working on this.


=20
 I know of the Goldie project. Is this it?


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




s,

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




drei

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




king

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




sest

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




ob

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


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


ly

 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=


ly

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


e.

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


nd

 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=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
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 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 Rnne 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 reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Btw why not take DDMD's lexer.d and start from there?
Jul 31 2011
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 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 

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 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 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
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 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
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 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 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 parent reply 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
parent reply 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
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 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 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
next sibling 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 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 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 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 reply "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
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 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 

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

 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 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
next sibling 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 parent Jimmy Cao <jcao219 gmail.com> writes:
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.
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
next sibling 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
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 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.


+1 for a good math lib (it would be cool if Scid cool become part of 
phobos after GSOC project)

also:
standard database lib (including bindings for postgresql, sqlite, etc)
gui lib (DWT2?)

thanks,

filgood
Aug 01 2011
prev 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 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
next sibling 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 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 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 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 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 reply 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
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 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 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
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 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
next sibling parent reply "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
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 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
next sibling parent reply 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
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 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.

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.

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


Dude, that's awesome! Can't wait to see the beta!! :)
Aug 04 2011
prev sibling next sibling parent reply 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
parent reply 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
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 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 reply 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
next sibling parent reply Jimmy Cao <jcao219 gmail.com> writes:
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
 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

possible in the future.  I see why it might not be possible, though.
Aug 02 2011
next sibling parent reply "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


 I agree, GUIs (and other huge libraries that everyone has their own
 favorite) don't belong standard library. Other languages get away with  
 it
 because they are either platform themselves or support only one  
 platform.
 Another reason not to include them to the standard library, remember  
 phobos
 has rules (we might need to change many things).
 But if we have something small, simple and cross-platform somewhere, why
 not!


 If a GUI library were included in Phobos, that would make D a much better

 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
parent reply Jimmy Cao <jcao219 gmail.com> writes:
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


 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

 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).
Aug 02 2011
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 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


 I agree, GUIs (and other huge libraries that everyone has their own
 favorite) don't belong standard library. Other languages get away with it
 because they are either platform themselves or support only one platform.
 Another reason not to include them to the standard library, remember
 phobos has rules (we might need to change many things).
 But if we have something small, simple and cross-platform somewhere, why
 not!


 
 If a GUI library were included in Phobos, that would make D a much better

 possible in the future.  I see why it might not be possible, though.



.NET and perhaps even until microsoft adopts it. I don't think a standard  
gui lib will make any difference.
Aug 02 2011
parent reply 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


 I agree, GUIs (and other huge libraries that everyone has their own
 favorite) don't belong standard library. Other languages get away with it
 because they are either platform themselves or support only one platform.
 Another reason not to include them to the standard library, remember
 phobos has rules (we might need to change many things).
 But if we have something small, simple and cross-platform somewhere, why
 not!


 If a GUI library were included in Phobos, that would make D a much better

 possible in the future.  I see why it might not be possible, though.



 .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.
Aug 03 2011
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 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 Jimmy Cao <jcao219 gmail.com> writes:
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
 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

possible in the future.  I see why it might not be possible, though.
Aug 02 2011
prev sibling parent reply 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
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 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 parent reply 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 

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

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




ssage

 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=




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


t

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

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


Perhaps a curses binding of some sort?

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


 Perhaps a curses binding of some sort?

 - Alex


Something like that.

-- 
/Jacob Carlborg
Aug 02 2011
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rnne 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.


 Perhaps a curses binding of some sort?


Maybe for linux, but it should be cross-platform and therefore use the Win 
API for that stuff on Windows. (For some bizarre reason, ANSI display 
support was removed from approx Win2k onward.)
Aug 02 2011
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
next sibling 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
next sibling 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 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 reply "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
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I'll find the damn thing, gimme a day. :p
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
next sibling parent reply 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
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 parent Caligo <iteronvexor gmail.com> writes:
product(), combinations(), permutations(), etc, are missing from Phobos.
Aug 06 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-02 22:01, Nick Sabalausky wrote:

 "Alex Rnne 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.


 Perhaps a curses binding of some sort?


 Maybe for linux, but it should be cross-platform and therefore use the Win
 API for that stuff on Windows. (For some bizarre reason, ANSI display
 support was removed from approx Win2k onward.)


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 next sibling parent reply 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
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 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.


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

-- 
Dmitry Olshansky
Aug 07 2011
next sibling parent reply 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
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.


 Well the name is here, dunno if it meets your expectations:
 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.


Yeah, although I don't mean anything /other/ than those -- I only care 
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.


I /do/ have an implementation, but it's (1) only for Windows, (2) 
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 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.


 Well the name is here, dunno if it meets your expectations:
 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 "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 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 reply 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
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