Older blog entries for sej (starting at number 136)

16 Apr 2002 (updated 23 Apr 2002 at 18:56 UTC) »

I'm in trivial diary commentary mode today. Too bad we don't have that entry cross-reference mechanism yet :-).

lindsey, the cc of MacOS X is gcc. Try "cc -v". I get:

Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs
Apple Computer, Inc. version gcc-932.1, based on gcc version 2.95.2 19991024 (release)

chalst, I think that is a job for the United Nations, not the United States.

15 Apr 2002 (updated 15 Apr 2002 at 17:32 UTC) »
amars, that swinging patent has to be a deliberate attempt to make the patent office look foolish. Like registering a dog to take classes at a university. How did you come across it (or maybe that is a question for yusufg)?

Been adding matrix operations to the command interpreter of ivtools. Now you could experimentally manipulate graphics in 3d (though you'd want a C implementation for speed if you were doing this interactively). As always the missing piece is the 3d raster transformer with anti-aliasing and perspective. libart? Vector-Agg? Or just commit to OpenGL/Mesa?

Interesting summary that distinguishes patterns and frameworks. Be able to tell the difference when you see them in the wild.

25 Mar 2002 (updated 25 Mar 2002 at 22:27 UTC) »

Just submitted a FreeBSD port of ivtools. I like their meta-makefile approach, and the fact binaries (packages) are automatically derived from sources (ports). I never got the feeling that it was required to synch the two in the RPM world. It is in Debian land, but they seem to layer on a lot of additional protocol, where the FreeBSD ports seems more mellow in their acceptance of whatever already works.

(Ok, I took a look at the www.rpm.org, and I see it really is a full-up system for building from sources of equivalent strength to FreeBSD or Debian. My bad.)

Watched a VH1 documentation on punk rock last night.

Punk is/was an underground culture of do-it-yourself creativity and collaboration that purposefully went against the grain of the mass media machine. Periodically a group breaks through to mass appeal if not riches (Ramones, Husker Du, Nirvana, Green Day), a certain percentage of the sound is transcribed into mass culture, and the cycle repeats itself as those who didn't "make it" carry on with their original motivations.

Sound like any other creative culture you know?

I've evolved my own dynamic language over the years (i.e. scripting language) with a bunch of nice features: conditional execution with stack growth related to nesting depth, not number of iterations; auto-vectorizing (or auto-streaming) operators reminiscent of APL; a syntax that is half C expressions, half Lisp-like parameters (fixed position parameters, both required and optional, and free-format keyword parameters with defaults and overrides).

I would never posit it as a general purpose language for widespread use. Mechanisms for objects and parameterized functions are yet-to-be developed. I've had long-standing plans for these (I started the design in 83, the implementation in 89, the Unix port in 94), but I guess I'm a regular tortoise of a programmer :-).

Instead I've packaged it as the command interpreter extension to a vector-graphic drawing editor, where I'm focusing on two things: primitives for manipulating vector and raster data in the context of a drawing editor, and language mechanisms that make that fun.

As for performance, I'm sure I take the normal 10x hit for a scripting language. I'm proud of the efficiency of the control constructs (for, while, if, each), but any reference to a variable through the symbol table requires a hash operation, and those add up, especially when you rely on them for language internals (any kind of dynamic binding costs at least a 3x hit relative to compiled alternatives).

And, can you believe it, the thing is not flawlessly conceived without kludge or special-case requirements. Don't get me wrong, it's no Perl or TCL. For the most part it is incredibly simple and self-consistent. But there came a day (a year) a while back when I knew I had no hope of perfecting the design without building the language, even if there was little hope in it being perfect if evolved over time.

Why am I writing all this today? Two reasons: obviously raph has made it the topic of the day (hmmm, could that be a new advogato feature?). And I just forced myself to make the first real significant kludge to the language that required an opaque change to the run-time environment (one that can't be explained in simple language-wide terms). And I wanted to tell you about it :-). Sometimes it is the blemishes that make things beautiful. Or maybe that is just my anti-monopolistic polytheistic Scottish world-view talking.

Ya see, "," is the tuple operator (the list concatenator). "1,2,3" yields a list "(1,2,3)". You can assign that to a variable, i.e. "l=1,2,3". Then further values can be concatenated with just the tuple operator, i.e. "l,4" would alter the "l" list to be "(1,2,3,4)".

All fine and quirky, but the problem came up that "(1,2),(3,4)" yields "(1,2,(3,4))", a somewhat counter-intuitive result. A completely consistent result as far as the language goes, but confusing. So I sweated it out a (long) while, and finally made special-case use of the parentheses to the left of the tuple operator, to yield the expected "((1,2),(3,4))". This has the added benefit that now the printed result of evaluating "(1,2),(3,4)" can in turn be evaluated to yield the same result.

I'm so happy. I promise no more of those for a long while. Have a good day.

The platypus release of ivtools is out. And I'm happy to be included in the Debian Jr junior-art package.

C'mon kids, get some legacy code while you can and draw something your dad will love :-)

Making good progress porting ivtools to Darwin. Most of the work is adding #defined(__APPLE__) where-ever there is a #defined(__FreeBSD__). Shared libraries are lib*.version.dylib instead of lib*.so.version. They seem to have tightened the screws down on gcc, like backing out support for #include_next for C (thank goodness it is still there for C++), and they have their own linker with slightly different behavior/arguments. But thanks to inertia this apple doth not fall far from the BSD tree.

Most amazing is my 5 year old Power Macintosh G3 (actually, my wife's) is now my home PC of choice. The 500 Mhz power-pc chip with *BSD is as snappy as my 800 Mhz Pentium with Linux at work. I didn't know I had such a workhorse (workstation) lurking under that old Macintosh software. If you're not a 100% pure copyleftist you might want to check it out :-).

1st annual state of ivtools e-mail.

raph, where can I find the web page for ksvg? I find oblique references in kde.org mailing lists, but no URL. I want to add a link from the vector-graphics foundry page.

auto* certainly is a marketing term for that toolchain. It's only automatic in the case where an end-user gets a configure script that was pre-tested on exactly their setup. Everything else falls off the wagon. I use a blend of autoconf/configure-light and imake. It fits peoples expectations of './configure;make;su -c "make install', and when it works without problem everyone is happy.

When it doesn't work people are often surprised, even miffed that I haven't tried it out on their latest OS. The more miffed they are the less likely they are to help me resolve the problems.

And often people suggest replacing it with whatever they are familiar with. I cringe, and think of the endless hours put into resolving problems to date (most of which are introduced by constantly evolving OS'es), and am not too interested in starting from scratch, throwing out all that work.

But with a fresh source tree hope springs eternal :-)

hacker, it sounds like you have a good case for enforcing copyright infringement. It will be interesting to get to the bottom of the misunderstanding.

Just to help firm it up, have you tried to see things from their perspective? What is the minimal violation they could be guilty of, if you gave them the benefit of the doubt on every close interpretation? I'm not familiar with the Plucker/Bluefish architecture. Could it be they are distributing an unmodified Plucker binary as part of their larger Bluefish distribution, and they believe that since you make the Plucker sources available they are meeting that obligation (not actually enough, but could be forgiven/corrected)? Could they possibly be using a looser definition of derivative work than you, and simply be making minor mistakes in their conformance to source distribution needs?

127 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!