Sascha Ziemann | 10 Jan 15:13 2012
Picon

(integer->char -1)

The function integer->char does funny things for -1. This is the
output on my system:

$ gosh
gosh> (integer->char -1)
#\������
gosh>

Is this intended?

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Gauche-devel mailing list
Gauche-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gauche-devel
Shiro Kawai | 10 Jan 15:55 2012
Picon

Re: (integer->char -1)

From: Sascha Ziemann <ceving <at> gmail.com>
Subject: [Gauche-devel] (integer->char -1)
Date: Tue, 10 Jan 2012 15:13:17 +0100

> The function integer->char does funny things for -1. This is the
> output on my system:
> 
> $ gosh
> gosh> (integer->char -1)
> #\������
> gosh>
> 
> Is this intended?

No, it's not.  Will fix.

--shiro


------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Gauche-devel mailing list
Gauche-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gauche-devel
(Continue reading)

Sascha Ziemann | 12 Jan 14:10 2012
Picon

copy-bit-field buggy?

The function copy-bit-field from srfi-60 seems to be buggy.

This is what SCM does:

> (number->string (copy-bit-field #b1000 -1 0 3) 2)
"1111"
> (number->string (copy-bit-field #b0000 -1 0 3) 2)
"111"

And this is what Gauche does:
$ gosh -u srfi-60
gosh> (number->string (copy-bit-field #b1000 -1 0 3) 2)
"1000"
gosh> (number->string (copy-bit-field #b0000 -1 0 3) 2)
"0"

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
Sascha Ziemann | 12 Jan 09:57 2012
Picon

Fwd: SRFI-60 integer->list and list->integer

Gauche list->integer function does not check for negative numbers either:

gosh> (integer->list 0)
()
gosh> (integer->list -1)
()
gosh> (list->integer (integer->list -1))
0

---------- Forwarded message ----------
From: Aubrey Jaffer <agj <at> alum.mit.edu>
Date: 2012/1/10
Subject: Re: SRFI-60 integer->list and list->integer
To: Sascha Ziemann <ceving <at> gmail.com>

 | Date: Tue, 10 Jan 2012 15:56:14 +0100
 | From: Sascha Ziemann <ceving <at> gmail.com>
 |
 | Hello,
 |
 | I have a question about the integer->list function in SRFI-60.
 |
 | The function list->integer does not seem to be the reverse function
 | for integer->list:
 |
 | $ scm
 | > (list->integer (integer->list -1))
 | 0
 |
 | Is this the intended behavior?
(Continue reading)

Kirill Zorin | 14 Jan 04:52 2012

Thinking again about parameters in the VM

>From private correspondence with Shiro:

"[An] error happens when a parameter is created *after* some
threads are already running, and the parameter is used
in those threads that were already running.  One possible
scenario is like this:

- We have thread A and thread B running.
- Thread A calls (use rfc.http) for the first time.
 This loads http.scm and creates parameters.
 Thread B isn't aware of those parameters.
- Thread B *dynamically* loads some file, say, foo.scm,
 which contains (use rfc.http).  This time http.scm has
 already been loaded, so it's no-op.
- Thread B calls some function defined in foo.scm,
 which in turn makes http call.  The call accesses
 parameters defined in http.scm, but they are not
 visible from B, hence the error.

This won't happen typically, since usually the modules
used by the program is statically stated in `use' form;
so when a thread starts running, all the necessary parameters
are already created.

However, if a module is dynamically loaded (via explicitly
by 'load', or implicitly by autoload), the above scenario
can happen.

[...]

(Continue reading)

Kirill Zorin | 14 Jan 05:08 2012

Re: Thinking again about parameters in the VM

One way would be to create a global table that holds all parameters
ever initialized (per module, I suppose, since the module system is
global as well) paired with their initial values. Then the parameter
getter procedure can be modified to check, on ref error, if the "same"
parameter exists in the table, and if so, to initialize a new
parameter of the same name in its own local storage using the initial
value stored in the table.

This would only fire for parameter ref errors, and we're assuming here
that most programs are at least well formed enough to not rely on or
exhibit parameter ref errors frequently.

The only thing that's probably bad is that now parameter creation is
serialized... I'm not sure how much of a handicap it is in
practice.

Thoughts?

On 2012-01-13, at 10:52 PM, Kirill Zorin wrote:

>> From private correspondence with Shiro:
> 
> "[An] error happens when a parameter is created *after* some
> threads are already running, and the parameter is used
> in those threads that were already running.  One possible
> scenario is like this:
> 
> - We have thread A and thread B running.
> - Thread A calls (use rfc.http) for the first time.
> This loads http.scm and creates parameters.
(Continue reading)

Shiro Kawai | 14 Jan 07:28 2012
Picon

Re: Thinking again about parameters in the VM

From: Kirill Zorin <k.zorin <at> me.com>
Subject: Re: [Gauche-devel] Thinking again about parameters in the VM
Date: Fri, 13 Jan 2012 23:08:03 -0500

> One way would be to create a global table that holds all parameters
> ever initialized (per module, I suppose, since the module system is
> global as well) paired with their initial values. 

Yes, that's what I have in mind now.

> The only thing that's probably bad is that now parameter creation is
> serialized... I'm not sure how much of a handicap it is in
> practice.

I don't think it's much problem, for typical parameters are
create at toplevel, when a module is loaded.  That happens only
once per module.

Parameters can be created locally, but that's not common, and
Gauche's current implementation doesn't handle such case well
anyway (for example, parameters won't be GC-ed)

--shiro

------------------------------------------------------------------------------
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
(Continue reading)

Michael Campbell | 14 Jan 08:49 2012

Re: Thinking again about parameters in the VM

Actually, I most often run into this problem when I'm working at the
REPL and reloading modules containing parameters referenced by code
called in other threads.  I reload the module defining the parameter,
and then my other (existing) threads blow up due to what are
effectively new parameter objects, from their point of view.

The obvious work-around is to always use some kind of a macro with
semantics like CL's 'defvar' (vs 'defparameter') or Clojure's
'defonce' for defining parameter objects, but then of course I have to
remember to actually use it instead of 'define'.  This approach mostly
works, except in the (fairly rare) cases where I decide to change a
parameter's default value, which need to be handled manually, one way
or another.

It sounds like your proposed global parameter table would do away with
these issues completely though.

On Fri, Jan 13, 2012 at 11:08:03PM -0500, Kirill Zorin wrote:
> One way would be to create a global table that holds all parameters
> ever initialized (per module, I suppose, since the module system is
> global as well) paired with their initial values. Then the parameter
> getter procedure can be modified to check, on ref error, if the "same"
> parameter exists in the table, and if so, to initialize a new
> parameter of the same name in its own local storage using the initial
> value stored in the table.
> 
> This would only fire for parameter ref errors, and we're assuming here
> that most programs are at least well formed enough to not rely on or
> exhibit parameter ref errors frequently.
> 
(Continue reading)

Kiril Zorin | 15 Jan 04:45 2012

Re: Thinking again about parameters in the VM

Shiro, have you already started working on this, or should I put something together? I think it might be
possible to implement entirely in Scheme without touching any C code. Maybe not =)

On 2012-01-14, at 1:28 AM, Shiro Kawai <shiro <at> lava.net> wrote:

> From: Kirill Zorin <k.zorin <at> me.com>
> Subject: Re: [Gauche-devel] Thinking again about parameters in the VM
> Date: Fri, 13 Jan 2012 23:08:03 -0500
> 
>> One way would be to create a global table that holds all parameters
>> ever initialized (per module, I suppose, since the module system is
>> global as well) paired with their initial values. 
> 
> Yes, that's what I have in mind now.
> 
>> The only thing that's probably bad is that now parameter creation is
>> serialized... I'm not sure how much of a handicap it is in
>> practice.
> 
> I don't think it's much problem, for typical parameters are
> create at toplevel, when a module is loaded.  That happens only
> once per module.
> 
> Parameters can be created locally, but that's not common, and
> Gauche's current implementation doesn't handle such case well
> anyway (for example, parameters won't be GC-ed)
> 
> --shiro
> 
> 
(Continue reading)

Shiro Kawai | 15 Jan 09:42 2012
Picon

Re: Thinking again about parameters in the VM

No, I haven't started.  If you have any idea, you're welcome to go
for it (but if the change gets pretty big, please keep us updated
so that your effort won't be wasted.)

I doubt you can do it without touching C code, since parameters
can be created by C API Scm_DefinePrimitiveParameter as well.

--shiro

From: Kiril Zorin <k.zorin <at> me.com>
Subject: Re: [Gauche-devel] Thinking again about parameters in the VM
Date: Sat, 14 Jan 2012 22:45:47 -0500

> Shiro, have you already started working on this, or should I put something together? I think it might be
possible to implement entirely in Scheme without touching any C code. Maybe not =)
> 
> On 2012-01-14, at 1:28 AM, Shiro Kawai <shiro <at> lava.net> wrote:
> 
>> From: Kirill Zorin <k.zorin <at> me.com>
>> Subject: Re: [Gauche-devel] Thinking again about parameters in the VM
>> Date: Fri, 13 Jan 2012 23:08:03 -0500
>> 
>>> One way would be to create a global table that holds all parameters
>>> ever initialized (per module, I suppose, since the module system is
>>> global as well) paired with their initial values. 
>> 
>> Yes, that's what I have in mind now.
>> 
>>> The only thing that's probably bad is that now parameter creation is
>>> serialized... I'm not sure how much of a handicap it is in
(Continue reading)


Gmane