Pike-devel November 2017

pike-devel@lists.lysator.liu.se

7 participants
42 discussions

GTK/GDK on OSX
by H William Wellliver III 08 Jan '18

08 Jan '18

I’m running into some build problems on OSX. It seems that the GTK module assumes that if a system is NT that gdkwin.h is used and otherwise gdkx.h is used. Unfortunately, it seems that on some builds of GTK/GDK for OS X, neither of those is correct and that gdkquartz.h should be used. I’m guessing that some configure tests are needed to determine which of the 3 files is actually present. However a quick look at configure.in leaves me unsure how best to include that. Anyone with more expertise in the GTK module’s inner workings care to weigh in? Bill

4 9

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

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

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 2017