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),
 


 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.


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),


 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


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 


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.


 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

 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 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
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's a reasonable point of view, but the motivating thing for me here is making
 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
next sibling 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 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's a reasonable point of view, but the motivating thing for me here is making
 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 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
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 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.
 
 


I updated the bug with some interesting links to Java discussions.
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 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 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 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 reply 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
parent reply 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
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 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 reply =?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
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
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