Re: [Chicken-users] Qt egg
On 2008-Nov-1, at 01:39, Shawn Rutledge wrote: Did you succeed yet? I just got around to trying this. qt.setup only uses QTDIR to find qmake, so you can set QTDIR to /usr. But the next problem is that qmake generates an XCode project rather than a Makefile. Actually, I made no progress with it, as I put that project on the back burner, and if I do go back to it, I'm likely to do it on Linux rather than OSX. However, it would still be nice to have a recipe to give to everyone :-) -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Qt egg
I neglected to thank Shawn for getting back to me on this! My apologies -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On 2008-Oct-26, at 11:50, Peter Bex wrote: It would be better to make the behaviour be system-specific, instead of adding flags. On Windows, *always* treat slashes as backslashes. On Unix, *only* accept slashes with no additional translation steps. (I'm not sure Windows doesn't allow slashes in filenames, but I don't think it does) I strongly disagree with this particular recommendation. Sometimes I have code running on Unix that manipulates Windows file names (thanks to VirtualBox, that's something I want to do more often, these days). I recommend a design that has a flag with settings such as `this is a Windows name', `this is a Unix name', and a default setting of `this is a name for the OS I'm currently on', which can certainly work the way Peter suggests. -- vincent ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Qt egg
Can someone walk me through the installation of the qt egg on OS X? I've installed the binary distribution from Trolltech's website (qt-mac- opensource-4.4.1.dmg). My main problem is figuring out what to set QTDIR to, as there doesn't seem to be a `Qt' directory as such. Any help would be appreciated. Thanks! -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] An alternative thread system?
On 2008-Aug-18, at 13:22, Graham Fawcett wrote: On Sun, Aug 10, 2008 at 9:42 PM, Vincent Manis [EMAIL PROTECTED] wrote: CPython uses a Global Interpreter Lock (GIL) to implement critical sections in the interpreter, thus rendering native threads in that system impossible. Some version of the Python interpreter (I think it was 1.6) was rewritten without the GIL, so as to provide for native threads. That's close, but not quite right. CPython threads are indeed system threads, but the GIL guarantees that only one of them is running Python code at any time. That first sentence in the quote from me is nonsensical. I really appreciate Graham's correction! -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] An alternative thread system?
On 2008-Aug-10, at 11:44, Elf wrote: NO KNOWN MULTIPLATFORM LANGUAGE IMPLEMENTATIONS HAVE WORKING NATIVE THREADING. NO KNOWN MULTIPLATFORM LIBRARY IMPLEMENTATIONS HAVE WORKING NATIVE THREADING. Seconding Elf's comments. A shared garbage-collected memory is only one of the factors that makes native threads almost impossible. CPython uses a Global Interpreter Lock (GIL) to implement critical sections in the interpreter, thus rendering native threads in that system impossible. Some version of the Python interpreter (I think it was 1.6) was rewritten without the GIL, so as to provide for native threads. The resulting system ran more slowly on both single and multi-threaded code than did the standard version. I'm not that knowledgeable about what the Python community is doing now, but I do remember reading that their BDFL (Benevolent Dictator For Life) had decreed that There Shall Never Be Native Threads. If you have a multi-core machine, and want to use all the cores, fork off processes. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Please do not drop 'thread-terminate!' from the SRFI 18 impl
On 2008-Aug-9, at 04:23, Jörg F. Wittenberger wrote: If the postulated programmer had just found mygreatprogram on the net and want's to run it, is it a good thing for said programmer to find chicken unable to run it until a patch is applied? And what mygreatprogram is written in R6RS Scheme? Anyway, while I really prefer terminating thread-terminate!, I would be happy with a strong warning in the manual. This allows mygreatprogram to run on Chicken (though perhaps crashing occasionally, as it does on other Scheme implementations, because of a design where threads were terminated prematurely), while still letting programmers know that it shouldn't be used. (Think of thread- terminate! as being like gets in the Standard C library: everybody knows you shouldn't use it, but it's left in the library for compatibility with programs written 30 years ago.) This warning is far too weak in the SRFI, so the manual is the obvious place to document it. And with that, I shall shut up on this matter. :-) -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault - a hard one
On 2008-Aug-7, at 19:53, John Cowan wrote: 1) Run it in a separate process, which you can kill without damaging yourself. 2) Use a modified version of eval to execute it that counts ticks. 3) Use a modified version of eval that polls for a thread termination request. I'd actually go along with John's suggestion to flush thread- terminate!, for the reasons already cited. At that point, we could no longer claim SRFI-18 compliance, but that's a very small price to pay. Just rename the unit `threads' or something. Maybe this is a change that can be made at Version 4? -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Please do not drop 'thread-terminate!' from the SRFI 18 impl
On 2008-Aug-8, at 16:30, Kon Lovett wrote: My 2 cents. The SRFI document is clear about the danger. The Chicken mail archive is clear about the danger. Standards Practices is clear about the danger. Who are we protecting? Well, I spent several years teaching concurrency (along with many other topics) at a large multinational company whose software engineers overwhelmingly spoke C++, and the number of horrific travesties they committed would sicken anyone. (A standard response to race conditions was to insert a sleep call, for example. `Oh, you QA folks are seeing crashes on your test machines? We can't reproduce them on our development machines.') We should keep in mind that the mailing list probably focuses on the high end of Chicken users, and that many programmers don't necessarily understand this stuff that well, even if they did take the obligatory 3rd year OS course where they used mutexes and condition variables. My preference is the same as John Cowan's: kill it. If not, put warnings in the manual. I don''t find SRFI-18's warning (in the paragraph headed NOTE:) strong enough, as it uses the phrase `may be a problem', not `is virtually guaranteed to be a problem'. Further, I don't know what fraction of Chicken users actually go and read the SRFIs. So, I'd say, `we're protecting that large group of programmers whom we would like to persuade that Chicken is a Good Thing'. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Segfault - a hard one
On 2008-Aug-7, at 06:04, felix winkelmann wrote: It must be added that `thread-terminate!' is a problematic function: terminating a thread forcefully destroy an execution context that doesn't necessarily expect to be terminated and may leave any kind of system in an inconsistent state. In fact, `thread-terminate!' shouldn't be used at all. That is not meant as an excuse - chicken provides it, so it should work, but it is a dangerous device in general. I'd be a bit stronger than Felix on this...fine if thread-terminate can be made to work, but it's almost impossible to design correct software that allows one thread (or process) to terminate another. Basically, the victim thread might be in any state at all, and therefore it's more or less impossible to ensure that whatever global invariants must be preserved are indeed preserved when the thread actually dies. Testing is also close to impossible in the presence of thread termination. Of course, this doesn't apply if the victim thread is allowed to intercept the terminate request, and execute a shutdown handler, but then it really isn't a true termination (the killer thread can't be sure that the victim is in fact dead). I'd prefer to have the manual document that to the best of our knowledge thread-terminate works `correctly', but that its use is fraught with design and testing problems, and therefore it should be avoided. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Last two snapshots (3.3.5 and 3.3.6) are broken
On 2008-Aug-2, at 06:37, Peter Bex wrote: Why not make irregex part of core and create a PCRE egg? That gives us the best of both worlds, IMHO. +1 if irregex meets Felix's criteria of performance and reliability. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] macro systems and chicken (long)
On 2008 Apr 06, at 22:59, Elf wrote: And as I believe I heard someone say on #scheme the other day, if your program involves EVAL, it's probably broken. Even if the EVAL is hidden behind something else. This sentence makes no sense to me, as this would imply that all programs are always broken. eval running within the program, not the eval being used to run the program. so, like, what lambda internals do within a program, or what internal let forms do, or like what happens to arguments before being passed to procedures, or None of those involves an explicit or implicit call to EVAL, they all involve variations on application. An interpreter likely implements them as calls to EVAL, but a compiler almost certainly doesn't. I'm glad Scheme has EVAL, it lets us write the REPL and various tools in Scheme, but, if Scheme (or Lisp in general) were widely used, EVAL- injection attacts would be very popular among crackers. It's a wonderful feature, but must be used with great caution. -- vincent ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chapter 1 is ready
Some time ago, I posted a draft of a rework of Chapter 1 of the manual, at http://chicken.wiki.br/new-chapter1. A number of you made changes and additions, and today I made my final set of revisions, so I now declare this to be Ready To Go. I'm not sure of the exact mechanism for doing this, so I'll leave in the capable hands of whoever is responsible for the manual the task of making it the new official Chapter 1. My next task is going to be a revision of Chapter 3, on the compiler. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] stream-wiki and stream-cgi have an unsatisfied dependency...
...on srfi-29. So I'm not sure if stream-cgi and stream-wiki are in error, or if srfi-29 mysteriously vanished from the repository. -- vincent ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] SRFI compliance
On 2008 Mar 12, at 20:13, Kon Lovett wrote: Hi Vincent, Thank you for the list. Some points: SRFI 48 is supported except for ~W (write circular) by both the format format-modular eggs. SRFI 58 is supported by the array-lib egg except for the #dimensions... form (to be released). SRFI 88 is builtin except that keywords are symbols. SRFI 90 is builtin except that weak-keys/values are ignored. Best Wishes, Kon Thanks, Kon. I have incorporated the changes into the page, as well as removing SRFI-7, as per Felix's earlier message. I think the page is ready to go into the manual now. I'd suggest a new `Reference' section at the end, if others are amenable to that. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Revised Chapter 1 (reminder)
On 2008 Mar 06, at 01:01, felix winkelmann wrote: On Wed, Mar 5, 2008 at 10:09 PM, Vincent Manis [EMAIL PROTECTED] wrote: A couple of weeks ago, I posted a draft of a new version of Chapter 1 of the manual, and asked for comments. There have been a few things added, and I think that the new version is almost ready. There are still some links to add, and a couple of more substantive things. Absolutely great! Should this chapter just replace the current Overview page, then? I think it can...I kept all the content from the current page. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Revised Chapter 1 (reminder)
On 2008 Mar 06, at 09:08, Ashley Bone wrote: I'd suggest combining the paragrapsh on the MinGW/msys builds and just noting that makefiles exist for cmd.exe and msys. Done. John Cowan asked what the point of having both flavors. Back when I was doing Windows stuff, I normally built things via bash scripts (just as I do today on OSX). I did use MinGW/MSys (curse their weird capitalization) for exactly that, once or twice. But most of my coworkers were kind of locked into Windows, and trying to explain shell scripts to them would have been very stressful on all of us. So had I been building something for them to use, I probably would have created a batch file for building it, on the grounds that they would be more likely to understand it than a shell script. So my vote (even though I have no machines at present that need or even could use MinGW) goes to keeping both. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Revised Chapter 1 (reminder)
On 2008 Mar 06, at 21:22, John Cowan wrote: Quite so, which is why I'd suggest that the msys version be scrapped and that everyone on Windows use either the cygwin or the mingw version. Well, I actually don't care one way or the other. I'll change the documentation if a consensus emerges. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] google summer of code
My top two votes would be: - top priority: module system, along the lines of the (still- emerging) ERR5RS `libraries' proposal - polishing an `official' OO extension (maybe that's just tinyclos or meroon or goops or ??? ...) Just grist for the mill :-) -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Unfair question: best Lisp for web development?
On 2008 Feb 27, at 10:45, Graham Fawcett wrote: ... So if you're going RDBMS, I'd pick one database and stick with it, or help write a common dbapi framework. This seems a meritorious project, and not very difficult (just steal the Python API, and Scheme-ize it). Is there any interest in doing it? -- vincent ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] DBI
On 2008 Feb 27, at 12:11, John Cowan wrote: In reality, though, I think portability between databases is more hypothetical than real. Projects typically start with one database and stick to it, for moving between databases *even if a portability layer is in use* turns out to be hard -- all sorts of stuff outside the main code base ends up changing (path names, load scripts, whatever). Agreed. Not only the API but even the dialect of SQL in use changes enough that one must review all the DB code in an application when the underlying DBMS changes. (Even when the old API works with the new DBMS, performance may be so abysmal that a rewrite is still necessary. I remember consulting with a team who were shocked when I told them that although you CAN use ODBC with Oracle, you really really don't want to. Switching from ODBC to OCI resulted in a 40% performance increase for their mid-tier server.) That said, a DBI is still useful, for several reasons. First, management may not have decided which DBMS is to be used, or may reverse their decision at an inopportune time. Whether prototyping or doing early production development, a DBI can be very useful. Second, I have taught database classes, and grew to love the fact that a DBI helps people learn the concepts without getting into a messof stuff that's not really relevant. -- vincent ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
void as a return value (Re: [Chicken-users] DBI)
\begin{rant}
On the subject of using void as a return value (rather than to
indicate that
a function or method doesn't return anything), E.
Please, please, don't ever write functions that return void as
anything other
than an indication that no value was returned.
#;44 (car (db-fetch-row (db-query select salary where empname='Bilbo
Baggins')))
#;45
So now, (a) you get no output, which might be mystifying and (b) car
is now returning
void. Neither of these violates any language rule, but each violates
the Law of
Least Astonishment.
For SQL nulls, one could use '(), as has been mentioned;
alternatively, an object
called the-SQL-null-object could be created (perhaps as a record type
value).
Incidentally, there are several different meanings for null in SQL,
including no
information, not applicable, no value presently exists (but one might
in the future),
etc. You can find lengthy essays on the appropriateness of using NULL
in several
of Chris Date's `Writings on Database' books. People have enough
trouble understanding
SQL null without further conflating it with `this function returns no
values'.
\end{rant}
Sorry :-) -- vincent
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] recursive mutex-lock!
On 2008 Feb 26, at 16:04, Tobia Conforto wrote: Well, the value returned by mutex-state can be either: locked by this thread In this case there can be no race condition, as we own the mutex and nothing is going to take it away from us. locked by another thread abandoned not-abandoned In these cases the mutex is not ours, therefore we don't care if it's locked or not, or if any other thread locks or unlocks it in a race condition, because we'll call mutex-lock! anyway. not-owned This I can't tell, as I have no clue what not-owned means :-) ... My ¢2 analysis says you can get away without a conditional lock, if you just ignore the existence of a not-owned state. You are exactly right, Tobia, and my apologies to Daishi, I should know better than to look at threaded code at 1am :-) Just a couple of clarifications. A race condition can occur if you do a test for *un*locked and then attempt to lock the mutex, but in this case, as Tobia says, the lock will hold. The not-owned case can only occur if someone locks the thread anonymously, which nobody ever does, and is yet another example of how Posix threads are overengineered. There is a way of making this code fail by writing incorrect code. Suppose a signal handler (say for SIGALRM) unlocks the mutex just after the test. Then the code will assume that the mutex is locked when it isn't. Fortunately, signal handlers aren't allowed to do things like that, so it's a case one should be aware of but not worry about. Let me put in a plug for my favorite book on concurrent programming, Doug Lea's _Concurrent Programming in Java_, which, despite the title and the fact that it's in Addison-Wesley's Java series, is much more about concurrency than about Java. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] recursive mutex-lock!
On 2008 Feb 25, at 00:19, Daishi Kato wrote: Hi, SRFI-18 states, The mutex primitives specified in this SRFI do not implement recursive mutex semantics; an attempt to lock a mutex that is locked implies that the current thread must wait even if the mutex is owned by the current thread so, I want a macro or procedure to support recursive mutex. Would be glad someone can note on it. Here's my macro, not sure if it works: Isn't there a similar code? (define my-mutex (make-mutex)) (define-macro (my-lock . body) `(let ([result #f]) (if (eq? (mutex-state my-mutex) (current-thread)) (set! result (begin ,@body)) ;;else (begin (mutex-lock! my-mutex) (set! result (begin ,@body)) (mutex-unlock! my-mutex))) result)) I have actually never used the Chicken threading capabilities, but with almost any mutex code it's a safe bet that there's race condition. In this case, is it possible that the mutex could become locked between a false eq? result and the call of mutex-lock! ? I think recursive mutex locking almost always needs a conditional lock operation. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Vim syntax file for svnwiki
On 2008 Feb 25, at 17:11, Alejandro Forero Cuervo wrote: I just wrote a Vim syntax file for svnwiki, mainly to learn how to write a Vim syntax file :-) and to help editing Wiki pages too. Thank you, Tobia, I can't wait to begin using it! :-) Care to send it to the Vim-people (I don't know if these days you're supposed to send it to their mailing list or directly to Bram or what) so it gets included with the official Vim releases? Can I ask one of you Vim people to go to the draft of the revised Chapter 1 at http://chicken.wiki.br/new-chapter1, and say something more about using Vim with Chicken (it will be in the section on Development Environments, you can replace the sentence about how :q! is the only vi command I know :-). I'm working on a document on GNU Emacs and Chicken, and I think a similar vim-based document would be really valuable. Cheers -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] chicken-users vs chicken-hackers
On 2008 Feb 25, at 17:19, Jeremy Sydik wrote: +1 -- There's no reason -hackers couldn't be brought back if the need arose, right? --Jeremy On Feb 25, 2008, at 7:08 PM, Ivan Raikov wrote: Cross-posting is quite annoying, I agree. Either we should discourage cross-posting, or not use Chicken-Hackers. I don't think that the two lists are so high-volume that merging would be an issue. +1 here too. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] MSVC makefile and patches
On 2008 Feb 22, at 01:08, felix winkelmann wrote: On Thu, Feb 21, 2008 at 11:44 PM, Ashley [EMAIL PROTECTED] games.com wrote: The build runs on msys with no problems. Tomorrow I plan to add a setup for cmd.exe, so a user only needs to have gnu make installed to build chicken for visual c. That seems like a pretty low barrier for windows users. Very good, Ashley. I'll integrate your stuff into the trunk ASAP Would it be possible to put together a package of GnuWin32 programs so as to make Chicken building and egg installation reliable on Windows? I guess that would include make, gzip, tar, maybe cp, rm, mv, and I don't know what else. That would make it easy for a naive Windows user to set up and use Chicken. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
On 2008 Feb 21, at 23:57, Alejandro Forero Cuervo wrote: As such, I will need more convincing before implementing support for indexentry. I don't see what it adds that we can't already do. Ok, I see that it would allow arbitrary pages to declare sub-topics of a given topic, but I don't think that should be supported. I fully agree that much of the indexing can be done automatically, but a good index also includes entries that can't be generated automatically. Again, taking my append example, we might be documenting SRFI-1, in which case we might want concatenate to have an index entry for append. Truthfully, the indexing facility is going to be more useful for the Chicken manual itself, but I do think that a complicated egg might also benefit from it. As for bold-facing entries, sometimes that can be done from section headings, but sometimes that isn't practical. Consider documenting the tinyclos egg, where you might find that the main index entry for `method resolution order' may or may not be in a section with that name. These entries would just be written to a file, and external code would then process them to produce index pages or whatever. I think an index of the entire wiki would be way too big to be useful. If there's interest in this, I could generate it. Keep in mind that the wiki currently has 300+ files. Ulp. That requires more thought on my part. Again, I was mostly thinking in terms of an index database for the manual, or for a small locally- developed set of eggs. Perhaps Alejandro's database of `where symbols in the wiki are documented' could also be added to this external file? I like this idea. I'll probably do it. :-) Thanks for the suggestions, Vincent. My pleasure! -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
On 2008 Feb 21, at 03:38, Alejandro Forero Cuervo wrote:
Sure, good thinking. I've created this document:
http://chicken.wiki.br/wiki-syntax-chicken
...
Suggestions would be appreciated. :-)
The page is much appreciated, and I now have a much better vision of
how the markup is
going.
I hesitate to bring it up again, but can we please have some kind of
indexing markup?
I agree that much of the indexing can be done automatically from the
procedure and
similar tags, but, especially if we're going to use the new markup for
the CHICKEN
manual, custom index entries will be absolutely necessary.
Here's my suggested syntax, keeping it XML-compliant:
indexentry major=List procedures [minor={{append}}]
[bold=yes|no] [see=other topic]/
where the major and minor attributes refer to the major and minor
levels of the
index entry, bold indicates whether the current page number shall be
boldfaced
(representing a definition of the topic and see replaces the page
number with
its operand, for `see also' type entries).
These entries would just be written to a file, and external code would
then process
them to produce index pages or whatever.
Perhaps Alejandro's database of `where symbols in the wiki are
documented' could
also be added to this external file?
Thanks for considering this! -- v
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] YADT: yet another documentation thread
I was offline for almost all of the documentation discussion, so please pardon my beating a somewhat dead horse. I'd like to make the following points, which (mostly) haven't been raised. 1. Total agreement that the first item of business is to fix the small stuff, and that no Grand Vision (TM) should interfere with that. 2. The critical thing for the future is how we can reach new potential Chicken users, as Chicken becomes more and more of a serious competitor to languages named after snakes and shiny stones. I believe that the current documentation, while fairly good, can be reorganized to make it more accessible to Scheme newbies, who probably have no clue where to get started. 2a. At present, a Chicken user has to be aware of - R5RS - the relevant SRFIs - the Chicken core - the appropriate eggs as well as other stuff outside Chicken (e.g., SQLite, Tk, Apache, etc.). While the organization of facilities makes sense to us, a newbie has a real problem sorting out that _member_ is described in R5RS, _any_ in SRFI 1, and _alist-update!_ in the Chicken manual. I am definitely not suggesting a humungous manual that duplicates R5RS, the SRFIs, and the Winnipeg phone book, but a good index and cross- reference can really help. 2b. The basic principle of software documentation is to mirror the user's questions and tasks, and thus I would like to see a new introductory chapter that explains * what Chicken is * a discussion of what you need to have on your machine for - a minimal Chicken core - a pretty much full R5RS system (including the scary installation of GNU MP if you want numbers) * an introduction to using the interpreter * a similar introduction to using the compiler * an introduction to using eggs * a brief discussion of editors and IDEs * suggestions of resources for debugging, profiling, and preparing documentation * references and useful websites (e.g., schemers.com) Much of this information already exists in the manual, but creating one chapter that gets people started could really make Chicken vastly more accessible. (I'm not proposing `Chicken for Brain-Dead Dummies in 24 Hours', just an introduction for intelligent programmers who are new to Scheme and to Chicken.) 2c. There is a set of core eggs that one needs in order to make an R5RS system. These would include numbers, perhaps a few more of the SRFIs. One might go a bit further and add tinyclos. A brief discussion of these eggs, and including their contents in the index, would help people find things more easily. I am NOT suggesting that the system packaging be changed in any way, just that it would make Chicken more appealing if people understand what they can have when they install it. 2d. Don't underestimate visual appeal. A nice-looking printed manual, and nice-looking online help will assist in spreading the message that Chicken is in fact ready for prime time. 3. Eggs and egg documentation. 3a. The `wild west' phenomenon is what has made for so many eggs in the repository. We should do nothing to our processes that in any way damages this. Heavyweight processes, and elaborate documentation standards, will turn off the tap FAST. 3b. I take no position on whether documentation should be inline (a la Javadoc or Doxygen) or separate. Both techniques should be supported. 3c. Users should be able to create addenda for egg documentation, with perhaps tutorials, platform-specific information, or anything else that might be useful. The standard egg build process should retrieve these addenda and provide them as a standard part of the egg. (Again, having to search the wiki or do a Google search acts as a barrier.) 3d. A checklist or guide should be available so that egg developers have some ideas of what we think are good practices, including documentation, testing, etc. This doesn't violate the `wild west' point above, because it's advisory, not mandatory. (It occurs to me that a separate Egg Developer Manual might not be a bad idea; this could include the current wiki tutorial, the guide, and a discussion of how the Eggs Unlimited repository is managed.) 4. Technology and process. What we have right now works adequately. I'd recommend we identify what we are trying to accomplish, and then define suitable technologies and build processes from that. I hope that, as much as possible, we make it easy for users to correct, modify, and extend the documentation. Wiki-like systems are close to ideal for that. I apologize for being so verbose (in the words of Doctor Samuel Johnson, `I did not have time to write you a short letter, so I wrote you a long one instead'), but I hope the points raised here cause some thought. I know that this proposal involves a fair bit of work; although I haven't yet made any contributions to Chicken (not even one egg, though some might appear from me in the near future), this
Re: [Chicken-users] opengl egg does not appear to compile under Chicken 3.0.0
Just as an irrelevant data point, I happened to build the opengl egg today on MacOS X 10.5, with the Feb 1 version of 3.0.0. It built fine, tho so far I have only tried the gears example with it. I don't know if that's of any interest, but I thought I'd pass it on. -- v ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
