Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures | Test imcc_interfaces and annotations-tree branches
Set by moderator on 31 January 2011.
whiteknight maybe also an assembler 00:01
we need a low-level language that compiles directly to pbc
if that's winxed, we can use that
NotFound_b whiteknight: I think that will be good to have one bytecode generating backend... if all tools use it.
cotto_work what pasm thought it was
whiteknight right, minus the shittiness of PASM and PIR 00:02
If NQP compiles right down to PBC, that's fine. If Winxed, we can use that
if something else, let's start designing it
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.
chromatic Which NQP?
bacek_at_work whiteknight, it's called POST 00:03
whiteknight right, but Winxed can't really use POST (yet)
maybe stage-1 Winxed can
NotFound_b whiteknight: maybe, but there isn't any proof of that yet.
whiteknight right
cotto_work NotFound_b: I'm not suggesting we use PASM, but that we're implementing what PASM was intended to be.
whiteknight chromatic: any NQP 00:04
chromatic If we're forking an NQP to live in the Parrot repo, we should change its name.
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
er, other VMs
What I don't like about NQP is the pervasive use of lexical variables and the requisite bookkeeping for them 00:05
I would prefer a Parrot system language not do anything like that unless asked
chromatic I hope the interop layer will be thinner, but in the absence of evidence....
Tene whiteknight: you'd prefer a parrot system langauge to not have lexical variables? o.O
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
PIR has lexicals, but you have to use them explicitly
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?
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
bacek_at_work because most of this bloat can be optimized-out
whiteknight I would rather not generate it in the first place, but that's sort of a moot point 00:09
chromatic What's your thinking here, cotto_work? 00:10
cotto_work chromatic: which point? lexicals? 00:11
chromatic PCT
cotto_work I need to think about it before I can give a good answer. 00:12
00:14 plobsing joined 00:18 kid51 joined
whiteknight blarg. so much to think about 00:22
bacek_at_work yes.
cotto_work indeed
bacek_at_work M0, M1, MOP, GC 00:23
it's what must be in core.
cotto_work what lives where, who cares, who needs to, who's responsible
bacek_at_work "some tool to generate M1" - should be in core.
"some tool to generate input for previous one" - very-very questionable. 00:24
"Bundling all required tools to develop with parrot" - definitely yes.
Look from "end user" point of view.
cotto_work I guess PCT depends on whether we feel like we can define and stick with a stable interface between layers.
bacek_at_work Who cares who developed PCT? 00:25
chromatic The people who have to support it.
bacek_at_work If after downloading tarball I (as HLL dev) will have all tools to develop my HLL
chromatic, I implemented support for :multi and vtable in nqp-rx. 00:26
NotFound_b "some tool to generate M1" -> A M1 assembler?
bacek_at_work I developed nqp-setting (mostly)
I don't see any problems with supporting PCT/nqp/whatever as parrot developer.
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.
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
or alternate grammars, which is fun to think about, but ultimately not great for us
00:30 Kapace joined
bacek_at_work chromatic, I'm not going to. 00:30
chromatic I have a problem with that.
bacek_at_work Sigh... 00:31
what is the problem?
It's up for "nqp-to-vm-compatibility-layer". 00:32
For parrot this layer will be thin (at least for :multi and :vtable)
For JVM/CLR - I don't care at all.
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.
bacek_at_work No
Not at all.
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.
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, irclog.perlgeek.de/parrot/2011-01-31#i_3239879
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?
16:23 <@pmichaud> not meeting nqp's goals, definitely.
bacek_at_work chromatic, pmichaud said totally opposite.
irclog.perlgeek.de/parrot/2011-01-31#i_3239896 00:36
chromatic I'm sure pmichaud doesn't want to sprinkle Parrot-specific code throughout Rakudo.
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.
bacek_at_work "switching grammar ... with the VM specific features"
chromatic, who is talking about rakudo?
chromatic Presumably, the people maintaining the new NQP want to use it to produce Rakudo. 00:37
bacek_at_work afk # meeting
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.
pmichaud Those would be available behind a "use Parrot;" pragma or the like.
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.
pmichaud for someone who is developing Parrot tools, that's presumably not an issue.
cotto_work chromatic: exactly
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.
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.
In the meantime ... 00:41
pmichaud it's not about making some watered-down language that runs exactly the same everywhere.
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
Tene 16:20 <@pmichaud> I know that Rakudo will. 00:41
You already said as much, more than once.
pmichaud yes, thanks for noticing.
Tene erm, I missed a line.
pmichaud (and for saving me the trouble of pasting what I already wrote :)
chromatic To use continuations in Rakudo with new NQP then you have the equivalent of an #ifdef for each different platform semantic? 00:42
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:43
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.
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
We just haven't implemented the "use Parrot;" requirement yet.
cotto_work I'd expect "use Parrot;" to fail on a backend that didn't support it. 00:47
chromatic Wow.
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.
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"?
pmichaud That was definitely a stop-gap measure. The pir:: functional interface is far easier to implement.
chromatic The latter, Tene.
pmichaud s/implement/emulate/
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"?
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.
It's like having libraries that give access to Windows-specific or Linux-specific features.
cotto_work pmichaud: exactly
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.
that's where individual implementations have some room outside of the Perl 6 spec, I think. 00:52
cotto_work decommutes 00:53
chromatic I hope it works out. 00:54
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
chromatic I'm not implementing it, so I decline to give any other opinion on the subject.
PerlJam fair enough 00:57
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:03
Tene Ahh, I missed this: 01:04
"<chromatic> ... and emulates PArrot semantics when running on other backends?" -- "<@pmichaud> if an application needs those Parrot semantics, then yes." 01:05
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:07
Regex and grammar support being an obvious example. 01:08
Tene That makes a lot more sense, yes.
sorear bacek_at_work: To what extent do you want all HLLs to generate POST?
Tene I would be very surprised if "use Parrot;" did anything but fail on other VMs.
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.
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
(except through libraries or well-defined compatibility APIs)
s/are/aren't/ 01:10
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:11
dalek nxed: r764 | NotFound++ | trunk/winxedst1.winxed:
replace some usages of Emiter say with emitbinop
 01:12
pmichaud I am? 01:14
chromatic Aren't you, if you want to use them from NQP in Rakudo?
pmichaud junctions won't be in NQP
that's already pretty much a Rakudo-specific implementation
many of those features are already handled by virtue of 6model 01:15
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.
pmichaud I expect to be able to use NQP to implement them, but I don't expect NQP to natively provide them.
chromatic It was one of my goals.
pmichaud if Parrot offers laziness, then we'll undoubtedly find ways to optimize Rakudo to use them when they're present. 01:17
but that doesn't mean we expect to require it of every backend.
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:19
coroutines would be a notable exception in that list -- clearly Parrot has helped us a lot there for handling given/when 01:20
sorry, gather/take
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"?
pmichaud I think so, yes. 01:21
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
that's clearly a language designer choice
01:26 cosimo left
chromatic I see. 01:26
01:27 kid51_at_dinner left
pmichaud afk, dinner 01:28
01:29 NotFound_b left
cotto ~~ 01:51
atrodo I wish $dayjob wasn't so demanding today, looks like a lot of good chatting happened 01:54
plobsing yes, seems we had an exciting day 01:55
01:57 Kristaba left
cotto good concusions too 02:00
conclusions
I think we agree to agree, for the most part 02:01
chromatic How so?
plobsing I agree with the conclusions. What are they? 02:03
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
working out, so sorry for typos or disjointedness
typing on an exercise bike does not seem to be my laptop's intended use case 02:06
chromatic Any thoughts on bundling versus forking NQP or creating something new? 02:08
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:09
chromatic Okay. 02:10
cotto (the "use Parrot;" pieces, not the layer that's at the same level as the3 cli code
how does that sound to you?
if we can assume a stable or at least reasonable interface for building the vm-specific bits, I think it'll be workable 02:11
02:16 whiteknight left 02:30 bubaflub joined, bubaflub left 02:43 bluescreen left
pmichaud does anyone know how I can get my new journal added to Planet Parrot? pmthium.com/category/parrot/ 03:57
sorear pmichaud: there's a contact link 04:03
it points at "webmaster at perl.org"
bacek_at_work pmichaud, (side question) can I have $/ in nqp(-rx)? 04:24
pmichaud bacek_at_work: what for? 04:25
bacek_at_work: you mean as an automatically declared lexical?
bacek_at_work pmichaud, for ~~
pmichaud setting of $/ isn't really part of ~~
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.
bacek_at_work oh. 04:26
aloha, S05?
aloha bacek_at_work: No clue. Sorry.
bacek_at_work stupid girl
pmichaud but you can do: my $/ := 'something' ~~ /pattern/; and you get much the same effect.
bacek_at_work pmichaud, I did it in YAML::Tiny
github.com/parrot/yaml-tiny/blob/4...ML/Tiny.pm 04:27
pmichaud I don't see a $/ in YAML::Tiny
bacek_at_work it's called $m 04:28
line 240 for example
pmichaud oh yes, that works too.
bacek_at_work aloha, S05 is perlcabal.org/syn/S05.html
aloha bacek_at_work: Okay.
pmichaud anyway, it's perfectly legal to declare $/ as a lexical and then use it.
bacek_at_work pmichaud, but I would like to see less noise :)
pmichaud I'm not quite ready to make it "automatic" in nqp yet.... even $_ isn't automatic except in for loops.
bacek_at_work ah. ok. 04:29
pmichaud and I'd really like to see the Perl 6 spec solidify on it first :)
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 $/.
What's wrong with it??? 04:30
pmichaud we don't yet know how .match gets access to $/ to set it 04:31
more to the point, if I have something like
$x.subst( /(pattern)/, { $0 - 1 } ) 04:32
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.
so $/ isn't purely a lexical -- it sometimes acts more like a dynamic variable
04:48 adu joined
adu hi 04:48
dukeleto adu: hola 04:54
adu how goes?
dukeleto adu: pretty well. welcome to #parrot 04:55
adu thanks :)
dukeleto adu: what brings you around these parts?
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:56
04:58 freeksh0w86 joined
dukeleto adu: welcome back 04:58
adu: what do you use to profile?
adu: perhaps you can try it on 3.0, our latest stable release
adu "leaks" (macosx)
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
mac has this thing called "verbose malloc" 05:00
dukeleto adu: well, memory leak info would be fantastic
adu well, I'm also writing a parser for Go 05:01
and wondering what to do with it once the parser is done
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
bah, humbug, I'm just a dreamer
ignore me
such a system would have massive documentation requirements, pulling docstrings from python/perldoc, the inconsistencies might be too much 05:06
I think parrot is on the right track 05:10
dukeleto: are you into webapps? 05:18
sorear adu: have you looked at Fly?
adu what's fly? 05:19
are you talking about www.criticalsecurity.net/index.php/...e__st__200 05:22
can you give me a URL? 05:23
dukeleto adu: i am very familiar with them, yes 05:29
adu: Go on Parrot sounds fun, no one has tried that, as far as I know
adu well, Go already requires some extra runtime, so it makes sense to use an existing runtime 05:30
for example, type-switch 05:31
sorear Fly was "how Parrot goes" 05:32
but I can't find a link
googling for parrot go fly isn't exactly helping
and it's not on the tracwiki Languages page
adu ah, you mean async calls? 05:33
sorear no 05:34
adu what do you mean?
sorear "Fly" was the name of the Go on Parrot implementation
05:37 diakopter joined
adu i found this: groups.google.com/group/golang-nut...b255d07c98 05:38
diakopter as in, "parrot go fly"
sorear: do you have an URL for "Fly"? 05:40
oh
adu diakopter: apparently not
diakopter nm I see in the log you didn't find it
cotto seen jvd 05:41
aloha Sorry, I haven't seen jvd.
diakopter irclog.perlgeek.de/parrotsketch/201...#i_2343784
Fly reference ^^
05:42 allison left
cotto does anyone care to clean up trac.parrot.org/parrot/wiki/MakeEveryPMCAnObject ? 05:43
adu i need to find this tcurtis guy 05:44
cotto figures he should probably do his own job 05:45
adu anyways, if someone is reading this conversation a year from now, I should probably post a link to my implementation 05:48
hackage.haskell.org/package/language-go
but I'm pretty sure I'm not going to call the compiler Fly, probably "dsgo" 05:51
05:56 rurban_ joined
dukeleto adu: tcurtis was a gsoc student, who wrote the tree-optimization library, but seems to be busy with school these days 05:56
06:00 rurban left, rurban_ is now known as rurban
adu hopefully well cross paths someday 06:00
06:06 particle1 joined 06:09 particle left, chromatic left
dalek tracwiki: v5 | cotto++ | MakeEveryPMCAnObject 06:29
tracwiki: most of these changes are rejected, but primarly because they'll be accomplished through M0 and 6model, not because they're bad ideas
tracwiki: trac.parrot.org/parrot/wiki/MakeEve...ction=diff
TT #1020 closed by cotto++: subclassing pmc from pir + lot more 06:34
TT #1020: trac.parrot.org/parrot/ticket/1020
sorear diakopter: what brings you here. 06:38
06:50 mtk left
diakopter sorear: :P 06:55
06:55 diakopter left, mtk joined 07:08 theory left 07:25 fperrad joined 08:10 allison joined 08:52 contingencyplan left 08:55 hudnix left 09:41 adu left 10:07 kid51 joined
dalek rrot/generational_gc: 7cb3dca | bacek++ | include/parrot/pobj.h:
Remove unused PObj_aligned_FLAG
 10:31
rrot/generational_gc: 49afb77 | bacek++ | src/gc/gc_gms.c:
Remove old idea about implementation of GenGC. Create stub for new one.
rrot/generational_gc: 31347e6 | bacek++ | src/gc/gc_gms.c:
Flash out new (fsvo) Generational GC algorithm without magic.
 11:00
bacek msg whiteknight Here we go! github.com/parrot/parrot/commit/31347e6389 11:01
aloha OK. I'll deliver the message.
dalek rrot/generational_gc: e85bb43 | bacek++ | src/gc/gc_gms.c:
Remove usage of GC_gen_2 flag.
 11:58
rrot/generational_gc: 3ce2d8a | bacek++ | include/parrot/pobj.h:
Add GC_on_dirty_list flag.
rrot/generational_gc: 18f0362 | bacek++ | include/parrot/pobj.h:
Remove unused GC_ref_* flags.
Coke msg pmichaud I can add your blog to parrot, but I need an RSS url that manages the category - pmthium.com/category/parrot/ is HTML. 12:16
aloha OK. I'll deliver the message.
dalek rrot/generational_gc: c1ea3e4 | bacek++ | src/gc/gc_gms.c:
"The earth shall rise on new foundations" commit. Break GMS totally
 12:31
bacek Coke, pmthium.com/category/parrot/feed/ 12:32
Coke bacek: IME, that will have everything, but OK, I'll try it. ;) 12:40
bacek Coke, no, this is for "parrot" only. 12:41
I checked it :)
Coke there's only one entry on his blog. hard to tell going forward. but done. 12:43
msg pmichaud never mind, bacek got the URL - added. 12:44
aloha OK. I'll deliver the message.
12:57 kid51 left 13:28 wknight-phone joined 13:36 wknight-phone left
dalek rrot/generational_gc: 1731594 | bacek++ | src/gc/gc_gms.c:
Unbreak GMS little bit: cleanup declarations, replace Linked_List with
 13:36
rrot/generational_gc: 412be2f | bacek++ | src/gc/gc_gms.c:
Fix pmc alloc/free.
rrot/generational_gc: 592f07d | bacek++ | src/gc/gc_gms.c:
Fix STRING alloc/free.
rrot/generational_gc: e296fc9 | bacek++ | src/gc/gc_gms.c:
Remove unused helper. We'll use Pointer_Array macro instead.
rrot/generational_gc: 2946e7d | bacek++ | src/gc/gc_gms.c:
Remove unused helper for sweeping pools.
rrot/generational_gc: e01ac98 | bacek++ | src/gc/gc_ (2 files):
Change mark_pobj_header to mark_str_header to keep in line with Modern Parrot.
rrot/generational_gc: 9abb367 | bacek++ | src/gc/gc_gms.c:
Factor out unseal_object helper.
rrot/generational_gc: 6214375 | bacek++ | src/gc/gc_gms.c:
Fix is_ptr_owned
rrot/generational_gc: edb47fb | bacek++ | src/gc/gc_gms.c:
Rewrite write_barrier according to new design.
rrot/generational_gc: 81be312 | bacek++ | src/gc/gc_gms.c:
Remove pobj2gen and gen2flags functions. They are not used anymore.
rrot/generational_gc: a110762 | bacek++ | src/gc/gc_gms.c:
Comment out (temporary) statistic calculation functions.
rrot/generational_gc: 13aa2d5 | bacek++ | src/gc/gc_gms.c:
Comment out validation functions. We will need new versions anyway, but keep
rrot/generational_gc: 5888e37 | bacek++ | src/gc/gc_gms.c:
Fix copy-paste error in is_string_ptr
13:41 hudnix joined
dalek rrot/generational_gc: ab43498 | bacek++ | src/gc/gc_gms.c:
Limit number of collected generations. We have only MAX_COLLECTIONS of them.
 13:47
rrot/generational_gc: 71d28f1 | bacek++ | src/gc/gc_gms.c:
Rename MAX_COLLECTIONS to MAX_GENERATIONS to reflect reality.
13:55 rurban_ joined 14:00 rurban left, rurban_ is now known as rurban 14:02 whiteknight joined, fperrad left 14:06 adu joined
whiteknight good morning, #parrot 14:06
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.
bacek whiteknight, it's mostly done :)
dalek rrot/generational_gc: 148c96b | bacek++ | src/gc/gc_gms.c:
Implement cleanup_dirty_list
rrot/generational_gc: 04351d3 | bacek++ | src/gc/gc_gms.c:
Replace asserts with ifs in write_barrier. We trigger them unconditionally in
whiteknight the new algorithm?
rrot/generational_gc: 7f9ec09 | bacek++ | src/gc/gc_gms.c:
Implement first cut of sweep_pools
whiteknight bacek: Do we need to insert write barriers for this system? 14:11
because that's going to take a long time to do. We need to check every file
bacek whiteknight, yes, we do
whiteknight, it's done already
whiteknight in the branch? 14:12
bacek yes
whiteknight ok
bacek and we don't have to "check every single file"
just few of them
whiteknight how is it implemented, vtables?
bacek yes
whiteknight okay
14:12 plobsing left
dalek rrot/generational_gc: 292bb8e | bacek++ | / (3 files):
Add .count to Pointer_Array in debug mode
 14:15
rrot/generational_gc: 25857f3 | bacek++ | src/gc/gc_gms.c:
Enable more stats
rrot/generational_gc: 1b24ec7 | bacek++ | src/gc/gc_gms.c:
Erm. Remove object from original list before promoting into new one.
14:31 hudnix left 14:32 bluescreen joined 14:36 hudnix joined
whiteknight bacek++ 14:36
you're doing great work on this
14:38 plobsing joined 14:41 adu left
Coke he's certainly doing a lot of work on this. ;) 14:50
15:05 fperrad joined 15:07 PerlJam left, PerlJam joined
dalek nxed: r765 | NotFound++ | trunk/winxedst1.winxed:
fix and rearrange allocation of temporary registers in stage 1
 15:11
15:12 Andy left 15:16 bluescreen left 15:24 vmspb joined, bluescreen joined 15:26 plobsing left 15:38 plobsing joined
dalek rrot/generational_gc: ea67f36 | bacek++ | src/gc/gc_gms.c:
Revert "Remove pobj2gen and gen2flags functions. They are not used anymore."

This reverts commit 81be312a4eebfe4ef8eff80473aeed99b0a2ad56.		 15:42
rrot/generational_gc: 2790788 | bacek++ | src/gc/gc_gms.c:
Move objects from work_list back to generation's list.
rrot/generational_gc: f951c0c | bacek++ | src/gc/gc_gms.c:
pobj2gen
rrot/generational_gc: f26c475 | bacek++ | src/gc/gc_gms.c:
Seal moved objects and update generation number.
rrot/generational_gc: 94fa70a | bacek++ | src/gc/gc_gms.c:
Fix off-by-one error in sweep_pools.
rrot/generational_gc: 286c19f | bacek++ | src/gc/gc_gms.c:
Fix bug when I try to move object to dirty_list in second time.
rrot/generational_gc: a05b385 | bacek++ | src/gc/gc_gms.c:
Add more stats and fix small bugs in asserts.
rrot/generational_gc: 594d503 | bacek++ | src/gc/gc_gms.c:
Properly remove items from Pointer_Array
cotto_work ~~ 15:56
16:00 adu joined 16:01 vmspb left 16:03 theory joined 16:08 Andy joined 16:09 bluescreen left
whiteknight we really need a library function for will_cause_segfault(void*ptr) 16:10
16:11 Patterner left
whiteknight returns 1 if dereferencing that pointer would cause a segfault 16:11
and then I can decide not to do that
NotFound whiteknight: I'd like better a function do_what_i_want_right_and_fast ;)
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)
whiteknight ah, okay 16:13
plobsing I've recently had a very evil idea to remedy the PIR/arbitrary-constants problem 16:14
whiteknight what's the problem?
and then...what's the solution?
plobsing PIR is a declarative language and can only express concepts its creators imagine
NotFound plobsing: more evil than the one I said yesterday?
plobsing which means that HLL authors wanting to capture complex data in PBC are SOL with PIR 16:15
NotFound: what did you say yesterday?
NotFound plobsing: make the constant table writable during :load and :init
plobsing nope, mines more evil. 16:16
whiteknight it already is writable during :immediate
plobsing whiteknight: yes, but not arbitrarily.
16:16 Psyche^ joined, Psyche^ is now known as Patterner
whiteknight plobsing: okay, get on with it! 16:16
NotFound whiteknight: :immediate does not work well enough.
whiteknight Notfound: I never said it worked well. Only that it works. In theory.
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:17
whiteknight I'm not sure what you mean by that 16:18
NotFound Me neither
plobsing which could destructure PIR into an imperative form, allowing for arbitrary operations on the segments being compiled
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
TT #1993: trac.parrot.org/parrot/ticket/1993
plobsing ok, in terms of which language should I explain it? forth or lisp?
whiteknight I'm not super familiar with either. Lisp
plobsing OK, in terms of lisp, '.sub' starts a reader macro, which expands to (defsub ... (... ops ...)) or somesuch 16:20
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?
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:23
pmichaud whiteknight: ping 16:24
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
is that reasonably accurate? 16:27
whiteknight what I meant by that, is that I don't like that bulk being added in automatically
that is, some variables don't need lexical scoping rules
plobsing paying for features you don't use is not good
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
nqp doesn't make those determinations -- past and post do 16:28
whiteknight yeah, I know that. It's something we need to fix
pmichaud it's a problem for all pct-based languages, not just nqp
whiteknight but in any case, a language that goes through PAST and POST is going to have those problems
so my complaints weren't directed at NQP per se
pmichaud that's how they came across, to me at any rate
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.
pmichaud oh, I think PAST ought to be redesigned to have a better variable allocation strategy, no doubt 16:30
but Parrot's underlying register and symbol table needs a lot of work too
the overhead with lexicals arises from not having a good container/value model
whiteknight yes
pmichaud or reference types
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
plobsing winxed seems to mostly get by without that
pmichaud the new nqp is working on fixing that
whiteknight if somebody such as yourself tells us what they need to see in those areas, we can start putting together a design
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
pmichaud cotto_work: well, there are several pieces to the problem 16:33
NotFound plobsing: winxed has binding/assignment distinction.
pmichaud let's start by identifying those
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
NotFound There is an obstacle in the way to a clean design: morph
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
that is, if I don't need a variable to be .lex, I don't want it to be used that way
NotFound morph and Parrot_pmc_reuse
pmichaud so, you think that nested scopes should not translate to nested parrot subs?
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
dalek TT #207 closed by doughera++: Unsecure RUNPATHS in parrot 0.90
TT #207: trac.parrot.org/parrot/ticket/207
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.
Unused in the innner scopes, that is. 16:38
pmichaud PAST doesn't lexicalized unused variables in the inner scopes either
oh, wait 16:39
I think I misread
you mean it doesn't lexicalize variables in an outer scope if that variable isn't used in any inner scopes
NotFound Yes
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
pmichaud or do we say "if you want to access a variable from an eval, you have to make sure it's lexicalized"?
plobsing not every language has to support dynamic evals. those that don't shouldn't have to pay the price.
pmichaud and yes, Q:PIR is definitely an issue there.
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?
NotFound winxed doesn't have evals.
pmichaud eval is almost always executed as lexically-nested inner sub
whiteknight it seems to me like that isn't a decision our lowest-level language should make 16:41
in nqp?
pmichaud it has to be, otherwise you can't access any variables from the scope you're calling eval from
whiteknight and if I don't want to access any of those variables, then it doesn't need to be lexically scoped 16:42
or if I write out the variables as constants in the code string
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
pmichaud yes, those are all possibilities. it'd be confusing to some programmers, but that's probably okay for a lower-level language
whiteknight my only point is that we have occasional (not common) needs for a language lower-level than NQP
PIR currently fits that niche 16:44
but I think we would all like to replace PIR with something of similar scope but nicer and more extensible syntax
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
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
for example:
.sub 'outer'
.lex '$a', $P0
...
.end
.sub 'inner' :outer('outer')
.outer-lex '$a', $P5
...
.end 16:47
the '.outer-lex' directive would map the local register $P5 to $P0 of the outer sub
so that any references to $P5 in inner are actually references to $P0 in outer
whiteknight The problem with that example is that currently register identifiers are mapped directly to indices in a memory block
plobsing pmichaud: and the underlying mechanism would be more efficient how? 16:48
whiteknight what we would need instead is a "register reference" type
pmichaud plobsing: because we no longer need store_lex or find_lex
whiteknight so .outer-lex '$a', $R0
$P5 = $R0
and later: $P0 = $P5
pmichaud any rebinding of $P5 in the inner scope would automatically rebind $P0 in the outer scope
plobsing pmichaud: *YOU* no longer need store_lex/find_lex, because we've pushed the complexity behind the curtain of the compiler
whiteknight er, $R0 = $P5
pmichaud plobsing: actually, we've pushed the complexity into the virtual machine
because the mapping of inner to outer scope has to take place at runtime, not compile time 16:49
it's still the same effort that we currently do for find_lex
but it cleanly resolves a lot of the binding/assignment problem, which is what leads to the overhead in the first place 16:50
furthermore
if/when lexicals can map to registers other than PMCs, this resolves the same issue that will take place there
i.e.
outer: .lex '$a', $I0
inner: .outer-lex '$a', $I5
changes to $I5 in inner are reflected in $I0 in outer
otherwise, lexical native types will also have to always be doing find_lex and store_lex operations 16:51
because of the possibility of reassignment
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?
it's not a performance hit at all
dukeleto ~~
pmichaud it's far less of a performance hit than what we do now
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
and only when accessing an outer lexical 16:54
it could be a fifth bank of registers, too
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
pmichaud i.e., I/S/N/P/R
in that fifth bank, we always know the registers are references
and then it's always .outer-lex '$a', $R5 16:55
as you alluded earlier
whiteknight right. but then we have to worry about typing. Is it a register to P? Register to S?
$RP5
that's actually very workable
pmichaud also, the compiler knows that the registers are references... that can be static instead of runtime performance 16:56
NotFound whiteknight: not neccesarily, the .lex declaration provide the information. 16:57
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
somewhere Parrot lost that
i.e., it was then trivial to have a called sub manipulate key registers of a caller sub
whiteknight I can imagine both many problems and many benefits with that approach 16:59
it was before my time, however
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.
pmichaud anyway, thanks for listening 17:00
whiteknight pmichaud: any time. We love the feedback 17:01
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
?
plobsing what more could it be?
whiteknight right now it's best use is in writing tests for libparrot
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
whiteknight to a smaller degree it's used in writing libraries
pmichaud: do tell
NotFound A linker more capable than pbc_merge and suppor for it in the pbc format can solve some problems.
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
because the inner closure may need to reference lexicals from the outer sub (even though it has exited)
currently, since lexicals are mapped to the P-bank of registers, that means that all of the P registers are marked "live" for GC
(as well as everything those PMCs mark)
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:05
imagine a PMC that was used to temporarily hold the results of a parse tree 17:06
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
releasing a *ton* of pressure on the GC
plobsing pmichaud: if you know that's going to happen in advance, you could null the registers
pmichaud we've thought about having PCT automatically null its temporaries, yes. 17:07
but that feels like more code bloat.
then people will say "why is NQP generating all of these 'null $Px' instructions?"
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
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
particle1 so then the instruction generated should be 'null $Px # reduce gc pressure' ;)
17:08 particle1 is now known as particle
plobsing if you make that and can demonstrate a marked improvement in GC behaviour, your case becomes a lot stronger 17:08
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.
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
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.
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
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?
pmichaud PerlJam: well, they could have several purposes 17:12
(1) easilly mappable between contexts
(2) lifetimes that extend beyond the scope of a sub execution
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 )
pmichaud plobsing: we've been planning to do something exactly like that in new NQP, yes. 17:13
But it just means you're replacing find_lex/store_lex with keyed lookups
also, note that sometimes the compiler cannot know the distance to the outer context that contains the symbol 17:14
(e.g., in evals)
so it's more of an optimization than a standard mechanism
but instead of a declaration, it could be an opcode, perhaps 17:15
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
PerlJam yes
PerlJam -- more to the point, it's not about "saving context", it's about nulling out no-longer-needed things
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
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
PerlJam how would you not accidentally clobber something in the 5th bank?
pmichaud PerlJam: I don't understand "not accidentally clobber"
plobsing pmichaud: you've said yourself it is hard to tell what is a temporary
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?
plobsing you've just change the problem into "its hard to tell what you can save in a $P register"
the problem is moved, not solved or mitigated
pmichaud okay, so let's fix that one instead
let's create a bank of registers that are explicitly temporary 17:19
and can be cleared on subexit
anyway, I agree that we can see about fixing this in PAST before we do anything else
however
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:20
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
that way you don't clobber any existing ones
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?
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)
we don't have sufficient tools to be able to find out what is holding on to them 17:23
17:23 dmalcolm joined
pmichaud we also know that contexts stay alive long after the outer subs have exited 17:23
and thus all of their contents stay alive
plobsing pmichaud: null dead registers, see if it can reduce GC churn
pmichaud plobsing: that's my point -- we don't have a good way of knowing which registers are 'dead' 17:24
17:24 bluescreen joined
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
plobsing "
pmichaud I know that they're being kept around because GC isn't picking them up 17:25
that doesn't mean I know which registers are holding them. I truly wish I did.
plobsing how can you know that without knowing which registers are dead?
those bits of information are one and the same
pmichaud I can know in this manner
I compile some HLL source code
that produces a parse tree
the parse tree is big
we then compile the parse tree down to the bytecode 17:26
the routines that needed the parse tree are all gone
but the parse tree is never gc'ed
something is holding a reference to the parse tree
I don't know what is holding that reference, but something is, therefore it's still "alive"
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?
I mean, printfs sprinkled all over :-)
cotto_work #ps in 178 17:29
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?
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"
pmichaud it cuts it down further than that, even
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
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
I do know that all of the registers in a context are therefore preserved, whether they need to be or not
this is a problem that wants a solution 17:33
I agree that the particular case I cite above could be due to a stray global
I'd like to have some better tools to find out the cause
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.
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:35
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:36
plobsing that would require a recursive GC wich would most likely blow your stack 17:37
pmichaud at least until recently, a recursive GC is exactly what we had 17:38
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
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:40
pmichaud that would actually be just fine 17:41
17:41 Kristaba joined
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:41
or even a 'gc_trace' opcode 17:42
that performs mark/sweep with tracing enabled
right now the reference situation is largely invisible to anyone working in PIR, so it's very hard to see what's happening 17:43
17:44 vmspb joined 17:45 arnsholt left
particle surely there's an unused flag bit in the parse tree pmc type 17:45
pmichaud parse trees are Regex::Match objects 17:46
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
PerlJam If you could dump the state of the GC to stderr, you could take snapshots whenever you wanted.
pmichaud PerlJam: yes, see 'gc_trace' above :) 17:48
PerlJam sorry, I'm only paying 0.25% attention right now
17:53 sheant joined 17:55 arnsholt joined
cotto_work It's funny how many wiki pages I look at, only to see that I originally created the first version. 17:58
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:11
*ref to a parse tree 18:12
whiteknight plobsing: ping 18:16
actually, unping 18:18
...and plobsing: reping 18:20
plobsing whiteknight: pong, unpong, repong? 18:31
whiteknight plobsing: the Eval PMC destroy vtable. Is there any way we're destroying PackFiles in there? 18:33
any reason?
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.
in this way, the eval PMC is providing primitive GC support for the packfiles it manages 18:36
18:36 arnsholt_ joined
tadzik hello parrots 18:36
18:36 arnsholt_ left
whiteknight plobsing: is that something we want? 18:37
adu: not that I am aware of
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
dalek nxed: r766 | NotFound++ | trunk/winxedst1.winxed:
add predefined symbol __FUNCTION__ and change ns and class path handling to
 18:47
rrot/whiteknight/imcc_compreg_pmc: f7bdb4f | Whiteknight++ | / (6 files):
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
rrot/whiteknight/imcc_compreg_pmc: d7e666a | Whiteknight++ | / (2 files):
give evals proper names again
rrot/whiteknight/imcc_compreg_pmc: 8e327c4 | Whiteknight++ | src/pmc/imccompiler.pmc:
make sure to restore the interp->code pointer after invoking the IMCC compreg
rrot/whiteknight/imcc_compreg_pmc: 713f76b | Whiteknight++ | tools/dev/pbc_to_exe.pir:
register PIR and PASM compregs in pbc_to_exe.

This fixes some of the bugs I was seeing in pbc_to_exe. Now I'm seeing a segfault when running nci thunk generator
rrot/whiteknight/imcc_compreg_pmc: b494693 | Whiteknight++ | src/pmc/imccompiler.pmc:
reset imcc before calling into it. This gets us much further in the build
rrot/whiteknight/imcc_compreg_pmc: bfa470e | Whiteknight++ | / (2 files):
build eval pmc in IMCCompiler.invoke.

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:52 chromatic joined
whiteknight I'm getting a really weird segfault now in this branch, if anybody has a few tuits to look at it 18:57
19:03 nwellnhof joined
dalek Heuristic branch merge: pushed 152 commits to parrot/nwellnhof/gc_dynamic_threshold by nwellnhof 19:13
nopaste "nwellnhof" at 192.168.1.3 pasted "pmichaud's GC test on nwellnhof/gc_dynamic_threshold" (301 lines) at nopaste.snit.ch/29949 19:14
whiteknight what is the output supposed to look like?
pmichaud like that. :-)
cotto_work pmichaud++ 19:15
pmichaud the original would have very long lines of #'s when a gc mark/sweep run occured
nwellnhof now we have more but shorter GC runs 19:16
tadzik mind showing the old output, or the script itself?
pmichaud just a sec
(running it now)
cotto_work what do those octothorpes represent? 19:17
pmichaud gist.github.com/806427
each octothorp represents 0.02 second spent in the iteration
(or time spent since the previous iteration)
cotto_work ok
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
pmichaud that's because of gc, we believe
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:20
pmichaud cotto_work: it depends on what features of parrot need to be exposed 19:21
for example, "use Parrot;" would enable the pir:: or pirop:: namespace for access to individual Parrot opcodes
I suspect it would also enable the "is vtable('...')" and "is multi('...')" traits for decorating subs with :multi, :vtable, etc. 19:22
it could also bring in prototypes for access to Parrot's built in PMC types
i.e., so one can use Integer/Float/ResizablePMCArray/etc directly
cotto_work that'd work through pir::new('X'); 19:23
pmichaud yes, we could fix that too
jnthn Eww, not string new. :)
pmichaud it might also enable some syntax for generating Key constants
jnthn :) 19:24
cotto_work bacek++ #tuning the moon
whiteknight every time you call new_p_sc, somewhere, somehow, jnthn gets hit in the face with a rock 19:25
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
tracking the sub where a PMC was created seems like a good idea.
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
cotto_work We have a very large number of invalid addresses we can use.
pmichaud knowing the sub where a PMC was created would be outstanding 19:30
as I mentioned earlier, it would be *really* helpful to track the number of PMCs being created by each sub
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? :)
pmichaud fwiw, adding a count-of-PMCs slot to subs shouldn't be all that expensive 19:32
19:32 contingencyplan joined
pmichaud whether or not it gets counted could be triggered by a toggle 19:32
so it doesn't add much in the way of runtime overhead
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
(when the enabling flag is set)
chromatic Don't tie it to the sub; tie it to the context.
pmichaud except that I don't have a way to report contexts 19:33
at the end, I really want to know which subs are responsible for creating all those pmcs
and contexts don't have that long a life
whiteknight tying it to the sub would probably be the most valuable
chromatic Tying it to the sub is broken.
whiteknight that count includes information about which subs are hot
pmichaud fair enough
chromatic Half of the problem of artifically extended lifespans is that our subs *aren't* read only at runtime. 19:34
The other half of the problem is a lack of any sensible register allocator.
pmichaud we'll always have some subs that have to be not-read-only, I fear. 19:35
eval() comes to mind
either that or we need a lot better :outer() handling
chromatic Creating new subs is fine.
Writing to existing subs is not.
19:35 freeksh0w86 left
pmichaud there's not presently a way to create a new sub attached to an existing outer 19:35
we have to create the sub, then modify its :outer 19:36
similarly for doing things like attaching HLL signatures
chromatic I agree. Those need fixing.
But please don't add to the list of things that need fixing.
pmichaud unless the declaration syntax is going to enable us to attach arbitrary attributes or wrappers at compile time
I'm just saying that "constant subs" requires a lot of other big changes first.
chromatic I agree. 19:37
nwellnhof bacek, ping
pmichaud if there's a way to mark a sub as read-only after it's been "managed", that would be okay also.
i.e., the HLL could say "I'm done fiddling with this Sub, it's constant now."
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
It's simply that PIR/PBC doesn't give us enough ability to decorate the sub with everything we need at IMCC compile time.
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.
chromatic It should help GC dramatically.
pmichaud that's really been there for backwards compatibility, afaik.
or if there's a way that we could decorate a sub to say "don't store the active context", that'd work too.
jnthn I thought that was ow capture_lex worked? 19:40
*how
pmichaud capture_lex captures outer contexts into the current context
the part where it gets stored in the sub is for autoclose, iirc.
capture_lex avoids the need for that altogether
jnthn ah, ok
pmichaud oh wait, perhaps not.
hmmm
jnthn auto-close only gets hit due to lack of static lexpads
pmichaud anyway, iirc auto-close is the bigger culprit here 19:41
jnthn It causes a bunch of our issues
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
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
So you can install something in it once (e.g. at init or even compile time once it's bootstrapped)
And you're done.
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.
aloha nwellnhof: OK. I'll deliver the message.
nwellnhof PerlJam: i think we can merge gc_dynamic_threshold in the next couple of days. 19:44
pmichaud nwellnhof: did you notice any other issues in larger programs, such as in building Rakudo itself or running Rakudo's spectests? 19:45
i.e., in making the one small program run better, did we lose something on the larger ones?
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
it didn't notice any spectest breakage, but i have to retest.
pmichaud okay
"a bit slower" is probably okay. a lot slower will cause pain :)
nwellnhof *i
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
environment variables or config files might be nicer.
and you can trigger tt #1990 easily, but there's a simple workaround. 19:50
dalek tracwiki: v3 | pmichaud++ | RakudoTasklist 19:55
tracwiki: trac.parrot.org/parrot/wiki/RakudoT...ction=diff
nwellnhof see also irclog.perlgeek.de/parrot/2010-12-24#i_3116771
pmichaud gist.github.com/806539 # gc-1 benchmark instrumented with memory usage 19:58
I don't see a significant jump in memory usage on the first iteration, fwiw 19:59
actually, I guess the first iteration consumes 4MB extra, relative to the others 20:00
so that's consistent with what nwellhof++ reported 20:01
nwellnhof pmichaud: that's because TOTAL_MEM_ALLOC also counts freed memory.
pmichaud I'm sure the extra there is because of methods being invoked for the first time and therefore having their signatures generated + attached
still, 4MB seems like an awful lot for that.
nwellnhof i will add TOTAL_MEM_USED which is much more accurate. 20:02
pmichaud please do
and something is leaking a ton of memory, which I wouldn't really expect in this little program
oh, wait 20:03
TOTAL_MEM_ALLOC is the total of all memory allocated, including that which is freed 20:04
so obviously this number is monotonically increasin....no, that can't be it
what does TOTAL_MEM_ALLOC really represent?
or is it really just not useful as currently implemented?
nwellnhof pmichaud: yes, it's monotonically increasing because Parrot doesn't return (most of the) memory to the system. 20:05
pmichaud but in the output I just nopasted, it's not monotonically increasing 20:06
it resets to a lower number after some of the gc runs
nwellnhof yes, it's buggy in master.
pmichaud okay, so "not useful as currently implemented"
nwellnhof yes, it should be more useful in my gc branch. 20:07
pmichaud: i'll try your new test script on my branch after make spectest has finished. 20:14
memory accounting is a bit complicated because Parrot also uses malloc for a lot of stuff. 20:15
whiteknight we really should be able to move most uses of malloc to the fixed-size allocator 20:17
that's neither here nor there
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
even if that "mechanism" was initially a thin wrapper around malloc 20:19
at least initially
20:19 tcurtis joined
nwellnhof yes, we could implement a variable size allocator that works like the fixed size allocator but uses size classes. 20:19
btw, we have that wrapper already. 20:20
whiteknight do we? I can't keep track of all the things we have now
nwellnhof the usual sequence is mem_gc_allocate => Parrot_gc_allocate_memory_chunk => malloc 20:21
then there's mem_sys_allocate which also calls malloc 20:22
it's a bit messy.
whiteknight ok 20:24
cotto_work #ps in 5 20:25
get those reports posted, slackers!
Hackbinary hello
I have a silly question
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?
Tene Hackbinary: that would be just fine
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 :)
whiteknight cardinal is at parrot/cardinal now, not cardinal/cardinal 20:28
20:28 plobsing left
whiteknight but same principle applies: create a fork and submit pull requests and patches 20:28
pmichaud does INTERPINFO_TOTAL_PMCS no longer work?
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...
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
Let's worry about that later. I'll do some research.
right now Hackbinary can create a fork and start making patches
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
cotto_work #ps in now 20:32
Tene I admit to ignorance of how github organizations work.
whiteknight Tene: Each organization has teams. Each team has a set of permissions and a list of repos
so I think we can create a team for cardinal developers, or a team for HLL developers in general
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
there are lots of things we can look at
nwellnhof Util: i'd love to have a look at those Coverity reports
Tene Sure.
nwellnhof Rakudo spectest: PASS on nwellnhof/gc_dynamic_threshold 20:34
pmichaud nwellnhof ++
nwellnhof gc-2.p6 on nwellnhof/gc_dynamic_threshold: gist.github.com/806603 20:37
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.
pmichaud that's a heck of a lot smaller memory usage
nwellnhof yes, that's because of the 1/8 of sysmem GC threshold.
pmichaud ah
Util nwellnhof: private msg
pmichaud and you have less memory than I, I suspect
I'll check out the branch and give it a try
nwellnhof pmichaud: no the dynamic threshold isn't based on sysmem anymore. 20:39
pmichaud oh
okay, maybe I'll wait for a merge
Hackbinary tene: that's my stuff up into github.com/hackbinary/cardinal 20:47
tene: now 525 of 609 tests passed; was at 497 of 603 20:49
Tene Hackbinary: That's great. What did you work on?
(bit too busy to read commit log ATM)
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
and a get_bool for NilType.pir to return 0
tadzik I'd like to see that
Hackbinary I also added 6 tests to 01-stmts.t 20:52
pmichaud NotFound: I'm not claiming that PCT is the only way to do it. 20:58
IMCC does not make for a robust enough infrastructure for writing, say Tcl or APL or Python without a *lot* of work 20:59
a higher level toolchain of some sort is needed
NotFound pmichaud: it will be, if people keeps going towards generating pbc from POST as the only reasonable way.
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
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
pmichaud fairy nuff.
whiteknight if our internal, self-maintained, IMCC replacement language is some kind of copy/fork of NQP, I'm fine with that 21:01
if our language for writing compilers tools is some kind of copy/fork of NQP, I'm fine with that too
actually, for the former I would probably prefer a fork that we maintain ourselves
for the later, maybe we can be a little bit more hands-off 21:02
but then it doesn't make a lot of sense to be mixing versions of NQP 21:03
chromatic That's the problem. 21:04
Oh, and ops2c relies on NQP.
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.
whiteknight so maybe that's it. We need a language that we can maintain, but we don't want to maintain NQP 21:05
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
cotto_work We need something stable. If someone else maintains it (and we have a channel to contribute fixes, etc), that's fine.
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.
whiteknight maintains what out of tree?
chromatic I was responding to cotto. 21:07
whiteknight oh, sorry
dalek TT #1994 created by pmichaud++: interpinfo TOTAL_PMCS and ACTIVE_PMCS no longer work in 3.0.0 21:08
TT #1994: trac.parrot.org/parrot/ticket/1994
21:13 plobsing joined
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:14
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:15
pmichaud cotto_work: I think so, yes. 21:16
I don't expect much to break quickly.
cotto_work "quickly"?
pmichaud We'll undoubtedly provide some deprecation points as we evolve
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
nqp-nom (the new nqp) is far more an evolution of nqp-rx than a rewrite
it's just we had to break the underlying object model code in order to use 6model
cotto_work that's my understanding
21:17 chromatic left
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
pmichaud I'd even be willing to make it a goal to keep that running for a while
cotto_work That'd be helpful.
dalek nxed: r767 | NotFound++ | trunk/winxedst1.winxed:
generate .const 'Sub' from using when the function is defined in the current
pmichaud I mean, we depend on ops2c pretty heavily too :)
since we have custom dynops
Hackbinary: I'm certain that nqp will move to a more regular release/deprecation cycle, yes.
cotto_work a deprecation policy like what Parrot tries to do (notify, provide a period when old and new work, etc) would help also
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
cotto_work were you on the concall?
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.
I'm sure it will be different going forward.
cotto_work is PaFo getting bought out? Are my shares worth millions? 21:21
dalek rrot/nwellnhof/gc_dynamic_threshold: 00d27fb | nwellnhof++ | / (3 files):
Work around GC problem in embed API
 21:22
rrot/nwellnhof/gc_dynamic_threshold: 017627f | nwellnhof++ | / (5 files):
Add TOTAL_MEM_USED to interpinfo
21:27 Andy left
KaeseEs "Winxed has three native datatypes: int, float, string and var. " 21:27
21:30 whiteknight left
tadzik and is subject to the banana problem 21:30
dukeleto cotto_work: yes, i was on the conf call
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
cotto_work: not really
cotto_work That's a good place to be unsurprised.
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
pmichaud particle can be the new mascot? ;-) 21:32
colored feathers, I hope!
dukeleto We have to reverse engineer financial data from Quickbooks, and nobody uses windows, except particle .
cotto_work "particle is a pretty cool guy. eh uses windows and doesn't afraid of anything" 21:33
done
21:34 ilia joined
dalek rrot: efd80f0 | NotFound++ | tools/dev/show_deprecated.pl:
show something meaningful for deprecation notices without eligible or ticket fields
 21:36
NotFound KaeseEs: what's the problem? 21:37
cotto_work 3 != 4
NotFound Uh :D
There are three kinds of people: able to count and unable to count. 21:38
21:41 plobsing left
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++
nwellnhof lol 21:42
21:42 fperrad left
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:47
cotto_work It shouldn't blow up. Can you nopaste what you're seeing? 21:50
21:57 rurban_ joined
nopaste "KaeseEs" at 192.168.1.3 pasted "In file included from include/" (63 lines) at nopaste.snit.ch/29968 21:57
NotFound KaeseEs: fixed, thanks. 21:59
cotto_work KaeseEs: it's probably an error in your code. Can you nopaste that?
notice the first few lines
22:00 rurban left, rurban_ is now known as rurban
KaeseEs pastebin.com/KX1Fu3MZ 22:00
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"
NotFound tadzik: writing four letters is more lazy than none? 22:04
22:04 wknight-phone joined
tadzik ah, you mean any fun(void) is wrong? 22:05
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
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
KaeseEs NotFound: see section 5.1.2.2.1 in the iso standard www.open-std.org/jtc1/sc22/wg14/www.../n1539.pdf 22:09
AndroUser2 standards. blah 22:12
22:14 AndroUser2 is now known as wknight-phone
NotFound Sorry, maybe I was thinking in C++ 22:14
wknight-phone c++, double blah
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
wknight-phone :) 22:17
22:18 mtk left
dalek rrot: 2cdf5dd | nwellnhof++ | / (2 files):
Add some debug output to IPv6 test
 22:22
22:24 mtk joined
Coke Didn't particle submit a bio a year ago? 22:24
... but I don't have it gmail. 22:25
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.
wknight-phone KaeseEs, what are you working on? 22:29
dalek parrot: f4a80b1 | theory++ | pgtap.sql:
Update pgTAP URL.
 22:31
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.
nwellnhof KaeseEs: doesn't metronome use read barriers? 22:34
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.
KaeseEs nwellnhof: unsure, I've only glossed through most of bacon's stuff so far
NotFound: gah I didn't see that, thanks 22:36
pmichaud particle: awwww, no tar and feathers?
particle tar and feather me anyway, i'm ready to party! 22:37
pmichaud :-P
Hackbinary I'll bring the whiskey
22:39 wknight-phone left 22:41 ilia left
dalek rrot/generational_gc: 515bf97 | bacek++ | src/gc/gc_gms.c:
Reimplement check_sanity
 22:53
22:55 vmspb left
dalek TT #721 closed by pmichaud++: PGE::P5Regex consumes all memory 23:06
TT #721: trac.parrot.org/parrot/ticket/721
TT #843 closed by pmichaud++: PGE will assume {*} at end of every regex
TT #843: trac.parrot.org/parrot/ticket/843
TT #851 closed by pmichaud++: [DEPRECATED] .find_key method on PGE;Match objects
TT #851: trac.parrot.org/parrot/ticket/851
TT #1017 closed by pmichaud++: recognize the form of alternation
TT #1017: trac.parrot.org/parrot/ticket/1017
TT #1037 closed by pmichaud++: throw useful exception on non-quoted non-word characters in PGE
TT #1037: trac.parrot.org/parrot/ticket/1037
TT #1042 closed by pmichaud++: PGE doesn't support angle quotes inside of regexes.
TT #1042: trac.parrot.org/parrot/ticket/1042
TT #1065 closed by pmichaud++: PGE should emit inline PIR with Grammar namespace
TT #1065: trac.parrot.org/parrot/ticket/1065
dukeleto KaeseEs: including parrot/parrot.h is bad juju 23:09
KaeseEs: best to include the actual headers that you need
KaeseEs: parrot/parrot.h is the internal api and can change at any time
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
cotto_work I'm happy.
Hackbinary +1 23:11
KaeseEs dukeleto: will keep in mind. 23:12
dalek rrot: a35f817 | nwellnhof++ | / (5 files):
Remove support for deprecated charset:encoding:"" literals

TT #1808		 23:18
TT #1163 closed by pmichaud++: PGE: refactor pod_comment rule into PGE/Util.pbc 23:23
TT #1163: trac.parrot.org/parrot/ticket/1163
TT #329 closed by pmichaud++: [PATCH] save compiler filename in PCT::HLLCompiler
TT #329: trac.parrot.org/parrot/ticket/329
TT #466 closed by pmichaud++: PAST::Val.new( :value( ~$/ ), :returns('Complex')) generates incorrect pir
TT #466: trac.parrot.org/parrot/ticket/466
TT #1808 closed by nwellnhof++: PIR string literals with charset and encoding are deprecated
TT #1808: trac.parrot.org/parrot/ticket/1808
23:26 kid51 joined
dalek rrot: 693ddea | pmichaud++ | compilers/pct/src/POST/Node.pir:
[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
rrot: d774533 | pmichaud++ | / (5 files):
Merge branch 'master' of github.com:parrot/parrot
23:31 plobsing joined 23:40 tcurtis left
dalek TT #1882 closed by nwellnhof++: gethostbyname failure doesn't throw an exception 23:40
TT #1882: trac.parrot.org/parrot/ticket/1882
TT #821 closed by pmichaud++: PCT - POST::Sub::add_param() ignores +optional+slurpy parameters.
TT #821: trac.parrot.org/parrot/ticket/821
TT #868 closed by pmichaud++: DEPRECATE generation of PAST::Val constants
TT #868: trac.parrot.org/parrot/ticket/868
TT #1198 closed by pmichaud++: interactive mode doesn't save lexicals correctly
TT #1198: trac.parrot.org/parrot/ticket/1198
TT #1179 closed by nwellnhof++: Test open file, close file, delete file, reopen previously opened stream
TT #1179: trac.parrot.org/parrot/ticket/1179
TT #1625 closed by pmichaud++: PCT generates usage message too early
TT #1625: trac.parrot.org/parrot/ticket/1625
pmichaud Resolved 14 tickets. :-) 23:43
Added one new ticket earlier today, which makes my total for the day of -13
cotto_work pmichaud++ 23:45
pmichaud So, we're down to 530 tickets.
dalek nxed: r768 | NotFound++ | trunk/winxedst1.winxed:
refactor command line option handling and activate the option --noan in stage 1
pmichaud closed #589, so -14 23:50
23:51 kid51 is now known as kid51_at_dinner, whiteknight joined
cotto_work I haven't even had a chance to get in on the action. 23:53
If this keeps up we'll hit 500 by the weekend.
pmichaud #1993 needs fixing soon -- it causes test failures on my system 23:54
whiteknight ...too...many....ticket....emails.....
whiteknight has seizure
pmichaud i.e., "make test" doesn't pass on my system
23:56 cosimo joined
dalek TT #589 closed by pmichaud++: PGE Longest token match 23:57
TT #589: trac.parrot.org/parrot/ticket/589
rrot/yaml-fix: 0ed38ee | cotto++ | t/tools/show_ (2 files):
add patch from doughera++ to start fixing the yaml tests on systems with the required perl modules installed
 23:59

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!