Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

Stdio.port listen() backlog again...
by Alexander Demenshin 22 Jan '03

22 Jan '03

Hi everyone, I posted this once on Pike list, and got no reply, so I am trying here, perhaps devel list is better place... > I found that it is impossible to specify backlog parameter when > using Stdio.Port - it is hardcoded to 16384. > > Actually, the questions are - what should I do to actually limit > backlog value? And - why it is hardcoded? Problem with current implementation: it is relatively easy to make a DoS attack against everything that listening through Stdio.Port (most used apps: Roxen & Caudium). Any comments? :) Regards, /Al

9 19

Parent reference semantics.
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 22 Jan '03

22 Jan '03

Poll: Given the following files: A.pmod: void foo() { werror("A\n"); } class B { void bar() { foo(); } } C.pike: inherit .A.B; void baz() { foo(); } void foo() { werror("C\n"); } Should the following program: int main() { object c = .C(); c->bar(); c->baz(); } Output A C or C C ? ie Should parent references be overloadable via inherit?

6 8

Parent reference semantics.
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 22 Jan '03

22 Jan '03

In order to overload bar(), you need to inherit A.

1 0

Whee!
by David Hedbor ＠ Pike developers forum 17 Jan '03

17 Jan '03

First successful icc build of Pike 7.5 just finished. :)

2 3

-O3
by David Hedbor ＠ Pike developers forum 16 Jan '03

16 Jan '03

Is there a reason while '-O2' is the "max" -Ox flag and not -O3? I.e have there been any specific problems or are there other reasons?

4 6

Re: signed integer division
by Johan Sundstr�m (a hugging punishment!) ＠ Pike (-) developers forum 16 Jan '03

16 Jan '03

Excellent documentation material for `/ and `%, Niels; thanks. I'm taking the liberty of incorporating parts of that discussion to the refdocs. / Johan Sundström (a hugging punishment!) Previous text: >2003-01-15 11:41: >Subject: Re: signed integer division >-------------------------------------------------------------------- >Rene van Rueschen <rueschi(a)berit-broese.de> writes: > >> There is a big difference between C/Pascal/LPC and Pike in signed integer division: >> In Pike, results are rounded down, while in all other languages the results are >> rounded towards 0. > >This behaviour was argued about and decided several years ago. As I >was one of those who argued strongly for the current behaviour, I >should perhaps explain why I prefer that: > > 1. It means that a % b always have the same sign as b (typically b > is positive (array size, rsa modulo, etc), and a varies a lot > more than b. > > 2. That means that the function f(x) = x % n behaves in a sane way, > as x increases, f(x) cycles through the values 0,1, ..., n-1, 0, > .... Nothing strange happens when you cross zero. > > 3. Furthermore, the function f(x) = x/n behaves in a sane way. When > you increase x, f(x) will jump one step for each n:th increment. > For all x, (x + n) / n = x/n + 1. Zero is not special. > > 4. The % operator implements the binary "mod" operation, as defined > by our god Donald Knuth (see the Art of Computer Programming, > 1.2.4) [1]. > >> (Results of the modulo operation are 'correct' referring to this >> unusual rounding style.) > >It's important that / and % are compatible, so that a = b*(a/b) + a%b >for alla and b. > >Also note the recent 15-20 years of history of the % operations. >Traditionally in C (i.e. at least up c89 ANSI C), the rounding >behaviour of % for negative numbers was left as implementation >defined. If there was a machine code instruction for division, C >typically did whatever the machine code did. > >It's unfortunate to have a basic operation like % not well defined. >When the Pike developers were annoyed about it, the question was >argued and in the end Pike chose the, in my opinion, sanest convention >for how it ought to work. Then java came a long, and choose the >round-towards-zero convention, which in my opinion is brain damaged. >I'm not sure what c99 says, perhaps it specifies the same behaviour as >java. > >Anyway, as you compare to C, you should be aware that a portable >programs can't make any assumptions about the rounding conventions of >%, it's all up to the compiler implementation (at least if you don't >require a c99 compiler). So any C program that depends on that % >behaviour is *broken*. I guess the same is true for LPC, at least >older versions of Pike and ulpc used to inherit the %-behaviour from >the C compiler that was used for compiling it, which in turn inherited >it from the corresponding machine code instruction. > >> This strange behavour makes it extremly difficult to port algorithms >> written in other languages to Pike. > >Can you give some examples of the extreme difficulties? > >/Niels > >[1] Ok, Knuth's definition also says that x mod 0 = 0 for all x. > That's not true for Pike's %; it treats %-by-0 as an error. But > that's really a border case. > > > > / Brevbäraren >

6 8

Intel C++ / gcc 2.95.4 comparisions
by David Hedbor ＠ Pike developers forum 15 Jan '03

15 Jan '03

Thought these results are interesting. Note that compilation with gcc-3.2 probably would generate better code, especially with arch-dependent data. The binary is compiled with arch-specific code for multiple platforms (i.e -march but for multiple platforms at once - rather nice). I'm also using multi-file Interprocedural optimizations (takes quite a long time to link Pike). arch is Athlon - Pentium probably would get even better results. gcc version 2.95.4 20011002 (Debian prerelease): test total user mem (runs) Pike start overhead........ 0.228s 0.001s 3352kb (22) Ackermann.................. 1.669s 1.453s 3532kb (3) Array & String Juggling.... 1.026s 0.808s 3660kb (5) Clone null-object.......... 0.488s 0.273s 3340kb (11) (12100000/s) Clone object............... 0.909s 0.692s 3340kb (6) (2602410/s) Compile.................... 1.975s 1.760s 3504kb (3) (41148 lines/s) Compile & Exec............. 1.790s 1.577s 3520kb (3) (1144313 lines/s) GC......................... 1.269s 0.925s 3468kb (4) Matrix multiplication...... 0.862s 0.643s 5144kb (6) Loops Nested (local)....... 0.578s 0.362s 3324kb (9) (416857184 iters/s) Loops Nested (global)...... 0.899s 0.642s 3324kb (6) (156877872 iters/s) Loops Recursed............. 1.442s 1.225s 3324kb (4) (3423922 iters/s) Intel(R) C++ Compiler for 32-bit applications, Version 7.0 Build 20021021Z: Pike start overhead........ 0.191s 0.000s 3760kb (25) Ackermann.................. 1.068s 0.864s 3956kb (5) Array & String Juggling.... 1.007s 0.804s 3968kb (5) Clone null-object.......... 0.426s 0.237s 3728kb (12) (15157895/s) Clone object............... 0.816s 0.626s 3728kb (7) (3356164/s) Compile.................... 1.594s 1.405s 3916kb (4) (68726 lines/s) Compile & Exec............. 1.667s 1.397s 3884kb (3) (1291790 lines/s) GC......................... 1.068s 0.880s 3876kb (5) Matrix multiplication...... 0.746s 0.556s 5680kb (7) Loops Nested (local)....... 0.727s 0.534s 3760kb (7) (219808464 iters/s) Loops Nested (global)...... 1.083s 0.894s 3760kb (5) (93832312 iters/s) Loops Recursed............. 0.784s 0.594s 3760kb (7) (12351014 iters/s) Note the slowdowns in the two nested loop tests though.

2 2

GTK and new libpng
by Martin Nilsson (�skblod) ＠ Pike (-) developers forum 15 Jan '03

15 Jan '03

It appears that the new libpng that up2date installed on mahoro don't work too well with the GTK linking. Has anyone got a fix for this?

1 0

Pike with icc (Intel C++, Linux)
by David Hedbor ＠ Pike developers forum 15 Jan '03

15 Jan '03

Aha, figured out the dynamic linking issue - don't link with -lc. I'm going to check in fixes to 7.5 once my test compile finishes. / David Hedbor Previous text: >2003-01-16 00:15: >Subject: Pike with icc (Intel C++, Linux) >-------------------------------------------------------------------- >Ok, a first compilation with icc is now finished. It doesn't work :-) > >Fails with: >/home/neotron/src/xenofarm/client/pike-7.4/stellar.home.hedbor.org/buildtmp/Pike7.4-20030115-205830/src/object.c:577: Fatal error: >Couldn't load master object. >No stack - no backtrace. > >I had do compile --without-dynamic-modules because currently I don't >have that working (not Pike specific). Ah well. :) > > / David Hedbor >

1 0

xenofarm build failure
by David Hedbor ＠ Pike developers forum 15 Jan '03

15 Jan '03

Hmm. I'm getting xenofarm build failures on my x86 box: /home/neotron/src/xenofarm/client/pike-7.4/stellar.home.hedbor.org/buildtmp/Pike7.4-20030115-190328/src/interpret.c:1296: undefined reference to `QUICK_FIND_LFUN' interpret.o(.text+0x866b):/home/neotron/src/xenofarm/client/pike-7.4/stella…: undefined reference to `QUICK_FIND_LFUN' collect2: ld returned 1 exit status make[5]: *** [tpike-real] Error 1 What's up with that? Both pike 7.4 and 7.5 I should add. It seems like the blame goes to this: revision 1.284 date: 2003/01/15 19:03:26; author: mast; state: Exp; lines: +12 -10 Before invoking the trampoline magic, check properly that it's the `() lfun in the trampoline object that is to be called.

4 8

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