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:

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.

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:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1293

An access problem with private members in nested classes.  Reference here:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1189

Bug with stdargs used in multiple translation units.  Reference here:
http://www.digitalmars.com/drn-bin/wwwnews?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


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.


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:

#public:









#class StringTemplate(T) : Array!(T) {
#public:






#alias StringTemplate!(char) String;

#void main() {




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:






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:


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





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:



  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:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1668

* any writef bug or stdarg bug. Is the following still a problem?
http://www.digitalmars.com/drn-bin/wwwnews?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,
http://www.digitalmars.com/drn-bin/wwwnews?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 ?


<snip>

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 ?


 <snip>

 Not sure what you mean by that....


Embedded here means that i want to put the application created with D into  
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




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>




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


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.


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


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.


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.








































2) Stronger support for DLLs.
----------------------------------------
Here's a part of Matthew's post that touchs on the subject at:
http://www.digitalmars.com/drn-bin/wwwnews?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.


<snip>

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


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

- 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

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















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:


















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>


















 
 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


their

 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:



(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 


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


if you used the gcc backend to compile D, then it works quite nicely 
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...

 


if you used the gcc backend to compile D, then it works quite nicely 
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


reason

 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


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:




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


allocator

 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


garbage

 collector; secure wiping of sensitive data; super-fast


allocation/deallocation

 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:




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:



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:




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:



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.


<snip>

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


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 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 
http://www.digitalmars.com/drn-bin/wwwnews?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