comments on JAPH?

T

Thomas Kratz

Hi,

below my first attempt for a JAPH. It's not that obfuscated, but I had
a tough time pressing it into 4 lines.

Comments anyone?

Thomas
 
L

LaDainian Tomlinson

Thomas Kratz said:
Comments anyone?

Sure.

http://www.perlmonks.com/index.pl?node=Obfuscated Code

You might get more response over there. This newsgroup is leans more toward
problem solving than Perl's silly side.

Brandan L.
--
$_=q$,197+,27S,137,08(),09-K,13,11%1332230!b#>:!+'t{$;srand$=;sub'x{$$$x+=po
p}$
qw=sub{$q++;$i[pop@a]=pop};unshift@a,x$_
for(map{reverse+split$,}/(\d*)!/g);&{$
qw}($+)while(s=,}?(\d{2})==x);$t=y*3012**d?reverse+split$i[@i]:die$_;@f=map$
i[$
_]?chr$i[$_]:chop$t,0..--$q+length;print+chr(int(rand(58)+65)^ord)for@f,m$JA
PH$
 
L

LaDainian Tomlinson

LaDainian Tomlinson said:
--
$_=q$,197+,27S,137,08(),09-K,13,11%1332230!b#>:!+'t{$;srand$=;sub'x{$$$x+=po
p}$
qw=sub{$q++;$i[pop@a]=pop};unshift@a,x$_
for(map{reverse+split$,}/(\d*)!/g);&{$
qw}($+)while(s=,}?(\d{2})==x);$t=y*3012**d?reverse+split$i[@i]:die$_;@f=map$
_]?chr$i[$_]:chop$t,0..--$q+length;print+chr(int(rand(58)+65)^ord)for@f,m$JA
PH$

I think it's time for a decent newsreader.

Brandan L.
 
M

Michele Dondi

below my first attempt for a JAPH. It's not that obfuscated, but I had
a tough time pressing it into 4 lines.

Comments anyone?

My first comments, modulo the fact that I didn't even try (yet) to
understand what it does due to absymal lack of time, are:

(i) it doesn't work, for the following meaning of "doesn't work": it
prints "J" and then exits!

(ii) I see the following piece of code:

open STDIN,"<&DATA";# rest of line snipped

and that there's an __END__ token. Isn't it that you're maybe trying
to do something like '*ARGV=DATA'?


Michele
 
T

Thomas Kratz

Michele said:
My first comments, modulo the fact that I didn't even try (yet) to
understand what it does due to absymal lack of time, are:

(i) it doesn't work, for the following meaning of "doesn't work": it
prints "J" and then exits!

That's because you are on Win* are you? It will work when you
change the 14 in the first line to 15.
To have this working on all platforms I'll have to find out how many bytes
are written for a newline. length("\n") will always return 1 for all
platforms.
(ii) I see the following piece of code:

open STDIN,"<&DATA";# rest of line snipped

and that there's an __END__ token. Isn't it that you're maybe trying
to do something like '*ARGV=DATA'?

More like '*STDIN=DATA'. It is just to be able to say getc instead of
getc(DATA).

Using ARGV would be an alternative (and the above problem would vanish).
I just found out that you can't paste the lines via STDIN (always tested
with a file :-( ). The DATA filehandle seems to be missing. I have to look
that up.

Thomas
 
A

Anno Siegel

Thomas Kratz said:
2. I just realized (never thought about it before), that when you paste
the code to the perl interpreter via STDIN, you won't get anything from
the DATA filehandle. ...

Have you tried it?

Anno
 
T

Thomas Kratz

Anno said:
Have you tried it?

Yes, although only with 5.6.0 and 5.8.0 under Win32. Does it behave
differently on other OSes?

I tried it with:

seek DATA,0,0;
print <DATA>;
__END__

prints '>><<' if pasted and

'>>seek DATA,0,0;
print '>>', <DATA>, '<<';
__END__
<<'

if run from a file

Thomas
 
M

Michele Dondi

Ok I'll try to be clearer.

1. I am moving through the comment on the right side of the JAPH with
'seek' and 'getc'. Therefore I need to know how many bytes the line
endings consist of, to get the right offset. Just pulling everything into
an array and parsing that would be easier.

2. I just realized (never thought about it before), that when you paste
the code to the perl interpreter via STDIN, you won't get anything from
the DATA filehandle. I don't know if and - if yes - how I can get at the
code when it comes in via STDIN.

Better?

Definitely!

However, in Perl one seldom (say in "everiday's life quick scripts")
*really* needs getc() IMHO. And OTOH Perl's (more) common I/O
operators/functions manage line endings (and not only!) transparently
and platform-independently.

May you consider using something other than getc()? Also, why not
chomp()ing? Note: I deleted your code because I do not even want to be
tempted to try and see if these suggestions are compatible with its
logic! :) (not much spare time, sorry!)


Michele
 
B

Ben Morrow

Thomas Kratz said:
I tried it with:

seek DATA,0,0;
print <DATA>;
__END__

prints '>><<' if pasted and

This is because pipes (and ttys, and whatever a command window behaves
as under Win32) are not seekable.

Ben
 
A

Anno Siegel

Thomas Kratz said:
Yes, although only with 5.6.0 and 5.8.0 under Win32. Does it behave
differently on other OSes?

I tried it with:

seek DATA,0,0;
print <DATA>;
__END__

Uh, okay, apologies. I thought you were saying the DATA filehandle doesn't
work when STDIN is piped. Of course "seek DATA" must fail when the source
isn't seekable, for whatever reason.

Anno
 
T

Thomas Kratz

Michele Dondi wrote:

May you consider using something other than getc()? Also, why not
chomp()ing? Note: I deleted your code because I do not even want to be
tempted to try and see if these suggestions are compatible with its
logic! :) (not much spare time, sorry!)

As I wrote before: I am considering giving up using getc unless there is a
foolproof method for knowing the actual line length. Shouldn't be too
difficult. I'll play with it as soon as I have the time to.

Thomas
 
J

Jay Tilton

: Michele Dondi wrote:
:
: >
: > My first comments, modulo the fact that I didn't even try (yet) to
: > understand what it does due to absymal lack of time, are:
: >
: > (i) it doesn't work, for the following meaning of "doesn't work": it
: > prints "J" and then exits!
:
: That's because you are on Win* are you? It will work when you
: change the 14 in the first line to 15.

Alternatively, you could tighten up the algorithm so there's room for code
to detect when it's running in Windows and adjust itself.

$r=$^O=~/MSWin32/?75:74;open STDIN,"<&DATA";{ #J~.> a>n~>>e~.......>r.
seek STDIN,$i||=50,0;$_=getc;/\./&&last;/\w| / #.u.t.^..oP..r.>h>a~.e..
&&print;$i+=($d=/~/?$r:/\^/?-$r:/>/?1:/</?-1:$d #.>s^~h<t< ..~. ...c.^..
?$d:1);redo}__END__ #....>>e>r^..>l^...>k^..

Or, more ambitiously, add path corrections to the befunge-like data that
will steer the "program address" back on course when run under Windows.
 
T

Thomas Kratz

Jay said:
: That's because you are on Win* are you? It will work when you
: change the 14 in the first line to 15.

Alternatively, you could tighten up the algorithm so there's room for code
to detect when it's running in Windows and adjust itself.

$r=$^O=~/MSWin32/?75:74;open STDIN,"<&DATA";{ #J~.> a>n~>>e~.......>r.
seek STDIN,$i||=50,0;$_=getc;/\./&&last;/\w| / #.u.t.^..oP..r.>h>a~.e..
&&print;$i+=($d=/~/?$r:/\^/?-$r:/>/?1:/</?-1:$d #.>s^~h<t< ..~. ...c.^..
?$d:1);redo}__END__ #....>>e>r^..>l^...>k^..

That looks at least more elegant than my code ;-) I have to look at what
it is doing as soon as I get the time.
Or, more ambitiously, add path corrections to the befunge-like data that
will steer the "program address" back on course when run under Windows.

Yes that would be cool. Less cool but effective would be counting the
bytes between the first 2 "#"s for the length of a line. Or - as I said in
another post - stop using seek altogether and read the lines into an array.

Thanks to all for the comments
Thomas
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top