Patch for making L-gui to work properly in interactive mode


#1

tkMain.c.diff.txt (1.7 KB)

As I commented before L-gui is not processing #lang directives in interactive mode and you can not write little code in the L-gui shell. I looked how the L shell is doing the right thing (in tclMain.c) and made the same changes in L-gui (tkMain.c).

To apply the patch:

patch tk/generic/tkMain.c tkMain.c.diff.txt 

I couldn’t figure out how to do a pull request on github when the modified code is from a submodule.

pmarin.


#2

Thanks! The code looks good but I haven’t yet gotten it to work on OS X. The #include Lcompile.h caused the build to break in my environment (OS X 10.10.5). It didn’t seem necessary to include that file, so I got a build after removing it but then Lgui segfaults on startup. It builds and works OK on Ubuntu. I’ll have a next-level look tomorrow.


#3

You are right.

I made a mistake in the line

cmd = Tcl_DStringAppend(&dstr, "set('::L',0);\n", 15);

The length of “set(’::L’,0);\n” is 14 not 15

Maybe L-gui segfaults when reading libl.tcl at startup because of this mistake.

tkMain.c.diff.txt (1.6 KB)


#4

I don’t think that was it, because I was getting a crash before the main
loop ever started up.

I discovered that the Tcl_SetVar early in Tk_MainEx is crashing
for me (this is on OS X 10.10.3). Maybe that’s too early in the Tk
init path to be setting Tcl variables; I don’t know. But if I move it
to just before the Tk_MainLoop call, it seems to work, on both OS X
and Linux. Can you verify that?


#5

It works in Linux. I don’t have a mac so I can not test in OSX.

Reading the code looks like in OSX you can run L-gui from a unix terminal typing L-gui in the bash shell or in a Tk console by double clicking L-gui in the file manager. Is it crashing in both situations?

I’m trying to compile on Windows but I’m not having luck with the build environment.


#6

Yes, the crash occurred both ways, but went away once I moved the Tcl_SetVar.

I don’t think this patch will fix the graphical Tk console though, which comes up when you double-click on the L-gui app in Finder under OS X. I haven’t been in that code before, but it looks like it’s handled by Tcl code in tk/library/console.tcl and not the loop in Tk_Main which is an interactive mode via stdin (not available on Windows).

I was able to get a Windows build (have you seen Building on Windows ? those directions should still apply except that we’ve already patched the source code so you shouldn’t have to do that part if you have the latest tree). Running L-gui on Windows also brings up the graphical Tk console. So I suppose a full solution would need some more changes. I’ll have a look at console.tcl later.


#7

console.tcl.diff.txt (910 Bytes)

I made this patch for the Tk console with the same changes, this time in Tcl.

I found two more unrelated bugs:

On Windows clicking in the file manager L or L-gui do not work.
To bring up the Tk console I have to type:

 $ start L/opt/little-lang/bin/L-gui

In Interactive mode in L or L-gui if you make a mistake when you are in #lang L mode the console doesn’t process input anymore.

pmarin


#8

Lcompile.c.diff.txt (431 Bytes)

This patch will fix the bug in the L command which stop evaluating code when a
previous syntax error has been produced.

How to reproduce the bug:

>L/opt/little-lang/bin/L 
% L { puts("It's working"); }
It's working
% L { this is a syntax error }
<stdin>:2: L Error: syntax error, unexpected id
 this is
       ^
% L { puts("The L command stops to evaluating code and this line is not going to be printed."); }
%

The problem is when a syntax error is produced by the previous command, ‘L->err’ is set to 1 in Lcompile.c:6478 .
‘L-err’ is checked by the fuction ast_compile and it does not evaluate the compiled code if L->err is set to 1.
The problem is that L->err is not reset to 0 for the next L command.

In my patch I just set L->err to 0 at the beginning of the L command to fix the problem.

pmarin