[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] A plan: Geek Clang
- To: Antti-Juhani Kaijanaho <gaia@xxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] A plan: Geek Clang
- From: Tuomas Lukka <lukka@xxxxxxxxxxx>
- Date: Mon, 14 Aug 2000 13:22:58 +0300 (EETDST)
- Cc: ZZ Development <zzdev@xxxxxxxxxx>
- In-reply-to: <20000814104200.A30713@xxxxxxxxxxx>
Could you call me (050-3647147)ld you call me? We're going to meet Ted at
2:30pm, you can come with us.
> > Everything: what about the primitive cells, and their joinage with Java?
> > Simply put them on a rank, nameless again, and
>
> Is there a way to make the "magic connection" between a cell and a Java
> callback persistent, without resorting to an associated string that
> magically binds them together; since if all primitives are cell clones,
> I would not want to have the meaning of all programs to change (or worse:
> the programs themselves to become broken) when somebody edits the texts
> that binds the cells to the callbacks.
>
> I can easily make that binding in a new space (eg. hash the cell object
> or cell id and the callback in a Java Hashtable), but it'd have to
> be persistent.
The best bet is to define a clear route, e.g. d.thales-ops rank from the
homecell of the space. The homecell and the permascroll are the only
things that are persistent.
> > - need a good mechanism for specifying which language a script is in
>
> My current idea is to use a namespace-like mechanism for the Greek Clang
> "magic dimensions", so that for example we'd have a d.thales-argument,
> d.thales-sequence etc. But is this enough?
Orthogonal: the systemneeds to know what to do when a cell is given to it
for execution. Looking through all the possible languages is not good.
Something like d.script-language or something from the root clone?
> Hmm, automatic cell management: which is more efficient in terms of space:
> when a cell representing an intermediate result is provably unnecessary,
> just leave it at deleting all its (relevant) connections, or should I
> also delete the cell itself? If latter, some of the languages will need
> an automatic cell management routine, a kind of garbage collector.
Thosetwo options are currently the same. We need a garbage collector at
some point but its interaction with history is going to be ...
interesting. Versioning affects MANY things.
Tuomas