Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Re: AutoDoc
by Per Hedbor () ＠ Pike (-) developers forum 30 Jul '10

30 Jul '10

As an example: On my Solaris server at home I have installed the sun C-compiler. However, the pike binary package I installed was built using gcc. It's not possible to build modules with pike -x module with 'complex' (or old) style modules. To get it to work you really do need your own configure tests instead of relying on the results of the ones done by pike at compile time. The 'simple' (or new style) modules gives you everything you need to do that, that is, the location of pike includefiles etc. The autodoc generation actually does not work at all unless you have the sourcetree installed (same goes for the testsuite, unless I am mistaken). So that's not really related to new or old style modules, unfortunately.

1 0

Re: AutoDoc
by Per Hedbor () ＠ Pike (-) developers forum 30 Jul '10

30 Jul '10

The 'old' (or complicated) method only really works correctly when you build your pike on your own, or when it's built on an identical system to the one you have, though.

1 0

GTK2 event
by Mirar ＠ Pike developers forum 30 Jul '10

30 Jul '10

I get this error: Bad argument 1 to `[](). Expected string (8bit). Unknown program: `[](0) /usr/local/pike/7.8.455/lib/modules/___GTK2.so:1: GDK2.Event(configure)->`[](0) lotrolayout.pike:512: /main()->__lambda_65666_2_line_512(GTK2.DrawingArea,GDK2.Event(configure)) /usr/local/pike/7.8.455/lib/modules/___GTK2.so:1: GTK2.Window->show_all() myprogram.pike:526: /main()->main(1,({"/home/mirar/hack/myprogram.pike"})) On this line: da=GTK2.DrawingArea(); da->signal_connect("configure-event", lambda(object da,array req) { ... }); Any idea why? It seems like a Pike bug to me, but maybe I'm doing something wrong?

1 0

Re: AutoDoc
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 30 Jul '10

30 Jul '10

>I am curious to know, though, what makes you think >dynamic_module_makefile has been deprecated? It's used by all of the >core modules, as well as any that third-party modules that are >packaged for distribution (such as at modules.gotpike.org). The section titled "New simplified method to write external C/C++ modules" in CHANGES.

2 2

AutoDoc
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 29 Jul '10

29 Jul '10

I'm having a look at how the extracted documentation is built, because I think there's supposed to be some infrastructure for extracting and installing documentation from third-party modules built with the help of pike -x module, and I doubt that it will work the current packaging. IIUC, "make documentation" first uses extract_autodoc to create one XML file with documentation per source file (placed under the doc_build subdirectory of the build directory), then join_autodoc to create autodoc.xml from these, then assemble_autodoc to create modref.xml, traditional.xml, and onepage.xml with the help of templates. Last, make is run in the refdoc directory. There, tree-split-autodoc.pike and make_html.pike (in refdoc/presentation) produce the HTML and put it in refdoc/modref and refdoc/traditional_manual, respectively. Now, in install.pike there is code to install autodoc.xml (as core_autodoc.xml) as well as images, templates, the aforementioned Pike scripts, and modref/Makefile into $(doc_prefix)/src. It doesn't install the generated HTML though. I wonder if refdoc/Makefile was meant to do that, because it prefixes *most* destination directories with $(DESTDIR), but DESTDIR is never set. Or wait, common_module_makefile.in actually sets DESTDIR to $(SYSTEM_DOC_PATH), i.e. doc_prefix. So if I guess correctly, pike -x module --make modref in a module source directory is meant to extract the documentation from the module, join it with the core module documentation and place the resulting HTML in the correct place. I'm not sure if that module's documentation will be kept if the same is done with another module, however. Have I understood correctly? What is the status of this system, especially considering that dynamic_module_makefile is deprecated?

1 0

Re: Debian packages
by Marc Dirix 29 Jul '10

29 Jul '10

> My plan for simplifying things while catering to various wishes is to > * remove pike7.8-full > * let pike7.8 Recommend all other packages. That way everything will > be installed if you run apt-get install pike7.8 unless you have > switched off automatic installation of recommended packages, but > it's still possible to opt out of individual packages. I have made a small set of patches which I'd like to be included in pike and debian packages in order to make the package emdebian (cross) compilable. I've attached the patches, but as described below there are still some caveats to them. Patches according to http://wiki.debian.org/EmdebianMakefile Patches are made against the current debian package (pike 7.8.352). 1) Patch to debian/rules. This patch can be included as is. The patch makes it possible to use a cross compiler for compiling pike. (cross compiling in debian you can do using "pkg-build -a arm -uc -us) 2) Patch to src/configure.in This patch can be included as is into pike, I think this was is a bug in configure.in because it originally tries to use the newly build pike instead of the pike installed on the host. 3) Patch to src/configure I think this patch should ultimately be done in src/configure.in. But I'm no M4 expert and haven't yet found which changes need to be made in src/configure.in 4) Patch to src/modules/Mysql/configure I think this patch was already included in src/modules/Mysql/configure.in. Then there is the issue of bytecompiling. As I understand it pike can do without byte-compiling. However the debian packaging copies the byte-compiled files into the several packages. If byte-compiling fails (because the newly build pike can't be used for byte-compiling) the package manager fails to create a package. I've only come up with one possible sollution to this. Which is, push the byte-compiling of the code into a post-install script. This way the byte-compiling can be done on the target machine. But maybe there is a better sollution? It is not allowed to have diff between the debian and the emdebian packaging files. Best regards, Marc

6 31

(no subject)
by Tor Edvardsson ＠ Pike developers forum 29 Jul '10

29 Jul '10

1 0

get_all_args and UNDEFINED
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 28 Jul '10

28 Jul '10

Yesterday I stumbled on a segfault: > allocate (17, UNDEFINED); Segmentation fault (core dumped) It's fixed now, but the problem is bigger than this particular case. The thing is that get_all_args doesn't always set the optional arguments - that happens both when the real arguments run out and when UNDEFINED is sent as a real argument. There's a lot of code that uses get_all_args and still looks at the arg counter to see whether an argument has been given. E.g. allocate() was like this: PMOD_EXPORT void f_allocate(INT32 args) { INT_TYPE size; struct array *a; struct svalue *init; get_all_args("allocate", args, "%+.%*", &size, &init); /.../ if(args>1) { /.../ copy_svalues_recursively_no_free(a->item+e, init, 1, 0); /.../ Even though there's more than one arg on the stack, it's not certain that init has a defined value there. I went through the pike source and fixed this at a number of places, so it seems to be a common misconception. So the bottom line is, please remember to _always_ initialize the variables for optional arguments when you use get_all_args.

1 0

`+ optimizations
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 23 Jul '10

23 Jul '10

The following program ---8<--- class foo { string `+(mixed ... args) { return "left:"+sizeof(args); } string ``+(mixed ... args) { return "right:"+sizeof(args); } } int main() { foo x = foo(); write("%s\n%s\n%s\n", x+x+x+x+x, (((x+x)+x)+x)+x, x+(x+(x+(x+x)))); return 0; } ---8<--- gives the output left:4 left:4 left:1 (tested in Pike 7.8.350). Shouldn't the last line be "right:4"? We seem to be missing an opportunity for optimization here.

2 6

Ideas for better performance
by Jonas Walld�n ＠ Pike developers forum 21 Jul '10

21 Jul '10

I'd like to start a discussion on performance issues where I feel we can do a lot better with reasonable effort. My test case was initially the XSLT module in our CMS but with tools such as Shark (an OS X sampling profiler) I've encountered some interesting results that I've now reproduced in isolation. A fundamental observation is of course that CPUs and memory subsystems have different performance properties today compared to when core parts of Pike were written. One particular detail is the frequent use of modulo (or rather int division) in hash tables which on x86_64 (if I recall correctly) has a latency in the 100+ cycle range. Examples of where this is used is mappings, identifier lookup, gc passes etc. A very naive replacement of %= in find_shared_string_identifier() (which typically scores high in an object-oriented test case like XSLT) improved benchmark runtime ~3-7% on my Core Duo laptop. My replacement was a very simple pointer shift/XOR mod 2^n. Next, enabling some additional Shark probes on misaligned memory writes together with the int div probe gave very weird results for code that I thought would be trivial. It turns out that this: void fn() { array arg = ({ 1, 2, 3 }); } ...copies arg recursively using a temporary mapping. Ouch! Consider a real-world example like the following: string quote_text(string txt, void|array from, void|array to) { from = from || ({ "<", ">", "&" }); to = to || ({ "<", ">", "&" }); return replace(txt, from, to); } ...which semantically uses the inlined arrays as constants if the caller doesn't pass from/to. In my mind this would just be a refcount bump but Grubba pointed out that arrays are not copy-on-write so that isn't currently possible. A similar test with mappings still passes copy_svalues_recursively_no_free so apparently the c-o-w property isn't taken advantage of there either. Adding c-o-w to arrays and using it in these situations would be really nice. I also found examples like the zeroing in real_allocate_array() where gcc (v4.2.1 in my case) generated quite lousy code. A rewrite to a pointer-based loop with item-chunked initialization was faster. Don't know if the compiler has to play safe with the repeated dereferencing of fields with unknown aliasing effects inside unions but I'll gladly help rewrite such code if people agree it's beneficial. Finally, anyone try compiling with Clang/llvm-gcc yet? I tested with llvm-gcc last year and aside from miscompilation in one place it was a tad slower overall compared to gcc. Maybe recent versions are better? Can we make a plan for action on these items or do we need the elusive 7.9 branch open first?

13 58

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