Giter Site home page Giter Site logo

ashinn / chibi-scheme Goto Github PK

View Code? Open in Web Editor NEW
1.2K 54.0 141.0 23.65 MB

Official chibi-scheme repository

License: Other

Scheme 81.47% C 17.07% Shell 0.18% Perl 0.03% Makefile 0.64% HTML 0.06% JavaScript 0.01% Emacs Lisp 0.17% CMake 0.37% ReScript 0.01%

chibi-scheme's Introduction

Chibi-Scheme

Minimal Scheme Implementation for use as an Extension Language

https://github.com/ashinn/chibi-scheme

Chibi-Scheme is a very small library intended for use as an extension and scripting language in C programs. In addition to support for lightweight VM-based threads, each VM itself runs in an isolated heap allowing multiple VMs to run simultaneously in different OS threads.

There are no external dependencies so is relatively easy to drop into any project.

Despite the small size, Chibi-Scheme attempts to do The Right Thing. The default settings include:

  • a full numeric tower, with rational and complex numbers
  • full and seamless Unicode support
  • low-level and high-level hygienic macros
  • an extensible module system

Specifically, the default repl language contains all bindings from R7RS small, available explicitly as the (scheme small) library. The language is built in layers, however - see the manual for instructions on compiling with fewer features or requesting a smaller language on startup.

Chibi-Scheme is known to work on 32 and 64-bit Linux, FreeBSD, NetBSD, OpenBSD and OS X, Plan 9, Windows, iOS, Android, ARM and Emscripten. Basic support for native Windows desktop also exists. See README-win32.md for details and build instructions.

To build on most platforms just run make && make test. This has a few conditionals assuming GNU make. If using another make, there are a few parameters in Makefile.detect you need to set by hand.

This will provide a shared library libchibi-scheme, as well as a sample chibi-scheme command-line repl. You can then run

sudo make install

to install the binaries and libraries. You can optionally specify a PREFIX for the installation directory:

make PREFIX=/path/to/install/
sudo make PREFIX=/path/to/install/ install

By default files are installed in /usr/local.

If you want to try out chibi-scheme without installing, be sure to set LD_LIBRARY_PATH (DYLD_LIBRARY_PATH on macOS) so it can find the shared libraries.

To make the emscripten build run make js (not emmake make js).

For more detailed documentation, run make doc and see the generated doc/chibi.html.

chibi-scheme's People

Contributors

amirouche avatar arthurgleckler avatar ashinn avatar briancaine avatar dpapavas avatar dpk avatar edw avatar ekaitz-zarraga avatar frerejerome avatar gambiteer avatar hamayama avatar ilammy avatar jacius avatar jimrees avatar jpellegrini avatar krzygorz avatar lassik avatar lubgr avatar nmeum avatar okuoku avatar omasanori avatar oxyd avatar pclouds avatar raviqqe avatar rettakjak avatar smazga avatar tramboi avatar traviscross avatar wasamasa avatar wrog avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

chibi-scheme's Issues

Bignums are not numbers

What steps will reproduce the problem?

> (number? 1234567890)
#f
(bignum? 1234567890)
#t

What is the expected output? What do you see instead?

Shouldn't bignums be numbers? This causes string->number to fail with big
numbers:

> (string->number "1234567890")
#f

What version of the product are you using? On what operating system?

chibi-scheme rev. 30a5c36bd8 on Fedora linux x86.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 29 Dec 2009 at 9:29

possible bugs

See my comments in the below diff.

--- gc.c    Wed Dec 02 15:00:54 2009 -0800
+++ gc.c    Thu Dec 03 01:30:32 2009 -0800
@@ -160,8 +160,11 @@
   free = h->free_list = (sexp_free_list) h->data;
   h->next = NULL;
   next = (sexp_free_list) ((char*)free + sexp_heap_align(sexp_sizeof(pair)));
-  free->size = 0; /* actually sexp_sizeof(pair) */
+  free->size = 0; /* actually sexp_heap_align(sexp_sizeof(pair)) */
   free->next = next;
+  /* Is next->size incorrect?  h->data was aligned...
+     Shouldn't it be:
+     (sexp_uint_t)(((char*)h + sizeof(struct sexp_heap) + size) -
(char*)next) */
   next->size = size - sexp_heap_align(sexp_sizeof(pair));
   next->next = NULL;
   return h;

--- sexp.c  Wed Dec 02 15:00:54 2009 -0800
+++ sexp.c  Thu Dec 03 01:30:32 2009 -0800
@@ -202,6 +202,7 @@

 #if ! USE_GLOBAL_HEAP
 sexp sexp_bootstrap_context (void) {
+  /* Should dummy_ctx be freed before returning? */
   sexp dummy_ctx, ctx;
   sexp_heap heap = sexp_make_heap(sexp_heap_align(SEXP_INITIAL_HEAP_SIZE));
   dummy_ctx = (sexp) malloc(sexp_sizeof(context));

Original issue reported on code.google.com by [email protected] on 3 Dec 2009 at 9:38

heap alignment for 32-bit machines should work for ARM

From Alexander Shendi's investigations, the heap alignment
for 64-bit machines is needed for Chibi to work under ARM.

  > On Apr 13, 10:26 pm, Alexander Shendi <[email protected]>
  > wrote:
  >>
  >> However using Linux on the Sharp Netwalker I have to change the file
  >> gc.c, line 16 from:
  >> "#define sexp_heap_align(n) sexp_align(n, 4)"
  >> to:
  >> "#define sexp_heap_align(n) sexp_align(n, 5)"

The smaller heap alignment should work too.

Original issue reported on code.google.com by [email protected] on 14 Apr 2010 at 10:53

need sexp_copy_context

For things like FASL loading, threads, and manual
process forking, we need a way to copy a whole
context and its associated heap:

  sexp sexp_copy_context(sexp ctx)

In addition to copying the raw data this will need to
adjust all the pointers.

Original issue reported on code.google.com by [email protected] on 9 Mar 2010 at 11:38

(get-time-of-day) is broken

What steps will reproduce the problem?
1.

(import (chibi time))
(timeval-seconds (car (get-time-of-day)))

What is the expected output? What do you see instead?

I'd expect the same output I get from:

> (current-seconds)
83314

Instead I get

> (timeval-seconds (car (get-time-of-day)))
-1262271600

What version of the product are you using? On what operating system?

Rev. 606fea8429     

Please provide any additional information below.

This used to work with rev. 3c9a7138f2 (Dec 29th).

I guess this might depend on the changes made to tools/genstubs.scm, as the
stub time.stub seems to be the same, but the generated time.c is different
(I don't know the code, though, so I leave finding it out to you ;-) ):

--- /tmp/time.c 2010-01-01 14:59:02.847941031 +0100
+++ /usr/local/share/chibi/lib/chibi/time.c 2010-01-01 10:28:00.000000000 +0100
@@ -78,6 +78,7 @@
   res1 = sexp_make_cpointer(ctx, sexp_tm_type_id, tmp1, SEXP_FALSE, 1);
   res = res1;
   }
+  free(tmp1);
   sexp_gc_release1(ctx);
   return res;
 }
@@ -116,6 +117,8 @@
   sexp_push(ctx, res, res1);
   sexp_push(ctx, res, res0);
   }
+  free(tmp0);
+  free(tmp1);
   sexp_gc_release3(ctx);
   return res;
 }
@@ -236,7 +239,7 @@
   sexp_define_foreign(ctx, env, "seconds->string", 1,
sexp_seconds_3E_string_stub);
   sexp_define_foreign(ctx, env, "time->seconds", 1,
sexp_time_3E_seconds_stub);
   sexp_define_foreign(ctx, env, "seconds->time", 1,
sexp_seconds_3E_time_stub);
-  sexp_define_foreign_opt(ctx, env, "set-time-of-day!", 2,
sexp_set_time_of_day_x_stub, sexp_make_cpointer(ctx, sexp_timezone_type_id,
NULL, SEXP_FALSE, 0));
+  sexp_define_foreign_opt(ctx, env, "set-time-of-day!", 2,
(sexp_proc1)sexp_set_time_of_day_x_stub, sexp_make_cpointer(ctx,
sexp_timezone_type_id, NULL, SEXP_FALSE, 0));
   sexp_define_foreign(ctx, env, "get-time-of-day", 0,
sexp_get_time_of_day_stub);
   sexp_define_foreign(ctx, env, "current-seconds", 0,
sexp_current_seconds_stub);
   sexp_gc_release2(ctx);


Original issue reported on code.google.com by [email protected] on 1 Jan 2010 at 2:17

disasm segmentation fault

> (disasm disasm)
  <unknown> 144 
  <unknown> 202 
  <unknown> 188 
  <unknown> 183 
  NOOP 
  NOOP 
  NOOP 
  NOOP 
  NOOP 
  NOOP 
  NOOP 
  NOOP 
  INEXACT->EXACT 
  <unknown> 127 
  <unknown> 246 
  <unknown> 183 
  TAIL-CALL 
Segmentation fault

Original issue reported on code.google.com by [email protected] on 2 Dec 2009 at 7:58

On Plan 9, u.h (and likely libc.h) need to be included before stdio.h

include/chibi/sexp.h includes ctype.h & stdio.h before the "#ifdef PLAN9" 
clause. This causes 
problems like:

/sys/include/stdio.h:79[sexp.c:471] mixed ansi/old function declaration: 
vfprintf
/sys/include/stdio.h:80[sexp.c:472] mixed ansi/old function declaration: vprintf
/sys/include/stdio.h:81[sexp.c:473] mixed ansi/old function declaration: 
vsprintf
/sys/include/stdio.h:82[sexp.c:474] mixed ansi/old function declaration: 
vsnprintf
/sys/include/stdio.h:83[sexp.c:475] mixed ansi/old function declaration: vfscanf

I moved the pair of includes for ctype.h and stdio.h (I believe only stdio.h is 
the problem, but the 
code looks cleaner moving the pair) at include/chibi/sexp.h:17,19 after the 
entire #ifdef 
PLAN9/#else/#endif clause, and this works on Plan 9. I have tested on OS X and 
this does not 
seem to adversely affect compilation or execution; I do not have other 
platforms to test on.

See also issue #46 to make building on Plan 9 work again.

Original issue reported on code.google.com by [email protected] on 24 Mar 2010 at 9:54

identifier comparison bugs

> (let ((else 1)) (cond (else 'ok) (#t 'bad)))
ERROR on line 1: non-final else in cond: (cond (else (quote ok)) (#t (quote
bad)))
> (let ((... 2))
    (let-syntax ((s (syntax-rules () ((_ x ...) '(x ...)))))
      (s a b c d e)))
(a b c d e)
> (let ((unquote 3)) `(,foo))
ERROR: undefined variable: foo
> 

Larceny in R5RS mode, and other systems, do:

> (let ((else 1)) (cond (else 'ok) (#t 'bad)))
ok
> (let ((... 2))
    (let-syntax ((s (syntax-rules () ((_ x ...) '(x ...)))))
      (s a b c d e)))
ERROR detected during macro expansion:
Use of macro does not match definition
(s a b c d e)
> (let ((unquote 3)) `(,foo))
(,foo)
> 

Attached is a patch which I think fixes the problem, however, there are
still a few uses of a compare which I wasn't sure about, so I didn't change
them.

Original issue reported on code.google.com by [email protected] on 7 Dec 2009 at 3:09

Attachments:

let* internal define

If a let* form has empty bindings, it expands to a begin form, and so
internal defines are bound in the wrong scope.  Attached is a bundle which
fixes this and adds tests to r5rs-tests.scm

> (let* () (define x 1) (- x))
-1
> x
1

Original issue reported on code.google.com by [email protected] on 8 Dec 2009 at 12:26

Attachments:

Missing argument type validation for some opcode implementations

At least the following opcodes are affected. Below each opcode one possible 
regression test, 
which either crash the interpreter or lead to nonsense results:

OP_STRING_LENGTH
  (string-length 6)

OP_STRING_REF
  (string-ref 5 6)

OP_VECTOR_LENGTH
  (vector-length 5)

OP_VECTOR_REF
  (vector-ref #(1 2 3 4) 6.7)

OP_MAKE_VECTOR
  (make-vector "abc")


I've added a patch (against HEAD).

Original issue reported on code.google.com by [email protected] on 3 Oct 2009 at 9:18

Attachments:

Minor Makefile changes

The three changes I'm currently using are the following :

1) include/chibi/bignum.h is added to INCLUDES; this is mainly needed for
the 'install' target, otherwise bignum.h will not be installed (but it's
used by sexp.h, which is installed).

2) Installs genstub.scm

3) avoids double installation of init.scm and config.scm (they are already
installed as part of the recursive copy of lib directory).

Original issue reported on code.google.com by [email protected] on 23 Jan 2010 at 7:24

Attachments:

Missing operator argument crashes the interpreter

What steps will reproduce the problem?
1. At chibi-scheme prompt digit (note the missing second argument to '<'):
    ((lambda () (if (< 0 ) 'a 'b)))

2.
3.

What is the expected output? What do you see instead?

    I would expect an error message or something similiar, instead I get:

    Segmentation fault (core dumped)

What version of the product are you using? On what operating system?

    Rev. 6d2f7320e6 (new today) on fedora fc12 32bits linux

Please provide any additional information below.

    The same holds for other operators '>', '=', '>=', etc

Original issue reported on code.google.com by [email protected] on 17 Dec 2009 at 9:40

"Integer" floats not fitting into a fixnum are turned to 0.

What steps will reproduce the problem?

> 123e9
0
> 123e90
0

What is the expected output? What do you see instead?

> 123e9
123000000000.0
> 123e90
1.23e+92

What version of the product are you using? On what operating system?

Ver. 361:2f8f2e85eafc Linux Fedora 12 x86

Please provide any additional information below.

The attached patch fixes the issues as shown above, by avoiding the call to
sexp_make_fixnum() if res doesn't fit.

Original issue reported on code.google.com by [email protected] on 29 Jan 2010 at 10:26

Attachments:

Problems with bignum operations

What steps will reproduce the problem?

Division of two bignums may give wrong result, and subtracting a flonum
from a bignum crashes:

> (/ 40413742330349316707 12864093722915635200)
-132744107638.09
> (- 1234567890 100.0)
Segmentation fault (core dumped)

What is the expected output? What do you see instead?

> (/ 40413742330349316707 12864093722915635200)
3.14159265322809
> (- 1234567890 100.0)
-1234567790.0

What version of the product are you using? On what operating system?

rev. 361:2f8f2e85eafc on linux fedora 12 x86.

Please provide any additional information below.

The attached patch fixes the problems.

The division problem was the last remaining failure from the set of srfi-42
examples, so that srfi is good at least as a test-suite ;-).

Original issue reported on code.google.com by [email protected] on 27 Jan 2010 at 3:51

Attachments:

string-ref not 8-bit clean

Currently, string access seems to be not "8-bit clean":

> (char->integer (string-ref (string (integer->char 255)) 0))
-1

The attached patch fixes this issue for me, though it might make sense to
take a look at the code for other potential occurrences of that problem.

Original issue reported on code.google.com by [email protected] on 21 Feb 2010 at 2:50

Attachments:

config.scm references *shared-object-extension* even when compiled statically

Currently, when chibi is compiled statically (as per README), it starts
with a warning:

% ./chibi-scheme-static 
WARNING: reference to undefined variable: *shared-object-extension*
> 

This appears to be due to *shared-object-extension* being referenced in
config.scm even when the cond-expand feature `dynamic-loading' is not
present. The attached patch should fix this.

Original issue reported on code.google.com by [email protected] on 21 Feb 2010 at 6:16

Attachments:

genstubs miscounts function args

What steps will reproduce the problem?

$ genstubs.scm test.stub 
ERROR on line 3 of file test.stub: FFI currently only supports up to 6
scheme args: (void (f "f") (int int int int int int))

What is the expected output? What do you see instead?

Up to 6 arguments should be handled, well, maybe even more, but the message
states that. 

What version of the product are you using? On what operating system?

chibi-scheme rev. 348:7433690190a1

Please provide any additional information below.

The real function I'm trying to stub is 

void putpixel_rgb(SDL_Surface * screen, int x, int y, Uint8 r, Uint8 g,
Uint8 b)

which makes a bit more sense than the one in the example.

I tried the attached patch and it seems to work with 6 arguments.
In case it has no drawbacks I'd suggest supporting even more arguments, at
least up to 10...

Original issue reported on code.google.com by [email protected] on 14 Jan 2010 at 8:10

Attachments:

let-syntax not splicing defines

> (letrec-syntax () (define lrs-def 1))
> lrs-def
1
> (let-syntax () (define ls-def 2))
> ls-def
ERROR: undefined variable: ls-def

I wasn't sure how to fix this, so didn't try.

Original issue reported on code.google.com by [email protected] on 8 Dec 2009 at 12:30

Division of a FLONUM by a FIXNUM is reversed

What steps will reproduce the problem?

> (/ 1.0 3)
3.0
> (/ 3 1.0)
3.0

What is the expected output? What do you see instead?

> (/ 1.0 3)
0.333333333333333
> (/ 3 1.0)
3.0

What version of the product are you using? On what operating system?

rev. 348:7433690190a1 on linux x86

Please provide any additional information below.

The attached patch fixes the problem.

Original issue reported on code.google.com by [email protected] on 11 Jan 2010 at 12:29

Attachments:

c++ fixes

changes to allow chibi to be embedded in c++ applications

- wrapped eval.h and sexp.h in extern "C" when __cplusplus is defined
- typeid is an operator in c++, changed to type_id
- gcc doesn't like it when you alias structures with typedefs, e.g.
"typedef struct my_struct *my_struct;", so i added "_t" to the struct names 

Original issue reported on code.google.com by [email protected] on 26 Feb 2010 at 6:39

Attachments:

Chibi doesn't respect architecture alignment when dealing with bytecode

If you run chibi on a platform which requires strict alignment for memory
access (e.g. ARMv5), chibi will case a bus error.

The attached patch should fix this problem, but is suboptimal, as it
increases the size of many VM instructions. It works by padding after to
opcode, so that _WORD0 & friends are located at a machine word boundary.
The use of that alignment is disabled by default in features.h, except on
ARM architectures (I think newer ARM do allow unaligned access, so the
check should probably be refined).

Original issue reported on code.google.com by [email protected] on 7 Mar 2010 at 11:01

Attachments:

Segmentation fault with bignum operations

What steps will reproduce the problem?
1. Execute the attached script:

$ chibi-scheme xxx.scm 
Segmentation fault (core dumped)

2.
3.

What is the expected output? What do you see instead?

$ chibi-scheme xxx.scm 
(536870923)

Instead we get a SIGSEGV

What version of the product are you using? On what operating system?

chibi-scheme rev. 20a17a8f5e4a on Fedora linux x86.

Please provide any additional information below.

Oddly enough uncommenting the "tracing" (begin ...) form makes the script
working.
It smells like a memory corruption, possibly related to bignum handling, as
the problem disappears when the number to be factorized becomes smaller
than the minimum bignum value... 

Here is a gdb log:

$ gdb /usr/local/bin/chibi-scheme
GNU gdb (GDB) Fedora (7.0-13.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/chibi-scheme...(no debugging symbols
found)...done.
(gdb) r xxx.scm
Starting program: /usr/local/bin/chibi-scheme xxx.scm

Program received signal SIGSEGV, Segmentation fault.
0x00cdbbc7 in sexp_vm (ctx=0xb7de9030, proc=0xb7f2c8a0) at eval.c:1293
1293      switch (*ip++) {
Missing separate debuginfos, use: debuginfo-install
chibi-scheme-0.2-1.200912291127.fc12.i386
(gdb) where
#0  0x00cdbbc7 in sexp_vm (ctx=0xb7de9030, proc=0xb7f2c8a0) at eval.c:1293
#1  0x00ce326d in sexp_apply (ctx=0xb7de9030, proc=0xb7f2c8a0, args=0xb7f2c930)
    at eval.c:2662
#2  0x08049a93 in run_main ()
#3  0x08049ae4 in main ()
(gdb) info locals
bc = 0x0
cp = 0x0
stack = 0xb7de9e9c
ip = 0x83 <Address 0x83 out of bounds>
i = 2
j = 0
k = 2
fp = 6
top = 13
prod = 536895241
self = 0xb7f2c950
__sexp_gc_preserver1 = {var = 0xbffff1d0, next = 0xbffff270}
tmp1 = 0xfffffffd
__sexp_gc_preserver2 = {var = 0xbffff1c4, next = 0xbffff1c8}
tmp2 = 0x16a0d
__sexp_gc_preserver3 = {var = 0xbffff1b8, next = 0xbffff1bc}
(gdb) 

Original issue reported on code.google.com by [email protected] on 29 Dec 2009 at 1:59

Attachments:

catching outside eval

In your log message for changeset f96809a075, you said: "It doesn't really
make sense for an exception to pass outside of EVAL."

Currently, inconsistent behavior is happening:

> (with-exception-handler
    (lambda (ex) (display "caught\n"))
    (lambda () (eval '(lambda))))
caught
> (with-exception-handler
    (lambda (ex) (display "caught\n"))
    (lambda () (eval '(raise 1))))
1
> (with-exception-handler
    (lambda (ex) (display "caught\n"))
    (lambda () (eval '(error "oops"))))
caught
> 


I'd like to request that catching outside eval be fully supported.  I use
this ability in two ways.  I use it for my test programs to check my
macros' syntax misuses correctly error.  I use it for my own REPL-type
things or for other dynamic evaluation -- I want to catch outside because
I'm supervising.

Original issue reported on code.google.com by [email protected] on 28 Dec 2009 at 9:20

Wrong check for immutable string in string-ref?

(string->ref "abc" 1)

won't return #\b as expected but complain with
ERROR: string-ref: immutable string: "abc"

I guess the respective check in eval.c line 1477 is not correct for string-ref.

Original issue reported on code.google.com by [email protected] on 4 Nov 2009 at 8:55

RESUMECC fails on Mac OS X 10.6.1

Attached is a GDB transcript illustrating a memory exception
experienced when using CALL-WITH-CURRENT-CONTINUATION
on Snow Leopard. I have not been able to test this on other
versions of OS X.

I'm happy to perform further debugging, but I've gotten about as
far as I can go without understanding the VM.

- Scott Bell

Original issue reported on code.google.com by [email protected] on 24 Sep 2009 at 6:21

Attachments:

segfaults on define-syntax

What steps will reproduce the problem?
1.Load a file containing the following:
(define-syntax symbol??
  (syntax-rules ()
    ((symbol?? (x . y) kt kf) kf)   ; It's a pair, not a symbol
    ((symbol?? #(x ...) kt kf) kf)  ; It's a vector, not a symbol
    ((symbol?? maybe-symbol kt kf)
      (let-syntax
    ((test
       (syntax-rules ()
         ((test maybe-symbol t f) t)
         ((test x t f) f))))
    (test abracadabra kt kf)))))

What is the expected output? What do you see instead?
The expected output is another prompt; instead I see "Process scheme
segmentation fault"

Here's a bit of info from gdb:
06:43:33 [erich@flap chibi-scheme]$ gdb ./chibi-scheme
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: /usr/local/src/chibi-scheme/chibi-scheme 
/usr/local/src/chibi-scheme/chibi-scheme: error while loading shared
libraries: libchibi-scheme.so: cannot open shared object file: No such file
or directory

Program exited with code 0177.
(gdb) setenv LD_LIBRARY_PATH=/usr/local/src/chibi-scheme/
Undefined command: "setenv".  Try "help".
(gdb) set env LD_LIBRARY_PATH=/usr/local/src/chibi-scheme/
(gdb) run
Starting program: /usr/local/src/chibi-scheme/chibi-scheme 
> (load "/home/erich/doodles/anagrams/scheme/chibi/assert.ss")

Program received signal SIGSEGV, Segmentation fault.
0xb7f35f1e in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7f35f1e in ?? () from /lib/tls/i686/cmov/libc.so.6
#1  0xb7f36ee6 in realloc () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7f36e22 in realloc () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7f2aaca in ?? () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7f21f69 in fclose () from /lib/tls/i686/cmov/libc.so.6
#5  0xb8051189 in sexp_close_port (ctx=0xb7d3ec60, port=0xb7d3ffa0) at
eval.c:1876
#6  0xb804d44e in sexp_vm (ctx=0xb7d3ec60, proc=0xb7d3ce50) at eval.c:1405
#7  0xb8052623 in sexp_apply (ctx=0xb7d3ec60, proc=0xb7d3ce50,
args=0xb7d3ec50) at eval.c:2113
#8  0xb804abcb in analyze (ctx=0xb7d3d5e0, object=0xb7d3e710) at eval.c:725
#9  0xb8052741 in sexp_compile (ctx=0xb7d3d5e0, x=0xb7d3e710) at eval.c:2125
#10 0xb8052885 in sexp_eval (ctx=0xb7d3d5e0, obj=0xb7d3e710) at eval.c:2146
#11 0xb804a29f in analyze_bind_syntax (ls=0xb7d3ec20, eval_ctx=0xb7d3d5e0,
bind_ctx=0xb7d3d5e0)
    at eval.c:606
#12 0xb804a420 in analyze_define_syntax (ctx=0xb7d3d5e0, x=0xb7d3e6b0) at
eval.c:627
#13 0xb804aab4 in analyze (ctx=0xb7d3d5e0, object=0xb7d3e6b0) at eval.c:711
#14 0xb8052741 in sexp_compile (ctx=0xb7d3d5e0, x=0xb7d3e6b0) at eval.c:2125
#15 0xb8052885 in sexp_eval (ctx=0xb7d3d5e0, obj=0xb7d3e6b0) at eval.c:2146
#16 0xb8051428 in sexp_load (ctx=0xb7c9e4d0, source=0xb7d3d410,
env=0xb7c9f510) at eval.c:1914
#17 0xb804d4ea in sexp_vm (ctx=0xb7c9e4d0, proc=0xb7d3d5a0) at eval.c:1411
#18 0xb8052623 in sexp_apply (ctx=0xb7c9e4d0, proc=0xb7d3d5a0, args=0xe) at
eval.c:2113
#19 0xb80528f4 in sexp_eval (ctx=0xb7c9e4d0, obj=0xb7d3d400) at eval.c:2154
#20 0x08048c5b in repl (ctx=0xb7c9e4d0) at main.c:72
#21 0x08049051 in run_main (argc=1, argv=0xbf87d154) at main.c:140
#22 0x08049086 in main (argc=1, argv=0xbf87d154) at main.c:149
(gdb) up
#1  0xb7f36ee6 in realloc () from /lib/tls/i686/cmov/libc.so.6
(gdb) 
#2  0xb7f36e22 in realloc () from /lib/tls/i686/cmov/libc.so.6
(gdb) 
#3  0xb7f2aaca in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb) 
#4  0xb7f21f69 in fclose () from /lib/tls/i686/cmov/libc.so.6
(gdb) 
#5  0xb8051189 in sexp_close_port (ctx=0xb7d3ec60, port=0xb7d3ffa0) at
eval.c:1876
1876        fclose(sexp_port_stream(port));
(gdb) p port
$1 = (sexp) 0xb7d3ffa0
(gdb) p *port
$2 = {tag = 12 '\f', immutablep = 0 '\0', gc_mark = 0 '\0', value = {
    flonum = 1.61046678963788e-267, type = {tag = 240 '', field_base = 2186, 
      field_len_base = -27032, field_len_off = 2186, field_len_scale = 0,
size_base = 0, 
      size_off = 1, size_scale = 0, name = 0x1 <Address 0x1 out of
bounds>}, pair = {
      car = 0x88a94f0, cdr = 0x88a9668, source = 0x0}, vector = {length =
143299824, 
      data = 0xb7d3ffa8}, string = {length = 143299824, data = 0xb7d3ffa8
"h\226\212\b"}, 
    symbol = {string = 0x88a94f0}, port = {stream = 0x88a94f0, buf =
0x88a9668 "1", offset = 0, 
      line = 1, size = 1, openp = 1, sourcep = 1, name = 0x1e, cookie =
0x4e}, exception = {
      kind = 0x88a94f0, message = 0x88a9668, irritants = 0x0, procedure =
0x1, source = 0x1}, 
    bignum = {sign = -16 '', length = 143300200, data = 0xb7d3ffac}, env =
{flags = -16 '', 
      parent = 0x88a9668, lambda = 0x0, bindings = 0x1}, bytecode = {length
= 143299824, 
      name = 0x88a9668, literals = 0x0, data = 0xb7d3ffb0 "\001"},
procedure = {flags = -16 '', 
      num_args = 2186, bc = 0x88a9668, vars = 0x0}, macro = {proc =
0x88a94f0, env = 0x88a9668}, 
    synclo = {env = 0x88a94f0, free_vars = 0x88a9668, expr = 0x0}, opcode =
{op_class = 240 '', 
      code = 148 '\224', num_args = 138 '\212', flags = 8 '\b', arg1_type =
104 'h', 
      arg2_type = 150 '\226', inverse = 138 '\212', name = 0x0, data = 0x1,
dflt = 0x1, 
      proc = 0x1}, core = {code = -16 '', name = 0x88a9668 "1"}, lambda =
{name = 0x88a94f0, 
      params = 0x88a9668, locals = 0x0, defs = 0x1, flags = 0x1, fv = 0x1,
sv = 0x1, 
      body = 0x1e}, cnd = {test = 0x88a94f0, pass = 0x88a9668, fail = 0x0},
set = {
      var = 0x88a94f0, value = 0x88a9668}, ref = {name = 0x88a94f0, cell =
0x88a9668}, seq = {
      ls = 0x88a94f0}, lit = {value = 0x88a94f0}, stack = {length =
143299824, top = 143300200, 
      data = 0xb7d3ffac}, context = {saves = 0x88a94f0, pos = 143300200,
depth = 0, tailp = 1, 
      tracep = 1, bc = 0x1, lambda = 0x1, stack = 0x1e, env = 0x4e, fv =
0x0, parent = 0x0}}}
(gdb) quit


What version of the product are you using? On what operating system?
changeset:   153:e8871a9d12f8 on Ubuntu 9.04 ("Jaunty Jackalope") 32-bit x86

Original issue reported on code.google.com by eric.hanchrow on 2 Jul 2009 at 1:48

Possibly wrong lambda behaviour

What steps will reproduce the problem?

load the attached script:

> (load "failtest.scm")
1st : 1
2nd : 2
3rd : 3

What is the expected output? What do you see instead?

the expected output (and what I actually get from gambit-C) is:

> (load "failtest.scm")
1st : 0
2nd : 1
3rd : 2

i.e. the generator starts from 0, not from 1.

What version of the product are you using? On what operating system?

rev. 360:9f5119bb860d on linux fedora 12 x86.

Please provide any additional information below.

The test is actually a stripped down failing test from srfi-42 examples.

I bet it's wrong terminology, but it looks like "'value' parameter to the
inner lambda is considered 'by reference' and not 'by value'".
Or maybe I just misunderstood it, nevertheless gambit-C behaves differently
here.

Original issue reported on code.google.com by [email protected] on 27 Jan 2010 at 10:50

Attachments:

mingw32 dynamic loading implementation

- changed Makefile to remove -ldl when compiling with mingw
- under SEXP_USE_DL, i added an #ifdef __MINGW32__ case; i chose to include
windows.h directly in eval.c to avoid polluting the namespace
- made sexp_load_dl static

obviously a lot of libraries depend on POSIX functionality, but (chibi ast)
built and appeared to work correctly.

Original issue reported on code.google.com by [email protected] on 3 Mar 2010 at 4:32

Attachments:

Float numbers having integer part bigger than word size are broken

What steps will reproduce the problem?

> 12345678901.1   ; note 12345678901 > 2^32
3755744309.1

What is the expected output? What do you see instead?

> 12345678901.1
12345678901.1

What version of the product are you using? On what operating system?

Ver. 361:2f8f2e85eafc Linux Fedora 12 x86

Please provide any additional information below.

The attached patch fixes it by changing sexp_read_float_tail() signature:
on 32bit arch, casting a float to sexp_uint_t (whole parameter) truncates it.

Original issue reported on code.google.com by [email protected] on 29 Jan 2010 at 10:18

Attachments:

FFI struct setters are not handled by genstubs

What steps will reproduce the problem?

Just try to translate and compile the attached stub:

$ genstubs.scm setter.stub
$ cc  -c setter.c -o setter.o
setter.c: In function ‘sexp_my_struct_set_int’:
setter.c:19: error: lvalue required as left operand of assignment

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?

chibi-scheme rev. 348:7433690190a1

Please provide any additional information below.

The attached patch seems to solve the issue, at least for simple cases.

Additional problems found with genstubs.scm:
- unions seem not to be supported
- the "constructor:" directive doesn't work

Original issue reported on code.google.com by [email protected] on 8 Jan 2010 at 9:17

Attachments:

Makefile fixes, main.c fixes, and more

Attached is a Mercurial bundle, against revision 218:26460a0e8554, with
these changes:

main.c
  - Check there is an argument for options which need one, instead of
    segfaulting if it's missing
  - Allow -s arg to start with the '-' char
include/chibi/config.h
  - Fix comment typos
include/chibi/eval.h
  - Move init file defines relevant to only main.c to main.c, because
    eval.h might be used without main.c
Makefile
  - Set LD_LIBRARY_PATH for genstubs
  - Find \*$(SO) instead of \*.$(SO) in clean:
  - Delete tests/basic/*.out tests/basic/*.err in clean:
  - Delete include/chibi/install.h in cleaner:
  - Fix LD_LIBRARY_PATH for tests
  - Have install: depend on all: instead of chibi-scheme$(EXE):
  - mkdir -p $(DESTDIR)$(SOLIBDIR) in install:
  - Fix typo of "-cp"
  - Install libchibi-scheme$(SO).a instead of libchibi-scheme.a, to be
    consistent with rest of Makefile
  - New ldconfig: rule for ldconfig'ing
  - New ifeq ($(PLATFORM),mingw) conditionals for install: and uninstall:
  - Use $(DESTDIR) in uninstall:
  - Only delete chibi-scheme$(EXE), not chibi-scheme*, in case user has own
    chibi-scheme* files
  - cd to correct directory to delete header files

Original issue reported on code.google.com by [email protected] on 2 Dec 2009 at 11:23

Attachments:

string->number does not for radix = 16

(string->number "c" 16)
=> 2  (not 12)

The last line of (digit-value) in init.scm should read "(- (...) 55)" not "(- 
(...) 65)"

(define (digit-value ch)
  (if (char-numeric? ch)
      (- (char->integer ch) (char->integer #\0))
      (and (<= 65 (char->integer (char-upcase ch)) 70)
           (- (char->integer (char-upcase ch)) 55))))

Original issue reported on code.google.com by [email protected] on 29 Dec 2009 at 2:40

Problems with 'string->number' and 'number->string'.

What steps will reproduce the problem?

> (number->string -100 16)
"0"
> (number->string -100 2)
"0"
> (string->number "#x100" 16)
#f
> (string->number "#x100" 2)
#f
> (string->number "")
Segmentation fault (core dumped)

What is the expected output? What do you see instead?

> (number->string -100 16)
"-64"
> (number->string -100 2)
"-1100100"
> (string->number "#x100" 16)
256
> (string->number "#x100" 2)
256
> (string->number "")
#f

What version of the product are you using? On what operating system?

Rev. 357:5f6d91a9a0da

Please provide any additional information below.

The attached patch solves these issues, but:
a) The fixes for the wrong results is probably not "nice enough" scheme.
b) The fix to the crash in string->number which adds a check on empty
strings is actually hiding what I think is a bug in 
sexp_make_input_string_port(): when fmemopen() is called with size = 0 it
returns a NULL file pointer. I guess that (open-input-string "") should
return an input port which returns eof at the first read attempt, instead.

Original issue reported on code.google.com by [email protected] on 24 Jan 2010 at 10:24

Attachments:

Numbers using radix prefix notation are misread

What steps will reproduce the problem?

Some wrong cases:
> #xa3
3
> #o9
9
> #oA
0
> #xg1
1

What is the expected output? What do you see instead?

I'd expect respectively:
> #xa3
163
> #o9
ERROR on line 14: invalid numeric syntax: #\9
> #oA
ERROR on line 15: invalid numeric syntax: #\A
> #xg1
ERROR on line 17: invalid numeric syntax: #\g
> 1

What version of the product are you using? On what operating system?

v. 348:7433690190a1

Please provide any additional information below.

The attached patch seems to fix it.

Original issue reported on code.google.com by [email protected] on 16 Jan 2010 at 8:48

Attachments:

Segfault in main program option parsing

What steps will reproduce the problem?
1. Run chibi-scheme using an option that requires an argument, but omit the
argument.

  For example: chibi-scheme -h

What is the expected output? What do you see instead?

Expected an error where applicable, but instead a segmentation fault occurs.

What version of the product are you using? On what operating system?

Using Mercurial tip, on Linux (Ubuntu) amd64.

Please provide any additional information below.

Problem originates from main.c, for example:
  case 'h':
      arg = ((argv[i][2] == '\0') ? argv[++i] : argv[i]+2);
Here, argv may not have i+1 elements in bounds, such as when -h is the last
argument given to chibi-scheme.

Maybe this is not such an important detail given what chibi-scheme is
supposed to be used for, but it really threw me off the first time I
ignorantly tried to use "-h" to get a usage message.

Original issue reported on code.google.com by [email protected] on 12 Mar 2010 at 4:31

segfault from call/cc eval raise combo

> (call-with-current-continuation
    (lambda (cc)
      (with-exception-handler
        (lambda (ex) (cc #t))
        (lambda () (eval '(raise 1)) #f))))
Segmentation fault


These work:

> (call-with-current-continuation
    (lambda (cc)
      (with-exception-handler
        (lambda (ex) (cc #t))
        (lambda () (eval '(lambda)) #f))))
#t
> (with-exception-handler
    (lambda (ex) (display "caught\n"))
    (lambda () (eval '(raise 1))))
caught
> 

Original issue reported on code.google.com by [email protected] on 27 Dec 2009 at 1:28

Errors parsing float numbers having bignum integer part

What steps will reproduce the problem?

1) Segfault for non-base 10 floats having a bignum integer part

> #xABCDABCD.0
Segmentation fault (core dumped)

2) Unrecognized floats having a bignum integer part

1234567890.1
> ERROR on line 5: unexpected '.'
> 1234567890e100
0
> ERROR: undefined variable: e

What is the expected output? What do you see instead?

1)

> #xABCDABCD.0
ERROR on line 69: found non-base 10 float
> 0

2)

> 1234567890.1
1234567890.1
> 1234567890e100
0                 ; NOTE: this is still wrong, but it's another issue and
                  ; it needs a patch given later

What version of the product are you using? On what operating system?

Ver. 361:2f8f2e85eafc Linux Fedora 12 x86

Please provide any additional information below.

The attached patch fixes the issues as shown above, by:
1) avoiding to overwrite the error returned by sexp_read_error().
2) avoiding to call sexp_push_char() when not needed.

As I don't have a 64 bit machine, right now I can't provide failing cases
for such arch, but they should be easily guessed from the description above.

Original issue reported on code.google.com by [email protected] on 29 Jan 2010 at 10:05

Attachments:

417:08c0e5ea9972 breaks the build for me

What steps will reproduce the problem?
1. check out tip or anything newer than 416
2. type make

What is the expected output? What do you see instead?

I expected to see stuff compiled.  Instead it complains that it can't
build x86.so.

What version of the product are you using? On what operating system?

tip (420) on Linux/386.

Please provide any additional information below.

See the Makefile diff here:
http://code.google.com/p/chibi-scheme/source/detail?
r=08c0e5ea99725f0ea01b4a5e8fc54c84381dd1cd

Original issue reported on code.google.com by [email protected] on 18 Apr 2010 at 12:16

exception handler nesting issues

(I'm assuming continuable exceptions are an intentional aspect of the design.)

This is currently happening:

> (with-exception-handler
    (lambda (ex) (display "outer\n"))
    (lambda ()
      (with-exception-handler
        (lambda (ex) (display "inner\n"))
        (lambda ()
          (raise 1)
          (display "continued 1\n")
          (raise 2)
          (display "continued 2\n")))))
inner
continued 1
outer
continued 2


I think it should be:

inner
continued 1
inner
continued 2


Below is a patch to fix this.  Note that the fix correctly does:

> (with-exception-handler
    (lambda (ex) (display "handler 1\n"))
    (lambda ()
      (with-exception-handler
        (lambda (ex)
          (display "handler 2\n")
          (raise 1))
        (lambda ()
          (with-exception-handler
            (lambda (ex)
              (display "handler 3\n")
              (raise 1))
            (lambda ()
              (raise 1)
              (display "continued 1\n")
              (raise 1)
              (display "continued 2\n")))))))
handler 3
handler 2
handler 1
continued 1
handler 3
handler 2
handler 1
continued 2


--- a/lib/init.scm  Sat Dec 26 16:21:37 2009 +0900
+++ b/lib/init.scm  Sat Dec 26 01:00:25 2009 -0800
@@ -313,9 +313,12 @@
 (define (with-exception-handler handler thunk)
   (let ((orig-handler (current-exception-handler)))
     (current-exception-handler
-     (lambda (exn)
-       (current-exception-handler orig-handler)
-       (handler exn)))
+     (letrec ((self (lambda (exn)
+                      (current-exception-handler orig-handler)
+                      (let ((res (handler exn)))
+                        (current-exception-handler self)
+                        res))))
+       self))
     (let ((res (thunk)))
       (current-exception-handler orig-handler)
       res)))

Original issue reported on code.google.com by [email protected] on 26 Dec 2009 at 9:03

Closing dynamic libraries

Hello I opened issues #36 & #37 under an old email address, this is my
current one.

Chibi needs to close dynamic library handles. I would be happy to write a
patch but I wasn't sure how to go about it.

Original issue reported on code.google.com by [email protected] on 9 Mar 2010 at 4:34

Inscrutable error when it cannot find init.scm

What steps will reproduce the problem?
1.make chibi-scheme-static
2.cd ..
3../chibi-scheme/chibi-scheme-static
4. (list 1 2 3)

What is the expected output? What do you see instead?
Expected:
> (list 1 2 3)
(1 2 3)
> 
Actual:
ERROR: not a string: #f
> (list 1 2 3)
ERROR: undefined variable: list
WARNING: reference to undefined variable: list
> 

What version of the product are you using? On what operating system?
changeset:   153:e8871a9d12f8 on Ubuntu Ubuntu 9.04 ("Jaunty Jackalope")
x86 32-bit

Please provide any additional information below.

Original issue reported on code.google.com by eric.hanchrow on 2 Jul 2009 at 1:33

mkfile doesn't generate include/chibi/install.h correctly; build fails

Taking the current trunk, the system does not compile on Plan 9. The first 
error hit is that the 
define of sexp_version_string on main.c:13 causes problems at main.c:175.

This seems to simply be because the mkfile is out of date. Makefile puts 
#defines of sexp_version 
and sexp_release_name in include/chibi/install.h; mkfile doesn't. I changed the 
mkfile clause 
generating include/chibi/install.h to read:

include/chibi/install.h: mkfile
    echo '#define sexp_default_module_dir "'$MODDIR'"' > include/chibi/install.h
    echo '#define sexp_platform "plan9"' >> include/chibi/install.h
    echo '#define sexp_version "'`{cat VERSION}'"' >> include/chibi/install.h
    echo '#define sexp_release_name "'`{cat RELEASE}'"' >> include/chibi/install.h

This is everything from Makefile except sexp_so_extension.

There is another change needed to make compilation on Plan 9 work again; filing 
a separate 
ticket for that.

Original issue reported on code.google.com by [email protected] on 24 Mar 2010 at 9:50

Exceptions from reader are not propagated

Take the following code:

  (define (f x) (case x ((#\cr) 'cr) (else 'else)))

This code is parsed properly, though chibi-scheme does not know about a 
character #\cr 
(=#\return).  On toplevel #\cr is not parsed, in the expression this problem 
seems to be ignored.

Take the following example however (it is also parsed properly):

  (define (f2 x) (case x ((#\cr) 'xxx) (else '(#\cr))))

When calling:

  (f2 6)

however, the result is:

  => (#<exception>)

I've attached a patch (against HEAD)

Original issue reported on code.google.com by [email protected] on 3 Oct 2009 at 9:22

Attachments:

exception handling bugs

A couple:

> (with-exception-handler
    (lambda (ex) (unbound))
    (lambda () (error "oops")))
Segmentation fault


> (with-exception-handler
    (lambda (ex) (display "caught\n"))
    (lambda () (error "oops")))
caught
caught
> 

The handler is getting called twice.

Original issue reported on code.google.com by [email protected] on 26 Dec 2009 at 6:33

Division "breaks" bignum values.

Dividing (even by one) a bignum value produces a "lesser" number for which
exact->inexact fails to give a correct answer.

What steps will reproduce the problem?

> (let ((n 536870912)) (list n (exact->inexact n)))
(536870912 536870912.0)

> (let ((n (/ 536870912 1))) (list n (exact->inexact n)))
(536870912 43486543872.0)

What is the expected output? What do you see instead?

The expected value is the same in both cases

What version of the product are you using? On what operating system?

Rev. 7ba22eff93

Please provide any additional information below.

As a possibly unrelated note, it looks like bignum are neither exact nor
inexact, is this correct?

> (exact? 536870912)
#f
> (inexact? 536870912)
#f
> 


Original issue reported on code.google.com by [email protected] on 1 Jan 2010 at 6:15

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.