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

Re: [Pharo-project] Memory usage

by johnmci

David Lewis and I spent a far amount of time a few years back to make the 32 vm 4gb clean. So are you running on stale knowledge here, or does the vm crash when to goes over 2gb? -- View this message in context: http://forum.world.st/Memory-usage-tp4641108p4642349.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 31, 2012

Re: [Pharo-project] [Pharo-users] Adding Websocket support to Zinc

by Marcus Denker

On Jul 31, 2012, at 11:16 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 31 July 2012 21:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Jul 31, 2012, at 10:18 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> >>> >>> I'm always happy with multiple, competing implementations of things - >>> I was under the impression that Andreas Raab's WebClient also supports >>> WebSockets? >>> >> >> >> We originally wanted to use WebClient and were told very clearly that it >> was off limits for Pharo. (this is why Zinc was done). > > That's... odd, given that it's licenced under MIT. I'm sad to hear that. > The MIT change came after we removed it from Pharo. Zinc is much better anyway. Not only from a technological point of view, much more from a social one. Marcus -- Marcus Denker -- http://marcusdenker.de

July 31, 2012

Re: [Pharo-project] [Pharo-users] Adding Websocket support to Zinc

by Frank Shearar

On 31 July 2012 21:57, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jul 31, 2012, at 10:18 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> >> >> I'm always happy with multiple, competing implementations of things - >> I was under the impression that Andreas Raab's WebClient also supports >> WebSockets? >> > > > We originally wanted to use WebClient and were told very clearly that it > was off limits for Pharo. (this is why Zinc was done). That's... odd, given that it's licenced under MIT. I'm sad to hear that. frank > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

July 31, 2012

Re: [Pharo-project] [Pharo-users] Adding Websocket support to Zinc

by Marcus Denker

On Jul 31, 2012, at 10:18 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> > > I'm always happy with multiple, competing implementations of things - > I was under the impression that Andreas Raab's WebClient also supports > WebSockets? > We originally wanted to use WebClient and were told very clearly that it was off limits for Pharo. (this is why Zinc was done). Marcus -- Marcus Denker -- http://marcusdenker.de

July 31, 2012

Re: [Pharo-project] Fwd: [Pharo-users] Adding Websocket support to Zinc

by Frank Shearar

On 31 July 2012 21:12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > Begin forwarded message: > > From: Andy Burnett <andy.burnett(a)knowinnovation.com> > Subject: [Pharo-users] Adding Websocket support to Zinc > Date: July 31, 2012 9:39:15 PM GMT+02:00 > To: pharo-users(a)lists.gforge.inria.fr > Reply-To: A friendly place where any question about pharo is welcome > <pharo-users(a)lists.gforge.inria.fr> > > I think we need Websocket support built into Pharo. So, rather than talk > about it, I have contracted with Sven to build it into Zinc. We hope to have > a running version in the early Autumn. > > The purpose of this email is: > > To let everyone know that we will have Websocket support soon > To ask if anyone else feels that they would gain commercial benefit from > using this feature, and if so, whether they would like to help cover the > cost. If so, please drop me an email. > > Cheers > Andy I'm always happy with multiple, competing implementations of things - I was under the impression that Andreas Raab's WebClient also supports WebSockets? frank > -- > Marcus Denker -- http://marcusdenker.de >

July 31, 2012

[Pharo-project] Fwd: [Pharo-users] Adding Websocket support to Zinc

by Marcus Denker

Begin forwarded message: > From: Andy Burnett <andy.burnett(a)knowinnovation.com> > Subject: [Pharo-users] Adding Websocket support to Zinc > Date: July 31, 2012 9:39:15 PM GMT+02:00 > To: pharo-users(a)lists.gforge.inria.fr > Reply-To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> > > I think we need Websocket support built into Pharo. So, rather than talk about it, I have contracted with Sven to build it into Zinc. We hope to have a running version in the early Autumn. > > The purpose of this email is: > To let everyone know that we will have Websocket support soon > To ask if anyone else feels that they would gain commercial benefit from using this feature, and if so, whether they would like to help cover the cost. If so, please drop me an email. > Cheers > Andy -- Marcus Denker -- http://marcusdenker.de

July 31, 2012

Re: [Pharo-project] Memory usage

by StÃ©phane Ducasse

esteban has been fighting all day to compile the vm on mountain lion. A problem with free type plugin not found dylib and friends. > Hi Jannik, > > I am not a Mac user, and I have only ever done this on Linux, so I cannot > promise that it will be easy. Possibly Esteban can give us some advice here, > and correct my errors. Also, if you are going to try this, we may want to > take the discussion to the vm-dev list. > > You will need to install the Mac tools for compiling Unix programs (sorry > I do not know what this is called) and you will need to be able to compile > programs using CMake and the gcc tools on a Mac. I know very little about > this myself, but I'm sure others can give some tips. > > The actual VM that you will need to build will be an interpreter VM, and > you will be building it with a preprocessor macro set to force use of > the 64-bit object format. The resulting VM will be slow compared to what > you are used to with Cog, and it may not have all the features that you > would expect from a Mac VM (i.e. the VM that Esteban supports), but I > expect that it should work on Mac and that it would allow you to run a > 64-bit image prepared with the SystemTracer. > > As luck would have it, Ian Piumarta is in the process of updating the unix > VM code right now, and this will make it easier to do the build for 64-bit > images. I would say that we should wait a couple of days before starting > any new work on this so that we have all of the latest updates. > > I'm not sure if this is something that you want to get into, and it is not > what I would call "easy" ;) But if you want to try it I will do my best > to step you through the process. > > Dave > > > On Tue, Jul 31, 2012 at 03:18:19PM +0200, jannik.laval wrote: >> Hi Dave, >> >> I begin with a small problem (is it ?): my os is the latest apple macos. >> It seems that there is no squeak vm 64 for macos (I did not find it). >> >> How can I build one "easily" ? >> >> Thanks, >> Jannik >> >> On Jul 24, 2012, at 2:04 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: >> >>> On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: >>>> Hi Dave, >>>> >>>> Should I load the SystemTracer available on SqueakSource ? The last version is from 2011, and seems old, no ? >>>> When I try it, it calls some methods that do not exist in Pharo. >>>> >>>> Do you have more information on how to use it ? >>> >>> Hi Jannik, >>> >>> The system tracer is explained in the class comment of class SystemTracer. >>> The comment was written by Dan Ingalls (I think), and gives credit to Ted >>> Kaehler as the inventor of the original. Class SystemTracer2 has additional >>> documentation including how to run the trace. SystemTracer2 is a newer >>> version that you will actually be using, so you can think of SystemTracer >>> as the original reference implementation, while SystemTracer2 and its >>> subclasses are variations on the original. SystemTracer64 is the subclass >>> that implements conversion logic for copying 32-bit objects into the >>> experimental 64-bit object memory format. This object format is described >>> in the SystemTracer64 class comment, and more information is available at >>> http://squeakvm.org/squeak64. >>> >>> A system tracer will first put your image into a "quiet" mode, then copy >>> and convert the running object memory to a new image file, and then wake up >>> and return to normal. This is similar to saving your image and restarting >>> from a disk file, except that the system tracer will trace your object >>> memory to a new format rather than saving it unchanged. >>> >>> To trace your running image to a new 64-bit image file, you would do this: >>> >>> SystemTracer64 writeImage: 'new64bitImage.image' >>> >>> The last update I did to SystemTracer (SystemTracing-dtl.23) works with >>> closure-enabled images, including Pharo at one time. I have a 64-bit >>> Pharo 1.4 image that I made about a year and a half ago. I don't know >>> what has changed in Pharo since then, so probably some updates will be >>> needed, or possibly a Pharo-specific version. I know that others on the >>> Pharo list have worked on this, so hopefully someone else can give you >>> some pointers about that. >>> >>> Dave >>> >>> >> >> --- >> Jannik Laval >> >

July 31, 2012

[Pharo-project] don't use update stream to get latest update

by Esteban Lorenzano

...because looks like the changes in the EventHandler breaks everything is you use it. Download a clean image from jenkins instead :) Esteban

July 31, 2012

Re: [Pharo-project] Memory usage

by David T. Lewis

I don't know of anyone who has built a StackVM for the 64-bit object memory, so this might require some development work. It would certainly be possible to do it, but I don't think that anyone has tried. Note that Eliot has plans for improved object memory formats, and the current 64-bit object memory is a "simplest thing that could possible work" conversion of the 32-bit object memory. I expect that Eliot would want to put his energy into the new object memory format(s), so a StackVM for the current 64-bit object memory would probably require someone to volunteer to do some development work. Dave On Tue, Jul 31, 2012 at 04:16:40PM +0200, phil(a)highoctane.be wrote: > Hi guys, > > I've been building the iOS StackVM for my own uses and am definitely > interested in getting a 64-bit StackVM for some large data sets I'd like to > load in RAM for some experiments. > > If there are pointers given, I am willing to test the build on my box. > > Phil > > > 2012/7/31 David T. Lewis <lewis(a)mail.msen.com> > > > Hi Jannik, > > > > I am not a Mac user, and I have only ever done this on Linux, so I cannot > > promise that it will be easy. Possibly Esteban can give us some advice > > here, > > and correct my errors. Also, if you are going to try this, we may want to > > take the discussion to the vm-dev list. > > > > You will need to install the Mac tools for compiling Unix programs (sorry > > I do not know what this is called) and you will need to be able to compile > > programs using CMake and the gcc tools on a Mac. I know very little about > > this myself, but I'm sure others can give some tips. > > > > The actual VM that you will need to build will be an interpreter VM, and > > you will be building it with a preprocessor macro set to force use of > > the 64-bit object format. The resulting VM will be slow compared to what > > you are used to with Cog, and it may not have all the features that you > > would expect from a Mac VM (i.e. the VM that Esteban supports), but I > > expect that it should work on Mac and that it would allow you to run a > > 64-bit image prepared with the SystemTracer. > > > > As luck would have it, Ian Piumarta is in the process of updating the unix > > VM code right now, and this will make it easier to do the build for 64-bit > > images. I would say that we should wait a couple of days before starting > > any new work on this so that we have all of the latest updates. > > > > I'm not sure if this is something that you want to get into, and it is not > > what I would call "easy" ;) But if you want to try it I will do my best > > to step you through the process. > > > > Dave > > > > > > On Tue, Jul 31, 2012 at 03:18:19PM +0200, jannik.laval wrote: > > > Hi Dave, > > > > > > I begin with a small problem (is it ?): my os is the latest apple macos. > > > It seems that there is no squeak vm 64 for macos (I did not find it). > > > > > > How can I build one "easily" ? > > > > > > Thanks, > > > Jannik > > > > > > On Jul 24, 2012, at 2:04 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > > > > On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: > > > >> Hi Dave, > > > >> > > > >> Should I load the SystemTracer available on SqueakSource ? The last > > version is from 2011, and seems old, no ? > > > >> When I try it, it calls some methods that do not exist in Pharo. > > > >> > > > >> Do you have more information on how to use it ? > > > > > > > > Hi Jannik, > > > > > > > > The system tracer is explained in the class comment of class > > SystemTracer. > > > > The comment was written by Dan Ingalls (I think), and gives credit to > > Ted > > > > Kaehler as the inventor of the original. Class SystemTracer2 has > > additional > > > > documentation including how to run the trace. SystemTracer2 is a newer > > > > version that you will actually be using, so you can think of > > SystemTracer > > > > as the original reference implementation, while SystemTracer2 and its > > > > subclasses are variations on the original. SystemTracer64 is the > > subclass > > > > that implements conversion logic for copying 32-bit objects into the > > > > experimental 64-bit object memory format. This object format is > > described > > > > in the SystemTracer64 class comment, and more information is available > > at > > > > http://squeakvm.org/squeak64. > > > > > > > > A system tracer will first put your image into a "quiet" mode, then > > copy > > > > and convert the running object memory to a new image file, and then > > wake up > > > > and return to normal. This is similar to saving your image and > > restarting > > > > from a disk file, except that the system tracer will trace your object > > > > memory to a new format rather than saving it unchanged. > > > > > > > > To trace your running image to a new 64-bit image file, you would do > > this: > > > > > > > > SystemTracer64 writeImage: 'new64bitImage.image' > > > > > > > > The last update I did to SystemTracer (SystemTracing-dtl.23) works with > > > > closure-enabled images, including Pharo at one time. I have a 64-bit > > > > Pharo 1.4 image that I made about a year and a half ago. I don't know > > > > what has changed in Pharo since then, so probably some updates will be > > > > needed, or possibly a Pharo-specific version. I know that others on the > > > > Pharo list have worked on this, so hopefully someone else can give you > > > > some pointers about that. > > > > > > > > Dave > > > > > > > > > > > > > > --- > > > Jannik Laval > > > > > > >

July 31, 2012

Re: [Pharo-project] Memory usage

by phil＠highoctane.be

Hi guys, I've been building the iOS StackVM for my own uses and am definitely interested in getting a 64-bit StackVM for some large data sets I'd like to load in RAM for some experiments. If there are pointers given, I am willing to test the build on my box. Phil 2012/7/31 David T. Lewis <lewis(a)mail.msen.com> > Hi Jannik, > > I am not a Mac user, and I have only ever done this on Linux, so I cannot > promise that it will be easy. Possibly Esteban can give us some advice > here, > and correct my errors. Also, if you are going to try this, we may want to > take the discussion to the vm-dev list. > > You will need to install the Mac tools for compiling Unix programs (sorry > I do not know what this is called) and you will need to be able to compile > programs using CMake and the gcc tools on a Mac. I know very little about > this myself, but I'm sure others can give some tips. > > The actual VM that you will need to build will be an interpreter VM, and > you will be building it with a preprocessor macro set to force use of > the 64-bit object format. The resulting VM will be slow compared to what > you are used to with Cog, and it may not have all the features that you > would expect from a Mac VM (i.e. the VM that Esteban supports), but I > expect that it should work on Mac and that it would allow you to run a > 64-bit image prepared with the SystemTracer. > > As luck would have it, Ian Piumarta is in the process of updating the unix > VM code right now, and this will make it easier to do the build for 64-bit > images. I would say that we should wait a couple of days before starting > any new work on this so that we have all of the latest updates. > > I'm not sure if this is something that you want to get into, and it is not > what I would call "easy" ;) But if you want to try it I will do my best > to step you through the process. > > Dave > > > On Tue, Jul 31, 2012 at 03:18:19PM +0200, jannik.laval wrote: > > Hi Dave, > > > > I begin with a small problem (is it ?): my os is the latest apple macos. > > It seems that there is no squeak vm 64 for macos (I did not find it). > > > > How can I build one "easily" ? > > > > Thanks, > > Jannik > > > > On Jul 24, 2012, at 2:04 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > > On Tue, Jul 24, 2012 at 09:27:49AM +0200, jannik.laval wrote: > > >> Hi Dave, > > >> > > >> Should I load the SystemTracer available on SqueakSource ? The last > version is from 2011, and seems old, no ? > > >> When I try it, it calls some methods that do not exist in Pharo. > > >> > > >> Do you have more information on how to use it ? > > > > > > Hi Jannik, > > > > > > The system tracer is explained in the class comment of class > SystemTracer. > > > The comment was written by Dan Ingalls (I think), and gives credit to > Ted > > > Kaehler as the inventor of the original. Class SystemTracer2 has > additional > > > documentation including how to run the trace. SystemTracer2 is a newer > > > version that you will actually be using, so you can think of > SystemTracer > > > as the original reference implementation, while SystemTracer2 and its > > > subclasses are variations on the original. SystemTracer64 is the > subclass > > > that implements conversion logic for copying 32-bit objects into the > > > experimental 64-bit object memory format. This object format is > described > > > in the SystemTracer64 class comment, and more information is available > at > > > http://squeakvm.org/squeak64. > > > > > > A system tracer will first put your image into a "quiet" mode, then > copy > > > and convert the running object memory to a new image file, and then > wake up > > > and return to normal. This is similar to saving your image and > restarting > > > from a disk file, except that the system tracer will trace your object > > > memory to a new format rather than saving it unchanged. > > > > > > To trace your running image to a new 64-bit image file, you would do > this: > > > > > > SystemTracer64 writeImage: 'new64bitImage.image' > > > > > > The last update I did to SystemTracer (SystemTracing-dtl.23) works with > > > closure-enabled images, including Pharo at one time. I have a 64-bit > > > Pharo 1.4 image that I made about a year and a half ago. I don't know > > > what has changed in Pharo since then, so probably some updates will be > > > needed, or possibly a Pharo-specific version. I know that others on the > > > Pharo list have worked on this, so hopefully someone else can give you > > > some pointers about that. > > > > > > Dave > > > > > > > > > > --- > > Jannik Laval > > > >

July 31, 2012