February 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] AWS SDK for Pharo

by Stefan Krecher

How would a controlled experiment look like? Am Mi., 27. Feb. 2019 um 13:18 Uhr schrieb ducasse <stepharo(a)netcourrier.com >: > It would be cool to have some bindings. > > I remember that > https://www.min.at/prinz/?x=entry:entry150318-104537 > It would be nice to make it work in Pharo 70. > > Now are you sure that this is complex to take json description and > generate SDKs > Did you run a controlled experiment? > > > Stef > > On 27 Feb 2019, at 12:37, Stefan Krecher <stefan.krecher(a)gmail.com> wrote: > > Hi, > I'm aware that there is already an AWS SDK implementation for Smalltalk ( > https://github.com/newapplesho/aws-sdk-smalltalk ) > This implementation doesn't seem to be a complete implementation to access > all AWS services. > Using a live-programming environment like Pharo would be so cool, > flexible, productive and intuitive to control/ manage AWS resources - but > implementing the SDK by hand is probably not a good idea, since it would be > so hard to keep it up-to-date, because AWS adds new features weekly ... > I contacted the AWS enterprise support and they gave me some great hints. > There are many 3rd party SDK's available that utilizes the json files > provided in botocore to automatically generate SDKs: Botocore: > https://github.com/boto/botocore > <https://github.com/boto/botocore>Example service.json: > <https://github.com/boto/botocore> > https://github.com/boto/botocore/blob/develop/botocore/data/ecs/2014-11-13/… > They can then automatically generate an SDK based off of these json > definitions. One example of this is Rusoto, the AWS SDK for Rust: > Rusoto: https://github.com/rusoto/rusoto Automatic generation portion: > https://github.com/rusoto/rusoto/tree/master/service_crategen > > Would anyone interested in supporting this kind of project? > What would be a good starting-point? > Although I am (to be honest: I was) a Smalltalk-Programmer, I have too > little experience with Pharo - but maybe others might find this useful. It > would also be useful to "spread the word" - AWS scripting/ automation is so > popular, there would be so many occasions to showcase Pharo + AWS or to > create Products that are based on AWS services. > > Regards > Stefan > > > -- Dipl.-Wirtsch.-Inf. Stefan Krecher Neulander Str. 17, 27374 VisselhÃ¶vede Tel +49(0)4262 958848 mobil +49(0)172 4396852

Feb. 27, 2019

Re: [Pharo-dev] AWS SDK for Pharo

by Sven Van Caekenberghe

Hi, This is interesting indeed. The meta descriptions in JSON are cool and most probably usable. It would be a huge project, though, given how many APIs/products there are, even with auto generation. A long time ago I did a AWS S3 client that is still part of Zinc HTTP Components (https://github.com/svenvc/zinc) although I believe the authentication/signing model is old now. Sven > On 27 Feb 2019, at 12:37, Stefan Krecher <stefan.krecher(a)gmail.com> wrote: > > Hi, > I'm aware that there is already an AWS SDK implementation for Smalltalk ( https://github.com/newapplesho/aws-sdk-smalltalk ) > This implementation doesn't seem to be a complete implementation to access all AWS services. > Using a live-programming environment like Pharo would be so cool, flexible, productive and intuitive to control/ manage AWS resources - but implementing the SDK by hand is probably not a good idea, since it would be so hard to keep it up-to-date, because AWS adds new features weekly ... > I contacted the AWS enterprise support and they gave me some great hints. > There are many 3rd party SDK's available that utilizes the json files provided in botocore to automatically generate SDKs: > Botocore: > https://github.com/boto/botocore > Example service.json:https://github.com/boto/botocore/blob/develop/botocore/data/ec… > They can then automatically generate an SDK based off of these json definitions. One example of this is Rusoto, the AWS SDK for Rust: > Rusoto: https://github.com/rusoto/rusoto > > Automatic generation portion: > https://github.com/rusoto/rusoto/tree/master/service_crategen > > Would anyone interested in supporting this kind of project? > What would be a good starting-point? > Although I am (to be honest: I was) a Smalltalk-Programmer, I have too little experience with Pharo - but maybe others might find this useful. It would also be useful to "spread the word" - AWS scripting/ automation is so popular, there would be so many occasions to showcase Pharo + AWS or to create Products that are based on AWS services. > > Regards > Stefan

Feb. 27, 2019

Re: [Pharo-dev] AWS SDK for Pharo

by ducasse

It would be cool to have some bindings. I remember that https://www.min.at/prinz/?x=entry:entry150318-104537 <https://www.min.at/prinz/?x=entry:entry150318-104537> It would be nice to make it work in Pharo 70. Now are you sure that this is complex to take json description and generate SDKs Did you run a controlled experiment? Stef > On 27 Feb 2019, at 12:37, Stefan Krecher <stefan.krecher(a)gmail.com> wrote: > > Hi, > I'm aware that there is already an AWS SDK implementation for Smalltalk ( https://github.com/newapplesho/aws-sdk-smalltalk <https://github.com/newapplesho/aws-sdk-smalltalk> ) > This implementation doesn't seem to be a complete implementation to access all AWS services. > Using a live-programming environment like Pharo would be so cool, flexible, productive and intuitive to control/ manage AWS resources - but implementing the SDK by hand is probably not a good idea, since it would be so hard to keep it up-to-date, because AWS adds new features weekly ... > I contacted the AWS enterprise support and they gave me some great hints. > There are many 3rd party SDK's available that utilizes the json files provided in botocore to automatically generate SDKs: > Botocore: https://github.com/boto/botocore <https://github.com/boto/botocore> > <https://github.com/boto/botocore>Example service.json: <https://github.com/boto/botocore>https://github.com/boto/botocore/blob/develop/botocore/data/ecs/2014-11-13/… <https://github.com/boto/botocore/blob/develop/botocore/data/ecs/2014-11-13/…> > They can then automatically generate an SDK based off of these json definitions. One example of this is Rusoto, the AWS SDK for Rust: > Rusoto: https://github.com/rusoto/rusoto <https://github.com/rusoto/rusoto> > Automatic generation portion: https://github.com/rusoto/rusoto/tree/master/service_crategen <https://github.com/rusoto/rusoto/tree/master/service_crategen> > > Would anyone interested in supporting this kind of project? > What would be a good starting-point? > Although I am (to be honest: I was) a Smalltalk-Programmer, I have too little experience with Pharo - but maybe others might find this useful. It would also be useful to "spread the word" - AWS scripting/ automation is so popular, there would be so many occasions to showcase Pharo + AWS or to create Products that are based on AWS services. > > Regards > Stefan

Feb. 27, 2019

AWS SDK for Pharo

by Stefan Krecher

Hi, I'm aware that there is already an AWS SDK implementation for Smalltalk ( https://github.com/newapplesho/aws-sdk-smalltalk ) This implementation doesn't seem to be a complete implementation to access all AWS services. Using a live-programming environment like Pharo would be so cool, flexible, productive and intuitive to control/ manage AWS resources - but implementing the SDK by hand is probably not a good idea, since it would be so hard to keep it up-to-date, because AWS adds new features weekly ... I contacted the AWS enterprise support and they gave me some great hints. There are many 3rd party SDK's available that utilizes the json files provided in botocore to automatically generate SDKs: Botocore: https://github.com/boto/botocore <https://github.com/boto/botocore>Example service.json: <https://github.com/boto/botocore> https://github.com/boto/botocore/blob/develop/botocore/data/ecs/2014-11-13/… They can then automatically generate an SDK based off of these json definitions. One example of this is Rusoto, the AWS SDK for Rust: Rusoto: https://github.com/rusoto/rusoto Automatic generation portion: https://github.com/rusoto/rusoto/tree/master/service_crategen Would anyone interested in supporting this kind of project? What would be a good starting-point? Although I am (to be honest: I was) a Smalltalk-Programmer, I have too little experience with Pharo - but maybe others might find this useful. It would also be useful to "spread the word" - AWS scripting/ automation is so popular, there would be so many occasions to showcase Pharo + AWS or to create Products that are based on AWS services. Regards Stefan

Feb. 27, 2019

Re: [Pharo-dev] Startup Metacello Error

by Sean P. DeNigris

Sean P. DeNigris wrote > Has something changed re startup in P7 that could account for this error? Also, are there any handlers for Notifications in the startup code? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 26, 2019

Startup Metacello Error

by Sean P. DeNigris

While loading a project from a class-side #startUp: method, I'm getting a DNU #ifTrue:ifFalse which seemed to come from somewhere deep inside Metacello [1]. On the Metacello ML, Dale suggested that the startup mechanism might be the cause: > MetacelloSkipDirtyPackageLoad is a subclass of Notification, so if some > piece of code is catching Notification or above and doing a simple resume, > then you've found your culprit ... sounds like something startup code > might do when the system isn't able to handle GUI interaction ... but it's > a pretty harsh solution ... This same code was not throwing an error on P6.1. Has something changed re startup in P7 that could account for this error? Thanks! [1] The top of the call chain is: DoItIn: arg1 ^ (MetacelloSkipDirtyPackageLoad signal: self) ifTrue: [ | tmp2 | tmp2 := Transcript. tmp2 cr; show: 'Skipping load of modified package: ' , self file. arg1 home return: self ] ifFalse: [ | tmp4 | tmp4 := Transcript. tmp4 cr; ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 26, 2019

Re: [Pharo-dev] Apparently Zodiac plugin can crash VM on Linux

by Max Leske

I've heard from Martin again: embee i think i figured out the problem: ZnClient works with libssl 1.0.0 but not with 1.1. if i force a symlink from 1.1 to 1.0.0 then ZnClient works, however git still fails because it links against libldap which links against openssl 1.1. it looks like the way to fix this would be to make ZnClient work with openssl 1.1 Max On 16 Jan 2019, at 16:37, Sven Van Caekenberghe wrote: >> On 16 Jan 2019, at 16:28, Max Leske <maxleske(a)gmail.com> wrote: >> >> On 15 Jan 2019, at 22:59, Sven Van Caekenberghe wrote: >> >> Doing HTTPS client calls is part of the standard test suite, so it >> should work, else we would not have a green build. > > It works for me and for the CI. > >> What exactly is he doing ? Is it reproducible ? >> >> Yes, consistently. > > How ? > >> Can he try with a fresh downloaded image+vm ? >> >> I quote: >> >> @embee >> i have tested >> https://files.pharo.org/get-files/70/pharo64-linux-stable.zip and >> https://files.pharo.org/get-files/70/pharo64-linux-latest.zip >> i hope those are the right ones. both crash >> >> @maxleske >> Thanks. I'll report that. >> Was that also with a fresh image? >> i.e. you can also reprocude it with a fresh image, right? >> >> @embee >> yes >> >> On 15 Jan 2019, at 22:20, Max Leske maxleske(a)gmail.com wrote: >> >> Hi, >> >> I'm writing on behalf of Martin (eMBee) who's experiencing crashes >> when using SSL. You can find a VM crash stack trace here: >> http://ws.stfx.eu/AKVNLUPMPGLG. >> >> He says he hasn't updated openssl since December 15th but that the >> crashes started to happen only recently (within the last couple of >> days). I asked him to try HTTP only connections and those work. The >> VM crashes immediately when using SSL. To me it looks like the >> cuplrit is the Zodiac plugin, or at least the library it works with. >> >> His system: >> linux, fedora 29, and from the system reporter i get: >> Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo >> CoInterpreter VMMaker.oscog-eem.2401 uuid: >> 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: >> 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 >> VM: 201806281256 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun >> 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> >> cheers, >> Max >>

Feb. 26, 2019

[Pharo 8.0] Build #107: 2725-When-doing-a-FileOut-propose-to-open-the-folder-containing-the-fileout

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

There is a new Pharo build available! The status of the build #107 was: FAILURE. The Pull Request #2726 was integrated: "2725-When-doing-a-FileOut-propose-to-open-the-folder-containing-the-fileout" Pull request url: https://github.com/pharo-project/pharo/pull/2726 Issue Url: https://pharo.fogbugz.com/f/cases/2725 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 25, 2019

[Pharo 8.0] Build #106: 2718-Rubric-should-not-depend-on-TextEditor

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

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

Feb. 25, 2019

[Pharo 7.0] Build #149: 2699 - backport pharo-vcs/tonel bug fix

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

There is a new Pharo build available! The status of the build #149 was: SUCCESS. The Pull Request #2700 was integrated: "2699 - backport pharo-vcs/tonel bug fix" Pull request url: https://github.com/pharo-project/pharo/pull/2700 Issue Url: https://pharo.fogbugz.com/f/cases/Pharo7.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 25, 2019