Re: dcollections 1.0 and 2.0a beta released
On Wed, 26 May 2010 10:06:32 -0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 24/05/2010 16:45, Andrei Alexandrescu wrote: In the past I have built a C++ library that abstracted features of the OS. My goal was to make it possible to dynamically load a module that abstracted things like setting the IP address of a network interface. My modules used std::string instead of char * to lookup services to get objects that implement the interface. Big mistake. On a later version of the standard C++ runtime, the private implementation of std::string changed, so the dynamically loaded libraries crashed horribly. No change in string's interface, just the private stuff changed, but because it's a template, the code that uses it necessarily has to be aware of it. We ended up ditching the standard C++ library's version of string, and used STLPort so we could control the library. I envision this same sort of problem would be likely with D collection objects that were not used via interfaces. I see no problem retrofitting a no-interface container into a formal interface if so needed. I don't understand this discussion: isn't the reason above pretty much a dead-on hard requirement for the collections to have interfaces? Something like, for example, an interface version of the range traits? Only if you wish to have binary compatibility with dynamic libs. Such a thing isn't likely today since dynamic libs aren't very well supported in D, and even phobos or dcollections isn't a dynamic lib. And I have specifically decided not to use interfaces with ranges because that makes them reference types. Ranges work well as value types, but not well as reference types. Therefore, to use dcollections as interfaces, you must not require the range traits. -Steve
Re: Bug fix week
Don wrote: snip IMHO, one of the most important bugs to fix is actually a spec bug: 4056 Template instantiation with bare parameter not documented snip Why single out that one? This is the one that needs fixing most of all: http://d.puremagic.com/issues/show_bug.cgi?id=677 Stewart.
Re: Bug fix week
Stewart Gordon wrote: Don wrote: snip IMHO, one of the most important bugs to fix is actually a spec bug: 4056 Template instantiation with bare parameter not documented snip Why single out that one? Because it's a feature that is used in almost every non-trivial D2 program, and the spec gives no hint that it even exists. Without it, you can't even make sense of many of the Phobos docs. It's an absolute disaster for anyone taking a first look at the language -- something which we expect to happen frequently in the next few weeks.
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: snip 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.
[OT] Web font sizing (was: dmd 1.061 and 2.046 release)
Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hspj3m$1c9...@digitalmars.com... snip 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. snip 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: [OT] Web font sizing
Stewart Gordon wrote: 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? With style sheets, you can set the font size as larger or smaller than the default. This should be good enough. Setting fonts as pixel sizes is just wrong.
