headers
Daniel B. Faken | 1 Aug 2005 05:47

[ANN] Alpha version of Scripting bindings to Chromium available

Hello,

  I've put up an early version of my Scheme scripting bindings for 
Chromium (chromium.sourceforge.net) at:
  http://www.cascv.brown.edu/~faken/sscriptedSPU-0.1a.tgz

The included README follows.

Comments, etc. are welcome (though I'll be on vacation until Aug 8th).

cheers,
Daniel Faken

---------------------------------------------------------------------
| README for Scheme-Scripted SPU  -  A.K.A. sscriptedspu
---------------------------------------------------------------------
Version: 0.1 (alpha) - July 31, 2005

This is a SPU (Stream-Processing Unit) for "Chromium" v1.8.
More information on Chromium is at http://chromium.sourceforge.net.

This SPU allows callbacks into Scheme, using the 'Chicken' scheme->C 
compiler.
More information on Chicken is at 
http://www.call-with-current-continuation.org.

----------------
LICENSE
----------------
This is released under the Lesser GNU Public License.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reed Sheridan | 1 Aug 2005 09:11
Picon

Re: Better algorithm for growing hash tables

That explains Chicken's pathetic performance in the spellcheck
benchmark in the alioth shootout (
http://shootout.alioth.debian.org/benchmark.php?test=spellcheck&lang=all&sort=fullcpu
) - dead last, at 35.4 seconds, compared to 16.9 seconds for the next
slowest language.  It's writing and reading ~39000 entries into a
10000 size hash table, with this dumb algorithm.  By changing the size
to 80000, on my machine the time for this benchmark goes from 42.7
seconds to .862 seconds, which would put Chicken near the top (I also
replaced cute with (lambda (x) ...), but that's a much smaller
factor.)

> Date: Fri, 29 Jul 2005 10:01:42 -0500
> From: Alejandro Forero Cuervo <azul <at> freaks-unidos.net>
> Subject: Re: [Chicken-users] Better algorithm for growing hash tables
> To: bunny351 <at> gmail.com, chicken-users <at> nongnu.org
> Message-ID: <20050729150142.GB18298 <at> bachue.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> > > (use srfi-1)
> > > (define hash (make-hash-table))
> > > (for-each (lambda (n) (hash-table-set! hash hash n)) (iota 1000000))
> 
> Erm, I meant
> 
>   (for-each (lambda (n) (hash-table-set! hash n #f)) (iota 1000000)) ,
> 
> of course.
> 
> Alejo.
> http://azul.freaks-unidos.net/
(Continue reading)

Permalink | Reply | 0 comments |
headers
felix winkelmann | 1 Aug 2005 11:39
Picon

Re: Bug in format: can't iterate over 100 values?

On 7/31/05, Alejandro Forero Cuervo <azul <at> freaks-unidos.net> wrote:
> Hi.
> 
> I just thought I'd report a bug in format that has bit me recently.
> It is very easy to reproduce:
> 
>   (use srfi-1 format)
>   (format #f "~{ ~A~}" (iota 200))
> 
> Notice that the returned string includes the numbers from 0 to 99, not
> to 200! :/

Look at this: 

format.scm:706:		 (else (if (not max-iterations) (set! max-iterations 100))))

Very strange. We should probably increase this a little. What the author
intended can only be guessed at...

> 
> BTW, I have a slightly incomplete implementation of format.  If anyone
> cares to help me finish it, we could replace the implementation in
> Chicken.  It already supports the following escape sequences (with all
> their optional arguments/colon/at): ~A ~S ~/ ~X ~D ~O ~B ~% ~( ~) ~[
> ~; ~] ~? ~* ~P ~{ ~} ~^.  It has two important advantages over
> Chicken's implementation: it is reentrant (thus can be safely used
> with threads or building streams of characters using a custom port)
> and is modular (allowing the caller to define new escape sequences).
> If anyone is interested, this is available at:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
felix winkelmann | 1 Aug 2005 12:31
Picon

Re: Lightweight threads, etc. : Chicken vs. Gambit

On 7/31/05, Joel Reymont <joelr1 <at> gmail.com> wrote:
> 
> How do the lightweight threads in Chicken compare to those of Gambit?

Chicken's threads are slower (about half the speed of Gambit in most
benchmarks), which is still orders of magnitude better than most other
languages (with the exception of Erlang) provide.

> 
> Can Chicken continuations be serialized?

No. It's evil. 

> 
> How is the numerical performance of Chicken vs. Gambit?

On floating-point intensive arithmetic, Chicken can keep up with Gambit
(last time I tested), for fixnum-only code Gambit will be faster.
I haven't compared the performance of the numbers egg (bignums and
rationals) with other implementations yet.

cheers,
felix
Permalink | Reply | 0 comments |
headers
Nelson Castillo | 2 Aug 2005 16:50
Picon
Gravatar

Re: Re: Better algorithm for growing hash tables

On 8/1/05, Ed Watkeys <edw <at> xmog.com> wrote:
> 
> On Aug 1, 2005, at 4:52 PM, Alejandro Forero Cuervo wrote:
> 
> >> That explains Chicken's pathetic performance in the spellcheck
> >> benchmark in the alioth shootout (
> >> http://shootout.alioth.debian.org/benchmark.php?
> >> test=spellcheck&lang=all&sort=fullcpu
> >> ) - dead last, at 35.4 seconds, compared to 16.9 seconds for the next
> >> slowest language.  It's writing and reading ~39000 entries into a
> >> 10000 size hash table, with this dumb algorithm.
> >>
> >
> > That's probably right.  I suppose currently it performs (39000 -
> > 500) / 101 = 337 resizes, whereas with the change it would resize
> > the table from 10000 to 39709 and then to 79423, just 3 resizes. :)
> 
> _The Practice of Programming_ (Kernighan & Pike) deals with a
> situation analgous to this; they grow storage for a string by powers
> of two. This works well because it heavily tests the algorithm --
> from 1 to 2 to 4 to 8... -- but also causes a grow for every log n
> inserts i.e. rarely.

Yup. But you really should use prime numbers for hash tables.
Permalink | Reply | 5 comments |
headers
Ash | 2 Aug 2005 22:20
Picon

Meroon superclasses

Hi,

I've been playing around with the meroon egg, comparing it to tinyclos. 
With tinyclos, I can define a superclass in a one file (or even a static
library), then subclass from it in another file, as long as
both files are linked into the program.

With meroon, the superclass definition must be available at
compile-time.  So, two questions:

If I have a superclass defined in one file, what's the preferred way to
make its definition available in another file at compile-time?  I can
(include ...) the file, but I'm not sure that makes sense.  What if I
need the superclass definition in several files?

On a related note, I have a library that contains several superclasses,
defined in several different files.  If I build this library as a shared
object, I can use (require-for-syntax ...) to pull in the superclass
definitions to any file that subclasses them in a program that uses
the library.  If I build the library statically, I can't do this.  Is
there any way to make superclass definitions from a static library
available?

Thanks,

Ashley
Permalink | Reply | 1 comment |
headers
Ed Watkeys | 2 Aug 2005 23:22

Re: Re: Better algorithm for growing hash tables


On Aug 2, 2005, at 10:50 AM, Nelson Castillo wrote:

> On 8/1/05, Ed Watkeys <edw <at> xmog.com> wrote:
>
>> _The Practice of Programming_ (Kernighan & Pike) deals with a
>> situation analgous to this; they grow storage for a string by powers
>> of two. This works well because it heavily tests the algorithm --
>> from 1 to 2 to 4 to 8... -- but also causes a grow for every log n
>> inserts i.e. rarely.
>>
>
> Yup. But you really should use prime numbers for hash tables.

Is there a paper or book that offers a convincing, empirical argument  
for this? I've read and heard this exhortation before but the  
justification in the presence well designed hash and rehash functions  
has always been "just to be safe."

Ed

--

-- 
Transmogrify, LLC * <http://xmog.com/>
Permalink | Reply | 4 comments |
headers
Dale Jordan | 3 Aug 2005 01:15
Picon
Favicon

Some notes on simple-macros extension

I have found a couple of problems with the simple-macros extension:

- The definitions of "include" and "define-macro" in 
chicken-macros-module.scm need to have their argument changed from 
"form" to "(form)" in line with the change referred to on the srfi-72 
discussion list.

- I found it useful to add "##sys#setslot" to the chicken-internals 
module export list defined in simple-macros.scm.

Michele Simionato reports:
 > ,x does not work in the REPL;

I haven't seen this and have it used it extensively.  (I have the debug 
extension loaded.  I recompiled it for 2.0, but I don't know if this is 
related.)

There are a few things with this macro system I don't yet understand, 
but I have to say that it makes writing macros fun again!  I really like 
it.  Thanks, felix for putting it up so quickly.

Cheerfully.
Dale
Permalink | Reply | 1 comment |
headers
Toby Butzon | 2 Aug 2005 23:09

Re: Re: Better algorithm for growing hash tables

On Tue, Aug 02, 2005 at 05:22:54PM -0400, Ed Watkeys wrote:
> >Yup. But you really should use prime numbers for hash tables.
> 
> Is there a paper or book that offers a convincing, empirical argument  
> for this? I've read and heard this exhortation before but the  
> justification in the presence well designed hash and rehash functions  
> has always been "just to be safe."

Maybe the blurb about it here
    http://www.concentric.net/~Ttwang/tech/primehash.htm
will help. Read the "Expandable Hash Table" section and the first paragraph
of the next section.

--

-- 
Toby Butzon
Permalink | Reply | 1 comment |
headers
Ed Watkeys | 3 Aug 2005 04:49

Re: Re: Better algorithm for growing hash tables


On Aug 2, 2005, at 5:09 PM, Toby Butzon wrote:

> On Tue, Aug 02, 2005 at 05:22:54PM -0400, Ed Watkeys wrote:
>
>>> Yup. But you really should use prime numbers for hash tables.
>>>
>>
>> Is there a paper or book that offers a convincing, empirical argument
>> for this? I've read and heard this exhortation before but the
>> justification in the presence well designed hash and rehash functions
>> has always been "just to be safe."
>>
>
> Maybe the blurb about it here
>     http://www.concentric.net/~Ttwang/tech/primehash.htm
> will help. Read the "Expandable Hash Table" section and the first  
> paragraph
> of the next section.
>

I'll check it out. Thanks.

Ed

--

-- 
Transmogrify, LLC * <http://xmog.com/>
Permalink | Reply | 0 comments |

Gmane