[Fluxus] couple of editor fixes

evan.raskob [lists] lists at lowfrequency.org
Wed Apr 27 12:33:52 PDT 2011


Ok, since you're deep in the editor...

There's a lot that needs to be done to get it working as a proper editor, IMHO.

I thought about it... and then the time needed to do it put me off.  Really, I would think that we need a much better approach to handling characters than just an array of chars, we should really have a character object that can also have color for each individual character, and probably other properties as well (font?), and then a character holder object (like an array) that wraps these smart characters and adds functionality, and then string matching/replacing/etc functions on top of that.  Also, we should keep track of edits so we can implement undo in successive stages.  Fun!  Until we get any real infrastructure done on the editor, or more importantly, until we decide that it is a priority and *should* be done (something that may be controversial?  Dave?) I'd discourage anyone from doing any real hacking on the C++ side of things, what's the point? (Besides adding some neat experimental functions like that code auto-selector Kassen just did)

That's just my opinion, take it or leave it.

Best,
Evan

 

On 27 Apr 2011, at 20:19, Kassen wrote:

> There seems to be a problem related to this stuff.
> 
> I was just playing some more with that "editor". Calling "(clear)" from there predictably leads to a error; 
> 
> Renderer::PopState : only one state left, not popping
> 
> I'm not sure that's the expected error but that's what I get. Then restarting the editor script leads to a Fluxus crash soon after. I was able to repeat this three times and wasn't able to get a crash just based on playing with text in the "editor". Of course that's only a very coarse analysis. The crash will give either this;
> 
> TypePrimitive::TypePrimitive: could not load font: /usr/local/share/fluxus-017/
> material/fonts/DejaVuSansMono.ttf
> Aborted
> 
> or this;
> 
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc
> 
> or some combination. Might be related to the issues with memory usage of strings and operations on them that we saw a while back?
> 
> Yours,
> Kas.




More information about the Fluxus mailing list