Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2016-08-12

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

All times shown according to UTC.

Time Nick Message
05:44 travis-ci RPerl build passed. Will Braswell says 'Learning RPerl, Scope Type Name Value, Part 5'
05:44 travis-ci https://travis-ci.org/wbraswell/rperl/builds/151711126 https://github.com/wbraswell/rperl/compare/66df51e9cc27...cab1433937de
05:44 willthechill yay
06:41 travis-ci RPerl build passed. Will Braswell says 'Learning RPerl, Scope Type Name Value, Part 6'
06:41 travis-ci https://travis-ci.org/wbraswell/rperl/builds/151717141 https://github.com/wbraswell/rperl/compare/cab1433937de...40ffa2c31773
07:06 travis-ci perl11/cperl#1403 (master - 4717fe0 : Reini Urban): The build passed. https://travis-ci.org/perl11/cperl/builds/151721185
11:45 mako joined #perl11
12:27 mako joined #perl11
13:44 mako joined #perl11
15:40 mako joined #perl11
16:09 willthechill joined #perl11
16:42 mako joined #perl11
16:58 mako joined #perl11
17:07 willthechill mako: howdy!  I saw you playing around on Trello on Weds afternoon.  :-)
17:34 mako joined #perl11
18:32 mako YES, ladys and gents, 'lib/RPerl/Test/Operator01NamedSineCosine/program_00_good.pl' is now working under CPPOPS_CPPTYPES.
18:33 mako At least when it comes to literals.
18:33 mako But it's a beginning.
18:40 mako joined #perl11
18:41 willthechill mako: wow awesome!  :-D  :-D  :-D
18:41 willthechill mako++
18:42 willthechill so did you figure out github as well?
18:54 mako Figure out github?
18:55 mako Do you mean how to push changes?
18:55 willthechill last I heard, you were having some issues with github
18:55 willthechill so I updated the git docs
18:55 willthechill but I didn't know if it was good enough to help or not?
18:56 mako Ah, ok, but wait I have to try something.
18:59 willthechill famous last words, haha!  ;-)
19:15 mako Hehe, you said it. As I could see I'm not allowed contribute directly to wbraswell:master as user '93r'. Did I get something wrong?
19:16 willthechill yes you make a pull request, as in the "getting started" doc
19:17 willthechill https://github.com/wbraswell/rperl/blob/master/docs/devs_getting_started.txt#L343
19:24 mako Ok, it doesn't matter whether I'm authorized (as I am) or not. Contributions only through pull requests?
19:25 willthechill yes we need all contributions to go through pull requests whenever possible, because github and travis are smart, they will run tests after you make a pull request but BEFORE I approve the pull request to be merged with the master branch in the main repo
19:25 willthechill so that is important, because then I can see if each pull request is passing tests before I approve it
19:26 willthechill this way we don't merge pull requests with bugs and break the main repo
19:26 willthechill :-)
19:28 mako Ah, ok, I wondered. Because, bulk88, for example, made contributions and it looked like he did it directly.
19:31 willthechill yes he did and sometimes that causes problems
19:32 willthechill and sometimes it takes ALL DAY to figure out those problems
19:32 willthechill :-P
19:32 willthechill so yes, we will use pull requests, haha!
19:32 willthechill although obviously bulk88 is an expert and he knows what he is doing
19:33 willthechill and since bulk88 is pretty much defacto in charge of the Windows platform, then sometimes he does need to do his own thing
19:35 mako Like me (when comes to OpenBSD/DragonFlyBSD someday far in the future. For what I am an expert.). BTW: I made a pull request.
19:36 willthechill well so far we do not have anybody in charge of BSD
19:36 willthechill ;-)
19:36 willthechill yes we can see your tests running here:  https://travis-ci.org/wbraswell/rperl/builds/151902355
19:39 mako Count me in for the BSD stuff (informal). A Question: Does RPerl have an environment variable for the standard C++ compiler?
19:39 willthechill one minor point so far: we always need to comment-out the calls to RPerl::diag() before submitting code to the master branch, same goes for me as well, unless I am actually debugging travis itself
19:40 willthechill C++ compiler is set by a command-line argument
19:40 willthechill https://metacpan.org/pod/distribution/RPerl/script/rperl#CXX-path-to-compiler
19:40 mako Ok, before contributing always stuff like RPerl::diag() has to be commented out.
19:41 willthechill yes because if we don't comment out the debugging statements then it will make RPerl run slower and also may create confusing output
19:41 willthechill do you need an actual environmental variable to set your C++ compiler, or is it good enough to use a command-line arg?
19:44 willthechill mako: next point regarding your current pull request, we are missing the test files *.CPPOPS_CPPTYPES to make sure your code generation is working correctly
19:44 willthechill https://github.com/wbraswell/rperl/blob/master/docs/devs_getting_started.txt#L308
19:45 willthechill for example CPPOPS_CPPTYPES files, you can see when pablo recently did the 'abs' operator
19:45 willthechill https://github.com/wbraswell/rperl/tree/master/lib/RPerl/Test/Operator01NamedAbsoluteValue
19:47 willthechill this means that if the currently-running travis tests pass, then it will really only be testing my own previously-existing tests, it will not actually be testing your new code
19:59 willthechill mako: okay your current pull request is passing on 5.18 at least!  :-)    https://travis-ci.org/wbraswell/rperl/jobs/151902360
19:59 willthechill However, we should NOT approve of merging this pull request, because as I said it does not contain the *.CPPOPS_CPPTYPES files to actually check if your code is working correctly
19:59 willthechill all we know so far is that you have not messed up MY code, haha!  ;-)
20:00 willthechill so as soon as the current travis tests finish for v5.24, then you can cancel this pull request and make a new one with the RPerl::diag() commented out and the missing *.CPPOPS_CPPTYPES files included
20:00 willthechill https://travis-ci.org/wbraswell/rperl/jobs/151902363
20:21 mako Made another pull request.
20:21 willthechill checking
20:23 willthechill mako: okay great looks good so far!  :-D
20:25 willthechill travis tests are running   https://travis-ci.org/wbraswell/rperl/builds/151911380
20:28 mako Excellent. But Literals for sin and cos are just the beginning. I have to get myself better acquainted with RPerl/Grammar.eyp. This code can't deal with more complex expressions. Even variables cause trouble. Anyway, I'm on way :-)
20:29 mako The travis tests are all under C++11?
20:30 willthechill all test are always using C++11, not just travis
20:30 willthechill RPerl is based on C++11
20:30 willthechill did you copy the code from the 'abs' operator?
20:30 willthechill because it SHOULD handle variables and anything else already
20:30 willthechill not just literals
20:32 willthechill mako: test failure but it is fixable
20:32 willthechill https://travis-ci.org/wbraswell/rperl/jobs/151911381#L9092-L9094
20:32 willthechill your code has    #ifndef __CPP__INCLUDED__program_00_good_cpp
20:33 willthechill but it should have    #ifndef __CPP__INCLUDED__RPerl__Test__Operator01NamedSineCosine__program_00_good_cpp
20:33 mako No, I used 'scalar' because 'sin' and 'cos' are in NamedUnary
20:33 willthechill okay scalar should be fine I think
20:35 willthechill yes I can see how scalar's CPPOPS_CPPTYPES code is a little bit complicated
20:35 willthechill because it is doing somewhat of a special jo
20:35 willthechill job
20:35 willthechill I suggest you take a look at 'abs' because it has simpler code
20:35 willthechill true that it is a different category of operator
20:35 willthechill but maybe it could help a bit...
20:36 mako It already helped.
20:36 willthechill oh you mean you looked at AbsoluteValue.pm just now?
20:38 mako No, I used 'scalar' and 'abs' simultaneously. Picked out what made most sense to me, logically speaking, that is.
20:38 willthechill ah okay gotcha, good job!  :-)
20:39 willthechill then I will let you continue with your work on Sine.pm & Cosine.pm
20:40 willthechill since this pull request is failing, obviously we need to fix that bug and make a new pull request
20:41 mako for #ifndef? also for the following #define?
20:44 willthechill yes correct
20:44 willthechill (I think)
20:47 willthechill mako: now that I look closer at your new code, I can see you have not caught onto the most important point, which is recursive generation
20:47 willthechill you are trying to manually generate each case, such as literal, etc.
20:48 willthechill this is already all done for you
20:48 willthechill but recursive generation
20:49 willthechill this is how it works:   https://github.com/wbraswell/rperl/blob/master/lib/RPerl/Operation/Expression/Operator/Named/AbsoluteValue.pm#L99-L107
20:49 willthechill that code from 'abs' is very close to what you need
20:49 willthechill needs to be changed to match proper grammar production serial numbers, etc which are specific to sine & cosine
20:50 willthechill the recursive generation happens with the call to ast_to_cpp__generate__CPPOPS_CPPTYPES( $modes, $self )
20:50 willthechill then the results are merged back into the currently-generated code by RPerl::Generator::source_group_append( $cpp_source_group, $cpp_source_subgroup )
20:52 willthechill for a simple operator like sine or cosine, you should not have to ever test for literals and handle them in any special way
20:52 willthechill so your code needs to be changed starting with:     if ( $subexpression_class eq 'SubExpression_138' )
20:52 willthechill (or perhaps earlier than that, but at least starting there)
20:53 mako Ok, I remember I already tried this. But something went wrong. Otherwise I would have never done it that way I did it. I have to rethink my steps.
20:54 mako But the changes in 'rperloperation.h' are ok, aren't they?
20:57 mako Oh, wait the 'rperloperations.h' stuff is missing.
20:58 willthechill you have not made any changes to rperloperations.h as far as I can see
21:13 mako Sorry, Will, another pull request.
21:18 willthechill checking
21:18 mako Needed stuff.
21:19 willthechill tests are running now    https://travis-ci.org/wbraswell/rperl/builds/151925529
21:20 mako The had to fail. Without the 'rperloperation.h' defines.
22:04 willthechill checking
22:05 willthechill mako: it seems to be passing on travis?  https://travis-ci.org/wbraswell/rperl/builds/151926904
22:06 willthechill or are you talking about a failure only on your system, not on a pull request?
22:14 mako I'm talking about the tests have to fail because I missed to commit 'rperloperations.h', but I have commited it now, so therefore if they fail it has to have another reason.
22:15 willthechill okay well the tests are NOT failing on travis right now?
22:18 mako At the moment: From Perl 5.10 to Perl 5.14 they seem to work. This is at least what I can see now.
22:18 mako Is it usual that it takes some time?
22:20 willthechill well sure we are running over 4K tests per version of Perl
22:20 willthechill about 15 - 20 mins per run
22:24 mako 5.16 also ok
22:27 willthechill yes it is rare that 1 version will fail if another passes
22:29 mako Let's see what happens.
22:29 willthechill I am still confused, you were saying that you thought travis should be failing because you did not include rperloperations.h in your pull request?
22:38 mako No, you're missing it. The real problem (obviously solved by now) was that I forgot to commit the 'rperloperations.h' file. https://travis-ci.org/wbraswell/rperl/builds/151926904
22:38 mako Doesn't seem to be an issue anymore.
22:39 mako Your decision, captain. ;-)
22:44 willthechill checking
22:46 willthechill OH okay I see, I was missing this commit    https://github.com/wbraswell/rperl/pull/60/commits/b6acaaf7452b2624bcff76627c77f22c3abeb93c
22:46 willthechill latest travis passing again   https://travis-ci.org/wbraswell/rperl/builds/151927920
22:46 willthechill so far so gooooood!  :-D
23:04 mako Great, seems to work. :-D
23:21 mako joined #perl11
23:49 mako joined #perl11

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