Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Nick Sabalausky
BCS n...@anon.com wrote in message 
news:a6268ff13be78ccc28aed90f...@news.digitalmars.com...
 Hello Nick,

 BCS n...@anon.com wrote in message
 news:a6268ff13bd08ccc27164400...@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.




Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Charles Hixson

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





Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Charles Hixson

On 05/15/2010 06:13 PM, BCS wrote:

Hello Adam,


On 5/15/10, Bernard Helyer b.hel...@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.





Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Walter Bright

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.


Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Jacob Carlborg

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.hel...@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.




Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Jérôme M. Berger
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:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature


Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Jérôme M. Berger
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:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature


Re: dmd 1.061 and 2.046 release

2010-05-16 Thread BCS

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





Re: dmd 1.061 and 2.046 release

2010-05-16 Thread linux user
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. 


Re: dmd 1.061 and 2.046 release

2010-05-16 Thread BCS

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





Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Nick Sabalausky
Jérôme M. Berger jeber...@free.fr wrote in message 
news:hspm5b$1h9...@digitalmars.com...


There's also Greasemonkey. 




Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Nick Sabalausky
Walter Bright newshou...@digitalmars.com wrote in message 
news:hspj3m$1c9...@digitalmars.com...

 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 agree a lot with most of this, but any web browser that doesn't scale 
so-called fixed-size fonts when zooming has a broken, archaic zoom function, 
period.


 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.


Speaking as a web developer, I've found that floating CSS is irritatingly 
gimped compared to tables when trying to adjust how things flow upon 
resizing. (Speaker as a web user, I've never cared one bit whether a site 
used floating CSS vs tables.)




Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Walter Bright

Nick Sabalausky wrote:
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.




Speaking as a web developer, I've found that floating CSS is irritatingly 
gimped compared to tables when trying to adjust how things flow upon 
resizing. (Speaker as a web user, I've never cared one bit whether a site 
used floating CSS vs tables.)


Doing them as floating CSS makes it possible to nodisplay the navigation 
sections when formatting for print.


The whole HTML/CSS design is such a horrific kludge it's a wonder it works at 
all.


Re: dmd 1.061 and 2.046 release

2010-05-16 Thread Nick Sabalausky
Walter Bright newshou...@digitalmars.com wrote in message 
news:hsqhhg$fm...@digitalmars.com...
 Nick Sabalausky wrote:
 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.


 Speaking as a web developer, I've found that floating CSS is irritatingly 
 gimped compared to tables when trying to adjust how things flow upon 
 resizing. (Speaker as a web user, I've never cared one bit whether a site 
 used floating CSS vs tables.)

 Doing them as floating CSS makes it possible to nodisplay the navigation 
 sections when formatting for print.


Ahh, good point.

 The whole HTML/CSS design is such a horrific kludge it's a wonder it works 
 at all.

That's exactly how I feel about 99% of internet technologies (including 
HTML/CSS, of course). And they're all horrific kludges *on top* of horrific 
kludges - I almost wish I never learned how ethernet, *ahem*...works. It's 
a wonder I have any sanity left.