Icosahedra and dodecahedra are strongly related, so that's why a soccer ball looks a bit dodecahedral (having, as it does, 12 pentagons). In fact, if you keep on truncating a icosahedron's corners more and more deeply, you end up with a dodecahedron. Duality is very cool!
5.0 SDK also released; "GCC not supported"
on
PalmOS 5 Turns Gold
·
· Score: 5, Informative
The final 5.0 SDK
was also released today (interim development versions have been available in beta for a while).
There are two C/C++ development toolchains for Palm OS:
Metrowerks CodeWarrior
and what's called prc-tools,
which is GCC, GDB, etc configured and patched as a cross-compiler for Palm OS. Some surveys suggest that each of them has about 50% of the market of Palm OS developers.
In the past,
Palm OS SDKs have supported both toolchains: the 3.5 and 4.0 SDKs contained
various linker (static) libraries in both CodeWarrior format and, for GCC, COFF format.
The 4.0 SDK was even available from Palm as an RPM as well as a Unix tarball.
The 5.0 SDK's ReadMe has this to say about GCC:
This release of the SDK does not provide any support for the GCC development
tools for Palm OS. GCC-specific components have not been updated for this
release. SDK 4.0 Update 1 should be used for development under Linux and for
using GCC on Windows.
In practice, it's not a show-stopper: the header files, which are all you really need to use the new 5.0 APIs (notably high density graphics and ARM subroutines), work fine with GCC. There's a bit of extra pain on Unix due to line termination issues and PalmSource's lack of familiarity with case-sensitive filesystems, but it's not too bad.
The GCC link libraries are entirely missing from the 5.0 SDK. This is unfortunate: while you can easily write an application without using them,
the glue routines in one of the libraries makes compatibility with various versions of the OS easier, and PalmSource recommends their use.
Curiously, while the ReadMe says the SDK "does not provide any support for [GCC]", PalmSource were happy to fix showstopper GCC-usage-related bugs in the SDK's header files when they were pointed out to them during the SDK's beta period.
Thus the note in the ReadMe is not really true.
All that's really missing is the GCC linker libraries and the Unix builds of
the SDK. Because they were happy to fix those header bugs, because their Web pages
still claim to "support prc-tools", and because of what various PalmSource
employees have told me, I don't believe there's been any conscious decision (or
conspiracy:-)) not to support GCC. I think the problem is that, even
though the GCC library and Unix build scripts are still lying around from
the 4.0 SDK, it's simply nobody's job to take responsibility for maintaining
the scripts or for pressing the button that runs them.
It's all very
disappointing: in all probability, there's no technical reason why the 5.0
SDK doesn't include GCC libraries or an easily installable Unix package, it's
just that no-one cared enough to make them.
It seems like it was always just Someone Else's Problem.
It's not too late to fix this. The company I work for and I know how to build these things (I wrote the scripts in a previous life:-)), and we've offered to help PalmSource build them several times. Hopefully they'll take us up on it, and make the users' lives easier.
I used to think Ebert was some pompous windbag, who wouldn't know a good movie
it it slapped him in the face. But the older he gets, and the more I read stuff
he's written, the more I come to realize he's a guy who really "gets it".
So, is this (the use of.US domains) going to be a step towards a more international Internet, even a baby step? [...]inherently biased towards people in the US [... X.edu, Y.org, Z.com...]
Those aren't so bad.
What's really offensive is whitehouse.gov and the like. If there's anything that ought to be under.us, isn't it that country's government?
a famous
example is Microsoft's interpretation of the scope of variables declared inside
the conditional section of a for loop. with "for(int i..." in standard C++, i's scope
is for the duration of the loop
No atomic operations? That does not agree with my experience: if I do a "cvs commit" on a directory, all the files go in at once or they don't go in at all.
Not always. Think server crashes, databases, and ACID tests.
But here's the more important side of atomic checkins.
One day I add a superfoo() function to foo.c and foo.h, making revision 1.37 of foo.c and 1.22 of foo.h.
Three months later, I am looking at foo.h, which is up to 1.57, and I want to find out everything about the changes that introduced superfoo(). With CVS, as far as I can tell, I look at foo.h's log, see the checkin comment that added superfoo(), hope that the same comment might appear in foo.c's log, but probably have to correlate the two via the ChangeLog file. It's harder when there's not something simple like "superfoo()" to grep for.
With a system with atomic checkins, I look in foo.h's log for the relevant global change number, and then I ask what effect that change number had on foo.c. No manual searching.
It seems to me that the sole reason why GNU projects labouriously maintain ChangeLog files is to cover for the lack of atomic checkins and reporting functionality in CVS.
We've been considering both Visual Source Safe (which we've had good luck with, but find it feature-poor) and CVS. I'd love any feedback anyone has comparing the two on a fairly large project, particularily where we have two sets of developers working off-site through slow IP links.
In previous lives, I've used in earnest RCS, PVCS, CVS, and VMS's CMS. Thankfully I was never subjected to Source Safe.
PVCS was appallingly bad. Random corruption, files perpetually locked by others. RCS was feature-poor. CMS was actually pretty good, especially if you didn't want to branch anything. I used to like CVS.
Then I landed in a shop where they use Perforce, and grumbled for a while that it wasn't CVS. Pretty quickly I was a convert. Perforce is like CVS except that:
branching is understandable
the commands and options are regular and systematic, so it's possible to remember what they all do
it has lots of reporting commands, so you don't have to maintain a ChangeLog by hand
Then I discovered how much fun scripting it was!
There's tension in that it's not free software, but then Perforce the software and Perforce the company are a joy to deal with, so you don't begrudge them all that much. Their user base is largely a free software-like rabid bunch of happy advocates, so something must be right.
I'm looking forward to next week's SVLUG talk about Subversion, which might be Perforce's first real competition for a while in the "it's not ClearCase -- thank God" category.
Over the slow IP links: by all accounts, Source Safe is terrible. On our large projects worked on from half a dozen sites, Perforce works well. The GCC folks can probably tell you how well CVS works in that situation: I suspect the answer is pretty reasonably well too.
What we really need are the "unspecified width integral types" such as we have today in int and friends, and a new set of types (or type aliases) for "exact width integral types".
It's funny you should say that... because the C99 standard provides precisely that with its intX_t types in stdint.h. Details in this slightly out of date summary, or section 7.18 of the C99 standard.
printf(gettext("usage: %s filename\n"),argv[0]);
[...]
Here the output of the gettext(3) function is not validated and passed directly to printf(3).
Sounds worrying (and we've known about such problems for ages), but
A malicious, unprivileged, user can build and install a bogus messages database and instruct the vulnerable program to use it, thus controlling the output of gettext() and force-feeding formatting characters to printf(3).
Surely the real vulnerability here is that the environment has been set up such that an unprivileged user can instruct a setuid program to use an arbitrary unvetted control file?
There's already been some interesting discussion of this on the GCC mailing list, and all the other lists Michael posted it to.
In general, I like to recommend that people do a little research before they take what Michael says too literally. Unfortunately, Google seems to have got bored with Michael's magnum opus (the page in which he describes his love for the GNU project is particularly fun), but it still lists many of the othermailinglists Michael has tortured over the years.
I've seen endless amounts of complaining on slashdot about the 'click here to agree' licenses that come with most commercial software. Some say they aren't binding and shouldn't be taken seriously. Why, then, should anybody take a license included with an open-source package seriously?
The GPL tells you how you can redistribute a work, and draws its force from copyright law.
By threatening to [blackhole it] and by publicizing the threat, MAPS would disrupt yesmail's contractual relationships with its advertising business, the complaint states.
So yesmail has entered into contractual agreements with advertisers stating that it is able to send email to third parties more or less reliably? Even without obvious impediments like MAPS, this is of course quite outside its power to guarantee.
In the first 12 weeks of this year, the number of requests for information--or hits--on the master server for all Internet addresses jumped from 220 million to 420 million a day, [...]
Could this possibly have anything to do with the "hot property" domain mindset that means every acme.com also registers acme-widgets.com, acme-foo.com, and acme-bar.com, instead of using the DNS hierarchically as it was designed for by registering widgets.acme.com and so on within their own domain?
Slashdot Mirror
Icosahedra and dodecahedra are strongly related, so that's why a soccer ball looks a bit dodecahedral (having, as it does, 12 pentagons). In fact, if you keep on truncating a icosahedron's corners more and more deeply, you end up with a dodecahedron. Duality is very cool!
There are two C/C++ development toolchains for Palm OS: Metrowerks CodeWarrior and what's called prc-tools, which is GCC, GDB, etc configured and patched as a cross-compiler for Palm OS. Some surveys suggest that each of them has about 50% of the market of Palm OS developers.
In the past, Palm OS SDKs have supported both toolchains: the 3.5 and 4.0 SDKs contained various linker (static) libraries in both CodeWarrior format and, for GCC, COFF format. The 4.0 SDK was even available from Palm as an RPM as well as a Unix tarball.
The 5.0 SDK's ReadMe has this to say about GCC:
There are no GCC libraries and no Unix SDKs.I've also posted to palm-dev-forum about this.
In practice, it's not a show-stopper: the header files, which are all you really need to use the new 5.0 APIs (notably high density graphics and ARM subroutines), work fine with GCC. There's a bit of extra pain on Unix due to line termination issues and PalmSource's lack of familiarity with case-sensitive filesystems, but it's not too bad.
The GCC link libraries are entirely missing from the 5.0 SDK. This is unfortunate: while you can easily write an application without using them, the glue routines in one of the libraries makes compatibility with various versions of the OS easier, and PalmSource recommends their use.
Curiously, while the ReadMe says the SDK "does not provide any support for [GCC]", PalmSource were happy to fix showstopper GCC-usage-related bugs in the SDK's header files when they were pointed out to them during the SDK's beta period. Thus the note in the ReadMe is not really true.
All that's really missing is the GCC linker libraries and the Unix builds of the SDK. Because they were happy to fix those header bugs, because their Web pages still claim to "support prc-tools", and because of what various PalmSource employees have told me, I don't believe there's been any conscious decision (or conspiracy :-)) not to support GCC. I think the problem is that, even
though the GCC library and Unix build scripts are still lying around from
the 4.0 SDK, it's simply nobody's job to take responsibility for maintaining
the scripts or for pressing the button that runs them.
It's all very disappointing: in all probability, there's no technical reason why the 5.0 SDK doesn't include GCC libraries or an easily installable Unix package, it's just that no-one cared enough to make them. It seems like it was always just Someone Else's Problem.
It's not too late to fix this. The company I work for and I know how to build these things (I wrote the scripts in a previous life :-)), and we've offered to help PalmSource build them several times. Hopefully they'll take us up on it, and make the users' lives easier.
Oh, disclaimer: I'm a prc-tools maintainer.
Methinks you meant to write "the older I get" :-)
What's really offensive is whitehouse.gov and the like. If there's anything that ought to be under .us, isn't it that country's government?
They're not the world government yet!
One day I add a superfoo() function to foo.c and foo.h, making revision 1.37 of foo.c and 1.22 of foo.h.
Three months later, I am looking at foo.h, which is up to 1.57, and I want to find out everything about the changes that introduced superfoo(). With CVS, as far as I can tell, I look at foo.h's log, see the checkin comment that added superfoo(), hope that the same comment might appear in foo.c's log, but probably have to correlate the two via the ChangeLog file. It's harder when there's not something simple like "superfoo()" to grep for.
With a system with atomic checkins, I look in foo.h's log for the relevant global change number, and then I ask what effect that change number had on foo.c. No manual searching.
It seems to me that the sole reason why GNU projects labouriously maintain ChangeLog files is to cover for the lack of atomic checkins and reporting functionality in CVS.
PVCS was appallingly bad. Random corruption, files perpetually locked by others. RCS was feature-poor. CMS was actually pretty good, especially if you didn't want to branch anything. I used to like CVS.
Then I landed in a shop where they use Perforce, and grumbled for a while that it wasn't CVS. Pretty quickly I was a convert. Perforce is like CVS except that:
Then I discovered how much fun scripting it was!
There's tension in that it's not free software, but then Perforce the software and Perforce the company are a joy to deal with, so you don't begrudge them all that much. Their user base is largely a free software-like rabid bunch of happy advocates, so something must be right.
I'm looking forward to next week's SVLUG talk about Subversion, which might be Perforce's first real competition for a while in the "it's not ClearCase -- thank God" category.
Over the slow IP links: by all accounts, Source Safe is terrible. On our large projects worked on from half a dozen sites, Perforce works well. The GCC folks can probably tell you how well CVS works in that situation: I suspect the answer is pretty reasonably well too.
In general, I like to recommend that people do a little research before they take what Michael says too literally. Unfortunately, Google seems to have got bored with Michael's magnum opus (the page in which he describes his love for the GNU project is particularly fun), but it still lists many of the other mailing lists Michael has tortured over the years.
Shrinkwrap licenses attempt to tell you what you can do with a work, and draw their force from... er... nowhere in particular.
Great work, guys!
But it seems this was too confusing for one of Cygnus's customers. Alas.
(Hey! It's still in there -- the removal was never checked in. Shhhhh!!)
Could this possibly have anything to do with the "hot property" domain mindset that means every acme.com also registers acme-widgets.com, acme-foo.com, and acme-bar.com, instead of using the DNS hierarchically as it was designed for by registering widgets.acme.com and so on within their own domain?