November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Unexpected block variable change of value

by Max Leske

Not sure if itâs related to your issue but Iâve been seeing swapped temporary variables in the debugger. The value used for execution is correct but in the view two variables will have the value of the other. Are you sure that the value *effectively* changes or could it be a visualization problem? Max On 11.11.2013, at 17:29, btc(a)openinworld.com wrote: > I'm not sure if I'm missing something, but there seems some strange behavior that I don't understand. The value of a block variable changes when stepping over a method that acts on that variable. I encountered this in Spec, but that seems co-incidental to the behaviour. > SETUP > 1. The attached "My-Spec-Tutorial-BenComan.1.mcz" (i.e. Bahman's tutorial) was loaded into build #30564. > > 2. A breakpoint was inserted after the first "e generateArguments" in... > SpecRowLayout>>privateAsArray > | result shouldCheckSplitters | > result := OrderedCollection new. > shouldCheckSplitters := false. (self commands reject: [:e | e isSplitter ]) do: [:e | > ...lots..hidden.for..conciseness.... > e generateArguments. > self haltOnce. "<------------------" > e asSpecElements do: [:el | > result add: el ]]. > > 3. The following was evaluated... > Halt enableHaltOnce. > MyFirstWindow new openWithSpec: #defaultSpec. > > > OBSERVATION > 1. When the debugger opened at the breakpoint > e = a SpecLayoutAdd > > 2. But after stepping over #asSpecElements > e = an OrderedCollection() > > So how did the value of 'e' change? > > Where... > SpecLayoutAdd(SpecLayoutSend)>>asSpecElements > ^ {self selector.}, self arguments > > SpecLayoutAdd(SpecLayoutSend)>>selector > ^ selector > > SpecLayoutAdd(SpecLayoutSend)>>arguments > ^ arguments > > > This was on Windows 7. Since files.pharo.org is offline, I wasn't able to try a newer VM. My current was... > > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > > Win32 built on Mar 13 2013 18:49:42 Compiler: 4.6.2 > VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > > cheers -ben > > <My-Spec-Tutorial-BenComan.1.mcz>

Nov. 11, 2013

Re: [Pharo-dev] Large difference in image size when loading configuration

by phil＠highoctane.be

I then signalled the semaphores (Alt-S in the process browser and the processes went away). Size of SHRange is now: SHRange allInstances size. 217381 (After a couple GCs). Are these things created when one views methods in the browser ? Phil On Mon, Nov 11, 2013 at 6:09 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > I had a look at the process browser and found this strange set of > processes with semaphores and style in background. > How comes? > There is no browser open even. > > See screenshot attached. > > Phil > > > > On Mon, Nov 11, 2013 at 5:10 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> Yeah, that's a tad weird. >> >> I am quite concerned about that image ballooning effect. >> >> I've got a dev image and it is now 185.515.948 >> >> I did the flush thing >> >> MCFileBasedRepository flushAllCaches. >> 3 timesRepeat: [Smalltalk garbageCollect]. >> >> and now, it is 158.740.484 >> >> SpaceTally new printSpaceAnalysis >> >> shows: >> >> Class code space # instances >> inst space percent inst average size >> Array 3712 817192 >> 31395576 19.30 38.42 >> Float 13047 1313593 >> 15763116 9.70 12.00 >> ByteString 2785 378125 >> 13078821 8.00 34.59 >> MorphExtension 3097 157557 >> 10713876 6.60 68.00 >> Bitmap 3653 1975 >> 10198648 6.30 5163.87 >> TextMethodLink 419 392396 >> 9417504 5.80 24.00 >> Point 7105 711444 >> 8537328 5.30 12.00 >> CompiledMethod 22467 82802 >> 5215856 3.20 62.99 >> SHRange 1919 217316 >> 4346320 2.70 20.00 >> Rectangle 8795 325385 >> 3904620 2.40 12.00 >> TableLayoutProperties 1169 49629 >> 3573288 2.20 72.00 >> Semaphore 949 149195 >> 2983900 1.80 20.00 >> >> A ton of MorphExtensions (which is a know problem). >> >> but also quite some TextMethodLinks, which I do not understand. >> SHRange, from styling things I guess, lots of remnants. >> >> And quite a bunch of Semaphores, too much I think. >> >> Tons of Arrays and floats. I do a lot of NeoCSV loads in the image. >> >> >> Phil >> >> >> >> >> >> >> On Mon, Nov 11, 2013 at 4:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >> >>> >>> On 11 Nov 2013, at 15:51, phil(a)highoctane.be wrote: >>> >>> > Image size goes back to: >>> > >>> > 29.068.612 >>> > >>> > Looks like all package contents are cached in the imageâ¦ >>> >>> But by a factor 3 ?? >>> >>> > Phil >>> > >>> > >>> > >>> > On Mon, Nov 11, 2013 at 1:32 PM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> > Phil, what happens if you evaluate (and save after) to the big image: >>> > >>> > MCFileBasedRepository flushAllCaches. >>> > 3 timesRepeat: [Smalltalk garbageCollect]. >>> > >>> > >>> > On Mon, Nov 11, 2013 at 8:30 AM, phil(a)highoctane.be < >>> phil(a)highoctane.be> wrote: >>> > [User.Techlab] â du -hs package-cache >>> > 5.3M package-cache >>> > >>> > Phil >>> > >>> > On Mon, Nov 11, 2013 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> > What is the total size of the package-cache, like du -hs ? >>> > Could it be the same size of the difference in image size ? >>> > That would mean that the contents of the packages themselves is cached >>> in the image... >>> > >>> > On 11 Nov 2013, at 10:39, phil(a)highoctane.be wrote: >>> > >>> > > I am experiencing the following while loading my configuration. >>> > > >>> > > REPO=http://www.smalltalkhub.com/mc/philippeback/HOWebStack/main >>> > > ./pharo Pharo.image config $REPO ConfigurationOfHOWebStack >>> --install=0.4 >>> > > >>> > > Everything loads fine. >>> > > >>> > > But: >>> > > >>> > > with a package-cache/ empty, the final image is: 44.452.060 with a >>> changes file of: 10.831.877 >>> > > >>> > > with a primed package-cache (meaning, letting the mczs in place and >>> starting with a fresh image), the final image is: 29.480.912 with a changes >>> file of: 10.830.899 >>> > > >>> > > That's quite a huge difference. >>> > > >>> > > I tried again to be sure (fresh image and empty package-cache, then >>> fresh image only) and, weirdly enough, even if the difference in size was >>> the same, the sizes themselves weren't.the same... >>> > > >>> > > 44.446.152 - 10.830.899 >>> > > 29.986.284 - 10.831.543 >>> > > >>> > > Maybe that's due to a GC occurring differently between the two. >>> > > >>> > > But this gives the impression that one cannot load a base image, >>> apply a configuration, and end up with the same image twice. Weird. >>> > > >>> > > Why is this difference so large in the first place ? >>> > > >>> > > Phil >>> > > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > Mariano >>> > http://marianopeck.wordpress.com >>> > >>> >>> >>> >> >

Nov. 11, 2013

Re: [Pharo-dev] Large difference in image size when loading configuration

by phil＠highoctane.be

I had a look at the process browser and found this strange set of processes with semaphores and style in background. How comes? There is no browser open even. See screenshot attached. Phil On Mon, Nov 11, 2013 at 5:10 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Yeah, that's a tad weird. > > I am quite concerned about that image ballooning effect. > > I've got a dev image and it is now 185.515.948 > > I did the flush thing > > MCFileBasedRepository flushAllCaches. > 3 timesRepeat: [Smalltalk garbageCollect]. > > and now, it is 158.740.484 > > SpaceTally new printSpaceAnalysis > > shows: > > Class code space # instances > inst space percent inst average size > Array 3712 817192 > 31395576 19.30 38.42 > Float 13047 1313593 > 15763116 9.70 12.00 > ByteString 2785 378125 > 13078821 8.00 34.59 > MorphExtension 3097 157557 > 10713876 6.60 68.00 > Bitmap 3653 1975 > 10198648 6.30 5163.87 > TextMethodLink 419 392396 > 9417504 5.80 24.00 > Point 7105 711444 > 8537328 5.30 12.00 > CompiledMethod 22467 82802 > 5215856 3.20 62.99 > SHRange 1919 217316 > 4346320 2.70 20.00 > Rectangle 8795 325385 > 3904620 2.40 12.00 > TableLayoutProperties 1169 49629 > 3573288 2.20 72.00 > Semaphore 949 149195 > 2983900 1.80 20.00 > > A ton of MorphExtensions (which is a know problem). > > but also quite some TextMethodLinks, which I do not understand. > SHRange, from styling things I guess, lots of remnants. > > And quite a bunch of Semaphores, too much I think. > > Tons of Arrays and floats. I do a lot of NeoCSV loads in the image. > > > Phil > > > > > > > On Mon, Nov 11, 2013 at 4:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> >> On 11 Nov 2013, at 15:51, phil(a)highoctane.be wrote: >> >> > Image size goes back to: >> > >> > 29.068.612 >> > >> > Looks like all package contents are cached in the imageâ¦ >> >> But by a factor 3 ?? >> >> > Phil >> > >> > >> > >> > On Mon, Nov 11, 2013 at 1:32 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> > Phil, what happens if you evaluate (and save after) to the big image: >> > >> > MCFileBasedRepository flushAllCaches. >> > 3 timesRepeat: [Smalltalk garbageCollect]. >> > >> > >> > On Mon, Nov 11, 2013 at 8:30 AM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> > [User.Techlab] â du -hs package-cache >> > 5.3M package-cache >> > >> > Phil >> > >> > On Mon, Nov 11, 2013 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > What is the total size of the package-cache, like du -hs ? >> > Could it be the same size of the difference in image size ? >> > That would mean that the contents of the packages themselves is cached >> in the image... >> > >> > On 11 Nov 2013, at 10:39, phil(a)highoctane.be wrote: >> > >> > > I am experiencing the following while loading my configuration. >> > > >> > > REPO=http://www.smalltalkhub.com/mc/philippeback/HOWebStack/main >> > > ./pharo Pharo.image config $REPO ConfigurationOfHOWebStack >> --install=0.4 >> > > >> > > Everything loads fine. >> > > >> > > But: >> > > >> > > with a package-cache/ empty, the final image is: 44.452.060 with a >> changes file of: 10.831.877 >> > > >> > > with a primed package-cache (meaning, letting the mczs in place and >> starting with a fresh image), the final image is: 29.480.912 with a changes >> file of: 10.830.899 >> > > >> > > That's quite a huge difference. >> > > >> > > I tried again to be sure (fresh image and empty package-cache, then >> fresh image only) and, weirdly enough, even if the difference in size was >> the same, the sizes themselves weren't.the same... >> > > >> > > 44.446.152 - 10.830.899 >> > > 29.986.284 - 10.831.543 >> > > >> > > Maybe that's due to a GC occurring differently between the two. >> > > >> > > But this gives the impression that one cannot load a base image, >> apply a configuration, and end up with the same image twice. Weird. >> > > >> > > Why is this difference so large in the first place ? >> > > >> > > Phil >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >> >> >

Nov. 11, 2013

Unexpected block variable change of value

by btc＠openinworld.com

I'm not sure if I'm missing something, but there seems some strange behavior that I don't understand. The value of a block variable changes when stepping over a method that acts on that variable. I encountered this in Spec, but that seems co-incidental to the behaviour. SETUP 1. The attached "My-Spec-Tutorial-BenComan.1.mcz" (i.e. Bahman's tutorial) was loaded into build #30564. 2. A breakpoint was inserted after the first "e generateArguments" in... SpecRowLayout>>privateAsArray | result shouldCheckSplitters | result := OrderedCollection new. shouldCheckSplitters := false. (self commands reject: [:e | e isSplitter ]) do: [:e | ...lots..hidden.for..conciseness.... e generateArguments. self haltOnce. "<------------------" e asSpecElements do: [:el | result add: el ]]. 3. The following was evaluated... Halt enableHaltOnce. MyFirstWindow new openWithSpec: #defaultSpec. OBSERVATION 1. When the debugger opened at the breakpoint e = a SpecLayoutAdd 2. But after stepping over #asSpecElements e = an OrderedCollection() So how did the value of 'e' change? Where... SpecLayoutAdd(SpecLayoutSend)>>asSpecElements ^ {self selector.}, self arguments SpecLayoutAdd(SpecLayoutSend)>>selector ^ selector SpecLayoutAdd(SpecLayoutSend)>>arguments ^ arguments This was on Windows 7. Since files.pharo.org is offline, I wasn't able to try a newer VM. My current was... NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 Win32 built on Mar 13 2013 18:49:42 Compiler: 4.6.2 VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 cheers -ben

Nov. 11, 2013

Re: [Pharo-dev] Large difference in image size when loading configuration

by phil＠highoctane.be

Yeah, that's a tad weird. I am quite concerned about that image ballooning effect. I've got a dev image and it is now 185.515.948 I did the flush thing MCFileBasedRepository flushAllCaches. 3 timesRepeat: [Smalltalk garbageCollect]. and now, it is 158.740.484 SpaceTally new printSpaceAnalysis shows: Class code space # instances inst space percent inst average size Array 3712 817192 31395576 19.30 38.42 Float 13047 1313593 15763116 9.70 12.00 ByteString 2785 378125 13078821 8.00 34.59 MorphExtension 3097 157557 10713876 6.60 68.00 Bitmap 3653 1975 10198648 6.30 5163.87 TextMethodLink 419 392396 9417504 5.80 24.00 Point 7105 711444 8537328 5.30 12.00 CompiledMethod 22467 82802 5215856 3.20 62.99 SHRange 1919 217316 4346320 2.70 20.00 Rectangle 8795 325385 3904620 2.40 12.00 TableLayoutProperties 1169 49629 3573288 2.20 72.00 Semaphore 949 149195 2983900 1.80 20.00 A ton of MorphExtensions (which is a know problem). but also quite some TextMethodLinks, which I do not understand. SHRange, from styling things I guess, lots of remnants. And quite a bunch of Semaphores, too much I think. Tons of Arrays and floats. I do a lot of NeoCSV loads in the image. Phil On Mon, Nov 11, 2013 at 4:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 11 Nov 2013, at 15:51, phil(a)highoctane.be wrote: > > > Image size goes back to: > > > > 29.068.612 > > > > Looks like all package contents are cached in the imageâ¦ > > But by a factor 3 ?? > > > Phil > > > > > > > > On Mon, Nov 11, 2013 at 1:32 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > Phil, what happens if you evaluate (and save after) to the big image: > > > > MCFileBasedRepository flushAllCaches. > > 3 timesRepeat: [Smalltalk garbageCollect]. > > > > > > On Mon, Nov 11, 2013 at 8:30 AM, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > > [User.Techlab] â du -hs package-cache > > 5.3M package-cache > > > > Phil > > > > On Mon, Nov 11, 2013 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > What is the total size of the package-cache, like du -hs ? > > Could it be the same size of the difference in image size ? > > That would mean that the contents of the packages themselves is cached > in the image... > > > > On 11 Nov 2013, at 10:39, phil(a)highoctane.be wrote: > > > > > I am experiencing the following while loading my configuration. > > > > > > REPO=http://www.smalltalkhub.com/mc/philippeback/HOWebStack/main > > > ./pharo Pharo.image config $REPO ConfigurationOfHOWebStack > --install=0.4 > > > > > > Everything loads fine. > > > > > > But: > > > > > > with a package-cache/ empty, the final image is: 44.452.060 with a > changes file of: 10.831.877 > > > > > > with a primed package-cache (meaning, letting the mczs in place and > starting with a fresh image), the final image is: 29.480.912 with a changes > file of: 10.830.899 > > > > > > That's quite a huge difference. > > > > > > I tried again to be sure (fresh image and empty package-cache, then > fresh image only) and, weirdly enough, even if the difference in size was > the same, the sizes themselves weren't.the same... > > > > > > 44.446.152 - 10.830.899 > > > 29.986.284 - 10.831.543 > > > > > > Maybe that's due to a GC occurring differently between the two. > > > > > > But this gives the impression that one cannot load a base image, apply > a configuration, and end up with the same image twice. Weird. > > > > > > Why is this difference so large in the first place ? > > > > > > Phil > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

Nov. 11, 2013

Re: [Pharo-dev] Large difference in image size when loading configuration

by Sven Van Caekenberghe

On 11 Nov 2013, at 15:51, phil(a)highoctane.be wrote: > Image size goes back to: > > 29.068.612 > > Looks like all package contents are cached in the imageâ¦ But by a factor 3 ?? > Phil > > > > On Mon, Nov 11, 2013 at 1:32 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Phil, what happens if you evaluate (and save after) to the big image: > > MCFileBasedRepository flushAllCaches. > 3 timesRepeat: [Smalltalk garbageCollect]. > > > On Mon, Nov 11, 2013 at 8:30 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > [User.Techlab] â du -hs package-cache > 5.3M package-cache > > Phil > > On Mon, Nov 11, 2013 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > What is the total size of the package-cache, like du -hs ? > Could it be the same size of the difference in image size ? > That would mean that the contents of the packages themselves is cached in the image... > > On 11 Nov 2013, at 10:39, phil(a)highoctane.be wrote: > > > I am experiencing the following while loading my configuration. > > > > REPO=http://www.smalltalkhub.com/mc/philippeback/HOWebStack/main > > ./pharo Pharo.image config $REPO ConfigurationOfHOWebStack --install=0.4 > > > > Everything loads fine. > > > > But: > > > > with a package-cache/ empty, the final image is: 44.452.060 with a changes file of: 10.831.877 > > > > with a primed package-cache (meaning, letting the mczs in place and starting with a fresh image), the final image is: 29.480.912 with a changes file of: 10.830.899 > > > > That's quite a huge difference. > > > > I tried again to be sure (fresh image and empty package-cache, then fresh image only) and, weirdly enough, even if the difference in size was the same, the sizes themselves weren't.the same... > > > > 44.446.152 - 10.830.899 > > 29.986.284 - 10.831.543 > > > > Maybe that's due to a GC occurring differently between the two. > > > > But this gives the impression that one cannot load a base image, apply a configuration, and end up with the same image twice. Weird. > > > > Why is this difference so large in the first place ? > > > > Phil > > > > > > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 11, 2013

Re: [Pharo-dev] Large difference in image size when loading configuration

by phil＠highoctane.be

Image size goes back to: 29.068.612 Looks like all package contents are cached in the image... Phil On Mon, Nov 11, 2013 at 1:32 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Phil, what happens if you evaluate (and save after) to the big image: > > MCFileBasedRepository flushAllCaches. > 3 timesRepeat: [Smalltalk garbageCollect]. > > > On Mon, Nov 11, 2013 at 8:30 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> [User.Techlab] â du -hs package-cache >> 5.3M package-cache >> >> Phil >> >> On Mon, Nov 11, 2013 at 11:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >> >>> What is the total size of the package-cache, like du -hs ? >>> Could it be the same size of the difference in image size ? >>> That would mean that the contents of the packages themselves is cached >>> in the image... >>> >>> On 11 Nov 2013, at 10:39, phil(a)highoctane.be wrote: >>> >>> > I am experiencing the following while loading my configuration. >>> > >>> > REPO=http://www.smalltalkhub.com/mc/philippeback/HOWebStack/main >>> > ./pharo Pharo.image config $REPO ConfigurationOfHOWebStack >>> --install=0.4 >>> > >>> > Everything loads fine. >>> > >>> > But: >>> > >>> > with a package-cache/ empty, the final image is: 44.452.060 with a >>> changes file of: 10.831.877 >>> > >>> > with a primed package-cache (meaning, letting the mczs in place and >>> starting with a fresh image), the final image is: 29.480.912 with a changes >>> file of: 10.830.899 >>> > >>> > That's quite a huge difference. >>> > >>> > I tried again to be sure (fresh image and empty package-cache, then >>> fresh image only) and, weirdly enough, even if the difference in size was >>> the same, the sizes themselves weren't.the same... >>> > >>> > 44.446.152 - 10.830.899 >>> > 29.986.284 - 10.831.543 >>> > >>> > Maybe that's due to a GC occurring differently between the two. >>> > >>> > But this gives the impression that one cannot load a base image, apply >>> a configuration, and end up with the same image twice. Weird. >>> > >>> > Why is this difference so large in the first place ? >>> > >>> > Phil >>> > >>> > >>> > >>> > >>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Nov. 11, 2013

Re: [Pharo-dev] Questions about Athens

by kilon alios

sorry previous stack was for slightly diffirent code this is the correct one UndefinedObject(Object)>>doesNotUnderstand: #drawDuring: Hyperion>>render Hyperion>>drawOn: FormCanvas(Canvas)>>draw: FormCanvas(Canvas)>>drawMorph: Hyperion(Morph)>>fullDrawOn: in Block: [ ... FormCanvas>>roundCornersOf:in:during: FormCanvas(Canvas)>>roundCornersOf:during: Hyperion(Morph)>>fullDrawOn: in Block: [ ... BlockClosure>>on:do: Hyperion(Morph)>>fullDrawOn: FormCanvas(Canvas)>>fullDraw: FormCanvas(Canvas)>>fullDrawMorph: SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :m | canvas fullDrawMorph: m ] Array(SequenceableCollection)>>reverseDo: SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :canvas | submorphs reverseDo: [ :m | canvas ful...etc... FormCanvas>>clipBy:during: SystemWindow(Morph)>>drawSubmorphsOn: SystemWindow(Morph)>>fullDrawOn: in Block: [ ... FormCanvas>>roundCornersOf:in:during: FormCanvas(Canvas)>>roundCornersOf:during: SystemWindow(Morph)>>fullDrawOn: in Block: [ ... BlockClosure>>on:do: SystemWindow(Morph)>>fullDrawOn: FormCanvas(Canvas)>>fullDraw: FormCanvas(Canvas)>>fullDrawMorph: WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: drawWorld: aWorld submorphs: submorphs invalidArea...etc... Rectangle>>allAreasOutsideList:startingAt:do: Rectangle>>allAreasOutsideList:do: WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: [ :dirtyRect | ... On Mon, Nov 11, 2013 at 4:43 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Igor I am trying your session code but it does not work for me. I still > get the red box of doom. This is the method > > checkSession > > session == Smalltalk session ifFalse: [ > surface := surface := AthensCairoSurface extent: self extent. . > session := Smalltalk session. > ] > > and This is my full stack > > NBFFICallout class>>signalError: > NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: > NBFFICalloutAPI>>function:module: > AthensCairoSurface class(Object)>>nbCall: > AthensCairoSurface class>>primImage:width:height: > NBFFICallout class(NBNativeCodeGen class)>>retrySend: > AthensCairoSurface class>>extent:format: > AthensCairoSurface class>>extent: > Hyperion>>mouseDown: > Hyperion(Morph)>>handleMouseDown: > MouseButtonEvent>>sentTo: > Hyperion(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchMouseDown:with: > MorphicEventDispatcher>>dispatchEvent:with: > Hyperion(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchMouseDown:with: > MorphicEventDispatcher>>dispatchEvent:with: > SystemWindow(Morph)>>processEvent:using: > SystemWindow(Morph)>>processEvent: > SystemWindow>>mouseDown: in Block: [ ... > BlockClosure>>ensure: > SystemWindow>>mouseDown: > SystemWindow(Morph)>>handleMouseDown: > MouseButtonEvent>>sentTo: > SystemWindow(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchMouseDown:with: > MorphicEventDispatcher>>dispatchEvent:with: > SystemWindow(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchMouseDown:with: > MorphicEventDispatcher>>dispatchEvent:with: > > > > On Sat, Nov 2, 2013 at 12:01 PM, kilon alios <kilon.alios(a)gmail.com>wrote: > >> and here is the strange MNU that I was talking about earlier >> >> here is the full stack >> >> Hyperion(Object)>>doesNotUnderstand: #passenger >> PackageTreeModel>>acceptDroppingMorph:event:inMorph: >> MorphTreeMorph>>acceptDroppingMorph:event: >> MorphTreeMorph(Morph)>>handleDropMorph: >> DropEvent>>sentTo: >> MorphTreeMorph(Morph)>>handleEvent: >> MorphicEventDispatcher>>dispatchDropEvent:with: >> MorphicEventDispatcher>>dispatchEvent:with: >> MorphTreeMorph(Morph)>>processEvent:using: >> MorphicEventDispatcher>>dispatchDropEvent:with: >> MorphicEventDispatcher>>dispatchEvent:with: >> PanelMorph(Morph)>>processEvent:using: >> MorphicEventDispatcher>>dispatchDropEvent:with: >> MorphicEventDispatcher>>dispatchEvent:with: >> NautilusWindow(Morph)>>processEvent:using: >> MorphicEventDispatcher>>dispatchDropEvent:with: >> MorphicEventDispatcher>>dispatchEvent:with: >> WorldMorph(Morph)>>processEvent:using: >> WorldMorph(Morph)>>processEvent: >> HandMorph>>sendEvent:focus:clear: >> HandMorph>>sendEvent:focus: >> HandMorph>>dropMorph:event: >> HandMorph>>dropMorphs: in Block: [ :m | ... >> Array(SequenceableCollection)>>reverseDo: >> HandMorph(Morph)>>submorphsReverseDo: >> HandMorph>>dropMorphs: >> HandMorph>>handleEvent: >> HandMorph>>processEvents >> WorldState>>doOneCycleNowFor: in Block: [ :h | ... >> Array(SequenceableCollection)>>do: >> >> >> This one happens when I bring up the halos and try to move the morph >> around.Morphs gets deleted because of MNU. Note it does not happen with >> just my Class (Hyperion) it happens with any morph using Athens. >> >> Hyperion in this case is a partial copy of the AthensDemoMorph. As always >> I am using Pharo 3 (Latest update: #30534) . >> >> >> On Fri, Nov 1, 2013 at 7:14 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> >>> On 1 November 2013 14:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: >>> >>>> Ok now the explanation :) >>>> Spec changed recently in 30. >>>> >>>> >>> then i need help on that.. what is needs to be changed. >>> btw, i noticed that monticello configuration browser also having >>> problems with spec. >>> >>> >>>> Stef >>>> >>>> >>>> Again I am following Igor instructions, loaded Athens-Tutorial from >>>> smalltalkhub , opened a new workspace, AthensTutorial open. I am using a >>>> pharo 3 that downloaded just yesterday. (Pharo3.0 Latest update: #30532) >>>> >>>> here is the full stack >>>> >>>> AthensViewMorph(Object)>>doesNotUnderstand: #layout: >>>> SpecInterpreter>>actionToPerformWithSelector:arguments: >>>> SpecInterpreter>>performNextSelectorAndIncrementIndex >>>> SpecInterpreter>>interpretASpec:selector: >>>> SpecInterpreter>>interpretASpec:model:selector: >>>> SpecInterpreter class>>private_interpretASpec:model:selector: >>>> SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ :each >>>> | self class private_interpretASpec: each ...etc... >>>> Array(SequenceableCollection)>>collect: >>>> SpecInterpreter>>performNextSelectorAndIncrementIndex >>>> SpecInterpreter>>interpretASpec:selector: >>>> SpecInterpreter>>interpretASpec:model:selector: >>>> SpecInterpreter class>>private_interpretASpec:model:selector: >>>> SpecInterpreter class>>interpretASpec:model:selector: in Block: [ >>>> result := self private_interpretASpec: aPresente...etc... >>>> BlockClosure>>ensure: >>>> SpecInterpreter class>>interpretASpec:model:selector: >>>> SpecInterpreter class>>interpretASpec:model: >>>> AthensTutorial(ComposableModel)>>buildWithSpecLayout: >>>> MorphicWindowAdapter>>addModelIn:withSpecLayout: >>>> MorphicWindowAdapter(AbstractAdapter)>>update:with: >>>> WindowModel(Object)>>changed:with: in Block: [ :aDependent | aDependent >>>> update: anAspect with: ...etc... >>>> DependentsArray>>do: >>>> WindowModel(Object)>>changed:with: >>>> WindowModel>>addModelIn:withSpecLayout: >>>> WindowModel>>buildWithSpecLayout: >>>> WindowModel>>openWithSpecLayout: >>>> AthensTutorial(ComposableModel)>>openWithSpecLayout: >>>> AthensTutorial(ComposableModel)>>openWithSpec: >>>> AthensTutorial(ComposableModel)>>openWithSpec >>>> AthensTutorial class>>open >>>> UndefinedObject>>DoIt >>>> >>>> Is that enough ? >>>> >>>> I am also getting another error from Athens from time to time, I will >>>> have to remember to capture it cause it appears randomly. >>>> >>>> >>>> On Fri, Nov 1, 2013 at 1:42 PM, StÃ©phane Ducasse < >>>> stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> >>>>> On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios(a)gmail.com> >>>>> wrote: >>>>> >>>>> Igor I got Athens-Tutorial but it gives me a MNU: >>>>> AthensViewMorph>>layout: >>>>> >>>>> >>>>> strange tell us more. >>>>> You know >>>>> which image >>>>> â¦. >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Nov 1, 2013 at 10:23 AM, kilon alios <kilon.alios(a)gmail.com>wrote: >>>>> >>>>>> ShivaVG looks definitely as a way to ease the pain of porting to >>>>>> OpenGL. >>>>>> >>>>>> Some notes on the matter. The Cairo backend for OpenGL is opengl but >>>>>> yet its not opengl. What it does is render cairo as a opengl texture. >>>>>> OpenGL true power is in the shaders so you dont get the kind of hardware >>>>>> acceleration you would expect. >>>>>> >>>>>> Speewise as surprising this may sound opengl is not the ideal >>>>>> option, because opengl is mainly 3d orientated. The ideal solution from >>>>>> what I have seen would be something like CUDA or OpenCL, that give direct >>>>>> access to the GPU cores and allow you to do any kind of computation thus >>>>>> liberation from the restrictions of APIs. For example Blender takes >>>>>> advantage of both Opengl and CUDA , the CUDA renderer is phenomenal better >>>>>> because of its flexibility. >>>>>> >>>>>> The problem however is that all that are very technical and it takes >>>>>> quite some dedication to implement. >>>>>> >>>>>> A reason why I abandoned opengl as an idea is that I came to realise >>>>>> that Cairo was already fast enough for my needs. But I still keep that door >>>>>> open for the distant future, ShivaVG with OpenCL would be awesome for >>>>>> really intensive GUIs and complex Graphics and definitely would love to >>>>>> give it another try eventually. >>>>>> >>>>>> >>>>>> On Fri, Nov 1, 2013 at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: >>>>>>> >>>>>>>> Not sure to fully understand the problem. In what ShivaVG would >>>>>>>> solve a situation better than with Athens? If I understand well, a then >>>>>>>> working with Cairo uses the hardware acceleration right? >>>>>>>> What is it not enough for you need? >>>>>>>> >>>>>>>> First, OpenVG is more complete and i would say thoroughly designed >>>>>>> API than Cairo. >>>>>>> Second, i don't want to go Athens -> Cairo -> OpenGL >>>>>>> if i can do directly Athens->OpenGL. >>>>>>> Putting extra dependency out of the loop is advantageous, OpenGL is >>>>>>> widely supported industry standard, which today you can find even on >>>>>>> portable devices, while you cannot say same about Cairo. >>>>>>> (not mentioning avoiding costs of having multiple layers to get to >>>>>>> the hardware). >>>>>>> >>>>>>> ShivaVG implements OpenVG API using OpenGL, since OpenVG is vector >>>>>>> graphics framework >>>>>>> it can serve as a good source to look how to implement OpenGL >>>>>>> backend for Athens. >>>>>>> >>>>>>> >>>>>>>> Alexandre >>>>>>>> >>>>>>>> > Le 31-10-2013 Ã 19:16, Igor Stasenko <siguctua(a)gmail.com> a >>>>>>>> Ã©crit : >>>>>>>> > >>>>>>>> > I cannot say, of course, how it would be for you, but there is >>>>>>>> ShivaVG[1] open-source >>>>>>>> > opengl implementation of OpenVG, more or less feature-complete, >>>>>>>> > so all what is needed is to port this code from C to smalltalk. >>>>>>>> > Or if not for porting, but using as a source of insights how to >>>>>>>> implement it. >>>>>>>> > I think it is fairly doable. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best regards, >>>>>>> Igor Stasenko. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >

Nov. 11, 2013

Re: [Pharo-dev] Questions about Athens

by kilon alios

Igor I am trying your session code but it does not work for me. I still get the red box of doom. This is the method checkSession session == Smalltalk session ifFalse: [ surface := surface := AthensCairoSurface extent: self extent. . session := Smalltalk session. ] and This is my full stack NBFFICallout class>>signalError: NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: NBFFICalloutAPI>>function:module: AthensCairoSurface class(Object)>>nbCall: AthensCairoSurface class>>primImage:width:height: NBFFICallout class(NBNativeCodeGen class)>>retrySend: AthensCairoSurface class>>extent:format: AthensCairoSurface class>>extent: Hyperion>>mouseDown: Hyperion(Morph)>>handleMouseDown: MouseButtonEvent>>sentTo: Hyperion(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchMouseDown:with: MorphicEventDispatcher>>dispatchEvent:with: Hyperion(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchMouseDown:with: MorphicEventDispatcher>>dispatchEvent:with: SystemWindow(Morph)>>processEvent:using: SystemWindow(Morph)>>processEvent: SystemWindow>>mouseDown: in Block: [ ... BlockClosure>>ensure: SystemWindow>>mouseDown: SystemWindow(Morph)>>handleMouseDown: MouseButtonEvent>>sentTo: SystemWindow(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchMouseDown:with: MorphicEventDispatcher>>dispatchEvent:with: SystemWindow(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchMouseDown:with: MorphicEventDispatcher>>dispatchEvent:with: On Sat, Nov 2, 2013 at 12:01 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > and here is the strange MNU that I was talking about earlier > > here is the full stack > > Hyperion(Object)>>doesNotUnderstand: #passenger > PackageTreeModel>>acceptDroppingMorph:event:inMorph: > MorphTreeMorph>>acceptDroppingMorph:event: > MorphTreeMorph(Morph)>>handleDropMorph: > DropEvent>>sentTo: > MorphTreeMorph(Morph)>>handleEvent: > MorphicEventDispatcher>>dispatchDropEvent:with: > MorphicEventDispatcher>>dispatchEvent:with: > MorphTreeMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDropEvent:with: > MorphicEventDispatcher>>dispatchEvent:with: > PanelMorph(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDropEvent:with: > MorphicEventDispatcher>>dispatchEvent:with: > NautilusWindow(Morph)>>processEvent:using: > MorphicEventDispatcher>>dispatchDropEvent:with: > MorphicEventDispatcher>>dispatchEvent:with: > WorldMorph(Morph)>>processEvent:using: > WorldMorph(Morph)>>processEvent: > HandMorph>>sendEvent:focus:clear: > HandMorph>>sendEvent:focus: > HandMorph>>dropMorph:event: > HandMorph>>dropMorphs: in Block: [ :m | ... > Array(SequenceableCollection)>>reverseDo: > HandMorph(Morph)>>submorphsReverseDo: > HandMorph>>dropMorphs: > HandMorph>>handleEvent: > HandMorph>>processEvents > WorldState>>doOneCycleNowFor: in Block: [ :h | ... > Array(SequenceableCollection)>>do: > > > This one happens when I bring up the halos and try to move the morph > around.Morphs gets deleted because of MNU. Note it does not happen with > just my Class (Hyperion) it happens with any morph using Athens. > > Hyperion in this case is a partial copy of the AthensDemoMorph. As always > I am using Pharo 3 (Latest update: #30534) . > > > On Fri, Nov 1, 2013 at 7:14 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 1 November 2013 14:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: >> >>> Ok now the explanation :) >>> Spec changed recently in 30. >>> >>> >> then i need help on that.. what is needs to be changed. >> btw, i noticed that monticello configuration browser also having problems >> with spec. >> >> >>> Stef >>> >>> >>> Again I am following Igor instructions, loaded Athens-Tutorial from >>> smalltalkhub , opened a new workspace, AthensTutorial open. I am using a >>> pharo 3 that downloaded just yesterday. (Pharo3.0 Latest update: #30532) >>> >>> here is the full stack >>> >>> AthensViewMorph(Object)>>doesNotUnderstand: #layout: >>> SpecInterpreter>>actionToPerformWithSelector:arguments: >>> SpecInterpreter>>performNextSelectorAndIncrementIndex >>> SpecInterpreter>>interpretASpec:selector: >>> SpecInterpreter>>interpretASpec:model:selector: >>> SpecInterpreter class>>private_interpretASpec:model:selector: >>> SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ :each >>> | self class private_interpretASpec: each ...etc... >>> Array(SequenceableCollection)>>collect: >>> SpecInterpreter>>performNextSelectorAndIncrementIndex >>> SpecInterpreter>>interpretASpec:selector: >>> SpecInterpreter>>interpretASpec:model:selector: >>> SpecInterpreter class>>private_interpretASpec:model:selector: >>> SpecInterpreter class>>interpretASpec:model:selector: in Block: [ result >>> := self private_interpretASpec: aPresente...etc... >>> BlockClosure>>ensure: >>> SpecInterpreter class>>interpretASpec:model:selector: >>> SpecInterpreter class>>interpretASpec:model: >>> AthensTutorial(ComposableModel)>>buildWithSpecLayout: >>> MorphicWindowAdapter>>addModelIn:withSpecLayout: >>> MorphicWindowAdapter(AbstractAdapter)>>update:with: >>> WindowModel(Object)>>changed:with: in Block: [ :aDependent | aDependent >>> update: anAspect with: ...etc... >>> DependentsArray>>do: >>> WindowModel(Object)>>changed:with: >>> WindowModel>>addModelIn:withSpecLayout: >>> WindowModel>>buildWithSpecLayout: >>> WindowModel>>openWithSpecLayout: >>> AthensTutorial(ComposableModel)>>openWithSpecLayout: >>> AthensTutorial(ComposableModel)>>openWithSpec: >>> AthensTutorial(ComposableModel)>>openWithSpec >>> AthensTutorial class>>open >>> UndefinedObject>>DoIt >>> >>> Is that enough ? >>> >>> I am also getting another error from Athens from time to time, I will >>> have to remember to capture it cause it appears randomly. >>> >>> >>> On Fri, Nov 1, 2013 at 1:42 PM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> >>>> >>>> On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios(a)gmail.com> wrote: >>>> >>>> Igor I got Athens-Tutorial but it gives me a MNU: >>>> AthensViewMorph>>layout: >>>> >>>> >>>> strange tell us more. >>>> You know >>>> which image >>>> â¦. >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> On Fri, Nov 1, 2013 at 10:23 AM, kilon alios <kilon.alios(a)gmail.com>wrote: >>>> >>>>> ShivaVG looks definitely as a way to ease the pain of porting to >>>>> OpenGL. >>>>> >>>>> Some notes on the matter. The Cairo backend for OpenGL is opengl but >>>>> yet its not opengl. What it does is render cairo as a opengl texture. >>>>> OpenGL true power is in the shaders so you dont get the kind of hardware >>>>> acceleration you would expect. >>>>> >>>>> Speewise as surprising this may sound opengl is not the ideal option, >>>>> because opengl is mainly 3d orientated. The ideal solution from what I have >>>>> seen would be something like CUDA or OpenCL, that give direct access to the >>>>> GPU cores and allow you to do any kind of computation thus liberation from >>>>> the restrictions of APIs. For example Blender takes advantage of both >>>>> Opengl and CUDA , the CUDA renderer is phenomenal better because of its >>>>> flexibility. >>>>> >>>>> The problem however is that all that are very technical and it takes >>>>> quite some dedication to implement. >>>>> >>>>> A reason why I abandoned opengl as an idea is that I came to realise >>>>> that Cairo was already fast enough for my needs. But I still keep that door >>>>> open for the distant future, ShivaVG with OpenCL would be awesome for >>>>> really intensive GUIs and complex Graphics and definitely would love to >>>>> give it another try eventually. >>>>> >>>>> >>>>> On Fri, Nov 1, 2013 at 2:19 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: >>>>>> >>>>>>> Not sure to fully understand the problem. In what ShivaVG would >>>>>>> solve a situation better than with Athens? If I understand well, a then >>>>>>> working with Cairo uses the hardware acceleration right? >>>>>>> What is it not enough for you need? >>>>>>> >>>>>>> First, OpenVG is more complete and i would say thoroughly designed >>>>>> API than Cairo. >>>>>> Second, i don't want to go Athens -> Cairo -> OpenGL >>>>>> if i can do directly Athens->OpenGL. >>>>>> Putting extra dependency out of the loop is advantageous, OpenGL is >>>>>> widely supported industry standard, which today you can find even on >>>>>> portable devices, while you cannot say same about Cairo. >>>>>> (not mentioning avoiding costs of having multiple layers to get to >>>>>> the hardware). >>>>>> >>>>>> ShivaVG implements OpenVG API using OpenGL, since OpenVG is vector >>>>>> graphics framework >>>>>> it can serve as a good source to look how to implement OpenGL backend >>>>>> for Athens. >>>>>> >>>>>> >>>>>>> Alexandre >>>>>>> >>>>>>> > Le 31-10-2013 Ã 19:16, Igor Stasenko <siguctua(a)gmail.com> a Ã©crit >>>>>>> : >>>>>>> > >>>>>>> > I cannot say, of course, how it would be for you, but there is >>>>>>> ShivaVG[1] open-source >>>>>>> > opengl implementation of OpenVG, more or less feature-complete, >>>>>>> > so all what is needed is to port this code from C to smalltalk. >>>>>>> > Or if not for porting, but using as a source of insights how to >>>>>>> implement it. >>>>>>> > I think it is fairly doable. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Nov. 11, 2013

Re: [Pharo-dev] Who is Penelope, Ulysse's wife?

by phil＠highoctane.be

Here: (once maintenance window is closed) http://bugs.pharo.org/ She allows the input of issues for people without FogBugz login etc I think. One should give us the full story on Ulysse the monkey for issues tests and Penelope Phil On Mon, Nov 11, 2013 at 2:04 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Looks like to be a robot, but apparently she is able to fill bug entries? > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Nov. 11, 2013