Pike-devel December 2017

pike-devel@lists.lysator.liu.se

7 participants
31 discussions

Sql.Date Sql.Time Sql.TimeTZ Sql.Timestamp Sql.Interval
by Stephen R. van den Berg 14 Dec '17

14 Dec '17

In Pike 8.1 I checked in a few new native Sql types. This allows for faster, easier and lossless manipulation of dates/times/intervals. It also facilitates binary transfer to and from the database. I currently implemented all this for the pgsql driver. The new code still needs documentation. Reviews welcome. -- Stephen.

5 14

Concurrent improvements and enhanced depend() interface to 8.0?
by Stephen R. van den Berg 13 Dec '17

13 Dec '17

Has anyone, other than myself, actually tested the 8.1 Concurrent (since my code overhaul and the enhanced depend() interface)? I have some applications that use it rather intensely, and I added a lot of testsuite entries. I have not used the enhanced depend() interface (in my own applications), except when writing the various testsuite entries. Since the new & improved Concurrent code has some critical bugfixes: - Removes all restrictions on callbacks not being allowed to be recursive (and thus eliminates a possible cause for deadlocks). - Reduce mutex contention. - Change some operations from O(n^2) to O(n). - Promises that Promises work without a running backend (pun intended :-). I'd like to port the fixes over; but that also implies that the enhanced depend() interface is introduced to 8.0. Did you already try to use the enhanced depend() interface, Martin? -- Stephen.

1 0

Reproducing the elusive xenofarm error?
by Stephen R. van den Berg 11 Dec '17

11 Dec '17

After my most recent commit, xenofarm shows an error. Trying to reproduce that using a simple "make" seems to be difficult. Any clues? -- Stephen.

3 4

Downtime for Pike sites on Saturday Dec 9
by Peter Bortas ＠ Pike developers forum 09 Dec '17

09 Dec '17

During Saturday Dec 9 the computer room at Lysator will be reorganized and all Pike resource sites will be down at some point during the day.

1 1

Variant warnings, should I fix the code, or is the warning incorrect?
by Stephen R. van den Berg 07 Dec '17

07 Dec '17

Since the latest variant changes in 8.1, I see this: Erroneous warning: test-install/pike/8.1.11/lib/modules/Web.pmod/SocketIO.pmod:205: Variant type mismatch in second pass for register. Erroneous warning: test-install/pike/8.1.11/lib/modules/Web.pmod/SocketIO.pmod:205: Expected: function(string, string, void | function({ Client = object }, function(mixed ... : void), string, string, mixed ... : void) : void). Erroneous warning: test-install/pike/8.1.11/lib/modules/Web.pmod/SocketIO.pmod:205: Got : function(string, string, void | function({ Client = object(implements program(/tmp/xenofarm/pike-devel/devel2.cuci.nl/buildtmp/Pike-v8.1-snapshot/build/linux-94.13.11-srb-asrock-00001-g90709e3b8a64-x86_64/test-install/pike/8.1.11/lib/modules/Web.pmod/SocketIO.pmod:255)) }, function(mixed ... : void), string, string, mixed ... : void) : void). Erroneous warning: test-install/pike/8.1.11/lib/modules/Web.pmod/SocketIO.pmod:210: Variant type mismatch in second pass for register. Erroneous warning: test-install/pike/8.1.11/lib/modules/Web.pmod/SocketIO.pmod:210: Expected: function(string, void | function({ Client = object }, function(mixed ... : void), string, mixed ... : void) : void). Erroneous warning: test-install/pike/8.1.11/lib/modules/Web.pmod/SocketIO.pmod:210: Got : function(string, void | function({ Client = object(implements program(/tmp/xenofarm/pike-devel/devel2.cuci.nl/buildtmp/Pike-v8.1-snapshot/build/linux-94.13.11-srb-asrock-00001-g90709e3b8a64-x86_64/test-install/pike/8.1.11/lib/modules/Web.pmod/SocketIO.pmod:255)) }, function(mixed ... : void), string, mixed ... : void) : void). Is that something that needs to be fixed in SocketIO.pmod? What does this warning even complain about? -- Stephen.

1 0

Concurrent flat_map() vs. map_with(), and depend()?
by Stephen R. van den Berg 06 Dec '17

06 Dec '17

Any comments on the map_with() I added to be preferred over flat_map() because it more consistently fits into the naming scheme with transform_with() and recover_with() ? How about the depend() functionality; does it fulfil all expectations? Anything else missing in Concurrent/Promises/Futures? If not, we might push it over to 8.0 together with the testsuite, since it does fix a few serious flaws in the current 8.0 implementation (the new fixes eliminate a few deadlock cases). -- Stephen.

2 2

Concurrent/Promises/Futures docs less scary?
by Stephen R. van den Berg 04 Dec '17

04 Dec '17

Anyone who has been scared away from Promises, should, I think, now take a look at the improved docs (still a lot of room for improvement there, like examples) in Pike 8.1. I changed the wording quite drastically to make it easier to digest. This time it might actually be understandable without feeling like a contortionist. -- Stephen.

1 0

Concurrent and avoid call_out() for most callbacks?
by Stephen R. van den Berg 03 Dec '17

03 Dec '17

In the old code, it was not possible to run the callbacks without incurring deadlocks. After the rewrite now, it's deadlock-free. I tested with and without the call_out() construct. In my testcases, I see: a. Comparable CPU usage for both cases. b. 6% wall-clock speed improvement when avoiding call_out(). I propose ripping out the call_out() method, so that callouts are ran directly in all cases except for the timeout-case. Any objections? -- Stephen.

2 5

A callback when main() returns with -1?
by Stephen R. van den Berg 02 Dec '17

02 Dec '17

Is there a callback when main() returns with -1 and drops into the DefaultBackend? If there is not, can we create one? -- Stephen.

1 1

HTTP.Promise2 vs. HTTP.Promise
by Stephen R. van den Berg 01 Dec '17

01 Dec '17

Are there many users of Protocols.HTTP.Promise already? I made a less filling version, with slightly changed API. The new one is called Protocols.HTTP.Promise2 at the moment; if there are no objections, I'd replace HTTP.Promise with this one. Most notable differences between HTTP.Promise2 and HTTP.Promise: a. Less filling (20% smaller compiled object file). b. Instead of two result objects, we simply have a single HTTP.Promise.Result object which is passed both on_success() and on_failure(). Why does the original separate this in a Promise.Success and Promise.Failure type? c. Various code optimisations, that do not change the interface. d. The Result object lacks the ok() method. What use was/is it? You should normally already know if you are a success or a failure callback. e. The Result object returns the raw body through "data", and the decoded body through get() (to conform more to standard Future objects). -- Stephen.

2 1

2026

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 December 2017