Camelia, the Perl 6 bug

IRC log for #parrot, 2012-04-03

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:02 cotto nbrown, hio
00:04 Justin hello
00:06 cotto hi Justin
00:06 nbrown cotto: hi, whiteknight said I could talk to you or dukeleto about m0
00:06 whiteknight yessir
00:07 nbrown cotto: my main issue is that Jimmy and I seem to be developing at odds right now and I'm trying to figure out how to move forward
00:07 cotto nbrown, we're the usual suspects in that area
00:08 nbrown cotto: execellent :)
00:08 cotto nbrown, ok.  what's the question?
00:09 whiteknight cotto: When you have a moment, I'd like your feedback about security
00:09 nbrown cotto: I'm trying to implement the spec and in order to do it I put in some detection of which register is being operated on in the deref operation so that it can tell the difference between IN registers and SP registers since the first are value based and the second are pointer based. Is that the correct approach?
00:10 nbrown cotto: I think Jimmy wants to pursue a register that is a union of different types
00:12 cotto nbrown, let me dig up the spec for a second
00:13 nbrown cotto: I got all of the m0 tests except the hash and poke caller tests working using that method and single precision floats over the weekend, but had my commits basically reverted because of the conflict of my approach and jimmy's...
00:13 nbrown cotto: I'm not complaining in the least, I'm just trying to understand the path ahead so I can help rather than hinder :)
00:15 nbrown right now, I'm taking a break from the c implementation to take a look at the perl implementation and get it to pass all tests again with double precion floats instead of single precision
00:17 cotto nbrown, M0 registers are just a bunch of bytes that are interpreted to be INSP by the op that's operating on them.  Why does deref need to know about the type of a register at all?
00:18 nbrown Well, we could move that logic to the ops instead I guess
00:18 kurahaupo joined #parrot
00:19 nbrown cotto: but I'm not 100% sure about that...
00:19 cotto because M0 is low-level and simple, there are ops that won't make sense (and therefore shouldn't be generated by anything that generates M0)
00:21 nbrown i agree, give me a second
00:23 nbrown well, deref needs to understand the size of the data that it's loading into the register (like int and float = 4 bytes vs SP = 8 bytes)
00:24 cotto yeah.  that's why I don't like inconsistently-sized registers
00:24 nbrown and S&P registers hold addresses while I&N hold values
00:24 nbrown sure, but it's the registers of the constants that we load that cause the issue
00:25 dngor_ joined #parrot
00:26 nbrown the smaller I&N values cause issues. You need to zero out the register prior to loading to ensure that future goto_if's work as expected for example
00:26 nbrown that issue confused me for a while
00:26 cotto I can see why.
00:26 cotto dumbness is fine, but sharp edges like that are lta
00:26 nbrown I agree
00:27 nbrown I don't think the perl implementation had that issue because it zeroed out the registers on creation unlike c
00:28 nbrown my implementation also used single precision floats to align with the perl assembler, but I plan to clean that up soon
00:29 nbrown but that caused me to have to play pointer games instead of just casting whenever we wanted do numerical math ops
00:30 nbrown I wasn't loving it, but I didn't see another way around it
00:31 nbrown cotto: when you get a chance, could you take a look at my branch and let me know what you think? https://github.com/nbrown/parrot/tree/m0-c-new-ops
00:32 cotto nbrown, sure
00:32 nbrown cotto: I know it's not pretty, but I'm just getting back into c programming
00:33 nbrown cotto: on my machine it tends to crash the m0_integration.t test, but only because it can't handle the hash and poke_caller tests. It passes the rest of them
00:34 nbrown cotto: thanks, I'd appreciate it
00:37 cotto those are the tricky tests
00:37 nbrown cotto: true, plus I hadn't implemented the gc_alloc and whatnot required for the poke_caller
00:38 nbrown cotto: I was gonna take a shot at the hash one this week, but if I'm headed in the wrong direction, I want to get better aligned first
00:38 cotto nbrown, sure
00:42 workbench joined #parrot
00:45 cotto Hmmm.  The spec doesn't specify floating point precision.
00:45 cotto that's kinda important
00:45 nbrown cotto: yes it does
00:46 nbrown cotto: let me find it
00:47 nbrown "N registers are 8 bytes wide. By default, instructions which work with N registers will assume IEEE 754 64-bit semantics."
00:47 cotto ah.  I was looking for "double" and "single".
00:47 nbrown cotto: although those by default statements worry me a little
00:48 nbrown cotto: how does one get anything other than the default interpretation?
00:48 cotto nbrown, I'm not sure what "by default" there means.
00:49 nbrown cotto: the phrase by default also shows up "By default, instructions which work with integer values will assume that I registers are unsigned."
00:49 nbrown cotto: I'm glad I'm not the only one
00:51 cotto nbrown, feel free to remove that.  It doesn't make the spec easier to understand.
00:53 nbrown cotto: cool, I'll submit a pull request that removes that phrase as appropriate
00:53 cotto nbrown, you don't have a commit bit?
00:53 nbrown nope
00:54 nbrown cotto: i played with m0 a little last year, disappeared forever and am just getting back into it
00:54 cotto nbrown, welcome back then
00:54 nbrown cotto: thanks
01:05 benabik joined #parrot
01:12 alvis```` joined #parrot
01:13 bacek_at_work aloha, humans
01:19 cotto aloha, bacek_at_work
01:19 bacek_at_work hio cotto
01:28 whiteknight hello bacek
01:29 bacek_at_work whiteknight
01:29 bacek_at_work quick question: should C<current_object> be part of C<Context> or C<CallSignature>
01:29 whiteknight context, I think
01:29 bacek_at_work (related to unmerge_context)
01:29 bacek_at_work whiteknight, why?
01:30 bacek_at_work it's "object for next call"
01:30 whiteknight no, you're right
01:30 whiteknight signature
01:30 bacek_at_work ok
01:30 whiteknight don't ask me a third time!
01:30 benabik whiteknight: why?
01:30 benabik ;-D
01:31 benabik It's it's "object for next call", why is it _current_ object?
01:31 bacek_at_work benabik, legacy of dark age
01:32 bacek_at_work actually, it was part of interp before I moved it into CallContext.
01:32 bacek_at_work now it's time for next move :)
01:33 bacek_at_work actually...
01:33 bacek_at_work Why do we need "current_object"?
01:33 bacek_at_work Isn't it just first parameter in Signature for method calls?
01:33 bacek_at_work Or I missed something really obvious?
01:34 benabik Sometimes it's Parrot that's missed the really obvious.
01:38 bacek_at_work benabik, yeah... Looks like it always goes in pairs: push_pmc and set_object. Smells like a bit of redundancy for me.
01:39 benabik Does anything _use_ current object?
01:40 bacek_at_work benabik, erm... May be some "introspection like API"?
01:40 bacek_at_work definitely not through standard PCC call mechanizm
01:43 dalek parrot/bacek/unmerge_context: 186a1c5 | bacek++ | src/pmc/callsignature.pmc:
01:43 dalek parrot/bacek/unmerge_context: Reorder static functions in CallSignature PMC
01:43 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/186a1c58fc
01:43 dalek parrot/bacek/unmerge_context: ff07689 | bacek++ | / (2 files):
01:43 dalek parrot/bacek/unmerge_context: Hack to disable set/get object
01:43 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/ff0768972a
01:43 bacek_at_work whiteknight, if you can have a look.
01:44 bacek_at_work whiteknight, t/op/exceptions.t ................... 22/32 Can't exec "./winxed": No such file or directory at t/op/exceptions.t line 706.
01:44 bacek_at_work looks like there is some wrong tests which shouldn't be executed after make corevm/coretest
01:44 whiteknight bacek_at_work: current_object is used to tell whether a function is a method or not
01:45 bacek_at_work whiteknight, from where?
01:45 whiteknight I don't know if we *should* do that
01:45 bacek_at_work we are putting implicit unpack of "self" inside :methods
01:45 bacek_at_work why do we need more?
01:46 bacek_at_work and afaiu self == current_object
01:47 bacek_at_work or even "==="
01:50 bacek_at_work (After my latest commit parrot build in full. And only few not related tests failed)
01:50 bacek_at_work Even TGE passed all tests
01:52 bacek_at_work something like this https://gist.github.com/2288708
01:52 whiteknight we need to kill implicit self
01:53 benabik whiteknight: +1
01:53 Tene +1
01:54 bacek_at_work whiteknight, erm... Why?
01:55 bacek_at_work aloha, https://gist.github.com/2288708
01:55 aloha bacek_at_work: [ unmerge_context test results -- Gist ]
01:57 bacek_at_work whiteknight, anyway. Even with explicit "self" equivalence of "current_object" and "self" still hold
01:57 bacek_at_work I would like to kill C<current_object>. Right now
01:59 bacek_at_work it's not used in rakudo and nqp.
01:59 bacek_at_work And it's not needed for PCC
02:00 bacek_at_work Looks like leftover
02:00 bacek_at_work from previous PCC refactor
02:00 bacek_at_work cotto, any objections?
02:00 dalek Rosella: 6725abf | Whiteknight++ | VERSION:
02:00 dalek Rosella: [Build] Update VERSION
02:00 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/6725abfb53
02:00 dalek Rosella: b9f2783 | Whiteknight++ | s (5 files):
02:00 aloha [ [Build] Update VERSION * 6725abf * Whiteknight/Rosella * GitHub ]
02:00 dalek Rosella: [Xml] Re-write the Xml parser using the same lookahead technique as I used with the Json parser. This should (in theory) allow both parsers to handle non-ascii strings
02:00 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/b9f2783a1e
02:00 aloha [ [Xml] Re-write the Xml parser using the same lookahead technique as I us... * b9f2783 * Whiteknight/Rosella * GitHub ]
02:01 benabik ...  Is aloha announcing commits now?
02:02 bacek_at_work benabik, nope... Just link titles
02:02 bacek_at_work I'll unload this module
02:02 benabik Ah.  Pity, that's a useful feature.  But somewhat unnecessary to do for dalek.
02:03 bacek_at_work I think I can set it up to ignore github commit links
02:03 bacek_at_work but not now
02:03 cotto bacek_at_work, just leaving.  will take a gander after dinner
02:03 whiteknight bacek: I'll look at it tomorrow. Right now is bed time
02:06 PerlJam joined #parrot
02:07 Util joined #parrot
02:07 pmichaud joined #parrot
02:07 tadzik joined #parrot
02:12 Coke joined #parrot
02:12 masak joined #parrot
02:16 he joined #parrot
02:22 Justin @benabik, hello are you still on. I have a quick question
02:22 benabik Justin: shoot
02:23 Justin I saved the timeline for last. Im trying to figure out how to break the core project down into smaller blocks. Besides adding the permissions/restrictions I was thinking of dividing this project into 3 main pieces, Interface, permissions/restrictions and implementation. WHat do you think?
02:23 Justin RIght now I am working off limited knowledge so I know there are key aspects that I am missing
02:23 Justin any suggestions?
02:24 benabik Well, I'm not completely certain of your project, but it sounds good.  I generally just keep trying to break things into smaller sensible bits.
02:29 aloha joined #parrot
02:30 bacek_at_work joined #parrot
02:51 dalek parrot: 53a07f9 | petdance++ | src/platform/generic/dl.c:
02:51 dalek parrot: Added ASSERT_ARGS calls
02:51 dalek parrot: review: https://github.com/parrot/parrot/commit/53a07f9d39
02:52 dalek parrot: 5b6d3dc | petdance++ | src/platform/generic/dl.c:
02:52 dalek parrot: the arg to remove_handle_entry() can be NULL
02:52 dalek parrot: review: https://github.com/parrot/parrot/commit/5b6d3dc4f8
03:02 bacek_at_work cotto, meh... We even have test to check that "current_object" === "self". https://github.com/parrot/parrot/bl​ob/master/t/pmc/object-meths.t#L651
03:04 aloha (parrot/parrot) Issues opened : 754 (M0 double precision) by nbrown : https://github.com/parrot/parrot/issues/754
03:28 Justin joined #parrot
04:04 Justinlh joined #parrot
04:04 Justinlh left #parrot
05:34 dalek parrot: c32af4b | bacek++ | src/platform/generic/dl.c:
05:34 dalek parrot: Fix push_handle_entry signature. NULL handles are kind of valid
05:34 dalek parrot: review: https://github.com/parrot/parrot/commit/c32af4bebf
05:34 dalek parrot/kill_current_object: 8f5eff6 | bacek++ | / (17 files):
05:34 dalek parrot/kill_current_object: Get rid of CallContext.current_object. It's useless
05:34 dalek parrot/kill_current_object: review: https://github.com/parrot/parrot/commit/8f5eff69dd
05:36 bacek_at_work msg cotto I would like to merge kill_current_object branch asap :)
05:36 aloha OK. I'll deliver the message.
06:15 alvis joined #parrot
06:21 fperrad joined #parrot
06:23 moritz all rakudo spectests pass on top of parrot/kill_current_object
06:23 moritz bacek_at_work++
06:23 bacek_at_work moritz, making parrot better one step at the time :)
06:24 moritz increasing bacek_at_work's karma one at a time :-)
06:24 bacek_at_work moritz, :)
06:30 dalek Heuristic branch merge: pushed 23 commits to parrot/ayardley/parrot_github_release by ayardley
07:25 lucian_ joined #parrot
08:02 dalek parrot/kill_current_object: de3545f | moritz++ | src/pmc/sub.pmc:
08:02 dalek parrot/kill_current_object: remove unused variable
08:02 dalek parrot/kill_current_object: review: https://github.com/parrot/parrot/commit/de3545f1a8
08:40 lucian joined #parrot
08:45 pjcj joined #parrot
08:46 dalek parrot/pcc_reorder_signatures: ef150bc | bacek++ | / (3 files):
08:46 dalek parrot/pcc_reorder_signatures: Add CallContext.temporary_context to preserve existing behaviour of CallContext creation on caller side
08:46 dalek parrot/pcc_reorder_signatures: review: https://github.com/parrot/parrot/commit/ef150bc971
08:46 dalek parrot/pcc_reorder_signatures: d13f53c | bacek++ | / (2 files):
08:46 dalek parrot/pcc_reorder_signatures: Rename merge_signature to merge_context to reflect reality
08:46 dalek parrot/pcc_reorder_signatures: review: https://github.com/parrot/parrot/commit/d13f53c876
08:46 dalek parrot/pcc_reorder_signatures: 33c9658 | bacek++ | / (2 files):
08:46 dalek parrot/pcc_reorder_signatures: Fix get_next_context accessor
08:46 dalek parrot/pcc_reorder_signatures: review: https://github.com/parrot/parrot/commit/33c96585e9
08:47 bacek oh shi...
08:47 nine ?
08:47 bacek wrong branch pushed
08:48 nine oops
08:57 dalek parrot/bacek/unmerge_context: 53a07f9 | petdance++ | src/platform/generic/dl.c:
08:57 dalek parrot/bacek/unmerge_context: Added ASSERT_ARGS calls
08:57 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/53a07f9d39
08:57 dalek parrot/bacek/unmerge_context: 5b6d3dc | petdance++ | src/platform/generic/dl.c:
08:57 dalek parrot/bacek/unmerge_context: the arg to remove_handle_entry() can be NULL
08:57 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/5b6d3dc4f8
08:57 dalek parrot/bacek/unmerge_context: c32af4b | bacek++ | src/platform/generic/dl.c:
08:57 dalek parrot/bacek/unmerge_context: Fix push_handle_entry signature. NULL handles are kind of valid
08:57 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/c32af4bebf
08:57 dalek parrot/bacek/unmerge_context: 8f5eff6 | bacek++ | / (17 files):
08:57 dalek parrot/bacek/unmerge_context: Get rid of CallContext.current_object. It's useless
08:57 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/8f5eff69dd
08:57 dalek parrot/bacek/unmerge_context: de3545f | moritz++ | src/pmc/sub.pmc:
08:57 dalek parrot/bacek/unmerge_context: remove unused variable
08:57 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/de3545f1a8
08:57 dalek parrot/bacek/unmerge_context: 2ed595c | bacek++ | / (18 files):
08:57 dalek parrot/bacek/unmerge_context: Merge remote-tracking branch 'origin/kill_current_object' into bacek/unmerge_context
08:57 dalek parrot/bacek/unmerge_context:
08:57 dalek parrot/bacek/unmerge_context: Conflicts:
08:57 dalek parrot/bacek/unmerge_context: include/parrot/context.h
08:57 dalek parrot/bacek/unmerge_context: src/call/context_accessors.c
08:57 dalek parrot/bacek/unmerge_context: src/ops/core_ops.c
08:57 dalek parrot/bacek/unmerge_context: src/pmc/callsignature.pmc
08:57 dalek parrot/bacek/unmerge_context: src/pmc/sub.pmc
08:57 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/2ed595c23c
08:58 bacek hmm...
08:58 bacek should have used --no-ff for it...
08:58 bacek or squash
08:58 bacek or whatever...
09:06 dalek parrot/bacek/unmerge_context: 0bcab54 | bacek++ | t/pmc/context.t:
09:06 dalek parrot/bacek/unmerge_context: Fix test.
09:06 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/0bcab545bc
09:06 dalek parrot/bacek/unmerge_context: c2b429c | bacek++ | config/gen/makefiles/root.in:
09:06 dalek parrot/bacek/unmerge_context: Fix dependencies.
09:06 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/c2b429c9ba
09:06 dalek parrot/bacek/unmerge_context: 0cbf8d0 | bacek++ | t/pmc/callsignature.t:
09:06 dalek parrot/bacek/unmerge_context: Fix test.
09:06 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/0cbf8d0b08
09:06 dalek parrot/bacek/unmerge_context: 3b856b9 | bacek++ | t/op/cc_params.t:
09:06 dalek parrot/bacek/unmerge_context: Fix test
09:06 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/3b856b9561
09:06 dalek parrot/bacek/unmerge_context: d2867c1 | bacek++ | t/pmc/parrotinterpreter.t:
09:06 dalek parrot/bacek/unmerge_context: Fix test.
09:06 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/d2867c1333
09:23 bacek who the heck wrote result_info op?
09:23 bacek hmm...
09:23 bacek nm
09:30 Timbus joined #parrot
10:13 dalek parrot/bacek/unmerge_context: 1b6fa60 | bacek++ | t/src/embed/pmc.t:
10:13 dalek parrot/bacek/unmerge_context: Fix test
10:13 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/1b6fa60833
10:13 dalek parrot/bacek/unmerge_context: 4c84bf3 | bacek++ | t/src/embed/api.t:
10:13 dalek parrot/bacek/unmerge_context: Fix test
10:13 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/4c84bf3a42
10:49 kid51 joined #parrot
10:49 bacek YAY!
10:49 dalek parrot/bacek/unmerge_context: 4e7b290 | bacek++ | t/pmc/callcontext.t:
10:49 dalek parrot/bacek/unmerge_context: Remove outdated test
10:49 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/4e7b2909c5
10:49 dalek parrot/bacek/unmerge_context: e790524 | bacek++ | / (6 files):
10:49 dalek parrot/bacek/unmerge_context: Move return_flags to Context. CallSignature hold only params, not expected returns
10:49 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/e79052410d
10:50 bacek ok, this branch is ready
10:50 bacek kind of
10:50 kid51 ?
10:51 kid51 What is the purpose of the branch?  What would a code reviewer want to look at?
10:52 bacek kid51, it's undoing my 2 years old branch of merging Context and CallSignature.
10:52 bacek just to prepare to switch of allocating of Context on callee side
10:53 bacek which will help with clearing of quite few parrot guts.
10:53 bacek actually...
10:53 bacek Context is already allocated on callee side. I just need a bit of tailcall optimisations
10:53 kid51 Suppose I were to do a diff between master and branch.  Which files would I really want to study to see the differences?
10:55 bacek context.pmc, callsignature.pmc, src/call/*c
10:56 kid51 Thx
10:57 bacek msg moritz If you have time can you benchmark bacek/unmerge_context branch? I expect it to be 5% _slower_ in current state.
10:57 aloha OK. I'll deliver the message.
10:58 kid51 Will we eventually recover that 5%?  (For some definition of "eventually"? ;-) )
11:01 bacek kid51, yes, of course :)
11:03 benabik joined #parrot
11:11 dalek parrot/bacek/unmerge_context: 14b30aa | bacek++ | t/ (2 files):
11:11 dalek parrot/bacek/unmerge_context: Fix leftover renames.
11:11 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/14b30aa661
11:11 dalek parrot/bacek/unmerge_context: 481932d | bacek++ | src/embed/api.c:
11:11 dalek parrot/bacek/unmerge_context: Fix embed call for reset callsignature.
11:11 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/481932d789
11:15 dalek parrot/bacek/unmerge_context: b7c6805 | bacek++ | src/ops/core (2 files):
11:15 dalek parrot/bacek/unmerge_context: More aggressively reuse CallSignature for subsequent calls
11:15 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/b7c68052f3
11:15 bacek kid51, ^^^ This should recover some of it :)
11:46 moritz bacek: nqp build fails on parrot/bacek/unmerge_context
11:46 moritz sixmodelobject.c: In function ‘decontainerize’:
11:46 moritz sixmodelobject.c:70: error: ‘enum_class_CallContext’ undeclared (first use in this function)
11:47 moritz which kinda makes benchmarking a lot harder :-)
11:58 dalek parrot/bacek/unmerge_context: c9f7a9f | jkeenan++ | MANIFEST:
11:58 dalek parrot/bacek/unmerge_context: Update MANIFEST to reflect recent addition/subtraction.
11:58 dalek parrot/bacek/unmerge_context: review: https://github.com/parrot/parrot/commit/c9f7a9f7fa
11:59 benabik joined #parrot
12:17 kid51 src/pmc/callsignature.pmc will need POD
12:26 benabik What is this 'documentation' you speak of?  We know not of that in these lands.
12:31 PacoAir joined #parrot
13:15 dalek Rosella: f31dfc2 | Whiteknight++ | src/ (2 files):
13:15 dalek Rosella: [Xml] Some parser fixes after the upgrade
13:15 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/f31dfc243d
13:15 dalek Rosella: 8850f9f | Whiteknight++ | src/unstable/xml/ (2 files):
13:15 dalek Rosella: [Xml] Refactor node handling and Document to be simpler. Don't store multiple references to each tag in the document. Fix raw text handling
13:15 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/8850f9f436
13:17 whiteknight joined #parrot
13:17 whiteknight good morning, #parrot
13:20 nine Good afternoon, whiteknight
13:21 whiteknight hello nine. How are you doing today?
13:23 nine whiteknight: tired. Same as the last week or two. I guess I'm in serious need of vacation
13:27 whiteknight yeah, you and me both
13:28 whiteknight we finally doped the kid up with some allergy medicine last night, so we were able to get a few hours of uninterrupted sleep
13:29 nine Funny how such a basic thing can become such a luxury
13:32 whiteknight seriously
13:34 benabik o/ whiteknight
13:35 moritz currently the small one wakes up once around 10:30pm, and then sleeps through until 6am. What a joy!
13:35 moritz (that is, that's how it was the last two nights)
13:36 whiteknight moritz: ours has been waking up around 3am, which is totally awesome
13:38 moritz whiteknight: the awesomeness of that is probably a question of perspective
13:38 whiteknight my perspective is extremely sarcastic
13:39 nine With everyone here just craving sleep it's a wonder that we make any progress at all ;)
13:39 whiteknight nine: progress is also a matter of perspective
13:39 whiteknight We certainly do move a lot of code around, for good or ill
13:40 nine true, true
13:40 * moritz liked 8f5eff69ddce5d95bf60ee70653acde7a5b57a46
13:44 whiteknight link?
13:45 moritz whiteknight: https://github.com/parrot/parrot/commit/​8f5eff69ddce5d95bf60ee70653acde7a5b57a46
13:45 whiteknight oh yeah, bacek is a whirlwind
13:57 Justinlh joined #parrot
13:58 JimmyZ joined #parrot
14:08 Justin joined #parrot
14:16 Justin joined #parrot
15:32 dalek parrot/m0: b6705e1 | jimmy++ | src/m0/ (2 files):
15:32 dalek parrot/m0: add prototype of new ops
15:32 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/b6705e1c1d
15:42 dalek parrot/m0: ab85c1c | jimmy++ | src/m0/ (2 files):
15:42 dalek parrot/m0: fixed thinko
15:42 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/ab85c1c9bd
15:42 alester joined #parrot
15:42 lucian joined #parrot
15:45 dalek parrot/m0: f35c986 | jimmy++ | / (5 files):
15:45 dalek parrot/m0: Merge pull request #754 from nbrown/m0-double-precision
15:45 dalek parrot/m0:
15:45 dalek parrot/m0: M0 double precision
15:45 dalek parrot/m0: review: https://github.com/parrot/parrot/commit/f35c986f39
15:46 JimmyZ aloha: help
15:46 aloha JimmyZ: Ask me for help about: msg, convert, status, vars, karma, auth, chanop, seen, maths, github::announce, infobot, clock, translate, github::pullrequests, loader, xkcd (say 'help <modulename>').
15:50 aloha (parrot/parrot) Issues closed : 754 (M0 double precision) by nbrown : https://github.com/parrot/parrot/issues/754
16:11 dmalcolm joined #parrot
16:12 rich joined #parrot
16:44 dalek rakudo/nom: 1bbf9eb | pmichaud++ | src/core/Any.pm:
16:44 dalek rakudo/nom: Fix slicing of non-lists with infinite ranges (RT #112216, timotimo++).
16:44 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1bbf9ebbd2
16:55 nopaste joined #parrot
17:14 lateau joined #parrot
17:15 lateau left #parrot
17:15 lateau joined #parrot
17:16 lateau left #parrot
17:20 lucian_ joined #parrot
17:55 dukeleto ~~
17:57 Justin joined #parrot
17:59 whiteknight hello dukeleto
18:01 alvis joined #parrot
18:19 nine Does anyone have an idea what context_gc_mark is about?
18:21 dalek rakudo/nom: 4373f09 | moritz++ | src/core/ (2 files):
18:21 dalek rakudo/nom: throw typed X::OutOfRange exception from Any.at_pos
18:21 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4373f09f61
18:27 whiteknight nine: I think it marks interp->current_context and tree
18:32 nine whiteknight: ack tells me it's only used in src/sub.c (it's a static int). I think it's dead code
18:32 whiteknight oh, I might be thinking of something else
18:32 whiteknight try ripping it out and see what happens
18:35 benabik Looks dead to me
18:35 rich joined #parrot
18:35 benabik The whole function Parrot_sub_context_start looks dead to me.
18:36 benabik Wait...  I misspelled my ack
18:36 benabik Well, it looks pointless anyway.
18:37 nine no smoke so far
18:37 Coke smoke! I am reminded to hack on muddle more.
18:37 nine Well, removed code is debugged code
18:38 Coke nine++
18:39 nine whiteknight: seems like my success message on Sunday was a bit premature. I still run into random GC problems and segfaults when creating and scheduling a million very short lived tasks
18:40 whiteknight nine: we should be fine with 900,000 or less
18:40 whiteknight :)
18:41 nine The thing is: I added assertions making sure that each PMC is on the interp where it belongs. I added tons of those in every GC function I could find. But still foreign PMCs show up in the work_list and dirty_list but not before.
18:42 whiteknight weird
18:42 whiteknight what kinds of PMCs are these? The type might tell you where they are coming from
18:43 whiteknight Can you add the assertions to the work_list and dirty_list insertion functions?
18:43 whiteknight Actually, I think those are macros
18:46 nine It's mostly CallContexts and Continuations but not only. I've seen Proxys as well. Since pretty much all I do is creating tasks which do nothing these are just the most common objects so I don't think their type is really revealing.
18:46 nine And the strangest thing of all: these PMCs are not from the main thread. They are from other child threads which should never happen at all since all child threads communicate exclusively with the main thread.
18:48 whiteknight That is weird
18:48 whiteknight yeah, my best suggestion is to add asserts to the macros for adding things to those lists
18:49 nine The only explanation I could imagine would be that the GC maybe scanning foreign memory blocks for pointers. But I've yet to confirm this with some assertion.
18:49 whiteknight even then, the GC's pointer detection would make sure it's in the pool of the current interp
18:53 whiteknight The GC does have functions to allocate memory blocks which might contain pointers
18:54 nine I already have assertions in those places.
18:54 whiteknight okay
18:54 nine Oh, now it even found a ParrotInterpreter PMC. A rare catch
18:54 whiteknight and you have no idea how it ends up on that list?
18:55 nine gc_gms_check_sanity found it in the objects list for generation 1
18:55 whiteknight wtf
18:59 hercynium joined #parrot
19:00 nopaste joined #parrot
19:00 nine Just checked every place where objects end up in the work_list, dirty_list and objects lists. Each one is protected by an assertion. There should be no way a foreign PMC might make it onto those lists.
19:04 nine It's fitting that gc_gms_check_sanity is the one finding those since this is clearly an insane situation :)
19:09 benabik gc_gms_check_sanity() { return FALSE; }
19:11 whiteknight those lists are linked-lists, right? Are there functions that move an item from one list to another?
19:13 nine They are Parrot Pointer Arrays
19:15 whiteknight we may have to ask bacek if he has insight
19:21 whiteknight I can fire it up tonight and take a look
19:22 nine Any help would be greatly appreciated
19:24 whiteknight yeah, sure
19:24 nine whiteknight: I pushed my current work version to git@github.com:niner/parrot.git threads_playground
19:24 whiteknight okay
19:30 nine btw. it's #ps time
19:38 whiteknight blah! I can never remember this damned meeting
19:39 whiteknight ...is anybody else in there?
19:50 marcel_r joined #parrot
20:14 nine Good night, #ps
20:15 nine Good night, #parrot even
20:23 whiteknight goodnight
20:32 perlite_ joined #parrot
20:58 lucian_ joined #parrot
22:14 hercynium left #parrot
22:25 betterworld joined #parrot
22:45 nbrown joined #parrot
23:02 benabik left #parrot
23:14 kid51 joined #parrot
23:57 whiteknight joined #parrot

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

Parrot | source cross referenced