wolfwings

...because I found an incredibly nifty feature of CSS that all this time I hadn't known about, that I'm working to integrate into that web-comic-interface program I was building before: Selectors. It's useful enough I'll deal with posting it here just so everyone on my friends list sees it.

Most folks know about the a:hover CSS-tag that lets you set the 'hover' style for a link, or the div.warning to let you style <div class="warning"> (which is actually a shorthand for something I'm about to show here) but I bet you didn't know about td[direction~="up"] did you? That lets you define new attributes for your elements, for example in this case making this valid: <td direction="up left"> and applying the "up" and "left" styles if you have both defined.

The fairly well-known td.card form (using the class="blah" attribute) is actually nothing more than a shorthand for td[class~="card"] actually. The ~= means that the attribute is treated as a series of space-seperated values, and matches against each one individually. If you replace it with =, as in td[direction="apples and oranges"] then the CSS-style will only apply to that explicit attribute tag, for example if you need to perform some special trickery on some combinations of your custom attributes.

A minimal example of the effect.

...you will all have to add

googlewolfwings to your friends list. I don't believe I'm going to post directly to LJ again because I have almost never except for experimentation posted to LJ with anything but the web-interface, and their new web-interface severely breaks my workflow.

shatterstripes? I know what you were talking about with what Flash did every version or so now, though admitedly to a lesser extent.

Everyone else? Come, join me. Let's show LJ we mean business. Mass exodus to Google! Who needs invites? :-)

Current Mood: pissed off

So I decided to take the plunge into GooglePages, now that I'm done treble-verifying, proof-reading, and testing the code I've been working on for a week or so.

Easy2Port Code Repository, v0.1

The arithmetic/range coding code ends up being under 20k total, in four distinct modules and a ported example compressor/decompressor included. None of the modules (one .c and one .h file each) know anything about the internal workings of each other, and are fully 'black boxed' though the statistical heap module does have a calling convention specifically for range coding. Everything passed the strictest syntax and other forms of automated checking I could put them through, and I believe all the code is simplified enough it should be easy to port to other languages.

Thoughts? Suggestions?

Edit: Now that I'm awake, working with the GooglePages editor a bit more. My server's up, but I'm actually starting to like GP's interface a lot. It's certainly convenient. =o.O=

Stuck up in San Jose because there's nowhere for me to sleep at my grandmother's this week, or possibly next week either. I'll find out this weekend what's up.

On the coding front, I'm almost done re-writing (since I can't really call it a conversion anymore, it's a full re-write from base math/concepts now) the bijective Arithmetic encoder in straight C.

( Before & after in here. )

I've realized one other nice trick that comes as a side-effect of Bijective compression. The routines, when properly written, by their very definition do not require 'end of file' markers, or anything except X markers for X symbols in an alphabet. I.E. If you don't have an explicit 'end of file' marker, and have to be able to have decompress(compress(file)) always return the same results as compress(decompress(file)) then you can't have things like file-length or original file-name tags inside the resulting files either. They are truly self-contained, opaque, compressed blocks of raw data. This makes them great for encapsulating in other formats, though it also makes them incredibly fragile because if any bits get changed the entire morass goes splat.

On a side-note, I've started looking into adding this compression to the Quake 3 networking protocol. This led me into looking up better methods of compressing floating-point numbers, and a rather straight-forward observation: IEEE floating-point numbers are not formatted in a way that's good to compress, but it is is a format that's easy to do comparison operations on. Amusingly, some simple bit-shuffling makes the numbers a lot more compressible byte-wise. Long story short, glue the sign bit onto the top of the Mantissa, and deal with the Exponent separately since it's already an 8-bit number. I'm sure that's in some publication out there somewhere, but I only had reason to figure it out for myself tonight for the first time ever.

The only complication will be the sheer quantity of encoder-heaps I'll have to track if I want to support ongoing heaps (the core bit of math-fu in the arithmetic encoder) between server frames instead of only one-shots for each frame. Each heap takes up about 2k, and I think I'll need four heaps tracked ideally. (Floating-point Exponent, Floating-point Sign/Mantissa, 32/16-bit Integers, and Text) So, about 8k per client connection per frame of sync delay... so roughly 8k per client per 50ms of latency between them and the server, on average. Worst-case, about 10MB of memory used if a fully-loaded 64-player Quake3 server had all the players >999 ping. At that point I believe some kind of 'skip the delta, here the full state' mode would be better. More realistically, I'll probably allocate a fixed buffer of 'heaps' ahead of time, and if no more can be allocated it'll force a client to 'zero state' frames, and flush all their heaps back into the pool. Just means I'll have to allocate one of the 'reserved' bits to flag a frame as 'heap based on delta-from frame' or 'heap based on zero' but that's pretty minor.

...I hate C++. Without automated tools, there's no way to guarantee, without a doubt, that the code does what it looks like it does. Even standard assumptions can be over-ridden, and far too often are in example C++ code to make the code make 'more sense' to the original coder. But in the process making it vastly harder to parse and understand to a layman trying to port the code elsewhere.

Currently picking through Matt Timmermans Bijective Arithmetic/Range Coding Compressor and (very slowly) shambling through converting it to straight C instead of a heap of C++ files for some very simple code bits of code.

And yes, this ties in vaguely to my old WikiCode idea. And no, my usual complaints about C++ don't all apply to the linked-to code, but are a complaint with the basic design of the language.

No Nonsense Self Defense

( Regarding the update-page changes. )

Chances of it making a difference immediately? Not much. Chances of it reinforcing the grassroots bitchfest that will hopefully revert this poorly-designed, pixel-fonted change? Really damn good I hope.

Current Mood: angry

...but it works so well.

If I get sniffly, I immediately run for an entire canister of frozen OJ concentrate and have it like sherbert.

I realized last night why I feel so wretched that evening, and why it works so well the next morning.

It throws my body's pH way the hell to one side, then lets it renormalize. So the bug barely catching hold suddenly finds itself in the Sahara, then back in the Florida Swamp, and it curls up and cries mommy. =^.^=

Yay for having a cast-iron gut.

Just made some couscous, forgot how trivial it is to make, and how fun it can be to have. =^.^= Boil a cup of water with a little olive oil in it (debatable if it takes longer in the microwave or on the stove... so little water just heats up instantly) then dump it in a cup of couscous in a bowl, swirl the bowl, set the pot on top of the bowl for a couple minutes, eat with a fork.

On a side-note... I've determined what makes some pages and images flat-out stall when loading them.

In laymans terms, if you have a LOT of RAM (say over 256MB) and run a recent version of Linux, you'll have some servers that magically stall when loading images from, for example. Reloading will cause more of the image to load usually, etc, etc.

The core problem is that newer versions of Linux don't limit the upper size they'll use for TCP buffers to a static value from the days of computers having 4MB of memory. It limits the value based on 1/128th of your usable system memory now, up to 4MB. This is in the internet standards, and has been for 12 years. So what breaks it? Most firewalls don't track the entire TCP connection, and the part often dropped is the part that negotiates the total size of the buffers to be allowed to use. In laymans terms... the firewall expects box #1 to be filled, but the two computers told each other to use boxes #1-#16. So the firewall never checks boxes #2-#16 for data to pass along to the other two computers... and the other two computers keep waiting to hear about mail in boxes #2-#16 to be able to assemble the network traffic properly.

For the geeks: The technical term is TCP Window Scaling, and it happens when a firewall tries to track SYN packets statelessly while still tracking TCP connections statefully. To disable it under Linux, add the following to /etc/sysctl.conf:

net.ipv4.tcp_window_scaling = 0

YUM! goes the engine for the Jeep and Escort.

Or at least they will in about a week when the $145 worth of oil and filters shows up.

Yes, $145, for two cars. 6 quarts (rather, 1 gallon + 2 quarts) each. Admitedly, $30 of that is the discount store membership, shipping, and sales tax, so it ends up being around $7.50/quart for the oil, and around $15 per oil filter.

But the oil and filter'll last around 17½-25k miles. So even with how much I drive that's over a year. :-)

If anyone on my friends list wants their oil changed, I can order another... well, if anyone wants to order oil or filters for their vehicles from Amsoil, I get the dealership prices. So lemme know!

Vehicle Lookup for Amsoil products

...but readable code is so much more usable.

I've always been a fan of data-compression and encryption technologies, or as I think of them and numerous related areas, data-transformation systems since (for Lossless compression and encryption, the only thing I've had much interest in) that's all they really are is transformations.

Lately I've been most interested in a surprisingly little-researched area, namely the compression of hundreds or thousands of very small items, typically each less than a hundred bytes. This has obvious applications in on-line gaming, and for example to compress values in a large database of keys in the case of MU*'s such as Fuzzball.

Far too much research has been written on absolute compression ratios, but a LOT of those techniques actually decrease the compression-ratio on very small files because of the 'warm up' time before the techniques really shine. Very much akin to optimizing a vehicle for stop-and-go versus highway driving.

I've been stepping through a couple of various compression technologies, namely Dynamic Vitter Huffman compression lately, and ran across something I found useful and interesting. Namely a Bijective version Huffman compression. This has a very unique trait, namely that any bitstream is valid. Meaning this is very useful for things such as gaming traffic because you can always safely call the decompress routine on a packet of data regardless of content and it will transform without error.

And this led me to downloading the code, and trying to understand it. I... don't believe I've ever seen such horribly-mangled code before in my life, not even in horribly Pascal/x86 Assembler mashups from my demo-coding tutorial-reading days.

And this is leading me to rewrite the entire block of code, but while I was doing that I realized... I really don't know of any good repository to 'publish' example source code for things like Huffman Compression, or Range Coding. Google can find examples, but there's no single site to post Wiki-editable or even just commentable code chunks that can be used directly but are meant to be illustrative and readable more than fast or efficient.

Anyone think setting up such a site would actually be useful? Something half-way between Wikipedia, MathWorld, and SourceForge meant more for discussion and community editing of a single file of self-contained source code, but very heavilly biased towards functional source code that's easy to port (for example favoring straight C over C++ or C#, and Assembly being unwelcome) and not just commentary and mathematical equations.

What would you say if I told you that simply changing from 'plain' nails to well-engineered, super-modern design nails of the same physical size and able to be used in existing nailguns would single-handedly triple the strength of a wooden structure, so that the type and strength of wood becomes the limiting factor?

Behold the HurriQuake 2 nail.

This makes nails comperable to bolts and screws for useful holding strength in wooden structures. =^.^= Note it doesn't have the absolute gripping of Bolts, obviously, but it tends to make the strength of the wood the failure point, not the nail failing. :-)

( Oh, forget it! )

Current Mood: working

( ...I immediately feel terrified. )

I may have to poke at RIITS now that I tracked down they are the ones that actually act as the 'clearing house' for the Los Angeles traffic congestion information network.

I'm just awfully sure I can make a system that blows SigAlert out of the water for a specific use, being able to be accessed by cell-phone to get near-realtime updates on a planned route and alternates.

...free Loot always helps.
...Physics sucks.

...I thought to poke around Revetec again, see about any new tidbits on the site, and they've done the math to make something even niftier.

This is an engine design that shows the true power of getting away from the crankshaft-based systems that prevent multiple overlapping centerlines for the pistons without sacrificing reliability. Initially meant to be in a 2.4l system, I'm staring at that and drooling. Though it's easier to see how things work if you manually slideshow through the frames. They estimate the core longblock will be around 160mm (<7in) deep. Sure, piping will add to that a bit, but the core engine being thinner than most one-use compact spare tires used on cars today. Just amazing.

...but it looks like Arlington, Virginia is single-handedly handing Virginia to the Democrats. Nowhere else in all of Virginia has anywhere near that lopsided a ratio.

...I have voted.

Mostly NOT for people, but for things.

No on everything except 1A (lock all gas taxes to road-use only with a repeatable-every-X-time-units exception) and 87 (punt another few cents tax on gas) myself.

I specifically voted no on the 'almost three dollars a pack' tobacco tax, because that will more than double the cost of smokes. That's too large a tax-hike all at once, IMHO. Raise it, sure, but don't just sneak in and more than double the price.

A single undetectably tampered memory card.

Finally updating here again...

Until LJ corrects this god-forsaken update.bml...

Well... I can't reach my own web server.

Slowly rummaging through the code everywhere...

Grr...

Interesting website...

My comment to lj_design

Man that treatment is hell...

Yum!

OwOwOwOw goes the MasterCard.

Code can be useful...

Yanked from /. but worth spreading around.

I'm gettin' all worked up.

Every time I look as job postings...

Hrm... interesting.

Two rules that apply to all video-games...

Oh my...

Vaguely fitting...

Over 350 miles and 6 hours of driving later...

So what does it take to steal an election?

Style Credit

Profile