Re: [Chicken-users] Compromise Hackathon Doc Proposal
On Wed, Feb 13, 2008 at 10:25:35PM -0600, Mark Fredrickson wrote: Hi all, 1. Our primary focus is on updating documentation where it currently resides (wiki, svn, etc) in the format it currently uses. Getting the documentation that exists current is a big task as it is. Let's not worry about moving documentation just yet. Yes, this is one of the things I put on the wiki page. Could you (and others, of course) add concrete points where documentation is missing/incomplete/out of date to the wiki page? An important part about a Hackathon is that there is a concrete list of things to get done. 4. Let's try to dedicate some time to infrastructure improvements: Mario suggested expanding SVN wiki tags, it sounds like the *-commit hooks could use a refactoring, etc. As Zbigniew said, infrastructure lasts. Good idea. Could you please add these points to the wiki page? There are a lot of smart people on this list with good ideas. Like Ivan, I'm a Scheme fan for the wild-west aspect. I'm not tied to any programming paradigm. I can experiment with many styles. I think we should take a similar attitude towards our documentation. :-) For now, I think this is the best way to go. The bikeshed discussion is going nowhere. (unless Elf comes up with something we can agree on) Cheers, Peter -- http://sjamaan.ath.cx -- 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 pgpHSrWPvLNm8.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Comprehensive documentation rewrite
Elf scripsit: That's true, I should have said that the different licenses might become an issue if you are distributing several eggs together. Though I am not overly worried about GPL violations in distributions of machine-generated C code, so that might be a sensible exception clause to add GPLed eggs. I can't, in general, distribute such generated code without the Scheme source, however, as generated code is not the preferred form of the work for making modifications to it; i.e. it is not source at all in the eyes of the GPL. And adding an exception to the egg helps not at all if the underlying dependency is itself GPLed. -- John Cowan [EMAIL PROTECTED] http://www.ccil.org/~cowan Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] documentation issues...
id like to entitle this next rant 'why wikis are highly suboptimal for documentation', if i may. approximately 9 hours ago, i noticed that the documentation that i had changed in the http wikidoc wasnt generating correctly. (for those wondering for future endeavours, its not possible at the moment to do nested tables directly. or tables with any wiki-markup at all. or any other markup. or ... you get the idea.) running through all those hoops only took about 2 hours before i realised that no markup would work inside existing markup. luckily, theres the scheme tag, to allow embedded evaluation of expressions. (and again, for those wondering, yes, the entire thing is generated via about 90 calls to (display) with static strings.) so we're about 4 hours in now, and things work about 95% of the way. its not handling margins properly and its not aligning text as specified. no biggie, right? this took the following 5 hours. and theres absolutely no reason why it should have taken more than 30 mins from the beginning, but im more than willing to allow for strange edge cases taking a bit longer. so why did it take so long? a) im stuck in a tiny window in a tiny screen with no real text manipulation abilities. b) theres no search and replace. theres no way of even killing lines off. c) cut and paste is fickle about where the mosue is, not where the cursor is. d) theres no undo. theres no redo. theres no means of even taking it offline effectively. e) and the real dealbreaker once i was 99.99% done and loading the preview... it froze in the middle of displaying. claimed it was done (ie, not a network error or something.) theres no buttons at the top to force a save or anything. meaning at 8.5 hours in, i had to start over almost from the beginning. now, if we're going to be doing a hackathon with a focus (so far) on documentation and participation, how long do you think it will be before people get sufficiently frustrated that they throw up their hands and leave? wikis are not a viable solution for documentation that rarely requires editing and even more rarely needs editing by the world at large. they are an excellent means of handling bugtracking, issue requests, public discussion, docs that DO get edited frequently or randomly, etc. they are not an excellent means of documenting a project. i am not in any way trying to criticise the excellent work done by alejandro in creating the wiki, nor mario in his tireless maintenance of the wiki site, nor am i in any way advocating for the removal of web docs, nor saying that the wiki sucks, nor am i criticisng those who think that everything should be through the wiki. i am recounting the reality of the last half day of my life. i am trying to raise what i consider to be a legitimate question on the wisdom and prudence of continuing to force a system to operate far beyond its original intent in design, and whether massively expanding its role is really such a good idea. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Compromise Hackathon Doc Proposal
Good idea. Could you please add these points to the wiki page? Added. I also added an additional hackathon goal of improving Chicken's performance on the PL Shootout. I know there was some noise around that in previous weeks, but I don't know where it ended up. -M ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
Thu, 14 Feb 2008 11:54:51 -0800 (PST), elf wrote: so why did it take so long? a) im stuck in a tiny window in a tiny screen with no real text manipulation abilities. b) theres no search and replace. theres no way of even killing lines off. c) cut and paste is fickle about where the mosue is, not where the cursor is. d) theres no undo. theres no redo. theres no means of even taking it offline effectively. e) and the real dealbreaker once i was 99.99% done and loading the preview... it froze in the middle of displaying. claimed it was done (ie, not a network error or something.) theres no buttons at the top to force a save or anything. meaning at 8.5 hours in, i had to start over almost from the beginning. All the above is related to using a browser which is not suited to the task. Use a light-weight browser that embeds a real editor like vim or emacs or use firefox with the right plugin like ViewWithSource. I hated Wikis before I found these two solutions. Ciao Sven pgpKJjAGwygzr.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
On Thu, Feb 14, 2008 at 02:19:46PM -0600, Jim Ursetto wrote: Select all in the preview window, cut and paste to Emacs or Vim, edit, and paste the text back to the wiki. I do it all the time, and it solves every one of these issues. (Modern browsers handle most of them, too.) You can also use `svn up` for the import step, but the preview window is still preferable to `svn ci` as you can see the result, unless you're making a small change or like to live dangerously. How primitive! :) I use this little script, I think Mario gave to me. #!/usr/pkg/bin/csi -s (use stream-wiki) (define (read-wiki text) (with-output-to-string (lambda () (write-stream (wiki-html (string-stream text) stream-null (constantly stream-null) (lambda (name tail) tail) (make-hash-table) (make-html-header 1) (constantly stream-null) (constantly #t) (make-hash-table) (lambda (url) (string-append ?page= (stream-string url (let ((args (command-line-arguments))) (when (null? args) (print usage: wiki2html.scm wiki file) (exit 1)) (print htmlheadtitle/titlemeta http-equiv=\Content-Type\ content=\text/html; charset=utf-8\/link rel=\stylesheet\ type=\text/css\ href=\http://galinha.ucpel.tche.br/common-css\//meta That way you can generate a simple preview locally. You don't even need network access if you download the CSS and modify the stylesheet link. Cheers, Peter -- http://sjamaan.ath.cx -- 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 pgp0XHSg37bNs.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
Elf, Not to prolong this discussion further, but w3m is lightweight and automatically shells out to your editor of choice for forms, and works fine with the wiki. I'm sure elinks works similarly. On 2/14/08, Elf [EMAIL PROTECTED] wrote: in a brief response to other posts: im not on a machine thats capable of running firefox, and emacs would exceed its memory and space many times over, k? also, i tried copying things over, but that didnt work so well... the mouse is incredibly fickle, as stated, and its way bigger than the cut buffer could handle. its also entirely unstructured, and whitespace matters in subtle ways (try putting an extra few spaces at the end of a section and see what happens, for example), and given the mouse being flaky enough as it is, i didnt want to spend oodles of time erasing accidental pastes. :) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Idea feedback
I have not had a chance to properly think this idea through yet but thought I would throw it out to the lions (chickens) for some feedback. In a mobile client application I am developing I currently embed Chicken into Gtk+. The client communicates with 2 servers. One connection uses plain s-expressions the other uses binary encoded s-expressions. This works fine but does add complication to the client. In the embedded Linux world D-Bus seems a popular inter-process communication tool (http://en.wikipedia.org/wiki/D-Bus). So I was wondering if it is feasible to develop some kind of s-expression based daemon which talks D-Bus. The Gtk+ client(s) can then talk dbus to send/receive data. The s-expression daemon mux's the communication to external TCP servers using s-expression based protocols. The client will then not need to have Chicken embedded and can use the in-built D-Bus features of glib. Ideally the s-expression mux'er could be configured to switch between binary and text encoding depending on requirements. Or even perhaps throttle traffic or try and limit costs over an expensive mobile link. So any feedback on the idea appreciated, John. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
Thanks for the script Peter, I had been looking for a way to generate local html from svnwiki source for ages (particularly while developing eggdoc-svnwiki). The complexity and dependencies weren't worth figuring it out, though. To this point w3m or cut/paste has worked acceptably. On 2/14/08, Peter Bex [EMAIL PROTECTED] wrote: I use this little script, I think Mario gave to me. #!/usr/pkg/bin/csi -s (use stream-wiki) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Compromise Hackathon Doc Proposal
yay! On Thu, 14 Feb 2008, Mark Fredrickson wrote: Good idea. Could you please add these points to the wiki page? Added. I also added an additional hackathon goal of improving Chicken's performance on the PL Shootout. I know there was some noise around that in previous weeks, but I don't know where it ended up. -M ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
Select all in the preview window, cut and paste to Emacs or Vim, edit, and paste the text back to the wiki. I do it all the time, and it solves every one of these issues. (Modern browsers handle most of them, too.) You can also use `svn up` for the import step, but the preview window is still preferable to `svn ci` as you can see the result, unless you're making a small change or like to live dangerously. On 2/14/08, Elf [EMAIL PROTECTED] wrote: a) im stuck in a tiny window in a tiny screen with no real text manipulation abilities. b) theres no search and replace. theres no way of even killing lines off. c) cut and paste is fickle about where the mosue is, not where the cursor is. d) theres no undo. theres no redo. theres no means of even taking it offline effectively. e) and the real dealbreaker once i was 99.99% done and loading the preview... it froze in the middle of displaying. claimed it was done (ie, not a network error or something.) theres no buttons at the top to force a save or anything. meaning at 8.5 hours in, i had to start over almost from the beginning. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
to respond to my own post, peter pointed out (nicely) that im an idiot who hadnt heard of svnwiki that (surprise!) uses svn to grab the pages for local editing. so my usability comments are probably not as relevant. what remains relevant is that its bloody hard to document anything even slightly nontrivial in it. in a brief response to other posts: im not on a machine thats capable of running firefox, and emacs would exceed its memory and space many times over, k? also, i tried copying things over, but that didnt work so well... the mouse is incredibly fickle, as stated, and its way bigger than the cut buffer could handle. its also entirely unstructured, and whitespace matters in subtle ways (try putting an extra few spaces at the end of a section and see what happens, for example), and given the mouse being flaky enough as it is, i didnt want to spend oodles of time erasing accidental pastes. :) -elf On Thu, 14 Feb 2008, Elf wrote: id like to entitle this next rant 'why wikis are highly suboptimal for documentation', if i may. approximately 9 hours ago, i noticed that the documentation that i had changed in the http wikidoc wasnt generating correctly. (for those wondering for future endeavours, its not possible at the moment to do nested tables directly. or tables with any wiki-markup at all. or any other markup. or ... you get the idea.) running through all those hoops only took about 2 hours before i realised that no markup would work inside existing markup. luckily, theres the scheme tag, to allow embedded evaluation of expressions. (and again, for those wondering, yes, the entire thing is generated via about 90 calls to (display) with static strings.) so we're about 4 hours in now, and things work about 95% of the way. its not handling margins properly and its not aligning text as specified. no biggie, right? this took the following 5 hours. and theres absolutely no reason why it should have taken more than 30 mins from the beginning, but im more than willing to allow for strange edge cases taking a bit longer. so why did it take so long? a) im stuck in a tiny window in a tiny screen with no real text manipulation abilities. b) theres no search and replace. theres no way of even killing lines off. c) cut and paste is fickle about where the mosue is, not where the cursor is. d) theres no undo. theres no redo. theres no means of even taking it offline effectively. e) and the real dealbreaker once i was 99.99% done and loading the preview... it froze in the middle of displaying. claimed it was done (ie, not a network error or something.) theres no buttons at the top to force a save or anything. meaning at 8.5 hours in, i had to start over almost from the beginning. now, if we're going to be doing a hackathon with a focus (so far) on documentation and participation, how long do you think it will be before people get sufficiently frustrated that they throw up their hands and leave? wikis are not a viable solution for documentation that rarely requires editing and even more rarely needs editing by the world at large. they are an excellent means of handling bugtracking, issue requests, public discussion, docs that DO get edited frequently or randomly, etc. they are not an excellent means of documenting a project. i am not in any way trying to criticise the excellent work done by alejandro in creating the wiki, nor mario in his tireless maintenance of the wiki site, nor am i in any way advocating for the removal of web docs, nor saying that the wiki sucks, nor am i criticisng those who think that everything should be through the wiki. i am recounting the reality of the last half day of my life. i am trying to raise what i consider to be a legitimate question on the wisdom and prudence of continuing to force a system to operate far beyond its original intent in design, and whether massively expanding its role is really such a good idea. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
On Thu, 14 Feb 2008, a r wrote: Hi, Just a few comments from a Chicken user. I really like searchable, accessible and editable documents on the web. On the other hand, I have never used any docs shipped with eggs - it's simply to much hassle to browse the directories if I can type two words in Google. Wiki docs (and eggs concept) were the two main features that attracted me to Chicken, BTW. i like searchable webdocs for browsing. i also like searchable docs in the interpreter. and i like the ability to generate arbitrary formats (say, pdf of the whole manual). if (use/require/require-extension/load/etc) loaded documentation into the interpreter automatically (or there was some flag to determine if it should do it, or something along these lines), this would be more useful imho in the general sense even than webdocs, provided it was generically searchable and well indexed. (the previous statement should in no way be taken to mean that i think webdocs should be removed or obsoleted, cause theyre obviously both popular and highly used. i know im on the site a dozen times a day most days.) the problem with web-only docs is that retranslation generally is unpleasant, and primitives to make documenting this sort of project easy are sorely lacking. I don't want any API docs automatically generated from source code comments - when separated from the code these comments are just a pile of useless random notes. Documentation _must_ be written in separation from the code. Yes, it is an additional effort, bu if you can't afford it simply don't bother writing any documentation. im in total agreement with you on this one :) -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
Hi Elf, thanks for the quick response... a) The protocol might not be simple it may be complex nested structures. I don't want to write my own parser in C. There is a C s-expr library out there though. b) Not sure what this is? c) XML is evil :) I have tried to compress XML without great results. Assume each bit counts in this application. On 14/02/2008, Elf [EMAIL PROTECTED] wrote: quick question, which may be a really stupid question cause im not sure im understanding properly... why not do one of the following: a) simple string-encoded sexprs to the mobile client, some kind of well-formed message to the server? (ie, different format based on communication direction, playing to both sides strong points) b) define a simple DS message format or lang and use this? c) pass around xml? -elf On Thu, 14 Feb 2008, john wrote: I have not had a chance to properly think this idea through yet but thought I would throw it out to the lions (chickens) for some feedback. In a mobile client application I am developing I currently embed Chicken into Gtk+. The client communicates with 2 servers. One connection uses plain s-expressions the other uses binary encoded s-expressions. This works fine but does add complication to the client. In the embedded Linux world D-Bus seems a popular inter-process communication tool (http://en.wikipedia.org/wiki/D-Bus). So I was wondering if it is feasible to develop some kind of s-expression based daemon which talks D-Bus. The Gtk+ client(s) can then talk dbus to send/receive data. The s-expression daemon mux's the communication to external TCP servers using s-expression based protocols. The client will then not need to have Chicken embedded and can use the in-built D-Bus features of glib. Ideally the s-expression mux'er could be configured to switch between binary and text encoding depending on requirements. Or even perhaps throttle traffic or try and limit costs over an expensive mobile link. So any feedback on the idea appreciated, John. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
w3m has massive display issues in general, eespecially with tables. elinks never seems to work on my machine. i dont know why. i also hate the elinks entry format. i use lynx and a very custom stripped-down ancient version of mozilla. i (stupidly) used mozilla, cause wikis in general dont get on well with lynx. (however, i just did a test, and its actually significantly easier to edit the wiki in lynx than it is in mozilla. which is an impressive feat, given the general track record of editing wikis in lynx.) -elf On Thu, 14 Feb 2008, Jim Ursetto wrote: Elf, Not to prolong this discussion further, but w3m is lightweight and automatically shells out to your editor of choice for forms, and works fine with the wiki. I'm sure elinks works similarly. On 2/14/08, Elf [EMAIL PROTECTED] wrote: in a brief response to other posts: im not on a machine thats capable of running firefox, and emacs would exceed its memory and space many times over, k? also, i tried copying things over, but that didnt work so well... the mouse is incredibly fickle, as stated, and its way bigger than the cut buffer could handle. its also entirely unstructured, and whitespace matters in subtle ways (try putting an extra few spaces at the end of a section and see what happens, for example), and given the mouse being flaky enough as it is, i didnt want to spend oodles of time erasing accidental pastes. :) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
quick question, which may be a really stupid question cause im not sure im understanding properly... why not do one of the following: a) simple string-encoded sexprs to the mobile client, some kind of well-formed message to the server? (ie, different format based on communication direction, playing to both sides strong points) b) define a simple DS message format or lang and use this? c) pass around xml? -elf On Thu, 14 Feb 2008, john wrote: I have not had a chance to properly think this idea through yet but thought I would throw it out to the lions (chickens) for some feedback. In a mobile client application I am developing I currently embed Chicken into Gtk+. The client communicates with 2 servers. One connection uses plain s-expressions the other uses binary encoded s-expressions. This works fine but does add complication to the client. In the embedded Linux world D-Bus seems a popular inter-process communication tool (http://en.wikipedia.org/wiki/D-Bus). So I was wondering if it is feasible to develop some kind of s-expression based daemon which talks D-Bus. The Gtk+ client(s) can then talk dbus to send/receive data. The s-expression daemon mux's the communication to external TCP servers using s-expression based protocols. The client will then not need to have Chicken embedded and can use the in-built D-Bus features of glib. Ideally the s-expression mux'er could be configured to switch between binary and text encoding depending on requirements. Or even perhaps throttle traffic or try and limit costs over an expensive mobile link. So any feedback on the idea appreciated, John. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
a r wrote: I don't want any API docs automatically generated from source code comments - when separated from the code these comments are just a pile of useless random notes. Documentation _must_ be written in separation from the code. Yes, it is an additional effort, bu if you can't afford it simply don't bother writing any documentation. I think what is meant by source code comments is parseable comments in the source code, intended for tools to generate and update documentation automatically, possibly with their own tags to add semantics. Look up Doxygen (http://en.wikipedia.org/wiki/Doxygen) and check out the example source code and generated docs. Granted, that's not Scheme, but hopefully that's enough to understand the idea. ** It not as if such a tool is going to detect each and every comment everywhere and create a useless pile of random comments. That would, indeed, be useless. Usually, this type of documentation is brief, just giving a general idea of what the function does, which arguments are required (and what they mean) and the expected output. How's that different from what's being done, for instance, in the sqlite3 egg? (http://www.call-with-current-continuation.org/eggs/sqlite3.html) If you need more than that, then a manual is called for. Or even a tutorial. And that can and should be kept in some other location, provided it is easily accessible. If you keep them apart, you cannot see at a glance (let's say, while adding features or fixing bugs) if the docs are out-of-date or if someone forgot to comment something. Furthermore, the authors have no need to look up documentation at all, so the documentation *will* become outdated. It's the users that need it, and those aren't always familiar with the code to spot the inconsistencies. Of course, you can keep the docs wherever you want, provided you have enough minions you can slap to bring all of them up-to-date :) Stephen Statistics are like humans. Torture them enough and you can make them admit anything you want ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
hm. i realised i didnt respond to your original question. iirc, shawn rutelege proposed something about a dbus egg a few months ago. i dont know what became of it. another possibility, if youre dealing with deeply nested structures: install chicken on the servers as well. use the embedded chicken interface from c (if you need to keep it in c) to handle the chicken messages and translate them into something more easily understandable. -elf On Thu, 14 Feb 2008, john wrote: Hi Elf, thanks for the quick response... a) The protocol might not be simple it may be complex nested structures. I don't want to write my own parser in C. There is a C s-expr library out there though. b) Not sure what this is? c) XML is evil :) I have tried to compress XML without great results. Assume each bit counts in this application. On 14/02/2008, Elf [EMAIL PROTECTED] wrote: quick question, which may be a really stupid question cause im not sure im understanding properly... why not do one of the following: a) simple string-encoded sexprs to the mobile client, some kind of well-formed message to the server? (ie, different format based on communication direction, playing to both sides strong points) b) define a simple DS message format or lang and use this? c) pass around xml? -elf On Thu, 14 Feb 2008, john wrote: I have not had a chance to properly think this idea through yet but thought I would throw it out to the lions (chickens) for some feedback. In a mobile client application I am developing I currently embed Chicken into Gtk+. The client communicates with 2 servers. One connection uses plain s-expressions the other uses binary encoded s-expressions. This works fine but does add complication to the client. In the embedded Linux world D-Bus seems a popular inter-process communication tool (http://en.wikipedia.org/wiki/D-Bus). So I was wondering if it is feasible to develop some kind of s-expression based daemon which talks D-Bus. The Gtk+ client(s) can then talk dbus to send/receive data. The s-expression daemon mux's the communication to external TCP servers using s-expression based protocols. The client will then not need to have Chicken embedded and can use the in-built D-Bus features of glib. Ideally the s-expression mux'er could be configured to switch between binary and text encoding depending on requirements. Or even perhaps throttle traffic or try and limit costs over an expensive mobile link. So any feedback on the idea appreciated, John. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
Yes, I remember talk of dbus! Any progress Shawn? I am actually doing what you describe now and embedding Chicken to C to handle s-expressions and bit stuffing them (packedobjects). I was curious though to examine ways of removing the dependency of Chicken from the graphical client and using dbus to communicate with another entity that handles the s-expressions. Removing Chicken would simplify building the graphical client on the mobile. The problem is just moved to another place and hidden from C developers who could focus on the client. If that makes sense. Regards, John. On 14/02/2008, Elf [EMAIL PROTECTED] wrote: hm. i realised i didnt respond to your original question. iirc, shawn rutelege proposed something about a dbus egg a few months ago. i dont know what became of it. another possibility, if youre dealing with deeply nested structures: install chicken on the servers as well. use the embedded chicken interface from c (if you need to keep it in c) to handle the chicken messages and translate them into something more easily understandable. -elf On Thu, 14 Feb 2008, john wrote: Hi Elf, thanks for the quick response... a) The protocol might not be simple it may be complex nested structures. I don't want to write my own parser in C. There is a C s-expr library out there though. b) Not sure what this is? c) XML is evil :) I have tried to compress XML without great results. Assume each bit counts in this application. On 14/02/2008, Elf [EMAIL PROTECTED] wrote: quick question, which may be a really stupid question cause im not sure im understanding properly... why not do one of the following: a) simple string-encoded sexprs to the mobile client, some kind of well-formed message to the server? (ie, different format based on communication direction, playing to both sides strong points) b) define a simple DS message format or lang and use this? c) pass around xml? -elf On Thu, 14 Feb 2008, john wrote: I have not had a chance to properly think this idea through yet but thought I would throw it out to the lions (chickens) for some feedback. In a mobile client application I am developing I currently embed Chicken into Gtk+. The client communicates with 2 servers. One connection uses plain s-expressions the other uses binary encoded s-expressions. This works fine but does add complication to the client. In the embedded Linux world D-Bus seems a popular inter-process communication tool (http://en.wikipedia.org/wiki/D-Bus). So I was wondering if it is feasible to develop some kind of s-expression based daemon which talks D-Bus. The Gtk+ client(s) can then talk dbus to send/receive data. The s-expression daemon mux's the communication to external TCP servers using s-expression based protocols. The client will then not need to have Chicken embedded and can use the in-built D-Bus features of glib. Ideally the s-expression mux'er could be configured to switch between binary and text encoding depending on requirements. Or even perhaps throttle traffic or try and limit costs over an expensive mobile link. So any feedback on the idea appreciated, John. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
On Thu, Feb 14, 2008 at 9:28 PM, Stephen Eilert [EMAIL PROTECTED] wrote: a r wrote: I don't want any API docs automatically generated from source code comments - when separated from the code these comments are just a pile of useless random notes. Documentation _must_ be written in separation from the code. Yes, it is an additional effort, bu if you can't afford it simply don't bother writing any documentation. I think what is meant by source code comments is parseable comments in the source code, intended for tools to generate and update documentation automatically, possibly with their own tags to add semantics. Look up Doxygen (http://en.wikipedia.org/wiki/Doxygen) and check out the example source code and generated docs. Granted, that's not Scheme, but hopefully that's enough to understand the idea. ** Yes, I meant Doxygen and similar tools. They inherently encourage a programmer to write a bad documentation. And there are several reasons for this: 1. limited space, 2. limited document editing resources (no tables, diagrams etc) 3. people generally write better documentation when they are not looking at the source code (it is simply easier to imagine what a user needs if you stop staring at your cheat sheet), 4. programmers who write Doxygen documentation feel relieved from writing good documentation (they have filled in all required forms after all). It not as if such a tool is going to detect each and every comment everywhere and create a useless pile of random comments. That would, indeed, be useless. Usually, this type of documentation is brief, just giving a general idea of what the function does, which arguments are required (and what they mean) and the expected output. How's that different from what's being done, for instance, in the sqlite3 egg? (http://www.call-with-current-continuation.org/eggs/sqlite3.html) If you need more than that, then a manual is called for. Or even a tutorial. And that can and should be kept in some other location, provided it is easily accessible. The problem is, that before plunging into API you should be able to find a description of the module itself. I have yet to see Doxygen generated docs that contain a big picture, description of data structures, protocols, examples and an API summary (not just a plain list of functions). I really much more prefer reading a few paragraphs describing what the module is for rather than wading through the API reference. Look at SRFI documents - most of them are pretty good examples of how the documentation should look like. If you keep them apart, you cannot see at a glance (let's say, while adding features or fixing bugs) if the docs are out-of-date or if someone forgot to comment something. Furthermore, the authors have no need to look up documentation at all, so the documentation *will* become outdated. It's the users that need it, and those aren't always familiar with the code to spot the inconsistencies. I agree it is a tedious work. But don't cheat yourself you can skip this task by using some magic. Of course, you can keep the docs wherever you want, provided you have enough minions you can slap to bring all of them up-to-date :) This is a common problem with the documentation, which it's not caused by tools but by people and policies, though. If you hate writing documentation you can always upload the commented source code to the web. IMHO (especially for scheme code) it is a better solution than using Doxygen or similar tools. BTW, I agree with elf that extracted function signatures (+ one line descriptions) could be useful for certain applications (editor/IDE support, interactive mode help etc.). This however has nothing to do with an end-user documentation. -r. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
Hi, Is it true that if you have svn write access, you can just edit the wiki/* files and commit them, which reflects to the web pages? My understanding is that this is a nice feature of svnwiki. Well, my assumption is that developers use Emacs or Vim, non-developers don't and developers could get the write access. Correct me if it's wrong. Daishi At Thu, 14 Feb 2008 14:19:46 -0600, Jim Ursetto wrote: Select all in the preview window, cut and paste to Emacs or Vim, edit, and paste the text back to the wiki. I do it all the time, and it solves every one of these issues. (Modern browsers handle most of them, too.) You can also use `svn up` for the import step, but the preview window is still preferable to `svn ci` as you can see the result, unless you're making a small change or like to live dangerously. On 2/14/08, Elf [EMAIL PROTECTED] wrote: a) im stuck in a tiny window in a tiny screen with no real text manipulation abilities. b) theres no search and replace. theres no way of even killing lines off. c) cut and paste is fickle about where the mosue is, not where the cursor is. d) theres no undo. theres no redo. theres no means of even taking it offline effectively. e) and the real dealbreaker once i was 99.99% done and loading the preview... it froze in the middle of displaying. claimed it was done (ie, not a network error or something.) theres no buttons at the top to force a save or anything. meaning at 8.5 hours in, i had to start over almost from the beginning. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ** XREA.COM -Free Web Hosting- http://www.xrea.com/ ** ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] proposed change to http-client
Hi, Why on earth do you want to add Connection: close in HTTP/1.0? I think it's meaning-less, I'd propose just to remove adding this header in http:POST, http:GET and http:send-request. Although I'm not sure why http:GET and http:send-request has been adding Connection: close. --daishi At Wed, 13 Feb 2008 14:51:15 -0800 (PST), Elf wrote: snip OK, since I need partial support for HTTP/1.1, plase do either the followings: a) modify http:POST so that Connection: close is added only if the req is string. what if i do a protocol-version check before adding the conenction close, so as to preserve proper behaviour under 1.0 ? ie, connection close will only be added if there isnt an extant connection header and the version == 1.0. b) modify http:POST and http:GET so that they never care the Connection header. this would break the default behaviour, and is more of a problem with the http-client egg as a whole, unfortunately. http:GET and http:PUT dont pay attention to the attributes, on the whole. theyre just simplification wrappers for everything beneath. for what its worth, the is-keep-alive? procedure does proper version checking and only closes on the connection header if its explicitly specified, if the protocol-version is 1.1. so as long as i fix the above bit (not explicitly adding the close), it will work as you expect in 1.1 -elf ** XREA.COM -Free Web Hosting- http://www.xrea.com/ ** ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
On Thu, 14 Feb 2008, john wrote: Yes, I remember talk of dbus! Any progress Shawn? I am actually doing what you describe now and embedding Chicken to C to handle s-expressions and bit stuffing them (packedobjects). I was curious though to examine ways of removing the dependency of Chicken from the graphical client and using dbus to communicate with another entity that handles the s-expressions. Removing Chicken would simplify building the graphical client on the mobile. The problem is just moved to another place and hidden from C developers who could focus on the client. If that makes sense. whats wrong with simply including libchicken.so (built for whatever platform) with the codeball for the graphical client? wouldnt need to build chicken again there and youd be simplifying interfaces and reducing dependencies... with a little work, you could even write some code that only used the bits of chicken you needed, compile that to a static lib, and send that, if space is at an insane premium... -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] proposed change to http-client
On Fri, 15 Feb 2008, Daishi Kato wrote: Hi, Why on earth do you want to add Connection: close in HTTP/1.0? I think it's meaning-less, I'd propose just to remove adding this header in http:POST, http:GET and http:send-request. Although I'm not sure why http:GET and http:send-request has been adding Connection: close. why did i add it? i didnt add it. it was there originally when i started modifying the one function. the goal was not to do a complete rewrite of the http egg, it was to make one particular procedure work correctly over its inputs. (the previous state had erroneous assumptions on content.) i left it there because a) it doesnt hurt anything to make it explicit b) it was put there initially by someone who knew what they were doing and c) i had neither the time nor inclination to try tracing and refactoring an entire egg, especially one that is widely used and is a core component of a lot of interesting very active things. the one method changed will act exactly the way it did before i changed it for the various eggs that use it. if i randomly remove things, i cannot guarantee that things wont break. (not that i can guarantee this regardless, but i can demonstrate that for all eggs currently in the repo that use http-client will get exactly the same request objects sent out as they did before i changed it.) -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
This is what I do now. I actually package Chicken for the mobile which installs the shared library. I was looking at a cleaner separation so one app remained C without FFI code (or knowledge of Chicken) the other remained Chicken (with knowledge of D-Bus). The interface between the two being D-Bus. I am quite possibly trying to over engineer something here but interested in the alternatives to embedding. I would like to tell John Doe, you write this C app that talks to D-Bus. John Doe is happy as he knows how to talk to D-Bus from his C app and has never heard of Chicken or Scheme or s-expressions. John Doe does not need to care beyond that point how the data is encoded/sent/decoded/received and can build his app the way he knows how. Regards, John. On 14/02/2008, Elf [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008, john wrote: Yes, I remember talk of dbus! Any progress Shawn? I am actually doing what you describe now and embedding Chicken to C to handle s-expressions and bit stuffing them (packedobjects). I was curious though to examine ways of removing the dependency of Chicken from the graphical client and using dbus to communicate with another entity that handles the s-expressions. Removing Chicken would simplify building the graphical client on the mobile. The problem is just moved to another place and hidden from C developers who could focus on the client. If that makes sense. whats wrong with simply including libchicken.so (built for whatever platform) with the codeball for the graphical client? wouldnt need to build chicken again there and youd be simplifying interfaces and reducing dependencies... with a little work, you could even write some code that only used the bits of chicken you needed, compile that to a static lib, and send that, if space is at an insane premium... -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] proposed change to http-client
Hi, First of all, I'm so much confortable with your modification, and I understand that you keep the original behaviour. I'm proposeing to rewrite http-client. Sorry for the confusion. --daishi At Thu, 14 Feb 2008 15:36:42 -0800 (PST), Elf wrote: On Fri, 15 Feb 2008, Daishi Kato wrote: Hi, Why on earth do you want to add Connection: close in HTTP/1.0? I think it's meaning-less, I'd propose just to remove adding this header in http:POST, http:GET and http:send-request. Although I'm not sure why http:GET and http:send-request has been adding Connection: close. why did i add it? i didnt add it. it was there originally when i started modifying the one function. the goal was not to do a complete rewrite of the http egg, it was to make one particular procedure work correctly over its inputs. (the previous state had erroneous assumptions on content.) i left it there because a) it doesnt hurt anything to make it explicit b) it was put there initially by someone who knew what they were doing and c) i had neither the time nor inclination to try tracing and refactoring an entire egg, especially one that is widely used and is a core component of a lot of interesting very active things. the one method changed will act exactly the way it did before i changed it for the various eggs that use it. if i randomly remove things, i cannot guarantee that things wont break. (not that i can guarantee this regardless, but i can demonstrate that for all eggs currently in the repo that use http-client will get exactly the same request objects sent out as they did before i changed it.) -elf ** XREA.COM -Free Web Hosting- http://www.xrea.com/ ** ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
On Thu, Feb 14, 2008 at 6:07 PM, Daishi Kato [EMAIL PROTECTED] wrote: Is it true that if you have svn write access, you can just edit the wiki/* files and commit them, which reflects to the web pages? My understanding is that this is a nice feature of svnwiki. Yes, you're correct on this. And yes, it is a great feature. Graham ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Comprehensive documentation rewrite
Yes, you are right that you have to distribute the Scheme code, I realized that last night after going home. If that wasn't the case, you could simply distribute generated assembly code for everything. As for GPL-ed dependencies, what I meant was that you could ask the author(s) of any GPL-ed eggs to make an exception for the particular purposes of your project, similar to the approach taken by Debian. -Ivan John Cowan [EMAIL PROTECTED] writes: I can't, in general, distribute such generated code without the Scheme source, however, as generated code is not the preferred form of the work for making modifications to it; i.e. it is not source at all in the eyes of the GPL. And adding an exception to the egg helps not at all if the underlying dependency is itself GPLed. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
On Thu, Feb 14, 2008 at 2:42 PM, john [EMAIL PROTECTED] wrote: Yes, I remember talk of dbus! Any progress Shawn? No. My first use for it was to interface to avahi, but the stacked dependencies got a bit overwhelming... have to figure out easyffi (or something) so I can interface to dbus so I can interface to avahi so I can discover my Scheme-over-TCP service (when the latter is the interesting part that I'd rather spend my spare time on). I got stuck at some point, I forgot where, but it's easy enough to have another look at it when I get home. I figured it might work better to just interface to the avahi API, but then the total number of libraries that need to be linked in goes up, whereas dbus is useful for more purposes. Your project might be similar to mine, but I planned the main comm channel to be plain sockets or SSH rather than dbus. Doing everything via dbus might be interesting, though. http://sourceforge.net/projects/dscm/ What kind of binary S-expression format are you planning to use? That's very much of interest to me, but I figured there needs to be a new standard for exchanging bse's across different versions of scheme (and even other languages, later). I have an experimental thing I call gtf (generic tree format) which might work: just a kind of tree in which all the symbols have been moved out into a symbol table, and then are referenced by offset. But that is not Scheme-specific at all; I intended it to be a replacement for XML actually. It could be a way of representing Scheme source compactly, but it's not as cool as the Kali idea of sending closures from one Scheme to another. That idea is still voodoo to me, but I wish I understood it better. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
Actually talking through this now I have just realised a major over sight in my cunning plan! I would still need a structure to the protocol over the D-BUS session and this would still need to be handled from C. From my limited understanding of D-Bus it provides mechanisms for structuring data that is binary encoded. I am not sure if it handles complex nested structures and how much easier a D-Bus programmer would find this approach! Oh wellit's good to talk! Thanks, John. On 14/02/2008, john [EMAIL PROTECTED] wrote: This is what I do now. I actually package Chicken for the mobile which installs the shared library. I was looking at a cleaner separation so one app remained C without FFI code (or knowledge of Chicken) the other remained Chicken (with knowledge of D-Bus). The interface between the two being D-Bus. I am quite possibly trying to over engineer something here but interested in the alternatives to embedding. I would like to tell John Doe, you write this C app that talks to D-Bus. John Doe is happy as he knows how to talk to D-Bus from his C app and has never heard of Chicken or Scheme or s-expressions. John Doe does not need to care beyond that point how the data is encoded/sent/decoded/received and can build his app the way he knows how. Regards, John. On 14/02/2008, Elf [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008, john wrote: Yes, I remember talk of dbus! Any progress Shawn? I am actually doing what you describe now and embedding Chicken to C to handle s-expressions and bit stuffing them (packedobjects). I was curious though to examine ways of removing the dependency of Chicken from the graphical client and using dbus to communicate with another entity that handles the s-expressions. Removing Chicken would simplify building the graphical client on the mobile. The problem is just moved to another place and hidden from C developers who could focus on the client. If that makes sense. whats wrong with simply including libchicken.so (built for whatever platform) with the codeball for the graphical client? wouldnt need to build chicken again there and youd be simplifying interfaces and reducing dependencies... with a little work, you could even write some code that only used the bits of chicken you needed, compile that to a static lib, and send that, if space is at an insane premium... -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
On Thu, 14 Feb 2008, john wrote: This is what I do now. I actually package Chicken for the mobile which installs the shared library. I was looking at a cleaner separation so one app remained C without FFI code (or knowledge of Chicken) the other remained Chicken (with knowledge of D-Bus). The interface between the two being D-Bus. I am quite possibly trying to over engineer something here but interested in the alternatives to embedding. I would like to tell John Doe, you write this C app that talks to D-Bus. John Doe is happy as he knows how to talk to D-Bus from his C app and has never heard of Chicken or Scheme or s-expressions. John Doe does not need to care beyond that point how the data is encoded/sent/decoded/received and can build his app the way he knows how. way overengineered. just wrap the chicken lib in a nice api ... then john doe doesnt need to know anything about chicken or that chicken is there, hes just loading some shared lib that gives server access. -elf Regards, John. On 14/02/2008, Elf [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008, john wrote: Yes, I remember talk of dbus! Any progress Shawn? I am actually doing what you describe now and embedding Chicken to C to handle s-expressions and bit stuffing them (packedobjects). I was curious though to examine ways of removing the dependency of Chicken from the graphical client and using dbus to communicate with another entity that handles the s-expressions. Removing Chicken would simplify building the graphical client on the mobile. The problem is just moved to another place and hidden from C developers who could focus on the client. If that makes sense. whats wrong with simply including libchicken.so (built for whatever platform) with the codeball for the graphical client? wouldnt need to build chicken again there and youd be simplifying interfaces and reducing dependencies... with a little work, you could even write some code that only used the bits of chicken you needed, compile that to a static lib, and send that, if space is at an insane premium... -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
So you are proposing to implement the D-Bus protocol in Scheme directly, instead of writing a Scheme wrapper for a C library that can talk D-Bus? In general, I would say this makes sense only if you need to send and receive complicated Scheme objects over the D-Bus link. For example, the mpi egg is a simple wrapper around the OpenMPI C library, because I only needed to send/receive homogeneous numeric vectors, and those are well supported by the Chicken FFI. But if I needed to send/receive Scheme closures (for example), then I would either have to use the s11n module and serialize the closures to bytevectors, which is not very efficient, or invent some fancy Scheme communication protocol that allows me to send and receive such objects. From your description, it is not entirely clear what those s-expressions contain -- whether it is simple data, such as numbers and strings, that can easily be represented in C, or whether it is some complex structured data that S-expressions are best at representing. If the former, you might save some time by writing an FFI wrapper. If the latter, then a Scheme implementation might be better (and way cooler :-). -Ivan john [EMAIL PROTECTED] writes: I have not had a chance to properly think this idea through yet but thought I would throw it out to the lions (chickens) for some feedback. In a mobile client application I am developing I currently embed Chicken into Gtk+. The client communicates with 2 servers. One connection uses plain s-expressions the other uses binary encoded s-expressions. This works fine but does add complication to the client. In the embedded Linux world D-Bus seems a popular inter-process communication tool (http://en.wikipedia.org/wiki/D-Bus). So I was wondering if it is feasible to develop some kind of s-expression based daemon which talks D-Bus. The Gtk+ client(s) can then talk dbus to send/receive data. The s-expression daemon mux's the communication to external TCP servers using s-expression based protocols. The client will then not need to have Chicken embedded and can use the in-built D-Bus features of glib. Ideally the s-expression mux'er could be configured to switch between binary and text encoding depending on requirements. Or even perhaps throttle traffic or try and limit costs over an expensive mobile link. So any feedback on the idea appreciated, John. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
This is correct. In fact, I edit wiki pages almost exclusively in Emacs, commit them to SVN, and wait 30 seconds for the post-commit script to update the web page. I find that extremely convenient, particularly with my local installation of svnwiki. -Ivan Daishi Kato [EMAIL PROTECTED] writes: Hi, Is it true that if you have svn write access, you can just edit the wiki/* files and commit them, which reflects to the web pages? My understanding is that this is a nice feature of svnwiki. Well, my assumption is that developers use Emacs or Vim, non-developers don't and developers could get the write access. Correct me if it's wrong. Daishi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Idea feedback
On Thu, Feb 14, 2008 at 5:20 PM, Shawn Rutledge [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 2:42 PM, john [EMAIL PROTECTED] wrote: Yes, I remember talk of dbus! Any progress Shawn? No. My first use for it was to interface to avahi, but the stacked err I guess I was trying to interface to gpsd first. Felix gave me some help with chicken-wrap in December. So I guess I'd better try to pick up that loose end again... ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] A variant of Peter's wiki2html
Hi, Please see attachment. Best Wishes, Kon wiki2html.sh Description: Binary data ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A variant of Peter's wiki2html
Instead of passing (make-hash-table) to wiki-html as the extensions argument, why not have the following: (define extensions (make-hash-table)) (load-extensions-from-file extensions enscript.scm) ... (wiki-html ... extensions (lambda (url) (string-append ?page= (stream-string url))) ) Of course, the load-extensions-from-file invocation could be made optional, but this would allow loading of the various extensions supplied with stream-wiki. -Ivan Kon Lovett [EMAIL PROTECTED] writes: Hi, Please see attachment. Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] A variant of Peter's wiki2html
On Feb 14, 2008, at 5:04 PM, Ivan Raikov wrote: Instead of passing (make-hash-table) to wiki-html as the extensions argument, why not have the following: (define extensions (make-hash-table)) (load-extensions-from-file extensions enscript.scm) ... (wiki-html ... extensions (lambda (url) (string-append ?page= (stream-string url))) ) Of course, the load-extensions-from-file invocation could be made optional, but this would allow loading of the various extensions supplied with stream-wiki. Nice. I just copied the source from the e-mail. Almost no idea what the arguments mean. -Ivan Kon Lovett [EMAIL PROTECTED] writes: Hi, Please see attachment. Best Wishes, Kon Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
