Smalltalk - Re: Microframeworks was: Re: Thank you so much for Pharo 3.0

Smalltalk › Pharo › Pharo Smalltalk Developers

Re: Microframeworks was: Re: Thank you so much for Pharo 3.0

Posted by Thierry Goubier on Oct 23, 2014; 3:36pm
URL: https://forum.world.st/Microframeworks-was-Re-Thank-you-so-much-for-Pharo-3-0-tp4786128p4786228.html

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

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.