July 31, 2011
== 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.
July 31, 2011
I would like to see something similar to Boost Graph Library for D.
July 31, 2011
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
July 31, 2011
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
July 31, 2011
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
July 31, 2011
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
July 31, 2011
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
July 31, 2011
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)
July 31, 2011
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/
July 31, 2011
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.