I recently learned there is javascript beyond browser web page, and
that there's actually a language. The language has some interesting
properties. It has a default library of stuff that's fairly
functional (from a network communcations sort of perspective; could
wish they had their own websock which is a few hundred lines of code
but I digress)
What I was thinking is part distributed database.
The branches may be saved on a disk, may be temporary in memory, each
A revision id. has a history of authority in a sense... But; it may
exist as a revision packet in a branch that is on a full duplex
datagram pipe and then be removed from the system.
But distributing the appriprate revision links respinsible for that
node would be able to transfer authentication to the remote...
Monotone did do one thing very right ( keep the files as they are and
never ask if you should be one way some place or another; though maybe
a forum of scripts for user contribution 'oh ya, I *DO* want that'
which I saw at the time. (git recemtly changed policy settings, and
the default is wrong).
But no, monotone exists as an entity tracking thing. If I modify a
content, it may store that change in addtion to the current revision.
If this were say a shopping list, then it would be least storage? And
I could always get a foreach() operator that's a snapshot of all... or
I could get single things in the list...
....
And it struck me that as a global object tracking system, could make
self-discovering-self-loading nodes with small bits of storage that is
a private db, a shared db, could be files... (the vfs is on the side
of the sqlite side really also ... wasn't really thinking of vfs on
the front-end? But sure, because I have this disk that I want to feed
it?
-----
Douglas Crockford wrote a book 'javascript - the good parts' he gave
a talk at many places where he covered to roots of what is good stuff.
And you can get by without ever using a single new :) because { a:
"is object" }.
and json is really kinda slick, and as expressive as xml... and
javascript is not going away.
There is the Atom/Electorn platform that Github is producing/hosting,
electorn is chromium-content wrapped in a thin javascript loader.
There are inconsistanies when you get to the DOM layer... but did you
know Encscriptem can compile source to javascipt by bytecode?
And I think sqlite is fabulous, and probably better now than it was...
and it's sad that it was said to be slow once upon a time (some
youtube video I saw with linus torvalds speaking of other experiences
at the time)
But ... if I could
var thing = require( "mtn://org.d3x0r.sack/src/" ); might be kinda slick...
node does have addon support; but... I think a general
reimplementation of the core just for kicks might be entertaining :)
which unfortunatly is off-sight... but I dunno coordiante some pull in
the back end, which would require knowing a directory of where things
were and why you might want to know they were there?
I saw a google V8 tech presnetaiton about things they do to speed it
up... and if code executes a certain way, deep inlining can be done,
which I suppose can be done by a optimizing comipler;... but it
doesn't KNOW that 'this exception handler will never execute' but you
can learn that.
I was on a youtube kick for a week learning the 5 hours crockford had
to teach; and it's not what you will find if you search for common
answers.
The other issue is that there's jquery that uses a magic variable $
everywhere, and they mean things with it.. another uses _ as a
variable so _.thing is what you want to get....
BUT you don't have to live in that world... node itself is a simple
binary to grab and tinker with, electron has a little complex startup
but it's managable...
(sorry for all the bad spellings)
On Tue, Mar 1, 2016 at 3:20 PM, Hendrik Boom <hend...@topoi.pooq.com> wrote:
> On Tue, Mar 01, 2016 at 07:27:51PM +0100, Markus Wanner wrote:
>>
>> (I personally find it hard to believe that JIT can generally be faster
>> than ahead of time compilation, but...)
>
> It can be faster if you only want to run a small part of the program.
>
> It can be faster if the intermediate code is so compact that compiling
> it to machine code saves disk reading time.
>
> It can be faster if at run time you discover what types are really used
> in an otherwise statically untyped program.
>
> But I can't see it being much faster for the kinds of languages I prefer
> to use.
>
> -- hendrik
>
> _______________________________________________
> Monotone-devel mailing list
> Monotone-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/monotone-devel
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
