I know it's getting close, but when should we expect DTL?  Are you allowing people to look at prereleases? If not, could you be?

I ask because I am right now writing code that is in desperate need of DTL.  I'm using primitive arrays, where I should be using sets, and this is architectural code (like method signatures that'll be used everywhere), so I don't need a fully featured or fully working DTL, just basically a set of prototypes and skeleton code, which I'm sure is done.

I don't want to delay writing this stuff any more than I already have, and I don't want to rewrite it once DTL is out either.  Something of a pickle.

Thanks
John

"teqDruid" <me@teqdruid.com> wrote in message news:pan.2004.07.26.15.35.22.913434@teqdruid.com...
> I know it's getting close, but when should we expect DTL?  Are you allowing people to look at prereleases? If not, could you be?
>
> I ask because I am right now writing code that is in desperate need of DTL.  I'm using primitive arrays, where I should be using sets, and this is architectural code (like method signatures that'll be used everywhere), so I don't need a fully featured or fully working DTL, just basically a set of prototypes and skeleton code, which I'm sure is done.
>
> I don't want to delay writing this stuff any more than I already have, and I don't want to rewrite it once DTL is out either.  Something of a pickle.
>
> Thanks
> John

I know this doesn't answer your question but mintl.map can be used as a set if you just pick some random value type - eg Map!(K,int). Or if you don't need sorting a builtin assoc array int[K] would also do. My gut tells me it is too early in D's existance to consider any API as "set in stone" - we don't even have any APIs written on tissue paper much less stone. So I'd recommend being flexible.

-Ben

On Mon, 26 Jul 2004 15:58:12 -0400, Ben Hinkle wrote:

> 
> "teqDruid" <me@teqdruid.com> wrote in message news:pan.2004.07.26.15.35.22.913434@teqdruid.com...
>> I know it's getting close, but when should we expect DTL?  Are you allowing people to look at prereleases? If not, could you be?
>>
>> I ask because I am right now writing code that is in desperate need of DTL.  I'm using primitive arrays, where I should be using sets, and this is architectural code (like method signatures that'll be used everywhere), so I don't need a fully featured or fully working DTL, just basically a set of prototypes and skeleton code, which I'm sure is done.
>>
>> I don't want to delay writing this stuff any more than I already have, and I don't want to rewrite it once DTL is out either.  Something of a pickle.
>>
>> Thanks
>> John
> 
> I know this doesn't answer your question but mintl.map can be used as a set if you just pick some random value type - eg Map!(K,int). Or if you don't need sorting a builtin assoc array int[K] would also do. My gut tells me it is too early in D's existance to consider any API as "set in stone" - we don't even have any APIs written on tissue paper much less stone. So I'd recommend being flexible.
> 
> -Ben

There are all sorts of things that I *could* do, and I am doing, but it would be nice to have something that I'll keep using.  I'm assuming that DTL will become pretty standard, so I'd like to start using it- even if it's just a skeleton implementation.

Basically, if DTL is interface based (defines interfaces, and implements
them) it'd be nice if the interfaces were released soon (or now).

John

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:ce3nol$1ecd$1@digitaldaemon.com...
>
> "teqDruid" <me@teqdruid.com> wrote in message news:pan.2004.07.26.15.35.22.913434@teqdruid.com...
> > I know it's getting close, but when should we expect DTL?  Are you allowing people to look at prereleases? If not, could you be?
> >
> > I ask because I am right now writing code that is in desperate need of DTL.  I'm using primitive arrays, where I should be using sets, and this is architectural code (like method signatures that'll be used
everywhere),
> > so I don't need a fully featured or fully working DTL, just basically a set of prototypes and skeleton code, which I'm sure is done.
> >
> > I don't want to delay writing this stuff any more than I already have,
and
> > I don't want to rewrite it once DTL is out either.  Something of a
pickle.
> >
> > Thanks
> > John
>
> I know this doesn't answer your question but mintl.map can be used as a
set
> if you just pick some random value type - eg Map!(K,int). Or if you don't need sorting a builtin assoc array int[K] would also do. My gut tells me
it
> is too early in D's existance to consider any API as "set in stone" - we don't even have any APIs written on tissue paper much less stone. So I'd recommend being flexible.
>
> -Ben

In fact I've attached a little set.d for making wrappers around Map!(K,int) or int[K] depending on if sorting is needed or not. The one usability issue with this approach is that the "int" will show up in foreach statements or other signatures. But it works pretty well in general. I'll probably expand out the doc and dump it into mintl.

-Ben

I'm still working away, whenever I can grab the time away.

I've spent the whole day on it today, and I intend to release *something* before I go to bed tonight, but I tell you it's incredibly frustrating work because the compiler is still so full of bugs. Plenty of times I'm having to think of neat workarounds, or just leaving out swathes of functionality, because either the compiler crashes, or the exe won't link, or the exe crashes.

FTR, I've got List, Map, Vector, Stack, and Queue, in varying degrees of completeness, and may have Set done also soon. By "varying degrees of completeness", this means whether or not they support the different enumeration models: foreach, ranges, Object-interfaces and parameterised interfaces. I'll provide a table of completeness in the docs when I release, so I'm not seen to be promising functionality that does not exist.

I apologise _again_ to everyone who's (still) interested, but I promise I'm not just wagging my tail out here.

Anyway, I'm getting to the point where the frustrations of working with the current state of the compiler/language are becoming quite demotivating, so I intend to get out what I can in the next day or so, and then let all the many smart minds out there have a look, and hopefully pick up things I've missed.

Cheers

Matthew


"teqDruid" <me@teqdruid.com> wrote in message news:pan.2004.07.26.15.35.22.913434@teqdruid.com...
> I know it's getting close, but when should we expect DTL?  Are you allowing people to look at prereleases? If not, could you be?
>
> I ask because I am right now writing code that is in desperate need of DTL.  I'm using primitive arrays, where I should be using sets, and this is architectural code (like method signatures that'll be used everywhere), so I don't need a fully featured or fully working DTL, just basically a set of prototypes and skeleton code, which I'm sure is done.
>
> I don't want to delay writing this stuff any more than I already have, and I don't want to rewrite it once DTL is out either.  Something of a pickle.
>
> Thanks
> John

Well, I'm far from a smart mind but I'm a smart ass and have a way of working around crap or throwing stuff against walls and giving up. Either one is cool and perhaps speaking my mind but I guess I should be nice since you may or may not release it tonight at a certain level of completeness.

> I'm still working away, whenever I can grab the time away.
> 
> I've spent the whole day on it today, and I intend to release *something* before I go to bed tonight, but I tell you
> it's incredibly frustrating work because the compiler is still so full of bugs. Plenty of times I'm having to think of
> neat workarounds, or just leaving out swathes of functionality, because either the compiler crashes, or the exe won't
> link, or the exe crashes.
> 
> FTR, I've got List, Map, Vector, Stack, and Queue, in varying degrees of completeness, and may have Set done also soon.
> By "varying degrees of completeness", this means whether or not they support the different enumeration models: foreach,
> ranges, Object-interfaces and parameterised interfaces. I'll provide a table of completeness in the docs when I release,
> so I'm not seen to be promising functionality that does not exist.
> 
> I apologise _again_ to everyone who's (still) interested, but I promise I'm not just wagging my tail out here.
> 
> Anyway, I'm getting to the point where the frustrations of working with the current state of the compiler/language are
> becoming quite demotivating, so I intend to get out what I can in the next day or so, and then let all the many smart
> minds out there have a look, and hopefully pick up things I've missed.
> 
> Cheers
> 
> Matthew

I'm still drowning under compiler bugs. (See my rant on the digitalmars.D ng)

"Gold Dragon" <dragonwing@dragonu.net> wrote in message news:ceagec$192k$1@digitaldaemon.com...
> Well, I'm far from a smart mind but I'm a smart ass and have a way of working around crap or throwing stuff against walls and giving up. Either one is cool and perhaps speaking my mind but I guess I should be nice since you may or may not release it tonight at a certain level of completeness.
>
> > I'm still working away, whenever I can grab the time away.
> >
> > I've spent the whole day on it today, and I intend to release *something* before I go to bed tonight, but I tell you it's incredibly frustrating work because the compiler is still so full of bugs. Plenty of times I'm having to think
of
> > neat workarounds, or just leaving out swathes of functionality, because either the compiler crashes, or the exe
won't
> > link, or the exe crashes.
> >
> > FTR, I've got List, Map, Vector, Stack, and Queue, in varying degrees of completeness, and may have Set done also
soon.
> > By "varying degrees of completeness", this means whether or not they support the different enumeration models:
foreach,
> > ranges, Object-interfaces and parameterised interfaces. I'll provide a table of completeness in the docs when I
release,
> > so I'm not seen to be promising functionality that does not exist.
> >
> > I apologise _again_ to everyone who's (still) interested, but I promise I'm not just wagging my tail out here.
> >
> > Anyway, I'm getting to the point where the frustrations of working with the current state of the compiler/language
are
> > becoming quite demotivating, so I intend to get out what I can in the next day or so, and then let all the many
smart
> > minds out there have a look, and hopefully pick up things I've missed.
> >
> > Cheers
> >
> > Matthew