August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Williams | On Thursday, 29 August 2013 at 06:34:23 UTC, Peter Williams wrote: > On 29/08/13 16:11, Rikki Cattermole wrote: >> I will say this, one thing about D that has annoyed me from the >> beginning is the state of the gui libs. Hence why in last month I've >> been having a real good play around with OpengGL and creating my own >> library [1]. > > On this topic, I started looking at porting one of my PyGTK applications to GtkD and found that the knowledge of PyGTK API wasn't a great deal of help in this endeavor. I think the problem is Python's "duck typing" and dynamic typing allow for a very flexible API that is much simpler than GTK+'s and GtkD's is much like GTK+'s. The problem is complicated by the fact that the amount of documentation is huge and it's often difficult to find where something is defined. > > Anyway, long story short, I've decided to investigate the feasibility of rewriting the parts of GTK+ that I like directly in D. It's early days yet and the code is in a private repository on github. I'll keep it private until I have some useful subset working at which time I'll make it public. Of course, if I find that it's all too hard I'll just delete it. > > Early indications are that the code will be much simpler than the original as GTK+ implements its own OOP and GC where I'll just delegate that to D. :-) > > Peter In case you didn't know, there is a C++ wrapper for GTK+ called gtkmm (http://www.gtkmm.org/en/). It may be useful as an example of object oriented interface to GTK+. |
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Thursday, 29 August 2013 at 07:02:40 UTC, Jacob Carlborg wrote: > Well, dsource.org is dead. The projects are basically there for reference only. Most project these days are at Github. I guess there isn't an obvious way to find all of them though. Thanks for that information an for - even better - pointing me to something alive. I'll come back on that later in a more general way. > DStep is a a tool for automatically converting C headers to D modules: > > https://github.com/jacob-carlborg/dstep That's really great news, thank you! But there is a (possibly very small) but, too: Tango. Maybe I'm simply mistaken but my impression so far is: There once were 2 rt libraries, phobos and tango and (for whatever reason, no judgement implied) phobos won and today with D2 it's D + phobos, period. > There's also a Github organization dedicated to C bindings, created by the D community and language authors: > > https://github.com/D-Programming-Deimos/ > http://jkm.github.io/d-programming-language.org/deimos.html Thanks for that info. |
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 29/08/13 09:03, Nick Sabalausky wrote:
> FWIW, most of the D community has moved from dsource to github. The
> things remaining on dsource are mostly going to be older things.
The problem for newcomers that a lot of searches wind up pointing you to dsource.org pages, and there's nothing there to tell you, "Hey, go over to dlang.org or GitHub!"
At the very least I think that dlang.org ought to have a page about 3rd-party projects that notes the situation on dsource.org, and points the user to well-updated resources about currently active projects.
|
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Jurczak | I'm still a newbie, which is not a pleasant but *can* be useful because, after all, D does not intend to be or stay a rarter closed insider group and a newbie might be better able to come up with certain, possibly stupid, issues. So kindly allow me to share some thoughts with you. I hear a lot about performance and sure enough that's important. Also very important, however, is the question of available libraries and of binding C libs. If there is (and possibly DStep is) an up-to-date (workig with D2, phobos) a solution LET US ADVERTISE THAT and make it easy to find, too! This is not some luxury like D being 7% faster than, say, Pascal. This is a go-or-break issue for many who have a first look at D. I took dsource to be of relevance and learned it's not. One reason for that was that I was, of course, looking for existing modules/libraries and it seems there is not yet an "official" list of repositories and modules. Let's change that. While I personally have not much of a problem with a funny assortment of cvs, svn, bzr, git and whatnot repositories spread all over the internet, some might consider that unattractive enough to stay away from D. Maybe we should create/have sth. like "the official D modules repository" where modules are sorted (gui, db, algo, etc. - and - D2, phobos, tango based, etc), where activity or last update or similar is shown, where some maturity indicator (like 1=concept ... 5=mature/production qual.) is shown. Thanks for considering and discussing A+ -R |
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ramon | On Thu, Aug 29, 2013 at 08:50:46PM +0200, Ramon wrote: > On Thursday, 29 August 2013 at 07:02:40 UTC, Jacob Carlborg wrote: > >Well, dsource.org is dead. The projects are basically there for reference only. Most project these days are at Github. I guess there isn't an obvious way to find all of them though. > > Thanks for that information an for - even better - pointing me to > something alive. > I'll come back on that later in a more general way. I wonder if we should post a notice on dlang.org to the effect that dsource.org is dead, and that people shouldn't rely on it. Right now, having no way to actually update that site to add a notice to this effect, the first thing people are going to do when they discover D is to hit the search engines and dsource.org is inevitably going to turn up. Then it's anyone's guess whether the net effect will be positive or negative -- I'm guessing negative, a bad first impression of D that it has lots of promising but dead projects. [...] > But there is a (possibly very small) but, too: Tango. > > Maybe I'm simply mistaken but my impression so far is: There once were 2 rt libraries, phobos and tango and (for whatever reason, no judgement implied) phobos won and today with D2 it's D + phobos, period. [...] This is a dark part of D's history that people don't really like to talk about... but as I understand it (I wasn't around at the time), the story went something like this: back in the days of D1, the original version of Phobos sucked because Andrei hasn't come on board yet, so the D community, out of dissatisfaction with the state of Phobos at that time, revolted and wrote their own standard library called Tango. This was a problem, because back then, Phobos and druntime were one and the same thing, so Tango had to provide its own D runtime. This meant that programs compiled with Phobos can't be linked with programs compiled with Tango, and vice versa, since their respective runtimes would conflict. As a result, half of all D code was specific to Tango and the other half was specific to Phobos. One striking example was the concurrent incremental GC implemented for Tango: it was a superior GC (at the time) but only Tango users could reap the benefit. Things like this caused an unpleasant schism in the D community. Anyway, long story short, eventually the decision was made to move to D2, and by then, Andrei had come on board, and he made Phobos awesome (or so I heard). Druntime was separated out from Phobos so that alternative standard libraries like Tango could be supported while still allowing interoperatibility between code compiled with either library. Phobos became better and better, and eventually gained the support of the majority of D users. Tango isn't dead, though; the D2 port of Tango is alive and well, and available if you wish to use it instead of Phobos. But I'd say that the current recommendation for newcomers is to use Phobos, since Phobos idioms and conventions are quickly becoming synonymous with "the D way" nowadays. T -- Ruby is essentially Perl minus Wall. |
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
On Thursday, August 29, 2013 12:17:21 H. S. Teoh wrote:
> Druntime was separated out from Phobos so that
> alternative standard libraries like Tango could be supported while still
> allowing interoperatibility between code compiled with either library.
Actually, druntime is a fork of Tango's runtime. So, once the runtime was separated from the standard library, it's Tango's runtime which got used, not the old one that was used with D1 Phobos. But regardless, the separation of the runtime and standard library now makes it possible to swap out runtimes if you need to and still use the standard library, which wasn't possible with D1.
- Jonathan M Davis
|
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote: > I wonder if we should post a notice on dlang.org to the effect that > dsource.org is dead, and that people shouldn't rely on it. Right now, > having no way to actually update that site to add a notice to this > effect, the first thing people are going to do when they discover D is > to hit the search engines and dsource.org is inevitably going to turn > up. Then it's anyone's guess whether the net effect will be positive or > negative -- I'm guessing negative, a bad first impression of D that it > has lots of promising but dead projects. Yes. I, being a D newbie myself, can report that's exactly what happened. And it's particularly bad because, while a newb-newbie might happily hack along and learn D, a professional newbie has actual work to do. *of course* looking for what's available is one of the first things to do. This whole thing get's even more weight as D happend to be advertised like "use any C library to your liking". > [...] >> But there is a (possibly very small) but, too: Tango. >> >> Maybe I'm simply mistaken but my impression so far is: There once >> were 2 rt libraries, phobos and tango and (for whatever reason, no >> judgement implied) phobos won and today with D2 it's D + phobos, >> period. > [...] > > This is a dark part of D's history that people don't really like to talk > ... Oh, I did b no means intend to dig in wounds. My point rather is: 2 "batteries included" libs is not a good thing but a bad thing because it confuses newbies. I go with phobos because it's the official thingy and because I don't see any major obstacles or bad issues. Being as was, hase come to be and is, some cleaning might be desirable. Frankly, the only reason I didn't just click away Dstep is because it's *so* bloody important. Otherwise seeing "tango" somewhere makes me click away. OTOH binding C libraries being so bloody vital for D I feel we should a) "port" Dstep to phobos and b) advertise prominently, happily and loudly. Being able to import C libs to D quite simply is vital, it's a go or break issue for many. And if Dstep is the reasonable and working way to get that done, we should put it on the front page. --- As for the modules, dsource etc., I very strongly feel that we should go the way of Python, span and others, i.e. we should build an official repository. A+ -R |
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ramon | On 2013-08-29 20:50, Ramon wrote: > Maybe I'm simply mistaken but my impression so far is: There once were 2 > rt libraries, phobos and tango and (for whatever reason, no judgement > implied) phobos won and today with D2 it's D + phobos, period. In short: Tango for D2 is just another third party library. If I recall correctly basically the only major usage of Tango in DStep is the arguments parser. I'm practical, if something is missing, not working or not working good enough in Phobos I don't hesitate to use other libraries. -- /Jacob Carlborg |
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rikki Cattermole | On 29/08/13 16:44, Rikki Cattermole wrote:
> On Thursday, 29 August 2013 at 06:34:23 UTC, Peter Williams wrote:
>> On 29/08/13 16:11, Rikki Cattermole wrote:
>>> I will say this, one thing about D that has annoyed me from the
>>> beginning is the state of the gui libs. Hence why in last month I've
>>> been having a real good play around with OpengGL and creating my own
>>> library [1].
>>
>> On this topic, I started looking at porting one of my PyGTK
>> applications to GtkD and found that the knowledge of PyGTK API wasn't
>> a great deal of help in this endeavor. I think the problem is
>> Python's "duck typing" and dynamic typing allow for a very flexible
>> API that is much simpler than GTK+'s and GtkD's is much like GTK+'s.
>> The problem is complicated by the fact that the amount of
>> documentation is huge and it's often difficult to find where something
>> is defined.
>>
>> Anyway, long story short, I've decided to investigate the feasibility
>> of rewriting the parts of GTK+ that I like directly in D. It's early
>> days yet and the code is in a private repository on github. I'll keep
>> it private until I have some useful subset working at which time I'll
>> make it public. Of course, if I find that it's all too hard I'll just
>> delete it.
>>
>> Early indications are that the code will be much simpler than the
>> original as GTK+ implements its own OOP and GC where I'll just
>> delegate that to D. :-)
>>
>> Peter
>
> Nice :)
> Although be careful it was designed for more Posix environment.
> I'm keeping DOOGLE as far limited in terms of platform dependence.
> So porting is literally implement the OpenGL context creation and Window
> creation classes.
>
> Also for anyone interested I'm keeping the controls that require text
> out of DOOGLE because of the font rasterizer dependency.
I'm starting at the top and working towards the "down and dirty" bits so issues such as platform dependence haven't arisen yet. My strategy is to look at the header file for a widget and extract its public interface and then implement a D class with that interface using the widget's C source file for guidance.
My thinking is that when I get to the bottom I define an abstract interface for the "down and dirty" part and then implement it for the back end of my choice leaving others to do the same for the back end of their if they can't wait for me to get around to it. Design of this interface is probably something I will need assistance from people familiar with Windows/Mac/X11/Weyland so that the interface is implementable and not biased towards one or another.
|
August 29, 2013 Re: obsolete D libraries/modules | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Jurczak | On 29/08/13 19:23, Paul Jurczak wrote:
> On Thursday, 29 August 2013 at 06:34:23 UTC, Peter Williams wrote:
>> On 29/08/13 16:11, Rikki Cattermole wrote:
>>> I will say this, one thing about D that has annoyed me from the
>>> beginning is the state of the gui libs. Hence why in last month I've
>>> been having a real good play around with OpengGL and creating my own
>>> library [1].
>>
>> On this topic, I started looking at porting one of my PyGTK
>> applications to GtkD and found that the knowledge of PyGTK API wasn't
>> a great deal of help in this endeavor. I think the problem is
>> Python's "duck typing" and dynamic typing allow for a very flexible
>> API that is much simpler than GTK+'s and GtkD's is much like GTK+'s.
>> The problem is complicated by the fact that the amount of
>> documentation is huge and it's often difficult to find where something
>> is defined.
>>
>> Anyway, long story short, I've decided to investigate the feasibility
>> of rewriting the parts of GTK+ that I like directly in D. It's early
>> days yet and the code is in a private repository on github. I'll keep
>> it private until I have some useful subset working at which time I'll
>> make it public. Of course, if I find that it's all too hard I'll just
>> delete it.
>>
>> Early indications are that the code will be much simpler than the
>> original as GTK+ implements its own OOP and GC where I'll just
>> delegate that to D. :-)
>>
>> Peter
>
> In case you didn't know, there is a C++ wrapper for GTK+ called gtkmm
> (http://www.gtkmm.org/en/). It may be useful as an example of object
> oriented interface to GTK+.
Thanks, but GTK+ IS an object oriented interface (just written C) so looking at the C++ interface would just mean more work for me with little gain.
|
Copyright © 1999-2021 by the D Language Foundation