faboo, posts by tag: programming - LiveJournal — LiveJournal

09:38 pm - a grammar

( Comments?Collapse )

Current Mood: drowsy

01:57 am - damn you microsoft

It compiles!

03:13 am - Note to self

just because you have to a assume that memoization might happen, doesn't mean you can assume that memoization will happen.

( exhibit ACollapse )

Current Mood: bemused

04:50 am - more keywords

why do (seemingly) all programming languages use rediculously simply selection schemes? take C's if/else, for example:

if( SOME CONDITION )
  do_stuff();
else
  do_other_stuff();

that's pretty demostrative of the general state of things. but why not something like the following:

if( SOME CONDITION )
  do_stuff();
elsif( MORE CONDITION )
  do_more_stuff();
any
  do_in_any_case();
else
  do_other_stuff();

where "elsif" is checked only if the "if" failed, and "any" is executed if _either_ of the above conditions passed (and "else" only if neither passed, obviously).

is that so weird? am I the only programmer who's ever wanted that? I bet it's in PL/1. and hey, if it's good enough for the DoD, it's good enough for me.

01:04 am - perl6 will make you eat your pants

macro circumfix:</* */> ($x)
	is parsed / .*? /
	{ '' }

01:05 am - hybrid garbage collectors

I read a while ago (in the perl6 faq) that a hybrid tracing/reference-counting collector was stupid because of the extra overhead. at the time it seemed to make sense.

so, I've just started adapting a marksweep garbage collector into a generational collector. generational collectors split objects into two groups: an infant group and a geriatric (mature ;-) group. geriatric objects are considered long-term stable and their livelihood isn't verified very often. infant objects are considered volatile and their livelihood is verified often.

in order to ensure that 1) references from a geriatric object to an infant object are accounted for and 2) geriatric objects do not (as a whole) need to analyzed very often, a table of geriatric-to-infant references needs to be kept.

it now occurs to me this table (particularly how I've represented it) can serve as reference counter (if infant-to-infant references are included), and that object destruction based solely on such a table is possible. I also don't see how this is actually wasteful (of time) as: this list of references has to be checked during each garbage collection cycle anyhow; the infant objects need to be traced during each garbage collection cycle anyhow; eventually all the objects will be traced anyhow.

I don't think you'd gain much doing this however. at best, you'd gain a modicum of certainty (that when an object is no longer referenced it will soon be destroyed), and at worst you'd waste extra space on infant-to-infant references (and given that most references to infant objects will be from other infant objects, this could be a lot of extra space).

(there are variations on generational collectors that assume that older objects will become unused more often, and that very old and very young objects will become unused at the same rate.)

Current Mood: sick

09:37 pm - makemake.pl Copyright 1993

I just realized that the oldest, best maintained program that I've written and use regularly is a Perl program that generates make files.

there's something very odd and sad about that.

don't get me wrong here, it's a very robust, full featured program. it handles mixed language projects (combinations of C, C++, and Haskell anyway), Java, C#, lex files, yacc files, user defined rules and variables, projects with multiple programs, and dependency tracking (that's new :) it generates rules for building, dependencies, packaging, clean up, and installation. its makefiles are clean, well formed, and well documented.

but it just builds makefiles. my other well used program, installtar, is written in Perl and doesn't use it. obviously, I _do_ write C, C++, Haskell, and Java programs (to hell with you C#!), or I wouldn't maintain a program to help work on them.

so what does this discovery mean about my ability to follow through with the use and maintainance of these programs?

Current Mood: disappointed

02:28 am - holy s-expression batman!

so, I've been working on a much-too-big-for-ten-weeks project for the past seven weeks. a (relatively) small, functional, lazy-evaluated language that is dynamically (and strongly) typed and garbage collected.

I'd like to announce, that just now, I've _finally_ gotten the language/interpreter itself and the first garbage collector finished.

WOW.

oddly, the garbage collector its self took very little time.

writing the interpreter for the language didn't take that long either. (though my initial attempt at lazy-evaluation was rather half-assed and broken)

it was actually retro-fitting the interpreter to support garbage collection and writing a memory manager (malloc/free-ish) and internal execution stack that took so damn long.

the next one, I daresay will go rather quickly.

Current Mood: ecstatic

11:01 pm - why yes, usibility is important

one of the coolest things about Free Software is that it allows for much faster bug fixing than traditional development (generally does). as Eric Raymond is fond of saying, many eyes make bugs shallow. the Free Software concept encourages communication - between developers and between developers and users. the sense of community that the Free Software idea fosters helps users bring to light the problems and failings in the software they use.

I just found what I think may be a bug in Firefox. there are four steps to reporting a bug in Firefox. two of them are downloading and installing new web browsers.

let me repeat two key pieces of information:

1. Free Software has the opportunity to be better because of the ease of communication between users and developers.
2. in order to report bugs in Firefox you must first download and install a Firefox nightly build, and then download and install a Mozilla Application Suite nightly build.

Firefox is a big and popular project. I imagine the number of reported, unfixed bugs is huge. I've really got to wonder, however, about what kind of sample of the Firefox user community is represented in those bug reports. how many normal users are going to download and install two new, unstable browsers; test the bug in that browser; and then report a bug?

don't get me wrong, Talk Back is a great feature, and Firefox version 1.5 incorporates a "Report Broken Website" feature. however, for Free Software and Open Source Software to really shine (in reality and in the minds of users), bugs and other problems need to be easy to report, and those reports need to be looked at and addressed.

Current Mood: irritated

04:19 am

dude. software engineering? stupid. Gtk developers? silly. perl-gtk2 developers? odd.

so, I'm trying to display a nice tree of installed packages/programs, their versions, and the files they contain. that ought to be a bit of work, but not too hard figure out. it at least used to be.

Gtk does, in fact, contain a widget for displaying trees of (tabulated?) data. however, this widget is actually six to twenty widgets.

see, the "tree widget" in Gtk is built around a "model, vigew, controller" design. so, there's a TreeStore (the model), which is basically just annotated storage space; a TreeView (presumably, the view), which is, from what I can tell, a big white box; a TreeViewColumn, which (kind of) displays a single column of data; and CellRenderers (of various kinds for various kinds of data), which actually draw things on the screen.

where the controller is in all that, I have no idea.

this design is very versatile. you can have multi-column trees (what that looks like, I have no idea), check boxes, text, icons, various kinds of sorting, and loads of things I'm not smart enough to think of.

however, if all you really want to do is display tree-like data (XML, or family tree, for example), then in addition to the object you'll actually add data to (the TreeStore) you need to create a TreeView, a TreeViewColumn, and a CellRendererText, none of which you really care about. most of the twiddling that you'll do to those objects is associating them with each other.

and, just to be outright silly, in order to add things to the tree, you have to grab a TreeIter from the TreeStore. this object _isn't_ an iterator, however. you cannot, in fact, use it to iterate over the contents of the TreeStore. you need a _new_ TreeIter for every object you add to the TreeStore.

all of this in a language designed to make the impossible possible and the difficult easy. at least the core is swank.

Current Mood: irritated