The Perl Short Questions Megathread: executable line noise

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Perl Short Questions Megathread: executable line noise

«‹›6 »

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Ahh, welcome home, brothers.

Just wanna throw it out there that I love Perl and work at a Perl shop in NYC, so if anyone needs job, holla back.

syphon^2, two awesome concepts that are not-exclusive to Perl but good launching points from where you are are functional programming and object-oriented programming.

The first part to functional programming is understanding the concept of an anonymous block/function, and seeing how it can be passed around like a value. If you understand how custom sorts, or how map and grep work, you're well on your way for basic, practical, Perl-wise functional programming. For future reference, the greater launch off point from there would be to read HOP (Higher Order Perl), but that's pretty intense, I don't grok all of it myself.

The other one, OOP... I think a lot of formal OOP fans will point out that Perl's current implementation of OOP is kinda... Not good. But! Don't let that stop you from learning the basics. A Perl object is kinda like a basic data primitive (usually a hash) that has a special name and has functions attached to it called methods.

It's pretty awesome. I've never done OOP until my first corporate job, so I can understand your hesitation in learning. Just... Get out there and do something. Anything! Rolling your own content management system seems to be a pretty full goal, if you want.

# ¿ Oct 25, 2007 04:27

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 07:56

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Z-Bo posted:

Have any Perl folks read the book Perl Medic? If so, I was wondering what you thought of it. I read a book review for Perl Medic at TechBookReviews and they claimed it was "highly recommended".

I have it and I wasn't impressed. I have a fairly good grasp of software (I think?) and how unit tests work...

But you know what I think the book is good for? Collating that stuff into one place so that someone who didn't know about any of it would have a really broad understanding. So, it wasn't as in depth as I personally would have liked, but I think it did a good job introducing some concepts and strategies for otherwise daunting tasks.

It comes up short in some places, where you'd like to know more, but as far as I can tell, people are very all or nothing with unit tests, so if you're from the nothing camp, then this book is an okay have. I'd suggest reading it at a bookstore to see how much value it can provide to you. I don't regret purchasing it, but I wish there was more to it.

# ¿ Oct 25, 2007 22:49

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Could you add PerlMonks to the OP, please? If the reader is willing to take the time to form well-worded questions (as they do here), the community loves to give back and help people learn more about Perl.

# ¿ Oct 26, 2007 03:09

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

1) How do you feel about Perl6? I saw a Google Video of Audrey's talk to a Japanese audience and it was pretty amazing. It was a really good presentation and I'm absolutely sold on Perl6. I'm a believer! I think if I knew more about what was required to contribute, I would. But I won't speak Haskellese or whatever.

2) What experience do you have with code coverage? James Keenan at perl seminar ny presented about it and it seemed pretty interesting. I honestly thought unit testing was the end all be all of how to pimp out your code, but code coverage testing seems to be a second tier above that. Very interesting.

# ¿ Oct 26, 2007 15:27

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I have this new coding style I've adopted, and personally, I like it. But I'm pretty sure no one else is keen on it. What do you guys think?

I don't know if this illustrates it enough, but it's tucking a whole set of temporary variables inside the scope of a do-block, where the last line/return value of the do block is what we actually want.

The reason I did this is because sometimes, to fetch the data we want, we have to go through these multi-phase transforms of data. I feel like all the temporary variables we use pollute the namespace. Like, certain structures aren't used for anything but the derivation of the last data structure. So I figured, why not tuck it into one temporary scope.

It's kinda like... An unwound subroutine.

code:

sub old_way {
  my $self = shift;

  my @resources = Global::get_resources();
  my $filter = $self->getFilter;

  my $boolean = grep { $_ eq $filter } @resources;

  return $boolean;
}

sub new_way {
  my $self = shift;

  my $boolean = do {
    my @resources = Global::get_resources();
    my $filter = $self->getFilter;

    grep { $_ eq $filter } @resources;
  };

  return $boolean;
}

# ¿ Oct 30, 2007 18:46

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I don't think you can save the value of an anonymous block, hence the do part. And, how would you differentiate it from an anonymous hash? I can't even come up with a compilable example without a do.

# ¿ Oct 30, 2007 19:40

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Twlight posted:

I have a large file that has strings that I would like to extract into a new file, I know I have to use regex but I'm unsure as to How I should format it. I want to save all words that have WS-xxxxx where xxxx is a name everything else in the file I don't care about. Any Ideas?

Well, what you're saving in the ideal Perl world would probably become an array. How that is serialized is completely up to you and shouldn't matter. You could freeze/thaw the entire structure (overkill). The simplest way to go about it would be to have each item be a line in a text file.

There's also YAML, tie'ing that array/file...

# ¿ Oct 30, 2007 20:04

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Twlight, I would break down the code into phases, platonic ideal first, storage second. The point is, you want your two idioms in two seperate paragraphs and not bound so tightly together.

floWenoL, I don't think do-block supports return, only subroutines.

code:

# untested

# phase one, capture
my @wanted_values = do {
  open DATA, "pso.txt";
  my $file = do { local $/; <DATA> };
  close DATA;

  ($file =~ /expr/g);
};

# phase two, storage
freeze @wanted_values, "wanted.txt"; # or whatever

# or...
open STORAGE, "saved.txt";
print STORAGE join "\n", @wanted_values;
close STORAGE;

# or...
YAML::out(\@wanted_values, "wanted.txt"); # or whatever

# ¿ Oct 30, 2007 20:38

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

tef posted:

Does it make the code simpler?
Does it make the code more general?
Does it make the code clearer?

Yours doesn't make the code simpler, or clearer.

That's funny, I think it does satisfy all of those points.

1) It makes it apparent that an assignment is dependent on that paragraph of code and nothing else.
2) That paragraph is a matter of implementation, like a method. How it's done shouldn't be of concern, other than that it is done.
3) It's clear that the variables introduced into that scope are destroyed as the assignment ends, reducing the confusion as to whether or not a top level variable is used later on.

I adopted this particular coding style out of frustration of maintaining other people's code, where a variable introduced near the top of a subroutine may or may not have been used at all in the subroutine itself. I feel like my style says, "this definitely is in use right now by this other variable" instead of "well we're predeclaring something, but I'm going to leave it up to you to figure out whether or not its useful!".

# ¿ Oct 30, 2007 21:26

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

IcePotato posted:

edit: gently caress I FORGOT TO USE \S INSTEAD OF S

So, problem solved? On the aside, something about your Perl doesn't jive with me... It might be something completely superficial like "I didn't write it". Do you have any inputs I could run it against?

# ¿ Nov 9, 2007 19:06

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Let's say I have a super class and a program that's supposed to handle N sub classes of that... Is there a way to load all of those based on their existance on the file system, and not hard code use statements somewhere?

Super class Fruit. Sub classes Apple, Orange, Strawberry, and whatever else I happen to include on the file system...

# ¿ Nov 13, 2007 21:12

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Wow, that was fast. How about to determine if a module is already used?

# ¿ Nov 13, 2007 21:32

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

What are my alternatives for the following?

code:

sub getMessage {
        my $self = shift;

        eval('$' . ref($self) . '::message');
}

This is a method off of the base class, whose mechanism never changes, but the source of the data does, it's class data, not instance data. What's a better way of writing this?

# ¿ Nov 14, 2007 20:19

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Uhh, what? That sounds way too confusing.

The HTTP request would just be a touch and go on the server to start the process. Subsequent HTTP requests via Ajax would hit a process that's in charge of monitoring the status of the first, longer running process. And... that's it. There's no forking anywhere in this design.

# ¿ Nov 16, 2007 22:34

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

code:

use warnings FATAL => 'all';
warn "hello";
print "doof";

Is the function warn supposed to throw a fatal exception there and prevent the display of "doof" (it prints when I run it), or is the fatality given by use warnings only apply to warnings::warns?

# ¿ Dec 5, 2007 23:10

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I'm sorry I don't know how to answer your question, but if you would like a roadmap of using Perl in web development in terms of making yourself more marketable to Perl jobs, I could suggest stuff for that.

1) mod_perl. To this day I'm still not sure what it does in that I haven't done anything with it myself.

2) Frameworks. I guess Catalyst would be a good choice.

3) Templating engines. Mason is pretty popular.

Looking up documentation for these might help you with your original question, since they're all interrelated.

# ¿ Dec 6, 2007 14:40

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

That's a great start. And for learning, CGI is a good place to be. But keep in mind that as you become a more experienced developer, you will begin to look at CGI.pm and be like... Wow, why did anyone write this.

Again, for where you are now, it's appropriate. Down the road, it will become less and less useful and more wtf.

# ¿ Dec 6, 2007 22:00

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I'm inheriting this Perl script at work that's just so :psyduck:

overwhelming every time I look at it. It really was written in a different era and just lacks any sort of modern idioms. It currently runs in production on Windows and I'm tasked with making it run on Linux. I would run-crash-edit run-crash-edit this until my eyes bleed except for the fact that it works with sensitive data and writes out to a production area. Essentially, there's no test environment set up and/or running it had side effects.

So I see two ways of attacking this. One, rewrite it from scratch, using the existing script as a spec. Two, check in the existing script and start pairing it down by refactoring idioms into it and deleting unnecessary code.

Thoughts? I'm just aggravated there's no sexy way to do this.

Edit: I've decided on using both approaches. I will write the script from the ground up, but I will also check in a dummy copy of the Windows script and start paring it down.

Triple Tech fucked around with this message at 23:24 on Dec 6, 2007

# ¿ Dec 6, 2007 22:54

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

mister_gosh posted:

If someone CTRL-C's this script, nothing gets put in to C:/example.txt. Is there a way to ensure it closes properly or a better way of doing this?

Edit: thinking about this some more, is there a way to do something like if a user does CTRL-C or if there is an abrupt end or big error, can the program say "on exit, close this file handle?"

Two things. One, it sounds like what you're asking for is to output to a file as soon as possible. That is achieved by the following:

code:

$|++;

I'm fully aware that it looks crazy, but that's the way most Perl programmers write it. It sets the output autoflush variable to true. That means every time something gets sent to a filehandle, it will definitely show up. I don't think a handle needs to be closed to be written to this way, that's what I'm banking on.

The other thing is how to clean up a mess when you've been interrupted. You get around that with a signal handler. I believe the Ctrl-C signal is SIGINT. You override that handler with your code and it will be run every time someone interrupts your program. But that's probably not what you want to do here.

# ¿ Dec 7, 2007 14:35

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I vaguely remember reading this in Perl Hacks or some such, but would it be good to focus on coding a type of Perl that didn't generate as many ops as say another method?

code:

my $a = "something";

# method 1, assignment
my $b = $a;

# method 2, stringify, assignment (more ops)
my $b = "$a";

Are less ops always faster than more?

# ¿ Dec 7, 2007 16:09

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Subotai posted:

Why would you ever want to increment [autoflush] instead of setting it to 1? Unless you are sharing it across threads or something and it is being used in the same manner a semaphore or something weird like that, you should just set it to 1.

Autoflush is just autoflush and it shouldn't be used for anything else (except maybe golfing and obfu). And it's written that way because that's just the way Perl people are.

code:

$| = 1; # too long
$|++;   # winnah

I guess I could make up a couple reasons. Well, it's shorter. Perl people love their terse. It's ... traditional, sort of. Also, it's not really an assignment. I'm not saying that the auto flush concept is "incrementable" but it doesn't really support arbitrary assignment, so the equals sign may be implying too much. Whatever, they're both equally bad, but one is less bad than the other.

Edit: Reviewing some posts in Perl Monks, I see that both are written, one not any less right than the other. But I would put my money on the ++ version being used more.

# ¿ Dec 7, 2007 18:33

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Sartak posted:

Nope. $| is deeply magical.

What? I thought any non-zero value is funneled to 1 and all in/decrement operators work as expected (on either the numbers one or zero). I don't see any reason why the implementors would go out of their way to provide a different implementation to decrement.

# ¿ Dec 7, 2007 22:46

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

So, what did everyone think about the latest State of the Onion?

I'm still a believer...

# ¿ Dec 8, 2007 19:26

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Ninja Rope posted:

Edit: A language reaches perfection when there is nothing left to take away, not when there is nothing left to add (similar to RFC1925). For that reason I'm a little worried about Perl6...

I don't understand what you're trying to say with this. By your logic, a stream of ones and zeros is perfect, because there's nothing left to take away. But that doesn't mean it's good for programming. Similarly, just because Perl 5 is pretty good on its own now doesn't mean it is immune from things to which it is insufficient in the future, like multi-methods and concurrency.

# ¿ Dec 9, 2007 05:33

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Ninja Rope posted:

is that really worth it?

Is it ever really worth it? Think about what programming languages have done since their inception; take more away so that we can do more. Programming languages will get higher and higher and enable us to see things that lower level languages haven't yet seen. I'm not saying higher level languages are a complete successor and substitute to lower level languages, but it helps keep your eye on what's really important: the work being done.

code:

# winnah
say for @items;

# sad panda
print "$_\n" for @items;

That's a trivial example. But you could ask if any of the features Perl6 is providing is worth it. I think they are, no matter what it is. If it brings us to a level where we can have an easier time discussing problems that were more complex today, I say go for it.

I never got why people are so opposed to Perl's way of handling things in all forms possible. No one is saying you can't do things a certain way. In fact, it's enabling the person do the work in whatever style they want. Of course people will then say oh it's hard to use someone else's code... Well, whatever. Work it out then. Talk about good practices. Or learn more about how different Perl looks.

Perl6 won't be perfect and it won't be for everyone... But I think it's the only language, that I know of (don't know many) that's really pushing the boundaries of making us more productive by providing use many, many tools. It isn't burdened by philosophical purity to the point of being unable to express a concept. Like if a language was completely void of multiple ways of saying things, I think it would just be a verbose mess.

And then verbosity gets into how people think in terms of chunks and lines of code, despite what language they're in... Terseness rules, Perl wins.

# ¿ Dec 9, 2007 06:09

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I'm not saying that Perl is the end-all-be-all of terseness and that terseness is the One True Dimension by which one judges code. Of course not, that's silly. But how I feel could be best expressed by reading this article by Paul Graham Yes, I have drank the cool-aid and I hope that's the right article...

It says (or should say) that the amount of effort a programmer puts towards programming N lines of code is constant, regardless of what programming language he uses. So, if you have a more verbose language, (Java) you will produce 1000 of code that only implements let's say one feature. But using a scripting language or something more flexible and possibly terse, you can produce 1000 lines of scripting that would implement three or four features. You're more productive that way.

Can you skew this test by jamming everything on one-line? No, I dont think you can. If you change the word from line to chunk, like a psychological chunk of thought, it makes more sense that way. People don't code in lines, they code in thoughts. It's like writing an essay. One run-on sentence doesn't help make your point any more clear. If Perl or some other agile language let's you encapsulate more and say more with less words, then you're more productive in it. I think this is a big win, because it helps me get real work done and that's what I'm all about.

And given your example in Python, I bet for fleshing out OOP concepts, Python would beat the pants off of Perl any day.

So I'm all for adding any feature that makes expressing certain concepts easier. Theoretically, you could run this into the ground and be like, well I made a language that's one character long ("1") and it is an accounts billing system! Well that's fantastic, that's the most productive accounts billing system programming language ever! But it's not flexible enough to be carried across different domains. So there's the key. What is it that you can add to a programming language to say less, but still remain flexible.

# ¿ Dec 9, 2007 15:27

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

vozz posted:

Why doesn't this work?

Why doesn't what work? What is your code supposed to do, anyway? Are you getting error messages? :confused:

code:

my @dict = ('A' .. 'Z', 'a' .. 'z');

Also, if you're never redifining your dictionary, it should be a global.

# ¿ Dec 10, 2007 19:29

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Kakesu posted:

directory mania!

For starters, don't make shell calls if there are CPAN modules available to do the same thing. There should definitely be an ActiveState-approved module that creates file paths...

Two, the system function accepts arrays! The first argument to the function is the command you want to run and subsequent arguments are arguments to the command, properly and automatically escaped by Perl.

So, you should try to write out your system call (which you shouldn't be using) like this:

code:

system('mkdir', $dirname);

And you can test if you have the correct number of slashes by just printing $dirname to STDOUT. That or just use forward slashes (no escaping necessary).

# ¿ Dec 11, 2007 22:31

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

You should try a one-liner first, like

code:

my @a = glob('*.pl'); print "@a";

If that doesn't work, well, then you're boned.

# ¿ Dec 17, 2007 20:17

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I'm trying to look up more about it, but off the top of my head, I can't help but think that there's something wrong with your perl. What version are you using? And what OS are you running?

You could reimplement the glob concept by just using readdir.

Edit: I think older versions of Perl outsource their globbing to the shell. So if there's something wacky about the environment you're running, that might be it.

# ¿ Dec 17, 2007 20:40

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Are you sure you're in the right directory? Is the one-liner still giving you problems?

# ¿ Dec 17, 2007 21:10

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

When you golf like that, it gives non-Perlers a negative impression of the language...

Golf away!!! :patriot:

Edit: Everyone rejoice! Perl 5.10 is out! Here is the delta. Sounds pretty neat to me.

Triple Tech fucked around with this message at 15:43 on Dec 19, 2007

# ¿ Dec 18, 2007 19:31

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

I don't understand, is something not working for you? Do you not know how to capture user input? Is it not running?!

# ¿ Dec 20, 2007 18:55

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Twlight posted:

oh I wasnt sure that it would take a file name as input for the copy command! sorry!

Yes, it takes a filename as the second argument... :confused:

code:

copy $original_file, $destination;

Didn't you read the POD? :cry:

# ¿ Dec 20, 2007 19:00

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

All things in software are possible... :pseudo:

If you can promise that everything is split up by lines nicely, you can just loop through each line in the file, analyze where you want to stop, inject your new stuff, and then keep printing.

A better, "more right", more complicated way would be to have a script interpret and parse the entire conf file, modify the Perl object that represents it, and then serialize it again... That would be the most flawless way.

# ¿ Dec 20, 2007 22:23

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Twlight posted:

I want to inject a return at the second to last }; and add my input so I would dump the contents of the file into an array, then I get lost

Right, so you load up the original conf file and you loop through all of the lines. You analyze a line and decide what to do with it. If do nothing, then just tack it back on to a buffer (another scalar). You're essentially reconstructing the file.

At some point, your testing mechanism will pass, telling you that you're at that particular point in the file. Before you push the original content back to the scalar buffer, you inject your content by pushing it on first. Then push the original.

Now you have a new file represented in Perl-space. Close the file for reading, then reopen it for writing, write out your buffer, and blamo, original file + injection complete.

# ¿ Dec 20, 2007 22:55

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Aren't your in and out file the same? If so, you would need to open, and then close. If not I guess your way with two filehandles is the same.

code:

my $buffer;
open CONF, $conf_file;
while (my $line = <CONF>) {
  if (/};/) {
    $buffer .= EOZ;
  zone "danger_zone" in {
    type master;
    file "danger_zone.txt";
  }; 
EOZ
  }

  # occurs unconditionally
  $buffer .= $line;
}
close CONF;

open CONF ">$conf_file";
print CONF $buffer;
close CONF;

# ¿ Dec 20, 2007 23:12

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

ashgromnies posted:

What don't you understand exactly? The perldoc is pretty explanatory...

To someone that doesn't know Perl that well or knows it to varying degrees, perldoc isn't some godlike, infallible tutorial on all things...

Besides, this module just spits out events as it parses a file. I don't see how this is at all relevant to the original problem of modifying the config by injecting another paragraph.

...unless you want to use the stream of events to detect and reconstruct parts of the object, and then inject things that way... Which I wouldn't be infavor of because that just sounds so indirect, compared to my way. :colbert:

# ¿ Dec 21, 2007 21:32

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

Did you ever hear anyone say "design your modules like you would release them on CPAN"? Is there any part of that advice that's negative?

I've also been thinking of creating another movement... All the companies I've been at store their utility functions (example, for text munging) in Company::Utility::Text. And it's started to bother me. Why not design it like you'd really release it on CPAN, so it goes under Text::Something. I guess that ties into the first question... Like, I want to keep real business logic seperate from fake business logic. Is that so bad?

Although I do see the argument of "well, it's a module we developed internally, so we have to put it in our own namespace". True, but sometimes you create things that aren't really proprietary, or could easily be shared with the world.

# ¿ Jan 3, 2008 23:38

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 07:56

Triple Tech: Jul 28, 2006; So what, are you quitting to join Homo Explosion?

ashgromnies posted:

Plus it keeps knowledge sharing a little easier - if you have a namespace specifically for the company, you know where to look for modules related to company or product-specific business logic.

But that's the point of my post. The code in question isn't specific to the company, at all. It could be used by other people. It's like if Amazon made an ISBN parser... Where ISBNs aren't unique to Amazon the company. Instead of putting it in Amazon::ISBN, it should be in ISBN::Parser, as if it were a public facing module.

# ¿ Jan 4, 2008 15:57

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > The Perl Short Questions Megathread: executable line noise

«‹›6 »