Re: [Chicken-users] New egg: hopefully

[Sudarshan S Chawathe]

I cannot seem to access this egg.  'chicken-install' doesn't know about
it (yet?) which didn't surprise me too much, but I also get HTTP 404
errors when using the link to the source from the egg's doc page on
call-cc.org (and ditto for the link on the askemos.org page):

  http://askemos.org/chicken-eggs/hopefully.tar.gz

Is there some other place I should check?

Regards,

-chaw

> To: chicken-users 
> From: Jörg F. Wittenberger 
> Date: Thu, 17 Dec 2015 22:38:54 +0100
> Subject: [Chicken-users] New egg: hopefully
> 
> Hi,
> 
> I just released the "hopefully" egg:  Composable transactional memory.
> 
> API inspired by Clojure's ref's and STMX.
> 
> Currently only some record types may be used with hopefully.  Further
> versions should add other mutable types.
> 
> I'd love to get feedback on the API.
> 
> https://wiki.call-cc.org/eggref/4/hopefully
> 
> Release-info and source is at
> http://askemos.org/chicken-eggs/index.html
> (this may be added the egg index).
> 
> Best
> 
> /Jörg
> 
> BTW: STM is usually advertised because it frees the programmer from
> getting locking sequences right.  However at least the "good", low level
> API appears to here be marginally (~5-10%) faster than the equivalent
> code using mutexs.

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

Re: [Chicken-users] This may be a bug in chickens hash tables - or my bad

[John Cowan]

Ivan Shmakov scripsit:

>   Given that the basic idea of hashing is to produce a key out of
>   the object’s /value/, the change of the value – and mutation
>   does just that – changes the hash.  

Well, yes and no.  SRFI 69 and other Scheme hash table frameworks
support at least two kinds of hashing: hash by value and hash by
identity.  If you have a large tree structure made with pairs, and
you want to keep ancillary information about some but not all of
the pairs, an identity-based hash table will let you keep the information
associated with *a particular pair*.  Otherwise, if you had a tree like
(a (b c) (b c)), then any information associated with the first (b c)
would be overwritten if you associated information with the second (b c).
This is quite independent of whether you ever mutate the tree or not.

-- 
John Cowan  http://www.ccil.org/~cowanco...@ccil.org
As you read this, I don't want you to feel sorry for me, because,
I believe everyone will die someday.
   --From a Nigerian-type scam spam

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

Re: [Chicken-users] New egg: hopefully

[Jörg F . Wittenberger]

Am 18.12.2015 um 17:41 schrieb Sudarshan S Chawathe:
> 
> I cannot seem to access this egg.  'chicken-install' doesn't know about
> it (yet?) which didn't surprise me too much, but I also get HTTP 404
> errors when using the link to the source from the egg's doc page on
> call-cc.org (and ditto for the link on the askemos.org page):
> 
>   http://askemos.org/chicken-eggs/hopefully.tar.gz

Thanks for the report.  This link was wrong:

http://askemos.org/chicken-eggs/hopefully/hopefully.tar.gz

> 
> Is there some other place I should check?
> 
> Regards,
> 
> -chaw
> 
>> To: chicken-users 
>> From: Jörg F. Wittenberger 
>> Date: Thu, 17 Dec 2015 22:38:54 +0100
>> Subject: [Chicken-users] New egg: hopefully
>>
>> Hi,
>>
>> I just released the "hopefully" egg:  Composable transactional memory.
>>
>> API inspired by Clojure's ref's and STMX.
>>
>> Currently only some record types may be used with hopefully.  Further
>> versions should add other mutable types.
>>
>> I'd love to get feedback on the API.
>>
>> https://wiki.call-cc.org/eggref/4/hopefully
>>
>> Release-info and source is at
>> http://askemos.org/chicken-eggs/index.html
>> (this may be added the egg index).
>>
>> Best
>>
>> /Jörg
>>
>> BTW: STM is usually advertised because it frees the programmer from
>> getting locking sequences right.  However at least the "good", low level
>> API appears to here be marginally (~5-10%) faster than the equivalent
>> code using mutexs.
> 
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
> 


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

Re: [Chicken-users] This may be a bug in chickens hash tables - or my bad

[Jörg F . Wittenberger]

Am 18.12.2015 um 18:35 schrieb John Cowan:
> Ivan Shmakov scripsit:
> 
>>  Given that the basic idea of hashing is to produce a key out of
>>  the object’s /value/, the change of the value – and mutation
>>  does just that – changes the hash.  
> 
> Well, yes and no.  SRFI 69 and other Scheme hash table frameworks
> support at least two kinds of hashing: hash by value and hash by
> identity.  If you have a large tree structure made with pairs, and
> you want to keep ancillary information about some but not all of
> the pairs, an identity-based hash table will let you keep the information
> associated with *a particular pair*.  Otherwise, if you had a tree like
> (a (b c) (b c)), then any information associated with the first (b c)
> would be overwritten if you associated information with the second (b c).
> This is quite independent of whether you ever mutate the tree or not.

Not necessarily.

Given the typical vector+alist implementation, this would still allow to
associate values to each particular pair.

The problem really arises only around the question what hash-by-identity
actually means.

I would understand the language as: "two objects comparing eq? will hash
to the same value".

This would imply that the hash value would have to be somehow
(implementation specific) being derived from a unique property of the
particular object.  (Easy if we'd assume malloc als allocator: just tag
the address bits as fixnum.  Harder for moving garbage collectors.)

So the question is kind of nitpicking: does the srfi-69 /mandate/ that
at least the hash-by-identity will produce the same value for the same
object over the livetime of the object even if the object is mutated?

If so, then we should change the chicken manual to document a deviation
from the standard.  Until we have a good idea how to fix it, that is.

Otherwise I'd still put a warning into the manual.  For boneheads like me.

I mean: the problem is trivial to work around, once you know what you're
dealing with.

/Jörg

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

Re: [Chicken-users] New egg: hopefully

[Sudarshan S Chawathe]

Thanks for the updated pointer to the source.

I installed the egg in the usual way ('chicken-install' in the directory
with the source files) but could not run the included test
(test/run.scm) successfully, although csc compiles it fine.  (Details
below.)  In interactive use, I get an error:

  cannot load extension: hopefully-intern

Perhaps I'm missing something obvious, or perhaps the tests/run.scm is
for internal use only?  

Regards,

-chaw


$ csc run.scm 
$ ./run 
D Initial: set
D Value in other thread is unchanged...: 9
D #: also in other thread former ref is still unchanged...
D even after commit.  (Note: tests caching of references to fields.): 9
D Value in other thread is unchanged...: 9
D Second round expecting changed value: 252
D #: also in other thread former ref is still unchanged...
D even after commit.  (Note: tests caching of references to fields.): 9

Error: (run.scm:161) assertion failed: (= (obox-v b1) 455)

Call history:

run.scm:159: step!
run.scm:123: mutex-unlock!
hopefully.scm:224: transaction-commit!
hopefully.scm:165: hopefully-intern-atomics#stmtnx-owner  
hopefully.scm:167: hopefully-intern-atomics#stmtnx-id 
hopefully.scm:168: hopefully-intern-atomics#stmtnx-refs   
hopefully.scm:199: loop   
hopefully.scm:196: loop   
hopefully.scm:186: loop   
hopefully.scm:177: hopefully-intern-atomics#transaction-close!
hopefully-intern-atomics.scm:119: transaction-reset!  
hopefully-intern-atomics.scm:33: ##sys#block-set! 
run.scm:161: obox-v   
run.scm:22: hopefully-intern-atomics#current-transaction  
hopefully-intern-atomics.scm:68: %current-transaction 
run.scm:161: ##sys#error<--
$ 

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