Older blog entries for ingvar (starting at number 130)

Micro-tool now packaged (not ASDF-Install-able yet, though).

Current feature-list:

1. Handles documents included by \input and \include
2. Only further processes documents matching *.tex
3. Can parse \epsfig

On "possible future features" is "handle BibTeX files".

Available here

New micro-tool written, a piece of code to extract dependency information from a LaTeX document (at the moment, it only follows \input and \include).

If there is enough interest, I'll package it up with ASDF and make it available.

The important part there being surface. generally sear means the outside is blackened to seal the inside, which is the heated, but not cooked to what most would consider "medium" or "done". this is the case with tuna which is so often served "seared" as an appetizer, which essentially equates to raw. Such is the way I like my steak, and indeed is the only way to eat a steak that preserves its flavor. Otherwise, you need to use things like marinades. and, ugh, who wants to use a marinade? You pay $30/lb for USDA Prime steak for a reason. It tastes good. Putting a marinade on it is a waste of money. Cooking it until it is grey and brown is senseless, and I think it should be legal to shoot people for killing a cow without savoring its seared meat. Heathen.

I may be a heathen but the fact is taht the searing doesn't do much for sealing juices in the meat. What does affect that is (basically) the moisture level during the cooking. My preferred way of preparing a slice of beef (ca 15-20 mm thick) is to take a frying pan, add in a small amount of fat (usually butter or oil), add some coarse-ground black pepper and some finely-ground white pepper. Plonk beef in, one side down and let sit until there's been enough indication iof "heat penetration" on the upper side, then flip it over and let sit for about as long. You can shorten the cooking time by simply putting a lid over. Tends to produce a moist result, cooked through and through. For slightly less cooked centres, simply take a thicker slice of meat. The flavour is usually spot-on too.As for the dictionary reference, yes, I am aware what "seared" means. Thus my reference to "coal-heated steel bars". I'd still not want it anything but well-done, thank you very much, since I don't enjoy throwing my meat up over my plate or the floor and I'd expect the restaurant to be quite upset too.

Routersim is progressing at an amusingly slow pace. At the moment I'm coding PRINT-OBJECT methods for access lists, prefix lists and route-maps, so I can start lookuing at debugging that part of the code. Still need to decide on exactly what mechanism I'll be using for sending update messages. I'm expecting them to be somethiong along a SEND-MESSAGE GF, with message objects depending on routing protocol, interface and recipient as arguments. possibly only using recipient. Then, on the other end, use a RECEIVE-MESSAGE GF dispatching things to the right place in the recipient router object and triggering updates as needed. With that in place, I should be able to code interfaces heading outside of the lisp image and cause (say) BGP talk to happen to an actual BGP router.

In this entry avrietta writes:

I cannot imagine how offended your waiter and chef were by being asked to destroy a piece of beef like that.

Seared, with a cool red center, if you please. Well done? For fuck's sake. I bet you like Pilsners and drink Corona with a lime.

Well-done doesn't mean seared. If I wanted it seared (usually on coal-heated steel bars), I'd aask for it "seared". I will, however, not ask for it rare or medium, since (in general) taht would have me throw up as I eat. If the chef and/or waiter has a problem with that (or, indeed, deep-fry and further incinerate the meat), I feel fully justified in not paying for the meal (what with not having been given what I ordered), not eat the meal and never grace the establishment with my patronage in the future.

In coding news, I have added another GF to routersim, this one to establish if a RIB is of a given sub-type. this (probably) means I need to update the package definitions.

Inspired by my "ease package packing-up" from yesterday I revisited some old and dusty code this morning, namely my code to implement RIBs and FIBs (and, eventually, once I get around to CLIM, with a user interface and "trace packets from A to B and back"). It was very dusty indeed and after having choked a bit on the code, I ended up checking it into my local CVS. That, in turn, reminded me that I should get around to check in all other code in CVS and (probably) start tagging the code with release tags.

However, as things stand, I shall be doodling on the routing code and see how workable the current approach is, my memories of musings walking to the train in the mornings sometime mid-January tells me that there is a fundamental problem with the underlying code for the RIB data structure and that while teh RIB and FIB are (essentially) very similar, the differences between them may require a specialised class for the FIB tree.

Very much "no coding" (except from "coding for work", but that is work, not play and so doesn't count, unless I have arranged a "let it free" agreement for it beforehand) for a good while. One micro-utility to simplify building ASDF-INSTALL-able packages, though. World, meet build-asdf-package. No docs, as of yet (well, there's some built-in help text) so here goes: "list all files you want in the package in .filelist and either force a version using -v version or have it in .version".

Thinking further on the whole "what is derivation" issue I have been discussing with Brian Mastenbrook (here, here, here and here).

After some thinking (and essay writing), I think the main contention is "is the copyright on the source, on the executable or on both".

Clearly, if the copyright covers the executable program, it will be incorporating the object library it links to and thus, at all instances of actually running, be a derived work.

Likewise, if the copyright is on the source code, it will only be referencing the library and thus ends up in a similar position to a critique, referencing well-chosen sections of another work.

And, naturally, I managde to misread the Lesstif homepage. Lesstif is licensed using LGPL and thus my whole analogy crumbles liek a badly-built house of cards.

Brian Mastenbrook replies to my reply on his blog entry on possible GPL problems:

Ingvar responded to my last post about the GPL. He says "When linking against libreadline, dynamically or not, libreadline is incorporated in whatever program is written and the result is, thus, a derivative work of libreadline." Unfortunately, I can't see how this works - the binary which dynamically links to libreadline references parts of the library by name, but I can't see how it's incorporating the library.

This is an interesting question that I tried to address in my diary entry. My thesis, for now, is that "standard dynamic linking" (as in "compile with suitable -l switches and end up with a binary that uses the system-provided dynamic linker to suck in the relevant dynamic libraries on program start") is morally equivalent to static linking and the "dynamic/static" distinction is merely cosmetic. This, in my view, means that one should copnsider what is derivative or not as if there were static linking happening.

He also references the Why CLISP is GPL mail exchange between Bruno Haible and RMS. In there, RMS tries to argue that providing a no-op stub for libreadline and providing instructions for how to link with libreadline still requires licensing CLISP as GPL. I would, off-hand, consider RMs to be wrong in this, since it places the "use readline or not, default is do not use it" squarely in the hands of the user.

Furthermore, I seem to have picked a somewhat unfortunate GPL library to use as example, since dtucker (in this entry) describes the NetBSD somewhat-plug-compatible readline replacement.

What I am trying to say is that there are at least two slightly different (from an "intent" point of view) ways of doing dynamic linking. Type 1 happens "under the hood" (normal, system-provided dynamic linking as patr of the normal startup process). Type 2 happens when the programmer explicitly writes code to link an external library into the program space. I'd say that when type 1 dynamic linking happens (and there are at least one non-GPL library that is API compatible) the facttaht it (on some computers) ends up linking against the GPL libarry is of no consequence fro teh GPL status of the program. Otherwise we'd end up in the thorny situation that all Motif programs must be GPL (since Lesstif puports to be a plug-compatible replacement lib and is GPLed). This is obviously absurd. Likewise, if I distribute my code with a library that is plug-compatible with a GPL library, I should be able to license my code as I want. Similarly, if I write a replacement library for a commercial library, I should be able to ship the code with my replacement library too. There might, of course, be other requirements on the commercial library.

Brian also writes (referring to me talking about commercial software libraries and commitments in code linking to them):

I'm not sure this is a convincing argument, since commercial libraries are by definition non-free, and for many of the same reasons that I would consider the GPL to be non-free too.

If we ignore the "free/non-free" distinction for the moment (it is, I find, a slight problem that RMS chose "Free" as a descriptive qualifier, I understand his reasoning behind it but there are interesting emotional undertones to the word "Free"), does it amke sense that GPL-licensed software requires derived software to be licensde under the same (or at least compatible) terms? Yes, without this requirement, the GPL wouldn't do what RMS wants it to do. I feel that this is the reason behind RMS arguing so strongly that providing a no-function readline library with CLISP is "just a circumvention device" (to paraphrase his reasoning why doing so would be bad).

As for "is GPL software non-free", the answer is "it depends on your definition of free". They are ceraintly license-encumbered. All software that is not in the public domain is, though in some cases (BSD without advertising clause) it's not really noticeable.

One must, before releasing GPLed software (or linking to GPLed software) consider if taht is the Right Thing to do. Most of my hobby-written software is released under the GPL, with an explicit mention to contact me if licensing under other terms is wanted. Most CL code I release is actually released as public domain (since it gets bundled with SBCL contributed code), since I feel that GPL and CL is a sticky mix I prefer not really touching.

Brian Mastenbrook mentions potential GPL problems. Specifically, what constitutes/does not constitute a derivative work. The specific example he chose was unfortunate in that libreadline comes in GPL flavour only and thus there is no non-GPL "vendor" who is API compatiple and one can therefore assume that his program linking against libreadline would be useless without that.

As far as I am aware, incorporating substantial material into work A from another (copyrighted) work B is, in the eyes of the law, creating a derivative work of work B. When linking against libreadline, dynamically or not, libreadline is incorporated in whatever program is written and the result is, thus, a derivative work of libreadline.

At least that is, as far as I am aware, the reasoning behind "link against GPL and you need to comply with the license". Having worked for a while at a software house, linking against any commercially available library does entail getting a specific license that allows incorporation and may (possibly) entail further per-seat or per-site license fees. This is, again, because the end result is a derivative work.

Note that in the "commercial library" case there tends to be an extreme lack of API-compatible code, so there's a choice of "write code oneself" or "use the commercial library". I can easily see the need for implementing a non-GPL libreadline with a compatible API. That way, people who want to write code using a libreadline-alike have a choice (either compile-time or, for dlopen() and friends, run-time) between using a GPL or non-GPL library.

Harking back to what Brian writes, it is slightly murky if he means dynamically link against as a compile-time "linked againsta dynamic library" or "run-time dynamic linking with explicit code handling and use of dlopen()" (there is, in my view, a small difference between these).

In the first case, I see no moral distinction between static and dynamic linking. The intent is definitely to incorporate a library into the program. In the second, it is slightly murkier, in that tehre could be code trying to find a non-free version by preference and only when not finding that falling back to a GPL version or (possibly) no version at all.

In the case of CL, it's hyper-murky, since the only way one can interact (as far as I know, with the majority of CL compilers) with a normal C library is by the latter method.