done: https://www.reddit.com/r/programming/comments/6t9242/debugging_lambdas_by_rematerializing_saved/ <https://www.reddit.com/r/programming/comments/6t9242/debugging_lambdas_by_rematerializing_saved/> https://news.ycombinator.com/item?id=14998234 <https://news.ycombinator.com/item?id=14998234>
Esteban > On 12 Aug 2017, at 17:26, Ben Coman <b...@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 <dionisi...@gmail.com > <mailto:dionisi...@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@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@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 > > >
