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

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

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

by Marcus Denker

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

About the Unicode class

by Christophe Demarey

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

Sept. 17, 2015

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

by Stephan Eggermont

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

Sept. 17, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50330 Home: https://github.com/pharo-project/pharo-core

Sept. 17, 2015

[pharo-project/pharo-core] 7586c2: 50330

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7586c211f6842acc22a041ac7df29bc8fffbb659 https://github.com/pharo-project/pharo-core/commit/7586c211f6842acc22a041ac… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-17 (Thu, 17 Sep 2015) Changed paths: A Deprecated50.package/extension/SmalltalkImage/instance/logChange_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/fileReaderServicesForFile_suffix_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/loadVersionFile_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/mergeVersionFile_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/openVersionFile_.st R Monticello.package/MCVersionReader.class/class/System-FileRegistry/services.st A Monticello.package/MCVersionReader.class/class/actions - file/loadVersionFile_.st A Monticello.package/MCVersionReader.class/class/actions - file/mergeVersionFile_.st A Monticello.package/MCVersionReader.class/class/actions - file/openVersionFile_.st A MonticelloFileServices.package/extension/MCVersionReader/class/fileReaderServicesForFile_suffix_.st A MonticelloFileServices.package/extension/MCVersionReader/class/loadVersionStream_fromDirectory_.st A MonticelloFileServices.package/extension/MCVersionReader/class/mergeVersionStream_.st A MonticelloFileServices.package/extension/MCVersionReader/class/openVersionFromStream_.st A MonticelloFileServices.package/extension/MCVersionReader/class/serviceLoadVersion.st A MonticelloFileServices.package/extension/MCVersionReader/class/serviceMergeVersion.st A MonticelloFileServices.package/extension/MCVersionReader/class/serviceOpenVersion.st A MonticelloFileServices.package/extension/MCVersionReader/class/services.st M Nautilus.package/PackageTreeNautilusUI.class/instance/package filter/package_matchPackagePattern_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50329.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50330.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50329.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50330.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R System-Support.package/SmalltalkImage.class/instance/sources%2C change log/logChange_.st Log Message: ----------- 50330 16523 Nautilus Regex Search Box borken https://pharo.fogbugz.com/f/cases/16523 16587 Deprecate SmalltalkImage>>#logChange: https://pharo.fogbugz.com/f/cases/16587 16573 Monticello should not depend on System-FileRegistry https://pharo.fogbugz.com/f/cases/16573 http://files.pharo.org/image/50/50330.zip

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Yuriy Tymchuk

Well, for me itâs ok. Then I donât have to create a new version in conf :). > On 17 Sep 2015, at 14:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 17 Sep 2015, at 14:08, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change > > When I learned something than this: Whatever you do, someone will think it is wrong. The largest mistake that you can do is to only do things that nobody objects toâ¦ because the only thing that fulfils that is to do nothing. > > Marcus

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Marcus Denker

> On 17 Sep 2015, at 14:08, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change When I learned something than this: Whatever you do, someone will think it is wrong. The largest mistake that you can do is to only do things that nobody objects toâ¦ because the only thing that fulfils that is to do nothing. Marcus

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Yuriy Tymchuk

Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change. Of course they are only a few of them, but as you are not able to set up what rules you want to have in QualityAssistant, it makes sense to remove ones that the majority does not like. But in critics browser we can specify which rules you want to run. So I donât see a need in a complete removal. Yes, maybe form UX perspective critic browser should have some button like: âRun only the important onesââ¦ Uko > On 17 Sep 2015, at 13:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 17 Sep 2015, at 12:50, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image? >> > Because it is wrong? If we keep it, people will see it when they use the Critic Browserâ¦ what would be the reason to keep a rule that everyone things is not good? > > Marcus > > >

Sept. 17, 2015

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

by Marcus Denker

> On 16 Sep 2015, at 22:17, Torsten Bergmann <astares(a)gmx.de> wrote: > > We are in a transition to use more and more ConfigurationOfxxxx > to manage packages included in Pharo 5. > Yes, and it is a mess. > But neither the new help topic "How to contribute to Pharo base code" > nor the link it points to http://pharo.org/contribute-propose-fix reflects this. > Yes, I will put it on my TODO to update it. > Also - how do I know which code has to be managed by a Configuration > and where is the original repo if so. > > How will I submit a fix that includes code to change both: somthing that is managed > vai config and something that is a change on a regular slice managed package... > > 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. Marcus

Sept. 17, 2015

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

by Ben Coman

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

Sept. 17, 2015

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

by Henrik Nergaard

-----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.. 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] <) 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 <) What do you think? cheers, Ben What do you think? Best regards, Henrik -- View this message in context: http://forum.world.st/Pedantic-on-Random-nextValue-method-name-tp4850582p48… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Marcus Denker

> On 17 Sep 2015, at 12:50, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image? > Because it is wrong? If we keep it, people will see it when they use the Critic Browserâ¦ what would be the reason to keep a rule that everyone things is not good? Marcus

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Yuriy Tymchuk

Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image? Uko > On 17 Sep 2015, at 12:11, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > yes the problem with rules comes when the rule add more noise than is helpful. > If you do not want to remove this rule because it is useful in some cases, maybe the rule could check only these specific situations to do not add noise in others. > > Le 17 sept. 2015 Ã 10:37, Yuriy Tymchuk a Ã©crit : > >> Ok, it can be removed from Pharoâ¦ I still find it useful as well as missing yourself, but I can keep track of then individually :) >> >> >>> On 17 Sep 2015, at 09:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >>> >>> You can probably remove it directly from Pharo instead >>> https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule <https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule> >>> >>> Peter >>> >>> On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> Hi. >>> >>> First of all: thank you for the feedback Damien! >>> It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful. >>> >>> Uko >>> >>> >>> > On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou(a)inria.fr <mailto:damien.cassou@inria.fr>> wrote: >>> > >>> > This lint rule pops up all the times and my code is always ok. I >>> > typically have to reference an abstract class when: >>> > >>> > - the abstract class takes care of choosing the concrete class to >>> > instantiate >>> > >>> > - the abstract class takes care of some shared variable for its >>> > subclasses (e.g., a cache or an shared external object) >>> > >>> > I propose to remove this rule which has never been useful for me. >>> > >>> > -- >>> > Damien Cassou >>> > http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/> >>> > >>> > "Success is the ability to go from one failure to another without >>> > losing enthusiasm." --Winston Churchill >>> > >>> >>> >>> >> >

Sept. 17, 2015

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

by stepharo

I forwarded to alain. Now this is the restart of the university... Stef Le 15/9/15 17:49, Stephan Eggermont a Ã©crit : > 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 > > >

Sept. 17, 2015

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

by stepharo

Yes we know. Now we are full. Sorry I cannot clone ourselves. Else I would do it. Stef Le 16/9/15 22:17, Torsten Bergmann a Ã©crit : > We are in a transition to use more and more ConfigurationOfxxxx > to manage packages included in Pharo 5. > > But neither the new help topic "How to contribute to Pharo base code" > nor the link it points to http://pharo.org/contribute-propose-fix reflects this. > > Also - how do I know which code has to be managed by a Configuration > and where is the original repo if so. > > How will I submit a fix that includes code to change both: somthing that is managed > vai config and something that is a change on a regular slice managed package... > > Also: > I did a simple fix on NautilusGroupAutoBuilder package - there is > a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally > or externally now? > > Thanks > T. > >

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Christophe Demarey

yes the problem with rules comes when the rule add more noise than is helpful. If you do not want to remove this rule because it is useful in some cases, maybe the rule could check only these specific situations to do not add noise in others. Le 17 sept. 2015 Ã 10:37, Yuriy Tymchuk a Ã©crit : > Ok, it can be removed from Pharoâ¦ I still find it useful as well as missing yourself, but I can keep track of then individually :) > > >> On 17 Sep 2015, at 09:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> You can probably remove it directly from Pharo instead >> https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule >> >> Peter >> >> On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Hi. >> >> First of all: thank you for the feedback Damien! >> It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful. >> >> Uko >> >> >> > On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou(a)inria.fr> wrote: >> > >> > This lint rule pops up all the times and my code is always ok. I >> > typically have to reference an abstract class when: >> > >> > - the abstract class takes care of choosing the concrete class to >> > instantiate >> > >> > - the abstract class takes care of some shared variable for its >> > subclasses (e.g., a cache or an shared external object) >> > >> > I propose to remove this rule which has never been useful for me. >> > >> > -- >> > Damien Cassou >> > http://damiencassou.seasidehosting.st >> > >> > "Success is the ability to go from one failure to another without >> > losing enthusiasm." --Winston Churchill >> > >> >> >> >

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Yuriy Tymchuk

Ok, it can be removed from Pharoâ¦ I still find it useful as well as missing yourself, but I can keep track of then individually :) > On 17 Sep 2015, at 09:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > You can probably remove it directly from Pharo instead > https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule <https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule> > > Peter > > On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Hi. > > First of all: thank you for the feedback Damien! > It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful. > > Uko > > > > On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou(a)inria.fr <mailto:damien.cassou@inria.fr>> wrote: > > > > This lint rule pops up all the times and my code is always ok. I > > typically have to reference an abstract class when: > > > > - the abstract class takes care of choosing the concrete class to > > instantiate > > > > - the abstract class takes care of some shared variable for its > > subclasses (e.g., a cache or an shared external object) > > > > I propose to remove this rule which has never been useful for me. > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/> > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." --Winston Churchill > > > > >

Sept. 17, 2015

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

by Stephan Eggermont

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

Sept. 17, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Sven Van Caekenberghe

> On 17 Sep 2015, at 09:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2015-09-17 9:10 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-09-16 15:14 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Argh, sent too early: > > self new color: Color red; yourself > > est bien une cascade, non? > > Yes, but in > > (self new color: Color red); yourself > the expression in parenthesis looks like "this evalulates first, to 'anObject' ", so we send " ; yourself", > a cascaded messages with only one message to "anObject". > > Yes, agreed of course. > > In a way, it looks like an error correction type of thing: the parser knows the parenthesis shouldn't be there or the ; shouldn't be there, so it chooses one interpretation out of the two: here it is the parenthesis are unnecessary. Hmm, I don't agree. We as humans can infer that, from a language/compiler's standpoint it is not clear/possible. someObject message1; message2 is a pure cascade (someObject message1) message2 is not a cascade, message2 being sent to the result the last expression is totally equivalent to someObject message1 message2 However expression message expression ; message could be equivalent, like if it said expression yourself; message but the decision to drop the parenthesis cannot be made automatically, IMHO I would make the spurious ; an error, to avoid confusion > By the way, John found another issue with a fix you did in RBParser (RBPatternParser>>parseUnaryMessage) which fail some refactoring expressions. Can you have a look? > > Thierry > > > > > > > > > Thierry > > > 2015-09-16 15:12 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2015-09-16 15:05 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > OK, I think Sven is right and a cascade needs at least one message send > > "self ; yourself" > > doesn't work too (both parser don't accept this). > > But > > > > There are currently two methods in Pharo 5.0 with this > syntax: > > DAPackageAnalyzerWindow class>>#onPackagesNamed: > DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: > > @Yuri, can you change that. > > > And I think we should fix RBParser. > > > 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Nicolai, > > can you try with the RBParser directly? I believe Opal uses the RBParser. > > RBParser parseMethod: 'createRedMorph > ^ (self new color:Color red); yourself' > > Oh, RBParser sees it as: > > self new > color: Color red; > yourself > > :) > > Thierry > > > 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > The following method compiles with Opal: > > createRedMorph > ^ (self new color:Color red); yourself > > but gives a syntax error with the old compilers parser > > createRedMorph > ^ (self new color:Color red)End of block expected -> ; yourself > > > removing the parenthesis of course works for both. > Who is right ? > > > (for those who understand the ParseTreeSearcher syntax, how would > a search expression look, for finding code like: > > "(some expression);yourself" > > > nicolai

Sept. 17, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50329 Home: https://github.com/pharo-project/pharo-core

Sept. 17, 2015

[pharo-project/pharo-core] feb71a: 50329

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: feb71a8705982cbb829e2678703c07d2131e71d8 https://github.com/pharo-project/pharo-core/commit/feb71a8705982cbb829e2678… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-17 (Thu, 17 Sep 2015) Changed paths: M CodeImport.package/CodeImporter.class/instance/evaluating/flushChangesFile.st A CodeImport.package/ManifestCodeImport.class/README.md A CodeImport.package/ManifestCodeImport.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st A CodeImport.package/ManifestCodeImport.class/definition.st M ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/symbolic versions/stable_.st A ConfigurationOfCatalog.package/ConfigurationOfCatalog.class/instance/versions/version09_.st A ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/baselines/baseline112_.st A ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/symbolic versions/development_.st A ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/symbolic versions/stable_.st A ConfigurationOfCodeImporter.package/ConfigurationOfCodeImporter.class/instance/versions/version112_.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadBlockSequence.st M Reflectivity.package/RFASTTranslatorForValue.class/instance/visitor-double dispatching/visitSequenceNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50328.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50329.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50328.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50329.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-Catalog.package/CatalogBrowser.class/instance/actions/installStableVersion_onSuccess_.st M Tool-Catalog.package/CatalogBrowser.class/instance/private - events/onLoadFrom_.st M Tool-Catalog.package/extension/GTSpotter/instance/spotterCatalogProjectsFor_.st Log Message: ----------- 50329 16589 #instead for block sequence https://pharo.fogbugz.com/f/cases/16589 16588 Integrate Catalog 0.9 https://pharo.fogbugz.com/f/cases/16588 16586 Load latest version of CodeImporter https://pharo.fogbugz.com/f/cases/16586 http://files.pharo.org/image/50/50329.zip

Sept. 17, 2015

[Reflectivity] Links on Block creation vs. execution

by Marcus Denker

Hi, For blocks, we now have the correct model to destinguish âblock creationâ from âblock executionâ: 1) put a link on the block node, it will be called when the block definition (creation) is executed. e.g. when you put a before link on the block in this method, it will be called when you execute the method: TT>>method ^[1 + 2]. 2) put a link on the *body* of the block (the sequence of statements), it will be called when the block *executes*. For the example, it would not be called when executing âTT new methodâ, but only when you do âTT new method valueâ. Test: testBeforeBlockSequenceNoValue | sequence link | sequence := (ReflectivityExamples >> #exampleBlockNoValue) ast statements first value body. self assert: sequence isSequence. link := MetaLink new metaObject: self; selector: #tagExec. sequence link: link. self assert: sequence hasMetalinkBefore. self assert: (ReflectivityExamples >> #exampleBlockNoValue) class = ReflectiveMethod. self assert: tag isNil. ReflectivityExamples new exampleBlockNoValue. self assert: tag isNil. ReflectivityExamples new exampleBlockNoValue value. self assert: tag = 'yes'. self assert: (ReflectivityExamples >> #exampleBlockNoValue) class = CompiledMethod. link uninstall. ReflectivityExamples recompile: #exampleBlockNoValue Marcus

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Peter UhnÃ¡k

You can probably remove it directly from Pharo instead https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule Peter On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi. > > First of all: thank you for the feedback Damien! > It makes sense, the rule also has higher amount of negative feedback. I > will remove it from QA, let it stay in the image, it actually can be useful. > > Uko > > > > On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > > > This lint rule pops up all the times and my code is always ok. I > > typically have to reference an abstract class when: > > > > - the abstract class takes care of choosing the concrete class to > > instantiate > > > > - the abstract class takes care of some shared variable for its > > subclasses (e.g., a cache or an shared external object) > > > > I propose to remove this rule which has never been useful for me. > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." --Winston Churchill > > > > >

Sept. 17, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Thierry Goubier

2015-09-17 9:10 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-09-16 15:14 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Argh, sent too early: >> >> self new color: Color red; yourself >> >> est bien une cascade, non? >> > > Yes, but in > > (self new color: Color red); yourself > the expression in parenthesis looks like "this evalulates first, to > 'anObject' ", so we send " ; yourself", > a cascaded messages with only one message to "anObject". > Yes, agreed of course. In a way, it looks like an error correction type of thing: the parser knows the parenthesis shouldn't be there or the ; shouldn't be there, so it chooses one interpretation out of the two: here it is the parenthesis are unnecessary. By the way, John found another issue with a fix you did in RBParser (RBPatternParser>>parseUnaryMessage) which fail some refactoring expressions. Can you have a look? Thierry > > > > > >> >> >> >> Thierry >> >> >> 2015-09-16 15:12 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> >>> >>> 2015-09-16 15:05 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>> >>>> OK, I think Sven is right and a cascade needs at least one message send >>>> >>>> "self ; yourself" >>>> >>>> doesn't work too (both parser don't accept this). >>>> >>> >>> But >>> >>> >>> >>>> >>>> There are currently two methods in Pharo 5.0 with this >>>> syntax: >>>> >>>> DAPackageAnalyzerWindow class>>#onPackagesNamed: >>>> DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: >>>> >>>> @Yuri, can you change that. >>>> >>>> >>>> And I think we should fix RBParser. >>>> >>>> >>>> 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>>> >>>>> Nicolai, >>>>> >>>>> can you try with the RBParser directly? I believe Opal uses the >>>>> RBParser. >>>>> >>>>> RBParser parseMethod: 'createRedMorph >>>>> ^ (self new color:Color red); yourself' >>>>> >>>>> Oh, RBParser sees it as: >>>>> >>>>> self new >>>>> color: Color red; >>>>> yourself >>>>> >>>>> :) >>>>> >>>>> Thierry >>>>> >>>>> >>>>> 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>>>> >>>>>> The following method compiles with Opal: >>>>>> >>>>>> createRedMorph >>>>>> ^ (self new color:Color red); yourself >>>>>> >>>>>> but gives a syntax error with the old compilers parser >>>>>> >>>>>> createRedMorph >>>>>> ^ (self new color:Color red)End of block expected -> ; yourself >>>>>> >>>>>> >>>>>> removing the parenthesis of course works for both. >>>>>> Who is right ? >>>>>> >>>>>> >>>>>> (for those who understand the ParseTreeSearcher syntax, how would >>>>>> a search expression look, for finding code like: >>>>>> >>>>>> "(some expression);yourself" >>>>>> >>>>>> >>>>>> nicolai >>>>>> >>>>>> >>>>> >>>> >>> >> >

Sept. 17, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Nicolai Hess

2015-09-16 15:14 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Argh, sent too early: > > self new color: Color red; yourself > > est bien une cascade, non? > Yes, but in (self new color: Color red); yourself the expression in parenthesis looks like "this evalulates first, to 'anObject' ", so we send " ; yourself", a cascaded messages with only one message to "anObject". > > > > Thierry > > > 2015-09-16 15:12 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> >> 2015-09-16 15:05 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >>> OK, I think Sven is right and a cascade needs at least one message send >>> >>> "self ; yourself" >>> >>> doesn't work too (both parser don't accept this). >>> >> >> But >> >> >> >>> >>> There are currently two methods in Pharo 5.0 with this >>> syntax: >>> >>> DAPackageAnalyzerWindow class>>#onPackagesNamed: >>> DAPackageCycleDetectionTreeModel class>>#onPackagesNamed: >>> >>> @Yuri, can you change that. >>> >>> >>> And I think we should fix RBParser. >>> >>> >>> 2015-09-16 11:30 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>> >>>> Nicolai, >>>> >>>> can you try with the RBParser directly? I believe Opal uses the >>>> RBParser. >>>> >>>> RBParser parseMethod: 'createRedMorph >>>> ^ (self new color:Color red); yourself' >>>> >>>> Oh, RBParser sees it as: >>>> >>>> self new >>>> color: Color red; >>>> yourself >>>> >>>> :) >>>> >>>> Thierry >>>> >>>> >>>> 2015-09-16 10:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >>>> >>>>> The following method compiles with Opal: >>>>> >>>>> createRedMorph >>>>> ^ (self new color:Color red); yourself >>>>> >>>>> but gives a syntax error with the old compilers parser >>>>> >>>>> createRedMorph >>>>> ^ (self new color:Color red)End of block expected -> ; yourself >>>>> >>>>> >>>>> removing the parenthesis of course works for both. >>>>> Who is right ? >>>>> >>>>> >>>>> (for those who understand the ParseTreeSearcher syntax, how would >>>>> a search expression look, for finding code like: >>>>> >>>>> "(some expression);yourself" >>>>> >>>>> >>>>> nicolai >>>>> >>>>> >>>> >>> >> >

Sept. 17, 2015

Re: [Pharo-dev] Remove rule "References an abstract class"

by Yuriy Tymchuk

Hi. First of all: thank you for the feedback Damien! It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful. Uko > On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > This lint rule pops up all the times and my code is always ok. I > typically have to reference an abstract class when: > > - the abstract class takes care of choosing the concrete class to > instantiate > > - the abstract class takes care of some shared variable for its > subclasses (e.g., a cache or an shared external object) > > I propose to remove this rule which has never been useful for me. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

Sept. 17, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by Nicolai Hess

2015-09-17 1:18 GMT+02:00 John Brant <brant(a)refactoryworkers.com>: > On 9/16/2015 10:34 AM, Ben Coman wrote: > >> On Wed, Sep 16, 2015 at 4:56 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> The following method compiles with Opal: >>> >>> createRedMorph >>> ^ (self new color:Color red); yourself >>> >>> but gives a syntax error with the old compilers parser >>> >>> createRedMorph >>> ^ (self new color:Color red)End of block expected -> ; yourself >>> >>> >>> removing the parenthesis of course works for both. >>> Who is right ? >>> >> >> What is the result in other dialects? >> > > Dolphin lets you do "self ; yourself" as well as the example above. > However, both VW & VA don't allow it. > Thanks for the info. > > This is a potential incompatibility for little gain. >> Anyway I would guess Opal is wrong. >> > > I don't remember if we allowed this on purpose to be compatible with other > Smalltalks or if it was a bug we missed. Anyway, a simple fix is to add " > and: [node parentheses isEmpty]" to the RBParser>>parseCascadeMessage > method: > > parseCascadeMessage > | node receiver messages semicolons | > node := self parseKeywordMessage. > (currentToken isSpecial > and: [currentToken value = $; and: [node isMessage and: > [node parentheses isEmpty]]]) ifFalse: [^node]. > ... > > > > John Brant > > >

Sept. 17, 2015

[Reflectivity] Support for primitive methods

by Marcus Denker

Hi, One thing I added over the last weeks: support to put links on primitives. 1) fail code. You can put links into the smalltalk code that is executed in case of primitive failure. For all primitive methods, we generate code immediately when setting the link, we do not wait till the method is called. (this is in there since a while). 2) links on the method node itself. What we do here is to wrap the original method. It is interesting how simple this was to do: 1) when generating code for a ReflectiveMethod, check if it is a primitive: compileAndInstallCompiledMethod "we install the old one as the compiler might need itâ self installCompiledMethod. compiledMethod isRealPrimitive ifTrue: [ self generatePrimitiveWrapper ]. self recompileAST. self installCompiledMethod. 2) compile a wrapper by building an AST by hand: generatePrimitiveWrapper | wrappedMethod send wrapperMethod | ast compilationContext semanticAnalyzerClass: RFSemanticAnalyzer; astTranslatorClass: RFASTTranslator. ast doSemanticAnalysis. "force semantic analysis" wrappedMethod := ast generate: compiledMethod trailer. send := RBMessageNode receiver: (RBLiteralNode value: wrappedMethod) selector: #valueWithReceiver:arguments: arguments: {RBVariableNode named: #self . RBArrayNode statements: ast variableNodes }. wrapperMethod := RBMethodNode selector: ast selector arguments: ast variableNodes body: (RBReturnNode value: send) asSequenceNode. wrapperMethod methodClass: ast methodClass. wrapperMethod propertyAt: #wrappedPrimitive put: true. ast hasMetalink ifTrue: [wrapperMethod propertyAt: #links put: (ast propertyAt: #links)]. ast := wrapperMethod. This means we copy over the links to the new wrapper. the #wrappedPrimitive marker is there so that, when we destroy the twin when the last link is removed, we remember to unwrap. 3) the compiler plugin that takes the links into account ignores links on MethodNode if itâs a primitive. 4) when getting rid of the Twin (because we remove the last link), we detect if it was a primitive and unwrap: destroyTwin (ast hasProperty: #wrappedPrimitive) ifTrue: [ ast := compiledMethod parseTree]. self recompileAST. self installCompiledMethod. compiledMethod reflectiveMethod: nil. SystemAnnouncer uniqueInstance unsubscribe: self e.g. testBeforeMethodPrimitive | methodNode link | methodNode := (ReflectivityExamples >> #examplePrimitiveMethod) ast. link := MetaLink new metaObject: self; selector: #tagExec. self assert: (ReflectivityExamples>>#examplePrimitiveMethod) isRealPrimitive. methodNode link: link. self assert: methodNode hasMetalink. self assert: (ReflectivityExamples >> #examplePrimitiveMethod) class = CompiledMethod. self assert: tag isNil. self assert: ReflectivityExamples new examplePrimitiveMethod class = ByteString. self deny: (ReflectivityExamples>>#examplePrimitiveMethod) isRealPrimitive. self assert: tag = #yes. self assert: (ReflectivityExamples >> #examplePrimitiveMethod) class = CompiledMethod. link uninstall. self assert: (ReflectivityExamples>>#examplePrimitiveMethod) isRealPrimitive. ReflectivityExamples recompile: #examplePrimitiveMethod Marcus

Sept. 17, 2015

Remove rule "References an abstract class"

by Damien Cassou

This lint rule pops up all the times and my code is always ok. I typically have to reference an abstract class when: - the abstract class takes care of choosing the concrete class to instantiate - the abstract class takes care of some shared variable for its subclasses (e.g., a cache or an shared external object) I propose to remove this rule which has never been useful for me. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Sept. 17, 2015

Re: [Pharo-dev] SyntaxError: parentheses; cascades and yourself (Opal vs. old compilers parser)

by John Brant

On 9/16/2015 10:34 AM, Ben Coman wrote: > On Wed, Sep 16, 2015 at 4:56 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> The following method compiles with Opal: >> >> createRedMorph >> ^ (self new color:Color red); yourself >> >> but gives a syntax error with the old compilers parser >> >> createRedMorph >> ^ (self new color:Color red)End of block expected -> ; yourself >> >> >> removing the parenthesis of course works for both. >> Who is right ? > > What is the result in other dialects? Dolphin lets you do "self ; yourself" as well as the example above. However, both VW & VA don't allow it. > This is a potential incompatibility for little gain. > Anyway I would guess Opal is wrong. I don't remember if we allowed this on purpose to be compatible with other Smalltalks or if it was a bug we missed. Anyway, a simple fix is to add " and: [node parentheses isEmpty]" to the RBParser>>parseCascadeMessage method: parseCascadeMessage | node receiver messages semicolons | node := self parseKeywordMessage. (currentToken isSpecial and: [currentToken value = $; and: [node isMessage and: [node parentheses isEmpty]]]) ifFalse: [^node]. ... John Brant

Sept. 16, 2015

Contribution scheme confusing ...

by Torsten Bergmann

We are in a transition to use more and more ConfigurationOfxxxx to manage packages included in Pharo 5. But neither the new help topic "How to contribute to Pharo base code" nor the link it points to http://pharo.org/contribute-propose-fix reflects this. Also - how do I know which code has to be managed by a Configuration and where is the original repo if so. How will I submit a fix that includes code to change both: somthing that is managed vai config and something that is a change on a regular slice managed package... Also: I did a simple fix on NautilusGroupAutoBuilder package - there is a ConfigurationOfNautilusGroupAutoBuilder. But is it managed internally or externally now? Thanks T.

Sept. 16, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50328 Home: https://github.com/pharo-project/pharo-core

Sept. 16, 2015

[pharo-project/pharo-core] 3a2205: 50328

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 3a220566b868affc78b29a8fc84cdbb3e8c6af42 https://github.com/pharo-project/pharo-core/commit/3a220566b868affc78b29a8f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-16 (Wed, 16 Sep 2015) Changed paths: M Collections-Tests.package/ArrayTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/ArrayTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/BagTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/BagTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/DictionaryTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/DictionaryTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/FloatArrayTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/FloatArrayTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/IntervalTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/IntervalTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/LinkedListTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/LinkedListTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/OrderedCollectionTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/OrderedCollectionTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/SetTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/SetTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/SortedCollectionTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/SortedCollectionTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/StringTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/StringTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/SymbolTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/SymbolTest.class/instance/tests - comma and delimiter/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/TAsStringCommaAndDelimiterSequenceableTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/TAsStringCommaAndDelimiterSequenceableTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterLastEmpty.st M Collections-Tests.package/TAsStringCommaAndDelimiterTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterEmpty.st M Collections-Tests.package/TAsStringCommaAndDelimiterTest.class/instance/tests - as string comma delimiter sequenceable/testAsStringOnDelimiterLastEmpty.st M Kernel-Tests.package/DateAndTimeDosEpochTest.class/instance/tests/testPrintOn.st M Kernel-Tests.package/DateAndTimeEpochTest.class/instance/tests/testPrintOn.st M Kernel-Tests.package/DateAndTimeLeapTest.class/instance/tests/testPrintOn.st M Kernel-Tests.package/DateAndTimeUnixEpochTest.class/instance/tests/testPrintOn.st M Kernel-Tests.package/DateTest.class/instance/tests/testPrintOn.st M Kernel-Tests.package/DateTest.class/instance/tests/testPrintOnFormat.st M Kernel-Tests.package/DateTest.class/instance/tests/testStoreOn.st M Kernel-Tests.package/DurationTest.class/instance/tests/testPrintOn.st M Kernel-Tests.package/IntegerTest.class/instance/tests - printing/testPrintOnBaseShowRadix.st M Kernel-Tests.package/StopwatchTest.class/instance/tests/testPrintOn.st M Kernel-Tests.package/TimeTest.class/instance/tests printing/testPrint24On.st M Kernel-Tests.package/TimeTest.class/instance/tests printing/testPrint24OnWithPM.st M Kernel-Tests.package/TimeTest.class/instance/tests printing/testPrint24OnWithoutSeconds.st M Kernel-Tests.package/TimeTest.class/instance/tests printing/testPrintOn.st M Kernel-Tests.package/TimeTest.class/instance/tests/testStoreOn.st M Kernel-Tests.package/TimespanTest.class/instance/tests/testPrintOn.st M Kernel-Tests.package/YearMonthWeekTest.class/instance/tests/testMonthPrintOn.st M Kernel-Tests.package/YearMonthWeekTest.class/instance/tests/testYearPrintOn.st M Morphic-Widgets-Basic.package/SimpleButtonMorph.class/instance/menu/setArguments.st M Refactoring-Core.package/RBClass.class/instance/accessing/definitionString.st M Refactoring-Core.package/RBExtractMethodRefactoring.class/instance/transforming/nameNewMethod_.st M Refactoring-Core.package/RBRemoveParameterRefactoring.class/instance/private/computeNewSelector.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - instead/testInsteadSequence.st A Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - reflective disable/testLinkOneShot.st M Reflectivity.package/HookGenerator.class/instance/private/hookFor_.st M Reflectivity.package/RFASTTranslatorForEffect.class/instance/visitor-double dispatching/visitSequenceNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50327.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50328.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50327.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50328.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M StartupPreferences.package/StartupPreferencesLoader.class/instance/private/buildStreamFor_.st M System-Support.package/Session.class/definition.st A System-Support.package/Session.class/instance/accessing/sid.st M System-Support.package/Session.class/instance/initialize/initialize.st M Tool-Finder.package/FinderUI.class/instance/text areas behavior/buildDescriptionOf_.st M UIManager.package/UIManager.class/class/utils/createPageTestWorkspace.st Log Message: ----------- 50328 16581 one-shot links https://pharo.fogbugz.com/f/cases/16581 16582 Reflectivity: #instead for sequence nodes https://pharo.fogbugz.com/f/cases/16582 15260 WriteStream on new string https://pharo.fogbugz.com/f/cases/15260 16578 Add an id to Session https://pharo.fogbugz.com/f/cases/16578 http://files.pharo.org/image/50/50328.zip

Sept. 16, 2015