vividsnow

• Website: vividsnow.tumblr.com
• About: perl blog

Recent Actions

• Commented on Perl 7, not quite getting better yet
  Thank you, it very closely reflects my feelings regarding the announcement of Perl 7....
• Commented on Etsy's skyline port to perl
  and $p->at(-1)...
• Commented on RSS feed for blogs.perl.org
  comments: https://blogs.perl.org/comments.xml...
• Commented on Video Encoding Modules?
  GStreamer + OpenGL...
• Commented on perl live coding
  Not real time of course - this is condensed version, because it is boring to watch chars appearing one by one )...
• Posted perl live coding to vividsnow

  Hello, Everyone!

  Since I think that live coding gives more flexibility and visual feedback than conventional REPL, here is approach to simple Perl live cod…

• Commented on Perl Data Language (PDL) 2.4.10 Release
  Great work and thank you, PDL team!...
• Commented on What should be core in Perl 5.16?
  App::cpanminus Try::Tiny JSON::XS YAML::XS DBI DBD::SQLite HTTP::Tiny Perl::Critic Perl::Tidy...

Recent Actions from vividsnow

Comment Threads

• moritz commented on Perl 7, not quite getting better yet

  Smylers, another nugget to consider: Raku's "use DBI:from;" only work because Raku and Perl 5 have different library search paths (and methods, but that's secondary).

  If you plan to use the same search paths for mixed Perl 5 + 7 libraries, then the information about which language to use has to be in the module, not in the caller.

  Otherwise you run into weird issues where you have "use5 A::B" but "use7 A::C", and then A::B cannot upgrade to Perl 7, because all the callers still use "use5" to load it (whatever the syntax turns out to be). Also, you spread the knowledg…

• Smylers commented on Perl 7, not quite getting better yet

  you run into weird issues where you have "use5 A::B" but "use7 A::C", and then A::B cannot upgrade to Perl 7, because all the callers still use "use5" to load it

  Not quite. use wouldn't mean ‘load and enforce v5 semantics regardless of what the file says’, but ‘load with v5 semantics by default’. A::B could still put a use v7 in there to switch itself to modern meanings. The point would be to avoid inadvertently loading a legacy module with modern semantics that it didn't know about, but nothing stops it opting i…

• Leon Timmermans commented on Perl 7, not quite getting better yet

  No apologies needed, but taking things to p5p may be a good idea indeed.

• tnish commented on Perl 7, not quite getting better yet

  Can we just have a /usr/bin/perl-ng (for 'next gen', or any other cheesy suffix we can think of)? It doesn't take over /usr/bin/perl, we won't end up with multiple perl8, perl9, etc... And it still has "perl" in it. /usr/bin/perl-ng will be 7 and beyond, /usr/bin/perl will be 5.x. Distros can ship a perl 7+, and a perl 5.x. It will be annoying to remember adding -ng to perldoc, cpan, and a few others, but, seems like something we can get used to (I'd just use shell aliases or something).

• George Magklaras commented on Perl 7, not quite getting better yet

  Nice article, I see most of your points. For the purposes of accuracy, however, you might like to correct what you say about Python3 and the Linux distros. Fedora (since Fedora 32 which is the latest stable) has switched to Python3 by default (and yes, this has upset many dev folk that were still relying on Python2). Gentoo (I think) has a compilable option to switch to Python3 and OpenMandriva has also ditched Python2. So, things are happening there.

Responses to Comments from vividsnow