search

lowne / xCodea

a live execution environment for large Codea projects
12 stars 1 forks source link

Non-Conformal Behaviour of 'parameter' Class in xCodea #2

Open elian opened 10 years ago

elian commented 10 years ago

Hi,

During testing of xCodea with one of my projects, I observd the following differences in behaviour of xCodea compared to the project run in Codea:

Note: I am using LDT for project edit on OS X 10.9.2 and xCodea runs on an iPad2.

1) If a 'parameter.number' variable is changed in running code (not through the GUI), the GUI doesen't follow the chanched value as it happens in standard Codea.

Thanks, Elian Epstan

lowne commented 10 years ago

Implemented in the latest commit, lemme know if it works as expected. (gotcha: apparently parameter.text stops working after an xCodea.restart() - please share your findings)

elian commented 10 years ago

Hi,

The test with the new xCodea implementation for 'parameter' table was working as expected. With following exceptins:

First test:

If sending 'xCodea.restart()' through eval.luac from xCodea server, the 'parameter.number' variable was reset to defined min value (and not defined initial value as expected). Same happend for 'parameter.text' whos value defaulted to empty string, not the defined initial string value.( For me it looks like the parameter calls in setup() do not execute from some reason.)

Also, the 'internal' parameter variable seams to be disconnected from its respective global variable (changes of the parameter var in Codea sidebar do not reflect themselves in their respective global variable and vice-versa).

Second test:

Loading 'xCodea.restart()' through cli in Codea sidebar generates same behaviour as described earlier, except that parameter.text HAS conection between its 'internal' and its global variable.

Then, I have put in setup() new code - parameter.clear() - before declaring any 'parameter.*', and repeated the two above tests with 'xCodea.restart()'.

First test - sending 'xCodea.restart()' through eval.luac: The parameter values initialised as expected and behaved as espected, except for parameter.text which initialized as expected but the didn't have a connection between its 'internal' and its global variable.

Second test - loading 'xCodea.restart()' through cli in Codea sidebar: Everything works as expected (including parameter.text).

Tanks and regards, Elian

lowne commented 10 years ago

This is some fantastic testing! The parameter.clear() thing makes total sense (I had spent some time wondering what crazy hack I could use to invalidate parameter.*'s "internal" variables... duh!) And more importantly, xCodea.restart() from eval.luac was running inside the sandbox ... whoops! Both are fixed in the latest commit (assets branch). This time everything should work! (fingers crossed)