Parrot 2.0.0 "Inevitable" released! | parrot.org | Priorities: merge branches, remove deprecations | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 9 February 2010.
Whiteknight what other MRO algorithms are there besides C3? 00:00
Wikipedia is strangely silent on the issue
Austin Well, the C3 paper mentions "the Dylan linearizer", L*Loops, CLOS
nopaste "Austin" at 68.37.46.53 pasted "Linearization" (5 lines) at nopaste.snit.ch/19548 00:02
Austin So apparently, either your language doesn't support MI (Java), or it supports MI but requires explicit MRO input from the coder, or it has an algorithm that is probably named after the language, unless it's a Lisp dialect in which case the algorithm may have its own name if you wrote a paper about it. 00:05
Whiteknight soo...C3 is the only game in town 00:06
00:08 tetragon joined
chromatic There's also depth first, but that's... complex and not necessary accurate. 00:10
Austin C3 is far from the only game in town. 00:14
It's important because Python uses it, and because of Parrot's historical ties to Python.
00:16 payload left
Austin But if someone were to try to implement CLOS atop Parrot, they would need a different MRO, since C3 is definitely not the MRO that CLOS uses. 00:16
00:19 cotto_work joined, patspam joined
Whiteknight so it might very well make sense to encapsulate the C3 linearizer as a PMC, and add an option for HLLs to override it as the default 00:28
dukeleto Whiteknight++
did someone say GSoC project?
00:29 cotto_work joined
Whiteknight just encapsulating it isn't a worthy project, but adding a few more options in addition might be 00:29
dukeleto Whiteknight: by the way, i have been enjoying your GSoC project idea blog posts. thanks for mentioning RTEMS. my blog-fu is definitely rusty
Whiteknight I've been thinking about adding an HLLInfo PMC, which stores HLL-global configuration information like that
dukeleto: No problems, I like to do it because I'm full of hot air and I spend too much time on the computer
Austin This may just be "rewrite class.pmc" 00:30
dukeleto Whiteknight: i meant adding a pluggable MRO subsystem, as a GSoC project
Austin Or maybe it's "rewrite oo.c and class.pmc into a pluggable shape"
Whiteknight ah, okay. That might be good, but would still have to add at least one other option to prove pluggability
Austin Since C3 is, for no very good reason, in oo.c
Fine. 00:31
What's the P5 mro like?
Whiteknight class.pmc could use plenty of improvements
dukeleto "Make the Parrot MRO subsystem pluggable, so languages can decide which MRO algorithm to use"
Whiteknight Ability to properly subclass built-in PMC types is high on the list
Austin :)
Austin gives Whiteknight a biiiiiig *smooch*. 00:32
dukeleto Austin: have you seen search.cpan.org/~tty/kurila-1.19_0/lib/mro.pm ?
Austin Nope.
What is it?
purl it's it!
dukeleto Austin: also, search.cpan.org/~flora/MRO-Compat-0.../Compat.pm
Austin: C3 + friends for Perl 5
Austin Okay, reading it now.
Whiteknight Austin: That's it, you're now on my valentines card giving list 00:33
Austin P5 uses depth-first-search, Whiteknight. There's your "for comparison" alternative.
dukeleto Austin: doing "prior art" research is almost always very helpful ;)
Austin: depth-first, left-most first ;)
00:34 s1n joined
Austin Hmm. 00:34
Not really depth first.
00:34 s1n left
Austin preorder? 00:35
dukeleto++ 00:37
Thanks for pointing to that.
Whiteknight: I'm thinking that class.pmc maybe needs to method-ize a bunch of its internal operations, and then the GSC thing would be to do that plus write two sets of methods: C3 and P5dfs 00:41
Whiteknight Austin: And then when the next algorithm comes down the pike we add another set of methods? 00:42
Austin Right.
Whiteknight better, I think, is a C3Linearizer PMC object, which we can replace with other PMC types later without having to hack into class again 00:43
Austin Eh?
Sorry. By "set of methods" what I secretly mean is "non-abstract class"
Maybe you could explain what a PMC offers in this context. 00:45
That is, a separate pmc for the linearization algorithm.
00:46 mikehh_ joined
Whiteknight cotto: ping 00:49
00:52 mikehh_ joined
cotto_work Whiteknight, pong 00:52
Whiteknight cotto: Where does the Parrot_DynOps_core_2_0_0 function get called? 00:53
cotto_work beats me. Let me dig a bit.
Why do you ask? 00:54
Whiteknight I'm trying to make a PMC type to encapsulate the op_table, and provide access to it from PIR 00:55
so I'm trying to figure out where it gets initialized
but I think the code is generated, because an ack doesn't turn up any results and I have build errors locally
cotto_work That function is #defined in op.h to PARROT_CORE_OPLIB_INIT, which appears to be what's used directly. 00:57
config.h 00:58
purl hmmm... config.h is guaranteed to be available on systems which didn't build their perl but installed the sources/headers from some package manager?
cotto_work Is that what you're looking for? 01:06
Whiteknight ah, yes 01:12
that's cotto++
cotto_work I wonder how such PMCs could affect the pct-based ops and pmc compilers. 01:14
Whiteknight I'm hoping significantly 01:15
especially if we provide the ability to compile an op
Austin Whiteknight: (re: your blog) Can you cast in C#? 01:16
That is, would (bool)(b[x] & 0x80) work?
Whiteknight Austin: I don't know if that would work, no 01:17
Austin Oh, well.
Whiteknight certainly no less verbose than != 0
Austin Nope. 01:18
close-parrot.blogspot.com/2010/02/m...-code.html
More pictures - mostly white.
01:20 jan joined
Austin That's weird. I tried calling '.new' on a non-existant class / namespace, and it hung. 01:27
Given that the trace shows a P-register with PMCNULL in it, shouldn't I have received an exception?
cotto_work nopaste? 01:28
purl i guess nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
Austin Aha. 01:29
Inferior runloop doesn't have trace enabled. I *did* receive an exception.
01:30 allison joined
Austin Perhaps an nqp bug? 01:32
cotto_work We can't know without a nopaste. 01:35
kid51 re yapc::na::2010 theme: robonperl.blogspot.com/2010/02/what...erl-5.html 01:48
01:50 allison joined
kid51 pmichaud: YAPC::NA::2010 Call for Presentations (conferences.mongueurs.net/yn2010/) states: "Perl 6 is going to be great, but we can't wait until 'Christmas' for Perl 6." Which implies that they're not expecting much re Rakudo/Perl 6 at YAPC. Comment? 01:52
02:06 plobsing joined 02:35 mikehh__ joined
Whiteknight NotFound: ping 02:48
Austin Whoa. 02:51
If you automatically generate and compile source code as an accessor method, that method goes into a space where it has offset 0. It's pretty weird making a call from 59131 and landing at 0, but not an error. 02:52
dukeleto is about to give his parrot talk 02:57
Austin Live feed?
purl well, Live feed is a little lame right now but there are some nifty archived realaudio dj shows at www.groovetech.com
dalek rrot: r43878 | whiteknight++ | branches/op_pmcs/src/pmc (3 files):
remove opfamily PMC, it was a non-starter. Flesh out oplib and opcode a little bit. Now contains all the basic functionality I think we need
rrot: r43879 | whiteknight++ | branches/op_pmcs/src/pmc/pmc.num:
make pmcrenumber
rrot: r43880 | whiteknight++ | branches/op_pmcs/src/pmc (2 files):
add some plumbing that I had neglected
rrot: r43881 | whiteknight++ | branches/op_pmcs/src/pmc/oplib.pmc:
extra vtable + comment
kid51 portland.pm.org/kwiki/
dukeleto we have "parrot-curious" people here! 03:06
03:06 mugwump joined
mugwump git head rakudo test failures on topic? :) 03:07
t/spec/S02-literals/quoting-unicode.rakudo Dubious
eternaleye mugwump: #perl6 on freenode is the canonical rakudo channel 03:08
mugwump ah true
I was looking ... rakudo, no
forgot it was once called perl 6
so long ago
eternaleye Lots of overlap peoplewise though
03:08 Austin_Hastings joined
eternaleye mugwump: rakudo is _a_ perl 6 implementation, but it is explicitly not the only onw 03:08
*one\\ 03:09
Austin_Hastings Well, there went the first inevitable power outage.
mugwump no, I think that only if the real pumpkin started interpreting perl 6 it could be called that
03:18 Austin_Hastings joined
Austin_Hastings And there's another one. 03:18
03:27 tetragon joined
kid51 vtable_massacre branch: t/pmc/bigint.t Failed tests: 35-45 Parse errors: Bad plan. You planned 34 tests but ran 45. 03:29
fixed plan 03:31
dalek rrot: r43882 | jkeenan++ | branches/vtable_massacre/t/pmc/bigint.t:
Correct quantity of tests in plan.
 03:32
mugwump ooo, I like the name of that branch 03:36
03:54 janus joined 03:55 Austin joined 04:20 notbenh1 joined 04:41 Austin joined 04:47 mikehh__ joined 04:55 JimmyZ joined
dukeleto live demo fail! but it went well 04:55
mugwump dukeleto: what? where? when? who? 04:57
plobsing seen japhb 05:01
purl japhb was last seen on #parrot 2 days, 2 hours, 26 minutes and 3 seconds ago, saying: And, as I said, it will currently be incomplete because there are a number of signatures that current Parrot NCI just can't handle. [Feb 9 02:35:34 2010]
cotto mugwump, portland.pm.org/kwiki/index.cgi?Feb...010Meeting 05:02
05:02 kurahaupo joined
cotto dukeleto, are they generally quick about putting up recordings of presentations? 05:03
I'd also like to listen to Schwern's presentation. That sounds interesting. 05:05
Coke . o O (BOOYAH!) 05:10
Coke once again ponders a poker BOF at yapc. 05:12
05:25 ashleyb joined 05:29 patspam joined, bacek joined 06:04 dduncan joined
cotto pmichaud, ping 06:12
dalek rrot: r43883 | cotto++ | branches/ops_pct/compilers/opsc (6 files):
[opsc] remove a now-unneeded cheat and get closer to passing tests (though still not there)
 06:31
06:44 chromatic joined, kurahaupo joined 06:45 dduncan left 06:50 kurahaupo joined 07:05 baest joined 07:09 kurahaupo1 joined, Austin joined 07:13 uniejo joined 07:16 AndChat| joined 07:34 kurahaupo joined 08:02 kurahaupo joined 08:04 eiro joined 08:07 iblechbot joined 08:16 barney joined 08:34 payload joined 09:11 bacek joined
dalek TT #1435 created by gerd++: Tru64 report 09:18
bacek aloha 09:58
10:23 eternaleye joined 10:40 Austin_Hastings joined 10:49 eternaleye joined
dalek rrot: r43884 | bacek++ | trunk/src/gc/api.c:
Made block/unblock GC functions optional.
 11:25
rrot: r43885 | bacek++ | trunk/src/interp/inter_create.c:
Propogate GC type from parent interpreter in allocate_interpreter.
rrot: r43886 | bacek++ | trunk/src/gc/api.c:
Mage pmc_needs_early_collection optional.
rrot: r43887 | bacek++ | trunk/src/gc/gc_inf.c:
Update GC INF to latest GC encapsulation API.
11:28 cognominal joined 11:51 bluescreen joined 11:54 Whiteknight joined
Whiteknight good morning #parrot 12:03
mikehh__ hi whiteknight 12:04
bacek Whiteknight, aloha. You are early today :) 12:07
Whiteknight yes, I can't go to work this morning because of snow. So I am working the morning from home 12:08
Austin And the boss believes this?
:)
Yaay, snow!
bacek Show? Do you mean one of water's state?
On streets??? 12:09
NO WAY!
Austin close-parrot.blogspot.com/
I don't live very far away from Whiteknight.
Maybe 25 km. 12:10
Whiteknight Austin: They haven't really plowed my apartment complex, I can't get my car out onto a real road
and from that point, I have zero faith that PennDOT has done any productive work since the storm stopped 12:11
bacek img-fotki.yandex.ru/get/4114/bacek....a738cdc_XL 12:13
Photo was taken less than a month ago :-P
Austin Yeah, yeah. It's always nicer in the _other_ hemisphere... 12:14
12:14 ruoso joined
bacek Of course :) 12:15
Austin :)
Whiteknight replace the sand with snow, then turn all the colors to white, and remove all the people, and take away the beach, and that's exactly what it looks like from my window 12:16
bacek Yay. Like a beautiful dawn but green :) 12:17
btw, gc_inf needs some love. 12:18
Especially of someone with good literacy skills to update documentation :)
Whiteknight I'll see what I can do about gc_inf now. 12:23
gc_inf doesn't really have an "algorithm", so it's hard to imagine that it's too broken 12:25
mikehh__ fixed some codetest failures - missing function docs still needed
bacek Whiteknight, it works. But documentation is outdated 12:28
badly
12:28 mikehh joined
Whiteknight bacek: doesn't work, I just tried it and segfault magic 12:29
no, wait. now it works. I had something weird before
dalek rrot: r43888 | mikehh++ | trunk/src/gc/gc_inf.c:
fix codetest failure - there should be at least one space between a C keyword and any subsequent open parenthesis
 12:30
rrot: r43889 | bacek++ | branches/boehm_gc_2:
Yet another attempt to bring Boehm GC into Parrot
rrot: r43890 | bacek++ | branches/boehm_gc_2 (2 files):
Copy configure auto::boehm from old branch
bacek Whiteknight, "it was looong time ago" :)
Whiteknight I made a hack to get it working with make test 12:31
mv parrot parrot-exe; echo "#!/bin/sh\\n./parrot-exe --gc inf $@" > parrot; chmod +x parrot
urg, it hangs on the stupid string_mem.t test
I hate that test, because it assumes too much about the operation of the GC 12:32
bacek Whiteknight, +1 12:34
Whiteknight In fact, I might just "accidentally" disable it. On accident 12:35
bacek looking at nice night sky 12:36
Whiteknight we need to add a selector in interpinfo to get information about the current GC
each GC needs a string name that we can return
bacek Sounds reasonable
Whiteknight that way in tests like this we can detect current GC and disable unnecessary tests 12:38
12:38 KingOfKarlsruhe joined
mikehh bacek, Whiteknight: doyou want me to fix the documrntation stubs - or shall mI leave it for now? 12:39
Whiteknight which documentation stubs?
in gc_inf.c
bacek mikehh, yes please. You can also add ASSERT_ARGS (I missed them)
dalek rrot: r43891 | bacek++ | branches/boehm_gc_2 (3 files):
Copy gc_inf into gc_boehm and add it into build.
 12:46
rrot: r43892 | bacek++ | branches/boehm_gc_2/src (2 files):
Add Boehm GC into list of available GCs.
rrot: r43893 | bacek++ | branches/boehm_gc_2/src/gc/api.c:
Initialize Boehm GC in gc_init.
 13:03
rrot: r43894 | mikehh++ | trunk/src/gc/gc_inf.c:
fix codetest failure - correct missing documentation stubs
rrot: r43895 | bacek++ | trunk/compilers/imcc (8 files):
Fix IMCC to use mem_sys_alloc/mem_sys_realloc/mem_sys_free
 13:19
rrot: r43896 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
First cut - use GC_* functions in gc_boehm.
rrot: r43897 | bacek++ | branches/boehm_gc_2/src/gc/alloc_memory.c:
Copy alloc_memory.c from old branch
rrot: r43898 | bacek++ | branches/boehm_gc_2 (9 files):
Merge branch 'master' into boehm2
ttbot Parrot trunk/ r43900 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/193596.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 13:23
13:26 bkuhn joined 13:28 payload joined
bacek mikehh, you broke build... 13:28
mikehh bacek: make headerizer failed I think 13:30
can you try and run it
damnit I tested before I commited it 13:31
bacek mikehh, fixed 13:33
dalek rrot: r43899 | mikehh++ | trunk/src/gc/gc_inf.c:
add ASSERT_ARGS
 13:36
rrot: r43900 | whiteknight++ | trunk (4 files):
add a GC_SYS_NAME option to interpinfo_s_i. Returns the name of the current GC system
rrot: r43901 | bacek++ | trunk/src/gc/gc_inf.c:
Restyle code to make headerizer happy.
bacek ...and whiteknight's commit as well ...
Whiteknight headerizer is broken on pirc, and I can't add my new function because of it 13:40
13:57 ilbot2 joined, ttbot joined, dngor_ joined, ingy joined, Tene joined 13:58 ascent joined, Ryan52 joined, Whiteknight joined 13:59 ruoso joined 14:03 particle joined
dalek rrot: r43905 | mikehh++ | trunk/src/gc/api.c:
add ASSERT_ARGS
 14:10
14:13 slavorg joined 14:17 ashleyb joined
Coke ... how long has checkdepend been failing most of its tests? 14:21
did someone add a new header file or something?
cotto: having the FULL text of the comparison is useless when you have 59 deps in one and 60 in the other. 14:23
Coke looks for that test module that highlights such things...
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32155), fulltest) at r43905 - Ubuntu 9.10 amd64 (g++ with --optimize) 14:28
14:39 rob joined
dalek rrot: r43906 | coke++ | trunk/tools/dev/checkdepend.pl:
Make the test diagnostics here usable.
 14:46
14:47 rob left
Coke Whiteknight: ... you probably ran configure with --maintainer. 14:53
and since you have a different version of bison, it makes changes. 14:54
Whiteknight oh, damnit
Coke shouldn't /hurt/ anything, though.
15:01 janus joined 15:10 theory joined 15:15 bubaflub joined
dalek rrot: r43907 | coke++ | branches/rm_cflags (5 files):
Add a suffix override for PMCs. (but don't do anything with it yet.)

fix some warnings.		 15:18
Coke svn merge in 1.6 is muuuch nicer. 15:24
dalek nie: r97 | allisonrandal++ | trunk/ports/plumage:
Adding a directory for plumage files.
 15:29
nie: r98 | allisonrandal++ | trunk/setup.py:
Cleaning up intermediate executable files.
nie: r99 | allisonrandal++ | trunk/p (2 files):
Move Plumage files to standard location.
Coke msg kid51 the merging in svn 1.6 completely removes the need for the tagging 2-step you do. 15:34
purl Message for kid51 stored.
dalek nie: r100 | allisonrandal++ | trunk/setup.pir:
Fix one character typo in Plumage build file.
 15:39
15:40 silug_ joined
dalek rrot: r43908 | coke++ | failed to fetch changeset:
merge from trunk
 15:52
15:54 Psyche^ joined
tewk_ Oh how I wish pir had native syntax support for closures. 16:15
Also no one spoke up yesterday as to why the program counter isn't stored in the ctx or the interpreter. 16:16
moritz (closures) that probably means that you're writing something in PIR where you should really be using a higher level language 16:17
Whiteknight pmc2c--
darbelo karma pmc2c 16:18
purl pmc2c has karma of -21
tewk_ I wrote some code that broke out of a runloop early and I had to preserve the pc myself so I could restart the runloop later
darbelo pmc2c--
Whiteknight pmc2c--
tewk_ moritz, I have been converted/warped to believe that scheme is a good low level language to do programming language research on top of. 16:20
In hind sight closures instead of subroutines would have been a better primitive for parrot to build on top of. 16:21
Closures got added on top of subs, and its just ugly.
16:24 payload joined
dalek rrot: r43909 | coke++ | branches/rm_cflags/compilers/imcc (2 files):
re-gen generated files
 16:25
Coke (scheme), ah, if only someone had written scheme-on-parrot 9 years ago. 16:30
I shouldn't assume I can blindly pass -Wno-foo to a non-gcc compiler, right? 16:32
Whiteknight $P1 = $P0["str"] is calling get_pmc_keyed, not get_pmc_keyed_str. Any reason why that would be? 16:39
16:40 eternaleye joined
darbelo autoboxing? 16:41
purl autoboxing is just a toy thing
dalek rrot: r43910 | whiteknight++ | branches/op_pmcs/src/pmc (2 files):
[pmc2c--] Fix Opcode and OpLib PMCs so they build and pass a few ad hoc tests I threw together.
 16:42
Coke purl, forget autobixing
purl Coke, I didn't have anything matching autobixing
Coke purl, forget autoboxing
purl Coke: I forgot autoboxing
Coke darbelo: autoboxing happens on sub/method calls, not opcodes. 16:43
Whiteknight I guess there is no way to call set_*_keyed_str directly 16:44
ops only support keyed and keyed_int
that's rediculous 16:45
darbelo Sounds like IMCC is to blame here.
16:47 cotto_w0rk joined, lucian joined
darbelo Write a ticket so we can reject it after we move to pirc ;) 16:48
Whiteknight geez, I can't even figure out now how to get a string out of this Key PMC 16:50
16:51 mikehh joined
dalek rrot: r43911 | coke++ | branches/rm_cflags/config/auto/pmc.pm:
Avoid most of the warnings in pmc compilation (for gcc, anyway.)
 16:58
17:00 iblechbot joined
darbelo Crazy idea: Rewrite pbc_merge in PIR to determine the suitability of the packfile PMCs 17:03
NotFound darbelo: Slightly less crazy: rewrite it in some HLL 17:05
darbelo Unless HLL == NQP we can't ship it in the core distribution. 17:06
NotFound darbelo: we can ship generated pir. 17:08
darbelo Yeah, but I've never been too fond of that strategy. 17:12
Whiteknight +1 from me
PIR or NQP would both be acceptable, and much preferred to the current implementation 17:13
darbelo Hmm. Maybe pbc_dump would be easier.
Tht's just inspecting, no twiddling. 17:14
NotFound Dump is a good first step 17:15
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32156), fulltest) at r43911 - Ubuntu 9.10 amd64 (gcc with --optimize) 17:20
17:34 ruoso joined 17:38 lucian joined
mikehh rakudo - make spectest_smolder #32157 - All tests PASS - parrot at r43911 - Ubuntu 9.10 amd64 (gcc with --optimize) 17:39
17:43 hudnix joined 17:49 [hudnix] joined
mikehh btw pugs seems to be at r29685 but rakudo make spectest_smolder only updates to r29188 17:51
17:52 hudnix joined 17:54 hudnix joined
cotto darbelo, good idea. Starting with pbc_dump would be a good way to flush out bugs before moving on to a tool that's part of the build. 17:57
darbelo cotto: If this turns out right, we could even make dissasembled byteode rountrip-able. 17:59
cotto Whiteknight, PMCs should use INTERP in internal VTABLE functions and METHODs.
(instead of interp)
cotto goes to w0rk 18:00
Whiteknight ah, yes. I'm normally more consistent about that 18:01
Coke someone just pointed out help.github.com/terms/ F3. that seems a little much. 18:13
18:14 cognominal joined
cotto_w0rk seen pmichaud 18:16
purl pmichaud was last seen on #parrot 19 hours, 16 minutes and 7 seconds ago, saying: (the problem would still exist if there were other subs after this one :)
darbelo 2. You must be a human. 18:19
Chimps not allowed.
dalek rrot: r43912 | whiteknight++ | branches/op_pmcs/src/pmc (2 files):
In PMCs, use INTERP instead of interp. cotto++
cotto_w0rk darbelo, ? 18:22
purl rumour has it darbelo, is there anything in config_lib.pasm that gives us enough information
darbelo Agh. Wrong window.
cotto_w0rk I figured
18:33 davidfetter joined 18:56 cotto_working joined 18:57 payload joined
Coke can someone with a non-gcc compiler give rm_cflags a shot? 19:14
I suspect it's currently broken anywhere that is not gcc.
can someone explain callcontext pmc's SET_CELL_CELL(cell) to me? that looks like a noop. 19:16
sorrty, SET_CELL_STRING(cell). looks like it does an in place cast and throws it away. 19:17
cotto_working istr that chromatic originally wrote that. I'll take a look in a minute. 19:19
19:20 lucian joined, payload joined
tewk_ Sorry for being an idiot, CallContext does have a pc struct member. 19:22
Coke I can remove it all with no test failurs.
cotto_working Coke, I'd ask chromatic about it. It does look suspiciously like a noop. 19:26
Coke (it is a noop, says the compiler)
killing it in branch... 19:27
cotto_working It might not be an intentional noop though.
That's the only reason I'd ask first.
19:30 ruoso joined 19:38 cognominal joined
Coke meh. he can revert a patch as easy as the next guy. 19:42
19:48 chromatic joined
Coke look, it's the next guy. 19:53
chromatic: my latest commit might bother you. we're not sure.
chromatic r43913? 19:54
Coke ayup 19:55
that look reasonable to you?
chromatic The diff is a little disturbing.
Coke INTVAL2PTR just does a cast, yes? 19:56
but the usage of the macro of the macro ignores the return value.
dalek rrot: r43913 | coke++ | branches/rm_cflags/src/pmc/callcontext.pmc:
Remove no-ops pointed out by extra Warnings.
 19:58
chromatic Those macros might be wrong.
Coke entirely possible... but if they're wrong, and they're noops... all tests pass doing nothing.
so I'd rather explicitly do nothing.
(all tests pass in branch after that, too)
chromatic We probably need more tests for them then. 19:59
Coke no doubt. 20:00
chromatic Sounds like I volunteered. 20:01
Coke sorry. :( 20:02
20:02 cotto_working joined
Coke you could just open a ticket and let some plucky developer grab it! 20:02
pmichaud is there a way to find out how many gc runs are occurring in a given program? 20:03
(from PIR, preferably)
Coke I think so.
moment. 20:04
pmichaud: in the meantime, have you read the github terms and conditions, specifically F3?
(you agree to pay github's legal costs.)
pmichaud hadn't noticed that item particularly, no. 20:05
Whiteknight pmichaud: take a look at t/op/string_mem.t 20:06
chromatic interpinfo 20:07
purl i guess interpinfo is the culprit there.
Coke Whiteknight++
chromatic The argument is a constant from interpinfo.pasm... GC_MARK_RUNS or GC_COLLECT_RUNS.
pmichaud okay, thanks. 20:10
I'm impressed with the improvements to GC on fib.nqp then. bacek++ chromatic++
chromatic Have you noticed a measurable difference? 20:11
pmichaud bacek posted one, and I was just wanting to confirm (getting reference)
lists.parrot.org/pipermail/parrot-d...03775.html
I get the same results on my system; it's a vast improvement over what we were getting in december, where running the .nqp version was taking twice as long as compile+run pir 20:12
20:12 cotto_working joined
pmichaud so, in december, fib.nqp was requiring 20+ seconds on my system, today it's running in 10 seconds 20:13
I was suspicious that perhaps gc had been inadvertently disabled altogether
but that appears to not be the case
chromatic I added a couple of algorithmic improvements. 20:14
pmichaud well, whatever changes have been made, they seem to avoid the problems that dynamic compilation was introducing
chromatic Yeah, that was a nasty one. 20:15
I have a similar improvement to make in the next couple of days.
Whiteknight chromatic: what improvement? 20:16
purl improvement is external to the program contruct.. knuth may be saying there is no advantage going multithread inside the program?
cotto_working Whiteknight, a good test for the op-related PMCs would be to rewrite bacek++'s hello world generator with them.
chromatic Whiteknight, the XNA trick: run GC only after allocating a threshold. 20:17
Coke oh, that reminds me: let's remove 'make hello' 20:20
cotto_working pmichaud, I'd appreciate it if you could take a look at the ops_pct branch. Configure/build as normal, run make opsc and prove compilers/opsc/t/01-parse.t.
Coke since we haven't supported directly generating a .o from .pbc in... some time.
cotto_working Coke, +1 20:21
20:21 joeri joined
Whiteknight cotto_working: bacek's hello world generator? 20:24
pmichaud cotto_working: what's the ops_pct branch?
cotto_working pmichaud, a branch to use pct-based tools to replace ops2c 20:25
pmichaud excellent 20:26
cotto_working Whiteknight, ./examples/pir/make_hello_pbc.pir
pmichaud cotto_working: I'll take a look, definitely 20:27
cotto_working much appreciated
pmichaud, bacek and I worked on it a couple months ago and I'm trying to get it up-to-date. 20:28
dalek tracwiki: v26 | coke++ | BranchDescriptions 20:36
tracwiki: trac.parrot.org/parrot/wiki/BranchD...ction=diff
tracwiki: v27 | coke++ | BranchDescriptions
tracwiki: trac.parrot.org/parrot/wiki/BranchD...ction=diff
Coke tries to build perl5i and fails. 20:42
20:44 bacek joined 20:49 kurahaupo joined
Whiteknight cotto_working: that's evil 20:52
cotto_working don't blame me. bacek wrote it. 20:53
(Though I'd argue that it's both evil and awesome.) 20:54
Whiteknight Oh, it is awesome 20:55
but the new Opcode PMC should make it less magical to compile an opcode
fewer magic numbers
cotto_working That's just was I was thinking.
Whiteknight the problem comes that to compile an opcode, we have to know whether each argument is held as a constant or in a register 20:59
urg, quite perplexing 21:00
cotto_working It's an interesting problem. For now you can at least use "say_sc" and a magic number instead of two magic numbers. 21:01
Coke anyone have cl.exe handy? 21:03
(er, the vc++ compiler) 21:04
particle coke: what do you need?
Coke particle: can you verify for me that you don't need slashes in makefiles converted to backslashes?
particle when passed as filenames to cl.exe? 21:05
or when used in "#include", or what?
Coke so we can have targets like src/gc/api$(O) and not src\\gc\\api$(O), and that yes, they work when used onthe command line.
particle that's actually cmd, not cl
Coke I'm fairly certain it's fine in targets or you would have broken after one_make merged.
particle and nmake.ext
Coke but in the build line...
particle yes, forward slashies should be ok, at least if you're not running windows 95 21:06
Coke we don't support win95.
particle yep
Coke I'm willing to go out on a limb there.
particle it's no longer a problem on win32
Coke ok. good. more crap I can rip out of the build.
cotto_working wheee
Coke rm_cflags branch currently borked on strawberry perl due to this. 21:07
particle however, some native commands like 'cd' won't work with forward slashes
Coke I don't think we should ever be using those. 21:09
(we are for the 3 remaining recursive makes, but we shouldn't be.) 21:10
particle: do you know whatever happened to our remote windows compiler access? 21:11
was it "talk to alias"?
particle yes, i don't recall it getting past that state
i suppose now that i'm no longer building parrot regularly, it's more of a priority 21:12
NotFound Whiteknight: Will not be easier to put that PMC in trunk, marking it as experimental? 21:13
Coke I pinged alias. I'll let folks know what I hear. 21:16
21:19 cotto_working joined 21:23 davidfetter joined
Coke particle : rule seems to be: if it's an argument, slashes are fine. if it's a path-to-a-command, native slashes a must. 21:35
Whiteknight NotFound: we can merge it to truk 21:36
doesnt break the build anymore
NotFound Great 21:38
Whiteknight actually fails codetests, and no coverage in t/pmc yet 21:41
Coke finds timethis.exe for windows and compares some stuff. 21:42
Whiteknight can somebody explain to me what a packfile fixup is? 21:48
cotto_working Sure.
It maps sub names to bytecode offsets. 21:49
21:50 iblechbot joined
cotto_working i.e. sub foo's bytecode starts 24 opcode_t's into the bytecode segment 21:50
Whiteknight but dont the subs themselves contain info about thestart and end offsets?
In bacek's example, the sub contains that info 21:51
cotto_working It appears to be duplicated
Whiteknight ok
21:54 payload joined
Whiteknight a packfile can have multiple of the same types of segments so long as the have different names? 21:55
particle yes
so you can, for example, have multiple data segments
cotto_working There's oddness there. Looking at pbc_to_exe.pbc with pbc_dump, the sub for main says it starts at offset 0 and ends at 161, but the fixup segment says it starts at 30 and ends at 36. 21:56
nm. The fixup table seems to be pointing at the constant table. 21:57
s/at/into/ 21:58
Whiteknight constant table? why would it point there?
in bacek's example the fixup has offset 5, but constants only go to idx 4 21:59
dalek TT #1436 created by fperrad++: Crash on Windows 22:00
22:01 cotto_working joined
cotto_working The offsets into bytecode are stored in the sub in the const table. 22:03
Whiteknight ...LOLWUT?
ah, nevermind. I see it 22:04
cotto_working Apparently end_offs isn't very important. I can delete and change it and the example runs fine.
Whiteknight so fixup points to the Sub PMC in the const table, which points to the bytecode offset
got it 22:05
cotto_working The sub init code doesn't ignore end_offs. Possibly it's only important when you have more than one sub. 22:06
yup
. o O (worst connection evar)
Whiteknight Probably used at runtime to prevent non-local jumps 22:07
cotto_working maybe a make_fib is in order. 22:14
It wouldn't be much harder.
or something more complex to flesh out what kind of abstractions we'd need for larger-scale pbc generation 22:16
Whiteknight I was just thinking that this whole process was ripe for an abstracting library 22:17
cotto_working quite 22:20
Whiteknight an add_sub() function could take the sub and an array of bytecode, and update the raw segment, constants segment, and add a fixup too in one shot
combine that with routines to build the bytecode in the first place, and we have a winner 22:21
cotto_working It could be a boon for pir/nqp-based pbc_merge and pbc_dump too.
NotFound I think end_offs is used when looking for annotations. 22:22
cotto_working self-hosting++
Whiteknight what bacek's example doesnt show is using a register
PCT could make big savings if it output PBC directly
GeJ Good morning everyone. 22:24
Whiteknight hello GeJ
cotto_working I think you don't have to do anything special to use a register other than call foo_[insp]_... and make sure there's something initialized in the register in quesstion.
hi GeJ
GeJ Hi Whiteknight
hi cotto 22:25
Whiteknight cotto_working, but the one he used was an offset into the constants table
so how does the op decide if it's a constant or a register?
darbelo Whiteknight: You can try a simple pasm example and pbc_dump it. 22:26
cotto_working Whiteknight, that's determined by which op is used.
say_sc vs say_s for example 22:27
Whiteknight cotto_working, ah, ok
cotto_working nopaste.snit.ch/19563
In that example note that all the references to the pmc use register 0 22:28
Whiteknight Imagine the runtime savings if PCT could output PMC constant aggregates in bytecode instead of having to build them at runtime! 22:29
Whiteknight starts to drool 22:30
tewk_ We just need a register allocator in nqp now :) 22:33
Whiteknight that wouldn't be too too hard, I dont think 22:37
assuming NQP could keep track of when registers are used and released 22:38
that's the hard part
chromatic Not with SSA. 22:40
darbelo We don't do SSA. 22:42
Whiteknight SSA?
purl rumour has it SSA is *fast*. or Static Single Assignment
tewk So i wrote a runloop that only allows a few safe instructions (non allocating) to execute.
Whiteknight ah, ok
tewk If you try to execute an unsafe instruction it forces the runloop off of a thread and back to the main thread. 22:43
darbelo tewk++
tewk In nother words unsafe operations are serialized on the main thread. 22:44
darbelo Nice.
cotto_working sounds safe and expensive 22:45
where's the code live?
tewk The run loop wasn't much code. I was thinking... Given Lorito's future functionality it should be possible to dynamically create custom runloops at runtime. security sandboxes etc.
cotto_working I'm always up for a new runloop.
darbelo tewk: Is this all proof-of-concept or do you expect to merge that work into trunk? 22:46
tewk cotto_working, its just a prototype, in my personal git repo.
I'm willing to push it somewhere for others to look at.
chromatic Run loops aren't much code, now.
darbelo wants to see the shiny.
cotto_working nope. chromatic++ for that work.
22:46 joeri joined
tewk I still have to fix gc and allocation. 22:47
cotto_working Well, most runloops aren't much code now.
22:47 slavorg joined
tewk I'm not sure runtime generated runloops are useful, but its a cool idea. 22:48
cotto_working In that context, what part of the runloop would be generated?
darbelo I'm all for "safe runloop sanboxing" if nothing else
tewk basically the predicate that says whether an opcode is safe or not. 22:49
chromatic Make it table-driven and it's trivial.
tewk yep, I was think crazy things like a meta runloop that could do arbitrary computations based on the bytecode stream being executed. 22:52
22:57 cotto_working joined 23:01 bacek_at_work joined
cotto_working hio bacek_at_work. Your make_hello_pbc.pir generated some good discussion. 23:02
bacek_at_work cotto_working, o hai.
What about it?
cotto_working It'll be less mysterious when Whiteknight's oplib PMCs are used to generate the opcodes, and to do more we'll need a library to take care of the low-level details. 23:03
bacek_at_work Ah. Yes, of course. 23:04
cotto_working Whiteknight++ for all the GSoC blogging. If anyone asks for ideas, there's a good chance you've covered something they'll find interesting. 23:09
darbelo We should move that into an actual 'ideas page'
cotto_working s/we/darbelo/ 23:10
darbelo s/darbelo/whiteknight/
See, I can delegate too! 23:11
Besides, I am unworthy to summarize Whiteknight's uniquely elegant prose in a way that would do it justice. 23:12
cotto_working nice try
purl indulges in a bit of evil laughter.
cotto_working A wiki page with summaries is a good idea. Maybe I'll tackle that if other Parrot stuff is too frustrating. 23:13
bacek_at_work Is "World domination" in list of GSoC ideas? 23:14
chromatic Next year.
purl next year is likely to have better beer
bacek_at_work ah, ok.
I'll apply as mentor than 23:15
cotto_working It's right after "dynamic generation of the dtrt op".
darbelo bacek++ # mentoring world domination
23:16 cotto_work joined 23:18 patspam joined
cotto_work dukeleto, where's the audio from pdx.pm talks posted? 23:37
chromatic pdxpm.podasp.com/archive.html?pname=meetings.xml 23:40
23:43 cotto_work joined
dukeleto 'ello 23:44
davidfetter hai dukeleto
cotto_work chromatic, thanks
hi
dukeleto Video of my intro to #parrot talk at #pdxpm last night: ping.fm/7rGS5 Slides: ping.fm/Qz4QO
davidfetter: ahoy!
davidfetter oh, cool
cotto_work 1.5 hours? That's a lot of parrot. 23:45
davidfetter watches
dukeleto cotto_work: indeed. people asked a bunch of questions
i think it was a success. lots of people had heard of parrot but did not know about recent advances 23:46
davidfetter is there some generic system for video + slides?
cotto_work Sweet. Maybe we'll get some more Parrot hackers out of the deal.
dukeleto one person said "i heard of it 8 years ago and that is about it", which made me laugh
cotto_work or hlls, or libraries...
dukeleto cotto_work: yes, one attendee is dead set on a new Scheme on Parrot which he calls "NoScheme" 23:47
wagle: where is your noscheme repo?
23:48 slavorg joined
cotto_work We can never have too many schemes. 23:48
or Schemes. ;]
dukeleto davidfetter: it would be nice for videos and slides to know about each other, but not that I know of 23:50
davidfetter there are some proprietary solutions that have the slides in one window and the video in another 23:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!