External representation for continuations

Hello,

I've come across a paper about Kali Scheme and so I started wondering 
whether it would be possible to create a sensible external 
representation of continuations / threads in CHICKEN -- something you 
could transmit over a network channel and use at the other side, at 
least if the other side was running the same Scheme program.

Any good ideas are welcome!

cu,
Thomas

Re: External representation for continuations

Thomas Chust wrote:
> Hello,
> 
> I've come across a paper about Kali Scheme and so I started wondering 
> whether it would be possible to create a sensible external 
> representation of continuations / threads in CHICKEN -- something you 
> could transmit over a network channel and use at the other side, at 
> least if the other side was running the same Scheme program.
> 
> Any good ideas are welcome!

Basically everything is possible... 

I pondered about this quite a bit. Basic serialization of data is not
a big problem, but code is somewhat tricky. A closure (or continuation)
contains a code-pointer to some C routine. To properly serialize a closure,
the code-pointer would have to be converted into some unique id, which,
when deserialized back into a running process must be converted into
a code-pointer again (we can't just write the code-pointer directly:
in a process that deserializes a closure, the code-addresses may be at
completely different locations, or might even not be available, for
example if a library is not linked, which was used and referenced in
a serialized continuation/closure).

One possible solution would be to generate a function-table for each
compiled file that maps code-pointers to unique identifiers). On serialization
a code-pointer would be looked up in that table, the id written and on
deserialization the id is searched in all loaded/linked units/modules
and converted back into a code-pointer.

Re: External representation for continuations

Felix Winkelmann wrote:
> [...]
> 
> Basically everything is possible... 
> 
> I pondered about this quite a bit. Basic serialization of data is not
> a big problem, but code is somewhat tricky. A closure (or continuation)
> contains a code-pointer to some C routine. To properly serialize a closure,
> the code-pointer would have to be converted into some unique id, which,
> when deserialized back into a running process must be converted into
> a code-pointer again (we can't just write the code-pointer directly:
> in a process that deserializes a closure, the code-addresses may be at
> completely different locations, or might even not be available, for
> example if a library is not linked, which was used and referenced in
> a serialized continuation/closure).
> 
> One possible solution would be to generate a function-table for each
> compiled file that maps code-pointers to unique identifiers). On 
> serialization
> a code-pointer would be looked up in that table, the id written and on
> deserialization the id is searched in all loaded/linked units/modules
> and converted back into a code-pointer.

Information like that already exists in every file compiled with 
debugging information, so perhaps one would be able to access it without 
too much trouble. The bigger problem will probably be the serialization 
of code that is dynamically loaded or generated at runtime, because it 
also requires transmission of the code itself, not only of an identifier.

> 

Re: status of chickenlib: build process and mysql interface usage sample

Jörg F. Wittenberger wrote:
| On Tue, 2004-08-31 at 07:55, gian paolo ciceri wrote:
|
|>2. I'm particulary interested in the mysql interface:
|>any kind soul out there that can share with me a
|>sample of usage ?
|
|
| I'm attaching some code I wrote for the Askemos.org port to chicken.
|

Thanks Joerg for your feedback,
but it seems to me the file in attachment is the
mysql interface itself, while I need a little sample
how to use it, say a connect, a select query, and insert/update
query and a disconnect.

Thanks again for your patience,
have a nice day.

/gp

| Beware: it has been a long time since I wrote it and I did not yet
| complete the whole port -> no promises that it works at all.  I just
| hope it might help you.
|
| regards
|
| /Jörg

Re: status of chickenlib: build process and mysql interface usage sample

gian paolo ciceri writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1

the technical director of the famous azienda at Milan 
writing financial software based on opensource components
where I once applied unsuccessfully? So scheme is seen now
suited for that sort of tasks and may compete with python?

 > 
 > Jörg F. Wittenberger wrote:
 > | On Tue, 2004-08-31 at 07:55, gian paolo ciceri wrote:
 > |
 > |>2. I'm particulary interested in the mysql interface:
 > |>any kind soul out there that can share with me a
 > |>sample of usage ?
 > |
 > |
 > | I'm attaching some code I wrote for the Askemos.org port to chicken.
 > |
 > 
 > Thanks Joerg for your feedback,
 > but it seems to me the file in attachment is the
 > mysql interface itself, while I need a little sample
 > how to use it, say a connect, a select query, and insert/update
 > query and a disconnect.
 > 
 > 

wopuld it be hard to provide a generalised sql interface on the lines

Re: status of chickenlib: build process and mysql interface usage sample

Jörg F. Wittenberger wrote:
|> > Thanks Joerg for your feedback,
|> > but it seems to me the file in attachment is the
|> > mysql interface itself, while I need a little sample
|> > how to use it, say a connect, a select query, and insert/update
|> > query and a disconnect.
|> >
|> >
|>
|>wopuld it be hard to provide a generalised sql interface on the lines
|>of Perl's DBI/DBD architecture?
|
|
| Well, it basically stems from such an idea.  I do have mysql and
| postgresql, sqllite is not hard, but the db2 implementation turned up,
| that the interface might be worth some minor reconsideration, since db2
| doesn't allow "seek"operations in the result set.  However it's not hard
| to modify.

mmmh., chickenlib has something following this schema (dbi/dbd),
for mysql and oracle - as eggs we've postgresql and sqlite that
don't follow this approach AFAIK.

Perhaps it's worth the effort to unify all of this attempts
in an unique common framework - and dbi/dbd could be the
right one (even if python db-api could be an alternative).

Felix, any suggestion for this ?

Re: status of chickenlib: build process and mysql interface usage sample

On Tue, 2004-08-31 at 07:55, gian paolo ciceri wrote:
> 2. I'm particulary interested in the mysql interface:
> any kind soul out there that can share with me a
> sample of usage ?

I'm attaching some code I wrote for the Askemos.org port to chicken.

Beware: it has been a long time since I wrote it and I did not yet
complete the whole port -> no promises that it works at all.  I just
hope it might help you.

regards

/Jörg

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: status of chickenlib: build process and mysql interface usage sample

> Thanks Joerg for your feedback,
> but it seems to me the file in attachment is the
> mysql interface itself, while I need a little sample
> how to use it, say a connect, a select query, and insert/update
> query and a disconnect.

I'm attaching the xsql[1] implementation of Askemos.  It takes a sql
statement and returns an xml row element per result row with
column-named children elements holding the result values.  Hope this
helps.

regards

/Jörg

[1] : http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/XSQL

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Re: status of chickenlib: build process and mysql interface usage sample

>  > Thanks Joerg for your feedback,
>  > but it seems to me the file in attachment is the
>  > mysql interface itself, while I need a little sample
>  > how to use it, say a connect, a select query, and insert/update
>  > query and a disconnect.
>  > 
>  > 
> 
> wopuld it be hard to provide a generalised sql interface on the lines
> of Perl's DBI/DBD architecture?

Well, it basically stems from such an idea.  I do have mysql and
postgresql, sqllite is not hard, but the db2 implementation turned up,
that the interface might be worth some minor reconsideration, since db2
doesn't allow "seek"operations in the result set.  However it's not hard
to modify.

> and is the existing interface pure scheme or based on libmysql?
> perl offers for some sql engines both pure perl and lib*sql-based
> drivers, the former allowing to write client codes running on engines 
> where the libraries aren't even available, the latter provide more speed.

pure lib*sql based.

> are there also gdbm interfaces available for chicken?

Re: status of chickenlib: build process and mysql interface usage sample

On Wed, 2004-09-01 at 15:05, gian paolo ciceri wrote:
> mmmh., chickenlib has something following this schema (dbi/dbd),
> for mysql and oracle - as eggs we've postgresql and sqlite that
> don't follow this approach AFAIK.
> 
> Perhaps it's worth the effort to unify all of this attempts
> in an unique common framework - and dbi/dbd could be the
> right one (even if python db-api could be an alternative).

I hardly have the time to look into that topic.  However I'd welcome a
unified inteface very much (if it's not too simple, like that one
http://groups.google.de/groups?q=oleg+scheme+database+group:comp.lang.scheme.*&hl=de&lr=&ie=UTF-8&group=comp.lang.scheme.*&selm=72nj6p%249n%241%40nnrp1.dejanews.com&rnum=1
which is great for one shot programms, but hardly suited for performance
sensitive apps).

But such an interface is not chicken only.  Maybe it#s worth to think of
a srfi? (As a srfi I'd welcome an implementation like Oleg's, based on a
command line tool.)

best regards

/Jörg