| Time |
S |
Nick |
Message |
| 00:00 |
|
jonathan |
Here we'd only ever invoke trait_auxiliary:is one time. |
| 00:00 |
|
pmichaud |
just one time? |
| 00:00 |
|
jonathan |
Right. |
| 00:00 |
|
pmichaud |
isn't it once per activation? |
| 00:00 |
|
jonathan |
See discussion I had on #perl6 yesterday with TimToady for more. :-) |
| 00:01 |
|
jonathan |
But it seems that since traits are a compile time thing, they actually more act upon the thingy at compile time. |
| 00:01 |
|
pmichaud |
my eyes glazed over a bit first time I looked at it. |
| 00:01 |
|
jonathan |
At the discussion on #perl6? |
| 00:01 |
|
pmichaud |
yes. |
| 00:01 |
|
pmichaud |
I can look again. |
| 00:01 |
|
jonathan |
I'm still trying to work out what it really means. |
| 00:02 |
|
pmichaud |
I think (naively) that we compile the trait once at compile time but apply it on every @x that gets created. |
| 00:02 |
|
pmichaud |
in the Parrot sense I think of it like a PMC property. |
| 00:02 |
|
jonathan |
What do you mean by "compile the trait"? |
| 00:03 |
|
pmichaud |
in this case, the fact that we have a certain type of dimension |
| 00:03 |
|
pmichaud |
but I _really_ need to read the discussion and traits a bit more |
| 00:03 |
|
jonathan |
Or maybe the real question here is, what do we pass to trait_auxiliary:is |
| 00:03 |
|
pmichaud |
because I know very little of what I'm saying here :-) |
| 00:03 |
|
jonathan |
Obviously, one parameter is the "dim" |
| 00:03 |
|
pmichaud |
...what do we pass, and when do we pass it? |
| 00:04 |
|
jonathan |
But the other? On the one hand, it could be the PAST::Var node, which can then tweak the viviself to actually contain the code to set the dimensions. |
| 00:04 |
|
pmichaud |
(I'm glad we're talking about traits here and not food :-) |
| 00:04 |
|
jonathan |
ewwww... |
| 00:04 |
|
purl |
ewwww is, like, tp's middle name |
| 00:04 |
|
pmichaud |
I'm actually planning to do this for parameters. |
| 00:04 |
|
* jonathan |
looks at his chips and salsa with less hunger now |
| 00:04 |
|
pmichaud |
i.e., that trait applications are part of the PAST::Var node. |
| 00:04 |
|
jonathan |
OK. I think that is the Right Thing. |
| 00:04 |
|
pmichaud |
that's why viviself is created the way it is :-) |
| 00:04 |
|
jonathan |
Yes. We dispatch to trait_auxiliary:is during compile. |
| 00:05 |
|
jonathan |
OK, discussing this is starting to make it feel less scary and more workable. :-) |
| 00:05 |
|
pmichaud |
in particular, the setproperty opcode is going to be set up so that it returns its first argument in the PAST tree |
| 00:05 |
|
pmichaud |
i.e., it's like getting a :scope('register') node for free |
| 00:06 |
|
pmichaud |
so I can do |
| 00:06 |
|
pmichaud |
PAST::Op.new(:pirop('setproperty'), PAST::Var.new( ... ) ) |
| 00:06 |
|
pmichaud |
and the "result" of that is the PAST::Var node with the property set on it. |
| 00:06 |
|
jonathan |
Ah. |
| 00:07 |
|
jonathan |
I'm not sure if that works unless trait_auxiliary:is returns something? |
| 00:07 |
|
pmichaud |
same for other "set" opcodes that don't normally return a value |
| 00:07 |
|
pmichaud |
we'll see how it goes :-) |
| 00:07 |
|
jonathan |
I mean, I'm thinking here we want to write something like |
| 00:07 |
|
|
kj joined #parrot |
| 00:08 |
|
jonathan |
role rw { multi sub 'trait_auxiliary:is'(rw $, PAST::Var $var) { ...something involving $var.viviself... } |
| 00:09 |
|
jonathan |
} |
| 00:09 |
|
jonathan |
So the dispatch to trait_auxiliary gets the Var node and is able to tweak it somehow to set up the rw semantics. |
| 00:09 |
|
|
AndyA joined #parrot |
| 00:10 |
|
pmichaud |
I think we can do that. |
| 00:10 |
|
|
bacek joined #parrot |
| 00:10 |
|
* kj |
has dates confused and missed #ps |
| 00:10 |
|
pmichaud |
or something like that. |
| 00:10 |
|
jonathan |
OK. |
| 00:10 |
|
jonathan |
I think that's what needs to happen. |
| 00:10 |
|
pmichaud |
I'd like to leave that for a medium-term goal. |
| 00:10 |
|
pmichaud |
(i.e., as part of your grant) |
| 00:10 |
|
pmichaud |
short term I'd like to get some of the other class/method refactors in place. |
| 00:11 |
|
* jonathan |
looks terrified |
| 00:11 |
|
jonathan |
Sure |
| 00:11 |
|
pmichaud |
and clean up parameter handling a bit. it may be that the traits falls out naturally from that, if so we can do it then. |
| 00:11 |
|
pmichaud |
this is all starting to look very good. |
| 00:11 |
|
jonathan |
Sure, if we can do it like that, great. If not, let's at least try and do something that doesn't make it harder to do that later. |
| 00:11 |
|
pmichaud |
absolutely |
| 00:11 |
|
pmichaud |
I'm sure the refactors will all make this much easier |
| 00:11 |
|
pmichaud |
that's been the general case |
| 00:12 |
|
jonathan |
Sure. |
| 00:12 |
|
pmichaud |
oh, for MAIN -- I'm thinking maybe we could do better by introducing a !MAIN subroutine |
| 00:12 |
|
pmichaud |
? |
| 00:12 |
|
jonathan |
But sometimes you have to do it the Other Way first to know the refactor. |
| 00:12 |
|
pmichaud |
rather than building it into the AST |
| 00:12 |
|
pmichaud |
i.e., the AST simply makes a call to !MAIN (passing args array) and it does the rest? |
| 00:12 |
|
jonathan |
That may work. |
| 00:13 |
|
jonathan |
If smaller AST is a goal. |
| 00:13 |
|
pmichaud |
well, that means less generated code, mainly |
| 00:13 |
|
jonathan |
Sure |
| 00:14 |
|
pmichaud |
and simplifies actions.pm, which is a goal. |
| 00:14 |
|
jonathan |
Yes, it's compilation time is creeping up... |
| 00:14 |
|
pmichaud |
well, not just that, but also trying to keep it somewhat understandable. |
| 00:14 |
|
pmichaud |
anyway, I have to go |
| 00:15 |
|
jonathan |
OK, sure, cu |
| 00:15 |
|
pmichaud |
see ya soon |
| 00:19 |
|
nopaste |
"japhb" at 76.191.190.8 pasted "Demo of Parrot and Rakudo problems, from crashers to mere annoyances" (132 lines) at http://nopaste.snit.ch/14542 |
| 00:23 |
|
dalek |
r32568 | japhb++ | trunk: |
| 00:23 |
|
dalek |
: [OpenGL] Perl 6 examples fixes |
| 00:23 |
|
dalek |
: * Don't exit() from a callback. |
| 00:23 |
|
dalek |
: * shapes.p6: |
| 00:23 |
|
dalek |
: + Get rid of $now variable |
| 00:23 |
|
dalek |
: + Add comment about += failure |
| 00:23 |
|
dalek |
: + Enable keyboard callback |
| 00:23 |
|
dalek |
: + Fix braino in FPS display |
| 00:23 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32568 |
| 00:30 |
|
jonathan |
"Everything can go wrong, and usually does |
| 00:31 |
|
jonathan |
What a life outlook! ;-) |
| 00:33 |
|
jonathan |
Thanks for preparing that file, though. |
| 00:34 |
|
* jonathan |
hopes we can get the bugs ironed out in not too long |
| 00:37 |
|
chromatic |
That return bug bothers me. |
| 00:42 |
|
Whiteknight |
what return bug? |
| 00:42 |
|
jonathan |
chromatic: The exit one isn't too wonderful either. |
| 00:43 |
|
jonathan |
Whiteknight: in the code japhb posted |
| 00:49 |
|
|
gmansi joined #parrot |
| 00:55 |
|
|
bacek joined #parrot |
| 01:08 |
|
|
Lorn joined #parrot |
| 01:09 |
|
|
hachi left #parrot |
| 01:19 |
|
|
MariachiElf joined #parrot |
| 01:21 |
|
japhb |
jonathan, chromatic: thanks for taking a look at that for me. |
| 01:41 |
|
|
jimmy joined #parrot |
| 02:08 |
|
|
rhr joined #parrot |
| 02:16 |
|
rblackwe |
Hey any parrot gurus that know anything about http://www.osgi.org that could help me with me efforts to get parrot on http://buglabs.net if so please let me know at robert robertblackwell.com. |
| 02:17 |
|
|
davidfetter joined #parrot |
| 03:06 |
|
|
Andy joined #parrot |
| 03:16 |
|
|
stockwellb joined #parrot |
| 03:21 |
|
stockwellb |
Parrot test question. pir_output_is? Why the output to file? |
| 03:22 |
|
stockwellb |
One more. I discoverd prove can run the perl tests, is there a cli tool to run the PIR tests? |
| 03:58 |
|
|
Psyche^ joined #parrot |
| 04:02 |
|
|
elmex_ joined #parrot |
| 04:05 |
|
stockwellb |
Anyone now how to run a single PIR test? |
| 04:09 |
|
|
Ademan joined #parrot |
| 04:25 |
|
jimmy |
is pirc implemented by c, and other by pirc self ? |
| 04:27 |
|
dalek |
bruce.stockwellgmail.com | Parrot: |
| 04:27 |
|
dalek |
link: http://www.perlfoundation.org/[…]/index.cgi?parrot |
| 04:29 |
|
dalek |
bruce.stockwellgmail.com | Parrot: |
| 04:29 |
|
dalek |
link: http://www.perlfoundation.org/[…]/index.cgi?parrot |
| 04:33 |
|
dalek |
bruce.stockwellgmail.com | Starting at the bottom: |
| 04:33 |
|
dalek |
link: http://www.perlfoundation.org/[…]ing_at_the_bottom |
| 05:14 |
|
cotto |
stockwellb, the *_output_* files are useful when testing an aspect of parrot that isn't easy to make part of a pure PIR test suite, i.e. something that might segfault. |
| 05:16 |
|
cotto |
Most tests can be rewritten as pure PIR tests, although there are some exceptions. |
| 05:18 |
|
cotto |
pure PIR tests can be run directly with the parrot executable or with prove. |
| 05:19 |
|
stockwellb |
I'm getting errors when I run PIR tests with prove |
| 05:19 |
|
stockwellb |
Perl tests work file with prove |
| 05:20 |
|
cotto |
example? |
| 05:20 |
|
stockwellb |
hold on. |
| 05:20 |
|
cotto |
nopaste? |
| 05:20 |
|
clunker3 |
http://pasta.test-smoke.org/ or http://paste.husk.org/ or http://nopaste.snit.ch:8001/ or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ |
| 05:20 |
|
purl |
nopaste is, like, at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ |
| 05:20 |
|
|
rhr joined #parrot |
| 05:21 |
|
stockwellb |
No plan found in TAP output |
| 05:22 |
|
stockwellb |
parrot runs the test just fine. |
| 05:23 |
|
cotto |
can you nopaste what you ran and its output? |
| 05:23 |
|
stockwellb |
yep |
| 05:24 |
|
nopaste |
"stockwellb" at 70.160.222.145 pasted "prove pir error" (14 lines) at http://nopaste.snit.ch/14544 |
| 05:26 |
|
cotto |
you need to run prove from the root of the build dir (or have a parrot in your $PATH). |
| 05:28 |
|
stockwellb |
ah yes prove works when run from the build root. Thank you |
| 05:28 |
|
cotto |
np |
| 05:29 |
|
stockwellb |
cotto, do you know a lot about the test suite? |
| 05:29 |
|
stockwellb |
do all of the Perl tests need to be converted to PIR tests? |
| 05:29 |
|
cotto |
That depends on who's asking. ;) I know more than nothing. |
| 05:30 |
|
cotto |
They don't. It speeds up the test suite if they are and it's a good way to learn your way around parrot, but it's not necessary. |
| 05:31 |
|
stockwellb |
I'm new to parrot and perl. I really want to learn more PIR, I thought I'd start by converting some tests. |
| 05:32 |
|
stockwellb |
So that won't really help the project, but it should help me. |
| 05:33 |
|
cotto |
Go for it. I'd be glad to review and commit any patches of that nature. |
| 05:34 |
|
cotto |
A faster test suite is always welcome. |
| 05:34 |
|
stockwellb |
I've never done any collaborative development before, so I'll definately have to lean on and learn from you vets. |
| 05:36 |
|
cotto |
docs/* is your friend |
| 05:37 |
|
cotto |
There's a surprising amount of useful information there. |
| 05:38 |
|
stockwellb |
there certainly is. |
| 05:57 |
|
dalek |
bruce.stockwellgmail.com | Starting at the bottom: |
| 05:57 |
|
dalek |
link: http://www.perlfoundation.org/[…]ing_at_the_bottom |
| 06:05 |
|
stockwellb |
Sleepy time... |
| 06:05 |
|
dalek |
bruce.stockwellgmail.com | Starting at the bottom: |
| 06:05 |
|
dalek |
link: http://www.perlfoundation.org/[…]ing_at_the_bottom |
| 06:20 |
|
|
davidfetter joined #parrot |
| 06:33 |
|
jimmy |
is particle here now? |
| 06:37 |
|
davidfetter |
particle: idle for 9 hours, 21 minutes, 18 seconds (on since Tue, Nov 11, 2008 2:31:52 PM) |
| 06:40 |
|
jimmy |
i just want this patch can be aplied in other place.http://svn.perl.org/viewvc/par[…]r1=32388&r2=32488 |
| 06:42 |
|
jimmy |
unification of usage. |
| 06:54 |
|
|
masak joined #parrot |
| 06:59 |
|
dalek |
r32569 | allison++ | calling_conventions: |
| 06:59 |
|
dalek |
: [calling_conventions] Standardize parameter processing so the invocant is |
| 06:59 |
|
dalek |
: handled while iterating through the paramters, rather than being a special |
| 06:59 |
|
dalek |
: case. |
| 06:59 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32569 |
| 07:04 |
|
MariachiElf |
How do you recover from a failed test? |
| 07:05 |
|
MariachiElf |
t/stm/runtime...............................NOK 4/5# Failed test 'queue adapted for the library' |
| 07:06 |
|
masak |
jonathan++ # $?PACKAGE |
| 07:06 |
|
moritz |
masak: what do you mean by "recover from"? the test harness doesn't die after a failed test |
| 07:07 |
|
MariachiElf |
moritz: Mine did |
| 07:07 |
|
masak |
moritz: sorry, need more context. where are we? |
| 07:07 |
|
MariachiElf |
Failed 1/394 test programs. 1/11452 subtests failed. |
| 07:07 |
|
MariachiElf |
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x1' |
| 07:07 |
|
MariachiElf |
Stop. |
| 07:07 |
|
MariachiElf |
I'm on Vista |
| 07:07 |
|
moritz |
uhm, that's weird. |
| 07:07 |
|
MariachiElf |
Just did a fresh SVN checkout a few moments ago |
| 07:07 |
|
masak |
moritz: did I say 'recover from'? where? |
| 07:08 |
|
moritz |
masak: sorry, I meant MariachiElf :/ |
| 07:08 |
|
masak |
moritz: that explains it. |
| 07:08 |
|
purl |
Damn right it does. |
| 07:08 |
|
moritz |
masak: my usual ma<tab> mistake :/ |
| 07:08 |
|
masak |
moritz: don't type with your eyes closed! |
| 07:09 |
|
MariachiElf |
nmake went fine |
| 07:09 |
|
MariachiElf |
nmake html seems to have gone well too |
| 07:10 |
|
masak |
chromatic: re refcount, continuations/exceptions: sounds reasonable. anything a lower-rung coder like me can do to eliminate any of those errors? I get them often enough to feel antipathy against them. |
| 07:10 |
|
moritz |
ah well, 'make test' returns a non-zero exit value if the test failed |
| 07:10 |
|
moritz |
MariachiElf: what else do you want 'make' to do? |
| 07:11 |
|
MariachiElf |
moritz: I'm assuming there were more tests to run |
| 07:11 |
|
moritz |
MariachiElf: don't assume. It already printed the summary (Failed 1/394 test programs. 1/11452 subtests failed.), so it's done now. |
| 07:12 |
|
MariachiElf |
Ohhhhh |
| 07:13 |
|
MariachiElf |
http://poundperl.pastebin.com/m9adfffb |
| 07:13 |
|
MariachiElf |
There's the full output of the stop |
| 07:14 |
|
MariachiElf |
The output was just scary and not what I'm used to |
| 07:14 |
|
MariachiElf |
my apologies |
| 07:14 |
|
moritz |
it happend to be the last test that failed, no worries ;) |
| 07:15 |
|
* MariachiElf |
nods. |
| 07:33 |
|
|
uniejo joined #parrot |
| 07:33 |
|
|
samlh joined #parrot |
| 07:34 |
|
masak |
rakudo: my @a = (1,2,3); @a.[2] = 5; say @a.perl |
| 07:34 |
|
polyglotbot |
OUTPUT[[1, 2, 5]] |
| 07:34 |
|
masak |
S09 says this should be a compile-time error. |
| 07:34 |
|
* masak |
reports |
| 07:35 |
|
chromatic |
masak, mostly we just have to understand all of the places we refer to an existing context and make sure that we update its reference count appropriately. |
| 07:35 |
|
moritz |
wtbh? |
| 07:35 |
|
chromatic |
With regard to the double-free errors. |
| 07:36 |
|
masak |
chromatic: aye. |
| 07:36 |
|
moritz |
masak: it says my @a.[5] should be an error |
| 07:36 |
|
moritz |
masak: you didn't confuse that, I hope? |
| 07:36 |
|
masak |
moritz: oh, I did. |
| 07:36 |
|
masak |
moritz: thx. |
| 07:36 |
|
* masak |
doesn't report |
| 07:37 |
|
* moritz |
was very disturbed, for a second ;) |
| 07:37 |
|
masak |
ah. right now my @a[5] doesn't work either. |
| 07:37 |
|
masak |
moritz: sorry ;) |
| 07:37 |
|
moritz |
np :-) |
| 07:38 |
|
dalek |
r32570 | allison++ | calling_conventions: |
| 07:38 |
|
dalek |
: [calling_conventions] Bringing the calling_conventions branch up-to-date with trunk r32569. |
| 07:38 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32570 |
| 07:53 |
|
|
mj41 joined #parrot |
| 08:07 |
|
|
Zaba joined #parrot |
| 08:18 |
|
|
allison joined #parrot |
| 09:06 |
|
|
iblechbot joined #parrot |
| 09:10 |
|
|
tomyan joined #parrot |
| 09:12 |
|
|
idemal joined #parrot |
| 09:16 |
|
|
cosimo joined #parrot |
| 09:53 |
|
|
Zaba joined #parrot |
| 10:16 |
|
|
Zaba joined #parrot |
| 10:30 |
|
|
masak joined #parrot |
| 10:31 |
|
masak |
szabgab: http://weblog.infoworld.com/fa[…]l_6_isnt_vap.html |
| 10:37 |
|
szabgab |
yeah, I read that already a few days ago, |
| 10:38 |
|
szabgab |
lucky that at least you ppl don't get discouraged by such things |
| 10:39 |
|
szabgab |
btw is there any plan when can one install parrot ? |
| 10:39 |
|
|
ruoso joined #parrot |
| 10:39 |
|
szabgab |
as in not running it from svn workspace |
| 10:39 |
|
|
konstantin joined #parrot |
| 10:39 |
|
masak |
szabgab: not discouraged, but sad to see such outside opinions. |
| 10:40 |
|
masak |
szabgab: you can install parrot already. |
| 10:40 |
|
masak |
szabgab: it's on CPAN. |
| 10:40 |
|
moritz |
szabgab: reini urban was working on a proper 'make install' |
| 10:40 |
|
szabgab |
yeah, but I thought it keeps saying, you better not run make install |
| 10:40 |
|
moritz |
szabgab: there's a branch for it, but sadly his work as stalled atm |
| 10:41 |
|
masak |
szabgab: ah. |
| 10:41 |
|
szabgab |
ah, so the recomenndation for people who want stable (realatively) is to download from CPAN, compile it and run it from there> |
| 10:42 |
|
szabgab |
? |
| 10:42 |
|
masak |
I suppose. |
| 10:42 |
|
masak |
since I don't have those requirements myself, I don't really know, though. |
| 10:42 |
|
masak |
I always work on bleeding edge Parrot. |
| 10:48 |
|
cotto |
That way when you cut yourself, you can give Parrot a bandage. |
| 10:49 |
|
masak |
bandages++ |
| 10:49 |
|
moritz |
and chromatic is master of bandages ;) |
| 10:50 |
|
masak |
...and of de-FUDding, incidentally. |
| 10:51 |
|
szabgab |
what about rakudo? it does not have separate release cycle from parrot right? |
| 10:51 |
|
masak |
no. |
| 10:51 |
|
szabgab |
so I should consider the released parrots to be stable rakudos as well? |
| 10:52 |
|
masak |
szabgab: depending on what you put into the term, yes. |
| 10:52 |
|
szabgab |
the stabelest we can have now |
| 10:52 |
|
masak |
right. |
| 10:55 |
|
szabgab |
and btw is there some estimation for parrot 1.0? |
| 10:56 |
|
* masak |
esteems Parrot 1.0 |
| 10:56 |
|
masak |
:) |
| 10:58 |
|
szabgab |
anything like "more than 6 months for sure" or "might be in 3 month" |
| 10:59 |
|
masak |
szabgab: when you ask about the release of 1.0, what particular feature(s) do you wish for? |
| 10:59 |
|
* moritz |
says 6 months |
| 10:59 |
|
szbalint |
you know the standard estimate, szabgab |
| 10:59 |
|
szbalint |
ready by xmas |
| 10:59 |
|
szabgab |
I don't care so much about features, more about the marketing bit |
| 10:59 |
|
szabgab |
thats' for perl 6 |
| 11:00 |
|
szabgab |
parrot is almost independent from perl 6 |
| 11:01 |
|
Patterner |
the standard answer is "xmas". the standard omission is the year. |
| 11:01 |
|
masak |
szabgab: well, yes and no. a dep for the release of Parrot is "two stable HLLs" or something like that. Rakudo will be one of them. |
| 11:02 |
|
|
barney joined #parrot |
| 11:02 |
|
masak |
s/release/1.0 release/ |
| 11:02 |
|
moritz |
masak: but "stable" ne "full" |
| 11:02 |
|
masak |
true. |
| 11:02 |
|
szabgab |
I know all the Xmas answers and I am not expecting anything like it will be done by that time, I am ok with an answer, at least 6 month |
| 11:03 |
|
szabgab |
so basically the "two stable HLLs" make it parrot quite dependent on the perl 6 design process, right? |
| 11:06 |
|
masak |
szabgab: um, depends on whether "stable" means "not changing" or "useable" |
| 11:08 |
|
moritz |
szabgab: I don't think that one of them has to be Perl 6. It could be partcl (tcl) and cardinal (ruby), for example |
| 11:09 |
|
szabgab |
I want to be able to run Padre on Parrot at least paritally written in Perl 6, I don't mind using a subset of the language |
| 11:09 |
|
szabgab |
and of course I'd like to let people use tcl and/or ruby to add plugins to Padre |
| 11:11 |
|
szabgab |
but I have to give the user a relatively painless and fearless way to install it |
| 11:11 |
|
moritz |
szabgab: in a comment on http://perlbuzz.com/2008/10/pe[…]ly-vaporware.html I wrote down what I think is needed to actually code in Perl 6, without too many "wtfs per minute" (No. 2 has been fixed since then) |
| 11:11 |
|
szabgab |
painless is technical, fearless is more psychological, marketingish issue |
| 11:12 |
|
moritz |
that's the "painless" part I was referring to ;) |
| 11:16 |
|
szabgab |
moritz: and do you any kind of time estimate for the other 3 ? |
| 11:18 |
|
masak |
szabgab: I'd rate #1 as "almost fixed now". maybe a week or two. |
| 11:26 |
|
szabgab |
and the other two? even a minimum time would do it for me. see I am begging :-) |
| 11:28 |
|
masak |
szabgab: you'll probably have to beg pmichaud++ and jonathan++ for estimates to #3 and #4. :) |
| 12:08 |
|
jonathan |
#4 is waiting on a refactoring of part of the grammar to get us more in line with STD.pm. |
| 12:08 |
|
jonathan |
I don't think it should be so bad to do, and I think we've got enough tests now that I shouldn't break too much. :-) |
| 12:14 |
|
|
ruoso joined #parrot |
| 12:29 |
|
|
Lorn joined #parrot |
| 12:44 |
|
|
konstantin joined #parrot |
| 12:53 |
|
|
DietCoke joined #parrot |
| 12:53 |
|
|
konstantin joined #parrot |
| 13:08 |
|
|
jimmy joined #parrot |
| 13:19 |
|
pmichaud |
(from http://perlbuzz.com/2008/10/pe[…]ly-vaporware.html comment): "There's no way to turn an array ref into an array" ... example? |
| 13:21 |
|
|
iblechbot joined #parrot |
| 13:27 |
|
szbalint |
you need to give an example to disprove that statement |
| 13:28 |
|
jonathan |
@array.values? |
| 13:28 |
|
jonathan |
er |
| 13:28 |
|
jonathan |
$arrayref.values? |
| 13:28 |
|
pmichaud |
I don't understand what "turn an array ref into an array" means here. |
| 13:31 |
|
szbalint |
me neither, but I didn't make that statement :) |
| 13:32 |
|
jonathan |
pmichaud: I suspect they're trying to do the Perl 5 equivalent of @$array_ref |
| 13:32 |
|
pmichaud |
ah. |
| 13:32 |
|
jonathan |
But you really don't need to in Perl 6. |
| 13:32 |
|
jonathan |
In most circumstances. |
| 13:32 |
|
pmichaud |
sometimes you do |
| 13:32 |
|
pmichaud |
actually, often you do |
| 13:32 |
|
pmichaud |
for $arrayref { ... } |
| 13:32 |
|
jonathan |
Ah, yes, that won't iterate over the array's values, will it... |
| 13:32 |
|
pmichaud |
you really need for @$arrayref { ... } or for $arrayref.values { ... } |
| 13:33 |
|
jonathan |
Right |
| 13:33 |
|
* jonathan |
needs more coffee |
| 13:33 |
|
jonathan |
Anyway, the .values way exists now |
| 13:33 |
|
pmichaud |
I wonder why .list isn't working. |
| 13:34 |
|
jonathan |
It's not? |
| 13:34 |
|
pmichaud |
according to jhorwitz yesterday it wasn't. |
| 13:34 |
|
pmichaud |
building now so I can check. |
| 13:34 |
|
jonathan |
kk |
| 13:34 |
|
Coke |
... what does for $arrayref do ? |
| 13:35 |
|
Coke |
it just fires once on the ref? |
| 13:35 |
|
pmichaud |
coke: it would loop over the single array element. |
| 13:35 |
|
pmichaud |
it's essentially the same as for ($arrayref, 2, 3) { ... } |
| 13:35 |
|
pmichaud |
except without the 2, 3 part. |
| 13:35 |
|
|
ChrisDavaz joined #parrot |
| 13:36 |
|
Coke |
Hurm. I am thinking I'd rather that act like an array in that context, and have to specify I wanted the ref instead of the array. |
| 13:37 |
|
pmichaud |
how would one "specify I want the ref" ? |
| 13:37 |
|
pmichaud |
anyway, that's a language design issue, so I get to pass the question off to p6l. :-) |
| 13:38 |
|
Coke |
ayup. (can't be a method, because that'd return a ref... which i already said I wanted to be special.) |
| 13:38 |
|
* Coke |
guesses $$ |
| 13:39 |
|
pmichaud |
in this sense it's really the same as Perl 5, though |
| 13:40 |
|
pmichaud |
my $a = [1, 2, 3]; |
| 13:40 |
|
pmichaud |
for ($a) { print "$_\n"; } # "1 2 3\n" |
| 13:40 |
|
pmichaud |
for (@{$a}) { print "$_\n"; } # "1\n2\n3\n" |
| 13:40 |
|
pmichaud |
(perl 5 code above) |
| 13:40 |
|
pmichaud |
oops |
| 13:40 |
|
pmichaud |
in reality |
| 13:40 |
|
purl |
in reality is probably that it is generated by on setup_function |
| 13:41 |
|
pmichaud |
for ($a) { print "$_\n"; } # "ARRAY(0x......)" |
| 13:42 |
|
pmichaud |
ahhh, I see the problem with 'list'. |
| 13:42 |
|
pmichaud |
jonathan: do we have a way to go from an ObjectRef to the thing it references? |
| 13:44 |
|
|
bacek joined #parrot |
| 13:44 |
|
pmichaud |
(in PIR) |
| 13:47 |
|
jonathan |
pmichaud: Anything that invokes get_pmc would probably do it... |
| 13:47 |
|
jonathan |
But I can't think of an op right away... |
| 13:47 |
|
jonathan |
hmm |
| 13:47 |
|
pmichaud |
is there a get_pmc op? |
| 13:47 |
|
jonathan |
maybe |
| 13:47 |
|
pmichaud |
I think there's a set_pmc op. |
| 13:47 |
|
jonathan |
It's a vtable |
| 13:48 |
|
pmichaud |
hrm, guess there isn't. |
| 13:48 |
|
pmichaud |
ah, setref and deref |
| 13:49 |
|
pmichaud |
how strange that they're actually called by names that indicate what they do. :-P |
| 13:50 |
|
jonathan |
lol! |
| 13:50 |
|
jonathan |
pmichaud++ |
| 14:14 |
|
|
Zaba joined #parrot |
| 14:16 |
|
nopaste |
"pmichaud" at 72.181.176.220 pasted "going from arrayref to a list" (12 lines) at http://nopaste.snit.ch/14547 |
| 14:17 |
|
|
gryphon joined #parrot |
| 14:23 |
|
|
Lorn joined #parrot |
| 14:23 |
|
dalek |
r32571 | pmichaud++ | trunk: |
| 14:23 |
|
dalek |
: [rakudo]: spectest-progress.csv update: 216 files, 4528 passing, 8 failing |
| 14:24 |
|
dalek |
: Failure summary: |
| 14:24 |
|
dalek |
: S02-literals/radix.rakudo aborted 8 test(s) |
| 14:24 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32571 |
| 14:24 |
|
dalek |
r32572 | pmichaud++ | trunk: |
| 14:24 |
|
dalek |
: [rakudo]: update test_summary.pl to report failures, output < 80 cols |
| 14:24 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32572 |
| 14:26 |
|
|
Zaba joined #parrot |
| 14:28 |
|
jimmy |
parrotvm is so slow... |
| 14:29 |
|
|
bacek joined #parrot |
| 14:35 |
|
|
dalek joined #parrot |
| 14:43 |
|
|
rdice joined #parrot |
| 14:51 |
|
dalek |
r32573 | pmichaud++ | trunk: |
| 14:51 |
|
dalek |
: [rakudo]: Fix .list method on arrays (and arrayrefs). |
| 14:51 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32573 |
| 14:52 |
|
|
Zaba joined #parrot |
| 14:58 |
|
|
Zaba joined #parrot |
| 15:02 |
|
|
dmknopp joined #parrot |
| 15:05 |
|
|
dmknopp left #parrot |
| 15:05 |
|
|
dmknopp joined #parrot |
| 15:06 |
|
|
Lorn joined #parrot |
| 15:18 |
|
|
Andy joined #parrot |
| 15:18 |
|
|
Zaba joined #parrot |
| 15:20 |
|
|
NotFound joined #parrot |
| 15:20 |
|
NotFound |
Hi |
| 15:20 |
|
purl |
hey, NotFound. |
| 15:22 |
|
Coke |
jimmy: I am often inclined to agree with that. |
| 15:30 |
|
jimmy |
had parrot implemented array class? |
| 15:31 |
|
Coke |
s/class/PMC/ yes. |
| 15:32 |
|
Coke |
$P1 = new 'Array' # or 'ResizablePMCArray', usually. |
| 15:32 |
|
Coke |
# or any of a lot of other more specific container types. |
| 15:32 |
|
|
AndyA joined #parrot |
| 15:32 |
|
jimmy |
where is the s dir? |
| 15:33 |
|
Coke |
s// is a perl-ism, it means replace the first part with the second. |
| 15:33 |
|
Coke |
so, to expand that, "if by class, you mean PMC, then yes." |
| 15:33 |
|
szbalint |
s// is an error actually |
| 15:33 |
|
szbalint |
:] |
| 15:33 |
|
Coke |
sorry about the confusion. |
| 15:34 |
|
Coke |
and about szbalint. |
| 15:36 |
|
jimmy |
find it, thanks coke |
| 15:37 |
|
szbalint |
purl: regexp? |
| 15:37 |
|
purl |
i guess regexp is short for regular expression |
| 15:37 |
|
szbalint |
purl: regular expression? |
| 15:37 |
|
purl |
regular expression is a predicate on strings |
| 15:37 |
|
szbalint |
pfft |
| 15:38 |
|
jimmy |
i thought there is a class, because i saw it ever. |
| 15:40 |
|
jimmy |
purl: regexp? |
| 15:40 |
|
purl |
regexp is short for regular expression |
| 15:42 |
|
|
Zaba joined #parrot |
| 15:44 |
|
|
cosimo joined #parrot |
| 15:47 |
|
|
hercynium joined #parrot |
| 15:52 |
|
|
ruoso joined #parrot |
| 15:53 |
|
dalek |
r32574 | pmichaud++ | trunk: |
| 15:53 |
|
dalek |
: [rakudo]: Make log(0) return a Failure (RT #60490, masak++) |
| 15:53 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32574 |
| 15:56 |
|
jonathan |
particle: ping |
| 16:31 |
|
Coke |
pmichaud: (anon) perhaps: .namespace ['Signature'] |
| 16:31 |
|
Coke |
.sub 'onload' :anon :init :load |
| 16:31 |
|
Coke |
that doesn't correspond directly to a user-defined block, does it? |
| 16:31 |
|
Coke |
(it's also neither an inner block nor a anonymous sub, of course.) |
| 16:32 |
|
pmichaud |
that's correct, those are auto-generated. |
| 16:40 |
|
|
jhorwitz joined #parrot |
| 16:40 |
|
|
Zaba joined #parrot |
| 16:42 |
|
* jonathan |
thinks that the bytecode annotations stuff really needs doing so we can generate good errors soon |
| 16:43 |
|
jonathan |
But it goes with a whole bunch of bytecode handling refactors which are quite a bit of work, though Infinoid++ has made a good start. |
| 16:45 |
|
Coke |
I wonder if it would be possible to create an artistic-license'd version of cold fusion running on parrot. |
| 16:46 |
|
Coke |
I don't think it would be it, |
| 16:47 |
|
pmichaud |
jonathan: btw, I think I've convinced myself that $?PACKAGE, $?CLASS should indeed be held as lexicals. |
| 16:47 |
|
Coke |
er, be worth the effort, but I wonder if legally it would be doable. |
| 16:47 |
|
pmichaud |
in particular, we can replace existing instances of 'def' with $?CLASS :-) |
| 16:50 |
|
jonathan |
(implementing it like the spec says)++ |
| 16:50 |
|
jonathan |
Yes, that's very true. |
| 16:51 |
|
pmichaud |
oh, there was a proposed PCT change that came out during your vacation |
| 16:52 |
|
pmichaud |
I'm thinking of allowing string/int/num constants directly in the PAST tree |
| 16:52 |
|
jonathan |
Rather than needing PAST::Val nodes? |
| 16:52 |
|
pmichaud |
yes. |
| 16:52 |
|
jonathan |
Rational, other than less objects to create? |
| 16:52 |
|
jonathan |
Or is that enough? |
| 16:52 |
|
pmichaud |
we still have PAST::Val nodes for things that have special requirements (typing, construction, etc.), but simple string/int/num can go directly in the tree |
| 16:52 |
|
pmichaud |
less objects to create, easier to read and process |
| 16:53 |
|
jonathan |
OK |
| 16:53 |
|
jonathan |
No immediate objections from me. |
| 16:53 |
|
pmichaud |
it just seems cleaner in a lot of ways |
| 16:53 |
|
jonathan |
I've at lesat a couple of times mistakenly not created a PAST::Var node when I shoulda done and just stuck a value in, anyway... |
| 16:55 |
|
pmichaud |
right. |
| 16:56 |
|
pmichaud |
for this limited case I think it's worth dwim instead of enforcing a rigid strictness |
| 16:57 |
|
|
Theory joined #parrot |
| 16:57 |
|
jonathan |
Yes. |
| 16:57 |
|
jonathan |
Makes sense. |
| 16:57 |
|
jonathan |
Go for it. |
| 16:58 |
|
|
Zaba joined #parrot |
| 17:03 |
|
* Coke |
goes WOOOT for a reason entirely not to do with parrot. |
| 17:03 |
|
pmichaud |
I don't know when it'll occur, but it's in the planning stage. |
| 17:04 |
|
jonathan |
Sure, I guess not high priority compared to other things. |
| 17:04 |
|
jonathan |
*cough*lexicals*cough*protoregexes*cough* |
| 17:04 |
|
pmichaud |
well, there's a fair bit of refactoring to do in actions.pm, which is what makes me think of it. |
| 17:04 |
|
jonathan |
*nod* |
| 17:04 |
|
pmichaud |
I'll be really glad to give someone else lexicals to do, btw. :-) |
| 17:05 |
|
jonathan |
Erm. |
| 17:05 |
|
pmichaud |
the only reason I'm doing it is because nobody else seems to want to take care of it. :-| |
| 17:05 |
|
jonathan |
How do the lolcats say... |
| 17:05 |
|
jonathan |
...DO NOT WANT. |
| 17:05 |
|
jonathan |
;-) |
| 17:05 |
|
jonathan |
It's...hard. |
| 17:05 |
|
jonathan |
How far along is the lex branch? |
| 17:05 |
|
pmichaud |
I'll bite the bullet and spend a day on it soon. |
| 17:06 |
|
jonathan |
As in, what's missing? What's done? |
| 17:06 |
|
pmichaud |
the basics are in place -- I have the capture_lex and newclosure opcodes done. |
| 17:06 |
|
pmichaud |
The hard part is autoclose semantics. |
| 17:06 |
|
Coke |
pmichaud: are you a coffee drinker? |
| 17:06 |
|
pmichaud |
I _think_ I have autoclose worked out mostly -- just need to write it down and then implement it. |
| 17:07 |
|
jonathan |
If you've got it worked out, then it's probably best you do at lesat one half of that. |
| 17:07 |
|
pmichaud |
part of the problem is that I'm working with code where I understand very few of the design parameters that are involved, so I don't know if I'm breaking anything |
| 17:07 |
|
pmichaud |
Coke: I very rarely drink coffee. |
| 17:07 |
|
pmichaud |
like, usually only in Europe. :-) |
| 17:07 |
|
Coke |
pmichaud: heh |
| 17:07 |
|
Coke |
so throwing a DD or SB card at you will not help you code faster. Roger. =-) |
| 17:07 |
|
jonathan |
pmichaud: If you can write up what you want, I maybe can help on implementing it. |
| 17:08 |
|
pmichaud |
jonathan: that's what I'm working on now. :-) |
| 17:08 |
|
jonathan |
I need to refactor variable_decl (I think it's that one) to look more like STD.pm. |
| 17:08 |
|
jonathan |
Then we can have things like "has $.x = 42" |
| 17:08 |
|
pmichaud |
what I have so far is at http://www.pmichaud.com/perl6/lexical.txt |
| 17:09 |
|
pmichaud |
refactoring variable_declarator really means we should have signature fixed first. |
| 17:09 |
|
jonathan |
Perhaps - I'd rather do the first refactor which is just shuffling around code mostly, rather than changing too much at one go. |
| 17:10 |
|
jonathan |
But yes, it will want to change with respect to sigs also. |
| 17:10 |
|
pmichaud |
it's all the same pieces |
| 17:11 |
|
jonathan |
Autoclose |
| 17:11 |
|
jonathan |
Autoclose |
| 17:11 |
|
jonathan |
erm |
| 17:11 |
|
|
tewk_ joined #parrot |
| 17:12 |
|
jonathan |
The stuff under that heading doesn't sound that vastly different to what we do today? |
| 17:12 |
|
jonathan |
Other than mentioning capture_lex? |
| 17:12 |
|
pmichaud |
the big difference is that I won't be chasing up the caller chain. |
| 17:12 |
|
jonathan |
Aha. |
| 17:12 |
|
pmichaud |
s/is/will be/ |
| 17:12 |
|
pmichaud |
so far none of this requires looking up the caller chain |
| 17:13 |
|
pmichaud |
which is where I think the current problems lie. |
| 17:13 |
|
jonathan |
OK |
| 17:13 |
|
pmichaud |
(well, we might look at the immediate caller as part of invoke, but that's about it.) |
| 17:14 |
|
pmichaud |
iiuc, what happens today is that autoclose tries to chase up the caller chain looking for contexts that match its criteria |
| 17:14 |
|
jonathan |
Ah, OK. |
| 17:14 |
|
pmichaud |
which is bad, especially if an outer lexical scope isn't even *in* the caller chain. |
| 17:14 |
|
jonathan |
Yes. |
| 17:14 |
|
jonathan |
Plus perhaps a source of subtle bugs. |
| 17:15 |
|
pmichaud |
anyway, I'll finish the writeup today if I can. |
| 17:16 |
|
jonathan |
OK. |
| 17:16 |
|
|
ruoso joined #parrot |
| 17:22 |
|
* jonathan |
ponders subtypes |
| 17:22 |
|
jonathan |
I think the SubSet class needs to go away. |
| 17:23 |
|
jonathan |
I suspect since the subset types are just refinements to real types, we can do it as an anonymous subclass of the proto that overrides ACCEPTS |
| 17:23 |
|
* jonathan |
JFDI |
| 17:38 |
|
|
rob joined #parrot |
| 17:42 |
|
|
PacoLinux_ joined #parrot |
| 17:46 |
|
|
konstantin joined #parrot |
| 17:47 |
|
|
PerlJam joined #parrot |
| 17:54 |
|
dalek |
r32575 | Whiteknight++ | trunk: |
| 17:54 |
|
dalek |
: [Book] Fix up the first half of Chapter 2. Fix prose and flow, grammar, and the occasional spelling problem. |
| 17:54 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32575 |
| 18:09 |
|
|
cognominal joined #parrot |
| 18:11 |
|
jonathan |
rakudo: subset Even of Int where { $^n %2 == 0 }; say Even.WHAT; |
| 18:11 |
|
polyglotbot |
OUTPUT[Subset] |
| 18:11 |
|
|
rhr joined #parrot |
| 18:12 |
|
|
wonko joined #parrot |
| 18:15 |
|
|
chromatic joined #parrot |
| 18:15 |
|
pmichaud |
(anonymous subclass)++ |
| 18:16 |
|
jonathan |
pmichaud: Yeah, the current bug (as shown there) will go away then. |
| 18:16 |
|
pmichaud |
for that matter, does it have to be anonymous? ;-) |
| 18:16 |
|
pmichaud |
looks to me like it has a name ("Even") |
| 18:16 |
|
jonathan |
Oh, in that case, yes. |
| 18:16 |
|
jonathan |
In the general case they can be anonymous. |
| 18:17 |
|
pmichaud |
yes. :-) |
| 18:17 |
|
jonathan |
but yeah, may well name the named ones |
| 18:17 |
|
jonathan |
Just trying to make sure my approach is going to work first. |
| 18:22 |
|
pmichaud |
afk, lunch |
| 18:24 |
|
|
bacek joined #parrot |
| 18:28 |
|
Coke |
jonathan: what should that have output? Even ? |
| 18:30 |
|
jonathan |
Coke: Yes. |
| 18:30 |
|
jonathan |
I think so. |
| 18:30 |
|
jonathan |
Oh,no |
| 18:30 |
|
jonathan |
I think maybe Int |
| 18:30 |
|
jonathan |
Since subtypes are just refinements on real types. |
| 18:31 |
|
jonathan |
It certainly shouldn't have emitted Subset. |
| 18:31 |
|
jonathan |
I can argue it either way on the other one, but I suspect Int is the answer. |
| 18:31 |
|
* jonathan |
-> dinner |
| 18:31 |
|
|
Zaba joined #parrot |
| 18:37 |
|
pmichaud |
I suspect Int is the answer, also. |
| 18:38 |
|
pmichaud |
I'm not even sure that .WHAT works on Even |
| 18:38 |
|
pmichaud |
(since it's really a macro) |
| 18:38 |
|
pmichaud |
afk, lunch for real this time. |
| 19:07 |
|
|
Zaba joined #parrot |
| 19:29 |
|
dalek |
r32576 | coke++ | trunk: |
| 19:29 |
|
dalek |
: use of .return as a synonym for .tailcall is [DEPRECATED] |
| 19:29 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32576 |
| 19:35 |
|
particle |
so, WHAT gives a shortname of "Int", and WHO gives "Even of Int"? |
| 19:35 |
|
particle |
or can you not get the name of a subclass even after you've named it? |
| 19:36 |
|
pmichaud |
note that subset != subclass |
| 19:37 |
|
particle |
oops, i meant subset of course |
| 19:37 |
|
particle |
my point is that if you name a subset, you should be able to somehow recover that name |
| 19:38 |
|
pmichaud |
maybe. I'm not sure that we could do things like my $x = Even; |
| 19:38 |
|
|
findlay joined #parrot |
| 19:39 |
|
particle |
no, i'm not sure of that either |
| 19:39 |
|
particle |
but why bother with having a name if it's declaration-only |
| 19:43 |
|
|
kj joined #parrot |
| 19:45 |
|
pmichaud |
oh, it's still usable wherever we expect a typename |
| 19:45 |
|
pmichaud |
i.e., my Even $x = 2; |
| 19:45 |
|
pmichaud |
but the fact that it's visible as a name doesn't necessarily imply it's a value that can be .WHAT |
| 19:45 |
|
pmichaud |
(it doesn't imply that it can't either -- I'm just saying we're not clear on it yet) |
| 19:46 |
|
particle |
yes, we're not clear. |
| 19:46 |
|
particle |
i suspect the fullname (.WHO) will contain the subset name |
| 19:49 |
|
* Coke |
runs "make TEST_JOBS=3 test" |
| 19:52 |
|
dalek |
r32577 | coke++ | trunk: |
| 19:52 |
|
dalek |
: using .return as a synonym of .tailcall is [DEPRECATED] |
| 19:52 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32577 |
| 19:54 |
|
Coke |
that's the last test failure regarding .return/.tailcall, I think. |
| 19:59 |
|
|
johbar joined #parrot |
| 20:00 |
|
TimToady |
phone |
| 20:00 |
|
dalek |
r32578 | coke++ | trunk: |
| 20:00 |
|
dalek |
: RT #58974; remove [DEPRECATED] .return syntax; use .tailcall instead. (all tests pass) |
| 20:00 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32578 |
| 20:00 |
|
Coke |
TimToady: 1m. |
| 20:01 |
|
pmichaud |
be there in 3 |
| 20:03 |
|
Coke |
TimToady++ |
| 20:17 |
|
particle |
coke: does r32578 requires realclean? |
| 20:25 |
|
Coke |
I don't think so. |
| 20:26 |
|
Coke |
presuming the deps are correct. |
| 21:01 |
|
|
AndyA joined #parrot |
| 21:16 |
|
|
masak joined #parrot |
| 21:19 |
|
masak |
have I got a Rakudo bug for you tonight! |
| 21:20 |
|
nopaste |
"masak" at 130.238.45.242 pasted "a bug involving gather, pattern matching and .substr" (15 lines) at http://nopaste.snit.ch/14553 |
| 21:20 |
|
bacek |
masak: good morning :) |
| 21:20 |
|
masak |
bacek: y0 Ö= |
| 21:20 |
|
masak |
:) |
| 21:21 |
|
masak |
when looking at the above code, keep in mind that it shouldn't produce anything. that's because I've removed all the parts that didn't cause trouble. |
| 21:22 |
|
masak |
IOW, I'm aware that one would never want a program exactly like this. the point is that the program crashes. |
| 21:23 |
|
bacek |
bacekicering:~/src/parrot/languages/perl6$ ../../parrot perl6.pbc g.pl |
| 21:23 |
|
bacek |
Cannot take substr outside string |
| 21:23 |
|
masak |
bacek: that's it. |
| 21:24 |
|
masak |
it's a reasonable error, in some circumstances. but I think you can look at the code and prove to yourself that it shouldn't do that. |
| 21:24 |
|
bacek |
masak: (crash) same bug with "die in subroutines" |
| 21:25 |
|
pmichaud |
that's a Parrot message |
| 21:25 |
|
pmichaud |
Parrot complains (with that message) if you attempt to take a substring beyond the end of a string. |
| 21:25 |
|
masak |
ok. |
| 21:25 |
|
pmichaud |
the answer is probably for rakudo's .substr method to check for that and do something reasonable. |
| 21:26 |
|
masak |
bacek: I don't understand what you mean with "same bug with 'die in subroutines'" |
| 21:26 |
|
pmichaud |
or, catch the exception and convert it to something reasonable. |
| 21:26 |
|
masak |
pmichaud: if you remove the gather block, the program doesn't crash |
| 21:26 |
|
bacek |
pmichaud: #56216 :) |
| 21:27 |
|
masak |
pmichaud: something is horribly wrong here. |
| 21:27 |
|
bacek |
pmichaud: patch is quite old. It should call '!FAIL' in moder rakudo |
| 21:27 |
|
bacek |
masak: it's #57330. |
| 21:28 |
|
masak |
bacek: yes, what about it? is this the same thing? |
| 21:28 |
|
bacek |
57396 & 57398 is actually duplicates. |
| 21:28 |
|
bacek |
masak: technically - yes. |
| 21:29 |
|
masak |
I'm lost -- how can adding a gather block cause the crash? |
| 21:29 |
|
pmichaud |
I don't believe they are all the same thing. |
| 21:29 |
|
masak |
the program works fine without it |
| 21:29 |
|
bacek |
masak: try 'sub foo { die }; foo' |
| 21:29 |
|
pmichaud |
Let's not assume things are the same until we can prove it. |
| 21:29 |
|
masak |
bacek: I know about that one, it's not the same. |
| 21:29 |
|
masak |
trust me. |
| 21:29 |
|
pmichaud |
masak: the gather block imposes an exception handler in the mix |
| 21:29 |
|
masak |
ok. |
| 21:29 |
|
bacek |
masak: NO WAY :) |
| 21:30 |
|
masak |
bacek: :) |
| 21:30 |
|
pmichaud |
masak: so it may be the existence (or non-existence) of the exception handler that is affecting things here. |
| 21:30 |
|
masak |
would looking at the PIR code make things clearer, perhaps? |
| 21:30 |
|
pmichaud |
let me look at the perl 6 snippet a bit closer, first. |
| 21:30 |
|
bacek |
afk # $kids->school |
| 21:31 |
|
masak |
pmichaud: yes, of course. |
| 21:31 |
|
purl |
Indubitably. |
| 21:31 |
|
nopaste |
"Coke" at 65.91.151.195 pasted "small-ish PIR from phone" (11 lines) at http://nopaste.snit.ch/14554 |
| 21:32 |
|
Coke |
chromatic, particle, pmichaud: that sample depends on the perl6 code you're trying to eval. if you use a different invalid bit of perl6, it works. |
| 21:32 |
|
Coke |
e.g. if you leave off the trailing }; something about that particular exception is causing trouble. |
| 21:32 |
|
bacek |
masak: try to put try around gather. It will fix crash |
| 21:32 |
|
Coke |
could probably narrow it down further if necessary. |
| 21:32 |
|
masak |
bacek: hokay. |
| 21:33 |
|
bacek |
masak: because of "handle all exceptions handler"... |
| 21:33 |
|
pmichaud |
of course, it's not clear why an exception is generated in the first place. |
| 21:33 |
|
chromatic |
That's an ASSERT failure. |
| 21:33 |
|
masak |
bacek: thing is, I don't want it to crash, try block or no try block. |
| 21:34 |
|
chromatic |
I think it's related to the exception handler gyrations. |
| 21:34 |
|
chromatic |
Huh. |
| 21:34 |
|
chromatic |
It's compiling code. |
| 21:34 |
|
chromatic |
do_sub_pragmas |
| 21:34 |
|
pmichaud |
(we now have two exception conversations going... my comments are aimed at the masak/bacek one :-) |
| 21:34 |
|
chromatic |
PackFile_fixup_subs |
| 21:34 |
|
masak |
pmichaud: aye, it's not clear why. that's what troubles me. |
| 21:35 |
|
pmichaud |
masak: it throws an exception only if gather is present? |
| 21:35 |
|
masak |
correct. |
| 21:35 |
|
chromatic |
I can't get it to segfault though. |
| 21:36 |
|
pmichaud |
masak: I'll need to svn up and rebuild parrot -- need about 5 mins |
| 21:36 |
|
Coke |
pmichaud: when running target=pir, there's an .include file that is included -after- constants from it are used. |
| 21:36 |
|
masak |
pmichaud: no problems -- I'm blogging right now, take your time. |
| 21:36 |
|
Coke |
chromatic: lemme double check. |
| 21:37 |
|
pmichaud |
Coke: is the file included more than once, or just the once? |
| 21:37 |
|
pmichaud |
Coke: I suspect that may have been from jonathan's MAIN change yesterday. |
| 21:37 |
|
pmichaud |
or the $?PACKAGE one |
| 21:37 |
|
Coke |
chromatic: crap. now i can't either. |
| 21:37 |
|
Coke |
pmichaud: just once. |
| 21:37 |
|
pmichaud |
okay, I'll have to check on the code there. |
| 21:38 |
|
Coke |
chromatic: but we can worry about that once the assert failure goes away. |
| 21:38 |
|
pmichaud |
I'm trying to eliminate the use of the constants from the generated code, but someone keeps adding them back in :-) |
| 21:38 |
|
|
davidfetter joined #parrot |
| 21:38 |
|
pmichaud |
or, I should say: adding new ones in :-) |
| 21:38 |
|
PerlJam |
masak: does #november-wiki actually exist anywhere? |
| 21:38 |
|
moritz |
PerlJam: on freenode |
| 21:39 |
|
masak |
moritz is faster than I am :) |
| 21:39 |
|
masak |
PerlJam: did some documentation lead you to believe otherwise? |
| 21:39 |
|
Coke |
(hurm. if c. can fix this assert, maybe I'll start throwing some of tcl's spec test explosions at him.) |
| 21:40 |
|
Coke |
chromatic++ |
| 21:40 |
|
PerlJam |
no, that I joined #november-wiki and I'm the only one on the channel led be to believe otherwise |
| 21:40 |
|
PerlJam |
(on freenode) |
| 21:40 |
|
moritz |
PerlJam: netsplit, I think |
| 21:40 |
|
moritz |
22:26 -!- Netsplit kubrick.freenode.net <-> irc.freenode.net quits: @masak, @viklund, @zarah, p6eval |
| 21:41 |
|
masak |
PerlJam: looking forward to seeing you there after the netmerge :) |
| 21:41 |
|
chromatic |
I don't know if we can trust the backtrace, thanks to all of the setjmp/longjmp. |
| 21:44 |
|
pmichaud |
masak: I think it may be a lexicals issue. |
| 21:45 |
|
masak |
pmichaud: I'm all ears. |
| 21:46 |
|
pmichaud |
I suspect the 'gather' scope isn't getting the correct set of lexicals. |
| 21:47 |
|
Coke |
(netsplits) purl, be Coke. |
| 21:47 |
|
masak |
pmichaud: is there any sense in me reporting the code snippet to rakudobug? |
| 21:48 |
|
moritz |
masak: put it as a test under t/spec/integration/ |
| 21:48 |
|
pmichaud |
works for me. |
| 21:48 |
|
masak |
moritz: aye. |
| 21:48 |
|
pmichaud |
(putting it as a test works for me) |
| 21:48 |
|
masak |
moritz: how should I test it, according to you? |
| 21:48 |
|
masak |
put a try block around it and check $! ? |
| 21:49 |
|
moritz |
masak: yes, or lives_ok |
| 21:49 |
|
pmichaud |
ouch. |
| 21:49 |
|
masak |
moritz: will do. |
| 21:50 |
|
masak |
pmichaud: note also that looping over only one of the strings doesn't crash. |
| 21:50 |
|
pmichaud |
yes |
| 21:50 |
|
pmichaud |
it happens on the second iteration |
| 21:50 |
|
masak |
aye. |
| 21:50 |
|
pmichaud |
what appears to be happening is that we retrieve the $c from the previous execution |
| 21:51 |
|
pmichaud |
but retain the $/ from the current execution |
| 21:51 |
|
masak |
not good. |
| 21:51 |
|
pmichaud |
so when it tries to do a .substr($/.from) that becomes .substr(3) on an empty string and we get the exception. |
| 21:51 |
|
pmichaud |
more precisely, the $c .= substr($/.from); uses the $c from the previous execution. |
| 21:52 |
|
masak |
pmichaud++ |
| 21:52 |
|
masak |
that makes perfect sense. |
| 21:52 |
|
masak |
(except that it's wrong, of course) |
| 21:52 |
|
pmichaud |
yes. |
| 21:53 |
|
pmichaud |
and if I remove the explicitly 'newclosure' op that is being run on gather nodes, I get even stranger output. |
| 21:53 |
|
pmichaud |
*explicit |
| 21:53 |
|
masak |
uh huh. |
| 21:54 |
|
pmichaud |
there are times that I think the only thing more broken than imcc is Parrot's lexicals. |
| 21:54 |
|
masak |
I know the feeling. |
| 21:56 |
|
nopaste |
"pmichaud" at 72.181.176.220 pasted "the diagnostic I ran (for masak)" (34 lines) at http://nopaste.snit.ch/14555 |
| 21:56 |
|
pmichaud |
it's actually doing .substr(3) on '1', not the empty string. But it's still the string left over from the previous execution. |
| 21:57 |
|
masak |
aye. |
| 21:57 |
|
masak |
I was wondering where the heck that "1" came from. |
| 21:57 |
|
masak |
now I understand. |
| 21:58 |
|
* pmichaud |
checks with family members to see if he can devote the evening to trying to fix lexicals. |
| 21:59 |
|
PerlJam |
pm: heh! |
| 22:00 |
|
PerlJam |
pm: Wednesdays are supposed to be "mine" for hacking or whatever. So far it hasn't worked out that way. |
| 22:00 |
|
PerlJam |
4 kids + wife + other relatives are too demanding of my time. |
| 22:01 |
|
|
MariachiElf joined #parrot |
| 22:02 |
|
dalek |
r32579 | coke++ | trunk: |
| 22:02 |
|
dalek |
: remove [DEPRECATED] warning - this is gone now. |
| 22:02 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32579 |
| 22:15 |
|
|
gmansi joined #parrot |
| 22:16 |
|
|
sjansen joined #parrot |
| 22:20 |
|
masak |
test added in r22996 |
| 22:20 |
|
masak |
it fails in Rakudo. |
| 22:20 |
|
moritz |
masak++ |
| 22:24 |
|
|
hercynium joined #parrot |
| 22:31 |
|
|
Zaba joined #parrot |
| 22:45 |
|
dalek |
r32580 | moritz++ | trunk: |
| 22:45 |
|
dalek |
: [rakudo] more test files for spectest, and restored alphabetical order. |
| 22:45 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32580 |
| 23:08 |
|
jonathan |
OK folks, I'm off for my pre-flight sleeps - be seeing some of you in California soonish. :-) |
| 23:08 |
|
pmichaud |
sounds good |
| 23:08 |
|
pmichaud |
see you in 48 hrs |
| 23:08 |
|
pmichaud |
oh, more like 50 |
| 23:09 |
|
pmichaud |
(forgot the timezone difference) |
| 23:10 |
|
jonathan |
Yes |
| 23:10 |
|
jonathan |
Looking forward to it. :-) |
| 23:11 |
|
pmichaud |
same here. Any particulars on how we should meet up? |
| 23:11 |
|
pmichaud |
just on IRC, perhaps? |
| 23:11 |
|
jonathan |
I will be arriving with particle, on the van he will be brining from SJC. |
| 23:11 |
|
jonathan |
I'm taking the first night in San Francisco, then coming to the airport and meeting particle and others there. |
| 23:11 |
|
pmichaud |
oh, then I'll see you there. |
| 23:11 |
|
jonathan |
I think you're arriving about then. |
| 23:11 |
|
jonathan |
Yes. |
| 23:11 |
|
pmichaud |
I arrive an hour before particle. |
| 23:12 |
|
jonathan |
Ah, OK. |
| 23:12 |
|
pmichaud |
(unless he's changed his travel arrangements ... /me checks) |
| 23:12 |
|
jonathan |
He gets in at 4:10pm I think. |
| 23:12 |
|
pmichaud |
I arrive 2:30p |
| 23:13 |
|
jonathan |
Ah, OK, a bit before. |
| 23:13 |
|
jonathan |
To SJC? |
| 23:13 |
|
pmichaud |
I'm arriving American 1865 |
| 23:13 |
|
pmichaud |
yes, to SJC |
| 23:13 |
|
pmichaud |
should we designate a meeting point at SJC? |
| 23:15 |
|
jonathan |
I don't know SJC at all. |
| 23:15 |
|
pmichaud |
me neither. I guess we can just wing it. |
| 23:15 |
|
jonathan |
OK, I will come to the airport a bit earlier so we can mee. |
| 23:15 |
|
jonathan |
*meet |
| 23:15 |
|
jonathan |
Well, I am armed with a cell phone. ;-) |
| 23:15 |
|
pmichaud |
me too... 214-682-9420 |
| 23:15 |
|
jonathan |
OK. That allows lazy evaluation of the problem. ;-) |
| 23:15 |
|
pmichaud |
works for me. |
| 23:16 |
|
pmichaud |
before departing you might also grab the latest copy of lexical.txt -- I'm adding some updates now (and plan to work on it much of the evening) |
| 23:16 |
|
jonathan |
aha, OK |
| 23:16 |
|
jonathan |
I'm getting my half-done subset patch shoved over to the laptop too |
| 23:19 |
|
jonathan |
OK |
| 23:19 |
|
jonathan |
Will take an earlier trian than I'd planned. |
| 23:19 |
|
pmichaud |
see you in 48. |
| 23:19 |
|
jonathan |
Yes |
| 23:20 |
|
jonathan |
Safe journey - see you there :-) |
| 23:22 |
|
dalek |
r32581 | coke++ | trunk: |
| 23:22 |
|
dalek |
: Add a failing TODO test for RT#45859 |
| 23:22 |
|
dalek |
diff: http://www.parrotvm.org/svn/pa[…]evision?rev=32581 |
| 23:23 |
|
|
bacek_ joined #parrot |
| 23:27 |
|
Coke |
hurm. anyone know enough lex/yacc to figure out where methods calls are processed in IMCC? I am prettysure that .tailcall <blah> allows them, so I think I'm looking for sub_call, but I can't see where sub_call is processed. |
| 23:29 |
|
chromatic |
Processed how? |
| 23:30 |
|
pmichaud |
.tailcall <blah> does allow method calls -- in fact, they're used quite heavily in much of PGE, PCT, Rakudo, etc. |
| 23:30 |
|
Coke |
aha. found it. |
| 23:35 |
|
|
Zaba joined #parrot |
| 23:47 |
|
Coke |
chromatic: if you make an imcc patch to remove bareword method names (45859), I'll fixup everything in 'make test' to comply. |
| 23:47 |
|
Coke |
(I thought I had it, but am failing to pass the new test I just added) |
| 23:48 |
|
pmichaud |
(fixup everything) that sounds like a big job. Worth doing, but big nonetheless. :-) |
| 23:49 |
|
nopaste |
"coke" at 72.228.52.192 pasted "thought this was it." (16 lines) at http://nopaste.snit.ch/14557 |
| 23:50 |
|
Coke |
but that also breaks foo.'foo'() |
| 23:51 |
|
chromatic |
Coke, will do. |
| 23:52 |
|
Coke |
it's gotta be in that section, damnit. |
| 23:53 |
|
Coke |
... hurm. |
| 23:53 |
|
Coke |
ooh, idea. |
| 23:54 |
|
Coke |
aha! |
| 23:55 |
|
chromatic |
I think there's a trick to it. |
| 23:55 |
|
chromatic |
Check to see if there's a symreg defined with that name (so you already have a PMC or a String register of that name). If not, check that it has quotes. |
| 23:55 |
|
Coke |
ah. |
| 23:56 |
|
chromatic |
If it doesn't, throw a parse exception. |
| 23:56 |
|
Coke |
I was thinking just replacing STRINGC with STRINGCONSTANT might do it. |
| 23:56 |
|
Coke |
ok. I leave the tricky bits to you. I can do all the grunt work after. =-) |
