- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] About the Unicode class

by Henrik Johansen

> 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 <http://www.fileformat.info/info/unicode/category/index.htm> Cheers, Henry

Sept. 17, 2015

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

by Paul DeBruicker

Marcus Denker-4 wrote > Hi, > > Review needed for > > > https://pharo.fogbugz.com/f/cases/16074/Is-RBClassNotReferencedRule-200x-sl… > > Speedup can be checked with: > > rule:=RBClassNotReferencedRule new. > environment:=RBBrowserEnvironment new forPackageNames: #('Fuel'). > [RBSmalllintChecker runRule: rule onEnvironment: > environment] timeToRun > > > Pharo5: "0:00:00:13.526" > Pharo5 with fix: "0:00:00:00.761" > Pharo3: 0:00:00:00.547 > > Checking all classes for usage: > > [Smalltalk allClassesAndTraits select: [ : each | each isUsed not]] > timeToRun > > still takes 1:40 to find 600 unused classes. > > This shows that adding a cache for âreferenced classesâ per environment > would speed this > up further. But it should be general, not just for RB or even RB Code > Critique. > > The nice things is that code environments only change when you add classes > or methods, > so adding a very general cache should be quite possible. > > Another thing we should add is a way for classes to define âI am usedâ. > E.g this > now finds all Configurations, all the Manifests and all cases like the RB > Rules themselves. > All these should know that they are not useless even though there are no > references. > > Marcus Thanks for working on this. I have a use for it this week. For methods RB allows one to add a pragma e.g.: <lint: 'Methods implemented but not sent' rationale: 'this code plays a role in examining the system' author: 'pad'> and described here: http://www.lukas-renggli.ch/blog/ignoring-lint-rules. 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 -- View this message in context: http://forum.world.st/review-needed-speed-up-RBClassNotReferencedRule-tp484… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 17, 2015

[Reflectivity] Links on Class Variables

by Marcus Denker

Hi, We can put meta links on AST Nodes. But with Variables being represented by Objects in Pharo, it is easy to allow those to be annotated, too. With the changes from https://pharo.fogbugz.com/f/cases/16596/before-for-Class-Variable <https://pharo.fogbugz.com/f/cases/16596/before-for-Class-Variable> it is now possible to put #before links on class variables: testBeforeClassVariable | classVar link | classVar := ReflectivityExamples classVariableNamed: #ClassVar. link := MetaLink new metaObject: self; selector: #tagExec. classVar link: link. self assert: classVar hasMetalinkBefore. self assert: (ReflectivityExamples >> #exampleClassVarRead) class = ReflectiveMethod. self assert: tag isNil. self assert: ReflectivityExamples new exampleClassVarRead isNil. self assert: tag = 'yes'. self assert: (ReflectivityExamples >> #exampleClassVarRead) class = CompiledMethod. self deny: (ReflectivityExamples >> #exampleClassVarRead) isQuick. link uninstall. ReflectivityExamples recompile: #exampleClassVarRead TODO: #after, #instead, then reifications (e.g. value), then tests for Globals, then the same for instance vars (slots) and tempsâ¦ step by step. Marcus

Sept. 17, 2015

Re: [Pharo-dev] EncodedCharSets

by Henrik Johansen

> On 17 Sep 2015, at 4:09 , 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. > > " If you mean the name EncodedCharSets, and the fact there are Encodings in that list, it is a leftover from when WideStrings code points could be in character sets other than Unicode. That made little sense since each WideChar takes 32 bits anyways (other than a possibly simpler codePoint -> glyph index translation described below), so most/all places where this happened have been removed and we now assume WideString code points to be equal to unicode code points. The goal of the old code was to give parameters to the old StrikeFont string display primitive, which is limited to using a table of 256 glyphs for any string it wants to render. The Scanners job was to introduce stops when it encounters a change that makes the string it's scanning unable to be displayed by a single call to the primitive. The presence of a leadingChar induced(/s) a stop in the Scanner, which explains the mix of encodings and Languages (whose codePoints are in Unicode) in the EncodedCharSets table. This stop let a properly constructed StrikeFontSet swap in a glyph table suitable for displaying the leading char, using a custom codePoint -> glyph index conversion. TLDR; It's a relic of a more complex past used in a mechanism that let StrikeFonts display other than macroman characters. Cheers, Henry P.S. Funnily enough, the mechanism is somewhat similar to what would be needed to swap in fallback fonts for code points not covered by the default font efficiently (although the stop would be on missing glyph, rather than leading char), instead of the current, doomed-to-fail approach of using a FallbackFont in each font.

Sept. 17, 2015

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

by Torsten Bergmann

Hi Marcus, Could work - but is a fragile rule. We should document it somewhere. What about providing this info directly in the image. Alexandre has already added a help topic on how to contribute (but yet only for the slice process). I changed it so we can have the differences of config managed ones described as well and we can list the configs there. See the attached changeset that you can file in into the latest Pharo5.0 Latest update: #50329 File in and check "How to contribute to Pharo base code" topic in Help -> Help Browser I guess this would be more clear to us and the users and we can simply point to the help info is someone asks. And look up ourself when we forgot. Thx T. > Gesendet: Donnerstag, 17. September 2015 um 15:40 Uhr > Von: "Marcus Denker" <marcus.denker(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Contribution scheme confusing ... > > >> > >> 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 > > >

Sept. 17, 2015

EncodedCharSets

by Christophe Demarey

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

Sept. 17, 2015

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

by Tudor Girba

Exactly! This is the cheapest way to document the process. We could even try to automatically remove the inbox if there is another repository associated with a package. What do you think? Cheers, Doru On Thu, Sep 17, 2015 at 3: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 > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 17, 2015