Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2016-11-16

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
06:00 rurban joined #perl11
06:40 rurban joined #perl11
06:43 anton_p joined #perl11
08:20 rurban joined #perl11
09:21 jahero joined #perl11
09:22 jahero Hello there. Can I ask basic question about rperl? Is it possible to use RPerl, and still utilize key CPAN modules, such as File::Spec, File::Basename, etc? And if yes, where is the "line in sand" - how to detect modules one can not use?
09:22 jahero Thanks!
09:23 willthechill jahero: nice to meet you, I am the creator of RPerl!  :-)
09:24 jahero Hello :)
09:24 willthechill RPerl compiles one file at a time, so you can move some subroutines in one special Perl module file to be compiled by RPerl, then leave the rest of your non-compiled code in other files
09:24 willthechill currently, the restriction is that normal Perl code can call RPerl code, and RPerl code can call other RPerl code, but RPerl code cannot call back to uncompiled Perl code
09:24 willthechill this limitation will be removed in some future version of RPerl
09:24 willthechill but it is very very very complicated to achieve that, so it may take a year or two, haha!  :-)
09:25 jahero Hmm...
09:25 jahero I am curious about this since the company I work for currently uses PERL as "glue" holding processing of data warehouse together
09:25 jahero some critical tasks are done in PERL (preprocessing of text files)
09:26 jahero some critical tasks are however implemented using "legacy" compiled code, and/or in Informatica
09:26 jahero since times are tough there are speculations that Informatica should be replaced
09:26 jahero so I had this idea of using PERL to achieve tasks such as normalization of phone numbers, etc.
09:27 willthechill sure you can do that
09:27 jahero however performance tax connected to overhead of using SUBs in the code seems rather daunting
09:27 willthechill when compiled, RPerl is faster than anything else
09:27 jahero so I thought - hey, perhaps I could use restricted perl to get better performance
09:27 willthechill yes that is correct!
09:28 jahero (seems to me I have to spend a month or two just experimenting)
09:28 jahero so, from your answer it seems that using CPAN modules might be feasible (depending on the way how they are implemented) - correct?
09:29 willthechill sure, just make sure it is the uncompiled parts of your code which will call CPAN
09:29 willthechill simples possible architecture: uncompiled master module calls both uncompiled CPAN modules and compiled RPerl module
09:30 willthechill compiled RPerl module only calls other RPerl code
09:30 jahero OK, thanks for your answers and your time. Much appreciated.
09:30 jahero Good day to you, sir - and I hope RPERL will see much use!
09:34 willthechill jahero: okay thanks!  :-)
09:34 willthechill jahero: do you use Facebook?
09:37 jahero no, not anymore :) too much noise
09:37 willthechill jahero: how about github?
09:38 jahero Not at the moment, no
09:38 jahero most of my work is connected to the account I am on... not much reusability there
09:38 willthechill what account is that?
09:38 willthechill sorry I'm confused
09:39 jahero sorry, English is not my native language.
09:39 jahero I am currently working for O2 Czech republic as an external work force.
09:39 willthechill okay gotcha
09:39 jahero I am a freelancer consultant, specializing in Teradata development and metadata management
09:39 willthechill cool!  :-)
09:40 jahero You could say that my interest in perl started from necessity, however lately it becomes sort of a passion
09:40 willthechill ah yes well many of us are quite passionate about Perl!  so what is your preferred method of communication, if not Facebook or GitHub?
09:40 jahero old school email I am afraid :)
09:41 jahero (I was not even aware that github can be used as a communication platform)
09:41 willthechill GitHub issues allows basic communication for bug reports, etc.
09:42 jahero cool, did not know that.
09:43 jahero well, what I can promise you is that if this idea of using RPerl "on site" proves feasible (several obstacles there), I will provide any feedback I can.
09:43 willthechill great!
09:43 willthechill if you would like to give me your gmail or e-mail address, then I can keep you on our list of possible developers
09:44 rurban problem is that email is a dangerous and not really usable communication platform for perl. so we use mainly stricter platforms.
09:44 jahero why not... currently jan.herout@teradata.com, however that email might be deleted in the future. personal email I am using is jan.herout@gmail.com
09:45 jahero however, my C++ skills are virtually nonexistent. Not much I can in rperl development area.
09:45 willthechill okay great, RPerl system developers must have C++ skills, RPerl application developers do not
09:46 jahero true
09:46 jahero so I guess you are thinking about creating a reusable code repository like CPAN?
09:47 willthechill we are using CPAN, no need to reinvent the wheel
09:47 willthechill already PhysicsPerl and MathPerl are on CPAN
09:47 willthechill both are RPerl application suites
09:47 jahero I have to check that :)
09:47 willthechill pre-release v0.1, but still, they exist
09:48 willthechill I sent you an invite to your gmail account
09:49 willthechill I will send you more info soon, you can accept the invite for now
09:49 willthechill soon, like over the next week or two probably
09:50 rurban but normalizing phone numbers you need only plain integers ops. they already exist. just the strings ops are a bit lacking IMHO
09:50 jahero well, not entirely true
09:50 jahero those CDRs are nasty business
09:50 jahero there is a lot of noise you have to get rid of...
09:50 rurban mostly regex?
09:51 jahero yes
09:51 jahero 20+ rules
09:51 rurban well, that's not in rperl yet. very tricky
09:52 rurban in mostly perl5 is already good enough, for short strings.
09:52 jahero oops :)
09:52 jahero well, some operations can be done using basic slicing and dicing (substr)
09:53 rurban slicing is already optimized a bit via fbm and offset hacks.
09:53 willthechill substr in RPerl is much faster and uses less memory than normal Perl, because it is using C++ data types and ops for strings
09:54 willthechill regex is not supported in RPerl v2.2, as rurban said
09:54 jahero do you plan this in the future?
09:54 rurban well, the libstdc++ ops for strings are not really much better than perls.
09:55 rurban and their regex is even worse. only without backtracking there would be bette regex, but phone number normalization probably needs a lot of backtracking
09:55 jahero hmm, seems like a lot of work then
09:56 rurban I would rather try using pure perl for this application then. rperl really shines with arithmetic and sorting/algo stuff, which is horribly slow in perl5.
09:56 jahero Well, actually, I am curently looking in the code my colleague is writing for this, and it is pretty basic (so far)
09:57 willthechill jahero: rurban and I disagree about some things.  if you are want to do fast string manipulation w/out regular expressions, then yes RPerl is good.
09:57 jahero seems to me that it is achievable using substr / index
09:57 jahero so perhaps it is not hopeless :)
09:58 willthechill I am in no rush whatsoever to add regular expression support to RPerl, you can use regular uncompiled Perl code for the regex parts
09:58 jahero problem with that approach is when going through a lot of data.
09:59 jahero read line => split it => do some stuff using regular expressions
09:59 jahero and do this for 300+ different extracts
09:59 rurban with perl5 you've got a 4x memory overhead for strings. with rperl/c++ less
09:59 jahero so it likely can not be hardcoded
09:59 jahero you need to write code which accepts some sort of parametrization from outside
10:00 rurban callbacks are also very slow in perl5, very fast in rperl/c++
10:00 jahero basically, if you do it in perl, performance likely goes to hell because you need to encapsulate code... can not do it "inline", you need to write subs / objects that achieve things
10:00 jahero so, thats why I am looking at RPerl now.
10:00 willthechill try to do it w/out any regex
10:01 jahero well, I think it is actually feasible
10:01 jahero so far have I have not seen anything which screams REGEXP NEEDED
10:01 rurban inlining is almost done in cperl, which is fully perl5 compatible. but it needs a few months still.
10:01 jahero though it is definitely much simpler to write regexp (less code needed)
10:02 jahero ok, my next step will be trying "hello world", and then experimenting a bit.
10:02 jahero promise to let you know how that fans out :)
10:03 willthechill jahero: make sure you start here...   http://rperl.org/learning_rperl.html
10:03 jahero yes, saw that one :)
10:04 jahero will do, thanks.
10:04 willthechill here's Hello World for you...    http://rperl.org/learning_rperl.html#Chapter_1%2C_Exercise_1
10:05 jahero thanks for your kind help
10:05 jahero got to go.... will stay in touch
10:05 willthechill you are quite welcome, see you soon!  :-)
10:06 jahero see you!
12:36 rurban joined #perl11
14:05 travis-ci perl11/cperl#1907 (smoke/master - 1055d8c : Reini Urban): The build was broken. https://travis-ci.org/perl11/cperl/builds/176370135
16:23 rurban joined #perl11
17:57 travis-ci perl11/cperl#1907 (smoke/master - 1055d8c : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/176370135
18:24 anton joined #perl11
21:45 willthechill joined #perl11

| Channels | #perl11 index | Today | | Search | Google Search | Plain-Text | summary