- Pharo-dev - lists.pharo.org

Re: [Pharo-project] First try - BOOM! (Re: [Vm-dev] Re: [squeak-dev] Teleplace Cog VMs are now available)

by Eliot Miranda

On Mon, Jun 21, 2010 at 12:27 PM, stephane ducasse < stephane.ducasse(a)gmail.com> wrote: > > > There are a few other things also. Please file-in > NecessaryImageChangesForCogToWork.1.cs from the image directory in the > tarball or upgrade to the latest in trunk (i.e. Andreas added the changes > from NecessaryImageChangesForCogToWork.1.cs to trunk over the weekend). > > eliot > do you know whether these changes can be integrated and the images will > work on the different Cog and nonCog > These are "carefully crafted" to be backward-compatible. They will /not/ break an image for older VMs. There are three sets of changes: 1. remove primitives in LargePositiveInteger. These will make images slightly slower for certain benchmarks but won't break anything. 2. add special primitives for Float>>basicAt: at: basicAt:put: & at:put: that call super if they fail. They will fail on older VMs, hence these will make images slightly slower for certain benchmarks but won't break anything. 3. a new version of recreateSpecialObjectsArray that does not recreate the Character table. This will have no effect except for Cog, where it allows the VM to inline Character table access in the at: primitive. > Stef > > > > > > > Cheers, > > Henry > > > > On Jun 21, 2010, at 1:39 51PM, GÃ¶ran Krampe wrote: > > > > > Howdy! > > > > > > First: Super fun and cool! I am of course *very* happy to see Cog > released. > > > > > > Now, over to some "testing"... > > > > > > SIDENOTE: First btw I ran pystone.py with regular Python 2.6.5 on my > Lucid Lynx, then in the latest "regular" VM from Squeakvm.org. Result: > > > > > > Python: 36k pystones > > > Squeak: 45k pystones > > > > > > So... the good ole VM is still a tad faster than CPython in that bench. > :) > > > > > > Now, I wanted to try it out with Cogit. Trouble begins! :) > > > > > > I am using the tar ball on a Lucid laptop. > > > > > > 1. vm-sound-NAS does not compile! Lots of compile errors, probably due > to a new upstream NAS. So try to get rid of that plugin... is harder than I > thought! I finally ended up hacking the configure script to "fail" on the > compile check by trying to compile rubbish. ;) > > > > > > 2. For some odd reason this will still create duplicate lines about NAS > in disabledPlugins.c, just manually remove one of them, fine. Tada! Got a VM > binary. > > > > > > 3. Fire it up on a *vanilla* Squeak4.1.1.image. BOOM, segfault. This is > a "full debug VM" per instructions in HowToBuild. Anyway, see all info > below, and tell me if there is more you want. :) > > > > > > Btw, is there some nice existing script to run to "collect data about > the box" that does uname etc? > > > > > > regards, GÃ¶ran > > > ------------------ > > > gokr@yoda:~/squeak$ cat /proc/cpuinfo > > > processor : 0 > > > vendor_id : GenuineIntel > > > cpu family : 6 > > > model : 14 > > > model name : Genuine Intel(R) CPU U2500 @ 1.20GHz > > > stepping : 8 > > > cpu MHz : 800.000 > > > cache size : 2048 KB > > > physical id : 0 > > > siblings : 2 > > > core id : 0 > > > cpu cores : 2 > > > apicid : 0 > > > initial apicid : 0 > > > fdiv_bug : no > > > hlt_bug : no > > > f00f_bug : no > > > coma_bug : no > > > fpu : yes > > > fpu_exception : yes > > > cpuid level : 10 > > > wp : yes > > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc > arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm > > > bogomips : 2393.82 > > > clflush size : 64 > > > cache_alignment : 64 > > > address sizes : 32 bits physical, 32 bits virtual > > > power management: > > > > > > gokr@yoda:~/squeak$ gcc --version > > > gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 > > > Copyright (C) 2009 Free Software Foundation, Inc. > > > This is free software; see the source for copying conditions. There is > NO > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > > > > > > gokr@yoda:~/squeak$ uname -a > > > Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC > 2010 i686 GNU/Linux > > > > > > gokr@yoda:~/squeak$ squeak -version > > > 3.9-7 #1 Mon Jun 21 13:20:28 CEST 2010 gcc 4.4.3 > > > Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.11] > > > Linux yoda 2.6.32-22-generic-pae #36-Ubuntu SMP Thu Jun 3 23:14:23 UTC > 2010 i686 GNU/Linux > > > plugin path: /usr/local/lib/squeak/3.9-7/ [default: > /usr/local/lib/squeak/3.9-7/] > > > > > > gokr@yoda:~/squeak$ squeak Squeak4.1.1.image > > > > > > ((rcvr & 1)) || (addressCouldBeObj(rcvr)) 11334 > > > > > > Segmentation fault > > > > > > > > > > > > Smalltalk stack dump: > > > 0xbfc87e08 M GradientFillStyle>scaledAlphaMix:of:with: 2018669100: a(n) > GradientFillStyle > > > 0xbfc87e5c M [] in GradientFillStyle>computePixelRampOfSize: > 2018669100: a(n) GradientFillStyle > > > 0xbfc87e7c M SortedCollection(OrderedCollection)>do: 2018669424: a(n) > SortedCollection > > > 0xbfc87eb4 I GradientFillStyle>computePixelRampOfSize: 2018669100: a(n) > GradientFillStyle > > > 0xbfc87ed8 I [] in GradientFillStyle class>initPixelRampCache > 2007164144: a(n) GradientFillStyle class > > > 0xbfc87f10 I LRUCache>at: 2012963616: a(n) LRUCache > > > 0xbfc87f2c M GradientFillStyle>pixelRamp 2018529312: a(n) > GradientFillStyle > > > 0xbfc87f4c M BalloonEngine>registerFill: 2018659444: a(n) BalloonEngine > > > 0xbfc87f74 M BalloonEngine>registerFills: 2018659444: a(n) > BalloonEngine > > > 0xbfc87f90 M BalloonEngine>registerFill:and: 2018659444: a(n) > BalloonEngine > > > 0xbfc87fb4 M > BalloonEngine>drawRectangle:fill:borderWidth:borderColor:transform: > 2018659444: a(n) BalloonEngine > > > 0xbfc87fe8 M BalloonCanvas>drawRectangle:color:borderWidth:borderColor: > 2018659252: a(n) BalloonCanvas > > > 0xbfc88010 M BalloonCanvas>fillRectangle:fillStyle: 2018659252: a(n) > BalloonCanvas > > > 0xbfc88030 M FormCanvas>balloonFillRectangle:fillStyle: 2018611404: > a(n) FormCanvas > > > 0xbfc88054 M FormCanvas>fillRectangle:fillStyle: 2018611404: a(n) > FormCanvas > > > 0xbfc88074 M FormCanvas(Canvas)>fillRectangle:fillStyle:borderStyle: > 2018611404: a(n) FormCanvas > > > 0xbfc88098 M SystemWindow(Morph)>drawOn: 2014426088: a(n) SystemWindow > > > 0xbfc880b4 M FormCanvas(Canvas)>draw: 2018611404: a(n) FormCanvas > > > 0xbfc880d0 M FormCanvas(Canvas)>drawMorph: 2018611404: a(n) FormCanvas > > > 0xbfc880f0 M [] in SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) > SystemWindow > > > 0xbfc8810c M CornerRounder > class>roundCornersOf:on:in:displayBlock:borderWidth:corners: 2007442196: > a(n) CornerRounder class > > > 0xbfc8813c M FormCanvas>roundCornersOf:in:during: 2018611404: a(n) > FormCanvas > > > 0xbfc88160 M FormCanvas(Canvas)>roundCornersOf:during: 2018611404: a(n) > FormCanvas > > > 0xbfc88180 M SystemWindow(Morph)>fullDrawOn: 2014426088: a(n) > SystemWindow > > > 0xbfc8819c M FormCanvas(Canvas)>fullDraw: 2018611404: a(n) FormCanvas > > > 0xbfc881b8 M FormCanvas(Canvas)>fullDrawMorph: 2018611404: a(n) > FormCanvas > > > 0xbfc88208 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: > 2001318316: a(n) WorldState > > > 0xbfc88240 I Rectangle>allAreasOutsideList:startingAt:do: 2017358104: > a(n) Rectangle > > > 0xbfc8826c I Rectangle>allAreasOutsideList:do: 2017358104: a(n) > Rectangle > > > 0xbfc882a8 M [] in WorldState>drawWorld:submorphs:invalidAreasOn: > 2001318316: a(n) WorldState > > > 0xbfc882cc M Array(SequenceableCollection)>do: 2018529764: a(n) Array > > > 0xbfc882fc M WorldState>drawWorld:submorphs:invalidAreasOn: 2001318316: > a(n) WorldState > > > 0xbfc88334 M [] in WorldState>displayWorld:submorphs: 2001318316: a(n) > WorldState > > > 0xbfc8834c M FormCanvas>roundCornersOf:in:during: 2017358448: a(n) > FormCanvas > > > 0xbfc88370 M FormCanvas(Canvas)>roundCornersOf:during: 2017358448: a(n) > FormCanvas > > > 0xbfc88398 M WorldState>displayWorld:submorphs: 2001318316: a(n) > WorldState > > > 0xbfc883c0 I PasteUpMorph>privateOuterDisplayWorld 2001318568: a(n) > PasteUpMorph > > > 0xbfc883e0 I PasteUpMorph>displayWorld 2001318568: a(n) PasteUpMorph > > > 0xbfc88404 I [] in WorldState>displayWorldSafely: 2001318316: a(n) > WorldState > > > 0xbfc88420 M BlockClosure>on:do: 2018529472: a(n) BlockClosure > > > 0xbfc88440 M BlockClosure>ifError: 2018529472: a(n) BlockClosure > > > 0xbfc88464 I WorldState>displayWorldSafely: 2001318316: a(n) WorldState > > > 0xbfc88480 M PasteUpMorph>displayWorldSafely 2001318568: a(n) > PasteUpMorph > > > 0xbfc88498 M PasteUpMorph>install 2001318568: a(n) PasteUpMorph > > > 0xbfc884c0 I AutoStart class>checkForPluginUpdate 2008299932: a(n) > AutoStart class > > > 0xbfc884e0 M AutoStart class>startUp: 2008299932: a(n) AutoStart class > > > 0xbfc8850c M [] in SmalltalkImage>send:toClassesNamedIn:with: > 2009624740: a(n) SmalltalkImage > > > 0xbfc88534 I OrderedCollection>do: 2009661056: a(n) OrderedCollection > > > 0xbfc8855c I SmalltalkImage>send:toClassesNamedIn:with: 2009624740: > a(n) SmalltalkImage > > > 0xbfc88588 I SmalltalkImage>processStartUpList: 2009624740: a(n) > SmalltalkImage > > > 0xbfc885b4 I SmalltalkImage>snapshot:andQuit:embedded: 2009624740: a(n) > SmalltalkImage > > > 2014606248 s SmalltalkImage>snapshot:andQuit: > > > 2014606132 s TheWorldMainDockingBar>saveAndQuitSqueak > > > 2014606040 s [] in MenuItemMorph>invokeWithEvent: > > > 2014605924 s BlockClosure>ensure: > > > 2014605832 s CursorWithMask(Cursor)>showWhile: > > > 2014605632 s MenuItemMorph>invokeWithEvent: > > > 2014605540 s MenuItemMorph>mouseUp: > > > 2014605448 s MenuItemMorph>handleMouseUp: > > > 2014605316 s MouseButtonEvent>sentTo: > > > 2014605224 s MenuItemMorph(Morph)>handleEvent: > > > 2014605132 s MorphicEventDispatcher>dispatchDefault:with: > > > 2014605040 s MorphicEventDispatcher>dispatchEvent:with: > > > 2014604948 s MenuItemMorph(Morph)>processEvent:using: > > > 2014604856 s MorphicEventDispatcher>dispatchDefault:with: > > > 2014604748 s MorphicEventDispatcher>dispatchEvent:with: > > > 2014604616 s DockingBarMenuMorph(Morph)>processEvent:using: > > > 2014604524 s DockingBarMenuMorph(Morph)>processEvent: > > > 2014604432 s DockingBarMenuMorph(MenuMorph)>handleFocusEvent: > > > 2014604340 s [] in HandMorph>sendFocusEvent:to:clear: > > > 2014604248 s [] in PasteUpMorph>becomeActiveDuring: > > > 2014604068 s BlockClosure>on:do: > > > 2014603976 s PasteUpMorph>becomeActiveDuring: > > > 2014603856 s HandMorph>sendFocusEvent:to:clear: > > > 2014603764 s HandMorph>sendEvent:focus:clear: > > > 2014603672 s HandMorph>sendMouseEvent: > > > 2014603528 s HandMorph>handleEvent: > > > 2014603180 s HandMorph>processEvents > > > 2014603064 s [] in WorldState>doOneCycleNowFor: > > > 2014602972 s Array(SequenceableCollection)>do: > > > 2014602872 s WorldState>handsDo: > > > 2014602780 s WorldState>doOneCycleNowFor: > > > 2014602688 s WorldState>doOneCycleFor: > > > 2014602596 s PasteUpMorph>doOneCycle > > > 2010011832 s [] in Project class>spawnNewProcess > > > 2010011700 s [] in BlockClosure>newProcess > > > > > > Most recent primitives > > > basicNew > > > copyBits > > > @ > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > @ > > > basicNew > > > copyBits > > > @ > > > @ > > > @ > > > basicNew > > > @ > > > copyBits > > > @ > > > @ > > > @ > > > basicNew > > > basicNew: > > > at:put: > > > @ > > > copyBits > > > @ > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > @ > > > basicNew > > > shallowCopy > > > new: > > > @ > > > @ > > > new: > > > at:put: > > > at:put: > > > at:put: > > > at:put: > > > @ > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > basicNew > > > basicNew: > > > basicNew > > > @ > > > @ > > > basicNew > > > copyBits > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > @ > > > basicNew > > > basicNew: > > > at:put: > > > at:put: > > > @ > > > basicNew > > > copyBits > > > at:put: > > > @ > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > basicNew > > > basicNew: > > > basicNew > > > @ > > > @ > > > basicNew > > > copyBits > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > @ > > > basicNew > > > basicNew: > > > at:put: > > > at:put: > > > @ > > > basicNew > > > copyBits > > > at:put: > > > @ > > > @ > > > @ > > > @ > > > basicNew@ > > > @ > > > basicNew > > > basicNew: > > > basicNew > > > @ > > > @ > > > basicNew > > > copyBits > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > @ > > > basicNew > > > basicNew: > > > at:put: > > > at:put: > > > @ > > > basicNew > > > copyBits > > > at:put: > > > @ > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > basicNew > > > basicNew: > > > basicNew > > > @ > > > @ > > > basicNew > > > copyBits > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > @ > > > basicNew > > > basicNew: > > > at:put: > > > at:put: > > > @ > > > basicNew > > > copyBits > > > at:put: > > > @ > > > perform:with: > > > @ > > > @ > > > perform:with: > > > @ > > > basicNew > > > basicNew > > > @ > > > @ > > > @ > > > basicNew > > > basicNew > > > basicNew > > > basicNew > > > new: > > > basicNew: > > > basicNew > > > primitiveSetBitBltPlugin: > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > basicNew > > > @ > > > primitiveSetBitBltPlugin: > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > basicNew > > > @ > > > @ > > > wait > > > at:put: > > > signal > > > primInitializeBuffer: > > > primSetAALevel: > > > primSetOffset: > > > primSetClipRect: > > > primSetEdgeTransform: > > > primSetColorTransform: > > > primSetEdgeTransform: > > > primSetColorTransform: > > > primGetDepth > > > primSetDepth: > > > new: > > > at:put: > > > at:put: > > > basicNew: > > > species > > > stringHash:initialHash: > > > fractionPart > > > truncated > > > fractionPart > > > fractionPart > > > truncated > > > basicNew > > > basicNew > > > new: > > > value: > > > at:put: > > > value: > > > at:put: > > > at:put: > > > value:value: > > > value:value: > > > basicNew: > > > basicNew: > > > at:put: > > > at:put: > > > at:put: > > > at:put: > > > fractionPart > > > truncated > > > basicNew: > > > at:put: > > > at:put: > > > at:put: > > > at:put: > > > fractionPart > > > truncated > > > basicNew: > > > at:put: > > > at:put: > > > at:put: > > > at:put: > > > truncated > > > truncated > > > truncated > > > truncated > > > at:put: > > > perform:with: > > > truncated > > > Aborted > > > gokr@yoda:~/squeak$ > > > > > > > > > > > >

June 21, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by StÃ©phane Ducasse

yes I understand On Jun 21, 2010, at 8:18 PM, Julian Fitzell wrote: > On Mon, Jun 21, 2010 at 9:38 AM, Michael Roberts <mike(a)mjr104.co.uk> wrote: >> >> >> On 21 Jun 2010, at 14:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >>> but do we want all grease? >>> >> >> Well. Not sure. Grease core is not that big. It has other useful stuff in. I >> was in part commenting on the philosophy markus was referring to. I have a >> different point of view. If we just copy the extensions we have to >> maintain our own branch. And we can not use any extensions that reference >> grease classes. Then what happens if we really want an extension like that? >> We copy classes too?that would not make a lot of sense to me. >> >> So what do you think? > > Philosophically, Grease does not desire to provide implementation but > tests of available functionality. The tests are common to all > platforms and it is up to the platforms to ensure the tests pass. The > ideal is that each platform simply provides the needed functionality > (that's why we try to keep the size of Grease relatively small) and > that in cases where they do not wish to do so they will provide a > platform-specific Grease package that provides the functionality. > > The question here is regarding methods that we have provided in our > Pharo-specific Grease package and whether some or all of them should > be moved under Pharo's responsibility instead. As with all the other > platforms, I encourage the adoption of Grease extensions that are > considered generally useful and sane. Having these methods managed as > part of the Pharo process means that the correct version will always > be available in each Pharo release and that the methods are more > widely available for use. > > It seems like the specific methods in question are currently in > Grease-Core instead of Grease-Pharo-Core and I agree this is probably > not ideal (I'll respond separately to Dale's email about this). > Assuming they were in Grease-Pharo-Core, though, it would be a matter > of *moving* them into Pharo, not *copying* them (with the added > wrinkle of dealing with different Pharo versions, some of which have > them and some of which do not). > > Julian > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 21, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by StÃ©phane Ducasse

The idea of marcus is that this is important to improve the core even at the expense of adding some methods. This is why we added the regex and in fact we could rewrite a lot of part. Now this is not that simple. Stef >> but do we want all grease? >> > > Well. Not sure. Grease core is not that big. It has other useful stuff in. I was in part commenting on the philosophy markus was referring to. I have a different point of view. If we just copy the extensions we have to maintain our own branch. And we can not use any extensions that reference grease classes. Then what happens if we really want an extension like that? We copy classes too?that would not make a lot of sense to me. > > So what do you think? > mike > > >> Stef >> >> On Jun 17, 2010, at 6:42 PM, Michael Roberts wrote: >> >>> I'm missing something. Why do we need to adopt the (copy of) methods and not just adopt the package as lukas said? I thought we wanted core to get smaller over time and better modularised anyway? We would just need to track a stable version rather than maintaining our own branch. Surely it is worse to copy the methods renamed or not but put them in a pharo specific package? >>> >>> >>> Cheers mike >>> >>> On 17 Jun 2010, at 14:14, Julian Fitzell <jfitzell(a)gmail.com> wrote: >>> >>>> 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >>>>> >>>>> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >>>>> >>>>> - If included with Pharo I suggest to rename all the methods, >>>>> otherwise we will run into big troubles with Seaside and other >>>>> projects that depend on Grease. >>>>> >>>>> >>>>> From a philosophical standpoint, I *hate* that. this means that as a >>>>> plattform, we can not >>>>> grow and improve our libraris anymore? >>>>> Shouldn't be the goal that useful extensions gets adopted by the core? >>>> >>>> We will need to find a way to allow platforms to adopt Grease methods >>>> - I do think this is the end goal. It's a bit of a nightmare from our >>>> point of view because we end up having to have different Grease >>>> versions for different versions of the platforms, but isn't that sort >>>> of unavoidable in the long run anyway? Part of the reason that's so >>>> awful is simply due to the lack of good branching and management tools >>>> in our version control systems... >>>> >>>> Julian >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 21, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Julian Fitzell

Hmm... Why did I only receive this email today...? Anyway, I agree that those methods should probably be in the platform-specific package. I guess we were originally trying to minimize the amount of implementation required on each platform. As long as no platform implements a method and the implementation is the same on all platforms, it is convenient to have it in only one place. As soon as a platform chooses to implement it, though, we will simply have to move it to the platform-specific package. At this point we run into the issue of having different platform packages for, say, Pharo 1.1 and 1.2. Perhaps in the end it is simpler just to keep extensions always in the platform packages and insist that the generic packages contain only GR* classes and grease* extension methods. I'm not sure about Grease providing reference implementations of all methods it tests, though. I'm not convinced that a "gold standard" always exists, nor that it will necessarily be implemented by Grease. In many cases, we have standardized on methods that already exist in Squeak/Pharo or in some other platform. On Thu, Jun 17, 2010 at 9:30 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Julian, > > The Grease-Core package contains a mixture of things (for convenience): the > GR* family of classes using a naming convention that is unlikely to collide > with platform classes and a collection of extensions to well-known classes > using names that could very easily collide with platform methods (or prevent > a platform from implementing that method in their base system). > > The well-known class extension methods could easily be moved to the > platform-side, then as platforms adopt the Grease extensions (an obvious > goal of Grease in the first place) the platform extensions can be adjusted > accordingly...the Grease-Tests for those methods should remain so that from > the Grease-Users perspective the behavior for those methods will remain > consistent (relative to Grease) over time... > > It _would be convenient_ to preserve the current well-known class extension > method implementations so that when Grease is ported to a new platform the > "standard implementation" can be used as a bootstrap. In fact if the > well-known class extension methods were moved into a separate platform > package, then you'd have the gold standard implementation and the initial > pharo/squeak implementation rolled into one. > > In the end this doesn't sound that awful... > > Dale > > Julian Fitzell wrote: >> >> 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >>> >>> - If included with Pharo I suggest to rename all the methods, >>> otherwise we will run into big troubles with Seaside and other >>> projects that depend on Grease. >>> >>> >>> From a philosophical standpoint, I *hate* that. this means that as a >>> plattform, we can not >>> grow and improve our libraris anymore? >>> Shouldn't be the goal that useful extensions gets adopted by the core? >> >> We will need to find a way to allow platforms to adopt Grease methods >> - I do think this is the end goal. It's a bit of a nightmare from our >> point of view because we end up having to have different Grease >> versions for different versions of the platforms, but isn't that sort >> of unavoidable in the long run anyway? Part of the reason that's so >> awful is simply due to the lack of good branching and management tools >> in our version control systems... >> >> Julian >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 21, 2010

Re: [Pharo-project] [squeak-dev] Teleplace Cog VMs are now available

by Juan Vuletich

Hi Eliot, Eliot Miranda wrote: > > Hi All, > > > it gives me great pleasure to announce that the Teleplace Cog VMs are > now available. Huge thanks to all at Teleplace who have given me the > opportunity to build Cog and release it as open source, been willing > guinea pigs braving its bugs, and providing indispensable > participation in getting Cog to its current state. Huge thanks are > also due to the original Back To The Future team whose VMMaker Cog > extends to write the VM, and to Peter Deutsch from whom I've taken > many ideas. > ... This is wonderful news! Thank you, Andreas, and all the people at Teleplace who made this possible! I tried to run Cuis on the Windows VM Andreas did, and I'm having trouble. I did as follows: 1) Start Cuis 2.4 with the Closure VM 2) Install the attached changeset (made after your post and the tweaks 3) Exit saving the image 4) Start it with the Cog VM When starting, it does an invalid memory access, and terminates without any error message or log. I guess I'd need to setup a VM building and debugging environment, etc, and learn quite a bit to fix this myself. I guess it would take you minutes to spot this, compared with the days I'd need to spend... I'd very much appreciate your help. Thank you. Cheers, Juan Vuletich

June 21, 2010

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] Teleplace Cog VMs are now available

by Eliot Miranda

Hi Henry, On Mon, Jun 21, 2010 at 10:22 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > > On Jun 20, 2010, at 11:47 45PM, Eliot Miranda wrote: > > > > > I expect the next few weeks to involve some bug fixing as it is used in > a much broader context (no pun intended). Y'all can help by giving me > reproducible test cases. > > I made the Float/LargeInt and special object array changes, not sure if it > 's just my derived images missing more or an actual bug, but... > > [|b| 5] value, and [: a | |b| 5 ] value: 1 crashes in both Squeak and > Pharo. > Crashes my VM too :) Thanks!! > Compiler evaluate: '[ :a | | t | ] value: 1' crashes the VM in Pharo 1.1, > but not in Squeak. > This doesn't crash for me. So this is likely a closure compiler issue. Someone might want to compare the closure compiler in Squeak trunk against Pharo and move the updates across. I'll happily review. It returns 1 rather than nil though, as is expected in Pharo at least. > > Cheers, > Henry > >

June 21, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Julian Fitzell

On Mon, Jun 21, 2010 at 9:38 AM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > > > On 21 Jun 2010, at 14:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> but do we want all grease? >> > > Well. Not sure. Grease core is not that big. It has other useful stuff in. I > was in part commenting on the philosophy markus was referring to. I have a > different point of view. Â If we just copy the extensions we have to > maintain our own branch. And we can not use any extensions that reference > grease classes. Then what happens if we really want an extension like that? > We copy classes too?that would not make a lot of sense to me. > > So what do you think? Philosophically, Grease does not desire to provide implementation but tests of available functionality. The tests are common to all platforms and it is up to the platforms to ensure the tests pass. The ideal is that each platform simply provides the needed functionality (that's why we try to keep the size of Grease relatively small) and that in cases where they do not wish to do so they will provide a platform-specific Grease package that provides the functionality. The question here is regarding methods that we have provided in our Pharo-specific Grease package and whether some or all of them should be moved under Pharo's responsibility instead. As with all the other platforms, I encourage the adoption of Grease extensions that are considered generally useful and sane. Having these methods managed as part of the Pharo process means that the correct version will always be available in each Pharo release and that the methods are more widely available for use. It seems like the specific methods in question are currently in Grease-Core instead of Grease-Pharo-Core and I agree this is probably not ideal (I'll respond separately to Dale's email about this). Assuming they were in Grease-Pharo-Core, though, it would be a matter of *moving* them into Pharo, not *copying* them (with the added wrinkle of dealing with different Pharo versions, some of which have them and some of which do not). Julian

June 21, 2010

Re: [Pharo-project] OpenDBX for dbase files

by Facundo Vozzi

Beniot, I could do that on Pharo 1.1 without troubles but then I'll try your steps on Pharo 1.0 and i'll notify you the results. Thanks, Facundo 2010/6/21 Benoit St-Jean <bstjean(a)hotmail.ca> > Hi Facundo, > > Looking at my notes : > > 1) Load FFI > ScriptLoader loadFFI > > 2) Load ODBC from SqueakSource.com > > MCHttpRepository > location: 'http://www.squeaksource.com/ODBC' > user: '' > password: '' > > 3) Initialize some stuff > > ExternalStructure > allSubclassesDo: [:each | each compileFields]. > > > Hope this helps. > Let me know if this works... > > > ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > ------------------------------ > Date: Thu, 17 Jun 2010 12:21:56 -0300 > > From: facundov79(a)gmail.com > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OpenDBX for dbase files > > > Beniot, > do you use this for OBDC on Pharo, > http://www.squeaksource.com/@N-vIVE5EmBTpAjWY/bYzXEKgO ? > > Last night, I tried it but i had my image blocked. Tonight, i'll try it > again. > > Thanks, > Facundo > > 2010/6/17 Benoit St-Jean <bstjean(a)hotmail.ca> > > Hi Facundo, > > You can use ODBC to access it. > > From what I read on the SqueakDBX web page, they don't support xBase files > nor ODBC (only ODBC for POstgreSQL is listed) yet. > > The xBase package on squeaksource might work but your best bet would be > ODBC as far as I know. > > ODBC works fine and is rock-solid in Pharo. I'm using it to connect to > PostGreSQL, InterBase, MySQL, Oracle, DB2 and SQL Server without any > problem. > > Hope this helps. > > ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > ------------------------------ > Date: Fri, 11 Jun 2010 08:18:14 -0300 > From: facundov79(a)gmail.com > > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] OpenDBX for dbase files > > > Hi at all, > can I used openDBX for read dbase (.dbf) files or I need try with xbase ? > > regards, > Facu > > > ------------------------------ > Turn down-time into play-time with Messenger games Play Now!<http://go.microsoft.com/?linkid=9734381> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- > Facundo Vozzi > InfOil S.A. > Project Leader > (+54-11) 4542-9999 x108 > fvozzi(a)infoil.com.ar > > ------------------------------ > Your Photo on Bing.ca: You Could WIN on Canada Day! Submit a Photo Now! > <http://go.microsoft.com/?linkid=9734380> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 21, 2010

Re: [Pharo-project] Issue 2560 : Convenient methods from Grease for Strings

by Julian Fitzell

On Fri, Jun 18, 2010 at 4:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jun 17, 2010, at 3:14 PM, Julian Fitzell wrote: > >> 2010/6/17 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>> On Jun 17, 2010, at 12:27 PM, Lukas Renggli wrote: >>> >>> - If included with Pharo I suggest to rename all the methods, >>> otherwise we will run into big troubles with Seaside and other >>> projects that depend on Grease. >>> >>> >>> From a philosophical standpoint, I *hate* that. this means that as a >>> plattform, we can not >>> grow and improve our libraris anymore? >>> Shouldn't be the goal that useful extensions gets adopted by the core? >> >> We will need to find a way to allow platforms to adopt Grease methods >> - I do think this is the end goal. It's a bit of a nightmare from our >> point of view because we end up having to have different Grease >> versions for different versions of the platforms, but isn't that sort >> of unavoidable in the long run anyway? > > because you were planning to have only one grease for all the platform. > Ok this was not obvious. No, there are packages for each platform. What we don't yet have is separate packages for different *versions* of a platform. But that may be unavoidable over time... Julian

June 21, 2010

Re: [Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by Adrian Lienhard

Hi Laurent, Thanks signing up for this task. If you don't get around to doing it, just let us know. Cheers, Adrian On Jun 21, 2010, at 10:10 , laurent laffont wrote: > On Fri, Jun 18, 2010 at 12:29 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> Just a meta remark... >> >> In this thread 8 people have sent a total of 30 mails. But in the end >> nobody volunteers to do the (not very hard) work to make what was discussed >> actually happen. Was this a bikeshed.com discussion? Maybe not since >> designing good menus is complex and important. But my point is that we >> should take care, as a community, to not only invest into discussions but at >> least as much into *doing*. >> > > You're right, but for my part I *hate* saying "I will do" and then don't > find the courage/motivation/whatever and not doing it (especially when > something else captures my energy, I'm suspicious of myself :). > > That said I've reached the first step I want on Autotest, so now I can work > on the menus, I know how it works. > > Cheers, > > Laurent > > > >> >> Cheers, >> Adrian >> >> >> >> On Jun 16, 2010, at 08:42 , Adrian Lienhard wrote: >> >>> OK, since there seems no opposition lets change it as proposed. >>> >>> Any taker? >>> >>> Adrian >>> >>> On Jun 15, 2010, at 09:17 , StÃ©phane Ducasse wrote: >>> >>>> >>>> On Jun 14, 2010, at 10:07 PM, Adrian Lienhard wrote: >>>> >>>>> OK, Torsten has some good points (like, why not doing it right now >> rather than later?)! I took the proposal of Torsten from an earlier mail and >> tweaked it a bit. This shows the complete world menu including sub menus: >>>>> >>>>> System Browser >>>>> Workspace >>>>> Test Runner >>>>> Monticello Browser >>>>> -------------------- >>>>> Tools >>>>> ... (<-as today) >>>>> Windows >>>>> Collapse all windows >>>>> Expand all windows >>>>> Close top window <<<< we could remove that since you can also press >> the button >>>>> Close all debuggers >>>>> Send top window to back >>>>> Move window onscreen >>>>> Delete unchanged windows >>>>> System >>>>> About... >>>>> Settings >>>>> -------------- >>>>> VM statistics >>>>> Start profiling all processes >>>>> Start profiling UI >>>>> -------------- >>>>> Start drawing again >>>>> Start stepping again >>>>> -------------- >>>>> Restore display >>>>> Enable halt inspect once >>>>> Help >>>>> Help Browser >>>>> ProfStef Tutorial >>>>> Welcome Workspace >>>>> ---------------- >>>>> Save >>>>> Save as... >>>>> Save and quit >>>>> Quit >>>>> >>>>> >>>>> Note, I inlined the debug menu into System. The reason is that I don't >> like multiply nested menus and the system menu does not get overly long. >> Also I deleted "Space left". Maybe other items like "Start stepping again" >> are also not really useful anymore? Furthermore I moved "Close all >> debuggers" into the Windows menu. I kept About... in system as I think it >> has not much to do with Help but more with System. I also changed the labels >> of some of the items (like Help Browser and ProfStef Tutorial). >>>>> >>>>> Does that look reasonable? >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> On Jun 14, 2010, at 20:45 , StÃ©phane Ducasse wrote: >>>>> >>>>>> torsten >>>>>> >>>>>> propose a menu redistribution as laurent did so that we arrive to >> something better. >>>>>> I agree that debug could be in another place than in root. >>>>>> >>>>>> stef >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 21, 2010