perl regex

[peterchan75]

@david/yk,

Surely, you must have an elegant way with 1 statement.

	my $minus = '-';
	my $fslash = '/';
	$date_str =~ s/$minus/$fslash/g;

 

[ykgoh]

$date_str =~ s/\-/\//g;

 

[localITguy]

$date_str =~ s/\-/\//g;

expert spotted

 

[peterchan75]

$date_str =~ s/\-/\//g;

Thanks.
I had this earlier but was applying to the wrong string. I suspected it didn't work and I use brute force in the correct string.

 

[davidktw]

$date_str =~ s/\-/\//g;

Good job.

Just a small note, there is no need to escape "-" since it is not a special character.
In cases of conflicting characters found in the regex, you can use a different delimiters as such

s#-#/#g
s{-}{/}g

To TS:

Alternatively you can also use transliterates operator "tr" as such

tr#-#/#

 

[peterchan75]

When one is tire, just stop and rest !

I google for help and got the same answer as yk. BUT....
I have $date_str in the subroutine parameter and return $new_date. I apply the regex on $new_date. I should have apply on $date_str i.e. MM-DD-YYYY to MM/DD/YYYY before processing.

BTW, I transform date from 7/10/2016 to 20160710 for sorting. Is this an optimal approach ?

 

[ykgoh]

When one is tire, just stop and rest !

I google for help and got the same answer as yk. BUT....
I have $date_str in the subroutine parameter and return $new_date. I apply the regex on $new_date. I should have apply on $date_str i.e. MM-DD-YYYY to MM/DD/YYYY before processing.

BTW, I transform date from 7/10/2016 to 20160710 for sorting. Is this an optimal approach ?

http://perltricks.com/article/59/2014/1/10/Solve-almost-any-datetime-need-with-Time--Piece/

 

[peterchan75]

http://perltricks.com/article/59/2014/1/10/Solve-almost-any-datetime-need-with-Time--Piece/

Thanks yk.
For the time being, my current subroutine is suffice.

 

[ykgoh]

Thanks yk.
For the time being, my current subroutine is suffice.

The problem is that Perl has no standard data type and API for date time unlike other languages like .NET or Java. The only standard functions we can assume that are always available are: time(), gmtime(), and localtime() function. Data tend to be returned as an array, or as a string. There is no standard special datatype.

This is good for understanding date and time in Perl, and the various modules that emerged to handle them differently. Some of these have overlapping features, and examples are available for different modules which add to the confusion. Read: http://www.perl.com/pub/2003/03/13/datetime.html

Apparently, Perl's treatment of time and date is influenced much by C programming language. And in C, the time_t is the datatype for storing date time, usually as an unsigned integer (typically 32 or 64 bits wide) which represents the number of seconds since the start of the Unix epoch: midnight UTC of January 1, 1970 (not counting leap seconds).

My personal opinion:

• If you prefer to rely on only standard functions in Perl without CPAN modules, you can probably follow C and save the number of non-leap seconds since epoch using a normal scalar variable returned by time().
• If you prefer to have convenience methods for date time manipulation and object-oriented codes, then look at those CPAN modules.

Personal disclaimer:

I know some old time Perl coders hate object-oriented codes. Many old Perl codes are also simply written as procedural style, so mixing blocks of newer OO-style codes does make it look like messy. For me, I prefer codes to be consistent, and either it is 100% OO or 100% procedural, but not a mixture: it looks like sheet to me. And I am not a big fan of C/C++ programming where macros are rampantly abused.

 

[davidktw]

I would agree different individuals have different needs and perspective of Perl, and so this is mine.

Perl is greatly influenced by C in those days and OO is really very much an afterthought, hence even the OO constructor used is in the form of method invocation as

$o = Class->new(...)

It is simply sugar syntax to use

$o = new Class(...)

My stand is if you were to expect Perl to be as consistent as some really strong typed languages like Java and C++, I suspect it would really take some going against the flow of what Perl represent. Perl is a glue language, its job is not really so much on performance and consistency. If it is, the syntax alone would greatly betray itself. The parser of Perl in my understanding of context free programming language, don't even fit in. There are just so much context required to parse Perl properly, and deliberateness of programmers to just help Perl in the parsing during ambiguous syntax. Just read up the map documentation using "perldoc -f map" and you will read the following


...

"{" starts both hash references and blocks, so "map { ..." could
be either the start of map BLOCK LIST or map EXPR, LIST. Because
Perl doesn't look ahead for the closing "}" it has to take a guess
at which it's dealing with based on what it finds just after the
"{". Usually it gets it right, but if it doesn't it won't realize
something is wrong until it gets to the "}" and encounters the
missing (or unexpected) comma. The syntax error will be reported
close to the "}", but you'll need to change something near the "{"
such as using a unary "+" or semicolon to give Perl some help:

%hash = map { "\L$_" => 1 } @array # perl guesses EXPR. wrong
%hash = map { +"\L$_" => 1 } @array # perl guesses BLOCK. right
%hash = map {; "\L$_" => 1 } @array # this also works
%hash = map { ("\L$_" => 1) } @array # as does this
%hash = map { lc($_) => 1 } @array # and this.
%hash = map +( lc($_) => 1 ), @array # this is EXPR and works!

%hash = map ( lc($_), 1 ), @array # evaluates to (1, @array)

...


Perl today is a mixture of OO, procedural and functional. OO is really nothing more than a modular packaging for the language, however we might see more in Perl6, but Perl6 is another set of nightmare.

For datetime, my opinion is stick with native integral unix epoch. Many OO date time classes will convert inputs of various formats into it simply because it is the most effective for storage, formatting, processing, and comparison. It will also allow you to easily pass between various languages whether via interoperability conduits such as HTTP, JSON, XML and definitely works extremely compatible when you need to touch on XS (interface to C/C++)

 

[peterchan75]

@david / yk,
Wall of text of purist discussion.

Why perl always like to give me nightmare ?

For example, sorting string from a to z, this should be the case.
Rail
REAL

But perl sort gives this.
REAL
Rail
What a nonsense ! Crap !
Upper case has precedence over lower case. Strange indeed.
Took me 2 days to figure this out... really 2 days in hell.

 

[davidktw]

@david / yk,
Wall of text of purist discussion.

Why perl always like to give me nightmare ?

For example, sorting string from a to z, this should be the case.
Rail
REAL

But perl sort gives this.
REAL
Rail
What a nonsense ! Crap !
Upper case has precedence over lower case. Strange indeed.
Took me 2 days to figure this out... really 2 days in hell.

Let me tell you, it is hell to you because you thought discussions like these are purist, which I can assure you, they are necessary and essence to correctness of the codes. The devil are in the details

Your claims of purist in your context don't even come near to one. Take the example of Uppercase are "smaller' than Lowercase. It don't even fit under the discussion of opinions. It is programming language agnostic, go read the ASCII table and read the details how lexical sorting works.

The more you want to take the easy way out, the more you get stuck in the caveats. This is my advise to you.

 

[Maeda_Toshiie]

Let me tell you, it is hell to you because you thought discussions like these are purist, which I can assure you, they are necessary and essence to correctness of the codes. The devil are in the details

Your claims of purist in your context don't even come near to one. Take the example of Uppercase are "smaller' than Lowercase. It don't even fit under the discussion of opinions. It is programming language agnostic, go read the ASCII table and read the details how lexical sorting works.

The more you want to take the easy way out, the more you get stuck in the caveats. This is my advise to you.

Not all machines are ASCII... *cough* EBCDIC *cough*

 

[davidktw]

Not all machines are ASCII... *cough* EBCDIC *cough*

That is true, how much coverage are we talking about for EBCDIC ? Would you be able to advise ?

In fact, I would probably want to upgrade to UTF-8 instead, which conveniently cover ASCII too.

 

[peterchan75]

Let me tell you, it is hell to you because you thought discussions like these are purist, which I can assure you, they are necessary and essence to correctness of the codes. The devil are in the details

Your claims of purist in your context don't even come near to one. Take the example of Uppercase are "smaller' than Lowercase. It don't even fit under the discussion of opinions. It is programming language agnostic, go read the ASCII table and read the details how lexical sorting works.

The more you want to take the easy way out, the more you get stuck in the caveats. This is my advise to you.

OK ...serves me right again !
In Excel VBA, it bashed right through without hitch. Irregardless of uppercase or lowercase !
Oh... boy... all these minor details are making my hair stand !

 

[davidktw]

OK ...serves me right again !
In Excel VBA, it bashed right through without hitch. Irregardless of uppercase or lowercase !
Oh... boy... all these minor details are making my hair stand !

The devil is in the details. VBA by default sort case insensitively, but there is also the option to sort in case sensitive lexicographical order based on the encoding table (to be more proper).

Most programming languages are case sensitive when coming to textual treatments. I must highlight this are the purists opinions that you seems to be having issues with, that is because programming languages have opinions on their own as introduced by their developers.

Bashing thru will only create gaps in your knowledge and very often these are the knowledge that differentiate your skill sets from another and also amount to the number strands of hairs growing on your head

 

[peterchan75]

The devil is in the details. VBA by default sort case insensitively, but there is also the option to sort in case sensitive lexicographical order based on the encoding table (to be more proper).

Most programming languages are case sensitive when coming to textual treatments. I must highlight this are the purists opinions that you seems to be having issues with, that is because programming languages have opinions on their own as introduced by their developers.

Bashing thru will only create gaps in your knowledge and very often these are the knowledge that differentiate your skill sets from another and also amount to the number strands of hairs growing on your head

Salute!
In order to get it to work... go by the book.
There is no other. The way of the purist !

 

[ykgoh]

Salute!
In order to get it to work... go by the book.
There is no other. The way of the purist !

Not because we want it that way, but all computers work as such.

Case-insensitive sort in Perl can still be written as 1 line. Need to be familiar with the tools to use them correctly, rather than trying to customize the tools to fit how we think they ought to work.

But many people think programming job is easy. It takes time - years perhaps - to learn, experiment and remember all the intricacies of all the technologies in use, and technologies keep changing. Now this is only Perl. If you try to be full stack developer or devops that is 1,000 times worse. And people are willing to pay only peanuts for a decent programmer.

 

[peterchan75]

Not because we want it that way, but all computers work as such.

Case-insensitive sort in Perl can still be written as 1 line. Need to be familiar with the tools to use them correctly, rather than trying to customize the tools to fit how we think they ought to work.

But many people think programming job is easy. It takes time - years perhaps - to learn, experiment and remember all the intricacies of all the technologies in use, and technologies keep changing. Now this is only Perl. If you try to be full stack developer or devops that is 1,000 times worse. And people are willing to pay only peanuts for a decent programmer.

My objective is not to be a full stack but just get the project done!
Sometime silly typo error like => instead of >= can cause a lot of pain.
The trouble is perl didn't complain => but everything goes through.
Of course, if pay peanuts, then only can get monkey.

 

[davidktw]

My objective is not to be a full stack but just get the project done!
Sometime silly typo error like => instead of >= can cause a lot of pain.
The trouble is perl didn't complain => but everything goes through.
Of course, if pay peanuts, then only can get monkey.

Using your rationale that we only need to learn just enough to get work done, then it must be really easy to build a rocket right? we all wanted to get work done, but that doesn't mean learning just enough, because you simply do not know where is the line to be drawn to consider just enough. Do you feel what you know now is enough to get the job done? You only know you need to know more when you meet up with issues, but often the next step to learn what is necessary has prerequisites, and just objective driven may not be the most optimal way to learning. You will be learning blindly if you are doing so