SCM_BOOL_T became #nil ?

SCM_BOOL_T became #nil ?

[nalaginrut]

hi all.
I found SCM_BOOL_T will convert to #nil in the Guile.
If we write c-function like this:
============================
SCM_DEFINE(scm_my_init, "my-init", 1, 0, 0,
            (SCM flags),
            "Initializes my env.")
#define FUNC_NAME s_scm_my_init
{
    SCM_ASSERT(scm_is_integer(flags), flags, SCM_ARG1, FUNC_NAME);

    if( init_somthing(scm_to_ulong(flags)) == -1 )
        return SCM_BOOL_F;
    else	
        return SCM_BOOL_T;

}
#undef FUNC_NAME

=============================
If init_something success, return true, else false.

And I call this "my-init" function in the Guile:
---------------------------
(if (not (my-init flags))
  (error "init failed!")
  (format #f "init ok!~%")
)
---------------------------

The problem is SCM_BOOL_T convert to #nil, and (not #nil)==>#t ! So I
can't get a logical result.

Is this conversion accepted? Or I made some mistakes?
Any help would be appreciated! Thanks!



-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

Re: SCM_BOOL_T became #nil ?

[Andy Wingo]

On Tue 22 Feb 2011 07:09, nalaginrut <nalaginrut@gmail.com> writes:

> The problem is SCM_BOOL_T convert to #nil, and (not #nil)==>#t ! So I
> can't get a logical result.

I believe this indicates that you compiled this extension against
headers from 1.8 or earlier.  Not sure how you managed that :)  Please
paste in your compilation line, and all locations of libguile.h on your
system.

Also in the future, bug-guile is a more appropriate list.

Regards,

Andy
-- 
http://wingolog.org/

Re: SCM_BOOL_T became #nil ?

[Mark H Weaver]

nalaginrut <nalaginrut@gmail.com> writes:
> I found SCM_BOOL_T will convert to #nil in the Guile.

You must be including the C headers from Guile 1.8, but linking to
libguile from Guile 2.0.

     Mark


> If we write c-function like this:
> ============================
> SCM_DEFINE(scm_my_init, "my-init", 1, 0, 0,
>             (SCM flags),
>             "Initializes my env.")
> #define FUNC_NAME s_scm_my_init
> {
>     SCM_ASSERT(scm_is_integer(flags), flags, SCM_ARG1, FUNC_NAME);
>
>     if( init_somthing(scm_to_ulong(flags)) == -1 )
>         return SCM_BOOL_F;
>     else	
>         return SCM_BOOL_T;
>
> }
> #undef FUNC_NAME
>
> =============================
> If init_something success, return true, else false.
>
> And I call this "my-init" function in the Guile:
> ---------------------------
> (if (not (my-init flags))
>   (error "init failed!")
>   (format #f "init ok!~%")
> )
> ---------------------------
>
> The problem is SCM_BOOL_T convert to #nil, and (not #nil)==>#t ! So I
> can't get a logical result.
>
> Is this conversion accepted? Or I made some mistakes?
> Any help would be appreciated! Thanks!

Re: SCM_BOOL_T became #nil ?

[Hans Aberg]

On 22 Feb 2011, at 09:11, Andy Wingo wrote:

>> The problem is SCM_BOOL_T convert to #nil, and (not #nil)==>#t ! So I
>> can't get a logical result.
> 
> I believe this indicates that you compiled this extension against
> headers from 1.8 or earlier.  Not sure how you managed that :)

I noticed that that is possible - in fact, to make sure to get it right, I removed all Guile headers in /usr/local/include/ and reinstalled guile-2.0.

The Guile 1.8 header libguile.h is in /usr/local/include/, but the one from 2.0 is in /usr/local/include/guile/2.0/. Both directories are included when compiling. So if the include order is wrong, or the from 2.0 is somehow excluded, you may get the wrong one, and it may in fact compile.

Perhaps 2.0 should have some check that it gets the right header.

Re: SCM_BOOL_T became #nil ?

[nalaginrut]

> On 22 Feb 2011, at 09:11, Andy Wingo wrote:
> 
> >> The problem is SCM_BOOL_T convert to #nil, and (not #nil)==>#t ! So I
> >> can't get a logical result.
> > 
> > I believe this indicates that you compiled this extension against
> > headers from 1.8 or earlier.  Not sure how you managed that :)
> 
> I noticed that that is possible - in fact, to make sure to get it right, I removed all Guile headers in /usr/local/include/ and reinstalled guile-2.0.
> 
> The Guile 1.8 header libguile.h is in /usr/local/include/, but the one from 2.0 is in /usr/local/include/guile/2.0/. Both directories are included when compiling. So if the include order is wrong, or the from 2.0 is somehow excluded, you may get the wrong one, and it may in fact compile.
> 
> Perhaps 2.0 should have some check that it gets the right header.
> 
> 

Well~I modified the include path and it's done.
Thanks all!


-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

Re: SCM_BOOL_T became #nil ?

[Hans Aberg]

On 22 Feb 2011, at 12:44, nalaginrut wrote:

>>>> The problem is SCM_BOOL_T convert to #nil, and (not #nil)==>#t ! So I
>>>> can't get a logical result.
>>> 
>>> I believe this indicates that you compiled this extension against
>>> headers from 1.8 or earlier.  Not sure how you managed that :)
>> 
>> I noticed that that is possible - in fact, to make sure to get it right, I removed all Guile headers in /usr/local/include/ and reinstalled guile-2.0.
>> 
>> The Guile 1.8 header libguile.h is in /usr/local/include/, but the one from 2.0 is in /usr/local/include/guile/2.0/. Both directories are included when compiling. So if the include order is wrong, or the from 2.0 is somehow excluded, you may get the wrong one, and it may in fact compile.
>> 
>> Perhaps 2.0 should have some check that it gets the right header.
> 
> Well~I modified the include path and it's done.
> Thanks all!

If you use `guile-config compile` (and `guile-config link`) in your Makefile it will come out right.

Re: SCM_BOOL_T became #nil ?

[Ken Raeburn]

On Feb 22, 2011, at 07:00, Hans Aberg wrote:
[quoting others...]
>>> I noticed that that is possible - in fact, to make sure to get it right, I removed all Guile headers in /usr/local/include/ and reinstalled guile-2.0.
>>> 
>>> The Guile 1.8 header libguile.h is in /usr/local/include/, but the one from 2.0 is in /usr/local/include/guile/2.0/. Both directories are included when compiling. So if the include order is wrong, or the from 2.0 is somehow excluded, you may get the wrong one, and it may in fact compile.
>>> 
>>> Perhaps 2.0 should have some check that it gets the right header.

It wouldn't be that tough to do something like:

  #define scm_init_guile  scm_init_guile_v2_0 // encode version in symbol

or

  #define scm_init_guile scm_init_guile_with_version_check(0x0200) // one byte each major/minor vers

and tell people to use the macro.  Ugly, maybe, but not tough. :-)

>> 
>> Well~I modified the include path and it's done.
>> Thanks all!
> 
> If you use `guile-config compile` (and `guile-config link`) in your Makefile it will come out right.

Unless you're also using some other "foo-config" script for the same object file (defining Guile wrappers for the Foo API?), and that one is installed in /usr/local where the old version of Guile is, you don't get the command-line order right for your specific installation quirks, etc.

I don't think there is a good answer to guarantee consistent versions; some additional technique to check for consistency doesn't seem like a horrible idea, though most packages I've worked with just seem to make do with the assumption that you'll figure out how to get this right if you're installing multiple versions.

Ken

Re: SCM_BOOL_T became #nil -- et al. ?

[Bruce Korb]

On 02/22/11 20:15, Ken Raeburn wrote:
> On Feb 22, 2011, at 07:00, Hans Aberg wrote:
>>>> Perhaps 2.0 should have some check that it gets the right header.
> 
> It wouldn't be that tough to do something like:
>   #define scm_init_guile  scm_init_guile_v2_0 // encode version in symbol
[...]
> and tell people to use the macro.  Ugly, maybe, but not tough. :-)
> 
>> If you use `guile-config compile` (and `guile-config link`)
>> in your Makefile it will come out right.
> 
> Unless you're also using some other "foo-config" script.....


Fail early and fail hard.  Please find a way to fail a test
program, once "configure" has arranged the -I list.

Also:

* guile should provide autoconf macros to do checking,
  like for wrong version headers.
* Developers should be clearly warned that -I/usr/local/include
  needs to be after all other -I options, due to guile
  header naming conflicts.
* I have to vary various interfaces because of the
  obsolescence that happens from release to release.
  Consistency would be really nice:

    There should be a macro that has the value 0x200000 or
    some such that includes the revision number, too.
    "scm_init_guile_with_version_check" would just ignore
    the last 12 bits (or divide by 1000, whatever works...)

  I have to if-def code due to the interface migration.
  BSD has moved on to 1.6, so I expect they won't be going
  to 2.0 any time soon.

Speaking of moving interfaces, since this call:
   scm_list_1(SCM_EOL);
yields a value that gets garbage collected and since it is
equivalent to the accidentally removed scm_listofnull,
I am interested in a stable "do it this way" equivalent.

>> > By replacing "scm_listofnull" with "ag_scm_listofnull" and initializing it:
>> >    SCM ag_scm_listofnull =  scm_list_1 (SCM_EOL);
> In Guile < 1.9.3, you have to scm_gc_protect_object this value
> (info "(guile) Garbage Collection Functions").

and it sounds like scm_gc_protect_object(ag_scm_listofnull) won't
work in 2.0.  Would you-all please put scm_listofnull back?
Thank you.  Regards, Bruce

P.S. the listofnull piece of my guile interface glue now looks like this:

> #if   GUILE_VERSION < 107000
> [.....]
> # define AG_SCM_LISTOFNULL()          scm_listofnull
> 
> #elif GUILE_VERSION < 108000
> [.....]
> # define AG_SCM_LISTOFNULL()          scm_listofnull
> 
> #elif GUILE_VERSION < 109000
> [.....]
> # define AG_SCM_LISTOFNULL()          scm_listofnull
> 
> #elif GUILE_VERSION < 201000
> [.....]
> # define AG_SCM_LISTOFNULL()          scm_list_1(SCM_EOL)
> 
> # define scm_sizet                    size_t
> 
> #else
> #error unknown GUILE_VERSION
> #endif

and I use AG_SCM_LISTOFNULL() instead of scm_listofnull.
Does this look right?

scm_listofnull

[Ludovic Courtès]

Hi,

Bruce Korb <bkorb@gnu.org> writes:

>>> > By replacing "scm_listofnull" with "ag_scm_listofnull" and initializing it:
>>> >    SCM ag_scm_listofnull =  scm_list_1 (SCM_EOL);
>> In Guile < 1.9.3, you have to scm_gc_protect_object this value
>> (info "(guile) Garbage Collection Functions").
>
> and it sounds like scm_gc_protect_object(ag_scm_listofnull) won't
> work in 2.0.

It will.

> Would you-all please put scm_listofnull back?

I’d rather avoid it, since it’s so trivially worked around, and it was
never documented.

So, just use code like below, unconditionally:

  SCM ag_listofnulls;

  ...

    ag_listofnulls = scm_gc_protect_object (scm_list_1 (SCM_EOL));

It will work for 1.6 to 2.0, at least.

Thanks,
Ludo’.

Re: SCM_BOOL_T became #nil -- et al. ?

[Ken Raeburn]

On Feb 23, 2011, at 15:14, Bruce Korb wrote:
> * guile should provide autoconf macros to do checking,
>  like for wrong version headers.

That seems like a good idea, but unless all the other packages' header directories have already been added to the include path by the time this test is run, it's not foolproof.  And of course another package would be in exactly the same boat -- if Guile's check comes last, the Foo package can't be sure that adding Guile's header directory (if we add them at the front -- but even if we add them at the tail, they'll come before /usr/include) isn't going to break things.

If the library ABI is tweaked to code the version into a symbol name, this test could become a simple compile-and-link test.  Of course, that approach has other issues, like getting backwards-compatible library upgrades to work without recompiling applications.



I vaguely remember reading an argument years back for including individual headers by pathname, rather than building up potentially long lists of directories and then searching all of them for each header.  So "--with-foo-dir=/x/y/z" means you should include "/x/y/z/include/foo.h", not "foo.h" with "-I/x/y/z/include" given to the compiler and a prayer offered up that you don't have a foo.h installed anywhere else.  I didn't spend much time thinking about pros and cons of such an approach.  It sounds like it would address this one problem fairly nicely, but I suspect other new problems would come up.

> * Developers should be clearly warned that -I/usr/local/include
>  needs to be after all other -I options, due to guile
>  header naming conflicts.

Again, this problem isn't unique to Guile -- and we can't put *all* packages' -I options first; somebody's gotta go second/third/.../last.

> * I have to vary various interfaces because of the
>  obsolescence that happens from release to release.
>  Consistency would be really nice:
> 
>    There should be a macro that has the value 0x200000 or
>    some such that includes the revision number, too.
>    "scm_init_guile_with_version_check" would just ignore
>    the last 12 bits (or divide by 1000, whatever works...)

I've seen this approach used elsewhere, and it seems like a good idea.  Configure-time feature tests are great and all, but some features are subtle to test for, and some packages don't use configure scripts that can do feature tests.  OpenSSL even encodes an extra digit for development version vs beta or release; I'm not sure if we need to go that far.

Ken

Re: SCM_BOOL_T became #nil -- et al. ?

[Bruce Korb]

On 02/24/11 08:35, Ken Raeburn wrote:
> On Feb 23, 2011, at 15:14, Bruce Korb wrote:
>> * guile should provide autoconf macros to do checking,
>>  like for wrong version headers.
> 
> That seems like a good idea, but unless all the other packages'
> header directories have already been added to the include path
....
> If the library ABI is tweaked to code the version into a symbol
> name, this test could become a simple compile-and-link test.

Exactly.

> Of course, that approach has other issues, like getting
> backwards-compatible library upgrades to work without recompiling
> applications.

The .so simply includes the versioned interfaces it supports.
They are simply not declared in the current interface.

> I vaguely remember reading an argument years back for including
> individual headers by pathname, rather than building up

The problem is naming conflicts.  The standard way to avoid
this is by including some directory information in the include
name.  e.g.  <libguile/guile.h> instead of <libguile.h>.
If someone really wants to ensure 2.0 vs. 1.8, then you can
put versioned subdirectories under /usr/include/libguile and
add a symlink farm to redirect requests to the current version.
But we're here now and I am saying that a mechanism needs to
be put into place whereby there is a hard build time failure
when /usr/include/libguile.h gets pulled in ahead of the
versioned header.  How precisely that is done is an exercise
for the Guile maintainers.  I'd make suggestions, but I have
to presume that you-all are inventive people, too.

>> * Developers should be clearly warned that -I/usr/local/include
>>  needs to be after all other -I options, due to guile
>>  header naming conflicts.
> 
> Again, this problem isn't unique to Guile

No, it is one of those "commonly known" things that isn't
particularly commonly known.  It would be a jog to people's
memories in an attempt to help make it actually commonly known.
(: Suggested here mainly because Guile introduces such a conflict. :)

>> * I have to vary various interfaces because of the
>>  obsolescence that happens from release to release.
>>  Consistency would be really nice:
>>
>>    There should be a macro that has the value 0x200000 or
>>    some such that includes the revision number, too.
>>    "scm_init_guile_with_version_check" would just ignore
>>    the last 12 bits (or divide by 1000, whatever works...)
> 
> I've seen this approach used elsewhere, and it seems like a
> good idea.  Configure-time feature tests are great and all,
> but some features are subtle to test for, and some packages
> don't use configure scripts that can do feature tests.
> OpenSSL even encodes an extra digit for development version
> vs beta or release; I'm not sure if we need to go that far.

If you promise to never, ever make any change that makes any
client adjust code in any way, then the micro version can be
left off.  OTOH, adding in a few more bits just in case you
have to is pretty cheap ....

Besides, people are already doing it, this would just put the
practice into the Guile header instead of my config.h header.

Re: SCM_BOOL_T became #nil -- et al. ?

[Andy Wingo]

On Wed 23 Feb 2011 21:14, Bruce Korb <bkorb@gnu.org> writes:

> * Developers should be clearly warned that -I/usr/local/include
>   needs to be after all other -I options, due to guile
>   header naming conflicts.

This is incorrect.  Guile 2.0 (and later) does not add
-I/usr/local/include to the CFLAGS in any configuration.  If you install
to /usr/local, it adds -I/usr/local/include/guile/2.0, or /2.2, etc.

The problem this thread is about is if you have Guile 1.8 or previous
eheaders installed in /usr.

Andy
-- 
http://wingolog.org/

Re: SCM_BOOL_T became #nil -- et al. ?

[Andy Wingo]

On Thu 24 Feb 2011 17:35, Ken Raeburn <raeburn@raeburn.org> writes:

> If the library ABI is tweaked to code the version into a symbol name,
> this test could become a simple compile-and-link test.  Of course, that
> approach has other issues, like getting backwards-compatible library
> upgrades to work without recompiling applications.

FWIW, Guile 2.0's library is "libguile-2.0.so".  2.2 will be "-2.2.so".
Most problems of this nature will be avoided in this way.

Regards,

Andy
-- 
http://wingolog.org/

Re: SCM_BOOL_T became #nil -- et al. ?

[Hans Aberg]

On 25 Feb 2011, at 12:07, Andy Wingo wrote:

>> * Developers should be clearly warned that -I/usr/local/include
>>  needs to be after all other -I options, due to guile
>>  header naming conflicts.
> 
> This is incorrect.  Guile 2.0 (and later) does not add
> -I/usr/local/include to the CFLAGS in any configuration.  If you install
> to /usr/local, it adds -I/usr/local/include/guile/2.0, or /2.2, etc.

I get:
  $ guile-config compile
  -D_THREAD_SAFE -I/usr/local/include/guile/2.0 -I/usr/local/include  

> The problem this thread is about is if you have Guile 1.8 or previous
> eheaders installed in /usr.

The directory /usr/local/include/ is added by the compiler. So possibly, if one has the 1.8 header, it will be included even when using `guile-config compile`.

Re: SCM_BOOL_T became #nil -- et al. ?

[Andy Wingo]

On Fri 25 Feb 2011 12:46, Hans Aberg <haberg-1@telia.com> writes:

>   $ guile-config compile
>   -D_THREAD_SAFE -I/usr/local/include/guile/2.0 -I/usr/local/include  

The -I/usr/local/include is added for some other library that Guile
depends on -- GMP or libgc or something else.

For example on my system I have Guile installed into /opt/guile, and
libgc and everything else in /usr, and I get:

  $ guile-config compile
  -pthread -I/opt/guile/include/guile/2.0  

>> The problem this thread is about is if you have Guile 1.8 or previous
>> eheaders installed in /usr.
>
> The directory /usr/local/include/ is added by the compiler. So
> possibly, if one has the 1.8 header, it will be included even when
> using `guile-config compile`.

Depends on your system, I think.  But yes, this is a danger.  Hopefully
it won't be as "dangerous" when we live in a 2.0+-only world.  I have
been meaning to write an article or FAQ about /usr/local, and this is a
good point.

Cheers,

Andy
-- 
http://wingolog.org/

Re: SCM_BOOL_T became #nil -- et al. ?

[Hans Aberg]

On 25 Feb 2011, at 13:42, Andy Wingo wrote:

>>  $ guile-config compile
>>  -D_THREAD_SAFE -I/usr/local/include/guile/2.0 -I/usr/local/include  
> 
> The -I/usr/local/include is added for some other library that Guile
> depends on -- GMP or libgc or something else.
> 
> For example on my system I have Guile installed into /opt/guile, and
> libgc and everything else in /usr, and I get:
> 
>  $ guile-config compile
>  -pthread -I/opt/guile/include/guile/2.0  

I do not know why it is added.

>>> The problem this thread is about is if you have Guile 1.8 or previous
>>> eheaders installed in /usr.
>> 
>> The directory /usr/local/include/ is added by the compiler. So
>> possibly, if one has the 1.8 header, it will be included even when
>> using `guile-config compile`.
> 
> Depends on your system, I think.  

But I checked that it is not needed for reading the gmp.h header which is in /usr/local/include/.

The funny thing is that it is the Apple tweaked GCC and /usr/local/ is not added when installing the system or (I think) the developer package.

> But yes, this is a danger.  Hopefully
> it won't be as "dangerous" when we live in a 2.0+-only world.  I have
> been meaning to write an article or FAQ about /usr/local, and this is a
> good point.

It might be viewed as a problem with 'make install' which does not remove the header from 1.8. I'm not sure if it is possible to have that and 2.0 both installed. At least the manual is overwritten.