Pike-devel November 2016

pike-devel@lists.lysator.liu.se

9 participants
53 discussions

Proposal: Checked subprocess calls
by Chris Angelico 06 Nov '16

06 Nov '16

Branch: rosuav/process-check-run Two features added to the Process module. Firstly, a simple wrapper Process.check_run that calls Process.run and throws an error if the exit code isn't 0; and secondly, a means for Process.run() to leave stderr attached to the console. The intention is for this to be used for subprocess invocations that should normally succeed, but which might fail under exceptional circumstances: https://github.com/Rosuav/shed/blob/master/double_compile.pike string build = Process.run(({"pike/bin/pike", argv[0], "-x", argv[1]}))->stdout; The intention is for this to run a process and return its stdout. I could, of course, manually check: mapping rc = Process.run(({"pike/bin/pike", argv[0], "-x", argv[1]})); if (rc->stderr != "") werror(rc->stderr); if (rc->exitcode) exit(1, "Oops\n"); But with this proposal, the code would look like this: string build = Process.check_run(({"pike/bin/pike", argv[0], "-x", argv[1]}), (["stderr": "-"]))->stdout; It's a fairly simple idiom (and it might be worth making check_run set stderr to "-" by default), and 99% of the time, it'll do the same as the equally-simple idiom that I currently use for any quick-and-dirty scripts - but if something goes wrong, check_run will make sure that you don't miss noticing it. There are, broadly speaking, two ways for a subprocess to signal that something went wrong: a message on stderr, or an exit code. They're handled independently (check_run looks for the exit code, and setting stderr to "-" lets the user notice an error message), so you can pick and choose. Is this something wanted in trunk? ChrisA

3 7

Commit policy in stable (8.0)
by Peter Bortas 05 Nov '16

05 Nov '16

During the Pike conference this weekend we decided to clarify the commit policy for the stable repository. So here it is written out: The stable branch is closed to new features unless approved by the release manager (Peter Bortas). Small bugfixes and any size documentation changes may be committed by anyone. Henrik Grubbström is exempt from this and may commit what he deems appropriate. Any feature change should come with an accompanying update to CHANGES, and the same for bug fixes where appropriate. This policy can also be found on https://pike.lysator.liu.se/development/git/policies/ Regards, -- Peter Bortas

1 0

pike-benchmark
by Arne Goedeke 05 Nov '16

05 Nov '16

Tobi and me have been working on a new suite of benchmarks for pike. The main reasons to use that instead of Tools.Shoot is to make it easier to compare different pike versions. It currently contains (modified) versions of all benchmarks from Tools.Shoot. They have been changed to better test what they were intended to test. Other things: * reduce the variance of test results and also diaplay their standard deviation to make comparisons possible * encourage people (also non pike developers) to add/send their benchmarks * make it easier to store benchmark runs and add tools to compare them In the long term it would be nice to integrate this and run it from xenofarm to automatically track performance during development. The repository name is 'pike-benchmark' and it is hosted on the same server as the pike git. everyone who has access to the pike git, can also access the 'pike-benchmark'. Feels free to add tests. Arne

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel November 2016