16 Jul 2006

winterkoninkje: shadowcrane (clean) (Default)

Just a small collections of things... Today I went to Geek Fair, had a decent time, got to walk around and talk with Z-san afterwards and found an old fountain I'd mislaid.

A few days back I had a most excellent beer. Now I'm not much of one for beer in general, though I can certainly respect a good one. There's this beer down at the grocery store I'd thought looked interesting for a while, but the price always seemed a bit too high for me. Last time I went shopping it was on sale, not much of a sale — one dollar off is all — but enough to bring it within cost for trying, and so I got the four pack. I had one not so long ago and oh man it was tasty, a good thick dark beer. A bit pricey for something to drink regularly but Old Rasputin Russian Imperial Stout is well worth the cost when you just want to sit down with a top of the line drink and enjoy life.

Work has been interesting. I'll be starting up some rambling about LDAP over on my f/oss blog this week to document my travails. That is afterall what the f/oss blog is for, much as it is frequently defunct.

Courtesy of nekketsu I've fallen madly for YUKI, a former member of JAM. Her videos are utterly bizarre. And gorgeous. And her voice is so unique and lovely. I'll have to see if I can't get my hands on some cds by her. Some choice PVs are: JOY (Live), メランコリニスタ, End of Shite (some surreality may not be work safe), ふがいないや, ドラマチック, ヘローグッバイ, 長い夢, スタンドアップ!シスター, 喜びの種, Home Sweet Home. ::sigh::

In searching around for Yuki I also discovered Lolita23q (少女ーロリヰター23区). Ah sweet sweet visual kei. This too I must come to possess. Siren Blue, 888 ~Kohaku tou no Shoujo~, Usagi ni Geru Hanazono, Ishoku Othello. (Hey Pretty. Fan tribute, different band does the song.)

And if you're still not convinced yet this is part of why I love Japanese. And this. And this. And this. And this.

In other news [livejournal.com profile] theweaselking wins at the internet. That had me cackling for an hour at least. And if that's not enough this only makes it better. ::chortle::

winterkoninkje: shadowcrane (clean) (Default)

So here's another crazy idea I have for Eng. When writing code, particularly at a low level, there's frequently call for doing basic sanity checks. That is, you often see code like this if ($foo == nil) { omg die! } elsif ($foo->bar()) { blah blah; } scattered liberally around everywhere. And especially with method calls when you got your object from some potentially unreliable source you see if ($foo and $foo->bar()) all over. Wouldn't it be nice if we could abstract that away?

I've had a few different ideas in the general area of different semantics of "return values" — for example you have different senses of "return value" when you're talking about the evaluation of a function/method/operator, the error code for failed evaluation, and returning "this" object so you can chain method calls together — but I recently had an idea that might be easier to implement in a similar field: we could do sanity checking with a special postfix operator ?. You would use it like $foo?->bar() and it would have short-circuit semantics so that if $foo passes the sanity check it behaves like a no-op, but if $foo fails sanity checking then it will skip evaluating bar() because trying to evaluate it will probably explode, what with $foo not being sane and all. In case there are different types of unsanity it would also be helpful to have some special variable ( $? perhaps) that stores the type of unsanity, or have perhaps some other way to deal with unsanity handling.

The challenge is where exactly to short-circuit to. If we have a statement that's a chain of method or field calls like $foo->bar()->baz->bif()->zorch()->quux; then it makes sense, wherever the ? is, to skip everything from there to the end of the chain/statement. But in other circumstances things get more complicated.

For instance, what do we do if it's in a conditional statement? If it's just a basic conditional statement like if ($foo?) or if ($foo?->bar) then it would make sense to have the whole statement return false. But if it's in a compound conditional statement like if ($foo?->bar() or $zorch->bazzle()) then it would make sense to skip the call to bar(), fail the first subexpression, and so evaluate the second. We could say that in boolean contexts the expression returns false, but that is contingent on what we mean by "expression" here.

Another example of complexity is how it interacts with non-method calls, such as arithmetic expressions. If we have $foo?->numeric() + 5 and $foo isn't sane, then what should the expression return? Well maybe the whole greater expression should fail (i.e. be skipped), that sounds sensible. Now what happens in non-algebraic expressions, like assignment? Should $foo = $bar?->baz() skip the assignment too, or should it set $foo to a known-bad value like nil? In case that question seems too straight forward, compare it against foo($bar?->baz(), $bif); should we call foo() with a known-bad value, or should we short-circuit out of ever calling foo()? Also, since ? is intended to simplify code, we must expect that callers won't necessarily test $? unless they really care about why ? failed.

A brief digression into implementation details. When calling ? we obviously need to pass it the thing we're testing. But at an assembly level, in order to know where to short-circuit to we also need to pass a label to jump back to. If during the course of evaluating sanity we determine the object's not sane, we can't just do a normal return because that wouldn't give us the short-circuit semantics we desire. The easiest way to get our short-circuiting would be to overwrite the memory location that stores the return address with the label we wish to jump to, and then when we return we'll return to somewhere else. In the event that some architectures disallow overwriting the return address, we'll have to manually pop a stack frame and do an unconditional jump, or use an inline function instead of a real function call, or devise some other method. If we allow operator overloading, overloading ? will have to be treated specially since we're not using a normal return.

Back to semantics. So far, I can identify six contexts that to be specified: method chains, boolean expressions, arithmetic expressions, string expressions, function calls, and assignment. And two general approaches: returning nil/false/zero/lambda or skipping evaluation. Since the whole point of this sanity checking operator is to avoid Doing Bad Things(tm) I'm thinking that we should err on the side of skipping evaluation, but there are certain places where just jumping to the next statement is jumping further than we may like. Inside conditional expressions — particularly disjunctions — is the big one, but also boolean expressions used as shorthand for control flow (like Perl's famous open($fh, ">", $file) or die "omg!";). Perhaps when the ? is buried in a boolean context it will skip the rest of evaluation for that whole subexpression and return false to the boolean operator, but in all other situations it just skips to the next statement. That sounds like a sensible enough place to start for Doing The Right Thing.

winterkoninkje: shadowcrane (clean) (Default)

So at work they have me switching over the network from NIS to LDAP for a network of a couple hundred machines on a mixed network of Solaris10 and linux (Ubuntu). Now, the basic idea of LDAP is pretty easy and there are a number of books that'll teach it to you like O'Reilly's take on the subject. Unfortunately once you get past the basic introduction to what it is, the documentation peters out.

Documentation is important. In fact that's the very First Law of Language Design: a language is only as good as its documentation. The documentation for LDAP is like the documentation for an extremely proprietary product intended only for use by governments and very large corporations. First of all there's very little of it. Secondly what documentation there is goes into excruciating and technical detail of very specific and often esoteric facets of the product, but makes no attempt whatsoever to answer basic questions nor mention how one is to actually use it. Thirdly, what brief discussions there are of how to do half of a basic task only discuss a different model (openldap) than the one we're using, which is of course incompatible with ours (SunONE DS5.2).

Back when I started this blog I started it with the hopes of collecting my thoughts and experiences as I navigate the world of IT and F/OSS in particular. While oft I've been defunct at doing so, I think for this project especially it's important to keep a log of my discoveries so that others in my position may learn from my tribulations. And now, onward to the first colossi to be slain.


Setup. ) Configuring Clients. ) Loading Schema. ) Autofs. )

June 2017

18192021 222324


Page generated 20 Sep 2017 03:45 am
Powered by Dreamwidth Studios