Pike-devel November 2017

pike-devel@lists.lysator.liu.se

7 participants
45 discussions

Re: Playing music using pike and SDL.
by Martin Nilsson (lvl 60) ＠ Pike (-) developers forum 13 Mar '26

13 Mar '26

Were you not able to get any C code to play through SDL either? Does your SDL library have a mixer compiled in it (I think it is optional)?

5 4

managing comport settings in linux
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 13 Mar '26

13 Mar '26

Not a good idea; the design philosophy of Pike is that Pike-level code should never be able to cause memory corruption at C-level. With ioctls there's no way to know what data a specific ioctl wants without reading the documentation for that specific ioctl for that specific OS. ioctls and fcntls are a way for device handlers to hook in APIs that aren't standard across all filedescriptors. / Henrik Grubbström (Lysator) Previous text: >2004-08-17 13:32: >Subject: managing comport settings in linux >-------------------------------------------------------------------- >What would be nice, is a way to define ioctl methods in >Pike. Perhaps something like > >object i = Stdio.IOCTL(4242 /* request_id */ ); >i->add_int_parameter(); >i->add_string_parameter(); >i->set_return_type(STRING); > >string ret = i(fd, 1, "somestring"); > > >That ought to be possible, or..? > > / Marcus Agehall (PacketFront) >

3 2

full MySQL 4.x support. or pike roadmap
by thomas.gusenleitner＠com-bet.com ＠ Pike developers forum 01 Mar '26

01 Mar '26

HI to all! mysql 4.x support works only with a mysql CFLAGS=-DUSE_OLD_FUNCTIONS is this correct ? are there plans to make a full 4.x support ? bye, thomas

4 4

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

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