IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 1 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Error checking remains a best practice
How to handle errors becomes a coding choice.

At the least you want to notice them and log the information somewhere useful. In a web environment you can just print to STDERR and it goes into the webserver error logs. The warn operator adds the current line, and Carp's carp function will add a stack backtrace. None of this will affect the rest of the execution of the program.

But the way that I like doing it is to make errors fatal with die. And then have in the server configuration a place where fatal errors are trapped with a signal handler for DIE. In development they are displayed on screen and in the log with a stack backtrace. In production the user gets a generic error message and the full error is in the logs. (And you work to keep error logs clean. Do not ignore them.) In production you do not want to show a stack backtrace - this debugging information is very helpful to attackers, allowing them to use standard techniques to convert minor coding errors into full-blown exploits.

Setting this configuration up, of course, takes some wizardry. I'd bet that you can find a good starting example from a co-worker though.

My attitude is that if errors are big and visible, then I'm more likely to catch them, and if I don't then testing does. The more you hide errors, the longer they last in the development process, and the longer they last, the more expensive they become to fix. (There is a lot of research backing up the point that errors caught later cost more. I don't know of any that specifically addressed whether having big visible crashes was a net gain or loss though - all I have is my anecdotal experience that this works pretty well.)

As for the directory path issue, ugh. Getting that kind of environment issue sorted out is always a PITA for me. Luckily Mason makes the actual decision configurable. Unluckily you have to figure out how Mason is set up to configure it.

In your position, I'd strongly be inclined towards getting fairly direct access on the Unix machine. Either by setting up VNC there, or setting up X on your machine, or just sshing and using a command-line environment. It isn't just your view of the path issue, it is also being able to run code out of the webserver environment, testing what modules are installed, etc, etc, etc.

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New Agree
More experimentation shows that Mason does something sane and decent when you die fatally.

This is an intranet app - its got maybe a dozen users - all of whom are techies - so its not terribly crucial to keep it ultra robust.

Interestingly, I've found that Jon Swartz, creator of mason, is in my group and just down the hall, so I've got a pretty good resource for mason questions. The rest is getting into the perl mindset.

I can't believe nobody has implemented plists in perl though.



That was lovely cheese.

     --Wallace, The Wrong Trousers
Expand Edited by tuberculosis Aug. 21, 2007, 06:37:51 AM EDT
New You lucky duck.
Nobody is down the hall from me. No peers in the whole building. :(
New What do you mean by plists?
There are a lot of things that are called plists in the world, I have no idea which one you're referring to. (I started with no idea, I hit Google, I still have no idea but now I know that, without context, I really shouldn't be able to make heads or tails of your comment.)

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska Supreme Court]
New I meant NextStep style plists
hashes or dictionaries are { key = value; }
arrays or lists are ( one, two, three )
strings are quoted when necessary (contain spaces or punctuation) otherwise not.

All three may be nested arbitrarily.
Interestingly, I've found that here at big river books the code modules have plist format compatibility descriptors.

This is a dictionary with two entries - one is strings, the second has a list of strings for a value.

{
"Todd's Key" = "This is cool";
NSRecentDocuments = (
"/Users/todd/Text File.txt",
/Users/todd/Desktop/Documents/Readme.rtf,
/tmp/file.txt,
/tmp/file2.txt
);
}



That was lovely cheese.

     --Wallace, The Wrong Trousers
Expand Edited by tuberculosis Aug. 21, 2007, 06:38:24 AM EDT
New Do you mean kind of like this?
\n{\n  "Todd's Key" => "This is cool",\n   NSRecentDocuments => [\n     "/Users/todd/Text File.txt",\n     "/Users/todd/Desktop/Documents/Readme.rtf",\n     "/tmp/file.txt",\n     "/tmp/file2.txt",\n   ],\n};\n

That's valid Perl. Like the plists that you're looking for, you can nest arbitrarily to produce any data structure that you want.

It shouldn't be particularly hard to write a parser that loads/dumps between plists and the above internal Perl data structure. The main problem that you might run into is in coming up with a good name to use when trying to release the module into the wild. (Because "plist" is such an ambiguous term.)

Incidentally what is the relationship between that kind of plist and the XML-based one that [link|http://search.cpan.org/~bdfoy/Mac-PropertyList-0.9/lib/PropertyList.pm|http://search.cpan.o...b/PropertyList.pm] deals with?

Cheers,
Ben
To deny the indirect purchaser, who in this case is the ultimate purchaser, the right to seek relief from unlawful conduct, would essentially remove the word consumer from the Consumer Protection Act
- [[link|http://www.techworld.com/opsys/news/index.cfm?NewsID=1246&Page=1&pagePos=20|Nebraska|http://www.techworld...gePos=20|Nebraska] Supreme Court]
New Pretty close
The plist format (which I would name NSPList for NextStep PList) I describe is now known by the J-heads at Apple as "Classic" or "old style" plists. They are trying to deprecate them. They are fools.

There are still plenty of them around and thus the libraries to read and write them are still (and ever will be) supported.

However - the J-headed XML fashion followers decided to "modernize" the plist and thus created a really lame and bloated XML-ization of them. So, while dictionaries used to be written:

{ key = value; key2 = value2; }

Now we have to have something like
\n<dict>\n   <key><string>key</string></key><data><string>value</string></data>\n   <key><string>key2</string></key><data><string>value2</string></data>\n</dict>\n


See, lots more readable (NOT).

The only advantage seems to be the addition of type tags - string, date, real, int, etc. Frankly I was happy with "everything is a string".

Anyhow, I still use NS style plists all the time. I have parsers in Java, C++, and Smalltalk. You can write a recursive descent plist parser in about a page of code. Once you have one you never write IO code to save data again.



That was lovely cheese.

     --Wallace, The Wrong Trousers
Expand Edited by tuberculosis Aug. 21, 2007, 06:40:25 AM EDT
New Ah
So for you the old-style plists are your One True Data Format for data interchange.

In the Perl world there is no such thing - largely because a lot of Perl exists in the boundaries of converting between different people's home-grown data formats. You aren't going to figure out how to deal with those without doing I/O.

However a million and one attempted universal formats have been produced. The ones that seem to have mindshare in the Perl world are XML, YAML, and native Perl code. Each of which has Perl tools that keep you from having to think about I/O. I don't think that another would get mindshare, but there is no harm in throwing it out there.

Incidentally for writing recursive descent parsers, the gold standard in Perl seems to be [link|http://search.cpan.org/~dconway/Parse-RecDescent-1.94/lib/Parse/RecDescent.pod|Parse::RecDescent]. Unfortunately since it was added, Perl added the /g attribute to REs but the module has never been rewritten to use that. (Damian intended to, but never got around to it in Perl 5. His rewrite will be built into the language in Perl 6.) So its memory use tends to be quadratic in the size of the string, and performance on long strings is correspondingly bad.

If you write a recursive descent parser in Perl, my suggestion is therefore either to use that, or to study the pos function and use REs with \\G and /gc liberally in your tokenizing. Oh, and never, ever use $`, $& or $'. (Use once and the RE engine slows down a lot, permanently.)

Cheers,
Ben
About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. -- Edsgar W. Dijkstra
New One True Data Format
Lets just say I've got a lot of them around, plenty of code for dealing with them, and I can read/write/edit them by hand easily.




That was lovely cheese.

     --Wallace, The Wrong Trousers
Expand Edited by tuberculosis Aug. 21, 2007, 06:40:37 AM EDT
New Big River Books - rofl
Sure that's not "Big Mean Lesbian Books"?

Watch that right breast!

-drl
New ICLRPD (new thread)
Created as new thread #174373 titled [link|/forums/render/content/show?contentid=174373|ICLRPD]
Two out of three people wonder where the other one is.
     Perl - storing a hash in a file to re-read later - (tuberculosis) - (26)
         Wouldn't it be better to build it as you read? - (drewk) - (2)
             Its not large - its small - (tuberculosis) - (1)
                 Perl is line oriented by default - (broomberg)
         This wheel has been invented already :-) - (ben_tilly) - (22)
             <fawn>Wonderful post</fawn> - (pwhysall) - (1)
                 <preen /> -NT - (ben_tilly)
             I am so glad I gave up on tying my programming skills... - (inthane-chan) - (7)
                 Why? -NT - (deSitter) - (6)
                     Because there's no way I could match that answer. -NT - (inthane-chan) - (5)
                         But that isn't programming - (ben_tilly) - (4)
                             Nice to see a teacher/craftsman in action. - (ChrisR) - (3)
                                 A good thing for my spare time you mean? - (ben_tilly)
                                 Why? -NT - (deSitter) - (1)
                                     Jack of all languages... - (ChrisR)
             I figured it had - one more quickie question - (tuberculosis) - (11)
                 Error checking remains a best practice - (ben_tilly) - (10)
                     Agree - (tuberculosis) - (9)
                         You lucky duck. - (FuManChu)
                         What do you mean by plists? - (ben_tilly) - (6)
                             I meant NextStep style plists - (tuberculosis) - (5)
                                 Do you mean kind of like this? - (ben_tilly) - (3)
                                     Pretty close - (tuberculosis) - (2)
                                         Ah - (ben_tilly) - (1)
                                             One True Data Format - (tuberculosis)
                                 Big River Books - rofl - (deSitter)
                         ICLRPD (new thread) - (Meerkat)

There might be poisonous gnomes hiding behind the furniture and I can't take that chance.
161 ms