[Chicken-users] Re: A Proposal for Texinfo Reference Manual
Hi Adhi, Given the current arrangement, I really think that maintaining a separate Texinfo manual will take a lot of (redundant) effort. The wiki is _not_ in HTML format, HTML is generated from the wiki internal representation. There is already code to generate fairly decent LaTeX code from the wiki, and some code to generate individual Texinfo pages, so I don't think you need to be concerned about idiosyncrasies and dirty hacks. Actually, the basic code that generates LaTeX and Texinfo code is quite simple, the only thing that seems to be missing from the latter (as far as I can tell) is a function to generate Texinfo contents and node pointers. hen.el at least has mode documentation (C-h m); what kind of additional documentation would you suggest? I do agree that it needs to be at least mentioned in the manual. I would say that hen.el was a lot more convenient back when you could look up a symbol in the Chicken Texinfo manual from within a Hen buffer. How about this: I will try to generate an example Texinfo manual from the wiki, using the existing wiki-texinfo code and the Emacs Texinfo editor functions, and you can look at it and tell me what you think about it. -Ivan Adhi Hargo [EMAIL PROTECTED] writes: THE PROPOSAL: Important point first: I propose, in the long run, to spare the wiki for tutorials, introductions, cookbooks, FAQs, installation problem, or anything else any casual user could confidently contribute, and let the maintainer or at least experienced programmers (a number of you, I suppose) do the real manual in Texinfo. The important chapters, I think, are: * Overview * Compiler usage * Interpreter usage * Interaction with Emacs through hen.el * Modules(?) and Functions * Foreign-Function Interface * Functions index * SRFI-support index I'll give a serious try to merge extant work (based on 2.613, not the wiki. Can't mirror) this week and see how it turned out. I'll learn an awful lot from the process, anyway. I seldom write Texinfo, so it *might* took longer to finish. NOTE ABOUT THE STRUCTURE: Of the two indices, the first any beginner will no doubt constantly peek at, the second readily accessed by more experienced Schemers. Each items in both points to a specific subsection in the Functions chapter. SOME BACKGROUND: I've tried MIT Scheme, Bigloo and PLT's (awesome) Scheme coding environment. What I'm used to see in a reference manual (GNU's especially), expect to (and do) find in their docs, and found to be lacking in Chicken's are (to say the least) a well-structured index to programming concepts, and library-functions supported by Chicken. Even hen.el's not described (only Lispers could use it in its current state). What's already provided is good, basically, but I find it hard to comprehend the system as a whole without looking at the source code and do regexp-search for ``^(define''s just to know what the codes could do out-of-the-box and how they do that. Even if no Texinfo version would ever exist, an alphabetical index in the HTML docs' offline version would suffice. I don't use the other aforementioned systems anymore, but still kept their docs to guess what I could expect to find in Chicken. Only recently do I find that Chicken (v2.6) barfs when I pass an output-port as the last argument to write-string, unlike MIT Scheme (not supposed to, according to the wiki. expected, according to the source). Keeping a Bigloo/MIT Scheme INFO file in a frame, R5RS INFO in another, and dired frame of Chicken src sure helps but it could've been better... By the way, I'm concerned about the wiki-texinfo thing. Wouldn't it be a dirty-hack kind of job, knowing Texinfo's strictness, and HTML usage and wiki engine's idiosyncracies? Don't know if it could be done cleanly in a reusable manner in Scheme, though. Now that's a good way to spend your hacking time. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] syntax-case modules questions
felix winkelmann [EMAIL PROTECTED] writes: On 5/25/07, Andreas Rottmann [EMAIL PROTECTED] wrote: Since Chicken lacks a built-in module system, I'm playing with the syntax-case egg. I want to take an extension (say SRFI-39) and make that (or parts of it) available as a syntax-case module. It seems I have to use EXPORT-TOPLEVEL instead of the export list, since this doesn't work: (module foo (append!) (require-extension srfi-1)) === Error: missing definition for export(s): (append!) The module form expects source forms to define the exported identifiers. require-extension just loads compiled code, basically. So there is no way to package extensions as syntax-case modules? This works: (module foo () (require-extension srfi-1) (export-toplevel append!)) Not really: it makes append! available under an (unqualified) name append!, not as an identifier specific to the module foo. Oh, I see. :-/ BTW, no need to CC me, I read the list. Regards, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://rotty.uttx.net| GnuPG Key: http://rotty.uttx.net/gpg.asc Fingerprint | C38A 39C5 16D7 B69F 33A3 6993 22C8 27F7 35A9 92E7 v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com Software Patents: Where do you want to stifle innovation today? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] syntax-case modules questions
On 5/25/07, felix winkelmann [EMAIL PROTECTED] wrote: Modules to be imported by client code should always be available in source code form: the source code is processed by the syntax-case macro expander and binding information (of normal variables and macros) is recorded. So to create an extension, install both the compiled .so and the source files. Conceivably, a different module-system could be designed that did this processing at compilation time? Perhaps library source would need to be available at application-compilation time, or perhaps the library source could be distilled into an export-directive that contains the details required by the importer (including syntax definitions)? BTW, on a related note, I would love to have an optional, categorical namespace through which I could access an extension's definitions, without any concerns of shadowing. E.g. #;1 (use definition-catalogue) ; a theoretical extension #;2 (use url) #;3 url-decode #procedure (url-decode str124) #;4 (set! url-decode #f) #;5 url-decode #f #;6 (as-defined-in 'url 'url-decode) #procedure (url-decode str124) ...where definition-catalogue's hooks would note the import of (url) and identify any toplevel definitions. The (as-defined-in) procedure performs the lookup of the final definition of 'url-decode that occurred during the extension-load phase. Possibly something like the (oblist) egg could be used to note changes in the toplevel environment caused by the require-extension call, or possibly a formal export-list might be required. (Or a do-not-export list, in the case of volatile definitions that should never be catalogued.) I'm concerned, for example, that more than one egg defines a 'format' procedure, as does the standard library. My app might depend on the standard (format) as well as on your egg; but if you modify your egg to depend on 'format-modular', for example, then my app might break. I'd like to be able to say (as-defined-in 'extras 'format) and know for sure what I'm getting, regardless of import-order and other side-effects. (I'm sure I'd choose a nicer syntax, but the point stands.) Having something like this might eliminate the need for library source to be available in order to make a module system work correctly. (Still not sure how to handle syntax, though.) Thoughts? G ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-setup -test
Yes, I actually meant testbase, but I wasn't paying attention when typing. By the way, if I want to migrate my test code from testeez to testbase, what should I use in place of the test-define macro? In testeez, it is a convenient way to define constants local to a test, but it is not clear to me how to do this in testbase. Also, something that testeez is lacking, but I would like to be able to do is test loop invariants, e.g.: (some tests ... ) (do ((i min (+ 1 i))) (( i max)) (some code ...) (test/equal (some test ...) #t)) So if any of the tests in the loop fail, then there should be a way to indicate that in the overall test stats. Is it possible to do this in testbase? -Ivan Kon Lovett [EMAIL PROTECTED] writes: On May 24, 2007, at 7:28 PM, Ivan Raikov wrote: Thanks for that useful addition. So if the tests require an additional egg (such as test-infrastructure or testeez), should that be added as a dependency in the .meta file? Yes, but haven't done it myself yet. (Note 'test-infrastructure' is obsolete.) Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] csc segfaults with certain recursive sources
$ cat x.scm (require 'y) (module x (fx) (define fx 10) ) $ cat y.scm (require 'x) (require-for-syntax 'x) (import x) (define fy 20) $ csc -R syntax-case -s x.scm $ csc -R syntax-case -s y.scm Error: (open-input-file) can not open file - Too many open files: ./x.so Segmentation fault (core dumped) *** Shell command terminated with exit status 139: /opt/chicken/bin/chicken y.scm -output-file y.c -dynamic -feature chicken-compile-shared -quiet -require-extension syntax-case ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
