October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Microframeworks was: Re: Thank you so much for Pharo 3.0

by Thierry Goubier

2014-10-23 17:24 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > 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-… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 23, 2014

Re: [Pharo-dev] Microframeworks was: Re: Thank you so much for Pharo 3.0

by Marcus Denker

On Thursday, Oct 23, 2014 at 5:27 pm, Sean P. DeNigris <sean(a)clipperadams.com>, wrote: 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. This is a problem of the TextEditorâ¦ The Rubric editor code that is now in the system that GTInspector uses does not have this problem, it can edit multi-MB files with no problem. Â Â Marcus

Oct. 23, 2014

Re: [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

by Sean P. DeNigris

Sean P. DeNigris wrote > http://youtu.be/vsCz7UKLqLo?list=PLn0YRc8Nw9kvQiLg82JBuI5sDRYXfEDu2 (skip > to 0:40). Oh cool, you can link to a specific start time in youtube... http://youtu.be/vsCz7UKLqLo?list=PLn0YRc8Nw9kvQiLg82JBuI5sDRYXfEDu2&t=0m40s ----- Cheers, Sean -- View this message in context: http://forum.world.st/Clickable-class-side-example-and-initialize-methods-i… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 23, 2014

Re: [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > I was thinking earlier that it should be possible to extend this even for > messages with arguments by just asking for them. Like this? ;) http://youtu.be/vsCz7UKLqLo?list=PLn0YRc8Nw9kvQiLg82JBuI5sDRYXfEDu2 (skip to 0:40). ----- Cheers, Sean -- View this message in context: http://forum.world.st/Clickable-class-side-example-and-initialize-methods-i… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 23, 2014

Re: [Pharo-dev] Microframeworks was: Re: Thank you so much for Pharo 3.0

by Sean P. DeNigris

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. 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. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Microframeworks-was-Re-Thank-you-so-much-for-Pharo-3-… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 23, 2014

Re: [Pharo-dev] Microframeworks was: Re: Thank you so much for Pharo 3.0

by Thierry Goubier

2014-10-23 16:38 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Thierry, > > On Oct 23, 2014, at 12:36 AM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > Le 23/10/2014 09:18, phil(a)highoctane.be a Ã©crit : > >> > >> On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier > >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > >> > >> > >> How long is long? > > > > 900 nodes in the AST seems to be the limit for the type of method SmaCC > generates (cascading ifTrue:ifFalse:). > > > > Other limits exist (number of literals, for example). Unless you > generate automatically some code, it's hard to hit them. Once you generate > automatically, it's easy to hit them :P > > Spur and Sista together lift these limits. Spur provides 64k literals per > method and Sista uses a bytecode set with effectively unlimited jumps. We > could possibly deploy the Sista bytecode set before the Sista optimizer. > Would you be interested in being a guinea pig? > Well, why not. I'm a bit behind stuff I have to do (should have done :() and I certainly have some code to test: probably all the SmaCC generated scanners have a scanToken method which is jump limited. If you want to have a look, SmaCC (development version) in Pharo has a SmaCCSmalltalkCodeGenerator>>maxMethodLength which control the process. A good test would be to use the PythonParser, recompile it (LALR) and run the python tests. Thierry > > Eliot (phone) > > > > >> Now, the point is to see all that as a stream, cut methods at > >> appropriate places and compile code under a WAComponent subclass. > > > > Yes. But then you need some kind of syntax to mark the start of a > method. Change sets and dolphin packages use !! markers. > > > >> I don't know about SmaCC but I think I can do something with PetitParser > >> and Smalltalk compile: > > > > It's all done with RBParser. Since you're parsing Smalltalk, it's easier > to do it that way (and probably a bit faster). And you're also playing with > the AST, so you want to fall back to a well defined API for that AST (and > visitors, and the like). > > > > Extending RBParser with a scheme to parse multi-methods files could be > convenient. > > > > Unless you fall back on a variant of a changeset. > > > > Thierry > > > >

Oct. 23, 2014

Re: [Pharo-dev] Microframeworks was: Re: Thank you so much for Pharo 3.0

by ClÃ©ment Bera

2014-10-23 16:38 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Thierry, > > On Oct 23, 2014, at 12:36 AM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > Le 23/10/2014 09:18, phil(a)highoctane.be a Ã©crit : > >> > >> On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier > >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > >> > >> > >> How long is long? > > > > 900 nodes in the AST seems to be the limit for the type of method SmaCC > generates (cascading ifTrue:ifFalse:). > > > > Other limits exist (number of literals, for example). Unless you > generate automatically some code, it's hard to hit them. Once you generate > automatically, it's easy to hit them :P > > Spur and Sista together lift these limits. Spur provides 64k literals per > method and Sista uses a bytecode set with effectively unlimited jumps. We > could possibly deploy the Sista bytecode set before the Sista optimizer. > Would you be interested in being a guinea pig? > > I want that too. If we deploy it we will deploy it for the Pharo 4 anyway. I thought we'll move to spur then to the new bytecode set because some sista bytecode (traps, inlined primitives, ...) will only work with Spur. We won't spend time implementing and stabilizing them for V3. > Eliot (phone) > > > > >> Now, the point is to see all that as a stream, cut methods at > >> appropriate places and compile code under a WAComponent subclass. > > > > Yes. But then you need some kind of syntax to mark the start of a > method. Change sets and dolphin packages use !! markers. > > > >> I don't know about SmaCC but I think I can do something with PetitParser > >> and Smalltalk compile: > > > > It's all done with RBParser. Since you're parsing Smalltalk, it's easier > to do it that way (and probably a bit faster). And you're also playing with > the AST, so you want to fall back to a well defined API for that AST (and > visitors, and the like). > > > > Extending RBParser with a scheme to parse multi-methods files could be > convenient. > > > > Unless you fall back on a variant of a changeset. > > > > Thierry > > > >

Oct. 23, 2014

Re: [Pharo-dev] .source file

by Sven Van Caekenberghe

Have you tried using two fake empty files ? If you are sure they are not used, that should work, right ? Or you could try hacking SourceFileArray>>#ensureOpen > On 23 Oct 2014, at 16:38, Hilaire <hilaire(a)drgeo.eu> wrote: > > For information, a iStoa user reported to me this problem, related to a > Pharo regression I already discussed about here > https://bugs.launchpad.net/istoa/+bug/1384649 > > I see this related bug report: > https://pharo.fogbugz.com/f/cases/10464/Always-warn-when-sources-or-changes… > > So what is the plan regarding source code, will we be forced to ship it. > It is untrue disk space is cheap, especially for desktop or tablet > application. > > Hilaire > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > >

Oct. 23, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40322 Home: https://github.com/pharo-project/pharo-core

Oct. 23, 2014

[pharo-project/pharo-core] 3fb395: 40322

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3fb395920c4a046dceda568c95d6450f4078572a https://github.com/pharo-project/pharo-core/commit/3fb395920c4a046dceda568c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-10-23 (Thu, 23 Oct 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script322.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40322.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Support.package/VirtualMachine.class/instance/testing/isSpur.st Log Message: ----------- 40322 14298 pre for 14297 Kernel fixes for Spur https://pharo.fogbugz.com/f/cases/14298 http://files.pharo.org/image/40/40322.zip

Oct. 23, 2014