Pike-devel January 2006

pike-devel@lists.lysator.liu.se

8 participants
36 discussions

gtk2
by lance dillon 26 Jan '06

26 Jan '06

I did an autoscan on the GTK2 directory, and came up with this: configure.in: warning: missing AC_CHECK_TYPES([ptrdiff_t]) wanted by: pgtk.h:80 configure.in: warning: missing AC_C_CONST wanted by: pgtk.h:107 configure.in: warning: missing AC_PREREQ wanted by: autoscan configure.in: warning: missing AC_PROG_LN_S wanted by: Makefile.in:50 It created a configure.scan, which had the following options added: AC_PREREQ(2.59) AC_PROG_CC AC_PROG_LN_S AC_C_CONST AC_C_INLINE AC_CHECK_TYPES([ptrdiff_t]) Are any of these necessary, or should we put some of them in the configure.in and modify pgtk.h and Makefile.in accordingly?

2 1

destructors take an argument now?
by Adam Montague 22 Jan '06

22 Jan '06

I just realized my ClearSilver module doesn't work under pike 7.7 because destroy() is being called with a single int argument now instead of nothing. Is this supposed to be the case? And what does the argument mean? Adam

2 1

mapping_rehash_backwards_{good,evil} rewrite
by Peter Bortas ＠ Pike developers forum 22 Jan '06

22 Jan '06

Commend him even, not comment...

1 0

mapping_rehash_backwards_{good,evil} rewrite
by Peter Bortas ＠ Pike developers forum 22 Jan '06

22 Jan '06

I see Jonas backported the mapping_rehash-rewrite grubba did in 7.7 to 7.6 and 7.4. This is probably good, but is there no testcase for the problem it should fix?

2 4

GTK2.Databox
by lance dillon 20 Jan '06

20 Jan '06

Another bug I found in 7.7 cvs, I think. The latest change (1.6) changes push_text() to ref_push_string(_STR()). Unfortunately, those were in a %{ %} block, which gets passed untranslated I believe. So, _STR() didn't get translated to the correct code, and GTK2.setup_gtk() returns with an undefined symbol: _STR. It should either get changed back to push_text(), or maybe to something else.

2 2

GTK2
by lance dillon 20 Jan '06

20 Jan '06

I think there is a type in gdkevent.pre in 7.7 (I don't have access to cvs from my work here, so I'm posting it here instead). The latest changes to gdkevent.pre on http://pike.ida.liu.se/development/cvs/pike.xml?between=2006-01-16&and=2006… At the bottom, case GDK_CLIENT_EVENT: - ref_push_string(s_data ); + ref_push_string(_STR("data ")); I think that should just be "data", not "data ".

2 1

patch to add affected_rows to Postgres
by Adam Montague 20 Jan '06

20 Jan '06

This adds an affected_rows() method to the Postgres module, which should behave just like the Mysql affected_rows() method. Also, should both of these methods have wrappers in the Sql.Mysql and Sql.Postgres modules so you don't need to call db->master_sql->affected_rows()? Adam

2 3

Fw: Protocols.SNMP.protocol()->readmsg hanging
by Adam Montague 19 Jan '06

19 Jan '06

Can this get all the way committed? The function args got changed, but the timeout still isn't actually used. Since UDP packets can go AWOL any time, you need to be able to set a timeout so you don't have your app waiting indefinately for UDP packets that will never arrive. Begin forwarded message: Date: Fri, 25 Nov 2005 17:16:14 -0500 From: Adam Montague <amontague(a)siriushosting.com> To: pikedevel <pike-devel(a)lists.lysator.liu.se> Subject: Protocols.SNMP.protocol()->readmsg hanging Protocols.SNMP.protocol()->readmsg waits forever trying to read from the socket. The problem is you can send out a request on a lossy link, then try to readmsg() it, and never get an answer, hanging your script. I've attached a tiny patch to add an optional int|void timeout to readmsg(). Adam

1 0

Null objects for postgresql (patch)
by Adam Montague 19 Jan '06

19 Jan '06

Here's a patch to add a Postgres.NULL object, and use it when results are NULL instead of returning "0". Adam

3 3

tracking lockups in Caudium on 7.6.50
by H.William Welliver III 16 Jan '06

16 Jan '06

A number of us who are running caudium on 7.6.50 have been experiencing what I'll describe as "lockups" on a pretty frequent basis. Normally, the watchdog will kill the process and restart things, but I wanted to figure out what was causing the problem. I managed to catch the hangup on my server a few minutes ago, and this is what I get: Describing all threads: Thread 1: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(2) Thread 2: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(3) Thread 3: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(4) Thread 4: _static_modules.Builtin()->thread_id: Thread.Thread(1)->backtrace() base_server/caudium.pike:3493: /opt/caudium/server/base_server/caudium ()->describe_all_threads() Stdio.File: Stdio.File("socket", "63.85.143.88 1198", 777 /* fd=103 */)->set_write_callback(Stdio.File("socket", "63.85.143.88 1198", 777 /* fd=103 */)$ /usr/local/pike/7.6.50/lib/modules/Stdio.pmod/module.pmod:1097: Stdio.File("socket", "63.85.143.88 1198", 777 /* fd=103 */)- >set_write_callback(SSL.ssl$ /usr/local/pike/7.6.50/lib/modules/SSL.pmod/sslfile.pike:1321: SSL.sslfile(Fd(103))->direct_write() /usr/local/pike/7.6.50/lib/modules/SSL.pmod/sslfile.pike:516: SSL.sslfile(Fd(103))->close(UNDEFINED,UNDEFINED) protocols/http.pike:812: /opt/caudium/server/protocols/ssl3()->end (0,UNDEFINED) _static_modules.Builtin()->Backend: Pike.Backend(0)->`()(0) /usr/local/pike/7.6.50/lib/master.pike:2703: master()->_main(({"/usr/ local/bin/pike","-DENABLE_THREADS","-DCAUDIUM","-DCAUDIUM_CACHE","- DROXEN","-Ietc/$ Thread 5: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(0) Thread 6: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(1) The hangup appears to be: Thread.Queue()->read() I also did a truss to see what the threads were up to, and here's what I got: bash-2.05$ sudo truss -p 26891 /1: ioctl(105, DP_POLL, 0xFFBFE8B8) (sleeping...) /2: lwp_park(0x00000000, 1) (sleeping...) /3: lwp_park(0x00000000, 0) (sleeping...) /4: lwp_park(0x00000000, 1) (sleeping...) /5: lwp_park(0x00000000, 0) (sleeping...) /6: lwp_park(0x00000000, 1) (sleeping...) /1: Received signal #5, SIGTRAP, in ioctl() [caught] This is Solaris 9/SPARC... any suggestions on how I might be able to troubleshoot the problem further? Bill

5 7

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 January 2006