OpenEndedGroup / Field

A development environment for art
201 stars 22 forks source link

Too many tweaks causes runtime error. #22

Closed highfellow closed 11 years ago

highfellow commented 11 years ago

I'm getting the error: python exception <java.lang.RuntimeException: Method code too large! after applying a large number of tweaks to a simple one segment FLine. There seems to be a maximum number of tweaks my system can handle. If I revert to an earlier save then make the tweaks again, the error re-occurs.

It would be useful if there was a function you could call on an FLine which simplified the tweaks code once you'd finished editing. I.e. apply every change in the tweak history, and replace with a smaller set of tweaks that go straight from beginning to end.

My system is a 64 bit PC running ubuntu linux 12.04. It has 4Gb of memory.

highfellow commented 11 years ago

If you could suggest some workaround code that I could run in the spline drawer that would have the effect of reducing the tweaks code on an element to a minimum set, that would be really useful. I'm liking field a lot from what I've seen so far, but it's pretty disheartening to see your nicely formed FLine collapse into a single straight line with no obvious way to recover it.

marcdownie commented 11 years ago

There are three things here:

  1. We ought to be able to avoid the Method code too large error. For all tweaks that Field generates, we could just feed the code to Jython in small incremental chuncks.
  2. I suspect that "Compressing" tweaks to a small set is somewhere between hard and very, very hard.
  3. We should make it clearer that the post-tweaks geometry is actually what gets stored in _self.lines (after tweaks is run). So you could just remove the code you have to generate your lines, delete tweaks, save off the bits of _self.lines that you are interested in, and keep going with some more modifications of those FLines.
  4. I'll fix in the next push.

On Tue, Feb 5, 2013 at 9:12 AM, Andrew Baxter notifications@github.comwrote:

If you could suggest some workaround code that I could run in the spline drawer that would have the effect of reducing the tweaks code on an element to a minimum set, that would be really useful. I'm liking field a lot from what I've seen so far, but it's pretty disheartening to see your nicely formed FLine collapse into a single straight line with no obvious way to recover it.

— Reply to this email directly or view it on GitHubhttps://github.com/OpenEndedGroup/Field/issues/22#issuecomment-13133541.

highfellow commented 11 years ago

Thanks for the quick reply(s).

  1. would be useful for me, as I keep getting this error.
  2. I thought would be easier than it obviously is - you know the code.
  3. It would be handy if you could document a recipe for doing this, as it's not quite clear to me from reading your post.
highfellow commented 11 years ago

Specifically, I'm not sure what you mean by 'save off the bits of _self.lines you're interested in'.

Do you mean removing the line code then saving the file as normal, or something more involved like pickling the FLine structures to a separate file on disk?

highfellow commented 11 years ago

I've just tried pickling the line to a file, and I get:

pickle.dump(_self.fracDef["line"], open("trunk.pickle", 'wb'))

python exception <TypeError("can't pickle CachedLine objects",)>
on line 1 trunk / <module> 
from line 1362 /usr/local/src/Field/Contents/linux/../lib/python/pickle.py / dump 
from line 224 /usr/local/src/Field/Contents/linux/../lib/python/pickle.py / dump 
from line 306 /usr/local/src/Field/Contents/linux/../lib/python/pickle.py / save 
from line 69 /usr/local/src/Field/Contents/linux/../lib/python/copy_reg.py / _reduce_ex 
highfellow commented 11 years ago

I've now written some code which successfully saves and loads FLines to/from separate files, which I'm now using as a workaround for this bug. I've put it on my wiki in case anyone else finds it useful:

http://highfellow.org/field:linesaver

marcdownie commented 11 years ago

Many thanks for the example! (Nice trees, by the way).

I was referring to the fact that geometry is saved with the sheet in properties (the computation that gets you the geometry, including the tweaks isn't run every time you open the file). So, if you don't care about having the line in a separate file:

_self.lines.clear()
a =FLine()
a.moveTo(10,10).lineTo(20,30)
_self.lines.add(a)
_self.tweaks()
_self.initialState = _self.lines[0].duplicate()

After running this, you can delete this code, and just start with _self.initialState rather than a. _self.initialState is saved with the box to disk. What we really should do is expose Field's internal serialize for geometry so that it's easily used from inside Field to make separate files.