Eval options macro: backward compatibility?

Eval options macro: backward compatibility?

[Han-Wen Nienhuys]

Hello,

what is the status of the eval options structure wrt binary compatibility?

Right now, it says

 scm_t_option scm_evaluator_trap_table[] = {
  { SCM_OPTION_BOOLEAN, "traps", 0, "Enable evaluator traps." },
  { SCM_OPTION_BOOLEAN, "enter-frame", 0, "Trap when eval enters new frame." },
  { SCM_OPTION_BOOLEAN, "apply-frame", 0, "Trap when entering apply." },
  { SCM_OPTION_BOOLEAN, "exit-frame", 0, "Trap when exiting eval or apply." },
  { SCM_OPTION_SCM, "enter-frame-handler", (unsigned long)SCM_BOOL_F, "Handler for enter-frame traps." },
  { SCM_OPTION_SCM, "apply-frame-handler", (unsigned long)SCM_BOOL_F, "Handler for apply-frame traps." },
  { SCM_OPTION_SCM, "exit-frame-handler", (unsigned long)SCM_BOOL_F, "Handler for exit-frame traps." }
};


this order is awkward when a new trap option has to be added.

The problematic thing is that this is exported to GUILE users, through

  #define SCM_ENTER_FRAME_P      scm_evaluator_trap_table[1].val

in eval.h

I would like to change this order, and if possible move this out of
the global namespace.  Are there any objections? It would break binary
compatibility with apps that inspect options by looking at
scm_evaluator_trap_table directly, but I believe those are broken
anyway.


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Eval options macro: backward compatibility?

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> this order is awkward when a new trap option has to be added.
>
> The problematic thing is that this is exported to GUILE users, through
>
>   #define SCM_ENTER_FRAME_P      scm_evaluator_trap_table[1].val
>
> in eval.h
>
> I would like to change this order, and if possible move this out of
> the global namespace.  Are there any objections?

It's ok for 1.9 to break binary compatibility, and it's also probably a
good thing to not export things that are not documented.  So I think
SCM_EVALUATOR_TRAP_TABLE could either be made `static' or renamed to
SCM_I_..., and `SCM_ENTER_FRAME_P' could certainly be moved in `eval.c'
if it's not needed elsewhere.

Thanks,
Ludovic.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Eval options macro: backward compatibility?

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
> Hi,
> 
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
> 
>> this order is awkward when a new trap option has to be added.
>>
>> The problematic thing is that this is exported to GUILE users, through
>>
>>   #define SCM_ENTER_FRAME_P      scm_evaluator_trap_table[1].val
>>
>> in eval.h
>>
>> I would like to change this order, and if possible move this out of
>> the global namespace.  Are there any objections?
> 
> It's ok for 1.9 to break binary compatibility, and it's also probably a
> good thing to not export things that are not documented.  So I think

does this also mean that we can (finally!) summarily throw away anything 
that is marked as "deprecated GUILE 1.7" ? 

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Eval options macro: backward compatibility?

[Kevin Ryde]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> does this also mean that we can (finally!) summarily throw away anything 
> that is marked as "deprecated GUILE 1.7" ? 

The short answer would be no, much too soon.  The whole idea of
discouraged etc is really bad.  Forcing everyone to change their
programs is terrible.  Unless an interface is utterly hopeless the
best thing is to leave it alone.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

deprecated features

[Han-Wen Nienhuys]

Kevin Ryde escreveu:
>> does this also mean that we can (finally!) summarily throw away anything 
>> that is marked as "deprecated GUILE 1.7" ? 
> 
> The short answer would be no, much too soon.  The whole idea of

If not now, is there any sort of timescale for when this is scheduled? 

I think it is reasonable to let deprecated interfaces live for one stable 
release, to allow people to update broken programs, and remove them after
that.

Marius?

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Kevin Ryde]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> If not now, is there any sort of timescale for when this is scheduled? 

Hopefully never for many bits.  I think several things have been
tagged unnecessarily.

If something is not very nice, then by all means shunt it off to a
corner of the manual and advertise the good way.  But taking stuff out
is bad.

> I think it is reasonable to let deprecated interfaces live for one stable 
> release,

You yourself have complained about things changed and removed, no?
SCM_STRING_CHARS perhaps ... :-)

One stable is much too short.  Surely it's not reasonable to expect
everyone to review all their programs on every stable release.

> to allow people to update broken programs, and remove them after
> that.

My point is that many bits in question aren't and weren't broken.  Not
too nice, sure, but not utterly hopeless.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Han-Wen Nienhuys]

Kevin Ryde escreveu:
>> I think it is reasonable to let deprecated interfaces live for one stable 
>> release,
> 
> You yourself have complained about things changed and removed, no?
> SCM_STRING_CHARS perhaps ... :-)

Perhaps, but I'm for cleaner code. Having to keep deprecated stuff
around (and worse: having to write various deprecation wrappers for
them) is detrimental to code quality.

If the consensus is that removing deprecated features will not ever be
done, then there is little point in marking routines as such, and
writing wrappers to signal their use. We could clean up GUILE by
throwing away all the bookkeeping.

> One stable is much too short.  Surely it's not reasonable to expect
> everyone to review all their programs on every stable release.

I tend to disagree.

At the current release rate of GUILE, I'd expect anyone using GUILE
seriously to run the CVS version.  I do, at least. 

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Bruce Korb]

Han-Wen Nienhuys wrote:

> I tend to disagree.
> 
> At the current release rate of GUILE, I'd expect anyone using GUILE
> seriously to run the CVS version.  I do, at least. 

The last time I looked, you could find the 1.4 series being released
with some BSD distributions.  That means my stuff has to run against
all versions 1.4.x through 1.8.x.  It might be easier to obsolete
the 1.4 interfaces if it were not still shipping.

By the way, have you all given any consideration to releasing a
valgrind config file that would clean out valgrind chaff?
I recently needed to do a valgrind run and it was quite painful.
Thanks - Bruce


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Han-Wen Nienhuys]

Bruce Korb escreveu:
> By the way, have you all given any consideration to releasing a
> valgrind config file that would clean out valgrind chaff?
> I recently needed to do a valgrind run and it was quite painful.

I always use the file below.  I am not sure what the best way to
distribute it would be.


# guile valgrind suppression file
{
    	guilegc
	Memcheck:Value4
    	fun:scm_c_hook_run
}
{
    	guilegc
	Memcheck:Cond
    	fun:scm_c_hook_run
}

{
    guilegc
	Memcheck:Value4
    fun:scm_gc_mark_dependencies
}

{
    guilegc
	Memcheck:Cond
    fun:scan_weak_hashtables
}

{
	guilegc
 	Memcheck:Cond
	fun:scm_i_mark_weak_vectors_non_weaks
}

{
	guilegc
	Memcheck:Value4
 	fun:scm_i_symbol_mark
}
{
	guilegc
	Memcheck:Value4
	fun:scm_markstream
}

{
	guilegc
	Memcheck:Value4
 	fun:scm_i_string_mark
}
{
    guilegc
	Memcheck:Cond
    fun:scm_gc_mark_dependencies
}

{
    guilegc
    Memcheck:Cond
    fun:scm_i_scan_weak_hashtables
}

{
    guilegc
    Memcheck:Cond
    fun:scm_i_remove_weaks_from_weak_vectors
}

{
    guilegc
    Memcheck:Cond
    fun:scan_dynamic_states_and_fluids
		}

{

    guilegc	    
	Memcheck:Value4
    fun:scm_gc_mark
}
{

    guilegc	    
	Memcheck:Value4
    fun:scm_gc_mark
}

{
guilegc
Memcheck:Value4
fun:scm_i_find_heap_segment_containing_object
}

{
guilegc
Memcheck:Cond
fun:scm_i_find_heap_segment_containing_object
}

{
guilegc
Memcheck:Value4
fun:scm_markcdr
}

{
	guilegc
	Memcheck:Value4
	fun:scm_mark_locations	
}

{
	guilegc4327
   Memcheck:Cond
   obj:/usr/lib/libguile.so.12.3.0
   fun:scm_mark_locations
   fun:scm_threads_mark_stacks
   fun:scm_igc
}

{
	guilegc
	Memcheck:Cond
	fun:scm_mark_locations	
}

{
    guilegc
	Memcheck:Cond
    fun:scm_gc_mark
}


{
    guilegc
	Memcheck:Cond
    fun:scm_i_sweep_card
}

{
    guilegc
	Memcheck:Cond
    fun:scm_mark_weak_vector_spines
}


{
    guilegc
	Memcheck:Cond
    fun:scm_gc_mark_dependencies
}

{
guilegc
Memcheck:Cond
fun:scm_scan_weak_vectors
}

**


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Bruce Korb]

Han-Wen Nienhuys wrote:
> Bruce Korb escreveu:
>> By the way, have you all given any consideration to releasing a
>> valgrind config file that would clean out valgrind chaff?
>> I recently needed to do a valgrind run and it was quite painful.
> 
> I always use the file below.  I am not sure what the best way to
> distribute it would be.

I think there are two reasonable ways:

1.  on the web site and referenced in the docs that it lives there
2.  stash in the datadir and make it obtainable via:

    $ cp `guile-config datadir`/guile.supp $my_debug_dir

Either way would be a lot easier than trying to figure it out
every few years.  :-)

Thank you for sending me your copy!

Cheers - Bruce


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Han-Wen Nienhuys]

Bruce Korb escreveu:
> Han-Wen Nienhuys wrote:
>> Bruce Korb escreveu:
>>> By the way, have you all given any consideration to releasing a
>>> valgrind config file that would clean out valgrind chaff?
>>> I recently needed to do a valgrind run and it was quite painful.
>> I always use the file below.  I am not sure what the best way to
>> distribute it would be.
> 
> I think there are two reasonable ways:
> 
> 1.  on the web site and referenced in the docs that it lives there
> 2.  stash in the datadir and make it obtainable via:
> 
>     $ cp `guile-config datadir`/guile.supp $my_debug_dir

Actually, I think it makes more sense to submit it to the valgrind guys.

(Would you be willing to do that?)

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Bruce Korb]

Han-Wen Nienhuys wrote:
>>>> By the way, have you all given any consideration to releasing a
>>>> valgrind config file that would clean out valgrind chaff?

>>> I always use the file below.  I am not sure what the best way to
>>> distribute it would be.
>> I think there are two reasonable ways:
>>
>> 1.  on the web site and referenced in the docs that it lives there
>> 2.  stash in the datadir and make it obtainable via:
>>
>>     $ cp `guile-config datadir`/guile.supp $my_debug_dir
> 
> Actually, I think it makes more sense to submit it to the valgrind guys.

Trouble is that it is Guile-version dependent.  You cannot sync
your releases.  It should come from Guile.  :)  (My opinions are
not overly humble...)  I prefer method #2, but either of these
works for me.  Cheers - Bruce


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Han-Wen Nienhuys]

Bruce Korb escreveu:
>> At the current release rate of GUILE, I'd expect anyone using GUILE
>> seriously to run the CVS version.  I do, at least. 
> 
> The last time I looked, you could find the 1.4 series being released
> with some BSD distributions.  That means my stuff has to run against

which ones? 

> all versions 1.4.x through 1.8.x.  It might be easier to obsolete
> the 1.4 interfaces if it were not still shipping.

Well, as long as we keep 'supporting' the 1.4 interfaces, there is little
incentive for developers to upgrade to the 1.6 or 1.8 API.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Bruce Korb]

Han-Wen Nienhuys wrote:
> Well, as long as we keep 'supporting' the 1.4 interfaces, there is little
> incentive for developers to upgrade to the 1.6 or 1.8 API.

Let me be clear about this:  it is (most likely) not the developers.
It is my clients.  Some of them upgrade to bleeding edge Guile and
the obsoleted interfaces choke my program.  I update the interfaces
and somebody running on a platform still on Guile 1.4 complains that
it chokes and dies on their system.  I could, of course, incorporate
the Guile library into my project, but I've determined that that is
way, way, way over the top.  If the interfaces are not stable enough
for me to readily be able to support the current active platforms,
then it is changing too quickly.  As it is, I have a long collection
of interface macros that wrap around Guile interfaces.  Maintaining
that isn't fun.  :(  [even less fun is the scm_c_eval_string_from_file_line()
thing, the subject of posts in the past...]

WRT the BSD distro:  It's been a couple of years since I encountered
the issue.  I don't actively track it.  A friend at UofU lets me play
on some of his build platforms, so I'll try to remember to check next
time I log in there.  I'm certain it is pretty old.

Cheers - Bruce


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Han-Wen Nienhuys]

Bruce Korb escreveu:
> it chokes and dies on their system.  I could, of course, incorporate
> the Guile library into my project, but I've determined that that is
> way, way, way over the top.  If the interfaces are not stable enough

As a sidenote,

We incorporate a copy of the GUILE library in the binaries that we
ship for lilypond.  People (call them 'clients' if you like) that go
out and create binaries on their own are a QA nightmare, as there is
no way to be sure that their configuration is working correctly. This
makes it a lot easier to deal with broken dependencies as well: if we
find a bug in a dependency, we fix it, and a patched version of the
dependency is included in the next lily release.

We do this for all dependencies except glibc.

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: deprecated features

[Kevin Ryde]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> Perhaps, but I'm for cleaner code. Having to keep deprecated stuff
> around (and worse: having to write various deprecation wrappers for
> them) is detrimental to code quality.

I would say the contrary is worse.  Users following the advertised
rules are told (exaggerated for rhetorical effect :-) "sucked in; we
said there was this feature, we encouraged you to use it, now it's
gone".  If guile is the official extension language, used by all gnu
packages (in principle) then it's a serious problem.

I expect the effect in practice is, at each incompatible change, to
throw off people who can't, or are not inclined to, update.  For
example gcc stuck to autoconf 2.13 for a long long time because
subsequent changes were incompatible (even though they were cleaner in
both concept and implementation).

Or you end up with versionitis, like 5 versions of automake all in
debian at the same time, because they each have subtle different
effects (even if sensible packages are ok with any of them).

> If the consensus is that removing deprecated features will not ever be
> done, then there is little point in marking routines as such, and
> writing wrappers to signal their use.

Yes.  "Don't do it" is the motto.  

> We could clean up GUILE by throwing away all the bookkeeping.

It has to stay for applications of course.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Eval options macro: backward compatibility?

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
>> I would like to change this order, and if possible move this out of
>> the global namespace.  Are there any objections?
> 
> It's ok for 1.9 to break binary compatibility, and it's also probably a
> good thing to not export things that are not documented.  So I think

I have committed a patch that does this, and also de-spaghettifies eval.c. 

-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Eval options macro: backward compatibility?

[Kevin Ryde]

ludo@chbouib.org (Ludovic Courtès) writes:
>
> It's ok for 1.9 to break binary compatibility,

Don't do it gratuitously though, just because something will look
better.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Eval options macro: backward compatibility?

[Kevin Ryde]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
> what is the status of the eval options structure wrt binary compatibility?

I remeber now: changing the size of a data object in a shared library
breaks mainlines using it, or even just taking its address.  And both
mainline and the library are broken, since the object is truncated to
the smaller size for both.  This is a bit subtle, but it bit for
instance in some of the old Xaw replacement libraries in the past.

If you think noone is using it then rename to scm_i_.  Or if you think
it's used then growing breaks it so take the opportunity to change to
a pointer at the same time.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel