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

[Pharo-project] Symbol>>cull:

by Nicolas Cellier

We recently added #value: to Symbol to be able to use it in place of a one arg block. (1 to: 10) select: #even. It would be logical to add #cull: too, xtreams tests use this for example: output write: #[ 1 2 3 4 5 6 7 8 9 ]. self assert: ((input rejecting: #even) read: 5) = #[ 1 3 5 7 9 ] Any objection to add it in core ? (otherwise i will add it to Xtreams-VWCompatible) Nicolas

Oct. 10, 2010

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Tudor Girba

Hi, I am glad it works :). If you have further problems or questions about Glamour, it is better to address them on the moose-dev mailing list: https://www.iam.unibe.ch/mailman/listinfo/moose-dev moose-dev(a)iam.unibe.ch Cheers, Doru On 10 Oct 2010, at 14:56, Esteban Lorenzano wrote: > Oh, damn... it was 2.0-beta.4 the problem, I'm sorry, it is working ok with beta 7 > > > On 2010-10-10 09:07:16 -0300, Tudor Girba <tudor.girba(a)gmail.com> said: > >> Hi, >> I cannot reproduce this. I took a PharoDev 1.1.1 and executed: >> Gofer new >> squeaksource: 'Glamour'; >> package: 'ConfigurationOfGlamour'; >> load. >> ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. >> Opening the System Settings browser works just fine. >> Cheers, >> Doru >> On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: >>> Hi, >>> I'm loading Glamour into a PharoDev 1.1.1 >>> Gofer project repository: 'http://www.squeaksource.com/Glamour'; >>> load: 'Glamour' version: '2.0-beta.7'. >>> and then try to open the settings browser... it raises a DNU >>> Cheers, >>> Esteban >>> _______________________________________________ >>> 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 -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 10 October 2010 15:39, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > Â Â process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > +1 i am also missing: someThing ifTrue: 1 ifFalse: 0 > cheers > > Nicolas > > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

[Pharo-project] WeakRegistry>>remove: - when you'll be in trouble

by Igor Stasenko

A current implementation of this method remove: oldObject ifAbsent: exceptionBlock "Remove oldObject as one of the receiver's elements." oldObject ifNil: [ ^nil ]. ^(self protected: [ valueDictionary removeKey: oldObject ifAbsent: nil ]) ifNil: [ exceptionBlock value ] simply removes a previously registered object from registry and voila. Now lets get back to our discussion about multiple finalizers per object and using them in weak subscriptions etc. Suppose i am added a socket to weak registry, and suppose i am added a weak subscription to it. Now, if i do 'socket close' , it tells weak registry to remove it from list. And what we'll have: - socket handle is closed - socket is wiped from weak registry - but weak subscription still listed somewhere in a list of subscriptions My suggestion is, that upon #remove:, a weak registry should notify all executors that object of interest are no longer takes part in finalization scheme, so they should not count on receiving #finalize eventually. In other words: remove: oldObject ifAbsent: exceptionBlock "Remove oldObject as one of the receiver's elements." oldObject ifNil: [ ^nil ]. ^(self protected: [ | executor | executor := valueDictionary removeKey: oldObject ifAbsent: nil. executor discardFinalization. ]) ifNil: [ exceptionBlock value ] -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Esteban Lorenzano

Oh, damn... it was 2.0-beta.4 the problem, I'm sorry, it is working ok with beta 7 On 2010-10-10 09:07:16 -0300, Tudor Girba <tudor.girba(a)gmail.com> said: > Hi, > > I cannot reproduce this. I took a PharoDev 1.1.1 and executed: > > Gofer new > squeaksource: 'Glamour'; > package: 'ConfigurationOfGlamour'; > load. > ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. > > Opening the System Settings browser works just fine. > > Cheers, > Doru > > > On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: > >> Hi, >> I'm loading Glamour into a PharoDev 1.1.1 >> >> Gofer project repository: 'http://www.squeaksource.com/Glamour'; >> load: 'Glamour' version: '2.0-beta.7'. >> >> and then try to open the settings browser... it raises a DNU >> >> Cheers, >> Esteban >> >> >> >> _______________________________________________ >> 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

[Pharo-project] Compiler pedantic about ifNotNil: argument

by Nicolas Cellier

The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. Thus we cannot write this xtream sentence process ifNotNil: #terminate. When the argument is not a block, Compiler should avoid inlining and just send a normal message. cheers Nicolas

Oct. 10, 2010

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Tudor Girba

Hi, I cannot reproduce this. I took a PharoDev 1.1.1 and executed: Gofer new squeaksource: 'Glamour'; package: 'ConfigurationOfGlamour'; load. ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. Opening the System Settings browser works just fine. Cheers, Doru On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: > Hi, > I'm loading Glamour into a PharoDev 1.1.1 > > Gofer project repository: 'http://www.squeaksource.com/Glamour'; > load: 'Glamour' version: '2.0-beta.7'. > > and then try to open the settings browser... it raises a DNU > > Cheers, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

Oct. 10, 2010

[Pharo-project] OCompletion usability

by Nicolas Cellier

Hi all, Thanks to Levente, I activated OCompletion in trunk. It's nice when typing a text from scratch (like in a workspace). But when modifying an existing text, not that great. The feature I most miss is the ability to overwrite a word fragment and hit cmd+j to repeat the replacement. Would it be possible to restore this behavior ? Nicolas

Oct. 10, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

OKay, now i see what the problem: <weak registry protected> <finalize items> <HostSystemMenusProxy>>finalize> .... <HostSystemMenusProxy class>>unregister> <weak registry protected> In my WeakRegistry, a #finalize message sent while registry semaphore locked, so, in case if object in #finalize trying to manipulate with registry then it going to deadlock. Then following piece: WeakRegistry>>finalizeValues self protected: [ valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues ]. ]. should be rewritten as: | expired | expired := OrderedCollection new. self protected: [ valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] ]. expired do: #finalizeValues. But either way, HostSystemMenusProxy should not attempt remove itself from registry during #finalize (and causing a deadlock), since its pointless. -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

[Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Esteban Lorenzano

Hi, I'm loading Glamour into a PharoDev 1.1.1 Gofer project repository: 'http://www.squeaksource.com/Glamour'; load: 'Glamour' version: '2.0-beta.7'. and then try to open the settings browser... it raises a DNU Cheers, Esteban

Oct. 10, 2010

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

by Nicolas Cellier

2010/10/10 Levente Uzonyi <leves(a)elte.hu>: > On Sun, 10 Oct 2010, Nicolas Cellier wrote: > >> >> 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 > OK, since we use memcpy rather than memmove in Squeak VM, I implemented the trivial work around - move through a motionBuffer temporary copy. I now have a single test failing, XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be due to my #after:do: simplistic implementation. Messing with #fork in SUnit TestCase is tricky, and I need help on this point. Nicolas

Oct. 10, 2010

[Pharo-project] Adding a new font in System like DejaVu fonts

by nullPointer

Now I know is possible add a new font, for use cross platform like DejaVu. I know Juan Vuletich did that but I donÂ´t know found the place of that is explained. Is heard do that? takes very space of image when the font is added? Many thanks for answers. -- View this message in context: http://forum.world.st/Adding-a-new-font-in-System-like-DejaVu-fonts-tp29701… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 10, 2010

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

by Nicolas Cellier

2010/10/10 Michael Lucas-Smith <michael.lucassmith(a)gmail.com>: >> >> 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 ? > > Which tests? I'd be in favor of removing that assumption. > > Michael > This is in: CollectionReadingWritingTest>>setUp | buffer | buffer := XTElasticBuffer on: ByteArray new. input := buffer reading. output := buffer writing. The expectation is that the buffer will be shared between input and output. If output modifies a copy of buffer, then the tests fail (input is empty or partial or too long if WriteStream>>#close did not perform a #become: ) Nicolas

Oct. 10, 2010

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

by Tudor Girba

Hi, Unfortunately, I cannot help much at this moment. The problem is due to a bug in Pier that crashes when there is a strange character in one of the pages. I believe this was fixed at some point, but I am not sure. Someone would have to update the Pier image. Cheers, Doru On 10 Oct 2010, at 11:53, Mariano Martinez Peck wrote: > 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: 8218 > > Expected 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Oct. 10, 2010

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

by nullPointer

Not exactly but almost..... In Windows the image is in same directory of exe. In MacOSX the image is on different path of exe. When I did open the connection I did pass only the name of existent file DB, for example, "MyDB.sqlite". If the file not exists and not complete path is specified then is created in same executable directory. In windows that behavior was correct for me but in MACOSX a new BD file was saved on general Applications folder. I donÂ´t view any table because was a new DB file... I donÂ´t know if I explain good, but was a sad error :( Anyway a sample connection to Sqlite is easy with Sqlite project, and I believe is possible include a very easy mapping mechanism. ItÂ´s only for a small project and probes. Many thanks for the help and excuse me the annoyances :) -- View this message in context: http://forum.world.st/Newbie-question-Connection-to-SQLite-DB-tp2954195p297… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 10, 2010

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