- Pharo-dev - lists.pharo.org

[Pharo-project] running Pharo headless as service on Windows.

by John Thornborrow

Hi all, We're attempting to run a Pharo image as Headless as a Service on Windows XP. We've successfully done this before, but now we're using a later image (and exupery vm) it is unable to fully initialize. Squeak.exe is visible in Task manager. I don't even know where to start looking for more information so any help is appreciated :) I know it's not working because it is only supposed to start, run some specs/tests, then exit the image. When running this manually in the command prompt, it behaves as expected (with and without the -headless opt) but when run as service (SYSTEM user) it starts, but does nothing. Presumably because of Morphic and no user environment for SYSTEM? MAny thanks and Regards, John Thornborrow. www.pinesoft.co.uk Consider your responsibility to the environment - think before you print! ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

June 30, 2009

[Pharo-project] creation of ReadWriteStream with #on:

by Cyrille Delaunay

Hi, ReadWriteStream inherits from WriteStream which hinerits from PositionableStream. When you create a ReadWriteStream with #on: you use the default definition in PositionableStream : PositionableStream class >> on: aCollection "Answer an instance of me, streaming over the elements of aCollection." ^self basicNew on: aCollection #on: is not overriden in the instance side of ReadWriteStream and therefore it's the definition of WriteStream that is called : WriteStream >> on: aCollection super on: aCollection. readLimit := 0. writeLimit := aCollection size. Put the readLimit at 0 make sense for a WriteStream ( with witch your not supposed to read ) but when you create a ReadWriteStream on a collection you would be able to read what is already in the collection, no? I wonder why #on: has not been overriden in the instance side of ReadWriteStream ? Maybe it's not a good idea to create a ReadWriteStream with a collection that already includes elements ?

June 30, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Marcus Denker

On 30.06.2009, at 11:44, Douglas Brebner wrote: > Marcus Denker wrote: >> I personally think that with today's resources (my laptop has 4GB of >> Ram, not 256Kb), we should rethink some of the design-desicions taken >> 30 years ago. But many people are violently against this, fighting a >> battle by citing "embedded systems". If one manages to convince them >> that "embedded" these days does not equal "small", they mumble about >> "smart dust" and obscure things just to be able to fight for hacks >> not needed these days... >> >> Exploring new ways with the resources we have today does not mean >> that everything needs to live in the image. It means that one can >> affort to invest resources into very general, reusable solution to >> problems like this. > > Didn't Tim change CompiledMethods so they referred to their source > using > a pointer so the source could be stored anywhere? > Yes, Tim did some changes (in 1998) to make compiledMethods normal objects that have a ByteArray for the bytecode and a normal instvar for the pointer to the source. IMHO the way to go, but it was never added to squeak... mostly because people feared the overhead (there are 40.000 methods, so adding another 40.000 is indeed noticable, as we have seen in 3.9 with the MethodProperties...). I personally like this change, as it makes the implementation higher- level and more OO, which I think is a good thing. I personally think that "more OO" is better than "more compact", considering that a laptop these days has 4GB (this is GIGABYTES) of RAM. I always wonder how Smaltalk would look like if it was disgned with the same philosophy in 1976 that people apply today. Using the "but it costs memory" philosphy that everyone favors today, Smalltalk would never have been done in 1976 at all. There is another patch floating around that allows larger sources/ changes without changing the mechanism too much. >> One interesting aspect of the source/changes "outside the image" is >> that this problem of data that is not used often and thus can live on >> disk vs. memory is a general one. Hacking it into the system just for >> the sources is just that: a hack. Providing a general, scalable way >> to let objects live on disk that are not needed is much better, as >> everyone can than use it. The system can use it for other resources >> (fonts, images...). Programmers can use it to keep their domain data >> on disk automatically. > > > You mean something like LOOM? I would love to have that :) > Yes! :-) Marcus

June 30, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Douglas Brebner

Marcus Denker wrote: > I personally think that with today's resources (my laptop has 4GB of > Ram, not 256Kb), we should rethink some of the design-desicions taken > 30 years ago. But many people are violently against this, fighting a > battle by citing "embedded systems". If one manages to convince them > that "embedded" these days does not equal "small", they mumble about > "smart dust" and obscure things just to be able to fight for hacks > not needed these days... > > Exploring new ways with the resources we have today does not mean > that everything needs to live in the image. It means that one can > affort to invest resources into very general, reusable solution to > problems like this. Didn't Tim change CompiledMethods so they referred to their source using a pointer so the source could be stored anywhere? > One interesting aspect of the source/changes "outside the image" is > that this problem of data that is not used often and thus can live on > disk vs. memory is a general one. Hacking it into the system just for > the sources is just that: a hack. Providing a general, scalable way > to let objects live on disk that are not needed is much better, as > everyone can than use it. The system can use it for other resources > (fonts, images...). Programmers can use it to keep their domain data > on disk automatically. You mean something like LOOM? I would love to have that :)

June 30, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Marcus Denker

On 29.06.2009, at 22:19, Hernan Wilkinson wrote: > > there are two answers: > in Squeak the changes file gets full too quickly > > Ups, I did not know about that. what is the limit? why? > Smalltalk was originally realized for a *very* resource contrained machine. (a self-build, very impressive design. Amazing for the time and in some aspects even today). But: Lots of design desicions had to be made that where purely driven by resource constraints. So for the sources and changes this meant: a) changes and sources use the same mechanism. b) they are not nicely object-oriented in the image but outside. c) the way this is done is a wonderful ugly hack. The last bytecodes of any method are not bytecodes at all, but instead they form a pointer to the sources and changes files. The end of the story is that this means that both can be max. 32MB in size. Plenty even 10 years ago, not enough to update from 3.8 to 3.9 today. (changes file needs to be reseted at some point). I personally think that with today's resources (my laptop has 4GB of Ram, not 256Kb), we should rethink some of the design-desicions taken 30 years ago. But many people are violently against this, fighting a battle by citing "embedded systems". If one manages to convince them that "embedded" these days does not equal "small", they mumble about "smart dust" and obscure things just to be able to fight for hacks not needed these days... Exploring new ways with the resources we have today does not mean that everything needs to live in the image. It means that one can affort to invest resources into very general, reusable solution to problems like this. One interesting aspect of the source/changes "outside the image" is that this problem of data that is not used often and thus can live on disk vs. memory is a general one. Hacking it into the system just for the sources is just that: a hack. Providing a general, scalable way to let objects live on disk that are not needed is much better, as everyone can than use it. The system can use it for other resources (fonts, images...). Programmers can use it to keep their domain data on disk automatically. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

June 30, 2009

Re: [Pharo-project] List of very big objects

by Adrian Lienhard

SpaceTally new printSpaceAnalysis: 100 on: 'space.txt' Prints the top 100 classes with the most instances. Adrian On Jun 30, 2009, at 09:20 , Damien Cassou wrote: > Hi, > > one of my images, with a web application in it, is getting larger and > larger. How can I find which object(s) take(s) so much place? > > Thank you > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 30, 2009

[Pharo-project] List of very big objects

by Damien Cassou

Hi, one of my images, with a web application in it, is getting larger and larger. How can I find which object(s) take(s) so much place? Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 30, 2009

[Pharo-project] Omnibrowser chapter

by Alexandre Bergel

Dear All, I think the chapter can be significantly improved on a number of points: - how to create a command needs to be described - how to import icon into pharo, without that, hard to see how someone can create new icons - using Filter I will sync with Oscar today. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 30, 2009

Re: [Pharo-project] VM buid from source on debian linux - pls help

by GÃ¶ran Krampe

danil osipchuk wrote: >> "make" yields >> >> - disabledPlugins.c:21: error: redefinition of 'RomePlugin_exports' >> >> and stops. Easy hack fix: Remove one of those lines in disabledPlugins. Then it works fine. regards, GÃ¶ran

June 29, 2009

Re: [Pharo-project] [ANN] Fix to issue 825

by Hernan Wilkinson

> > > there are two answers: > in Squeak the changes file gets full too quickly Ups, I did not know about that. what is the limit? why? > > can you post an email in a separate thread to ask for review? I did, it is under the subject: [ANN] MouseOverHandler refactoring I hope it helps! Bye, Hernan. > > > But it is ok, I understand that pharo is getting better and it takes > > time to have an stable system. > > Thanks. > > > > > Bye, > > Hernan. > > > > > > > > > > > Stef > > > > > > > > Bye, > > > > Hernan. > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 29, 2009