[Chicken-users] [new egg] pilgrim
I've been working on another http engine for chicken (I know, reinventing the wheel. but it seemed like a fun way to learn about how it worked). Anyway, it was fine to keep my code vendored up in the only project using it, but I want to use it in a second project, and as far as I can tell with the existing infrastructure I need to package it up and distribute it as an egg. Can someone with commit access please add: https://raw.github.com/richo/pilgrim/master/pilgrim.release-info To the relevant locations (and let me know if I did it right? I couldn't see an obvious way to have (requires pilgrim) result in master being checked out while I'm still hacking on it. I followed this: http://wiki.call-cc.org/releasing-your-egg#github-git Finally, I think this may be my first post to the list, so; Hi! Cheers richo -- richo || Today's excuse: virus attack, luser responsible http://blog.psych0tik.net signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [new egg] pilgrim
On 13/01/13 16:02 +0100, Peter Bex wrote: On Mon, Jan 14, 2013 at 12:31:35AM +1100, richo wrote: I've been working on another http engine for chicken (I know, reinventing the wheel. but it seemed like a fun way to learn about how it worked). We don't mind, in fact we slightly encourage a sense of anarchy and diversity in our extensions. Anyway, it was fine to keep my code vendored up in the only project using it, but I want to use it in a second project, and as far as I can tell with the existing infrastructure I need to package it up and distribute it as an egg. Can someone with commit access please add: https://raw.github.com/richo/pilgrim/master/pilgrim.release-info To the relevant locations (and let me know if I did it right? Done! You did it right, AFAICT So I just post to the list again with each new version? Or will it enumerate my tags automagically? I couldn't see an obvious way to have (requires pilgrim) result in master being checked out while I'm still hacking on it. Well, that's indeed not supported. The distributed egg repository only supports publishing released eggs with a given version. You'll need to tag a release and add this release to the release-info file for it to be installable. After pushing this, the egg should appear on the main server within the hour. I think Alaric's mirror takes a little longer to show up. Thinking about it, it should be pretty easy to develop new features in my application, and when they're stable push them back into pilgrim to be generally consumable, and then bump the patchlevel. This is probably a saner way to do it anyway. I followed this: http://wiki.call-cc.org/releasing-your-egg#github-git Excellent. If you had any difficulty I'd love to get feedback on this. So far it was good. A few weird loops I ended up in, I might put together some thoughts tomorrow. Finally, I think this may be my first post to the list, so; Hi! Hello! Welcome! Please help yourself to some tasty code :) Thanks I've been hacking on and off on various scheme projects for a few months, I'm on #chicken semi-regularly. Cheers, Peter -- http://sjamaan.ath.cx ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users -- richo || Today's excuse: Power company testing new voltage spike (creation) equipment http://blog.psych0tik.net signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Egg: redis bindings
On 23/01/13 20:59 -0500, Andrei Barbu wrote: Hi, I put up an egg that has high-performance redis bindings using hiredis. It's much faster (>100x) than the current egg and it doesn't suffer from timeout issues. Provides a pretty bare-bones API. I've put up docs on the wiki: https://wiki.call-cc.org/eggref/4/redis And the egg is available from: https://github.com/abarbu/redis-chicken Could someone make this accessible via chicken-install? Thanks! I'd also appreciate if someone had a look at the meta/release-info/setup files and let me know if I'm doing something inappropriate. Awesome, I wrote a small library that's current backed onto either flat files or redis at the deployers option, I'll have a play with this in the evening! Cheers Richo -- richo || Today's excuse: The monitor is plugged into the serial port http://blog.psych0tik.net signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [patch] remove the initial check on directory existance
This patch removes the internal check for directory existance in create-directory, meaning that it can be treated as atomic on platforms where mkdir(2) is. -- richo || Today's excuse: IRQ dropout http://blog.psych0tik.net From 3e1d5c55b3673403a8a1a69638ffe7083c09967c Mon Sep 17 00:00:00 2001 From: richo Date: Sun, 3 Feb 2013 02:14:24 +1100 Subject: [PATCH 1/2] create-directory: Remove the internal check for existance This causes the EEXIST to be raised, and brings the unix implementation inline with win32 --- posixunix.scm | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/posixunix.scm b/posixunix.scm index 9de549f..7e5a9c5 100644 --- a/posixunix.scm +++ b/posixunix.scm @@ -766,8 +766,7 @@ EOF (lambda (name #!optional parents?) (##sys#check-string name 'create-directory) (let ((name (##sys#expand-home-path name))) - (unless (or (fx= 0 (##sys#size name)) - (file-exists? name)) + (unless (fx= 0 (##sys#size name)) (if parents? (let loop ((dir (let-values (((dir file ext) (decompose-pathname name))) (if file (make-pathname dir file ext) dir -- 1.8.1.2 signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
On 02/02/13 11:16 -0600, Jim Ursetto wrote: I am positive this is a case where the documentation was written to explain an implementation artifact. That note wasn't added until 11 months ago ... by Mario. The current implementation returns "foo" if a file foo (not just a directory foo) already exists. No one is ever going to check this return value. It seems to me if regular file "foo" exists it should be an error. I don't think it's atomic any more if you ignore EEXISTS, because 1) the existing directory could be owned by the wrong person 2) it might still be a regular file 3) when used to implement dotlocking, the caller needs to know whether EEXISTS was returned, akin to using O_CREATE|O_EXCL. Unfortunately as Peter suggested, I doubt we could change the behavior to error out when the directory exists, because some code probably relies on it. I think we could error out on regular file existing, i.e. change file-exists? to directory-exists? or perhaps check type after the fact on EEXISTS. But making it atomic would probably require a new procedure name, which does not check for existence beforehand and does not ignore EEXISTS. You could still ignore EEXISTS if creating the full path (parents? == #t). This is then like mkdir -p. It's how I would expect it to behave and preserves atomicity. This could potentially go in the posix-extras egg. Jim Thanks all for your feedback. Also, apologies for posting this to -users and not -hackers as I should have done. Based on this feedback I'd like to: 1) Change create-directory to only test for directory existance, leaving the current behaviour in place for already existing directories to avoid breaking backwards compatibility. It's worth noting that win32 doesn't currently do this. Should I fix (break, depending on your perspective) that implementation? 2) Refactor create-directory into posix-common.scm and only have the platform specific bindings in the platform specific code. 3) expose a new function that raises errors if the directory exists so that an atomic mkdir is available. My thought is to just name it mkdir, but I'm not sure where it belongs. Cheers richo -- richo || Today's excuse: Borg implants are failing http://blog.psych0tik.net signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [patch] remove the initial check on directory existance
On 03/02/13 11:42 +0100, Peter Bex wrote: On Sun, Feb 03, 2013 at 06:42:55PM +1100, richo wrote: 3) expose a new function that raises errors if the directory exists so that an atomic mkdir is available. My thought is to just name it mkdir, but I'm not sure where it belongs. Please don't do that. This sort of "design" leads to mysql_real_escape_string. It's confusing to the user, and ugly to have several differently named procedures that do almost exactly the same thing but with slight differences in behavior. Better to either keep it the way it is, change the semantics and breaking compat (so be it), or convert to keyword args and make it an optional feature (my least favorite alternative). Cheers, Peter Awesome, I guess with that said, I need someone who's more planted in the project to make a call so I know which way to jump. My preference is certainly to change the semantics and have a unified implementation without weird caveats, but I can't speak for how much code it'll break. I have a patch ready, but I can't test it as I can't get the test suite to work (followup post to -hackers incoming) Thanks again Richo -- richo || Today's excuse: The Dilithium Crystals need to be rotated. http://blog.psych0tik.net signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] [ANN] Zephyros Chicken bindings (attn osx users)
Today sdegutis merged my CHICKEN bindings for Zephyros[1] a display and window manager for OSX. I'd love a) For people to use it, and b) feedback on the code. The bindings[2] and my config[3] are both on github. [1]: https://github.com/sdegutis/zephyros [2]: https://github.com/sdegutis/zephyros/blob/master/libs/zephyros.scm [3]: https://github.com/richo/dotfiles/blob/master/zeph.scm -- richo || Today's excuse: Backbone Scoliosis http://blog.psych0tik.net signature.asc Description: Digital signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] Zephyros Chicken bindings (attn osx users)
On 12/09/13 11:04 +0200, Moritz Heidkamp wrote:
Hey Richo,
thanks for your contribution to the Chicken ecosystem!
richo writes:
I'd love a) For people to use it, and b) feedback on the code.
As for a), I'm not an OS X user so I can't but as for b) I figured I can
give you a small hint:
(define (send datum thunk)
(call/next-id (lambda (id)
(register-callback id thunk)
(with-output-to-port zeph-out (lambda ()
(let* ((payload (apply vector id datum))
(json-payload (json->string payload)))
(write-string json-payload)
(write-string "\n"
id)))
Here you can just immediately serialize JSON into the output port using
`(write-json payload)`. Also, I would advise you not to use
`with-output-to-port` but instead pass the port to write calls
explicitly as implicitly redirecting output can be a source of very
subtle bugs :-)
I missed that in the refactor. The original protocol required you to send the
number of bytes in the json, as an ascii string, then a newline, then the
json.
I'll fix it in a sec. I'll also start explicitly using the port. Where can I
read more about these subtle bugs?
I'm not sure I understand how `send-get-value` works. It kind of looks
too clever to me but maybe I'm missing something.
Potentially. There are a ton of future'esque excamples, but this seemed
simplest. Basically a value (or more than one) will be returned by the
backend. This procedure just exposes a sync api on top of it.
The reason for the (mainloop) call is that otherwise the initial call returns
a garbage value and breaks everything. I've implemented the same logic with
the call/foo and foo implementations, and they seem equal (but I might be
missing something).
Thanks for the feedback
--
richo || Today's excuse:
Our ISP is having {switching,routing,SMDS,frame relay} problems
http://blog.psych0tik.net
signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] [ANN] FUSE interface
On 25/12/13 10:26 +1300, Evan Hanson wrote: There is now a FUSE[1] interface available: http://wiki.call-cc.org/egg/fuse It's been only lightly tested so far, so I'd appreciate hearing about any issues people have with it, especially troubles installing or running the examples. Happy holidays, Evan [1]: http://fuse.sourceforge.net/ I for one salute you, you have made my festivus. Have you done any benchmarking or profiling against other high level wrappers around fuse? -- richo || Today's excuse: Power surges on the Underground. http://blog.psych0tik.net pgpWccD8Qg7N0.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] CHICKEN at 31C3
On 30/10/14 01:12 +0100, Christian Kellermann wrote: Hi there, I have registered an assembly for CHICKEN enthusiasts and other lispy people for the upcomming 31C3: https://events.ccc.de/congress/2014/wiki/Assembly:The_%28un%29employed_schemers_%26_lispers_guild If you can make it to Hamburg, I am looking forward to hacking with you there! Cheers, Christian I will definitely swing by and say hello- although i won't be writing any scheme unless I can find an excuse to use it in the ctf :) ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] New egg: clucker (Twitter API)
On 30/06/15 15:43 -0400, Nick Van Horn wrote: Hello fellow chickeneers, I'm happy to announce the first release of the "clucker" egg, which provides access methods to Twitter's public api endpoints. Currently, the egg: * Provides access to all (two) public streaming api endpoints (https://dev.twitter.com/streaming/public). * Provides access to all GET methods on the REST api (https://dev.twitter.com/rest/public). * Includes oauth procedures for handling credentials (via the oauth egg). * Provides customizable parameters for each api call that control how returned data is processed. Default behavior is simply `read-line`, which means you get strings of json in return. This can be easily set to something more useful such as `read-json` from the medea egg. I've been successfully using the egg in an application I've been developing. I've written some procedures for this other application that handle things such as rate limits (api requests are limited by number of calls, and reset after set amounts of time), pagination of results, etc. If others are interested, I'd be happy to share what I've done, or simply include these procedures in the clucker egg. A big TODO is to add the remaining REST api POST methods, which have been ignored to date due to me not needing them in my other project :P If one of the maintainers (Mario?) could add this to the egg repository I would appreciate it. The egg passes salmonella and should be ready to go. You can find the repo at https://github.com/n3mo/clucker Cheers! Nick Hey Nick, This looks great! Do you have any example code that consumes it? I've been wanting to write a new CLI twitter client for a while now, some sample code to get a feel for what actually consuming the API looks like would be really handy. Cheers richo ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
