|
half-pie" released! | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview Set by moderator on 5 October 2009. |
|||
| darbelo | coverage? | 00:02 | |
| purl | well, coverage is cv.perl6.cz | ||
| dalek | TT #1095 created by geraud++: [PATCH] un-TODO unconditionally some tests in t/op/io.t | ||
|
00:04
bacek joined
|
|||
| GeJ | regarding TT#1095, my bad. I should have filled a TT when I reported it on IRC. | 00:05 | |
| G'Day bacek | |||
| darbelo | GeJ: Not a problem. Do we know the NetBSD status now? | ||
| bacek_at_work | G'Day GeJ | 00:06 | |
| nopaste | "darbelo" at 200.49.154.173 pasted "src/library.c: Now strstart free!" (33 lines) at nopaste.snit.ch/18236 | 00:10 | |
| darbelo | Can I get a win32 test of nopaste.snit.ch/18236 | 00:11 | |
| I'd rather not bother ttbot this late :) | |||
| GeJ | darbelo: no info on NetBSD but I can try to subvert a NetBSD user to make a run. However, I'd bet that the tests will pass there as well. | 00:17 | |
| darbelo | That's my guess as well, but it doesn't hurt to check ;) | 00:18 | |
| GeJ | Eventually, I'll try to get a shell on a NetBSD box tonight and see if I can run it myself. | ||
| darbelo | Do we have any regular NetBSD smokers? | 00:20 | |
| Or is it smolderers now? | |||
| smolder? | 00:22 | ||
| purl | somebody said smolder was sourceforge.net/projects/smolder or web-based smoke test aggregator used by developers and testers to upload (automated or manually) and view smoke/regression tests using the Test Anything Protocol (TAP). or smolder.plusthree.com/app/public_pr..._reports/8 | ||
| darbelo | smolder slooooooow. | 00:24 | |
| GeJ | smolder.plusthree.com/app/public_pr.../28566/106 | 00:25 | |
| shorten | GeJ's url is at xrl.us/bfqmw6 | ||
| GeJ | smolder.plusthree.com/app/public_pr...ails/28566 (for the big picture) | 00:26 | |
| shorten | GeJ's url is at xrl.us/bfqmxg | ||
| GeJ | it looks like the latest smoke test from a NetBSD user. | ||
| Ryan52 | so in a chroot rakudo segfaults. the gdb traceback shows all parrot stuff, so...how can I debug this? | ||
| GeJ | both TODO tests are ok. | ||
| darbelo | Yeah, found it. But the way they're being TODOed doen't leave room for a TODO PASS result, which is what I wanted to check. | 00:27 | |
|
00:28
Zak joined
|
|||
| darbelo | GeJ: Ok, commited. We'll see how much smoke pours in after this. | 00:31 | |
| dalek | rrot: r41731 | darbelo++ | trunk/t/op/io.t: Unconditionally un-TODO tests in t/op/io.t, they PASS everywhere now. |
||
|
00:33
cotto joined
|
|||
| GeJ | darbelo++ | 00:33 | |
| thanks | |||
|
00:37
bacek_at_work joined
|
|||
| dalek | TT #1095 closed by darbelo++: [PATCH] un-TODO unconditionally some tests in t/op/io.t | 00:38 | |
|
00:48
rhr joined
|
|||
| japhb | Should an exception handler include a pop_eh? | 01:37 | |
| I'm getting mixed signals from the docs | |||
| Tene | japhb: Um... it depends on exactly what you mean. | 01:38 | |
| >.> | |||
| japhb: that is, on what your code is saying. | |||
| darbelo | japhb: Ideally, yes. | ||
| Tene | They mean different things, so it varies. | ||
| japhb | Tene, explain please. What are the cases? | ||
| Tene | japhb: you should pop_eh if you want the EH to be gone, and don't pop_eh if you don't want the EH tob e gone. | 01:39 | |
| many EHs, after handling the exception, jump back into some kind of loop. | |||
| japhb | ah! OK. | ||
| darbelo | If you push_eh, you should pop_eh once you no longer need the 'eh'. | ||
| Tene | some EHs, after handling the exception, terminate and go off somewhere else. | ||
| japhb | yep, the latter is the case I'm dealing with. | ||
| So I should do pop_eh right after .get_results, yes? | 01:40 | ||
| Tene | japhb: yeah, that will be fine. | ||
| japhb | OK, cool, thanks. | ||
|
02:00
darbelo left
02:01
rhr joined
02:35
janus joined
|
|||
| dalek | ose: r180 | Austin++ | trunk/ (25 files): Got more visitors working object-style. |
02:41 | |
|
02:52
cottoo joined
02:54
cotto joined
|
|||
| Ryan52 | slexy.org/raw/s228rtU4Y1 | 03:03 | |
| this is with the latest released parrot and latest release rakudo in a minimal chroot. | 03:04 | ||
| any ideas or steps to debug better? | |||
| if there's anybody else who actually has a clue what they're doing who would be willing to debug it, I can give you access to the system. | 03:07 | ||
|
03:09
kjeldahl__ joined
03:27
TonyC joined
03:30
napalm joined
04:10
nopaste joined,
TonyC joined
04:48
baest joined
06:24
uniejo joined
06:28
xenoterracide joined
06:36
mokurai left
06:53
mberends joined
|
|||
| moritz | tonight I dreamt that the pcc-rewire branch passed all tests. Really. | 07:00 | |
|
07:07
fperrad joined
07:08
Zak joined
07:09
kurahaupo joined
|
|||
| cotto | I hardly ever get to think about code enough that I dream about it, though I think I did have a dream involving the profiling runcore at one point. | 07:14 | |
| moritz | well, I didn't even touch any code (except a test regex) in that brnach | 07:16 | |
| usually I just dream that stuff I checked in the previous night is horribly broken | |||
|
07:20
bacek joined
|
|||
| bacek | o hai | 07:20 | |
|
07:22
TiMBuS joined
|
|||
| bacek | moritz: why you are dreaming about pcc-reapply branch? | 07:23 | |
| moritz | bacek: no idea | ||
| bacek | moritz: :) | ||
| cotto | clock? | 07:28 | |
| purl | cotto: LAX: Tue 12:28am PDT / CHI: Tue 2:28am CDT / NYC: Tue 3:28am EDT / LON: Tue 8:28am BST / BER: Tue 9:28am CEST / IND: Tue 12:58pm IST / TOK: Tue 4:28pm JST / SYD: Tue 6:28pm EST / | ||
| xenoterracide | question... how easy would it be to create a 'template engine' in parrot vs one in perl5? | 07:31 | |
| bacek | xenoterracide: depends on "template engine". You can easily create some sort of DSL using PCT in parrot. | 07:35 | |
| xenoterracide | DSL? PCT? | 07:36 | |
| cotto | dls? | ||
| purl | dls is the dalles oregon | ||
| cotto | dsl? | ||
| purl | i think dsl is digital subscriber line or a conspiracy to collect geeks near major cities so they'll be easier to round up when society collapses. or Dammit Slow Link or diesel in kewlt0k. or Dick Sucking Lips or LSD BACKWARDS or a Domain Specific Language or the Definitive Software Library or french for 'damn slow line' | ||
| cotto | domain specific language | ||
| pct? | |||
| purl | pct is probably the Parrot Compiler Toolkit | ||
| xenoterracide | ah | 07:37 | |
| dalek | rrot: r41732 | bacek++ | branches/pcc_reapply/src/ops/core.ops: Remove unused ccont from op set_returns |
||
| rrot: r41733 | bacek++ | branches/pcc_reapply/src/call/args.c: Remove unused ctx in fill_returns. |
|||
| cotto | now you know | 07:39 | |
| purl | And knowing is half the battle. | ||
| moritz | writing the parser is probably much easier with parrot | 07:42 | |
| cotto | we do have some unusually shiny parsing tools | 07:44 | |
| moritz | and they are going to become even more shiny real soon ;-) | ||
| cotto | but not so shiny that it's going to keep me up any longer. good night all. | ||
| moritz | 'night cotto | 07:45 | |
| xenoterracide | ... will parrot languages work with just mod_parrot? or do they require mod_parrot plus there own mod? | 07:47 | |
|
07:47
AndyA joined
|
|||
| xenoterracide | or do they just need there own mod? | 07:47 | |
|
07:54
iblechbot joined
|
|||
| bacek | xenoterracide: mod_parrot will probably enough | 07:57 | |
| xenoterracide | so then why is there a mod_perl6? | ||
| moritz | I think it's more high level than mod_parrot | 07:58 | |
| xenoterracide | k | 07:59 | |
| anyone know of any vim syntax highlighting files for parrot? | 08:02 | ||
| moritz | xenoterracide: look in the editor/ dir | 08:04 | |
| xenoterracide | how do you know whether to write in pir/pasm/npq ? | 08:15 | |
| moritz | if I were to do such a thing, I'd write as much as possible in nqp, because it's most high level | 08:16 | |
| actually I'd do it straight in Perl 6, with Rakudo :-) | 08:17 | ||
| bacek | xenoterracide: you don't know. You just free your mind, put hands on the keyboard and at the end of the day watching beautiful state of art code written in unspeakable language | ||
| xenoterracide | is code written in pir faster? | ||
|
08:18
fperrad_ joined
|
|||
| moritz | faster than perl 6, yes | 08:18 | |
| xenoterracide | well faster than npq | ||
| moritz has no idea | 08:19 | ||
| but nqp doesn't optimize, so it's propably a bit slower | |||
| xenoterracide | err nqp | ||
| right | |||
| although technically I'm thinking of just using it as a template language I may end up just implementing the whole spec. or as usual I may end up doing nothing | 08:21 | ||
| moritz | :-) | ||
| xenoterracide | I'm just thinking that since I may end up implementing the whole language... it may not hurt to just start by writing it in parrot | 08:22 | |
| another question how hard would it be to create multiple syntax's that do exactly the same thing? | 08:25 | ||
| would you create wrapper code? | |||
| moritz | it depends on how similar the structure is | ||
| xenoterracide | ah | 08:26 | |
| moritz | if the second version just uses different literals, you can write a set of common action methods, and re-use them for different syntaxes | ||
| but if they differ very much in the structure, you might have to do much more | |||
| xenoterracide | hmm... well I'm thinking about implementing cfml on parrot... I sorta like the language but I hate it's obsessive use of cf at the beginning of everything... I'd rather just have <if> than <cfif> however, it'd be nice to support existing code... so I'd think supporting both syntax's would be key | 08:28 | |
| moritz | that looks not hard at all | 08:30 | |
| mikehh | All tests PASS (pre/post-config, smoke (#28611), fulltest) at r41731 - Ubuntu 9.04 amd64 | 08:31 | |
| xenoterracide | however there's also cfscript which I believe uses a C style syntax but is otherwise doing the same things | 08:32 | |
| dunno looked at cfml once and liked the syntax (at least to some degree) but I hate that all cfml runs on java | |||
| moritz | if you structure your rules cleverly, you can make the <cfif> vs. <if> distinction by simply subclassing the grammar | 08:33 | |
| xenoterracide wonders why parrot has its own irc server | 08:41 | ||
| szbalint | it doesn't | 08:46 | |
| if you mean this network that is | |||
|
08:47
bacek joined
08:48
payload joined
|
|||
| moritz | there is a separate irc.parrot.org, but I've never used it | 08:49 | |
| xenoterracide | moritz: that's what I'm connected to now | 08:51 | |
| szbalint | that's here | ||
| $ host irc.parrot.org | |||
| irc.parrot.org is an alias for irc.perl.org. | |||
| moritz | oh | ||
| szbalint | this is the trick :) | ||
| xenoterracide | right | 08:53 | |
| xenoterracide thinks ya'll should just be on freenode | 08:54 | ||
| moritz | #perl6 is on freenode :-) | ||
| but you already found that | 08:55 | ||
| xenoterracide | yep | ||
| I just don't see the need for perl or mozilla to have there own irc networks.... I think it'd be better if all of foss was on 1 network | |||
| moritz | NIH-syndrome | 08:56 | |
| xenoterracide | prolly | 08:57 | |
| or freenode wasn't around/awesome when it was created | |||
| moritz | some things on freenode are also quite complicated | 08:58 | |
| like recovering a "lost" channel | |||
| xenoterracide | lost? | ||
| purl | lost is the past tense of to lose or what we call those who are stuck on WINN'T. or "I fell on it in the shower" | ||
| xenoterracide | lol | ||
| moritz | on irc.perl.org one can just talk to one of the admins, and they'll give ops to a few people they know | ||
| xenoterracide | moritz: I've been able to do that on freenode | 08:59 | |
| of course I had connections | |||
| moritz | "lost" == person who registered the channel went away | ||
| xenoterracide | person who registered should have defined multiple contacts... and create multiple ops | ||
| moritz | we have multiple ops, but can't add new ones (for #perl6) | 09:00 | |
| xenoterracide | huh | ||
| I don't know | |||
| 'course if I have a problem on freenode serious enough I tend to slap christel w/ a fish | 09:01 | ||
| xenoterracide wonders why I'm up at 5am | |||
| mikehh | pcc_reapply - revision make smolder_coretest #28614 | 09:05 | |
| revision r41733 | |||
| 10am for me :-} as for bacek ... | 09:07 | ||
| xenoterracide | grr... why doesn't this just run... | 09:11 | |
| bacek | who called my name? | 09:17 | |
|
09:20
particle joined
|
|||
| xenoterracide | is there any documentation for installing these .vim files | 09:23 | |
| oh guess there's a pod | |||
| moritz | it's called README so that nobody's ever going to read it :-) | 09:24 | |
| xenoterracide | readme's are overly complicated | ||
|
09:24
masak joined
|
|||
| xenoterracide | of course the fact that I had to download the source tarball to get these is kinda silly | 09:25 | |
|
09:43
riffraff joined
09:49
mberends joined
09:55
particle joined
10:29
kid51 joined
10:31
quek joined
10:34
riffraff joined
10:42
sri joined
10:43
cconstantine joined
11:30
ruoso joined
11:54
tetragon joined
12:12
preflex joined
12:15
whiteknight joined
|
|||
| whiteknight | good 'morrow parrot | 12:18 | |
|
12:24
bluescreen joined
|
|||
| Util | whiteknight: Is it tomorrow already? JIT! | 12:28 | |
| whiteknight | Util: It's always tomorrow somewhere | ||
|
12:30
szabgab joined
|
|||
| Util | Some people carry so much yesterday with them, that they cause tidal effects. | 12:30 | |
| whiteknight | pcc_reapply doesn't even build on win32 right now apparently | 12:34 | |
| src/nci_test.c says undefined reference to PMCNULL | 12:37 | ||
|
12:44
whiteknight joined
12:45
allison joined
12:47
bluescreen joined
|
|||
| jonathan | oh hai | 12:54 | |
| Need to check against latest Parrot, but just got back from vacation and the version Rakudo uses segfaults... :-S | 12:55 | ||
| In miniparrot.exe | |||
| whiteknight | I was seeing some smoke failures in trunk I think. I haven' looked at it recently | 12:59 | |
| I've been focusing much effort on the pcc_reapply branch | |||
| jonathan | I'm trying latest now. If latest works, I'll go with that. | ||
| No, same. | 13:00 | ||
| *sigh* | |||
| Oh, Rakudo defaults to optimized build now. | 13:02 | ||
| Trying non-optimized. | |||
| ah | 13:03 | ||
| that gets further | |||
| moritz | if that's the culprit, you change Configure.pl to only default to optimized build on non-windows platforms | ||
| jonathan | moritz: yup, doing that | 13:06 | |
|
13:08
particle joined
|
|||
| dalek | kudo: f845ccf | jonathan++ | Configure.pl: On Win32, the optimized Parrot does not even build, so don't do --optimize on Win32 for now. |
13:21 | |
| shorten | dalek's url is at xrl.us/bfqpbn | ||
|
13:22
iblechbot joined
13:24
AndyA joined
|
|||
| whiteknight | something is definitely broken on win32. Needs us some fixin' | 13:27 | |
| jonathan | whiteknight: It blew up somewhere in pcc. | 13:38 | |
| whiteknight: But that doesn't have to mean the problem is in there. | |||
| whiteknight | right | 13:39 | |
|
13:54
PacoLinux joined
14:15
theory joined
14:20
Psyche^ joined
14:30
PacoLinux joined
14:37
ruoso joined
15:07
allison joined
15:16
pyrimidine joined
|
|||
| whiteknight | good morning allison | 15:19 | |
|
15:19
mokurai joined
|
|||
| pyrimidine | Odd, can't connect to #perl6 | 15:20 | |
| moritz | pyrimidine: are you on irc.freenode.net (or .org)? | 15:21 | |
| masak was just going to ask the same | |||
| pyrimidine | moritz: irc.freenode.net | ||
| purl | hmmm... irc.freenode.net is home of the mirror universe #perl that isn't full of assholes. or where you can find a #perl that's supposedly actually got something to do with perl | ||
| masak | purl: talk a lot, do you? | 15:23 | |
| purl | masak: i haven't a clue | ||
| masak | I guess that's part of the problem. | ||
| allison | whiteknight: good morning | ||
| moritz | pyrimidine: I'm removing a few bans now | ||
| pyrimidine: please try again | 15:24 | ||
| pyrimidine | Can't connect via Colloquy, but I can comment via browser | 15:25 | |
|
15:26
coke joined
|
|||
| coke ~~ | 15:26 | ||
| Coke | opbots, names | 15:27 | |
| opbots, trust andya | |||
| slavorgn | Ok | ||
| slavorg | Ok | ||
| Coke | opbots, names | ||
| (too slow) | |||
| Coke ~~ from the UK | 15:28 | ||
| pyrimidine | moritz: ok, seems to be working now with colloquy. | 15:29 | |
| thx | |||
| moritz | you're welcome | 15:30 | |
| dalek | rrot: r41734 | japhb++ | trunk/config/auto/opengl.pm: [OpenGL] Ancient and small doc patch that I'd forgotten to commit |
15:38 | |
|
15:39
jrtaylor joined
15:55
darbelo joined
|
|||
| mikehh | hi Coke, y'all in Leeds? | 16:05 | |
|
16:08
davidfetter joined
|
|||
| dukeleto | 'ello | 16:31 | |
| whiteknight | 'ello poppet | 16:36 | |
|
16:50
cotto_work joined
|
|||
| dalek | rrot: r41735 | pmichaud++ | branches/pct-rx: [pct-rx]: Removing branch, now developing in a github repository (pmichaud/nqp-rx). |
17:16 | |
| darbelo | slow day. | 17:27 | |
| whiteknight | yeah it is | ||
| darbelo | did anyone test nopaste.snit.ch/18236 on win32? | 17:28 | |
|
17:30
Andy joined
|
|||
| darbelo | whiteknight: ping. | 17:36 | |
| whiteknight | pong | ||
| darbelo | You were doing some IO refactors a while back. What came out fo those? | 17:37 | |
| whiteknight | a long task list :) | 17:38 | |
| There is much more IO work to do, but I got delayed and then distracted | |||
| dalek | rrot: r41736 | Util++ | trunk (3 files): Removed bogus properties from files: "svn", "mime-type", "snv:eol-style". |
17:39 | |
| jonathan | When is #ps? | 17:40 | |
| 50 mins? | |||
| darbelo | Got a link to the task list? | 17:41 | |
| cotto_work | jonathan, yes | ||
| darbelo goes afk | |||
| Util | darbelo: if you mean the milestone list: trac.parrot.org/parrot/report/14 | 17:42 | |
| jonathan | cotto_work: thanks | ||
| <- away for a month, only just getting back into the swing of things | |||
| dalek | rrot: r41737 | Util++ | trunk: Removed bogus properties from root dir: "svn:mime-type", "svn:keywords", "Makefile.PL". |
17:43 | |
| cotto_work | Tene, if all you do is make fill_params work, feel free to call it a good week. | 17:52 | |
|
17:53
preflex joined
17:54
fperrad_ joined
17:55
jsut joined
|
|||
| darbelo | Util: no, I meant whiteknight's io task list. | 17:56 | |
| allison | Tene: are you working on fill_params now? | 17:57 | |
| Util | darbelo: KTHX | ||
| darbelo | But I found it on the wiki. | ||
| allison | Tene: (I made changes to your patch last night, then reverted them, didn't like the direction it was heading) | ||
| Tene | allison: I'm working on contacting HP support to deal with lab machines that have spontaneously gone offline. | ||
| So... no. :) | 17:58 | ||
| allison | Tene: no worries | ||
| Tene: I'm going to go ahead and check your patch back in | |||
| Tene | :) | ||
| I'll look at it when I get home tonight. | |||
| allison | Tene: I know it breaks tests, but it'll be easier to check in fixes as small modifications | ||
| Tene: (and easier for both of us to work on it that way) | 17:59 | ||
| cotto_work | It's a branch. The whole point is that the rest of us don't have to worry too much if it breaks tests. | ||
| Tene | I'd branch the branch, but I don't want anyone sending me a mail bomb. ;) | 18:00 | |
|
18:07
kurahaupo joined
|
|||
| dalek | rrot: r41738 | Util++ | branches/autoprops: TT#994 Creating a private, temporary branch of trunk/editor to test git-svn autoprops. |
18:12 | |
| Coke | mikehh: yes, in leed.s | 18:13 | |
| just got some extremely yummy thai takeaway. mmmm. | |||
| I could get used to this. | 18:14 | ||
| ps? | 18:18 | ||
| purl | ps is postscript or process status or see "parrotsketch" or non-vector?! or annoying. | ||
| Coke | parrotsketch? | ||
| purl | rumour has it parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch | ||
| Coke | clcok? | ||
| purl | clcok is clock or cock | ||
| Coke | clock? | ||
| purl | Coke: LAX: Tue 11:18am PDT / CHI: Tue 1:18pm CDT / NYC: Tue 2:18pm EDT / LON: Tue 7:18pm BST / BER: Tue 8:18pm CEST / IND: Tue 11:48pm IST / TOK: Wed 3:18am JST / SYD: Wed 5:18am EST / | ||
| darbelo | PDT == Parrot Developer's Time? | 18:19 | |
| Coke | parrotsketch in 70? | ||
| cotto_work | Coke, closer to 10 | 18:20 | |
|
18:20
barney joined
|
|||
| Coke | ah, right, LON NE GMT. | 18:20 | |
| er, NE UTC | 18:21 | ||
| mikehh | UTC +1 | ||
| dalek | rrot: r41739 | allison++ | branches/pcc_reapply/src/call/args.c: [pcc] Reapplying r41721, Tene's work on return handling, so we can work on the |
||
| mikehh | summer time or whatever | ||
| allison | depending on daylight saving time | ||
| whiteknight | I am very interested to see what makes this work | ||
| because I really don't understand the returns algorithm | |||
| dalek | rrot: r41740 | allison++ | branches/pcc_reapply/src/call/args.c: [pcc] A few quick fixes to return/result handling. |
18:28 | |
| allison | whiteknight: it's largely the same as the args/params algorithm, just the storage is different | 18:31 | |
| whiteknight | Seems then that we could use fill_params with different accesor function pointers | 18:32 | |
| darbelo | #ps in 0 | ||
| whiteknight | but I'm getting ahead of myself | ||
|
18:33
bacek joined
|
|||
| darbelo | Hello bacek | 18:33 | |
|
18:33
chromatic joined
|
|||
| jdv79 | i remember someone suggesting a hw parrot vm implementation. just curious - has anyone ever seen a hw jvm or .net vm or any vm? | 18:34 | |
| cotto_work | jdv79, there are some partial hardware jvm implementations. | 18:35 | |
| chromatic | I've seen JVM hardware -- the Java Ring. | ||
| whiteknight | jdv79: Yes, I've looked at them closely | ||
| chromatic | A lot of ARM processors have hardware support for some JVM operations. | ||
| Azul systems has a Java processor. | |||
| whiteknight | I would love to to a PBC-based processor hardware, if I were still doing hardware stuff | 18:36 | |
| jdv79 | did it really provide sufficient value? | ||
| chromatic | Azul's stuff seems to. | 18:37 | |
| They have hardware support for GC and JVM memory management. | |||
| whiteknight | I was looking at an HDL design that would integrate a few picoblaze sub-cores to handle things like GC that would be hard to do in hardware | 18:39 | |
| chromatic | Even merely read/write barrier support in hardware would be a huge improvement. | 18:40 | |
| whiteknight | we don't read/write barrier in trunk now though | ||
| dalek | rrot: r41741 | pmichaud++ | trunk/runtime/parrot/library/PGE/Perl6Grammar.pir: [pge]: Add ability for PGE::Perl6Grammar to handle category:sym<...> names. |
18:41 | |
|
18:41
jrtaylor joined
|
|||
| chromatic | Lorito will make read/write barriers easier. | 18:41 | |
| particle | a microkernel code, named seL4, has been proven correct, and will soon be available as a hypervisor. nicta.com.au/news/current/world-fir...eliability | 18:42 | |
| shorten | particle's url is at xrl.us/bfqq4b | ||
| jrtaylor | chromatic, how so? | ||
| chromatic | If we know that all "Store this!" operations go through a single opcode, we can annotate that opcode. | 18:43 | |
| jrtaylor | oh, I see. | 18:44 | |
| thanks | |||
| whiteknight | being able to write certain operations only once means that when we need to make a change, we only need to make it once | 18:47 | |
| chromatic | Or if we need to swap it out for profiling.... | ||
| jdv79 | yes, L1 sounds too good to be true. | 18:50 | |
| japhb | dukeleto, want Plumage commit bit? | 18:52 | |
| dukeleto | japhb: surely | ||
| japhb: it is on gitorious? | 18:53 | ||
| japhb | Have signed PaFo CLA sent in? | ||
| dukeleto, yup | |||
| dukeleto | i haven't used that yet | ||
| japhb: yes, I am a parrot committer | |||
| japhb | It's github with less social and more stable. | ||
| dukeleto | japhb: that is a good, concise description of it | ||
| japhb: do I need to make a gitorious account? | |||
| japhb: or do you just need a key from me? | 18:54 | ||
| japhb | dukeleto, yup. Just send me the gitorious nick once you have it set up, and I'll add you to the project. | ||
| dukeleto | japhb: okely dokely | ||
| japhb | (y) | ||
|
18:56
cconstantine left
18:59
joeri joined
|
|||
| Coke | aigh. SG:U is on sky 1... and I only have sky 3 here. curses. | 19:03 | |
| japhb has to wait for Netflix for SG anyway ... | 19:04 | ||
| Coke | And I apparently missed it in the states last friday. | 19:05 | |
| coises. | |||
| chromatic | Given how they handled the end of Atlantis, were you *really* anticipating it? | 19:09 | |
| Coke | chromatic: you're talking to the guy who watched every episode of andromeda because he watched part of the first season. | 19:14 | |
| and I have lot invested into SG:1. =-) | |||
| chromatic | Oh yeah, Andromeda. Sigh. | 19:15 | |
| I liked the Gaheris Rhade episodes. | |||
| japhb | Rhade++ | 19:16 | |
| whiteknight | MMV? | ||
| japhb | I miss "Excalibur", the follow-on to Babylon 5. The cast was just beginning to gel when they got cancelled. | 19:17 | |
| chromatic | Excalibur or Crusade? | ||
| japhb | Maybe I got mixed up. The one based on the ship that looked kinda like a sword from the side, and could only fire its main gun every few minutes (the ship being dead in space for a while after it fired) | 19:18 | |
| Coke | crusade. I think excalibur was the ship | ||
| whiteknight | allison: what's the status of pynie? Where is it hosted now? | 19:19 | |
| kurahaupo | I've had a nagging feeling for the last week about the ResizableXXXArray PMCs' lack of memory initialization. I was told that the lack of initialization is because they're "low level", yet they have push/pop/shift/unshift implemented in ways that bespeak being intended as a higher-level construct than the corresponding FixedXXXArray. | ||
| (If we really care about them being fast for push/pop etc they'd be done with ring-buffer counters, not by shifting memory blocks.) | 19:20 | ||
| whiteknight | all the array types are in desperate need of an overhaul, yes | 19:21 | |
| japhb | I thought bacek was working on that? Or did he get sidetracked? | 19:22 | |
| whiteknight | kurahaupo: create a page like "ArrayTasklist" on the wiki where we can start putting ideas | ||
| allison | whiteknight: on google code | 19:24 | |
| pmichaud | Util: (re STD.pm and protoregexes) protoregexes and ltm aren't the only blockers to STD.pm, but they're the major ones atm | 19:26 | |
| Util | pmichaud: OK, thanks. | ||
| pmichaud | Util: I think it's also the case that once Rakudo and NQP have protoregexes and ltm, we'll see a convergence of grammars more than "Rakudo adopting STD.pm" | ||
| chromatic | Convergence seems most likely to me as well; Rakudo's parser pulls in more and more of STD. | 19:27 | |
| pmichaud | I can't speak for TimToady++, but my feeling is that this round of implementation is going to affect STD.pm about as much as STD.pm is affecting Rakudo | ||
|
19:27
payload joined
|
|||
| dalek | tracwiki: v105 | whiteknight++ | WikiStart | 19:28 | |
| tracwiki: +tasklist page for cleanups of Array-like PMCs | |||
| tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfqq95 | ||
| pmichaud | so, my feeling is that the next round of rakudo grammar will be _very_ STD.pm like but not entirely STD.pm | 19:29 | |
| moderator | half-pie" released! | Test CallSignature PMC | pcc_reapply branch still needs your love! trac.parrot.org/parrot/wiki/Callin...nsOverview | 19:35 | |
| dalek | tracwiki: v1 | kurahaupo++ | ArrayTasklist | 19:45 | |
| tracwiki: new page. open question about lack of initialization of resizable arrays | |||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfqrcu | ||
| bacek | Good morning | 19:48 | |
| whiteknight | kurahaupo: We should look through the tickets list to find any array-related tickets and add them to the tasklist | 19:50 | |
| dalek | tracwiki: v2 | whiteknight++ | ArrayTasklist | 19:51 | |
| tracwiki: + two tasklist items concerning arrays | |||
| whiteknight | #1089 and #1072 are good candidates | ||
| dalek | tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | ||
| shorten | dalek's url is at xrl.us/bfqrdv | ||
| whiteknight | #1039, #809, #879, #218, #159 | 19:55 | |
| dalek | tracwiki: v3 | kurahaupo++ | ArrayTasklist | 19:58 | |
| tracwiki: Make multiple variants for different purposes? | |||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfqres | ||
| kurahaupo | whitenight: #1089 has contributions already. | 19:59 | |
| whitenight: #1089 has my contributions already. | 20:00 | ||
| whiteknight | could still be listed on the tasklist | ||
|
20:05
jan joined
|
|||
| dalek | tracwiki: v4 | kurahaupo++ | ArrayTasklist | 20:08 | |
| tracwiki: Links to related tickets | |||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfqrgf | ||
| whiteknight leaves. Later | 20:10 | ||
| cotto_work | clock? | 20:13 | |
| purl | cotto_work: LAX: Tue 1:13pm PDT / CHI: Tue 3:13pm CDT / NYC: Tue 4:13pm EDT / LON: Tue 9:13pm BST / BER: Tue 10:13pm CEST / IND: Wed 1:43am IST / TOK: Wed 5:13am JST / SYD: Wed 7:13am EST / | ||
| chromatic thinks he may have fixed line numbering in IMCC. | 20:14 | ||
| darbelo | chromatic | 20:16 | |
| chromatic++ | |||
| cotto_work thinks me may be impressed | |||
| chromatic, as in completely fixed or just significantly less broken? | 20:17 | ||
| chromatic | Less broken. | ||
| I'm chasing an off-by-one in macros that I think I know how to fix. | |||
| cotto_work | still impressive given imcc's code | ||
| Tene | chromatic++ | 20:20 | |
| cotto_work | yes. chromatic++ | ||
|
20:20
zerhash joined
|
|||
| dalek | tracwiki: v5 | kurahaupo++ | ArrayTasklist | 20:21 | |
| tracwiki: more related tickets, plus details | |||
| tracwiki: trac.parrot.org/parrot/wiki/ArrayT...ction=diff | |||
| shorten | dalek's url is at xrl.us/bfqrhc | ||
| dukeleto | i am all about rallying and getting pcc_reapply merged in for 1.7 . let me know what I can do to make this happen. | 20:26 | |
| cotto_work hands dukeleto a whip and points at Tene | |||
| dukeleto | so, we are down to 58 failed tests in coretest? | 20:29 | |
| Tene | dukeleto: please feel free to harass me daily or more to work on pcc. I'm at work right now, so don't have the concentration, but I should be home in 3 or 4 hours. | ||
| pmichaud | hugme help | 20:30 | |
| hugme: help | |||
| oops, wrong chan | |||
| dukeleto hugs pmichaud anyway | 20:32 | ||
| Tene: ok, you asked for it :) | |||
| cotto_work | dukeleto, I imagine that understanding the algorithm that fill_returns is trying to implement would be helpful too, in case Tene++ needs another set of eyes. | 20:36 | |
| Tene | cotto_work: the alg is on the wiki, approximately. | ||
| cotto_work | yup | ||
| dukeleto | which page on the wiki? | ||
| the calling convention overview? | 20:37 | ||
| cotto_work | dukeleto, yes | ||
| I wonder why we're implementing all these fancy calling conventions when we know they won't be sufficient for our poster child Rakudo. | 20:38 | ||
| dukeleto | cotto_work: good question. care to expand? Why are they not sufficient? | ||
| cotto_work | I don't know the details, but I remember pmichaud saying something to that effect recently. | 20:39 | |
| jonathan | Actually, all Rakudo really wants is raw access to the CallSignature. | ||
| moritz | there's one thing that isn't supported by parrot right now which rakudo needs: calling a positional argumet by name | ||
| jonathan | (And in the long run, that the CallSignature doesn't put the nameds into a hash.) | 20:40 | |
| moritz | consider sub foo($a, $b, $c). in Perl 6 you're allowed to call foo(1, 3, b => 2) | ||
| jonathan | moritz: We're going to have a custom binder for Rakudo anyway, so it's now irrelevant to Rakudo whether Parrot does this or not. | ||
| moritz | and that will mean $a => 1, $b => 2, $c => 3 | ||
| jonathan | It may be interesting to other HLLs. | ||
| But Rakudo is very much going its own way. | 20:41 | ||
| The main important thing about the refactor is that all calls populate a common data structure (the CallSignature) that Rakudo can then take and process as it wishes. | |||
| I the end, I've concluded it's just unrealistic to expect Parrot to support all of the ins and outs of Perl 6 signature binding. | 20:42 | ||
| cotto_work | I know Pipp won't care in the slightest, but that's just because PHP only supports positionals iirc. | 20:43 | |
| mikehh | pcc_reapply - there have been 123 commits to the branch since it was created (inclusive) as follows: | 20:46 | |
|
20:49
bluescreen joined
|
|||
| dukeleto | msg japhb my gitorious username is 'leto' | 20:50 | |
| purl | Message for japhb stored. | ||
| Tene | cotto_work: embrace and extend? ;) | ||
| dukeleto | if I am going to add new tests to CallSignature, should it be done in trunk or pcc_reapply ? | 20:53 | |
| moritz | I think pcc_reapply makes more sense (but IANARPH) | 20:54 | |
| dukeleto | moritz: i think i figured out your TLA :) | 20:57 | |
| ug | |||
| not TLA, but acronym | |||
| moritz | "I Am Not A Real Parrot Hacker" | ||
| dukeleto | moritz: but you are :) | 20:58 | |
|
20:58
Whiteknight joined
|
|||
| darbelo | dukeleto: Have you met him? How do you know he's real? | 20:58 | |
| japhb | dukeleto, welcome to plumage | ||
| moritz | dukeleto: not really; I committed some tests, coding standard fixes and doc fixes, but I never touched the "real iron" | ||
| dukeleto | japhb: shweet. i am assuming I need to set up some ssh keys on gitorious to start committing | 20:59 | |
|
20:59
joeri left
|
|||
| japhb | dukeleto, It's been a while since I set up my account, but I would assume the same thing. ;-) | 21:00 | |
| allison | cotto: that's a good question, since many of them were added for Rakudo | ||
| dukeleto | moritz: well, I still consider you a parrot hacker as well, but I understand. i have mostly only worked on the perl 6 test suite, not the real iron. I wrote the roots() builtin for rakudo, but that got refactored :) | ||
| allison reading scrollback | |||
| dukeleto | allison: where is the best place for new CallSignature tests? trunk or pcc_reapply ? | 21:01 | |
| allison | cotto: I'd say the chances of most languages using named, slurpy, optional, etc returns are pretty slim | ||
| dukeleto: t/pmc/callsignature.t | |||
| oh, pcc_reapply | |||
| since, there are more features implemented there than in trunk, and we want all of them tested | 21:02 | ||
| cotto_work | allison, they're mostly for internal (i.e. pct) use then? | ||
| dukeleto | allison: thanks | ||
| allison | cotto: well, they were added for Perl 6, back in the day | ||
| mikehh | I forgot to post the numbers - for pcc_rrapply branch - commits to date: | ||
| allison | cotto: but, if Rakudo isn't using them, maybe we can just rip them out | 21:03 | |
| mikehh | bacek (49). allison (32), whiteknight (15), mikehh (11), jkenan(9), tene (3), NotFound(2) and 1 each by dukeleto and moritz | ||
| allison | cotto: it would substantially simplify our calling conventions | ||
| pmichaud | pct and pge still want them | ||
| allison | cotto: (cleaner, faster, more maintainable code) | ||
| mikehh | I think I got everyone | ||
| dukeleto | mikehh: do you have a script for that? | ||
| allison | pmichaud: all of them, even on the returns? | 21:04 | |
| NotFound | mikehh: There is some prize for the most commiter? | ||
| mikehh | not really - just collected the commits to the branch and counted | ||
| pmichaud | allison: we certainly want :slurpy and :optional | ||
| allison | pmichaud: returns or calls? | 21:05 | |
| pmichaud | returns | ||
| jonathan | I'm think Rakudo may be using slurpy named returns. | ||
| pmichaud | sometimes we don't know how many values are being returned, we need to collect them all into a pmc | ||
| allison | pmichaud: fair enough (though I'm really curious what the code is doing) | ||
| dukeleto | moritz: your blog post perlgeek.de/blog-en/perl-6/parse-tree.html says "Mosse" instead of "Moose" | ||
| mikehh | just that there were a lot of commits to that branch since last week - not counting what allison did before | 21:06 | |
| chromatic | Macro line numbers work right now, per my tests. | 21:07 | |
| allison | pmichaud: once we merge calls and returns into one code set, we get all those options for free, so it's not really a big deal | ||
| darbelo | chromatic++ | ||
| pmichaud | allison: that's what I would hope for, yes. :) | 21:08 | |
| mikehh | NotFound: we need to find something for bacek++ | 21:09 | |
| NotFound | bacek++ | 21:10 | |
| chromatic | I'm pondering a branch to add STRINGNULL. | 21:11 | |
| dukeleto | chromatic++ # i loves me some correct line numbers | ||
| chromatic: go for it | |||
| darbelo | +1 | ||
| purl | 1 | ||
| dalek | TT #1016 closed by chromatic++: PIR line number wrong in stacktrace. | ||
| chromatic | We need it, no question. | ||
| The only question is "Yow, PCC refactoring!" | |||
| dalek | rrot: r41742 | chromatic++ | trunk (8 files): [IMCC] Improved IMCC line number tracking, especially in macros and other Fixes TT #1016. Note that macros have slightly more tests now, because they're the tricky part. POD and heredocs may need more testing too. |
21:12 | |
| mikehh | chromatic: I forgot to mention - what can we do about STRING_CONST - breaks all linelength restrictions? | ||
| chromatic | Beg and plead with stupid C compiler vendors to consider supporting C99 sometime this millennium. | 21:13 | |
| mikehh | I meant to ask in #ps but forgot | ||
| chromatic | The problem is (and you'll love the irony of synchronicity) that some C compilers don't understand the #line directive in macros. | 21:14 | |
| mikehh | its M$ mainly afaik | ||
| chromatic | By "understand" I mean "Know how to track line numbers in". | ||
| Clang had trouble there too, but there's a chance of getting that fixed. | |||
| japhb | chromatic: Does this fix tools/util/dump_pbc.pl 's problem listed in the BUGS section in the POD at the top? | ||
| s/this/the IMCC line numbering fixes/ | |||
| chromatic | japhb, I haven't checked. | ||
| If not, can you work up some test cases? | 21:15 | ||
| japhb | Would be nice if it did. | ||
| chromatic, once upon a time, I had some notes on examples, but I have since lost those notes. | |||
| I could try a before and after and see if I can catch it. | |||
| chromatic | That would be very helpful. | 21:16 | |
| I fixed a bug (well, removed a workaround) where the line number for certain opcodes in certain situations would be one line too low. | |||
| japhb | That sounds like it might match. It was causing the opcodes to appear just before the source line rather than just after. | 21:17 | |
| chromatic | Heredocs and macros are two big culprits. POD may have an effect too. | 21:18 | |
|
21:20
nopaste joined
|
|||
| japhb | OK, the "before" case with r41734 was still showing the old problem. Compiling r41742 now to test "after". | 21:21 | |
| allison | Tene: some logic fixes and an explanation of the reasoning in r41743 | 21:22 | |
| dalek | rrot: r41743 | allison++ | branches/pcc_reapply/src/call/args.c: [pcc] Some logic fixes to the returns handling. Even though args==returns and substitution, because the logic is reversed for return/result handling. So, fill_results needs to iterate over the array of results and the flags from the returns. (This is the reverse of arg/param handling, which iterates over the array of args and the flags of the params.) The fill_results function currently also has to track the flags of the results, to detect slurpy results. It would be better to mark "slurpy" on the CPointer, so we don't have to track two data structures to get the result information. |
||
| allison | Tene: that's all from me tonight, so I'll hand it off to you | 21:23 | |
| Coke | chromatic: holy. crap. | 21:24 | |
| chromatic | You saw me beat up a scarecrow? | 21:25 | |
| Coke | no, you closed an issue I opened on 08/16/06 | ||
| chromatic | I can revert if you want to reopen it.... | 21:27 | |
| masak | hm, PIR's local_branch/local_return are like BASIC's GOSUB/RETURN, right? except within the same sub. | 21:28 | |
| bacek_at_work | Good morning again | 21:30 | |
| japhb | chromatic, I don't think it's fully fixed. Comparing before and after, I see some numbering better, and some worse. | 21:32 | |
| chromatic | I'm not surprised. | 21:33 | |
| japhb | chromatic, I used ./parrot -o triangle.pbc examples/opengl/triangle.pir to generate a pbc file before and after, ran perl tools/util/dump_pbc.pl triangle.pbc > dump-triangle on both, and then did a diff --side-by-side. | ||
| Clearly better is the construction: .const 'Sub' foo = 'foo', which now seems exactly right. | 21:34 | ||
| One of the 'clearly worse' is: .local pmc foo; foo = new 'Integer'; foo = ... | 21:35 | ||
| chromatic | Which line in triangle.pir? | ||
| japhb | And .param isn't changed at all, I think. | ||
| Let's see. lines 37-40 | 21:36 | ||
| lines 54-56 | |||
|
21:36
bluescreen joined
|
|||
| japhb | that kind of stuff | 21:36 | |
| On the flip side, lines 59-62 were a big improvement | 21:37 | ||
| chromatic | 37-40 look correct for me. | ||
| japhb | Lemme nopaste what I see | ||
| nopaste? | |||
| purl | nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or poundperl.pastebin.com/ or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl | ||
| nopaste | "japhb" at 76.191.190.8 pasted "Lines 37-40 in examples/opengl/triangle.pir disassembly" (13 lines) at nopaste.snit.ch/18241 | 21:39 | |
| japhb | (Mind you, I'm coming back to this bug from a lot of months not looking at it, so I could have my neurons crossed.) | 21:40 | |
| chromatic | I'm comparing the dissasembly to the .pir file itself. | ||
| Everything I've looked at matches. | |||
| japhb | So you think the weave is fubar? | 21:41 | |
| chromatic | Oh. | ||
| Hm. | |||
| I wasn't even looking at the right thing. | 21:42 | ||
| japhb | :-) | ||
| chromatic | I was reading the annotations only and they all matched, for obvious reasons. | ||
|
21:42
Whiteknight joined
|
|||
| chromatic | How certain are you that the weave is correct? | 21:43 | |
| japhb | About 70%. | ||
| The entire weaver is only a few dozen lines, though, so it's not like a rat's nest. | 21:45 | ||
| chromatic | If you want to add some tests to t/compilers/imcc/syn/regressions.t (or start a new file), I'll do my best to make them pass. | 21:46 | |
| My best approach so far is to make deliberate syntax errors and check the line number there. | |||
| japhb | chromatic, I'll see what I can manage. I've got some $day_job stuff to do before I can throw serious tuits at it, though. | 21:47 | |
|
21:51
jsut_ joined
|
|||
| chromatic | Me too. | 21:52 | |
| cotto_work | clearwire-- | 22:06 | |
| dukeleto | can someone suggest a very simple test case that I could write for CallSignature ? | 22:12 | |
| cotto_work | "Will it float?" | 22:13 | |
| chromatic | Does it work? | 22:14 | |
| purl | i guess Does it work is it used? =-) | ||
| chromatic | Is there pie? | ||
| darbelo | Will it blened? | ||
| cotto_work | PMC smoke. Don't breathe this. | 22:15 | |
| dukeleto | wow, i haven't gotten that many snarky answers in a row in while :) | 22:16 | |
| chromatic | We know you're not Chuck Norris. Drop the fake beard. | ||
| japhb | Yes, but is he Bruce Schneier? | 22:17 | |
| dukeleto | chromatic: what is the simplest possible thing that I can test CallSignature for, from PIR? | ||
| chromatic: other than instantiation | 22:18 | ||
| cotto_work | maybe call a sub in raw mode and test that the CallSignature has what you expect? | ||
| chromatic | Getting and setting short_sig. | ||
| Getting and setting type_tuple. | |||
| There's not much else in the PMC. | |||
| cotto_work has the rest of it. | 22:19 | ||
|
22:19
kid51 joined
|
|||
| dukeleto | chromatic: ok, that give me some direction | 22:19 | |
| s/give/gives/ | 22:20 | ||
| allison | dukeleto: also integer keyed access to positional arguments and string keyed access to named arguments | 22:21 | |
| dukeleto | allison: gotcha | ||
| cotto_work | btw, what's the proper name for raw mode? | ||
| :call_sig? | |||
| GeJ | Good morning everyone | 22:22 | |
| everyone | Good morning GeJ | 22:23 | |
| allison | cotto: not defined yet (and won't be implemented in this branch), but something like :call_sig | ||
| cotto: it would be nice to have a name that's more immediately obvious what it's doing | |||
| cotto: but haven't thought of one yet | 22:24 | ||
| cotto_work | Thanks. I was curious if there was some code I could look at now. | ||
| allison | cotto: (admittedly I haven't spent more than 5 minutes thinking about the name yet) | ||
| cotto_work | we can just ask TimToady when the time comes | 22:25 | |
| allison | cotto: it's something along the lines of "let me look at the guts" | 22:26 | |
| chromatic | :eviscerate | ||
| :abattoir | 22:27 | ||
| :tripe | |||
| :divine | |||
| NotFound | :anything | ||
| chromatic | :meteorology | ||
| cotto_work | :raaw | ||
| chromatic | (subtle) | ||
| :velociraptor | |||
| allison | chromatic: eviscerate would be a good replacement for :flat :) | 22:28 | |
| chromatic stifles the question "How offensive, on a scale of one to ten?" | |||
| cotto_work | I'd like to see some more colorful language in pir. | ||
| NotFound | :asyouwish | ||
| allison | chromatic: so far, I'm favoring 'dissect' | ||
| (for :flat) | 22:29 | ||
| NotFound | :catchfire | ||
| chromatic | You could go the Thomas Friedman route and mistake :flat for :hasuniformsizedshippingcontainers, but that's more of an :autounbox (very subtle). | 22:30 | |
| allison | :) | ||
| chromatic | Maybe not that subtle; I suspect most people in here did not fail geometry. | 22:31 | |
| cotto_work | We could go the surrealist route with :giraffe | 22:32 | |
| allison | :escher | ||
| NotFound | :bycommitee | 22:33 | |
| chromatic | :derrada | ||
| NotFound | :finnegans | ||
| dukeleto | :iwanttoknowhowparrotsausageismade | 22:34 | |
| NotFound | :xkcd | ||
| dukeleto gets hungry thinking about Parrot sausage. | |||
| bacek_at_work | :twofingers | ||
| NotFound | What about just :pcc ? | 22:35 | |
| jonathan | allison: Does the branch still have the nameds going into a hash in the call signature PMC? | ||
| Or more useful for me to know: is fixing that a post-branch task, or an "in this branch" task? | 22:36 | ||
| cotto_work | NotFound, it's basically bypassing most of pcc. | ||
| allison | nameds go into a hash | ||
| jonathan | It seems like it'd be easier to get right in the beginning, but if it's going to delay the branch, I can deal with that. | ||
| allison | what's the fix? | ||
| purl | i think the fix is " return @_ if $self->{PERL_SRC};" as the second line of MM_Win32::arch_check - but I'll mail a patch unless I forget | ||
| dukeleto | purl, forget the fix | 22:37 | |
| purl | dukeleto: I forgot fix | ||
| NotFound | cotto_work: Is just :makeyourownpcc abreviated ;) | ||
| jonathan | allison: nameds going into a hash don't allow custom argument processors that can do something useful/interesting with multiple named arguments with the same name. | ||
| allison | jonathan: that is, I don't have any plans to move named args out of a hash | ||
| jonathan | allison: OK. What are the semantics of a call with multiple arguments of the same name? | 22:38 | |
| allison | well, you'll have the option of passing in your own call signature object and pulling it out on the other side | ||
| as far as parrot arg processing is concerned, that's an error | |||
| dukeleto | i am getting "FixedIntegerArray: index out of bounds!" all over the place on the pcc_reapply branch, is that normal? | ||
| jonathan | When is it an error though? | ||
| allison | dukeleto: that's from return handling, which is in active development | ||
| jonathan | I mean, at the moment that's a binding time error, afaik, not a call signature construction time error. | 22:39 | |
| (e.g. callee side, not caller side) | |||
| allison | jonathan: it's an error right from the start | ||
| jonathan | It seems the change would make it caller side? | ||
| Today, or in the branch? | |||
| allison | jonathan: what change? | ||
| purl | change is, like, very minimal as you can see in the js, so what you suggests seems like a good alternative | ||
| jonathan | allison: IIRC, today it's not an error until the callee does get_args. | 22:40 | |
| allison: Anyway, what's really behind this is that if all the nameds go into a hash rather than a list of "name, value, name, value, ..." like trunk has it today, then Parrot's CallSignature gets rather less useful for Rakudo. | 22:41 | ||
| dukeleto | allison: i get that error when loading test_more.pir, so that is kind of a blocker | ||
| jonathan | So not only will we have to process the CallSignature ourselves, but also we'll have to build our own one. | ||
| allison | jonathan: that's because Parrot currently doesn't do any processing at all until get_params | ||
| it just holds on to the opcode pointer or varargs list until the parameter setting | 22:42 | ||
| nopaste | "dukeleto" at 70.102.219.22 pasted "Simple program complains about "FixedIntegerArray: index out of bounds!" on pcc_reapply" (11 lines) at nopaste.snit.ch/18242 | ||
| jonathan | allison: Yes, indeed. | ||
| allison | dukeleto: yes, it's a known failure in work in progress, and we checked it in so we can work on it together | ||
| dukeleto | allison: ok, just trying to get up to speed | 22:43 | |
| jonathan | allison: I'm fine with that changing, for the most part. | ||
| allison | jonathan: as far as I can tell, you're planning on doing all your own argument processing anyway | ||
| jonathan | allison: My concern is that building a hash rather than a "name, value, name, value" style list will cause some pain. | ||
| allison | jonathan: you realize, of course that I only put them in a hash in the first place because that's what Rakudo wanted | 22:44 | |
| jonathan | allison: Yes, but I was expecting to just be able to process the default Parrot CallSignature. | ||
| allison: I'm kinda confused. Yes, a capture *does* (I agree) expose a hash interface to the parameters. | 22:45 | ||
| However, it's also spec'd as preserving the original call information. | |||
| allison | jonathan: you can't have it both ways | ||
| either you have quick access to parameters by name | 22:46 | ||
| or you have a strict preservation of original order | |||
| jonathan | Yeah, true. | ||
| dukeleto | does anybody have any ideas about how to get test_more.pir to work on pcc_reapply? It is hard to write tests without it ... | ||
| jonathan | Trouble is, Perl 6 cares about knowing the original order. | ||
| Which is kinda irritating. | 22:47 | ||
| (It also cares about binding in signature, not calling, order.) | |||
| chromatic rejects the default assumption that hashes are quick | |||
| allison | well, talk to Patrick about it and decide what's most important | ||
| dalek | tracwiki: v22 | dukeleto++ | CallingConventionsOverview | ||
| tracwiki: trac.parrot.org/parrot/wiki/Callin...ction=diff | |||
| allison | then get back to me | ||
| shorten | dalek's url is at xrl.us/bfqrzj | ||
| allison | and, it may make the most sense for you to just do your own call signatures for a while until the ideas mature | ||
| if something good comes out of it, we can always work it into core parrot later | 22:48 | ||
| jonathan | allison: Will there be a way to do :call_sig on the caller side too? | ||
| Tene | dukeleto: I can look at it when I go home in about an hour. | ||
| jonathan | Or whatever the name is... | ||
| allison | jonathan: yes, it works on both sides | ||
| jonathan | allison: OK, that makes doing our own thing more workable. | ||
| allison | just foo(myarg :callsig) | ||
| or whatever | |||
| jonathan | allison: OK, I can likely work with that somewhat. | ||
| allison | jonathan: that's the goal | 22:49 | |
| (making doing your own thing workable) | |||
| jonathan | I do worry that the default being a hash may be trick for language interop though. | ||
| *tricky | |||
| allison | jonathan: very few languages use named parameters anyway | ||
| jonathan | Generally, I'd expect the restrictions on arguments to be something the callee cares about, not the caller. | ||
| allison | and the ones that do are pretty basic about it | ||
| jonathan: we don't guarantee that we'll always use a hash for storage internally | |||
| jonathan | Perl 6 and pretty basic rarely go in the same sentence. ;-) | 22:50 | |
| allison: OK, that makes me feel a tad easier too, if it's not API that we do it that way. | |||
| allison | jonathan: we only guarantee that we'll provide a hash interface on the call sig | ||
| jonathan | OK. | ||
| allison | (and ask that you do the same on your custom call sigs for anything that might be exposed outside Perl 6) | ||
| Tene | allison: curious... if we can get pcc merged, how much longer before you get :vtable('invoke') working in PIR classes? | ||
| allison | in PIR subclasses? | 22:51 | |
| Tene | I remember you saying that PCC was a requirement before you could start working on that. | ||
| in any PIR classes. | |||
| jonathan | allison: OK. I think if :call_sig can land not too long after the branch merge (I can likely help get that in place, or get it added myself, since in theory it's simple) then I think I'm set. :-) | ||
| allison | it's not on my list, but IIRC, the big obstacle was providing access to all the right arguments from within the user defined code | 22:52 | |
| Tene: so it should be pretty straightforward | |||
| Tene | Okay. | ||
| jonathan | I do feel that hash as the default isn't going to be the right way to go. But since that's not API, and I really, really don't want to hold this branch up by suggesting more changes now, I'm happy to settle with the fact that I'll be able to build my own call signature. | 22:53 | |
| And/or that it may change in the future. | |||
| Tene | allison: have you looked at the problem in build_sig_returns when specifying named returns in pcc branch? | ||
| allison | Tene: not yet, but I'm pretty sure there's no code there to handle named returns | 22:54 | |
| dukeleto | Tene: that would be awesome. as long as I can write tests, I can be useful on pcc_reapply. If not, I am not so sure. | ||
| allison | Tene: (at the time I wrote that code I was thinking "Hey, it'd be interesting to have named and slurpy returns eventually", instead of "we have to support this because trunk does") | 22:55 | |
| Tene: I'm off for the evening (up for classes in 7 hours) | |||
| Tene | goodnight, allison. | ||
| allison | Tene: if you check in any changes you make, I'll start up where you left off tomorrow | ||
| Tene | allison: confirm, fill-returns is currently in pcc branch, or no? | ||
| allison | Tene: yes, it's checked in, and I've checked in further fixes | 22:56 | |
| Tene | Okay, great. exactly what I wanted. | ||
|
22:56
TiMBuS joined
|
|||
| allison | Tene: if you want to give dukeleto some relief, you could make the choice between the old and new code an ifdef inside fill_returns_from_op | 22:57 | |
| Tene | Oh, true. I might try that. | ||
| allison | (i.e. it either does all the old code (which was pretty basic), or it calls fill_results | ||
| chromatic | Is that a temporary workaround? | 22:58 | |
|
22:58
tetragon joined
|
|||
| dukeleto | 'make coretest' currently goes into an infinite loop in t/pmc/namespace-old.t for me. has anybody else seen this? | 22:58 | |
| on pcc_reapply, that is | |||
| allison | chromatic: yes, just for a day or two so dukeleto can write tests while we finish the last feature | ||
| Tene | chromatic: Yes. The new code still doesn't work in some pretty basic cases. | ||
| chromatic | Thanks for confirming. | 23:00 | |
|
23:08
cotto joined
|
|||
| cotto_work | wb, cotto | 23:08 | |
|
23:08
jsut joined
|
|||
| cotto_work | .o0(I really need to find a better ISP.) | 23:09 | |
| dukeleto | jsut: howdy | 23:11 | |
| Whiteknight missed a lot of good chat. Backlogging | 23:14 | ||
| Tene: :vtable('invoke') should be much easier after this | |||
| I have a few ideas, but want to wait for the dust to settle first | |||
| Tene | rather. | ||
| dukeleto | Whiteknight: yeah, busy day | 23:15 | |
| Whiteknight | the biggest issue from the PIR perspective is getting access to the "self" variable | 23:16 | |
| Of course, there is a semantic issue about what "self" should refer to inside VTABLE_invoke | |||
| Because "$P0()" has the same invocant as "$P0.'method'()", but a different Sub | 23:17 | ||
|
23:17
coke joined
|
|||
| coke | (named parameters) tcl's are "positional with names"... but I pretty much have to hand roll all my argument processing because parrot won't let me create my own error message if the args are wrong. | 23:18 | |
| (we even have a slurpy mode.) | |||
| jonathan | Whiteknight: I did an epic hack to make invoke overridable in Rakudo, while waiting for the Real Answer. :-) | 23:21 | |
| dalek | kudo: 41bc84f | jonathan++ | (6 files): Extensive re-working of the way we generate signatures in actions.pm. Now we build an object representing the signature at compile time, and then use a method on it to do the code generation. This neatens up actions.pm a little, but also means it'll be easier to change signature building later (since only one method will need to change, in theory). |
23:22 | |
| kudo: d39a7de | jonathan++ | src/parser/ (2 files): Fix a couple of readtype bugs, which deals with many of the failures from the signature changes. |
|||
| kudo: 0f4d0cd | jonathan++ | (4 files): Couple of other extra fixes to get us handling the spectests again. |
|||
| shorten | dalek's url is at xrl.us/bfqr45 | ||
| shorten | dalek's url is at xrl.us/bfqr47 | ||
| dalek's url is at xrl.us/bfqr49 | |||
| Whiteknight | jonathan: awesome. I'm sure it's going to be an epic hack to make it work right in Parrot too | 23:23 | |
| chromatic | How's Rakudo startup with that? | 23:26 | |
|
23:27
TonyC joined
|
|||
| jonathan | chromatic: This is the change that will let me more easily do the change that should make startup better. :-) | 23:28 | |
| chromatic: In this, I isolated signature code generation in one place. | 23:29 | ||
|
23:29
Austin joined
|
|||
| jonathan | chromatic: So now the next step should be easier. | 23:29 | |
|
23:30
Ruiloff-on-off joined
|
|||
| chromatic | Very nice. | 23:31 | |
| Austin | PIR question: Is there a difference between calling 7 find_method $S0 and just using the 7 object.$S0(args...) syntax? | ||
| Tene | Austin: I'm really starting to like you use of color to denote quotes on IRC. | ||
| Austin | :) | ||
| Thanks. | 23:32 | ||
| Tene | :P | ||
| cotto_work | You go too far, sir. | 23:33 | |
| Austin | Reverse doesn't show up for me. :| Probably for the best. | ||
| dalek | kudo: 8d63378 | jonathan++ | (2 files): Stub in P6LowLevelSig PMC. |
||
| shorten | dalek's url is at xrl.us/bfqr6x | ||
| GeJ | allison: Just so you know : `make coretest` in latest pcc_reapply hangs indefinitely in t/compilers/imcc/syn/regressions.t | 23:34 | |
| cotto_work | GeJ, it's known goofy atm | 23:35 | |
| GeJ | Ah, okay. Sorry for the noise then. | 23:36 | |
| cotto_work | GeJ, no worries. | ||
| Austin | What word is the opposite of :flat in an arg-expression? | 23:37 | |
| That is, if I have 7 sub foo(*@args) , the args parameter is slurpy. But the array itself is ... "slurped", "collected", ...? | 23:38 | ||
| darbelo | the slurpee? | 23:39 | |
| chromatic | Splattened | ||
| Austin | darbelo: I'm looking for a state, not a pronomial. | ||
| darbelo | Oh, my bad. Slurpificated, then. | 23:40 | |
| Austin | So I would have 7 sub foo_splattened(@args) as the alternative target? | 23:41 | |
| There's a certain symmetry there, I guess: flattened and splattened. | |||
| dukeleto | GeJ: i emailed parrot-dev about pcc_reapply looping on "make coretest" | 23:54 | |
|
23:55
patspam joined
|
|||