On 05/15/2010 02:00 AM, Walter Bright wrote:
> Don wrote:
>> Walter Bright wrote:
>>> Leandro Lucarella wrote:
>>>> I saw the patches, and having all hardcoded in the compiler doesn't
>>>> seems
>>>> like a good idea =/
>>>
>>> I know the hardcoding is probably not the best, but I wanted to try
>>> it out to see if it was a good feature before committing a lot of
>>> work to it.
>>>
>>> The alternative is to use some sort of configuration file for it. The
>>> problem, though, is that the hints are for newbies, and newbies
>>> probably aren't going to get a configuration file properly set up,
>>> especially if there are multiple such files.
>>
>> I think the only purpose of such a feature is to increase the chance
>> that a newbie's "hello world" compiles successfully. The importance of
>> that can't be underestimated, I think. First impressions matter.
>
> Yes, or at least have a to-the-point error message rather than just an
> undefined identifier.
>
> It's amazing how much information we take for granted. For example, I've
> been trying to use Apple's xcode system. I find it hard to do the most
> trivial things, like trying to figure out how to just start the thing.
>
> 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?
>
> It won't render at all in Explorer.
>
> The D web site is rather pedestrian, but at least it's easy on the eyes.

*Pedestrian*??

The D web pages are a marvel of clarity and utility.  Compare them to the Python web pages, which I rate a second best.  Things are documented with relative clarity, one can generally find what one needs with a bit of searching, even if one doesn't know what it's named.  Etc.

The D web site has only two minor (*minor*!) problems
One is the search engine which doesn't work on local copies.
The other is that one needs to disable google translation on local copies, or everything loads too slowly.
(The first of those is probably impossible to deal with, but the second looks trivial.)

If by pedestrian you mean clean, clear, and easy to use, then give me more pedestrian.

My sole problem with D is one that's probably impossible to address: the lack of libraries.  When I need libraries, I usually end up using some other language.  But it sure isn't the web page.

(DSource is marvelous, but most of the libraries listed appear to be either moribund or morbid.)

On 05/15/2010 06:13 PM, BCS wrote:
> 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.
>
>
/usr/bin is for system installed executables.  It's bad practice to put other things there.  I could see installing them to /usr/local/bin , /usr/opt/bin or /home/$USER/bin, but otherwise just leaving them where they're unzipped is quite reasonable.  (Each of the approaches has their own particular reason why they're a good idea.  E.g. /usr/local/bin is easy to share with other users on the system.  I'm not sure why /usr/opt/bin, but some have, historically, preferred it. /home/$USER/bin allows sharing libraries within a single user.  And just leaving it where you unzipped it facilitates having multiple versions of the same program available.)

P.S.:  Does D actually allow you to just run from the unzipped folder? Earlier versions required a global library installation.  It's been awhile since I've done the tarball installation, so I don't recall.  But it used to be impossible to have both D1 and D2 installed, much less D2.040 and D2.046.

Charles Hixson wrote:
> On 05/15/2010 02:00 AM, Walter Bright wrote:
>> The D web site is rather pedestrian, but at least it's easy on the eyes.
> 
> *Pedestrian*??
> 
> The D web pages are a marvel of clarity and utility.  Compare them to the Python web pages, which I rate a second best.  Things are documented with relative clarity, one can generally find what one needs with a bit of searching, even if one doesn't know what it's named.  Etc.
> 
> The D web site has only two minor (*minor*!) problems
> One is the search engine which doesn't work on local copies.
> The other is that one needs to disable google translation on local copies, or everything loads too slowly.
> (The first of those is probably impossible to deal with, but the second looks trivial.)
> 
> If by pedestrian you mean clean, clear, and easy to use, then give me more pedestrian.

People often say it doesn't look professional. I agree it could probably use better colors, etc. But for this kind of web site, I think it's just wrong to use flash, javascript, or anything that takes a long time to load. I don't like pages that have a tiny bit of content surrounded by acres of flashy, blinky, hovering advertisements. I don't like websites that sacrifice readability in favor of a "look". I don't like web pages that refuse to reflow if the window size is changed. The site should print properly, and be mechanically convertible to a reasonably decent looking pdf.

The site needs to be friendly to search engines, and usable by screen readers. Yes, there are blind programmers, and at least one blind D programmer. It's obnoxious to make a site they cannot use.

I'm also old, and just don't like sites that use small fonts, cute fonts, blurry fonts, fonts with poor contrast, etc. They're hard, even painful, to read. When I was a kid writing letters to my aged relatives, my mom told me that they'd struggle to read typical handwriting, and that it's nice to use a typewriter instead. I always remembered that advice, and when I started using word processors for letters, the ones I'd send to them I'd always enlarge the font quite a bit. Web sites should avoid setting specific font sizes, so low vision users can enlarge it.

I recently completed a revamp of the digitalmars site that got rid of the table based layout in favor of using floating CSS layout. The result looks a bit nicer, and the printing should be much better.


> My sole problem with D is one that's probably impossible to address: the lack of libraries.  When I need libraries, I usually end up using some other language.  But it sure isn't the web page.
> 
> (DSource is marvelous, but most of the libraries listed appear to be either moribund or morbid.)

The library situation hopefully will get better over time.

And thanks for the kind words about the site (!), it is nice to hear them.

On 5/16/10 22:02, Charles Hixson wrote:
> On 05/15/2010 06:13 PM, BCS wrote:
>> 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.
>>
>>
> /usr/bin is for system installed executables. It's bad practice to put
> other things there. I could see installing them to /usr/local/bin ,
> /usr/opt/bin or /home/$USER/bin, but otherwise just leaving them where
> they're unzipped is quite reasonable. (Each of the approaches has their
> own particular reason why they're a good idea. E.g. /usr/local/bin is
> easy to share with other users on the system. I'm not sure why
> /usr/opt/bin, but some have, historically, preferred it. /home/$USER/bin
> allows sharing libraries within a single user. And just leaving it where
> you unzipped it facilitates having multiple versions of the same program
> available.)
>
> P.S.: Does D actually allow you to just run from the unzipped folder?
> Earlier versions required a global library installation. It's been
> awhile since I've done the tarball installation, so I don't recall. But
> it used to be impossible to have both D1 and D2 installed, much less
> D2.040 and D2.046.

Yes you can use D straight out of the unzipped folder. DMD looks for dmd.conf/ini in the same directory as the binary first, before it looks at the system level. I have both D1 and D2 installed, it works fine.

Andrej Mitrovic wrote:
> Maybe there's a plugin for Firefox that can force some colors on individual websites, I'll have a look later.
> 
	There is: Stylish. It allows you to completely redefine the style
sheet on a site by site basis (always assuming that the web site
uses css of course): https://addons.mozilla.org/fr/firefox/addon/2108/

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Ary Borenszweig wrote:
> Jérôme M. Berger wrote:
>> 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.
>>>
>>     Text is black here. But it is very thin, are you sure this isn't an
>> anti-aliasing issue?
> 
> It's #323232
> 
	Well, that's dark grey, not light grey like Walter said he gets...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

Hello Charles,

> On 05/15/2010 06:13 PM, BCS wrote:
> 
>> 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.
>> 
> /usr/bin is for system installed executables.  It's bad practice to
> put other things there.  I could see installing them to /usr/local/bin
> , /usr/opt/bin or /home/$USER/bin, but otherwise just leaving them
> where they're unzipped is quite reasonable.  (Each of the approaches
> has their own particular reason why they're a good idea.  E.g.
> /usr/local/bin is easy to share with other users on the system.

#if you are assuming DMD is being installed by an un privileged user

By all means, run it from where it got unziped. In fact if I were admin on the system I'd discourage anyone from running binaries owned by another user. If they want it but can't talk me into installing it for everyone, then build your own. I think there might be security problems with doing it the other way.

#else

Follow the lead of most every other program out there and put things where they belong.

#endif


> I'm
> not sure why /usr/opt/bin, but some have, historically, preferred it.
> /home/$USER/bin allows sharing libraries within a single user.  And
> just leaving it where you unzipped it facilitates having multiple
> versions of the same program available.)
> 

-- 
... <IXOYE><

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, done. It couldn't be simpler.

I have a script that does this:

unzip dmd.1.0xx.zip
chmod +x dmd/linux/bin/{dmd,dumpobj,obj2asm,rdmd,shell}
zip -r dmd.1.0xx.zip dmd

The standard distribution is rather amateurish. Zip supports the executable flag but for some reason the compiler has negative attitude towards Linux users. Maybe it's supposed to boost the sales of the Windows port?

Charles Hixson wrote:

> The D web pages are a marvel of clarity and utility.  Compare them to the Python web pages, which I rate a second best.  Things are documented with relative clarity, one can generally find what one needs with a bit of searching, even if one doesn't know what it's named.

The site looks like it was created using some generic boring documentation tool with a basic minimalistic style template. It might attract some developers who think that javadoc or doxygen looks a bit too artistic for their taste and their largest goal in life is to win the international dryness competition. The content of the documentation is a bit too grammar oriented. Hopefully the coming book will solve this issue.

Hello linux,


> The site looks like it was created using some generic boring
> documentation tool with a basic minimalistic style template. It might
> attract some developers who think that javadoc or doxygen looks a bit
> too artistic for their taste and their largest goal in life is to win
> the international dryness competition. The content of the
> documentation is a bit too grammar oriented. Hopefully the coming book
> will solve this issue.

For documentation, my primary requirements are that it be clear, correct and informative. A fair distance after that comes nice prose and that it be at least as visually readable as a simple text file in a text editor. A *long* ways after that comes any style goals. I'll take an understandable document, done as a plain default HTML file over the best presentation anyone can do if it gets me even a moderate improvement in the first three points.

-- 
... <IXOYE><

""Jérôme M. Berger"" <jeberger@free.fr> wrote in message news:hspm5b$1h9f$2@digitalmars.com...
>

There's also Greasemonkey.