Pike-devel May 2018

pike-devel@lists.lysator.liu.se

7 participants
20 discussions

Pike Meet-up 2018-Q1
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 20 Oct '21

20 Oct '21

Hi. At Pike Conference 2017 it was decided that we ought to hold a more informal meeting in Linköping ~ once every quarter. As the three month mark from the conference is coming up soon, it seems time to announce the first such meeting for 2018: Pike Meet-up 2018-Q1 Date: 2018-02-03 (Sat) Time: 10:00 - afternoon/evening Place: Roxen IS AB S:t Larsgatan 22A Linköping Welcome! /grubba

2 13

Operator assignment and strict_types
by Marc Simpson 07 Jul '20

07 Jul '20

Hi folks, It looks like operator assignment (op=), increment and decrement statements aren't subjected to the same typechecks as their more explicit equivalents. For example, neither the post-increment nor += statements below warn with strict_types enabled, even though they assign values outside of foo's restricted int domain: int(3..3) foo = 3; foo++; // no warning foo += 1; // no warning foo = foo + 1; // warning from strict_types Similarly, operator assignment on aggregates fails to elicit a warning: array(int) a = ({}); multiset(int) b = (<>); mapping(int:int) c = ([]); // no warnings a += ({ "hey" }); b += (< "hey" >); c += ([ "hey": "there" ]); // warnings from strict_types a = a + ({ "hey" }); b = b + (< "hey" >); c = c + ([ "hey": "there" ]); I'm guessing this is because the checks provided by the F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment; op= and friends are presumably not instrumented for strict_types in the same manner. Have there been any discussions around addressing this inconsistency? Thanks, Marc

3 3

Recent change in Gmp.mpq
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 30 May '18

30 May '18

Before: > sprintf("%3.3f", Gmp.mpq(1,3)); (1) Result: "0.333" > sprintf("%3.3f", Gmp.mpq(2,3)); (2) Result: ".666" > Ok, I can see that seems a bit wrong. After: > sprintf("%3.3f", Gmp.mpq(1,3)); (1) Result: "0.333" > sprintf("%3.3f", Gmp.mpq(2,3)); (2) Result: "066\0\0" > Uh, but that's not right either, is it? Could we please make it a habit to test our code at least once before pushing it? K thx bye...

2 1

Re: calling methods
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 29 May '18

29 May '18

invoke_signal_func calls Pike code (via apply_svalue). To run Pike code, you need to hold the interpreter lock. But that is not all. You also need to have a Pike stack and a frame pointer, which are thread local. These are kept in a structure called a "Pike_interpreter_struct", which in turn is part of something called a "thread_state". All threads created with thread_create() already has such a state, stored in a lookup table indexed on the thread id. However, a thread created by (say) C-code in an external library will not have such a state created for it. call_with_interpreter is simply a convenience function used to be able to call Pike code from an unknown context: * If the running thread already has an entry in the lookup table, then it just takes the interpreter lock, if it wasn't already taken, and calls the function. Then it unlocks the interpreter lock again if it was unlocked before. * If the running thread does _not_ have an entry in the lookup table, then a new thread_state is created, and made the current interpreter (after taking the lock). The thread_state is also stored in the lookup table, in case the pike code calls the C library back, which then again makes a call into Pike and we reenter call_with_interpreter within the same context. After the Pike code has been executed, the thread_state is removed from the table and discarded.

2 1

Re: calling methods
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 29 May '18

29 May '18

> Could I trouble you for some insight into your GI branch code? > I was looking at > >static void signal_func_wrapper(struct signal_data *d, gpointer go, guint n_params, > const GValue *param_values, GValue *return_value) { > struct signal_wrapper_context ctx = { > d, n_params, param_values, return_value > }; > call_with_interpreter(invoke_signal_func, &ctx); >} > > > Why call_with_interpreter instead of just invoke_signal_func(ctx)? > I see it has something to do with having the interpreter lock, but > what does this give you over a direct function call? call_with_interpreter() ensures that there is a valid Pike context for the current thread. This is used to handle the case that the signal might have been triggered from some strange non-pike thread. /grubba

1 0

pike -x module
by Lance Dillon 28 May '18

28 May '18

There may be an error in this? Not sure, but in my code, I'm getting an error. I removed @ from the beginning the shell code in Makefile so that I can see the output: if test "xgi.o" != "x" ; then \ /usr/local/pike/8.0.610/include/pike/install_module module.so /usr/local/pike/8.0.610/lib/modules/___GI.so && \ fi; \ if test "x./module.pmod.in" != "x"; then \ /usr/local/pike/8.0.610/include/pike/install_module module.pmod /usr/local/pike/8.0.610/lib/modules/GI.pmod ;\ fi; /bin/sh: -c: line 2: syntax error near unexpected token `fi' /bin/sh: -c: line 2: `fi; \' make: *** [Makefile:449: install] Error 1 The error is the && at the end of ___GI.so above, it should be replaced with ; (semicolon). Although looking at PIke-8.0.610/src/modules/dynamic_module_makefile.in, I see this: # # install a standard module with optional c component in the system module path # install: $(MODULE_INSTALL) @if test "x$(OBJS)" != "x" ; then \ $(TMP_BINDIR)/install_module module.so $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODULE_WRAPPER_PREFIX)$(MODNAME).so && \ if [ -f $(MODNAME).pdb ]; then \ cp $(MODNAME).pdb $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODULE_WRAPPER_PREFIX); \ else :; fi; \ fi; \ if test "x$(MODULE_PMOD_IN)" != "x"; then \ $(TMP_BINDIR)/install_module module.pmod $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODNAME).pmod ;\ fi; Which is different from my generated Makefile: # # install a standard module with optional c component in the system module path # install: $(MODULE_INSTALL) @if test "x$(OBJS)" != "x" ; then \ $(TMP_BINDIR)/install_module module.so $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODULE_WRAPPER_PREFIX)$(MODNAME).so && \ fi; \ if test "x$(MODULE_PMOD_IN)" != "x"; then \ $(TMP_BINDIR)/install_module module.pmod $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODNAME).pmod ;\ fi; So mine might be getting dynamic_module_makefile.in from somewhere else... Hmm, so removed /usr/local/pike/8.0.610/include/pike/modules/dynamic_module_makefile, and did a reinstall (sudo make install) of pike from Pike-8.0.610, and the proper code (2 stanzas above) got output to the incorrect code (just above) in my file, which is causing problems doing pike -x module install. So it looks like the part: if [ -f $(MODNAME).pdb ]; then \ cp $(MODNAME).pdb $(SYSTEM_MODULE_PATH)/$(MODDIR)$(MODULE_WRAPPER_PREFIX); \ else :; fi; \ is being removed for some reason, which is causing a problem with && being improper syntax for the resulting shell code. Weird...

2 2

calling methods
by Lance Dillon 27 May '18

27 May '18

So I'm working on a GTK3 module (finally). This will be a little different and use gobject introspection to call methods by name, dynamically, so I won't have to write code to interface with every single function. The module will use gobject introspection to look up the method by the object and the name, and if it exists, call it with the arguments. Anyway, I was thinking of using GTK2 module.pmod as an interface to the [] method, although that might not be the proper way to do this. So, basically I'll be creating a sort of blank program with only a couple methods, with a lot of behind the scenes infrastructure type code, and want to write so that when you call GTK3.Window("title"), it will call GTK3.method_missing (say), which will call my infrastructure code that will look up the class and method, create the program (if it doesn't exist already), add the method (if it doesn't exist already, if this is possible), and then call it with the arguments. Of course, if all that exists already, it would call it directly. Which brings up a question: is it possible to add a method to a class that has already started and ended (using start_new_program() and end_program()). And how could I write the frontend pike code to intercept GTK3.Window and have it call GTK3.method_missing. I was looking at the GTK2 module's module.pmod as a base, but not sure if that is the right way to do it... Thanks...

5 8

Re: signal()
by Tomasz Jamroszczak 25 May '18

25 May '18

OK, that's clear.

1 0

Re: signal()
by Tomasz Jamroszczak 25 May '18

25 May '18

2018-05-25 11:06 GMT+02:00 Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se>: > The latter. Basically, there is no legitimate reason for pike code to > trap these signals since there should be nothing pike code can do that > cause these signals to be fired. > Right. But when I include some library which corrupts memory into Pike build or make changes to Pike sourcecode itself, then it is possible to crash Pike and then trapping SIGSEGV can bring in additional information about probable place where the memory corruption occurred. Is my understanding correct?

3 2

signal()
by Tomasz Jamroszczak 25 May '18

25 May '18

Documentation of signal https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/signal.… says: "Although it IS possible to trap SIGBUS, SIGSEGV etc, I advise you not to; Pike should not receive any such signals, and if it does, it is because of bugs in the Pike interpreter" Should I read it as "Pike doesn't support trapping SIGSEGV"? Or as "We, Pike interpreter developers, try hard not to crash the interpreter but it can happen; in such case please file a bug"?

2 1

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 May 2018