Error: expected version number but got "8.6b2"

[Michael Talbot-Wilson]

Message returned by catch to a 'source /usr/local/lib/tcl8.6/init.tcl'.

8.6b2 is the correct version. It creates /usr/local/lib/tcl8.6 with no
'b' in the directory name, and 'b' is a valid character in a version
number according to generic/tclPkg.c.

Okay, if I enter "source /usr/local/lib/tcl8.6/init.tcl" interactively
in tclsh8.6 there is no error message.

I'm attempting to adapt someone else's script that works on tcl8.4.19
and the statement concerned is:

set res
[catch { uplevel #0 {source "/usr/local/lib/tcl8.6/init.tcl" } } srcErr]

which returns srcErr set to "expected..." per subject line.

What am I doing wrong?

[Michael Talbot-Wilson]

On 2012-05-11, Michael Talbot-Wilson <mtw@view> wrote:
> Message returned by catch to a 'source /usr/local/lib/tcl8.6/init.tcl'.

I should have said that I've had to do a wholesale replacement of
"interp->result" with Tcl_GetStringResult(interp).

- sprintf (interp->result, "%d %d", rx, ry);
+ sprintf (Tcl_GetStringResult(interp), "%d %d", rx, ry);

and

- interp->result = Tk_PathName(RasterPtr->tkwin);
+ Tcl_SetResult(interp, Tk_PathName(RasterPtr->tkwin), TCL_DYNAMIC);

(where TCL_DYNAMIC is a pure guess).

Is that correct, and are there traps one can fall into doing that?

[Andreas Leitgeb]

Michael Talbot-Wilson <m...@calypso.view.net.au> wrote:
> On 2012-05-11, Michael Talbot-Wilson <mtw@view> wrote:
>> Message returned by catch to a 'source /usr/local/lib/tcl8.6/init.tcl'.

I can't really say much about the C-code, but maybe you're not
aware that the rules about parsing version numbers changed fairly
recently (in terms of tcl versions, which may still be a few years).
So, if 8.6b2 is not accepted as a correct version number, then chances
are, that it is maybe a 8.4 interpreter that throws this error. If it
is so, then it can be expected that this version number misparsing would
not be the only error that it would freak out on a 8.6's init.tcl.

[Emiliano]

On 11 mayo, 07:56, Michael Talbot-Wilson <m...@calypso.view.net.au>
wrote:

> On 2012-05-11, Michael Talbot-Wilson <mtw@view> wrote:
>
> > Message returned by catch to a 'source /usr/local/lib/tcl8.6/init.tcl'.
>
> I should have said that I've had to do a wholesale replacement of
> "interp->result" with Tcl_GetStringResult(interp).
>
> -       sprintf (interp->result, "%d %d", rx, ry);
> +       sprintf (Tcl_GetStringResult(interp), "%d %d", rx, ry);

Recommended practice is to use the modern Tcl_Obj interface:

Tcl_SetObjResult(interp, Tcl_ObjPrintf("%d %d", rx, ry));

>
> and
>
> -       interp->result = Tk_PathName(RasterPtr->tkwin);
> +       Tcl_SetResult(interp, Tk_PathName(RasterPtr->tkwin), TCL_DYNAMIC);
>
> (where TCL_DYNAMIC is a pure guess).

Tcl_SetObjResult(interp,
Tcl_NewStringObj(Tk_PathName(RasterPtr->tkwin), -1));


Regards
Emiliano

[Donal K. Fellows]

On 11/05/2012 11:56, Michael Talbot-Wilson wrote:
> On 2012-05-11, Michael Talbot-Wilson<mtw@view> wrote:
>> Message returned by catch to a 'source /usr/local/lib/tcl8.6/init.tcl'.
>
> I should have said that I've had to do a wholesale replacement of
> "interp->result" with Tcl_GetStringResult(interp).

That's not right either. The work-around fix is to define the macro
USE_INTERP_RESULT when compiling, which re-exposes the field. Be aware
that we are going to get rid of the field entirely in the not very
distant future; it's _truly_ deprecated (and if you're building with the
development trunk with gcc, you'll get warnings even that macro defined).

> - sprintf (interp->result, "%d %d", rx, ry);
> + sprintf (Tcl_GetStringResult(interp), "%d %d", rx, ry);

The best way to write that now is:

Tcl_SetObjResult(interp, Tcl_ObjPrintf("%d %d", rx, ry));

In many ways, that actually says what is happening better than the other
two. OTOH, it might also be worthwhile actually building a list of two
numbers there; more code, but faster (both to generate and to parse).

Tcl_Obj *objs[2];
objs[0] = Tcl_NewIntObj(rx);
objs[1] = Tcl_NewIntObj(ry);
Tcl_SetObjResult(interp, Tcl_NewListObj(2, objs));

Perhaps there ought to be a varargs version of that... (There isn't
right now.)

> - interp->result = Tk_PathName(RasterPtr->tkwin);
> + Tcl_SetResult(interp, Tk_PathName(RasterPtr->tkwin), TCL_DYNAMIC);
>
> (where TCL_DYNAMIC is a pure guess).

Tcl_SetResult is still a supported interface (if not especially fast)
but the right values there are TCL_STATIC or TCL_VOLATILE as you don't
want Tcl to deallocate that string immediately.

Donal.