- Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Tim Mackinnon

Hi Guille - just running SpaceTally on my dev image to get a feel for it. It turns out that in the minimal images youâve been creating, its not loaded (makes sense). Iâm wondering if there is an easy way to import it in (I guess that package should be in the Pharo git tree I cloned to get Fuel loaded right? Or is there a separate standalone source?). Thanks for all the support, and your email about why the contexts stack up is very well received (I will comment over there). By the way - it looks like Martin Fowler picked up on this announcement - so maybe we might get some interest from his mass of followers. Tim > On 14 Aug 2017, at 10:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Tim, > > On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hey guys, thanks for your enthusiasm around this - and I cannot stress enough how this was only possible because of the work that has gone into making Pharo (in particular the 64bit image, as well as having a minimal image, and some great blog posts on serialising contexts) as well as the patience from everyone in answering questions and helping me get it all working. > > Iâm still quite keen to get my execution time back down under 800ms and Iâd like to actually get back to writing a few skills to automate a few things around my house. > > To Answer Denisâ question - > > My final footprint is 30.4mb - thats composed of a 22mb image (with a simple example that pulls in Fuel, ZTimestamp and the S3 Library which depends on XMLParser) and then the VM (from which I removed obvious dllâs). > > In my original experiments with a 6.0 minimal image - I did manage to get to a 13.4mb image (which started out as 12mb original size, and then loaded in STON and had only a simple clock example). I think the sweet spot is around 20mb total footprint as that seems to get me into the 450ms-900ms range. > > The 7.0 min image now starts out at 15mb and then Iâm not sure why loading Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not dug into that). > > You can do further space analysis using the following expression > > SpaceTally new printSpaceAnalysis > > You can do that in an eval and check what's taking space. With measures we can iterate and improve :). > > Iâve also found (and this on the back of unserialising the context in my example) that the way we build images has 15+ saved stack sessions that have saved on top of each other from the way we build up the images. I donât yet know the implications of size/speed of these - but we need a better way of folding executions when we snapshot headless images. Iâm also not clear if there are any other startup tasks that take precious time (this also has implications for our fat development images as they take much longer to appear than they really should). > > I'm working on this as I'm writing this mail ;) > > https://pharo.fogbugz.com/f/cases/20309 <https://pharo.fogbugz.com/f/cases/20309> > https://github.com/pharo-project/pharo/pull/196 <https://github.com/pharo-project/pharo/pull/196> > > I'll write down the implications further in a different thread. > > > Iâll be exploring some of these size/speed tradeoffâs in follow on messages. > > But once again, a big thanks - Iâve not enjoyed programming like this for ages. > > Tim > >> On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>> wrote: >> >> hi Tim, >> >> That is..... AWESOME! >> >> Very nice delivery - it flowed well with great narration. >> >> I loved @2:17 "this is the interesting piece, because PharoLambda has serialized the execution context of its application and saved it into [my S3 bucket] ... [then on the local machine] rematerializes a debugger [on that context]." >> >> There is a clarity in your video presentation that really may intrigue outsiders. As a community we should push this on the usual hacker forums - ycombinator could be a good starting point (but I'm locked out of my account there). >> An enticing title could be... >> "Debugging Lambdas by re-materializing saved execution contexts on your local machine." >> >> cheers -ben >> >> On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> This is cool Tim. >> >> So what image size you deployed at the end? >> >> 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> I just wanted to thank everyone for their help in getting my pet project further along, so that now I can announce that PharoLambda is now working with the V7 minimal image and also supports post mortem debugging by saving a zipped fuel context onto S3. >> >> This latter item is particularly satisfying as at a recent serverless conference (JeffConf) there was a panel where poor development tools on serverless platforms was highlighted as a real problem. >> >> In our community weâve had these kinds of tools at our fingertips for ages - but I donât think the wider development community has really noticed. Debugging something short lived like a Lambda execution is quite startling, as the current answer is âadd more loggingâ, and we all know that sucks. To this end, Iâve created a little screencast showing this in action - and it was pretty cool because it was a real example I encountered when I got everything working and was trying my test application out. >> >> Iâve also put a bit of work into tuning the excellent GitLab CI tools, so that I can cache many of the artefacts used between different build runs (this might also be of interest to others using CI systems). >> >> The Gitlab project is on: https://gitlab.com/macta/PharoLambda <https://gitlab.com/macta/PharoLambda> >> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E <https://www.youtube.com/watch?v=bNNCT1hLA3E> >> >> Tim >> >> >>> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>> >>> Hi - Iâve been playing around with getting Pharo to run well on AWS Lambda. Itâs early days, but I though it might be interesting to share what Iâve learned so far. >>> >>> Usage examples and code at https://gitlab.com/macta/PharoLambda <https://gitlab.com/macta/PharoLambda> >>> >>> With help from many of the folks here, Iâve been able to get a simple example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily try it out yourself. This seems slightly better than what the GoLang folks have been able to do. >>> >>> Tim >> >> >> > > > > > -- > > Guille Polito > > Research Engineer > French National Center for Scientific Research - http://www.cnrs.fr <http://www.cnrs.fr/> > > > Web: http://guillep.github.io <http://guillep.github.io/> > Phone: +33 06 52 70 66 13

Aug. 14, 2017

Re: [Pharo-users] including Pillar in Pharo image by default

by Esteban Lorenzano

again, I think this is a discussion for pharo-dev. Please keep it there (is good discussion, btw ;) ). What about my proposal of including a tiny PetitParser? (it would be âInfimeParserâ :P) Esteban > On 14 Aug 2017, at 11:10, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi Tim, > > The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books. > > The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text. > > Cheers, > Doru > > >> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far). >> >> My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway). >> >> Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown. >> >> >> Tim >> >>> On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi tim >>> >>> I personally do not care much about the syntax but I care about what I >>> can do with it >>> (ref, cite, ... ) >>> I cannot write books in markdown because reference to figures!!!!!! >>> were missing. >>> >>> And of course a parser because markdown is not really nice to parse >>> and I will not write a parser because I have something else to do. I >>> want to make pillar smaller, simpler, nicer. >>> >>> Now if someone come up with a parser that parse for REAL a markdown >>> that can be extended with decent behavior (figure reference, section >>> reference, cite) and can be extended because there are many things >>> that can be nice to have (for example I want to be able to write the >>> example below) and emit a PillarModel (AST) we can talk to have >>> another syntax for Pillar but not before. >>> >>> [[[test >>> 2+3 >>>>>> 5 >>> ]]] >>> >>> and being able to verify that the doc is in sync. >>> >>> >>> Stef >>> >>> >>> >>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim(a)testit.works> wrote: >>>> Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen. >>>> >>>> So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel. >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>>> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>> >>>>> A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well). >>>>> >>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar. >>>>> >>>>>> The readme.md that Peter is talking about is gfm markdown >>>>> >>>>> Well, technically it is just a CommonMark, as I am not using any github extensions. >>>>> (Github uses CommonMarks and adds just couple small extensions.) >>>>> >>>>> Peter >>>>> >>>> >>>> >>> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > âLive like you mean it." > >

Aug. 14, 2017

Re: [Pharo-users] Honest question, new to ecosystem: are Glorp and Garage alive?

by Esteban A. Maringolo

2017-08-14 9:07 GMT-03:00 Herby VojÄÃk <herby(a)mailbox.sk>: >> Garage is not maintained as people started developing the alternative >> UDBC drivers, that share the same spirit at the end. I do not know if >> they share the same API though. > > I did not know. So I should use ConfigurationOfGlorpSQLite instead of > ConfigurationOfGarageGlorp as my dependency? In the Glorp booklet these are the instructions to install SQLite: Gofer it smalltalkhubUser: 'TorstenBergmann' project: 'UDBC'; configuration; load. (Smalltalk at: #ConfigurationOfUDBC) loadBleedingEdge. Gofer it smalltalkhubUser: 'DBXTalk' project: 'Garage'; configurationOf: 'GarageGlorp'; load. (Smalltalk at: #ConfigurationOfGarageGlorp) project stableVersion load. Gofer it smalltalkhubUser: 'DBXTalk' project: 'Glorp'; package: 'Glorp-SQLite3'; load. >> About Glorp, I will let Esteban Maringolo ask :). > It seems from other responses that Glorp is fine. :-) Glorp was updated in Pharo last year from the latest version in Cincom Public Repository, although a year might seem like a lot, it isn't much because Glorp is mostly in "maintenance", and the ORM domain isn't a moving target anymore. What we're still lacking is better database drivers, not for Glorp which supports many, but in terms of low level connectivity. I really liked the idea of an unified driver layer the way UDBC was taking, unfortunately this was put to a halt. Maybe we should focus on having good reliable native drivers instead of trying to support all and end up having incomplete support for only a few. Regards! Esteban A. Maringolo ps: I'm currently not doing any RDBMS on Pharo, and that's why I'm not "updating" Glorp with minor/usability changes, but I'm using Glorp with SQLite in VW, so in the future I might update Pharo's port if there are changes. However those update must be manual, since Glorp isn't coordinated to be portable as Seaside or other projects are.

Aug. 14, 2017

Re: [Pharo-users] Honest question, new to ecosystem: are Glorp and Garage alive?

by Herby VojÄÃk

Guillermo Polito wrote: > Hi Holger, ??? :-) > Garage is not maintained as people started developing the alternative > UDBC drivers, that share the same spirit at the end. I do not know if > they share the same API though. I did not know. So I should use ConfigurationOfGlorpSQLite instead of ConfigurationOfGarageGlorp as my dependency? > About Glorp, I will let Esteban Maringolo ask :). It seems from other responses that Glorp is fine. :-) > On the other side, you should check again how you downloaded Garage and > GarageGlorp because I still believe you're not using the latest > versions. The last thing I did on that was to update it to pharo 6 and > UFFI, so it is working. Moreover, I moved garage's code base to github > to use travis (because inria CI was very unstable). I loaded what is in Pharo6 catalog. That is, GarageGlorp, which I load from Pharo6 meta repo. It then loads Garage and Glorp. Last commit in Garage-SQLite loaded via that (offical, I hope) configuration is Name: Garage-Sqlite3-GuillermoPolito.26 Author: GuillermoPolito Time: 3 May 2016, 11:24:28.35761 am UUID: 55bd20d2-c691-4065-94cc-8bf76e775410 Ancestors: Garage-Sqlite3-GuillermoPolito.25 Making it work for all platforms which is pre-pharo6 as far as I can say (and code actually looks like so). > > https://github.com/guillep/garage/blob/master/.travis.yml > > And travis reports that last build on pharo 6 was green (at the time I > set that up, travis had no cron jobs, so it was the last commit). > > https://travis-ci.org/guillep/garage This indeed contains much more commit beyond May 2016. Maybe the ConfigurationOfGarage / Pharo6 catalog needs updating? > So, Garage works on pharo 6 using UFFI, but I cannot maintain it mainly > because I don't use relational databases on my daily work. Thus, this is > complicated to maintain 4 backends for 3 platforms, on 2 pharo versions, > if you don't eat your own food. > > Now, documentation may be outdated :) > > On Mon, Aug 14, 2017 at 11:57 AM, Herby VojÄÃk <herby(a)mailbox.sk > <mailto:herby@mailbox.sk>> wrote: > > Hello! > > Without wanting to offend anyone, I'd like to know, as I do not > follow the tides yet, what is the state of Glorp and Garage re > maintained / having bright future vs. stalled? > > I know about Voyage but I chose not to use it as it seems a bit > "savage" to me with automatically applying to all instances of a > class. Did I backed the right horse by using Glorp (and wanting to > use Garage drivers)? > > Thanks, Herby > > > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - _http://www.cnrs.fr_ > > > > *Web:* _http://guillep.github.io_ > > *Phone: *+33 06 52 70 66 13 > Thanks, Herby

Aug. 14, 2017

Re: [Pharo-users] Honest question, new to ecosystem: are Glorp and Garage alive?

by Alistair Grant

Hi Herby, I've been using Glorp with UDBC/SQLite since early last year and it has been quite stable. Cheers, Alistair On 14 Aug. 2017 11:58, "Herby VojÄÃk" <herby(a)mailbox.sk> wrote: Hello! Without wanting to offend anyone, I'd like to know, as I do not follow the tides yet, what is the state of Glorp and Garage re maintained / having bright future vs. stalled? I know about Voyage but I chose not to use it as it seems a bit "savage" to me with automatically applying to all instances of a class. Did I backed the right horse by using Glorp (and wanting to use Garage drivers)? Thanks, Herby

Aug. 14, 2017

Re: [Pharo-users] Honest question, new to ecosystem: are Glorp and Garage alive?

by jtuchel＠objektfabrik.de

Herby, I cannot say anaything good or bad about Garage, since I am not using Pharo regularly. Glorp is maintained by CIncom employees and Cincom uses Glorp for their source control management, so at least from a bug fixing perspective, Glorp is in good shape. It does lack features like multiple inheritance levels spread over tables, and it seems nobody is implementing that. So I would probably be careful about the brightness level of Glorp's future when it comes to new features. Not sure if and how the Pharo crowd is involved and whether Cincom is looking for help with Glorp. I know that Niall is very helpful and helps as good as he can (and he can) if time permits. I have been using Glorp on a commercial web project for years now and happy with it. But I am using it on another Smalltalk dialect. Glorp has been in a very poor shape on Pharo for a while, but about a year or two ago, it has re-gained traction. So if you want to use an O/R mapper in Smalltalk, I don't think there is anything maintained better than Glorp. It's as good as you can get in the Smalltalk world. Most alternatives are far less finished and look quite abandoned to me. So it seems like you need to swallow and make the best out of it ;-) Maybe somebody more deeply involved with Pharo has another (better?) option in their sleeves...? IIRC, Sven, who usually writes great code and maintains it very well, came up with a Postgres driver and a Glorp layer for it just a few weeks ago. If Garage doesn't work for you, and if Postgres is an option for you, you should definitiely take a look at it: https://github.com/svenvc/P3 HTH Joachim Am 14.08.17 um 11:57 schrieb Herby VojÄÃk: > Hello! > > Without wanting to offend anyone, I'd like to know, as I do not follow > the tides yet, what is the state of Glorp and Garage re maintained / > having bright future vs. stalled? > > I know about Voyage but I chose not to use it as it seems a bit > "savage" to me with automatically applying to all instances of a > class. Did I backed the right horse by using Glorp (and wanting to use > Garage drivers)? > > Thanks, Herby > > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Aug. 14, 2017

Re: [Pharo-users] Honest question, new to ecosystem: are Glorp and Garage alive?

by Guillermo Polito

Hi Holger, Garage is not maintained as people started developing the alternative UDBC drivers, that share the same spirit at the end. I do not know if they share the same API though. About Glorp, I will let Esteban Maringolo ask :). On the other side, you should check again how you downloaded Garage and GarageGlorp because I still believe you're not using the latest versions. The last thing I did on that was to update it to pharo 6 and UFFI, so it is working. Moreover, I moved garage's code base to github to use travis (because inria CI was very unstable). https://github.com/guillep/garage/blob/master/.travis.yml And travis reports that last build on pharo 6 was green (at the time I set that up, travis had no cron jobs, so it was the last commit). https://travis-ci.org/guillep/garage So, Garage works on pharo 6 using UFFI, but I cannot maintain it mainly because I don't use relational databases on my daily work. Thus, this is complicated to maintain 4 backends for 3 platforms, on 2 pharo versions, if you don't eat your own food. Now, documentation may be outdated :) On Mon, Aug 14, 2017 at 11:57 AM, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Hello! > > Without wanting to offend anyone, I'd like to know, as I do not follow the > tides yet, what is the state of Glorp and Garage re maintained / having > bright future vs. stalled? > > I know about Voyage but I chose not to use it as it seems a bit "savage" > to me with automatically applying to all instances of a class. Did I backed > the right horse by using Glorp (and wanting to use Garage drivers)? > > Thanks, Herby > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 14, 2017

Honest question, new to ecosystem: are Glorp and Garage alive?

by Herby VojÄÃk

Hello! Without wanting to offend anyone, I'd like to know, as I do not follow the tides yet, what is the state of Glorp and Garage re maintained / having bright future vs. stalled? I know about Voyage but I chose not to use it as it seems a bit "savage" to me with automatically applying to all instances of a class. Did I backed the right horse by using Glorp (and wanting to use Garage drivers)? Thanks, Herby

Aug. 14, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Guillermo Polito

In a full image (just bootstrapped) we have: 7.7 MB of arrays (probably in collections, we should check usages) 6.3 MB of methods 5.3 MB of ByteArrays 3.3 MB of ByteStrings 2.7 MB of Bitmaps 1.8 MB of ByteSymbols That sumps up aready ~27 MB On Mon, Aug 14, 2017 at 11:49 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi Tim, > > On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hey guys, thanks for your enthusiasm around this - and I cannot stress >> enough how this was only possible because of the work that has gone into >> making Pharo (in particular the 64bit image, as well as having a minimal >> image, and some great blog posts on serialising contexts) as well as the >> patience from everyone in answering questions and helping me get it all >> working. >> >> Iâm still quite keen to get my execution time back down under 800ms and >> Iâd like to actually get back to writing a few skills to automate a few >> things around my house. >> >> To Answer Denisâ question - >> >> My final footprint is 30.4mb - thats composed of a 22mb image (with a >> simple example that pulls in Fuel, ZTimestamp and the S3 Library which >> depends on XMLParser) and then the VM (from which I removed obvious dllâs). >> >> In my original experiments with a 6.0 minimal image - I did manage to get >> to a 13.4mb image (which started out as 12mb original size, and then loaded >> in STON and had only a simple clock example). I think the sweet spot is >> around 20mb total footprint as that seems to get me into the 450ms-900ms >> range. >> >> The 7.0 min image now starts out at 15mb and then Iâm not sure why >> loading Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not >> dug into that). >> > > You can do further space analysis using the following expression > > SpaceTally new printSpaceAnalysis > > You can do that in an eval and check what's taking space. With measures we > can iterate and improve :). > > >> Iâve also found (and this on the back of unserialising the context in my >> example) that the way we build images has 15+ saved stack sessions that >> have saved on top of each other from the way we build up the images. I >> donât yet know the implications of size/speed of these - but we need a >> better way of folding executions when we snapshot headless images. Iâm also >> not clear if there are any other startup tasks that take precious time >> (this also has implications for our fat development images as they take >> much longer to appear than they really should). >> > > I'm working on this as I'm writing this mail ;) > > https://pharo.fogbugz.com/f/cases/20309 > https://github.com/pharo-project/pharo/pull/196 > > I'll write down the implications further in a different thread. > > >> Iâll be exploring some of these size/speed tradeoffâs in follow on >> messages. >> >> But once again, a big thanks - Iâve not enjoyed programming like this for >> ages. >> >> Tim >> >> On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com> wrote: >> >> hi Tim, >> >> That is..... AWESOME! >> >> Very nice delivery - it flowed well with great narration. >> >> I loved @2:17 "this is the interesting piece, because PharoLambda has >> serialized the execution context of its application and saved it into [my >> S3 bucket] ... [then on the local machine] rematerializes a debugger [on >> that context]." >> >> There is a clarity in your video presentation that really may intrigue >> outsiders. As a community we should push this on the usual hacker forums - >> ycombinator could be a good starting point (but I'm locked out of my >> account there). >> An enticing title could be... >> "Debugging Lambdas by re-materializing saved execution contexts on your >> local machine." >> >> cheers -ben >> >> On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> This is cool Tim. >>> >>> So what image size you deployed at the end? >>> >>> 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >>> >>>> I just wanted to thank everyone for their help in getting my pet >>>> project further along, so that now I can announce that PharoLambda is now >>>> working with the V7 minimal image and also supports post mortem debugging >>>> by saving a zipped fuel context onto S3. >>>> >>>> This latter item is particularly satisfying as at a recent serverless >>>> conference (JeffConf) there was a panel where poor development tools on >>>> serverless platforms was highlighted as a real problem. >>>> >>>> In our community weâve had these kinds of tools at our fingertips for >>>> ages - but I donât think the wider development community has really >>>> noticed. Debugging something short lived like a Lambda execution is quite >>>> startling, as the current answer is âadd more loggingâ, and we all know >>>> that sucks. To this end, Iâve created a little screencast showing this in >>>> action - and it was pretty cool because it was a real example I encountered >>>> when I got everything working and was trying my test application out. >>>> >>>> Iâve also put a bit of work into tuning the excellent GitLab CI tools, >>>> so that I can cache many of the artefacts used between different build runs >>>> (this might also be of interest to others using CI systems). >>>> >>>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda >>>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E >>>> >>>> Tim >>>> >>>> >>>> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> Hi - Iâve been playing around with getting Pharo to run well on AWS >>>> Lambda. Itâs early days, but I though it might be interesting to share what >>>> Iâve learned so far. >>>> >>>> Usage examples and code at https://gitlab.com/macta/PharoLambda >>>> >>>> With help from many of the folks here, Iâve been able to get a simple >>>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily >>>> try it out yourself. This seems slightly better than what the GoLang folks >>>> have been able to do. >>>> >>>> Tim >>>> >>>> >>>> >>> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 14, 2017

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

by Guillermo Polito

Hi Tim, On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <tim(a)testit.works> wrote: > Hey guys, thanks for your enthusiasm around this - and I cannot stress > enough how this was only possible because of the work that has gone into > making Pharo (in particular the 64bit image, as well as having a minimal > image, and some great blog posts on serialising contexts) as well as the > patience from everyone in answering questions and helping me get it all > working. > > Iâm still quite keen to get my execution time back down under 800ms and > Iâd like to actually get back to writing a few skills to automate a few > things around my house. > > To Answer Denisâ question - > > My final footprint is 30.4mb - thats composed of a 22mb image (with a > simple example that pulls in Fuel, ZTimestamp and the S3 Library which > depends on XMLParser) and then the VM (from which I removed obvious dllâs). > > In my original experiments with a 6.0 minimal image - I did manage to get > to a 13.4mb image (which started out as 12mb original size, and then loaded > in STON and had only a simple clock example). I think the sweet spot is > around 20mb total footprint as that seems to get me into the 450ms-900ms > range. > > The 7.0 min image now starts out at 15mb and then Iâm not sure why loading > Fuel, S3 and XMLParser takes 7mb (it seems big to me - but Iâve not dug > into that). > You can do further space analysis using the following expression SpaceTally new printSpaceAnalysis You can do that in an eval and check what's taking space. With measures we can iterate and improve :). > Iâve also found (and this on the back of unserialising the context in my > example) that the way we build images has 15+ saved stack sessions that > have saved on top of each other from the way we build up the images. I > donât yet know the implications of size/speed of these - but we need a > better way of folding executions when we snapshot headless images. Iâm also > not clear if there are any other startup tasks that take precious time > (this also has implications for our fat development images as they take > much longer to appear than they really should). > I'm working on this as I'm writing this mail ;) https://pharo.fogbugz.com/f/cases/20309 https://github.com/pharo-project/pharo/pull/196 I'll write down the implications further in a different thread. > Iâll be exploring some of these size/speed tradeoffâs in follow on > messages. > > But once again, a big thanks - Iâve not enjoyed programming like this for > ages. > > Tim > > On 12 Aug 2017, at 16:26, Ben Coman <btc(a)openInWorld.com> wrote: > > hi Tim, > > That is..... AWESOME! > > Very nice delivery - it flowed well with great narration. > > I loved @2:17 "this is the interesting piece, because PharoLambda has > serialized the execution context of its application and saved it into [my > S3 bucket] ... [then on the local machine] rematerializes a debugger [on > that context]." > > There is a clarity in your video presentation that really may intrigue > outsiders. As a community we should push this on the usual hacker forums - > ycombinator could be a good starting point (but I'm locked out of my > account there). > An enticing title could be... > "Debugging Lambdas by re-materializing saved execution contexts on your > local machine." > > cheers -ben > > On Fri, Aug 11, 2017 at 3:37 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> This is cool Tim. >> >> So what image size you deployed at the end? >> >> 2017-08-10 15:47 GMT+02:00 Tim Mackinnon <tim(a)testit.works>: >> >>> I just wanted to thank everyone for their help in getting my pet project >>> further along, so that now I can announce that PharoLambda is now working >>> with the V7 minimal image and also supports post mortem debugging by saving >>> a zipped fuel context onto S3. >>> >>> This latter item is particularly satisfying as at a recent serverless >>> conference (JeffConf) there was a panel where poor development tools on >>> serverless platforms was highlighted as a real problem. >>> >>> In our community weâve had these kinds of tools at our fingertips for >>> ages - but I donât think the wider development community has really >>> noticed. Debugging something short lived like a Lambda execution is quite >>> startling, as the current answer is âadd more loggingâ, and we all know >>> that sucks. To this end, Iâve created a little screencast showing this in >>> action - and it was pretty cool because it was a real example I encountered >>> when I got everything working and was trying my test application out. >>> >>> Iâve also put a bit of work into tuning the excellent GitLab CI tools, >>> so that I can cache many of the artefacts used between different build runs >>> (this might also be of interest to others using CI systems). >>> >>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda >>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E >>> >>> Tim >>> >>> >>> On 15 Jul 2017, at 00:39, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi - Iâve been playing around with getting Pharo to run well on AWS >>> Lambda. Itâs early days, but I though it might be interesting to share what >>> Iâve learned so far. >>> >>> Usage examples and code at https://gitlab.com/macta/PharoLambda >>> >>> With help from many of the folks here, Iâve been able to get a simple >>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily >>> try it out yourself. This seems slightly better than what the GoLang folks >>> have been able to do. >>> >>> Tim >>> >>> >>> >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Aug. 14, 2017