Camelia, the Perl 6 bug

IRC log for #parrot, 2010-03-10

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 japhb Which actor is #10 again?
00:00 tewk Seen line 118 before in src/pmc/sub.c - can't continue at tools/build/c2str.pl line 146, <$IN> line 407. ???
00:01 tewk All I did was add a line to the bottom of src/vtable.tbl.
00:02 chromatic Tennant, get it?
00:02 tewk oops, I figured it out
00:09 Whiteknight chromatic: TT #1505 is knocked out, pending tests. I'm ready to hit #389 like the fist of an angry god
00:09 japhb Whiteknight: "But which god?  And what was he doing in Heathrow airport ...?"
00:11 * Coke finally has a working OS X system, and guessing he'll have to resurrect the macport.
00:11 Coke *guesses
00:13 * Coke also ponders watching all the doctor who he can on netflix .
00:15 * japhb can't wait for the next season ... though I'm dubious about the next doctor
00:16 payload joined #parrot
00:16 chromatic Whiteknight, if you're looking for something to do, the fix_hll_mmd branch probably needs attention too.
00:16 japhb Anyone know if BBC America is delayed (by a season or more) from BBC proper?
00:16 chromatic I'm completely stuck on that one for the time being.
00:16 kid51 joined #parrot
00:17 Whiteknight chromatic, sure, whichever. can you bring me up to speed on the purpose of that branch?
00:17 chromatic It's to fix subclassing of intrinsic PMCs and MMD.
00:18 Whiteknight ah, sweet
00:18 chromatic TT #784, #1040, etc.
00:18 chromatic I think there's a problem with the distance calculations with a PMCProxy in MRO, but I'm not entirely sure.
00:19 Whiteknight oh, nothing's been done here yet
00:19 chromatic Dispatch from intrinsic MMD within PMCs also seems to Do the Wrong Thing, because types aren't necessarily isomorphic.
00:19 Whiteknight ...but the tickets have test cases, so we're in business
00:19 chromatic Also, have some commits.
00:20 Whiteknight nice
00:22 lucian joined #parrot
00:23 lichtkind thanks for cooperation @parrot i'll be back :)
00:23 lichtkind good night
00:32 lucian allison: i'd like to implement dir() in pynie. where should I start? (already looking at builtins.pir)
00:33 allison lucian: yes, add a function there
00:34 Coke someone with git-svn want to merge trunk into the pcc branch?
00:34 lucian allison: ok, wasn't sure what's generated and what isn't
00:34 Coke (if not, I can do it the hard way. =-)
00:35 Whiteknight chromatic: that new test passes in branch
00:35 Whiteknight ok 46 - Integer subclass and MMD - TT \#784
00:36 allison Coke: I tend to merge the branch into a fresh branch from trunk, rather than the other way around
00:36 allison Coke: are there great new features in trunk that we need in the branch?
00:36 Whiteknight yes, I've learned that merging into a branch from trubk can be evil
00:36 Coke ok. there's no point in fixing an issue with corevm, I think, until it's updated. Also, I cannot reproduce any problems in that branch.
00:36 dalek parrot: r44834 | chromatic++ | branches/fix_hll_mmd/lib/P​arrot/Pmc2c/PMC/Object.pm:
00:36 Austin Q: Kakapo is a library. Kakapo has a set of dependency queues for managing the startup processing of interdependent modules. What is the class name that describes that service - collecting, ordering, and processing the dependencies?
00:36 dalek parrot: [lib] Allowed Objects inheriting from PMCProxy to pass through the proxied PMC
00:36 dalek parrot: to MMD math vtables, if they exist.
00:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44834/
00:36 dalek parrot: r44835 | chromatic++ | branches/fix_hll_mmd (2 files):
00:36 dalek parrot: [lib] Removed "MMD must obviously take care of this!" from i_* VTABLE entries,
00:36 dalek parrot: especially as the core types *don't* use MMD with them.  This fixes TT #784.
00:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44835/
00:37 dalek parrot: r44836 | chromatic++ | branches/fix_hll_mmd (3 files):
00:37 dalek parrot: Checkpoint.
00:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44836/
00:37 dalek parrot: r44837 | whiteknight++ | trunk/t/oo/vtableoverride.t:
00:37 dalek parrot: tests for TT #1505. The matter is now resolved
00:37 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44837/
00:37 Coke Austin: "Makefile"
00:37 allison Coke: well, that's a good reason :)
00:37 plobsing hi #parrot
00:37 Austin Coke: :)
00:37 Whiteknight Austin: rhetorical question?
00:37 purl somebody said rhetorical question was rhetorical.
00:37 Coke allison: I can't reproduce the bug folks were talkinga bout, though, so...
00:37 allison Coke: which bugs?
00:37 Coke "corevm builds PGE"
00:38 Austin Whiteknight: No, I'm looking to refactor the dq processing out to a separate class. I need a name, but my enormous vocabulary is failing me.
00:38 allison Coke: so, what happens when you run 'make corevm' on the branch?
00:38 Coke ... it builds.
00:38 Coke and I can't find PGE.pbc.
00:38 allison and, no errors?
00:38 purl You mean no error *messages*
00:38 Coke I assume that the make would have bombed out if so.
00:38 plobsing Whiteknight: just read over #ps log. VTABLE_init_int is probably a good idea, I don't really understand why you need to throw away the Integer PMC wrapper.
00:39 Coke I'll retry on my a clean checkout on os x just to see.
00:39 allison Coke: hmmm... it was bombing for me as recently as this afternoon...
00:39 Coke i'll retry.
00:40 zostay joined #parrot
00:40 tewk init_int hits the mailing list
00:41 Coke allison: pcc_hackathon_6Mar10 ?
00:41 tewk only 8 new opcodes new_p,s,pc,sc_i,ic
00:41 tewk :)
00:42 allison Coke: it does include the $(GEN_LIBRARY) in corevm, which builds PGE libraries
00:42 allison Coke: that's the one
00:42 Coke there is a PGE.pir that doesn't actually rely on the PGE compiler being built, as I recall.
00:42 Coke checking...
00:44 kurahaupo joined #parrot
00:44 Coke should corevm include the library at all?
00:45 Whiteknight no
00:45 allison Coke: it shouldn't include much of any core libraries
00:45 allison Coke: PIR libraries, I mean
00:45 Coke ... there's the failure.
00:46 Coke probably needed a realclean.
00:46 allison Coke: just the VM itself and the absolute minimum of extras to get it to run
00:46 Coke dynpmc? dynoplibs?
00:47 Whiteknight tewk++
00:47 allison Coke: debatable, but would be okay if needed for core tests
00:47 Coke we're defining what core means. =-)
00:47 allison Coke: the goal is to be able to run a core set of tests on the vm
00:48 Coke ok. dynops and dynpmcs out, then.
00:48 allison Coke: okay, the goal is to be able to run *a* set of tests on the VM, even if there's something wrong in higher functions
00:49 allison Coke: to help figure out what's wrong
00:51 allison Coke: ah, it looks like the --core-tests argument to t/harness is unchanged
00:53 Coke alright. I'll just pull stuff out until it works, then. =)
00:55 Coke getting ranlib: file: blib/lib/libparrot.a(win32.o) has no symbols
00:56 bacek_at_work Tcl/Glob.pbc also depends on PGE.pbc
00:56 Coke that can get renamed and move out to plumage.
00:56 Whiteknight chromatic: I think you kicked more butt on that fix_hll_mmd branch than you realize
00:57 Whiteknight all tests, plus the one from TT #784 pass
00:57 abqar joined #parrot
00:57 chromatic There should be several TODOs that still don't.
00:58 Whiteknight oh, which? can you un-todo them so we see what is needed?
00:58 Coke ... untodo them.
00:58 chromatic I'll take a look later tonight.
00:58 lucian there's no make target vim-install in editor/
01:03 cotto do we have a list of hll bugs that need love and eyeballs?
01:10 parthm joined #parrot
01:10 Coke cotto: there's a trac report.
01:13 davidfetter joined #parrot
01:13 Coke http://trac.parrot.org/parrot/report/16
01:13 Coke feel free to ignore the tcl ones for this week.
01:13 Coke lucian: are you sure?
01:13 purl You still have ALL THREE lifelines left!
01:13 Coke "WFM"
01:14 Coke "cd editor && make vim-install" works here.
01:14 Coke s/works/does something/
01:15 cotto Coke, he left
01:15 cotto I was about to ask him the same thing though
01:16 Coke msg lucian "cd editor && make vim-install" works here.
01:16 purl Message for lucian stored.
01:17 theory_ joined #parrot
01:25 Coke ok. corevm now builds in the branch.
01:27 Coke many tests failing in 'coretest' - all the initial ones seem to be real failures.
01:28 Coke doing the same in trunk, so it'll be more obvious why whatever's failing is.
01:28 dalek parrot: r44838 | coke++ | branches/pcc_hackathon_6Mar10/​config/gen/makefiles/root.in:
01:28 dalek parrot: Naive attempt to minimize corevm.
01:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44838/
01:46 dalek parrot: r44839 | cotto++ | branches/ops_pct/config/gen/makefiles/root.in:
01:47 dalek parrot: [makefile] don't remove function-based runcore files
01:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44839/
01:47 dalek parrot: r44840 | whiteknight++ | failed to fetch changeset:
01:47 dalek parrot: merge fix_icc_failures branch. Parrot builds with icc and passes all tests. also, fixed several build warnings
01:47 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44840/
01:48 jimk joined #parrot
01:50 Whiteknight bubaflub: ping
01:51 dukeleto 'ello
01:56 plobsing arg. tt1015 has made my head explode multiple times!
01:57 plobsing what do you expect to get from "$P0 = getinterp \n $S0 = freeze $P0 \n $P1 = thaw $S0"?
01:59 Austin A new thread?
01:59 plobsing nope.
01:59 plobsing you get the current interpreter.
01:59 Austin Hey, it's what *I* expect...
01:59 Austin Hmm...
01:59 Austin Something to be said for that, too, I guess.
02:00 plobsing if you thaw any ParrotInterpreter, you get the current one. With the state of the frozen one merged ini.
02:00 plobsing s/ini/in/
02:00 Whiteknight ...good?
02:00 * Austin coughs.
02:00 plobsing I can't imagine how that's right from any perspective.
02:01 Austin Wow, that was not _ever_ going to be on my list of suggestions.
02:01 dalek parrot: r44841 | whiteknight++ | trunk/PLATFORMS:
02:01 dalek parrot: update PLATFORMS with icc info
02:01 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44841/
02:02 Whiteknight plobsing: are there any tests or code that rely on that behavior?
02:02 Whiteknight may be a necessary quirk
02:02 plobsing Whiteknight: yes. its necessary.
02:02 plobsing it was hijacked to mark (and automatically load) extensions required by a PBC
02:03 plobsing every PBC has the interpreter used to compile it as the first constant
02:03 Austin Heh.
02:03 plobsing which means I can hand craft a PBC to load libmalicious and you'd have a pretty hard time finding out that I did
02:03 * Austin is laughing on the inside.
02:05 plobsing also means I can't really make a parrot program that compiles other that don't include the compiler
02:05 plobsing s/other/other parrot programs/
02:06 Austin What problem are you trying to solve, here, peter?
02:06 plobsing trying to solve tt1015 on the assumption that clone(x) = thaw(freeze(x))
02:07 Austin Ah.
02:07 plobsing and finding some major fail along the way
02:07 Whiteknight damn fart crap
02:07 plobsing next fail: is the name a property of a class? If I clone a class, should it be anonymous?
02:07 Austin I'm a little leery of the whole freeze/thaw thing.
02:07 Whiteknight I hate this kind of shit
02:07 Austin I don't know what it is, and I don't interact with it.
02:09 kurahaupo joined #parrot
02:09 Whiteknight plobsing: I still dont understand the utility of sticking an Interpreter in the PBC if thawing it just returns the current interp
02:09 plobsing Whiteknight: it merges the state of the frozen interpreter
02:09 Austin Whiteknight: thawing the interp is basically resuming it.
02:09 plobsing so if you'd loaded dynlibs, they would get loaded
02:09 Austin ^^
02:10 Whiteknight ah, better explanation. I get it
02:10 Austin So you start a "blank" interp, then thaw your "configured" one, and you're doing whatever you wanted...
02:10 plobsing I think that dynext requirements should be an explicit and separate part of the PBC, not squirelled away in a frozen PMC.
02:11 plobsing helps with introspection
02:11 Austin The business about pbcs merging interps to get dynops or whatever is totally bogus.
02:11 Austin +1
02:11 purl 1
02:11 Whiteknight that still doesn't make a ton of sense. why would thaw do the merging?
02:11 Austin That's what :load / :init is for.
02:11 Whiteknight thaw the interp and then merge it
02:11 Austin whiteknight: Thaw does the merge because that's a good way to do ... something they wanted to do 10 years ago.
02:12 Austin And then they noticed they could do clever dynaload stuff with it...
02:12 plobsing Imma take it out and see if everything breaks.
02:12 Austin And now they have a chain of franchises across the world...
02:13 Whiteknight plobsing: If thaw can do the right thing, and we can add a new func or method to merge, I think that would be best
02:14 plobsing Whiteknight: OK, I'll see what I can do.
02:15 plobsing meanwhile, I have more issues on the queue.
02:15 plobsing Is the name of a class the property of the class? same for subs?
02:16 Austin That's one for the list, I think.
02:16 Austin Ask parrot-dev
02:16 plobsing OK. Will do.
02:16 Austin I'd think the clone would get the same name, but would not be "the" class/sub, linked to the namespace, etc.
02:17 plobsing But then you'd have identically named classes/subs which were different. That makes my head hurt.
02:17 Austin Likewise, a cloned method would not be "the" method linked by the class. But some of the brahmins may have a better idea.
02:17 Whiteknight urg
02:18 Whiteknight it's amazing parrot works at all when I hear this stuff
02:18 Austin "Do the simplest thing that can possibly work."
02:18 Austin "Then refactor."
02:19 plobsing It runs on the sanity of developers.
02:19 Austin Heh
02:19 Austin plobsing++
02:23 Austin Whiteknight: "ComponentMarshaller"
02:23 tewk I'm about to add a new vtable entry, I assume I need to invalidate the bytecode right?
02:23 Whiteknight nice
02:24 Austin tewk: Only if there's going to be a number assigned to it.
02:25 tewk Well I had to make realclean
02:25 dalek tracwiki: v49 | Austin_Hastings++ | ParrotQuotes
02:25 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=49&amp;action=diff
02:30 cotto tewk, I don't think a new VTABLE function has any effect on pbc compatibility
02:30 cotto you'd need to rebuild the PMCs but bytecode wouldn't care
02:30 tewk cotto, yeah I think your right.
02:31 * cotto thinks his right too
02:32 tewk I'm lazy what can I say your -> you're
02:33 cotto It's my second favorite pet peeve.
02:34 cotto I knit little sweaters for it and take it out for a walk twice a day.
02:34 Coke cotto: I think you're wrong.
02:34 Coke ... but given how often we break pbc compatibility, do we care?
02:34 cotto about pbc compatibility?
02:36 cotto easy fix: I'll remove cpu_ret and for sure break PBC_COMPAT so it'll be a moot point.
02:36 dalek parrot: r44842 | cotto++ | branches/ops_pct (2 files):
02:36 dalek parrot: [opsc] add bootstrap-ops and bootstrap-ops-test makefile targets, which attempt to build and test parrot with a opsc-generated ops
02:36 dalek parrot: also, fix pct's makefile to depend on pbc_merge explicitly
02:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44842/
02:36 dalek parrot: r44843 | whiteknight++ | branches/fix_icc_failures:
02:36 dalek parrot: branch already merged to trunk
02:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44843/
02:36 dalek parrot: r44844 | tewk++ | trunk (4 files):
02:36 dalek parrot: VTABLE_init_int
02:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44844/
02:37 cotto any objections?
02:37 cotto good
02:39 Whiteknight include/parrot/vtable.h is built from src/vtable.tbl at config time
02:40 Whiteknight hence the need to reconfigure
02:40 Coke ... for now.
02:40 Coke (one of those thigns that can probably be moved into a normal build step.)
02:44 tewk Whiteknight, ahh, that makes sense
02:45 Coke 'make corevm' functional in trunk and branch. does less in trunk, branch will need to catch up.
02:46 tewk w
02:47 dalek TT #1488 closed by whiteknight++: fix test suite when building with ICC
02:52 cotto Are there any real objections to removing cpu_ret?
02:52 cotto istr that it's a jit leftover.  It's definitely not used anywhere in core.
02:52 Whiteknight kill it
02:53 cotto done
02:53 dalek parrot: r44845 | coke++ | trunk/config/gen/makefiles/root.in:
02:54 dalek parrot: Reduce corevm build. coretest still passes.
02:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44845/
02:54 dalek parrot: r44846 | cotto++ | trunk (8 files):
02:54 dalek parrot: [ops] remove cpu_ret op
02:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44846/
02:54 Whiteknight okay, beddy-bye time
02:54 Whiteknight later
02:56 kid51 Any branches that need a smolder?
03:04 parthm left #parrot
03:32 snarkyboojum joined #parrot
03:35 nopaste joined #parrot
03:35 TonyC joined #parrot
03:42 janus joined #parrot
03:58 cotto Is there a character class for CCLASS_GRAPHICAL in nqp-rx?
03:59 cotto or something that'll let me refer to all non-whitespace characters without enumerating them?
03:59 Austin Yeah.
03:59 Austin Lemme look
04:00 Austin Graphical = 128
04:00 cotto how do I use that in a grammar
04:00 cotto ?
04:01 Austin What do you get when you cross an elephant with a rhinocerous?
04:02 cotto ...
04:02 Austin Elefino
04:03 Austin Pm does some cclass stuff explicitly in pir in $_RX/src/cheats/hll-grammar.pir
04:03 Austin Maybe you have to write a method?
04:03 Austin (What is it you want to do?)
04:04 cotto as part of a grammar, define words to be a contiguous sequence of CCLASS_GRAPHICAL characters
04:04 cotto There's a 'graph' method on Regex;Cursor but I don't know how I'd use that in a grammar.
04:04 Austin That's pretty abstract.
04:05 Austin Is that new? I don't have graph
04:06 Austin Ahh, cursor-builtins
04:06 cotto It's only in 2 places in the nqp-rx source but I wouldn't expect it to be very new.
04:06 cotto yeah
04:06 JimmyZ joined #parrot
04:06 Austin Hell, it looks like you just say <graph>
04:07 Austin Yeah, it's comparable to ident.
04:07 * cotto tries
04:08 Austin I'm wrong. It's not like ident.
04:08 Austin Ident has a built-in +, while the cclass methods don't. You need to say + yourself.
04:08 Austin <graph>+
04:09 Austin Please note that doing what you're doing may very well break the implicit assumptions in the whitespace processing code.
04:10 Austin You'll want to define your "word" to be a token, and either use it only in limited circumstances, or always use it as the lowest-level thing.
04:11 cotto That's how I'll be using it.
04:12 Austin Okay. The default whitespace rule relies on the <ww> rule, which is defined in terms of "word" characters - \w - so you should maybe redefine that, too.
04:12 cotto There's a non-default <ws> rule.
04:26 brooksbp joined #parrot
04:32 estrabd joined #parrot
04:33 cotto What's the regex syntax for inline pir?
04:35 Austin gone, it's inline nqp
04:35 Austin which can do inline pir
04:35 moritz but you can use Q:PIR in inline nqp :-)
04:36 cotto ok.  What's it for inline nqp?
04:36 Austin <{
04:36 Austin or <?{
04:37 Austin don't forget you're in the "wrong" namespace
04:39 cotto I got the parse tree.  That'll be good enough to obviate my need for inline somethingorother.
04:43 Andy joined #parrot
04:51 cotto What nqp-rx really needs is a way to warn you when a regex could potentially go into an infinite loop.
04:52 tewk cotto, that feature has a special name, its called the Halting Problem
04:52 moritz tewk: not quite
04:52 cotto If we could get that feature, it'd basically solve half the world's problems.
04:53 cotto I'll go file a bug.
04:53 moritz if you ignore inline code, it can be done quite reliably
04:53 moritz as Perl 5 does it
04:55 tewk moritz, my understanding is that Perl6 grammars can have arbitrary code in them and are thus turing complete.
04:55 moritz tewk: yes; but usually regexes just loop if you quantify a zero-width match
04:55 moritz tewk: and that's something that the regex engine can catch
04:56 moritz and that'w what I meant by "if you ignore inline code"
04:57 tewk Anyways I'll go away and quit being obnoxious. :)
04:59 tuxdna joined #parrot
05:02 baest joined #parrot
05:12 dalek parrot: r44847 | mikehh++ | trunk/src/pmc.c:
05:12 dalek parrot: fix c function docs
05:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44847/
05:12 dalek parrot: r44848 | mikehh++ | trunk/include/parrot/exceptions.h:
05:12 dalek parrot: fix codetest failure - unwrapped macro argument
05:12 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44848/
05:16 mikehh t/pmc/nci.t FAILS (Parse errors: Bad plan.  You planned 71 tests but ran 0) in make corevm/make coretest at r44848 BUT PASSes  make world/make test
05:18 cotto 0 is an atypical number of tests
05:19 mikehh t/pmc/nci.t - Can't use string ("Test::Builder") as a HASH ref while "strict refs" in use at /usr/local/lib/perl5/5.10.1/Test/Builder.pm line 485. (make corevm/make coretest)
05:20 Austin "Note that I have not tested this code, I have merely proven it correct."
05:20 parthm joined #parrot
05:21 baest joined #parrot
05:24 cotto mikehh, that test wfm
05:28 mikehh it works for me after make world BUT not after make realclean/make corevm
05:30 cotto That's suspicious.
05:30 cotto must have something to do with the corevm cleanup earlier today
05:34 mikehh sure, some tests are not available after make corevm - whiuch is one of reasons I test it, but it wasn't catching this before the cleanup
05:34 mikehh which
05:43 mikehh make corevm/make coretest FAILs - t/pmc/nci.t does not run any tests (it PASSes make test) other tests PASS
05:43 mikehh all other tests PASS (pre/post-config, smoke (#32584), fulltest) at r44848 - Ubuntu 9.10 amd64 (gcc with --optimize)
05:46 dalek parrot: r44849 | darbelo++ | trunk/config (2 files):
05:46 dalek parrot: Probe for icc warning flags and place them into @cc_warn@ when icc is detected. They were being hardcoded into @ccflags@ by the linux hints file.
05:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44849/
05:57 cotto clock?
05:57 purl cotto: LAX: Tue 9:57pm PST / CHI: Tue 11:57pm CST / NYC: Wed 12:57am EST / LON: Wed 5:57am GMT / BER: Wed 6:57am CET / IND: Wed 11:27am IST / TOK: Wed 2:57pm JST / SYD: Wed 4:57pm EST /
06:00 snarkyboojum joined #parrot
06:03 parthm left #parrot
06:30 mikehh darbello: after r44849 t/steps/init/hints/linux-01.t fails (post-config tests)
06:31 mikehh sorry
06:31 mikehh darbelo: after r44849 t/steps/init/hints/linux-01.t fails (post-config tests)
07:03 chromatic joined #parrot
07:13 dalek nqp-rx: 2d51ec9 | duff++ | t/nqp/47-fatarrow.t:
07:13 dalek nqp-rx: Add some tests for the fat arrow
07:13 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/2​d51ec961fea5941c9e17cd487bf0138f0398982
07:13 dalek nqp-rx: c441ffc | duff++ | src/NQP/ (2 files):
07:13 dalek nqp-rx: Make NQP understand single quoted strings on the LHS of =>
07:13 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/c​441ffc653572efd82b80e9c0fa4be3aa96dbbd8
07:16 eternaleye joined #parrot
07:17 uniejo joined #parrot
07:20 aukjan joined #parrot
07:21 bacek joined #parrot
07:23 mikehh tewk: r44844 has a compiler warning in src/pmc.c with gcc - fails to build with g++
07:23 mikehh src/pmc.c: In function ‘Parrot_pmc_new_init_int’:
07:23 mikehh src/pmc.c:585: warning: passing argument 3 of ‘classobj->vtable->instantiate’ makes pointer from integer without a cast
07:23 mikehh src/pmc.c:585: note: expected ‘struct PMC *’ but argument is of type ‘INTVAL’
07:24 cotto hio bacek
07:24 bacek aloha cotto
07:24 bacek howizgoin?
07:24 mikehh hi bacek
07:24 cotto surprisingly well
07:25 cotto I'm pretty close to getting most of the subst calls out of opsc.
07:25 bacek hi mikehh
07:26 cotto hopefully you haven't already implemented it. ;)
07:26 bacek cotto, excellent
07:26 bacek nope... I tried to improve grammar but failed epically.
07:26 cotto I'm also starting to not hate nqp.
07:27 mikehh bacek, cotto I got most of the codetest stuff I could fix but a lot of stuff from generated files is still failing - these files should not go through codetest
07:27 bacek nqp is beautiful!
07:28 cotto bacek, I'm starting to see its beauty
07:28 dalek parrot: r44850 | mikehh++ | trunk/src/call/args.c:
07:28 dalek parrot: fix compiler warning
07:28 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44850/
07:28 cotto mikehh, sure.  There should be a simple way to add exceptions to the codingstd tests.
07:29 mikehh src/ops/core_ops.c. include/parrot/oplib/core_ops.h and ext/nqp-rx/src/gen/settings.pm are causing a lot of codetest failures and they shouldn't be tested
07:29 bacek mikehh, indeed. If you can teach codetest to ignore them it will be great.
07:30 mikehh I think it should be something in MANIFEST or MANIFEST.SKIP otr something
07:34 bacek mikehh, lib/Parrot/Distribution.pm
07:37 mikehh bacek: that looks right - I will have to examine it carefully
07:37 bacek mikehh, starting from line 400
07:39 bacek cotto, are you working on '  * Generate something more meaningfull for Ops::Op.body instead of munched string.' from TODO?
07:40 cotto yes
07:40 mikehh bacek: what about the stuff at line 505?
07:40 cotto It's a stupid hack that I'm using to parse the C code, but it's less stupid than what we were doing before
07:40 cotto also, way easier than bothering to write a full C parser
07:41 bacek ok
07:42 bacek Push it as soon as it will do something (even if it's not finished). I can finish it.
07:42 eternaleye joined #parrot
07:42 cotto ok.  I'll need to go to bed soon anyway.
07:42 cotto I'll give it a few more minutes and commit what's there.
07:42 cotto fsvo "a few more minutes"
07:43 dalek nqp-rx: f34ed51 | duff++ |  (3 files):
07:43 dalek nqp-rx: get rid of icky fatarrow2 rule and parse double quoted strings on the LHS of =>
07:43 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/f​34ed51e251c01e7a75286ea703f85d377ca8244
07:46 cotto like now
07:47 bacek :)
07:47 cotto The grammar and actions are done.  I think the only bit that needs work is get_body in Ops::Op, but there may be more.
07:48 cotto also macro_sanity_check in Actions.pm, but that can be implemented whenever one of us feels like it
07:49 bacek cotto, it's great!
07:49 cotto I'm excited to see how fast it is without the substs
07:50 bacek exactly.
07:50 bacek You missed $n variables but I can continue from this point
07:50 cotto Those are handled.
07:51 cotto macro_param
07:51 bacek ah
07:51 bacek my bad
07:51 bacek _I_ missed it
07:51 cotto (naming was tricky.  I should probably revisit it.)
07:51 cotto ;)
07:52 cotto The info you put in the TODO was very helpful.
07:52 bacek I did my best :)
07:53 iblechbot joined #parrot
07:53 cotto clock?
07:53 purl cotto: LAX: Tue 11:53pm PST / CHI: Wed 1:53am CST / NYC: Wed 2:53am EST / LON: Wed 7:53am GMT / BER: Wed 8:53am CET / IND: Wed 1:23pm IST / TOK: Wed 4:53pm JST / SYD: Wed 6:53pm EST /
07:54 bacek got to bed!
07:54 bacek cotto++ # Cracking ops grammar!
07:54 cotto bacek++ #finishing it
07:54 bacek Do we have multis in nqp?
07:54 cotto (going to bed)++
07:55 cotto I don't think so.
07:55 bacek Or I have fall to pir?
07:55 bacek Sigh...
07:55 bacek 02-parse-all-ops passed and it's VERY GOOD THING! :)
07:56 cotto whoops.  I forgot to test that.
07:57 cotto I'm sure it's misparsing the macros with double parentheses
07:58 bacek there is no double parentheses in real ops.
07:58 cotto orly?
07:58 purl YA RLY.
07:58 bacek So we can ignore them safely
07:58 bacek Yes, I checked it on the other day.
07:58 cotto You're right.  There aren't even spaces.
08:00 bacek exactly.
08:00 bacek So.
08:00 bacek GO TO BED
08:00 cotto Fine.
08:00 bacek And have a good night :)
08:00 cotto Good night.
08:00 cotto eof
08:03 dalek parrot: r44851 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops (5 files):
08:03 dalek parrot: [opsc] do most of the work to remove textual substitutions in the op body
08:03 dalek parrot: The build completes but Ops::Op.get_body is incomplete, probably among others.
08:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44851/
09:15 fperrad joined #parrot
09:17 eternaleye joined #parrot
09:20 brooksbp joined #parrot
09:26 AndyA joined #parrot
09:27 iblechbot_ joined #parrot
09:36 riffraff joined #parrot
10:16 estrabd_ joined #parrot
10:20 dalek parrot: r44852 | bacek++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Grammar.pm:
10:21 dalek parrot: Use token/rule instead of 'regex' in Grammar.
10:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44852/
10:21 dalek parrot: r44853 | bacek++ | branches/ops_pct/compilers/opsc/src/builtins.pir:
10:21 dalek parrot: Add say builtin
10:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44853/
10:21 dalek parrot: r44854 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler (2 files):
10:21 dalek parrot: Start generating PAST top-down
10:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44854/
10:21 dalek parrot: r44855 | bacek++ | branches/ops_pct/compilers/ops​c/src/Ops/Compiler/Actions.pm:
10:21 dalek parrot: Resurrect merging on 'inline' chunks
10:21 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44855/
10:34 dalek lua: 91552d9 | fperrad++ | t/lua-TestMore:
10:34 dalek lua: update submodule lua-TestMore
10:34 dalek lua: review: http://github.com/fperrad/lua/commit/91​552d92b1e47f0a0a2c8a69225a4d7e8543f9d4
10:45 estrabd joined #parrot
10:58 tuxdna joined #parrot
11:14 parthm joined #parrot
11:34 aukjan joined #parrot
11:53 estrabd joined #parrot
11:57 iblechbot joined #parrot
12:06 bluescreen joined #parrot
12:26 slavorgn joined #parrot
12:36 aukjan joined #parrot
12:41 parthm left #parrot
12:51 tetragon joined #parrot
13:00 lucian joined #parrot
13:00 whiteknight joined #parrot
13:01 lucian allison: i'm playing around with pynie's dict(). i tried to fork the bitbucket repo, but it didn't work. can you give me access to your bb repo instead?
13:02 lucian Coke: i figured out the make vim-install issue
13:04 Coke darbelo++ # auto::warnings
13:04 Coke lucian: very good.
13:06 whiteknight hahahaha, today's xkcd is hilarious
13:10 lucian whiteknight: i don't get it
13:10 whiteknight sauron gave rings to all the elves and dwarves
13:10 whiteknight he liked them, so he put rings on them
13:10 * whiteknight shakes his butt a little
13:11 lucian whiteknight: right. i still don't find it particularly funny. perhaps my LOTR illiteracy is part of the problem
13:12 whiteknight ah. Well, it's not for everybody
13:13 lucian whiteknight: i've seen the movies and that's about it (my gf loves them)
13:15 payload joined #parrot
13:16 Coke it's comparing the use of magical rings to control them to a wedding ring. through beyonce. I think that's the funniest thing I've seen in weeks. (Of course, I don't get out much.)
13:16 whiteknight And Sauron, the "dark lord" to be all depressed at a dive bar listening to beyonce is the kicker
13:17 riffraff joined #parrot
13:17 fperrad_ joined #parrot
13:19 lucian Coke: right, a tad funnier :)
13:41 allison lucian: odd that forking bitbucket didn't work, perhaps I should create a dedicated user for pynie?
13:42 lucian allison: it's a bb internal server error. they've had issues yesterday and today
13:42 bubaflub joined #parrot
13:43 allison lucian: okay, I'll go look at the bitbucket configs and see what's possible
13:44 lucian allison: ok. you either give me commit access or just wait it out. i can work locally for now
13:45 lucian allison: didn't mean that to sound like a demand :)
13:45 Coke allison: you see the mailing list note about the bzr mirror via launchpad?
13:45 allison Coke: yah, did I send my reply yet?... checking
13:45 Coke I am leaving that to you, as our primary (only?) lp user. =-)
13:46 allison coke: sending
13:46 Coke my corevm changes break anything for anyone in trunk?
13:46 Coke (they seemed fine on my windows box.)
13:46 allison Coke: we don't actually have ownership on that bzr branch
13:46 payload joined #parrot
13:47 * lucian finds :slurpy funny
13:47 allison Coke: apparently I'm now one of 2 lp users. I'm surprised to see anyone using the bzr branch, but happy to help them
13:48 allison lucian: it looks like it's easy enough to grant you write permission on my hg branch of pynie
13:48 atrodo joined #parrot
13:48 allison lucian: what's best practice for hg? to have my personal account as primary, or to create a bitbucket.org/pynie user?
13:49 lucian allison:
13:50 lucian allison: doesn't really matter, attribution is done by the commit header
13:50 lucian allison: so your bb account doesn't matter. you can just use primary
13:50 lucian allison: s/primary/your own personal/
13:51 allison lucian: makes sense
13:51 allison lucian: what's your bitbucket user name?
13:51 allison lucian: lucian1900?
13:51 lucian allison: lucian1900
13:51 allison lucian: done, enjoy
13:51 lucian allison: bitbucket looks in the commit header for your bb email account or stated name
13:52 lucian allison: thanks
13:54 lucian allison: i'm going through dict() calling posibilities. i can't figure out how to introspect params in pir
13:55 allison lucian: from inside the subroutine?
13:56 lucian allison: yep. i want to find out the type of the first argument, for exampel
13:56 allison lucian: from your comment above, you're using slurpy?
13:57 lucian allison: yes
13:58 PerlJam lucian++
13:58 allison lucian: so slurpy bundles all the arguments into a list datatype
13:58 PerlJam allison: I bet you're glad to have some company on pynie  :)
13:59 allison lucian: to check the type of the first element, you pull it out, with something like $P0 = args[0]
13:59 allison then call the 'type_of' operation on it
13:59 dalek rakudo: a705b41 | jonathan++ |  (6 files):
13:59 dalek rakudo: Translate cheating use into NQP and split out need and import. Stubs for various things we'll need (tags, lexical import).
13:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​705b4116d2837d1ee384fc071d29b0669bef6bd
13:59 dalek rakudo: 5d6aba2 | jonathan++ | src/Perl6/Module/VersionDetectionActions.pm:
13:59 lucian allison: right. that returns a strign?
13:59 dalek rakudo: Add some comment to say what a file is for.
13:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​d6aba2d9664b5e0201213738086eb6a3046e492
13:59 dalek rakudo: a11211c | jonathan++ | src/Perl6/ (2 files):
13:59 dalek rakudo: Switch symbol importation to lexical by default; actually load modules during the compile. Probably has quirks, but a step towards what we want.
13:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​11211c19f4766865ad8edb93f4982b35f9ac562
13:59 dalek rakudo: 8d76887 | jonathan++ | src/Perl6/Grammar.pm:
13:59 dalek rakudo: Actually parse a module_name, rather than cheating and parsing a longname, in use.
13:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​d76887311301f8e63c654cc71c1a404ca4fd277
14:00 * lucian slightly hates this keyboard
14:00 allison PerlJam: very much so :)
14:01 allison lucian: $S0 = typeof $P0 will give you the string name
14:01 allison lucian: $P0 = args[0] will return an object
14:01 lucian allison: right, ok. are my googling skills bad today or is PIR documentation lacking?
14:02 allison lucian: google links to pir documentation are pretty bad
14:02 allison lucian: take a look at http://docs.parrot.org/parrot/latest/html/
14:03 allison lucian: particularly "PIR Book"
14:03 lucian allison: thanks
14:10 * lucian likes pir's inline docs
14:16 allison lucian: me too
14:19 bkuhn joined #parrot
14:19 allison Coke: yay! I'm running 'make coretest' on the branch!
14:21 lucian how do people debug pir?
14:22 * lucian shuts up and goes to read the book
14:22 Coke lucian:  depends on what I'm trying to do. there's always "print" or "say", you can add "trace 1" "trace 0" opcodes around a particular branch. There's a debugger, but it's not well cared for.
14:22 lucian Coke: is print more explicit than say? i'd like something like python's repr
14:22 Coke if I'm trying to find a crash, I might run parrot with -t4 (== trace 4) first, that shows sub invocations/returns. then I can add 'trace 1'/'trace 0' inside.
14:23 Coke if you want to dump the guts of a pmc, see data::dumper in the library. (more).
14:23 Coke say == "print plus a newline"
14:23 lucian Coke: oh. ok, i'll look up data dumper
14:23 lucian Coke: thanks
14:24 Coke http://github.com/partcl/partcl/​blob/master/src/macros.pir#L257
14:24 Coke I use that in partcl.
14:24 Coke then I can just do .dumper($P0) instead of having to explicitly load the dumping library.
14:24 lucian Coke: cool. i'll steal it! :)
14:24 Coke enjoy
14:28 lucian allison: should i put helper macros in any particular place?
14:40 allison joined #parrot
14:41 allison left #parrot
14:45 allison joined #parrot
14:46 allison (firefox blames google calendar, but personally I suspect it's more likely caused by running matlab remotely over ssh
14:47 allison (with x forwarding))
14:51 lucian allison: i'd blame virgin, they throttle me to no end
14:51 allison lucian: also possible
14:51 purl it has been said that also possible is creating an "Error" type, which could also contain an error message (explaining the reason for the Null return value), and allowing easy promotion to an actual exception in certain contexts or pragmas
14:52 * lucian enjoys the deliciousness of print in an interpreter implementation
14:55 lucian allison: what's the status of objects in pynie?
14:56 allison lucian: the syntax is parsed, but they aren't implemented
14:56 allison lucian: like dictionary and list, they will be a thin wrapper around the parrot types
14:57 lucian allison: right. i miss dir(), but i realised i can't do it without object.__dict__
14:58 allison lucian: aye, you will need objects before you can start doing lookups on module objects
14:59 allison lucian: maybe start smaller?
14:59 lucian lucian: i'm hacking dict() now. i've got dict({}) working :)
14:59 allison lucian: excellent!
14:59 * purl plays air guitar
15:01 lucian allison: how can i determine if an optional param is empty or not?
15:01 lucian allison: wait, don't answer that. i should read more :)
15:01 allison lucian: okay
15:01 allison lucian: look for :opt_flag
15:01 allison (as you're reading)
15:02 lucian allison: ok
15:09 payload joined #parrot
15:12 patspam joined #parrot
15:12 Psyche^ joined #parrot
15:21 lucian allison: found it, thanks
15:22 * lucian is slightly dazzled by pir flow control
15:25 particle dazzled is better than fazed, i hope
15:26 lucian particle: i'm not really used to assembly
15:26 lucian it's just that it takes longer to translate ideas into code
15:27 particle well, luckily, pir flow control is better than assembly flow control.  except there's the whole 'if()' and 'while()' thing...
15:27 particle who needs them when you have goto!
15:27 PerlJam lucian: that's why I tend to prefer coding in NQP (or some other HLL)
15:28 particle lucian, there are macros that provide if, for, while, but i'm not sure how well they deal with nested loops.
15:28 davidfetter joined #parrot
15:28 lucian particle: i'll stick to goto for now, it's not bad just unusual
15:28 lucian PerlJam: i'm hoping pynie will be self-hosting at some point
15:29 PerlJam lucian: are there nice parsing libs for python?
15:29 lucian PerlJam: there are a few, but i'm not sure about dependencies
15:29 NotFound joined #parrot
15:29 lucian PerlJam: meh, NQP is less bad than perl5, so i'm mostly fine with it
15:29 particle lucian: if you want to prematurely optimize, remember that when using branch/goto that most processors have 'branch prediction', which prefers the code immediately following the goto
15:30 lucian particle: i wasn't thinking of optimisation, i want to learn pir
15:30 particle if null goto somewhere ; preferred code ; somewhere: ; non-preferred code
15:31 lucian yeah, afaik some simple cpus always predict the first branch
15:31 particle if you're reading pir code, you may see a bunch of 'unless' or 'if not' statements, and branch prediction optimization is why they're written that way instead of the easier on the eyes way
15:32 lucian particle: right. this is one case where i agree with the existance of unless
15:36 lucian allison: gen_builtins and friends mess up line numbers and filenames
15:37 lucian allison: for build error messages
15:38 allison lucian: yes, the process of "include" combining them all into one file is less than ideal
15:38 allison lucian: it's done so pynie can be bundled into a single executable
15:38 lucian allison: right
15:39 lucian allison: also, should i use :multi for dict()?
15:39 lucian allison: i think it would remove a lot of ifs and gotos
15:40 allison lucian: in order to handle multiple possible inputs?
15:40 lucian allison: yes. dict(), dict({}), dict((,), (,)), etc
15:40 allison lucian: how complicated are possible alternate signatures?
15:40 estrabd joined #parrot
15:41 lucian allison: http://bitbucket.org/allison/pynie/s​rc/tip/src/builtins/funcs.pir#cl-293
15:42 lucian allison: dict() is missing, though
15:43 allison lucian: aye, throws an "unimplemented" exception
15:43 lucian allison: well, the subroutine is a stub
15:43 allison lucian: it looks like dict() can accept a variable number of arguments
15:43 lucian allison: i was thinking of having severals .subs with :multi, so i can handle that cleaner
15:44 kthakore hi folks
15:44 allison lucian: if you use :multi, each :multi alternate has to have a distinct signature
15:45 lucian allison: i know. dict(), dict(seq) and dict(mapping)
15:46 allison lucian: as in signatures a) no arguments, b) a list, and c) a dictionary?
15:48 lucian allison: a) no args, b) list/tuple of tuples, c) a dict, d) dict(one=1, two=2)
15:48 allison lucian: a multi doesn't work if one of the alternates is :slurpy (because :slurpy would always work for anything)
15:49 lucian allison: afaict, slurpy shouldn't be needed for dict()
15:49 lucian allison: dict( (1,2), (2,4) ) seems to be invalid
15:49 allison lucian: it's :slurpy :named
15:49 lucian allison: yes, just checked on cpython. dict has 1 or 2 arguments, always
15:49 allison lucian: that means it collects all the arguments into a dictionary
15:50 lucian allison: for dict(one=1, two=2) ?
15:50 allison lucian: builds a dictionary with the keys 'one' and 'two' and the values 1 and 2
15:50 lucian allison: right. so because of that, i can't use multis
15:51 lucian allison: well, i can use a multi for the dict() case because that has arity 0, right?
15:51 allison lucian: yes, a multi works best when you have fixed signatures
15:51 dalek winxed: r433 | julian.notfound++ | trunk/examples/pirado.winxed:
15:51 dalek winxed: parse subs and main flag in pirado
15:51 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=433
15:51 allison lucian: well, the :slurpy handles that case too, it's an empty result
15:52 allison lucian: (:slurpy is happy to consume anything or nothing)
15:52 lucian allison: right. that kinda sucks. i'll stick to gotos then
15:52 allison lucian: so, :slurpy takes care of the variable arguments
15:53 allison lucian: it looks like the other cases are all one argument?
15:53 lucian allison: yes
15:53 lucian allison: i wish for python's kwargs in pir :)
15:54 allison lucian: so, you either get a single argument (that's a list/dictionary) or a list of key/values
15:54 lucian allison: a list or tuple
15:55 allison lucian: looking at how kwargs works so I can translate...
15:55 particle why won't multi work, then? you get to dispatch based on the type of the argument
15:55 lucian allison: it's like multi, but more explicit. so you could do just this
15:55 lucian particle: can you dispatch separately if you have arbitrary arity, but with keyword arguments?
15:56 allison lucian: that looks like :named args/params
15:56 particle :slurpy :named
15:57 particle :slurpy
15:57 lucian particle: yes, but that'll eat up the arity=1 and arity=0 cases
15:57 Coke parrot, do more in this challenging economic times with gotomeeting.
15:57 particle those are the two sigs
15:57 particle lucian: is the parameter named in the arity=1 case?
15:57 lucian particle: no
15:57 allison lucian: the equivalent of test_var_args_call(**kwargs) in pir is test_var_args_call(kwargs :flat)
15:58 allison lucian: (assuming kwargs is a dictionary-like key/value pair set)
15:58 lucian allison: and can i use that in a multi?
15:59 lucian allison: or will it try to flatten the 1 arg?
15:59 allison lucian: on the parameter side, you'd say .param arg1 :named
15:59 allison lucian: it will flatten the 1 arg if you tell it to using :flat
15:59 allison lucian: it won't flatten the arg automatically
15:59 lucian allison: right. trying it now
16:00 allison lucian: (we tend to be very explicit about these things, since difference languages want different behavior)
16:00 lucian allison: right, makes sense
16:01 lucian does .local come with a perf hit?
16:01 allison lucian: on the definition side:
16:01 allison def test_var_kwargs(farg, **kwargs):
16:01 allison is equivalent to
16:01 allison .sub test_var_kwargs
16:01 allison .param pmc farg
16:01 allison .param pmc kwargs :slurpy :named
16:02 particle .local is strictly for human-readability
16:02 lucian yeah, that i had inferred
16:02 allison lucian: .local is a very fast alias to the register
16:02 Coke lucian: .local as opposed to $P0 ?
16:02 Coke hell, $P0 is an alias.
16:02 lucian Coke: yes
16:02 allison lucian: no overhead compared to $P0 direct access to the register
16:02 Coke there is no way in PIR to directly access the registers like there is in pasm.
16:02 lucian allison: ok, then what's the point of $P in the first place?
16:02 allison lucian: lexical variables are another matter
16:03 allison lucian: originally there was only direct access to the registers P0, I0, etc
16:03 allison lucian: then we added automatic allocation, and prefixed that with $P0
16:03 lucian allison: right
16:03 allison lucian: .local is verbose for code under 3 lines
16:03 Coke and then we removed direct access. =-)
16:04 allison lucian: but the $P0 names are cumbersome for code over 3 lines
16:04 lucian allison: i'd argue that .local pmc is more readable, so should be used always :)
16:04 whiteknight_ joined #parrot
16:05 particle but $P0 is easier for pir-generating compilers
16:05 lucian particle: that makes sense
16:15 lucian allison: btw, there's also dict(iter)
16:16 allison lucian: it sounds like a signature with one optional pmc argument and one :slurpy :named argument will catch all the cases
16:17 lucian allison: yes it does, but i was hoping for some patern mathing to reduce the number of gotos
16:18 allison lucian: or you could multidispatch on that based on the type of the first argument
16:18 allison lucian: but only if you never plan on using the **kwargs behavior
16:19 NotFound There is some reason to not have an opcode invokecc_pc ?
16:20 allison lucian: python doesn't really support multiple dispatch
16:20 lucian allison: dict(**{1:2, 3:4}) works on cpython
16:20 aukjan joined #parrot
16:20 allison lucian: that's dynamic dispatch, but not multiple dispatch
16:21 lucian allison: i know, i was just saying that works
16:21 lucian allison: and i'm not sure how to handle it
16:22 allison lucian: does it mostly just follow the behavior of ** combined with {} anyway?
16:22 lucian allison: it's identical to dict(1=2, 3=4). except this wouldn't work for numbers
16:23 allison lucian: that's :flat
16:23 allison it flattens out the variable created by {}, and passes it as keyword args
16:24 lucian allison: oh, right ** == :flat
16:24 allison aye
16:34 lucian allison: i'm dropping multis, going with my working goto-laden single .sub
16:35 allison lucian: sounds good
16:38 wagle joined #parrot
16:40 allison lucian: there are always options to refactor later
16:42 lucian allison: yeah. i was hoping to get away with nicer code from the start, mais c'est la vie
16:47 lucian is there a pir interactive interpreter?
16:48 particle no
16:48 particle but 'parrot -'
16:48 particle allows you to feed pir subs in, hit Ctrl-Z, and it'll run
16:48 lucian particle: right, that'll do. thanks
16:52 bubaflub lucian: you can use parrot_shell, in perl tools/dev/parrot_shell.pl
16:52 wagle joined #parrot
16:52 bubaflub type in some lines of PIR and then end it with a .
16:52 bubaflub the shell will run it
16:53 lucian bubaflub: oh, nice. thanks
17:02 particle bubaflub++
17:06 theory joined #parrot
17:14 dukeleto 'ello
17:14 dukeleto yay, people are using the parrot shell! bubaflub++
17:14 dukeleto tewk: ping
17:15 bubaflub dukeleto don't know if you saw it either, but whiteknight++ took care of the last icc test errors and a bunch of the warnings
17:15 bubaflub s/either//
17:16 tewk dukeleto, pong, I got your tests checkin coming shortly
17:17 dukeleto tewk: sweet!
17:18 dukeleto bubaflub: yes, i am looking at recent commits and saw that fly by. nice!
17:18 PacoLinux joined #parrot
17:19 bacek joined #parrot
17:19 dukeleto bacek: o hai
17:19 bacek dukeleto, aloha
17:20 aukjan joined #parrot
17:20 tewk t/pmc/fixedintegerarray.t .. 1/30 init_pmc() not implemented in class 'FixedIntegerArray'
17:21 tewk $P0 = new ['FixedIntegerArray'], 10
17:21 cotto hi bacek
17:21 bacek morning cotto
17:21 cotto just committed a thing
17:21 cotto it does some stuff
17:21 tewk The 10 seems to be getting autoboxed into a PMC, thats not good
17:21 bacek good
17:21 cotto since I'm committed to my job, I also need to go do some stuff
17:21 bacek I changes PAST generator yesterday.
17:22 cotto yes.  It's improved.
17:22 bacek changed
17:22 cotto thanks
17:22 cotto bbs
17:26 dalek parrot: r44856 | cotto++ | branches/ops_pct/compilers/opsc (5 files):
17:26 dalek parrot: [opsc] make jump flags accessible to Trans, remove a mostly-done TODO item
17:26 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44856/
17:29 dukeleto tewk: yes, the error seemed odd to me, since we are passing in an int
17:32 tewk How dukeleto I'll just comment out the tests and commit, I need to work on something else today.
17:40 dukeleto tewk: i didn't commit the test
17:40 tewk dukeleto, I just did :)
17:42 davidfetter tewk++ :)
17:42 dukeleto tewk: oh noes! yeah, i guess comment it out. if you have a hint about how to fix it, maybe shoot a mail to the list and somebody else can fix it?
17:43 dalek parrot: r44857 | tewk++ | trunk (11 files):
17:43 dalek parrot: VTABLE_init_int commented out tests
17:43 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44857/
17:43 tewk I don't know off the top of my head, maybe it has something to do with opcode selection, maybe the more specific int opcodes need to come first in the opcode list, I don't know.
17:44 tewk the new ones are at the end bacause I put them into experimental
17:45 brooksbp joined #parrot
17:46 dukeleto tewk: ok, maybe someone on the list can shed some light on it
17:47 lucian joined #parrot
17:56 cotto_work good marooning
17:56 cotto_work tewk, what's br0ken?
17:56 cotto_work other than my kb
17:57 tewk I may have just done something wrong, but new ['FixedIntegerArray'], 10  seems to call the new_p_p_p opcode instead of the new_p_p_i opcode.
17:59 NotFound tewk: or maybe just imcc does his own magic instead of searching for an appropiate op.
18:06 tewk NotFound, I just findi it interesting that _p ops come after _i _n _s ops in ops.num.  so maybe I need to move my ops out of experimental so they come before the more general _p_p_p ops.
18:06 dalek winxed: r434 | julian.notfound++ | trunk/examples/pirado.winxed:
18:06 dalek winxed: sub calls and .return, only with empty args and returns, in pirado
18:06 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=434
18:07 cotto_work tewk, I was wondering if that might have something to do with it.
18:14 ruoso joined #parrot
18:34 whiteknight joined #parrot
18:46 Coke parrotshell?
18:57 cotto_work whiteknight, the pre tags in your blog post make some of the quoted conversation be hidden
18:58 whiteknight really? damnit
18:58 cotto_work I have a pretty wide monitor too
18:59 cotto_work typo: "BigInt nd BigNum"
19:00 theory joined #parrot
19:00 theory joined #parrot
19:02 dukeleto Coke: the parrot shell is tools/dev/parrot_shell.pl
19:03 dukeleto Coke: it is a parrot REPL
19:03 aukjan joined #parrot
19:06 chromatic joined #parrot
19:10 dukeleto chromatic: mornin'
19:12 denisw joined #parrot
19:12 denisw hi
19:12 denisw how easy is it to implement a prototype object system on top of parrot? (for a javascript implementation) i found some info about that in the internet, but that might be dated (written two years ago) so maybe things got simpler with parrot 2.0?
19:15 whiteknight joined #parrot
19:15 whiteknight EFIREFOXCRASHED
19:16 allison denisw: pretty straightforward, it already has one
19:16 dukeleto denisw: you should be able to piggy-back on the parrot object system, which docs where you looking at?
19:17 denisw allison: ? i thought classes are immutable after instantiation
19:17 allison denisw: see Protoobject.pir
19:17 allison denisw: in the base object model, yes
19:18 denisw allison: does that have accompanying documentation?
19:19 dukeleto denisw: http://docs.parrot.org/parrot/latest/html/
19:20 dukeleto denisw: that will always be the most up-to-date docs
19:21 allison denisw: it has inline documentation, but it's based on the Perl 6 spec, so you can also look there for the ideas behind how it works
19:25 theory joined #parrot
19:28 ruoso joined #parrot
19:30 denisw allison: doesn't that implement perl 6 protoobjects which is a different concept?
19:32 allison denisw: yes, you wouldn't want to use that protoobject implementation
19:32 allison denisw: but it demonstrates that a prototype-based object model can be dropped on top of the Parrot model
19:32 denisw allison: so i have to roll my own?
19:33 whiteknight allison: on a related note, is there any interest for Parrot to supply a prototype-based model in the core install?
19:33 allison denisw: essentially, there are certain interfaces the class/object needs to support, and anything that supports them works
19:33 allison denisw: yes, but it should be pretty simple
19:34 allison whiteknight: potentially, yes, if we can make it generic enough to support the needs of a collection of languages
19:35 whiteknight allison: okay. Obviously there was some talk recently about supporting prototype-based languages, and if we have our own prototype system, we will have more intimate knowledge of what is needed to support it
19:35 whiteknight plus, many languages would be able to make use of our built-in version with ease
19:37 allison whiteknight: providing base features that make it easier for new languages to get started are a definite advantage
19:37 slavorg joined #parrot
19:38 whiteknight what would be the first step for somebody interested in such a project? Draft a PDD? implement it externally, etc?
19:39 allison whiteknight: an added section to the PDD would work, just outlining the API
19:39 AndyA joined #parrot
19:39 whiteknight not a new PDD in pdds/draft?
19:39 denisw whiteknight: probably a good candidate would be something like the table concept in lua
19:39 allison whiteknight: it's just part of Parrot's base object model
19:39 allison (if we decide to make it core)
19:40 whiteknight denisw: yes, that would be a decent candidate. I am a little biased towards the JavaScript model myself, but no reason we can't incorporate both
19:40 denisw aren't they semantically equal?
19:40 whiteknight yeah, I suppose
19:41 denisw a javascript object is more or less a hash table
19:41 whiteknight I'm not nearly so fluent in Lua, so I dont know the details
19:41 allison whiteknight: under Definitions, it needs to define "prototype", and then add a section for "Proto PMC API"
19:41 whiteknight gotcha
19:41 whiteknight I'll kick some ideas around and write a draft
19:41 denisw cool
19:42 allison bonus points if it can support both lua and javascript proto models
19:42 whiteknight denisw: You have any documentation on the Lua object model?
19:42 ash_ joined #parrot
19:42 darbelo you might want to look at what fperrad's lua is doing now too.
19:42 whiteknight more reading is always a good thing
19:42 whiteknight ah, that's true
19:42 cotto_work Lua's still using TGE, isn't it?
19:43 darbelo Yep.
19:43 denisw i would love to have that for a parrot-based ecmascript5 implementation
19:43 whiteknight urg, I am not a fan of TGE
19:44 kjeldahl_ joined #parrot
19:44 denisw whiteknight: the official lua documentation has a good explanation on doing OO with lua
19:44 denisw whiteknight: one moment
19:44 allison whiteknight: it hasn't had much attention lately
19:44 Coke dukeleto: a url is what I was looking for.
19:44 Coke parrotshell is tools/dev/parrot_shell.pl
19:44 Coke (feed the bot)
19:44 denisw whiteknight: http://www.lua.org/pil/16.html
19:45 whiteknight denisw++
19:46 denisw basically, lua tables can reference "metatables" to which table lookups are delegated when the main table's ookup fails
19:47 denisw whiteknight: it is mostly the same as  prototypes
19:47 whiteknight allison: perhaps the biggest question I would have up front is how the prototypes would be stored and manipulated by the system. For instance, Classes are stored in the interp's class hash. Also, classes connect closely to a NameSpace. Do we want prototypes to share or even mirror these behaviors?
19:50 allison whiteknight: yes, a prototype should act as a class and as an object, fully integrating with the current system
19:51 whiteknight okay, that's what I was hoping you would say. I foresee us needing to do some cleanup in the NameSpace PMC to support this, but that's something to worry about later (plus, cleanup there is something we need anyway)
19:51 allison whiteknight: that's the advantage of doing it once in the core, we can get the core semantics right
19:51 allison yes, there definitely is some cleanup needed there
19:52 whiteknight anyway, its an issue to worry about later. Rakudo* is #1 priority for now
19:53 particle is lua prototype based oo?
19:53 dukeleto Coke: https://svn.parrot.org/parrot/t​runk/tools/dev/parrot_shell.pl
19:53 denisw allison: actually, a class system is more easily done _on top_ of a prototype system than the other way around
19:54 particle if so, fperrad might be able to lend a hand at a set of generic prototype-based oo pmcs for parrot
19:54 denisw particle: it is table based, but you can easily do prototype object orientation with "metatables"
19:54 tewk dukeleto, new $P0, ['FixedIntegerArray'], 10 should be new $P0, 'FixedIntegerArray', 10
19:55 dukeleto tewk: i was using the code that you gave in your email :)
19:55 denisw particle: you can create tables whose keys map to method closures, and if a looked up key doesn't exist in the table, it is looked up in that table's metatable
19:56 dukeleto tewk: everything works without the brackets? sounds fine to me
19:56 tewk dukeleto, and I copied that from #parrotsketch,  cut and paste will kill us.
19:56 denisw particle: giving you a prototype-like delegation chain
19:56 particle denisw++ # thanks for the lesson
19:57 denisw particle: no problem :)
19:57 tewk With brackets you get a object that inherits from 'FixedIntegerArray'  I think
19:57 dukeleto tewk: yes. death from a thousand cut and pastes
19:58 denisw gotta go now, i'll sure come back here and track the progress on a prototype model whiteknight
19:59 denisw whiteknight: i would create a prototype system and define the class system in terms of that, but that might be a too big change to parrot
19:59 dukeleto denisw: feel free to create a ticket on trac.parrot.org describing what you want
19:59 allison joined #parrot
19:59 denisw dukeleto: ok i'll do
19:59 denisw anyway, really got to go now, see you soon
20:00 bacek joined #parrot
20:00 TimToady phone
20:01 dukeleto TimToady: those devices scary me
20:01 dukeleto scare, even
20:04 Coke crap. will be a few moments late.
20:09 Coke Houston++
20:10 tewk so if you pass a Integer PMC to VTABLE_instanciate, should it call init_int?
20:12 AndyA joined #parrot
20:12 allison joined #parrot
20:13 particle tewk: i say no, a pmc is a pmc
20:14 Coke yah, this isn't a method.
20:14 Coke (no autoboxing)
20:15 whiteknight tewk: you may not be able to instantiate a user-defined class with an integer value
20:15 whiteknight would need instantiate_int, and that doesn't seem necessary since all Object attributes are PMCs anyway
20:15 whiteknight no sense avoiding the box when all attributes get boxed anyway
20:18 NotFound instantiate with initializer is almost unusable, anyway.
20:19 * whiteknight just computed the stats, in the SVN repo at work I  account for 52.23% of all commits
20:19 whiteknight methinks the other people don't understand the "commit early, commit often" mantra
20:21 NotFound I'll write a system that generate a patch for each line changed, and set a cron job to apply and commit each at 5:00 am X-)
20:22 whiteknight it's not a competition. In fact it's a little depressing
20:34 payload joined #parrot
20:35 payload1 joined #parrot
20:37 tewk whiteknight, the problem is that new ['FixedIntegerArray'], 10 finds a class (PMCProxy) so it wants to call instanciate.
20:38 tewk Is this the new best practice way of creating PMCs?
20:38 whiteknight hmm... I'm not sure I was aware of that
20:38 tewk new 'FixedIntegerArray'
20:40 tewk The funny thing is PMCProxy_instantiate turns around and calls Parrot_pmc_new_init.
20:40 darbelo How quaint.
20:40 tewk It seems that new and instantiate opcodes at least for this use case are synonymous
20:41 tewk s/opcodes/vtables/
20:41 darbelo We need to cut down on indirection.
20:42 chromatic http://www.cs.mcgill.ca/~zhioua/MscSami.pdf
20:42 tewk Well I think the indirection supports backwards compatibility while progressing toward a unified PMC and Object world.
20:44 whiteknight the "new" opcodes definitely seem like they contain some unnecessary code. Especially after TT #389 if PMCProxies for all types are created early
20:44 darbelo I'm all for unification. Even more so if it means removing layers.
20:44 whiteknight ditto
20:45 whiteknight there's so much special-purpose code we can get rid of, and so many things we can optimize
20:45 whiteknight I don't have any experimental data, but I suspect that looking up built-in type numbers by string name is hugely expensive the way we do it now
20:46 tewk We should probably start unifying some things and dropping unneeded backwards compatibility.
20:47 whiteknight First step is probably to reduce the number of C-based PMC types
20:48 whiteknight followed by rewriting as many as possible in PIR instead of C (we'll probably still need a system for writing NCI methods in C and storing them in the namespace)
20:48 tewk Anyone know why we can't unify init_* and instanciate
20:48 whiteknight tewk: instantiate is used by the metaobject to create things, init is run on the object itself after creation
20:49 cotto_work Why can't that be a method?
20:49 whiteknight at the moment it would be hugely inefficient for built-in types that need C-level initialization
20:50 whiteknight BUT... it's a great idea for Objects
20:50 cotto_work I didn't know the built-in types needed explicit instantiation.
20:51 tewk create and init shouldn't be two separate steps
20:51 whiteknight cotto_work: apparently the "new" opcodes all use the PMCProxy to instantiate
20:51 tewk They do if you pass them ['PMCNAME
20:51 NotFound whiteknight: I think we can already insert NCIs in namespaces.
20:51 tewk ']
20:51 cotto_work Where's the code that does that?
20:51 purl i think the code that does that is only 3 lines, plus some image magick magic.
20:52 cotto_work no, the code that does that is still in my head
20:52 purl okay, cotto_work.
20:52 whiteknight NotFound: yeah, we can do it manually. I'm thinking about something like pmc2c where we write them in a *.methods file, and they get inserted automatically at startup
20:53 NotFound whiteknight: to include predefined classes in core, you mean?
20:53 whiteknight NotFound: yes, exactly
20:53 NotFound Sounds good.
20:53 purl somebody said Sounds good. was there a good way for me to find out when branches are merged, other than read every svn commit?
20:54 whiteknight NotFound: eventually, if we could write ALL PMC types in PIR (or, more likely, Lorito) we'll need a mechanism to include them
20:54 cotto_work forget sounds good.
20:54 purl cotto_work, I didn't have anything matching sounds good
20:54 cotto_work forget sounds good
20:54 purl cotto_work, I didn't have anything matching sounds good
20:54 whiteknight so if we could start making inroads for that kind of mechanism, it's a good start
20:55 theory joined #parrot
20:59 cotto_work bacek, is there any purpose for compilers/opsc/opsc.pir other than to aggregate all the opsc pbc files into one file?
21:01 Coke (pmcs in pir) those are called objects, neh?
21:01 whiteknight Coke: depends. A ResizablePMCArray isn't an Object
21:01 bacek cotto_work, no already
21:01 Coke whiteknight: it would be if it were written in PIR, is what I'm saying. at least today.
21:01 whiteknight Ah, true
21:02 Coke (you could write it MOSTLY in pir and have it still be a PMC)
21:02 whiteknight I would love to see improvements to pmc2c that allow writing of some VTABLEs and METHODs in PIR transparently
21:03 whiteknight for METHODs, a PIR version would just be a Sub in the PMCProxy
21:04 whiteknight would also need a bootstrapped build, since we would need a PIR compiler around to build them
21:04 whiteknight could happen immediately for dynpmcs without bootstrapping though
21:06 cotto_work whiteknight, the opsc work bacek and I are doing is part of making that possible.
21:07 whiteknight cotto_work: another pie-in-the-sky idea I would love to see implemented is the ability to define new ops, at runtime, using PIR
21:08 whiteknight though with the current architecture, that's nigh-impossible
21:08 lucian allison: i can't for the life of me figure out how to do boolean compositions like and
21:08 whiteknight .op "foo"\n .param pmc arg1 ...
21:09 whiteknight anyway, I have to jet out of here. Later
21:09 allison lucian: they're split out over multiple opcodes, and then combined at the end
21:10 Coke lucian: $I0 = and $I2, $I3
21:10 lucian Coke: i was trying and $I0, $I2, $I3 as per the doc, didn' twork
21:11 PerlJam lucian: are you expecting bitwise and or logical and?
21:11 lucian PerlJam: logical
21:12 PerlJam just checking :)
21:12 allison lucian: so, the high level language "if (a and b)" translates to what Coke said, plus "if $I0" as the next statement
21:12 lucian allison: right, i'll try Coke's syntax
21:13 lucian The opcode 'and_i_i' (and<2>) was not found
21:14 lucian for $I0 = and $I2, $I3
21:14 lucian similar for and $I0, $I2, $I3
21:18 lucian found the problem. i was doing and has_sequence has_mapping, where the two are .param :opt_flag
21:18 lucian it wants me to put them in registers first and then and on those
21:19 patspam joined #parrot
21:20 iblechbot joined #parrot
21:28 lucian allison: it seems registers + isnull is more useful than :opt_flag
21:28 nopaste "coke" at 65.91.151.194 pasted "for lucian" (18 lines) at http://nopaste.snit.ch/19906
21:29 Coke lucian: that outputs 0, 0, 1
21:29 allison lucian: it's not reliable though
21:29 lucian Coke: this bit doesn't work for me $I0 = and has_a, has_b. for some reason
21:29 Coke lucian: does my sample output 0\n0\n1\n for you?
21:30 snarkyboojum joined #parrot
21:30 lucian Coke: yep
21:30 Coke ok. then we just need to figure out how your code is idferent.
21:31 allison lucian: you can't absolutely guarantee that a memory location will be nulled out if no parameter was passed, and for integer parameters, you have no way of distinguishing if a 0 value was passed or no value was passed
21:31 lucian allison: right
21:31 Coke lucian, can you nopaste your code that fails?
21:31 lucian Coke: in a minute
21:32 lucian allison: i find pir's idea of boolean operations very incosistent
21:33 lucian allison: it seems a very bad idea to have $S0 = "0" eval to false
21:33 lucian Coke: wait, now it works. diffing to see what's changed
21:35 lichtkind joined #parrot
21:35 lucian Coke: missing comma it seems. stupid. but the error message confused me
21:35 lucian it said The opcode 'and_i_i' (and<2>) was not found
21:37 lichtkind allison: thanks , yesterday i even couldn't tell you that your great president
21:37 allison lucian: several dynamic languages do extraction of numeric values from strings
21:38 Coke lucian: right. the reason that makes sense is that the opcode is really add_i_i_i
21:38 Coke $I0 = and $I1,$I2 == sugar for and $I0,$I1,$I2
21:38 lucian Coke: right
21:39 Coke hey, allison, do we need commas to separate opcode args?
21:39 Coke (i know we do /know/)
21:39 Coke er, NOW.
21:39 purl i heard er, now was probably not the time to mention markl's 16 years experience as a manager of software groups, is it...
21:39 allison Coke: could work just as well without them, it's largely for clarity
21:39 Coke NOW is also the catchphrase of Jack Bauer.
21:39 purl okay, Coke.
21:40 lucian allison: perhaps for a dynamic language (that's debatable), but not for an implementation language
21:40 allison my annoying persistent typo is "opcodename, arg1, arg2"
21:40 lucian i keep doing opcode arg1 arg2
21:41 allison Coke: the commas are so habitual, they spread
21:41 lucian allison: you can easily compose extraction from strings for boolean comparison over a more strict boolean logic, but the reverse is not quite true
21:41 allison lucian: It is partly auto-unboxing, but it's also a design decision of the Parrot core types
21:42 lucian allison: ok, fair enough
21:42 allison lucian: but, any data type is free to over-ride the behavior
21:42 lucian allison: i know PMCs can, but $S/$I can't
21:43 allison lucian: so, if the Python datatypes want strings to always evaluate as true, they override 'get_bool'
21:43 lucian allison: can they do that for non-pmc strings too?
21:43 allison lucian: in general, an HLL type corresponds to a PMC, not to a bare register
21:43 lucian allison: right, ok
21:44 allison lucian: because HLL types may have methods defined on them, etc
21:44 Coke s/in general//
21:45 allison Coke: also true
21:45 lucian yeah, i imagine C on parrot might not want to do that
21:51 Coke ->
21:55 NotFound You can imagine C on parrot? :o
21:56 darbelo There used to be a c99 parser in languages/
21:56 darbelo I submitted a GSoC proposal to ressurect it two years ago.
21:56 NotFound A parser has no problems with runtime data types ;)
21:57 cotto_work Close is... um... close.
21:57 theory joined #parrot
21:59 lucian NotFound: parrot seems general enough to me to host C, and it might be useful
22:00 NotFound lucian: I can dream with it, but fail to imagine.
22:00 NotFound (and the dream can be a nightmare)
22:00 lucian NotFound: crypto libs that don't depend on platform binaries
22:02 darbelo Hmm.
22:02 darbelo dukeleto: ping
22:03 cotto_work lucian, Parrot could certainly be used to write a C compiler but the generated code would be very slow since it'd be compiled down to pir.
22:03 darbelo Also, have fun writing libc in PIR ;)
22:04 NotFound You can also write a compiler that generates any other thing using parrot, of course.
22:04 lucian cotto_work: i know, but you'd get tested crypto libs. and a jit might help a bit
22:05 cotto_work It's possible if you've got the itch.
22:06 lucian cotto_work: yeah. gcc or llvm backend?
22:06 darbelo purl: msg dukeleto 'Pick and ressurect a language from http://trac.parrot.org/languages/browser ' might make for an interesting GSoC project...
22:06 purl Message for dukeleto stored.
22:06 lucian i vote for chitchat! :)
22:07 dukeleto darbelo: pong
22:07 Tene I should migrate chitchat to nqp-rx eventually.
22:07 darbelo dukeleto: Read the just sent purl-o-gram.
22:07 Tene it was a fun parser to write.
22:07 Tene The grammar is pretty much complete, as I recall, it just needs to have a library written for it.
22:07 darbelo I'd like forth myself.
22:07 joeri joined #parrot
22:08 kurahaupo joined #parrot
22:08 dukeleto darbelo: i think we are going the route of only having parrot-core projects for GSoC, i.e. not HLL's
22:08 dukeleto darbelo: that is what we did last year and I think we are continuing that
22:09 dukeleto darbelo: but that is a good quesiton to bring up on -directors and/or -dev
22:09 dukeleto darbelo: i think the motivation is that there is still lots of stuff to do in core and those things benefit all HLL's
22:09 lucian dukeleto: jit! :)
22:10 darbelo dukeleto: I understand the rationale, just wanted to point out a newbie-friendly publicity oportunity for our compiler tools.
22:11 dukeleto lucian: yes, JIT is definitely wanted badly, but may be too large for a GSoC project. a piece of JIT would work well as a GSoC project, like a pluggable frame builder
22:11 lucian dukeleto: right. well i doubt i could do jit work myself, i think i'll stick to applying to PSF with pynie
22:11 dukeleto darbelo: the decision is not set in stone, but people decided that last year and I am just assuming that we are continuing with that. if PaFo wants to allow language work, then that is fine
22:12 dukeleto msg plobsing would you be interested in mentoring a student on a pluggable frame builder? is it reasonable to assume that can be done by a good student in a summer?
22:12 purl Message for plobsing stored.
22:13 dalek rakudo: d0a4488 | duff++ | src/Perl6/Actions.pm:
22:13 dalek rakudo: Use &eager to Parcelize the statement modifier for loop
22:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​0a448868f175a395267a1e5a567a2cfd0f412a6
22:14 darbelo dukeleto: Making frame builders compile-time pluggable should be manageable, run-time pluggable is unlikely.
22:15 darbelo But it's not the most encapsulated part of parrot's internals
22:18 darbelo Also, doing the cleanup work to encapsulate framebuilders *and* write one from scratch is probably pushing it.
22:18 darbelo At least for somebody who'll have to learn the codebase.
22:19 chromatic Then encapsulation isn't too bad.
22:19 lucian i don't know too much about parrot internals, would a simple patching jit translating from pasm to llvm ir be worthed?
22:21 darbelo lucian: I'd rather see pbc translated, insted of pasm, but yes, we'd like it.
22:21 lucian darbelo: pbc is the bytecode, right. my lack of knowledge is showing
22:21 darbelo lucian: Yes.
22:23 lucian i'm thinking that llvm should be able to optimise across pbc instructions even if the jit just does patching
22:26 Whiteknight joined #parrot
22:32 dukeleto darbelo: compile-time pluggable would be fine in my book
22:33 AndyA joined #parrot
22:34 Whiteknight chromatic: ping
22:35 darbelo dukeleto: I would still aim at just making them pluggable, and importing plobsing's libjit famebuilder rather thatn writing a new one.
22:36 darbelo There's a considerable amount of ugly in our current framebuilder.
22:36 dukeleto darbelo: that is fine with me. if the gsoc student can help plobsing with what he has, that would be great
22:36 chromatic pong, Whiteknight
22:36 dukeleto darbelo: nothing a little napalm can't fix
22:36 Whiteknight chromatic: I'm chomping at the bit to help with tt389_fix or hll_mmd_fix branches. If you can point me in the right direction I can go crazy
22:37 Whiteknight hl_mmd_fix you said you would un-todo the tests we need to fix, and tt389_fix you said you were having some issues and would know by tomorrow if you were stuck
22:38 darbelo dukeleto: When we ripped out the JIT, I basically scraped some of it's parts off the walls and stitched them together into a framebuilder. It's not pretty to look at.
22:38 chromatic Let me find the ticket numbers for hll_mmd_fix.
22:39 Whiteknight tt389_fix branch appears to be passing all existing tests for me now, so are there more tests need to be added/un-todoed?
22:40 chromatic Yes, there should be one failure in p6object.t
22:41 chromatic TT #562, TT #784, and TT #1040 on hll_mmd_fix.
22:41 Whiteknight also, TT #389 on closer inspection really looks like it's multiple separate issues: fixed handling of :anon in many cases and adding of :nsentry flag
22:42 Whiteknight so is this branch tackling all those issues, or just the issue of method storage in the namespace?
22:42 chromatic Just the latter.
22:43 Whiteknight okay. So we should probably create new tickets to separate out the other stages of work
22:43 chromatic That sounds reasonable.
22:44 dukeleto darbelo: so what you are saying is that we need more chainsaws ?
22:46 darbelo dukeleto: Kind of, what I mean is that the currrent fram builder doesn't respect encapsulation boundaries nor was designed acording to a plan more elaborate than 'make it work again'.
22:47 dukeleto darbelo: ok, i hear ya. it is in dire need of refactoring
22:47 darbelo Getting a student unfamiliar with our codebase to encapsulate *that* mess behind a coherent and sane interface won't be trivial.
22:48 dukeleto darbelo: i hear ya. maybe it isn't the best gsoc projecgt
22:48 darbelo It is certaily doable, but we should make sure they walk into it with their eyes open.
22:48 cotto_work and with adequate protective clothing
22:48 dukeleto darbelo: stapled open, you mean :)
22:49 cotto_work chromatic, would it be possible to use lexicals to make pir Test::More TODOing more user-friendly?
22:50 dukeleto cotto_work: what is your idea?
22:50 cotto_work have ok() etc check if there's a lexical TODO set and print todo output if so
22:51 plobsing darbelo: what aspects of the current frame builder disrespect encapsulation? (not that I don't agree, just curious)
22:51 chromatic I'm not sure lexicals are visible that way.
22:52 cotto_work find_dynamic_lex doesn't do something like that?
22:52 dalek tracwiki: v50 | cotto++ | ParrotQuotes
22:52 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Pa​rrotQuotes?version=50&amp;action=diff
22:53 dalek parrot: r44858 | whiteknight++ | branches/tt389_fix/t/pmc/complex.t:
22:53 dalek parrot: un-TODO test for TT #562 that fails and needs to un-fail.
22:53 darbelo plobsing: I'd have to check, it's been a while since I last looked at it, but I think it liked to play with ManagedStruct's guts.
22:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44858/
22:53 dalek parrot: r44859 | whiteknight++ | branches/tt389_fix/t/pmc/integer.t:
22:53 dalek parrot: adding another test, modified from a failing example in TT #562. It fails in branch and needs to un-fail
22:53 dalek parrot: review: http://trac.parrot.org/parrot/changeset/44859/
22:53 dalek rakudo: 0a0469e | duff++ | src/Perl6/Grammar.pm:
22:53 dalek rakudo: parse version and need
22:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​a0469ece218ee44a70b8424a40144541e77fb17
22:55 plobsing darbelo: true. the frame builder is expected to hand off void pointers. that fix is step three of the plan in my head (which I need to put down somewhere sometime)
22:55 dukeleto plobsing: please put that plan in a TT or series of TT's! it would be much appreciated
22:55 chromatic Whiteknight, why are you unTODOing TODO tests?
22:56 dukeleto plobsing: i am trying to think of good parrot projects for gsoc students
22:56 plobsing darbelo: my biggest issue from a JIT point of view was parrot's use of macros  (which I had to wrap in functions or re-impement in JIT)
22:57 plobsing dukeleto: I'm not sure frame builder is big enough. what happens if the student finishes halfway thru?
22:57 plobsing dukeleto: also, what are the requirements on a mentor?
22:57 darbelo We make him build another one?
22:58 dukeleto plobsing: then the student writes docs, more tests, blog posts, maybe does a few extra features
22:58 plobsing dukeleto: ok
22:58 dukeleto plobsing: it is a good idea to size projects so that they can be done in less than 3 months, because roadblocks (tech and IRL) always happen
22:59 plobsing roadblocks on frame builder? impossible!
22:59 dukeleto plobsing: requirements for a mentor are just to basically answer questions from the student via whichever communication mediums the mentor+student have agreed to use
23:00 dukeleto plobsing: some mentors say they spend as little as ~3-5 hrs a week helping a student, some up to 20. it all depends on the project and student
23:00 plobsing rough estimate hrs/wk?
23:00 plobsing that was fast
23:01 dukeleto plobsing: but there is no actual required hrs/week. if you have an amazing student, they require little help
23:01 darbelo IIRC students should put in ~40 hrs/week or so.
23:01 dukeleto but i will say that I enjoyed the mentoring experience, even though it was occasionally time-intensive
23:02 dukeleto darbelo: yes, students should consider it a full time job.
23:02 TiMBuS joined #parrot
23:02 dukeleto plobsing: i helped write a book about gsoc mentoring: http://en.flossmanuals.net/bin/view/GSoCMentoring
23:03 dukeleto plobsing: it has a lot of good advice. it was written by 8 gsoc mentors/admins with the help of the GSoC program coordinator
23:04 plobsing dukeleto: by when would you like to know? My situation changes this spring and I haven't worked out my rough daily schedule yet (but could given a little time).
23:05 Coke dukeleto: I don't think we should refuse HLL work a priori, but Having some sort of comment about prioritizing projects (and how core is /probably/ going to fare better) might be reasonable.
23:05 dukeleto plobsing: well, we don't know if Perl/Parrot will get accepted as an org until March 18th, student apps are accepted between March 23rd - April 9th
23:06 dukeleto Coke: our policy last year was no work on HLL's, i am just going along with that. If parrot-directors wants to chane that, it doesn't matter to me
23:06 dukeleto change, even
23:06 dukeleto plobsing: the gsoc 2010 timeline http://socghop.appspot.com/document/sho​w/gsoc_program/google/gsoc2010/timeline
23:08 Coke iwbni?
23:08 purl hmmm... iwbni is "it would be nice if"
23:09 plobsing dukeleto: thanks for the info. will get back to you ASAP on that.
23:10 dukeleto plobsing: thanks! you have at least a week or so to decide
23:12 lucian allison: an :opt_flag for a :named :slurpy parameter doesn't always return the same value for the same input
23:13 lucian allison: http://pastie.org/864154
23:17 Coke lucian: what input are you feeding that that is changes?
23:17 Coke *changing
23:17 lucian Coke: i'm calling dict()
23:18 lucian Coke: some calls print 1 for has_mapping, some call 0
23:19 lucian s/some call/some print/
23:20 Coke lucian: wfm.
23:20 Coke you know you have 2 print statements there, yes?
23:20 Coke s/print/say
23:20 lucian Coke: yes. i'm talking about the second one
23:20 Coke yes. always prints 1 for me.
23:21 lucian Coke: on the first dict() call, it's 1. on subsequent calls it's 0
23:21 Coke not here.
23:21 lucian i can't see any state anywhere
23:21 Coke let me show you my slightly modified program that highlights this:
23:21 lucian Coke: then it's a bug in pynie's interp
23:22 Coke (have to install some cpan...)
23:23 lucian Coke: when calling 'dict' from pir code, it works
23:23 lucian Coke: when i call it from pynies repl, it prints 0 for all calls but the first
23:26 Coke what is "pynie's repl" ?
23:26 Coke (url to source code repo?)
23:27 patspam joined #parrot
23:27 Coke (wow does WWW::Mechanize have a lot of deps =-)
23:27 Coke (and yah, I only tested it from PIR)
23:28 lucian Coke: the pynie interpreter's repl http://bitbucket.org/allison/pynie/
23:28 kurahaupo joined #parrot
23:29 Coke oh, I thought you meant a specific method.
23:29 Coke not "the REPL". =-)
23:29 lucian Coke: oh, right
23:29 lucian my bad
23:29 Coke oh, no worries.
23:29 purl i heard no worries. was my smoke harness code public?
23:30 TonyC joined #parrot
23:32 Whiteknight chromatic: TDD. See the test failures, make them not fail
23:34 lucian Coke: it's quite late here, i'll try to figure this out tomorrow
23:34 lucian good night everybody!
23:34 lucian Coke: thanks for looking into it, btw
23:34 Coke ~
23:34 Coke np. I know how frustrating it is to be a HLL developer! ^_^
23:34 Whiteknight chromatic: we can re-todo them if you like it cleaner
23:38 chromatic I don't like having to remember which failures I expect and which I don't when I run the test suite.
23:39 dukeleto chromatic: yeah, that ires me. the test suite should always pass on trunk. if it doesn't, there is a problem
23:40 nopaste joined #parrot
23:41 chromatic I don't think anyone disagrees about trunk; we're talking about a branch.
23:41 Whiteknight chromatic: well, that's fine. Although in the end none of the tests should fail
23:42 dukeleto chromatic: ah. then that depends on the branch, i guess
23:44 Whiteknight chromatic: in the hll_mmd_fix branch, I notice that there is never a fallback to the VTABLE of the PMCProxy parent
23:45 chromatic Right.  Sometimes that's right and sometimes it seems wrong.  I didn't find a good general rule for that.
23:45 chromatic Must commute now though.
23:45 Whiteknight in half the vtables, there is a fallback to the delegate object, and in half not
23:45 chromatic Exactly.
23:47 eternaleye joined #parrot
23:48 Andy joined #parrot

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

Parrot | source cross referenced