cpan.org · Domains · Slashdot Mirror

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Re:This is the beginning of the revolution by Shiny+Metal+S. · 2002-04-06 07:01 · Score: 1, Redundant · on Google to Offer API

This is really fantastic. I can already think of a dozen scripts or so that I'd like to write to take advantage of this.

I see that most of people probably don't know that there are already Perl modules on CPAN to search Google and even to use Google cache:

As you can see, it's already possible to use lots of different search engines in your own scripts. Of cource it's great news about Google API, but I wouldn't exactly call it a revolution. You could write a dozen of your scripts a very long time ago.

Here is what I have as my perfect email client by TV-SET · 2002-04-06 02:44 · Score: 3, Insightful · on The Perfect Email Client?

There are three major points for my perfect email client:

1. Look and feel the same in X and console, so that I could make use of both xpdf/mozilla and remote mail reading.
2. Localization. Being non-native english speaker, this one is pretty important.
3. Keyboard navigation

For the last 4 years I am extremely satisfied with the combination:
- fetchmail (getting mail)
- procmail (sorting mail into mailboxes)
- mutt (reading/replying)
- vim (editing)

When it comes down to analyze mailbox and generate some reports, like for example, in the case with antivirus reports, I use perl with Mail::MboxParser module.

For all my friends, who need GUI to read email, I recommend using Mozilla and or Evolution

Perl Users All Thank Sun For Their Support by twoshortplanks · 2002-04-01 09:08 · Score: 3, Informative · on CPAN Shifts Focus

In real non april 1st way, the Perl Peeps are all really grateful for Sun's support of Perl.

Recently Sun donated some new hardware to make search.cpan.org work a lot faster. This was covered on use Perl.

Thanks Sun!

Re:this'll show 'em by WWWWolf · 2002-03-20 22:40 · Score: 2, Insightful · on SedSokoban

Hey, let's not be unfair. At least we Perl users have terminal control libraries and something that looks like a programming language. Besides, using sed for "real" programming is hard and challenging and people stand in awe, but using Perl for real programming is just fun and no one notices if you program something infinitely cool with it, because Perl was made so that infinitely cool things could be made easily.

This hack is impressive because it was made in a toothless environment, not because it has not yet been implemented in some better language =)

Re:Erm, right... by alangmead · 2002-03-11 10:55 · Score: 1 · on Mac OS X 3D File Browser

You view of what is trivial resources is based specifically current manufacturing technology and economics. The 256K that explorer.exe takes on my windows box would be unreasonable 5 years ago.

To reach the current state of GUI file managers, they (the same they that you were referring to.) that basing the system on recalling visual cues over remembering commands gave certain advantages to a certain group of users. I'd consider this an experiment in whether a spatial cues help or hinder the users navigation of the system.

By the time this research manifests itself as a marketable product, it might not be a 3D browser any more. It might just be that some facet of this app makes someone figure out how to create a single paned view that can show disparate parts of the file system hierarchy.

This reminds me a bit about an argument I had with a friend of mine about Lingua::Romana::Perligata. He couldn't see the package as anything but a waste of time, programming in a dead natural language. The point that I tried to make about the library isn't simply to write programs in latin. It could be viewed as an experiment in determining whether programming languages are required to be positionally dependent. If the results from Lingua::Romana::Perligata showed that there were significant advantages from determining syntax from inflection rather than position, a new syntax (not based on dead languages) could be developed by someone creating a commercial product.

Depends on what you are programming by Kirruth · 2002-03-10 00:44 · Score: 3, Informative · on Cheap Software Languages for NT?

It's not clear what kinds of areas you are working on, so its not easy to recommend a tool.

Personally, I use C/C++ for general purpose apps. Nevertheless, for text/scripts Perl is hard to beat, for objects/GUIs Python is amazing, and Haskell wipes the floor with all the other languages on numerical/functional work. (OK, I admit, I have no life).

In terms of tools,

DevC++and Cygwin, work well for C/C++ development, and together form a nice little set of tools.

Perl can be found at CPANwhich has links to various interpreters and IDEs. It is a language of crazed brilliance, and is wonderfully cross-platform.

Python is really great, comes with a very well-thought-out IDE (IDLE) and a very familiar syntax. It has standard modules which will link it to C++ and Windows.

And finally, Haskell is at Haskell.org, and offers Hugs, which is probably the most advanced open-source IDE available for any language.

With so many wondrous open source tools available, I feel pretty bad about saying this, but your best bet in a corporate environment might actually be Java. It's boring, it's a little slow, its overhyped. In short, it is the Devil and whenever I have used it, I have wanted to kill myself and my neighbours. Still, its free, popular and backed by a big old corporation, its very similar to C++ and you won't get fired for choosing it. Best go with Java.

Re:My perl is not as grand as it once was... by Shiny+Metal+S. · 2002-03-09 16:53 · Score: 2 · on 16th IOCCC Winners Announced

...but I do not think that perl is the "Write Once, Read Nowhere" langue you make it out to be ^_^

My post was actually a joke (I'm surprised that someone has moderated it as Troll! If that moderator thought I don't like Perl, he/she obviously hasn't read my code...) and this was a parody for Java's "write once, run everywhere".

Just for a little fun, I thought I'd try out my rusting perl tricks and unroll your silly script.

You're a first person I know about, who was ever interested in understanding this code. This is my original, clean version:

$c = 'plfeY04jaJnYI'; $s = substr $c, 0, 2; for $l (1..8) { for ('a' x $l .. 'z' x $l){ if($c eq crypt($_, $s)) { print "$_.$s\n"; exit; } } }

I'm amazed, that your code is almost identical, congratulations! I like this program, because looking at it (the clean version) it's impossible to know how long it would take to get the result. For example your domain voila.fr would be written if $c was frmHZ0u6Ne2HQ but it takes about an hour to crack on my machine, while my domain in plfeY04jaJnYI is cracked in only 4 seconds. It would take over 2 years and 7 months to crack this xxFHuIaD7CdpI, which is the worst case, zzzzzzzz, the last key guessed by my program. So, the average time for guessing random keys (containing 1 to 8 lowercase letters) is over one year!

If you want to see a really good password cracking program, check out Alec Muffett's great and famous Crack. It's really great, especially when you have good dictionaries. If you want to check if your password is easily cracked by Crack, you can use Alec Muffett's CrackLib. Check out my online Password-Guessability-O-Meter, I wrote it some time ago to demonstrate to one of my clients how does the CrackLib work. You just enter your desired password, and it tells you if (and why) it is easy to guess, using English, Polish, Czech, French and Latin dictionaries.

I use CrackLib for online registrations CGI scripts etc. so users can't have silly and easy to guess passwords. It can also be used with passwd program. Great library, and easy to use (there's Crypt::Cracklib Perl interface), but may be quite difficult to set up for the first time.

Not very difficile, Mister shiny@rfl.pl, but I shall compliment you for at least trying to obfuscate with the silly "q//" perl operateur ^_^

Thanks. :) I like it too. That's the most recent obfuscation, if I remember correctly. When I started to experiment with q// using q,x, and q.x. and q;x; etc. I was even trying to use something like this:

$q=q,p,.q,l,.q,f,.q,e,.q,Y,.q,0,.q,4,.q,j,.q,a,.q, J,.q,n,.q,Y,.q,I,;

(in one line and with no spaces) but it looks terrible, as you can see.

The "if" statement is another ruse; suffixed "if" is in fact called before the condition of the "if" statement, and he uses this to initialise $q apparently after it's been first used. The above code is in fact equal to this:
$q = 'plfeY04jaJnYI'; $x = substr $q, 0, 2;

Yes, this is exactly the original code, and this is exactly the way I was thinking. You're very good. :)

And it makes itself apparent that $q is the crypt hash (henceforth called $crypt) and $x is the salt ($salt).

The original variables were $c and $s, I changed them to $q and $x for easy mistakes with q// quoting and x repetition operator.

for (++$_..$_<<3){...}
Now you are just being silly :-) $_ is not used yet and thus is 0, and ++0 is of course 1. 1<<3 is 8.

:) 1..8 looked just to clear and simple... And that way I have 3 independent values of $_ variable (i.e. the original global $::_ is two times localized) in 3 nested scopes (main program, outer loop and inner loop), which makes it more interesting.

for($i = 1; $i <= 8; ++$i) {...}
Which not only looks simpler, but runs faster too ^_^

Actually in newer versions of Perl, the foreach loop is faster than the C-style for loop. See perlop manpage: Range Operators and perlsyn manpage: Foreach Loops.

I just run this benchmark:

#!/usr/bin/perl -w use Benchmark; sub s1{ for ($i = 1; $i <= 1_000_000; ++$i) { } } sub s2{ for (1 .. 1_000_000) { } } $t1 = timestr timeit 100, \ $t2 = timestr timeit 100, \ print "1. $t1\n2. $t2\n";

and with Perl 5.6.1 I got this results:

1. 103 wallclock secs (87.77 usr + 0.15 sys = 87.92 CPU) @ 1.14/s (n=100)
2. 60 wallclock secs (51.93 usr + 0.04 sys = 51.97 CPU) @ 1.92/s (n=100)

But in my code this loop has only eight iterations, where the 8th one takes two years, so the loop control overhead itself doesn't really matter here. The inner loop is more important but crack() function takes most of the time, anyway.

Older versions of Perl (I don't know which exactly) created a temporary array for the range operator in foreach loop, so the code like:

for (1 .. 1_000_000_000) { ... }

could easily take all of the memory, but now it's fixed. Fortunately, it doesn't create a temporary array any more, and it's highly optimized, so it's safe to use it now for large ranges.

The "and die" bit just is taking advantage of the short-circuit boolean operateur système. The "die" only is executing when $crypt (the origin hash) and the encrypted form of the current guess are equal, in which case the key has been found and we quit ^_^ I changed it to a nicer looking "print" statement for further clairitie.

Yes, there were print and exit in the original version. You have exactly reconstructed my way of thinking. Well done. :)

I think you're very good, really. Most of people have no idea how to analyze such obfuscated code. Actually I'm quite disappointed that decrypting my code was so easy for you... :)

I'll tell you why and how I wrote this program. I was inspired by this code:

#!/usr/bin/perl @a=(Lbzjoftt,Inqbujfodf, Hvcsjt); $b="Lbssz Wbmm" ;$b =~ y/b-z/a-z/ ; $c = " Tif ". @a ." hsfbu wj" ."suvft pg b qsphsbnnfs" . ":\n";$c =~y/b-y/a-z/; print"\n\n$c ";for($i=0; $i<@a; $i++) { $a[$i] =~ y/b-y/a-z/;if($a[$i]eq$a [-1]){print"and $a[$i]." ;}else{ print"$a[$i], "; }}print"\n\t\t--$b\n\n";

and few JAPH signatures. I wanted to write a small program, that it would be impossible to tell what it writes, until you run it. Most of such programs are very obfuscated but after enough work you can usually find the printed message, without running them. So I thought that the message could be ciphered using some one-way alghoritm, like crypt(3) or MD5, and the code would just brute-force crack it. That way it's really impossible to tell what the message is, until you run the code. The code itself only cracks, but doesn't know what is being cracked and when it finishes. Using crypt(3) had this advantage, that it has 2-character salt, which can act as country code in domain name.

So I wrote the first working version and started to make it as small as possible. Originally it didn't have to be obfuscated, just small. This is the smallest version I've written so far:

$c='plfeY04jaJnYI';$s=substr$c,0, 2;for(1..8){for('a'x$_..'z'x$_){ die"$_.$s\n"if crypt($_,$s)eq$c}}

with 98 characters. But today I shrinked it some more, to 93 characters:

$c='plfeY04jaJnYI';$s=substr$c, 0,2;for(1..8){$c eq crypt$_,$s and die"$_.$s"for'a'x$_..'z'x$_}

and few minutes ago (while I write this comment!) I found a better idea and wrote this:

$c='plfeY04jaJnYI';$s=substr$c,0,2;$k= 'a';$k++while$c ne crypt$k,$s;die"$k.$s";

which having only 79 characters is my record so far (thanks to Perl's magical auto-increment operator) and finally fits in one line!

Hopefully that wasn't too difficile to follow, my english is not perfect.

Your english is OK, don't worry. Actually, I like the way you use French spelling for some words, like difficile. It's like a French accent in written text, very nice in my opinion.

Just remember, Mr. shiny@rfl.pl, no langue is completely impenetrable (except perhaps Intercal, but that's a small bit pathological :-)

Good point. :) I wonder if these guys tried Intercal when proving the impossibility of obfuscating programs... I personally like Unlambda and Brainf***.

This Unlambda program "calculates and prints the Fibonacci numbers (as lines of asterisks)":

```s``s``sii`ki `k.*``s``s`ks ``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk `k``s`ksk

I wanted to show a Hello world example of Brainf***, but I got this error:

Lameness filter encountered. Post aborted!
Reason: Please use fewer 'junk' characters.

Visit Esoteric Topics in Computer Programming, great stuff if you want to go mad.

You like Perl, so if you know Inline::C and Inline::CPR (if you don't, read Pathologically Polluting Perl by Brian Ingerson) you may enjoy understanding this code:

#!/usr/bin/cpr int main(void) { CPR_eval("use Inline (C => q{ char* greet() { return \"Hello world\"; } })"); printf("%s, I'm running under Perl version %s\n", CPR_eval("&greet"), CPR_eval("use Config; $Config{version}")); return 0; }

It's great, once you really understand it.

Are you up to date with Perl 6 development? It's going to be great and extremely powerful language. Read Larry Wall's Apocalypses and Damian Conway's Exegeses if you're interested:

Apocalypse 1: The Ugly, the Bad, and the Good (April 2, 2001)
Apocalypse 2: Fundamental data types, variables and the context and scoping of the language (May 3, 2001)
Exegesis 2 (May 15, 2001)
Apocalypse 3: Operators (October 2, 2001)
Exegesis 3 (October 3, 2001)
Apocalypse 4: Syntax (January 18, 2002)

It's my favorite language already, and it's not even fully designed yet.

Re:My perl is not as grand as it once was... by Shiny+Metal+S. · 2002-03-09 16:53 · Score: 2 · on 16th IOCCC Winners Announced

...but I do not think that perl is the "Write Once, Read Nowhere" langue you make it out to be ^_^

My post was actually a joke (I'm surprised that someone has moderated it as Troll! If that moderator thought I don't like Perl, he/she obviously hasn't read my code...) and this was a parody for Java's "write once, run everywhere".

Just for a little fun, I thought I'd try out my rusting perl tricks and unroll your silly script.

You're a first person I know about, who was ever interested in understanding this code. This is my original, clean version:

$c = 'plfeY04jaJnYI'; $s = substr $c, 0, 2; for $l (1..8) { for ('a' x $l .. 'z' x $l){ if($c eq crypt($_, $s)) { print "$_.$s\n"; exit; } } }

I'm amazed, that your code is almost identical, congratulations! I like this program, because looking at it (the clean version) it's impossible to know how long it would take to get the result. For example your domain voila.fr would be written if $c was frmHZ0u6Ne2HQ but it takes about an hour to crack on my machine, while my domain in plfeY04jaJnYI is cracked in only 4 seconds. It would take over 2 years and 7 months to crack this xxFHuIaD7CdpI, which is the worst case, zzzzzzzz, the last key guessed by my program. So, the average time for guessing random keys (containing 1 to 8 lowercase letters) is over one year!

If you want to see a really good password cracking program, check out Alec Muffett's great and famous Crack. It's really great, especially when you have good dictionaries. If you want to check if your password is easily cracked by Crack, you can use Alec Muffett's CrackLib. Check out my online Password-Guessability-O-Meter, I wrote it some time ago to demonstrate to one of my clients how does the CrackLib work. You just enter your desired password, and it tells you if (and why) it is easy to guess, using English, Polish, Czech, French and Latin dictionaries.

I use CrackLib for online registrations CGI scripts etc. so users can't have silly and easy to guess passwords. It can also be used with passwd program. Great library, and easy to use (there's Crypt::Cracklib Perl interface), but may be quite difficult to set up for the first time.

Not very difficile, Mister shiny@rfl.pl, but I shall compliment you for at least trying to obfuscate with the silly "q//" perl operateur ^_^

Thanks. :) I like it too. That's the most recent obfuscation, if I remember correctly. When I started to experiment with q// using q,x, and q.x. and q;x; etc. I was even trying to use something like this:

$q=q,p,.q,l,.q,f,.q,e,.q,Y,.q,0,.q,4,.q,j,.q,a,.q, J,.q,n,.q,Y,.q,I,;

(in one line and with no spaces) but it looks terrible, as you can see.

The "if" statement is another ruse; suffixed "if" is in fact called before the condition of the "if" statement, and he uses this to initialise $q apparently after it's been first used. The above code is in fact equal to this:
$q = 'plfeY04jaJnYI'; $x = substr $q, 0, 2;

Yes, this is exactly the original code, and this is exactly the way I was thinking. You're very good. :)

And it makes itself apparent that $q is the crypt hash (henceforth called $crypt) and $x is the salt ($salt).

The original variables were $c and $s, I changed them to $q and $x for easy mistakes with q// quoting and x repetition operator.

for (++$_..$_<<3){...}
Now you are just being silly :-) $_ is not used yet and thus is 0, and ++0 is of course 1. 1<<3 is 8.

:) 1..8 looked just to clear and simple... And that way I have 3 independent values of $_ variable (i.e. the original global $::_ is two times localized) in 3 nested scopes (main program, outer loop and inner loop), which makes it more interesting.

for($i = 1; $i <= 8; ++$i) {...}
Which not only looks simpler, but runs faster too ^_^

Actually in newer versions of Perl, the foreach loop is faster than the C-style for loop. See perlop manpage: Range Operators and perlsyn manpage: Foreach Loops.

I just run this benchmark:

#!/usr/bin/perl -w use Benchmark; sub s1{ for ($i = 1; $i <= 1_000_000; ++$i) { } } sub s2{ for (1 .. 1_000_000) { } } $t1 = timestr timeit 100, \ $t2 = timestr timeit 100, \ print "1. $t1\n2. $t2\n";

and with Perl 5.6.1 I got this results:

1. 103 wallclock secs (87.77 usr + 0.15 sys = 87.92 CPU) @ 1.14/s (n=100)
2. 60 wallclock secs (51.93 usr + 0.04 sys = 51.97 CPU) @ 1.92/s (n=100)

But in my code this loop has only eight iterations, where the 8th one takes two years, so the loop control overhead itself doesn't really matter here. The inner loop is more important but crack() function takes most of the time, anyway.

Older versions of Perl (I don't know which exactly) created a temporary array for the range operator in foreach loop, so the code like:

for (1 .. 1_000_000_000) { ... }

could easily take all of the memory, but now it's fixed. Fortunately, it doesn't create a temporary array any more, and it's highly optimized, so it's safe to use it now for large ranges.

The "and die" bit just is taking advantage of the short-circuit boolean operateur système. The "die" only is executing when $crypt (the origin hash) and the encrypted form of the current guess are equal, in which case the key has been found and we quit ^_^ I changed it to a nicer looking "print" statement for further clairitie.

Yes, there were print and exit in the original version. You have exactly reconstructed my way of thinking. Well done. :)

I think you're very good, really. Most of people have no idea how to analyze such obfuscated code. Actually I'm quite disappointed that decrypting my code was so easy for you... :)

I'll tell you why and how I wrote this program. I was inspired by this code:

#!/usr/bin/perl @a=(Lbzjoftt,Inqbujfodf, Hvcsjt); $b="Lbssz Wbmm" ;$b =~ y/b-z/a-z/ ; $c = " Tif ". @a ." hsfbu wj" ."suvft pg b qsphsbnnfs" . ":\n";$c =~y/b-y/a-z/; print"\n\n$c ";for($i=0; $i<@a; $i++) { $a[$i] =~ y/b-y/a-z/;if($a[$i]eq$a [-1]){print"and $a[$i]." ;}else{ print"$a[$i], "; }}print"\n\t\t--$b\n\n";

and few JAPH signatures. I wanted to write a small program, that it would be impossible to tell what it writes, until you run it. Most of such programs are very obfuscated but after enough work you can usually find the printed message, without running them. So I thought that the message could be ciphered using some one-way alghoritm, like crypt(3) or MD5, and the code would just brute-force crack it. That way it's really impossible to tell what the message is, until you run the code. The code itself only cracks, but doesn't know what is being cracked and when it finishes. Using crypt(3) had this advantage, that it has 2-character salt, which can act as country code in domain name.

So I wrote the first working version and started to make it as small as possible. Originally it didn't have to be obfuscated, just small. This is the smallest version I've written so far:

$c='plfeY04jaJnYI';$s=substr$c,0, 2;for(1..8){for('a'x$_..'z'x$_){ die"$_.$s\n"if crypt($_,$s)eq$c}}

with 98 characters. But today I shrinked it some more, to 93 characters:

$c='plfeY04jaJnYI';$s=substr$c, 0,2;for(1..8){$c eq crypt$_,$s and die"$_.$s"for'a'x$_..'z'x$_}

and few minutes ago (while I write this comment!) I found a better idea and wrote this:

$c='plfeY04jaJnYI';$s=substr$c,0,2;$k= 'a';$k++while$c ne crypt$k,$s;die"$k.$s";

which having only 79 characters is my record so far (thanks to Perl's magical auto-increment operator) and finally fits in one line!

Hopefully that wasn't too difficile to follow, my english is not perfect.

Your english is OK, don't worry. Actually, I like the way you use French spelling for some words, like difficile. It's like a French accent in written text, very nice in my opinion.

Just remember, Mr. shiny@rfl.pl, no langue is completely impenetrable (except perhaps Intercal, but that's a small bit pathological :-)

Good point. :) I wonder if these guys tried Intercal when proving the impossibility of obfuscating programs... I personally like Unlambda and Brainf***.

This Unlambda program "calculates and prints the Fibonacci numbers (as lines of asterisks)":

```s``s``sii`ki `k.*``s``s`ks ``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk `k``s`ksk

I wanted to show a Hello world example of Brainf***, but I got this error:

Lameness filter encountered. Post aborted!
Reason: Please use fewer 'junk' characters.

Visit Esoteric Topics in Computer Programming, great stuff if you want to go mad.

You like Perl, so if you know Inline::C and Inline::CPR (if you don't, read Pathologically Polluting Perl by Brian Ingerson) you may enjoy understanding this code:

#!/usr/bin/cpr int main(void) { CPR_eval("use Inline (C => q{ char* greet() { return \"Hello world\"; } })"); printf("%s, I'm running under Perl version %s\n", CPR_eval("&greet"), CPR_eval("use Config; $Config{version}")); return 0; }

It's great, once you really understand it.

Are you up to date with Perl 6 development? It's going to be great and extremely powerful language. Read Larry Wall's Apocalypses and Damian Conway's Exegeses if you're interested:

Apocalypse 1: The Ugly, the Bad, and the Good (April 2, 2001)
Apocalypse 2: Fundamental data types, variables and the context and scoping of the language (May 3, 2001)
Exegesis 2 (May 15, 2001)
Apocalypse 3: Operators (October 2, 2001)
Exegesis 3 (October 3, 2001)
Apocalypse 4: Syntax (January 18, 2002)

It's my favorite language already, and it's not even fully designed yet.

Re:My perl is not as grand as it once was... by Shiny+Metal+S. · 2002-03-09 16:53 · Score: 2 · on 16th IOCCC Winners Announced

...but I do not think that perl is the "Write Once, Read Nowhere" langue you make it out to be ^_^

My post was actually a joke (I'm surprised that someone has moderated it as Troll! If that moderator thought I don't like Perl, he/she obviously hasn't read my code...) and this was a parody for Java's "write once, run everywhere".

Just for a little fun, I thought I'd try out my rusting perl tricks and unroll your silly script.

You're a first person I know about, who was ever interested in understanding this code. This is my original, clean version:

$c = 'plfeY04jaJnYI'; $s = substr $c, 0, 2; for $l (1..8) { for ('a' x $l .. 'z' x $l){ if($c eq crypt($_, $s)) { print "$_.$s\n"; exit; } } }

I'm amazed, that your code is almost identical, congratulations! I like this program, because looking at it (the clean version) it's impossible to know how long it would take to get the result. For example your domain voila.fr would be written if $c was frmHZ0u6Ne2HQ but it takes about an hour to crack on my machine, while my domain in plfeY04jaJnYI is cracked in only 4 seconds. It would take over 2 years and 7 months to crack this xxFHuIaD7CdpI, which is the worst case, zzzzzzzz, the last key guessed by my program. So, the average time for guessing random keys (containing 1 to 8 lowercase letters) is over one year!

If you want to see a really good password cracking program, check out Alec Muffett's great and famous Crack. It's really great, especially when you have good dictionaries. If you want to check if your password is easily cracked by Crack, you can use Alec Muffett's CrackLib. Check out my online Password-Guessability-O-Meter, I wrote it some time ago to demonstrate to one of my clients how does the CrackLib work. You just enter your desired password, and it tells you if (and why) it is easy to guess, using English, Polish, Czech, French and Latin dictionaries.

I use CrackLib for online registrations CGI scripts etc. so users can't have silly and easy to guess passwords. It can also be used with passwd program. Great library, and easy to use (there's Crypt::Cracklib Perl interface), but may be quite difficult to set up for the first time.

Not very difficile, Mister shiny@rfl.pl, but I shall compliment you for at least trying to obfuscate with the silly "q//" perl operateur ^_^

Thanks. :) I like it too. That's the most recent obfuscation, if I remember correctly. When I started to experiment with q// using q,x, and q.x. and q;x; etc. I was even trying to use something like this:

$q=q,p,.q,l,.q,f,.q,e,.q,Y,.q,0,.q,4,.q,j,.q,a,.q, J,.q,n,.q,Y,.q,I,;

(in one line and with no spaces) but it looks terrible, as you can see.

The "if" statement is another ruse; suffixed "if" is in fact called before the condition of the "if" statement, and he uses this to initialise $q apparently after it's been first used. The above code is in fact equal to this:
$q = 'plfeY04jaJnYI'; $x = substr $q, 0, 2;

Yes, this is exactly the original code, and this is exactly the way I was thinking. You're very good. :)

And it makes itself apparent that $q is the crypt hash (henceforth called $crypt) and $x is the salt ($salt).

The original variables were $c and $s, I changed them to $q and $x for easy mistakes with q// quoting and x repetition operator.

for (++$_..$_<<3){...}
Now you are just being silly :-) $_ is not used yet and thus is 0, and ++0 is of course 1. 1<<3 is 8.

:) 1..8 looked just to clear and simple... And that way I have 3 independent values of $_ variable (i.e. the original global $::_ is two times localized) in 3 nested scopes (main program, outer loop and inner loop), which makes it more interesting.

for($i = 1; $i <= 8; ++$i) {...}
Which not only looks simpler, but runs faster too ^_^

Actually in newer versions of Perl, the foreach loop is faster than the C-style for loop. See perlop manpage: Range Operators and perlsyn manpage: Foreach Loops.

I just run this benchmark:

#!/usr/bin/perl -w use Benchmark; sub s1{ for ($i = 1; $i <= 1_000_000; ++$i) { } } sub s2{ for (1 .. 1_000_000) { } } $t1 = timestr timeit 100, \ $t2 = timestr timeit 100, \ print "1. $t1\n2. $t2\n";

and with Perl 5.6.1 I got this results:

1. 103 wallclock secs (87.77 usr + 0.15 sys = 87.92 CPU) @ 1.14/s (n=100)
2. 60 wallclock secs (51.93 usr + 0.04 sys = 51.97 CPU) @ 1.92/s (n=100)

But in my code this loop has only eight iterations, where the 8th one takes two years, so the loop control overhead itself doesn't really matter here. The inner loop is more important but crack() function takes most of the time, anyway.

Older versions of Perl (I don't know which exactly) created a temporary array for the range operator in foreach loop, so the code like:

for (1 .. 1_000_000_000) { ... }

could easily take all of the memory, but now it's fixed. Fortunately, it doesn't create a temporary array any more, and it's highly optimized, so it's safe to use it now for large ranges.

The "and die" bit just is taking advantage of the short-circuit boolean operateur système. The "die" only is executing when $crypt (the origin hash) and the encrypted form of the current guess are equal, in which case the key has been found and we quit ^_^ I changed it to a nicer looking "print" statement for further clairitie.

Yes, there were print and exit in the original version. You have exactly reconstructed my way of thinking. Well done. :)

I think you're very good, really. Most of people have no idea how to analyze such obfuscated code. Actually I'm quite disappointed that decrypting my code was so easy for you... :)

I'll tell you why and how I wrote this program. I was inspired by this code:

#!/usr/bin/perl @a=(Lbzjoftt,Inqbujfodf, Hvcsjt); $b="Lbssz Wbmm" ;$b =~ y/b-z/a-z/ ; $c = " Tif ". @a ." hsfbu wj" ."suvft pg b qsphsbnnfs" . ":\n";$c =~y/b-y/a-z/; print"\n\n$c ";for($i=0; $i<@a; $i++) { $a[$i] =~ y/b-y/a-z/;if($a[$i]eq$a [-1]){print"and $a[$i]." ;}else{ print"$a[$i], "; }}print"\n\t\t--$b\n\n";

and few JAPH signatures. I wanted to write a small program, that it would be impossible to tell what it writes, until you run it. Most of such programs are very obfuscated but after enough work you can usually find the printed message, without running them. So I thought that the message could be ciphered using some one-way alghoritm, like crypt(3) or MD5, and the code would just brute-force crack it. That way it's really impossible to tell what the message is, until you run the code. The code itself only cracks, but doesn't know what is being cracked and when it finishes. Using crypt(3) had this advantage, that it has 2-character salt, which can act as country code in domain name.

So I wrote the first working version and started to make it as small as possible. Originally it didn't have to be obfuscated, just small. This is the smallest version I've written so far:

$c='plfeY04jaJnYI';$s=substr$c,0, 2;for(1..8){for('a'x$_..'z'x$_){ die"$_.$s\n"if crypt($_,$s)eq$c}}

with 98 characters. But today I shrinked it some more, to 93 characters:

$c='plfeY04jaJnYI';$s=substr$c, 0,2;for(1..8){$c eq crypt$_,$s and die"$_.$s"for'a'x$_..'z'x$_}

and few minutes ago (while I write this comment!) I found a better idea and wrote this:

$c='plfeY04jaJnYI';$s=substr$c,0,2;$k= 'a';$k++while$c ne crypt$k,$s;die"$k.$s";

which having only 79 characters is my record so far (thanks to Perl's magical auto-increment operator) and finally fits in one line!

Hopefully that wasn't too difficile to follow, my english is not perfect.

Your english is OK, don't worry. Actually, I like the way you use French spelling for some words, like difficile. It's like a French accent in written text, very nice in my opinion.

Just remember, Mr. shiny@rfl.pl, no langue is completely impenetrable (except perhaps Intercal, but that's a small bit pathological :-)

Good point. :) I wonder if these guys tried Intercal when proving the impossibility of obfuscating programs... I personally like Unlambda and Brainf***.

This Unlambda program "calculates and prints the Fibonacci numbers (as lines of asterisks)":

```s``s``sii`ki `k.*``s``s`ks ``s`k`s`ks``s``s`ks``s`k`s`kr``s`k`sikk `k``s`ksk

I wanted to show a Hello world example of Brainf***, but I got this error:

Lameness filter encountered. Post aborted!
Reason: Please use fewer 'junk' characters.

Visit Esoteric Topics in Computer Programming, great stuff if you want to go mad.

You like Perl, so if you know Inline::C and Inline::CPR (if you don't, read Pathologically Polluting Perl by Brian Ingerson) you may enjoy understanding this code:

#!/usr/bin/cpr int main(void) { CPR_eval("use Inline (C => q{ char* greet() { return \"Hello world\"; } })"); printf("%s, I'm running under Perl version %s\n", CPR_eval("&greet"), CPR_eval("use Config; $Config{version}")); return 0; }

It's great, once you really understand it.

Are you up to date with Perl 6 development? It's going to be great and extremely powerful language. Read Larry Wall's Apocalypses and Damian Conway's Exegeses if you're interested:

Apocalypse 1: The Ugly, the Bad, and the Good (April 2, 2001)
Apocalypse 2: Fundamental data types, variables and the context and scoping of the language (May 3, 2001)
Exegesis 2 (May 15, 2001)
Apocalypse 3: Operators (October 2, 2001)
Exegesis 3 (October 3, 2001)
Apocalypse 4: Syntax (January 18, 2002)

It's my favorite language already, and it's not even fully designed yet.

Re:Yes, but... by Shiny+Metal+S. · 2002-02-17 19:48 · Score: 2 · on FSF Awards Guido van Rossum For Python

I'm saying that no linguist other than Larry Wall would think that Perl was anything vaguely similar to a natural language. Yes, natural languages are crufty and context sensitive and Perl is crufty and context sensitive. That doesn't mean Perl is like a natural language.

There's much more than only context sensitivity. But I see I won't convince you, for some reason.

I said "probably". As in "statistically". As in "that's what I've observed" and "heard many other people observe". If you've observed otherwise and we don't have the funds for a study I guess I'll have to leave it at that. No way to come to agreement. You can have the last word if you want it.

I commented your point as irrational, when you came to conclusion that my code is probably hard to maintain, because of fact, that there's more hard to maintain than easy to maintain Perl code out there (which is true of course). It doesn't make sense in the context of this thread and everything I was talking about. The whole long thread I talk about how I fix Perl code so it's more readable, faster, more maintainable, more clear, what are the most common mistakes of beginners, how I help them, etc. - which you conclude with:

But there is a price to be paid: and whoever has maintain your code is probaby paying it.

You shouldn't be surprised, that I call it irrational.

But it's not so important to me any more. You may however want to visit CPAN and search for such distributions as CGI.pm, DBI, DBD*, and the core Perl modules, and read them, to see lots of extremely well written Perl code. It's really worth reading.

Re:Yes, but... by Shiny+Metal+S. · 2002-02-17 19:48 · Score: 2 · on FSF Awards Guido van Rossum For Python

I'm saying that no linguist other than Larry Wall would think that Perl was anything vaguely similar to a natural language. Yes, natural languages are crufty and context sensitive and Perl is crufty and context sensitive. That doesn't mean Perl is like a natural language.

There's much more than only context sensitivity. But I see I won't convince you, for some reason.

I said "probably". As in "statistically". As in "that's what I've observed" and "heard many other people observe". If you've observed otherwise and we don't have the funds for a study I guess I'll have to leave it at that. No way to come to agreement. You can have the last word if you want it.

I commented your point as irrational, when you came to conclusion that my code is probably hard to maintain, because of fact, that there's more hard to maintain than easy to maintain Perl code out there (which is true of course). It doesn't make sense in the context of this thread and everything I was talking about. The whole long thread I talk about how I fix Perl code so it's more readable, faster, more maintainable, more clear, what are the most common mistakes of beginners, how I help them, etc. - which you conclude with:

But there is a price to be paid: and whoever has maintain your code is probaby paying it.

You shouldn't be surprised, that I call it irrational.

But it's not so important to me any more. You may however want to visit CPAN and search for such distributions as CGI.pm, DBI, DBD*, and the core Perl modules, and read them, to see lots of extremely well written Perl code. It's really worth reading.

Re:Yes, but... by Shiny+Metal+S. · 2002-02-17 19:48 · Score: 2 · on FSF Awards Guido van Rossum For Python

I'm saying that no linguist other than Larry Wall would think that Perl was anything vaguely similar to a natural language. Yes, natural languages are crufty and context sensitive and Perl is crufty and context sensitive. That doesn't mean Perl is like a natural language.

There's much more than only context sensitivity. But I see I won't convince you, for some reason.

I said "probably". As in "statistically". As in "that's what I've observed" and "heard many other people observe". If you've observed otherwise and we don't have the funds for a study I guess I'll have to leave it at that. No way to come to agreement. You can have the last word if you want it.

I commented your point as irrational, when you came to conclusion that my code is probably hard to maintain, because of fact, that there's more hard to maintain than easy to maintain Perl code out there (which is true of course). It doesn't make sense in the context of this thread and everything I was talking about. The whole long thread I talk about how I fix Perl code so it's more readable, faster, more maintainable, more clear, what are the most common mistakes of beginners, how I help them, etc. - which you conclude with:

But there is a price to be paid: and whoever has maintain your code is probaby paying it.

You shouldn't be surprised, that I call it irrational.

But it's not so important to me any more. You may however want to visit CPAN and search for such distributions as CGI.pm, DBI, DBD*, and the core Perl modules, and read them, to see lots of extremely well written Perl code. It's really worth reading.

Re:Yes, but... by Shiny+Metal+S. · 2002-02-17 19:48 · Score: 2 · on FSF Awards Guido van Rossum For Python

I'm saying that no linguist other than Larry Wall would think that Perl was anything vaguely similar to a natural language. Yes, natural languages are crufty and context sensitive and Perl is crufty and context sensitive. That doesn't mean Perl is like a natural language.

There's much more than only context sensitivity. But I see I won't convince you, for some reason.

I said "probably". As in "statistically". As in "that's what I've observed" and "heard many other people observe". If you've observed otherwise and we don't have the funds for a study I guess I'll have to leave it at that. No way to come to agreement. You can have the last word if you want it.

I commented your point as irrational, when you came to conclusion that my code is probably hard to maintain, because of fact, that there's more hard to maintain than easy to maintain Perl code out there (which is true of course). It doesn't make sense in the context of this thread and everything I was talking about. The whole long thread I talk about how I fix Perl code so it's more readable, faster, more maintainable, more clear, what are the most common mistakes of beginners, how I help them, etc. - which you conclude with:

But there is a price to be paid: and whoever has maintain your code is probaby paying it.

You shouldn't be surprised, that I call it irrational.

But it's not so important to me any more. You may however want to visit CPAN and search for such distributions as CGI.pm, DBI, DBD*, and the core Perl modules, and read them, to see lots of extremely well written Perl code. It's really worth reading.

Re:Yes, but... by Shiny+Metal+S. · 2002-02-17 19:48 · Score: 2 · on FSF Awards Guido van Rossum For Python

I'm saying that no linguist other than Larry Wall would think that Perl was anything vaguely similar to a natural language. Yes, natural languages are crufty and context sensitive and Perl is crufty and context sensitive. That doesn't mean Perl is like a natural language.

There's much more than only context sensitivity. But I see I won't convince you, for some reason.

I said "probably". As in "statistically". As in "that's what I've observed" and "heard many other people observe". If you've observed otherwise and we don't have the funds for a study I guess I'll have to leave it at that. No way to come to agreement. You can have the last word if you want it.

I commented your point as irrational, when you came to conclusion that my code is probably hard to maintain, because of fact, that there's more hard to maintain than easy to maintain Perl code out there (which is true of course). It doesn't make sense in the context of this thread and everything I was talking about. The whole long thread I talk about how I fix Perl code so it's more readable, faster, more maintainable, more clear, what are the most common mistakes of beginners, how I help them, etc. - which you conclude with:

But there is a price to be paid: and whoever has maintain your code is probaby paying it.

You shouldn't be surprised, that I call it irrational.

But it's not so important to me any more. You may however want to visit CPAN and search for such distributions as CGI.pm, DBI, DBD*, and the core Perl modules, and read them, to see lots of extremely well written Perl code. It's really worth reading.

Re:Yes, but... by Shiny+Metal+S. · 2002-02-17 19:48 · Score: 2 · on FSF Awards Guido van Rossum For Python

I'm saying that no linguist other than Larry Wall would think that Perl was anything vaguely similar to a natural language. Yes, natural languages are crufty and context sensitive and Perl is crufty and context sensitive. That doesn't mean Perl is like a natural language.

There's much more than only context sensitivity. But I see I won't convince you, for some reason.

I said "probably". As in "statistically". As in "that's what I've observed" and "heard many other people observe". If you've observed otherwise and we don't have the funds for a study I guess I'll have to leave it at that. No way to come to agreement. You can have the last word if you want it.

I commented your point as irrational, when you came to conclusion that my code is probably hard to maintain, because of fact, that there's more hard to maintain than easy to maintain Perl code out there (which is true of course). It doesn't make sense in the context of this thread and everything I was talking about. The whole long thread I talk about how I fix Perl code so it's more readable, faster, more maintainable, more clear, what are the most common mistakes of beginners, how I help them, etc. - which you conclude with:

But there is a price to be paid: and whoever has maintain your code is probaby paying it.

You shouldn't be surprised, that I call it irrational.

But it's not so important to me any more. You may however want to visit CPAN and search for such distributions as CGI.pm, DBI, DBD*, and the core Perl modules, and read them, to see lots of extremely well written Perl code. It's really worth reading.

Re:Let me call up some painful memories here... by Shiny+Metal+S. · 2002-02-17 13:32 · Score: 2 · on FSF Awards Guido van Rossum For Python

If you can't figure out the majority of what the programmer is getting at... There's more than one way to RE-do it.

I don't know what painful memories do you have with redoing something (do you know about CPAN?), but if you can't figure out the majority of what the programmer is getting at... There's a sign, that you need more education. Sad but true. This includes much more than only programming.

Perl OO with Encapsulation, and other comments by n1vux · 2002-02-12 10:07 · Score: 2, Informative · on What Makes a Powerful Programming Language?

Firstly, comparing the core standard of one language with the latest extensions of another is a very old troll, and older than the USENET; probably dates to the DARPA lists, if not before in the IEEE and ACM paper journals. (I was using this troll back when PL/I was cool.) Nothing, not even Perl or or it's blood-brother PL/I, can be all things to all people. I hope the list of needed features actually addresses the next project's needs, we can't judge that from here.

Secondly, Perl OO is conforming with Perl's TIMTOWTDI (There Is More Than One Way To Do It) design goal. While native Perl OO is pretty casual in its encapsulation, if you want Bondage-And-Discipline OO, you can use one of Damian's Class::Classes, with Contract programming or Data hiding enforcement or ... there are at least 6 choices. At least one should have multiple inheritance grafted on, although I can't recommend actually using multiple inheritance of implementation (except maybe in CLOS); multiple inheritance of interface (like in Java or COM) seems safe enough.

Likewise, anything else Perl is missing can be added via other modules -- many of which probably already exist, but can be custom crafted on demand. This includes Operator Overloading, which can be added, for whatever cases are required, using Inline::Filter -- using the full power of Perl as a macro-language for Perl, to enhance the syntax as desired. Not for the faint of heart, but a good Perl consultant can whip it up for you.

GUI's -- Yes, it is true development of GUI's isn't built into Perl, unless you count the TCL modules as "built in". Ability to do GUIs does seem to run counter to portability (at compile time, whenever that is); this requirement may force your choice on Java. Perl has Gnome, TK/GTK, and Curses interfaces already. See CPAN

Thirdly, Perl6 will likely be mostly functional before .NET this summer, and _will_ be all things to all people, thanks to the modular bolt-on accessories. (Operator overloading will apparently be a part of the PARROT runtime for Perl 6, as well as in Perl6.)

Fourthly, Reality Context: Did The Boss specify that you had to be able to hire programmers in this language? Cheap or expensive? With lots of experience or not? Here or offshore? Eiffel's a great language, if you don't mind all your staff speaking French.

Regarding the evils of Lisp ... see the story of Yahoo!Stores Paul Graham: Beating the Averages or /. #1539239 for a real world $ucce$$ story with Lisp and why; amusingly, he turned up just last week /. #1917202.

-- Bill

I had a sigfile ... back when sigfiles were cool

Quantum::Superpositions by ilkahn · 2002-02-09 13:11 · Score: 5, Interesting · on Quantum Programming with Perl

Anyone interested in doing any type of quantum computing should check out Dr. Damian Conway's excellent Quantum::Superpositions. It is an extension to the perl language which adds the operators "any" and "all"... it's lets you do *incredible* things like:

use Quantum::Superpositions;

if ($x == any($a, $b, $c)) { ... }

while ($nextval < all(@thresholds)) { ... }

$max = any(@value) < all(@values);

A good place to go and discuss the in's and out's of the cooler aspects of the perl community is perlmonks.org, check it out some time...

Re:There are many more esoteric programming langua by Shiny+Metal+S. · 2002-02-04 12:43 · Score: 1 · on A Warrior's Programming Language

I've also kicked around the idea of a programming language based on Latin based on Chris' thoughts on using inflection in a programming language, but it's not one of those things that seems to come together easily...

Take a look at Damian Conway's Perl module named Lingua::Romana::Perligata.

From the README:

NOMEN
Lingua::Romana::Perligata -- Perl in Latin
DESCRIPTIO
The Lingua::Romana::Perligata makes it possible to write Perl programs in Latin. (If you have to ask "Why?", then the answer probably won't make any sense to you either.)
The linguistic principles behind Perligata are described in:
http://www.csse.monash.edu.au/~damian/papers/HTML/ Perligata.html
The module is `use'd at the start of the program, and installs a filter which allows the rest of the program to be written in (modified) Latin, as described in the accompanying documentation.
(...)

Re:There are many more esoteric programming langua by Shiny+Metal+S. · 2002-02-04 12:43 · Score: 1 · on A Warrior's Programming Language

I've also kicked around the idea of a programming language based on Latin based on Chris' thoughts on using inflection in a programming language, but it's not one of those things that seems to come together easily...

Take a look at Damian Conway's Perl module named Lingua::Romana::Perligata.

From the README:

NOMEN
Lingua::Romana::Perligata -- Perl in Latin
DESCRIPTIO
The Lingua::Romana::Perligata makes it possible to write Perl programs in Latin. (If you have to ask "Why?", then the answer probably won't make any sense to you either.)
The linguistic principles behind Perligata are described in:
http://www.csse.monash.edu.au/~damian/papers/HTML/ Perligata.html
The module is `use'd at the start of the program, and installs a filter which allows the rest of the program to be written in (modified) Latin, as described in the accompanying documentation.
(...)

Re:var'aq by pne · 2002-02-04 03:03 · Score: 3, Informative · on A Warrior's Programming Language

Anyhow, the interesting thing about var'aq is that because it runs on Perl, it's pretty ubiquitous meaning that if you really hate your job and feel the need for revenge, just go rewrite the production administration scripts in var'aq and then quit.

You can get a similar effect by translating your scripts to use a source filter such as Lingua::Romana::Perligata or the newer Lingua::Sinica::PerlYuYan. Read Perl in the original Latin or Middle Chinese!

Re:var'aq by pne · 2002-02-04 03:03 · Score: 3, Informative · on A Warrior's Programming Language

Anyhow, the interesting thing about var'aq is that because it runs on Perl, it's pretty ubiquitous meaning that if you really hate your job and feel the need for revenge, just go rewrite the production administration scripts in var'aq and then quit.

You can get a similar effect by translating your scripts to use a source filter such as Lingua::Romana::Perligata or the newer Lingua::Sinica::PerlYuYan. Read Perl in the original Latin or Middle Chinese!

Re:Why a scripting language? by scottcain · 2002-01-29 05:10 · Score: 2, Informative · on Beginning Perl for Bioinformatics

It's easy to explain really: text manipulation. Bioinformatics is really about moving text around. What are DNA and protein sequences? Text. What are the reports generated by the plethora of analysis programs? Text. And Perl has outstanding and easy to use text manipulation tools. Add to that CPAN and BioPerl, and you have the makings of excellent Bioinformatics tools.

Perl Bioinformatics for AI Neuroscience by Mentifex · 2002-01-29 03:54 · Score: 2, Offtopic · on Beginning Perl for Bioinformatics

Anyone who wanders into the use of Perl for bioinformatics ought to consider the ultimate plunge into the use of Perl for neuroscientific Artificial Intelligence. Since v.t.y. Mentifex here has been coding the AI Brain-Mind in JavaScript for tutorial purposes and also in Forth for Intelligent Mind Roboinformatics, the switch-over to Perl is advancing so slowly that I must first promulgate some candidate AI module proposals for inclusion among the object-oriented Perl 5 Module List.

The Comprehensive Perl Archive Network (CPAN) contains some not-yet-implemented, suggested AI module namespaces for those who read the Beginning Perl book reviewed here on SlashDot and who may then wish to do some really exciting, wave-of-the-future Perl neuroscience theory and practice work.

Perl Bioinformatics for AI Neuroscience by Mentifex · 2002-01-29 03:54 · Score: 2, Offtopic · on Beginning Perl for Bioinformatics

Anyone who wanders into the use of Perl for bioinformatics ought to consider the ultimate plunge into the use of Perl for neuroscientific Artificial Intelligence. Since v.t.y. Mentifex here has been coding the AI Brain-Mind in JavaScript for tutorial purposes and also in Forth for Intelligent Mind Roboinformatics, the switch-over to Perl is advancing so slowly that I must first promulgate some candidate AI module proposals for inclusion among the object-oriented Perl 5 Module List.

The Comprehensive Perl Archive Network (CPAN) contains some not-yet-implemented, suggested AI module namespaces for those who read the Beginning Perl book reviewed here on SlashDot and who may then wish to do some really exciting, wave-of-the-future Perl neuroscience theory and practice work.

Re:what is the real life application to this? by Yakko · 2002-01-17 11:28 · Score: 2, Informative · on CompactFlash / IDE Interface for Apple II

my question is , is there an easy way to access the filesystem other than on an apple?

It's off the top of my head, but I believe that AppleII::ProDOS can do this from Perl... it'd be a fun project for me some weekend, as my perl-fu needs work.

Not exactly easy, since you do have to write an app, but there're tools out there.

One word: perldap by Linux_ho · 2002-01-08 07:47 · Score: 2 · on LDAP Tools - Where are they?

Check out the LDAP module at CPAN. 'Course, if you don't already know Perl it will take you an hour or so to learn it, but I think you will find it to be the most flexible and powerful LDAP tool available.

Generic LDAP Tools by Hackysack · 2002-01-08 06:40 · Score: 1 · on LDAP Tools - Where are they?

I used to work alot with LDAP, my job function has changed since then so I'm not as upto date as I'd like to be.

I ran up against the same problem, using LDAP for a dropin replacement for most authentication systems (PAM, etc) isn't very practical since there are almost NO tools available for management.

The problem is the lack of defined specifications for what objects in LDAP have what attributes. CompanyA might want certain things in a user object, CompanyB might want other elements there.

It's good and bad. The scalability and flexibility is that there are few specifications, the downside is that there are no tools because of this.

I ended up writing a web based admin application in perl which did add/delete/update. I can't post it since it's not mine to post. It's not hard to write however.

Net::LDAP, DBI:LDAP, and LDAP::API are all good perl modules for manipulating OO databases via LDAP. I used LDAP::API, since it was the only one available at the time.