Hi Tim:
Ok, I checked what I did. See http://smalltalkhub.com/#!/~StefanMarr/SMark/packages/Scripting
This implements support for command-line scripting by registering a startup handler, which then calls SMarkHarness class>>#run:.
Last time I checked, this was compatible with Squeak and Pharo, because I was using it even with Squeak 3.9 images. All this infrastructure is coming out of the RoarVM project. So, mind you, the code is dating back a while…
The `ScriptStarter` class should be the code to look at. The #initialize/#install methods on the class side do the relevant setup.
Hope that helps Stefan
On 01 May 2016, at 00:24, Tim Felgentreff timfelgentreff@gmail.com wrote:
Hi Chris and Stefan
yes, the Squeak cmdline arg processing through a file is what I'm using, but Pharo supports different ( more 'traditional looking') stuff afaict. If there was code specific to the Pharo way of doing it, I'm SMark, I don't know about it, since I haven't used Pharo for a few years (and RSqueak doesn't work with it, because they removed some of the fallback code for primitives that we don't implement).
I can look at the code, but I would be against a command line interface that doesn't work the same across different Smalltalk distributions. But we can certainly think about how to improve it.
cheers, Tim
On 30 April 2016 at 18:12, Chris Muller asqueaker@gmail.com wrote:
Squeak always processes command-line arguments. If the #readDocumentAtStartup Preference in the image is set (the default), it will treat the first image argument as a URL referring to a Smalltalk script to execute, and the subsequent ones as arguments to that script:
squeak -vm [vmArgs] myImage.image [urlToSmalltalkScript] [scriptArg1 scriptArg2 ...]
There's a convenience method provides easy access to those arguments and basic error handling for headless running via
"This code goes in a text file and referred to by the urlToSmalltalkScript" Smalltalk run: [ :scriptArg1 :scriptArg2 | "... your script..." ]
If readDocumentAtStartup is not set, then each image argument is simply passed in as an Array of Strings.
squeak -vm [vmArgs] myImage.image [imageArg1 imageArg2 imageArg3 ...]
On Fri, Apr 29, 2016 at 8:45 AM, Stefan Marr smalltalk@stefan-marr.de wrote:
Hi Tim:
On 29 Apr 2016, at 12:10, timfelgentreff timfelgentreff@gmail.com wrote:
what does your squeak-vm.sh script do? Because on Squeak, I cannot simply type --help and get output. The mailing list thread you linked refers to something Pharo specific that I don’t think we have in Squeak.
At least in Pharo there was/is a way to register a handler for the startup. SMark used to do that. It then will process the command line arguments.
I don’t remember the details, sorry, and currently don’t have access to the code to check.
Best regards Stefan
Stefan Marr-3 wrote
Hi Tim:
On 28 Apr 2016, at 13:01, Tim Felgentreff <
timfelgentreff@
> wrote:
> - can it be controlled from the command line?
Yes, provided you mean "use a .st file argument". To run a benchmark you can write e.g.
- BenchmarkAutosizeSuite run: {'BenchmarkSimpleStatisticsReporter'.
'SMarkShootout'. 100}. # runs all shootout benchmarks for 100 outer iterations, reporting statistics in the autosize suite
- BenchmarkCogSuite run: {'BenchmarkSimpleStatisticsReporter'.
'SMarkShootout.benchBinaryTrees'. 100}. # runs the binarytrees benchmarks for 100 outer iterations without autosizing, but with one extra iteration for warmup
I look at your changes to the code, but if you didn’t remove any SMark features, there is also a proper command-line interface.
See: http://forum.world.st/Convention-to-build-cmd-line-interfaces-with-Pharo-td3...
$ 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
Best regards Stefan
-- Stefan Marr Johannes Kepler Universität Linz http://stefan-marr.de/research/
-- View this message in context: http://forum.world.st/A-Benchmarking-tool-for-the-trunk-tp4892463p4892865.ht... Sent from the Squeak - Dev mailing list archive at Nabble.com.