[ANN] PharoLambda a demo of Pharo running on AWS Lambda

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ANN] PharoLambda a demo of Pharo running on AWS Lambda

Tim Mackinnon
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] PharoLambda a demo of Pharo running on AWS Lambda

Tim Mackinnon
Things move fast, I already got a shout out from an AWS advocate - https://twitter.com/chrismunns/status/885959425860808704

Tim

On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] PharoLambda a demo of Pharo running on AWS Lambda

Tudor Girba-2
Nice job!

Doru


> On Jul 15, 2017, at 1:43 AM, Tim Mackinnon <[hidden email]> wrote:
>
> Things move fast, I already got a shout out from an AWS advocate - https://twitter.com/chrismunns/status/885959425860808704
>
> Tim
>
>> On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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
>

--
www.tudorgirba.com
www.feenk.com

"Every thing has its own flow."






Reply | Threaded
Open this post in threaded view
|

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

Tim Mackinnon
In reply to this post by Tim Mackinnon
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Esteban A. Maringolo
Hi Tim,

Impressive pet project you have. And what a way to deliver! Not only
with fun features never built before, but also with a documented repo
and a detailed screencast.

Congratulations.

In my self interest, and indirectly for the Pharo community, I look
forward to see more contributions like this from you.

Regards!

Esteban A. Maringolo


2017-08-10 10:47 GMT-03:00 Tim Mackinnon <[hidden email]>:

> 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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

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

abergel
In reply to this post by Tim Mackinnon
Impressive stuff!! 

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Aug 10, 2017, at 9:47 AM, Tim Mackinnon <[hidden email]> wrote:

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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Mariano Martinez Peck
Yeah, very nice. I just watched it all and looks cool. I am happy that the debugger/stack/context serialization is still breaking other people's mind :)
There are a few limitations and problems with the serialization of debugger and materialization in another image. I think I listed those several times in the mailing list, but if you want, let me know, and I can remind them again (there we workarounds or help with the limits).

Cheers,

On Thu, Aug 10, 2017 at 5:57 PM, Alexandre Bergel <[hidden email]> wrote:
Impressive stuff!! 

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Aug 10, 2017, at 9:47 AM, Tim Mackinnon <[hidden email]> wrote:

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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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





--
Reply | Threaded
Open this post in threaded view
|

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

Stephane Ducasse-3
In reply to this post by Tim Mackinnon
Tim

I definitively think that we could turn it into a Pharo success story
or something that we can keep on the web site
because it is really nice.

Stef

On Thu, Aug 10, 2017 at 3:47 PM, Tim Mackinnon <[hidden email]> wrote:

> 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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

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

Tudor Girba-2
In reply to this post by Tim Mackinnon
Very nice work, Tim!

It is quite impressive what you could do within a short amount of time (essentially since PharoDays). Please do keep this up.

Cheers,
Doru


> On Aug 10, 2017, at 3:47 PM, Tim Mackinnon <[hidden email]> wrote:
>
> 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 <[hidden email]> 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
>

--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."


Reply | Threaded
Open this post in threaded view
|

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

Tudor Girba-2
In reply to this post by Stephane Ducasse-3
+1

Doru


> On Aug 10, 2017, at 11:34 PM, Stephane Ducasse <[hidden email]> wrote:
>
> Tim
>
> I definitively think that we could turn it into a Pharo success story
> or something that we can keep on the web site
> because it is really nice.
>
> Stef
>
> On Thu, Aug 10, 2017 at 3:47 PM, Tim Mackinnon <[hidden email]> wrote:
>> 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 <[hidden email]> 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
>>
>>
>

--
www.tudorgirba.com
www.feenk.com

"Reasonable is what we are accustomed with."


Reply | Threaded
Open this post in threaded view
|

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

Denis Kudriashov
In reply to this post by Tim Mackinnon
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

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

Ben Coman
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 <[hidden email]> wrote:
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

EstebanLM
done: 


Esteban

On 12 Aug 2017, at 17:26, Ben Coman <[hidden email]> 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 <[hidden email]> wrote:
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

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

Ben Coman
Thanks Esteban.  
@everyone, please vote & share.

cheers -ben

On Sat, Aug 12, 2017 at 11:35 PM, Esteban Lorenzano <[hidden email]> wrote:
done: 


Esteban

On 12 Aug 2017, at 17:26, Ben Coman <[hidden email]> 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 <[hidden email]> wrote:
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

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

Tim Mackinnon
In reply to this post by Ben Coman
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). 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’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 <[hidden email]> 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 <[hidden email]> wrote:
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

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

Guillermo Polito
Hi Tim,

On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <[hidden email]> 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 ;)


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 <[hidden email]> 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 <[hidden email]> wrote:
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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



Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> wrote:
Hi Tim,

On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <[hidden email]> 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 ;)


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 <[hidden email]> 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 <[hidden email]> wrote:
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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



Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13




--

   

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

Reply | Threaded
Open this post in threaded view
|

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

Tim Mackinnon
In reply to this post by Guillermo Polito
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 <[hidden email]> wrote:

Hi Tim,

On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <[hidden email]> 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 ;)


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 <[hidden email]> 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 <[hidden email]> wrote:
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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


Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

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

Stephane Ducasse-3
In reply to this post by Tim Mackinnon
Tim

could you send me a "sexy" screen capture for a success story half september?
I will take you text as an input and come back to you.

Stef

On Thu, Aug 10, 2017 at 3:47 PM, Tim Mackinnon <[hidden email]> wrote:

> 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 <[hidden email]> 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
>
>

Reply | Threaded
Open this post in threaded view
|

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

Guillermo Polito
In reply to this post by Tim Mackinnon


On Mon, Aug 14, 2017 at 4:42 PM, Tim Mackinnon <[hidden email]> wrote:
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).

Yup, it's loaded afterwards.

All packages are loaded through metacello baselines. We should start refactoring and making standalone projects, each one with a baseline for himself, and his own dependencies described.

I was checking on your gitlab and I have probably no access: how are you finally loading packages in the bootstrap image? Can you share that with us in text? I'd like to improve that situation.
 
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?).

Yes it is, you can get the package programatically doing 

SpaceTally package name

And furthermore, get the baseline that currently is loading by doing

package := SpaceTally package name.
BaselineOf subclasses select: [ :e | 
e project version packages anySatisfy: [ :p | p name = package ]].
 

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 <[hidden email]> wrote:

Hi Tim,

On Mon, Aug 14, 2017 at 11:41 AM, Tim Mackinnon <[hidden email]> 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 ;)


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 <[hidden email]> 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 <[hidden email]> wrote:
This is cool Tim.

So what image size you deployed at the end?

2017-08-10 15:47 GMT+02:00 Tim Mackinnon <[hidden email]>:
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

Tim


On 15 Jul 2017, at 00:39, Tim Mackinnon <[hidden email]> 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


Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13




--

   

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

12