Pike-devel February 2014

pike-devel@lists.lysator.liu.se

7 participants
6 discussions

debugger opcodes
by Bill Welliver 30 Oct '14

30 Oct '14

I noticed that folks have been working on code generation lately. Any chance it might be possible to implement some of the opcodes required to get debugging working (step, break, etc)? I seem to recall someone indicating it wasn't a terribly difficult task, but it's clearly beyond my understanding of the problem. Bill

4 6

Sql.pgsql behavior in case of errors
by aldem-pikedev＠aldem.net 21 Aug '14

21 Aug '14

Hi everyone, I am preparing to use Postgres in my app, found the following strange behavior: ---snip--- Sql.Sql db = Sql.Sql("pgsql://localhost", "test", "test", "test"); db->query("BEGIN"); db->query("INSERT INTO requests (SvTrId) VALUES ('lala')"); catch(db->query("INSERT INTO requests (SvTrId) VALUES ('lala')")); db->query("INSERT INTO requests (SvTrId) VALUES ('juju')"); db->query("ROLLBACK"); ---snip--- Database is opened, row with 'lala' is inserted, second query (obviously) fails as SvTrId is the primary key, but row with 'juju' is inserted *and* appears in the database - i.e. the transaction is *committed*! Studying source code show, that once error is encounter, session is reset, i.e. running transaction is rolled back, everything is closed, temporary tables are deleted and session variables are reset as well, and after that, the next statement(s) will be committed immediately, as there is no active transaction. In my opinion, this is not exactly correct behavior when statement fails, as session still may be needed (especially temporary tables, open cursors etc). Im some cases, this is perfectly normal when SQL statement fails, especially in SERIALIZED transaction isolation level, and it would be more practical to leave the decision as of what to do to the application. Yes, this is true that it is impossible to continue executing statements in failed transaction, but temporary tables etc. may still be needed. Also, silent reconnection is not a good idea too - when there are many transactional statements are executed - it would be nice to have an option to modify this behavior. Best regards, /Alexander

5 6

bash/dash
by Arne Goedeke 10 Mar '14

10 Mar '14

My gentoo /bin/sh (which is bash) unlike dash generates a broken whitespace.h file from the current bin/getwhitespace.sh . I dont know which of the two is wrong here, but should we simply use numeric values instead of character escapes? arne

5 10

New 7.8 alpha
by Bill Welliver 27 Feb '14

27 Feb '14

Good day, I've prepared and uploaded a new Pike 7.8 alpha. This includes all of the backports and has an up-to-date changelog. I've verified the build passes tests* on OSX 10.9. Please have a look and let me know if there aren't any problems. If all goes well, I'll upgrade it to beta status in a week or so. http://pike.lysator.liu.se/pub/pike/alpha/7.8.834/Pike-v7.8.834.tar.gz Bill * MacOS X 10.9 seems to have different kqueue behavior than previous releases, in that events seem to be delayed, causing the IP tests to timeout unless the timeout is increased beyond the default 20 seconds.

2 1

curious printf bug
by Martin Bähr 27 Feb '14

27 Feb '14

hi, this was found by hallvabo on irc: write("%.3f\n",Gmp.mpf("3.14159265359")) prints all the decimals, not just three confirmed in 7.9 all the way down to 7.5 by genesys. but it works in 7.3 btw: http://pike-jira.lysator.liu.se/ is down. greetings, martin.

2 1

Another typo in Thread.pmod on 7.8
by Jeff Hungerford 02 Feb '14

02 Feb '14

It looks like this is fixed in 8.0, but in 7.8 Thread.Farm()->run() doesn't connect the returned result object to the job in the queue. Line 661 is: job_queue->write( ({ 0, ({f, args }) }) ); But it should be: job_queue->write( ({ ro, ({f, args }) }) ); -Jeff

1 0

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 February 2014