Re: [Chicken-users] Bug in SRFI-13 lib?
On Feb 17, 2008 11:56 AM, Jim Ursetto <[EMAIL PROTECTED]> wrote: > > This is all made a little more confusing by the lack of a > final question mark on the end of these predicates--which > sometimes indicates a "boolean-plus" value is intentionally being > returned; in other words, either #f or a useful true value. > Such is the case with memq, memv, etc. But the dropping of the ? > was, as far as I can tell, done for aesthetic reasons only. > Combine that with the historical baggage of the mismatch index > and the behavior of the reference implementation, and you have > a recipe for discombobulation. > > I hope this explanation made you feel a little better. ;) > Thanks for this (explanation). Would anybody mind if we change string[=<>...] accordingly? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Problem w/ Meroon
On Feb 17, 2008 4:03 AM, Matt Gushee <[EMAIL PROTECTED]> wrote: > felix winkelmann wrote: > > > I just committed a fix (well, I don't know whether it really fixes anything > > as I don't understand the code, > > Brave of you to admit that :-) So is this thing safe to use? I think so. Note that the example was wrong (the NamedColor constructor doesn't take a color argument). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
On 2008 Feb 17, at 06:15, Alejandro Forero Cuervo wrote: ... Documentation for egg foobar should live in the chicken-eggs repository, in wiki/foobar, in wiki format with some extensions for including semantics. By this I mean wiki syntax using tags such as ... , from where some semantics can be extracted by other tools. I oppose using XML or some similar format (eg. s-expr based format) on the basis that this would make it harder for our users to modify. Raising the bar required for editing, even if only slightly, can greatly reduce the number of contributions. ... Ivan tasked me with a proposal on the subject of egg documentation, so let me augment Alejandro's proposal slightly, and then my work will be done :-). The idea is to make it easy for users to add tutorials or other documents to an egg. 1. The main author documentation should live in wiki/foobar. 2. Users who want to add documents to the main user documentation should put them in other files whose names begin with foobar--, with whatever names they like, e.g., foobar--HOWTO-frobozz. 3. A derived files in HTML is produced, containing a table of contents, the official foobar documentation, plus any auxiliary documents. This file is placed as index.html at a well-defined place in the egg hierarchy (doc/foobar.html seems plausible). This HTML file has a comment at the beginning, reading `automatically-generated file, DO NOT EDIT'. That's pretty much what I had in mind in my earlier message. Comments? By the way, on the subject of wiki markup, I'd like to put in a plug for marking index entries. -- vincent ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
The problem is that the .html files generated from the wiki files are not present in the repository. So any scripts that traverse the egg directories and do stuff with the eggs would not have the _rendered_ documentation accessible. For example, I want to be able to run a script that builds Debian packages for each egg that has a debian subdirectory. So that script either needs to be able to run the wiki->html script that is used to create the egg, or the generated .html file needs to reside somewhere in the repository. -Ivan Alejandro Forero Cuervo <[EMAIL PROTECTED]> writes: > > I'm not sure I understand the problem here, so I'll share *my* vision > of how documentation for eggs should be handled in the ideal world. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Errors building eggs in mingw/msys
Ashley Bone scripsit: > I had what seemed to be this EXACT same problem when I built chicken > for cygwin, which I solved by copying the cygchicken dll's > to the path containing chicken (or adding the lib directory to the > path, not sure at this point). I'm at a loss in this case, though I'm > convinced it's something trivial. All builds on Windows (cygwin, mingw, mingw/msys) have the same issue: Windows doesn't have a separate search path for DLLs, so all DLLs have to be on $PATH. However, the working directory is *always* on $PATH whether explicitly so or not. -- There is / One art John Cowan <[EMAIL PROTECTED]> No more / No less http://www.ccil.org/~cowan To do / All things With art- / Lessness -- Piet Hein ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
> In the example below,
> some will remark that you've no longer wrapped the procedure
> description in a tag. However, any reasonable parser should be able
> to reconstruct this information heuristically--after all, we don't
> require the user to wrap entire wiki sections in tags; we simply
> reconstruct where they end.
I think you've touched on a crucial aspect of this, specially by your
use of the word “heuristically”. Clearly, we are not looking for an
XML-based (or, equivalently, an s-expr based) format, but some
compromise between the goals of (1) being very easy to edit and (2)
containing semantics that can be extracted by other tools.
In practice, I expect to use drivers (in the stream-wiki definition of
“drivers”) to programatically extract meaning (such as a
wiki->procedures function, receiving a wiki page and returning a list
(stream) of all the procedures defined on it).
I like your example. I will add a bit to it:
> (+ a b ...)
>
> Adds two or more values.
>
> Examples:
>
>
> Add 3 numbers together
> (+ 1 2 3)
> 6
>
>
>
> Simple example of adding two numbers
> (+ 4 5)
> 9
>
>
> (string-append a b ...)
>
> ...
>
> Examples:
>
>
> Simple example of appending two strings.
> (string-append "foo" "bar")
> "foobar"
>
>
> ...
>
>
> Simple example of the use of {{~A}} escape sequences.
> (use format-modular)
>
> (format #t "There are ~A objects." 10)
>
> There are 10 objects.
>
Note that with just a bit of glue (a driver similar to the
wiki->procedures I described above) we would very easily be able to
extract the information from the examples and turn it into unit tests,
so users adding examples to the documentation would actually be
defining user tests and we could programatically get notified when we
break one of the examples in our documentation. We could also create
wiki pages to contain nothing but tests like these and encourage users
to submit new tests to them (of course, the person running the tests
would need to validate the logs/diffs or use sandboxes). This is
something I find very exciting.
Care to add more to my example above? I'll probably implement
something like this during the next weekend or so.
Alejo.
http://azul.freaks-unidos.net/
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] aliases in the wiki
> I was wondering if these could be placed in a separate namespace > (e.g. http://chicken.wiki.br/sym/stream-xcons or > http://chicken.wiki.br/sym:stream-xcons). The reason being that > with an influx of procedure names the potential for collision > goes way up with a flat namespace. I don't think the potential for collision is too bad: in those cases in which we have collisions, we can simply create a page listing the multiple possible meanings, something along the lines of: > Format > > There are the following pages about this: > > * Eggs: > - format > - format-modular > * Procedures: > - format at the format-modular egg For the egg pages we would simply prefix them (so format-modular would become egg-format-modular). This is just what wikipedia does. I think the advantage of not requiring users to type the "sym:" or "sym/" each time they use this functionality is larger than the disadvantage of having the clashes. Basically, think of it as just one namespace where a user can search for pretty much anything and expect to find something useful. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
On 2/17/08, Ivan Raikov <[EMAIL PROTECTED]> wrote: > Also, it is not clear to me how to convert ... symbol-table formatting > elements to wiki format. Ivan, The symbol-table is essentially a nod to aesthetics--it just alters the appearance of the table (mainly, the 'symbol' column is monospaced). The eggdoc-svnwiki egg translates symbol-table elements to Although svnwiki currently ignores class elements, it might not in the future. In the meantime, you just get a proportional font in the left column. You can see the result by checking any wiki document that was translated with eggdoc->svnwiki, e.g. http://chicken.wiki.br/objc . ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] sqlite3 wtf
Ozzi wrote: ;; Works fine... (sqlite3:prepare (sqlite3:open "db.sqlite3") "select * from foo") ;; but do the same thing again... (sqlite3:prepare (sqlite3:open "db.sqlite3") "select * from foo") ;; and get a weird error! Error: (sqlite3:prepare) unrecognized token: "@" Anybody have an idea where to start on this one? Chicken 2.740 on both machines. Reinstalled all the eggs on Dreamhost, no change. You could try upgrading Chicken to 3.0. That's what I'm using, and I don't get any errors. -- Matt Gushee : Bantam - lightweight file manager : matt.gushee.net/software/bantam/ : : RASCL's A Simple Configuration Language : matt.gushee.net/rascl/ : ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] sqlite3 wtf
The sqlite3 egg seems to have issues on Dreamhost (Linux). Works fine on OS X here. ;; Works fine... (sqlite3:prepare (sqlite3:open "db.sqlite3") "select * from foo") ;; but do the same thing again... (sqlite3:prepare (sqlite3:open "db.sqlite3") "select * from foo") ;; and get a weird error! Error: (sqlite3:prepare) unrecognized token: "@" # "select * from foo" Call history: (sqlite3:prepare (sqlite3:open "db.sqlite3") "select * from foo") (sqlite3:open "db.sqlite3") (sqlite3:prepare (sqlite3:open "db.sqlite3") "select * from foo") (sqlite3:open "db.sqlite3") <-- Anybody have an idea where to start on this one? Chicken 2.740 on both machines. Reinstalled all the eggs on Dreamhost, no change. Ozzi ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
I forgot to mention: if you accept a plain string you can also slim down the overall representation considerably. In the example below, some will remark that you've no longer wrapped the procedure description in a tag. However, any reasonable parser should be able to reconstruct this information heuristically--after all, we don't require the user to wrap entire wiki sections in tags; we simply reconstruct where they end. Off the top of my head, you could terminate reading the procedure description at the next procedure or section tag. In my opinion, moving the smarts to the parser reduces the burden on the user quite a bit, with little semantic loss. For example: (stream-xcons a b) Of utility only as a value to be conveniently passed to higher-order procedures. (stream-cons* a b) Like stream, but the last argument provides the tail of the constructed stream, returning: ... On 2/17/08, Jim Ursetto <[EMAIL PROTECTED]> wrote: > For example, ... . ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
Just a comment: in eggdoc the name of the procedure / syntax etc. is taken as a plain string -- e.g. "(stream-xcons a b)". For HTML output, it is used verbatim. For texinfo output, which has special directives to mark functions, this input is deconstructed into procedure name and arguments using (read), if possible. (See eggdoc-texinfo for more.) For example, ... . This could be considered a design flaw in eggdoc, as the semantics have to be reconstructed. But it was easier to type and didn't matter for HTML. I think your proposal is fine, as any XML-based solution is going to be verbose no matter what. On 2/17/08, Alejandro Forero Cuervo <[EMAIL PROTECTED]> wrote: > > > > Of utility only as a value to be conveniently passed to higher-order > > procedures. > > The name stands for "eXchanged CONS." > > ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] new egg etiquette
Yes. The toplevel directory is for release 2 only, and will probably be renamed later to release/2, but has not yet been to retain backwards compatibility. On 2/17/08, Shawn <[EMAIL PROTECTED]> wrote: > Should all new eggs be created in chicken-eggs/release/3 instead of > the toplevel chicken-eggs/ directory now? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] aliases in the wiki
I was wondering if these could be placed in a separate namespace (e.g. http://chicken.wiki.br/sym/stream-xcons or http://chicken.wiki.br/sym:stream-xcons). The reason being that with an influx of procedure names the potential for collision goes way up with a flat namespace. If this could be done in a separate directory in SVN (e.g. wiki/sym/) then even better, to avoid clogging the main directory with hundreds of entries. Just a thought. On 2/17/08, Alejandro Forero Cuervo <[EMAIL PROTECTED]> wrote: > I have tweaked a bit the code in Svnwiki a bit to support defining > This causes accesses to http://chicken.wiki.br/stream-xcons to be > redirected to http://chicken.wiki.br/stream-ext#stream-xcons. Go > ahead and try it. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Consultants available?
Someone gently pointed out that knowing what the project entails might be helpful. Here is some background: The project, www.kiatoa.com, currently broken and offline, is yet another blog/slashdot/online society/craigslist combo site with a few unique (I think) twists. This is the chicken rewrite of the original problematic ruby/IOWA code. BTW, I tried Ruby on Rails and found it was not for me. The project is built with chicken, Postgresql and a little HTML/CSS. The SQL is separated MVC style from the view and control. I had considered attempting to separate out the core code as an egg but I think there are now better solutions available as chicken eggs. My thought is that I will work on the SQL/Models and get help on the control/view side. I'm not particularly rigorous about keeping the three arenas separated. If a little control leaks into the model because it saves an hour of coding that is fine by me. I'm not a professional programmer so it is all written in a simple subset of scheme, no macros, no call/cc etc. I have a internet accessible host for working on or the entire stack can be installed on any Linux system. It runs fine for example on colinux. Hopefully that is more detail than anyone would want! Thanks for reading. Matt -- On Sunday 17 February 2008 10:56:12 am Matthew Welland wrote: > Fellow Schickians, > > I need some scheme programming assistance for a pet project that has > stalled due to "real life" and burnout issues. > > If you are interested and have some free time please drop me an email > with your hourly rates and any other info you think pertinent. > > Thanks in advance! > > Matt > -- > Schickian: An enthusiastic user of the Chicken Scheme compiler :-) > > > ___ > Chicken-users mailing list > Chicken-users@nongnu.org > http://lists.nongnu.org/mailman/listinfo/chicken-users -- http://www.kiatoa.com, fight for a better world. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] new egg etiquette
On Feb 15, 2008, at 8:39 PM, Graham Fawcett wrote: Hi folks, I just started a new egg in the svn repo. It's nothing worth looking at yet, I just want to make sure I didn't do something stupid that would break anything. Here's what I did: cd release/3/ svn mkdir locality Should all new eggs be created in chicken-eggs/release/3 instead of the toplevel chicken-eggs/ directory now? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Errors building eggs in mingw/msys
I don't seem to be able to build any eggs in the mingw/msys environment. I built chicken using the mingw-msys makefile. When I run chicken-setup, eg: $ chicken-setup -v easyffi I get this: executing silex.setup ... "/home/ashley/local/bin/csc" -feature compiling-extension -v -s -O2 -d1 silex.scm The system cannot find the path specified. Error: shell invocation failed with non-zero return status "\"/home/ashley/local/bin/csc\" -feature compiling-extension -v -s -O2 -d1 sile... If I go into silex.egg-dir and run csc manually on silex.scm, I get a similar problem: $ csc -feature compiling-extension -v -s -O2 -d1 silex.scm /home/ashley/local/bin/chicken silex.scm -output-file silex.c -dynamic -feature chicken-compile-shared -quiet -feature compiling-extension -optimize-level 2 -debug-level 1 The system cannot find the path specified. *** Shell command terminated with exit status 1: /home/ashley/local/bin/chicken silex.scm -output-file silex.c -dynamic -feature chicken-compile-shared -quiet -feature compiling-extension -optimize-level 2 -debug-level 1 However, if I run chicken directly, it outputs a C file with no problem: $ /home/ashley/local/bin/chicken silex.scm -output-file silex.c -dynamic -feature chicken-compile-shared -quiet -feature compiling-extension -optimize-level 2 -debug-level 1 That works fine and produces silex.c when run manually. I had what seemed to be this EXACT same problem when I built chicken for cygwin, which I solved by copying the cygchicken dll's to the path containing chicken (or adding the lib directory to the path, not sure at this point). I'm at a loss in this case, though I'm convinced it's something trivial. Thanks for any help, ashley ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] aliases in the wiki
I have tweaked a bit the code in Svnwiki a bit to support defining aliases for functions in the wiki. My thinking is that (1) for all procedures f, http://chicken.wiki.br/f should return something useful, regardless of where f is defined and (2) we shouldn't have to duplicate information in the wiki. Here is how I do it: $ ln -s 'stream-ext#stream-xcons' stream-xcons $ svn add stream-xcons $ svn ci -m "Creating link for procedure stream-xcons" This causes accesses to http://chicken.wiki.br/stream-xcons to be redirected to http://chicken.wiki.br/stream-ext#stream-xcons. Go ahead and try it. As such, we don't have to split the eggs' documentation wiki files (or documents in the manual) and we can still allow people to play with URL hacking. Feel free to create links such as those. To make it even easier, you can send me mails with the subject 'chicken wiki links' containing lines of the form 'source-for-link destination#url' and I will define those links. If Mario or some other hackers can programatically extract a list of such functions and their location in the wiki, that'd be neat. :-) Hopefully, in some time, http://chicken.wiki.br/some-random-function will work most of the time. I think that would be a bit useful. Alejo. http://azul.freaks-unidos.net/ Ps: I'd like to thank Arhuaco who helped me a bit with the work required to make this work. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Consultants available?
Fellow Schickians, I need some scheme programming assistance for a pet project that has stalled due to "real life" and burnout issues. If you are interested and have some free time please drop me an email with your hourly rates and any other info you think pertinent. Thanks in advance! Matt -- Schickian: An enthusiastic user of the Chicken Scheme compiler :-) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
> The only piece I see missing right now is that documentation can't be > posted to the wiki in a semanticly rich way from which other tools can > easily extract meaning. I will probably work on that. Seeing that this has been just around the corner for months, I decided to cross said corner today and start doing something about it. I have the following in wiki/stream-ext: > === stream-xcons > > > Of utility only as a value to be conveniently passed to higher-order > procedures. > > > (stream-xcons (stream 'b 'c) 'a) > # > (stream-xcons (stream 2 3 4) 1) > # > > > The name stands for "eXchanged CONS." > The output can be seen, obviously, in: http://galinha.ucpel.tche.br:8080/stream-ext#stream-xcons You can see the code that supports this in stream-wiki/trunk/extensions/chicken.scm. I would invite others to define new syntactic constructions by extending that file and sending patches (please do not commit directly to it) as a reply sent to the list to this mail so that we can all comment on the new proposals. Thanks. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
> Ivan raised a good point on the Hackathon1 page (where he asks that > people don't move his egg documentation out of the egg and into the > wiki, because it's a pain to deal with eggs that don't have a copy of > their docs in the egg directory itself). I'm not sure I understand the problem here, so I'll share *my* vision of how documentation for eggs should be handled in the ideal world. Documentation for egg foobar should live in the chicken-eggs repository, in wiki/foobar, in wiki format with some extensions for including semantics. By this I mean wiki syntax using tags such as ... , from where some semantics can be extracted by other tools. I oppose using XML or some similar format (eg. s-expr based format) on the basis that this would make it harder for our users to modify. Raising the bar required for editing, even if only slightly, can greatly reduce the number of contributions. Documentation for eggs should not leave in the eggs' directories. Instead, eggs should use the doc-from-wiki tag in their meta, so when the egg gets created the latest version of the documentation gets pulled from the wiki. Documentation in the wiki should be generated from previous eggdoc files only once. When that has happened and the documentation has been imported to the wiki, that should be considered the live version. Regenerating the stuff in the wiki from eggdocs in the future clashes against the spirit of encouraging users to help developers improve the documentation. Documentation should only live in one place: the wiki (with some additional semantics). HTML pages will be included with eggs if this happens, eggs authors can modify their documentation with their favorite editors and users can contribute and help improve it. The only piece I see missing right now is that documentation can't be posted to the wiki in a semanticly rich way from which other tools can easily extract meaning. I will probably work on that. Can you explain to me why it is a pain for some to deal with eggs that don't have a copy of their docs in the egg directory itself? Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
Well, I've been thinking about it, and perhaps it will be sufficient to have a tool that translates from eggdoc to wiki syntax along the lines of the following example. I would like to have fixed section names and some code in the wiki that checks that all of the required sections are present in the page. Also, it is not clear to me how to convert eggdoc procedure, macro, and symbol-table formatting elements to wiki format. == Name digraph == Description Directed graph in adjacency list format == Author ... == History * Version 1.1 ... * Version 1.0 Initial release == Requires [dyn-vector.html|dyn-vector] == Usage (require-extension digraph) == Download [digraph.egg|digraph.egg] == Documentation The digraph library is an implementation of a directed graph, where the edges are stored as adjacency lists. === Directed graph procedures The digraph object is created by procedure make-digraph, which is the only user-visible procedure defined in this egg: ; Procedure: make-digraph:: NAME INFO [NODE-LIST [SUCC-LIST [PRED-LIST]]] -> SELECTOR The returned selector procedure can take one of the following arguments: ; Describe name: returns the graph name (string or symbol) ; describe info: returns the graph metadata (arbitrary type) == Examples ;; example adapted from graph example in the Boost library documentation (require-extension srfi-1) (require-extension digraph) (define g (make-digraph 'depgraph "dependency graph")) == License ... Alejandro Forero Cuervo <[EMAIL PROTECTED]> writes: > > I'm not sure I understand what the problem here is. Could you > explain? > > Alejo. > http://azul.freaks-unidos.net/ > ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
> Then we could gradually add eggdoc-like markup to stream-wiki to the > point where it would be easy to write a script that automatically > converts eggdoc to wiki. Of course, this still doesn't solve the > problem with not having the documentation available in the SVN > repository. So any automatic operation on the repository, such as > building Debian packages for the eggs cannot work without manual > intervention. I'm not sure I understand what the problem here is. Could you explain? Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] egg documentation
> This I agree with 100%. I still haven't figured out why Chicken seems to be > spread across three different sites. > > http://galinha.ucpel.tche.br > http://chicken.wiki.br > http://www.call-with-current-continuation.org/ It should be noted that two of these are exactly the same, there's really no difference at all (chicken.wiki.br was added later as an alias and we haven't got rid of referenced to the old name). Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
> 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. I don't think this addresses all the problems that most wikis have for strong-editing: the fact that you can't edit your documents offline (ie. you have to get online to load the edit page or preview your changes) and the fact that browsers are prone to crash and make you lose hours of work. I prefer using a real editor outside of Firefox or other browsers. Which, as I said in the other message I sent to the list, is what lead me to create Svnwiki in first place. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] documentation issues...
> id like to entitle this next rant 'why wikis are highly suboptimal > for documentation', if i may. Well, I mostly agree with the points you are raising, which I would summarize as 'having to edit text for hours using a web interface sucks' (even if you use plugins or special browsers so that you are actually using a real editor for textareas). On the other hand, I think wikis have the draw of lowering the barrier to making changes to the point where people reading documents begin contributing. The extent to which this happens varies greatly from one website to the next (and even for specific pages in a website), but there are several examples of why this can work greatly. I started Svnwiki back in 2004 because I wanted a wiki system but I was not willing to go through what you just did: editing something for hours on an extremely limited text-editor risking just losing everything because the connection went away. On the other hand, I wanted to lower the barrier to collaboration. I've been using Svnwiki for lots of websites since then and I'm mostly happy with the overall experience. I migrated my weblog http://azul.freaks-unidos.net/ to it so I can write my posts through Vim (my favorite editor), commit and call it a day. I even support weblogs of other people (http://wiki.freaks-unidos.net/weblogs) and installations such as http://fsfla.org/svnwiki or, obviously, Chicken's. Of course, there have been some problems in the past when I have added lots of features in small intervals of time and I have introduced some unstability. Furthermore, installing Svnwiki has a reputation of being hard, as you have to (1) set up an Svn repository and (2) set lots of properties on it. Thirdly, getting all the dependencies installed, while not rocket science, had some complexity that should be eliminated (some day I'll get of my lazy butt and turn the Svnwiki extensions into eggs of their own so that they can be installed with chicken-setup, finally solving this problem). Fourthly, there seem to be some infrequent errors with the use of sqlite involving concurrent accesses to the database, which I haven't really got to debug or try to solve. With all that said, 4 years later I'm mostly happy with the results. :-) That said, you seem to also mention another point which is that, to you, the wiki syntax we use seems to be limiting: > what remains relevant is that its bloody hard to document anything > even slightly nontrivial in it. While this is not my perception, I've heard this claim in the past. I would like to see if Svnwiki can be improved in this area to make it easier for you and others like you to use it. Care to give me a few examples of concrete syntax forms that you think we should support and what they should parse to? Thanks and happy editing! :-) Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in SRFI-13 lib?
On 2/16/08, Kon Lovett <[EMAIL PROTECTED]> wrote: > On Feb 16, 2008, at 6:55 PM, Matt Gushee wrote: > > > Nonetheless, I've gotten accustomed to a world where datatypes are > > used very precisely to model the semantics of your problem domain. > > So when I see a function behaving in a way that implies semantics > > that aren't in the spec, it just doesn't feel right. Even if I know > > it's not really a problem in practice. > > Yeah, it isn't right. > > Some of the SRFI documents are not up-to-date with respect to the > reference implementation. This isn't true in general & the more > recent are probably in-sync. This issue happened to be pointed out on the post-finalization discussion archive for SRFI-13 a couple years ago, along with a little fix. http://srfi.schemers.org/srfi-13/post-mail-archive/msg6.html If you take a look at the pre-finalization discussions of SRFI-13, you'll find that the string<, string=, etc. procedures were originally intended to return a "mismatch index" along the lines of that described in string-compare. However, it was pointed out that if this behavior was required, it would preclude string= and string<> from simply short-circuiting based on comparison of the string lengths. So the mismatch index was changed to a boolean return value in the SRFI, with <, > etc. also changed to boolean for consistency. However, it seems Olin didn't modify the reference implementation to strictly obey this change--perhaps he found it useful or it just slipped by. It does do the quick length test, though. So the mismatch index shines through, but you rely on it at your own peril. This is all made a little more confusing by the lack of a final question mark on the end of these predicates--which sometimes indicates a "boolean-plus" value is intentionally being returned; in other words, either #f or a useful true value. Such is the case with memq, memv, etc. But the dropping of the ? was, as far as I can tell, done for aesthetic reasons only. Combine that with the historical baggage of the mismatch index and the behavior of the reference implementation, and you have a recipe for discombobulation. I hope this explanation made you feel a little better. ;) ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] wiki spam merging issue
> This makes sense. However, since spam is apparently bypassing authorization > --the index page can't be edited anonymously--and also logging, I was > concerned > there is a more critical underlying problem. It might even affect more than > the index page. I have upgraded the version of Svnwiki in Galinha and will try to keep an eye on it. It's strange that on conflicts it is not managing to revert the index file out of conflicts. I suspect there may be a bug in the underlying svn libraries. We'll see what happens now. If you see any other problems with the wiki, please bring them to my atention. Thanks. Alejo. http://azul.freaks-unidos.net/ ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
