Re: [Chicken-users] Numbers weirdness

2016-04-01 Thread John Cowan
Andy Bennett scripsit:

> I'm mostly using log2 to work out if numbers are a power of two and find
> the highest bit that they have set.

You can use integer-length to tell how many bits are required.  If you
subtract 1 and the number of bits shrinks by 1, you have a power of 2.

Rules for WWI pilots:

1.  Stay out of WWII.


--Peanuts

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] CHICKEN hang / crash / memoize egg

2016-04-01 Thread Peter Bex
On Fri, Apr 01, 2016 at 03:28:26PM +0100, Andy Bennett wrote:
> Hi Peeps!
> 
> I'm running CHICKEN 4.9.0rc1 and I'm trying out the memoize egg.
> 
> I saw the tail-call-optimized version of the factorial procedure in the
> memoize documentation at http://api.call-cc.org/doc/memoize and I've
> been trying to modify it so that it memoizes intermediate results such
> that, for example, a call to (fact 10) makes a subsequent call to (fact
> 9) fast.
> 
> Sometimes I'll crash immediately and someytimes I have to press some
> keys when the "#;8>" prompt appears.
> 
> Is this a known bug in Chicken 4.9.0rc1 or the srfi-69 hash-tables that
> memoize uses?

There are two problems.  In your code you don't limit the size of the
memoized hash table, which means it won't ever delete anything from its
hash tables.

The other problem seems to be in the memoize egg: there, even if you do
set a limit, the check for the hash table size occurs at precisely the
wrong place in the recursion.  It checks the size, then calls the
procedure and when it returns, the result is stored in the hash table.

Let's say we put a limit of 1.  Then we call (memoized-fact 3).
It will determine (3) doesn't exist yet, and that the cache size is 0.
Then it will actually call (original-fact 3), which calls memoized-fact
recursively as (memoized-fact 2).  In the recursion, the cache is still
empty and there's no entry for (2).  So it calls (original-fact 2) to
determine the result to store.  This calls (memoized-fact 1), which
enters with an empty cache and (1) doesn't exist yet.  Then it calls
(original-fact 1), which returns with 1 immediately.

When it returns, the result is stored in the hash table for args = (1).
This returns its value to the pending continuation which will
calculate 2, which is then stored in the cache for (2) and returned to
the pending continuation which will calculate our final result 6, which
is stored in the cache for (3) and then finally returned.

After all this, the cache's size is 3 even though we capped it to a
limit of only 1 item!  Also, the numbers you're storing _are_ really
large (the final result requires over 59KiB to store the number), and
because all the intermediate results are retained because the cache
isn't ever cleared, it's no wonder you're running out of heap size.

The attached patch fixes the problem, as long as you do set a limit,
using (define memo-fact** (memoize fact** 10)).  In fact, you can set
a limit of 1 if you want; the outermost recursion step is the one that
will never be deleted.

A proper test suite should:

a) ensure the procedure is only called as many times as necessary to
   generate new values for uncached values.  Fibonacci would be great
   for measuring this: it should be called n times instead of n^2 times.
b) ensure that the cache limit is obeyed.  This is trickier to write a
   test for.  Maybe something that is called in a sequence that looks
   like 1, 1, 2, 2, 3, ... n, n, ... 3, 3, 2, 2, 1, 1 would be useful:
   in that case it should be called exactly 2n times if the limit is < n,
   unless I'm wrong.  You'd then have to make a few variants of the
   memoized procedure, with limits around the edge cases n, n-1, n+1
   and check if the original procedure is called 2n times or 4n times.

I'm sure smarter people than myself can come up with a better way to
test this.

Cheers,
Peter
From 6e0077bacabbdc270302e89c9f0f0a12240ae0c3 Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Fri, 1 Apr 2016 20:20:12 +0200
Subject: [PATCH] Fix caching bug which caused the limit to be ignored during
 recursion

---
 memoize.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/memoize.scm b/memoize.scm
index 681ca13..8612404 100644
--- a/memoize.scm
+++ b/memoize.scm
@@ -51,11 +51,11 @@
  (lambda args
(let ((results (hash-table-ref/default cache args not-found)))
 	 (cond ((eq? results not-found)
-		;; Avoid a huge cache by deleting random keys if limit is determined. 
-		(and limit (>= (hash-table-size cache) limit) (delete-random-key! cache))
 		(let ((results (call-with-values 
    (lambda () (apply proc args))
    list)))
+		  ;; Avoid a huge cache by deleting random keys if limit is determined.
+		  (and limit (>= (hash-table-size cache) limit) (delete-random-key! cache))
 		  (hash-table-set! cache args results)
 		  (apply values results)))
 	   (else
-- 
2.1.4



signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] CHICKEN hang / crash / memoize egg

2016-04-01 Thread Arthur Maciel
Dear Andy, good to know you are playing with the memoize egg. ATM I don't
have time to look deeper into the problem you pointed out. Sorry for that.
After I finish some personal stuff I'll dig into it.

Cheers,
Arthur
Em 01/04/2016 11:56, "Andy Bennett"  escreveu:

> On 01/04/16 15:28, Andy Bennett wrote:
> > Hi Peeps!
> >
> > I'm running CHICKEN 4.9.0rc1 and I'm trying out the memoize egg.
> >
> > I saw the tail-call-optimized version of the factorial procedure in the
> > memoize documentation at http://api.call-cc.org/doc/memoize and I've
> > been trying to modify it so that it memoizes intermediate results such
> > that, for example, a call to (fact 10) makes a subsequent call to (fact
> > 9) fast.
> >
> > In doing so I've managed to get the interpreter into a loop or crash it
> > entirely.
> >
> >
> > When pasting this into a csi prompt:
> >
> > -
> > (use numbers)
> > (use memoize)
> >
> > (define (fact** x #!optional (self memo-fact**))
> >   (if (= x 0)
> > 1
> > (* x (self (- x 1)
> >
> > (define memo-fact** (memoize fact**))
> >
> > (define x (time (memo-fact**  35710)))
> > (define x (time (memo-fact**  35720)))
> > (define x (time (memo-fact**  35730)))
> > -
> >
> > I get:
> >
> > -
> > $ csi
> >
> > CHICKEN
> > (c) 2008-2014, The Chicken Team
> > (c) 2000-2007, Felix L. Winkelmann
> > Version 4.9.0rc1 (rev 3cf1967)
> > linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
> > compiled 2014-04-17 on hd-t1179cl (Linux)
> >
> > ; loading /home/local/andyjpb/.csirc ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/parley.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/chicken.import.so ...
> > ; loading
> > /usr/local/chicken-4.9.0/lib/chicken/7/data-structures.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/extras.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/ports.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/posix.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/srfi-1.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/srfi-13.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/srfi-18.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/stty.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/srfi-69.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/foreign.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/foreigners.import.so
> ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/parley.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/stty.so ...
> > #;1> (use numbers)
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/numbers.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/numbers.so ...
> > #;2> (use memoize)
> > #;2>
> > #;2> (define (fact** x #!optional (self memo-fact**))
> > #;2>   (if (= x 0)
> > #;2> 1
> > #;2> (* x (self (- x 1)
> > #;2>
> > #;2> (define memo-fact** (memoize fact**))
> > #;2>
> > #;2> (define x (time (memo-fact**  35710)))
> > #;2> (define x (time (memo-fact**  35720)))
> > #;2> (define x (time (memo-fact**  35730)))
> > #;2>
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/memoize.import.so ...
> > ; loading /usr/local/chicken-4.9.0/lib/chicken/7/memoize.so ...
> >
> > Note: the following toplevel variables are referenced but unbound:
> >
> >   memo-fact** (in fact**)
> > 2.804s CPU time, 1.064s GC time (major), 81305 mutations, 21/1551 GCs
> > (major/minor)
> > 0s CPU time, 20 mutations
> > 0s CPU time, 20 mutations
> > #;8>
> > [panic] out of memory - heap full while resizing - execution terminated
> >
> > ...more...
> > parley.scm:610: history817818
> > parley.scm:610: history817818
> > parley.scm:603: ##sys#dynamic-wind
> > parley.scm:603: history798799
> > parley.scm:603: history798799
> > parley.scm:603: history798799
> > parley.scm:603: history798799
> > parley.scm:610: ##sys#dynamic-wind
> > parley.scm:610: history817818
> > parley.scm:610: history817818
> > parley.scm:615: get-next-char!
> > parley.scm:579: parley-char-ready?
> > parley.scm:586: append-while-incomplete
> > parley.scm:560: string-null?
> > parley.scm:561: repl-prompt
> > parley.scm:561: g769<--
> > -
> >
> > Sometimes I'll crash immediately and someytimes I have to press some
> > keys when the "#;8>" prompt appears.
> >
> >
> > If I run the above script thusly:
> >
> > -
> > $ csi -s memo-demo.scm
> > -
> >
> > I see
> >
> > -
> > $ csi -s ../memo-demo.scm
> > 2.908s CPU time, 1.164s GC time (major), 75257 mutations, 22/1550 GCs
> > (major/minor)
> > 0s CPU time, 20 mutations
> > -
> >
> > ...and it hangs there (on the last time call) indefinitely using all the
> > CPU. Ctrl-C doesn't terminate it: a call to 'killall csi' does tho'.
> >
> >
> > If you cannot reproduce it then try varying the numbers in the call to
> > memo-fact**.
> >
> >
> >
> > Is this a known bug in 

Re: [Chicken-users] Numbers weirdness

2016-04-01 Thread Peter Bex
On Fri, Apr 01, 2016 at 06:23:28PM +0100, Andy Bennett wrote:
> Thanks Peter!
> 
> I'm mostly using log2 to work out if numbers are a power of two and find
> the highest bit that they have set.
> 
> Is there a more robust way to do that in CHICKEN when using the numbers
> egg and bignums?

It's probably better to do something like this:

(= (arithmetic-shift 1 (sub1 (integer-length x))) x)

If you find it clearer, you can also use

(= (expt 2 (sub1 (integer-length x))) x)

Note that the former accepts zero as a power of two, while the latter
doesn't.

And if you want to have some fun with bits:

(zero? (bitwise-xor (arithmetic-shift 1 (sub1 (integer-length x))) x))

Maybe we should consider including "first-bit-set" or "logcount" from
SRFI-60, what do you think?  These would allow us to avoid constructing
potential bignums just to check the lowest bit.  I initially decided
against including SRFI-60 because it's such a huge grab-bag of
procedures without much of a design behind it, and the worst part is
that most of them have two names instead of one :(

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Numbers weirdness

2016-04-01 Thread John Cowan
Peter Bex scripsit:

> That's a complete mischaracterisation.  First, it depends on your
> definition of "accurately", and secondly, you can tell CHICKEN to
> change the print precision.  See my other mail, which shows that
> Racket is _also_ truncating the value, just after more digits than
> CHICKEN is doing so.

By "accurately" I mean what is meant in the Burger & Dybvig paper
"Printing Floating-Point Numbers Quickly and Accurately" at
.
That is, printing the shortest correctly rounded output string
that converts to the same IEEE double value when read back in.
Of course it is possible to generate more digits than that,
but they are more precise than IEEE double format allows for,
and therefore are essentially garbage.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
My corporate data's a mess!
It's all semi-structured, no less.
But I'll be carefree / Using XSLT
On an XML DBMS.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Numbers weirdness

2016-04-01 Thread Andy Bennett
Hi,

>> Is it just late on a Friday? Am I crazy?
> 
> Floating point numbers are weird enough to drive anyone bat shit:
> 
> #;1> (use numbers)
> #;2> (define (log2 n) (/ (log n) (log 2)))
> #;3> (log2 (expt 2 251))
> 251.0
> #;4> (flonum-print-precision 100)
> 15
> #;5> (log2 (expt 2 251))
> 251.028421709430404007434844970703125

Thanks Peter!

I'm mostly using log2 to work out if numbers are a power of two and find
the highest bit that they have set.

Is there a more robust way to do that in CHICKEN when using the numbers
egg and bignums?






Regards,
@ndy

-- 
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0290 DA75 E982 7D99 A51F  E46A 387A 7695 7EBA 75FF




signature.asc
Description: OpenPGP digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Numbers weirdness

2016-04-01 Thread Peter Bex
On Fri, Apr 01, 2016 at 12:48:54PM -0400, John Cowan wrote:
> Trying (log2 (expt 2 251)) in Racket, which prints 64-bit floats
> accurately (unlike Chicken, which depends on C to do it)

That's a complete mischaracterisation.  First, it depends on your
definition of "accurately", and secondly, you can tell CHICKEN to
change the print precision.  See my other mail, which shows that
Racket is _also_ truncating the value, just after more digits than
CHICKEN is doing so.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Numbers weirdness

2016-04-01 Thread Peter Bex
On Fri, Apr 01, 2016 at 05:25:44PM +0100, Andy Bennett wrote:
> Hi,
> 
> In CHICKEN 4.9.0rc1 and 4.10.0 both with numbers 4.6:
> 
> -
> #;1> (use numbers)
> #;2> (define (log2 n) (/ (log n) (log 2)))
> #;3> (= (log2 (expt 2 252)) (ceiling (log2 (expt 2 252
> #t
> #;4> (= (log2 (expt 2 251)) (ceiling (log2 (expt 2 251
> #f
> #;5> (log2 (expt 2 251))
> 251.0
> #;6> (ceiling (log2 (expt 2 251)))
> 252.0
> -
> 
> Is it just late on a Friday? Am I crazy?

Floating point numbers are weird enough to drive anyone bat shit:

#;1> (use numbers)
#;2> (define (log2 n) (/ (log n) (log 2)))
#;3> (log2 (expt 2 251))
251.0
#;4> (flonum-print-precision 100)
15
#;5> (log2 (expt 2 251))
251.028421709430404007434844970703125

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Numbers weirdness

2016-04-01 Thread John Cowan
Andy Bennett scripsit:

> #;5> (log2 (expt 2 251))
> 251.0
> #;6> (ceiling (log2 (expt 2 251)))
> 252.0
> 
> Is it just late on a Friday? Am I crazy?

Trying (log2 (expt 2 251)) in Racket, which prints 64-bit floats
accurately (unlike Chicken, which depends on C to do it) returns
a value of 251.03.  The ceiling of that is indeed 252.0.

As Kernighan and Plauger said back in 1974:  "Floating point numbers
are like sandpiles:  every time you move one, you lose a little sand
and pick up a little dirt."  It's still true.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
Barry thirteen gules and argent on a canton azure fifty mullets of five
points of the second,  six, five, six, five, six, five, six, five, and six.
--blazoning the U.S. flag

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] Numbers weirdness

2016-04-01 Thread Andy Bennett
Hi,

In CHICKEN 4.9.0rc1 and 4.10.0 both with numbers 4.6:

-
#;1> (use numbers)
#;2> (define (log2 n) (/ (log n) (log 2)))
#;3> (= (log2 (expt 2 252)) (ceiling (log2 (expt 2 252
#t
#;4> (= (log2 (expt 2 251)) (ceiling (log2 (expt 2 251
#f
#;5> (log2 (expt 2 251))
251.0
#;6> (ceiling (log2 (expt 2 251)))
252.0
-

Is it just late on a Friday? Am I crazy?



Regards,
@ndy

-- 
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0290 DA75 E982 7D99 A51F  E46A 387A 7695 7EBA 75FF


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


[Chicken-users] [TFP 2016] Final call for papers

2016-04-01 Thread Peter Achten

-
C A L L   F O R   P A P E R S
-

 TFP 2016 ===

  17th Symposium on Trends in Functional Programming
   June 8-10, 2016
 University of Maryland, College Park
 Near Washington, DC
 http://tfp2016.org/


The symposium on Trends in Functional Programming (TFP) is an
international forum for researchers with interests in all aspects of
functional programming, taking a broad view of current and future
trends in the area. It aspires to be a lively environment for
presenting the latest research results, and other contributions (see
below). Authors of draft papers will be invited to submit revised
papers based on the feedback receive at the symposium.  A
post-symposium refereeing process will then select a subset of these
articles for formal publication.

TFP 2016 will be the main event of a pair of functional programming
events. TFP 2016 will be accompanied by the International Workshop on
Trends in Functional Programming in Education (TFPIE), which will take
place on June 7nd.


== INVITED SPEAKERS ==

TFP 2016 is pleased to announce keynote talks by the following two
invited speakers:

* Ronald Garcia, University of British Columbia
* Steve Zdancewic, University of Pennsylvania


== HISTORY ==

The TFP symposium is the heir of the successful series of Scottish
Functional Programming Workshops. Previous TFP symposia were held in
   * Edinburgh (Scotland) in 2003;
   * Munich (Germany) in 2004;
   * Tallinn (Estonia) in 2005;
   * Nottingham (UK) in 2006;
   * New York (USA) in 2007;
   * Nijmegen (The Netherlands) in 2008;
   * Komarno (Slovakia) in 2009;
   * Oklahoma (USA) in 2010;
   * Madrid (Spain) in 2011;
   * St. Andrews (UK) in 2012;
   * Provo (Utah, USA) in 2013;
   * Soesterberg (The Netherlands) in 2014;
   * and Inria Sophia-Antipolis (France) in 2015.
For further general information about TFP please see the TFP homepage.
(http://www.tifp.org/).


== SCOPE ==

The symposium recognizes that new trends may arise through various
routes.  As part of the Symposium's focus on trends we therefore
identify the following five article categories. High-quality articles
are solicited in any of these categories:

Research Articles: leading-edge, previously unpublished research work
Position Articles: on what new trends should or should not be
Project Articles: descriptions of recently started new projects
Evaluation Articles: what lessons can be drawn from a finished project
Overview Articles: summarizing work with respect to a trendy subject

Articles must be original and not simultaneously submitted for
publication to any other forum. They may consider any aspect of
functional programming: theoretical, implementation-oriented, or
experience-oriented.  Applications of functional programming
techniques to other languages are also within the scope of the
symposium.

Topics suitable for the symposium include, but are not limited to:

 Functional programming and multicore/manycore computing
 Functional programming in the cloud
 High performance functional computing
 Extra-functional (behavioural) properties of functional programs
 Dependently typed functional programming
 Validation and verification of functional programs
 Debugging and profiling for functional languages
 Functional programming in different application areas:
   security, mobility, telecommunications applications, embedded
   systems, global computing, grids, etc.
 Interoperability with imperative programming languages
 Novel memory management techniques
 Program analysis and transformation techniques
 Empirical performance studies
 Abstract/virtual machines and compilers for functional languages
 (Embedded) domain specific languages
 New implementation strategies
 Any new emerging trend in the functional programming area

If you are in doubt on whether your article is within the scope of
TFP, please contact the TFP 2016 program chair, David Van Horn.


== BEST PAPER AWARDS ==

To reward excellent contributions, TFP awards a prize for the best paper
accepted for the formal proceedings.

TFP traditionally pays special attention to research students,
acknowledging that students are almost by definition part of new
subject trends. A student paper is one for which the authors state
that the paper is mainly the work of students, the students are listed
as first authors, and a student would present the paper. A prize for
the best student paper is awarded each year.

In both cases, it is the PC of TFP that awards the prize. In case the
best paper happens to be a student paper, that paper will then receive
both prizes.


== SPONSORS ==

TFP is financially supported by CyberPoint, Galois, Trail of Bits, and
the University of Maryland 

Re: [Chicken-users] CHICKEN hang / crash / memoize egg

2016-04-01 Thread Andy Bennett
On 01/04/16 15:28, Andy Bennett wrote:
> Hi Peeps!
> 
> I'm running CHICKEN 4.9.0rc1 and I'm trying out the memoize egg.
> 
> I saw the tail-call-optimized version of the factorial procedure in the
> memoize documentation at http://api.call-cc.org/doc/memoize and I've
> been trying to modify it so that it memoizes intermediate results such
> that, for example, a call to (fact 10) makes a subsequent call to (fact
> 9) fast.
> 
> In doing so I've managed to get the interpreter into a loop or crash it
> entirely.
> 
> 
> When pasting this into a csi prompt:
> 
> -
> (use numbers)
> (use memoize)
> 
> (define (fact** x #!optional (self memo-fact**))
>   (if (= x 0)
> 1
> (* x (self (- x 1)
> 
> (define memo-fact** (memoize fact**))
> 
> (define x (time (memo-fact**  35710)))
> (define x (time (memo-fact**  35720)))
> (define x (time (memo-fact**  35730)))
> -
> 
> I get:
> 
> -
> $ csi
> 
> CHICKEN
> (c) 2008-2014, The Chicken Team
> (c) 2000-2007, Felix L. Winkelmann
> Version 4.9.0rc1 (rev 3cf1967)
> linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
> compiled 2014-04-17 on hd-t1179cl (Linux)
> 
> ; loading /home/local/andyjpb/.csirc ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/parley.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/chicken.import.so ...
> ; loading
> /usr/local/chicken-4.9.0/lib/chicken/7/data-structures.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/extras.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/ports.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/posix.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/srfi-1.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/srfi-13.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/srfi-18.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/stty.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/srfi-69.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/foreign.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/foreigners.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/parley.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/stty.so ...
> #;1> (use numbers)
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/numbers.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/numbers.so ...
> #;2> (use memoize)
> #;2>
> #;2> (define (fact** x #!optional (self memo-fact**))
> #;2>   (if (= x 0)
> #;2> 1
> #;2> (* x (self (- x 1)
> #;2>
> #;2> (define memo-fact** (memoize fact**))
> #;2>
> #;2> (define x (time (memo-fact**  35710)))
> #;2> (define x (time (memo-fact**  35720)))
> #;2> (define x (time (memo-fact**  35730)))
> #;2>
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/memoize.import.so ...
> ; loading /usr/local/chicken-4.9.0/lib/chicken/7/memoize.so ...
> 
> Note: the following toplevel variables are referenced but unbound:
> 
>   memo-fact** (in fact**)
> 2.804s CPU time, 1.064s GC time (major), 81305 mutations, 21/1551 GCs
> (major/minor)
> 0s CPU time, 20 mutations
> 0s CPU time, 20 mutations
> #;8>
> [panic] out of memory - heap full while resizing - execution terminated
> 
> ...more...
> parley.scm:610: history817818
> parley.scm:610: history817818
> parley.scm:603: ##sys#dynamic-wind
> parley.scm:603: history798799
> parley.scm:603: history798799
> parley.scm:603: history798799
> parley.scm:603: history798799
> parley.scm:610: ##sys#dynamic-wind
> parley.scm:610: history817818
> parley.scm:610: history817818
> parley.scm:615: get-next-char!
> parley.scm:579: parley-char-ready?
> parley.scm:586: append-while-incomplete
> parley.scm:560: string-null?
> parley.scm:561: repl-prompt
> parley.scm:561: g769<--
> -
> 
> Sometimes I'll crash immediately and someytimes I have to press some
> keys when the "#;8>" prompt appears.
> 
> 
> If I run the above script thusly:
> 
> -
> $ csi -s memo-demo.scm
> -
> 
> I see
> 
> -
> $ csi -s ../memo-demo.scm
> 2.908s CPU time, 1.164s GC time (major), 75257 mutations, 22/1550 GCs
> (major/minor)
> 0s CPU time, 20 mutations
> -
> 
> ...and it hangs there (on the last time call) indefinitely using all the
> CPU. Ctrl-C doesn't terminate it: a call to 'killall csi' does tho'.
> 
> 
> If you cannot reproduce it then try varying the numbers in the call to
> memo-fact**.
> 
> 
> 
> Is this a known bug in Chicken 4.9.0rc1 or the srfi-69 hash-tables that
> memoize uses?
> 
> 
> Thanks for any tips you can offer.

With CHICKEN 4.10.0 from the website the following works:

-
(define x (time (memo-fact**  35710)))
(define x (time (memo-fact**  35720)))
(define x (time (memo-fact**  36030)))
-

...but a slightly larger number hangs as before:

-
(define x (time (memo-fact** 35710)))
(define x (time (memo-fact** 35720)))
(define x (time (memo-fact** 37030)))
-



...Also, under CHICKEN 4.10.0, pasting things into csi with parley 

Re: [Chicken-users] CHICKEN hang / crash / memoize egg

2016-04-01 Thread Andy Bennett
Hi,

>> I'm running CHICKEN 4.9.0rc1 and I'm trying out the memoize egg.
>>
>> I saw the tail-call-optimized version of the factorial procedure in the
>> memoize documentation at http://api.call-cc.org/doc/memoize and I've
>> been trying to modify it so that it memoizes intermediate results such
>> that, for example, a call to (fact 10) makes a subsequent call to (fact
>> 9) fast.
>>
>> In doing so I've managed to get the interpreter into a loop or crash it
>> entirely.
>>
> 
> This looks like a perfectly legitimate crash. The memoize egg doesn’t
> impose a limit on memory usage unless you explicitly tell it so.

I get the same results with '(define memo-fact** (memoize fact** 3))'.
I suspect this is a numbers bug as it still allocates a fair bit of memory.





Regards,
@ndy

-- 
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0290 DA75 E982 7D99 A51F  E46A 387A 7695 7EBA 75FF


___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] CHICKEN hang / crash / memoize egg

2016-04-01 Thread Kooda
On Fri, 01 Apr 2016 16:28:26 +0200,
Andy Bennett wrote:
> 
> Hi Peeps!
> 
> I'm running CHICKEN 4.9.0rc1 and I'm trying out the memoize egg.
> 
> I saw the tail-call-optimized version of the factorial procedure in the
> memoize documentation at http://api.call-cc.org/doc/memoize and I've
> been trying to modify it so that it memoizes intermediate results such
> that, for example, a call to (fact 10) makes a subsequent call to (fact
> 9) fast.
> 
> In doing so I've managed to get the interpreter into a loop or crash it
> entirely.
> 

This looks like a perfectly legitimate crash. The memoize egg doesn’t
impose a limit on memory usage unless you explicitly tell it so.

___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] cross compiled hellow world says: Error: call of non-procedure: #

2016-04-01 Thread Peter Bex
On Fri, Apr 01, 2016 at 01:49:35PM +, jo wrote:
> Hi
> 
> This time I followed the instructions on 
> http://wiki.call-cc.org/man/4/Cross%20development to build a cross compiler 
> for powerpc. 
> 
> After the build I copied the target tree to the device.
> I compiled following test program:
>  cat hello.scm
> (define (hello who)
>   (format #t "~A ~A!\n"
>   "Hello" who))
> (hello "Wisp")
> 
> Howver on target I get this error?:
> 
> target:/tmp# ./hello
> 
> Error: call of non-procedure: #
> 
>     Call history:
> 
>     hello.scm:4: hello
>     hello.scm:2: format <--
> 
> What does this mean ? Any ideas on how to proceed?

Hello again,

This is probably because you didn't load the module or unit that
defines format (this is the "extras" module).  The interpreter has
a few units available implicitly by default which aren't loaded
into compiled code.

This is a bit of a gotcha, which is why we're working on making this
more consistent in CHICKEN 5.

Anyway, if you put your code in a module the compiler would give
an error about a missing import.  The fix is to put this at the top
of your file:

(use extras)

This isn't a cross-compilation issue by the way, this would also
give an error if you compile and run on the host platform.

Hope this helps!
Peter


signature.asc
Description: Digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users