2014-10-23 17:24 GMT+02:00 Sean P. DeNigris <[email protected]>:

> Thierry Goubier wrote
> > Once you
> > generate automatically, it's easy to hit them :P
>
> Besides the hard limits IIRC I also ran into weird unexpected issues like
> really long methods slowing Nautilus down to a crawl.


It's the styler. I hit that regularly on my home machine. You have that
delay when you type something and you wait for the few seconds necessary
for the styler to update the coloring :(


> Is there a library
> that can effectively take source code and break it up into a reasonable set
> of methods to avoid these issues? I think this could also be useful in a
> lot
> of places e.g. STON. I've been using a trick to distribute "data" which
> changes often in development but is read-only when deployed; I work with
> the
> live model and serialize to method source (like we do with icons I guess).
> I've had to use different strategies e.g. I favor STON but when porting to
> Amber, there is no STON, so I serialize to source code.
>

Well, I've written something but:
- I only tried and tested with the code that SmaCC generates
- It still makes long methods (900 nodes is a long method)
It could become a library, but it requires a significant amount of work. In
the general case, writing something which knows, without errors, than a
subset of a method can be moved in another method and replaced by a message
send is not that easy. The reverse is easier (i.e., inlining :)).

Thierry


>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Microframeworks-was-Re-Thank-you-so-much-for-Pharo-3-0-tp4786128p4786222.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Reply via email to