[Pharo-project] Convention to build cmd-line interfaces with Pharo?
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
On 15 May 2011, at 11:13, Stefan Marr wrote:
So, are there other ways to get to a clean command-line interface?
Just notice that there is actually a preference 'readDocumentAtStartup' in Squeak, and in Pharo there is AbstractLauncher>>readDocumentAtStartup:. That will probably work. What is the best approach to support both of these different ways to disable this behavior? 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
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
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
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
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
On 15 May 2011 17:40, Stefan Marr <pharo@stefan-marr.de> wrote:
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?
Yes. On your place i would just trash everything and implement a good command line interface from scratch. :) As you may know, Squeak was inherently designed to not care about a command-line and any stdio, so we don't have a standartized way to handle command-line and standard input/output :( I don't remember what exactly was done in 1.3. Some cleanup i guess. -- Best regards, Igor Stasenko AKA sig.
As you may know, Squeak was inherently designed to not care about a command-line and any stdio, so we don't have a standartized way to handle command-line and standard input/output :( I don't remember what exactly was done in 1.3. Some cleanup i guess.
not only cleaning, we can specify that a certain extension should be handled in a certain way without breaking because this is not 100% smalltalk for example. For example a coral script (which has a different syntax than a cs) can be loaded without breaking and breaking the laoding of cs. Stef
On 16 May 2011 18:47, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
As you may know, Squeak was inherently designed to not care about a command-line and any stdio, so we don't have a standartized way to handle command-line and standard input/output :( I don't remember what exactly was done in 1.3. Some cleanup i guess.
not only cleaning, we can specify that a certain extension should be handled in a certain way without breaking because this is not 100% smalltalk for example. For example a coral script (which has a different syntax than a cs) can be loaded without breaking and breaking the laoding of cs.
This needs to be documented somewhere. Because a correctly working command-line becoming more and more important once we're using Hudson for automatic building images, run tests and other tasks. That's why i spent time implementing NonInteractiveUIManager. @Stefan Marr: About command-line on some Mac VMs: yes, this is known bug. Some VMs are just "swallowing" command-line arguments so you cannot see them from image side.
Stef
-- Best regards, Igor Stasenko AKA sig.
participants (4)
-
Igor Stasenko -
Stefan Marr -
Stéphane Ducasse -
Sven Van Caekenberghe