Re: dmd 1.061 and 2.046 release
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
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
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
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
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
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
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
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
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
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
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
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
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
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.