javascript monotone

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

javascript monotone

J Decker
I don't know how to phrase this.
This is meant for the architect of the innermost guts of monotone...
strip away a database, strip away a file system, and just track
revisions.  track merging of chains....

I read somewhere that in the distribution of monotone revision chunks
that there are conglomerated chunks of revision that get sent and can
later be referenced with a key(?) Maybe that's where the failure is...
Sorry I've been imagining monotone doing a different job than source
control, like ledger transactions for bank accounts.  And to share
those.  The chains of transactions are verifiable, and I guess that's
what bitcoin is kinda built on.

I'd like a system for sharing ID's between nodes in a cluster....
where IDs are added, sometimes transfer, sometimes don't, those
clusters exist as a memory idea somewhere in monotone at some point?
Even if for optimization it is cursor driven so you can only see a
portion of it at a time.

and something entirely without boost.

Can that be written and shared as a NPM module for node? :)   I hear
that v8 does extra clever things that allow it to more deeply optimize
than a static compile does... it could; but it doesn't.

- Or -
I'd like a VFS interface (virtual file system) interface to monotone
so I can load a place to store the database?  Could just use my
existing sqlite interface with a small hack I suppose... but you
probably leverage more than I do (which is almost sufficient to look
like ODBC's retarded stepcousin )

I dunno maybe it's not so hard?

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: javascript monotone

Markus Wanner-2
Hi,

On 03/01/2016 10:16 AM, J Decker wrote:
> This is meant for the architect of the innermost guts of monotone...
> strip away a database, strip away a file system, and just track
> revisions.  track merging of chains....

Huh? What for? And what's your persistence layer, if you strip those?

> I read somewhere that in the distribution of monotone revision chunks
> that there are conglomerated chunks of revision that get sent and can
> later be referenced with a key(?)

A revision id.

> Maybe that's where the failure is...
> Sorry I've been imagining monotone doing a different job than source
> control, like ledger transactions for bank accounts.  And to share
> those.  The chains of transactions are verifiable, and I guess that's
> what bitcoin is kinda built on.

Yeah, Monotone and Bitcoin certainly share the concept of a
monotonically growing tree. However, Bitcoin doesn't have any kind of
merge functionality and Monotone doesn't need Prove of Work...

> I'd like a system for sharing ID's between nodes in a cluster....
> where IDs are added, sometimes transfer, sometimes don't, those
> clusters exist as a memory idea somewhere in monotone at some point?
> Even if for optimization it is cursor driven so you can only see a
> portion of it at a time.

Cassandra? Tahoe-LAFS? There are many projects with somewhat similar use
cases. I didn't fully (nor partially) understand your use case.

> and something entirely without boost.

Implementation detail.

> Can that be written and shared as a NPM module for node? :)   I hear
> that v8 does extra clever things that allow it to more deeply optimize
> than a static compile does... it could; but it doesn't.

Hearsay. And implementation detail.

(I personally find it hard to believe that JIT can generally be faster
than ahead of time compilation, but...)

> I'd like a VFS interface (virtual file system) interface to monotone
> so I can load a place to store the database?

I thought about that as well. Just out of curiosity: Why would you want
that? And what's the important difference to an ordinary checkout (maybe
to a tmpfs)?

> I dunno maybe it's not so hard?

Given I don't even partly grasp what you're trying to accomplish, it's
hard to say...

Kind Regards

Markus Wanner


_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: javascript monotone

Hendrik Boom-2
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel
Reply | Threaded
Open this post in threaded view
|

Re: javascript monotone

J Decker
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 <[hidden email]> 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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/monotone-devel

_______________________________________________
Monotone-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/monotone-devel