Re: [Chicken-users] Re: Trac moving to new server
I'll offer up that callcc.org dns can be pointed however folks here would like. Thanks, Toby On Mon, Apr 6, 2009 at 12:27 AM, Elf e...@ephemeral.net wrote: As soon as I can get ahold of Eric, we can give it one (or more) chicken domain names :) -elf On Mon, 6 Apr 2009, Ivan Raikov wrote: I have set up a Trac instance that is synchronized with the Chicken SVN repository; however, it is installed on the web server of my institute, because currently we do not have an available public IP address. I will be happy to administer this Trac instance, and I can be sure that any downtime will be minimized, because I have administrative access to the machine it runs on; however, I cannot use a Chicken-related domain name for it. If this is acceptable, we can make my Trac instance the primary one. -Ivan felix winkelmann bunny...@gmail.com writes: Hi! Thanks, Arto. I must admit that I'm not using the trac anymore - it is often not reachable (usually when I needed it most). Ivan is going to set up a new one on a dedicated server. Will we still need the current trac instance? What do others think? ___ 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 -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] domain query
+1 chickenscheme.org for me too. BTW, if anyone finds they have some ambition and think callcc.org can be put to better use, I'm open. --TB On Feb 16, 2008 12:42 PM, john [EMAIL PROTECTED] wrote: (+ 1 vote) for chickenscheme.org On 16/02/2008, Elf [EMAIL PROTECTED] wrote: as it comes around time to do my yearly domain registrations (not involving chicken), i happened to notice that many chicken-based domain names are not currently taken, like chickenscheme.org/net/com, chicken-scheme.org/net/com, schemechicken.org/net/com, etc etc etc. two questions: a) do a majority of people want Yet Another set of domains for chicken? b) if a, what does the majority want to register? -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 -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Centralized documentation
Felix and I have had related discussions. I don't mean to steer the conversation away from the topic (how to do egg documentation) -- but I would like to make sure we move in the direction of making things more coherent and usable. Part of that should be that whatever is decided for egg documentation should be something that will last us a good long while. What I would like to see (and have been working on parts of, ever so slowly in my free time): * Merge callcc.org functionality into call/cc.org layout/content (making both URLs serve the same purpose, either by mirroring or redirection) * Merge the wiki into call/cc.org so that all chicken stuff (except trac) is available at a URL that begins call/cc.org. (E.g., call/cc.org/wiki perhaps.) * Unify documentation procedures. All of Chicken, including Eggs, should have indexes of their functions/variables/API that are easily machine-readable (a simple alist or something would be nice, or perhaps embed some kind of markup into the wiki, although I cringe at the thought of much xml). Ultimately, all of this would bring Chicken back to one main website, and it would have mostly editable pages and full search ability. The three URLs we have now (call/cc.org, callcc.org, and galinha) would continue to work, but would serve up the same content, thereby allowing us to move to one canonical URL (or perhaps an easy to remember system of mirror URLs, e.g. us1.callcc.org, br1.callcc.org, de1.callcc.org, etc. (Trac would stay sort of separated, but that's fine because most developers are used to a separate developer site.) -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/4/07, felix winkelmann [EMAIL PROTECTED] wrote: I have a good deal of Qt experience, a bit of FLTK and generally not enough resources to create this on my own (surprise!). I also am unable to do any windows-related coding. Why not build on top of something like wxwidgets? -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] MySQL egg updated
Hi, The MySQL egg has been updated in an attempt to fix compilation issues on Mac OS X. It now compiles for me on OS X and Gentoo Linux. I've also changed it to call (error ...) instead of failing silently when mysql-connect fails (it simply returned #f before). Some of the warnings have been ironed out, too. More suggestions would be appreciated. I apologize that the ones made months ago weren't incorporated much faster. -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] bugtracking and open source labor
Hi, On 12/11/06, felix winkelmann [EMAIL PROTECTED] wrote: Well, what can I say? That would be excellent. We use Trac at work, and it looks quite comfortable. What will be the relationship between the Trac wiki and chicken.wiki.br? -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] (regexp) can not compile regular expression
Hi, I had stream-cgi working before (not exactly sure what changed, maybe a new chicken version?), but now just trying to (use) it does this: [EMAIL PROTECTED]:~ $ csi ___| |_) | | __ \ | __| | / _ \ __ \ | | | | | ( __/ | | \|_| |_|_|\___|_|\_\\___|_| _| Version 2.5 - macosx-unix-gnu-x86 - [ dload ptables applyhook ] (c)2000-2006 Felix L. Winkelmann ; loading ./.csirc ... #;1 (use stream-cgi) ; loading /usr/local/lib/chicken/1/stream-cgi.so ... ; loading /usr/local/lib/chicken/1/srfi-40-base.so ... ; loading /usr/local/lib/chicken/1/stream-ext.so ... ; loading /usr/local/lib/chicken/1/format-modular.so ... ; loading /usr/local/lib/chicken/1/content-type.so ... Error: (regexp) can not compile regular expression: \\s*([0-9A-Za-z-]+)\\s*/\\s*([0-9A-Za-z-]+)\\s*(|;\\s*.*)$ Call history: eval (##sys#require (quote stream-cgi)) -- #;1 Seems the problem is in the content-type egg, and it boils down to the tail end of the regexp: (|;\\s*.*) I figure there's probably a simple fix... anyone? -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Manuals on the wiki
Are there two manuals for a reason? Is one more up-to-date? http://chicken.wiki.br/The%20User%27s%20Manual http://chicken.wiki.br/manual If I didn't know better, I'd be quite confused. ;) -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] readline not saving one-char commands to history
Hi Dan,On 10/24/06, Dan [EMAIL PROTECTED] wrote: That's right, the latest readline egg doesn't save things like x, f, or + (on a line by themselves) to the history. Once you type at least two chars the command is safe though. Is this a feature or (more likely) a bug? I can't reproduce this problem. Works for me on OS X/Chicken 2.5 and Gentoo Linux/Chicken 2, Build 2, both using latest readline egg. When was the last time it did the right thing? -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] How easy is it to use Chicken in Windows XP
On Wed, Aug 23, 2006 at 01:10:28PM +0100, Sean D wrote: 7. YES - I can download latest virus-free executable version for Windows from (please supply URL) Perhaps this? http://www.call-with-current-continuation.org/chicken-2.41-win32.zip -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] RFC: documentation lookup utility
Hi all, My own tendancy when working with Chicken is to have a web browser open with the R5RS index, the Chicken manual, relevant eggs, et cetera, in separate tabs (in firefox), so lookups in the various documents are (somewhat) convenient. I've got some plans for a simplification of the above -- along the lines of what I would personally find useful -- that I would make generally available online. (It would be, after all, just a way of finding pointers to the information that's already online.) I'll outline the idea below; what I'm really interested in is (a) would you personally find the service useful and (b) if this idea doesn't fit the way you work and and wouldn't make things easier for you, I'm interested in hearing how you work -- I personally can't code very long before I have to go lookup what arguments a certain function takes, or to find a function that already exists to accomplish some task. So if you have a few minutes, I'd appreciate whatever feedback you could send me. Feel free to reply off list (or on, but I'd rather not hijack chicken-users :)). The details of what I'm thinking now follow... I've registered callcc.org, and it currently provides very rudimentary shortcuts to the documents I mentioned before. For example, http://callcc.org/ redirects to Chicken's home page; http://callcc.org/r5rs/ redirects to the HTML R5RS on schemers.org; http://callcc.org/wiki/ redirects to galinha; http://callcc.org/wiki/users redirects to galinha/users; and so on. Some of these (/wiki/ for example) serve as wildcards: /wiki/ takes you to / on galinha, while /wiki/users takes you to /users on galinha. Now, my goal is this: Any callcc.org URL should try to take me to something relevant. So I could use http://callcc.org/apply and be taken directly to the R5RS blurb on apply (and likewise everything indexed in the R5RS index would work). Similarly, functions specific to Chicken should be made available: http://callcc.org/print would take me to the Chicken manual on print http://galinha.ucpel.tche.br:8080/Unit%20library#print. URLs that don't exactly match (or don't return exactly 1 result) might instead return a page of search results. (This is all inspired by php.net's similarly functionality. Try http://php.net/echo to see an exact match and http://php.net/hex for an example of search results related to hex.) The Chicken manual part will probably require some indexing, which I haven't quite decided how to do yet. (AFAICT, unlike R5RS, there isn't an existing index of all of Chicken's functions that link into the appropriate portions of the manual. A machine-generated index might be sufficient, but I haven't decided exactly how yet. For instance, print should always take me straight to the print function, but the print function is no doubt mentioned in many places in the manual, and the word print (not necessarily referring to the function) even more, so the machine indexer would be lead to believe multiple results ought to be displayed in a case where one result is clearly correct.) I would like to have eggs and any other relevant documentation included, too. It all comes down to generating and maintaining the index, though; and that's where I was hoping to gather some feedback. I'm considering approaching this sequentially, as follows: * index functions first (R5RS, Chicken, eggs, ...) * maybe other somewhat structured things, like read syntax (#! etc) * and finally a full-text index of R5RS, Chicken manual, egg documentation, and so on, to be consulted when a query doesn't exactly match the before-mentioned indexen. The main difficulties I foresee are: * Is there any existing document with sufficient metadata as to give me a way to machine-generate the index of all of Chicken's functions? If not, I expect I will spend a little time manually generating this sort of data; it may be beneficial to embed it in the existing manual (sexprs in HTML comments?) or otherwise (a) make it generally available and (b) keep it up-to-date. * For eggs, the eggdoc source files might be enough (or come close; I haven't done enough research yet). It may be easy enough to pull out, e.g., foo from (procedure (foo BAR BAZ)), but HTML anchors will need to be added to the autogenerated output to make this be useful. Further, at least some of the eggs don't mention all of the functions they provide in the eggodc; but perhaps this shortcoming should rightly be fixed on their end. Anyway, there's the gist of it. Comments? -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] RFC: documentation lookup utility
Hi Brandon, Thanks for the feedback. On Sat, Aug 12, 2006 at 08:59:19PM -0700, Brandon J. Van Every wrote: Typing a word into a URL is not really the kind of documentation I want. I want to click on a word in the editor I'm using and be taken to relevant documentation. I don't want to use my brain, I want the computer to do that. I agree with you that editor-integrated documentation is nice. I haven't seen anything like that for Chicken yet, and even when it exists, I'll still find the browser-based approach useful. It'd certainly bring Chicken bragging rights to have both. :) The common problem seems to be that both ideas would need an accurrate, well-maintained index of function names and [a pointer to or actual content of] the associated documentation. Knocking it out in one swing for both of us would be really nice. Although... Being able to fetch a blurb (instead of a link) might actually take a little more work. The R5RS functions are grouped with many on a single page, so it might be difficult to determine the appropriate boundaries for the blurb. In my application, the browser would handle this by starting the user off in the right place and they can read what they want. In an IDE, it might be unmanagable to get back more than a paragraph or so -- or you might just want the (func foo bar baz) synopsis to remind you of the arguments. We could possibly solve this by adding more metadata during the indexing process -- mark up not only the procedure and its arguments, but also give a description of it that would allow programs to know where the end of the text about each function is. Did you have plans for where the data for each function would come from for your application? And are you planning to provide just the argument list or also a description of the function? I would be happy to combine efforts on this indexing/retrieval problem if our needs really do overlap. -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CMake tarballs
I've come close to responding to this notion that we're headed for CMake being the way to build Chicken, and I've chosen to keep my mouth shut. But it seems like we're moving in that direction simply because there isn't much resistance. So, I'll go on and make it clear that there is. On Sun, Jul 30, 2006 at 09:40:01AM -0700, Brandon J. Van Every wrote: John Cowan wrote: Brandon J. Van Every scripsit: I'm not keen on naming the build in a way that looks unofficial or special or different. As in, what the hell is this -cmake- thing?? I want people to just use the build. It *is* special, different, and unofficial. I agree with John -- 2.41c looks like a version number. Even chicken-c-2.41 is too cryptic for me. I'd rather have it be clear -- chicken-cmake-2.41. On Sun, Jul 30, 2006 at 09:40:01AM -0700, Brandon J. Van Every wrote: Well why don't I name it chicken-dont-use-this-its-unofficial-2.41.tar.gz then? I'm not interested in an unappetizing name, if such names there be. It will never become official if it is not consumed. If you're rather use chicken-dont-use-this-its-unofficial, go right ahead. ;) I, for one, am not interested in making Chicken even more obscure by requiring an obscure build tool. On *every* platform except non-Cygwin, non-MSYS, straight Windows, autotools does the job just fine. IMHO, one platform -- for which two viable workarounds exist -- should not drive a shift that will require everyone else -- those that *have* been able to build up to this point, just by typing ./configure; make; make install -- to go out and get some newfangled installer for the same job. CMake isn't even a usual solution for Windows. Creating a CMake build isn't going to make Chicken internals development on Windows any less obscure. (For most people, just having a Windows binary would be plenty. They couldn't care less if it was built on mingw.) If I had to run chicken on windows, I certainly wouldn't be itching to build it from scratch. There isn't even a C compiler on a Windows machine, by default... How is that sane? John Cowan wrote: And of course it relies on the user already having cmake or being willing to install it. Exactly. Why would I want to install CMake so I can build on a system that actually allows me to have a real build environment. Autotools by design doesn't have to be installed... it generates a shell script and makefiles that work anywhere with a reasonable development environment. Testily, I say, so what? It also relies on people having a friggin' C compiler, a minimum level of technical literacy, and probably other things. No need to be snippy. Yes, it requires a C compiler, which every system EXCEPT Windows ships with already installed. On Unix, requiring CMake, which isn't a usual addition, would be more work. Increasing the work on Unix to decrease the work necessary on a system that doesn't come with a C compiler just sounds backwards. Hey, we could probably compile it on the N64... let's make the Unix process harder so N64 takes a step or two less. I'll grant that having Windows binaries is important. But building from scratch? ...not so much. It only relies on people having a Unix shell. Convenient, but it sure makes people lazy. I don't see how having a Unix shell makes me lazy. Because I can install Chicken with a simple ./configure; make; make install? Do you whip yourself every time you install a program with an InstallShield wizard, for being so lazy? So there it is. Is it lamentable that the build process on Windows isn't *easy*? Yes. Is it Chicken's fault? No. Would it be a showstopper for Chicken to be used or even be popular on Windows? No. Windows people tend to be perfectly happy without compiling things in the first place. Don't get me wrong. Having a CMake build can be nothing but an asset. But pushing so hard for it to be the official way to build is too much. It's fine if you want to support it... I hope lots of people find it useful, and I hope it gives you satisfaction to contribute. Just try not to be too heavy handed about it... chucking autotools would not be a good move. -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
build test farm [was Re: [Chicken-users] Cmake broken again: paths are not quoted]
On Thu, Jul 20, 2006 at 04:00:48PM -0400, John Cowan wrote: Sourceforge.net does provide a compile farm that provides the ability to build on multiple platforms, though Felix would have to move Chicken there to take advantage of it. It doesn't do Windows, though. Hmm... maybe it would be possible to construct our own, with volunteered resources. The normal process would be to pull from darcs, try the build, and post apparent success or failure (maybe to a page on the swiki?). If it fails, a log could be posted, too. (A similar alternate process would exist for checking release tarballs, but this would run only when a new tarball has been released, so as not to waste cycles rebuilding something that's already been tested.) I would envision this being a chicken script (compilefarm.egg?) and it'd be triggered by cron/task scheduler, on the volunteer's terms (so volunteers are in full control of how much it encroaches upon their system). I don't think the program to do it would be all that complicated; the question is, could we find volunteers to give up some cpu cycles on various platforms? (I for one have at least a Windows box and a Linux 2.6 box I leave always running that would be offered.) The product would be a page with a table on it, showing each volunteered machine, architecture and OS, build schedule, when the last build ran, and success/failure. (And, if failure, a link to the log of what happened.) Maybe this would also provide some more incentive for a test suite, and at a minimum, we could start with one for (use srfi-1) and whatever other problems might be diagnosed after successfully building. I'd like to hear what others think about this. -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] rails-like framework
Anybody know of a Chicken-compatible Ruby on Rails workalike? I know Ed Watkeys posted something about the URL mapping part, but is there anything close to a full framework? -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] MySQL egg
Alrighty, here's the fruit of my recent Chicken labors. :) http://toby.butzon.com/cs/mysql-egg/ All of my code is there, plus a packed-up mysql.egg, an eggdoc page (docs/mysql.html), and a mole page (docs/mysql-mole.html). If anyone's interested in this egg, I'd love to get some feedback. I'm also interested in hearing comments on my code usage of the FFI; it's been a while since I've written Scheme code, and it's my first time using Chicken's FFI. So all comments welcomed. There are still some rough edges, as noted in docs/mysql.html under Bugs. I'm planning to smooth as much of that out as possible over the next few weeks. I'm posting now in hopes of getting some early feedback. :) It's so refreshing to be in Scheme again after 2 years in a mostly Java world. If only there were more Scheme jobs! -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] FFI unsigned long pointer
So, I'm playing with FFI (which is great, BTW :)). I'm writing some glue to use MySQL's C API from within Scheme (which I hope to submit as an egg soon...) and I've come across this: unsigned long *mysql_fetch_lengths(MYSQL_RES *result) Now, I can find out before I call this function how long the returned array is going to be... I just don't know how to get that array back into Scheme. Could it be done using one of the srfi-4 foreign type specifiers... Or, if not, perhaps I could write a C wrapper that calls mysql_fetch_lengths, builds a vector out of the result with C_vector, and returns that. (Then what? I tell foreign-lambda it's a scheme-object?) Please forgive me if this has been answered already... There's similar stuff already in the archives, but it doesn't quite seem to answer my question (or maybe I'm just too dense... :-P). Thanks! -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
