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