Cygwin 1.5.5-1: Tk support for 'plot' command and widget?

Cygwin 1.5.5-1: Tk support for 'plot' command and widget?

[Lloyd Wood]

(I was directed to insight from the cygwin list.)

I've been maintaining and enhancing Tcl/Tk code that uses a plot
command for a creating and manipulating a vector plot widget (rather
than a canvas bitmap or image widget). That code has worked fine under
Tcl/Tk 7/4 and 8.x on e.g. Solaris and Linux for the past eight years,
but I find that just issuing the plot command of the form:

plot $name -bg black -height 300 -width 300

causes Tcl/Tk 8.4 (tcltk 20030901-1, says cygcheck) under an
just-installed-yesterday Cygwin 1.5.5-1 to die -- while Tcl/Tk 8.4
under Redhat 7.2 draws the widget and window just fine.

A refresher look through Tk's man pages shows the canvas command, but
not a plot command. Which is puzzling... so how did this plot command
ever work? Has this code been relying on an undocumented command in
Tcl/Tk under unix all this time? Is Tcl/Tk 8.4 under Cygwin different
from under unix in handling this? (The Cygwin Tk does live outside of
X, and I don't know what that leads to.)

The code to build the window that I'm describing is fisheye(build) at:
http://cvs.sourceforge.net/viewcvs.py/savi/savi-dev/tcl/fisheye.tcl
which calls simple procedures in:
http://cvs.sourceforge.net/viewcvs.py/savi/savi-dev/tcl/utils.tcl

This is part of SaVi: http://savi.sourceforge.net/
and a 17 January SaVi snapshot that compiles cleanly under Cygwin
and gcc 3.3.1 can be downloaded from:
http://www.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/src/unreleased/

A similar coverage window in the same application that uses a canvas
bitmap widget has no problems under Cygwin; canvas is fine, and canvas
is in the Tk documentation and man pages just as you would expect.

Pointers on what I'm doing wrong and my mistaken assumptions much
appreciated. The Tcl/Tk release that cygwin installs doesn't appear
debuggable; tips on debugging Tcl/Tk under Cygwin also welcome.

thanks,

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@ee.surrey.ac.uk>

building insight with mingw

[Dave Murphy]

Hi,

does anyone read this list?


I'm currently trying to build gdb/insight under mingw. So far I've managed
to get it to compile and install but not work as yet. Insight complains
about invalid command name "ide_cygwin_path" - I've enabled this in
tclwinpath.c but so far no joy. Is there anything else I need to do to get
tcl to recognise this command?

Dave

Re: building insight with mingw

[Keith Seitz]

On Mon, 2004-01-19 at 10:25, Dave Murphy wrote:
> does anyone read this list?

Sorta. ;-)

> I'm currently trying to build gdb/insight under mingw. So far I've managed
> to get it to compile and install but not work as yet. Insight complains
> about invalid command name "ide_cygwin_path" - I've enabled this in
> tclwinpath.c but so far no joy. Is there anything else I need to do to get
> tcl to recognise this command?

I wasn't aware that one could compile gdb under mingw. Oh well, shows
how out of touch I am...

ide_cygwin_path is defined in libgui (src/libgui). It only compiles for
cygwin. Since you are building for mingw and not cygwin, it is not being
built.

However, Insight has a ton of code which assumes that if it is running
on windows, it must be under cygwin. You will need to search for all
cases like this and distinguish between running on cygwin and running on
mingw.

Keith

Re: building insight with mingw

[Christopher Faylor]

On Mon, Jan 19, 2004 at 10:37:06AM -0800, Keith Seitz wrote:
>On Mon, 2004-01-19 at 10:25, Dave Murphy wrote:
>> I'm currently trying to build gdb/insight under mingw. So far I've managed
>> to get it to compile and install but not work as yet. Insight complains
>> about invalid command name "ide_cygwin_path" - I've enabled this in
>> tclwinpath.c but so far no joy. Is there anything else I need to do to get
>> tcl to recognise this command?
>
>I wasn't aware that one could compile gdb under mingw. Oh well, shows
>how out of touch I am...

I don't think that gdb builds without unofficial patches that are
sponsored by mingw folk.  If that is the case, then that makes building
gdb/insight a problem for mingw since it isn't really a supported
platform.

cgf

RE: building insight with mingw

[Dave Murphy]

> -----Original Message-----
> From: insight-owner@sources.redhat.com
> [mailto:insight-owner@sources.redhat.com]On Behalf Of Christopher Faylor
> Sent: 19 January 2004 21:03
> To: Keith Seitz
> Cc: Dave Murphy; insight@sources.redhat.com
> Subject: Re: building insight with mingw
>
>
> On Mon, Jan 19, 2004 at 10:37:06AM -0800, Keith Seitz wrote:
> >On Mon, 2004-01-19 at 10:25, Dave Murphy wrote:
> >> I'm currently trying to build gdb/insight under mingw. So far
> I've managed
> >> to get it to compile and install but not work as yet. Insight complains
> >> about invalid command name "ide_cygwin_path" - I've enabled this in
> >> tclwinpath.c but so far no joy. Is there anything else I need
> to do to get
> >> tcl to recognise this command?
> >
> >I wasn't aware that one could compile gdb under mingw. Oh well, shows
> >how out of touch I am...
>
> I don't think that gdb builds without unofficial patches that are
> sponsored by mingw folk.  If that is the case, then that makes building
> gdb/insight a problem for mingw since it isn't really a supported
> platform.
>

It would be nice if it was a supported platform though :)

I've managed to get past the ide_cygwin_path stuff now, everything compiles
and installs but Insight just stops for no readily apparent reason.
Attempting to debug gives me a SIGSEGV in mscvrt.dll relating to setjmp
which is confusing me a little.

Program received signal SIGSEGV, Segmentation fault.
0x7801ea8c in setjmp () from C:\WINNT\system32\msvcrt.dll
(gdb) backtrace
#0  0x7801ea8c in setjmp () from C:\WINNT\system32\msvcrt.dll
#1  0x0041fe6c in catcher (func=0x41fff0 <do_catch_errors>,
func_uiout=0x1279498,
    func_args=0x22d750, func_val=0x22d748, func_caught=0x22d74c,
errstring=0x5e90b7 "", mask=6)
    at ../../../insight-6.0.new/gdb/top.c:432
#2  0x00420046 in catch_errors (func=0x418e30 <wrapped_call>,
func_args=0x22d780,
    errstring=0x5e90b7 "", mask=6) at ../../../insight-6.0.new/gdb/top.c:514
#3  0x00418d62 in gdbtk_call_wrapper (clientData=0x419170, interp=0x1284510,
objc=2,
    objv=0x1287044) at
../../../insight-6.0.new/gdb/gdbtk/generic/gdbtk-cmds.c:356
#4  0x615ce62c in TclEvalObjvInternal (interp=0x2, objc=19427396, objv=0x1,
command=0x0, length=0,
    flags=2) at ../../../../insight-6.0.new/tcl/generic/tclBasic.c:3048
#5  0x01284510 in ?? ()
#6  0x00000002 in ?? ()
#7  0x01287044 in ?? ()
#8  0x00000001 in ?? ()

digging around I found this
http://sources.redhat.com/ml/gdb/2002-06/msg00135.html which suggests that
setjmp/longjmp should not be used. Currently I'm not sure if the error is
caused by setjmp or by something I've introduced at this point.

Any help in finding the problem would be greatly appreciated


Dave

RE: building insight with mingw

[Keith Seitz]

On Wed, 2004-01-21 at 12:37, Dave Murphy wrote:
> I've managed to get past the ide_cygwin_path stuff now, everything compiles
> and installs but Insight just stops for no readily apparent reason.
> Attempting to debug gives me a SIGSEGV in mscvrt.dll relating to setjmp
> which is confusing me a little.

I think you've hit the proverbial brick wall. Gdb uses setjmp/longjmp,
and I suspect it always will.

Apparently, there may be API errors between the unix way and the windows
way of dealing with this call. Here's a start: Is it possible that gcc
and msdev are using different memory layouts?

I would try writing a small test application which does setjmp/longjmp
and compiling that with mingw gcc. Does it work work?

Keith

Re: building insight with mingw

[Christopher Faylor]

On Wed, Jan 21, 2004 at 01:12:46PM -0800, Keith Seitz wrote:
>On Wed, 2004-01-21 at 12:37, Dave Murphy wrote:
>>I've managed to get past the ide_cygwin_path stuff now, everything
>>compiles and installs but Insight just stops for no readily apparent
>>reason.  Attempting to debug gives me a SIGSEGV in mscvrt.dll relating
>>to setjmp which is confusing me a little.
>
>I think you've hit the proverbial brick wall.  Gdb uses setjmp/longjmp,
>and I suspect it always will.
>
>Apparently, there may be API errors between the unix way and the
>windows way of dealing with this call.  Here's a start: Is it possible
>that gcc and msdev are using different memory layouts?
>
>I would try writing a small test application which does setjmp/longjmp
>and compiling that with mingw gcc.  Does it work work?

Wouldn't it be best to be working these kind of issues out with the
mingw mailing list?  I doubt that we have many people with windows
experience here.

cgf

RE: building insight with mingw

[Dave Murphy]

> On Wed, Jan 21, 2004 at 01:12:46PM -0800, Keith Seitz wrote:
> >On Wed, 2004-01-21 at 12:37, Dave Murphy wrote:
> >>I've managed to get past the ide_cygwin_path stuff now, everything
> >>compiles and installs but Insight just stops for no readily apparent
> >>reason.  Attempting to debug gives me a SIGSEGV in mscvrt.dll relating
> >>to setjmp which is confusing me a little.
> >
> >I think you've hit the proverbial brick wall.  Gdb uses setjmp/longjmp,
> >and I suspect it always will.


The issue isn't with gdb as such, plain vanilla gdb works fine under windows
when compiled with mingw. Obviously this is with the non official patches.
Setjmp/longjmp are supported in that environment although I believe there
are some issues with windows SEH.

What  I'm trying to find out is if the error is likely to be thrown up by
attempting to debug Insight with a native gdb or indeed a cygwin Insight.

> Wouldn't it be best to be working these kind of issues out with the
> mingw mailing list?  I doubt that we have many people with windows
> experience here.

I was hoping similar issues may have been encountered with the cygwin port
that might give some clue as to the best way to proceed :) I was hoping
someone here might know from the stack trace I showed if the error was
actually at this point :-

#4  0x615ce62c in TclEvalObjvInternal (interp=0x2, objc=19427396, objv=0x1,
command=0x0, length=0,
    flags=2) at ../../../../insight-6.0.new/tcl/generic/tclBasic.c:3048

and the rest of the problem was just the windows SEH, perhaps similar to
this issue

http://lists.freebsd.org/pipermail/freebsd-bugs/2003-August/002700.html

apologies if you consider this offtopic, just looking for info in as many
places as I can find.



Dave

Re: Cygwin 1.5.5-1: Tk support for 'plot' command and widget?

[Lloyd Wood]

It turns out the plot command is created the program's own code; I
had missed that. Inspection of the C code called when the plot
command is invoked shows that

http://cvs.sourceforge.net/viewcvs.py/savi/savi-dev/src/tkPlot.c

tkPlot.c's:

  plotPtr->pixelsPerMM = WidthOfScreen(Tk_Screen(new));
  plotPtr->pixelsPerMM /= WidthMMOfScreen(Tk_Screen(new));

crashes the program, and if those are commented out, so does the
later:

Tk_ConfigureWidget(interp, tkwin, configSpecs, argc, argv, (char *)
plotPtr, flags)

How does Insight Tk do screen handling? Is WidthOfScreen et al.
supported?

thanks,

L.

On Sun, 18 Jan 2004, Lloyd Wood wrote:

> Date: Sun, 18 Jan 2004 23:14:14 +0000 (GMT)
> From: Lloyd Wood <eep1lw@eim.surrey.ac.uk>
> To: insight@sources.redhat.com
> Subject: Cygwin 1.5.5-1: Tk support for 'plot' command and widget?
>
> (I was directed to insight from the cygwin list.)
>
> I've been maintaining and enhancing Tcl/Tk code that uses a plot
> command for a creating and manipulating a vector plot widget (rather
> than a canvas bitmap or image widget). That code has worked fine under
> Tcl/Tk 7/4 and 8.x on e.g. Solaris and Linux for the past eight years,
> but I find that just issuing the plot command of the form:
>
> plot $name -bg black -height 300 -width 300
>
> causes Tcl/Tk 8.4 (tcltk 20030901-1, says cygcheck) under an
> just-installed-yesterday Cygwin 1.5.5-1 to die -- while Tcl/Tk 8.4
> under Redhat 7.2 draws the widget and window just fine.
>
> A refresher look through Tk's man pages shows the canvas command, but
> not a plot command. Which is puzzling... so how did this plot command
> ever work? Has this code been relying on an undocumented command in
> Tcl/Tk under unix all this time? Is Tcl/Tk 8.4 under Cygwin different
> from under unix in handling this? (The Cygwin Tk does live outside of
> X, and I don't know what that leads to.)
>
> The code to build the window that I'm describing is fisheye(build) at:
> http://cvs.sourceforge.net/viewcvs.py/savi/savi-dev/tcl/fisheye.tcl
> which calls simple procedures in:
> http://cvs.sourceforge.net/viewcvs.py/savi/savi-dev/tcl/utils.tcl
>
> This is part of SaVi: http://savi.sourceforge.net/
> and a 17 January SaVi snapshot that compiles cleanly under Cygwin
> and gcc 3.3.1 can be downloaded from:
> http://www.ee.surrey.ac.uk/Personal/L.Wood/software/SaVi/src/unreleased/
>
> A similar coverage window in the same application that uses a canvas
> bitmap widget has no problems under Cygwin; canvas is fine, and canvas
> is in the Tk documentation and man pages just as you would expect.
>
> Pointers on what I'm doing wrong and my mistaken assumptions much
> appreciated. The Tcl/Tk release that cygwin installs doesn't appear
> debuggable; tips on debugging Tcl/Tk under Cygwin also welcome.
>
> thanks,
>
> L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@ee.surrey.ac.uk>