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

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

by Nicolas Cellier

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

How should I load Seaside/Bootstrap in Pharo 7 ?

by Sven Van Caekenberghe

Hi, [ Max replied on the Seaside ML where I originally posted: > We don't have a build for Pharo 7 yet. Loading from github would be the recommended way. A quick look makes me think that it will require a bit of work to get the baseline set up correctly. I can't promise anything before next weekend. I think it is important that Seaside works on Pharo 7, it is an important use case and test during development, and very necessary as well. ] I am stuck trying to move my main development to Pharo 7 because I have trouble loading Seaside (which I normally do indirectly by loading the Bootstrap project). Here is my dependency: project: 'Bootstrap' with: [ spec className: 'ConfigurationOfBootstrap'; repository: 'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main/'; versionString: #stable ] I also tried the following: Metacello new baseline:'Seaside3'; repository: 'github://SeasideSt/Seaside:master/repository'; load. What is the right/recommended way to do it ? Thx, Sven

Nov. 6, 2017

Re: [Pharo-dev] Moving from mc to tonel?

by Peter UhnÃ¡k

Hi Martin, several people successfully migrated with git-migration... so I guess it works. > Is it good idea to move now? There is no risk in trying to use it. If it fails, you report a bug. :-) Is it the right tool? Yes. As for Tonel... git-migration uses FileTree, but I am looking into making it configurable. (I have filetree-tonel migration tool now... but that is a bit more hardcore and potentially destructive :) (unlike git-migration)). Cheers, Peter On Mon, Nov 6, 2017 at 1:42 AM, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi all, I'm considering to move Epicea (+Ombu+Hiedra) to github. I read > that tonel is the new format and there is Peter's git-migration, which > could be the tool to do it. > > Is it good idea to move now? > Is it the right tool? > > Bests, > MartÃn >

Nov. 6, 2017

Re: [Pharo-dev] Call for help for stability and rewrite of FreeType

by Tudor Girba

Thanks, Ronie. Cheers, Doru > On Nov 5, 2017, at 11:05 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hi Stef, > > I can try to continue what Thibault started. Give me two weeks. > > Best regards, > Ronie > > 2017-11-05 18:10 GMT-03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Personally now I do not care because I cannot continue to work with a > system that I have to save after every accept. > This is totally insane. > Thomas on Ubuntu CANNOT even open Pharo. I'm on mac. > Pharo just crashes all the time for me. > I just crashed before committing again! This bug is KILLING our credibility. > I can also drop Pharo 60 70 and go to work in Pharo 50! > But then do not count on me to improve anything on Pharo for a while > (and may be this is the solution after all > working on my own little programs is really tempting). > > Stef > > On Sun, Nov 5, 2017 at 10:04 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Stephane Ducasse-3 wrote > >> I suggest that we remove the FreeType plugin. > > > > How will that effect non-Latin users? For example, is it possible to work > > with Chinese characters without it? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Nov. 6, 2017

ExternalAddress uniqueness (was Re: Call for help for stability and rewrite of FreeType)

by Ben Coman

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

Moving from mc to tonel?

by Martin Dias

Hi all, I'm considering to move Epicea (+Ombu+Hiedra) to github. I read that tonel is the new format and there is Peter's git-migration, which could be the tool to do it. Is it good idea to move now? Is it the right tool? Bests, MartÃn

Nov. 6, 2017

Re: [Pharo-dev] About Collator

by Nicolas Cellier

2017-11-05 20:11 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-11-05 18:41 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> 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 (>) >> > > While it is well known comparison logic I would like to find better name > than #compare/collate which reflects explicitly what you just described. > Something like: > > sortFunction rank: anObject1 comparedTo: anObject2 > > And according to this the current #threeWayCompareTo: can be renamed too: > > anObject rankComparedTo: anObject2 > > > Another idea is to have explicit meaning in the method name that it > defines ascending order of receiver compared to argument. I am always > confused when I need to implement a new block for sorted collection. I am > usually not know what result I will have: will it be ascending or > descending. Because block itself has no meaning about it and it only > returns true or false. Same confusion could happen during implementation of > new #threeWayCompareTo: method. > So I would use something like: > > anObject rankInAscendingOrderTo: anObject2 > > > Maybe it is bad in english. But I hope it shows my idea. So if you like > it, try suggest better names. > > Denis, you already know my opinion, but if you insist on a new selector, then I'm proposing <,=,> anObject "Answer the direction for collating self and anObject. The direction is -1 is self is to be collated to the left (self < anObject) 0 if self and anObject have same rank (self = anObject) 1 if self is to be collated to the right (self > anObject)" ...snip... >> 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@gmai >> l.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 SortFunctions

by Nicolas Cellier

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. 5, 2017

Pharo 7 and Traits ?

by Sven Van Caekenberghe

Hi, So what is the story with Pharo 7 and Traits ? I may be wrong, but were they not removed but flattened ? How are external libraries that want to support multiple Pharo versions supposed to cope when they need to add extension methods to (meta) class ? I have a problem with STON. Sven

Nov. 5, 2017

Re: [Pharo-dev] STOP THE WORLD FINISHED

by Sven Van Caekenberghe

> On 5 Nov 2017, at 22:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > 2017-11-05 22:17 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Esteban > > when I save code in Tonel I get > > - #category : 'HelpSystem-Core-Builders' > + #category : #HelpSystem-Core-Builders > > and this is not a correct symbol. > > So why do we get broken code? > > It is a property of STON. STON format does not contain expressions so there is no conflict. However, at least it is not very educational to use such symbols that are not valid in standard Pharo grammar. Yes, STON is a bit more liberal with Symbols than normal Smalltalk, but it is totally consistent with itself. STON fromString: (STON toString: #'My Strange Symbol'). STON fromString: (STON toString: #'foo-bar'). If a Symbol consists only of characters in 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_./' then the Symbol does not need to be quoted. I see no problem there. > -- Pavel > > > Stef > > > On Sun, Nov 5, 2017 at 8:21 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Great, thanks for all the hard work behind the scenes. > > > >> On 3 Nov 2017, at 11:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >> Hi, > >> > >> Yesterday we finish the conversion to tonel, but I announced it just replying to the build that realises it. > >> So I announce here officially and in his own mail :) > >> > >> You can resume contributions. > >> > >> This change should improve everybody's life but in particular windows users. I would like to know how them feel the new format in that context. > >> > >> Of course, I know there are still a lot of optimisation/improvements we need to do, but this is a beginning :) > >> > >> cheers, > >> Esteban > >> > >> > >> > > > > > >

Nov. 5, 2017