September 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [review needed] speed up RBClassNotReferencedRule

by Marcus Denker

> Maybe we can hijack that mechanism with a class side method e.g. > > rbNotReferenced > <lint> > > > Do your modifications test sends of subclassesDo: and friends? > > OR > > #(#MyClass1 #MyClass2 #MyClass3) collect:[:ea | (Smalltalk at: ea) > doSomething]. > > The reason I ask is I'm planning to do a bunch of cleanup of a package and > it would be nice to not worry about those cases getting missed > What I did is to implement #isUsed like this in e.g the hierarchy of RBLintRule: isUsed "all my sublasses are used" ^self name ~= âRBLintRule' this way if RBLintRule is not used, it is seen by the Critique, but all subclasses are used by default. I implemented that in TestCase, too, and removed the explicit check for TestCase subclasses from the rule. Marcus

Sept. 18, 2015

Re: [Pharo-dev] PID of VM ?

by stepharo

nativeboost is not maintained and we need a solution that can be maintained by multiple people. Normally with the new FFI esteban is doing you will be able to use the NativeBoost syntax. > > Bye > T. > >

Sept. 17, 2015

Re: [Pharo-dev] About the Unicode class

by stepharo

Le 17/9/15 18:27, Nicolas Cellier a Ã©crit : > There has been some work on Squeak by Levente in this area, maybe it's > time to harvest... Thanks nicolas for the information. It is in the Unicode class? > > 2015-09-17 18:22 GMT+02:00 Henrik Johansen > <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > > >> On 17 Sep 2015, at 2:58 , Christophe Demarey >> <christophe.demarey(a)inria.fr >> <mailto:christophe.demarey@inria.fr>> wrote: >> >> Hi, >> >> Does anyone know why there are so many class variables in Unicode >> and what they are used for? >> Most of them have no sender. >> >> EncodedCharSet subclass: #Unicode >> instanceVariableNames: '' >> classVariableNames: 'Cc Cf Cn Co Cs DecimalProperty >> GeneralCategory Ll Lm Lo Lt Lu Mc Me Mn Nd Nl No Pc Pd Pe Pf Pi >> Po Ps Sc Sk Sm So ToCasefold ToLower ToUpper Zl Zp Zs' >> category: 'Multilingual-Encodings' >> >> Thanks, >> Christophe > > A partial / incomplete / broken implementation of querying > character properties, I'd guess. > See for instance: > http://en.wikipedia.org/wiki/Unicode_character_property > http://www.fileformat.info/info/unicode/category/index.htm > > Cheers, > Henry > >

Sept. 17, 2015

Re: [Pharo-dev] Rubric/Event handling issue?

by Nicolai Hess

2015-09-17 10:35 GMT+02:00 Stephan Eggermont <stephan(a)stack.nl>: > ping > > > On 15-09-15 17:49, Stephan Eggermont wrote: > >> There is an interesting bad interaction between my drag-and-drop code >> and Rubric. It kills all Rubric editors at the same time, so it looks >> to me like a problem with the Rubric background thread interacting with >> mouseMove or mouseEnter/Leave. >> >> https://vimeo.com/139353992 >> >> To reproduce, >> Load DragPanels from StephanEggermont/DragPanels >> and NewUI from StephanEggermont/Documentation >> >> In a Playground open a panel >> CodePanel new openInWindowLabeled:'Code Panel' >> >> add a few cards (drop them in the panel) >> (CodeCard class: CodeCard selector: #initialize) openInHand >> and expand them by clicking on the arrow >> >> Right click on the empty area in the CodePanel and open the >> colors. A fast drag from the color panel to the rubric area of the >> code card sometimes results in the rubric editors losing their content. >> >> Stephan >> >> >> >> > > > DragWell startDrag: evt WorldState addDeferredUIMessage: [ evt hand grabMorph: self copy ]. calls Morph>>#copy and this makes a veryDeepCopy. I don't know exactly how this affects the other rubric text morphs, but replacing self copy with self shallowCopy seems to work.

Sept. 17, 2015

Re: [Pharo-dev] Contribution scheme confusing ...

by Ben Coman

On Thu, Sep 17, 2015 at 9:40 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Also: >>> I did a simple fix on NautilusGroupAutoBuilder package - there is >>> a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally >>> or externally now? >>> >> Even I can not tell you. >> > > I think the rule we should adopt: if there is a dedicated repository defined in the image for a package, people should commit > there. If there is non (just the inbox), then this should be used (with the Slice mechanism). > > The repositories in the image should be already up to date, I think. > > Marcus > > How would the CI monkey work with Configurations from other repositories? My workflow for reviewing a submitted fix (e.g. for issue 11111) is to open the Pharo5Inbox repository and filter on the issue number, which leaves the SLICE-Issue-11111 as the only item. Having to discover where fixes are scattered makes it harder to review fixes, and they will get less review Now if the Inbox contained ConfigurationofXyz-Issue-11111, it would be simple to identify what needs to be reviewed. This might even help the CI monkey to pick up Configurations for testing. btw, it would be cool if a package loaded by a Configuration becomes dirty, then the Configuration also becomes dirty, or is otherwise flagged somehow. cheers -ben

Sept. 17, 2015

Re: [Pharo-dev] EncodedCharSets

by Sven Van Caekenberghe

> On 17 Sep 2015, at 19:26, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Christophe, > > On Thu, Sep 17, 2015 at 7:09 AM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Hi again, > > Does anyone know the rationale behind this? > > declareEncodedCharSet: anEncodedCharSetOrLanguageEnvironmentClass atIndex: aNumber > > EncodedCharSets at: aNumber put: anEncodedCharSetOrLanguageEnvironmentClass > > "this method is used to modularize the old initialize method: > EncodedCharSets at: 0+1 put: Unicode. > EncodedCharSets at: 1+1 put: JISX0208. > EncodedCharSets at: 2+1 put: GB2312. > EncodedCharSets at: 3+1 put: KSX1001. > EncodedCharSets at: 4+1 put: JISX0208. > EncodedCharSets at: 5+1 put: JapaneseEnvironment. > EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment. > EncodedCharSets at: 7+1 put: KoreanEnvironment. > EncodedCharSets at: 8+1 put: GB2312. > EncodedCharSets at: 12+1 put: KSX1001. > EncodedCharSets at: 13+1 put: GreekEnvironment. > EncodedCharSets at: 14+1 put: Latin2Environment. > EncodedCharSets at: 15+1 put: RussianEnvironment. > EncodedCharSets at: 17+1 put: Latin9Environment. > EncodedCharSets at: 256 put: Unicode. > > " > > what Henrik says is correct. Here's the relevant definition in Character: > > Character>>leadingChar > "Answer the value of the 8 highest bits which is used to identify the language. > This is mostly used for east asian languages CJKV as a workaround against unicode han-unification." > ^ self asInteger bitShift: -22 > > > i.e. the top 8 bytes of the leading character in a string is (was?) used to index EncodedCharSets to determine what language the string is in. Past tense indeed, until someone can explain why we would need this while it cannot be found anywhere else. > _,,,^..^,,,_ > best, Eliot

Sept. 17, 2015

Re: [Pharo-dev] Rubric/Event handling issue?

by Ben Coman

On Thu, Sep 17, 2015 at 8:47 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 17-09-15 13:59, Ben Coman wrote: >> >> On Tue, Sep 15, 2015 at 11:49 PM, Stephan Eggermont <stephan(a)stack.nl> >> wrote: >>> >>> There is an interesting bad interaction between my drag-and-drop code and >>> Rubric. It kills all Rubric editors at the same time, so it looks >>> to me like a problem with the Rubric background thread interacting with >>> mouseMove or mouseEnter/Leave. >>> >>> https://vimeo.com/139353992 >> >> >> It looks like there was meant to be sound, but I didn't hear any >> (could just be me) >> cheers -ben > > > Yes, there is sound, and it is 720p video. I'm probably constructing the > rubric editor incorrectly, and it would be good if that would only interfere > with the ones I created... Problem was at my end. cheers -ben

Sept. 17, 2015

Re: [Pharo-dev] Pedantic on Random>>nextValue method name

by Ben Coman

On Thu, Sep 17, 2015 at 7:56 PM, Henrik Nergaard <henrin10(a)student.uia.no> wrote: > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben > Coman > Sent: Wednesday, September 16, 2015 6:39 PM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Pedantic on Random>>nextValue method name > > On Wed, Sep 16, 2015 at 11:22 PM, Henrik Nergaard <henrin10(a)uia.no> wrote: >>> The method #nextValue actually calculates the next value the seed >>> should be, the current value can be accessed by sending #seed. > >>> I do agree that #nextValue might not be the clearest method name for >>> its use; perhaps #nextSeed would be a better name? > >>Yes. Thats better again. Now its a private method, so there should be >>problem changing it ;) ??anyone > > Continuing on another Random topic related to.. > https://pharo.fogbugz.com/default.asp?16577 > > I notice that Collection>>atRandom is protected by a mutex but > Collection>>atRandom: is not. This makes me believe the protection is > for the Random generator and not for the actual picking of the element from > the collection. So it seems that #atRandom holds the mutex too long - for > both random generation and element picking. > (> > Is there a specific use for the mutex in this case? I tried to use a shared > random without the mutex, and forking a few block closures, worked fine.. I was going to retort that inter-thread race conditions can be tricky to invoke with considerations of timing and priorities :P but then I had the insight this can be done using the debugger as demonstrated below. Presuming that use cases exist that require the repeatable nature of a PRNG. This feature is dependent on the /seed/ ivar having the same value in the calculation of both /hi/ and /lo/ in #nextValue. But consider this sequence of events... Priority 40 thread1 enters #next, then #nextValue, and takes the current value of /seed/ to calculate /hi/. Then before proceeding to the line, priority 50 thread2 enters #next and updates the value of /seed/. Thread1 then proceeds to take calculate /lo/ with a different value of /seed/ -- thus the algorithm is broken. This might be addressed by caching /seed/ ivar into a temporary /safeThreadCopySeed/. Yet other use cases may exist that expect simultaneous threads don't receive the same random number (more often than single thread would.) So priority 40 thread1 enters #next, then #nextValue, and copies the current value of /seed/ into /safeThreadCopySeed/. Then before it can update /seed/, priority 50 thread2 enters #next, then #nextValue, and copies the same current value of /seed/ into /safeThreadCopySeed/. So both threads will receive the same random number. To demonstrate... | sharedRandom context1 process1 thread1 result1 context2 process2 thread2 result2 | sharedRandom := Random new. context1 := [ result1 := sharedRandom next ] asContext. context2 := [ result2 := sharedRandom next ] asContext. process1 := Process forContext: context1 priority: 40. process2 := Process forContext: context2 priority: 40. thread1 := DebugSession process: process1 context: context1. thread2 := DebugSession process: process2 context: context2. 100 timesRepeat: [ result1 ifNil: [thread1 stepInto]. result2 ifNil: [thread2 stepInto]. ]. Transcript crShow: result1; tab; tab; show: result2. > > If the mutex could be removed we could just add a method in the class side > of Random like this: > > globalGenerator > ^Generator ifNil: [ Generator := Random new] I don't think Random should have a global. Instead the same on the proposed SharedRandom might be suitable using a class-instance-variable... SharedRandom class instanceVariableNames: 'globalGenerator' SharedRandom>>globalGenerator ^ globalGenerator ifNil: [ globalGenerator := self new]. Then we can have... Collection>>atRandom ^ self randomAt: SharedRandom globalGenerator. cheers -ben > Thus I wonder if rather than copying the existing pattern of > Collection>>atRandom to GlobalSharedRandom>>generateFor: it might be > better to make a more generic SharedRandom as follows... > > (> > Maybe :P > > I had a look at the Random Superclass in SciSmalltalk; here #next is used to > create and give the next random value. #seed for seed, and #peek for > checking what the next value would be without changing the current state. > The peek method could be a good addition in Random -> > Random>>#Peak > Self nextValue / m > > I would keep the way the #nextValue method behaves since this gives the > option to "peek" at the next value the Ivar seed will have without changing > it (could be useful?), but the name could be improved to be more clear. > Perhaps the method name #nextSeed might not be so good after all, it might > imply that the method creates a new seed, but what it actually does is to go > to the next state in the random generation? ( so a better name could be > #nextState ?), (perhaps the Ivar seed would also be better called state or > internalState? ) > > <) > > "Old calls to #next changed to private #nextValue" > > Random>>nextValue > | lo hi aLoRHi answer | > hi := (seed quo: q) asFloat. > lo := seed - (hi * q). " = seed rem: q" > aLoRHi := (a * lo) - (r * hi). > seed := (aLoRHi > 0.0) > ifTrue: [aLoRHi] > ifFalse: [aLoRHi + m]. > ^ seed / m "this line moved here from old #next" > > Random>>next > ^ self nextValue > > Random>>next: anInteger into: anArray > 1 to: anInteger do: [:index | anArray at: index put: self nextValue]. > ^ anArray > > Random>>nextInt: anInteger > anInteger strictlyPositive ifFalse: [ self error: 'Range must be > positive' ]. > anInteger asFloat isInfinite > ifTrue: [^(self nextValue asFraction * anInteger) truncated + 1]. > ^ (self nextValue * anInteger) truncated + 1 > > > "SharedRandom protects all calls to private #nextValue" > > Random subclass: SharedRandom > instanceVariableNames: 'mutex' > > SharedRandom>>initialize > mutex := Semaphore forMutualExclusion. > > SharedRandom>>next > ^ mutex critical: [ self nextValue ] > > SharedRandom>>next: anInteger into: anArray > ^ mutex critical: [ super next: anInteger into: anArray ]. > > SharedRandom>>nextInt: anInteger > ^ mutex critical: [ nextInt: anInteger ]. > > > Then... > > Object subclass: GlobalSharedRandom > classVariables: 'sharedRandom' > > GlobalSharedRandom class>>initialize > sharedRandom := SharedRandom new. > > GlobalSharedRandom class>>generator > ^ sharedRandom > > > And finally... > > Collection>>atRandom > ^ self randomAt: GlobalSharedRandom generator. (> +1 <)

Sept. 17, 2015

Re: [Pharo-dev] EncodedCharSets

by Eliot Miranda

Hi Christophe, On Thu, Sep 17, 2015 at 7:09 AM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi again, > > Does anyone know the rationale behind this? > > declareEncodedCharSet: anEncodedCharSetOrLanguageEnvironmentClass atIndex: > aNumber > > EncodedCharSets at: aNumber put: > anEncodedCharSetOrLanguageEnvironmentClass > > "this method is used to modularize the old initialize method: > EncodedCharSets at: 0+1 put: Unicode. > EncodedCharSets at: 1+1 put: JISX0208. > EncodedCharSets at: 2+1 put: GB2312. > EncodedCharSets at: 3+1 put: KSX1001. > EncodedCharSets at: 4+1 put: JISX0208. > EncodedCharSets at: 5+1 put: JapaneseEnvironment. > EncodedCharSets at: 6+1 put: SimplifiedChineseEnvironment. > EncodedCharSets at: 7+1 put: KoreanEnvironment. > EncodedCharSets at: 8+1 put: GB2312. > EncodedCharSets at: 12+1 put: KSX1001. > EncodedCharSets at: 13+1 put: GreekEnvironment. > EncodedCharSets at: 14+1 put: Latin2Environment. > EncodedCharSets at: 15+1 put: RussianEnvironment. > EncodedCharSets at: 17+1 put: Latin9Environment. > EncodedCharSets at: 256 put: Unicode. > > " > what Henrik says is correct. Here's the relevant definition in Character: Character>>leadingChar "Answer the value of the 8 highest bits which is used to identify the language. This is mostly used for east asian languages CJKV as a workaround against unicode han-unification." ^ self asInteger bitShift: -22 i.e. the top 8 bytes of the leading character in a string is (was?) used to index EncodedCharSets to determine what language the string is in. _,,,^..^,,,_ best, Eliot

Sept. 17, 2015

Re: [Pharo-dev] About the Unicode class

by Nicolas Cellier

There has been some work on Squeak by Levente in this area, maybe it's time to harvest... 2015-09-17 18:22 GMT+02:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 17 Sep 2015, at 2:58 , Christophe Demarey <christophe.demarey(a)inria.fr> > wrote: > > Hi, > > Does anyone know why there are so many class variables in Unicode and what > they are used for? > Most of them have no sender. > > EncodedCharSet subclass: #Unicode > instanceVariableNames: '' > classVariableNames: 'Cc Cf Cn Co Cs DecimalProperty GeneralCategory Ll Lm > Lo Lt Lu Mc Me Mn Nd Nl No Pc Pd Pe Pf Pi Po Ps Sc Sk Sm So ToCasefold > ToLower ToUpper Zl Zp Zs' > category: 'Multilingual-Encodings' > > Thanks, > Christophe > > > A partial / incomplete / broken implementation of querying character > properties, I'd guess. > See for instance: > http://en.wikipedia.org/wiki/Unicode_character_property > http://www.fileformat.info/info/unicode/category/index.htm > > Cheers, > Henry >

Sept. 17, 2015