View mode: basic / threaded / horizontal-split · Log in · Help
August 05, 2010
Re: Mac OSX installer for dmd
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
August 05, 2010
Re: Mac OSX installer for dmd
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
August 05, 2010
Re: Mac OSX installer for dmd
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
August 07, 2010
Re: Mac OSX installer for dmd
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
August 07, 2010
Re: Mac OSX installer for dmd
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.
August 07, 2010
Re: Mac OSX installer for dmd
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.
September 30, 2010
Re: Mac OSX installer for dmd
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
Next ›   Last »
2 3 4 5 6
Top | Discussion index | About this forum | D home