Pike-devel December 2017

pike-devel@lists.lysator.liu.se

7 participants
28 discussions

JSON5
by H. William Welliver III 24 Dec '17

24 Dec '17

I was thinking that it might be nice to support parsing JSON5[1] documents (and a few of the additions, such as trailing commas in arrays and objects already seem to work). My initial thought before looking at Standards.JSON was that the additional feature support would be enabled by a flag to Standards.JSON.decode(). After looking at the ragel parser and the differences in the grammar, I'm wondering if it might be better to just create a new parser for JSON5. I suppose it would be possible to use a feature flag to select the parser but the overall architecture question remains. Any thoughts? Bill [1] http://json5.org

5 6

Parser.XML.Simple is gone?
by Stephen R. van den Berg 23 Dec '17

23 Dec '17

Parser.XML.Simple seems to be lost in Pike-git 8.1. -- Stephen.

3 4

Re: GTK2.Object()->destroy() checking for no args?
by Chris Angelico 22 Dec '17

22 Dec '17

On Sat, Dec 23, 2017 at 2:11 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>On Sat, Dec 23, 2017 at 12:42 AM, Henrik Grubbström (Lysator) @ Pike >>(-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>> Note that AFAIK destruct() in some GTK2 classes is a public function >>> (and thus part of the API). >> >>Do you mean destroy? It got renamed in the big _destruct rename, and > > Yes, the LFUN got renamed. The GTK2 API function however did not. > >>it was because I'd been using it that I started poking around and >>finding this. But I'm quite okay with the API being "destruct(obj)" >>rather than "obj->destroy()", as long as it works reliably. > > Using _destruct() for this kind of stuff is NOT a good idea as it gets > called in a signal context. Hmm. But there needs to be _something_ to cope with object abandonment, otherwise a long-running process risks leaking resources. So what SHOULD apps do? Not forgetting that an app may have to support multiple Pike versions (currently I try to support 7.8->8.1), so breaking changes have a cost. ChrisA

3 4

Re: GTK2.Object()->destroy() checking for no args?
by Chris Angelico 22 Dec '17

22 Dec '17

On Sat, Dec 23, 2017 at 12:42 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Note that AFAIK destruct() in some GTK2 classes is a public function > (and thus part of the API). Do you mean destroy? It got renamed in the big _destruct rename, and it was because I'd been using it that I started poking around and finding this. But I'm quite okay with the API being "destruct(obj)" rather than "obj->destroy()", as long as it works reliably. ChrisA

3 2

>2038 mktime tests
by Stephen R. van den Berg 22 Dec '17

22 Dec '17

To avoid failed tests on systems with a 32-bit time_t, you should either make the tests for time_t values >=2^31 conditional on the width of time_t, or they should be changed to avoid testing beyond 2038? -- Stephen.

2 3

Re: Calendar does not seem to use mktime()/localtime()/gmtime()
by Chris Angelico 14 Dec '17

14 Dec '17

On Fri, Dec 15, 2017 at 12:41 AM, Peter Bortas @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: > While true, for actual Pike installations 64bit dominate. The number > of Pike mobile applications are quite low. By "quite low" do you actually mean zero, or is there actually such a thing as Pike-for-mobile? ChrisA

1 0

Calendar does not seem to use mktime()/localtime()/gmtime()
by Stephen R. van den Berg 14 Dec '17

14 Dec '17

Is there a reason for that? Because it seems that the functionality of mktime/localtime/gmtime is being reimplemented/duplicated alongside the daylight-saving tables which should be identical as provided in libc? -- Stephen.

4 8

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 12 Dec '17

12 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

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