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

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win

by Raffaello Giulietti

Thanks Nicolas! On 2017-11-06 11:30, Nicolas Cellier wrote: > Oh yes, you're right, > the SqueakSLL could have been built but was not built in pharo... > I just changed > https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/p… > this should trigger another automated build and if all goes well you > will have a new bintray artefact to test. > > 2017-11-06 10:21 GMT+01:00 Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>>: > > Hi Nicolas, > > I tried both the vm found at the location you mention (dated > 2017-10-22): > > https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… > <https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p…> > > and the "official" latest vm on the Pharo site (dated 2017-11-01) > > http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1… > <http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1…> > > > > Neither of them contains the SqueakSSL.dll and, in fact, in both > cases I get an exception when using Gofer to download Roassal2, > using the latest 60519 image: > > Gofer it > Â Â smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > Â Â configurationOf: 'Roassal2'; > Â Â loadDevelopment > > This works on Pharo 32 bit/Win, where SquekSSL is present. > > > > > > > > > On 2017-11-04 23:31, Nicolas Cellier wrote: > > Note that win64 SSL works at least since > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510…> > and > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae… > <https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae…> > > Maybe it's a bit too recent to be found in official Pharo > distribution, but if you can live with bleeding edge, pick a > more recent VM here: > https://bintray.com/opensmalltalk/vm/cog/201710221351#files > <https://bintray.com/opensmalltalk/vm/cog/201710221351#files> > (or maybe you can find one from the Pharo site?) > > > 2017-11-04 22:21 GMT+01:00 henry <henry(a)callistohouse.club > <mailto:henry@callistohouse.club > <mailto:henry@callistohouse.club>>>: > > Â Â This is the advantage of in-image SSL solution, found in the > Â Â Cryptography repository: > > http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > Â Â <http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html>> > > Â Â Sent from ProtonMail Mobile > > > Â Â On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti > Â Â <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch> > Â Â <mailto:raffaello.giulietti@lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>>> wrote: > > Â Â Hi, the SqueakSSL dll is not included in the Pharo > 64bit/Win vm > Â Â distribution. I guess this has to do with problems in > building it. > Â Â Anybody knows where the difficulties lie? Greetings > Raffaello > > > > > >

Nov. 6, 2017

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win

by Nicolas Cellier

Oh yes, you're right, the SqueakSLL could have been built but was not built in pharo... I just changed https://github.com/OpenSmalltalk/opensmalltalk-vm/edit/Cog/build.win64x64/p… this should trigger another automated build and if all goes well you will have a new bintray artefact to test. 2017-11-06 10:21 GMT+01:00 Raffaello Giulietti < raffaello.giulietti(a)lifeware.ch>: > Hi Nicolas, > > I tried both the vm found at the location you mention (dated 2017-10-22): > > https://bintray.com/opensmalltalk/vm/download_file?file_ > path=cog_win64x64_pharo.cog.spur_201710221351.zip > > and the "official" latest vm on the Pharo site (dated 2017-11-01) > > http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64- > 201711010928-e14fbab.zip > > > > Neither of them contains the SqueakSSL.dll and, in fact, in both cases I > get an exception when using Gofer to download Roassal2, using the latest > 60519 image: > > Gofer it > smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > configurationOf: 'Roassal2'; > loadDevelopment > > This works on Pharo 32 bit/Win, where SquekSSL is present. > > > > > > > > > On 2017-11-04 23:31, Nicolas Cellier wrote: > >> Note that win64 SSL works at least since >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa >> 70862014d3bb510f2edf7465e857c645be0e4 >> and >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa >> 8241de11b99ecaea5236b3d3e3c0d303c6eb4 >> >> Maybe it's a bit too recent to be found in official Pharo distribution, >> but if you can live with bleeding edge, pick a more recent VM here: >> https://bintray.com/opensmalltalk/vm/cog/201710221351#files (or maybe >> you can find one from the Pharo site?) >> >> >> 2017-11-04 22:21 GMT+01:00 henry <henry(a)callistohouse.club <mailto: >> henry(a)callistohouse.club>>: >> >> This is the advantage of in-image SSL solution, found in the >> Cryptography repository: >> >> http://www.squeaksource.com/Cryptography.html >> <http://www.squeaksource.com/Cryptography.html> >> >> Sent from ProtonMail Mobile >> >> >> On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti >> <raffaello.giulietti(a)lifeware.ch >> <mailto:raffaello.giulietti@lifeware.ch>> wrote: >> >>> Hi, the SqueakSSL dll is not included in the Pharo 64bit/Win vm >>> distribution. I guess this has to do with problems in building it. >>> Anybody knows where the difficulties lie? Greetings Raffaello >>> >> >> >> > >

Nov. 6, 2017

Re: [Pharo-dev] Iceberg Clone Location

by Esteban Lorenzano

> On 5 Nov 2017, at 11:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > 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. I do not have a real solution for this. So far the url needs to have a kind of format and there is no way to change it. Yes we can make the search of projects a bit more intelligent but right now it is not there. The *trick* you can use (and Iâm not sure is a trick at all or even something good, but at least it works ;) ) is that iceberg does not clones a project that is already in the image. So if you installed project dependency {projectName}, it will find it on his list and it will use it. This has collateral not desired outputs (like if you ask for a tag or branch and it founds the project already there, it does not moves it to the place you asked for)â¦ I will fix that eventually :) Now, this forces you to install previously the dependences which can be not desired either :( Esteban > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Nov. 6, 2017

Re: [Pharo-dev] ExternalAddress uniqueness (was Re: Call for help for stability and rewrite of FreeType)

by Dimitris Chloupis

Its the usual case of not being able to have your cake and eat it too. If you want top performance you have to manage memory yourself plus the abilitiy to access thousands of C libraries is not such a bad excuse for a compromise. The FFI is not a problem is a solution to many problems and people using it its not as if Smalltalk offers them any alternative choice. Not to forget that Slang itself relies heavily on C, which is only the core of the VM and the very core of the implementation. Understanding how to work with pointers in C is pretty much understanding how to works with Objects in Smalltalk. Both are nuclear weapons that those two languages are build around. If ones does not understand their usage he will shoot his foot in the end. The important thing to remember is that C's goal is not the same as of Smalltalk. Its not there to hold your hand and make coding easy for you. C is there to offer low level access combined with top performance. It may have started as a general purpose language decades ago when coding in Assembly was still a pleasant experience. Nowdays C has completely replaced Assembly as the top performance language for low level coding. C may appear as a problematic language to a Smalltalker but only because he sees it from the Smalltalk point of view. The harsh reality of the world is that as much as one may want to shoehorn it , not everything can be elegantly mapped to a object. Smalltalk may be OO to the bone , but the world we live in, cannot afford such simple structures to accomodate of varied immense complexity. On the subject of pointers, the general rule of thumb is to keep things as simple as possible and avoide trying to do weird "magic" with them. There is a ton of things that C does under the hood to generate highly optimised machine code that can fry the brain , as the usual case with low level coding, so keeping it simple is the way to go. Oh and dont try to shoehorn the Live coding enviroment in debugging C code, as much as one may want to brag of Smalltalk's elegant debugger, C development tools are light years ahead in dealing with C problems. May advice to people is that if you do it via FFI first, you do it wrong. Do it always first with C with a powerful C IDE like Visual Studio, make sure your code works there and then use the UFFI. Will make life thousand times easier. I learned that the hard way when I was playing around with Pharo and shared memory. So yes having a FFI that does not help you avoid coding in C first, is a big plus, not a minus. Sometimes it makes sense to live outside the image, this is an excellent case to prove why that is a great idea. . On Mon, Nov 6, 2017 at 11:10 AM Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi Ben, > It's a super bad idea to copy an ExternalAddress. > It's common knowledge in C++ copy operator & copy constructors... > > But it's not obvious to me that you'll have double freeing (unless you > explicitely free the pointer by yourself). > If you use gcallocate: then only the original is registered for magical > auto-deallocation at garbage collection... > > What you will have is more somthing like dangling pointer: continue to use > pointer xa2->a1 when a1 was already freed. > > FFI is great, it introduces the problem of C in Smalltalk, augmented with > the problems of wrapping C in Smalltalk. > > > 2017-11-06 4:23 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> My current employment work hours and roster have severely curtailed the >> time I have hacking Pharo, so I've not dug enough to be sure of my >> observations a few months ago, and this is from memory, but I was starting >> to develop a suspicion about the uniqueness of ExternalAddress(s). >> >> A while ago, in order to fix some stability issues on Windows, a guard >> was added somewhere that slowed down some operations. Looking into this >> and experimenting with removing the guard I seem to remember VM crashes due >> to a double-free() of an address, due to there being two ExternalAddresses >> holding the same external address. >> >> My intuition is that that somewhere an ExternalAddress(a1) pointing at a >> particular external resource address "xa1" was being copied, so we end up >> with ExternalAddress(a2) also pointing at "xa1", with and object b1 holding >> a1 and object b2 holding a2. During finalization of b1, ExternalAddress a1 >> free()d xa1, and a1 was flagged to avoid double-free()ing. But that didn't >> help when b2 was finalized, since a2 had no indication that xa1 had been >> free()d. >> >> That is... >> b1-->a1-->xa1 >> b2 := b1 copy. >> b2-->a2-->xa1 >> b1 finalize a1 --> free(xa1) >> b2 finalize a2 --> free(xa1) --> General Protection Fault >> >> It was hard to follow this through and I didn't succeed in tracking down >> where such a copy might have been made, but the idea simmering in my mind >> since then is to propose that... >> >> ExternalAddresses be unique in the image and behave like Symbols, >> such that trying to copy one returns the identical object. >> >> The idea being that when b2 is finalized, a1 would notice that xa1 had >> already been free()d and raise a Smalltalk exception rather than a general >> protection fault. >> b1-->a1-->xa1 >> b2 := b1 copy. >> b2-->a1-->xa1 >> ^^ >> b1 finalize a1 --> free(xa1) >> b2 finalize a1 --> Smalltalk exception >> >> >> I write now in response to Stef since I vaguely remember it being >> Freetype related. But I also remember the issue being FFI related and >> Freetype is a plugin not FFI. So I'm not sure my memory is clear and >> perhaps I have the "wrong end of the stick" but anyway, rather than hold >> back longer because of that, perhaps this can stimulate some discussion and >> at least I learn something to clarify my understanding here. >> >> cheers -ben >> >> >> On Sat, Oct 28, 2017 at 4:48 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> > >> > Hi all >> > >> > I'm and I guess many of you are fedup about the instability that the >> > FreeType plugin produces. >> > >> > So we need help because clement and esteban are fully booked. >> > >> > We have three options: >> > >> > - drop Freetype alltogether >> > - rewrite the plugin >> > - create a binding using raffaillac sketch >> > >> > Now we need help. Who is willing to help us? >> > Should we try to set up a bounty? >> > >> > Stef >> >> >> >

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Sven Van Caekenberghe

> On 6 Nov 2017, at 10:37, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Because it's a cross dialect library and because contributing in Squeak is so much easier for me. > > I like the social power provided by github and i know how to use git, at least as an expert beginner. > But it took me two hours to pick a pharo image, fork and clone the pharo repository, pick a pharo VM (I ended up building my own), > retrieve my ssh pass phrase to avoid using github thru https, > search documentation of where should I put the image wrt to my cloned git repository, > search how to use iceberg, > and finally realized that the author/date would not even be preserved if we want to port this cross dialect library. You are absolutely right, but it is improving and will get better. > The dark theme upsets me, especially the green on blue, I could have searched how to change it, but there I stopped. Then switch to the light/white theme, just one setting. > While doing all these things, I did not spent a minute focusing on the SortFunction subject. > I can see that as an investment, maybe I should have done it before, but it was too much for a Sunday evening. I think what Denis means is, it would have been helpful to apply the change in Pharo. How you communicate that is less relevant, just saving the MC version and mailing it would already have been very helpful. IMHO. > 2017-11-06 10:13 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > It is difficult to compare to current Pharo version. > Why you not produce Pharo pull request? > > 2017-11-06 0:06 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > I've put some of the proposed composition features into > > http://source.squeak.org/inbox/Collections-nice.766.mcz > http://source.squeak.org/inbox/CollectionsTests-nice.283.mcz > > http://source.squeak.org/inbox/Collections-nice.766.diff > http://source.squeak.org/inbox/CollectionsTests-nice.283.diff > > SInce it's Squeak based, it uses <=>, but never mind, that's the same functions. > > > Stephane: the original comments were from Travis Griggs. > It's more a tutorial for using the SortFunction than a detailed explanation of implementation. > > The original idea is that oSortFunction are composable. > For example, it's possible to chain sorting on a first criterion, then resort on a second criterion if objects have same rank with first. > > For this, we need a to distinguish when objects have same rank (=) and cannot use a binary result (Boolean) like legacy sortBlock, > So we rather need a ternary comparison (<=>). > > This thread is about extending composition, and generalizing implementation by composition (like Xtreams) > - for sorting nil first (or last) > - for reversing the order > - for sorting properties with any collation order, and not just default <=> > > 2017-11-05 17:52 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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. 6, 2017

Re: [Pharo-dev] [IMPORTANT] Is there a bug in Tonel with category:

by stephan

On 05-11-17 22:05, Stephane Ducasse wrote: > I was working in cleaning the users of asLayoutFrame and when I commit I see > > - #category : 'Morphic-Base-Layouts' > + #category : #Morphic-Base-Layouts > > but #category : #Morphic-Base-Layouts > is not a valid symbol. In Metacello we use the quoted symbol form exactly because different smalltalks have different ideas of what a valid symbol is. Stephan

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

Oh, I hope we will be able improve this process. But personally when I set up it first time everything start to be smooth. And when I repeat it from scratch it takes just couple of minutes. 2017-11-06 10:37 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Because it's a cross dialect library and because contributing in Squeak is > so much easier for me. > > I like the social power provided by github and i know how to use git, at > least as an expert beginner. > But it took me two hours to pick a pharo image, fork and clone the pharo > repository, pick a pharo VM (I ended up building my own), > retrieve my ssh pass phrase to avoid using github thru https, > search documentation of where should I put the image wrt to my cloned git > repository, > search how to use iceberg, > and finally realized that the author/date would not even be preserved if > we want to port this cross dialect library. > The dark theme upsets me, especially the green on blue, I could have > searched how to change it, but there I stopped. > > While doing all these things, I did not spent a minute focusing on the > SortFunction subject. > I can see that as an investment, maybe I should have done it before, but > it was too much for a Sunday evening. > > 2017-11-06 10:13 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> It is difficult to compare to current Pharo version. >> Why you not produce Pharo pull request? >> >> 2017-11-06 0:06 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> I've put some of the proposed composition features into >>> >>> http://source.squeak.org/inbox/Collections-nice.766.mcz >>> http://source.squeak.org/inbox/CollectionsTests-nice.283.mcz >>> >>> http://source.squeak.org/inbox/Collections-nice.766.diff >>> http://source.squeak.org/inbox/CollectionsTests-nice.283.diff >>> >>> SInce it's Squeak based, it uses <=>, but never mind, that's the same >>> functions. >>> >>> >>> Stephane: the original comments were from Travis Griggs. >>> It's more a tutorial for using the SortFunction than a detailed >>> explanation of implementation. >>> >>> The original idea is that oSortFunction are composable. >>> For example, it's possible to chain sorting on a first criterion, then >>> resort on a second criterion if objects have same rank with first. >>> >>> For this, we need a to distinguish when objects have same rank (=) and >>> cannot use a binary result (Boolean) like legacy sortBlock, >>> So we rather need a ternary comparison (<=>). >>> >>> This thread is about extending composition, and generalizing >>> implementation by composition (like Xtreams) >>> - for sorting nil first (or last) >>> - for reversing the order >>> - for sorting properties with any collation order, and not just default >>> <=> >>> >>> 2017-11-05 17:52 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>>> 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. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

Because it's a cross dialect library and because contributing in Squeak is so much easier for me. I like the social power provided by github and i know how to use git, at least as an expert beginner. But it took me two hours to pick a pharo image, fork and clone the pharo repository, pick a pharo VM (I ended up building my own), retrieve my ssh pass phrase to avoid using github thru https, search documentation of where should I put the image wrt to my cloned git repository, search how to use iceberg, and finally realized that the author/date would not even be preserved if we want to port this cross dialect library. The dark theme upsets me, especially the green on blue, I could have searched how to change it, but there I stopped. While doing all these things, I did not spent a minute focusing on the SortFunction subject. I can see that as an investment, maybe I should have done it before, but it was too much for a Sunday evening. 2017-11-06 10:13 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > It is difficult to compare to current Pharo version. > Why you not produce Pharo pull request? > > 2017-11-06 0:06 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> I've put some of the proposed composition features into >> >> http://source.squeak.org/inbox/Collections-nice.766.mcz >> http://source.squeak.org/inbox/CollectionsTests-nice.283.mcz >> >> http://source.squeak.org/inbox/Collections-nice.766.diff >> http://source.squeak.org/inbox/CollectionsTests-nice.283.diff >> >> SInce it's Squeak based, it uses <=>, but never mind, that's the same >> functions. >> >> >> Stephane: the original comments were from Travis Griggs. >> It's more a tutorial for using the SortFunction than a detailed >> explanation of implementation. >> >> The original idea is that oSortFunction are composable. >> For example, it's possible to chain sorting on a first criterion, then >> resort on a second criterion if objects have same rank with first. >> >> For this, we need a to distinguish when objects have same rank (=) and >> cannot use a binary result (Boolean) like legacy sortBlock, >> So we rather need a ternary comparison (<=>). >> >> This thread is about extending composition, and generalizing >> implementation by composition (like Xtreams) >> - for sorting nil first (or last) >> - for reversing the order >> - for sorting properties with any collation order, and not just default >> <=> >> >> 2017-11-05 17:52 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> 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. 6, 2017

Re: [Pharo-dev] SqueakSSL on Pharo 64bit/Win

by Raffaello Giulietti

Hi Nicolas, I tried both the vm found at the location you mention (dated 2017-10-22): https://bintray.com/opensmalltalk/vm/download_file?file_path=cog_win64x64_p… and the "official" latest vm on the Pharo site (dated 2017-11-01) http://files.pharo.org/vm/pharo-spur64/win/pharo-win-x86_64-201711010928-e1… Neither of them contains the SqueakSSL.dll and, in fact, in both cases I get an exception when using Gofer to download Roassal2, using the latest 60519 image: Gofer it smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; configurationOf: 'Roassal2'; loadDevelopment This works on Pharo 32 bit/Win, where SquekSSL is present. On 2017-11-04 23:31, Nicolas Cellier wrote: > Note that win64 SSL works at least since > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/baa70862014d3bb510… > and > https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/caa8241de11b99ecae… > > Maybe it's a bit too recent to be found in official Pharo distribution, > but if you can live with bleeding edge, pick a more recent VM here: > https://bintray.com/opensmalltalk/vm/cog/201710221351#files (or maybe > you can find one from the Pharo site?) > > > 2017-11-04 22:21 GMT+01:00 henry <henry(a)callistohouse.club > <mailto:henry@callistohouse.club>>: > > This is the advantage of in-image SSL solution, found in the > Cryptography repository: > > http://www.squeaksource.com/Cryptography.html > <http://www.squeaksource.com/Cryptography.html> > > Sent from ProtonMail Mobile > > > On Fri, Nov 3, 2017 at 12:53, Raffaello Giulietti > <raffaello.giulietti(a)lifeware.ch > <mailto:raffaello.giulietti@lifeware.ch>> wrote: >> Hi, the SqueakSSL dll is not included in the Pharo 64bit/Win vm >> distribution. I guess this has to do with problems in building it. >> Anybody knows where the difficulties lie? Greetings Raffaello > >

Nov. 6, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

It is difficult to compare to current Pharo version. Why you not produce Pharo pull request? 2017-11-06 0:06 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > I've put some of the proposed composition features into > > http://source.squeak.org/inbox/Collections-nice.766.mcz > http://source.squeak.org/inbox/CollectionsTests-nice.283.mcz > > http://source.squeak.org/inbox/Collections-nice.766.diff > http://source.squeak.org/inbox/CollectionsTests-nice.283.diff > > SInce it's Squeak based, it uses <=>, but never mind, that's the same > functions. > > > Stephane: the original comments were from Travis Griggs. > It's more a tutorial for using the SortFunction than a detailed > explanation of implementation. > > The original idea is that oSortFunction are composable. > For example, it's possible to chain sorting on a first criterion, then > resort on a second criterion if objects have same rank with first. > > For this, we need a to distinguish when objects have same rank (=) and > cannot use a binary result (Boolean) like legacy sortBlock, > So we rather need a ternary comparison (<=>). > > This thread is about extending composition, and generalizing > implementation by composition (like Xtreams) > - for sorting nil first (or last) > - for reversing the order > - for sorting properties with any collation order, and not just default <=> > > 2017-11-05 17:52 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> 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. 6, 2017