Re: [scite] Startup issue
304 views
Skip to first unread message
sdaau
May 22, 2012, 8:01:25 AM5/22/12
to scite-interest
Just wanted to post back, in response to this thread:
Re: [scite] Startup issue -
http://www.mail-archive.com/scite-i...@lyra.org/msg03855.html
(from Jul 2007 - while archive on google groups goes back only to Oct
2007).
The problem was:
> Hi,
> I get the following error when starting Scite:
>
> attempt to call a string value
> >Lua: error occurred while loading startup script
> attempt to call a string value
> >Lua: error occurred while loading startup script
I got the same error, but my use case was slightly different - if I
changed sciteLuaFunctions.lua from within Scite, and tried to save it,
I sometimes got that error, due to a `require("SciTEHexEdit")`.
Namely, it seems that each time you switch a tab to a document in
Scite, it seems that Scite's "current directory" is also changed to
the directory of the document in the tab. However, this somehow
doesn't work when you switch back to the tab for
sciteLuaFunctions.lua; which is why I got those errors. I noticed,
however, that if - after switching to sciteLuaFunctions.lua tab - I
try to type "pwd" in the Output Pane; it gets correctly read as `/home/
username` - and *after* this, saving sciteLuaFunctions.lua after a
change goes fine (unless there are lua compilation problems, of
course).
So a more permanent fix for without having to type "pwd" each time you
switch a tab, is to simply have Lua do it each time it wants to load
sciteLuaFunctions.lua - so I just add this, right before the `require`
line:
-- before the require, "pwd" once in this directory;
-- else crashes when changing tabs
print(pwd)
os.execute("pwd")
... and finally, it seems I can switch tabs, and change
sciteLuaFunctions.lua all I want now :)
Hope this ends up helping others in the same situation,
Cheers!
Re: [scite] Startup issue -
http://www.mail-archive.com/scite-i...@lyra.org/msg03855.html
(from Jul 2007 - while archive on google groups goes back only to Oct
2007).
The problem was:
> Hi,
> I get the following error when starting Scite:
>
> attempt to call a string value
> >Lua: error occurred while loading startup script
> attempt to call a string value
> >Lua: error occurred while loading startup script
I got the same error, but my use case was slightly different - if I
changed sciteLuaFunctions.lua from within Scite, and tried to save it,
I sometimes got that error, due to a `require("SciTEHexEdit")`.
Namely, it seems that each time you switch a tab to a document in
Scite, it seems that Scite's "current directory" is also changed to
the directory of the document in the tab. However, this somehow
doesn't work when you switch back to the tab for
sciteLuaFunctions.lua; which is why I got those errors. I noticed,
however, that if - after switching to sciteLuaFunctions.lua tab - I
try to type "pwd" in the Output Pane; it gets correctly read as `/home/
username` - and *after* this, saving sciteLuaFunctions.lua after a
change goes fine (unless there are lua compilation problems, of
course).
So a more permanent fix for without having to type "pwd" each time you
switch a tab, is to simply have Lua do it each time it wants to load
sciteLuaFunctions.lua - so I just add this, right before the `require`
line:
-- before the require, "pwd" once in this directory;
-- else crashes when changing tabs
print(pwd)
os.execute("pwd")
... and finally, it seems I can switch tabs, and change
sciteLuaFunctions.lua all I want now :)
Hope this ends up helping others in the same situation,
Cheers!
Neil Hodgson
May 22, 2012, 9:24:35 AM5/22/12
to scite-i...@googlegroups.com
sdaau:
>> attempt to call a string value
>>> Lua: error occurred while loading startup script
>> attempt to call a string value
>>> Lua: error occurred while loading startup script
>
> I got the same error, but my use case was slightly different
Lua shows "attempt to call a string value" for many different failures.
> Namely, it seems that each time you switch a tab to a document in
> Scite, it seems that Scite's "current directory" is also changed to
> the directory of the document in the tab.
This shouldn't be the case. There have been problems caused by switching current directories so I've been trying to eliminate chdir calls. There are still some on GTK+ when showing file open and save dialogs - it may now be possible to eliminate those. There are also some when running a command and it would also be better for the forked process to do that so SciTE's directory remains constant.
Neil
>> attempt to call a string value
>>> Lua: error occurred while loading startup script
>> attempt to call a string value
>>> Lua: error occurred while loading startup script
>
> I got the same error, but my use case was slightly different
> Namely, it seems that each time you switch a tab to a document in
> Scite, it seems that Scite's "current directory" is also changed to
> the directory of the document in the tab.
Neil
sdaau
May 22, 2012, 9:35:22 AM5/22/12
to scite-interest
Ehm, I was wrong:
> Namely, it seems that each time you switch a tab to a document in
> Scite, it seems that Scite's "current directory" is also changed to
> the directory of the document in the tab.
Nope, correction: it turns out to be more specific than that - if you
turn to a different tab AND execute one of your own lua scripts
(stored in luaSciteFunctions.lua); THEN the problem with changing the
"current directory" of lua occurs (otherwise not by simply changing
tabs).
The most straightforward way to fix that is to simply add the home
directory to lua's package.path; however, since lua is in Scite's case
running as a module, it doesn't have a reference to argv[0]. So this
is what worked for me, as a sort of a "preamble" for
luaSciteFunctions.lua:
---------
-- get home dir from shell
myHomeDir=io.popen("pwd"):read("*a")
-- the returned string contains an enter; remove it
-- (last character on end is -2)
myHomeDir=myHomeDir:sub(1,-2)
-- append myHomeDir to lua package.path
package.path = package.path .. ";" .. myHomeDir .. "/?.lua"
-- print to Output Pane to check if all good
print(package.path)
---------
However, before I figured that out, I was messing with a solution
based on lfs for Lua - which also works, but you have to install a
separate package; and then have lua in Scite use it.. So it is a bit
of work, so I'll dump also some of my notes for that below...
Anyways, hope this helps someone,
Cheers!
---------
Some useful links:
-- Change directory in Lua - http://forum.luahub.com/index.php?topic=2839.0
-- LuaFileSystem - http://keplerproject.github.com/luafilesystem/manual.html#reference
-- Lua: Modules: package.loaders - http://pgl.yoyo.org/luai/i/package.loaders
-- Convenient Lua Features: package.preload « Play With Lua! -
http://www.playwithlua.com/?p=11
-- Programming in Lua : 8 - Compilation, Execution, and Errors -
http://www.lua.org/pil/8.html
-- Re: loading lua scripts relative to an app's path -
http://lua-users.org/lists/lua-l/2006-10/msg00200.html
A separate binary has to installed for lfs (lua-filesystem); on Linux
it is "lfs.so"
-- sudo apt-get install lua-filesystem # not in my old version
-- wget http://launchpadlibrarian.net/48263173/liblua5.1-filesystem0_1.4.2-3_i386.deb
; sudo dpkg -i *.deb
That package installs in /usr/lib/lua/5.1/lfs.so; have to tell Scite's
lua to find it - by appending its location to package.cpath:
-- append to cpath location of lfs.so
package.cpath = package.cpath .. ";/usr/lib/lua/5.1/?.so"
print(package.cpath) -- for .so stuff
If you don't know this about cpath, one could have also used
package.preload; here is how you would load an .so file (along with
wrong syntax examples)
-- package.preload['lfs'] = "/usr/lib/lua/5.1/lfs.so" # NO; needs to
be function()!
package.preload['lfs'] = function()
------------ return "/usr/lib/lua/5.1/lfs.so" -- no!
local f = assert(loadfile("/usr/lib/lua/5.1/lfs.so"))
return f()
end
Finally, with lfs loaded, one can use lfs.chdir("/absolute/path") to
set the current directory which lua within Scite sees; I ran the
following snippet for debugging purposes:
require"lfs"
print(lfs) -- if ok, should be table: 0x9ffef58
print("pwd")
os.execute("pwd")
print(io.popen("pwd"):read("*a"))
--~ print(os.currentdir()) -- noexist
print(lfs.currentdir())
print("pwd2")
os.execute("cd ~") -- only in subshell; cd nowork back here
print(io.popen("cd ~"):read("*a")) -- only in subshell; cd nowork
back here
os.execute("pwd")
print(lfs.currentdir())
lfs.chdir("~") -- nowork on linux (~ is shell expansion)
print(lfs.currentdir())
lfs.chdir("/home/username") -- works fine
print(lfs.currentdir())
On May 22, 2:01 pm, sdaau <s...@imi.aau.dk> wrote:
> Just wanted to post back, in response to this thread:
>
> Re: [scite] Startup issue -
> http://www.mail-archive.com/scite-inter...@lyra.org/msg03855.html
> Namely, it seems that each time you switch a tab to a document in
> Scite, it seems that Scite's "current directory" is also changed to
> the directory of the document in the tab.
turn to a different tab AND execute one of your own lua scripts
(stored in luaSciteFunctions.lua); THEN the problem with changing the
"current directory" of lua occurs (otherwise not by simply changing
tabs).
The most straightforward way to fix that is to simply add the home
directory to lua's package.path; however, since lua is in Scite's case
running as a module, it doesn't have a reference to argv[0]. So this
is what worked for me, as a sort of a "preamble" for
luaSciteFunctions.lua:
---------
-- get home dir from shell
myHomeDir=io.popen("pwd"):read("*a")
-- the returned string contains an enter; remove it
-- (last character on end is -2)
myHomeDir=myHomeDir:sub(1,-2)
-- append myHomeDir to lua package.path
package.path = package.path .. ";" .. myHomeDir .. "/?.lua"
-- print to Output Pane to check if all good
print(package.path)
---------
However, before I figured that out, I was messing with a solution
based on lfs for Lua - which also works, but you have to install a
separate package; and then have lua in Scite use it.. So it is a bit
of work, so I'll dump also some of my notes for that below...
Anyways, hope this helps someone,
Cheers!
---------
Some useful links:
-- Change directory in Lua - http://forum.luahub.com/index.php?topic=2839.0
-- LuaFileSystem - http://keplerproject.github.com/luafilesystem/manual.html#reference
-- Lua: Modules: package.loaders - http://pgl.yoyo.org/luai/i/package.loaders
-- Convenient Lua Features: package.preload « Play With Lua! -
http://www.playwithlua.com/?p=11
-- Programming in Lua : 8 - Compilation, Execution, and Errors -
http://www.lua.org/pil/8.html
-- Re: loading lua scripts relative to an app's path -
http://lua-users.org/lists/lua-l/2006-10/msg00200.html
A separate binary has to installed for lfs (lua-filesystem); on Linux
it is "lfs.so"
-- sudo apt-get install lua-filesystem # not in my old version
-- wget http://launchpadlibrarian.net/48263173/liblua5.1-filesystem0_1.4.2-3_i386.deb
; sudo dpkg -i *.deb
That package installs in /usr/lib/lua/5.1/lfs.so; have to tell Scite's
lua to find it - by appending its location to package.cpath:
-- append to cpath location of lfs.so
package.cpath = package.cpath .. ";/usr/lib/lua/5.1/?.so"
print(package.cpath) -- for .so stuff
If you don't know this about cpath, one could have also used
package.preload; here is how you would load an .so file (along with
wrong syntax examples)
-- package.preload['lfs'] = "/usr/lib/lua/5.1/lfs.so" # NO; needs to
be function()!
package.preload['lfs'] = function()
------------ return "/usr/lib/lua/5.1/lfs.so" -- no!
local f = assert(loadfile("/usr/lib/lua/5.1/lfs.so"))
return f()
end
Finally, with lfs loaded, one can use lfs.chdir("/absolute/path") to
set the current directory which lua within Scite sees; I ran the
following snippet for debugging purposes:
require"lfs"
print(lfs) -- if ok, should be table: 0x9ffef58
print("pwd")
os.execute("pwd")
print(io.popen("pwd"):read("*a"))
--~ print(os.currentdir()) -- noexist
print(lfs.currentdir())
print("pwd2")
os.execute("cd ~") -- only in subshell; cd nowork back here
print(io.popen("cd ~"):read("*a")) -- only in subshell; cd nowork
back here
os.execute("pwd")
print(lfs.currentdir())
lfs.chdir("~") -- nowork on linux (~ is shell expansion)
print(lfs.currentdir())
lfs.chdir("/home/username") -- works fine
print(lfs.currentdir())
On May 22, 2:01 pm, sdaau <s...@imi.aau.dk> wrote:
> Just wanted to post back, in response to this thread:
>
> Re: [scite] Startup issue -
sdaau
May 22, 2012, 9:43:11 AM5/22/12
to scite-interest
Hi Neil,
Many thanks for your reply!!
>
> [snip]
from Python and such): `print myvar` generates an error;
`print(myvar)` doesn't :)
> > Namely, it seems that each time you switch a tab to a document in
> > Scite, it seems that Scite's "current directory" is also changed to
> > the directory of the document in the tab.
>
> This shouldn't be the case. There have been problems caused by switching current directories so I've been trying to eliminate chdir calls. There are still some on GTK+ when showing file open and save dialogs - it may now be possible to eliminate those. There are also some when running a command and it would also be better for the forked process to do that so SciTE's directory remains constant.
>
Indeed it isn't - sorry for that, I wasn't clear about it myself; just
before you posted, I had found and written a correction: "if you turn
to a different tab AND execute one of your own lua scripts ..." ; ...
and then switch back to the sciteLuaFunction.lua tab, I may add - then
the current directory seems to remain the one from the last visited
tab document.
However, I think now I have a fix for this on a lua-script-for-Scite
level, also posted in that reply - so all looks good now :)
Cheers!
> Neil
Many thanks for your reply!!
>
> [snip]
>
> Lua shows "attempt to call a string value" for many different failures.
>
Indeed - what I experienced just now (and what I always forget, mixing
> Lua shows "attempt to call a string value" for many different failures.
>
from Python and such): `print myvar` generates an error;
`print(myvar)` doesn't :)
> > Namely, it seems that each time you switch a tab to a document in
> > Scite, it seems that Scite's "current directory" is also changed to
> > the directory of the document in the tab.
>
> This shouldn't be the case. There have been problems caused by switching current directories so I've been trying to eliminate chdir calls. There are still some on GTK+ when showing file open and save dialogs - it may now be possible to eliminate those. There are also some when running a command and it would also be better for the forked process to do that so SciTE's directory remains constant.
>
before you posted, I had found and written a correction: "if you turn
to a different tab AND execute one of your own lua scripts ..." ; ...
and then switch back to the sciteLuaFunction.lua tab, I may add - then
the current directory seems to remain the one from the last visited
tab document.
However, I think now I have a fix for this on a lua-script-for-Scite
level, also posted in that reply - so all looks good now :)
Cheers!
> Neil
sdaau
May 22, 2012, 10:01:00 AM5/22/12
to scite-interest
And was wrong again - this earlier snippet is *not* the fix:
> -- get home dir from shell
> myHomeDir=io.popen("pwd"):read("*a")
>
Once you were in tab A, and switch to sciteLuaFuntions.lua - even
`pwd` (in shell) will read the directory of file in tab A! So the
right thing to do, is ask the shell for the absolute path to your home
directory; so under linux we can use `readlink` to return location of
home directory `~` (which lua couldn't understand directly)... The fix
is thus this:
-- get home dir from shell
myHomeDir=io.popen("readlink -f ~"):read("*a")
I made a couple of checks now, and it seems to work now - so hope that
was it for this problem :)
Cheers!
> -- LuaFileSystem -http://keplerproject.github.com/luafilesystem/manual.html#reference
> -- Lua: Modules: package.loaders -http://pgl.yoyo.org/luai/i/package.loaders
> -- Convenient Lua Features: package.preload « Play With Lua! -http://www.playwithlua.com/?p=11
> -- Programming in Lua : 8 - Compilation, Execution, and Errors -http://www.lua.org/pil/8.html
> -- Re: loading lua scripts relative to an app's path -http://lua-users.org/lists/lua-l/2006-10/msg00200.html
> -- get home dir from shell
> myHomeDir=io.popen("pwd"):read("*a")
>
`pwd` (in shell) will read the directory of file in tab A! So the
right thing to do, is ask the shell for the absolute path to your home
directory; so under linux we can use `readlink` to return location of
home directory `~` (which lua couldn't understand directly)... The fix
is thus this:
-- get home dir from shell
I made a couple of checks now, and it seems to work now - so hope that
was it for this problem :)
Cheers!
> -- Lua: Modules: package.loaders -http://pgl.yoyo.org/luai/i/package.loaders
> -- Convenient Lua Features: package.preload « Play With Lua! -http://www.playwithlua.com/?p=11
> -- Programming in Lua : 8 - Compilation, Execution, and Errors -http://www.lua.org/pil/8.html
> -- Re: loading lua scripts relative to an app's path -http://lua-users.org/lists/lua-l/2006-10/msg00200.html
>
> A separate binary has to installed for lfs (lua-filesystem); on Linux
> it is "lfs.so"
>
> -- sudo apt-get install lua-filesystem # not in my old version
> -- wgethttp://launchpadlibrarian.net/48263173/liblua5.1-filesystem0_1.4.2-3_...
> A separate binary has to installed for lfs (lua-filesystem); on Linux
> it is "lfs.so"
>
> -- sudo apt-get install lua-filesystem # not in my old version
Neil Hodgson
May 28, 2012, 10:10:50 AM5/28/12
to scite-i...@googlegroups.com
me:
> There have been problems caused by switching current directories so I've been trying to eliminate chdir calls. There are still some on GTK+ when showing file open and save dialogs - it may now be possible to eliminate those.
These calls to chdir have now been replaced with calls to the GTK+ API for setting the directory for file open and save dialogs. This will have the effect that most of these dialogs now open showing the directory of the current file. For the open dialog, this is the same as was achieved with the open.dialog.in.file.directory property. This property no longer has any effect on GTK+.
Recent Linux distributions have been using 'Recently Used' as the default directory for the open file dialog which has been annoying enough that most users were setting open.dialog.in.file.directory if they could find it. This change should make SciTE's default behaviour more useful for many.
Neil
> There have been problems caused by switching current directories so I've been trying to eliminate chdir calls. There are still some on GTK+ when showing file open and save dialogs - it may now be possible to eliminate those.
Recent Linux distributions have been using 'Recently Used' as the default directory for the open file dialog which has been annoying enough that most users were setting open.dialog.in.file.directory if they could find it. This change should make SciTE's default behaviour more useful for many.
Neil
Reply all
Reply to author
Forward
0 new messages