Pike-devel December 2017

pike-devel@lists.lysator.liu.se

7 participants
31 discussions

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

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

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