December 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0] Build #86: Bottom21

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #86 was: SUCCESS. The Pull Request #2133 was integrated: "Bottom21" Pull request url: https://github.com/pharo-project/pharo/pull/2133 Issue Url: https://pharo.fogbugz.com/f/cases/Bottom21 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 29, 2018

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

by Tudor Girba

Great work! Doru > On Dec 27, 2018, at 10:32 AM, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi, > > Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform. Lamba has quite a large "free-tier", more than enough to do some experiments and to host small applications for free. > > See the GitHub project for more details https://github.com/jvdsandt/pharo-aws-toolbox > > Cheers, > Jan. -- www.feenk.com "You can inspect and adapt only what is explicit."

Dec. 29, 2018

Re: [Pharo-dev] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

Hi Offray, I believe I replied to all your emails. If I missed one, please point me to it. Cheers, Doru > On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > > On 28/12/18 8:03, Tudor Girba wrote: >>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: >>> >>> WOW >> :) >> >> What part of it do you like? >> >> Cheers, >> Doru > > And which parts you don't? > > I wrote a long mail regarding good and no so good parts of the new GT > experience, including features possible forks, that I hope will be > answered also in detail, to keep the big picture. > > Cheers, > > Offray > > > -- www.feenk.com "You can inspect and adapt only what is explicit."

Dec. 29, 2018

[Pharo 7.0] Build #85: 22848-Patch-to-avoid-breaking-iceberg

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #85 was: FAILURE. The Pull Request #2132 was integrated: "22848-Patch-to-avoid-breaking-iceberg" Pull request url: https://github.com/pharo-project/pharo/pull/2132 Issue Url: https://pharo.fogbugz.com/f/cases/22848 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 28, 2018

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

by Tim Mackinnon

Ah - so is the HANDLER variable set via the AWS console? (If so, then Iâd agree that using the env var makes more sense). It also sounds like NeoJson makes sense for the mapping - I hadnât needed it before in my usage - I donât think itâs very heavy weight anyway. For debugging, the serialisation of the stack to a bucket is so cool (kudos to Fuel for that), but cloudwatch is a useful basic tool and it does let you hook up to things like data dog etc. so we fit easily into the cloud eco system. I need to get things up and running again and will report back. Thanks again. Tim Sent from my iPhone > On 28 Dec 2018, at 17:30, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi Tim, > >> On Fri, Dec 28, 2018 at 4:49 PM Tim Mackinnon <tim(a)testit.works> wrote: >> Hi Jan - reading through your docs, this looks very promising as I hadnât got as far as using the api gateway - I was just connecting to the internal Alexa service. >> >> One thing I didnât quite understand - you mention specifying a HANDLER as an env variable, but your example description doesnât seem to show where that is set? Is it in the bootstrap file (also is that bootrap.sh or just simply bootstrap? > > Up til now I have configured my Lambda functions mostly via the AWS Console. When you create your function you must upload your code, specify the type of runtime and give the name of the handler. For a Java runtime this is the name of the main class, so for the Smalltalk implementation I choose something similar. If you want you can leave this item empty or set it to "Provided" and just hardcode the startup class in the image or in the bootstrap file. > >> And are there any file attributes to set on that file?). It strikes me that rather than using an env variable - why donât you specify the handler class when you invoke the image as the last command line option? (That is what I did in my example - or is it faster to query an env variable? Personally I find it easier to see it more explicitly on the command line). >> >> I also notice you include NeoJson - did you need that? I found that the default Ston reader was more than adequate for reading the json that was sent over (and so itâs one less pre-req). >> > With NeoJSON you can create mappings to serialize/deserialize custom Smalltalk classes to Json. I use this functionality in the CloudWatch-Logs interface to handle the request and response objects. I don't think this is possible with STON. > >> I havenât yet fully understood the runtime layer - is this simply a zip file with the vm + files and without the image? Previously I had to add all of that in the zip I uploaded for each function, but this sounds like it simplifies things a lot. Do you have a script you used to create that - I ask as I found that trimming down the size of that made a difference to load times for Alexa (eg there are lots of sound and graphics dllâs you can remove - which I have in my script, and possibly, I could add to what you have done). > > Yes, the layers are a great new feature. My layer just includes a standard Pharo 64 bits VM without any additions or removals. I made this one by hand, a script would be a better idea! You can remove shared libraries that you don't need. I think the most important thing is that the image does not load/initialize any unnecessary libraries. >> >> Equally, I also figured out the command line fu for uploading and registering your Lamba so it works in a ci - this might also be worthy of inclusion. >> > Yes, a CI job that can build a 'deployment' image and that can upload this image to AWS Lambda would be a great feature! > >> Anyway, lâll Give it a go and see how the results compare - it was surprisingly fast using the js shim - but this seems like a much better solution. >> >> Thanks for sharing - itâs an executing world. >> >> Tim >> > Thanks for your comments! > Jan. > >> >> >> >> Sent from my iPhone >>> On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote: >>> Hi Tim, >>> >>> Yes, I read that you got Pharo working via the Javascript runtime. It should now be much easier and faster. >>> >>> I still have to figure out the best way to create a deployment image. With the new bootstrap/modular setup of Pharo 7 it should be possible to create a lean-and-mean runtime image that can run in the cheapest 128MB max. ram configuration. >>> >>> Jan. >>> >>> On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon <tim(a)testit.works> wrote: >>> Cool - I was using a JS shim and had asked AWS many times why they couldnât open it up wider... >>> >>> Now Iâm back from my travels Iâll reincarnate my previous work and see how it works with this. I was looking forward to doing more with Lambda, so this is great timing. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: >>>> Hi, >>>> >>>> Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform. Lamba has quite a large "free-tier", more than enough to do some experiments and to host small applications for free. >>>> >>>> See the GitHub project for more details https://github.com/jvdsandt/pharo-aws-toolbox >>>> >>>> Cheers, >>>> Jan. >>

Dec. 28, 2018

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

by Jan van de Sandt

Hi Tim, On Fri, Dec 28, 2018 at 4:49 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Jan - reading through your docs, this looks very promising as I hadnât > got as far as using the api gateway - I was just connecting to the internal > Alexa service. > > One thing I didnât quite understand - you mention specifying a HANDLER as > an env variable, but your example description doesnât seem to show where > that is set? Is it in the bootstrap file (also is that bootrap.sh or just > simply bootstrap? > Up til now I have configured my Lambda functions mostly via the AWS Console. When you create your function you must upload your code, specify the type of runtime and give the name of the handler. For a Java runtime this is the name of the main class, so for the Smalltalk implementation I choose something similar. If you want you can leave this item empty or set it to "Provided" and just hardcode the startup class in the image or in the bootstrap file. And are there any file attributes to set on that file?). It strikes me that > rather than using an env variable - why donât you specify the handler class > when you invoke the image as the last command line option? (That is what I > did in my example - or is it faster to query an env variable? Personally I > find it easier to see it more explicitly on the command line). > > I also notice you include NeoJson - did you need that? I found that the > default Ston reader was more than adequate for reading the json that was > sent over (and so itâs one less pre-req). > > With NeoJSON you can create mappings to serialize/deserialize custom Smalltalk classes to Json. I use this functionality in the CloudWatch-Logs interface to handle the request and response objects. I don't think this is possible with STON. > I havenât yet fully understood the runtime layer - is this simply a zip > file with the vm + files and without the image? Previously I had to add all > of that in the zip I uploaded for each function, but this sounds like it > simplifies things a lot. Do you have a script you used to create that - I > ask as I found that trimming down the size of that made a difference to > load times for Alexa (eg there are lots of sound and graphics dllâs you can > remove - which I have in my script, and possibly, I could add to what you > have done). > Yes, the layers are a great new feature. My layer just includes a standard Pharo 64 bits VM without any additions or removals. I made this one by hand, a script would be a better idea! You can remove shared libraries that you don't need. I think the most important thing is that the image does not load/initialize any unnecessary libraries. > > Equally, I also figured out the command line fu for uploading and > registering your Lamba so it works in a ci - this might also be worthy of > inclusion. > > Yes, a CI job that can build a 'deployment' image and that can upload this image to AWS Lambda would be a great feature! > Anyway, lâll Give it a go and see how the results compare - it was > surprisingly fast using the js shim - but this seems like a much better > solution. > > Thanks for sharing - itâs an executing world. > > Tim > > Thanks for your comments! Jan. > > > > Sent from my iPhone > On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote: > > Hi Tim, > > Yes, I read that you got Pharo working via the Javascript runtime. It > should now be much easier and faster. > > I still have to figure out the best way to create a deployment image. With > the new bootstrap/modular setup of Pharo 7 it should be possible to create > a lean-and-mean runtime image that can run in the cheapest 128MB max. ram > configuration. > > Jan. > > On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon <tim(a)testit.works> wrote: > > Cool - I was using a JS shim and had asked AWS many times why they > couldnât open it up wider... > > Now Iâm back from my travels Iâll reincarnate my previous work and see how > it works with this. I was looking forward to doing more with Lambda, so > this is great timing. > > Tim > > Sent from my iPhone > > On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi, > > Last month Amazon extended their serverless runtime platform AWS Lambda > with support for custom runtimes. I created a Pharo Lambda Runtime so now > we can implement Lambda functions in Smalltalk and easily deploy them on > the Lambda platform. Lamba has quite a large "free-tier", more than enough > to do some experiments and to host small applications for free. > > See the GitHub project for more details > https://github.com/jvdsandt/pharo-aws-toolbox > > Cheers, > Jan. > > >

Dec. 28, 2018

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

by Tim Mackinnon

Hi Jan - reading through your docs, this looks very promising as I hadnât got as far as using the api gateway - I was just connecting to the internal Alexa service. One thing I didnât quite understand - you mention specifying a HANDLER as an env variable, but your example description doesnât seem to show where that is set? Is it in the bootstrap file (also is that bootrap.sh or just simply bootstrap? And are there any file attributes to set on that file?). It strikes me that rather than using an env variable - why donât you specify the handler class when you invoke the image as the last command line option? (That is what I did in my example - or is it faster to query an env variable? Personally I find it easier to see it more explicitly on the command line). I also notice you include NeoJson - did you need that? I found that the default Ston reader was more than adequate for reading the json that was sent over (and so itâs one less pre-req). I havenât yet fully understood the runtime layer - is this simply a zip file with the vm + files and without the image? Previously I had to add all of that in the zip I uploaded for each function, but this sounds like it simplifies things a lot. Do you have a script you used to create that - I ask as I found that trimming down the size of that made a difference to load times for Alexa (eg there are lots of sound and graphics dllâs you can remove - which I have in my script, and possibley, I could add to what you have done). Equally, I also figured out the command line fu for uploading and registering your Lamba so it works in a ci - this might also be worthy of inclusion. Anyway, lâll Give it a go and see how the results compare - it was surprisingly fast using the js shim - but this seems like a much better solution. Thanks for sharing - itâs an executing world. Tim Sent from my iPhone > On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote: > Hi Tim, > > Yes, I read that you got Pharo working via the Javascript runtime. It should now be much easier and faster. > > I still have to figure out the best way to create a deployment image. With the new bootstrap/modular setup of Pharo 7 it should be possible to create a lean-and-mean runtime image that can run in the cheapest 128MB max. ram configuration. > > Jan. > > On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon <tim(a)testit.works> wrote: > Cool - I was using a JS shim and had asked AWS many times why they couldnât open it up wider... > > Now Iâm back from my travels Iâll reincarnate my previous work and see how it works with this. I was looking forward to doing more with Lambda, so this is great timing. > > Tim > > Sent from my iPhone > >> On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: >> Hi, >> >> Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform. Lamba has quite a large "free-tier", more than enough to do some experiments and to host small applications for free. >> >> See the GitHub project for more details https://github.com/jvdsandt/pharo-aws-toolbox >> >> Cheers, >> Jan.

Dec. 28, 2018

Re: [Pharo-dev] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: > > WOW :) What part of it do you like? Cheers, Doru > On Thu, Dec 20, 2018 at 01:57 Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Luke, > > I am happy this looks exciting :). > > About the confusion part: The Glamorous Toolkit we are working on right now is a complete new world built on a complete new graphical stack that does is not based on the existing stack that ships with Pharo. It is not an evolution. It is a leap. > > The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. > > But, in the new world, we are bringing the concept much further. For example, Documenter provides a whole new kind of a tool that can mold to unify multiple workflows (like data notebooks, code documentation, or tutorials) right in the IDE. Coder provides the infrastructure for manipulating code that can mold its shape as you type. Transcript allows you to embed various widgets to transform the otherwise dull experience of a console into a live one. > > Behind the scenes GT comes with several engines. The Examples engine enables example-driven development which also bridges the gap between testing and documentation effort, especially when combined with Documenter. Releaser is able to release deeply nested projects. Phlow offers an engine that shares similarities with Glamour. Completer provides moldable completion. Visualizer offers a couple of visualization engines such as Mondrian. > > All of these are possible because of the underlying graphical stack made of Sparta/Bloc/Brick. > > All in all, we believe that the new GT enables a new way of programming. Individual features can be attractive, but our goal is to reshape the development experience. > > Does this address the concern? > > Cheers, > Doru > > > > On Dec 19, 2018, at 2:09 PM, Luke Gorrie <luke(a)snabb.co> wrote: > > > > On Fri, 14 Dec 2018 at 05:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Please do let us know what you think .. and, of course, what you feel. > > > > I'm feeling excited and confused :). > > > > Excited because I love seeing all these new demos streaming out and I'm itching to put new capabilities to work. > > > > Confused about the roadmap. How does this "new" Glamorous Toolkit relate to the "old" one that I learned about last year from the Moldable Tools thesis? Is this a new version or a complete rewrite? Is it backwards compatible or completely reimagined? Is adopting the new version a seamless process or is porting required? Are frameworks like Glamour still there behind the scenes or were they replaced? etc. > > > > > > <gt-documenter-magic-markup.gif><gt-0-4-0.png>_______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > "Things happen when they happen, > not when you talk about them happening." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Dec. 28, 2018

Re: [Pharo-dev] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Tudor Girba

Hi, The visualization you describe should be easily doable in the new world. Did you write the visualization in plain Roassal or with the RTMondrian API? Cheers, Doru > On Dec 28, 2018, at 11:32 AM, Luke Gorrie <luke(a)snabb.co> wrote: > > Thanks for the explanations! > > I like the separation between selecting (single-click) and spawning (double-click). The miller column panning is indeed working with a two-finger drag on the touchpad. I will need to test whether this gesture works when running GT on Linux and operating it on a Mac via VNC. That's the most common setup for our application. > > Spotter is not urgent for us. I have written some extensions for it but we aren't really using them much yet. If the inspector is working well then that's the main thing. > > I do have one very important Roassal visualization that I need to bring with me smoothly somehow. Question is whether to port if over to the new framework or somehow smoothly embed Roassal in the new GT? > > The visualization is for compile SSA intermediate representation code and looks like this: > > <Screen Shot 2018-12-28 at 11.25.06.png> > There are some important properties about this diagram: > > - These are two digraphs stacked on top of each other. > - Nodes are always placed below their parents. > - Y-position indicates the max number of edges to reach parent nodes. > - Extra edges (red) can create cycles and should be ignored for layout purposes. > - Nodes can be compound shapes i.e. colored opcode and optionally fused immediate operands in white. > - Each node is an object that can be selected and inspected in the next miller column. > > Can this be done in the new framework with similar effort to the old one? > > On Fri, 28 Dec 2018 at 09:46, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Thanks for the feedback! > > I am happy you like the new possibilities and that you see the incentives to move to the new world :). > > The inspector part is working quite well. The main reason we call it an alpha is because of the missing pieces to get to a full environment. > > You noticed the issue of Spotter. The existing Spotter is the one that is included in the old GT and it lives in the Morphic world. When the focus is in the new inspector, that means that keybindings are handled by Bloc and this is a separate world from Morphic. At present time, we can embed Bloc in Morphic but not the other way around as we want no binding from Bloc to Morphic. For this reason, unhandled keys are not propagated from Bloc to Morphic and that is why pressing Shift+Enter does not open Spotter. > > So, we will have a Spotter, but that will be another implementation. Other unfinished tools are the Debugger and Coder, but these are likely less relevant for your use case. > > A few other missing pieces: > - some widgets such as a tree are not yet implemented. So, we do not yet have a tree view in inspector. > - the text editor requires a few enhancements for navigation support. > - scrollbar > > The Miller-columns interface can be scrolled with the touchpad left-right. Can you confirm? > > About clicking vs double-clicking: Indeed, we now distinguish between selecting and spawning. As soon as there is a page to the right, selecting will populate that page. However, if there is no page to the right, simply selecting in a list will not spawn, like in the old inspector. Like this, you can work on a page without the page scrolling from underneath you. Please note that between pages we have triangles which are actually buttons. Selecting in a list shows a triangle. Clicking on the triangle spawns. So, you can either double-click to spawn, or you can select and then click on the triangle. Once spawned, simple selection is enough. Does this clarify the situation? > > About Roassal: In the new GT we have GtMondrian which is similar to the one from Roassal. We do not yet have support for creating charts (like bar or line charts). > > About the porting strategy: When you have the new GT loaded, the old Inspector will get a _GT pane that will essentially embed the new views in the old inspector. These also allow for interaction. Like this, you can port at your pace and switch only when you are ready. > > Cheers, > Doru > > > > > On Dec 27, 2018, at 11:36 AM, Luke Gorrie <luke(a)snabb.co> wrote: > > > > ... Some comments and questions if I may: > > > > The "+" button to quickly maximize a panel is fantastic. I am often looking at complex visualizations that should really be full-screen and it was always too much trouble to "drag" them to full screen and back. > > > > Is the Spotter still a part of GToolkit? If not then what replaces it? (I can see that it is present in the image but Shift-Return doesn't seem to invoke it when the GTInspector window has focus.) > > > > Is it still possible to pan left-right between "miller columns"? I see the squares at the top representing panes but clicking and dragging them doesn't seem to do anything. > > > > How come a double-click is now needed to inspect an object? Is single-click going to have a new function? > > > > Once more - great work you guys are doing ! > > > > On Thu, 27 Dec 2018 at 11:06, Luke Gorrie <luke(a)snabb.co> wrote: > > Hi Doru, > > > > Thank you very much for the detailed explanation. > > > > I have spent some time with the alpha now. I think it is absolutely fantastic! > > > > I love the new narrative style of the UI. This ties everything together beautifully and makes it easy to explore. That's really what I am lacking in my application. Currently it simply opens to a blank quasi-playground and it is not obvious what to type or how to get started. I started writing a separate HTML manual but I don't think that's the right medium -- much better with something interactive in the image like the Documenter. > > > > Just clicking around everything seemed to work basically smoothly for me. Maybe it's already time for me to port over to the new GT? Or what do you think the most likely obstacles would be in transitioning to this alpha version? > > > > Currently my custom inspector extensions are mostly based on Roassal and List/Tree/Table views. I also have one or two Glamour browsers. Is that all still there in one form or another? > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > "Every thing has its own flow." > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Dec. 28, 2018

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

by Jan van de Sandt

Hi Tim, Yes, I read that you got Pharo working via the Javascript runtime. It should now be much easier and faster. I still have to figure out the best way to create a deployment image. With the new bootstrap/modular setup of Pharo 7 it should be possible to create a lean-and-mean runtime image that can run in the cheapest 128MB max. ram configuration. Jan. On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon <tim(a)testit.works> wrote: > Cool - I was using a JS shim and had asked AWS many times why they > couldnât open it up wider... > > Now Iâm back from my travels Iâll reincarnate my previous work and see how > it works with this. I was looking forward to doing more with Lambda, so > this is great timing. > > Tim > > Sent from my iPhone > > On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi, > > Last month Amazon extended their serverless runtime platform AWS Lambda > with support for custom runtimes. I created a Pharo Lambda Runtime so now > we can implement Lambda functions in Smalltalk and easily deploy them on > the Lambda platform. Lamba has quite a large "free-tier", more than enough > to do some experiments and to host small applications for free. > > See the GitHub project for more details > https://github.com/jvdsandt/pharo-aws-toolbox > > Cheers, > Jan. > >

Dec. 28, 2018