October 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Stuck trying to contribute

by Stephane Ducasse

I'm in the process to push out of the cliff all the material I have written and not released over the year. On Tue, Oct 31, 2017 at 12:27 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Sven >> >> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >> the pain for me. > > Ah, OK, found it. Thanks. > > Nice document BTW ;-) > >> Stef >> >> >> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> If you give me precise instructions I can update the post :) >> >> precise instructions is: >> - do not use https, use ssh >> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >> >>> >>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> I think I succeeded: >>> >>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>> https://github.com/pharo-project/pharo/pull/420 >>> >>> It does contain 4 identical commits due to my troubles earlier on. >>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>> >>> > On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > >>> > >>> >> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >> >>> >> hi, >>> >> >>> >> thing is, you should not use https authentication (and the guide should not point to it) >>> >> Using SSH mode works out of the box. >>> >> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>> > >>> > Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>> > >>> > Thanks ! >>> > >>> >> Esteban >>> >> >>> >>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> >>> Hi, >>> >>> >>> >>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>> >>> >>> >>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>> >>> >>> >>> $ sw_vers >>> >>> ProductName: Mac OS X >>> >>> ProductVersion: 10.13 >>> >>> BuildVersion: 17A405 >>> >>> >>> >>> $ curl get.pharo.org/70+vm | bash >>> >>> ... >>> >>> >>> >>> $ ./pharo-ui Pharo.image >>> >>> >>> >>> I now have the following setup, which is correct I think. >>> >>> >>> >>> <Screen Shot 2017-10-30 at 20.28.05.png> >>> >>> >>> >>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>> >>> >>> >>> Locally, I see >>> >>> >>> >>> $ git status >>> >>> On branch 20613-Improve-some-UUID-comments >>> >>> nothing to commit, working tree clean >>> >>> >>> >>> with the new code already committed >>> >>> >>> >>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>> >>> instance creation >>> >>> new >>> >>> "Create and return a new UUID" >>> >>> >>> >>> "self new" >>> >>> >>> >>> ^ (self new: 16) >>> >>> >>> >>> What did I do wrong ? How do I proceed ? >>> >>> >>> >>> Sven >>> >>> >>> >> >>> > >>> >>> >>> >>> >>> >>> -- >>> >>> Guille Polito >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> CRIStAL - UMR 9189 >>> French National Center for Scientific Research - http://www.cnrs.fr >>> >>> Web: http://guillep.github.io >>> Phone: +33 06 52 70 66 13 >> >> > >

Oct. 31, 2017

Re: [Pharo-dev] Baseline/Configuration loading bars

by Stephane Ducasse

Agreed! On Tue, Oct 31, 2017 at 9:42 PM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > Hello > > I have never paid any attention to following thing, but now I use Pharo to > teach students object oriented programming and there is one thing that I > realized how very bad is from user experience perspective: When I am loading > package with lots of dependencies, like Moose or Seaside, it may take > multiple minutes (especially on Windows) and those loading bars are there > half of a time, but half of a time there is nothing, just nothing - it looks > like finished, but it is in fact still loading and everything is therefore > sluggish. If I was not sure it is in actually still loading just fine, I > would try to kill the process and try again. Example which causes such > loading without much of UI is this one: > > Gofer it > smalltalkhubUser: 'zeroflag' project: 'Teapot'; > configuration; > loadStable. > Metacello new > repository: > 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; > configuration: 'Seaside3'; > version: #'release3.2'; > load: #('OneClick'). > > It would be nice to have some loading bar or something like "loading > packages, please wait..." there at all times until baseline/configuration > loading is completely done... also some confirming message like > "ConfigurationOfSeaside3 loaded successfully" would be nice > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 31, 2017

Baseline/Configuration loading bars

by Jan BlizniÄenko

Hello I have never paid any attention to following thing, but now I use Pharo to teach students object oriented programming and there is one thing that I realized how very bad is from user experience perspective: When I am loading package with lots of dependencies, like Moose or Seaside, it may take multiple minutes (especially on Windows) and those loading bars are there half of a time, but half of a time there is nothing, just nothing - it looks like finished, but it is in fact still loading and everything is therefore sluggish. If I was not sure it is in actually still loading just fine, I would try to kill the process and try again. Example which causes such loading without much of UI is this one: Gofer it smalltalkhubUser: 'zeroflag' project: 'Teapot'; configuration; loadStable. Metacello new repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; configuration: 'Seaside3'; version: #'release3.2'; load: #('OneClick'). It would be nice to have some loading bar or something like "loading packages, please wait..." there at all times until baseline/configuration loading is completely done... also some confirming message like "ConfigurationOfSeaside3 loaded successfully" would be nice -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 31, 2017

Re: [Pharo-dev] [Iceberg] Couple of bugs/problems on Iceberg

by Mariano Martinez Peck

4) OK, here is a more heavy issue.... I keep reviewing that PR and it looks like NOT all commits changes are being correctly diffED in the UI. For example, look at the attached picture of commit 3ca50bb with description "Ignore 7th field of lsof". As you can see, it shows NO diff no changes, empty box when I do "Changes vs parent". While github correctly shows the diff [1]. Aside from the "Changes vs Parent" if I go to "Changes vs Destination" and I even go to the latest commit, I do NOT see either that change as part of the changes. Any idea what is happening? Thanks in advance, [1] https://github.com/marianopeck/OSSubprocess/pull/26/commits/8786a342fe306af… On Tue, Oct 31, 2017 at 10:49 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys, > > 1) I am reviewing an awesome PR from Guille and I think the labels "Left: > working copy" and "Right: incoming updates" are switched. Look at the > attached screenshot. In this example, the method `waitForExitWithTimeout:` > is new and comes from the update (PR), its NOT not on my working copy. > > 2) Subtree revert not possible? Let's say I have a class with 2 methods I > changed and I want to revert both. I thought that reverting the class would > do the trick and revert all the inner tree. But no, I am getting a `nil dnu > #inverse`. Look at the attached screenshot. I mean to revert > OSUnixSubprocess (hence, both methods below). > > 3) The scrolling of versions in the PR review feels slow... and my project > is tiny... is that using "FastTable" ? Btw...I would also love if upper and > down keys could be used in that table. > > > Thanks in advance, > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Oct. 31, 2017

Re: [Pharo-dev] [Pharo-users] [ANNOUNCE] ParrotTalk release/design change considerations

by henry

I wanted to share my good news, though I have not yet gotten Pharo, Squeak and Java talking. What I was able to accomplish, after finishing the port of Cryptography's ASN1Types, Module and Streams is to get Java's rendezvous and key exchange working. After I got that connecting, I looked at the ciphers, ivSequences and MAC and got that working. In Java, I am now able to encrypt and decrypt "hello world". *Celebrates* - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations > Local Time: October 25, 2017 12:00 PM > UTC Time: October 25, 2017 4:00 PM > From: henry(a)callistohouse.club > To: Ben Coman <btc(a)openinworld.com>, Squeak-dev <squeak-dev(a)lists.squeakfoundation.org>, Pharo-users list <pharo-users(a)lists.pharo.org> > Pharo Development List <pharo-dev(a)lists.pharo.org> > > I disabled vatId authorization in version 3, located in SessionOperations>>processIWant | SessionOperations>>processIAm:. > > I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt. > > ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document. > > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… > > For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo. > > http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz > http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz > > The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda. > > http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz > http://www.squeaksource.com/Oceanside/hubbub-HenryHouse.38.mcz > > Hubbub currently fails to load correctly in Pharo. In Squeak the two ParrotRemoteTestCases: LookupTestCase and OperationalTestCase really screw everything up, do not save an image after running. I never run these tests until I get a better handle of serialization. Currently, do to a shift in progress to STON, the serialization tests fail, just the way we like it. Fix the tests then the system starts to work right. > > The shift away from vatId authorization should not adversely affect hubbub, we hope! When STON starts to work, and I think I need to turn off jsonMode, then traffic between vats can start to be analyzed and figure out how resolving is working with redirectors invoked remotely. > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations >> Local Time: October 25, 2017 12:43 AM >> UTC Time: October 25, 2017 4:43 AM >> From: btc(a)openinworld.com >> To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> >> Stephane Ducasse <stepharo.self(a)gmail.com> >> >> If I google... parrottalk protocol >> nothing seems related. So what is ParrotTalk? >> >> P.S... since this is not "part of" pharo, [pharo-users] would be a better place for discussion than [pharo-dev]. >> Could you re-announce there, with some description of use cases and who/where the protocol is used? >> >> cheers -ben >> >> On Wed, Oct 25, 2017 at 1:42 AM, henry <henry(a)callistohouse.club> wrote: >> >>> Please excuse all the low-level detail, if inappropriate to the discussion. The protocol changes are here specified. >>> >>> - HH >>> >>> On Tue, Oct 24, 2017 at 13:40, henry <henry(a)callistohouse.club> wrote: >>> >>>> In order to bring ParrotTalk-3.6 support, alongside historical 3.5 support, the frame header stays the same and the processing of the ProtocolOffered would select "ParrotTalk-3.6" to use the compact protocol of >>>> >>>> - ProtocolOffered { offered, preferred } >>>> - ProtocolAccepted { accepted } >>>> - IWant|GiveInfo|ReplyInfo { vatId, domain, publicKey, cryptoProtocols, dataEncoders } >>>> - IAm|ReplyInfo { vatId, domain, publicKey, cryptoProtocol, dataEncoder, dhParam } >>>> - Go { cryptoProtocol, dataEncoder, dhParam, signature } >>>> - GoToo { signature } >>>> >>>> Using eLinda : >>>> >>>> http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz >>>> >>>> Above the FrameBuffer, below the SessionOperations for each version of the protocol, an ELindaSession could be inserted. This session think would have the stacks for each protocol version SessionOperation registered by protocol in a Tuple, for eventual callback. When the ProtocolOffered comes in we publish the tuple frame, with set selected version, to route to the correct SessionOperation to support each version of the protocol. >>>> >>>> With a non-specific vatId required, anonymous connections would be supported. >>>> >>>> - HH >>>> >>>> On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>>> Hi henry thanks for this announce. Can you tell where such protocols are used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry wrote: > Hi all, > > I am happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and Pharo, found here: > > http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows this specification: > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… > > One item of note, in version 3.5, the system connecting to a server, sending > the IWant msg, must know the vatId of the system being connected to. I am > considering changing this to version 3.6 by removing one round-trip in > messaging. Therefore, these messages would be combined: IWant/GiveInfo, > IAm/ReplyInfo. I will keep ProtocolOffered and ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and 3.6. > > Thoughts please? > > - HH

Oct. 31, 2017

[Pharo 7.0-dev] Build #248: 20599 make kernel independent of deprecated file stream

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

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

Oct. 31, 2017

Re: [Pharo-dev] Github API on github

by Ronie Salgado

Hi, This looks interesting. Maybe I should migrate Thermite into using some of this bindings. In Thermite I am using my custom wrapper for the GitHub API, Best regards, Ronie 2017-10-30 13:50 GMT-03:00 Torsten Bergmann <astares(a)gmx.de>: > Hi Guille, > > nice. Instead of just two we can merge all three into a single solution. > As I proposed > it should be made available for instance on a general URL like: > > https://github.com/pharo-vcs/github-api > > so we could work and improve on it all together. > > Thanks > Torsten > > > Gesendet: Montag, 30. Oktober 2017 um 17:24 Uhr > Von: "Guillermo Polito" <guillermopolito(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Github API on github > > Hi all, > > So I talked with Skip (Balletie) and he's not planning on supporting the > github api he hosted because he's not doing pharo any time soon. So he has > for the moment transferred the ownership of his project to me: > > https://github.com/guillep/Github > > I'll work soon in merging both > > https://github.com/guillep/Github[https://github.com/guillep/Github] > > and > > https://github.com/guillep/github-api[https://github.com/ > guillep/github-api] > > to have a single solution. > > To answer Esteban and Norbert, I try to keep it small and modular :) But > those are really high-level goals. What do you want to "not load" or what > is bothering? > > Because I'll not cut the library so you can load services in a 'per-class' > basis. That will be impossible to maintain in the long term... We need to > find an equilibrium between modularity and reuse. Right now the github API > embedded in Iceberg is not completely reusable either. > > >

Oct. 31, 2017

[Pharo 7.0-dev] Build #247: 20609-defaultBackgroundColor-should-be-removed-from-Object

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

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

Oct. 31, 2017

[Pharo 7.0-dev] Build #246: 20155-Browse-implementers-of-in-Nautilus-doesnt-parse-source-code-properly-for-methods-in-a-block

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

There is a new Pharo build available! The status of the build #246 was: FAILURE. The Pull Request #410 was integrated: "20155-Browse-implementers-of-in-Nautilus-doesnt-parse-source-code-properly-for-methods-in-a-block" Pull request url: https://github.com/pharo-project/pharo/pull/410 Issue Url: https://pharo.fogbugz.com/f/cases/20155 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 31, 2017

potentially useful diagrams

by Stephane Ducasse

Hi during the last sprint we were brainstorming how we can help people to understand the git hub setup. I produced these two diagrams with christophe. Are they useful for you? Stef

Oct. 31, 2017