On 5/15/10 19:27, Walter Bright wrote:
> Jacob Carlborg wrote:
>> On 5/15/10 11:00, Walter Bright wrote:
>>> Apple's web site isn't much better, it's got to be the most hard to read
>>> site I've ever encountered. The text is a faint grey on white, of all
>>> things, and the font is so poorly rendered my eyes turn red and painful
>>> after a while reading it. I have to actually select the text in order to
>>> read it. I find this astonishing, am I doing something wrong?
>>
>> Looking at Apple's developer site and the API reference, for me the
>> body of the text is black using firefox, some minor parts are in gray.
>
> I'm using firefox. Even on their main
> developer.apple.com/iphone/index.action, most of the text is light grey
> on white.
>
> Now click on "getting started documents", which brings you to a page
> that will not render in Explorer or Firefox, only Safari.

It renders perfectly fine for me using firefox, looks exactly the same with safari and firefox.

> In the docs themselves, a very light blue font is used for links that is
> illegible. The code examples in the docs are even lighter grey on white.
> Couple this with the unusually small font used, and it's literally
> painful to read.

I can agree with you about the links, oh the code examples, yeah they are quite gray.

> For a company that prides itself on excellent readability, I am
> astonished, and I can't believe I'm the only one with problems reading
> their pages.

Walter Bright, el 15 de mayo a las 10:28 me escribiste:
> Leandro Lucarella wrote:
> >I think the feature could be nice if it needs no configuration at all (it searches the import path and looks for modules where a missing symbol is).
> 
> The problem with that is often newbies have trouble setting up import paths.

That's a problem with D distribution, not with the compiler. It would be better to fix the original problem =)

In Linux you should provide distribution packages, there is now way to get the installation wrong that way. On Windows I guess you should provide an installer like most Windows programs do.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Corrí muchas carreras, tratando de alcanzarte a vos.
Pero corría sólo y siempre salí último.

On Sat, May 15, 2010 at 07:21:00PM -0300, Leandro Lucarella wrote:
> That's a problem with D distribution, not with the compiler. It would be better to fix the original problem =)

It amazes me that people have trouble installing D. Download, unzip, done. It couldn't be simpler.

On 16/05/10 11:11, Adam Ruppe wrote:
> On Sat, May 15, 2010 at 07:21:00PM -0300, Leandro Lucarella wrote:
>> That's a problem with D distribution, not with the compiler. It would be
>> better to fix the original problem =)
>
> It amazes me that people have trouble installing D. Download, unzip,

Set executable bit, modify PATH

done.
> It couldn't be simpler.


I've a little script that copies the executables into /usr/bin, the manpages into manpage land, the docs into /usr/share/docs/dmd, imports into /usr/include/d and the libraries into /usr/lib, and so on. So the install process is simply

sudo installdmd dmd.whatever.zip

which is nice.

On 5/15/10, Bernard Helyer <b.helyer@gmail.com> wrote:
> Set executable bit, modify PATH

Meh, you don't have to do that. On my box, I have a wrapper script in /usr/bin
so the dmd command works from anywhere, but you can just as well run
it right out of wherever you download it too. ./dmd works just as well as dmd.

> I've a little script that copies the executables into /usr/bin, the manpages into manpage land, the docs into /usr/share/docs/dmd, imports into /usr/include/d and the libraries into /usr/lib, and so on.

Ew, why? I guess if you have a script it is ok for you, but there's really no need to take it out of the folders where they are at the unzip.

Hello Adam,

> On 5/15/10, Bernard Helyer <b.helyer@gmail.com> wrote:
> 
>> Set executable bit, modify PATH
>> 
> Meh, you don't have to do that. On my box, I have a wrapper script in
> /usr/bin
> so the dmd command works from anywhere, but you can just as well run
> it right out of wherever you download it too. ./dmd works just as well
> as dmd.
>> I've a little script that copies the executables into /usr/bin, the
>> manpages into manpage land, the docs into /usr/share/docs/dmd,
>> imports into /usr/include/d and the libraries into /usr/lib, and so
>> on.
>> 
> Ew, why? I guess if you have a script it is ok for you, but there's
> really no need to take it out of the folders where they are at the
> unzip.
> 

The same holds for every file in /usr/bin, I wonder what that says about all the other people who put stuff there. Similar thought hold for the other bits and places.


-- 
... <IXOYE><

On 16/05/10 13:06, Adam Ruppe wrote:
> Ew, why? I guess if you have a script it is ok for you, but there's
> really no need to take it out of the folders where they are at the
> unzip.

Because certain tools expect dmd to be on the PATH. I could edit /etc/environment, but this is simpler.

"BCS" <none@anon.com> wrote in message news:a6268ff13bd08ccc2716440002a@news.digitalmars.com...
> Hello Adam,
>
>> On 5/15/10, Bernard Helyer <b.helyer@gmail.com> wrote:
>>
>>> Set executable bit, modify PATH
>>>
>> Meh, you don't have to do that. On my box, I have a wrapper script in
>> /usr/bin
>> so the dmd command works from anywhere, but you can just as well run
>> it right out of wherever you download it too. ./dmd works just as well
>> as dmd.
>>> I've a little script that copies the executables into /usr/bin, the manpages into manpage land, the docs into /usr/share/docs/dmd, imports into /usr/include/d and the libraries into /usr/lib, and so on.
>>>
>> Ew, why? I guess if you have a script it is ok for you, but there's really no need to take it out of the folders where they are at the unzip.
>>
>
> The same holds for every file in /usr/bin, I wonder what that says about all the other people who put stuff there. Similar thought hold for the other bits and places.
>

Maybe it's my windows upbringing, but I've never liked the idea of having each of my apps spread all across the whole filesystem.

Hello Nick,

> "BCS" <none@anon.com> wrote in message
> news:a6268ff13bd08ccc2716440002a@news.digitalmars.com...
> 
>> The same holds for every file in /usr/bin, I wonder what that says
>> about all the other people who put stuff there. Similar thought hold
>> for the other bits and places.
>> 
> Maybe it's my windows upbringing, but I've never liked the idea of
> having each of my apps spread all across the whole filesystem.
> 

There is something to be said for that, but at least with Linux it's *only* the filesystem that it gets spread across (registry).

I think this is a case where the phrase "when in Rome" is a good starting point.

-- 
... <IXOYE><

"BCS" <none@anon.com> wrote in message news:a6268ff13be78ccc28aed90fd98@news.digitalmars.com...
> Hello Nick,
>
>> "BCS" <none@anon.com> wrote in message news:a6268ff13bd08ccc2716440002a@news.digitalmars.com...
>>
>>> The same holds for every file in /usr/bin, I wonder what that says about all the other people who put stuff there. Similar thought hold for the other bits and places.
>>>
>> Maybe it's my windows upbringing, but I've never liked the idea of having each of my apps spread all across the whole filesystem.
>>
>
> There is something to be said for that, but at least with Linux it's *only* the filesystem that it gets spread across (registry).
>
> I think this is a case where the phrase "when in Rome" is a good starting point.
>

True enough.

Actually, this is something I've often given thought to. The basic problem, really, is inherent limitations of hierarchies. There are apps, and then apps can have executables, helper executables, asset files, help files, settings files, plugins, etc. This is really a 2D matrix with "App" on one axis and "Type of data" on the other. So to put it into a hierarchical data system (ie, any modern filesystem) one must arbitrarily choose one of the axes to be the most significant. Unix traditionally chooses "type of data". Windows and the modern OSX package system choose "app" (with notable exceptions - registry, user settings directories). My own personal preference is "app", but there are certainly reasonable points to be made for either approach.

This also gets into why I was a bit disappointed that MS's WinFS project died out. I hadn't thought much about it prior to all the talk of WinFS, but things like that and iTunes convinced me rather quickly that hierarchical filesystems are a bit antiquated for modern needs, and that there are definite benefits to be gained from a relational approach even if it's nothing more than a system-wide layer on top of a traditional hierarchical system (hell, DBMS's abandoned hierarchies in favor of relational long ago, and for good reason). But of course, actually pulling that off on a technical level, and doing it well, is probably another matter entirely, at least if MS's experience is any indication.