Microframeworks was: Re: Thank you so much for Pharo 3.0
Nice the hear indeed. I miss your posts! Pharo is indeed very stable. Doing everything on 3.0 here. Got a full week of clients demos done, never ever had to touch the server running the app. Even the guy doing the demos told me it never crashed on him (which wasn't that usual apparently). With the command line based tools that are now very doable, this makes for a serious contender. Now, for a bit of thread hijacking... We need to put more care in the datadabase sector, I've been bit by SQLite crashes with WeakRegistry sessions. Good thing is that I was to fix that on my own, which would be close to impossible with other toolchains. That's a key thing about Pharo: being able to debug quite deep and still grasp what's going on. Postgres works too. But APIs are really far apart and some alignment is required... That's a limiting factor for adoption, as DBs are really used in a lot of places. For getting traction, we also need some more quick tools. I like Teapot for example. It looks like close to Flask http://flask.pocoo.org/ Look at how easy it is to bang an app together: https://github.com/mitsuhiko/flask/tree/master/examples/minitwit https://github.com/mitsuhiko/flask/blob/master/examples/minitwit/minitwit.py We should have something like that. In the last hackathon, we go the top apps using this kind of tech. http://www.rtbf.be/info/medias/detail_trois-applications-primees-au-premier-... (french ahead)... I was in a team where we enhanced an existing thing (http://noselus.be for the interested). and was bit by SQLite trouble. No issue as I wanted to use Pharo in a new case, namely https://github.com/noselusbe/noselus-etl I believe we could have a Pharo microframework thing where people would not use the browser to code but a single script. Ha! Heretic! A file! Burn him! hum, yeah, but that's what people use and I also have a startup script for my apps. We could use that to "bootstrap people" into Pharo. Instead of a crappy debugger, they can then just pharo-ui Pharo.image and bam, a full IDE with all bells and whistles. 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 This would generate a WAComponent subclass with methods in it, register the thing and go for it. We can pack JSON support in there as the JsonObject support allows to really load and access Json easily. TIA for your feedback. Phil Phil On Thu, Oct 23, 2014 at 7:40 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
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 <marianopeck@gmail.com> 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, phil@highoctane.be 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
On Thu, Oct 23, 2014 at 8:17 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 23/10/2014 08:09, phil@highoctane.be 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.
Well, I meant "a file like this in Smalltalk" :-) Still, a cool idea of yours!
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/
Phil
Thierry
Le 23/10/2014 08:23, phil@highoctane.be a écrit :
On Thu, Oct 23, 2014 at 8:17 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 23/10/2014 08:09, phil@highoctane.be <mailto:phil@highoctane.be> 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/minitwi... <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!
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
On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 23/10/2014 08:23, phil@highoctane.be a écrit :
On Thu, Oct 23, 2014 at 8:17 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Le 23/10/2014 08:09, phil@highoctane.be <mailto:phil@highoctane.be> 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!
That in Smalltalk may be better, especially to induce people to extend it with Pharo afterwards :)
That's the idea indeed.
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.
How long is long? Now, the point is to see all that as a stream, cut methods at appropriate places and compile code under a WAComponent subclass. I don't know about SmaCC but I think I can do something with PetitParser and Smalltalk compile: Phil
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, phil@highoctane.be a écrit :
On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier <thierry.goubier@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
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
On Thu, Oct 23, 2014 at 9:36 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 23/10/2014 09:18, phil@highoctane.be a écrit :
On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier <thierry.goubier@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
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.
Thanks for the pointers, I'll look into that. In the meantime, I put together a starting point (using your merge driver as an inspiration ;-) ). https://github.com/philippeback/Bubble clone it, make ./bubble --app blah.bubble (if one is on centos6.5, make centos) Check the makefile, I made everything load from filetree and rename the image with another name than a bland "Pharo.image" Phil
Thierry
Hi Thierry, On Oct 23, 2014, at 12:36 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 23/10/2014 09:18, phil@highoctane.be a écrit :
On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier <thierry.goubier@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? 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
2014-10-23 16:38 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Thierry,
On Oct 23, 2014, at 12:36 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 23/10/2014 09:18, phil@highoctane.be a écrit :
On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier <thierry.goubier@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
2014-10-23 16:38 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Thierry,
On Oct 23, 2014, at 12:36 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 23/10/2014 09:18, phil@highoctane.be a écrit :
On Thu, Oct 23, 2014 at 8:42 AM, Thierry Goubier <thierry.goubier@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
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... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Thursday, Oct 23, 2014 at 5:27 pm, Sean P. DeNigris <sean@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
2014-10-23 17:36 GMT+02:00 Marcus Denker <marcus.denker@gmail.com>:
On Thursday, Oct 23, 2014 at 5:27 pm, Sean P. DeNigris < sean@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.
Cool. I'll have a look to integrate that. Thierry
Marcus
2014-10-23 17:24 GMT+02:00 Sean P. DeNigris <sean@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-0... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (6)
-
Clément Bera -
Eliot Miranda -
Marcus Denker -
phil＠highoctane.be -
Sean P. DeNigris -
Thierry Goubier