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

[pharo-project/pharo-core] 343374: 50334

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 3433740685ce7124d5396063bedffb45fa2a7f8f https://github.com/pharo-project/pharo-core/commit/3433740685ce7124d5396063… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-20 (Sun, 20 Sep 2015) Changed paths: M AST-Core.package/RBParser.class/instance/private-parsing/parseIncompleteExpression_.st M Compression.package/extension/FileStream/instance/viewGZipContents.st A Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeBlockSequenceNoValue.st A Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/exampleBlockNoValue.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/README.md R Reflectivity-Tests.package/ReflectivityLinkTest.class/definition.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/running/tearDown.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tagging/tagExec.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tagging/tagExec_.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - primitives/testPrimitiveWithLinkExecuteWrapper.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - condition/testLinkWithCondition.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - condition/testLinkWithConditionInvalidation.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - error handling/testSetLinkIncompatibleReification.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - metalevel/testLinkWithMeta.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - metalevel/testLinkWithMetaDisabled.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - reflective disable/testLinkConditionReflectiveDisable.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - reflective disable/testLinkOneShot.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - reflective disable/testTwoLinks.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - reflective disable/testTwoSendLinks.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - reflective disable/testUninstallLink.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - reflective disable/testUninstallLinkAndRun.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - reflective disable/testUninstallLinkAndRunOptionNoJIT.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - symbolic/testConditionArgument.st R Reflectivity-Tests.package/ReflectivityLinkTest.class/instance/tests - symbolic/testSymbolicMetaObject.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50333.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50334.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50333.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50334.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50334 16597 DNU RBParseErrorNode>>statements: when | is placed before a . https://pharo.fogbugz.com/f/cases/16597 16599 Compression should not depend on Graphics-Display Object (leftover) https://pharo.fogbugz.com/f/cases/16599 16610 test: block body vs block https://pharo.fogbugz.com/f/cases/16610 http://files.pharo.org/image/50/50334.zip

Sept. 20, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Jan Vrany

Hi, I'm not sure what's the decision, however, as a pain-relief I committed just couple days ago CompatibilityANSI to http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility For now it only defines subStrings: :-) On Sun, 2015-09-20 at 16:08 +0200, Stephan Eggermont wrote: > We have quite a lot of instances of #subString: in Seaside. > The deprecation makes loading painful. > What is the decision? > > Stephan > >

Sept. 20, 2015

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

by Marcus Denker

Yes, this is good to put it in the imageâ¦ I will update the website later, too. can you make an issue? > On 17 Sep 2015, at 17:35, Torsten Bergmann <astares(a)gmx.de> wrote: > > 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 >> >> > <HowToContributeHelp class.TorstenBergmann.cs>

Sept. 20, 2015

Re: [Pharo-dev] Reflectivity: Links that de-install themselves (oneShot)

by Marcus Denker

> On 19 Sep 2015, at 01:10, stepharo <stepharo(a)free.fr> wrote: > > Marcus I have a API design question > > when you offer > > options: #(optionOneShot); > > versus > > optionOneShot > > Do you do a perform of the arrays selectors? > What is the benefit of options: I needed a mechanism for flags (stored not each in an ivar, as they normally not active). As we have this mechanism in Opal already, I decided to use the same pattern. As in Opal, for all the pre-defined options we should not rely on perform: but have explicit #optionOneShot getter/setter methods. I will add those later.. Marcus

Sept. 20, 2015

Re: [Pharo-dev] Need a decision on subString: vs substring:

by Stephan Eggermont

We have quite a lot of instances of #subString: in Seaside. The deprecation makes loading painful. What is the decision? Stephan

Sept. 20, 2015

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

by stepharo

Sorry guys but this is terrible because it is implicitly scoped. From an analysis point of view we have to rely on order to >> After a class declaration like this: >> >> LLVMDisposableObject subclass:#LLVMDIBuilder >> instanceVariableNames:'' >> classVariableNames:'' >> poolDictionaries:'LLVMModuleFlagBehavior' >> category:'LLVM-S-Core' >> >> Annotation key: 'disposable:' value: 'true' >> >> This ANSI-compatible way (see page 39 of NCITS J20 DRAFT >> of ANSI Smalltalk Standard, rev 1.9). >> >> Perhaps nice way is >> >> Annotation disposable: true A better way would be LLVMDIBuilder disposable: true or LLVMDIBuilder annotationKey: #disposable: value: true

Sept. 20, 2015

Re: [Pharo-dev] Modyfing BlueInk formatter

by Peter UhnÃ¡k

> It could be cool yep, I will do it. I don't mind digging into it provided I have some pointers. :) > So we say 3 characters as limit ? 3 characters is a good start, but I wonder... because there may be other use-cases. For example "all elements are symbols AND it all fits on a single line" { #smb1 . #smb2 . #smb3 } or "all elements are sends to the same object AND it all fits on a single line" { TextEmphasis bold . TextEmphasis italic } The ideal scenario is that we can A/B test this -- implement it all and see how each scenario behaves in real world, but that is perhaps a lot of work. Speaking of which... I'm thinking that I could analyze existing code and see how these things are generally formatted (there's a lot of code formatted by hand). Peter

Sept. 19, 2015

Re: [Pharo-dev] Modyfing BlueInk formatter

by Franck Warlouzet

Hi, It could be cool yep, I will do it. So we say 3 characters as limit ? Franck > Date: Sat, 19 Sep 2015 02:16:34 +0200 > From: i.uhnak(a)gmail.com > To: pharo-dev(a)lists.pharo.org > Subject: [Pharo-dev] Modyfing BlueInk formatter > > Hi, > > how hard it would be to modify BlueInk formatter to inline dynamic > array in some situations? > > Currently BL places each element of dynamic array at separate line > > ~~~~~~~~~~ > v addAll: > {l1. > l2. > l3} > ~~~~~~~~~~ > > and what I want is to inline them if the length of the element names > is small (1-3 characters maybe)... > > ~~~~~~~~~ > v addAll: { l1 . l2 . l3 } > ~~~~~~~~~ > > For longer names I want to keep the current behavior. > > Obviously this would have to be configurable, however as I have no > knowledge of BL internals I don't even know where to start... > > Any pointers appreciated, > Peter >

Sept. 19, 2015

Re: [Pharo-dev] Drawing underlined text on AthensCanvas

by Peter UhnÃ¡k

Never mind, apparently I have to draw the underline manually. On Sat, Sep 19, 2015 at 3:38 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > is it currently possible to draw underlined text onto AthensCanvas? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > |font view| > font := TextStyle defaultFont. > font := font emphasized: TextEmphasis underlined emphasisCode. "<- > underline does NOT work" > "font := font emphasized: TextEmphasis bold emphasisCode." "<- bold works" > > view := AthensSceneView new. > > view scene: [:canvas | > canvas surface clear: Color black. > canvas setFont: font. > canvas setPaint: Color red. > canvas drawString: font asString. > ]. > view openInWindow. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I managed to find this previous discussion, however that is related > more to Morphic > http://forum.world.st/FreeType-fonts-and-underline-strikethrough-emphasis-t… > https://pharo.fogbugz.com/f/cases/15362/ > > or maybe it's the same? > > This also doesn't work for StringMorph (as mentioned in the linked > discussion), however TextMorph seems to work just fine.. > > Thanks, > Peter

Sept. 19, 2015

Re: [Pharo-dev] Permanent storage for implementation docs referenced from image

by Marcus Denker

> On 19 Sep 2015, at 11:40, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > There is no reason to expect that files.pharo.org links will not rot > away for such unusual content. > Also I'm pretty sure that copying it there is against copyright; this > however also applies for Web Archive (plus the owner of the domain can > retroactively remove content from Web Archive). > So why not just put there the name of the article (and it's DOI), > which is sufficient to always trace the article (just like any > reference in any article), and have the regular link for convenience? > Yes, that is the way to go. > Peter > > p.s.: pharo.com is a hedge fund ;) > They had enough money to buy the domainâ¦ Marcus

Sept. 19, 2015

Re: [Pharo-dev] Permanent storage for implementation docs referenced from image

by Peter UhnÃ¡k

There is no reason to expect that files.pharo.org links will not rot away for such unusual content. Also I'm pretty sure that copying it there is against copyright; this however also applies for Web Archive (plus the owner of the domain can retroactively remove content from Web Archive). So why not just put there the name of the article (and it's DOI), which is sufficient to always trace the article (just like any reference in any article), and have the regular link for convenience? Peter p.s.: pharo.com is a hedge fund ;) On Sat, Sep 19, 2015 at 5:42 AM, Ben Coman <btc(a)openinworld.com> wrote: > While doing a bit of background reading on the Random algorithm used > in the image I found this [1] which describes the choice of the > initialised magic numbers. So I would like to reference this document > from the class comment. However one day the link may die, so I was > wondering if such could get a permanent place under Pharo control > (e.g. files.pharo.com) or we just submit them to the WayBackMachine > [2] [3] and hope for the best. > > [1] http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf > [2] http://archive.org/web/ > [3] http://web.archive.org/web/20150919033900/http://www.firstpr.com.au/dsp/ran… > > cheers -ben >

Sept. 19, 2015

Re: [Pharo-dev] Permanent storage for implementation docs referenced from image

by Max Leske

> On 19 Sep 2015, at 05:42, Ben Coman <btc(a)openInWorld.com> wrote: > > While doing a bit of background reading on the Random algorithm used > in the image I found this [1] which describes the choice of the > initialised magic numbers. So I would like to reference this document > from the class comment. However one day the link may die, so I was > wondering if such could get a permanent place under Pharo control > (e.g. files.pharo.com) or we just submit them to the WayBackMachine > [2] [3] and hope for the best. > > [1] http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf > [2] http://archive.org/web/ > [3] http://web.archive.org/web/20150919033900/http://www.firstpr.com.au/dsp/ran… > > cheers -ben > Great read! Thanks Ben.

Sept. 19, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 19, 2015

[pharo-project/pharo-core] 9b2797: 50333

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9b279714a09f380eb1324802ce1879d24456dae1 https://github.com/pharo-project/pharo-core/commit/9b279714a09f380eb1324802… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-19 (Sat, 19 Sep 2015) Changed paths: M Morphic-Base.package/MenuMorph.class/instance/events/keyStroke_.st M RPackage-Core.package/RPackage.class/instance/properties/propertyAt_put_.st M Reflectivity-Tests.package/ReflectivityControlTest.class/instance/tests - before/testBeforeClassVariable.st M Reflectivity.package/RFASTTranslator.class/instance/reflectivity/visitVariableValue_.st A Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/visitVariableNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50332.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50333.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50332.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50333.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/LiteralVariable.class/instance/properties/propertyAt_put_.st A Slot.package/LiteralVariable.class/instance/testing/isGlobal.st M Slot.package/Slot.class/instance/properties/propertyAt_put_.st A Slot.package/Slot.class/instance/testing/isGlobal.st M Slot.package/TemporaryVariable.class/instance/properties/propertyAt_put_.st A System-Support.package/SystemNavigation.class/instance/private/classRefsToClassName_.st M Text-Edition.package/SmalltalkEditor.class/instance/menu messages/sendersOfIt.st A Tool-Base.package/extension/SystemNavigation/instance/browseAllSendersOrUsersOf_.st M Tool-Workspace.package/Workspace.class/instance/file support/readStringFromFile_.st M Tool-Workspace.package/Workspace.class/instance/file support/saveString_toFile_.st Log Message: ----------- 50333 16606 remove bubble like ballon tooltip from menus https://pharo.fogbugz.com/f/cases/16606 16605 senders/implementors window shows unrelated content https://pharo.fogbugz.com/f/cases/16605 16598 Cannot save the contents of the standard workspace to disk https://pharo.fogbugz.com/f/cases/16598 16596 #before for Class Variable https://pharo.fogbugz.com/f/cases/16596 http://files.pharo.org/image/50/50333.zip

Sept. 19, 2015

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

by Esteban Lorenzano

> On 19 Sep 2015, at 10:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >>> >>> 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? >> > I does the check the same as for slices. (Which is great). but the configuration needs to be copied into the inbox, of course :) > > What is a bit harder is reviewing the changes. But as the idea of external packages is that > there is a maintainer, I actually just trust them: A configuration where the tests go trough > I integrate without looking at it, as that is the job of the maintainer that created the Config. exactly. the idea is to have maintainers for configurations, then relieving a bit the work of the integrator. thatâs what happens with GTools, Zinc, etc. Anywayâ¦ I want to do a âconfiguration diffâ to be able to check what a new configuration will bringâ¦ is not so hard, but you knowâ¦ time time time :) what we are still struggling is with the best way to inform those changes. Because having a commit report that says âUpdate GToolsâ, does not says a lot about the bugs fixed upstream :) Esteban > > Marcus

Sept. 19, 2015

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

by Marcus Denker

>> >> 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? > I does the check the same as for slices. (Which is great). What is a bit harder is reviewing the changes. But as the idea of external packages is that there is a maintainer, I actually just trust them: A configuration where the tests go trough I integrate without looking at it, as that is the job of the maintainer that created the Config. Marcus

Sept. 19, 2015

Class Pragmas was: Re: [review needed] speed up RBClassNotReferencedRule

by Marcus Denker

>> Yes, the question is where to put it syntactically > > After a class declaration like this: > > LLVMDisposableObject subclass:#LLVMDIBuilder > instanceVariableNames:'' > classVariableNames:'' > poolDictionaries:'LLVMModuleFlagBehavior' > category:'LLVM-S-Core' > > Annotation key: 'disposable:' value: 'true' > > This ANSI-compatible way (see page 39 of NCITS J20 DRAFT > of ANSI Smalltalk Standard, rev 1.9). > > Perhaps nice way is > > Annotation disposable: true > > >> and how to save it in monticelloâ¦ > > In the source as above. In the binary, in a separate > entry in the .zip so the other MC implementation won't > crash but silently ignore them. Yes, that looks good. I made a note (no idea when I will come around implementing it, though). Marcus

Sept. 19, 2015

Permanent storage for implementation docs referenced from image

by Ben Coman

While doing a bit of background reading on the Random algorithm used in the image I found this [1] which describes the choice of the initialised magic numbers. So I would like to reference this document from the class comment. However one day the link may die, so I was wondering if such could get a permanent place under Pharo control (e.g. files.pharo.com) or we just submit them to the WayBackMachine [2] [3] and hope for the best. [1] http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf [2] http://archive.org/web/ [3] http://web.archive.org/web/20150919033900/http://www.firstpr.com.au/dsp/ran… cheers -ben

Sept. 19, 2015

Drawing underlined text on AthensCanvas

by Peter UhnÃ¡k

Hi, is it currently possible to draw underlined text onto AthensCanvas? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |font view| font := TextStyle defaultFont. font := font emphasized: TextEmphasis underlined emphasisCode. "<- underline does NOT work" "font := font emphasized: TextEmphasis bold emphasisCode." "<- bold works" view := AthensSceneView new. view scene: [:canvas | canvas surface clear: Color black. canvas setFont: font. canvas setPaint: Color red. canvas drawString: font asString. ]. view openInWindow. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I managed to find this previous discussion, however that is related more to Morphic http://forum.world.st/FreeType-fonts-and-underline-strikethrough-emphasis-t… https://pharo.fogbugz.com/f/cases/15362/ or maybe it's the same? This also doesn't work for StringMorph (as mentioned in the linked discussion), however TextMorph seems to work just fine.. Thanks, Peter

Sept. 19, 2015

Modyfing BlueInk formatter

by Peter UhnÃ¡k

Hi, how hard it would be to modify BlueInk formatter to inline dynamic array in some situations? Currently BL places each element of dynamic array at separate line ~~~~~~~~~~ v addAll: {l1. l2. l3} ~~~~~~~~~~ and what I want is to inline them if the length of the element names is small (1-3 characters maybe)... ~~~~~~~~~ v addAll: { l1 . l2 . l3 } ~~~~~~~~~ For longer names I want to keep the current behavior. Obviously this would have to be configurable, however as I have no knowledge of BL internals I don't even know where to start... Any pointers appreciated, Peter

Sept. 19, 2015

Re: [Pharo-dev] Reflectivity: Links that de-install themselves (oneShot)

by stepharo

Marcus I have a API design question when you offer options: #(optionOneShot); versus optionOneShot Do you do a perform of the arrays selectors? What is the benefit of options: STef Le 16/9/15 08:52, Marcus Denker a Ã©crit : > Hi, > > This is just a one-liner to add to the framework, but that makes it even more fun: One-Shot links. > > A link now can have the #optionOneShot, which means that it will de-install itself when activated for > the first time: > > link := MetaLink new > metaObject: self; > options: #(optionOneShot); > selector: #tagExec. > > The full test looks like this: > > testLinkOneShot > | sendNode link | > sendNode := (ReflectivityExamples>>#exampleMethod) sendNodes first. > link := MetaLink new > metaObject: self; > options: #(optionOneShot); > selector: #tagExec. > sendNode link: link. > self assert: sendNode hasMetalink. > self assert: tag isNil. > self assert: (ReflectivityExamples new exampleMethod = 5). > self assert: (tag = #yes). > self deny: sendNode hasMetalink. > tag := nil. > self assert: (ReflectivityExamples new exampleMethod = 5). > self assert: tag isNil. > > > https://pharo.fogbugz.com/f/cases/16581/one-shot-links > > Marcus >

Sept. 18, 2015

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

by Stephan Eggermont

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 I've removed the video. As noted by Henrik in 'RubAbstractTextArea copying', a RubScrolledTextMorph cannot be safely copied, which can be seen by opening the halos on a playground's edit space and trying to duplicate the morph. Stephan

Sept. 18, 2015

Re: [Pharo-dev] RubAbstractTextArea copying

by Stephan Eggermont

On 18-09-15 22:52, Henrik Nergaard wrote: > It does not seem that RubScrolledTextMorph supports duplication/copy (tried to duplicate one from nautilus code area and the same clear all code happened. Trying to duplicate a Playground just freezes the image (might be some circular references that is not handled when copying )). > > Anyway: this code works ish.. (does not add unaccepted edits) > > CodeCard>>#duplicate > | newCard | > > newCard := self class new. > newCard > selector: self selector; "must be before selectedClass" > selectedClass: self selectedClass; > updateCodeWith: self textModel text. > self activeHand attachMorph: newCard. "attachMorph: is nicer than grabMorph: :)" > selected := false. > self changed. > Thanks Henrik. I'm slowly getting to the finer points of Morphic. Stephan

Sept. 18, 2015

Re: [Pharo-dev] RubAbstractTextArea copying

by Henrik Nergaard

It does not seem that RubScrolledTextMorph supports duplication/copy (tried to duplicate one from nautilus code area and the same clear all code happened. Trying to duplicate a Playground just freezes the image (might be some circular references that is not handled when copying )). Anyway: this code works ish.. (does not add unaccepted edits) CodeCard>>#duplicate | newCard | newCard := self class new. newCard selector: self selector; "must be before selectedClass" selectedClass: self selectedClass; updateCodeWith: self textModel text. self activeHand attachMorph: newCard. "attachMorph: is nicer than grabMorph: :)" selected := false. self changed. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont Sent: Friday, September 18, 2015 6:19 PM To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] RubAbstractTextArea copying On 18-09-15 16:50, Henrik Nergaard wrote: > I looked into the bug a bit and found something strange.... > > | m m2 | > > m := ColorPanel open. > m2 := m submorphs third copy. > m = m2 panel. "prints false; the panel is duplicated " Yes, that is a bug, that should stay the same. > add this method to DragWelL: > > veryDeepInner: deepCopier > super veryDeepInner: deepCopier That seems to work. > Another observation is that after all the text is lost, > if you have a Playground that is effected and try to do > something like: (ColorPanel allInstances size.) it raises > an error 'MessageNotUnderstood: receiver of "style:" is nil' > from "a GLMMorphicPharoPlaygroundRenderer actOnHighlightAndEvaluate: ann" Yes. All editors break. That is independent of the ColorPanel, I've verified with the cloning of cards. I just don't know how I can safely copy a Rubric editor morph. Either directly, or through its textModel. Stephan

Sept. 18, 2015

Re: [Pharo-dev] [ANN]: AconcaguaAddOns

by HernÃ¡n Morales Durand

Hi Sean, First thanks for sharing this. Now I suppose this was AconcaguaDeluxe before? Do you have a ConfigurationOf for AconcaguaAddOns? I want to use it but don't have idea what to load. HernÃ¡n 2015-04-21 13:21 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > I pushed some Aconcagua extensions to > http://smalltalkhub.com/mc/SeanDeNigris/AconcaguaAddOns/main/ > > One part consists of tiny (so far) Aconcagua models of various domains - > Time*, Money, and Weight at the moment. > > The other is the Aconcagua-Magritte package. This gives you > MAMeasureDescription, which represents an Aconcagua Measure. It mostly acts > like a number field mapped to its amount. You just have to tell it which > unit to use to convert the amount number into a Measure. > > Example usage: > MAMeasureDescription new > accessor: #replacementPrice; > label: 'Replacement Price'; > unit: AmDollar new; > yourself > > Then, you can type 100 in a Magritte form and "100 dollars" will be saved > to > the model. Enjoy! > > * Yes, I know Chalten has months and years, but (I think when Chalten was > extended to handle non-Gregorian calendars) months and year units are no > longer derived from each other, and so can not be compared. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/ANN-AconcaguaAddOns-tp4820940.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Sept. 18, 2015

Re: [Pharo-dev] RubAbstractTextArea copying

by Stephan Eggermont

On 18-09-15 16:50, Henrik Nergaard wrote: > I looked into the bug a bit and found something strange.... > > | m m2 | > > m := ColorPanel open. > m2 := m submorphs third copy. > m = m2 panel. "prints false; the panel is duplicated " Yes, that is a bug, that should stay the same. > add this method to DragWelL: > > veryDeepInner: deepCopier > super veryDeepInner: deepCopier That seems to work. > Another observation is that after all the text is lost, > if you have a Playground that is effected and try to do > something like: (ColorPanel allInstances size.) it raises > an error 'MessageNotUnderstood: receiver of "style:" is nil' > from "a GLMMorphicPharoPlaygroundRenderer actOnHighlightAndEvaluate: ann" Yes. All editors break. That is independent of the ColorPanel, I've verified with the cloning of cards. I just don't know how I can safely copy a Rubric editor morph. Either directly, or through its textModel. Stephan

Sept. 18, 2015

Re: [Pharo-dev] ANSICompatibility package

by Jan Vrany

On Fri, 2015-09-18 at 23:04 +0800, Ben Coman wrote: > Thanks for your contribution Jan. It is interesting how in > "CompatibilitySmalltalkX class>>initialize" you deal with missing > classes by inserting what are essentially alias into the Smalltalk > dictionary. So, I'm happy I learnt something new today. > > Just curious though why both the class-side and instance-side > #initialize methods set the same alias, but different ways. Well, this is (was) a bug, I by mistake defined the method on instance side (where it makes no sense). The Nautilus UI is rather stupid in that respect, not making clear whether what you see is class side or instance side... > > Also curious why "ClassDescription>>isClass" is blank. It would seem > to need a boolean return value. Accident, should be removed. Both issues fixed in Compatibility-SmalltalkX-JanVrany.11 Thanks for spotting! Jan > > cheers -ben > > On Fri, Sep 18, 2015 at 10:05 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > wrote: > > Thanks, Ben. Stuff copied. > > > > Cheers, Jan > > > > > > On Fri, 2015-09-18 at 21:54 +0800, Ben Coman wrote: > > > Jan, Thanks for your contribution. Actually I hadn't uploaded > > > anything > > > yet since I was waiting on more votes on renaming, but to push > > > ahead > > > I > > > settled on SmalltalkCompatibility [1], since I think the repo can > > > serve a wider purpose than just ANSI. > > > > > > I added you to the PharoExtras team. Hopefully that works. > > > > > > [1] > > > http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility > > > > > > cheers -ben > > > > > > On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz > > > > > > > wrote: > > > > > > > > > > I would rename it to SmalltalkCompatibility to > > > > > > ANSICompatibility > > > > > > because "Compatibility" is a too general term and could > > > > > > mean > > > > > > backward compatibility > > > > > > of Pharo versions or compatibility to other languages as > > > > > > well. > > > > > > > > > > That was me :) I was thinking more broadly that over time > > > > > the > > > > > "repository" might hold different packages Compatibility > > > > > -ANSI, > > > > > Compatibility-VW, Compatibility-Dolphin. But maybe that is > > > > > overreaching and its better to be more focussed. Let me know > > > > > what > > > > > you > > > > > think on this and restate what you think the repository name > > > > > should > > > > > be. > > > > > > > > Ben, could you please give me a commit access? I intend to > > > > move Compatibility-SmalltalkX and Compatibility-ANSI (which > > > > I created and "maintain" for my own need). Maybe some others > > > > may find them useful or maybe even contribute. > > > > > > > > Cheers, Jan > > > > > > > > > > > > > > > Also see http://wiki.squeak.org/squeak/2384 and > > > > > > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32 > > > > > > d338 > > > > > > 9ec > > > > > > which could be a start. > > > > > > > > > > I saw those, but they interact with existing classes, so I > > > > > thought it > > > > > easier to kickstart by loading in the tests first, which are > > > > > all > > > > > new > > > > > classes. I only created the repository since the tests were > > > > > *hard* > > > > > to > > > > > find eventually at > > > > > http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-com > > > > > pati > > > > > bili > > > > > ty/ > > > > > So I thought it would be good make them more accessible as a > > > > > Monticello Package. > > > > > > > > > > cheers -ben > > > > > > > > > > P.S. I don't quite follow "to SmalltalkCompatibility to > > > > > ANSICompatibility" > > > > > do you mean "to SmalltalkCompatibility or ANSICompatibility" > > > > > ? > > > > > > > > > > > > > > > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr > > > > > > > Von: stepharo <stepharo(a)free.fr> > > > > > > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > > > > > > Betreff: Re: [Pharo-dev] ANSICompatibility package > > > > > > > > > > > > > > We should have a SmalltalkCompatibility (not Ansi per se) > > > > > > > package > > > > > > > were we can add some methods to help migration. > > > > > > > > > > > > > > Stef > > > > > > > > > > > > > > > > > > > > > Le 8/9/15 06:04, Ben Coman a Ã©crit : > > > > > > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < > > > > > > > > jan.vrany(a)fit.cvut.cz> wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > is there actually such a thing like ANSICompatibility > > > > > > > > > package? > > > > > > > > > (it has been mentioned here lately, but I cannot find > > > > > > > > > it) > > > > > > > > > > > > > > > > > > Thanks, Jan > > > > > > > > > > > > > > > > > I made it up for the purpose of discussion to see what > > > > > > > > interest > > > > > > > > it generated. > > > > > > > > Should we start one ? > > > > > > > > cheers -ben > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Sept. 18, 2015

Re: [Pharo-dev] ANSICompatibility package

by Ben Coman

Thanks for your contribution Jan. It is interesting how in "CompatibilitySmalltalkX class>>initialize" you deal with missing classes by inserting what are essentially alias into the Smalltalk dictionary. So, I'm happy I learnt something new today. Just curious though why both the class-side and instance-side #initialize methods set the same alias, but different ways. Also curious why "ClassDescription>>isClass" is blank. It would seem to need a boolean return value. cheers -ben On Fri, Sep 18, 2015 at 10:05 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Thanks, Ben. Stuff copied. > > Cheers, Jan > > > On Fri, 2015-09-18 at 21:54 +0800, Ben Coman wrote: >> Jan, Thanks for your contribution. Actually I hadn't uploaded >> anything >> yet since I was waiting on more votes on renaming, but to push ahead >> I >> settled on SmalltalkCompatibility [1], since I think the repo can >> serve a wider purpose than just ANSI. >> >> I added you to the PharoExtras team. Hopefully that works. >> >> [1] http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility >> >> cheers -ben >> >> On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> >> wrote: >> > >> > > > I would rename it to SmalltalkCompatibility to >> > > > ANSICompatibility >> > > > because "Compatibility" is a too general term and could mean >> > > > backward compatibility >> > > > of Pharo versions or compatibility to other languages as well. >> > > >> > > That was me :) I was thinking more broadly that over time the >> > > "repository" might hold different packages Compatibility-ANSI, >> > > Compatibility-VW, Compatibility-Dolphin. But maybe that is >> > > overreaching and its better to be more focussed. Let me know what >> > > you >> > > think on this and restate what you think the repository name >> > > should >> > > be. >> > >> > Ben, could you please give me a commit access? I intend to >> > move Compatibility-SmalltalkX and Compatibility-ANSI (which >> > I created and "maintain" for my own need). Maybe some others >> > may find them useful or maybe even contribute. >> > >> > Cheers, Jan >> > >> > > >> > > > Also see http://wiki.squeak.org/squeak/2384 and >> > > > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d338 >> > > > 9ec >> > > > which could be a start. >> > > >> > > I saw those, but they interact with existing classes, so I >> > > thought it >> > > easier to kickstart by loading in the tests first, which are all >> > > new >> > > classes. I only created the repository since the tests were >> > > *hard* >> > > to >> > > find eventually at >> > > http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compati >> > > bili >> > > ty/ >> > > So I thought it would be good make them more accessible as a >> > > Monticello Package. >> > > >> > > cheers -ben >> > > >> > > P.S. I don't quite follow "to SmalltalkCompatibility to >> > > ANSICompatibility" >> > > do you mean "to SmalltalkCompatibility or ANSICompatibility" ? >> > > >> > > > >> > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr >> > > > > Von: stepharo <stepharo(a)free.fr> >> > > > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> > > > > Betreff: Re: [Pharo-dev] ANSICompatibility package >> > > > > >> > > > > We should have a SmalltalkCompatibility (not Ansi per se) >> > > > > package >> > > > > were we can add some methods to help migration. >> > > > > >> > > > > Stef >> > > > > >> > > > > >> > > > > Le 8/9/15 06:04, Ben Coman a Ã©crit : >> > > > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < >> > > > > > jan.vrany(a)fit.cvut.cz> wrote: >> > > > > > > Hi, >> > > > > > > >> > > > > > > is there actually such a thing like ANSICompatibility >> > > > > > > package? >> > > > > > > (it has been mentioned here lately, but I cannot find it) >> > > > > > > >> > > > > > > Thanks, Jan >> > > > > > > >> > > > > > I made it up for the purpose of discussion to see what >> > > > > > interest >> > > > > > it generated. >> > > > > > Should we start one ? >> > > > > > cheers -ben >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > > >> > >> >> >

Sept. 18, 2015

Re: [Pharo-dev] RubAbstractTextArea copying

by Henrik Nergaard

Hi Stephan, I looked into the bug a bit and found something strange.... | m m2 | m := ColorPanel open. m2 := m submorphs third copy. m = m2 panel. "prints false; the panel is duplicated " ------------- add this method to DragWelL: veryDeepInner: deepCopier super veryDeepInner: deepCopier and it returns true. Another observation is that after all the text is lost, if you have a Playground that is effected and try to do something like: (ColorPanel allInstances size.) it raises an error 'MessageNotUnderstood: receiver of "style:" is nil' from "a GLMMorphicPharoPlaygroundRenderer actOnHighlightAndEvaluate: ann" Hope this helps Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont Sent: Friday, September 18, 2015 4:09 PM To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] RubAbstractTextArea copying I'm trying to understand how to copy a rubric text morph. I don't have a 2nd implementor of #text:textStyle:textColor so how does this work? RubAbstractTextArea>>text: t textStyle: s color: c textColor: tc "Private -- for use only in morphic duplication" self releaseParagraph. super text: t textStyle: s color: c textColor: tc.

Sept. 18, 2015

Re: [Pharo-dev] R: ANSICompatibility package

by Ben Coman

Thanks Lorenzo, but I'm not clear what the offer is... * making VisualSmalltalk compatible with ANSI ? * making Pharo compatible with VisualSmalltalk ? cheers -ben On Fri, Sep 18, 2015 at 10:09 PM, Lorenzo Schiavina <lorenzo(a)edor.it> wrote: > Hi Ben, > > I am available if you want to include VisualSmalltalk into ANSICompatibility package. > I have both full documentation and lot of applications. > > Lorenzo > > -----Messaggio originale----- > Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Ben Coman > Inviato: venerdÃ¬ 18 settembre 2015 15:54 > A: Pharo Development List > Oggetto: Re: [Pharo-dev] ANSICompatibility package > > Jan, Thanks for your contribution. Actually I hadn't uploaded anything yet since I was waiting on more votes on renaming, but to push ahead I settled on SmalltalkCompatibility [1], since I think the repo can serve a wider purpose than just ANSI. > > I added you to the PharoExtras team. Hopefully that works. > > [1] http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility > > cheers -ben > > On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >>> > I would rename it to SmalltalkCompatibility to ANSICompatibility >>> > because "Compatibility" is a too general term and could mean >>> > backward compatibility of Pharo versions or compatibility to other >>> > languages as well. >>> >>> That was me :) I was thinking more broadly that over time the >>> "repository" might hold different packages Compatibility-ANSI, >>> Compatibility-VW, Compatibility-Dolphin. But maybe that is >>> overreaching and its better to be more focussed. Let me know what you >>> think on this and restate what you think the repository name should >>> be. >> >> Ben, could you please give me a commit access? I intend to move >> Compatibility-SmalltalkX and Compatibility-ANSI (which I created and >> "maintain" for my own need). Maybe some others may find them useful or >> maybe even contribute. >> >> Cheers, Jan >> >>> >>> > Also see http://wiki.squeak.org/squeak/2384 and >>> > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec >>> > which could be a start. >>> >>> I saw those, but they interact with existing classes, so I thought it >>> easier to kickstart by loading in the tests first, which are all new >>> classes. I only created the repository since the tests were *hard* >>> to find eventually at >>> http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compatibili >>> ty/ >>> So I thought it would be good make them more accessible as a >>> Monticello Package. >>> >>> cheers -ben >>> >>> P.S. I don't quite follow "to SmalltalkCompatibility to >>> ANSICompatibility" >>> do you mean "to SmalltalkCompatibility or ANSICompatibility" ? >>> >>> > >>> > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr >>> > > Von: stepharo <stepharo(a)free.fr> >>> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> > > Betreff: Re: [Pharo-dev] ANSICompatibility package >>> > > >>> > > We should have a SmalltalkCompatibility (not Ansi per se) package >>> > > were we can add some methods to help migration. >>> > > >>> > > Stef >>> > > >>> > > >>> > > Le 8/9/15 06:04, Ben Coman a Ã©crit : >>> > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < >>> > > > jan.vrany(a)fit.cvut.cz> wrote: >>> > > > > Hi, >>> > > > > >>> > > > > is there actually such a thing like ANSICompatibility >>> > > > > package? >>> > > > > (it has been mentioned here lately, but I cannot find it) >>> > > > > >>> > > > > Thanks, Jan >>> > > > > >>> > > > I made it up for the purpose of discussion to see what interest >>> > > > it generated. >>> > > > Should we start one ? >>> > > > cheers -ben >>> > > > >>> > > > >>> > > >>> > > >>> > > >>> > >>> >>> >> > >

Sept. 18, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 18, 2015

[pharo-project/pharo-core] 0f5bc4: 50332

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0f5bc4ad3988e682b5dcb39d06356ed64e478bde https://github.com/pharo-project/pharo-core/commit/0f5bc4ad3988e682b5dcb39d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-18 (Fri, 18 Sep 2015) Changed paths: M Multilingual-Encodings.package/EncodedCharSet.class/class/class methods/ucsTable.st M Multilingual-Encodings.package/Latin1.class/class/class methods/initialize.st A Multilingual-Encodings.package/Latin1.class/class/class methods/initializeUcsTable.st M Multilingual-Encodings.package/ManifestMultilingualEncodings.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R Multilingual-Encodings.package/UCSTable.class/README.md R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/gb2312Table.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/initialize.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/initializeLatin1Table.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/jisx0208Table.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/ksx1001Table.st R Multilingual-Encodings.package/UCSTable.class/class/accessing - table/latin1Table.st R Multilingual-Encodings.package/UCSTable.class/definition.st A Multilingual-Encodings.package/Unicode.class/class/character classification/ucsTable.st M Multilingual-OtherLanguages.package/GB2312.class/class/class methods/initialize.st A Multilingual-OtherLanguages.package/GB2312.class/class/class methods/initializeUcsTable.st R Multilingual-OtherLanguages.package/GB2312.class/class/class methods/ucsTable.st A Multilingual-OtherLanguages.package/JISX0208.class/class/character classification/initializeUcsTable.st M Multilingual-OtherLanguages.package/JISX0208.class/class/class methods/initialize.st R Multilingual-OtherLanguages.package/JISX0208.class/class/class methods/ucsTable.st M Multilingual-OtherLanguages.package/KSX1001.class/class/class methods/initialize.st A Multilingual-OtherLanguages.package/KSX1001.class/class/class methods/initializeUcsTable.st R Multilingual-OtherLanguages.package/KSX1001.class/class/class methods/ucsTable.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50331.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50332.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50331.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50332.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Unicode-Initialization.package/extension/CombinedChar/class/parseCompositionMappingFrom_.st R Unicode-Initialization.package/extension/UCSTable/class/initializeGB2312Table.st R Unicode-Initialization.package/extension/UCSTable/class/initializeJISX0208Table.st R Unicode-Initialization.package/extension/UCSTable/class/initializeKSX1001Table.st Log Message: ----------- 50332 16595 Get rid of UnicodeInitialization in the bootstrap https://pharo.fogbugz.com/f/cases/16595 http://files.pharo.org/image/50/50332.zip

Sept. 18, 2015

R: ANSICompatibility package

by Lorenzo Schiavina

Hi Ben, I am available if you want to include VisualSmalltalk into ANSICompatibility package. I have both full documentation and lot of applications. Lorenzo -----Messaggio originale----- Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Ben Coman Inviato: venerdÃ¬ 18 settembre 2015 15:54 A: Pharo Development List Oggetto: Re: [Pharo-dev] ANSICompatibility package Jan, Thanks for your contribution. Actually I hadn't uploaded anything yet since I was waiting on more votes on renaming, but to push ahead I settled on SmalltalkCompatibility [1], since I think the repo can serve a wider purpose than just ANSI. I added you to the PharoExtras team. Hopefully that works. [1] http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility cheers -ben On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> > I would rename it to SmalltalkCompatibility to ANSICompatibility >> > because "Compatibility" is a too general term and could mean >> > backward compatibility of Pharo versions or compatibility to other >> > languages as well. >> >> That was me :) I was thinking more broadly that over time the >> "repository" might hold different packages Compatibility-ANSI, >> Compatibility-VW, Compatibility-Dolphin. But maybe that is >> overreaching and its better to be more focussed. Let me know what you >> think on this and restate what you think the repository name should >> be. > > Ben, could you please give me a commit access? I intend to move > Compatibility-SmalltalkX and Compatibility-ANSI (which I created and > "maintain" for my own need). Maybe some others may find them useful or > maybe even contribute. > > Cheers, Jan > >> >> > Also see http://wiki.squeak.org/squeak/2384 and >> > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec >> > which could be a start. >> >> I saw those, but they interact with existing classes, so I thought it >> easier to kickstart by loading in the tests first, which are all new >> classes. I only created the repository since the tests were *hard* >> to find eventually at >> http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compatibili >> ty/ >> So I thought it would be good make them more accessible as a >> Monticello Package. >> >> cheers -ben >> >> P.S. I don't quite follow "to SmalltalkCompatibility to >> ANSICompatibility" >> do you mean "to SmalltalkCompatibility or ANSICompatibility" ? >> >> > >> > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr >> > > Von: stepharo <stepharo(a)free.fr> >> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> > > Betreff: Re: [Pharo-dev] ANSICompatibility package >> > > >> > > We should have a SmalltalkCompatibility (not Ansi per se) package >> > > were we can add some methods to help migration. >> > > >> > > Stef >> > > >> > > >> > > Le 8/9/15 06:04, Ben Coman a Ã©crit : >> > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < >> > > > jan.vrany(a)fit.cvut.cz> wrote: >> > > > > Hi, >> > > > > >> > > > > is there actually such a thing like ANSICompatibility >> > > > > package? >> > > > > (it has been mentioned here lately, but I cannot find it) >> > > > > >> > > > > Thanks, Jan >> > > > > >> > > > I made it up for the purpose of discussion to see what interest >> > > > it generated. >> > > > Should we start one ? >> > > > cheers -ben >> > > > >> > > > >> > > >> > > >> > > >> > >> >> >

Sept. 18, 2015

RubAbstractTextArea copying

by Stephan Eggermont

I'm trying to understand how to copy a rubric text morph. I don't have a 2nd implementor of #text:textStyle:textColor so how does this work? RubAbstractTextArea>>text: t textStyle: s color: c textColor: tc "Private -- for use only in morphic duplication" self releaseParagraph. super text: t textStyle: s color: c textColor: tc.

Sept. 18, 2015

Re: [Pharo-dev] ANSICompatibility package

by Jan Vrany

Thanks, Ben. Stuff copied. Cheers, Jan On Fri, 2015-09-18 at 21:54 +0800, Ben Coman wrote: > Jan, Thanks for your contribution. Actually I hadn't uploaded > anything > yet since I was waiting on more votes on renaming, but to push ahead > I > settled on SmalltalkCompatibility [1], since I think the repo can > serve a wider purpose than just ANSI. > > I added you to the PharoExtras team. Hopefully that works. > > [1] http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility > > cheers -ben > > On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > wrote: > > > > > > I would rename it to SmalltalkCompatibility to > > > > ANSICompatibility > > > > because "Compatibility" is a too general term and could mean > > > > backward compatibility > > > > of Pharo versions or compatibility to other languages as well. > > > > > > That was me :) I was thinking more broadly that over time the > > > "repository" might hold different packages Compatibility-ANSI, > > > Compatibility-VW, Compatibility-Dolphin. But maybe that is > > > overreaching and its better to be more focussed. Let me know what > > > you > > > think on this and restate what you think the repository name > > > should > > > be. > > > > Ben, could you please give me a commit access? I intend to > > move Compatibility-SmalltalkX and Compatibility-ANSI (which > > I created and "maintain" for my own need). Maybe some others > > may find them useful or maybe even contribute. > > > > Cheers, Jan > > > > > > > > > Also see http://wiki.squeak.org/squeak/2384 and > > > > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d338 > > > > 9ec > > > > which could be a start. > > > > > > I saw those, but they interact with existing classes, so I > > > thought it > > > easier to kickstart by loading in the tests first, which are all > > > new > > > classes. I only created the repository since the tests were > > > *hard* > > > to > > > find eventually at > > > http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compati > > > bili > > > ty/ > > > So I thought it would be good make them more accessible as a > > > Monticello Package. > > > > > > cheers -ben > > > > > > P.S. I don't quite follow "to SmalltalkCompatibility to > > > ANSICompatibility" > > > do you mean "to SmalltalkCompatibility or ANSICompatibility" ? > > > > > > > > > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr > > > > > Von: stepharo <stepharo(a)free.fr> > > > > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > > > > Betreff: Re: [Pharo-dev] ANSICompatibility package > > > > > > > > > > We should have a SmalltalkCompatibility (not Ansi per se) > > > > > package > > > > > were we can add some methods to help migration. > > > > > > > > > > Stef > > > > > > > > > > > > > > > Le 8/9/15 06:04, Ben Coman a Ã©crit : > > > > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < > > > > > > jan.vrany(a)fit.cvut.cz> wrote: > > > > > > > Hi, > > > > > > > > > > > > > > is there actually such a thing like ANSICompatibility > > > > > > > package? > > > > > > > (it has been mentioned here lately, but I cannot find it) > > > > > > > > > > > > > > Thanks, Jan > > > > > > > > > > > > > I made it up for the purpose of discussion to see what > > > > > > interest > > > > > > it generated. > > > > > > Should we start one ? > > > > > > cheers -ben > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Sept. 18, 2015

Re: [Pharo-dev] ANSICompatibility package

by Ben Coman

Jan, Thanks for your contribution. Actually I hadn't uploaded anything yet since I was waiting on more votes on renaming, but to push ahead I settled on SmalltalkCompatibility [1], since I think the repo can serve a wider purpose than just ANSI. I added you to the PharoExtras team. Hopefully that works. [1] http://smalltalkhub.com/#!/~PharoExtras/SmalltalkCompatibility cheers -ben On Fri, Sep 18, 2015 at 7:10 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> > I would rename it to SmalltalkCompatibility to ANSICompatibility >> > because "Compatibility" is a too general term and could mean >> > backward compatibility >> > of Pharo versions or compatibility to other languages as well. >> >> That was me :) I was thinking more broadly that over time the >> "repository" might hold different packages Compatibility-ANSI, >> Compatibility-VW, Compatibility-Dolphin. But maybe that is >> overreaching and its better to be more focussed. Let me know what you >> think on this and restate what you think the repository name should >> be. > > Ben, could you please give me a commit access? I intend to > move Compatibility-SmalltalkX and Compatibility-ANSI (which > I created and "maintain" for my own need). Maybe some others > may find them useful or maybe even contribute. > > Cheers, Jan > >> >> > Also see http://wiki.squeak.org/squeak/2384 and >> > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec >> > which could be a start. >> >> I saw those, but they interact with existing classes, so I thought it >> easier to kickstart by loading in the tests first, which are all new >> classes. I only created the repository since the tests were *hard* >> to >> find eventually at >> http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compatibili >> ty/ >> So I thought it would be good make them more accessible as a >> Monticello Package. >> >> cheers -ben >> >> P.S. I don't quite follow "to SmalltalkCompatibility to >> ANSICompatibility" >> do you mean "to SmalltalkCompatibility or ANSICompatibility" ? >> >> > >> > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr >> > > Von: stepharo <stepharo(a)free.fr> >> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> > > Betreff: Re: [Pharo-dev] ANSICompatibility package >> > > >> > > We should have a SmalltalkCompatibility (not Ansi per se) package >> > > were we can add some methods to help migration. >> > > >> > > Stef >> > > >> > > >> > > Le 8/9/15 06:04, Ben Coman a Ã©crit : >> > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < >> > > > jan.vrany(a)fit.cvut.cz> wrote: >> > > > > Hi, >> > > > > >> > > > > is there actually such a thing like ANSICompatibility >> > > > > package? >> > > > > (it has been mentioned here lately, but I cannot find it) >> > > > > >> > > > > Thanks, Jan >> > > > > >> > > > I made it up for the purpose of discussion to see what interest >> > > > it generated. >> > > > Should we start one ? >> > > > cheers -ben >> > > > >> > > > >> > > >> > > >> > > >> > >> >> >

Sept. 18, 2015

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

by Jan Vrany

On Fri, 2015-09-18 at 14:48 +0200, Marcus Denker wrote: > > > > > > > > > > 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. > > > > This is a nice thing. In the same way we can deal with abstract > > classes. So if someone develops an abstract class with an intent to > > use it, he can specify that itâs ok to use the class. > > > > True. > > Also is there any work on pragmas for classes, at some point Iâve > > heard something about it but canât recall. > > > Yes, the question is where to put it syntactically After a class declaration like this: LLVMDisposableObject subclass:#LLVMDIBuilder instanceVariableNames:'' classVariableNames:'' poolDictionaries:'LLVMModuleFlagBehavior' category:'LLVM-S-Core' Annotation key: 'disposable:' value: 'true' This ANSI-compatible way (see page 39 of NCITS J20 DRAFT of ANSI Smalltalk Standard, rev 1.9). Perhaps nice way is Annotation disposable: true > and how to save it in monticelloâ¦ In the source as above. In the binary, in a separate entry in the .zip so the other MC implementation won't crash but silently ignore them.

Sept. 18, 2015

[pharo-project/pharo-core]

by GitHub

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

Sept. 18, 2015

[pharo-project/pharo-core] 9c0520: 50331

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9c0520696d637781a4d225f3b83f862488b36f6b https://github.com/pharo-project/pharo-core/commit/9c0520696d637781a4d225f3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-18 (Fri, 18 Sep 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50330.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50331.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50330.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50331.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Changes.package/ChangeSet.class/class/defaults/promptForDefaultChangeSetDirectoryIfNecessary.st M System-Changes.package/ManifestSystemChanges.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st R System-Changes.package/extension/PositionableStream/instance/nextChunkText.st A Text-Core.package/extension/PositionableStream/instance/nextChunkText.st Log Message: ----------- 50331 16594 System-Changes should not depend on Text-Core https://pharo.fogbugz.com/f/cases/16594 http://files.pharo.org/image/50/50331.zip

Sept. 18, 2015

Re: [Pharo-dev] EncodedCharSets

by Nicolas Cellier

Yes, but first step consists in reading http://www.ipa.go.jp/files/000005751.pdf to exactly understand which feature you're going to loose, or better, how you're going to support it differently. Nicolas 2015-09-18 10:10 GMT+02:00 Christophe Demarey <Christophe.Demarey(a)inria.fr>: > Thanks all for your explanations. > It looks like there are still a lot of things to clean. > > Christophe > > Le 17 sept. 2015 Ã 19:26, Eliot Miranda a Ã©crit : > > 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. 18, 2015

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

by Marcus Denker

>>> >> >> 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. > > This is a nice thing. In the same way we can deal with abstract classes. So if someone develops an abstract class with an intent to use it, he can specify that itâs ok to use the class. > True. > Also is there any work on pragmas for classes, at some point Iâve heard something about it but canât recall. > Yes, the question is where to put it syntactically and how to save it in monticelloâ¦ could be interesting to have. > I will try to hack a bit this weekend and see if I can add some kind of automation to marking a class as used. I.e. if you see a critic, you should be able to mark the class as being used with 1-2 clicks. If you are developing some king of facade, you should know that you will not reference it from your library. > ok. Marcus

Sept. 18, 2015

Re: [Pharo-dev] Bitmap VS WordArray in System-Hashing

by Max Leske

> On 18 Sep 2015, at 13:51, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi, > > With Max M., we try to kill the dependency between System-Hashing to Graphics - Display Objects. > The dependency is there because SHA1 and SHA256 use the Bitmap class to store raw data. > We came to replace the use of Bitmap by a WordArray. Tests are still working. > > Could someone tell us if this fix is right or if we miss something? > > Thanks, > Max and Christophe Looks good to me. Also: the âtotalsâ variable (which is the bitmap) is never used in SHA-256 (only written once and then assigned nil later). Cheers, Max

Sept. 18, 2015

Bitmap VS WordArray in System-Hashing

by Christophe Demarey

Hi, With Max M., we try to kill the dependency between System-Hashing to Graphics - Display Objects. The dependency is there because SHA1 and SHA256 use the Bitmap class to store raw data. We came to replace the use of Bitmap by a WordArray. Tests are still working. Could someone tell us if this fix is right or if we miss something? Thanks, Max and Christophe

Sept. 18, 2015

Re: [Pharo-dev] ANSICompatibility package

by Jan Vrany

> > I would rename it to SmalltalkCompatibility to ANSICompatibility > > because > > "Compatibility" is a too general term and could mean backward > > compatibility > > of Pharo versions or compatibility to other languages as well. > > That was me :) I was thinking more broadly that over time the > "repository" might hold different packages Compatibility-ANSI, > Compatibility-VW, Compatibility-Dolphin. But maybe that is > overreaching and its better to be more focussed. Let me know what you > think on this and restate what you think the repository name should > be. Ben, could you please give me a commit access? I intend to move Compatibility-SmalltalkX and Compatibility-ANSI (which I created and "maintain" for my own need). Maybe some others may find them useful or maybe even contribute. Cheers, Jan > > > Also see http://wiki.squeak.org/squeak/2384 and > > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec > > which could be a start. > > I saw those, but they interact with existing classes, so I thought it > easier to kickstart by loading in the tests first, which are all new > classes. I only created the repository since the tests were *hard* > to > find eventually at > http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compatibili > ty/ > So I thought it would be good make them more accessible as a > Monticello Package. > > cheers -ben > > P.S. I don't quite follow "to SmalltalkCompatibility to > ANSICompatibility" > do you mean "to SmalltalkCompatibility or ANSICompatibility" ? > > > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr > > > Von: stepharo <stepharo(a)free.fr> > > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > > Betreff: Re: [Pharo-dev] ANSICompatibility package > > > > > > We should have a SmalltalkCompatibility (not Ansi per se) package > > > were we can add some methods to help migration. > > > > > > Stef > > > > > > > > > Le 8/9/15 06:04, Ben Coman a Ã©crit : > > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany < > > > > jan.vrany(a)fit.cvut.cz> wrote: > > > > > Hi, > > > > > > > > > > is there actually such a thing like ANSICompatibility > > > > > package? > > > > > (it has been mentioned here lately, but I cannot find it) > > > > > > > > > > Thanks, Jan > > > > > > > > > I made it up for the purpose of discussion to see what interest > > > > it generated. > > > > Should we start one ? > > > > cheers -ben > > > > > > > > > > > > > > > > > > > > >

Sept. 18, 2015

Pharo 5 and method extensions

by roberto.minelli＠usi.ch

Dear all, I just moved to Pharo 5 for development and discovered that it does not correctly show method extensions. I opened a case https://pharo.fogbugz.com/f/cases/16601/Pharo-5-does-not-show-method-extens… Cheers, R

Sept. 18, 2015

Re: [Pharo-dev] Configuration Madness

by roberto.minelli＠usi.ch

Thanks a lot Dale, this works indeed. P.s. Sorry for the delay in the answer but my mailbox went crazy! R > On 16 Sep 2015, at 17:43, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > > On 9/16/15 8:07 AM, Max Leske wrote: >>> On 16 Sep 2015, at 16:39, roberto.minelli(a)usi.ch wrote: >>> >>> Dear all, >>> >>> I have a question about the ConfigurationOf my project, and I really hope you can help. >>> >>> In my project I have a package called âDevFlow-Extensionsâ that is a âplaceholderâ for code that is dependent on the Pharo version. >>> >>> On the ConfigurationOf, according to the Pharo version I do something like >>> >>> spec for: #'pharo3.x' >>> do: [ >>> >>> spec blessing: #baseline. >>> spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. >>> >>> spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions30'. >>> ]. >>> >>> spec for: #'pharo4.x' >>> do: [ >>> >>> spec blessing: #baseline. >>> spec repository: 'http://smalltalkhub.com/mc/RobertoMinelli/DevFlow/main'. >>> >>> spec package: 'DevFlow-Extensions' with: 'DevFlow-Extensions40'. >>> ]. >>> >>> In this way, in Pharo 3.0 Iâd load DevFlow-Extensions30 and in Pharo 4.0 Iâd load DevFlow-Extensions40. Super cool. >>> I am using a single package (âDevFlow-Extensionsâ) to specify of groups, for example: >>> >>> spec group: 'User' with: #( >>> 'DevFlow-Meta' >>> ... >>> 'DevFlow-Announcement' >>> 'DevFlow-Extensions'). >>> >>> Now the problem is that for Pharo 5 I have to load both 'DevFlow-Extensions40â and 'DevFlow-Extensions50â. >>> I read the chapter on Metacello, but didnât find a solution. I tried some combinations of #includes: and #requires: but with no luck. >>> >>> Any help is appreciated, thank you very much! >>> >>> Roberto >> Shouldnât this work? >> >> spec package: 'DevFlow-Extensions' with: #('DevFlow-Extensions40â âDevFlow-Extensions50). >> >> >> > Good idea, but it's not quite correct, I think this will work: > > spec for: #'pharo5.x' > do: [ > spec package: 'DevFlow-Extensions40' . > spec package: 'DevFlow-Extensions50' . > spec group: 'DevFlow-Extensions' with: #('DevFlow-Extensions40â âDevFlow-Extensions50) ]. > > > Dale >

Sept. 18, 2015

Re: [Pharo-dev] EncodedCharSets

by Christophe Demarey

Thanks all for your explanations. It looks like there are still a lot of things to clean. Christophe Le 17 sept. 2015 Ã 19:26, Eliot Miranda a Ã©crit : > 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. 18, 2015

Re: [Pharo-dev] About the Unicode class

by Christophe Demarey

Thanks for your answers. I also took a look in Squeak 5.0 but the implementation is also incomplete. I think the best is to remove unused unicode character categories. Le 17 sept. 2015 Ã 18:27, Nicolas Cellier a Ã©crit : > 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. 18, 2015

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

by Stephan Eggermont

On 17-09-15 23:11, Nicolai Hess wrote: > 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. Thanks. So there's something wrong with how I hold onto the Rubric text morph and or model. Something shouldn't be copied there. We don't have many examples of using veryDeepCopy and the fixups needed in image, and I'm not sure I fully understand the class comment of DeepCopier :( The clone menu option for a code card does a duplicate, and that creates the same problem as shown with the color panel. In CodeCard I hold onto both the model and the morph. They are connected using announcements, if I understand it correctly? Shouldn't that connection be rewired when doing a copy? Stephan

Sept. 18, 2015

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

by Yuriy Tymchuk

> On 18 Sep 2015, at 08:34, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> 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. This is a nice thing. In the same way we can deal with abstract classes. So if someone develops an abstract class with an intent to use it, he can specify that itâs ok to use the class. Also is there any work on pragmas for classes, at some point Iâve heard something about it but canât recall. I will try to hack a bit this weekend and see if I can add some kind of automation to marking a class as used. I.e. if you see a critic, you should be able to mark the class as being used with 1-2 clicks. If you are developing some king of facade, you should know that you will not reference it from your library. Uko > > Marcus

Sept. 18, 2015