Re: [Chicken-users] eval from string with long strings.
On Wed, Sep 3, 2008 at 4:50 PM, Heinrich Taube <[EMAIL PROTECTED]> wrote: > hi my c++ app statically links to libchicken 3.0.0 and i start a chicken > session like this: > HeapSize: 100 > StackSize: 64000 > > now, if i send chicken a long string to eval i get the error > > Error: not enough room for result string > > and my app crashes, which is really bad since editing windows with unsaved > work and everthing else dies. > > is there a way to tell chicken to allocate more room without such a hard > constraint? the string in sending to chicken (via eval_from_string) contains > an expression "(define foo '())" where is longish (35000 chars) > but lisp should be able to deal with this i think. Do you mean CHICKEN_eval_to_string() ? You should be able to pass a buffer-size that wll hold the result string. What arguments are you giving to the function? > > whats strange is that if i start CSI in the terminal and simply paste the > expr into csi it handles it. That doesn't go through CHICKEN_eval_to_string. The result is converted to a C string and we have to supply the maximal buffer size. In the interpreter the result is written to the console, and thus isn't limited to a particular length. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] TCP and threads again
On Thu, Sep 4, 2008 at 6:00 AM, Shawn Rutledge <[EMAIL PROTECTED]> wrote: > Experience confirms the unit TCP documentation which says that those > TCP socket operations do not block SRFI-18 threads, but what about > socket operations that occur via C code? It would seem that they do > block threads. I just ran into this when I tried to use my gps egg > (under development), which uses libgps to connect to gpsd, in an > application that has a UI. After the SRFI-18 thread which polls for > GPS messages gets started, the UI event loop never even gets a chance > to start. Makes me think the Chicken socket implementation must be > doing something special, not to block the threads. Am I going to run > into the same thing with dbus? I could use gypsy rather than gpsd > (because it has a dbus interface), but dbus comms are also done with > sockets. > C-level operations that block will block all threads. All Scheme-level thread operations are multiplexed in the scheduler into a big select(3) loop. By supplying a file-descriptor (as you mention in your followup mail) you can take advantage of this. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Re: TCP and threads again
Fortunately libgps gives me access to the FD so I was able to get around it with thread-wait-for-i/o! this time. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] TCP and threads again
Experience confirms the unit TCP documentation which says that those TCP socket operations do not block SRFI-18 threads, but what about socket operations that occur via C code? It would seem that they do block threads. I just ran into this when I tried to use my gps egg (under development), which uses libgps to connect to gpsd, in an application that has a UI. After the SRFI-18 thread which polls for GPS messages gets started, the UI event loop never even gets a chance to start. Makes me think the Chicken socket implementation must be doing something special, not to block the threads. Am I going to run into the same thing with dbus? I could use gypsy rather than gpsd (because it has a dbus interface), but dbus comms are also done with sockets. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Chicken SRFI 19 impl clips trailing ".0" when printing
Hello Jörg, The current release of the srfi-19 egg fixes the large integer display issue. (Note that the Chicken impl is not strictly the reference impl. Beyond extra functionality the internal arithmetic is hand-optimized; expression w/ a restricted range use domain specific operations.) After some thought I see the problem w/ changing the 'number->string' proc to clip a trailing ".0" for flonums is a bad idea. Chicken has no way of knowing that a fixnum -> flonum conversion has occurred; there is no way to distinguish a flonum used as an exact & a flonum used as an inexact. Best Wishes, Kon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] eval from string with long strings.
hi my c++ app statically links to libchicken 3.0.0 and i start a chicken session like this: HeapSize: 100 StackSize: 64000 now, if i send chicken a long string to eval i get the error Error: not enough room for result string and my app crashes, which is really bad since editing windows with unsaved work and everthing else dies. is there a way to tell chicken to allocate more room without such a hard constraint? the string in sending to chicken (via eval_from_string) contains an expression "(define foo '())" where is longish (35000 chars) but lisp should be able to deal with this i think. whats strange is that if i start CSI in the terminal and simply paste the expr into csi it handles it. any help on how to stop the crashing greatly appreciated. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross compilation setup
Am Dienstag, den 02.09.2008, 10:01 +0200 schrieb felix winkelmann:
> Hi!
>
>
> Try:
>
> PATH=:$PATH make PLATFORM=cross-linux-mingw
> PREFIX= install
What is this supposed to build? The host system, the target system or
both?
It did not work for me: looks for chicken.exe
> > !!! Use -host-extension - not -host as the wiki said. -host is the same
> > as -H and changes the download host name!
>
> Right, thanks for mentioning this.
I checked the current svn head. How it the -host-extension supposed to
work? I found:
> Now chicken-setup accepts the -host-extension and sets a parameter
> object, but does not evaluate it anywhere. (Therefore it tries to
> compile with the target instead the host compiler.) Around line 347 I
> changed:
> (define-macro (compile . explist)
> `(run (csc ,@(if (host-extension) '("-host") '()) ,@explist) ) )
/Jörg
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] hygienic named let
Hi! I think the reason for the (r 'apply) not working is that the initial macro definitions (in expand.scm) are created in an empty syntactic environment where (for example) `apply' is not visible yet. There is a fair amount of patching of SE's involved during this phase and during imports. Exactly this (the special treatment of primitive value bindings in the initial syntactic environments) is a tricky issue and probably not particularly well implemented. In any case it has caused many of the bugs you and others reported. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
