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

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Camille

> On 24 Feb 2015, at 10:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 24 Feb 2015, at 09:58, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >> >> >> >> 2015-02-24 9:48 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: >> >> > On 24 Feb 2015, at 09:47, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> > >> > >> >> On 24 Feb 2015, at 09:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> >> >> But for configuration everyone anyway uses >> >> >> >> âCoufigurationOfâ¦â asClass load >> > >> > I wasnât aware that #asClass existedâ¦ ;) >> >> You are a Noob, Max ;-) >> >> >> Maybe >> >> 'Foo' as: Class >> -> >> String>>as: aBehavior ^aBehavior fromString: self >> -> >> ^Class fromString: 'Foo' >> >> or something like that? >> >> > > I wonder why we do not just late-bind global access. Yes why not. The question is: late-bind onto whom? Since bindings can be changed without recompilation, Iâm not sure that late-bound global have a lot of added value. Camille > > Marcus

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Camille

> On 24 Feb 2015, at 08:18, stepharo <stepharo(a)free.fr> wrote: > > Interesting idea. > We should have a guy trying. Thatâs close to one of the first thing I tried when I started with Pharo, and I liked it (you didnât back then ;) ). Packages were globals (so no dashes in their name unfortunately) and answered #import: #import:as: #load #unload #@â¦ Each package was defining an environment for its classes and this environment had a ThisEnvironment binding pointing to itself. You could change imports with statements like: ThisEnvironment import: SomePackage @ #SomeClass as: #LocalName. The only difference with what Marcus suggests is that packages didnât have business-level behavior. If you want that, nested classes sound like a good solution since in that context both packages and classes define behavior and are instanciable. So it worth unifying both concepts. I tried that also, but first itâs much more difficult to implement cleanly (I remember that I had to rely on many little hacks to make it work) and then it's a huge paradigm shift we canât afford (basically transforming Pharo into Newspeak). If we were writing a new language I would say yes, go for nested classes, but integrating into them into Pharo, no. And in the end, not many packages offer a stand-alone service like Compiler does. So instead, having one class in a package that acts as a facade is good enough to me. > I would be curious to see what is happening in the context of Conch (the module system of camille). > He should present it to us too. Conch is about local extension methods, not about global variables. Dealing with globals is much simpler, partly because the problem itself is simpler, partly because the infrastructure is already there: classes answer to #environment and thatâs what is used during compilation instead of 'Smalltalk globals'. > But we would need somebody to work on the tools. Yes, thatâs the difficult part for any language extension. And code migration... > Now for me what I would prefer is to have a kernel in which class have a direct pointer to their packages like for their super/subclasses. Classes already have an #environment and it does the job. Of course, we could rename it to #package if we all agree that to one package corresponds one environment. Camille > Stef > > > Le 24/2/15 08:01, Marcus Denker a Ã©crit : >>> On 24 Feb 2015, at 07:49, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Just my 2 cents: >>> >>> I find this really useful and have already implemented this extension in a couple of my packages, as writing: >>> >>> RuleChecker check: (RPackageOrganizer default packageNamed: âKernelâ) >>> >>> is much worse than: >>> >>> RuleChecker check: âKernelâ asPackage >>> >>> >> Sometimes I wonder if Packages should not be part of the Smalltalk globals namespaceâ¦ >> >> e.g. packages could have a nice reflective API: >> >> MyPackage unload. >> >> and even an API for usingâ¦ e.g. a Compiler has a very tiny surface API: >> >> OpalCompiler compile: ââ¦.â >> >> (but I do not really like nested classes, which is what people will now suggestâ¦) >> >> Marcus >> > >

Feb. 24, 2015

Re: [Pharo-dev] Spotter does not respect the selected fonts

by Marcus Denker

> On 24 Feb 2015, at 13:11, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > yesterday I gave a presentation and spotter fonts were not updated to the font changes > Yes, this is the editor (Rubric). The font setting is just for the old one. There are already two issues on the issue tracker about this. Marcus

Feb. 24, 2015

about dark theme

by stepharo

just some feedback because I was forced to use it because the projector quality was not great. and now I cannot use it on my machine :) the caret is black as well as the window cross and it is really difficult to see them on my machine. Stef

Feb. 24, 2015

Spotter does not respect the selected fonts

by stepharo

Hi guys yesterday I gave a presentation and spotter fonts were not updated to the font changes Stef

Feb. 24, 2015

[pharo-project/pharo-core]

by GitHub

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

Feb. 24, 2015

[pharo-project/pharo-core] 1aa5d3: 40504

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 1aa5d3e8e3390d4fcda678dda52bd6132c38dd7a https://github.com/pharo-project/pharo-core/commit/1aa5d3e8e3390d4fcda678dd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-24 (Tue, 24 Feb 2015) Changed paths: A Deprecated40.package/extension/OldClassBuilderAdapter/instance/anonymousSubclassOf_.st A Gofer-Core.package/extension/MCFileTreeRepository/instance/goferVersionFrom_.st M Kernel.package/Class.class/instance/subclass creation/newAnonymousSubclass.st A Metacello-MC.package/extension/MCFileTreeRepository/instance/versionInfoFromVersionNamed_.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/accessing/allFileNames.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/accessing/allFileNamesForVersionNamed_.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/accessing/directory_.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/accessing/filterFileNames_forVersionNamed_.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/accessing/versionFromFileNamed_.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/accessing/versionInfoFromFileNamed_.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/accessing/versionNameFromFileName_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/allFileNames.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/allFileNamesForVersionNamed_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/basicStoreVersion_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/cachedFileNames.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/canReadFileNamed_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/directory_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/filterFileNames_forVersionNamed_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/flushCache.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/goferVersionFrom_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/versionFromFileNamed_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/versionInfoFromFileNamed_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/versionNameFromFileName_.st R MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/as yet unclassified/writeRepositoryProperties.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/caching/cachedFileNames.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/private/flushCache.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/private/writeRepositoryProperties.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/storing/basicStoreVersion_.st A MonticelloFileTree-Core.package/MCFileTreeRepository.class/instance/testing/canReadFileNamed_.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/generateInitialize.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script504.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40504.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot-Tests.package/SlotIntegrationTest.class/instance/tests/testAnonymousSubclass.st R Slot.package/OldClassBuilderAdapter.class/instance/accessing/anonymousClassInstaller.st R Slot.package/OldClassBuilderAdapter.class/instance/adapted api/anonymousSubclassOf_.st Log Message: ----------- 40504 14964 deprecated #anonymousSubclassOf: https://pharo.fogbugz.com/f/cases/14964 14975 Generate initialize methods should be in initialization protocol https://pharo.fogbugz.com/f/cases/14975 14967 MCFileTreeRepository does not implement #versionInfoFromVersionNamed: correctly https://pharo.fogbugz.com/f/cases/14967 http://files.pharo.org/image/40/40504.zip

Feb. 24, 2015

Torch repo?

by Yuriy Tymchuk

Hi, is there anywhere a repo of the Torch project by Veronica? Uko

Feb. 24, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 3fabea: 40497

by Marcus Denker

> On 24 Feb 2015, at 09:58, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2015-02-24 9:48 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > > > On 24 Feb 2015, at 09:47, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > > > > > >> On 24 Feb 2015, at 09:33, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > >> > >> But for configuration everyone anyway uses > >> > >> âCoufigurationOfâ¦â asClass load > > > > I wasnât aware that #asClass existedâ¦ ;) > > You are a Noob, Max ;-) > > > Maybe > > 'Foo' as: Class > -> > String>>as: aBehavior ^aBehavior fromString: self > -> > ^Class fromString: 'Foo' > > or something like that? > > I wonder why we do not just late-bind global access. Marcus

Feb. 24, 2015

Re: [Pharo-dev] [jenkins] >30 issues for review

by Marcus Denker

Now that the CI is working againâ¦ there is *a lot* to review, massage and pushâ¦ keep in mind that *nothing* happens by itself, regardless how obvious/trivialâ¦ > On 20 Feb 2015, at 13:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > People are busy submitting fixes and improvements.. we should not forget to give them feedback. > > There are a lot if issues that needs reviewsâ¦ > > 6 where the monkey ran (or can not run): > https://pharo.fogbugz.com/f/filters/45/Review > > and 26 waiting for the monkey that is down due to CI: > > https://pharo.fogbugz.com/f/filters/36/Fixed-to-Review > > Marcus

Feb. 24, 2015