October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Newbie question: Connection to SQLite DB

by Mariano Martinez Peck

On Mon, Oct 4, 2010 at 10:23 PM, nullPointer <epicfan(a)gmail.com> wrote: > > > Mariano Martinez Peck wrote: > > > > > >> Anything, I need OpenDBX for use Sqlite3 project? ( > >> http://squeaksource.com/@7SFD7f008dKbC-Yt/rKzITl0- > >> http://squeaksource.com/@7SFD7f008dKbC-Yt/rKzITl0- ) I donÂ´t need use > >> glorp for the work; is for a very dummy DB. > >> > >> > > I don't get this links....what did you want to link? > > > > Is a project on SqueakSource for connect to Sqlite DBs. Excuse me for the > bad link. > http://www.squeaksource.com/SQLite.html > > That libs work without SqueakDBX, but obviously needs FFI. Works on Windows > without problems, but in MACOSX donÂ´t found any table on DB... :( > I will try a nice shoot: In sqlite, the database is a "file". So, in windows, you database can be "c:/windows/mariano/sqlite.db". However, if sqlite doesn't find the database, sometime (I think that depending which funcion the driver is calling) Sqlite creates a database IN MEMORY. So...MAYBE, you are using in Mac the same PATH you used in Windows, which fails, then creates an in memory database, and that explains why you don't see your tables. ok....if it were that, you own me a beer :) cheers mariano > > Many thanks for the help. > > -- > View this message in context: > http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p295… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 10, 2010

Re: [Pharo-project] [Pharo-users] could not search contents at http://book.pharo-project.org

by Mariano Martinez Peck

Thanks! I can reproduce. Doru can you help us? Thanks Mariano On Thu, Oct 7, 2010 at 10:40 PM, Bernardo Ezequiel Contreras < vonbecmann(a)gmail.com> wrote: > Hi All, > > Description: > Could not search contents at http://book.pharo-project.org. > I would like to search some expression in the contents of the book. > > Steps to reproduce: > * goto to http://book.pharo-project.org > * click on main image > * add any string on search contents and press Enter > Actual Result: > Seaside Walkback Error: subscript is out of bounds: 8218Expected Result: > a list of results that matches your input string > > > Thanks, > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

Oct. 10, 2010

Re: [Pharo-project] 12186 image quit problem

by Pavel Krivanek

On Sun, Oct 10, 2010 at 10:09 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > > > On Fri, Oct 8, 2010 at 7:40 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> > >> > >> > On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek < >> pavel.krivanek(a)gmail.com> >> > wrote: >> >> >> >> >> >> On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >>> >> >>> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >> >>> > Hi Marcus, >> >>> > is that really all what happened between 12172 and 12186? >> >>> > >> >>> > update12186 >> >>> > Issue 3071: fixing timestamp tests >> >>> > Issue 3068: Non portable SmalltalkImage>>platformName >> >>> > deprecationWarning >> >>> > Issue 3063: removing explain >> >>> > Issue 3039: There should not be any configuration on Core >> >>> > It doesn't explain the problems with VM versions and in 12186 I >> cannot >> >>> > build >> >>> > the PharoKernel (it hangs without error in unload phase) >> >>> > -- Pavel >> >>> > >> >>> please , tell me if it keep hanging after you doing: >> >>> >> >>> WeakArray restartFinalizationProcess. >> >>> >> >>> it seems like a deadlock with WeakArray's FinalizationLock or >> >>> FinalizationSemaphore. >> >> >> >> it hangs for me... >> >> -- Pavel >> > >> > with the MCMethodDefinition>>shutdown hack it work well >> >> so, at least we know what causing it. >> >> Now i wonder, what may cause that >> WeakArray classPool at: #FinalizationLock >> get locked by some other process and not released anymore? >> >> > if I replace critical:ifError: by critical:ifLocked: in WeakArray >> > removeWeakDependent:, it shows that it is really locked. I can reproduce it > everytime. Any idea how can I determine who locked it? > > -- Pavel > It collides with HostSystemMenusProxy class >> unregister this is the call stack: [caught := true. self wait. blockValue := mutuallyExcludedBlock value] in Semaphore>>critical: BlockClosure>>ensure: Semaphore>>critical: Semaphore>>critical:ifError: WeakRegistry>>protected: WeakRegistry>>remove:ifAbsent: HostSystemMenusProxy class>>unregister: HostSystemMenusProxy>>unregister HostSystemMenusProxy>>destroyEveryThing [self destroyEveryThing] in HostSystemMenusProxy>>finalize BlockClosure>>on:do: BlockClosure>>ifError: HostSystemMenusProxy>>finalize WeakFinalizerItem>>finalizeValues [:finItem | finItem finalizeValues] in [valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues]] in WeakRegistry>>finalizeValues WeakIdentityKeyDictionary(WeakKeyDictionary)>>expiredValuesDo: [valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues]] in WeakRegistry>>finalizeValues [mutuallyExcludedBlock value] in [blockValue := [mutuallyExcludedBlock value] ifError: [:msg :rcvr | hasError := true. errMsg := msg. errRcvr := rcvr]] in Semaphore>>critical:ifError: BlockClosure>>on:do: BlockClosure>>ifError: [blockValue := [mutuallyExcludedBlock value] ifError: [:msg :rcvr | hasError := true. errMsg := msg. errRcvr := rcvr]] in Semaphore>>critical:ifError: [caught := true. self wait. blockValue := mutuallyExcludedBlock value] in Semaphore>>critical: BlockClosure>>ensure: Semaphore>>critical: Semaphore>>critical:ifError: WeakRegistry>>protected: WeakRegistry>>finalizeValues [:weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]] in [WeakFinalizationList checkTestPair. FinalizationDependents do: [:weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] in WeakArray class>>finalizationProcess WeakArray(SequenceableCollection)>>do: [WeakFinalizationList checkTestPair. FinalizationDependents do: [:weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] in WeakArray class>>finalizationProcess [mutuallyExcludedBlock value] in [blockValue := [mutuallyExcludedBlock value] ifError: [:msg :rcvr | hasError := true. errMsg := msg. errRcvr := rcvr]] in Semaphore>>critical:ifError: BlockClosure>>on:do: BlockClosure>>ifError: [blockValue := [mutuallyExcludedBlock value] ifError: [:msg :rcvr | hasError := true. errMsg := msg. errRcvr := rcvr]] in Semaphore>>critical:ifError: [caught := true. self wait. blockValue := mutuallyExcludedBlock value] in Semaphore>>critical: BlockClosure>>ensure: Semaphore>>critical: Semaphore>>critical:ifError: WeakArray class>>finalizationProcess [self finalizationProcess] in WeakArray class>>restartFinalizationProcess [self value. Processor terminateActive] in BlockClosure>>newProcess -- Pavel

Oct. 10, 2010

Re: [Pharo-project] Getting my head around low space

by Max Leske

Thanks everyone for the suggestions! I'll give the -memory option a try, using 1 GB. I'll report back. Max On 10.10.2010, at 06:51, John M McIntosh wrote: > It's fairly clear: " the Mac VM has an option -memory" > no -mmap > > use it or set the info.plist setting of SqueakMaxHeapSize. > You can in theory set values up to 4GB on a 4.2.x VM or 5.7.x > Might make lights dim and core dump on a 5.8.x VM, please try... > Obviously you have to actually use the 4GB of memory. > > However I suspect asking for anything close to or over 5.8GB on a 4.2.x and 5.8.x VM won't fly. > Should work with a 5.7.x VM > > > On 2010-10-09, at 8:14 PM, Levente Uzonyi wrote: > >> On Sat, 9 Oct 2010, Max Leske wrote: >> >>> I'm actually working on a mac, so that shouldn't be the problem. >>> So your proposition to use -mmap would be unix specific? Is the option available on mac? >> >> I don't have a Mac, but you can easily check it by starting an image with "-mmap 64m", then allocating a 64MB array in the image. If it fails, then the switch works, otherwise not. >> >> >> Levente >> >>> >>> Thanks, >>> Max >>> >>> >>> On 09.10.2010, at 21:34, Levente Uzonyi wrote: >>> >>>> On Sat, 9 Oct 2010, Adrian Lienhard wrote: >>>> >>>>> The unix VM and apparently also the Mac VM has an option -memory that allows you to set a heap size: >>>>> >>>>> [adrian:/Applications/Squeak 4.2.3beta1U.app/Contents/MacOS] ./Squeak\ VM\ Opt -help >>>>> Usage: ./Squeak VM Opt [<option>...] [<imageName> [<argument>...]] >>>>> ./Squeak VM Opt [<option>...] -- [<argument>...] >>>>> >>>>> Common <option>s: >>>>> -help print this help message, then exit >>>>> -memory <size>[mk] use fixed heap size (added to image size) >>>>> -pathenc <enc> set encoding for pathnames (default: macintosh) >>>>> -headless run in headless (no window) mode (default: false) >>>>> >>>>> Notes: >>>>> <imageName> defaults to `Squeak.image'. >>>>> If `-memory' is not specified then the heap will grow dynamically. >>>>> <argument>s are ignored, but are processed by the Squeak image. >>>>> The first <argument> normally names a Squeak `script' to execute. >>>>> Precede <arguments> by `--' to use default image. >>>> >>>> This is ok for Mac, but the unix VM takes different arguments. >>>> >>>> >>>> Levente >>>> >>>>> >>>>> >>>>> HTH, >>>>> Adrian >>>>> >>>>> On Oct 9, 2010, at 18:01 , Max Leske wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> I'm having trouble with low space warnings in Pharo. Is there a source on how much memory the image can get from the OS? Is there maybe a way to up that limit? I am loading a lot of data into the image and the limit at the moment seems to be around 500 MB. >>>>>> >>>>>> Thanks for any ideas. >>>>>> >>>>>> Cheers, >>>>>> Max >>>>>> _______________________________________________ >>>>>> 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 > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

Re: [Pharo-project] Getting my head around low space

by Max Leske

Hey Bill No, I hadn't thought about that. But I guess It wouldn't help me much anyway since what effectively eats memory is the data I store in the image; I reuse my objects as much as possible. Basically, I'm storing thousands of very short strings in ByteArrays (files in a memory filesystem, using Colin Putney's Filesystem framework). Writing the same data to disk gives me around 500 MB because of the massive overhead per file (there's around 50 bytes per file and each file allocates 4 KB). I guess it would be less in the image but let's just say I'll need around 1 GB probably. Max On 09.10.2010, at 23:14, Schwab,Wilhelm K wrote: > Max, > > You are probably way ahead of this (and keep pushing the envelope<g>), but you do know about #release, right? A couple of weeks ago I ran some fairly intense calculations that resulted in low space conditions. Sending #release to the participants (and implementing it correctly) fixed it. > > One thing that IMHO has never worked well, or at least not as well as advertised, in Dolphin is relying on its finalization "water mark" to trigger cleanup of finalizable objects on need. Most notably, I found it necessary to explicitly clean up ODBC statements to avoid errors/crashes. > > How much memory do you need? May I ask for what? 32 or 64 bit? > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Max Leske [maxleske(a)gmail.com] > Sent: Saturday, October 09, 2010 12:01 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Getting my head around low space > > Hi > > I'm having trouble with low space warnings in Pharo. Is there a source on how much memory the image can get from the OS? Is there maybe a way to up that limit? I am loading a lot of data into the image and the limit at the moment seems to be around 500 MB. > > Thanks for any ideas. > > Cheers, > Max > _______________________________________________ > 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

Oct. 10, 2010

Re: [Pharo-project] 12186 image quit problem

by Pavel Krivanek

On Fri, Oct 8, 2010 at 7:40 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > > > > > > On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com > > > > wrote: > >> > >> > >> On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >>> > >>> 2010/10/8 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > >>> > Hi Marcus, > >>> > is that really all what happened between 12172 and 12186? > >>> > > >>> > update12186 > >>> > Issue 3071: fixing timestamp tests > >>> > Issue 3068: Non portable SmalltalkImage>>platformName > >>> > deprecationWarning > >>> > Issue 3063: removing explain > >>> > Issue 3039: There should not be any configuration on Core > >>> > It doesn't explain the problems with VM versions and in 12186 I > cannot > >>> > build > >>> > the PharoKernel (it hangs without error in unload phase) > >>> > -- Pavel > >>> > > >>> please , tell me if it keep hanging after you doing: > >>> > >>> WeakArray restartFinalizationProcess. > >>> > >>> it seems like a deadlock with WeakArray's FinalizationLock or > >>> FinalizationSemaphore. > >> > >> it hangs for me... > >> -- Pavel > > > > with the MCMethodDefinition>>shutdown hack it work well > > so, at least we know what causing it. > > Now i wonder, what may cause that > WeakArray classPool at: #FinalizationLock > get locked by some other process and not released anymore? > > if I replace critical:ifError: by critical:ifLocked: in WeakArray >> removeWeakDependent:, it shows that it is really locked. I can reproduce it everytime. Any idea how can I determine who locked it? -- Pavel

Oct. 10, 2010

Re: [Pharo-project] Getting my head around low space

by John M McIntosh

It's fairly clear: " the Mac VM has an option -memory" no -mmap use it or set the info.plist setting of SqueakMaxHeapSize. You can in theory set values up to 4GB on a 4.2.x VM or 5.7.x Might make lights dim and core dump on a 5.8.x VM, please try... Obviously you have to actually use the 4GB of memory. However I suspect asking for anything close to or over 5.8GB on a 4.2.x and 5.8.x VM won't fly. Should work with a 5.7.x VM On 2010-10-09, at 8:14 PM, Levente Uzonyi wrote: > On Sat, 9 Oct 2010, Max Leske wrote: > >> I'm actually working on a mac, so that shouldn't be the problem. >> So your proposition to use -mmap would be unix specific? Is the option available on mac? > > I don't have a Mac, but you can easily check it by starting an image with "-mmap 64m", then allocating a 64MB array in the image. If it fails, then the switch works, otherwise not. > > > Levente > >> >> Thanks, >> Max >> >> >> On 09.10.2010, at 21:34, Levente Uzonyi wrote: >> >>> On Sat, 9 Oct 2010, Adrian Lienhard wrote: >>> >>>> The unix VM and apparently also the Mac VM has an option -memory that allows you to set a heap size: >>>> >>>> [adrian:/Applications/Squeak 4.2.3beta1U.app/Contents/MacOS] ./Squeak\ VM\ Opt -help >>>> Usage: ./Squeak VM Opt [<option>...] [<imageName> [<argument>...]] >>>> ./Squeak VM Opt [<option>...] -- [<argument>...] >>>> >>>> Common <option>s: >>>> -help print this help message, then exit >>>> -memory <size>[mk] use fixed heap size (added to image size) >>>> -pathenc <enc> set encoding for pathnames (default: macintosh) >>>> -headless run in headless (no window) mode (default: false) >>>> >>>> Notes: >>>> <imageName> defaults to `Squeak.image'. >>>> If `-memory' is not specified then the heap will grow dynamically. >>>> <argument>s are ignored, but are processed by the Squeak image. >>>> The first <argument> normally names a Squeak `script' to execute. >>>> Precede <arguments> by `--' to use default image. >>> >>> This is ok for Mac, but the unix VM takes different arguments. >>> >>> >>> Levente >>> >>>> >>>> >>>> HTH, >>>> Adrian >>>> >>>> On Oct 9, 2010, at 18:01 , Max Leske wrote: >>>> >>>>> Hi >>>>> >>>>> I'm having trouble with low space warnings in Pharo. Is there a source on how much memory the image can get from the OS? Is there maybe a way to up that limit? I am loading a lot of data into the image and the limit at the moment seems to be around 500 MB. >>>>> >>>>> Thanks for any ideas. >>>>> >>>>> Cheers, >>>>> Max >>>>> _______________________________________________ >>>>> 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 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Oct. 10, 2010

Re: [Pharo-project] Getting my head around low space

by Levente Uzonyi

On Sat, 9 Oct 2010, Max Leske wrote: > I'm actually working on a mac, so that shouldn't be the problem. > So your proposition to use -mmap would be unix specific? Is the option available on mac? I don't have a Mac, but you can easily check it by starting an image with "-mmap 64m", then allocating a 64MB array in the image. If it fails, then the switch works, otherwise not. Levente > > Thanks, > Max > > > On 09.10.2010, at 21:34, Levente Uzonyi wrote: > >> On Sat, 9 Oct 2010, Adrian Lienhard wrote: >> >>> The unix VM and apparently also the Mac VM has an option -memory that allows you to set a heap size: >>> >>> [adrian:/Applications/Squeak 4.2.3beta1U.app/Contents/MacOS] ./Squeak\ VM\ Opt -help >>> Usage: ./Squeak VM Opt [<option>...] [<imageName> [<argument>...]] >>> ./Squeak VM Opt [<option>...] -- [<argument>...] >>> >>> Common <option>s: >>> -help print this help message, then exit >>> -memory <size>[mk] use fixed heap size (added to image size) >>> -pathenc <enc> set encoding for pathnames (default: macintosh) >>> -headless run in headless (no window) mode (default: false) >>> >>> Notes: >>> <imageName> defaults to `Squeak.image'. >>> If `-memory' is not specified then the heap will grow dynamically. >>> <argument>s are ignored, but are processed by the Squeak image. >>> The first <argument> normally names a Squeak `script' to execute. >>> Precede <arguments> by `--' to use default image. >> >> This is ok for Mac, but the unix VM takes different arguments. >> >> >> Levente >> >>> >>> >>> HTH, >>> Adrian >>> >>> On Oct 9, 2010, at 18:01 , Max Leske wrote: >>> >>>> Hi >>>> >>>> I'm having trouble with low space warnings in Pharo. Is there a source on how much memory the image can get from the OS? Is there maybe a way to up that limit? I am loading a lot of data into the image and the limit at the moment seems to be around 500 MB. >>>> >>>> Thanks for any ideas. >>>> >>>> Cheers, >>>> Max >>>> _______________________________________________ >>>> 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 >

Oct. 10, 2010

Re: [Pharo-project] Xtreams : first embryonary port on Squeak

by Schwab,Wilhelm K

FWIW, SIF might help you: http://www.pocketsmalltalk.com/sif/ I have put a lot of code through it in the past couple of years. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Saturday, October 09, 2010 6:33 PM To: The general-purpose Squeak developers list; Pharo Development; vwnc(a)cs.uiuc.edu Subject: [Pharo-project] Xtreams : first embryonary port on Squeak So, I started a quick port of VW Xtreams to Squeak this evening. Only the Xtreams-Core and the trivial Xtreams-Terminals (no file/pipe/socket/pointer). You'll find code at http://www.squeaksource.com/XTream. My previous experimental Xtream project has been renamed SqueaXTream to reduce confusion, but still sits in the same project. Please find my report below. cheers Nicolas --------------------- REPORT --------------------- THE CONTENTS: This first port is made of 3 packages - Xtreams-Core - Xtreams-Terminals - Xtreams-VWCompatible Plus 2 tests - Xtreams-CoreTests - Xtreams-TerminalsTests Please notice I removed one hyphen from test package names for MC compatibility. THE PROCEDURE: I didn't use FileOut30 not any more advanced tool, but just a simple copy/paste strategy. This gave me a chance to do a fast review of code. For porting the future evolutions of VW Xtreams, more advanced tools will be necessary, the manual approach does not scale. THE MODIFICATIONS: The changes I made are quite restricted, which indicates that Xtreams is not that hard to port. Main changes are due to lack of namespace in Squeak: - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) - I added XTPools, a SharedPool for holding the single Xtreams namespace variable DefaultBufferSize - I transformed class SharedVariables into class variables and added proper class side initialization for these in XTWriteStream For the rest, I tried to not change Xtreams contents. but rather did implement VW compatible messages when possible in the Xtreams-VWCompatible package when they did not exist in Squeak. These message are a full rewrite and are also released under MIT license. The few exceptions are: - I modified originator -> self originator in XTIncomplete. - I changed the senders of #newInFixedSpace: to rather send an #error: 'not implemented in Squeak' in XTRecyclingBuffer - I replaced #waitIfCurtailedSignal/#signal with a #critical: section in XTRecyclingBuffer - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests A DISCUSSION OF TECHNICAL DETAILS: I first attempted to replace #growToAtLeast: with #grownBy: because Squeak become: is notoriously inefficient. But obviously, this did not work, the tests rely on destination preserving its identity. This clearly is going to degrade micro benchmarks when the destination collection capacity is not well adjusted in advance. I think we should discuss this particular point. Is identity preservation absolutely required, or just convenient ? THE STATUS OF TESTS: Tests do not all pass. There seems to be a bug in Squeak #replace:from:to:with: when the replacement is the collection itself, moved to the right (this is with a COG VM). THE FUTURE: I will probably continue porting with reduced activity, so I invite any interested person to help. Right now, the project is world writeable, code commited here falling under MIT license. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak

by Levente Uzonyi

On Sun, 10 Oct 2010, Nicolas Cellier wrote: > So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below. Great. :) > > cheers > > Nicolas > > --------------------- REPORT --------------------- > > THE CONTENTS: > > This first port is made of 3 packages > - Xtreams-Core > - Xtreams-Terminals > - Xtreams-VWCompatible > Plus 2 tests > - Xtreams-CoreTests > - Xtreams-TerminalsTests > Please notice I removed one hyphen from test package names for MC compatibility. > > THE PROCEDURE: > > I didn't use FileOut30 not any more advanced tool, but just a simple > copy/paste strategy. > This gave me a chance to do a fast review of code. > For porting the future evolutions of VW Xtreams, more advanced tools > will be necessary, the manual approach does not scale. If you can create a diff from the VW changes, then porting "by hand" shouldn't be hard. > > THE MODIFICATIONS: > > The changes I made are quite restricted, which indicates that Xtreams > is not that hard to port. > Main changes are due to lack of namespace in Squeak: > - I added a XT prefix to every Xtreams classes (no Namespace in Squeak) > - I added XTPools, a SharedPool for holding the single Xtreams > namespace variable DefaultBufferSize > - I transformed class SharedVariables into class variables and added > proper class side initialization for these in XTWriteStream > > For the rest, I tried to not change Xtreams contents. but rather did > implement VW compatible messages when possible in the > Xtreams-VWCompatible package when they did not exist in Squeak. > These message are a full rewrite and are also released under MIT license. > The few exceptions are: > - I modified originator -> self originator in XTIncomplete. > - I changed the senders of #newInFixedSpace: to rather send an #error: > 'not implemented in Squeak' in XTRecyclingBuffer > - I replaced #waitIfCurtailedSignal/#signal with a #critical: section > in XTRecyclingBuffer > - I replaced Core.Timer after:do: with self after:do: in Xtreams-CoreTests > > A DISCUSSION OF TECHNICAL DETAILS: > > I first attempted to replace #growToAtLeast: with #grownBy: because > Squeak become: is notoriously inefficient. > But obviously, this did not work, the tests rely on destination > preserving its identity. > This clearly is going to degrade micro benchmarks when the destination > collection capacity is not well adjusted in advance. > I think we should discuss this particular point. Is identity > preservation absolutely required, or just convenient ? I've never seen a real world example where this identity preservation was useful, but it causes trouble when literals aren't immutable. IMHO the #become: send is just convenient with VW's stream implementation and it has no advantage over Squeak's approach. > > THE STATUS OF TESTS: > > Tests do not all pass. There seems to be a bug in Squeak > #replace:from:to:with: when the replacement is the collection itself, > moved to the right (this is with a COG VM). #replace:from:to:with: is not supposed to work for moves. IIRC the primitive version uses memcpy (or strncpy), so moving to the left works just because the undelying C function supports it. I used to (ab)use this feature though. Levente > > THE FUTURE: > > I will probably continue porting with reduced activity, so I invite > any interested person to help. Right now, the project is world > writeable, code commited here falling under MIT license. > >

Oct. 10, 2010