Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Benchmark output
by Per Hedbor () ＠ Pike (-) developers forum 16 Aug '13

16 Aug '13

Is anyone seriously attached to the current pike -x benchmark format/output? I have done some work to a: Only output relevant information b: Actually output relevant information. Additionally I have added a json output mode, and a way to run a benchmark with an old result as the baseline (and then report differences, useful when you are trying to optimize something). What is left of the output is somewhat sparse, though. The perhaps most important part that is missing is the memory usage, but it was rather .. random before, since it counted the memory use _after_ the benchmark was run. # leopard$ make benchmark BENCHARGS="-c $PWD/compare" (...) ----------------------------------------------------------------- Test Result Change ----------------------------------------------------------------- Ackermann . . . . . . . . . . . . . . . . . . . . . 38M/s -0.1% Append array . . . . . . . . . . . . . . . . . . . 23M/s -0.1% Append mapping (+) . . . . . . . . . . . . . . . 4902k/s 0.2% Append mapping (|) . . . . . . . . . . . . . . . 5571k/s 6.3% Append multiset . . . . . . . . . . . . . . . . . . 105k/s -3.3% Array & String Juggling . . . . . . . . . . . . . . 110k/s -4.8% Array Copy . . . . . . . . . . . . . . . . . . . . 41M/s 2.0% Array Zero . . . . . . . . . . . . . . . . . . . . 285k/s 0.0% Binary Trees . . . . . . . . . . . . . . . . . . . 994k/s 3.3% Clone null-object . . . . . . . . . . . . . . . . . 11M/s 1.1% Clone object . . . . . . . . . . . . . . . . . . 5627k/s -9.4% Compile . . . . . . . . . . . . . . . . . . . 97k lines/s -0.1% Compile & Exec . . . . . . . . . . . . . . . 92k lines/s -0.3% Foreach (arr,global) . . . . . . . . . . . . . . . 71M/s -2.6% Foreach (arr,local) . . . . . . . . . . . . . . . . 174M/s 1.4% Foreach (arr;local;global) . . . . . . . . . . . . 37M/s -1.1% Foreach (arr;local;local) . . . . . . . . . . . . . 52M/s 1.0% GC . . . . . . . . . . . . . . . . . . . . . . . . 1197/s 2.2% Insert in array . . . . . . . . . . . . . . . . . . 48M/s 0.4% Insert in mapping . . . . . . . . . . . . . . . . . 10M/s -2.2% Insert in multiset . . . . . . . . . . . . . . . 3868k/s 2.4% Loops Nested (global) . . . . . . . . . . . . . . . 31M/s 2.9% Loops Nested (local) . . . . . . . . . . . . . . . 181M/s -0.4% Loops Nested (local,var) . . . . . . . . . . . . . 161M/s -2.0% Loops Recursed . . . . . . . . . . . . . . . . . . 18M/s 1.1% Matrix multiplication (100x100) . . . . . . . . 2.23 GF/s 1.9% Read binary INT128 . . . . . . . . . . . . . . . . 197k/s -0.9% Read binary INT16 . . . . . . . . . . . . . . . . . 19M/s 20.1% Read binary INT32 . . . . . . . . . . . . . . . . . 17M/s -2.0% Replace (parallel) . . . . . . . . . . . . . . . . 9831/s 5.0% Replace (serial) . . . . . . . . . . . . . . . . . 13k/s -2.6% Sort equal integers . . . . . . . . . . . . . . . . 59M/s -0.9% Sort ordered integers . . . . . . . . . . . . . . . 88M/s -0.1% Sort unordered integers . . . . . . . . . . . . . . 14M/s 3.9% Sort unordered objects . . . . . . . . . . . . . . 569k/s -2.2% String Creation . . . . . . . . . . . . . . . . . 3053k/s -8.1% String Creation (existing) . . . . . . . . . . . . 10M/s 1.9% String Creation (wide) . . . . . . . . . . . . . . 678k/s 1.9% Tag removal u. Parser.HTML . . . . . . . . . . . 4929k/s 3.5% Tag removal u. Regexp.PCRE . . . . . . . . . . . 2124k/s 1.4% Tag removal u. array_sscanf . . . . . . . . . . . 6150k/s -0.2% Tag removal u. division . . . . . . . . . . . . . 3113k/s -1.5% Tag removal u. search . . . . . . . . . . . . . . 5218k/s -2.9% Tag removal using a loop . . . . . . . . . . . . . 895k/s -2.3% Tag removal using sscanf . . . . . . . . . . . . . 718k/s 2.7% Upper/lower case shift 0 . . . . . . . . . . . . . 137M/s -0.3% Upper/lower case shift 1 . . . . . . . . . . . . . 60M/s -1.4% call_out handling . . . . . . . . . . . . . . . . . 177k/s 0.2% call_out handling (with id) . . . . . . . . . . . 4560k/s -2.4% ----------------------------------------------------------------- 0.3% -----------------------------------------------------------------

5 6

Calender question.
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 14 Aug '13

14 Aug '13

If you create a Day and call next() it will not have all fields calculated. It looks intentional, but is it useful? Pike v7.9 release 11 running Hilfe v3.5 (Incremental Pike Frontend) > object d = Calendar.ISO.Day(2013,8,14); > object e = d->next(); > e->md; (1) Result: -1000 > e->m; (2) Result: -1000 > e->make_month(); (3) Result: 0 > e->md; (4) Result: 15 > e->m; (5) Result: 8 or to put it in more surprising terms > object d = Calendar.ISO.Day(2013,8,14)->next(); > d->m; (1) Result: -1000 > d; // Forces _sprintf to call make_month() (2) Result: Day(Thu 15 Aug 2013) > d->m; (3) Result: 8

2 3

beginning a new Pike 7.8 release cycle
by Bill Welliver 12 Jul '13

12 Jul '13

It's been a bit over 9 months since the last 7.8 release, and a number of fixes have been applied to the 7.8 tree. Therefore, I'd like to begin the process of making another 7.8 stable release. I will begin working on the changelog during the next week; once that's complete, I'll cut an alpha release for review and consideration. If you've been saving any bugfixes for 7.8, please start thinking about getting those committed. Thanks! Bill

1 0

Thread deprecation
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 09 Jul '13

09 Jul '13

The deprecation of Thread->`() doesn't look to work as it should. bin/pike -e Thread lib/modules/Thread.pmod:9: Warning: Using deprecated function(mixed, mixed ... : { Thread = object(implements _static_modules.Builtin()->thread_id) }) value. lib/modules/Thread.pmod:10: Warning: Using deprecated function(mixed, mixed ... : { Thread = object(implements _static_modules.Builtin()->thread_id) }) value.

2 1

DEBUG_MALLOC
by Arne Goedeke 30 Jun '13

30 Jun '13

I was trying to replace the BLOCK_ALLOC usage in pike_memory.c DEBUG_MALLOC mode. Unfortunately, since it uses the block allocator in its malloc tracer, which in turn calls malloc, that results in a deadlock. From what I can tell, that problem was already present when using the old "block_alloc.h", but it wasnt triggered since memory pages are preallocated. Before I try to work around that: What kinds of malloc misuses and memory access errors will DEBUG_MALLOC actually detect, which valgrind won't? Is it something we want to keep? arne

2 1

Pike 8
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 17 Jun '13

17 Jun '13

This Saturday we had a short (6 hours) Pike meeting in Linköping where we discussed what we would like to do with the langauge for the near future. The two topics were basically (besides trading ideas and discussions in general) what we need to do to make the next release in shortest amount of time, and what we would like to do for the next immediate release. The consensus was to attempt to push for a 8.0 release, given the large amount of changes since 7.0, and to make that release with the current feature set. The task list for that on a high level is - Fork a 8.0 and next branch (9.0?) soonish (within a week?) - Fix compilation issues. This basically boils down to a requirement on version 4 of GCC and to remove redundant configure tests that today prevents correct behavior. - Fix the testsuite. There are not very many issues that needs to be fixed, but they have been around for a while, suggesting that they may be tricky to fix, or at least requires a time investment from someone knowledgable. We have a few type system issues, a scope issue with inherit, a test case that breaks the pike stack and broken dumped file system. - Valgrind currently takes issue with a few of the tests. Check if these are real and fix them. - We have a few documentation issues reported by the autodoc extractor. These should be fixed. - Test that exported source and exported builds compile/installs/work. - Set up Xenofarm to build Pike 8. - Check if there are obvious performance regressions from 7.8, and address them if that appears to be easy. - And everyones favorite; Write a changelog. For the next version of Pike we want to be more explicit about supported operating systems. Linux, Solaris, MacOS, Windows and, if Marcus supports it, AmigaOS. - Remove configure and transition to a profile based system where a pike script generates header files. - Remove the compat system, as it creates a lot of maintenance overhead, ugly code and is of dubious value in practice. - Consider removing the less used C modules to cut down on dependenices and compilation time. DVB, Mird, spider and PDF were mentioned as examples. - Remove the Pike security system. This is not maintained and would simplify the code. - Remove the bundle system. All the bundle dependencies are now available as packages and most are already installed by default. - Make support for bignums mandatory, to remove all ifdef bignum code. - Remove support for old systems (e.g. outdated code in port.c) - Remove short svalue support. - Remove Fd_ref from Stdio.File, currently implemented under STDIO_DIRECT_FD define. - Implement typed constants. - Implement "operator" as an alternative syntax for "`". - Replace block alloc with a single (and better) implementation. - Remove local calendar locale configuration support. - Split mega apply into a pike and a C version to speed up calls between pike functions. - Remove the mark stack. - Renumber the types so that PIKE_T_INT becomes 0. Any item that makes the release of 8.0 easier and faster should be done there rather than later.

6 27

Pike on Hurd
by Magnus Holmgren 07 Jun '13

07 Jun '13

Trying to get Pike (7.8.700 still) to compile on Debian GNU/Hurd (which was officially released(!) on May 23, for some value of "released"), I found three issues: 1. PATH_MAX used as the size of the buffer passed to realpath() in system.c. pathnames can be arbirarily long on Hurd, so one should in this instance pass NULL to realpath and let it allocate the returned string itself. 2. mach/message.h, which defines mach_msg_type_number_t, is not included by mach/task_info.h (or either of the other two .h files); we have to include it ourselves directly. 3. The GTK2 module uses a couple of Xlib functions without explicitly linking with -lX11, instead relying on the GTK libs to pull it in. This practice is discouraged/deprecated, but apparently still works with the toolchains on most of the architectures; I don't know why Debian GNU/Hurd is different in this regard. I've created a patch that addresses these issues, but I'm not sure if it integrates in the most clean way. It's also untested, because pike dies right away when run to generate the documentation (I've: uncommented the several fprintf calls in object.c): Need a new master object... Builtin_constants: 0x871ae3c Cannot load master object yet! /home/holmgren/pike7.8-7.8.700/src/object.c:695: Fatal error: Couldn't load master object. No stack - no backtrace. Backtrace from gdb: #9 0x08144d47 in debug_fatal (fmt=fmt@entry=0x84b6eb7 "Couldn't load master object.\n") at /home/holmgren/pike7.8-7.8.700/src/error.c:654 #10 0x08186ce9 in debug_master () at /home/holmgren/pike7.8-7.8.700/src/object.c:695 #11 0x083beca9 in resolve_syms () at /Users/hww3/pike- build/src/post_modules/GSSAPI/gssapi.cmod:434 #12 0x083bf12d in get_dd_oid (gss_oid=0x182d8c0) at /Users/hww3/pike- build/src/post_modules/GSSAPI/gssapi.cmod:351 #13 0x083ca9c8 in pike_module_GSSAPI_init () at /Users/hww3/pike- build/src/post_modules/GSSAPI/gssapi.cmod:4450 #14 0x082106d7 in init_modules () at /home/holmgren/pike7.8-7.8.700/src/module.c:424 #15 0x0817b7a5 in init_pike_runtime (exit_cb=0x80e6f00 <exit@plt>) at /home/holmgren/pike7.8-7.8.700/src/pike_embed.c:418 #16 0x080e8f1d in main (argc=4, argv=0x3dffd68) at /home/holmgren/pike7.8-7.8.700/src/main.c:610 It seems that _static_modules isn't set yet. Any idea why? Or rather, why is debug_master() called while initializing the static modules? Oh, now I know! The problem is of course that the modules aren't being linked dynamically at all. That's probably the reason behind issue #3, too. I guess there's been some code rot because nobody ever links the modules statically. You might want to look into why static modules don't work - but probably not... -- Magnus Holmgren holmgren(a)debian.org Debian Developer

3 4

FYI/RFC: Variant functions in Pike 7.9
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 28 May '13

28 May '13

FYI: The support for variant function (aka polymorphic overloading) has now reached a semi-useable state in Pike 7.9: | Pike v7.9 release 5 running Hilfe v3.5 (Incremental Pike Frontend) | > class foo { | >> variant int bar(int a) { return a*2; } | >> variant string bar(string s) { return "FOO" + s + "FOO"; } | >> variant string bar() { return "FOO"; } | >> } | > typeof(foo()->bar); | (1) Result: function( : string) | function(int : int) | function(string : string) | > foo()->bar(17); | (2) Result: 34 | > foo()->bar("BAR"); | (3) Result: "FOOBARFOO" | > foo()->bar(); | (4) Result: "FOO" | > foo()->bar(1.2); | Compiler Error: 1: Bad argument 1 to bar. | Compiler Error: 1: Expected: string | int. | Compiler Error: 1: Got : float. | > foo()->bar((mixed)1.2); | Invalid arguments to bar()! | HilfeInput:1: HilfeInput()->foo()->bar(1.2) | HilfeInput:1: HilfeInput()->___HilfeWrapper() I would appreciate feedback especially regarding the expected semantics for: * When the variants have different modifiers (protected, private, etc). * When there's a function without the variant keyword. * When the types for the variants aren't disjunct. * When overriding X from an inherit with a variant function. - A non-variant function. - A variant function with a new definition with the same type. - A variant function with a new definition with a different type. * Should the previous definition be accessible in any of the above cases, or only if there's an explicit trampoline? * Multiple inherits of variant functions. - With the same types. - With different types. I've probably forgotten or not thought of some cases, please mention the expected semantics for these as well. /grubba

4 4

Fwd: Bug#708366: pike7.8: FTBFS due to conflicting REG_* definitions
by Magnus Holmgren 26 May '13

26 May '13

OK, so now all of REG_EAX, REG_EBX and so on are defined on Linux, or rather, in the newest eglibc. Do you prefer renaming the enum items or #undef-ing all of them? ---------- Forwarded message ---------- Subject: Bug#708366: pike7.8: FTBFS due to conflicting REG_* definitions Date: onsdagen den 15 maj 2013 From: Colin Watson <cjwatson(a)ubuntu.com> To: submit(a)bugs.debian.org Package: pike7.8 Version: 7.8.700-2 Severity: serious User: ubuntu-devel(a)lists.ubuntu.com Usertags: origin-ubuntu saucy pike7.8 fails to build in unstable as follows: Compiling pikecode.c In file included from /«PKGBUILDDIR»/src/pikecode.c:25:0: /«PKGBUILDDIR»/src/code/ia32.c:22:16: error: redeclaration of enumerator 'REG_EAX' In file included from /usr/include/signal.h:360:0, from /usr/include/i386-linux-gnu/sys/param.h:28, from /«PKGBUILDDIR»/src/pike_macros.h:14, from /«PKGBUILDDIR»/src/program.h:12, from /«PKGBUILDDIR»/src/pikecode.c:15: /usr/include/i386-linux-gnu/sys/ucontext.h:180:3: note: previous definition of 'REG_EAX' was here In file included from /«PKGBUILDDIR»/src/pikecode.c:25:0: /«PKGBUILDDIR»/src/code/ia32.c:22:29: error: redeclaration of enumerator 'REG_EBX' In file included from /usr/include/signal.h:360:0, from /usr/include/i386-linux-gnu/sys/param.h:28, from /«PKGBUILDDIR»/src/pike_macros.h:14, from /«PKGBUILDDIR»/src/program.h:12, from /«PKGBUILDDIR»/src/pikecode.c:15: /usr/include/i386-linux-gnu/sys/ucontext.h:174:3: note: previous definition of 'REG_EBX' was here *snip* It looks painful to reliably avoid the enumeration values in <sys/ucontext.h>. I suggest simply renaming Pike's enumeration values. Thanks, -- Colin Watson [cjwatson(a)ubuntu.com] ------------------------------------------------------- -- Magnus Holmgren holmgren(a)debian.org Debian Developer

2 2

callback support for encoding JSON
by Martin Bähr 24 May '13

24 May '13

hi, the JSON module can only encode objects if they provide an encode_json function. i find this a bit limiting because it is hardly possible to add encode_json to all classes that would need it. better would be to allow the caller of JSON.encode provide a callback for objects that the module can't handle by itself. it seems to me the simplest would be to add an argument to JSON.encode to allow passing a function. and then call that function of the object has none of its own. i am unfamiliar with CMODs but i think in src/post_modules/JSON/json.cmod i need to add the function to the encode_context and then call it in the PIKE_T_OBJECT case. also what i am wondering is, should i store the whole svalue for the function or just the functionpointer itself? (is that u.efun->function?) greetings, martin.

5 19

Jump to page:

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