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

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

by Ronie Salgado

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 > > > >

Nov. 5, 2017

Re: [Pharo-dev] STOP THE WORLD FINISHED

by Pavel Krivanek

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. -- 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

Re: [Pharo-dev] STOP THE WORLD FINISHED

by Stephane Ducasse

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? 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

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

by Stephane Ducasse

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 >

Nov. 5, 2017

[IMPORTANT] Is there a bug in Tonel with category:

by Stephane Ducasse

Hi 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. So is it a bug? Stef

Nov. 5, 2017

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

by Sean P. DeNigris

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

Nov. 5, 2017

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

by Stephane Ducasse

Hi guys Since this email got zero reaction, I suggest that we remove the FreeType plugin. Stef On Sat, Oct 28, 2017 at 11:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > (Ok so continuing with this superb gmail UI) > > > - 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 > > > > On Sat, Oct 28, 2017 at 10:48 AM, 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: >> >> >> Does anybody >> >> >> Stef

Nov. 5, 2017

Re: [Pharo-dev] STOP THE WORLD FINISHED

by Sven Van Caekenberghe

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

Re: [Pharo-dev] About Collator

by Denis Kudriashov

2017-11-05 18:41 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)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. > 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@ > 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 Denis Kudriashov

Thank's Nicolas for answers. I have same vision. 2017-11-05 15:47 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > SortByPropertyFunction -> shouldnât be âPropertySortFunctionâ ? (coherent >> with the previous one) >> > > +1 for PropertySortFunction, or maybe just PropertySorter > > 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). > Agree, I prefer SortFunction name instead of Sorter. > > Nicolas > > >> Esteban >> >> > >> > Stef >> > >> >> >> >

Nov. 5, 2017