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

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.


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.

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)

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?

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.

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.

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.


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 { 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.