Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Xor
by Peta, jo det �r jag ＠ Pike developers forum 06 Feb '03

06 Feb '03

({1,2,3,4,1,2}) ^ ({1,2}) gives ({3,4,1,2}) I was expecting ({3,4}), I guess there is a good reason behind it but I can't figure it out :)

9 48

synchronized
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 06 Feb '03

06 Feb '03

I've never understood benefit of hiding mutexes like that Java construct does. It even does so in three different ways depending on how it's used. Is the code somehow made more clear because the mutexes disappear? I prefer to see them, so I can tell easily which regions are synchronized with each other. That also makes it easier to search on the mutex variable to find those regions. There's one benefit with a block construct like that: It makes the region where the lock is held more clear. (The pike way of relying on refcount garbing of the lock has lead to many bugs, e.g. with the tail recursion optimization. I don't rely on refcounting for locks anymore; I always zero them explicitly afterwards.) So in my view a good synchronized construct would always require a mutex argument. E.g: Thread.Mutex my_mutex = Thread.Mutex(); synchronized(my_mutex) void my_first_function() {...} void my_second_function() { ... synchronized(my_mutex) { ... } } The second case above is solvable with implicit lambda, but I'd rather avoid implementing it that way since it "destroys" the syntax so it can't be upgraded to a better implementation later on (see the blurb about implicit lambdas in the CHANGES file). As a transitionary measure, we could perhaps have something like this instead that works through implicit lambdas: my_mutex->synchronize() { ... }; / Martin Stjernholm, Roxen IS Previous text: >2003-02-04 19:14: >Subject: synchronized >-------------------------------------------------------------------- >One thing that's nice in Java is the 'synchronized keyword. It would >be nice to have that functionality in Pike since it's easier than >manually using mutex locks (nicer code): > > >synchronized void do_something() { ... } > >and > >mapping foo; >void do_something() { > synchronized(foo) { > work on foo > } >} > >and > >void do_something() { > ... > synchronized { > locked region > } > ... >} > >would be nice. The first one creates an implicit mutex lock for the >entire method, the second one creates a lock bound to a specific >variable (i.e you can have multiple methods "locking" the same >variable) and the third method works just like the first, except for a >specific region rather than the entire method. > >Another possibility is to have synchronized classes: > >synchronized class { > ... >} > >and variable instanses: > >synchronized mapping foo = ([]); > >But the first three versions are IMHO more interesting. > >How hard would this be to implement in pike? I'm guessing "quite >hard", but... :) > > / David Hedbor >

5 26

index() in a testsuite
by Peta, jo det �r jag ＠ Pike developers forum 06 Feb '03

06 Feb '03

Does anyone know why it seems impossible to use the word index() in a testsuite.in file. It will just remove the entire word and generate a warning /export/spare/pike/home/peta/Pike/7.5/src/post_modules/Test/testsuite.in:258: /pike/sw/bin/gm4: Warning: Too few arguments to built-in `index' And is there any way to avoid it?

3 2

INT_TYPE = INT64
by Mirar ＠ Pike developers forum 06 Feb '03

06 Feb '03

Hm, I filled in too few '*'. Note that Ackermann gets faster with 12-byte svalues (can anyone explain that?).

3 4

The Gmp, Math modules and the files module in pike 7.5
by Marek Habersack 05 Feb '03

05 Feb '03

Hey all, The Gmp/ and _math/ directories in src/modules/ both contain .cmod files which requires that the system where pike is compiled (even from exported sources) will require an existing pike before even tpike is linked. I thought that moving them to post_modules/ would be a temporary solution, but then files/stat.o linking fails since it cannot find f_max/f_min which are defined in the _math/math.c file. The other solution is to precompile those files when exporting the sources, but alas - I have no idea how to do that :) thanks, marek

3 8

Any way to access the calling object?
by Alexander Demenshin 05 Feb '03

05 Feb '03

Hi everyone, Is there any way to find out which object [instance] is calling some function? I expected that this_object() will do the work, but regardless of the caller it always returns module where it is written. Actually, what I need is to get exact reference to the instance of the object which calls my function (if there is an instance). backtrace() won't work - I'll get the function name and location in the file, but no reference to calling object... Or, to summarize: --- snip otest.pike --- class A { void method() { some_func(); } } some_func() { write(sprintf("Called from: %O", caller())); } int main() { A a = A(); some_func(); // Should print "Called from: otest()" a->some_func(); // Should print "Called from: A()" and (caller() == a) will be true } --- snip otest.pike --- Regards, /Al

2 1

synchronized
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 04 Feb '03

04 Feb '03

mixed synchronized(Thread.Mutex|mapping m, function f) { mixed r; if(mappingp(m)) m = m->_mutex; object key = m->lock(); r = f(); destruct(key); return r; } mapping foo; void do_something() { synchronized(foo) { work on foo }; } should work already, provided you place a mutex in the mapping under the index "_mutex" (or whatever index you choose to look under in the method "synchronized"). / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2003-02-04 19:14: >Subject: synchronized >-------------------------------------------------------------------- >One thing that's nice in Java is the 'synchronized keyword. It would >be nice to have that functionality in Pike since it's easier than >manually using mutex locks (nicer code): > > >synchronized void do_something() { ... } > >and > >mapping foo; >void do_something() { > synchronized(foo) { > work on foo > } >} > >and > >void do_something() { > ... > synchronized { > locked region > } > ... >} > >would be nice. The first one creates an implicit mutex lock for the >entire method, the second one creates a lock bound to a specific >variable (i.e you can have multiple methods "locking" the same >variable) and the third method works just like the first, except for a >specific region rather than the entire method. > >Another possibility is to have synchronized classes: > >synchronized class { > ... >} > >and variable instanses: > >synchronized mapping foo = ([]); > >But the first three versions are IMHO more interesting. > >How hard would this be to implement in pike? I'm guessing "quite >hard", but... :) > > / David Hedbor >

3 2

synchronized
by Peter Bortas ＠ Pike developers forum 04 Feb '03

04 Feb '03

See also: much of the reason for implicit lambda. / Peter Bortas Previous text: >2003-02-04 19:14: >Subject: synchronized >-------------------------------------------------------------------- >One thing that's nice in Java is the 'synchronized keyword. It would >be nice to have that functionality in Pike since it's easier than >manually using mutex locks (nicer code): > > >synchronized void do_something() { ... } > >and > >mapping foo; >void do_something() { > synchronized(foo) { > work on foo > } >} > >and > >void do_something() { > ... > synchronized { > locked region > } > ... >} > >would be nice. The first one creates an implicit mutex lock for the >entire method, the second one creates a lock bound to a specific >variable (i.e you can have multiple methods "locking" the same >variable) and the third method works just like the first, except for a >specific region rather than the entire method. > >Another possibility is to have synchronized classes: > >synchronized class { > ... >} > >and variable instanses: > >synchronized mapping foo = ([]); > >But the first three versions are IMHO more interesting. > >How hard would this be to implement in pike? I'm guessing "quite >hard", but... :) > > / David Hedbor >

1 0

Pike 7.4 on Debian/Sparc - a build problem
by Marek Habersack 03 Feb '03

03 Feb '03

Hey guys, I've got pike failing to build a deb on a sparc64 machine. It segfaults while trying to run precompile.sh using tpike. Is it really necessary to run precompile.sh on exported sources? If not - how can avoid it? And the most important issues: - the original build failure record: http://buildd.debian.org/fetch.php?&pkg=pike7.4&ver=7.4.13-2&arch=sparc&sta… - a fragment of a failed build when just running 'make' in a debian-patched directory on sparc64 cpu : TI UltraSparc II (BlackBird) fpu : UltraSparc II integrated FPU promlib : Version 3 Revision 27 prom : 3.27.0 type : sun4u ncpus probed : 1 ncpus active : 1 Cpu0Bogo : 591.46 Cpu0ClkTck : 0000000011a4695a MMU Type : Spitfire the fragment: precompile: /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/tpike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/master.pike /scratch/grendel/pike7.4-7.4.13/bin/mktreeopt.pike /scratch/grendel/pike7.4-7.4.13/src/treeopt.in (method=QQ) /scratch/grendel/pike7.4-7.4.13/build/linux-2.4.18-sparc64/precompile.sh: line 203: 15768 Segmentation fault $RUNPIKE $SCRIPT "$@" 1>&5 - a final fragment of strace from the above segfault: 22764 mprotect(0x2693c0, 52, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2693c0, 48, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x296da8, 1144, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 2432, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 2424, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 3376, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 mprotect(0x2adc98, 4912, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 brk(0) = 0x2ba000 22764 brk(0x2bc000) = 0x2bc000 22764 mprotect(0x2b70a8, 10104, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 22764 --- SIGSEGV (Segmentation fault) --- 22764 +++ killed by SIGSEGV +++ - and a compile-time warning (not sure if related): /scratch/grendel/pike7.4-7.4.13/src/program.c: In function store_constant': /scratch/grendel/pike7.4-7.4.13/src/program.c:4508: warning: variable e'might be clobbered by longjmp' or vfork' Right now I'm trying to compile the deb on another sparc machine (will take a while), but I'd appreciate any help on that issue... TIA, marek p.s. if you need access to one of the sparc machines, contact me privately, I think we will be able to arrange something.

3 12

Two questions
by Peta, jo det �r jag ＠ Pike developers forum 03 Feb '03

03 Feb '03

I've run in to some problems and would be grateful for some help. 1. How do you combine pike and C in a module? 2. If I have a program struct, what is the best way to decide what kind of program it is?

5 9

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