[#8566] Visions for 2001/1.7.x development? — Robert Feldt <feldt@...>

Hi matz and other Ruby developers,

18 messages 2001/01/03
[#8645] Re: Visions for 2001/1.7.x development? — matz@... (Yukihiro Matsumoto) 2001/01/04

Hi,

[#8580] bug?? — jmichel@... (Jean Michel)

I don't understand the following behaviour:

19 messages 2001/01/03

[#8633] Interesting Language performance comparisons - Ruby, OCAML etc — "g forever" <g24ever@...>

13 messages 2001/01/04

[#8774] No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...>

So, why not include Comparable in Array by default? It shouldn't have any

28 messages 2001/01/07
[#8779] Re: No :<, :>, etc. methods for Array — matz@... (Yukihiro Matsumoto) 2001/01/07

Hi,

[#8780] Re: No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...> 2001/01/07

matz@zetabits.com (Yukihiro Matsumoto) wrote:

[#8781] Re: No :<, :>, etc. methods for Array — gotoken@... (GOTO Kentaro) 2001/01/07

In message "[ruby-talk:8780] Re: No :<, :>, etc. methods for Array"

[#8782] Re: No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...> 2001/01/07

gotoken@math.sci.hokudai.ac.jp (GOTO Kentaro) wrote:

[#8829] Sandbox (again) — wys@... (Clemens Wyss)

Hi,

20 messages 2001/01/08
[#8864] Re: Sandbox (again) — Clemens Hintze <c.hintze@...> 2001/01/08

On 8 Jan, Clemens Wyss wrote:

[#8931] String confusion — Anders Bengtsson <ndrsbngtssn@...>

Hello everyone,

21 messages 2001/01/09
[#8937] Re: String confusion — matz@... (Yukihiro Matsumoto) 2001/01/09

Hi,

[#8953] Please remove account from files — "Thomas Daniels" <westernporter@...>

Please take my e-mail address from your files and "CANCEL" my subscription to "Ruby-Talk". Ruby is not right for what I do. The "Bulk Mail" is overwhelming. Please, no more e-mail! Thank you! yours truly, Stan Daniels

14 messages 2001/01/09
[#8983] Re: Please remove account from files — John Rubinubi <rubinubi@...> 2001/01/10

On Wed, 10 Jan 2001, Thomas Daniels wrote:

[#9020] time to divide -talk? (was: Please remove account from files) — Yasushi Shoji <yashi@...> 2001/01/10

At Wed, 10 Jan 2001 14:23:30 +0900,

[#9047] Re: time to divide -talk? (was: Please remov e account from files) — Aleksi Niemel<aleksi.niemela@...>

Yasushi Shoji:

27 messages 2001/01/10
[#9049] Re: time to divide -talk? — Yasushi Shoji <yashi@...> 2001/01/10

At Thu, 11 Jan 2001 00:20:45 +0900,

[#9153] what about this begin? — Anders Strandl Elkj誡 <ase@...> 2001/01/11

[#9195] Re: Redefining singleton methods — ts <decoux@...>

>>>>> "H" == Horst Duch=EAne?= <iso-8859-1> writes:

10 messages 2001/01/12

[#9242] polymorphism — Maurice Szmurlo <maurice@...>

hello

73 messages 2001/01/13

[#9279] Can ruby replace php? — Jim Freeze <jim@...>

When I read that ruby could be used to replace PHP I got really

15 messages 2001/01/14

[#9411] The Ruby Way — "Conrad Schneiker" <schneiker@...>

As a member of the "Big 8" newsgroups, "The Ruby Way" (of posting) is to

15 messages 2001/01/17

[#9462] Re: reading an entire file as a string — ts <decoux@...>

>>>>> "R" == Raja S <raja@cs.indiana.edu> writes:

35 messages 2001/01/17
[#9465] Re: reading an entire file as a string — Dave Thomas <Dave@...> 2001/01/17

raja@cs.indiana.edu (Raja S.) writes:

[#9521] Larry Wall INterview — ianm74@...

Larry was interviewed at the Perl/Ruby conference in Koyoto:

20 messages 2001/01/18
[#10583] Re: Larry Wall INterview — "greg strockbine" <gstrock@...> 2001/02/08

Larry Wall's interview is how I found out

[#9610] Re: 101 Misconceptions About Dynamic Languages — "Ben Tilly" <ben_tilly@...>

"Christian" <christians@syd.microforte.com.au> wrote:

13 messages 2001/01/20

[#9761] Re: 101 Misconceptions About Dynamic Languages — ts <decoux@...>

>>>>> "C" == Christoph Rippel <crippel@primenet.com> writes:

16 messages 2001/01/23

[#9792] Ruby 162 installer available — Dave Thomas <Dave@...>

15 messages 2001/01/24

[#9958] Re: Vim syntax files again. — "Conrad Schneiker" <schneik@...>

Hugh Sasse wrote:

14 messages 2001/01/26
[#10065] Re: Vim syntax files again. — Hugh Sasse Staff Elec Eng <hgs@...> 2001/01/29

On Sat, 27 Jan 2001, Conrad Schneiker wrote:

[#9975] line continuation — "David Ruby" <ruby_david@...>

can a ruby statement break into multiple lines?

18 messages 2001/01/27
[#9976] Re: line continuation — Michael Neumann <neumann@...> 2001/01/27

On Sat, 27 Jan 2001, David Ruby wrote:

[#9988] Re: line continuation — harryo@... (Harry Ohlsen) 2001/01/28

>A statement break into mutliple lines if it is not complete,

[ruby-talk:9878] Re: Miniturising libraries on linux

From: "Ben Tilly" <ben_tilly@...>
Date: 2001-01-25 14:48:31 UTC
List: ruby-talk #9878
James Fenn <jfenn@uklinux.net> wrote:
>
>On Wed, 24 Jan 2001 14:23:19 -0500 (EST)
>Mathieu Bouchard <matju@cam.org> wrote:
[...]
> > 	(b) tar archive, not gzipped, but containing only .gz files
>
>isn't that what a tar.gz is anyway?

No.

These translations are non-commutative.  If you put on
your pants before your underwear you get a different
outcome than if you put on your underwear before your
pants... :-)

To get a tar.gz file you tar, and then gzip.  What is
being talked about here is gzip and then tar.  If you
have many small similar files then taring and gzipping
will give substantially better compression.  But if
you gzip and then tar, then the outside world has a
tar file and you can extract any individual file by
itself.

Think of gzip as a type of encryption for a second (*).
If you tar and then encrypt, you canot even tell that
you have a tar file until you decrypt.  Whereas if you
encrypt then tar you can see that you have a tar file,
but you cannot read the files in it without decrypting.

[...]

Cheers,
Ben

PS Though encryption and compression are very dissimilar
   operations, there is a connection.  Perceived
   randomness of data is connected to information density.
   White noise has a density of 1.  Compression carries the
   same information in less data, so the density of
   compressed data moves towards 1.  Encryption scrambles
   data so that without all of it and a secret key you
   cannot tell that its density is not 1.

   This leads to several basic facts of information theory:
   1. White noise, compressed data, and encrypted data
      look pretty much the same.  Therefore if you need
      a large sample of fairly good random data, grab a
      large volatile data file, compress, encrypt, and
      then sample from there.  (Avoid headers.)
   2. White noise and encrypted data are not compressible.
      Don't even try.
   3. While there is no point in encrypting and then
      compressing data, if you compress and then encrypt
      you usually get a much better encryption.  For
      instance the classical Unix crypt utility can be
      trivially decrypted if you use it on straight
      text.  But if you compress and then encrypt it poses
      (somewhat) more of a challenge.  (Of course far, far
      better encryptions are widely available.  But even
      they will be better if you compress first.)
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

In This Thread

Prev Next