next upload (was: Re: bug 219448)

[Alastair McKinstry]

Hi,

I plan to upload slang2 to unstable as soon as possible. Are there any
plans to update the scripts in jed, etc to use slang2?

Note that I will upload slang2 as a new package, with package names
libslang2, libslang2-dev, libslang2-pic, slsh and libslang2-udeb (for
d-i). Hence this will be in parallel with slang1 (which will no longer
be actively maintained); Debian packages can transition from slang1 ->
slang2 without breakage.

Are there any objections / good reasons not to do this?

Regards
Alastair McKinstry

On Sath, 2005-05-21 at 13:15 +0200, Paul Boekholt wrote:
> On Sat, 21 May 2005 09:43:02 +0100, Alastair McKinstry <mckinstry@computer.org> said:
> 
> > I was already packaging 2.0.2 when I received your mail; can you explain
> > this issue a bit further? I don't see how implementing 2.0.0 helps (will
> > hold off uploading 2.0.2 for the moment)
> 
> Packaging 2.0.0 would be OK because that version does not have the
> incompatibility of 2.0.2.  In 2.0.2, an "autoload" statement such as
> autoload("f", bar)
> 
> evaluated in namespace foo will create a name foo->f that will cause the
> file bar to be evaluated in namespace foo when that function is called,
> that is, when foo.sl calls f().  But if bar.sl contained the definition
> public define f()
> than this will lead to an error in slang 2.0.2,  you'd get the error
> 
> f already has static or private linkage in this unit
> 
> In this case the word "public" in bar.sl was superfluous, and removing it
> would get rid of the error.  However the fact that slang 2.0.2 will load
> the file in the foo namespace, instead of just using the global
> namespace, can cause deeper incompatibilities.  For example if bar.sl:f
> looks like
> define f()
> {
>    g();
> }
> 
> and both the global namespace and the foo namespace have a g(), 2.0.0 as
> well as 1.x will use Global->g() and 2.0.2 will use foo->g() (if foo->g()
> is static that is, private functions are now private to the file they are
> in).
> 
> So the solution is to make sure that the autoloads are above the
> "implements" line.  So in foo.sl this involves the change
> 
> implements("foo");
> autoload("f", "bar");
> 
> to
> 
> autoload("f", "bar");
> implements("foo");
> 
> 
> It gets even worse when the require() and provide() functions of slang 2
> (in /usr/share/slsh/require.sl) are used in a future version of JED.  Then
> all requires and provides will also have to be moved above any implements
> statements.
> 
> So quite a few scripts will have to be updated.