[OT] Web font sizing (was: dmd 1.061 and 2.046 release)
Nick Sabalausky wrote: "Walter Bright" wrote in message news:hspj3m$1c9...@digitalmars.com... 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. Correct. Indeed, here's a post I once made here http://www.facebook.com/group.php?gid=2384051749 -- "6. For partially sighted persons, there is no way to adjust text size. You say "wow, they are demanding", this is something really easy to do." Yes there is a way. Just stop using Internet Exploiter and get yourself a real web browser. But still -- But you could well ask: Is it right to punish people for using broken browsers? Especially if you're going out of your way to do so by specifying font sizes in pt or px. I've always told people it just shouldn't be done. Moreover, some have sensibly pointed out that web authors shouldn't change the body text size from the default, since the user's default is the size the user is comfortable with. But maybe it's acceptable if all you're doing is compensating for the font you've chosen looking a little bigger or smaller at the same point size than the default Times New Roman. That said: - somebody might have set a different font as default in browser settings or a user stylesheet - who decreed that the factory default in all graphical browsers shall be Times New Roman, anyway? Stewart.
Re: dmd 1.061 and 2.046 release
Jérôme M. Berger wrote: Ary Borenszweig wrote: Jérôme M. Berger wrote: Walter Bright wrote: 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? In Windows Vista at least, anti-aliasing (whether Standard or ClearType) clearly isn't a straight average, considering that zooming out doesn't cause it to fade. AIUI, part of M$'s patent on ClearType is about how it differs from straight average anti-aliasing by colour stripes. I don't really know how it works. Nor do I know how the anti-aliasing in other OSs compares. But there, there's also the issue of system gamma vs. CSS standard gamma (well, sRGB) and whether or not the browser corrects. It's #323232 Well, that's dark grey, not light grey like Walter said he gets... Which text? In the top half, most of the text is #33 (obscure grey, according to the VisiBone naming). In the bottom half, most of the text is #66 (dark grey) or #77. (Firefox 3.6.3, examined using Firebug) Stewart.
Re: dmd 1.061 and 2.046 release
> Regarding the stack trace, I don't like the idea of having it only in debug > mode... After battling with huge stack traces, there's another related feature that I'd like to have on default: stack trace compression. If a recursive function keeps calling itself, or two functions keep calling each other (other possibilities exist, but those two cover most cases), the stack trace can become too much long to print and read. So just looking at the latest stack frame printed and penultimate stack frame printed it can compress it, reporting only how many time the last one or the last two ones are repeated (the uncompressed stack trace can be obtained on request, that shows all the line numbers too). Bye, bearophile
Re: dmd 1.061 and 2.046 release
Charles Hixson wrote: > /usr/bin is for system installed executables. It's bad practice to put > other things there. Actually that is not the case. /usr/bin is for system installations and general practice when using a system with package management is to leave it for packages installed by the package manager. But is intended as the programs shared by all systems on the network and /usr/local/bin are the programs that are installed to the local machine. That is /usr would be mounted to a network drive, possibly read only, and administered by the main administrators. And /usr/local would be mounted to a harddrive in the machine /dev/sda1 allowing access to those using the system but not everyone on the network. It is not bad practice. If the setup works and you have a reason for doing it different from the norm all is well.
Re: dmd 1.061 and 2.046 release
"Simen kjaeraas" wrote in message news:op.vcvnwvmkvxi...@biotronic-pc.home... > > There is also the issue of the Phobos documentation not having the > updated top box. "D 2.0 Home" is labeled "D", "Library Reference" is > "Phobos", etc. > > Once you've gotten to the library documentation, it being labeled > Phobos is not that important, though. > As long as we're on the topic of minor issues on the digital mars site, there seems to be a stray '>' floating around in the header of the D1 Language Reference pages (also D1 Home and D1 Comparisons).
Re: dmd 1.061 and 2.046 release
Robert Jacques wrote: On Mon, 17 May 2010 21:03:02 -0400, Steven Schveighoffer wrote: Walter Bright Wrote: Steven Schveighoffer wrote: > The end result is, sometimes I can't find a link I clicked on before, > because I'm no longer on the exact right page -- the nav bar is totally > dependent on the current page! I agree, the nav bar changes from page to page. Not sure that's a problem, though. In theory it's not, but when links just mysteriously disappear even though other links in the same group remain, it doesn't make any sense. Yes, I agree that the nav bar should change to reflect the section you are in, but that's not what I'm talking about. It's trying to play mind tricks on me :) -Steve I find the biggest problem with the website is the Phobos documentation menu. For example, core.memory is listed as std.gc. And some modules aren't listed at all (like std.perf). There is also the issue of the Phobos documentation not having the updated top box. "D 2.0 Home" is labeled "D", "Library Reference" is "Phobos", etc. Once you've gotten to the library documentation, it being labeled Phobos is not that important, though. -- Simen
Re: dmd 1.061 and 2.046 release
On Mon, 17 May 2010 21:03:02 -0400, Steven Schveighoffer wrote: Walter Bright Wrote: Steven Schveighoffer wrote: > The end result is, sometimes I can't find a link I clicked on before, > because I'm no longer on the exact right page -- the nav bar is totally > dependent on the current page! I agree, the nav bar changes from page to page. Not sure that's a problem, though. In theory it's not, but when links just mysteriously disappear even though other links in the same group remain, it doesn't make any sense. Yes, I agree that the nav bar should change to reflect the section you are in, but that's not what I'm talking about. It's trying to play mind tricks on me :) -Steve I find the biggest problem with the website is the Phobos documentation menu. For example, core.memory is listed as std.gc. And some modules aren't listed at all (like std.perf).
Re: dmd 1.061 and 2.046 release
Walter Bright Wrote: > Steven Schveighoffer wrote: > > The end result is, sometimes I can't find a link I clicked on before, > > because I'm no longer on the exact right page -- the nav bar is totally > > dependent on the current page! > > I agree, the nav bar changes from page to page. Not sure that's a problem, > though. In theory it's not, but when links just mysteriously disappear even though other links in the same group remain, it doesn't make any sense. Yes, I agree that the nav bar should change to reflect the section you are in, but that's not what I'm talking about. It's trying to play mind tricks on me :) -Steve
Re: dmd 1.061 and 2.046 release
Jérôme M. Berger Wrote: > Andrej Mitrovic wrote: > > 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. > > OT: > > > > The funny thing about the Python website, is that I never managed to find a > > direct link to the package repo (pypi) from the main site. > > > There's a "Package Index" line in the left-hand menu on > http://python.org/ that links to http://pypi.python.org/pypi > > Jerome > -- > mailto:jeber...@free.fr > http://jeberger.free.fr > Jabber: jeber...@jabber.fr > > I've no idea how I missed that. Still, I wish they added a button on the left, it's much easier to notice.
Re: dmd 1.061 and 2.046 release
Steven Schveighoffer wrote: The end result is, sometimes I can't find a link I clicked on before, because I'm no longer on the exact right page -- the nav bar is totally dependent on the current page! I agree, the nav bar changes from page to page. Not sure that's a problem, though.
Re: dmd 1.061 and 2.046 release
Andrej Mitrovic wrote: > 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. > OT: > > The funny thing about the Python website, is that I never managed to find a > direct link to the package repo (pypi) from the main site. > There's a "Package Index" line in the left-hand menu on http://python.org/ that links to http://pypi.python.org/pypi 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
On Mon, 17 May 2010 14:08:05 -0400, Walter Bright wrote: Steven Schveighoffer wrote: On Mon, 17 May 2010 13:29:19 -0400, Andrej Mitrovic wrote: 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. OT: The funny thing about the Python website, is that I never managed to find a direct link to the package repo (pypi) from the main site. And yet if I google PyPI, and follow a link to pypi.python.org, a Package Index tab suddenly appears on the top left. If I click on another tab, it dissapears again. Needlessly inconsistent imo. (+ how are newbies supossed to find the libraries if they're not linked from the main site?) The D website's navigation bar suffers the same problems. I cannot reproduce such bad behavior. I meant that the bar is not consistent, clicking on different items makes the bar change inexcusibly. For example, from the page http://www.digitalmars.com/d/2.0/index.html, click on "All Forums" and see the bar change completely. The bar should remain consistent throughout the section. There are other cases, like click on 'const and immutable' from this page: http://www.digitalmars.com/d/2.0/lex.html The end result is, sometimes I can't find a link I clicked on before, because I'm no longer on the exact right page -- the nav bar is totally dependent on the current page! -Steve
Re: dmd 1.061 and 2.046 release
"bearophile" wrote in message news:hsqv52$18c...@digitalmars.com... > linux user: >>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?< > > The situation is different. It's for LLVM and GCC that Windows users look > like third-class citizens. What you are seeing is just DMD being a bit > more fair. > I'm of the firm optinion that any app that requires MSYS or MinGW to work on Windows is no more cross-platform than an app that requires Wine to run on Linux. Less so, in fact, since MSYS and MinGW are a royal f*&*&^% pain in the ass, and Wine isn't (not to the same degree, anyway). And then with LLVM, it goes another step further what with Windows exceptions continuing to be ignored. Well, it *is* backed by Apple...
Re: dmd 1.061 and 2.046 release
"linux user" wrote in message news:hsqcdg$4c...@digitalmars.com... > > Maybe it's supposed to boost the sales of the Windows port? > ...sales? ...of DMD? ...???
Re: dmd 1.061 and 2.046 release
Steven Schveighoffer wrote: On Mon, 17 May 2010 13:29:19 -0400, Andrej Mitrovic wrote: 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. OT: The funny thing about the Python website, is that I never managed to find a direct link to the package repo (pypi) from the main site. And yet if I google PyPI, and follow a link to pypi.python.org, a Package Index tab suddenly appears on the top left. If I click on another tab, it dissapears again. Needlessly inconsistent imo. (+ how are newbies supossed to find the libraries if they're not linked from the main site?) The D website's navigation bar suffers the same problems. I cannot reproduce such bad behavior.
Re: dmd 1.061 and 2.046 release
On Mon, 17 May 2010 13:29:19 -0400, Andrej Mitrovic wrote: 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. OT: The funny thing about the Python website, is that I never managed to find a direct link to the package repo (pypi) from the main site. And yet if I google PyPI, and follow a link to pypi.python.org, a Package Index tab suddenly appears on the top left. If I click on another tab, it dissapears again. Needlessly inconsistent imo. (+ how are newbies supossed to find the libraries if they're not linked from the main site?) The D website's navigation bar suffers the same problems. -Steve
Re: dmd 1.061 and 2.046 release
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. OT: The funny thing about the Python website, is that I never managed to find a direct link to the package repo (pypi) from the main site. And yet if I google PyPI, and follow a link to pypi.python.org, a Package Index tab suddenly appears on the top left. If I click on another tab, it dissapears again. Needlessly inconsistent imo. (+ how are newbies supossed to find the libraries if they're not linked from the main site?)
Re: dmd 1.061 and 2.046 release
On 17/05/10 15:16, linux user wrote: > for some reason the compiler has negative attitude towards Linux Maybe it's supposed to boost the sales of the Windows port? hahahahahahahahahahahahahahahahahahahahahahahah *gasp* hahahahahahahahahahahahahahahahahahahahahahahaahahahahah As bearophile says, the experience we get with DMD on Linux is by _far_ the best out of {Windows,Mac,Linux}.
Re: dmd 1.061 and 2.046 release
On 5/16/10 22:04, Walter Bright wrote: 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. About the font size, I like the font size that the D1 site uses better than the one that the D2 site uses. 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
But it seems true that the Linux version of dmd has come after the Windows one... So the situation is not perfectly balanced. Bye, bearophile
Re: dmd 1.061 and 2.046 release
linux user: >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?< The situation is different. It's for LLVM and GCC that Windows users look like third-class citizens. What you are seeing is just DMD being a bit more fair. Bye, bearophile
Re: dmd 1.061 and 2.046 release
On 2010-05-16 21:47, Nick Sabalausky wrote: "Walter Bright" 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. There's this idea called "Worse is Better", which you've no doubt heard of... sometimes when I am feeling gloomy I agree with it wholeheartedly. ;-) -- ~ Due to cutbacks, the light at the end of the tunnel is temporarily out of service. ~ http://tagzilla.mozdev.org v0.066
Re: dmd 1.061 and 2.046 release
"Walter Bright" 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.
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" 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
""Jérôme M. Berger"" wrote in message news:hspm5b$1h9...@digitalmars.com... > There's also Greasemonkey.
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. -- ... <
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 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.) -- ... <
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
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
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 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
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 05/15/2010 06:13 PM, BCS wrote: Hello Adam, On 5/15/10, Bernard Helyer 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
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
"BCS" wrote in message news:a6268ff13be78ccc28aed90f...@news.digitalmars.com... > Hello Nick, > >> "BCS" 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
Hello Nick, "BCS" 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. -- ... <
Re: dmd 1.061 and 2.046 release
"BCS" wrote in message news:a6268ff13bd08ccc27164400...@news.digitalmars.com... > Hello Adam, > >> On 5/15/10, Bernard Helyer 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.
Re: dmd 1.061 and 2.046 release
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.
Re: dmd 1.061 and 2.046 release
Hello Adam, On 5/15/10, Bernard Helyer 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. -- ... <
Re: dmd 1.061 and 2.046 release
On 5/15/10, Bernard Helyer 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.
Re: dmd 1.061 and 2.046 release
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.
Re: dmd 1.061 and 2.046 release
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.
Re: dmd 1.061 and 2.046 release
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.
Re: dmd 1.061 and 2.046 release
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.
Re: dmd 1.061 and 2.046 release
Sean Kelly: > I made this change a few days ago, after Brad suggested the same thing. > It was just a tad late for 2.046. With luck I'll have stack tracing > sorted out on Windows before 2.047 as well. Sometimes I complain, but I am very grateful for all the work you and others put in D and its libs. Thank you, bye, bearophile
Re: dmd 1.061 and 2.046 release
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. > > 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. > > 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. The link works for me (The getting started page) with Firefox. I agree about the colors, they're not the best combination, e.g. this piece of code gray on light-blue: http://developer.apple.com/iphone/library/samplecode/AdvancedURLConnections/Listings/ChallengeHandlers_AuthenticationChallengeHandler_m.html#//apple_ref/doc/uid/DTS40009558-ChallengeHandlers_AuthenticationChallengeHandler_m-DontLinkElementID_11 There's an option in Firefox to force the rendering of text using system defined colors. Try Tools>Options>Content tab>Colors button> and check "Use system colors" and uncheck "Allow pages to user their own colors". But this only works globally afaik. There's a Download button on top of those examples for a zipped collection of the samples, which is kind of neat actually. Maybe there's a plugin for Firefox that can force some colors on individual websites, I'll have a look later.
Re: dmd 1.061 and 2.046 release
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? Yes, because there is some legible black text on other parts of the page. Now click on "getting started documents", which brings you to a page that will not render in Explorer or Firefox, only Safari. Works fine here. Firefox 3.6.3 on Linux. 3.0.18 on Ubuntu.
Re: dmd 1.061 and 2.046 release
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 So I would say it's grey like the one you find in a banana's stone. ... http://blog.xkcd.com/2010/05/03/color-survey-results/
Re: dmd 1.061 and 2.046 release
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? > Now click on "getting started documents", which brings you to a page > that will not render in Explorer or Firefox, only Safari. > Works fine here. Firefox 3.6.3 on Linux. 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
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.
Re: dmd 1.061 and 2.046 release
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. 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. 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.
Re: dmd 1.061 and 2.046 release
Don, el 15 de mayo a las 09:47 me escribiste: > 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. Looks OK from that POV, my fear was that we had all phobos harcoded in the compiler to give hints. 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). I guess that would be too slow to be practical though, but maybe the compiler can generate a small index file (a reduced json with just symbol->module) and that can be pre-generated for phobos and distributed with the compiler. The good part of this is you can easily extend it for your libraries. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Just because you're paranoid, don't mean they're not after you.
Re: dmd 1.061 and 2.046 release
bearophile wrote: > Walter Bright: > > 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. > > In general I approve the idea of doing similar experiments. Often you > have enough information to choose well only when you try a feature. > > Regarding the stack trace, I don't like the idea of having it only in > debug mode. I like to always (on default) have a stack trace when > there is an error, but when the code is compiled in release mode. So > you tell the compiler when you don't want the stack trace, instead of > the opposite. > I made this change a few days ago, after Brad suggested the same thing. It was just a tad late for 2.046. With luck I'll have stack tracing sorted out on Windows before 2.047 as well.
Re: dmd 1.061 and 2.046 release
Walter Bright: > 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. In general I approve the idea of doing similar experiments. Often you have enough information to choose well only when you try a feature. Regarding the stack trace, I don't like the idea of having it only in debug mode. I like to always (on default) have a stack trace when there is an error, but when the code is compiled in release mode. So you tell the compiler when you don't want the stack trace, instead of the opposite. Bye, bearophile
Re: dmd 1.061 and 2.046 release
On 5/15/10 05:46, 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. How about generating a file with all imports of Phobos, ship the file with the compiler and then read from the file. Something like having a configuration file that is set up to work with everything from Phobos to start with, then the user can add more things if he/she likes to.
Re: dmd 1.061 and 2.046 release
On 5/15/10 11:00, 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? 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. It won't render at all in Explorer. The D web site is rather pedestrian, but at least it's easy on the eyes.
Re: dmd 1.061 and 2.046 release
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.
Re: dmd 1.061 and 2.046 release
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.
Re: dmd 1.061 and 2.046 release
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.
Re: dmd 1.061 and 2.046 release
Walter Bright, el 14 de mayo a las 14:42 me escribiste: > Ary Borenszweig wrote: > >Walter Bright wrote: > >>This is to fix the spell corrector speed problems and several > >>forward reference bugs. > >> > >>http://www.digitalmars.com/d/1.0/changelog.html > >>http://ftp.digitalmars.com/dmd.1.061.zip > >> > >> > >>http://www.digitalmars.com/d/2.0/changelog.html > >>http://ftp.digitalmars.com/dmd.2.046.zip > > > >Add hints for missing import declarations. > > > >What does that mean? > > Write the following program: > > --- > void main() > { > writeln("hello world!"); > } > --- > > compile it and see what happens. I think it'll be clear! I saw the patches, and having all hardcoded in the compiler doesn't seems like a good idea =/ -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- ¿Cómo estais? ¿Cómo os senteis hoy 29 del membre de 1961 día en que conmemoreramos la nonésima setima nebulización del martir Peperino Pómoro junto al Rolo Puente en la ciudad de Jadad? -- Peperino Pómoro
Re: dmd 1.061 and 2.046 release
This release seems to work, thank you. >Bugzilla 1001: print stack trace (in debug mode) when program die< Can you or someone else show me an example of how to activate stack tracing? For example on Windows I have written this small program: import std.c.stdlib: atoi; void main() { int x = atoi("0.0"); int y = 10 / x; } I compile it with: dmd -debug test.d If I run it it prints: object.Error: Integer Divide by Zero This other program gives the same output: import std.c.stdlib: atoi; import core.runtime; void main() { Runtime.traceHandler = &defaultTraceHandler; int x = atoi("0.0"); int y = 10 / x; } Is this a Linux feature only for now, as Sean says in bug 1001? If so, then the changelog can specify it's a linux thing only. Bye, bearophile
Re: dmd 1.061 and 2.046 release
Ary Borenszweig wrote: Walter Bright wrote: This is to fix the spell corrector speed problems and several forward reference bugs. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.061.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.046.zip Add hints for missing import declarations. What does that mean? Write the following program: --- void main() { writeln("hello world!"); } --- compile it and see what happens. I think it'll be clear!
Re: dmd 1.061 and 2.046 release
Walter Bright wrote: This is to fix the spell corrector speed problems and several forward reference bugs. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.061.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.046.zip Add hints for missing import declarations. What does that mean?
dmd 1.061 and 2.046 release
This is to fix the spell corrector speed problems and several forward reference bugs. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.061.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.046.zip