#594

My bad, I hadn’t seen the issue. This is a bit more complex than I thought.

#596

What is the best way to include a relative file in a project repo, when you don’t know the name of the folder in which you are?

#597

the global include() function, checks in dust/code and in the directory of the last loaded script.

#598

but this does work with a file like a lib relative nested directory?

(I can’t find references to the various require/include conversations from 2.0 beta)

#599

no, you’re right, it’s limited.

i don’t think it’s really possible for a chunk of lua code to know what file it came from, even if we hack the lua interpreter. (matrron/src/lua_eval.c)

the chunk is just a string compiled to bytecode. the string could be from anywhere.

that’s why we have the dust/code convention (_path.code global, a constant) and the concept of “current working directory” (norns.state.path global - updated when script is loaded)

#600

I think what we’re chasing here is a convention in some scripts to use require - which needs more of a path, vs include which can be relative (I think)

local MeadowPhysics = require "meadowphysics/lib/meadowphysics"
vs
local MeadowPhysics = include("lib/meadowphysics")

The top one MUST be in a directory named meadowphysics. The bottom one seems to work but does not have the directory name problem.

See this mention for background.

EDIT - also the Dust 2.0 wiki is somewhat confusing on this because it interchangeably uses require and include - which should be mentioned as different things.

Also also - is dofile preferred over loadfile?

#601

agreed. i think i’ve said this, but we should really discourage require. we use it in core libs, but in scripts it is a pointless optimization and actually hinders development of user libraries. (b/c caching)

3 Likes
#602

they do different things: dofile parses and executes, loadfile parses and returns a function but doesn’t execute.

loadfile does allow for better error handling if the file failed to parse. (it actually has two return values - an unusual feature of lua - a function and an error.) so we could make better use of this in include().

1 Like
#604

i was under the assumption that our design of include accommodated the standard use case for using libs.

can someone explain to me the use case that it does not accommodate?

#605

to be clear, i don’t think there’s anything wrong with the way include() works, but the conventions and assumptions could maybe be more explicit.

namely:
include('foo') assumes that one of these exists:
~/dust/code/foo.lua
or
~/dust/code/last_script_parent_dir/foo.lua

so far i’ve seen both of the following more than once, which don’t work:

  • installing scripts somewhere besides ~/dust/code (e.g. ~/norns/lua/ - don’t put scripts there, it’s for system stuff)
  • trying to include('foo') from ~/dust/code/baz/foo.lua when the current script is in ~dust/code/bar (instead, include('baz/foo'))
#606

When I load a different engine.load('Why'), it doesn’t update engine.name, but I feel like it should. Any thoughts on this?

Also, what is the proper way to outload an engine, for example, self-playing engines like Why and SineTest, will keep on playing after a new engine has been loaded, some engines have removeVoice, but not all?

What is the right way to handle this, see context.

#607

6 posts were merged into an existing topic: Norns: Development

#608

Is there an issue with the script reference for include()? The docs says:

include('lib/somelib.lua') will first look in the directory of the current script. This allows using relative paths to use libraries local to the script.

My current folder structure:

script.lua
lib/
  target.lua

In script.lua, include('lib/target.lua') results in:

including /home/we/dust/code/lib/target.lua.lua
### SCRIPT ERROR: load fail
cannot open /home/we/dust/code/lib/target.lua.lua: No such file or directory

It seems like if .lua is present in the include’s filename, it adds it again.

#609

This is true and the doc is incorrect

#610

include attempts to follow the syntax of require (which is a builtin)

1 Like
#611

What would be the easiest way to get a 3d perlin noise function in a lua script? Is it possible to expose the Perlin3 function of Supercollider or embed a C file?

#612

Here’s an example where I use a few functions similar to Perlin3 (Brownian, Lorenz, and a few others) in SuperCollider that then effect Lua code via polls:

It and it’s accompanying lua code is a big mess right now, I’d love to wrap it up into a shareable modulator library at some point.

5 Likes
#613

seems like just… coding it up in lua? would be the most straightforward.

#614

When I tried to use a Perlin noise function I found a gist of in Lua at 15fps it ended up causing the controls and menu to get a little unresponsive. It could have been particularly inefficient or just be the cumulative effect of a lot of stuff I was doing in the draw loop, but things felt a lot snappier after I pushed it to SC and used a poll.

#615

Yea that makes sense too. I can imagine a naive LERP in lua being pretty rough

e.g., people forget that the # operator loops over the table!