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

Tonel questions

by Stephane Ducasse

Hi Should I download the latest Pharo 7 image? Yes Should I fork again the Pharo-project? Should I clone again the Pharo-project? Stef

Nov. 3, 2017

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

by Ben Coman

On Fri, Nov 3, 2017 at 4:06 AM, henry <henry(a)callistohouse.club> wrote: > I have a question about my derivation of a MAC key. It is very complicated > and I am considering ways to simplify for use by potential language > implementations. Here is the current derivation in Squeak/Pharo. Should I > just use the sharedKey as the SHA1HMAC key or some simplified hash of the > sharedKey, without all the pad hashings I am doing? What do you think? I > want to hear from you. > Hi Henry, I'd guess not many people here are *really* competent enough in crypto to confidently advise you. I know I'm not. I only know enough to know crypto is *hard*. * https://www.happybearsoftware.com/you-are-dangerously-bad- at-cryptography.html * https://www.schneier.com/blog/archives/2011/04/schneiers_law.html * https://www.schneier.com/essays/archives/1997/01/why_cryptography_is.html I hope that doesn't discourage you, and I'm interested to hear a more useful reply from anyone else. cheers -ben P.S. I just bumped into what looks like an interesting intellectual exercise... http://cryptopals.com/ > > makeHMAC > > | sharedKey hashPadder macKey | > sharedKey := diffieHellman sharedKeyPadPositiveByteArray. > hashPadder := self class. > macKey := MD5 hashMessage: ( > (hashPadder hash: sharedKey pad: 16rCC), > (hashPadder hash: sharedKey pad: 16rBB), > (hashPadder hash: sharedKey pad: 16rAA), > (hashPadder hash: sharedKey pad: 16r99)). > macKey := macKey, (MD5 hashMessage: ( > (hashPadder hash: sharedKey pad: 16r88), > (hashPadder hash: sharedKey pad: 16r77), > (hashPadder hash: sharedKey pad: 16r66), > (hashPadder hash: sharedKey pad: 16r55))). > macKey := macKey, (MD5 hashMessage: ( > (hashPadder hash: sharedKey pad: 16r44), > (hashPadder hash: sharedKey pad: 16r33), > (hashPadder hash: sharedKey pad: 16r22), > (hashPadder hash: sharedKey pad: 16r11))). > ^ SHA1 new hmac key: macKey. > > Would a better way forwards is simply this? > > makeHMAC > > macKey := diffieHellman sharedKeyPadPositiveByteArray. > ^ SHA1 new hmac key: macKey. > > > Thank you. > > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk > release/design change considerations > Local Time: November 2, 2017 3:50 PM > UTC Time: November 2, 2017 7:50 PM > From: henry(a)callistohouse.club > To: henry <henry(a)callistohouse.club> > 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 have developed the ParrotTalk Protocol, documented in part here[1], > while I have two implementations: 1 in Squeak/Pharo [2 a/b] and the other > in Java [3 a/b]. Particulars of some decisions are absent from the > specification: namely the MAC key and ivSequence derivations, as well as > constrained traffic signing; they are in the implementations. I will update > the 3.6 slideshow to specify these items. > > Thank you. > > - HH > > [1] - ParrotTalk Protocol : http://jmp.sh/OqlYpyg > > Squeak/Pharo implementation > [2 a] - http://www.squeaksource.com/Cryptography/Cryptography-Henr > yHouse.113.mcz > [2 b] - http://www.squeaksource.com/Cryptography/ParrotTalk-HenryH > ouse.9.mcz > > Java implementation > [3 a] - https://github.com/ZiroZimbarra/ASN1 > [3 b] - https://github.com/ZiroZimbarra/ParrotTalk > > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk > release/design change considerations > Local Time: November 2, 2017 3:43 PM > UTC Time: November 2, 2017 7:43 PM > From: henry(a)callistohouse.club > To: 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> > > More celebration requested. I got encrypted data passing between > Squeak/Pharo and Java: AES with CBC and IVs and SHA1 HMAC. It works! > NSA-proof crypto rocking Squeak, Pharo & Java! > > *Celebrates again, drinks for everyone* > > > - HH > > > -------- Original Message -------- > Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk > release/design change considerations > Local Time: October 31, 2017 1:54 PM > UTC Time: October 31, 2017 5:54 PM > From: henry(a)callistohouse.club > To: henry <henry(a)callistohouse.club> > Ben Coman <btc(a)openinworld.com>, Squeak-dev <squeak-dev(a)lists.squeakfounda > tion.org>, Pharo-users list <pharo-users(a)lists.pharo.org>, Pharo > Development List <pharo-dev(a)lists.pharo.org> > > 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/ParrotTalkFrameDesign-3.5.pdf > > 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/Cr >> yptography/ParrotTalk-zzz.2.mcz > > It follows this specification: > >> https://github.com/ZiroZimbarra/callistohouse/blob/master/do >> cs/ParrotTalkFrameDesign-3.5.pdf > > 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 >> >> > > > > > > > >

Nov. 3, 2017

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

by Cyril Ferlicot D.

Le 02/11/2017 Ã 20:01, Stephane Ducasse a Ã©critÂ : > Super tx Cyril > Tx dale. I think that Camillo back then introduced Job. > Stef > > Hi, The issue is corrected in Metacello/metacello on github and Dale updated the Pharo 6.1/7.0 tags. (Thank you) Now, how should I integrate it in Pharo? Will it be automatic since the tags changed? Should I integrate the change as I would do for a package managed internally during the time the process is not well defined for external projects? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 2, 2017

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

by henry

I have a question about my derivation of a MAC key. It is very complicated and I am considering ways to simplify for use by potential language implementations. Here is the current derivation in Squeak/Pharo. Should I just use the sharedKey as the SHA1HMAC key or some simplified hash of the sharedKey, without all the pad hashings I am doing? What do you think? I want to hear from you. makeHMAC | sharedKey hashPadder macKey | sharedKey := diffieHellman sharedKeyPadPositiveByteArray. hashPadder := self class. macKey := MD5 hashMessage: ( (hashPadder hash: sharedKey pad: 16rCC), (hashPadder hash: sharedKey pad: 16rBB), (hashPadder hash: sharedKey pad: 16rAA), (hashPadder hash: sharedKey pad: 16r99)). macKey := macKey, (MD5 hashMessage: ( (hashPadder hash: sharedKey pad: 16r88), (hashPadder hash: sharedKey pad: 16r77), (hashPadder hash: sharedKey pad: 16r66), (hashPadder hash: sharedKey pad: 16r55))). macKey := macKey, (MD5 hashMessage: ( (hashPadder hash: sharedKey pad: 16r44), (hashPadder hash: sharedKey pad: 16r33), (hashPadder hash: sharedKey pad: 16r22), (hashPadder hash: sharedKey pad: 16r11))). ^ SHA1 new hmac key: macKey. Would a better way forwards is simply this? makeHMAC macKey := diffieHellman sharedKeyPadPositiveByteArray. ^ SHA1 new hmac key: macKey. Thank you. - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations > Local Time: November 2, 2017 3:50 PM > UTC Time: November 2, 2017 7:50 PM > From: henry(a)callistohouse.club > To: henry <henry(a)callistohouse.club> > 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 have developed the ParrotTalk Protocol, documented in part here[1], while I have two implementations: 1 in Squeak/Pharo [2 a/b] and the other in Java [3 a/b]. Particulars of some decisions are absent from the specification: namely the MAC key and ivSequence derivations, as well as constrained traffic signing; they are in the implementations. I will update the 3.6 slideshow to specify these items. > > Thank you. > > - HH > > [1] - ParrotTalk Protocol : http://jmp.sh/OqlYpyg > > Squeak/Pharo implementation > [2 a] - http://www.squeaksource.com/Cryptography/Cryptography-HenryHouse.113.mcz > [2 b] - http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.9.mcz > > Java implementation > [3 a] - https://github.com/ZiroZimbarra/ASN1 > [3 b] - https://github.com/ZiroZimbarra/ParrotTalk > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations >> Local Time: November 2, 2017 3:43 PM >> UTC Time: November 2, 2017 7:43 PM >> From: henry(a)callistohouse.club >> To: 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> >> >> More celebration requested. I got encrypted data passing between Squeak/Pharo and Java: AES with CBC and IVs and SHA1 HMAC. It works! NSA-proof crypto rocking Squeak, Pharo & Java! >> >> *Celebrates again, drinks for everyone* >> >> - HH >> >>> -------- Original Message -------- >>> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations >>> Local Time: October 31, 2017 1:54 PM >>> UTC Time: October 31, 2017 5:54 PM >>> From: henry(a)callistohouse.club >>> To: henry <henry(a)callistohouse.club> >>> 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 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

Nov. 2, 2017

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

by henry

I have developed the ParrotTalk Protocol, documented in part here[1], while I have two implementations: 1 in Squeak/Pharo [2 a/b] and the other in Java [3 a/b]. Particulars of some decisions are absent from the specification: namely the MAC key and ivSequence derivations, as well as constrained traffic signing; they are in the implementations. I will update the 3.6 slideshow to specify these items. Thank you. - HH [1] - ParrotTalk Protocol : http://jmp.sh/OqlYpyg Squeak/Pharo implementation [2 a] - http://www.squeaksource.com/Cryptography/Cryptography-HenryHouse.113.mcz [2 b] - http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.9.mcz Java implementation [3 a] - https://github.com/ZiroZimbarra/ASN1 [3 b] - https://github.com/ZiroZimbarra/ParrotTalk - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations > Local Time: November 2, 2017 3:43 PM > UTC Time: November 2, 2017 7:43 PM > From: henry(a)callistohouse.club > To: 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> > > More celebration requested. I got encrypted data passing between Squeak/Pharo and Java: AES with CBC and IVs and SHA1 HMAC. It works! NSA-proof crypto rocking Squeak, Pharo & Java! > > *Celebrates again, drinks for everyone* > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations >> Local Time: October 31, 2017 1:54 PM >> UTC Time: October 31, 2017 5:54 PM >> From: henry(a)callistohouse.club >> To: henry <henry(a)callistohouse.club> >> 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 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

Nov. 2, 2017

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

by henry

More celebration requested. I got encrypted data passing between Squeak/Pharo and Java: AES with CBC and IVs and SHA1 HMAC. It works! NSA-proof crypto rocking Squeak, Pharo & Java! *Celebrates again, drinks for everyone* - HH > -------- Original Message -------- > Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations > Local Time: October 31, 2017 1:54 PM > UTC Time: October 31, 2017 5:54 PM > From: henry(a)callistohouse.club > To: henry <henry(a)callistohouse.club> > 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 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

Nov. 2, 2017

Re: [Pharo-dev] UFFI #rebuildFieldAccessors problem

by Todd Blanchard

I know this problem annonymousClassCreator ^ String streamContents: [ :stream | stream nextPutAll: '(FFITypeArray ofType: #'; print: self objectClass type class; nextPutAll: ' size: '; print: self objectClass numberOfElements; nextPutAll: ')' ] is where it code goes wrong. class is...a class. change to print: self objectClass type class displayString; > On Nov 2, 2017, at 12:00 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Juhuuu! it worked with Pharo 6.0 :) > > Which means there is a problem with Pharo 7.0. > I will appreciate any help. thanks! > > Cheers, > Alex > > On 2 November 2017 at 19:49, Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: > Hi, > > I have the following line in BaselineOfBloc: (postLoadBloc:) > FFIExternalStructure withAllSubclassesDo: #rebuildFieldAccessors. > If I don't rebuild accessors, some offsets are nil in external structures. > > However, on Windows 32bit it fails with the following exception: > <Pharo7.0 FFI-Error.PNG> > > How to reproduce: > Take Pharo 7 (http://files.pharo.org/get-files/70/pharo.zip <http://files.pharo.org/get-files/70/pharo.zip>) > VM (http://files.pharo.org/get-files/70/pharo-win-stable.zip <http://files.pharo.org/get-files/70/pharo-win-stable.zip>) > Excecute FFITestArrayStructure rebuildFieldAccessors > Links to Image and VM I took from SmalltalkCI. > > The reason I'm posting this is because Bloc Appveyour builds fail and more importantly Stef will give lectures in Prague and they will use Bloc for the semester projects. > Not being able to install Bloc on Windows is not nice :( > > We wanted to release alpha version of Bloc and now we can not. > > Cheers, > Alex >

Nov. 2, 2017

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

by Stephane Ducasse

Super tx Cyril Tx dale. I think that Camillo back then introduced Job. Stef On Thu, Nov 2, 2017 at 7:00 PM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > Cyrille has submitted a bug[1] and I believe that he is taking a crack at a > fix ... > > Personally I am not aware of whether or not > String>>displayProgressAt:from:to:during: still exists and if not whether or > not it is the approved api for interacting with progress bars ... I sort of > assumed that it was dropped because the progress bar API changed, but it may > have been inadvertently dropped on the floor, since it's absence is not an > error ... once the correct API is identified, the fix can be merged into the > master branch for Metacello. > > The next step would be to ensure that the latest version of Metacello is > included in new builds for Pharo6.1/7.0 and I believe that Esteban is > tackling that bit...There are now 6.1/7.0 tags for Metacello that are > presumably used by the Pharo build process ... > > Dale > > [1] https://github.com/Metacello/metacello/issues/466 > > On 11/02/2017 10:18 AM, Stephane Ducasse wrote: >> >> Hi dale >> >> I'm confused :) what we should do? >> I could not get it (ok I'm a doct waiting room so not a super place to >> check). >> Stef >> >> On Wed, Nov 1, 2017 at 4:43 PM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com> wrote: >>> >>> Ben, >>> >>> I took a look at this and Metacell has wrapped the load expressions with >>> a >>> MetacelloPlatform>>do:displaying: call that presumably is supposed to >>> show >>> the progress bars continuously during a Metacello load, but a check in >>> Pharo3.0 shows that the Pharo platform class don't override the default >>> implementation. >>> >>> The original implementation of the method was in the >>> Metacello-Platform,pharo package ... which was for Pharo1.0 --- so >>> Metacello >>> progress bar display has not been properly functioning since then (about >>> 5 >>> years) --- and not noticed until now:) >>> >>> It should be possible to implement that method for Pharo6.0/7.0 and see >>> continuous progress bars again ... >>> >>> Dale >>> >>> [1] >>> >>> https://github.com/Metacello/metacello/blob/master/repository/Metacello-Pla… >>> >>> >>> On 10/31/17 6:05 PM, Ben Coman wrote: >>> >>> I would guess the problem with doing this pervasively is (IIUC) that >>> Configurations are self-contained/self-bootstrapping so each >>> Configurationhas its own copy of #load (I've no access to an Image to >>> check >>> right now) >>> Perhaps it could be a use case for metalinks. When Configurations are >>> loaded, insert a #notify: at the end of certain api methods. >>> >>> cheers -ben >>> >>> On Wed, Nov 1, 2017 at 4:50 AM, Stephane Ducasse >>> <stepharo.self(a)gmail.com> >>> wrote: >>>> >>>> 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 >>>>> >>> > >

Nov. 2, 2017

Re: [Pharo-dev] UFFI #rebuildFieldAccessors problem

by Aliaksei Syrel

Juhuuu! it worked with Pharo 6.0 :) Which means there is a problem with Pharo 7.0. I will appreciate any help. thanks! Cheers, Alex On 2 November 2017 at 19:49, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > I have the following line in BaselineOfBloc: (postLoadBloc:) > FFIExternalStructure withAllSubclassesDo: #rebuildFieldAccessors. > If I don't rebuild accessors, some offsets are nil in external structures. > > However, on Windows 32bit it fails with the following exception: > [image: Inline images 1] > > How to reproduce: > > 1. Take Pharo 7 (http://files.pharo.org/get-files/70/pharo.zip) > 2. VM (http://files.pharo.org/get-files/70/pharo-win-stable.zip) > 3. Excecute FFITestArrayStructure rebuildFieldAccessors > > Links to Image and VM I took from SmalltalkCI. > > The reason I'm posting this is because Bloc Appveyour builds fail and more > importantly Stef will give lectures in Prague and they will use Bloc for > the semester projects. > Not being able to install Bloc on Windows is not nice :( > > We wanted to release alpha version of Bloc and now we can not. > > Cheers, > Alex >

Nov. 2, 2017

UFFI #rebuildFieldAccessors problem

by Aliaksei Syrel

Hi, I have the following line in BaselineOfBloc: (postLoadBloc:) FFIExternalStructure withAllSubclassesDo: #rebuildFieldAccessors. If I don't rebuild accessors, some offsets are nil in external structures. However, on Windows 32bit it fails with the following exception: [image: Inline images 1] How to reproduce: 1. Take Pharo 7 (http://files.pharo.org/get-files/70/pharo.zip) 2. VM (http://files.pharo.org/get-files/70/pharo-win-stable.zip) 3. Excecute FFITestArrayStructure rebuildFieldAccessors Links to Image and VM I took from SmalltalkCI. The reason I'm posting this is because Bloc Appveyour builds fail and more importantly Stef will give lectures in Prague and they will use Bloc for the semester projects. Not being able to install Bloc on Windows is not nice :( We wanted to release alpha version of Bloc and now we can not. Cheers, Alex

Nov. 2, 2017