www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - An Anti-Big Feature Request

reply downs <default_357-line yahoo.de> writes:
I have an Anti-Big Feature request; that is, a request against new features.

When this const issue will finally be solved to most peoples' satisfaction,
kindly consider inserting a period of consolidation.

No more sudden, game-changing new super features for a while.
Maybe fix some long-standing bugs.
Maybe finally implement the generational GC.
Maybe actually get DbC inheritance to work like it's supposed to.
Maybe give memory back to the OS on occasion.
Maybe revisit some 1.0 concepts and consider if they're still needed.
Maybe add small things everybody can agree are good (return type deduction
comes to mind).
Aim for low-hanging fruits, stuff we can agree on for once.
How about a redundancy free import syntax?

D's 2.0 series has been characterized by a series of fundamental changes
(const, closures),
but what really makes a new release great is the polish. Small stuff everybody
looks forward to.
Clean up the issues with the OMF tools? Maybe even consider switching to PE?
(Heresy, I know; however, it is fact that GDC has no problem with megabyte-long
symbol names)

Oh, and please, delay the AST macros for a while. My head is still spinning
with closures. :)
 --downs

PS:
  Personal wish list:
    * Struct copy semantics, lazy and ref storage types
    * a way to detect ref in a delegate parameter list
    * Improved compile-time information for enums
    * TRACED EXCEPTIONS ;____; yeah I wish
    * Allow inheriting from superclasses' nested classes

PPS: Representative sentiment from #d:

 <fundesktop> a stable, feature complete compiler without bugs and good
additional tools
 <fundesktop> SOMETHING WHICH D WILL NEVER GET
Dec 14 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"downs" <default_357-line yahoo.de> wrote in message 
news:fjv3hq$15gd$1 digitalmars.com...

I have an Anti-Big Feature request; that is, a request against new 
features.

 When this const issue will finally be solved to most peoples' 
 satisfaction,
 kindly consider inserting a period of consolidation.

 No more sudden, game-changing new super features for a while.
 Maybe fix some long-standing bugs.
 Maybe finally implement the generational GC.
 Maybe actually get DbC inheritance to work like it's supposed to.
 Maybe give memory back to the OS on occasion.
 Maybe revisit some 1.0 concepts and consider if they're still needed.
 Maybe add small things everybody can agree are good (return type deduction 
 comes to mind).
 Aim for low-hanging fruits, stuff we can agree on for once.
 How about a redundancy free import syntax?

 D's 2.0 series has been characterized by a series of fundamental changes 
 (const, closures),
 but what really makes a new release great is the polish. Small stuff 
 everybody looks forward to.
 Clean up the issues with the OMF tools? Maybe even consider switching to 
 PE?
 (Heresy, I know; however, it is fact that GDC has no problem with 
 megabyte-long symbol names)

 Oh, and please, delay the AST macros for a while. My head is still 
 spinning with closures. :)
 --downs


Agreed on (virtually) every count.


 PS:
  Personal wish list:
    * TRACED EXCEPTIONS ;____; yeah I wish


Huh!  Tango's had those for months.

Yeah.  What.
Dec 14 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Jarrett Billingsley wrote:

 "downs" <default_357-line yahoo.de> wrote in message 
 news:fjv3hq$15gd$1 digitalmars.com...

 I have an Anti-Big Feature request; that is, a request against new 
 features.

 When this const issue will finally be solved to most peoples' 
 satisfaction,
 kindly consider inserting a period of consolidation.

 No more sudden, game-changing new super features for a while.
 Maybe fix some long-standing bugs.
 Maybe finally implement the generational GC.
 Maybe actually get DbC inheritance to work like it's supposed to.
 Maybe give memory back to the OS on occasion.
 Maybe revisit some 1.0 concepts and consider if they're still needed.
 Maybe add small things everybody can agree are good (return type deduction 
 comes to mind).
 Aim for low-hanging fruits, stuff we can agree on for once.
 How about a redundancy free import syntax?

 D's 2.0 series has been characterized by a series of fundamental changes 
 (const, closures),
 but what really makes a new release great is the polish. Small stuff 
 everybody looks forward to.
 Clean up the issues with the OMF tools? Maybe even consider switching to 
 PE?
 (Heresy, I know; however, it is fact that GDC has no problem with 
 megabyte-long symbol names)

 Oh, and please, delay the AST macros for a while. My head is still 
 spinning with closures. :)
 --downs


 
 Agreed on (virtually) every count.
 

 PS:
  Personal wish list:
    * TRACED EXCEPTIONS ;____; yeah I wish


 
 Huh!  Tango's had those for months.
 
 Yeah.  What. 


I'm looking into giving memory back to the OS as well.  It will take 
some re-engineering of the GC, but it seems quite doable.


Sean
Dec 14 2007
prev sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
Jarrett Billingsley wrote:

 PS:
  Personal wish list:
    * TRACED EXCEPTIONS ;____; yeah I wish


 
 Huh!  Tango's had those for months.


Not on Windows, unless I've missed something?

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Dec 15 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Matti Niemenmaa wrote:

 Jarrett Billingsley wrote:

 PS:
  Personal wish list:
    * TRACED EXCEPTIONS ;____; yeah I wish


 Huh!  Tango's had those for months.


 
 Not on Windows, unless I've missed something?


Glue in Flectioned and you get it on Windows & Linux.
Dec 15 2007
parent Jascha Wetzel <firstname mainia.de> writes:
Robert Fraser wrote:

 Matti Niemenmaa wrote:

 Jarrett Billingsley wrote:

 PS:
  Personal wish list:
    * TRACED EXCEPTIONS ;____; yeah I wish


 Huh!  Tango's had those for months.


 Not on Windows, unless I've missed something?


 
 Glue in Flectioned and you get it on Windows & Linux.


or use ddbg ;)
Dec 15 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Downs,

[goood stuff]

Yup. There are a few bugs I'd like to see fixed to.



 Clean up the issues with the OMF tools? Maybe even consider switching
 to PE?
 (Heresy, I know; however, it is fact that GDC has no problem with
 megabyte-long symbol names)


BTW, Why isn't this getting fixed? people known how to fix this, several 
solutions have been thrown out there. this should have been fixed a long 
time ago.

here's my take on it:

If the symbol is over 1Kb*, MD5 it or something and use that. Hash them down 
to 128bits and your chances of collision are so remote it's not even worth 
thinking about.  If you need to be able to go back to the original, stuff 
a table in the .obj that maps the two. This wouldn't make for human readable 
link errors but the gzipping that is used now doesn't either. 

* or pick your size
Dec 14 2007
parent 0ffh <frank frankhirsch.youknow.what.todo.net> writes:
BCS wrote:

 Reply to Downs,
 
 [goood stuff]
 


Hear! Hear!
Hear the voices of calmness & tranquility!

=)

Kind regards, frank
Dec 14 2007
prev sibling next sibling parent reply downs <default_357-line yahoo.de> writes:
downs wrote:

     * a way to detect ref in a delegate parameter list


Huh. After writing this, in a sudden flash of insight, I reinvented a method
that has been in use in std.bind for ages now (props to h3).

Consider the following code:


 template _isRef(C, size_t which) {
   alias ParameterTypeTuple!(C) pt;
   pt[0..which] pre;
   const pt[which] test;
   pt[which+1..$] post;
   const bool r=!is(typeof(C(pre, test, post)));
 }
 template isRef(C, size_t which) { const bool isRef=_isRef!(C, which).r; }



What does this mean?
Succinctly put, if (and only if) a parameter is ref, then trying to call
the delegate/function type in question with a constant value for that parameter
will fail. The const bool r expression literally means "true if calling C with
a constant test fails to produce a return value".

Should there be a place to collect metaprogramming thingies like this so people
don't have to reinvent the wheel?

 I vote std.meta! :)


 --downs
Dec 14 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
downs wrote:

 
 Should there be a place to collect metaprogramming thingies like this so people
 don't have to reinvent the wheel?
 
  I vote std.meta! :)


hehe... Tango had a meta package until CTFE came along and rendered the 
bulk of it pointless.  This particular routine would make sense in 
std.traits though.


Sean
Dec 14 2007
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 12/15/07, downs <default_357-line yahoo.de> wrote:

 Should there be a place to collect metaprogramming thingies like this so people
 don't have to reinvent the wheel?

  I vote std.meta! :)


I would have thought std.traits.
Dec 14 2007
parent downs <default_357-line yahoo.de> writes:
Janice Caron wrote:

 On 12/15/07, downs <default_357-line yahoo.de> wrote:

 Should there be a place to collect metaprogramming thingies like this so people
 don't have to reinvent the wheel?

  I vote std.meta! :)


 
 I would have thought std.traits.


Right, my mistake. Sorry. (same to Sean)

In other, not entirely unrelated, news, scrapple.tools' /fix/ now preserves
refness of its arguments :)
(not that anybody uses that except me (sadly), but it will make my code a bit
easier)

 --downs
Dec 15 2007
prev sibling next sibling parent reply Hxal <hxal freenode.d.channel> writes:
downs Wrote:


 I have an Anti-Big Feature request; that is, a request against new features.
 
 When this const issue will finally be solved to most peoples' satisfaction,
 kindly consider inserting a period of consolidation.
 
 No more sudden, game-changing new super features for a while.
 Maybe fix some long-standing bugs.
 Maybe finally implement the generational GC.
 Maybe actually get DbC inheritance to work like it's supposed to.
 Maybe give memory back to the OS on occasion.
 Maybe revisit some 1.0 concepts and consider if they're still needed.
 Maybe add small things everybody can agree are good (return type deduction
comes to mind).
 Aim for low-hanging fruits, stuff we can agree on for once.
 How about a redundancy free import syntax?
 
 D's 2.0 series has been characterized by a series of fundamental changes
(const, closures),
 but what really makes a new release great is the polish. Small stuff everybody
looks forward to.
 Clean up the issues with the OMF tools? Maybe even consider switching to PE?
 (Heresy, I know; however, it is fact that GDC has no problem with
megabyte-long symbol names)
 
 Oh, and please, delay the AST macros for a while. My head is still spinning
with closures. :)
  --downs
 
 PS:
   Personal wish list:
     * Struct copy semantics, lazy and ref storage types
     * a way to detect ref in a delegate parameter list
     * Improved compile-time information for enums
     * TRACED EXCEPTIONS ;____; yeah I wish
     * Allow inheriting from superclasses' nested classes
 
 PPS: Representative sentiment from #d:

 <fundesktop> a stable, feature complete compiler without bugs and good
additional tools
 <fundesktop> SOMETHING WHICH D WILL NEVER GET




votes++;

If I could add something to the "small things" wishlist:
A pragma to tell the compiler to inline all occurences of a function and not
generate its body in the object file separately. It could unclutter generated
code from numerous useless proxy or otherwise simple functions that don't do
much, but get generated in flocks for example in template expansion. Could also
be used to prevent functions meant solely for CTFE from ending up in the binary.
Dec 14 2007
parent reply Dan <murpsoft hotmail.com> writes:
Hxal Wrote:


 downs Wrote:
 

 I have an Anti-Big Feature request; that is, a request against new features.
 
 When this const issue will finally be solved to most peoples' satisfaction,
 kindly consider inserting a period of consolidation.
 
 No more sudden, game-changing new super features for a while.
 Maybe fix some long-standing bugs.
 Maybe finally implement the generational GC.
 Maybe actually get DbC inheritance to work like it's supposed to.
 Maybe give memory back to the OS on occasion.
 Maybe revisit some 1.0 concepts and consider if they're still needed.
 Maybe add small things everybody can agree are good (return type deduction
comes to mind).
 Aim for low-hanging fruits, stuff we can agree on for once.
 How about a redundancy free import syntax?
 
 D's 2.0 series has been characterized by a series of fundamental changes
(const, closures),
 but what really makes a new release great is the polish. Small stuff everybody
looks forward to.
 Clean up the issues with the OMF tools? Maybe even consider switching to PE?
 (Heresy, I know; however, it is fact that GDC has no problem with
megabyte-long symbol names)
 
 Oh, and please, delay the AST macros for a while. My head is still spinning
with closures. :)
  --downs
 
 PS:
   Personal wish list:
     * Struct copy semantics, lazy and ref storage types
     * a way to detect ref in a delegate parameter list
     * Improved compile-time information for enums
     * TRACED EXCEPTIONS ;____; yeah I wish
     * Allow inheriting from superclasses' nested classes
 
 PPS: Representative sentiment from #d:

 <fundesktop> a stable, feature complete compiler without bugs and good
additional tools
 <fundesktop> SOMETHING WHICH D WILL NEVER GET




 
 votes++;
 
 If I could add something to the "small things" wishlist:
 A pragma to tell the compiler to inline all occurences of a function and not
generate its body in the object file separately. It could unclutter generated
code from numerous useless proxy or otherwise simple functions that don't do
much, but get generated in flocks for example in template expansion. Could also
be used to prevent functions meant solely for CTFE from ending up in the binary.
 


Yeah, really, "inline" should be a function attribute, never a file attribute,
and it should be used.  That said, I too am pretty tired of major compiler
changes.

At the moment, Walnut cannot compile with DMD 1.21 or later because of some bug
or unmentioned feature implemented in that version.  It has something to do with

struct Value {
  union {
   struct {}
   int i;
   bool b;
   char[] c;
  bla bla.
}

and later doing something with b.  I'd be able to say more, but the error
message is 100% ambiguous and doesn't mention a file or line number.

The exact string I get looks like:

C:\Code\walnut>make
dmd bla bla bla
Error: 'b' is not a member of 'Value'

--- errorlevel 1

Regards,
Dan
Dec 14 2007
parent jcc7 <technocrat7 gmail.com> writes:
== Quote from Dan (murpsoft hotmail.com)'s article

...


 At the moment, Walnut cannot compile with DMD 1.21 or later because of some bug


or unmentioned feature implemented in that version.  It has something to do with

 struct Value {
   union {
    struct {}
    int i;
    bool b;
    char[] c;
   bla bla.
 }
 and later doing something with b.  I'd be able to say more, but the error


message is 100% ambiguous and doesn't mention a file or line number.

I worked on reducing the error to a small example, and I filed a related bug:
http://d.puremagic.com/issues/show_bug.cgi?id=1738

In the process of reducing the error, I guess I lost some of the context for the
error, but I think it seems to be related to the assignment of FALSE in
structure.d:



Note that I'm not defending that DMD rejects your code. My bug report only gives
an example of an error message that should include a line number. I hope this
helps, but it looks like the compiler is malfunctioning in a couple of ways when
it tries to process your code. I only identified one of the malfunctions (lack
of
a line number).


By the way, to come up with the reduced example, I basically used the method
described at:
http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReports



 The exact string I get looks like:
 C:\Code\walnut>make
 dmd bla bla bla
 Error: 'b' is not a member of 'Value'
 --- errorlevel 1
 Regards,
 Dan
Dec 17 2007
prev sibling parent Dan <murpsoft hotmail.com> writes:
jcc7 Wrote:

 I worked on reducing the error to a small example, and I filed a related bug:
 http://d.puremagic.com/issues/show_bug.cgi?id=1738
 
 In the process of reducing the error, I guess I lost some of the context for
the
 error, but I think it seems to be related to the assignment of FALSE in
structure.d:



Sweet, thanks JCC.  : )  I can code okay I think, but I'm really inept when it
comes to managing open source projects.  I haven't filed a bug report before,
and I still have troubles with SVN.

I was ignoring the bug and working on porting to DMD 2.000 (which was released
earlier than 1.020 and doesn't seem to have the bug that prevents compilation)


 
 Note that I'm not defending that DMD rejects your code. My bug report only
gives
 an example of an error message that should include a line number. I hope this
 helps, but it looks like the compiler is malfunctioning in a couple of ways
when
 it tries to process your code. I only identified one of the malfunctions (lack
of
 a line number).


I figured the way I wrote that might strain a few things.  17kb of code only
has 4 semicolons, and Value struct is pretty demanding on a few features.  The
function library also maps most things into phobos so I suppose it's bound to
happen.


 
 By the way, to come up with the reduced example, I basically used the method
 described at:
 http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReports


Thanks.
Dec 17 2007