Matt Gushee | 1 Jun 01:06 2009
Picon

Re: Scope problem?

Peter Bex wrote:
> On Sun, May 31, 2009 at 04:11:27PM -0600, Matt Gushee wrote:
>> So, do I need further education, or should I report a bug?
> 
> I think we need to see the actual code to your fastcgi port to know more.
> By the way, string-length is a R5RS procedure, so you shouldn't
> need srfi-13.  (which makes it extra-odd that it works when you load
> srfi-13)

Sorry, it wasn't string-length, it was string-index. Also, one more 
detail that may be relevant: in this exploratory phase of development, I 
am running the code script-style, i.e. the script begins w/

   #!/usr/local/bin/chicken -script

Anyway, the fastcgi module code follows. I didn't change much:

  * Replace the old unit declarations with appropriate module
    declarations.

  * Changed miscellaneous foreign types as necessary.

  * Replaced a define-foreign-record section w/
    define-foreign-record-type

  * Replaced all instances of make-property-condition with
    make-exn-condition

  * Replaced the byte-vector in (get-scheme-str) with a u8vector.

(Continue reading)

Peter Bex | 1 Jun 01:20 2009
Picon
Picon

Re: Scope problem?

On Sun, May 31, 2009 at 05:06:37PM -0600, Matt Gushee wrote:
> Sorry, it wasn't string-length, it was string-index.

OK, that clarifies it a bit ;)

> -- BEGIN fastcgi.scm ------------------------------------------------
> 
> [ copyright notice omitted ]
> 
>   ( import scheme
>            chicken
>            matchable
>            lolevel
>            srfi-1
>            srfi-4
>            srfi-13
>            foreign
>            foreigners
>            conditions )
  [code]

Import simply loads the import library (FOO.import.so) for each library
FOO you import, it doesn't actually load the library itself.  This makes
no difference for "built-in" libraries that are part of libchicken.so,
but for matchable, srfi-4, srfi-1, foreigners and srfi-13 you will have
to add a statement to load them as well.

You can either add (require-library srfi-13 srfi-1 srfi-4 matchable foreigners)
to your code, or replace the import and require-library pair with one
(use ...) or one (require-extension ...) expression.
(Continue reading)

Matt Gushee | 1 Jun 01:44 2009
Picon

Re: Scope problem?

Peter Bex wrote:

> Import simply loads the import library (FOO.import.so) for each library
> FOO you import, it doesn't actually load the library itself.  This makes
> no difference for "built-in" libraries that are part of libchicken.so,
> but for matchable, srfi-4, srfi-1, foreigners and srfi-13 you will have
> to add a statement to load them as well.
> 
> You can either add (require-library srfi-13 srfi-1 srfi-4 matchable foreigners)
> to your code, or replace the import and require-library pair with one
> (use ...) or one (require-extension ...) expression.
> 
> Hope this helps!

Well, it helps me to investigate further. But I don't think the actual 
behavior I have observed quite matches your explanation. For example, it 
appears that just about any FastCGI request will access symbols defined 
in foreigners and matchable, yet I have not seen any errors related to 
those extensions (or rather, I did at first, but not after I added the 
declarations to import them).

Also, I notice that matchable and foreigners are eggs, while srfi-1, -4, 
and -13 are ... umm, what are they? They are installed with the core 
distribution, and listed in the Supported Language section of the Manual
--but you say they should be treated as extensions?

--

-- 
Matt Gushee
: Bantam - lightweight file manager : matt.gushee.net/software/bantam/ :
: RASCL's A Simple Configuration Language :     matt.gushee.net/rascl/ :
(Continue reading)

Jeremy Sydik | 1 Jun 06:53 2009

Re: Scope problem?

I actually ported this a few weeks back and have been running with no  
problems.  The original author, Alex Drummond was going to email Felix  
to get me hooked up to commit the new egg, but I haven't heard what  
has become of that.  In the meantime, here's the code:

Attachment (fastcgi.scm): application/octet-stream, 15 KiB
Attachment (fastcgi.setup): application/octet-stream, 249 bytes

On May 31, 2009, at 6:44 PM, Matt Gushee wrote:

> Peter Bex wrote:
>
>> Import simply loads the import library (FOO.import.so) for each  
>> library
>> FOO you import, it doesn't actually load the library itself.  This  
>> makes
>> no difference for "built-in" libraries that are part of  
>> libchicken.so,
>> but for matchable, srfi-4, srfi-1, foreigners and srfi-13 you will  
>> have
>> to add a statement to load them as well.
>> You can either add (require-library srfi-13 srfi-1 srfi-4 matchable  
>> foreigners)
>> to your code, or replace the import and require-library pair with one
>> (use ...) or one (require-extension ...) expression.
>> Hope this helps!
>
> Well, it helps me to investigate further. But I don't think the  
(Continue reading)

Peter Bex | 1 Jun 11:05 2009
Picon
Picon

Re: Scope problem?

On Sun, May 31, 2009 at 05:44:10PM -0600, Matt Gushee wrote:
> Well, it helps me to investigate further. But I don't think the actual 
> behavior I have observed quite matches your explanation. For example, it 
> appears that just about any FastCGI request will access symbols defined 
> in foreigners and matchable, yet I have not seen any errors related to 
> those extensions (or rather, I did at first, but not after I added the 
> declarations to import them).

This is caused by a technicality; the symbols from these eggs that you
are using map to macros.  Macros are eliminated at compile time, and
therefore not part of the library itself, but they're part of the import
library, instead.  You can see this if you compile foreigners or
matchable with -j and take a peek at the generated import.scm file.
The macro code is right there.

In fact, the matchable.so shared library is almost completely empty;
the compiled stuff all ends up in the import library!  This is why
your code still works even though you're not loading the actual
libraries for matchable and foreigners.

It's a good habit to load the library even if you know that the library
has only macros, for this reason: a macro might expand to code that uses
helper procedures which are defined in the library.  Even if they're not
doing that currently, they might in the future.

> Also, I notice that matchable and foreigners are eggs, while srfi-1, -4, 
> and -13 are ... umm, what are they? They are installed with the core 
> distribution, and listed in the Supported Language section of the Manual
> --but you say they should be treated as extensions?

(Continue reading)

Alexey Bakhirkin | 1 Jun 17:48 2009
Picon

Syntax-rules seems not to rename identifiers correctly

;This is sample code (also can be found in attachment):
(define-syntax define/bug
 (syntax-rules ()
   ((_ name foo-value)
    (begin
     (define foo foo-value) ;Here we introduce a binding to "foo" and
expect it not to be visible as "foo" outside macro definition.
     (define name
       (lambda () foo))))))

(define/bug first "first")
(display foo)(newline)        ;Displays "first", but "foo" is not
expected to be defined at all. Seems, that the macro does not rename
it.
(display (first))(newline)    ;Displays "first" as expected

(define/bug second "second")
(display (second))(newline)   ;Displays "second" as expected
(display foo)(newline)        ;Displays "second". The second macro
expansion redefines "foo".
(display (first))(newline)    ;Displays "second". So, both macros
share one "foo".
Attachment (chicken-bug-report.2009-05-01): application/octet-stream, 7886 bytes
_______________________________________________
Chicken-users mailing list
Chicken-users <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
(Continue reading)

Matt Gushee | 2 Jun 02:33 2009
Picon

Re: Scope problem?

Jeremy Sydik wrote:
> I actually ported this a few weeks back and have been running with no 
> problems.  The original author, Alex Drummond was going to email Felix 
> to get me hooked up to commit the new egg, but I haven't heard what has 
> become of that. 

Great, I'll check it out--I'm interested to see what, if anything, I did 
differently from you.

--

-- 
Matt Gushee
: Bantam - lightweight file manager : matt.gushee.net/software/bantam/ :
: RASCL's A Simple Configuration Language :     matt.gushee.net/rascl/ :
Matt Gushee | 2 Jun 02:44 2009
Picon

Re: Scope problem?

Peter Bex wrote:

> Hope this helps some more ;)

Yes, very much. I think it would be even better if we could get have 
some of this clearly explained in the manual. Maybe some of it already 
is, yet somehow ... I have long felt that there is a problem with the 
documentation of Chicken and maybe other Scheme implementations. I'm not 
sure quite how to explain it, but I do believe this is a major obstacle 
for people learning how to do practical work with Scheme.

Perhaps this is something I can help with. I have some tech writing 
experience, and maybe an idea or two for how the docs can be improved. 
Let me think about this.

--

-- 
Matt Gushee
: Bantam - lightweight file manager : matt.gushee.net/software/bantam/ :
: RASCL's A Simple Configuration Language :     matt.gushee.net/rascl/ :
Kon Lovett | 2 Jun 06:46 2009
Picon

Re: How to deal with bit sets in chicken?


On May 30, 2009, at 10:36 AM, Anthony Carrico wrote:

> For example, according epoll_ctl(2) on the Linux AMD64 platform, the
> following are __uint32_t.
>
> (foreign-declare "#include <sys/epoll.h>\n")
> (define-foreign-variable _EPOLLET unsigned-integer32 "EPOLLET")
> (define EPOLLET _EPOLLET)
> (define-foreign-variable _EPOLLONESHOT unsigned-integer32  
> "EPOLLONESHOT")
> (define EPOLLONESHOT _EPOLLONESHOT)
>
> #;2> EPOLLET
> 1.84467440715621e+19
> #;3> EPOLLONESHOT
> 1073741824
> #;4>
>
>
> Here I declare them as int:
>
> (define-foreign-variable _EPOLLET int "EPOLLET")
> (define EPOLLET _EPOLLET)
> (define-foreign-variable _EPOLLONESHOT int "EPOLLONESHOT")
> (define EPOLLONESHOT _EPOLLONESHOT)
>
> #;8> EPOLLET
> -2147483648
> #;9> EPOLLONESHOT
(Continue reading)

felix | 2 Jun 10:21 2009
Picon

Re: Easyffi

bill <RamsayW1 <at> comcast.net> writes:

> 
> Hi again,
> 
> I'm still trying to get back into run m ode with Xubuntu and now I'm 
> finding a problem with easyffi.
> I use gtk+ in my user interface and access it through easyffi.    This 
> is an old program that's worked for a long time - including in 
> Chicken-4.0.0 on Gentoo.   It compiles fine, but now I get the following 
> runtime error:
> 
> Error: unbound variable: foreign-parse
> 
>     Call history:
> 
>     foreign-parse            <--
> 
> The offending lines are only in the c code - I don't  use 
> 'foreign-parse' anywhere  in the  scheme  code.
> 
> Any ideas on what could be wrong?   I rather like the Xubuntu 
> distribution and would hate to go back to Gentoo.
> 

Hi, Bill!

Are you using "#>?" in your code? Are you using the module
system? And if yes, are you doing the "#>?" inside a module
declaration that imports "easyffi"? Can you try to replace 
(Continue reading)


Gmane