April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Squeaksource.com down

by Marcus Denker

On Apr 23, 2011, at 6:44 AM, Miguel CobÃ¡ wrote: > It says: > > "SqueakSource is currently down. We are sorry for the inconvenience and > working on the problem. In the meantime you can still commit to a > directory repository on your disk and later copy the versions to > SqueakSource." > Should work now again. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 23, 2011

[Pharo-project] Squeaksource.com down

by Miguel CobÃ¡

It says: "SqueakSource is currently down. We are sorry for the inconvenience and working on the problem. In the meantime you can still commit to a directory repository on your disk and later copy the versions to SqueakSource." Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

April 23, 2011

Re: [Pharo-project] Fwd: [Vm-dev] Re: out of memory - cog on windows

by Andres Valloud

Does that mean that, even if your app uses 128mb of RAM, the VM will allocate 512mb of memory regardless? It seems a bit strange that just 1gb worth of allocations would cause problems. What about the load address of the VM and the way the memory chunk is allocated? Has the 32 bit VM been compiled to indicate the app is 32 bit address aware (if not, address space is limited to 2gb)? On 4/22/11 14:44 , Mariano Martinez Peck wrote: > > > ---------- Forwarded message ---------- > From: *Andreas Raab* <andreas.raab(a)gmx.de <mailto:andreas.raab@gmx.de>> > Date: Fri, Apr 22, 2011 at 3:01 PM > Subject: Re: [Vm-dev] Re: [Pharo-project] out of memory - cog on windows > To: vm-dev(a)lists.squeakfoundation.org > <mailto:vm-dev@lists.squeakfoundation.org> > > > > FWIW, the reason for the 512MB limit has to do with Windows memory > layout. When you're running applications that load dynamic libraries > (directly or indirectly such as when using ODBC which loads further > DLLs) Windows needs (sometimes a lot of) address space to map these DLLs > in order to load them[*]. When the VM starts it grabs MAX_VIRTUAL_MEMORY > from the OS which will consequently not be available to map DLLs into. > We have found that depending on the libraries in use and depending on > the overall system utilization, loading DLLs would fail seemingly "at > random" which, after further investigation, we were able to track to > reserving too much address space upfront. We were able to show > experimentally, that changing the limit from 1GB to 512MB would on some > machines make all the difference. > > [*] This is true in particular for libraries that create more threads as > the default Windows policy is to create threads with the stack size of > the application executable. Thus a 1MB default stack in the application > will by default create all further threads to be allocated with a 1MB > stack size. Of course all of this is subject to various other conditions. > > In the end we concluded that 512MB is a reasonable size for most apps > and with 512MB we've never seen these random failures. You can increase > the limit by recompiling the VM, but if you ship your app in diverse > environments you should be aware of the potential issues. > > Cheers, > - Andreas > > On 4/21/2011 22:44, Alain_Rastoul wrote: >> >> >> >> Apparently, the vm allocates MAX_VIRTUAL_MEMORY and reduces by steps >> of 128M until it >> succeeds. >> so I suppose it could be possible to allocate 2Gb and see how it runs >> on a 1Gb system and if this is not too much stress for >> the system (thinking of the pagefile) ? >> Tudor is your vm a cog or non cog vm ? >> >> "Mariano Martinez Peck" <marianopeck(a)gmail.com >> <mailto:marianopeck@gmail.com>> a Ã©crit dans le message de news: >> BANLkTi=Tved13_KL7quOzemOXPnCcfWw+g(a)mail.gmail.com >> <mailto:BANLkTi=Tved13_KL7quOzemOXPnCcfWw+g@mail.gmail.com>... >> >> ------------------------------------------------------------------------ >> >> >> On Thu, Apr 21, 2011 at 10:21 PM, Tudor Girba >> <tudor.girba(a)gmail.com <mailto:tudor.girba@gmail.com>> wrote: >> >> Hi, >> >> Should I to understand that the only way to enable more memory >> is to recompile the VM? Does that mean that there is no way to >> pass this information as a parameter like we can on Mac? >> >> >> As far as I know you can pass a parameter, but even so, it won't >> be able to allocate more than 512MB. >> I can compile the VM for you with this change in 5 minutes. But I >> am not sure that such simple code would make it work. I think such >> limit is there because of something. Otherwise, it sounds stupid >> imposing a limit just because. >> >> The problem is that I cannot recompile the VM because I have >> no access to a Windows machine. Is there one available that >> provides more memory? >> >> >> I don't think so, but start cc'ing the VM mailing list. You'd >> probably receive more help. >> >> Cheers >> >> Mariano >> >> Cheers, >> Doru >> >> >> On 21 Apr 2011, at 22:09, Alain_Rastoul wrote: >> >> > Hi Tudor, >> > >> > There is a constant in sqWin32Alloc.h (platforms\win32\vm) : >> > #define MAX_VIRTUAL_MEMORY 512*1024*1024 >> > you can change it to whatever you want and rebuild the vm, >> > for exzmple give all the available memory less 256 M . >> > >> > HTH >> > >> > Regards >> > Alain >> > >> > "Tudor Girba" <tudor.girba(a)gmail.com >> <mailto:tudor.girba@gmail.com>> a Ã©crit >> > dans le message de news: >> 03B9389F-C719-44D0-B106-2AC78B120F56(a)gmail.com >> <mailto:03B9389F-C719-44D0-B106-2AC78B120F56@gmail.com>... >> > Hi, >> > >> > We have no specific startUp: methods in Moose. In any case, >> the issue with >> > opening the image does not seem to be related to startUp:. >> > >> > Is it really true that the Cog VM is limited to 512MB of memory? >> > >> > Cheers, >> > Doru >> > >> > >> > On 21 Apr 2011, at 14:27, Luc Fabresse wrote: >> > >> >> Hi Doru, >> >> >> >> 2011/4/21 Tudor Girba >> >> <tudor.girba(a)gmail.com <mailto:tudor.girba@gmail.com>> >> >> Hi, >> >> >> >> >> >> >> >> On Apr 21, 2011, at 14:06, Mariano Martinez Peck >> >> <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> >> >>> >> >>> >> >>> On Thu, Apr 21, 2011 at 1:58 PM, Tudor Girba >> >>> <tudor.girba(a)gmail.com <mailto:tudor.girba@gmail.com>> wrote: >> >>>> Hi again, >> >>>> >> >>>> I did not say what the problem was :). The problem was >> that when >> >>>> opening the image on Windows, he got a Space is low >> message and the >> >>>> image was not usable (see attachment). >> >>> >> >>> That's weird. Does moose have something on the startup >> list? something >> >>> that can be bothering there? >> >> >> >> Not that I know of. Is there a way to check this? >> >> >> >> Classes should be registered using Smalltlak >> addToStartUpList: aClass >> >> Then aClass class>>#startUp: is executed at startup. >> >> So implementors of #startUp: on Moose classes should give >> you the answer. >> >> >> >> #Luc >> >> >> >> >> >> Actually, using exactly the same process some days ago he >> produced an >> >> image of 190MB. This one works just fine on Windows. The >> only difference >> >> between the two is the size of the loaded data. >> >> >> >> It would be really bad news if the Windows vm would be so >> severely limited >> >> in terms of memory. >> >> >> >> Cheers, >> >> Doru >> >> >> >> >> >>> >> >>> On Mac it worked just fine. >> >>>> >> >>>> Cheers, >> >>>> Doru >> >>>> >> >>>> >> >>> >> >>>> >> >>>> >> >>>> >> >>>> On 21 Apr 2011, at 12:52, Tudor Girba wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> I received a question from someone running a 200MB image >> on Windows >> >>>>> using Cog 2361. >> >>>>> >> >>>>> If I open the image on Mac, it works just fine. >> Unfortunately, I do >> >>>>> not have a Windows machine around, and I cannot test but >> I believe it >> >>>>> should be solvable by increasing the allocated memory. >> >>>>> >> >>>>> On Mac, I would run it with: ./Croquet -memory 1500m >> >>>>> >> >>>>> Can anyone help me with the right incantation for Windows? >> >>>>> >> >>>>> Cheers, >> >>>>> Doru >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> www.tudorgirba.com <http://www.tudorgirba.com> >> >>>>> >> >>>>> "What we can governs what we wish." >> >>>>> >> >>>>> >> >>>>> >> >>>>> <Space is low.png> >> >>>> >> >>>> -- >> >>>> www.tudorgirba.com <http://www.tudorgirba.com> >> >>>> >> >>>> "Yesterday is a fact. >> >>>> Tomorrow is a possibility. >> >>>> Today is a challenge." >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Mariano >> >>> http://marianopeck.wordpress.com >> >>> >> >> >> > >> > -- >> > www.tudorgirba.com <http://www.tudorgirba.com> >> > >> > "Beauty is where we see it." >> > >> > >> > >> > >> > >> > >> > >> > >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

April 23, 2011

Re: [Pharo-project] A ready only transcript does not fly

by Igor Stasenko

On 23 April 2011 00:06, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Fernando > I think that we should rollback the transcript. because this is really annoying that we cannot use > the transcript: > Â Â Â Â copy and paste > Â Â Â Â execute an expression there. > May be this is better to improve the ThreadSafeTranscript. > The new one looks like a regression and I'm quite sure people will not like it. > So this was a good try but we should recognise when stuff do not work as good as we wanted. > amen. > Stef > -- Best regards, Igor Stasenko AKA sig.

April 22, 2011

[Pharo-project] Fwd: [Vm-dev] Re: out of memory - cog on windows

by Mariano Martinez Peck

---------- Forwarded message ---------- From: Andreas Raab <andreas.raab(a)gmx.de> Date: Fri, Apr 22, 2011 at 3:01 PM Subject: Re: [Vm-dev] Re: [Pharo-project] out of memory - cog on windows To: vm-dev(a)lists.squeakfoundation.org FWIW, the reason for the 512MB limit has to do with Windows memory layout. When you're running applications that load dynamic libraries (directly or indirectly such as when using ODBC which loads further DLLs) Windows needs (sometimes a lot of) address space to map these DLLs in order to load them[*]. When the VM starts it grabs MAX_VIRTUAL_MEMORY from the OS which will consequently not be available to map DLLs into. We have found that depending on the libraries in use and depending on the overall system utilization, loading DLLs would fail seemingly "at random" which, after further investigation, we were able to track to reserving too much address space upfront. We were able to show experimentally, that changing the limit from 1GB to 512MB would on some machines make all the difference. [*] This is true in particular for libraries that create more threads as the default Windows policy is to create threads with the stack size of the application executable. Thus a 1MB default stack in the application will by default create all further threads to be allocated with a 1MB stack size. Of course all of this is subject to various other conditions. In the end we concluded that 512MB is a reasonable size for most apps and with 512MB we've never seen these random failures. You can increase the limit by recompiling the VM, but if you ship your app in diverse environments you should be aware of the potential issues. Cheers, - Andreas On 4/21/2011 22:44, Alain_Rastoul wrote: Apparently, the vm allocates MAX_VIRTUAL_MEMORY and reduces by steps of 128M until it succeeds. so I suppose it could be possible to allocate 2Gb and see how it runs on a 1Gb system and if this is not too much stress for the system (thinking of the pagefile) ? Tudor is your vm a cog or non cog vm ? "Mariano Martinez Peck" <marianopeck(a)gmail.com> a Ã©crit dans le message de news: BANLkTi=Tved13_KL7quOzemOXPnCcfWw+g(a)mail.gmail.com... ------------------------------ On Thu, Apr 21, 2011 at 10:21 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > Should I to understand that the only way to enable more memory is to > recompile the VM? Does that mean that there is no way to pass this > information as a parameter like we can on Mac? > > As far as I know you can pass a parameter, but even so, it won't be able to allocate more than 512MB. I can compile the VM for you with this change in 5 minutes. But I am not sure that such simple code would make it work. I think such limit is there because of something. Otherwise, it sounds stupid imposing a limit just because. The problem is that I cannot recompile the VM because I have no access to a > Windows machine. Is there one available that provides more memory? > > I don't think so, but start cc'ing the VM mailing list. You'd probably receive more help. Cheers Mariano > Cheers, > Doru > > > On 21 Apr 2011, at 22:09, Alain_Rastoul wrote: > > > Hi Tudor, > > > > There is a constant in sqWin32Alloc.h (platforms\win32\vm) : > > #define MAX_VIRTUAL_MEMORY 512*1024*1024 > > you can change it to whatever you want and rebuild the vm, > > for exzmple give all the available memory less 256 M . > > > > HTH > > > > Regards > > Alain > > > > "Tudor Girba" <tudor.girba(a)gmail.com> a Ã©crit > > dans le message de news: 03B9389F-C719-44D0-B106-2AC78B120F56(a)gmail.com > ... > > Hi, > > > > We have no specific startUp: methods in Moose. In any case, the issue > with > > opening the image does not seem to be related to startUp:. > > > > Is it really true that the Cog VM is limited to 512MB of memory? > > > > Cheers, > > Doru > > > > > > On 21 Apr 2011, at 14:27, Luc Fabresse wrote: > > > >> Hi Doru, > >> > >> 2011/4/21 Tudor Girba > >> <tudor.girba(a)gmail.com> > >> Hi, > >> > >> > >> > >> On Apr 21, 2011, at 14:06, Mariano Martinez Peck > >> <marianopeck(a)gmail.com> wrote: > >> > >>> > >>> > >>> On Thu, Apr 21, 2011 at 1:58 PM, Tudor Girba > >>> <tudor.girba(a)gmail.com> wrote: > >>>> Hi again, > >>>> > >>>> I did not say what the problem was :). The problem was that when > >>>> opening the image on Windows, he got a Space is low message and the > >>>> image was not usable (see attachment). > >>> > >>> That's weird. Does moose have something on the startup list? > something > >>> that can be bothering there? > >> > >> Not that I know of. Is there a way to check this? > >> > >> Classes should be registered using Smalltlak addToStartUpList: aClass > >> Then aClass class>>#startUp: is executed at startup. > >> So implementors of #startUp: on Moose classes should give you the > answer. > >> > >> #Luc > >> > >> > >> Actually, using exactly the same process some days ago he produced an > >> image of 190MB. This one works just fine on Windows. The only difference > >> between the two is the size of the loaded data. > >> > >> It would be really bad news if the Windows vm would be so severely > limited > >> in terms of memory. > >> > >> Cheers, > >> Doru > >> > >> > >>> > >>> On Mac it worked just fine. > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>> > >>>> > >>>> > >>>> > >>>> On 21 Apr 2011, at 12:52, Tudor Girba wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I received a question from someone running a 200MB image on Windows > >>>>> using Cog 2361. > >>>>> > >>>>> If I open the image on Mac, it works just fine. Unfortunately, I do > >>>>> not have a Windows machine around, and I cannot test but I believe it > >>>>> should be solvable by increasing the allocated memory. > >>>>> > >>>>> On Mac, I would run it with: ./Croquet -memory 1500m > >>>>> > >>>>> Can anyone help me with the right incantation for Windows? > >>>>> > >>>>> Cheers, > >>>>> Doru > >>>>> > >>>>> > >>>>> -- > >>>>> www.tudorgirba.com > >>>>> > >>>>> "What we can governs what we wish." > >>>>> > >>>>> > >>>>> > >>>>> <Space is low.png> > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Yesterday is a fact. > >>>> Tomorrow is a possibility. > >>>> Today is a challenge." > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > > > > -- > > www.tudorgirba.com > > > > "Beauty is where we see it." > > > > > > > > > > > > > > > > > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > > -- Mariano http://marianopeck.wordpress.com -- Mariano http://marianopeck.wordpress.com

April 22, 2011

Re: [Pharo-project] Online Pharo Documentation

by laurent laffont

That's really nice Camillo. Thank you. I hope to see it online soon ;) Laurent. On Fri, Apr 22, 2011 at 9:52 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > Hi everyone, > > During the last month I worked a bit on my pharo web documentation tool. > It's a derivate of ruby's http://yardoc.org/ running on top of seaside. > > A test image is available here: > http://dl.dropbox.com/u/18184943/WebDoc.zip > Open the image then access the documentation in your browser > http://localhost:8080/doc > > There are still some glitches due to the javascript fancyness around. > > Features: > - browse and filter packages > - browse and filter classes of packages > - Class overview with markdown enabled comments > - fully annotated source code with popups for known types and > selectors > > Missing: > - fully functional and slightly more intelligent search for methods, > classes and packages > - hierarchical display of packages > - bookmarkable links don't work yet. > > Please feel free to add your own wishes, I hope to slowly improve this > webdoc to make it really usable. > > v(^_^)v > camillo >

April 22, 2011

[Pharo-project] A ready only transcript does not fly

by StÃ©phane Ducasse

Fernando I think that we should rollback the transcript. because this is really annoying that we cannot use the transcript: copy and paste execute an expression there. May be this is better to improve the ThreadSafeTranscript. The new one looks like a regression and I'm quite sure people will not like it. So this was a good try but we should recognise when stuff do not work as good as we wanted. Stef

April 22, 2011

Re: [Pharo-project] Smalltalk, git, files, the universe and everything...okay not everything:)

by Craig Latta

Hi Dale and everyone-- I think traditional Smalltalk is just file-based enough to cause major annoyance for everyone. :) This seems like yet another good moment to read Ingalls' "Design Principles Behind Smalltalk"[1]. What resonates most for me are the "messages" and "uniformity" principles. In Smalltalk's first several development cycles in the 1970s, key technologies which could enable the realization of those principles (and which have since become commonplace) were still nascent. Specifically, establishing network connections between arbitrary computers was relatively difficult, and the connections themselves were relatively slow and expensive. In that situation, it seems more attractive to use files to communicate changes, rather than using remote messaging, even though that's a retreat from uniform application of the communicating-objects idea. Perhaps remote messaging wasn't even considered then (hm, if only there were people from that time who could tell us... :). Anyway, once you've decided to use files to communicate changes, you establish several conventions which are hard to drop. These include: - It's normal to express an application as a set of differences from some known object memory state, or one that is "close enough"... except when it isn't. - It's normal to express those differences as source code, to be compiled by an object memory which is again "close enough". - Conveying changes from one Smalltalk system to another is not an interactive process. If the changes in a file are wrong, you need to fiddle with the file yourself, or change the system that made the file and recreate it. The dependency relationship between multiple files of changes is even more problematic. Change sets and fileouts are a result of these unfortunate conventions, but they need not be integral to Smalltalk. However, this is all independent of the external interfaces we can provide to an object memory. Another thing we can do with today's easy/fast/cheap network connections, and the web services that have grown around them, is provide WebDAV access to object memories. A Smalltalk WebDAV server could provide a virtual filesystem, suitable for use with anyone's Favorite Text Editor. It could present whatever file content and file/directory structure it likes (e.g., a mapping to classes and methods in some useful way, like Casey mentioned), and perform whatever side effects it likes when those virtual files are changed by the Favorite Text Editors. People would be free to copy those virtual files and put them into whatever other system they like (e.g. git), but the interesting stuff happens when the files make their way back into the virtual filesystem, through those WebDAV server side effects. I suspect one could integrate writes to the virtual filesystem with commits to another system. (Despite that, I agree with Steven that it's the "social coding" affordances of git that are really interesting, not git's mechanisms per se.) -C [1] http://tinyurl.com/3wyxavt (archive.org) -- Craig Latta www.netjam.org/resume +31 06 2757 7177 + 1 415 287 3547

April 22, 2011

Re: [Pharo-project] out of memory - cog on windows

by Igor Stasenko

On 22 April 2011 22:48, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > It's nice to see how to set up one's environment. Â The specific compiler > versions, as well as versions of the relevant SDKs, should be well > documented so that anyone can reproduce an "official" build. > Indeed. That's the idea. > IMHO, it seems a bit weird that a command line switch was superceded with a > #define. > i'm not sure if there was such switch on windoze. -- Best regards, Igor Stasenko AKA sig.

April 22, 2011

[Pharo-project] Question on Merlin

by Alexandre Bergel

Hi! Is there a way to break the pane flow based on what the user has selected? Consider the following example: In Hapao, there are two panes: one to select previous coverage, and the second one to pick packages. I would like to have if the user does not select a previous coverage, then we move to pane 2. If he has selected one, then we begin the analysis. Is there a way to do this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 22, 2011