July 31, 2011
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
July 31, 2011
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
July 31, 2011
== Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
> I think that it would be useful to query the community for what piece of
> library functionality they don't currently have in D and would most like to
> see. For instance, there is no official logging framework in D or any 3rd party
> libraries which do it AFAIK. So, that could be one type of functionality that
> you may like to see. Now, there is a prospective implementation for std.log
> which shouldn't be all that far away from being reviewed, so listing that here
> wouldn't be all that useful, since it's on its way. But what other major
> functionality do you miss in D that other languages' that you use have
> available in their libraries?
> My hope here would be that we could get some good ideas going here such that
> we have can have a better idea what type of functionality it would be
> particularly useful to be working on for Phobos or 3rd party D libraries for
> the community, and maybe it'll even get some people to actually go and work on
> these ideas so that we can improve the libraries that we have to work with in
> D. We can always use more help, and we definitely need a richer library
> ecosystem for D. But even just discussing ideas could be of benefit.
> So, what major functionality which we don't currently have would you like to
> see in either Phobos or in a 3rd party library so that you could use it in
> your D programs?
> - Jonathan M Davis

I could really use a linear algebra library, but the GSoC project I'm mentoring is oriented towards creating one and it's now close to usable.  (I'd like to thank Cristi Cobzarenco for doing a great job on his GSoC project so far.)

Next in line would be high-level MPI wrappers, like boost::mpi, or something functionally similar, like a std.concurrency that works across multiple address spaces.  std.parallelism works great for SMP parallelism (which is what it was designed to do), but sometimes I want an easy way to parallelize stuff across address spaces, too.
July 31, 2011
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
July 31, 2011
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
July 31, 2011
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
July 31, 2011
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
July 31, 2011
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!

July 31, 2011
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
July 31, 2011
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