On Wed 26 Oct 2011 17:38, Vok Vojwo writes:
> On my system current-processor-count returns 2. I use random with the
> same seed: first in normal evaluation order and second in parallel.
> But the two evaluations return the same result. I expected that the
> order of the random numbers differs but
Now that I've replied to your last message, I think I've spotted the bug:
-[ Tue, Oct 25, 2011 at 08:34:23PM +, Whitlock, Bradley D ]
> {
> // Storage for temporary string
> char* s = NULL;
> scm_dynwind_begin (0);
> scm_dynwind_unwind_handler (free, s, SCM_F_WIND_EXPLICITLY);
>
>
> {
> // Storage for temporary string
> char* s = NULL;
>
> scm_dynwind_begin (0);
> s = scm_to_locale_string (scm_val);
>
> fstWriterEmitValueChange(SCM_TO_CTX (scm_ctx),
> SCM_TO_FSTHANDLE (scm_fsthandle),
> s);
> scm_dynwind_free (s
Hm, thanks Andy. I settled on the following solution, no problems:
SCM_DEFINE (libguile_fst_writer_emit_value, "libguile-fst-writer-emit-value",
3,0,0,
(SCM scm_ctx, SCM scm_fsthandle, SCM scm_val),
"Write a change on fstHandle")
{
// Storage for temporary st
On my system current-processor-count returns 2. I use random with the
same seed: first in normal evaluation order and second in parallel.
But the two evaluations return the same result. I expected that the
order of the random numbers differs but it is the same. Why?
This is the example:
(use-modu
On Tue 25 Oct 2011 22:34, "Whitlock, Bradley D"
writes:
> scm_dynwind_unwind_handler (free, s, SCM_F_WIND_EXPLICITLY);
You can write this as scm_dynwind_free (s), FWIW.
Otherwise I didn't see the problem. `s' is not managed by the GC, so
the GC shouldn't have much to do with it.
Regards,
