#parrot Parrot 2.1.1 Released! | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Tasks: Fix HLL bugs! Fix and test corevm target!
Set by moderator on 9 March 2010.
00:00 hercynium joined
Whiteknight hates that "exit" is an unrecognized command in gdb 00:04
darbelo just Contrlo-D's everything this days. 00:05
Works much more often than quit, exit, etc. 00:06
Whiteknight damnit, chromatic disappears when I want to bounce ideas off him 00:08
dukeleto Whiteknight: i can pretend that I am him and give you a random answer, if that helps :)
Tene /nick chromatic
dukeleto we really should create a TT to look into cloning chromatic 00:10
Whiteknight dukleto: ok. I suggest that for mathematics ops, we should delegate to the proxy first, fallback to MMD second, and default last 00:11
dalek nxed: r435 | julian.notfound++ | trunk/examples/pirado.winxed:
.param and .local directives, some register allocation and const string
00:12
dukeleto Whiteknight: these are for regular math ops or the dynops or both?
Whiteknight dukeleto, math vtables for subclasses of numeric bultin types 00:13
dukeleto Whiteknight: "the proxy" refers to PMCProxy ? 00:14
dukeleto puts on dunce hat
Whiteknight yes
dukeleto Whiteknight: what is the reasoning behind PMCProxy coming before MMD ?
Whiteknight take a read through the generated code of src/pmc/object.c sometime. It's obnoxious 00:15
dukeleto puts that on my TODO mountain
Whiteknight meh, fugedaboudit
dukeleto Whiteknight: what generates object.c ?
Whiteknight lib/Parrot/pmc2c/PMC/Object.pm 00:16
dukeleto Whiteknight: i am hoping that my dumb questions maybe help you answer some of your questions. That may be too much to hope for, though
NotFound Now that pirado is able to do some PCC without generating the stringized hex flags I'm wondering what is the reason to have that things in the pbc. If they are used only to check calls in pasm mode, why we store it in the pbc? 00:18
darbelo NotFound: because we don't know better? 00:20
Coke: ping 00:21
NotFound darbelo: I'm unable to follow imcc internal logic, but maybe someone... 00:23
darbelo I tried to understand IMCC once... 00:24
After that I decided we should migrate to pirc *yesterday*
NotFound Looks like the problem is that the string is stored in the constant table and checked from it, so is not easy to isolate. 00:26
dukeleto darbelo: yeah, reading the source of IMCC is the best motivation to work on pirc 00:28
NotFound I'd like better to be freed from lex, yacc and family. 00:30
nopaste "whiteknight" at 68.46.29.192 pasted "patch for chromatic++" (38 lines) at nopaste.snit.ch/19907
Whiteknight purl msg chromatic take a look at nopaste.snit.ch/19907. Fixes the two tests from TT #542 and TT #768, but we fail new tests in multidispatch.t and objects.t. I'm looking a those tests now to make sure they are sane 00:31
purl Message for chromatic stored.
darbelo purl: msg Coke The rm_dynoplibs_make was introducing some unportable makefile constructs. r44860 fixes BSD make, but I can't vouch for other platforms.
purl Message for coke stored.
dalek rrot: r44860 | darbelo++ | branches/rm_dynoplibs_make/src/dynoplibs/Rules.in:
[Makefile] Avoid using $< in non-suffix rules to make BSD make happy.
00:37 snarkyboojum joined 00:42 snarkyboojum_ joined 00:48 eternaleye joined 00:57 abqar joined
Whiteknight damnit, I made commits to the wrong branch 01:00
darbelo purl: msg Coke Also, see r44859. I think that fixes your liking issues on this branch.
purl Message for coke stored.
darbelo And with that. I'm going to sleep.
See y'all later. 01:01
cotto_work night 01:02
dalek rrot: r44861 | darbelo++ | branches/rm_dynoplibs_make (2 files):
Read the LINKARGS variable, taken from the old dynoplibs template, and use it for linking.
01:04
rrot: r44862 | whiteknight++ | branches/tt389_fix (3 files):
[tt389_fix] I committed this to the wrong branch. undo.
01:20
01:23 snarkyboojum joined 01:42 Austin joined
Whiteknight thinks he has the fix_hll_mmd problems licked 01:42
Austin I think it's kind of bizarre that I order something from Amazon.com, select "standard shipping", and the package arrives before the confirmation email. 01:47
Not that I'm complaining, since it showed up overnight...
cotto_work I'd appreciate thoughts on a more refined plan for Lorito: 01:51
nopaste "cotto" at 131.107.0.111 pasted "plan for Lorito" (32 lines) at nopaste.snit.ch/19908
cotto_work goes home 01:53
02:34 ash_ joined 02:44 patspam joined 02:54 snarkyboojum joined
Coke msg cotto - does lorito sit on top of existing bytecode? 02:55
purl Message for cotto stored.
Coke -> 02:56
03:01 patspam joined 03:21 preflex joined
Austin Coke: I think the idea is the other way around - that existing bytecode sits on pmc/ops that is written in lorito. 03:25
Essentially, it's the lower-level vm.
03:28 patspam joined
cotto Coke, what stage of the plan are you talking about? 03:32
The long-term plan is what Austin said. 03:33
03:35 janus joined
plobsing cotto: what about the ability to have bytecode in the interpreter by default on startup so that core VM features can be implemented in PIR but be transparent to users? 03:41
do we have that already?
cotto not sure what you mena 03:42
*mean
I think what you're saying is part of the plan.
plobsing yes, but I don't see it explicitly there, and it's a feature I think would help start us along (and might be useful in other areas) 03:43
cotto I'm adding it now. It's just something I forgot to mention. 03:44
Austin Not only that, but I think a significant fraction of the pmc stuff should already be in pir.
03:44 eternaleye joined
plobsing Austin: exactly. one of the reasons it's not is not wanting to have to "load_bytecode 'RPA.pbc'" 03:44
cotto plobsing, I see what you mean. 03:45
something like parrot_bootstrap.pbc that does all kinds of magical interp init stuff 03:46
Austin Sure, and there's a couple of pmc's that are clearly always going to be in C for performance. But why are there all these "methods" - that are clearly aimed at being called from pir - in C? Why not just write 'em in pir and be done.
plobsing that's a good point. Another point this would improve is ops-based security. If you made Filehandle PMC in PIR over ops/dynops, you eliminate loopholes in op-filter based security (as pitched in TT #1500) 03:50
cotto plobsing, sure. If everything goes through Lorito we can have a high degree of control over what's allowed to run. 03:51
03:53 tetragon joined
plobsing cotto: that depends... If Lorito is as low level as I have come to understand it to be, it may be difficult to distinguish between permissable and forbidden operations. 03:53
03:53 szabgab joined
cotto How so? 03:54
03:55 bacek joined
cotto a wild bacek appears 03:55
bacek I'm not wild. I'm mad! 03:56
plobsing uses sanity. It's not very effective.
cotto agrees with whatever the mad bacek says and backs off slowly
bacek keeps silence 03:57
plobsing cotto: Say Lorito implements filehandle open as with a syscall op. There will be cases when I cannot statically determine what syscall is being made. Maybe its open, maybe its write, maybe its unlink, etc. 03:58
cotto That'll be a good case to bring up when discussion on Lorito starts in earnest. 04:00
plobsing Do I a) risk it and allow this or b) explain to an HLL end user why they have to jump through hoops so that their invariants can translate downwards
cotto I don't see requiring a constant to be used for syscalls creating extra difficulty for HLL users. 04:03
they'll say $f = open("foo","w") and the HLL will eventually generate syscall x, ..., where x is a compile-time constant. 04:04
(assuming we go that route)
plobsing cotto: that's a simple case. There will be cases where the programmer can guarrantee invariance while either the HLL compiler or Lorito analyser cannot 04:05
cotto I'd encourage you to send something to the list about it. It sounds like a point that's worth getting right early. 04:07
bacek, thoughts on a more fine-grained Lorito plan?: 04:21
nopaste "cotto" at 96.26.227.153 pasted "cotto attacks the wild bacek with a Lorito plan" (38 lines) at nopaste.snit.ch/19909
bacek cotto, looks about all right.
cotto Call that v1.1 04:22
What would you add or modify? 04:23
Austin What's the purpose of the plan? More to the point, what's the purpose of lorito?
bacek cotto, may be move "pmc" into later stages. 04:24
cotto bacek, why? 04:25
purl bacek, why is the conditional in mark_context_start() in sub.c? Why do you need to check if it is 0? Why not just do context_gc_mark = 1, and skip the check?
bacek Does almost nothing on early stages. We can implement ops first and than implement pmc in HLL from stage 2 04:26
cotto We'd still need to flesh out how to implement/use core PMCs written in HLLs. 04:28
i.e. the mangled-C PMCs would have to stick around longer
bacek But after implementing ops it will be much easier. 04:29
cotto So you're saying that we should focus on ops until they're all Lorito-y, then use the lessons from that transition on PMCs? 04:30
bacek exactly 04:34
cotto That makes sense.
bacek small steps
purl small steps are easier to debug than big ones. We could get :todo<...> working and not know it due to other errors :-)
cotto bacek, are you saying that the nqp-rx pmc compiler should go later or just that we should wait before implementing PMCs in HLLs? 04:46
bacek just wait
cotto waits 04:47
bacek nqp-rx pmc compiler is independent stream of work.
It can be done in parallel with main ops/lorito work
cotto I think I understand; once Lorito's sufficiently far along, we won't need a separate pmc compiler to build PMCs? 04:48
so the pmc compiler eventually becomes irrelevant 04:49
dukeleto 'ello 04:51
cotto i
cotto goes shopping 04:52
04:52 Austin_Hastings joined
dukeleto Austin_Hastings: howdy 04:53
purl hola, dukeleto.
Austin_Hastings Hey, duke.
bacek not quite true. 04:54
We still need main Grammar for PMC.
But grammar for vtable/methods bodies will be shared with opsc
dukeleto msg particle what is your gsoc link id? i need it for the gsoc app 05:01
purl Message for particle stored.
05:05 tuxdna joined
dalek rrot: r44863 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (2 files):
Remove redundant
05:23
rrot: r44864 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops (2 files):
Implement generating C code for new Ops::Op past
bacek msg cotto new grammar doesn't parse ops correctly... E.g. "opcode * next = expr NEXT();" will be parsed without <macro>. 05:26
purl Message for cotto stored.
dukeleto is hacking on the gsoc app and making tests pass 05:33
dalek kudo: e634b58 | (Martin Berends)++ | src/Perl6/Module/Loader.pm:
[Perl6/Module/Loader.pm] patch by jnthn++ need's %name_adverbs argument optional
05:42 eternaleye joined
cotto bacek, good catch 05:51
dukeleto can someone tell me the difference between: new 'Foo' and new ['Foo'] and where that is documented? 05:53
Austin Duke: I think there's no current difference, but the second way is preferred because of .... mumble mumble mumble ... it's NEW! 05:54
dukeleto Austin: ah, but there is a difference. tewk's recent patch that allows new 'Foo', 5 does not work with the ['Foo'] syntax
cotto 'Foo' would be sc and ['Foo'] would be kc 05:55
dukeleto cotto: sc and kc ?
cotto They might need to be handled explicitly. not 05:56
string const and key const
referring to the op variant that's executed
new_p_sc_i vs new_p_kc_i
dukeleto cotto: interesting. do 'Foo' and ['Foo'] have different semantics? where can I read about that?
cotto I don't think they do but I'm also unclear about why the change is a good idea. 05:57
dukeleto cotto: which change are you talking about? 05:58
Austin: here is how they are different: gist.github.com/328889 06:00
Austin Huh. That's an interesting output format for FSA. Is that built-in, or did you put something in the namespace? 06:02
dukeleto Austin: no, that is built in. it stringifies 06:04
Austin Well, cool.
dukeleto Austin: yes. a pleasant surprise for us both :)
06:16 chromatic joined
dukeleto chromatic: howdy 06:19
purl hello, dukeleto.
chromatic howdy 06:20
purl hey, chromatic.
dukeleto chromatic: it seems that new 'Foo' and new ['Foo'] go down different code paths, such that new 'Foo', 10 works, but new ['Foo'], 10 does not
chromatic: trac.parrot.org/parrot/ticket/1507
chromatic new 'Foo', 10 is the new_s(c?)_i(c?) op and new [ 'Foo' ], 10 is the new_p(c?)_i(c?) op. 06:23
'Foo' is a STRING (and maybe constant) while [ 'Foo' ] is a PMC (and maybe constant).
If tewk didn't add variants for the latter, that syntax won't work. 06:24
dukeleto chromatic: yes, cotto was telling me that. do you have a hint on how I would change VTABLE_init_int to allow the ['Foo'] usage ?
chromatic I don't think the problem is in VTABLE_init_int. 06:25
dukeleto chromatic: tewk was saying that it may be the order that the opcodes are listed
chromatic I don't think that's the case either, but let me look at it. 06:26
06:27 bacek joined
chromatic bacek, did you find anything with compact_pool? 06:28
dalek rrot: r44865 | dukeleto++ | trunk/t/pmc (5 files):
[t] Enable various tests that test VTABLE_init_int. Note that it does not work for key constants (i.e. Foo?) but works on string constants. This needs to be fixed.
06:28 snarkyboojum joined
dukeleto chromatic: thanks 06:28
dukeleto wow, dalek totally munged my commit msg 06:29
dalek TT #1507 created by dukeleto++: VTABLE_init_int does not work on key constants 06:31
dukeleto has anybody tried to write File::Temp in PIR yet? 06:37
lots of tests are stuck in perl-land because they need temp files 06:38
Austin Write it in nqp instead.
dukeleto Austin: i hear what you are saying, but it is for the parrot core test suite, which doesn't use NQP 06:39
Austin And of course nqp doesn't compile to pir, so there's no way to use it.... 06:40
dukeleto Austin: ;)
Austin: yeah, i guess you are correct. it seems that parrot does not currently come with any .nqp files, but there is no reason why it can't 06:42
Austin Just because the source is nqp doesn't mean you can't ship pir - look at nqprx itself.
The point of nqp is to be a hll, because hlls are easier to write, etc. 06:43
chromatic dukeleto, patch on the way. 06:46
dukeleto chromatic: sweet!
nopaste "chromatic" at 67.168.199.244 pasted "dukeleto: fix init_int when instantiating from Key" (52 lines) at nopaste.snit.ch/19910 06:48
chromatic All tests pass here with that. I can commit it if you're satisfied with your tests.
dukeleto chromatic: there are no tests currently that test new ['Foo'], 5 . but go ahead and commit and I will test 06:50
chromatic: did you try to something like in gist.github.com/328889 ? perl tools/dev/parrot_shell.pl and paste the second command for a quick verification 06:51
chromatic I did. 06:52
Straight out of TT #1507.
dukeleto chromatic: sweet!
chromatic: please commit and i will add lots of tests
chromatic: so the previous code was not checking for PMC's created from PIR? 06:53
chromatic It was, but it assumed that Parrot_oo_get_class() would only return a PMC for PMCs written in PIR. 06:54
"Not true," says the hacker who still has scars from wrestling with PMCProxy. 06:55
And that's why it was the Best. Day. Ever.
dukeleto chromatic: interesting. i am still trying to wrap my head around PMCProxy. It seems a lot bigger than my head, currently.
dalek rrot: r44866 | chromatic++ | trunk/src/ops/experimental.ops:
[ops] Fixed the experimental new PPI op to use the init_int VTABLE directly
07:01
dukeleto chromatic++ 07:02
07:20 uniejo joined
dalek rrot: r44867 | dukeleto++ | trunk/t/op (2 files):
[t] Convert some more tests for transcendental ops to PIR
07:34
07:41 bacek joined
dukeleto bacek: o hai 07:42
bacek aloha dukeleto 07:44
dukeleto bacek: may the force be with you. I am going to bed. 07:47
bacek Good idea :)
07:48 iblechbot joined
dalek rrot: r44868 | dukeleto++ | trunk/t/pmc (5 files):
[t][TT#1507] Add tests for VTABLE_init_int with a key constant
07:50
TT #1507 closed by dukeleto++: VTABLE_init_int does not work on key constants 07:53
dukeleto chromatic: $P0 = new ['FixedStringArray'], -5 causes a VM panic, but I can't seem to throw the exception correctly. I should really go to bed 08:06
chromatic Sounds like a malloc problem. 08:12
Yep. 08:13
Cannot instantiate PMC with negative size -5 08:15
How's that work for an exception message?
08:19 JimmyZ joined 08:30 AndyA joined 08:38 fperrad joined 08:56 bacek joined 08:57 lucian joined
bacek msg chromatic ...and rakudo creates A LOT of very long strings. E.g. for ~80k 09:04
purl Message for chromatic stored.
dalek rrot: r44869 | bacek++ | trunk/src/ops/core.ops:
Use str_new_constant in pop_eh/count_eh
09:11
chromatic bacek, I wonder if allocating STRINGs out of fixed size pools would be more useful. 09:13
... except sweeping is hard.
bacek chromatic, indeed. non-mutable strings will be better. 09:14
chromatic The biggest problem with compact_pool is that the pool size grows without bounds. 09:15
It'll always hit a high water mark.
I tried modifying it never to create pools larger than a megabyte in size and copying over that way, but I couldn't get it to work in an hour. 09:16
bacek I think it worth to try to split it into set of pools instead of allocating everything from one 09:17
chromatic I ran into two bits of trouble. 09:20
The first is that you have to make sure to copy from and free multiple pools instead of one, when you compact. That's not a big deal.
The second is that you might have to deal with cases where the current fresh pool isn't large enough to hold the next STRING to copy. 09:21
I think that's what caused problems in my implementation.
bacek yeah... It can be bit of problem. 09:22
Ok. Main slow down of rakudo in core.pm is _many_ calls to "escape $S0" with same string.
Very large one 09:23
Like 100 kilobytes.
chromatic That's probably the output file.
Austin Why would it be escaping the string multiple times?
bacek "[0]) };\\n", ' ' <repeats 12 times>, "} elsif @lhs[1] / @lhs[0] == @lhs[2] / @lhs[1] {\\n", ' ' <repeats 16 times>, "@lhs[0] ... { $_ * (@lhs[1] / @lhs[0]) };\\n", ' ' <repeats 12 times>, "} else {\\n", ' ' <repeats 16 times>, "fail \\"Unable to figure out pattern o" 09:24
Austin, something like :node(~$/)
Austin ?
Escaping is not idempotent.
If its re-escaping the unescaped string, that's a bit wierd. If it's repeatedly escaping the escaped string, that's probably a bug. 09:25
FWIW, maybe escape could benefit from a one-entry cache. 09:26
bacek May be NQP "bug". 09:27
./src/stage0/Regex-s0.pir: $S0 = escape token
09:28 AndyA joined
chromatic That's escaping a substring though. 09:28
Austin Humorously enough, it's doing the escape so it can print a debugging message. 09:29
Maybe !cursor_debug should do it's own escaping, *after* it decides to print the string. 09:30
chromatic Are the tokens really that long?
Austin chromatic: ^^ bacek says ~100k. Probably one of the top-level productions. 09:34
bacek It's !cursor_debug from NQP.
Trying to fix it now
chromatic They should be COW... but can you try this patch?
dalek tracwiki: v3 | mj41++ | Lorito
tracwiki: see also
purl see also is traditionally near the end of the pod...
dalek tracwiki: trac.parrot.org/parrot/wiki/Lorito?...ction=diff
nopaste "chromatic" at 67.168.199.244 pasted "bacek: fewer escapes in NQP-rx" (29 lines) at nopaste.snit.ch/19911
bacek chromatic, I'm working in same direction 09:35
Austin Why not just put the escape in the !cursor_debug sub? 09:36
chromatic How do you know what you can escape safely in there?
Austin Well, I'm figuring that most of the "static" bits will be immune to escaping. 09:37
token=
token1=
chromatic self.'!cursor_debug'( "Got here!\\n" )
I don't want that newline to turn into \\\\n. 09:38
Austin -> self.'!cursor_debug'("Got here!")
!cursor_debug already does \\n
chromatic I want two newlines.
I also don't want my double quotes to turn into \\"
Or my tabs to \\\\t 09:39
dalek kudo: 9786b03 | moritz++ | t/spectest.data:
enable passing test files
kudo: 9ef3c7c | moritz++ | src/core/Parcel.pm:
methods ACCEPTS in class Parcel

do; this patch just implements the case where the invocant has no items, which is also known as Nil.
kudo: 04ad775 | moritz++ | build/Makefile.in:
install Test.pir, since we can't load .pm modules right now
Austin Well, then, in that case the right answer is clearly to impose the whole check-if-debug, branch-to-nodebug, escape, call !cursor_debug, :nodebug tax all over the place, on the off chance you want two newlines. :) 09:40
cotto bacek, grammar fix committed 09:41
chromatic Only one place in this file escapes the strings it sends.
bacek cotto, good!
chromatic ... the strings it sends to !cursor_debug(), that is.
09:41 knewt joined
cotto night 09:41
chromatic msg dukeleto See r44872 for one FSA fix; tests welcome. 09:43
purl Message for dukeleto stored.
bacek Good night, cotto 09:44
dalek rrot: r44870 | cotto++ | branches/ops_pct/compilers/opsc (2 files):
[opsc] force op_macro to first try an empty string for body_word so that
rrot: r44871 | mikehh++ | trunk/src/pmc/fixedbooleanarray.pmc:
fix codetest failure - line length
rrot: r44872 | chromatic++ | trunk/src/pmc/fixedstringarray.pmc:
[PMC] Made FSA throw an exception when initialized with a negative integer.

prevents weird memory panics for now anyhow.
bacek chromatic, reducing escaping doesn't help much in terms of performance... 09:58
chromatic, holy shit... 10:00
dalek rrot: r44873 | mikehh++ | trunk/src/ops/experimental.ops:
fix codetest failure - space before closing parenthesis
bacek Parrot_mmd_build_type_tuple_from_sig_obj calls CallContext.get_string
rrot: r44874 | mikehh++ | trunk/src/pmc/fixedstringarray.pmc:
fix codetest failure - space before closing parenthesis
Austin Well, you would expect that 'escape' is C, and probably fast.
bacek which allocates new string 10:01
Austin What does it do with the string?
mikehh post-config test failure - t/steps/init/hints/linux-01.t - Failed tests: 3-5 10:06
make corevm/make coretest failure - t/pmc/nci.t - Parse errors: Bad plan. You planned 71 tests but ran 0 -- this tests PASSSes after I run make world/make test 10:08
darbelo Austin: That hardly matters, it's the string *creation* that's expensive. 10:10
Even with COW, which cuts down on buffer allocations, the string header overhead is sizable. 10:11
Austin darbelo: That's if there's one being created. I was wondering if this was part of the pcc refactor, or if it was really to-stringing the thing for some reason.
(Like maybe get_string was overridden to return the signature, or something...) 10:12
darbelo "07:00 <@bacek> which allocates new string", whatever it's doing there, it's teh allocation that's expensive. 10:13
Looking at the source it "Returns the short signature for the CallContext." 10:14
Austin Shouldn't that be a constant, and pretty much free? 10:15
darbelo Probably, right now it allocates and constructs the string at runtime. 10:16
Oh, wait. It's cached. 10:17
10:23 gaz joined
mikehh post-config FAIL - t/steps/init/hints/linux-01.t - Failed tests: 3-5 10:24
coretest FAIL - t/pmc/nci.t - Non-zero exit status: 2 - Parse errors: Bad plan. You planned 71 tests but ran 0. (PASS in test/smoke)
all other tests PASS (pre-config, smoke (#32607), fulltest) at r44874 - Ubuntu 9.10 amd64 (g++ with --optimize)
bacek darbelo, inside CallContext. Which created on every PCC call. 10:26
darbelo Oh. Ouch. 10:27
I see how that might be a problem...
mikehh I get the same test failures and passes with gcc and g++ (with or without --optimize) 10:40
going to try on i386 10:41
rebooting - bbiab
10:52 payload joined 11:08 lucian joined 11:10 mikehh joined 11:12 snarkyboojum joined
moritz there's something wrong with parrots GC behaviour 11:13
when I compile rakudo, it uses up all memory (about 3.5GB including swap space)
and makes the computer thrash like mad
but when I ulimit it to 1GB, it still works (a bit slow, but it does work)
so parrot uses huge amounts of memory that it doesn't actually need 11:14
we're talking about a factor of 3 here, at least
darbelo WTF? I've never seen it do that. 11:20
lucian i'm a newbie, what kind of GC does parrot use? (trac and google revealed nothing useful)
dalek kudo: 26a9a3e | (Solomon Foster)++ | src/core/ (2 files):
Merge branch 'series'
11:22
lucian allison: i get very weird behaviour for dict(one=2, two=3) and the has_mapping inside 11:25
darbelo lucian: homegrown stop-the-world mark and sweep.
bacek's trying to add bohem as an option in a branch right now. 11:26
lucian darbelo: right. boehm isn't particulary good either 11:27
darbelo His first attempt had some performance issues due to bohem not being precise. But I think he had found ways to make that work acceptably after the last gc encapsulation branch landed. 11:29
I don't recall what exactly was stoping him from merging the branch to trunk. 11:30
lucian the PyPy folks have quite a few nice generational GCs, perhaps some useful research
allison: pastie.org/864788 11:33
dalek rrot: r44875 | darbelo++ | trunk/t/steps/init/hints/linux-01.t:
[hints] Adjust icc flags test on linux to search for a flag we actually set.
11:38
kudo: 595ec0e | (Solomon Foster)++ | t/spectest.data:
Turn on basic series test files.
11:45
darbelo msg mikehh does r44875 fix your post-config failures?
purl Message for mikehh stored.
mikehh darbelo - yes - wtf is wd269/we167 11:48
darbelo Magic icc command line option. 12:03
The -wd??? options are warnign related, so I moved them to the appropiate config step. 12:04
12:10 cognominal joined 12:14 lucian joined
mikehh coretest FAIL - t/pmc/nci.t - Non-zero exit status: 2 - Parse errors: Bad plan. You planned 71 tests but ran 0. (PASS in test/smoke) 12:16
all other tests PASS (pre/post-config, smoke (#32611), fulltest) at r44875 - Ubuntu 9.10 i386 (g++ with --optimize)
12:20 bluescreen joined 12:26 sjn joined
Coke msg cotto - perhaps a little ascii-o diagram showing the layers of parrot with lorito in it. 12:29
purl Message for cotto stored.
Coke looks like the rm_dynoplibs_make branch is fixed. (darbelo++, yes?) - someone wants to merge that back to trunk, I'd appreciate it. 12:31
dalek TT #1508 created by parthm++: broken links on parrot.org 12:32
mikehh ok headed back to amd64 - bbiab 12:35
Coke ->
12:36 ruoso joined 12:40 iblechbot joined
lucian allison: i pushed a working but incomplete version of dict 12:57
darbelo Coke: ping 12:59
dalek TT #1509 created by dukeleto++: "new ['FixedStringArray'], -5" core dumps 13:05
13:09 mikehh joined
dukeleto 'ello 13:09
mikehh hi dukeleto 13:10
dukeleto - I am getting a failing test in coretest - t/pmc/nci.t which runs under test 13:11
dukeleto mikehh: howdy! i will see if that fails for me 13:12
mikehh I was just wondering if anyone else had the same problem (all other tests PASS)
13:12 rblackwe joined
mikehh it just fails for me with make corevm/make coretest 13:13
dukeleto mikehh: can you nopaste the full output of the test file?
mikehh since the recent adjustments to make corevm
it fails before any (sub)tests are run in the perl - ===Can't use string ("Test::Builder") as a HASH ref while "strict refs" in use at /usr/local/lib/perl5/5.10.1/Test/Builder.pm line 485 13:14
dukeleto mikehh: that is peculiar 13:15
mikehh but other tests use Test::Builder so I am not sure what it is
13:15 whiteknight joined
dukeleto mikehh: what does perl -MTest::Builder -e 'print $Test::Builder::VERSION . "\\n"' say ? 13:16
mikehh: does the same thing happen when you run the test by itself vs. as part of "make test/coretest" ?
Coke news.bbc.co.uk/2/hi/americas/8561707.stm 13:17
(nci) - does it help to move back the NCI_TEST dep from all to corevm ? 13:18
darbelo: bpon
... er, pong
mikehh dukeleto 0.94 - and yes both with prove and make corevm/make coretest - but it is ok with make world/make test
Coke mikehh: you should totally upgrade to duketo 0.97 13:19
dukeleto Coke: i hear it is still buggy
mikehh: i think maybe nci shouldn't be part of coretest, but i am not sure 13:20
Coke the cake?
purl somebody said the cake was a lie.
Coke I love you, purl.
purl Coke: huh?
dukeleto who is on first?
purl okay, dukeleto.
Coke second base?
dukeleto wow.
Coke who?
the guy on first?
purl the guy on first is who
Coke purl, you need help.
purl Coke: sorry...
mikehh othere tests use Test::More 13:23
Coke ah. 13:25
I added test::more lib specificially to get built by corevm.
might be missing a PBC somewhere, with a LTA error message.
dukeleto is nci supposed to be part of coretest? 13:26
should the creation of arrays of size 0 be allowed? when can that ever be useful? 13:30
mikehh damnit - I have to go and collect some paperwork in the centre of the city - parking is going to be a nightmare or something 13:32
anyway bbl 13:33
dukeleto mikehh: good luck
purl You'll need it.
dukeleto purl, go play in traffic
purl wanders off to dent some cars.
particle dukeleto: you still about? 13:35
dukeleto particle: ahoy
particle: do you know your gsoc link id? i guessed that it was 'particle'
particle where do i find this id you need? 13:36
yes, it probably is, let me check with a little help from you
dukeleto particle: hmm. well, it is the same link id that you used in last years gsoc
particle yes, where do i login?
socghop.appspot.com?
dukeleto particle: socghop.appspot.com/gsoc/org_app/ta...010/orgapp 13:37
particle link id: particle 13:38
dukeleto: is there a channel besides #soc-help that i should be in?
dukeleto particle: awesome, i guessed correctly. 13:39
particle: no, that is the only channel, for now 13:40
particle dukesnack
dukeleto particle: the app has been submitted
particle awesome. nice work!
Coke rant: drupal & trac both sucks.
*suck.
particle why this time, coke?
dukeleto Coke: i find trac usable, bit very much agree about drupal 13:41
Coke this overagressive caching in drupal makes it COMPLETELY UNUSABLE unless you're just browsing.
dukeleto particle: we should hear if we are accepted no later than "March 18, 2010 at 19:00 UTC"
Coke edit a page. save my changes. they don't show up unless I add ?drupal_sucks1
I go back to make another edit. THE EDIT PAGE IS ALSO CACHED
so the change I just made doesn't show up in the edit screen.
particle coke: either it's the caching layer (varnish) or your browser. are you using firefox? 13:42
Coke chrome. 13:43
particle i've found ff does some aggressive caching.
hrmm, i haven't seen that with chrome.
Coke (And I don't have this problem with any other server side technology. and if the app is not sending out the right caching directives, it's not the browser's fault.
dukeleto definitely has noticed lots of wonky chrome behavior lately
Coke gives up on TT#1508 and leaves it for someone else. 13:44
what a !@#$%^&*()_ pita.
(trac) and the auth stuff on trac is still broken. 13:45
"save" "you're logged out" "login" "ok, you're logged in with no challenge, but I forgot where you were, and oh, I saved those changes from last time."
particle: when I hit edit, my local proxy shows that I'm getting a 200 from the server, and that it's actually pulling data down. 13:46
and the /server/ is giving me the old, wrong, page that I JUST edited and saved a new version of. 13:47
particle coke: that points to varnish
Coke if I instead use www.parrot.org/node/2/edit?drupal_sucks1
I get the edit screen for that node with the correct content. 13:48
is varnish part of drupal?
particle create a support ticket for osuosl with this info, it should give them a good place to look and an easy way to recreate
Coke or part of our admin setup?
*admin's
particle no, it's a web caching layer
Coke bug opened, cc'd -directors 13:54
particle coke++. i hope they get this fixed for you. 13:55
why is Devel::Cover such a bear to install?
and why doesn't screen like my PgUp key? sigh. 13:56
Coke shift-pgup, perhaps? 13:59
particle in scrollback mode, screen doesn't respond to shift-pgup, and when i hit pgup, it exits scrollback mode and gives me '[5~' 14:07
dukeleto particle: Ctrl-A-[ will put you into copy-paste mode, where you can use j/k to go scroll up/down
particle my muscle memory is tied to pgup/pgdn 14:08
i can use arrows and jk, but i need to scroll through 10k lines
dukeleto particle: oh boy
particle yeah, screenlogs aren't ideal, either, with all the ^Ms 14:09
darbelo Coke: I can merge rm_dynoplibs_make for you if you have no further work to do there. 14:11
Also, you might want to ask for a windows (actually nmake) test before merging. 14:12
14:20 bubaflub joined
Coke I would, but whenever I ask for that, no one does it until I merge back to trunk anyway. =-) 14:20
darbelo JFDI++ 14:21
Coke Seriously, I would love to have it tested first.
darbelo As far as I can tell, we're safe. But I'm paranoid when it comes to makefile portablility. 14:22
Coke and trunk has ttbot, so we'll know soon enough.
(not like it's untested, just... immediately post-tested)
dukeleto hmm. it is a bug that when one .pmc file is changed, all .pmc's get re-compiled ?
s/it is/is it/
Coke dukeleto: yes.
dukeleto has it always been that way?
Coke because that doesn't happen. =-)
which pmc are you changing? 14:23
default?
purl rumour has it default is sub { } => just the same as not having a default, right
darbelo For dynpmcs yes, for regular pmcs, no.
14:23 mls joined
dukeleto Coke: i changed fixedfloatarray.pmc and all pmc's got regenerated 14:23
Coke dukeleto: did you edit that .pmc and just type "make" ?
dukeleto Coke: yep
Coke (and had you done a full make first?)
darbelo svn-- 14:24
dukeleto Coke: yes
Coke dukeleto: let me see if I can duplicate yoru bug.
dukeleto Coke: and i just got it to happen again with "touch src/pmc/fixedfloatarray.pmc; make"
darbelo Coke: it's allways been like that, AFAIR.
mls particle: regarding screen, that's probably because $TERM doesn't match your terminal
dukeleto Coke: after a full make
Coke unless the other pmcs are depending on that pmc file, there's no reason for that; it should be respecting the pmc inherits chain (plus a few that are depending on by everything) 14:25
particle mls: in screen, $TERM is screen. outside, it's xterm. 14:26
centos-5.4
dukeleto Coke: i don't think many (or any) pmc's depend on FFA. maybe something thinks they do?
Coke RFA does. 14:27
mls particle: what's the output of 'infocmp | grep kpp' outside of screen?
particle $ infocmp | grep kpp
knp=\\E[6~, kpp=\\E[5~, kri=\\E[1;2A, mc0=\\E[i, mc4=\\E[4i,
dukeleto Coke: ok, does that cause all other PMC's to get pulled in?
Coke nope. nothing else seems to depend on RFA.
dukeleto Coke: can you reproduce the issue? 14:28
Coke build is warning me with: /home/coke/sandbox/parrot/blib/lib/libparrot.so: undefined reference to `SUPER'
dukeleto: no, I cannot duplicate the issue.
ah. probably due to the SUPER error. 14:29
mls particle: does ^A:bindkey -m contain a :kP: line?
particle kN is set to stuff ^F, kP to stuff ^B 14:30
maybe that's it!
mls No, that's good.
particle hrmm
mls terminfo says that \\E[5~ is kpp (i.e. kP in termcap)
so \\E[5~ should be mapped to ^B 14:31
particle can i set those to C-u and C-f ?
...the vim commands for scroll up/down a page.
Coke needed a realclean. 14:32
mls Doesn't ^U/^F already work?
14:32 bluescreen joined
particle hrmm, yes, it does. 14:32
i want pgup to do what ^u does 14:33
ttbot Parrot trunk/ r44876 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/225555.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ )
Coke dukeleto: ok. realclean, my build works. I touch src/pmc/fixedfloatarray.pmc, It rebuilds FFA, RFA, and that's about it until after parrot is rebuilt and rebuilds all the pbcs.
mls If you press ^V and then PgUp, you get ^[[5~? 14:34
Coke so, it's just you. =-)
dukeleto Coke: ok, will look more into it
Coke feather.perl6.nl/~coke/mf shows the build log after I touch ffa.pmc
(that's with straight make, no -j)
and trunk@44875 14:35
particle mls: i have ^a remapped to ^z for screen btw. when i hit ^v PgUp, i get ^[[5~
the ^a remapping probably doesn't matter, but there it is. 14:36
14:38 payload joined
nopaste "particle" at 98.232.31.142 pasted "mls: my .screenrc" (161 lines) at nopaste.snit.ch/19912 14:40
mls Hmm, last idea: what do you get if you do ^A:echo $:kP:
dalek rrot: r44876 | darbelo++ | failed to fetch changeset:
Merge rm_dynoplibs_make to trunk.
rrot: r44877 | dukeleto++ | trunk (10 files):
[t][TT#1509] Prevent core dumps by preventing negative length array creation. Tests for FFA, FPA, FIA, FSA and FBA
Coke arg. all those prop changes are back. 14:41
someone who understands the new svn merging really needs to clean up our repository
particle mls: that shows [H in my status line
mls partile: argh, you have a bad line in you screenrc
darbelo Also, I broke the windows build.
mls particle: please remove the termcapinfo xterm 'kh=\\E[1~:kI=\\E[2~:kD=\\E[3~:kH=\\E[4~:kP=\\E[H:kN=\\E[6~' line...
and reattach 14:42
Coke ah, linkflags.
particle: can you suggest a fix on tt.ro.vutbr.cz/file/cmdout/225555.txt ?
dalek TT #1509 closed by dukeleto++: "new ['FixedStringArray'], -5" core dumps 14:43
Coke darbelo: guessing a pathing issue? 14:44
(since that link step used to work when invoked from inside src/dynoplibs.
darbelo It could be.
Coke hurm. looks like libparrot.dll would be created in the top level dir... 14:45
darbelo It can't link with libparrot.
particle mls++ # that did it! (cargo culting)--
Coke (the link step for libparrot.dll succeeded earlier in the build...)
particle coke: looking...
darbelo s/LIBPARROT/LIBPARROT_SHARED/ ? 14:47
Coke OH. 14:48
darbelo:
the old LIBPARROT in the subfile was -LIBPARROT = @libparrot_ldflags@
ttbot Parrot trunk/ r44877 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/225603.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 14:49
particle coke: you should be using libparrot.lib, not .dll
Coke the new one is a different config var.
rather, the one in the core makefile is a different config var.
14:50 brooksbp joined
Coke swap LINKARGS's $(LIBPARROT) to @libparrot_ldflags@ and that should do it. 14:50
"different things should be named differently"
easy thing to miss, though. 14:51
darbelo Testing...
purl testing is the best thing ever ZOMG
14:53 payload joined
darbelo Coke: works for me, lets see if it pleases ttbot. 14:56
dalek rrot: r44878 | darbelo++ | branches/rm_dynoplibs_make:
Branch has merged to trunk and is no longer needed at HEAD.
14:57
rrot: r44879 | darbelo++ | trunk/config/gen/makefiles/root.in:
[Makefile] Fix pasto that had us using the wrong libparrot when linking dynoplibs.
Coke ttbot? 15:02
purl ttbot is TapTinder build bot owned by mj41 and reporting tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk build errors. or a master of timing.
Coke darbelo++: 44879 is green.
darbelo tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ shows as 'not yet' 15:03
Coke whoops. green is a terrible color for not yet.
darbelo '-' instead of 'ok'
Coke yup. definitely misread it, I did.
mj41 Coke: fixed tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk 15:06
darbelo One 'ok' now...
15:11 Psyche^ joined
particle aha! thanks to getting my screen session fixed (mls++) i found out that Devel::Cover wasn't installing because it doesn't like being tested in parallel. 'export HARNESS_OPTIONS=; make test' works! 15:13
darbelo Both errors are now green. I'm calling this fixed. 15:16
Coke darbelo++
darbelo: if you're bored, you can work on the dynpmc target now. =-) 15:17
(I'll probably hit that this evening.)
darbelo All in all, faster than waiting for testers.
15:31 tewk joined
tewk chromatic++ dukeleto++ finishing up init_int 15:33
15:35 Andy joined
whiteknight I didn't think init_int would be such a huge hassle when I first proposed it 15:39
tewk It wasn't bad, I just ran out of time to rethink how new_p_*_i[c] should be written. chromatic did a fine job. 15:40
whiteknight has chromatic been around this morning? 15:42
Coke it's early yet for him. 15:47
whiteknight early? bah! I demand people work on MY schedule 15:58
NotFound init_int now works with new? Fine. What about root_new? 16:03
darbelo You are getting pretentious. 16:06
whiteknight root_new doesn't work? 16:07
darbelo If you keep it up you'll be demanding the vm stops segfaulting.
whiteknight segfaults are part of our tradition! our software heritage!
NotFound I'm looking, but asked anyway just to keep you en garde.
error:imcc:The opcode 'root_new_p_pc_ic' (root_new<3>) was not found. Check the type and number of the arguments.. 16:08
tewk NotFound, it should be trivial to write root_new_p_p_i its a quick combo of new_p_p_i and root_new_p_p_p 16:09
If no one bites at the karma, I'll do it. 16:10
So what do people thing about deprecating Fixed*Array ability to set size post creation?
darbelo I'm +0.1 on it. 16:11
NotFound tewk: I think we must solve before the issue with size 0. 16:12
darbelo It *does* say fixed on the name, but I don't care enough to think through it's implications :)
NotFound Currently setting size 0 is a nop, you can resize later. 16:13
I hardly call that a fixed size.
tewk NotFound, thats bad behavior you fix a Fixed* at size 0 it should always be size 0 16:14
darbelo nopaste.snit.ch/19915 for the obvious fix ;)
A size 0 array is rather unuseful thing. 16:15
NotFound darbelo: I think is highly useful, it avoids the need of treating zero as an special case. 16:16
tewk I'm advocating removeing set_integer_native entirely from Fixed* 16:17
You specify size only at construction time.
darbelo +0.5
purl 0.5
darbelo tewk: ask the list. 16:18
NotFound I think is a liitle early when init_int usage is still in experimental ops. 16:19
dukeleto 'ello 16:21
NotFound A quick winxed benchmark shows less than 1% speed improvement using init_int, but no wonder, the compiler and the tests use very few fixed size arrays. 16:22
16:23 shockwave joined
shockwave Hi all. 16:23
davidfetter hi
dukeleto NotFound: yeah, i think it is mostly easier to type and more intuitive. 16:24
tewk Parrot needs more types that dont resize and immutable types. These are important for parallelism performance 16:26
NotFound An InmutableString PMC? 16:27
dukeleto tewk: i think that is the purpose of parrot-data-structures, i.e. to experiment with new types that hopefully make it back to core
shockwave I can't think of a good reason why I would want to create a NULL variable every time I want to pass null to a sub. Is there any reason it would be a bad idea for me to create the a NULL pmc once, store it in the HLL global space, and fetch that when I need to pass null to subs: set_hll_global 'nil', $P0; $P1 = get_hll_global 'nil'; 'foo'($P1); 'bar'($P1)
16:27 payload joined
NotFound shockwave: what is the advantage? I just see generating more code. 16:28
shockwave Actually, I would use the same null object everywhere, not just to pass to subs.
NotFound: The fact that I don't have to create a new 'NULL' object every time.
NotFound: And the way I'm describing, it's actually less code. 16:29
s/it's/is/
NotFound shockwave: I think 'null $P1' is short enough.
shockwave NotFound, is not about that. I'm not really going to be working with the generated code, except while developing the compiler itself. It's about what's more efficient. 16:30
NotFound shockwave: measure it.
shockwave NotFound: The answer should be clear. One is better than the next, for X reasons, and someone here ought to know. 16:31
NotFound: I'll post some code, for a better illustration.
NotFound, btw, I'm not trying to be agressive, if I sound like it :) 16:32
davidfetter so eggyknap++ did yeoman work yesterday on pl/parrot, but there's clearly something not quite right
NotFound shockwave: null $P1 just put a value on a register. Is hard to beat that both in shortness and in performance.
16:33 lucian joined
davidfetter github.com/leto/plparrot/tree/load_pir 16:33
dukeleto davidfetter: what is up?
davidfetter well, in particular, i'm not sure what embed_string.h was supposed to do, or what should be happening instead 16:34
nopaste "shockwave" at 76.119.137.239 pasted "Code generation for 'bar()' call." (58 lines) at nopaste.snit.ch/19916 16:36
shockwave NotFound, the code at ^^^ shows how I arrived at the conclusion. 16:37
In the HLL snippet, the important part is the call to bar()
In version 1, $P5000004 and $P000006 are NULL instances. 16:38
NotFound You are using new 'Null', instead of the null opcode.
shockwave In version 2, I realized I can reuse the same register for nil.
In version 3, I realized that I don't have to create Null everytime. So, I only fetch it once, and use it 2 (could be more) times. 16:39
NotFound, I can substitute the call to get_hll_global for the opcode easily. Thanks for the tip. 16:40
But, is there any possible issues with using the same null object everywhere I use null in the HLL?
Let me know if I'm not making sense anymore. 16:41
NotFound shockwave: PMCNULL is a singleton, new 'Null' gives you always the same object. The null opcode does the same, but fast.
shockwave NotFound: Cool. That means the answer is clear. In each sub, store null in a register once, using the null opcode, and use the same register everywhere. 16:43
NotFound: Thanks
NotFound Think of it as a NULL that throws exception when used instead of segfaulting. 16:44
shockwave NotFound: oh, one more question. doing $P1 = null; is the same as using the opcode you mentioned before, correct?
NotFound shockwave: yes, the = syntax is pir sugar. 16:45
shockwave NotFound: Cool. Thanks again.
16:47 kjeldahl joined 17:10 iblechbot joined 17:29 zpmorgan joined 17:41 cognominal joined
dalek rrot: r44880 | tewk++ | trunk/src/ops/experimental.ops:
root_new_p_p_i
17:55
tewk NotFound, tag you're it, you want to add tests? 17:59
whiteknight fperrad: ping 18:01
NotFound tewk: I'll test usage in winxed first.
tewk NotFound, I didn't add init_int for speed, I added it for safety in parallel programs, but chromatic thinks it could improve the performance of CallingContext. 18:02
whiteknight what does the root_new opcode do? 18:03
tewk If fixed arrays are still used in PCC it could help there too, but the performance difference may be small.
NotFound tewk: shortening some code is good, also
tewk needs to commit his changes to the thread subsystem some time.
NotFound whiteknight: always start keying from root, regrdless o current HLL 18:04
whiteknight tewk: make a branch. I would love to see the changes
purl msg fperrad the setup.nqp script for kakapo doesn't do anything on "install". Any pointers about why not? www.gitorious.com/kakapo/kakapo/blo.../setup.nqp 18:05
purl Message for fperrad stored.
tewk whiteknight, its minimal right now. but the idea is we need different PMCs that represent lightweight threads(futures) that share the same GC and heavyweight threads (places) that are completely separate interpreters that communicate only through message passing. 18:06
whiteknight ah, okay. Like the difference between "threads" and "fibres" on windows
fibers 18:07
tewk thats differnet, lightweight threads is a bad name.
my futures are kernel threads scheduled by the OS. so you get true parallelism.
whiteknight gotcha 18:08
tewk We also need to add green threads(user threads) at some point.
whiteknight what would be the difference between green threads and places in this model?
tewk green threads are not scheduled by the os, they would be scheduled by parrots concurrency scheduler 18:10
Our embedding interface needs extending here is a prototype, comments? github.com/leto/plparrot/commit/ac6...01e2e15b23 18:11
whiteknight tewk: all sounds very cool. I would love to see a design doc or even a branch sometime with the ideas 18:12
NotFound tewk: PARROT_EXPORT should be PARROT_API 18:15
tewk NotFound, embed.h doesn't use PARROT_API, there was even a ticket to remove all PARROT_API references. From the list archives it sounds like PARROT_API was removed until an embedding api stablizes at which point we might bring it back. 18:19
I wouldn't say we have a stable embeddign api yet.
NotFound tewk: yes, but that looks like an stabilizing step. 18:20
dalek parrot: 38c47d2 | (David Fetter)++ | HACKING.parrot:
Started on parrot hackery.
18:21
parrot: 0970b81 | (David Fetter)++ | HACKING.parrot:
Fixed up wrt. -j arguments.
NotFound tewk: Class '[ 'parrot' ; 'FixedIntegerArray' ]' not found
fperrad whiteknight, the setup.nqp of Kakapo was writen by Austin. I just fix the distutils library when called from NQP. 18:23
tewk NotFound, does just plain root_new work? 18:24
NotFound tewk: yes
dalek tracwiki: v25 | tewk++ | GitObjections
tracwiki: trac.parrot.org/parrot/wiki/GitObje...ction=diff
whiteknight fperrad: it calls setup() 18:25
fperrad: to help with debugging, is there some kind of way to turn on diagnostic messages in the distutils library? 18:27
fperrad whiteknight yes, setup() is the entry point of distutils
whiteknight because it fails silently, and I'm trying to figure out why
dalek rrot: r44881 | mikehh++ | trunk/src/pmc/fixedpmcarray.pmc:
fix codetest failure - there should be one space or a newline after a comma
18:28
tewk NotFound, what about root_new [ 'FixedIntegerArray' ], 10
NotFound tewk: that is not root at all. 18:29
tewk yeah, but I bet it works because of how I wrote it.
NotFound Shit, we are still using a global class hash? 18:32
fperrad whiteknight, Kakapo produces only pbc files. There are installed only if an 'inst_lib' is set 18:34
whiteknight fperrad: okay, so if I add an inst_lib with an array of .pbc file names, they will get installed? 18:35
dalek rrot: r44882 | mikehh++ | trunk/src/ops/experimental.ops:
fix codetest failure - no documentation for root_new(out PMC, in PMC, in INT) - boilerplate only
18:44
18:46 chromatic joined
whiteknight fperrad++ # inst_lib works! Thanks! 18:47
hello chromatic 18:49
chromatic hello 18:51
whiteknight get my emails last night? I think that fix_hll_mmd branch is doable along those lines
chromatic I saw it, but I haven't had a chance to review the code yet. 18:52
dalek kapo: fce690d | whiteknight++ | setup.nqp:
update setup.nqp to properly install files. Thanks to fperrad++ for guidance.
18:53
whiteknight okay, that's fine. As I mentioned, the patch doesn't even build PGE. We do have some questions about order of resolution to worry about
mikehh make corevm/make coretest FAIL - t/pmc/nci.t - No tests run - remaining tests PASS - (PASS in make world/make test) 18:59
all other tests PASS (pre/post-config, smoke (#32616), fulltest) at r44882 - Ubuntu 9.10 amd64 (gcc with --optimize)
19:04 joeri joined
whiteknight purl msg Austin I pushed a commit to get kakapo installing properly. I want to use it to implement the test suite and harness of the parrot-linear-algebra project soon. Could I pick your brain about how to do that? 19:05
purl Message for austin stored.
Austin whiteknight: ?
purl, messages
whiteknight ah, I didn't see you standing there
Austin :)
whiteknight++ # commits = karma
whiteknight I already got karma for it. Don't need to double-dip 19:06
Austin Did you? I didn't know kakapo was on the karma list.
Well, then karma for being an early adopter..
What's the question about pla?
whiteknight backscroll a few lines
I want to implement the test harness and test suite there using kakapo's unit tests
Austin Okay.
whiteknight so I'm just wondering how to go about doing it 19:07
Austin Grab the top N lines from one of the files in the t/ directory.
That's what I do.
whiteknight Kakapo's test tools arent TAP-based, correct?
Austin Kakapo emits tap.
whiteknight oh, it does? So I can use the same harness?
Austin But it does it differently.
Yeah. 19:08
whiteknight Austin: Okay, I want the INIT blocks, the MAIN sub, and the set_up() sub in my copypasta?
Austin The kakapo UnitTest library treats each test case as a single test. So if you have three assert_...() statements, they all get rendered into a single ok 1 - Verify ... TAP entry 19:09
whiteknight okay, nice
I like this because it's much more similar to NUnit and the unit tests in visual studio 19:10
Austin Yes. You want to load the lib, pick your own class name :), then do the boilerplate MAIN (which just figures out what class it's a part of). The set_up is optional.
whiteknight ah, okay
Austin Also, you'll want to use the UnitTest::Assertions module
Do you have the latest master? 19:11
whiteknight yeah
Austin Can we look at t/Program.nqp, then...
whiteknight sure
Austin At line 16 there's nothing. That's where you would declare something (I usually call it $!sut) that you were going to initialize in set_up 19:12
$!sut := My::Class.new
Line 14 has the test class name. Pick your own.
Line 28 is an example of how to bypass the TAP and view the output directly (comment out the suite.run and just invoke the test method). This kind of sucks, and I'm working on a cli way.. 19:13
Everything after line 30 is testcase specific. I usually start with the same test_new(), just to make sure things work. 19:14
whiteknight Austin: Okay, so how does it know which methods to run as tests? 19:17
Austin The ones that start with test_
whiteknight ah, that's what I was missing 19:18
Austin Of, if you prefer, you can start like testFoo 19:19
or test99
whiteknight gotcha, so long as the prefix is "test"
Austin Basically test as a separate word at the front of the name. (So *not* testing)
whiteknight ok
ls
Austin m/ test [ :digit: :upper: _ ] 19:20
/
whiteknight okay
okay, my first test file uses Kakapo, runs, and passes
so that's a good first step 19:21
Austin nopaste ?
purl it has been said that nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) 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
whiteknight give me a second, I'll nopaste it
Austin I'm gonna put it up as a template. 19:22
nopaste "whiteknight" at 173.12.37.77 pasted "first kakapo-based test in pla, for Austin++" (29 lines) at nopaste.snit.ch/19917
whiteknight it's a stupid-simple test 19:23
Austin Always start with a pass.
whiteknight but, it's necessary to make sure we can load the dynpmc and fail early or all the other tests fail with cryptic error messages
Austin One thing you should be wary of is that the test name and the assertion have different purposes. The test name, or the string you pass to verify_that(), is used as the ok/not ok comment. The assertion message shows up as a diagnostic. 19:25
whiteknight okay 19:26
Austin So your assertion messages should be diagnostic (fix-whats-wrong) rather than positive (declare-what's-right)
whiteknight gotcha
Austin "expected two entries in array"
whiteknight these matrix types have methods that iterate a callback over all elements. I'm very much looking forward to using mocks for that 19:27
Austin Heh. Me too.
That should be a good workout for Cuckoo 19:28
whiteknight I'm definitely going to push some bounds
Austin :)
wtf? Your test just passed 19:29
whiteknight ...wut?
isn't it supposed to?
Austin Not on my box. 19:30
Unless PLA is part of core?
whiteknight definitely not part of core
Austin Ahh.
whiteknight okay, we's gots some debuggering to do
Austin loadlib returns undef, not null.
whiteknight oh, damnit
that's stupid
Austin pir::trace++
And of course, why would we document the return codes? 19:31
dalek kudo: d07f647 | (Martin Berends)++ | src/Perl6/Module/Locator.pm:
[Perl6/Module/Locator.pm] insert a / between path and filename if the name occurs after a :: separator
whiteknight so I would do an assert_not_instance_of($pla, "Undef")
Austin Yeah, dynlibs.c explicitly creates the undef.
whiteknight as they say on TEH INTERNETZ: FAIL 19:32
Austin For now, not_isa or not_instance_of is right. 19:33
Or you could add "assert_defined"
:)
whiteknight true
Austin: in NQP, how do I include another NQP file?
use?
Austin You don't.
whiteknight .....damnit 19:34
Austin My use() assumes the file is loaded, and imports any symbols the other module exported.
But you can load the bytecode.
whiteknight fuggit. I'll just copy+paste the code
Austin The other choice is to compreg to get the nqp compiler, and then ... 19:35
What are you trying to do?
whiteknight ...and kakapo is going to get a loader class to do this when?
Austin After I extract the use cases from my first user...
... and then collect some round tuits.
whiteknight All my tests are going to have an identical header: load kakapo, setup the UnitTest, and load the linalg library 19:36
I would like to include in a file that does this automatically, in like a :load Sub
and then every test has only one or two lines of boilerplate instead of two dozen
Austin Okay.
You can't do #include in nqp. 19:37
whiteknight yeah, no language is perfect
:)
Austin So you could hide the first init block.
whiteknight I saw a hilarious example one time of a "program" that wrote out the lyrics of 99 Bottles of Beer using only C preprocessor directives
Austin Yeah, I've seen that. Proving that C, or at least the C preprocessor, is a purely functional language.. 19:38
darbelo 99-bottles-of-beer.net/
whiteknight that's the on
one 19:39
darbelo s/one/hundeds/
Austin That is sick.
darbelo Austin: check out th one in Malbolge.
*thats* sick.
Austin I wasn't complaining about the C, but about the site. 19:40
PerlJam heh, there's an old parrot version I put up in 2005 19:41
you guys should submit alternate parrot versions
Austin Mmm....socialists... failblog.org/2010/03/10/grammar-fail/ 19:42
whiteknight Austin: what's the difference between assert_same and assert_equals? 19:47
the former a reference compare? 19:48
Austin Yes.
opcode same vs iseq
whiteknight I didn't know we had a "same" opcode 19:49
Austin Of course we do.
whiteknight of course, we have ALL the other possible opcodes
Austin sings "One of these things isn't like the others, one of these things just doesn't belong..." 19:50
whiteknight Austin: I don't know if you were here for it, but not long ago we had an "hcf" opcode
Austin Hell, we had a factorial opcode. How could we not have a "same" opcode...
whiteknight had?
purl had is like HAND, but BOFHier.
Austin Isn't that dead?
whiteknight I think we still have "fact"
hcf is gone, thankfully
I'll be damned if there was a good way to test it
I wonder if NQP supports multidimensional array indexing 19:51
Austin Well, Kakapo does.
my $key := Key.new(...)
say( $array{$key} )
whiteknight that's hardly the same 19:52
Austin I do what I can..
whiteknight and you've done quite well heretofore
you like that? I feel threatened by your vocabulary so I'm whipping out the big guns 19:56
Is there a way to specify that tests should run in a partcular order? 19:57
20:00 bacek joined
Austin whiteknight: No, the order is deliberately random. (Although not random enough.) 20:00
purl okay, Austin.
whiteknight what do I need to do to make my type CharMatrix2D instantiable using the syntax "my foo := CharMatrix2D.new;"? 20:04
using("CharMatrix2D")?
Austin What's that type? a pmc? 20:06
whiteknight yeah 20:07
Austin Hmm... 20:08
You could use Parrot::new( 'CharMatrix2D' )
Or P6metaclass.register_pmc_type( 'CharMatrix2D' ) 20:09
(which would then allow CharMatrix2D.new() calls
whiteknight ah, okay. 20:10
Austin whiteknight: code.google.com/p/kakapo-parrot/wiki/UnitTest You're more famous than you already were. 20:16
whiteknight w00t
awesome page 20:25
Austin You going to do assert_(not_)defined for me? 20:27
whiteknight yeah, I can add that
I'm picking my way through translating a test file right now
Austin okay, cool. 20:28
What kind of test file?
nopaste "whiteknight" at 173.12.37.77 pasted "test problem for Austin++" (23 lines) at nopaste.snit.ch/19919
whiteknight I'm translating the whole test suite of pla to use kakapo-based tests 20:29
dukeleto whiteknight: wow. nice
whiteknight right now it uses "NQP", but every single test is Q:PIR{}
Austin Heh. Needs a semicolon at the end
Q:PIR { };
whiteknight I'm running into problems that NQP never calls get_string_keyed_int like I am trying to test, since all variables are PMCs 20:30
so $c[0] = "ABCD" calls VTABLE_set_pmc_keyed_int
...which is why I need to use Q:PIR for this stupid test to make sure I exercise the correct VTABLE
Austin++ # semicolon works 20:31
Austin I think you can do that with pir::set__SPI
whiteknight yeah, maybe
purl it has been said that yeah, maybe is what i need for optional positionals
whiteknight shuddap purl
Austin But maybe not if it's a key.
whiteknight that's the problem. For matrices I really need 2-d keys, and I need to use a shitload of them 20:32
so bulky "new Key" syntax isn't going to be any good
Austin Create a sub: 20:33
Or better yet a method.
whiteknight like I said, all the tests are already in Q:PIR form. so it's almost zero effort to keep them that way if it's a hassle 20:34
Austin Okay.
whiteknight Austin: how to mark a test TODO?
Austin Heh. 20:35
I dunno.
whiteknight well, in a pinch verify_that("# TODO"); works 20:36
Austin Should the whole test be todo, or just one assertion?
whiteknight the whole test
purl i think the whole test is sql only
Austin Dude! That's clever
whiteknight++
whiteknight I imagine making just one assertion todo is not easy
I'm also pleased to say that in Q:PIR-land, assert_equal works with Parrot native strings 20:37
shockwave Is it fair to say that 'self' can be used anywhere a PMC register can appear? 20:38
Austin Yes.
shockwave Austin, that's for me, right?
Austin shockwave: yes. self is an automatic .local pmc
whiteknight shockwave: funny story. "self" is really just a ".local pmc self"
20:38 lichtkind joined
whiteknight so it is a pmc 20:38
shockwave Cool, thanks both.
Austin shockwave: note: that's .local, not .lex. If you want a lexical variable self, you have to DIY
lichtkind any hints what i could add to www.perlfoundation.org/perl6/index.cgi?parrot ? 20:39
thanks
shockwave Austin, I haven't had to use .lex yet. But I'll keep that in mind for the future.
Austin Whiteknight: At the assertion level, I could do: assert_equal( $a, $b, 'a and b are not equal', :todo('Equality is overrated') );
whiteknight Austin: yeah, I suppose that's cool too
would add a lot of checking logic to all of the assert_* functions though 20:40
Austin But I'm going with your whole-test idea.
whiteknight for now it's the most important for my needs
bacek ~~ 20:43
dalek rrot-linear-algebra: 31b7cbb | Whiteknight++ | t/sanity.t:
convert t/sanity.t to use Kakapo's unit test framework.
20:45
purl I don't know how to convert t/sanity.t to use Kakapo's unit test framework..
dalek rrot-linear-algebra: 5516941 | Whiteknight++ | src/pmc/charmatrix2d.pmc:
some changes to charmatrix2d. set_string_keyed* and set_pmc_keyed* methods now act like string-setters, while number/integer variants act element-wise
rrot-linear-algebra: 5e99208 | Whiteknight++ | t/pmc/charmatrix2d.t:
migrate the charmatrix2d tests to use kakapo.
rrot-linear-algebra: 2bb1210 | Whiteknight++ | t/sanity.t:
fix sanity.t to actually test what I want. loadlib returns Undef, not Null, on failure. Austin++ for the catch
Austin Damn, purl. I didn't know you were working on that.
particle somebody please teach purl to ignore dalek!
Austin Is that what that is?
dukeleto particle++ 20:46
Austin I occasionally see spontaneous messages from purl...
lucian particle: no, teach it to understand dalek instead
Austin I thought she was getting smarter.
lucian s/it/her/
dukeleto Austin: purl reacts to commit messges. Someone thought it was a good idea, evidently
lucian i'd love to see a conversation between purl and dalek
Austin lucian: Stick around. You will.
lucian i got my phenny bot to talk to a sister once, but i did it on purpose 20:47
darbelo dukeleto: If purl doesn't react to dalek's messages whe can't keep track of commit karma. 20:48
dukeleto karma dalek
purl dalek has karma of 9
bacek msg cotto More grammar bugs: { goto OFFSET(argc + 2); }
purl Message for cotto stored.
cotto_work hi
purl hello, cotto_work.
bacek aha!
dukeleto darbelo: i am sure it is possible to make it count karma, but not talk to dalek. 20:49
purl, you have a big mouth
purl dukeleto: i'm not following you...
bacek cotto_work, also JUMP handling in C emitting
dukeleto purl, big mouth is YEAH I HAVE ONE
purl OK, dukeleto.
darbelo dukeleto: she could not *reply* to dalek, but she should definitely listen to him.
projectname: commit_id | author++ | (touched flies):
dukeleto darbelo: agreed 20:50
cotto_work bacek, what do you mean about jump handling? 20:52
lucian karma lucian 20:53
purl lucian has karma of 1
whiteknight Austin: doesn't look like tests in t/UnitTest/*.nqp are run as part of the normal test suite 20:54
ls
dukeleto rm -rf /
purl rm -rf / is the oldest warhorse in the book
Austin Yeah, I turned them off. I think the tests were old. 20:55
whiteknight ah, nevermind. They get moved to t/bootstrap?
Austin The bootstrap tests are minimal tests, to get the unittest code working.
The "good" tests should be in t/UnitTest
dalek rrot: r44883 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Actions.pm:
Add ';' after implicit goto_next
rrot: r44884 | bacek++ | branches/ops_pct/compilers/opsc/src/Ops/Compiler/Actions.pm:
Fix generating PAST
whiteknight Austin: assert_defined and assert_not_defined committed and pushed. Enjoy 20:56
Austin You rock.
purl Dis is the drum
nopaste "bacek" at 114.72.185.13 pasted "JUMP handling b0rked for cotto++" (9 lines) at nopaste.snit.ch/19920 20:57
bacek $dayjob time 20:58
see you!
20:59 theory joined
dalek kapo: e350825 | whiteknight++ | (2 files):
add assert_defined and assert_not_defined, plus tests (though I don't think these particular test files run as part of the normal suite).
21:00
whiteknight ...and with that, I'm OUT
Coke rakudo: "what?".say 21:31
Austin No bot for you! 21:32
cotto_work coke++
Coke cries. 21:34
21:45 AndyA joined
Coke msg chromatic - the biggest single problem I have with rakudo right now is build time. 21:47
purl Message for chromatic stored.
Coke msg chromatic (if you're looking for pain points) 21:48
purl Message for chromatic stored.
PerlJam Coke: you're fine with the memory consumption though? 21:52
Austin "biggest single problem" =/=> "only problem" 21:53
chromatic I think memory consumption hurts build time. 21:55
Coke PerlJam: only on my osx box. everywhere else it dies.
21:58 pjcj joined
shockwave I just read that namespaces are PMC objects. So am I right in thinking that to emulate static class variables in a HLL, i could get the namespace object that represents the class and do: getattribute nsObj, 'attName' ; ? 21:59
cotto_work chromatic, do you have a little time to give input on an expanded Lorito roadmap? 22:02
gist.github.com/329720
chromatic Will do in a bit, cotto_work. 22:04
cotto_work thanks
Feel free to edit directly
22:06 snarkyboojum joined
NotFound shockwave: nsObj['attName'], I think. 22:09
shockwave: or get_global, if used inside the namespace, and you don't need to get the ns object. 22:10
shockwave NotFound: Nice. I was mostly concerned if there was a reason *not* to store attributes in ns objects. 22:11
NotFound, thanks.
NotFound shockwave: you'll need to use addattribute first, and I think that in order to do that you must define your own namespace class. 22:13
Austin pmichaud: Is there a way in nqp to tell a lexical block that it should have a 'self' lexical?
shockwave NotFound, define my own namespace class as in within C? 22:14
Austin shockwave: You could just put it in a namespace global 22:15
My::Class:variable := 1
My::Class::variable := 1
The NameSpace pmc defines add_var() method for this
shockwave Austin, That's actual PIR syntax? 22:16
Austin nqp
shockwave Austin, I'm not using nqp.
Austin Pir would be sth like $P0 = get_hll_global [namespace;path], 'variable'
cotto_work github++
Austin And set_hll_global [], var, $P0
shockwave Austin or NotFound: So in order to use the addattribute method, I would have to write some C? 22:17
The reason I would preffer the addattribute method is to have my own a bit more consistent. 22:18
my own code*
Austin Give it a try.
NotFound shockwave: a pir class derived from Namespace will do the job, I think.
shockwave NotFound: I'm sorry, I don't know what you mean by 'derived from Namespace'. 22:19
NotFound But I think that usage is not tested, don't know if it work well.
shockwave: inheriting from it.
shockwave NotFound: Do you mean a) derrived from the 'Namespace' pmc, if there is one, or b) write some C class that derrives the internal Namespace object? 22:20
NotFound I tend to use C++ jargon, base and derived.
shockwave NotFound, I'm all C++ too.
NotFound, I'm not sure if we're talking about C or PIR, though. 22:21
Austin You'll have to extend the namespace, since it doesn't support set_attr
NotFound shockwave: no, a pir class that inherits from the Namespace PMC.
shockwave NotFound, ok, gotcha.
Austin, thanks.
nopaste "Austin" at 68.39.12.202 pasted "Trying to attribute-ify namespaces" (4 lines) at nopaste.snit.ch/19922
NotFound But you must have the namespace in pir in order to write methods, so there is a chicken and egg problem and I don't know if there is a solution. 22:22
shockwave NotFound: I'll mess around with it. I'll post something whether I was successful or not. 22:23
22:25 Hunger joined
dalek kudo: eac348a | (Solomon Foster)++ | src/core/operators.pm:
CHEAT: Directly implement Whatever versions of the most common &infix:<+> and &infix:<-> operations, so that we have them available even though the full Whatever closure code is not done.
22:28
kudo: 2cdf434 | (Solomon Foster)++ | t/spectest.data:
Turn on series.t.
kudo: 6e6096d | (Solomon Foster)++ | src/Perl6/Module/Locator.pm:
Merge branch 'master' of git@github.com:rakudo/rakudo
rrot: r44885 | jonathan++ | trunk/src/pmc/os.pmc:
[os.pmc] Correct an oversight in the Win32 implementation of readdir - should handle being passed directory name that already has a trailing slash.
22:33
22:36 PacoLinux joined
Austin If this works, I'll have to give Pmichaud a big smooch. 22:40
Whew! Thank God, a bug. 22:42
cotto_work I'm sure pmichaud will be relieved to see that too. 22:43
Austin ayup 22:44
22:46 cognominal joined 23:13 cognominal joined
dalek kudo: 73cc9f2 | jonathan++ | src/Perl6/ (2 files):
Implement need and import, and make use just boil down to calls to the two of them.
23:20
kudo: 5faf418 | jonathan++ | build/PARROT_REVISION:
Bump PARROT_REVISION to get Win32 readdir fix.
kudo: dab10dd | jonathan++ | src/Perl6/Module/Locator.pm:
Fix for Win32 - stat with a trailing / on Win32 doesn't work out so well.
kudo: 69ce6d7 | jonathan++ | src/Perl6/Module/Loader.pm:
If there's no PIR pre-compiled file to hand, use the .pm instead. Still need to do checks for which is newer, and generating the PIR file if we can haz write access. Also, awesomize module not found error to show any version and authority if they are passed.
23:23 jan joined 23:24 davidfetter joined 23:28 davidfetter joined
cotto_work seen whiteknight 23:35
purl whiteknight was last seen on #parrot 2 hours, 34 minutes and 6 seconds ago, saying: ...and with that, I'm OUT
lucian seen allison 23:36
purl allison was last seen on #parrot 1 days, 1 hours, 51 minutes and 5 seconds ago, saying: Coke: also true [Mar 10 21:45:08 2010]
chromatic Nobody in here but us working peeps. 23:37
cotto_work seen cotto 23:39
purl cotto was last seen on #parrot 13 hours, 57 minutes and 41 seconds ago, saying: night