Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

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

SCRAM and docs
by Stephen R. van den Berg 01 Dec '17

01 Dec '17

Two things: a. I see a remark about making that cache-mapping weak. What would that help (it contains strings only)? b. Where did the docs go? I can't seem to find them anywhere. -- Stephen.

2 3

Concurrent.Future.zip() ?
by Stephen R. van den Berg 29 Nov '17

29 Nov '17

What reference documentation was used to determine how that method should work exactly? -- Stephen.

4 16

Sql.FutureResult, an Sql.Connection Concurrent.Promise interface
by Stephen R. van den Berg 27 Nov '17

27 Nov '17

Utilising the momentum, I whipped out a Concurrent.Promise interface for Sql.Connection in git Pike 8.1. The included examples in the docs could still use some love. Other than that, I thought this was a reasonable attempt at a sane interface between promises and SQL. Lame sample code: int main() { db = Sql.Sql(DBNGURL); Concurrent.Future q1 = db->promise_query("SELECT :bar::INT b", (["bar":3])); Concurrent.Future q2 = db->promise_query("SELECT :foo::INT f", (["foo":4])); array all = ({q1, q2}); all->on_success(lambda (Sql.FutureResult okresp) { werror("#########################Ok result %O %O\n", okresp, okresp->data); }); all->on_failure(lambda (Sql.FutureResult okresp) { werror("##########################Failed result %O\n", okresp); }); return -1; } Promises only work with the default backend running. I have tested this with pgsql only, but it should work with any database backend. Any critisism, suggestions and/or improvements are welcome. -- Stephen.

3 11

Re: Proposed improvements to Hilfe
by Chris Angelico 23 Nov '17

23 Nov '17

On Thu, Nov 23, 2017 at 8:44 AM, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>The other is the addition of a new help() built-in function, which >>gives human-readable information about whatever object it's given. >>Currently it shows a little information about functions and programs, >>and not much else; the intent is that it can be expanded at will, >>since it's purely human-readable. There is no backwards-compatibility >>guarantee about its specific output format. > > This sounds like it might overlap with the existing "doc" function? I'm not sure. help() is designed to work at runtime; doc doesn't seem to do much with functions and such, and I've never actually used it. In my help() code, I have a TODO about having a command for it. Maybe the doc command could call help() in situations where that makes sense? I've rebased the rosuav/hilfe-improvements branch onto current 8.1, so it's once again mergeable if this is of interest. The smaller change of suppressing quit/exit is merged into 8.1, leaving help() unmerged as yet. ChrisA

1 0

Faster Calls
by Arne Goedeke 23 Nov '17

23 Nov '17

I have pushed a new version of the faster calls branch. I readded support for profiling. I also fixed one more open bug. Of course there may more more. Performance-wise the situation did not change since the conference, but I have done some experimentation to improve it. One follow-up change will probably be a re-work of the function call API used from within interpreter. I also want to add more tail call optimizations where missing. Current comparison to 8.1 on my intel: interpreter/automap.pike#efun | 27.8 M 0.4 % | 41.1 M 0.6 % | interpreter/automap.pike#private | 17.3 M 0.7 % | 25.8 M 0.3 % | interpreter/automap.pike#public | 17.6 M 0.2 % | 26.1 M 0.1 % | interpreter/call.pike#efun |173.9 M 0.6 % |171.6 M 0.8 % | interpreter/call.pike#index | 15.7 M 0.4 % | 14.3 M 0.4 % | interpreter/call.pike#private | 20.9 M 0.5 % | 18.7 M 0.2 % | interpreter/call.pike#public | 21.1 M 0.2 % | 18.6 M 0.4 % | interpreter/call_array.pike#efun | 23.7 M 0.1 % | 34.1 M 0.3 % | interpreter/call_array.pike#private | 15.6 M 0.3 % | 14.1 M 0.1 % | interpreter/call_array.pike#public | 15.3 M 0.3 % | 14.0 M 0.1 % | interpreter/map.pike#efun | 41.8 M 0.4 % | 37.0 M 0.5 % | interpreter/map.pike#private | 15.7 M 0.5 % | 22.9 M 0.4 % | interpreter/map.pike#public | 16.0 M 0.1 % | 22.9 M 0.2 % | interpreter/recurse.pike#private | 27.9 M 0.4 % | 38.1 M 0.3 % | interpreter/recurse.pike#public | 27.7 M 0.2 % | 37.2 M 0.7 % | interpreter/tailcall.pike#private | 20.6 M 0.4 % | 31.4 M 0.4 % | interpreter/tailcall.pike#public | 21.0 M 0.2 % | 30.7 M 0.5 % | As you can see, the only slow-downs currently are in standard lfun calls. I believe this can be fixed using some refactoring of the corresponding opcodes. I believe that we can also come up with a simpler API which can more easily be called directly from machine code. I think the branch is now in a state in which it could be merged into 8.1. I expect that there are still some issues which will come up when running more complex code bases. I did write a test-suite which tries to cover all different function call types and I will integrate that into the standard testsuite soon. Unless anyone sees any issue with the code as it stands, I will use the decision reached during the conference and merge this within the next week or so. Arne

3 4

Re: Proposed improvements to Hilfe
by Chris Angelico 23 Nov '17

23 Nov '17

On Thu, Nov 23, 2017 at 8:44 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>Branch: rosuav/hilfe-improvements >> >>Two smallish improvements to Hilfe. One is suppressing "quit" and >>"exit", per the TODO at the top; fairly simple but I'd like someone >>else's eyeballing to make sure it's going about things the right way. > > Do you handle the case where the user ends the session with EOF (ie > usually ^D) correctly? > > /grubba Yes; the readline history-pop function takes an optional string argument of the string to pop, and will do nothing if the last history element is not that exact string. So if you key an EOF, or if you terminate Hilfe in some other way, the history pop will silently do nothing. ChrisA

1 0

"old" mails on the list
by Peter Bortas 22 Nov '17

22 Nov '17

Hello list subscribers, I finally took over responsibility for the LysKOM exporter, and ran it through the backlog. Which means you just got a bunch of new mails that have a send date of today but might have been written months and months ago in LysKOM. From now on the exporter will export new texts every few minutes. Regards, -- Peter Bortas, NSC

2 1

Jump to page:

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