Pike-devel March 2018

pike-devel@lists.lysator.liu.se

6 participants
8 discussions

Pike Meet-up 2018-Q1
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 20 Oct '21

20 Oct '21

Hi. At Pike Conference 2017 it was decided that we ought to hold a more informal meeting in Linköping ~ once every quarter. As the three month mark from the conference is coming up soon, it seems time to announce the first such meeting for 2018: Pike Meet-up 2018-Q1 Date: 2018-02-03 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB S:t Larsgatan 22A Linköping Welcome! /grubba

2 13

Operator assignment and strict_types
by Marc Simpson 07 Jul '20

07 Jul '20

Hi folks, It looks like operator assignment (op=), increment and decrement statements aren't subjected to the same typechecks as their more explicit equivalents. For example, neither the post-increment nor += statements below warn with strict_types enabled, even though they assign values outside of foo's restricted int domain: int(3..3) foo = 3; foo++; // no warning foo += 1; // no warning foo = foo + 1; // warning from strict_types Similarly, operator assignment on aggregates fails to elicit a warning: array(int) a = ({}); multiset(int) b = (<>); mapping(int:int) c = ([]); // no warnings a += ({ "hey" }); b += (< "hey" >); c += ([ "hey": "there" ]); // warnings from strict_types a = a + ({ "hey" }); b = b + (< "hey" >); c = c + ([ "hey": "there" ]); I'm guessing this is because the checks provided by the F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment; op= and friends are presumably not instrumented for strict_types in the same manner. Have there been any discussions around addressing this inconsistency? Thanks, Marc

3 3

Pike 8.0.528 release candidate
by Peter Bortas 11 May '18

11 May '18

As is tradition a release has been prepared at the new years party with Champagne in one hand and keyboard in the other waiting for the clock to hit 24:00. Pike 8.0.528 release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.528/Pike-v8.0.528.tar.gz Other builds: https://pike.lysator.liu.se/pub/pike/beta/8.0.528/Pike-v8.0.528-Darwin-15.4… https://pike.lysator.liu.se/pub/pike/beta/8.0.528/Pike-v8.0.528-win32-oldli… Real Mac build comes when Bill has time to have a look at that. Changes since Pike 8.0.498 (release 11) ---------------------------------------------------------------------- New Features ------------ o Sql.pgsql - Added support for PostgreSQL 10's stronger password authentication (SCRAM-SHA-256). - Slightly reduced overhead. - Support IEEE binary float database-wireformat. - Prevent new queries from starting in the local_backend. o Crypto.Hash.SCRAM New class to support SCRAM authentication. o Thread.ResourceCount New module to allow threadsafe race-condition-free counting of resources. o SSL.File Support query_fd() and set_buffer_mode() methods. o Toole.Standalone.check_http - Allow redirect responses. - Support --expect option. Bug fixes --------- o Compiler Improved variant robustness. o Calendar Updated tzdata to 2017c. o Crypto.CCM Fixed initialization of the iv. o Filesystem.Monitor - Fixed issue with next_poll being set to zero causing polling every second. - Fixed indexing the NULL value error when InotifyMonitor was used in combination with a filter_file() that doesn't accept everything. o HTTPLoop: Fixed some potential race conditions. o Image.Image - Improved argument checking in apply_curve(). Non-integer array values lead to use of uninitialized curve values. o Image.PVR Fixed size check for twiddled images. o MIME Support trailing newline in MIME part epilogues. o Protocols.HTTP Fixed incoming chunked transfers (timed async works now, chunk options are properly 'parsed'). o Protocols.LDAP Fixed race condition on initializing LDAPS. o Search.Utils Updated debug string format. o Sql.pgsql - Suppress spurious 'File not open' blurts on stderr when the connection is still pending and we inspect the connection object. - Signal EOF early before closing the SQL result portal and thoroughly cleanup bufcon/stashcount to prevent occasional deadlocks on asynchronous object destructions. - Suppress rare "access in destructed object" messages. - Rip out fundamentally flawed reconnect logic, made failures consistent. - Repair SSL connect logic. - Update documentation. - Repair fetch_row_array(). o mktime/System.TM Make timezone management consistent (especially UTC handling). o Standards.IIM Disabled debug output for unknown segment markers. o Stdio.send_file Improved support for TLS/SSL; wait for TLS handshake to complete before calling the sendfile done callback when sending an empty string. This fixes the issue where the connection got closed before TLS handshaking was completed, confusing the other side. o Image Creating images with mode "grey" now works as documented, e.g. Image.Image(10,10,"grey",123); Optimizations ------------- o mktime/System.TM Considerable speedup and a reduction in codesize. Building & Tools ---------------- o Image.SVG Fall back to using the unprefixed pkg-config if the arch-prefixed doesn't exist. o Mysql Support MariaDB 10.2 headerfiles. o precompile Support precompilation with Pike 8.1 again. o smartlink Fixed multiple issues on Darwin & NetBSD. o Whitefish Use the standard VPATH. o Yp Support using libtirpc. Glibc 2.26 has removed the Sun RPC implementation... Regards, -- Peter Bortas

5 12

Problems with premature close using Protocols.HTTP.Server.SSLPort
by H. William Welliver III 30 Mar '18

30 Mar '18

When in non-blocking mode, calls to SSL.File()->write() may return before data has actually been written to the underlying socket. For applications that close the connection immediately following a write() that completes the data to be sent, this can result in premature closure I/O errors on the receiving side. I first noticed this with some custom SSL code that I'd ported from 7.8, but it also manifests itself when using SSL with the built-in pike HTTP server. I've solved this problem in my code by waiting for the first write callback after sending the last data before closing the SSL.File object, which seems to work in my application. I've written a patch that does the same for Protocols.HTTP.Server.Request when my_fd is a SSL.File, and it seems to resolve the problem there as well. Does anyone have an objection to this approach? I'm not sure that this approach works for all situations, as I haven't yet looked to see if a write callback can occur while there is still data in the buffer to be written. Bill

1 0

Filesystem.Monitor race condition
by H. William Welliver III 21 Mar '18

21 Mar '18

I’ve noticed that when using Filesystem.Monitor on a system with inotify there is the possibility of monitors being created on paths that don’t exist. Specifically, if a directory is created and deleted in very rapid succession, the inotify events are processed after the directory is already gone. The resulting Monitors hang around forever (with their associated polls). It doesn’t appear that any events get triggered for this situation, though I can’t be absolutely sure because I’m not watching for directory changes. My concern is that these phantom monitors can build up over time. Does it make sense to check for the existence of something before monitoring it? I didn’t want to assume that was desirable because I suppose it’s possible someone might want to watch with the expectation that it will exist later… (maybe?) Bill

3 5

Re: sqlite bug in Pike 8.1?
by H. William Welliver III 20 Mar '18

20 Mar '18

OK, I think I found the cause of the problem. The SQL module in 8.1 does things quite differently than in 8.0... There's a common Connection class that all of the database drivers inherit. Its code is called when you use sprintf() style bindings and under the covers converts a query() to a big_query(), which returns a Result object which it then converts back to the array of mappings that you expect query() to return. That's where the problem occurred. The Result object is designed for interacting with databases that return results in a streaming manner. There was an interaction with they way SQLite works (there's no "execute query" function per-se, so you step through the results and it executes the query as part of the stepping process). The code in Connection that converts a Result into an array looked to see if there were any fields in the result, and if none were present, it just stopped. That resulted in the query never being executed for those that may not return any colums (such as inserts, updates and deletes). I changed this method so that it fetches the rows before checking for the columns. A result without fields will likely not return any rows, so this shouldn't be a problem for databases that have already executed the query by this point. On a side note, I'm concerned that the conversion of query() to big_query() for bindings that already provide query() may be a performance regression... for example, the SQLite binding generates the result array in C, which should be at least somewhat faster than the Pike code used by Connection. I also suspect that there could be result differences since the code paths are so drastically different. Is there a reason for query() not to use the driver provided query() when it exists? Bill March 19, 2018 11:57 AM, "Matthew Clarke" <pclar7(a)yahoo.co.uk (mailto:%22Matthew%20Clarke%22%20<pclar7(a)yahoo.co.uk>)> wrote: Hi No I'm afraid that update didn't fix the problem though it doesn't crash the system now - just silently fails to insert anything into the table. int main() { Sql.Sql conn = Sql.Sql("sqlite://mydb.db"); conn->query("create table t(id int)"); array arr = ({ 14, 3, 7, 9, 100, 20, 5, 12 }); foreach (arr, int x) { conn->query("insert into t(id) values(%d)", x); //conn->query("insert into t(id) values(:a)", ([":a":x])); } array arr2 = conn->query("select * from t"); write("num rows=%dn", sizeof(arr2)); return 0; } The second of those query() calls (commented out) works but not the sprintf-style version. Regards, Matthew On Sunday, 18 March 2018, 04:02:13 GMT, H. William Welliver III <william(a)welliver.org (mailto:william@welliver.org)> wrote: Hey… sorry for the delay, the week got away from me. As I was looking into this, I noticed that grubba may have fixed the problem earlier today (not sure if he told you directly). If a current checkout doesn’t resolve the problem for you, let me know. Bill On Mar 11, 2018, at 1:37 PM, Matthew Clarke <pclar7(a)yahoo.co.uk (mailto:pclar7@yahoo.co.uk)> wrote: Hi Bill I posted again but I'm not sure that went through either. So if I email you directly... Here's the example: int main() { Sql.Sql conn = Sql.Sql("sqlite://mydb.db"); conn->query("create table t(id int)"); array arr = ({ 14, 3, 7, 9, 100, 20, 5, 12 }); foreach (arr, int x) { conn->query("insert into t(id) values(%d)", x); } return 0; } Works on 8.0.498 but not on 8.1.12. On 8.1.12 you need to use the other version of the query() method: conn->query("insert into t(id) values(:var)", ([":var":x])); Thanks & regards, Matthew On Sunday, 11 March 2018, 15:36:02 GMT, H. William Welliver III <william(a)welliver.org (mailto:william@welliver.org)> wrote: Hi… I’m not sure if you meant to include code examples, but they didn’t come through, and I don’t see your post on nabble. Can you resend it? Some changes were made to the sqlite binding to bring them in line with the way the other database bindings wok. It’s possible the change broke something but I’ll have to see what you’re doing to know for sure :) Bill > On Mar 11, 2018, at 7:26 AM, larcky <pclar7(a)yahoo.co.uk (mailto:pclar7@yahoo.co.uk)> wrote: > > Hi > This works perfectly in stable 8.0.498 but crashes in 8.1.12. > > > > To get it to work in 8.1.12, you have to use the other version of the > 'query' method: > > > Would it be possible to get the 'sprintf' variant working again? > Thanks, larcky > > > > > -- > Sent from: http://pike.1058338.n5.nabble.com/Pike-User-f4601254.html (http://pike.1058338.n5.nabble.com/Pike-User-f4601254.html) >

1 0

Bug in aclocal.m4?
by Pontus Östlund 16 Mar '18

16 Mar '18

I found the following in aclocal.m4 if test "x$enable_binary" = "no"; then Allthough I'm lamer in comparison to most developers, in my world that can never evaluate to true. It's been like that since 2002-01-27. I have no idea what the code folloing the statement does in practice though. And then I saw the following in configure.in # Do the below even when --disable-binary is used, since we need a # real $CPP, and AC_PROG_CPP wants AC_PROG_CC to be called earlier. # $CC will be overridden with a dummy later on. # MY_AC_PROG_CC # The above has problems if the smartlink binary is removed. /grubba Which seems somewhat related? Now, I have no idea what this code does so maybe there's nothing to bother about. But from a glance it looked somewhat suspicious so I though I'd report it. Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69 www.roxen.com <http://www.roxen.com/> | twitter.com/roxen <https://twitter.com/roxen>

2 1

8.0 and precompiled pike files...
by Stephen R. van den Berg 07 Mar '18

07 Mar '18

The current git version of 8.0, but it has been this way for at least the past two months, works fine for me as long as I remove all *.o files from the installed version. If I do not do that, it crashes right away with a segmentation fault. It does not matter if I compile it with gcc 6, 7 or 8. Same result. Is that just on my system, or is this a generic .o file dumping problem in pike 8.0? I regularly compile with: --with-cdebug --without-rtldebug --without-valgrind --with-double-precision --with-long-int --disable-noopty-retry --with-machine-code --without-portable-bytecode -g -O2 on an amd64 linux system (devel2, to be exact, from pikefarm). -- Stephen.

1 2

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 March 2018