Perl 6 - the future is here, just unevenly distributed

IRC log for #perl11, 2016-06-28

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

All times shown according to UTC.

Time Nick Message
02:05 sten joined #perl11
05:18 kentnl joined #perl11
07:27 willthechill joined #perl11
09:59 travis-ci perl11/cperl#1238 (smoke/relprep5.24.0 - 29d9567 : Matthew Horsfall): The build passed. https://travis-ci.org/perl11/cperl/builds/140752446
10:02 ashevchuk joined #perl11
10:35 sten joined #perl11
12:29 travis-ci RPerl build passed. Will Braswell says 'Merge branch 'master' of github.com:wbraswell/rperl'
12:29 travis-ci https://travis-ci.org/wbraswell/rperl/builds/140786776 https://github.com/wbraswell/rperl/compare/01e556314f96...3bf6a0b51b26
12:30 ashevchuk joined #perl11
12:34 willthechill bulk88: I added more debugging messages to test 09, it is freezing or otherwise stalling out in waitpid
12:34 willthechill https://ci.appveyor.com/project/wbraswell/rperl/build/1.0.111
12:35 willthechill this is where it hangs in the code:  https://github.com/wbraswell/rperl/blob/master/t/09_interpret_execute.t#L136-L138
12:36 willthechill how to proceed?
12:52 ashevchuk joined #perl11
13:11 lizmat joined #perl11
13:19 bulk88 willthechill dmake process is hung for some reason in the VM
13:20 bulk88 you can login and see the process tree on the screen
13:20 bulk88 C:\strawberry\perl\bin\perl.exe  -Mblib=C:\projects\rperl\blib\lib C:\projects\rperl\blib\lib/RPerl/Test/Expression/program_06_good.pl
13:20 bulk88 calls dmake in a _Inline dir
13:21 bulk88 will, I tried a VC 2013 build, 09.t is failing due to integer sign problems
13:23 willthechill going to sleep now for a few hrs, talk after
15:40 travis-ci perl11/cperl#1239 (master - 29d9567 : Matthew Horsfall): The build passed. https://travis-ci.org/perl11/cperl/builds/140820530
17:27 willthechill joined #perl11
17:29 willthechill bulk88: I'm awake, how about you?  :-)
17:34 willthechill okay I see the github issue about the integer issue with bitwise negation
18:01 willthechill oh I see, the github issue is for VC2013 compiler, whereas the appveyor hang is due to strawberry...
18:01 willthechill 2 different issues
19:11 willthechill bulk88: I have replied to your github issue about VC2013 bitwise negation integer mismatch, w/ a request for more info
19:12 willthechill I do not know how to proceed on the appveyor dmake hanging issue, please advise?
19:24 willthechill bulk88: github received, thanks!
19:25 bulk88 I'll have to try gmake instead of dmake ont he appveyor VM and see if it makes a differece
19:25 bulk88 it could be a buggy dmake  from an "old" perl (5.20)
19:25 willthechill ah okay gotcha
19:26 willthechill I literally know nothing about windows, I've never even heard of dmake or gmake!  :P
19:26 willthechill you da man, haha!  :D
19:26 willthechill I am thinking about the integer issue now
19:26 willthechill the output looks good for the non-overflowed values of 0, 1, and 5
19:26 willthechill and the overflowing values look consistent, so that is also good
19:28 willthechill I assume this integer issue is the same as what I already have listed in my todo.txt file:
19:28 willthechill https://github.com/wbraswell/rperl/blob/master/docs/todo.txt#L202-L211
19:28 willthechill and which is directly related to the number (float) data type issue, immediately following in the todo.txt file
19:31 willthechill what I need to do is add the ability for RPerl to check what integer (and float) native types that Perl was originally compiled with, and then utilize those types for both the tests (which is hurting us here) and for the compiled C++ output code
19:32 willthechill there will also be an RPerl config setting to manually override the C++ output types, if you don't want it to match the types used in the original Perl compile
19:33 willthechill what I do NOT know is, what are the logical combinations of all those config vars like $Config{ivtype} and friends, so that we actually do the right thing?  there seems to be at least 8 config vars related to integer size, and another 5 for float size???
19:33 willthechill obviously I don't want to start writing too much new code w/out actually knowing what I'm dealing with here...
19:47 bulk88 strawbeerry uses 64 bit IVs on 32, VC perl uses 32 bit IVs on 32 by default
19:48 bulk88 VC perl is capabale of 64 bit IVs on 32 but I'd have to recompile my perl (not the worst thing in the world)
19:48 willthechill good to know, although I don't want to hard-code those values
19:49 willthechill I think what we need to do is first test for $Config{ivtype}
19:49 willthechill then it will say something like "long"
19:49 willthechill then test $Config{longsize}
19:49 willthechill based on what the output of the $Config{ivtype} is
19:50 willthechill THEN based on the output of $Config{longsize} we make the decision
19:51 willthechill and that decision is at least used in the tests
19:51 willthechill to make sure the test suite passes
19:52 bulk88 ok 106 - require RPerl::Algorithm::Sort::Bubble;
19:52 bulk88 ok 107 - require RPerl::Algorithm::Inefficient;
19:52 bulk88 not ok 108 - RPerl::Algorithm::Sort::Bubble::cpp_load() lives
19:52 bulk88 #   Failed test 'RPerl::Algorithm::Sort::Bubble::cpp_load() lives'
19:52 bulk88 #   at t/10_precompiled_oo_inherit.t line 232.
19:52 bulk88 # died: Can't use an undefined value as a subroutine reference at t/10_precompiled_oo_inherit.t line 232.
19:52 bulk88 I am doing this
19:52 bulk88 C:\sources\rperl>perl -Ilib -e"use RPerl::Algorithm::Sort::Bubble; RPerl::Algori
19:52 bulk88 thm::Sort::Bubble::cpp_load()"
19:52 bulk88 Undefined subroutine &RPerl::Algorithm::Sort::Bubble::cpp_load called at -e line 1.
19:52 bulk88 C:\sources\rperl>
19:52 bulk88 but I am not getting any CC output
19:52 willthechill okay hang on let me check
19:53 bulk88 nvm I had to delete _inline
19:53 willthechill because you are in PERLOPS_PERLTYPES mode
19:53 willthechill cpp_load() only exists in Bubble.pmc not Bubble.pm
19:53 willthechill gotta be in CPPOPS_CPPTYPES mode to get access to cpp_load()
19:54 willthechill by which I mean there needs to be a Bubble.pmc file and Bubble.cpp and Bubble.h in place
19:54 bulk88 http://paste.scsys.co.uk/524845
19:55 bulk88 http://paste.scsys.co.uk/524846
19:55 willthechill if cpp_load() is not defined then you are in PERLOPS_PERLTYPES mode
19:56 willthechill this explicitly tells you that you are stuck in PERLOPS mode, from your 2nd pastebin:
19:56 willthechill #   Failed test 'main::RPerl__DataType__Integer__MODE_ID() ops returns CPP'
19:56 willthechill #   at t/10_precompiled_oo_inherit.t line 245.
19:56 willthechill #          got: 'PERL'
19:56 willthechill #     expected: 'CPP'
19:56 willthechill those 4 lines are saying "your MODE is set to PERL instead of CPP"
19:57 bulk88 so why am I in PERL mode? what CC compile attempt fialed?
19:57 bulk88 *failed
19:57 willthechill thinking
19:58 bulk88 http://paste.scsys.co.uk/524847 full console of 10.t
19:58 willthechill ls -l lib/RPerl/Algorithm/Sort
19:58 willthechill what files are in your Sort/ directory now?
20:00 willthechill something went wrong somewhere in tests 90 - 107, which is where the manually-compiled files are copied around to manually go from PERLOPS_PERLTYPES to CPPOPS_*TYPES mode(s)
20:01 willthechill *I assume something went wrong
20:01 willthechill that is my current theory  :)
20:01 willthechill so maybe Windows doesn't like the file copying commands
20:02 willthechill so again, what files are in the  lib/RPerl/Algorithm/Sort/ directory?
20:02 willthechill is your directory structure read-only or something like that?
20:07 bulk88 http://paste.scsys.co.uk/524848
20:09 willthechill you have no Bubble.pmc or Bubble.cpp or Bubble.h
20:09 bulk88 the tests are cleaning up the dir
20:09 willthechill oh true
20:09 willthechill put a breakpoint right after the failing test
20:09 willthechill then do another dir listing
20:09 bulk88 # DEV NOTE: must call long form of cpp_load() to bypass mysterious 'undefined subroutine' symtab weirdness
20:09 bulk88 # ONLY 2 MODULES
20:09 bulk88 #lives_ok( sub { RPerl::Algorithm::Sort::Bubble::cpp_load(); }, q{RPerl::Algorithm::Sort::Bubble::cpp_load() lives} );
20:09 bulk88 lives_ok( sub { &{ $RPerl::Algorithm::Sort::Bubble::{'cpp_load'} }(); }, q{RPerl::Algorithm::Sort::Bubble::cpp_load() lives} );    # long form
20:09 bulk88 lives_ok( sub { &{ $RPerl::Algorithm::Inefficient::{'cpp_load'} }(); },  q{RPerl::Algorithm::Inefficient::cpp_load() lives} );     # long form
20:09 willthechill I still think the file copying commands are not working
20:10 bulk88 http://paste.scsys.co.uk/524849
20:10 willthechill yes there was unexplained symtab weirdness but that should have been fixed as you see there
20:10 willthechill with the long form commands
20:10 bulk88 I got the bubble.pmc
20:10 bulk88 and bubble cpp
20:10 willthechill okay NOW try the manual command
20:10 willthechill use ...Bubble; ...Bubble::cpp_load()
20:11 willthechill so I was wrong, the file copying commands are working
20:11 willthechill now we need to see the compile error(s)
20:14 bulk88 http://paste.scsys.co.uk/524851 there is none as far as I can tell
20:15 willthechill okay that's a little weird
20:15 willthechill hang on
20:15 bulk88 http://paste.scsys.co.uk/524852
20:16 bulk88 that is a list of every xsub that DLL exposes to perl interp
20:16 willthechill cpp_load() is not an xsub
20:16 willthechill it is a normal perl subroutine in Bubble.pmc
20:17 willthechill throw a debug breakpoint of some kind in the very top of Bubble.pmc and see if it is actually getting loaded when you do 'use ...Bubble;'
20:17 willthechill or if it is somehow including Bubble.pm instead of Bubble.pmc
20:17 willthechill if it only finds Bubble.pm then cpp_load() will be undefined
20:18 willthechill OH WAIT is it because you still have pmc files manually disabled in your Perl core?
20:19 bulk88 let me check
20:20 bulk88 yes, PMC files are disabled
20:20 willthechill HAHA your fault this time!  :P
20:20 willthechill ;)
20:20 bulk88 Characteristics of this binary (from libperl):
20:20 bulk88 Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY
20:20 bulk88 PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DISABLE_PMC
20:20 willthechill 30 lashes with a wet noodle!
20:20 bulk88 do I get to eat it afterwards?
20:20 willthechill eww okay I guess so
20:20 willthechill :P
20:21 bulk88 im going to recompile my VC perl to have .pmc and 64 bit IVs (maybe 09.t will be fixed)
20:21 willthechill yes that should fix t/09 for you
20:21 willthechill HOWEVER it does not fix it for other people
20:22 willthechill can you please keep a copy of your current perl which has 32-bit ints?
20:22 willthechill we will want to use it for testing...
20:29 bulk88 ill recompile with 32 bit IVs when 10.t is diagnosed/fixed/passes
20:30 willthechill okay
20:32 willthechill I'll go ahead and start working on the integer size fix so hopefully we can get back to it later today or tonight if we are lucky  :)
23:41 willthechill bulk88: with my latest push to github just now, we should pass t/09 on both 32-bit as well as 64-bit integer machines
23:41 willthechill I'll be away for a few hours
23:50 travis-ci RPerl build passed. Will Braswell says 'Types, Enable Integer Size Detection, Part 1'
23:50 travis-ci https://travis-ci.org/wbraswell/rperl/builds/140952234 https://github.com/wbraswell/rperl/compare/3bf6a0b51b26...327c8cf11e4b

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