Slashdot Mirror

Actually, it was ISO/IEC 10646 that started out as a Han Unification project. Unicode actually began as a universal character encoding standard. Between version 1.0 and 1.01, Unicode merged with 10646, and they became one big squabbling family, where everyone got to act like they were Unicode, but got named after 10646. The Tibetans got lost when they moved into the new house, and somehow the Koreans ended up being triplets, but they eventually found their way back home. Eventually the Cherokees brought some native flair, while the Mormons made everyone stop drinking, at least for a while. Eventually the Chinese decided they needed a place for all their ancestors ashes, and the Japanese kids spread lolcats all over the place. Of course, now we've got French stenographers and old Hungarians knocking at the door, trying to get in, not to mention a bunch of African tribesmen and some more Minoans trying to force the gate.

PS, the "pictographs" are encoded because of a need to catalogue all of those emoji-laden text messages they send in Japan.

Actually, it was ISO/IEC 10646 that started out as a Han Unification project. Unicode actually began as a universal character encoding standard. Between version 1.0 and 1.01, Unicode merged with 10646, and they became one big squabbling family, where everyone got to act like they were Unicode, but got named after 10646. The Tibetans got lost when they moved into the new house, and somehow the Koreans ended up being triplets, but they eventually found their way back home. Eventually the Cherokees brought some native flair, while the Mormons made everyone stop drinking, at least for a while. Eventually the Chinese decided they needed a place for all their ancestors ashes, and the Japanese kids spread lolcats all over the place. Of course, now we've got French stenographers and old Hungarians knocking at the door, trying to get in, not to mention a bunch of African tribesmen and some more Minoans trying to force the gate.

PS, the "pictographs" are encoded because of a need to catalogue all of those emoji-laden text messages they send in Japan.

Actually, it was ISO/IEC 10646 that started out as a Han Unification project. Unicode actually began as a universal character encoding standard. Between version 1.0 and 1.01, Unicode merged with 10646, and they became one big squabbling family, where everyone got to act like they were Unicode, but got named after 10646. The Tibetans got lost when they moved into the new house, and somehow the Koreans ended up being triplets, but they eventually found their way back home. Eventually the Cherokees brought some native flair, while the Mormons made everyone stop drinking, at least for a while. Eventually the Chinese decided they needed a place for all their ancestors ashes, and the Japanese kids spread lolcats all over the place. Of course, now we've got French stenographers and old Hungarians knocking at the door, trying to get in, not to mention a bunch of African tribesmen and some more Minoans trying to force the gate.

PS, the "pictographs" are encoded because of a need to catalogue all of those emoji-laden text messages they send in Japan.

Actually, it was ISO/IEC 10646 that started out as a Han Unification project. Unicode actually began as a universal character encoding standard. Between version 1.0 and 1.01, Unicode merged with 10646, and they became one big squabbling family, where everyone got to act like they were Unicode, but got named after 10646. The Tibetans got lost when they moved into the new house, and somehow the Koreans ended up being triplets, but they eventually found their way back home. Eventually the Cherokees brought some native flair, while the Mormons made everyone stop drinking, at least for a while. Eventually the Chinese decided they needed a place for all their ancestors ashes, and the Japanese kids spread lolcats all over the place. Of course, now we've got French stenographers and old Hungarians knocking at the door, trying to get in, not to mention a bunch of African tribesmen and some more Minoans trying to force the gate.

PS, the "pictographs" are encoded because of a need to catalogue all of those emoji-laden text messages they send in Japan.

Shouldn't be too long before the Mordor script "Tengwar" is formally accepted into unicode ...

But you still can't utter it here because slashcode is just a pile of ç, ÐоÐно, okay then U+7caa!
At least I can still call it cachu.

Introduce Elvish as a language option?

Which elvish language? If you mean Sindarin, the language of Tolkien's elves, that can't happen until 1. the Unicode Consortium approves the tengwar proposal, and 2. operating system vendors implement rendering support for tengwar.

[A strictly conforming program] shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.

Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign. ...
-- minimum value for an object of type short int
                        SHRT_MIN -32767 // -(2^15-1)

-- maximum value for an object of type short int
                        SHRT_MAX +32767 // 2^15-1

Even better... according to the article, apparently that keyboard "allows convenient use of any language -- Cyrillic, Ancient Greek, Georgian, Arabic, Quenya, hiragana, etc. ". Technically, you don't need a keyboard for a language (as opposed to a script), but if they mean what I think, a piece of hardware that can finally push the Tengwar through the Unicode Consortium would be nice.

They've been rotting there since 1989...

What would you expect OpenOffice (or any other app!) to do with an SGML document whose particular set of elements and entities it does not know?

Nothing, of course! That's why, if I had to archive data in such a format for the long term, I'd expect to include a reader and/or a schema (i.e. DTD for the SGML in question). Yes, for ODF both reader and schema will probably available in the far future. But, over 25+ years, it's not certain. Could you guarantee it? Personally?

The schema is available available from ISO, if you like officially looking things, but you can get it from many other sources. For example, http://std.dkuug.dk/keld/iso26300-odf/ has the actual official ISO document. Just get a copy and save it with your files.

As for the reader: the fun thing is, you can write your own, because the schema is fully documented. Now, by ``write your own'' I do not mean necessarily that you yourself write it: you can pay someone to do it, you can ask nicely thatsomeone does it for free, and so on.

One is support for multiple return values, which I love.

Have you seen the new tuple library being added to C++? See here. GCC 4.0 already supports them. At first I was reading through and wasn't that impressed, but then I saw things like:

#include <tr1/tuple>
#include <tr1/functional>
using namespace std::tr1;

tuple<int,char,double> doStuff(); ...
{
int a; char b;
tie(a,b,ignore)=doStuff();
}

Yes, the above works. And with inlining or the named return value optimization, it doesn't slow down your program. And it shuts up those people who don't like returning data in references :)

I was reading through the list of things already in the first library addition and got pretty excited. see here. Already added are reference-counted smart pointers (much more impressive than the usual), regexp, standarized hash tables, a new parameter binder, additional support for template metaprogramming and a few other things.

In the pipeline for TR2 are lambda functions (see Boost.lamba, say: Function F= _1*_2) and a lot of other fun stuff.

Heh. And Java is barely on templates :P

I do, in fact, research my posts before I hit "Submit". I'm fully aware of just how big the Supplementary Multilingual Plane is getting in the newest specs -- hell, the undeciphered Indus valley script made it in there, albeit only as a preliminary proposal so far. However, there are still a handful of languages out there that aren't represented, including a few obscure but living languages (unfortunately I can't recall any of them, but we're talking <100 speakers left).

I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages

Just in case you don't know, Lisp is a compiled language and not slow, especially when compiled with appropriate type declarations. Only the very most early dialects (forty or so years ago) were interpreted-only. Some interpreted implementations exist now, but that's a choice of the implementor, not a requirement of the language.

I disagree with your remarks about ugly and illegible, too, but that's personal taste, I guess. My views on all this are copiously documented in my Slashdot interview, Part I and Part II.

However, what really disappointed me in this chart was its unscientific and subjective decision about what to include and how to present things.

Some of the arrows stop mysteriously so far leftward (as if to hint "this language is no longer used). That's apparently a subjective assessment on their part offered with no foundation, and irresponsibly inappropriate in a document intended to fairly describe history. Common Lisp's arrow stops short for reasons I don't understand since it continues in commmercial use today.

I didn't check the table thoroughtly, but the absence of mention of the fact that Scheme influences Common Lisp seems odd since it's a well-advertised truth.

The omissions of ISLISP, an ISO standard (ISO/IEC 13816:1997) is also surprising and shows poor researching. The absence of Interlisp, Portable Standard Lisp (PSL), Eulisp, Gnu Emacs-Lisp (in spite of huge distribution world-wide as customization substrate for Emacs), and Xlisp (hugely distributed as part of Autocad) as important dialects is similarly sad.

O'Reilly sells books and has for a long time requested outright that no Lisp authors approach them. I and others have long noted that it has an apparent chip on its shoulder about Lisp, and little surprise they couldn't help exposing that bias in their chart. They want you to think the books they sell define the market. But that's just not so, especially when they voluntarily close their eyes to what's going on around them.

People should look skeptically at a company that wants a reputation as a "documentation" company yet so easily falls victim to its own commercial decision to close its eyes to this language family's achievements (such as an international standard).

A quick glance at other parts of the table leave out many other important languages and dialects, with no explanation of their rationale. Just for example: Teco, which strongly influenced Emacs-Lisp. I don't see HyperTalk there, either, even though I thought it influential. And there were many dialects of BASIC and LISP that are too small to mention, yet variations on the Unix shell language like bash are apparently worth mention. I guess that more reflects O'Reilly's sales than an attempt to explain history.

As a consequence, I have to regard this chart of theirs as commercial eye candy and not a properly scholarly work. I think it's a shame that Slashdot has chosen to give it all this free press. I'm sure that's just what they were hoping. And I'm sure they just don't care about their errors, omissions, and biases. I imagine they just want to sell books, and that all this free press will do just that.

Me, I buy my books from other sources. And I recommend you do, too.

Two meetings annually, technical report on library extensions is currently in draft and publicly available (N1647), dozens of people showing up. Have a look at C++ 2004 papers, just this year there have been 88 contributions. Another measure is also telling. Boost is serving as a testbed for the new library features, and its mailing list easiliy has dozens of postings daily. C++0x will get these features, but only after they have been field-tested.

The proposal is here, on the ISO site. Why yes, I did have this bookmarked, why d'ya ask?

Constraints, however, are something that I think are a generally good idea.

Stroustrup seems to be thinking of them for C++0x. See this paper, for example, from the C++ Standards Committee papers.

there's also ANSI X3.110 which appears to be very different from iso 8859-anything or windows 1252

Sorry, just saying luminaries wanted it banished and then not explaining left a bad taste in my mouth. I should have provided this link to a Herb Sutter article called "Can't Afford Export" (regarding getting rid of the export keyword) in the original post.

This isn't the only such article, but it's the only one I'm finding on a brief search; IIRC, I think I've also seen similar stances from Meyers and Dewhurst. Not certain, though, 'cause I can't seem to find them (yay 30 second searches.)

Tengwar has thousands of users, and quite possible more then cuniform. Do scholars of twenth century literature and sociology matter less then scholars of Babylon?

If one were to provide a list of ten names of scholars working in an academic environment on languages written in Tengwar (not just on Tolkien, but on his languages) - I know there are some, indeed I'm thinking of picking up the book "Tolkien's Languages"); and provide a list of three literary works not by J.R.R. Tolkien in a Tengwar language (or point to two literary works by Tolkien in Tengwar languages beyond the Ring poem itself), I'd say no, they probably aren't. But at the moment, the corpus of literary, scientific, historical, and commercial significance is entirely the work of one man, and so it remains effectively an idiolect. Other users of the language are either Tolkien scholars or Tolkien readers using the language in the context of Tolkien's work. So I doubt that sharing of large corpora across disciplines and user communities, and the other things that a non-PUA encoding would be used for, are currently necessary to the user community.

There are more Chinese characters encoded in Unicode then every other script combined. They've got their fair share.

Let's say that a Chinese writer is born who is at least as important as Tolkien. In his works, he uses unencoded (new or not) standard Chinese characters. Are you saying that it is more important to get Tolkien's fictional scripts, which are not the actual medium of his literary work, but are in fact part of the "message" of his literary work, encoded than it would be to get the new characters from the hypothetical Chinese writer, which as postulated WOULD BE part of the actual medium of his work, encoded?

By the way, I believe you're mischaracterizing the arguments against the hieroglyphic encodings: they tend to be "we don't understand the repertoire well enough" or "we don't agree that the proposed repertoire properly represents the script," not "hieroglyphics should never be encoded in Unicode." Here's the relevant paragraph of the objection:

At the present stage of research in Egyptian hieroplyphic script, one always has to expect new characters and changes in what we currently perceive to be an abstract character. This means that the clumsy instrument of standardization cannot meet the demands of the incomplete stage of research in Egyptology. A far more appropriate means would be fonts registered by Egyptologists, which can be very quickly expanded and modified within the science itself, as is the case with the directories of the Standard and the Extended Library that Hans van den Berg, Utrecht, is running within the framework of the program for printing hieroglyphs Glyph (please note the name). Only after the repertoires will have stabilized within Egyptology itself, further steps can be sensible.

Fine, it's disinformation.

Do you know the word "wrong"? You seem to want to impune ill motive to me.

Cunieform and Hieroglyphic Egyptian are used by thousands of scholars;

That's far different from thousands of native speakers; Tengwar has thousands of users, and quite possible more then cuniform. Do scholars of twenth century literature and sociology matter less then scholars of Babylon? Egytologists have actively discouraged the addition of Hieroglyphics to Unicode; should we force Unicode on everyone before encoding Tengwar?

Coptic, which is being reencoded

Right; so Coptic is encoded, and has been encoded for a long time. Now we should make sure Unicode is perfect before encode Tengwar.

the current repertoire of Chinese at any point in time is a closed system

The current repertoire of paintings at any point in time is a closed system too. That's a moot point. There can be new Chinese characters invented, and are on a regular basis. Thus Chinese is not a closed system. There are more Chinese characters encoded in Unicode then every other script combined. They've got their fair share. Besides that, there is the IRG which handles Chinese characters completely parellel to any of these fictional scripts.

Er, sorry if I just slashdotted you guys.

There is space reserved for Egyptian Hieroglyphics in "Plane 1" (i.e. 00010000 - 0001FFFF) of ISO 10646.

ISO 10646 is a 32-bit character mapping standard which includes Unicode as "Plane 0" (00000000 - 0000FFFF).

Here's some more info:
http://www.dkuug.dk/JTC1/SC2/WG2/docs/n2461.pdf

I'm not sure if anything really supports ISO 10646 characters yet, though it can be encoded as UTF-8.

If they can do this right, I'll be very happy. After all, Java's main advantage over C++ is their abstracting away pointers. Course Java is still slow, and that pointer abstraction is expensive, in terms of garbage collection, program speed, and (most important) huge memory footprint. C++ pointers are a major PITA, but they are fast 'n cheap. How fast 'n cheap are smart pointers?????

Sutter and Plum advocate dropping export, the reason the implementation you cite took so long, in this paper.

The development cycle of embedded software does not easily lend itself to the trial-and-error style of programming and debugging, so a stubborn C++ compiler that catches as many errors as possible at compile-time significantly reduces the dependence on run-time debugging, executable run-time support and compile/download/test cycles.

This saves untold hours at the test bench, not to mention strain on PROM sockets.

Inconsistent capitalization of method names. I guess you put the 'semi-standard' names in lower case for consistency with the STL containers, but then having other methods in UpperCaseStyle looks weird.

Why use my_pair instead of std::pair?

I couldn't convince myself that your hashing itself was correct, especially when deleting items. Rather than 'chaining' items when a hash collision occurs (using a list of some sort), you probe for an empty bucket with (hashLocation + hashIncrement)%maxLength. This means that the delete function must probe ahead and see if other objects need to be moved into its place. But I don't see how that works from looking at the code.

I ended up writing my own, based (loosly) on Matt Austern's standard library proposal, using the doublely linked list scheme. It turned out to be very elegant, the iterator type is just list::iterator, so no need to write a custom iterator class. The only thing I didn't get right is the complexity requirements for the bucket interface, but I don't use that anyway so I havn't bothered trying to fix it.

So unless you are using a non-Unicode, non-ISO-Latin encoding there are no printable characters in that range, and if you're using another character you will need to remap the characters before considering any of the rules in the XML spec anyway, since those rules refer to the unicode codepoints.

But, unfortunately, the very commonly used Windows codepage 1252 puts printable glyphs in that code point range. Rather, recent versions of CP 1252 (not all versions of CP1252 are the same) have put things like trademark signs in that character codepoint range. Keep in mind that Microsoft still dominates the computer software industry more so than IBM and their attempts to keep things open and standards body approved.

actually, unicode decided not to encode the klingon characters for several reasons. the movie producers don't use them consistently and the creators drew two very different alphabets, neither of which is widely used by the fanfic community which uses the latin transliteration. this is documented on the proposed characters page.

proposal to encode klingon

there has to be some organization to do the same for C/C++ or it will surely grow old and die

It's called the ISO C++ Standard Committee. The members meet regularly and are comprised of the world's C++ experts.

GUI's are as standard as iostreams now, yet there is no standard for programming GUI's

If you are looking for a C++ standard in GUIs, then you will most likely go to the grave with that wish. C++ (like it's older sibling, C) is not designed as a language to handle these platform-specific functions. Many people (yourself seemingly included) seem to think that this means C++ is somehow defunt, archaic, useless, etc. The fact is that the language is actually designed to decouple itself from such functionality, leaving the major platfom-specifics up to the implementer of the compiler/environment. I like it this way, many C++ developers the world over like it this way, and I think we all would be upset if it changed.

Read The Design and Evolution of C++ sometime. It will open your eyes to the realization that C++ is not an environment like Java, but just a basic language to assist you in creating your environment.

Australia

ftp://ftp.planetmirror.com/pub/Mandrake/8.2/i586/ (Brisbane)
Austria

ftp://ftp.univie.ac.at/systems/linux/Mandrake/8.2/ i586/ (Vienna)

ftp://gd.tuwien.ac.at/pub/linux/Mandrake/8.2/i586/ (Vienna)
Belgium

ftp://ftp.belnet.be/packages/mandrake/8.2/i586/
Costa Rica

ftp://ftp.ucr.ac.cr/pub/Unix/linux/mandrake/Mandra ke/8.2/i586/
Czech Republic

ftp://ftp.cesnet.cz/OS/Linux/Mandrake/mandrake/8.2 /i586/ (Brno)

ftp://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586/ (Brno)

ftp://klobouk.fsv.cvut.cz/pub/linux-mandrake/Mandr ake/8.2/i586/ (Prague)

ftp://mandrake.redbox.cz/Mandrake/8.2/i586/

ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Mandrake/m andrake/8.2/i586/ (Prague)

http://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586/ (Brno)
Denmark

ftp://ftp.dkuug.dk/pub/mandrake/8.2/i586/ (Koebenhavn)

ftp://ftp.sunsite.dk/mirrors/mandrake/8.2/i586/ (Aalborg)
Estonia

ftp://ftp.aso.ee/pub/os/Linux/distributions/mandra ke/8.2/i586/
Finland

ftp://ftp.song.fi/pub/linux/Mandrake/8.2/i586/ (Espoo)
France

ftp://ftp.ciril.fr/pub/linux/mandrake/8.2/i586/ (Nancy)

ftp://ftp.club-internet.fr/pub/unix/linux/distribu tions/Mandrake/8.2/i586/ (Paris)

ftp://ftp.info.univ-angers.fr/pub/linux/distributi ons/mandrake/8.2/i586/ (Angers)

ftp://ftp.lip6.fr/pub/linux/distributions/mandrake /8.2/i586/ (Paris)

ftp://ftp.proxad.net/pub/Distributions_Linux/Mandr ake/8.2/i586/ (Paris)

ftp://ftp.u-strasbg.fr/pub/linux/distributions/man drake/8.2/i586/ (Strasbourg)

ftp://linux.ups-tlse.fr/Mandrake/8.2/i586/ (Toulouse)
Germany

ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/Mandra ke/8.2/i586/ (Esslingen)

ftp://ftp.de.uu.net/pub/linux/mandrake/8.2/i586/

ftp://ftp.fh-giessen.de/pub/linux/mandrake/8.2/i58 6/ (Giessen)

ftp://ftp.fh-wolfenbuettel.de/pub/os/linux/mandrak e/dist/8.2/i586/ (Wolfenbuettel)

ftp://ftp.gwdg.de/pub/linux/mandrake/8.2/i586/ (Goettingen)

ftp://ftp.join.uni-muenster.de/pub/linux/distribut ions/mandrake/8.2/i586/ (Muenster)

ftp://ftp.leo.org/pub/comp/os/unix/linux/Mandrake/ Mandrake/8.2/i586/ (Munchen)

ftp://ftp.tu-chemnitz.de/pub/linux/mandrake/8.2/i5 86/ (Chemnitz)

ftp://ftp.tu-clausthal.de/pub/linux/mandrake/8.2/i 586/ (Clausthal)

ftp://ftp.uasw.edu/pub/os/linux/mandrake/dist/8.2/ i586/ (Wolfenbuettel)

ftp://ftp.uni-bayreuth.de/pub/linux/Mandrake/8.2/i 586/ (bayreuth)

ftp://ftp.uni-kassel.de/pub/linux/mandrake/8.2/i58 6/ (Kassel)

ftp://ftp.uni-mannheim.de/systems/linux/mandrake/8 .2/i586/ (Mannheim)

ftp://ftp.vat.tu-dresden.de/pub/Mandrake/8.2/i586/ (Dresden)

ftp://ramses.wh2.tu-dresden.de/pub/mirrors/mandrak e/8.2/i586/ (Dresden)

ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/ mandrake/8.2/i586/ (Aachen)
Greece

ftp://ftp.duth.gr/pub/Mandrake/8.2/i586/ (Thrace)

ftp://ftp.ntua.gr/pub/linux/mandrake/8.2/i586/ (Athens)
Hong Kong

ftp://ftp.wisr.eie.polyu.edu.hk/linux/mandrake/8.2 /i586/
Hungary

ftp://ftp.linuxforum.hu/mirror/Mandrake/8.2/i586/
Ireland

ftp://ftp.esat.net/pub/linux/mandrake/8.2/i586/
Italy

ftp://bo.mirror.garr.it/mirrors/Mandrake/8.2/i586/ (Bologna)

ftp://ftp.edisontel.it/pub/Mandrake_Mirror/Mandrak e/8.2/i586/
Latvia

ftp://ftp.latnet.lv/linux/mandrake/8.2/i586/
Netherlands

ftp://ftp.nl.uu.net/pub/linux/mandrake/8.2/i586/

ftp://ftp.nluug.nl/pub/os/Linux/distr/Mandrake/Man drake/8.2/i586/

ftp://ftp.surfnet.nl/pub/os/Linux/distr/Mandrake/M andrake/8.2/i586/

ftp://ftp.wau.nl/pub/Mandrake/8.2/i586/ (Wageningen)
Poland

ftp://ftp.ps.pl/mirrors/mandrake/8.2/i586/ (Szczecin)

ftp://ftp.task.gda.pl/pub/linux/Mandrake/8.2/i586/ (Gdansk)
Portugal

ftp://ftp.dei.uc.pt/pub/linux/Mandrake/Mandrake/8. 2/i586/ (Coimbra)

ftp://tux.cprm.net/pub/Mandrake/8.2/i586/
Russia

ftp://ftp.chg.ru/pub/Linux/mandrake/8.2/i586/ (Chernogolovka)
Singapore

ftp://ftp.singnet.com.sg/opensource/linux/Mandrake /8.2/i586/
Slovakia

ftp://spirit.profinet.sk/mirrors/Mandrake/8.2/i586 / (Bratislava)
Spain

ftp://ftp.cesga.es/pub/linux/Mandrake/8.2/i586/ (Galicia)

ftp://ftp.cica.es/pub/Linux/Mandrake/8.2/i586/ (Sevilla)

ftp://ftp.rediris.es/pub/linux/distributions/mandr ake/8.2/i586/
Sweden

ftp://ftp.chello.se/pub/Linux/Mandrake/8.2/i586/

ftp://ftp.chl.chalmers.se/pub/Linux/distributions/ Mandrake/8.2/i586/ (Gothenburg)

ftp://ftp.du.se/pub/os/mandrake/8.2/i586/ (Dalarma)
Switzerland

ftp://ftp.pcds.ch/pub/Mandrake/8.2/i586/ (Neuhausen)

ftp://sunsite.cnlab-switch.ch/mirror/mandrake/8.2/ i586/ (Zurich)
Taiwan

ftp://linux.cdpa.nsysu.edu.tw/pub/Mandrake/mandrak e/8.2/i586/

ftp://linux.csie.nctu.edu.tw/distributions/mandrak e/Mandrake/8.2/i586/

ftp://mdk.linux.org.tw/pub/mandrake/8.2/i586/
Turkey

ftp://ftp.ankara.edu.tr/pub/linux/dagitimlar/Mandr ake/8.2/i586/ (Ankara)
United Kingdom

ftp://ftp.mirror.ac.uk/sites/sunsite.uio.no/pub/un ix/Linux/Mandrake/Mandrake/8.2/i586/ (Canterbury)
United States

ftp://ftp-linux.cc.gatech.edu/pub/linux/distributi ons/mandrake/8.2/i586/ (Georgia)

ftp://ftp.cise.ufl.edu/pub/mirrors/mandrake/Mandra ke/8.2/i586/ (Florida)

ftp://ftp.cse.buffalo.edu/pub/Linux/Mandrake/mandr ake/8.2/i586/ (NY)

ftp://ftp.nmt.edu/pub/linux/mandrake/8.2/i586/ (New Mexico)

ftp://ftp.orst.edu/pub/mandrake/8.2/i586/ (Oregon)

ftp://ftp.tux.org/pub/distributions/mandrake/8.2/i 586/ (Virginia)

ftp://ftp.umr.edu/pub/linux/mandrake/Mandrake/8.2/ i586/ (Missouri)

ftp://ftp.uwsg.indiana.edu/linux/mandrake/8.2/i586 / (Indiana)

ftp://linux-cs.tccw.wku.edu/pub/linux/distribution s/Mandrake/8.2/i586/ (WKU-Linux, Western Kentucky University)

ftp://mirror.aca.oakland.edu/linux/mandrake/8.2/i5 86/ (Michigan)

ftp://mirror.cs.wisc.edu/pub/mirrors/linux/Mandrak e/8.2/i586/ (Wisconsin)

ftp://mirror.mcs.anl.gov/pub/Mandrake/8.2/i586/ (Illinois)

ftp://mirrors.ptd.net/mandrake/8.2/i586/ (Pensylvania)

ftp://mirrors.secsup.org/pub/linux/mandrake/Mandra ke/8.2/i586/

ftp://uml-pub.ists.dartmouth.edu/mirrors/ftp.mandr akesoft.com/pub/Mandrake/mandrake/8.2/i586/ (New Hampshire)

ftp://videl.ics.hawaii.edu/mirrors/mandrake/Mandra ke/8.2/i586/ (Hawaii)

http://mandrake.dsi.internet2.edu/Mandrake/8.2/i58 6/ (For Internet2 academic institutions only)

But then I reconsidered. First, a little background. C# was, is, and always will be, a Micro$oft invention. Like it did with SMB and OLE, not to mention DirectX and ZIP, M$ will have no reservations about mucking with C# just to break Mono compatibility.

C# is an ECMA standard, like C++ which is an ISO standard unlike Java which is Sun Microsystem's property. Thus Sun has complete control over the future of Java while Microsoft does not have the same for C#. So claiming supporting C# is supporting Microsoft is way off base. Question: Were DirectX, OLE and SMB also international standards or are they technologies wholly owned by M$?

Get it right people; it's an ISO standard, not an ANSI standard. If nothing else this is a useful interview answer!

As for Herb Sutter - I believe him when he says he's to going to compromise his standards work. I don't believe MS, but Herb Sutter's books have earned him my respect.

• In terms of C++ standards compliance GCC is believed to be the first compiler to achieve full ISO compliance

• In terms of C++ standards compliance GCC is believed to be the first compiler to achieve full ISO compliance

Correct me if I'm wrong, but wasn't Java withdrawn by Sun from standardization efforts so Sun could retain exclusive control? (Microsoft is Evil and Nasty and attempting to Embrace/Extend/Extinguish for allowing programmers to access the Microsoft API's from Java code, but we can add Native Methods calls ourselves!)

Even implementing your own version and using the name "Java" anywhere near it will have fifteen Sun lawyers jumping down your throats? (Witness java enthusiasts writing "Java Spacegame" demo applets and getting cease-and-desist's) ... Java's great, but unless I'm seriously misinformed it needs Sun to loosen its grip quite a bit...

C99 standard. Overview.The Honorable Dennis Ritchie (father of C) on C99

I think, frankly, that this report is rubbish. The purpose of Unicode is NOT to provide a full listing of all possible glyphs; it is to provide a list of characters. The author of the report appears to me to have made a reasonably common mistake when reading through the Unicode spec; he sees one of the Unified Han characters, says "Ha! That looks nothing like the character in !" and assumes that Unicode is some Western pigheaded colonialist rubbish.

For a more complete discussion, which summarises more accurately the way to use the Unified Han character section of the Unicode specification, trot off to here. Particularly read the section on "why were the characters unified". Unicode isn't perfect, but the Unified Han system is a good attempt to minimize bloat in the character tables.

p.s. Those dudes from the Klingon Language Institute have been trying to get themselves a spot in the Unicode tables for ages and have recently had their application rejected :-( see here

Actually,someone thought about hieroglyphs in UCS (this was mentioned in the quickies section some time ago):


http://anubis.dkuug.dk/jtc1/sc2/wg2/docs/n1637/n 16 37.htm


I don't know whether it is/will be implemented at the end. Looking at the limited character space, probably not.

Maybe if people didn't try to get character sets like Klingon, Cirth and Tengwar added into unicode we wouldn't have this problem!

In a word, "what?" As in, what are people thinking when the write tirades *against* open standards bodies for computing technology?

Here are some that have worked, and made your lives a whole lot better:

RFCs
POSIX/IEEE
HTTP/HTML
ASCII/ISO 8859
ANSI C

And that's just to name a few that immediately came to mind. Note that some of them had coporate sponsorship, some are truly community reviewed, and some are a mixture. But standards are essential for ever moving *beyond* the technology of today. If we didn't have a standard C, then people will still be arguing over how to improve C, rather than creating new languages.

Really, standards shouldn't evolve that much. And people shouldn't wait to get them perfect. Agree on something that mostly works, use it, and move on.

Unless you want to register domain names in Klingon.

Michael Everson of Everson Gunn Teoranta has proposed an encoding of Klingon in Plane 1 of ISO/IEC 10646-2; if it gets adopted, future versions of Unicode may adopt it (Everson's one of the editors and authors of Unicode 3.0).

Heiroglyphs are boring. The real news is that, according to the Unicode Proposed Characters Page, the Klingon alphabet, and the Tengwar and Cirth runes (from Tolkein) are under investigation for being included in Unicode.

Heiroglyphs are boring. The real news is that, according to the Unicode Proposed Characters Page, the Klingon alphabet, and the Tengwar and Cirth runes (from Tolkein) are under investigation for being included in Unicode.

Heiroglyphs are boring. The real news is that, according to the Unicode Proposed Characters Page, the Klingon alphabet, and the Tengwar and Cirth runes (from Tolkein) are under investigation for being included in Unicode.

Halla-fuckin'-lujia. Really. I'm sick of sketching them, and the existing fonts (there's a couple of sets) suck. Naturally, with a language that's both phonetic and ideogram based, the set is limited. But this set does a really good job of covering the bases. It's enough to get me back into Egyptian again.

-Waldo

Perhaps you might be so kind as to please remind me which revision of the standard added those silly C++ comments to C.

C9X added them. See here for the summary of changes, or here for the full standard (section 6.4.9).

I don't think there's anything wrong with // as comments. OTOH, people using // for multi-line comments probably shouldn't be.

Perhaps you might be so kind as to please remind me which revision of the standard added those silly C++ comments to C.

C9X added them. See here for the summary of changes, or here for the full standard (section 6.4.9).

I don't think there's anything wrong with // as comments. OTOH, people using // for multi-line comments probably shouldn't be.

According to here, it's finished and available to read. It doesn't look like it's all that long, but still cute.

The only evidence that Microsoft lobbied for this is Baratz's assertion. You can go and read the ISO e-mail discussions yourself (be patient, slow server in Denmark); The Microsoft people basically kept their mouths shut and now everyone on the list is pissed at Sun.

Baratz needed a scapegoat. Who else would he blame?

LJS

We had some problems with the host for this projet but they are solved now.

Join the project and show the World how we work in the Linux Community - in a way ordinary people understand.

See more at ely.dkuug.dk.

Claus Sørensen, Initiator of ELY.

First of all the project is organized. It is managed from the start - but what it will contain is not planned. Ad hoc management.

Why do you think it becomes crappy?

Is it because you won't review it and give your feed back to make the book better?

Join the project - and see what you can do?

Thanks in advance.

See more at ely.dkuug.dk.

Claus Sørensen, Initiator of ELY.