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:17 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