gmane.lisp.scheme.chibi

chibi repl failure

Lorenzo Campedelli — 2013-05-25T06:04:43

Hello,

it seems chibi.repl has some problem:

$ chibi-scheme -mchibi.repl -e'(repl)'
ERROR in child thread: #<Context>
ERROR in point-depth on line 583 of file /usr/share/chibi/init-7.scm: 
vector-ref: not a vector: (#f)
ERROR in point-depth on line 583 of file /usr/share/chibi/init-7.scm: 
vector-ref: not a vector: (#f)


Not sure when it started, as I've not been updating from hg since last 
February,
but is seems might be related to revision 4505057ebc97: "Using non-mutating 
tree of dynamic-wind state for thread safety."

Lorenzo

Re: GC-management of foreign function sexp arguments

Alex Shinn — 2013-05-23T00:33:46



No.  As I said before, you should assume all passed
parameters are preserved.

Re: GC-management of foreign function sexp arguments

2013-05-22T19:36:50

That is, are there any steps needed to properly manage garbage collection.

On Wednesday, May 22, 2013 2:40:14 PM UTC-4, cino...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org wrote:

GC-management of foreign function sexp arguments

2013-05-22T18:40:14

sexp_define_foreign can define functions that take sexp arguments.

...
sexp_define_foreign(ctx, env, "foo", 1, foo);
...
sexp foo(sexp ctx, sexp self, sexp n, sexp arg){
  ...
}

Are there any steps needed to manipulate the argument?

sexp foo(sexp ctx, sexp self, sexp n, sexp arg){
  arg = sexp_make_integer(ctx, 42);
  return arg;
}

Re: Creating a bytevector in C interface

Alex Shinn — 2013-05-22T03:54:35



Correct.

Re: Creating a bytevector in C interface

2013-05-22T03:13:39

Oh whoops. I neglected the last clause there; I assume it being invalidated 
means it doesn't need to be GC-managed.

On Tuesday, May 21, 2013 11:12:17 PM UTC-4, cino...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org wrote:

Re: Creating a bytevector in C interface

2013-05-22T03:12:17

Thanks. In this case, would the the result from sexp_c_string need to be 
GC-managed?

On Tuesday, May 21, 2013 10:42:06 PM UTC-4, Alex Shinn wrote:

Re: Creating a bytevector in C interface

Alex Shinn — 2013-05-22T02:42:06



Yes, the Chibi C API was written before the R7RS name "bytevector" was
finalized.

Additionally, there is the procedure sexp_make_bytes which I believe is the

You can use

  sexp_string_to_bytes(ctx, sexp_c_string(ctx, some_char_ptr, -1))

Note sexp_string_to_bytes is a macro, and the string is
invalidated after it's called.

Re: Creating a bytevector in C interface

2013-05-22T02:37:56

After prodding around the source for a bit, the source appears to call it 
bytes rather than bytevector.

Additionally, there is the procedure sexp_make_bytes which I believe is the 
Scheme equivalent of make-vector, however a procedure to create a 
bytevector from an arbitrary data buffer would be convenient.

On Tuesday, May 21, 2013 4:50:47 PM UTC-4, cino...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org wrote:

Re: Passing around GC managed sexpr's

2013-05-22T02:34:39

Makes sense, thank you.

On Tuesday, May 21, 2013 8:54:23 PM UTC-4, Alex Shinn wrote:

Re: Passing around GC managed sexpr's

Alex Shinn — 2013-05-22T00:54:23


The same way.  The assumption is that everything passed to
a function (and presumably addresses if you want to use them)
is already preserved, so a function is only responsible for the
allocations it makes, directly or indirectly.

More specifically, the results of any computation in your function
must be preserved, excluding the last.  Thus in the simple case
that you only allocate a single object you don't need to preserve
anything:

sexp bar(sexp ctx) {
  return sexp_make_integer(ctx, 42);
}

If you do potentially perform additional allocations you need to
preserve:

/* WRONG! */
sexp add_forty_two(sexp ctx, sexp x) {
  return sexp_add(ctx, x, sexp_make_integer(ctx, 42));
}

/* Correct */
sexp add_forty_two(sexp ctx, sexp x) {
  sexp res;
  sexp_gc_var1(tmp);
  sexp_gc_preserve1(ctx, tmp);
  tmp = sexp_make_integer(ctx, 42);
  res = sexp_add(ctx, x, tmp);        // final allocation, so
  sexp_gc_release1(ctx);              // no need to preserve res
  return res;
}

Of course, here sexp_make_integer(ctx

Re: Multi-lined comments treated as one line

Alex Shinn — 2013-05-22T00:36:32


Thanks!  I'll fix this shortly, but I just moved and have no internet at
home this week.

Re: Passing around GC managed sexpr's

2013-05-21T23:03:57

The second bar function should return baz.

On Tuesday, May 21, 2013 6:56:44 PM UTC-4, cino...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org wrote:

Multi-lined comments treated as one line

2013-05-21T23:02:31

$ cat a
(+ 1 1)
$ chibi-scheme a
ERROR on line 1 of file a: undefined variable: +
$ cat b
#| This is a
multi-lined comment |#
(+ 1 1)
$ chibi-scheme b
ERROR on line 2 of file b: undefined variable: +
$

The second error should display line 3 instead of line 2.

Passing around GC managed sexpr's

2013-05-21T22:56:44

I know that this is the general way of handling GC managed sexpr's:

void foo(void){
  sexpr_gc_var1(tmp);
  sexpr_gc_preserve1(ctx, tmp);

  sexpr_gc_release1(ctx);
}

But what would be the best way to pass around GC managed sexpr's?:

void bar(sexpr *baz){
  *baz = sexp_make_integer(ctx, 42);
}

void foo(void){
  sexpr_gc_var1(tmp);
  sexpr_gc_preserve1(ctx, tmp);
  bar(&tmp);
  sexpr_gc_release1(ctx);
}

or

sexpr bar(void){
  sexpr_gc_var1(tmp);
  sexpr_gc_preserve1(ctx, baz);
  baz = sexp_make_integer(ctx, 42);
  sexpr_gc_release1(ctx);
}

void foo(void){
  sexpr_gc_var1(tmp);
  sexpr_gc_preserve1(ctx, tmp);
  tmp = bar();
  sexpr_gc_release1(ctx);
}

Creating a bytevector in C interface

2013-05-21T20:50:47

In Scheme, a string literal would be "foo" and a bytevector literal would 
be #u8(1 2 3).

The C interface provides sexp_c_string; is there an analogue for 
bytevectors? I grepped the includes for bytevector but came up with nothing.

Re: Creating a list in C interface

2013-05-15T00:08:17

Thanks, works perfectly.

On Tuesday, May 14, 2013 7:47:53 PM UTC-4, Alex Shinn wrote:

Re: Creating a list in C interface

Alex Shinn — 2013-05-14T23:47:53


You forgot all the GC steps :)

Both sexp_cons and sexp_c_string allocate memory, so
you'll need to declare ret and a tmp as GC managed vars:

sexp_gc_var2(ret, tmp);
sexp_gc_preserve2(ctx, ret, tmp);
...
tmp = sexp_c_string(ctx, ent->d_name, -1);
ret = sexp_cons(tmp, ret);
...
sexp_gc_release2(ctx);
return ret;

Creating a list in C interface

2013-05-14T20:25:53

sexp om_enum_files(sexp ctx, sexp self, sexp n){
  sexp ret = SEXP_NULL;

  DIR *dir = opendir("./");
  struct dirent *ent;
  while(ent = readdir(dir)){
    if(ent->d_type == DT_REG){
      ret = sexp_cons(ctx, sexp_c_string(ctx, ent->d_name, -1), ret);
    }
  }
  closedir(dir);

  return ret;
}

This code seems to work for a directory with let's say, 26 files, but it 
seems to break on a directory with around 17k files and some with non-ASCII 
characters (don't know if that's relevant?). Is there something 
fundamentally wrong with the iteration, perhaps I forgot some GC steps?

Re: cross compiling chibi

Dirk Theisen — 2013-05-13T11:49:46

Hey, Attila!

What's that state on this project?

I'd like to see Chibi on OpenWRT / Mips. Someone done this?

Dirk

Am Donnerstag, 2. Februar 2012 16:10:29 UTC+1 schrieb Alex Shinn:

R7RS-small voting deadline extended through May 20

John Cowan — 2013-05-10T16:02:33

For various reasons, the deadline for voting on R7RS-small draft 9 has
been extended through May 20.  That is, votes will be accepted until
May 20 has passed into history everywhere on Earth, which is the same
as saying until noon UTC on May 21.

For voting instructions, see
<http://lists.scheme-reports.org/pipermail/scheme-reports/2013-April/003299.html>.