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

Mariano,

It is good to hear from you, and it is even better to hear such nice words. Thanks you !

I think that in general, in our day to day struggles, people underestimate just how good Pharo is and how useful it is to do real work in the real world, in other words, to be successful.

Do we already have your story as a 'success story' for the website ?

Sven

> On 23 Oct 2014, at 03:15, Mariano Martinez Peck <[hidden email]> wrote:
>
> Hi guys,
>
> I just wanted to share my happiness with you. I joined a team 2 years ago almost to develop a Seaside 3.0 app, using and old Magritte version, and Pharo 1.4. As soon as I started, I created a ConfigurationOfMyApp, and migrated to Pharo 2.0.
>
> That worked fine for almost 2 years. Since several weeks/months, I wanted to update to new Seaside versions and Pharo. Of course, you never have time, there are always other problems to fix first, etc...But 10 days ago, I stopped everything, and I migrated to Seaside 3.1.3, latest Magritte, latest Bootstrap (very very cool project too...we are using it everywhere), latest everything...and... of course...Pharo 3.0!!!   Also..the "port" was almost nothing...everything almost worked out of the box. Thanks to contributors maintaining great softwares like Metacello and all existing configurations.
>
> Btw...I am also deploying my app in GemStone since almost  an year, and this also is being good. Gemstone people also have a great support via mailing list which I very much appreciate.
>
> I played with Pharo 3.0 when it was released and some time also before that. But not that much. Now..I am using the very same image since at least 10 days. Working full time. All my projects are working great. I cannot believe so good it feels developing in Pharo 3.0. I am using the great Dark Theme from Esteban. Everything is super fast, super nice, super stable. And with my 2.0 images..they always grew too much (up to 500MB), that everything started to be very very slow. I needed to start again with a fresh image, etc. This 3.0 image has almost the same size as I started and continues to be super fast.
>
> So...I cannot repeat myself how good Pharo 3.0 feels. I should have migrated long ago. Thanks all the contributors and developers for such a great and professional product.
>
> Best,
>
> --
> Mariano
> http://marianopeck.wordpress.com

Le 23/10/2014 08:09, [hidden email] a écrit :

How hard would it be to parse such a file with this kind of content?

https://github.com/mitsuhiko/flask/blob/master/examples/minitwit/minitwit.py

Not hard. A bit of work on PythonParser2.

This would generate a WAComponent subclass with methods in it, register
the thing and go for it.

The level of Python in it look not too difficult to convert. But it relies on a framework for which I can't answer. What is jinja ?

Thierry

Le 23/10/2014 08:23, [hidden email] a écrit :

On Thu, Oct 23, 2014 at 8:17 AM, Thierry Goubier
<[hidden email] <mailto:[hidden email]>> wrote:

    Le 23/10/2014 08:09, [hidden email] <mailto:[hidden email]>
    a écrit :

        How hard would it be to parse such a file with this kind of content?

        https://github.com/mitsuhiko/__flask/blob/master/examples/__minitwit/minitwit.py
        <https://github.com/mitsuhiko/flask/blob/master/examples/minitwit/minitwit.py>


    Not hard. A bit of work on PythonParser2.


Well, I meant "a file like this in Smalltalk" :-) Still, a cool idea of
yours!

... [show rest of quote]

That in Smalltalk may be better, especially to induce people to extend it with Pharo afterwards :)

But Pharo has issues with long methods (such as a single, long file). I wrote some code to split methods for SmaCC at the AST level (parse, split, create sub-methods, replace code with call to method, compile), but it works in SmaCC generated code; I didn't really try to make it general.

        This would generate a WAComponent subclass with methods in it,
        register
        the thing and go for it.


    The level of Python in it look not too difficult to convert. But it
    relies on a framework for which I can't answer. What is jinja ?

Jinja is the template engine: http://jinja.pocoo.org/

Ok,

Thierry

Le 23/10/2014 09:18, [hidden email] a écrit :

On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier
<[hidden email] <mailto:[hidden email]>> 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

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

Hi Thierry,

On Oct 23, 2014, at 12:36 AM, Thierry Goubier <[hidden email]> wrote:

> Le 23/10/2014 09:18, [hidden email] a écrit :
>>
>> On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier
>> <[hidden email] <mailto:[hidden email]>> 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?

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
>

Hi Thierry,

On Oct 23, 2014, at 12:36 AM, Thierry Goubier <[hidden email]> wrote:

> Le 23/10/2014 09:18, [hidden email] a écrit :
>>
>> On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier
>> <[hidden email] <mailto:[hidden email]>> 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?

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
>

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-0-tp4786128p4786222.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On Thursday, Oct 23, 2014 at 5:27 pm, Sean P. DeNigris <[hidden email]>, 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