seeds Alex Shinn 08 Oct 2015 05:03 UTC
Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 07:55 UTC
Re: seeds Arthur A. Gleckler 08 Oct 2015 17:46 UTC
Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 19:38 UTC
Re: seeds Arthur A. Gleckler 08 Oct 2015 21:47 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 08:09 UTC
Re: seeds Kevin Wortman 09 Oct 2015 17:18 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 18:33 UTC
Re: seeds Kevin Wortman 13 Oct 2015 17:36 UTC
Re: seeds taylanbayirli@xxxxxx 13 Oct 2015 18:28 UTC
Re: seeds Alex Shinn 14 Oct 2015 01:59 UTC
Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 09:09 UTC
Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 10:06 UTC
Re: seeds Alex Shinn 16 Oct 2015 01:23 UTC
Re: seeds taylanbayirli@xxxxxx 16 Oct 2015 13:34 UTC
Re: seeds Alex Shinn 16 Oct 2015 23:48 UTC
Re: seeds taylanbayirli@xxxxxx 17 Oct 2015 12:08 UTC
Re: seeds Alex Shinn 17 Oct 2015 13:12 UTC
Re: seeds taylanbayirli@xxxxxx 17 Oct 2015 14:09 UTC
What SRFIs are for John Cowan 17 Oct 2015 14:41 UTC
Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 15:56 UTC
Re: What SRFIs are for John Cowan 17 Oct 2015 16:55 UTC
Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 18:08 UTC
Re: What SRFIs are for John Cowan 17 Oct 2015 18:51 UTC
Re: seeds John Cowan 15 Oct 2015 17:49 UTC
Re: seeds Alex Shinn 09 Oct 2015 02:54 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 07:59 UTC
Re: seeds John Cowan 15 Oct 2015 17:51 UTC
Re: seeds taylanbayirli@xxxxxx 15 Oct 2015 23:08 UTC
Re: seeds John Cowan 16 Oct 2015 13:09 UTC
Re: seeds taylanbayirli@xxxxxx 16 Oct 2015 14:01 UTC

Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 19:38 UTC

"Arthur A. Gleckler" <xxxxxx@speechcode.com> writes:

> On Thu, Oct 8, 2015 at 12:55 AM, Taylan Ulrich Bayırlı/Kammer
> <xxxxxx@gmail.com> wrote:
>
>     2. That environment variable is the easiest way to make hash
>     tables deterministic when running a test suite, and a 'getenv'
>     call to get its value and derive a salt from it doesn't seem like
>     a big burden to me.
>
>
> Using an environment variable is bad for a number of reasons:
>
> * It's non-portable to systems that don't support environment
>   variables.
> * It's likely to be slow.
>
> A parameter object seems like a much better way to supply this value.
> Implementations can decide how the default value for that parameter is
> set, and you could even suggest the environment variable, but it
> decouples things better.

The idea is that the value in the environment variable will be read
during initialization of the Scheme process, and a salt value generated
once from it.  So performance should not be an issue.

A Scheme interface is a good idea, but I'm not sure how to define it
most cleanly.

- We want to keep the value opaque, since different implementations
  might accept different ranges of integers.

- What happens when I use the same hashtable inside and outside of a
  (parameterize ((hash-salt ...)) ...)?  Does it crash and burn?

Reading a parameter might also be a bit slower than reading a global C
variable.

I think implementations should just provide a secondary interface of
their choice for platforms that don't have environment variables.  Since
this whole feature is only for running test programs, I don't see it as
harmful if there's some variation in how implementations do things.

Besides, it seems that MS Windows supports environment variables, and
surely all Unixes do.  The systems you have in mind must be rather
obscure then?

Taylan