Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (25 to go), merge outstanding branches; profile your favorite PIR for memory leaks with valgrind
Set by moderator on 31 August 2010.
00:02 Psyche^ joined 00:08 Patterner left, Psyche^ is now known as Patterner
NotFound whiteknight: I just looked at metadata/kakapo.json 00:11
00:12 nwellnhof left
whiteknight hmmm 00:12
if I generate that file in kakapo now, it gives me parrot_setup 00:14
NotFound Can't you just hand edit it? 00:16
whiteknight I figured it out 00:19
:setup('setup.nqp')
00:24 kid51 left 00:29 ruoso joined
cotto ~~ 00:39
headerizer is broken 00:52
actually, it might just need a reconfig 00:53
yup. It's fine now.
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (24 to go), merge outstanding branches; profile your favorite PIR for memory leaks with valgrind 00:55
dalek TT #43 closed by cotto++: auto-headerize PIRC sources 01:06
TT #43: trac.parrot.org/parrot/ticket/43
TT #29 closed by cotto++: Add more files to the tutorial
TT #29: trac.parrot.org/parrot/ticket/29
moderator Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (23 to go), merge outstanding branches; profile your favorite PIR for memory leaks with valgrind 01:06
01:37 whiteknight left 01:38 hercynium left 01:45 hercynium joined 01:50 kid51 joined
dalek rrot: r48741 | jkeenan++ | trunk (65 files):
Merge detect_llvm branch into trunk. Adds configuration step auto::llvm to detect Low Level Virtual Machine (LLVM) and associated test file.
02:02
rrot: r48742 | jkeenan++ | branches/detect_llvm:
Branch has been merged into trunk and is no longer needed at HEAD.
purl i already had it that way, dalek.
02:03 GodFather joined
dalek rrot: r48743 | jkeenan++ | branches/gsoc_threads/include/parrot/threads.h:
[codingstd] c_macro_args: wrap 2 arguments.
02:19
rrot: r48744 | jkeenan++ | branches/gsoc_threads/include/parrot/events.h:
[codingstd] c_header_guards.
rrot: r48745 | jkeenan++ | branches/gsoc_threads/t/src/threads_io.t:
[codingstd] Add coda.
rrot: r48746 | jkeenan++ | branches/gsoc_threads/src/pmc/pmclist.pmc:
[codingstd] c_function_docs.
rrot: r48747 | jkeenan++ | branches/gsoc_threads/src/threads.c:
[codingstd] c_parens.
02:28 kid51 left 02:35 janus left 02:36 GodFather left 02:38 mikehh left 02:40 bluescreen joined 02:46 Infinoid left 02:48 janus joined 02:51 Infinoid joined
tcurtis Are comparisons between signed and unsigned types potentially unproductive in C? 03:02
s/unproductive/problematic/
cotto they're good to avoid 03:05
chromatic Are you looking at the packfile warnings? 03:06
03:07 mikehh joined
tcurtis There are a few other warnings about it in charsets and IMCC, also. 03:07
chromatic The problem is losing precision, if you overflow the max signed value or invalid comparisons of a negative to a positive. 03:08
Most of the warnings I've seen are using a signed integer as a loop counter compared to an unsigned "How many did we allocate?" value.
That's C for you; no one expected iterators when devising the PDP memory model. 03:09
tcurtis Is it worth changing those instances to use an unsigned loop counter? 03:11
chromatic Yes. 03:13
03:28 FullMetalHarlot joined, FullMetalHarlot left 03:31 hercynium left 03:58 ash_ joined 04:48 sri joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48747 - Ubuntu 10.04 i386 (g++) 04:54
05:28 Coke left 05:34 Coke joined 06:09 uniejo joined 06:21 cxreg left
sorear seen pmichaud 06:23
purl pmichaud was last seen on #parrot 1 days, 11 hours, 24 minutes and 53 seconds ago, saying: if spectests pass with that line removed, then +1 from me [Aug 30 18:58:07 2010]
aloha pmichaud was last seen in #parrot 1 days 11 hours ago saying "if spectests pass with that line removed, then +1 from me".
sorear msg bacek #perl6 @ irc.freenode.net needs a seen-bot
purl Message for bacek stored.
06:28 cxreg joined 06:33 jsut_ joined
dalek rrot: r48748 | mikehh++ | failed to fetch changeset:
[html_cleanup] merge trunk into branch
06:35
06:38 jsut left 07:01 chromatic left 07:04 cxreg left 07:05 cxreg joined 07:09 theory left 07:22 allison left
dalek rrot: r48749 | NotFound++ | trunk/t/src/extend.t:
rearrange other bunch of extend tests to make its coverage reports more useful
07:25
rrot: r48750 | NotFound++ | trunk/t/pmc/exception.t:
test Exception birthtime attribute and annotations method
07:42
07:58 cognominal left
dalek kudo: 606c5fb | moritz++ | src/core/operators.pm:
prevent not and so from autothreading
08:10
kudo: dc99008 | tadzik++ | src/Perl6/Grammar.pm:
Added more info to an error message for <>

Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
rrot: r48751 | mikehh++ | branches/html_cleanup/docs/index/tools.json:
[html_cleanup] fix tools.json to handle moved file
08:16
08:20 tcurtis left 08:22 mikehh left 08:44 mikehh joined 09:19 bacek joined
aloha bacek: bacek asked me to tell you Blah 09:19
10:15 cotto_work left 10:54 ruoso left 11:33 bluescreen left 11:37 preflex left 12:09 whiteknight joined 12:13 hudnix left 12:14 hudnix joined
whiteknight good morning, #parrot 12:25
kthakore whiteknight: good moin 12:41
whiteknight hello kthakore. How are you doing today? 12:48
12:50 bluescreen joined 12:54 cognominal joined 12:57 ruoso joined 13:01 nwellnhof joined 13:09 mikehh left
kthakore whiteknight: ok 13:17
whiteknight: back is killing me
I was cutting lumber yesterday
13:22 luben left 13:23 luben_work joined
particle nwellnhof: does STRING_iter_skip do the advancing part of STRING_iter_get_and_advance? if so, why not name it STRING_iter_advance for consistency? 13:44
nwellnhof you're right. that would be more consistent. 13:48
13:48 hudnix left
nwellnhof but STRING_iter_skip also supports skipping of more than one char 13:49
you can even skip backwards, so i think we should keep it 13:51
13:52 hudnix joined
particle so, is it seek rather than skip? 14:01
nwellnhof yes it's a relative seek. STRING_iter_set_position is an absolute seek. 14:02
they could be combined like fseek. 14:03
14:03 uniejo left
particle hrmm 14:04
is there a tell?
nwellnhof the string iterator API has been like that before my changes BTW. but now would be a good time to change it.
particle yes, agreed
nwellnhof "tell" is reading the bytepos or charpos element of the iterator struct. 14:05
there are no macros for that.
particle does skip go by byte or grapheme? 14:06
nwellnhof it goes by codepoint
particle actually, can you point me to where it's defined? i don't have a branch checkout atm
i'll look it up with svnweb
nwellnhof it's defined for every single encoding. which one do you want? 14:07
particle ah, so that's why it's not in encoding.h... duh
what i'm thinking, when looking at this api is: if i were implementing e.g. fast boyer-moore, what functions would i want to use? how would i do that with this api? where could this be improved{ 14:09
s/{/?/
nwellnhof you would change the "index" function for each encoding 14:10
14:11 tcurtis joined
particle i don't like STRING_length and STRING_byte_length, because the first macro assumes 'codepoint' 14:11
14:11 smash joined
smash hello everyone 14:11
particle hola smash
nwellnhof particle: what do you propose instead of STRING_length? 14:12
particle STRING_codepoint_length
put the units of measurement explicitly in the name
so later when STRING_grapheme_length comes around... nobody's upset. 14:13
nwellnhof good point.
currently, we have Parrot_str_length and Parrot_str_byte_length 14:14
that's why i chose STRING_length and STRING_byte_length
particle yes, and currently half our opcodes have underscores between words and half don't. 14:15
we're marking a deprecation point here
let's take the time to get the api right as we change it
nwellnhof yes, now would be the best time
particle i know this is somewhat beyond what you've proposed, but i can't help but respond to the nagging urge to clean up the string api 14:16
nwellnhof that's perfectly ok, i already did some cleanups
like renaming get_codepoints to substr
get_codepoint to ord 14:17
like the parrot opcodes
particle yes, it's a good form of consistency 14:18
14:19 patspam joined
nwellnhof eventually, i'd like to have the code in string.ops call those macros directly 14:19
that would save us one function call
kthakore Does parrot have different types for numbers? 14:22
I mean ... perl interchanges freely between IV,NV,PV, and the other one 14:23
nwellnhof PV isn't a number type in Perl 14:25
particle kthakore: parrot has integer, number (floating point), string, and abstract data type (pmc) registers
kthakore nwellnhof: perl interchanges between it freely 14:27
particle: okie
nwellnhof perl converts strings to numbers automatically 14:28
but i wouldn't consider PV a number type
kthakore well if I send a PV* from XS wrapped in a SV* 14:29
I can use it as a number
nwellnhof but it's converted before 14:30
kthakore sure
Coke cotto: I distinctly remember that pirc was NOT fully headerized, and that andy had given up trying to make it so. Did you verify #43 before closing, or is that running on memory?
(I may have just not been around for the very last bit of fixup on that.)
cotto That's from memory. 15:04
except that I verified that headerizer didn't generate anything that wasn't already checked in
15:07 jsut_ is now known as jsut
cotto I do remember that some others (possibly bacek) worked on headerizing it. 15:08
Coke yah. and I remember them giving up. ;) 15:09
in any case, probably worth double checking that the headerization works for all the pirc files before letting go of the ticket entirely.
I haven't touched ^/branches/pirc_config in a while, but all it did was add a configure option that controlled the setting of a C #define - it is probably mergable back to trunk, if someone wants to take it. 15:11
15:11 Andy joined
Coke ah, even better, it's a single commit. 15:13
cotto I'll do that.
15:13 theory joined
Coke some chunks failed trying to apply to trunk. ping me with problems or questions. 15:14
looks trivial, though. 15:15
15:41 patspam left 15:42 patspam joined 15:46 luben_work_ joined 15:49 luben_work left 16:11 nwellnhof left 16:35 cotto_work joined
sjn seen jnthn? 16:42
purl jnthn was last seen on #parrot 7 days, 17 hours, 35 minutes and 44 seconds ago, saying: Maybe that link needs breaking at some point. [Aug 24 23:06:43 2010]
aloha Sorry, I haven't seen jnthn.
16:44 chromatic joined 17:08 luben_work_ left 17:24 nwellnhof joined 17:34 tcurtis left
moritz jnthn is 1.5 weeks on vacations, or so 17:53
cotto_work lucky fellow
17:54 davidfetter joined, szabgab left, tcurtis joined 17:55 chromatic left 17:56 szabgab joined 18:06 chromatic joined
dalek TT #1761 created by dasx++: Inconsistent release tags 18:11
TT #1761: trac.parrot.org/parrot/ticket/1761
18:13 chromatic left 18:17 patspam left 18:18 patspam joined 18:21 macroron joined 18:23 chromatic joined, jsut_ joined 18:25 jan left 18:27 bluescreen left, ash_ left, bluescreen joined 18:28 jsut left
Coke that bug should be easily fixable by anyone with access to drupal and the release guide. 18:37
18:44 ash_ joined 18:47 jsut joined 18:52 jsut_ left 19:07 robin-gvx joined 19:17 hercynium joined
dalek rrot: r48752 | pmichaud++ | trunk/ext/nqp-rx/src/stage0 (5 files):
[nqp-rx]: Update bootstrap with DEBUG fixes for cclass-based builtins.
19:23
p-rx: 71b25e6 | pmichaud++ | src/Regex/Cursor-builtins.pir:
Add regex debugging for cclass-based builtins.
19:25
p-rx: 29ce78f | pmichaud++ | src/Regex/Cursor-builtins.pir:
Add debugging output to <alpha>.
p-rx: 5349f17 | pmichaud++ | / (3 files):
Comment out split() function for now; it causes the Parrot build to fail

is repaired.
p-rx: 699da41 | pmichaud++ | src/stage0/ (5 files):
Update bootstrap.
19:27 mikehh joined
GeJ Bonjour everyone. 19:30
cotto_work hi GeJ 19:31
GeJ servus cotto. 19:37
dalek rrot-linear-algebra: c20c635 | Whiteknight++ | src/pmc/complexmatrix2d.pmc:
start improving POD for the ComplexMatrix2D type.
19:53
rrot-linear-algebra: 973a792 | Whiteknight++ | src/pmc/complexmatrix2d.pmc:
finish the documentation for ComplexMatrix2D.pmc
rrot-linear-algebra: 0d73c5b | Whiteknight++ | src/pmc/ (2 files):
update documentation in NumMatrix2D, and make some fixes/improvements back to ComplexMatrix2D
rrot-linear-algebra: 3cc1c0d | Whiteknight++ | src/pmc/ (3 files):
...and documentation for PMCMatrix2D
19:54
rrot-linear-algebra: c2e4804 | Whiteknight++ | s (4 files):
add html_pod to the output of the build. Also, fix up some of the pod files to actually pass podcheck
rrot-linear-algebra: 0161a22 | Whiteknight++ | src/pmc/ (3 files):
add headings to the POD so the generated HTML is more usable
TimToady phone 20:00
moritz speakiing of which, it's been quite some time since I've seen some notes about the phone calls 20:02
chromatic My fault; I'll get to those. 20:03
moritz ++chromatic
20:05 luben joined 20:06 whiteknight left 20:12 jan joined, ruoso left
dalek TT #1762 created by nwellnhof++: Memory leak in Parrot_find_method_with_cache 20:16
TT #1762: trac.parrot.org/parrot/ticket/1762
TT #1763 created by nwellnhof++: Memory leak in PackFile_Annotations_new
TT #1763: trac.parrot.org/parrot/ticket/1763
mikehh All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48752 - Ubuntu 10.04 i386 (gcc with --optimize) 20:17
chromatic Sweet gorilla of Manila! 20:18
I've seen both before. I wanted to ask plobsing about TT #1763. 20:24
20:24 ash_ left
tcurtis If Rakudo doesn't work under the profiling core, is the problem likely in Parrot or in Rakudo? 20:25
tcurtis wants to know where to submit the bug report.
cotto_work probably parrot
and by "probably" I mean "" 20:26
chromatic I couldn't get all of TT #1762, but I did get some of it. 20:27
20:30 perlite left, perlite joined 20:31 robin-gvx left
Tene chromatic: you ever look at TT #757 yet? 20:32
chromatic Probably. 20:33
Oh yeah, I remember that code.
20:33 ash_ joined
dalek TT #1764 created by nwellnhof++: Infinite loop in exit handler 20:34
TT #1764: trac.parrot.org/parrot/ticket/1764
chromatic I think cloning is probably the wrong approach there. 20:35
Tene I opened that ticket way back when I was trying to get threading to work at all. I couldn't get past it, and failed at understanding what the code was doing there at all.
chromatic The basic idea is "Oh no, what if another thread modifies what the first thread thinks of as a class!"
Tene I gave up on getting threading working after attacking that for a few days.
chromatic Until we get a policy governing global modifications in threaded systems, I'm comfortable disabling cloning in general to see what happens. 20:37
It's awful code, it doesn't work, and it's probably the wrong approach to concurrency anyway.
Coke misses the phone today due to $DAYJOB 20:38
kthakore hi chromatic 20:39
chromatic howdy
kthakore So I was setting up CUDA for my project and noticed python has pyCUDA (it uses Inline C like stuff)
is an Inline possible in Perl6 or Parrot? 20:40
chromatic Parrot's made for that.
kthakore chromatic: oh man been writing the Manual. it has pretty pictures!
chromatic: really! ... will it talk subset of the C language 20:41
as OpenCL and CUDA use other compilers
nvcc
but it should be able to make a shared library
chromatic A subset of C? That's harder, but ... well Lorito and... hmm.
20:41 ash_ left
tcurtis How reliable is valgrind for finding memory leak problems? Specifically, if it's reporting at least 120-ish kb "definitely lost" on every Rakudo spectest, do I know that that's a problem? 20:41
kthakore tcurtis: you need to use a suppression script 20:42
chromatic I consider it highly reliable.
kthakore find useless memleaks and add them to suppression
tcurtis: like chromatic said for reliability
chromatic The only problem I've seen in Parrot without a suppression script is a weird dlerror() leak deep in what I think is Valgrind's ld replacement. 20:43
kthakore oh I have seen that before
that is acutally fixable
kthakore looks for linky from long time ago
issues.asterisk.org/view.php?id=16007 20:44
err
so this is another project 20:45
that uses valgrind heavily
tcurtis I ran a few of the files from examples/benchmarks and Parrot looked fine. Rakudo, not so much. Are there reasons that are not problematic for Rakudo having more than 120kb memory definitely lost?
Potential reasons, rather.
kthakore chromatic: adding pthread_exit(NULL) at the end fixes this problem
chromatic Really? Interesting. 20:46
kthakore tcurtis: what was the valgrind flags you used?
chromatic tcurtis, TT #1762 may be a culprit.
Coke msg whiteknight - preferred address for addition to directors list?
purl Message for whiteknight stored.
Coke msg dukeleto - preferred address for addition to directors list? 20:47
purl Message for dukeleto stored.
Coke msg kid51 - preferred address for addition to directors list?
purl Message for kid51 stored.
tcurtis kthakore: --leak-check=full 20:48
kthakore tcurtis: can you paste the output? 20:49
tcurtis kthakore: I'm going to leave the spectests running when I go out to eat in a while. When I get back home, I'll work on sifting through and putting the results somewhere they can be looked at. There will be a lot of output. 20:53
20:55 ash_ joined
Coke I'll just pick whatever their commonly used emails are at some point this evening if I don't hear back. NBD. 21:00
21:01 whiteknight joined
Coke nwellnhof++ #leak finder 21:02
dalek TT #1765 created by nwellnhof++: Memory leak in allocate_interpreter 21:08
TT #1765: trac.parrot.org/parrot/ticket/1765
chromatic That's a biggie. 21:17
nwellnhof i think it only happens if you create a new interpreter form PIR 21:18
s/form/from/
21:19 patspam left
chromatic Not from C? 21:19
dalek rrot: r48753 | NotFound++ | trunk/t/src/extend.t:
rearrange remaining extend tests to make its coverage reports more useful
21:20
nwellnhof no, afaics
it seems to be specific to t/op/interp_2.pir
21:21 patspam joined
chromatic You'd think ParrotInterpreter's destroy() would destroy the contained interpreter. 21:25
nwellnhof but it doesn't
easy to fix
chromatic Should do it. 21:26
(says the person who skimmed the code in between editing the Perl 6 section on advanced method dispatch)
nwellnhof hmm, there's no destroy_interpreter function 21:34
only Parrot_really_destroy 21:35
21:35 bluescreen left
nwellnhof and it doesn't work to call that from the ParrotInterpreter PMC 21:35
dalek rrot: r48754 | Paul C. Anagnostopoulos++ | trunk (3 files):
Integer neg and absolute now promote to BigInt
21:37
rrot: r48755 | Paul C. Anagnostopoulos++ | trunk/t/op/integer.t:
Integer neg and absolute now promote to BigInt (2)
chromatic That sounds like a problem.
Parrot_really_destroy() has guards if it's a child interp though. 21:38
NotFound Parrot_destroy, Parrot_exit, and the way they are documented and used need some love. 21:39
chromatic Most of src/interp/ needs attention.
nwellnhof calling Parrot_really_destroy from the PMC causes a crash in miniparrot 21:40
ok, not so easy to fix 21:41
NotFound The PMC is an envelope, you can't be sure that the Interpreter is owned bty it. 21:42
dalek TT #1616 closed by Paul_the_Greek++: t/pmc/bigint.t: implement 2 todo-ed items: Minint conversions
TT #1616: trac.parrot.org/parrot/ticket/1616
NotFound And the interpreter itself isn't garbage collected, so there is no easy solution. 21:43
chromatic Only the case where the PMC has created the interp matters, right? 21:44
nwellnhof i think so 21:45
NotFound I'm not sure, the interpreter mau remain active after the PMC is out of scope 21:46
chromatic We can steal one of the PMC flags.
21:48 Paul_the_Greek joined
Paul_the_Greek Grump. svn commit does a commit even if you list a file that has no changes. It should complain. 21:49
cotto_work orly? 21:50
purl YA RLY.
cotto_work I thought it ignored any unchanged files. 21:51
21:51 kthakore left
Paul_the_Greek It does. But obviously I typed the wrong file if it has no changes, so it should complain. 21:51
No real harm done, except there are two revisions for my one change. 21:52
Say, another question: I have gnu patch. Is there some trick to getting it to understand our patch file format? 21:53
cotto_work It should be fine without any special magic.
Paul_the_Greek I enter patch <patch-file 21:54
It doesn't recognize the Index: lines, so it asks me which file for each patch.
cotto_work how did you get patch-file, i.e. what command?
NotFound The problem with git diffs is the a/ and b/ prefixes 21:55
Paul_the_Greek I tried it with one I made (svn diff) and one someone else made attached to a ticket. 21:57
Same problem in both cases.
Once you tell it the file(s), the patches are applied correctly.
There are some patch options that sound interesting, but I don't know patch-speak. 21:58
chromatic alias ap='patch -p0 <'
alias gp='patch -p1 <'
ap means "Apply patch"
gp means "Apply patch generated by Git"
Paul_the_Greek How does -p0 differ from not specifying it at all? 21:59
chromatic Consistency in my .alias file. 22:00
Paul_the_Greek I will try -p0 next time. Adding to alias file ...
chromatic alias realias='chmod u+w $ALIASES; $EDITOR $ALIASES; source $ALIASES; chmod -w $ALIASES' 22:01
NotFound The man page says that omiting -p uses the filename without any dir in the path 22:02
Paul_the_Greek I just tried the same patch again with that option and I got a failed assertion in patch.c. That's amusing. 22:04
chromatic Sometimes I also think about taking up goat farming. 22:05
Paul_the_Greek I'll play with it some more later.
I'd go with llamas.
chromatic There's an alpaca farm down the road here.
22:05 mikehh left
Paul_the_Greek Where are you? 22:05
chromatic Up the road from the alpacas.
Paul_the_Greek And I can't get there from here? 22:06
particle realias doesn't pull/push to a github repo of dotfiles? for shame!
Paul_the_Greek chromatic: Not sure we can improve Boolean, but I'm going to take a look at it over the next few days.
chromatic If you can get a plane to PDX, take the red or blue line MAX west and stop at Sunset TC. Then take a shuttle up the hill. My office is up the hill from the lake.
Paul_the_Greek Sounds nice. Never been out that way. 22:07
chromatic If you ever make it out here, maybe you can help me move a piano. 22:08
Paul_the_Greek No, sorry, you would hear very bad sounds from my spine.
I can help you hire someone, though. 22:09
chromatic Ah, I already have percussive instruments.
22:09 patspam left
Paul_the_Greek Moving pianos is best done by professionals. 22:09
22:09 mikehh joined
NotFound Software syntesizers are easier to move. 22:09
22:09 patspam joined
Paul_the_Greek To make sure I understand: If I stop Boolean from inheriting from Integer or Scalar, it will inherit from Default? 22:10
NotFound I even have one in my pocket.
chromatic Yes, that is correct.
Paul_the_Greek Okay.
chromatic All PMCs inherit from default, even if they don't mention it. They may inherit directly or through a parent, but they all ultimately inherit from default. 22:11
NotFound Default is the default. Sometimes we are consistent ;)
Paul_the_Greek That is a reasonable name for the default, I must admit. 22:12
Looking at Scalar's logical_and ... strange. logical_xor ... stranger. 22:15
22:15 patspam left
Paul_the_Greek Off for dinner, then some investigation. 22:16
22:16 Paul_the_Greek left, nwellnhof left 22:25 mikehh left
dalek rrot: r48756 | NotFound++ | trunk/t/pmc/stringiterator.t:
test StringIterator get_pmc vtable
22:29
22:30 macroron left 22:32 jsut_ joined 22:37 jsut left, ash_ left
chromatic lambda-the-ultimate.org/node/4058 23:18
Articles on Precise GC with Parametric Polymorphism
23:19 TiMBuS left 23:20 TiMBuS joined
cotto_work That sounds too shiny not to look at. 23:21
LtUU++
LtU++
chromatic academic.research.microsoft.com/Pap...58308.aspx 23:22
23:25 mikehh joined
whiteknight nice page 23:26
23:27 jsut joined
chromatic I keep meaning to read that article. 23:27
whiteknight that's one I actually haven't seen yet, I don't think 23:29
It's interesting the comment about Mono's GC, and how their JIT doesn't play nice with a precise stack trace 23:30
my one dream for Parrot is to get rid of walking the C stack entirely 23:31
chromatic What C stack?
whiteknight *the* C stack
there aren't many to choose from
23:31 jsut_ left
chromatic I know what the C stack is. I'm just wondering why your dream for Parrot includes it. 23:31
whiteknight my dream for parrot excludes it. We shouldn't be walking it. Ever 23:32
chromatic Okay, good.
whiteknight Lorito should, *should* make it go away
although we run into a hell of a lot of problems in extensions
chromatic That was like saying "My dream for my life includes not getting into slap fights with *clowns*." 23:33
Why would you want to get into slap fights with anyone?
whiteknight Well, there are some people that just might deserve it
Justin Beiber, Tiger Woods, most US senators 23:34
chromatic My IRC client doesn't yet support the RSP. More importantly, neither do the clients of the people who most deserve it.
whiteknight RSP?
purl RSP is the most trivial perl code inverter possible. or remote strangulation protocol.
chromatic I've still never heard Justin Bieber, but I had the TV muted and saw him in a music video with that little girl from the new Karate Kid movie. 23:35
whiteknight The problem with a GC that never walks the C stack though is that your JIT is going to have a hard time with it 23:36
really, JIT wants to write it's own control flow. The resulting machine code won't look anything like the lorito runloop 23:37
chromatic Only if you pass GCables to extensions that use the C stack.
whiteknight the JIT will be descending into ops and API calls using the C stack. It won't be using a friendly runloop 23:38
and Lorito methods may be block-compiled into functions. or traces might be
chromatic Why would the JIT use C semantics?
whiteknight they aren't C semantics. They're the semantics of the underlying machine, and the machine code that the JIT generates 23:39
we could come up with a crazy system with jumps and no call/ret, but that seems to take more work than it provides benefit
C is just a shitty, mostly portable overlay of the metal
and most modern processors have been designed specifically to support and optimize for programms written in C 23:40
where the semantics differ is that we might not be passing parameters on the stack
23:45 chromatic left 23:48 chromatic joined
chromatic The places I've seen C beat out every other language on a real-world program are places where someone's written a custom Scheme that emits the world's ugliest C code (and I've patched Perl 5 itself and read a patch to PHP once) that no one sane would write. 23:48
whiteknight no argument there.
chromatic I don't want to assume that our JIT will optimize things to standard C function calls. 23:49
I'm not sure that's a good way to JIT a pervasively CPS program.
whiteknight I don't either. But making the assumption that we can completely avoid call/ret machine codes is foolhardy
those aren't going away
chromatic ... especially a program intended to achieve parallelism through pervasive CPS.
23:49 smash left
chromatic I'd honestly rather have the JIT emit *something* (register a bitmap for an area of the heap, for example) when it emits code to leave the area of precision and unregister it when it reenters than walk a stack or heap. 23:53
That's really the problem: we lose precision at the boundary of untrusted code. 23:54