ashinn / chibi-scheme Goto Github PK
View Code? Open in Web Editor NEWOfficial chibi-scheme repository
License: Other
Official chibi-scheme repository
License: Other
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:
> (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
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:
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
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:
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:
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
should be wrapped in #ifndef
Original issue reported on code.google.com by [email protected]
on 30 Mar 2010 at 4:02
Attachments:
Running:
> (let lp () (open-output-string) (lp))
will eventually consume all memory.
Original issue reported on code.google.com by [email protected]
on 9 Mar 2010 at 11:18
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
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:
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:
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
> (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:
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:
(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
- 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:
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
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
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
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:
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:
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
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:
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
(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
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:
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:
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
1. spurious space in "Source/Checkout/Command-Line Access" hg clone line.
2. "R5" (sic) link in "Project Home/Summary" is 404.
3. add DESTDIR handling to Makefile? diff attached...
Original issue reported on code.google.com by [email protected]
on 29 Jun 2009 at 2:50
Attachments:
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:
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:
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
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:
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
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
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:
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
> (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
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
(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
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:
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:
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
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:
[deleted issue]
> (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
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:
(#t .) causes the REPL to stop accepting input
Original issue reported on code.google.com by [email protected]
on 16 Mar 2010 at 12:33
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.