Parrot 3.0.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: Fix ipv6-related failures
Set by moderator on 10 February 2011.
00:01 Andy left
bacek_at_work auto::pcre - Does your platform support pcre...............yes, 8.02. 00:02
on my box
linux/i386/c++ with optimize
test passed...
cotto_work ship it
bacek_at_work cotto_work, it's "shipped"
whiteknight chromatic pwnd my github dashboard
cotto_work It's not on a ship. It's not shipped. 00:03
00:07 davidfetter left
cotto_work github's new file browser is really nice 00:09
00:14 mikehh left
tadzik slp & 00:14
00:17 janus left
dukeleto cotto_work: i dig it 00:19
cotto they're going nuts hiring recently 00:33
makes me wish I lived in sf and cared about ruby
Tene cotto: The company I'm working for in mountain view is hiring, and doesn't use ruby. 00:34
I expect the other condition also applies, though
cotto very much so, and I already have a job I'm happy with 00:35
Tene If anyone here happens to know any sysadmins in the bay area that want work, we very much need another good sysadmin.
cotto I love hearing about tech companies that are hiring. 00:36
Tene Our operations code is all in perl. The original ops people treated it like an awkward bash, though, so I've been doing a lot of cleanup. 00:37
00:38 Coke left
cotto allison, I don't see your PhD paper in my inbox. Could you re-send it? 00:38
00:52 mikehh joined
whiteknight my company is hiring like crazy. C# devs in philly 00:53
cotto mine too, though most PHP folks probably aren't hanging out on #parrot 00:54
statistically there'll only be one, so I'm it 00:59
00:59 NotFound left
Tene cotto: we've had other php guys in the past, I thought 00:59
01:00 NotFound joined
cotto I haven't seen barney in a while. 01:02
whiteknight me either
01:09 plobsing joined 01:11 lucian left
nopaste "kid51" at 192.168.1.3 pasted "generational_gc branch no longer builds on darwin/ppc" (825 lines) at nopaste.snit.ch/31256 01:13
kid51 ... which is surprising, because up until today it was building there, albeit with some test failures when configured with --optimize 01:14
Trying again ... 01:19
I think the failure was with "all gcc", which is not the way I usually configure on darwin/ppc 01:20
whiteknight is there any reason why interp->ctx would be 0x200? 01:24
oh nevermind, my mistake 01:27
blah. this imcc branch is a huge pain in the ass 01:30
01:45 dmalcolm left 01:52 jsut joined
Hackbinary I have a question about pod linking in the documentation: how should it be done? 01:54
because the generators are autolinking it cpan
should I just code it to go github, or to parrot.org? 01:55
01:56 jsut_ left
whiteknight github, I think 01:58
kid51 whiteknight: I feel your pain. It's not building even on plain vanilla linux/i386 (or, at least it wasn't several hours ago)
whiteknight kid51: my branch? 01:59
Hackbinary github it is :)
kid51 the compreg branch
Is it no longer possible to configure Parrot with g++? 02:10
Was it ever?
In master, if I say:
CXX='g++';echo $CXX
perl Configure.pl --cc=$CXX
... I get massive failures before I'm even out of configuration 02:11
And, where did our --cxx option go to?
I can no longer find any place in the configuration system where it is assigned from
whiteknight kid51: yeah, the branch is in flux. You may want to avoid testing it for the next few days 02:15
02:26 Coke joined 02:29 mtk left
dalek rrot/whiteknight/imcc_compreg_pmc: b7dac65 | Whiteknight++ | / (4 files):
in Parrot_ext_try, cache the current context, and make sure to go back to it when we are done. This solves an infinite loop problem I was seeing earlier. In inter_create, set interp->ctx to NULL because PMCNULL hasn't been initialized yet so it's just garbage.
 02:36
rrot/whiteknight/imcc_compreg_pmc: 93a0088 | Whiteknight++ | / (3 files):
use the same callin/callout mechanism for the IMCC API as for the normal embedding API. This makes correct error handling much easier. Also, remove the Parrot_x_jump_out_error function. IMCC can jump out now by throwing a normal exception. Through the API it has the API error handling mechanism. Through the compreg it has the normal Parrot exception handling system
rrot/whiteknight/imcc_compreg_pmc: 6620d5f | Whiteknight++ | / (5 files):
fix the frontend to use the new IMCC API functions. almost build again
02:36 whiteknight left, mtk joined 02:38 wknight-phone joined
dalek TT #2004 created by jkeenan++: Where did Configure.pl option '--cxx' go to? 02:38
TT #2004: trac.parrot.org/parrot/ticket/2004
mikehh kid51: I am not sure I follow that - I use it 02:40
kid51: base config -> date && time perl Configure.pl --test --cc=g++ --cxx=g++ --link=g++ --ld=g++ (plus maybe other options)
kid51 mikehh: Yes, on Darwin/PPC, I've used '$CX=g++;perl Configure.pl --cxx=g++' for years 02:48
But where does that option get used inside the configuration system?
Tene kid51: what shell is that?
kid51 bash
Tene that... won't do anything to influence the run of Configure.pl
kid51 Tene: Set aside that shell question. 02:49
Tene except probably error, unless $CX is already set to something
kid51 I'm getting this on Linux/i386 were I simply use perl Configure.pl
Tene 'k
I haven't been following anything else going on; that just stood out as notable to me.
kid51 Show me where (right now) we take that command-line option and use it to say "Use this value as your c++ compiler" 02:50
allison cotto: yah, I composed an email message to resend, just in case I didn't CC you when I sent it to whiteknight a few months ago... sending now 02:56
02:59 wknight-phone left
dukeleto ~~ 03:01
kid51: i may be able to attend the python event, don't remember the exact time 03:02
03:04 wknight-phone joined
kid51 dukeleto: Appears to be a day-long event starting at 9:00 am. 03:05
dukeleto kid51: i don't do 9am 03:07
kid51: if you know what you want me to say to prospective python devs, I can orate that 03:08
kid51 dukeleto: Just pass along what I posted on parrot.org. 03:15
or consult with Allison
dukeleto kid51: that doesn't really cut it 03:19
kid51: there is no infrastructure
kid51: there is no plan 03:20
kid51: who is the goto person for python-on-parrot ?
kid51: is there a spec ?
kid51: which repo does python on parrot live in?
kid51: without those things figured out before that meeting, nothing will happen
kid51 dukeleto: Fine, then don't go. 03:21
It's up to the python people who want to build on parrot to formulate their own plan of action 03:22
I'm just trying to encourage them.
I spent two hours with a Python developer Tuesday night.
He was already ahead of me. He had been IMing with Allison and Lucian the previous night ... on this channel! 03:23
dukeleto kid51: i didn't say I wasn't going to go. I am just telling you that not having some basic infrastructure setup is going to seriously hamper stuff happening 03:33
kid51: who is this person you are talking about?
03:42 benabik joined 03:45 particle1 joined 03:50 particle left
cotto kid51, I've been configuring for a c++ build with --cc=g++ --link=g++ --ld=g++ and it's definitely using g++ as the compiler. 03:54
I don't remember --cxx ever being required. It might be a fossil from the bad old days when icu was included in svn.
kid51 cotto: Back in late 2006, I was having problems compiling on Darwin/PPC 03:55
coke gave me this shell script which I've used ever since
It assigns: $CX="/usr/bin/g++", and then calls perl Configure.pl --cc="$CC" --cxx="$CX" --ld="$CX" --link="$CX" 03:57
So, I assume from that -- and from the presence of 'cxx' in the Options modules -- that at one point it was meaningful
The only thing that prompted me was the problems I'm having today on generational_gc on darwin/ppc ... 03:58
... when by accident I called 'perl Configure.pl' by itself once, outside of my shell script
I believe that in 'master', I can simply run 'perl Configure.pl' on Darwin/ppc ... but that isn't working in generational_gc 04:00
./parrot-nqp --target=pir runtime/parrot/library/YAML/Tiny.pm > runtime/parrot/library/YAML/Tiny.pir
src/gc/gc_gms.c:2177: failed assertion '!PObj_on_free_list_TEST(pmc)'
make: *** [runtime/parrot/library/YAML/Tiny.pir] Error 134
kid51 must sleep
cotto 'night 04:01
dukeleto cotto: are you thinking about m0 stuff? 04:05
cotto usually 04:09
dukeleto, did you have an idea?
seen chromatic 04:11
aloha chromatic was last seen in #parrot 9 days 6 hours ago leaving the channel.
04:14 hercynium joined 04:15 kid51 left
dukeleto cotto: i saw chromatic last night :) 04:15
cotto: yes, i did have an idea. It hurt.
cotto: have you looked at my lorito branch
cotto not recently 04:16
dukeleto cotto: i need help with defining the internals of LoritoContextPMC
cotto dukeleto, What's your current sticking point? 04:17
dukeleto cotto: needing a way forward 04:19
cotto: do you remember our meeting when allison said that implementing "print 42" in M0 is our first prototype?
cotto: what do we need in M0 to implement "print 42" ?
cotto I'm glad you remembered that. For some reason it didn't stick with me. 04:20
op definition, op encoding, parser for textual M0, basic runloop, set of registers, pc 04:22
way to deal with int constants
default (or explicit) entry point for ops 04:24
Is there anything else you can think of? 04:25
dukeleto cotto: lets ignore encoding for now. It will be simple to add later 04:26
cotto: what do you mean by "op definition" ?
cotto "When you see 'print', here's what you do with the arguments."
i.e. what lives in .ops files currently 04:27
04:27 wknight-phone left
dukeleto cotto: so we need a "print" M0 op, correct? 04:28
cotto definitely 04:31
dukeleto will add it 04:33
dalek rrot/m0spec: 2e1618c | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Add print and set as M0 ops
 04:35
dukeleto cotto: arg, i accidentally created a new branch. fixing. 04:39
dalek rrot/m0-spec: 2e1618c | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Add print and set as M0 ops
 04:40
dukeleto cotto: fixed.
cotto: define "basic runloop" 04:41
cotto read an op and args, lookup/run the right bit of code, increment the pc if it hasn't changed, repeat 04:42
dukeleto cotto: that is our killer feature for lorito right now. We need a functioning runloop 04:44
cotto: can you add details about what a functional runloop is to the spec?
cotto dukeleto, yes I can.
dukeleto, what magic do I need to invoke so that git will pull the current branch when I say git pull? 04:45
dukeleto cotto: i will humbly suggest git pull --rebase 04:46
cotto dukeleto, that still asks which branch I want to pull from 04:51
sorear cotto: fix your .git/config 04:53
cotto do I need to do that for each branch I'm playing with? 04:54
sorear no 04:55
you can edit .git/config with wildcards
dukeleto cotto: gist the error that you get 04:57
cotto: which version of git?
cotto gist.github.com/821942
1.7.1 04:58
dukeleto cotto: what does this mean ? gist.github.com/821943 04:59
cotto: you forgot --rebase
cotto: git pull does a merge
cotto: git pull -rebase does a rebase
cotto: you can also do "git fetch --all"
cotto: then a git rebase origin/master
cotto: or whatever branch it is
cotto: you can also do "git fetch origin"
cotto: fetch only operates on the index
cotto: pull operates on the working copy 05:00
cotto dukeleto, looks like you need to include the generated pmc header somewhere
is that in your lorito branch 05:01
?
if the lorito ops are dynops, nothing that links into libparrot should be using its attr accessors directly 05:03
cotto got confused
looks like some pmc2c lameness 05:05
dukeleto cotto: yes, that is in my lorito branch 05:06
cotto: i am trying to make it compile
baby steps... 05:07
cotto the code is trying to access ATTRs that aren't defined
e.g. there's no ATTR declaration for to_ctx 05:08
dalek rrot/lorito: 385209c | dukeleto++ | src/pmc/loritocontext.pmc:
Make stuff compile. Linking still fails
dukeleto cotto: yes, i am cargo culting
cotto that's the best kind of cult
though to be fair, the other kinds aren't very good at all 05:09
dalek rrot/luben/gc_gms_dyn_threshold: 6f6c95b | luben++ | src/gc/gc_ (2 files):
port dynamic threshold to gc_gms
 05:13
dukeleto cotto: where am I supposed to put ATTR definitions? 05:14
cotto dukeleto, after the pmclass declaration
you've already got a bunch there
starting at line 55 05:15
bacek_at_work luben, this is wrong: 05:16
- interp->gc_sys->stats.mem_used_last_collect = 0;
833
+ interp->gc_sys->stats.mem_used_last_collect = interp->gc_sys->stats.memory_used;
(for GenGC)
luben stats.memory_used is not the whole memory? 05:17
bacek_at_work luben, it is 05:18
But for triggering nursery collections we don't have to know it
we need size of _nursery_
stats.memory_used can be trigger for collecting oldest generation 05:19
dukeleto cotto: i think you didn't create a tracking branch
cotto: when creating a new branch, do "git checkout -b foo origin/foo"
cotto hmmm. I thought I was in the habit of doing that. 05:20
luben as it is now it is triggered by the total alocated size
dukeleto cotto: and then git will know that local branch foo is supposed to push to foo on origin
cotto: cat .git/config and gist it
bacek_at_work dukeleto, of just use modern git which will do it automatically :)
luben, in MS2 - yes, in GMS - no.
dukeleto cotto: that is what i am doing. modern gits don't need -t
cotto: but you do need to tell it that you are trackign origin/foo when you branch :)
bacek_at_work: ^^^ 05:21
dukeleto misfired
cotto: you should have : [branch "m0-spec"] remote = origin merge = refs/heads/m0-spec
cotto: in your .git/config, with the appropriate newlines
dalek rrot/lorito: f75b446 | dukeleto++ | src/pmc/loritocontext.pmc:
Make LoritoContext PMC compile
 05:22
cotto dukeleto, thanks. That worked.
dukeleto cotto: cool.
cotto dukeleto++
dukeleto cotto: LoritoContext PMC now compiles.
cotto dukeleto, so it does 05:23
dalek rrot/lorito: 8cbccce | dukeleto++ | / (2 files):
Add a basic LoritoContext PMC test
 05:24
dukeleto cotto: we need the M0 spec to exactly spell out what a LoritoContext contains
cotto: it is the secret sauce of M0
cotto: we are close to getting "print 42" to work. I can smell it. 05:25
cotto dukeleto, I'm thinking about how important it is to maintain a distinction between M0 (ops and vm) and Lorito as a whole.
M0 will be implemented several times for different purposes, but the higher-level pieces will only need to be implemented once. 05:28
dukeleto cotto: the spec is the most important thing 05:29
cotto: my lorito branch is just a prototype usign dynops. That might be how we end up doing Lorito, or we may go another route
cotto right. I'm thinking how (and if) the specs for M0 and Lorito should be separated.
dukeleto cotto: but the hammering out the spec is the most valuable thing right now
cotto: i think M0 is the most important part of Lorito right now 05:30
cotto yes
dukeleto cotto: Lorito can't exist without M0
cotto that's the first thing we need to get right
dukeleto cotto: so we concentrate on the spec of M0 now
cotto: and when we are in a position to worry about M1, we deal witht that
cotto It's also important to define what's not part of M0 though.
dukeleto cotto: for now, Lorito and M0 are essentially the same thing, until we figure enough stuff out
cotto and how those parts interact with M0
dukeleto cotto: yes, i agree. I think we can start an M1 spec document now, and add stuff to it that we know we don't want in M0 05:31
cotto: it can be in the same PDD in another section
cotto wfm.
dukeleto, I wonder if we should just say that M0 implementations need to do some hard-coding of Contexts. 05:42
05:44 hercynium left
dukeleto cotto: please explain 05:47
05:47 minusnine_ joined
cotto dukeleto, I'm thinking about how to get out of the "turtles all the way down" problem where eventually, something needs to be hard-coded. 05:49
bacek_at_work guys, invoke_cc is wrong for M0. 06:00
It's better to be explicit on this level of what to invoke
E.g. "Subs are identified by :subid" 06:01
"invoke ctx, sub, continuation"
etc
otherwise will have same situation as now with "foo"("bar", "baz") in pir. 06:02
dukeleto bacek_at_work: i don't understand. Why shouldn't M0 have a invoke_cc ?
bacek_at_work cc stands for "current continuation" 06:03
which is some magical variable stored somewhere
E.g. interp->ctx->ccont
and invokecc now set it to -1. And then Sub.invoke allocate Continuation if ctx->ccont == -1 06:04
This is kind of magic we should avoid in M0.
otoh, it can be implemented in M1+
dukeleto bacek_at_work: we get the current interp by looking at the current context in lorito, not the other way around 06:05
bacek_at_work: LoritoContext PMC basically has everything that M0 needs 06:06
06:06 rurban_ joined
bacek_at_work dukeleto, it doesn't really matter. I want _explicit_ usage of everything on M0 level. 06:06
06:06 benabik left
dukeleto bacek_at_work: no global interp in M0 06:06
bacek_at_work dukeleto, replace interp->ctx->ccont with ctx->ccont.
dukeleto bacek_at_work: current context isn't a magic global 06:07
bacek_at_work it is
dukeleto bacek_at_work: there is an opcode to return the current context
bacek_at_work "current context" and "current continuation" are different :)
dukeleto bacek_at_work: yeah, i am conflating them a bit
bacek_at_work invoke_cc is invoke with current _continuation_
dukeleto bacek_at_work: isn't a context also a continuation ? 06:08
bacek_at_work dukeleto, I don't now. Maybe
cotto that's been part of the plan
bacek_at_work Can we have different "Continuations" for same context?
06:09 rurban left, rurban_ is now known as rurban
dukeleto bacek_at_work: we have a "new context" opcode 06:09
bacek_at_work: that is a good question
bacek_at_work dukeleto, yes. But it's new context, not new current context
dukeleto bacek_at_work: our current problem is "how do we do 'print 42' in M0 ?
cotto bacek_at_work, you mean like an exception handler or something more generic?
bacek_at_work yes, exception handlers are good example
"push_eh something". What is "something"? 06:10
How many "somethings" we allow per context?
cotto what about either a sub or a label 06:11
bacek_at_work "sub" is?
"label" is?
dukeleto bacek_at_work: currently, my LoritoContext is an invokable Context, with some extra junk
bacek_at_work dukeleto, it is one of the possible solutions. 06:13
dukeleto bacek_at_work: i am just trying to get the prototype to do something useful, so we can hone the spec 06:15
bacek_at_work: i know I am doing hacky things
bacek_at_work indeed :)
dukeleto bacek_at_work: but i just want to get some basic functionality so we can make sure the spec is implementable
bacek_at_work: ;)
bacek_at_work What if we split "invoke_cc" to Context.set_continuation + Context.invoke?
dukeleto bacek_at_work: i guess that is reasonable 06:16
bacek_at_work So, we can have something like:
$ctx = new_ctx 06:17
dukeleto bacek_at_work: i was assuming that every opcode gets passed the current context, in addition to 3 arguments
bacek_at_work set_sub $ctx, subid
set_cont $ctx, <offset>
invoke $ctx
dukeleto, we don't want to invoke current context
dukeleto bacek_at_work: sure, sounds fine to me. You want to update the m0-spec branch with that? 06:18
bacek_at_work: the most important thing right now is improving our spec 06:19
dalek rrot/m0-spec: af8ae5e | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add a runloop definition
rrot/m0-spec: 99d71f5 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add section for non-M0 topics
cotto If every op gets the current context, what about using that for i/o? 06:24
er, to determine what print prints to
bacek_at_work, the role of :write in src/vtable.tbl in gen_gc should be documented. 06:29
bacek_at_work cotto, go for it :)
cotto d'oh 06:30
bacek_at_work, can you think of someplace better than vtable.tbl? 06:34
bacek_at_work gs_gms.c also 06:35
cotto ok
dalek rrot/generational_gc: 6a76796 | cotto++ | src/ (2 files):
add some docs on :write
 06:38
ttbot Parrot 6a767962 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/8994 06:44
dalek rrot/generational_gc: dddb4ba | bacek++ | src/gc/gc_gms.c:
Revert "Small optimizations for is_foo_ptr."

Looks like it broke win32.
This reverts commit 1880c15da798dae10cde05af63cb74d2ec6135a8.		 06:47
cotto dukeleto, do you have any plans for yapc::na? 06:55
bacek_at_work Yay, green taptinder on ge_gc branch! 06:58
cotto good times
06:59 minusnine_ left 07:00 lateau joined
dalek rrot: 464fa68 | NotFound++ | src/ops/core (2 files):
delete unused variable ccont in get_results op
 07:12
rrot: b03561f | NotFound++ | src/extend.c:
initialize curctx in the catch part of Parrot_ext_try
 07:17
07:18 fperrad joined 07:26 jsut_ joined 07:31 jsut left
dalek rrot: 7055f69 | fperrad++ | runtime/parrot/library/distutils.pir:
[distutils] restore get_nqp (for compat)
 07:35
08:00 cosimo left
dukeleto cotto: yes, i plan on going to YAPC::NA, but haven't made tickets yet 08:32
cotto dukeleto, cool. What about? 08:33
dukeleto cotto: also planning on YAPC::EU as well. so many confs
cotto: you mean what talks will I submit?
cotto me too
yeah
pl/perl6, I'm sure 08:34
dukeleto i haven't given any talks about bioinformatics with open source tools
but yeah, PL/Perl6 and some parrot talks too :)
bioperl is pretty big
in terms of the number of scientists that depend on it
cotto I have a dim idea of that. 08:35
dukeleto i think parrot has a lot of potential in the bioinformatics world, because biologist don't give a shit about programming languages
they all re-implement the world in every dynamic language to do the same stuff
so the potential to use a ruby or perl module from PHP would be huge to them 08:36
they just want publications, and whatever is the fastest way to do that, that is what they will migrate to 08:37
moritz we need a new language, "biology paper generator", short bpg 08:38
dukeleto lulz 08:39
cotto There's no way I'm missing this years OS Bridge.
I have a good excuse for making that a priority, especially since I don't need to fly there.
dukeleto cotto: you shouldn't. It is usually the best conf I go to each year.
cotto even over yapc? 08:40
dukeleto cotto: i have actually never been to a YAPC
dukeleto has never been to a Perl conference, amazingly
cotto serious?
dukeleto cotto: dead serious.
cotto That's deeply surprising.
moritz very much liked the perl conferences he has attended so far
dukeleto Indeed. It surprises even me.
I was planning on YAPC::NA last year, but had to cancel. 08:41
cotto I'm excited to hit YAPC::EU this year. There's a good-sized batch of Rakudo folks who don't usually make it stateside. 08:43
"All" we need to do is have something to show for M0 and Lorito by then. 08:45
08:46 lucian joined
dukeleto slowly but surely. At least we have a spec now. 08:48
cotto Yes. and I'm motivated to beat it into something awesome.
dukeleto things are starting to come together
cotto: what kind of M0 ops do we need to interact with the runloop and pc ? 08:49
cotto what kind of interaction with the runloop are you thinking about?
dukeleto cotto: we could just have hard-coded indexes into the LoritoContext PMC do stuff
cotto if the PC is just another register we don't need anything special for it 08:50
dukeleto cotto: well i am thinking of incrementing the pc and exception handling in the runloop
08:50 theory left
dukeleto cotto: we can't be sure that a register won't get stomped on due to flying yaks 08:50
08:51 fperrad left
cotto If something's stomping on the PC, we've got issues. 08:51
dukeleto cotto: it needs to be in some kind of protected memory that is not accessible other than M0 ops
indeed, we do. I guess I am paranoid
cotto dukeleto, that sounds magical
dukeleto cotto: so, if I understand you, we say "the PC is always in $I42". But what happens when generated code assigns to $I42 ? Do we have lexical registers or something? 08:52
cotto: that is what I don't understand 08:53
cotto dukeleto, I'm thinking of the PC as being a special but otherwise unprotected register. 08:54
different from [INSP]\\d+ 08:55
We may be saying the same thing.
I'm thinking that add $PC, $PC, 43 or set $PC, $I2 would be valid 08:56
dukeleto cotto: ah, so you are saying that the PC is some kind of "symbolic register" ? 08:57
register means on of INSP in all our docs, so that is a bit confusing 08:58
but I see that we are talking about the same thing
cotto I like it when that happens.
yes
dukeleto cotto: how do we actually using the "$PC" from PIR ? 08:59
cotto: these lorito dynops will be used from PIR, at first
cotto: how do we actually use, rather
cotto dukeleto, Indirectly. goto X can be sugar around setting $PC, same as ops2c does with C. 09:00
dukeleto cotto: do we want an op to retrieve and set the PC ?
cotto PIR can be a little bit magical.
dukeleto cotto: an M0 op, that is.
cotto dukeleto, That brings up the question of how M0 ops will deal with registers. 09:01
dukeleto cotto: perhaps when we want a JIT, having an op to get/set the PC will be better for optimization?
cotto: yes. I assume we want set/get opcodes for each register type 09:02
cotto If an op is hard-coded to work with a certain register type, then we'd need separate instructions for dealing with the PC.
dukeleto i don't like that
cotto me neither 09:03
dukeleto and ops at M0 must be hard-coded per-register, for performance
we don't want unnecessary indirection at M0
cotto indirection is slightly magical 09:04
(and expensive when used in large quantities)
lucian cotto: i disagree with your terminology
dukeleto lucian: welcome 09:05
lucian: which terminology?
lucian "indirection is slightly magical"
i'd rather say "implicit indirection is slightly magical"
if it's explicit, it's just an explicit abstraction
cotto I need a better word than "magical". 09:06
lucian cotto: :)
dukeleto pony-like
cotto wfm
lucian, indirection is slightly pony-like
lucian cotto: much better :)
lucian apologises for the intrusion 09:07
dukeleto cotto: so the current context has an interp object in it, right ?
cotto lucian, I mean that indirection adds a little bit of complexity. M0 should be as simple as practical.
lucian it just sort of bugs me when people use "magic" for any abstraction
cotto lucian, no intrusion.
dukeleto cotto: we index into the interp object to modify the PC
cotto: and provide an M0 "opcode" that is really just sugar for that 09:08
cotto lucian, I'm always glad when people feel welcome to jump into a discussion.
dukeleto cotto: i sense that we will have "primitive" M0 ops and some "derived" M0 ops
cotto: in the sense that we could get by with only primitive M0 ops but for the sake of carpel-tunnel-syndrome, we provide some sugar 09:09
cotto dukeleto, we need a clear distinction between context and interp
dukeleto cotto: but generated code would never use the sugar
cotto: a context has a single interp. What more do you want?
cotto dukeleto, maybe
dukeleto cotto: such as "what happens when i create 2 interp objects?" 09:10
cotto: each context has a single interp which is the interp that the context was created with
cotto: other created interps are part of the list of PMCs that are alive in that context 09:11
cotto: make sense?
cotto dukeleto, what's the interp responsible for and what's the context responsible for?
lucian dukeleto: i still think there should only be primitive ops
then you get back to something like PIR
cotto that's what needs definition, especially since we're changing some of the assumptions that hold in Parrot now. 09:12
dukeleto lucian: yeah, we shall see. We can make something macro-like that is expanded before compile-time
lucian: i am just trying to save our poor wrists
lucian dukeleto: i may have made this point before, but the best way to save wrists is to use a higher level system language for parrot, like winxed or close
cotto dukeleto, It's a balance between not getting CTS and staying motivated to generate M0. 09:13
dukeleto cotto: everything always defers to the current context to do anything. The current context is the arbiter of all information
cotto lucian, absolutely.
I hope we eventually have a gc implemented mostly in nqp.
dukeleto cotto: i am not sure that will happen. Maybe after a JIT 09:14
cotto eventually
lucian cotto: i'm not sure that's feasible
cotto for now, definitely not
lucian like, ever
dukeleto cotto: NQP is just too slow for the GC, which needs to run all the time
cotto or some other hll
lucian cotto: i meant any HLL on top 09:15
dukeleto cotto: perhaps we can come up with DSL for the GC that compiles to C, that might be feasible
cotto: to make the code easier to understand and maintain
bacek ~~
cotto We'll see what becomes possible. For now, apologies for the distraction.
lucian if C is that problematic, you might want to use one of the many languages that compile to mostly readable C
dukeleto but one yak at a time.
cotto hio bacek
happy Friday 09:16
aloha, clock?
aloha cotto: LAX: Fri, 01:16 PST / CHI: Fri, 03:16 CST / NYC: Fri, 04:16 EST / UTC: Fri, 09:16 UTC / LON: Fri, 09:16 GMT / BER: Fri, 10:16 CET / TOK: Fri, 18:16 JST / SYD: Fri, 20:16 EST
bacek cotto, aloha
dukeleto bacek: happy beer drinking day
bacek dukeleto, it's exactly what I'm doing right now
seen mikehh
aloha mikehh was last seen in #perl6 5 hours 15 mins ago joining the channel.
cotto my $dayjob just got a new beer fridge. It'll be great.
bacek cotto, congratulations! :)
dukeleto lucian: i think you are right. only primitve ops in M0, evertying else is a macro 09:17
cotto Apparently you can put other things in there, but I'm not sure why you would.
dukeleto bacon
lucian dukeleto: or bootstrap Close/Winxed early and have no need for macros :)
dukeleto A fridge full of bacon and beer is a happy fridge indeed.
lucian actually, there isn't even any need for bootstrapping, since a parrot system language has no core types or stdlib
dukeleto lucian: sounds nice, but M0 will be in C for the time-being 09:18
lucian: definitely and interesting thing to experiment with, though
lucian dukeleto: sure, what i mean is that maybe you should avoid writing any M0 by hand. just like people almost never write java bytecode/ass
cotto For anyone reading xkcd, )
dukeleto lucian: sure, that is a fine idea 09:19
cotto You're welcome.
dukeleto lucian: i don't plan to write M0 by hand, but I have to write the C code implementation of M0 by hand :)
lucian dukeleto: sure, the implementation. but actual M0 code needn't be written by humans
dukeleto lucian: yes, i agree 09:20
bacek lucian, +1
cotto lucian, exactly
dukeleto i expect parrot devs will code in M1 which is transformed automagically to M0
lucian dukeleto: that i also disagree with, looking at PIR vs PASM
dukeleto not sure if that is at compile-time or run-time, yet 09:21
could be either
lucian: what do you agree with?
lucian dukeleto: writing in a higher level language
dukeleto lucian: that is the whole design of M0, M1, .. MN
lucian but i don't agree with this language being assembly-like
dukeleto lucian: each level is implemented in the previous level
lucian dukeleto: right, scheme
do you have this design written down somewhere? i may be missing something 09:23
cotto lucian, that's what the m0-spec branch is about. Other materials are rather dispersed. 09:24
lucian right. what i had hoped for parrot was to get rid of writing assembly (PIR) altogether, and just write winxed/close for *everything* above the C level 09:25
dukeleto cotto: is there an M0 op for selecting a runcore? or is that just an index into the interp object?
lucian: that is what we are calling M1
lucian dukeleto: ah, ok. sorry. i had assumed M1 was superset of M0, but otherwise still assembly 09:26
dukeleto lucian: PIR is just the first implementation for M0 and M1. We plan on having other, better languages to interact with M0 and M1 in the future
cotto dukeleto, I haven't thought about that.
dukeleto lucian: M0 and M1 are orthogonal to PIR
lucian dukeleto: ok
dukeleto lucian: currently, we are implementing M0 as C dynops
cotto M1 corresponds somewhat to where PIR lives now 09:27
dukeleto lucian: and using PIR to interact with them. But we could really choose any Parrot language to interact with M*
lucian dukeleto: right
dukeleto lucian: we are concentrating on the spec of M0 now
lucian sure, sorry i digressed 09:28
dukeleto lucian: and not worrying too much about M1 or the fact that we are using PIR
lucian i see
dukeleto lucian: no worries, these are good questions
lucian so you're trying to move away from PIR by changing the backend from under it
cotto I had pictured the runcore living below M0 (i.e. the runcore implements M0). 09:29
dukeleto cotto: i don't parse that
cotto: we need to know our runcore to execute bytecode
cotto: which is what happens after we increment the PC, iirc
cotto dukeleto, the runcore is what executes bytecode. You give it a PC and it knows what to do. 09:30
(this is how I see the world, not necessarily how it is) 09:31
dukeleto cotto: how do you give the runcore the PC from M0? I am not seeing it.
cotto The PC is a register that the runcore knows to look at in order to determine which op to execute. 09:32
bacek Guys.
dukeleto Gals.
bacek Treat every op as sub program.
dukeleto bacek: explain a bit more 09:33
bacek Then execution of of is "Context.invoke(op, pc+2)
if Context is continuation
then PC is just where it's point to
dukeleto bacek: that is the plan
bacek Than we don't need separate handling (logically) of m0 ops 09:34
So, execution of _current_ op is equal to Context.invoke(op_sub, pc+1) 09:35
09:36 lucian left
bacek call of real sub is "$P0 = <fiind_sub_some_how>; $P1 = new_ctx; $P1.invoke($P0, pc + 1)" 09:36
even better 09:37
(partially joking)
Subs are indexed. In something like "ExecutionUnit" (similar to packfile) 09:38
M0 ops have indexes [0...N]
Other subs (including M1 ops) numbered [N+1...M]
Runloop become trivial 09:39
mikehh bacek: you was lookin' fo me
bacek mikehh, can you retest gen_gc? 09:40
dukeleto bacek: shouldn't that be current_ctx ?
cotto I really need to sleep. Please add any ideas to m0-spec. 09:41
'night
bacek dukeleto, yes.
dukeleto cotto: take it easy
bacek cotto, night
dukeleto was right for once!
bacek: why do we want to pass the pc to invoke? 09:42
bacek: seems like it should know how to get it
bacek dukeleto, goto
dukeleto bacek: GET_ATTR_ADDRESS in Continuation PMC gets the PC 09:43
bacek dukeleto, we are passing _next_ address 09:44
mikehh bacek: sure, looked ok about 8 hours ago
dukeleto bacek: ah, yes
bacek mikehh, I did small fix. It was some failures on amd64
mikehh, what about merging it for 3.1? :)
mikehh bacek: had 1 failure on rakudo on amd64/none on rakudo i386 09:45
bacek mikehh, gc-leaky?
dalek rrot: d5a6bc6 | (Gerd Pokorra)++ | NEWS:
add a news about NQP
 09:46
mikehh bacek: bumped to 4e7 but failed on 2e7 on both
bacek: did not commit it though 09:47
bacek mikehh, I think it's safe to commit. We can put check into loop to exit it early.
mikehh bacek: we need to incorporate a check for available memory, what if someone had 12GB or more 09:50
bacek: and tune it on that basis 09:51
bacek: anyway I will run some tests now (on amd64 at the moment) 09:52
dukeleto bacek: i have a darwin/x86 smoker on gen_gc running now 09:54
09:58 contingencyplan left 10:03 cotto left
dalek rrot/generational_gc: 2d0471f | bacek++ | t/op/gc-leaky- (2 files):
Made tests more tolerant to big amount of available memory
 10:06
bacek mikehh, latest commit into branch should solve it 10:07
dalek rrot/lorito: 246f4f3 | dukeleto++ | / (2 files):
Improve LoritoContext init and tests
 10:08
mikehh bacek: had started testing, but will stat again 10:11
start
bacek mikehh, it's just t/op/gc-leaky-*.t
amd64/c++?
mikehh bacek: yes 10:12
bacek mikehh, good.
seen kid51 10:13
aloha kid51 was last seen in #parrot 6 hours 12 mins ago saying "make: *** [runtime/parrot/library/YAML/Tiny.pir] Error 134".
bacek msg kid51 Can you retest gen_gc? I hope this bug is fixed.
aloha OK. I'll deliver the message.
10:17 mtk left
dalek rrot/generational_gc: 8669daa | bacek++ | src/gc/gc_gms.c:
Remove c++-commented code.
 10:23
rrot/generational_gc: 5244700 | bacek++ | src/ (2 files):
Remove c++-comment. Put normal comment instead and made code more obvious about semantics
mikehh bacek: ok that seems to work - make corevm/make coretest PASS, but, api_t_test.pir is still not removed
10:24 mtk joined
bacek mikehh, I didn't touch this test at all in branch. 10:24
I think it's from whiteknight's api branch 10:25
ttbot Parrot 5244700f i386-freebsd-64int make error tt.taptinder.org/cmdinfo/9160 10:26
dalek rrot/generational_gc: 5eec12f | bacek++ | src/string/api.c:
Restore previous behaviour of setting GC flags in str_copy.
 10:29
mikehh bacek: t/src/embed/api.t has an extra line comparing to master 10:32
bacek mikehh, git diff master -- t/src/embed/api.t doesn't give anything... 10:34
mikehh, may be you have POSTMORTEM environment variable set (or how it's called)? 10:36
no
this file is actually handled wrong in test
but it should be same in master 10:37
nopaste "mikehh" at 192.168.1.3 pasted "git diff master -- t/src/embed/api.t" (15 lines) at nopaste.snit.ch/31331 10:40
mikehh bacek: does for me see nopaste - nopaste.snit.ch/31331 10:41
bacek mikehh, ah 10:42
it was fixed in master recently
Test was added on 7th
Let me merge master to branch
mikehh bacek: ok once done will build and run to fulltest and test rakudo 10:44
bacek mikehh, ok, thanks!
dalek rrot/generational_gc: 0c03f7e | bacek++ | / (9 files):
Merge branch 'master' into generational_gc
 10:46
bacek mikehh, pushed
mikehh bacek: building and testin' now 10:48
bacek dukeleto, how is your testing on Darwin? 10:52
dalek rrot/generational_gc: 8802115 | mikehh++ | src/pmc.c:
fix codetest failure - trailing space
 10:58
mikehh bacek: codetest now PASSes 11:02
bacek mikehh, hooray!
Merge party? Or wait until after 3.1?
tadzik :)
s/party/madness/ 11:10
bacek tadzik, not at all. Diff with master is quite small :) 11:13
tadzik :) 11:15
well, thursday, friday, little difference :)
11:16 lateau left
tadzik Your branch is behind 'origin/master' by 879 commits, and can be fast-forwarded. 11:17
/o\\
bacek go-go-go!!! :) 11:18
11:27 woosley joined
mikehh bacek: all tests PASS up to fulltest - Kubuntu 10.10 amd64 (g++-4.5) 11:28
bacek mikehh, excellent!
mikehh bacek: now for with --optimize and rakudo
bacek little bit nervous :) 11:29
tadzik ;)
tadzik taps bacek's back
Everything's gonna be alright ;)
bacek of course!
I've got 3 more beers to fix everything.
11:30 fperrad joined 11:44 adu joined 11:50 darbelo joined, clunker3_ joined 11:53 clunker3 joined 11:54 clunker3_ left
mikehh generational_gc branch: 11:57
All tests PASS (pre/post-config, make corevm/make coretest, smoke (#8971) fulltest) at 3_0_0-886-g8802115 - Kubuntu 10.10 amd64 (g++-4.5 with --optimize)
11:58 adu left
mikehh bacek: rakudo date && time make -j -> real 5m42.895s, user 6m55.790s, sys 0m6.460s 12:04
vs last build on master -> real 8m15.501s, user 10m1.750s, sys 0m5.180s
bacek: running spectest_smolder now 12:07
12:10 eternaleye joined 12:15 adu joined 12:17 clunker3 left 12:18 clunker3 joined
mikehh bacek: rakudo alltests PASS - spectest_smolder #8982 12:32
bacek mikehh, hooray! 12:33
mikehh bacek: merge it - we can fix any bugs over the weekend
bacek As you wish! :)
dalek rrot: 2d0471f | bacek++ | t/op/gc-leaky- (2 files):
Made tests more tolerant to big amount of available memory
 12:36
rrot: 8669daa | bacek++ | src/gc/gc_gms.c:
Remove c++-commented code.
rrot: 5244700 | bacek++ | src/ (2 files):
Remove c++-comment. Put normal comment instead and made code more obvious about semantics
rrot: 5eec12f | bacek++ | src/string/api.c:
Restore previous behaviour of setting GC flags in str_copy.
bacek hmmm....
dalek rrot: 0c03f7e | bacek++ | / (9 files):
Merge branch 'master' into generational_gc
rrot: 8802115 | mikehh++ | src/pmc.c:
fix codetest failure - trailing space
rrot: b55f22f | bacek++ | / (44 files):
Generational GC enters the building. Merge generational_gc branch
bacek mikehh, done-done 12:38
12:39 adu left
mikehh bacek: winxed also builds and PASSes tests 12:40
12:41 clunker3 left
mikehh bacek: will check out master and tests and then on i386 12:41
bacek mikehh, ok, thanks!
It's bed time for me now. 12:42
G'Night, folks
mikehh bacek++
12:42 clunker3 joined
dalek umage: d6ce79d | darbelo++ | setup.pir:
Update setup.pir to use get_nqp_rx() instead of get_nqp(). Needed after parrot commit 0617415a.
 12:45
12:46 bluescreen joined
dalek p: 7387a66 | bacek++ | src/metamodel/reprs/P6opaque.c:
Insert write barrier after compute of allocation strategy.
 13:26
TT #2005 created by jkeenan++: Parrot no longer builds on Darwin/PPC
TT #2005: trac.parrot.org/parrot/ticket/2005
13:30 whiteknight joined
whiteknight bacek++ 13:31
...and, good morning #parrot
bacek whiteknight, can you join #perl6? masak have some problems with gen_gc. And I'm almost felt asleep 13:34
mikehh bacek: can you check TT #2005, I will understand if you need sleep first 13:38
bacek mikehh, ouch... 13:40
seen kid51
clunker3 kid51 was last seen on #toolchain 5 months, 12 days, 13 hours, 30 minutes and 8 seconds ago, saying: So today is 29 Aug. Which germans broke what?
aloha kid51 was last seen in #parrot 9 hours 40 mins ago saying "make: *** [runtime/parrot/library/YAML/Tiny.pir] Error 134".
whiteknight that quote is hilarious
Coke bacek++ 13:47
bacek Coke, not yet. 13:48
whiteknight msg cotto_work any preference on what function naming should be for src/interp/*? I need to add at least one new function in there for the IMCC branch, and I'll be damned if I'm not going to use a proper name for it 13:50
aloha OK. I'll deliver the message.
13:53 fperrad_ joined, fperrad left
Coke bacek++ #don't you tell me what to do! 13:53
13:53 fperrad_ is now known as fperrad 13:56 clunker3 left, clunker3_ joined
Coke tries to build partcl after months of neglect. 14:02
whiteknight I sense much fail in your future
I feel a great disturbance in the force, as if many trac tickets were suddenly created and then assigned to me 14:03
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#9001) fulltest) at 3_0_0-887-gb55f22f - Kubuntu 10.10 amd64 (g++-4.5) 14:04
mikehh got to go out for a bit 14:06
14:06 rurban_ joined
mikehh will test on Ubuntu i386 when I get back 14:06
14:06 mikehh left
dalek rrot: 77b57cc | bacek++ | include/parrot/gc_api.h:
Disable shortcutting of mark_PMC_alive. It's needed for calculating of youngest child.
 14:06
14:09 rurban left, rurban_ is now known as rurban 14:13 plobsing left
Coke looks like one of the changes is in dealing with named function params. 14:27
whiteknight yeah, there was a special case for a while where we weren't doing error checking on named parameters in certain situations. We removed the special case 14:28
I don't remember what it was or why, but I know it's gone
Coke good night, magical coding robot. 14:29
14:30 mikehh joined
Hackbinary good afternoon #parrot 14:32
mikehh hay Hackbinary 14:33
Hackbinary: it was mentioned somewhere that you are in Scotland
Hackbinary it's true 14:34
I'm in Edinburgh
mikehh I am in Aderdeen
bacek night humans
Hackbinary g'night bacek
mikehh cheers bacek
Hackbinary Aberdeen is the only large city in Scotland that I haven't been to yet 14:35
mikehh Hackbinary: whatcha ya doin' in Edinburgh 14:36
Hackbinary right now, looking for work
:( 14:37
mikehh ah, sad way to spend time
Hackbinary yah it's not the best
what you doing in aberdeen? 14:39
mikehh generally I work from home, doing various development for clients, none actually here in Aberdeen 14:40
in fact only one client in Scotland at the moment. 14:42
Hackbinary perlish type stuff? 14:43
mikehh Linux based usually, c++, c, perl and others, some Web type stuff as well, I also do sys admin for a couple of websites, although how I got into that I have no idea 14:45
mikehh fresh out of milk and other things, really need to get some stuff - bbl 14:50
Hackbinary okay, see you in awhile 14:57
dalek TT #2006 created by masak++: Problem compiling Rakudo's Test.pm on Debian x64 15:04
TT #2006: trac.parrot.org/parrot/ticket/2006
15:04 benabik joined
whiteknight yay! I think I just fixed a large number of the test failures in the imcc branch 15:05
I wish Parrot's test harness would give a final count of number of test failures, so I could compare progress quickly 15:08
Coke isn't that a function of whatever perl test harness we're using? 15:10
15:14 rurban_ joined, cotto joined
whiteknight Coke: yeah, I don't know the details 15:16
I seem to remember seeing a short totals summary table at one point, but it isn't there now 15:17
15:19 rurban left, rurban_ is now known as rurban, lateau joined 15:25 theory joined 15:27 woosley left 15:28 Andy joined
cotto_work ~~ 15:40
darbelo ~~ 15:41
15:42 plobsing joined
whiteknight on the bright side, I think fixing all the test failures in my imcc branch is going to require me to completely rip out the hack-job homebrew exception handling that IMCC uses 15:42
atrodo That's a good thing, right? 15:43
cotto_work whiteknight: that will the new function do? 15:44
whiteknight cotto_work: Get an Interp* from a ParrotInterpreter PMC, without having an Interp* around already for calling vtables
necessary for the API 15:45
cotto_work I can see where you might want to do that.
What name were you thinking? Also, how would that work? You need an Interp* before you can do anything. 15:48
whiteknight in the branch now, I'm calling it "Parrot_int_get_interp_something_something_something" 15:50
I don't remember what I called it
the API renaming page on the wiki says "Parrot_int_*", but clearly no functions in that folder follow that naming scheme
15:50 contingencyplan joined
cotto_work "int"? 15:50
do not want
That's too ambiguous. "int" has a very different meaning from "interp". 15:51
imcc_interp_code branch? 15:52
I don't see "Parrot_int_*" in either imcc_ branch. 15:54
whiteknight cotto_work: the whiteknight/imcc_compreg_pmc branch. I haven't pushed this change yet 15:56
what would you prefer, Parrot_interp_*?
I ask because there is no prior art here, so we can pick whatever we want and get it right 15:57
cotto_work I'd prefer Parrot_interp_*. Names don't need to be artificially short if it hurts readability.
We have modern compilers. They can deal with long function names. 15:58
whiteknight that's true, but at the same time we start ending up with unnecessarily large prefixes on function names
15:58 PerlJam left
whiteknight Parrot_interp_ is fine 15:58
15:58 PerlJam joined
cotto_work wfm 16:01
Hackbinary hello everyone, the smolder server for cardinal doesn't seem to work anymore, has it been migrated? 16:11
smolder.plusthree.com/app/public_pr...reports/16
darbelo Hackbinary: check smolder.parrot.org 16:12
Hackbinary I don't see cardinal on there? 16:15
cotto_work I love the gen_gc branch, but I'm not thrilled that it was merged into master without even a mention at #ps. 16:16
16:17 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner
plobsing gen_gc got merged? 16:18
cotto_work especially since it's clear that nqp didn't get sufficient testing
plobsing: yes
plobsing this close to a release? when there were still hacky workarounds? 16:19
are we insane?
cotto_work It's also a violation of our support policy since some languages may need to add write barriers. 16:20
plobsing sure, there were significant speedups in some very common use cases, but I am 99% sure I can find a case where the ctx-dirty/register workaround makes things notably slower
Coke bacek got approval from the release manager. Also, I hear we have the ability to undo things. ;) 16:21
cotto_work I saw that, but this is more than a feature addition.
Coke speedups in the common case but slowdowns in uncommon cases is not a reason not to merge. (the write barriers might be.) - but in that case, cotto, the merge will have to wait 2 more months. (not arguing, just pointing out.) 16:22
whiteknight we do not want to wait 2 months on this
2 weeks, there's an argument to be made. 2 months is out of the question
cotto_work whiteknight: I agree, but this was too fast.
Coke I suspect just after the release with a big note in the news saying "Sorry, but this is really worth it" (re: the write barriers changes) is a good compromise. 16:23
cotto_work Coke: that would have been preferable.
Coke especially since you we can leave the macros in master even if we rollback the code. 16:24
cotto_work yes
Coke cotto_work: so make it work that way. the release hasn't happened yet.
cotto_work Coke: indeed 16:25
dukeleto: ping
plobsing Coke: the "uncommon" case is more common than you think. Every register access is slower. 16:26
darbelo Ouch.
whiteknight plobsing: what's the story there? I wasn't aware of a slowdown on register accesses
plobsing look at REG_INT
it used to be, in optimized builds, registers were accessed through a couple of pointer dereferences and an array lookup. 16:27
Coke plobsing: I took you at your word when you said uncommon.
that sounds like it might actually be what we call common.
plobsing with gen_gc, that meant that the ctx could be updated without marking it dirty. the workaround was to always go through accessor functions (which we already had for debug builds), which marked the ctx. 16:28
these accessor functions are in a separate file and not inlinable
whiteknight that does sound like something we could optimize in-place 16:29
NotFound Marking int registers?
plobsing the *correct* solution is to get ops2c to generate different code for accesses that could actually make the CTX dirty (either call the accessors or WB inplace)
whiteknight plobsing: right, I thought it was agreed yesterday to do that very thing? 16:30
plobsing 90% of register accesses are not this
whiteknight: there was a sense that this should be done. my opinion is that should have happened before the merge.
whiteknight we know that gen_gc brings about a 25% speedup to Rakudo in most tests. reverting that because there is a slowdown on certain accesses hardly seems prudent 16:31
Either we revert the gen_gc merge now because it has problems, or we stick with it and use it as the new basis for future optimizations
at least, that 25% number is what I have been told. I haven't done the testing myself 16:32
plobsing my concern is that this regression never gets adressed
Coke well, if it stays in master, step 1: open a ticket so it doesn't get lost. 16:33
whiteknight how hard would it be to address it? I've never monkeyed around in ops2c, but I can't imagine it's uber-difficult to generate different accessors
Coke (or as soon as it gets back in master.)
cotto_work whiteknight: it depends on how accustomed you are to nqp. 16:34
plobsing whiteknight: my past attempts at modifications to ops2c have resulted in nothing but frustration. IMHO, it is a ball of spaghetti Perl 5 which was ported to NQP nearly verbatim. I have no desire to touch it again. 16:35
NotFound Also, while doing that it will be good to get rid of generating the current context var in ops that doesn't use it.
whiteknight NotFound: yes, that is another good optimization
cotto_work I'm still on the fence about reverting the merge. 16:36
NotFound Alternative approach: create a branch from a point before the merge and cut the release from it. 16:37
cotto_work NotFound: I like that idea if mikehh feels comfortable enough with git to do it. 16:38
whiteknight if the merge causes a problem, that's not a bad idea
I wish we weren't having this conversation while bacek was sleeping 16:39
cotto_work Awesome. Take a look at support_policy.pod and look for "<<<<<<<". 16:41
fixing now 16:42
Coke SWEET
most awesome that it's from our git master. ;)
NotFound And none of the alternatives is correct. 16:44
dalek rrot: ad9c8a0 | cotto++ | docs/project/support_policy.pod:
fix some unresolved conflicts from deprecations as data
NotFound cotto_work: Isn't api.yaml now? 16:45
Coke misses the diffs-in-email.
cotto_work d'oh 16:46
dalek rrot: cd7619c | cotto++ | docs/project/support_policy.pod:
refer to the right file
NotFound TODO: add a test that verify docs refered to in pod do exists. 16:47
cotto_work NotFound: are you volunteering? 16:48
NotFound whistles
nopaste "coke" at 192.168.1.3 pasted "segfault in partcl." (3 lines) at nopaste.snit.ch/31363 16:52
16:52 bluescreen left
cotto_work Coke: is that new since the gen_gc merge? 16:53
Coke cotto_work: partcl has been so broken for so long I have no idea how long it's been there. 16:54
trying to get it back to passing again as time permits.
bisecting to identify changes is, IME, useless, so I won't volunteer it.
dalek rtcl-nqp: 9b45b77 | coke++ | build/PARROT_REVISION:
lie so we can build with latest parrot
 16:55
rtcl-nqp: 34a4df4 | coke++ | src/Partcl/commands/time.pm:
Avoid "TclString doesn't have set_string_native" error.

this avoids it. :(
rtcl-nqp: d0fa4e9 | coke++ | src/Partcl/commands/string.pm:
parrot now complains about this extra arg
Coke happy to provide backtrace, etc. 16:56
Hackbinary notfound / cotto_work, I'm happy to work on some of the documentation 16:57
nopaste "coke" at 192.168.1.3 pasted "2 segfaults..." (11 lines) at nopaste.snit.ch/31366 16:59
whiteknight awesome 17:01
cotto_work Hackbinary: thanks. The idea is to make sure that anything in F<...> in Pod is a real file. You could probably copy/modify t/codingstd/pod_syntax.t as a starting point.
whiteknight Hackbinary: send in a CLA 17:02
plobsing for a tangible example of the slowdown I complained about earlier, examples/pir/md5sum.pir /usr/lib/libc.a went from ~3.25s to ~7.75 seconds for me
whiteknight plobsing: okay, that is pretty substantial 17:03
plobsing I'd say. heavy math getting >2x slower is not acceptable IMO.
cotto_work aloha: clock?
aloha cotto_work: LAX: Fri, 09:03 PST / CHI: Fri, 11:03 CST / NYC: Fri, 12:03 EST / UTC: Fri, 17:03 UTC / LON: Fri, 17:03 GMT / BER: Fri, 18:03 CET / TOK: Sat, 02:03 JST / SYD: Sat, 04:03 EST
atrodo cotto_work> github.com/atrodo/parrot/blob/m0-s...d32_m0.pod
cotto_work plobsing: how many cases like that do you expect there to be? 17:05
17:05 dip left
cotto_work atrodo: I gauss I cant spel 17:06
Hackbinary www.parrot.org/files/parrot_cla.pdf --> 404
atrodo cotto_work> ? 17:07
plobsing cotto_work: I expect nearly anything that isn't PCT-based to suffer. This is an example chosen to highlight the issue, so the magnitude of the slowdown experienced in the average case will likely be less.
NotFound plobsing: you mean winxed, for example? 17:08
cotto_work atrodo: nm. I didn't realize which parts were yours.
NotFound: there's an easy way to find out.
plobsing NotFound: certainly some code written in winxed could suffer from the issue. Not sure about the compiler. How much garbage does it churn through?
NotFound cotto_work: yes, but I'm short of time right now, I should be on the road now. 17:09
plobsing I use PCT-based as a first-order approximation for "generates a lot of garbage"
cotto_work NotFound: ok
plobsing I also see a slowdown on examples/hexdump.winxed 17:14
cotto_work seen mikehh 17:15
clunker3_ mikehh was last seen on #parrot 2 hours, 29 minutes and 59 seconds ago, saying: Linux based usually, c++, c, perl and others, some Web type stuff as well, I also do sys admin for a couple of websites, although how I got into that I have no idea
aloha mikehh was last seen in #parrot 2 hours 30 mins ago saying "Linux based usually, c++, c, perl and others, some Web type stuff as well, I also do sys admin for a couple of websites, although how I got into that I have no idea".
cotto_work msg mikehh It's becoming clear that gen_gc was merged too early and without enough discussion and testing. Are you comfortable making a branch from before the merge and cutting the release from that? 17:16
aloha OK. I'll deliver the message.
17:17 dmalcolm joined
cotto_work I'm leaning toward either that or reverting and re-merging after the release. 17:19
whiteknight the two options are basically equivalent 17:20
creating a new branch from before the merge saves the effort of unmerging
17:25 bluescreen joined
mikehh cotto_work: if necessary - however I wass testing the branch and we got it passing everything as well as rakudo and winxed 17:27
cotto_work mikehh: yes but there are performance concerns 17:28
It's much faster for Rakudo but slower for other kinds of programs.
mikehh possibly, but it builds rakudo much faster, spectest did not take much longer 17:29
cotto_work It also was merged without much discussion, which is bad because it breaks our support policy.
mikehh we can optimize it a lot, however I have never been too happy with the gc, this has much better potential 17:30
that is probably my fault (merging that is) because we got everything passing and rakudo works with it 17:31
in what way does it breask the support policy - gc is internal? 17:33
break
cotto_work mikehh: some HLLs need to add write barriers to some VTABLE slots. 17:34
mikehh really, which working ones?
Coke rakudo
cotto_work Rakudo at least, possibly nqp
mikehh tested that - spectest smolder passes 17:35
Coke obviously, rakudo is already fixed, there, but if our main language needed it...
cotto_work mikehh: that's because bacek gave them a patch
mikehh sure I saw it 17:36
everything was passing (on parrot) before the merge, so I can probably pick it up there if absolutely necessary 17:39
I was hoping to test everything over the weekend, with some help of course, and fix any outstanding bugs 17:43
there is a lot of room for optimization in gen_gc as it stands, but that can come over the course of the next couple of months 17:45
plobsing gen_gc is a good idea. the problem is it isn't ready yet. this is experienced in the form of large performance regressions. 17:46
mikehh I don't really want to go forward with the old gc and wait until 3.3 or 3.6 to put it in
cotto_work mikehh: I'm not suggesting that. I'm just saying 3.1 is too soon.
mikehh cotto_work: it's probably your decision, but I don't really agree with that 17:47
cotto_work We can occasionally go against our support policy if we believe that the trade-off will benefit users, but I never want that to happen without some discussion at a #ps.
My preference would be to merge shortly after 3.1 (or cut 3.1 from a pre-merge branch) and optimize from there, along with adding a proper deprecation notice. 17:48
17:48 ryan joined
mikehh cotto_work: I thought we had agreed to put it in as soon as possiblky, I could be wrong though 17:48
17:51 chromatic joined
chromatic How about fixing the non-PMC register accesses instead of reverting everything? 17:52
See include/parrot/context.h line 35.
mikehh chromatic: good idea
cotto_work also an option if we can make it work within the next day or so
mikehh I'll create a branch from just before the mergem just in case 17:53
chromatic Let me try something quick.
cotto_work mikehh: thanks
Coke (releasing from branch) this may also mess up rakudo, temporarily. not sure how smart their configure.pl script is yet. 18:01
nopaste "chromatic" at 192.168.1.3 pasted "Re-enable register access optimizations" (41 lines) at nopaste.snit.ch/31376
plobsing chromatic: also need WB on string registers 18:02
chromatic Really? Should be easy to add.
plobsing true. just pointing it out.
chromatic I don't have time at the moment; anyone who wants to take over is welcome to do so. 18:03
18:04 mtk left
chromatic All of the core tests did pass for me, FWIW. 18:05
18:06 chromatic left
plobsing the problem is that the corner-case is very small. it is quite likely the core tests don't show the problem 18:06
Coke it is hard to not break things we have no tests for. 18:07
plobsing I'm trying to come up with something that demos it. 18:09
Coke \\o/
Hackbinary whiteknight, where should I send in the cla? and do you need a scan of page 2 as well? 18:10
cotto_work Hackbinary: you can scan and email if you prefer. 18:11
Coke Hackbinary: parrot.org/foundation should have details
whiteknight Hackbinary: both pages. Address and fax number should be on the CLA itself I think
18:11 mtk joined
Hackbinary sorry, I need an email address 18:11
i'm blind, legal@ 18:12
okay, I've sent in page 1 and page 3; if you need me to send in page 2, just let me know. (There was nothing to fill in on page 2) 18:16
=) 18:17
18:27 minusnine_ joined
dukeleto ~~ 18:28
cotto_work good morning, dukeleto 18:29
dukeleto why was gen_gc merged to master? 18:30
cotto_work: mornin'
cotto_work dukeleto: welcome to the madhouse
It shouldn't have been.
dukeleto we didn't do any benchmarking
18:31 lateau left
dukeleto running rakudo spectest and looking at build times is not the same as doing real run-time benchmarking of various nontrivial stuff 18:32
cotto_work plobsing pointed out that there are cases that are substantially slower due to the write barrier 18:34
they can be improved, but it was the first I've heard of those cases 18:35
dukeleto so we need benchmarks that constantly modify many long-lived PMCs 18:37
cotto_work dukeleto: the md5sum test is slowed down measurably
the PMCs don't need to be long-lived
18:39 lateau joined
cotto_work (according to plobsing. I haven't tested it myself.) 18:39
plobsing you just need to do more work with registers than is made up for by GC churn. PCC generates considerable churn, so any "well factored" code improves, whereas more straightforward imperative code suffers
dukeleto cotto_work: how much has md5 slowed down? 18:40
plobsing dukeleto: >2x
on large files
dukeleto so, do we want generational_gc to stay merged? Do we care about un-even performance changes in a dev release? 18:45
This does not bode well: trac.parrot.org/parrot/ticket/2006
I don't think this branch merge followed the merge guidelines
cotto_work stupid inability to join #perl6 18:46
18:46 lateau_ joined
dukeleto cotto_work: what irc client are you using? 18:47
cotto_work xchat
2.8.8
dukeleto something is borked
cotto_work clearly
plobsing dukeleto: I wouldn't be averse to uneven performance if it were *discussed* beforehand. but this is a result of a quick *hack* to get gms working. there is a correct solution, which I feel should have been implemented *before* gen_gc was mereged.
cotto_work plobsing: that's a big part of my problem with the way this merge was done too. 18:48
dukeleto We have github.com/parrot/parrot/blob/mast...elines.pod for a reason. 18:49
plobsing also note that before, we were only 100 times worse than C for md5 (on my system), which is nothing to scoff at. now we're between 200 and 250 times worse.
dukeleto Performance characteristics 18:50
How does your branch affect performance on our selected benchmarks? For hosted languages? Does it have memory leaks? Does it affect memory use or startup time? We have traditionally let these questions go unanswered, but we can be more disciplined here.
generational_gc did not get enough testing for these things
i expected it to get merged just after 3.1, and then it would have a month for tuning 18:51
merging a huge branch a few days before a release is bad ju-ju
plobsing what does "selected benchmark" mean? does that mean only the benchmarks which the branch targets or all parrot benchmarks? the use of only the former is what caused this regression to go unnoticed. 18:52
dukeleto plobsing: we need very specific guidelines, such as "these 10 benchmark programs must not show regressions" or something like that 18:53
that is how we can move forward, instead of in circles
We keep going in circles of performance. Tweaking, tuning, failing to test, making it waaaay slower, then rinse and repeat.
moritz real programs > benchmarks
dukeleto moritz: real benchmarks :) 18:54
plobsing moritz: md5 is a real program
dukeleto plobsing: can you send a quick email to parrot-dev about exactly how you ran the md5 benchmarks and what you found? 18:55
plobsing dukeleto: I don't think a fixed set of benchmarks is necessarily a good choice. I selected this benchmark because I already "knew" about the potential for regression using common sense.
dukeleto: sure thing 18:56
dukeleto plobsing: having no gauntlet of benchmarks to test stuff against is worse, in my opinion
whiteknight okay, let's come up with a plan right now. Based on what we are seeing, I suggest the generational_gc should not be in the release branch
dukeleto plobsing: sure, our gauntlet could be found to be not good enough, but then we add things to the guantlet
cotto_work whiteknight: +1
whiteknight I don't think we can do enough testing and benchmarking between now and tuesday, along with the necessary tweaking and tuning
dukeleto whiteknight: +1 18:57
whiteknight so we can unmerge it, or we can take a new branch as the basis for 3.2 and keep master "dirty" with gen_gc
I don't care which strategy is used
dukeleto whiteknight: let me suggest an easier way
whiteknight dukeleto: you have the floor
dukeleto whiteknight: create a new branch from where master is right now. gen_gc2 or whatever
whiteknight: then, go back to the commit before gen_gc was merged, and branch from there 18:58
whiteknight: call that new_master or something
whiteknight: then merge new_master into master, which should wipe out the gen_gc merge, 18:59
and then we still have the gen_gc2 branch pointed at what is master right now
i am not sure if other stuff has been added to master since the gen_gc merge. I assume not much.
whiteknight that's fine. Like I said, I don't care about the mechanism, only the fact that the release-making branch does not include generational_gc 19:00
whoever fixes it first gets to pick how it gets fixed
dukeleto joy to the world.
works for me, that is just one possible way to skin that yak
whiteknight that said, we *need* generational_gc in some capacity. The performance benefits to Rakudo are not ignorable
dukeleto whiteknight: rakudo already bumped their parrot_revision to get gen_gc, so this needs coordination with them 19:01
whiteknight so we should immediately start new work (possibly a new branch) to start properly addressing the write-barrier nonsense
cotto_work whiteknight: I absolutely agree. It just wasn't merged with due diligence.
dukeleto moritz: what are your thoughts?
whiteknight that means we need to identify (or create) some key benchmarks that show different aspects of the performance changes
dukeleto the md5 and sha examples are probably pretty decent benchmarks. We obviously need more, though. 19:02
whiteknight the MD5 one is probably a great candidate. We do need things that are garbage hungry to emulate PCT and NQP applications
everything in the middle
dukeleto we need benchmarks written in NQP
whiteknight that should definitely be a set of them, yes 19:03
19:04 lateau_ left
whiteknight Okay, action list. I'm going to start spitting out steps. Speak up if you want to volunteer for them: 19:04
19:04 [hudnix] left
whiteknight 1) Unmerge/move generational_gc 19:04
2) identify benchmarks that demonstrate the performance changes (both good and bad)
3) Start working on a way to make register accesses cheaper 19:05
any takers?
19:05 lucian joined
moritz dukeleto: I don't really care; we won't base a Star release on this parrot + rakudo 19:06
I too was surprised at the early merge
19:07 minusnine_ left, hudnix joined, lateau_ joined
lucian i was thinking whether java could possibly be coaxed into being a parrot system language/ jikesrvm.org/MMTk 19:08
mikehh I think bacek and I were both a bit tired and we all the tests to pass and rakudo and winxed I said go ahead and merge it
we got all
and rakudo built a lot quicker 19:09
whiteknight mikehh: that's fine. Like I said, we do want this
we just want to make sure it's right, and with some effort it can be right
plobsing lucian: Java is coaxable to be a Parrot system language, sure. But just try to get most Parrot developers to spend their volunteer time writing Java. 19:10
lucian plobsing: well, they wouldn't have to. it would only be useful if it was compatible with existing java code 19:11
plobsing lucian: there was even a paper written about integrating Jikes w/ Parrot. Not sure how far they went.
lucian: Java-the-language is fairly easy. It is Java-the-kitchen-sink which is tricky. And yes, I've looked at GNU Classpath
lucian plobsing: i'll look for that paper. at least jikes doesn't assume the kitchen sink 19:12
19:13 lateau_ left
lucian plobsing: i think classpath is reasonably tame in that the VM-specific bit is small. classpath itself is a bit crap, though 19:14
plobsing lucian: the main issue highlighted by classpath is incremental implementation does not see incremental benefit because the whole thing is so highly self-referential 19:15
dalek rrot: 6e5cd4a | dukeleto++ | tools/dev/headerizer.pl:
Remove a remnant of the dark days of Subversion
 19:16
plobsing it's kinda like your "need python core objects to implement python core objects" issue taken to the nth degree.
lucian plobsing: yeah, i get it
mostly i'd like to steal jikes' gcs
mikehh I think we are looking at commit d5a6bc669b77742316cac48b23cb6fd0a708b773 as pre-merge 19:18
whiteknight I read that immix paper this morning. Very interesting stuff
There are some things I think we can easily steal from there for our fixed-size allocators and our PMC/STRING allocators 19:19
line-based allocations and lazy sweep could each be implemented relatively quickly for some gain
if GC pauses are a problem, lazy sweep would shrink those significantly 19:20
line-based allocators with bump-pointer allocations would be an improvement over our current free-list allocator in most counts 19:21
there's a question about how much extra memory bloat and fragmentation we would suffer
dalek Heuristic branch merge: pushed 19 commits to parrot by leto
Coke dukeleto: you might want to run "ack -Q '$Id$'" - there's more than one there. 19:22
lucian whiteknight: i think there's been research about how most mallocs are bad for gcs for a while now
whiteknight lucian: we already don't use malloc much. Only to allocate the initial arenas 19:23
lucian whiteknight: i see
Coke um, we shouldn't be making our docs point to github.
whiteknight once we have the arenas, we're doing slab allocations and management
Coke msg dukeleto you might want to run "ack -Q '$Id$'" - there's more than one there. 19:24
aloha OK. I'll deliver the message.
19:24 sri left
Coke msg dukeleto - -1 on making all those links point to github. we should be making them work with "make html". 19:24
aloha OK. I'll deliver the message.
plobsing why do we use malloc for arenas? those are large allocations. shouldn't we be using mmap or sbrk directly?
lucian whiteknight: slabs within the arenas, right
whiteknight plobsing: maybe, yes
Coke msg hackbinary - -1 on making all those links point to github. we should be making them work with "make html".
aloha OK. I'll deliver the message.
19:24 sri joined
lucian it wasn't clear to me from reading the docs what sizes the arenas are 19:24
whiteknight lucian: in Parrot's GC, "slab == arena". Pools contain multiple arenas 19:25
lucian in the gengc
whiteknight we should probably update the terminology one day
dalek rrot: 93710cd | dukeleto++ | tools/dev/merge_pull_request.pl:
[tools] Script to make merging pull requests easier
 19:26
lucian whiteknight: a "legend" would probably be enough
lucian i do understand that docs aren't written yet because the code's so new
dukeleto Coke: feel free to fix stuff, but I merged that stuff already
dukeleto would like feedback on tools/dev/merge_pull_request.pl 19:27
it just saved me about 5 minutes, using it for one pull request
i hope it makes peoples lives a bit easier 19:28
it will even stash working copy changes if you have them
it requires wget and autodie right now, but we can fiddle with that. I just wanted something that worked *right now*
dalek rrot: 56df0ae | dukeleto++ | docs/glossary.pod:
[doc] Make the link point to the canonical repo
 19:30
lucian plobsing: i keep coming back to the same issue, the lack of a good system language that isn't C 19:32
plobsing winxed is unacceptable for some reason?
lucian plobsing: i mean lower than parrot, for implementing parrot itself
jikes has nice gcs because the language is nicer 19:33
partly, i mean
Coke dukeleto: I'll open a ticket.
dukeleto Coke: danke
lucian plobsing: for pynie, winxed does indeed look like the best option
19:33 lateau_ joined
whiteknight lucian: One thing not to overlook is that we have several extremely competent C coders on the team right now 19:34
lucian: on a different language, maybe not so much expertise
lucian whiteknight: sure, and they do awesome work
whiteknight damn straight
:)
lucian whiteknight: on a higher level language though, i'm pretty sure these great C coders would keep doing great work
cyclone, bitc or something else 19:35
whiteknight we certainly can't use cyclone. We need pointer arithmetic for the GC, and we need setjmp/longjmp for exceptions 19:36
other than that, I like the concept 19:37
lucian D is very nice, it's just kinda immature right now
plobsing cyclone, bitc, and c-- are decent options from a certain perspective
Coke D++
er, I like D.
lucian Coke: sure, let's not do another C++ :)
plobsing I kinda agree with Linus' exclusion argument against C++ for C++ and Java 19:38
whiteknight what argument is that?
plobsing we don't want the contributions of those that require such languages to acheive results in stead of C 19:39
19:39 lateau_ left
plobsing such languages can enable great power. but they can also be used as a crutch. 19:39
whiteknight from everything I've read, I've always thought Linus's attitude towards certain languages is a bit assinine
lucian plobsing: no offence, but i think that's elitist and silly 19:40
whiteknight C++ isn't a great language, but choice of C++ does not a bad programmer make
19:40 lateau_ joined
whiteknight choice of Java? maybe. :) 19:40
19:40 GodFather joined
plobsing no, but the requirement of C++ to get results does. 19:40
whiteknight no, that's true. If you can do it in C++ you should be able to do it in C
personally, if we had a language that was basically "C with thin classes", I would take it 19:41
lucian then you can do it in assembly too
whiteknight: vala?
19:41 AzureSto_ joined
whiteknight lucian: right. It's a matter of trading off and getting results in a timely manner 19:41
plobsing vala for parrot would be cool
whiteknight deep down we all want to be writing assembly. We just can't find the time
lucian plobsing: you mean like a HLL?
plobsing no, like Vala, but swap PMC for GObject 19:42
lucian whiteknight: except for me, who'd rather write the highest level possible langauge :)
plobsing: right. well, that's not too far from Close
benabik whiteknight: No, I've been very very happy with writing C++ for school.
lucian s/write/write in/
plobsing lucian: that's similar to what Close promised. I think it diverged somewhat from that.
lucian plobsing: it's dead now anyway 19:43
whiteknight I still do think that a GObject-based MOP for Parrot as one option would be a very good thing 19:44
19:44 AzureStone left
lucian whiteknight: in fact, gobject interop is a requirement for gtk. and with gobject-introspection it's not bad at all 19:44
whiteknight right
plobsing wait? I thought the GObject-based MOP was to create an optional GObject repr, not to base all parrot objects off of GObject. 19:45
whiteknight no, I wanted to use gobject as our underlying object system. At least as one pluggable option
plobsing isn't GObject single-inheritance?
whiteknight 6model should probably be our default still
cotto_work whiteknight: I thought the same thing as plobsing
whiteknight we wouldn't need to base all parrot objects off a GObject MOP. It could be separate and distinct from our normal PMCs and from Class/Object system now 19:46
or 6model
But we could have a GObjectClass type, which manages and instantiates GObject PMCs
plobsing ah, so the PMC/Object dichotomy all over again
whiteknight parrot should be able to support multiple pluggable MOPS. At least eventually 19:47
and a good GObject interface will be a major boost to Parrot getting integrated to gtk applications
lucian whiteknight: i don't see how that'll work 19:48
plobsing mono is used for a lot of Gtk stuff. It's base objects aren't GObject are they?
lucian the pluggable MOPs i mean
plobsing as is python. same deal. 19:49
whiteknight I'm sure mono has wrappers or mappers between it's objects and GObject
same with python. There's got to be a translation step, or a wrapper type
plobsing zomg heating up these benchmarks takes so long
19:50 mj41_ joined
lucian whiteknight: wrappers. there's a mono/python-level GObject you get that all GObject objects inherit 19:50
and it's rather foreign much of the time
dalek TT #2007 created by coke++: documentation now links offsite
TT #2007: trac.parrot.org/parrot/ticket/2007
dukeleto plobsing: if you describe exactly how you are running benchmarks, i can put them in a cron job on the gcc compile farm or something
plobsing: hint hint
plobsing dukeleto: I'm nearly done. I just have to run hexdump.winxed 3 more times on libc.a 19:51
whiteknight lucian: In Parrot, if I do a "$P0 = new ['Foo']", we look up a class object with that key and instantiate it. There's no reason why that class object we find has to be a Class PMC. It could be registered as any other type of PMC
then there's no reason why it couldn't be a GObjectClass object, without the user ever having to know
so long as we implement the necessary interfaces, we should be able to use any kind of class object we want for instantiating a class. And as long as we use methods and vtables at the parrot level, anybody can communicate with it 19:52
lucian whiteknight: right, then it's nothing too fancy
19:52 mj41 left
whiteknight it doesn't need to be fancy 19:52
19:52 mj41_ is now known as mj41
plobsing I can see why that would be cool. I'm not convinced it would be desirable. It has the potential to create a set of mutually slightly incompatible parrots and affiliated libraries. 19:52
whiteknight it certainly doesn't need to be disruptive or even obvious 19:53
lucian i thought it was something like CLOS's MOP, which is a tad insane
19:53 bluescreen left
lucian plobsing: i'd also rather see something like $P0 = GObject.new ['Bla'] and $P1 = Python.new ['bla'] 19:54
benabik I would think that it could be done inside 6model's idea of HOW/REPR. GObjectClassHOW and GObjectREPR.
cotto_work I'd really like to see something like that.
that has the potential for some shiny interop between disparate systems. 19:55
lucian yeah, as long as all object systems define how they can be used
in terms of native parrot types/operations
benabik lucian: Couldn't the translation layer (HOW) handle that?
lucian benabik: i don't know, i'm not familiar with 6model 19:56
but i don't think a translation is possible in general, N to N
whiteknight if i have a type registered, I shouldn't need to know what object system that type uses
get an object, use the object, never worry about how it's implemented
lucian whiteknight: but how do you use it? even between python and ruby (which are quite similar in many ways) that wouldn't work 19:57
ruby has only methods and no attributes or functions
python has no methods and only attributes and functions (for methods)
how do you fetch a method? 19:58
benabik Look up an attribute and see if it's a function?
lucian benabik: and if it's a ruby object? 19:59
whiteknight what does a method call look like in python?
lucian what if you set an attribute
in python, that could mean replacing a method
whiteknight lucian: for any object, you still have to know it's interface 20:00
lucian whiteknight: the attribute is fetched, if it's a function it gets called with self as the first argument
whiteknight but the interface is the only thing you need to know. Not the internal representation
plobsing dukeleto: benchmarks sent
lucian whiteknight: that's what i'm saying, the interface can only give a lowest common denominator, which is useless
dukeleto plobsing++
whiteknight I could make a class in NQP that has no methods, but can return functions through the get_attr_str vtable 20:01
lucian: and there's no reason that python-on-parrot objects can't implement VTABLE_find_method, to search for attributes and return PMCNULL if the attribute it finds is not invocable
lucian whiteknight: sure, but i don't think a general interface can be made 20:02
whiteknight lucian: the vtable is the general interface
lucian whiteknight: how would inheritance work?
whiteknight however you want it to work. that's a problem for the object designer, not the object consumer
if the question is "can a python class inherit from a ruby class" the answer might be "no" 20:03
lucian whiteknight: yeah, i meant inheritance by the consumer
plobsing lucian: classes implement 'add_method'. in python that's equivalent to 'add_attribute'. in other languages it may not be.
lucian some APIs require inheritance
whiteknight well, if I do find_method on a python object, it could ask it's class to find the attribute. When the class can't find it, it delegates up the chain of inheritance. That asks the ruby parent class for a method, which it can return 20:04
so long as everybody respects the vtable interface, no harm no foul
lucian whiteknight: hmm
plobsing: how would that work for purely functional languages?
20:04 bluescreen joined
whiteknight right now the linearization routine (C3) is provided by Parrot and is not pluggable, but that could be changed 20:04
lucian whiteknight: that's not a big deal, most multiple inheritance languages use C3 anyway 20:05
whiteknight right, that's why nobody has bothered to make it pluggable yet
plobsing lucian: purely functional language implementers have mapping their ideal math into an imperative world down to a fine art.
lucian plobsing: heh, nice way of putting it 20:06
so the interface is the PMC's vtable? that's exceedingly simple
i wonder if it'll work
my brain keeps bugging me that something doesn't quite fit 20:07
i probably just need to read more
20:07 lateau_ left
whiteknight lucian: that said, the vtable interface is clearly not perfect right now, so it does need some teaks 20:08
tweaks
but there are a lot of commonalities in operations between objects and metamodels
20:14 lateau_ joined
atrodo is rakudo not building a known issue? 20:16
cotto_work there's tt #2006 that masak++ filed 20:19
atrodo Yep, that looks like the error that isparrotfastyet is getting 20:20
20:25 lateau left
whiteknight Hackbinary: ping 20:28
dalek p-rx: 14741af | moritz++ | src/HLL/Grammar.pm:
change error reporting in <charspec>

This makes no difference in nqp itself, but in rakudo the old way caused a
  "Method 'paniuc' not found for invocant of class 'Regex;Match'		 20:30
20:30 ryan left
p-rx: e18bf4e | moritz++ | src/stage0/ (3 files):
update bootstrap files
cotto_work dukeleto: do you have the tuits to put gen_gc into its own branch? 20:37
dukeleto cotto_work: hmm 20:41
cotto_work: what exactly do you want me to do?
cotto_work: has no one volunteered to fix the mess yet? 20:42
cotto_work dukeleto: nope
whiteknight dukeleto: pick whatever strategy you prefer
dukeleto doesn't understand why he isn't smart enough yet to not volunteer for this stuff
whiteknight I can do it myself, but it would have to happen later tonight 20:43
20:45 AzureStone joined, lateau_ left
dalek rrot: 2d62367 | plobsing++ | / (4 files):
macro hygiene
 20:46
rrot: 2ee7af9 | plobsing++ | include/parrot/context.h:
dedup macros
rrot: 5829c74 | plobsing++ | include/parrot/context.h:
optimize non-gcable register access (somewhat mitigates WB issues)

  chromatic++ for idea
dukeleto BLARG 20:47
can everyone stop committing to master right now?
plobsing: ^^^
20:48 AzureSto_ left
plobsing I'm done. I was just trying chromatic's gen_gc regression mitigation. Sorry. 20:48
whiteknight plobsing++ 20:50
dukeleto plobsing: save those commits locally, 'cause i am stomping on them right now
darbelo How much does it mitigate?
whiteknight we should be able to add in dummy read/write macros for string and pmc types right now. When we're ready to update ops2c we can make use of them 20:51
dukeleto plobsing: can you push those to the gen_gc2 branch ?
dalek rrot: b1d3cb5 | dukeleto++ | / (44 files):
Revert "Generational GC enters the building. Merge generational_gc branch"

This reverts commit b55f22f6757b9f77fb851a07f69ddec1a708f329, reversing changes made to d5a6bc669b77742316cac48b23cb6fd0a708b773.		 20:52
dukeleto does a force push, hopefully nobody notices
rrot/gen_gc2: 2d62367 | plobsing++ | / (4 files):
macro hygiene
dukeleto plobsing: nm, did it already
dalek rrot/gen_gc2: 2ee7af9 | plobsing++ | include/parrot/context.h:
dedup macros
rrot/gen_gc2: 5829c74 | plobsing++ | include/parrot/context.h:
optimize non-gcable register access (somewhat mitigates WB issues)

  chromatic++ for idea
dukeleto ok, generationa_gc branch is unmerged, now lives in the gen_gc2 branch, with plobsing++'s recent tweaks 20:54
You all owe me beer.
whiteknight dukeleto: I'll put one in the mail right now
cotto_work dukeleto: sure. Catch me at YAPC::EU.
(or sooner)
dukeleto i didn't test stuff, i just unmerged, so master might be borked right now
please test
whiteknight I've been squirreling away extra change in my "buy dukeleto a beer" jar for a while now 20:55
cotto_work deal
dukeleto hopes it is a very large jar
whiteknight not nearly as big as my "buy bacek more computer chips" jar, but still pretty big
20:55 plobsing left 20:56 darbelo left
cotto_work msg bacek We've reverted the gen_gc branch merge. There are some performance regressions that need to be addressed (plobsing++ started on these), and the branch was merged without nearly enough discussion beforehand. We'll most likely re-merge just after 3.1 is kicked out and continue work from there. 20:58
aloha OK. I'll deliver the message.
dukeleto just sent an email to parrot-dev as well 21:01
You are all very lucky that you didn't have to read www.kernel.org/pub/software/scm/git...-merge.txt 21:03
cotto_work It took 4 seconds for my eyes to glaze over.
To be fair, I'm definitely feeling how late I stayed up last night. 21:04
dukeleto git revert -m 1 is all I did, and that seemed to work 21:05
arnsholt "In such a situation, you would want to first revert the previous revert" Oh god, it sounds like redo in Emacs... 21:06
dalek TT #451 closed by cotto++: Anticipated changes to bytecode 21:11
TT #451: trac.parrot.org/parrot/ticket/451
Hackbinary whitenight: pong 21:12
pmichaud good afternoon, #parrot
gc_gen branch discussion is .... interesting. :-) 21:13
21:14 fperrad left
whiteknight Hackbinary: we received your CLA. At the next #ps meeting somebody can nominate you to become a committer now 21:15
dukeleto pmichaud: howdy
Hackbinary ah, okay cool
whiteknight Hackbinary: Somebody will nominate you, and somebody will offer to mentor you, and if there's a positive vote you get the commit bit 21:16
dukeleto pmichaud: we unmerged the generational gc due to performance regressions
pmichaud: but we just need to tweak a few things and it will mostly likely be merged just after 3.1 goes out 21:17
Hackbinary cool
pmichaud dukeleto: yes; I'm fine with whatever you all decide to do. I think it points to continued difficulty with the deprecation policy, though
whiteknight pmichaud: yeah, don't worry. We are definitely going to merge it, we just don't want to rush
pmichaud I totally agree it had to be unmerged 21:18
Hackbinary whiteknight: I promise not to break anything ... I'm pretty conservative about changes
whiteknight Hackbinary: good. If you break something we take away your birthday
pmichaud I'm very eager for its performance benefits for Rakudo, but (1) not within 5 days of a Parrot release, and (2) not without a mention in the deprecations file, and (3) not at the expensive of huge performance regressions elsewhere, and ... 21:19
Hackbinary hmm ..... would that mean I stop aging?
;)
pmichaud *expense
atrodo The revert made my building of rakudo work again 21:20
whiteknight pmichaud: definitely after the release. I think we're all willing to "bend" the deprecation policy because this change is so fundamentally important
we don't want to wait until after 3.3 for it
pmichaud it doesn't matter that much to Rakudo anyway at this point -- the next rakudo Star isn't slated until April
whiteknight still, we want to have a lot of experience with the performance changes
pmichaud although if gen_gc lands in 3.2 we might issue a special R* to grab it 21:21
but we're kind of hoping that by then R* will be using the new 6-model based NQP
whiteknight it will definitely be in place shortly after 3.1
pmichaud yeah, that's the other reason it shouldn't be in 3.1 -- I suspect it broke the new nqp
I don't think anyone's tested that
whiteknight I wasn't aware it was ready for testing 21:22
pmichaud that's kind of not the point, though
the point is that it would be a huge example of a non-deprecated/non-noticed change breaking a HLL 21:23
Hackbinary seen coke
clunker3_ Coke was last seen on #parrot 1 hour, 46 minutes and 8 seconds ago, saying: er, I like D.
coke was last seen on #parrot 2 years, 5 months, 21 days, 18 hours, 2 minutes and 51 seconds ago, saying: I'll get you an answer on that one by Friday.
aloha coke was last seen in #parrot 1 hours 46 mins ago saying "er, I like D.".
whiteknight pmichaud: so what is your suggestion, wait until 3.3?
pmichaud no 21:24
(more)
I'm not arguing for/against any specific action, other than what you've already done (revert until after 3.1). I just find it interesting from a process perspective.
something still isn't right somewhere if this could happen again
Hackbinary coke, that's cool, I'll fix it. I asked lastnight about it, but not very many people where online
whiteknight pmichaud: Everybody here knows that I would like to light the deprecation policy on fire, snort the ashes, and dance a happy dance about it. I'm trying not to make many decisions about this whole issue 21:25
pmichaud anyway, I agree with whatever parrot decides to do. If it were me, I'd probably do what you propose -- i.e., say "it's too big an improvement to wait until 3.4" (which is how long it would have to wait in order to follow the deprecation policy, and 3.6 would be the next supported release with the improvement) 21:26
I'm just really glad we're on 3-month deprecation cycles instead of 6-month
6-month would've been... horrible
21:26 plobsing joined
whiteknight I do forsee the argument being made that GC write barriers aren't covered by the deprecation policy. I'm not saying it, but I expect it will be said before the issue is resolved 21:27
fair warning
pmichaud I think they have to be considered part of the dep policy (more) 21:28
if we expect HLLs and other users to create custom PMCs (and that's been a core component of Parrot's design since day 1), then the requirement to add GC write barriers is part of the API.
we can't say "custom PMCs aren't part of the API" -- they have to be.
whiteknight I will say that this represents a weird case. It's difficult to deprecate something we don't have, so that it can be safely added. It's also not like there is any real way we could have both solutions available simulaneously 21:29
that is, we can't really have a release where we both have and do not have write barriers so the users can safely migrate
in any case, I have to catch a train. Later 21:30
pmichaud later
plobsing I'll point out that I mentioned the dep policy WRT read/write barriers back in *September*
pmichaud plobsing++ :-)
21:30 whiteknight left
moritz don't we have pluggable GCs? 21:31
plobsing we do. so it should be possible to use ms2 even after gms lands. 21:32
pmichaud would it be possible to keep ms2 as the default, and let a HLL switch to gms?
plobsing but that does not resolve the issue that gms is the default GC, and that the optimizations that were removed (the perf regressions) were removed universally 21:33
moritz so why not make gen_gc available via a command line option, so that people can test the deprecation that way?
ok, the optimizations are a good point
pmichaud agreed fully
21:34 nwellnhof joined
nwellnhof ~ 21:34
pmichaud anyway, we'll all manage it as best we can. plobsing++ on noticing the performance regressions for non-GC heavy code 21:35
I completely agree that's a problem that needs addressing before the merge
tbh, I wasn't expecting gc_gen to be able to merge (because of deprecation/policy issues) until well after 3.1. 21:36
and only in 3.2 or 3.3 with a policy exception
cotto_work It's not so much a problem of the deprecation policy as of that policy being ignored.
21:36 mtk left
pmichaud cotto_work: yes, I think that's what I'm trying to say 21:36
it's a process and cultural issue
cotto_work yes 21:37
pmichaud afk, kid pickup from school 21:38
see you all later
also, I'll be largely afk for the next 5 days -- we're taking a last-minute vacation this weekend
the folks on #perl6 can answer any critical questions you might have, or email me.
cotto_work pmichaud: have fun!
Coke pmichaud: be well. 21:48
benabik master builds, passes tests, and builds rakudo on Darwin/x86 22:01
22:02 wknight-phone joined
lucian i don't mean to be insulting, but how many parrot users are there? 22:05
i don't think deprecation matters at this point
everyone outside #parrot thinks parrot's getting rewritten the 3rd or 4th time, and avoiding it until someone announces "the fresh new parrot has arrived"
plobsing lucian: 5. I know because we phone home with usage stats. 22:06
22:07 rurban_ joined
lucian plobsing: parrot phones home? cool 22:08
22:09 rurban left, rurban_ is now known as rurban
Hackbinary I'm also using parrot to run my l33t 16 node bbc, running pcboard 16, customized to the max 22:10
plobsing but, all jokes aside, even if we do not have a lot of users, a conservative approach is likely the best approach for *attracting* users and retaining them
lucian plobsing: sure, after you can say "lorito is done, we have pluggable gc and jit"
before that, it's unlikely people will care much 22:11
plobsing parrot has historically taken the other approach "full ahead, consequences be damned" and burned out a lot of depending projects
lucian right
plobsing partcl is a recent, and perenial (it seems), example of this
22:13 ryan joined
Coke of course, considering partcl an actual "user base" would be overselling it, but yes, it's certainly a PITA to keep up, even with the deprecation policy. 22:14
but for some time, it was the canary in the coal mine.
plobsing you do that to enough developers, you'll build up a reputation, and no amount of shiny will attract the good developers. 22:15
lucian plobsing: well, parrot already has a reputation of not delivering 22:16
i would think shiny, quick could be more attractive
Coke at this point, I would think "keeping rakudo happy and not breaking lua" is our best bet.
plobsing I'll take "well thought out" over "runs fast for me" any day. A conservative approach to improvement encourages the former. 22:17
22:18 ambs joined
lucian plobsing: hopefully. from the extreme skepticism i've been hearing, i'm not so sure 22:18
plobsing I'm not saying the dep policy is perfect. But having standards we hold ourselves to is a Good Thing (TM), even if they may be annoying in the small.
and in many cases, we at least have the opportunity to put the notices in. this includes gen_gc. 22:20
dukeleto lucian: i question the fact that HLL's want a pluggable GC. They want a fast GC that works. 22:26
lucian: just about 0% of HLL authors want to write their own GC
lucian dukeleto: of course no one really wants to write one 22:27
dukeleto lucian: so pluggable GC is just abstraction for abstractions sake
lucian but having several gcs selectable at runtime is a good idea
dukeleto lucian: i question that
lucian: choosing at compile-time, sure. Run-time? I haven't seen a good sales pitch yet.
lucian works pretty well for the jvm
dukeleto lucian: the jvm can switch GC's at run-time ? I wasn't aware. 22:28
lucian you need about 3 classes of gcs
dukeleto: yeah, it has 4-5 gcs you can select
dukeleto lucian: i see. It seems more convenient, but when do you actually need to choose a GC at runtime?
lucian: if I am on a real-time OS, i know I need a real-time GC at compile time 22:29
lucian: if I am on a phone, I know I want the mobile-friendly-gc
lucian many music processing apps choose a real-time gc on the jvm
dukeleto lucian: when do you not know which GC you want until runtime?
lucian applications might want different gcs
dukeleto lucian: sure, which they can choose at compile-time. Why would they wait until run-time ?
lucian: i agree. I just don't see the need to work on the engine of a car while driving it 90mph on the highway. 22:30
lucian compile-time of what?
compile-time of the app, run-time of parrot
dukeleto lucian: well, a GC can already be chosen with command line arguments to the parrot binary 22:31
lucian dukeleto: sure, that's what i meant
dukeleto lucian: but once you choose, that is it. No changing it half-way through execution
22:31 ambs left
lucian of course, the jvm can't do that either 22:31
dukeleto lucian: ah, ok. We are back on the same boat.
lucian yeah :)
nwellnhof notes that JIT can help a lot with pluggable GCs 22:32
plobsing still, until you've exhausted all other avenues, you really shouldn't be doing that
lucian when i listed that as shiny, i meant a few pluggable gcs
dukeleto lucian: let's concentrate one making *one* really good first, but I agree.
lucian so your app could choose the slow-but-low-memory or the fast-but-high-memory or the slow-but-incremental gc
dukeleto: yes, of course
but the potential to do this would be enough "shiny" i think 22:33
22:33 wknight-phone left
dukeleto lucian: we already have that. You can choose a gc now. 22:33
plobsing you could of course have multiple parrots sitting around to provide that functionality. that way, you have the benefits of knowing the GC statically and being able to eliminate read/write barriers for the GCs that don't require them. 22:34
lucian plobsing: i think that's what the jvm does, to some extent
dukeleto: yes, and it's nice
nwellnhof you can plug in another mark and sweep GC right now, but that's it. Parrot doesn't support any other type of GC yet. 22:35
plobsing nwellnhof: there is the infinite memory GC. that's something else... 22:36
and it works great on real turing machines
nwellnhof it's a mark and sweep GC without marking and sweeping ;)
lucian plobsing: i'll get you one for your birthday
btw, i forgot to list tachyon.in/clay/ when i was ranting about nicer system languages 22:37
plobsing lucian: great. now I just have to get someone to buy me pushable rope. and some frictionless, massless pulleys. 22:38
lucian plobsing: don't forget the ideal point mass 22:39
ryan Hello, I'm looking for GSOC ideas and Dukeleto++ informed me that I should speak to some people in the IRC. Does any one have any ideas? 22:41
nwellnhof ryan: a copying garbage collector 22:42
plobsing ryan: have you looked at trac.parrot.org/parrot/wiki/BigProjectIdeas 22:44
22:44 vmspb joined
ryan no I'll look at that now thanks 22:45
nwellnhof what does "context-threaded runcore" mean? 22:47
ryan I saw this "GObject Metamodel", this is to work with GTK right? 22:48
is there a project like this for qt? 22:49
lucian ryan: you could implement a SMOKE binding, i guess
smoke is the qt equivalent of gobject-introspection
22:51 whiteknight joined
ryan lucian: sounds cool 22:53
lucian ryan: for example, RubyQt is made with SMOKE 22:54
perhaps you could implement a QObject metamodel with SMOKE, but i don't really know
ryan thanks 22:55
sorear ryan: before implementing something, make sure it's actually wanted 23:00
whiteknight what is ryan implementing?
sorear whiteknight: nothing, yet 23:01
whiteknight has some backloggin' to do
23:01 kid51 joined
whiteknight nwellnhof: a context-threaded runcore is a type of runcore 23:02
it's a way to dispatch ops
lucian whiteknight: btw, i think runcores are an awesome feature of parrot 23:03
a way to market parrot would be to look at existing mainline vms and see what they can't do 23:04
plobsing we've already neutered the most interesting aspect of runcores for practical reasons 23:05
op-dispatch strategy is fixed
lucian ah. oh well 23:06
plobsing because otherwise we need separate oplibs and supporting stuff for every runcore
I'd like to see op-dispatch strategy re-introduced as a compile-time-fixed option
what our runcores currently provide is orthogonal to op-dispatch strategy 23:07
23:09 vmspb left
plobsing they're still really cool though. just less cool than the name implies 23:11
whiteknight a context-threaded runcore could easily be added to parrot as-is
because we could still be using the op function bodies
lucian right 23:12
nwellnhof is context-threading some kind of poor man's JIT?
sorear no 23:13
context threading is basically just a reinvention of subroutine-threaded-code
lucian is it this? en.wikipedia.org/wiki/Threaded_code
sorear check out any Forth book for an explanation of that term 23:14
plobsing it is a JIT in some sense. it has all of the requirements with fewer advantages. 23:15
IIUC, you need to deal with W^X and generate machine code. 23:17
lucian it's pretty cool. i do think it's named horribly
plobsing: python's threaded interp is pure C
plobsing lucian: is it context threaded?
op-dispatch strategy is commonly refered to as "threading" regardless of what type it is 23:18
lucian plobsing: don't think so
plobsing: bugs.python.org/issue4753 23:19
nothing fancy at all, just a compiler trick
23:20 Andy left
plobsing that's what cgoto (also cgp) did 23:20
arnsholt Does anyone know why PAST::Op(:pasttype<try>) doesn't pop_eh until the end of the recovery clause?
plobsing and it was worth it sometimes. for some workloads our branch mispredict went from 100% (which it is effectively all the time right now) to 5%. 23:21
but most workloads aren't dominated by op dispatch
sorear plobsing: "generate machine code" is not boolean
plobsing: the x86 instruction encoding is incredibly complex, and I don't fancy writing a full JIT (even non-optimizing), ever 23:22
plobsing sorear: anything that generates machine code at runtime can be classified as JIT in some sense.
tadzik is amd64 any better?
sorear but remembering 9F xx xx xx xx where *(int*)(ip+1) = dest - (ip + 5) isn't that hard
lucian i think a llvm jit would be more useful
tadzik or is it just extended x86?
sorear and yes, I know that by heart
tadzik: amd64 is almost a compatible extension of x86 23:23
lucian i think if you use amd64 in 64 more it's better
sorear tadzik: they axed setalc to make room for a new encoding form
tadzik axed setalc?
lucian you have to put in x86 mode for full compat
23:30 plobsing left 23:31 nwellnhof left 23:34 nwellnhof joined 23:35 plobsing joined
whiteknight the benefit to context-threading is that it's not the same weight as a JIT, and you end up with huge cache benefits. opdispatch costs drop down to zero 23:35
admittedly our op dispatch costs are not high right now
at least not comparitively
plobsing cgoto had effectively the same advantage. see how many people cared. 23:36
whiteknight in Lorito world we will conceivably have to execute many more ops to perform the same operations
plobsing: cgoto was a completely different architecture and wasn't supported on one of our key target platforms
context threading will be perfectly supported, requires no fancy features from C99, and can reuse the fast/slow core op libraries and op bodies 23:37
plobsing yes Lorito might make op dispatch important. we should address this when it happens or when it become clear that it is imminent
whiteknight: at the cost of dirtying PBC with a direct-threading equivalent.
whiteknight I don't think runcore improvements are high-priority right now in any case 23:38
if somebody implemented it and delivered it to us on a silver platter, awesome. 23:39
sorear whiteknight: now that W^X et al exist I don't think the benefit of context-threading is as big as it once was
whiteknight what do you mean "W^X"
?
sorear write xor execute
plobsing Write XOR eXecute
memory access modes 23:40
whiteknight ah, okay
plobsing modern OSen often enforce that at any given time only one of these can be set
sorear whiteknight: ten years ago, when everybody who could run real software ran 32-bit x86 and execute protection wasn't used, you could write a decent context threader in 200 lines of C since JMP, CALL, RET are a tiny subset of the complexity of an assembler 23:41
nowadays:
whiteknight it's still no so bad with mmap. And we have a PMC for mmapping
sorear - x86_64 and ARM exist on the desktop
- a lot of OSes implement execute protection in mutually incompatible ways
plobsing not to mention, from the explanations I've seen, CTT (context threaded), like DT (direct threaded), requires writting into the op stream. this means the mmapped pages are dirty and cannot be shared. 23:44
Tene arnsholt: you don't pop_eh until the end of the handler because for many situations you want to leave the handler active; anything with resuming the exception, basically
arnsholt: Let me know if you want more information or examples of that
arnsholt Resuming the exception is a good point 23:45
Tene arnsholt: when providing flow control support to loops, you don't want to be pushing and popping the eh over and over 23:46
afk meeting
dalek rrot: 9dadd29 | jkeenan++ | / (19 files):
Per TT #2004: Remove remaining references to former '--cxx' option to Configure.pl.
arnsholt Indeed a good point. But it's a bit annoying in my case, which is essentially try { function() } catch { /* Complicated recovery and condition checking goes here. */ } 23:50
Ideally, I'd have the pop_eh at the top of the recovery, but if I add pop_eh at the top of my recovery PAST it'll blow up on the automatic pop_eh at the end if it gets through the recovery without a rethrow 23:53
dalek TT #2004 closed by jkeenan++: Where did Configure.pl option '--cxx' go to? 23:54
TT #2004: trac.parrot.org/parrot/ticket/2004
whiteknight arnsholt: you can create a new mini-handler in the try section, to catch errors from your error handler
then do pop_eh\\npop_eh
23:56 ryan left
arnsholt Hmm. That'd work 23:56
A bit hacky, but working and hacky beats clean and broken
lucian hmm, i might play with writing bits of parrot with clay 23:59
i mean, in clay
can the gc be plugged in if written in something other than C?
like plugin in a .so?

Powered by Cro and the Raku® Programming Language.

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

Thank you!