Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets; merge branches; review Git conversion plan
Set by moderator on 7 September 2010.
whiteknight is there a standalone, pure-parrot POD parser? 00:00
Coke tools/dev/ops_not_tested.pl
that probably doesn't need it.
(also, shouldn't that be a .t?)
Paul_the_Greek What if some configuration program ever asked for all the files in a directory tree? Then it will get backslashes.
Coke whiteknight: not SFAIK. trivial to write one in nqp, though.
Paul_the_Greek: assuming that is true... so? 00:01
is that configuration program written in perl5?
Paul_the_Greek Then it would be the case that matching only / would fail.
Coke (if so, it's using File::Spec, if that matters)
Paul_the_Greek Does Perl5 changed \\ to / ? 00:02
Coke perl5 has modules to deal with that.
Paul_the_Greek Just wondering if we could ever get a \\ programmatically.
Coke if it ever comes up, we have {slash} 00:03
dalek p-rx: 7188f73 | pmichaud++ | src/NQP/ (2 files):
Initial version of trait_mod:is and "is pirflags" trait for subs.
p-rx: f3dabb7 | pmichaud++ | src/NQP/ (2 files):
Add traits to method definitions.
p-rx: 95acd86 | pmichaud++ | t/nqp/52-vtable.t:
Add tests for "is pirflags<:vtable(...)>".
p-rx: e528a3d | pmichaud++ | t/nqp/52-vtable.t:
Oops. Failing to plan() is like planning to fail().
Coke in fact, headerizer should be rewritten to avoid that regex entirely and use File::*... but it's probably not worth it. 00:04
Paul_the_Greek Yes, someone else was complaining that this is really the wrong solution to the problem.
sorear whiteknight: what kind of POD do you want to parse? Parrot uses all three
whiteknight sorear: there are types?
sorear POD5 (in our Perl5 and C), POD6 (in our NQP), and PseudoPOD (in docs/book) 00:05
Paul_the_Greek In my makefile: PERL = c:\\strawberry\\perl\\bin\\perl.exe 00:06
pmichaud nqp-rx can now create vtable methods :)
Paul_the_Greek And this gem: LINKARGS = $(LDFLAGS) $(LD_LOAD_FLAGS) "C:/Parrot/Develop/parrot\\libparrot.dll"
Take it easy, folks. See you tomorrow. 00:08
00:08 Paul_the_Greek left
whiteknight pmichaud++ 00:10
pmichaud: did you ever take a look at that HLL patch I msg'd you? 00:11
I haven't wanted to play with it any further if you don't think I'm going in a good direction
pmichaud whiteknight: oops, no, I didn't. I think it's still in my purl messages though.
dalek rrot: r48893 | coke++ | trunk/tools/dev/headerizer.pl:
add a little more explanation about why we need this both ways. minor code change.
rrot: r48894 | nwellnhof++ | trunk (3 files):
Use Hash instead of Hash PMC in PackFile_ConstTable
pmichaud I'd like to finish what I'm working on now (a data_json replacement) 00:12
whiteknight pmichaud: that's okay, no rush. I've got plenty of other projects to keep myself busy too
pmichaud then I can look at the patch to see if it's in the right direction :)
cotto_work nwellnhof: does that hash get destroyed anywhere?
whiteknight thanks, I would really appreciate it
cotto_work (referring to r48894)
nwellnhof cotto: i just noticed that, too. wait for my next commit. 00:13
cotto_work nwellnhof++
dukeleto seen Austin_Hastings 00:15
purl Austin_Hastings was last seen on #parrot 30 days, 22 hours, 30 minutes and 57 seconds ago, saying: also <tt> [Aug 10 01:44:38 2010]
aloha Sorry, I haven't seen Austin_Hastings.
dukeleto seen Austin
purl Austin was last seen on #parrot 26 days, 16 hours, 13 minutes and 44 seconds ago, saying: bah. ww [Aug 14 08:02:00 2010]
aloha Sorry, I haven't seen Austin.
whiteknight what is \\h in NQP grammar? 00:19
dukeleto whiteknight: i think \\h is horizontal whitespace in Perl 6 00:20
bacek_at_work horizontal space
whiteknight okay, thanks
I was going to try to copy the POD parsing stuff out of the NQP compiler, but it's way over my head right now 00:21
dalek rrot: r48895 | nwellnhof++ | trunk/src/packfile.c:
Don't forget to free the hash in PackFile_ConstTable
 00:28
pmichaud and it's POD 6, if that makes a different.
*difference.
whiteknight I'm thinking about giving up on POD entirely for this. Converting what I have into good-looking HTML is turning out to just be way too much work 00:32
00:32 davidfetter joined
whiteknight I can probably convert it all to textile without too much effort. 00:33
whiteknight is going to bed. Will think about it tonight 00:39
00:39 whiteknight left
cotto_work clock? 00:43
purl cotto_work: LAX: Thu 5:43pm PDT / CHI: Thu 7:43pm CDT / NYC: Thu 8:43pm EDT / LON: Fri 1:43am BST / BER: Fri 2:43am CEST / IND: Fri 6:13am IST / TOK: Fri 9:43am JST / SYD: Fri 10:43am EST /
cotto_work early to bed..., I guess
00:52 Coke left
dalek rrot: r48896 | nwellnhof++ | trunk (2 files):
Add PARROT_NOINLINE to valid headerizer macros
 01:02
NotFound I think I've finally got a fix for amd64 --optimize 01:04
cotto_work NotFound++ 01:06
NotFound It was StringBuilder, after all.
01:07 tcurtis left
NotFound r48897 01:09
pmichaud gist.github.com/572880 # a JSON compiler written in nqp 01:11
gist.github.com/572883 # some samples 01:12
oh, I can do a little better here. 01:13
NotFound pmichaud: that's been fast 01:14
pmichaud gist.github.com/572889 # better version of json.nqp -- autoprint now calls _dumper automatically when in interactive mode. 01:17
01:18 AzureSto_ left
dalek rrot: r48897 | NotFound++ | trunk/src/pmc/stringbuilder.pmc:
use appropiate string memory management functions instead of rolling its own in StringBuilder
 01:18
01:19 AzureStone joined
pmichaud yeah, I'm happy with json.nqp. Only took me an hour to write (I detoured to implement 'pirflags' trait in NQP :) 01:19
01:20 dalek left, GeJ left, GeJ joined, TiMBuS left, mj41_ joined 01:21 Themeruta joined, particle1 joined, Hunger left 01:22 nwellnhof_ joined, dalek joined, TiMBuS joined 01:23 particle left, nwellnhof left, Hunger joined, NotFound left, nwellnhof_ is now known as nwellnhof 01:24 Coke joined 01:25 Themeruta is now known as NotFound, mj41 left, mj41_ is now known as mj41
cotto ~~ 01:26
nqp-rx: a tool that allows pmichaud to write compilers faster than previously though to be possible 01:28
NotFound Can someone confirm the fix for amd64 --optimize?
01:28 nwellnhof_ joined 01:29 dalek left
NotFound Now we just need a comparable tool for writing compiler's user manual ;) 01:29
pmichaud actually, I'm thinking this might serve as the basis for a great nqp tutorial.
01:30 dalek joined
pmichaud it's relatively short, includes a protoregex, does compilation (to PIR now, can also make it go straight to data) 01:30
01:30 particle1 left
pmichaud the only really complicated part is the creation of hashes, since PCT doesn't support those natively. 01:31
01:31 s1n left
cotto it compiles to pir that generates the data structure? 01:31
NotFound pmichaud: and you can show the pir version to compare size and legibility.
pmichaud cotto: yes -- e.g. if you needed to embed into a larger program
so it's an example of a code generating compiler, but with a couple of additional methods it could also go straight to a data structure. 01:32
(bypassing the pir)
NotFound I *need* a confirmation. I've been fighting this beast for hours!
pmichaud NotFound: one moment
01:32 dngor left, krunen left, dngor joined, autark left 01:33 autark joined, treed left, treed joined, krunen joined, ascent left, particle joined, ascent joined, nwellnhof left, sorear left, smash left, sorear joined, perlite left, nwellnhof_ is now known as nwellnhof, smash joined, Coke left, Coke joined, perlite joined, jsut left, cosimo left, dukeleto left, Util left, jsut joined, cosimo joined 01:34 TiMBuS left, s1n joined, TiMBuS joined
dalek rrot: r48898 | NotFound++ | trunk/tools/dev/nci_thunk_gen.pir:
avoid svn playing with the Id mark for the generated files in nci_thunk_gen
 01:35
p-rx: 129c25b | pmichaud++ | examples/json.nqp:
Add json.nqp, an example of a JSON compiler written entirely in NQP.
 01:36
01:38 particle1 joined, Util joined 01:39 particle left, slavorg left, slavorg joined
NotFound pmichaud: here goes other difference between git and svn builds 01:42
01:43 davidfetter left, dukeleto joined 01:44 plobsing left 01:45 perlite_ joined, plobsing joined, smash left, smash joined, krunen left, theory left, krunen joined, theory joined, perlite left
pmichaud parrot r48897 builds on my machine okay 01:51
running parrot tests and rakudo spectests
all parrot tests pass on 48897 01:52
(rakudo spectests take a little longer)
testing nqp with 48897
cotto NotFound, what are you referring to? 01:55
pmichaud rakudo builds on r48897
01:55 Hunger left
pmichaud it's looking really good 01:55
01:55 Hunger joined
NotFound Sorry for the speed. I hope that now with the problem located a better solution can be found. 01:55
pmichaud it doesn't seem to be that much slower, at least not yet.
urg, I'm getting spectest failures in rakudo :-( 01:56
NotFound cotto: The git/svn thing? r48898
cotto Yeah. That's a fun one. 01:58
pmichaud drat.... my son shutdown the laptop while I was in the middle of the spectest run :-( 02:01
trying again
oh 02:02
cotto's fix for get_class breaks Rakudo
cotto sad face 02:03
purl ā˜¹
pmichaud gist.github.com/572939
cotto Do you know how to fix that or should I dig in? 02:04
pmichaud looking 02:05
but I suspect it means we need a revert+deprecation
cotto whee
02:08 kid51 joined
kid51 ~~ 02:09
cotto let me know if you want me to back it out and add a proper deprecation notice 02:14
pmichaud I'm not sure exactly why it's failing.
NotFound winxed build and pass tests, plumage builds and works fine with trunk in amd64 --optimize
pmichaud and using --trace=1 is giving me segfaults. 02:15
we fail a lot of 'isa' checks, though.
anyway, backing out the change seems to be most expedient. 02:17
cotto I'll do that.
pmichaud afk for a bit -- errands
NotFound And plumage successfully fetches and builds rakudo. trunk looks stable enough for me. 02:20
cotto pmichaud, reverted 02:33
02:35 janus left 02:39 Coke left
dalek rrot: r48899 | cotto++ | trunk/src/oo.c:
back out the functional part of r48851, which broke Rakudo
 02:42
kid51 Darwin/PPC: make test PASS at r48898 02:50
GeJ /e/winw
pmichaud cotto: testing
kid51 Linux/i386 (no --optimize): make fulltest pass at r48898 (absent codingstd tests which I'm now correcting) 02:51
GeJ grumph.
02:52 theory left
dalek rrot: r48900 | jkeenan++ | trunk (2 files):
[codingstd] No trailing whitespace.
 02:59
rrot: r48901 | chromatic++ | branches/hash_inlined_func/src/hash.c:
[hash] Fixed annotations for hash_compare().
rrot: r48902 | NotFound++ | trunk/t/pmc/lexinfo.t:
more tests for LexInfo
03:07 janus joined 03:22 kid51 left
dalek rrot: r48903 | jkeenan++ | branches/hash_inlined_func/src/hash.c:
[codingstd] No trailing whitespace. Fix perlcriticisms.
 03:33
cotto pmichaud, two of the tests fail but the exception doesn't get thrown. Is that what you'd hoped for? 03:35
dukeleto hola 03:36
purl hey, dukeleto.
cotto good evening, dukeleto 03:39
pmichaud cotto: (had to run errand -- just got back) 03:40
yes, I get two errors also. Looking.
Yes, that's much better than I was getting earlier.
03:43 tcurtis joined
pmichaud something looks wrong with method dispatch, though. 03:44
oh.
I think we can declare the two remaining failures to be Rakudo bugs. It's weird that they show up now and didn't before, however. 03:48
cotto There have been intervening changes. 03:52
pmichaud yes, but I don't see which change would explain this.
what's happening is that the .trans method from Parrot's String PMC is now being called in preference to the .trans method on Rakudo's Str type 03:53
cotto The only part of the change I didn't revert was the docs fix.
pmichaud where previously it was the other way around.
I don't think it's related to the change you made; I'm guessing it's some other change over the past 7 days that has caused the difference.
(Rakudo hasn't built from trunk since Sep 2)
cotto Why don't we have a big red siren going? 03:54
pmichaud well, it probably built with versions of parrot after Sep 2... but we hadn't needed to bump PARROT_REVISION until a few days ago
so I just know that something changed between 48768 and current head that is causing string dispatch to act differently. 03:55
s/string dispatch/methods on String/
dukeleto pmichaud: sounds like bisect to the rescue 03:57
pmichaud bisect won't help here.
because there were unrelated errors blocking the build. 03:58
dalek parrot: 4c20d42 | leto++ | / (2 files):
Clean up data marshalling code since rakudobugs have been fixed; add a test for Mu
pmichaud bisect only helps if there's *one* problem.
dukeleto pmichaud: you can exit bisect with a special exit code if the build doesn't work
pmichaud: bisect is very flexible
pmichaud: you can only choose to exit with a passing exit code for some arbitrary condition
pmichaud dukeleto: but if the change occurred in a version of parrot that doesn't build rakudo, how do I detect that? 03:59
dukeleto pmichaud: like running one specific test with certain params
pmichaud dukeleto: I totally don't understand.
dukeleto pmichaud: touche. but you can find bounds on what that rev is with bisect
pmichaud: git bisect takes a script as an argument that exits with a special exit code to denote "good/bad/ignore" 04:00
pmichaud: so you ignore the revs that don't build, and it will stop when it can't narrow down the commit range any further 04:01
pmichaud dukeleto: I don't think that's going to significantly help me locate the problem.
but thanks.
dukeleto pmichaud: just a thought, but yes, reading the code will probably be faster :)
pmichaud: for larger ranges of commits tho, bisect can really be the only feasible way 04:02
pmichaud well, I know the endpoint of the range already -- it's 48897
that's the first point at which rakudo started building again 04:03
dukeleto aloha, msg whiteknight any clue about the error that i get when trying to run the PLA test suite? gist.github.com/572779 seems to be a kakapo issue 04:04
aloha dukeleto: OK. I'll deliver the message.
cotto you could make applying my revert part of the bisect script 04:05
pmichaud cotto: your patch isn't what was blocking rakudo prior to 48897
I suppose I could try building without --optimize, though. 04:09
I'll do that if I'm not able to locate it otherwise. 04:10
04:21 jsut_ joined 04:22 dalek left 04:23 pmichaud left, dukeleto left, PerlJam left, Util left 04:24 nwellnhof left 04:26 jsut left 04:29 dalek joined 04:34 dukeleto joined, PerlJam joined 04:38 pmichaud joined 04:43 Util joined 05:02 baest joined
sorear seen Infinoid 05:17
purl Infinoid was last seen on #parrot 1 days, 18 hours, 42 minutes and 19 seconds ago, saying: Ok :) [Sep 8 10:35:21 2010]
aloha Infinoid was last seen in #parrot 1 days 18 hours ago saying "Ok :)".
sorear Infinoid: ping
05:22 theory joined 05:38 theory left 06:08 uniejo joined 06:15 fperrad joined
dukeleto fperrad: hello 06:19
dalek rrot: r48904 | fperrad++ | trunk/tools/dev/fetch_languages.pl:
[languages] PIR/Pirate moves on ļæ½github.com/parrot/pir.git
 06:29
06:42 cottoo joined, cotto left 06:45 cottoo is now known as cotto 07:41 cottoo joined, cotto left 07:42 cottoo is now known as cotto
luben NotFound++ # for fixing amd64 optimized builds 07:51
08:05 esskar joined 08:08 dalek left 08:09 dalek joined 08:31 luben_work joined
dalek parrot: 767e473 | leto++ | t/sql/plperl6.sql:
Test for returning Failure objects from PL/Perl6
 08:32
parrot: 8896891 | leto++ | t/sql/plperl6.sql:
Revert "Test for returning Failure objects from PL/Perl6"

This reverts commit 767e473e243556c60e23f7577fee65bb02781ef3. There is a failure branch tracking this now. Let's hope it isn't aptly named.
smash mornin' everyone 08:45
dalek rrot: r48905 | luben++ | branches/hash_inlined_func (6 files):
merge recent changes in master
rrot: r48906 | luben++ | branches/hash_inlined_func (22 files):
Bring up to date with master
rrot: r48907 | luben++ | branches/hash_inlined_func/compilers/imcc/pbc.c:
fix confilict in compilers/imcc/pbc.c
08:49 tcurtis left 08:53 JimmyZ joined 08:56 JimmyZ_ joined 09:00 JimmyZ left, JimmyZ_ is now known as JimmyZ
pmichaud hmmmm.... the type of PMC methods changed without any deprecation notice (that I can see) 09:08
that's what is currently causing Rakudo failures in trunk 09:10
gist.github.com/573362 # type of PCC methods changed from 2_6_0 to present 09:22
I think I can work around the change, but will have to do it later this morning after I get some sleep.
sorear How does Rakudo notice? 09:23
pmichaud Str.trans always fails 09:24
The trans method defined in Cool (and inherited by Str) isn't overriding the trans PCCMETHOD provided by Parrot's String PMC 09:25
sorear Yes, but how do type names affect that
pmichaud ah. various parts of rakudo and p6object have to test specifically for pccmethods, which aren't Parrot Sub PMCs
so all of those tests are now invalid.
currently they test for objects of type "NCI" (which is what PCCMETHODS were instances of) 09:26
anyway, commit r48790 is the one that broke things there, for people who want to consider the issue further. 09:28
sleep time for me -- bbl 09:29
JimmyZ good night, pmichaud 09:32
10:00 JimmyZ left
Infinoid sorear: pong 10:06
sorear Infinoid: I was wondering if you could give me the rundown on dalek's architecture, or who else to ask 10:08
Infinoid the bot architecture, or the feed plugins?
sorear mostly the latter 10:09
I had a crazy idea earlier
a web interface for dalek
Infinoid Cool. Ok
sorear when github posts to feather.perl6.nl/~dalek/rakudo, dalek immediately rechecks the feed 10:10
I'm not going to ask you for this, it's too big to impose like that ;)
but I'd like to try it
Infinoid Sounds interesting
dalek runs a perl5 bot software package called botnix, which for us, defines what the plugin architecture and timer API looks like
The way the dalek-plugins stuff is set up, each feed is a separate "plugin" (many of which are autogenerated by the googlecode, github and gitorious base classes) 10:11
10:12 luben left
Infinoid rakudo is an example of one which is not currently autogenerated, because it has a nondefault set of channels (e.g. it outputs to freenode as well as the default magnet/#parrot) 10:12
But it's still implemented mostly by the base class, as you can see: github.com/Infinoid/dalek-plugins/b...kudolog.pm 10:13
sorear why is drain 700? 10:14
Infinoid I don't know, I didn't actually install that instance. I'm happy to keep referring to the github repo for now so you can follow along 10:15
As I mentioned, currently the feed checking is triggered by a timer callback. In githubparser's case, the timer is registered by try_link (which is what detects that the link is a github link and parses out the author/project/branch stuff), and the callback function itself is process_project
If you have an alternate update scheme, you can just call process_project directly. Note, though, that it plays some package/class tricks to get the local state back 10:16
botnix doesn't call it as a class instance, so there's a global hash to store per-project state.
The run_function sub in github.com/Infinoid/dalek-plugins/b...al/test.pl emulates the way botnix calls the callbacks 10:17
The rest of github probably wouldn't have to change much, but it's fairly well commented if you want to read through it. github.com/Infinoid/dalek-plugins/b...bparser.pm 10:18
Alternately, if you already know the hash of what you want it to output, you can skip the feed parsing stuff entirely and just use try_item() 10:20
Oops, that POD is out of date. It's no longer using XML::Atom::Entry objects 10:21
s/try_item/output_item/
10:22 Coke joined
Infinoid sorear: As for the installation on feather, I'm not sure who really "owns" dalek. I know diakopter has been involved in its maintenance in the past 10:30
11:30 aloha left 11:31 bacek left 11:37 Coke left 12:31 ruoso joined 12:35 yuriguy joined 12:36 yuriguy left 12:53 whiteknight joined
whiteknight good morning, #parrot 13:02
arnsholt How do I invoke a method in a parent class on a P6object? 13:08
whiteknight i have no idea 13:11
jnthn get the parent
$P0 = find_method the_parent, 'name'
$P0(inv, arg1, arg2, ...)
whiteknight how to get the parent?
arnsholt self.HOW.get_parrotclass(self) it turns out 13:12
(Which was the real issue, it turns out)
Third time's the charm it appears. I've been digging around in P6object.pir a couple times trying to figure it out 13:13
whiteknight is there anything like good documentation for P6object?
jnthn whiteknight: Well, in Perl 6 you tend to either be explicit ($foo.Parent::methodname()) or be doing deferal using nextsame etc
whiteknight: There's a bunch of POD in the P6object.pir
arnsholt Yeah, that was helpful in the end 13:14
jnthn whiteknight: But P6object.pir is a tad lacking in the introspection side of things, so you sometimes end up doing things directly on the Parrot class.
whiteknight: The new Perl 6 objects implementation will be rather better on that front.
The answer then will probably be obj.^mro[1] or some such to get the immediate "parent" though 13:15
But in an MI world parent is a bit handwavey. 13:16
arnsholt True. What I needed was essentially nextwith($fiddled_arguments) 13:17
13:17 Patterner left
arnsholt So that my compiler knows whether it's compiling a program or a query (yay Prolog =) 13:18
13:27 Psyche^ joined, Psyche^ is now known as Patterner 14:06 uniejo left
pmichaud good morning, #parrot 14:21
14:23 fperrad left
whiteknight good morning, pmichaud 14:25
14:35 patspam joined 14:37 theory joined 14:40 jan left 15:07 tadzik joined 15:25 mikehh left, luben_work left 15:26 tadzik left 15:29 bacek joined 15:35 aloha joined
dalek kudo: c957c9f | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to update to a known working 64-bit Parrot (passes all spectests).
 15:36
cotto_work ~~ 15:38
dalek rrot: r48908 | pmichaud++ | trunk/runtime/parrot/library/P6object.pir:
[p6object]: PCCMETHODS changed type from 'NCI' to 'NativePCCMethod' in r48790 -- update P6object to match.
 15:43
rrot: r48909 | pmichaud++ | trunk/src/pmc/nativepccmethod.pmc:
[core]: NativePCCMethods need to be marked "does invokable".
pmichaud I'm trying to come up with a helpful response to trac.parrot.org/parrot/ticket/1491#comment:5 and failing. :-| 15:45
cotto_work "do it"? 15:46
dalek kudo: c84d0d3 | pmichaud++ | build/PARROT_REVISION:
Oops. *This* is the correct Parrot revision for 64-bit builds -- fixes c957c9f.
 15:54
pmichaud yes, but "do it" means I'm likely to just come up with another create_language.pl replacement (likely in the nqp-rx directory) 15:55
atrodo The more the merrier?
cotto_work I thought they were trying to either merge the functionality of one into the other or write a replacement for both that'd obsolete (and allow us to nuke) the other two. 15:57
pmichaud yes. But I'm not at all comfortable with the functionality of the other. 15:58
that's one of the reasons I created 'create_language.pl'. 16:00
cotto_work do you not think anyone should be using mk_language_shell.pl 16:01
pmichaud it's not the script I have issues with, it's the setup.pir tools. 16:02
cotto_work a bus number issue?
pmichaud design issue
afaik, setup.pir still isn't sufficiently advanced to build something like Rakudo 16:03
(and to do it in a way that is better or on par with the use of a Makefile in terms of understandability and flexibility) 16:04
I also expect nqp to be targetting an additional backend in the near future, and setup.pir doesn't seem like it's going to be portable in that situation.
cotto_work Lorito? 16:05
purl Lorito is "little parrot" in spanish or xkcd.org/707/ or github.com/atrodo/lorito or trac.parrot.org/parrot/wiki/Lorito or github.com/ekiru/yalp-asm
pmichaud .net, most likely.
atrodo Lorito!
cotto_work also shiny
pmichaud and by "near future" I mean "in calendar 2010" :-)
atrodo pmichaud> How much work would be involved in porting nqp to a new vm? 16:06
cotto_work Why not allow both and explain the limitations of setup.pir?
pmichaud maintenance, primarily.
dalek nxed: r620 | NotFound++ | trunk/winxedst1.winxed:
fix namespace parsing and improve its error detection
 16:10
pmichaud atrodo: we don't know exactly how much work will be involed in porting nqp. But jnthn++ already has a good start on a .net port.
and nqp-rx was designed from the outset with the idea that would hopefully be portable to other backends. 16:11
particle1 nqp-rx: designed with hope! 16:14
16:14 particle1 is now known as particle
atrodo pmichaud> how much does the backend have to provide? The basics like method dispatch and primative data types, or more like what parrot provides like CPS, MMD, etc? 16:16
dalek TT #1776 closed by pmichaud++: r48847 breaks Rakudo 16:17
TT #1776: trac.parrot.org/parrot/ticket/1776
pmichaud atrodo: iiuc, jnthn's work is basically coming up with a new object model and method dispatch system, which can then provide mmd for systems that don't have it.
(it's not a new object model -- it's basically the Perl 6 object model at a somewhat lower level)
(but with efficient attribute access and method dispatch) 16:18
atrodo Ah, makes sense
pmichaud so, I don't think we're going to be expecting a whole lot from the backend
and most of the dispatch and metamodel code is itself being written in nqp :)
16:19 patspam left 16:26 jan joined
dalek kudo: 7517e39 | pmichaud++ | src/pmc/perl6multisub.pmc:
Remove dead check_invokable() code from perl6multisub.pmc .
 16:29
nxed: r621 | NotFound++ | trunk/winxedst1.winxed:
typo
 16:34
16:38 patspam joined
dukeleto waves good localtime() 16:43
cotto_work wishes everyone in a very different timezone a happy Tuesday. 16:45
dukeleto lulz 16:48
aloha, msg JimmyZ you have been added to the parrot github org
aloha dukeleto: OK. I'll deliver the message.
dukeleto seen gerd 16:49
purl gerd was last seen on #parrot 87 days, 4 hours, 26 minutes and 25 seconds ago, saying: I will start to copy the tar file to the ftp server. [Jun 15 12:22:48 2010]
aloha Sorry, I haven't seen gerd.
16:50 tcurtis joined
cotto_work That's a bit disconcerting given that he's on for the next couple releases. 16:51
16:53 patspam left
dukeleto cotto_work: feel free to improve this: wiki.github.com/parrot/parrot/ 16:56
cotto_work: i think he uses a different nick nowadays
cotto_work: just using the wiki there for important git-related info, not trying to replace Trac
cotto_work I'd rather just have it direct to either our wiki or the GitMigration page so people know not to add anything there. 16:57
dukeleto cotto_work: if that is possible, go for it 16:58
cotto_work Can you think of a decent definition of ""well-tested" for the github trac plugin?
dukeleto cotto_work: it is just that people are asking me these questions and I don't want to repeat myself and I don't want people to hate me if they create a branch called foo and then my mirror script kills it 17:00
cotto_work: does it have any tests for functionality that was added?
cotto_work: gerd was emailing me questions about parrot.git
cotto_work It doesn't have any tests.
dukeleto cotto_work: github-trac had no tests, to begin with ? 17:01
cotto_work Nope. It doesn't seem to be common for trac plugins to come with tests. I'd have written some if there were a test suite to work with. 17:02
dukeleto cotto_work: hmm. I guess we need to have some manual checklist of stuff
cotto_work That'll do, I guess. 17:03
dukeleto cotto_work: can you think of a way to verify that each feature you added works?
cotto_work: like "do X, see if Y is there" for each thing, a manual checklist
cotto_work wfm 17:06
dukeleto cotto_work: that will also be a useful list of "this is what our improvements to github-trac do" 17:08
cotto_work I'll start a wiki page.
dukeleto cotto_work: have you contacted davglass about getting that stuff merged upstream?
cotto_work yup. no reply 17:09
dukeleto cotto_work: ok, thanks for contacting him 17:11
dalek tracwiki: v24 | cotto++ | GitMigration 17:13
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
cotto_work I'll ask him via email this weekend. It's possible he didn't notice the pull request (or needs a nudge). 17:14
My contract ends after Monday, so tuits won't be much of a problem. 17:16
dukeleto yay for tuits 17:17
cotto_work Do you know of a good template for manual tests? 17:20
cotto_work does not look forward to dealing with trac tables 17:21
17:25 patspam joined
cotto_work or manual tests, for that matter 17:29
17:29 davidfetter joined
dukeleto cotto_work: i hear ya 17:32
cotto_work better than nothing, though 17:33
17:33 smash left
dalek rrot-linear-algebra: 5798a17 | Whiteknight++ | t/pir-subclass/pmcmatrix2d.t:
Add a stray test file that I forgot to add yesterday
 17:36
rrot-linear-algebra: e5332d7 | Whiteknight++ | / (2 files):
Merge branch 'master' of github.com:Whiteknight/parrot-linear-algebra
pmichaud trac.parrot.org/parrot/ticket/1491#comment:6 # took far too long to write, still not well written :-(
rrot-linear-algebra: 659d91a | Whiteknight++ | t/harness:
refactor the test harness class to allow breaking the test run into multiple sections, which can be executed independently. Also, allow the line parser to ignore garbage lines, though the algorithm isn't great yet
cotto_work and trac-- puts it in a fixed-width box with a scrollbar, wasting a good 2/3 of my screen 17:40
17:40 davidfetter left, davidfetter joined
cotto_work View->Page Style->No Style to the rescue 17:41
firefox++ for making really stupid layouts more bearable
dukeleto cotto_work: you are fine with me commiting to your git_aware_tools branch, right? 17:42
dalek tracwiki: v1 | cotto++ | GitHubTracPluginTests 17:47
tracwiki: one fleshed-out test case and a healthy TODO list
tracwiki: trac.parrot.org/parrot/wiki/GitHubT...ction=diff
cotto_work absolutely
purl Indubitably.
17:56 tadzik joined
dukeleto cotto_work: i question the usefulness of branch_status.pl 17:58
cotto_work I wouldn't feel bad if it went away, given github's branch view thingy.
dukeleto asks parrot-dev about it 18:00
18:00 cotto_work is now known as parrot-dev
parrot-dev nuke it 18:00
18:01 parrot-dev is now known as cotto_work
atrodo Creative 18:01
cotto_work guesses that darbelo is probably happy, given his upcoming job 18:03
dalek tracwiki: v25 | cotto++ | GitMigration 18:04
tracwiki: trac.parrot.org/parrot/wiki/GitMigr...ction=diff
davidfetter cotto_work, from orbit. it's the only way to be sure
cotto_work You're saying we should test it from orbit? ;} 18:09
plobsing: do your latest changes work with rakudo? 18:11
atrodo cotto_work> all my code is tested from orbit. Or so I assume
18:13 mikehh joined
dalek rrot: r48910 | plobsing++ | branches/oplib_handling_cleanup (17 files):
eliminate now inappropriate uses of core_ops->op_code in favour of interp->op_hash
 18:15
rrot: r48911 | plobsing++ | branches/oplib_handling_cleanup/src/runcore/main.c:
eliminate now defunct parts of dynop_register
plobsing cotto_work: I'm working in branch, haven't tested. Will test when finished.
dalek nxed: r622 | NotFound++ | trunk/winxedst1.winxed:
look for classes in namespaces scopes in stage 1
 18:17
nxed: r623 | NotFound++ | trunk/winxedst1.winxed:
codingstd: tab -> spaces
 18:22
nxed: r624 | NotFound++ | trunk/pir/winxed_compiler.pir:
update generated pir
dukeleto sees that rosettacode.org is a great way to not hack on other more-useful things 18:25
davidfetter "420 tasks?" 18:29
just exactly what tasks is 420 supposed to help with?
dukeleto davidfetter: it helps with lots of things... 18:44
davidfetter: TimToady++ has been posting some perl6 solutions to rosettacode.org, which is how I found it
dalek rrot: r48912 | plobsing++ | branches/oplib_handling_cleanup (10 files):
eliminate interp.op_info_table and interp.op_func_table
 18:48
davidfetter dukeleto, yeah, here in california, there's a ballot initiative... 18:51
davidfetter curious about how this will turn out
18:51 Paul_the_Greek joined
Paul_the_Greek Hey ho, folks. 18:52
davidfetter ĪšĪ±Ī»Ī·Ī¼Ī­ĻĪ± 18:53
davidfetter may be assuming too much about Paul_the_Greek's nick 18:56
dukeleto Paul_the_Greek: good morrow
Paul_the_Greek Good morning to you, too, davidfetter.
davidfetter 2 minutes' worth of morning left here in oakland 18:57
atrodo I've been fresh out of morning all afternoon 18:58
Paul_the_Greek dukeleto: We should talk about breakpoints later.
18:59 tcurtis left
dukeleto Paul_the_Greek: have you made any progress? 19:00
19:08 nwellnhof joined
dukeleto looks like rakudo coredumps a spec test on 64bit linux since the last bump to PARROT_REVISION 19:11
looks like dalek doesn't know about roast.git 19:12
19:20 M_o_C joined
dalek rrot: r48913 | plobsing++ | branches/oplib_handling_cleanup (2 files):
eliminate interp.op_count and interp.op_lib
 19:22
rrot: r48914 | plobsing++ | branches/oplib_handling_cleanup/src/runcore/main.c:
make headerizer
rrot: r48915 | plobsing++ | branches/oplib_handling_cleanup/config/gen/config_h/config_h.in:
[codetest] macro args
dukeleto i added roast.git to the languages page on the trac wiki, hopefully dalek will learn about it soon
davidfetter roast? 19:26
purl it has been said that roast is about to come... from everyone
19:28 M_o_C left
dalek tracwiki: v141 | dukeleto++ | Languages 19:29
tracwiki: trac.parrot.org/parrot/wiki/Languag...ction=diff
dukeleto davidfetter: roast.git is what the perl 6 spec tests are called now 19:30
dukeleto goes to seattle
davidfetter have fun in seattle, dukeleto :)
whiteknight my old boss used to say he was going to the "basement" when he wanted to do some heavy drinking at work 19:31
when a really annoying customer came in, he would say "I'm going to the basement", and he would hide in the bathroom and drink beer
msg dukeleto (PLA test error) yes, it is a kakapo error. I have a custom version of kakapo that I need to tag. I'll do that this afternoon and msg you when it's ready. 19:32
purl Message for dukeleto stored.
aloha OK. I'll deliver the message.
whiteknight a dependency tree is a fickle mistress 19:34
19:44 nwellnhof left 19:45 alin joined 19:47 patspam left 19:49 patspam joined 20:04 whiteknight left
dalek kudo: 43c27a9 | pmichaud++ | src/core/Cool.pm:
Remove .succ and .pred from Cool.
 20:08
rrot: r48916 | plobsing++ | branches/oplib_handling_cleanup/config/gen/config_h/config_h.in:
remove bad include line
 20:12
rrot: r48917 | plobsing++ | branches/oplib_handling_cleanup (27 files):
sync with trunk
20:17 Coke joined, aloha left 20:19 bacek left
dalek kudo: ce565f3 | moritz++ | src/Perl6/Actions.pm:
enable :r and :ratchet outside of regexes
 20:20
20:28 tadzik left 20:34 tadzik joined 20:58 whiteknight joined
Paul_the_Greek ping dukeleto 21:05
dalek izkost: 2275955 | NotFound++ | src/pmc/bkmarshal.c:
Use does invokable instead of isa Sub to identify invokables in marshalling.
 21:07
cotto_work wonders what's in Seattle that dukeleto's going to
Paul_the_Greek cotto_work: Do you use the Parrot debugger? 21:10
cotto_work very irregularly 21:11
Paul_the_Greek How much work do you think it's worth? 21:12
cotto_work I can answer questions or look confused, though.
adding breakpoints will help, if that' 21:14
s what you're thinking about
21:14 patspam left
Paul_the_Greek They seem to work for me, although they are confusing. 21:15
The list command is broken, too.
cotto_work It's something of a bootstrapping problem. It's not useful because people don't use it, etc 21:16
well, not as useful as it could be
Paul_the_Greek I think I'll work on it a bit, at least to fix the obvious bugs.
It would be nice, for example, if the list command thought that lines start with 1 rather than 0. 21:17
cotto_work That could be an imcc thing.
Paul_the_Greek If you enter just 'list', you get lines starting at 1. 21:18
If you enter 'list 1', you get lines starting at 2.
NotFound Paul_the_Greek: that is probably my fault 21:19
cotto_work Oh. You should add a test for that.
Paul_the_Greek Your fault, NotFound?
NotFound Paul_the_Greek: I worked on it a year ago or so.
Paul_the_Greek Ah. I think I'll poke at it a bit. A good way to learn some internals, anyway. 21:20
21:23 perlite_ left, perlite joined 21:35 luben joined
Coke seen chromatic? 21:52
purl chromatic was last seen on #parrot 2 days, 36 minutes and 41 seconds ago, saying: Wordsize problem? [Sep 8 21:15:41 2010]
dalek rrot: r48918 | chromatic++ | trunk/src/gc/system.c:
[GC] Made system tracer use precise type marking.
rrot: r48919 | chromatic++ | trunk/src/namespace.c:
[src] Rearranged NameSpace type checks.
rrot: r48920 | chromatic++ | trunk/src/pmc/object.pmc:
[PMC] Optimized Object's isa() VTABLE slightly.
Coke msg kid51 - trac.parrot.org/parrot/changeset/48...nqp-rx/src - that's why I mentioned it. just don't modify the generated files then, if you can't submit the patch upstream. Or report a bug, or something. 21:54
purl Message for kid51 stored.
Coke msg kid51 (to be clear, we shouldn't be modifying the generated files directly even if a patch is submitted upstream. the re-import of nqp-rx will get the fix in that case)
purl Message for kid51 stored.
22:03 ruoso left
dalek ast: d837943 | patrickas++ | S03-operators/series (2 files):
Changed some tests to follow the new spec
 22:07
ast: cb28dfa | patrickas++ | S03-operators/series (2 files):
Changed more tests to follow the new spec
ast: 4d37df5 | patrickas++ | S03-operators/series.t:
Added more tests for code on the fhs and added tests for infinite list on the lhs
 22:08
22:08 bacek joined 22:09 ash_ joined, aloha joined
dalek rrot: r48921 | NotFound++ | trunk/src/pmc/packfile.pmc:
a bit of refactoring in the Packfile PMC
 22:09
Paul_the_Greek Debugger 'list' command much improved. 22:10
22:11 eternaleye_ joined
cotto_work Paul_the_Greek++ 22:11
Paul_the_Greek Next stop: 'info' (crashes). 22:12
22:13 eternaleye left 22:16 tadzik left 22:19 hercynium joined
dalek rrot: r48922 | luben++ | branches/hash_inlined_func (5 files):
Track master
 22:26
22:32 shockwave joined
nopaste "shockwave" at 192.168.1.3 pasted "Performance question." (10 lines) at nopaste.snit.ch/23293 22:33
shockwave While updating some code, it occurred to me that I could change a sub into a macro, to possible get some performance gains. The code I posted above shows them both. 22:34
In general, is there a decent speed difference between the two? I have a few places in my codebase that could use that conversion, then. (Not that they are slow, but if one is much faster than the other, why not?) 22:35
NotFound shockwave: premature optimization is the root of all evil
cotto_work -1 to any optimization without profiling 22:36
shockwave @NotFound: Yeah, I know that mantra. But this is more is a code generation thing which could easily go either way.
plobsing shockwave: use of $P99 in a macro is *not* hygenic 22:37
shockwave It takes no effort on my part to choose one over the other. So, sure, it is an optimization; but not the obsfuscate-code-to-get-some-speed-gain type.
@plobsing: True. It can cause issues with generated code.
NotFound shockwave: the mantra says "prmature optimization", no "obsfuscate-code-to-get-some-speed-gain" ;) 22:38
plobsing I *think* that it is possible to get hygenic macros in PIR, but I cannot remember how. There's a test for it somewhere...
shockwave @plobsing: Probably something like: $P99.someMacroArg = foo
NotFound If is generated code, just generate it instead of generating macros that generate the code. 22:39
shockwave @NotFound: Its not for generated code. It's for Runtime Support System.
Anyhow, what about my question? *Could* the speed difference be considerable? If there is such thing as .tailcall optimization, then the function context switching must have a decent overhead, since there is an optimization for it. 22:41
NotFound I've just spend a lot of hours diagnosing an ugly bug caused by premature optimization, so I'm specially sensitive ;)
shockwave @NotFound: I feel your pain. And I know you're right. But, trust me, this aint my first rodeo. 22:42
plobsing shockwave: the cost involved in tailcall optimization is mostly about space allocated to call frames IIUC. 22:46
NotFound shockwave: the Parrot Calling Conventions aren't know for its big speed, sure, but you should profile if the operations is done in such a number that has a noticeable impact.
jnthn Using a macro for a very frequent operation rather than a call with save you a decent bit under current Parrot, it nothing else because it saves you a gc-able (e.g. the context) 22:48
s/with/will/
shockwave NotFound: This code lives in the array/map setting code. i.e., arr[5] = true; map_['a'] = 5; Every scalar type must be boxed, and tagged with its typeid. These types of things will happen ALOT. This will, for sure, make a difference. 22:49
jnthn shockwave: In the longrun, you'd really want to build those at compile time and serialize 'em, I expect. We don't quite have the infrastructure for that yet though. 22:50
But still, checking the type tag will be a common operation.
In Rakudo we just do the getprop directly 22:51
But for the type we don't attach an ID but rather an object representing the type.
(These days I'm fairly against type IDs for anything other than caching.) 22:52
shockwave @jnthn: I'm a bit lucky in that I have the type-id available at compile-time, since my language, Runik, is statically typed.
jnthn If it's statically typed, then why do you need to do checks at runtime at all?
If the program was badly typed, you'd detect that at compile time and refuse to code-gen it, no?
(Other than explicit cats, etc)
er, casts
dalek nxed: r625 | NotFound++ | trunk/winxedst1.winxed:
rearrange the generated initialization code in stage 1 compiler
 22:53
shockwave jnthn: Because containers are dynamic. One can put any type into an array/map. They are always stored as 'objects', the base-type of all types, including scalars.
jnthn ah, OK 22:54
shockwave when fetched, they must be casted to its proper type.
jnthn: Well, thanks for the help. I got the answer I was looking (and hoping) for. 22:55
Thank you also, plobsing, NotFound.
jnthn shockwave: Happy to help. I've done/am doing a lot of the type systemy stuff in Rakudo, so have visited quite a few of these issues before. :-) 22:56
shockwave jnthn, type systems are fun, aren't they? Psych!
jnthn Oh, yes. :-) 22:57
The only thing I'd point out with type IDs even in the static case you have, is that you'll still hit linkage issues with them.
shockwave what?
jnthn e.g. what if I write module A and module B and use them in the same program, and they both gave ID 42 to a type? 22:58
shockwave Oh, I'm guessing you're talking about for dynamic code loading.
jnthn Well, even if you know you're using them up front and both were compiled ahead of time and have different mappings for a type ID, it could be an issue. 22:59
shockwave jnthn: All types have unique ids. Guaranteed.
ash_ what if you made a GUID for the type id?
jnthn ash_: Then if it really is GU you're safe. :-) 23:00
shockwave jnthn: When the are stored in the symbol table, they are given an unique type.
jnthn shockwave: OK, if you have a way to be sure of that, then you're fine.
shockwave jnthn: They only problem would be for, say, loading code at runtime. That's a few versions in the future, but, even then, I'm guessing that it would be a matter of keeping the last used id, and incrementing that. 23:01
jnthn: But, thanks for the heads up, anyway.
jnthn shockwave: Well, it more happens if you're serializing the type ID anywhere. If you're assigning them when the code is loaded, then yeah, you'll be quite safe I guess. :-) 23:02
shockwave jnthn: I'm assigning them at compile time.
jnthn Do you allow for modules to be pre-compiled? 23:03
If so, that's the case I worry about.
plobsing shockwave: do you have separate compile time and run time and do you want types to be able to cross module boundaries? if you answered yes to both, it'll be tricky.
jnthn Because you could compile two modules that know nothing about each other and share type IDs if you're not careful. 23:04
And then try and use them both int eh same program.
plobsing: Right, that pretty much is what I'd worry about.
plobsing jnthn: I've been doing a lot of thinking about the linkage issue since your parrot-dev emails.
shockwave plobsing: I'm not quite sure I undestand, 23:05
for compile time, do you mean, for instance, a C library that gets loaded at runtime?
and for the compile time to just be the code that gets generated?
plobsing shockwave: nope, more like if you want to compile units separately like C .o object files 23:06
shockwave @plobsing: If by compile-unit you mean like, a separate file is its own compilation unit, then I currently do that. 23:07
plobsing jnthn: what if objects having a special member in their prophash were stored as references to other PBC's consttables.
shockwave But, currently, the compiler always recompiles everything, so its easy.
jnthn shockwave: In Rakudo, we can take a module, say Foo.pm, and compile it to PIR. We could take Bar.pm and do the same. We could then have a baz.pl that uses both. If Foo and Bar were compiled in ignorance of each other and we use the compiled versions in baz.pl, you'd need to make sure that Foo and Bar didn't assign overlapping type IDs, even though you didn't know both existed when compiling them.
Oh, if you re-compile everything then you get away with it :-)
plobsing you get away with it to a point. larger compiles will become painful eventually. 23:08
shockwave Actually, I'm hoping to start the dependency stuff tomorrow :-) So I'll atually be dealing with this tomorrow (hopefully).
jnthn plobsing: I don't think this is something that really belongs in the prophash.
plobsing: In my 6model prototype I've gone and stuck it straight into the objects themselves
That is, a pointer (well, reference in C#, where I'm prototyping :-)) to a serialization context. 23:09
Then it's dead cheap
You walk until you see something with an SC pointer in place already
shockwave jnthn: Yeah, I've thought about this issue abit, though not that much, since I don't find it that scarry (maybe because I havent thought about it).
jnthn (If it's null you know it's gotta be serialized.)
plobsing jnthn: that sounds nifty, but I don't think it'll fly with other HLLs to make certain object fields special.
jnthn plobsing: ? 23:10
plobsing: I don't see why this has to be Rakudo specific.
plobsing: Oh, I think I mis-explained. (more)
I'm envisioning this at a bit lower level. That is, the SC pointer would be a member of the PMC structure. 23:11
plobsing that's what I'm getting at. Other languages might not want a field in their objects at all.
jnthn Rather than specific to any particular object system implementation.
plobsing jnthn: oic. that works and is more or less equivalent to the prophash, but more efficient. 23:12
jnthn Well, and if it's in the prophash it's "exposed"
Rather than an implementation detail. 23:13
plobsing jnthn: but it costs an extra sizeof(void *) for every allocated object even for programs that never serialize
jnthn But yes, there's an efficiency win too.
You are, of course, correct on that. On the other hand, I think that many languages will want to make their constant-y things at compile time and reference them rather than build them up every time. 23:14
plobsing jnthn: there's nothing wrong with exposing it. How else is the HLL supposed to manage it? 23:15
23:15 shockwave left
jnthn I'd rather we expose it through some kind of interface for manipulating SCs. 23:16
e.g. if you were using PCT, you'd get access to some object representing your current SC that you can add things to
cotto ~~ 23:17
jnthn Just having it in the prop hash feels like a really clumbsy interface that we'd only regret later on.
Plus the memory cost of everything having a prophash will be really not great too.
plobsing jnthn: most things don't have a prophash, just stuff you want to link to, and just during compile time.
jnthn It isn't really just during compile time though 23:18
For example, imagine I pre-compile A.pm and B.pm to PBC
I have a C.pm that uses both of them that I then compile 23:19
plobsing ok, I'm with you so far
jnthn When I load the two of those they'd need to keep their SC references.
plobsing why? 23:20
jnthn So when we make the PBC for C.pm it knows what it needs to serialize, and what it needs to reference from A and B.
plobsing but that's still compile time. it is C.pm's compile time.
jnthn Hmm, true. 23:21
plobsing when you then go and run foo.pl which uses C.pm, the references exist in the PBC, but there is no reason to keep the object properties for maintaining the references alive.
unless an arbitrary perl 6 program can compile PBC somehow 23:22
jnthn Aye, I'm wondering if we have a case where compile time and runtime are blurry enough that we'd run into issues.
Somehow using the prophash just feels like we'd be hanging it in the wrong place, though. 23:23
plobsing maybe. I'm not really sure what the prophash is for. I thought it was for attributes parrot needs to put on objects that shouldn't show up as attributes when the HLL queries the object for its attributes. 23:25
ETOOMANYATTRS
jnthn The prophash is kinda easy/lazy way to stash some extra data on a PMC. 23:26
Trouble is, we often use it in Rakudo to stash stuff we need to check Real Quick.
dalek nxed: r626 | NotFound++ | trunk/winxedst1.winxed:
minor refactor
 23:27
jnthn plobsing: Anyway, I'm going to need to Do Something on the serialization issue soon. (more) 23:28
It's going to quickly become a blocker for unifying the compile time and runtime MOPs, which I need to do in order to make gradual typing drop out in a fairly natural way.
Not to mention we want decent startup time in Rakudo. 23:29
plobsing jnthn: in the end, it's just an implementation detail. If somebody makes a way to hang that data off of a PMC and lets me know about it, I can make linkage work on PBC serialize/deserialize.
jnthn plobsing: I did talk about this with allison++ at YAPC::EU for a while. She wasn't opposed to us giving PMCs an extra slot to store an SC pointer if needed. 23:30
23:30 kid51 joined
plobsing pbc_merge might be a little trickier 23:30
jnthn plobsing: So there's not a blocker in that sense.
plobsing: If you're interested to help on this though, that'd be really great. :-) Essentially, I can go two ways on this: I can build something outside of Parrot core, or I can help to improve the current freeze/thaw to the point where it can handle what is needed. 23:31
And if there's support from @parrot-folk to do the latter, I think it'd benefit more Parrot users. 23:32
plobsing yes. Perl 6 isn't the only language where this might become an issue.
jnthn Also there's an opportunity to get this right in nqp-rx first before shooting for full Rakudo. 23:33
Well, I think everyone with classes will probably want to represent and serialize their "meta-objects" for those at compile time too, once it's made possible.
23:37 Paul_the_Greek left
plobsing OK, if we're going down the improve parrot compilation/serialization path, do you have a roadmap? 23:38
I think a high priority would be to get nqp-rx to avoid PIR altogether.
jnthn No, but I can probably get a draft one together tomorrow.
nqp-rx is going to be changing a fair bit generally 23:39
Not in all ways, but certainly in the way it compiles e.g. classes.
23:40 theory left
plobsing yes, that's what I'm getting at mostly. Serializing data is one of PIR's many weak points. 23:40
jnthn Right - I expect to be building up the meta-objects from the actions, and adding them to an SC.
Not generating PIR to build them.
23:40 theory joined
jnthn We can do same for many constant thingies. 23:41
I need to get some sleep now - it's been a *very* long day here (at $dayjob we hosted some workshop, so I've been helping with setup/speaking/teardown etc). Tomorrow I'll try and get a roadmap together for this stuff. 23:43
23:43 theory left
whiteknight jnthn++ 23:45
jnthn At some point, I'd also like to discuss some possible lexpad-y things with Parrot folks that are interested too. 23:46
But anyway, another day. :-)
night all o/
dalek rrot: r48923 | plobsing++ | trunk (121 files):
merge oplib_handling_cleanup
 23:50
rrot: r48924 | plobsing++ | branches/oplib_handling_cleanup:
branch has been merged
NotFound Urgh.... I broke blizkost horribly somehow. 23:55

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!