About TODO Blog RSS Old blog Projects Gallery Notes

Tue, 05 Feb 2008

Selecting computer language for the new project.

assert youKnowWhatYouReallyWant == true;
if (iAmWritingForPersonalUseOnly()) {
    if (iWantAReallyNewParadigm()) { // actually you'll get some irreversible brain damage.
        try {
            return "Huskell"; // dude, I really mean the DAMAGE!
        } catch(ECriticalBrainFailure e) {
            if (preferDotNetWorld()){
                return "F#"; // it's the same as Gb, ain't it?
            } else if (processorCount() >= OH_SO_MANY) {
                return "Erlang"; // start thinking in 1000 threads
            } else if (preferPunctuation() == STRONGLY){
                try {
                    return "J"; // APL needed a transliteration -- and got it
                } catch (EBrainOverolad e) {
                    return "K"; // better have a bank hire you soon!
                }
            } else {
                throw new RethinkParadigmException();
                // you should have better selected Haskeel before
            }
        }
    } else {
        if (isDynamicTypingOk()) { // hey, everyone wanna be a cool geek today.
            if (cannotLiveWithoutCurlyBraces()) { // well, who can ?!
                return "Ruby"; // it's Python done better.
            } else if (enjoyIndentation()){
                return "Python"; // it's Ruby done right.
            } else if (shizophrenia->isOK()){
                return "Perl"; // all the expressivenes and imprecision of a human language.
            } else if (sourceCodeConceptIsObsolete()){
                return "Smalltalk"; // ever modified the value of True -- on a live system?
            } else {
                throw new LameException("PHP5"); // stick with this, los^W poor dude
            }

        } else { // static typing obviously
            if (isManagedOk()) { // let PC do some job for me, they are so smart nowdays.
	    			 //Sick of doing everything myself.
                if (preferJavaWorld()) { // die, MS, die!!!
                    return "Scala"; // huge, really huge. Must be inspired by Noah Arc.
                } else if (preferDotNetWorld()) { // stuck on Windows, ha?
                    return "Nemerle"; // kazalos' by... oh, not again...
                } else {
                    throw new IsThereReallyAnythingElseException();
                }
	    
	    // computers will eliminate the humankind if they get enough control.
            } else if (unmanagedOnly()) {
                return "D"; // get a whole new language with every new release. Great fun.
            } else {
                throw new YouWantSomethingStrangeHereException();
            }
        }
    }
} else {
    return "Do Whatever Your Boss Says To And Keep Your Mouth Shut Programming Language";
}

/devel/other :: Link / Comments (6)

POHMELFS inode generation and cache coherency.

I think I've just designed the way to fix the problem with overlapping inodes on different clients or server and clients.

Here is short problem description: when client locally creates some object, it has to assign unique number to its inode and put it into global hash tables. With local cache and maximum performance (or when client is offline) it shold not connect to server and perform create operation at all, instead it should pick some number for inode and work with it.
Problem is that number of clients can have the same inode number for different inodes and have actually the same object but with different inode number on different client's machine.
When clients and server will have to sync its states problem rises: server does not know about inode with client's number and thus sync can not happen.

Solution is quite simple imo, which solves both cache coherency problem and inode number one.
Clients use any numbers they like: for example sequential increase from zero. When new object is created its parent is marked as dirty by client (if it is already marked as dirty by other clien, it is forced to push its changes to the server, which then will be forwarded to the new client), and client uses own inode numbering scheme. When later there is a need for resync (lile forced writeback or above case of cache coherency synchronization), client sends inode content to the server with both name and local inode number. Server then creates an object and assigns real unique inode number to it, which is then returned back to client. Client removes inode with old (local) number from hash and inserts it back with different inode number. That's all.

Simple. And allows to work with any filesystem on the server side because system uses both object name and object id (inode number) as identificators during creation time.

So far I do not see any drawbacks in this approach, but practice will show if it is correct design or not. Stay tuned.

/devel/fs :: Link / Comments (0)