Journal de Jamber

My code—or rather my bugs, you could say—have apparently been trying to make an artistic statement.

No comment, except... I think they succeeded. o..o

template<> struct promote<byte, unsigned shirt> { ... }

(decoderGroup new: `x86ArithmeticRegOps
    memberWhen:   `($code[0]  ~ @00??????
                 && $code[0] !~ @00????11)
    memberIndex:  `($code[0] takeBits: %00111000)
    members:      [ADD OR ADC SBB AND SUB XOR CMP]
    details:      [
        `(if `($code[0] ~ @???????1)
            ($dataSize = [32 16] choose:
                (bits16 in $cpuMode
                    ^^ toggleSize in $prefixes))
            ($dataSize = 8)
            )
        `($args = ($code[0] takeBits: %00000110)
            selectFrom: [
                (ModRMArgs bytes: code[1..] dest: regOrMem  src: reg)
                (ModRMArgs bytes: code[1..] dest: reg       src: regOrMem)
                (ImmedArgs bytes: code[1..] dest:
                    ([8:regAL 16:regAX 32:regEAX]
                        choose: $dataSize))
            ])
    ])

I thought I'd try the Visual .NET Forms stuff in MSVC++ 2005. I hoped I could get a decent GUI up and keep the rest of my code as clean, platform-independent C++.

Maybe I'm just stupid, but this is the simplest way I could find to get a std::wstring path out of an explorer icon dragged atop the form:

System::Void MainWin_DragDrop(
    System::Object^ sender,
    System::Windows::Forms::DragEventArgs^ e
) {
    array<String^>^ dropList =
        dynamic_cast<array<String^>^>(
            e->Data->GetData( DataFormats::FileDrop ));
    
    String^         filePathCLR = dropList[0];
    std::wstring    filePathSTL;
    	 
    // "Obvious" method
    //for each( wchar_t c in filePathCLR )
    //	filePathSTL.push_back(c);
    
    // Suggested method (MSVC documentation... srsly)
    using namespace Runtime::InteropServices;
    const wchar_t* filePathRaw = (wchar_t*)(
        (Marshal::StringToHGlobalUni( filePathCLR )).ToPointer()
    );
    filePathSTL = filePathRaw;
    Marshal::FreeHGlobal(IntPtr( (void*)filePathRaw ));
    
    m_MyObj = new SomeDocumentObject(filePathSTL);
    // ...
}

There are several interesting things to be seen here. I'm not sure what to think of them.

For one thing, this isn't even C++! They've added a whole chunk of C# as completely new syntax. Seen here are the ^ which is their garbage-collected heap pointer, array (which is a keyword and derives from System::Array), and a few bits of their class library. Also notice the for each, where each and in are context-sensitive (!!) as keywords.

Oh, and don't even get me started on the freaking casts.

This syntax is completely required. The form designer generates it, and their library depends on the special references. That's because if you compile in "safe" mode, hoping to run under someone's tight security policy (and they encourage you to)... pointers aren't even allowed!

Naturally, this breaks just about every useful piece of C and C++ out there, including the all-important STL which sets C++ apart. While I understand the security motivation, I think this is misleading on MS's part, since at that point, it's not C++ anymore! It's just another dialect of C#, or maybe C# with templates. :/

I could simply compile in "pure" mode (effectively, insecure bytecode), and use the STL with the bureaucracy above, but it's still annoying. Mmmfeh.

So tonight, I was perusing some annoyingly table-y tech reference, and I wondered if it was feasible to print this out, four pages to a double-sided letter sheet, and bind it into bookish form. To my surprise, OpenOffice actually has some basic stuff documented, and I was able to get proper page headering and left/right page margins.

Time to print! I checked the Bookbinding Page Calculator, and got the following 2-up page orderings:

Front: 32,1,30,3,28,5,26,7,24,9,22,11,20,13,18,15,
1,33,1,35,1,37,1,39,1,41,54,43,52,45,50,47
Back: 2,31,4,29,6,27,8,25,10,23,12,21,14,19,16,17,
34,1,36,1,38,1,40,1,42,55,44,53,46,51,48,49

Feeling wary, I tried this first with the excellent PDFCreator. And fortunately so--can you guess what I got? Why, yes...!

1,3,5,7,9,11,13,15,18,20,22,24,26,28,30,32,33,35,37,39,41,43,45,47,50,52,54

So apparently some programmer thought he was ZOMG CLEVER!!@ and decided to "helpfully" union and sort the list. Except (nevermind, I think, that MS Word doesn't) that's not the purpose of this option at all! If anyone wanted foolproof consecutive numbers, they'd type a page range... yeah. Real smart.

*growls*

On another note, Windows Live Writer is still very sparse and beta, but actually kinda promising. For one thing, it works with LiveJournal (!) among others. I can take screenshots and paste them right in, and it uploads to Scrapbook without ever needing to save in between. They also try to grab your blog style and display it all WYSIWYG-like in the editor, although it doesn't completely work for me yet. Supposedly, it supports plugins.

Bah. I don't remember what else I wanted to say.

width   = 2{page} * 10.5{in} * 600{dpi};
height  = 2{Page} *  8.0{in} * 600{dpi};
iters   = 10,000;
samples = 10,000;

let pn+1 = µ * (1 - pn) * pn;

let pixels[] = 1.0;
let pixels[xc, yc] = 0,
where
  xc = floor(µ * width / 4),
  yc = floor(piters * height),
  p0 = 0.5 * index / (samples - 1),
  index = floor(x), x over [0..samples-1],
  µ over [0..4];

CPU: 88%
Working set: 9,420K
Virtual size: 478,228K
Page faults: 238,735

Rendering... 42.381%

I think this is gonna be awhile. :>

Yanno, I really wish there was a language like this. The compiler ought to be able to slurp up all these clauses at once, and then say:

"Hey, pixels at xc and yc should be zero, but what are those? Oh, I see xc is an integer coming from a formula involving µ which covers the range 0..4. So we'll try all the integers 0..width. And yc involves p_iters, and okay, I can get that starting with p₀, but then I have to try all values of index... Of course with two variables involved I have to try all the combinations, and p is an iterated function so it's really a triply nested loop.."

Well, you get the idea. Maybe there is something like that already, but it sounds pretty academic. For now, the actual code's in Delphi.

[13:40] Edit: Well, it's always the littlest things. I rotated the whole thing 90° so it stopped thrashing the processor/page caches, and killed a couple (!) of redundant zero-fills in the graphics stuff. Kinda important when the graphics get that huge! And noticably faster. No trying to commit that virtual 500MB at once.

Still the same size, but now it's more like 90+% CPU, 6MB working set and 1,690 pagefaults. It should just stream out to the swapfile as it touches the rest, since it never reads them except to save at the end. Yay or sommin.

I wonder how much this sorta tuning conspires to wreck the notions above. In this case, the value (and not just the curse) of imperative languages is being, well, imperative! A good inferential compiler would have to think pretty hard about this stuff, maybe even experiment at runtime. (Now that I think of it, perhaps the SQL people have already been there, it's quite similar in spirit.)

So DietPower, the food logger I use, decided as long as I'm sitting here, I could wait two minutes for the food log to open. It was already slow, but now it's firmly in the realm of code that doesn't scale.

C'mon, it's clearly a C job. No excuse. I know people who write faster apps in Perl!

Another irritating thing is it's missing an export option, so the only way to get the logs out involves manual inspection, and then writing the code. The latter's not so hard, but I always used to cringe at binary files. Maybe the braver people would drag out a hex editor.

Well, the first thing I reach for is EDIT.COM. That used to be because it's all I had that reliably saved binaries... too bad it doesn't do hex, right? But after awhile I noticed that an ascii view is really useful, quite possibly moreso.

For one, you get the best use of screen space, which reveals a lot of patterns. Intel code is very dense, with the occasional word-size data thrown in. C structs with small numbers (e.g. most of them) leave a lot of zero padding. Pointers and offsets can be seen growing throughout the file. Text, of course, is immediately readable.

Repeated data shows up especially well, since nearly every byte has a unique glyph. The exceptions, 0x00/0x20/0xff, are blank. Happily, this includes various representations of nil: space, the integers 0 and -1, floating-point zero--and unused numeric precision.

Other values show up too, for example values centered around 0x3f (?, @, A) which are sign/exponent bits for small positive floats. "  Ç┐" happens to be 0xbf800000, or -1.0. At left, it marks unspecified nutritional values. (Sloppy coding has introduced other negative values as well!)

If the file is just a series of structs, it shows up as angular striations, betraying the length and number of the records. Usually somewhere nearby is the count. If you know your hex and ascii (essentially base-16/256), you'll quickly find it, and now you can write a skeletal reader.

And then you can go try all the program's special cases, and make note of what it spits out. This is how I wrote my OpenCanvas reader. Maybe I can get DietPower's logs into a spreadsheet or something...

It does give me thoughts, though. Using EDIT works great, but it's still a pain to do the math. I wonder if there's a better editor out there. I think I should be able to select regions, say "this looks like a record", and have the thing pattern-matched down the whole file. Then I could say "these are float fields", and it would update everywhere.

I think I would have circular tooltips, where you hover over some data and it shows you all the different values it could be in each representation it knows, and then the most likely one. (0's or 1's on the left = small int, high bits near 0xbf, 0x3f = small float, compare to values in other instances of the record...) Then you'd right-drag through a pie menu to choose one of them.

There could even be a hex view, either through a lens tool, or using a color mapping on top of the numbers, to show patterns. Or you could space things out and display assembler inline with all the other data, using heuristics (statistics, file headers) or manual selection to identify the code.

Ideally it would come with different plugins for the known formats, and people could write their own. You could use it as a teaching tool for Operating systems 101, or to help debug things, or repair corrupt files.

Ohwell, I'm probably dreaming. But it would be helpful right now.

If you can stand the quirks/don't need C++, Tiny C is amazing. Where GCC takes entire seconds per file on my machine, a Makefile running TCC spills output faster than the xterm can display. I only wish I was kidding!

TCC also comes in a library form that you can plug into your apps to compile C "scripts", can do optional bounds and pointer checking at runtime, and it even squeezes onto a floppy. Mind, it doesn't generate the best code, but then again, most isn't time-sensitive—and if your algorithms depend on a clever optimizer to be usable, they probably won't scale as it is... But I digress. In fact, there was a problem...

Kahmynx@FRANCIS /c/Code/Magenta_bloo $ make run
tcc -g -o build/magenta.exe Fuschia.o Cyan.o White.o
  -L/Dev/gc6.6 -lkernel32 -luser32 -lgdi32 -lgc
build/magenta.exe
Segmentation fault

make: *** [run] error 5

Kahmynx@FRANCIS /c/Code/Magenta $ gdb build/Magenta.exe
The debugging information in 
  `c:\Code\Magenta_bloo/build/Magenta.exe' is corrupted.
The file has a `.stabs' section, but no `.stabstr' section.
(gdb) break main
No symbol table is loaded.  Use the "file" command.
(gdb) . o O ( wtf? )

/* load an object file and merge it with current files */
/* XXX: handle correctly stab (debug) info */
static int tcc_load_object_file(
  TCCState *s1, int fd, unsigned long file_offset)
{

"Correctly?" Erk!! Well they don't call it v0.9 for nothing, but it's not the sort of commentary one wants to see in a compiler!

But with the company of lazyweb, and some quick if mind-numbing research, things are looking up. Many hours later:

# Why not? Btw, no visible delay here
Kahmynx@FRANCIS /Dev/tcc/src $ ../tcc -g tcc.c -lkernel32
Kahmynx@FRANCIS /Dev/tcc/src $ ./tcc -g mathtest.o win32/lib/crt1.o
  -L./win32/lib -B./win32/lib
Kahmynx@FRANCIS /Dev/tcc/src $ gdb mathtest.exe
(gdb) break main
Breakpoint 1 at 0x4011da:
  file c:/Code/Magenta_bloo/scraps/mathtest.c, line 94.
(gdb) list
85              unsigned overflow = xor & (x ^ modulo) & 0x80808080;
86              unsigned over_p = overflow & modulo;
87              over_p = over_p - (over_p >> 7);
88              unsigned over_np = overflow - (overflow >> 7);
89              return (modulo ^ overflow) & ~over_np | over_p;
90      }
91      
92      int main(int argc, char**argv)
93      {
94              if( argc < 4 )
(gdb)

And right now this is the most gratifying thing, being able to go and hack on the compiler, and even sort of comprehend what I'm doing. It's the wonderful feeling of a warm light shown on things that are black magic to most people...

Or maybe the feeling I might take over the world next Tuesday. That doesn't seem substantiated, though.

• Eliminating the expectation on a given day (within deadlines, just do the next doable thing);
  
• Never writing anything down, or thinking about it (to decide whether to actually do it, etc), more than -once-;
  
• Reviewing the notes and such, so you keep them off your brain;
  
• Making sure the "todo items" (as distinct from "projects") are actually things you can do in exactly one step. Otherwise, if it is sufficiently complex, it will be unclear and scary and confusing, and never get done (this stalls many of my programming ideas).

Not much progress on the code front, but I did take the time to work out OC's image format for future compatibility. I haven't seen this anywhere, so I might as well put it here. This is what goes into the *.wpb's.

( OC 1.1 b71 *.wpb structure )