Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Re: Debian packages
by Marc Dirix 06 Jun '10

06 Jun '10

> I'm not sure that packages are allowed to build-depend on themselves, > but I suspect that the same bootstrapping problem may exist with other > packages as well? In the emdebian channel it is stated that although error recovery can be a pain, other packages (ghc6) just fail while cross-building on the host.

1 0

Re: Debian packages
by Marc Dirix 06 Jun '10

06 Jun '10

On 06-06-10 19:25, Magnus Holmgren, Millnet/Lysator/Debian/Mensa @ Pike developers forum wrote: >> On 06-06-10 18:15, Magnus Holmgren, Millnet/Lysator/Debian/Mensa @ Pike >> developers forum wrote: >>> If the diff is manageable I prefer to patch configure and avoid >>> depending on and running autoconf. I suppose that's the only reason >>> for the last hunk of rules.diff. >> >> I don't exactly understand what you mean here? >> If configure.in in pike is patched, then for every new stable release >> configure will also be correct thereafter? > > It's just that it tends to produce huge diffs when building a package > twice in a row unless all the files created by autoconf are restored > or deleted by debian/rules clean. If configure.in is patched in pike before autoconf is used to export the stable pike, autoconf doesn't have be run anymore from debian/rules and can be left out. Even for emdebian. The patch to debian/rules is for the current package 7.8.352. But I think it is far less complex to try and make it right in the next stable release of pike. (So then the added line "$(MAKE) force_autoconfig CONFIGUREARGS="$(CFARGS)" can be left out.) > > I'm not sure that packages are allowed to build-depend on themselves, > but I suspect that the same bootstrapping problem may exist with other > packages as well? Since it is only a problem when cross-compiling I don't think it is right to make the package depend on itself for building. I'd opt for the build process failing and leaving it up to the cross-compiler to see that pike is missing on the host. But to be sure I'll ask in the emdebian community.

1 0

Re: Debian packages
by Marc Dirix 06 Jun '10

06 Jun '10

On 06-06-10 18:15, Magnus Holmgren, Millnet/Lysator/Debian/Mensa @ Pike developers forum wrote: >> 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. > > If the diff is manageable I prefer to patch configure and avoid > depending on and running autoconf. I suppose that's the only reason > for the last hunk of rules.diff. I don't exactly understand what you mean here? If configure.in in pike is patched, then for every new stable release configure will also be correct thereafter? > > How do you ensure that pike is installed on the host system before > cross-compiling for other architectures? > One could declare a build-dependecy in the control file. Otherwise the building process just fails, stating pike is not found. >> 4) Patch to src/modules/Mysql/configure >> I think this patch was already included in src/modules/Mysql/configure.in. > > That one looks reversed. It is, sorry about that! Attached is the correct diff.

2 1

--with-machine-code
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 06 Jun '10

06 Jun '10

The Debian package makefile (debian/rules) currently contains the following lines since time immemorial: DO_MACHINE_CODE=no ifeq ($(DEB_BUILD_ARCH),i386) DO_MACHINE_CODE=yes endif ifeq ($(DEB_BUILD_ARCH),powerpc) DO_MACHINE_CODE=yes endif ifeq ($(DEB_BUILD_ARCH),sparc) DO_MACHINE_CODE=no endif ifeq ($(DO_MACHINE_CODE),yes) MACHINE_OPTS=--with-machine-code else MACHINE_OPTS=--without-machine-code endif As you can see, --with-machine-code is only enabled on i386 (x86) and powerpc, for some reason. Marek Habersack had the following to say in the changelog for 7.5.17: * Disabled using the machine code in the pike bytecode. It poses a security risk and breaks under kernels with exec-shield or PAX. Apart from that, no explanations. Is the above reason, or any other, still valid?

3 2

Debian packages
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 05 Jun '10

05 Jun '10

I've been meaning to upload a pike7.8 package to unstable for some time, but first I want to fix the set of binary packages, among them the metapackages. There are currently two - pike7.8, which depends on a smaller set of modules, and pike7.8-full, which pulls in all the module packages there are. The actual pike binary and core modules are in pike7.8-core. I think one metapackage should be enough, and some people have complained about Debian that when they apt-get install foo, they don't get foo (what they would get by downloading the source and running ./configure && make && sudo make install) but a "recommended subset" or just the main binary, but not the documentation, development files, or optional modules. The main reason that many of the Pike modules are put in separate packages is that they together add a large number of dependencies. Contrast with Perl and Python, where such things as GTK2+ bindings are separate projects. 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.

1 0

Re: Crypto.CRC
by Marc Dirix 05 Jun '10

05 Jun '10

If I understand the convention right, it should now comply.

1 0

Compiling mappings
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 01 Jun '10

01 Jun '10

Something is horribly unoptimized when compiling mappings. I did some data processing and wrote out the resulting mapping with sprintf %O into a text file, resulting in some 40,000 entries. I then created a file like this mapping m= #include "stat.txt" ; void main() { } and started it. Since it took a long while to execute I wrote this while waiting void main() { mapping m = ([]); foreach(Stdio.File("stat.txt")->line_iterator();;string line) { int a,b; if( sscanf(line, "%*s%d: %d", a,b)==3 ) m[a] += b; } } which ended up taking real 0m0.222s user 0m0.208s sys 0m0.008s I have now stopped the first program, which didn't yet terminate. It looked like this just before I stopped it. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7962 nilsson 20 0 1264m 1.2g 792 R 100 61.8 974:54.12 pike

6 11

cmod example
by Marc Dirix 31 May '10

31 May '10

Is there any good example cmod module which I could take as a starting point for creating a new one? Preferably with linking to some externaly shared library. I've tried using the "hello.tgz" module which is on the website but it won't compile using the latest pike 7.8.435: In file included from hello.cmod:8: /usr/local/pike/7.8.435/include/pike/module_magic.h:25:2: error: #error module_magic.h is deprecated. Please read the header file for details. hello.cmod:25: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘struct’ hello.cmod:30: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ptrdiff_t’ hello.cmod:31: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ hello.cmod:45: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ptrdiff_t’ hello.cmod:46: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘void’ hello.cmod:58: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token hello.cmod:26: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token WARNING: Compiler failure! Trying without optimization! In file included from hello.cmod:8: /Marc

4 6

JSON
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 29 May '10

29 May '10

Can we please have a testsuite in the JSON module? The fact that there isn't one is breaking the xenofarm builds...

4 6

Floating point formatting
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 27 May '10

27 May '10

I plan to fix this, since I consider it a gross bug: > Gettext.setlocale (Gettext.LC_NUMERIC, "sv_SE.UTF-8"); (1) Result: 1 > (string) 3.14; (2) Result: "3,14" > sprintf ("%O", 3.14); (3) Result: "3,14" I.e. casting and %O are locale sensitive and doesn't always produce a decimal point. Would it conceivably be a compatibility problem to just fix this right away in 7.8? It would not affect %f, %g and all the other floating point formatters.

2 1

Jump to page:

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