- Pharo-dev - lists.pharo.org

Call for Spec Examples

by stepharo

Hi guys I started to group the Spec material in a github pillar project. I should add the dynamic chapter of stephan. Julien is preparing some examples and what would be good is if you have some tips and tricks we could add a chapter to collect them. https://github.com/SquareBracketAssociates/BuildingUIWithSpec Stef

Feb. 28, 2016

Re: [Pharo-dev] wrong method trailer kind

by Tudor Girba

Ok, but still I do not understand how did the methods end up having a problem with the method trailer? And what can we do about it? Doru > On Feb 27, 2016, at 12:32 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-02-27 0:36 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Fri, Feb 26, 2016 at 1:50 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > 17618 Failing test: ReleaseTest>>#testInstalledMethodsWithIncorrectTrailerKind > Interesting bug. > someone who can tell me what exactly is this trailer kind and why it is based > on some "flag" in "method at: method size". > > There's a rich class comment in CompiledMethodTrailer which explains a lot, but let me add a little. > > Ah, yes, thanks, sorry, should have read the class comments first:-) > > > Back in the day the source pointer in methods (the pointer that says which of the two source files and where in the file a method's source is kept) was stored in three bytes added onto the end of a CompiledMethod after its endPC. Then Dan Ingalls added the ability to not have source files at all but just to have named temporary variables. he added a compressed version of the temp names in bytes tacked on at the end of a method, replacing the source pointer. IIRC the difference between a source pointer, no source pointer, or a compressed version of the temp names was all encoded in the last byte. > > > Interesting. > > > Round about 2009 Igor Stasenko did a really nice reimplementation of this scheme where he factored out the encoding tricks into CompiledMethodTrailer, allowing one to generalize the scheme and add new encoding types, for a total of 256 different kinds of trailer. > > Yes I do remember his work on this. > > > (and if you already know all of this, forgive me for trying to teach you to suck eggs) > Anyway this trailer is > > CompiledMethodTrailer >>encodeEmbeddedSourceQCompress > > "data is string with method's source code, encode it using qCompress method" > self encodeUsingQCompress > > CompiledMethodTrailer >>decodeEmbeddedSourceQCompress > > "data is string with method's source code, encoded using qCompress method" > self qDecompress. > > HTH > > Thanks Eliot > > > And why it seems to be wrong for many GT-methods: > > (CompiledMethod allInstances select:[:m | (m at: m size) = 24]) collect:[:k | > k -> k trailer kind] "an Array(String class>>#gtInspectorFourtyTwo->#EmbeddedSourceQCompress OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress GlobalVariable class>>#gtExampleSmalltalk->#EmbeddedSourceQCompress VirtualMachine class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMBrowser class>>#gtExampleBasic->#EmbeddedSourceQCompress RPackageTag class>>#gtExamplePackageTag->#EmbeddedSourceQCompress Object class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMCompositePresentation class>>#gtExampleCompositePresentation->#EmbeddedSourceQCompress LiteralVariable class>>#gtExampleUniqueLiteralVariable->#EmbeddedSourceQCompress GTSpotterRecorderEvent class>>#gtExampleAnySubclass->#EmbeddedSourceQCompress MetacelloAbstractPackageSpec class>>#gtExamplePackageSpec->#EmbeddedSourceQCompress MetacelloProjectReferenceSpec class>>#gtExampleProjectReferenceSpec->#EmbeddedSourceQCompress MetacelloProjectSpec class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloSpec class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloVersion class>>#gtExampleMetacelloVersion->#EmbeddedSourceQCompress GLMPresentation class>>#gtExampleBasic->#EmbeddedSourceQCompress Bag class>>#gtExampleBagWithTenElements->#EmbeddedSourceQCompress Bag class>>#gtExampleBagWithOneElement->#EmbeddedSourceQCompress GTDummyExamplesRecursive class>>#h->#EmbeddedSourceQCompress GLMAlertBrick class>>#gtExample->#EmbeddedSourceQCompress GTDummyExampleProvider>>#a->#EmbeddedSourceQCompress GTDummyExampleProvider>>#b->#EmbeddedSourceQCompress GTDummyExampleWithAssertions>>#a->#EmbeddedSourceQCompress GTDummyExampleWithAssertions>>#b->#EmbeddedSourceQCompress GTDummyExamples class>>#l->#EmbeddedSourceQCompress GTDummyExamples class>>#o->#EmbeddedSourceQCompress GTDummyExamplesInvalid class>>#a:->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#a->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#c->#EmbeddedSourceQCompress GTDummyExamplesPragmas class>>#b->#EmbeddedSourceQCompress GLMCollapsableBrick class>>#gtExample->#EmbeddedSourceQCompress FileReference class>>#gtExampleText->#EmbeddedSourceQCompress GTSpotterStep class>>#gtExampleBasic->#EmbeddedSourceQCompress GTEventAnnouncement class>>#gtExampleEmptyAnnouncement->#EmbeddedSourceQCompress UndefinedObject>>#DoIt->#EmbeddedSourceQCompress UndefinedObject>>#DoIt->#EmbeddedSourceQCompress)" > > _,,,^..^,,,_ > best, Eliot -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

Feb. 27, 2016

Re: [Pharo-dev] wrong method trailer kind

by David T. Lewis

On Sat, Feb 27, 2016 at 12:32:06PM +0100, Nicolai Hess wrote: > 2016-02-27 0:36 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > Round about 2009 Igor Stasenko did a really nice reimplementation of this > > scheme where he factored out the encoding tricks into > > CompiledMethodTrailer, allowing one to generalize the scheme and add new > > encoding types, for a total of 256 different kinds of trailer. > > > > Yes I do remember his work on this. > Igor's enchancement also enabled us to eliminate the size restriction on the changes file. Dave

Feb. 27, 2016

Re: [Pharo-dev] [bloc] when saving bloc and relaunching I get

by Esteban Lorenzano

not spurâ¦ UFFI (or Athens)â¦ that means ExternalAddresses are not correctly freed before quitting :( Esteban > On 26 Feb 2016, at 21:14, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > The same for me... Looks like something spur related. I could not find what causes an issue :( > > On Feb 26, 2016 8:39 PM, "stepharo" <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > <fggjdjce..png>

Feb. 27, 2016

Re: [Pharo-dev] [bloc] why redefining new is not enough?

by stepharo

Can you create a bug entry? we should log the bloc design improvements to not forget them. Le 25/2/16 14:08, Aliaksei Syrel a Ã©crit : > > An we need NullSpace to be default value. > > On Feb 25, 2016 2:06 PM, "Aliaksei Syrel" <alex.syrel(a)gmail.com > <mailto:alex.syrel@gmail.com>> wrote: > > Well, it is not *important* for design what method is redefined > new or basicNew in order to set space. My question is why do we > need at all to set space? It means that element created (not > added) while spaceA is running can not be used in or added to spaceB. > The only reason that I know is a possibility to add global event > listener to space while initializing an element. This must be > fixed by having lazy addition of global event listeners. > > On Feb 25, 2016 9:55 AM, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > BlElement class>>basicNew > "Redefined to set the space of the element" > > ^ super basicNew basicSpace: BlUniverse default runningSpace > > why redefining new is not enough? > > Ok now back to the mooc videos :( > >

Feb. 27, 2016

Re: [Pharo-dev] [bloc] why redefining new is not enough?

by stepharo

Aliaksei can you log this action somewhere? in a bloc bug entry? Stef Le 25/2/16 14:06, Aliaksei Syrel a Ã©crit : > > Well, it is not *important* for design what method is redefined new or > basicNew in order to set space. My question is why do we need at all > to set space? It means that element created (not added) while spaceA > is running can not be used in or added to spaceB. > The only reason that I know is a possibility to add global event > listener to space while initializing an element. This must be fixed by > having lazy addition of global event listeners. > > On Feb 25, 2016 9:55 AM, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > BlElement class>>basicNew > "Redefined to set the space of the element" > > ^ super basicNew basicSpace: BlUniverse default runningSpace > > why redefining new is not enough? > > Ok now back to the mooc videos :( > >

Feb. 27, 2016

Re: [Pharo-dev] wrong method trailer kind

by Nicolai Hess

2016-02-27 0:36 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Fri, Feb 26, 2016 at 1:50 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> 17618 >> <https://pharo.fogbugz.com/f/cases/17618/Failing-test-ReleaseTest-testInstal…> >> Failing test: ReleaseTest>>#testInstalledMethodsWithIncorrectTrailerKind >> Interesting bug. >> someone who can tell me what exactly is this trailer kind and why it is >> based >> on some "flag" in "method at: method size". >> > > There's a rich class comment in CompiledMethodTrailer which explains a > lot, but let me add a little. > Ah, yes, thanks, sorry, should have read the class comments first:-) > > Back in the day the source pointer in methods (the pointer that says which > of the two source files and where in the file a method's source is kept) > was stored in three bytes added onto the end of a CompiledMethod after its > endPC. Then Dan Ingalls added the ability to not have source files at all > but just to have named temporary variables. he added a compressed version > of the temp names in bytes tacked on at the end of a method, replacing the > source pointer. IIRC the difference between a source pointer, no source > pointer, or a compressed version of the temp names was all encoded in the > last byte. > Interesting. > > Round about 2009 Igor Stasenko did a really nice reimplementation of this > scheme where he factored out the encoding tricks into > CompiledMethodTrailer, allowing one to generalize the scheme and add new > encoding types, for a total of 256 different kinds of trailer. > Yes I do remember his work on this. > > (and if you already know all of this, forgive me for trying to teach you > to suck eggs) > Anyway this trailer is > > CompiledMethodTrailer >>encodeEmbeddedSourceQCompress > > "data is string with method's source code, encode it using qCompress > method" > self encodeUsingQCompress > > CompiledMethodTrailer >>decodeEmbeddedSourceQCompress > > "data is string with method's source code, encoded using qCompress method" > self qDecompress. > > HTH > Thanks Eliot > > And why it seems to be wrong for many GT-methods: >> >> (CompiledMethod allInstances select:[:m | (m at: m size) = 24]) >> collect:[:k | >> k -> k trailer kind] "an Array(String >> class>>#gtInspectorFourtyTwo->#EmbeddedSourceQCompress >> OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress >> OSEnvironment>>#getEnv:->#EmbeddedSourceQCompress GlobalVariable >> class>>#gtExampleSmalltalk->#EmbeddedSourceQCompress VirtualMachine >> class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMBrowser >> class>>#gtExampleBasic->#EmbeddedSourceQCompress RPackageTag >> class>>#gtExamplePackageTag->#EmbeddedSourceQCompress Object >> class>>#gtExampleBasic->#EmbeddedSourceQCompress GLMCompositePresentation >> class>>#gtExampleCompositePresentation->#EmbeddedSourceQCompress >> LiteralVariable >> class>>#gtExampleUniqueLiteralVariable->#EmbeddedSourceQCompress >> GTSpotterRecorderEvent >> class>>#gtExampleAnySubclass->#EmbeddedSourceQCompress >> MetacelloAbstractPackageSpec >> class>>#gtExamplePackageSpec->#EmbeddedSourceQCompress >> MetacelloProjectReferenceSpec >> class>>#gtExampleProjectReferenceSpec->#EmbeddedSourceQCompress >> MetacelloProjectSpec >> class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloSpec >> class>>#gtExampleMetacelloSpec->#EmbeddedSourceQCompress MetacelloVersion >> class>>#gtExampleMetacelloVersion->#EmbeddedSourceQCompress GLMPresentation >> class>>#gtExampleBasic->#EmbeddedSourceQCompress Bag >> class>>#gtExampleBagWithTenElements->#EmbeddedSourceQCompress Bag >> class>>#gtExampleBagWithOneElement->#EmbeddedSourceQCompress >> GTDummyExamplesRecursive class>>#h->#EmbeddedSourceQCompress GLMAlertBrick >> class>>#gtExample->#EmbeddedSourceQCompress >> GTDummyExampleProvider>>#a->#EmbeddedSourceQCompress >> GTDummyExampleProvider>>#b->#EmbeddedSourceQCompress >> GTDummyExampleWithAssertions>>#a->#EmbeddedSourceQCompress >> GTDummyExampleWithAssertions>>#b->#EmbeddedSourceQCompress GTDummyExamples >> class>>#l->#EmbeddedSourceQCompress GTDummyExamples >> class>>#o->#EmbeddedSourceQCompress GTDummyExamplesInvalid >> class>>#a:->#EmbeddedSourceQCompress GTDummyExamplesPragmas >> class>>#a->#EmbeddedSourceQCompress GTDummyExamplesPragmas >> class>>#c->#EmbeddedSourceQCompress GTDummyExamplesPragmas >> class>>#b->#EmbeddedSourceQCompress GLMCollapsableBrick >> class>>#gtExample->#EmbeddedSourceQCompress FileReference >> class>>#gtExampleText->#EmbeddedSourceQCompress GTSpotterStep >> class>>#gtExampleBasic->#EmbeddedSourceQCompress GTEventAnnouncement >> class>>#gtExampleEmptyAnnouncement->#EmbeddedSourceQCompress >> UndefinedObject>>#DoIt->#EmbeddedSourceQCompress >> UndefinedObject>>#DoIt->#EmbeddedSourceQCompress)" >> > > _,,,^..^,,,_ > best, Eliot >

Feb. 27, 2016

Re: [Pharo-dev] [ANN] OSUnix and OSLinuxUbuntu on new UFFI

by stepharo

Thanks!!! Stef Le 17/2/16 21:24, Torsten Bergmann a Ã©crit : > These two projects (who were based on NativeBoost in Pharo 4) are now updated > to new UFFI in Pharo 5 which means they are loadable in recent Pharo 5 image and > all tests pass. > > So if you are working on Linux/Unix you might wan to check them out in latest > Pharo 5 by loading them from Catalog browser. > > A BIG THANKS to Esteban for helping me in the conversion and updating > the new Unified FFI (UFFI) according to the issues that were found during > the conversion. > > More is in the pipe ... step by step it goes! > > Bye > T. > > > > > > > > > >

Feb. 27, 2016

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

by stepharo

I will move the method and add a delegation and it should work for handMorph too. <hypothesis> Stefan a case is that we may have a BlElement whose drawing is done by the hardware <hypothesis> Le 26/2/16 10:14, Tudor Girba a Ã©crit : > Exactly. > > This is a sensible point. We need to learn a bit more from concrete implementations on top of Bloc before we decide. > > @Alex: Could you add a flag in the implementation? > > Doru > > p.s. I really love this kind of discussion OK we will continue to have them. I hope to get some time to start to write some tests based on the method comments in BlElement and enrich the class comments as well. Stef > > >> On Feb 26, 2016, at 9:33 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >> >> >> From: Alain Plantec <alain.plantec(a)yahoo.com> >> Subject: Re: [Pharo-dev] [bloc] feature envy -> move method close to data? >> Date: February 26, 2016 at 9:32:16 AM GMT+1 >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> >> Hello, >> I think the problem is that, as far as we know now, >> it is not desirable that new subclasses of BlShape are created >> in case the drawing has to be redefined for a particular BlElements. >> For now, we flag it as a sensible point. >> We will fix or at least take a decision later. >> We need a layer as Brick on top of Bloc to see how it goes. >> Alain >> >> >> >>> On 25 Feb 2016, at 23:01, stepharo <stepharo(a)free.fr> wrote: >>> >>> Sorry but I do not buy your argument. >>> BlElement is in charge and it delegates it to BlShape. >>> This is a quite common pattern and this is more logical that the object responsible for the shape drawing draw it in fact. >>> It was like that in Bloc before so I do not see why this is not possible now. >>> >>> Le 25/2/16 13:37, Aliaksei Syrel a Ã©crit : >>>> All arbitrary shapes are being drawing in the same way and it is enough to have only one method. Allowing shape to render itself would lead to misunderstanding: bloc user would have to look into two places (element and shape) to find out where drawing actually happens. >>>> >>>> On Feb 25, 2016 12:56 PM, "stepharo" <stepharo(a)free.fr> wrote: >>>> To me this is pre optimisation >>>> >>>> I do not see why we cannot do >>>> >>>> BlElement>>drawOnAthensCanvas: aCanvas >>>> >>>> self shape drawOnAthensCanvas: aCanvas with: self >>>> >>>> so far only localBounds from BlElement are used. >>>> >>>> And to me this is really strange to have an object responsible for the drawing not doing it. >>>> It blurs the responsibility. >>>> >>>> Stef >>>> >>>> Le 25/2/16 10:39, Tudor Girba a Ã©crit : >>>> Hi, >>>> >>>> Good question. >>>> >>>> The reason we want to have the morph be responsible because subclasses might decide to draw in a different way regardless of the shape being used. This gives us the maximum freedom for more specific blocs. Still, this is something to experiment with once we have more complicated examples built with Bloc. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On Feb 25, 2016, at 9:56 AM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Hi Blockers >>>> >>>> I do not really understand why drawOnAthensCanvas: is not defined on BlShape >>>> (especially when we see how many self space are defined in this method. >>>> And this is one of the few things I thought I understood from bloc (grouping the rendering in a separate object). >>>> >>>> >>>> drawOnAthensCanvas: aCanvas >>>> "Actually render receiver on aCanvas in local bounds. >>>> Override to customize. >>>> aCanvas is an instance of AthensCanvas >>>> aCanvas must not be nil" >>>> >>>> | pathTransform | >>>> pathTransform := aCanvas pathTransform. >>>> "First we fill" >>>> pathTransform >>>> restoreAfter: >>>> [ | path fillExtent fillTranslation | >>>> "We fill inside natural element's bounds" >>>> fillExtent := self shape path fillExtentFor: self shape inBounds: self localBounds. >>>> path := self shape path pathOn: aCanvas forExtent: fillExtent. >>>> "Translate fill if needed" >>>> fillTranslation := self shape path >>>> fillTranslationFor: self shape >>>> inBounds: self localBounds. >>>> pathTransform translateBy: fillTranslation. >>>> aCanvas >>>> setPaint: self shape fillPaint; >>>> drawShape: path ]. >>>> pathTransform >>>> restoreAfter: >>>> [ | path strokeExtent strokeTranslation | >>>> "We stroke inside natural element's bounds" >>>> strokeExtent := self shape path strokeExtentFor: self shape inBounds: self localBounds. >>>> path := self shape path pathOn: aCanvas forExtent: strokeExtent. >>>> "Translate stroke if needed" >>>> strokeTranslation := self shape path >>>> strokeTranslationFor: self shape >>>> inBounds: self localBounds. >>>> pathTransform translateBy: strokeTranslation. >>>> aCanvas >>>> setPaint: self shape strokePaint; >>>> drawShape: path ] >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Sometimes the best solution is not the best solution." >>>> >>>> >>>> >>>> >>>> >> >> > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of reality." > > >

Feb. 27, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 335349: 50617

by stepharo

Thanks a lot for the menu I will be able to produce a videos before leaving to teahc to annecy :) Le 27/2/16 09:57, GitHub a Ã©crit : > 50617 > 17283 strange monticello repo in 507:http://www.squeaksource.com/Pharo/ > https://pharo.fogbugz.com/f/cases/17283 > > 16436 add RBSelfSuperSentNotImplementedRule > https://pharo.fogbugz.com/f/cases/16436 > > 17622 Failing test: MethodPragmaTest>>#testPrimitiveNamedErrorCode1 > https://pharo.fogbugz.com/f/cases/17622 > > 17714 Clean old startup mechanism - part 2 > https://pharo.fogbugz.com/f/cases/17714 > > 17691 ProfStef menu are broken > https://pharo.fogbugz.com/f/cases/17691

Feb. 27, 2016