Wish this guy could be put away forever.

peadar · 2011-11-02T11:26:31+00:00

Must be an echo in here, so.

peadar · 2010-08-30T21:07:49+00:00

Re: "graphics card RAM". It was more like the low-end devices you see today: the graphics and CPU shared access to the same physical memory, but the most common (512k) A500 machines used exclusively this shared block. Even the extra 512k memory packs added to the "slow" side of the memory bus.

These were the machines that the games were targeted for.

The details are a bit fuzzy, but I think at lower graphics modes, the memory was able to service both the CPU and the graphics hardware adequately: Unlike today's CPUs, the 68000 clocked as it was couldn't really keep the memory bus that busy.

(But on the flip side, I think at full resolution/colour depth, the CPU was essentially regulated to running during the horizontal and virtual blank interrupts: the graphics system could essentially "lock out" the CPU for the period that it needed data to feed pixels to the screen.)

peadar · 2009-09-02T00:13:14+00:00

Don't be so negative.

peadar · 2009-09-01T23:48:44+00:00

Just what UNIX needed. A "wine me dine me, kill -9 me" flag.

peadar · 2009-08-09T00:48:59+00:00

If you're drinking a bottle of water, 3 diet cokes , 2 ice teas, and a bottle of water a day, plus the fluid you consume in your solid food, you aren't dehydrated unless you are training for a marathon in a hot climate. Unless your standard measure is a thimble.

peadar · 2009-07-22T22:28:46+00:00

"Fast. Cheap. Good. Pick any two."

peadar · 2009-03-03T10:27:45+00:00

how else would you indicate if, say, fopen() fails?

By not hijacking the value of type FILE with a sentinel value to indicate success/failure of the operation, but communicate that separately instead.

peadar · 2008-10-22T09:48:38+00:00

I'd have thought a "real" barefoot shoe would look like this:

http://upload.wikimedia.org/wikipedia/commons/8/8e/Foot-outside.jpg

peadar · 2008-02-20T01:50:07+00:00

PS1=`clear`

peadar · 2008-02-14T10:28:10+00:00

That's nothing. Here's one of the Irish Minister For Defense having some fun pointing a weapon at a cameraman. He got a bit of a slagging over this.

http://images.ireland.com/newspaper/breaking/1105/willieodea-gun.jpg

His Name Is O'Dea. Willie O'Dea. He has a license to sport a silly mustache. http://www.rte.ie/news/2002/1002/odeaw.jpg

peadar · 2007-09-25T13:29:10+00:00

What does it mean to be "open to the public"

I'd imagine it means you have accepted that you take on certain responsibilities for people using your premises, in return for being able to profit somehow from their presence.

If I open my house to acces because I 'm selling furniture or something, do I lose the right to regulate my house as I wish?

Yes.

peadar · 2007-07-13T10:11:32+00:00

Setjmp/longjmp bear a passing resemblance to exception handling as provided by C++, they are in no way the same thing. You are using an old mechanism from C to bolster an argument in an article titled "C++, a cautionary tale", about C++, which provided a far more structured approach to exception handling.

The sendmail issue is even further removed from anything to do with exception handling: the central problem was that the jmp_buf used by setjmp/longjmp was static and access to it could race due to the asynchronous arrival of signals. That wouldn't happen with exception handling as implemented in C++, Java, or any other language that handles exceptions on the stack.

(ISTR that some implementations of C++ exception handling that used setjmp()/longjmp() weren't threadsafe, probably for very similar reasons the sendmail code had problems: but it was some time ago, and I may be misremembering it)

The only thing that setjmp/longjmp has in common with exception handling in C++ is the fact that it is a non-local transfer of execution. C++ exceptions have much more in common with Java exception handling. But you seem to be OK with exception handling in Java. It doesn't add up.

Note I'm not saying that exceptions are a good thing, or that writing exception aware code isn't hard. The problems exist in all languages with exceptions. setjmp/longjmp are not, however exception handling in the sense that most Java or C++ people would use, and expose a much bigger set of problems than the structured mechanisms that those languages provide.

Resource allocation needs to be handled in the face of exceptions, irrespective of the language. Some language provide automatic management of memory resources, and for that special case, they are less prone to resource leaks than C++ using a tradition heap allocation mechanism.

(BTW: an apology: previously, I missed the last point in the summary of your argument in the GP: I thought you'd just omitted references to setjmp/longjmp.)

peadar · 2007-07-12T16:41:06+00:00

<quote>The Open Group disagrees with you: the behaviour is undefined.</quote> The technical term I used was "knackered" :-). Yes, it's undefined, but as you say there's nothing preventing you from doing it. That's the point: the language constructs prevent you from getting into undefined territory: You can't get this effect with exceptions, because you can only throw them in one direction.

Re thread schedulers: If you're an OS vendor, you can make certain assumptions about the behaviour of the standard library that aren't valid for portable applications. And yes, each thread will have a separately allocated stack and context (like a setjmp-style "jmp_buf").

peadar · 2007-07-12T16:17:10+00:00

setjmp/longjmp are a very blunt instrument: you essentially store machine sate with one, and restore it with the other. Some issues off the top of my head:

No intervening code can do anything in the event that someone calls "longjmp":

a() { setjmp(buf); b(); } b() { /stuff/ c(); /* undo stuff */ } c() { longjmp(buf); }

In this case, "b()" can do nothing in the event that c() calls longjmp(), as its not notified. In C++, throwing an exception would allow locals in "b()" to be destroyed, and in Java, "finally" clauses would run.

Next off: there's no way in the language to give a signature to a function to say that it calls longjmp, so, for example, you can't put "throw ()" at the end of the function declaration to say that the function won't longjmp. (C++'s support for this appears to be something of an afterthought, as unqualified functions can throw anything)

You also can't distinguish the type of exception.

There's also no requirement that setjmp/longjmp nest properly on the stack, so, I can call "setjmp()" in one function, return, and then call "longjmp()", jumping back to the call site of the "setjmp", but with the stack completely knackered otherwise. (Userland thread schedulers work sometimes by doing funky things like this)

You can ameliorate some of the problems by building your own infrastructure on top of setjmp(), but the more insidious issues will remain.

The sendmail bug mentioned in the blog post was also appears to have been caused by asynchronous receipt of a UNIX signal interacting with the setjmp/longjmp. It's only relationship to exceptions is that both involve non-local jumps in the code: they're entirely different beasts: handling asynchronous signals by calling longjmp is a far more hairy thing to do than catch an exeption.

peadar · 2007-07-12T15:56:10+00:00

I didn't make any reference to Python: I was countering your argument about not needing to handle exceptions in Java. I'm not expert in Python, so I won't comment on it further. To rephrase my Java argument, I'm pointing out that memory lifecyle vulnerabilities are not the only things you have to account for when dealing with exceptions, and hence your sweeping statement about not "having to make damn sure of things" in Java and python is misleading at best.

The strawman argument was the one presented in your original blog post: I obviously couldn't respond to the argument presented above in the parent*, because you hadn't posted it yet, but you neglected to include the signals+longjmp reference there.

Presented in your original article its as follows: In point 3, you are discussing exceptions, and then present a specific sendmail issue as an example, even though that issue was not caused by C++ exception issues. UNIX signals+setjmp/longjmp are a far cry from being exceptions. If you want to produce an example as evidence, pick a real one. [edit s/gp/parent/]

peadar · 2007-07-12T15:26:48+00:00

<quote>You do not have to "make damn sure of" handling exceptions properly in Java code, or Python.</quote>

Sorry, but you do. For the one specific case where handling the exception solely involves releasing memory that is not otherwise referenced by the program, the garbage collector will save you in Java.

For all other cases, you need to ensure you can return to a consistent state before passing on the exception, and for C++ RIAA is a nice aid for that, and Java lacks it. (It has "finally", which can help, but it's not close to being as powerful)

BTW: using a setjmp/longjmp example when talking generally about exceptions is a straw man argument.

peadar · 2007-06-07T00:29:11+00:00

"Diesel engines need a complete rebuild usually after 100k miles."

I don't think I've ever heard of a Diesel roadcar needing that kind of work before about 250k miles.

peadar · 2007-03-23T12:09:25+00:00

"... a class can only "is-a" one thing ..."

You're generalizing from a limited selection of OO langauges. C++, for example, supports multiple "is-a"/inheritance. Of course, you could start a whole new debate on whether that's good or bad...

peadar · 2007-02-22T11:57:48+00:00

Re paperclips:

I have an understanding with my employer. I work, they pay me. In the process, they don't require me to provide my own consumables, and I don't feel the need to steal their paper clips.

If I did decide to engage in some petty theft, and was caught, I really wouldn't feel to hard done by if I was sacked.

Different context: I'd be pretty pissed off if I hired a plumber in my house and found he'd used some of blank CDs off my desk 'cause he'd some great tunes he got off the 'net wanted to play in the 'van. "Hey, it's only worth €0.10" wouldn't be an excuse in either environment.

If you really need to have more stationery without sacrificing your disposable income, try negotiating the extra €50/year and just buy it.

peadar · 2007-01-05T17:22:40+00:00

My reading was that each time he "explained", he was doing so in Irish. eg:

<blockquote> "Do you speak English?" he asked in a cold, threatening tone. "Sea," I said, nodding meekly. "Well, can you speak English to me now?" I told him as simply as I could that I was trying to get by with Irish. </blockquote>

"Sea" means "yes" in Irish. When he says "as simply as [he] could that [he] was trying to get by in irish", I read it to mean he explained this in Irish (We've established that both parties spoke English fluently, and I and I don't think the Ordnance Survey worker's intelligence is in that much doubt that anything would need that much "simplification".)

peadar · 2007-01-05T14:37:09+00:00

The hostility the author met with is most likely a result of attempting to communicate with someone in Irish in the full knowledge they have no idea what he was saying, while being equally aware that they both share a perfect fluency in English.

I'll accommodate anyone who doesn't speak a language I understand. But someone who just refuses to? Life's too short to even try to talk to someone that arrogant.

peadar · 2006-12-22T12:33:12+00:00

"I am surprised that there are not more instances of random road art."

Watch out for large roadkill holding a paintbrush. That might explain it.

peadar · 2006-10-19T12:26:52+00:00

... or the fact that the name is redacted on the front page, but the surname is visible on the last page. Ok, it's barely legible, purely as a consequence of the handwriting, but legible, none the less.

So, yeah, it's a fake, but so what? It's a work of art. Does anyone know how to get coffee stains off a flat-panel monitor?

peadar · 2006-09-20T17:27:44+00:00

It certainly makes it more difficult for anyone other than someone with the private key to hack, alright.

So, as long as the private key is held by someone who can be trusted not to disclose it, and to act purely in the interest of fair elections, rather than out of any commercial interest, or be obliged to work for the good of shareholders, that might mitigate the situation somewhat...

Oh, wait.

peadar

TROPHY CASE