Integrate gsl-shell

[jayveesea]

add gsl-shell integration probably as a Lua Interpreter.

see here... http://www.nongnu.org/gsl-shell/

ps. well done!

[pkulchenko]

@coppolajj, thank you for the suggestion. I tried and ran into some issues with debugging GSL functions. You may be able to try it yourself if you want; since I'm not that familiar with GSL-shell, maybe I'm not doing this correctly.

Here is what I tried:

(1) I took demos/fractals.lua example and added von_koch_demo() call before return, so that it would just draw a fractal when called

(2) I added a batch file that would set environment variable to refer to mobdebug and luasocket from ZBS:

set ZBS=D:\users\paul\ZeroBraneStudio
set LUA_PATH=.\?.lua;%ZBS%\lualibs/?/?.lua;%ZBS%\lualibs/?.lua
set LUA_CPATH=%ZBS%\bin/?.dll;%ZBS%\bin/clibs/?.dll
start "GSL-shell" gsl-shell.exe demos\fractals.lua

Just change the ZBS path to your location or tweak the file If you are on Linux. You now should be able to run the batch file.

(3) Now add require('mobdebug').start() after use commands in the fractals.lua file. When I run the batch file, I get an error complaining about lua5.1.dll file. Unfortunately, this is expected as luasocket from ZBS is compiled against lua5.1.dll file, which is not available as GSL-shell includes those functions in the executable itself. So, I took lua5.1.dll from LuaJIT 2.0 and put it in the same folder as gsl-shell executable.

(4) Open ZBS. Go to Project | Start Debugger Server and start the server.

(5) Open GSL-shell folder in ZBS; Just put the folder in project drop down and hit Enter. In my case it is D:\Lua\gsl-shell-2.1.0-win32\. Open demos\fractals.lua file in the editor.

(6) Run the batch file. You should now see the green arrow on line require('mobdebug').start(). You can step through the code until you get to the plot() call where it crashes for me. It also crashes when I try to execute one of use or other non-standard Lua commands, which indicates that it probably has something to do with how GSL represents those commands internally.

I haven't had a chance to look at what happens inside the debugger, but may have time to do that in few days. If you figure something or find how to fix this, let me know.

[pkulchenko]

It seems like the problem somehow caused by the select call on line 546 in mobdebug:

      or (socket.select(rset, nil, 0))[server])

If you comment out this line (make sure you keep the closing bracket), then I can debug GSL-shell scripts just fine (stepping and breakpoints also work). This may still be related to how the luasocket library compiled as it works fine with the "normal" luajit 2.0 (but not with GSL-shell one). Still checking...

[jayveesea]

thanks for the quick response! i have not had time to try this out until today. i am getting hung up though.

i created a batch file...

set ZBS = E:\enviro\ZeroBraneStudioEduPack-0.33-win32
set LUA_PATH=.\?.lua;%ZBS%\lualibs/?/?.lua;%ZBS%\lualibs/?.lua
set LUA_CPATH=%ZBS%\bin/?.dll;%ZBS%\bin/clibs/?.dll
start "GSL-shell" gsl-shell.exe demos\fractals.lua

...and put it in the same directory as gsl-shell.exe. i can run this batch file and see that it works. i am using gsl-shell-2.1.0-win32.

then i added "require('mobdebug').start()" to fractals.lua like this...

use 'math'
use 'graph'
use 'iter'
require('mobdebug').start()

but i get this error when i try to run the batch file....

gsl-shell.exe: .\template.lua:81: 
no file '.\sf-defs.lua'
    no file '\lualibs/sf-defs/sf-defs.lua'
    no file '\lualibs/sf-defs.lua'
stack traceback:
    [C]: in function 'error'
    .\template.lua:81: in function 'process'
    .\template.lua:99: in function 'load'
    .\sf.lua:2: in main chunk
    [C]: in function 'require'
    .\gslext.lua:14: in main chunk
    [C]: ?
    [C]: ?
gsl-shell.exe: demos\fractals.lua:4: module 'mobdebug' not found:
    no field package.preload['mobdebug']
    no file '.\mobdebug.lua'
    no file '\lualibs/mobdebug/mobdebug.lua'
    no file '\lualibs/mobdebug.lua'
    no file '\bin/mobdebug.dll'
    no file '\bin/clibs/mobdebug.dll'
stack traceback:
    [C]: in function 'require'
    demos\fractals.lua:4: in main chunk
    [C]: ?

i did not have a lua jit dll, so i got one from here... http://www.scilua.org/get.html ...the dll from there is called "lua51.dll" so i made a copy and called it "lua5.1.dll" and put them both in the same directory as gsl-shell.exe (maybe not necessary???).

any suggestions?

i am trying to learn lua now so apologize if i am making some simple mistake.

maybe a stupid question... is it possible to use libgsl-0.dll with ZBS instead of the exe?

[pkulchenko]

@coppolajj, try to remove spaces here:

set ZBS = E:\enviro\ZeroBraneStudioEduPack-0.33-win32

to make it looks like this:

set ZBS=E:\enviro\ZeroBraneStudioEduPack-0.33-win32

This should help GSL to find the libraries it needs for debugging.

i did not have a lua jit dll, so i got one from here... http://www.scilua.org/get.html ...the dll from there is called "lua51.dll" so i made a copy and called it "lua5.1.dll" and put them both in the same directory as gsl-shell.exe (maybe not necessary???).

Yes, this may work. You may still get a run-time error (depending on how these dlls were built), but this is the best you can do for now.

is it possible to use libgsl-0.dll with ZBS instead of the exe?

I'm afraid not; part of the code that GSL-shell is using is in the executable, so you can't split them.

[jayveesea]

ok, thanks! this seems to work, but i am still playing around with it.

one thing that happens is when i run the bat file i initially get this error in a command window...

gsl-shell.exe: .\template.lua:81:
        no file '.\sf-defs.lua'
        no file 'E:\enviro\ZeroBraneStudioEduPack-0.33-win32\lualibs/sf-defs/sf-
defs.lua'
        no file 'E:\enviro\ZeroBraneStudioEduPack-0.33-win32\lualibs/sf-defs.lua
'
stack traceback:
        [C]: in function 'error'
        .\template.lua:81: in function 'process'
        .\template.lua:99: in function 'load'
        .\sf.lua:2: in main chunk
        [C]: in function 'require'
        .\gslext.lua:14: in main chunk
        [C]: ?
        [C]: ?

...but when i go over the ZeroBrane i can step through the file and i can see the plot. although sometimes it seems like it does not work, but i am still playing with it... i may try a simpler script and build from there. thanks for the help. it would be nice if this could be integrated more easily into ZBS... maybe like love2d???

[pkulchenko]

@coppolajj, I do get the same error, but not sure yet what triggers it. This doesn't seem to be related to ZBS.

it would be nice if this could be integrated more easily into ZBS... maybe like love2d???

Yes, the first step is usually to make it run manually to figure out what the environment should look like (which is what we are doing). When it's done, I'll find a way to make it run from the IDE.

[franko]

Hi,

I'm beginning to look into these problems to integrate gsl shell with ZBS. I need some time to verify some things but unfortunately I'm quite busy at work. Yet I think I will be able to help you to solve these problems in the next few days.

Just something about what you are trying to do: gsl shell needs to have "templates/?.lua.in" in package.path to load some templates. This is the reason for some of the errors that you got.

I don't have any clue why sockets don't work with gsl shell, probably this is just a problem of binary compatibility but I'm not sure about that. I need more times to better understand the problem.

Unfortunately lua socket does not build out of the box on windows and there are no build instructions. Yet I should be able to work it out with some time. I'm doing also some tests on linux when I have some spare time.

I hope we can make it work, ZBS looks like a great debugging environment :-)

Francesco

[pkulchenko]

@franko, thank you for taking time to look into this. Indeed, adding templates/?.lua.in to LUA_PATH eliminates the template.lua error.

socket.select() crashing is not a huge deal; I'd love to test on luasocket compiled against the correct DLL, but if it still doesn't work, I can possibly add a configuration switch to disable it.

Unfortunately lua socket does not build out of the box on windows and there are no build instructions.

Yes, I also tried to build it and probably ran into the same issue. Although I was trying the latest version as it was said that it's compatible with 5.2, so it may be related to that.

Please use this ticket to let us know if you make any progress and I'll do the same. Thanks.

[jayveesea]

thanks! i updated my bat file and now have no errors.

set ZBS=E:\enviro\ZeroBraneStudioEduPack-0.33-win32
set GSL=E:\enviro\gsl-shell-2.1.0-win32\gsl-shell
set LUA_PATH=.\?.lua;%ZBS%\lualibs/?/?.lua;%ZBS%\lualibs/?.lua;.\?.lua;%GSL%\?.lua;%GSL%\templates/?.lua.in
set LUA_CPATH=.\?.dll;%ZBS%\bin/?.dll;%ZBS%\bin/clibs/?.dll;%GSL%\?.dll
start "GSL-shell" gsl-shell.exe demos\fractals.lua

thanks!

[pkulchenko]

@franko, if you had a chance to compile luasocket on windows for gsl-shell, if would be great to know if socket.select() is working there. I can test it myself if you have the DLL library I can use.

If it still doesn't work, I'll consider adding a workaround to ZBS/Mobdebug.

[franko]

@pkulchenko Unfortunately I don't have compiled the library on windows. What prevented me from continue in this work was some doubts about how gsl shell should be integrated in ZBS. I've seen that on linux ZBS depends on lua and on lua-socket so I was thinking that it will never be binary compatible with luajit2 (or I'm wrong ?).

In other words I understood that ZBS works in a Lua ecosystem of modules and this is based on PUC-RIO Lua and not compatible with LuaJIT2.

I can compile gsl shell to be completely compatible with LuaJIT2 using the LUA_BUILD option in "makeconfig" but would this be enough to be integrated in ZBS ?

May be you should try to write down the technical requirements to be integrated with ZBS so that I can better understand what needs to be done.

In any case I will try to compile lua socket on windows tomorrow. If you think it can work I'm glad to make this effort :-)

[pkulchenko]

@franko, good points. Essentially, there are no dependencies on ZBS for the integration, but I do need to have luasocket available (plus MobDebug, but it's pure-Lua and LuaJIT-friendly). The only reason I tried with luasocket that ships with ZBS is because I didn't have anything else available. If there is a luasocket compatible with gsl-shell, I wouldn't need anything else to integrate.

The integration will be along the lines of the batch file that @coppolajj posted (minus LUA_CPATH reference as it will probably be using it's own luasocket). The IDE will start the gsl-shell process (after setting LUA_* environment variables) and will interact with that process over TCP. There is no dependency on what version of Lua is used or what the version of LuaJIT is as long as MobDebug supports it (and in the case of gsl-shell I tested with, it works fine).

So, all we need at this point is gsl-shell friendly luasocket dll that we can test with (or a version of gsl-shell that includes luasocket). I do get most of the debugging functionality working using luasocket that ships with ZBS, but since socket.select crashes the process, I'm not sure if it's because of incompatible DLL or if there is some other issue.

[franko]

@pkulchenko Hi, here a build of GSL Shell 2.2 for windows 32. It does include luasocket and it seems to work. I've built gsl shell using the dynamic linking with lua51.dll. This is mostly compatible with LuaJIT except the non-standard search-path for modules.

The package is here:

https://github.com/downloads/franko/gsl-shell/gsl-shell-luasocket-bc80382e.zip

[pkulchenko]

@franko, nice! Thank you for putting it together! As far as I can tell, everything works, including breaking a running application, which was crashing the gsl-shell before (so I think it was indeed related to some incompatibility with the socket dll I used).

Is there a way to make this version of gsl-shell available for download more or less permanently? I'm thinking about adding some form of integration to allow gsl-shell scripts to be run and debugged directly from the IDE.

One challenge with that is that right now they can't be compiled from the IDE (as they use a non standard syntax). Is there a way to incorporate the syntax to make things like ilist(|| 0, n+1) to work in loadstring?

[franko]

@pkulchenko I'm glad it works now :-)

Talking about this version of GSL Shell, it is actually a normal binary distribution except that

• the lua library is used as a DLL
• the luasocket library is included.

For the DLL I think that I will favor this solution at least on windows, so no problems. For the luasocket I think that I will offer it for download in the GSL Shell site as a separate module. I guess this should be ok for ZBS.

For the last point, I don't see any simple solution. The "short function syntax" is added as a simple modification of luajit parser. The only thing that I can imagine is to create a Lua DLL where this option can be enabled on demand. In this way ZBS can use the non standard script and the DLL can be still used as a standard Lua DLL. What kind of solution you would prefer ?

[pkulchenko]

For the DLL I think that I will favor this solution at least on windows, so no problems. For the luasocket I think that I will offer it for download in the GSL Shell site as a separate module. I guess this should be ok for ZBS.

@franko, yes, this would be great. I'll just add a note that if you want to debug use the version with luasocket (or download luasocket from your website). If you have a URL for that, I'll add it to the documentation when I'm done with the integration script.

For the last point, I don't see any simple solution. The "short function syntax" is added as a simple modification of luajit parser. What kind of solution you would prefer ?

I agree, I don't see a simple solution either. If this is the only difference -- meaning this syntax: |x| cos(x) * exp(-0.1 * x) -- I can probably solve this by providing a simple filter that will turn this into a "standard" function definition before checking if the code compiles. In all other cases, I'll just run it "as is". An even simpler alternative would be to simply disable compilation at all with gsl-shell and just report back any errors that are reported by it, whether compilation or run-time.

So, this |x| cos(x) * exp(-0.1 * x) will just become function (x) return cos(x) * exp(-0.1 * x) end, right?

[franko]

@pkulchenko Talking about your idea of automatically translating GSL Shell specific code, I don't recommend that. You will need to implement a whole parser for that.

May be we can address the problem by having a specific DLL that can still be Lua comatible ? Matter for thoughts...

[pkulchenko]

I agree; this would be ideal. For now I'll probably disable compilation before running, so that GSL-shell could report both compile-time and run-time errors back.

[marcelvanherk]

Hi Paul,

I tried running GSL-shell from within ZeroBrane studio (sound like a great combo) and had no luck. Even using the socket version listed above, and the following startup script:

set GSL="C:\Program Files (x86)\gsl-shell"
set ZBS=C:\lua\ZeroBraneStudio
set LUA_PATH=.?.lua;%ZBS%\lualibs/?/?.lua;%ZBS%\lualibs/?.lua;.?.lua;%GSL%?.lua;%GSL%\templates/?.lua.in
set LUA_CPATH=.?.dll;%ZBS%\bin/?.dll;%ZBS%\bin/clibs/?.dll;%GSL%?.dll
path C:\lua\ZeroBraneStudio\clibs;C:\lua\ZeroBraneStudio\bin\clibs
cd %GSL%
C:\lua\ZeroBraneStudio\zbstudio

I got:

Debugger server started at PC:8172.
Program starting as '"C:\Program Files (x86)\gsl-shell\gsl-shell.exe" "C:\Program Files (x86)\gsl-shell\gsl-shell\demos\plot.lua"'.
Program 'gsl-shell.exe' started in 'C:\Program Files (x86)\gsl-shell\gsl-shell\demos' (pid: 3544).
C:\Program Files (x86)\gsl-shell\gsl-shell.exe: C:\Program Files (x86)\gsl-shell\gsl-shell\import.lua:74: module sf not found
stack traceback:
[C]: in function 'error'
C:\Program Files (x86)\gsl-shell\gsl-shell\import.lua:74: in function 'use'
.\sf.lua:3: in main chunk
[C]: in function 'require'
C:\Program Files (x86)\gsl-shell\gsl-shell\gslext.lua:15: in main chunk
[C]: ?
[C]: ?
Program completed in 0.17 seconds (pid: 3544).

What do I do wrong?

Marcel

[pkulchenko]

Marcel, I don't see you doing anything wrong. Can you try directly from ZBS? You don't need the startup script at all; just select GSL-shell from the list of interpreters in ZBS and use Run (compile won't work because of || syntax GSL-shell is using).

If you still get the same error, maybe @franko can take a quick look at this. Thank you.

[marcelvanherk]

Same error. Must be a Lua path thing. The new (socket) version, though, does give an error when I try to start it directly. When replacing it by the 2.2.0 release I still get the same error...

Marcel

[pkulchenko]

Indeed; I can reproduce the same error. Seems harmless as I can continue debugging, but still. If I set the project path to the folder with GSL-shell I don't get this error, so it does seem path-related. Still looking...

[pkulchenko]

@franko, can you take a quick look at this error? It seems to be path related as when the current folder is "C:\Program Files (x86)\gsl-shell\gsl-shell" the error disappears (in this case the folder is "C:\Program Files (x86)\gsl-shell\gsl-shell\demos").

Program starting as '"C:\Program Files (x86)\gsl-shell\gsl-shell.exe" "C:\Program Files (x86)\gsl-shell\gsl-shell\demos\plot.lua"'.
Program 'gsl-shell.exe' started in 'C:\Program Files (x86)\gsl-shell\gsl-shell\demos' (pid: 3544).
C:\Program Files (x86)\gsl-shell\gsl-shell.exe: C:\Program Files (x86)\gsl-shell\gsl-shell\import.lua:74: module sf not found
stack traceback:
[C]: in function 'error'
C:\Program Files (x86)\gsl-shell\gsl-shell\import.lua:74: in function 'use'
.\sf.lua:3: in main chunk
[C]: in function 'require'
C:\Program Files (x86)\gsl-shell\gsl-shell\gslext.lua:15: in main chunk
[C]: ?
[C]: ?

Also, if I remove the line that loads sf.lua in gslext.lua, the scripts work without any issues.

[marcelvanherk]

Hi,

indeed setting the project folder takes away the message. I still can't see any output though. Which version of gsl-shell do I need to use?

Marcel

---

Van: Paul Kulchenko [notifications@github.com]
Verzonden: zaterdag 1 december 2012 20:19
Aan: pkulchenko/ZeroBraneStudio
CC: Marcel van Herk
Onderwerp: Re: [ZeroBraneStudio] Integrate gsl-shell (#72)

Indeed; I can reproduce the same error. Seems harmless as I can continue debugging, but still. If I set the project path to the folder with GSL-shell I don't get this error, so it does seem path-related. Still looking...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/72#issuecomment-10920879.

[pkulchenko]

Marcel, if by "output" you mean the window with plotting results, then the plot script doesn't plot it; it only provides functions that do this. try adding demo4() before return in the script. You may need to put a breakpoint right after demo4 call as the window will disappear quickly.

print statements should work too (you will see the output in the Output window), but they may be buffered.

[marcelvanherk]

Hi Paul,

Now I see the window flash but I cannot set breakpoints. What are the prerequisites to run/debug gsl-shell from zbs?

Marcel

---

Van: Paul Kulchenko [notifications@github.com]
Verzonden: zaterdag 1 december 2012 20:35
Aan: pkulchenko/ZeroBraneStudio
CC: Marcel van Herk
Onderwerp: Re: [ZeroBraneStudio] Integrate gsl-shell (#72)

Marcel, if by "output" you mean the window with plotting results, then the plot script doesn't plot it; it only provides functions that do this. try adding demo4() before return in the script. You may need to put a breakpoint right after demo4 call as the window will disappear quickly.

print statements should work too (you will see the output in the Output window), but they may be buffered.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/72#issuecomment-10921072.

[pkulchenko]

Marcel, I neglected to mention small but significant detail (it's listed at the beginning of this discussion). LuaJIT-based interpreters don't work the same way as "normal" lua interpreters in this regard and you need to add the following line to your script to start debugging explicitly:

require('mobdebug').start()

You will see a green arrow on that line and from that you can set breakpoints, step, continue and so on.

[marcelvanherk]

Hi Paul,

If I add require('mobdebug').start(), it then complains that it cannot find lua5.1.dll. If I add the one from your distribution gsl-shell.exe crashes at address 0000e1c4. I use the gsl-shell posted above (which includes socket.dll).

Marcel

[pkulchenko]

Marcel, it works for me with the version you are using when I set the project folder to gsl-shell folder.

If you set some other project folder, try with the latest code from github as there was a patch that sets CPATH to use luasocket that ships with gsl-shell instead of the one that comes with ZBS.

[marcelvanherk]

With your patch it tries to start but it is back to missing lua5.1.dll. Copying the one from your distribution to gsl-shell causes a crash. I may have different (or no) windows PATH. Also having fun writing an interpreter for Conquest DICOM server. Marcel

[pkulchenko]

Marcel, can you include the output from ZBS: "Program starting as..." and "...started in..." messages?

I tried with a fresh install of GSL-shell-with-socket to D:\Program Files\gsl-shell\ and set the project folder to ...\demos folder. I don't get any issues (other than sf.lua message) when I run with the latest github code (make sure you restart ZBS if you make any changes to the interpreter code).

[marcelvanherk]

Hi,

Just did a fresh install of both packages, same lua5.1.dll message. Socket/core.dll is seeking for this file. It may be in your path somewhere. And I guess the version with ZBS is not compatible with GSL, as the latter uses JIT, while ZBS does not.

Marcel

---

Van: Paul Kulchenko [notifications@github.com]
Verzonden: zaterdag 1 december 2012 23:44
Aan: pkulchenko/ZeroBraneStudio
CC: Marcel van Herk
Onderwerp: Re: [ZeroBraneStudio] Integrate gsl-shell (#72)

Marcel, can you include the output from ZBS: "Program starting as..." and "...started in..." messages?

I tried with a fresh install of GSL-shell-with-socket to D:\Program Files\gsl-shell\ and set the project folder to ...\demos folder. I don't get any issues (other than sf.lua message) when I run with the latest github code (make sure you restart ZBS if you make any changes to the interpreter code).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/72#issuecomment-10923271.

[pkulchenko]

Right, the version of gsl-shell referenced earlier in this thread includes that dll. The one from zbs won't work in this case.

[marcelvanherk]

Here it is:

Program starting as '"C:\Program Files (x86)\gsl-shell\gsl-shell.exe" "C:\Program Files (x86)\gsl-shell\gsl-shell\demos\plot.lua"'.
Program 'gsl-shell.exe' started in 'C:\Program Files (x86)\gsl-shell' (pid: 5712).
C:\Program Files (x86)\gsl-shell\gsl-shell.exe: error loading module 'socket.core' from file 'C:\lua\ZeroBraneStudio\bin/clibs/socket\core.dll':
The specified module could not be found.
The message box show lua5.1.dll not found.

Marcel

[marcelvanherk]

Paul, if your refer to gsl-shell-luasocket-bc80382e.zip, it does not: it includes lua51.dll, but NOT lua5.1.dll

Marcel

[pkulchenko]

Paul, if your refer to gsl-shell-luasocket-bc80382e.zip, it does not: it includes lua51.dll, but NOT lua5.1.dll

Marcel, you are correct, but this still doesn't look right; from your earlier message:

C:\Program Files (x86)\gsl-shell\gsl-shell.exe: error loading module 'socket.core' from file 'C:\lua\ZeroBraneStudio\bin/clibs/socket\core.dll':

Note that it tries to load socket.core from ZBS folders and it should be using GSL-shell's version. Are you sure you have socket version of gsl-shell and the latest version of ZBS (it should add gsl-shell/?.dll to LUA_CPATH before ZBS folders)?

I'd make sure that sockets work with gsl-shell without ZBS at all. Copy mobdebug.lua to gsl-shell folder and try running:

"C:\Program Files (x86)\gsl-shell\gsl-shell.exe" "C:\Program Files (x86)\gsl-shell\gsl-shell\demos\plot.lua"

If this works, it should also work with ZBS. Note that you have "gsl-shell" twice in the second path.

[franko]

@marcelvanherk , @pkulchenko ,

Hi,

sorry for replying only now. With the latest gsl shell release 2.2.0 I've also uploaded a separate luasocket package to be used with gsl shell on windows. It is in the download directory:

http://download.savannah.gnu.org/releases/gsl-shell/

The file is named: luasocket-gsl-shell-2.2.0.zip .

Talking about the other problems, I was thinking it was already clear from the previous discussion. Quoting from my previous post :

Just something about what you are trying to do: gsl shell needs to have "templates/?.lua.in" in package.path to load some templates. This is the reason for some of the errors that you got.

So the idea is that to make gsl shell work with ZBS you need the specific luasocket package from luasocket directory. Both luasocket and gsl shell should use the lua5.1.dll included with gsl shell. Then make sure that the LUA_PATH and LUA_CPATH are configured to point to gsl shell specific paths . You can inspect the paths of these directory from gsl shell by inspecting the variables "packages.path" and "packages.cpath". The difference with Lua is the lua/5.1 is replaced by gsl-shell/2.2 and "templates/?.lua.in" is added to search for templates.

I hope that helps.

Francesco

[pkulchenko]

Francesco, thank you for making the download available!

I do have "templates/?.lua.in" in package.path, but I'm still getting the error below:

D:\Program Files\gsl-shell\gsl-shell.exe: D:\Program Files\gsl-shell\import.lua:74: module sf not found: nil
stack traceback:
    [C]: in function 'error'
    D:\Program Files\gsl-shell\import.lua:74: in function 'use'
    .\sf.lua:3: in main chunk
    [C]: in function 'require'
    D:\Program Files\gsl-shell\gslext.lua:15: in main chunk
    [C]: ?
    [C]: ?

Just in case my path and cpath:

path, ...D:\Program Files\gsl-shell\?.lua;D:\Program Files\gsl-shell\templates/?.lua.in
cpath, D:\Program Files\gsl-shell\?.dll;bin/?.dll;bin/clibs/?.dll;.\?.dll;.\?51.dll;...

[marcelvanherk]

Hi Paul, Francesco,

After I unpacked the luasocket zip file into C:\Program Files (x86)\gsl-shell\gsl-shell, and I added require('mobdebug').start() in the first line of the code the debugger started to work. However, I still get the lua5.1.dll error (it is loading the wrong core.dll) unless C:\Program Files (x86)\gsl-shell\gsl-shell is my project folder in ZBS.

This is my startup batch file:

set GSL="C:\Program Files (x86)\gsl-shell"
set ZBS=C:\lua\ZeroBraneStudio
set LUA_PATH=.?.lua;%ZBS%\lualibs/?/?.lua;%ZBS%\lualibs/?.lua;.?.lua;%GSL%?.lua;%GSL%\templates/?.lua.in
set LUA_CPATH=.?.dll;%ZBS%\bin/?.dll;%ZBS%\bin/clibs/?.dll;%GSL%?.dll
path C:\Program Files (x86)\gsl-shell;C:\Program Files (x86)\gsl-shell\gsl-shell;C:\lua\ZeroBraneStudio\clibs;C:\lua\ZeroBraneStudio\bin\clibs
cd %GSL%
C:\lua\ZeroBraneStudio\zbstudio

Also, it would be (more than) perfect if we could get "run as scratchpad" working in gsl-shell. And if I could integrate some of gsl-shell's elements with my own projects (that use plain lua).

Thanks,

Marcel

[franko]

@pkulchenko

It seems that the path you are using is not correct. Normally if you install gsl-shell in a folder D:\programs\gsl-shell you should have in path:

D:\programs\gsl-shell\gsl-shell?.lua;D:\programs\gsl-shell\gsl-shell\templates?.lua.in

In other words the modules for gsl shell lives inside the 'gsl-shell' directory nested into the installation directory.

The same things is true for cpath.

[franko]

@marcelvanherk, @pkulchenko

After I unpacked the luasocket zip file into C:\Program Files (x86)\gsl-shell\gsl-shell, and I added require('mobdebug').start() in the first line of the code the debugger started to work. However, I still get the lua5.1.dll error (it is loading the wrong core.dll) unless C:\Program Files (x86)\gsl-shell\gsl-shell is my project folder in ZBS.

I've made some attemps but they were all unsuccessful. Probably Paul is the only one that can make it work.

What I can say is that: gsl shell is not binary compatible with Lua neither it is with ZBS. So when using it with ZBS, the two processes should not share any module, each one should have its own environment to run. This was the reason why I provided the luasocket binaries for windows.

When gsl-shell starts it tries needs to run some initialization script. The initialization script itself is "gslext.lua". If gsl shell cannot locate the needed initialization script it will fails.

If we want to discuss more interactively may be we can meet by char at freenode or something like that. I'm available in this moment.

[marcelvanherk]

Hi Francesco,

I guess indeed we need to discuss it with Paul, but he might not be up yet.

Marcel

[pkulchenko]

Francesco, you are correct about the module structure. I was going by the wrong structure and this is why I was missing one gsl-shell folder.

Marcel, I think you are almost right, but the paths you set from your batch file are overwritten by ZBS when it sets the environment for GSL-shell.

Also, it would be (more than) perfect if we could get "run as scratchpad" working in gsl-shell.

I'm experimenting with it, but it may not be possible due to differences in LuaJIT comparing to "normal" interpreter. Still trying.

And if I could integrate some of gsl-shell's elements with my own projects (that use plain lua).

It seems like you'd need to use GSL-shell as your interpreter for that.

[pkulchenko]

Marcel, I pushed the change that uses correct gsl-shell folder structure. It should work for your setup out-of the box. You don't need any batch files to run it. Just set project folder to whatever you need to select GSL-shell as the interpreter. It works with different files on my machine without any other changes. You still need require('mobdebug').start() in your scripts to get debugging to work.

Francesco, I still get this error (not fatal);

D:\Program Files\gsl-shell\gsl-shell.exe: D:\Program Files\gsl-shell\gsl-shell/import.lua:74: module sf not found
stack traceback:

You can try with the new version that should work out of the box for you too. You will see this error with the traceback in the Output window of ZBS. If I comment out line 15 in gslext.lua everything still works and the message is gone.

[marcelvanherk]

Hi Paul,

it works, and only gives the sf error when I use C:\Program Files\gsl-shell\gsl-shell\demos as startup directory, it does not when I use C:\Program Files\gsl-shell\gsl-shell or C:\Program Files\gsl-shell as startup directory.

Marcel

[pkulchenko]

Right, I get the same result.

@franko, can you look at this? I'm out of ideas as I can't reproduce it from outside of ZBS and yet there shouldn't be anything tricky as I only set LUA_CPATH, LUA_PATH and the current folder to the project folder. Everything works except that non fatal error message that disappears when the project folder (as the current folder as the result) is set to gsl-shell folder.