January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] cogwin/Croquet (Win7) + Moose + very large models = crash (out of Memory)

by StÃ©phane Ducasse

why jenkins is not building the vm windows? Stef On Jan 25, 2012, at 11:18 PM, Mariano Martinez Peck wrote: > I think Igor fixed that for the Windows VM, but such changes were not integerated in Eliot VMs, but rather in the branch of Git. > But since the Jenkins is not building Windows VM, I have no idea where you can get such a VM. > > Cheers > > On Wed, Jan 25, 2012 at 11:12 PM, Hani Abdeen <hani.abdeen(a)gmail.com> wrote: > > > On 25 January 2012 23:05, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > Hani Abdeen wrote > > > > Hello, > > > > I'm using cogwin/Croquet VM (last version > > http://www.mirandabanda.org/files/Cog/VM/VM.r2522/) on windows7, > > and today I had this probelm: when the size of the pharo image become so > > large the VM crashes with reason 'out of memory'. > > The same problem with previous versions of cogwin. > > Note that I use a PC with 8G of RAM, so it's really damage to have such a > > problem. > > > > Any idea about another VM working well on Windows and does not have such > > an > > issues? > > Any urgent solution? > > > > Thanks, > > Hani > > > > From this thread: > http://forum.world.st/experience-with-large-images-td4101765.html > > It seems that on windows the size of the image by default is limited to > 500MB in RAM. I don't know if you can change it or not. Linux/Mac is > limited to 2GB. Can you try your experiments on a Mac? > > Unfortunately no, I've not Mac, and the company for which I'll use Moose on their software, Tomorrow morning :(, do not use Mac. > > > > > -- > View this message in context: http://forum.world.st/cogwin-Croquet-Win7-Moose-very-large-models-crash-out… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 26, 2012

Re: [Pharo-project] Beginner question about "self" in block

by StÃ©phane Ducasse

this explains in PBE2 Stef On Jan 25, 2012, at 11:04 PM, Garret Raziel wrote: > Ok, so it automaticaly uses longest possible message?

Jan. 26, 2012

[Pharo-project] Fwd: [Moose-dev] cogwin/Croquet (Win7) + Moose + very large model = crash (out of Memory)

by StÃ©phane Ducasse

Begin forwarded message: > From: Hani Abdeen <hani.abdeen(a)gmail.com> > Subject: [Moose-dev] Re: cogwin/Croquet (Win7) + Moose + very large model = crash (out of Memory) > Date: January 26, 2012 8:52:15 AM GMT+01:00 > To: Moose-related development <moose-dev(a)iam.unibe.ch> > Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> > > Hi Doru, > > the image size starts at 400M, before doing anything on the model. > Now, as I start manipulating the model and sending navigation queries, trying to create an Arki report about the model, the image size apparently exceed 500M and the VM crashes! > For more information I enclosed the header of the crash.dmp file. > > Cheers, > Hani > > --------------------------------------------------------------------- > Fri Jan 13 14:57:11 2012 > > > Error in the VM thread > Reason: out of memory > > > > Hardware information: > Manufacturer: Unknown > Model: Unknown > Number of processors: 4 > Page size: 4096 > > Memory Information (upon launch): > Physical Memory Size: 4194303 kbytes > Physical Memory Free: 4194303 kbytes > Page File Size: 4194303 kbytes > Page File Free: 4194303 kbytes > Virtual Memory Size: 2097024 kbytes > Virtual Memory Free: 2025868 kbytes > Memory Load: 20 percent > > Processor 0: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz > Identifier: Intel64 Family 6 Model 42 Stepping 7 > ~MHZ: 2494 > > Processor 1: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz > Identifier: Intel64 Family 6 Model 42 Stepping 7 > ~MHZ: 2494 > > Processor 2: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz > Identifier: Intel64 Family 6 Model 42 Stepping 7 > ~MHZ: 2494 > > Processor 3: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz > Identifier: Intel64 Family 6 Model 42 Stepping 7 > ~MHZ: 2494 > > Operating System: Windows 7 Ultimate (Build 7600 ) > Registered Owner: Microsoft > Registered Company: Microsoft > SP major version: 0 > SP minor version: 0 > Suite mask: 100 > Product type: 1 > > Display Information: > Graphics adapter name: Intel(R) HD Graphics Family > Primary monitor resolution: 1366 x 768 > > Device: RDPDD Chained DD > Adapter String: ??? > Bios String: ??? > Chip Type: ??? > DAC Type: ??? > Memory Size: 0xFFFFFFFF > > Driver Versions: > RDPDD: > > VM Version: Cog VM 4.0.0 (release) from Dec 1 2011 > Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > Interpreter Build: CoInterpreter VMMaker.oscog-eem.138 uuid: f9a63bdf-7bbc-4ae5-9634-ecd6fd814c9d Dec 1 2011 > Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.139 uuid: c2849383-9768-4948-b9b2-a5c22d482b07 Dec 1 2011 > > > > > On 26 January 2012 07:29, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > What does large mean in your case? I routinely work with 500MB images on Windows 7 using the same VM. > > Cheers, > Doru > > > On 25 Jan 2012, at 23:25, Hani Abdeen wrote: > > > Hello, > > > > I'm using cogwin/Croquet VM (last version http://www.mirandabanda.org/files/Cog/VM/VM.r2522/) on windows7, > > and today I had this probelm: when the size of the pharo image become so large the VM crashes with reason 'out of memory'. > > The same problem with previous versions of cogwin. > > I've only one, but very large, Java model in Moose. > > Note that I use a PC with 8G of RAM, so it's really damage to have such a problem. > > > > Any idea about another VM working well on Windows and does not have such an issues? > > Any urgent solution? > > > > Unfortunately I've not Mac and the company for which I'am going to demonstrate Moose, on their code base and Tomorrow morning do not use Mac. > > > > Thanks, > > Hani > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Jan. 26, 2012

Re: [Pharo-project] Noobs perspective on pasting example code

by Ben Coman

Thanks Milan. Something new I've learnt. However I don't think this is a conflict. While your example works from Workspace, go where you define a method and try to get the following accepted. String >> #asDate ^1 The above is not valid, so no conflict in this context. Milan Mimica wrote: > #>> already does something. Try printing "String >> #asDate". It fetches a > compiled method. > > On 26 January 2012 08:15, Ben Coman <btc(a)openinworld.com> wrote: > > >> Just a passing thought.... >> It is common convention for example methods to be presented in text using >> '>>' preceded by the class. This is obviously needed to define the >> class/method relationship outside the image, but the whole example cannot >> be pasted directly into System Browser as the '>>' is not part of the >> Smalltalk syntax for defining methods. >> For those new to Pharo going through tutorials, copy/pasting the whole of >> the presented code eg [1] returns only the error "Nothing more expected" >> which is a bit cryptic to noobs who expect to follow the example verbatim. >> Once past understanding this, it continues (for me) to be a minor >> annoyance to have to select only the text following the '>>'. >> >> I wonder whether it would be beneficial for the compiler to handle '>>' >> at the start of a method definition. The System Browser would then jump >> to the created method. As well as beneficial to those experiencing Pharo >> for the first time, this might be useful as a general shortcut such that >> when browsing one class you can define a method for another class without >> first having to browse to that class. >> >> cheers, Ben >> >> [1] >> BExp>>testBlock: aBlock >> | t | >> t := nil. >> aBlock value >> >> >> >> >> > > >

Jan. 26, 2012

[Pharo-project] DosFileDirectory class>>privateFullPathForURI: aURI [WAS] Re: [Vm-dev] Primitive failed when compiling Vm on Windows

by Mariano Martinez Peck

On Thu, Jan 26, 2012 at 12:13 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > > Hi! > > I've downloaded version 3.8 of ConfigurationOfCog on Pharo 1.4, and when > sending #topDir: to a CogWindowsConfig instance, I get a primitive failed > error: > > Guille, if you see the family of Windows confs, regarding the file paths, they usually use #msysPathFor: Check its senders as an example. Maybe we can adapt topDir to use that. But I am not sure if that's a good idea. I think several months ago I was bitten but the same problem. I would like if your change to: DosFileDirectory class>>privateFullPathForURI: aURI is correct. Because maybe we can just integerate that. anyone? > PrimitiveFailed: primitive #primCreateDirectory: in DosFileDirectory failed > 25 January 2012 7:24:30 pm > > VM: Win32 - IX86 - 5.1 - CoInterpreter VMMaker.oscog-eem.140 uuid: > 2487009c-2c13-4609-b89e-77f0e195f433 Dec 12 2011, > StackToRegisterMappingCogit VMMaker.oscog-eem.139 uuid: > c2849383-9768-4948-b9b2-a5c22d482b07 Dec 12 2011, r2522 > http://www.squeakvm.org/svn/squeak/branches/Cog > Image: Pharo1.4a [Latest update: #14296] > > DosFileDirectory(Object)>>primitiveFailed: > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > selector: #primCreateDirectory: > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(Object)>>primitiveFailed > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(FileDirectory)>>primCreateDirectory: > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > fullPath: '\\MinGW' > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(FileDirectory)>>createDirectory: > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > localFileName: '\\MinGW' > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > lPath: '\\MinGW' > localPath: '\\MinGW' > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW' > Arguments and temporary variables: > lPath: 'msys' > localPath: 'msys' > Receiver's instance variables: > pathName: FilePath('\\MinGW') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys' > Arguments and temporary variables: > lPath: '1.0' > localPath: '1.0' > Receiver's instance variables: > pathName: FilePath('\\MinGW\msys') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys\1.0' > Arguments and temporary variables: > lPath: 'home' > localPath: 'home' > Receiver's instance variables: > pathName: FilePath('\\MinGW\msys\1.0') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys\1.0\home' > Arguments and temporary variables: > lPath: 'Guille' > localPath: 'Guille' > Receiver's instance variables: > pathName: FilePath('\\MinGW\msys\1.0\home') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys\1.0\home\Guille' > Arguments and temporary variables: > lPath: 'cog' > localPath: 'cog' > Receiver's instance variables: > pathName: FilePath('\\MinGW\msys\1.0\home\Guille') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys\1.0\home\Guille\cog' > > > I followed the error up to: > > DosFileDirectory class>>privateFullPathForURI: aURI > | path | > path := aURI path unescapePercents. > > "Check for drive notation (a: etc)" > path size > 1 > ifTrue: [ > ((path at: 3) = $:) > ifTrue: [path := path copyFrom: 2 to: path size] > ifFalse: [ > "All other cases should be network path names (\\xxx\sdsd etc)" > path := '/' , path]]. > > ^path copyReplaceAll: '/' with: self slash > > Which seems not being resolving well a full path like > 'c:\something\another\directory' and is answering something like > > '\\MinGW\msys\1.0\home\Guille\cog\gpolito-cogvm' > > which then is treated as a relative path... > > I've done a temporary fix like this in my image so I can continue, but > maybe someone has a little more knowledge on this class: > > DosFileDirectory class>>privateFullPathForURI: aURI > | path | > path := aURI asString unescapePercents. > > "Check for drive notation (a: etc)" > path size > 1 > ifTrue: [ > ((path at: 2) = $:) > ifTrue: [path := path copyFrom: 1 to: path size] > ifFalse: [ > "All other cases should be network path names (\\xxx\sdsd etc)" > path := '/' , path]]. > > ^path copyReplaceAll: '/' with: self slash > > Guille > > -- Mariano http://marianopeck.wordpress.com

Jan. 26, 2012

Re: [Pharo-project] Noobs perspective on pasting example code

by Milan Mimica

#>> already does something. Try printing "String >> #asDate". It fetches a compiled method. On 26 January 2012 08:15, Ben Coman <btc(a)openinworld.com> wrote: > > Just a passing thought.... > It is common convention for example methods to be presented in text using > '>>' preceded by the class. This is obviously needed to define the > class/method relationship outside the image, but the whole example cannot > be pasted directly into System Browser as the '>>' is not part of the > Smalltalk syntax for defining methods. > For those new to Pharo going through tutorials, copy/pasting the whole of > the presented code eg [1] returns only the error "Nothing more expected" > which is a bit cryptic to noobs who expect to follow the example verbatim. > Once past understanding this, it continues (for me) to be a minor > annoyance to have to select only the text following the '>>'. > > I wonder whether it would be beneficial for the compiler to handle '>>' > at the start of a method definition. The System Browser would then jump > to the created method. As well as beneficial to those experiencing Pharo > for the first time, this might be useful as a general shortcut such that > when browsing one class you can define a method for another class without > first having to browse to that class. > > cheers, Ben > > [1] > BExp>>testBlock: aBlock > | t | > t := nil. > aBlock value > > > > -- Milan Mimica http://sparklet.sf.net

Jan. 26, 2012

[Pharo-project] Noobs perspective on pasting example code

by Ben Coman

Just a passing thought.... It is common convention for example methods to be presented in text using '>>' preceded by the class. This is obviously needed to define the class/method relationship outside the image, but the whole example cannot be pasted directly into System Browser as the '>>' is not part of the Smalltalk syntax for defining methods. For those new to Pharo going through tutorials, copy/pasting the whole of the presented code eg [1] returns only the error "Nothing more expected" which is a bit cryptic to noobs who expect to follow the example verbatim. Once past understanding this, it continues (for me) to be a minor annoyance to have to select only the text following the '>>'. I wonder whether it would be beneficial for the compiler to handle '>>' at the start of a method definition. The System Browser would then jump to the created method. As well as beneficial to those experiencing Pharo for the first time, this might be useful as a general shortcut such that when browsing one class you can define a method for another class without first having to browse to that class. cheers, Ben [1] BExp>>testBlock: aBlock | t | t := nil. aBlock value

Jan. 26, 2012

Re: [Pharo-project] Squeaksource Mirror Q&A

by GastÃ³n Dall' Oglio

Hello. Maybe you are interesting too in CoralCDN. See: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-October/055014.ht… Regards. 2012/1/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > thanks a lot Udo. > We really appreciate that. > > I was in contact with nicolas about SmalltalkHub. They were trying to see > if they could build a complete pharo solution for the back-end. > > Stef > > > All, > > > > building on top of Johan's work I built kind of a squeaksource CDN. This > CDN mirrors squeaksource daily and should provide fast access to all > packages using "nearby" edge location. Before making this public I'd like > to get some feedback on it's speed and reliability - especially if you are > far away (in terms of hops and bandwidth) from the real squeaksource server. > > > > So if you can spare some time please drop me a mail and I'll send you > further details. > > > > Thanks, > > > > Udo > > > > > > On 17.01.12 15:00, Johan Fabry wrote: > >> Hi All, > >> > >> Alex notified me that there were some mails flying around here about > the squeaksource mirror. I'm usually not on this mailing list because of > its high volume. I'd like to gather some questions that have been raised in > the last few days (thanks Nabble!) and give answers / share my thoughts. > I'll try to keep it brief. > >> > >> - How to use the mirror. If you don't know or tend to forget, just > point a web browser at http://dsal.cl/squeaksource Everything is > explained there. Write the URL on a post-it, add it to your browers > favorites or whatever ;-) Just remember http://dsal.cl/squeaksource > >> > >> - Mirror not complete: It is supposed to be a full mirror of the public > packages on Squeaksource. We are using wget to copy everything over. If you > know of a project that misses packages, please send me a mail (personally, > not to the list is best I guess) and we will try to debug the issue. > >> > >> - Pharo 1.4 / ObjectAsMethodWrapper issues: The redirect package was > written for 1.3, it uses ObjectAsMethodWrapper (i.e. method wrappers). I > don't know why ObjectAsMethodWrapper (apparently) is no longer in 1.4 but I > would highly recommend including it as it is a very useful package. I > thought even the profiler used it. In any case, I welcome any contributions > on how to make it work for 1.4 > >> > >> - Friendler configuration / user interface / having it in the core > image / ...: I am all for it, but I cannot dedicate the time to this right > now. All help is welcome and highly appreciated. I guess that some of you > must be much more knowledgeable at preferences settings/user interfaces et > al. so what would take you 10 minutes would take me a day ... > >> > >> I subscribed to the list now BTW so any comments/questions simply hit > reply :-) > >> > >> ---> Save our in-boxes! http://emailcharter.org<--- > >> > >> Johan Fabry > >> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile > >> > >> > >> > >> > >> > > > > > > > > >

Jan. 26, 2012

Re: [Pharo-project] cogwin/Croquet (Win7) + Moose + very large models = crash (out of Memory)

by Paul DeBruicker

Hani Abdeen wrote > > On 25 January 2012 23:05, Paul DeBruicker <pdebruic@> wrote: > >> >> Hani Abdeen wrote >> > >> >> It seems that on windows the size of the image by default is limited to >> 500MB in RAM. I don't know if you can change it or not. Linux/Mac is >> limited to 2GB. Can you try your experiments on a Mac? >> > > Unfortunately no, I've not Mac, and the company for which I'll use Moose > on > their software, Tomorrow morning :(, do not use Mac. > >> > Can you run virtualbox on your windows machine? I have a 32 bit debian linux (vers 6.0.3) virtual disk image (2.5GB RAM, 8GB disk) you coudl use that would let you hit the limit of what Pharo 32 bit can work with. -- View this message in context: http://forum.world.st/cogwin-Croquet-Win7-Moose-very-large-models-crash-out… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 25, 2012

Re: [Pharo-project] Beginner question about "self" in block

by Gabriel Cotelli

Yes, Binary messages always involves two objects, so in your example there's two message sends. Be aware also that there's no arithmetic specific precedence rules ( 4 * 5 + 2 will return 22). The precedence is consistent among the whole language (unary->binary->keyworded). On Wed, Jan 25, 2012 at 7:55 PM, Garret Raziel <boloomka(a)gmail.com> wrote: > So, keyword messages are slightly different from binary messages, because > 5+4*3 doesn't invoke "+*" message so I don't have to write "(5+4)*3". If I > had SmallInteger>>#multiplyBy and SmallInteger>>#add, I should use > parenthesis "(5 add: 3) multiplyBy: 3". >

Jan. 25, 2012