www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Most important issues for D (MIID)

reply "Walter" <newshound digitalmars.com> writes:
In some delightful ways, D is a victim of its own success. There's a lot of
traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
a day goes by without new proposals for features. It's simply beyond my
capacity to give these all the attention they deserve, or even to read them
all. I probably spend a minimum of 2 hours a day reading messages, and I
could easilly spend 12 hours a day at it, and accomplish nothing else.

Hence, I inadvertently overlook important issues. I know that this has been
frustrating to some people, and I apologize for it.

So I'd like to kick off this thread as an opportunity for all to post their
two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
mean pragmatic things like:

1) compiler bugs
2) language shortcomings with no reasonable workarounds
3) issues that are fundamentally blocking projects from using or proceeding
with D
4) severe library faults

I don't mean things like:

1) D 2.0 issues
2) feature proposals like "It would be nice if ..."
3) minor irritants
4) philosophical issues
5) issues that have been beaten to death already <g>

If a thread here exists for the topic, a reference to that thread would be
nice rather than reproducing it.

It's time to prioritize and get us on a rational, sensible path for
releasing 1.0.
Sep 10 2004
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
#1 DLL's + GC + threading. This is a sine qua non for D, and I'd hazard to
suggest it may be the most important thereof. 
I'd suggest Eric and Kris write a discussion paper/proposal on this, which I'd
be happy to review/slag/bemoan, but I 
think Kris is holidaying at the moment. Eric, if you want to make a start,
that'd be cool, or we can wait for the return 
of our demure friend.
#2 The parlous and inconsistent state of Phobos. Phobos needs to be a killer
library when 1.0 launches: lean, efficient, 
cohesive, low-coupling, discoverable, expressive, and without inconsistency.
Currently it is a scrappy, crappy, 
embarassing mess (and I'm in no way exempting some of my own contributions).
We're going to start with an Exceptions 
refactoring. Hopefully, that will be the start of several such
reviews/refactorings, and we'll eventually end up with 
something grand.


"Walter" <newshound digitalmars.com> wrote in message
news:cht9gl$20m8$1 digitaldaemon.com...
 In some delightful ways, D is a victim of its own success. There's a lot of
 traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
 a day goes by without new proposals for features. It's simply beyond my
 capacity to give these all the attention they deserve, or even to read them
 all. I probably spend a minimum of 2 hours a day reading messages, and I
 could easilly spend 12 hours a day at it, and accomplish nothing else.

 Hence, I inadvertently overlook important issues. I know that this has been
 frustrating to some people, and I apologize for it.

 So I'd like to kick off this thread as an opportunity for all to post their
 two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
 mean pragmatic things like:

 1) compiler bugs
 2) language shortcomings with no reasonable workarounds
 3) issues that are fundamentally blocking projects from using or proceeding
 with D
 4) severe library faults

 I don't mean things like:

 1) D 2.0 issues
 2) feature proposals like "It would be nice if ..."
 3) minor irritants
 4) philosophical issues
 5) issues that have been beaten to death already <g>

 If a thread here exists for the topic, a reference to that thread would be
 nice rather than reproducing it.

 It's time to prioritize and get us on a rational, sensible path for
 releasing 1.0.

 

Sep 10 2004
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Issues that have affected me personally:

Partially broken TypeId's for pointers and structs.  Reference here:
digitalmars.D.bugs/1293

An access problem with private members in nested classes.  Reference here:
digitalmars.D.bugs/1189

Bug with stdargs used in multiple translation units.  Reference here:
digitalmars.D.bugs/1137

Beyond that, I think Eric's thread about module imports deserves some attention.
At the very least, I think it is important that every module that has a static
constructor has that constructor called on initialization (I think this was an
issue with private imports), and that module initialization order is correct
whenever appropriate.  I agree that if a module has no static constructor then
its order in initialization shouldn't matter.

Also, Matthew's mention of dlls, gc, and threading are all quite important,
though I haven't played with that stuff enough to know the issues very well.
And exceptions need to be sorted out, but Matthew is currently working on that.


Sean
Sep 10 2004
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:chtckm$21uv$1 digitaldaemon.com...
 Beyond that, I think Eric's thread about module imports deserves some

 At the very least, I think it is important that every module that has a

 constructor has that constructor called on initialization (I think this

 issue with private imports), and that module initialization order is

 whenever appropriate.  I agree that if a module has no static constructor

 its order in initialization shouldn't matter.

This is fixed, will go out in next update.
Sep 10 2004
prev sibling next sibling parent Joey Peters <Joey_member pathlink.com> writes:
I'll try to reproduce a bug.

1)

#class Array(T) {
#public:
#	T[] data;
#public:
#	void bug() {
#		printf("Why is this happening?");
#	}
#	// this seems to cause the problem, take it out and it will work
#	int opCast() {
#		return data.length;
#	}
#}
#
#class StringTemplate(T) : Array!(T) {
#public:
#	this(T[] l) {
#		data = l;
# 	}	
# 	this() { }
#}
#
#alias StringTemplate!(char) String;
#
#void main() {
#	String a = new String;
#	a.bug(); // taking this out also helps, it seems to be related to opCast
#}

It seems base classes don't like cast overloading so well. It doesn't crash the
compiler, it doesn't even output an error, it just happily quits. (actually I'm
not that high on what kind of emotions compilers have)

2)

This is more some kind of a feature request. I've found more bugs though I can't
seem to isolate them, so that would be pointles. Anyway, what I'd like to see is
that something like this would be possible:

#class Array(T) {
#public:
#   ...
#   Array!(typeof(this)) split(T by) {
#       ...
#   }
#}

I can see it would be hard to add since it would be recursive. Though, maybe it
would be useful (especially for making a stl make sense) to somehow make it that
when the compiler finds a return type similar to a template construction, it
doesn't create the class from the template yet, rather he only does that once it
finds the function being called, keeping it from doing pointles recursion.

It's minor though ;) But it would make sense. You could make things like:

new String("file.exe").split('.').top();

more easily (actually that would be the only way, if you want to maintain
concistancy (?)). Whereas now you have to (from a more developed point of view):

String[] a = new String("file.exe").split('.');
String ext = a[a.length - 1];

or when you're smart, you could make split in the template, so you'd call it
String.split(new String()).top(), but that would look, I don't know, weirdish.
It's like making OO modular, where every member function of a class is also
member of the global namespace, but with left side arguments (bar from Foo can
be using in global as bar(foo_object)). Though this sometimes is a good thing,
you'd often want to be able to do both.

Anyway, not important ;)

3) I'm a rebel ;)

I agree that phobos should be better. A lot better. Maybe it should even be
recoded from scratch. I'm currently working on my own stl, dragonstl, which also
provides a minor wrapper around phobos. I mean, wrapping D in D? They should
totally drop things like printf, and they should try writing the whole thing in
pure D (it's capable). I would like to help with phobos but I don't think I'm
good enough, I can be volunteer idiot though.

-Joey

In some delightful ways, D is a victim of its own success. There's a lot of
traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
a day goes by without new proposals for features. It's simply beyond my
capacity to give these all the attention they deserve, or even to read them
all. I probably spend a minimum of 2 hours a day reading messages, and I
could easilly spend 12 hours a day at it, and accomplish nothing else.

Hence, I inadvertently overlook important issues. I know that this has been
frustrating to some people, and I apologize for it.

So I'd like to kick off this thread as an opportunity for all to post their
two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
mean pragmatic things like:

1) compiler bugs
2) language shortcomings with no reasonable workarounds
3) issues that are fundamentally blocking projects from using or proceeding
with D
4) severe library faults

I don't mean things like:

1) D 2.0 issues
2) feature proposals like "It would be nice if ..."
3) minor irritants
4) philosophical issues
5) issues that have been beaten to death already <g>

If a thread here exists for the topic, a reference to that thread would be
nice rather than reproducing it.

It's time to prioritize and get us on a rational, sensible path for
releasing 1.0.

Sep 10 2004
prev sibling next sibling parent h3r3tic <h3r3tic dev.null> writes:
#1:

<snip>
void foo()
{
     class Foo
     {
         int x;
     }
}

void bar()
{
     class Foo
     {
         int y;
     }

     Foo f = new Foo;
     f.y = 5;
}

void main()
{
}
</snip>

<result>
foo.d(17): no property 'y' for type 'Foo'
</result>

<comment>
the class Foo declared in function foo somehow obscures the Foo class in 
function bar. This should not be the case ;)
</comment>



#2:

it would be nice if array arithmetic operations were implemented in ANY 
way so we can start using them



Keep up the good work !
Tom
Sep 10 2004
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
#1) compile loader.d into libphobos.a on linux

#2) when you use goto label; and there is no label "label," it spits out 
  this horrid error message "Error: undefined label bob" that doesn't 
give filename or line number.

Walter wrote:
 In some delightful ways, D is a victim of its own success. There's a lot of
 traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
 a day goes by without new proposals for features. It's simply beyond my
 capacity to give these all the attention they deserve, or even to read them
 all. I probably spend a minimum of 2 hours a day reading messages, and I
 could easilly spend 12 hours a day at it, and accomplish nothing else.
 
 Hence, I inadvertently overlook important issues. I know that this has been
 frustrating to some people, and I apologize for it.
 
 So I'd like to kick off this thread as an opportunity for all to post their
 two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
 mean pragmatic things like:
 
 1) compiler bugs
 2) language shortcomings with no reasonable workarounds
 3) issues that are fundamentally blocking projects from using or proceeding
 with D
 4) severe library faults
 
 I don't mean things like:
 
 1) D 2.0 issues
 2) feature proposals like "It would be nice if ..."
 3) minor irritants
 4) philosophical issues
 5) issues that have been beaten to death already <g>
 
 If a thread here exists for the topic, a reference to that thread would be
 nice rather than reproducing it.
 
 It's time to prioritize and get us on a rational, sensible path for
 releasing 1.0.
 
 

Sep 10 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
On Fri, 10 Sep 2004 15:18:03 -0700, "Walter"
<newshound digitalmars.com> wrote:

In some delightful ways, D is a victim of its own success. There's a lot of
traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
a day goes by without new proposals for features. It's simply beyond my
capacity to give these all the attention they deserve, or even to read them
all. I probably spend a minimum of 2 hours a day reading messages, and I
could easilly spend 12 hours a day at it, and accomplish nothing else.

Hence, I inadvertently overlook important issues. I know that this has been
frustrating to some people, and I apologize for it.

So I'd like to kick off this thread as an opportunity for all to post their
two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
mean pragmatic things like:

1) compiler bugs
2) language shortcomings with no reasonable workarounds
3) issues that are fundamentally blocking projects from using or proceeding
with D
4) severe library faults

I don't mean things like:

1) D 2.0 issues
2) feature proposals like "It would be nice if ..."
3) minor irritants
4) philosophical issues
5) issues that have been beaten to death already <g>

If a thread here exists for the topic, a reference to that thread would be
nice rather than reproducing it.

It's time to prioritize and get us on a rational, sensible path for
releasing 1.0.

* compiler bug with volatile statements and templates: digitalmars.D.bugs/1668 * any writef bug or stdarg bug. Is the following still a problem? digitalmars.D/5757 I can't reproduce it on Windows. I've started shying away from writef because I don't trust it. Also I'd like to make sure the Linux support is on par with the Windows support. Last time I tried I had troubles recompiling phobos on Linux. Walter have you recompiled phobos from scratch with unittests on Linux recently? Does it pass? I seem to always have to clean up phobos before it gets close to working. See, for example, digitalmars.D/9119
Sep 10 2004
parent reply "BUDI ARIEF GUSANDI" <budi online.ie> writes:
Dear all,

I'm a beginner to C and C++. Yesterday i search over internet and found D  
is easiest to learn than
the predeccessors and very comfortable for me. But several question makes  
me a little doubt, please
help.

1. D can only run on Windows Console, i can not run it in pure DOS  
Console. This is is something
very important since C and C++ can do that. How can i run it on embedded  
system if it should require
windows ?
2. The executable file size is so big, test using "Hello World" program  
around 97 kb and in linux it's bigger. Is that because D runs in
win32 console mode ? Even i use exe compressor, the size doesn't cut for  
the half of the original
size instead.

Thank you. Keep up good working

Regards,

Budi
Sep 16 2004
next sibling parent reply Martin <Martin_member pathlink.com> writes:
I'm a beginner to C and C++. Yesterday i search over internet and found D  
is easiest to learn 

Yes D is a very good language. If you have any questions, feel free to contact me, if you want. Send an email to arvutilaat at arvutilaat.net (where "at" if ofcourse) I have many junk mails coming to that mail address, so the subject line should be something like "D question", so I can recognise it. If you are a beginner to D, or to the programming I can help you. I have worked with D since this spring and have been programming C over 8 years and C++ over 4 or 5 years. And I am ready to answer some newbie questions. Ofcourse you can send questions to this forum. Here are many experts, who can help you, including Walter, the man who makes the D language and the dmd compiler.
1. D can only run on Windows Console, i can not run it in pure DOS  
Console. This is is something
very important since C and C++ can do that. How can i run it on embedded  
system if it should require
windows ?

Yes D works only in windows and linux for now. Maybe in the future more OS will be supported.
2. The executable file size is so big, test using "Hello World" program  
around 97 kb and in linux it's bigger. Is that because D runs in
win32 console mode ? Even i use exe compressor, the size doesn't cut for  
the half of the original
size instead.

That is because D likes to compile everything it can into it's exe (or ELF-linux) file, so no one should have problems running these files. For example if you make a program in Visul C, then by default it makes a smaller file, but it requires many dll-s. I have downloaded some programs from the internet and then spent hours searching the required dll files. So D files are bigger, but you should have less problems running them on other computers. Greetings, Martin. In article <opseeytqz4ukcpn4 telkomnetinstan>, BUDI ARIEF GUSANDI says...
Dear all,

I'm a beginner to C and C++. Yesterday i search over internet and found D  
is easiest to learn than
the predeccessors and very comfortable for me. But several question makes  
me a little doubt, please
help.

1. D can only run on Windows Console, i can not run it in pure DOS  
Console. This is is something
very important since C and C++ can do that. How can i run it on embedded  
system if it should require
windows ?
2. The executable file size is so big, test using "Hello World" program  
around 97 kb and in linux it's bigger. Is that because D runs in
win32 console mode ? Even i use exe compressor, the size doesn't cut for  
the half of the original
size instead.

Thank you. Keep up good working

Regards,

Budi

Sep 16 2004
next sibling parent Toaster <wb sapo.pt> writes:
On Thu, 16 Sep 2004 10:22:05 +0000 (UTC), Martin
<Martin_member pathlink.com> wrote:
1. D can only run on Windows Console, i can not run it in pure DOS  
Console. This is is something
very important since C and C++ can do that. How can i run it on embedded  
system if it should require
windows ?

Yes D works only in windows and linux for now. Maybe in the future more OS will be supported.

Besides the OS support which hopefully will grow, isn't it true that D is being designed a language that can produce compiled code that doesn't depend on any OS, allowing, for example, to write a bootable program? I think that is what the original question was about.
Sep 16 2004
prev sibling parent reply Jens <Jens_member pathlink.com> writes:
In article <cibpgd$2efk$1 digitaldaemon.com>, Martin says...

2. The executable file size is so big, test using "Hello World" program  
around 97 kb and in linux it's bigger. Is that because D runs in
win32 console mode ? Even i use exe compressor, the size doesn't cut for  
the half of the original
size instead.

That is because D likes to compile everything it can into it's exe (or ELF-linux) file, so no one should have problems running these files. For example if you make a program in Visul C, then by default it makes a smaller file, but it requires many dll-s. I have downloaded some programs from the internet and then spent hours searching the required dll files. So D files are bigger, but you should have less problems running them on other computers.

If you use the DigitalMars C compiler (i.e. you write a console Hello World program in plain C) you get "only" 39 KB. I never experienced any dependency on any DLL, though, not even MSVCRT.DLL or CRTDLL.DLL. Strangely, D *does* use the C module for printf, doesn't it? Then why don't they have the same size? Regards, Jens
Sep 16 2004
next sibling parent Deja Augustine <deja scratch-ware.net> writes:
Jens wrote:

 In article <cibpgd$2efk$1 digitaldaemon.com>, Martin says...
 
 
2. The executable file size is so big, test using "Hello World" program  
around 97 kb and in linux it's bigger. Is that because D runs in
win32 console mode ? Even i use exe compressor, the size doesn't cut for  
the half of the original
size instead.

That is because D likes to compile everything it can into it's exe (or ELF-linux) file, so no one should have problems running these files. For example if you make a program in Visul C, then by default it makes a smaller file, but it requires many dll-s. I have downloaded some programs from the internet and then spent hours searching the required dll files. So D files are bigger, but you should have less problems running them on other computers.

If you use the DigitalMars C compiler (i.e. you write a console Hello World program in plain C) you get "only" 39 KB. I never experienced any dependency on any DLL, though, not even MSVCRT.DLL or CRTDLL.DLL. Strangely, D *does* use the C module for printf, doesn't it? Then why don't they have the same size? Regards, Jens

D automatically links phobos.lib. That's the cause for the extra bloat. But to be completely serious, what the hell kind of difference is 58kb going to make on todays machines? The only instance I can think of is if you were developing for a PDA, and even then a 100kb executable doesn't seem excessively bloated. -Deja
Sep 16 2004
prev sibling parent Regan Heath <regan netwin.co.nz> writes:
On Fri, 17 Sep 2004 00:26:01 +0000 (UTC), Jens <Jens_member pathlink.com> 
wrote:

 In article <cibpgd$2efk$1 digitaldaemon.com>, Martin says...

 2. The executable file size is so big, test using "Hello World" program
 around 97 kb and in linux it's bigger. Is that because D runs in
 win32 console mode ? Even i use exe compressor, the size doesn't cut 
 for
 the half of the original
 size instead.

That is because D likes to compile everything it can into it's exe (or ELF-linux) file, so no one should have problems running these files. For example if you make a program in Visul C, then by default it makes a smaller file, but it requires many dll-s. I have downloaded some programs from the internet and then spent hours searching the required dll files. So D files are bigger, but you should have less problems running them on other computers.

If you use the DigitalMars C compiler (i.e. you write a console Hello World program in plain C) you get "only" 39 KB. I never experienced any dependency on any DLL, though, not even MSVCRT.DLL or CRTDLL.DLL. Strangely, D *does* use the C module for printf, doesn't it? Then why don't they have the same size?

The difference in size IIRC is due to the garbage collector, in a D application the garbage collecting code is built into the executable. This extra size is a one off cost, I've heard it said that a larger application written in D will actually be smaller than the equivalent one in C. It is intended, but not yet possible (I believe) to completely disable the garbage collector, meaning that you can write a D application without one, this is what you'd do to write an embedded program that has size constraints. Ideally the GC would be part of the Operating System, if that were the case it would not be built into the application, could be more efficient, and would solve the problems that arise using a GC with DLL's etc. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Sep 16 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
BUDI ARIEF GUSANDI wrote:
<snip>
 1. D can only run on Windows Console, i can not run it in pure DOS  
 Console.

Yes, because MS-DOS is a 16-bit system. D needs at least a 32-bit system, by design.
 This is is something very important since C and C++ can do that.

Walter didn't consider it worth putting in features to support legacy OSs. http://www.digitalmars.com/d/overview.html Features To Drop ... Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures.
 How can i run it on embedded system if it should require windows ?

Not sure what you mean by that.... Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 16 2004
next sibling parent "BUDI ARIEF GUSANDI" <budi online.ie> writes:
 How can i run it on embedded system if it should require windows ?

Not sure what you mean by that....

Flash ROM in Single Board Computer (SBC) or embedded computer, which of course has minimal size and memory to run, and most of SBC using 386 processor, which definitely using DOS 16 Bit for OS, unless we create our own OS or using linux embedded but will need some extra cost for additional memory and flash disk... Thanks Anyway ;) Budi
Sep 16 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Stewart Gordon schrieb:

 BUDI ARIEF GUSANDI wrote:
 <snip>
 
 1. D can only run on Windows Console, i can not run it in pure DOS  
 Console.

Yes, because MS-DOS is a 16-bit system. D needs at least a 32-bit system, by design.

Someone got some DMD-made code work on DOS using a 32-bit DOS-extender, if i recall correctly.
 This is is something very important since C and C++ can do that.


Using advanced C++ on a 16-bit system looks like trouble to me, due to 64 kilobytes allocation unit maximum. GCC doesn't work on 16-bit systems either, yet there is DJGPP (using an extender), so if there is a recent DJGPP update, combining it with GDC would get you a DOS-compatible D compiler.
 How can i run it on embedded system if it should require windows ?


You can make it run under just about any 32-bit operating system, DOS extender being no exception. About the executable size: it comes from the basic libraries. You would need to rework them for an embedded system anyway, and i'm sure one can make the problem go away with it. On the other hand, i recall DJGPP generated executables were quite big, however the extender removes code size restrictions so you need not care any longer. :> -eye
Sep 24 2004
prev sibling next sibling parent Ant <duitoolkit yahoo.ca> writes:
On Fri, 10 Sep 2004 15:18:03 -0700, Walter wrote:

 In some delightful ways, D is a victim of its own success.

 I inadvertently overlook important issues. I know that this has been
 frustrating to some people, and I apologize for it.

no need to appologize, we thank you for your efford! here is a quote from a post on slashdot: " When a volunteer gives you a product for free and it is defective, you let the person know what's wrong, offer to retest it if they try to fix it, and if you have any time & talent to draw on, you offer to fix the problem and send in a patch. You NEVER, EVER complain. The worst you have the right to say is "I hope they take care of it in the next release". " http://developers.slashdot.org/developers/04/09/08/125208.shtml?tid=104&tid=152&tid=8
 two Most Important Issues

1) ability to generate shared libraries on linux. 2) add symbolic debug info on linux. Ant
Sep 10 2004
prev sibling next sibling parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
<alert comment="newbie">

Reasonably stable and mature "official" gui library with enough widgets to
put simple non-console apps together (may or may not be all that portable)

Reasonably stable and mature ide with symbolic debugger and step-into and
step-over. If already available, documentation for it.

</alert>
Sep 11 2004
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Lynn Allan" <l_d_allan adelphia.net> wrote in message
news:chuk7d$2mrs$1 digitaldaemon.com...
 <alert comment="newbie">

 Reasonably stable and mature "official" gui library with enough widgets to
 put simple non-console apps together (may or may not be all that portable)

A gui library will probably be a good idea around version 2.0 or 3.0. A 1.0 language and core library is probably going to be too early to use to build complex apps or libraries. Look at AWT and how now Java Swing has various warts because of backwards compatibility with it.
 Reasonably stable and mature ide with symbolic debugger and step-into and
 step-over. If already available, documentation for it.

ah, yeah. that would be very helpful.
 </alert>

Sep 11 2004
parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:chvkmg$2u6$1 digitaldaemon.com...
 "Lynn Allan" <l_d_allan adelphia.net> wrote in message
 news:chuk7d$2mrs$1 digitaldaemon.com...
 <alert comment="newbie">

 Reasonably stable and mature "official" gui library with enough widgets


 put simple non-console apps together (may or may not be all that


 A gui library will probably be a good idea around version 2.0 or 3.0. A

 language and core library is probably going to be too early to use to

 complex apps or libraries. Look at AWT and how now Java Swing has various
 warts because of backwards compatibility with it.

 Reasonably stable and mature ide with symbolic debugger and step-into


 step-over. If already available, documentation for it.

ah, yeah. that would be very helpful.
 </alert>


I hesitated to submit the 2 MIID that I did. Clearly they were at least somewhat outside what "The WB" was asking. And I appreciate your patient, gentle reply to this newbie. However ... I would speculate that any relatively general purpose language will have an "uphill battle" for acceptance and "critical mass" if gui apps are difficult to accomplish. Is there really a need for yet another language for embedded and console apps? I used AWT for a relatively simple freeware app and found it acceptable. If a gui library equivalent to AWT was available for "D", I would now be deciding whether to commence development on a freeware app now in the planning stage, or porting two existing freeware apps to "D". Similarly, a development tool with a decent debugger is much easier to learn and use. I probably overuse debuggers, but the ability to step-into code and directly see what is going on with an object probably facilitates my "getting up to speed" with a new language by an order of magnitude.
Sep 11 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <chvtiv$75r$1 digitaldaemon.com>, Lynn Allan says...
I would speculate that any relatively general purpose language will have an
"uphill battle" for acceptance and "critical mass" if gui apps are difficult
to accomplish. Is there really a need for yet another language for embedded
and console apps?

There are very few standalone languages that have shipped with GUI support. In fact Java is just about the only one I can think of. And Java totally scapped their GUI api and started over around version 1.4. As for the need for a new system language, I think we do or I wouldn't be here. C++ is an incredibly powerful but I can't help but feel it could be better if it weren't stuck with all sorts of legacy issues. D offers a chance to start fresh and so far I think Walter has done a tremendous job with the design. If you want more out of D you're certainly welcome to make it whatever you want. There are plenty of library features I'd like to see, but the groundwork has to be laid first--language issues, core library support (garbage collection, exceptions, threading)--before that level of work can really begin.
Similarly, a development tool with a decent debugger is much easier to learn
and use. I probably overuse debuggers, but the ability to step-into code and
directly see what is going on with an object probably facilitates my
"getting up to speed" with a new language by an order of magnitude.

Agreed. I think Eclipse may be D's best shot at a native IDE, but I haven't been able to get the D plugin working yet (though I hope to find more time to play with it in the next week or so). Again, this is something that the community could provide, as it isn't really necessary to get the compiler finished and such. Sean
Sep 11 2004
parent reply ninjadroid <ninjadroid gazuga.net> writes:
In article <ci00oi$89c$1 digitaldaemon.com>, Sean Kelly says...
Agreed.  I think Eclipse may be D's best shot at a native IDE, but I haven't
been able to get the D plugin working yet (though I hope to find more time to
play with it in the next week or so).  Again, this is something that the
community could provide, as it isn't really necessary to get the compiler
finished and such.

I just came back from a solid hour of arguing with eclipse. In my humblest opinion, I think D deserves better than that. Caveat being that I seem to have reluctantly become an emacs fag*, and can't get my brain around any of the Real IDEs I've recently tried. Eclipse, however, seems particularly disagreeable. Whereas the alternatives I've tried, primarily anjuta, merely felt unfinished in this or that regard, eclipse feels over done. *Way* overdone. Whenever I encounter the behemoth, I'm reminded of the Monty Python bit with the corpulent fellow who eats just a lil' too much. And remember, this is the perspective of an *EMACS* user. I'm no stranger to "big." * If you take offense of my use of the word "fag" because of it's colloquial use as a disparaging remark for those with a minority sexual orientation, I suggest lightening up; I certainly don't mean for the locution to be interpreted in such a manner, so don't. On the other hand, if you're offended by the fact that I'm an emacs user, don't be; I feel like a heroin addict, and I'd do pretty much anything to kick this habit. Emacs is stuck in 197*, and it chaps my ass. However, it gets the gist of things *very* right, and I think I'd have an easier time dragging emacs into the 21st century than adding what's missing to the alternatives (and I'm not referring to Gnus *shudder*).
Sep 11 2004
parent reply Sean Kelly <sean f4.ca> writes:
ninjadroid wrote:
 In article <ci00oi$89c$1 digitaldaemon.com>, Sean Kelly says...
 
Agreed.  I think Eclipse may be D's best shot at a native IDE, but I haven't
been able to get the D plugin working yet (though I hope to find more time to
play with it in the next week or so).  Again, this is something that the
community could provide, as it isn't really necessary to get the compiler
finished and such.

I just came back from a solid hour of arguing with eclipse. In my humblest opinion, I think D deserves better than that. Caveat being that I seem to have reluctantly become an emacs fag*, and can't get my brain around any of the Real IDEs I've recently tried. Eclipse, however, seems particularly disagreeable. Whereas the alternatives I've tried, primarily anjuta, merely felt unfinished in this or that regard, eclipse feels over done. *Way* overdone. Whenever I encounter the behemoth, I'm reminded of the Monty Python bit with the corpulent fellow who eats just a lil' too much. And remember, this is the perspective of an *EMACS* user. I'm no stranger to "big."

I use emacs and like it a lot, but its interactive debugging support is pretty sparse (last I saw it just had a bit of gdb integration). Eclipse seemed promising because it's essentially an IDE toolkit, but I agree that it's kind of much. On the emacs end, if you're inclined to improve the D syntax hilighting mode for emacs, please do. I've actually fallen back on UltraEdit recently because emacs does odd things with D source and it's gotten irritating. Sean
Sep 11 2004
parent Ben Hinkle <bhinkle4 juno.com> writes:
[snip]

  On the emacs end, if you're inclined to
 improve the D syntax hilighting mode for emacs, please do.  I've
 actually fallen back on UltraEdit recently because emacs does odd things
 with D source and it's gotten irritating.

I second that. Anyone willing to improve the emacs mode please feel free to jump on in. The current support is 99.9% the C/C++/Java engine so it doesn't handle D all that well and my emacs lisp is... well... terrible. -Ben
Sep 11 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Lynn Allan wrote:
 I hesitated to submit the 2 MIID that I did. Clearly they were at least
 somewhat outside what "The WB" was asking. And I appreciate your patient,
 gentle reply to this newbie.
 
 However ...
 
 I would speculate that any relatively general purpose language will have an
 "uphill battle" for acceptance and "critical mass" if gui apps are difficult
 to accomplish. Is there really a need for yet another language for embedded
 and console apps? I used AWT for a relatively simple freeware app and found
 it acceptable. If a gui library equivalent to AWT was available for "D", I
 would now be deciding whether to commence development on a freeware app now
 in the planning stage, or porting two existing freeware apps to "D".
 
 Similarly, a development tool with a decent debugger is much easier to learn
 and use. I probably overuse debuggers, but the ability to step-into code and
 directly see what is going on with an object probably facilitates my
 "getting up to speed" with a new language by an order of magnitude.

The thing is, neither of these issues are in Walter's hands. :) Walter is the only one who can make improvements to the compiler itself, so it stands to reason that it be his primary focus. The auxiliary code monkeys (that's us!) can handle most everything else. -- andy
Sep 11 2004
next sibling parent Benjamin Herr <ben 0x539.de> writes:
Andy Friesen wrote:
 Walter is the only one who can make improvements to the compiler itself, 

Hm, why is that the case? -ben
Sep 11 2004
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <ci01kt$8gj$1 digitaldaemon.com>, Andy Friesen says...
 GUI 
 debugger

Walter is the only one who can make improvements to the compiler itself, so it stands to reason that it be his primary focus. The auxiliary code monkeys (that's us!) can handle most everything else.

Totally agree, these are just "marketing" issues not language/library issues why bother Walter with this stuff
Sep 17 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <ciep4v$1c1t$1 digitaldaemon.com>, Mark T says...
In article <ci01kt$8gj$1 digitaldaemon.com>, Andy Friesen says...
 GUI 
 debugger

Walter is the only one who can make improvements to the compiler itself, so it stands to reason that it be his primary focus. The auxiliary code monkeys (that's us!) can handle most everything else.

Totally agree, these are just "marketing" issues not language/library issues why bother Walter with this stuff

The debugger issue /IS/ in Walter's hands. It's a compiler problem, and Walter is the only one who can fix it. Nobody is suggesting that Walter write an IDE. Fact is, there are plenty of existing IDEs around that work fine. I use MS Visual Studio, for example, and this debugger is pretty damn good. I don't have any complaints about it. However, it can't (for instance) step into D template code without getting lost. The reason for this is nothing to do with MS Visual Studio. If I have understood this correctly, the fault lies with the DMD compiler, for failing to insert sufficient debugging code into the executable. That is why we must bother Walter with this stuff. Arcane Jill
Sep 17 2004
prev sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
 I hesitated to submit the 2 MIID that I did. Clearly they were at least
 somewhat outside what "The WB" was asking. And I appreciate your patient,
 gentle reply to this newbie.

Actually I probably shouldn't have responded to your post since this thread is really for feedback to Walter. Sorry for singling your post out but I agree the topic of a GUI framework is very important and I couldn't resist commenting. I had the same impression you did when I first started learning about D and not seeing anything about GUI frameworks. Your comments provide an important "reality check" for what is expected nowadays in a language and the libs and tools.
Sep 11 2004
parent reply "Lynn Allan" <l_d_allan adelphia.net> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:ci0bq2$iof$1 digitaldaemon.com...
 about D and not seeing anything about GUI frameworks.

As noted in a related MIID post, a stable GUI framework is pretty much a prerequisite to an IDE/Debugger. The DigDug project is currently suspended until a mature GUI framework is available.
Sep 14 2004
parent Sean Kelly <sean f4.ca> writes:
In article <ci7pr9$bbu$1 digitaldaemon.com>, Lynn Allan says...
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:ci0bq2$iof$1 digitaldaemon.com...
 about D and not seeing anything about GUI frameworks.

As noted in a related MIID post, a stable GUI framework is pretty much a prerequisite to an IDE/Debugger. The DigDug project is currently suspended until a mature GUI framework is available.

No one said the debugger had to be written in D. Also, there are debuggers out there (gdb) with no GUI component at all. From what Jill has said, it sounds like the biggest obstacle to decent interactive debugging is with template code. Sean
Sep 14 2004
prev sibling next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <cht9gl$20m8$1 digitaldaemon.com>, Walter says...
So I'd like to kick off this thread as an opportunity for all to post their
two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
mean pragmatic things like:

1) compiler bugs
2) language shortcomings with no reasonable workarounds
3) issues that are fundamentally blocking projects from using or proceeding
with D
4) severe library faults

Walter: My top two are as follows: 1) Please solve both the parameter passing and string concatenation (~) problems when using string literals, plus the handling of parameter implicit conversion of char[], wchar[], and dchar[] to functions' problems. # int main() # { # char[] sDynStr = ""; # wchar[] wsDynStr = ""; # wchar[] wsDynStr2 = ""; # dchar[] dsDynStr = ""; # # // This works # sDynStr = "Initializing to 8-Bit"; # wsDynStr = "Initializing to 16-Bit"; # wsDynStr2 = "Initializing to 16-Bit"; # dsDynStr = "Initializing to 32-bit"; # # // This always works # sDynStr = "This is" ~ " a test!"; # # /+ # ' But when I use the ~ operator it forces # ' the 2nd literal string to a char[] # ' thus causing the "cannot implicitly convert # ' expression "This is a test!" # ' of type char[15] to wchar[]" error. # ' # +/ # wsDynStr = "This is" ~ " a test!"; # dsDynStr = "This is" ~ " a test!"; # # // This works - forced to cast() each literal string # wsDynStr = cast(wchar[])"This is" ~ cast(wchar[])" a test!"; # dsDynStr = cast(dchar[])"This is" ~ cast(dchar[])" a test!"; # # // This works - - forced to cast() a literal string with (x)s # wsDynStr = cast(wchar[])( "This is" ~ " a test!" ); # dsDynStr = cast(dchar[])( "This is" ~ " a test!" ); # # return 0; # # } // end int main() 2) Stronger support for DLLs. ---------------------------------------- Here's a part of Matthew's post that touchs on the subject at: digitalmars.D/9166 <partial content> I see four issues with DLLs and D. I'm interested to hear whether I've missed any and, especially, what ideas people have for solving these issues in a "Spirit of D" way (i.e. without all the clodhopping nonsense that is the Java/.NET infrastructure): 1. Sharing/managing GC - I think this is the most important in the short/medium term 2. Being able to talk _classes_ not just _interfaces_ between link units. We can get a long way with interfaces, methinks, once GC sharing is handled, but still it'd be nice to work with classes as well, if simply achievable. 3. Versioning, i.e. avoiding DLL Hell 4. Security. Is there something simple and efficient that nonetheless addresses those handled by the heaving leviathan that is .NET? Ancilary issues: 1. Serialisation as a part of the language?? </partial content> Walter, thanks for asking! ;) ------------------------------------------------------------------- "Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Sep 11 2004
prev sibling next sibling parent Juanjo =?ISO-8859-15?Q?=C1lvarez?= <juanjuxNO SPAMyahoo.es> writes:
Walter wrote:

 So I'd like to kick off this thread as an opportunity for all to post
 their two Most Important Issues for D with respect to getting 1.0 done. By
 MIID, I mean pragmatic things like:
 
 1) compiler bugs
 2) language shortcomings with no reasonable workarounds
 3) issues that are fundamentally blocking projects from using or
 proceeding with D
 4) severe library faults

A bugzilla (web bug tracking system) would be more apt for this task than a forum thread, wasn't one about to be set up at dsource? Walter, the (php) MantisBT can be configured in no more than 20 minutes! (it's what we're using at work and works really well.): http://www.mantisbt.org/ The CVS version also allow for voting (sponsorship) of bugs.
Sep 11 2004
prev sibling next sibling parent reply Sai <Sai_member pathlink.com> writes:
1. Put "D language and compiler" in maintainance mode ASAP.
2. Improve Phobos. Phobos right now looks like some 
bunch of crap put together.

- Sai
Sep 11 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Sai" <Sai_member pathlink.com> wrote in message
news:chvfss$17j$1 digitaldaemon.com...
 1. Put "D language and compiler" in maintainance mode ASAP.
 2. Improve Phobos. Phobos right now looks like some
 bunch of crap put together.

Lots of people have commented that Phobos is crap. But I need specifics.
Sep 11 2004
next sibling parent reply Sai <Sai_member pathlink.com> writes:
Walter, I think I should apologise, I don't mean to be so harsh.

Actually, I feel that the "D Language" is such an achievement,
it is something which I have been looking for since last 7 years.

Language is great, compiler is great, but somehow I feel that 
phobos got neglected. 

Specifically, 

1. Where is DTL ? Why there are no direct links from website
to DTL ? Why should I dig NG for downloading DTL. Why can't 
we make DTL part of phobos ? No wonder so many versions of
miniTL, xTl yTl's are floating around, infact I have my 
own version of TL in D !!

2. I feel that the amount of API is very less. The API which is 
currently in phobos seems to be there just to help you in 
writing compiler. it wasn't of much use to me. I had to 
write lot of classes when I tried to port my code to D.
For example, we don't have 'Timer' classes yet.

3. Documentation is very bad. I think any powerful API is useless
unless it is well documented. Lacking of "Search" facility 
or "Index" in D documentation is a huge discouraging factor.

For D 1.0 above things are enough for me.

Regards
Sai




In article <ci0gf5$18rn$1 digitaldaemon.com>, Walter says...
"Sai" <Sai_member pathlink.com> wrote in message
news:chvfss$17j$1 digitaldaemon.com...
 1. Put "D language and compiler" in maintainance mode ASAP.
 2. Improve Phobos. Phobos right now looks like some
 bunch of crap put together.

Lots of people have commented that Phobos is crap. But I need specifics.

Sep 12 2004
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sai" <Sai_member pathlink.com> wrote in message
news:ci0u0m$2k7g$1 digitaldaemon.com...
 Walter, I think I should apologise, I don't mean to be so harsh.

 Actually, I feel that the "D Language" is such an achievement,
 it is something which I have been looking for since last 7 years.

 Language is great, compiler is great, but somehow I feel that
 phobos got neglected.

 Specifically,

 1. Where is DTL ?

news://news.digitalmars.com/digitalmars.D.dtl
 Why there are no direct links from website
 to DTL ?

Because it's not ready yet. In the next round I'll do a website as well, with Doxygenated help.
 Why should I dig NG for downloading DTL.

Because no-one's paying me to work on it full-time, more's the pity. Hence, there's been no (time to prepare a) website yet. If you browse the website, all the design intent is in there.
 Why can't
 we make DTL part of phobos ?

We will, eventually. At the moment we have two streams of development. DTL is working on "concepts" and MinTL is ploughing implementation furrows. This is actually a nice thing because we're learning lessons that don't overlap, and DTL may well be able to incorporate MinTL's containers (and their growing use/testing/robustness) into the DTL framework. I think that's a big plus! You must remember that D's templates are an almost entirely new mechanism, and there are *no* experts in it anywhere. As such, no-one is in a position to write the definitive library that would go into Phobos at this time, and doing so would just piss people off as each release changed the interfaces to the library.
 No wonder so many versions of
 miniTL, xTl yTl's are floating around, infact I have my
 own version of TL in D !!

 2. I feel that the amount of API is very less. The API which is
 currently in phobos seems to be there just to help you in
 writing compiler. it wasn't of much use to me. I had to
 write lot of classes when I tried to port my code to D.
 For example, we don't have 'Timer' classes yet.

 3. Documentation is very bad. I think any powerful API is useless
 unless it is well documented. Lacking of "Search" facility
 or "Index" in D documentation is a huge discouraging factor.

True. Unfortunately we've not so far defined a documentation standard, though if you search the archives you'll see that many of us have been advocating Doxygen-compatible doc tags in all Phobos code (and all my submissions have it). Like many other things, time is the constraining factor. All I can say is that if we continue to mark up contributions, it can all be generated at a later time with relative ease.
 For D 1.0 above things are enough for me.

 Regards
 Sai




 In article <ci0gf5$18rn$1 digitaldaemon.com>, Walter says...
"Sai" <Sai_member pathlink.com> wrote in message
news:chvfss$17j$1 digitaldaemon.com...
 1. Put "D language and compiler" in maintainance mode ASAP.
 2. Improve Phobos. Phobos right now looks like some
 bunch of crap put together.

Lots of people have commented that Phobos is crap. But I need specifics.


Sep 12 2004
prev sibling next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
Sai wrote:

 Walter, I think I should apologise, I don't mean to be so harsh.
 
 Actually, I feel that the "D Language" is such an achievement,
 it is something which I have been looking for since last 7 years.
 
 Language is great, compiler is great, but somehow I feel that
 phobos got neglected.
 
 Specifically,
 
 1. Where is DTL ? Why there are no direct links from website
 to DTL ? Why should I dig NG for downloading DTL. Why can't
 we make DTL part of phobos ? No wonder so many versions of
 miniTL, xTl yTl's are floating around, infact I have my
 own version of TL in D !!

cool - is your TL available? I'm curious what it's like, if you don't mind.
 2. I feel that the amount of API is very less. The API which is
 currently in phobos seems to be there just to help you in
 writing compiler. it wasn't of much use to me. I had to
 write lot of classes when I tried to port my code to D.
 For example, we don't have 'Timer' classes yet.

Again, do you have a link for that?
 3. Documentation is very bad. I think any powerful API is useless
 unless it is well documented. Lacking of "Search" facility
 or "Index" in D documentation is a huge discouraging factor.

Do you mean the documentation for phobos or all of D? For Phobos I just search the web page using the Find command on my browser or I look at the list of modules and pick the one that looks relevant. It can be out of date, though. "See also" entries would be nice - so that for instance std.file could say to see also std.stream and std.mmfile and vice versa.
 For D 1.0 above things are enough for me.
 
 Regards
 Sai
 
 
 
 
 In article <ci0gf5$18rn$1 digitaldaemon.com>, Walter says...
"Sai" <Sai_member pathlink.com> wrote in message
news:chvfss$17j$1 digitaldaemon.com...
 1. Put "D language and compiler" in maintainance mode ASAP.
 2. Improve Phobos. Phobos right now looks like some
 bunch of crap put together.

Lots of people have commented that Phobos is crap. But I need specifics.


Sep 12 2004
prev sibling next sibling parent J C Calvarese <jcc7 cox.net> writes:
Sai wrote:
 Walter, I think I should apologise, I don't mean to be so harsh.

...
 1. Where is DTL ? Why there are no direct links from website
 to DTL ? Why should I dig NG for downloading DTL. Why can't 
 we make DTL part of phobos ? No wonder so many versions of
 miniTL, xTl yTl's are floating around, infact I have my 
 own version of TL in D !!

Here's a summary: http://www.prowiki.org/wiki4d/wiki.cgi?DTemplateLibrary (It even has links.) ...
 3. Documentation is very bad. I think any powerful API is useless
 unless it is well documented. Lacking of "Search" facility 
 or "Index" in D documentation is a huge discouraging factor.

Have you tried this: http://www.digitalmars.com/advancedsearch.html
 
 For D 1.0 above things are enough for me.
 
 Regards
 Sai

-- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Sep 12 2004
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Sai wrote:
<snip>
 3. Documentation is very bad. I think any powerful API is useless
 unless it is well documented. Lacking of "Search" facility 
 or "Index" in D documentation is a huge discouraging factor.

Doesn't your web browser allow you to search within a page? To me, the trouble with Phobos documentation is the amount of Phobos that is still undocumented. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 13 2004
prev sibling next sibling parent reply Joey Peters <Joey_member pathlink.com> writes:
Lots of people have commented that Phobos is crap. But I need specifics.

What I think about it: No more c style things like time_t, printf, or that kind of things. It'd be also nice if it would be a whole fish rather than a school of fish. Also it looks like it's code could need a revamp. Containers should also be embedded, though I don't have a problem with that since I have a great time making my own containers ;) D's standard functionality sort of patches that problem up, though that doesn't mean it doesn't need it. How common is it that you want to push items on an array? That you want to sort an array, or whatever?
Sep 12 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Joey Peters" <Joey_member pathlink.com> wrote in message
news:ci15ag$2rea$1 digitaldaemon.com...
Lots of people have commented that Phobos is crap. But I need specifics.

What I think about it: No more c style things like time_t, printf, or that kind of things. It'd be also nice if it would be a whole fish rather than a school of fish.

D, like the other good non-commercially aligned powerful systems-software language, is not a one-shoe fits all. Thankfully, it never will be. If you want that, you're looking in the wrong place, and expend effort in going forward and petitioning for it will be a waste of your time.
 Also it looks
 like it's code could need a revamp. Containers should also be embedded, though
I
 don't have a problem with that since I have a great time making my own
 containers ;)

What do you mean by embedded?
 D's standard functionality sort of patches that problem up, though
 that doesn't mean it doesn't need it. How common is it that you want to push
 items on an array? That you want to sort an array, or whatever?

It is not clear whether you are for or against.
Sep 12 2004
parent reply Joey Peters <Joey_member pathlink.com> writes:
D, like the other good non-commercially aligned powerful systems-software
language, is not a one-shoe fits all. 
Thankfully, it never will be. If you want that, you're looking in the wrong
place, and expend effort in going forward 
and petitioning for it will be a waste of your time.

I thought D was designed with in mind that things together make sense coherently, I'm not talking about making it fit for anyone. Should we end up with bad conventions on everything, that even the runtime lib has inconsistancy? I don't have a problem with this kind of behaviour if it wasn't shipped with D. That whole statement is kind of vague anyway.
 Also it looks
 like it's code could need a revamp. Containers should also be embedded, though
I
 don't have a problem with that since I have a great time making my own
 containers ;)

What do you mean by embedded?

Into phobos/d release, doesn't really matter to me.
 D's standard functionality sort of patches that problem up, though
 that doesn't mean it doesn't need it. How common is it that you want to push
 items on an array? That you want to sort an array, or whatever?

It is not clear whether you are for or against.

It patches it up, in the sense of you can make it work with some effort. Though, still, D seems to provide a whole lot of functionality that's not getting used yet, also hence to people that just stick to their own ideas, programming around those features. It's like Mars itself, if we could get there, we could do a whole lot with it 'eventually' if we could convince ourselves it's not just a gigantic red rock (why would we want to go there in the first place, because it's a big red rock?). Phobos just only sees one part of mars at a time ;)
Sep 12 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
D, like the other good non-commercially aligned powerful systems-software
language, is not a one-shoe fits all.
Thankfully, it never will be. If you want that, you're looking in the wrong
place, and expend effort in going forward
and petitioning for it will be a waste of your time.

I thought D was designed with in mind that things together make sense coherently, I'm not talking about making it fit for anyone. Should we end up with bad conventions on everything, that even the runtime lib has inconsistancy?

I haven't advocated that. Incoherence is not necessarily the obverse of multi-paradigm.
 I don't have a problem with this kind of behaviour if it wasn't shipped with D.
 That whole statement is kind of vague anyway.

I was trying to avoid impoliteness.
 Also it looks
 like it's code could need a revamp. Containers should also be embedded, though
I
 don't have a problem with that since I have a great time making my own
 containers ;)

What do you mean by embedded?

Into phobos/d release, doesn't really matter to me.

Ok.
 D's standard functionality sort of patches that problem up, though
 that doesn't mean it doesn't need it. How common is it that you want to push
 items on an array? That you want to sort an array, or whatever?

It is not clear whether you are for or against.

It patches it up, in the sense of you can make it work with some effort. Though, still, D seems to provide a whole lot of functionality that's not getting used yet, also hence to people that just stick to their own ideas, programming around those features. It's like Mars itself, if we could get there, we could do a whole lot with it 'eventually' if we could convince ourselves it's not just a gigantic red rock (why would we want to go there in the first place, because it's a big red rock?). Phobos just only sees one part of mars at a time ;)

I'm afraid this is still entirely opaque to my terrestrial comprehension.
Sep 12 2004
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:ci1crf$2u2i$1 digitaldaemon.com...
D, like the other good non-commercially aligned powerful systems-software
language, is not a one-shoe fits all.
Thankfully, it never will be. If you want that, you're looking in the wrong
place, and expend effort in going forward
and petitioning for it will be a waste of your time.

I thought D was designed with in mind that things together make sense coherently, I'm not talking about making it fit for anyone. Should we end up with bad conventions on everything, that even the runtime lib has inconsistancy?

I haven't advocated that. Incoherence is not necessarily the obverse of multi-paradigm.

I meant "single-paradigm". Obviously.
Sep 12 2004
prev sibling parent Joey Peters <Joey_member pathlink.com> writes:
I'm afraid this is still entirely opaque to my terrestrial comprehension. 

Does the earthling understand the concept of never minding? Nevermind :P
Sep 12 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:ci0gf5$18rn$1 digitaldaemon.com...
 "Sai" <Sai_member pathlink.com> wrote in message
 news:chvfss$17j$1 digitaldaemon.com...
 1. Put "D language and compiler" in maintainance mode ASAP.
 2. Improve Phobos. Phobos right now looks like some
 bunch of crap put together.

Lots of people have commented that Phobos is crap. But I need specifics.

There've been probably 75% of the specifics reported in the NG over the last, say, 12 months. However, I can't conjure them to mind now any more than you can. A series of directed reviews may be our best bet. I will start with Exceptions next week.
Sep 12 2004
prev sibling next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
Change 0 to 1 in line 58 of parse.c :)
Reference return types would be great :)

You are doing a great job with D, and the above is just one of those
wishes everyone has, but i would like this to be possible:

1)

class A
{
    this(){/*...*/}
    template constr(T)
    {
        this(T x){/*...*/}
    }

    mixin constr!(int);
    mixin constr!(float);
}

This code looks exelent but to turn on name overloading between the default
constructor and the mixed ones, i would have to alias it. But how?

mixin constr!(int) somename;
alias somename.this this; //doesn't work

Someone mentioned something about combining mixin and alias
into one thing like: mixin constr!(int) as this; or something like that,
but i would be prefectlly happy with anything that did the job.

2)
a more usefull Phobos but this can wait, but it can wait until while
you are making a compiler and the language better.



"Walter" <newshound digitalmars.com> wrote in message
news:cht9gl$20m8$1 digitaldaemon.com...
 In some delightful ways, D is a victim of its own success. There's a lot

 traffic in the D newsgroups, sometimes getting to 100 messages per day.

 a day goes by without new proposals for features. It's simply beyond my
 capacity to give these all the attention they deserve, or even to read

 all. I probably spend a minimum of 2 hours a day reading messages, and I
 could easilly spend 12 hours a day at it, and accomplish nothing else.

 Hence, I inadvertently overlook important issues. I know that this has

 frustrating to some people, and I apologize for it.

 So I'd like to kick off this thread as an opportunity for all to post

 two Most Important Issues for D with respect to getting 1.0 done. By MIID,

 mean pragmatic things like:

 1) compiler bugs
 2) language shortcomings with no reasonable workarounds
 3) issues that are fundamentally blocking projects from using or

 with D
 4) severe library faults

 I don't mean things like:

 1) D 2.0 issues
 2) feature proposals like "It would be nice if ..."
 3) minor irritants
 4) philosophical issues
 5) issues that have been beaten to death already <g>

 If a thread here exists for the topic, a reference to that thread would be
 nice rather than reproducing it.

 It's time to prioritize and get us on a rational, sensible path for
 releasing 1.0.

Sep 11 2004
prev sibling next sibling parent reply Mike Swieton <mike swieton.net> writes:
On Fri, 10 Sep 2004 15:18:03 -0700, Walter wrote:

 So I'd like to kick off this thread as an opportunity for all to post their
 two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
 mean pragmatic things like:
 
 1) compiler bugs
 2) language shortcomings with no reasonable workarounds

I'm not sure if this is a shortcoming, or just a feature request, but I'll mention it again: D's unit test facility is not usable for test driven development (because it's unnecessarily difficult to run a subset of tests) or for automated builds (because a single failure will halt execution of the test suite). I don't classify this as a showstopper bug, but I think it's at the very next level. To use D at my company, we would have to completely drop a significant language feature in favor of a library, because D doesn't work the way we do. I have posted thoughts on the wiki about this, with a link to my original proposal. Even if that feature proposal is not a good solution, I believe it covers the problems well. Mike Swieton __ Following the light of the sun, we left the Old World. - Inscribed on Columbus' caravels
Sep 11 2004
parent reply Nick <Nick_member pathlink.com> writes:
In article <pan.2004.09.11.20.54.46.684151 swieton.net>, Mike Swieton says...
I'm not sure if this is a shortcoming, or just a feature request, but I'll
mention it again: D's unit test facility is not usable for test driven
development (because it's unnecessarily difficult to run a subset of
tests)

How narrow a subset do you need? I have set up my makefile to make a stand alone program of each module, called ut_modname, which does nothing but run the module unit tests.
 or for automated builds (because a single failure will halt
execution of the test suite).

Can't you get around this by writing errors to stdout, stderr or a log file instead of using asserts? Nick
Sep 13 2004
parent reply Mike Swieton <Mike_member pathlink.com> writes:
In article <ci4oks$2rt0$1 digitaldaemon.com>, Nick says...
In article <pan.2004.09.11.20.54.46.684151 swieton.net>, Mike Swieton says...
I'm not sure if this is a shortcoming, or just a feature request, but I'll
mention it again: D's unit test facility is not usable for test driven
development (because it's unnecessarily difficult to run a subset of
tests)

How narrow a subset do you need? I have set up my makefile to make a stand alone program of each module, called ut_modname, which does nothing but run the module unit tests.
 or for automated builds (because a single failure will halt
execution of the test suite).

Can't you get around this by writing errors to stdout, stderr or a log file instead of using asserts?

No, not and have it still be D's unit test facility. Sure, I can write CppUnit in D, and use that. But that's hardly means that D's unit test feature works. Just because I can implement test selection in a Makefile doesn't mean that it's a solution. It's only a workaround. Good unit test suites which meet all of my criteria can be made and written in D. But that can be done in assembly and befunge too. I am saying that if I want to do this in D, I have to actively fight 'features' of D's unit testing. Therefore, D does not have a sufficient unit test facility.
Sep 13 2004
parent reply Nick <Nick_member pathlink.com> writes:
In article <ci4q6p$he$1 digitaldaemon.com>, Mike Swieton says...
No, not and have it still be D's unit test facility. Sure, I can write CppUnit
in D, and use that. But that's 
hardly means that D's unit test feature works. Just because I can implement test
selection in a Makefile 
doesn't mean that it's a solution. It's only a workaround.

Point taken.
Good unit test suites which meet all of my criteria can be made and written in
D. But that can be done 
in assembly and befunge too. I am saying that if I want to do this in D, I have
to actively fight 'features' 
of D's unit testing. Therefore, D does not have a sufficient unit test facility.

Ok. Do you (or anyone else) have any specific suggestions as to how to improve the D unit test system so it will meet your criteria? I admit I'm pretty clueless about this. Nick
Sep 13 2004
parent reply Mike Swieton <mike swieton.net> writes:
On Mon, 13 Sep 2004 19:46:56 +0000, Nick wrote:
 Ok. Do you (or anyone else) have any specific suggestions as to how to improve
 the D unit test system so it will meet your criteria? I admit I'm pretty
 clueless about this.
 
 Nick

These are my requirements (in no order): 1: Test isolation. I should be able to have a single test failure abort only that test. Rationale: Automated tests. At work, we have one particular product who's test suite takes hours to run fully. Others merely take tens of minutes. I run it over night, and I want to come in in the morning and see a complete report of the results, not just the first failure. 2: Test selection. I should be able to select a subset of tests programatically. Rationale: This stems from the above: with a large test suite, I should be able to run just a few. The 'programatically' part is essentially philosophical: managing the test suite is the job of the test framework, not the build system. 2: Separate tests from application. I should be able to run the tests without running the application. Rationale: A unit test for a single function doesn't require the entire app. Also, the startup of a large program may be time consuming, resource intensive, or interactive. Again, this is largely ideological: the tests and the app are simply not the same thing. It is illogical to run a batch of tests overnight, and come back to a running app in the morning. Why are the two activities connected? 3: Test reports. I should be able to generate some sort of report about which tests failed, and why. Rationale: Currently, if there's a failure, testing terminates. However, if I want to run a batch of 5000 tests, and 300 fail, it's impractical for me to not have a file documenting it. 4: Useful asserts. I want an assertEquals. I want an assert with a message. Rationale: I'm lazy. Also, I want a message because assert(x < 3 && x > 1) doesn't really *mean* "assert that x is between 1 and 3". It means something like "assert that x is within the range valid for brake forces". Walter has said that the line number output is enough, but that's gets less useful for unit test suites because if I get a test report of 300 failures, I want to look at the report and see why it failed. I don't want to see 300 line numbers. 5: Setup/teardown methods. Rationale: it is tremendously useful to be able to run some setup/cleanup code before/after tests run, to ensure a clean environment. This is basically required when the code involves something persistent that needs the state to be reset, such as a hardware device or database. Now, this is how I want things to behave. This doesn't necessarily mean that it needs to be implemented in the language itself, only that it should be able to be done without replacing D's unit testing. My suggestions to accomplish the above: - Change assert to be a normal function that can be overridden, and have it thrown an exception. That is, make it Java-like. This will require some magic to continue to let assertions have line numbers and file names. This addresses #4, and #1. - Separate tests into actual functions, named, and expose them somehow (such as an AA). If these two are done, a library could be written on top of D allowing D to keep the current behavior (test fatality would stay because the exception would be uncaught, and test selection would follow the current scheme). At the same time, a library could allow you to select which tests to run, handle all the logging, etc. I don't care if this is how it's solved, but right now I don't feel that D can really advertise built in unit testing. It simply isn't there yet. What I object to now is that to get the behavior I want (which is required for TDD), I need to throw away or work around D's built in unit testing - one of my (theoretically) favorite D features. Mike Swieton __ If the government wants us to respect the law, they should set a better example.
Sep 13 2004
next sibling parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Mike Swieton wrote:

 On Mon, 13 Sep 2004 19:46:56 +0000, Nick wrote:
 
Ok. Do you (or anyone else) have any specific suggestions as to how to improve
the D unit test system so it will meet your criteria? I admit I'm pretty
clueless about this.

Nick


<snip type="a bunch of great stuff"/> Mike, great post detailing the same things I observed. Now, what I like about D unit tests is that the test is next to the code being tested-- this is a good thing. If done correctly, it should allow you to test even private member functions (something that JUnit cannot do). I second the cry for restructuring how tests are compiled and run.
 
 My suggestions to accomplish the above:
 
 - Change assert to be a normal function that can be overridden, and have it
 	thrown an exception. That is, make it Java-like. This will require some
 	magic to continue to let assertions have line numbers and file names. This
 	addresses #4, and #1.
 - Separate tests into actual functions, named, and expose them somehow (such
 	as an AA).

I'm not sure I agree with those suggestions based on what I think D unit testing can be. Here are my suggestions: * Add a text parameter to the assert keyword so that additional information can be passed back to the user. This will allow libraries of useful "assertXXX" functions to be written and still include the developer defined message. * Separate the unit-test entry point from the application entry point. A "d-unit" utility (like the dmd utility) should be used to collect and run the tests. Information from those tests should be collected in a file--or at the very least provide a "callback" function to add on test reporting in a way that fits the developer. * Test failure and test errors are separated. Any test that throws an exception other than an AssertionError (or whatever it is called) has an error because the condition was not planned for. If the assert fails then the test fails. ****Stack Traces Are Imperative****, with unit tests it is more important to follow the trail of activity with class names, method names, and line numbers. The actual point of failure is less important than what led up to it. * Provide a class-wide "unit-init" and "unit-destroy" style blocks so that the variables associated with the unit testing can be set up and used in each "unit" block. Associated with this is a way to distinguish variables used for unit testing from variables used for operation. It should be a compile error to access unit testing variables from outside a "unitXXX" block. By the same token, it should be a compile error for the "unit-init" and "unit-destroy" blocks to touch non-unit testing variables. During a "-release" build all those variables can be safely removed without side-effect. I think this will solve the desires for TDD in a "D" way.
Sep 14 2004
parent reply Mike Swieton <mike swieton.net> writes:
On Tue, 14 Sep 2004 09:42:26 -0400, Berin Loritsch wrote:
 I'm not sure I agree with those suggestions based on what I think D unit
 testing can be.  Here are my suggestions:
 
 * Add a text parameter to the assert keyword so that additional
    information can be passed back to the user.  This will allow
    libraries of useful "assertXXX" functions to be written and
    still include the developer defined message.

I think this is a strange restriction. Wouldn't making it a regular function be more powerful, or at least make more sense?
 * Separate the unit-test entry point from the application entry
    point.  A "d-unit" utility (like the dmd utility) should be used
    to collect and run the tests.  Information from those tests should
    be collected in a file--or at the very least provide a "callback"
    function to add on test reporting in a way that fits the developer.

I dislike a utility. Purely for philosophical reasons: why should I need a separate application to use a language feature? I had in mind something more like a library I could link against (or would automatically be linked in when in -unittest mode). Or is that what you just suggested?
 * Test failure and test errors are separated.  Any test that throws
    an exception other than an AssertionError (or whatever it is called)
    has an error because the condition was not planned for.  If the assert
    fails then the test fails.  ****Stack Traces Are Imperative****,
    with unit tests it is more important to follow the trail of activity
    with class names, method names, and line numbers.  The actual point
    of failure is less important than what led up to it.

Agreed, completely.
 * Provide a class-wide "unit-init" and "unit-destroy" style blocks so
    that the variables associated with the unit testing can be set up and
    used in each "unit" block.  Associated with this is a way to
    distinguish variables used for unit testing from variables used for
    operation.  It should be a compile error to access unit testing
    variables from outside a "unitXXX" block.  By the same token, it
    should be a compile error for the "unit-init" and "unit-destroy"
    blocks to touch non-unit testing variables.  During a "-release" build
    all those variables can be safely removed without side-effect.

My thinking was that this could be done in a library, for two reasons: firstly, it's less invasive to the language (simpler change). Secondly, it is more extensible. As long as the test methods themselves are accessible, a library can be written and features can be added. But without that, we're stuck with one design forever. The big question is where to draw the line: what is a language feature, and what should be done in a library? I think most of it should be a library, for extensibility and future-proofing D. I don't think the unit testing is quite as important as proper debugging information, or Arcane Jill's hooks for the GC, as those affect coding and not testing. But without changes to address the testing issues, I don't feel that D can honestly advertise that it has 'built-in unit testing'. That's why I feel this is definitely a D 1.0 feature, not 2.0. It's not a 'nice feature' to have, it's a feature D claims to have, but really doesn't. Anyone have any thoughts? Mike Swieton __ Brutes find out where their talents lie; a bear will not attempt to fly. - Jonathan Swift
Sep 14 2004
parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Mike Swieton wrote:

 On Tue, 14 Sep 2004 09:42:26 -0400, Berin Loritsch wrote:
 
I'm not sure I agree with those suggestions based on what I think D unit
testing can be.  Here are my suggestions:

* Add a text parameter to the assert keyword so that additional
   information can be passed back to the user.  This will allow
   libraries of useful "assertXXX" functions to be written and
   still include the developer defined message.

I think this is a strange restriction. Wouldn't making it a regular function be more powerful, or at least make more sense?

There is nothing stopping regular methods wrapped around this from being written, as is the case in the XXXUnit libraries. I think it would over-complicate the *language* to have a zillion assert variant keywords.
* Separate the unit-test entry point from the application entry
   point.  A "d-unit" utility (like the dmd utility) should be used
   to collect and run the tests.  Information from those tests should
   be collected in a file--or at the very least provide a "callback"
   function to add on test reporting in a way that fits the developer.

I dislike a utility. Purely for philosophical reasons: why should I need a separate application to use a language feature? I had in mind something more like a library I could link against (or would automatically be linked in when in -unittest mode). Or is that what you just suggested?

For purely practical reasons in TDD unit testing is more a function of compilation than runtime. One could do what Java does and have all the JDK tools written in Java with EXE shells to link to the tools.jar lib. The equivalent would satisfy both our needs (i.e. have the bulk of the logic in a library with a utility to call it from the command line). The bottom line is that I want to be able to execute just the tests any time I want.
* Provide a class-wide "unit-init" and "unit-destroy" style blocks so
   that the variables associated with the unit testing can be set up and
   used in each "unit" block.  Associated with this is a way to
   distinguish variables used for unit testing from variables used for
   operation.  It should be a compile error to access unit testing
   variables from outside a "unitXXX" block.  By the same token, it
   should be a compile error for the "unit-init" and "unit-destroy"
   blocks to touch non-unit testing variables.  During a "-release" build
   all those variables can be safely removed without side-effect.

My thinking was that this could be done in a library, for two reasons: firstly, it's less invasive to the language (simpler change). Secondly, it is more extensible. As long as the test methods themselves are accessible, a library can be written and features can be added. But without that, we're stuck with one design forever. The big question is where to draw the line: what is a language feature, and what should be done in a library? I think most of it should be a library, for extensibility and future-proofing D.

To tell the truth, it would be easy enough writing a DUnit library to do everything you want. Of course having something like DCover (coverage utility) would rock as well. The proposal I came up with preserves the idea of completing the Unit Testing integration--which until now is almost too limiting to be truly useful.
 
 I don't think the unit testing is quite as important as proper debugging
 information, or Arcane Jill's hooks for the GC, as those affect coding and not
 testing. But without changes to address the testing issues, I don't feel that
 D can honestly advertise that it has 'built-in unit testing'. That's why I
 feel this is definitely a D 1.0 feature, not 2.0. It's not a 'nice feature' to
 have, it's a feature D claims to have, but really doesn't.
 
 Anyone have any thoughts?

Well, having been test infected, I like being able to claim my tests have 100% coverage. However, in order for tests to be useful, proper debugging information and stack trace information are very important. If D has to come up with its own debugger (like Java had to do), then it is a worthwhile endeavor. You will find that writing the debugger will help determine what callbacks and tie-ins to the compiled binary are necessary.
Sep 15 2004
parent Mike Swieton <mike swieton.net> writes:
On Wed, 15 Sep 2004 09:27:06 -0400, Berin Loritsch wrote:
 There is nothing stopping regular methods wrapped around this from being
 written, as is the case in the XXXUnit libraries.  I think it would
 over-complicate the *language* to have a zillion assert variant
 keywords.

Right now, there is: it's impossible to get the file/line number information that the assert keyword right now provides. I don't really care too much about the mechanism, though, as long as I can override assert.
 For purely practical reasons in TDD unit testing is more a function of
 compilation than runtime.  One could do what Java does and have all the
 JDK tools written in Java with EXE shells to link to the tools.jar lib.
 The equivalent would satisfy both our needs (i.e. have the bulk of the
 logic in a library with a utility to call it from the command line).
 
 The bottom line is that I want to be able to execute just the tests any
 time I want.

That would be an acceptable solution.
* Provide a class-wide "unit-init" and "unit-destroy" style blocks so
   that the variables associated with the unit testing can be set up and
   used in each "unit" block.  Associated with this is a way to
   distinguish variables used for unit testing from variables used for
   operation.  It should be a compile error to access unit testing
   variables from outside a "unitXXX" block.  By the same token, it
   should be a compile error for the "unit-init" and "unit-destroy"
   blocks to touch non-unit testing variables.  During a "-release" build
   all those variables can be safely removed without side-effect.

My thinking was that this could be done in a library, for two reasons: firstly, it's less invasive to the language (simpler change). Secondly, it is more extensible. As long as the test methods themselves are accessible, a library can be written and features can be added. But without that, we're stuck with one design forever. The big question is where to draw the line: what is a language feature, and what should be done in a library? I think most of it should be a library, for extensibility and future-proofing D.

To tell the truth, it would be easy enough writing a DUnit library to do everything you want. Of course having something like DCover (coverage utility) would rock as well. The proposal I came up with preserves the idea of completing the Unit Testing integration--which until now is almost too limiting to be truly useful.

Yeah, all of what I want would be pretty trivial to implement. However, D claims to have 'built in unit testing'. Either it does, or it doesn't. If I have to write DUnit, then it definately does not, and such a deviation from the spec must be a bug.
 
 I don't think the unit testing is quite as important as proper debugging
 information, or Arcane Jill's hooks for the GC, as those affect coding and not
 testing. But without changes to address the testing issues, I don't feel that
 D can honestly advertise that it has 'built-in unit testing'. That's why I
 feel this is definitely a D 1.0 feature, not 2.0. It's not a 'nice feature' to
 have, it's a feature D claims to have, but really doesn't.
 
 Anyone have any thoughts?

Well, having been test infected, I like being able to claim my tests have 100% coverage. However, in order for tests to be useful, proper debugging information and stack trace information are very important. If D has to come up with its own debugger (like Java had to do), then it is a worthwhile endeavor. You will find that writing the debugger will help determine what callbacks and tie-ins to the compiled binary are necessary.

That's beyond my area of expertise, I'm afraid. As long as I can debug my D code, I'll be happy. And test it, too. Mike Swieton __ What would you attempt to do if you knew you would not fail? - Dr. Robert Schuller
Sep 15 2004
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
Hi,
I start with an example, because I think I didn't understand.

# class Sum
# {
#   int add(int x, int y) { return x + y; }
#   int sub(int x, int y) { return x - y; }
#
#   unittest
#   {
#     assert(add(3,4) == 7);
#     assert(add(-2,0) == -2);
#     assert(sub(3,4) == -1);
#     assert(sub(2,1) == 1);
#   }
# }

According to the language specification, the unittest member function is called
automatically at startup, before the main() function is called.

This can be accomplished by not issuing an assert() in case of failure, but
logging to a file instead. From the previous example:

# unittest {
#   // init test module
#   Test.setModule("mycompany.myproduct.mypackage.Sum")
#
#   // test feature add()
#   if (Test.enabled("mycompany.myproduct.mypackage.Sum.add")) {
#     Test.expr(add(3,4) == 7, "Positive add test");
#     Test.expr(add(-2,0) == -2, "Negative add test");
#   }
#
#   // test feature sub()
#   if (Test.enabled("mycompany.myproduct.mypackage.Sum.sub")) {
#     Test.expr(sub(3,4) == -1, "Negative sub test");
#     Test.expr(sub(2,1) == 1, "Positive sub test");
#   }
# }

Where the Test class is a singleton that loads a configuration file at startup,
thus the user can decide wich tests to enable for each run.
Since the unittests are run before the main function is called, a simple:

int main() {
if (Test.enabled()) {
return 0;
}

.. // the rest of the main function
}

will run the tests and not the application.

Ciao
Sep 15 2004
parent reply Mike Swieton <mike swieton.net> writes:
On Wed, 15 Sep 2004 08:12:23 +0000, Roberto Mariottini wrote:

<snip>

 # unittest {
 #   // init test module
 #   Test.setModule("mycompany.myproduct.mypackage.Sum")
 #
 #   // test feature add()
 #   if (Test.enabled("mycompany.myproduct.mypackage.Sum.add")) {
 #     Test.expr(add(3,4) == 7, "Positive add test");
 #     Test.expr(add(-2,0) == -2, "Negative add test");
 #   }
 #
 #   // test feature sub()
 #   if (Test.enabled("mycompany.myproduct.mypackage.Sum.sub")) {
 #     Test.expr(sub(3,4) == -1, "Negative sub test");
 #     Test.expr(sub(2,1) == 1, "Positive sub test");
 #   }
 # }
 
 Where the Test class is a singleton that loads a configuration file at startup,
 thus the user can decide wich tests to enable for each run.
 Since the unittests are run before the main function is called, a simple:
 
 int main() {
 if (Test.enabled()) {
 return 0;
 }
 
 .. // the rest of the main function
 }

That's a solution that works, but that relegates D's unittest keyword to be basically nothing more than version(unittest){}. If that's the most testing support the language provides, then it just doesn't provide testing support. I shouldn't have to throw away and work around the language for a feature it claims to have built in. Mike Swieton __ History will be kind to me, for I intend to write it. - Winston Churchill
Sep 15 2004
parent reply h3r3tic <h3r3tic dev.null> writes:
Ummm... would've forgotten. Fixing typeinfos is crucial for D 1.0
Sep 15 2004
parent reply pragma <pragma_member pathlink.com> writes:
In article <ciamqg$1t4j$1 digitaldaemon.com>, h3r3tic says...
Ummm... would've forgotten. Fixing typeinfos is crucial for D 1.0

I'll second that. Especially having full class reflection (methods, members, ctors, etc) as a part of typeinfo would be most appreciated. - Pragma
Sep 16 2004
parent Bastiaan Veelo <Bastiaan.N.Veelo ntnu.no> writes:
pragma wrote:

Ummm... would've forgotten. Fixing typeinfos is crucial for D 1.0

I'll second that. Especially having full class reflection (methods, members, ctors, etc) as a part of typeinfo would be most appreciated.

Same here, but for me it is not a showstopper for 1.0. I could wait until shortly after that ;-) I think support for shared libraries and good debugging info under Linux is more important. What I am actually hoping for is for gdc to catch up... Bastiaan.
Sep 16 2004
prev sibling next sibling parent "Lynn Allan" <l_d_allan adelphia.net> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cht9gl$20m8$1 digitaldaemon.com...
 Hence, I inadvertently overlook important issues. I know that
 this has been frustrating to some people, and I apologize for it.

 So I'd like to kick off this thread as an opportunity for all to post

 two Most Important Issues for D with respect to getting 1.0 done.

<alert comment="newbie"> Thanks for asking! I've been impressed by how well the development model based on a "benevolent czar with inner sanctum meritocracy" is working with "D". </alert>
Sep 11 2004
prev sibling next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <newshound digitalmars.com> escribió en el mensaje
news:cht9gl$20m8$1 digitaldaemon.com
| So I'd like to kick off this thread as an opportunity for all to post their
| two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
| mean pragmatic things like:
|
| 1) compiler bugs
| 2) language shortcomings with no reasonable workarounds
| 3) issues that are fundamentally blocking projects from using or proceeding
| with D
| 4) severe library faults

Since 0.99, DMD (Windows) has a bug which I can't reproduce where it suddenly
crashes where it didn't use to. I'm still trying to reduce it a send a bug
report.
So my MIID is that: consistent behavior from one release to the other unless an
explicit change has been made.
The other one would be consistency across Phobos. Things like MemoryStream,
MMFile and OutBuffer should be reviewed, unified, etc. imports made private,
etc.
Keep up the good work, Walter!

-----------------------
Carlos Santander Bernal
Sep 11 2004
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:ci0esc$s55$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> escribió en el mensaje
 news:cht9gl$20m8$1 digitaldaemon.com
 | So I'd like to kick off this thread as an opportunity for all to post their
 | two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
 | mean pragmatic things like:
 |
 | 1) compiler bugs
 | 2) language shortcomings with no reasonable workarounds
 | 3) issues that are fundamentally blocking projects from using or proceeding
 | with D
 | 4) severe library faults

 Since 0.99, DMD (Windows) has a bug which I can't reproduce where it suddenly
 crashes where it didn't use to. I'm still trying to reduce it a send a bug
 report.
 So my MIID is that: consistent behavior from one release to the other unless an
 explicit change has been made.
 The other one would be consistency across Phobos. Things like MemoryStream,
 MMFile and OutBuffer should be reviewed, unified, etc. imports made private,
 etc.

Carlos, excellent point! I'd planned to do exactly that once I've done a review of Exceptions and Mango (which I'm only part way through, and have been promising Kris for, oh, about 5 months!). If someone else wants to do that, though, that's fine by me. If no-one else takes it up by about this time next month, I'll do it. I will post a message like the chrebn$12f7$1 digitaldaemon.com, asking for input, and then do a review, debate with big-W, and release for group review. Matthew
Sep 11 2004
prev sibling next sibling parent Charles <Charles_member pathlink.com> writes:
It's time to prioritize and get us on a rational, sensible path for
releasing 1.0.

Awesome! -array arithmetic operations -complete CV4 debug info Thanks for including us! Charlie In article <cht9gl$20m8$1 digitaldaemon.com>, Walter says...
In some delightful ways, D is a victim of its own success. There's a lot of
traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
a day goes by without new proposals for features. It's simply beyond my
capacity to give these all the attention they deserve, or even to read them
all. I probably spend a minimum of 2 hours a day reading messages, and I
could easilly spend 12 hours a day at it, and accomplish nothing else.

Hence, I inadvertently overlook important issues. I know that this has been
frustrating to some people, and I apologize for it.

So I'd like to kick off this thread as an opportunity for all to post their
two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
mean pragmatic things like:

1) compiler bugs
2) language shortcomings with no reasonable workarounds
3) issues that are fundamentally blocking projects from using or proceeding
with D
4) severe library faults

I don't mean things like:

1) D 2.0 issues
2) feature proposals like "It would be nice if ..."
3) minor irritants
4) philosophical issues
5) issues that have been beaten to death already <g>

If a thread here exists for the topic, a reference to that thread would be
nice rather than reproducing it.

It's time to prioritize and get us on a rational, sensible path for
releasing 1.0.

Sep 12 2004
prev sibling next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cht9gl$20m8$1 digitaldaemon.com>, Walter says...
So I'd like to kick off this thread as an opportunity for all to post their
two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
mean pragmatic things like:

1) compiler bugs
2) language shortcomings with no reasonable workarounds
3) issues that are fundamentally blocking projects from using or proceeding
with D
4) severe library faults

Memory management issues - specifically, the interaction of the garbage collector with DLLs and the absence of C++-style memory management. I shall be more specific. (1) Suppose a class A has its own custom allocator/deallocator. Suppose it also has a destructor. I want to be able to call the destructor (~this()) /without/ also calling the deallocator. I also want to be able to call the deallocator (the delete override) /without/ also calling the destructor. Both of these things are possible in C++, but not in D. Same goes for allocation versus construction. (2) I want to be able to globally (not just per-class) override new. For example, I want to be able to do: # int[] array = new(myGlobalAllocator) array[n]; (3) And (most importantly) I want the garbage collector's memory-tracking mechanism to /notify me/ when the memory I've allocated via my custom allocator is no longer referenced. With these modifications in place, all memory allocation issues, including garbage collection across DLL boundaries; plugging in an alternative garbage collector; secure wiping of sensitive data; super-fast allocation/deallocation of small objects; etc., would become immediately and simply solvable. Okay, so that's three things, not two, but they go together, and missing any one of them out seemed a bit dumb. Jill
Sep 13 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ci3jv1$10v8$1 digitaldaemon.com>, Arcane Jill says...

I want to change my mind about what I consider the most important and urgent
impediment to writing code in D.

Instead of my previous suggestion (GC/DLL/memory management issues), I now want
to vote instead for DEBUGGING INFORMATION.

I can use D with Visual Studio to a limited extent, but it won't expand
non-primitive D types, and -- /most importantly/ -- if you try to step into a
template class or function, the source-code view jumps to COMPLETELY THE WRONG
PLACE.

Is this hindering development? Yes, absolutely. In fact, it's the sole reason
I'm not using templates yet.

Jill
Sep 14 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <ci6nf0$2p89$1 digitaldaemon.com>, Arcane Jill says...
In article <ci3jv1$10v8$1 digitaldaemon.com>, Arcane Jill says...

I want to change my mind 

 vote instead for DEBUGGING INFORMATION.

See Walter? this is very important!
I can use D with Visual Studio to a limited extent,

now imagine us linux guys... :(
[...] In fact, it's the sole reason I'm not using templates yet.

if all the other people here were like you there would be no linux projects at all. Ant
Sep 14 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
Ant wrote:
 In article <ci6nf0$2p89$1 digitaldaemon.com>, Arcane Jill says...
 
In article <ci3jv1$10v8$1 digitaldaemon.com>, Arcane Jill says...

I want to change my mind 

nah, nah, too late for that. ;)
vote instead for DEBUGGING INFORMATION.

See Walter? this is very important!
I can use D with Visual Studio to a limited extent,

now imagine us linux guys... :(
[...] In fact, it's the sole reason I'm not using templates yet.

if all the other people here were like you there would be no linux projects at all. Ant

with gdb. it's not perfect, but you can get a whole heck of a lot more info than with DMD.exe (I can only end up running this thru wine... the linux native one won't work with my glibc :-( ) is gdc (gcc backend) ever going to get updated to support the post .81 bugfixes/features(mixins) I'm getting kind of tired of the oldness of .81 and most importantly the bugs (can't make statically sized arrays cast properly to dynamically sized arrays for instance) or can it magically be compiled with the latest frontend source
Sep 15 2004
parent Ant <Ant_member pathlink.com> writes:
In article <ci93cn$12ol$1 digitaldaemon.com>, Daniel Horn says...
 

with gdb. it's not perfect, but you can get a whole heck of a lot more info than with DMD.exe (I can only end up running this thru wine... the linux native one won't work with my glibc :-( ) is gdc (gcc backend) ever going to get updated to support the post .81 bugfixes/features(mixins) I'm getting kind of tired of the oldness of .81 and most importantly the bugs (can't make statically sized arrays cast properly to dynamically sized arrays for instance) or can it magically be compiled with the latest frontend source

maybe it's time to try to keep it up with dmd as D is not changing dramatically from week to week. I was able to compile a small test with gdc when it first come out. (see you on the d.gnu group) Ant
Sep 15 2004
prev sibling parent "Lynn Allan" <l_d_allan adelphia.net> writes:
 Is this hindering development? Yes, absolutely. In fact, it's the sole

 I'm not using templates yet.

<alert comment="newbie"> No doubt I overuse debuggers ... but for me, learning a new language is typically an order of magnitude harder without a symbolic debugger. I'm trying to get the native Win32 TreeView to work, and it is mostly trial and error ... like coding in Braille. I don't look forward to a possible project using "D" that involves "bit twiddling" until a debugger is more usable. It can be VERY difficult to follow quasi-magical invocations of delegates, virtuals, overloading, constructors, destructors, etc. without a very servicable debugger. I'm reluctantly holding off learning and using mixins and associative arrays until debugging support improves. In the dsource forums, I came across the latest thread (2004-May-21: Project on hold) that effort on the debugger project ("DigDug") has been suspended until a gui library is standardized and matures. http://dsource.org/forums/viewtopic.php?t=153 </alert>
Sep 14 2004
prev sibling next sibling parent "Lynn Allan" <l_d_allan adelphia.net> writes:
Based on a number of your posts, I consider you (among several others) a
fluent "voice of reason" on this list. I'd been wondering what your MIID's
would be. The WB posted the question on the 10th and I have to speculate
that a number of people were more or less eagerly awaiting your response.

And thanks for your previous efforts to figure out how to get the Visual
Studio (98 & .Net) debugger partly working with "D".

Hope all is well with your family. We missed you some time back when you
needed some time by yourself. The list wasn't the same.
Sep 14 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:ci3jv1$10v8$1 digitaldaemon.com...
 (1) Suppose a class A has its own custom allocator/deallocator. Suppose it

 has a destructor. I want to be able to call the destructor (~this())

 also calling the deallocator. I also want to be able to call the

 (the delete override) /without/ also calling the destructor. Both of these
 things are possible in C++, but not in D. Same goes for allocation versus
 construction.

 (2) I want to be able to globally (not just per-class) override new. For
 example, I want to be able to do:

 #    int[] array = new(myGlobalAllocator) array[n];

You can do: int[] array = (cast(int*)myGlobalAllocator(n * int.sizeof))[0..n];
 (3) And (most importantly) I want the garbage collector's memory-tracking
 mechanism to /notify me/ when the memory I've allocated via my custom

 is no longer referenced.

That's what the destructor is for. But perhaps I'm misunderstanding you - do you mean having a custom allocator work with the existing gc? I don't know how that would work.
 With these modifications in place, all memory allocation issues, including
 garbage collection across DLL boundaries; plugging in an alternative

 collector; secure wiping of sensitive data; super-fast

 of small objects; etc., would become immediately and simply solvable.

You can already plug in a different gc - the API for it is simple - but it isn't so easy to write one. But I don't think that's what you mean. I think I understand what you're driving at, but I don't think it is easy to achieve :-(
Sep 21 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ciq19h$28dr$1 digitaldaemon.com>, Walter says...

 (2) I want to be able to globally (not just per-class) override new. For
 example, I want to be able to do:

 #    int[] array = new(myGlobalAllocator) array[n];

You can do: int[] array = (cast(int*)myGlobalAllocator(n * int.sizeof))[0..n];

That's not really very impressive though. It's no more advantageous than a simple function/functor. It achieves no more than: # int[] array = cast(int*)myMalloc(n*int.sizeof); only with more typing. Anyway - if you follow this thread, note that I actually changed my mind about this being a most important issue. In the end, I voted instead for complete debugging information.
You can already plug in a different gc - the API for it is simple - but it
isn't so easy to write one. But I don't think that's what you mean. I think
I understand what you're driving at, but I don't think it is easy to achieve
:-(

It's not urgently important. Maybe when we're both not so busy (!) I'll mention what I'm going on about in more detail and in a different thread. If you could prioritise the debugging thing over this, that'd be great. Many thanks for D, and its continuing improvement. Jill
Sep 21 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cir7m9$1imj$1 digitaldaemon.com>, Arcane Jill says...
In article <ciq19h$28dr$1 digitaldaemon.com>, Walter says...

 (2) I want to be able to globally (not just per-class) override new. For
 example, I want to be able to do:

 #    int[] array = new(myGlobalAllocator) array[n];

You can do: int[] array = (cast(int*)myGlobalAllocator(n * int.sizeof))[0..n];

That's not really very impressive though. It's no more advantageous than a simple function/functor. It achieves no more than: # int[] array = cast(int*)myMalloc(n*int.sizeof); only with more typing.

Placement new would be nice. A quick scan of the docs doesn't seem to imply this exists. But it's not in my top 5 list of needed things. Sean
Sep 22 2004
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:
<snip>
 So I'd like to kick off this thread as an opportunity for all to post their
 two Most Important Issues for D with respect to getting 1.0 done.

1. A complete spec. 2. Complete functionality in line with the spec. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 13 2004
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner wikiservice.at> writes:
Walter wrote:
 So I'd like to kick off this thread as an opportunity for all to post their
 two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
 mean pragmatic things like:
 
 1) compiler bugs
 2) language shortcomings with no reasonable workarounds
 3) issues that are fundamentally blocking projects from using or proceeding
 with D
 4) severe library faults
 
 I don't mean things like:
 
 1) D 2.0 issues
 2) feature proposals like "It would be nice if ..."
 3) minor irritants
 4) philosophical issues
 5) issues that have been beaten to death already <g>

It might not exactly follow your guidelines, but I would add: static initialization of dynamic arrays and hashes (assoziative arrays). In Perl you write just my array=( 1, 12, 333, -4, 5); my %hash=( 'darkred' => '#bb0000', 'red' => '#ff0000', 'lightred' => '#ffcccc'); and this makes array and hashes really a pleasure to use. Of course, the exact syntax for this isn't important. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 13 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Helmut Leitner wrote:
<snip>
 It might not exactly follow your guidelines, but I would add:
 static initialization of dynamic arrays and hashes (assoziative arrays).
 
 In Perl you write just
 
    my  array=( 1, 12, 333, -4, 5);
    my %hash=(  'darkred' => '#bb0000',  'red' => '#ff0000',  'lightred' =>
'#ffcccc');
 
 and this makes array and hashes really a pleasure to use.
 Of course, the exact syntax for this isn't important.

Presumably they'd take on the exact same syntax we already have for static initialisation of static arrays. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 14 2004
prev sibling next sibling parent "Lynn Allan" <l_d_allan adelphia.net> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cht9gl$20m8$1 digitaldaemon.com...
 It's time to prioritize and get us on a rational, sensible path for
 releasing 1.0.

Years ago, there was a "metric" for whether software was getting ready for release: existing bugs were getting fixed faster than new bugs were being reported. Overall, you like to see that the number of unresolved bugs has been declining long enough to discern a trend. Just curious: is this the case for D? Does this seem like a reasonable guide to whether software is getting ready to release? Another question to consider asking the list participants (if not already asked): Do you consider D 0.1## ready to release as ver 1.0? If not, why?
Sep 14 2004
prev sibling next sibling parent =?ISO-8859-1?Q?Julio_C=E9sar_Carrascal_Urquijo?= writes:
I'm hoping it isn't to late to post but I wanted to read all posts to be 
sure I wasn't repeating what someone said.

I would want to implement my class methods in another file. When I want 
to have a platform specific implementation in C++ I ussualy create a 
linux/, windows/ and macosx/ folder.

In D I have keep the entire implementation in one file and use 
version()s. Witch isn't to bad when there's only two platforms but three 
or more platforms isn't that easy.

The other way is to maintain copies of each file for each platform in 
diferent folders and then I have to remember that when I change one of 
the common methods I have to update the other files. This kind of 
development doesn't scale.

In a previous post you said we could use a "striper" to acomplish this. 
¿Where can I find such a tool?.


Thanks.


Walter wrote:

 In some delightful ways, D is a victim of its own success. There's a lot of
 traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
 a day goes by without new proposals for features. It's simply beyond my
 capacity to give these all the attention they deserve, or even to read them
 all. I probably spend a minimum of 2 hours a day reading messages, and I
 could easilly spend 12 hours a day at it, and accomplish nothing else.
 
 Hence, I inadvertently overlook important issues. I know that this has been
 frustrating to some people, and I apologize for it.
 
 So I'd like to kick off this thread as an opportunity for all to post their
 two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
 mean pragmatic things like:
 
 1) compiler bugs
 2) language shortcomings with no reasonable workarounds
 3) issues that are fundamentally blocking projects from using or proceeding
 with D
 4) severe library faults
 
 I don't mean things like:
 
 1) D 2.0 issues
 2) feature proposals like "It would be nice if ..."
 3) minor irritants
 4) philosophical issues
 5) issues that have been beaten to death already <g>
 
 If a thread here exists for the topic, a reference to that thread would be
 nice rather than reproducing it.
 
 It's time to prioritize and get us on a rational, sensible path for
 releasing 1.0.
 
 

Sep 14 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Walter wrote:
...
 So I'd like to kick off this thread as an opportunity for all to post their
 two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
 mean pragmatic things like:

Thanks for asking. I have some specific suggestions for Phobos: 1) Rename std.std* to std.*, i.e. std.stdarg => std.arg std.stdint => std.integer std.stdio => std.io 2) Reorganize a little bit: std.asserterror => std.error.asserterr std.outofmemory => std.error.outofmemory std.switcherr => std.error.switcherr std.syserror => std.error.syserr object => std.object 3) Remove printf and wprintf from object.d and change the bool alias to: alias int bool; /* (line 11) */ After changing the definition of bool, these redundant lines could be removed from Phobos: public alias recls_bool_t boolean; /* std.recls (line 90) */ public alias int boolean; /* std.loader (line 81) */ -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Sep 15 2004
next sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
J C Calvarese wrote:
 
 Walter wrote:
 ...
 So I'd like to kick off this thread as an opportunity for all to post their
 two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
 mean pragmatic things like:

Thanks for asking. I have some specific suggestions for Phobos: 1) Rename std.std* to std.*, i.e. std.stdarg => std.arg std.stdint => std.integer std.stdio => std.io 2) Reorganize a little bit: std.asserterror => std.error.asserterr

maybe std.error.assert ?
      std.outofmemory => std.error.outofmemory
      std.switcherr   => std.error.switcherr

maybe std.error.switch ?
      std.syserror    => std.error.syserr

maybe std.error.sys ?
 
      object          => std.object
 
 3) Remove printf and wprintf from object.d and change the bool alias to:
    alias int bool; /* (line 11) */
 
 After changing the definition of bool, these redundant lines could be
 removed from Phobos:
    public alias recls_bool_t boolean;     /* std.recls (line 90) */
    public alias int boolean;              /* std.loader (line 81) */
 
 --
 Justin (a/k/a jcc7)
 http://jcc_7.tripod.com/d/

-- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 15 2004
parent J C Calvarese <jcc7 cox.net> writes:
In article <41493850.9E050BE9 hls.via.at>, Helmut Leitner says...
 2) Reorganize a little bit:
      std.asserterror => std.error.asserterr

maybe std.error.assert ?
      std.outofmemory => std.error.outofmemory
      std.switcherr   => std.error.switcherr

maybe std.error.switch ?
      std.syserror    => std.error.syserr

maybe std.error.sys ?

I don't think the assert or switch will work as module names since they're keywords, but "sys" should work and that's a good substitution as far as I'm concerned.
-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

jcc7
Sep 16 2004
prev sibling parent reply Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <ciaj0k$1rrg$1 digitaldaemon.com>, J C Calvarese says...

I have some specific suggestions for Phobos:

1) Rename std.std* to std.*, i.e.
    std.stdarg => std.arg
    std.stdint => std.integer
    std.stdio  => std.io

Good.
2) Reorganize a little bit:
     std.asserterror => std.error.asserterr
     std.outofmemory => std.error.outofmemory
     std.switcherr   => std.error.switcherr
     std.syserror    => std.error.syserr

Why not: std.asserterror => std.error.assert std.outofmemory => std.error.outofmemory std.switcherr => std.error.switch std.syserror => std.error.system
     object          => std.object


3) Remove printf and wprintf from object.d and change the bool alias to:
   alias int bool; /* (line 11) */

After changing the definition of bool, these redundant lines could be 
removed from Phobos:
   public alias recls_bool_t boolean;     /* std.recls (line 90) */
   public alias int boolean;              /* std.loader (line 81) */

It's good enough for me (considered I vote for true-boolean type :-). Ciao
Sep 16 2004
parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 std.asserterror => std.error.assert
 std.outofmemory => std.error.outofmemory
 std.switcherr   => std.error.switch
 std.syserror    => std.error.system

std.error.assert and std.error.switch wohn't work as module names, presumably because they contain identifiers that are keywords. std.error.asserterror and std.error.switcherror should work though.
Sep 16 2004
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner wikiservice.at> writes:
And, of course:

   std.c.windows.windows.d

should go from about 10% to at least 95% coverage of the Win32 API.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
Sep 16 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Helmut Leitner wrote:
 And, of course:
 
    std.c.windows.windows.d
 
 should go from about 10% to at least 95% coverage of the Win32 API.

All in the same file? ;) -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Sep 16 2004
parent Helmut Leitner <leitner hls.via.at> writes:
J C Calvarese wrote:
 
 Helmut Leitner wrote:
 And, of course:

    std.c.windows.windows.d

 should go from about 10% to at least 95% coverage of the Win32 API.

All in the same file? ;)

Not necessarily. But the original API header files are monolithic, so one would have to invent a modularization which will be not intuitive to Win32 users (you can't derive a hint to it from the 5 volume Win32 API reference) There are still collision problems if a module includes windows.d from Phobos AND windows.d from Pavel (needed for additional functions) ======================================================= * identically defined external C functions * * identically defined C structs * * identically defined C constants and enums * * should not create collisions * ======================================================= If this is not solved, one must ensure that there are absolutely no intersections of external API declarations if you include more than one API interface module in one of your sources. But this is almost impossible, because you notice the collision only if you actually use an item. So it may bite you any time. The Win32 API is vast, it is impossible to wrap it (and Walter doesn't promote wrapper functions anyway). It would be impossible to expect programmers - to write the external function declarations they need on demand or - copy & paste them from a repository on demand There must be a foolproof way to access the Win32 API. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 17 2004
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <414A7C9E.543F83BF wikiservice.at>, Helmut Leitner says...
And, of course:

   std.c.windows.windows.d

should go from about 10% to at least 95% coverage of the Win32 API.

Why should the standard language have a complete map to the Win32 API? This should really be in its own module. Maybe a separate win32.d module could contain the complete API. If Billy G has his way Win32 will become obsolete anyways.
Sep 17 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cies8m$1iqg$1 digitaldaemon.com>, Mark T says...
Maybe a separate win32.d module could contain the complete API. If Billy G has
his way Win32 will become obsolete anyways.

As well the .NET windowing API. Sometimes it seems MS deprecates stuff before it's even shipped ;) Sean
Sep 17 2004
parent Charlie <Charlie_member pathlink.com> writes:
Hehe, can you say , cha-ching!
Charlie

In article <cieto4$1m33$1 digitaldaemon.com>, Sean Kelly says...
In article <cies8m$1iqg$1 digitaldaemon.com>, Mark T says...
Maybe a separate win32.d module could contain the complete API. If Billy G has
his way Win32 will become obsolete anyways.

As well the .NET windowing API. Sometimes it seems MS deprecates stuff before it's even shipped ;) Sean

Sep 18 2004
prev sibling parent reply Helmut Leitner <helmut.leitner wikiservice.at> writes:
Mark T wrote:
 
 In article <414A7C9E.543F83BF wikiservice.at>, Helmut Leitner says...
And, of course:

   std.c.windows.windows.d

should go from about 10% to at least 95% coverage of the Win32 API.

Why should the standard language have a complete map to the Win32 API? This should really be in its own module.

(1) because you get thousands of collission problems otherwise (2) D will never be a success if it doesn't support Windows out of the box
 Maybe a separate win32.d module could contain the complete API. 

collission problems.
 If Billy G has his way Win32 will become obsolete anyways.

It won't, for (1) it's at the basis of so many application (2) the .NET -> Win32 Interface is just as broken and slow as the Java native code interface to Windows -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 17 2004
next sibling parent reply Berin Loritsch <bloritsch d-haven.org> writes:
Helmut Leitner wrote:
 
 Mark T wrote:
 
In article <414A7C9E.543F83BF wikiservice.at>, Helmut Leitner says...

And, of course:

  std.c.windows.windows.d

should go from about 10% to at least 95% coverage of the Win32 API.

Why should the standard language have a complete map to the Win32 API? This should really be in its own module.

(1) because you get thousands of collission problems otherwise

?? Huh? A little more detail please?
    (2) D will never be a success if it doesn't support Windows out of the box

I suppose there is noone using other operating systems out there then? How much of a success does D have to be before it is good to write software in? You can support windows without mapping the whole win32 API. I don't know about you, but I found writing MFC code bad enough--whenever I even attempted to look at win32 code it gave me a headache. As long as there is a windowing/gui toolkit (several are under development), and standard libraries to do your I/O work then those libraries can map to whatever API is available. The bottom line is to start reasonably then build on that. The entire win32 API is quite large and it covers everything from windowing to threads to socket IO to file IO to driver communications. Not to mention the hacked POSIX half-support. Do you really want to bloat the D API with all that nastiness?
Maybe a separate win32.d module could contain the complete API. 

collission problems.

Info? Supporting information would help. WHat do you mean "collision problems"?
If Billy G has his way Win32 will become obsolete anyways.

It won't, for (1) it's at the basis of so many application (2) the .NET -> Win32 Interface is just as broken and slow as the Java native code interface to Windows

You lost me. Yes, the first argument is the only one that makes sense here. They would be quite foolish to simply remove it and render the current investment in software null and void. MS would lose their shirt because noone would want to upgrade. When you say Win32 API just what part are you talking about? If you are merely limiting it to the GUI related API then I would agree that the Java API (built in and for Java) is slower than many C++ programs, but if you know how to work with it instead of against it, then it is fast enough. Don't be in such tunnel vision to assume that the world is Windows. To tell the truth, there is a lot of potential for D outside the world of Windows--if the debugging information can get straightened out. If it's a pain to find what's wrong in your programs then noone will use it.
Sep 17 2004
parent Helmut Leitner <helmut.leitner wikiservice.at> writes:
Berin Loritsch wrote:
 
 Helmut Leitner wrote:
 Mark T wrote:

In article <414A7C9E.543F83BF wikiservice.at>, Helmut Leitner says...

And, of course:

  std.c.windows.windows.d

should go from about 10% to at least 95% coverage of the Win32 API.

Why should the standard language have a complete map to the Win32 API? This should really be in its own module.

(1) because you get thousands of collission problems otherwise

?? Huh? A little more detail please?

As I said: it's way too inefficient to define the API on demand, so users will expect the Win32 API predefined. If (Phobos)windows.d isn't complete (but anyone will still build on it) you will combine another module for the rest. The chance is extremely high that there is an overlap that will lead to collisions. This will bite nearly everyone doing Win32, especially those building fundamental modules.
    (2) D will never be a success if it doesn't support Windows out of the box

I suppose there is noone using other operating systems out there then? How much of a success does D have to be before it is good to write software in?

I don't understand your question. It's a question of efficiency.
 You can support windows without mapping the whole win32 API.  I don't
 know about you, but I found writing MFC code bad enough--whenever I even
 attempted to look at win32 code it gave me a headache.  As long as there
 is a windowing/gui toolkit (several are under development), and standard
 libraries to do your I/O work then those libraries can map to whatever
 API is available.  The bottom line is to start reasonably then build on
 that.  The entire win32 API is quite large and it covers everything from
 windowing to threads to socket IO to file IO to driver communications.
 Not to mention the hacked POSIX half-support.  Do you really want to
 bloat the D API with all that nastiness?

No, but there will be those that build the D-GUI APIs. And Win32 is the last resort if you need to do special things. MFC is built as a C++ wrapper for the Win32. We will not get good D wrappers if it is a lot of nasty work to accesss the Win32 API.
Maybe a separate win32.d module could contain the complete API.

collission problems.

Info? Supporting information would help. WHat do you mean "collision problems"?
If Billy G has his way Win32 will become obsolete anyways.

It won't, for (1) it's at the basis of so many application (2) the .NET -> Win32 Interface is just as broken and slow as the Java native code interface to Windows

You lost me. Yes, the first argument is the only one that makes sense here. They would be quite foolish to simply remove it and render the current investment in software null and void. MS would lose their shirt because noone would want to upgrade. When you say Win32 API just what part are you talking about? If you are merely limiting it to the GUI related API then I would agree that the Java API (built in and for Java) is slower than many C++ programs, but if you know how to work with it instead of against it, then it is fast enough.

Fast enough is sometimes not enough. Last time I tested, JNI and .NET had the same API call overhead of about 40 usec (950 MHz Athlon). This may not seem much, but it is the equvalent to about 200 simple C function calls for a one API call. So, forget about high performance timing and pixel io. D doesn't have this overhead! The Win32 API isn't that bad if you are used to it. A lightweight wrapper for application building and menus / MDI would be enough if the access to the other Win32 functions is easy. I argue that it should be easy for at least 95% of Win32. Things needn't be perfect. But usable.
 Don't be in such tunnel vision to assume that the world is Windows.
 To tell the truth, there is a lot of potential for D outside the
 world of Windows

Cool down, I know that very well. I live in both worlds. Still a large part of the world is Windows.
 --if the debugging information can get straightened
 out.  If it's a pain to find what's wrong in your programs then
 noone will use it.

I'm sure that Walter will work that out. This is just work, not a problem. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 19 2004
prev sibling parent J C Calvarese <jcc7 cox.net> writes:
Helmut Leitner wrote:
 
 Mark T wrote:
 
In article <414A7C9E.543F83BF wikiservice.at>, Helmut Leitner says...

And, of course:

  std.c.windows.windows.d

should go from about 10% to at least 95% coverage of the Win32 API.



I agree with this, but I think there'd be too much code for one file (windows.d is already huge as it is). It should be split into multiple modules: std.c.windows.commdlg std.c.windows.ole2 std.c.windows.oleauto std.c.windows.oleextra std.c.windows.winbase std.c.windows.windef std.c.windows.wingdi std.c.windows.winnt std.c.windows.winuser std.c.windows.wtypes
Why should the standard language have a complete map to the Win32 API?
This should really be in its own module.

(1) because you get thousands of collission problems otherwise

The collisions can be very annoying, but there are solutions -- even without Walter's direct help. Two methods that I've seen: 1) Standalone: don't use std.c.windows.windows and its buddies in Phobos 2) Complimentary: leave out the sections in the extra headers that are already in Phobos There are already a couple projects aim to be suitable ports of the Win32 headers: Core32 and Y. Tomino's project. Core32 http://dsource.org/projects/core32/ The idea behind the Core32 project is to allow either method. Method 2 is used by default, but Method 1 can be used by compiling in the version(STANDALONE) code. I'm currently using Core32, and I have write access to the SVN repository. Many of the version(STANDALONE) locations have been added based on trial-and-error. I fix 'em when I find 'em. Y. Tomino's project http://hp.vector.co.jp/authors/VA028375/d/windows.h.html This project only uses Method 1. I've used this code in the past. It's a solid port, too. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Sep 17 2004
prev sibling next sibling parent "Phill" <phill pacific.net.au> writes:
I have one suggestion, that I know you more than likely wont adopt.

That is, you pluck about half a dozen of the very talented
people on this NG(these would more than likely be the ones that are
frustrated), and utilize their talents.
Give them each a particular task that you want done, whether it be a bug fix
or enhancement, when they complete it you can take a look. If you are happy,
then you can repeat the process.....

Im sure those talented people would be honored to be involved, and you could
still be in control.

Otherwise you just might end up having to post this same message again in 6
months time.

You arent superman, no offense intended(probably a lot taken).

Phill

 "Walter" <newshound digitalmars.com> wrote in message
news:cht9gl$20m8$1 digitaldaemon.com...
 In some delightful ways, D is a victim of its own success. There's a lot

 traffic in the D newsgroups, sometimes getting to 100 messages per day.

 a day goes by without new proposals for features. It's simply beyond my
 capacity to give these all the attention they deserve, or even to read

 all. I probably spend a minimum of 2 hours a day reading messages, and I
 could easilly spend 12 hours a day at it, and accomplish nothing else.

 Hence, I inadvertently overlook important issues. I know that this has

 frustrating to some people, and I apologize for it.

 So I'd like to kick off this thread as an opportunity for all to post

 two Most Important Issues for D with respect to getting 1.0 done. By MIID,

 mean pragmatic things like:

 1) compiler bugs
 2) language shortcomings with no reasonable workarounds
 3) issues that are fundamentally blocking projects from using or

 with D
 4) severe library faults

 I don't mean things like:

 1) D 2.0 issues
 2) feature proposals like "It would be nice if ..."
 3) minor irritants
 4) philosophical issues
 5) issues that have been beaten to death already <g>

 If a thread here exists for the topic, a reference to that thread would be
 nice rather than reproducing it.

 It's time to prioritize and get us on a rational, sensible path for
 releasing 1.0.

Sep 18 2004
prev sibling next sibling parent reply Stephen Silber <Stephen_member pathlink.com> writes:
DEBUGGING OH MY GOD DEBUGGING!

Everything else I've seen in this thread is incredibly minor in the face of
being able to easily debug a program!  I think only one other person mentioned
it.

Until I can just fire up a debugger and see into data structures, D is sadly not
really usuable in my projects, as I want to build products more than fight with
stupid watch expressions just to look inside a struct.

Please oh please don't make me go back to C++ and/or perl!  Please get real
debugging support in here!

(This issue should be filed under "3) issues that are fundamentally blocking
projects from using or proceeding with D".)
Sep 19 2004
parent "Walter" <newshound digitalmars.com> writes:
"Stephen Silber" <Stephen_member pathlink.com> wrote in message
news:cil97f$1nn0$1 digitaldaemon.com...
 DEBUGGING OH MY GOD DEBUGGING!

I heard you <g>!
Sep 19 2004
prev sibling next sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
My personal concern are the array issues which clearly are a 2.0 topic.
Anyhow: one 1.0-issue related to this are "Array Operations" explained in
the specs.

It should be finally be made clear whether these are going to be part of 1.0
or not. My personal belief is that they are ill defined leading to
contradicting interpretations. Unfortunately, the current spec is so vague
that it is really hard to argue against them.

If it is the plan to implement them in 1.0, this should happen soon, because
it will most likely introduce a bunch of problems.

Otherwise (and this is what I would suggest) the whole section should be
thrown out of the specs completely and the topic should be rolled up anew,
once there is a clear concept for multidimensional arrays.
Sep 24 2004
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I've been silent, waiting to think of an important enough issue.  Then 
today in the shower, I remembered two of them.  They are discussed at 
digitalmars.D/6766, but I'm 
going to give more detail here to (hopefully) make things more clear.

1. Create delegates from arbitrary pointers
2. Access stack variables as an anonymous struct



1. Create delegates from arbitrary pointers

This is required so that we have a portable way of creating a delegate 
from an arbitrary pointer and an arbitrary function pointer.  You can 
create delegates using unions, but that is not portable.  Plus, it would 
require templates that were parameterized by the return value AND an 
unknown number of arguments.

I would prefer that D simply support this syntax:
	<ptr>.delegate <ret>(<args>) { <code> }
where <ptr> could be any pointer or class reference.

NOTE: If <ptr> is a class reference, then the delegate can ONLY access 
the fields and functions which the enclosing block can access.  That is, 
it cannot access private or protected fields or functions unless the 
enclosing block could.

The compiler should support a 'this' pointer inside the delegate which 
allows the code to access the pointer.  But it should also allow fields 
of structs, unions, and classes to be accessed without having to use 
'this'.  So all three of the following delegates would be legal:
	struct S { int a; }
	class  C { public int a(); }

	S s;
	C c = new C;
	char **p = <whatever>;

	void delegate() foo = &s.delegate void()
				{ a++; };
	void delegate() bar =  c.delegate void()
				{ printf("%d", a()); };
	void delegate() baz =  p.delegate void()
				{ printf("%s", *this); };



2. Access stack variables as an anonymous struct

This is necessary so that you can copy stack delegates.

I want to be able to get a pointer to an anonymous struct.  The pointer 
points to the current stack frame, and the anonymous struct lines up 
with the stack variables.

The anonymous struct should also include a dup() property, like this:
	struct _anon_stack_struct_12345 {
		_anon_stack_struct_12345 *dup() {
			return this[0..1].dup;
		}
	}

My suggestion is that the way to do this is via a new keyword, "stackframe":
	int a;
	int *p1 = &a;
	int *p2 = &(stackframe.a);
	// p1 points to the same thing as p2

When I want to copy a stack delegate, what I do is get the stack 
structure, copy it, and then use (1) above to create a delegate.
	void delegate() getFoo() {
		int x,y,z;
		return stackframe.dup.delegate void() {
			return x+y+z;
		}
	}
Sep 29 2004