Camelia, the Perl 6 bug

IRC log for #parrot, 2011-05-12

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 whiteknight (and it's a mess because we might tailcall into IMCC, and IMCC treats the interp as it's own personal dumping ground)
00:01 plobsing whiteknight: I thought it didn't do that anymore.
00:01 whiteknight plobsing: it might not, but I'm not prepared to remove any of that safety code
00:02 whiteknight plobsing: I think it still does, especially for :immediate and that kind of stuff
00:03 plobsing IMCC calls into libparrot to manage :immediate and :postcomp. if those screw things up, that's parrot's fault.
00:03 whiteknight I have to look at it all again
00:03 whiteknight actually, IMCC isn't an NCI PMC anymore
00:04 whiteknight so the issue might be moot
00:04 NotFound If :immediate messes with the current context, it should stopping doing it and create its own.
00:04 whiteknight although IMCCompiler uses that tailcall code
00:04 NotFound :immediate invocation in imcc, I mean.
00:04 whiteknight we can try removing that. It hasn't been high on my priorities list
00:07 NotFound I'm sure :immediate invocation should not be speed-critical in any reasonable parrot usage. Optimizing by complicating other parts is not right.
00:07 whiteknight Sub.invoke perplexes me
00:07 whiteknight why is the lexical/autoclose logic in there?
00:07 whiteknight and the lexpad stuff?
00:08 whiteknight I feel like setting up lexicals and outers should be done by the invoke opcodes, and be in place before we ever get to Sub.invoke
00:09 whiteknight like chromatic points out, eventually we will want to have multiple types of invokable PMC, and we will want that logic factored out
00:11 theory left #parrot
00:11 theory_ joined #parrot
00:13 kid51_at_dinner is now known as kid51
00:13 theory_ left #parrot
00:13 theory joined #parrot
00:13 * kid51 does cage cleaning on recent trac tickets
00:14 whiteknight brb, have to restart the computer
00:14 whiteknight left #parrot
00:18 whiteknight joined #parrot
00:18 spinclad joined #parrot
00:19 lucian_ left #parrot
00:20 plobsing We also want to slim down our Sub PMCs. They're a convenient place to hang all sorts of innappropriate info, so they're overly bloated
00:21 whiteknight plobsing++ I couldn't have said that any better myself
00:21 sorear what's worse is that the clone/capture_lex combo copies the entire structure
00:22 kid51 seen moritz?
00:22 aloha moritz was last seen in #perl6 3 hours 14 mins ago saying "of course web frameworks can help you with it".
00:27 plobsing sorear: our subs are 23 machine words in size and track information like "the vtable slot that this sub should go in"
00:27 plobsing oh misparsed
00:28 theory left #parrot
00:32 jsut joined #parrot
00:32 * whiteknight is extremely impressed by Unity and Ubuntu 11.04 on first blush
00:33 kid51 Hmm, I'm wondering whether our current Trac problems mean that people who no longer have current passwords will not receive email notifications of additions to tickets (e.g. "cc"; e.g. new posts to tickets they originally created).
00:37 jsut_ left #parrot
00:40 NotFound Looks like :call_sig is not handled well in the caller side.
00:41 whiteknight NotFound: I did the initial implementation of :call_sig, and I know it's not good
00:41 whiteknight it was a quick prototype and we never went back to improve i
00:41 NotFound I mean, not handled at all.
00:41 Coke left #parrot
00:42 Coke joined #parrot
00:42 NotFound Uh... /* EXPERIMENTAL! This block adds provisional :call_sig param support on the callee side only.
00:42 NotFound We have ben warned ;)
00:44 whiteknight heh, I know it's ugly
00:44 whiteknight I spent a whole 10 minutes on it
00:47 NotFound param_count - 1 isn't always 0 in that branch, or I'm misreading something?
00:48 whiteknight NotFound: if we have :call_sig, it should be 0. You can only have :call_sig, no other parameters
00:48 whiteknight I think we check that in IMCC, which is bad
00:49 NotFound whiteknight: it is in the esle part of: if (param_count > 2 || param_count == 0)
00:49 NotFound else
00:50 NotFound Oh, never mind.
00:50 whiteknight I don't know
00:50 NotFound It may be an invocant in case of method calls.
00:50 jsut_ joined #parrot
00:51 NotFound I've misread > as >=
00:52 NotFound Eh, no... I just need to sleep %-)
00:52 whiteknight :)
00:52 whiteknight that code is terrible, don't read it too hard
00:52 NotFound The point is, without support in the caller side we can't do proof of concept.
00:53 whiteknight we can do half. We can do it on the callee side
00:53 NotFound Well, we can, by adding an indirection, giving less meaning to the tests.
00:54 NotFound Testing only the callee is almost trivial.
00:54 NotFound function test(args[call_sig])
00:54 NotFound {
00:54 NotFound say('test');
00:55 NotFound say(args[0]);
00:55 NotFound }
00:55 whiteknight this proof of concept would only prove that the mechanism works. It doesn't show us speed because we still use a signature and still hit fillparams
00:55 whiteknight fill_params
00:55 jsut left #parrot
00:55 NotFound whiteknight: but it will show if filling the params with pir ops is fast enough.
00:56 whiteknight true. It shouldn't be any slower
00:57 whiteknight I want to add a 2-argument invokecc opcode to take a CallContext, and then we can start doing real tests
00:57 NotFound And the support in the caller can bypass fill_params almost completely, like it does for the callee side.
00:57 whiteknight and I can add in a get_call_context op for the callee
00:57 whiteknight if we hand-roll the callee, we don't need to use get_params
00:57 NotFound An experimental op will be fine, yes.
00:58 NotFound And I can add experimental support to winxed.
00:59 NotFound No need to touch imcc.
01:00 NotFound For basic tests, I mean, not for testing nqp or rakudo.
01:01 NotFound Stupid idea of the day: add a winxed backed to pct ;)
01:02 NotFound Definitely need sleep. Bye.
01:03 whiteknight goodnight
01:05 kid51 Can anyone speculate as to why certain tests fail with a "Dubious" exit status when run under 'make test' -- but not under 'prove', 'perl t/harness' or even a smaller test target such as 'make dynoplibs_tests'?
01:08 whiteknight kid51: Dubious usually means a non-zero exit code
01:08 whiteknight and exit codes are not printed by default, so you wouldn't know if you ran it directly
01:09 kid51 Why should the test file exit with a non-zero code when run under, say, 'make smolder_test' but not under 'prove' or 'make library_tests'?
01:10 whiteknight oh. good question
01:10 kid51 I should note that I encounter this problem (a) on Darwin/PPC;
01:10 kid51 (b) on files I suspect touch GC heavily;
01:10 whiteknight does anything else change? Any tests fail in that file?
01:10 kid51 (c) but on different files at different commit points.
01:11 kid51 For example, tonight, at head, under 'make smolder_test', t/compilers/opsc/02-parse-all-ops.t reported: Non-zero wait status: 11;  Parse errors: Bad plan.  You planned 19 tests but ran 9.
01:11 kid51 But I get all PASS when run individually under 'prove' or as part of 'make library_tests'
01:12 kid51 Last night, it was a different file (lemme think which)
01:12 kid51 t/compilers/pge/p5regex/p5rx.t
01:13 woosley joined #parrot
01:13 kid51 In the case of t/compilers/pge/p5regex/p5rx.t, it was the first bad result I'd ever seen from this file.
01:14 kid51 t/compilers/opsc/02-parse-all-ops.t, in contrast, is the mother of all GC test files.  Takes forever on this box, but has consistently PASSed for a long time.
01:14 cotto joined #parrot
01:15 cotto ~~
01:18 whiteknight gen::makefiles -      Generate makefiles and other build files...value for '@cc_build_call_frames@' in config/gen/makefiles/root.in is undef at lib/Parrot/Configure/Compiler.pm line 572, <$in> line 95.
01:18 whiteknight wtf?
01:18 kid51 whiteknight: There were changes in last 24 hours that might have generated that.
01:19 whiteknight blah
01:19 whiteknight I just updated ubuntu too. I've already had a version problem with my ICU install
01:20 kid51 Perhaps 3f4486932fa, whose log message reads:  eliminate unused buildframes code (this is now handled by libffi)
01:21 whiteknight and I'm seeing that problem with errno.h again
01:21 kid51 whiteknight: Problem confirmed.  I just looked at my last Configure output
01:22 whiteknight blah. I really wanted to start looking at some PCC stuff tonight, but now I have to twiddle files around to make parrot build
01:23 kid51 It's probably the commit I cited.  The commit immediately before that has Configure.pl running clean
01:23 kid51 (However, this problem did not prevent me from building tonight on either linux or darwin.)
01:23 kid51 YMMV
01:24 dalek TT #2105 closed by jkeenan++: New build failure on darwin/PPC at runtime/parrot/library/YAML/Tiny.pir
01:24 dalek TT #2105: http://trac.parrot.org/parrot/ticket/2105
01:25 kid51 Trying a correction
01:35 kid51 whiteknight: pull
01:35 dalek parrot: 650471b | jkeenan++ | config/gen/makefiles/root.in:
01:35 dalek parrot: Remove reference to cc_build_call_frames, which probably should have been done along with other recent work on frames.  Configure.pl once again runs cleanly.
01:35 dalek parrot: review: https://github.com/parrot/parrot/commit/650471b06b
01:38 dalek parrot: 5893e91 | Whiteknight++ | frontend/parrot/main.c:
01:38 dalek parrot: We don't have a -p option
01:38 dalek parrot: review: https://github.com/parrot/parrot/commit/5893e91ede
01:38 whiteknight configing now
01:38 whiteknight yes, work
01:38 whiteknight works
01:38 whiteknight kid51++
01:40 dalek TT #2109 created by whiteknight++: Can't find asm/errno.h
01:40 dalek TT #2109: http://trac.parrot.org/parrot/ticket/2109
01:44 * whiteknight is going to bed now. Goodnight
01:44 whiteknight left #parrot
01:58 frodwith left #parrot
02:01 frodwith joined #parrot
02:02 Coke_ msg mj41 started.
02:02 aloha OK. I'll deliver the message.
02:03 mtk left #parrot
02:06 dalek parrot/m0-prototype: 43a14dc | dukeleto++ | src/m0/m0_assembler.pl:
02:06 dalek parrot/m0-prototype: Refactor writing of bytecode to a documented function
02:06 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/43a14dcd39
02:06 dalek parrot/m0-prototype: dfd717c | dukeleto++ | src/m0/m0_assembler.pl:
02:06 dalek parrot/m0-prototype: Add a stub to_bytecode function which takes a line of M0 and returns the bytecode representation
02:06 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/dfd717cf0c
02:06 cotto dukeleto++
02:09 Andy joined #parrot
02:11 dukeleto Andy: slightly OT, but can you release a new version of Test::WWW::Mechanize? The latest release on CPAN fails tests, but them seem to be fixed in svn
02:11 dukeleto s/them seem/they seem/
02:11 mtk joined #parrot
02:11 Andy I did.
02:11 Andy Today
02:11 dukeleto Andy!
02:11 Andy yes?
02:11 dukeleto Andy++ # /me goes back in his cave
02:13 Andy and it's not in svn any more.  IT's on github.
02:16 cotto Mmmmm.  Future.
02:20 bacek_at_work ~~
02:27 kid51 And with my most recent git pull, yet another different file borks early under 'make smolder_test' on Darwin/PPC.  This time it's t/library/yaml_tiny.t.
02:31 ingy o/
02:32 theory joined #parrot
02:33 dalek parrot: f29f90c | petdance++ | src/call/args.c:
02:33 dalek parrot: Removed unused variables
02:33 dalek parrot: review: https://github.com/parrot/parrot/commit/f29f90c164
02:33 dalek parrot: 9b2ad7c | petdance++ | / (2 files):
02:33 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
02:33 dalek parrot: review: https://github.com/parrot/parrot/commit/9b2ad7cb25
02:33 Andy bah
02:42 bacek_at_work Andy, git config branch.master.rebase true ?
02:43 Andy I always do --rebase
02:44 bacek_at_work hmm
02:44 bacek_at_work why then do you have merge commits?
02:44 Andy I don't know.
02:44 ttbot Parrot 9b2ad7cb MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/2372
02:45 Andy Hmm, shouldn't that update my ~/.gitconfig
02:53 plobsing I have an alias that does 'pull --rebase'. That seems to work for me.
02:59 plobsing how did that change break the build? it boggles the mind.
03:03 bacek_at_work plobsing, same GC failure is reported by kid51++ for Darwin/PPC. Someone does't WB properly... I'll try to look at it tonight.
03:12 benabik joined #parrot
03:13 kid51 left #parrot
03:16 hudnix left #parrot
03:31 ShaneC1 joined #parrot
03:44 dalek parrot: 8628ca5 | petdance++ | / (2 files):
03:44 dalek parrot: fix an arg annotation
03:44 dalek parrot: review: https://github.com/parrot/parrot/commit/8628ca5810
03:45 ShaneC1 left #parrot
03:55 ttbot Parrot 8628ca58 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/2532
04:06 Andy Anyone got guesses why this diff https://github.com/parrot/parrot/commit/​f29f90c1649b1ef351160069133759d1a0861985 which only removes unused vars would cause this failure http://tt.taptinder.org/cmdinfo/2401
04:06 plobsing Andy: bacek guesses it has to do with write barriers.
04:06 plobsing I'm tempted to believe that.
04:07 Andy What is a write barrier
04:07 plobsing it is a necessary part of generational GC
04:08 plobsing it is somewhat analogous to incref/decref operations in a reference counting scheme
04:09 plobsing if a reference from an object in an older generation to an object in a younger generation, the old-gen object has to be marked as "dirty" (which makes it a part of the rootset when only GCing the young generation)
04:11 soh_cah_toa left #parrot
04:11 Andy my guess is that const INTVAL named_arg_count = h->entries; causes linkage tohappen.
04:12 plobsing linkage?
04:13 Andy http://tt.taptinder.org/cmdinfo/2401
04:13 Andy that removing that causes the link failure
04:13 Andy vs. the unused stack vars.
04:14 plobsing that isn't a link failure
04:14 plobsing that's a segfault int parrot-nqp.exe
04:14 plobsing there are some link *warnings*
04:15 dalek parrot/get-entropy: f71bf5d | cotto++ | / (3 files):
04:15 dalek parrot/get-entropy: add Parrot_platform_get_entropy implementations for generic and win32
04:15 dalek parrot/get-entropy:
04:15 dalek parrot/get-entropy: The generic code relies on /dev/urandom, which seems to be common
04:15 dalek parrot/get-entropy: enough.  The win32 code relies on MS' Cryptograph API and needs testing.
04:15 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/f71bf5db03
04:15 dalek parrot/get-entropy: 77191d6 | cotto++ | src/interp/inter_create.c:
04:15 dalek parrot/get-entropy: initialize Parrot's prng from system entropy
04:15 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/77191d6a5a
04:16 benabik left #parrot
04:16 Andy plobsing: What in there tells you its a segfault?
04:17 Andy ooh ooh, it's not trying to make parrot-nqp
04:17 Andy make is using parrot-nqp,which segfaults.
04:17 plobsing bingo
04:17 Andy and only on Windows which I can't do anything with
04:18 plobsing Andy: we've been seeing failures are Darwin/PPC as well
04:18 Andy I have no darwin
04:18 plobsing go fish
04:18 Andy I mean, no PPC
04:18 Andy ooh wait, I might
04:18 Andy I think Quinn's mini is ppc
04:19 cotto anyone on windows mind testing that branch?
04:21 Andy Maybe I"ll try running that build step for nci_test under splint
04:23 Andy I'm gonna splint on nci_test.c
04:23 plobsing I'm fairly sure none of the steps to build libnci_test use parrot-nqp. I think make has moved on or is working in parallel.
04:25 Andy waaah
04:26 plobsing and the darwin/ppc errors don't necessarily present in the same locations.
04:26 plobsing they tend to move based on apparently unrelated changes
04:27 Andy Are the functions in nci_test.c supposed to be unused anywhere else in the codebase?
04:27 Andy Is that the nature of the testing?
04:27 plobsing yes. To my knowledge, they are only used by t/pmc/nci.t
04:27 Andy splint is unhappy about nci_ttt() but I find it not used anywhere
04:29 Andy indeed, no ttt anyway
04:29 Andy anywhere
04:29 plobsing what does it find objectionable?
04:30 Andy sprintfing into a potentially-NULL buffer
04:30 Andy What I find objectionable is sprintfing into a string and pritnfing it
04:31 Andy but I'm not seeing it used anywhere
04:31 plobsing Andy: it doesn't *only* printf it, it also returns it
04:31 Andy so it does
04:32 Andy i'm just seeing if I can yank it entirely.
04:32 Andy as a leftover
04:32 plobsing I'm betting it is
04:32 Andy it is what?  A leftover?
04:32 plobsing yep.
04:33 plobsing In fact, I have good evidence that it is. It isn't cited as an export by libnci_test.def, meaning it isn't an exported symbol on win32
04:37 Andy Yanking it.
04:37 Andy (testing first)
04:44 dalek parrot/get-entropy: ccf2d6a | cotto++ | src/string/api.c:
04:44 dalek parrot/get-entropy: use system entropy for hash seed randomization
04:44 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/ccf2d6a380
04:45 dalek parrot: 570ced6 | petdance++ | src/nci_test.c:
04:45 dalek parrot: Dropped used nci_ttt function. Consted some local vars, and updated argument annotations in function delcarations
04:45 dalek parrot: review: https://github.com/parrot/parrot/commit/570ced68e7
04:50 bubaflub left #parrot
04:52 cotto plobsing, I'd like to know your thoughts on the get-entropy branch.  It seems like the kind of thing you'd know more about than I do.
04:53 eternaleye_ joined #parrot
04:53 eternaleye left #parrot
04:54 plobsing cotto: it looks like a good start. I'd like to see some error checking.
04:56 plobsing Also, I am not aware of any OS standard (well, the linux FHS probably) that defines where in the file system a random device should be found
04:56 plobsing so that is a point of concern
04:57 ttbot Parrot 570ced68 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/2680
04:58 sorear there's naturally no inter-OS standard
04:58 cotto plobsing, I looked around and /dev/urandom seemed to be very common
04:58 sorear on Linux it's *always* /dev/u?random
04:58 sorear devfs is dead
05:00 cotto Error handling is tricky.  The code is used during interp init.
05:01 pjcj joined #parrot
05:01 plobsing cotto: an impolite bail is better than a silent fail-and-continue
05:02 plobsing if the operation consistently fails, we will likely get a constant random seed (most likely 0)
05:02 dalek parrot: b4be648 | petdance++ | config/gen/makefiles/root.in:
05:02 dalek parrot: splinting nci_test.c is OK
05:02 dalek parrot: review: https://github.com/parrot/parrot/commit/b4be648bec
05:03 cotto plobsing, I guess so
05:03 elmex_ joined #parrot
05:03 plobsing sorear: even on GoboLinux?
05:05 TiMBuS|Away joined #parrot
05:06 Hunger left #parrot
05:06 elmex left #parrot
05:06 TiMBuS left #parrot
05:06 TiMBuS|Away is now known as TiMBuS
05:06 elmex_ is now known as elmex
05:06 Hunger- joined #parrot
05:07 eternaleye_ is now known as eternaleye
05:08 Andy left #parrot
05:12 tadzik plobsing: yes
05:12 tadzik "Through a mapping of traditional paths into their GoboLinux counterparts, we transparently retain compatibility with the Unix legacy"
05:14 ttbot Parrot b4be648b MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/2740
05:25 birdwindupbird joined #parrot
05:49 alh left #parrot
06:05 dngor_ joined #parrot
06:05 GeJ_ joined #parrot
06:05 cxreg2 joined #parrot
06:05 autark_ joined #parrot
06:05 jtpalmer joined #parrot
06:05 jsut joined #parrot
06:06 dngor left #parrot
06:06 cxreg left #parrot
06:06 jsut_ left #parrot
06:06 sjn left #parrot
06:06 rblackwe_ left #parrot
06:06 jtpalmer_ left #parrot
06:06 KaeseEs left #parrot
06:06 autark left #parrot
06:06 GeJ left #parrot
06:06 KaeseEs joined #parrot
06:10 sjn joined #parrot
06:24 TiMBuS left #parrot
06:25 athomason left #parrot
06:29 TiMBuS joined #parrot
06:31 cxreg2 is now known as cxreg
06:33 dalek parrot: 715d913 | NotFound++ | / (2 files):
06:33 dalek parrot: Make parrot_iterate_hash more consistent by always expecting a semicolon after it
06:33 dalek parrot: review: https://github.com/parrot/parrot/commit/715d9136fe
06:34 athomason joined #parrot
06:38 TiMBuS left #parrot
06:38 TiMBuS joined #parrot
06:48 ShaneC joined #parrot
07:00 NotFound Given that ttbot has been silent for some time, I'll assume 715d913 fixed the problem.
07:06 bacek_at_work But how???
07:15 NotFound bacek_at_work: either do a web search for 'do while(0)' or accept it as white magic ;)
07:15 mj41 joined #parrot
07:15 bacek_at_work Magical Coding Robots do not believe in magic! Oh, wait...
07:17 NotFound In short: macros intended to be used as statemente are tricky.
07:18 bacek_at_work Ookey.
07:19 NotFound For the details you'll need to expand its usages by hand or with cpp help... which I didn't.
07:19 NotFound And to understand why it failed only on some platforms... I give up.
07:40 theory left #parrot
07:43 SHODAN joined #parrot
07:46 rurban_ joined #parrot
07:47 alh joined #parrot
07:48 rurban left #parrot
07:48 rurban_ is now known as rurban
08:57 dod joined #parrot
09:40 bacek ~~
09:52 mtk left #parrot
09:58 mtk joined #parrot
10:19 contingencyplan left #parrot
10:36 dalek parrot: 81c9e6b | bacek++ | include/parrot/context.h:
10:36 dalek parrot: Provide optimized definitions for Parrot_pcc_foo functions.
10:36 dalek parrot:
10:36 dalek parrot: It was obvious leftovers from GMS implementation branch. valgrind++ for pointing out.
10:36 dalek parrot: review: https://github.com/parrot/parrot/commit/81c9e6b8e4
10:46 ttbot Parrot 81c9e6b8 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3121
10:50 woosley left #parrot
10:52 mikehh bacek: you done broke it again :-}
10:52 bacek mikehh, meh... It's flacking failure. Same as all other GC fails
10:56 mikehh bacek: 759d13 was probably just luck
10:56 bacek mikehh, indeed
11:02 Psyche^ joined #parrot
11:03 dalek parrot: e744d10 | bacek++ | src/gc/gc_gms.c:
11:03 dalek parrot: Fix off-by-one error in selecting generation to collect.
11:03 dalek parrot: review: https://github.com/parrot/parrot/commit/e744d10b18
11:07 Patterner left #parrot
11:07 Psyche^ is now known as Patterner
11:13 ttbot Parrot e744d10b MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3181
11:13 mikehh What is fatal error U1077
11:15 bacek "segfault" I think
11:15 SHODAN is there a way for a mere mortal to comment on a ticket? http://trac.parrot.org/parrot/ticket/2107 for example.
11:17 bacek SHODAN, did you register in trac?
11:17 SHODAN just did
11:17 SHODAN (and couldn't find a way to comment) :)
11:17 mikehh bacek: looks like a nmake error - can't find something in include path
11:19 bacek SHODAN, yes. We have to disable trac activity for "fresh users" few weeks ago due abnormal spam activity. Just msg whiteknight/coke with your trac id. They can whitelist you.
11:20 bacek mikehh, return code 0xc0000005 is segfault. nmake is just not smart enough to report absence of YAML/Tiny.pir properly.
11:20 SHODAN i see
11:22 bacek SHODAN, sorry for inconvenience.
11:33 mikehh bacek: so it is segfaulting building YAML/Tiny.pir - that is/was yours no?
11:34 bacek mikehh, I'm not sure who is responsible for this fault. But most likely it's me.
11:35 * moritz finds "who fixes it?" much more interesting than "who broke it?"
11:35 mikehh bacek: I take it you don't have a Windoze machine to test this on (me either)
11:36 bacek mikehh, nope
11:37 mikehh moritz: yeah - not trying to cast any blame, just trying to track down the fault
11:39 mikehh with neither bacek nor me having windoze platforms, it becomes that much more difficult
11:40 moritz I understand, yes
11:43 mikehh anyway have just installed Ubuntu 11.04 i386 (again), built perl 5.14.0 and am now going to test parrot on it :-}
11:48 KaeseEs left #parrot
11:54 KaeseEs joined #parrot
12:07 dngor_ is now known as dngor
12:12 ambs joined #parrot
12:13 lucian joined #parrot
12:18 bluescreen joined #parrot
12:19 bubaflub joined #parrot
12:24 PacoLinux_ joined #parrot
12:28 bacek msg pmichaud I've got bad feelings that recent changes in rakudo slowed down "gcd" again.
12:28 aloha OK. I'll deliver the message.
12:29 hudnix joined #parrot
12:29 bacek aloha, (191-184)/192*100
12:29 aloha bacek: 3.64583333333333
12:36 pmichaud bacek: did gcd change since my last set of patches yesterday?
12:36 * pmichaud looks at commit log
12:37 bacek pmichaud, I comparing your initial commit for improve gcd with master (which adds few gcd related multisubs)
12:38 bacek But I can be totally wrong.
12:38 pmichaud the gcd operators are definitely faster than what we had in master as of 48 hours ago
12:38 pmichaud ~16% faster on my box
12:39 pmichaud however, sin.t could still be slower than what we had in the 2011.01 release
12:39 pmichaud I didn't have callgrind numbers for 2011.04 to work from to be able to decide if the problem was just since 2011.04 or perhaps from farther back
12:41 pmichaud https://gist.github.com/966698   # results of gcd changes -- rakudo-work is the version with the changes
12:41 pmichaud afk, taking kids to school.  bbiab
12:42 redicaps joined #parrot
12:43 bacek pmichaud, gist was done on your original commit to fix gcd. It was few commits after related to it.
12:53 PacoLinux_ left #parrot
12:53 pmichaud I suppose it could've slowed down because of the multi
12:53 pmichaud I'll check that
12:56 PacoLinux_ joined #parrot
12:58 pmichaud (re gc and speedup)  I suspect you're correct about gc on my box.  What we've been able to show is that in situations where gc dominates (boxes with smaller memory footprints, or programs that generate lots of gcables), the gms gc is now a big improvement over what existed in 2011.01.  That's good work.  (more)
12:59 pmichaud In other words, gc is no longer the bottleneck it was in 2011.01.  To get more speedups, we can start looking at other pieces of the puzzle and not just say "oh, it's the gc slowing us down".
12:59 pmichaud so, bacek++ bacek++
12:59 * moritz points to PCC
12:59 pmichaud yes, I suspect PCC is a big culprit.
13:00 whiteknight joined #parrot
13:01 dukeleto ~~
13:01 whiteknight good morning, #parrot
13:01 pmichaud good morning, whiteknight
13:01 whiteknight hello pmichaud, dukeleto
13:02 pmichaud sorry for flooding your ticket (re errno.h) with replies last night :)
13:03 whiteknight pmichaud, no worries. That's what I get for filing a ticket right before I sign off and go to bed
13:03 atrodo whiteknight++ The PCC blog had some good info
13:03 dukeleto whiteknight: mornin'
13:03 whiteknight atrodo: my goal for today is to put together a mini benchmark to prove it
13:03 dukeleto whiteknight: i also read your PCC blog post and enjoyed the thoroughness of explanation :)
13:04 moritz url?
13:04 dukeleto cotto++ # entropy branch
13:04 whiteknight atrodo: unfortunately, I have to use PASM to avoid the PIR-mandated infrastructure
13:05 atrodo whiteknight> Some of the choices you went over left me curious why it had been done that way
13:06 atrodo whiteknight> For instance, the CallContext as a part of the interp, is that left over from previous refactors or was that a designed feature?
13:06 moritz ah, http://whiteknight.github.com/2011/05/​11/pcc_refactors_and_improvements.html
13:06 pmichaud bacek: you're correct, the additional multis slow rakudo down slightly:  http://gist.github.com/968447
13:06 whiteknight atrodo: most of it is a hold-over
13:06 whiteknight the last round of PCC refactors was a herculean task, and we didn't clean up everything that needed cleaning
13:06 whiteknight plus, we didn't want to break too much backwards compatibility
13:07 atrodo whiteknight> Makes sense.  So how was it done before the refactor?  Did the refactor create CallContext?
13:08 whiteknight atrodo: before the refactor, there were at least 3 different code paths for different types of invocation. There was no CallContext
13:08 whiteknight All the functions labeled "Parrot_pcc_" didn't exist
13:09 atrodo whiteknight> So how were the arguments passed?
13:14 moritz "In short, we have plenty of information available at compile time, but we discard it"
13:14 moritz that's what hurt(s) rakudo too
13:16 pmichaud I envision a potential problem with the proposed refactor
13:17 pmichaud although I guess it must be handled already somehow/somewhere
13:17 dalek parrot: a7862a2 | mikehh++ | src/nci_test.c:
13:17 dalek parrot: fix =item after consting
13:17 dalek parrot: review: https://github.com/parrot/parrot/commit/a7862a2b33
13:17 dalek parrot: 42b1d80 | mikehh++ | src/gc/gc_gms.c:
13:17 dalek parrot: fix codetest failure - trailing spaces
13:17 dalek parrot: review: https://github.com/parrot/parrot/commit/42b1d80064
13:17 dalek parrot: 6456502 | mikehh++ | include/parrot/context.h:
13:17 dalek parrot: fix codetest failure - c_parens
13:17 dalek parrot:
13:17 dalek parrot: there should be at least one space between a C
13:17 dalek parrot: keyword and any subsequent open parenthesis
13:17 dalek parrot: review: https://github.com/parrot/parrot/commit/6456502075
13:17 pmichaud is CallContext able to store native types in the positional and named slots?
13:19 whiteknight pmichaud: yes, it handles native types without boxing
13:19 whiteknight otherwise the situation would be even worse
13:19 pmichaud so, even in the new scheme, CallContext still has a "signature" that keeps track of the types of the things in each slot
13:20 pmichaud but there'd be only one, set up when the CallContext gets values stored into it
13:21 pmichaud i.e., if my call context is $P9,  then  $P9[2] = 4    sets a flag in the CallContext so that we know that the 3rd positional slot contains an int
13:21 whiteknight CallContext still has internal bookkeeping stuff, yes. PCC uses an entirely separate set of signature PMCs
13:21 pmichaud got it
13:21 whiteknight so we have a signature PMC and a separate CallContext PMC, then a handful more temporary PMCs to deal with both of them
13:21 dukeleto whiteknight: i particularly don't like that there are multiple types of signature PMCs
13:22 whiteknight and temporary strings to lookup signatures *by name* in CallContext
13:22 whiteknight er, it looks up attributes by name
13:22 * dukeleto just crafted an email begging for somebody to look into getting our trac usernames+passwords back
13:22 moritz in a hash?
13:22 pmichaud anyway, fwiw, Rakudo already does the new model on the callee-side of things
13:23 whiteknight moritz: No. A chain of if(STREQ(...)) checks to get the attribute by name
13:23 moritz hm
13:23 whiteknight pmichaud: exactly. That's how I know that it works AND it's what users really want
13:23 pmichaud i.e., our subs have a single :call_sig parameter, and then we have a specialized opcode to unpack it the way we need based on whatever's in the CallContext
13:23 pmichaud whiteknight: correct :)
13:24 whiteknight If we have the decision between Parrot implementing the semantics in a way that nobody wants, or Parrot exposing the primitives to the user to implement those semantics themselves....
13:24 pmichaud +1.  That's kinda what we (Rakudo) argued a long time ago.
13:24 whiteknight even without performance savings, which bacek doubts, we still give much win to the users
13:25 moritz our code is license compatiable with your code (hint, hint) :-)
13:25 moritz *compatible
13:25 whiteknight moritz: :) It's more a matter of Parrot ripping bad code out than borrowing your good code
13:25 whiteknight There are inefficiencies inherent in your implementation that we can reduce
13:26 moritz well, rakudo needs some weird stuff that parrot doesn't need
13:26 moritz like, filling positional parameters by name
13:26 ttbot Parrot 42b1d800 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3257
13:26 whiteknight yes, so we'll expose the CallContext to you directly, and you do whatever with it that you want
13:27 whiteknight or even provide a subclass of CallContext, or something different entirely
13:27 whiteknight what you pass to a subroutine is no business of mine
13:28 pmichaud whiteknight++  # excellent blog post
13:28 whiteknight pmichaud, thanks! I sincerely hope some of these ideas pan out
13:29 pmichaud now let's see if I can grok valgrind and get the call numbers bacek++ was producing
13:33 atrodo I'm not a fan of magic that assumes it knows what the end-user wants
13:33 atrodo whiteknight> And actually, your proposed change is in line with what I had been working towards for Lorito
13:33 whiteknight atrodo: I've been thinking about these suggestions specifically with Lorito in mind
13:37 atrodo whiteknight> I think the current m0-spec has argument passing done with registers
13:39 dukeleto atrodo: argument passing to what?
13:40 atrodo dukeleto> Between methods
13:40 dukeleto atrodo: well, i would say that a continuation is passed along, but yes, the continuation boils down to registers
13:41 pmichaud ooc, is there a reason we want/need a separate CallContext PMC?
13:41 pmichaud would it make sense to make all of the argument passing stuff a part of the Context PMC?
13:42 pmichaud hmmm, probably not, because of CPS and coroutines
13:42 pmichaud nm
13:42 pmichaud (and continuations)
13:43 atrodo pmichaud> Perhaps I'm missing the difference between CallContext and Context
13:43 pmichaud Context holds the registers and information for a currently executing Sub
13:43 pmichaud iiuc, CallContext just holds the information for an invocation of a sub
13:44 pmichaud I'm sure I have my names wrong anyway... too early in the morning, too many other things going on
13:45 pmichaud afk, traveling across town
13:45 pmichaud bbl
13:46 dukeleto in M0, we are going to take things that shouldn't be in the interp object and put them in the current context, where they belong
13:47 dukeleto interps will still hold a small collection of truly global state info, tho
13:49 whiteknight do we have a Context PMC?
13:49 whiteknight I don't think we have a separate Context
13:49 whiteknight Lorito might separate that out
13:50 atrodo whiteknight> What do you mean?
13:50 whiteknight We only have a CallContext PMC. There is no separate Context type
13:51 atrodo whiteknight> I see what you're saying.  That's a good question
13:51 mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_3_0-214-g6456502
13:51 mikehh Ubuntu 11.04 i386 (g++)
13:52 JimmyZ joined #parrot
13:52 mikehh that is with perl 5.14.0
13:52 JimmyZ left #parrot
13:53 JimmyZ joined #parrot
13:53 ttbot Parrot 64565020 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3357
13:53 mikehh I get a deprecation warning in pre-/post-config tests:
13:53 mikehh Use of qw(...) as parentheses is deprecated at config/init/defaults.pm line 305.
13:54 mikehh 6 times and once in config
13:55 dukeleto mikehh: interesting. which version of perl ?
13:56 mikehh otherwise perl 5.14.0 looks good with parrot - have not tested some of the /tools/dev progs
13:56 dukeleto mikehh: sounds like a new deprecation
13:57 mikehh I just did a fresh install of Ubuntu 11.04 and built perl 5.14.0 on top of it and have just now built and tested parrot using it
13:57 mikehh it seems to be in perldelta.pod
13:58 mikehh it is still on RC3
13:59 mikehh of course Ubuntu is still on perl 5.10.1 :-{
14:00 rj_ac joined #parrot
14:04 mikehh I am still on perl 5.12.3 on my Kubuntu/Ubuntu 11.04 amd64
14:06 JimmyZ left #parrot
14:13 JimmyZ joined #parrot
14:17 JimmyZ left #parrot
14:21 NotFound whiteknight: thinking about hand decoding call_sig, a posiible slowdown is the distinction between a named optional unfilled and filled with a new value need several ops.
14:21 NotFound s/new/null
14:29 redicaps left #parrot
14:31 lucian left #parrot
14:33 woosley joined #parrot
14:33 woosley left #parrot
14:38 simcop2387 left #parrot
14:39 PacoLinux_ left #parrot
14:47 SHODAN left #parrot
15:00 SHODAN joined #parrot
15:04 SHODAN left #parrot
15:05 theory joined #parrot
15:10 darbelo joined #parrot
15:15 lucian joined #parrot
15:18 SHODAN joined #parrot
15:18 davidfetter joined #parrot
15:27 PacoLinux_ joined #parrot
15:29 PacoLinux_ left #parrot
15:30 PacoLinux_ joined #parrot
15:30 cotto ~~
15:38 dalek parrot/whiteknight/pcc_prototyping: b2cae51 | Whiteknight++ | / (5 files):
15:38 dalek parrot/whiteknight/pcc_prototyping: Add in a few new opcodes required for my PCC refactors idea. invokecc_p_p, new_call_context_p, and get_call_context_p. I'm working on a writeup now to discuss why these would be necessary to replace set_args, get_params, set_returns and get_results
15:38 dalek parrot/whiteknight/pcc_prototyping: review: https://github.com/parrot/parrot/commit/b2cae51ada
15:39 SHODAN left #parrot
15:46 rurban_ joined #parrot
15:48 rurban left #parrot
15:48 rurban_ is now known as rurban
15:50 dalek nqp: d846b25 | moritz++ | src/Regex/P6Regex/Grammar.pm:
15:50 dalek nqp: more awesome error message for unrecognized meta character in regexes
15:50 dalek nqp:
15:50 dalek nqp: not quite awesome yet, it does not report the actual offending character
15:50 dalek nqp: review: https://github.com/perl6/nqp/commit/d846b25a3d
15:51 atrodo whiteknight++
15:53 cotto I suspect that watching MacGuyver may not be the best thing for my code.
15:54 atrodo cotto> What's the worse that could happen.  Remember, MacGuyver's hacks always worked and never had side effects
15:56 benabik joined #parrot
15:59 benabik ~~
16:00 cotto Did someone get NotFound access to his trac account?
16:00 dalek parrot: 4f65ae6 | mikehh++ | config/init/defaults.pm:
16:00 dalek parrot: add parentheses around qw(...) to avoid deprecation warning in perl 5.14.0
16:01 dalek parrot: review: https://github.com/parrot/parrot/commit/4f65ae6b35
16:03 dalek parrot/m0-prototype: ec14582 | dukeleto++ | src/m0/m0_assembler.pl:
16:03 dalek parrot/m0-prototype: Generate less wronger M0 bytecode
16:03 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/ec1458257c
16:05 benabik I managed to get into my Trac account by asking for a new password...
16:07 alester joined #parrot
16:08 alester dukeleto: Are you using the new TWMech OK?
16:08 whiteknight atrodo: You like some of those timings? It's good validation
16:08 atrodo whiteknight> what timings?
16:09 atrodo whiteknight> Ah, new blog.  I was giving you karma for the branch
16:09 whiteknight atrodo: Oh, I thought you were ++ing my latests blog
16:09 whiteknight :)
16:09 cotto benabik, some users don't remember which email they set for password recovery (if any)
16:09 atrodo whiteknight++ that too
16:09 benabik cotto: Well, that would be a problem yes.
16:10 dodathome joined #parrot
16:10 ttbot Parrot 4f65ae6b MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3425
16:11 NotFound I think I set it, but I'm not completely sure.
16:12 cotto dukeleto, I don't think the M0 assembler needs to do as much work as you think it does.
16:17 mj41 left #parrot
16:17 atrodo whiteknight> So thinking outloud, how would this change hll interop?
16:18 dukeleto alester: haven't tried the newest version, yet. Will let you know.
16:20 simcop2387 joined #parrot
16:20 dukeleto cotto: please explain
16:26 Coke_ shodan, userid?
16:26 PacoLinux_ left #parrot
16:26 cotto dukeleto, cotto_work will.
16:26 cotto left #parrot
16:28 Coke_ I'm happy to play tracadmin, but need trac IDs in order to assign privs. Ping me if it's still an issue.
16:32 whiteknight atrodo: Good question. Right now it's the wild west. Parrot tries to provide a system, and if you don't like it (how Rakudo doesn't) you provide your own
16:32 whiteknight atrodo, in my system, the only interface is that you put parameters into the CallContext, and the recipient unpacks it however they want
16:33 bluescreen left #parrot
16:36 whiteknight and if you do it that way, there's no reason why CallContext even needs to contain the actual values. It could just contain references to the registers where those values are held
16:36 whiteknight or CallContext could be lazy, and not load values until they are unpacked
16:38 dukeleto BREAKING NEWS FROM OSL
16:38 whiteknight something like Javascript's arguments[] array becomes trivial to implement. "arguments" is just an alias over the CallContext
16:39 dukeleto they have restored our trac htpasswd file from a backup
16:39 NotFound whiteknight: note that javascript has no named parameters.
16:39 dukeleto and the version we have been modifying is now called parrot.htpasswd.bak is the same directory.
16:39 benabik dukeleto: woo!
16:39 whiteknight NotFound: right
16:40 dukeleto which means people can go back to their passwords before the madness
16:40 NotFound dukeleto: verfied, I'm logged now.
16:42 NotFound People actually do backups? I'm amazed ;)
16:42 NotFound I thought they were an urban legend.
16:42 NotFound Or even pre-urban.
16:43 benabik whiteknight: re blog: is a two argument invoke basically call/cc and three arg tail recursion (i.e. never comes back to here)?
16:43 atrodo whiteknight> So if js doesn't have named params, how would they get named params?
16:43 whiteknight benabik, right now we have invokecc (1 arg) and invoke (2 args). invoke takes a sub and a return continuation
16:43 atrodo Although, that probably doesn't change with the new callcontext
16:43 whiteknight benabik, I think we could condence down to a single invoke op with 2 or 3 args. The optional third arg would be the return continuation
16:44 whiteknight atrodo, if javascript doesn't have named params, they wouldn't be generating code to access them
16:44 benabik whiteknight: If you have "invoke sub, contination" then "say 'Hi'", the code never prints anything because it never comes back, right?  (Just trying to be certain I have the structure right.)
16:44 benabik whiteknight: It invokes the continuation at return instead of coming back to after the invoke.
16:45 whiteknight atrodo: If they wanted to be able to receive named args from code written in a different language, they could add a custom function or override named attribute access on "arguments"
16:45 whiteknight benabik, exactly right. The return continuation is where the subroutine jumps to when it is over
16:45 whiteknight benabik, and there's no reason it has to jump back to the point of the call
16:46 whiteknight it can jump directly to another chained sub, or a continuation somewhere
16:46 benabik whiteknight: Right, right.  I was just making sure I wasn't assuming the wrong thing.
16:46 whiteknight no, you've got it
16:46 benabik :-D
16:46 * benabik has been stuck in Java-land for 3 days.
16:46 * benabik puts away Eclipse and doesn't want to touch it again any time soon.
16:47 whiteknight brb
16:47 whiteknight left #parrot
16:47 whiteknight joined #parrot
16:47 alh left #parrot
16:47 dukeleto benabik: good idea
16:48 NotFound Note that on the callee side you can already do all that, just by using a :call_sig arg
16:48 benabik dukeleto: I like Eclipse when I have to work in Java, but I don't like working in Java.  I've been working in Ruby, Scala and Parrot for too long.
16:48 bluescreen joined #parrot
16:53 benabik Hm.  Does parrot have any way to bypass repeated type lookups?  i.e. can I do something like `mypmc = get_type "MyPMC"; a = new mypmc; b = new mypmc` instead of `a = new "MyPMC"; b = new "MyPMC"`?
16:53 cotto_work ~~
16:57 plobsing benabik: yes. I believe it is called 'get_class'
16:57 birdwindupbird left #parrot
16:59 benabik plobsing: Interesting.  I was wondering about that because of whiteknight's blog and comment about the slowness of `new "CallContext"`.  Although a dedicated op new_callcontext is probably best because we need that to be as fast as possible all the time.
17:00 cotto_work dukeleto: the M0 assembler doesn't need to care about what op arguments mean.  Looking things up is the responsibility of the M0 interp.
17:00 whiteknight benabik: I didn't try get_class at all. I might want to include that in a benchmark instead of a dedicated new opcode
17:00 rj_ac left #parrot
17:00 dalek parrot: dbfe940 | plobsing++ | config/gen/opengl.pm:
17:00 dalek parrot: convert opengl NCI signatures to new format
17:00 dalek parrot: review: https://github.com/parrot/parrot/commit/dbfe9404be
17:00 dalek parrot: 5e2b6af | plobsing++ | runtime/parrot/library/OpenGL.pir:
17:00 dalek parrot: handle new signature change at runtime
17:01 dalek parrot: review: https://github.com/parrot/parrot/commit/5e2b6afcb2
17:01 dalek parrot: 5e2f161 | plobsing++ | runtime/parrot/library/NCI/Utils.pir:
17:01 dalek parrot: update call_toolkit_init for new call by reference calling convention
17:01 dalek parrot: review: https://github.com/parrot/parrot/commit/5e2f1613f5
17:01 whiteknight Notfound: :call_sig on the callee does not do quite the same thing I do. It still calls get_params, which calls fill_params. fill_params does a check for :call_sig flag and returns early
17:01 benabik whiteknight: get_class only helps people who make multiple calls while an opcode helps everyone. And without the opcode, we'll just end up with every single bit of PIR code with a dedicated CallContext class register.
17:01 whiteknight it's less work than doing the whole fill_params show, but it's more than we need
17:01 plobsing benabik: be careful not to fall into the "add an op for it" trap. adding ops just pushes the complexity elsewhere
17:01 benabik plobsing: True enough.
17:01 NotFound whiteknight: I mean "you" the compiler writer.
17:02 plobsing NotFound: opengl appears to be fixed now
17:02 whiteknight plobsing: Yeah, that's my least favorite part of this approach. I find comfort in the idea that we should be able to delete more ops than we add
17:02 benabik plobsing: But performing calls is such a vital part of the VM that it doesn't seem uncalled for.
17:02 NotFound whiteknight: "you" can wtite the code to get the arguments.
17:02 benabik (Uncalled for, heh.)
17:02 NotFound plobsing: nice, going to test...
17:02 whiteknight Notfound: yes, true. Getting the call context is still more expensive now than it needs to be
17:03 plobsing whiteknight: WRT callcontext referencing the caller context, we already have something that does that - Keys. Perhaps we could merge the two concepts.
17:04 whiteknight blah. I have an irrational and unfounded hatred of keys
17:04 benabik plobsing: Keys?
17:04 whiteknight benabik: basically, something like a magical linked list
17:04 plobsing whiteknight: the implementation is a bit lacking, but the concept is necessary
17:04 whiteknight src/key.c and src/pmc/key.pmc
17:04 benabik whiteknight: I have a distrust of "magical".
17:04 plobsing whiteknight:  there is nothing that *requires* keys to be a linked list
17:05 plobsing they could just as easily be implemented using an array of integeres
17:05 benabik I also distrust comments like "Sometimes it's the next key, sometimes it's not.  The Key code is like that."
17:06 plobsing the caller convention would then be (1) fetch key constant describing call (functions as signature PMC) (2) clone key and bind clone to current context (3) pass cloned key during call
17:07 NotFound That comments can be remanants from a previous epoch, the key usage is more clean right now.
17:08 plobsing fetching a constant is cheap, cloning a key (if implemented using an integer array) could be cheap, binding a key to a context is a single pointer assign
17:08 contingencyplan joined #parrot
17:08 plobsing the caller side of PCC becomes increadibly inexpensive
17:09 whiteknight can we implement all that inexpensiveness inside CallContext?
17:09 NotFound plobsing: examples/fly flies again :)
17:09 benabik Key is a constant heterogeneous list?
17:09 plobsing benabik: yes, it is used to implement keyed access to aggregates
17:09 ttbot Parrot dbfe9404 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/3497
17:09 plobsing keys can also reference registers
17:10 plobsing whiteknight: we can. and then we can kill keys replace them with callcontext, and rename callcontext to key
17:10 plobsing they are the same concept
17:11 benabik plobsing: They sound more like "closely related concepts" than the same one.
17:11 whiteknight CallContext does a lot more than just passing arguments. It also holds the registers and all context information for the sub
17:11 plobsing see, that strikes me as just wrong
17:12 whiteknight We could CallContext isa Key, if you think that's worthwhile. The whole thing gives me the heeby-jeebies, so I don't want to think about it much
17:12 plobsing the register frame should be independant of the callcontext
17:12 whiteknight plobsing: We combined the two during the PCC refactors because it was seen as needlessly wasteful to create a CallSignature AND a Context for every call
17:13 whiteknight and since the two almost always have a 1:1 relationship, they were merged. Great savings. There was much rejoicing
17:13 plobsing but some of that information is much more long-lived than other information
17:13 plobsing the call info is only alive during the call
17:13 whiteknight I'm not saying it's the best decision on all levels
17:13 plobsing and should be reclaimed afterwards
17:13 whiteknight but it was an optimization with significant performance benefits
17:14 whiteknight a better design that doesn't regress miserably on performance would be eagerly considered
17:14 plobsing GenGC means we should aggressively seek to split information with different lifetimes
17:15 whiteknight to the point of turning one PMC allocation per call into two PMC allocations per call, across the board?
17:16 plobsing young generation garbage is cheap
17:16 plobsing call info is young generation except in special cases
17:19 dukeleto msg bacek you gonna unbreak master anytime soon? http://jitterbug.leto.net:3000/project/parrot
17:19 aloha OK. I'll deliver the message.
17:19 dukeleto msg bacek i would prefer you break a branch
17:19 aloha OK. I'll deliver the message.
17:19 fedov joined #parrot
17:22 dukeleto cotto_work: i am going afk for a while. Can you send an email to me or parrot-dev explaining exactly what an M0 assembler should and should not do ?
17:22 cotto_work dukeleto: srue
17:23 cotto_work *sure
17:25 davidfetter left #parrot
17:27 fedov left #parrot
17:47 jevin joined #parrot
17:55 * lucian has just submitted his dissertation. yay for mediocrity! :)
17:55 benabik lucian++
17:56 lucian whiteknight: with a good gc, constant-size allocation is free
17:56 lucian whiteknight: so overall, i agree with plobsing, although PMC construction might be more complex that i immagine
17:56 lucian benabik: thanks
17:57 benabik lucian: Is this the final dissertation?  Ready for defense and everything?
17:57 * benabik just started talking to a prof about a thesis.
17:57 lucian benabik: yeah, pretty much
17:57 lucian done with uni after this
17:57 benabik lucian: Awesome!
17:57 lucian not really, it's kinda crap
17:57 whiteknight lucian: okay, I'll take your work and plobsing's word for it. I don't think we need to be changing around the way CallContext works for the first upcoming round of refactors
17:58 whiteknight I mean, we can do it, or we can start cleaning crap up and make a new plan when the dust settles
17:58 lucian and i have plenty of coursework and exams left ...
17:58 lucian whiteknight: if you think about it, you can arrange your gc so that allocation is just incrementing a pointer
17:58 benabik Do we currently have allocation pools for constant sized objects?
17:58 lucian PyPy's and jdk's do that
17:59 whiteknight lucian: yes, that's how we do allocations in Parrot now, for the most part
17:59 lucian whiteknight: but you certainly know more than me about parrot, it might not be feasible/good idea short-term
17:59 whiteknight for a fresh pool, we increment a pointer. Once the pool has been exhausted the first time, we GC and then pull off a linked free list
18:00 lucian right. so if the pools are too small/not aligned to pmc size, two allocations might be an issue
18:00 whiteknight pools should be plenty large and are aligned
18:00 lucian btw, http://dl.dropbox.com/u/317039/paper.pdf if anyone cares about my paper. don't distribute it please, 'cause i'm not sure i'm allowed
18:00 whiteknight because each pool only services objects of one size
18:00 lucian and is PMC initialisation expensive?
18:01 whiteknight I would say so, yes
18:01 benabik lucian: IRC channels are logged, so that link is now "public", so you might want to move it after a short time.  :-/
18:01 whiteknight for each PMC we have to allocate an attributes structure for it, assign a vtable, and call VTABLE_init
18:01 lucian benabik: for some definition of "public"
18:02 benabik lucian: In this case, by public I mean "indexed by Google"
18:02 cotto_work There's a pretty good chance it'll be indexed by various search engines at some point.
18:02 * lucian shrugs. it "slipped" out of my dropbox
18:02 lucian whiteknight: right. could this be reduced?
18:03 lucian if nothing else, a zygote PMC might help
18:04 lucian after 3 years, i truly regret doing uni
18:05 benabik lucian: That sucks.  :-(  Despite the panic at the end of this quarter, I've been really enjoying it.
18:05 lucian benabik: at least mine's been mostly useless
18:05 lucian only 3rd year have i learned new things
18:06 lucian and even then, the exams and coursework is usually stupid
18:07 benabik lucian: Well, that's no good.  I've had three classes a quarter so far and it's broken down into:  1 bleh, 1 kinda interesting, 1 awesome.
18:07 lucian right. my first year was all bleh, second year mostly bleh with a little interesting, 3rd mostly interesting with a little awesome
18:08 darbelo ~~
18:08 benabik lucian: Oh well.  :-(
18:08 benabik lucian: Hopefully the little bit of paper they'll give you will be useful at least.  :-D
18:08 cotto_work Anyone know windows and want to take a look at the get-entropy branch?
18:09 lucian benabik: doubtful, but hopefully
18:14 whiteknight cotto_work: yes, and no
18:14 whiteknight :)
18:15 cotto_work sad face
18:15 whiteknight I'm looking now
18:15 benabik lunch!
18:15 benabik left #parrot
18:15 cotto_work happy face
18:15 cotto_work whiteknight++
18:15 whiteknight cotto_work, where is the entropy stuff defined?
18:15 cotto_work src/platform/win32/entropy.c
18:16 cotto_work new file
18:18 whiteknight okay, what am I looking at?
18:19 whiteknight just make sure it works, or you want me to fill in the blanks?
18:19 cotto_work Why it won't build with the msvc toolchain
18:19 whiteknight ah, okay
18:19 cotto_work the blanks are the easy part
18:19 cotto_work I just left them blank in case the surrounding code needed to be changed.
18:24 whiteknight cotto_work, it doesn't look like we are linking against advapi32.dll
18:25 whiteknight that's where those functions are defined
18:25 cotto_work whiteknight: ok.
18:26 cotto_work do you have the tuits to fix it?
18:27 whiteknight lemme look
18:30 whiteknight I'm trying a build now.
18:30 cotto_work much appreciated
18:33 cotto_work figured out how to fix the Makefile
18:34 whiteknight yeah, me too
18:35 cotto_work and where to add the .lib
18:35 whiteknight okay, parrot builds but the build now fails building ops2c
18:35 whiteknight .\parrot-nqp.exe --target=pir --output=compilers/opsc/ge​n/Ops/Compiler/Grammar.pir compilers/opsc/src/Ops/Compiler/Grammar.pm
18:35 whiteknight NMAKE : fatal error U1077: '.\parrot-nqp.exe' : return code '0xc0000005'
18:35 whiteknight Stop.
18:35 whiteknight everything up to that point passes
18:36 cotto_work I saw that on mingw
18:36 atrodo Looks like we're legit: http://www.yapc2011.us/yn2011/event/877
18:36 cotto_work atrodo: wootsauce
18:36 atrodo http://www.yapc2011.us/yn2011/event/876
18:37 cotto_work whiteknight: trying after adding advapi.lib to the mswin32 hints
18:38 whiteknight cotto_work: that's what I did the first time. It's in the commandline for building parrot-nqp
18:39 cotto_work build looks good for me
18:40 dalek parrot/get-entropy: 42dda94 | cotto++ | config/init/hints/mswin32.pm:
18:40 dalek parrot/get-entropy: add advapi32 to the list of libs libparrot gets linked to
18:40 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/42dda94d06
18:41 cotto_work That wasn't quite as painful as I'd expected.
18:43 cotto_work It seems to work and generate superficially random-looking numbers.
18:44 dalek parrot/get-entropy: c59893a | cotto++ | src/platform/win32/entropy.c:
18:44 dalek parrot/get-entropy: pass PARROT_INTERP to entropy function instead of void
18:44 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/c59893ac06
18:45 cotto_work nice to have that working
18:47 cotto_work whiteknight: thanks
18:47 cotto_work and whiteknight++
18:50 cotto_work The mingw build still explodes on opsc.
18:50 cotto_work I saw that on master too, though.
18:51 whiteknight that's worrisome
18:52 whiteknight I wasn't building with mingw
18:52 cotto_work yes
19:06 cotto_work The entropy code also doesn't dtrt on mingw.
19:08 SHODAN joined #parrot
19:14 cotto_work having msvc working is definite progress
19:24 mikehh plobsing: perlcritic does not like the prototype on line 48 of config/gen/opengl.pm
19:26 mikehh whiteknight: bacek claims that error code is a segfault
19:27 whiteknight mikehh: which error code?
19:27 mikehh whiteknight: NMAKE : fatal error U1077: '.\parrot-nqp.exe' : return code '0xc0000005' <- this one
19:28 whiteknight oh, nice
19:29 mikehh U1077 indicates nmake can't find it - the return code is supposed to be a segfault
19:30 whiteknight ok
19:31 cotto_work awesome
19:31 mikehh IOW it fails to build and '0xc0000005' indicates a segfault has occurred (at least according to bacek) me I don't know from nothing
19:31 cotto_work It's been too long since I've seen a segfault.
19:43 whiteknight I can make a bunch more for you, if you want
19:46 whiteknight entropy generator + pointer dereference seems like a good system for making them
19:47 cotto_work whiteknight: sounds good
19:51 dukeleto ~~
19:54 cotto_work hio dukeleto
19:56 dukeleto cotto_work: howdy
20:00 dalek parrot/get-entropy: 782b0e5 | cotto++ | src/platform/win32/entropy.c:
20:00 dalek parrot/get-entropy: add enough magic to fix entropy for the mingw build
20:00 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/782b0e5ad4
20:00 dukeleto cotto_work: which platforms has get-entropy not been tested on yet?
20:01 darbelo left #parrot
20:01 darbelo joined #parrot
20:01 dalek winxed: r997 | NotFound++ | trunk/winxedst1.winxed:
20:01 dalek winxed: extract creation of predef caller into a function
20:01 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=997
20:02 cotto_work dukeleto: I've tested on windows (msvc and mingw) and Ubuntu 10.10 (x86) and 11.04 (x64).
20:03 cotto_work dukeleto: any other *nix would be great.  /dev/urandom seems to be very common, but there's no fallback for if it doesn't exist.
20:04 benabik joined #parrot
20:06 ShaneC left #parrot
20:15 benabik left #parrot
20:19 benabik joined #parrot
20:25 Coke_ benabik: (java land) hey, I'm in cold fusion land.
20:26 ShaneC joined #parrot
20:26 benabik Coke_: Cold fusion in physics is neat.  In programming, not so much.
20:27 ambs left #parrot
20:27 whiteknight FYI: https://github.com/blog/854-schedu​led-maintenance-saturday-22-00-pst
20:28 ambs joined #parrot
20:28 whiteknight left #parrot
20:30 particle left #parrot
20:32 ShaneC left #parrot
20:34 particle joined #parrot
20:37 dodathome left #parrot
20:42 bubaflub left #parrot
20:49 dalek winxed: r998 | NotFound++ | trunk/winxedst1.winxed:
20:49 dalek winxed: check validity of instanceof left operand
20:49 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=998
20:51 ambs_ joined #parrot
20:51 ambs left #parrot
20:51 ambs_ is now known as ambs
20:55 NotFound Winxed millenium edition is approaching ;)
20:56 tadzik yay :)
20:57 cotto_work worst marketing evar
20:57 Coke left #parrot
20:58 Coke joined #parrot
20:58 plobsing NotFound: oh noes. I'll have to rush to ensure all my code is w1k compliant
20:59 perlite_ joined #parrot
20:59 NotFound if (r % 100 > 99) ...
21:02 perlite left #parrot
21:02 perlite_ is now known as perlite
21:05 Coke left #parrot
21:05 Coke joined #parrot
21:07 SHODAN left #parrot
21:15 dalek TT #2110 created by cotto++: mingw build fails while building opsc
21:15 dalek TT #2110: http://trac.parrot.org/parrot/ticket/2110
21:18 bubaflub joined #parrot
21:20 dalek winxed: r999 | NotFound++ | trunk/winxedst1.winxed:
21:20 dalek winxed: check invalid initialization from void
21:20 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=999
21:30 bacek Good morning, humans
21:31 bacek dukeleto, I didn't brake build. GC maybe. But not build.
21:32 ambs left #parrot
21:32 cotto_work aloha, bacek
21:32 bacek msg whiteknight Nice post. Just 2 "small" problems: "C boundaries" and "MMD".
21:32 aloha OK. I'll deliver the message.
21:32 bacek cotto_work, aloha
21:39 cotto_work msg whiteknight The formatting on your latest blog post looks wacky.  There's a big gap between the first paragraph and the code snippet.
21:39 aloha OK. I'll deliver the message.
21:40 bacek msg whiteknight And another "small" problem - ":flat/:slurpy". E.g. ($P1, $P2 :slurpy) = foo($P3 :flat) where "foo" is declared with ".param int a; .param pmc b :slurpy".
21:40 aloha OK. I'll deliver the message.
21:41 benabik 'lo bacek!  I'm one major project closer to working on GSoC.  :-D
21:41 bacek msg whiteknight and .return ("foo", "bar", "baz", $P3 :flat). Good luck!
21:41 aloha OK. I'll deliver the message.
21:41 bacek benabik, good to know! How many left?
21:41 benabik bacek: 1 large paper, 1 homework, 3 finals.
21:41 bacek benabik, which is equal to (in days)?
21:42 benabik bacek: Monday the projects are done, and I can actually spend some (but not too much) time in Parrot-land.  Friday morning is my last final and I can really dig in after that.
21:43 bacek benabik, hooray!
21:44 benabik bacek: I'm not overly worried about the finals this quarter.  Need to do some studying, but nothing too bad.  It's been the projects due today and Monday that have taken ALL OF MY TIME.
21:48 bacek benabik, fair enough :)
21:48 benabik ETOOMANYFINALS ETOOMANYPROJECTS ENOTENOUGHTIME ETOOMANYERRORS
21:48 cotto_work ENOTENOUGHROBOTS
21:51 bacek msg whiteknight https://gist.github.com/969536 - this is why we have all "fill_params hell". Without splitting PCC into 2 parts a-la "fastcall" vs "smartcall" we can't do it much faster.
21:51 aloha OK. I'll deliver the message.
21:56 bluescreen left #parrot
21:56 darbelo left #parrot
22:08 bacek cotto_work, #2110 (mingw fail) Is it optimized build?
22:09 cotto_work bacek: no
22:09 bluescreen joined #parrot
22:10 bacek cotto_work, hmm. Can you obtain backtrace for it?
22:15 bluescreen_ joined #parrot
22:21 cotto_work bacek: I need to install gdb first
22:22 cotto_work apparently strawberry doesn't include it
22:24 cotto_work should have something in a minute or two
22:27 alester left #parrot
22:28 cotto_work doesn't seem to fail under gdb
22:28 benabik cotto_work: I love that kind of bug.
22:29 alester joined #parrot
22:30 benabik I have a bug in git where a change in the configuration code causes git-fsck to fail a test, but only when I run the test on a ramdisk.  If I run fsck manually or run the test on my hard drive, it works fine.  I call it a quantum bug.  Its behavior is different depending on how I observe it.
22:32 lucian benabik: sounds like a timing bug
22:32 cotto_work What's $? in CMD.COM?
22:32 cotto_work er, what's its equivalent.
22:33 benabik lucian: I think it's timing and memory allocation.  When a variable changed from a static buffer to an allocated one, it started exploding.  Fun to track down at any rate.  (Which I'll spend some cycles on after finals.)
22:33 benabik lucian: It'll give me good practice for GC bugs in Parrot.  ;-)
22:33 lucian i try to stay away from anything that can deadlock
22:34 lucian benabik: good luck with that :)
22:36 lucian seeing as how i hate C so much, the only gc work i plan to maybe to would be either porting jikes rvm gcs or writing gcs in winxed
22:36 cotto_work looks like %errorlevel% is what I wanted
22:36 lucian s/maybe to/maybe do/
22:36 lucian cotto_work: i can never remember all the odd windows constants
22:36 cotto_work bacek: any suggestions?
22:47 lucian left #parrot
22:50 lucian joined #parrot
22:50 bacek_at_work cotto_work, is there something like "ulimit -c unlimited" on win32?
22:51 cotto_work beats me.  lemme dig
22:55 lucian i've been thinking that perhaps parrot could adopt one of the OS abstraction libs
22:56 cotto_work lucian: you mean something like apr?
22:56 lucian that, or nspr or glib
22:56 benabik Wasn't someone talking about glib interop?
22:57 cotto_work Historically, we've tried to be very minimal in our dependencies.
22:57 cotto_work benabik: that's GObject interop at the PMC level
22:57 lucian cotto_work: but doesn't that involve a lot of new wheels?
22:57 lucian like with threads. either one of those gives you threads, presto
22:57 lucian at least locks
22:58 bubaflub left #parrot
23:03 dalek parrot/get-entropy: 8f424c1 | cotto++ | / (5 files):
23:03 dalek parrot/get-entropy: shorten entropy function name, implement error checking/reporting
23:03 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/8f424c1191
23:03 benabik left #parrot
23:08 cotto_work lucian: I'll have to dig around to form a proper response to that.  I think a big reason we're not using something like apr is that it'd limit the potential for embedded applications, but honestly it's an assumption that I've inherited and not thought about a lot.
23:09 lucian i see. it's just one more of the things i run background tasks in my brain for
23:09 lucian cotto_work: myself, i rather like glib, and vala to some extent
23:12 lucian it might even be interesting to couple PMCs and gobject more closely, or even base PMC on gobject
23:13 lucian but that's a lot of work with little clear benefit
23:13 cotto_work yeah
23:17 Caelum left #parrot
23:19 lucian well, there are clear benefits
23:20 whiteknight joined #parrot
23:20 lucian but as you said, there may be features that can't be done easily this way
23:20 bacek_at_work cotto_work, can you try to revert 19962bf49db7a9fb7f60f54d17786a52f64758c4 locally? It's only one "big" change in GC which can cause this failure.
23:21 Khisanth left #parrot
23:22 Khisanth joined #parrot
23:24 cotto_work bacek_at_work: trying now
23:27 whiteknight what failure are we looking at?
23:27 * whiteknight needs to backlog
23:29 whiteknight bacek_at_work: I suspect we are going to need two new ops, one to pass :flat args and one to gather :slurpy args. Both of those things could also be done using loops/iterators or even the old slice vtable
23:29 cotto_work whiteknight: mingw build 'splosion
23:30 lucian left #parrot
23:30 bubaflub joined #parrot
23:31 dalek parrot/get-entropy: 0596d98 | cotto++ | src/platform/win32/entropy.c:
23:31 dalek parrot/get-entropy: add missing semicolon
23:31 dalek parrot/get-entropy: review: https://github.com/parrot/parrot/commit/0596d98514
23:34 cotto_work bacek_at_work: same failure after reverting that commit
23:35 bacek_at_work cotto_work, oookey.
23:35 bacek_at_work cotto_work, what about reverting 6f0cfa824ff117c6731ab47320e0375402f14e80?
23:36 bacek_at_work cotto_work, or even better - just bisect RELEASE_3_3_0..HEAD
23:36 cotto_work or that
23:38 cotto_work might be a while
23:40 whiteknight I can debug it tomorrow in VisualStudio if needed
23:40 whiteknight I didn't have time for that earlier today
23:40 cotto_work whiteknight: good to know
23:40 cotto_work we'll see how far I can get
23:40 whiteknight ok
23:46 rurban_ joined #parrot
23:48 KaeseEs has anyone started on the m0 disassembler? i have some tuits tonight and tomorrow
23:48 rurban left #parrot
23:48 rurban_ is now known as rurban
23:49 hudnix left #parrot
23:53 cotto_work KaeseEs: it's all yours
23:53 cotto_work KaeseEs: please do any m0-related work in the m0-prototype branch

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced