#parrot Parrot 2.1.1 Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Tasks: Fix HLL bugs! Fix and test corevm target!
Set by moderator on 9 March 2010.
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. ???
All I did was add a line to the bottom of src/vtable.tbl. 00:01
chromatic Tennant, get it? 00:02
tewk oops, I figured it out
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 ...?"
Coke finally has a working OS X system, and guessing he'll have to resurrect the macport. 00:11
*guesses
Coke also ponders watching all the doctor who he can on netflix . 00:13
japhb can't wait for the next season ... though I'm dubious about the next doctor 00:15
00:16 payload joined
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?
chromatic I'm completely stuck on that one for the time being.
00:16 kid51 joined
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.
Whiteknight ah, sweet 00:18
chromatic TT #784, #1040, etc.
I think there's a problem with the distance calculations with a PMCProxy in MRO, but I'm not entirely sure.
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.
Whiteknight ...but the tickets have test cases, so we're in business
chromatic Also, have some commits.
Whiteknight nice 00:20
00:22 lucian joined
lichtkind thanks for cooperation @parrot i'll be back :) 00:23
good night
lucian allison: i'd like to implement dir() in pynie. where should I start? (already looking at builtins.pir) 00:32
allison lucian: yes, add a function there 00:33
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
Coke (if not, I can do it the hard way. =-)
Whiteknight chromatic: that new test passes in branch 00:35
ok 46 - Integer subclass and MMD - TT \\#784
allison Coke: I tend to merge the branch into a fresh branch from trunk, rather than the other way around 00:36
Coke: are there great new features in trunk that we need in the branch?
Whiteknight yes, I've learned that merging into a branch from trubk can be evil
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.
dalek rrot: r44834 | chromatic++ | branches/fix_hll_mmd/lib/Parrot/Pmc2c/PMC/Object.pm:
[lib] Allowed Objects inheriting from PMCProxy to pass through the proxied PMC
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?
rrot: r44835 | chromatic++ | branches/fix_hll_mmd (2 files):
[lib] Removed "MMD must obviously take care of this!" from i_* VTABLE entries,
rrot: r44836 | chromatic++ | branches/fix_hll_mmd (3 files):
Checkpoint.
rrot: r44837 | whiteknight++ | trunk/t/oo/vtableoverride.t:
tests for TT #1505. The matter is now resolved
Coke Austin: "Makefile"
allison Coke: well, that's a good reason :)
plobsing hi #parrot
Austin Coke: :)
Whiteknight Austin: rhetorical question?
purl somebody said rhetorical question was rhetorical.
Coke allison: I can't reproduce the bug folks were talkinga bout, though, so...
allison Coke: which bugs?
Coke "corevm builds PGE"
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?
Coke ... it builds.
and I can't find PGE.pbc.
allison and, no errors?
purl You mean no error *messages*
Coke I assume that the make would have bombed out if so.
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.
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...
Coke i'll retry.
00:40 zostay joined
tewk init_int hits the mailing list 00:40
Coke allison: pcc_hackathon_6Mar10 ? 00:41
tewk only 8 new opcodes new_p,s,pc,sc_i,ic
:)
allison Coke: it does include the $(GEN_LIBRARY) in corevm, which builds PGE libraries 00:42
Coke: that's the one
Coke there is a PGE.pir that doesn't actually rely on the PGE compiler being built, as I recall.
checking...
00:44 kurahaupo joined
Coke should corevm include the library at all? 00:44
Whiteknight no 00:45
allison Coke: it shouldn't include much of any core libraries
Coke: PIR libraries, I mean
Coke ... there's the failure.
probably needed a realclean. 00:46
allison Coke: just the VM itself and the absolute minimum of extras to get it to run
Coke dynpmc? dynoplibs?
Whiteknight tewk++ 00:47
allison Coke: debatable, but would be okay if needed for core tests
Coke we're defining what core means. =-)
allison Coke: the goal is to be able to run a core set of tests on the vm
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
Coke: to help figure out what's wrong 00:49
Coke: ah, it looks like the --core-tests argument to t/harness is unchanged 00:51
Coke alright. I'll just pull stuff out until it works, then. =) 00:53
getting ranlib: file: blib/lib/libparrot.a(win32.o) has no symbols 00:55
bacek_at_work Tcl/Glob.pbc also depends on PGE.pbc 00:56
Coke that can get renamed and move out to plumage.
Whiteknight chromatic: I think you kicked more butt on that fix_hll_mmd branch than you realize
all tests, plus the one from TT #784 pass 00:57
00:57 abqar joined
chromatic There should be several TODOs that still don't. 00:57
Whiteknight oh, which? can you un-todo them so we see what is needed? 00:58
Coke ... untodo them.
chromatic I'll take a look later tonight.
lucian there's no make target vim-install in editor/
cotto do we have a list of hll bugs that need love and eyeballs? 01:03
01:10 parthm joined
Coke cotto: there's a trac report. 01:10
01:13 davidfetter joined
Coke trac.parrot.org/parrot/report/16 01:13
feel free to ignore the tcl ones for this week.
lucian: are you sure?
purl You still have ALL THREE lifelines left!
Coke "WFM"
"cd editor && make vim-install" works here. 01:14
s/works/does something/
cotto Coke, he left 01:15
I was about to ask him the same thing though
Coke msg lucian "cd editor && make vim-install" works here. 01:16
purl Message for lucian stored.
01:17 theory_ joined
Coke ok. corevm now builds in the branch. 01:25
many tests failing in 'coretest' - all the initial ones seem to be real failures. 01:27
doing the same in trunk, so it'll be more obvious why whatever's failing is. 01:28
dalek rrot: r44838 | coke++ | branches/pcc_hackathon_6Mar10/config/gen/makefiles/root.in:
Naive attempt to minimize corevm.
rrot: r44839 | cotto++ | branches/ops_pct/config/gen/makefiles/root.in:
[makefile] don't remove function-based runcore files
 01:46
rrot: r44840 | whiteknight++ | failed to fetch changeset:
merge fix_icc_failures branch. Parrot builds with icc and passes all tests. also, fixed several build warnings
01:48 jimk joined
Whiteknight bubaflub: ping 01:50
dukeleto 'ello 01:51
plobsing arg. tt1015 has made my head explode multiple times! 01:56
what do you expect to get from "$P0 = getinterp \\n $S0 = freeze $P0 \\n $P1 = thaw $S0"? 01:57
Austin A new thread? 01:59
plobsing nope.
you get the current interpreter.
Austin Hey, it's what *I* expect...
Hmm...
Something to be said for that, too, I guess.
plobsing if you thaw any ParrotInterpreter, you get the current one. With the state of the frozen one merged ini. 02:00
s/ini/in/
Whiteknight ...good?
Austin coughs.
plobsing I can't imagine how that's right from any perspective.
Austin Wow, that was not _ever_ going to be on my list of suggestions. 02:01
dalek rrot: r44841 | whiteknight++ | trunk/PLATFORMS:
update PLATFORMS with icc info
Whiteknight plobsing: are there any tests or code that rely on that behavior? 02:02
may be a necessary quirk
plobsing Whiteknight: yes. its necessary.
it was hijacked to mark (and automatically load) extensions required by a PBC
every PBC has the interpreter used to compile it as the first constant 02:03
Austin Heh.
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
Austin is laughing on the inside.
plobsing also means I can't really make a parrot program that compiles other that don't include the compiler 02:05
s/other/other parrot programs/
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))
Austin Ah. 02:07
plobsing and finding some major fail along the way
Whiteknight damn fart crap
plobsing next fail: is the name a property of a class? If I clone a class, should it be anonymous?
Austin I'm a little leery of the whole freeze/thaw thing.
Whiteknight I hate this kind of shit
Austin I don't know what it is, and I don't interact with it.
02:09 kurahaupo joined
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
Austin Whiteknight: thawing the interp is basically resuming it.
plobsing so if you'd loaded dynlibs, they would get loaded
Austin ^^
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...
plobsing I think that dynext requirements should be an explicit and separate part of the PBC, not squirelled away in a frozen PMC.
helps with introspection 02:11
Austin The business about pbcs merging interps to get dynops or whatever is totally bogus.
+1
purl 1
Whiteknight that still doesn't make a ton of sense. why would thaw do the merging?
Austin That's what :load / :init is for.
Whiteknight thaw the interp and then merge it
Austin whiteknight: Thaw does the merge because that's a good way to do ... something they wanted to do 10 years ago.
And then they noticed they could do clever dynaload stuff with it... 02:12
plobsing Imma take it out and see if everything breaks.
Austin And now they have a chain of franchises across the world...
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:13
plobsing Whiteknight: OK, I'll see what I can do. 02:14
meanwhile, I have more issues on the queue. 02:15
Is the name of a class the property of the class? same for subs?
Austin That's one for the list, I think. 02:16
Ask parrot-dev
plobsing OK. Will do.
Austin I'd think the clone would get the same name, but would not be "the" class/sub, linked to the namespace, etc.
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.
Whiteknight urg
it's amazing parrot works at all when I hear this stuff 02:18
Austin "Do the simplest thing that can possibly work."
"Then refactor."
plobsing It runs on the sanity of developers. 02:19
Austin Heh
plobsing++
Whiteknight: "ComponentMarshaller" 02:23
tewk I'm about to add a new vtable entry, I assume I need to invalidate the bytecode right?
Whiteknight nice
Austin tewk: Only if there's going to be a number assigned to it. 02:24
tewk Well I had to make realclean 02:25
dalek tracwiki: v49 | Austin_Hastings++ | ParrotQuotes
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
cotto tewk, I don't think a new VTABLE function has any effect on pbc compatibility 02:30
you'd need to rebuild the PMCs but bytecode wouldn't care
tewk cotto, yeah I think your right.
cotto thinks his right too 02:31
tewk I'm lazy what can I say your -> you're 02:32
cotto It's my second favorite pet peeve. 02:33
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.
... but given how often we break pbc compatibility, do we care?
cotto about pbc compatibility?
easy fix: I'll remove cpu_ret and for sure break PBC_COMPAT so it'll be a moot point. 02:36
dalek rrot: r44842 | cotto++ | branches/ops_pct (2 files):
[opsc] add bootstrap-ops and bootstrap-ops-test makefile targets, which attempt to build and test parrot with a opsc-generated ops
rrot: r44843 | whiteknight++ | branches/fix_icc_failures:
branch already merged to trunk
rrot: r44844 | tewk++ | trunk (4 files):
VTABLE_init_int
cotto any objections? 02:37
good
Whiteknight include/parrot/vtable.h is built from src/vtable.tbl at config time 02:39
hence the need to reconfigure 02:40
Coke ... for now.
(one of those thigns that can probably be moved into a normal build step.)
tewk Whiteknight, ahh, that makes sense 02:44
Coke 'make corevm' functional in trunk and branch. does less in trunk, branch will need to catch up. 02:45
tewk w 02:46
dalek TT #1488 closed by whiteknight++: fix test suite when building with ICC 02:47
cotto Are there any real objections to removing cpu_ret? 02:52
istr that it's a jit leftover. It's definitely not used anywhere in core.
Whiteknight kill it
cotto done 02:53
dalek rrot: r44845 | coke++ | trunk/config/gen/makefiles/root.in:
Reduce corevm build. coretest still passes.
rrot: r44846 | cotto++ | trunk (8 files):
[ops] remove cpu_ret op
Whiteknight okay, beddy-bye time
later
kid51 Any branches that need a smolder? 02:56
03:04 parthm left 03:32 snarkyboojum joined 03:35 nopaste joined, TonyC joined 03:42 janus joined
cotto Is there a character class for CCLASS_GRAPHICAL in nqp-rx? 03:58
or something that'll let me refer to all non-whitespace characters without enumerating them? 03:59
Austin Yeah.
Lemme look
Graphical = 128 04:00
cotto how do I use that in a grammar
?
Austin What do you get when you cross an elephant with a rhinocerous? 04:01
cotto ... 04:02
Austin Elefino
Pm does some cclass stuff explicitly in pir in $_RX/src/cheats/hll-grammar.pir 04:03
Maybe you have to write a method?
(What is it you want to do?)
cotto as part of a grammar, define words to be a contiguous sequence of CCLASS_GRAPHICAL characters 04:04
There's a 'graph' method on Regex;Cursor but I don't know how I'd use that in a grammar.
Austin That's pretty abstract.
Is that new? I don't have graph 04:05
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.
yeah
04:06 JimmyZ joined
Austin Hell, it looks like you just say <graph> 04:06
Yeah, it's comparable to ident. 04:07
cotto tries
Austin I'm wrong. It's not like ident. 04:08
Ident has a built-in +, while the cclass methods don't. You need to say + yourself.
<graph>+
Please note that doing what you're doing may very well break the implicit assumptions in the whitespace processing code. 04:09
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:10
cotto That's how I'll be using it. 04:11
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 04:32 estrabd joined
cotto What's the regex syntax for inline pir? 04:33
Austin gone, it's inline nqp 04:35
which can do inline pir
moritz but you can use Q:PIR in inline nqp :-)
cotto ok. What's it for inline nqp? 04:36
Austin <{
or <?{
don't forget you're in the "wrong" namespace 04:37
cotto I got the parse tree. That'll be good enough to obviate my need for inline somethingorother. 04:39
04:43 Andy joined
cotto What nqp-rx really needs is a way to warn you when a regex could potentially go into an infinite loop. 04:51
tewk cotto, that feature has a special name, its called the Halting Problem 04:52
moritz tewk: not quite
cotto If we could get that feature, it'd basically solve half the world's problems.
I'll go file a bug. 04:53
moritz if you ignore inline code, it can be done quite reliably
as Perl 5 does it
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
tewk: and that's something that the regex engine can catch
and that'w what I meant by "if you ignore inline code" 04:56
tewk Anyways I'll go away and quit being obnoxious. :) 04:57
04:59 tuxdna joined 05:02 baest joined
dalek rrot: r44847 | mikehh++ | trunk/src/pmc.c:
fix c function docs
 05:12
rrot: r44848 | mikehh++ | trunk/include/parrot/exceptions.h:
fix codetest failure - unwrapped macro argument
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:16
cotto 0 is an atypical number of tests 05:18
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:19
Austin "Note that I have not tested this code, I have merely proven it correct." 05:20
05:20 parthm joined 05:21 baest joined
cotto mikehh, that test wfm 05:24
mikehh it works for me after make world BUT not after make realclean/make corevm 05:28
cotto That's suspicious. 05:30
must have something to do with the corevm cleanup earlier today
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
which
make corevm/make coretest FAILs - t/pmc/nci.t does not run any tests (it PASSes make test) other tests PASS 05:43
all other tests PASS (pre/post-config, smoke (#32584), fulltest) at r44848 - Ubuntu 9.10 amd64 (gcc with --optimize)
dalek rrot: r44849 | darbelo++ | trunk/config (2 files):
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
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 06:03 parthm left
mikehh darbello: after r44849 t/steps/init/hints/linux-01.t fails (post-config tests) 06:30
sorry 06:31
darbelo: after r44849 t/steps/init/hints/linux-01.t fails (post-config tests)
07:03 chromatic joined
dalek p-rx: 2d51ec9 | duff++ | t/nqp/47-fatarrow.t:
Add some tests for the fat arrow
 07:13
p-rx: c441ffc | duff++ | src/NQP/ (2 files):
Make NQP understand single quoted strings on the LHS of =>
07:16 eternaleye joined 07:17 uniejo joined 07:20 aukjan joined 07:21 bacek joined
mikehh tewk: r44844 has a compiler warning in src/pmc.c with gcc - fails to build with g++ 07:23
src/pmc.c: In function ‘Parrot_pmc_new_init_int’:
src/pmc.c:585: warning: passing argument 3 of ‘classobj->vtable->instantiate’ makes pointer from integer without a cast
src/pmc.c:585: note: expected ‘struct PMC *’ but argument is of type ‘INTVAL’
cotto hio bacek 07:24
bacek aloha cotto
howizgoin?
mikehh hi bacek
cotto surprisingly well
I'm pretty close to getting most of the subst calls out of opsc. 07:25
bacek hi mikehh
cotto hopefully you haven't already implemented it. ;) 07:26
bacek cotto, excellent
nope... I tried to improve grammar but failed epically.
cotto I'm also starting to not hate nqp.
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!
cotto bacek, I'm starting to see its beauty 07:28
dalek rrot: r44850 | mikehh++ | trunk/src/call/args.c:
fix compiler warning
cotto mikehh, sure. There should be a simple way to add exceptions to the codingstd tests.
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.
mikehh I think it should be something in MANIFEST or MANIFEST.SKIP otr something 07:30
bacek mikehh, lib/Parrot/Distribution.pm 07:34
mikehh bacek: that looks right - I will have to examine it carefully 07:37
bacek mikehh, starting from line 400
cotto, are you working on ' * Generate something more meaningfull for Ops::Op.body instead of munched string.' from TODO? 07:39
cotto yes 07:40
mikehh bacek: what about the stuff at line 505?
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
also, way easier than bothering to write a full C parser
bacek ok 07:41
Push it as soon as it will do something (even if it's not finished). I can finish it. 07:42
07:42 eternaleye joined
cotto ok. I'll need to go to bed soon anyway. 07:42
I'll give it a few more minutes and commit what's there.
fsvo "a few more minutes"
dalek p-rx: f34ed51 | duff++ | (3 files):
get rid of icky fatarrow2 rule and parse double quoted strings on the LHS of =>
 07:43
cotto like now 07:46
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.
also macro_sanity_check in Actions.pm, but that can be implemented whenever one of us feels like it 07:48
bacek cotto, it's great! 07:49
cotto I'm excited to see how fast it is without the substs
bacek exactly. 07:50
You missed $n variables but I can continue from this point
cotto Those are handled.
macro_param 07:51
bacek ah
my bad
_I_ missed it
cotto (naming was tricky. I should probably revisit it.)
;)
The info you put in the TODO was very helpful. 07:52
bacek I did my best :)
07:53 iblechbot joined
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 /
bacek got to bed! 07:54
cotto++ # Cracking ops grammar!
cotto bacek++ #finishing it
bacek Do we have multis in nqp?
cotto (going to bed)++
I don't think so. 07:55
bacek Or I have fall to pir?
Sigh...
02-parse-all-ops passed and it's VERY GOOD THING! :)
cotto whoops. I forgot to test that. 07:56
I'm sure it's misparsing the macros with double parentheses 07:57
bacek there is no double parentheses in real ops. 07:58
cotto orly?
purl YA RLY.
bacek So we can ignore them safely
Yes, I checked it on the other day.
cotto You're right. There aren't even spaces.
bacek exactly. 08:00
So.
GO TO BED
cotto Fine.
bacek And have a good night :)
cotto Good night.
eof
dalek rrot: r44851 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops (5 files):
[opsc] do most of the work to remove textual substitutions in the op body
 08:03
09:15 fperrad joined 09:17 eternaleye joined 09:20 brooksbp joined 09:26 AndyA joined 09:27 iblechbot_ joined 09:36 riffraff joined 10:16 estrabd_ joined
dalek rrot: r44852 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Grammar.pm:
Use token/rule instead of 'regex' in Grammar.
 10:20
rrot: r44853 | bacek++ | branches/ops_pct/compilers/opsc/src/builtins.pir:
Add say builtin
rrot: r44854 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler (2 files):
Start generating PAST top-down
rrot: r44855 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Actions.pm:
Resurrect merging on 'inline' chunks
a: 91552d9 | fperrad++ | t/lua-TestMore:
update submodule lua-TestMore
 10:34
10:45 estrabd joined 10:58 tuxdna joined 11:14 parthm joined 11:34 aukjan joined 11:53 estrabd joined 11:57 iblechbot joined 12:06 bluescreen joined 12:26 slavorgn joined 12:36 aukjan joined 12:41 parthm left 12:51 tetragon joined 13:00 lucian joined, whiteknight joined
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:01
Coke: i figured out the make vim-install issue 13:02
Coke darbelo++ # auto::warnings 13:04
lucian: very good.
whiteknight hahahaha, today's xkcd is hilarious 13:06
lucian whiteknight: i don't get it 13:10
whiteknight sauron gave rings to all the elves and dwarves
he liked them, so he put rings on them
whiteknight shakes his butt a little
lucian whiteknight: right. i still don't find it particularly funny. perhaps my LOTR illiteracy is part of the problem 13:11
whiteknight ah. Well, it's not for everybody 13:12
lucian whiteknight: i've seen the movies and that's about it (my gf loves them) 13:13
13:15 payload joined
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, fperrad_ joined
lucian Coke: right, a tad funnier :) 13:19
allison lucian: odd that forking bitbucket didn't work, perhaps I should create a dedicated user for pynie? 13:41
lucian allison: it's a bb internal server error. they've had issues yesterday and today 13:42
13:42 bubaflub joined
allison lucian: okay, I'll go look at the bitbucket configs and see what's possible 13:43
lucian allison: ok. you either give me commit access or just wait it out. i can work locally for now 13:44
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?
allison Coke: yah, did I send my reply yet?... checking
Coke I am leaving that to you, as our primary (only?) lp user. =-)
allison coke: sending 13:46
Coke my corevm changes break anything for anyone in trunk?
(they seemed fine on my windows box.)
allison Coke: we don't actually have ownership on that bzr branch
13:46 payload joined
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
lucian: it looks like it's easy enough to grant you write permission on my hg branch of pynie 13:48
13:48 atrodo joined
allison lucian: what's best practice for hg? to have my personal account as primary, or to create a bitbucket.org/pynie user? 13:48
lucian allison: 13:49
allison: doesn't really matter, attribution is done by the commit header 13:50
allison: so your bb account doesn't matter. you can just use primary
allison: s/primary/your own personal/
allison lucian: makes sense 13:51
lucian: what's your bitbucket user name?
lucian: lucian1900?
lucian allison: lucian1900
allison lucian: done, enjoy
lucian allison: bitbucket looks in the commit header for your bb email account or stated name
allison: thanks 13:52
allison: i'm going through dict() calling posibilities. i can't figure out how to introspect params in pir 13:54
allison lucian: from inside the subroutine? 13:55
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?
lucian allison: yes 13:57
PerlJam lucian++ 13:58
allison lucian: so slurpy bundles all the arguments into a list datatype
PerlJam allison: I bet you're glad to have some company on pynie :)
allison lucian: to check the type of the first element, you pull it out, with something like $P0 = args[0] 13:59
then call the 'type_of' operation on it
dalek kudo: a705b41 | jonathan++ | (6 files):
Translate cheating use into NQP and split out need and import. Stubs for various things we'll need (tags, lexical import).
kudo: 5d6aba2 | jonathan++ | src/Perl6/Module/VersionDetectionActions.pm:
Add some comment to say what a file is for.
lucian allison: right. that returns a strign?
kudo: a11211c | jonathan++ | src/Perl6/ (2 files):
Switch symbol importation to lexical by default; actually load modules during the compile. Probably has quirks, but a step towards what we want.
kudo: 8d76887 | jonathan++ | src/Perl6/Grammar.pm:
Actually parse a module_name, rather than cheating and parsing a longname, in use.
lucian slightly hates this keyboard 14:00
allison PerlJam: very much so :)
lucian: $S0 = typeof $P0 will give you the string name 14:01
lucian: $P0 = args[0] will return an object
lucian allison: right, ok. are my googling skills bad today or is PIR documentation lacking?
allison lucian: google links to pir documentation are pretty bad 14:02
lucian: take a look at docs.parrot.org/parrot/latest/html/
lucian: particularly "PIR Book" 14:03
lucian allison: thanks
lucian likes pir's inline docs 14:10
allison lucian: me too 14:16
14:19 bkuhn joined
allison Coke: yay! I'm running 'make coretest' on the branch! 14:19
lucian how do people debug pir? 14:21
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.
lucian Coke: is print more explicit than say? i'd like something like python's repr
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.
if you want to dump the guts of a pmc, see data::dumper in the library. (more). 14:23
say == "print plus a newline"
lucian Coke: oh. ok, i'll look up data dumper
Coke: thanks
Coke github.com/partcl/partcl/blob/maste...s.pir#L257 14:24
I use that in partcl.
then I can just do .dumper($P0) instead of having to explicitly load the dumping library.
lucian Coke: cool. i'll steal it! :)
Coke enjoy
lucian allison: should i put helper macros in any particular place? 14:28
14:40 allison joined 14:41 allison left 14:45 allison joined
allison (firefox blames google calendar, but personally I suspect it's more likely caused by running matlab remotely over ssh 14:46
(with x forwarding)) 14:47
lucian allison: i'd blame virgin, they throttle me to no end 14:51
allison lucian: also possible
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
lucian enjoys the deliciousness of print in an interpreter implementation 14:52
allison: what's the status of objects in pynie? 14:55
allison lucian: the syntax is parsed, but they aren't implemented 14:56
lucian: like dictionary and list, they will be a thin wrapper around the parrot types
lucian allison: right. i miss dir(), but i realised i can't do it without object.__dict__ 14:57
allison lucian: aye, you will need objects before you can start doing lookups on module objects 14:58
lucian: maybe start smaller? 14:59
lucian lucian: i'm hacking dict() now. i've got dict({}) working :)
allison lucian: excellent!
purl plays air guitar
lucian allison: how can i determine if an optional param is empty or not? 15:01
allison: wait, don't answer that. i should read more :)
allison lucian: okay
lucian: look for :opt_flag
(as you're reading)
lucian allison: ok 15:02
15:09 payload joined 15:12 patspam joined, Psyche^ joined
lucian allison: found it, thanks 15:21
lucian is slightly dazzled by pir flow control 15:22
particle dazzled is better than fazed, i hope 15:25
lucian particle: i'm not really used to assembly 15:26
it's just that it takes longer to translate ideas into code
particle well, luckily, pir flow control is better than assembly flow control. except there's the whole 'if()' and 'while()' thing... 15:27
who needs them when you have goto!
PerlJam lucian: that's why I tend to prefer coding in NQP (or some other HLL)
particle lucian, there are macros that provide if, for, while, but i'm not sure how well they deal with nested loops. 15:28
15:28 davidfetter joined
lucian particle: i'll stick to goto for now, it's not bad just unusual 15:28
PerlJam: i'm hoping pynie will be self-hosting at some point
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
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
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
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
lucian particle: right. this is one case where i agree with the existance of unless 15:32
allison: gen_builtins and friends mess up line numbers and filenames 15:36
allison: for build error messages 15:37
allison lucian: yes, the process of "include" combining them all into one file is less than ideal 15:38
lucian: it's done so pynie can be bundled into a single executable
lucian allison: right
allison: also, should i use :multi for dict()? 15:39
allison: i think it would remove a lot of ifs and gotos
allison lucian: in order to handle multiple possible inputs? 15:40
lucian allison: yes. dict(), dict({}), dict((,), (,)), etc
allison lucian: how complicated are possible alternate signatures?
15:40 estrabd joined
lucian allison: bitbucket.org/allison/pynie/src/tip...pir#cl-293 15:41
allison: dict() is missing, though 15:42
allison lucian: aye, throws an "unimplemented" exception 15:43
lucian allison: well, the subroutine is a stub
allison lucian: it looks like dict() can accept a variable number of arguments
lucian allison: i was thinking of having severals .subs with :multi, so i can handle that cleaner
kthakore hi folks 15:44
allison lucian: if you use :multi, each :multi alternate has to have a distinct signature
lucian allison: i know. dict(), dict(seq) and dict(mapping) 15:45
allison lucian: as in signatures a) no arguments, b) a list, and c) a dictionary? 15:46
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)
lucian allison: afaict, slurpy shouldn't be needed for dict() 15:49
allison: dict( (1,2), (2,4) ) seems to be invalid
allison lucian: it's :slurpy :named
lucian allison: yes, just checked on cpython. dict has 1 or 2 arguments, always
allison lucian: that means it collects all the arguments into a dictionary
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
lucian allison: right. so because of that, i can't use multis
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
dalek nxed: r433 | julian.notfound++ | trunk/examples/pirado.winxed:
parse subs and main flag in pirado
allison lucian: well, the :slurpy handles that case too, it's an empty result
lucian: (:slurpy is happy to consume anything or nothing) 15:52
lucian allison: right. that kinda sucks. i'll stick to gotos then
allison lucian: so, :slurpy takes care of the variable arguments
lucian: it looks like the other cases are all one argument? 15:53
lucian allison: yes
allison: i wish for python's kwargs in pir :)
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
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
lucian allison: it's like multi, but more explicit. so you could do just this
particle: can you dispatch separately if you have arbitrary arity, but with keyword arguments?
allison lucian: that looks like :named args/params 15:56
particle :slurpy :named
:slurpy 15:57
lucian particle: yes, but that'll eat up the arity=1 and arity=0 cases
Coke parrot, do more in this challenging economic times with gotomeeting.
particle those are the two sigs
lucian: is the parameter named in the arity=1 case?
lucian particle: no
allison lucian: the equivalent of test_var_args_call(**kwargs) in pir is test_var_args_call(kwargs :flat)
lucian: (assuming kwargs is a dictionary-like key/value pair set) 15:58
lucian allison: and can i use that in a multi?
allison: or will it try to flatten the 1 arg? 15:59
allison lucian: on the parameter side, you'd say .param arg1 :named
lucian: it will flatten the 1 arg if you tell it to using :flat
lucian: it won't flatten the arg automatically
lucian allison: right. trying it now
allison lucian: (we tend to be very explicit about these things, since difference languages want different behavior) 16:00
lucian allison: right, makes sense
does .local come with a perf hit? 16:01
allison lucian: on the definition side:
def test_var_kwargs(farg, **kwargs):
is equivalent to
.sub test_var_kwargs
.param pmc farg
.param pmc kwargs :slurpy :named
particle .local is strictly for human-readability 16:02
lucian yeah, that i had inferred
allison lucian: .local is a very fast alias to the register
Coke lucian: .local as opposed to $P0 ?
hell, $P0 is an alias.
lucian Coke: yes
allison lucian: no overhead compared to $P0 direct access to the register
Coke there is no way in PIR to directly access the registers like there is in pasm.
lucian allison: ok, then what's the point of $P in the first place?
allison lucian: lexical variables are another matter
lucian: originally there was only direct access to the registers P0, I0, etc 16:03
lucian: then we added automatic allocation, and prefixed that with $P0
lucian allison: right
allison lucian: .local is verbose for code under 3 lines
Coke and then we removed direct access. =-)
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
particle but $P0 is easier for pir-generating compilers 16:05
lucian particle: that makes sense
allison: btw, there's also dict(iter) 16:15
allison lucian: it sounds like a signature with one optional pmc argument and one :slurpy :named argument will catch all the cases 16:16
lucian allison: yes it does, but i was hoping for some patern mathing to reduce the number of gotos 16:17
allison lucian: or you could multidispatch on that based on the type of the first argument 16:18
lucian: but only if you never plan on using the **kwargs behavior
NotFound There is some reason to not have an opcode invokecc_pc ? 16:19
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
allison lucian: that's dynamic dispatch, but not multiple dispatch 16:20
lucian allison: i know, i was just saying that works 16:21
allison: and i'm not sure how to handle it
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
allison lucian: that's :flat 16:23
it flattens out the variable created by {}, and passes it as keyword args
lucian allison: oh, right ** == :flat 16:24
allison aye
lucian allison: i'm dropping multis, going with my working goto-laden single .sub 16:34
allison lucian: sounds good 16:35
16:38 wagle joined
allison lucian: there are always options to refactor later 16:40
lucian allison: yeah. i was hoping to get away with nicer code from the start, mais c'est la vie 16:42
is there a pir interactive interpreter? 16:47
particle no 16:48
but 'parrot -'
allows you to feed pir subs in, hit Ctrl-Z, and it'll run
lucian particle: right, that'll do. thanks
bubaflub lucian: you can use parrot_shell, in perl tools/dev/parrot_shell.pl 16:52
16:52 wagle joined
bubaflub type in some lines of PIR and then end it with a . 16:52
the shell will run it
lucian bubaflub: oh, nice. thanks 16:53
particle bubaflub++ 17:02
17:06 theory joined
dukeleto 'ello 17:14
yay, people are using the parrot shell! bubaflub++
tewk: ping
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
s/either//
tewk dukeleto, pong, I got your tests checkin coming shortly 17:16
dukeleto tewk: sweet! 17:17
bubaflub: yes, i am looking at recent commits and saw that fly by. nice! 17:18
17:18 PacoLinux joined 17:19 bacek joined
dukeleto bacek: o hai 17:19
bacek dukeleto, aloha
17:20 aukjan joined
tewk t/pmc/fixedintegerarray.t .. 1/30 init_pmc() not implemented in class 'FixedIntegerArray' 17:20
$P0 = new ['FixedIntegerArray'], 10 17:21
cotto hi bacek
bacek morning cotto
cotto just committed a thing
it does some stuff
tewk The 10 seems to be getting autoboxed into a PMC, thats not good
bacek good
cotto since I'm committed to my job, I also need to go do some stuff
bacek I changes PAST generator yesterday.
cotto yes. It's improved. 17:22
bacek changed
cotto thanks
bbs
dalek rrot: r44856 | cotto++ | branches/ops_pct/compilers/opsc (5 files):
[opsc] make jump flags accessible to Trans, remove a mostly-done TODO item
 17:26
dukeleto tewk: yes, the error seemed odd to me, since we are passing in an int 17:29
tewk How dukeleto I'll just comment out the tests and commit, I need to work on something else today. 17:32
dukeleto tewk: i didn't commit the test 17:40
tewk dukeleto, I just did :)
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?
dalek rrot: r44857 | tewk++ | trunk (11 files):
VTABLE_init_int commented out tests
 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.
the new ones are at the end bacause I put them into experimental 17:44
17:45 brooksbp joined
dukeleto tewk: ok, maybe someone on the list can shed some light on it 17:46
17:47 lucian joined
cotto_work good marooning 17:56
tewk, what's br0ken?
other than my kb
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:57
NotFound tewk: or maybe just imcc does his own magic instead of searching for an appropiate op. 17:59
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 nxed: r434 | julian.notfound++ | trunk/examples/pirado.winxed:
sub calls and .return, only with empty args and returns, in pirado
cotto_work tewk, I was wondering if that might have something to do with it. 18:07
18:14 ruoso joined 18:34 whiteknight joined
Coke parrotshell? 18:46
cotto_work whiteknight, the pre tags in your blog post make some of the quoted conversation be hidden 18:57
whiteknight really? damnit 18:58
cotto_work I have a pretty wide monitor too
typo: "BigInt nd BigNum" 18:59
19:00 theory joined
dukeleto Coke: the parrot shell is tools/dev/parrot_shell.pl 19:02
Coke: it is a parrot REPL 19:03
19:03 aukjan joined 19:06 chromatic joined
dukeleto chromatic: mornin' 19:10
19:12 denisw joined
denisw hi 19:12
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
whiteknight EFIREFOXCRASHED 19:15
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?
denisw allison: ? i thought classes are immutable after instantiation 19:17
allison denisw: see Protoobject.pir
denisw: in the base object model, yes
denisw allison: does that have accompanying documentation? 19:18
dukeleto denisw: docs.parrot.org/parrot/latest/html/ 19:19
denisw: that will always be the most up-to-date docs 19:20
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:21
19:25 theory joined 19:28 ruoso joined
denisw allison: doesn't that implement perl 6 protoobjects which is a different concept? 19:30
allison denisw: yes, you wouldn't want to use that protoobject implementation 19:32
denisw: but it demonstrates that a prototype-based object model can be dropped on top of the Parrot model
denisw allison: so i have to roll my own?
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
denisw: yes, but it should be pretty simple
whiteknight: potentially, yes, if we can make it generic enough to support the needs of a collection of languages 19:34
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
plus, many languages would be able to make use of our built-in version with ease
allison whiteknight: providing base features that make it easier for new languages to get started are a definite advantage 19:37
19:37 slavorg joined
whiteknight what would be the first step for somebody interested in such a project? Draft a PDD? implement it externally, etc? 19:38
allison whiteknight: an added section to the PDD would work, just outlining the API 19:39
19:39 AndyA joined
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
allison whiteknight: it's just part of Parrot's base object model
(if we decide to make it core)
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?
whiteknight yeah, I suppose
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
allison whiteknight: under Definitions, it needs to define "prototype", and then add a section for "Proto PMC API"
whiteknight gotcha
I'll kick some ideas around and write a draft
denisw cool
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
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
ah, that's true
cotto_work Lua's still using TGE, isn't it?
darbelo Yep. 19:43
denisw i would love to have that for a parrot-based ecmascript5 implementation
whiteknight urg, I am not a fan of TGE
19:44 kjeldahl_ joined
denisw whiteknight: the official lua documentation has a good explanation on doing OO with lua 19:44
whiteknight: one moment
allison whiteknight: it hasn't had much attention lately
Coke dukeleto: a url is what I was looking for.
parrotshell is tools/dev/parrot_shell.pl
(feed the bot)
denisw whiteknight: www.lua.org/pil/16.html
whiteknight denisw++ 19:45
denisw basically, lua tables can reference "metatables" to which table lookups are delegated when the main table's ookup fails 19:46
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?
allison whiteknight: yes, a prototype should act as a class and as an object, fully integrating with the current system 19:50
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
yes, there definitely is some cleanup needed there
whiteknight anyway, its an issue to worry about later. Rakudo* is #1 priority for now 19:52
particle is lua prototype based oo? 19:53
dukeleto Coke: svn.parrot.org/parrot/trunk/tools/...t_shell.pl
denisw allison: actually, a class system is more easily done _on top_ of a prototype system than the other way around
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"
tewk dukeleto, new $P0, ['FixedIntegerArray'], 10 should be new $P0, 'FixedIntegerArray', 10
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
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.
denisw particle: giving you a prototype-like delegation chain
particle denisw++ # thanks for the lesson
denisw particle: no problem :) 19:57
tewk With brackets you get a object that inherits from 'FixedIntegerArray' I think
dukeleto tewk: yes. death from a thousand cut and pastes
denisw gotta go now, i'll sure come back here and track the progress on a prototype model whiteknight 19:58
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
denisw dukeleto: ok i'll do 19:59
anyway, really got to go now, see you soon
20:00 bacek joined
TimToady phone 20:00
dukeleto TimToady: those devices scary me 20:01
scare, even
Coke crap. will be a few moments late. 20:04
Houston++ 20:09
tewk so if you pass a Integer PMC to VTABLE_instanciate, should it call init_int? 20:10
20:12 AndyA joined, allison joined
particle tewk: i say no, a pmc is a pmc 20:13
Coke yah, this isn't a method. 20:14
(no autoboxing)
whiteknight tewk: you may not be able to instantiate a user-defined class with an integer value 20:15
would need instantiate_int, and that doesn't seem necessary since all Object attributes are PMCs anyway
no sense avoiding the box when all attributes get boxed anyway
NotFound instantiate with initializer is almost unusable, anyway. 20:18
whiteknight just computed the stats, in the SVN repo at work I account for 52.23% of all commits 20:19
methinks the other people don't understand the "commit early, commit often" mantra
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:21
whiteknight it's not a competition. In fact it's a little depressing 20:22
20:34 payload joined 20:35 payload1 joined
tewk whiteknight, the problem is that new ['FixedIntegerArray'], 10 finds a class (PMCProxy) so it wants to call instanciate. 20:37
Is this the new best practice way of creating PMCs? 20:38
whiteknight hmm... I'm not sure I was aware of that
tewk new 'FixedIntegerArray'
The funny thing is PMCProxy_instantiate turns around and calls Parrot_pmc_new_init. 20:40
darbelo How quaint.
tewk It seems that new and instantiate opcodes at least for this use case are synonymous
s/opcodes/vtables/ 20:41
darbelo We need to cut down on indirection.
chromatic 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.
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.
whiteknight ditto
there's so much special-purpose code we can get rid of, and so many things we can optimize 20:45
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
tewk We should probably start unifying some things and dropping unneeded backwards compatibility. 20:46
whiteknight First step is probably to reduce the number of C-based PMC types 20:47
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
whiteknight tewk: instantiate is used by the metaobject to create things, init is run on the object itself after creation
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
BUT... it's a great idea for Objects 20:50
cotto_work I didn't know the built-in types needed explicit instantiation.
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
tewk They do if you pass them ['PMCNAME
NotFound whiteknight: I think we can already insert NCIs in namespaces.
tewk ']
cotto_work Where's the code that does that?
purl i think the code that does that is only 3 lines, plus some image magick magic.
cotto_work no, the code that does that is still in my head 20:52
purl okay, cotto_work.
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
NotFound whiteknight: to include predefined classes in core, you mean? 20:53
whiteknight NotFound: yes, exactly
NotFound Sounds good.
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?
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.
purl cotto_work, I didn't have anything matching sounds good
cotto_work forget sounds good
purl cotto_work, I didn't have anything matching sounds good
whiteknight so if we could start making inroads for that kind of mechanism, it's a good start
20:55 theory joined
cotto_work bacek, is there any purpose for compilers/opsc/opsc.pir other than to aggregate all the opsc pbc files into one file? 20:59
Coke (pmcs in pir) those are called objects, neh? 21:01
whiteknight Coke: depends. A ResizablePMCArray isn't an Object
bacek cotto_work, no already
Coke whiteknight: it would be if it were written in PIR, is what I'm saying. at least today.
whiteknight Ah, true
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
for METHODs, a PIR version would just be a Sub in the PMCProxy 21:03
would also need a bootstrapped build, since we would need a PIR compiler around to build them 21:04
could happen immediately for dynpmcs without bootstrapping though
cotto_work whiteknight, the opsc work bacek and I are doing is part of making that possible. 21:06
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:07
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
whiteknight .op "foo"\\n .param pmc arg1 ...
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
Coke lucian: $I0 = and $I2, $I3 21:10
lucian Coke: i was trying and $I0, $I2, $I3 as per the doc, didn' twork
PerlJam lucian: are you expecting bitwise and or logical and? 21:11
lucian PerlJam: logical
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
lucian allison: right, i'll try Coke's syntax
The opcode 'and_i_i' (and<2>) was not found 21:13
for $I0 = and $I2, $I3 21:14
similar for and $I0, $I2, $I3
found the problem. i was doing and has_sequence has_mapping, where the two are .param :opt_flag 21:18
it wants me to put them in registers first and then and on those
21:19 patspam joined 21:20 iblechbot joined
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 nopaste.snit.ch/19906
Coke lucian: that outputs 0, 0, 1 21:29
allison lucian: it's not reliable though
lucian Coke: this bit doesn't work for me $I0 = and has_a, has_b. for some reason
Coke lucian: does my sample output 0\\n0\\n1\\n for you?
21:30 snarkyboojum joined
lucian Coke: yep 21:30
Coke ok. then we just need to figure out how your code is idferent.
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
Coke lucian, can you nopaste your code that fails?
lucian Coke: in a minute
allison: i find pir's idea of boolean operations very incosistent 21:32
allison: it seems a very bad idea to have $S0 = "0" eval to false 21:33
Coke: wait, now it works. diffing to see what's changed
21:35 lichtkind joined
lucian Coke: missing comma it seems. stupid. but the error message confused me 21:35
it said The opcode 'and_i_i' (and<2>) was not found
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
Coke lucian: right. the reason that makes sense is that the opcode is really add_i_i_i 21:38
$I0 = and $I1,$I2 == sugar for and $I0,$I1,$I2
lucian Coke: right
Coke hey, allison, do we need commas to separate opcode args? 21:39
(i know we do /know/)
er, NOW.
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...
allison Coke: could work just as well without them, it's largely for clarity
Coke NOW is also the catchphrase of Jack Bauer.
purl okay, Coke.
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"
lucian i keep doing opcode arg1 arg2
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
allison lucian: It is partly auto-unboxing, but it's also a design decision of the Parrot core types
lucian allison: ok, fair enough 21:42
allison lucian: but, any data type is free to over-ride the behavior
lucian allison: i know PMCs can, but $S/$I can't
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?
allison lucian: in general, an HLL type corresponds to a PMC, not to a bare register
lucian allison: right, ok
allison lucian: because HLL types may have methods defined on them, etc 21:44
Coke s/in general//
allison Coke: also true 21:45
lucian yeah, i imagine C on parrot might not want to do that
Coke -> 21:51
NotFound You can imagine C on parrot? :o 21:55
darbelo There used to be a c99 parser in languages/ 21:56
I submitted a GSoC proposal to ressurect it two years ago.
NotFound A parser has no problems with runtime data types ;)
cotto_work Close is... um... close. 21:57
21:57 theory joined
lucian NotFound: parrot seems general enough to me to host C, and it might be useful 21:59
NotFound lucian: I can dream with it, but fail to imagine. 22:00
(and the dream can be a nightmare)
lucian NotFound: crypto libs that don't depend on platform binaries
darbelo Hmm. 22:02
dukeleto: ping
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 ;)
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
cotto_work It's possible if you've got the itch. 22:05
lucian cotto_work: yeah. gcc or llvm backend? 22:06
darbelo purl: msg dukeleto 'Pick and ressurect a language from trac.parrot.org/languages/browser ' might make for an interesting GSoC project...
purl Message for dukeleto stored.
lucian i vote for chitchat! :)
dukeleto darbelo: pong 22:07
Tene I should migrate chitchat to nqp-rx eventually.
darbelo dukeleto: Read the just sent purl-o-gram.
Tene it was a fun parser to write.
The grammar is pretty much complete, as I recall, it just needs to have a library written for it.
darbelo I'd like forth myself.
22:07 joeri joined 22:08 kurahaupo joined
dukeleto darbelo: i think we are going the route of only having parrot-core projects for GSoC, i.e. not HLL's 22:08
darbelo: that is what we did last year and I think we are continuing that
darbelo: but that is a good quesiton to bring up on -directors and/or -dev 22:09
darbelo: i think the motivation is that there is still lots of stuff to do in core and those things benefit all HLL's
lucian dukeleto: jit! :)
darbelo dukeleto: I understand the rationale, just wanted to point out a newbie-friendly publicity oportunity for our compiler tools. 22:10
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
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
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.
dalek kudo: d0a4488 | duff++ | src/Perl6/Actions.pm:
Use &eager to Parcelize the statement modifier for loop
 22:13
darbelo dukeleto: Making frame builders compile-time pluggable should be manageable, run-time pluggable is unlikely. 22:14
But it's not the most encapsulated part of parrot's internals 22:15
Also, doing the cleanup work to encapsulate framebuilders *and* write one from scratch is probably pushing it. 22:18
At least for somebody who'll have to learn the codebase.
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?
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
darbelo lucian: Yes.
lucian i'm thinking that llvm should be able to optimise across pbc instructions even if the jit just does patching 22:23
22:26 Whiteknight joined
dukeleto darbelo: compile-time pluggable would be fine in my book 22:32
22:33 AndyA joined
Whiteknight chromatic: ping 22:34
darbelo dukeleto: I would still aim at just making them pluggable, and importing plobsing's libjit famebuilder rather thatn writing a new one. 22:35
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
chromatic pong, Whiteknight
dukeleto darbelo: nothing a little napalm can't fix
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
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:37
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.
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:39
chromatic Yes, there should be one failure in p6object.t 22:40
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
so is this branch tackling all those issues, or just the issue of method storage in the namespace? 22:42
chromatic Just the latter.
Whiteknight okay. So we should probably create new tickets to separate out the other stages of work 22:43
chromatic That sounds reasonable.
dukeleto darbelo: so what you are saying is that we need more chainsaws ? 22:44
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:46
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.
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.
cotto_work and with adequate protective clothing
dukeleto darbelo: stapled open, you mean :)
cotto_work chromatic, would it be possible to use lexicals to make pir Test::More TODOing more user-friendly? 22:49
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
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.
cotto_work find_dynamic_lex doesn't do something like that? 22:52
dalek tracwiki: v50 | cotto++ | ParrotQuotes
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
rrot: r44858 | whiteknight++ | branches/tt389_fix/t/pmc/complex.t:
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.
rrot: r44859 | whiteknight++ | branches/tt389_fix/t/pmc/integer.t:
adding another test, modified from a failing example in TT #562. It fails in branch and needs to un-fail
kudo: 0a0469e | duff++ | src/Perl6/Grammar.pm:
parse version and need
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
chromatic Whiteknight, why are you unTODOing TODO tests?
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)
dukeleto: I'm not sure frame builder is big enough. what happens if the student finishes halfway thru? 22:57
dukeleto: also, what are the requirements on a mentor?
darbelo We make him build another one?
dukeleto plobsing: then the student writes docs, more tests, blog posts, maybe does a few extra features 22:58
plobsing dukeleto: ok
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
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
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?
that was fast
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.
dukeleto but i will say that I enjoyed the mentoring experience, even though it was occasionally time-intensive
darbelo: yes, students should consider it a full time job. 23:02
23:02 TiMBuS joined
dukeleto plobsing: i helped write a book about gsoc mentoring: en.flossmanuals.net/bin/view/GSoCMentoring 23:02
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:03
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:04
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
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
change, even
plobsing: the gsoc 2010 timeline socghop.appspot.com/document/show/g...0/timeline
Coke iwbni? 23:08
purl hmmm... iwbni is "it would be nice if"
plobsing dukeleto: thanks for the info. will get back to you ASAP on that. 23:09
dukeleto plobsing: thanks! you have at least a week or so to decide 23:10
lucian allison: an :opt_flag for a :named :slurpy parameter doesn't always return the same value for the same input 23:12
allison: pastie.org/864154 23:13
Coke lucian: what input are you feeding that that is changes? 23:17
*changing
lucian Coke: i'm calling dict()
Coke: some calls print 1 for has_mapping, some call 0 23:18
s/some call/some print/ 23:19
Coke lucian: wfm. 23:20
you know you have 2 print statements there, yes?
s/print/say
lucian Coke: yes. i'm talking about the second one
Coke yes. always prints 1 for me.
lucian Coke: on the first dict() call, it's 1. on subsequent calls it's 0 23:21
Coke not here.
lucian i can't see any state anywhere
Coke let me show you my slightly modified program that highlights this:
lucian Coke: then it's a bug in pynie's interp
Coke (have to install some cpan...) 23:22
lucian Coke: when calling 'dict' from pir code, it works 23:23
Coke: when i call it from pynies repl, it prints 0 for all calls but the first
Coke what is "pynie's repl" ? 23:26
(url to source code repo?)
23:27 patspam joined
Coke (wow does WWW::Mechanize have a lot of deps =-) 23:27
(and yah, I only tested it from PIR)
lucian Coke: the pynie interpreter's repl bitbucket.org/allison/pynie/ 23:28
23:28 kurahaupo joined
Coke oh, I thought you meant a specific method. 23:29
not "the REPL". =-)
lucian Coke: oh, right
my bad
Coke oh, no worries.
purl i heard no worries. was my smoke harness code public?
23:30 TonyC joined
Whiteknight chromatic: TDD. See the test failures, make them not fail 23:32
lucian Coke: it's quite late here, i'll try to figure this out tomorrow 23:34
good night everybody!
Coke: thanks for looking into it, btw
Coke ~
np. I know how frustrating it is to be a HLL developer! ^_^
Whiteknight chromatic: we can re-todo them if you like it cleaner
chromatic I don't like having to remember which failures I expect and which I don't when I run the test suite. 23:38
dukeleto chromatic: yeah, that ires me. the test suite should always pass on trunk. if it doesn't, there is a problem 23:39
23:40 nopaste joined
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
dukeleto chromatic: ah. then that depends on the branch, i guess 23:42
Whiteknight chromatic: in the hll_mmd_fix branch, I notice that there is never a fallback to the VTABLE of the PMCProxy parent 23:44
chromatic Right. Sometimes that's right and sometimes it seems wrong. I didn't find a good general rule for that. 23:45
Must commute now though.
Whiteknight in half the vtables, there is a fallback to the delegate object, and in half not
chromatic Exactly.
23:47 eternaleye joined 23:48 Andy joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!