Parrot 1.9.0 "Blue-fronted Amazon" released! | parrot.org | Priorities: Add deprecations for 2.0; test platforms; check with HLL implementors | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 9 January 2010.
00:03 cognominal joined 00:05 tetragon joined 00:07 jan joined 00:23 lucian joined
chromatic www.vitanuova.com/inferno/papers/dis.html 00:26
www.lua.org/doc/jucs05.pdf (the implementation of Lua 5) 00:28
ash_ chromatic: do you know if anyone's doing anything with the stack frame builder? i know plobsing made a libjit stack frame builder a while back, but it never got put into the parrot repo 00:30
Tene I haven't heard about any recent work on it. 00:31
chromatic Me neither. He's around frequently; he might know more. 00:32
ash_ one thing he did in his was make the stack frame a config option, i have been thinking of toying with an llvm stack frame builder for a comparision, was going to try to follow his method of making it a configuration option 00:35
chromatic That's very doable. 00:37
I'm sure it's in a branch somewhere.
00:41 dukeleto joined
dukeleto 'ello 00:41
ash_ i see there is a detect_llvm branch 00:42
anyone know if thats being worked on?
dukeleto ash_: i think maybe plobsing was working on that a while ago? 00:43
kid51 ash_: I am the author of detect_llvm branch. 00:44
chromatic That's the configure probe, I believe.
kid51 That was done to provide functionality to do what branch name suggests ... 00:45
ash_ it simply detects if you have the llvm?
kid51 ... but was/is intended to be merged into trunk only when other aspects of LLVM are ready to rock 'n roll.
See trac.parrot.org/parrot/ticket/1075 00:46
See also: trac.parrot.org/parrot/ticket/1105#comment:36 00:49
ash_ kid51: I was thinking of taking a stab at an llvm based stack frame builder 00:50
kid51 You're welcome to take a shot at it. All that the detect_llvm branch was designed to do was to say "Yup, I've got an LLVM" or "Not". 00:51
It's completely independent of any use we would make of an LLVM.
See also the libjit_framebuilder branch.
ash_ well, that was the first thing i was going to do, so hey thats awesome
is that like plobsing's git repo? i have seen that with the libjit frame builder 00:52
kid51 Once we actually decide to make use of an LLVM somewhere, then we can merge the configure probe to trunk.
No, there's a branch in our repository: trac.parrot.org/parrot/browser/bran...amebuilder 00:53
But consult with plobsing about that branch.
00:53 nopaste joined 00:59 cconstantine joined 01:02 abqar joined 01:12 nopaste joined 01:16 theory joined 01:21 bacek joined 02:06 bacek joined 02:08 urkle joined 02:09 mikehh joined
cconstantine Is it possible to have PAST default vars to a scope of 'package' instead of 'lexical' if the var can't be found? 02:10
02:26 japhb joined 02:31 JimmyZ joined 02:42 nopaste joined
dukeleto 'ello 02:46
cconstantine hi 02:50
JimmyZ hello 02:54
purl what's up, JimmyZ.
03:03 abqar joined
dukeleto there is talk of having parrot+RTEMS as a GSoC project this summer. could be interesting 03:03
03:17 nopaste joined 03:19 Hunger joined
cconstantine RTEMS? 03:20
purl well, RTEMS is the Real-Time Operating System for Multiprocessor Systems, see www.rtems.com/ for more.
cconstantine oh fun
I'm writting a pir multimethod that needs to dispatch on PAST::Var... and I can't seem to get it to match the type... Could I get some help? 03:21
I'm specifying the type as 'PAST;Var'
03:27 nopaste joined 03:37 nopaste joined 03:47 nopaste joined 03:48 GeJ joined 03:51 nopaste joined 03:58 bacek joined 04:02 nopaste joined
Tene cconstantine: that's not going to be right. that's a class with a semicolon in it. 04:10
cconstantine it's PAST::Var in NQP, but 'PAST::Var' doesn't work either 04:11
Tene Because that's a class with two colons in the name.
lemme look.
use a key. 04:13
:multi(['PAST';'Node'])
cconstantine aahh, lemme try that 04:14
that did it! :) 04:15
yay thanks :)
04:30 bacek joined 04:55 coke joined
Coke . 04:56
davidfetter , 04:58
04:59 cognominal joined 05:22 plobsing joined 05:35 davidfetter joined 05:57 bacek joined 05:58 cotto joined 06:24 chromatic joined 06:25 JimmyZ joined
cotto chromatic, did you take a deeper look at the id-objects paper? It an interesting idea, but I'm finding that I don't know Parrot well enough to say if anything from the paper could be applied with a net gain to Parrot. 06:36
chromatic Was that the new approach to vtables in C? 06:37
cotto yes, though I don't think anything precludes other languages 06:38
chromatic Right. 06:44
cotto I like the idea of a highly-flexible object system like that, but I don't know what benefits Parrot could get from it. Current VTABLE functions are already pretty fast and any implementation would still have to implement PCC for methods and subs. 06:52
chromatic I'd like to unify all of those. 06:53
...
chromatic watches tumbleweeds tumble
cotto Wouldn't that stick us with a speed penalty on VTABLE function calls? 06:55
I guess that's an implementation detail to be hashed out once a system is proposed. 06:56
chromatic There's already a speed penalty on VTABLE calls. 06:58
At least one.
purl i think at least one is NO THERE CAN ONLY BE ONE, HIGHLANDER!
cotto the pir/c boundary?
chromatic That's the biggest one, but there's always the pointer dereference and check. 07:03
cotto I have trouble seeing how VTABLE functions cause c/pir boundary pain. In methods it's clear because of all the PCC goop that pmc2c has to add but the VTABLE functions are simple and have known signatures. 07:10
chromatic Call a VTABLE from PIR.
*Override* a VTABLE from PIR. 07:11
07:11 uniejo joined
cotto What's the code path for those? 07:11
chromatic Calling a VTABLE from PIR always goes through an opcode, which thunks from PCC to CCC. 07:12
Overriding a VTABLE from PIR goes through a thunk which goes the opposite way. 07:13
07:55 iblechbot joined 08:11 mikehh joined 08:13 cognominal joined
chromatic msg pmichaud Please see r43451, per our discussion earlier. 08:13
purl Message for pmichaud stored.
GeJ Does anyone know who's behind the parrot account on identi.ca? 08:15
dalek rrot: r43450 | chromatic++ | branches/pge_no_namespace_methods:
Branch to port PGE not to fetch methods directly from NameSpaces
 08:16
rrot: r43451 | chromatic++ | branches/pge_no_namespace_methods/src/global.c:
[src] Made fetching a method from a NameSpace throw an exception. This is a

directly from namespaces. When TT #389 gets fixed, that won't work. Remember not to merge this commit back to trunk.
rrot: r43452 | chromatic++ | branches/tt389_fix/runtime/parrot/library/Stream/Base.pir:
[library] Made Stream::Base work with TT #389 fix.
chromatic GeJ, I believe that's dukeleto.
GeJ chromatic: thanks.
08:40 fperrad joined 09:42 nopaste joined 09:43 AndyA joined
chromatic doc.cat-v.org/plan_9/IWP9/2008/inferno_DS.pdf 09:48
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31666), fulltest) at r43452 - Ubuntu 9.10 i386 (g++ with --optimize) 09:51
chromatic: Interesting - do we have a parrot on Inferno - has anyone tried 09:56
09:58 bacek joined 09:59 payload joined
chromatic Not to my knowledge. Most of my interest is in Dis; they have some very good ideas there. 10:02
10:07 nopaste joined 10:14 fperrad joined 10:15 aninhumer joined 10:21 bacek joined 10:24 riffraff joined
bacek o hai 10:26
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31667), fulltest) at r43452 - Ubuntu 9.10 i386 (gcc) 10:27
hi bacek
bacek aloha mikehh 10:28
mikehh bacek: I have been putting some GC notes on the wiki - are they any use - that is should I continue with more? 10:29
bacek mikehh, erm. I didn't check them. url? 10:30
mikehh or chromatic, for that matter
chromatic I saw them; they look useful. 10:31
mikehh trac.parrot.org/parrot/wiki/Copying...eCollector
trac.parrot.org/parrot/wiki/Cheneys...gCollector
10:32 nopaste joined
bacek mikehh, in parrot case research.microsoft.com/en-us/um/peo...oEntry.pdf can be quite useful for implementing Generational GC. 10:33
mikehh I put a link to the first in Development Work Pages on the front page of the wiki and the first has a link to the second
bacek So, you can put some extract from it.
mikehh I have some more notes on (mainly the algorithms) on Generational etc. 10:34
bacek mikehh, actually SPJ's work is based on Cheneys work (as most of them)
mikehh yes - I got a book on the subject and been working through it - www.cs.kent.ac.uk/people/staff/rej/gc.html 10:36
chromatic We have a precise collector; we don't have to scan the whole heap. 10:37
mikehh It is a little old but the new book is only out later this year
chromatic (We do have to scan processor registers and the C stack frames.)
mikehh I think I got that so far 10:38
chromatic Oh, now I understand bacek's comment about vtable modifications and eliminating write barriers for copying.
Clever.
mikehh there is been some interesting work being done on GC in go 10:41
bacek chromatic, indeed. I was pretty impressed. So simple idea which actually will work. 10:42
chromatic, when 2.0 release scheduled? 10:43
found it... I will not be able to finish gc_encapsulate... 10:45
11:03 clinton joined 11:53 bluescreen joined 12:06 cconstantine joined 12:16 ruoso joined 12:22 payload joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31669), fulltest) at r43452 - Ubuntu 9.10 i386 (gcc with --optimize) 12:25
12:25 cognominal joined 12:27 payload joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31674), fulltest) at r43452 - Ubuntu 9.10 i386 (g++) 12:34
At the moment all test PASS on all variants on Ubuntu 9.10 i386 12:35
heading back to amd64 to complete the testing there
12:50 payload joined, mikehh joined 13:22 lucian joined 13:46 perlpilot joined 13:56 payload joined 14:12 nopaste joined, TonyC joined
TonyC nopaste it out of most channels until my link is fixed, the web interface is still there 14:18
14:19 iblechbot joined, ruoso joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31686), fulltest) at r43452 - Ubuntu 9.10 amd64 (gcc) 15:02
15:03 bubaflub joined 15:09 Psyche^ joined
tewk_ reference? bacek's comment about vtable modifications? 15:12
15:42 zak__ joined 15:44 fperrad_ joined 15:57 zak__ joined 16:03 plobsing joined 16:04 clinton joined 16:05 whiteknight joined 16:08 fperrad_ joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31688), fulltest) at r43452 - Ubuntu 9.10 amd64 (g++) 16:18
16:20 jsut joined 16:48 payload joined 16:51 theory joined
dalek a: af6556b | fperrad++ | t/lua-TestMore:
update submodule lua-TestMore
 16:54
16:54 davidfetter joined 17:09 cotto_work joined 17:37 frodwith joined 17:46 plobsing joined 17:50 bluescreen joined
cotto_work good morning 18:14
dalek rrot: r43453 | plobsing++ | trunk/DEPRECATED.pod:
add formal deprecation of 'vv' (and similar) nci parameter signatures as per PDD16
 18:16
Coke plobsing: re r43453 - a ticket would be nice. 18:18
(especially since the string "xv" doesn't appear in the referenced file. 18:19
plobsing search for deprecated
Coke ok. what's the x?
purl the x is Y or absolute delta, in Befunge-98 or x11. or shit or ...
plobsing any valid return sig char. 18:20
v in return position is still valid. v in argument position is deprecated.
that's why the x is necessary
Coke and that isn't clear in the notice. the primary notice for the deprecation should be a ticket, both the PDD and the pod file should refer to that ticket. 18:21
plobsing ok. creating.
purl well, creating is no prob...I'm just trying to understand config better...
Coke (please also add an [eligible in 2.1] in deprecated.pod)
plobsing: danke.
dalek TT #1410 created by plobsing++: [DEPRECATED] 'v' as an nci argument signature 18:29
rrot: r43454 | plobsing++ | trunk (2 files):
Add TT reference and eligibility to 'xv' deprecation
 18:32
18:53 mj41 joined 18:58 joeri joined 19:01 riffraff joined 19:08 darbelo joined 19:31 ruoso joined 19:34 plobsing joined 19:36 chromatic joined
Coke chromatic: hio 20:06
chromatic hello 20:09
purl hi, chromatic.
dukeleto a darn fine morning/afternoon it is 20:15
20:24 bacek joined 20:29 solarion joined 20:44 whiteknight_ joined
GeJ Good morning everyone. 20:54
21:03 cotto_w0rk joined 21:05 TonyC joined
Coke BOOYAH 21:06
21:09 plobsing joined 21:10 cotto_working joined 21:11 riffraff joined 21:42 japhb joined 21:46 patspam joined
bacek_at_work Good morning 21:50
cotto_working good day 21:51
purl every day above ground is a good day or I love the smell of napalm in the morning. It's the smell of victory.
cotto_working Those underground days aren't so bad either.
21:57 plobsing joined 22:16 joeri left 22:21 Whiteknight joined 22:26 iblechbot joined 22:31 TonyC joined 23:05 cconstantine joined 23:06 fperrad_ joined 23:10 PerlJam joined, Coke joined 23:11 dalek joined, nopaste joined 23:24 fperrad_ joined 23:27 fperrad__ joined 23:30 Psyche^ joined 23:32 cconstantine joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!