Pike-devel

pike-devel@lists.lysator.liu.se

3 participants
3048 discussions

Re: [caudium-general] Pike & Caudium conference
by Bertrand LUPART 12 Aug '03

12 Aug '03

> One more thing, the conference will not take place at the university > campus but in heinz nixdorf institute as shown on > http://wwwhni.uni-paderborn.de/service/standort.php3 Do we have net access there? Or do we have to do an internal network of our own? -- Bertrand LUPART Linkeo.com - R&D | http://www.linkeo.com/ +33 1 72 71 71 82 | 17, rue de la Banque - F75002 Paris Syste`mes de gestion d'email entrant | Email management systems

1 0

Re: [caudium-devel] Pike conference
by Martin Nilsson (ja till euro, nej till cent) ＠ Pike (-) developers forum 12 Aug '03

12 Aug '03

You mean a hands on version of http://pike.ida.liu.se/docs/tutorial/ ? / Martin Nilsson (ja till euro, nej till cent) Previous text: >2003-08-12 13:36: >Subject: Re: [caudium-devel] Pike conference >-------------------------------------------------------------------- >On Tue, Aug 12, 2003 at 07:30:04AM -0400, Martin Nilsson (ja till euro, nej till cent) @ Pike (-) developers forum wrote: >> I can give a "Current state of Pike" talk. > >excellent, you're on! > >who else? > >i talked to a group of students in essen, who are currently working on a >project for sTeam. they have expressed interest in a pike beginners >tutorial. anyone interrested to do that? > >greetings, martin. > > > / Brevbäraren >

2 1

Machine code efficiency
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 08 Aug '03

08 Aug '03

I've tested on a few more architectures now and it seems that it indeed is Athlon specific. The following are measurements with machine code. The last column is the difference in user time wrt without machine code. sparc (Ultra-80): test total user mem (runs) diff Compile.................... 6.588s 4.096s -1kb (76) (5894 lines/s) 2% Compile & Exec............. 7.060s 4.488s -1kb (71) (134009 lines/s) 0% Ackermann.................. 5.311s 2.841s -1kb (95) -10% Loops Nested (local)....... 4.426s 1.981s -1kb (100) (8469060 iters/s) 9% Loops Nested (global)...... 4.992s 2.532s -1kb (100) (6625550 iters/s) -18% Loops Recursed............. 4.747s 2.270s -1kb (100) (461968 iters/s) -16% Seems like local variable accesses could be improved on sparc. ia32 (PIII 700 MHz): test total user mem (runs) diff Compile.................... 3.462s 2.945s 5260kb (100) (8198 lines/s) 11% Compile & Exec............. 3.408s 2.760s 3628kb (100) (217922 lines/s) 9% Ackermann.................. 1.789s 1.323s 3716kb (100) -8% Loops Nested (local)....... 1.217s 0.740s 3504kb (100) (22678034 iters/s) -27% Loops Nested (global)...... 1.857s 1.359s 3504kb (100) (12342540 iters/s) -23% Loops Recursed............. 1.512s 1.031s 3504kb (100) (1017443 iters/s) -9% ia32 (Athlon XP 1535 MHz): test total user mem (runs) diff Compile.................... 1.464s 1.251s 5244kb (100) (19300 lines/s) 7% Compile & Exec............. 1.389s 1.197s 3656kb (100) (502423 lines/s) 6% Ackermann.................. 1.387s 1.198s 3724kb (100) 84% !! Loops Nested (local)....... 0.450s 0.261s 3508kb (100) (64182112 iters/s) -39% Loops Nested (global)...... 0.787s 0.598s 3508kb (100) (28036812 iters/s) -23% Loops Recursed............. 1.518s 1.329s 3508kb (100) (789115 iters/s) 172% !! I also tried with a binary copied from the PIII system on my Athlon in case there's some kind of compiler difference, but that didn't change anything much. It's amazing that some cpu difference can have this dramatic effect on function call performance. It'd be interesting to see this on more systems. / Martin Stjernholm, Roxen IS Previous text: >2003-07-31 02:18: >Subject: Machine code efficiency >-------------------------------------------------------------------- >It's on an Athlon XP. But if that matters appreciably then it's a >problem in itself. I doubt it, though. Anyway, please try it yourself >and see if there's a difference. > > / Martin Stjernholm, Roxen IS >

6 37

Machine code efficiency
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 07 Aug '03

07 Aug '03

Perhaps I should point out that the percentages in the "diff" columns are still against non-machine code and not the previous machine code results.

1 0

LDAP decoding problem
by Peter Bortas (med ny klient) ＠ Pike (-) developers forum 07 Aug '03

07 Aug '03

Using Pike 7.2.259 delivered with Roxen 2.2.252 I tried to extract a huge amount uf user data via LDAP search. This ended badly: > object s = c->search("(objectclass=liustudent)", 0 ,({ "cn", "uid", "dn" })); utf8_to_string(): Unexpected continuation block 0xb4 at index 7. /export/home/zino/roxen/roxen/server-2.2.252/pike/lib/pike/modules/Protocols.pmod/LDAP.pmod/client.pike:137: _get_attr_values(3,Types.asn1_sequence()) /export/home/zino/roxen/roxen/server-2.2.252/pike/lib/pike/modules/Protocols.pmod/LDAP.pmod/client.pike:154: _New_decode(({"*censored*",,,4447 0})) /export/home/zino/roxen/roxen/server-2.2.252/pike/lib/pike/modules/Protocols.pmod/LDAP.pmod/client.pike:194: create(({"*censored*",,,44471}),0 ) /export/home/zino/roxen/roxen/server-2.2.252/pike/lib/pike/modules/Protocols.pmod/LDAP.pmod/client.pike: Stdio.File("socket", "*censored*:389", 777 /* fd=7 */)->result() /export/home/zino/roxen/roxen/server-2.2.252/pike/lib/pike/modules/Protocols.pmod/LDAP.pmod/client.pike:937: Stdio.File("socket", "*censored*:389", 777 /* fd=7 */)->search("( objectclass=liustudent)",0,({"cn","uid","dn"})) -:1: ___Foo4711() We are talking more than 40k users, so "out of memory" (or death by signal) I could have expected, but not this. What goes wrong really? Sidenote: A streaming search would probably be good if someone has time they don't know what to do with. This particular search takes more than one hour to execute. (I can solve my problem in other ways, but connection->search()->next()->fetch()->next()->fetch() and so on seemed natural when I'm going to check every user.)

2 5

Pike conference
by David Gourdelier 07 Aug '03

07 Aug '03

Hello,

6 7

has_index()
by Peter Lundqvist (disjunkt) ＠ Pike (-) developers forum 05 Aug '03

05 Aug '03

Just now on IRC I got a question on has_index() and multisets. It turns out (in various pike versions) that Pike v7.4 release 11 running Hilfe v3.5 (Incremental Pike Frontend) > mixed m= (<"foo","bar">); > m["foo"]; (1) Result: 1 > has_index(m,"foo"); (2) Result: 0 > search(indices(m),"foo"); (3) Result: 1 > wich is not consistent with the documentation, right?

2 4

Protocols.IMAP
by Peter Bortas (med ny klient) ＠ Pike (-) developers forum 04 Aug '03

04 Aug '03

Protocols.IMAP is totally without documentation. Is there a client part and where do I start unraveling it?

7 8

Nettle
by Martin Nilsson (ja till euro, nej till cent) ＠ Pike (-) developers forum 03 Aug '03

03 Aug '03

I've been poking a bit with Nettle and the Crypto module and have made a few advancements. I could use some help though, to have the transition from Pikes crypto lib to nettle done as soon as possible. Things left to do is - Implementing MD4 in Nettle. I made one attempt, but it needs a review. - Implementing MD2 in Nettle. - Adding MD2 glue to Pike. - Adding Arcfour glue to Pike. - Adding DES glue to Pike. - Adding DES3 glue to Pike. - Adding Blowfish glue to Pike. All of those are fairly straight forward. The following are a bit more complicated. - Decide if we should use a Pike implementation of HMAC or use the Nettle one (and if so write a glue). - Make a glue to the Yarrow random code. - Figure out how to make cbc mode crypto (as now?) - Decide what to do with Crypto.pipe. (Implement in Pike?) - Create compatibility functions that doesn't need the Pike C crypto lib. - Create a testsuite that tests both the new Crypto stuff and the old.

1 0

/tmp/mysql.sock
by edde (nu med b�ge!!!) ＠ Pike (-) developers forum 02 Aug '03

02 Aug '03

Det där är något som jag poängterat i 2-3 år nu... Har visst något att göra med byggsystemet på Roxen. Vill du ha en bättre lösning än en symlänk i /tmp så kolla min sajt www.nutshell.nu där det finns en del tips. / edde (nu med båge!!!) Previous text: >2003-08-02 13:45: >Subject: /tmp/mysql.sock >-------------------------------------------------------------------- >Önskemål: > >RH-paketet av Roxen (dvs dess Pike?) borde som default leta efter >/var/lib/mysql/mysql.sock i stället för /tmp/mysql.sock. > >Jag sköt mig just själv i foten när jag skapade en symlänk från >/var/lib/mysql/mysql.sock till /tmp/mysql.sock som tmpwatch raderade >några dagar senare. > > / Hedda (Det är enklare med euro!) >

2 4

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