Nezmar

This weekend saw the election of the first Pirate Members of Parliament to a national-level, proportional parliament. (Pirates have previously been elected into the European Parliament, the Czech Senate, multiple state-level parliaments, and many local councils.)

The most fascinating thing about that election wasn’t that it happened a mere seven years after the movement’s founding, but that it happened in another country than where it was founded.

They say that each generation must reconquer democracy. In practice, there seems to be a little more time between each major wave of new political values. Universal suffrage and liberalism gained ground about 120 years ago, the labor movement gained ground about 80 years ago, and the environmental movement gained ground about 40 years ago. But still.

These movements took decades from their inception to their first successful elections. Decades! In contrast, the Pirate Party’s first election success was in 2009, a mere three and a half years after the movement was founded. Today, there are Pirate parties in 70 countries – arguably in varying stages of development – and support is growing pretty much everywhere, slowly but measurably.

Some would say that the Pirate Party movement is “just a protest party”, as if that were something bad. Such parties are part of a functioning democracy. We call them “opposition”. If you’re not content with the way things are run, then by definition, you are dissenting against the incumbent administration.

All major movements have followed the same pattern. They started out as a protest against what they saw as unfair, solidified that protest into a narrow set of policy changes, and ran for office. Then, they deepened into an ideology that could be applied across all of society.

The labor movement protested exploitation of workers, solidified that into a narrow policy that would legalize and strengthen labor unions, and then deepened into an ideology of solidarity. The green movement protested pollution, crafted a narrow policy that would regulate industries, then deepened that into an ideology of sustainability.

The Pirate Party movement is in the middle of this deepening and broadening process. I find it fascinating that whenever I speak to self-identified pirates no matter where in the world, we seem to be in agreement on the most minute of policy details far outside the cores of sharing, transparency, and accountability, as well as how we arrived at that conclusion. It’s true that we started out protesting that some businesses’ neophobia (fear of the new) were allowed to supersede civil liberties online, but we’ve come a long way since.

It’s like the understanding of society spread by osmosis through the Internet. Perhaps the Pirate Parties really are the political arm of the Internet, as some have called the movement.

Anyway, with this election, the movement is officially out of the starter blocks.

The election of Pirate MPs on Iceland is an exciting beginning. My congratulations to Birgitta, Jon-Thor and Helgi on your new jobs.

Source: Reflections on Iceland’s Election of Pirate MPs

“

After learning my flight was detained 4 hours,
I heard the announcement:
If anyone in the vicinity of gate 4-A understands any Arabic,
Please come to the gate immediately.

Well—one pauses these days. Gate 4-A was my own gate. I went there.
An older woman in full traditional Palestinian dress,
Just like my grandma wore, was crumpled to the floor, wailing loudly.
Help, said the flight service person. Talk to her. What is her
Problem? we told her the flight was going to be four hours late and she
Did this.

I put my arm around her and spoke to her haltingly.
Shu dow-a, shu- biduck habibti, stani stani schway, min fadlick,
Sho bit se-wee?

The minute she heard any words she knew—however poorly used—
She stopped crying.

She thought our flight had been canceled entirely.
She needed to be in El Paso for some major medical treatment the
Following day. I said no, no, we’re fine, you’ll get there, just late,

Who is picking you up? Let’s call him and tell him.
We called her son and I spoke with him in English.
I told him I would stay with his mother till we got on the plane and
Would ride next to her—Southwest.

She talked to him. Then we called her other sons just for the fun of it.

Then we called my dad and he and she spoke for a while in Arabic and
Found out of course they had ten shared friends.

Then I thought just for the heck of it why not call some Palestinian
Poets I know and let them chat with her. This all took up about 2 hours.

She was laughing a lot by then. Telling about her life. Answering
Questions.

She had pulled a sack of homemade mamool cookies—little powdered
Sugar crumbly mounds stuffed with dates and nuts—out of her bag—
And was offering them to all the women at the gate.

To my amazement, not a single woman declined one. It was like a
Sacrament. The traveler from Argentina, the traveler from California,
The lovely woman from Laredo—we were all covered with the same
Powdered sugar. And smiling. There are no better cookies.

And then the airline broke out the free beverages from huge coolers—
Non-alcoholic—and the two little girls for our flight, one African
American, one Mexican American—ran around serving us all apple juice
And lemonade and they were covered with powdered sugar too.

And I noticed my new best friend—by now we were holding hands—
Had a potted plant poking out of her bag, some medicinal thing,

With green furry leaves. Such an old country traveling tradition. Always
Carry a plant. Always stay rooted to somewhere.

And I looked around that gate of late and weary ones and thought,
This is the world I want to live in. The shared world.

Not a single person in this gate—once the crying of confusion stopped
—has seemed apprehensive about any other person.

They took the cookies. I wanted to hug all those other women too.
This can still happen anywhere.

Not everything is lost.

”

-

Naomi Shihab Nye (b. 1952), “Wandering Around an Albuquerque Airport Terminal.” 

(via awelltraveledwoman, clambistro)

Language, culture, travel, food and people. Some of our favourite things in one small, powerful story.

So I'm currently doing some creative reconstructions of some partially-lost Winsor McCay strips from 1934, the year he died, which were never finished. It's for a book on McCay's Gertie (and other McCay dinosaurs) being put together by Ulrich Merkl, who was responsible for the fabulous Dreams of the Rarebit Fiend book a couple of years back.

I'll resist revealing any of the actual McCay artwork here – it's never been published before as far as I know, so that'll be a big selling point – but here's one panel I drew, taken from the pages I'm recreating from the fragments of existing artwork and various clues supplied in the surviving pages. I'll tell you one thing, being Winsor McCay was hard work – these things are taking me an age to draw!

Spesso torna di attualità la discussione sull’introdurre delle forme di pagamento per accedere a determinati contenuti sul web. Molti giornali hanno provato, dopo aver capito che era irrealizzabile un modello esclusivamente a pagamento, a introdurre un accesso oneroso solo dopo aver letto un certo numero di articoli “offerti” gratuitamente. Ad ora non sembra che nessun sistema  sia vincente in assoluto (quindi proficuo e apprezzato sia dai lettori che dagli editori/scrittori).

Un tweet del buon Nicola D’Agostino (@nezmar se ancora non lo seguite) mi ha fatto scoprire Flattr, ossia il tentativo di far funzionare il sistema dei micropagamenti per chi produce del contenuto interessante su internet.

Il funzionamento è semplice: una volta deciso qual’è il proprio budget mensile (minimo 2 €) questo verrà destinato in parti uguali a colori che avranno creato i contenuti su cui è stato cliccato “Like”, “Favorite”, “Star” in base al social network che stiamo guardando.

Flattr trattiene dal proprio budget il 10% mentre il resto se ne va ogni mese ai destinatari che hanno un account Flattr. Se vi piace un contenuto il cui autore non ha ancora un account Flattr viene tenuta da parte questa preferenza ed il giorno che si iscrive riceverà la sua donazione come se allora avrete cliccato.

Il concetto è che magari non siete disposti ad abbonarvi ad un blog a pagamento, non volete fare una donazione via Paypal, ma volete comunque premiare un tweet che vi è piaciuto, una foto particolarmente bella, un infografica riuscita o un singolo articolo interessante. Purtroppo un sistema del genere funziona solo se si diffonde realmente, chissà se avrà fortuna.
Voi siete disposti a pagare singoli contenuti? O preferite formule più tradizionali di sostegno a siti e autori?

On February 13, 2013, the Computer History Museum reported that they had received the source code for version 1.1 of Photoshop from Adobe, and had permission to release it for non-commercial use. This is the second time recently that something like this has happened, the first being the release of the Quickdraw and MacPaint source code by Apple last year. In both cases, there was a nice commentary by Grady Booch, software design legend and trustee of the Computer History Museum. Both times, Booch reported having a look at the code and found it to be elegant and clear, and outstanding examples of how to write software. In his commentary on the Photoshop source code, Booch says "Software source code is the literature of computer scientists, and it deserves to be studied and appreciated".
Writers need to study the writing of others, and usually they do. Computer programmers? not so much. There is a lot written about programming, and most programmers read that stuff (including Grady Booch's books), but there are very few opportunities to actually read an acknowledged Great Work of programming from the past. So now we have the sources to Photoshop, an indisputable software masterpiece. How can we make use of it? Shall we read through the 100,000 or so lines of code in 179 files to see how Thomas Knoll made it do its magic? Maybe Grady Booch can just look at the code and immediately understand the thread of genius that runs through it, but I can't. Source code may be the literature of computer scientists, and each program’s source code may tell the story of its function, but that story is written in a scrambled, crazy order and it makes no sense. To understand their stories, computer programs must be read in the order of their execution, not the order of the text in the files. For Photoshop, as for MacPaint, that means the code has to be compiled and running when we read it. We need to see it in its natural order, and while it is executing, so we can compare what it says to what it does. Only then can we learn its story.

MacApp version 1.1
Photoshop was created for the Macintosh computer in the late 1980's, and it looks a little strange to today's programmers. Anyone can see (and many are surprised) that it is written in Pascal. Maybe it is not well known that 25 years ago the Pascal language saw a lot of use, even for teaching programming in college. Pascal is not taught much these days, and that must be why almost nobody notices that Photoshop is not written in ordinary Pascal, but rather in Object Pascal. Even fewer would recognize that it is written using Apple's MacApp object library. The version of Photoshop that was released to the public is not a complete set of sources. If you are going to build Photoshop from the distributed files, you need a Macintosh Object Pascal compiler, its associated libraries, and the appropriate version of the MacApp class library. MacApp was not included in the source code release, and could not have been, because Adobe does not have a license to distribute MacApp™.
It would have been helpful if Apple had decided to release the source code for the appropriate version of MacApp at the same time as Photoshop. Why not? The source for MacApp is not a trade secret. The class library was distributed to programmers as source, and they were expected to compile it themselves. The version of MacApp in question is version 1, released in 1987 and replaced by a totally rewritten version in 1990. The original was distributed as a set of 2 floppy disks. MacApp version 2 was the first version to be distributed on CDROM. In 1990, Apple wanted programmers to port their programs to version 2, and they didn't include version 1 on the version 2 CD or on any of the later developer distributions. I think it is probably pretty rare. Of course, some people no doubt still have an old copy of MacApp on floppy disks. I didn't. I started using MacApp at version 2, in 1990, and never had a copy of version 1. Miraculously, a pair of MacApp v1.1.1 diskettes was for sale on ebay at the time the Photoshop code was released.
I bought them, realizing that at their age they and might or might not be readable. They mostly were. One of the disks contains all of the Pascal and assembly source code for the MacApp library. The other has everything else needed to build and test the library, including the resource files, the one object file for which Apple did not share their source (called wwDriver.c.o), and the MPW script called MABuild that is used to build MacApp programs from their make files. There is also a compiled MPW tool, called PostRez, that is used to post-process the code. It connects menu GUI elements compiled by the resource compiler Rez to the object code that they are supposed to evoke. The second diskette also contains the classic MacApp example programs, like DrawShapes and Nothing. I am lucky; the diskettes I bought were mostly readable. The second diskette was completely error-free. The source code diskette had one unreadable file, that contained seven bad sectors. The file that could not be read was UTTEView.inc1.p, which contained the implementation of an object called TTEView that is a baby text editor. It was a relief to find that Photoshop did not use this component of MacApp, but I wasn't surprised. TTEView was not used much outside of Apple's demos, because it was limited to editing text blocks of size 32K or smaller.
The MacApp that I bought was complete enough to compile Photoshop. But if you happen to have a copy of UTTEView.inc1.p, I'd be interested in acquiring a copy of that file, just to complete the library. Don’t worry about Apple’s lawyers. I have a license for MacApp.
I tried to compile MacApp and a couple of examples (the ones that didn't use TTEView) to make sure my MPW setup was working with MacApp. It wasn't. A quick look around the inter-webs yielded this post on comp.sys.mac.programmer from Apple's Keith Rollin in 1989, after the release of MacApp 2.0 (thanks to macgui.com for archiving these old usenet posts). Basically, it says that if you want to keep on using MacApp 1.x (and you shouldn't), you have to use MPW version 2.x and its Pascal compiler, not version 3.x. Of course I was trying to use MPW 3.0. It is the earliest version I have. I haven’t used MPW 2 on any computer since about 1991. And like MacApp v1, MPW 2 was only distributed on floppy diskettes. I still have the MPW 2.0 diskettes, but in a moment of bad judgement in the mid 1990's I reused them to store some files that seemed more important at the time (but don’t seem so anymore). There were no MPW 2 diskettes that I could find for sale anywhere. According to the usenet post, I could use MPW 3.0 under system 6 with some changes to the MacApp makefiles and to the application resources. It says that might suffice for builds that do not evoke MacApp's built-in debugger. But according to Keith Rollin, the MacApp debugger will not work if MacApp is compiled under MPW 3. I tried the Nothing and DrawShapes examples both ways; the nodebug versions worked and the debug versions crashed. I could build the nodebug version of Photoshop. But what good is that? I don't just want to just use some old version of Photoshop, I want to run it in the MacApp debugger. MPW version 2 didn't have a source level debugger. Apple’s first source debugger for MPW (SADE) was released with version 3. I think Thomas Knoll must have created Photoshop without the use of any source level debugger other than the one that was part of MacApp. If I want to see it the way he saw it (and I do), I would need to compile MacApp with debugging turned on. Luckily, the problem with the debugger was fixed with only a small change in the MacApp source code.

Getting MacApp to Build
If you build a MacApp v1.1 program with debug on, it enables code for the Writeln window, names in code, range checking, the MacApp debugger interface, and subroutine tracing. Tracing subroutine calls, when on, means that the MacApp debugger keeps track of entry into and exit from every subroutine. When trace is then activated in the debugger, every subroutine call is recorded to the Writeln window, similarly to the trace function in Lisp. If the code was compiled for the debugger, whether tracing is turned on or not, MacApp calls a couple of weirdly-named functions called %_BP and %_EP respectively (implemented in unit UTrace.inc1.p) on entry and exit to every subroutine. Some subroutines that should never be seen in a trace (like the ones that write trace information to the Writeln window) are exempted from %_BP and %_EP using the directive {$D+}, which leaves subroutine names in code but does not trace. The directive {$D++} turns tracing back on for the next subroutine. In MacApp v1.1, both %_BP and %_EP call a subroutine, named MeasureTally. For some reason, MeasureTally was not exempt from the trace. I don't know what would happen if it was compiled with the MPW 2.0 Pascal compiler, but MPW 3.0 compiled this into an infinite recursion, as it should. At startup any program compiled with debugging on would immediately hang, stay hung for a while, and then the stack would collide with something vital in the heap (probably some code segment) and there would be a Bad Crash. It was an easy bug to track down. As soon as it hung but before it crashed, I hit the programmer's switch and fell into TMON. I was in %_EP. Both %_EP and MeasureTally are short, and I could step through them and see them call each other in turn. The problem was fixed by exempting MeasureTally from the trace.
I don't see how the MacApp debugger could have ever worked without this change. It seems to me that everything in UMeasure probably ought have been exempted, but it doesn’t look like it was. Anyway, just exempting MeasureTally got everything working for now. In pretty short order, I was able to build MacApp in System 6 using MPW 3.0, and get the examples to work with debugging turned on. It was fun messing around with the MacApp example programs. What a thrill. I was ready to compile Photoshop.

Fixing the Files
The files in the Photoshop distribution are not ready to use. Firstly, all the text files are contaminated by Windows-style newline characters. Every text line in Windows (and in DOS before it, and in CPM and DEC RT-11 before that) was terminated by a pair of characters, a carriage return (ascii 13) and a linefeed (ascii 10). If you were printing the text using a teletype machine these two characters would first move the print head to the left limit, and then advance the paper one line. This made sense as a line terminator back in the days of the PDP-11, but by the time the Macintosh was released it was already vestigial. Macintoshes were never expected to be connected to teletype machines. They needed a character to represent newline, but one was enough. So Apple omitted the linefeed and kept the carriage return. Somebody at Adobe or at the Computer Museum must have thought we would be using this code with Windows, or some other operating system intended to work with teletype machines. To build Photoshop, the first thing you have to do is to strip out all those extraneous linefeeds. Next, it is necessary to attend to the copyright blurb at the top of each of the resource files. Every Pascal and every Rez file has a little snippet of legalese at the top, encased in curly brackets, like this:

{Photoshop version 1.0.1, file: About.r Computer History Museum, www.computerhistory.org This material is (C)Copyright 1990 Adobe Systems Inc. It may not be distributed to third parties. It is licensed for non-commercial use according to www.computerhistory.org/softwarelicense/photoshop/ }

Curly brackets delimit comments in Pascal, so these are fine for the Pascal files. For the assembly language files, the curly brackets have already been replaced with semicolons at the start of each line, which is exactly right. Semicolons start a comment line in MPW assembly (as in many others). But the resource files are in the Rez language, whose conventions are apparently unknown to the archivers, because they retained the curly bracket Pascal comments. Rez resembles C, so curly brackets mean something altogether different. Comment lines in Rez begin with //, and so all of these need to be added. Finally, the MPW make files and other shell scripts used a unique lexicon of special characters. Comment lines began with #, as they do in most unix shell scripts, and this part has been done right in the sources as distributed. But all the MPW scripts are mangled by the use of a backslash (\) instead of option-d (∂) as the escape character (for line continuation), and all instances of option-f (ƒ) to indicate target-dependency in makefiles have been replaced with colon (:), I suppose because that is what is used in unix makefiles. Fixing all that was easily done with a couple of little MPW scripts.
There are some additional small version issues to address before compiling Photoshop in MPW 3.0. The Photoshop code uses a Pascal interface file called Quickdraw32bit.p. The contents of this file were folded into Quickdraw.p at the time of release of MPW 3, so you have to to remove the reference to Quickdraw32bit.p in several places. The MPW 3.0 version of Quickdraw.p left out the definition of a couple of constants that were in Quickdraw32bit.p, however, so I had to borrow a later version of Quickdraw.p from MPW 3.2. Also, I think Knoll must have been using a particularly early version of the Quickdraw32bit.p file. He refers to a field of the ColorTable record as transindex. That field is called ctFlags in Inside Macintosh V, and in the MPW 3.x interface files. I changed references to transindex with ctFlags everywhere it appeared in the Photoshop code.

Knoll’s Modifications of MacApp
One of the great things about MacApp was that it was distributed as source code. The first thing you had to do was to build the library yourself. What was so great about that? Well, it meant you could improve it if you wanted to. In this particular case that was not so great. I do not have a copy of Thomas Knoll's version of MacApp, so I was hoping that he had used an unaltered version, but I knew it wasn't likely. A lot of things you can readily see happening in Photoshop were not implemented in MacApp v1. For example, that floating palette window with the tools in it. Floating windows like that were (in)famously not part of MacApp v1. Another well-known difficulty with MacApp at that time was its lack of support for "mouse-up tracking”. This problem was even mentioned by Kurt Schmucker in his 1986 book on MacApp, "Object-Oriented Programming for the Macintosh".
To understand the problem with mouse-up tracking, you have to understand MacApp's support for mouse tracking. Mouse tracking means that your code is drawing and redrawing something on the screen in response to movements of the mouse. Normally this happens only when the mouse button is down. When your user was drawing, or defining a selection or dragging something, or for whatever reason moving the mouse around in a window with the button pressed, mouse monitoring code (in the TFrame object) would call your command object (subclass of TCommand) and tell it where the mouse was and where it had been most recently. A command object that handled mouse tracking was called a tracker. You were expected to subclass TCommand to implement each specific behavior of your program during mouse-down tracking, but you didn't expect to have to change TFrame at all. TFrame would call your tracker periodically while the user held the mouse button down, so you could update what was needed and draw stuff on the screen accordingly. When the user let go of the mouse button, your tracker was called one last time, with the advisement this was the end of the series. At that time you were supposed to clean up and draw the final state of your window as it should appear after the user-interaction.
It was a cool system, because you just made a command object and didn't worry about how it got called. Stuff that happened in between the time that the TApplication object intercepted the user's action and the time your tracker was called stayed completely invisible to you as a programmer. The down side was you couldn't easily keep tracking the mouse after a mouse-up event. The TFrame would think that the action was over and wouldn't call your tracker again till the mouse button was pressed to start a new interaction. But let’s say you wanted to let the user draw with the mouse up. For example, imagine you wanted the user to be able to define a polygon by clicking on a series of vertices, and have the program drag out a dynamic line between your last clicked point and the current mouse position as the user moved around with the mouse button up. Mouse-up tracking was used in the polygon-drawing tools in MacDraw, SuperPaint, and Canvas, and lots of other drawing programs. If you wanted to do mouse-up drawing in a MacApp v1 application, you could not do it purely in your command object. You would have to bore down deep and alter the normally untouched MacApp code in class TFrame that called command objects. These days this kind of problem is solved using multiple inheritance, or (even better) by delegation, so you never have to alter the guts of the framework, and this is why Apple doesn't have to share the class framework source code with you.
It turned out that the floating palette window was not a problem. Knoll coded that window's behavior by subclassing the existing MacApp TView class. That's one of the things I'd like to study at when I get everything running. And Photoshop almost did not use mouse-up tracking. But it did, just for one small thing. I am a long-time Photoshop user, but I didn't know or had forgotten about this feature. I learned about it because I got an error at compile-time. A subclass of TCommand (a tracker) in Photoshop, called TLassoSelector, overrides a TCommand method called TrackMouseUp. The compiler knew that in my version of MacApp, TCommand does not have a message called TrackMouseUp. In Thomas Knoll’s version, there must have been.
The Lasso tool uses mouse-up tracking, but only sometimes. Try this in any version of Photoshop. Start to make a selection using the Lasso tool. Part way through the selection, press the option key, and then release the mouse button. Photoshop drags out a straight line between the place you released the mouse button and the current location of the mouse. If you release the option key, it closes the selection with a straight line. Photoshop v1.1 also did that, Knoll had to change MacApp to make this happen, and I didn't have a copy of his changes. Of course it is easy to put a dummy method called TrackMouseUp in TCommand; that would satisfy the compiler. But it would never get called, and the mouse-up tracking would not happen. My version of Photoshop would compile, but it would not be authentic. Not good enough. I had to add a call to TrackMouseUp somewhere in just the right spot. I would know it was the right spot, because if I did it right, TrackMouseUp in Knoll’s lasso command object would do the right thing. Of course, I also needed a default do-nothing version of TrackMouseUp in TCommand so it could be overriden. I’m pretty sure TFrame is the object that has to call TrackMouseUp. In MacApp v1 (but not in later versions), objects of class TFrame provides scrolling to views in windows. They also monitor clicks and drags in their screen territories, and send messages to tracker command objects that are supposed to be drawing in those spaces. As pointed out by Grady Booch in his commentary, there are almost no comments at all in the Photoshop code; there was no hint left anywhere by Knoll. By the looks of it, TrackMouseUp in the LassoSelector was supposed to take over for TFrame after TFrame gave up tracking the mouse. I stuck a call to TrackMouseUp in the part of TFrame.TrackInContent that runs at the end of tracking, when the mouse has just been released. It works, but I can't be sure whether this is the same change that was made to MacApp for the original Photoshop. A similar change to another part TFrame was also required because of another mystery override. Photoshop overrides TFrame.CalcSBarMin, another MacApp method that does not exist. There is a TFrame.CalcSBarMax in TFrame.AdjustSBars, and so I put the call to CalcSBarMin there too. I don't actually know what the function of this is, so I can't even be sure it's working. I’ll find that later when I study it in action. Photoshop also expects to find a procedure called FlashButton. I thought it was apparent what this should do and wrote something accordingly.

EVEITF.o
Photoshop expects to link an object file called EVEITF.o. The file is not there. It apparently provides the code for 5 functions, called EVEStatus, EVEReset, EVEEnable, EVEReadGPR, and EVEChallenge. These functions are called by a global function, VerifyEve, which is present, and is called at startup time. Linking Photoshop fails because of these unresolved references. Examination of VerifyEve shows that none of the EVE functions are called unless Photoshop has a resource of type 'Eve ' (that’s E-v-e-space). There is no such resource in the distribution's resource description file. So these functions would never be called anyway. The source code distribution is designed to link EVEITF.o into the final build, but not to call it. It is dead code. But adding an appropriate ‘Eve ‘ resource would bring it back to life without a rebuild. I think VerifyEve must have had something to do with serial number registration, because it is called immediately after RegisterCopy, which checks whether or not a valid registration number has been entered. After commenting out the EVE functions, the program runs and RegisterCopy works fine. It successfully accepts valid Photoshop serial numbers and rejects invalid ones, even without VerifyEve. So VerifyEve remains a mystery. The personalization information, including the serial number if correct, is stored in the program in a resource of type 'Reg '. The debug version of Photoshop includes av alid 'Reg ' resource with registration information, and allows the program to start up fine, as if it were already registered. It shows personalization for Thomas Knoll at Knoll Software. Cool. Photoshop thinks I am Thomas Knoll. Who else would be running it with the debugger enabled?

Things Were Tougher Then
I built Photoshop on a stock Mac IIci with my ‘040 accelerator removed and the cache card put back in place, to see what the experience would have been to do the build on a high end Macintosh in 1989. The full build, compiling MacApp and the program together, took 14 minutes. If MacApp was already built, it was reduced to 10 minutes.
The debug version of Photoshop starts up normally, and the only immediate differences from the release version are the Debug menu and the presence of the Writeln window (labeled Debug Window) at the bottom of the screen. The Debug window is a regular window you can drag around and resize. A few things are initially written there, and any Writeln command in the code will write into it, but it is not immediately obvious how you use it as an interactive debugger. In MacApp v2 there was a selection in the Debug menu that would stop the program and drop you into an interaction with the Debug window. There is no such item in version 1. I don't have a version 1 manual, so I had to look up in the MacApp source code to find out how you were supposed to enter the debugger. It turns out the answer is to press the command, option, and shift keys at the same time. At that point you get a prompt (≥). Typing a ? gets a list of one-character commands and what they do.
Some of the commands are pretty obviously useful. The Stack Crawl command prints the name of functions on the stack, and addresses of objects whose methods are on the stack. It is also possible to display a block of memory, a list of recently run subroutines, information about memory allocation and some other useful things. You can step through the program. But this isn't a source level debugger in the sense of being able to examine the source file from inside this debugger. One really useful-sounding command is Inspect, which will show the contents of fields of an object. In MacApp version 2 this feature has its own window that presents a list of every object in memory and can inspect any of them. In this version, if you know the address of an object, it will print the values stored in all the fields, in hex. Not as useful as you might hope. Turning on trace (T) and starting the program again (G) will create a storm of activity in the Debug Window as subroutines fire off and run their course. By default, the Debug Window only stores 55 lines of text, so it is important to redirect the output to a file. This is probably the most useful general debugging feature.
Seriously, did Thomas Knoll write and debug Photoshop with just this? I don’t know for sure, but maybe so. Programmers were tougher back then. Most had never used a source debugger; they relied on debugging in object code, using something like TMON or Macsbug. Probably a lot of debugging of Photoshop happened this way. I suspect Knoll was not a big believer in the MacApp built-in debugger. I think this because he didn't code for it. If you were going to use the Inspect command in MacApp, you needed to override a special method, called Inspect, in all your classes. In Inspect you would format the values of all the fields you had added to your applications classes so they could be inspected in the MacApp debugger. If you didn't do this, Inspect would only show the fields of the most immediate superclass that did implement it. Nowhere in the Photoshop code is there any single override of Inspect. There are quite a few direct calls to Writeln, so that the debugging version of the code reports some information about what was going on. I think that means he was using the MacApp debugger. If so, I'm sure that there were lots more of these calls to Writeln when something was not working during the debugging of Photoshop, and that these were removed after the problems were solved.
One of my first lessons learned while reading Photoshop is an appreciation for the power and convenience of the tools we have available for coding today, and the skill of the programmers who made big programs like this without them not too long ago. I'm sure there are a lot more lessons waiting for me, now that the book of Photoshop is open and ready to read.

BG

Basalgangster@macgui.com

Questa ricetta me l’ha data il mio amico Salvatore, siciliano DOC, fumettaro DOC, gay DOC. A parte l’essere siciliano, le altre caratteristiche non sono essenziali per cucinare bene la caponata, ma sembra che per lui sia così. Salvatore ha una fumetteria a Palermo insieme a Filippo, il suo uomo. Se andate a trovarli e gli state simpatici certe volte vi offrono il caffè, oppure un piatto di caponata se beccate il giorno giusto.
La fumetteria si chiama Altroquando ed è in via Vittorio Emanuele 143, orario 8.00/13.00 - 15.00/20.00.
E comunque a me quelli che fanno pubblicità a tutti i costi stanno sulle palle.

Ma veniamo a noi e alla nostra caponata. Neanche in mille anni riuscirete a farla buona come quella di Salvatore. Ma non scoraggiatevi, perché se seguite alla lettera le istruzioni è possibile che verrà piuttosto buona.



Ingredienti:
4 melanzane - 50 g di capperi - 100 g di olive - 50 g di concentrato di pomodoro - 1 gambo di sedano - 1 cipolla - aceto - zucchero.

Procedimento:
Tagliate le melanzane a cubetti abbastanza grandi, almeno 2 centimetri di lato. Mettete i cubetti in uno scolapasta salandoli abbondantemente e lasciateli a “spurgare” per mezz’ora. In questo modo le melanzane perderanno un po’ del loro amaro.
Dopo questa operazione dovete dimenticare che sulla Terra esiste il sale.
Mettete i capperi a bagno in un po’ d’acqua, snocciolate e tagliate a pezzetti le olive mettendo a bagno anche loro.
Pulite il sedano, tagliatelo a pezzetti di circa 1 centimetro e fatelo bollire per qualche minuto. Attenzione a non farlo diventare molle ché Salvatore s’incazza.
A questo punto è il turno delle melanzane. Cercate di togliere più sale possibile (senza usare l’acqua ovviamente) e friggetele in olio di oliva.
In un’altra padella fate soffriggere la cipolla, poi aggiungete il concentrato di pomodoro e allungate con mezzo bicchiere d’acqua. Quando la salsa è pronta unitevi il sedano, le olive e i capperi. Aggiungete un pizzico di zucchero e una spruzzata di aceto. Fate cuocere per qualche minuto e spegnete il fuoco. Aggiungete le melanzane e mescolate con MOLTA delicatezza, altrimenti i cubetti di melanzane s’impappano e vi trovate con una padellata di stucco marrone. Però se avete spifferi negli infissi vi può tornare utile.
Rimettete la padella sul fuoco, fate riprendere il bollore e spegnete il fuoco.
Lasciate riposare la vostra caponata e non scaldatela prima di servirla a tavola perché l’ideale è mangiarla a temperatura ambiente.

Questa è la caponata di Salvatore. Io l’ho assaggiata una volta che sono stata nella sua fumetteria per assistere alla presentazione di un libro. Che c’entra la caponata a una presentazione? Non sono meglio salatini e coca cola?, direte voi.
All’inizio l’ho pensato anch’io, ma poi mi son detta che Salvatore è così: o lo ami o lo odi e io non ho ancora conosciuto nessuno che lo odi.

Later this year The Pirate Bay will celebrate its 10th anniversary. Quite an achievement for a site that has been dragged into lawsuits for the better half of its existence.

Looking ahead we wanted to discover the oldest active torrent to have survived all of these troubles.

After digging around for a while we found that the honor goes to a pirated copy of the documentary “Revolution OS.” The torrent in question was uploaded March 31, 2004.

At the time there were only a few hundred torrent files stored on The Pirate Bay, compared to more than 2 million today. Over the years just 15 people left a comment on the torrent and at the time of writing it has 27 seeders.

There is some irony in the fact that a “pirated” copy of a movie about Linux, GNU and the free software movement is the longest seeded torrent. Richard Stallman, one of the key figures in the documentary, will be proud.

Revolution OS director J.T.S. Moore has mixed feelings about the achievement.

“It’s definitely a problem, but I guess there’s some satisfaction in knowing that REVOLUTION OS still has appeal for some people twelve years later,” Moore told TorrentFreak.

Revolution OS

But is Revolution OS also the oldest active torrent overall?

No, that honor goes to another non-mainstream product. The torrent file that has been around for the longest time according to our knowledge is The Matrix ASCII.

We already crowned this one the oldest torrent back in 2005, and as of today it is still active with a few downloaders and seeders. The torrent file in question was created in December 2003 when The Pirate Bay was only a few months old and when Facebook and YouTube didn’t yet exist. Thus far, this torrent has survived a mind-boggling 3,333 days.

Since we’re talking about records we should also mention the largest and smallest torrents on The Pirate Bay. The largest active torrent is an archive of the late Geocities.com, that was shut down by Yahoo in 2010. The 641.32 GB torrent is currently battling for its survival with just one seeder.

The smallest torrent, just over 3 kb, points to an Adobe Photoshop “crack”. In this case the torrent file itself takes up more disk space than the download itself. With more than 1,000 seeders this one is expected to be around for a while.

Next year the Revolution OS torrent is set to turn 10 years old, and we have a feeling that it will still be around to celebrate its birthday.

Update: The information on the oldest “active” torrent was provided to us by The Pirate Bay, with the criteria that it should have at least one seeder and one leecher. A commenter (vetyu) rightfully points out that there is a torrent that’s a few days older with 1 seeder and no leechers.

Source: The Pirate Bay’s Oldest Torrent is “Revolution OS”

I was born in a house of many typewriters. All the members of my family used Olivetti typewriters for work reasons or to type down their thoughts and keep them in order and the recurrent noise of the typebars hitting the platen is definitely one of my earliest (and to tell you the truth at times quite annoying...) memories.

Many things changed around myself, but the typewriters still surround me: occasionally my young nephews sit in front of one and tell me they're writing a poem or a novel. In my personal history, Olivetti typewriters are therefore linked to happy memories and I must admit that in the last few months while considering the Italian financial and political crisis, Adriano Olivetti often came to my mind.

Celebrated last year also in one of the sections of the Italian Pavilion during the 13th International Venice Architecture Exhibition (through images, books, adverts and obviously typewriters), Adriano Olivetti was an enlightened businessman with a strong interest in art, architecture, culture, design, graphics, politics and town planning.

As a young man he developed in postwar Italy the factory that he inherited from his father Camillo and turned it into a cutting-edge international business, focusing on electronics in the early 1950s.

Yet Adriano Olivetti is also remembered as an innovator, a urban planner, a multifaceted intellectual, and a politician. Rather than just running a business, Olivetti experimented with new welfare models that could have improved society.

He often employed scholars, sociologists, economists, artists and architects in the company’s production activity and in sectors apparently foreign to them. Throughout the years he worked with many famous architects including Carlo Scarpa, Vico Magistretti, Gae Aulenti, Ettore Sottsass, Michele De Lucchi, Kenzo Tange, Louis Kahn and Le Corbusier, among the others.

Olivetti thought industry had an ethical role and firmly believed in a city organised as a place of social meeting. He created industrial complexes with homes and services capable of offering the workers the best conditions of social and cultural life, turning into this way boring industrial sites into factory cities and experimental modules.

Olivetti also contributed to the publishing sector through his magazines, writings as editor and publishing houses NEI (Nuova Editrice Ivrea) and Edizioni di Comunità.

Many Olivetti products became symbols of excellent Made in Italy design, winning important awards and later on became part of the permanent collections of many museums across the world, including New York's MOMA.

While Olivetti products may be part of prestigious collections and while the architectural works the entrepreneur built in Ivrea were officially chosen as candidates for UNESCO’s World Heritage Sites last year, Adriano Olivetti is often remembered as a model who can help us facing up the global crisis and rethinking new strategies that can link innovative industries, civil society and culture.

Bearing all this in mind, thinking about my personal history and remembering that this year marks the 105th anniversary of the Olivetti company, I came up with this typewriter necklace.

The main elements, the rabbit-shaped (yes, they do look like cute rabbits View this photo) typebars (note: it can be a bit of a hard job to disassemble them one by one, especially if you don't have the proper tools, and Olivetti typewriters are pretty solid, so it can take a few hours of work to destroy one and then clean all the pieces you need...) are taken from an Olivetti "Lettera 42" typewriter I rescued from a second-hand shop (you see, I can't disassemble my family's heirlooms).

The main aim of this piece was transforming industrial remnants, creating something with a different meaning and a new kind of beauty that indirectly told my personal history, while referencing the history of Italian design and of the unknown person who owned that typewriter.  

I reassembled the typebars with some Meccano-style pieces as a reference to industrial materials, but also to Adriano Olivetti's playful and creative imagination.

Since it's made with Meccano pieces, the necklace can be disassembled and reassembled in different ways, and this hints at two things - first the construction and mechanics of language and how single letters form words and sentences; second Adriano Olivetti's policy focused on giving people a variety of opportunities.

"Design is a question of substance, not just form," Adriano Olivetti once stated. "It’s a tool a company uses through its products, graphics, and architecture to convey an image that is not just simply appearance but a tangible reflection of a way of being and operating".

I wonder what he would think if he saw some vital parts of one of his products being turned into a decorative piece of jewellery. Somehow, I think that, deep down, he would approve.

Member of the Boxxet Network of Blogs, Videos and Photos

Member of the Boxxet Network of Blogs, Videos and Photos

Add to Technorati Favorites

Related articles Ars Inter-Media: Renato Nicolodi's Structural Rigour and Clarity of Forms Architecture as Reliable Source for Fashion Behind His Five Principles, In His Secret Studio: Moment - Le Corbusier's Secret Laboratory @ Stockholm's Moderna Museet Chromatic Power in a Polaroid: Couleurs de L'Ombre by Hiroshi Sugimoto @ The Singapore Tyler Print Institute Academy of Art University Special - Part 1: Spotlight on Janine M. Villa and Amanda Nervig

Earlier today we launched Super Sync Sports, a Chrome Experiment. It’s an interactive web game that enables up to four friends to compete in running, swimming and cycling events on a shared computer screen, using their smartphones or tablets as game controllers.



Super Sync Sports was built with the latest browser technologies:

• Touch APIs to recognise gestures made on your smartphone and tablet. 
• WebSockets are used to deliver immediate real-time playback across all the players in your group and to update the main game screen as you play. 
• Finally, CSS3, SVG and Canvas provide rich visuals and an immersive experience. 

In the next few weeks, we’ll be publishing an article on HTML5 Rocks with more information on how we built this experience. You can follow +Google Chrome Developers to learn when the article will be live.

In the meantime, enjoy competing with your friends at chrome.com/supersyncsports and be sure to open Chrome’s developer tools to see what happens under the track!

Posted by Paul Kinlan, Developer Advocate