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

Re: [Pharo-project] Support for stdout without OSProcess (issue 4065)

by David T. Lewis

On Sun, May 15, 2011 at 06:44:30PM +0200, Stefan Marr wrote: > Hi: > > What needs to be done for issue 4065? > http://code.google.com/p/pharo/issues/detail?id=4065 > > I would like to have an easy way to provide compatibility for the RoarVM primitive RVMOperations>print: which really just dumps a string to stdout. So, ideally, I don't want to many dependencies like OSProcess in SMark. > > What would need to be done for that? The issue is not to verbose. > Is it a missing print primitive in the VM? > > Thanks > Stefan FilePlugin>>primitiveFileStdioHandles is present in both the interpreter VM and Cog. It was added to the interpreter VM (SqueakSource/VMMaker) here: Name: VMMaker-dtl.213 Author: dtl Time: 28 December 2010, 2:06:59 am UUID: f2524f34-cfcb-46ea-80b6-81402f9a875f Ancestors: VMMaker-dtl.212 VMMaker 4.4.4 Add FilePlugin>>primitiveFileStdioHandles adapted from oscog. Reference Mantis 0007591: Add #primitiveFileStdioHandles to standard VM Notes r.e. adopting the oscog implementation of primitiveFileStdioHandles: Cog primitive uses "interpreterProxy topRemappableOop" which is defined for VM_PROXY_MINOR > 9 but standard VM support code is at VM_PROXY_MINOR 8 (Cog is at VM_PROXY_MINOR 11). Work around this by popping and pushing the result array rather than using topRemappableOop. Cog uses primitive failure return codes not yet supported in the interpreter VM. The primitive return codes need to be adopted in standard VM but this is not yet done.

May 15, 2011

[Pharo-project] Support for stdout without OSProcess (issue 4065)

by Stefan Marr

Hi: What needs to be done for issue 4065? http://code.google.com/p/pharo/issues/detail?id=4065 I would like to have an easy way to provide compatibility for the RoarVM primitive RVMOperations>print: which really just dumps a string to stdout. So, ideally, I don't want to many dependencies like OSProcess in SMark. What would need to be done for that? The issue is not to verbose. Is it a missing print primitive in the VM? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 15, 2011

Re: [Pharo-project] redundancy

by Dale Henrichs

Stef, GemSource is running Seaside2.6 and a very old version of the SqueakSource code. I'd rather run Seaside3.0 and Tobias' SqueakSource3 as an alternative to SqueakSource. And as a matter of fact, we have already started heading down that path. While I was on vacation we had a vm provisioned in a VMware data center for hosting a SqueakSource3 instance:) The plan is to run the SqueakSource3 instance as a beta for a couple of weeks to correct any load/code issues and then barring any big issues, open it up for general usage. I'll need a week or so to get the GemStone and SqueakSource3 installed and configured. When the beta is ready I'll send email to the list ... Dale On May 14, 2011, at 12:54 AM, StÃ©phane Ducasse wrote: > Yes. > So how do we do that? > Dale can we use the ssgemstone you host? > > Stef > >>> >> The problem is that the network operator is down... >> >> see http://code.google.com/p/pharo/issues/detail?id=4218 >> >> We should really t hink hard about redundancy... >> >

May 15, 2011

[Pharo-project] [update 1.3] #13201

by stephane ducasse

13201 ----- - Issue 4222: Senders/Implementors cannot remove methods from there nor to right click. - Issue 4230: Need to reinitialize desktop command shortcuts. Thanks Damien Cassou. - Issue 4155: Check for copied methods. Thanks Camillo Bruni.

May 15, 2011

Re: [Pharo-project] Convention to build cmd-line interfaces with Pharo?

by Stefan Marr

On 15 May 2011, at 14:57, StÃ©phane Ducasse wrote: > look into 1.3 because we made it better so that you can pass something that is not an cs or st and that > you can specify who should handle it and not get the system barking dummily at you. That will probably help with Pharo 1.3, thanks. Unfortunately, that does not help me as an application developer. I still want to maintain compatibility with Squeak and Pharo 1.2 since that is the current stable version. So, I would still appreciate some guidance on what the best approach is to handle such incompatibilities. Are there some common practices how to encapsulate these differences? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 15, 2011

[Pharo-project] [update 1.3] #13200

by Marcus Denker

13200 ----- Issue 4227: Failign Test: ImageSegmentTestExport.testSaveAndLoadImageSegmentToDiskWithoutGC Issue 4224: Put search button next to search input text in Finder Issue 4226: Issue 3597 has not been included completely Issue 4225: Latest Transcript changes have broken alt+t and alt+k Issue 3732: Change #standardWindowExtent Was: default omni browser size bigger -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 15, 2011

Re: [Pharo-project] Convention to build cmd-line interfaces with Pharo?

by StÃ©phane Ducasse

look into 1.3 because we made it better so that you can pass something that is not an cs or st and that you can specify who should handle it and not get the system barking dummily at you. Sref On May 15, 2011, at 11:13 AM, Stefan Marr wrote: > Hi: > > Is there any convention/standard approach to build nice cmd-line interfaces with Pharo? > > The first road block I encountered is the assumption that the first argument to the image on the command line is a document/script. Which fires an exception if it is not actually a loadable document. > > I did not see any way to disable that other than to deinstall Autostart (Autostart>>deinstall). > > That is fine for me, but might have unintended consequences. > The ProjectLauncher>>startUpAfterLogin is the actual place where that assumption is hard coded. > And, well, I don't know what the consequences are of disabling Autostart and as a consequence ProjectLauncher. > > So, are there other ways to get to a clean command-line interface? > > What I want eventually is the following: > > > $ squeak-vm.sh Pharo-1.2.image --help > SMark Benchmark Framework, version: SMark-StefanMarr.12 > > Usage: <vm+image> SMarkHarness [runner] [reporter] <suiteOrBenchmark> > [iterations [processes [problemSize]]] > > Arguments: > runner optional, a SMarkRunner class that executes the benchmarks > reporter optional, a SMarkReporter class that processes > and displays the results > suiteOrBenchmark required, either a SMarkSuite with benchmarks, > or a benchmark denoted by Suite.benchName > iterations optional, number of times the benchmarks are repeated > processes optional, number of processes/threads used by the benchmarks > problemSize optional, depending on benchmark for instance number of > inner iterations or size of used data set > > Bye the way, Squeak 4.1 exhibits the same behavior, but I did not notice anything alike in our 3.9 image, there is works just fine. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

May 15, 2011

Re: [Pharo-project] Which mailing-list for issues ?

by laurent laffont

On Sun, May 15, 2011 at 9:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > sorry what do you want to say? > Forget it, I've found and add it to http://www.pharo-project.org/community (Issue tracker mailing-list) Laurent. > On May 15, 2011, at 8:55 AM, laurent laffont wrote: > > > I'm still not subscribed, I want to, but it's not in > http://www.pharo-project.org/community nor > http://www.pharo-project.org/community/issue-tracking > > > > Laurent. > > >

May 15, 2011

Re: [Pharo-project] Convention to build cmd-line interfaces with Pharo?

by Stefan Marr

On 15 May 2011, at 12:40, Sven Van Caekenberghe wrote: > I think most Smalltalk user would be happy with a 'command line interface' at the Smalltalk level. SMarkHarness class>>execute: aBenchmarkOrSuite using: aRunnerClass andReport: withAReporterClass SMarkSuite class>>run and similar methods should satisfy the needs for casual image-bound Smalltalk users. The command line interface is meant for people who care about the VM-level and want some integration with existing build systems and/or benchmarking tools like ReBench, buildbot or perhaps Hudson... > > Sven > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 15, 2011

Re: [Pharo-project] Convention to build cmd-line interfaces with Pharo?

by Sven Van Caekenberghe

On 15 May 2011, at 11:13, Stefan Marr wrote: > What I want eventually is the following: > > > $ squeak-vm.sh Pharo-1.2.image --help > SMark Benchmark Framework, version: SMark-StefanMarr.12 > > Usage: <vm+image> SMarkHarness [runner] [reporter] <suiteOrBenchmark> > [iterations [processes [problemSize]]] > > Arguments: > runner optional, a SMarkRunner class that executes the benchmarks > reporter optional, a SMarkReporter class that processes > and displays the results > suiteOrBenchmark required, either a SMarkSuite with benchmarks, > or a benchmark denoted by Suite.benchName > iterations optional, number of times the benchmarks are repeated > processes optional, number of processes/threads used by the benchmarks > problemSize optional, depending on benchmark for instance number of > inner iterations or size of used data set You could code around it at the shell level, giving your users a 'smark.sh' script that exposes a Unix like command line interface and hiding the actual invocation of the vm and image. But that would only cover Linux and Mac OS X I guess. On the other hand, Windows is quite different at the command level, so it would be hard to make all this totally transparent. I think most Smalltalk user would be happy with a 'command line interface' at the Smalltalk level. Sven

May 15, 2011