Re: [Chicken-users] simple threading
Hi Felix, I've been contemplating...could chicken include some basic support for native thread communication? rscheme has these C functions void rscheme_intr_call0( obj thunk ); void rscheme_intr_call1( obj proc, obj arg ); void rscheme_intr_call2( obj proc, obj arg1, obj arg2 ); which basically enqueue a "virtual" signal, which is then processed similar to system level signals. BTW: I feel that it might be safer/easier and just enough to provide only the first (thunk) version. Am Freitag, den 16.06.2006, 15:28 -0400 schrieb John Cowan: Matthew David Parker scripsit: > > > Does anyone know a clever solution to my problem? > > What you need is OS-level threads (not Chicken-level threads or > OS-level > processes), but Chicken does not support them. It's possible that > you > could invoke an OS-specific threading package to create such > threads, > though they wouldn't be able to run Chicken code AFAICT, only C > code. > > (felix?) > ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] simple threading
Am Samstag, den 17.06.2006, 23:35 +0200 schrieb felix winkelmann: On 6/17/06, Joerg F. Wittenberger <[EMAIL PROTECTED]> wrote: > > Hi Felix, > > > > I've been contemplating...could chicken include some basic support > > for > > native thread communication? > > > > rscheme has these C functions > > > > void rscheme_intr_call0( obj thunk ); > > void rscheme_intr_call1( obj proc, obj arg ); > > void rscheme_intr_call2( obj proc, obj arg1, obj arg2 ); > > > > which basically enqueue a "virtual" signal, which is then > > processed > > similar to system level signals. > > > > BTW: I feel that it might be safer/easier and just enough to > > provide > > only the first (thunk) version. > > > > Not a bad idea... What should this do in particular? > Short answer: schedule thunk/proc for execution at the Scheme side. Whatever that means for the Scheme runtime system. Long answer: ... (straight&unchecked from my weak brain; we had a good party tonight; I just got up; sorry if the rest doesn't make too much sense :-/ ) I recall rscheme maintaining some event system (queue? no memories). A select loop controls time slices and async i/o. C signals are queued (by default) and this select loop will eventually call registered handlers on the queued signal. Now rscheme_intr_call0 puts a virtual signal into the queue and the handler will just call (thunk) in the appropriate context, i.e. from the thread running the whole Scheme side, not the second native thread. The "most users will..."-lie: most users will associate the *_call0 with some native<->Scheme communication channel and protect with semaphore. So the following protocol applies (assuming pthread being the native thread system): Native side: pthread_lock_sema(scheme_sema); my_channel->data=result; _intr_call0(my_channel->thunk); Scheme (application level) side: (let ((result (my-channel-data))) (unlock-scheme-sema) result) For the chicken system, I could imagine that chicken_intr_call0 would just create a thread to execute thunk and register that with the scheduler. I'm not sure why there should be some queue system. best regards /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] R6RS immutable pair
On Jul 2, 2006, at 20:00 AM, Ken wrote:
> > Is the decision to drop set-c*r! final in R6RS?
> No. The editors are considering it & they want considered feedback
> from the community. I think compiler writers should talk about the
> real gains to be had from immutable pairs. We can take as given the
> answer from regular Scheme programmers.
Here my experience. Full text (formated and linked) at
http://www.askemos.org/A92529c85ccc348aae277522d6d5b801e/mutable-pairs-position.html
= Position Statement on Mutability of Pairs =
Joerg F. Wittenberger
In response to R6RS status report as of june 2006 I'd like to add my
experience concerning section 5, on the mutability of pairs.
Summary
Non-mutability of pairs (i.e. all objects) creates a very different
language than traditional Scheme. Such a setting allows to practically
fulfil semantics of program execution and distributed shared state
beyond feasibility on the basis of a arbitrary mutable store.
I'm personally divided myself whether such a radical change should be
made to the Scheme language. Having made first hand experience with
the implementation of a side effect free dialect of Scheme and on the
background of the reasoning, which lead to the Askemos project, I
value the advantages of controlled mutability. However there is just
too much good Scheme code out there, which should not be broken by
radical language changes.
Wouldn't it be better to add a new data type for those immutable
pairs?
== In Detail ==
=== A Fictional Task ===
An international company has 5 owners from all over the world. Used to
electronic cooperation as they are they want to elect their CEO online
as well. A lack of trust make it difficult to decide whom of them
should host the polling system.
=== Proposed Solution ===
The problem is solved by by hosting the polling system on all five
interested sites simultaneously. The language system stores a copy of
the programs continuation, in the example the polls counter, on each
site. Each vote is counted at each site by this continuation. However
execution is synchronised in byzantine agreement. Now, until three of
those five partners collaborate there's no doubt about the result. But
that's the point of an election anyway.
So the aim is to design a language, which can implement justiciable
processes. (For more (german) background see Rechtssicherheit im Netz
(course of studies at HTWK Leipzig).
The implementer is left with the problem that each mutation to the
shared state has to be agreed. Thus speed of light limits what's
feasible. Here immutable objects become advantageous.
We escaped the problem by dedicating a kind of a coarse Scheme dialect
to control persistent, replicated effects. These are intercepted by
the agreement system. Another side effect free subset of Scheme is
used to query the store and produce proposed modifications for the
persistent part.
For the programmer this boils down to implement two programs, the
query part:
(lambda (this request) ) =>response
and the proposal of the new state:
(lambda (this request) ) =>(values proposal digest).
The proposal is (kind of a) Scheme program, which describes the
(locally) proposed changes to the persistent state (i.e., the new
continuation and variable assignments) and the final response of the
transaction. However before the proposal is actually executed on all
sites, byzantine agreement is sought on the cryptographic digest
[something like (sha1-digest (with-output-to-string (lambda() (write
proposal].
Since never effects the store, complex computations can be done
efficiently. Smart application design means in this context to require
only a small number of persistent (distributed) transactions per user
request. This makes the delay from the agreement protocol negotiable
in exchange for the "tamper proofed backup system".
(The coarse grained language, being slow by design anyway, does
slightly more: some meta data usually interesting in dispute, like
date of creation and check sums to verify content integrity are
maintained. Furthermore the runtime system provides a super user free
permission management system. Eventually there's a resynchronisation
protocol. But that's off topic here. For details see the white paper.)
== Final Note ==
I hope I could demonstrate good reasons to have a standardised side
effect free Scheme subset. Such a language can be used to encode
processes defined by legally binding contracts in machine executable,
tamper proofed way. But I'm not sure that this radical change should
go into R6RS at the expense of breaking compatibility. Due to these
concerns I'd rather vote for an optional language feature or a
distinct data type.
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: Writing Linux kernel code in Scheme?
does this one help: http://www.abstractnonsense.com/schemix/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Coming to Scheme from Python.
Steve Freitas wrote: > I wonder if there's been any movement on porting Termite from Gambit > to Chicken. If you're willing to cast your problem in an > Erlang-style light, that could make for very high multicore > performance indeed. Just spawn some child processes and start > tossin' your functions at them. Porting Termite will not exactly help here. Termite (on gambit) allows you to manually transfer objects from host to host, where host is a OS process. On multicore machines you still have to run one host per processor. Then you would be left with *manually* controlling object transfer and distribution. Gambit-C, chicken, rscheme (I don't know about Java???) and many other user level threading systems simly share the problem: user mode threads are fast, but don't scale with multiple cores. Usually that's a memory management issue (Felix should know) which doesn't go away by any amount of code in the language. Needed is a n:m mapping from user level threads to system threads running the chicken VM (runtime). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Coming to Scheme from Python.
Steve Freitas wrote: > On Thu, 2006-09-21 at 11:14 +0200, Joerg F. Wittenberger wrote: > > Porting Termite will not exactly help here. Termite (on gambit) > > allows you to manually transfer objects from host to host, where > host > > is a OS process. On multicore machines you still have to run one > host > > per processor. Then you would be left with *manually* controlling > > object transfer and distribution. > > With a threading system, you're still, at some point in your code, > *manually* firing off new threads, so it's different work, not > necessarily more. Oh, I see your point. I assumed you'd expect your Scheduler to assign the processor automatically to your threads. > > Gambit-C, chicken, rscheme (I don't know about Java???) and many > > other > > user level threading systems simly share the problem: user mode > > threads are fast, but don't scale with multiple cores. > > And that's why something like Termite makes so much sense. When you > institute immutables, and copy by value on function arguments, it > makes > it easy to scale with multiple cores since you've eliminated most > potential concurrency bugs. So you run one host per core, and dispatch > the work. Have you look at Termite's syntax? It makes such things > very, > very easy. You are true, that's exactly our experience. I, personally, decided a few years back that I do not like to have to care for even thread creation, mutal exclusion, dead locks etc. That's why I came to write an Erlang-inspired (message passing) environment with Scheme as application programming language: Askemos. In contrast to Termite we do not (yet) have pattern matching on the incoming queue (for some other reasons related to possibly different message orders at hosts, that's an unresolved theoretical issue). Also I did not know how to serialize a full continuation (as gambit does), that's why I tricked users to supply them at application level. In other areas Askemos is more mature than Termite: it doesn't hide in some docs that users are supposed not to use side effects (like set-car!), it just doesn't support them (on application level). And eventually the highlight: it's the only environment I'm aware of, which runs it's in virtual synchrony (byzantine agreement) at several hosts at once. Hence there's no single point of failure in the p2p network, reason: legal liability; Askemos was designed to be impervious to intentional insider attacs. In fact, if one of the hosts behind www.askemos.org is cut of the net, our programmers will not even notice while they continue their work. Ah, you where asking for chicken: once I started a port in 2003. RScheme is not so different, except for the FFI and internals, but we stuck close to R5RS where possible anyway. Than we ran into performance and UTF8 issues and had to abandon the port in favor of featuritis. > > > Usually that's > > a memory management issue (Felix should know) which doesn't go away > > by > > any amount of code in the language. Needed is a n:m mapping from > > user > > level threads to system threads running the chicken VM (runtime). > > If I'm understanding your suggested n:m mapping correctly, then > Termite > makes it really simple to establish what you're asking for. Not at all. I'm asking for some way to assing Scheme threads to a processor *without* moving the thread out of the process where they where startet. The Askemos implementation we have today uses lots of threads for short activities (since they are cheap). If I wanted to run them on multiple cores, there should be close to zero effort to migrate threads among processors and they should still share e.g. mailboxes with other threads on other cores. However I understand that fast user level threads and multicore scaling looks currently like conflicting goals. I would *not* vote to pay on the thread system side. Instead close assesment of application needs will probably reveal better ways of multicore scaling. Example: Askemos runs it's byzantine agreement over HTTPS (huge waste, I know). We made the SSL layer into an extra executable, thus chances are that the kernel will put the memory hungry server on one core and those SSL proxies on others. best regards /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: Re: Re: [Chicken-users] performance issue in xml-rpc
> So, it looks like the top two time-consuming procedures are > read-request and SSAX:XML->SXML. The third is probably > http:read-request-attributes. > > Any comments? > Maybe, I would need to look into the chicken source code. Probably you need to. My experience from Askemos [www.askemos.org] implementation: parsing and serializing should be optimised at all cost except for concurrency. I'd personally love to port Askemos/BALL to chicken and that's why I'm lurking here. (To save reading about Askemos: it's technically STM on P2P in Scheme. Users see a byzantine replicated programming environment similar to Termite.) There are a few things why my code is currently pretty tied to RScheme and not easily portable to chicken+spiffy even though I did my best to stick to R5RS. (E.g.: I did not use the RScheme object system no matter how tempting it was.): * C code in parsing and serializing XML * new data type for XML (performance and transparancy issues with SXML) So if you care for performance, optimization here will buy you much more than anything else (like compiler choice). The BALL code base brings up age old bug in rscheme, I'm afraid it would do so with chicken too. I have to make my living too, I just don't have time to help on this one. /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] anyone have a Playstation 3 ?
> On Dec 25, 2006, at 10:10 PM, John Cowan wrote: > > > Shawn Rutledge scripsit: > > > >> What other kinds of constructs can you imagine in Scheme for > >> parallel > >> execution, which would work better than threads? > > > > Communicating sequential processes (CSP) would be the obvious > > candidate. > > All the pieces for a Chicken Termite are in place: > > match-action egg > mailbox egg (w/ timeout & cursor) > Thomas Chust's rpc egg > logging egg > remote-launch egg Even more: www.askemos.org has a slightly out of date chicken tarball. That one already served non-mutating requests before. Background: - we plan to go multi plattform anyway, but it takes time - the chicken based dev version is stalled for performance reasons (at chicken version 0.something) - Askemos/BALL is slightly more advanced at the application level (e.g. we don't ask in the manual to stay away from side effects, we avoid them in the interpreter); otherwise it's highly simillar - it doesn't have message matching (at application level) since it's are completely unclear how this could interfer with the synchronisation protocol - it has a byzantine sync protocol, there is global shared state (sort of "software transactional memory") over a quorum of hosts (the quorum is a per object property) - the shared state is beyond the exclusive control of individual machines (required for tamper proof processes like electronic contracts, where Askemos is currently the only know option which actually works) - porting requires mostly pulling eggs (is there something like libmagic and iconv?), convert FFI and some C in parsing and serialising - we would have done it long ago, we just don't have the time. Money will probably bring us even a Java version before the chicken port even though the Java port will be much more than a few weeks. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Brandon Van Every wrote: > Matthew Welland wrote: > > I'd suggest going one step further and striving to keep the scheme > > portion not too chicken specific. Other schemes would only have to > > provide the interface layer and the bulk of the code could be > > reused. > > > > From a support and community growth standpoint, I see no value in > projects that try to be all things to all Schemes. Doing things > well on Chicken is what's important. Also, reuse doesn't mean > anything without people and interest. I'm not sure you are right here, Brandon. The people and interest are there. Just some of them will not jump on the chicken/gui ship when it's chicken specific - as they refuse to jump on those other PLT or whatever specific ships even though they seriously lack an viable alternative. So adding one more ship will extends the set of options I'm *not* taking anyway. For me this boild down to accepting strange restrictions (besides coding R5RS(subset) whenever possible): I, for one, arrived at a certain user interface methodology. At model level I insist not to add anything UI specific. But I allow some generic call back registry for update events (the well known MVC model approach). At the edit level, either give me a graphical editor to try out, or some declarative syntax, be it Scheme or whatever. No more than 20 pages documentation. For persistant storage and data exchange I insist at some automatic transformation between hand written source and XML (both ways, round trip safe at source level) at least for the model data, preferably for the call back registry too. Why? I want to care about structure; rendering the structure to valid HTML/XML/SVG/PDF etc. should be negotiated and performed by some magic in my programming environment. I just don't want to see it in my code. Also, nobody likes XML, but still that's the least common denominator to stay for long, long time. And it's well known how to programmatically modify it without resorting to characterwise processing. For display, push some kind of update description from model towards the renderer. There's probably some stack of backend specific layers between the model and the actual renderer. Preferably: put a network connection somewhere in this stack. This network transparency is often handy. If it comes into the way (say for games), just bypass it in memory. If this sound like HTML/XML/JavaScript and gecko, it's not too far off. That's how we do it most of the time. Just a little less of footprint would be great! And maybe a nicer syntax. But the latter is about taste and I don't want to argue about that one. Also http://haxe.org/ is on my radar in this context. Furthermore: this path readily allows for terminal based alternative user interfaces, e.g. for disabled people or small devices. All without changing the toolkit. However a JavaScript dependancy might look strange to people, who value security. (At CCC, we just got demonstrated for how long we'll expect man-in-the-middle holes) So I don't want to see JS in the source code. It's ok, if generated (so an alternative solution can replace it entirely whithout me touching my code). Still there ought to be the mentioned alternative. The fast path is "web 1.5" - a term I coined for "web 2.0 sans JavaScript": full page update, all POST's redirected back to the sending page (keeps the backbutton working), all state at the server. Again: hide these aspects from my UI source code. Advantages: works immediately als terminal alternative. Works with same usability for JS-disabled browsers (root users). Disadvantage[*]: just close to a GUI but it isn't. The GUI alternative: hm, there've been Matthew's and other good proposals. End goal: SRFI, not less! Render, say SVG (or subset) [great, we get graphical GUI editors for free] plus some additional basic widgets, about the Java AWT set, but if possible, more declarative. Automatic element positioning. Allow to attach callbacks (closures) to events. React to update events. Period. No-no's: convey internal data from renderer to controler; "turtle graphic" where you (...define a font, a brush, a second brush, a cursor shape a cursor bit mask, select them into the drawing context, remember to do so in the correct order, strike a path, close it, fill it...). I guess, the best thing to start with, was to agree on some "least common denominator" GUI description syntax. This would allow to exchange the underlying implementation. Looks like a Schemeish way to me. ;-) Just my two cent. /Joerg Footnote: [*] you may wonder why I did not mention "network load" under those disadvantages. After all AJAX was conceived because of that bottle neck. I did not, because "web 1.5" was invented a context like X Windows, where is a "deployment mistake" to put WAN connections between server and client. Said context replaces servers of traditional web setups alltogether with peer to peer networks. Hence most work of the
Re: [Chicken-users] cross-platform gui toolkit
Brandon Van Every wrote: > > Chicken wouldn't have half the eggs it does if the non-Chicken > > Scheme community had taken that position. Fortunately for us, > > they did not. > > Which half? My world is OpenGL and C FFIs. I don't see any > interloper eggs helping out here. It's one thing if your task is pure > Scheme, quite another if your task is OS interfacing. Brandon, please don't take things personal. Don't downplay others contributions just because you don't know yet where you might need them. > > I'm not sure you are right here, Brandon. The people and interest are > > there. Just some of them will not jump on the chicken/gui ship when > > it's chicken specific - as they refuse to jump on those other PLT or > > whatever specific ships even though they seriously lack an viable > > alternative. > > > You can of course post an abstract GUI project to comp.lang.scheme and > see what takers you get. But from a practical standpoint, you're in > serious danger of design by committee. :-) If I would bother so much, maybe I would do. > Or a bunch of people talking and no action. But I'm not doing this for the fun of it. I'm forced to think economical too. There's a project, a design, a market need, obstacles, challenges, actual and potential resources. I'm on action for several years now. Slowly, sure, but eventually not without success. (I just hired a first employee for Scheme programming - ok wrt. "no action", thank you.) A good GUI toolkit is such a resource. But I don't have the time or money to write something up, just to see what I can eventually use it for. So let me tell you something: a chicken specific gui toolkit, which somehow wraps opengl and that it - that's something I don't have time for. > It would make a lot more sense to get it done in Chicken with a few > people, show it to the world, and show that it's actually good. > Then refactor whatever is Chicken specific about it, if you can > draft up the labor for ports. However I still have so much time for it, that I might spend half an hour or more to write up my requirement for those, who might pick the project up anyway. Not because I'm ready to fight with them over their design. They might care or ignore my notes entirely. If they ignore my requirements however, there is little chance that, once they show their work to world, they will meet my needs. If it fails, like those toolkits before, I'll ignore their work as much as they ignored my requirements. (Hey, I can live without M$-Windows - because it fails my requirements - I'll come over yet another gui toolkit to forget.) However I've got the feeling that there where some persons, who listened, who - at least partially - agreed with my concerns. Look, Brandon: long ago, when there was no chicken Scheme, I choose a pretty nice Scheme for the feature set it had: multithreaded, asynchronous i/o, persistant data, compile to C. (Before than, I used bigloo for my work.) Then I went on to actually read the source and had a look at it's community to find out how good I could support my compiler without the original author (hey, he could be run over by a bus the next day), before I based a business case on it. A little more community would have been a plus, but as things where, it was ok. The I coded. I tried to abstain from anything not looking like R5RS+SRFI (except when there was real - i.e. economic - pressure). I ignored a nice object system. I reimplemented few features to avoid dependancies. I ignored a huge amount of code (DNS, PDF, database integration, font metrics, X11 integration spring to mind), which all where very tempting to just reuse (and add sexy features). All because - by design - I'm not going to produce a rscheme specific result. Nevertheless - as I said economic pressure - a few things crept in, like FFI related code, few finalization issues, and eval/sandbox API questions, SSL etc. which keep the result system specific for the moment. (Currently the incompatibilities with chicken+eggs appear to boil down mostly to API differences, not feature sets anymore; some changes to our code base are just motivated to use chicken's APIs.) See: been there, done that. For economical reasons, we'll be able to shell out money for porting Askemos to Java. Otherwise I'll take the freedom to wait and help for more and more pieces of the work we have put into Askemos beeing doublicated for other Schemes. I'm not agry about that. Maybe a bit sad, because it's taking longer that way. The advantage for me: there'll be others who will be asked to fix their bugs. ;-) I'm desperately *and* paitiently waiting for the moment, when, eventually, there will be enough eggs to port Askemos in a few days, cutting off most of my code. Zero code sharing between hosts is what I call a "heterogenous network" and that's what Askemos is going to become - by definition. Schemers don't share code! (Except if doing so
[Chicken-users] cello? cross-platform gui toolkit
I'm afraid I'm sold. I just read about cells and http://common-lisp.net/project/cells-gtk/ (haven't heard about it before). To me this looks like a usable way to write (G)UI's. So whatever the underlying toolkit will be (and how inclomplete the implementation to start with), I'd vote for something like this http://common-lisp.net/project/cells-gtk/cgtk-primer.html as the syntax and style, I shall edit. Well, maybe we could drop a few of those "mk-" prefixes (as is "mk-vbox", "mk-radio-button" etc.). But probably I'm sold because I'm biased anyway. Could someone please tell me, what the difference between cells, termite and askemos is? (except maybe for persistance or safety; from cell-doc.lisp, which I just have open): take a system from time T to time T+1 smoothly versus http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/ProcessStep http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/AskemosDVM Looks just like different wording, to me. Anything substancial I'm missing? regards /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cello? cross-platform gui toolkit
scwm - I recall vaguely. Kon Wrote: > > But probably I'm sold because I'm biased anyway. Could someone > > please > > tell me, what the difference between cells, termite and askemos is? > > Cells is a constraint propagation system for CLOS (spreadsheet-style > programming). Termite is Erlang in Scheme. Askemos is a trusted/ > reliable distributed computing framework. Only Termite & Askemos > could be considered in a similar category. Except that - it struck me, when I read this cell stuff. Because there's exactly the same mechanism to propagate updates. When I compare them, I don't compare so much on the category or purpose. I compare the computational model. This is the same for cells, FPGA's, spreadsheets, Termite, Erlang, iO (http://www.iolanguage.com) and whatnot. Cells/Objects carry properties, updates tightly controlled, messages propagate updates, data flow driven (in a way at least). I ways simillarities don't surprise me: a) Michael Haard once (~94) wrote a spreadsheet called "teapot". At my request he added some capability to compute "stepwise updates". We wrote a game of life with it. Why my request? I've been busy at that time experimenting with FPGA's. I wanted some modelling tool. b) That FPGS's experience had a lot of influence at the Askemos design (because I had learned that it allows to parallelise algorithms up to the point that a matrix multiplication on a stream can be done at O(1) amortised time). So no wonder that this cellular structure persisted. c) One of my early experiments where done using FramerD. What I've been missing there was the ability to put slot-updates under formula control. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Brandon J. Van Every wrote: > Crazy Eddie's GUI System > http://www.cegui.org.uk/wiki/index.php/Main_Page is worth looking at > in this regard. It is a C++ toolkit, skinnable, MIT licensed, and has > survived as the preferred GUI of the Ogre3D engine. Ogre3D ain't > small potatoes. This means CEGUI has community resources that most > open source projects lack. When I say "look at it," I mean for design > inspiration, since it's a successful system. I think C++ wrapping > projects are currently hard in Chicken, so I've been leery of chasing > anyone's C++ development. Not bad! And give some inspiration. I'd ignore "C++ wrapping" is currently hard in Chicken. It could be solved rather easily for this particular (and simillar) case(s). What I would do: 1. Nag Felix, the poor guy - until he adds (that is finishes, as I recall) an interface to call Chicken from POSIX threads. Maybe that's even possible already, but I don't think so. Is it? 2. Start two POSIX threads. One running Crazy Eddie plus a some C++ "driver" code talking to the other POSIX thread running Chicken, where it's a different job to dispatch events to whatever chicken thread. I like CE's XML way of specifying GUI layouts. Fit's pretty well with SXML on the Scheme side. It should not be too hard to deploy the ResourceProvider mechanism of CE to fetch the XML in core from Chicken. Also Input gathering ougth to be done here per default (though for the sake of game developers optionally). This must not preclude event injection from the Scheme side. 3. At the Scheme side, *I* would (I told you in the other mail that I'm sold already) base the interface at this cell-gtk syntax (with modifications like dropping "mk-" prefixes. I'd consider to modify the language: compare to CE's syntax and unify or alias what maps. 3b. Do these cells very general, Scheme way of doing things. If this becomes a SRFI of it's own, not bad but also not nessesary. 4. While doing 2 and 3 in parallel, have a look aside to the cell-gtk LISP code. Eventually, that is once 3 is sort of stable (beta), throw some alternate GTK bindings underneath the syntax of 3. 4b. Having two bindings, some KDE guy will probably sit down and create an alternative to the CE thread, driving KDE. 5. Write two SRFI's about (1) and (3). (3) will need some system support impossible with pure Scheme - the graphics side. But there where several bindings at this time already. And the conversation between Scheme and the GUI system is by now broken down to a thread-thread communication, which could be done via ports for the SRFI, while we don't have an extra interpreter and pipes for the "real thing" of an implementation. 6. Have a lot fun with the result. And don't mind if the SRFI takes years to adoption. /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cool 3d logo by Joshua Griffith
> Alejo wrote: > > > On 2/20/07, Alejandro Forero Cuervo <[EMAIL PROTECTED]> wrote: > > > > > >Can you specify what you mean by 'a Page Index'? > > > > > >A list with the names of absolutely all pages in the wiki, sorted > > >alphabetically? > > > > > > > Yes. > > I'd be inclined to believe such functionality should -not- be > provided by a wiki system. Me too. However something similar should be there. Once I thought a wiki is something like a mind map. So the link structure should be available somehow. For the (minimalistic) wiki I wrote for askemos, a page is generated, which depicts the context of the page. That is those pages linked from the current page, those linking to the current page and for each of those (linked and linking) pages the next "generation" linked/linking pages. Example: http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/PHP?template=context Here this is presented as a simple table, where the "current" page would be right in the middle. Two columns right and left. Still this can easily get out of control: http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/XML?template=context What I always wanted to do, but never got around to actually implement, was using graphviz http://www.graphviz.org/ or alike to draw that as an SVG with links to the pages... but I'd love it. Nevertheless, for a wiki, I believe, the picture should always be cut down around a "focus page". /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Chicken manual in Texinfo format
Adhi Hargo wrote: > --- Alejandro Forero Cuervo <[EMAIL PROTECTED]> > wrote: > > > It's best to keep the authoritative version of the manual in wiki > > format instead of Texinfo. I think this makes it easier for most > > to contribute to it. I also think a Texinfo version should be > > generated from it. [...] > apply the right tag. in the long run, wiki->texi > conversion loses a lot more semantic information than > the other way around, so much so that wiki != quality > reference. > > *But* I agree, that the main focus should be ease of > contribution. My 0.02 cent, for what it's worth to consider. a) Taking the ease of contribution argument one step further: I have always seen wiki syntax as kind of a non-authoritative visual respresentation intented for a certain editing task. (Because I've never been able to decide upfront, which wiki syntax I like most, since each of them has it's merits.) So most of the time I - as an authro - would like to choose the syntax I'm most familar with...which implies that the abstract contributer needs to be able to choose the syntax per edit session, not per page and upon page creation time (for all future contributers and contribution). b) Data formats, if not strictly defined and widely deployed (in different applications), have a tendency to develop over time. Eventually you end up like "word": backward compatible for about one version and a half. Prepare to keep converting you old documents! c) Therefore I'd always recomment to *store* some strictly checked format, while serializing to the fashion-of-the-day, human readably syntax in the very moment of delivery for edit/display. d) Example: Long ago (in '96 cvs said) I wrote "sdc" (Sgml Document Comipler) in Scheme (bigloo). Using James Clarks nsgmls parser it converts SGML into a lazy evaluated stream of tag events and applies stream operators from a template in a way very simillar to sxml-tool's prep-post-order tree traversal. This saved my day. I could type in my own SGML syntax (oh boy, I *loved* those data tag and minimization features) patterned after LaTeX documents. Sdc would convert that via latex or lout into postscript, into gnu info files (directly in scheme, no texinfo involved), man pages and html. It did the indexing and cross referencing. And it did even allow me to mix my prefered table syntax (roff) with lout graphics and LaTeX formulars in one SGML source file. (For reference http://login.softeyes.net/jfw/CC/sdc.tar.gz ) But the advantage of that approach: I always knew the "way out": dump the tag stream in simple SGML (which later got the name XML) and read that in whatever tool I'll ever like. (BTW: sdc was not that bad of a deal for me: once I've been asked "we have this huge amount of GML documents at that IBM Host machine and we want to get rid of the 1M bugs a year it costs us. sdc got a new frontend and a specialized style sheet. Now they have docbook.) So I'd recomment to enfore strict checks on canonicalized wiki content. Store that as S-Expressions or XML, no fancy parsers. Hint: the canonicalization process could add sensible defaults for mandatory items to give the user an idea, what to complete/change. The Askemos website works that way too. http://www.askemos.org/A849640f672ed0df0958abc0712110f3c/HowToEditThisPage The wiki stores some html plus some wiki specific tags (cross references seen as back links, "include that other page here literally" to compose big pages from componets and cross references into other wikis [the askemos wiki allows to be stacked]). The "source" template will show the page source in text/xml by default and present an option to change into some wikipedia style (not exactly, I tried to parse the syntax using lalr, so I needed to modify the syntax anyway; and I'm not yet satisfied with the result of the "serialize as wikipedia" procedure). best regards /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] a file system using Chicken
> "felix winkelmann" <[EMAIL PROTECTED]> writes: > > >> > >> A few of you have mentioned their past interest in using Scheme > >> for a filesystem. Out of curiosity, what ideas did you guys have > >> in mind? I must have missed that post. This is, when I *must* put in my shameless plug about having worked towards such a thing in the past years. > Me too! ;-) > > - developing a Scheme-based domain-specific language for implementing > secure/safe/guaranteed-integrity filesystems, using techniques like > the various secure proof-carrying calculi I did end up with something like http://softeyes.net/A04538159df3258ea68544531bea1c006 (white paper from 2002, PDF), the implementations looks roughly like this: level 1: comparable to git (see "man git" section "the object data base"): content addressed objects. Askemos has only two types "blob" and "place". Blob, as in git is a static byte sequence, addresses by it's sha256 has. Blobs as well as places are referenced from other places via links. Everythink place linked from the well know place (where - by "accident" higher level will store your current X509 private host key is referenced as blob) is kept during garbage collection (of places). level 2: For each place the system kernel maintains a set of properties. What exactly is already configurable. However a certain set of properties is provided. 1. The object type. Called either "action-document" or "contract" in the context of Askemos. (Where the former is better to explain the internals of the machinery, while the latter names the real purpose.) Objects types are "consed" with initial data at object creation time. They are static objects. 2. Mandatory capabilities. (Here I need to point out that the scientific contribution of the Askemos project is to solve the distribution of capabilities "how do the capabilities get granted to the objects (places)" in a secure manner. [boils down to a few lines of set theory]) 3. Creator, Date and some such meta data. 4. the actual (optional) object data (a blob). level 3: Places communicate to each other sending messages (Erlang style interaction). The "contract", which governs the execution of the process whose state is stored (in the blob and link pattern) at the place defines via some embedded Scheme code a few operations. At least: "Read" - how the repls to idempotent calles to the place are composed, and a "propose"/"accept" pair, which defines how messages are handled, which might modify the place. Recall MVC and the GET/POST distinction of HTTP and some imagination, which one goes where. We return to the "propose/accept" instead of naive "write" in a second. > - developing file-systems optimized for reading and writing particular > types of data structures, with the ability to add new data structure > definitions on the fly, essentially a hybrid between file systems > and databases > > - union directories ala Plan 9 -- combining different resources in a > filesystem interface; the resources could be different Scheme > programs and so on -- I guess this is a generalization of Felix's > ideas #1 and #3 By means of the contract, all types of objects (e.g., comparable to those "tree" and "commit" records of git, but that's now for git comparision) can be defined. Use your OO knowledge to roll your own MOP. (((We have slightly optimised already for XML processing. Parsed state / serialized octec sequence cached side by side. Also sqlite available because I could not resist.))) >From level three there are a few network protocols available. Most important HTTP/S to communicate with the places within Askemos from outside. I've been looking into fuse a few times myself and I am very grateful for duggfs in that respect. ;-) But for file system operations we currently rely on WebDAV no matter how bad a standard that one is. At least the destop tools talk it and: it will not leave the local machine anyway (most of the time). See below. The brings us to level 4: There is second well know object with the public host key and some initial data intented for use as initial contract and initial process. Since contracts are static places, but places nevertheless, their type must be a contract. The recursion ends where the legal recursion regarding contracts ends in the real world to in a initial contract, the "constitution". Using their public key as identity, hosts running an Askemos representative (my name for the server/proxy mix) may route requests among each other. (Hell strict rules regarding capabilities.) The locations (representatives) where a place resides is a property of the place and under control of the contract as yet another property. So applications can choose where to run (given enought of those choosen representative is willing to support the application). This takes us back to the "propose"/"accept" pair above. The last paragraph should look s
[Chicken-users] offtopic: download problems
Hi all, this is unrelated to chicken, but I don't know any way else do debug the problem. Probably due to my yesterdays post, there where unusual many download on the Askemos white paper http://www.softeyes.net/A04538159df3258ea68544531bea1c006 Now I have several occurences of error log entries, where somehow iconv where run over the PDF and bailed out. (Sure iconv should only be run when converting charsets on the way out.) However I can not reproduce the case. To me it delivers just fine, regardless of the host I use. I'd be thankful to those of you, who did experience download problems to send reports my way in private mail. And grateful to those, who just click the url to check. best regards /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] RFC 1123/HTTP-format date parsing
Ivan Shmakov wrote: > MA> I need to parse some RFC 1123 dates, in order to turn them into >While I'm not aware of any existing parsers, implementing one >on top of ... srfi19 from plain memory RFC 1123 is iso 8601, isn't it? (did not check now) (define iso-8601-time-string-format "~Y-~m-~dT~H:~M:~f~z") and go along with SRFI 19 parser/format procedures. Works with the askemos source, that is HTTP/WebDAV. Usually we use konqueror and cadaver for testing, so I only hope it's correct. (Never went deeper into the issue.) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
