[Pipmak-Devel] Named nodes - request for testing

[Christian Walther]

I just committed support for named nodes as revision 209. This is quite
an invasive change, but if I made no mistakes, it should be backwards
compatible with existing projects, unless they do weird things like
relying on node:getid() returning a number (it's a string now) or using
"../" in paths in different places than once at the beginning (its
semantics have changed, it's a real "up one level" command now).

Therefore, I'd appreciate if those who are set up for building from SVN
could check this out and run it through its paces with their projects,
to see if I broke anything. Updated documentation is available at
<http://pipmak.sourceforge.net/Reference.pdf>, to see what's changed
refer to
<http://pipmak.svn.sourceforge.net/viewvc/pipmak/trunk/pipmak/documentation/Reference.tex?r1=209&r2=208&pathrev=209>.

-Christian

[Aidan Gauland]

Works just the same for me. I'll start changing my project to make use of
this feature. This should make things much clearer (Lua code in particular).

Post by Christian Walther
I just committed support for named nodes as revision 209. This is quite
an invasive change, but if I made no mistakes, it should be backwards
compatible with existing projects, unless they do weird things like
relying on node:getid() returning a number (it's a string now) or using
"../" in paths in different places than once at the beginning (its
semantics have changed, it's a real "up one level" command now).
Therefore, I'd appreciate if those who are set up for building from SVN
could check this out and run it through its paces with their projects,
to see if I broke anything. Updated documentation is available at
<http://pipmak.sourceforge.net/Reference.pdf>, to see what's changed
refer to
<http://pipmak.svn.sourceforge.net/viewvc/pipmak/trunk/pipmak/documentation/Reference.tex?r1=209&r2=208&pathrev=209>.
-Christian

[Aidan Gauland]

Works just the same for me. I'll start changing my project to make use of
this feature. This should make things much clearer (Lua code in particular).

-Aidan

Post by Christian Walther
I just committed support for named nodes as revision 209. This is quite
an invasive change, but if I made no mistakes, it should be backwards
compatible with existing projects, unless they do weird things like
relying on node:getid() returning a number (it's a string now) or using
"../" in paths in different places than once at the beginning (its
semantics have changed, it's a real "up one level" command now).
Therefore, I'd appreciate if those who are set up for building from SVN
could check this out and run it through its paces with their projects,
to see if I broke anything. Updated documentation is available at
<http://pipmak.sourceforge.net/Reference.pdf>, to see what's changed
refer to
<http://pipmak.svn.sourceforge.net/viewvc/pipmak/trunk/pipmak/documentation/Reference.tex?r1=209&r2=208&pathrev=209>.
-Christian

[Andrea Viarengo]

Hi,

Good and bad news:

r209 works fine with old project (autocubic and forest gen. also),
but it have had little problems with a new one:

New project:

named-test.pipmak/main.lua
named-test.pipmak/first
named-test.pipmak/first/second
named-test.pipmak/first/second/node.lua
named-test.pipmak/first/second/face.png

main.lua:
-------------------------------------------
version (0.27)

title "named-test"
startnode ("first/second")
-------------------------------------------

node.lua:
-------------------------------------------
cubic {
"face.png", --front
"face.png", --right
"face.png", --back
"face.png", --left
"face.png", --top
"face.png" --bottom
}
-------------------------------------------


When I start the project, I enter in node

first/second: Ok

But now if I press "ESC", I get the error:

Error loading lua file "first/0/node.lua": file not found.

This error doesn't happen if I use only one level folder
(i.e.: startnode ("second") and I moved "second" out of "first")

If I have this structure:

1) ...first/node.lua
2) ...first/second/node.lua
3) ...second/node.lua

a) pipmak.gotonode("first") --now I am in (1)
b) pipmak.gotonode("second") --now I an in (3) not in (2)
c) pipmak.gotonode("first/second") --now I an in (2)

Is it correct this behaviour? Because it's different from
navigate into filesystem (I am expect to go into (2) with (b)

d) pipmak.gotonode("../") -- should it be possible? (doesn't work)
Error loading lua file "node.lua": file not found.

Now we put a node.lua in the same folder of main.lua

e) pipmak.gotonode("/") --it's works!
if I press "n" I get "We're at node" (without anymore)

f) pipmak.gotonode("/first/second") --ok
g) pipmak.gotonode("../") --now it's work, but I am in "/"
and not in "/first"

Now, delete node.lua in the same folder of main.lua
(I use command line to run lua)
h) pipmak.gotonode("/first/second") --ok
i) pipmak.gotonode("../") --error (not found)
press "n" --> We are at node -11
l) pipmak.gotonode("/second")
Now I get:
error running text editor handler:
-11/node.lua:76 calling selection on bad self.......

I hope this help you

Bye,

Andrea

[Christian Walther]

Post by Andrea Viarengo
When I start the project, I enter in node
first/second: Ok
Error loading lua file "first/0/node.lua": file not found.

Good catch - this is fixed in r210, thanks.

Post by Andrea Viarengo
1) ...first/node.lua
2) ...first/second/node.lua
3) ...second/node.lua
a) pipmak.gotonode("first") --now I am in (1)
b) pipmak.gotonode("second") --now I an in (3) not in (2)
c) pipmak.gotonode("first/second") --now I an in (2)
Is it correct this behaviour? Because it's different from
navigate into filesystem (I am expect to go into (2) with (b)

This is correct. This behavior is necessary for backwards compatibility
with projects that assume the old "flat" project structure. Or can you
think of a way of retaining backwards compatibility without this
exception (or worse exceptions)?

Is the note about this in the manual not clear enough? Or did you just
not read the manual (for which I wouldn't blame you, it's normal that
people don't read the manual, and if we can somehow be fault-tolerant in
this respect, all the better)?

Besides, apart from the fundamental disadvantage of being an exception
in the first place, I think this exception actually makes things easier
in the case that many (or all) nodes are in the same folder, which I
assume will be the usual case: it allows you to write
pipmak.gotonode("othernode") instead of pipmak.gotonode("../othernode").

Post by Andrea Viarengo
d) pipmak.gotonode("../") -- should it be possible? (doesn't work)
Error loading lua file "node.lua": file not found.

This should be possible (for the sake of completeness, if nothing else -
I'm not sure if it makes any real sense to have the root of the project
be a node itself). By "doesn't work", do you mean that there's a bug
here, in your opinion? In my opinion, this error message is correct, you
can't go to a node that doesn't have a node.lua (i.e. by definition
isn't a node).

Post by Andrea Viarengo
Now we put a node.lua in the same folder of main.lua
e) pipmak.gotonode("/") --it's works!
if I press "n" I get "We're at node" (without anymore)

OK, that last part is confusing. I added quotation marks around the node
name in r210, so even an empty node name comes out recognizably.

Post by Andrea Viarengo
Now, delete node.lua in the same folder of main.lua
(I use command line to run lua)
h) pipmak.gotonode("/first/second") --ok
i) pipmak.gotonode("../") --error (not found)
press "n" --> We are at node -11
l) pipmak.gotonode("/second")
-11/node.lua:76 calling selection on bad self.......

Whew. What happens is that after the failed loading of node "/", there's
no background node anymore because the old node has been left already,
so the Lua command line overlay drops down into the background node
slot. Therefore, when you call gotonode(), that node is left, and since
the Lua command line code isn't prepared for having its node taken away
from under it, you get the error message in the end.

This is clearly not good. In r211, I've changed the node loading
sequence so that the old node is only left after the new node has been
loaded successfully (entering the new node still only happens
afterward). When there are errors loading the new node, the old node is
not left but stays, avoiding the overlay-becoming-background. Hope this
works better.

Thanks for the meticulous testing!

-Christian

[Andrea Viarengo]

Yes,

You are right, if we want to maintain compatibility with old project, this
is the only (or simplest) way, I have understand.
I have read the doc very quickly...

I think the better way to doesn't make confusion is to use absolute paths,
and use relatives one for modules...

Now r211 seems ready to add modules...

Ok for rotation naming too.

Bye

Andrea