Camelia, the Perl 6 bug

IRC log for #parrot, 2011-05-01

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 lucian left #parrot
00:02 whiteknight I really need to talk to jnthn about that soon
00:02 * tcurtis is slightly amused by how fervently DeRemer disclaims the practical importance of fully general LALR(k) parsing in his dissertation.
00:03 whiteknight tcurtis: link?
00:03 tcurtis whiteknight: http://computer-refuge.org/bitsaver​s/pdf/mit/lcs/tr/MIT-LCS-TR-065.pdf
00:04 whiteknight oh wow. Hah. I love reading papers this old
00:04 whiteknight some of the best papers I ever read were from Dijkstra
00:05 tcurtis whiteknight: In Chapter 3 and 4 he develops parsing techniques for LR(0) and SLR(k) parsers, and in Chapter 5 he generalizes to LALR(k) and general LR(k) (I think).
00:05 whiteknight okay, cool
00:05 whiteknight so this is definitely something I want to read
00:05 whiteknight I need to pull out my dragon book too, methinks
00:05 sorear in a lot of real world cases languages are designed by people who understand parsing technology
00:06 sorear you need a LALR(1) parser if you want to parse a language designed by a yacc user
00:06 whiteknight LALR(1) parsers have a lot of benefits
00:06 whiteknight not the least of which is quick failure
00:09 whiteknight that is something easily overlooked
00:10 whiteknight tcurtis: oh, it's 219 pages. Will take me some time to read
00:16 whiteknight I am excited about the prospect of LALR on Parrot
00:16 whiteknight I was the one who suggested the topic in the first place
00:17 whiteknight all we need now is a good tokenizing library for the frontend
00:28 ShaneC left #parrot
00:35 * tcurtis needs to come up with a name for his GSoC project.
00:36 whiteknight "tyler's awesome freaking lalr thingy"
00:36 whiteknight taflalrt
00:39 bubaflub could be LinewALkeR
00:39 bubaflub i guess wholesaler would work as well
00:57 whiteknight pyacc
00:57 whiteknight pison
00:57 whiteknight anyway, I've had enough bad ideas for one night. I'm going to bed
00:57 whiteknight later
00:57 whiteknight left #parrot
01:55 crankin joined #parrot
02:00 crankin clear
02:00 crankin left #parrot
02:01 crankin joined #parrot
02:03 crankin left #parrot
02:04 crankin joined #parrot
02:05 crankin Is this channel dead?
02:05 crankin left #parrot
02:18 bubaflub nope
02:41 JimmyZ joined #parrot
02:59 soh_cah_toa agh! i just spent all day building an rpm .spec file for parrot only to find that there already is one!
03:00 JimmyZ left #parrot
03:17 hudnix left #parrot
03:27 soh_cah_toa left #parrot
03:49 dukeleto ~~
03:53 cotto I hereby dub whiteknight++ as our magical blogging robot.
03:54 dukeleto msg whiteknight your new name, as decided by cotto++, is "The Magic Blogging Robot". We'll help you change your legal name.
03:54 aloha OK. I'll deliver the message.
04:01 Andy joined #parrot
04:01 Andy What is in src/call/*.c?
04:02 Andy I'm trying to find where those funcs get called
04:03 cotto calling conventions
04:07 tcurtis left #parrot
04:07 dukeleto Andy: search for _pcc
04:07 tcurtis joined #parrot
04:07 * dukeleto is having an M0 mindmeld with cotto++
04:08 Andy Perhaps some of the functions in src/call/*.c need not be flagged as exported then?
04:09 Andy Im' trying to find what it was that looked like it wasn't getting used outside of src/call/*
04:09 dukeleto Andy: hmmm. some probably, but not all.
04:10 dukeleto Andy: in theory, some people might access them. In practice, they mostly only get used by parrot internals
04:11 woosley joined #parrot
05:11 dalek parrot: d2145a3 | petdance++ | / (2 files):
05:11 dalek parrot: consting pointer arguments, and removing unnecessary intermediate variables
05:11 dalek parrot: review: https://github.com/parrot/parrot/commit/d2145a3e63
05:11 Andy Yes, that's right, I found still more places to const.
05:11 Andy I thought I'd found them all.
05:12 Andy But no
05:20 dalek parrot/m0-spec: 90c8f75 | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
05:20 dalek parrot/m0-spec: add a note about the 3rd arg to print_s being arbitrary
05:20 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/90c8f75523
05:35 dalek parrot/tt1931-nci-parameters-deprecation: 2830c24 | plobsing++ | src/platform/generic/dl.c:
05:35 dalek parrot/tt1931-nci-parameters-deprecation: manage NULL dlsym handles properly
05:35 dalek parrot/tt1931-nci-parameters-deprecation:
05:35 dalek parrot/tt1931-nci-parameters-deprecation: A NULL handle actually means RTLD_DEFAULT on most platforms (notably linux), and
05:35 dalek parrot/tt1931-nci-parameters-deprecation: this has become the expected behaviour. This change formalizes the practice.
05:35 dalek parrot/tt1931-nci-parameters-deprecation: review: https://github.com/parrot/parrot/commit/2830c2491d
05:39 dalek parrot/m0-spec: 3f31f13 | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
05:39 dalek parrot/m0-spec: Consistently use the opcode name set_var
05:39 dalek parrot/m0-spec:
05:39 dalek parrot/m0-spec: Also, the order of arguments to set_var were made more intuitive for mere mortals.
05:39 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/3f31f138ef
05:45 woosley left #parrot
05:47 dalek parrot/tt1931-nci-parameters-deprecation: 1c272ab | plobsing++ | config/auto/opengl.pm:
05:47 dalek parrot/tt1931-nci-parameters-deprecation: dissable building opengl bindings if the thunk generator is going to crash and burn
05:47 dalek parrot/tt1931-nci-parameters-deprecation: review: https://github.com/parrot/parrot/commit/1c272ab330
05:47 dalek parrot/tt1931-nci-parameters-deprecation: dc68cb0 | plobsing++ | / (33 files):
05:47 dalek parrot/tt1931-nci-parameters-deprecation: Merge branch 'master' into tt1931-nci-parameters-deprecation
05:47 dalek parrot/tt1931-nci-parameters-deprecation: review: https://github.com/parrot/parrot/commit/dc68cb00c1
05:55 dalek parrot/m0-prototype: b6630d3 | dukeleto++ | t/m0/hello.m0:
05:55 dalek parrot/m0-prototype: Add an actual example M0 file that will be interpreted
05:55 dalek parrot/m0-prototype:
05:55 dalek parrot/m0-prototype: This M0 code will be used as the first test for parsing M0 source code,
05:55 dalek parrot/m0-prototype: generating the relevant bytecode and then running that bytecode.
05:55 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/b6630d3b01
05:57 cotto left #parrot
05:57 cotto joined #parrot
06:02 dalek parrot/m0-prototype: 3a11657 | dukeleto++ | t/m0/hello.m0:
06:02 dalek parrot/m0-prototype: Add enlightening comments to our M0 source code
06:02 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/3a11657296
06:03 dalek parrot: c9da673 | petdance++ | src/call/pcc.c:
06:03 dalek parrot: fixed headerization of is_invokable
06:03 dalek parrot: review: https://github.com/parrot/parrot/commit/c9da673429
06:03 dalek parrot: 06bb92c | petdance++ | src/ (2 files):
06:03 dalek parrot: headerizing previously unheaderized functions
06:03 dalek parrot: review: https://github.com/parrot/parrot/commit/06bb92cc59
06:06 Andy left #parrot
06:09 bubaflub left #parrot
06:21 dalek parrot/m0-spec: a6d7840 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
06:21 dalek parrot/m0-spec: spell out M0 execution, define "chunk"
06:21 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/a6d7840d49
06:21 dalek parrot/m0-spec: a12576c | cotto++ | docs/pdds/draft/pdd32_m0.pod:
06:21 dalek parrot/m0-spec: add mostly-empty section spelling out what we need from control flow
06:21 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/a12576cde8
06:44 dukeleto seen cgaertner
06:44 aloha cgaertner was last seen in #parrot 28 days 16 hours ago saying "btw, who would be willing to mentor the project? the proposal template ask for that information, I I don't remeber anyone actually mentioning that...".
06:44 dukeleto seen cgaertner_
06:44 aloha Sorry, I haven't seen cgaertner_.
06:50 theory left #parrot
07:12 mtk left #parrot
07:18 mtk joined #parrot
08:03 dalek parrot/m0-prototype: b75c140 | dukeleto++ | .gitignore:
08:03 dalek parrot/m0-prototype: Ignore vim swap files in any subdirectory
08:03 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/b75c140ef1
08:03 dalek parrot/m0-prototype: 8520c66 | dukeleto++ | / (3 files):
08:03 dalek parrot/m0-prototype: Beginning of an M0 assembler in Perl 5
08:03 dalek parrot/m0-prototype:
08:03 dalek parrot/m0-prototype: After having an M0 mindmeld with cotto++, we decided that the dynop
08:03 dalek parrot/m0-prototype: implementation of M0 has served us well, but development should not
08:03 dalek parrot/m0-prototype: continue further. It greatly helped us define the M0 spec, but the
08:03 dalek parrot/m0-prototype: current impedance mismatch of having to use M0 from PIR is now blocking
08:03 dalek parrot/m0-prototype: us from completing the spec.
08:03 dalek parrot/m0-prototype:
08:03 dalek parrot/m0-prototype: This is an M0 prototype that we plan on throwing away, but which will
08:03 dalek parrot/m0-prototype: help us improve the spec further. There will be an assembler, which
08:03 dalek parrot/m0-prototype: eats M0 source code and spews out bytecode as binary data, and then
08:03 dalek parrot/m0-prototype: an M0 interpreter which actually executes the bytecode.
08:03 dalek parrot/m0-prototype:
08:03 dalek parrot/m0-prototype: This prototype aims to have a structure much like our final M0
08:03 dalek parrot/m0-prototype: implementation, but implemented in Perl 5 for maximum whipupitude.
08:03 dalek parrot/m0-prototype:
08:03 dalek parrot/m0-prototype: Also, the tests from this implementation will serve as the "M0 spec
08:03 dalek parrot/m0-prototype: tests" and will be quite useful for any implementation of M0.
08:03 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/8520c66f64
08:19 mj41 joined #parrot
08:37 fperrad joined #parrot
08:47 autark left #parrot
08:51 jjore left #parrot
08:52 jjore joined #parrot
09:35 autark joined #parrot
10:22 jrt4__ left #parrot
10:44 whiteknight joined #parrot
10:45 lucian joined #parrot
10:59 lucian whiteknight: sorry i left abruptly last night. my isp disconnected me and i didn't bother to fix it
11:27 lucian_ joined #parrot
11:30 lucian left #parrot
11:41 whiteknight lucian_: no worries. ISPs are the worst
11:42 whiteknight now it's my turn to leave abruptly, I have to go pick up the kid. I'll be back later
11:42 whiteknight left #parrot
11:45 lucian_ is now known as lucian
11:57 Patterner left #parrot
11:57 Psyche^ joined #parrot
11:58 Psyche^ is now known as Patterner
12:27 dalek parrot/jit_prototype: ea1641f | bacek++ | compilers/opsc/Rules.mak:
12:27 dalek parrot/jit_prototype: Add opsc build dependency on LLMV
12:27 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/ea1641fec8
12:27 dalek parrot/jit_prototype: 6610a93 | bacek++ | / (3 files):
12:27 dalek parrot/jit_prototype: [llvm] Extract defined types from LLMVModule and expose it via bindings
12:27 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/6610a93fe1
12:27 dalek parrot/jit_prototype: b029c56 | bacek++ | runtime/parrot/library/LLVM/Type.pm:
12:27 dalek parrot/jit_prototype: [llvm] Add more methods to LLVM::Type
12:27 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/b029c56d43
12:27 dalek parrot/jit_prototype: 5127ff6 | bacek++ | compilers/opsc/src/Ops/JIT.pm:
12:27 dalek parrot/jit_prototype: Initial cut of extracting of underlying struct type from llvm bitcode. Now we can generate proper accessor for something like 'interp->ctx'
12:27 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/5127ff68c1
12:40 dalek parrot/jit_prototype: 4d2e471 | bacek++ | compilers/opsc/ (4 files):
12:40 dalek parrot/jit_prototype: Add handcrafted structs definitions for future use in 'keyed' access
12:40 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/4d2e47119e
12:45 JimmyZ joined #parrot
12:48 dalek parrot/jit_prototype: c6b2f49 | bacek++ | compilers/opsc/src/Ops/JIT.pm:
12:48 dalek parrot/jit_prototype: Finish 'proper' handling of struct access
12:48 dalek parrot/jit_prototype: review: https://github.com/parrot/parrot/commit/c6b2f49a56
12:49 lucian left #parrot
12:50 lucian joined #parrot
13:04 benabik left #parrot
13:09 benabik joined #parrot
13:25 hudnix joined #parrot
13:28 whiteknight joined #parrot
13:34 whiteknight good morning again, #parrot
13:37 * lucian waves
13:37 whiteknight hello lucian
13:37 lucian i've just realised that a semispace gc can be trivially parallel
13:37 lucian anyway, i should get back to the dissertation
13:40 whiteknight :)
13:40 whiteknight that's quite a fun realizating
13:40 whiteknight realization
13:41 woosley joined #parrot
13:45 whiteknight I am going to fix Parrot-Instrument if it kills me
13:53 kid51 joined #parrot
14:02 birdwindupbird joined #parrot
14:12 sjn joined #parrot
14:37 whiteknight of course, at this rate it's very possible that I die first
14:39 kid51 left #parrot
14:46 lucian ok, DOM sucks. bigtime
14:56 whiteknight plobsing: ping
14:57 JimmyZ left #parrot
14:58 mtk left #parrot
15:05 mtk joined #parrot
15:11 plobsing whiteknight: pong
15:12 whiteknight plobsing: I'm still debugging Parrot-Instrument.
15:12 whiteknight plobsing: the parent interp creates a child interp and the two call methods on each other
15:12 whiteknight when I come back from a sequence of methods, the interp->code has some changes. The number of ops has changed, op_func_table and op_info_table too
15:13 whiteknight are those kinds of changes acceptable?
15:13 plobsing not within the same sub
15:13 plobsing but in general, those things do change a lot
15:13 whiteknight okay. I'm in an NCI method, which calls a method in the child interp, which in turn causes recursive calls to the parent interp
15:14 whiteknight so inside that NCI method, I shouldn't be seeing changes to the oplibs?
15:14 plobsing um, I'm not sure where the switch_to_cs() happens
15:15 plobsing within an NCI those don't really matter
15:16 whiteknight when I return from the NCI and go back to the runloop, it executes a weird op and has weirdness
15:16 whiteknight that is, it executes a load_language op, which appears nowhere in the test program
15:16 whiteknight and load_language is not the next op in the top-level sub
15:16 whiteknight so somewhere either the bytecode is changing from under us, or the way we interpret it is changing
15:18 plobsing or we're failing to switch code segments on the return
15:18 whiteknight interp->ctx was being changed, but I restored it and still have the problem
15:18 whiteknight interp->code and interp->current_pf are the same before and after the call
15:18 plobsing yeah, neither of those really matter much
15:18 whiteknight although the contents of interp->code that I mentioned were different
15:19 plobsing that is, current_pf and ctx. they shouldn't really be playing in to this problem
15:20 plobsing you can set data watchpoints in gdb. that might be informative
15:20 whiteknight At first I was worried that interp->ctx changing would change the pc when we got back up to the runloop. It doesn't
15:21 whiteknight I've set up a few of them. There are a hell of a lot of recursive calls though
15:24 whiteknight so when I get back to the runloop, is it a problem that interp->code->op_func_table and interp->code->op_info_table are completely different values?
15:25 plobsing well, yes. that's how we interpret bytecode
15:30 whiteknight that's what I figured
15:30 whiteknight so should I try to save and restore those fields, or should I try to figure out where they are being modified?
15:31 kid51 joined #parrot
15:31 plobsing I'd say you should try to figure out who is responsible for resetting those fields after a call and find out why they are not being reset
15:33 whiteknight okay
15:34 Coke__ left #parrot
15:34 Coke joined #parrot
15:45 jnthn__ When we create a fake executable, does it do anything to preserve the PBC name that it's the fake executable for?
15:46 jnthn__ Alternatively, is there a way to get the name of the PBC we're currently running?
15:52 woosley left #parrot
16:08 theory joined #parrot
16:25 dodathome joined #parrot
16:31 dalek nqp: 105839b | jonathan++ | src/ (2 files):
16:31 dalek nqp: Resolve issue #9 reported by masak++ that meant that use nqp; was not possible. Actually fixes the root issue which is that if you try to load a module that is the actual program that is running - even if it's in a compilation managed by that program.
16:31 dalek nqp: review: https://github.com/perl6/nqp/commit/105839b24b
16:58 cotto left #parrot
17:11 ambs joined #parrot
17:12 mj41 left #parrot
17:22 cotto joined #parrot
17:34 plobsing left #parrot
17:38 kid51 left #parrot
17:39 dukeleto ~~
17:39 cotto hio dukeleto
17:40 cotto I'm in the haskell building just about to blog
17:42 Coke left #parrot
17:42 cotto dukeleto, where are you at?
17:42 Coke joined #parrot
17:43 dukeleto cotto: sweet. I will be hanging in the OpenStreeMap session. Very informative.
17:43 cotto ok
17:44 cotto blogg'd
17:45 dukeleto cotto++
17:45 cotto and dukeleto++ for getting some tests written
17:46 dukeleto cotto: link for blog?
17:46 dukeleto cotto: i don't see it on the parrot aggregator yet
17:47 cotto dukeleto, http://reparrot.blogspot.com​/2011/05/m0ving-forward.html
17:48 * dukeleto reads
17:52 cotto Yay.  I have a reader!
17:54 cotto http://blog.bacek.com/2011/05/craz​y-jit-prototype-resurrection.html
17:57 bubaflub joined #parrot
18:08 dukeleto bubaflub: 'sup
18:09 bubaflub morning dukeleto
18:10 varta joined #parrot
18:14 dukeleto varta: welcome
18:14 dukeleto bubaflub: done with skool yet?
18:14 bubaflub dukeleto: not yet - almost.
18:14 * dukeleto can't keep all the GSoC student schedule in his head, yet.
18:14 bubaflub dukeleto: 2 weeks and i'll be done
18:18 tadzik I'm jealous :(
18:22 cotto bacek++ for figuring out how to unblock ops parsing
18:25 birdwindupbird left #parrot
18:29 SHODAN joined #parrot
18:32 Coke left #parrot
18:32 Coke joined #parrot
18:35 davidfetter left #parrot
18:49 particle joined #parrot
18:49 Andy joined #parrot
18:52 particle1 left #parrot
18:58 jrt4__ joined #parrot
19:04 whiteknight cotto does not blog nearly enough!
19:05 cotto whiteknight, it's to cancel you out
19:05 whiteknight I'll gladly cut back if it opens more reparrot
19:05 cotto ;)
19:05 dukeleto whiteknight: i read all your concurrency blog posts. I can haz cookie?
19:05 whiteknight dukeleto: I didn't even read them all! I have cookies, will send
19:05 dukeleto whiteknight: i agree with pretty much all of it. Let's ship it.
19:06 dukeleto whiteknight: we need to fill out the M0 spec with respect to concurrency stuff
19:06 cotto yup.  That's one of three remaining known holes.
19:06 dukeleto whiteknight: do you forsee M0 needing concurrency opcodes? What do they look like?
19:06 whiteknight okay, that's part of the reason why I wanted to put those posts out there in the first place
19:06 dukeleto whiteknight: i assume we may need a few, but don't quite know what they look like
19:07 whiteknight dukeleto: that's just the thing, I suspect 99% of the concurrency stuff I talked about can be implemented in terms of PMCs and methods
19:07 whiteknight The only opcode I really think we need is "share" to share read-only data between threads
19:08 whiteknight and really, that opcode will be mostly a convenience over PMC methods and vtables
19:10 cotto whiteknight, what do you view the mechanism for message passing looking like?
19:10 soh_cah_toa joined #parrot
19:10 dukeleto whiteknight: M0 doesn't know what a PMC is
19:10 cotto ctrl-z
19:10 whiteknight cotto: from the PIR level, I suggest a method call on the thread: thread.send_message(msg)
19:11 whiteknight dukeleto: whatever mechanism is used to instantiate "things" and do "stuff" on them is what threading requires
19:11 whiteknight dukeleto: whatever PIR methods turn into in M0 world is what we need
19:11 whiteknight I do assume objects and methods will still be possible, in some fashion
19:12 dalek nqp/ctmo: 4679b68 | jonathan++ | src/core/NQPMu.pm:
19:12 dalek nqp/ctmo: Fix a type-o. Detected by in-progress typename handling work.
19:12 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/4679b68190
19:12 dalek nqp/ctmo: 556b715 | jonathan++ | src/NQP/ (2 files):
19:12 dalek nqp/ctmo: Resolve typename at compile time.
19:12 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/556b71593b
19:12 dalek nqp/ctmo: 3564e72 | jonathan++ | src/NQP/Actions.pm:
19:12 dalek nqp/ctmo: Add parrot v-table overrides through the compile time meta-object.
19:12 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/3564e72784
19:12 dalek nqp/ctmo: f993bf4 | jonathan++ | src/ (2 files):
19:12 dalek nqp/ctmo: Attach multi signatures during normal fixup stage, not as special loadinits. Should cut startup time a little. Also resolves the multi-method regression introduced earlier in this branch.
19:12 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/f993bf499a
19:12 dukeleto whiteknight: M0 basically indexes into blobs of memory
19:12 dukeleto whiteknight: it may be that no concurrency M0 ops are needed
19:13 whiteknight dukeleto: I don't really care what the mechanism is. At some level, we have methods, right?
19:13 cotto It'll be a hard sell otherwise.
19:13 whiteknight dukeleto: As for M0 ops, I don't suspect we need anything special
19:13 dukeleto whiteknight: at the lowest level, what does message passing look like?
19:13 whiteknight We will need a wrapper API for threads (not for greenthreads), but that should be able to be called in the same way other API calls look like
19:14 whiteknight dukeleto: passing a message looks like thread.mailbox.push(share(msg))
19:14 whiteknight the thread mailbox will just be a queue like RPA
19:14 whiteknight share creates a new proxy object
19:15 whiteknight so thread.mailbox.push(new ShareProxy(msg))
19:15 whiteknight or maybe thread.mailbox.push(new ShareProxy(thread, this_thread, msg))
19:15 whiteknight but nothing special or complicated. Attribute lookups, method calls, object instantiation
19:16 cotto Does there need to be something preventing data from being shared between threads apart from convention?
19:16 cotto i.e. poking into another object's guts is possible, but is a Bad Idea apart from via message passing
19:17 dukeleto whiteknight: can't sharing just be the default? what happens if we assume everything is shared by default?
19:18 whiteknight dukeleto: depends what you mean by "sharing". Read-only sharing poses no real problems whatsoever
19:18 whiteknight read-write sharing creates the potential for data corruption, so we need to have STM and/or locks and other nonsense
19:18 dukeleto whiteknight: sure. so read-only sharing is default. So you are talking about "sharing" in the "you can write to this" sense ?
19:18 dukeleto whiteknight: ah, ok. So sharing is for read-write
19:19 whiteknight dukeleto: in my system, "sharing" means read-only proxies and using messages to perform cross-thread updates
19:19 whiteknight you can't write directly to another threads data
19:19 whiteknight you can read it, because there's no reason to restrict that
19:19 dukeleto whiteknight: and I am not sure we even need an op for "share", since it really boils down to accessing memory and looking up the metadata about if that data is writable by the current thread/task
19:19 dukeleto whiteknight: does that make sense?
19:20 whiteknight dukeleto: What the "share" opcode does in my imagination is to create a read-only proxy, and sends the proxy to the new thread in place of the original data
19:20 whiteknight the proxy allows direct reads, but uses messages to send updates
19:20 bubaflub left #parrot
19:20 whiteknight so all "share" does is create that proxy
19:20 dukeleto whiteknight: sure, but "share" can be written in M0, M0 does not need an opcode to represent it. methinks, anyway.
19:21 whiteknight right, share is a PIR-level op.
19:21 whiteknight basically, it's a combination of hll-map-lookup and new
19:21 whiteknight so nothing fancy
19:21 whiteknight at the M0 level, I think we do not need any special concurrency-related ops
19:21 dukeleto whiteknight: sweet. This is good. The spec is much closer to complete than we thought.
19:21 whiteknight that is, assuming we can call arbitrary API functions written in C
19:22 dukeleto whiteknight: M0 has FFI, so yes.
19:22 whiteknight so, we all win. I'll get the champagne
19:22 dukeleto whiteknight: awesome. I am going to get some fresh air to brood upon these matters.
19:22 whiteknight okay, please do
19:23 whiteknight I'm glad to be finally talking about concurrency in a real way
19:23 * dukeleto is excited
19:23 * dukeleto goes
19:35 mj41 joined #parrot
19:37 benabik A little late to the conversation, but if we want to do proper locking we'll need an atomic test-and-set or similar op.
19:37 cotto left #parrot
19:38 jnthn__ Wasn't there some paper that said that you can build all concurrency stuff out of atomic compare and swap?
19:38 jnthn__ er, concurrency control mechanisms, I mean. :)
19:39 ambs left #parrot
19:40 benabik jnthn__: I think so.  It's been a while since my OS classes, but IIRC you need a single check-and-alter op for something like 95% of concurrency control.  Intel went with Test-and-set, but I think test and swap is a little more versitile.
19:40 whiteknight for locking, we might want something like that yes. But then again, we only need locking if we allow cross-thread data writing
19:40 Coke left #parrot
19:42 jnthn__ whiteknight: You can build a LOAD of lock-free data structures out of CAS.
19:42 whiteknight true
19:43 * jnthn__ does those now and then
19:43 whiteknight a CAS op might be useful
19:43 whiteknight any M0 op is going to be atomic as far as we are concerned, because tasks only switch between ops, and messages are just tasks
19:44 benabik Even if PIR doesn't cross the threads, M0 might end up needing to do coordination across threads like that to support things like the mailboxes.
19:44 whiteknight mailboxes are the one issue I've been glossing over
19:44 whiteknight mailboxes need to be thread-safe
19:44 whiteknight but if we follow message passing as the one and only communication mechanism, nothing else needs it
19:45 Coke joined #parrot
19:49 bubaflub joined #parrot
19:51 mikehh left #parrot
19:54 Coke left #parrot
19:55 Coke joined #parrot
19:56 bluescreen left #parrot
19:56 bluescreen joined #parrot
19:57 benabik Probably better to have a nice CAS op for M0, even if mailboxes are the only official usage of it exposed to anyone above.
19:58 whiteknight like I said, all M0 ops will be essentially atomic, so we can have whatever we want
19:58 whiteknight CAS is as good a choice as any
19:58 ambs joined #parrot
20:05 sorear CAS2! *ducks*
20:06 Andy left #parrot
20:06 ShaneC joined #parrot
20:07 whiteknight msg plobsing if you have a spare moment, could you take a quick look at parrot-instrument src/dynpmc/instrumentruncore​.pmc:runcore_optable_fixup? I think that's the source of (some of) our problems. Commenting it out reclaims several tests
20:07 aloha OK. I'll deliver the message.
20:08 lucian whiteknight: uh, you might not need to care about the thread-safety of the mailboxes
20:08 lucian there are ready-made implementations, from signals to ampq
20:09 whiteknight that's fine too. We could easily create a PMC wrapper over an existing implementation
20:09 whiteknight I'm consciously glossing over those kinds of details
20:17 Coke left #parrot
20:17 Coke joined #parrot
20:19 autark left #parrot
20:21 autark joined #parrot
20:22 whiteknight I think I just plain don't understand how oplibs work
20:23 whiteknight clearly I don't understand it well enough to figure out why some of this crap is failing
20:23 whiteknight part of me is starting to wonder if it's worth the effort to save parrot-instrument at all. All the changes to oplibs and packfiles between then and now have it broken pretty badly
20:26 Coke left #parrot
20:26 Coke joined #parrot
20:29 plobsing joined #parrot
20:31 dodathome left #parrot
20:32 fperrad left #parrot
20:32 perlite_ joined #parrot
20:33 Coke left #parrot
20:33 Coke joined #parrot
20:36 perlite left #parrot
20:36 perlite_ is now known as perlite
20:44 dalek nqp/ctmo: eed9b67 | jonathan++ | src/stage0/ (6 files):
20:44 dalek nqp/ctmo: Update the bootstrap with the various branch changes so far.
20:44 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/eed9b67e82
20:44 dalek nqp/ctmo: c74cce8 | jonathan++ | src/ (2 files):
20:44 dalek nqp/ctmo: Refactor to generate the prefixes list during the actions stage rather than using the one built in the regex compiler. This means it can be added through the compile-time meta-objects.
20:44 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/c74cce8709
20:44 dalek nqp/ctmo: 519ef59 | jonathan++ | src/stage0/ (6 files):
20:44 dalek nqp/ctmo: Update bootstrap.
20:44 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/519ef59d4c
20:44 dalek nqp/ctmo: b6e14db | jonathan++ | src/PAST/Compiler-Regex.pir:
20:44 dalek nqp/ctmo: Remove now-unused prefix routine code-gen from the regex compiler.
20:44 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/b6e14db3ef
20:45 Coke left #parrot
20:45 Coke joined #parrot
20:51 lucian_ joined #parrot
20:54 lucian left #parrot
20:55 dukeleto ~~
20:57 Coke left #parrot
20:57 Coke joined #parrot
20:58 dalek nqp/ctmo: 811d9a5 | jonathan++ | src/NQP/ (2 files):
20:58 dalek nqp/ctmo: Eliminate a mention of $*PACKAGE-SETUP, which it's now time to start finally killing.
20:58 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/811d9a5f48
21:11 SHODAN left #parrot
21:17 cotto joined #parrot
21:18 ambs left #parrot
21:18 dalek nqp/ctmo: 1a16b84 | jonathan++ | src/ (2 files):
21:18 dalek nqp/ctmo: Stub in initial bits towards role building refactor, which removes another usage of $*PACKAGE-SETUP. Finishing that is main task left in this branch.
21:19 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/1a16b84a94
21:19 dalek nqp/ctmo: f30806d | jonathan++ | src/ (2 files):
21:19 dalek nqp/ctmo: Switch .^compose to compile time meta-object. Darn...breaks multi-methods. :/
21:19 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/f30806d975
21:19 dalek nqp/ctmo: 707bae5 | jonathan++ | src/NQP/ (2 files):
21:19 dalek nqp/ctmo: Remove last remaining usages of $*PACKAGE-SETUP.
21:19 dalek nqp/ctmo: review: https://github.com/perl6/nqp/commit/707bae553a
21:46 cotto left #parrot
21:56 mj41 left #parrot
22:46 mtk left #parrot
22:53 plobsing_ joined #parrot
22:53 mtk joined #parrot
22:57 plobsing left #parrot
23:11 davidfetter joined #parrot
23:17 soh_cah_toa hey guys, i'm having some serious trouble trying to install winxed. anyone wanna try and take a look at this?
23:17 nopaste "soh_cah_toa" at 192.168.1.3 pasted "Problems With Winxed Installation" (40 lines) at http://nopaste.snit.ch/43085
23:21 plobsing_ looks like something is trying to allocate a silly amount of memory
23:22 plobsing_ 92M is a rather large allocation
23:22 soh_cah_toa yeah, but i haven't a clue what or why
23:23 plobsing_ do you have gdb on hand?
23:23 soh_cah_toa of course
23:25 soh_cah_toa why, stacktrace maybe?
23:25 plobsing_ that's the first place to start
23:26 plobsing_ break on panic_failed_allocation
23:31 soh_cah_toa should i do 'gdb parrot winxedrun.pbc --stage=1 -c -o winxedst2.pir winxedst1.winxed'? b/c when i do, gdb complains that winxedrun.pbc is an unrecognized file format
23:31 benabik I think it's gdb --args parrot ...
23:32 sorear plobsing_: 92MB is not a silly allocation if it comes from compact_pool
23:32 soh_cah_toa i just loaded it w/ 'file' after already in gdb
23:33 soh_cah_toa actually that worked
23:33 soh_cah_toa i spoke too soon
23:33 soh_cah_toa anyway, i can't 'break panic_failed_allocation' b/c it says its undefined
23:39 plobsing_ you'll need to run it once so gdb loads the shared lib where the function resides
23:40 soh_cah_toa yup, there we go
23:40 soh_cah_toa alright, i'm at panic_failed_allocation
23:41 plobsing_ bt will give you a backtrace
23:43 nopaste "soh_cah_toa" at 192.168.1.3 pasted "Backtrace at panic_failed_allocation()" (65 lines) at http://nopaste.snit.ch/43086
23:44 plobsing_ sorear: looks like you called it
23:44 plobsing_ sorear: how much memory do you have on that system?
23:45 plobsing_ er soh_cah_toa: ^^^^
23:45 soh_cah_toa it's a vm. i gave it 1024 megs
23:45 plobsing_ ulimit?
23:45 lucian joined #parrot
23:45 soh_cah_toa unlimited
23:46 mikehh joined #parrot
23:47 plobsing_ what does the memory usage climb to?
23:48 soh_cah_toa how do i get that?
23:49 lucian_ left #parrot
23:51 plobsing_ when you are at the breakpoint in gdb, run 'ps aux' in another terminal.
23:52 plobsing_ %MEM, VSZ, and RSS are all somewhat meaningful
23:52 soh_cah_toa alright, h/o
23:55 soh_cah_toa %MEM: 63.7 VSZ: 1034084 RSS: 653348
23:58 * soh_cah_toa will be right back

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

Parrot | source cross referenced