Perl 6 - the future is here, just unevenly distributed

IRC log for #inline, 2014-12-09

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

All times shown according to UTC.

Time Nick Message
00:46 davido_ hey ingy
00:52 GitHub186 [inline-c-pm] sisyphus comment on issue #31:
01:03 ingy davido_: is your math repo o the inlinemod branch
01:03 ingy ?
02:01 davido__ joined #inline
03:27 davido__ Yes.
03:27 davido__ ingy yes.
04:22 ingy hi
06:40 GitHub186 [inline-c-pm] bulk88 comment on issue #31: > @bulk88 Just run this test on Windows XP.... http://git.io/KHzI4g
06:55 GitHub186 [inline-c-pm] mohawk2 comment on issue #31: `prove -lv test/26fork.t`... http://git.io/XDIcMw
07:26 GitHub8 [inline-c-pm] bulk88 comment on issue #31: process tree... http://git.io/_VfzSw
07:37 GitHub163 [inline-c-pm] mohawk2 comment on issue #31: Nice work. Why is `chcp` hanging? http://git.io/I8tFAQ
07:41 bulk88 mohawk i might not have an answer for 12 hours
07:42 bulk88 procexp hangs when clicking on the cmd.exe that called chcp and the parent of it which is perl.exe makefile.pl
07:42 bulk88 proexp also can't be killed by task man when it hangs unless I kill the cmd.exe chcp process
07:48 bulk88 proc exp uses a kernel driver AFAIK, it might have gotten in a funking state, which means I need to reboot, not prepared to do that ATM, so it might take 12 hours for my next response
08:06 mohawk bulk88, no rush - thanks for doing this! i would try it if i knew how and had XP ;-)
16:26 ingy morning davido__
16:31 davido__ hi ingy
16:31 davido__ :)
16:35 davido__ ingy : Do you mind if we look at the M::P::FS issue in a Pairup? I'd like to demonstrate.
16:53 davido__ just ping / sms me :)
16:54 ingy davido__: sure
16:54 davido__ let me know what time works for you.
16:57 GitHub44 [inline-cog] ingydotnet pushed 1 new commit to build: http://git.io/T-Lsag
16:57 GitHub44 inline-cog/build 445ece4 Ingy döt Net: Add links to sidebar
16:58 davido__ I like the sidebar.
16:58 ingy only works on front page
16:59 davido__ oh yeah.
17:04 daoswald^ingy in the pairup
17:04 daoswald^ingy just got a really strange error
17:05 davido__ ok, just a moment.
17:05 davido__ Ok, I'm there.
17:06 davido__ Yeah, the PERL5OPT thing wasn't working well for me.  I switched to makestub.
17:07 davido__ you're in the inlinemod branch?
17:08 davido__ k
17:08 davido__ haha
17:09 davido__ Yeah, that was what autostub was doing for me too.  makestub gets further.
17:10 ingy that's the weird error
17:11 davido__ I didn't see that one before.
17:11 ingy me neither
17:11 ingy I don't get it on my local machine
17:11 davido__ Let's unset PERL5OPT and generate a stub file instead.
17:12 davido__ just for now.
17:12 davido__ (I was getting other weirdness with PERL5OPT; cpanm was even failing to run)
17:13 ingy we can try
17:16 davido__ I recently updated deps. to latest EUMM, etc.
17:17 davido__ tests should take a couple mins.  the grammar tests and namespace tests are slow.
17:17 davido__ I intend to get to that eventually.
17:18 ingy that's about what I got
17:18 ingy but with autostub
17:19 davido__ ok...  So look at t/01can_subs.t
17:21 ingy Where is blib/Inline?
17:21 ingy maybe inline-module not up to dat
17:22 davido__ The other thing is that there's a warning issued out of Inline::CPP.
17:22 davido__ on first compile.
17:22 davido__ the warning gives an indication that there's some stuff missing out of the ISLM structure.
17:22 davido__ I think.
17:23 davido__ :)
17:25 ingy what was wrong with data section?
17:25 ingy just asking
17:25 davido__ Oh, I actually preferred it...
17:26 davido__ but was trying to eliminate differences between how I did things and how you did.
17:27 davido__ I'd prefer keeping the C++ code in __DATA__ ... __CPP__
17:28 davido__ If you start with master, but pull in changes to t/... that would be a clean basis for a new alt branch.
17:28 ingy let's turn this into Alt-M-P-FS-Inline
17:29 davido__ sure.
17:29 davido__ are you basing it on inlinemod or master branch?
17:29 davido__ actually inlinemod is probably fine to start
17:29 daoswald^ingy basing on inlinemod^
17:30 davido__ yeah, fine.
17:30 davido__ I thought I commented out the END block.
17:31 davido__ no, END {
17:31 davido__ we can comment that out. will be irrelevant.
17:34 davido__ hm...
17:34 davido__ No underscore.
17:34 davido__ NOCLEAN
17:34 davido__ and can be lc.
17:35 davido__ should be => 0
17:36 davido__ not => 1
17:36 davido__ there's that warning.
17:36 davido__ on 'make'
17:43 davido__ What's strange to me is why the {ILSM}{parser}{data} would be different under Inline::Module than under the plain vanilla Inline::CPP version
17:45 ingy no rtype?
17:45 davido__ yeah. but um... :)
17:46 davido__ It can't be the grammar parsing, because everything's fine under M::P::FS v0.18.
17:48 ingy weird
17:48 davido__ yeah.
17:49 ingy well now should be easy to fix :)
17:49 davido__ I spent a day on it a couple weeks ago before we had the autostub and makestub.
17:51 davido__ I'm not fond of the Perl::Critic stuff.  I did that a couple years ago when I was trying to establish that Inline::CPP was fit for use. :)
17:52 davido__ fixing this will be progress :)
17:52 ingy indeed
18:00 ingy what's _INSTALL_?
18:00 davido__ hm, not sure.
18:01 davido__ was that eumm or the outdated inline::mm?
18:04 davido__ that was the Inline::MM -generated makefile, right?
18:04 davido__ (Makefile.PL for v0.18 uses Inline::MakeMaker
18:04 ingy ?
18:04 davido__ You were looking at the Makefile generated by M::P::FS version 0.18.
18:04 davido__ Makefile.PL for v0.18 uses Inline::MakeMaker, not EUMM
18:05 ingy yes
18:05 davido__ but when I converted to Inline::Module, I changed back to EU::MM.
18:39 davido__ back
18:43 GitHub108 [inline-c-pm] bulk88 comment on issue #31: I have a suspicion the freeze is because of the ".lock" file next to config-MSWin32-x86-multi-thread-5.021006 file and "build" dir. I thought I debugged a similar/identical kernel hang a few weeks ago but I can't find it on google. http://www.perlmonks.org/?node_id=1008652 ... http://git.io/XFjQzw
18:58 davido__ ah, that's a more reasonable screen size.
18:58 ingy :)
19:01 davido__ do you have an idea of where it's coming from?
19:01 ingy maybe
19:02 ingy when you have 2 inputs producing 2 different outputs
19:02 ingy you first make sure the inputs are really the same
19:02 davido__ yeah.
19:02 ingy not the C++ code
19:03 ingy but the other stuff and the flow
19:03 davido__ right.
19:03 davido__ Would hate to find something simple like a hard-coded Inline::C ilsm somewhere in I::M. ;)
19:04 davido__ but we're not getting C compiler failures, so that can be ruled out :)
19:13 ingy let's get both branches going through same stuff
19:14 ingy we should get it quick
19:14 davido__ ok.
19:15 davido__ This is a pretty good test module, eh? :)
19:18 ingy aye :)
19:18 ingy I was wanting to convert YAML::XS today
19:18 ingy but this is better for first
19:18 davido__ Yeah.  Also we're going to find List::BinarySearch a very worthwhile exercise.
19:19 ingy ok
19:19 davido__ not because it's heavily used, but because it uses things that are important to XS programmers.
19:22 davido__ out for 15.
19:33 davido__ back
19:35 ingy cool
20:02 ingy ok so the parser doesn't even look the same
20:02 davido__ that's not pretty: #include <iostream> twice.
20:02 ingy both are PRD
20:02 davido__ Hm.... how could just changing from I::MM to I::M change the parse output.
20:07 ingy well Inline::Module is obviously messing up
20:08 davido__ :)
20:08 davido__ hm..... 'using (in import)... is that propagating into Inline::CPP?
20:08 davido__ (importer)
20:14 ingy ok so only coming through once
20:14 ingy that's good to know
20:14 davido__ :)
20:14 ingy we just need to get parser to match
20:15 davido__ checking something...
20:16 davido__ no revelations. ;)
20:20 davido__ See the name difference?
20:20 ingy yeah, that's right
20:20 davido__ ok
20:21 davido__ that was one thing I was trying to chase down a few days ago, but if it's right, it's right. :)
20:22 ingy what's OVERRIDDEN?
20:22 davido__ hm, no idea.
20:22 davido__ looking at IL::CPP source now.
20:22 davido__ word doesn't even appear in the source.
20:24 ingy well whatever it is that's it
20:24 ingy o wait
20:24 ingy sorry nm
20:24 davido__ :)
20:24 ingy got my sides miced up
20:25 davido__ left is the good side.
20:25 davido__ right?
20:25 ingy right side is master
20:25 davido__ ok.
20:25 davido__ oh yeah
20:27 ingy brb
20:27 davido__ k
20:31 ingy I think OVERRIDDEN is just a result of USING
20:31 ingy which we need anyway
20:31 davido__ Ok, and nothing to worry about?
20:31 ingy might be
20:32 davido__ can we walk through the order of execution at startup? Maybe there's something missed.
20:33 ingy I want to see where the parser is created
20:33 davido__ yeah.
20:34 davido__ It's probably that Inline::CPP is sensitive to when it gains control.  importer is requiring Inline, and then doing Inline->import.  But maybe it should be doing Inline::CPP->import
20:34 davido__ that's not right either. but...
20:34 ingy ah I get it now
20:34 davido__ Inline::CPP probably isn't expecting Inline to have had import called already.
20:35 davido__ lol, I hate the "I currently only know..." message.
20:35 ingy yeah :\
20:36 ingy file an issue
20:36 davido__ k
20:37 davido__ still got that warning on the left.
20:38 ingy we never get to Inline::CPP::get_parser with I:M
20:38 davido__ Yeah.  It's probably because Inline->import(....) in I::M
20:38 davido__ Inline::CPP expects to be in control.
20:39 davido__ and then to pass control back to Inline::C/Inline when it's done.
20:41 davido__ yeah, we really want 42, then 43
20:41 ingy nod
20:42 davido__ I::CPP is probably the one that's bass ackwards.
20:55 ingy trying to figure out the right thing to do here
20:56 davido__ just a sec.. ..looking at i::CPP source again.
20:58 davido__ :(
20:59 ingy I see what it is I think
20:59 davido__ what?
21:00 ingy Inline::CPP doesn't expect USING to override get_parser
21:00 davido__ :)
21:00 ingy and it's not really using regular OO
21:00 davido__ yeah. it's an ugly tight coupling.
21:01 ingy where is Inline::CPP::Grammar::grammar defined?
21:01 davido__ lib/Inline/CPP/Grammar.pm
21:02 ingy does Inline::CPP only use the RecDescent grammar?
21:02 davido__ Yes.
21:03 ingy well that's um
21:03 davido__ :)
21:03 ingy does it reuse the the Inline::C grammar?
21:04 ingy extend it?
21:04 davido__ No.
21:04 davido__ I don't believe so.
21:05 ingy OK I have the easy solution
21:05 davido__ that would be nice. :)
21:07 davido__ oh, i think i know what's going to happen :)
21:08 davido__ : ()
21:08 davido__ yeah.
21:13 davido__ wow!
21:16 ingy ok, well at this point we have a non-negotiable PRD requirement for I:CPP based I:M modules
21:16 ingy well
21:16 davido__ that's not optimal.
21:16 ingy actually we can likely bundle PRD in inc too
21:16 ingy so maybe ok for now
21:16 davido__ yeah.  and it *is* working.
21:17 ingy let's work on that next time
21:17 davido__ but what I thought you were getting at is that if we were to add a different parser to Inline::CPP, it would also not be available to I::M.
21:17 ingy maybe tonight
21:17 ingy that needs to be fixed too
21:17 davido__ Since using is ignored unless Inline::C.
21:18 davido__ I could bundle a fall-back PRD under Inline::CPP
21:20 davido__ yeah.  I::CPP needs a bit of time under the magnifying glass.
21:20 GitHub141 [inline-module-pm] ingydotnet opened issue #12: Inline::CPP needs to bundle PRD in inc http://git.io/wuP_Bg
21:20 ingy well we can make I:M work around it
21:20 ingy for now
21:20 davido__ yeah.
21:21 ingy I need to shift gears. you around later?
21:21 davido__ I may have a problem tonight.

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