[Chicken-users] rails-like framework

Post by Toby Butzon
Anybody know of a Chicken-compatible Ruby on Rails workalike?
I know Ed Watkeys posted something about the URL mapping part, but is
there anything close to a full framework?

Not that I know of. There are some parts (Ed's code and the ajax egg for
example), but nothing even remotely comparable with Rails.

cheers,
felix

Brandon J. Van Every

2006-04-21 21:05:45 UTC

Post by felix winkelmann

Post by Toby Butzon
Anybody know of a Chicken-compatible Ruby on Rails workalike?
I know Ed Watkeys posted something about the URL mapping part, but is
there anything close to a full framework?

Not that I know of. There are some parts (Ed's code and the ajax egg for
example), but nothing even remotely comparable with Rails.

Yeah... things like Rails are community / investment phenomena. Success
breeds success. If you want Rails, go use Rails. The Lisp world has
some mature web relevant things, but I'm not up on 'em. Inquire in
comp.lang.lisp.

I'm afraid my own Chicken projects are getting the backburner right
now. Technical stuff is just too much work when I'm spending a lot of
time signature gathering. The season ends in early July and if I don't
travel to another state to do more work, then I'll have more time for
Chicken. This kind of problem of critical mass, and application
interest, is why Ruby has Rails and Chicken doesn't.

Cheers,
Brandon Van Every

Peter Bex

2006-04-22 11:13:51 UTC

I'm afraid my own Chicken projects are getting the backburner right
now. Technical stuff is just too much work when I'm spending a lot of
time signature gathering. The season ends in early July and if I
don't travel to another state to do more work, then I'll have more
time for Chicken. This kind of problem of critical mass, and
application interest, is why Ruby has Rails and Chicken doesn't.

If I recall correctly, Rails was initially done by one person/small team
for a website. Later the Rails stuff got separated from the project.

In essence, Rails isn't that much: it's a handy hack for building class
layouts from a database table description (ActiveRecord), some addon
libraries for the Time class and a framework that aids in implementing
the model/view/controller (data manipulation/presentation/logic)
separation. It also includes some stuff to do Ajax, but we already
have that in the Ajax egg. And some session support, but we can do
that easily, and even _better_ with continuations. See
(http://radio.weblogs.com/0102385/2004/04/03.html#a568) for some tasty
stuff. This could ideally be integrated in Spiffy.

I think the hardest thing will be the ActiveRecord-like support since
Scheme isn't especially object-oriented. The question is whether
that is really required. The most important aspect about Rails is that
it has decent defaults. You can just build a database and run Rake
to set up a Rails environment and you have a bare-bones interface to
the database out of the box. To do things, you need the very minimum
of custom code. This is the essence of what makes Rails so popular.
I'm not sure if this can be done as easily in a non-object-oriented
environment. Ruby makes it easy to automatically build objects from
information because it allows you to add members to existing classes.
I think with the Prometheus egg we could do something like this.

As you see, a lot of stuff is already there. It's just crying for
someone to put it all together.

I've been thinking about doing something like this myself since I am
involved in web programming for a company where we are using PHP (yuck!)
and Ruby. I'd *love* to have something like Rails in Chicken.
The reason I haven't done any work on it is, of course, I'm currently
too busy with some other things that just need to get done before I can
do anything fun like hacking Chicken :(

If anyone is interested: having a decent userfriendly Scheme CMS would
be *very* useful too :)

Regards,
Peter

--
http://www.student.ru.nl/peter.bex
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth

Peter Busser

2006-04-22 14:05:22 UTC

Hi!

Post by Peter Bex
Ajax egg. And some session support, but we can do
that easily, and even _better_ with continuations. See
(http://radio.weblogs.com/0102385/2004/04/03.html#a568) for some tasty
stuff. This could ideally be integrated in Spiffy.

IMHO it would be better to make it easy to integrate, but seperate from
Spiffy. There are people who do not want to or who cannot use Spiffy.
They would not benefit from such a framework.

For instance, in many companies, it is mandatory to use something like
Apache. It would be useful if this framework would work with the SCGI egg,
so it can be integrated with Apache through the mod-scgi module for Apache.

Post by Peter Bex
I've been thinking about doing something like this myself since I am
involved in web programming for a company where we are using PHP (yuck!)
and Ruby. I'd *love* to have something like Rails in Chicken.

I would love to have something like that too.

Post by Peter Bex
If anyone is interested: having a decent userfriendly Scheme CMS would
be *very* useful too :)

Agreed! I have been looking for something like that. IMHO it should consist
of building blocks, which can be glued together. This makes customisation
easier, because no size fits all.

Groetjes,
Peter.

Peter Bex

2006-04-22 14:19:22 UTC

Post by Peter Busser
Hi!

IMHO it would be better to make it easy to integrate, but seperate from
Spiffy. There are people who do not want to or who cannot use Spiffy.
They would not benefit from such a framework.
For instance, in many companies, it is mandatory to use something like
Apache. It would be useful if this framework would work with the SCGI egg,
so it can be integrated with Apache through the mod-scgi module for Apache.

I agree fully. This is the approach Rails takes too: It allows you to
choose from CGI or FCGI with an arbitrary webserver or Ruby Webrick for
quick 'n dirty testing. (Webrick isn't as scalable as "big" webservers
like Apache or Lighttpd and I imagine Spiffy is not much better)

Post by Peter Bex
If anyone is interested: having a decent userfriendly Scheme CMS would
be *very* useful too :)

Agreed! I have been looking for something like that. IMHO it should consist
of building blocks, which can be glued together. This makes customisation
easier, because no size fits all.

Yes, it should use plug-in components. That's what makes CMSes like
Joomla! (which is crap) so popular; if you want something you don't need
to code it, you just upload a component that presents the info. You only
need to tell the CMS with a template where you want the info and style
it optionally with CSS. (IMHO the template is perhaps not even necessary
since CSS is powerful enough to position things)

When I'm done with wrapping up all the stuff I still need to do I'll get
back to you, we could work together on this. Sounds like the interest
is there, but people just are too busy with other stuff.

Regards,
Peter

Shawn Rutledge

2006-04-22 17:15:26 UTC

Post by Peter Busser
For instance, in many companies, it is mandatory to use something like
Apache. It would be useful if this framework would work with the SCGI egg,
so it can be integrated with Apache through the mod-scgi module for Apache.

Has anybody benchmarked Apache vs. Spiffy? (Hopefully a compiled
spiffy to get the best results, and only static html for the test.)

Peter Busser

2006-04-22 17:30:22 UTC

Hi!

Has anybody benchmarked Apache vs. Spiffy? (Hopefully a compiled
spiffy to get the best results, and only static html for the test.)

Not me. But I bet that Apache is much faster than Spiffy with static
content, because I think it uses system specific optimisations like e.g.
sendfile(). Apache is likely to scale better too.

Groetjes,
Peter.

Alex Shinn

2006-04-23 05:29:01 UTC

Has anybody benchmarked Apache vs. Spiffy? (Hopefully a compiled
spiffy to get the best results, and only static html for the test.)

Not me. But I bet that Apache is much faster than Spiffy with static
content, because I think it uses system specific optimisations like e.g.
sendfile(). Apache is likely to scale better too.

What does "scale better" mean? Apache 1.x uses multi-processes, which
are severely limited, and Apache 2.x uses POSIX threads, which are
still very heavy compared to the lightweight threads Spiffy uses. In
this sense, Spiffy is closer to Yaws (http://yaws.hyber.org), a
webserver written in Erlang, and in the following benchmark Yaws is
shown to completely outscale Apache 2.0, handling over 80,000 requests
compared to Apache's 4000:

http://www.sics.se/~joe/apachevsyaws.html

For Ajax sites, small dynamic requests are the norm and this
scalability is essential.

--
Alex

P.S. sendfile(2) would be very easy to add to Spiffy for those
interested.

P.P.S. you can always use Spiffy along with Apache via mod_proxy and
mod_rewrite. synthcode.com runs on a Scheme webserver on the same
machine as several friends who all use Apache (and, sadly, rails).

Peter Busser

2006-04-23 09:08:33 UTC

Post by Alex Shinn

Has anybody benchmarked Apache vs. Spiffy? (Hopefully a compiled
spiffy to get the best results, and only static html for the test.)

Not me. But I bet that Apache is much faster than Spiffy with static
content, because I think it uses system specific optimisations like e.g.
sendfile(). Apache is likely to scale better too.

What does "scale better" mean?

It means that it won't slow down faster than the load increases.

Post by Alex Shinn
Apache 1.x uses multi-processes, which
are severely limited, and Apache 2.x uses POSIX threads, which are
still very heavy compared to the lightweight threads Spiffy uses.

Agreed. But threads are just one thing, there is more to a web server
than just threads.

Post by Alex Shinn
In
this sense, Spiffy is closer to Yaws (http://yaws.hyber.org), a
webserver written in Erlang, and in the following benchmark Yaws is
shown to completely outscale Apache 2.0, handling over 80,000 requests
http://www.sics.se/~joe/apachevsyaws.html

Sounds good, except that Yaws is not Spiffy and Erlang is not Chicken.
However, it would certainly be interesting to see the same benchmark performed
on Spiffy.

Post by Alex Shinn
For Ajax sites, small dynamic requests are the norm and this
scalability is essential.

Except that Ajax is not the kind of static HTML content Shawn was talking
about.

Post by Alex Shinn
P.S. sendfile(2) would be very easy to add to Spiffy for those
interested.

True. Fact is, Spiffy does not use it right now. Therefore it has to
read/write every bit of the content. Which is slow. I don't think the
threading makes up for this in the case of static content (especially
not if we're talking about large files, like ISO images).

Post by Alex Shinn
P.P.S. you can always use Spiffy along with Apache via mod_proxy and
mod_rewrite. synthcode.com runs on a Scheme webserver on the same
machine as several friends who all use Apache (and, sadly, rails).

Sure you can do that. But that is not going to make Spiffy faster than
Apache.

Nor does it make it a good idea to put everything in Spiffy. I mean, the
generation of code depending on the database layout (if I understand
correctly, that is the main advantage of Rails) could be useful for
stand-alone application development too. Why should it be limited to only
web-site development? Or to only one web-server? There is no need to
unnecessarily limit its usefulness.

Just my 2 Eurocents.

Groetjes,
Peter.

Alex Shinn

2006-04-23 09:42:52 UTC

Sounds good, except that Yaws is not Spiffy and Erlang is not Chicken.
However, it would certainly be interesting to see the same benchmark performed
on Spiffy.

I did say "is closer to," which seemed fair since we're all waving our
hands and making stuff up here :)

In the absense of any lies^Wstatis^Wbenchmarks, I'd wager Chicken's
thread handling is closer to Erlang than to POSIX threads. And if you
look at the conclusions on that Apache comparison, the author suggests
the reason Apache doesn't scale has nothing to do with the Apache code
itself, but rather because POSIX threads themselves do not scale.

BTW, I believe Termite threads are within a factor 1.x the speed of
Erlang threads, and there has been mention of Tint, a Chicken port of
Termite.

Post by Alex Shinn
For Ajax sites, small dynamic requests are the norm and this
scalability is essential.

Except that Ajax is not the kind of static HTML content Shawn was talking
about.

Yes, but Ajax and more generally dynamic content is _exactly_ what
Rails is about. Since that is the topic of this thread, benchmarking
static data isn't very meaningful.

Sure you can do that. But that is not going to make Spiffy faster than
Apache.

Indeed no, that was an unrelated point to an earlier comment. Someone
mentioned out that many people are stuck with Apache, and there were
suggestions of using FCGI or SCGI. I was pointing out that this was
entirely unecessary, and you could still run Spiffy-based applications
behind Apache.

Post by Peter Busser
Nor does it make it a good idea to put everything in Spiffy. I mean, the
generation of code depending on the database layout (if I understand
correctly, that is the main advantage of Rails) could be useful for
stand-alone application development too. Why should it be limited to only
web-site development? Or to only one web-server? There is no need to
unnecessarily limit its usefulness.

Sure, this makes perfect sense, though an easy-to-use Spiffy interface
built on top of the core functionality would be nice, just as Rails
has Webrick.

--
Alex

John Cowan

2006-04-23 15:15:09 UTC

Post by Alex Shinn
In the absense of any lies^Wstatis^Wbenchmarks, I'd wager Chicken's
thread handling is closer to Erlang than to POSIX threads. And if you
look at the conclusions on that Apache comparison, the author suggests
the reason Apache doesn't scale has nothing to do with the Apache code
itself, but rather because POSIX threads themselves do not scale.

Well, there's scaling, and then there's scaling. Lightweight threads
are wonderful things on uniprocessor machines, but they aren't going
to be sufficient on multicore boxes, especially not the ones that
are coming with large numbers of cores. A way is going to have to
be found to overcome that problem, or lightweight thread architectures
are going to be as dead as the dodo on the Web.

--
Time alone is real John Cowan <***@ccil.org>
the rest imaginary
like a quaternion --phma http://www.ccil.org/~cowan

Shawn Rutledge

2006-04-23 19:16:59 UTC

That's a good point. So which OS has the most efficient threads now
that can be spread across cores?

Maybe there is room for a hybrid approach - create a fixed number of
OS threads (equal to the number of cores), then shuffle lightweight
threads among them in a way that balances the load and avoids putting
threads that compete for the same resources on different cores?

Alex Shinn

2006-04-24 01:30:32 UTC

It's really not that simple.

For one thing, this is totally a non-issue for high-scale web-servers.
Just run a separate process for each CPU on its own port and have the
load balancer split between them. Each process can use lightweight
threads resulting in higher scalability overall than a POSIX thread
based solution.

For scientific computing and pure number-crunching, generally either
you have a parallelizable problem, in which case multiple processes
work just as well as threads, or you don't, in which case no threading
architecture will be of any use.

Probably the most important use of SMP-based POSIX threads is video
games, yet the vast majority of games are single-threaded.

Also, it's not clear that multicore is the future, anymore than it is
that RISC is the future :) With AMD's new reverse hyperthreading, they
are using multiple cores to emulate a single core, an approach which
will let people continue to develop single-threaded applications and
count on Moore's law to continue to apply to single-processor machines
for the forseeable future.

--
Alex

Brandon J. Van Every

2006-04-24 04:58:24 UTC

Post by Alex Shinn
Probably the most important use of SMP-based POSIX threads is video
games, yet the vast majority of games are single-threaded.

Because it's way easier to do the logic and debugging for the single
threaded case. This is a commonly reported finding throughout the game
industry. Game developers typically want control over everything that's
going on, especially with respect to latency. This is easier to achieve
with single threading.

Post by Alex Shinn
Also, it's not clear that multicore is the future, anymore than it is
that RISC is the future :)

RISC is, sadly, the past. It failed to take hold in the marketplace
because it was different from the dominant architecture, Intel. Intel
munged as much of RISC as was useful to its purposes. The DEC Alpha was
the best CPU in the world in 1998, and it is no more. Spent my paying
career on that chip. There will of course be new RISC and VLIW
architectures, but from a $$$$$$$$ standpoint their architectural
characteristics are not interesting. What matters is whether they can
fabricate and market in sufficient volume to give Intel a real
challenge. Intel kicked the snot out of DEC because they had better
fabrication and better marketing.

Cheers,
Brandon Van Every
ex-DECcie

john

2006-04-24 09:28:31 UTC

Post by Brandon J. Van Every

What about the 3 major games console makers? They are went for RISC
solutions in their latest consoles. That is a lot of units!

Also, the embedded world is dominated by low powered RISC based solutions.

John.

Post by Alex Shinn
Probably the most important use of SMP-based POSIX threads is video
games, yet the vast majority of games are single-threaded.

Post by Alex Shinn
Also, it's not clear that multicore is the future, anymore than it is
that RISC is the future :)

Brandon J. Van Every

2006-04-24 12:46:31 UTC

Post by john
What about the 3 major games console makers? They are went for RISC
solutions in their latest consoles. That is a lot of units!

Yeah this is an instance of not being beholden to Intel. BTW I think
Cell is VLIW, not RISC.

Post by john
Also, the embedded world is dominated by low powered RISC based solutions.

Again, not beholden to Intel.

Cheers,
Brandon Van Every

Shawn Rutledge

2006-04-23 19:23:09 UTC

Post by Alex Shinn

Post by Alex Shinn
For Ajax sites, small dynamic requests are the norm and this
scalability is essential.

Except that Ajax is not the kind of static HTML content Shawn was talking
about.

Yes, but Ajax and more generally dynamic content is _exactly_ what
Rails is about. Since that is the topic of this thread, benchmarking
static data isn't very meaningful.

I think a lot of sites are unnecessarily dynamic these days - news
sites that serve up stories from a database, wikis that do the same,
etc. And anytime you are using a database table just to map one key
to one value, the same thing could be more efficiently done in the
filesystem, especially nowadays when filesystem optimization is
getting some attention.

F. Wittenberger

2006-04-22 14:21:02 UTC

Dear all,

who are interested in a decent web programming framework in Scheme.

We've been spending quite a while on such a thing and I'm simply not the
person to brag about my part of work (which has been too much), maybe
that's the reason it makes me sad watching you people here calling for
it in *chicken*. That makes my posting off topic. But I can't resist,
since you really don't know what you are missing right next door:

There's a web programming framework in rscheme. I've been close to a
chicken port once. And I'm longing for it, since I hope we could
eventually leverage the larger user base to fasten development instead
of working almost like proprietary developers, though we've been open
source from the very beginning. (To be fair: for the initial
development, a bazar style would not have been helpful, so we did not
try.)

Our framework appears to the Scheme programmer in a way like two Scheme
alike programming languages. One just as any Scheme, think of your
favourite Scheme interpreter and one, which is like a coarse grained
Scheme. (But it's not [yet] a complete Scheme. The vm kernel
implements only basic operations. Enough to build a Scheme interpreter,
which is left to be done.) This coarse grained virtual machine is
intended to keep persistent application state. It supports a the actor
programming model, whereby each object/actor is merely just a
continuation. Those talk to each other using asynchronous messages.
Much like Erlang or E ( http://www.erights.org/elang/index.html ). The
MVC model is deeply build in the system too. For two reasons: for one
thing it's a difference from a legal point of view, whether you explore
things without modification or if you apply methods, which may cause
modifications. Second: optimisation: for idempotent operations, we
don't need to take locks. Therefore our "view" parts are written in a
Scheme subset, which can not mutate persistent data (subsets of Scheme,
XSLT and SQL). (BTW: a [fixed] SRFI 49 can be useful, for SXML. ;-)

Still missing is some ajax support. Shouldn't be too hard. Want to see
the classic address book example (w/o SQL)?
http://askemos2.tc-mw.de/A67bb0753e1676f81983e0ecf3a15b391/UsingWeightBalancedTrees
(scroll down to "Source code:")

But Askemos is defined as a protocol (not an implementation), keeping
such coarse grained Interpreters synchronous in byzantine agreement.
This means: a certain minority of hosts can get lost (due to disk crash,
malicious hackers, unreliable administration, gun power or whatever
disaster), your applications continue to run untroubled. If you where
to run on a few hosts together with your, say business partners or
friends, connected over tor (tor.eff.org), you where safe even against
physical extortion. Just let them take the machine, where you kept your
encrypted notes and ask your partners for their copy. If we had
multiple implementations, it would be even better: if one implementation
broke (say a bug would let you take over any program written in a
particular Scheme implementation), the heterogeneous net is uneffected.

The fact that we need such a protocol eventually (to evade the chaos of
computers taken out of control and random due to broken DRM systems)
made me define the VM in XML. That's what I call coarse grained: all
persistent data has an XML representation (besides the internal
structure, which we cache too). And a checksum is taken for each and
every transaction and agreed upon over the net. This is kind of slow
(think of 0.3 seconds per mouse click over WAN/SSL and a few seconds
when using tor [pipelining will help one day]) and that's why there are
two interpreters: the "traditional" one for the computation itself and
the byzantine to update persistent state which may not get lost or
tampered with.

On the wire you get to speak http/s, WebDAV and lmtp/smtp out of the
box. So your applications will typically talk SOAP or alike to the
outside world. But that's app developer's decision.

The main intent was to allow to model legal systems. Legal purposes
require to record some meta data with all values. You must always be
able to verify the author, timestamp of creation, determine that
document are unmodified and determine the local interpreter (needed for
tamper proofed processes, would go far beyond this posting). Ensuring
correctness using a Askemos network goes far beyond the simple
guaranties associated with timestamps from accredited and certified
providers.

The most interesting thing is of the whole framework is the capability
system. Since we are not interested in a toy system, it has to make
sure that no player will be able to intrude the system. Even at initial
setup. All byzantine agreement was useless, if one you partners is in
your reliance set for logical reasons. Therefore users (and the public)
are like citizens of the network and the root of their private
capability hierarchies. They are equal among each other. No other
pre-system start capability distribution exists (like in E). No super
user to hack. (AFAIK Askemos is still the only system, which can proof
this "incorruptible" property, which is essential for accountability.)

Find it working at www.askemos.org , askemos1.tzv.de and
askemos2.tc-mw.de . Those 96.2982% write availability seen here
http://askemos2.tc-mw.de/A539cdd39291e7d159c68bb199f5a88d5
include downtime due to kernel development, network partinioning etc.
(and in theory, three machines is already like 1/4 missing).

Think of it. Askemos gives you a degree of certainty and reliability
not yet found anywhere else.

Just it's not yet available in chicken. If you where to start again,
please consider to join and help to port it over to you favorite
language.

Post by Peter Bex

How about
http://askemos2.tc-mw.de/A67bb0753e1676f81983e0ecf3a15b391/XSQLExample
(The part about data base connection configuration only applies if you
don't use sqlite.)

Post by Peter Bex
The question is whether
that is really required. The most important aspect about Rails is that
it has decent defaults. You can just build a database and run Rake
to set up a Rails environment and you have a bare-bones interface to
the database out of the box. To do things, you need the very minimum
of custom code. This is the essence of what makes Rails so popular.
I'm not sure if this can be done as easily in a non-object-oriented
environment. Ruby makes it easy to automatically build objects from
information because it allows you to add members to existing classes.
I think with the Prometheus egg we could do something like this.
As you see, a lot of stuff is already there. It's just crying for
someone to put it all together.
I've been thinking about doing something like this myself since I am
involved in web programming for a company where we are using PHP (yuck!)
and Ruby. I'd *love* to have something like Rails in Chicken.
The reason I haven't done any work on it is, of course, I'm currently
too busy with some other things that just need to get done before I can
do anything fun like hacking Chicken :(
If anyone is interested: having a decent userfriendly Scheme CMS would
be *very* useful too :)

Peter Bex

2006-04-22 15:09:09 UTC

I've taken a look at the Askemos webpage and read your description a
number of times, but I can't really grasp *what* Askemos is exactly.
Is it an operating system, a language, a web development framework, a
system to make concurrent programming reliable or a system that makes
it easy to use a number of redundant servers? Or is it all of these
things?

I'm sorry if I sound stupid and I don't mean to insult, but I really
don't understand what Askemos does. I think I speak for everyone here
if I say that we want a system that is *easy* to hack. It should be
simple and lightweight, just like Chicken itself. What makes Scheme
interesting is that it's small enough to fit in your head and
nevertheless is powerful enough to do anything you want. A web
framework in Scheme should have the same qualities.

Regards,
Peter

F. Wittenberger

2006-04-22 17:29:13 UTC

...

Post by Peter Bex
I've taken a look at the Askemos webpage and read your description a
number of times, but I can't really grasp *what* Askemos is exactly.
Is it an operating system, a language, a web development framework, a
system to make concurrent programming reliable or a system that makes
it easy to use a number of redundant servers? Or is it all of these
things?

It's all of these. Well the easy part is still sort of questionable.
Depends on what you compare.

If you look at it from 3000 feet, you see an operating system, because
an operating system manages computer resources. As such it has been
hard all the times to distinguish between operating system and language
implementation. As long as we talk about assembler or C, things are
clear, but when you add threads and garbage collection, the difference
blurs away. At the other hand: expect funny reactions when telling
people "this OS is written in Scheme".

If you look at it as an application developer, you always see it though
some HTTP/S request response scheme. So web dev framework applies.
Since that's what we do to make our living, this aspect gets better over
time.

So it's a reliable distributed - ähm, uh... - app server?

Actually Askemos is only the concept: all objects (be them documents or
processes) of a legal system (to be modelled) are represented at a
"place" (which is basically an agent/object, serves as either deed, file
or process). Certain properties are ensured by the agreement protocol:
clear authorship, tamper proofed, no rights escalation, no corruption,
agreed execution. There's a VM, which defines how processes are
executed. Beeing XML it's as language and hardware independent as it
can get. Anything would be better but that's why XML is the worst
common denominator everybody accepts as readable. (The
"Justizkommunikationsgesetz" [would this be "justice comunication
act" ??] for instance defines for Germany that XML would be acceptable.
Not much else.)

Beyond the VM-Level we stop talking about Askemos itself. There are two
more levels the protocol (http+extension) and the implementation (ball).
If we distinguish these, we come closer to the questions.

Yes, this should be visible at the web site. Thanks for asking.

Hm, now I'm in trouble: one says "drop the ball part" from the page,
here it's back.

Post by Peter Bex
I'm sorry if I sound stupid and I don't mean to insult, but I really
don't understand what Askemos does. I think I speak for everyone here
if I say that we want a system that is *easy* to hack. It should be
simple and lightweight, just like Chicken itself. What makes Scheme
interesting is that it's small enough to fit in your head and
nevertheless is powerful enough to do anything you want. A web
framework in Scheme should have the same qualities.

Agreed. That's our goal as well. At the application level it's not
that hard. All you do usually: put all you stuff in a webdav folder.
Start on of you Scheme scripts as a process and you are done. There's
no principal difference to other frame works. Except for completeness.

If you need to access C libraries or other compiled code, you need to
export it properly. Not too hard either, I'd say.

Let's put it that way: once they got it up and running, a few people
liked it. That's good and bad: good for as relative success, bad for
the total amount.

But it runs single host as well. And that is at least supposed to work
out of the box.

/Jörg

F. Wittenberger

2006-04-24 16:33:35 UTC

sorry, this was meant to be sent to the mailing list, not private

Jörg, what would be needed to port Askemos to Chicken
(not that I have time for this, but I'd like to know anyway... ;-)
?

I placed a tarball at the askemos web site, which contains an directory
with chicken modules and makefile. This directory used to build about
30 month ago. I'm afraid it will no longer.
There are a few things, which should probably be redone. The sandbox
interpreter, UTF-8 come to mind. C FFI work: sha256, libmagic, sqlite.
Many things will be API glue code. Also persistent storage: rscheme has
pstore, chickens evict might be helpful to reduce load time. But that's
less priority, since it's optional. Furthermore I'm pretty sure that
more issues will pop up as we go. I recall e.g., the leventhshein egg
not deploying some obvious optimisation and beeing deadly incompatible
with user level threading. I vaguely recall apparent slow i/o on
chicken and never could pin it down and I recall askemos/ball triggering
some age old bug in rscheme's i/o and pstore code. Who knows what's
coming next.
A real problem will be how to implement time constraints for certain
operations. There are two kind of operations, which may need to
asynchronous termination: network activity and user supplied code. In
any case, we need to make sure the dynamic wind stack is properly
cleaned. This is an open questions for rscheme too: if the timeout
exception is raised during the execution of the post hook of a dynamic
wind, just before the actual post hooks code is executed, the post hook
is not executed at all, which ist just the opposite of the intention. I
guess: Felix, here we depend on you anyway. ;-/
Cheers
/Jörg

cheers,
felix

Post by F. Wittenberger
...

It's all of these. Well the easy part is still sort of questionable.
Depends on what you compare.
If you look at it from 3000 feet, you see an operating system, because
an operating system manages computer resources. As such it has been
hard all the times to distinguish between operating system and language
implementation. As long as we talk about assembler or C, things are
clear, but when you add threads and garbage collection, the difference
blurs away. At the other hand: expect funny reactions when telling
people "this OS is written in Scheme".
If you look at it as an application developer, you always see it though
some HTTP/S request response scheme. So web dev framework applies.
Since that's what we do to make our living, this aspect gets better over
time.
So it's a reliable distributed - ähm, uh... - app server?
Actually Askemos is only the concept: all objects (be them documents or
processes) of a legal system (to be modelled) are represented at a
"place" (which is basically an agent/object, serves as either deed, file
clear authorship, tamper proofed, no rights escalation, no corruption,
agreed execution. There's a VM, which defines how processes are
executed. Beeing XML it's as language and hardware independent as it
can get. Anything would be better but that's why XML is the worst
common denominator everybody accepts as readable. (The
"Justizkommunikationsgesetz" [would this be "justice comunication
act" ??] for instance defines for Germany that XML would be acceptable.
Not much else.)
Beyond the VM-Level we stop talking about Askemos itself. There are two
more levels the protocol (http+extension) and the implementation (ball).
If we distinguish these, we come closer to the questions.
Yes, this should be visible at the web site. Thanks for asking.
Hm, now I'm in trouble: one says "drop the ball part" from the page,
here it's back.

Agreed. That's our goal as well. At the application level it's not
that hard. All you do usually: put all you stuff in a webdav folder.
Start on of you Scheme scripts as a process and you are done. There's
no principal difference to other frame works. Except for completeness.
If you need to access C libraries or other compiled code, you need to
export it properly. Not too hard either, I'd say.
Let's put it that way: once they got it up and running, a few people
liked it. That's good and bad: good for as relative success, bad for
the total amount.
But it runs single host as well. And that is at least supposed to work
out of the box.
/Jörg
_______________________________________________
Chicken-users mailing list
http://lists.nongnu.org/mailman/listinfo/chicken-users

Shawn Rutledge

2006-04-24 22:12:31 UTC

Well I see the idea of calling a web framework an OS is not new:

http://blogs.zdnet.com/web2explorer/?p=166

Somebody states the obvious, that DHTML + Javascript isn't very nice
and wouldn't it be great if we could start over. I've been thinking
for a while that Scheme could be the universal language for such
things - you could describe the page and write the scripting to make
it dynamic, and write the server-side code, in the same language.
Hopefully by using higher-level abstractions that gloss over the fact
that it's a distributed application. This is what I ultimately want
to accomplish. I want the same app to run on a single machine, or as
a web app on a legacy browser, or on a new kind of browser that is all
Scheme, without having to rewrite the app. So are these the kinds of
goals you have in Askemos too? It doesn't seem well-defined enough,
and more concerned with being secure and tamper-proof, whereas I would
be glad to achieve usefulness first, and worry about security later.

A side project is how to get rid of the parentheses so that ordinary
people can tolerate writing Scheme. :-) I think it's just a matter
of writing a really awesome editor that understands a lot of common
constructs and displays them appropriately. It should look something
like MathCAD but have graphical representations for every concept used
in programming, not just math expressions. You would edit the lists
in memory directly, and the textual syntax is only the output when you
save it to a file.

Rscheme sounds interesting in that it has object persistence already.
Can you trust it? Can you be sure that data will not be lost to
obscurity because it's in some platform-specific binary form? Can you
trust it not to change in incompatible ways so that your data is lost?
These are the reasons I think maybe a human-readable S-expression
form is good for persistence. And leverage the filesystem to do some
of the indexing work (e.g. use a lot of files rather than one big
file, laid out into a tree that makes sense. Just in case the code
has to be re-written some day.)

Otherwise there are some other object databases that are not
Scheme-specific (Goods, and the Zope one for example).

Post by F. Wittenberger
Dear all,
who are interested in a decent web programming framework in Scheme.
We've been spending quite a while on such a thing and I'm simply not the
person to brag about my part of work (which has been too much), maybe
that's the reason it makes me sad watching you people here calling for
it in *chicken*. That makes my posting off topic. But I can't resist,
There's a web programming framework in rscheme. I've been close to a
chicken port once. And I'm longing for it, since I hope we could
eventually leverage the larger user base to fasten development instead
of working almost like proprietary developers, though we've been open
source from the very beginning. (To be fair: for the initial
development, a bazar style would not have been helpful, so we did not
try.)
Our framework appears to the Scheme programmer in a way like two Scheme
alike programming languages. One just as any Scheme, think of your
favourite Scheme interpreter and one, which is like a coarse grained
Scheme. (But it's not [yet] a complete Scheme. The vm kernel
implements only basic operations. Enough to build a Scheme interpreter,
which is left to be done.) This coarse grained virtual machine is
intended to keep persistent application state. It supports a the actor
programming model, whereby each object/actor is merely just a
continuation. Those talk to each other using asynchronous messages.
Much like Erlang or E ( http://www.erights.org/elang/index.html ). The
MVC model is deeply build in the system too. For two reasons: for one
thing it's a difference from a legal point of view, whether you explore
things without modification or if you apply methods, which may cause
modifications. Second: optimisation: for idempotent operations, we
don't need to take locks. Therefore our "view" parts are written in a
Scheme subset, which can not mutate persistent data (subsets of Scheme,
XSLT and SQL). (BTW: a [fixed] SRFI 49 can be useful, for SXML. ;-)
Still missing is some ajax support. Shouldn't be too hard. Want to see
the classic address book example (w/o SQL)?
http://askemos2.tc-mw.de/A67bb0753e1676f81983e0ecf3a15b391/UsingWeightBalancedTrees
(scroll down to "Source code:")
But Askemos is defined as a protocol (not an implementation), keeping
such coarse grained Interpreters synchronous in byzantine agreement.
This means: a certain minority of hosts can get lost (due to disk crash,
malicious hackers, unreliable administration, gun power or whatever
disaster), your applications continue to run untroubled. If you where
to run on a few hosts together with your, say business partners or
friends, connected over tor (tor.eff.org), you where safe even against
physical extortion. Just let them take the machine, where you kept your
encrypted notes and ask your partners for their copy. If we had
multiple implementations, it would be even better: if one implementation
broke (say a bug would let you take over any program written in a
particular Scheme implementation), the heterogeneous net is uneffected.
The fact that we need such a protocol eventually (to evade the chaos of
computers taken out of control and random due to broken DRM systems)
made me define the VM in XML. That's what I call coarse grained: all
persistent data has an XML representation (besides the internal
structure, which we cache too). And a checksum is taken for each and
every transaction and agreed upon over the net. This is kind of slow
(think of 0.3 seconds per mouse click over WAN/SSL and a few seconds
when using tor [pipelining will help one day]) and that's why there are
two interpreters: the "traditional" one for the computation itself and
the byzantine to update persistent state which may not get lost or
tampered with.
On the wire you get to speak http/s, WebDAV and lmtp/smtp out of the
box. So your applications will typically talk SOAP or alike to the
outside world. But that's app developer's decision.
The main intent was to allow to model legal systems. Legal purposes
require to record some meta data with all values. You must always be
able to verify the author, timestamp of creation, determine that
document are unmodified and determine the local interpreter (needed for
tamper proofed processes, would go far beyond this posting). Ensuring
correctness using a Askemos network goes far beyond the simple
guaranties associated with timestamps from accredited and certified
providers.
The most interesting thing is of the whole framework is the capability
system. Since we are not interested in a toy system, it has to make
sure that no player will be able to intrude the system. Even at initial
setup. All byzantine agreement was useless, if one you partners is in
your reliance set for logical reasons. Therefore users (and the public)
are like citizens of the network and the root of their private
capability hierarchies. They are equal among each other. No other
pre-system start capability distribution exists (like in E). No super
user to hack. (AFAIK Askemos is still the only system, which can proof
this "incorruptible" property, which is essential for accountability.)
Find it working at www.askemos.org , askemos1.tzv.de and
askemos2.tc-mw.de . Those 96.2982% write availability seen here
http://askemos2.tc-mw.de/A539cdd39291e7d159c68bb199f5a88d5
include downtime due to kernel development, network partinioning etc.
(and in theory, three machines is already like 1/4 missing).
Think of it. Askemos gives you a degree of certainty and reliability
not yet found anywhere else.
Just it's not yet available in chicken. If you where to start again,
please consider to join and help to port it over to you favorite
language.

Post by Peter Bex

How about
http://askemos2.tc-mw.de/A67bb0753e1676f81983e0ecf3a15b391/XSQLExample
(The part about data base connection configuration only applies if you
don't use sqlite.)

Well, I personally don't use much more that the wiki, directories
(WebDAV), a Forum/RSS, a messaging thingy and a few special applications
(for invoices etc.). We have also some Webmailer, but that's not yet
powerful enough to make me ditch evolution.
Best regards
/Jörg
_______________________________________________
Chicken-users mailing list
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every

2006-04-24 23:13:24 UTC

Post by Shawn Rutledge
http://blogs.zdnet.com/web2explorer/?p=166
Somebody states the obvious, that DHTML + Javascript isn't very nice
and wouldn't it be great if we could start over. I've been thinking
for a while that Scheme could be the universal language for such
things -

Anything could be. Jeez look at C++. This kind of problem is about
creating critical mass. It's more a marketing than a technical problem.

Don't waste time on this. The reason people don't use Scheme, is
success hasn't bred success. If you had a Scheme On Rails, or some
other killer app that was really industrial strength and saved a lot of
users a significant amount of work, people would stop bitching and
moaning about parentheses. You'd be better off doing less technical
projects and more human organizational projects. Get people together to
create an important Scheme app.

Unfortunately, web stuff completely bores me and I have no time
anyways. I've made the overtures about game stuff several times here.
Nobody has bitten. I don't really expect them to. The real problem is
not parentheses. It's critical mass and compelling apps.

Cheers,
Brandon Van Every

Matthew Welland

2006-04-29 03:38:51 UTC

Post by Brandon J. Van Every
Unfortunately, web stuff completely bores me and I have no time
anyways. I've made the overtures about game stuff several times here.
Nobody has bitten. I don't really expect them to. The real problem is
not parentheses. It's critical mass and compelling apps.

I missed the game stuff. What were you thinking about? I've been toying with
bb + opengl with both some engineering applications and some game
applications in mind but I keep getting stuck. Maybe a light-weight initial
goal would be a good starting point.

Matt
--

Post by Brandon J. Van Every
Cheers,
Brandon Van Every
_______________________________________________
Chicken-users mailing list
http://lists.nongnu.org/mailman/listinfo/chicken-users

--
Visit http://www.kiatoa.com, the first self-governing site on the Internet.
You choose the stories and the polls and the classifieds are always free.

Pupeno

2006-04-25 08:22:20 UTC

Post by Shawn Rutledge
A side project is how to get rid of the parentheses so that ordinary
people can tolerate writing Scheme.

Getting rid of parenthesis is dangerous, people may forget that while writting
Scheme programs you are doing it as Scheme data and that programs are no more
than a tree (build up with cons... lists if you like).
I believe the best thing is to teach the language, not to bend it to fits
someone's mind. That kind be done by making conferences in Linux and
Linux-like events.
I've done that and even with parethesis I've got some people really interested
wanting to try it.
If you are interested, my sildes are on-line:
http://pupeno.com/conferencias/lisp-un-lenguage-diferente/
They are in spanish, so, let me translate the firsts for you:

(silde 1
Lisp, a different language.)

There I explain that Lisp is really different. Let's see why it is different:

(slide 2
- The name of a procedure goes inside the parenthesis, (print "a") instead of
print("a").
- Instead of writting 4 + 4 you write + 4 4.
- It is the second oldest language.
- It is used in artificial intelligence)

And as I explain the last point I let a label "BULLSHIT" stamp over those
reasons. That really wakes up the public. And it also puts things where they
belong. I go on explaining that those difference really exist and that
newcomers are likely to see them first but they should not regard it as
important because they are not. They are superficial things and the real
thing is below.
I think that explanation and all the circus around it makes people not wanting
to worry about it (nobody likes worrying about superficial things, so, stand
up and shout that it is just a superficial thing... you may at least, have a
few people that will try to look deeper).

The first time I gave this talk I had a slot of one hour... when the hour
passed by I continue as nobody needed the room; I noticed some people
leaving, maybe for other talks that were starting, so I announced that time
was up, everybody was free to leave but I would continue until I was finished
or kicked out of the room. I continue with one and a half more hours, the
public ended up being those really interested, it was very relaxed and I had
times to do some very nice tricks on the blackboard (like implementing pairs
using just procedures, implementing IF using cond and syntax extensions,
etc). People were really pleased, with discussed the language against other
languages (there were people in the audience with a wide spectrum of
languages; one even was complaining that some other language could do all
that until I've found out that it was another Lisp, hehehe).
I am not currently using Lisp actively, but I would love to give this
conference again, either in Spanish or English, if I am allowed the right
amount of times (2hs). I even could turn it into a written article, but so
far no magazines were interested on it.
Thank you.

--
Pupeno <***@pupeno.com> (http://pupeno.com)

Brandon J. Van Every

2006-04-25 08:35:25 UTC

Post by Pupeno

Post by Shawn Rutledge
A side project is how to get rid of the parentheses so that ordinary
people can tolerate writing Scheme.

Also, the market doesn't need it. If you want decent programming
languages without parentheses for web development, you can use Python or
Ruby. Dumbing down Scheme is like parenthesizing-up Python. Almost
nobody needs it.

Post by Pupeno
- It is used in artificial intelligence)
And as I explain the last point I let a label "BULLSHIT" stamp over those
reasons. That really wakes up the public. And it also puts things where they
belong.

Especially for game development, I see almost no evidence of anyone
using Lisp or Scheme for game AI. Of course it's usually not real AI.

Cheers,
Brandon Van Every

Shawn Rutledge

2006-04-25 18:43:29 UTC

Post by Pupeno

Post by Shawn Rutledge
A side project is how to get rid of the parentheses so that ordinary
people can tolerate writing Scheme.

OK, so the concept that data and code are the same is important, but
the parentheses are just there because pre-order syntax with variable
numbers of arguments requires some kind of delimiter. (And HP
calculator users take the opposite stance that RPN is so wonderful
precisely because you don't need delimiters.) I think teaching the
concept requires some thought about the structure in memory; it's way
more important than the ASCII syntax. The books use diagrams to show
this, yet there is no editor to let you interactively modify memory by
manipulating diagrams. (And then there is the related issue that
keyboarding is faster than mousing. So you just have to make the
diagram manipulation similarly efficient by keyboard. MathCAD
achieved this, for math expressions. I used to use it on DOS, without
a mouse.)

F. Wittenberger

2006-04-26 11:21:09 UTC

Post by Pupeno

Post by Shawn Rutledge
A side project is how to get rid of the parentheses so that ordinary
people can tolerate writing Scheme.

May I second that!

I feel that most of these religious wars about programming languages
stem from some warm feeling when you come closer to the ASCII style you
are used to. That's like coming at home, sure, but no more.

Be multilingual and you can choose the tool language according to the
problem domain.

Post by Shawn Rutledge
The books use diagrams to show
this, yet there is no editor to let you interactively modify memory by
manipulating diagrams. (And then there is the related issue that
keyboarding is faster than mousing. So you just have to make the
diagram manipulation similarly efficient by keyboard. MathCAD
achieved this, for math expressions. I used to use it on DOS, without
a mouse.)

Wait. I'm longing for such a tool. What makes it special to math
expressions? (Or: what's the difference between lambda calculus and
math, so why should this not work for Scheme?)

Post by Shawn Rutledge
_______________________________________________
Chicken-users mailing list
http://lists.nongnu.org/mailman/listinfo/chicken-users

Brandon J. Van Every

2006-04-27 11:04:33 UTC

Post by F. Wittenberger
Be multilingual and you can choose the tool language according to the
problem domain.

Which unfortunately is also the opportunity to be unproductive for long
periods of time as you chase down further learning curves, rabbit holes,
and support burdens. Language religionism is based on how long it takes
to learn things, and how easy or hard it is to tackle various problems
in the real world.

Cheers,
Brandon Van Every

F. Wittenberger

2006-04-25 16:13:32 UTC

Post by Shawn Rutledge
http://blogs.zdnet.com/web2explorer/?p=166

So who was the first one? ;-)

Post by Shawn Rutledge
Somebody states the obvious, that DHTML + Javascript isn't very nice
and wouldn't it be great if we could start over. I've been thinking
for a while that Scheme could be the universal language for such
things - you could describe the page and write the scripting to make
it dynamic, and write the server-side code, in the same language.
Hopefully by using higher-level abstractions that gloss over the fact
that it's a distributed application. This is what I ultimately want
to accomplish. I want the same app to run on a single machine, or as
a web app on a legacy browser, or on a new kind of browser that is all
Scheme, without having to rewrite the app. So are these the kinds of
goals you have in Askemos too?

Yep. I expect Askemos to cater the "M+C" part of the MVC. Run the app
(business logic) regardless of the choosen viewer.

And run the backup too. In case my machine blows up is is beeing
rooted.

There's quite a lot on my wish list. But there I distinguish between
application level, where your Scripts and libraries reside, and kernel
level, which just does the message routing and state synchronization.

Post by Shawn Rutledge
It doesn't seem well-defined enough,
and more concerned with being secure and tamper-proof, whereas I would
be glad to achieve usefulness first, and worry about security later.

Unfortunately the security experts insist for a reason, that you can't
build security into an insecure system, it has to be build in right from
the beginning.

And that's more true, when the focus is legal processes. This *must* go
down to the system architecture or you'll loose all your development
work eventually.

The good news is, that we have it usable. Our pages look slightly
simpler that plain Spiffy or this ajax frame work posted these days.
Well, to me and I'm biased. But I know about at least one person, who
just picked Askemos/BALL because of it's mix of XML transformation
features ignoring all the sec. features.

However: we lack ajax right now. It's pretty much in focus, but not
there yet.

Post by Shawn Rutledge
A side project is how to get rid of the parentheses so that ordinary
people can tolerate writing Scheme. :-) I think it's just a matter
of writing a really awesome editor that understands a lot of common
constructs and displays them appropriately. It should look something
like MathCAD but have graphical representations for every concept used
in programming, not just math expressions. You would edit the lists
in memory directly, and the textual syntax is only the output when you
save it to a file.
Rscheme sounds interesting in that it has object persistence already.
Can you trust it? Can you be sure that data will not be lost to
obscurity because it's in some platform-specific binary form? Can you
trust it not to change in incompatible ways so that your data is lost?

Yes and no. No, you don't want to trust any binary only data format.
Especially not, when it's a gziped memory dump. Furthermore there are
size limits. But it helps to reduce load time. So I'm caching a lot of
intermediate data. But there's always a "canonical" copy in, well,
that's why I decided to go XML.

Post by Shawn Rutledge
These are the reasons I think maybe a human-readable S-expression
form is good for persistence.

Hm, XML has a few more editors and I'd expect them to become usable
eventually. I don't think this will be the case for S-expressions any
time soon. (Well, up to emacs etc. editing help, that's not the type I
think of.)

Post by Shawn Rutledge
And leverage the filesystem to do some
of the indexing work (e.g. use a lot of files rather than one big
file, laid out into a tree that makes sense. Just in case the code
has to be re-written some day.)

That's how I keep the "canonical" form.

Post by Shawn Rutledge
Otherwise there are some other object databases that are not
Scheme-specific (Goods, and the Zope one for example).

Post by Peter Bex

How about
http://askemos2.tc-mw.de/A67bb0753e1676f81983e0ecf3a15b391/XSQLExample
(The part about data base connection configuration only applies if you
don't use sqlite.)

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

Shawn Rutledge

2006-04-25 18:32:45 UTC

Post by F. Wittenberger

Post by Shawn Rutledge
http://blogs.zdnet.com/web2explorer/?p=166

So who was the first one? ;-)

Oh you guys started the trend?

Post by F. Wittenberger
There's quite a lot on my wish list. But there I distinguish between
application level, where your Scripts and libraries reside, and kernel
level, which just does the message routing and state synchronization.

In which level are the model objects then?

Post by F. Wittenberger
Unfortunately the security experts insist for a reason, that you can't
build security into an insecure system, it has to be build in right from
the beginning.

Yeah and the other risk is if you worry about too many things at once,
the prototype never gets done. The Xanadu project to me is both a
great inspiration, and a great example of how not to get anything
done. I would like to have all of its features and then some, but not
to get trapped in 40 years of tailspin. Anyway to me security is the
least interesting part of the problem, and I'm not an expert. I
thought the Eros project sounded very interesting, mostly because of
the orthogonal persistence implementation. But the focus is the
capability security model, which is also interesting but probably
that's the only thing that will be accomplished, the way the project
is going now. What do you think of that? Seems to me it could work
pretty well in a system like this.

Post by F. Wittenberger
And that's more true, when the focus is legal processes. This *must* go
down to the system architecture or you'll loose all your development
work eventually.

Are you saying this about all possible software projects or just Askemos?

I don't know if a few humans can design a system so tamperproof as to
keep out the billions of other humans trying to tamper with it. It's
worth a try but I think security will have to keep evolving as
different methods get cracked. The best methods that have been
envisioned don't even exist yet (like quantum computing). We'll see
if existing security architectures will adapt well to those new
methods over time.

Post by F. Wittenberger
The good news is, that we have it usable. Our pages look slightly
simpler that plain Spiffy or this ajax frame work posted these days.
Well, to me and I'm biased. But I know about at least one person, who
just picked Askemos/BALL because of it's mix of XML transformation
features ignoring all the sec. features.

XML transformation is yucky and inefficient IMO. My least favorite
language of all is XSLT.

Post by F. Wittenberger
Yes and no. No, you don't want to trust any binary only data format.
Especially not, when it's a gziped memory dump. Furthermore there are

Wow it's even worse than I thought.

What about hooking Scheme to a more stable, portable sort of OODB?

Another idea I had is if Scheme people could agree on an ideal VM
implementation (like Java or C# has), and an efficient portable binary
data format, then binary transport (like RMI in Java) and binary
serialization to files would be more trustworthy. But when VMs are
developed, not a lot of bragging is done about the design of them. I
studied QScheme a bit; it has one. Kali seems to be one of the most
complete distributed Schemes (even continuations can travel from one
machine to another, and be executed there) so doesn't that imply that
it has a portable bytecode and portable data structures? But if you
design such bytecode and data structures for conventional 32-bit or
64-bit machines, it will not be optimized for an ideal Lisp machine
(the kind that has extra bits to store the data type) and you have to
do tricks like limiting ints to 29 bits (Chez does this). And we
happen to be in a transition from 32-bit to 64-bit computing, so if
you allow 64-bit addresses for upwards scalabilty, the bytecode is not
as portable to, say, embedded devices or small platforms.

As for Chicken, is there a VM? I'm guessing not, because for speed
you just use the compiler, and therefore not a lot of emphasis would
be placed on making the interpreter the fastest.

What does RScheme do?

Post by F. Wittenberger

Post by Shawn Rutledge
These are the reasons I think maybe a human-readable S-expression
form is good for persistence.

IMO somebody needs to write a better editor for S-expressions. Good
XML editors are also nontrivial.

XML is such a fad, but it is far from optimal for either machines or humans.

At work I came up with a binary format that is portable, and allows
you to store the same kind of structures as you would express in XML
(trees of name-value pairs), but is very compact, and safe for binary
data (an int is really stored as an int - not a string, and there is a
BLOB type as well). I feel that I could trust it because the bytes
are in network byte order, and I know the format of the file. (It is
not resilient to data corruption, though. One flipped bit in the
wrong place can lead the reader off into the weeds.) The design is
straightforward and obvious (yet, other designs like WBXML are very
similar but have flaws which I think I got around in this design. I
was surprised it has not been done quite this way before.) There is a
string table at the beginning for tags and for enumerated values; each
tag uses the string table index so this is much like Scheme symbols -
the ASCII string only exists once. Each tag has a length (so you
don't need a delimiter to end the "value" part of the tag). The
length includes that of the child tags, so you can skip over entire
subtrees at read time if you decide that they are not interesting - no
need to parse every byte as with ASCII formats. Bool tags are
particularly efficient; I can store a tag and its boolean value in 2
bytes. I don't know if they would let me open-source the
implementation (not likely) but I did this in both C++ and Java and we
have used it successfully on multiple platforms and processors.

I could do something similar for S-expressions (same idea, but more
datatypes). One core problem I think for distributed Scheme is how to
negotiate a shared symbol table, to try to eliminate a level of
indirection (multiple machines could end up using the same numeric
value, or pointer, for each symbol that is known to all the machines).
The same thing applies to persisted binary files - let's not repeat
symbol tables any more often than necessary, or even if we do put the
symbol table in every file, the unification process must occur when
the file is loaded, so that in memory you don't need multiple contexts
with their own symbol tables. This is a low-level detail which can be
procrastinated, and I'm not quite sure how to do it the most efficient
way. (Maybe MMU tricks could be used effectively.) So in the
meantime ASCII S-expression files (or a binary equivalent, with the
relevant symbol table fragments repeated in every file) are nice and
portable, yet not as verbose as XML; and the assumption would be that
humans don't write them - they use friendly tools. Nowadays many
people don't write HTML by hand, and eventually I think nobody will be
writing XML by hand either. But there is no insanely great XML editor
yet, is there? Nor is there for Scheme, unless you count Emacs (which
I have still not learned to use).

John Cowan

2006-04-25 19:16:22 UTC

Post by Shawn Rutledge
Another idea I had is if Scheme people could agree on an ideal VM
implementation (like Java or C# has), and an efficient portable binary
data format, then binary transport (like RMI in Java) and binary
serialization to files would be more trustworthy.

Scheme people can't even agree on the contents of their language beyond
a bare minimum. Dream on.

Post by Shawn Rutledge
As for Chicken, is there a VM? I'm guessing not, because for speed
you just use the compiler, and therefore not a lot of emphasis would
be placed on making the interpreter the fastest.

No, Chicken does not have a VM.

Post by Shawn Rutledge
IMO somebody needs to write a better editor for S-expressions. Good
XML editors are also nontrivial.

"Good" XML editors are impossible, because they have to serve mutually
contradictory goals. The only hope is to have a variety of adequate
editors with different purposes.

Post by Shawn Rutledge
XML is such a fad, but it is far from optimal for either machines or humans.

That's the whole idea.

Post by Shawn Rutledge
At work I came up with a binary format that is portable, and allows
you to store the same kind of structures as you would express in XML
(trees of name-value pairs), [...]

In that case you might as well use ASN.1, which has the advantage of
being an international standard with multiple data representations
available (including a textual one). IMHO there is little point in
concocting yet another binary representation of XML.

In any case, it's just *one* use case of XML to provide trees of
name-value pairs. The world already has too many ways to do
XML without mixed content, but mixed content is the crown jewel
of XML.

--
First known example of political correctness: John Cowan
After Nurhachi had united all the other http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the ***@ccil.org
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should --S. Robert Ramsey,
be banned, and from then on, they were all The Languages of China
to be called Manchus.

john

2006-04-26 20:57:24 UTC

My packedobjects egg attempts to provide a simple way to express a subset of
ASN.1 using an s-expr and then encode it using the unaligned variant of
Packed Encoding Rules. It is not a general purpose encoding technique though
as it meant for applications which benefit from tightly packed binary
protocols.

I like the dynamic nature of using an s-expr over using an ASN.1 compiler.
It allows me to hack network protocols on my Sharp Zaurus without the hassle
of having to cross compile.

John.

Post by Shawn Rutledge
At work I came up with a binary format that is portable, and allows
you to store the same kind of structures as you would express in XML
(trees of name-value pairs), [...]

Shawn Rutledge

2006-04-27 00:03:45 UTC

Post by John Cowan
In that case you might as well use ASN.1, which has the advantage of
being an international standard with multiple data representations
available (including a textual one). IMHO there is little point in
concocting yet another binary representation of XML.

What I don't like about ASN.1 is the data is not self-describing - you
need to specify a sort of schema or IDL which defines the parameters
in the messages, and then at runtime the assignment of actual
parameters to formal ones is positional, right? The design becomes
way too rigid and brittle - you can't add or remove parameters, or
give them in the wrong order, and you can't intercept a message and
decipher it without the schema. Maybe you could use it for simple
remote function calls though - let the Scheme function definition
drive the message format.

john

2006-04-27 11:20:01 UTC

With ASN.1 there is a separation between how the protocol is described and
how it is represented "on the wire". As the other John mentioned, depending
on application requirements you can choose different encoding techniques.
Ones like Basic Encoding Rules (BER) encode a "tag" structure together with
the values. Packed Encoding Rules (PER) attempts to send the minimum amount
of data so does not encode this structure. Although this concise encoding is
a little less flexible the values encoded may still be optional and you may
send them in any order if you use the right datatype.

John.

John Cowan

2006-04-27 11:53:55 UTC

Post by john
With ASN.1 there is a separation between how the protocol is described
and how it is represented "on the wire". As the other John mentioned,
depending on application requirements you can choose different encoding
techniques.

Yes. Thanks for making this clear.

Post by john
Ones like Basic Encoding Rules (BER) encode a "tag" structure together
with the values. Packed Encoding Rules (PER) attempts to send the
minimum amount of data so does not encode this structure. Although
this concise encoding is a little less flexible the values encoded
may still be optional and you may send them in any order if you use
the right datatype.

And now we also have XER (XML Encoding Rules), which are a defined way
of representing ASN.1 as XML. The reverse, encoding arbitrary XML as
ASN.1, is also extant, but not (the last time I looked) fully cooked as
an international standard yet.

I once suggested to a particularly persistent advocate of ASN.1 on the
xml-dev mailing list that he could PER-encode his emails by representing
the author as 0x01 and leaving the rest of the message to be inferred
by the recipient. Fortunately for me, he had a good sense of humor.

--
John Cowan ***@ccil.org http://www.ccil.org/~cowan
Is it not written, "That which is written, is written"?

F. Wittenberger

2006-04-26 11:13:21 UTC

No, Chicken does not have a VM.

If chicken has no VM, at least we two have fundamentally different
assumption how a VM is defined.

The VM of chicken is just neither a single data structure, nor (the even
worse definition) an executable interpreting some byte sequence. It's a
calling convention, threads data structure and a few global variables.

Post by Shawn Rutledge
IMO somebody needs to write a better editor for S-expressions. Good
XML editors are also nontrivial.

"Good" XML editors are impossible, because they have to serve mutually
contradictory goals. The only hope is to have a variety of adequate
editors with different purposes.

Too true. There are probably few things under the sun, which qualify
for GUI-Tool and not for editor. As soon as you bind them to their data
format, they become bitmap-editors, xml-editors, ini-editors, etc.
adding converters, what's the point of an XML-editor vs. S-expression
editor?

/Jörg

John Cowan

2006-04-27 11:46:13 UTC

Post by F. Wittenberger
The VM of chicken is just neither a single data structure, nor (the even
worse definition) an executable interpreting some byte sequence. It's a
calling convention, threads data structure and a few global variables.

That is to say that Chicken *itself* is a VM; but it is not *implemented*
using a VM, unless you want to say that C provides a VM -- which if you
do, don't let me stop you.

--
One Word to write them all, John Cowan <***@ccil.org>
One Access to find them, http://www.ccil.org/~cowan
One Excel to count them all,
And thus to Windows bind them. --Mike Champion

F. Wittenberger

2006-04-27 12:13:00 UTC

That is to say that Chicken *itself* is a VM; but it is not *implemented*

yes, I would call chicken the implementation of a vm, which executes
Scheme

Post by John Cowan
using a VM, unless you want to say that C provides a VM -- which if you
do, don't let me stop you.

Thomas Chust

2006-04-25 19:54:09 UTC

[...] Kali seems to be one of the most complete distributed Schemes
(even continuations can travel from one machine to another, and be
executed there) so doesn't that imply that it has a portable bytecode
and portable data structures? [...]

Hello,

as far as I know, the Scheme48 bytecode is portable across architectures,
yes.

But concerning the serialization especially of continuations in Kali:
Scheme48 is stack-based. Though, to reduce network load, Kali does not
transmit the entire stack for a continuation, but only the first few
frames. The rest is pulled if really needed via a mechanism pretty similar
to RScheme's persitent object store system, just via network. And I never
know whether I should consider this kind of page fault magic ingenious or
horrible. Especially in a network environment where additional
complicating factors like node failure resistance have to be considered...

cu,
Thomas

felix winkelmann

2006-04-26 06:12:12 UTC

There is no such thing as an ideal VM, unfortunately.

(and I don't think we need one - let Scheme be the VM)

cheers,
felix

F. Wittenberger

2006-04-26 10:53:57 UTC

Post by felix winkelmann

There is no such thing as an ideal VM, unfortunately.
(and I don't think we need one - let Scheme be the VM)

Scheme is pretty good as an _abstract_ VM (as opposed to a concrete and
never will be ideal VM). That's why I eventually settled on it for the
Askemos project.

IMHO the trick is to put the effort into serialiser/parser pairs mapping
from "lingua franka" to binary. Same plattforms may negotiate on binary
formats, while plattform changes pay the cost of translation for
compatibility. None is locked out.

Post by felix winkelmann
cheers,
felix
_______________________________________________
Chicken-users mailing list
http://lists.nongnu.org/mailman/listinfo/chicken-users

F. Wittenberger

2006-04-26 14:33:13 UTC

Post by F. Wittenberger

Post by Shawn Rutledge
http://blogs.zdnet.com/web2explorer/?p=166

So who was the first one? ;-)

Oh you guys started the trend?

Dunno. I don't care. Once upon a time I've been thinking whether the
term applies. Out there came the wiki entry we created (german):

http://askemos2.tc-mw.de/A849640f672ed0df0958abc0712110f3c/BetriebsSystem
Last modification: Thu Jun 21 23:57:02 2001
source forge registration 2001-10-02 10:56

In which level are the model objects then?

Application level.

Post by F. Wittenberger
Unfortunately the security experts insist for a reason, that you can't
build security into an insecure system, it has to be build in right from
the beginning.

actually I see quite some overlap, at the application level

Post by Shawn Rutledge
I
thought the Eros project sounded very interesting, mostly because of
the orthogonal persistence implementation. But the focus is the
capability security model, which is also interesting but probably
that's the only thing that will be accomplished, the way the project
is going now. What do you think of that? Seems to me it could work
pretty well in a system like this.

It's actually pretty close. However with I take several issues with it.
But as you said, security is of least concern to you, those are off
topic of sort.

1.: pre-system dawn capability distribution
2.: a "swiss number" is nothing but a clear text password

Also it's hard to see, why reachability and access should be identified.
I can imagine cases, where I want to hold a reference to an project,
even though it refuses to talk to me.

Eventually: how to you prevent manufacturing of pointers, if you
transfer them over the wire? You can with benign partner.

Post by F. Wittenberger
And that's more true, when the focus is legal processes. This *must* go
down to the system architecture or you'll loose all your development
work eventually.

Are you saying this about all possible software projects or just Askemos?

The problem is, that if there's a second person in your "reliance set",
you don't have true accountability. There's always another one, who
could have done it (whatever you are accused to). Facts derived such
software should never hold in the curt (except for the practical matter
that today many things are accepted, which should never have been).

To answer your question I need to distinguish between Askemos and BALL.

With Askemos I refer to the concept of a global virtual machine, which
is intrusion resistant (healing defunct part of certain percentage) and
incorruptible (no person can impersonate any other, i.e., no super user
concept, not even accidentally). Any rule system (computer executable
or not; think of games) may qualify to be "Askemos compliant".

BALL refers to one implementation of one such system.

Now: yes, I'm saying this about all possible software projects, which
don't qualify as Askemos-compliant. No, I'm not saying that BALL is the
only possible system.

Post by Shawn Rutledge
I don't know if a few humans can design a system so tamperproof as to
keep out the billions of other humans trying to tamper with it.

Not a few, but they did already. About 300 years ago.

And it's partially based on even older knowledge. Military this time,
the problem of the byzantine generals.

As a computer scientist it's not always you duty to invent something
new. Often it's better to model reality as close as possible.

What I refer to is (the theory of) our legal system. Since ethics
changed during enlightenment slightly, the legal starts out of equality
between humans. The limited truth of legally effective facts is defined
by some kind of common understanding. (This for instance invalidates
knowledge gained by torture before the judge.)

Post by Shawn Rutledge
It's
worth a try but I think security will have to keep evolving as
different methods get cracked.

OK, but that's a political issue: how do you crack the majority vote?
There seems some kind of answer though: ask Mr. B. reach him via italian
TV. ;-)

Post by Shawn Rutledge
The best methods that have been
envisioned don't even exist yet (like quantum computing). We'll see
if existing security architectures will adapt well to those new
methods over time.

There's one thing we need to aknowledge: legal security and (total)
secrecy are mutual exclusive. There needs to be a certain amount of
publication. And all sudden: you don't need better encryption, you need
crypto protocols to reach common knowledge in presence of attack.
Agreement that is.

Not too complicated.

XML transformation is yucky and inefficient IMO. My least favorite
language of all is XSLT.

yucky, hm, sorry, my english.

Inefficient, maybe. What exactly is inefficient about it?

Well, since I don't know what concrete syntax is, but think only in in
core tree structures: what's the difference between xml transformation
and S-expression transformation?

As for ball: yes, there is some xslt support. But not mandatory. For
me it's just a handy way to store some Scheme scripts and dispatch.

Post by F. Wittenberger
Yes and no. No, you don't want to trust any binary only data format.
Especially not, when it's a gziped memory dump. Furthermore there are

Wow it's even worse than I thought.

The tools ought to fit the purpose, doesn't it? Pointer swizzling at
page fault time can be even faster than reading plain files. It's
definately faster than parsing <insert you favorite portable format
here>. Use it as a cache and you know what the gain is! Don't put it
into your backup, it just doesn't belong there.

Post by Shawn Rutledge
What about hooking Scheme to a more stable, portable sort of OODB?

Great.

Post by Shawn Rutledge
What does RScheme do?

Compile to monotones C or to bytecode, both either on the fly or
offline. So in theory, that if some more smartness where build into the
compiler, it could be possible to schedule monotones as in a real time
operating system.

Post by Shawn Rutledge
portable, yet not as verbose as XML; and the assumption would be that

As I said before: the decision to go XML is at least for germany made by
the parliament. Who am I to go against it, just because I know this
would be technically better?

(((A man might be intelligent, mankind has yet to become so.)))

/Jörg

John Cowan

2006-04-27 12:17:47 UTC

Post by F. Wittenberger
Not a few, but they did already. About 300 years ago.
And it's partially based on even older knowledge. Military this time,
the problem of the byzantine generals.

The Byzantine Generals problem was invented by Leslie Lamport, a
computer scientist, in 1982 or shortly before that. See
http://research.microsoft.com/users/lamport/pubs/pubs.html#byz .

--
John Cowan http://www.ccil.org/~cowan ***@ccil.org
Be yourself. Especially do not feign a working knowledge of RDF where
no such knowledge exists. Neither be cynical about RELAX NG; for in
the face of all aridity and disenchantment in the world of markup,
James Clark is as perennial as the grass. --DeXiderata, Sean McGrath

F. Wittenberger

2006-04-28 07:48:25 UTC

Post by F. Wittenberger
Not a few, but they did already. About 300 years ago.
And it's partially based on even older knowledge. Military this time,
the problem of the byzantine generals.

The Byzantine Generals problem was invented by Leslie Lamport, a
computer scientist, in 1982 or shortly before that. See
http://research.microsoft.com/users/lamport/pubs/pubs.html#byz .

I don't recall how long this page
http://askemos2.tc-mw.de/A849640f672ed0df0958abc0712110f3c/ByzantineAgreement
refers to Leslie Lamports paper.

But if I understand the text behind the link correctly, that it claims

Post by John Cowan
There is a problem in distributed computing that is sometimes called
the Chinese Generals Problem,

...

Post by John Cowan
I stole the idea of the generals

...

Post by John Cowan
The main reason for writing this paper was to assign the new name
to the problem.

So, he correctly states that the problem was known before. In fact most
solutions we find these days are incremental improvements of prior
knowledge.

BTW: I'd be surprised if those 5000 year of chinese culture had been an
especially non-military time. And I'd bet, that the solution has been
know before. Messenger used to have a lower chance to get through than
UDP packets and forced-to-be soldiers are not exactly trustworthy.

/Jörg

Shawn Rutledge

2006-04-22 17:08:22 UTC

Post by Peter Bex
If anyone is interested: having a decent userfriendly Scheme CMS would
be *very* useful too :)

Yes as I mentioned, I wanted to build a wiki. But lately I've been
thinking that editing wiki-style text should just be one possible UI.
It's hard to say that the wiki syntax is a canonical way of storing
web content when nobody can even agree on that syntax (Alejandro's,
Felix's, MediaWiki etc. are all different). So I want to build an
object tree that represents a web page and store that, and dynamically
generate a wiki-like editing UI. Then an alternative UI could be a
Javascript one where you have wordprocessor-style controls rather than
having to use wiki syntax; and another would be a full GUI; etc.

I'm also thinking about how to do version control within the object
system rather than having to rely on external things like subversion
or whatever.

I may choose prometheus for the object system, but there are a couple
things I don't like about it. And then I have to tackle persistence.
I think I would like to just write something to a file that looks like
an assoc tree, but can be parsed back into an object structure. That
could stand a chance of outliving the particular object system.

F. Wittenberger

2006-04-22 17:48:10 UTC

Post by Peter Bex
If anyone is interested: having a decent userfriendly Scheme CMS would
be *very* useful too :)

OK, that's exactly the thinking behind the wiki style I included in
Askemos/BALL. I'd never store syntax, which is hardly readable in 200
years. It stores plain HTML (as parsed tree in the pstore module and
standard XML syntax in the file system) plus some XML for meta data,
lock handling etc.

You can edit HTML or wiki syntax. For that to work, the XML tree is
serialised in wiki syntax from the template. (
http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/template?template=source
This might loose information and be vary of round trip problems.) So
wiki syntax applies only on the UI. Otherwise: the law, you know, XML
(see previous posting regarding german JComG).

BTW: I do have a pointer around here, were a nice JS editor could turn
our text fields into a browser based editor. Yust nobody had the time
to care.

Post by Shawn Rutledge
I'm also thinking about how to do version control within the object
system rather than having to rely on external things like subversion
or whatever.

That's sort of a weak point of mine. We have one level backup copies
right now. It would be so easy to keep all versions. But I'd rather
have an ((S)XML) tree diff run over the data. With proper indentiation
this would be more effective on Scheme or XML as line-by-line diffs are.

So much for the dream. But where's the code? I don't have it.

Post by Shawn Rutledge
I may choose prometheus for the object system, but there are a couple
things I don't like about it. And then I have to tackle persistence.

I don't know much, if anything at all, about prometheus.

But I know the persistence feature of RScheme. (Frankly it has been
stressed hard by my own work. And gotten much better in response.) It
makes it so easy: anything reachable from a pivot object is persistent.
But it's waste for large objects. Much better on reads than parsing xml
from files. Writes depend on total size of the data base. Can be long.
No problem if used asynchronously.

Post by Shawn Rutledge
I think I would like to just write something to a file that looks like
an assoc tree, but can be parsed back into an object structure. That
could stand a chance of outliving the particular object system.

The other day I did somehting like that extending wt-tree from slib.
Now you can give an optional argument to make-wt-tree-type: an access
encapsulation for the actual objects. Now you can read the objects from
memory (as before), file system, Askemos whatever you like. Since
that's pretty new and under testing, it's not yet fed back to slib, but
only in askemos tar ball.

Thomas Chust

2006-04-22 18:40:41 UTC

Post by Peter Bex
[...]
I think the hardest thing will be the ActiveRecord-like support since
Scheme isn't especially object-oriented. The question is whether
that is really required. The most important aspect about Rails is that
it has decent defaults. You can just build a database and run Rake
to set up a Rails environment and you have a bare-bones interface to
the database out of the box. To do things, you need the very minimum
of custom code. This is the essence of what makes Rails so popular.
I'm not sure if this can be done as easily in a non-object-oriented
environment. Ruby makes it easy to automatically build objects from
information because it allows you to add members to existing classes.
I think with the Prometheus egg we could do something like this.
[...]

Hello,

I don't know exactly what you would expect from a runtime object <->
database row interface, but I can't imagine that it requires a lot of
effort to create something simple that gets the job done -- no matter
which object system is used.

A small example using TinyCLOS and SQLite3 is attached. It does runtime
generation of classes and accessor methods completely automatically from
the database schema and is terribly easy to use because I didn't have the
time to make up something sophisticated. The code allows you to write
something like this:

;;; load extensions
(require-extension
sqlite3 tinyclos sqlite3-tinyclos)

;;; create a database
(define db
(sqlite3:open "test.db"))

(sqlite3:exec db #<<EOD
CREATE TABLE eggs(name TEXT NOT NULL,
license TEXT, is_module INTEGER NOT NULL DEFAULT 0,
PRIMARY KEY(name), CHECK(is_module IN (0, 1)));
EOD
)

;;; define the object class
(sqlite3:define-stored-object-class db "eggs")

;;; add some data
(let ((egg (make <egg> "sqlite3")))
;; now the entry should already exist
(print (sqlite3:in-store? egg))
;; let's add some data
(set-license! egg "BSD")
;; and read it back
(print (license egg))
;; other fields are filled with default data
(print (module? egg))
;; changing the primary key is possible as well
(sqlite3:set-pk! egg "foo")
(print (sqlite3:pk egg))
;; which does not change data, of course
(print (license egg))
;; and we can also delete the entry
(print (sqlite3:remove-from-store! egg))
;; then it is gone
(print (sqlite3:in-store? egg)))

;; close database connection
(sqlite3:finalize! db)

cu,
Thomas

Thomas Chust

2006-04-22 18:58:44 UTC

Post by Thomas Chust
[...]
A small example using TinyCLOS and SQLite3 is attached. It does runtime
generation of classes and accessor methods completely automatically from the
database schema and is terribly easy to use because I didn't have the time to
make up something sophisticated.
[...]

Oops, I just found some parameter handling mistakes in my quick hack that
would break it with more "advanced" usage. Here is a better version.

cu,
Thomas

PeterBex

2006-04-22 19:05:59 UTC

Post by Thomas Chust
Hello,
I don't know exactly what you would expect from a runtime object <->
database row interface, but I can't imagine that it requires a lot of
effort to create something simple that gets the job done -- no matter
which object system is used.
A small example using TinyCLOS and SQLite3 is attached. It does runtime
generation of classes and accessor methods completely automatically from
the database schema and is terribly easy to use because I didn't have the
time to make up something sophisticated.

Bravo! This is just beautiful! Quickly - make an egg out of it :)

Regards,
Peter

Thomas Chust

2006-04-22 22:47:22 UTC

Post by PeterBex

Post by Thomas Chust
[...]
A small example using TinyCLOS and SQLite3 is attached. It does runtime
generation of classes and accessor methods completely automatically from
the database schema and is terribly easy to use because I didn't have the
time to make up something sophisticated.

Bravo! This is just beautiful! Quickly - make an egg out of it :)
[...]

Hello Peter,

I'm happy and a bit surprised that you like it. But maybe this code is
really more useful than I thought. Anyway, you asked for it, so here is
the egg:
* documentation only
http://www.chust.org/projects/sqlite3-tinyclos.html
* installable bundle
http://www.chust.org/projects/sqlite3-tinyclos.egg
* subversion repository
svn co https://secure.afc.no-ip.info/svn/chicken-eggs/sqlite3-tinyclos

Writing the documentation took a little, so it wasn't exactly very quick
;-)

cu,
Thomas

Reed Sheridan

2006-04-22 15:29:57 UTC

Subject: Re: [Chicken-users] rails-like framework
Content-Type: text/plain; charset="us-ascii"

Post by Peter Busser
Hi!

IMHO it would be better to make it easy to integrate, but seperate from
Spiffy. There are people who do not want to or who cannot use Spiffy.
They would not benefit from such a framework.
For instance, in many companies, it is mandatory to use something like
Apache. It would be useful if this framework would work with the SCGI

egg,

Post by Peter Busser
so it can be integrated with Apache through the mod-scgi module for

Apache.
I agree fully. This is the approach Rails takes too: It allows you to
choose from CGI or FCGI with an arbitrary webserver or Ruby Webrick for
quick 'n dirty testing. (Webrick isn't as scalable as "big" webservers
like Apache or Lighttpd and I imagine Spiffy is not much better)

I've written something (or rather, mutated Gauche's CGI module into
something) that allows you to choose CGI or FCGI (and soon, SCGI).

http://simonio.us/cgi-bin/darcsweb.cgi?r=public;a=tree;f=/gateway-interface

I suppose that it could support Spiffy too. But you might have to give up
some of the advantages that Spiffy gives you. I haven't really used Spiffy
enough to understand the issues at hand.

I don't consider it quite release-worthy yet, but I hope to rectify that in
the next week or two.

Reed Sheridan

Reed Sheridan

2006-04-22 15:56:30 UTC

Subject: Re: [Chicken-users] rails-like framework

Yeah... things like Rails are community / investment phenomena. Success

breeds success. If you want Rails, go use Rails. The Lisp world has
some mature web relevant things, but I'm not up on 'em. Inquire in
comp.lang.lisp.

But then you'd have to use Ruby or Common Lisp. Ugh. Not in my spare time.

Reed Sheridan

Luther Huffman

2006-04-24 23:02:13 UTC

Sorry if its been mentioned in this thread already (I haven't seen it)
but speaking of Ed Watkeys, he's been working on a scheme-based rails
equivalent called "Magic". It's written in Scheme48, however, not
Chicken.

http://magic.xmog.com/

Post by Toby Butzon
Anybody know of a Chicken-compatible Ruby on Rails workalike?
I know Ed Watkeys posted something about the URL mapping part, but is
there anything close to a full framework?

Luther Huffman

2006-04-25 09:15:09 UTC