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

Re: [Pharo-dev] About Collator

by Nicolas Cellier

As for -1 , 0 , 1, we must encode 3 possible results: value1 is before value2 (<) value1 is same rank as value2 (=) value1 is after value2 (>) Using numbers -1,0,+1 to encode these results is clever, because it's trivial to revert the order (just take the opposite, or multiply by -1) So it's widespread in programming community, it's cultural We could use any other convention like Symbols #(< = >), that would convey a bit more meaning, but there's no need to go against culture if we have no superior solution (wrt inversion) 2017-11-05 18:30 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Hi Stef > > Collation is the accurate and correct term > If I google: Unicode comparison algorithm for example, the first hit is: > UTS #10: Unicode Collation Algorithm - Unicode.org > http://unicode.org/reports/tr10/ > > collationner (collate) has a second meaning, even in French: > https://fr.wiktionary.org/wiki/collationner > > Interestingly, the wikipedia page https://en.wikipedia.org/wiki/Collation > isn't even translated in French... > Maybe i's not popular enough in French (un mot savant)... > I'm not good enough in English to tell if it has same "snob" connotation > > Nicolas > > 2017-11-05 17:49 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> Hi nicolas >> >> where it is defined that collation is something returning -1, 0, 1? >> I'm always thinking to newcomers that have to learn yet another >> concept and here for nothing. >> Because SortFunction with a nice comment saying that it should return >> -1, 0, 1 looks simpler that CollatorFunction which tells me nothing, >> except that may be this is about drinking (for french). >> >> >> Stef >> >> On Sun, Nov 5, 2017 at 3:47 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> > >> > >> > 2017-11-05 10:16 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> >> >> >> >> >> > On 5 Nov 2017, at 06:00, Stephane Ducasse <stepharo.self(a)gmail.com> >> >> > wrote: >> >> > >> >> > Hi guys >> >> > >> >> > Why do we rename class Sort to introduce terms that have unknown, >> >> > unclear, undocumented meaning? >> >> >> >> +1 >> >> >> >> > >> >> > To me PluggableSortFunction is MUCH better than >> CollatorBlockFunction. >> >> >> >> but pluggable is also bad, IMO. >> >> also I see there is some incoherence in the names: >> > >> > >> > agree with Esteban, Pluggable pouah! >> > >> >> >> >> ChainedSortFunction -> this is kind of ok, but I think a >> >> âComposedSortFunctionâ is better. >> > >> > >> > But there can be several kind of composition... >> > For example wrapped as illustrated with UnderfinedSorter refactoring >> that I >> > proposed. >> > Personnally I like Chained because it explicitely tells the kind of >> > composition >> > >> >> SortByPropertyFunction -> shouldnât be âPropertySortFunctionâ ? >> (coherent >> >> with the previous one) >> > >> > >> > +1 for PropertySortFunction, or maybe just PropertySorter >> > >> >> CollatorSortFunction -> this is like a âBlockSortFunctionâ or >> >> âValuableSortFunctionâ ? >> > >> > >> > CollatorBlockFunction is only a proxy to the block so as it answers to >> > #threeWayCompare:with: protocol rather than value:value: >> > It's a Block view as a CollatorFunction. >> > The name first surprised me negatively, but after reflexion it tells >> what it >> > is. >> > >> > 1) Collator indicates that the block (valuable) will return -1, 0 or +1 >> > >> > 2) It's not necessarily a block, it could be anything understanding >> > value:value: >> > But, the valuable should return -1,0,+1, so apart <=> >> (threeWayCompareTo:) >> > it ain't gonna be anything but a block in practice. >> > For <=> we would want a DefaultSortFunction and would not use a >> > CollatorBlockFunction. >> > >> > 3) Function refers to SortFunction. >> > For this, I'm neutral, whether you call it Sorter or SortFunction I >> don't >> > care. >> > SortFunction kind of implies these are stateless, so it's a rather good >> and >> > accurate name. >> > Maybe a Sorter could be more confusing, because a Sorter could be >> thought as >> > having the sorted collection as instance variable (statefull). >> > >> > Nicolas >> > >> >> >> >> Esteban >> >> >> >> > >> >> > Stef >> >> > >> >> >> >> >> > >> >> >

Nov. 5, 2017

Re: [Pharo-dev] About Collator

by Nicolas Cellier

Hi Stef Collation is the accurate and correct term If I google: Unicode comparison algorithm for example, the first hit is: UTS #10: Unicode Collation Algorithm - Unicode.org http://unicode.org/reports/tr10/ collationner (collate) has a second meaning, even in French: https://fr.wiktionary.org/wiki/collationner Interestingly, the wikipedia page https://en.wikipedia.org/wiki/Collation isn't even translated in French... Maybe i's not popular enough in French (un mot savant)... I'm not good enough in English to tell if it has same "snob" connotation Nicolas 2017-11-05 17:49 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi nicolas > > where it is defined that collation is something returning -1, 0, 1? > I'm always thinking to newcomers that have to learn yet another > concept and here for nothing. > Because SortFunction with a nice comment saying that it should return > -1, 0, 1 looks simpler that CollatorFunction which tells me nothing, > except that may be this is about drinking (for french). > > > Stef > > On Sun, Nov 5, 2017 at 3:47 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > > > 2017-11-05 10:16 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> > >> > >> > >> > On 5 Nov 2017, at 06:00, Stephane Ducasse <stepharo.self(a)gmail.com> > >> > wrote: > >> > > >> > Hi guys > >> > > >> > Why do we rename class Sort to introduce terms that have unknown, > >> > unclear, undocumented meaning? > >> > >> +1 > >> > >> > > >> > To me PluggableSortFunction is MUCH better than CollatorBlockFunction. > >> > >> but pluggable is also bad, IMO. > >> also I see there is some incoherence in the names: > > > > > > agree with Esteban, Pluggable pouah! > > > >> > >> ChainedSortFunction -> this is kind of ok, but I think a > >> âComposedSortFunctionâ is better. > > > > > > But there can be several kind of composition... > > For example wrapped as illustrated with UnderfinedSorter refactoring > that I > > proposed. > > Personnally I like Chained because it explicitely tells the kind of > > composition > > > >> SortByPropertyFunction -> shouldnât be âPropertySortFunctionâ ? > (coherent > >> with the previous one) > > > > > > +1 for PropertySortFunction, or maybe just PropertySorter > > > >> CollatorSortFunction -> this is like a âBlockSortFunctionâ or > >> âValuableSortFunctionâ ? > > > > > > CollatorBlockFunction is only a proxy to the block so as it answers to > > #threeWayCompare:with: protocol rather than value:value: > > It's a Block view as a CollatorFunction. > > The name first surprised me negatively, but after reflexion it tells > what it > > is. > > > > 1) Collator indicates that the block (valuable) will return -1, 0 or +1 > > > > 2) It's not necessarily a block, it could be anything understanding > > value:value: > > But, the valuable should return -1,0,+1, so apart <=> > (threeWayCompareTo:) > > it ain't gonna be anything but a block in practice. > > For <=> we would want a DefaultSortFunction and would not use a > > CollatorBlockFunction. > > > > 3) Function refers to SortFunction. > > For this, I'm neutral, whether you call it Sorter or SortFunction I don't > > care. > > SortFunction kind of implies these are stateless, so it's a rather good > and > > accurate name. > > Maybe a Sorter could be more confusing, because a Sorter could be > thought as > > having the sorted collection as instance variable (statefull). > > > > Nicolas > > > >> > >> Esteban > >> > >> > > >> > Stef > >> > > >> > >> > > > >

Nov. 5, 2017

Re: [Pharo-dev] about SortFunctions

by Stephane Ducasse

Hi guys Do you have some nice comments somewhere? because I do not understand anything about this thread. I check the code and the comments are well... unclear and confusing. Stef On Sun, Nov 5, 2017 at 4:15 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-11-05 16:06 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> >> 2017-11-05 11:33 GMT+01:00 Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com>: >>> >>> >>> Ah, I messed up, UndefinedSorter must not be chained, it must be a >>> wrapper! >>> Otherwise comparing to nil will resort to sorting by properties and >>> fail... >>> >>> SortFunction>>undefinedFirst >>> ^UndefinedSorter descending wrap: self >>> >>> UndefinedSorter>> collate: value1 with: value2 >>> "sort all nil according to the direction (first if -1, last if >>> +1), then" >>> value1 ifNil: [value2 ifNil: [^0] ifNotNil: [^direction]]. >>> value2 ifNil: [^direction negated]. >>> ^sorterForNonNil collate: value1 with: value2 >>> >>> It's important to have the UndefinedSorter : >>> - decoupled from property sort, because it can be generally usefull >>> - collating 2 nil as 0, so that another property can be chained >> >> >> I like your idea. >> It also forced me to think that direction itself should be implemented as >> wrapper. I would name it InvertedSortFunction: >> >> InvertedSortFunction>>collate: value1 with: value2 >> ^(actualSortFunction collate: value1 with: value2) * -1 >> >> >> If we will do it then direction will be not part of SortFunction. And all >> current functions will be in fact ascending. >> And to explicitly reflect this fact I would introduce >> AscendingSortFunction as their superclass. >> InvertedSortFunction and ChainedSortFunction will stay subclasses of >> SortFunction. >> >> So what you think? > > > Yes, I was thinking the same. > On another hand, direction makes thing symmetric and has its elegance too. > What I don't like with it is that it forces the library to have two > different messages for the same thing: > - collate:with: in base class accounting for direction > - threeWayCompare:with: in every subclass > > The fact to hardcode the direction in base class could be seen as an > optimization too. > I'm not sure what Sista optimization could bring in this case, because the > selectors may get megamorphic... > > >> >>> >>> >>> In >>> >>> people sortBy: #name ascending undefinedFirst , #age descending >>> >>> we could then have people with name nil still sorted by age, what is not >>> possible with current implementation >>> >> >

Nov. 5, 2017

Re: [Pharo-dev] About Collator

by Stephane Ducasse

Hi nicolas where it is defined that collation is something returning -1, 0, 1? I'm always thinking to newcomers that have to learn yet another concept and here for nothing. Because SortFunction with a nice comment saying that it should return -1, 0, 1 looks simpler that CollatorFunction which tells me nothing, except that may be this is about drinking (for french). Stef On Sun, Nov 5, 2017 at 3:47 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-11-05 10:16 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> >> > On 5 Nov 2017, at 06:00, Stephane Ducasse <stepharo.self(a)gmail.com> >> > wrote: >> > >> > Hi guys >> > >> > Why do we rename class Sort to introduce terms that have unknown, >> > unclear, undocumented meaning? >> >> +1 >> >> > >> > To me PluggableSortFunction is MUCH better than CollatorBlockFunction. >> >> but pluggable is also bad, IMO. >> also I see there is some incoherence in the names: > > > agree with Esteban, Pluggable pouah! > >> >> ChainedSortFunction -> this is kind of ok, but I think a >> âComposedSortFunctionâ is better. > > > But there can be several kind of composition... > For example wrapped as illustrated with UnderfinedSorter refactoring that I > proposed. > Personnally I like Chained because it explicitely tells the kind of > composition > >> SortByPropertyFunction -> shouldnât be âPropertySortFunctionâ ? (coherent >> with the previous one) > > > +1 for PropertySortFunction, or maybe just PropertySorter > >> CollatorSortFunction -> this is like a âBlockSortFunctionâ or >> âValuableSortFunctionâ ? > > > CollatorBlockFunction is only a proxy to the block so as it answers to > #threeWayCompare:with: protocol rather than value:value: > It's a Block view as a CollatorFunction. > The name first surprised me negatively, but after reflexion it tells what it > is. > > 1) Collator indicates that the block (valuable) will return -1, 0 or +1 > > 2) It's not necessarily a block, it could be anything understanding > value:value: > But, the valuable should return -1,0,+1, so apart <=> (threeWayCompareTo:) > it ain't gonna be anything but a block in practice. > For <=> we would want a DefaultSortFunction and would not use a > CollatorBlockFunction. > > 3) Function refers to SortFunction. > For this, I'm neutral, whether you call it Sorter or SortFunction I don't > care. > SortFunction kind of implies these are stateless, so it's a rather good and > accurate name. > Maybe a Sorter could be more confusing, because a Sorter could be thought as > having the sorted collection as instance variable (statefull). > > Nicolas > >> >> Esteban >> >> > >> > Stef >> > >> >> >

Nov. 5, 2017

nice CSS for the Pharo online HTML version?

by Stephane Ducasse

Hi Iâm looking for a nice CSS for the Pharo online HTML version. I found something like that https://www.smashingmagazine.com/2015/02/designers-start-coding-with-uilang/ Stef -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Nov. 5, 2017

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

by henry

I was a latecomer to all the work the Cryptography Team put together, all functions and ciphers and hashes they put together. I helped add ASN.1, later on. They did the hard work I put some pieces together. I heard someone likes it. That makes me happy. Henry Sent from ProtonMail Mobile On Fri, Nov 3, 2017 at 00:04, Ben Coman <btc(a)openinworld.com> wrote: > 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.h… > * 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: ( >> (hashPad der hash: sharedKey pad: 16rCC), >> (hashPad der hash: sharedKey pad: 16rBB), >> (hashPad der hash: sharedKey pad: 16rAA), >> (hashPad der hash: sharedKey pad: 16r99)). >> macKey := macKey, (MD5 hashMessage: ( >> (hashPadder hash: sharedKey pad: 16r88), >> (hashPad der hash: sharedKey pad: 16r77), >> (hashPad der hash: sharedKey pad: 16r66), >> (hashPad der hash: sharedKey pad: 16r55))). >> macKey := macKey, (MD5 hashMessage: ( >> (hashPad der hash: sharedKey pad: 16r44), >> (hashPad der hash: sharedKey pad: 16r33), >> (hashPad der hash: sharedKey pad: 16r22), >> (hashPad der 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 considerationsLocal 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>>processIWan t | 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 { v atId, 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. 5, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

2017-11-05 16:06 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-11-05 11:33 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> Ah, I messed up, UndefinedSorter must not be chained, it must be a >> wrapper! >> Otherwise comparing to nil will resort to sorting by properties and >> fail... >> >> SortFunction>>undefinedFirst >> ^UndefinedSorter descending wrap: self >> >> UndefinedSorter>> collate: value1 with: value2 >> "sort all nil according to the direction (first if -1, last if >> +1), then" >> value1 ifNil: [value2 ifNil: [^0] ifNotNil: [^direction]]. >> value2 ifNil: [^direction negated]. >> ^sorterForNonNil collate: value1 with: value2 >> >> It's important to have the UndefinedSorter : >> - decoupled from property sort, because it can be generally usefull >> - collating 2 nil as 0, so that another property can be chained >> > > I like your idea. > It also forced me to think that direction itself should be implemented as > wrapper. I would name it InvertedSortFunction: > > InvertedSortFunction>>collate: value1 with: value2 > ^(actualSortFunction collate: value1 with: value2) * -1 > > > If we will do it then direction will be not part of SortFunction. And all > current functions will be in fact ascending. > And to explicitly reflect this fact I would introduce > AscendingSortFunction as their superclass. > InvertedSortFunction and ChainedSortFunction will stay subclasses of > SortFunction. > > So what you think? > Yes, I was thinking the same. On another hand, direction makes thing symmetric and has its elegance too. What I don't like with it is that it forces the library to have two different messages for the same thing: - collate:with: in base class accounting for direction - threeWayCompare:with: in every subclass The fact to hardcode the direction in base class could be seen as an optimization too. I'm not sure what Sista optimization could bring in this case, because the selectors may get megamorphic... > >> >> In >> >> people sortBy: #name ascending undefinedFirst , #age descending >> >> we could then have people with name nil still sorted by age, what is not >> possible with current implementation >> >> >

Nov. 5, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

2017-11-05 11:33 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > Ah, I messed up, UndefinedSorter must not be chained, it must be a > wrapper! > Otherwise comparing to nil will resort to sorting by properties and fail... > > SortFunction>>undefinedFirst > ^UndefinedSorter descending wrap: self > > UndefinedSorter>> collate: value1 with: value2 > "sort all nil according to the direction (first if -1, last if +1), > then" > value1 ifNil: [value2 ifNil: [^0] ifNotNil: [^direction]]. > value2 ifNil: [^direction negated]. > ^sorterForNonNil collate: value1 with: value2 > > It's important to have the UndefinedSorter : > - decoupled from property sort, because it can be generally usefull > - collating 2 nil as 0, so that another property can be chained > I like your idea. It also forced me to think that direction itself should be implemented as wrapper. I would name it InvertedSortFunction: InvertedSortFunction>>collate: value1 with: value2 ^(actualSortFunction collate: value1 with: value2) * -1 If we will do it then direction will be not part of SortFunction. And all current functions will be in fact ascending. And to explicitly reflect this fact I would introduce AscendingSortFunction as their superclass. InvertedSortFunction and ChainedSortFunction will stay subclasses of SortFunction. So what you think? > > In > > people sortBy: #name ascending undefinedFirst , #age descending > > we could then have people with name nil still sorted by age, what is not > possible with current implementation > >

Nov. 5, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

2017-11-05 15:27 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi Nicolas. > > We had discussion on operator <=> in original case where SortFunction was > integrated https://pharo.fogbugz.com/f/cases/17728/ > Integrate-Travis-Griggs-TAG-SortFunctions. > > > Thanks for the link Denis. I'm happy to see that Sven used exactly same arguments as me :) Everything was said... I still disagree with this decision. It would be nice to ask for vox populi in the mailing list for such decision. Even if vox populi may not lead to the wisest decision, it sound less arbitrary... At least it can give greater chances for expressing different opinions and arguments. Bug reports are way too much confidential (and this one is not even public!). But that's a only a small detail. We'd better look foreward, and discuss the composability features, notably the fact that - property sort does allways use the default sort <=> and cannot be composed - Undefined sort function is a general utility and should be implemented in own class Nicolas 2017-11-05 0:37 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> Hi all, >> I started a discussion with Denis in a pull request >> https://github.com/pharo-project/pharo/pull/430 >> But since it's going beyond simple code review, it probably has a better >> place here. >> >> First, I want to say thanks for enriching this original work of Travis >> Griggs. >> http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html >> http://objology.blogspot.fr/2010/11/tag-sortfunctions.html >> <http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html> >> >> Of course, I'm never satisfied. >> So I don't really appreciate the rewrite of space ship operator <=> into >> a more heavy threeWayCompareTo: >> >> In my eyes, it's so obvious that <=> means < or = or > in the context of >> SortFunction >> And also that the order matches the signs >> < = > >> -1 0 1 >> IOW result will be -1 if receiver is <, 0 if equal, +1 if superior >> >> #threeWayCompareTo: does not tell as well. >> But maybe It's a question of taste and I don't have the same eyes as >> Pharo people? >> To me it's also a question of respect to the original author, don't >> change a good selector for the sake of changing. >> >> Apart this detail, I wanted to speak about SortByPropertyFunction. >> SortByProperty is super usefull for composing / chaining like this: >> >> population sortBy: #name ascending , #age descending. >> >> But currently, SortByPropertyFunction is allways using the default >> hardcoded collation <=> ... He he, it's also notice it's shorter to write ;) >> >> Imagine that my properties are neither String nor Magnitude, or they are, >> but I want a different collation policy, because in French $Ã© must not be >> sorted too far from $e. >> >> It could be written quite simply with: >> >> c sortBy: #name collatedInFrench ascending , #age descending >> >> With current implementation, collatedInFrench would have to use a block >> (thru a CollatorBlockFunction which is a proxy to the block in a >> SortFunction disguise): >> >> Symbol>>collatedInFrench >> "interpret self as a property" >> ^[:a :b | FrenchCollator collate: (self value: a) with: (self >> value: b)] >> >> But IMO SortByPropertyFunction should better feed a reified >> CollatorFunction, or said differently a SortFunction, as Denis said. >> >> Symbol>>collatedInFrench >> ^FrenchCollator new onProperty: self >> >> SortFunction>>onProperty: aValuable >> ^SortByPropertyFunction sortProperty: aValuable with: self >> >> What do you think? >> >> Nicolas >> >> >

Nov. 5, 2017

Iceberg Clone Location

by Sean P. DeNigris

I have a problem I'm not sure how to solve. In many of my baselines for personal private projects, I have dependencies with filetree URL repositories. IIUC, that was the best practice when I asked on the MetaC mailing list. The file URLS are all of the form {sharedRepoFolder}/{projectName}. Now Iceberg seems to expect clones to be in {sharedRepoFolder}/{gitHubUser}/{projectName}. It doesn't find them there, and then clones everything anew. I have a few concerns about this, not the least of which is the thought of having to redo all my baselines. That said, I realize that maybe this is inevitable, so I wanted to put this out there to see if I'm missing something and the best way to proceed. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 5, 2017