[ZeroBrane Studio] Re: couple of questions
- From: Geoff smith <luadataviz@xxxxxxxxxxxxx>
- To: "zerobrane@xxxxxxxxxxxxx" <zerobrane@xxxxxxxxxxxxx>
- Date: Fri, 8 Nov 2013 03:17:18 +0000
Hi Paul
Thanks a lot for the detailed reply, I will study it some more tomorrow.
Aha yes that was the problem, I had a line something like print
(math.mod(8,3))
That no longer worked after you switched over. Yes that could easily be
corrected with the % operator but to be honest I wouldn't like recommending in
future to our users a 5.2 compatible editor for a 5.1 only target.
You know how easily things get confused, we will have folks putting gotos in
the script that work fine on the PC but then don't work on the target. I just
feel more comfortable keeping things in sync version wise.
Anyway I will try the tweak you suggested to get 5.1 back, see how I get on
with that.
Thanks again
Geoff
> Date: Thu, 7 Nov 2013 18:11:59 -0800
> Subject: [ZeroBrane Studio] Re: couple of questions
> From: paul@xxxxxxxxxxxxx
> To: zerobrane@xxxxxxxxxxxxx
>
> Hi Geoff,
>
> > Yes removing Lua 5.1 was a big problem for us, so much so that I stopped
> > using ZBS and switched to a different IDE. We are using it to write scripts
> > for a embedded system that is 5.1 and unlikely to change to 5.2 and will
> > never be Lua Jit.
>
> Sorry to hear that; I wish you'd told me that when you first
> encountered that error. This is only the second time I hear about
> possible incompatibilities and the first one was related to the use of
> "goto" as a variable name.
>
> > The first script I loaded into V0.39 that was fine in earlier versions
> > produced an error for me. I cant recall what it was now as I did this a few
> > weeks back, but it was due to some small but significant incompatibility
> > between versions
>
> I'd love to know what the error was as my assumption was that using
> LuaJIT would provide a smooth transition path to those who want to
> switch to Lua 5.2 and also would allow to stay compatible with Lua
> 5.1. So far I have only came across two issues: missing math.mod (can
> be replaced with %) and tbl.goto not allow as goto is a keyword.
>
> The current version of LuaJIT is compiled with
> LUAJIT_ENABLE_LUA52COMPAT switch, which is a bit less compatible with
> Lua 5.1 (http://luajit.org/extensions.html). I'm considering
> recompiling LuaJIT without that switch, especially if it's causing
> compatibility issues as the ones you see.
>
> > It would be great to have it back in as a future option please ? Thanks
> > for the note on how to put it back, I will try that tomorrow.
>
> That was my original plan, but it turned out to be too complex because
> of dynamic library dependencies (especially on windows). I tried to
> find a way to make Lua 5.1, LuaJIT and Lua 5.2 to co-exist, but there
> was just no clean option to package them all, so I decide to go with
> LuaJIT and Lua 5.2. You should still be able to use Lua5.1 dll (as I
> suggested earlier), but my preference would be to figure out what
> exactly is causing the issue for you.
>
> Using LuaJIT has some other advantages even for those who don't use
> LuaJIT as I plan to integrate profiling and some other features that
> are not available in Lua 5.1.
>
> > My other question missed a detail I should have mentioned. The other
> > language for syntax colouring was an oddball language that wouldn't be in
> > Scintilla as an existing lexer. so I guess to implement that I would have
> > to implement it first in Scintilla then build that as a custom object and
> > then hook it up to ZBS. That sounds pretty tough to figure out and get
> > working.
>
> It is possible. I've done something similar with styling I use for
> Markdown formatting. Roughly, the logic is this: you set Lexer to the
> value of SCLEX_CONTAINER, which will make Scintilla to trigger
> StyleNeeded events when it needs to style a text fragment. You can
> then style the fragment any way you need.
>
> Some of the resources that can be helpful:
> 1. Scintilla styling docs: http://www.scintilla.org/ScintillaDoc.html#Styling
> 2. How to write a lexer; it's in C, but all the calls can be mapped
> with wxlua calls: http://www.scintilla.org/Lexer.txt
> 3. Simple lexer in a container:
> http://sphere.sourceforge.net/flik/docs/scintilla-container_lexer.html
> 4. Markdown styling used in ZeroBrane Studio:
> https://github.com/pkulchenko/ZeroBraneStudio/blob/master/src/editor/markup.lua#L151-L210;
> it's called from UPDATEUI event, but it can also be called from
> STYLENEEDED even and will work exactly the same way, but STYLENEEDED
> is only generated when lexer is set to CONTAINER (which is your case)
> and not LUA (which is my case).
>
> You can still use something similar to what I sent you in
> spec/cpp.lua, but instead of wxstc.wxSTC_LEX_CPP you will have
> wxstc.wxSTC_LEX_CONTAINER and your own constants instead of
> wxstc.wxSTC_C_*. When you parse your file format, you will apply those
> styles to specific fragments of your code, which will automatically
> apply whatever colors/attributes you configured for those styles.
>
> Paul.
>
> On Thu, Nov 7, 2013 at 4:49 PM, Geoff smith <luadataviz@xxxxxxxxxxxxx> wrote:
> > Hello Paul
> >
> > Yes removing Lua 5.1 was a big problem for us, so much so that I stopped
> > using ZBS and switched to a different IDE.
> >
> > We are using it to write scripts for a embedded system that is 5.1 and
> > unlikely to change to 5.2 and will never be Lua Jit.
> >
> > The first script I loaded into V0.39 that was fine in earlier versions
> > produced an error for me. I cant recall what it was now as I did this a few
> > weeks back, but it was due to some small but significant incompatibility
> > between versions
> >
> > It would be great to have it back in as a future option please ? Thanks for
> > the note on how to put it back, I will try that tomorrow.
> >
> > My other question missed a detail I should have mentioned. The other
> > language for syntax colouring was an oddball language that wouldn't be in
> > Scintilla as an existing lexer. so I guess to implement that I would have to
> > implement it first in Scintilla then build that as a custom object and then
> > hook it up to ZBS.
> >
> > That sounds pretty tough to figure out and get working.
> >
> > Regards Geoff
> >
> >
> >
> >> Date: Tue, 5 Nov 2013 17:07:42 -0800
> >> Subject: [ZeroBrane Studio] Re: couple of questions
> >> From: paul@xxxxxxxxxxxxx
> >> To: zerobrane@xxxxxxxxxxxxx
> >
> >>
> >> Hi Geoff,
> >>
> >> > I was a bit shocked to discover you had removed the standard Lua 5.1
> >> > Interpreter :(
> >>
> >> It has been replaced by LuaJIT, which is fully ABI compatible with Lua
> >> 5.1 while also providing some level of language compatibility with Lua
> >> 5.2. May I ask what you are missing in the current setup?
> >>
> >> > Could you point me at some instructions as to how I add that back in
> >> > please ?
> >>
> >> You have several options. One would be to get the old
> >> library/executable and use it instead of the current one. You can get
> >> all the binaries from one of the older versions of ZBS
> >>
> >> (https://github.com/pkulchenko/ZeroBraneStudio/tree/115924d56797f9d1f3a43df453a1cef8e9a1a581/bin).
> >> You can also install Lua interpreter to some other folder and
> >> configure ZBS to use it with path.lua setting
> >>
> >> (http://studio.zerobrane.com/doc-general-preferences.html#interpreter_path)
> >>
> >> My assumption was that users are not losing anything with this switch,
> >> but maybe I missed something.
> >>
> >> > A second more wacky question for you. How easy or difficult would it be
> >> > to modify ZBS so that its syntax colour highlighting was for a different
> >> > language other than Lua ? I am guessing this might be hidden away inside
> >> > the
> >> > Scintilla edit component you are using, so therefore would be very
> >> > awkward
> >> > to change ?
> >>
> >> Yes, it should be possible to get access to other lexers inside
> >> Scintilla. It should be a matter of connecting spec identifiers that
> >> ZBS recognizes with those defined in Scintilla lexers. I recently did
> >> something similar for c/cpp that you may use as a starting point
> >> (spec/cpp.lua).
> >>
> >> If you open .cpp file you should see that highlighting if you enable
> >> loading of spec files by adding this to the config file:
> >> load.specs(function(file) return file:find('spec[/\\]cpp%.lua$') end).
> >> I should probably change this to allow new specs to be loaded by
> >> default.
> >>
> >> You should still be able to use all the color themes and everything
> >> else color related.
> >>
> >> If you want to distribute this, you can wrap this into a plugin that
> >> uses ide:AddSpec and ide:RemoveSpec calls. This may be easier option
> >> as it eliminates the need to modify the config file and to provide
> >> multiple files. Let me know if you need an example on how this can be
> >> done.
> >>
> >> Paul.
> >>
>
Other related posts:
