www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mac OSX installer for dmd

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hello,


I got an email from someone who got an interest in D following my talk 
at Google. He tried to install dmd on OSX, but got turned off (and 
rightly so) for the unnecessary difficulties of that process and the 
lack of documentation. Nicely of him he took the time to write me and 
detail his experience. Following that, Walter managed to fix the most 
egregious documentation errors.

Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is 
someone able and willing to own this project? I think improving the 
out-of-the-box experience is important and urgent.


Andrei

P.S. My talk at Google went, I think, reasonably well. It could've gone 
a whole lot better; I neglected to make a couple of points. The talk was 
recorded and, I was told, the recording will be on YouTube some time 
next week. My mentions of Python and Haskell will probably get me 
mortified in certain circles.
Aug 01 2010
next sibling parent reply Ryan W Sims <rwsims gmail.com> writes:
On 8/1/10 5:07 PM, Andrei Alexandrescu wrote:
 Hello,

 I got an email from someone who got an interest in D following my talk
 at Google. He tried to install dmd on OSX, but got turned off (and
 rightly so) for the unnecessary difficulties of that process and the
 lack of documentation. Nicely of him he took the time to write me and
 detail his experience. Following that, Walter managed to fix the most
 egregious documentation errors.

Are those fixes reflected anywhere on the site? I found the process to be a little clumsy, but not hideous; I would be very interested to see what's changed, though. [Possibly OT?] The only real trouble I ran into is this: $ ./rdmd dyld: unknown required load command 0x80000022 Trace/BPT trap
 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
 someone able and willing to own this project? I think improving the
 out-of-the-box experience is important and urgent.

I don't know that a simple .dmg file is the right way to go, since you need to get some binaries onto the user's path. I think it'd have to be a .mpkg package IIRC (which are, admittedly, distributed in a .dmg files) I don't have much experience with packaging for OSX, but if there are not more experienced folks willing to take it on, I'm willing to take this on: would love to help, but sadly I don't have the compiler chops to make a more significant contribution.
 Andrei

 P.S. My talk at Google went, I think, reasonably well. It could've gone
 a whole lot better; I neglected to make a couple of points. The talk was
 recorded and, I was told, the recording will be on YouTube some time
 next week. My mentions of Python and Haskell will probably get me
 mortified in certain circles.

[OT] I thought it went well myself, but I might be something of an easy mark. Which points did you miss?
Aug 01 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Ryan W Sims wrote:
 On 8/1/10 5:07 PM, Andrei Alexandrescu wrote:
 I got an email from someone who got an interest in D following my talk
 at Google. He tried to install dmd on OSX, but got turned off (and
 rightly so) for the unnecessary difficulties of that process and the
 lack of documentation. Nicely of him he took the time to write me and
 detail his experience. Following that, Walter managed to fix the most
 egregious documentation errors.

Are those fixes reflected anywhere on the site?

Here's what I sent the guy: ====================================== 1. I put up a new download, http://ftp.digitalmars.com/dmd.2.047.zip All that's different is it adds the file: dmd2/osx/bin/dmdx.conf and adds a revised license file: dmd2/license.txt which hopefully will make things clearer. 2. I revised the installation instructions: http://www.digitalmars.com/d/2.0/dmd-osx.html which now also include instructions for building dmd and the runtime library. If things still fail for you, please let me know. ======================================== If these changes improve things, I'll fold them into D1 as well.
Aug 01 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/01/2010 07:22 PM, Ryan W Sims wrote:
 On 8/1/10 5:07 PM, Andrei Alexandrescu wrote:
 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
 someone able and willing to own this project? I think improving the
 out-of-the-box experience is important and urgent.

I don't know that a simple .dmg file is the right way to go, since you need to get some binaries onto the user's path. I think it'd have to be a .mpkg package IIRC (which are, admittedly, distributed in a .dmg files)

You're already way ahead of me. When I said .dmg, I'd already expounded 90% of my knowledge of OSX installers.
 I don't have much experience with packaging for OSX, but if there are
 not more experienced folks willing to take it on, I'm willing to take
 this on: would love to help, but sadly I don't have the compiler chops
 to make a more significant contribution.

Thanks, that would be terrific. To frame the problem more precisely, I think a shell script that takes a .zip file containing the installation and doing what it takes to build a .mpkg would be perfect.
 Andrei

 P.S. My talk at Google went, I think, reasonably well. It could've gone
 a whole lot better; I neglected to make a couple of points. The talk was
 recorded and, I was told, the recording will be on YouTube some time
 next week. My mentions of Python and Haskell will probably get me
 mortified in certain circles.

[OT] I thought it went well myself, but I might be something of an easy mark. Which points did you miss?

Thanks for being there! I had this example in my slides (repro from memory): import std.exception, std.file; void main(string[] args) { enforce(args.length == 3, "Usage: tcopy file1 file2"); auto tmp = args[2] ~ ".messedup"; scope(failure) if exists(tmp) remove(tmp); copy(args[1], tmp); rename(tmp, args[2]); } It's a simple transactional copy program that never leaves the fragment of its target on the disk (rename is atomic on all Unixen and most likely Windows too). It's a very annoying problem with large files copied via network connections, I've been using such an idiom for years. A couple of people got rightly worried that the script uses names such as copy, rename, and remove. Such names are highly susceptible to be ambiguous when more imports are used. I explained how D works (which I think is a very solid design, probably the best I've seen), but the nagging issue remained that changes to a library could make a call ambiguous to a function in another. I personally think that's all well but it's a matter in which reasonable people may disagree. What I forgot to mention is static import, which would have quenched that question perfectly. Andrei
Aug 01 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 I explained how D works (which I 
 think is a very solid design, probably the best I've seen),

The D module system has some holes, most of them are already reported in Bugzilla (some of them are more than just implementation bugs). From your words I presume you have never seen the Python module system :-) It lacks the holes present in the D one and its management of packages is almost good. Bye, bearophile
Aug 01 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/01/2010 08:16 PM, bearophile wrote:
 Andrei Alexandrescu:
 I explained how D works (which I
 think is a very solid design, probably the best I've seen),

The D module system has some holes, most of them are already reported in Bugzilla (some of them are more than just implementation bugs).

I'm referring to the design more than the implementation.
  From your words I presume you have never seen the Python module system :-) It
lacks the holes present in the D one and its management of packages is almost
good.

I agree that Python's module system is very solid. Andrei
Aug 01 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello bearophile,

 Andrei Alexandrescu:
 
 I explained how D works (which I think is a very solid design,
 probably the best I've seen),
 

in Bugzilla (some of them are more than just implementation bugs). From your words I presume you have never seen the Python module system :-) It lacks the holes present in the D one and its management of packages is almost good.

With aliases and static/selective imports what can python do that D can't? I'll grant it might not be as clean, but everything I know of that python can do, I can think how to make D do. OTOH I'm no Python experts so I'd love to learn of some new nice features I can use. -- ... <IXOYE><
Aug 01 2010
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Andrei Alexandrescu:
 I explained how D works (which I
 think is a very solid design, probably the best I've seen),


 From your words I presume you have never seen the Python module system :-) It

 Bye,
 bearophile

Python is my language of second choice for things where D just isn't the right tool for the job. This basically means anything where efficiency and static checkability don't count much but either dynamicness or mainstreamness/maturity/support counts a lot. There's a lot that's good about the language. That said, I think D's module system is much better. Python's module system suffers from one huge wart that makes me hate it no matter how good it is otherwise: There's no way to import a module such that you don't have to use qualified names, **but** when there's a collision the behavior is reasonable and avoids hijacking. I absolutely despise using qualified names because they are both syntactic noise and extra typing. D lets me just import tons of stuff and skip the qualified names in most cases. Most of the time it does what I mean, and it complains if and only if there's ambiguity about what I mean. With Python, I have two options: 1. import module, which sucks because contrary to most of Python's terseness and expressiveness this forces me to constantly qualify my names, leading to extra typing and syntactic noise. 2. from module import *, which sucks because contrary to the Python philosophy it allows hijacking, or in other words guesses in the face of ambiguity.
Aug 01 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
dsimcha wrote:
 I absolutely despise using qualified names because they are both syntactic
noise
 and extra typing.  D lets me just import tons of stuff and skip the qualified
 names in most cases.  Most of the time it does what I mean, and it complains if
 and only if there's ambiguity about what I mean.

I am inordinately pleased with how the anti-hijacking design worked out. I think it is unique to D2. Consider, for example, what a botch C++ did with this (namespaces and Koenig lookup). C# requires lots of pointless qualifications. D2's design works so well most people don't even notice it. It just works.
Aug 01 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 dsimcha wrote:
 I absolutely despise using qualified names because they are both syntactic
noise
 and extra typing.  D lets me just import tons of stuff and skip the qualified
 names in most cases.  Most of the time it does what I mean, and it complains if
 and only if there's ambiguity about what I mean.

it is unique to D2. Consider, for example, what a botch C++ did with this (namespaces and Koenig lookup). C# requires lots of pointless qualifications. D2's design works so well most people don't even notice it. It just works.

Yeah, I always take this for granted when programming in D, and never mention it as a reason why I like D, but whenever I use something else I'm always astounded at how much of a PITA something as simple as getting modules right is. One reason I hate programming in C is that people Greenspun namespaces that force you to **always** use fully qualified names. C++ isn't much better since just doing "using namespace myNamespace" invokes so many here be dragons. It just seems like common sense to me that a module system (and a language in general) should do what you mean as long as there's no ambiguity about what you mean (without forcing you to specify things redundantly, such as by using qualified names), but not guess what you mean when there is ambiguity. Is there any other language that gets this right?
Aug 02 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
dsimcha wrote:
 It just seems like common sense to me that a module system (and a language in
 general) should do what you mean as long as there's no ambiguity about what you
 mean (without forcing you to specify things redundantly, such as by using
 qualified names), but not guess what you mean when there is ambiguity.  Is
there
 any other language that gets this right?

As far as I know, no other language does this right. While it seems common sense in retrospect, coming up with it took a while. D1 is close, but D2 shines. Rob Pike (of Go fame) says Go doesn't allow function overloading because of the confusion it causes. That's understandable given C++'s uncontrollable overloading and open namespaces. D2 doesn't have that problem.
Aug 02 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Leandro Lucarella wrote:
 For me the problem with D is dependency control. You don't know what
 symbol come from which module. Yes, I know you can do explicit
 dependencies in D with static and selective imports, the same you can do
 the inverse in other languages with the import module.*-like syntax, but
 I think D got the default wrong, I prefer explicit by default.

It's a reasonable point of view, but the motivating thing for me here is making it easy for people to write quick&dirty programs.
 With this default, I think complaining when no symbol from an imported
 module is used would be better to avoid extra unneeded dependencies. But
 I suggested that before and you don't like it.

While that idea has merit, too, I feel it would become rather annoying to people who want to: import std.all; or who use conditional compilation. It would also mess with template definitions, as the symbols in them are not lookup up until they are instantiated.
Aug 02 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 Leandro Lucarella wrote:
 For me the problem with D is dependency control. You don't know what
 symbol come from which module. Yes, I know you can do explicit
 dependencies in D with static and selective imports, the same you can do
 the inverse in other languages with the import module.*-like syntax, but
 I think D got the default wrong, I prefer explicit by default.

it easy for people to write quick&dirty programs.

I truly appreciate D's stance that both quick and dirty code and more heavily engineered code need to be supported. My biggest gripe about languages like Java is that they force so much "proper style" on me that I can't just "make it work" before I "make it right". I love how, using D, I can go from a quick and dirty prototype to a "real" program/library without having to switch languages and completely rewrite every function. In bioinformatics research, we do TONS of prototyping/small scripts and only a small fraction of these prototypes are fleshed out into serious programs. I suspect there are other fields like this, where you just want a quick prototype up front, but it may or may not be converted into a proper program depending on how the prototype works. Being able to do both in the same language is just an outstanding feature. Second, being able to write quick/dirty programs lowers the barrier to entry for trying out the language. My first few D programs, back when D was a mere curiosity for me, were things like programs that counted the amount of times each DNA nucleotide occurred in a sequence. Of course this is trivial, but if the language treated me like a naughty child instead of a consenting adult, I would likely not have stuck with it. Third, often only part of a program needs to be well-engineered (the core algorithms that will likely be around awhile) and the rest is just some quick and dirty glue to feed data to the core algorithms, and will likely change in relatively short order. The well-factored core algorithms plus quick and dirty glue style is very often how I program in practice.
Aug 02 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
dsimcha wrote:
 Third, often only part of a program needs to be well-engineered (the core
 algorithms that will likely be around awhile) and the rest is just some quick
and
 dirty glue to feed data to the core algorithms, and will likely change in
 relatively short order.  The well-factored core algorithms plus quick and dirty
 glue style is very often how I program in practice.

I agree with all your points. D has a "layered" approach to program correctness and safety, and you can mix & match them as your project needs change. The downside is D gets flak for being complicated and a kitchen sink, but I think it's a far better approach to have them properly integrated into the language rather than the rather desperate approaches I've seen using coding standards, third party analyzers, source code annotations, etc.
Aug 02 2010
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Leandro Lucarella (luca llucax.com.ar)'s article
 With this default, I think complaining when no symbol from an imported
 module is used would be better to avoid extra unneeded dependencies. But
 I suggested that before and you don't like it.
 Too bad.

But then you wouldn't be able to do import somelib.all;. This is essential because importing all the modules you need individually is tedious, annoying boilerplate code. IMHO in a modern language with good metaprogramming facilities like D, boilerplate code should absolutely, 110%, at all costs, be swept off to the ash heap of history. It's boring to write, hard to maintain (in the sense that it's just more code to slog through) and encourages cut-and-paste style coding. I refuse to write even the few lines of boilerplate it takes to import the same 15 modules over and over, when I can have a module that just publicly imports all of the ones I typically need.
Aug 02 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <luca llucax.com.ar> wrote in message 
news:20100803004718.GW3508 llucax.com.ar...
 Walter Bright, el  2 de agosto a las 16:12 me escribiste:
 dsimcha wrote:
It just seems like common sense to me that a module system (and a 
language in
general) should do what you mean as long as there's no ambiguity about 
what you
mean (without forcing you to specify things redundantly, such as by 
using
qualified names), but not guess what you mean when there is ambiguity. 
Is there
any other language that gets this right?

As far as I know, no other language does this right. While it seems common sense in retrospect, coming up with it took a while. D1 is close, but D2 shines. Rob Pike (of Go fame) says Go doesn't allow function overloading because of the confusion it causes. That's understandable given C++'s uncontrollable overloading and open namespaces. D2 doesn't have that problem.

For me the problem with D is dependency control. You don't know what symbol come from which module. Yes, I know you can do explicit dependencies in D with static and selective imports, the same you can do the inverse in other languages with the import module.*-like syntax, but I think D got the default wrong, I prefer explicit by default.

Personally, I would find that to save a couple minutes once in a while, and be a PITA most of the time. I'd find that to be a poor tradeoff.
Aug 02 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter, I suggest you to stop right now to say how much good D module system is
and how much good your design is, etc, and to start looking for the
problems/holes instead. In my language there is a proverb that says something
like "Who praises himself a lot, covers himself with broth" or something
similar ^_^ Keep looking for the *design* problems of the D module system, and
try to fix them, instead of saying several times how much good D module system
is.

Later,
bearophile
Aug 02 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Walter, I suggest you to stop right now to say how much good D module system
is and how much good your design is, etc, and to start looking for the
problems/holes instead. In my language there is a proverb that says something
like "Who praises himself a lot, covers himself with broth" or something
similar ^_^ Keep looking for the *design* problems of the D module system, and
try to fix them, instead of saying several times how much good D module system
is.

I agree with the spirit. Getting in the state we unconditionally believe we got it right essentially prevents progress in the matter by halting the brain. That being said, I recall you mentioned a couple of times in the past that D's modules have problems. Whenever you substantiated those claims, I found the arguments insufficient and ended up forgetting them. Are there some bugzilla reports (at the risk of repeating the same question)? Andrei
Aug 02 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-03 08:39, Andrei Alexandrescu wrote:
 bearophile wrote:
 Walter, I suggest you to stop right now to say how much good D module
 system is and how much good your design is, etc, and to start looking
 for the problems/holes instead. In my language there is a proverb that
 says something like "Who praises himself a lot, covers himself with
 broth" or something similar ^_^ Keep looking for the *design* problems
 of the D module system, and try to fix them, instead of saying several
 times how much good D module system is.

I agree with the spirit. Getting in the state we unconditionally believe we got it right essentially prevents progress in the matter by halting the brain. That being said, I recall you mentioned a couple of times in the past that D's modules have problems. Whenever you substantiated those claims, I found the arguments insufficient and ended up forgetting them. Are there some bugzilla reports (at the risk of repeating the same question)? Andrei

How about this one: http://d.puremagic.com/issues/show_bug.cgi?id=3108 -- /Jacob Carlborg
Aug 03 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jacob Carlborg wrote:
 On 2010-08-03 08:39, Andrei Alexandrescu wrote:
 bearophile wrote:
 Walter, I suggest you to stop right now to say how much good D module
 system is and how much good your design is, etc, and to start looking
 for the problems/holes instead. In my language there is a proverb that
 says something like "Who praises himself a lot, covers himself with
 broth" or something similar ^_^ Keep looking for the *design* problems
 of the D module system, and try to fix them, instead of saying several
 times how much good D module system is.

I agree with the spirit. Getting in the state we unconditionally believe we got it right essentially prevents progress in the matter by halting the brain. That being said, I recall you mentioned a couple of times in the past that D's modules have problems. Whenever you substantiated those claims, I found the arguments insufficient and ended up forgetting them. Are there some bugzilla reports (at the risk of repeating the same question)? Andrei

How about this one: http://d.puremagic.com/issues/show_bug.cgi?id=3108

Thanks. I voted it up! A cursory reading suggests that neither of those are matters of principles, only implementation issues. Is that right? Andrei
Aug 03 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-03 16:20, Andrei Alexandrescu wrote:
 Jacob Carlborg wrote:
 On 2010-08-03 08:39, Andrei Alexandrescu wrote:
 bearophile wrote:
 Walter, I suggest you to stop right now to say how much good D module
 system is and how much good your design is, etc, and to start looking
 for the problems/holes instead. In my language there is a proverb that
 says something like "Who praises himself a lot, covers himself with
 broth" or something similar ^_^ Keep looking for the *design* problems
 of the D module system, and try to fix them, instead of saying several
 times how much good D module system is.

I agree with the spirit. Getting in the state we unconditionally believe we got it right essentially prevents progress in the matter by halting the brain. That being said, I recall you mentioned a couple of times in the past that D's modules have problems. Whenever you substantiated those claims, I found the arguments insufficient and ended up forgetting them. Are there some bugzilla reports (at the risk of repeating the same question)? Andrei

How about this one: http://d.puremagic.com/issues/show_bug.cgi?id=3108

Thanks. I voted it up! A cursory reading suggests that neither of those are matters of principles, only implementation issues. Is that right? Andrei

Am not sure about 1441 and I don't think 2529 is just an implementation issue. -- /Jacob Carlborg
Aug 03 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Jacob Carlborg wrote:
 Am not sure about 1441 and I don't think 2529 is just an implementation 
 issue.

2529 is an implementation issue (and I don't agree with Don, I think his suggestion breaks encapsulation).
Aug 03 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-03 21:28, Walter Bright wrote:
 Jacob Carlborg wrote:
 Am not sure about 1441 and I don't think 2529 is just an
 implementation issue.

2529 is an implementation issue (and I don't agree with Don, I think his suggestion breaks encapsulation).

I guess it depends on how one wants it to work, what the intended behavior is. -- /Jacob Carlborg
Aug 03 2010
prev sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Jacob Carlborg wrote:
 Am not sure about 1441 and I don't think 2529 is just an 
 implementation issue.

2529 is an implementation issue (and I don't agree with Don, I think his suggestion breaks encapsulation).

Maybe it does. I think the bug should be closed as invalid, because the initial suggestion in the bug report is completely wrong: it would drive you to put low-level stuff in the root, and derived stuff in the leaves. Implementing that suggestion would encourage poor design. I believe D's current approach is what Java does?
Aug 04 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Don wrote:
 Walter Bright wrote:
 Jacob Carlborg wrote:
 Am not sure about 1441 and I don't think 2529 is just an 
 implementation issue.

2529 is an implementation issue (and I don't agree with Don, I think his suggestion breaks encapsulation).

Maybe it does. I think the bug should be closed as invalid, because the initial suggestion in the bug report is completely wrong: it would drive you to put low-level stuff in the root, and derived stuff in the leaves. Implementing that suggestion would encourage poor design.

Please add this as a comment to the entry.
 I believe D's current approach is what Java does?

I'm not sure what Java does.
Aug 04 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-04 12:34, Walter Bright wrote:
 Don wrote:
 Walter Bright wrote:
 Jacob Carlborg wrote:
 Am not sure about 1441 and I don't think 2529 is just an
 implementation issue.

2529 is an implementation issue (and I don't agree with Don, I think his suggestion breaks encapsulation).

Maybe it does. I think the bug should be closed as invalid, because the initial suggestion in the bug report is completely wrong: it would drive you to put low-level stuff in the root, and derived stuff in the leaves. Implementing that suggestion would encourage poor design.

Please add this as a comment to the entry.
 I believe D's current approach is what Java does?

I'm not sure what Java does.

I'm pretty sure that D's and Java's approach is the same. -- /Jacob Carlborg
Aug 05 2010
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 05/08/2010 11:59, Jacob Carlborg wrote:
 On 2010-08-04 12:34, Walter Bright wrote:
 Don wrote:
 Walter Bright wrote:

 I believe D's current approach is what Java does?

I'm not sure what Java does.

I'm pretty sure that D's and Java's approach is the same.

Yes, it is the same I think. In Java a package is considered "flat", not hierarchical. It consists only of the classes directly contained on the package's directory. And AFAIK sub-packages are no different than any other packages with regards to the parent. -- Bruno Medeiros - Software Engineer
Aug 06 2010
parent reply Don <nospam nospam.com> writes:
Bruno Medeiros wrote:
 On 05/08/2010 11:59, Jacob Carlborg wrote:
 On 2010-08-04 12:34, Walter Bright wrote:
 Don wrote:
 Walter Bright wrote:

 I believe D's current approach is what Java does?

I'm not sure what Java does.

I'm pretty sure that D's and Java's approach is the same.

Yes, it is the same I think. In Java a package is considered "flat", not hierarchical. It consists only of the classes directly contained on the package's directory. And AFAIK sub-packages are no different than any other packages with regards to the parent.

Seems pretty clear that the problems are with the concept itself, rather than D's implementation of it.
Aug 07 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Don wrote:
 Seems pretty clear that the problems are with the concept itself, rather 
 than D's implementation of it.

That leads me to be cautious in rushing in to 'fix' it.
Aug 07 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 07/08/2010 22:05, Walter Bright wrote:
 Don wrote:
 Seems pretty clear that the problems are with the concept itself,
 rather than D's implementation of it.

That leads me to be cautious in rushing in to 'fix' it.

Yeah, there is some relevant things I want to say on this issue of component encapsulation, especially coming from the Java world. I think they are really relevant insights from there. In summary, I think the ideal would be to have something like OSGi has: a bundle system. That's a really good way to have component encapsulation and version/dependency management scale to really large apps, built from several separate, and well "encapsulated", components. The alternative " internal" proposal is somewhat limited, it would only be a very minor improvement. (a related concept exists in OSGi bundles though) Also, I think this can be dealt with without involving the compiler (although a standard will be very important). I'll try to make a more detailed exposť, when I have more time, so that the use case be better understood. I'll post it on the bug report itself: http://d.puremagic.com/issues/show_bug.cgi?id=2529 -- Bruno Medeiros - Software Engineer
Sep 30 2010
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-02 02:22, Ryan W Sims wrote:
 On 8/1/10 5:07 PM, Andrei Alexandrescu wrote:
 Hello,

 I got an email from someone who got an interest in D following my talk
 at Google. He tried to install dmd on OSX, but got turned off (and
 rightly so) for the unnecessary difficulties of that process and the
 lack of documentation. Nicely of him he took the time to write me and
 detail his experience. Following that, Walter managed to fix the most
 egregious documentation errors.

Are those fixes reflected anywhere on the site? I found the process to be a little clumsy, but not hideous; I would be very interested to see what's changed, though. [Possibly OT?] The only real trouble I ran into is this: $ ./rdmd dyld: unknown required load command 0x80000022 Trace/BPT trap

I'm guessing that is because rdmd is built on Mac OS X 10.6 and you're running it on Mac OS X 10.5.
 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
 someone able and willing to own this project? I think improving the
 out-of-the-box experience is important and urgent.

I don't know that a simple .dmg file is the right way to go, since you need to get some binaries onto the user's path. I think it'd have to be a .mpkg package IIRC (which are, admittedly, distributed in a .dmg files) I don't have much experience with packaging for OSX, but if there are not more experienced folks willing to take it on, I'm willing to take this on: would love to help, but sadly I don't have the compiler chops to make a more significant contribution.
 Andrei

 P.S. My talk at Google went, I think, reasonably well. It could've gone
 a whole lot better; I neglected to make a couple of points. The talk was
 recorded and, I was told, the recording will be on YouTube some time
 next week. My mentions of Python and Haskell will probably get me
 mortified in certain circles.

[OT] I thought it went well myself, but I might be something of an easy mark. Which points did you miss?

-- /Jacob Carlborg
Aug 02 2010
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
dsimcha, el  3 de agosto a las 02:34 me escribiste:
 == Quote from Walter Bright (newshound2 digitalmars.com)'s article
 Leandro Lucarella wrote:
 For me the problem with D is dependency control. You don't know what
 symbol come from which module. Yes, I know you can do explicit
 dependencies in D with static and selective imports, the same you can do
 the inverse in other languages with the import module.*-like syntax, but
 I think D got the default wrong, I prefer explicit by default.

it easy for people to write quick&dirty programs.

I truly appreciate D's stance that both quick and dirty code and more heavily engineered code need to be supported. My biggest gripe about languages like Java is that they force so much "proper style" on me that I can't just "make it work" before I "make it right". I love how, using D, I can go from a quick and dirty prototype to a "real" program/library without having to switch languages and completely rewrite every function. In bioinformatics research, we do TONS of prototyping/small scripts and only a small fraction of these prototypes are fleshed out into serious programs. I suspect there are other fields like this, where you just want a quick prototype up front, but it may or may not be converted into a proper program depending on how the prototype works. Being able to do both in the same language is just an outstanding feature. Second, being able to write quick/dirty programs lowers the barrier to entry for trying out the language. My first few D programs, back when D was a mere curiosity for me, were things like programs that counted the amount of times each DNA nucleotide occurred in a sequence. Of course this is trivial, but if the language treated me like a naughty child instead of a consenting adult, I would likely not have stuck with it. Third, often only part of a program needs to be well-engineered (the core algorithms that will likely be around awhile) and the rest is just some quick and dirty glue to feed data to the core algorithms, and will likely change in relatively short order. The well-factored core algorithms plus quick and dirty glue style is very often how I program in practice.

I agree completely, I hate Java and every programming language where a readable hello world takes more than 3 SLOC. But I insist I'm talking about defaults. If D would accept an import module.* syntax, you could still do quick&dirty without much hassle, but make the dirtyness explicit. The argument about having technical problems to implement this model seems like a good reason (but I guess it should be doable though, at some point you have to know all the symbols that are present in a source file, and where they came from). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- <original> [Penis Uptime: 2days 13hrs 59mins 35secs] <Yapa> viagra? :) <original> yea, 20 pills
Aug 02 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-01 20:07:10 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is 
 someone able and willing to own this project? I think improving the 
 out-of-the-box experience is important and urgent.

I agree too. That's why I made sure the D for Xcode installer installs DMD too, so the user doesn't have to bother about that whole mess. <http://michelf.com/projects/d-for-xcode/> If you download this package from Safari it'll automatically open in Mac OS X's standard installer program from where you can proceed with the installation. The installer package does not contains DMD: it downloads the latest version from the website during the install process. It installs DMD 1 and DMD 2 and makes them work both from the command line though symlink trickery. A nice "side effect" of using this installer is that you'll also be ready to use D from whithin Xcode. But you can deactivate that part by customizing the install and unchecking the relevant subpackages. You can install just DMD 2 or just DMD 1 that way too. Try it, it just works. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 01 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/01/2010 10:06 PM, Michel Fortin wrote:
 On 2010-08-01 20:07:10 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
 someone able and willing to own this project? I think improving the
 out-of-the-box experience is important and urgent.

I agree too. That's why I made sure the D for Xcode installer installs DMD too, so the user doesn't have to bother about that whole mess. <http://michelf.com/projects/d-for-xcode/> If you download this package from Safari it'll automatically open in Mac OS X's standard installer program from where you can proceed with the installation. The installer package does not contains DMD: it downloads the latest version from the website during the install process. It installs DMD 1 and DMD 2 and makes them work both from the command line though symlink trickery. A nice "side effect" of using this installer is that you'll also be ready to use D from whithin Xcode. But you can deactivate that part by customizing the install and unchecking the relevant subpackages. You can install just DMD 2 or just DMD 1 that way too. Try it, it just works.

That sounds encouraging. Would you be willing to modify and contribute your installer for dmd? Thanks, Andrei
Aug 01 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-02 00:02:35 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 That sounds encouraging. Would you be willing to modify and contribute 
 your installer for dmd?

Notice the installer is already open source, part of the D for Xcode project. You might want a change of license, but for the installer changing the license is not a problem. As for modifications, what do you have in mind? I guess you'll want DMD to be stored inside the package instead of downloaded during installation. Also, do you want to preserve the filesystem layout used by D for Xcode or you want to go with something different? -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 02 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/02/2010 06:55 AM, Michel Fortin wrote:
 On 2010-08-02 00:02:35 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 That sounds encouraging. Would you be willing to modify and contribute
 your installer for dmd?

Notice the installer is already open source, part of the D for Xcode project. You might want a change of license, but for the installer changing the license is not a problem. As for modifications, what do you have in mind? I guess you'll want DMD to be stored inside the package instead of downloaded during installation. Also, do you want to preserve the filesystem layout used by D for Xcode or you want to go with something different?

The only modifications I have in mind concern separation of dmd installation from anything XCode specific. Note that I haven't tried your code yet - I'm working off my Ubuntu machine nowadays. Andrei
Aug 02 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-02 09:22:41 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 The only modifications I have in mind concern separation of dmd 
 installation from anything XCode specific.

Well, they're already separated: the package contains two subpackage related to Xcode, and two subpackages to download and install DMD 1 and 2. You can select each separately if you do a custom install. If what you mean is an installer package with the two Xcode-related subpackages removed, that's a rather trivial matter of dragging the subpackage out of the main package. Here they are (8 Kb each): DMD 1: <http://michelf.com/docs/d/dmd1install.zip> DMD 2: <http://michelf.com/docs/d/dmd2install.zip> They lack the introduction text of the main package, but that'd be easy to fix. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 02 2010
prev sibling parent Jeffrey Yasskin <jyasskin gmail.com> writes:
On Sun, Aug 1, 2010 at 8:06 PM, Michel Fortin <michel.fortin michelf.com> wrote:
 On 2010-08-01 20:07:10 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
 someone able and willing to own this project? I think improving the
 out-of-the-box experience is important and urgent.

I agree too. That's why I made sure the D for Xcode installer installs DMD too, so the user doesn't have to bother about that whole mess. <http://michelf.com/projects/d-for-xcode/> If you download this package from Safari it'll automatically open in Mac OS X's standard installer program from where you can proceed with the installation. The installer package does not contains DMD: it downloads the latest version from the website during the install process. It installs DMD 1 and DMD 2 and makes them work both from the command line though symlink trickery. A nice "side effect" of using this installer is that you'll also be ready to use D from whithin Xcode. But you can deactivate that part by customizing the install and unchecking the relevant subpackages. You can install just DMD 2 or just DMD 1 that way too. Try it, it just works.

Looks cool. That would have been a pretty good experience were it linked from the OSX download page. I looked in MacPorts for a package before looking on the D site. gdc-0.24 already has one, but dmd and ldc don't. It should be fairly straightforward to write one (http://guide.macports.org/#development.creating-portfile), and I'll try to do so for dmd in the next couple days unless someone gets to it first.
Aug 02 2010
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-02 02:07, Andrei Alexandrescu wrote:
 Hello,


 I got an email from someone who got an interest in D following my talk
 at Google. He tried to install dmd on OSX, but got turned off (and
 rightly so) for the unnecessary difficulties of that process and the
 lack of documentation. Nicely of him he took the time to write me and
 detail his experience. Following that, Walter managed to fix the most
 egregious documentation errors.

 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
 someone able and willing to own this project? I think improving the
 out-of-the-box experience is important and urgent.


 Andrei

 P.S. My talk at Google went, I think, reasonably well. It could've gone
 a whole lot better; I neglected to make a couple of points. The talk was
 recorded and, I was told, the recording will be on YouTube some time
 next week. My mentions of Python and Haskell will probably get me
 mortified in certain circles.

Have you guys completely forgot http://dsource.org/projects/dmd-installer/browser/trunk/osx ? It's been there for over a year. -- /Jacob Carlborg
Aug 02 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 08/02/2010 06:01 AM, Jacob Carlborg wrote:
 On 2010-08-02 02:07, Andrei Alexandrescu wrote:
 Hello,


 I got an email from someone who got an interest in D following my talk
 at Google. He tried to install dmd on OSX, but got turned off (and
 rightly so) for the unnecessary difficulties of that process and the
 lack of documentation. Nicely of him he took the time to write me and
 detail his experience. Following that, Walter managed to fix the most
 egregious documentation errors.

 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
 someone able and willing to own this project? I think improving the
 out-of-the-box experience is important and urgent.


 Andrei

 P.S. My talk at Google went, I think, reasonably well. It could've gone
 a whole lot better; I neglected to make a couple of points. The talk was
 recorded and, I was told, the recording will be on YouTube some time
 next week. My mentions of Python and Haskell will probably get me
 mortified in certain circles.

Have you guys completely forgot http://dsource.org/projects/dmd-installer/browser/trunk/osx ? It's been there for over a year.

Hi Jacob, Apologies for the oversight. I take it it's okay if Walter uses your code to build the distribution automatically? If so, what are the similarities and the differences with Michel's approach? Andrei
Aug 02 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-02 09:18:37 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 On 08/02/2010 06:01 AM, Jacob Carlborg wrote:
 Have you guys completely forgot
 http://dsource.org/projects/dmd-installer/browser/trunk/osx ? It's been
 there for over a year.

Hi Jacob, Apologies for the oversight. I take it it's okay if Walter uses your code to build the distribution automatically? If so, what are the similarities and the differences with Michel's approach?

I think I can answer that. * Jacob's installer includes DMD directly inside the installation package, which I believe is more practical for the user, but less for the maintainer as the installer needs to be rebuild for each new release. My installer downloads the latest version during the install. I do this so I can host the installer on my website with no licensing issue and update it only when releasing a new version of D for Xcode. * Jacob's installer installs in /usr/share/dmd and creates symlinks in /usr/bin and /usr/share/man. D for Xocde installs DMD 1 in /Library/Compilers/dmd and DMD 2 in /Library/Compilers/dmd2 (user visible folders) and makes symlinks in /usr/local/{bin,lib,man}. * Jacob's installer requires a modified dmd.conf file. Not with my installer. With mine, once the symlinks are in place you can just swap the dmd or dmd2 folder in /Library/Compilers with a newer one from Digital Mars, but you'll need to set the executable bits manually (because Walter's archives comes without the executable bit set). * With Jacob's installer, DMD 1 and DMD 2 will overwrite each other (or so I believe). My installer is meant to have both dmd1 and dmd2 usable at the same time. Essentially the symlinks /usr/local/bin/* pointing to /Library/Compilers/{dmd,dmd2}/osx/bin/* are arranged to that you can call 'dmd1' and 'dmd2' from the command line to get either one or the other, and 'dmd' will call either dmd2 or dmd1, which you can change with the 'sudo setdmd 1' or 'sudo setdmd 2' command. This mimics somewhat how Apple bundles multiple versions of GCC in the Xcode package and allow changing the default version. As a side note, my D plugin for Xcode expects DMD to be available at /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in /usr/local/lib. It won't work if the files can't be found there, although I might change that if an official distribution of DMD installs itself elsewhere. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 02 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-02 16:41, Michel Fortin wrote:
 On 2010-08-02 09:18:37 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:

 On 08/02/2010 06:01 AM, Jacob Carlborg wrote:
 Have you guys completely forgot
 http://dsource.org/projects/dmd-installer/browser/trunk/osx ? It's been
 there for over a year.

Hi Jacob, Apologies for the oversight. I take it it's okay if Walter uses your code to build the distribution automatically? If so, what are the similarities and the differences with Michel's approach?

I think I can answer that. * Jacob's installer includes DMD directly inside the installation package, which I believe is more practical for the user, but less for the maintainer as the installer needs to be rebuild for each new release. My installer downloads the latest version during the install. I do this so I can host the installer on my website with no licensing issue and update it only when releasing a new version of D for Xcode. * Jacob's installer installs in /usr/share/dmd and creates symlinks in /usr/bin and /usr/share/man. D for Xocde installs DMD 1 in /Library/Compilers/dmd and DMD 2 in /Library/Compilers/dmd2 (user visible folders) and makes symlinks in /usr/local/{bin,lib,man}. * Jacob's installer requires a modified dmd.conf file. Not with my installer. With mine, once the symlinks are in place you can just swap the dmd or dmd2 folder in /Library/Compilers with a newer one from Digital Mars, but you'll need to set the executable bits manually (because Walter's archives comes without the executable bit set). * With Jacob's installer, DMD 1 and DMD 2 will overwrite each other (or so I believe). My installer is meant to have both dmd1 and dmd2 usable at the same time. Essentially the symlinks /usr/local/bin/* pointing to /Library/Compilers/{dmd,dmd2}/osx/bin/* are arranged to that you can call 'dmd1' and 'dmd2' from the command line to get either one or the other, and 'dmd' will call either dmd2 or dmd1, which you can change with the 'sudo setdmd 1' or 'sudo setdmd 2' command. This mimics somewhat how Apple bundles multiple versions of GCC in the Xcode package and allow changing the default version.

I guess I should fix that if anyone wants to use the installer.
 As a side note, my D plugin for Xcode expects DMD to be available at
 /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in
 /usr/local/lib. It won't work if the files can't be found there,
 although I might change that if an official distribution of DMD installs
 itself elsewhere.

That was a lot better answer than mine. -- /Jacob Carlborg
Aug 02 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Michel Fortin wrote:
 As a side note, my D plugin for Xcode expects DMD to be available at 
 /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in 
 /usr/local/lib. It won't work if the files can't be found there, 
 although I might change that if an official distribution of DMD installs 
 itself elsewhere.

To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.
Aug 04 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Michel Fortin wrote:
 As a side note, my D plugin for Xcode expects DMD to be available at 
 /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in 
 /usr/local/lib. It won't work if the files can't be found there, 
 although I might change that if an official distribution of DMD 
 installs itself elsewhere.

To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.

Since we're talking about a Unix command-line utility, I suggest we go with the Unix traditional directories. Andrei
Aug 04 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Michel Fortin wrote:
 As a side note, my D plugin for Xcode expects DMD to be available at 
 /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in 
 /usr/local/lib. It won't work if the files can't be found there, 
 although I might change that if an official distribution of DMD 
 installs itself elsewhere.

To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.

Since we're talking about a Unix command-line utility, I suggest we go with the Unix traditional directories.

Which are what, for: dmd libphobos phobos imports ?
Aug 04 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-04 17:56:31 -0400, Leandro Lucarella <luca llucax.com.ar> said:

 I'd say:
 
 dmd

/usr/local/bin

That makes a lot of sense. I agree that /usr/local/{bin,lib,man} is the right place. But you can't install dmd1 and dmd2 side by side this way (because of dmd.conf). That's why the D for Xcode installer put them elsewhere and simply add symlinks in /usr/local/bin. (Or to be more precise: symlink-like programs that set args[0] to the real dmd path.)
 libphobos

/usr/local/lib
 phobos imports

/usr/local/include/d (d is just a suggestion, since at least Debian/Ubuntu uses that, well, without the "local" because are official packages, for gdc and ldc). And you may add /usr/local/etc as a search path for dmd.conf (and look for it *before* /etc is searched) and install dmd.conf there.

About dmd.conf: perhaps dmd2 should look for dmd2.conf instead of dmd.conf. This way you can have both dmd1 and dmd2 installed side by side. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 04 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-04 15:31:32 -0400, Walter Bright <newshound2 digitalmars.com> said:

 Michel Fortin wrote:
 As a side note, my D plugin for Xcode expects DMD to be available at 
 /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in 
 /usr/local/lib. It won't work if the files can't be found there, 
 although I might change that if an official distribution of DMD 
 installs itself elsewhere.

To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.

I agree. It took me quite a while to decide to do things as I did. The goals were: 1. It should be easy to manually replace DMD from a new package from Digital Mars. 2. It should work on the command line with no user intervention (no need to add something to $PATH in the bash profile for instance). 3. It should not mess with the system directories. Except when it come from third party package managers (fink, MacPorts), most Unix software not coming from Apple installs in /usr/local on Mac OS X (for instance I have: MySQL, Git, Mercurial, Doxygen, 7za and a couple others there). So it makes a lot of sense to install it there. To make manual replacement easy, I wanted to preserve the dmd and dmd2 directories from the zip archive intact, so it's easy to swap them for another one. Initially, I decided to use /usr/local/dmd and /usr/local/dmd2, and add with symlinks in /usr/local/{bin,lib,man} to make everything work from the command line without changing $PATH. Symlinks didn't work quite well: dmd takes the value of args[0] to know which directory to search for dmd.conf. I guess I could have installed a dmd.conf in /etc/ to override that, but then how do you install dmd1 and dmd2 side by side? So what I did is replace the symlinks with a sort of trampoline program that adjusts the value of the args[0] for the path of the DMD just before calling exec(), allowing a different dmd.conf to be used for each one. And using /usr/local/{dmd,dmd2} wasn't entirely satisfactory either. Mac OS X hides the /usr folder when you browse using the Finder. So replacing /usr/local/{dmd,dmd2} manually with a newer one isn't as straightforward as it should be. I settled on using /Library/Compilers/{dmd,dmd2}. This isn't entirely satisfactory either since it doesn't follow UNIX ways, but it's not too far of how Mac OS X is packaged and I told myself it'd be easier to support users that way. Now, the only missing piece for an easy manual replacement of DMD is a zip archive where the executable bit is set. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 04 2010
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Michel Fortin wrote:
 To me, the biggest problem is deciding where the files should go. There
doesn't seem to be any consensus or culture in OS X about this.

I agree. It took me quite a while to decide to do things as I did. The goals were: 1. It should be easy to manually replace DMD from a new package from Digital Mars. 2. It should work on the command line with no user intervention (no need to add something to $PATH in the bash profile for instance). 3. It should not mess with the system directories.

It used to be that /usr/local/bin wasn't in the $PATH, and that the shell wasn't bash either for that manner. And since GDC was using the GCC installation anyway, it installs into /usr/bin... (while being relocatable to a root, like Developer/usr/bin too)
 Except when it come from third party package managers (fink,
 MacPorts), most Unix software not coming from Apple installs in
 /usr/local on Mac OS X (for instance I have: MySQL, Git, Mercurial,
 Doxygen, 7za and a couple others there). So it makes a lot of sense
 to install it there.

Yeah, as long as the user has admin privileges the /usr/local hierarchy (and matching /Library) is definitely the one to use. [...]
 And using /usr/local/{dmd,dmd2} wasn't entirely satisfactory either. Mac 
 OS X hides the /usr folder when you browse using the Finder. So 
 replacing /usr/local/{dmd,dmd2} manually with a newer one isn't as 
 straightforward as it should be. I settled on using 
 /Library/Compilers/{dmd,dmd2}. This isn't entirely satisfactory either 
 since it doesn't follow UNIX ways, but it's not too far of how Mac OS X 
 is packaged and I told myself it'd be easier to support users that way.

Sounds excellent. For instance Python is packaged in the same way. (/Library/Frameworks/Python.framework and symlinks from /usr/local) For a hybrid environment like Mac OS X it makes sense to use both... Then the user can either use the Unix way or set it up like Windows.
 Now, the only missing piece for an easy manual replacement of DMD is a 
 zip archive where the executable bit is set.

Hard to believe that bit is still missing, after all these years. --anders
Aug 05 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2010-08-05 01:21, Michel Fortin wrote:
 On 2010-08-04 15:31:32 -0400, Walter Bright <newshound2 digitalmars.com>
 said:

 Michel Fortin wrote:
 As a side note, my D plugin for Xcode expects DMD to be available at
 /usr/local/bin/{dmd,dmd1,dmd2} and the runtime libraries should be in
 /usr/local/lib. It won't work if the files can't be found there,
 although I might change that if an official distribution of DMD
 installs itself elsewhere.

To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.

I agree. It took me quite a while to decide to do things as I did. The goals were: 1. It should be easy to manually replace DMD from a new package from Digital Mars. 2. It should work on the command line with no user intervention (no need to add something to $PATH in the bash profile for instance). 3. It should not mess with the system directories. Except when it come from third party package managers (fink, MacPorts), most Unix software not coming from Apple installs in /usr/local on Mac OS X (for instance I have: MySQL, Git, Mercurial, Doxygen, 7za and a couple others there). So it makes a lot of sense to install it there. To make manual replacement easy, I wanted to preserve the dmd and dmd2 directories from the zip archive intact, so it's easy to swap them for another one. Initially, I decided to use /usr/local/dmd and /usr/local/dmd2, and add with symlinks in /usr/local/{bin,lib,man} to make everything work from the command line without changing $PATH. Symlinks didn't work quite well: dmd takes the value of args[0] to know which directory to search for dmd.conf. I guess I could have installed a dmd.conf in /etc/ to override that, but then how do you install dmd1 and dmd2 side by side? So what I did is replace the symlinks with a sort of trampoline program that adjusts the value of the args[0] for the path of the DMD just before calling exec(), allowing a different dmd.conf to be used for each one. And using /usr/local/{dmd,dmd2} wasn't entirely satisfactory either. Mac OS X hides the /usr folder when you browse using the Finder. So replacing /usr/local/{dmd,dmd2} manually with a newer one isn't as straightforward as it should be. I settled on using /Library/Compilers/{dmd,dmd2}. This isn't entirely satisfactory either since it doesn't follow UNIX ways, but it's not too far of how Mac OS X is packaged and I told myself it'd be easier to support users that way. Now, the only missing piece for an easy manual replacement of DMD is a zip archive where the executable bit is set.

I would vote for something like this, making it easy to have dmd and dm2 installed side by side and to easily manually update the compiler to a newer version. I would name the trampoline programs dmd1 and dmd2 and then make a symlink named dmd pointing to dmd1 or dmd2. -- /Jacob Carlborg
Aug 05 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-08-05 07:14:19 -0400, Jacob Carlborg <doob me.com> said:

 I would vote for something like this, making it easy to have dmd and 
 dm2 installed side by side and to easily manually update the compiler 
 to a newer version. I would name the trampoline programs dmd1 and dmd2 
 and then make a symlink named dmd pointing to dmd1 or dmd2.

The D for Xcode installer does all this and also installs a small command to easily change which version the dmd symlink points to: $ sudo setdmd 1 $ dmd -v Digital Mars D Compiler v1.062 ... $ sudo setdmd 2 $ dmd -v Digital Mars D Compiler v2.047 ... -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Aug 05 2010
parent Jacob Carlborg <doob me.com> writes:
On 2010-08-05 14:29, Michel Fortin wrote:
 On 2010-08-05 07:14:19 -0400, Jacob Carlborg <doob me.com> said:

 I would vote for something like this, making it easy to have dmd and
 dm2 installed side by side and to easily manually update the compiler
 to a newer version. I would name the trampoline programs dmd1 and dmd2
 and then make a symlink named dmd pointing to dmd1 or dmd2.

The D for Xcode installer does all this and also installs a small command to easily change which version the dmd symlink points to: $ sudo setdmd 1 $ dmd -v Digital Mars D Compiler v1.062 ... $ sudo setdmd 2 $ dmd -v Digital Mars D Compiler v2.047 ...

Forgot about that one, it's really nice to have. -- /Jacob Carlborg
Aug 05 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-08-02 15:18, Andrei Alexandrescu wrote:
 On 08/02/2010 06:01 AM, Jacob Carlborg wrote:
 On 2010-08-02 02:07, Andrei Alexandrescu wrote:
 Hello,


 I got an email from someone who got an interest in D following my talk
 at Google. He tried to install dmd on OSX, but got turned off (and
 rightly so) for the unnecessary difficulties of that process and the
 lack of documentation. Nicely of him he took the time to write me and
 detail his experience. Following that, Walter managed to fix the most
 egregious documentation errors.

 Ideally we'd have a one-click OSX installer for dmd - a .dmg file. Is
 someone able and willing to own this project? I think improving the
 out-of-the-box experience is important and urgent.


 Andrei

 P.S. My talk at Google went, I think, reasonably well. It could've gone
 a whole lot better; I neglected to make a couple of points. The talk was
 recorded and, I was told, the recording will be on YouTube some time
 next week. My mentions of Python and Haskell will probably get me
 mortified in certain circles.

Have you guys completely forgot http://dsource.org/projects/dmd-installer/browser/trunk/osx ? It's been there for over a year.

Hi Jacob, Apologies for the oversight. I take it it's okay if Walter uses your code to build the distribution automatically? If so, what are the similarities and the differences with Michel's approach? Andrei

Yes, it's okay, that was the whole point of the code. The difference is that the package my code builds will contain dmd and it will install it in a different location (/usr/share/dmd). Obviously it doesn't contain the XCode plugin. -- /Jacob Carlborg
Aug 02 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Walter Bright, el  2 de agosto a las 16:12 me escribiste:
 dsimcha wrote:
It just seems like common sense to me that a module system (and a language in
general) should do what you mean as long as there's no ambiguity about what you
mean (without forcing you to specify things redundantly, such as by using
qualified names), but not guess what you mean when there is ambiguity.  Is there
any other language that gets this right?

As far as I know, no other language does this right. While it seems common sense in retrospect, coming up with it took a while. D1 is close, but D2 shines. Rob Pike (of Go fame) says Go doesn't allow function overloading because of the confusion it causes. That's understandable given C++'s uncontrollable overloading and open namespaces. D2 doesn't have that problem.

For me the problem with D is dependency control. You don't know what symbol come from which module. Yes, I know you can do explicit dependencies in D with static and selective imports, the same you can do the inverse in other languages with the import module.*-like syntax, but I think D got the default wrong, I prefer explicit by default. With this default, I think complaining when no symbol from an imported module is used would be better to avoid extra unneeded dependencies. But I suggested that before and you don't like it. Too bad. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- no longer afraid of the dark or midday shadows nothing so ridiculously teenage and desperate, nothing so childish - at a better pace, slower and more calculated, no chance of escape,
Aug 02 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
dsimcha, el  3 de agosto a las 02:16 me escribiste:
 == Quote from Leandro Lucarella (luca llucax.com.ar)'s article
 With this default, I think complaining when no symbol from an imported
 module is used would be better to avoid extra unneeded dependencies. But
 I suggested that before and you don't like it.
 Too bad.

But then you wouldn't be able to do import somelib.all;

If a syntax like import somelib.*; would be implemented, that kind of "import all" statements could be taken as a special case and don't trigger the error. public imports should not trigger errors either, because you are just explicitly propagating what's in a module.
 because importing all the modules you need individually is tedious, annoying
 boilerplate code.  IMHO in a modern language with good metaprogramming
facilities
 like D, boilerplate code should absolutely, 110%, at all costs, be swept off to
 the ash heap of history.  It's boring to write, hard to maintain (in the sense
 that it's just more code to slog through) and encourages cut-and-paste style
 coding.  I refuse to write even the few lines of boilerplate it takes to import
 the same 15 modules over and over, when I can have a module that just publicly
 imports all of the ones I typically need.

Again, I completely agree. But you can avoid all the boilerplate code and keep the dependencies explicit by default. They are not mutually exclusive goals. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Y será el día en que la electricidad deje de ser rayo y sea depilador femenino. -- Ricardo Vaporeso
Aug 02 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Walter Bright, el  4 de agosto a las 12:41 me escribiste:
 Andrei Alexandrescu wrote:
Walter Bright wrote:
Michel Fortin wrote:
As a side note, my D plugin for Xcode expects DMD to be
available at /usr/local/bin/{dmd,dmd1,dmd2} and the runtime
libraries should be in /usr/local/lib. It won't work if the
files can't be found there, although I might change that if an
official distribution of DMD installs itself elsewhere.

To me, the biggest problem is deciding where the files should go. There doesn't seem to be any consensus or culture in OS X about this.

Since we're talking about a Unix command-line utility, I suggest we go with the Unix traditional directories.

Which are what, for:

I'd say:
 dmd

/usr/local/bin
 libphobos

/usr/local/lib
 phobos imports

/usr/local/include/d (d is just a suggestion, since at least Debian/Ubuntu uses that, well, without the "local" because are official packages, for gdc and ldc). And you may add /usr/local/etc as a search path for dmd.conf (and look for it *before* /etc is searched) and install dmd.conf there. Main reference: FHS: /usr/local Local hierarchy: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY Some other references: FHS: http://www.pathname.com/fhs/pub/fhs-2.3.html LSB: http://www.linuxfoundation.org/collaborate/workgroups/lsb (yes, Linux only) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- 3 people die every year, testing if a 9 volts battery works on their tongue
Aug 04 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Michel Fortin, el  4 de agosto a las 19:26 me escribiste:
 On 2010-08-04 17:56:31 -0400, Leandro Lucarella <luca llucax.com.ar> said:
 
I'd say:

dmd

/usr/local/bin

That makes a lot of sense. I agree that /usr/local/{bin,lib,man} is the right place. But you can't install dmd1 and dmd2 side by side this way (because of dmd.conf). That's why the D for Xcode installer put them elsewhere and simply add symlinks in /usr/local/bin. (Or to be more precise: symlink-like programs that set args[0] to the real dmd path.)

In that case, /opt should be the place: http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES But I think is a shame to use /opt because of this small issue, the config file problem is a DMD bug, dmd2 should use dmd2.conf.
And you may add /usr/local/etc as a search path for dmd.conf (and look
for it *before* /etc is searched) and install dmd.conf there.

About dmd.conf: perhaps dmd2 should look for dmd2.conf instead of dmd.conf. This way you can have both dmd1 and dmd2 installed side by side.

You said it brotha! =) And you know what, I reported the bugs: http://d.puremagic.com/issues/show_bug.cgi?id=4585 http://d.puremagic.com/issues/show_bug.cgi?id=4586 -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- <mazzi> gmail is down? <Luca> waiting for mail.google.com.... <mazzi> ya vendí todas mis acciones de google en los mercados asiaticos <Luca> se viene la ecatombe <mazzi> mal <mazzi> es como que te corten el porno en una tarde al pedo en tu casa
Aug 05 2010
prev sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
Anders F Björklund, el  5 de agosto a las 10:40 me escribiste:
Now, the only missing piece for an easy manual replacement of DMD
is a zip archive where the executable bit is set.

Hard to believe that bit is still missing, after all these years.

In Linux the zip program support the executable bit, I'd be surprised if Mac OSX don't have it, it's just that Walter is not setting it: $ touch exe $ chmod a+x exe $ ls -l exe -rwxrwxr-x 1 luca luca 0 2010-08-05 11:01 exe $ zip exe.zip exe adding: exe (stored 0%) $ rm exe $ ls exe ls: no se puede acceder a exe: No existe el archivo o directorio $ unzip exe.zip Archive: exe.zip extracting: exe $ ls -l exe -rwxrwxr-x 1 luca luca 0 2010-08-05 11:01 exe $ -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- HACIA NEUQUEN: EL JUEVES SALDRA CARAVANA CON PERROS DESDE CAPITAL EN APOYO AL CACHORRO CONDENADO A MUERTE -- Crónica TV
Aug 05 2010