date:20090320

Denis Koroskin пишет:
 On Thu, 19 Mar 2009 19:54:10 +0300, Weed resume...@mail.ru wrote:
 
 naryl пишет:
 Weed Wrote:
 naryl яПНяПНяПНяПНяПН:
 Weed Wrote:
 BCS яПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПН:
 Yes you can be
 very careful in keeping track of pointers (not practical) or use
 smart
 pointers and such (might end up costing more than GC)
 I am do not agree: GC overexpenditure CPU or memory. Typically, both.
 I wouldn't be so sure about CPU:
 http://shootout.alioth.debian.org/debian/benchmark.php?test=alllang=gdclang2=gppbox=1

 You should not compare benchmarks - they depend on the quality of the
 testing code.

 Then find a way to prove that GC costs more CPU time than explicit
 memory management and/or reference counting.

 I suggest that reference counting for -debug.
 Yes, it slows down a bit. As invariant{}, in{}, out(){}, assert()
 
 Yeah, ref-count your objects in debug and let the memory leak in release!

Not leak - that may be a reference to non-existent object.

The design of invariant{} does not reveal all problems with the class
in all cases which compiled to the release. So that they abandon
invariant{}?

Yes, this language is the same danger as the C++.

Dynamic loading of D modules

2009-03-20 Thread Steve Teale

Is there anyone out there these days working on dynamic loading of D modules in 
D - preferably using Phobos.

Re: new D2.0 + C++ language

Yigal Chripun пишет:
 what you suggest is C++ with better syntax, *NOT* a variant of D. for that 
 look at: 
 http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C%2B%2B_Syntax
 

No! Only because of the value semantic returns used pointers instead
of references for pointing to objects.

 C++ has the wrong semantics which D fixes. No sane person that moved to D 
 would ever want to go back to C++ and its huge pile of issues. C++ implements 
 only very basic mechanisms for OOP and even that is done poorly. 
 
 Also, Your point of view about performance and GC is very much outdated and 
 completely wrong. I will not go into GC implementation details since others 
 did that already. All I'll say is that C++ will eventually get GC too. it was 
 planned to be added in C++0x (the new standard that's planned for 2009) but 
 was postponed because of lack of time and tight deadlines. 
 
 to quote Wikipedia:
 qoute
 Transparent garbage collection
 
 C++0x will not feature transparent garbage collection directly. Instead, the 
 C++0x standard will include features that will make it easier to implement 
 garbage collection in C++.

Only optional

Re: new D2.0 + C++ language

BCS пишет:
 Hello Weed,
 
 BCS ?:

 Reply to Weed,

 If you know the
 best way for language *without GC* guaranteeing the existence of an
 object without overhead - I have to listen!
 Never delete anything?

 One of the arguments for GC is that it might well have /less/
 overhead than any other practical way of managing dynamic memory.

 Mmm
 When I say overhead I mean the cost of executions, and not cost of
 programming
 
 So do I.
 
 I figure unless it save me more times than it costs /all/ the users, run
 time cost trumps.

This is a philosophical dispute.

A good and frequently used code can be written once and then used 10
years in 50 applications in 1 installations. Here, the costs of
programming may be less than the cost of end-user's time and hardware.

 Yes you can be
 very careful in keeping track of pointers (not practical) or use
 smart
 pointers and such (might end up costing more than GC)
 I am do not agree: GC overexpenditure CPU or memory. Typically, both.
 
 ditto naryl on CPU
 
 As for memory, unless the thing overspends into swap and does so very
 quickly (many pages per second) I don't think that matters. This is
 because most of the extra will not be part of the resident set so the OS
 will start paging it out to keep some free pages. This is basically free
 until you have the CPU or HDD locked hard at 100%. The other half is
 that the overhead of reference counting and/or the like will cost in
 memory (you have to store the count somewhere) and might also have bad
 effects regarding cache misses.

Once again I repeat: forget about reference counting - it is only for
the debug purposes. I think this addition should be switchable by
compiler option.

It did not included into the resulting code. Ref-counting needed for
multithreaded programs, when there is a risk to get and use a reference
to an object that another process has already been killed. This
situation needs to be recognized and issued to a run-time error.

This is addition to synchronization of threads, which is realized in D.

Re: new D2.0 + C++ language

Christopher Wright пишет:

 And regarding performance, eventually it will come a lot from a good
 usage of multiprocessing,
 The proposal will be able support multiprocessing - for it provided a
 references counting in the debug version of binaries. If you know the
 best way for language *without GC* guaranteeing the existence of an
 object without overhead - I have to listen!
 You cannot alter the reference count of an immutable variable.
 Why?
 Because it's immutable!

 Unless you're storing a dictionary of objects to reference counts
 somewhere, that is. Which would be hideously slow and a pain to use. Not
 that reference counting is fun.


 Precisely. I wrote the cost for that: 1 dereferencing + inc/dec of
 counter.
 
 It's more expensive than dereferencing. If your const object points to
 its reference count, then the reference count is also const, so you
 can't alter it.

It is designed not so. There will be a hidden dereferencing:

const ref Obj object - struct{ Obj* object;- Obj object;
int counter; };

For all objects will be created such structs. this inside the object
returns ptr to struct. Any appeal by reference to an object would cause
such dereferencing.

Creating reference to object in a code block will cause an increase in
the counter. Destruction of reference will cause an automatic decrease
in the counter.

By the way, upon arrival into the try{} it will save values of reference
counters for the correct exit if exception will be generated.

 
 So the best you can possibly do is one hashtable lookup for every time
 you alter the reference count for a non-mutable variable. That is a huge
 overhead, much more so than garbage collection.

Re: for in D versus C and C++

2009-03-20 Thread Rioshin an'Harthen

Walter Bright newshou...@digitalmars.com kirjoitti viestissä 
news:gpu1sn$sn...@digitalmars.com...

Denis Koroskin wrote:
That was less than a week ago. I'd say that this type of bugs will live 
as long as C++ lives.


The thing is, even if the programmer *intended* to put the ; there, it 
looks like a bug to the maintenance programmer, and he has to spend extra 
effort determining if it was intended or not.


I doubt anyone types { } by accident.


I have a habit of indenting the semicolon on the following line, if I wanted 
a blank statement, like


for (...; ...; ...)
   ;

Much clearer in my opinion than having it on the same line as the for 
construct.

Re: No -c no main()

2009-03-20 Thread Mike Parker


Yigal Chripun wrote:

Mike Parker Wrote:


Yigal Chripun wrote:

On 19/03/2009 12:19, Walter Bright wrote:

It's a good idea. Please add to bugzilla as an enhancement request!
another thing that can be done is provide a compiler flag to specify the 
module that contains main() so the compiler will use that specific main 
and ignore all others. this is similar to how you specify the class with 
main() method in Java. Jar files have a manifest with this info and in 
Eclipse you specify the class in the Run dialog. I don't remember how it 
works with the command line (actually, I don't remember ever using the 
command line with Java)
It's not something that happens at compile time. All existing main 
methods are compiled into their respective class files. From the command 
line, you execute the JRE (java or javaw in Sun's case) and pass it the 
name of the class you want to execute. If the class has a main method, 
it is called. If not, you get an error.


Java's model is complicated. it has the concept of class-loaders. 
What I'm suggesting is this: 
given three modules a,b and c all defining the main() function, you can do the following:
dmd a.d b.d c.d --main=b.d 
currently the compiler will complain about multiple definitions of main(), but with the above flag, it could skip over the main() functions in a and c. 


the next logical step would be to allow:
dmd -c a.d
dmd -c b.d 
dmd -c c.d

dmd a.obj b.obj c.obj --main=b.obj

in the above all three obj files have a main() method. this time it must be the *linker* that needs to understand the flag and only link the main() function into the executable. this requires changing the linker which is written in asm so less likely to happen. 


I was not suggesting D to use a VM or the class-loader concept as in Java. even 
if we want that concept in D it needs to have a different implementation than 
in Java since there are problems with the way Java does this. (that's besides 
the differences due to the JVM)


I understand what you were suggesting. My point is that in Java, which 
entry point to use is decided at run time, not compile time. From that 
perspective, it's a useful feature. For a statically compiled language 
like D, I don't see any obvious benefit. I mean, what is the benefit of 
this over delegating to a specific pseudo-main method based on a 
commandline arg or config file?

Re: No -c no main()

2009-03-20 Thread Ary Borenszweig


Mike Parker escribió:

Yigal Chripun wrote:

Mike Parker Wrote:


Yigal Chripun wrote:

On 19/03/2009 12:19, Walter Bright wrote:

It's a good idea. Please add to bugzilla as an enhancement request!
another thing that can be done is provide a compiler flag to specify 
the module that contains main() so the compiler will use that 
specific main and ignore all others. this is similar to how you 
specify the class with main() method in Java. Jar files have a 
manifest with this info and in Eclipse you specify the class in the 
Run dialog. I don't remember how it works with the command line 
(actually, I don't remember ever using the command line with Java)
It's not something that happens at compile time. All existing main 
methods are compiled into their respective class files. From the 
command line, you execute the JRE (java or javaw in Sun's case) and 
pass it the name of the class you want to execute. If the class has a 
main method, it is called. If not, you get an error.


Java's model is complicated. it has the concept of class-loaders. What 
I'm suggesting is this: given three modules a,b and c all defining the 
main() function, you can do the following:
dmd a.d b.d c.d --main=b.d currently the compiler will complain about 
multiple definitions of main(), but with the above flag, it could skip 
over the main() functions in a and c.

the next logical step would be to allow:
dmd -c a.d
dmd -c b.d dmd -c c.d
dmd a.obj b.obj c.obj --main=b.obj

in the above all three obj files have a main() method. this time it 
must be the *linker* that needs to understand the flag and only link 
the main() function into the executable. this requires changing the 
linker which is written in asm so less likely to happen.
I was not suggesting D to use a VM or the class-loader concept as in 
Java. even if we want that concept in D it needs to have a different 
implementation than in Java since there are problems with the way Java 
does this. (that's besides the differences due to the JVM)


I understand what you were suggesting. My point is that in Java, which 
entry point to use is decided at run time, not compile time. From that 
perspective, it's a useful feature. For a statically compiled language 
like D, I don't see any obvious benefit. I mean, what is the benefit of 
this over delegating to a specific pseudo-main method based on a 
commandline arg or config file?


It is useful. Suppose you are writing a new module and want to test 
something quickly (not with unittests, maybe make a little program to 
see how a specific feature you just wrote works). So you write a main 
right there in the module, compile it and link it saying that the main 
is in your new module. And you can then run it.


If you couldn't do that you'd have to search for your only main in your 
project, change it by adding the necessary imports, compile it and run 
it. Way more steps.


Also, that way each module can have a main method that shows some of 
it's funcionality with a little program.

Re: new D2.0 + C++ language


Weed wrote:

Christopher Wright пишет:

Weed wrote:

+ Sometimes allocation and freeing of memory in an arbitrary
unpredictable time  unacceptable. (in game development or realtime
software, for example. One hundred million times discussed about it
there, I guess)

So you are optimizing for the uncommon case?


GC is an attempt of optimizing for the uncommon case )


I don't think so. Programmers have more important things to do than 
write memory management systems. My boss would not be happy if I 
produced an application that leaked memory at a prodigious rate, and he 
would not be happy if I spent much time at all on memory management.


With the application I develop at work, we cache some things. These 
would have to be reference counted or deleted and recomputed every time. 
Reference counting is a lot of tedious developer effort. Recomputing is 
rather expensive. Deleting requires tedious developer effort and 
determining ownership of everything. This costs time and solves no 
problems for the customers.


And the best manual memory management that I am likely to write would 
not be faster than a good garbage collector.


What sort of applications do you develop? Have you used a garbage 
collector in a large application?

Re: new D2.0 + C++ language


Weed wrote:

Christopher Wright пишет:

It's more expensive than dereferencing. If your const object points to
its reference count, then the reference count is also const, so you
can't alter it.


It is designed not so. There will be a hidden dereferencing:

const ref Obj object - struct{ Obj* object;- Obj object;
int counter; };


Okay, a language level feature, or a wrapper struct. That would work. If 
it's a library level feature, there's a problem of usage.

Re: new D2.0 + C++ language

2009-03-20 Thread Simen Kjaeraas


Weed resume...@mail.ru wrote:


Simen Kjaeraas Ð¿Ð¸ÑˆÐµÑ‚:

Weed resume...@mail.ru wrote:


I think the point you're trying to make is that a GC is more memory
intensive.


+ Sometimes allocation and freeing of memory in an arbitrary
unpredictable time  unacceptable. (in game development or realtime
software, for example. One hundred million times discussed about it
there, I guess)


Then use the stub GC or disable the GC, then re-enable it when
you have the time to run a sweep (yes, you can).



Then a memory overrun


If so, you have allocated a lot of things you shouldn't have, or otherwise
would have the same problem using manual allocation.


A need language that does not contain a GC (or contains optional). Many
C++ programmers do not affect the D only because of this.


While GC in D is not optional, it can be stubbed out or disabled,


Then some part of the language will stop working (dynamic arrays, and
possibly delegates)


Yes. So don't use those parts, or disable the GC and enable it
when you have the time.

Re: eliminate writeln et comp?

2009-03-20 Thread Don


Robert Jacques wrote:

On Thu, 19 Mar 2009 09:23:44 -0400, Don nos...@nospam.com wrote:
I agree, requiring to include copyright with every binary distribution 
is unacceptable for a standard library. But...
Tango is also available under the Academic Free License. Which I don't 
understand, despite having read through the ten page explanation of it.
Specifically, you're allow to change it to any license of your choice 
that does not contradict the terms and conditions, including 
Licensor's reserved rights and remedies, in this Academic Free  
License;
But what does that mean? Which licenses does it include? Does it 
include the zlib license? I presume not.
In which case Andrei and Walter's position is entirely justified. If 
that is correct, I will cease contributing to Tango.

Someone, _please_ tell me I'm wrong.


No, sadly you're right. According to wikipedia, the AFL is not GPL 
compatible. If AFL could be converted to zlib then you could convert ALF 
source to zlib and it would then be GPL compatible. Q.E.D. Hence, ALF 
can not be convert to zlib.


So far the only other licence I saw without the binary-licence 
distribution problem is the Boost Software License (BSL1.0) (And of 
course the WTFYW licence) And I'm guessing this issue is why they wrote 
a new licence instead of reusing an old one.


The zlib license also doesn't have the binary distribution problem.

The Boost license looks pretty good to me, and they seem to have used 
better legal consultation than the zlib license. I also like the fact 
that it only occupies 3 lines of source code -- that's much better than 
zlib.


Boost, zlib, WTFYW, and public domain, seem to be the only ones which 
are suitable for a standard library.


Actually, some of the BSD/MIT like licences might be valid if you 
included the licence string as a constant in the binary distribution 
(although this is definitely not in the spirit of the licence)

Re: Dynamic loading of D modules

2009-03-20 Thread Sergey Gromov

Fri, 20 Mar 2009 05:53:18 -0400, Steve Teale wrote:

 Is there anyone out there these days working on dynamic loading of D modules 
 in D - preferably using Phobos.

DDL?

http://dsource.org/projects/ddl

Re: The Joy of Signalling NaNs! (A compiler patch)


Great work Don!
Fawzi

On 2009-03-19 05:58:40 +0100, Don nos...@nospam.com said:

It's great that D initializes floating-point variables to NaN, instead 
of whatever random garbage happened to be in RAM.
But, if your calculation ends up with a NaN, you have to work out where 
it came from. Worse, the NaN might not necessarily

be visible in your final results, but you results may nonetheless be wrong.

The hardware has excellent support for debugging these problems -- all 
you need to do is activitating the floating-point 'invalid' trap,
and you'll get a hardware exception whenever you _create_ a NaN. What 
about uninitialized variables?
Signalling NaNs are designed for exactly this situation. The instant 
you access a signalling NaN, a hardware exception occurs,

and you drop straight into your debugger (just like accessing a null pointer).
But this could only work if the compiler initialized every 
uninitialised floating-point variable to a signalling NaN.


Now that we have access to the backend (thanks Walter!), we can do 
exactly that. My patch(below) is enabled only when compiled with DMC.
real.nan is unchanged, and won't cause exceptions if you use it, but 
real.init is now a signalling nan.

This doesn't make any difference to anything, until you enable FP exceptions.
And when you do, if no exceptions occur, you can use the code coverage 
feature to give very high confidence that you're not using any 
uninitialised floating-point variables.


I propose that this should become part of DMD. It doesn't need to be in 
the spec, it's primarily for debugging.


Don.

==
Example of usage:
==

void main()
{
 double a, b, c;
 a*=7;// Exactly the same as it is now, a is nan.

 enableExceptions();

 c = 6;  // ok, c is initialized now
 c *= 10;
 b *= 10;// BANG ! Straight into the debugger
 b *= 5;

 disableExceptions();
}

---

void enableExceptions() {
 version(D_InlineAsm_X86) {
  short cont;
  asm {
  fclex;
  fstcw cont;
  mov AX, cont;
  and AX, 0xFFFE; // enable invalid exception
  mov cont, AX;
  fldcw cont;
  }
  }
  }

void disableExceptions() {
 version(D_InlineAsm_X86) {
  short cont;
  asm {
  fclex;
  fstcw cont;
  mov AX, cont;
  or AX, 0x1; // disable invalid exception
  mov cont, AX;
  fldcw cont;
  }
  }
  }


=
Patches to DMD to turn all unitialized floats into SNANs.

Changes are in mytype.c and e2ir.c
=
mytype.c:
=
line 2150:

Expression *TypeBasic::defaultInit(Loc loc)
{   integer_t value = 0;
#if __DMC__
// Note: could be up to 16 bytes long.
unsigned short snan[8] = { 0x, 0x, 0x, 0xBFFF, 0x7FFF, 0, 
0, 0 };
d_float80 fvalue = *(long double*)snan;
#endif

line 2177:

case Tfloat80:
#if __DMC__
return new RealExp(loc, fvalue, this);
#else
return getProperty(loc, Id::nan);
#endif

line 2186:

case Tcomplex80:
#if __DMC__
{   // Can't use fvalue + I*fvalue (the im part becomes a quiet 
NaN).
complex_t cvalue;
((real_t *)cvalue)[0] = fvalue;
((real_t *)cvalue)[1] = fvalue;
return new ComplexExp(loc, cvalue, this);
}
#else
return getProperty(loc, Id::nan);
#endif
=
e2ir.c line 1182.
=

bool isSignallingNaN(real_t x)
{
#if __DMC__
if (x=0 || x0) return false;
return !unsigned short*)x)[3])0x4000);
#else
return false;
#endif
}


elem *RealExp::toElem(IRState *irs)
{   union eve c;
 tym_t ty;

 //printf(RealExp::toElem(%p)\n, this);
 memset(c, 0, sizeof(c));
 ty = type-toBasetype()-totym();
 switch (tybasic(ty))
 {
case TYfloat:
case TYifloat:
c.Vfloat = value;
if (isSignallingNaN(value) ) {
((unsigned int*)c.Vfloat)[0] = 0xFFBFL;
}
break;

case TYdouble:
case TYidouble:
c.Vdouble = value; // this unfortunately converts SNAN to QNAN.
if ( isSignallingNaN(value) ) {
((unsigned int*)c.Vdouble)[1] = 0xFFF7L;
}
break;

case TYldouble:
case TYildouble:
c.Vldouble = value;
break;

default:
print();
type-print();
type-toBasetype()-print();
printf(ty = %d, tym = %x\n, type-ty, ty);
assert(0);
 }
 return el_const(ty, c);
}

elem *ComplexExp::toElem(IRState *irs)
{   union eve c;

Re: new D2.0 + C++ language

Christopher Wright пишет:
 Weed wrote:
 + Sometimes allocation and freeing of memory in an arbitrary
 unpredictable time  unacceptable. (in game development or realtime
 software, for example. One hundred million times discussed about it
 there, I guess)
 
 So you are optimizing for the uncommon case?

GC is an attempt of optimizing for the uncommon case )

Re: No -c no main()

2009-03-20 Thread bearophile

Ary Borenszweig:
 It is useful. Suppose you are writing a new module and want to test 
 something quickly (not with unittests, maybe make a little program to 
 see how a specific feature you just wrote works). So you write a main 
 right there in the module, compile it and link it saying that the main 
 is in your new module. And you can then run it.

It has many usages, we have already discussed about this in the past.
In D you can group related functions and classes into one module, so sometimes 
a module can be run alone (with the help of some modules it imports). So you 
can add demonstration code into its main, or benchmark/testing code, or module 
testing code, and so on. You can even create a program where certain modules 
can be sub-programs, that you can run alone to do specific sub-purposes, 
instead of using them as imported modules.
Such usages are very common in Python too, there's even a idiomatic syntax to 
do such things. In the past other people and me have suggested some ways to do 
this.
One of them was to add a __MAIN__ compile time constant defined as false for 
all the modules that the compiler is asked to not compile as the (main) module 
that contains the main(), so you can use a:
static if (__MAIN__) { void main(string[] args) {...} }
to wrap the main function. I don't remember if this very simple idea was 
already shot down or improved by better ideas.

Bye,
bearophile

Re: eliminate writeln et comp?


On 2009-03-20 05:46:08 +0100, Robert Jacques sandf...@jhu.edu said:


On Thu, 19 Mar 2009 09:23:44 -0400, Don nos...@nospam.com wrote:
I agree, requiring to include copyright with every binary distribution  
is unacceptable for a standard library. But...
Tango is also available under the Academic Free License. Which I don't  
understand, despite having read through the ten page explanation of it.
Specifically, you're allow to change it to any license of your choice  
that does not contradict the terms and conditions, including Licensor's 
 reserved rights and remedies, in this Academic Free  License;
But what does that mean? Which licenses does it include? Does it 
include  the zlib license? I presume not.
In which case Andrei and Walter's position is entirely justified. If  
that is correct, I will cease contributing to Tango.

Someone, _please_ tell me I'm wrong.


No, sadly you're right. According to wikipedia, the AFL is not GPL  
compatible. If AFL could be converted to zlib then you could convert 
ALF  source to zlib and it would then be GPL compatible. Q.E.D. Hence, 
ALF can  not be convert to zlib.


yes as far as I understand the problem with AFL is that it has a kind 
of viral component like GPL, in that derivative work need to have a 
compatible license, and redistribution should ensure that the license 
is preserved, zlib does not have that.


I don't think it is wrong, but I would be happy also with zlib...

Fawzi

So far the only other licence I saw without the binary-licence  
distribution problem is the Boost Software License (BSL1.0) (And of 
course  the WTFYW licence) And I'm guessing this issue is why they 
wrote a new  licence instead of reusing an old one.


Actually, some of the BSD/MIT like licences might be valid if you 
included  the licence string as a constant in the binary distribution 
(although this  is definitely not in the spirit of the licence)

Re: No -c no main()

2009-03-20 Thread Yigal Chripun


On 20/03/2009 13:11, Mike Parker wrote:

I understand what you were suggesting. My point is that in Java, which
entry point to use is decided at run time, not compile time. From that
perspective, it's a useful feature. For a statically compiled language
like D, I don't see any obvious benefit. I mean, what is the benefit of
this over delegating to a specific pseudo-main method based on a
commandline arg or config file?


to add to what Ary and bearophile already said, that can be even more 
useful if it's combined with D's unittesting features. for example the 
main() could specify what unit-tests to run and in what order, provide 
the before  after code, etc..

Re: eliminate writeln et comp?


On 2009-03-20 13:28:06 +0100, Don nos...@nospam.com said:


Robert Jacques wrote:

On Thu, 19 Mar 2009 09:23:44 -0400, Don nos...@nospam.com wrote:
I agree, requiring to include copyright with every binary distribution 
is unacceptable for a standard library. But...
Tango is also available under the Academic Free License. Which I don't 
understand, despite having read through the ten page explanation of it.
Specifically, you're allow to change it to any license of your choice 
that does not contradict the terms and conditions, including Licensor's 
reserved rights and remedies, in this Academic Free  License;
But what does that mean? Which licenses does it include? Does it 
include the zlib license? I presume not.


I read more carefully and tried to understand it better,  I had not 
understood the problem that makes it incompatible with GPL, the thing 
is that it puts extra restrictions that limit the responsibility of the 
licenser, in particular has provisions for revoking the patent granted 
to the licensee should he choose to make a patent claim about the 
original work.


Which is reasonable, but an extra restriction, and thus incompatible with GPL

In which case Andrei and Walter's position is entirely justified. If 
that is correct, I will cease contributing to Tango.

Someone, _please_ tell me I'm wrong.


No, sadly you're right. According to wikipedia, the AFL is not GPL 
compatible. If AFL could be converted to zlib then you could convert 
ALF source to zlib and it would then be GPL compatible. Q.E.D. Hence, 
ALF can not be convert to zlib.


So far the only other licence I saw without the binary-licence 
distribution problem is the Boost Software License (BSL1.0) (And of 
course the WTFYW licence) And I'm guessing this issue is why they wrote 
a new licence instead of reusing an old one.


The zlib license also doesn't have the binary distribution problem.
The Boost license looks pretty good to me, and they seem to have used 
better legal consultation than the zlib license. I also like the fact 
that it only occupies 3 lines of source code -- that's much better than 
zlib.


Boost, zlib, WTFYW, and public domain, seem to be the only ones which 
are suitable for a standard library.


I agree that these a good licenses for a standard library.

Re: Proposal: adding condition variable to object monitors

2009-03-20 Thread Sean Kelly


Graham St Jack wrote:

class C
{
 Mutex m;
 Condition c;

 this()
 {
 // make m this object's monitor
 m = new Mutex( this );
 c = new Condition( m );
 }

 synchronized void foo()
 {
 // m is locked
 c.notify();
 }
}


I like this approach, and agree that it is very useful to be able to have 
more than one condition share the same mutex.


I don't mind the handraulic creation of the mutex and condition when you 
are using a condition, because of the added flexibility and the fact that 
it doesn't come up much.


Being able to use the Object's monitor for the mutex is really good too.

Please release it soon!


It was meant to be in the last D2 release and something happened with 
the script that assembles the zipfile.  I'll make double sure it's in 
this release.

opImplicitCast

2009-03-20 Thread dsimcha

Is opImplicitCast (and fixing opCast) anywhere in the pipeline?  It seems like
every time I want to create an interesting library type, lack of
opImplicitCast prevents me from making its API nice enough to be worth doing.
 In some cases, alias this, which has been proposed,  isn't enough.

I've wanted an ArrayBuilder (with a capacity field) that can be implicitly
converted to a regular array for the longest time.  The latest thing I want to
do is write fixed point number structs for efficiently representing numbers in
a narrowly defined range.  I often need to store, for example, huge amounts of
real numbers between 0 and 1.  Space efficiency is important, very high
precision isn't.  The obvious answer would be to use a ubyte or a ushort to
represent it, with 0 representing 0 and ubyte.max or ushort.max representing
1.  I can't do this in a well-encapsulated, elegant way because so much
functionality (both standard and homegrown math libs) assumes that numeric
types are implicitly convertible to real, double, float, etc.

IMHO, now that we have ref returns, etc., lack of user-defined implicit
casting rules is one of the few things preventing user-defined types in D from
really being able to behave as if they were first-class types.  Does anyone
else have some good real-world use cases for opImplicitCast, so we can start
seriously considering how it should work?

Re: new D2.0 + C++ language

Simen Kjaeraas пишет:
 Weed resume...@mail.ru wrote:
 
 Simen Kjaeraas Ð¿Ð¸ÑˆÐµÑ‚:
 Weed resume...@mail.ru wrote:

 I think the point you're trying to make is that a GC is more memory
 intensive.

 + Sometimes allocation and freeing of memory in an arbitrary
 unpredictable time  unacceptable. (in game development or realtime
 software, for example. One hundred million times discussed about it
 there, I guess)

 Then use the stub GC or disable the GC, then re-enable it when
 you have the time to run a sweep (yes, you can).

 
 Then a memory overrun
 
 If so, you have allocated a lot of things you shouldn't have, or otherwise
 would have the same problem using manual allocation.

No, as far as I know that some pieces of language does not imply a
manual release memory. (See below)

 A need language that does not contain a GC (or contains optional). Many
 C++ programmers do not affect the D only because of this.

 While GC in D is not optional, it can be stubbed out or disabled,

 Then some part of the language will stop working (dynamic arrays, and
 possibly delegates)
 
 Yes. So don't use those parts,

It is not impossible without blocking at the compiler level (by CLI
option) in the real world.

 or disable the GC and enable it
 when you have the time.

Again, the memory will be overrun)

Re: new D2.0 + C++ language


Reply to Weed,



It is designed not so. There will be a hidden dereferencing:

const ref Obj object - struct{ Obj* object;- Obj object;
int counter; };


Who deletes those structs and when?

Re: new D2.0 + C++ language


Reply to Weed,


Simen Kjaeraas ?:


Weed resume...@mail.ru wrote:


I think the point you're trying to make is that a GC is more memory
intensive.


+ Sometimes allocation and freeing of memory in an arbitrary
unpredictable time  unacceptable. (in game development or realtime
software, for example. One hundred million times discussed about it
there, I guess)


Then use the stub GC or disable the GC, then re-enable it when you
have the time to run a sweep (yes, you can).


Then a memory overrun



I can't think of a case where having the GC running would be a problem where 
allocating memory at all would not (malloc/new/most any allocator is NOT 
cheap)

Re: new D2.0 + C++ language

Christopher Wright пишет:

 + Sometimes allocation and freeing of memory in an arbitrary
 unpredictable time  unacceptable. (in game development or realtime
 software, for example. One hundred million times discussed about it
 there, I guess)
 So you are optimizing for the uncommon case?

 GC is an attempt of optimizing for the uncommon case )
 
 I don't think so. Programmers have more important things to do than
 write memory management systems. My boss would not be happy if I
 produced an application that leaked memory at a prodigious rate, and he
 would not be happy if I spent much time at all on memory management.
 

You should use language with GC in this case.

 With the application I develop at work, we cache some things. These
 would have to be reference counted or deleted and recomputed every time.
 Reference counting is a lot of tedious developer effort. Recomputing is
 rather expensive. Deleting requires tedious developer effort and
 determining ownership of everything. This costs time and solves no
 problems for the customers.

I do not agree. I am quite easy to give tracking the creation and
deletion of the objects on the stack and on the heap. I do not see
problem there. Although there is an alternative - C++, but not D.

And you do not need to do reference counting for all the objects in the
program. Normally, objects in need not so much as objects do not need.
(Therefore, I propose to extend the stack usage for storing and passing
objects.)

Unfortunately, not yet thought of another way to memory management

 
 And the best manual memory management that I am likely to write would
 not be faster than a good garbage collector.
 
 What sort of applications do you develop?

games, images processing

 Have you used a garbage
 collector in a large application?

I do not write really large applications

Re: new D2.0 + C++ language


Reply to Weed,


Simen Kjaeraas ?:


or disable the GC and enable it
when you have the time.


Again, the memory will be overrun)



Are you saying that you have a program with a time critical section that 
allocates 100s of MB of memory? If so, you have other problems to fix. If 
that is not the case, then disable the GC run your critical/RT section allocating 
a few kB/MB and when you exit that section re enable the GC and clean up. 
This won't create a memory overrun unless you allocate huge amounts of memory 
or forget to re enable the GC.


Short version: The only places I can think of where having the GC run would 
cause problems are can't be allowed to run for very long or allocate hardly 
ram at all. To argue this point you will have to give a specific use case.

Re: new D2.0 + C++ language


Reply to Weed,


BCS ?:


Hello Weed,



Mmm
When I say overhead I mean the cost of executions, and not cost of
programming

So do I.

I figure unless it save me more times than it costs /all/ the users,
run time cost trumps.


This is a philosophical dispute.

A good and frequently used code can be written once and then used 10
years in 50 applications in 1 installations. Here, the costs of
programming may be less than the cost of end-user's time and hardware.



You are agreeing with me.



As for memory, unless the thing overspends into swap and does so very
quickly (many pages per second) I don't think that matters. This is
because most of the extra will not be part of the resident set so the
OS will start paging it out to keep some free pages. This is
basically free until you have the CPU or HDD locked hard at 100%. The
other half is that the overhead of reference counting and/or the like
will cost in memory (you have to store the count somewhere) and might
also have bad effects regarding cache misses.



Once again I repeat: forget about reference counting - it is only for
the debug purposes. I think this addition should be switchable by
compiler option.

It did not included into the resulting code. Ref-counting needed for
multithreaded programs, when there is a risk to get and use a
reference to an object that another process has already been killed.
This situation needs to be recognized and issued to a run-time error.


As I understand the concept reference counting is a form of GC. It has 
nothing to do with threading. The point is to keep track of how many references, 
in any thread, there are to a dynamic resource and to free it when there 
are no more. Normally (as in if you are not doing things wrong) you never 
release/free/delete a reference counted resource so it doesn't even check 
if it is delete. Also because the count is attached to the referenced resource, 
it can't do that check because the count is deleted right along with it.


For that concept (the only meaning of the term reference counting I known 
of) the idea of turning it off for non-debug builds is silly. Are you referring 
to something else?

Re: eliminate writeln et comp?


after some extra digging

tango licensing:

BSD (and this is the revised 3 clause BSD)
- is compatible with GPL
- copyright need to be advertised also in the documentation and binary

a commonly used permissive license (which probably you are using when 
linking for example network code in almost any operating system).

It does *not* include the original fourth statement of BSD

APL
- similar to BSD, but with some extra protections against the liability 
of the licenser, in particular with respect to patents

- these extra restrictions make it incompatible with GPLv2
- it should be equivalent to apache 2.0 ( 
http://www.opensource.org/proliferation-report )

and so it might be compatible with GPLv3 but I am not 100% sure on this.

In any case the double licensing of tango allows one to use it also 
with GPL code


Fawzi

Re: No -c no main()

2009-03-20 Thread Steve Teale

  dmd -c a.d
  dmd -c b.d 
  dmd -c c.d
  dmd a.obj b.obj c.obj --main=b.obj
  
  in the above all three obj files have a main() method. this time it must be 
  the *linker* that needs to understand the flag and only link the main() 
  function into the executable. this requires changing the linker which is 
  written in asm so less likely to happen. 
  
  I was not suggesting D to use a VM or the class-loader concept as in Java. 
  even if we want that concept in D it needs to have a different 
  implementation than in Java since there are problems with the way Java does 
  this. (that's besides the differences due to the JVM)
 
 I understand what you were suggesting. My point is that in Java, which 
 entry point to use is decided at run time, not compile time. From that 
 perspective, it's a useful feature. For a statically compiled language 
 like D, I don't see any obvious benefit. I mean, what is the benefit of 
 this over delegating to a specific pseudo-main method based on a 
 commandline arg or config file?
 
I just asked what I thought was a very simple question. It was not intended to 
be the stimulus for vast changes! This newsgroup could do with some moderation. 
Wandering off the original topic is normal, not just common! All should bear in 
mind that unless this is just intellectual wanking we need to get this language 
stabilized.

Then others might start to take it seriously.

Re: new D2.0 + C++ language

BCS пишет:

 I figure unless it save me more times than it costs /all/ the users,
 run time cost trumps.

 This is a philosophical dispute.

 A good and frequently used code can be written once and then used 10
 years in 50 applications in 1 installations. Here, the costs of
 programming may be less than the cost of end-user's time and hardware.

 
 You are agreeing with me.
 

 As for memory, unless the thing overspends into swap and does so very
 quickly (many pages per second) I don't think that matters. This is
 because most of the extra will not be part of the resident set so the
 OS will start paging it out to keep some free pages. This is
 basically free until you have the CPU or HDD locked hard at 100%. The
 other half is that the overhead of reference counting and/or the like
 will cost in memory (you have to store the count somewhere) and might
 also have bad effects regarding cache misses.


 Once again I repeat: forget about reference counting - it is only for
 the debug purposes. I think this addition should be switchable by
 compiler option.

 It did not included into the resulting code. Ref-counting needed for
 multithreaded programs, when there is a risk to get and use a
 reference to an object that another process has already been killed.
 This situation needs to be recognized and issued to a run-time error.
 
 As I understand the concept reference counting is a form of GC.

In the proposed language is a way to learn mistake - deleting object in
another thread that still have a reference.

In other words, it is a way to provide proof that the reference refers
to an object rather than the emptiness or garbage.


 It has
 nothing to do with threading. The point is to keep track of how many
 references, in any thread, there are to a dynamic resource and to free
 it when there are no more. Normally (as in if you are not doing things
 wrong) you never release/free/delete a reference counted resource so it
 doesn't even check if it is delete. Also because the count is attached
 to the referenced resource, it can't do that check because the count is
 deleted right along with it.
 
 For that concept (the only meaning of the term reference counting I
 known of) the idea of turning it off for non-debug builds is silly. Are
 you referring to something else?

Library for Linear Algebra?

2009-03-20 Thread Trass3r


Is there any working library for Linear Algebra?
I only found BLADE, which seems to be abandoned and quite unfinished, 
and Helix which only provides 3x3 and 4x4 matrices used in games :(

Re:[OT] No -c no main()


Reply to Steve,


I just asked what I thought was a very simple question. It was not
intended to be the stimulus for vast changes! This newsgroup could do
with some moderation. Wandering off the original topic is normal, not
just common!



The the interesting threads are the OT ones. Particularly the OT regarding 
the subject line but still in CS.


This comes from the point that if some thing was on topic and interesting, 
I would have already looked into it. So the interesting things I don't know 
about are general OT.

Re: for in D versus C and C++

2009-03-20 Thread Walter Bright


Rioshin an'Harthen wrote:
Walter Bright newshou...@digitalmars.com kirjoitti viestissä 

I doubt anyone types { } by accident.


I have a habit of indenting the semicolon on the following line, if I 
wanted a blank statement, like


for (...; ...; ...)
   ;

Much clearer in my opinion than having it on the same line as the for 
construct.


Yes, that's ok, too. The only issue with it as far as working it into 
the language goes is then the parser and lexer do not have a clean 
separation - whitespace has meaning in one case.

Re: Library for Linear Algebra?


Reply to Trass3r,


Is there any working library for Linear Algebra?
I only found BLADE, which seems to be abandoned and quite unfinished,
and Helix which only provides 3x3 and 4x4 matrices used in games :(



I havent used them but:

http://www.dsource.org/projects/mathextra
http://www.dsource.org/projects/lyla

if either works well for you, please comment in it.

Re: new D2.0 + C++ language


Reply to Weed,


BCS пишет:


As I understand the concept reference counting is a form of GC.


In the proposed language is a way to learn mistake - deleting object
in another thread that still have a reference.

In other words, it is a way to provide proof that the reference refers
to an object rather than the emptiness or garbage.



OK, than quit calling it reference counting because everyone will think of 
something else when you call it that. 

Also, what you are proposing would not be specific to threads. The problem 
of deleting stuff early is just as much a problem and looks exactly the same 
in non threaded code.

Re: Library for Linear Algebra?

2009-03-20 Thread Trass3r


BCS schrieb:

http://www.dsource.org/projects/mathextra


This project contains BLADE, I didn't test it myself cause the author 
stated on Wed Oct 17, 2007 that there are still some fairly large 
issues to work out and there haven't been any updates to it since May 2008.



http://www.dsource.org/projects/lyla


This seems to be something I should look further into. Though it is 
abandoned as well :(



That's a real pity, having a good scientific computation library is 
crucial for D being used at universities.
You know, Matlab is fine for writing clean, intuitive code, but when it 
comes to real performance requirements it totally sucks (damn Java ;) )

Re: Library for Linear Algebra?

2009-03-20 Thread Bill Baxter

On Sat, Mar 21, 2009 at 3:38 AM, Trass3r mrmoc...@gmx.de wrote:
 Is there any working library for Linear Algebra?
 I only found BLADE, which seems to be abandoned and quite unfinished, and
 Helix which only provides 3x3 and 4x4 matrices used in games :(


For D1 try Gobo and Dflat.  Gobo has a bunch of wrappers for Fortran
libraries.  Dflat is a higher level matrix/sparse matrix interface.

Works with Tango using Tangobos.

See:
http://www.dsource.org/projects/multiarray

--bb

Re: for in D versus C and C++

2009-03-20 Thread Walter Bright


Sean Kelly wrote:

Sounds like HTTP/HTML.  The best I've come up with so far for parsing
that stuff is to have the lexer actually return tokens representing whitespace
in some instances.  It's totally ridiculous.


When you see ad-hoc designs like that, it's obvious the designer has no 
experience with compilers. It's why every programmer should take a basic 
course in compiler design g.

Response files

2009-03-20 Thread Frank Benoit

DMD 1.041 on windows does support response files, that is a file
containing arguments.
On Linux dmd does not understand that. Instead a build mechanism needs
to handle dmd in a special way on linux.
cat rsp | xargs dmd

Would be nice, if both can be used in the same way.

Re: for in D versus C and C++

2009-03-20 Thread Sean Kelly

== Quote from Walter Bright (newshou...@digitalmars.com)'s article
 Sean Kelly wrote:
  Sounds like HTTP/HTML.  The best I've come up with so far for parsing
  that stuff is to have the lexer actually return tokens representing 
  whitespace
  in some instances.  It's totally ridiculous.
 When you see ad-hoc designs like that, it's obvious the designer has no
 experience with compilers. It's why every programmer should take a basic
 course in compiler design g.

I very much agree.  In fact, I'd go so far as to say that my compiler design
course was the single most valuable CS course I took while in college.  It's
amazing how many problems I encounter have something to do with parsing
or language translation.  It's also amazing how many crappy parsers there
are out there for these same tasks.  Clearly, compiler design doesn't get
as much attention as it should in undergrad CS.

Re: new D2.0 + C++ language


Weed wrote:

Christopher Wright пишет:

What sort of applications do you develop?


games, images processing


Libraries will often have no need for data structures with complex 
lifestyles. There are exceptions, of course, but that's what I have 
generally found to be the case. For the bulk of image processing, you 
can just throw the memory management problem to the end user.


Games have strict performance requirements that a stop-the-world type of 
garbage collector violates. Specifically, a full collection would cause 
an undue delay of hundreds of milliseconds on occasion. If this happens 
once every ten seconds, your game has performance problems. This is not 
true of pretty much any other type of application.


Games usually have scripting languages that might make use of a garbage 
collector, though. And there is research into realtime garbage 
collectors that would be suitable for use in games.

Re: No -c no main()


Ary Borenszweig wrote:
It is useful. Suppose you are writing a new module and want to test 
something quickly (not with unittests, maybe make a little program to 
see how a specific feature you just wrote works).


Why aren't you writing a unittest?

Well, you might only want to run the current module's tests, though in 
that case, you can compile the one module with -unittest and omit that 
for the others.

Re: eliminate writeln et comp?

2009-03-20 Thread Daniel Keep



Fawzi Mohamed wrote:
 after some extra digging
 
 tango licensing:
 
 BSD (and this is the revised 3 clause BSD)
 - is compatible with GPL
 - copyright need to be advertised also in the documentation and binary
 
 a commonly used permissive license (which probably you are using when
 linking for example network code in almost any operating system).
 It does *not* include the original fourth statement of BSD
 
 APL
 - similar to BSD, but with some extra protections against the liability
 of the licenser, in particular with respect to patents
 - these extra restrictions make it incompatible with GPLv2
 - it should be equivalent to apache 2.0 (
 http://www.opensource.org/proliferation-report )
 and so it might be compatible with GPLv3 but I am not 100% sure on this.
 
 In any case the double licensing of tango allows one to use it also with
 GPL code
 
 Fawzi
 

When was the last time you had to put this in your GCC-compiled programs?

Portions of this program Copyright (C) Free Software Foundation.  Uses
glibc.

For a regular library, binary attribution clauses are OK.  For a
standard library, it's distasteful [1].  I shouldn't HAVE to worry about
legal issues from compiling Hello World.

  -- Daniel

[1] I've contributed code to Tango under BSD.  If I'd have known about
this issue, I would have made it Public Domain or a license without the
binary attribution clause.

Re: No -c no main()

2009-03-20 Thread Mike Parker


Steve Teale wrote:


I just asked what I thought was a very simple question. It was not intended to 
be the stimulus for vast changes! This newsgroup could do with some moderation. 
Wandering off the original topic is normal, not just common! All should bear in 
mind that unless this is just intellectual wanking we need to get this language 
stabilized.

Then others might start to take it seriously.



Discussions like this are precisely one of the strengths of this 
newsgroup. They sometimes lead to beneficial results, such as additions 
or changes to the language. The last thing we need here is moderation.

Re: eliminate writeln et comp?


Daniel Keep wrote:

When was the last time you had to put this in your GCC-compiled programs?

Portions of this program Copyright (C) Free Software Foundation.  Uses
glibc.


Executable code resulting from compilation is not a work derived from GCC.

glibc is extremely difficult to link statically and is distributed under 
the LGPL, so no copyright notice is necessary.


If dmd had good support for dynamic linking, this wouldn't be nearly as 
much of an issue. Sadly, ddl seems to be on hiatus, and at any rate, it 
can't be applied to the runtime.

Re: Response files

2009-03-20 Thread Walter Bright


Frank Benoit wrote:

DMD 1.041 on windows does support response files, that is a file
containing arguments.
On Linux dmd does not understand that.


The windows response files date back to the problem DOS/Windows had with 
only a very short command line length was allowed. So the arguments were 
put into a file instead.


It's probably a good idea to do it for Linux, too.

Re: new D2.0 + C++ language

2009-03-20 Thread bearophile

Yigal Chripun:
 what you suggest is C++ with better syntax, *NOT* a variant of D. for that 
 look at: 
 http://en.wikipedia.org/wiki/Significantly_Prettier_and_Easier_C%2B%2B_Syntax

Thank you for the link, I did know only A Modest Proposal: C++ Resyntaxed.
In some situations that SPECS syntax is more readable than D syntax:

Function having an int argument and returning pointer to float:
(int - ^float)

Pointer to function having an int and float argument returning nothing:
^(int, float - void)

Note that SPECS uses  ^  :=  and  =  as in Pascal.
Pointer syntax of Pascal is better, and the :=  = often avoid the C bugs like 
if(a = b).

But probably D needs to tell apart functions and delegates too, so that syntax 
isn't enough.
And I think now it's not easy to change the meaning of  ^ in D :-)

So a possibility (keeping the usual * pointer syntax):
{int = int}
Delegate:
{{int = int}}
That can also offer a syntax for anonymous functions/delegates:
{int x = x*x}
{x = x*x}
{{x = x*x}}

Bye,
bearophile

Re: new D2.0 + C++ language

2009-03-20 Thread Craig Black

Robert Jacques sandf...@jhu.edu wrote in message
news:op.uq0ng1we26s...@sandford.myhome.westell.com...

On Wed, 18 Mar 2009 13:48:55 -0400, Craig Black cbl...@ara.com wrote:

bearophile Wrote:

Weed:
I want to offer the dialect of the language D2.0, suitable for use
where
are now used C/C++. Main goal of this is making language like D, but
corresponding zero-overhead principle like C++:
...
The code on this language almost as dangerous as a code on C++ - it
is a
necessary cost for increasing performance.

No, thanks...

And regarding performance, eventually it will come a lot from a good
usage of multiprocessing, that in real-world programs may need pure
functions and immutable data. That D2 has already, while C++ is less
lucky.

Bye,
bearophile

Multiprocessing can only improve performance for tasks that can run in
parallel. So far, every attempt to do this with GC (that I know of) has
ended up slower, not faster. Bottom line, if GC is the bottleneck, more
CPU's won't help.

For applications where GC performance is unacceptable, we either need a
radically new way to do GC faster, rely less on the GC, or drop GC
altogether.

However, in D, we can't get rid of the GC altogether, since the compiler
relies on it. But we can use explicit memory management where it makes
sense to do so.

-Craig

*Sigh*, you do know people run cluster multi-threaded Java apps all the
time right? I'd recommend reading about concurrent GCs
http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Stop-the-world_vs._incremental_vs._concurrent.
By the way, traditional malloc has rather horrible multi-threaded
performance as 1) it creates lots of kernel calls and 2) requires a global
lock on access. Yes, there are several alternatives available now, but the
same techniques work for enabling multi-threaded GCs. D's shared/local
model should support thread local heaps, which would improve all of the
above.

I admit to knowing nothing about clusters, so my point does not apply to
them. Also note that I didn't say GC was not useful. I said GC can be a
bottleneck. If it is a bottleneck (on a single computer), throwing more
CPU's at it doesn't help. Why? The big performance problem with GC is with
large applications that allocate a lot of memory. In these apps, modern
GC's are constantly causing page faults because they are touching too much
memory.

I look forward to the day where all the GC problems are solved, and I
believe it will come. It would be really nice to have a faster GC in D.
However, I don't see how each processor working on a separate heap will
solve the problem of the GC causing page faults. But maybe I missed
something.

BTW, I don't use traditional malloc. I use nedmalloc and the performance is
quite good.

-Craig

Re: new D2.0 + C++ language

2009-03-20 Thread Rainer Deyke

Christopher Wright wrote:
 Games have strict performance requirements that a stop-the-world type of
 garbage collector violates. Specifically, a full collection would cause
 an undue delay of hundreds of milliseconds on occasion. If this happens
 once every ten seconds, your game has performance problems. This is not
 true of pretty much any other type of application.

If you spend hundreds of milliseconds on garbage collection every ten
second, you spend multiple percent of your total execution time on
garbage collection.  I wouldn't consider that acceptable anywhere.


-- 
Rainer Deyke - rain...@eldwood.com

Re: new D2.0 + C++ language

2009-03-20 Thread bearophile

Jarrett Billingsley:
  Pointer syntax of Pascal is better, and the :=  = often avoid the C bugs 
  like if(a = b).
 
 Which isn't a problem in D ;)

Let's say D has a workaround to patch most of that C-syntax hole :-)
And I'll never like C pointer syntax.


 That's actually pretty nice.

An alternative syntax that avoids the two nested {{}}:
Lambda functions:
{int x - x*x}
{x - x*x}
{float x, float x*y}
Lambda delegates:
{int x = x*x}
{x = x*x}
{float x, float y = x*y}

I may even like that :-)

Bye,
bearophile

Re: new D2.0 + C++ language


Hello Rainer,


Christopher Wright wrote:


Games have strict performance requirements that a stop-the-world type
of garbage collector violates. Specifically, a full collection would
cause an undue delay of hundreds of milliseconds on occasion. If this
happens once every ten seconds, your game has performance problems.
This is not true of pretty much any other type of application.


If you spend hundreds of milliseconds on garbage collection every ten
second, you spend multiple percent of your total execution time on
garbage collection.  I wouldn't consider that acceptable anywhere.



If you spend a few 0.1ths of a ms every 10 ms on reference counting, smart 
pointers or passing around other meta data it's the just as bad. I have no 
data but even worse would be, as I expect is true, if non GC apps end up 
being architected different to make memory management easier (if so, you 
can bet money it won't be faster as result).

Re: new D2.0 + C++ language


Rainer Deyke wrote:

Christopher Wright wrote:

Games have strict performance requirements that a stop-the-world type of
garbage collector violates. Specifically, a full collection would cause
an undue delay of hundreds of milliseconds on occasion. If this happens
once every ten seconds, your game has performance problems. This is not
true of pretty much any other type of application.


If you spend hundreds of milliseconds on garbage collection every ten
second, you spend multiple percent of your total execution time on
garbage collection.  I wouldn't consider that acceptable anywhere.


I was pulling numbers out of my ass. If I wanted to do a proper job, I 
would have built a large application and modified druntime to get proper 
timings.


0.1 seconds out of every ten is a small amount to pay for the benefits 
of garbage collection in most situations. (Most GUI applications are 
idle most of the time anyway.) I did, however, specifically make the 
point that it's unacceptable in some situations. These situations may be 
your situations. Even so, the garbage collector might not be that slow. 
(And for what it's doing, that seems pretty fast to me.)


It would be cool if the GC could watch for what pages have been written 
to since the last collection and only bother looking through them. That 
would require some additional accounting. On Windows, there's a system 
call GetWriteWatch that works in that regard, but on Linux, the only 
solution I've seen is marking the memory readonly and trapping SIGSEGV. 
That would be pretty expensive.

Re: eliminate writeln et comp?

2009-03-20 Thread Robert Jacques


On Fri, 20 Mar 2009 08:28:06 -0400, Don nos...@nospam.com wrote:
Boost, zlib, WTFYW, and public domain, seem to be the only ones which  
are suitable for a standard library.


Actually, due to some interesting aspects of international copyright law  
public domain isn't suitable for a standard library. In some countries it  
is not possible to put a work into the public domain; a work may only  
enter it once the copyright has expired.

Re: new D2.0 + C++ language