Re: Two debconf issues

2001-05-07 Thread Brendan O'Dea
On Sat, May 05, 2001 at 02:03:59AM +0300, Shaul Karl wrote:
Can you compare Perl speed to Python? 
Just curious, have no prior knowledge on this.

Can you?  Of course you can.  Has someone?  Very probably, although I
can't recall seeing an instance off-hand.

Compare Perl speed to Python is pretty open ended question though.  In
general?  For task X?  Task Y?

While it doesn't mention Python specifically, there is a very
interesting paper by Kernighan and Van Wyk describing some experiments
with various tasks in different languages which is germane to this
thread:

Timing Trials, or, the Trials of Timing
http://www.cs.bell-labs.com/cm/cs/who/bwk/interps/pap.html

Regards,
-- 
Brendan O'Deabod@compusol.com.au
Compusol Pty. Limited  (NSW, Australia)  +61 2 9810 3633




Re: Two debconf issues

2001-05-07 Thread Paolo Molaro
On 05/07/01 Brendan O'Dea wrote:
 On Sat, May 05, 2001 at 02:03:59AM +0300, Shaul Karl wrote:
 Can you compare Perl speed to Python? 
 Just curious, have no prior knowledge on this.
 
 Can you?  Of course you can.  Has someone?  Very probably, although I
 can't recall seeing an instance off-hand.
 
 Compare Perl speed to Python is pretty open ended question though.  In
 general?  For task X?  Task Y?

Here it is a comparison for one specific task: starting a graphical
application that uses the gtk bindings for either python or perl.
The comparison involves also disk and runtime memory issues as well
as completeness of the binding.
If you want more context search the gnome-hackers archives.

=cut cut=

On 03/21/01 Alan Cox wrote:
 Perl bothers me - which perl 5.6 5.005 ... all of them are syntatically subtly
 incompatible. Perl is also about a 20Mb minimum footprint on disk.

Currently the perl binding is tested with 5.005 and 5.6, but should
work with 5.004 and probably with 5.003 too. As for the version
required by the applications I'm not aware of any significant
incompatibility at least between 5.005 - 5.6 (check the perldelta 
manpage).

Also I'd like to point out that 20 Mb minimum footprint is really
20 M_b_ and not 20 MB:-)

$ dpkg -s perl-base |grep ^Installed-Size
Installed-Size: 2520

This is version 5.6. It's likely older versions are smaller.
Note that this includes 300 KB of changelogs, so the minimum perl
installation is more like 2200 KB. A more complete perl package
will get us to about 6 MB including the development files and other
utilities written in perl.
The documentation amounts to slightly more than 6 megs for a total
of about 13 MB.

The python situation is similar:
$ dpkg -s python-base python-dev python-doc |grep ^In
Installed-Size: 2696
Installed-Size: 1132
Installed-Size: 6968

For a total of about 11 MB (remember that the perl packages contain
500 KB of compressed changelogs more than python and a number of
utilities, from the profiler to sed and awk replacements).

So the difference in size doesn't hold: if redhat uses a single
big package for all of perl, it's redhat's fault:-) I wonder how
it gets to the 20 Mb figure, though, maybe it includes other
modules from CPAN?

And now to some other issues:

Loading speed in ms (on my K6 400 with 128 MB RAM):
The python program are 'from gtk import *' and 'from gnome.ui import *'.
The perl programs are 'perl -MGtk=-init -e 0' and 
'perl -MGnome -e init Gnome $0'.

python  perl
gtk 0.715   0.680   (took the best result for python and the worse for
perl in a number of runs each after a find /)
gtk
cached  0.715   0.280  (values taken after running the same program a few 
times, best value for python, worst for perl: the
average for perl is about 0.230)
gnome   1.083   0.777   (same as above for the Gnome support)
gnome
cached  1.085   0.379

So, the perl binding loads 3 times faster when there is an already running
interpreter. It would be interesting to have the numbers for smaller
machines, though.
I'd like to have the numbers for other scripting langages bindings, too.
FYI, for C programs I get 0.105 (gtk) and 0.230 (gnome).

Memory requirements: I used the same programs as above running under
memprof (after adding a sleep() call at the end) and noting the max 
memory usage. Please point out if there are better ways to do this
or if the results from this procedure are not significant for some 
reason.

python  perl
gtk 1032 KB 915 KB
gnome   1576 KB 1341 KB

I have already implemented a lazy-loading mechanism in cvs gnome-perl
that reduces the perl numbers to 710 KB and 1031 KB (if the
program uses _all_ the widgets in gtk and gnome there is no change
in the end, but this is unlikely).

Completeness: it's really hard to find a way to measure this, but let's
try anyway, since the results I get seem to imply the perl binding is the
more complete:-) The program I used is attached. It works this way:
for a number of libraries (libgtk, libgdk, libgnome etc. in the gnome
core) it checks the exported symbols and matches them against the
symbols required by the langauge bindings dynamic modules. I used to
use the program to find what functions are missing in my binding, but I
added a check for the python and guile modules while I was at it:-)
Note that some of the missing functions are bogus or useless for
a binding implementation. I think I have an almost complete perl,
python and guile gnome devel environment: let me know what numbers you
get (it's possible I'm missing some module or maybe the guile binding
doesn't have symbol references for all the functions it supports?).

Missing funcs in perl binding: 972/3201 total
Missing funcs in python binding: 1479/3201 total
Missing funcs in guile binding: 2220/3201 total

Executive summary:
Perl and python use basically the same disk space.
The perl binding loads faster, uses less memory and is more 

Re: Two debconf issues

2001-05-04 Thread Shaul Karl
 On Thu, May 03, 2001 at 05:00:29PM -0400, Joey Hess wrote:
  Wolfgang Sourdeau wrote:
It might happen if there was a good reason, but nobody has suggested 
one yet.
I doubt there is one.
   
   I have one. It's that dependency on perl makes owners of 486 machines die
   of an heart-attack whenever an installation task has to occur...
  
  Bollocks. Profile running perl sometime. Then profile running dpkg.
 
 Let me second this.  Perl is very, very fast.
 
 Perl is faster than most people's hand-crafted C code for certain
 tasks (mainly pattern matching type tasks, also its associative array
 implementation is pretty nippy).
 
 On my 68020 machine, using a short perl script was an order of
 magnitude faster than sed or awk, even for exactly the kind of pattern 
 matching tasks that sed and awk are designed for.
 
 Perl ain't your problem, it really ain't.
 
 Jules
 


Can you compare Perl speed to Python? 
Just curious, have no prior knowledge on this.
-- 

Shaul Karl [EMAIL PROTECTED]





Re: Two debconf issues

2001-05-04 Thread mdanish
I created a test program to do fibonacci series recursively in Perl, Python,
Scheme, Lisp, C, and OCaML.  Needless to say, OCaML kicked ass ;) But between
Perl and Python, Python performed better by about 20%.  On the other hand,
fibonacci series is a bit of a different application than whatever tasks
you may be talking about.

On Sat, May 05, 2001 at 02:03:59AM +0300, Shaul Karl wrote:
  On Thu, May 03, 2001 at 05:00:29PM -0400, Joey Hess wrote:
   Wolfgang Sourdeau wrote:
 It might happen if there was a good reason, but nobody has suggested 
 one yet.
 I doubt there is one.

I have one. It's that dependency on perl makes owners of 486 machines 
die
of an heart-attack whenever an installation task has to occur...
   
   Bollocks. Profile running perl sometime. Then profile running dpkg.
  
  Let me second this.  Perl is very, very fast.
  
  Perl is faster than most people's hand-crafted C code for certain
  tasks (mainly pattern matching type tasks, also its associative array
  implementation is pretty nippy).
  
  On my 68020 machine, using a short perl script was an order of
  magnitude faster than sed or awk, even for exactly the kind of pattern 
  matching tasks that sed and awk are designed for.
  
  Perl ain't your problem, it really ain't.
  
  Jules
  
 
 
 Can you compare Perl speed to Python? 
 Just curious, have no prior knowledge on this.
 -- 
   
   Shaul Karl [EMAIL PROTECTED]
 
 
 
 -- 
 To UNSUBSCRIBE, email to [EMAIL PROTECTED]
 with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
 

-- 
;;
;; Matthew Danish email: [EMAIL PROTECTED] ;;
;; GPG public key available from:'finger [EMAIL PROTECTED]' ;;
;;


pgp3U3E1I89kR.pgp
Description: PGP signature


Re: Two debconf issues

2001-05-03 Thread Hamish Moffatt
On Tue, May 01, 2001 at 05:04:12PM -0700, David Whedon wrote:
 debconf.  There has been discussion of making perl not required, but it 
 remains
 to be seen if that will happen.

It might happen if there was a good reason, but nobody has suggested one yet.
I doubt there is one.


Hamish
-- 
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]




Re: Two debconf issues

2001-05-03 Thread Wolfgang Sourdeau
 It might happen if there was a good reason, but nobody has suggested one yet.
 I doubt there is one.

I have one. It's that dependency on perl makes owners of 486 machines die
of an heart-attack whenever an installation task has to occur...


Wolfgang




Re: Two debconf issues

2001-05-03 Thread Joey Hess
Wolfgang Sourdeau wrote:
  It might happen if there was a good reason, but nobody has suggested one 
  yet.
  I doubt there is one.
 
 I have one. It's that dependency on perl makes owners of 486 machines die
 of an heart-attack whenever an installation task has to occur...

Bollocks. Profile running perl sometime. Then profile running dpkg.

-- 
see shy jo




Re: Two debconf issues

2001-05-03 Thread Adam Heath
On Thu, 3 May 2001, Joey Hess wrote:

 Wolfgang Sourdeau wrote:
   It might happen if there was a good reason, but nobody has suggested one 
   yet.
   I doubt there is one.
 
  I have one. It's that dependency on perl makes owners of 486 machines die
  of an heart-attack whenever an installation task has to occur...

 Bollocks. Profile running perl sometime. Then profile running dpkg.

profile dpkg 1.9.x, please.  Don't do it with 1.8.

I only say this, because 1.9 includes several fixes, gotten from profiling
data.




Re: Two debconf issues

2001-05-03 Thread Jules Bean
On Thu, May 03, 2001 at 05:00:29PM -0400, Joey Hess wrote:
 Wolfgang Sourdeau wrote:
   It might happen if there was a good reason, but nobody has suggested one 
   yet.
   I doubt there is one.
  
  I have one. It's that dependency on perl makes owners of 486 machines die
  of an heart-attack whenever an installation task has to occur...
 
 Bollocks. Profile running perl sometime. Then profile running dpkg.

Let me second this.  Perl is very, very fast.

Perl is faster than most people's hand-crafted C code for certain
tasks (mainly pattern matching type tasks, also its associative array
implementation is pretty nippy).

On my 68020 machine, using a short perl script was an order of
magnitude faster than sed or awk, even for exactly the kind of pattern 
matching tasks that sed and awk are designed for.

Perl ain't your problem, it really ain't.

Jules




Re: Two debconf issues

2001-05-02 Thread Adrian Bunk
On Tue, 1 May 2001, David Whedon wrote:

...
 In that case it would be that fact that perl-base is 'priority required' that
 allows you to avoid a dependancy on perl rather than the fact that you are 
 using
...

It's not the 'priority required' but the Essential: yes of perl-base
that makes sure that the package is always installed (as an example, mawk
is 'priority required' but not essential and I've removed it from my
system a long time ago).

 David

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.




Re: Two debconf issues

2001-05-02 Thread Joey Hess
Simon Richter wrote:
 I'm currently debconfizing one of my packages, uptimed. Two quoestions
 have arised:

That's debconfiscated[1].

  - At the start of my config script, I import all settings from the real
 configuration file, if it exists. For some settings, this is trivial,
 for some, I need rather complex text processing. Since perl isn't
 essential, writing the script in perl would make the package depend on
 perl while this is unnecessary for normal operation. Would this be
 acceptable or should I find a better solution?

But perl-base _is_ essential.

  - One of the strings should default to the empty string. How do I express
 that in a templates file?

Default:

-- 
see shy jo

[1] All your interactive postinsts are belong to us.




Re: Two debconf issues

2001-05-02 Thread John Galt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 2 May 2001, Joey Hess wrote:

Simon Richter wrote:
 I'm currently debconfizing one of my packages, uptimed. Two quoestions
 have arised:

That's debconfiscated[1].

No, that's what lilo did to install-mbr...
schnip

- -- 
Sacred cows make the best burgers

Who is John Galt?  [EMAIL PROTECTED], that's who!!!

-BEGIN PGP SIGNATURE-
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBOvDNXB9mehuYcOjMEQKooACfVLZgJEzIt1Q2tjlY/A3MuiB+uL4AnArk
YhCCMj6Qzd3LarvSunYR2mpA
=DtWS
-END PGP SIGNATURE-




Two debconf issues

2001-05-01 Thread Simon Richter
Hi,

I'm currently debconfizing one of my packages, uptimed. Two quoestions
have arised:

 - At the start of my config script, I import all settings from the real
configuration file, if it exists. For some settings, this is trivial,
for some, I need rather complex text processing. Since perl isn't
essential, writing the script in perl would make the package depend on
perl while this is unnecessary for normal operation. Would this be
acceptable or should I find a better solution?

 - One of the strings should default to the empty string. How do I express
that in a templates file?

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: DC26 EB8D 1F35 4F44 2934  7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!




RE: Two debconf issues

2001-05-01 Thread Sean 'Shaleh' Perry

On 01-May-2001 Simon Richter wrote:
 Hi,
 
 I'm currently debconfizing one of my packages, uptimed. Two quoestions
 have arised:
 
  - At the start of my config script, I import all settings from the real
 configuration file, if it exists. For some settings, this is trivial,
 for some, I need rather complex text processing. Since perl isn't
 essential, writing the script in perl would make the package depend on
 perl while this is unnecessary for normal operation. Would this be
 acceptable or should I find a better solution?
 
  - One of the strings should default to the empty string. How do I express
 that in a templates file?
 

If you use debconf you are using perl (-:  of course awk is your friend and
mine.




RE: Two debconf issues

2001-05-01 Thread Simon Richter
On Tue, 1 May 2001, Sean 'Shaleh' Perry wrote:

 If you use debconf you are using perl (-:  of course awk is your friend and
 mine.

Hrm, since that stuff will also tend to get ugly when written in awk, I
think I'm going to use perl then.

   Simon

-- 
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc
 Fingerprint: DC26 EB8D 1F35 4F44 2934  7583 DBB6 F98D 9198 3292
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!




Re: Two debconf issues

2001-05-01 Thread David Whedon
  for some, I need rather complex text processing. Since perl isn't
  essential, writing the script in perl would make the package depend on
  perl while this is unnecessary for normal operation. Would this be
  acceptable or should I find a better solution?
  
 
 If you use debconf you are using perl (-:  of course awk is your friend and
 mine.
 

It is likely that Randolph Chung's cdebconf
http://packages.debian.org/testing/utils/cdebconf.html
will be a complete and compatible alternative to the perl version in the future.

In that case it would be that fact that perl-base is 'priority required' that
allows you to avoid a dependancy on perl rather than the fact that you are using
debconf.  There has been discussion of making perl not required, but it remains
to be seen if that will happen.


David