- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 2290: window placement strategy
by Laval Jannik June 21, 2010

June 21, 2010

Hi all, I made a setting for placement strategy. By default, it is reversed stragger (which is the one by default since Pharo exists). And I create one I have named "Cascade", which place the new window above the current active window, or if there is no active window, the window is placed at the cursor position. The change is available in SLICE-Issue-2290-windowsStrategy. The setting is available in the SettingBrowser in Appearance>Morphic>Windows>Window position strategy. Now, it is possible to create new strategy positions by creating a new strategy in RealEstateAgent (category strategy - there is also three strategies), and by modifying the method RealEstateAgent >>usedStrategySettingsOn: to add an entry in the menu. I hope that this change will be integrated in 1.2. Cheers, --- Jannik Laval

3 3

Re: [Pharo-project] First try - BOOM! (Re: [Vm-dev] Re: [squeak-dev] Teleplace Cog VMs are now available)
by Eliot Miranda June 21, 2010

June 21, 2010

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$ > > > > > > > > > > > >

1 0

Re: [Pharo-project] [squeak-dev] Teleplace Cog VMs are now available
by Lukas Renggli June 21, 2010

June 21, 2010

Thank you Eliot. This is wonderful, it feels like I just got a new laptop :-) I noticed some problems in the continuation tests of Seaside (WAContinuationTest, WAFlowPlatformTest and WAPartialContinuationTest): "Computation has been terminated" in MethodContext>>cannotReturn: Is this a known problem? Or is this maybe specific to Pharo on Cog? Cheers, Lukas On 20 June 2010 22:53, stephane ducasse <stephane.ducasse(a)gmail.com> wrote: > This is really an excellent news. I open a lot of new futures! > Thanks teleplace, andreas and all the people that helped. > > Stef > PS: you already answer my questions about platform were the jit cannot work so this is great. > > > On Jun 20, 2010, at 10:11 PM, 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 release contains two VMs. Â The Stack VM, is a cross-platform interpreter that uses context-to-stack mapping to achieve modest performance gains. Â The Cog VM is a just-in-time compiler that currently supports only x86 that builds upon the Stack VM to achieve substantial performance improvements. Â The release is in the form of a Monticello package containing the VMMaker source and a tarball containing the platform sources, the generated sources and a Squeak 4.1 image containing the VMMaker sources. Â Download both at >> Â Â Â http://ftp.squeak.org/Cog/VMMaker-oscog.11.mcz >> Â Â Â http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz >> >> Cog VMs: >> >> The Cog VMs are Squeak/Croquet VMs that run closure Squeak/Croquet/Pharo/Cuis images. The VMs support existing plugin source but will require plugins to be recompiled as the VM_PROXY_MAJOR plugin api has been extended. >> >> This release contains two distinct VMs, the StackInterpreter and the Cogit. Â The StackInterpreter is a fully-portable plug-in replacement for the current closure Squeak VMs and images. Â The Stack VM uses context-to-stack mapping and a somewhat improved garbage collector to achieve modest but useful performance gains in the 10% to 15% range. Â The StackInterpreter is intended to supersede the Squeak VM on platforms where the Cogit cannot be used. Â The Cogit extends the StackInterpreter with a just-in-time compiler that uses aggressive inline caching techniques to deliver substantial performance gains in the 3x to 15x range, depending on benchmark. Â The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. Â I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64. Â The Cogit (excuse the pun) is so named because it is both an interpreter and a JIT, choosing not to generate machine code for large methods, interpreting them instead, the default policy being not to JIT methods with more than 60 literals. >> >> The Cog VM requires a few minor image changes all in image/NecessaryImageChangesForCogToWork.1.cs. Â The JIT's machine-code SmallInteger primitives insist on a SmallInteger receiver so the primitives in LargePositiveInteger = ~= bitAnd: bitOr: butShift: and bitXor: cannot be used and these methods must be deleted. Â The Cogit inlines the address of the Character instance table, Smalltalk specialObjectsArray at: 25, into the machine-code at: primitive for faster ByteString>>at: and so the table cannot be rebuilt in SmalltalkImage>>recreateSpecialObjectsArray. Â The new version preserves the existing table. Â Both VMs maintain floats in platform order to ease implementation of machine code floating-point primitives, and hence internally are in little-endian order instead of big-endian in current Squeak images. Â While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt: & Float>>basicAt:put: that undo the reversal and answer Float contents in big-endian order so that e.g. Float>>hash is unchanged. Â The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs. >> >> The image/VMMaker-Squeak4.1.image is a Squeak 4.1 image, runnable with the current Squeak VMs, that contains these changes, and can hence also be run with a Cog VM. Â But beware, once an image has been saved on Cog it cannot be run by an existing Squeak VM, because existing VMs cannot undo the Float order change. >> >> >> Platform Subsystem: >> >> Most of the platform subsystem is unchanged but there are some important changes that need description. Â The biggest change is the heartbeat and the clock in platforms/unix/vm/sqUnixHeartbeat.c and platforms/win32/vm/sqWin32Heartbeat.c. Â The Cog VMs avoid the slow and variable interruptCheckCounter, folding the event check into the stack overflow check on frame build. Â The heartbeat, typically 500Hz or 1KHz, changes the stackLimit to a value that will always fail. Â On the next frame building send the VM will enter stack overflow handling that, as a side effect, will also check for events. Â This is more efficient than the update of interruptCheckCounter and much more regular. Â If one is running code that executes long-running primitives (e.g. large integer arithmetic) the counter approach will result in too low an interrupt check frequency, and conversely if one is running normal code the interrupt check frequency can be very high. >> >> The heartbeat also maintains a 64-bit microsecond clock, UTC microseconds from 1901, from which the backward-compatible millisecond and second clocks are derived. Â Primitives exist to answer UTC microseconds and local microseconds. Â Updating the clock in the heartbeat results in a 1 or 2 millisecond resolution but avoids the cost of accessing the OS time on every prim tie which we've found important for performance at Teleplace. Â The 64-bit microsecond clocks provide a unified time basis and eliminate wrapping (for the next 54,000 years at least). Â I hope community images will move to these clocks. Â It's worked well in VisualWorks. >> >> Another significant change is in the external semaphore table support code. Â This is now lock-free at the cost of having to specify a maximum number of external semaphores at start-up (default 256). Â The support code for the lock-free data structures are processor-specific and is currently implemented only for x86 and gcc-compatible compilers; see platforms/Cross/vm/{sqAtomicOps.h,sqMemoryFence.h}. >> >> There is also improved crash reporting code that prints a primitive log and a C backtrace in addition to the Smalltalk backtrace. Â See platforms/Mac OS/vm/sqMacMain.c, platforms/unix/vm/sqUnixMain.c, platforms/win32/vm/sqWin32Intel.c & platforms/win32/vm/sqWin32Backtrace.c. >> >> Finally there is support for the QVMProfiler, a pc-sampling profiler for profiling at the VM level. Â See platforms/unix/vm/sqUnixVMProfile.c and platforms/win32/vm/sqWin32VMProfile.c. Â The profiler itself is in the VMMaker image described below in Qwaq-VMProfiling. >> >> There are also changes to do with Teleplace-specific extensions to the HostWindowPlugin but these are not essential to Cog. >> >> >> VMMaker and Slang: >> >> The image/VMMaker-Squeak4.1.image Squeak 4.1 image contains the complete Cog VMMaker with necessary support code for simulation. This image was used to generate the sources in the src and stacksrc directories. >> >> Cog's VMMaker is substantially revised and extended from the current VMMaker. Â It supports multiple classes, not just Interpreter and superclasses, because both context-to-stack mapping and the Cogit are too complex to write monolithically. Â Classes can specify ancilliaryClasses and ancilliaryStructClasses, such as CoInterpreterStackPage, CogMethod and CogAbstractInstruction. Â The Monticello package version is included in the header of all generated files and constitutes the version stamp for generated code. Â Code is generated in sorted order so that minor changes in the Smalltalk source produce correspondingly minor changes in the generated code. Â The gnuification step is built-in to VMMaker. Â No effort has been made to maintain 64-bit compatibility. Â Apologies, this was unaffordable. >> >> The VMMaker generates a single source tree used by all platforms. Â Instead of deciding at generation time whether to use the Interpreter struct the generated code depends on the SQ_USE_GLOBAL_STRUCT define which can be overridden in platform makefiles. Â All plugins live in src/plugins and platform makefiles along with plugins.int and plugins.ext files in the build subdirectories decide which plugins are built as external or internal. Â The VM Generation Workspace from Workspace.text workspace contains dots to generate the sources. Â We no longer use the VMMakerTool since there should be nothing platform-specific in the generated sources (if we add ports to other ISAs all their source can be included and selected as required by the platform makefiles). >> >> Since the Cogit generates x86 machine code simulation is much more complex. Â There is a support plugin, platforms/Cross/plugins/BochsIA32Plugin that depends on a large simulation of the x86 family implemented in C++ (see Â processors/IA32/bochs) and on Alien. Â I use the simulator frequently (but note that I haven't had time to build a working version for Squeak 4.1). Â I have tested Cog simulation in this image, running on the image/VMMaker-Squeak4.1.image itself. Â The VM Simulation Workspace in the VMMaker image contains an example doit that starts the simulator. Be patient, even on a fast machine unhibernating the Squeak display background image takes nearly a minute. Â Native fonts do not (yet) simulate correctly, but the system runs. Â But note that I have only attempted to build and run the simulator on Mac OS X. Â I expect Bochs can be built on linux and win32 but I have not tried. Â By the way, I've not described how to run the Bochs simulator on the current Squeak VM. Â That's because the plugin depends on the heartbeat to break out of simulation occasionally via a new interpreterProxy entry point setInterruptCheckChain. Â As this isn't supported by the current Squeak VMs the plugin would require modification. Â So to simulate first build either of the Cog VMs and then run the simulation with it. >> >> There are a number of unpublished changes to the base other than those in NecessaryImageChangesForCogToWork.1.cs. Â This is partly laziness on my part, partly avoiding publishing things in advance of Cog. Â These changes are better motivated once Cog is in use. Â There are changes to the "translated primitives" (see implementors of translatedPrimitives) which replace messages with method tags for generation directives. Â The Cog VMMaker uses Object>>perform:with:with:with:with: & Object>>perform:with:with:with:with:with: during simulation, and Collection>>#fold: & SquenceableCollection>>#copyUpThrough: during generation. Â Object>>inline: and Object var:declareC:, which are mispackaged in Kernel in Squeak 4.1 are obsolete (method tags being used instead) and have been removed. I have changed Integer>>hex and Integer>>hex8 back to their original semantics as of 3.8. Â Backward compatibility is important and one can easily add new selectors if one wants different functionality. Â VMMaker was here first ;) >> >> >> Tarball: >> >> The top-level directories in the tarball are >> >> Â Â Â src >> Â Â Â Â Â Â Â the tree for the Cog generated sources including all plugins >> Â Â Â stacksrc/vm >> Â Â Â Â Â Â Â the directory containing the Stack VM source (plugins can be taken from above) >> Â Â Â platforms >> Â Â Â Â Â Â Â the usual svn platform tree but including Cog specific changes such as the heartbeat >> Â Â Â processors >> Â Â Â Â Â Â Â the tree containing simulation support code, i.e. the bochs C++ x86 simulation library, along with a potential ARM, PowerPC & MIPS simulator, Skeye. >> >> Â Â Â image >> Â Â Â Â Â Â Â the Cog-prepared Squeak 4.1 VMMaker image >> Â Â Â scripts >> Â Â Â Â Â Â Â some svn scripts to revert unchanged plugins that haven't really changed >> >> Â Â Â cygwinbuild >> Â Â Â Â Â Â Â the win32 build directory >> Â Â Â winbuild >> Â Â Â Â Â Â Â the old win32 build directory for minnow gcc 2.95. Â Not entirely obsolete as the cygwin build as yet fails to generate a functional FFIPlugin >> Â Â Â macbuild >> Â Â Â Â Â Â Â the CoreVM.xcodeproj and support build projects for Mac OS X 10.5 or better >> Â Â Â unixbuild >> Â Â Â Â Â Â Â the build directory for linux >> >> >> Building Cog: >> >> Each build directory above contains a HowToBuild file that describes building in more detail. Â The build directories only contain Cogit makefiles. Â f you want to build a Stack VM you're on your own but this is very close to the existing Squeak VM build. >> >> >> Status: >> The Cogit VM has been our sole VM at Teleplace for nearly a year. Â We do occasionally find bugs and there are almost certainly areas of functionality that we have not touched (for example I know that co-routining does not yet work). Â If you find a bug please try and create a reproducible test case and let me know. Â I can't promise to take a look or fix it but I am motivated to do so and will try my best as time allows. Â Better still if you find and fix bugs be sure to let me know. >> >> License (MIT): >> All contributions from Teleplace in this release are >> Copyright (c) 2010 Teleplace, Inc. >> >> Permission is hereby granted, free of charge, to any person obtaining a copy >> of this software and associated documentation files (the "Software"), to deal >> in the Software without restriction, including without limitation the rights >> to use, copy, modify, merge, publish, distribute, sublicense, and/or sell >> copies of the Software, and to permit persons to whom the Software is >> furnished to do so, subject to the following conditions: >> >> The above copyright notice and this permission notice shall be included in >> all copies or substantial portions of the Software. >> >> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR >> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE >> AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER >> LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, >> OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN >> THE SOFTWARE. >> >> Eliot Miranda >> June 2010 >> >> > > > -- Lukas Renggli www.lukas-renggli.ch

4 4

[Pharo-project] OpenDBX for dbase files
by Facundo Vozzi June 21, 2010

June 21, 2010

Hi at all, can I used openDBX for read dbase (.dbf) files or I need try with xbase ? regards, Facu

4 9

[Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1
by Torsten Bergmann June 21, 2010

June 21, 2010

Hi Adrian, > still I think arguments like this do not help in finding the best >solution, The "egg thing" was not meant as argument, I apologize if this moved the whole discussion off-topic. My arguments were listed here [1] so can we please continue to discuss on these. >The rationale for moving the help menu was basically what I said before >- it was a single lonely item inside a submenu (we didn't know that Pharo >adds more submenus so this point only holds for PharoCore) OK, we now know: - it is a single item in Pharo core - it is a multiple icon in Pharo-dev ("Pharo") since more items are added - an "end user" typically uses Pharo-dev > My current point of view is that since we don't have a helpful help system > (yet) In Pharo Core we currently offer: - the help on help itself (which should be enough for core since we typically ship additional stuff in Pharo/Pharo-dev) There is more in "Pharo": - Welcome Workspace - ProfStef - HelpBrowser - with a loaded book for Pharo including a full browsable API as Stef wanted. - a help book for ScriptManager - the help on help And yes it needs more work but this is independent from the discussion to find a (root) place and make Help accessible >it is not really important that the help menu is at the top level. This is something I dont buy for three reasons (sorry for repeating my thoughts): - Getting "Help" is in almost any application I know of easily accessible at the root level and not hidden in another menu. Look at Firefox, Linux, Opera, ... at least on Win/Linux. - if you write a commercial app using Pharo as RCP then you want to provide Help (menu) but you may have no/wish no "System" menu - If you argue about having it at the top level only under the condition that the content gets better then why wait until the content gets better and confuse people at that point in time? Can't we just put it where we want it and work on better content? - I think we can agree that we dont want to have "System -> Help" in Core and root "Help" menu in Pharo to have them in sync - Ask a newbie to find help (I tried with a non-Smalltalk friend today and he also didnt expect it under "System"). He also said it would be better to just have "Help". Therefore I would vote to better move "Debug" away from the root level. >On another note, I don't agree with you that we should not move menus >around. If I hadn't carefully reorganized the menus of Pharo two years >ago, our menus would still be the same mess as in a previous Squeak >version. Of course stability is good, but it should not hinder us to clean >up and optimize. Moving a menu item to a better place may be annoying at >first but is quickly amortized. Again: I'm not agains menu moving to clean things up (especially the bloated Squeak menus) But currently we discuss about a good place for the help menu and you suggested to keep it under System and (if better content is available) move it. But this has nothing to do with cleanup. At which point in time will you move it? How do you measure the quality of the content? Let us think about the best place today, nail it down and improve content constantly. Nothing more. Bye T. - the help browser does not provide (much) content yet and hence is of no big help at the moment [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-June/028287.html -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

4 7

Re: [Pharo-project] [squeak-dev] Re: Using WebClient
by GermÃ¡n Arduino June 21, 2010

June 21, 2010

Unfortunately the customer cancelled the project (He selected an automation solution using ActiveX, but automating the IE. My proposal was talking directly with the http server and make a service and so, but well....are the business :) ). Anyway I got very interested by this topic and will try to give a try to the implementation of the post method using multipart boundaries when time permit (This topic is already on my near-to-infinite-todo list). Cheers. GermÃ¡n. 2010/6/2 GermÃ¡n Arduino <garduino(a)gmail.com>: > Hi Andreas: > > Thanks by the comments. > > I will continue with the multipart stuff, because this may become a > payed work for a local customer. > > Indeed I could do the job with other tools but in most of cases that > means install a gazillion of different pieces of software of third > parts that are complex to make work. I prefer to develop my own > solution, even with a bit more of work, but completeley Smalltalk. > Then I can deploy on the customer a self containded service that I can > extend as the customer need. > > I'm now reading about multipart/form-data enctype and will try to > develop this feature for WebClient (if the customer don't cancel the > project). > > Will send the news. > > Cheers. > GermÃ¡n. >

1 1

[Pharo-project] Autotest (TDD), request for comments
by laurent laffont June 21, 2010

June 21, 2010

Hi, Autotest is a live testing tool (similar too Ruby Autotest, but the Smalltalk way, more dynamic). Autotest automatically runs tests related to the methods you edit. Screencast to see it in action: http://lolgzs.free.fr/pharo/autotest3.mpeg Autotest uses the following heuritics to find the tests to run: - if the method is a test, runs it - it the method is a test setUp or tearDown, run all the tests of the TestCase - else find all senders which are tests in the same package and runs them (it detects different packages that are related, for example ProfStef-Core and ProfStef-Test) To activate the Autotest dashboard: - open the settings browser - go under System - check "Show Autotest Dashboard" option To load it: Gofer new squeaksource: 'Autotest'; package: 'Autotest'; load HelpSystem book included. I would like to know what needs enhancements, what to add (and to remove :) and whether you would use it or not (and why). Thanks for feedback. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

4 7

[Pharo-project] Where is everyone? Watching the world cup?
by Miguel Enrique CobÃ¡ MartÃnez June 21, 2010

June 21, 2010

I haven't received any email from pharo mailing list, even if the archives in the inria mailman interface show some activity (although less than usual). So, there was some change in the mailman configuration that I'm not receiving anymore messages? Someone sees the same problem? I even tried to register again in the mailman page, but never received the confirmation email. Someone? Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

3 3

[Pharo-project] Pharo book TableLayout tutorial
by laurent laffont June 21, 2010

June 21, 2010

Hi, I've added a tutorial on TableLayout http://book.pharo-project.org/book/GUI/PolymorphTutorial/TableLayout/ which follows the one on Proportional Layout. Again, thanks for feedback and English check. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

2 2

Re: [Pharo-project] [Pharo-users] Writing extensions
by Mariano Martinez Peck June 21, 2010

June 21, 2010

On Mon, Jun 21, 2010 at 12:32 PM, Bob Cowdery <bob(a)bobcowdery.plus.com>wrote: > Hi Mariano > > Thanks for the links. I managed to dig out my old code and found some of > the links, enough for me to write the slang and convert to C. Now I need > some header files for the build and presumable a library to link > which headers? I am a vm newbie, so I cc'ed squeak-vm mailing list. They may help you much more than me. Cheers Mariano > against. I would appreciate a pointer to those as it's not obvious from > the links where to get those from. > > Regards > Bob > > Mariano Martinez Peck wrote: > > Hi Bob and welcome. There are two possibiities I know to > > write/communicate to C: > > > > - The FFI plugin is intended to call external libraries from Smalltalk > > http://wiki.squeak.org/squeak/1414 > > http://forum.world.st/FFI-Documentation-td2225148.html#a2225148 > > > > - Write your own VM primitives > > http://wiki.squeak.org/squeak/356 > > http://wiki.squeak.org/squeak/3336 > > http://wiki.squeak.org/squeak/6102 > > > > Probably there are much more links, but maybe this is enough to > > remember you what you used. > > > > Let us know > > > > Mariano > > > > On Mon, Jun 14, 2010 at 9:02 PM, Bob Cowdery <bob(a)bobcowdery.plus.com > > <mailto:bob@bobcowdery.plus.com>> wrote: > > > > Hi all, > > > > I played with Squeak about 4 years ago and I built some extensions > > in C. > > I would like to do the same again with Pharo and I have a big lump > > of C > > I would like to interface to. I can't actually remember what I did > > before and can't seem to find the tutorial I used. Could somebody > > point > > me in the right direction please. > > > > Thanks > > Bob > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > <mailto:Pharo-users@lists.gforge.inria.fr> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Pharo-users mailing list > > Pharo-users(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

1 1