- Pharo-dev - lists.pharo.org

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