Pike-devel December 2017

pike-devel@lists.lysator.liu.se

7 participants
25 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

"Clean up stack in create": what is the practical difference?
by Stephen R. van den Berg 30 Dec '17

30 Dec '17

Does this mean that before this commit was in: ----------------- commit 65810c5a195a998bae51ced3518e1553e23f539d Author: Martin Nilsson <nilsson(a)fastmail.com> Date: Thu Dec 28 16:42:27 2017 +0100 Clena up stack in create ----------------- The stack objects lingered longer than necessary? -- Stephen.

2 2

dmalloc
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 28 Dec '17

28 Dec '17

There are a few regressions when running verify with dmalloc, if anyone has the time to take a look.

1 0

Port fixes to mktime() and System.TM() from 8.1 to 8.0?
by Stephen R. van den Berg 26 Dec '17

26 Dec '17

As a by-product of creating the Val.Timestamp (et al) types, I encountered numerous bugs and uncertainties in mktime() and System.TM() with regard to timezone handling/abuse. AFAICS, all these bugs have now been dealt with and fixed in 8.1. Any objections if I port these fixes from 8.1 to 8.0? It, incidentally, would allow us to git rid of some slow/undeterministic custom Pike-mktime() code (so the Pike footprint gets smaller, faster and deterministic with the fixes applied). -- Stephen.

2 2

Problem on SunOS 5.10 I cannot figure out
by Stephen R. van den Berg 24 Dec '17

24 Dec '17

Xenofarm machine: motoko.roxen.com (maybe others too) Git pike 8.1 Case in point: In the testsuite I created two entries: test_eq(mktime (33, 3, 12, 14, 6, 117, 0, 0), 1500033813); test_eq(mktime ((["sec":33, "min":3, "hour":12, "mday":14, "mon":6, "year":117, "timezone":0])), 1500033813); They should be equivalent. And they are (on other machines), but on this machine, they differ because of this code segment in src/builtin_functions.c (code shortened for readability, irrelevant parts omitted): ------------------------------------------ PMOD_EXPORT void f_mktime (INT32 args) { if(args == 1) { push_static_text("sec"); push_static_text("min"); push_static_text("hour"); push_static_text("mday"); push_static_text("mon"); push_static_text("year"); push_static_text("isdst"); push_static_text("timezone"); f_aggregate(8); f_rows(2); Pike_sp--; dmalloc_touch_svalue(Pike_sp); push_array_items(Pike_sp->u.array); args=8; } get_all_args("mktime",args, "%i%i%i%i%i%i.%i%i", &sec, &min, &hour, &mday, &mon, &year, &isdst, &tz); if((args > 7) && (SUBTYPEOF(Pike_sp[7-args]) == NUMBER_NUMBER)) { ------------------------------------------ It appears that when mktime() is called using 8 direct arguments, it works fine and (SUBTYPEOF(Pike_sp[7-args]) == NUMBER_NUMBER evaluates to true. However, if mktime() is called using a mapping as sole argument, it works fine on most machines, but on motoko/SunOS 5.1 then (SUBTYPEOF(Pike_sp[7-args]) == NUMBER_NUMBER evaluates to false? Any clues? I want to avoid debugging this through successive approximation and xenofarm. NUMBER_NUMBER seems to be defined to 0, BTW. -- Stephen.

1 3

Re: JSON5
by Chris Angelico 24 Dec '17

24 Dec '17

On Sun, Dec 24, 2017 at 10:58 AM, Martin Nilsson (Coppermist) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>Having taken a quick cursory look at the new JSON5 module, I think it >>would make sense to have a distinct decoder for JSON5, but have common >>code for the encoder. Having decode() and validate() call the >>appropriate implementation depending on flags. This would reduce the >>amount of code duplication, and ensure that the flags used by the >>modules stay compatible. >> > > I think it makes sense to have JSON and JSON5 exposed as different > modules, since presumably you know which version of JSON you are > processing. In JSON5 you can encode more compact than JSON, and there > is support for inf/nan, so you want different encoder behaviour. If they can share common code, it might be good to have them in one module, with encode_json5 and decode_json5. AIUI, if you're not sure which one you're decoding, you can decode as JSON5, as it's a strict superset of JSON. ChrisA

1 0

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

24 Dec '17

I doubt anyone will know the answer to this, as it's in 12+ year old code in the GTK2 module, but the destroy method (now renamed to _destruct) was explicitly checking that it received exactly zero args before calling gtk_object_destroy. Any idea why? Is there a situation in which destroy() might have been called with arguments, such that it shouldn't actually destroy anything? I've removed the check, and now GTK2 apps correctly clean up their underlying objects when they're destroyed. But I'm hoping this hasn't reintroduced an old problem somewhere. ChrisA

4 4

JSON5
by H. William Welliver III 23 Dec '17

23 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

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