Neil Jerram writes:
>> The problem is,
>> of course, that if you scm_init_guile in some .so,
>> you will accidentally place the entire system into guile
>> mode, and not just the .so, as intended.
>
> Or, to put that another way, the "guile mode"-ness persists on the
> thread that called your lib
2009/1/17 Linas Vepstas :
> 2009/1/16 :
>> Neil Jerram wrote:
>>> scm_init_guile has always been a bit problematic, as it requires lots
>>> of heuristic and OS-dependent code to try to determine where the base
>>> of the stack is. It's never been formally deprecated, but we have
>>> always
2009/1/16 Linas Vepstas :
> I feel obligated to respond, having made all sorts of noise.
>
> 2009/1/15 Neil Jerram :
>
>> whether people think that scm_init_guile is really needed.
>
> kill it. there seem to be perfectly adequate ways of
> living without it. Unfortunately, the current documentatio
Hi Roland...
2009/1/22 Neil Jerram :
> 2009/1/22 Roland Haeder :
>> Here are more to fix:
>>
>> threads.c: In function
>> `block_self':
>> threads.c:231: warning: passing arg 3 of `scm_pthread_cond_timedwait'
>> from incompatible pointer type
>
> There is an apparent mismatch between "const scm_t_
Hi again Carlo,
2008/7/22 carlo.bramix :
> Hello.
>
> Into pthread.h of pthread-win32 package there is this code:
>
> #ifndef HAVE_STRUCT_TIMESPEC
> #define HAVE_STRUCT_TIMESPEC 1
> struct timespec {
>long tv_sec;
>long tv_nsec;
> };
> #endif /* HAVE_STRUCT_TIMESPEC */
>
> When con
