Re: Bug fix week
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: SHOO's time code
On Wed, 19 May 2010 06:45:42 -0400, Steven Schveighoffer wrote: On Tue, 18 May 2010 14:10:05 -0400, Moritz Warning moritzwarn...@web.de wrote: On Tue, 18 May 2010 14:24:40 +, superdan wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Tue, 18 May 2010 09:39:12 -0400, superdan su...@dan.org wrote: guys go with boost and std.gregorian n shit. sorry shoo. tango is a fucking boat anchor for d. shit. Having written most of the API for tango.time, I sorta like it :) I really like the API that SHOO came up with based on it. If there's any way to get SHOO's code into Phobos, I want to pursue that first. If this fails, we can go with boost. -Steve i feel ya bro. i once sorta liked a hoe with herpes. way i c it is simple. it's fucking dates and fucking times. wut the fuck. ain't a fucking operating system. no matter how u dress a pig u still call it a fucking pig. if u have da datetime functionality it don't matter to be cute. we is wasting time sucking lars douche's cock 2 give us permission 2 his fucking shit. fuck that shit. dis must be da least amount of power that got to some idiot's head. Wut? Person A wrote some code and had a look at code from person B. Now person C says that A need to get permission from B so that C can use the code from A. The reason is because the license of the code written by B isn't quite compatible with the license recently chosen by C. And now you are calling B an idiot/douche for that reason? Let's make it a bit clearer. Person A *used* the code from person B, and used the *documentation* of said code to write his own similar library. Person A has not claimed that he looked at the source. I agree, that's more accurate. Person B claims that it is impossible to do so without actually looking at the source, but has not yet cited any specific copying. Person C doesn't want any trouble, and just is being extra careful. Afaik, Person B haven't looked at the source in question but relied on what others said. I think it was a move forward in anticipation to Person Cs license sensibility. Anyway, Person B haven't hesitated when asked to give permission himself. I don't really like the situation, but if this is the way it has to be, then let's get it done and move on. right :) -Steve
Re: SHOO's time code
On 2010-05-14 00:52, Moritz Warning wrote: I have asked Kris Bell and Matti Niemenmaa. No Problem at all. Since this evidently needs confirming: I'm fine with relicensing any of my contributions to the tango.time modules under the Boost Software License, Version 1.0. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Re: To interface or not to interface
Recently I've hit a problem with collections in C#. Given classes
class A {}
class B {}
And two collections CollectionA and CollectionB 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 CollectionB type to CollectionA.
Re: Installing D on MacOS X Leopard box
Duke Normandin dukeofp...@ml1.net 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.
Re: 64-bit support (Was: Poll: Primary D version)
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: Poll: Primary D version
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: To interface or not to interface
On Tue, 25 May 2010 02:26:02 -0400, Kagamin s...@here.lot wrote:
Recently I've hit a problem with collections in C#. Given classes
class A {}
class B {}
And two collections CollectionA and CollectionB 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 CollectionB type to CollectionA.
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: Installing D on MacOS X Leopard box
On Tue, 25 May 2010, Nick Sabalausky wrote:
Duke Normandin dukeofp...@ml1.net 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: Installing D on MacOS X Leopard box
On 2010-05-24 21:56:55 -0400, Duke Normandin dukeofp...@ml1.net 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. http://michelf.com/projects/d-for-xcode/ -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Bug fix week
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: Bug fix week
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: To interface or not to interface
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: 64-bit support (Was: Poll: Primary D version)
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
On Tue, 25 May 2010 09:03:34 -0400, Jason House jason.james.ho...@gmail.com 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: Installing D on MacOS X Leopard box
On Tue, 25 May 2010, Michel Fortin wrote: On 2010-05-24 21:56:55 -0400, Duke Normandin dukeofp...@ml1.net 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. http://michelf.com/projects/d-for-xcode/ 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: 64-bit support (Was: Poll: Primary D version)
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: To interface or not to interface
On Mon, 24 May 2010 18:13:38 -0400, Walter Bright newshou...@digitalmars.com 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)
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
On 2010-05-24 21.08, Steven Schveighoffer wrote:
On Mon, 24 May 2010 14:36:57 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Steven Schveighoffer wrote:
On Mon, 24 May 2010 14:10:26 -0400, Walter Bright
newshou...@digitalmars.com 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: Installing D on MacOS X Leopard box
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
On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg d...@me.com 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
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
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
On 2010-05-25 15.38, Steven Schveighoffer wrote:
On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg d...@me.com 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
On 2010-05-25 09:19:01 -0400, Duke Normandin dukeofp...@ml1.net 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. http://michelf.com/projects/d-for-xcode/ 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: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/XcodeBuildSystem/ -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Installing D on MacOS X Leopard box
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
On Tue, 25 May 2010 10:01:48 -0400, Jacob Carlborg d...@me.com wrote:
On 2010-05-25 15.38, Steven Schveighoffer wrote:
On Tue, 25 May 2010 09:26:20 -0400, Jacob Carlborg d...@me.com 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: 64-bit support (Was: Poll: Primary D version)
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: Installing D on MacOS X Leopard box
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)
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
On Tue, 25 May 2010, Michel Fortin wrote: On 2010-05-25 09:19:01 -0400, Duke Normandin dukeofp...@ml1.net 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. http://michelf.com/projects/d-for-xcode/ 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: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/XcodeBuildSystem/ That URL is exactly what I've been looking for. Thanks. -- duke
Re: Installing D on MacOS X Leopard box
On 2010-05-25 10:30:44 -0400, Duke Normandin dukeofp...@ml1.net 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: To interface or not to interface
On 2010-05-25 10:01:48 -0400, Jacob Carlborg d...@me.com 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
On Tue, 25 May 2010, Michel Fortin wrote: On 2010-05-25 10:30:44 -0400, Duke Normandin dukeofp...@ml1.net 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: Poll: Primary D version
On Sun, May 23, 2010 at 1:14 AM, bearophile bearophileh...@lycos.com 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: 64-bit support (Was: Poll: Primary D version)
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: 64-bit support (Was: Poll: Primary D version)
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)
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: Poll: Primary D version
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: Poll: Primary D version
On Tue, May 25, 2010 at 12:11 PM, bearophile bearophileh...@lycos.com 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=alllang=luajitlang2=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
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
On Tue, May 25, 2010 at 12:45 PM, Bill Baxter wbax...@gmail.com wrote: On Tue, May 25, 2010 at 12:11 PM, bearophile bearophileh...@lycos.com 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=alllang=luajitlang2=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
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.
container stuff
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: container stuff
On Tue, 25 May 2010 18:27:32 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org 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
Re: container stuff
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: 64-bit support (Was: Poll: Primary D version)
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: Poll: Primary D version
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: container stuff
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: container stuff
On 05/25/2010 06:04 PM, Steven Schveighoffer wrote: On Tue, 25 May 2010 18:27:32 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org 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
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
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 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
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
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 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
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
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
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: To interface or not to interface
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: To interface or not to interface
Steven Schveighoffer wrote: On Mon, 24 May 2010 18:13:38 -0400, Walter Bright newshou...@digitalmars.com 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: 64-bit support (Was: Poll: Primary D version)
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: container stuff
Andrei Alexandrescu Wrote: On 05/25/2010 06:04 PM, Steven Schveighoffer wrote: On Tue, 25 May 2010 18:27:32 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org 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: Installing D on MacOS X
On Tue, 25 May 2010 09:50:52 -0400, Duke Normandin dukeofp...@ml1.net wrote: Hey... 2 hours into my D language experience Got some instructions from th digitalmars-d list for getting D installed on my Intel OS X box. Still having problems: dnormandin@ ~/programming/dmd2/code 06:40 am dmd 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 ld: can't open output file for writing: firstApp, errno=21 collect2: ld returned 1 exit status --- errorlevel 1 First of all, if there are any D language developers tuned in, how about getting a $%^* makefile happening to install _all_ language-related stuff where it's suppose to go? Anyway, what's the problem _now_, given the above error message? I'll preface this by saying I am not and have never really been a MAC user, but I have a lot of experience on Linux. Could it be that you have a 64-bit MacOS and the 32-bit compatible libraries aren't installed? I'm not sure how mac works, but i386 is a 32-bit architecture, and it looks like your linking with files named x86_64. dmd is a 32-bit only compiler for now. Again, no idea how to do this on a Mac. -Steve
Re: Installing D on MacOS X
On 05/25/2010 08:50 AM, Duke Normandin wrote: Hey... 2 hours into my D language experience Got some instructions from th digitalmars-d list for getting D installed on my Intel OS X box. Still having problems: dnormandin@ ~/programming/dmd2/code 06:40 am dmd 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 ld: can't open output file for writing: firstApp, errno=21 collect2: ld returned 1 exit status --- errorlevel 1 First of all, if there are any D language developers tuned in, how about getting a $%^* makefile happening to install _all_ language-related stuff where it's suppose to go? It's the first time I've read those instructions, but I find them highly suspect. You shouldn't need to copy anything outside the folders from the zip file. Anyway, what's the problem _now_, given the above error message?
[Issue 4232] New: Local struct member variable can be returned by ref
http://d.puremagic.com/issues/show_bug.cgi?id=4232
Summary: Local struct member variable can be returned by ref
Product: D
Version: 2.041
Platform: x86
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro rsi...@gmail.com 2010-05-24 23:21:52 PDT
---
Using struct members bypasses the compiler check for escaping reference to
local variables.
This code should not compile:
struct S { int a; }
ref int test()
{
S s;
s.a = 42;
return s.a;
}
void main()
{
auto p = test(); // reference to the local variable
assert(test() == 42); // assertion fails with -O
}
Moreover, test() in the above example returnes a corrupted (or uninitialized)
value when optimization is on. This causes unittests for
std.functional.toDelegate() to segfault.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001
--- Comment #19 from Brad Roberts bra...@puremagic.com 2010-05-25 00:15:31
PDT ---
Sean, any objection to me submitting this minor diff:
Index: src/object_.d
===
--- src/object_.d (revision 296)
+++ src/object_.d (working copy)
@@ -1189,6 +1189,13 @@
traceHandler = h;
}
+/**
+ * Return the current trace handler
+ */
+extern (C) TraceHandler rt_getTraceHandler()
+{
+return traceHandler;
+}
/**
* This function will be called when an exception is constructed. The
Index: src/core/runtime.d
===
--- src/core/runtime.d (revision 296)
+++ src/core/runtime.d (working copy)
@@ -23,6 +23,7 @@
extern (C) void rt_setCollectHandler( CollectHandler h );
extern (C) void rt_setTraceHandler( TraceHandler h );
+extern (C) TraceHandler rt_getTraceHandler();
alias void delegate( Throwable ) ExceptionHandler;
extern (C) bool rt_init( ExceptionHandler dg = null );
@@ -172,6 +173,13 @@
rt_setTraceHandler( h );
}
+/**
+ * Return the current trace handler
+ */
+static TraceHandler traceHandler()
+{
+return rt_getTraceHandler();
+}
/**
* Overrides the default collect hander with a user-supplied version.
This
This would enable code like this:
auto oldTH = Runtime.traceHandler;
Runtime.traceHandler = null;
scope(exit) Runtime.traceHandler = oldTH;
I ran across this 'need' while working on the dmd test suite that is checking
some object throwing results, specifically two asserts like this:
Object e = new Exception(hello);
assert(e.toString() == object.Exception: hello);
assert(format(e) == object.Exception: hello);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2127] inliner turns struct return *this from by-value into by-ref (D1 only)
http://d.puremagic.com/issues/show_bug.cgi?id=2127 --- Comment #1 from Brad Roberts bra...@puremagic.com 2010-05-25 01:59:48 PDT --- Created an attachment (id=642) tentative fix for this for the d2 branch (might work on d1 as well, untested) This bug exists in the d2 code base as well. This patch fixes the test case and passes the test suite. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2127] inliner turns struct return *this from by-value into by-ref (D1 only)
http://d.puremagic.com/issues/show_bug.cgi?id=2127 Brad Roberts bra...@puremagic.com changed: What|Removed |Added Attachment #642 is|0 |1 obsolete|| --- Comment #2 from Brad Roberts bra...@puremagic.com 2010-05-25 03:05:16 PDT --- Created an attachment (id=643) d2 fix, version 2 Oops.. the version I attached previously was an older copy. This is the newer version that moves the changes down from FuncDeclaration::inlineScan to doInline and fixes a problem with the first version. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3909] toDelegate handles only a tiny subset of function pointer types
http://d.puremagic.com/issues/show_bug.cgi?id=3909
David Simcha dsim...@yahoo.com changed:
What|Removed |Added
CC||dsim...@yahoo.com
Depends on||1818
--- Comment #2 from David Simcha dsim...@yahoo.com 2010-05-25 06:29:49 PDT ---
I just noticed this report now. Really, the reason this code is so poorly
designed (I wrote it, and I'll admit in hindsight that it does suck) is bug
1818. The stupid mixin hack was a last-minute workaround for this bug and
wasn't thought through properly. This is noted in the comments:
functional.d around line 550:
// Workaround for DMD Bug 1818.
mixin(alias ~ ReturnType!(F).stringof ~
delegate ~ ParameterTypeTuple!(F).stringof ~ DelType;);
version(none) {
// What the code would be if it weren't for bug 1818:
alias ReturnType!(F) delegate(ParameterTypeTuple!(F)) DelType;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3909] toDelegate handles only a tiny subset of function pointer types
http://d.puremagic.com/issues/show_bug.cgi?id=3909
--- Comment #3 from Max Samukha samu...@voliacable.com 2010-05-25 08:12:12
PDT ---
(In reply to comment #2)
I just noticed this report now. Really, the reason this code is so poorly
designed (I wrote it, and I'll admit in hindsight that it does suck) is bug
1818. The stupid mixin hack was a last-minute workaround for this bug and
wasn't thought through properly. This is noted in the comments:
functional.d around line 550:
// Workaround for DMD Bug 1818.
mixin(alias ~ ReturnType!(F).stringof ~
delegate ~ ParameterTypeTuple!(F).stringof ~ DelType;);
version(none) {
// What the code would be if it weren't for bug 1818:
alias ReturnType!(F) delegate(ParameterTypeTuple!(F)) DelType;
}
Phobos has recently acquired functionality for extracting storage classes from
functions and function parameters. I haven't given it a close look but it seems
to do that by parsing mangled names. Hacky but should make it possible to
correctly generate function types based on other function types.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4233] New: Eponymous template template members inaccessible
http://d.puremagic.com/issues/show_bug.cgi?id=4233
Summary: Eponymous template template members inaccessible
Product: D
Version: 2.041
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas simen.kja...@gmail.com 2010-05-25 09:23:24
PDT ---
template foo( T ) {
template foo( U ) {
enum foo = is( U == T );
}
}
static assert( foo!( int )!( int ) );
The above code does not compile, complaining that the ! should not be there.
Ok, so I use a FQN:
static assert( foo!( int ).foo!( int ) );
Error: undefined identifier template foo(U).foo
So apparently, there is no way to get access to the inner foo.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1886] Inserting into an AA of structs with opAssign results in ArrayBoundsError
http://d.puremagic.com/issues/show_bug.cgi?id=1886 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #5 from Don clugd...@yahoo.com.au 2010-05-25 13:27:52 PDT --- Duplicate of bug 2451. However there is some useful information in the comments for this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4233] Eponymous template template members inaccessible
http://d.puremagic.com/issues/show_bug.cgi?id=4233 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #1 from Don clugd...@yahoo.com.au 2010-05-25 13:33:59 PDT --- This is yet another duplicate of the oldest open DMD enhancement in Bugzilla. It's probably worth voting for bug 242. *** This issue has been marked as a duplicate of issue 242 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 242] template implicit template properties doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=242 --- Comment #4 from Don clugd...@yahoo.com.au 2010-05-25 13:33:59 PDT --- *** Issue 4233 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4169] building dmd with a modern gcc produces a buggy compiler
http://d.puremagic.com/issues/show_bug.cgi?id=4169 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2010-05-25 15:09:04 PDT --- http://www.dsource.org/projects/dmd/changeset/501 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
http://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #20 from Sean Kelly s...@invisibleduck.org 2010-05-25 15:18:01 PDT --- Not at all. We should really make all of the Runtime properties get/settable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4234] New: Cannot create a std.socket.Socket from an fd
http://d.puremagic.com/issues/show_bug.cgi?id=4234 Summary: Cannot create a std.socket.Socket from an fd Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: mike.casingh...@gmail.com --- Comment #0 from mike.casingh...@gmail.com 2010-05-25 20:22:40 PDT --- I have a socket fd that is set up for communicating with my parent process, and I need to talk to it. Socket.sock is declared private, and there's no way to access it. Maybe just make it protected or something? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4169] building dmd with a modern gcc produces a buggy compiler
http://d.puremagic.com/issues/show_bug.cgi?id=4169
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Comment #5 from Brad Roberts bra...@puremagic.com 2010-05-25 20:55:50 PDT
---
Looks like you missed one file's changes:
diff --git a/src/mtype.c b/src/mtype.c
--- a/src/mtype.c
+++ b/src/mtype.c
@@ -2832,14 +2832,17 @@ Expression *TypeBasic::defaultInit(Loc loc)
* so that uninitialised variables can be
* detected even if exceptions are disabled.
*/
-unsigned short snan[8] = { 0, 0, 0, 0xA000, 0x7FFF };
+union {
+unsigned short us[8];
+long doubleld;
+} snan = {{ 0, 0, 0, 0xA000, 0x7FFF }};
/*
* Although long doubles are 10 bytes long, some
* C ABIs pad them out to 12 or even 16 bytes, so
* leave enough space in the snan array.
*/
assert(REALSIZE = sizeof(snan));
-d_float80 fvalue = *(long double*)snan;
+d_float80 fvalue = snan.ld;
#endif
#if LOGDEFAULTINIT
The rest of the compiler builds w/o aliasing warnings on my box from tip of svn
now.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
