Re: [Boston.pm] Boston-pm Digest, Vol 184, Issue 2

Don’t forget the quotemeta function.   It will escape what needs to be escaped for you.   

-Hank

> On Jan 25, 2019, at 6:01 PM, [email protected] wrote:
> 
> Send Boston-pm mailing list submissions to
>    [email protected]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://mail.pm.org/mailman/listinfo/boston-pm
> or, via email, send a message with subject or body 'help' to
>    [email protected]
> 
> You can reach the person managing the list at
>    [email protected]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Boston-pm digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Is there a modifier on m or s that says the argument is
>      not a regex (Jerrad Pierce)
>   2. Re: Is there a modifier on m or s that says the argument is
>      not a regex (Steve Tolkin)
>   3. perl data to/from JSON? (Greg London)
>   4. Re: perl data to/from JSON? (Bill Ricker)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 13 Jan 2019 21:44:52 -0500
> From: Jerrad Pierce <[email protected]>
> To: Steve Tolkin <[email protected]>
> Cc: "'Boston PM'" <[email protected]>
> Subject: Re: [Boston.pm] Is there a modifier on m or s that says the
>    argument is not a regex
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="us-ascii"
> 
> You can wrap your expression to match in \Q \E to auto-escape things.
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 14 Jan 2019 20:40:14 -0500
> From: "Steve Tolkin" <[email protected]>
> To: "'Conor Walsh'" <[email protected]>, "'Jerrad Pierce'"
>    <[email protected]>, "'Bill Ricker'" <[email protected]>
> Cc: "'Boston PM'" <[email protected]>
> Subject: Re: [Boston.pm] Is there a modifier on m or s that says the
>    argument is not a regex
> Message-ID: <[email protected]>
> Content-Type: text/plain;    charset="UTF-8"
> 
> Thanks to all -- both suggestions are good.  If I make the time (ha!) I'll try to see if there is a material performance difference.  But I doubt it.
> So \Q \E wins by being a little easier to type -- and it has the side benefit that I can use regex in a few cases where what I want to match looks like \d+ etc.
> 
> -----Original Message-----
> From: Conor Walsh [mailto:[email protected]] 
> Sent: Sunday, January 13, 2019 9:57 PM
> To: Steve Tolkin <[email protected]>
> Cc: Boston PM <[email protected]>
> Subject: Re: [Boston.pm] Is there a modifier on m or s that says the argument is not a regex
> 
> Steve,
> 
> This sounds like a use-case for...  not using regular expressions. :) https://perldoc.perl.org/functions/index.html
> https://perldoc.perl.org/functions/substr.html
> 
> -C.
> 
>> On Sun, Jan 13, 2019 at 9:29 PM Steve Tolkin via Boston-pm <[email protected]> wrote:
>> 
>> Is there a modifier for m  that says the argument is not a regular 
>> expression?  Similarly for the or the first argument to s?
>> I looked and did not find it.
>> This seems like it would be useful.
>> 
>> I want to extract certain lines from a log file.  My perl program is 
>> basically  lots of lines like:
>> 
>> print if m/some string/;
>> 
>> If the string contains a left or right parenthesis I must escape it or 
>> else get an error message that says the argument is "not a regular expression".
>> 
>> So I have to escape each parenthesis with a backslash, which is 
>> tedious and error prone.
>> I presume I would also need to escape at least the open square 
>> bracket, but have not had those in the file.
>> 
>> Also, the string often contains lots of dots, e.g., is 
>> com.example.foo/bar/program.c at line(123)  and this requested 
>> modifier would have a small performance benefit.
>> 
>> --
>> Steve Tolkin
>> 
>> _______________________________________________
>> Boston-pm mailing list
>> [email protected]
>> https://mail.pm.org/mailman/listinfo/boston-pm
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Fri, 25 Jan 2019 15:47:50 -0500
> From: "Greg London" <[email protected]>
> To: [email protected]
> Subject: [Boston.pm] perl data to/from JSON?
> Message-ID:
>    <[email protected]>
> Content-Type: text/plain;charset=utf-8
> 
> This is a work-related issue, so certain decisions are out of my control.
> Also, I know only rudimentary python, and I know absolutely nothing about
> JSON, so, this whole thing may be complete garbage for reasons I'm unaware
> of. That said:
> 
> We have a number of perl and python scripts and we are looking to share
> data between them. It was decided that we use a JSON file format to store
> data and then have all the scripts read/write this format so it wouldn't
> matter if the script was python or perl.
> 
> basically I want to do this:
> 
> my $my_complex_data = [ {key1=>data1,key2=>data2}, [ {}, {key=>[] } ]];
> use Storable qw(nstore dclone retrieve);
> nstore ($my_complex_data, 'filename');
> my $revived = retrieve('filename');
> 
> But have the intermediate file format be JSON instead of Storable's format.
> 
> We also have to go through a process to get executable modules installed,
> so if it can be pure perl, I can just copy the file to a local directory,
> check it into the project, and use it without delay.
> I can get executables installed, but they have to be approved through a
> process, and then someone has to make sure they're installed on every
> machine everywhere, including all teh machines on LSF. so executables are
> possible, but likely a bit more painful.
> 
> I looked for JSON on CPAN and found... hundreds of matches???
> 
> It looks like JSON::PP is pure perl and does what I want.
> https://metacpan.org/pod/JSON::PP
> however, it says:
> "JSON::PP is a pure perl JSON decoder/encoder, and (almost) compatible to
> much faster JSON::XS"
> 
> How compatible is "almost" compatible?
> 
> I'm not actually worried about being compatible with JSON::XS. I'm worried
> about being compatible with whatever JSON file some python script ends up
> generating, or generating a JSON file that a python script may have to
> read.
> 
> 
> JSON::XS https://metacpan.org/pod/JSON::XS says:
> "This module converts Perl data structures to JSON and vice versa. Its
> primary goal is to be correct"
> 
> How "incorrect" might JSON::PP be?
> 
> JSON::PP says it is not "java script friendly" and that "If you need
> JavaScript-friendly RFC7159-compliant pure perl module, try JSON::Tiny,"
> 
> https://metacpan.org/pod/JSON::Tiny
> 
> JSON::Tiny says "it is among the fastest pure-Perl implementations of RFC
> 7159." But it doesn't say anything about "correct"ness.
> 
> So, what's the point of JSON::PP if JSON::Tiny does everything better and
> is also pure perl?
> 
> Has anyone used any of these modules?
> 
> If I wanted to take a complex perl data structure, save it to JSON format,
> and then have a python script read that JSON file, possibly modify the
> structure, and save it back as JSON, and then my perl script open that
> JSON back up, and read it back in again, which module is most likely to be
> cross-language compatible?
> 
> Any help woudl be appreciated.
> Greg
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Fri, 25 Jan 2019 18:00:51 -0500
> From: Bill Ricker <[email protected]>
> To: Greg London <[email protected]>
> Cc: Boston PM <[email protected]>
> Subject: Re: [Boston.pm] perl data to/from JSON?
> Message-ID:
>    <CAAbKA3Utb6eueOggR-+8NKCz9PnCXziFb5n9erTGCPQzzqhA6g@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> Scanning projects on my drive, i see lots of plain "use JSON;",  some "use
> JSON qw(encode_json decode_json);", a couple "use JSON::PP;" and one client
> using "JSON::XS", which would be desirable for speed (e.g. scaling web
> servirces).  I don't have any examples of  JSON::Tiny.
> 
> On MetaCpan, plain "JSON" has lots of reverse dependencies and is
> up-to-date.
> Tiny has many fewer rev-deps (packages that require it).
> 
> Plain "JSON" uses "JSON::XS" when available and falls back to JSON::PP ...
> and carries its own JSON::backportPP along as final default.
> So if you "use JSON;" you can install XS version later for speed with no
> change to using code.
> 
> As to Compatibility ... one can hope but no guarantees. EcmsScript is the
> standardized version of JavaScript, but the implementations aren't ES\d+
> they're something else.  The important thing is for your group to define
> what structure you're passing and write test cases to verify that your
> script reads and writes that format. And they do likewise.
> 
> 
> 
> 
> 
>> On Fri, Jan 25, 2019 at 4:08 PM Greg London <[email protected]> wrote:
>> 
>> This is a work-related issue, so certain decisions are out of my control.
>> Also, I know only rudimentary python, and I know absolutely nothing about
>> JSON, so, this whole thing may be complete garbage for reasons I'm unaware
>> of. That said:
>> 
>> We have a number of perl and python scripts and we are looking to share
>> data between them. It was decided that we use a JSON file format to store
>> data and then have all the scripts read/write this format so it wouldn't
>> matter if the script was python or perl.
>> 
>> basically I want to do this:
>> 
>> my $my_complex_data = [ {key1=>data1,key2=>data2}, [ {}, {key=>[] } ]];
>> use Storable qw(nstore dclone retrieve);
>> nstore ($my_complex_data, 'filename');
>> my $revived = retrieve('filename');
>> 
>> But have the intermediate file format be JSON instead of Storable's format.
>> 
>> We also have to go through a process to get executable modules installed,
>> so if it can be pure perl, I can just copy the file to a local directory,
>> check it into the project, and use it without delay.
>> I can get executables installed, but they have to be approved through a
>> process, and then someone has to make sure they're installed on every
>> machine everywhere, including all teh machines on LSF. so executables are
>> possible, but likely a bit more painful.
>> 
>> I looked for JSON on CPAN and found... hundreds of matches???
>> 
>> It looks like JSON::PP is pure perl and does what I want.
>> https://metacpan.org/pod/JSON::PP
>> however, it says:
>> "JSON::PP is a pure perl JSON decoder/encoder, and (almost) compatible to
>> much faster JSON::XS"
>> 
>> How compatible is "almost" compatible?
>> 
>> I'm not actually worried about being compatible with JSON::XS. I'm worried
>> about being compatible with whatever JSON file some python script ends up
>> generating, or generating a JSON file that a python script may have to
>> read.
>> 
>> 
>> JSON::XS https://metacpan.org/pod/JSON::XS says:
>> "This module converts Perl data structures to JSON and vice versa. Its
>> primary goal is to be correct"
>> 
>> How "incorrect" might JSON::PP be?
>> 
>> JSON::PP says it is not "java script friendly" and that "If you need
>> JavaScript-friendly RFC7159-compliant pure perl module, try JSON::Tiny,"
>> 
>> https://metacpan.org/pod/JSON::Tiny
>> 
>> JSON::Tiny says "it is among the fastest pure-Perl implementations of RFC
>> 7159." But it doesn't say anything about "correct"ness.
>> 
>> So, what's the point of JSON::PP if JSON::Tiny does everything better and
>> is also pure perl?
>> 
>> Has anyone used any of these modules?
>> 
>> If I wanted to take a complex perl data structure, save it to JSON format,
>> and then have a python script read that JSON file, possibly modify the
>> structure, and save it back as JSON, and then my perl script open that
>> JSON back up, and read it back in again, which module is most likely to be
>> cross-language compatible?
>> 
>> Any help woudl be appreciated.
>> Greg
>> 
>> _______________________________________________
>> Boston-pm mailing list
>> [email protected]
>> https://mail.pm.org/mailman/listinfo/boston-pm
>> 
> 
> 
> -- 
> Bill Ricker
> [email protected]
> https://www.linkedin.com/in/n1vux
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> 
> _______________________________________________
> Boston-pm mailing list
> [email protected]
> https://mail.pm.org/mailman/listinfo/boston-pm
> 
> 
> ------------------------------
> 
> End of Boston-pm Digest, Vol 184, Issue 2
> *****************************************

_______________________________________________
Boston-pm mailing list
[email protected]
https://mail.pm.org/mailman/listinfo/boston-pm