Re: [ANN] IUP Bindings

2010/9/30 Martin DeMello <martindemello <at> gmail.com>:
> On Thu, Sep 30, 2010 at 3:02 AM, Thomas Chust <chust <at> web.de> wrote:
>> in case anybody else finds this useful: I have created fairly full-featured
>> bindings for the IUP graphical user interface library [1] that work identically
>> (to the maximum possible extent) under the Racket [2] and CHICKEN [3]
>> Scheme systems.
>
> Very nice! How did you do the bindings?
> [...]

I simply wrote them manually, since the API is not that large.

Ciao,
Thomas

--

-- 
When C++ is your hammer, every problem looks like your thumb.

Re: I'm starting using chicken4 (Re: 4.6.1 performance boost

At Tue, 28 Sep 2010 19:36:32 +0200,
Peter Bex wrote:
> > I was heavily using the http egg in chicken3, which is
> > incompatible with chicken4.
> 
> Unfortunately, it is.  I like to think it's an improvement though :)

Yeah, I see that. It's clean.

> > In chicken3/http-server, I did something like:
> > (http:request-method-handler 'GET (lambda (req) ...
> > This is converted like the following in chicken4/spiffy.
> > (define (my-request-handler)
> >   (let* ([req (current-request)]
> >          [method (request-method req)])
> >     (case method
> >       ((GET) (lambda (req) ...)
> >       ((POST) (lambda (req) ...)
> > (vhost-map `((".*" .
> >               ,(lambda (continue)
> >                  (my-request-handler)))))
> 
> Yes, this is uglier.  There are several different request handling
> eggs now though!  They make it easier to handle incoming requests.

Is it that ugly?
None of the request handling eggs in the spiffy manual
was not so low level.

> Porting the old-style request handling stuff shouldn't be too hard,

how to handle http multipart/form-data

Dear Peter,

Another question regarding with chicken3->chicken4 porting.
I used the http-server-form-posts egg to handle multipart/form-data,
but the egg is not available (or not compatible) for chicken4.

How can I deal with mime multipart/form-data?

Best,
Daishi

Re: how to handle http multipart/form-data

On Sat, Oct 02, 2010 at 12:28:45AM +0900, Daishi Kato wrote:
> Dear Peter,
> 
> Another question regarding with chicken3->chicken4 porting.
> I used the http-server-form-posts egg to handle multipart/form-data,
> but the egg is not available (or not compatible) for chicken4.
> 
> How can I deal with mime multipart/form-data?

I'm afraid nobody has implemented this yet.

Cheers,
Peter
--

-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
							-- Donald Knuth

Re: I'm starting using chicken4 (Re: 4.6.1 performance boost

On Sat, Oct 02, 2010 at 12:22:22AM +0900, Daishi Kato wrote:
> > Yes, this is uglier.  There are several different request handling
> > eggs now though!  They make it easier to handle incoming requests.
> 
> Is it that ugly?
> None of the request handling eggs in the spiffy manual
> was not so low level.

I'm confused; do you think the eggs are lower-level than your code, or
do you think the spiffy code itself is low-level, or what?

> I don't understand the discussion here. How felix isn't happy?

He's unhappy that the way to define request handlers has become so
much more complicated.

> I thought the vhost support is very powerful.

It is, but it comes at the price of not being able to simply define
request handlers at the global path level, since those would apply
to all vhosts.

> > > There were many tiny things for porting my code, such as dealing
> > > with the fancy uri-common egg and string-match -> string-search.
> > 
> > Are you using "fancy" in a good way or in a bad way?  I'm really eager
> > to hear how these new http libraries are being used and how people like
> > them, so I can improve where things are not as smooth as they should be.
> 
> Good question. I used "fancy" in a good way, but if you ask me:

srfi-34

I found the srfi-34 egg not working nice together with srfi-18 and when
mixed with chicken's exceptions.

Find attached an implementation, which fixes this.

_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users

Installing data files for eggs

Hi all,

Is there a proper way to install data files from egg .setup-files?
I couldn't find anything at http://wiki.call-cc.org/manual/Extensions
so I rolled my own for the "slatex" egg:

---
(define style-path
  (list (installation-prefix) "share" "chicken" "slatex"))

;; <snipped: code to build style-path into to the program>

(copy-file "slatex.sty" (make-pathname style-path "slatex.sty"))
(copy-file "slatex-chicken.sty" (make-pathname style-path "slatex-chicken.sty"))
(copy-file "cltl.sty" (make-pathname style-path "cltl.sty"))
---

The disadvantages are obvious: these files don't get uninstalled by
chicken-uninstall and Chicken's data files aren't necessarily installed
under $PREFIX/share/chicken  (the user can override $DATADIR on the Make
invocation when building Chicken).

So, I think it would be a good idea to add something like this to
setup-api:

(define style-path (data-path-for-extension 'slatex))

(install-data 'slatex
              '("slatex.sty" "slatex-chicken.sty" "cltl.sty")
              `((version ,slatex-version))) ;; If this makes sense?

Re: Installing data files for eggs

On Sat, Oct 02, 2010 at 08:55:59PM +0200, Peter Bex wrote:
> 
> Is there a proper way to install data files from egg .setup-files?
> I couldn't find anything at http://wiki.call-cc.org/manual/Extensions
> so I rolled my own for the "slatex" egg:
> 
> ---
> (define style-path
>   (list (installation-prefix) "share" "chicken" "slatex"))
> 
> ;; <snipped: code to build style-path into to the program>
> 
> (copy-file "slatex.sty" (make-pathname style-path "slatex.sty"))
> (copy-file "slatex-chicken.sty" (make-pathname style-path "slatex-chicken.sty"))
> (copy-file "cltl.sty" (make-pathname style-path "cltl.sty"))
> ---
> 
> The disadvantages are obvious: these files don't get uninstalled by
> chicken-uninstall and Chicken's data files aren't necessarily installed
> under $PREFIX/share/chicken  (the user can override $DATADIR on the Make
> invocation when building Chicken).

Hi Peter,

I'm really not *that* knowledgeable about egg installation. But I have
been writing packaging scripts for most of the eggs, for the Arch Linux
user repository. From that experience, I got the following impressions:

1. You're right, you shouldn't hard-code share/chicken/slatex in the way
you do. But this would work instead:

Re: Installing data files for eggs

On Sat, Oct 02, 2010 at 06:40:59PM -0400, Jim Pryor wrote:
> Hi Peter,

Hi Jim,

> I'm really not *that* knowledgeable about egg installation. But I have
> been writing packaging scripts for most of the eggs, for the Arch Linux
> user repository. From that experience, I got the following impressions:
> 
> 1. You're right, you shouldn't hard-code share/chicken/slatex in the way
> you do. But this would work instead:
> 
> -(define style-path
> -  (list (installation-prefix) "share" "chicken" "slatex"))
> +; also declare additional dependency on setup-helper
> +(include "setup-helper")
> +(define style-path
> +  (list (installation-chicken-home) "slatex"))

That's perhaps slightly better from a readability point of view, but
installation-chicken-home is just an alias for
{installation-prefix}/share/chicken so in reality all this does is
add a depedency on the setup-helper egg.

> 2. And that's where you should be copying your slatex.sty etc. files. Is
> it really true that files copied in that way don't get uninstalled by
> chicken-uninstall?

Yes, the install-* procedures register their files in a database.
Chicken-uninstall simply looks there and removes all registered items.