- Pharo-dev - lists.pharo.org

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

by stepharo

Doru and Yuriy String is not a good API for reflective operations. This is what you are doing with asPackage. When I want to access to a class I do Class or Smalltalk globals classNamed: 'Point' a compile method Point>>#x and not 'Point?x' asCompiledMethod I would prefer to have Package named: 'jkljk' than the string behavior. and what if I want to reflect on code that is remote? So I maintain that we are polluting String with reflective operations that it should not have. Stef

Feb. 24, 2015

Re: [Pharo-dev] convention for protocol names

by Esteban Lorenzano

> On 24 Feb 2015, at 08:47, Nicolai Hess <nicolaihess(a)web.de> wrote: > > Nautilus provides some nice icons for different protocol names > a red square for a "private" > a yellow diamond for "initialization" > > And you can generate the initialize method. > But this generated initialize method is put into an "initialize" protocol. > > What is the convention a protocol for the initialize methods: > > initialize > or > initialization this one :) Esteban > ? > > nicolai >

Feb. 24, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by Marcus Denker

> On 19 Feb 2015, at 10:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >> I started to implement PropertySlot, this uses hidden slots, initialisation (to set the empty dictionary of the base slot), virtual slots >> (the proper slots), reflectively changing the class both when adding and removing (to add the base slot and remove it as needed). >> > > Next tiny step: > > 14914 #initializeSlots: should not skip hidden slots > https://pharo.fogbugz.com/f/cases/14914/initializeSlots-should-not-skip-hid… > This is now finally in 502â¦ 5 days feel like eternity. > Now the slots get correctly called when initialising an object. To test: > > Object subclass: #TT > slots: { #tt => PropertySlot } > classVariables: { } > category: âPlayground' > > The slot will add an #initialize methods to the class when it gets installed. > > When you inspect > > TT new > > you can see just the tt slot (you can change it in the inspector). > > Adding an accessor for tt will show what the compiler does: > > 21 <20> pushConstant: #tt => PropertySlot > 22 <70> self > 23 <E1> send: read: > 24 <7C> returnTop > > > this means that it compiles a reflective read for that slot.

Feb. 24, 2015

convention for protocol names

by Nicolai Hess

Nautilus provides some nice icons for different protocol names a red square for a "private" a yellow diamond for "initialization" And you can generate the initialize method. But this generated initialize method is put into an "initialize" protocol. What is the convention a protocol for the initialize methods: initialize or initialization ? nicolai

Feb. 24, 2015

[pharo-project/pharo-core]

by GitHub

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

Feb. 24, 2015

[pharo-project/pharo-core] 3f2cda: 40502

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 3f2cdac7de828dde7c7a11862756359315d4fb26 https://github.com/pharo-project/pharo-core/commit/3f2cdac7de828dde7c7a1186… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-24 (Tue, 24 Feb 2015) Changed paths: M Kernel.package/Class.class/instance/instance variables/addInstVarNamed_.st M Kernel.package/Duration.class/instance/accessing/seconds.st A Kernel.package/Duration.class/instance/accessing/totalSeconds.st A Kernel.package/Duration.class/instance/accessing/wholeMicroseconds.st A Kernel.package/Duration.class/instance/accessing/wholeMilliseconds.st A Kernel.package/Duration.class/instance/accessing/wholeNanoseconds.st A Kernel.package/Duration.class/instance/printing/humanReadablePrintString.st A Kernel.package/Duration.class/instance/printing/printHumanReadableOn_.st A KernelTests.package/DurationTest.class/instance/tests/testHumanReadablePrintString.st A KernelTests.package/DurationTest.class/instance/tests/testIsZero.st A KernelTests.package/DurationTest.class/instance/tests/testPrintHumanReadableOn.st A KernelTests.package/DurationTest.class/instance/tests/testTotalSeconds.st A KernelTests.package/DurationTest.class/instance/tests/testWholeMicroseconds.st A KernelTests.package/DurationTest.class/instance/tests/testWholeMilliseconds.st A KernelTests.package/DurationTest.class/instance/tests/testWholeNanoseconds.st M Manifest-Core.package/TheManifestBuilder.class/instance/adding%2Fremoving/removeManifestOf_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script502.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40502.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Slot.package/PropertyBaseSlot.class/instance/testing/isVisible.st M Slot.package/PropertySlot.class/instance/class building/installingIn_.st M Slot.package/SlotClassBuilder.class/instance/initialize-release/buildNewClass.st M Traits.package/TBehavior.class/instance/initialization/initializeSlots_.st Log Message: ----------- 40502 14960 Extend Duration with a human readable print option and some related accessors https://pharo.fogbugz.com/f/cases/14960 14963 addInstVarNamed: should use addSlot: https://pharo.fogbugz.com/f/cases/14963 14970 TheManifestBuilder>>removeManifestOf:(manifest is shadowed) https://pharo.fogbugz.com/f/cases/14970 14914 #initializeSlots: should not skip hidden slots https://pharo.fogbugz.com/f/cases/14914 http://files.pharo.org/image/40/40502.zip

Feb. 24, 2015

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

by stepharo

I have to think about what it means that have them in global (in terms of having different kind of value for binding). 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] [pharo-project/pharo-core] 3fabea: 40497

by stepharo

Interesting idea. We should have a guy trying. 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. But we would need somebody to work on the tools. 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. 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] Class/Method common interface idea

by Marcus Denker

> On 23 Feb 2015, at 17:46, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi, > > so my idea is that maybe we can create traits for common classes(behaviors) and methods properties. Because besides the real ones there are ring, monticello and other definitions. It would be nice if one could browse the trait that defines common properties for all the definitions + if someone needs a custom property - there is one place to add it. What is clear is that we need to unify the API. We now have propertyValueAt: in CompiledMethod and Behaviour, while RBProgramNode uses propertyAt: and Morph even valueOfProperty: I think the best is just propertyAt:, we donât have âvalueAt:â in Array, either. As for a shared Traitâ¦ the implementation is quite different in all of them... Marcus

Feb. 24, 2015

Re: [Pharo-dev] Determine if a method is Jitted or not

by Marcus Denker

> On 23 Feb 2015, at 18:07, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > On Feb 23, 2015, at 7:50 AM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > >> >> >> 2015-02-23 16:36 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >> Hi Thierry, >> >> there's an unadvertised primitive called Context>>#xRay (or ContextPart>>#xRay) that answers these questions for tests. I'm away from the system right now but I'll get you the source soon. Also, the limit on jutting methods, 60 literals, is a default. There's a command line option -maxcoglits (IIRC) that you can change. >> >> Thanks Eliot! >> >> It's helping a lot to guide me, even if I have to work at the ast level and, as a result, I estimate the number of literals in the bytecode by counting the number of literal nodes in the AST, with the approximation that ~100 literal nodes will make it under the limit. >> >> Making it under the limit shaves 30% of the execution time of a parse with SmaCC. And it avoids the too long methods as a side benefit. >> >> I would dream of having precise ways of estimating things like that on the AST. It's interesting to hit those "I'd like to be able to predict the performance of that piece of code" issues. > > Alas two things other than the AST affect the number of literals. First is the specialSelectors; these are used for sends only. So if a method only sends one of the special selectors the selector will not occur in the method as a literal. Second is the bytecode set. While we only have one set now, Sista is introducing another, and Newspeak has its own. In the current set, -1, 0, 1 & 2 and true and false have bytecodes to push these literals, so they don't occur as literals in methods. In both the Sista and the Newspeak sets there are bytecodes that encode a much wider range of integers and characters as bytecodes (a push literal bytecode takes 1 byte for the bytecode and 4 or 8 bytes for the literal; a bytecode for the 16-bit integer range takes 3 bytes). > > Another thing that affects the number of literals is the compiler's decision to include selectors for optimized methods such as ifTrue: et al (which I think is a very good thing). > > If you could ask the back end which literal would be encoded as a literal (and if course the question is asked when bytecode is generated) you could get a more accurate count. > Another thing that we use the literal array for is (will be) meta objectâ¦ if you annotate an AST node or variable with a MetaLink, it stores that in the literal array. For example: link := MetaLink new metaObject: Halt; selector: #now. then installing this on some AST node (or Slot) will lead to bytecode like ... pushLiteral: Halt send: #now ... This means that the meta object is stored in the literal frame of the compiledMethod (the Link itself is just an annotation on the structural element). Marcus

Feb. 24, 2015