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

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

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

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

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.

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.

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