Camelia, the Perl 6 bug

IRC log for #parrot, 2011-02-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:01 whiteknight maybe also an assembler
00:01 whiteknight we need a low-level language that compiles directly to pbc
00:01 whiteknight if that's winxed, we can use that
00:01 NotFound_b whiteknight: I think that will be good to have one bytecode generating backend... if all tools use it.
00:01 cotto_work what pasm thought it was
00:02 whiteknight right, minus the shittiness of PASM and PIR
00:02 whiteknight If NQP compiles right down to PBC, that's fine. If Winxed, we can use that
00:02 whiteknight if something else, let's start designing it
00:02 NotFound_b cotto_work: pasm isn't enough. If you generate PASM you must update to generator to any change in calling conventions, for example.
00:02 chromatic Which NQP?
00:03 bacek_at_work whiteknight, it's called POST
00:03 whiteknight right, but Winxed can't really use POST (yet)
00:03 whiteknight maybe stage-1 Winxed can
00:03 NotFound_b whiteknight: maybe, but there isn't any proof of that yet.
00:03 whiteknight right
00:03 cotto_work NotFound_b: I'm not suggesting we use PASM, but that we're implementing what PASM was intended to be.
00:04 whiteknight chromatic: any NQP
00:04 chromatic If we're forking an NQP to live in the Parrot repo, we should change its name.
00:04 whiteknight chromatic: if we merge many features from new NQP down into Parrot core, the interoperability layer between NQP and Parrot will be much thinner than on other languages
00:04 whiteknight er, other VMs
00:05 whiteknight What I don't like about NQP is the pervasive use of lexical variables and the requisite bookkeeping for them
00:05 whiteknight I would prefer a Parrot system language not do anything like that unless asked
00:05 chromatic I hope the interop layer will be thinner, but in the absence of evidence....
00:05 Tene whiteknight: you'd prefer a parrot system langauge to not have lexical variables? o.O
00:06 whiteknight Tene: can have lexicals, but not insert them everywhere. NQP pays a performance penalty for using .lex and friends when not needed
00:06 whiteknight PIR has lexicals, but you have to use them explicitly
00:07 bacek_at_work whiteknight, it's all about optimizations (of generated code)
00:07 cotto_work whiteknight: is your problem with lexicals themselves or with the performance and code bloat penalties?
00:08 bacek_at_work And it was one of my reasons to push tree-optimization forward.
00:08 whiteknight cotto_work: the code bloat penalties. not the feature itself. Parrot's lowest-level system language shouldn't have magic
00:08 bacek_at_work because most of this bloat can be optimized-out
00:09 whiteknight I would rather not generate it in the first place, but that's sort of a moot point
00:10 chromatic What's your thinking here, cotto_work?
00:11 cotto_work chromatic: which point?  lexicals?
00:11 chromatic PCT
00:12 cotto_work I need to think about it before I can give a good answer.
00:14 plobsing joined #parrot
00:18 kid51 joined #parrot
00:22 whiteknight blarg. so much to think about
00:22 bacek_at_work yes.
00:22 cotto_work indeed
00:23 bacek_at_work M0, M1, MOP, GC
00:23 bacek_at_work it's what must be in core.
00:23 cotto_work what lives where, who cares, who needs to, who's responsible
00:23 bacek_at_work "some tool to generate M1" - should be in core.
00:24 bacek_at_work "some tool to generate input for previous one" - very-very questionable.
00:24 bacek_at_work "Bundling all required tools to develop with parrot" - definitely yes.
00:24 bacek_at_work Look from "end user" point of view.
00:24 cotto_work I guess PCT depends on whether we feel like we can define and stick with a stable interface between layers.
00:25 bacek_at_work Who cares who developed PCT?
00:25 chromatic The people who have to support it.
00:25 bacek_at_work If after downloading tarball I (as HLL dev) will have all tools to develop my HLL
00:26 bacek_at_work chromatic, I implemented support for :multi and vtable in nqp-rx.
00:26 NotFound_b "some tool to generate M1" -> A M1 assembler?
00:26 bacek_at_work I developed nqp-setting (mostly)
00:26 bacek_at_work I don't see any problems with supporting PCT/nqp/whatever as parrot developer.
00:27 bacek_at_work NotFound_b, no. "M1 assembler" is  "some tool to generate input for previous one"
00:27 chromatic I think you might have had more trouble supporting :multi and :vtable on JVM, CLR, Lua, GHC, v8, etc.
00:29 whiteknight right, that's the problem. New NQP isn't Parrot-only. Those kinds of things are going to be extensions at least
00:29 whiteknight or alternate grammars, which is fun to think about, but ultimately not great for us
00:30 Kapace joined #parrot
00:30 bacek_at_work chromatic, I'm not going to.
00:30 chromatic I have a problem with that.
00:31 bacek_at_work Sigh...
00:31 bacek_at_work what is the problem?
00:32 bacek_at_work It's up for "nqp-to-vm-compatibility-layer".
00:32 bacek_at_work For parrot this layer will be thin (at least for :multi and :vtable)
00:32 bacek_at_work For JVM/CLR - I don't care at all.
00:32 chromatic All of a sudden, adding new features to new NQP to run better on Parrot means you have to consider how to add those features to other VMs which aren't Parrot.
00:32 bacek_at_work No
00:32 bacek_at_work Not at all.
00:34 chromatic If I were a maintainer of this new NQP and I cared about multiple backends, I'd reject patches which didn't.
00:34 cotto_work I'm seeing two classes of features; ones which are supported across all backends and ones which are VM-specific.
00:35 Tene It's a shame we can't ask the actual maintainer of this new NQP to see how he feels about that.
00:35 bacek_at_work chromatic, http://irclog.perlgeek.de/p​arrot/2011-01-31#i_3239879
00:35 Tene 16:22 <@Tene> If support for other backends interfered with good support with Parrot, would that be considered a failure of NQP's design, or at least not meeting NQP's goals?
00:35 Tene 16:23 <@pmichaud> not meeting nqp's goals, definitely.
00:35 bacek_at_work chromatic, pmichaud said totally opposite.
00:36 bacek_at_work http://irclog.perlgeek.de/p​arrot/2011-01-31#i_3239896
00:36 chromatic I'm sure pmichaud doesn't want to sprinkle Parrot-specific code throughout Rakudo.
00:36 NotFound_b Currenty, there is some way of generating POST that can use all parrot features other than creating a lot of pir nodes? If not, targeting POST instead of PIR is just complicating things.
00:36 bacek_at_work "switching grammar ... with the VM specific features"
00:36 bacek_at_work chromatic, who is talking about rakudo?
00:37 chromatic Presumably, the people maintaining the new NQP want to use it to produce Rakudo.
00:37 bacek_at_work afk # meeting
00:38 pmichaud I wouldn't expect to have to support :multi and :vtable on JVM, CLR, etc.  I've already said as much.
00:38 cotto_work I see the VM-specific features being intended only for use on those VMs.  There's no reason the other backends need to know or care.
00:38 pmichaud Those would be available behind a "use Parrot;" pragma or the like.
00:39 pmichaud Just because something is available on one VM doesn't mean they have to be available on all.
00:39 chromatic But they won't get used in languages intended to be portable.
00:39 pmichaud for someone who is developing Parrot tools, that's presumably not an issue.
00:39 cotto_work chromatic: exactly
00:39 pmichaud And they will get used in languages intended to be portable, including Rakudo.  In that case they also have to be "unlocked" by a suitable Perl 6 pragma.
00:40 pmichaud Perl 6 absolutely wants to be able to expose low-level parts of the underlying environment as well.  NQP and Rakudo have to be able to support that.
00:40 kid51 pmichaud:  Hope to get back to you later this evening re roadmaps.
00:41 kid51 In the meantime ...
00:41 pmichaud it's not about making some watered-down language that runs exactly the same everywhere.
00:41 Tene 16:20 <@Tene> pmichaud: is it currently a goal of yours that nqp will be able to provide Parrot with what it needs, be able to expose parrot-specific features well, etc?
00:41 kid51 is now known as kid51_at_dinner
00:41 Tene 16:20 <@pmichaud> I know that Rakudo will.
00:41 Tene You already said as much, more than once.
00:41 pmichaud yes, thanks for noticing.
00:41 Tene erm, I missed a line.
00:41 pmichaud (and for saving me the trouble of pasting what I already wrote :)
00:42 chromatic To use continuations in Rakudo with new NQP then you have the equivalent of an #ifdef for each different platform semantic?
00:43 cotto_work Given that that's the intent, it seems to make sense for the platform-agnostic part of PCT to live as part of nqp and be bundled with Parrot and for Parrot to include its own extensions in parrot.git or a parrot-owned submodule.
00:45 chromatic In other words, the new NQP exposes as much of Parrot semantics as possible directly when running on Parrot and emulates Parrot semantics when running on other backends?
00:45 pmichaud if an application needs those Parrot semantics, then yes.
00:46 pmichaud even in the current world view, I would expect that things like pir:: and Q:PIR in Rakudo would need to be exposed by a "use Parrot;", that would need emulation if a Perl 6 program expects to run on a backend other than Parrot.
00:46 pmichaud We just haven't implemented the "use Parrot;" requirement yet.
00:47 cotto_work I'd expect "use Parrot;" to fail on a backend that didn't support it.
00:47 chromatic Wow.
00:48 NotFound_b Thing like that are expected to be working when not using imcc?
00:48 pmichaud well, I really hope Q:PIR goes away entirely.
00:48 Tene chromatic: "to use continuatiosn" -- were you asking about "Using a continuation from Perl 6 as a user" or "Implementing continuation support in Rakudo's source"?
00:48 pmichaud That was definitely a stop-gap measure.  The pir:: functional interface is far easier to implement.
00:48 chromatic The latter, Tene.
00:48 pmichaud s/implement/emulate/
00:49 pmichaud and it doesn't have to be pir:: -- it can just as easily be parrotop:: or some other more suitable name that exposes parrot opcode semantics
00:49 Tene chromatic: In that case, explain "Wow"?
00:50 chromatic "Wow, porting Parrot to other VMs is a lot of work."
00:50 pmichaud I don't expect it to be common.  I just expect it to be possible.
00:50 pmichaud It's like having libraries that give access to Windows-specific or Linux-specific features.
00:50 cotto_work pmichaud: exactly
00:51 Tene chromatic: It's never been the intent that every possible NQP program can run equivalently on every possible VM.  That's part of the objection to "platform agnostic" that was discussed earlier.
00:51 pmichaud nor is it the intent for every Perl 6 program to run equivalently on every possible VM, I don't think.
00:52 pmichaud that's where individual implementations have some room outside of the Perl 6 spec, I think.
00:53 * cotto_work decommutes
00:54 chromatic I hope it works out.
00:56 pmichaud "perl 6 is created by *terrifyingly* hopeless dreamers who /are going to succeed/"  -- sorear++ on #perl6   :-)
00:56 * PerlJam wonders what that means wrt chromatic's position on this subject
00:56 chromatic I'm not implementing it, so I decline to give any other opinion on the subject.
00:57 PerlJam fair enough
01:03 pmichaud kid51_at_dinner: no rush on any responses on the roadmaps, at least not from my perspective.  But any comments you have are definitely welcome :)
01:04 Tene Ahh, I missed this:
01:05 Tene "<chromatic> ... and emulates PArrot semantics when running on other backends?" -- "<@pmichaud> if an application needs those Parrot semantics, then yes."
01:07 pmichaud I should have qualified that to "Parrot-specific" semantics, I guess.  NQP of course has semantics that it seeks to provide regardless of VM backend (and regardless of whether each VM supports them natively or not).
01:08 pmichaud Regex and grammar support being an obvious example.
01:08 Tene That makes a lot more sense, yes.
01:08 sorear bacek_at_work: To what extent do you want all HLLs to generate POST?
01:08 Tene I would be very surprised if "use Parrot;" did anything but fail on other VMs.
01:08 pmichaud I suspect that if a VM doesn't have certain Parrot-specific semantics that's because it's not seen as being particularly important to its customer base.
01:09 pmichaud and I suspect that most portable HLLs are in the business of exposing every platform-specific capability across all of their platforms either.
01:09 pmichaud (except through libraries or well-defined compatibility APIs)
01:10 pmichaud s/are/aren't/
01:11 chromatic Yes, but you're talking about fundamental Perl 6 language features such as method dispatch, gradual typing, laziness, operator composition, context, variadic return, named parameters, multiple dispatch, junctions, coroutines, grammars, lexical variables, temporary variables, closures, higher-order functions, first-class primitives as objects, open classes, namespaces, and autopromotion.
01:12 dalek winxed: r764 | NotFound++ | trunk/winxedst1.winxed:
01:12 dalek winxed: replace some usages of Emiter say with emitbinop
01:12 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=764
01:14 pmichaud I am?
01:14 chromatic Aren't you, if you want to use them from NQP in Rakudo?
01:14 pmichaud junctions won't be in NQP
01:14 pmichaud that's already pretty much a Rakudo-specific implementation
01:15 pmichaud many of those features are already handled by virtue of 6model
01:16 pmichaud many of them (e.g., laziness) aren't particularly supported well by Parrot or nqp-rx as it is now, so I don't see that as an obvious point.  I'm not expecting laziness to suddenly appear in NQP.
01:16 PerlJam pmichaud: you must be reading my mind as I was just about to ask about that one.
01:16 pmichaud I expect to be able to use NQP to implement them, but I don't expect NQP to natively provide them.
01:16 chromatic It was one of my goals.
01:17 pmichaud if Parrot offers laziness, then we'll undoubtedly find ways to optimize Rakudo to use them when they're present.
01:17 pmichaud but that doesn't mean we expect to require it of every backend.
01:19 pmichaud I might be overstating this, but I think that for the majority of items in that list they've been implemented in Rakudo by working around core Parrot, not as a result of it.  (Modulo PGE and PCT being considered part of "core Parrot".)
01:20 pmichaud coroutines would be a notable exception in that list -- clearly Parrot has helped us a lot there for handling given/when
01:20 pmichaud sorry, gather/take
01:20 chromatic Hypothetically speaking, if Parrot included new NQP in a tarball as the One Good Default Option for building languages with PCT, we would tell users "To use Parrot specific features, use 'use parrot' in the appropriate scope"?
01:21 pmichaud I think so, yes.
01:22 pmichaud or, it could be enabled by default, but if you expect to your language to run on another backend, you want to avoid those features or make sure that the parrot features are emulated for that other backend somewhere.
01:22 pmichaud that's clearly a language designer choice
01:26 cosimo left #parrot
01:26 chromatic I see.
01:27 kid51_at_dinner left #parrot
01:28 pmichaud afk, dinner
01:29 NotFound_b left #parrot
01:51 cotto ~~
01:54 atrodo I wish $dayjob wasn't so demanding today, looks like a lot of good chatting happened
01:55 plobsing yes, seems we had an exciting day
01:57 Kristaba left #parrot
02:00 cotto good concusions too
02:00 cotto conclusions
02:01 cotto I think we agree to agree, for the most part
02:01 chromatic How so?
02:03 plobsing I agree with the conclusions. What are they?
02:04 cotto i need to reread, but it seems like  what pmichaud wants to do with nqp will let us have a good implementation of nqp on parrot  that lets us use our low level stuff
02:04 cotto working out, so sorry for typos or disjointedness
02:06 cotto typing on an exercise bike does not seem to be my laptop's intended use case
02:08 chromatic Any thoughts on bundling versus forking NQP or creating something new?
02:09 cotto i'd really rather not fork just because of duplicated effort.  i see us bundling the platform-specific nqp and including/maintaining a parrot-specific layer
02:10 chromatic Okay.
02:10 cotto (the "use Parrot;" pieces, not the layer that's at the same level as the3 cli code
02:10 cotto how does that sound to you?
02:11 cotto if we can assume a stable or at least reasonable interface for building the vm-specific bits, I think it'll be workable
02:16 whiteknight left #parrot
02:30 bubaflub joined #parrot
02:30 bubaflub left #parrot
02:43 bluescreen left #parrot
03:57 pmichaud does anyone know how I can get my new journal added to Planet Parrot?  http://pmthium.com/category/parrot/
04:03 sorear pmichaud: there's a contact link
04:03 sorear it points at "webmaster at perl.org"
04:24 bacek_at_work pmichaud, (side question) can I have $/ in nqp(-rx)?
04:25 pmichaud bacek_at_work: what for?
04:25 pmichaud bacek_at_work: you mean as an automatically declared lexical?
04:25 bacek_at_work pmichaud, for ~~
04:25 pmichaud setting of $/  isn't really part of ~~
04:25 pmichaud it's a part of the .match method, or something like that.  We haven't even nailed it down precisely in Rakudo or Perl 6 yet.
04:26 bacek_at_work oh.
04:26 bacek_at_work aloha, S05?
04:26 aloha bacek_at_work: No clue. Sorry.
04:26 bacek_at_work stupid girl
04:26 pmichaud but you can do:    my $/ := 'something' ~~ /pattern/;   and you get much the same effect.
04:26 bacek_at_work pmichaud, I did it in YAML::Tiny
04:27 bacek_at_work https://github.com/parrot/yaml-tiny/blob/4d712bc9​4ba155f69e71f9f48f9eba2ea5d529bc/lib/YAML/Tiny.pm
04:27 pmichaud I don't see a $/ in YAML::Tiny
04:28 bacek_at_work it's called $m
04:28 bacek_at_work line 240 for example
04:28 pmichaud oh yes, that works too.
04:28 bacek_at_work aloha, S05 is http://perlcabal.org/syn/S05.html
04:28 aloha bacek_at_work: Okay.
04:28 pmichaud anyway, it's perfectly legal to declare $/ as a lexical and then use it.
04:28 bacek_at_work pmichaud, but I would like to see less noise :)
04:28 pmichaud I'm not quite ready to make it "automatic" in nqp yet.... even $_ isn't automatic except in for loops.
04:29 bacek_at_work ah. ok.
04:29 pmichaud and I'd really like to see the Perl 6 spec solidify on it first :)
04:29 bacek_at_work The underlying match object is now available via the $/ variable, which is implicitly lexically scoped. All user access to the most recent match is through this variable, even when it doesn't look like it. The individual capture variables (such as $0, $1, etc.) are just elements of $/.
04:30 bacek_at_work What's wrong with it???
04:31 pmichaud we don't yet know how .match gets access to $/ to set it
04:31 pmichaud more to the point, if I have something like
04:32 pmichaud $x.subst( /(pattern)/, { $0 - 1 } )
04:32 pmichaud the $0 (which is really $/[0])  has to refer to the $/ inside of the subst, and not the $/ that is lexically part of the closure or its outer scope.
04:32 pmichaud so $/ isn't purely a lexical -- it sometimes acts more like a dynamic variable
04:48 adu joined #parrot
04:48 adu hi
04:54 dukeleto adu: hola
04:54 adu how goes?
04:55 dukeleto adu: pretty well. welcome to #parrot
04:55 adu thanks :)
04:55 dukeleto adu: what brings you around these parts?
04:56 adu well, I remember profiling for memory leaks about a year ago (for parrot), and haven't dropped by recently, so I thought I should
04:58 freeksh0w86 joined #parrot
04:58 dukeleto adu: welcome back
04:58 dukeleto adu: what do you use to profile?
04:58 dukeleto adu: perhaps you can try it on 3.0, our latest stable release
04:58 adu "leaks" (macosx)
04:59 dukeleto adu: we would love some stats such as "max ram usage during compile/test suite", can you track stuff like that easily?
04:59 adu hm, probably
05:00 adu mac has this thing called "verbose malloc"
05:00 dukeleto adu: well, memory leak info would be fantastic
05:01 adu well, I'm also writing a parser for Go
05:01 adu and wondering what to do with it once the parser is done
05:04 adu I have this vision in my head of an editor written in Go with modules written in everything imaginable, compiled to PBC, or perhaps even communicating over CGI or something, but all usable from any language
05:04 adu bah, humbug, I'm just a dreamer
05:04 adu ignore me
05:06 adu such a system would have massive documentation requirements, pulling docstrings from python/perldoc, the inconsistencies might be too much
05:10 adu I think parrot is on the right track
05:18 adu dukeleto: are you into webapps?
05:18 sorear adu: have you looked at Fly?
05:19 adu what's fly?
05:22 adu are you talking about http://www.criticalsecurity.net/inde​x.php/topic/29757-fly/page__st__200
05:23 adu can you give me a URL?
05:29 dukeleto adu: i am very familiar with them, yes
05:29 dukeleto adu: Go on Parrot sounds fun, no one has tried that, as far as I know
05:30 adu well, Go already requires some extra runtime, so it makes sense to use an existing runtime
05:31 adu for example, type-switch
05:32 sorear Fly was "how Parrot goes"
05:32 sorear but I can't find a link
05:32 sorear googling for parrot go fly isn't exactly helping
05:32 sorear and it's not on the tracwiki Languages page
05:33 adu ah, you mean async calls?
05:34 sorear no
05:34 adu what do you mean?
05:34 sorear "Fly" was the name of the Go on Parrot implementation
05:37 diakopter joined #parrot
05:38 adu i found this: https://groups.google.com/group/golang-nu​ts/browse_thread/thread/f0e3e5b255d07c98
05:38 diakopter as in, "parrot go fly"
05:40 diakopter sorear: do you have an URL for "Fly"?
05:40 diakopter oh
05:40 adu diakopter: apparently not
05:40 diakopter nm I see in the log you didn't find it
05:41 cotto seen jvd
05:41 aloha Sorry, I haven't seen jvd.
05:41 diakopter http://irclog.perlgeek.de/parr​otsketch/2010-05-18#i_2343784
05:41 diakopter Fly reference ^^
05:42 allison left #parrot
05:43 cotto does anyone care to clean up http://trac.parrot.org/parro​t/wiki/MakeEveryPMCAnObject ?
05:44 adu i need to find this tcurtis guy
05:45 * cotto figures he should probably do his own job
05:48 adu anyways, if someone is reading this conversation a year from now, I should probably post a link to my implementation
05:48 adu http://hackage.haskell.org/package/language-go
05:51 adu but I'm pretty sure I'm not going to call the compiler Fly, probably "dsgo"
05:56 rurban_ joined #parrot
05:56 dukeleto adu: tcurtis was a gsoc student, who wrote the tree-optimization library, but seems to be busy with school these days
06:00 rurban left #parrot
06:00 rurban_ is now known as rurban
06:00 adu hopefully well cross paths someday
06:06 particle1 joined #parrot
06:09 particle left #parrot
06:09 chromatic left #parrot
06:29 dalek tracwiki: v5 | cotto++ | MakeEveryPMCAnObject
06:29 dalek tracwiki: most of these changes are rejected, but primarly because they'll be accomplished through M0 and 6model, not because they're bad ideas
06:29 dalek tracwiki: http://trac.parrot.org/parrot/wiki/MakeEv​eryPMCAnObject?version=5&amp;action=diff
06:34 dalek TT #1020 closed by cotto++: subclassing pmc from pir + lot more
06:34 dalek TT #1020: http://trac.parrot.org/parrot/ticket/1020
06:38 sorear diakopter: what brings you here.
06:50 mtk left #parrot
06:55 diakopter sorear: :P
06:55 diakopter left #parrot
06:55 mtk joined #parrot
07:08 theory left #parrot
07:25 fperrad joined #parrot
08:10 allison joined #parrot
08:52 contingencyplan left #parrot
08:55 hudnix left #parrot
09:41 adu left #parrot
10:07 kid51 joined #parrot
10:31 dalek parrot/generational_gc: 7cb3dca | bacek++ | include/parrot/pobj.h:
10:31 dalek parrot/generational_gc: Remove unused PObj_aligned_FLAG
10:31 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/7cb3dca60d
10:31 dalek parrot/generational_gc: 49afb77 | bacek++ | src/gc/gc_gms.c:
10:31 dalek parrot/generational_gc: Remove old idea about implementation of GenGC. Create stub for new one.
10:31 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/49afb77a96
11:00 dalek parrot/generational_gc: 31347e6 | bacek++ | src/gc/gc_gms.c:
11:00 dalek parrot/generational_gc: Flash out new (fsvo) Generational GC algorithm without magic.
11:00 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/31347e6389
11:01 bacek msg whiteknight Here we go! https://github.com/parrot/parrot/commit/31347e6389
11:01 aloha OK. I'll deliver the message.
11:58 dalek parrot/generational_gc: e85bb43 | bacek++ | src/gc/gc_gms.c:
11:58 dalek parrot/generational_gc: Remove usage of GC_gen_2 flag.
11:58 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/e85bb43d92
11:58 dalek parrot/generational_gc: 3ce2d8a | bacek++ | include/parrot/pobj.h:
11:58 dalek parrot/generational_gc: Add GC_on_dirty_list flag.
11:58 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/3ce2d8a9d1
11:58 dalek parrot/generational_gc: 18f0362 | bacek++ | include/parrot/pobj.h:
11:58 dalek parrot/generational_gc: Remove unused GC_ref_* flags.
11:58 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/18f0362f3e
12:16 Coke msg pmichaud I can add your blog to parrot, but I need an RSS url that manages the category - http://pmthium.com/category/parrot/ is HTML.
12:16 aloha OK. I'll deliver the message.
12:31 dalek parrot/generational_gc: c1ea3e4 | bacek++ | src/gc/gc_gms.c:
12:31 dalek parrot/generational_gc: "The earth shall rise on new foundations" commit. Break GMS totally
12:31 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/c1ea3e453c
12:32 bacek Coke, http://pmthium.com/category/parrot/feed/
12:40 Coke bacek: IME, that will have everything, but OK, I'll try it. ;)
12:41 bacek Coke, no, this is for "parrot" only.
12:41 bacek I checked it :)
12:43 Coke there's only one entry on his blog. hard to tell going forward. but done.
12:44 Coke msg pmichaud never mind, bacek got the URL - added.
12:44 aloha OK. I'll deliver the message.
12:57 kid51 left #parrot
13:28 wknight-phone joined #parrot
13:36 wknight-phone left #parrot
13:36 dalek parrot/generational_gc: 1731594 | bacek++ | src/gc/gc_gms.c:
13:36 dalek parrot/generational_gc: Unbreak GMS little bit: cleanup declarations, replace Linked_List with
13:36 dalek parrot/generational_gc: Pointer_Array, etc.
13:36 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/1731594eb6
13:36 dalek parrot/generational_gc: 412be2f | bacek++ | src/gc/gc_gms.c:
13:36 dalek parrot/generational_gc: Fix pmc alloc/free.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/412be2fb81
13:37 dalek parrot/generational_gc: 592f07d | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Fix STRING alloc/free.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/592f07de7d
13:37 dalek parrot/generational_gc: e296fc9 | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Remove unused helper. We'll use Pointer_Array macro instead.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/e296fc9811
13:37 dalek parrot/generational_gc: 2946e7d | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Remove unused helper for sweeping pools.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/2946e7d8b9
13:37 dalek parrot/generational_gc: e01ac98 | bacek++ | src/gc/gc_ (2 files):
13:37 dalek parrot/generational_gc: Change mark_pobj_header to mark_str_header to keep in line with Modern Parrot.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/e01ac98f8f
13:37 dalek parrot/generational_gc: 9abb367 | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Factor out unseal_object helper.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/9abb367f37
13:37 dalek parrot/generational_gc: 6214375 | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Fix is_ptr_owned
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/6214375921
13:37 dalek parrot/generational_gc: edb47fb | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Rewrite write_barrier according to new design.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/edb47fb1c7
13:37 dalek parrot/generational_gc: 81be312 | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Remove pobj2gen and gen2flags functions. They are not used anymore.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/81be312a4e
13:37 dalek parrot/generational_gc: a110762 | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Comment out (temporary) statistic calculation functions.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a110762658
13:37 dalek parrot/generational_gc: 13aa2d5 | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Comment out validation functions. We will need new versions anyway, but keep
13:37 dalek parrot/generational_gc: it for reference purpose.
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/13aa2d5f34
13:37 dalek parrot/generational_gc: 5888e37 | bacek++ | src/gc/gc_gms.c:
13:37 dalek parrot/generational_gc: Fix copy-paste error in is_string_ptr
13:37 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/5888e37da8
13:41 hudnix joined #parrot
13:47 dalek parrot/generational_gc: ab43498 | bacek++ | src/gc/gc_gms.c:
13:47 dalek parrot/generational_gc: Limit number of collected generations. We have only MAX_COLLECTIONS of them.
13:47 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/ab4349836c
13:47 dalek parrot/generational_gc: 71d28f1 | bacek++ | src/gc/gc_gms.c:
13:47 dalek parrot/generational_gc: Rename MAX_COLLECTIONS to MAX_GENERATIONS to reflect reality.
13:47 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/71d28f1686
13:55 rurban_ joined #parrot
14:00 rurban left #parrot
14:00 rurban_ is now known as rurban
14:02 whiteknight joined #parrot
14:02 fperrad left #parrot
14:06 adu joined #parrot
14:06 whiteknight good morning, #parrot
14:07 whiteknight msg bacek thanks for the link. I read that algorithm this morning. I'll take some time to study it
14:07 aloha OK. I'll deliver the message.
14:07 bacek whiteknight, it's mostly done :)
14:07 dalek parrot/generational_gc: 148c96b | bacek++ | src/gc/gc_gms.c:
14:07 dalek parrot/generational_gc: Implement cleanup_dirty_list
14:07 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/148c96be62
14:07 dalek parrot/generational_gc: 04351d3 | bacek++ | src/gc/gc_gms.c:
14:07 whiteknight the new algorithm?
14:07 dalek parrot/generational_gc: Replace asserts with ifs in write_barrier. We trigger them unconditionally in
14:07 dalek parrot/generational_gc: generated code.
14:07 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/04351d34bd
14:07 dalek parrot/generational_gc: 7f9ec09 | bacek++ | src/gc/gc_gms.c:
14:07 dalek parrot/generational_gc: Implement first cut of sweep_pools
14:07 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/7f9ec092ac
14:11 whiteknight bacek: Do we need to insert write barriers for this system?
14:11 whiteknight because that's going to take a long time to do. We need to check every file
14:11 bacek whiteknight, yes, we do
14:11 bacek whiteknight, it's done already
14:12 whiteknight in the branch?
14:12 bacek yes
14:12 whiteknight ok
14:12 bacek and we don't have to "check every single file"
14:12 bacek just few of them
14:12 whiteknight how is it implemented, vtables?
14:12 bacek yes
14:12 whiteknight okay
14:12 plobsing left #parrot
14:15 dalek parrot/generational_gc: 292bb8e | bacek++ | / (3 files):
14:15 dalek parrot/generational_gc: Add .count to Pointer_Array in debug mode
14:15 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/292bb8e926
14:15 dalek parrot/generational_gc: 25857f3 | bacek++ | src/gc/gc_gms.c:
14:15 dalek parrot/generational_gc: Enable more stats
14:15 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/25857f3239
14:15 dalek parrot/generational_gc: 1b24ec7 | bacek++ | src/gc/gc_gms.c:
14:16 dalek parrot/generational_gc: Erm. Remove object from original list before promoting into new one.
14:16 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/1b24ec7cf2
14:31 hudnix left #parrot
14:32 bluescreen joined #parrot
14:36 hudnix joined #parrot
14:36 whiteknight bacek++
14:36 whiteknight you're doing great work on this
14:38 plobsing joined #parrot
14:41 adu left #parrot
14:50 Coke he's certainly doing a lot of work on this. ;)
15:05 fperrad joined #parrot
15:07 PerlJam left #parrot
15:07 PerlJam joined #parrot
15:11 dalek winxed: r765 | NotFound++ | trunk/winxedst1.winxed:
15:11 dalek winxed: fix and rearrange allocation of temporary registers in stage 1
15:11 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=765
15:12 Andy left #parrot
15:16 bluescreen left #parrot
15:24 vmspb joined #parrot
15:24 bluescreen joined #parrot
15:26 plobsing left #parrot
15:38 plobsing joined #parrot
15:42 dalek parrot/generational_gc: ea67f36 | bacek++ | src/gc/gc_gms.c:
15:42 dalek parrot/generational_gc: Revert "Remove pobj2gen and gen2flags functions. They are not used anymore."
15:42 dalek parrot/generational_gc:
15:42 dalek parrot/generational_gc: This reverts commit 81be312a4eebfe4ef8eff80473aeed99b0a2ad56.
15:42 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/ea67f36f89
15:42 dalek parrot/generational_gc: 2790788 | bacek++ | src/gc/gc_gms.c:
15:42 dalek parrot/generational_gc: Move objects from work_list back to generation's list.
15:42 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/279078835c
15:42 dalek parrot/generational_gc: f951c0c | bacek++ | src/gc/gc_gms.c:
15:42 dalek parrot/generational_gc: pobj2gen
15:42 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/f951c0cce9
15:42 dalek parrot/generational_gc: f26c475 | bacek++ | src/gc/gc_gms.c:
15:42 dalek parrot/generational_gc: Seal moved objects and update generation number.
15:42 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/f26c4756ec
15:42 dalek parrot/generational_gc: 94fa70a | bacek++ | src/gc/gc_gms.c:
15:42 dalek parrot/generational_gc: Fix off-by-one error in sweep_pools.
15:42 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/94fa70a38b
15:42 dalek parrot/generational_gc: 286c19f | bacek++ | src/gc/gc_gms.c:
15:42 dalek parrot/generational_gc: Fix bug when I try to move object to dirty_list in second time.
15:42 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/286c19fa54
15:42 dalek parrot/generational_gc: a05b385 | bacek++ | src/gc/gc_gms.c:
15:42 dalek parrot/generational_gc: Add more stats and fix small bugs in asserts.
15:42 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/a05b38570e
15:42 dalek parrot/generational_gc: 594d503 | bacek++ | src/gc/gc_gms.c:
15:42 dalek parrot/generational_gc: Properly remove items from Pointer_Array
15:42 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/594d5039f8
15:56 cotto_work ~~
16:00 adu joined #parrot
16:01 vmspb left #parrot
16:03 theory joined #parrot
16:08 Andy joined #parrot
16:09 bluescreen left #parrot
16:10 whiteknight we really need a library function for will_cause_segfault(void*ptr)
16:11 Patterner left #parrot
16:11 whiteknight returns 1 if dereferencing that pointer would cause a segfault
16:11 whiteknight and then I can decide not to do that
16:11 NotFound whiteknight: I'd like better a function do_what_i_want_right_and_fast ;)
16:12 whiteknight NotFound: but if we pass in a segfaulty pointer, it breaks
16:12 NotFound Then: void do_what_i_want_right_and_fast (void)
16:13 whiteknight ah, okay
16:14 plobsing I've recently had a very evil idea to remedy the PIR/arbitrary-constants problem
16:14 whiteknight what's the problem?
16:14 whiteknight and then...what's the solution?
16:14 plobsing PIR is a declarative language and can only express concepts its creators imagine
16:14 NotFound plobsing: more evil than the one I said yesterday?
16:15 plobsing which means that HLL authors wanting to capture complex data in PBC are SOL with PIR
16:15 plobsing NotFound: what did you say yesterday?
16:15 NotFound plobsing: make the constant table writable during :load and :init
16:16 plobsing nope, mines more evil.
16:16 whiteknight it already is writable during :immediate
16:16 plobsing whiteknight: yes, but not arbitrarily.
16:16 Psyche^ joined #parrot
16:16 Psyche^ is now known as Patterner
16:16 whiteknight plobsing: okay, get on with it!
16:16 NotFound whiteknight: :immediate does not work well enough.
16:16 whiteknight Notfound: I never said it worked well. Only that it works. In theory.
16:17 plobsing if we had a fairly simple language with a powerful lexing system (eg: forth, scheme), we could abuse the hell out of the reader and make it a *superset* of PIR
16:18 whiteknight I'm not sure what you mean by that
16:18 NotFound Me neither
16:18 plobsing which could destructure PIR into an imperative form, allowing for arbitrary operations on the segments being compiled
16:19 whiteknight I don't follow any of that
16:19 dalek TT #1993 created by doughera++: New api.yaml tests require YAML.pm and List::MoreUtils.pm
16:19 dalek TT #1993: http://trac.parrot.org/parrot/ticket/1993
16:19 plobsing ok, in terms of which language should I explain it? forth or lisp?
16:19 whiteknight I'm not super familiar with either. Lisp
16:20 plobsing OK, in terms of lisp, '.sub' starts a reader macro, which expands to (defsub ... (... ops ...)) or somesuch
16:22 cotto_work It's times like this that I wish I could see more in lisp than toenail clippings.
16:22 NotFound Do you mean writing a pir interpreter that generates the pbc from the code is interpreting?
16:23 plobsing NotFound: yes, but as part of the language lexer, so that the "abused" language is fully available when we want to escape from PIR
16:24 pmichaud whiteknight: ping
16:26 whiteknight pong
16:26 pmichaud yesterday during the various nqp discussions you mentioned that you don't like it's use of lexicals ... and clarified that you didn't like the bulk associated with them
16:27 pmichaud is that reasonably accurate?
16:27 whiteknight what I meant by that, is that I don't like that bulk being added in automatically
16:27 whiteknight that is, some variables don't need lexical scoping rules
16:27 plobsing paying for features you don't use is not good
16:27 pmichaud I just want to say that this is not really an issue with nqp itself -- it's the design of past and parrot's symbol tables that require it
16:28 pmichaud nqp doesn't make those determinations -- past and post do
16:28 whiteknight yeah, I know that. It's something we need to fix
16:28 pmichaud it's a problem for all pct-based languages, not just nqp
16:28 whiteknight but in any case, a language that goes through PAST and POST is going to have those problems
16:28 whiteknight so my complaints weren't directed at NQP per se
16:28 pmichaud that's how they came across, to me at any rate
16:29 whiteknight I apologize then for the miscommunication
16:29 NotFound That is one of the reason I'm skecptical about apossible winxed PAST or POST backend.
16:30 pmichaud oh, I think PAST ought to be redesigned to have a better variable allocation strategy, no doubt
16:30 pmichaud but Parrot's underlying register and symbol table needs a lot of work too
16:30 pmichaud the overhead with lexicals arises from not having a good container/value model
16:30 whiteknight yes
16:30 pmichaud or reference types
16:31 pmichaud and a lack of binding/assignment semantic distinctions
16:31 whiteknight right. All those things we know to be problems. What we don't have is a compelling design to fix it
16:31 plobsing winxed seems to mostly get by without that
16:31 pmichaud the new nqp is working on fixing that
16:31 whiteknight if somebody such as yourself tells us what they need to see in those areas, we can start putting together a design
16:32 cotto_work pmichaud: great.  What do you need from Parrot to do that?
16:32 * cotto_work hopes it's something that can be done
16:33 pmichaud cotto_work: well, there are several pieces to the problem
16:33 NotFound plobsing: winxed has binding/assignment distinction.
16:33 pmichaud let's start by identifying those
16:34 pmichaud whiteknight: which part of lexicals bugs you the most?  that might be a good place to start
16:34 plobsing NotFound: true, but the weakness of the bind/assign semantics doesn't infect the entire design
16:34 NotFound There is an obstacle in the way to a clean design: morph
16:35 whiteknight pmichaud: no particular part. The overhead of calling set_lex and find_lex for register values which won't be used in inclosing scopes is what I was mostly talking about
16:35 whiteknight that is, if I don't need a variable to be .lex, I don't want it to be used that way
16:35 NotFound morph and Parrot_pmc_reuse
16:35 pmichaud so, you think that nested scopes should not translate to nested parrot subs?
16:36 pmichaud because that's the blocker there
16:36 whiteknight pmichaud: in some cases they should. But if we have no nested scopes, we don't need .lex and LexPad
16:36 dalek TT #207 closed by doughera++: Unsecure RUNPATHS in parrot 0.90
16:36 dalek TT #207: http://trac.parrot.org/parrot/ticket/207
16:37 whiteknight my point is only this: For a low-level parrot language, I would be able to specify the :outer relations where necessary, and I should be able to avoid storing values in LexPads for values that I don't want stored that way.
16:37 NotFound winxed uses nested scopes for anonymous functions but does not lexicalize unused variables.
16:38 NotFound Unused in the innner scopes, that is.
16:38 pmichaud PAST doesn't lexicalized unused variables in the inner scopes either
16:39 pmichaud oh, wait
16:39 pmichaud I think I misread
16:39 pmichaud you mean it doesn't lexicalize variables in an outer scope if that variable isn't used in any inner scopes
16:39 NotFound Yes
16:40 pmichaud what about dynamic evals?  or should we simply say "can't be used in low-level parrot"?
16:40 cotto_work that'd make Q:PIR tricky
16:40 pmichaud or do we say "if you want to access a variable from an eval, you have to make sure it's lexicalized"?
16:40 plobsing not every language has to support dynamic evals. those that don't shouldn't have to pay the price.
16:40 pmichaud and yes, Q:PIR is definitely an issue there.
16:40 whiteknight depends what you want the scoping rules to be. Is the eval executed on it's own, or as a lexically-nested inner sub of the caller?
16:40 NotFound winxed doesn't have evals.
16:40 pmichaud eval is almost always executed as lexically-nested inner sub
16:41 whiteknight it seems to me like that isn't a decision our lowest-level language should make
16:41 whiteknight in nqp?
16:41 pmichaud it has to be, otherwise you can't access any variables from the scope you're calling eval from
16:42 whiteknight and if I don't want to access any of those variables, then it doesn't need to be lexically scoped
16:42 whiteknight or if I write out the variables as constants in the code string
16:43 NotFound I suppose you can detect if any of that conflicting things is used, and optimize if not.
16:43 whiteknight or if I compile a function and pass values in through the parameter list
16:43 pmichaud yes, those are all possibilities.  it'd be confusing to some programmers, but that's probably okay for a lower-level language
16:43 whiteknight my only point is that we have occasional (not common) needs for a language lower-level than NQP
16:44 whiteknight PIR currently fits that niche
16:44 whiteknight but I think we would all like to replace PIR with something of similar scope but nicer and more extensible syntax
16:45 pmichaud okay.  This helps.  We'll definitely make register and variable optimization a key component of the new PAST we're creating
16:45 whiteknight with PIRATE in the wings, it may be possible to improve PIR in-place over time. This is especially good if most people use something higher up (NQP or other HLL) and aren't relying on PIR syntax directly
16:46 pmichaud btw, I think that the entire lexical situation would be hugely improved if it were possible to use lexical to "map registers" from outer frames directly
16:46 pmichaud for example:
16:46 pmichaud .sub 'outer'
16:46 pmichaud .lex '$a', $P0
16:46 pmichaud ...
16:46 pmichaud .end
16:46 pmichaud
16:46 pmichaud .sub 'inner' :outer('outer')
16:46 pmichaud .outer-lex '$a', $P5
16:46 pmichaud ...
16:47 pmichaud .end
16:47 pmichaud the '.outer-lex' directive would map the local register $P5 to $P0 of the outer sub
16:47 pmichaud so that any references to $P5 in inner are actually references to $P0 in outer
16:47 whiteknight The problem with that example is that currently register identifiers are mapped directly to indices in a memory block
16:48 plobsing pmichaud: and the underlying mechanism would be more efficient how?
16:48 whiteknight what we would need instead is a "register reference" type
16:48 pmichaud plobsing: because we no longer need store_lex or find_lex
16:48 whiteknight so .outer-lex '$a', $R0
16:48 whiteknight $P5 = $R0
16:48 whiteknight and later: $P0 = $P5
16:48 pmichaud any rebinding of $P5 in the inner scope would automatically rebind $P0 in the outer scope
16:48 plobsing pmichaud: *YOU* no longer need store_lex/find_lex, because we've pushed the complexity behind the curtain of the compiler
16:48 whiteknight er, $R0 = $P5
16:48 pmichaud plobsing: actually, we've pushed the complexity into the virtual machine
16:49 pmichaud because the mapping of inner to outer scope has to take place at runtime, not compile time
16:49 pmichaud it's still the same effort that we currently do for find_lex
16:50 pmichaud but it cleanly resolves a lot of the binding/assignment problem, which is what leads to the overhead in the first place
16:50 pmichaud furthermore
16:50 pmichaud if/when lexicals can map to registers other than PMCs, this resolves the same issue that will take place there
16:50 pmichaud i.e.
16:50 pmichaud outer:     .lex '$a', $I0
16:50 pmichaud inner:    .outer-lex '$a', $I5
16:50 pmichaud changes to $I5 in inner are reflected in $I0 in outer
16:51 pmichaud otherwise, lexical native types will also have to always be doing find_lex and store_lex operations
16:51 pmichaud because of the possibility of reassignment
16:52 whiteknight I definitely understand what you're saying. That particular solution would probably be a nightmare for common-case performance, but the underlying idea is a good one
16:52 pmichaud why is it a nightmare for common-case performance?
16:52 pmichaud it's not a performance hit at all
16:52 dukeleto ~~
16:52 pmichaud it's far less of a performance hit than what we do now
16:53 whiteknight because like I said, registers in PIR are integer indices into an array. If we change them to possibly be pointer-aliases, we pay a performance hit by having to ask whether a register is a value or a reference, or we have to always dereference and store a second array of register pointers
16:53 pmichaud in inner subs only
16:54 pmichaud and only when accessing an outer lexical
16:54 pmichaud it could be a fifth bank of registers, too
16:54 whiteknight like I said, the underlying idea is a good one. We need to find a clean way to implement it which doesn't cost us the farm
16:54 pmichaud i.e., I/S/N/P/R
16:54 pmichaud in that fifth bank, we always know the registers are references
16:55 pmichaud and then it's always    .outer-lex '$a', $R5
16:55 pmichaud as you alluded earlier
16:55 whiteknight right. but then we have to worry about typing. Is it a register to P? Register to S?
16:55 whiteknight $RP5
16:55 whiteknight that's actually very workable
16:56 pmichaud also, the compiler knows that the registers are references... that can be static instead of runtime performance
16:57 NotFound whiteknight: not neccesarily, the .lex declaration provide the information.
16:58 pmichaud in earlier versions of parrot, where we were using the "sliding window register banks" approach, being able to share registers across sub invocations was explicitly designed for
16:58 pmichaud somewhere Parrot lost that
16:58 pmichaud i.e., it was then trivial to have a called sub manipulate key registers of a caller sub
16:59 whiteknight I can imagine both many problems and many benefits with that approach
16:59 whiteknight it was before my time, however
16:59 plobsing whiteknight: (re: pirate might make PIR nicer) PIR is a declarative syntax, which is inherantly limiting. we need an imperative means of constructing PBC if we want to get more general, which is a better approach in my mind than adding yet another special case syntax.
17:00 pmichaud anyway, thanks for listening
17:01 whiteknight pmichaud: any time. We love the feedback
17:02 whiteknight plobsing: it really depends what we want PIR to be. is PIR simply a syntax for constructing PBC? Is it more than that
17:02 whiteknight ?
17:02 plobsing what more could it be?
17:02 whiteknight right now it's best use is in writing tests for libparrot
17:03 whiteknight making that easier for our testers would be a big benefit
17:03 pmichaud oh, there's another huge advantage of having a fifth bank of registers exclusively for lexicals
17:03 whiteknight to a smaller degree it's used in writing libraries
17:03 whiteknight pmichaud: do tell
17:03 NotFound A linker more capable than pbc_merge and suppor for it in the pbc format can solve some problems.
17:04 pmichaud right now when a outer sub exits, if any inner closures possibly exist then we have to keep the context for the outer sub around
17:04 pmichaud because the inner closure may need to reference lexicals from the outer sub (even though it has exited)
17:04 pmichaud currently, since lexicals are mapped to the P-bank of registers, that means that all of the P registers are marked "live" for GC
17:04 pmichaud (as well as everything those PMCs mark)
17:05 pmichaud so, if a P-register was used as a temporary in an outer sub that has to continue to stick around, its PMC (and all of that PMC's children) are kept alive, even though they are in fact totally inaccessible
17:06 pmichaud imagine a PMC that was used to temporarily hold the results of a parse tree
17:06 pmichaud however, if all of the lexicals were moved to their own register bank, then it would be safe to clear the PMC bank when the sub exits
17:06 pmichaud releasing a *ton* of pressure on the GC
17:06 plobsing pmichaud: if you know that's going to happen in advance, you could null the registers
17:07 pmichaud we've thought about having PCT automatically null its temporaries, yes.
17:07 pmichaud but that feels like more code bloat.
17:07 pmichaud then people will say "why is NQP generating all of these 'null $Px' instructions?"
17:07 plobsing sure, your approach is cleaner. but this one is simpler and allows a demonstration (as opposed to speculation) of exaclty how much win we get
17:08 whiteknight pmichaud: That's definitely something important to keep in mind
17:08 pmichaud well, except it's often hard to know when a register is temporary
17:08 particle1 so then the instruction generated should be 'null $Px # reduce gc pressure' ;)
17:08 particle1 is now known as particle
17:08 plobsing if you make that and can demonstrate a marked improvement in GC behaviour, your case becomes a lot stronger
17:09 whiteknight a good register allocator may be overwriting registers anyway. Adding in lots of null operations would actually defeat that
17:09 particle no, i'm not really advocating that.
17:09 pmichaud but we can perhaps modify PCT to maintain a list of the registers it creates as temporaries (that aren't lexicals) and null them out
17:10 plobsing whiteknight: a register allocator has to know about the lifetime of registers anyways. it knows that null is a write-only, pure operation and therefore, nulling will not interfere with a register allocator
17:10 pmichaud as I said, it's really hard to know when a temporary is no longer being used.
17:11 whiteknight brb food
17:11 pmichaud especially since the temporaries that are likely to be big are the ones that come from subroutine calls and the like
17:11 PerlJam pmichaud: earlier you said "a fifth bank of registers exclusively for lexicals"  Would that be true?  Or would the 5th bank have general utility where the most obvious use is for keeping lexicals?
17:12 pmichaud PerlJam: well, they could have several purposes
17:12 pmichaud (1) easilly mappable between contexts
17:12 pmichaud (2) lifetimes that extend beyond the scope of a sub execution
17:12 plobsing pmichaud: for the find_lex/store_lex issue, how about explicitly using keyed access on the outer context? ( $P0 = get_outer_context 1; $P0[lexical-index] = 1 )
17:13 pmichaud plobsing: we've been planning to do something exactly like that in new NQP, yes.
17:13 pmichaud But it just means you're replacing find_lex/store_lex with keyed lookups
17:14 pmichaud also, note that sometimes the compiler cannot know the distance to the outer context that contains the symbol
17:14 pmichaud (e.g., in evals)
17:14 pmichaud so it's more of an optimization than a standard mechanism
17:15 pmichaud but instead of a declaration, it could be an opcode, perhaps
17:16 PerlJam pmichaud: also, does that mean that this hypothetic 5th bank of registers is special as compared with the others?  e.g., when you "save context", you're really only concerned with the 5th bank and not the others (the INSP are all assumed temporaries)?
17:16 pmichaud $R0 = map_outer_lex '$a'   # map $R0 to the outer lexical $a
17:16 pmichaud PerlJam yes
17:16 pmichaud PerlJam -- more to the point, it's not about "saving context", it's about nulling out no-longer-needed things
17:16 pmichaud i.e., it's safe to null out the $P registers on sub exit, but you leave the 5th back alone and let normal GC take care of it
17:17 pmichaud s/back/bank/
17:17 plobsing if subs marked what they needed within the context (in stead of the context marking all of its contents) you'd get the GC improvement
17:17 PerlJam how would you not accidentally clobber something in the 5th bank?
17:17 pmichaud PerlJam: I don't understand "not accidentally clobber"
17:17 plobsing pmichaud: you've said yourself it is hard to tell what is a temporary
17:18 pmichaud plobsing: in this case, $P registers are all temporaries
17:18 PerlJam okay, say I need to keep a value around, so I stick it in an R register.  How do I know which R register to use?
17:18 plobsing you've just change the problem into "its hard to tell what you can save in a $P register"
17:18 plobsing the problem is moved, not solved or mitigated
17:18 pmichaud okay, so let's fix that one instead
17:19 pmichaud let's create a bank of registers that are explicitly temporary
17:19 pmichaud and can be cleared on subexit
17:19 pmichaud anyway, I agree that we can see about fixing this in PAST before we do anything else
17:19 pmichaud however
17:20 pmichaud it may be a little difficult to figure out how much savings to allocate to this particular change, since so much will be changing in other places as well
17:21 pmichaud PerlJam: (how do I know which R register to use)  -- you allocate a new R register for each new thing you need to keep -- same as we do now
17:21 pmichaud that way you don't clobber any existing ones
17:22 plobsing I don't think it is worth making this change unless and until it can be demonstrated to have improvements in benchmarks. It may be intuitive (at least to you) that it would improve performace, but I want proof for such a large change.
17:22 PerlJam pmichaud: so, what would that look like?
17:22 pmichaud we know from past analysis that large data structures are being kept around long after they're no longer needed or used (e.g., parse trees)
17:23 pmichaud we don't have sufficient tools to be able to find out what is holding on to them
17:23 dmalcolm joined #parrot
17:23 pmichaud we also know that contexts stay alive long after the outer subs have exited
17:23 pmichaud and thus all of their contents stay alive
17:23 plobsing pmichaud: null dead registers, see if it can reduce GC churn
17:24 pmichaud plobsing: that's my point -- we don't have a good way of knowing which registers are 'dead'
17:24 bluescreen joined #parrot
17:24 plobsing you are at least implying some knowledge that they are "large data structures are being kept around long after  they're no longer needed or used
17:24 pmichaud I had speculated at one point that we could have something that looks at the context's LexPad and nulls out all of the registers that aren't in the LexPad
17:24 plobsing "
17:25 pmichaud I know that they're being kept around because GC isn't picking them up
17:25 pmichaud that doesn't mean I know which registers are holding them.  I truly wish I did.
17:25 plobsing how can you know that without knowing which registers are dead?
17:25 plobsing those bits of information are one and the same
17:25 pmichaud I can know in this manner
17:25 pmichaud I compile some HLL source code
17:25 pmichaud that produces a parse tree
17:25 pmichaud the parse tree is big
17:26 pmichaud we then compile the parse tree down to the bytecode
17:26 pmichaud the routines that needed the parse tree are all gone
17:26 pmichaud but the parse tree is never gc'ed
17:26 pmichaud something is holding a reference to the parse tree
17:26 pmichaud I don't know what is holding that reference, but something is, therefore it's still "alive"
17:27 pmichaud and we see the existence of the parse tree in the cost of subsequent mark+sweep operations
17:27 moritz maybe the GC can somehow be hacked to show what references exist to a certain mem location?
17:27 moritz I mean, printfs sprinkled all over :-)
17:29 cotto_work #ps in 178
17:30 pmichaud PerlJam: (what would that look like?)   Same as what we do now.  In PAST, whenever I need a new register, I just generate  $Pxxx where 'xxx' is some unique number that hasn't been used before.  IMCC takes care of allocating a unique register for it.
17:30 plobsing pmichaud: how about we null all the non-lex registers in returncc?
17:31 pmichaud plobsing: yes, that's what I mentioned a few lines above, about LexPads
17:31 plobsing that would cut the problem down into "a context is holding on to the tree" vs "something else is holding on to the tree"
17:31 pmichaud it cuts it down further than that, even
17:31 plobsing I've seen no evidence to support that it is somehow a stray context in stead of a stray global, or an entry in a hash
17:32 plobsing we don't know what is causing the problem, so perscribing solutions at this point is *silly*
17:32 pmichaud I do know that contexts exist long after they are exited
17:32 pmichaud I do know that all of the registers in a context are therefore preserved, whether they need to be or not
17:33 pmichaud this is a problem that wants a solution
17:33 pmichaud I agree that the particular case I cite above could be due to a stray global
17:33 pmichaud I'd like to have some better tools to find out the cause
17:34 pmichaud I don't know what they would look like -- that's a bit beyond my area of Parrot core expertise
17:34 NotFound There are also things being marked from the signature objects in the context.
17:35 pmichaud it could be very interesting if I could somehow mark a PMC with a flag that says "if after this point you encounter the PMC in a mark-sweep, give me the trace that led to it"
17:36 pmichaud then, I could mark big PMC structures (like the parse tree) with the flag when I think they're no longer needed, and if they show up as alive in a later mark+sweep I can at least have some clue of the PMCs that led to it
17:37 plobsing that would require a recursive GC wich would most likely blow your stack
17:38 pmichaud at least until recently, a recursive GC is exactly what we had
17:39 plobsing which is why I know about the stack-blowing issues
17:39 pmichaud I'm not saying we should go back to that, but a tracing GC that is able to keep track of such situations would be a big help
17:40 plobsing I just thought of a horribly inefficient algorithm that would give what you asked. Tell the GC to give you a list of all objects that reference another object, run GC, update searched-for object, repeat.
17:41 pmichaud that would actually be just fine
17:41 Kristaba joined #parrot
17:41 pmichaud if we just had a tracing GC that could output all of the references, a perl script could afterwards analyze it to find the chain(s)
17:42 pmichaud or even a 'gc_trace' opcode
17:42 pmichaud that performs mark/sweep with tracing enabled
17:43 pmichaud right now the reference situation is largely invisible to anyone working in PIR, so it's very hard to see what's happening
17:44 vmspb joined #parrot
17:45 arnsholt left #parrot
17:45 particle surely there's an unused flag bit in the parse tree pmc type
17:46 pmichaud parse trees are Regex::Match objects
17:47 pmichaud but I'd want it for all PMCs, not just match objects
17:47 plobsing any feature implemented for only a specific type is broken beyond beleife
17:47 PerlJam If you could dump the state of the GC to stderr, you could take snapshots whenever you wanted.
17:48 pmichaud PerlJam: yes, see 'gc_trace' above :)
17:48 PerlJam sorry, I'm only paying 0.25% attention right now
17:53 sheant joined #parrot
17:55 arnsholt joined #parrot
17:58 cotto_work It's funny how many wiki pages I look at, only to see that I originally created the first version.
18:11 particle plobsing: my suggestion was to debug one particular problem, not to be a general solution. flag bit + gdb can work for finding what's holding a parse tree.
18:12 particle *ref to a parse tree
18:16 whiteknight plobsing: ping
18:18 whiteknight actually, unping
18:20 whiteknight ...and plobsing: reping
18:31 plobsing whiteknight: pong, unpong, repong?
18:33 whiteknight plobsing: the Eval PMC destroy vtable. Is there any way we're destroying PackFiles in there?
18:33 whiteknight any reason?
18:35 adu whiteknight: have you ever been on the tetration forum?
18:35 plobsing we most likely are destroying packfiles there. if they are still necessary, the subs will have a pointer to the eval PMC and keep it alive.
18:36 plobsing in this way, the eval PMC is providing primitive GC support for the packfiles it manages
18:36 arnsholt_ joined #parrot
18:36 tadzik hello parrots
18:36 arnsholt_ left #parrot
18:37 whiteknight plobsing: is that something we want?
18:37 whiteknight adu: not that I am aware of
18:38 plobsing we want packfiles GCable, yes. how eval goes about doing it? probably not.
18:38 whiteknight adu: I used to go to several programming forums several years ago. I can't remember which
18:41 bluescreen left #parrot
18:47 dalek winxed: r766 | NotFound++ | trunk/winxedst1.winxed:
18:47 dalek winxed: add predefined symbol __FUNCTION__ and change ns and class path handling to
18:47 dalek winxed: support it
18:47 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=766
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: f7bdb4f | Whiteknight++ | / (6 files):
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: a few small fixes. We're still failing trying to build PGE, but I'm slowly getting past problems one at a time
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/f7bdb4f21c
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: d7e666a | Whiteknight++ | / (2 files):
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: give evals proper names again
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/d7e666a3bc
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: 8e327c4 | Whiteknight++ | src/pmc/imccompiler.pmc:
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: make sure to restore the interp->code pointer after invoking the IMCC compreg
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/8e327c4ef1
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: 713f76b | Whiteknight++ | tools/dev/pbc_to_exe.pir:
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: register PIR and PASM compregs in pbc_to_exe.
18:49 dalek parrot/whiteknight/imcc_compreg_pmc:
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: This fixes some of the bugs I was seeing in pbc_to_exe. Now I'm seeing a segfault when running nci thunk generator
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/713f76ba6b
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: b494693 | Whiteknight++ | src/pmc/imccompiler.pmc:
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: reset imcc before calling into it. This gets us much further in the build
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/b494693e59
18:49 dalek parrot/whiteknight/imcc_compreg_pmc: bfa470e | Whiteknight++ | / (2 files):
18:50 dalek parrot/whiteknight/imcc_compreg_pmc: build eval pmc in IMCCompiler.invoke.
18:50 dalek parrot/whiteknight/imcc_compreg_pmc:
18:50 dalek parrot/whiteknight/imcc_compreg_pmc: This should preserve current PIR-facing behavior of this method, which we don't need to do since it's deprecated. I'll tackle that beast in a different branch. segfaulting in nci thunk generator
18:50 dalek parrot/whiteknight/imcc_compreg_pmc: review: https://github.com/parrot/parrot/commit/bfa470e300
18:52 chromatic joined #parrot
18:57 whiteknight I'm getting a really weird segfault now in this branch, if anybody has a few tuits to look at it
19:03 nwellnhof joined #parrot
19:13 dalek Heuristic branch merge: pushed 152 commits to parrot/nwellnhof/gc_dynamic_threshold by nwellnhof
19:14 nopaste "nwellnhof" at 192.168.1.3 pasted "pmichaud's GC test on nwellnhof/gc_dynamic_threshold" (301 lines) at http://nopaste.snit.ch/29949
19:14 whiteknight what is the output supposed to look like?
19:14 pmichaud like that.  :-)
19:15 cotto_work pmichaud++
19:15 pmichaud the original would have very long lines of #'s when a gc mark/sweep run occured
19:16 nwellnhof now we have more but shorter GC runs
19:16 tadzik mind showing the old output, or the script itself?
19:16 pmichaud just a sec
19:16 pmichaud (running it now)
19:17 cotto_work what do those octothorpes represent?
19:17 pmichaud http://gist.github.com/806427
19:17 pmichaud each octothorp represents 0.02 second spent in the iteration
19:17 pmichaud (or time spent since the previous iteration)
19:17 cotto_work ok
19:18 pmichaud we'd like the iterations to be somewhat even.  in the gist output I just made, you'll see that iterations 63, 149, and 225 are 10x slower than the others
19:18 cotto_work yup
19:18 pmichaud that's because of gc, we believe
19:20 cotto_work pmichaud: have you thought about what kind of interface the "use Parrot;" layer of nqp would look like?  (also, what's a better name)
19:21 pmichaud cotto_work: it depends on what features of parrot need to be exposed
19:21 pmichaud for example, "use Parrot;"  would enable the pir:: or pirop:: namespace for access to individual Parrot opcodes
19:22 pmichaud I suspect it would also enable the "is vtable('...')"  and "is multi('...')"  traits for decorating subs with :multi, :vtable, etc.
19:22 pmichaud it could also bring in prototypes for access to Parrot's built in PMC types
19:22 pmichaud i.e., so one can use  Integer/Float/ResizablePMCArray/etc directly
19:23 cotto_work that'd work through pir::new('X');
19:23 pmichaud yes, we could fix that too
19:23 jnthn Eww, not string new. :)
19:23 pmichaud it might also enable some syntax for generating Key constants
19:24 jnthn :)
19:24 cotto_work bacek++ #tuning the moon
19:25 whiteknight every time you call new_p_sc, somewhere, somehow, jnthn gets hit in the face with a rock
19:28 nwellnhof pmichaud: that GC tracing thing shouldn't be too hard to implement. the biggest problem i see is how to identify PMCs. output like "that PMC is referenced by a PMC at 0xdeadbeef" isn't very helpful.
19:28 nwellnhof tracking the sub where a PMC was created seems like a good idea.
19:29 nwellnhof and we have the type of a PMC of course.
19:29 pmichaud type of a PMC I think was what I was looking for
19:29 cotto_work We have a very large number of invalid addresses we can use.
19:30 pmichaud knowing the sub where a PMC was created would be outstanding
19:30 pmichaud as I mentioned earlier, it would be *really* helpful to track the number of PMCs being created by each sub
19:31 nwellnhof we would probably need a compile time flag that adds some debugging slots to subs and PMCs.
19:31 PerlJam nwellnhof++ when does gc_dynamic_threshold get merged to master?  :)
19:32 pmichaud fwiw, adding a count-of-PMCs slot to subs shouldn't be all that expensive
19:32 contingencyplan joined #parrot
19:32 pmichaud whether or not it gets counted could be triggered by a toggle
19:32 pmichaud so it doesn't add much in the way of runtime overhead
19:32 pmichaud but basically, I'd think have pmc_new (or whatever does the memory allocation) simply increments the count inside of the current_sub of the interpreter
19:32 pmichaud (when the enabling flag is set)
19:32 chromatic Don't tie it to the sub; tie it to the context.
19:33 pmichaud except that I don't have a way to report contexts
19:33 pmichaud at the end, I really want to know which subs are responsible for creating all those pmcs
19:33 pmichaud and contexts don't have that long a life
19:33 whiteknight tying it to the sub would probably be the most valuable
19:33 chromatic Tying it to the sub is broken.
19:33 whiteknight that count includes information about which subs are hot
19:33 pmichaud fair enough
19:34 chromatic Half of the problem of artifically extended lifespans is that our subs *aren't* read only at runtime.
19:34 chromatic The other half of the problem is a lack of any sensible register allocator.
19:35 pmichaud we'll always have some subs that have to be not-read-only, I fear.
19:35 pmichaud eval() comes to mind
19:35 pmichaud either that or we need a lot better :outer() handling
19:35 chromatic Creating new subs is fine.
19:35 chromatic Writing to existing subs is not.
19:35 freeksh0w86 left #parrot
19:35 pmichaud there's not presently a way to create a new sub attached to an existing outer
19:36 pmichaud we have to create the sub, then modify its :outer
19:36 pmichaud similarly for doing things like attaching HLL signatures
19:36 chromatic I agree. Those need fixing.
19:36 chromatic But please don't add to the list of things that need fixing.
19:36 pmichaud unless the declaration syntax is going to enable us to attach arbitrary attributes or wrappers at compile time
19:36 pmichaud I'm just saying that "constant subs" requires a lot of other big changes first.
19:37 chromatic I agree.
19:37 nwellnhof bacek, ping
19:37 pmichaud if there's a way to mark a sub as read-only after it's been "managed", that would be okay also.
19:37 pmichaud i.e., the HLL could say "I'm done fiddling with this Sub, it's constant now."
19:38 pmichaud because (at least in rakudo), once we get all of the attributes and signatures attached to the object, it effectively is (or should be) constant after that.
19:38 pmichaud It's simply that PIR/PBC doesn't give us enough ability to decorate the sub with everything we need at IMCC compile time.
19:39 chromatic The biggest problem is the part of Sub's invoke() which stores the active context in the sub to allow runtime closure creation.
19:39 pmichaud if we want to deprecate that capability, I'd be okay with that.
19:39 chromatic It should help GC dramatically.
19:39 pmichaud that's really been there for backwards compatibility, afaik.
19:39 pmichaud or if there's a way that we could decorate a sub to say "don't store the active context", that'd work too.
19:40 jnthn I thought that was ow capture_lex worked?
19:40 jnthn *how
19:40 pmichaud capture_lex captures outer contexts into the current context
19:40 pmichaud the part where it gets stored in the sub is for autoclose, iirc.
19:40 pmichaud capture_lex avoids the need for that altogether
19:40 jnthn ah, ok
19:40 pmichaud oh wait, perhaps not.
19:40 pmichaud hmmm
19:40 jnthn auto-close only gets hit due to lack of static lexpads
19:41 pmichaud anyway, iirc auto-close is the bigger culprit here
19:41 jnthn It causes a bunch of our issues
19:41 pmichaud but yes, capture_lex has an issue as well -- because we have to tell the sub which closure to use when its context is created
19:42 jnthn In nqpclr, if you try to hit an outer that's never been invoked, it doesnt magically create a lexpad. It just uses the static one. And the stuff bound into that is the basis of the lexpad for all future invocations.
19:42 jnthn So you can install something in it once (e.g. at init or even compile time once it's bootstrapped)
19:42 jnthn And you're done.
19:43 jnthn That's why I have a $?CLASS lexical there, and can't do that in nqp-rx/nom at the moment.
19:43 nwellnhof aloha msg bacek do you see any problems with nwellnhof/gc_dynamic_threshold? otherwise i'd merge it soonish.
19:43 aloha nwellnhof: OK. I'll deliver the message.
19:44 nwellnhof PerlJam: i think we can merge gc_dynamic_threshold in the next couple of days.
19:45 pmichaud nwellnhof: did you notice any other issues in larger programs, such as in building Rakudo itself or running Rakudo's spectests?
19:45 pmichaud i.e., in making the one small program run better, did we lose something on the larger ones?
19:47 nwellnhof pmichaud: it improves Rakudo build time on low-memory systems, and is a bit slower on machines with more memory. although that can be tuned manually.
19:47 nwellnhof it didn't notice any spectest breakage, but i have to retest.
19:47 pmichaud okay
19:47 pmichaud "a bit slower" is probably okay.  a lot slower will cause pain :)
19:47 nwellnhof *i
19:48 PerlJam nwellnhof: when you say "tuned manually" does that mean "edit a file and change a number"  or something else?
19:48 nwellnhof PerlJam: command line options, currently
19:48 nwellnhof environment variables or config files might be nicer.
19:50 nwellnhof and you can trigger tt #1990 easily, but there's a simple workaround.
19:55 dalek tracwiki: v3 | pmichaud++ | RakudoTasklist
19:55 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Rak​udoTasklist?version=3&amp;action=diff
19:55 nwellnhof see also http://irclog.perlgeek.de/p​arrot/2010-12-24#i_3116771
19:58 pmichaud http://gist.github.com/806539   # gc-1 benchmark instrumented with memory usage
19:59 pmichaud I don't see a significant jump in memory usage on the first iteration, fwiw
20:00 pmichaud actually, I guess the first iteration consumes 4MB extra, relative to the others
20:01 pmichaud so that's consistent with what nwellhof++ reported
20:01 nwellnhof pmichaud: that's because TOTAL_MEM_ALLOC also counts freed memory.
20:01 pmichaud I'm sure the extra there is because of methods being invoked for the first time and therefore having their signatures generated + attached
20:01 pmichaud still, 4MB seems like an awful lot for that.
20:02 nwellnhof i will add TOTAL_MEM_USED which is much more accurate.
20:02 pmichaud please do
20:02 pmichaud and something is leaking a ton of memory, which I wouldn't really expect in this little program
20:03 pmichaud oh, wait
20:04 pmichaud TOTAL_MEM_ALLOC is the total of all memory allocated, including that which is freed
20:04 pmichaud so obviously this number is monotonically increasin....no, that can't be it
20:04 pmichaud what does TOTAL_MEM_ALLOC really represent?
20:04 pmichaud or is it really just not useful as currently implemented?
20:05 nwellnhof pmichaud: yes, it's monotonically increasing because Parrot doesn't return (most of the) memory to the system.
20:06 pmichaud but in the output I just nopasted, it's not monotonically increasing
20:06 pmichaud it resets to a lower number after some of the gc runs
20:06 nwellnhof yes, it's buggy in master.
20:06 pmichaud okay, so "not useful as currently implemented"
20:07 nwellnhof yes, it should be more useful in my gc branch.
20:14 nwellnhof pmichaud: i'll try your new test script on my branch after make spectest has finished.
20:15 nwellnhof memory accounting is a bit complicated because Parrot also uses malloc for a lot of stuff.
20:17 whiteknight we really should be able to move most uses of malloc to the fixed-size allocator
20:17 whiteknight that's neither here nor there
20:18 nwellnhof everything except large arrays and hashes probably.
20:18 whiteknight and even then, we could add a new mechanism to the gc for allocating those things
20:19 whiteknight even if that "mechanism" was initially a thin wrapper around malloc
20:19 whiteknight at least initially
20:19 tcurtis joined #parrot
20:19 nwellnhof yes, we could implement a variable size allocator that works like the fixed size allocator but uses size classes.
20:20 nwellnhof btw, we have that wrapper already.
20:20 whiteknight do we? I can't keep track of all the things we have now
20:21 nwellnhof the usual sequence is mem_gc_allocate => Parrot_gc_allocate_memory_chunk => malloc
20:22 nwellnhof then there's mem_sys_allocate which also calls malloc
20:22 nwellnhof it's a bit messy.
20:24 whiteknight ok
20:25 cotto_work #ps in 5
20:25 cotto_work get those reports posted, slackers!
20:25 Hackbinary hello
20:25 Hackbinary I have a silly question
20:26 cotto_work Hackbinary: you may get a silly answer then, but it's worth a shot.
20:26 Hackbinary Thanks :)  I have some stuff to commit the cardinal project, but how should I do that? Should I create fork then someone else will pull in my changes?
20:26 Tene Hackbinary: that would be just fine
20:27 Tene If you submit a few good patches, I'll give you commit privs on the cardinal repo.
20:27 Hackbinary Tene: okay, that sounds good :)
20:28 whiteknight cardinal is at parrot/cardinal now, not cardinal/cardinal
20:28 plobsing left #parrot
20:28 whiteknight but same principle applies: create a fork and submit pull requests and patches
20:28 pmichaud does INTERPINFO_TOTAL_PMCS no longer work?
20:29 cotto_work we need this stuff documented
20:29 Tene whiteknight: does being hosted under the parrot organization imply need for a CLA or anything?  I figured it was just a convenience for parrot committers...
20:30 whiteknight Tene: That's a very good question. I suspect we could create a new group of HLL developers who don't have write access to the Parrot repo
20:30 whiteknight Let's worry about that later. I'll do some research.
20:30 whiteknight right now Hackbinary can create a fork and start making patches
20:31 Tene whiteknight: It's been valuable to me to freely give out commit privs to cardinal in the past, and I'd like that to continue.
20:31 whiteknight Tene: yes, I agree with you. I will figure this out one way or another
20:32 cotto_work #ps in now
20:32 Tene I admit to ignorance of how github organizations work.
20:32 whiteknight Tene: Each organization has teams. Each team has a set of permissions and a list of repos
20:32 whiteknight so I think we can create a team for cardinal developers, or a team for HLL developers in general
20:33 whiteknight Tene: Also, you could have a semi-official fork of your own, and grant out privs to that. Then, we can pull changes into the parrot org
20:33 whiteknight there are lots of things we can look at
20:33 nwellnhof Util: i'd love to have a look at those Coverity reports
20:33 Tene Sure.
20:34 nwellnhof Rakudo spectest: PASS on nwellnhof/gc_dynamic_threshold
20:34 pmichaud nwellnhof ++
20:37 nwellnhof gc-2.p6 on nwellnhof/gc_dynamic_threshold: https://gist.github.com/806603
20:38 nwellnhof i was wrong about TOTAL_MEM_ALLOCATED being monotonically increasing. string buffers are returned actually.
20:38 chromatic That uses a fraction of the memory.
20:38 pmichaud that's a heck of a lot smaller memory usage
20:38 nwellnhof yes, that's because of the 1/8 of sysmem GC threshold.
20:38 pmichaud ah
20:38 Util nwellnhof: private msg
20:38 pmichaud and you have less memory than I, I suspect
20:38 pmichaud I'll check out the branch and give it a try
20:39 nwellnhof pmichaud: no the dynamic threshold isn't based on sysmem anymore.
20:39 pmichaud oh
20:39 pmichaud okay, maybe I'll wait for a merge
20:47 Hackbinary tene: that's my stuff up into github.com/hackbinary/cardinal
20:49 Hackbinary tene: now 525 of 609 tests passed; was at 497 of 603
20:49 Tene Hackbinary: That's great.  What did you work on?
20:49 Tene (bit too busy to read commit log ATM)
20:51 Hackbinary tene: np, fixed the else clause in actions.pm; added get_bool to Integer.pir, String.pir, Object.pir to return true
20:51 Hackbinary and a get_bool for  NilType.pir to return 0
20:51 tadzik I'd like to see that
20:52 Hackbinary I also added 6 tests to 01-stmts.t
20:58 pmichaud NotFound: I'm not claiming that PCT is the only way to do it.
20:59 pmichaud IMCC does not make for a robust enough infrastructure for writing, say Tcl or APL or Python without a *lot* of work
20:59 pmichaud a higher level toolchain of some sort is needed
20:59 NotFound pmichaud: it will be, if people keeps going towards generating pbc from POST as the only reasonable way.
20:59 whiteknight We need a language to replace IMCC for low-level stuff and bootstrapping. We need a language for writing HLL compilers and compiler tools. I see no reason why these have to be the same language
21:00 pmichaud whiteknight: they don't.  I don't think that was being claimed.
21:00 whiteknight Right. I'm just trying to be very clear. We've all been doing a lot of talking over and around each other in the past two days
21:00 pmichaud fairy nuff.
21:01 whiteknight if our internal, self-maintained, IMCC replacement language is some kind of copy/fork of NQP, I'm fine with that
21:01 whiteknight if our language for writing compilers tools is some kind of copy/fork of NQP, I'm fine with that too
21:01 whiteknight actually, for the former I would probably prefer a fork that we maintain ourselves
21:02 whiteknight for the later, maybe we can be a little bit more hands-off
21:03 whiteknight but then it doesn't make a lot of sense to be mixing versions of NQP
21:04 chromatic That's the problem.
21:04 chromatic Oh, and ops2c relies on NQP.
21:04 cotto_work My apprehension centers around two things; First, pmichaud is better at maintaining nqp (any flavor) than we. Second, I don't want subtly-incompatible versions of nqp floating around.
21:05 whiteknight so maybe that's it. We need a language that we can maintain, but we don't want to maintain NQP
21:05 whiteknight so, let's draw a line in the sand. NQP is the de facto standard language for building compilers. We tell everybody to use NQP for that purpose
21:05 cotto_work We need something stable.  If someone else maintains it (and we have a channel to contribute fixes, etc), that's fine.
21:06 whiteknight internally, we use PIR (assuming PIRATE and improved syntax/features), or something like Winxed
21:06 chromatic If someone else maintains it out of tree, I'm not sure it's stable.
21:06 whiteknight maintains what out of tree?
21:07 chromatic I was responding to cotto.
21:07 whiteknight oh, sorry
21:08 dalek TT #1994 created by pmichaud++: interpinfo TOTAL_PMCS and ACTIVE_PMCS no longer work in 3.0.0
21:08 dalek TT #1994: http://trac.parrot.org/parrot/ticket/1994
21:13 plobsing joined #parrot
21:14 Hackbinary should there not be branches for stable, development and experimental of the NQP?  With solutions being migrated from experimental through development to stable as appropriate?
21:15 cotto_work pmichaud: what's going to break on nqp that works with nqp?  Will it be an issue of adding use Parrot; and deleting implementations of functions that will provided by the setting?
21:16 pmichaud cotto_work: I think so, yes.
21:16 pmichaud I don't expect much to break quickly.
21:16 cotto_work "quickly"?
21:16 pmichaud We'll undoubtedly provide some deprecation points as we evolve
21:17 pmichaud for example, I expect the new nqp will continue to support pir:: even without "use Parrot;" for a short time into the future
21:17 pmichaud nqp-nom (the new nqp)  is far more an evolution of nqp-rx than a rewrite
21:17 pmichaud it's just we had to break the underlying object model code in order to use 6model
21:17 cotto_work that's my understanding
21:17 chromatic left #parrot
21:18 pmichaud I think it will be very telling to see how something like, say, ops2c works under the new nqp
21:18 cotto_work I know that it's keeping the same test suite as nqp-rx
21:18 pmichaud I'd even be willing to make it a goal to keep that running for a while
21:18 cotto_work That'd be helpful.
21:18 dalek winxed: r767 | NotFound++ | trunk/winxedst1.winxed:
21:18 dalek winxed: generate .const 'Sub' from using when the function is defined in the current
21:19 dalek winxed: compilation
21:19 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=767
21:19 pmichaud I mean, we depend on ops2c pretty heavily too :)
21:19 pmichaud since we have custom dynops
21:19 pmichaud Hackbinary: I'm certain that nqp will move to a more regular release/deprecation cycle, yes.
21:19 cotto_work a deprecation policy like what Parrot tries to do (notify, provide a period when old and new work, etc) would help also
21:20 pmichaud until now nqp was really following under parrot for much of that.  in the future we'll need our own.
21:20 dukeleto looks like i missed #ps
21:20 cotto_work were you on the concall?
21:20 pmichaud originally I started nqp-rx expecting to do "monthly releases", but I found that there wasn't much purpose to it with the way it ended up being packaged in parrot.
21:20 pmichaud I'm sure it will be different going forward.
21:21 cotto_work is PaFo getting bought out?  Are my shares worth millions?
21:22 dalek parrot/nwellnhof/gc_dynamic_threshold: 00d27fb | nwellnhof++ | / (3 files):
21:22 dalek parrot/nwellnhof/gc_dynamic_threshold: Work around GC problem in embed API
21:22 dalek parrot/nwellnhof/gc_dynamic_threshold: review: https://github.com/parrot/parrot/commit/00d27fbb3d
21:22 dalek parrot/nwellnhof/gc_dynamic_threshold: 017627f | nwellnhof++ | / (5 files):
21:22 dalek parrot/nwellnhof/gc_dynamic_threshold: Add TOTAL_MEM_USED to interpinfo
21:22 dalek parrot/nwellnhof/gc_dynamic_threshold: review: https://github.com/parrot/parrot/commit/017627fbf9
21:27 Andy left #parrot
21:27 KaeseEs "Winxed has three native datatypes: int, float, string and var. "
21:30 whiteknight left #parrot
21:30 tadzik and is subject to the banana problem
21:30 dukeleto cotto_work: yes, i was on the conf call
21:31 cotto_work anything surprising?
21:31 dukeleto cotto_work: we are close to having our ducks in a row to submit stuff to the IRS to regain non-profit status
21:31 dukeleto cotto_work: not really
21:31 cotto_work That's a good place to be unsurprised.
21:31 dukeleto cotto_work: particle owes us a bio, and we are going to tar and feather him if he doesn't send it in today
21:32 pmichaud particle can be the new mascot?  ;-)
21:32 pmichaud colored feathers, I hope!
21:32 dukeleto We have to reverse engineer financial data from Quickbooks, and nobody uses windows, except particle .
21:33 cotto_work "particle is a pretty cool guy.  eh uses windows and doesn't afraid of anything"
21:33 cotto_work done
21:34 ilia joined #parrot
21:36 dalek parrot: efd80f0 | NotFound++ | tools/dev/show_deprecated.pl:
21:36 dalek parrot: show something meaningful for deprecation notices without eligible or ticket fields
21:36 dalek parrot: review: https://github.com/parrot/parrot/commit/efd80f03b4
21:37 NotFound KaeseEs: what's the problem?
21:37 cotto_work 3 != 4
21:37 NotFound Uh :D
21:38 NotFound There are three kinds of people: able to count and unable to count.
21:41 plobsing left #parrot
21:41 KaeseEs NotFound: there are only two really hard problems in computer science: cache invalidation, naming things and off-by-one errors :V
21:41 cotto_work KaeseEs++
21:42 nwellnhof lol
21:42 fperrad left #parrot
21:47 KaeseEs noob question: i want to test Parrot_hires_get_time(), which lives in src/platform/generic/hires_timer.c and has its prototype in include/platform/platform_interface.h .  when i write a quick test program to fiddle with it, gcc blows up when it encounters UHUGEINTVAL, which is defined in /include/parrot/config.h.  is there an easymode solution to this?
21:50 cotto_work It shouldn't blow up.  Can you nopaste what you're seeing?
21:57 rurban_ joined #parrot
21:57 nopaste "KaeseEs" at 192.168.1.3 pasted "In file included from include/" (63 lines) at http://nopaste.snit.ch/29968
21:59 NotFound KaeseEs: fixed, thanks.
21:59 cotto_work KaeseEs: it's probably an error in your code.  Can you nopaste that?
21:59 cotto_work notice the first few lines
22:00 rurban left #parrot
22:00 rurban_ is now known as rurban
22:00 KaeseEs http://pastebin.com/KX1Fu3MZ
22:03 NotFound BTW int main(void) is wrong, please don't contribute to keep that mistake alive.
22:03 tadzik main(void) is usually "I'm lazy"
22:04 NotFound tadzik: writing four letters is more lazy than none?
22:04 wknight-phone joined #parrot
22:05 tadzik ah, you mean any fun(void) is wrong?
22:06 tadzik I thought that's the old way to do it
22:06 KaeseEs NotFound: comp.lang.c faq says int main(void) is one of the 2 valid declarations of main in c89.  does parrot use c99?
22:07 AndroUser2 joined #parrot
22:09 NotFound Last time I checked the strict valid ones were () and (argc, argv)
22:09 KaeseEs (or are you referring to the use of void to indicate a function takes no arguments being one of the abominations created by the C standardization process)
22:09 wknight-phone left #parrot
22:09 KaeseEs NotFound: see section 5.1.2.2.1 in the iso standard http://www.open-std.org/jtc1/​sc22/wg14/www/docs/n1539.pdf
22:12 AndroUser2 standards. blah
22:14 AndroUser2 is now known as wknight-phone
22:14 NotFound Sorry, maybe I was thinking in C++
22:14 wknight-phone c++, double blah
22:16 KaeseEs i like that you gave c a karma point and decried its misbegotten offspring in the same statement
22:16 tadzik makes C bigger, but returs the old value
22:17 wknight-phone :)
22:18 mtk left #parrot
22:22 dalek parrot: 2cdf5dd | nwellnhof++ | / (2 files):
22:22 dalek parrot: Add some debug output to IPv6 test
22:22 dalek parrot: review: https://github.com/parrot/parrot/commit/2cdf5dd565
22:24 mtk joined #parrot
22:24 Coke Didn't particle submit a bio a year ago?
22:25 Coke ... but I don't have it gmail.
22:26 particle it's coming in like 3 minutes
22:26 KaeseEs well, i feel like a doofus.  adding parrot/parrot.h to my includes resolved all the compiler errors, and only left the linker error that ld can't find clock_gettime.  despite it being in libc.
22:29 wknight-phone KaeseEs, what are you working on?
22:31 dalek plparrot: f4a80b1 | theory++ | pgtap.sql:
22:31 dalek plparrot: Update pgTAP URL.
22:31 dalek plparrot: review: https://github.com/leto/plparrot/commit/f4a80b1328
22:33 KaeseEs wknight-phone: quickie program to test Parrot_hires_get_time() to see if might be a workable way to do precise timing for a metronome-like rt collector
22:33 cotto_work KaeseEs: it's not guaranteed to provide a minimum resolution.
22:34 nwellnhof KaeseEs: doesn't metronome use read barriers?
22:35 particle for all of you interested in my tardiness, my bio has been sent :P
22:35 NotFound From the linux man page: NOTES Most systems require the program be linked with the  librt  library  to use these functions.
22:35 KaeseEs nwellnhof: unsure, I've only glossed through most of bacon's stuff so far
22:36 KaeseEs NotFound: gah I didn't see that, thanks
22:36 pmichaud particle: awwww, no tar and feathers?
22:37 particle tar and feather me anyway, i'm ready to party!
22:37 pmichaud :-P
22:37 Hackbinary I'll bring the whiskey
22:39 wknight-phone left #parrot
22:41 ilia left #parrot
22:53 dalek parrot/generational_gc: 515bf97 | bacek++ | src/gc/gc_gms.c:
22:53 dalek parrot/generational_gc: Reimplement check_sanity
22:53 dalek parrot/generational_gc: review: https://github.com/parrot/parrot/commit/515bf97409
22:55 vmspb left #parrot
23:06 dalek TT #721 closed by pmichaud++: PGE::P5Regex consumes all memory
23:06 dalek TT #721: http://trac.parrot.org/parrot/ticket/721
23:06 dalek TT #843 closed by pmichaud++: PGE will assume {*} at end of every regex
23:06 dalek TT #843: http://trac.parrot.org/parrot/ticket/843
23:06 dalek TT #851 closed by pmichaud++: [DEPRECATED]  .find_key method on PGE;Match objects
23:06 dalek TT #851: http://trac.parrot.org/parrot/ticket/851
23:06 dalek TT #1017 closed by pmichaud++: recognize the  form of alternation
23:06 dalek TT #1017: http://trac.parrot.org/parrot/ticket/1017
23:06 dalek TT #1037 closed by pmichaud++: throw useful exception on non-quoted non-word characters in PGE
23:06 dalek TT #1037: http://trac.parrot.org/parrot/ticket/1037
23:06 dalek TT #1042 closed by pmichaud++: PGE doesn't support angle quotes inside of regexes.
23:06 dalek TT #1042: http://trac.parrot.org/parrot/ticket/1042
23:06 dalek TT #1065 closed by pmichaud++: PGE should emit inline PIR with Grammar namespace
23:06 dalek TT #1065: http://trac.parrot.org/parrot/ticket/1065
23:09 dukeleto KaeseEs: including parrot/parrot.h is bad juju
23:09 dukeleto KaeseEs: best to include the actual headers that you need
23:09 dukeleto KaeseEs: parrot/parrot.h is the internal api and can change at any time
23:10 cotto_work those tickets are dropping like flies
23:10 dukeleto KaeseEs: if it is a one-off program, that is fine, but if you want to maintain the code, don't use parrot/parrot.h
23:10 cotto_work I'm happy.
23:11 Hackbinary +1
23:12 KaeseEs dukeleto: will keep in mind.
23:18 dalek parrot: a35f817 | nwellnhof++ | / (5 files):
23:18 dalek parrot: Remove support for deprecated charset:encoding:"" literals
23:18 dalek parrot:
23:18 dalek parrot: TT #1808
23:18 dalek parrot: review: https://github.com/parrot/parrot/commit/a35f817a34
23:23 dalek TT #1163 closed by pmichaud++: PGE: refactor pod_comment rule into PGE/Util.pbc
23:23 dalek TT #1163: http://trac.parrot.org/parrot/ticket/1163
23:23 dalek TT #329 closed by pmichaud++: [PATCH] save compiler filename in PCT::HLLCompiler
23:23 dalek TT #329: http://trac.parrot.org/parrot/ticket/329
23:23 dalek TT #466 closed by pmichaud++: PAST::Val.new( :value( ~$/ ), :returns('Complex')) generates incorrect pir
23:23 dalek TT #466: http://trac.parrot.org/parrot/ticket/466
23:23 dalek TT #1808 closed by nwellnhof++: PIR string literals with charset and encoding are deprecated
23:23 dalek TT #1808: http://trac.parrot.org/parrot/ticket/1808
23:26 kid51 joined #parrot
23:30 dalek parrot: 693ddea | pmichaud++ | compilers/pct/src/POST/Node.pir:
23:30 dalek parrot: [pct]:  TT #821 -- Allow POST::Sub to handle parameters :slurpy + :optional and :slurpy + :named + :optional (by treating them as though :optional is not present, as recommended in the ticket).
23:30 dalek parrot: review: https://github.com/parrot/parrot/commit/693ddea46e
23:30 dalek parrot: d774533 | pmichaud++ | / (5 files):
23:30 dalek parrot: Merge branch 'master' of github.com:parrot/parrot
23:30 dalek parrot: review: https://github.com/parrot/parrot/commit/d77453355e
23:31 plobsing joined #parrot
23:40 tcurtis left #parrot
23:40 dalek TT #1882 closed by nwellnhof++: gethostbyname failure doesn't throw an exception
23:40 dalek TT #1882: http://trac.parrot.org/parrot/ticket/1882
23:40 dalek TT #821 closed by pmichaud++: PCT - POST::Sub::add_param() ignores +optional+slurpy parameters.
23:40 dalek TT #821: http://trac.parrot.org/parrot/ticket/821
23:40 dalek TT #868 closed by pmichaud++: DEPRECATE generation of PAST::Val constants
23:40 dalek TT #868: http://trac.parrot.org/parrot/ticket/868
23:40 dalek TT #1198 closed by pmichaud++: interactive mode doesn't save lexicals correctly
23:40 dalek TT #1198: http://trac.parrot.org/parrot/ticket/1198
23:40 dalek TT #1179 closed by nwellnhof++: Test open file, close file, delete file, reopen previously opened stream
23:40 dalek TT #1179: http://trac.parrot.org/parrot/ticket/1179
23:40 dalek TT #1625 closed by pmichaud++: PCT generates usage message too early
23:40 dalek TT #1625: http://trac.parrot.org/parrot/ticket/1625
23:43 pmichaud Resolved 14 tickets.  :-)
23:43 pmichaud Added one new ticket earlier today, which makes my total for the day of -13
23:45 cotto_work pmichaud++
23:45 pmichaud So, we're down to 530 tickets.
23:45 dalek winxed: r768 | NotFound++ | trunk/winxedst1.winxed:
23:45 dalek winxed: refactor command line option handling and activate the option --noan in stage 1
23:45 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=768
23:50 pmichaud closed #589, so -14
23:51 kid51 is now known as kid51_at_dinner
23:51 whiteknight joined #parrot
23:53 cotto_work I haven't even had a chance to get in on the action.
23:53 cotto_work If this keeps up we'll hit 500 by the weekend.
23:54 pmichaud #1993 needs fixing soon -- it causes test failures on my system
23:54 whiteknight ...too...many....ticket....emails.....
23:54 * whiteknight has seizure
23:54 pmichaud i.e., "make test" doesn't pass on my system
23:56 cosimo joined #parrot
23:57 dalek TT #589 closed by pmichaud++: PGE Longest token match
23:57 dalek TT #589: http://trac.parrot.org/parrot/ticket/589
23:59 dalek parrot/yaml-fix: 0ed38ee | cotto++ | t/tools/show_ (2 files):
23:59 dalek parrot/yaml-fix: add patch from doughera++ to start fixing the yaml tests on systems with the required perl modules installed
23:59 dalek parrot/yaml-fix: review: https://github.com/parrot/parrot/commit/0ed38ee5ca

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

Parrot | source cross referenced