#164

And this is why I am not writing code (at a deep level) until some of these failsafe issues are addressed. I’m just not accomplished enough a coder to risk it.

#165

i’m not settled on what the right thing to do is here but agree with you that something would be better than nothing. minimally a warning? if you’re curious, i started playing with an idea for a script-loading hack that could be used to monitor / police global access.

it’s kind of a babystep to sandboxing which is a pretty attractive ultimate solution. (caveat: i’ve done only a wee bit of testing. enough to make me think the idea has legs but i’d value input from folks who know their way around better than i do.)

ouch! curious where? (or maybe don’t say it or i won’r be able to resist doing it myself :wink: .)

fwiw: this is a strong argument for considering getting git setup on your norns. probably easier / less disruptive to ssh in and do a git revert than apply an update…

1 Like
#166

yeah, should get git setup on norns!

it was in arc.lua, in Arc:refresh() - i imagine you’d have a similar result with grid.lua

#168

Would be great if this was part of the image! I can also imagine maiden menu items that run git commands.

3 Likes
#169

so i guess you then have a syntax error in the default script, which gets run on startup. i’m surprised this would make the menu unresponsive.

nvmd, i really can read. you were modifying system modules. if you are doing this you really need to be prepared for matron to hang on an error. which means:

in case that does happen, the thing to try is:

  • connect over the serial port with screen
  • revert the change
  • reboot
4 Likes
#170

really think the way forward is to create a new environment for each script launch, populated with everything in _G (or a subset, if we want to restrict things.)

sticking point is REPL eval. by default each REPL chunk actually has its own scope. but there has to be an easy way to specify an env when evaluating a chunk, so pass the same env as used for current script.

( in fact yeah, just set _ENV right?
http://leafo.net/guides/setfenv-in-lua52-and-above.html )

i’m sorry that i’ve been such an armchair coder last couple weeks. day job. but this is something i should be able to manage implementing if no-one else can sneak it in…

1 Like
#171

When you talk about a new environment are you talking about creating a new lua_State with lua_newstate?

Am I right in thinking that is de facto an independent Lua interpreter then?

What would we do? Have a Matron lua_State and a script lua_State? With the script state being destroyed and re-created each time a script is started?

1 Like
#172

nah, i mean global vars in lua are just stored in a special table (called _G). and in lua 5.2+, the environment is an upvalue that shadows this, called _ENV, and acts as the current “namespace” for globals. you can just use a different value for _ENV to execute a given chunk.

http://lua-users.org/wiki/EnvironmentsTutorial

(in the same LVM)

lua is primarily a scripting language, so this mechanism is there for exactly this kind of thing - preventing scripts from accessing stuff in the global table that would let them mess things up. (like, say, os.execute("rm -rf ~").)

3 Likes
#173

Hi All, how risky is it to install other programs into norns on the command line? Is there a “factory reset” procedure if I end up completing messing up my norns image?

#174

(a slight clarification on the angle i’m proposing above — pardon me if unnecessary, and especially if i’m just muddying the waters!)

the trick i’m exploring is to define a new env that proxies _G. for practical purposes the proxy contains stuff from _G in the sense that it can choose to forward accesses on to it. the rub is it needn’t forward them. for example, an attempt to write to g (currently the shared grid instance) could be blocked and a warning issued. in this way a proxy can both protect the sanity of the global environment and the sanity of a specific script. (sorry if this is too fine a point; time for :coffee:!)

totally. this is the big thing to figure out. i’d be curious if @ngwese has any insights.

1 Like
#175

in a pinch you can always re-image [1]. it’s linux. i say go for it. (@tehn et al may have more sober advice though! :wink:)

[1] instructions here. really not a big deal, though now i’m not sure where the latest is getting posted… anyone remember? (should update the readme probably.)

#176

to be clear to anyone reading this— it’s pretty difficult to break the norns with a normal user script. don’t be afraid of programming this machine.

i need to get an updated disk image uploaded, but @ppqq’s link is what you want.

2 Likes
#177

sorry - i should’ve clarified in my post it was one of the system lua scripts!

curious though why executing ./waf didn’t catch this? is there some validation that is done for user scripts that could also be done for system scripts?

#178

Don’t answer this if it’s too complex/time consuming.

But why not have separate Lua states for the system and for user scripts?

Is there some architectural reason that I haven’t thought through? Or is it just too much sunk cost into the current method (i.e. not worth the time and effort).

#179

the latter I guess? Sounds like would require both VMs calling down into C whenever they need to share state.

One early proposal was to do all system and menu stuff in C. But we didn’t go that way mostly with an eye towards more flexibility, easier customization, lower barrier to contributions

2 Likes
#180

So I’m not too sure where to post this, hoping this is the correct place?
While I daydream until my second batch norns arrives…
Im wondering if anyone has got norns to work with usb midi - cv interfaces?
Im particularly interested in having an 8 track kria setup sequencing say norns on one track and the rest sequencing my modular.
I guess this is two topics.
norns talking usb midi and enhancing kria.
Anyway, super excited to get on board and this is just one application I’m dreaming about on top of all the other awesome stuff I’m seeing norns doing!

#181

Sorry for the big delay in confirming, I’ve been traveling for several weeks and on my first day out of the country my laptop flat-out died. So much for the hacking in hotel rooms that I’d planned. :frowning: I was able to resuscitate an ancient laptop this weekend when I got back.

It was super-easy to get norns broadcasting to a Teensy over USB serial. This should be perfect for my experiments - assuming that I can figure out a simple way to identify which serial device I want to send to. I quickly found a few ways to enumerate (one pictured below) - but identifying the proper one seems to be the trick.

local p = io.popen('dmesg | grep tty')     
   for file in p:lines() do 
       print(file)       
   end

Heading out of the country again today with fingers crossed I’ll be able to play and figure this out. :slight_smile:

I was also thinking about implementing this Arduino/Teensy OSC Library and communicating using OSC for fun. It looks like there will be some serial transport stuff to figure out and some unwinding the current code’s assumptions that OSC = Grid (or now Arc with @scanner_darkly’s contribution).

Anyone play with OSC stuff yet?

Thanks again for the quick hints @zebra, just what I needed. :slight_smile:

2 Likes
#182

just real quick, norns doesn’t use OSC for talking to grid controllers, uses serial protocol directly via libmonome.

again, assumption it makes is that tty == monome controller; obvs not a good one; is that what you mean?

other tty devices should just be ignored at the moment. so yeah, use lua file I/O for experimenting.

if you do want to build out generic serial-OSC functionality, might be good to add it to the C side device manager, so hotplug / device detection can work alongside other usb devices. problem i see there is just being able to recogize when a device wants serial-OSC.

1 Like
#183

Oops. I misunderstood the Grid protocol in the discussion above and assumed OSC. Thanks for the clarification.

I’ll play with some serial stuff for a bit. There is enough here for me to rock and roll on for a while. Given that the devices and firmware I’m planning to connect with are i2c based, the protocol will translate pretty well to arrays of bytes. OSC would be overkill at the moment - though it is intriguing to think about getting it working. :slight_smile:

Thanks again!

1 Like
#184

I hacked together a TouchOSC grid and modded a couple scripts to work (more or less).

But… Then I went down a different rabbit-hole so I should circle back to this soon.

3 Likes