Re: jitc_finish_eframex

> * Yaroslav Kavenchuk <xnirapuhx <at> ghg.ol> [2008-05-31 12:25:07 +0300]:
>
> Sam Steingold wrote:
>> when HAVE__JMP is not defined, we do not #define setjmp and longjmp to
>> _setjmp and _longjmp, respectively, and use the system-provided setjmp &
>> longjmp as is.
>
> We must redefine setjmp but not redefine longjmp. Included patch does it.
>
> -- 
> WBR, Yaroslav Kavenchuk.
>
> --- src/lispbibl.d.orig	2008-05-26 22:22:01 +0300
> +++ src/lispbibl.d	2008-05-31 11:49:03 +0300
>  <at>  <at>  -1377,6 +1377,10  <at>  <at> 
>  
>  /* non-local exits */
>  #include <setjmp.h>
> +#if defined(__MINGW32__) && !defined(HAVE__JMP)
> +  #undef setjmp
> +  #define setjmp  _setjmp
> +#endif
>  #if (defined(UNIX) || defined(__MINGW32__)) && defined(HAVE__JMP)
>    /* The "_" routines are more efficient (do not save/restore signal masks,
>     see http://article.gmane.org/gmane.lisp.clisp.devel/18227 or

why?
I think we should be using _matching_ versions - i.e., either setjmp &
longjmp or _setjmp & _longjmp.

Re: obsolete autoconf macros: CL_CLOSEDIR & cygwin

> * Bruno Haible <oehab <at> pyvfc.bet> [2008-05-31 14:43:20 +0200]:
>
> CL_CLOSEDIR can at least be simplified. I think it's probable that the
> mentioned Cygwin bug is not relevant nowadays any more, but I'm not sure.
>
> !   # The following test is necessary, because Cygwin32 declares closedir()
> !   # as returning int but the return value is unusable.
> !   AC_CACHE_CHECK(for usable closedir return value, cl_cv_func_closedir_retval,[

Reini, could you please check that this is no longer applicable?
Thanks.

--

-- 
Sam Steingold (http://sds.podval.org/) on Fedora release 8 (Werewolf)
http://camera.org http://memri.org http://iris.org.il
http://israelunderattack.slide.com http://pmw.org.il http://dhimmi.com
If a cat tells you that you lost your mind, then it is so.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

clisp-cvs Digest, Vol 25, Issue 69

Send clisp-cvs mailing list submissions to
	clisp-cvs <at> lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	clisp-cvs-request <at> lists.sourceforge.net

You can reach the person managing the list at
	clisp-cvs-owner <at> lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."

CLISP CVS commits for today

Today's Topics:

   1. clisp/modules/zlib config.h.in,1.4,1.5 configure,1.17,1.18
      (Bruno Haible)
   2. clisp/modules/syscalls config.h.in,1.56,1.57
      configure,1.68,1.69 (Bruno Haible)
   3. clisp/modules/wildcard config.h.in,1.13,1.14
      configure,1.29,1.30 (Bruno Haible)
   4. clisp/src encoding.d,1.147,1.148 ChangeLog,1.6264,1.6265
      (Bruno Haible)
   5. clisp/src encoding.d,1.148,1.149 ChangeLog,1.6265,1.6266
      (Bruno Haible)
   6. clisp/src ChangeLog,1.6266,1.6267 constsym.d,1.365,1.366
      (Bruno Haible)

Re: clisp/src/malloc gmalloc.c,1.3,1.4

> * Bruno Haible <unvoyr <at> hfref.fbheprsbetr.arg> [2008-05-31 11:35:55 +0000]:
>
> Update of /cvsroot/clisp/clisp/src/malloc
> In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv27727/src/malloc
>
> Modified Files:
> 	gmalloc.c 
> Log Message:
> Assume ANSI C headers.
>

this is not our file - we took it from emacs.
are you sure it is a good idea to modify it ourselves instead or syncing
with emacs (or gnulib or glibc or whatever)?

--

-- 
Sam Steingold (http://sds.podval.org/) on Fedora release 8 (Werewolf)
http://iris.org.il http://pmw.org.il http://memri.org http://truepeace.org
http://camera.org http://mideasttruth.com http://israelunderattack.slide.com
History doesn't repeat itself, but historians do repeat each other.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: obsolete autoconf macros: CL_CLOSEDIR & cygwin

2008/6/1 Sam Steingold <sds <at> gnu.org>:
>> * Bruno Haible <oehab <at> pyvfc.bet> [2008-05-31 14:43:20 +0200]:
>>
>> CL_CLOSEDIR can at least be simplified. I think it's probable that the
>> mentioned Cygwin bug is not relevant nowadays any more, but I'm not sure.
>>
>> !   # The following test is necessary, because Cygwin32 declares closedir()
>> !   # as returning int but the return value is unusable.
>> !   AC_CACHE_CHECK(for usable closedir return value, cl_cv_func_closedir_retval,[
>
> Reini, could you please check that this is no longer applicable?
> Thanks.

clisp-cvs + cygwin 1.5.25 (both current)
checking for usable closedir return value... yes

configure:42200: checking for usable closedir return value
configure:42232: gcc -o conftest.exe -pipe   conftest.c -lavcall -lcallback >&5
configure:42236: $? = 0
configure:42242: ./conftest.exe
configure:42246: $? = 0
configure:42263: result: yes

I don't know when this was fixed. I only have yes in my old config logs
from 2.41 on, and lost all my previous build dirs.

[BTW: rurban <at> inode.at is no longer valid, clisp-devel is enough]
--

-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

cygwin syscalls precision problems

The new syscalls functions cause 13 tests to fail.
The cygwin libs (newlib) obviously deviates from the glibc.
This should be fixed for other platforms using newlib also, when they
appear in the future on some embedded systems.

Interesting is only the deviation of (+ (ERF -1) (ERFC -1), which I'll
report upstream.
The rest is arguable.
Attached patch fixes the test.

Form: (ERFC -1)
CORRECT: 1.842700792949715d0
CLISP  : 1.8427007929497148d0

Form: (ERFC 3)
CORRECT: 2.2090496998585438d-5
CLISP  : 2.209049699858544d-5

Form: (ERFC 5)
CORRECT: 1.5374597944280351d-12
CLISP  : 1.537459794428035d-12

Form: (ERFC 20)
CORRECT: 5.3958656116079005d-176
CLISP  : 5.395865611607901d-176

Form: (ERFC 22)
CORRECT: 1.6219058609334724d-212
CLISP  : 1.6219058609334726d-212

Re: jitc_finish_eframex

Sam Steingold wrote:
> why?
> I think we should be using _matching_ versions - i.e., either setjmp &
> longjmp or _setjmp & _longjmp.

I already wrote about it: on mingw in <setjmp.h> setjmp defined as

 > _CRTIMP int __cdecl __MINGW_NOTHROW _setjmp (jmp_buf);

 > #define	setjmp(x)	_setjmp(x)

and need to redefine it, but longjmp define as

 > _CRTIMP void __cdecl __MINGW_NOTHROW longjmp (jmp_buf, int) 
__MINGW_ATTRIB_NORETURN;

and not need to redefine it.

--

-- 
WBR, Yaroslav Kavenchuk.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: cygwin syscalls precision problems

2008/6/1 Reini Urban <rurban <at> x-ray.at>:
> The new syscalls functions cause 13 tests to fail.
> The cygwin libs (newlib) obviously deviates from the glibc.
> This should be fixed for other platforms using newlib also, when they
> appear in the future on some embedded systems.

Oops, I forgot to fix one wrong value in (y0 1.0)
Please use the new patch attached.
--

-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel

Re: jitc_finish_eframex

> * Yaroslav Kavenchuk <xnirapuhx <at> ghg.ol> [2008-06-01 12:06:22 +0300]:
>
> Sam Steingold wrote:
>> why?
>> I think we should be using _matching_ versions - i.e., either setjmp &
>> longjmp or _setjmp & _longjmp.
>
> I already wrote about it: on mingw in <setjmp.h> setjmp defined as
>
>  > _CRTIMP int __cdecl __MINGW_NOTHROW _setjmp (jmp_buf);
>
>  > #define	setjmp(x)	_setjmp(x)
>
> and need to redefine it, but longjmp define as

it is already defined as _setjmp, why should we redefine it?
the only situation where this would matter is if we were using setjmp
without an argument, which we do not.

--

-- 
Sam Steingold (http://sds.podval.org/) on Fedora release 8 (Werewolf)
http://palestinefacts.org http://truepeace.org http://thereligionofpeace.com
http://pmw.org.il http://jihadwatch.org http://mideasttruth.com
If your VCR is still blinking 12:00, you don't want Linux.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: obsolete autoconf macros: CL_CLOSEDIR & cygwin

> * Reini Urban <eheona <at> k-enl.ng> [2008-06-01 09:44:25 +0200]:
>
> 2008/6/1 Sam Steingold <sds <at> gnu.org>:
>>> * Bruno Haible <oehab <at> pyvfc.bet> [2008-05-31 14:43:20 +0200]:
>>>
>>> CL_CLOSEDIR can at least be simplified. I think it's probable that the
>>> mentioned Cygwin bug is not relevant nowadays any more, but I'm not sure.
>>>
>>> !   # The following test is necessary, because Cygwin32 declares closedir()
>>> !   # as returning int but the return value is unusable.
>>> !   AC_CACHE_CHECK(for usable closedir return value, cl_cv_func_closedir_retval,[
>>
>> Reini, could you please check that this is no longer applicable?
>
> clisp-cvs + cygwin 1.5.25 (both current)
> checking for usable closedir return value... yes
>
> configure:42200: checking for usable closedir return value
> configure:42232: gcc -o conftest.exe -pipe   conftest.c -lavcall -lcallback >&5
> configure:42236: $? = 0
> configure:42242: ./conftest.exe
> configure:42246: $? = 0
> configure:42263: result: yes

thanks!

--

-- 
Sam Steingold (http://sds.podval.org/) on Fedora release 8 (Werewolf)
http://jihadwatch.org http://memri.org http://palestinefacts.org
http://pmw.org.il http://honestreporting.com http://dhimmi.com