Pike-devel June 2010

pike-devel@lists.lysator.liu.se

5 participants
20 discussions

SO_REUSEADDR
by Stephen R. van den Berg 15 Jun '10

15 Jun '10

Browsing the source, I see the Stdio/file module is littered with SO_REUSEADDR setsockopts of which *all* of them are bogus (i.e. they either have no effect, or have an effect which is detrimental to the socket's operation and could cause the socket to receive unexpected errors because the network is still delivering lingering packets to a newly reused socket). It looks like they were scattered into the code by someone who either does not fully understand its semantics, or in a futile attempt to camouflage certain network problems (but were never removed again because it was uncertain if they helped or not (they do not help!)). I've already noticed this while fixing the network-tests from the test-suite. Can anybody either explain what the excessive use of SO_REUSEADDR was supposed to accomplish? Grubba? (it seems like you added or at least touched some of them), or does anybody object to me cleaning up this mess? The reason why I actually touch the subject is because I currently happen to have one of the two only valid reasons to actually use SO_REUSEADDR (I want to bind two Roxens to the same port on the same IP-address for load balancing), and it turns out that I cannot activate the option from Pike (ironically, the code is littered with these SO_REUSEADDR options, except for the one spot where it actually matters). It should/will become a separate setsockopt kind of interface at the Pike level. -- Stephen. "Tomorrow will be cancelled due to lack of interest."

1 0

Crypto.CRC
by Marc Dirix 13 Jun '10

13 Jun '10

Hi, I've found the python CrcMoose library. The CRC algorithm I seemed to need CRC16X was different from CCITT and CRC16IBM or modbus. I've converted the CrcMoose library to pike and attached it to this email. The original module (python) can be found here: http://www.nightmare.com/~ryb/ I'd like to opt to get this module into Crypto if possible. I'm not sure how this works with his license in the original file. /Marc

8 15

pad/unpad
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 06 Jun '10

06 Jun '10

It appears that we have a bug in the pad/unpad methods of the Crypto.Buffer object. Where all padding standards (ANSI X.923, ISO 10126, PKCS7) have the last byte of the last block be the number of padded bytes, Pike sets it to 1 less than that (i.e. the number of padded bytes in addition to the length byte). I think these functions are used directly in SSL. However fixing it may create a bit of a compatibility issue in other places.

1 0

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

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 June 2010