Re: container stuff

[Don]

Andrei Alexandrescu wrote:

I've uploaded a work in progress on the container design here:

http://erdani.com/d/phobos/std_container.html

It's deceptively simple - the entire design is a nomenclature, really. 
Any given container may choose to implement whichever primitives it can, 
if (and only if) it can satisfy the requirements. Beyond that, each 
container can define its own primitives.


Looks great to me. A couple of comments:

There are a bunch of "soft" primitives. Those are meant to put a stop to 
the iterator invalidation problems experienced in the STL. The container 
implementor may alias softXyz to xyz if she knows the operation won't 
mess the ranges currently iterating the container (which is the case for 
most node-based containers). I haven't yet discussed subtler cases in 
which a range starts with a removed element etc., but I plan to.


The softXXX primitives are listed as having the same complexity as the 
non-soft primitives. Should it be explicitly stated that non-soft should 
always be at least as fast as soft? (So that if you don't need the soft 
guarantee, you should always use the non-soft primitive?)


Also, I agree with Jerry that something like "stable" would be more 
intuitive than "soft". I guess it's not exactly the same meaning as 
stableSort, but it's pretty close. A problem with the name "soft" is 
that it's a harder, stronger guarantee! It seems to be a concept of a 
"tame" removal as opposed to reckless, "savage" removal?






So, this is it really: the containers specification is a collection of 
capabilities. A given container picks the ones it can support 
meaningfully, and user code has the specification as semantic and 
complexity guarantees.


This design is quite far removed from Steve's, which makes the 
integration with dcollection tenuous. But at a minimum, maybe we can 
work out something in which Steve offers, with credit, implementation 
for this design and also offers dcollections as a separate library.



Andrei

Re: container stuff

[Jerry Quinn]

Andrei Alexandrescu Wrote:

> On 05/25/2010 06:04 PM, Steven Schveighoffer wrote:
> > On Tue, 25 May 2010 18:27:32 -0400, Andrei Alexandrescu
> >  wrote:
> >
> >> I've uploaded a work in progress on the container design here:
> >>
> >> http://erdani.com/d/phobos/std_container.html
> >>
> >> It's deceptively simple - the entire design is a nomenclature, really.
> >> Any given container may choose to implement whichever primitives it
> >> can, if (and only if) it can satisfy the requirements. Beyond that,
> >> each container can define its own primitives.
> >>
> >> There are a bunch of "soft" primitives. Those are meant to put a stop
> >> to the iterator invalidation problems experienced in the STL. The
> >> container implementor may alias softXyz to xyz if she knows the
> >> operation won't mess the ranges currently iterating the container
> >> (which is the case for most node-based containers). I haven't yet
> >> discussed subtler cases in which a range starts with a removed element
> >> etc., but I plan to.

softXXX might be better named safeXXX or stableXXX.  The names might be more 
suggestive of preserving iteration.

The doc isn't quite clear whether make is a member function or
standalone.  I assume it's standalone, but that's worth firming up.

> > I don't like insertInstead, can we make it replace?
> 
> replace was the original name. insertInstead is consistent with the 
> other two, so we have (softI|i)nsert[Before|After|Instead].

I second the request for the name "replace".  Despite the consistency, I think 
replace is clear to programmers as well as being more familiar and comfortable. 
 Also, the operation really isn't "insert instead", it's "delete then insert 
instead".  So there is lack of symmetry because it removes elements while the 
other does not.

Another  issue I see is that opIndex and its brethren takes KeyType, but for 
something like vector, this should be size_t..  I don't think you want 
ElementType to be tuple!(size_t, ElementType) in this case.  

Related to this, do you intend removal of a single element to use remove(range) 
or removeKey?

Finally, opSlice(begin, end) is not there.  Was this intentional or overlooked?

Jerry

Re: 64-bit support (Was: Poll: Primary D version)

[Jesse Phillips]

Andrei Alexandrescu wrote:

>
> Good point. Who here knows what steps need be taken to create a repository?
>
> Andrei

I haven't tried myself, someone has for the Tango side. It doesn't look
to be too difficult:

http://www.debian-administration.org/articles/286

If you would like I could try to come up with a configuration file this
week/weekend

Re: To interface or not to interface

[Walter Bright]

Steven Schveighoffer wrote:
On Mon, 24 May 2010 18:13:38 -0400, Walter Bright 
 wrote:



Steven Schveighoffer wrote:
All an interface does is give an abstract representation of functions 
that are *already there*.  Removing the interface does not remove the 
functions that implemented the interface.


Then why do interfaces need to be part of the collection component? 
Why can't the user add them if he wants them?


How do you add an interface to a class?


Define an interface who's member functions call the class' member functions.

Re: To interface or not to interface

[Walter Bright]

Jason House wrote:

Walter Bright Wrote:


Jason House wrote:

7. Compiler-assisted verification.

For interfaces, the compile time checking is limited to verifying that
functions with the right signature are supplied. Templates can go
considerably beyond that with the constraint checking.


constraints are more powerful, but they have downsides: • If a class is
incorrectly defined, failure to use a type without a constraint check leads
to errors in the code using it instead of the class definition. Usage isn't
always guaranteed to be correct either, so the developer must spend extra
time diagnosing the real error. • If a class is incorrectly, initial usage
without a constraint may completely miss the error. Easy examples would be a
typo propogated with copy/paste, or neglecting to use save. • If a class is
incorrectly defined and usage uses a constraint, the developer will simply
get an error that there is no matching call. • If a constraint is incorrectly
defined and usage uses the constraint, the developer will simply get an error
that there is no matching call.

None of these scenarios are particularly helpful for a developer
creating/expanding a family of objects.



You can also make constraints that give custom error messages, so you can do 
better than the compiler's stab at it. How good they are is up to the designer 
of the type.

Re: container stuff

[Andrei Alexandrescu]

On 05/25/2010 06:04 PM, Steven Schveighoffer wrote:

What about the purge function of dcollections (i.e. removal while
iterating)?


I changed remove and softRemove to return a range positioned to after 
the removed stuff.


Andrei

Re: container stuff

[Walter Bright]

Andrei Alexandrescu wrote:

On 05/25/2010 09:07 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

On 05/25/2010 08:31 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

On 05/25/2010 07:35 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

I've uploaded a work in progress on the container design here:


Great! Some nitpicky comments:

1. What's the difference between a value and an element?


None.


Then I suggest sticking with one or the other throughout the spec. 
Also,

there's both an ElementType and a ValueType.


Sorry, I was wrong. ValueType is defined for keyed containers to mean
the mapped type. Should I call it MappedType?


Can a container have different ElementTypes from ValueTypes?


For a hash K->V, KeyType is K, ValueType is V, and ElementType is 
Tuple!(K, V).


Ok, that makes it clear, and it needs to be in the spec.

Re: container stuff

[Andrei Alexandrescu]

On 05/25/2010 09:07 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

On 05/25/2010 08:31 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

On 05/25/2010 07:35 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

I've uploaded a work in progress on the container design here:


Great! Some nitpicky comments:

1. What's the difference between a value and an element?


None.


Then I suggest sticking with one or the other throughout the spec. Also,
there's both an ElementType and a ValueType.


Sorry, I was wrong. ValueType is defined for keyed containers to mean
the mapped type. Should I call it MappedType?


Can a container have different ElementTypes from ValueTypes?


For a hash K->V, KeyType is K, ValueType is V, and ElementType is 
Tuple!(K, V).


Andrei

Re: container stuff

[Walter Bright]

Andrei Alexandrescu wrote:

On 05/25/2010 08:31 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

On 05/25/2010 07:35 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

I've uploaded a work in progress on the container design here:


Great! Some nitpicky comments:

1. What's the difference between a value and an element?


None.


Then I suggest sticking with one or the other throughout the spec. Also,
there's both an ElementType and a ValueType.


Sorry, I was wrong. ValueType is defined for keyed containers to mean 
the mapped type. Should I call it MappedType?


Can a container have different ElementTypes from ValueTypes?

Re: container stuff

[Andrei Alexandrescu]

On 05/25/2010 08:31 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

2. What's the affect of clear() on the capacity?


There is no guaranteed effect.


Should say so in the spec.


I guess if it's missing then it's implied.


3. Shouldn't KeyTypes be a type tuple?


Yes. At the end of the day you must be able to say KeyTypes!3 to get
the fourth type there. You say it should be KeyTypes[3]. I see tuple
trouble, sigh. With a template I feel I have more control.


The reason I prefer a tuple for this is then I can ask KeyTypes.length,
whereas with the template that's not specified by the spec.


OK.


Andrei

Re: container stuff

[Andrei Alexandrescu]

On 05/25/2010 08:31 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

On 05/25/2010 07:35 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

I've uploaded a work in progress on the container design here:


Great! Some nitpicky comments:

1. What's the difference between a value and an element?


None.


Then I suggest sticking with one or the other throughout the spec. Also,
there's both an ElementType and a ValueType.


Sorry, I was wrong. ValueType is defined for keyed containers to mean 
the mapped type. Should I call it MappedType?


Andrei

Re: container stuff

[Walter Bright]

Andrei Alexandrescu wrote:

On 05/25/2010 07:35 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

I've uploaded a work in progress on the container design here:


Great! Some nitpicky comments:

1. What's the difference between a value and an element?


None.


Then I suggest sticking with one or the other throughout the spec. Also, there's 
both an ElementType and a ValueType.




2. What's the affect of clear() on the capacity?


There is no guaranteed effect.


Should say so in the spec.



3. Shouldn't KeyTypes be a type tuple?


Yes. At the end of the day you must be able to say KeyTypes!3 to get the 
fourth type there. You say it should be KeyTypes[3]. I see tuple 
trouble, sigh. With a template I feel I have more control.


The reason I prefer a tuple for this is then I can ask KeyTypes.length, whereas 
with the template that's not specified by the spec.

Re: container stuff

[Andrei Alexandrescu]

On 05/25/2010 07:35 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

I've uploaded a work in progress on the container design here:


Great! Some nitpicky comments:

1. What's the difference between a value and an element?


None.


2. What's the affect of clear() on the capacity?


There is no guaranteed effect.


3. Shouldn't KeyTypes be a type tuple?


Yes. At the end of the day you must be able to say KeyTypes!3 to get the 
fourth type there. You say it should be KeyTypes[3]. I see tuple 
trouble, sigh. With a template I feel I have more control.



Andrei

Re: container stuff

[Andrei Alexandrescu]

On 05/25/2010 06:18 PM, bearophile wrote:

Andrei Alexandrescu:


I feel this design is pretty close to what I really wanted.<


Good :-)

How is opApply playing in the design of the containers? Can opSlice return a 
struct that defines opApply?


I hope to work with ranges only.


There are a bunch of "soft" primitives. Those are meant to put a stop to
the iterator invalidation problems experienced in the STL.


I can suggest another thing, that doesn't replace this idea, but can make the 
nonsoft primitives a little safer when the program is compiled in nonrelease 
mode: http://d.puremagic.com/issues/show_bug.cgi?id=4179


Will look into it, sounds like an implementation matter.


any container must be a reference type, whether implemented as a class or 
struct.<


This probably makes their usage simpler, so this can be the right decision. But 
then you can't define something like a TinyHashSet or a StaticBitSet that are 
better allocated on the stack... (a StaticBitSet is a struct template I have 
defined, at compile time you give it its length and it gets allocated on the 
stack, and represents a set of integers in an intgerval, or something similar).


I'm guessing some value container-like entities wouldn't harm if they 
can easily be converted to references.



Why is length O(log(n))? If a linked list has no length field, to compute its 
length it has to scan all of it.


I forgot the case I had in mind. I know that opSlice() must be O(log n) 
for e.g. tree traversals. Probably some trees could save some state if 
they exploit O(log n) length.



make(): this has just killed the new :-)

Among the standard primitives is it useful to have something to ask the actual 
computational complexity of a specific operation of a specific container? There 
are some ways to implement this, the simplest is to define enum with the most 
common complexities, and then a collection can contain an enum (const) value 
for each operation, something like:
enum lengthComplexity = CompComplexity.linear;
I don't know if this can be useful (to choose collections, to infer code 
complexity, etc).


If it can be used gainfully, that would be great. Intriguing idea.


Andrei

Re: container stuff

[Andrei Alexandrescu]

On 05/25/2010 06:04 PM, Steven Schveighoffer wrote:

On Tue, 25 May 2010 18:27:32 -0400, Andrei Alexandrescu
 wrote:


I've uploaded a work in progress on the container design here:

http://erdani.com/d/phobos/std_container.html

It's deceptively simple - the entire design is a nomenclature, really.
Any given container may choose to implement whichever primitives it
can, if (and only if) it can satisfy the requirements. Beyond that,
each container can define its own primitives.

The design is not fancy, which doesn't worry me in the least because I
was aiming for the right design, not a fancy design. I feel this
design is pretty close to what I really wanted.

The major players are the containers themselves and the ranges they
define. Most operations are defined in terms of ranges, not
containers. The containers only need to support a modicum of
primitives that affect the topology of containers, plus a few
convenience functions.

There are a bunch of "soft" primitives. Those are meant to put a stop
to the iterator invalidation problems experienced in the STL. The
container implementor may alias softXyz to xyz if she knows the
operation won't mess the ranges currently iterating the container
(which is the case for most node-based containers). I haven't yet
discussed subtler cases in which a range starts with a removed element
etc., but I plan to.

So, this is it really: the containers specification is a collection of
capabilities. A given container picks the ones it can support
meaningfully, and user code has the specification as semantic and
complexity guarantees.

This design is quite far removed from Steve's, which makes the
integration with dcollection tenuous. But at a minimum, maybe we can
work out something in which Steve offers, with credit, implementation
for this design and also offers dcollections as a separate library.


I take it from the comment in the docs that cursors can be an auxiliary
range? Is there any reason not to define a mandatory cursor type (a
cursor is elementary to define if a range is definable)?


Yes, but the cursor would have to pass scrutiny for usefulness just like 
anything else.



There is no remove(Range) function, this is a bad omission. It's one of
the main reasons I created dcollections (quick element removal when
element lookup is not quick).


I think it got lost when I reordered the code (I did a major reshuffling 
just before posting). I put it back.



I don't like insertInstead, can we make it replace?


replace was the original name. insertInstead is consistent with the 
other two, so we have (softI|i)nsert[Before|After|Instead].



What about the purge function of dcollections (i.e. removal while
iterating)?


Removal while iterating is achieved through different means. I need to 
think through the details a bit more, but in essence it doesn't have to 
be a primitive. The primitives should allow implementation of a generic 
function that removes elements that satisfy a condition, something as 
follows:


If the collection supports softRemove, if you want to remove an element 
while iterating with a range r, you can say coll.softRemove(r.take(1)). 
If it doesn't, I'm thinking of allowing the erase/remove idiom 
(http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Erase-Remove). For 
that, remove should return a range positioned right after the removed 
element. Let me think a bit more about that.



What about opApply? Without opApply, you cannot use foreach to get both
keys and values.


I'd like to design without opApply as part of the primitives. You can 
use foreach to iterate tuples of keys and values.



I can probably submit my basic implementations, and use them from std.x
to implement dcollections. This way, the complex pieces are shared.
Dcollections definitely fills needs that this collection package
doesn't, and it should be mostly compatible.


Sounds promising!


Andrei

Re: container stuff

[Walter Bright]

Andrei Alexandrescu wrote:

I've uploaded a work in progress on the container design here:


Great! Some nitpicky comments:

1. What's the difference between a value and an element?

2. What's the affect of clear() on the capacity?

3. Shouldn't KeyTypes be a type tuple?

Re: Poll: Primary D version

[retard]

Tue, 25 May 2010 14:22:47 -0700, Walter Bright wrote:

> retard wrote:
>> I don't think the D community is really interested in hearing something
>> positive about dynamically typed non-native languages. Traditionally
>> that's the best way to wreck your efficiency and it's tough to admit
>> that those languages are now better. The traditional native code way is
>> to use primitive compilers and brute force via inline asm.
> 
> If this were true, C and C++ would be dead languages. C++, for example,
> is often used in combination with Python. The C++ part is for the bits
> that need to be fast.
> 
> BTW, even the best compilers fall far short of what an expert can do
> with assembler.

It's impossible to say whether e.g. LuaJIT is faster than some C++ 
compiler. The code matters. Bad code written by a novice programmer often 
works faster when a higher level language is used because there's more 
room for optimizations. However, it really depends on the quality of the 
optimzations done by the compiler.

What I wanted to point out was that if a person needs to choose between D 
(DMD) and Lua (LuaJIT), it would probably make more sense to use LuaJIT 
if the user wants better performing code. However, D (LDC) and D (some 
other vendor who uses modern backends like LLVM/GCC) probably win DMD 
here. Almost all compilers probably beat it.

Re: 64-bit support (Was: Poll: Primary D version)

[retard]

Tue, 25 May 2010 13:38:00 -0300, Leandro Lucarella wrote:

> Justin Johansson, el 25 de mayo a las 22:42 me escribiste:
>> retard wrote:
>> >The files inside the .zip won't run because one particular Mr. Bright
>> >doesn't set the +x flag on. It's not a fault of Linux if he is using
>> >retarded Windows version of the zip packager. It's easy to fix, he
>> >just doesn't care. The zip works just fine even on a 64-bit system if
>> >the 32-
>> >bit libraries have been installed.
>> 
>> Hey retard, while I enjoy reading a lot of the controversy that you
>> like to create on this NG, sorry, on this occasion I think you are
>> being somewhat unfair towards one particular person here.
>> 
>> My understanding is that .zip files are traditionally a DOS (originally
>> PKZIP) then come Windows thing then come Unix available.
>> 
>> http://en.wikipedia.org/wiki/ZIP_%28file_format%29
>> 
>> Being so, .zip files do not inherently/traditionally support recording
>> Unix file permissions such as +x within the archive.  If such
>> facilities exist today in Unix .zip utilities (and I am unaware of the
>> same) these would have to be extensions over and above what .zip files
>> are commonly understood to support given the DOS/PKZIP history of this
>> file format.
> 
> Yes, it does:
> 
> $ touch bin
> $ chmod a+x bin
> $ ls -l bin
> -rwxr-xr-x 1 luca luca 0 may 25 12:27 bin $ zip bin.zip bin
>   adding: bin (stored 0%)
> $ rm bin
> $ ls -l bin
> ls: cannot access bin: No such file or directory $ unzip bin.zip
> Archive:  bin.zip
>  extracting: bin
> $ ls -l bin
> -rwxr-xr-x 1 luca luca 0 may 25 12:27 bin
> 
>> Recording of Unix file permissions in archives is traditionally
>> achieved with .tar files (and compressed variants) as I am sure you are
>> well aware.
>> 
>> When downloading archive from the net, I look for .zip files if wanting
>> to install on Windows and .tar or .tar.gz if wanting to install on
>> Unixes.  I imagine that most Unix-aware folks would do the same.
> 
> That makes no sense. Even when history is interesting, now both zip and
> tar works just fine in both Unix and Windows, so retard is right, the
> zip being broken is entirely Walter's fault. And I think he knows it,
> that's why he said he wanted to give some love to the toolchain and
> distribution issues when D2 is finished.
> 
> I don't think either attacking Walter gratuitously or defending him
> blindly is a good for D.

I wasn't attacking anyone, just pointing out the cause. Yes, it's because 
he uses a windows version of zip so it's his decision to make it harder 
for *nix users. Because of the non-free license he is the only person who 
can fix this -- I can't officially redistribute a fixed .zip package or 
any other repackaged dmd.

And Justin is also right, I wouldn't mind having a .tar.gz package with 
the executable flags correctly set (and without win32 executables). Just 
repacking the distribution on a *nix computer would be enough to fix it 
and would probably be the easiest solution if windows zip archivers don't 
support setting the flag.

Re: container stuff

[bearophile]

Andrei Alexandrescu:

>I feel this design is pretty close to what I really wanted.<

Good :-)

How is opApply playing in the design of the containers? Can opSlice return a 
struct that defines opApply?


> There are a bunch of "soft" primitives. Those are meant to put a stop to 
> the iterator invalidation problems experienced in the STL.

I can suggest another thing, that doesn't replace this idea, but can make the 
nonsoft primitives a little safer when the program is compiled in nonrelease 
mode: http://d.puremagic.com/issues/show_bug.cgi?id=4179


>any container must be a reference type, whether implemented as a class or 
>struct.<

This probably makes their usage simpler, so this can be the right decision. But 
then you can't define something like a TinyHashSet or a StaticBitSet that are 
better allocated on the stack... (a StaticBitSet is a struct template I have 
defined, at compile time you give it its length and it gets allocated on the 
stack, and represents a set of integers in an intgerval, or something similar).

Why is length O(log(n))? If a linked list has no length field, to compute its 
length it has to scan all of it.

make(): this has just killed the new :-)

Among the standard primitives is it useful to have something to ask the actual 
computational complexity of a specific operation of a specific container? There 
are some ways to implement this, the simplest is to define enum with the most 
common complexities, and then a collection can contain an enum (const) value 
for each operation, something like:
enum lengthComplexity = CompComplexity.linear;
I don't know if this can be useful (to choose collections, to infer code 
complexity, etc).

Bye,
bearophile

Re: container stuff

[Steven Schveighoffer]

On Tue, 25 May 2010 18:27:32 -0400, Andrei Alexandrescu  
 wrote:



I've uploaded a work in progress on the container design here:

http://erdani.com/d/phobos/std_container.html

It's deceptively simple - the entire design is a nomenclature, really.  
Any given container may choose to implement whichever primitives it can,  
if (and only if) it can satisfy the requirements. Beyond that, each  
container can define its own primitives.


The design is not fancy, which doesn't worry me in the least because I  
was aiming for the right design, not a fancy design. I feel this design  
is pretty close to what I really wanted.


The major players are the containers themselves and the ranges they  
define. Most operations are defined in terms of ranges, not containers.  
The containers only need to support a modicum of primitives that affect  
the topology of containers, plus a few convenience functions.


There are a bunch of "soft" primitives. Those are meant to put a stop to  
the iterator invalidation problems experienced in the STL. The container  
implementor may alias softXyz to xyz if she knows the operation won't  
mess the ranges currently iterating the container (which is the case for  
most node-based containers). I haven't yet discussed subtler cases in  
which a range starts with a removed element etc., but I plan to.


So, this is it really: the containers specification is a collection of  
capabilities. A given container picks the ones it can support  
meaningfully, and user code has the specification as semantic and  
complexity guarantees.


This design is quite far removed from Steve's, which makes the  
integration with dcollection tenuous. But at a minimum, maybe we can  
work out something in which Steve offers, with credit, implementation  
for this design and also offers dcollections as a separate library.


I take it from the comment in the docs that cursors can be an auxiliary  
range?  Is there any reason not to define a mandatory cursor type (a  
cursor is elementary to define if a range is definable)?


There is no remove(Range) function, this is a bad omission.  It's one of  
the main reasons I created dcollections (quick element removal when  
element lookup is not quick).


I don't like insertInstead, can we make it replace?

What about the purge function of dcollections (i.e. removal while  
iterating)?


What about opApply?  Without opApply, you cannot use foreach to get both  
keys and values.


I can probably submit my basic implementations, and use them from std.x to  
implement dcollections.  This way, the complex pieces are shared.   
Dcollections definitely fills needs that this collection package doesn't,  
and it should be mostly compatible.


-Steve

container stuff

[Andrei Alexandrescu]

I've uploaded a work in progress on the container design here:

http://erdani.com/d/phobos/std_container.html

It's deceptively simple - the entire design is a nomenclature, really. 
Any given container may choose to implement whichever primitives it can, 
if (and only if) it can satisfy the requirements. Beyond that, each 
container can define its own primitives.


The design is not fancy, which doesn't worry me in the least because I 
was aiming for the right design, not a fancy design. I feel this design 
is pretty close to what I really wanted.


The major players are the containers themselves and the ranges they 
define. Most operations are defined in terms of ranges, not containers. 
The containers only need to support a modicum of primitives that affect 
the topology of containers, plus a few convenience functions.


There are a bunch of "soft" primitives. Those are meant to put a stop to 
the iterator invalidation problems experienced in the STL. The container 
implementor may alias softXyz to xyz if she knows the operation won't 
mess the ranges currently iterating the container (which is the case for 
most node-based containers). I haven't yet discussed subtler cases in 
which a range starts with a removed element etc., but I plan to.


So, this is it really: the containers specification is a collection of 
capabilities. A given container picks the ones it can support 
meaningfully, and user code has the specification as semantic and 
complexity guarantees.


This design is quite far removed from Steve's, which makes the 
integration with dcollection tenuous. But at a minimum, maybe we can 
work out something in which Steve offers, with credit, implementation 
for this design and also offers dcollections as a separate library.



Andrei

Re: Poll: Primary D version

[Walter Bright]

retard wrote:
I don't think the D community is really interested in hearing something 
positive about dynamically typed non-native languages. Traditionally 
that's the best way to wreck your efficiency and it's tough to admit that 
those languages are now better. The traditional native code way is to use 
primitive compilers and brute force via inline asm.


If this were true, C and C++ would be dead languages. C++, for example, is often 
used in combination with Python. The C++ part is for the bits that need to be fast.


BTW, even the best compilers fall far short of what an expert can do with 
assembler.

Re: Poll: Primary D version

[Bill Baxter]

On Tue, May 25, 2010 at 12:45 PM, Bill Baxter  wrote:
> On Tue, May 25, 2010 at 12:11 PM, bearophile  wrote:
>> Bill Baxter:
>>> Do you have any citations of that?  All I can find on LuaJIT.org is
>>> comparisons of LuaJIT vs other versions of Lua.
>>
>> On my site you can see a version of the SciMark2 benchmark (that contains 
>> several sub-benchmarks, naive scientific kernels, mostly) for D with 
>> numerous timings. LDC is able to compile it quite well.
>>
>> You can find a version of that code here:
>> http://luajit.org/download/scimark.lua
>> I have compiled the awesome LUA JIT (it's easy) on Linux, and found timings 
>> against ldc, dmd.
>> I have taken similar timings for another benchmark (nboby, from Shootout 
>> site).
>
> So LuaJIT beats D on some or all of those benchmarks?  I can't quite
> remember what your website URL is.
> But I did find this:
> http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=luajit&lang2=gpp
> I was thinking LuaJIT would be too new and/or fringe for it to be on
> the Alioth shootout, but it's there.
> From that it looks like LuaJIT can't beat g++ for speed on any of the
> benchmarks.  You disagree with those results?

Nevermind.  I realize you didn't say that LuaJIT was faster than g++,
just faster than DMD.But that last part made it sound like you
thought LuaJIT was on track to eventually outperform all compilers.
As in the need for fast JIT is strong enough that eventually people
will figure out how to make it faster than everything else out there.

--bb

Re: Poll: Primary D version

[bearophile]

Bill Baxter:
> So LuaJIT beats D on some or all of those benchmarks?

It's faster or close, D code compiled with dmd.


> >From that it looks like LuaJIT can't beat g++ for speed on any of the
> benchmarks.  You disagree with those results?

I don't disagree with those results, in my original post I have said: >But 
today programs running on the the Lua JIT are often faster than equivalent 
FP-heavy D programs compiled with DMD.<
This means comparing FP-heavy programs compiled with LUA jit 2.0a4 and DMD 2.x.
I have not given hard timings because the point of my post was qualitative and 
not quantitative :-)

Bye,
bearophile

Re: Poll: Primary D version

[Bill Baxter]

On Tue, May 25, 2010 at 12:11 PM, bearophile  wrote:
> Bill Baxter:
>> Do you have any citations of that?  All I can find on LuaJIT.org is
>> comparisons of LuaJIT vs other versions of Lua.
>
> On my site you can see a version of the SciMark2 benchmark (that contains 
> several sub-benchmarks, naive scientific kernels, mostly) for D with numerous 
> timings. LDC is able to compile it quite well.
>
> You can find a version of that code here:
> http://luajit.org/download/scimark.lua
> I have compiled the awesome LUA JIT (it's easy) on Linux, and found timings 
> against ldc, dmd.
> I have taken similar timings for another benchmark (nboby, from Shootout 
> site).

So LuaJIT beats D on some or all of those benchmarks?  I can't quite
remember what your website URL is.
But I did find this:
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=luajit&lang2=gpp
I was thinking LuaJIT would be too new and/or fringe for it to be on
the Alioth shootout, but it's there.
>From that it looks like LuaJIT can't beat g++ for speed on any of the
benchmarks.  You disagree with those results?

--bb

Re: Poll: Primary D version

[bearophile]

Bill Baxter:
> Do you have any citations of that?  All I can find on LuaJIT.org is
> comparisons of LuaJIT vs other versions of Lua.

On my site you can see a version of the SciMark2 benchmark (that contains 
several sub-benchmarks, naive scientific kernels, mostly) for D with numerous 
timings. LDC is able to compile it quite well.

You can find a version of that code here:
http://luajit.org/download/scimark.lua
I have compiled the awesome LUA JIT (it's easy) on Linux, and found timings 
against ldc, dmd.
I have taken similar timings for another benchmark (nboby, from Shootout site).

Bye,
bearophile

Re: 64-bit support (Was: Poll: Primary D version)

[Leandro Lucarella]

Andrei Alexandrescu, el 25 de mayo a las 08:27 me escribiste:
> On 05/24/2010 07:16 PM, eles wrote:
> >== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
> >article
> >>On 05/24/2010 05:20 PM, Walter Bright wrote:
> >>>Andrei Alexandrescu wrote:
> E.g. I can't install the .deb file on my 64-bit Linux.
> >>>
> >>>I think the current .deb files can be.
> >>Just tried again, same error message:
> >>Error: Wrong architecture 'i386'
> >>Let me know how I can help.
> >>Andrei
> >
> >just type
> >
> >sudo dpkg -i --force-architecture dmd_X.XXX-0_i386.deb
> >
> >where dmd_X.XXX-0_i386.deb is the name of the .deb file
> 
> Thanks. Is there a way to make that directive automatic inside the
> .deb file?

No, that's a broken deb file. The "right thing to do" is make 2 packages,
one for i386 and one for amd64. The amd64 packages should depend on the
necessary 32-bit libraries like ia32-libs.

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
Every day 21 new born babies will be given to the wrong parents

Re: 64-bit support (Was: Poll: Primary D version)

[Leandro Lucarella]

Jesse Phillips, el 25 de mayo a las 14:22 me escribiste:
> Andrei Alexandrescu wrote:
> 
> >
> > I think at the end of the day we need a link that people can click on 
> > and that's that. How can we make that work? Do we need a 64-bit .deb, or 
> > is it possible to automatically instruct the package manager (in the 
> > case of Ubuntu gdebi) to install it with dependencies and all?
> >
> > Andrei
> 
> Ubuntu (and family) is probably the only distro that you can expect
> gdebi to be installed on. And the only way to have it install the proper
> packages is to install a package with the required dependencies e.g. an
> AMD64 package.
> 
> To really make many Linux users happy would be to provide a repository.
> Even Google doesn't provide a one-click install for their programs (I
> bring them up because they try very hard to be user friendly).

In Ubuntu is extremely easy, just create a PPA[1].


For Debian is not that east but is not that hard either and I think
providing a (well done) .deb is acceptable. In Debian (or even Ubuntu) it
could be possible to pull the package "upstream" (to the non-free
repositories in Debian and to the multiverse repositories in Ubuntu,
I think). *That* would be the ideal for a Debian/Ubuntu user.

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
Yo soy Peperino, mártir latino, venid al asado pero traed el vino.
-- Peperino Pómoro

Re: 64-bit support (Was: Poll: Primary D version)

[Leandro Lucarella]

Justin Johansson, el 25 de mayo a las 22:42 me escribiste:
> retard wrote:
> >The files inside the .zip won't run because one particular Mr.
> >Bright doesn't set the +x flag on. It's not a fault of Linux if he
> >is using retarded Windows version of the zip packager. It's easy
> >to fix, he just doesn't care. The zip works just fine even on a
> >64-bit system if the 32-
> >bit libraries have been installed.
> 
> Hey retard, while I enjoy reading a lot of the controversy that you
> like to create on this NG, sorry, on this occasion I think you are
> being somewhat unfair towards one particular person here.
> 
> My understanding is that .zip files are traditionally a DOS
> (originally PKZIP) then come Windows thing then come Unix available.
> 
> http://en.wikipedia.org/wiki/ZIP_%28file_format%29
> 
> Being so, .zip files do not inherently/traditionally support
> recording Unix file permissions such as +x within the archive.  If
> such facilities exist today in Unix .zip utilities (and I am unaware
> of the same) these would have to be extensions over and above what
> .zip files are commonly understood to support given the DOS/PKZIP
> history of this file format.

Yes, it does:

$ touch bin
$ chmod a+x bin
$ ls -l bin
-rwxr-xr-x 1 luca luca 0 may 25 12:27 bin
$ zip bin.zip bin
  adding: bin (stored 0%)
$ rm bin
$ ls -l bin
ls: cannot access bin: No such file or directory
$ unzip bin.zip 
Archive:  bin.zip
 extracting: bin
$ ls -l bin
-rwxr-xr-x 1 luca luca 0 may 25 12:27 bin

> Recording of Unix file permissions in archives is traditionally
> achieved with .tar files (and compressed variants) as I am sure you
> are well aware.
> 
> When downloading archive from the net, I look for .zip files if
> wanting to install on Windows and .tar or .tar.gz if wanting to
> install on Unixes.  I imagine that most Unix-aware folks would do
> the same.

That makes no sense. Even when history is interesting, now both zip and
tar works just fine in both Unix and Windows, so retard is right, the zip
being broken is entirely Walter's fault. And I think he knows it, that's
why he said he wanted to give some love to the toolchain and distribution
issues when D2 is finished.

I don't think either attacking Walter gratuitously or defending him
blindly is a good for D.

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
He cometido pecados, he hecho el mal, he sido víctima de la envidia, el
egoísmo, la ambición, la mentira y la frivolidad, pero siempre he sido
un padre argentino que quiere que su hijo triunfe en la vida.
-- Ricardo Vaporeso

Re: Poll: Primary D version

[Bill Baxter]

On Sun, May 23, 2010 at 1:14 AM, bearophile  wrote:
> Walter Bright:
>
> Compiling programs of a dynamic language like Lua was seen as hopelessly 
> inefficient. But today programs running on the the Lua JIT are often faster 
> than equivalent FP-heavy D programs compiled with DMD.

Do you have any citations of that?  All I can find on LuaJIT.org is
comparisons of LuaJIT vs other versions of Lua.

--bb

Re: Installing D on MacOS X Leopard box

[Duke Normandin]

On Tue, 25 May 2010, Michel Fortin wrote:

> On 2010-05-25 10:30:44 -0400, Duke Normandin  said:
>
> > I simply followed the installation instructions on:
> >
> > http://www.digitalmars.com/d/2.0/dmd-osx.html
> >
> > I also installed the XCode plugin for D. Could _that_ have hosed my
> > install?
>
> Unlikely. The two errors you wrote about:
>
> > > dnormandin@ ~/programming/dmd2/osx/bin
> > > 07:53 am>>  ./dmd ../../code/firstApp.d
> > > ld warning: in /usr/local/gnat/lib/libgcc_s.10.5.dylib, missing
> > > required architecture i386 in file
> > > ld warning: in
> > > /usr/local/gnat/lib/gcc/x86_64-apple-darwin9.6.0/4.3.4/libgcc.a, file
> > > is not of required architecture
>
> Noticed that both refer to files in /usr/local/gnat? "GNAT", isn't this a
> GCC-based ADA compiler? My guess is that some of you environment variables
> have the "/usr/local/gnat" path before the standard system path, and "gnat"
> seems to include single-architecture (x86_64) copies of the GCC libraries. If
> that's the case, GCC running in 64 bit will work using these libraries, but
> since DMD is 32 bit it won't.

Nice catch! You must be French! ;) (like me..) Have to go out of town
for a few days, so I'll get back to this stuff at the end of the
week. L8r..
-- 
duke

Re: To interface or not to interface

[Michel Fortin]

On 2010-05-25 10:01:48 -0400, Jacob Carlborg  said:

Now Item could be an interface but it don't have to be. I suggest you 
have a look at Apple's documentation of NSTableView:


What Cocoa is doing is basically allowing 'optional' methods in an 
interface (a protocol in Objective-C). Taking your example, the 
NSTableViewDataSource protocol contains a lot of functions to provide 
the required data to a table. But many of them are optional: for 
instance a data source that does not implement the 
"...setObjectValue..." method will prevent the table's content from 
being edited, one that doesn't implement the 
"...sortDescriptorsDidChange..." method prevents the table from being 
sorted by clicking on its column headers, one that doesn't implement 
the various methods for drag and drop will prevent rows from being 
dragged.


(Note to Cocoa programmers: Prior to the Mac OS X 10.6 SDK, 
NSTableViewDataSource was an informal protocol implemented as a 
category of unimplemented functions in NSObject. The 10.6 SDK changed 
it to be a formal protocol with optional methods, a feature added to 
Objective-C 2.0.)


In D, one could create one interface for each of these groups of 
things, but then you'll have a bazilion of small interfaces and either 
you lose the relation between them or you end up with a combinational 
explosion. For instance, let's create a bunch of interfaces for what I 
wrote above:


interface TableDataSource {...}
interface TableDataSourceEdit : TableDataSource {...}
interface TableDataSourceSort : TableDataSource {...}
interface TableDataSourceDrag : TableDataSource {...}
interface TableDataSourceDropTarget : TableDataSource {...}

Now, when I implement the table view I could have one data source

class TableView {
TableDataSource dataSource;
}

and then I'd dynamically check whether my data source implements each 
of the child interfaces:


auto dataSourceEdit = cast(TableDataSourceEdit)dataSource)
if (dataSourceEdit) {
dataSourceEdit.setObject(object, row, column);
} else {
// data source cannot be edited
}

That's essentially what is done in Cocoa, except that in Cocoa an 
object usually checks for the existence of one of its delegate function 
prior calling it instead of having a whole lot of interfaces. This is 
why protocols are allowed to have optional methods.


Perhaps interfaces could be allowed to have optional methods that would 
require you to check if they're implemented before use.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Installing D on MacOS X Leopard box

[Michel Fortin]

On 2010-05-25 10:30:44 -0400, Duke Normandin  said:


I simply followed the installation instructions on:

http://www.digitalmars.com/d/2.0/dmd-osx.html

I also installed the XCode plugin for D. Could _that_ have hosed my
install?


Unlikely. The two errors you wrote about:


dnormandin@ ~/programming/dmd2/osx/bin
07:53 am>>  ./dmd ../../code/firstApp.d
ld warning: in /usr/local/gnat/lib/libgcc_s.10.5.dylib, missing
required architecture i386 in file
ld warning: in
/usr/local/gnat/lib/gcc/x86_64-apple-darwin9.6.0/4.3.4/libgcc.a, file
is not of required architecture


Noticed that both refer to files in /usr/local/gnat? "GNAT", isn't this 
a GCC-based ADA compiler? My guess is that some of you environment 
variables have the "/usr/local/gnat" path before the standard system 
path, and "gnat" seems to include single-architecture (x86_64) copies 
of the GCC libraries. If that's the case, GCC running in 64 bit will 
work using these libraries, but since DMD is 32 bit it won't.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Installing D on MacOS X Leopard box

[Duke Normandin]

On Tue, 25 May 2010, Michel Fortin wrote:

> On 2010-05-25 09:19:01 -0400, Duke Normandin  said:
>
> > On Tue, 25 May 2010, Michel Fortin wrote:
> >
> > > If you want to avoid the hassle of installing things manually, you can
> > > also
> > > use the D for Xcode installer which, in addition to installing a plugin
> > > for
> > > Xcode, downloads and installs the latest version of DMD 1 and 2.
> > >
> > > 
> >
> > Have it already - thanks! However, _now_ I need a tutorial on how to
> > use XCode, cuz I've been using emacs forever. I dabbled in ObjC for
> > awhile, but never got anywhere with, because I spent most of my time
> > keeping XCode happy. I don't want that to happen with my D
> > experience. Do you know of a _real good_ XCode tutorial?
>
> First, you don't *need* Xcode. The D for Xcode installer installs DMD so it is
> usable on the command line. You shouldn't have any problem using emacs, make,
> and whatever else you may like. If the 'dmd' command doesn't work after
> install, then it's probably something else outside of the DMD installation
> that is causing problems.

Never had a problem with gcc and all the other tools before I
installed D...

> Second, most Xcode tutorials focus on Cocoa and writing GUI applications. I'm
> not sure what you want to know, but personally what I find quite useful to be
> aware of is how the build system works. If that's what you want to learn,
> perhaps this is what you should read:
> 

That URL is exactly what I've been looking for. Thanks.
-- 
duke

Re: 64-bit support (Was: Poll: Primary D version)

[Andrei Alexandrescu]

On 05/25/2010 09:22 AM, Jesse Phillips wrote:

Andrei Alexandrescu wrote:



I think at the end of the day we need a link that people can click on
and that's that. How can we make that work? Do we need a 64-bit .deb, or
is it possible to automatically instruct the package manager (in the
case of Ubuntu gdebi) to install it with dependencies and all?

Andrei


Ubuntu (and family) is probably the only distro that you can expect
gdebi to be installed on. And the only way to have it install the proper
packages is to install a package with the required dependencies e.g. an
AMD64 package.


OK, thank you.


To really make many Linux users happy would be to provide a repository.
Even Google doesn't provide a one-click install for their programs (I
bring them up because they try very hard to be user friendly).


Good point. Who here knows what steps need be taken to create a repository?

Andrei

Re: Installing D on MacOS X Leopard box

[Duke Normandin]

On Tue, 25 May 2010, Jacob Carlborg wrote:

> On 2010-05-25 15.55, Duke Normandin wrote:
> > On Tue, 25 May 2010, Jacob Carlborg wrote:
> >
> > > On 2010-05-25 03.56, Duke Normandin wrote:
> > > > Hello list...
> > > >
> > > > I'm new to D, but not programming. I've followed the instructions on
> > > >
> > > > http://www.digitalmars.com/d/2.0/dmd-osx.html
> > > >
> > > > However, I keep on getting this error:
> > > >
> > > > dnormandin@ ~/programming/dmd2/code
> > > > 04:38 pm>>   dmd -w firstApp.d
> > > > object.d: Error: module object is in file 'object.d' which cannot be
> > > > read
> > > > import path[0] = /etc/../../src/phobos
> > > > import path[1] = /etc/../../src/druntime/import
> > > >
> > > > My guess is that dmd.conf is hosed somehow. I haven't edited the
> > > > default one - I've got it living in /etc/.
> > >
> > > You can just unzip the zip file, add executable permission on
> > > dmd/osx/bin/dmd
> > > and use it just where it is.
> >
> > dnormandin@ ~/programming/dmd2/osx/bin
> > 07:53 am>>  ./dmd ../../code/firstApp.d
> > ld warning: in /usr/local/gnat/lib/libgcc_s.10.5.dylib, missing
> > required architecture i386 in file
> > ld warning: in
> > /usr/local/gnat/lib/gcc/x86_64-apple-darwin9.6.0/4.3.4/libgcc.a, file
> > is not of required architecture
> >
> > Now what?
>
> What have you done with your developer tools installation ?? It doesn't
> install anything in /usr/local by default. And by default all libraries are
> universal binaries so you shouldn't have that problem.
>
> It seems you have installed a new gcc version and you haven't build it the
> Apple way, that is building with support for universal builds.

I simply followed the installation instructions on:

http://www.digitalmars.com/d/2.0/dmd-osx.html

I also installed the XCode plugin for D. Could _that_ have hosed my
install?
-- 
duke

Re: 64-bit support (Was: Poll: Primary D version)

[Jesse Phillips]

Andrei Alexandrescu wrote:

>
> I think at the end of the day we need a link that people can click on 
> and that's that. How can we make that work? Do we need a 64-bit .deb, or 
> is it possible to automatically instruct the package manager (in the 
> case of Ubuntu gdebi) to install it with dependencies and all?
>
> Andrei

Ubuntu (and family) is probably the only distro that you can expect
gdebi to be installed on. And the only way to have it install the proper
packages is to install a package with the required dependencies e.g. an
AMD64 package.

To really make many Linux users happy would be to provide a repository.
Even Google doesn't provide a one-click install for their programs (I
bring them up because they try very hard to be user friendly).

Re: To interface or not to interface

[Steven Schveighoffer]

On Tue, 25 May 2010 10:01:48 -0400, Jacob Carlborg  wrote:


On 2010-05-25 15.38, Steven Schveighoffer wrote:

On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg  wrote:


On 2010-05-24 21.08, Steven Schveighoffer wrote:


Don't user interface objects have data? If a UI component is an
interface, how does it expose access to its data? For example, a .NET
ListView control contains an Items property which you can use to  
access

the elements in the list view. The Items property returns a
ListViewItemCollection which implements IList, IContainer, and
IEnumerable. I've found these types of abstractions useful when
adding/iterating, etc.
-Steve



I would say that is a bad design, I would go with the MVC pattern. For
example, you have a ListView and when it's ready to display, say row
3, it calls your delegate and request you to return the item that
should be visible on row 3. Then it's up to you to store the items in
some appropriate data structure, like a list or array.


I don't know if a delegate is enough to implement the pattern. What you
need is a set of delegates that perform operations on the container. Oh
wait, that's an interface!


What I was trying to say is that a ListView should not contain a data  
structure. I try to explain that I want to say in code instead:


auto data = new Item[10];
auto listView = new ListView;
listView.numberOfRows = size_t delegate (ListView lv) {
return data.length;
}
listView.itemAtRow = Item delegate (ListView lv, size_t row) {
 return data[row];
}


Yes, I get that.  What I'm saying is this is basically an interface.  The  
difference is that the interface is not required to be declared on the  
container class, and requires 2 words of storage in the ListView per  
function instead of 1 word for all the functions.


Another way to do this is:

listView.items = data;

Where listView.items is an interface that contains the functions you  
need.  If the set of functions is complex, then using the delegates could  
be tedious.


It's just a different way of doing it.  There are benefits to both ways.   
Using the delegates is more flexible because a delegate does not need to  
be defined in a class with a predefined interface being implemented.  It's  
also much easier to build a bunch of delegates on the fly rather than  
build an interface implementation.


-Steve

Re: Installing D on MacOS X Leopard box

[Michel Fortin]

On 2010-05-25 09:19:01 -0400, Duke Normandin  said:


On Tue, 25 May 2010, Michel Fortin wrote:


If you want to avoid the hassle of installing things manually, you can also
use the D for Xcode installer which, in addition to installing a plugin for
Xcode, downloads and installs the latest version of DMD 1 and 2.




Have it already - thanks! However, _now_ I need a tutorial on how to
use XCode, cuz I've been using emacs forever. I dabbled in ObjC for
awhile, but never got anywhere with, because I spent most of my time
keeping XCode happy. I don't want that to happen with my D
experience. Do you know of a _real good_ XCode tutorial?


First, you don't *need* Xcode. The D for Xcode installer installs DMD 
so it is usable on the command line. You shouldn't have any problem 
using emacs, make, and whatever else you may like. If the 'dmd' command 
doesn't work after install, then it's probably something else outside 
of the DMD installation that is causing problems.


Second, most Xcode tutorials focus on Cocoa and writing GUI 
applications. I'm not sure what you want to know, but personally what I 
find quite useful to be aware of is how the build system works. If 
that's what you want to learn, perhaps this is what you should read:



--


Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Installing D on MacOS X Leopard box

[Jacob Carlborg]

On 2010-05-25 15.55, Duke Normandin wrote:

On Tue, 25 May 2010, Jacob Carlborg wrote:


On 2010-05-25 03.56, Duke Normandin wrote:

Hello list...

I'm new to D, but not programming. I've followed the instructions on

http://www.digitalmars.com/d/2.0/dmd-osx.html

However, I keep on getting this error:

dnormandin@ ~/programming/dmd2/code
04:38 pm>>   dmd -w firstApp.d
object.d: Error: module object is in file 'object.d' which cannot be
read
import path[0] = /etc/../../src/phobos
import path[1] = /etc/../../src/druntime/import

My guess is that dmd.conf is hosed somehow. I haven't edited the
default one - I've got it living in /etc/.


You can just unzip the zip file, add executable permission on dmd/osx/bin/dmd
and use it just where it is.


dnormandin@ ~/programming/dmd2/osx/bin
07:53 am>>  ./dmd ../../code/firstApp.d
ld warning: in /usr/local/gnat/lib/libgcc_s.10.5.dylib, missing
required architecture i386 in file
ld warning: in
/usr/local/gnat/lib/gcc/x86_64-apple-darwin9.6.0/4.3.4/libgcc.a, file
is not of required architecture

Now what?


What have you done with your developer tools installation ?? It doesn't 
install anything in /usr/local by default. And by default all libraries 
are universal binaries so you shouldn't have that problem.


It seems you have installed a new gcc version and you haven't build it 
the Apple way, that is building with support for universal builds.


--
/Jacob Carlborg

Re: To interface or not to interface

[Jacob Carlborg]

On 2010-05-25 15.38, Steven Schveighoffer wrote:

On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg  wrote:


On 2010-05-24 21.08, Steven Schveighoffer wrote:


Don't user interface objects have data? If a UI component is an
interface, how does it expose access to its data? For example, a .NET
ListView control contains an Items property which you can use to access
the elements in the list view. The Items property returns a
ListViewItemCollection which implements IList, IContainer, and
IEnumerable. I've found these types of abstractions useful when
adding/iterating, etc.
-Steve



I would say that is a bad design, I would go with the MVC pattern. For
example, you have a ListView and when it's ready to display, say row
3, it calls your delegate and request you to return the item that
should be visible on row 3. Then it's up to you to store the items in
some appropriate data structure, like a list or array.


I don't know if a delegate is enough to implement the pattern. What you
need is a set of delegates that perform operations on the container. Oh
wait, that's an interface!


What I was trying to say is that a ListView should not contain a data 
structure. I try to explain that I want to say in code instead:


auto data = new Item[10];
auto listView = new ListView;
listView.numberOfRows = size_t delegate (ListView lv) {
   return data.length;
}
listView.itemAtRow = Item delegate (ListView lv, size_t row) {
return data[row];
}

Now Item could be an interface but it don't have to be. I suggest you 
have a look at Apple's documentation of NSTableView:


* 
http://developer.apple.com/mac/library/documentation/Cocoa/Reference/ApplicationKit/Classes/NSTableView_Class/Reference/Reference.html 



* 
http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/TableView/Tasks/UsingTableDataSource.html#//apple_ref/doc/uid/2117



One interesting difference between an interface and a delegate is that
an interface is a single pointer, whereas a delegate is two. With the
context-pointer design, many more features are possible. For instance,
struct interfaces would be easy, as well as easily tacking on an
interface to a class.

In any case, Windows Forms is probably the easiest UI toolkit I've
worked with (which isn't saying much), I don't think it's a bad design.
That could be the Visual Studio talking though :)


I suggest you have a look at Cocoa, it uses the MVC pattern.


-Steve



--
/Jacob Carlborg

Re: Installing D on MacOS X Leopard box

[Duke Normandin]

On Tue, 25 May 2010, Jacob Carlborg wrote:

> On 2010-05-25 03.56, Duke Normandin wrote:
> > Hello list...
> >
> > I'm new to D, but not programming. I've followed the instructions on
> >
> > http://www.digitalmars.com/d/2.0/dmd-osx.html
> >
> > However, I keep on getting this error:
> >
> > dnormandin@ ~/programming/dmd2/code
> > 04:38 pm>>  dmd -w firstApp.d
> > object.d: Error: module object is in file 'object.d' which cannot be
> > read
> > import path[0] = /etc/../../src/phobos
> > import path[1] = /etc/../../src/druntime/import
> >
> > My guess is that dmd.conf is hosed somehow. I haven't edited the
> > default one - I've got it living in /etc/.
>
> You can just unzip the zip file, add executable permission on dmd/osx/bin/dmd
> and use it just where it is.

dnormandin@ ~/programming/dmd2/osx/bin
07:53 am >> ./dmd ../../code/firstApp.d
ld warning: in /usr/local/gnat/lib/libgcc_s.10.5.dylib, missing
required architecture i386 in file
ld warning: in
/usr/local/gnat/lib/gcc/x86_64-apple-darwin9.6.0/4.3.4/libgcc.a, file
is not of required architecture

Now what?
-- 
duke

Re: To interface or not to interface

[Jacob Carlborg]

On 2010-05-25 00.13, Walter Bright wrote:

Steven Schveighoffer wrote:

All an interface does is give an abstract representation of functions
that are *already there*. Removing the interface does not remove the
functions that implemented the interface.


Then why do interfaces need to be part of the collection component? Why
can't the user add them if he wants them?


How would the user do that? The user would need to create an interface 
and then a wrapper that implements the interface. An interface without 
implementations is useless. Or am I missing something ?


--
/Jacob Carlborg

Re: Installing D on MacOS X Leopard box

[Jacob Carlborg]

On 2010-05-25 03.56, Duke Normandin wrote:

Hello list...

I'm new to D, but not programming. I've followed the instructions on

http://www.digitalmars.com/d/2.0/dmd-osx.html

However, I keep on getting this error:

dnormandin@ ~/programming/dmd2/code
04:38 pm>>  dmd -w firstApp.d
object.d: Error: module object is in file 'object.d' which cannot be
read
import path[0] = /etc/../../src/phobos
import path[1] = /etc/../../src/druntime/import

My guess is that dmd.conf is hosed somehow. I haven't edited the
default one - I've got it living in /etc/.


You can just unzip the zip file, add executable permission on 
dmd/osx/bin/dmd and use it just where it is.


--
/Jacob Carlborg

Re: To interface or not to interface

[Steven Schveighoffer]

On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg  wrote:


On 2010-05-24 21.08, Steven Schveighoffer wrote:


Don't user interface objects have data? If a UI component is an
interface, how does it expose access to its data? For example, a .NET
ListView control contains an Items property which you can use to access
the elements in the list view. The Items property returns a
ListViewItemCollection which implements IList, IContainer, and
IEnumerable. I've found these types of abstractions useful when
adding/iterating, etc.
-Steve



I would say that is a bad design, I would go with the MVC pattern. For  
example, you have a ListView and when it's ready to display, say row 3,  
it calls your delegate and request you to return the item that should be  
visible on row 3. Then it's up to you to store the items in some  
appropriate data structure, like a list or array.


I don't know if a delegate is enough to implement the pattern.  What you  
need is a set of delegates that perform operations on the container.  Oh  
wait, that's an interface!


One interesting difference between an interface and a delegate is that an  
interface is a single pointer, whereas a delegate is two.  With the  
context-pointer design, many more features are possible.  For instance,  
struct interfaces would be easy, as well as easily tacking on an interface  
to a class.


In any case, Windows Forms is probably the easiest UI toolkit I've worked  
with (which isn't saying much), I don't think it's a bad design.  That  
could be the Visual Studio talking though :)


-Steve

Re: To interface or not to interface

[Jacob Carlborg]

On 2010-05-24 21.08, Steven Schveighoffer wrote:

On Mon, 24 May 2010 14:36:57 -0400, Walter Bright
 wrote:


Steven Schveighoffer wrote:

On Mon, 24 May 2010 14:10:26 -0400, Walter Bright
 wrote:


Steven Schveighoffer wrote:

I'd ask the naysayers of interfaces for dcollections, and also the
supporters: what is the point of having interfaces in D? Are
interfaces pretty much obsolete, and I am just nostalgic about
their utility?


Interfaces are for runtime polymorphism, rather than compile time
polymorphism. They are especially useful for things like:

1. runtime plugin interfaces
2. designs where strict implementation hiding is desired
3. to have binary libraries (shared and static)
4. to support Java/C# style coding
5. reduced code memory footprint
6. experience shows they are an excellent fit for user interfaces


Compile time polymorphism, such as what templates provide, are most
useful for:

1. maximum performance
2. minimal data memory consumption
3. better compile time checking


I believe the tradeoffs for collection types favor compile time
polymorphism because:

1. performance is often critical for collections
2. C++ STL has shown the success of this approach
3. collections must fit in naturally with ranges, and ranges are
compile time polymorphic

I'd counter point 2 by saying that 1. C++ classes are value-types by
default and 2. C++ doesn't have interfaces, so it's not exactly fair
to say that the STL author considered interfaces but rejected them.


C++ certainly does have interfaces. The whole COM system is based on
them, for example. Technically, D interfaces are just a subset of C++
multiple inheritance.


And if STL looked like COM, I think it would have been a miserable
failure indeed.




and on point 3, why is it not OK to *also* provide interfaces in
addition to ranges as dcollections does? That is, take away
dcollections' interfaces, and you have essentially compile-time
polymorphism, they all support ranges etc. Interfaces are also there
in case you want to use them in things like runtime plugin interfaces.


The best reason I can think of is to avoid kitchen-sink style
components. Components should do one thing well. Adding capability
should be done with aggregation by the user.


What if it can do both things well (I would propose that dcollections
does)?





Basically, my point is, compile time interfaces does not mean you
can't also have runtime interfaces. In fact, interfaces can be
compile-time parameterized.


Sure, but I'd argue that adding such runtime polymorphism should be
done with a separate add-on component. It should not be part of the
collection component.


So I should specifically have to wrap a collection type in order to make
it runtime polymorphic, forwarding all the operations to the collection?
Essentially something like:

class WrappedSet(Impl, V) : Set!V
{
Impl!V impl;

bool contains(V v) { return impl.contains(v);}
...
}

For what reason? Why is it so bad to just stick Set!V on the end of the
implementation class?





Also, much of a user interface consists of various collections
(listview, treeview, child widgets, etc.). Why is runtime
polymorphism good there, but not on a generic collections package
(not as the only means of access of course)?


A user interface object is not a collection component, I think there's
a confusion in the design there.


Don't user interface objects have data? If a UI component is an
interface, how does it expose access to its data? For example, a .NET
ListView control contains an Items property which you can use to access
the elements in the list view. The Items property returns a
ListViewItemCollection which implements IList, IContainer, and
IEnumerable. I've found these types of abstractions useful when
adding/iterating, etc.
-Steve



I would say that is a bad design, I would go with the MVC pattern. For 
example, you have a ListView and when it's ready to display, say row 3, 
it calls your delegate and request you to return the item that should be 
visible on row 3. Then it's up to you to store the items in some 
appropriate data structure, like a list or array.


--
/Jacob Carlborg

Re: 64-bit support (Was: Poll: Primary D version)

[Andrei Alexandrescu]

On 05/24/2010 08:03 PM, Jesse Phillips wrote:

Andrei Alexandrescu wrote:


On 05/24/2010 05:20 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

E.g. I can't install the .deb file on my 64-bit Linux.


I think the current .deb files can be.


Just tried again, same error message:

Error: Wrong architecture 'i386'

Let me know how I can help.


Andrei


DDebber will build packages for i386 and AMD64. The main difference is
that the AMD64 package will depended on the required ia32 libraries
which will not be pulled in with -force-architecture.

Just say'n

Ok, it still isn't that simple because if you don't have the required
packages then dmd will be left unconfigured since dpkg will not install
dependencies. # apt-get -f should fix this.


I think at the end of the day we need a link that people can click on 
and that's that. How can we make that work? Do we need a 64-bit .deb, or 
is it possible to automatically instruct the package manager (in the 
case of Ubuntu gdebi) to install it with dependencies and all?


Andrei

Re: To interface or not to interface

[Steven Schveighoffer]

On Mon, 24 May 2010 18:13:38 -0400, Walter Bright  
 wrote:



Steven Schveighoffer wrote:
All an interface does is give an abstract representation of functions  
that are *already there*.  Removing the interface does not remove the  
functions that implemented the interface.


Then why do interfaces need to be part of the collection component? Why  
can't the user add them if he wants them?


How do you add an interface to a class?  Wrapping seems like it would add  
more overhead than just implementing the interface, especially since D's  
inliner has some strange restrictions.


-Steve

Re: 64-bit support (Was: Poll: Primary D version)

[Andrei Alexandrescu]

On 05/24/2010 07:16 PM, eles wrote:

== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article

On 05/24/2010 05:20 PM, Walter Bright wrote:

Andrei Alexandrescu wrote:

E.g. I can't install the .deb file on my 64-bit Linux.


I think the current .deb files can be.

Just tried again, same error message:
Error: Wrong architecture 'i386'
Let me know how I can help.
Andrei


just type

sudo dpkg -i --force-architecture dmd_X.XXX-0_i386.deb

where dmd_X.XXX-0_i386.deb is the name of the .deb file


Thanks. Is there a way to make that directive automatic inside the .deb 
file?


Andrei

Re: Installing D on MacOS X Leopard box

[Duke Normandin]

On Tue, 25 May 2010, Michel Fortin wrote:

> On 2010-05-24 21:56:55 -0400, Duke Normandin  said:
>
> > Hello list...
> >
> > I'm new to D, but not programming. I've followed the instructions on
> >
> > http://www.digitalmars.com/d/2.0/dmd-osx.html
> >
> > However, I keep on getting this error:
> >
> > dnormandin@ ~/programming/dmd2/code
> > 04:38 pm >> dmd -w firstApp.d
> > object.d: Error: module object is in file 'object.d' which cannot be
> > read
> > import path[0] = /etc/../../src/phobos
> > import path[1] = /etc/../../src/druntime/import
> >
> > My guess is that dmd.conf is hosed somehow. I haven't edited the
> > default one - I've got it living in /etc/.
>
> If you want to avoid the hassle of installing things manually, you can also
> use the D for Xcode installer which, in addition to installing a plugin for
> Xcode, downloads and installs the latest version of DMD 1 and 2.
>
> 

Have it already - thanks! However, _now_ I need a tutorial on how to
use XCode, cuz I've been using emacs forever. I dabbled in ObjC for
awhile, but never got anywhere with, because I spent most of my time
keeping XCode happy. I don't want that to happen with my D
experience. Do you know of a _real good_ XCode tutorial?
-- 
Duke

Re: To interface or not to interface

[Steven Schveighoffer]

On Tue, 25 May 2010 09:03:34 -0400, Jason House  
 wrote:



Walter Bright Wrote:


Jason House wrote:
> 7. Compiler-assisted verification.

For interfaces, the compile time checking is limited to verifying that  
functions
with the right signature are supplied. Templates can go considerably  
beyond that

with the constraint checking.


constraints are more powerful, but they have downsides:
 • If a class is incorrectly defined, failure to use a type without a  
constraint check leads to errors in the code using it instead of the  
class definition. Usage isn't always guaranteed to be correct either, so  
the developer must spend extra time diagnosing the real error.
• If a class is incorrectly, initial usage without a constraint may  
completely miss the error. Easy examples would be a typo propogated with  
copy/paste, or neglecting to use save.
• If a class is incorrectly defined and usage uses a constraint, the  
developer will simply get an error that there is no matching call.
• If a constraint is incorrectly defined and usage uses the constraint,  
the developer will simply get an error that there is no matching call.


None of these scenarios are particularly helpful for a developer  
creating/expanding a family of objects.


These all boil down to the fact that you must declare an interface up  
front, whereas constraints are not required.


You can get to about the same level as an interface by using static  
asserts, but this is optional (it probably should be a "best practice"  
though somewhere).


-Steve

Re: 64-bit support (Was: Poll: Primary D version)

[Justin Johansson]

retard wrote:
The files inside the .zip won't run because one particular Mr. Bright 
doesn't set the +x flag on. It's not a fault of Linux if he is using 
retarded Windows version of the zip packager. It's easy to fix, he just 
doesn't care. The zip works just fine even on a 64-bit system if the 32-

bit libraries have been installed.


Hey retard, while I enjoy reading a lot of the controversy that you like 
to create on this NG, sorry, on this occasion I think you are being 
somewhat unfair towards one particular person here.


My understanding is that .zip files are traditionally a DOS (originally 
PKZIP) then come Windows thing then come Unix available.


http://en.wikipedia.org/wiki/ZIP_%28file_format%29

Being so, .zip files do not inherently/traditionally support recording 
Unix file permissions such as +x within the archive.  If such facilities 
exist today in Unix .zip utilities (and I am unaware of the same) these 
would have to be extensions over and above what .zip files are commonly 
understood to support given the DOS/PKZIP history of this file format.


Recording of Unix file permissions in archives is traditionally achieved 
with .tar files (and compressed variants) as I am sure you are well aware.


When downloading archive from the net, I look for .zip files if wanting 
to install on Windows and .tar or .tar.gz if wanting to install on 
Unixes.  I imagine that most Unix-aware folks would do the same.


In this instance I think you should be asking that archives be available 
in both .tar and .zip variants for the respective platforms and not 
accusing a certain somebody of being delinquent in not setting a +x flag 
on a file in a .zip file.


Cheers
Justin Johansson

Re: To interface or not to interface

[Jason House]

Walter Bright Wrote:

> Jason House wrote:
> > 7. Compiler-assisted verification.
> 
> For interfaces, the compile time checking is limited to verifying that 
> functions 
> with the right signature are supplied. Templates can go considerably beyond 
> that 
> with the constraint checking.

constraints are more powerful, but they have downsides:
 • If a class is incorrectly defined, failure to use a type without a 
constraint check leads to errors in the code using it instead of the class 
definition. Usage isn't always guaranteed to be correct either, so the 
developer must spend extra time diagnosing the real error.
• If a class is incorrectly, initial usage without a constraint may completely 
miss the error. Easy examples would be a typo propogated with copy/paste, or 
neglecting to use save.
• If a class is incorrectly defined and usage uses a constraint, the developer 
will simply get an error that there is no matching call.
• If a constraint is incorrectly defined and usage uses the constraint, the 
developer will simply get an error that there is no matching call.

None of these scenarios are particularly helpful for a developer 
creating/expanding a family of objects.

PS: The use of the word class above is for clarity instead of using type or 
object. I could have said struct as well.  

Re: Bug fix week

[Jacob Carlborg]

On 2010-05-24 16.17, Andrei Alexandrescu wrote:

On 05/24/2010 09:08 AM, Don wrote:

Andrei Alexandrescu wrote:

We've had a tremendous infusion of talent and energy in Phobos, and
lately work has picked up in unprecedented ways, both in terms of new
features and bug fixes. I can't say how happy I am about that!

At the end of this starting week, on Friday May 28, TDPL will be out
on trucks to bookstores.

Let's make this week a bug fixing week for both dmd and Phobos, and
issue a release on Monday. We're going public!


Andrei


IMHO, one of the most important bugs to fix is actually a spec bug:

4056 Template instantiation with bare parameter not documented

The foo!int syntax as a shortcut for foo!(int) isn't documented anywhere
in the spec!! This is an embarrassing omission and should be fixed ASAP.
Anyone could submit a patch with suggested wording for this one.


I agree that's bad, but somewhat ironically it's not as bad for TDPL's
timeline. The syntax _is_ documented in TDPL.

Andrei


I would say that's even worse, let me explain. In D if you run into a 
problem/bug with the compiler you never now where the problem is.


* Is it the spec that is correct and the compiler doesn't follow the spec?
* Is it the spec that is incorrect and the compiler behaves correctly?
* Perhaps the spec is correct and the compiler follows the spec but a 
feature is not implemented correctly?
* Perhaps the spec is correct but the compiler doesn't implement the 
feature yet.


Now when TDPL comes into the picture there is yet another layer to all 
this. Now you can have the behavior when TDPL is correct but the 
compiler and the spec is incorrect or any other combination of the now 
three parties.


--
/Jacob Carlborg

Re: Bug fix week

[Jason House]

Andrei Alexandrescu Wrote:

> We've had a tremendous infusion of talent and energy in Phobos, and 
> lately work has picked up in unprecedented ways, both in terms of new 
> features and bug fixes. I can't say how happy I am about that!
> 
> At the end of this starting week, on Friday May 28, TDPL will be out on 
> trucks to bookstores.
> 
> Let's make this week a bug fixing week for both dmd and Phobos, and 
> issue a release on Monday. We're going public!
> 
> 
> Andrei

I don't have the time right now to do proper bugzilla entries, but in the 
interest of time, I'm posting them here. I'm not at a computer, and my dmd 
install is a recent beta, etc...

I noticed that if I compile code that lacks a main function, I get something on 
the order of 8 error messages. Most of which would be meaningless to someone 
writing a hello world app.

The other thing I noticed is more obscure. unaryFunc does not seem to support 
void return types when using a string alias. For example "x[a] = foo(a)".  
Creating a nested function seems to get around the problem.

Re: Installing D on MacOS X Leopard box

[Michel Fortin]

On 2010-05-24 21:56:55 -0400, Duke Normandin  said:


Hello list...

I'm new to D, but not programming. I've followed the instructions on

http://www.digitalmars.com/d/2.0/dmd-osx.html

However, I keep on getting this error:

dnormandin@ ~/programming/dmd2/code
04:38 pm >> dmd -w firstApp.d
object.d: Error: module object is in file 'object.d' which cannot be
read
import path[0] = /etc/../../src/phobos
import path[1] = /etc/../../src/druntime/import

My guess is that dmd.conf is hosed somehow. I haven't edited the
default one - I've got it living in /etc/.


If you want to avoid the hassle of installing things manually, you can 
also use the D for Xcode installer which, in addition to installing a 
plugin for Xcode, downloads and installs the latest version of DMD 1 
and 2.




--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Installing D on MacOS X Leopard box

[Duke Normandin]

On Tue, 25 May 2010, Nick Sabalausky wrote:

> "Duke Normandin"  wrote in message
> news:mailman.43.1274754397.24349.digitalmar...@puremagic.com...
> > Hello list...
> >
> > I'm new to D, but not programming.
>
> Welcome to D :)

Thank you!

> > I've followed the instructions on
> >
> > http://www.digitalmars.com/d/2.0/dmd-osx.html
> >
> > However, I keep on getting this error:
> >
> > dnormandin@ ~/programming/dmd2/code
> > 04:38 pm >> dmd -w firstApp.d
> > object.d: Error: module object is in file 'object.d' which cannot be
> > read
> > import path[0] = /etc/../../src/phobos
> > import path[1] = /etc/../../src/druntime/import
> >
> > My guess is that dmd.conf is hosed somehow. I haven't edited the
> > default one - I've got it living in /etc/.
> > --
> > Duke
>
> Looks like those instructions need to be fixed.

I'm glad that in my noobiness, I've been able to contribute
_something_ ;)

> The file dmd.conf is expecting to live in the same directory as the DMD
> executable (ie, "{wherever you unzipped DMD}/osx/bin/" ). Deleting it out of
> /etc/ should work. Or, if you really wanted, you could edit it (it's a
> pretty simple text file) and change the paths to point to the right places
> (Just replace "%...@p%" with ""{wherever you unzipped DMD}/osx/bin/")

Kinda thought so - but thought I'd ask first, _before_ I started
hacking and chopping.

> BTW, these sorts of things are probably best asked over in
> "digitalmars.D.learn".

Thanks for the heads-up!
-- 
Duke

Re: To interface or not to interface

[Steven Schveighoffer]

On Tue, 25 May 2010 02:26:02 -0400, Kagamin  wrote:


Recently I've hit a problem with collections in C#. Given classes
class A {}
class B {}
And two collections Collection and Collection it's possible to  
concat them into an array A[]. The efficient way to do it is to use  
CopyTo(T[],int) method, but it accepts only array of exact collection  
item's type, so I had to change the Collection type to Collection.


Did you mean

class B : A {} ?

According to this page, it says that an exception could be thrown if "Type  
T cannot be cast automatically to the type of the destination array."   
This implies that a destination array type to which T could automatically  
be cast should work.


http://msdn.microsoft.com/en-us/library/0efx51xw%28v=VS.100%29.aspx

But the larger point that compile-time code generation can help with this  
is valid.


-Steve

Re: Poll: Primary D version

[retard]

Sun, 23 May 2010 04:14:30 -0400, bearophile wrote:

> Walter Bright:
>> Doing it in an automated way
>> requires whole program analysis, something not entirely practical in a
>> language designed to support separate compilation.
> 
> Compiling programs of a dynamic language like Lua was seen as hopelessly
> inefficient. But today programs running on the the Lua JIT are often
> faster than equivalent FP-heavy D programs compiled with DMD. So it's
> all in having a positive attitude toward technological problems: if the
> need to do something grows strong enough, people usually find a way to
> do it :-)

I don't think the D community is really interested in hearing something 
positive about dynamically typed non-native languages. Traditionally 
that's the best way to wreck your efficiency and it's tough to admit that 
those languages are now better. The traditional native code way is to use 
primitive compilers and brute force via inline asm.

Re: 64-bit support (Was: Poll: Primary D version)

[retard]

Mon, 24 May 2010 17:45:01 +, dsimcha wrote:

> == Quote from Leandro Lucarella (llu...@gmail.com)'s article
>> dsimcha, el 24 de mayo a las 13:05 me escribiste:
>> > == Quote from Bruno Medeiros (brunodomedeiros+s...@com.gmail)'s
>> > article
>> > > On 23/05/2010 01:45, Walter Bright wrote:
>> > > > Walter Bright wrote:
>> > > >
>> > > > Other toolchain problems are things like shared libraries,
>> > > > installation, bugzilla bugs, etc.
>> > > Installation? What kind of problems are those?
>> >
>> > On Linux, DMD can be a PITA to install if you're using an ancient
>> > distribution due to glibc being a different version than what DMD
>> > expects.  I use such a machine and the only way to get DMD to work is
>> > to compile from source.
>> BTW, distributing a huge .zip with the binaries for all platforms is
>> not ideal either. In Linux you have to make the binaries executables.
>> The only straighforward option for Linux is the .deb, but it's only
>> straightforward for Ubuntu 32-bits, anything else needs some
>> (non-trivial) work.
> 
> If packaging nightmares like this don't explain why Linux hasn't
> succeeded on the desktop, then nothing will.

The files inside the .zip won't run because one particular Mr. Bright 
doesn't set the +x flag on. It's not a fault of Linux if he is using 
retarded Windows version of the zip packager. It's easy to fix, he just 
doesn't care. The zip works just fine even on a 64-bit system if the 32-
bit libraries have been installed.

The Microsoft installer stuff doesn't work well either. Try running 64-
bit installers on a 32-bit Windows system or the latest .NET 
expecting .msi files on Windows 95/98/ME or Windows NT4/2000.. now how 
does it handle package dependencies - the answer is it doesn't.

A 32-bit .deb works in most (if not all) 32-bit Debian derivatives unless 
the package is expecting some Ubuntu related configuration. Your solution 
seems to be: "because it's too complex to build packages for every 
distro, don't provide anything". Yay, nothing works.

Re: Installing D on MacOS X Leopard box

[Nick Sabalausky]

"Duke Normandin"  wrote in message 
news:mailman.43.1274754397.24349.digitalmar...@puremagic.com...
> Hello list...
>
> I'm new to D, but not programming.

Welcome to D :)

> I've followed the instructions on
>
> http://www.digitalmars.com/d/2.0/dmd-osx.html
>
> However, I keep on getting this error:
>
> dnormandin@ ~/programming/dmd2/code
> 04:38 pm >> dmd -w firstApp.d
> object.d: Error: module object is in file 'object.d' which cannot be
> read
> import path[0] = /etc/../../src/phobos
> import path[1] = /etc/../../src/druntime/import
>
> My guess is that dmd.conf is hosed somehow. I haven't edited the
> default one - I've got it living in /etc/.
> -- 
> Duke

Looks like those instructions need to be fixed.

The file dmd.conf is expecting to live in the same directory as the DMD 
executable (ie, "{wherever you unzipped DMD}/osx/bin/" ). Deleting it out of 
/etc/ should work. Or, if you really wanted, you could edit it (it's a 
pretty simple text file) and change the paths to point to the right places 
(Just replace "%...@p%" with ""{wherever you unzipped DMD}/osx/bin/")

BTW, these sorts of things are probably best asked over in 
"digitalmars.D.learn".