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

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

Re: What library functionality would you most like to see in D?

[user]

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

Re: What library functionality would you most like to see in D?

[Sean Kelly]

On Jul 30, 2011, at 10:27 PM, 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?


I can't say that these exist in other standard libraries either, but I want:

1. A high-performance sockets API.
2. A robust logging tool (ie. Boost.Log).

Re: What library functionality would you most like to see in D?

[H. S. Teoh]

On Thu, May 10, 2012 at 10:49:08AM -0700, Sean Kelly wrote:
> On Jul 30, 2011, at 10:27 PM, 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. [...] But what other major functionality do
> > you miss in D that other languages' that you use have available in
> > their libraries?
[...]

I don't know if this can be considered "major functionality", but I
would be really really happy if there was a high-quality linear algebra
library available for D. Or at the very least, a generic matrix/vector
algebra module that can interoperate with more targeted libraries
(something along the lines of Blitz++ in C++).


> I can't say that these exist in other standard libraries either, but I
> want:
> 
> 1. A high-performance sockets API.
> 2. A robust logging tool (ie. Boost.Log).

I thought std.log is in the queue? Or is it not powerful enough for what
you need?


T

-- 
"I suspect the best way to deal with procrastination is to put off the
procrastination itself until later. I've been meaning to try this, but
haven't gotten around to it yet. " -- swr

Re: What library functionality would you most like to see in D?

[Michaël.Larouche]

On Thursday, 10 May 2012 at 18:37:19 UTC, H. S. Teoh wrote:

On Thu, May 10, 2012 at 10:49:08AM -0700, Sean Kelly wrote:

On Jul 30, 2011, at 10:27 PM, 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. [...] But what other major 
> functionality do
> you miss in D that other languages' that you use have 
> available in

> their libraries?

[...]

I don't know if this can be considered "major functionality", 
but I
would be really really happy if there was a high-quality linear 
algebra
library available for D. Or at the very least, a generic 
matrix/vector
algebra module that can interoperate with more targeted 
libraries

(something along the lines of Blitz++ in C++).



gl3n would be a good candidate for a standard vector/matrix 
library, the big feature missing is intrinsics support (aka 
SSE,AltiVec,VMX and Neon vector operations)


I can't say that these exist in other standard libraries 
either, but I

want:

1. A high-performance sockets API.
2. A robust logging tool (ie. Boost.Log).


I thought std.log is in the queue? Or is it not powerful enough 
for what

you need?


T

Re: What library functionality would you most like to see in D?

[Tove]

On Sunday, 31 July 2011 at 14:10:12 UTC, Heywood Floyd wrote:

- Incremental Garbage collector (for real-time apps)
- More example code snippets in the docs (for all libs)


The entire compiler as a library. :D

Re: What library functionality would you most like to see in D?

[H. S. Teoh]

On Thu, May 10, 2012 at 09:00:40PM +0200, Tove wrote:
> On Sunday, 31 July 2011 at 14:10:12 UTC, Heywood Floyd wrote:
> >- Incremental Garbage collector (for real-time apps)
> >- More example code snippets in the docs (for all libs)
> 
> The entire compiler as a library. :D

Or at the very least, the front-end. That would open the door to many
useful tools like lints, superior IDE integration, pretty-printers, all
kinds of neat stuff.


T

-- 
"How are you doing?" "Doing what?"

Re: What library functionality would you most like to see in D?

[sclytrack]

I want to see the following library feature the most.

apt-get install d-library-name

Re: What library functionality would you most like to see in D?

[Kiith-Sa]

gl3n would be a good candidate for a standard vector/matrix 
library, the big feature missing is intrinsics support (aka 
SSE,AltiVec,VMX and Neon vector operations)


Again, there's a confusion between game-oriented and 
science-oriented

linear algebra library.

gl3n is game oriented.

I would like to have both in Phobos, though.


But I still think there's more need to fix containers and streams 
and
to have allocators in Phobos. (My D:YAML project can't go stable 
without

stable streams, for instance).

Re: What library functionality would you most like to see in D?

[H. S. Teoh]

On Thu, May 10, 2012 at 09:11:46PM +0200, sclytrack wrote:
> I want to see the following library feature the most.
> 
> apt-get install d-library-name

Well, then read this:

http://www.debian.org/doc/debian-policy/

then make your package, and find a sponsor to upload it to the Debian
repos for you.


T

-- 
"Life is all a great joke, but only the brave ever get the point." -- Kenneth 
Rexroth

Re: What library functionality would you most like to see in D?

[H. S. Teoh]

On Thu, May 10, 2012 at 09:15:40PM +0200, Kiith-Sa wrote:
> >gl3n would be a good candidate for a standard vector/matrix library,
> >the big feature missing is intrinsics support (aka SSE,AltiVec,VMX
> >and Neon vector operations)
> 
> Again, there's a confusion between game-oriented and science-oriented
> linear algebra library.
> 
> gl3n is game oriented.
> 
> I would like to have both in Phobos, though.

That's what I was trying to get at: we need a common interface for both.
Things like matrix/vector types should be interoperable between the two
kinds of libraries.

I work with more science-oriented (or rather math-oriented) linear
algebra, but interoperability with 3D acceleration, for example, would
be a very nice thing (for math visualization, etc.).


> But I still think there's more need to fix containers and streams and
> to have allocators in Phobos. (My D:YAML project can't go stable
> without stable streams, for instance).

Yeah, I'm eagerly awaiting the day std.io is integrated into Phobos.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze

Re: What library functionality would you most like to see in D?

[Sean Kelly]

On May 10, 2012, at 11:38 AM, H. S. Teoh wrote:

> On Thu, May 10, 2012 at 10:49:08AM -0700, Sean Kelly wrote:
> 
>> I can't say that these exist in other standard libraries either, but I
>> want:
>> 
>> 1. A high-performance sockets API.
>> 2. A robust logging tool (ie. Boost.Log).
> 
> I thought std.log is in the queue? Or is it not powerful enough for what
> you need?

Assuming I were actually using this at work, it's not powerful enough for what 
I'd need.  At the very least, it needs configurable output filenames and 
rules-based log rolling.  Fancier stuff like multiple formatters and sinks 
would be significant as well.  Say I want the logger to dump to syslog on Unix 
or the Windows event logger, for example, plus console, file, and a 
user-defined location like a remote service with a socket API.  Synchronous or 
asynchronous logging for high-latency writes would be important, unless that 
was left up to the user-defined sink implementation.  Finally, I'd need some 
way to log to different sinks based on some rule.  Say I want data for each 
user in a separate file, for example.  Boost.Log is almost too configurable in 
this regard, and comes off as overcomplicated, but it does all this and more.

Re: What library functionality would you most like to see in D?

[Dejan Lekic]

On Thursday, 10 May 2012 at 19:43:51 UTC, Sean Kelly wrote:

On May 10, 2012, at 11:38 AM, H. S. Teoh wrote:


On Thu, May 10, 2012 at 10:49:08AM -0700, Sean Kelly wrote:

I can't say that these exist in other standard libraries 
either, but I

want:

1. A high-performance sockets API.
2. A robust logging tool (ie. Boost.Log).


I thought std.log is in the queue? Or is it not powerful 
enough for what

you need?


Assuming I were actually using this at work, it's not powerful 
enough for what I'd need.  At the very least, it needs 
configurable output filenames and rules-based log rolling.  
Fancier stuff like multiple formatters and sinks would be 
significant as well.  Say I want the logger to dump to syslog 
on Unix or the Windows event logger, for example, plus console, 
file, and a user-defined location like a remote service with a 
socket API.  Synchronous or asynchronous logging for 
high-latency writes would be important, unless that was left up 
to the user-defined sink implementation.  Finally, I'd need 
some way to log to different sinks based on some rule.  Say I 
want data for each user in a separate file, for example.  
Boost.Log is almost too configurable in this regard, and comes 
off as overcomplicated, but it does all this and more.


From personal perspective - nothing beats log4j ... Seriously...

Re: What library functionality would you most like to see in D?

[Sean Kelly]

On May 10, 2012, at 12:46 PM, Dejan Lekic wrote:
> 
> From personal perspective - nothing beats log4j ... Seriously…

I've heard that it's terribly slow.

Re: What library functionality would you most like to see in D?

[Steven Schveighoffer]

On Thu, 10 May 2012 15:11:46 -0400, sclytrack  wrote:




I want to see the following library feature the most.

apt-get install d-library-name



https://code.google.com/p/d-apt/wiki/APT_Repository#APT_Repository_for_D

-Steve

Re: What library functionality would you most like to see in D?

[Nathan M. Swan]

On Thursday, 10 May 2012 at 19:11:48 UTC, sclytrack wrote:



I want to see the following library feature the most.

apt-get install d-library-name


Or even better: a D packaging system

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

On Thursday, May 10, 2012 12:08:27 H. S. Teoh wrote:
> On Thu, May 10, 2012 at 09:00:40PM +0200, Tove wrote:
> > On Sunday, 31 July 2011 at 14:10:12 UTC, Heywood Floyd wrote:
> > >- Incremental Garbage collector (for real-time apps)
> > >- More example code snippets in the docs (for all libs)
> > 
> > The entire compiler as a library. :D
> 
> Or at the very least, the front-end. That would open the door to many
> useful tools like lints, superior IDE integration, pretty-printers, all
> kinds of neat stuff.

That's the plan more or less (at least, we definitely intend to have the lexer 
and the parser included - I don't know what beyond that, and I don't know how 
far the front-end goes before passing stuff off to the backend). The problem is 
implementing it. Walter already gave permission for the front-end's lexer to 
be ported to D (with a range-based API) under the Boost license to be put into 
Phobos. I volunteered to do it and made some progress, but I haven't time to 
work on it in a while. A couple of other people have said that they'd do it, 
but no one has ever gotten to the point that they've attempted to submit 
anything to Phobos. Taking what ddmd did, updating it, and adjusting it 
accordingly might reduce the coding effort (or it might not, depending on how 
out-of-date ddmd is), but you'd have to get ahold of all of the relevant ddmd 
developers so that you could get their permission to change the license to 
Boost.

I'd _like_ to finish the lexer, but I honestly have no idea when I'll be able 
to finish it. Regardless, it's definitely the plan to at minimum have a lexer 
and parser for D in Phobos.

There was also some discussion on adding lexer and parser generator framework 
of some kind to Phobos to make generating lexers and parsers easy. But no one 
has submitted anything like that to Phobos yet either.

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2012-05-10 22:02, Nathan M. Swan wrote:

On Thursday, 10 May 2012 at 19:11:48 UTC, sclytrack wrote:



I want to see the following library feature the most.

apt-get install d-library-name


Or even better: a D packaging system


Working on that: 
https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D


--
/Jacob Carlborg

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2012-05-10 21:00, Tove wrote:

On Sunday, 31 July 2011 at 14:10:12 UTC, Heywood Floyd wrote:

- Incremental Garbage collector (for real-time apps)
- More example code snippets in the docs (for all libs)


The entire compiler as a library. :D



I would love to see that in Phobos.

--
/Jacob Carlborg

Re: What library functionality would you most like to see in D?

[Sean Cavanaugh]

On 5/10/2012 12:49 PM, Sean Kelly wrote:

On Jul 30, 2011, at 10:27 PM, 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?



I can't say that these exist in other standard libraries either, but I want:

1. A high-performance sockets API.
2. A robust logging tool (ie. Boost.Log).


The whole windows SDK (all the C functions, all the COM stuff).   The 
defaults in dmd are rather limited, and even the win32 bindings project 
on dsource.org has a lot of hole being a port from Ming that is only up 
to WinXP levels for the most part.


I would imagine parsing the sdk headers and turning it into a language 
neutral database that could be annotated with language specific metadata 
would be rather useful, especially as other languages and toolchains 
could all benefit from being able to make their own bindings from it.

Re: What library functionality would you most like to see in D?

[Roman D. Boiko]

On Thursday, 10 May 2012 at 21:38:26 UTC, Jonathan M Davis wrote:

On Thursday, May 10, 2012 12:08:27 H. S. Teoh wrote:

On Thu, May 10, 2012 at 09:00:40PM +0200, Tove wrote:
> On Sunday, 31 July 2011 at 14:10:12 UTC, Heywood Floyd wrote:
> >- Incremental Garbage collector (for real-time apps)
> >- More example code snippets in the docs (for all libs)
> 
> The entire compiler as a library. :D


Or at the very least, the front-end. That would open the door 
to many
useful tools like lints, superior IDE integration, 
pretty-printers, all

kinds of neat stuff.


That's the plan more or less (at least, we definitely intend to 
have the lexer
and the parser included - I don't know what beyond that, and I 
don't know how
far the front-end goes before passing stuff off to the 
backend). The problem is
implementing it. Walter already gave permission for the 
front-end's lexer to
be ported to D (with a range-based API) under the Boost license 
to be put into
Phobos. I volunteered to do it and made some progress, but I 
haven't time to
work on it in a while. A couple of other people have said that 
they'd do it,
but no one has ever gotten to the point that they've attempted 
to submit
anything to Phobos. Taking what ddmd did, updating it, and 
adjusting it
accordingly might reduce the coding effort (or it might not, 
depending on how
out-of-date ddmd is), but you'd have to get ahold of all of the 
relevant ddmd
developers so that you could get their permission to change the 
license to

Boost.

I'd _like_ to finish the lexer, but I honestly have no idea 
when I'll be able
to finish it. Regardless, it's definitely the plan to at 
minimum have a lexer

and parser for D in Phobos.

There was also some discussion on adding lexer and parser 
generator framework
of some kind to Phobos to make generating lexers and parsers 
easy. But no one

has submitted anything like that to Phobos yet either.

- Jonathan M Davis


Please take a look at my draft implementation of lexer and source 
decoding from UTF: https://github.com/roman-d-boiko/dct


Any feedback and reviews would be welcome.

Re: What library functionality would you most like to see in D?

[Roman D. Boiko]

On Friday, 11 May 2012 at 06:23:07 UTC, Jacob Carlborg wrote:

On 2012-05-10 21:00, Tove wrote:

On Sunday, 31 July 2011 at 14:10:12 UTC, Heywood Floyd wrote:

- Incremental Garbage collector (for real-time apps)
- More example code snippets in the docs (for all libs)


The entire compiler as a library. :D



I would love to see that in Phobos.


Please take a look at https://github.com/roman-d-boiko/dct

It is an early draft and not tested after restructuring.

What would be needed for that code to become a bit closer for 
Phobos inclusion? Any feedback is highly appreciated.

Re: What library functionality would you most like to see in D?

[Jens Mueller]

H. S. Teoh wrote:
> On Thu, May 10, 2012 at 10:49:08AM -0700, Sean Kelly wrote:
> > On Jul 30, 2011, at 10:27 PM, 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. [...] But what other major functionality do
> > > you miss in D that other languages' that you use have available in
> > > their libraries?
> [...]
> 
> I don't know if this can be considered "major functionality", but I
> would be really really happy if there was a high-quality linear algebra
> library available for D. Or at the very least, a generic matrix/vector
> algebra module that can interoperate with more targeted libraries
> (something along the lines of Blitz++ in C++).

Hopefully, Cristi will be able to submit a module this summer.

Jens

Re: What library functionality would you most like to see in D?

[Roman D. Boiko]

On Friday, 11 May 2012 at 07:31:14 UTC, Roman D. Boiko wrote:

Please take a look at https://github.com/roman-d-boiko/dct

It is an early draft and not tested after restructuring.

What would be needed for that code to become a bit closer for 
Phobos inclusion? Any feedback is highly appreciated.


I created a dedicated thread for feedback in the 
digitalmars.D.announce forum: 
http://forum.dlang.org/thread/ghdcgdydadqqetqdk...@forum.dlang.org

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2012-05-11 09:31, Roman D. Boiko wrote:

On Friday, 11 May 2012 at 06:23:07 UTC, Jacob Carlborg wrote:

On 2012-05-10 21:00, Tove wrote:

On Sunday, 31 July 2011 at 14:10:12 UTC, Heywood Floyd wrote:

- Incremental Garbage collector (for real-time apps)
- More example code snippets in the docs (for all libs)


The entire compiler as a library. :D



I would love to see that in Phobos.


Please take a look at https://github.com/roman-d-boiko/dct

It is an early draft and not tested after restructuring.

What would be needed for that code to become a bit closer for Phobos
inclusion? Any feedback is highly appreciated.


A couple of questions:

* What's the sate of the lexer
* Does it convert numerical literals and similar to their actual values
* Does it retain full source information
* Is there an example we can look at to see how the API is used
* Does it have a range based interface

--
/Jacob Carlborg

Re: What library functionality would you most like to see in D?

[Roman D. Boiko]

On Friday, 11 May 2012 at 08:37:06 UTC, Jacob Carlborg wrote:

A couple of questions:

* What's the sate of the lexer
I consider it a draft state, because it has got several rewrites 
recently and I plan to do more, especially based on community 
feedback. However, implementation handles almost all possible 
cases. Because of rewrites it is most likely broken at this 
moment, I'm going to fix it ASAP (in a day or two).


Lexer will provide a random-access range of tokens (this is not 
done yet).


Each token contains:
* start index (position in the original encoding, 0 corresponds 
to the first code unit after BOM),

* token value encoded as UTF-8 string,
* token kind (e.g., token.kind = TokenKind.Float),
* possibly enum with annotations (e.g., token.annotations = 
FloatAnnotation.Hex | FloatAnnotation.Real)


* Does it convert numerical literals and similar to their 
actual values
It is planned to add a post-processor for that as part of parser, 
please see README.md for some more details.



* Does it retain full source information
Yes, this is a design choice to preserve all information. Source 
code is converted to UTF-8 and stored as token.value, even 
whitespaces. Information about code unit indices in the original 
encoding is preserved, too.



* Is there an example we can look at to see how the API is used

TBD soon (see Roadmap in the readme file)


* Does it have a range based interface

Yes, this is what I consider one of its strengths.

Re: What library functionality would you most like to see in D?

[Joseph Rushton Wakeling]

On 10/05/12 21:23, H. S. Teoh wrote:

Well, then read this:

http://www.debian.org/doc/debian-policy/

then make your package, and find a sponsor to upload it to the Debian
repos for you.


Bear in mind that your package will most likely need to be compilable with GDC 
in order to get it into Debian.  I doubt they'll accept DMD-compiled executables.

Re: What library functionality would you most like to see in D?

[Nick Sabalausky]

"Jonathan M Davis"  wrote in message 
news:mailman.1978.1312090051.14074.digitalmar...@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

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

On Sunday 31 July 2011 01:53:25 Nick Sabalausky wrote:
> "Jonathan M Davis"  wrote in message
> news:mailman.1978.1312090051.14074.digitalmar...@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

Re: What library functionality would you most like to see in D?

[Alex Rønne Petersen]

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(

Re: What library functionality would you most like to see in D?

[Anders Ahlstr�m]

== Quote from Alex Rønne Petersen (xtzgzo...@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.

Re: What library functionality would you most like to see in D?

[Mirko Pilger]

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

Re: What library functionality would you most like to see in D?

[Alex Rønne Petersen]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Alex Rønne Petersen]

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

Re: What library functionality would you most like to see in D?

[Anders Ahlstr�m]

== Quote from Alex Rønne Petersen (xtzgzo...@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.

Re: What library functionality would you most like to see in D?

[Caligo]

I would like to see something similar to Boost Graph Library for D.

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

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

Re: What library functionality would you most like to see in D?

[Alex Rønne Petersen]

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

Re: What library functionality would you most like to see in D?

[Alex Rønne Petersen]

On 31-07-2011 12:09, Anders Ahlstr�m wrote:

== Quote from Alex Rønne Petersen (xtzgzo...@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:

127.0.0.1
65535


1234
asdf


...

...


or something like that, if I'm reading the property trees docs right...

- Alex

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

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

Re: What library functionality would you most like to see in D?

[Alex Rønne Petersen]

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

Re: What library functionality would you most like to see in D?

[simendsjo]

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)

Re: What library functionality would you most like to see in D?

[Robert Clipsham]

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/

Re: What library functionality would you most like to see in D?

[Peter Alexander]

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.

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[dsimcha]

== Quote from Jonathan M Davis (jmdavisp...@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.

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Mike Parker]

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!

Re: What library functionality would you most like to see in D?

[bearophile]

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

Re: What library functionality would you most like to see in D?

[Heywood Floyd]

- Incremental Garbage collector (for real-time apps)
- More example code snippets in the docs (for all libs)

Re: What library functionality would you most like to see in D?

[Jim Hewes]

On 7/31/2011 3:01 AM, Jacob Carlborg wrote:


I personally would like to see DWT (GUI library,
http://dsource.org/projects/dwt) in a more finished state. These are
things that need work:

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

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



I agree with this one. I'll tell you why, hopefully without getting too 
long-winded. :-) I've just been a lurker here and although I like the D 
language haven't really used it seriously yet.


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


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


I've recently downloaded the QtD binding to take a look because Qt seem 
to be a pretty popular cross-platform library. I was able to build it 
and then also build a couple of the sample projects, although I haven't 
really spent time with it beyond that. It seems that not only is a Hello 
World program a 1.7MB executable, but I think I would also need to 
distribute the libcpp_core.dll and libcpp_gui.dll files with it for a 
total of about 17MB. QtD looks like a lot of good work and I don't mean 
to knock it here. I just mean to say that in contrast what would be nice 
is a “standard” GUI written in D that could be statically linked and 
would be not too large. I confess I have not tried the existing DWT yet, 
mostly since I just didn't want to also download Tango.


Jim

Re: What library functionality would you most like to see in D?

[Walter Bright]

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

Re: What library functionality would you most like to see in D?

[Brian Hay]

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.

Re: What library functionality would you most like to see in D?

[Andrej Mitrovic]

Some template/mixin functions which ease generating C or C++ bindings.
Same goes for DLLs.

Re: What library functionality would you most like to see in D?

[KennyTM~]

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

Re: What library functionality would you most like to see in D?

[Jimmy Cao]

On Sun, Jul 31, 2011 at 6:13 AM, simendsjo  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
> )
>


FTP, HTTP, and SMTP are the protocols that are included in etc.curl.

Re: What library functionality would you most like to see in D?

[Johann MacDonagh]

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.

Re: What library functionality would you most like to see in D?

[Andrej Mitrovic]

Btw why not take DDMD's lexer.d and start from there?

Re: What library functionality would you most like to see in D?

[Johann MacDonagh]

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.

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

On Monday 01 August 2011 03:31:41 Andrej Mitrovic wrote:
> Btw why not take DDMD's lexer.d and start from there?

It's a possibility but has 2 downsides to it.

1. Due to licensing issues, you have to get permission from the ddmd 
developers. The front-end is LGPL IIRC, not Boost. Walter gave permission to 
port the lexer from the front-end to D and make it Boost, but that doesn't 
hold for the ddmd code, which was taken from dmd's front-end and ported by 
other folks. So, their permission would be required. It's not necessarily a 
big deal, but it is something that needs to be dealt with.

2. To really do it right, you need to understand how it works. Personally, I 
think that doing all the work of porting it is going to help a _lot_ in 
gaining that understanding. If all you do is take and adjust the ddmd code, 
then you don't gain that understanding.

So, ddmd's source code definitely could be used as the base for Phobos' D 
lexer, but I haven't taken the time to deal with #1, and because of #2, I find 
it very valuable to do the porting myself. I haven't gotten very far on of it 
of late though. Taking ddmd and adjusting would probably be faster, but as a 
maintainer of the result, it would be harder to maintain just because I 
wouldn't understand it as well.

- Jonathan M Davis

Re: What library functionality would you most like to see in D?

[Johann MacDonagh]

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

Re: What library functionality would you most like to see in D?

[Johann MacDonagh]

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

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

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

Re: What library functionality would you most like to see in D?

[Andrej Mitrovic]

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.

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

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

Re: What library functionality would you most like to see in D?

[Andrej Mitrovic]

Licenses are the greatest code smell.

Re: What library functionality would you most like to see in D?

[Johann MacDonagh]

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?

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

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

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

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

Re: What library functionality would you most like to see in D?

[Johann MacDonagh]

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.

Re: What library functionality would you most like to see in D?

[Andrei Alexandrescu]

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

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

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

Re: What library functionality would you most like to see in D?

[Walter Bright]

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.

Re: What library functionality would you most like to see in D?

[Marco Leise]

Am 01.08.2011, 05:31 Uhr, schrieb Jonathan M Davis :

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?

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

On 2011-07-31 21:06, Jim Hewes wrote:

On 7/31/2011 3:01 AM, Jacob Carlborg wrote:


I personally would like to see DWT (GUI library,
http://dsource.org/projects/dwt) in a more finished state. These are
things that need work:

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

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



I agree with this one. I'll tell you why, hopefully without getting too
long-winded. :-) I've just been a lurker here and although I like the D
language haven't really used it seriously yet.

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


That's understandable.


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


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



I've recently downloaded the QtD binding to take a look because Qt seem
to be a pretty popular cross-platform library. I was able to build it
and then also build a couple of the sample projects, although I haven't
really spent time with it beyond that. It seems that not only is a Hello
World program a 1.7MB executable, but I think I would also need to
distribute the libcpp_core.dll and libcpp_gui.dll files with it for a
total of about 17MB. QtD looks like a lot of good work and I don't mean
to knock it here. I just mean to say that in contrast what would be nice
is a “standard” GUI written in D that could be statically linked and
would be not too large. I confess I have not tried the existing DWT yet,
mostly since I just didn't want to also download Tango.

Jim


DWT works with D2 (Phobos) as well. It's statically linked so the hello 
world application gets quite large. But that's because it pulls in a lot 
of the library, meaning even if you start using other parts of the 
library it won't increase the size of the executable at the same rate.


--
/Jacob Carlborg

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Lutger Blijdestijn]

streams and network programming is most desirable, this also impacts other 
libraries. 

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

It's interesting to see that in .NET a lot of new stuff concerning async 
programming is coming out, suggesting that the (many) existing patterns are 
considered inadequate. In C# 5, async operations will be a language level 
feature with the async/await keywords. There is also the reactive extensions 
library for async streams: http://msdn.microsoft.com/en-us/data/gg577609. 
Most interesting about this one is how easy it is to compose async 
operations.

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Jacob Carlborg]

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

Re: What library functionality would you most like to see in D?

[Heywood Floyd]

- DBs
- Incremental GC (for real-time apps)
- Code examples!!! ..in the docs, applies to all libs, please..

Re: What library functionality would you most like to see in D?

[Paul D. Anderson]

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

Re: What library functionality would you most like to see in D?

[Jim Hewes]

"Jacob Carlborg"  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 

Re: What library functionality would you most like to see in D?

[filgood]

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

Re: What library functionality would you most like to see in D?

[Johann MacDonagh]

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.

Re: What library functionality would you most like to see in D?

[Nick Sabalausky]

"Johann MacDonagh"  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.

Re: What library functionality would you most like to see in D?

[Nick Sabalausky]

"Alex Rønne Petersen"  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?

Re: What library functionality would you most like to see in D?

[Jonathan M Davis]

> 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

Re: What library functionality would you most like to see in D?

[Nick Sabalausky]

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

Re: What library functionality would you most like to see in D?

[Andrei Alexandrescu]

On 8/1/11 4:35 PM, Nick Sabalausky wrote:

"Johann MacDonagh"  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

Re: What library functionality would you most like to see in D?

[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

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.

Re: What library functionality would you most like to see in D?

[Brad Roberts]

On Mon, 1 Aug 2011, Andrei Alexandrescu wrote:

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

Re: What library functionality would you most like to see in D?

[Andrei Alexandrescu]

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