#parrot Parrot 2.1.1 Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Tasks: PCC deprecations hackathon on Saturday, TT #389 branch
Set by moderator on 5 March 2010.
dalek rrot: r44781 | allison++ | branches/pcc_hackathon_6Mar10 (2 files):
[pcc] Removed two deprecated and unused functions for setting return arguments
 00:01
allison chromatic: oooh, no that's bad
chromatic: it's setting it to null right after fetching the *arguments*, which means it's gone once you get to the return 00:02
chromatic Yep.
allison a throw-back to a bygone era where calls and returns were different 00:03
chromatic It looked suspicious.
allison and worked when we were doing the funny pointer saving trick
chromatic Removing it gives different errors. Are they better errors? 00:04
Whiteknight different is always better
allison we probably need to add code to null out the signature in get_results and equivalent 00:05
now that those are the final step of the call sequence
00:07 tetragon joined
lucian Austin: padre on os x is quite bad 00:08
Austin lucian: Really?
Is it a gui thing, or is there more?
lucian Austin: they do say it's experimental
Whiteknight I havent used padre in a while. probably time to upgrade
lucian Austin: quite a few GUI things are broken 00:09
the text rendering isn't very good, but that's a known wx bug
Austin whiteknight: I took a look a few weeks back, and decided it wasn't time yet -- still no multi-window support.
Whiteknight what I care about most is C syntax highlighting
lucian heh, the font chooser dialog appears for 0.1sec and then dissapears 00:10
Austin C?
purl C is for cookie, and it's good enough for you. or chromatic
dalek kudo: 3cc313f | jonathan++ | src/Perl6/Module/Locator.pm:
Include alternative versions of modules in the candidate list too.
kudo: 8b2fb24 | jonathan++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get readdir that works on Win32.
kudo: aa8c65e | jonathan++ | (5 files):
Identify version and authority properly for each module in the candidate list. Choosing latest if multiple versions are found now appears to work (though requesting specific version/authority is NYI).
Austin Geez, dude. What kind of luser still codes in C? Haven't you heard of dynamic languages?
lucian padre is a bit too young for me, i'll stick to vim
Whiteknight how do I tell cpan to "yes, always install prerequisites"? 00:11
Austin --dwiw ?
lucian Austin: editra is mostly the python counterpart to padre
allison chromatic: did you check in the removal of the stray sig nullification? 00:12
Coke Whiteknight: o conf mumble de mumble
o conf prerequisites_policy follow
(while in CPAN shell)
Coke tries padre on os x; certainly easier to install than the windows version. =-) 00:16
er, sorry, than the cpan version. 00:17
Whiteknight padre failed mak on my system 00:18
so that answers my question
chromatic allison, I didn't. Should I?
GeJ Good morning everyone 00:19
00:19 Maddingu1 joined
Coke hurm. no build troubles for rakudo on osx. 00:20
allison chromatic: it's the right fix, so go ahead 00:24
chromatic: whatever error comes after we'll tackle next
chromatic kablammo
Whiteknight how do I get the GTK+ development files? 00:28
chromatic too many positional arguments: 2 passed, 1 expected
current instr.: 'parrot;P6metaclass;register' pc 576 (runtime/parrot/library/P6object.pir:425)
Does the CallSignature need reset somehow? 00:29
... that'd be morph. 00:33
dalek rrot: r44782 | chromatic++ | branches/pcc_hackathon_6Mar10/lib/Parrot/Pmc2c/PCCMETHOD.pm:
[lib] Removed CallSignature NULLing at the start of PCCMETHODs, as reusing the
 00:34
rrot: r44783 | allison++ | branches/pcc_hackathon_6Mar10/src/call/args.c:
[pcc] Remove unused static function to set a default return value (returns now
allison chromatic: the morph happens in Parrot_pcc_build_call_* 00:36
Coke wonders if everyone that is working on rakudo has a quad core machine with 16G of memory. 00:37
allison chromatic: but the morph should only happen between call and return
chromatic Parrot_pcc_build_call_from_varargs seems to do it.
allison chromatic: between separate calls, the call_sig should be nulled
chromatic: aye 00:38
chromatic Looks like that morph is happening anyway.
allison the morph will happen anytime an active call sig is passed into Parrot_pcc_build_call_* 00:39
it's safe to reuse the same call sig pmc between calls
but the spec says different call sigs
dalek tracwiki: v24 | allison++ | CallingConventionsTasklist
tracwiki: trac.parrot.org/parrot/wiki/Calling...ction=diff
allison hmmm... looks to me like the call sig isn't getting nulled between calls 00:40
chromatic Maybe morph is missing something. 00:41
allison chromatic: morph only nulls the signature elements, nothing else 00:46
chromatic: because between call and return that's all that changes
chromatic: the set_args op ignores the current value of the current call sig, just creates a new one and stuffs it into place 00:49
so, that's okay
some other call path might not be doing the same
chromatic num_positionals is 2. 00:52
allison chromatic: aye, and I'm sure if you look into it, the first one will be from a previous call or return 00:53
with the expected arg for the current call pushed on after the old arg
we could get around all this if we didn't recycle callcontexts for return signatures 00:54
but, I'd rather avoid thrashing the GC with double the number of PMCs for every call
chromatic Wild thought. 00:55
Pushing the invocant at the start?
dalek tracwiki: v25 | allison++ | CallingConventionsTasklist 00:56
tracwiki: trac.parrot.org/parrot/wiki/Calling...ction=diff
allison chromatic: okay, Parrot_pcc_build_sig_object_from_varargs doesn't do the morph trick, is anything still calling that?
one call in src/call/pcc.c 00:57
from Parrot_PCCINVOKE
chromatic Here's your problem. 00:58
allison and a couple of calls to that from src/pmc/role.c
yah? 00:59
purl yah is at a point of agreement almost
chromatic Returning from a method means you don't unshift the invocant.
Whiteknight hates the cpan client. It's always painful
allison chromatic: ? 01:00
chromatic: the invocant should be stored as one of the regular args, and so nulled out when the rest of the sig storage is nulled 01:01
chromatic: that is, interp->current_object is nulled as soon as the sig is created, so it's not around later
nopaste "chromatic" at 173.50.130.127 pasted "-t" (30 lines) at nopaste.snit.ch/19885
"chromatic" at 173.50.130.127 pasted "Don't unshift the invocant when reusing a CallContext" (30 lines) at nopaste.snit.ch/19886 01:02
01:03 abqar joined
allison chromatic: ensuring that the invocant is only added on call signatures, not on return signatures? 01:03
chromatic: that's a reasonable fix for now
chromatic I can do better.
allison eventually would like interp->current_object to go away 01:04
and use the Pi signature everywhere
chromatic In theory, we can null it out in returns from PCCMETHODs. 01:05
allison we can null it as soon as fill_params happens 01:06
really, we can null it as soon as the call sig is created
(on the argument side, long before the returns) 01:07
nopaste "chromatic" at 173.50.130.127 pasted "Empty it in PCCMETHOD returns" (12 lines) at nopaste.snit.ch/19887
allison chromatic: does that fix the bug? 01:08
chromatic Checking.
Seems to. 01:09
allison cool 01:10
chromatic Looks like positional parameter arity checking is way too strict for returns now.
Coke does "make -n install" in a perl5 checkout and is hella confused.
01:10 abqar joined
allison chromatic: as in, it's not silently ignoring extra return arguments? 01:11
Austin Hmm... does this mean I can do named returns, now?
allison Austin: aye
Austin: anything that's supported in a call is supported in a return now
Austin Nicholas Wirth's head just exploded.
chromatic As in "I'm returning an empty list, but the caller wants to bind four values".
allison Austin: (it's just the same code)
chromatic: well, shouldn't that be an error? 01:12
chromatic Try to build pbc_to_exe.
allison chromatic: return params can be marked as :optional
chromatic see tools/dev/pbc_to_exe.pir line 35 01:13
allison looking...
chromatic Then lines 153 and 162.
allison yah, good example 01:15
chromatic I can't argue that should be an error. 01:16
allison chromatic: calls and returns aren't spec'd to behave differently here
chromatic: (reread the PDD to be sure) 01:17
chromatic: it's a bug in the implementation that crept in because they weren't following the same code path
chromatic: we can either declare it a bug that's now fixed, or declare it a feature that requires a deprecation cycle 01:18
chromatic: does tagging the returns with :optional work? 01:19
chromatic It gets past that bug anyhow. 01:20
allison well, that's the sensible thing, since return signatures are parameters 01:21
chromatic I'm going to have to convince myself I like that behavior. 01:22
allison long-term, I don't want any code differences between calls and returns (too much chance for maintenance errors)
but in the short term I'm open to saying this is a feature that requires deprecation 01:23
maybe ask the HLL devs if they were depending on it?
it boils down to being very explicit at the VM level, so HLLs have the flexibility to choose their behavio 01:24
chromatic We should do that, but we also need to consider how we work around it if we decide to keep it temporarily.
allison chromatic: two code paths
chromatic: there's not really any other way to do it
okay, we could hack up the fill_params code for it 01:25
but, that just makes it harder to remove after 2.3
and since we're talking about 1 month of deprecation... not worth the hack
chromatic This means a lot of potential fixups. 01:27
allison chromatic: in outside code? 01:35
chromatic: potentially
chromatic Potentially yes. 01:36
allison chromatic: a quick hack would be to modify IMCC to mark all return signatures as :optional for now
Whiteknight are we really silently treating all returns as optional now?
even with error checking on? 01:37
allison apparently
chromatic Yes.
allison though... I wonder
Whiteknight better question: were we doing this before the last PCC refactor?
chromatic I believe so.
Austin ++ # Another passing testcase.
Whiteknight ok
allison did pbc_to_exe have return checking turned off?
Whiteknight I don't even remember when pbc_to_exe was converted to PIR 01:38
allison because one problem I do know currently is that the param filling code doesn't check the interpreter attribute for whether to flag return count mismatches
it only checks the attribute for parameter mismatches 01:39
Austin ++ # Another passing testcase.
allison chromatic: if it was a bug introduced in the last refactor, we're safe to just call it "fixed" 01:40
chromatic particle and I converted pbc_to_exe to PIR a couple of years ago.
allison that particular call could be a later addition, though
chromatic git annotate says that Francois last touched it last July. 01:42
allison then it's been around a while 01:43
Coke as long as you're fixing things, are you going to make no-param subs strict?
Whiteknight that would be nice
allison Coke: strict how?
Coke (wozzit, RT#39844?)
Whiteknight allison: subs with no params dont check arity
Coke aka trac.parrot.org/parrot/ticket/1033 01:44
Whiteknight I think it was a hack to allow :main to be declared with no params
Coke it's very very old.
and is also causing issues for rakudo: 01:45
rt.perl.org/rt3/Ticket/Display.html?id=56366
allison Coke: I thought that was fixed in the previous refactor
Coke: I guess not if it's still affecting Rakudo
Coke never been fixed.
SFAIK>
Coke checks the test.
allison heh, I like the simple patch that deletes the code in IMCC to hack around parameter checking... 01:46
Austin ++ # Another passing testcase.
Coke pir_error_output_like( <<'CODE', <<'OUTPUT', "arg mismatch with no params", todo=> 'TT #1033' );
I have no problem with a fix that either forces :main to have the required .param decl, or that makes :main special and allows it to ignore argv. 01:47
allison if we are making a special case for subs marked :main, it should only apply to subs marked :main
Whiteknight +1 01:48
purl 1
Coke allison: I don't think anyone knows for sure why it is that way now. the :main thing is just the mostly like "what were they thinking"
Austin What about subs that get treated as main because they're first in line, and there is no :main
Coke that's the same as :main. =-)
allison (and subs that happen to get the "main" quality by simple virtue of being first don't get the same treatment
chromatic :main is because arity checking the command line invocation is a real son of a gun.
Coke chromatic: not if you force :main to be :slurpy 01:49
(which is the only sane approach)
Whiteknight chromatic: that shouldn't matter if a :main only takes a single string array
or, do we do more processing on argv than that?
allison well, someone might want to, but if they do they can declare their own parameter signature
Whiteknight okay, I'm off to bed. Goodnight 01:50
allison at the point of that hack in IMCC, we have the sub object and can check if it was flagged :main 01:51
Austin Whiteknight:
Coke allison: ISTR that there was some reason why I couldn't get that to work. If you can, go for it. =-)
allison okay, if people in the US are going to bed, that tells me I'm up way too late :)
Austin I'm about to commit the Cuckoo stuff. Mocking finally works.
Coke it's only 9pm eastenr
allison Coke: yah, not in this refactor, but will look into it
Coke Austin, I've been able to mock you for some time. Code doesn't help. 01:52
allison Coke: mainly just hoping to merge this in quickly, so want to limit the scope
Austin Sure, Coke, but could you arbitrarily mock anything else?
chromatic is done for the night here, needing to work on other things 01:53
Austin my $proto := cuckoo( Some::Class ); my $obj := $proto.new ; calling( $obj ).foo( 1 ).will_return( 7 ); $obj.foo( 1 ); verify( $obj, :never ).foo( 2 );
And: verify( $proto ).new.was_called: :once; 01:54
allison chromatic: thanks for the debugging work! 01:57
chromatic: I'll look into it further tomorrow
chromatic: did you commit that one last fix to null out the current_object before filling returns? 01:59
chromatic Pushing everything now. 02:02
02:04 adu joined
allison chromatic: cool, it gets a lot farther in PGE, thanks! 02:10
dalek rrot: r44784 | chromatic++ | branches/pcc_hackathon_6Mar10/lib/Parrot/Pmc2c/PCCMETHOD.pm:
[lib] Made PCCMETHODs clear their invocant before returning, so as to avoid
 02:12
rrot: r44785 | chromatic++ | branches/pcc_hackathon_6Mar10/tools/dev/pbc_to_exe.pir:
[tools] Fixed up pbc_to_exe to meet return positional strictness checks.
rrot: r44786 | cotto++ | branches/ops_pct/compilers/opsc (2 files):
[opsc] fix ops2c.nqp, fix an incorrect comment
 02:28
02:39 JimmyZ joined
Coke lhf? 02:40
purl i guess lhf is Low Hanging Fruit
Coke purl+-
03:00 AndyA joined
cotto seen bacek 03:03
purl bacek was last seen on #parrot 7 hours, 1 minutes and 8 seconds ago, saying: Coke, it was actually in klingon
cotto clock?
purl cotto: LAX: Mon 7:03pm PST / CHI: Mon 9:03pm CST / NYC: Mon 10:03pm EST / LON: Tue 3:03am GMT / BER: Tue 4:03am CET / IND: Tue 8:33am IST / TOK: Tue 12:03pm JST / SYD: Tue 2:03pm EST /
bacek_at_work cotto, pong 03:05
cotto do you know what's broken atm in opsc? 03:07
I was just about to start looking, but I figured you might have an idea.
bacek_at_work something. I updated it this morning. Still fails epically on PGE compilation.
cotto but hello world works, which is nice
bacek_at_work I suspect some of "goto" rewrites
cotto I'll look over those very carefully. 03:08
bacek_at_work check "PC + n" gotos.
It fails with assertion when pc == 1
cotto will do that 03:09
It'd help if I tried to debug ops2c.nqp with a non-bootstrapped parrot 03:14
dalek rrot: r44787 | cotto++ | branches/ops_pct/MANIFEST:
[opsc] manifest update
 03:17
03:35 janus joined
dalek kudo: b093791 | (Solomon Foster)++ | t/spectest.data:
Turn on S04-statements/for.t.
 03:36
kudo: 0162536 | (Solomon Foster)++ | t/spectest.data:
Add test file S03-operators/comparison-simple.t.
04:01 tony joined 04:06 ewilhelm joined
ewilhelm hey all, who's up for summer of code? 04:07
Coke ewilhelm: see dukeleto. 04:08
dukeleto i have ewilhem hostage and we are working on gsoc stuff 04:09
who wants to be a mentor?
cotto dukeleto, is PaFo registered?
04:10 tuxdna joined, zostay joined
dukeleto cotto: i am working on the app now. we need a gsoc projects page. i am working on that now 04:16
i have whiteknight's blog posts as a starting point, if anybody else has ideas, let me konw 04:18
know, even
ewilhelm cotto: we're proposing TPF as an org. Is there anybody who wants to head-up PaFo as its own entity for GSoC? 04:32
cotto sounds like a good #ps question. What's involved? 04:34
ewilhelm cotto: socghop.appspot.com/document/show/g...#org_apply 04:40
it would need somebody to be administrator for the org, so they would need to go through that process, round up some mentors, students, then herd cats throughout the summer 04:42
or parrot projects can feel free to ride with perlfoundation 04:43
dukeleto parrot is riding with TPF this year. But that is something to think about for next year 04:44
ewilhelm yeah it's probably too late for an org to try to get that together this year. Put it on the calendar for Jan 02 2011
dukeleto i implore everyone in here to please add something to www.perlfoundation.org/perl5/index....0_projects if you have ideas for GSoC projects this year 04:45
there is also trac.parrot.org/parrot/wiki/GSOC2010, but that links back to that page
the parrot wiki page could still use some love in terms of making it friendly to new devs
dalek tracwiki: v1 | dukeleto++ | GSOC2010 04:47
tracwiki: trac.parrot.org/parrot/wiki/GSOC201...ction=diff
dukeleto if you would like to be a GSoC mentor, please add yourself to www.perlfoundation.org/perl5/index....oc_mentors 04:49
also, if you were one last year and DO NOT want to be one this year, you should take yourself off that page. It is opt-out this year :) ::laughs deleriously:: 04:50
Coke might be about to break the build on windows. 04:59
chromatic Good, that means we only support Linux now, like God and Queen intended.
ewilhelm see also #soc-help 05:02
Coke chromatic: ... I'm pretty sure Freddy was a Mac guy. 05:06
davidfetter o/` god save the queen o/`
Austin I think you're bigoting on the wrong axis. If we could just focus support on x86, we'd make a lot faster progress..
davidfetter o/` we mean it, man o/`
dalek kapo: 0bca702 | austin++ | (33 files):
Got cuckoo() mocking system working. (Now it just needs documentation...)
 05:08
kapo: 7adbb4d | austin++ | :
review: gitorious.org/kakapo/kakapo/commit/...59aeb065c8
chromatic I can't imagine Apple wooing someone as creative and talented as Freddy Mercury. Overvalued and self-indulgent like John Lennon sure, but not Freddy Mac. 05:11
cotto It makes me sad how much faster than ops2c.nqp ops2c.pl is.
chromatic Profile?
purl somebody said Profile was protected by a password
cotto I'm running a profile at work. It'll be ready sometime tomorrow. 05:12
05:13 mikehh joined
cotto (8*60*60) 05:13
purl 28800
Austin message Whiteknight Kakapo release 8 is on master. See code.google.com/p/kakapo-parrot/wik...naeLibrary 05:17
purl Message for whiteknight stored.
05:42 adu joined
Coke finds that the obscure ops lib is not being built as a switch. 05:46
ugh. close to eliminating recursive make on dynoplibs, but not tonight. 06:09
dalek rrot: r44788 | cotto++ | trunk/lib/Parrot/Op.pm:
[ops2c] remove some unneeded regexes
 06:32
Coke if I compile src/dynoplibs/*.o using the default C rule, it fails. if I add -I. to the command line args, it compiles. wtf. 06:36
pushed the work into a branch, if anyone wants to poke at it. 06:42
dukeleto msg whiteknight can you add short descriptions of your gsoc ideas to www.perlfoundation.org/perl5/index....0_projects and link them to your blog posts? thanks! 06:44
purl Message for whiteknight stored.
06:46 bacek joined
cotto hio bacek 06:49
dalek rrot: r44789 | cotto++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
[opsc] remove some unneeded substitutions
rrot: r44790 | coke++ | branches/rm_dynoplibs_make:
Eliminate the recursive make used for src/dynoplibs
rrot: r44791 | coke++ | branches/rm_dynoplibs_make (8 files):
Close but not quite;

and add -I., it works. ??
rrot: r44792 | cotto++ | trunk/src/ops/var.ops:
[ops] Fix pod for find_sub_not_null. I don't know why this was working before.
bacek aloha cotto
cotto any objections to a sync on the branch?
bacek nope
cotto btw, cutting out those extra subst() calls dropped the time to run ops2c.nqp from ~8m to ~6m. 06:50
bacek We do need caching of regexes...
cotto If nqp doesn't do /o by default, it just became a really important feature. 06:53
With that latest commit, opsc generates the same number of ops as ops2c. 06:54
I also didn't see anything broken about the output of any of the goto FOO() code. 06:55
bacek Hmm... nqp doesn't require /o. It's already compiled down to pir code. 06:56
cotto, are you doing merge now or I'm free to dcommit my changes? 06:57
cotto Rats. I thought that might be the case.
go ahead
is it just those 2 commits? 06:59
bacek 3 I think
44795 is last one 07:00
cotto In that case I'll sync now. 07:01
bacek ok 07:02
I'm trying to build selfhosted ops again... 07:03
cotto I tried with reordered ops and didn't get any better results.
bacek Sigh... 07:04
dalek rrot: r44793 | bacek++ | branches/ops_pct/compilers/opsc/ops2c.nqp:
Use ops in same order as ops2pm.
 07:05
rrot: r44794 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Actions.pm:
Auto-vivify OPLIB in Actions.
cotto I really want to avoid comparing the code for the generated ops, but that may become necessary.
rrot: r44795 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Trans/C.pm:
Generate code closer to ops2c.
07:05 uniejo joined
cotto sync committed 07:06
bacek Hmm... Just parsing all ops takes 15 seconds... 07:11
07:20 ewilhelm left
dalek rrot: r44796 | cotto++ | branches/ops_pct (17 files):
[opsc] sync branch with trunk
 07:22
cotto Now opsc generates a bunch of extra ops. 07:24
bacek Remove second set.ops in ops2c.nqp 07:27
It was badly merged...
cotto committed 07:28
thanks
How does that even happen? I can accept myself making a stupid mistake, but it's pretty weak for a vcs to do that. 07:32
bacek It's on my side. I forgot to push some changes and then missed bad merge by git-svn
cotto ok 07:33
Do you know if there's a nice way to add #line directives to the generated code? 07:35
bacek $/ should have enough info to store in Ops::Op 07:37
dalek rrot: r44797 | cotto++ | branches/ops_pct/compilers/opsc/ops2c.nqp:
[opsc] fix merge goof
 07:38
07:49 fperrad joined
bacek cotto, I can't spot any obvious bugs in generated code... It's almost same as before. Slightly better in code-style. But semantically same 07:50
cotto There's clearly a bug somewhere. 07:51
but it is a little mystifying.
bacek indeed. 07:52
Ok. I'm going to redo this bloody double substitution nonsense. We are loosing time waiting ops2c.nqp to finish. 07:58
cotto go for it 08:00
a mandatory 6-minute break tends to break my focus too 08:01
chromatic How do you run ops2c.nqp on ops? 08:11
bacek ./parrot-nqp compilers/opsc/ops2c.nqp 08:14
It will generate include/ and src/ files 08:15
chromatic Is this supposed to work? 08:16
$ make compilers/opsc/opsc.pbc
cotto make opsc
bacek make opsc
chromatic ./parrot-nqp --target=pir --output=compilers/opsc/gen/Ops/Trans/C.pir compilers/opsc/src/Ops/Trans/C.pm 08:17
Unable to open filehandle from path 'compilers/opsc/gen/Ops/Trans/C.pir'
bacek oops
looks like we need more IGNOREME files 08:18
cotto mkdir compilers/opsc/gen/Ops/Trans #until it gets fixed in svn
bacek cotto, can you commit IGNOREME in this directory?
chromatic I can if you need it. 08:19
cotto I can do it
I can do it nine times.
chromatic Okay, you do that.
08:19 lucian joined
cotto done 08:21
dalek rrot: r44798 | cotto++ | branches/ops_pct/compilers/opsc/gen/Ops/Trans/IGNOREME:
[opsc] add IGNOREME file
 08:27
chromatic I find nothing obvious profiling at the C level. 08:36
We can probably get a ~3% improvement on most call-heavy programs by allocating more than one cell at a time in CallContext, but that's not a big problem here.
cotto bacek, it'd also be nice if opsc generated ops in the order of ops.num 08:51
bacek ops.num is also generated...
purl okay, bacek.
cotto ops.num?
purl ops.num is mapping between op name and pbc/switch statement in generated code. or generated...
cotto oh.
it's a tough nut to crack, but it'll be cracked 08:52
09:12 iblechbot joined 09:43 uniejo joined 09:45 AndyA joined
dalek rrot: r44799 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Trans/C.pm:
Generate code close to ops2c.pl
 10:05
rrot: r44800 | bacek++ | branches/ops_pct/compilers/opsc/ops2c.nqp:
Put experimental.ops as last one to keep order of ops same as ops2c.pl
10:08 bacek joined 10:13 tony joined 10:14 tony joined 10:18 TonyC joined 10:28 lbr left
dalek kudo: de996e9 | moritz++ | src/core/Any-str.pm:
fix RT #73120: Str.subst should allow both :g and :global
 10:28
mikehh ha - that was fun - pcc_hackathon_6Mar10 branch still goes into infinite loop on t/compilers/imcc/syn/regressions.t 10:32
I was working on something else and suddenly had no memory etc left 10:33
moritz mikehh: I strongly recommend ulimit -v before running parrot tests 10:34
mikehh: at least that's what I do before running experimental rakudo tests
mikehh moritz - normally have no problem there - just trying to work on 2 branches at once and forgot to stop the test :-} 10:35
dalek kudo: 16efb68 | moritz++ | src/core/Any-str.pm:
implement Str.subst($matcher, Code, :g)
 10:57
10:57 mj41_ joined 11:01 cosimo joined 11:03 payload joined 11:05 baest joined
dalek kapo: adec347 | austin++ | src/Internals/Full.nqp:
Fixed Kakapo::Full to mark all pre-initload modules as completed for DepQ processing.
 11:09
rrot: r44801 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (2 files):
Generate code closer to ops2c.pl
 11:42
rrot: r44802 | bacek++ | failed to fetch changeset:
Regenerate ops without #line directives to simplify comparision with opsc
rrot: r44803 | bacek++ | failed to fetch changeset:
Remove get_label and set_label from ops.num. They are in
 11:45
bacek cotto, IT WORKS!!!!!!!!! 11:46
msg cotto IT WORKS!!! 11:47
purl Message for cotto stored.
bacek msg cotto You was right about ops code vs ops.num. After fixing ops.num in r44803 everything start magically works. 11:50
purl Message for cotto stored.
11:59 kid51 joined 12:05 payload joined 12:22 ruoso joined
dalek rrot: r44804 | bacek++ | branches/ops_pct/compilers/opsc/TODO:
Update TODO
 12:30
rrot: r44805 | bacek++ | branches/ops_pct/compilers/opsc/t/07-emitter.t:
Update test
mikehh bacek: got a bunch of manifest/codetest fixes ready 12:32
bacek mikehh, ship it! :) 12:33
mikehh bacek: what do we do about src/ops/core_ops.c and include/parrot/oplib/core_ops.h which are generated but are in the MANIFEST/source tree 12:40
bacek can we put them in MANIFEST.skip?
mikehh bacek: not sure what to do about them 12:41
bacek They are generated. Very similar to bison/flex files.
mikehh what do we do about other generated files? 12:42
bacek So, codetest should ignore them
mikehh definately at the moment - lots of errors from them - make realclean removes them but svn status -u says they are missing 12:43
bacek it's work-in-progress
At the end - make realclean will not remove them. 12:44
mikehh yeah - I'll give it a good thunk or something :-}
anywat will come back to that 12:45
bacek ok
dalek rrot: r44806 | bacek++ | branches/ops_pct/compilers/opsc/t/07-emitter.t:
More test updates
 12:46
rrot: r44807 | mikehh++ | branches/ops_pct/MANIFEST:
re-generate MANIFEST
rrot: r44808 | mikehh++ | branches/ops_pct (4 files):
add svn properties
 13:03
13:04 whiteknight joined 13:06 kurahaupo joined
dalek kudo: 3fba2c3 | moritz++ | (2 files):
implement :x in Str.subst; implement :all in Str.split(Str)
 13:16
rrot: r44809 | jkeenan++ | trunk/src/ops/var.ops:
[codingstd] No trailing whitespace.
 13:19
13:26 whiteknight joined
moritz Coke++ # going through the perl6 RT queue 13:27
dalek rrot: r44810 | mikehh++ | branches/ops_pct/src/ops/var.ops:
remove trailing whitespace and update copyright
 13:35
rrot: r44811 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Actions.pm:
remove trailing whitespace and update copyright
rrot: r44812 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Grammar.pm:
remove trailing whitespace and update copyright
13:39 bubaflub joined 13:43 smash joined
smash hello everyone 13:43
Coke If you are adding more generated files to the build, please make them re-generatable via the same mechanism as --maintainer. 13:44
moritz: I thought I was subscribed to the mailing list, but I'm not seeing any emails from those tickets I modified.
moritz Coke: I see them :-) 13:45
dalek kudo: 85ef035 | (Solomon Foster)++ | t/spectest.data:
Turn on S05-match/blocks.t.
Coke ... ah, they're here this morning.
mikehh anyway whole lot more to come, but gotta go out for a while - bbl with more 13:46
Coke moritz: what is the mechanism for saying "this works now but needs tests?"
(in rakudo RT)
moritz Coke: yes; say that in the ticket, assign it to me
there's also a "needs test" tag or so, but I'm not sure if you can already search for it
Coke you can search for anything! =-) 13:50
I didn't see the tag, though.
13:50 atrodo joined
moritz finds RT's search to suck a lot 13:50
but maybe I just don't understand it 13:51
dalek rrot: r44813 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Emitter.pm:
remove trailing whitespace and add copyright and Id
Coke moritz: what's your id? 13:52
rrot: r44814 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler.pm:
add copyright and Id
rrot: r44815 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Trans.pm:
remove trailing whitespace and add copyright and Id
moritz Coke: moritz 13:53
Coke moritz: odd. you're not on the list of potential owners. 13:54
odd. you are.
(wtf.)
I don't see any field, custom or otherwise, that refers to tests, other than:
tag: testcommitted
moritz ah 13:55
but no testneeded
Coke Seems like that should actually be a status, not a tag. 13:57
no matter, assignment to you is fine for now. =-)
13:58 slavorgn joined
Coke now, if someone would just magically fix my branch... 14:00
whiteknight Coke: which branch?
Coke svn.parrot.org/parrot/branches/rm_...plibs_make 14:01
it is very close to killing another recursive make target.
I'm either missing a dependency or a compilation flag.
.. or something else. =-) 14:02
14:04 payload joined
dalek kudo: 2302b7c | moritz++ | t/spectest.data:
enable type.t
 14:17
14:25 bluescreen joined 14:26 patspam joined 14:30 patspam joined 14:35 whiteknight_ joined 14:36 payload joined 14:45 Essobi left
whiteknight dukeleto: ping 14:51
dalek kudo: 24faa67 | moritz++ | t/spectest.data:
enable what.t
 14:52
whiteknight purl msg dukeleto: I have a few GSoC project ideas for tangential projects like parrot-linear-algebra. Would those be cool to add to the list of projects? 14:53
purl Message for dukeleto stored.
darbelo whiteknight: More is better. 14:58
whiteknight darbelo: yeah, I know. I just want to make sure things on the fringe of the ecosystem are allowed
oooh, I just had a great idea: threading system enhancements 14:59
or, a new threading system
darbelo Good point. My project eneded up on the fringe of the ecosystem, but it started out as a core thing.
That reminds me. I hate our bignums and want them to die... 15:00
atrodo out of curiosity, what's the problems with the current threads?
darbelo atrodo: All of it?
purl All of it is supposed to be somewhat redundant, and you might be calling that boring, but that's for a reason.
darbelo Less glib answer: They were designed and implemented a long time ago, when parrot was pretty different from what it is today. 15:02
And nobody cares enough bout them to update them.
whiteknight they are extremely buggy and very inefficient 15:03
darbelo: I agree with the bignums thing 100%. I want bignums out of the repo and moved to their own project 15:04
There's no sense keeping them when I suspect a majority of users can't use them because they don't have GMP installed 15:06
darbelo Actually, I wouldn't mind them being in the core if they weren't dependant on a lib I don't have. 15:07
I actually had started to write a stand-alone BigInteger PMC after last year's SoC. 15:08
whiteknight that would make an awesome project too. 15:09
15:09 Andy joined
whiteknight I think we should have lots of projects like that, and for developers to be able to pick which solution they want 15:09
moritz are there no good, portable and liberally licensed bigint libraries available? 15:10
whiteknight as we are now, it's easier to force BigInt to pretend to do what we need instead of just using the best solution, which might be DecNumber or something else
moritz: GMP
moritz then... the right path for rakudo would be to require GMP, no? 15:11
rakudo needs bigints; actually it needs them quite badly
darbelo Maybe, but GMP is much, much more than just bignums. It's a pretty big library. 15:12
whiteknight libdecnumber is decent too
darbelo Our PMCs don't even start to scratch the surface of what GMP can do.
15:12 payload joined
whiteknight darbelo: so moving those PMCs out to a separate library and adding wrappers for other functionality might be nice 15:13
15:13 Psyche^ joined
darbelo I would consider a GMP binding much more valuble to parrot than our current use of the lib, yes. 15:14
Also, libdecnumber is pretty good in some aspects, but sucks in others. 15:15
variably sized numbers are a complete pain in the ass. And it doesn't really do bigints at all. 15:16
15:18 davidfetter joined
whiteknight allison: ping 15:18
darbelo: we should suggest that today at #ps
bubaflub last year i worked a bit with GMP library and suggested to dukeleto we work on a GMP binding for parrot 15:19
last year with GSOC and perl 5
darbelo bubaflub: That would be nice to have. 15:20
bubaflub though we used an existing perl 5 binding (Math::GMPz)
whiteknight yes, that would be a wonderful project
bubaflub but we could nab the test suite and what not
i'm not totally sure how to do the bindings in parrot - are their SWIG bindings for parrot? 15:21
or would it rather be done with NCI?
whiteknight exactly. We have the two PMC types, and we could write wrappers for the rest of the library and get all sorts of additional power
bubaflub: I don't know about swig. Ifthere are, I haven't heard about them in a long time
bubaflub whiteknight: ok. 15:22
whiteknight NCI would work. Adding PMCs or ops is a good idea too
so we have the existing BigInt and BigNum PMCs, we could add methods to them
bubaflub i think access to the GMP library in general would be nice; the stuff i worked on last year was setting some foundational stuff for cryptography libraries
whiteknight bubaflub: you may be interested in the parrot-linear-algebra project. We're trying to put together bindings to the cblas/atlas libraries 15:23
linear algebra is very important for cryptography
bubaflub agreed. 15:24
man, so many proposal options for GSOC
whiteknight bubaflub: more to come!
bubaflub haha. 15:25
i'm leaning more towards math / linear-algebra type stuff as that was my undergrad
but i'm also open to hacking on some HLLs
darbelo Right now I'm researching possibilities for the RTEMS port as a GSoC project. 15:27
PARROTS IN SPACE!!! 15:28
bubaflub hah.
darbelo The tricky part is finding the right balance between too much and too little. 15:30
bubaflub it's also difficult to judge how long things will take 15:31
who knows, a few hours into something a light bulb could turn on and you could get a major breakthrough
or you could be banging your head against your desk for months 15:32
darbelo If I'm right about what the port will take, Coke just did a lot of the work for me in rm_cflags ;) 15:36
Coke c question - is '.' ever implicitly in the include path? 15:37
NotFound Possible idea: resurrect parrot ecmascript, or write a new one from scratech.
dalek kudo: ad6b5d8 | moritz++ | t/spectest.data:
turn on more smartmatch tests
 15:38
Coke tries to remind himself that we don't expect GSOC projects to work on core aspects of parrot.
NotFound Coke: search paths are implementation dependant. 15:39
Coke ok. so if I want ., I should be explicit.
NotFound Do you mean #include "./something", or using -I . or equivalent command line option? 15:41
darbelo I think he means -I .
Coke ops2c.pl is generating "#include "src/foo/bar.c"" on dynamic files. 15:42
$(CC) is getting invoked with -Isrc/foo, but not -I., so the build fails.
so I either need to change the ops2c --dynamic generator, or the makefile rule.
(easier to change the generator, methinks) 15:43
darbelo Coke: you could ping cotto or bacek on that one. They're rewriting ops2c right now.
NotFound I think changing the generator is preferable, too much additions to -I may lead to confusions. 15:44
whiteknight dukeleto: ping
cotto good morning 15:45
whiteknight purl msg dukeleto I listed security sandboxing as a possible GSoC project. If that's a good idea, I think we could use some documentation about what is needed.
purl Message for dukeleto stored.
cotto bacek++ 15:46
Coke, it's probably easier to change the generator. 15:47
though neither sounds very hard 15:48
Coke that seems to have done it -the dynops build failed when pulled into the top level build because regular ops have their inc file in the public area. dynops leave them in src/*, so it's not quite the same pathing issues.
and by "done it" I mean it now fails differently. :| 15:49
cotto also, mikehh++ for the cleanups
nice to have you keeping an eye out for those 15:50
Coke (ok. the .o's build in src/dynoplibs - now the link to generate the output file in dynext is failing.)
src/extra_nci_thunks.c seems to be leftover on a realclean. 15:51
cotto istr that it's generated but checked in for bootstrapping porpoises 15:52
Coke then it shouldn't be svn:ignored. 15:53
that's only generated-but-not-checked-in stuff.
bubaflub Coke: i'm also seeing some other files left over from `make realclean` - src/events.o, src/events.str src/tsq.o, runtime/parrot/include/io_thr_msg.pasm, and CFLAGS
Coke bubaflub: you are working from an old checkout. 15:54
cotto istr incorrectly
bubaflub Coke: ok.
Coke you probably have them leftover; realclean, remove them, rebuild, realclean, and check again.
bubaflub will do 15:55
15:55 payload joined
Coke (we don't remove files that are no longer generated; if you have them still generated and regen your makefilie before a realclean, you're sol) 15:55
$ svn ls src/*extra*.c
svn: 'src/extra_nci_thunks.c' is not under version control
whiteknight Coke: how do we specify a compiler does not have negative zero? 16:02
dalek rrot: r44816 | coke++ | branches/rm_dynoplibs_make/lib/Parrot/Ops2c/Utils.pm:
Now build src/dynoplibs/*.o
 16:04
bubaflub whiteknight: are you working on getting parrot to build with ICC by any chance? 16:07
whiteknight bubaflub: yes, I'm doing that right now
parrot does build with ICC, but fails some tests 16:08
bubaflub whiteknight: yeah, i was looking into that for dukeleto about a week back; i put my findings in a ticket
i'm looking for the ticket number now
trac.parrot.org/parrot/ticket/1488 16:09
not sure if that'll help ya
whiteknight yes, definitely helps
bubaflub i think there is a discrepancy between the parrot sprintf and c printf 16:10
particle we tried really hard to get rid of those years ago, but sprintf is tough 16:11
platform-independent sprintf with extended functionality, that is
bubaflub whiteknight: right around line 199 or 200 of src/spf_render.c i think 16:15
whiteknight bubaflub: the ICC compiler isn't even storing -0.0 in the structure 16:16
Coke whiteknight: you can override the neg_0 value in the your hints file for that platform.
bubaflub whiteknight: doh.
Coke something like $conf->data->set->{'has_negative_zero'} = 0 if $compiler eq 'icc' in the linux hints file. 16:17
(looks like there's already an icc section in config/init/hints/linux.pm) 16:18
whiteknight Coke: I think I may have a fix 16:22
GOT IT 16:24
bubaflub: reconfigure with the --ccflags="-fp-model source" 16:25
bubaflub nice. lemme try.
whiteknight it looks like ICC optimizes floating-point too aggressively byt default, and loses ANSI compliance in the process 16:26
Coke: where are the hints files?
Coke config/init/hints/linux.pm
whiteknight Coke++ 16:27
Coke see: _handle_icc_ccflags
whiteknight (sorry about all the n00b questions)
Coke oh, hey, look at that, icc puts all sorts of warnings here in the wrong place. 16:28
Coke will have to fix that if someone ever installs icc on feather. =-)
bubaflub whiteknight: i'm building now with perl Configure.pl --cc=icc --ld=icc --link=icc --ccflags="-fp-model source"
whiteknight Coke: do you happen to know off-hand what distro feather uses? 16:29
moritz debian 16:31
unstable/experimental unhealthy mixture
16:35 iblechbot joined
whiteknight bubaflub: that fixes some errors, but still have a stringification problem 16:37
so $N0 = -0.0 works now, but $P0 = -0.0, say $P0 doesn't
bubaflub whiteknight: i'm running `make coretest` now
Coke ->
16:39 davidfetter joined
bubaflub whiteknight: weird, coretest passes for me 16:40
whiteknight I'm trying again 16:41
if so, this could be the shortest branch ever 16:43
the ICC build still outputs a crapton of warnings 16:44
darbelo icc is picky.
whiteknight most of the errors it finds are problems with trailing commas in headers 16:45
so we could fix those easily
bubaflub whiteknight: is there any test / test suite you'd like me to run? 16:46
16:47 theory joined
whiteknight we have a lot of instances in the code of PARROT_ASSERT(!"string"), which ICC hates 16:50
a PARROT_FAIL("") macro might be better for the purpose
dalek rrot: r44817 | whiteknight++ | branches/fix_icc_failures (2 files):
update hints to compile with '-fp-model source' on icc. This fixes handling of negative zero, but doesn't fix stringification of negative zero issues
 16:52
rrot: r44818 | whiteknight++ | branches/fix_icc_failures/include/parrot (3 files):
remove some non-standard trailing commas at the end of enums, which isn't a problem most of the time but ICC hates it
cotto_work Yay! The opsc-generated src/core_ops.c has no new test failures! 16:53
whiteknight cotto++ 16:57
Coke: is that hints file in the same place after all your refactors?
cotto_work t/compilers/pct/complete_workflow.t fails, but it also fails with the checked-in core_ops.c
bacek++ did 90% of the work
whiteknight bubaflub: yes, I'm seeing all tests pass now too, after the realclean 16:59
I think this branch is mergable.
bubaflub whiteknight++ 17:00
whiteknight bubaflub: if we could fix some build warnings today, that would be awesome
bubaflub sure sure. should i make realclean and build again?
whiteknight just make clean 17:01
bubaflub whoops.
i'm about to head out to lunch with coworkers, i'll start a build and take a look at some errors.
whiteknight okay, I'm off to lunch too. Let's fix whatever we can today and merge it tonight or tomorrow 17:02
bubaflub whiteknight: i'll throw the build errors i find onto the ticket 17:06
nopaste "whiteknight" at 173.12.37.77 pasted "ICC warnings for bubaflub++" (800 lines) at nopaste.snit.ch/19895
whiteknight bubaflub: There's a listing of all build warnings for you. 17:07
bubaflub huzzah.
hooboy
whiteknight: what platform are you building on?
17:08 ruoso joined
whiteknight bubaflub: Ubuntu x86 17:10
bubaflub whiteknight: ok, i'm on Mac OS X 10.6 (and change)
nopaste "bubaflub" at 173.209.128.134 pasted "ICC warnings on Mac OS X" (178 lines) at nopaste.snit.ch/19896 17:12
bubaflub whiteknight: those are the errors i get when i make with icc
17:16 chromatic joined 17:23 payload joined 17:32 ruoso joined 17:37 kjeldahl_ joined
dalek kudo: 62d70b7 | moritz++ | t/spectest.data:
enable two more test files
 17:50
18:09 lichtkind joined
lichtkind dukeleto: i have some questions and want to talk about GSOC 18:10
whiteknight lichtkind: what kinds of questions? 18:14
lichtkind whiteknight: what were the most important changes between parrot 1 and 2
whiteknight ah, good question 18:15
There were relatively few major feature additions between them. Mostly it was a period of intense cleanup, coding standards, refactoring, code improvement, etc
lichtkind whiteknight: that i know, wasnt too lazy to read logs but i cant say if there were any "important features" between them 18:17
whiteknight: beside that i currently write www.perlfoundation.org/perl6/index.cgi?timeline 18:18
please tell me if theres something missing
whiteknight okay, let me look at your list
lichtkind whiteknight: that are 2 completely different questions :) 18:19
whiteknight lichtkind: I only saw one question 18:20
PerlJam lichtkind: somewhere in 2003/2004 Dan gave up working on perl6 and TPF started a search for a Perl 6 Pumpking that culminated in selecting pmichaud. 18:24
dukeleto lichtkind: hello
lichtkind dukeleto: hai 18:25
dukeleto lichtkind: hola
lichtkind PerlJam: do you know when this was? 18:26
dukeleto whiteknight: I think GSoC projects need to be parrot-core-only, sadly. That isn't set in stone, it might be something to bring up on parrot-directors and/or parrot-dev 18:27
18:27 lucian joined
lichtkind whiteknight: im really interested which parrot features or changes were most important between 1 and 2 which isnt subject of the timeline 18:27
PerlJam lichtkind: I'm looking it up, but I think it was in the spring of 2004 just after A12 release
dukeleto whiteknight: and i think the idea of a gsoc project on PDD18 (security sandboxing) would be awesome 18:28
lichtkind PerlJam: thanks a lot a date for dans leaving were great too
dukeleto: i wanted you just tell thats great that you du gsow and that i could help as drop in mentor for november 18:29
dalek rrot: r44819 | whiteknight++ | branches/fix_icc_failures (6 files):
Added PARROT_ASSERT_MSG macro, which does an assertion with a custom error message. Added PARROT_FAILURE which does an unconditonal assertion failure with a custom error message. PARROT_ASSERT was used (abused) to provide these two functions, but ICC gets very unhappy about it. No changes to functionality, but a lot fewer warnings on ICC"
 18:30
davidfetter when's #ps? 18:31
dukeleto lichtkind: awesome! did you add yourself to the gsoc mentors wiki page? www.perlfoundation.org/perl5/index....oc_mentors
lichtkind dukeleto: im currently opened this page
cotto_work dukeleto, in 117 minutes 18:32
davidfetter notes in future to ask either the time-to-ps or specify a time zone 18:33
PerlJam lichtkind: Hmm. All I've found so far is an Aug 6 email congratulating pmichaud on being accepted as the perl 6 compiler pumpking 18:34
lichtkind: Aug 6 2004 that is
dukeleto cotto_work: thanks for asking my question before I asked :) 18:37
cotto_work I'd like to blame autocomplete, but that was more of a pebcak 18:39
lichtkind PerlJam: thank you, and any notice when dan resign, the current date is related to his farewell post 18:42
dukeleto when did parrot switch to a monthly release cycle? that would be good to put in the timeline 18:43
lichtkind dukeleto: written
cotto_work You can see that pretty easily by looking at docs/parrothist.pod 18:44
looks like Jan 2007 18:45
dukeleto cotto_work: thanks, i added that to the timeline 18:54
lichtkind pmichaud: ** August 6 - [Patrick Michaud] got accepted as the perl 6 compiler pumpking, after [TPF] was looking for a new one for some time 18:56
PerlJam lichtkind: that's when the email was. He may have gotten accepted sooner than that :) 18:59
lichtkind PerlJam: its a wiki we can change it anytime
dukeleto: when exactly was the release cycle change? 19:00
chromatic November or December 2006, I think. 19:03
19:03 aukjan1 joined, japhb joined
dukeleto lichtkind: i wrote Jan 2007 on the wiki 19:05
whiteknight Austin: ping
Austin ?
whiteknight Austin: the mock stuff looks great 19:06
if it does everything the docs claim, it's fantastic
Austin Currently, I think it does - the test cases all run.
lichtkind dukeleto: allright, could you tellme whats parrots biggest feature or improvement between 1.0 and 2.0? 19:07
Austin I haven't had time to use it under load, yet, since I'm on a different project today. But I should have some real-world experience in the next few days.
whiteknight I would like to start getting some of my projects using it more. I think I want to update Parrot-Linear-Algebra to use Kakapo for the whole test suite
chromatic lichtkind, your question makes me think that you believe we increment the major version number to coincide with a large feature release.
PerlJam lichtkind: pmichaud "applied" for the perl 6 compiler position in Jul 2004 19:08
lichtkind: so, I guess Dan stepped down as the perl 6 compiler guy sometime between Apr 2004 and Jul 2004 19:13
oh! here's an announcement from Dan on Jul 6, 2004: www.perlmonks.org/?node_id=372089 (Dan == Elian) 19:14
19:14 AndyA joined
lichtkind chromatic: as i wrote, i ask because i dont have the feeling log reading makes me really knowing whats going on 19:14
chromatic There's no single big feature, but thousands of commits. 19:16
19:17 AndyA_ joined
chromatic The best anyone could do is look over the release announcements and pick out a handful of big things. 19:17
Profiling runcore, GC tuning, PCC revamps, some MMD changes, NQP-rx I believe. 19:18
cotto_work chromatic, #ps reports would also be good for mining
lichtkind hm 19:20
whiteknight Austin: I get a test failure on kakapo master:
t/Program.nqp ......................... Parent isn't a Class.
current instr.: 'parrot;P6metaclass;add_parent' pc 224 (runtime/parrot/library/P6object.pir:232)
Austin Whiteknight: That's odd. Are you on master:HEAD, or at release 8? 19:21
whiteknight master:HEAD
Austin Okay. Whew.
I'm working on Program in the background, so probably something slipped through. You can safely ignore it for now. I'll try to stabilize it today for you. 19:22
allison Whiteknight: pong (many hours later)
whiteknight allison: what's the status of the pcc branch? I checked out early last night
I also had a question about returns checking and how strict we plan to be 19:23
19:25 kthakore joined
kthakore dukeleto: around? 19:25
allison whiteknight: I've been working my way through errors in PGE
whiteknight: chromatic put in a good bit of work there yesterday too 19:26
whiteknight allison: I'm wondering about the case where we call a function but ignore all return values. Will that be acceptable?
lichtkind allison: hello
allison whiteknight: I can't say how many errors are left in PGE, but the tasklist for this refactor is almost completed
whiteknight ok 19:27
allison whiteknight: currently, returns are exactly as strict as parameters
whiteknight okay, so there's no way to completely ignore return values?
allison whiteknight: they can be marked as optional, but not completely ignored
whiteknight okay, is that feature on the wish-list?
allison whiteknight: not at the moment, now
whiteknight: we had some discussion last night on whether that's a bug or a features 19:28
feature
lichtkind: hi
purl hey, allison.
dukeleto kthakore: ahoy
allison whiteknight: it could go either way, really, it's a question for HLL devs 19:29
lichtkind allison: really long time we talked :)
allison whiteknight: that is, do we want to silently ignore mismatches in return signatures?
whiteknight: or, do we require explicitly marking when a return is dropped? 19:30
whiteknight allison: true, but to draw an analogy, how many people ever use the return value of printf in C?
allison whiteknight: almost never
purl i guess almost never is not good enough.
allison whiteknight (it could be argued that it's a poorly designed function, but that's a side question) 19:31
whiteknight ...so, not a great analogy
allison the thing is, there are substantial advantages to fully treating return invocations as sub calls
one code path means one maintenance path, means escaping subtle bugs between implementations of the same code 19:32
darbelo (returns = calls)++
whiteknight I dont debate that. I'm thinking more along the lines of "if we never call get_results, who's going to know?"
NotFound So we'll need to cal get_results to get void? 19:33
19:33 eternaleye joined
allison in CPS, returns really *are* calls (of a return continuation) 19:33
whiteknight allison: I know that. 19:34
allison whiteknight: aye, I'm just running over tthe advantages for the sake of discussion
whiteknight okay
allison whiteknight: on the other hand, we have the "principle of least surprise" 19:35
particle tewk: you'll want to have the code coda etc on that generated file to mark it as read-only
allison whiteknight: Perl 5 silently ignores mismatches in the return args and params 19:36
I suspect Perl 6 does too
it's possible to implement an HLL that silently ignores missing or extra returns on top of a VM that's strict about them (thought a bit of a hassle) 19:37
whiteknight Austin: Where does kakapo install to? I tried installing it but don't see the files anywhere
allison: Well, we can be strict about them when get_results is called. But, if IMCC uses a heuristic to not call get_results if no results are wanted, we bypass the check 19:38
there's a difference between () = foo(), and just bare foo()
dalek kudo: e42042c | moritz++ | src/pmc/p6opaque.pmc:
awesome error message when you try to access attributes of type objects, as suggested by TimToady++
 19:39
tewk in a CPS world get_results sounds wrong. It should be this is the continuation and signature you call next. 19:40
Austin Depends, but probably /usr/local/lib/parrot 19:41
19:41 shockwave joined
shockwave Howdy. 19:41
allison whiteknight: yes, and it may actually handle that now if get_results isn't called in the second case
shockwave Can an array access be used anywhere a register can be? i.e., $P[0] 19:42
$P1[0] ^^^
Austin shockwave: no
shockwave umh
Austin Array (and hash) accesses can be used to store, and fetch.
$P0 = $P1[1] 19:43
But not generally whereever an op takes a $P register.
shockwave ah
Austin $P2 = newclass $P0[1] # Doesn't work
allison tewk: oddly enough, it actually makes sense to have separate ops for results, because they pull from a different context level than params
tewk: (get_params pulls from the current context, get_results pulls from a child of the current context 19:44
shockwave Austin, so, is the recommended thing is to do something like: $P2 = $P1[0] ... Use $P2 as pointing to $P1[0] ?
Austin $P0[1] = split '::', $P1 # Doesn't work
shockwave: right! Remember that PMCs are pointers, so you're creating an alias.
$P0 = $P1[4] 19:45
inc $P0
will increment $P1[4], whatever "increment" means to that pmc.
allison whiteknight: but, yeah, I could see an argument that () = foo() should do parameter checking, while foo() shouldn't
whiteknight: of course, we also have the global setting for "don't check return parameter mismatches"
Coke ... osx has icc? 19:46
whiteknight all that is a little moot if we never call get_returns
shockwave Austin, So I'm correct in assuming that if I do: $P1[0] = 42; $P2 = $P1[0]; inc $P2; # That, although I stored a literal int, it will be incremented correctly?
Austin Won't work. 19:47
Use 'box'
Coke PerlJam: (dan gave up working on perl6) ... do you mean parrot? I don't recall dan working on p6.
shockwave $P1[0] = box 42
chromatic I remember that, Coke.
PerlJam Coke: Dan was doing double duty on parrot and perl6 in the early days
allison whiteknight: (trying a quick code example)
PerlJam: Parrot *was* perl 6 in the earliest days
Austin $P0 = box 42 ; $P1 = new ['ResizablePMCArray'] ; $P1[0] = $P0 ; inc $P0 ; $P2 = $P1[0] ; say $P2
PerlJam allison: well, that's one way to look at it :) 19:48
shockwave Austin, Thanks alot. You're the man.
allison PerlJam: but he never worked on Perl6 design, if that's the question
PerlJam allison: right.
Coke: what allison said
allison PerlJam: or on any of the early prototype implementations of Perl6 on top of the VM
PerlJam: only on the VM that eventually came to be known as Parrot
PerlJam: so you're *both* right :) 19:49
tewk allison, I've not been following the latest PCC changes, but I would suspect that tailcalls use the same context right?
allison tewk: yes
tewk offtopic, it would be nice for parallelism if parrot had some container types whose size were set on creation 19:52
chromatic I agree.
allison tewk: certainly doable 19:54
Coke $P0 = new 'arryish', 5
whiteknight so add an init_int vtable?
19:54 TiMBuS joined
whiteknight that seems highly reasonable 19:55
I also like that it would prevent us from needing to shoehorn Fixed*Array.set_integer for the purpose of setting the capacity
or, us continuing to do that
tewk whiteknight, that is exactly the problem,
is that feature needed anywhere? 19:56
whiteknight if the dream comes true and we have only one array-like type in the repo, it won't really be needed, no
but other array types and other PMCs would use it 19:57
one fewer vtable call for every single Integer PMC in the system, which adds up
chromatic There's already init_pmc, though that means creating and throwing away a temporary Integer for each arraylike creation. 19:58
19:59 shockwave left
tewk constructors are really a powerfull concept, maybe once pmcs and objects become one ... 19:59
20:00 zostay joined
chromatic CallContext would be cheaper if we could initialize its storage size on creation. 20:00
tewk yep, you could eliminate PMC_data indirections. 20:01
whiteknight we can ask if there are any objections at #ps, but I think it's a great iea 20:02
idea
allison me too 20:04
tewk In some ways we optimized VTABLES and object methods backwards, native method access should be optimized first and interop access later.
chromatic VTABLEs should have used MMD from the start. 20:05
allison tewk: a lot of it fell out of "what's easiest to implement" 20:06
chromatic Number of problems that would have caused: few.
Number of problems that would have prevented: many.
allison chromatic: aye
chromatic: they were pseudo-MMD pretty early on
chromatic Not really.
allison chromatic: but, the system didn't play well at all with any true MMD
chromatic: there was that funny kind-of MMD system we ripped out in the MMD refactor 20:07
chromatic: oh, but it was only for a limited set of math ops, so you're basically right
chromatic Yeah, true MMD doesn't easily fall out of a system where you always first dispatch on the leftmost invocant and then, maybe, redispatch. 20:08
I'll save the rest of my "The Marriage of Heavenly Methods and Hellish VTABLEs" for the William Blake stage of Lorito however. 20:09
dukeleto ponders writing a script to scrape Trac to autogenerate some parts of his weekly #ps report 20:14
whiteknight dukeleto: I would pay for a tool like that 20:16
just being reminded of what commits I made would be awesome
dukeleto whiteknight: I won't forget that ;)
darbelo Not exactly what you are asking for, but home.gna.org/forgeplucker/ 20:17
bubaflub dukeleto: trac.parrot.org/parrot/timeline?fro...ate=Update
Coke dukeleto: I just ... right.
I bet if you were clever, you coudl get that to restrict by actor.
dukeleto whiteknight: yes, being reminded of what $user did in the last week would benefit everyone and make our #ps reports easier to make better
tewk I get "easiest to implement", I was nostalgic to see PCCMETHOD AND PCCINVOKE in the channel discussion recently :) 20:18
japhb fperrad, ping
particle whiteknight: cia.vc/stats/author/whiteknight 20:19
particle used this for years as #parrotsketch prep 20:20
whiteknight particle: holy shit, what is this magical page? 20:21
darbelo You... prepped on whiteknight's commits?
Kinda creepy.
dukeleto bubaflub: that is useful, thanks 20:22
Coke trac is slightlz nicer because also� tickets.
... what happened to mz kezboard_
-win 4 20:23
aigh.
dukeleto Coke: looks like you switched to a german qwertz layout
Coke I cannot tzpe a slash.
qwertz
azup.
particle heh
Coke -me wonders how that happened, as he thought he disabled german input on this kezboard.
moritz Coke: Shift + 7 if it's really German 20:24
Coke is a slash, zes. 20:25
-me is more wondering how to disable this. ��=
er, ;) 20:26
dukeleto bubaflub: wow, that timeline really helps. I did a lot more than I remembered :) 20:27
whiteknight damnit, /me has to run over to the lab now, will miss at least the first part of #ps.
bubaflub dukeleto: yeah, the authors have their own span class, so aggregating the data shouldn't be too bad 20:28
darbelo clock?
purl darbelo: LAX: Tue 12:28pm PST / CHI: Tue 2:28pm CST / NYC: Tue 3:28pm EST / LON: Tue 8:28pm GMT / BER: Tue 9:28pm CET / IND: Wed 1:58am IST / TOK: Wed 5:28am JST / SYD: Wed 7:28am EST /
bubaflub at least in my head with a ruby / nokogiri type script
darbelo #ps in 2.
20:28 bacek joined, ruoso joined
chromatic #ps time 20:31
kthakore ps ? 20:33
purl well, ps is postscript or process status or see "parrotsketch" or non-vector?! or annoying.
kthakore oh ok
darbelo parrotsketch
purl somebody said parrotsketch was a status meeting for parrot core committers held every Tuesday at 20:30 UTC in #parrotsketch
Coke aha. "alt-shift" switches between german & english mode (despite a lack of DE being specified anymore in regions) 20:36
dukeleto bubaflub: feel free to write something like that :)
chromatic Coke, could you take a look at the PGE dependency on the PCC hackathon branch? 20:40
20:41 whiteknight joined 20:42 joeri joined
Coke chromatic: sure, post $DAYJOB. 20:44
chromatic Thanks. 20:45
Coke I'm not sure it makes sense to add a test for it, but I can definitely unbork it.
darbelo japhb: Count me in for any plumage work you need help on. 20:47
japhb darbelo, Ah, cool, there you are. Didn't see you on #ps 20:48
(and thanks!) 20:49
whiteknight in #ps, did anybody mention the new init_int vtable? 20:51
moderator #parrot Parrot 2.1.1 Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Task: Fix HLL bugs! 20:52
chromatic Not yet, whiteknight. 20:52
20:57 shockwave joined
nopaste "shockwave" at 76.119.137.239 pasted "Long question." (27 lines) at nopaste.snit.ch/19897 20:57
Coke chromatic: and monkey's brains, while a popular dish in cantonese cuisine... 20:58
shockwave I have a question, but since is pretty long, I posted it at the above location.
chromatic My monkey is a robot. Just try to get at his positronic brain.
moritz shockwave: parrot basically has no notion of assignment, just binding. pmichaud has been cursing about this for years - I'm sure he can tell you what his workaround his (but he is much distracted by real life these days) 21:00
shockwave: you might also find plenty of discussions in old #parrotsketch and mailing list discussions
trac.parrot.org/parrot/wiki/WhyDoes...icientCode
shockwave moritz, reading the link right now... 21:01
whiteknight I really didn't expect that question to generate so much opposition 21:03
dalek rrot-plumage: 51ac9c0 | japhb++ | src/lib/Plumage/Project.nqp:
[LIB] Plumage::Project: Support nqp_setup method
 21:04
rrot-plumage: 3c71f8b | japhb++ | metadata/kakapo.json:
[METADATA] Update kakapo.json: use nqp_setup, other improvements; fperrad++
Coke plumage? 21:07
purl hmmm... plumage is the future Parrot module ecosystem. It will include tools to search metadata, handle dependencies, install modules, and so forth. The repository is at gitorious.org/parrot-plumage/parrot-plumage and the design docs are at trac.parrot.org/parrot/wiki/ModuleEcosystem
whiteknight the day after Rakudo* is released, I'm starting work on my "dancing hamsters" port to Parrot
And then I'm porting the TI Calculator game "Drug Wars" to Parrot 21:08
chromatic Man, that game takes me back.
whiteknight And then I'm going to port Parrot to my roomba
japhb I want Parrot on my old TI graphing calculator 21:09
whiteknight chromatic: still need help on #389? 21:11
shockwave @moritz, Sorry, it took me a while to read and understand that post. I'm feeling like "oh, oh, I'm going to be in for some hurt".
whiteknight I think I can knock #1505 out tonight, and then I can move to that since I know it's still a big deal for rakudo
chromatic whiteknight, I do. I have one more thing to try, but if you don't see anything from me by this time Thursday, I'm stuck.
whiteknight okay, well let's keep a dialog open about it. I 21:12
'm in that code now and will offer all the tuits I have
shockwave msg pmichaud Hit me up when you get a chance. I'd like to talk to you about assignment vs binding. For reference: trac.parrot.org/parrot/wiki/WhyDoes...icientCode 21:13
purl Message for pmichaud stored.
chromatic I'm going to try once more to create the PMCProxy during class init 2. If that doesn't work, I'll probably do what you suggested and stuff a method hash into the VTABLE.
shockwave Thanks, moritz
whiteknight why doesn't it work at class init 2? That seems like the perfect time 21:14
chromatic I may have done it poorly.
Last time I tried to make it work and pretty at the same time.
Perhaps we need to consider a pretty pass later.
whiteknight if we add a third init stage, I may foam at the mouth until we remove non-essential PMC types from the repo 21:15
chromatic Not init 3, but "Let's go over the code and make it pretty now that it works."
whiteknight yeah, I definitely want to get in there and gussy up some of that shit 21:16
japhb ^ quote
whiteknight class_init with a flag and two branches is worse than two separate class_init functions with no branches 21:17
cotto_work istr that one-stage PMC init would be possible if we hard-coded the PMCs needed to initialize other PMCs.
whiteknight cotto_work: like a fixed ordering? 21:18
cotto_work yes but just for the first few
The rest could be lazy or in whatever order.
I briefly looked into it when thinking about implementing lazy PMC initialization. 21:19
whiteknight I'm not sure that's going to work anymore after chromatic's work
cotto_work ok
whiteknight because every type is going to require an RPA and a PMCProxy
and you can't initialize them at the same time
chromatic I'm not sure a stage one init works with the way we initialize vtables.
bacek, care to look at weird behavior in compact_pool? 21:21
whiteknight chromatic: instead of storing methods on the proxy, what if we created a Hash* pointer in the vtable?
could be done immediately because that isn't a PMC type
chromatic Yes, that's doable, but I like it less.
bacek chromatic, holley schitt. What about compact_pool?
chromatic I like the use of PMCProxy because we can unify method lookup that way.
bacek, I think it grows unconstrained.
whiteknight what do you mean "unify method lookup"?
chromatic Classes look up methods one way. 21:22
PMCs look up methods another way.
bacek chromatic, any test cases?
chromatic Building gen_core.pm for Rakudo.
lucian i'm curious about GSoC. what are the chances of a pynie proposal being accepted?
bacek And it actually grows unconstrained. We just compact it.
PerlJam lucian: zero I'd think. But what do I know? 21:23
chromatic I don't think compacting actually works.
lucian PerlJam: right. well, good to know that's what you think :)
PerlJam lucian: you'd have to show a strong connection between whatever you propose for pynie to perl 5, perl 6, or parrot. That's where the focus lies for TPF. 21:24
chromatic bacek, I *think* the size of the single pool always grows, even if most of the STRINGs are garbage and don't need collected.
lucian PerlJam: right, fair enough
bacek chromatic, hmmm...
lucian PerlJam: i'd propose work to bring pynie as close to CPython as possible 21:25
PerlJam lucian: maybe the python people would approve it :)
chromatic If you write a benchmark that makes a bunch of large strings that are immediately garbage, you should see it grow without bounds.
japhb lucian, better for a submission to the Python foundation?
lucian japhb: yes, that's a consideration as well. i figured i should ask here as well 21:26
Austin lucian: It's a problem of politics and structure. The SoC "slots" are allocated to mentoring organizations. So your project has to be relevant to an organization in order for them to carry it forward to Google.
lucian Austin: true
whiteknight lucian: your project might have a better chance of being supported by the python people 21:27
japhb lucian, As Austin said. TPF + PaFo decided to join forces again this year, in attempt to gain extra slots. But that means they are very Perl-biased.
Well, maybe not 'very', but at least somewhat
whiteknight if the two communities have good report, you could do the project under the python banner with a co-mentor from Parrot
Austin * rapport
PerlJam whiteknight: good point.
whiteknight Austin++
lucian whiteknight: ok. i'll ask around 21:28
PerlJam whiteknight: probably doable too
whiteknight lucian: ask allison, she's friendly with python people
Austin Not that there's anything wrong with that...
whiteknight Austin: did you get my message earlier about kakapo not installing?
Austin Whiteknight: I just pushed a set of Program changes that pass 21:29
lucian Austin: heh
whiteknight Austin++
Austin Yeah, I replied. Look in /usr/local/lib/*parrot*/library/...
japhb chuckled on looking at allison's slide in her Pynie talk at PyCon in which NQP got re-acronymed
whiteknight Austin: I did look there. Nothing
lucian allison: ping
Austin Curiouser and curiouser.
purl Now I'm opening out like the largest telescope that ever was! Good-bye, feet!"
allison lucian: hi
japhb: we're a multi-cultural bunch :) 21:30
japhb whiteknight, kakapo not installing? I just pushed a new Plumage and kakapo metadata, to switch over to using setup.nqp/distutils. Seemed to work here.
lucian allison: i may be interested in doing GSoC work on pynie
Austin whiteknight: I've never actually run the install myself, so I may have misconfigured something in the setup.nqp.
allison lucian: excellent!
purl Smithers, release the hounds!
whiteknight okay, I'll look at it more tonight too. As I mentione,d I'm planning to redo parrot-linear-algebra to use all kakapo all the time 21:31
allison lucian: I'd be happy to mentor
lucian allison: what's the best way to about it? apply to the PSF? PaFo?
moderator #parrot Parrot 2.1.1 Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Tasks: Fix HLL bugs! Fix and test corevm target! 21:31
Coke I think it is possible to cross-post. 21:31
lucian allison: just so you know up front, this would be my second choice, right now Sugar Labs would be my first
allison lucian: PaFo is a small foundation, we've gone under the TPF umbrella
lucian allison: yes, i noticed
Austin Damn, dude! Never tell a woman she's your second choice.
allison luician: it's worth talking to the Python folks and see if they'd be willing to include it in their list 21:32
particle lucian: it might be worth starting a conversation with the org admin for psf, as well as allison
allison++
lucian allison: right. i know the PSF is interested in py3 projects mostly
allison lucian: but feel free to put it in the PaFo queue otherwise
shockwave Are all the vtable methods listed in src/vtable.tbl available to a custom class, or are some of those methods only available if one subclasses specific classes?
allison lucian: pynie *is* a py3 project
lucian allison: right. i'll talk to the PSF people
particle what version of python is pynie emulating? ah, 3, excellent. 21:33
whiteknight shockwave: some of them cannot currently be overridden from PIR
lucian allison: i know, which is why i said that
allison lucian: ah, yeah
whiteknight shockwave: most can, and most *should*. if you find one you cannot override but think of a plausible reason why you would want to, it's a bug
Austin shockwave: All the vtables are on all the pmcs. But not all pmcs use them - like who tries to .invoke() an array?
shockwave whiteknight, is there a way to know which one, or is it a try and see thing?
Coke but in general, all vtables are at least invokable on all pmcs. some will error and carp about being unimplemented, but that's the implementation. =-)
whiteknight try and see, mostly
Coke Austin: I invoke an array all the time: Eval. 21:34
dalek kapo: f1a4df5 | austin++ | (3 files):
Simplified Program, got tests passing for Whiteknight.
Austin (Of course, a MultiSub is sort of an invocable array, but ...)
whiteknight okay, I'm packing up and heading home. Laterz
shockwave whiteknight, Austin, thanks.
Austin Coke: How?
$P0 = new ['ResizablePMCArray'] ; $P0() 21:35
Coke Austin: Eval is an array of subs.
shockwave I hope the "solution" to the assignment issue I'm having will work, even if not very efficient. Sucks that I wont be able to try it for some time. 21:37
dukeleto well, that was an exciting #ps 21:39
Coke oooh, I think I can make all the makefiles autoregen.
chromatic That sounds like a way to orphan files! 21:40
Coke 'include' everything that is dynamically generated, and provide a rule to regen them.
cotto_work Hmm. The profiling runcore seems to be useless for profiling opsc. 21:41
chromatic The line number problem blocking on japhb? 21:42
cotto_work no, it 21:43
s showing almost nothing
I'll be digging into it.
japhb Bah.
chromatic Just call me Mr. Teflon. 21:44
japhb is trying to unblock people, now that tuits not completely eaten, but I've got a substantial backlog.
cotto_work line numbers aren't that big a deal as long as I've got sub info
Coke is this corevm building PGE thing happening in trunk? 21:45
Tene I have a fix for 'rethrow' telling lies about the source of rethrown exceptions in exceptions_refactor branch.
Coke I'm not seeing it.
Tene: wow, that's an old ticket. =-) 21:46
chromatic Coke, it's the pcc hackathon branch.
Coke tene++
chromatic cotto_work, line numbers are very wrong in several places.
cotto_work indeed
Coke chromatic: ... has that branch been updated from trunk lately?
chromatic I thought so, but perhaps not in the past week. 21:47
21:48 bluescreen joined
dalek kudo: 5b81dfe | moritz++ | src/Perl6/ (2 files):
awesomize error message for regexes in packages a bit (though allowing them would really be preferrable)
 21:51
Coke svn++ for # svn ls ^/branches
cotto_work Coke, which version introduces that? 21:53
Coke iunno. "recent"
^ == "repository root"
useful for switch, ls, log, etc.
cotto_work yeah
PerlJam 1.6 I think 21:54
svn++ for finally adding that feature indeed 21:55
Coke that branch predates the mergeback of rm_cflags. 21:59
so I would recommend doing a merge update first. 22:00
(before tackling the corevm problem.)
also, I get no failures on 'make -j3 corevm' in that branch. 22:01
-> 22:02
dalek rrot: r44820 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Op.pm:
remove trailing spaces
rrot: r44821 | mikehh++ | branches/ops_pct/compilers/opsc/src/Ops/Trans/C.pm:
remove trailing whitespace and add copyright and Id
22:08 snarkyboojum joined, bacek joined
tewk How does something get in the embedding interface? 22:08
chromatic We document it as such. 22:09
moritz www.perlmonks.org/?node_id=825863 more parrot hackers need to participate in that poll :-)
particle prepend PARROT_API to the c function definition 22:10
dalek rrot: r44822 | mikehh++ | branches/ops_pct/compilers/opsc/t/common.pir:
remove trailing whitespace and add copyright and Id
 22:19
rrot: r44823 | mikehh++ | branches/ops_pct/compilers/opsc/src/builtins.pir:
remove trailing whitespace and fix copyright and Id
rrot: r44824 | tewk++ | trunk/lib/Parrot/OpsRenumber.pm:
generate include/parrot/opsenum.h
tewk so I only found PARROT_API in one doc file, PARROT_EXPORT seemes to be used by everything in embed.h 22:22
particle tewk: some time ago PARROT_API and PARROT_EXPORT had a divorce, i can't remember who's side we're on. i'm sure it was discussed in #ps and on the mailing list 22:24
GeJ Good morning everyone. 22:25
davidfetter hi GeJ 22:32
tewk particle, yeah I have faint memories of the discussion 22:33
particle it may be, "we'll figure PARROT_API out later, for now, mark what you need exported with PARROT_EXPORT"
dalek rrot: r44825 | mikehh++ | branches/ops_pct/compilers/opsc/opsc.pir:
remove trailing spaces
 22:35
rrot: r44826 | mikehh++ | branches/ops_pct/compilers/opsc/t/03-past.t:
remove trailing whitespace and add copyright and Id
rrot: r44827 | mikehh++ | branches/ops_pct/compilers/nqp/src/Grammar/Actions.pir:
remove trailing spaces
rrot: r44828 | mikehh++ | branches/ops_pct/compilers/opsc/t/01-parse.t:
add copyright and Id and fix coda
tewk which is preferred Parrot_string_ or Parrot_str_ prefix, by count it looks like Parrot_str? 22:40
cotto_work sounds right 22:43
22:44 cotto_work joined 22:46 Andy joined
allison Parrot_str_ is the new (following the coding standards for a short prefix) 22:50
Parrot_string_ is still on some older functions
tewk Adding deprecations now. I've created Parrot_str_is_null and deprecated STRING_is_null too. 22:51
dalek rrot: r44829 | mikehh++ | branches/ops_pct/compilers/opsc/t/07-emitter.t:
add copyright and Id
rrot: r44830 | mikehh++ | branches/ops_pct/compilers/opsc/t (3 files):
add copyright and Id
rrot: r44831 | mikehh++ | branches/ops_pct/compilers/opsc/t/02-parse-all-ops.t:
add copyright and Id
tewk =item C<PMC* Parrot_str_split(PARROT_INTERP, STRING *delim, STRING *str)> 22:53
Splits the string C<str> at the delimiter C<delim>, returning a
C<ResizableStringArray>, or his mapped type in the current HLL,
opps 22:54
lucian allison: i'm trying to make sense of pynie's source. what flavor of developing languages on parrot does it follow? 22:57
cotto_work bacek++ for making all of opsc's test pass again 22:59
PerlJam pynie hasn't been updated to use nqp-rx yet, has it?
japhb PerlJam, last I heard allison was working on that conversion in a separate repo 23:00
PerlJam lucian: if what japhb says is true, *that's* probably the pynie you want to look at.
japhb (And according to her PyCon talk, converting from Python 2.5 grammar + 3.0 fixes to pure 3.0 grammar)
lucian japhb: PerlJam: she directed me to this repo bitbucket.org/allison/pynie/overview/ 23:01
allison the pynie-nqp repo is the update 23:03
but, it's just the fresh grammar
that is, it's a replacement, not an in-place update
though, everything but the grammar and actions file will remain the same after the nqp conversion
lucian is furiously reading parrot docs :) 23:04
allison japhb: yes, the pynie-nqp grammar is a pure translation of the 3.x grammar 23:05
Tene allison: I remember a long time ago we discussed OO for pynie, and you planned to do a lot of thinking about how you wanted to build the metamodel for pynie (not inheriting from P6object, I think). Has that happened? 23:07
allison Tene: for now I'd like to get the simplest possible thing working
Tene nods. 23:08
allison Tene: AFAICT, that's a thin wrapper around Parrot's Object/Class
Tene: I don't see much value in P6object for Python
Tene I'd really like to work on that sometime soon, but I'm not hopeful. 23:09
allison Tene: it's okay
Tene: I worked on it some at PyCon, will work on it some more soon 23:10
Tene: the thing I'm not sure of is whether to work on features, or on moving to NQP
lucian allison: is NQP not quite perl?
allison Tene: I'm finding NQP-rx a lot easier to work with than PGE
PerlJam lucian: aye 23:11
allison lucian: it's a lightweight language used inside the compiler tools
Tene Moving to NQP isn't too bad. I could put whatever time I end up with into that.
lucian allison: reading some nqp code. i guess my eyes are trained to recoil at the sight of perl
allison lucian: aye, my ultimate goal is to write the Python compiler differently (as you heard in my talk), but these tools are quite far along 23:12
lucian: it's a good boot-strap
lucian: don't think of it as perl, just think of it as a declarative DSL 23:13
lucian allison: yes, i get that it's a bootstrap. i'll have to supress my instincts 23:14
allison: i rather like pir. it is indeed the nicest assembly i've ever seen 23:19
23:19 Whiteknight joined
allison lucian: it's a good language, simple and powerful 23:20
particle except where it's messy and ugly 23:22
sure would be nice to get failure semantics cleared up.
dalek rrot: r44832 | tewk++ | trunk (7 files):
Added Parrot_str_is_null, DEPRECATED Parrot_string_* and STRING_is_null
 23:26
Whiteknight did PBC_COMPAT bump recently? 23:32
tewk Whiteknight, are you working on init_int? I've decided to just bust it out, half way done already 23:33
I've got everything done but the vtable, I don't remember how to do those, looking 23:34
chromatic If you benchmark it, we'll get the biggest gains from adding it to CallContext and fixing the "Allocate one cell at a time" nonsense there.
If you're looking for an example of my "make it work, then make a pretty pass" philosophy, the allocation strategy in CallContext is certainly an example of something. 23:35
tewk chromatic, I'm motivated by fixing fixed*arrays but I'll paste a patch 23:36
soon
chromatic Do you consider them buggy or merely inefficient? 23:38
tewk I'm willing to live with data race conditions (who wrote to an array location last) but having to lock on every read and write to the array (sequential consistency) just to see if the array is allocated yet seems wasteful. 23:41
particle can't you emit two instructions for array creation? 23:42
chromatic Arguably you won't have anything sharing an array before you've finished creating it.
tewk particle, sure, but I'm trying to carve out a set of opcodes that have safety properties. And build a runloop that only allows safe instructions. 23:43
dalek rrot: r44833 | whiteknight++ | trunk/src/global.c:
allow adding of :anon :vtable Subs to the namespace. This technically resolves TT #1505, though some cleanup and performance improvements in this area would be welcome additions later
 23:44
tewk if fixed*arrays' actuall data array is allocated when the fixed*arrays is created I know that sets and gets to fixed*arrays are safe. 23:46
cotto_work tewk, opsrenumber is only run rarely, so enumops.h should probably be checked in or built as part of the build process
also, ops_enum.h would be a subjectively nicer name
tewk cotto_work, feel free to fix it 23:47
cotto_work ok
chromatic +1 to ops_enum.h.
tewk I check things in so others can make them better :)
yeah I like it too, +1 I was trying to hard to be consistent to enum_class_ in the filename. 23:48
Whiteknight I check things in so that they may be absolutely perfect the first time!!!
Whiteknight lies
chromatic I like the whole idea, not just the name. 23:49
tewk imperfect checkins helps motivate newcomers that they can contribute too :) I believe in the bazaar.
allison ooh, I forgot to mention in my report, Parrot 2.0 is in Debian and Ubuntu Lucid 23:50
japhb yay!
cotto_work nice 23:51
Whiteknight allison: I would like to learn more about the whole debian packaging process 23:52
tewk howto add a vtable docs? I added a line to src/vtable.tbl, now what?
chromatic Have you heard of the description of Usenet as a stampede of elephants?
allison Whiteknight: happy to pass along info, get people started 23:53
Whiteknight chromatic: that metaphor never accounted for the huge volumes of porn on usenet. To my knowledge, most elephants are not obsessed with porn
japhb chromatic, It is just so much more painful than that
allison Whiteknight: I figure we'll have quite a few packages coming up for various languages
japhb Whiteknight, only because they haven't been provided with elephant-friendly cameras
Whiteknight allison: how painful is it? With the infrastructure in place now, how hard is it to get a release into the package repos?
dalek TT #1505 closed by whiteknight++: :anon vtable overrides don't work in PIR 23:54
Whiteknight japhb: they say the camera adds 15,000 lbs
chromatic Besides the large quantities of processed elephant food the process produces, it also produces large amounts of arguing over the legal intent and interpretation of non-legal documents written by non-lawyers and interpreted by non-lawyers.
allison Whiteknight: it can be slow, but patient persistence seems to do it
tewk plumage should provide a autopackage for debian/ubuntu, how I wish cpan had that feature 23:55
allison tewk: that would be great
Whiteknight allison: (patient persistance) damnit! I was hoping I could help!
japhb fperrad++ has been doing a great job of making Plumage metadata for everything under the sun. That should be a very useful boost for doing system packages. (Plus I think distutils does/will have some ability to make packages on its own)
allison tewk: some custom rolling likely still needed, but the common cases can be tackled
japhb Whiteknight, (re: 15000 lbs) *chuckle*
tewk allison, right, but it should do 95% of the work 23:56
japhb tewk: Plumage + distutils seems to be a powerful combo.
tewk japhb, I need to take a look at it sometime, nqp-nx too, I spend all my time in the c guts of parrot and PLT Scheme. 23:57
japhb nodnod
chromatic didn't realize PLT Scheme had a lot of C guts.
tewk Yes it has a lot, we want to get rid of them but we have less man power than parrot and a lot more complex, complete features. 23:58
it grew out of libscheme and has its C roots from there.
chromatic In the words of the tenth Doctor, "I'm sorry. I'm so sorry." 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!