Parrot 2.3.0 Released | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: apply deprecations, merge branches, test exceptions_refactor branch | welcome our GSoC students
Set by moderator on 27 April 2010.
01:05 Austin_away joined 01:11 dl748 joined
dalek rrot: r46225 | NotFound++ | trunk/src/interp/inter_create.c:
flush and unbuffer stderr and stdout at the start of interpreter destruction
 01:18
01:21 hicx174 joined 01:22 JimmyZ joined
JimmyZ \\o 01:23
01:27 snarkyboojum joined 01:59 Psyche^ joined 02:04 snarkyboojum joined 02:18 parthm joined 02:34 ruoso joined 02:35 janus joined 03:05 theory joined 03:16 LoganLK joined
cotto seen kid51 04:07
purl kid51 was last seen on #parrot 1 days, 12 hours, 17 minutes and 10 seconds ago, saying: Those two files should have been governed by an svn:ignore property. Committed fix in r46204. [May 1 15:50:42 2010]
cotto seen jkeenan
purl I haven't seen 'jkeenan', cotto
cotto seen purl_is_stupid 04:08
purl I haven't seen 'purl_is_stupid', cotto
04:15 Austin_Hastings joined 04:22 parthm joined 04:23 japhb joined 04:42 dngor joined
cotto seen allison 04:43
purl allison was last seen on #parrot 2 days, 4 hours, 9 minutes and 58 seconds ago, saying: it's 1:30am here, going to get some sleep [May 1 00:33:40 2010]
04:56 workbench joined
dalek rrot: r46226 | plobsing++ | failed to fetch changeset:
merge pbc_frozen_strings1 branch
 05:08
sorear one idea I've been playing with recently is a "streaming" extension to PCT 05:11
right now, compilers are required to prepare all their PAST and hand it back as a big lump
but keeping all the PAST in memory at once is problematic 05:12
(especially so ATM because the PAST retains match nodes, in NQP-based compilers)
what if PCT provided an &*ISSUE hook which allowed compilers to send off PAST::Block s to the pipeline tail as they are constructed? it would have to generate a name for the block and return a PAST::Node representing the block by name 05:13
and the root block would have to become marked :main since we'd no longer be able to rely on it coming first 05:14
plobsing sorear: interesting idea. a streaming PAST model also lends itself well to task concurrency
05:15 parthm left
sorear it would also be good for "are we there yet?" types. tail -f $outputfile.pir 05:15
05:19 eternaleye joined
plobsing not holding the entire PAST tree at once could also be easier on memory consumption 05:19
sorear plobsing: that's actually the primary reason 05:22
dalek rrot: r46227 | cotto++ | trunk/MANIFEST:
[MANIFEST] regenerate manifest
 05:24
sorear PCT compilers appear to use close to O(n) space, and 6000 lines is the practical limit for NQP source files 05:27
this is not going to cut it forever
plobsing so whatcha gonna do about it? 05:28
sorear well, I've got some ideas for a solution I've been playing with
a "streaming" extension to PCT 05:29
right now, compilers are required to prepare all their PAST and hand it back as a big lump
what if PCT provided an &*ISSUE hook which allowed compilers to send off PAST::Block s to the pipeline tail as they are constructed? it would have to generate a name for the block and return a PAST::Node representing the block by name
that way, the blocks could be POSTed and written to the output file as soon as they are generated 05:30
and memory usage would only be O(nesting depth) instead of O(file size)
How is --target=past spelled these days?
plobsing an ISSUE hook seems good for the current architecture, but why not play to the advantages of the VM and use something like coroutines to manage separate compilation steps. then ISSUE simply becomes yield 05:31
sorear because ISSUE needs to return a value 05:34
my &*ISSUE := sub ($x) { $x }; is simpler than writing a coroutine-calling loop 05:35
because yield is harder to access from random languages than function calls 05:36
because dynamic-scope-wide parameters are already playing to the advantages of the VM 05:37
05:54 eternaleye joined
dalek rrot: r46228 | plobsing++ | trunk/DEPRECATED.pod:
deprecate String.lower()
 05:57
TT #1606 created by plobsing++: [DEPRECATION] String.lower() 06:00
TT #1606: trac.parrot.org/parrot/ticket/1606
06:02 uniejo joined 06:08 aukjan joined 07:16 somebody_ joined 07:18 riffraff joined 07:20 iblechbot joined 07:21 parthm joined
dalek rrot: r46229 | chromatic++ | trunk/src/pmc/imageiosize.pmc:
[PMC] Fixed C++ build error in ImageIOSize PMC.
 08:07
rrot: r46230 | chromatic++ | trunk/src/dynpmc/gziphandle.pmc:
[dynpmc] Fixed some compilation warnings in GzipHandle PMC.
moritz seen pmichaud 08:25
purl pmichaud was last seen on #parrot 10 days, 7 hours, 17 minutes and 2 seconds ago, saying: cotto_work: (troll refutation) Thanks. :-) [Apr 23 01:07:58 2010]
08:25 fperrad joined 08:30 fperrad_ joined 08:36 riffraff joined 08:42 parthm left
dalek rrot: r46231 | chromatic++ | trunk/compilers/imcc/pbc.c:
[IMCC] Rearranged the STRING comparisons in add_const_str() to find mismatches

example NQP-based PBC by 27.777%.		 09:12
rrot: r46232 | chromatic++ | trunk/src/pmc/imageiosize.pmc:
[PMC] Rearranged STRING comparisons in ImageIOSize PMC's push_string() to

by another 21.280%.
rrot: r46233 | chromatic++ | trunk/src/pmc/imageio.pmc:
[PMC] Rearranged STRING comparisons in ImageIO PMC's push_string() to filter

another 12.049%.
09:14 lucian joined
moritz wow 09:16
sorear ImageIO should probably be renamed 09:24
I read those commits and my first thought was "WTF why are we shipping a graphics file library with Rakudo" 09:25
moritz FWIW, rakudo on latest parrot segfaults on t/spec/S06-signature/errors.rakudo 09:31
(you can generate that file with `make t/spec/S06-signature/errors.t')
09:32 bacek joined
nopaste "moritz" at 192.168.1.3 pasted "backtrace from perl6 t/spec/S06-signature/errors.rakudo" (26 lines) at nopaste.snit.ch/20447 09:32
dalek kudo: c9d9a99 | moritz++ | build/PARROT_REVISION:
bump PARROT_REVISION to get some testing after merge of pbc_frozen_strings1 branch
 09:40
09:42 JimmyZ joined 10:11 clinton joined 10:12 alexn_org joined 10:23 parthm joined 10:37 jsut_ joined
nopaste "bacek" at 192.168.1.3 pasted "moritz, this is spectest result on my box..." (11 lines) at nopaste.snit.ch/20448 10:43
bacek ~~
moritz, I can't reproduce S06-signature segfault...
10:59 parthm left
moritz is on 64 bit linux 11:17
11:39 riffraff joined
dalek kudo: 1eef087 | (Solomon Foster)++ | src/core/operators.pm:
Change infix:<...> code to use the last three elements passed on the left-hand side to determine the series, rather than the first three.
 11:52
purl dalek: that doesn't look right
11:58 Mokurai joined 12:03 bluescreen joined 12:14 ruoso joined
dalek kudo: b440a11 | moritz++ | t/spectest.data:
two more passing test files
 12:49
13:11 Rahly joined 13:14 athomason joined
dalek parrot: 4bd4e44 | dukeleto++ | plparrot.c:
Use constant Parrot strings when applicable
 13:15
13:25 Coke joined
Coke anyone wants easy karma, feel free to update the codestring branch with latest changes from trunk. 13:25
particle (easy karma)++ 13:26
Coke I think I fixed sorear's bug building test.pir in codestring branch.
13:30 atrodo joined 13:33 whiteknight joined
dalek rrot: r46234 | coke++ | branches/codestring/src/pmc/string.pmc:
Don't fixup get/set string to deal with alternate storage - If you want

This avoids an issue building Test.pir on rakudo, sorear++ for reporting.		 13:33
13:36 parthm joined
bacek ~~ 13:45
Coke @bacek ~~ /Robot/ # True 13:49
bacek :) 13:50
Coke msg cotto - can we slap the svn front end on a github repo like github does? would that make everyone happy? 13:53
purl Message for cotto stored.
Coke msg (since github's svn-git seems much more transparent than git-svn)
purl Sorry, I've never seen (since before.
Coke msg cotto (since github's svn-git seems much more transparent than git-svn) 13:54
purl Message for cotto stored.
bacek Coke, erm... Why do we need svn frontend?
Coke bacek: for those who would prefer svn. 13:55
"make everyone happy" instead of "make 90% happy"
bacek is svn-git two way?
Coke bacek: whatever github is doing seems to be, yes. 13:56
13:56 Andy joined
bacek github.com/blog/626-announcing-svn-support 13:57
1st of April...
moritz it works anyway :-)
bacek hollei schitt 13:58
Coke yah. So we really can do it both ways. Only thing we need on top is trac.
ah. my bad, it's readonly. 13:59
(FOR NOW!) 14:00
bacek bacek@icering:~/src/ppp/parrot.git$ svn commit -m "Added foo" foo
svn: Commit failed (details follow):
svn: MKACTIVITY of '/bacek/parrot.git/!svn/act/08d29ebd-75ca-4ddd-a1d9-3fa6eb0e3573': Could not read status line: connection was closed by server (svn.github.com)
Coke curses. 14:02
still good for all the tinder/smoke tools.
they are currently working on the ability to commit. 14:05
"@jcaspes - working on it right now. trying to make really sure that SVN doesn't do anything stupid with your code."
14:05 parthm joined, lucian joined 14:12 confound joined, parthm joined 14:13 parthm left
Coke seen sorear? 14:16
purl sorear was last seen on #parrot 4 hours, 51 minutes and 6 seconds ago, saying: I read those commits and my first thought was "WTF why are we shipping a graphics file library with Rakudo"
14:20 bubaflub joined
Coke I suspect our problem with the svn properties in trunk is that the merge backs have not been using "--reintegrate" 14:21
14:21 GodFather joined
Coke that combined with specific ranges to the merges to branch (instead of a simple "svn merge ^/trunk") is probably causing the svn:merge property propagation. 14:22
I do wish that 'svn merge' had a verbose option to compensate for it being so slow. 14:24
14:25 GodFather joined
bacek Coke, it's called "git merge; git svn dcommit" 14:26
14:26 PacoLinux joined
Coke bacek: not helpful. =-) 14:27
to me, git >> svn >> git-svn
(the pain of the svn portion of git-svn outweighs the git goodness.)
bacek it's less painful now with svn 1.5 on server side. 14:28
dukeleto 'ello 14:29
Coke bacek: the mismatch still hurts. easier for me to just use svn if we're using svn. 14:32
(though I'd prefer using git)
dukeleto git++ 14:35
dalek rrot: r46235 | coke++ | failed to fetch changeset:
merge changes from trunk
 14:41
nopaste "coke" at 192.168.1.3 pasted "svn error?" (6 lines) at nopaste.snit.ch/20450
14:43 mikehh joined
Coke that hosed my entire checkout. 14:43
everything is locked. cleanup? can't. remove it? next directory is fubar.
bacek "git reset --hard remotes/trunk"
Coke svn--
bacek: NOT HELPERING
s/ER//
moritz svn-- indeed 14:44
bacek "helping is not implemented yet in my program"
Coke I'm not using git or git-svn. I've already said i wish to switch to git. telling me how to fix my problem /in git-svn/ is not at all helpful to me. 14:45
bacek Nice. Looks like LOLCODE testsuite expose bug in parrot lexicals.
Coke d'oh. rakudo's going to build much faster with -j1 due to memory issues, isn't it. 14:54
moritz unless you have quite some memory 14:55
and it segfaults randomly on many test files
Coke whoops.
it's segfaulting now?
(against trunk?)
moritz on r46233 14:56
Coke hopefully the segfaults are the cause of the speed increase. =-) 14:57
AREN'T
moritz: any objection to a patch that rewrote gen_builtins.pl into NQP? 14:59
nopaste "bacek" at 192.168.1.3 pasted "most beautiful parrot bug ever..." (45 lines) at nopaste.snit.ch/20451 15:00
moritz Coke: no objections... what's the benefit?
bacek output of nopasted code is "not ok 6"
If I'll comment out last .return - it will output "ok 6" 15:01
And it's 1AM already...
Coke moritz: move towards eliminating perl5 as a direct dependency to the build process for rakudo.
(plus, more sixian perl. =-) 15:02
moritz well, fine by me
maybe it should go into a different directory then
15:03 riffraff joined
nopaste "moritz" at 192.168.1.3 pasted "another rakudo backtrace on parrot trunk" (50 lines) at nopaste.snit.ch/20452 15:12
dalek rrot: r46236 | mikehh++ | trunk (2 files):
fix codetest failure - parentheses should not have space immediately after the opening parenthesis nor immediately before the closing parenthesis
 15:13
NotFound moritz: all backtraces I've looked at recently are almost the same, they are triggered from hashiterator shift. 15:16
Coke msg chromatic I just timed the codestring branch vs. trunk in building rakudo. my clock-based timings (I know, I know) show that trunk runs in 78% of the time that the branch does. :(
purl Message for chromatic stored.
moritz NotFound: can you also fix it? :-) 15:17
moritz documutes
s/o/e
whatever
purl i guess whatever is easiest to type
NotFound moritz: no, I've just be able to make it less frequent by reducing the number of short-lived pmcs. 15:18
The real culprit hasn't been diagnosed yet. 15:19
Coke (reducing # of short lived pmcs always a plus) 15:20
NotFound Coke: yes, there were a lot of them in deep paths. 15:21
init_int has been very helpful.
Coke An infrequent rant: valgrind in macports still not updated to work with 10.6 15:30
arnsholt Quite. I don't think GHC works either 15:31
NotFound I think that at least part of the problem comes from Parrot_pmc_new_temporary. Temporaries are created in the constant pool, and thus not marked. 15:36
moritz: Can you make a short test? 15:37
Uh, forget it, pge doesn't even pass tests. 15:38
purl NotFound, I didn't have anything matching it, pge doesn't even pass tests
Coke NotFound: looks like Parrot_new_pmc_temporary is hardly used. 15:39
NotFound Coke: look at cmp.ops
Coke right.
why is eq_p_i_l creating a temporary pmc at all? 15:40
NotFound Uh....
Coke (hurm. to use the LHS's vtable.) seems like there should be a better way than using a temp PMC, though. :( 15:41
(note that eq_p_n_l does it the other way, getting a numeric from the PMC and comparing them directly)
NotFound: looks evil. wonder, given how infrequently it's used, if it's still needed. if something like it is, maybe it'd be better to improve the vtable interface than rely on it. 15:51
NotFound Coke: VTABLE_equal_integer ?
16:01 davidfetter joined 16:05 darbelo joined
cotto Coke, github's svn backend is read-only (for now). 16:06
I'll bring up the question of what would be preferred at the next #ps. 16:07
16:07 integral joined
cotto I've at least done enough exploring to know that it's possible to have multiple version controls backends for trac (though having n-1 be read-only is pretty essential to maintaining sanity). 16:08
seen allison
purl allison was last seen on #parrot 2 days, 15 hours, 34 minutes and 50 seconds ago, saying: it's 1:30am here, going to get some sleep [May 1 00:33:40 2010]
16:10 theory joined 16:27 iblechbot joined 16:30 ash_ joined
dalek rrot: r46237 | mikehh++ | trunk/t/src/embed.t:
fix test failure with g++ build
 16:35
NotFound mikehh: Fail! 16:37
parrot.h must not be used from embedding! 16:38
ash_ why not use parrot.h in embedding? 16:40
is that breaking encapsulation?
darbelo Yeah.
ash_ got ya
NotFound ash_: because is for internal usage only.
darbelo It exposes all sort of things that embedders/extenders should know the details of. 16:41
s/should/shouldn't/
NotFound If real usages require a function that isn't available in extend.h or embed.h, you should open a ticket, instead of hacking up. 16:42
mikehh NotFound: I tried various other things and that was the only thing I get that test to pass with g++
NotFound mikehh: look at examples/embed/cotorra.c
mikehh it passedf with gcc - but I am dubious 16:43
NotFound mikehh: I don't care if the test pass, I care about his correctness.
If isn't correct, making it pass is counterproductive.
And we already have a lot of wrong embed tests skipped. 16:44
mikehh NotFound: ok I will look - but the calls are suspect
the string stuff got changed in r46226 16:45
darbelo Coke: ping
NotFound mikehh: if the code compiles in C without warnings, it will pass with C++ unless some header is wrong. 16:46
mikehh NotFound: yes - it claims that various functions are NOT defined (at least in g++ - it doesn't bother gcc) 16:48
NotFound Sigh. 16:49
ash_ are there some specific #includes that only happen if your in C or that don't happen if your in C++ 16:50
?
dalek rrot: r46238 | mikehh++ | trunk/t/src/embed.t:
forgot to update copyright
 16:51
NotFound Oh, nice, the Makefile in examples/embed doesn't use ccwarn 16:52
mikehh before I modified I got:
# Failed to build 't/src/embed_1.o': t/src/embed.t: In function ‘int main(int, const char**)’:
# t/src/embed.t:59: error: ‘Parrot_str_new_constant’ was not declared in this scope
# t/src/embed.t:62: error: ‘Parrot_str_to_cstring’ was not declared in this scope
# t/src/embed.t:64: error: ‘Parrot_str_free_cstring’ was not declared in this scope
that's with g++ - no problems with gcc 16:53
NotFound mikehh: we are not checking our ability to compile wrong code.
mikehh NotFound: I found similar problems in other areas 16:54
NotFound mikehh: and if we keep hiding instead of solving, we'll have it forever.
mikehh NotFound: one of the reasons I use gcc and g++ in my tests and also with and without --optimize 16:56
NotFound mikehh: sorry if I'm being rude, but that problems with embed tests are a long history. 16:57
mikehh NotFound: np - I understand where you are coming from 16:58
NotFound Uhhh... We don't have any is_null in the extend interface? :o 16:59
darbelo That doesn't sound like a good idea.
particle call the pir op from c :P 17:00
mikehh I seem to recall other tests that required adding include/parrot/extend.h 17:01
17:03 cotto_work2 joined 17:04 Mokurai1 joined
dalek rrot: r46239 | NotFound++ | trunk/examples/embed/Makefile:
use ccwarn in examples/embed
 17:07
Coke darbelo: pong 17:28
darbelo Coke: I can update codestring for you if you want me to, but I'll probably need input with regard to any conflicts from trunk. 17:34
ISTR there being optimizations on both trunk and branch. 17:35
17:37 chromatic joined
dalek rrot: r46240 | NotFound++ | trunk/t/src/embed.t:
fix embed compile string error test for C++ buildability and parrot internal correctness, and place it after a simpler test
 17:40
chromatic PMCs created with Parrot_pmc_new_temporary() don't need to be marked. 17:41
Coke darbelo: already done. 17:43
chromatic: is codestring still faster than trunk for you?
(for me, was clock-slower, but I trust your measurements more than `time`)
chromatic I haven't tried. What were you measuring? 17:44
Coke uh, darbelo, what did you?
*do
did you just merge the things I hadn't merged y et?
(and how did you do it?)
chromatic: 'make -j1' in rakudo
darbelo Coke: I dcommited before you told me it was alredy done. Sorry. 17:45
Coke darbelo: ugh. I think you reverted everything.
chromatic Parrot's -o to PBC is a lot slower on trunk.
darbelo Coke: Entirely possible if it was already up to date. 17:46
chromatic I doubled its speed, but looking for constants to coalesce is at least an O(n) operation, where it could be O(1), and that n is a lot bigger than you think it should be.
darbelo Coke: We need to revert 46241 and 46242. 17:47
I'll do it now. 17:48
Coke darbelo: thanks. 17:49
darbelo Oh, and I screwed up the non-codestring merge too. Go me! 17:50
chromatic There's too much awesome in that single file for only one branch to contain.
Coke darbelo: just revert those 2 commits, and everything will be fine.
chromatic msg plobsing Building Rakudo's PBC now takes long enough that it's time to consider the hash lookup, as well as a unification of the three places that add constant strings. 17:51
purl Message for plobsing stored.
17:51 mikehh joined
Coke chromatic: if codestring is better for you, feel free to merge it back to trunk. 17:53
(or I can, trying the --reintegrate option).
chromatic If the random segfaults are gone, that's fine. 17:54
Coke I thought those were a trunk thing.
chromatic Based on my timings, the version in the branch is faster than the version in the trunk. The slowness is another step.
Coke ... I cannot parse that last sentence in the context of the first one.
OH. the slowness is not the part we made faster. =-)
what were you using? a build of nqp-rx? 17:55
chromatic The frozen strings merge.
17:55 GodFather joined
Coke darbelo: ... see that one change looks fine. 17:55
chromatic If you time building Rakudo's core.pir from Rakudo's core.pm, codestring is faster on the branch than in trunk. 17:56
Coke the two separately looked very very wrong.
chromatic If you time building perl6.pbc from Perl6Compiler.pir, trunk is several times slower.
Coke ah, just that one thing? mmkay.
chromatic CodeString is irrelevant to the latter.
dalek rrot: r46241 | darbelo++ | branches/codestring/src/pmc/codestring.pmc:
Merge non-codestring changes from trunk.
Coke ok. I think the diff on that should be similar with the recent merge from trunk.
dalek rrot: r46242 | darbelo++ | branches/codestring/src/pmc/codestring.pmc:
Merge codestring.pmc changes from trunk as a separate commit to ease review.
rrot: r46243 | darbelo++ | branches/codestring/src/pmc/codestring.pmc:
Undo codestring mis-merges darbelo--
Coke chromatic: I just tried timings with src/gen/perl6-grammar.pir when building rakudo: 18:09
codestring built using no more than 1031M memory, took 2m0.007s; trunk took ~1400M memory, builtin 31s.
(my machine may have other stuff going on, however.) 18:10
ash_ i found a bug in nqp 18:24
well, really diakopter++ found it in perl6, and the problem also exists in nqp
PerlJam random question: should nqp get its own RT queue?
ash_ > sub foo($i) { return { $i }; }; my $a := foo(1); my $b := foo(3); say($a(), $b());
33
should be 13
Coke PerlJam: given the large overlap between rakudo & nqp devs atm... meh? 18:25
PerlJam The devs are the same, but the bugs are different.
But I guess there's also the argument to be made that NQP *is* a dialect of Perl 6 :) 18:26
anyway ... just a thought.
Coke <shrug> go for it. you'll need to manage 2 bugs queues and pull in ask & robrt.
PerlJam Coke: you've convinced me the bang/buck ratio is *way* off :) 18:27
PerlJam meeting &
ash_ how do you compile nqp into pir? parrot-nqp --target=pir filename.nqp > filename.pir doesn't seem to work 18:28
well at least when i run that pir file i get errors saying things like it cant find sub say
chromatic I'm surprised it took that much memory. It's only ever taken ~360M for me lately. 18:29
arnsholt ash_: I've had similar issues. I think say() disappears when you're in a namespace (or something like that) 18:33
It works if you replace say() with pir::say()
ash_ well, running the file works fine with parrot-nqp
Coke .pm.pir: $(PARROT_NQP) --target=pir -o $@ $< 18:34
... with a newline after the :
(from partcl-nqp's makefile) 18:35
ash: (with formatting:) github.com/partcl/partcl-nqp/blob/m...ile.in#L56 18:36
dukeleto 'ello again 18:41
how long until #ps ?
dukeleto is in a different timezone and a bit lagged in general
bubaflub dukeleto: isn't ps on tuesdays?
dukeleto bubaflub: like I said, I am lagged :) 18:42
bubaflub haha.
or from the future
Great Scott!
dukeleto 1.21 gigawatts!?!
bubaflub: congrats on getting the RTEMS project
bubaflub woo hoo!
dukeleto bubaflub: that is gonna be all kinds of fun
bubaflub i know, right?
dukeleto bubaflub: i am in NY for work, so I have not been keeping up with everything 18:43
bubaflub i'll need to eventually patch the makefile to handle out of directory builds for parrot
dukeleto bubaflub: have you been talking to the RTEMS guys?
bubaflub dukeleto: new job or just travel?
dukeleto: yep. i've got VirtualBox up and running and all the stuff built correctly already.
dukeleto bubaflub: new job. I work for solgenomics.net/ now. they are a research institute at cornell university 18:44
bubaflub ahhhhh cool. bio stuff?
dukeleto bubaflub: there is a branch to handle out of dir builds, but it is only semi-function now
bubaflub: yep. it is mostly the tomato genome project, but they are actually studying all of the Solanacaea family, which includes lots of plants 18:45
bubaflub: they are mostly a Perl+Postgres shop, so it is right up my alley
bubaflub oh nice!
dukeleto bubaflub: how is your bonding period going? are you feeling covalent yet? 18:46
atrodo That's very nice
bubaflub dukeleto: heh. i think most of the guys are in a separate time zone. i'll get my bonds on a bit more after next week
darbelo feels bound.
bubaflub finals--
dukeleto my new job is 100% telecommute as well (except for a few trips per year to the mothership). /me likes telecommuting 18:47
darbelo: that is good to hear
bubaflub dukeleto: nice. i had that for a bit last year, but switched to something local
now i'm thinking about going back to telecommuting
dukeleto i am glad both of your are previous GSoC students and know the ropes. Less work for me :) 18:48
May 24 is the end of the bonding. Wow, they sure did make the bonding period longer this year. We need to take advantage of that 18:49
bubaflub dukeleto: yeah. it's pretty nice; good amount of time after my finals to really dig in 18:50
dukeleto bubaflub: you will enjoy working with the RTEMS guys, they are very cool. I met Joel Sherril and Chris Johns at last years GSoC mentor summit 18:52
bubaflub: and parrot+rtems has potentially far-reaching implications for both communities 18:53
bubaflub dukeleto: parrots in space!
dukeleto bubaflub: and not many people get to say that their code will run in space :)
eggzactly
bubaflub bwahahaha
19:13 ash_ joined
Coke ... anyone using addrregistry? 19:45
chromatic Parrot_pmc_register.
src/interp/inter_create.c lines 269 and 270. 19:46
Coke ... why is that on the list to move to dynpmcs, then?
(if it's used by our GC ?) 19:47
chromatic I have no idea. I objected to that long ago.
Coke chromatic: could you object on the ticket?
TT # 448
chromatic I responded via email.
Coke whoops. 19:48
oh, hey, refresh, there it is. =-)
chromatic++
also, addrregistry has only the bare minimum of tests. 19:50
but that woudl be a new ticket. =-)
19:58 jsut joined
dalek rrot: r46244 | coke++ | trunk/DEPRECATED.pod:
Reflect current state of TT #448
 20:08
20:09 joeri joined
Coke chromatic: any object to whittling the list down to just file and OS? 20:13
*objection 20:16
20:19 cotto_work joined
ash_ how do you dump a var in pir? _dumper? 20:22
Coke you have to load it first, but yes. 20:29
here's a macro that does it: github.com/partcl/partcl/blob/maste...s.pir#L257 20:30
file needs a .str file; dynpmcs don't seem to support this yet. 20:31
Coke wonders what the point of dynpmc singletons is. 20:33
Coke guesses 'encapsulation'
ahahaha. File is used by pbc2exe. 20:34
msg moritz: when rakudo starts saying that it can't instantiate File and OS pmcs, insert a pir::loadlib('file'); pir::loadlib('os'); 20:36
purl Message for moritz stored.
20:37 eternaleye joined
ash_ how does capture_lex work? 20:40
Coke I don't know, but if I wanted to check, I'd like in src/ops/*.ops for the opcode source. 20:47
s/like/look/
which points to src/sub.c line 593. 20:48
note to cage cleaners, there's an "#if 0" just after that.
(ingore my previous str rant. dynpmcs need to be declared as dynpmcs, just mv'ing them doesn't help. =-) 20:50
21:05 lucian_ joined 21:26 cotto_work joined 21:32 mikehh joined, jsut_ joined 21:33 chromatic joined
dalek parrot: ca5e9ac | (Joshua Tolley)++ | Makefile:
Fix typo
 21:39
21:43 Tene joined
bacek ~~ 21:46
Good morning, humans
humans Good morning, bacek 21:48
bacek :) 21:49
chromatic, around?
ash_ how does capture_lex know what to capture? 21:50
i think there is a problem with capture_lex (or a possible problem) 21:52
chromatic I'm here. 21:53
bacek ash_, in nutshell - it iterates over :outer subs chain and capture every lex in current frame.
chromatic, nopaste.snit.ch/20451
chromatic, can you check output of nopasted pir?
chromatic not ok 6 21:54
bacek sigh... 21:55
lexicals are broken.
comment out .return and rerun it
chromatic Interesting.
ash_ gist.github.com/388632 is the bug i am referring too
chromatic 002a new P0, "String" P0=PMCNULL 21:56
002d assign P0, "ok 6" P0=String=PMC(0x9d82604 Str:"")
0030 find_lex P4, "ANOTHER" P4=PMCNULL
0033 say P4 P4=String=PMC(0x9d825a0 Str:"not ok 6")
not ok 6
0035 set_returns PC4 (1), P6 PC4=FixedIntegerArray=PMC(0x9db306c) P6=PMCNULL
0024 new P4, "String" P4=PMCNULL
0027 assign P4, "not ok 6" P4=String=PMC(0x92ff5a0 Str:"")
002a new P7, "String" P7=PMCNULL
002d assign P7, "ok 6" P7=String=PMC(0x92ff604 Str:"")
0030 find_lex P8, "ANOTHER" P8=PMCNULL
0033 say P8 P8=String=PMC(0x92ff604 Str:"ok 6")
21:56 Tene joined
bacek chromatic, exactly. 21:56
It should output "ok 6" every time.
chromatic Look at the allocated registers. 21:57
Change the P-reg in the .return to something already seen.
purl chromatic: that doesn't look right
bacek But how it's related to output of previous line? 21:58
chromatic No idea. 21:59
Isn't that strange?
bacek Also, you can comment find_lex $P23, "IT" (for example).
(Leave .return as is)
It will output "ok 6"... 22:00
chromatic Change the return from $P32 to $P31 and the output is correct.
purl chromatic: that doesn't look right
bacek It's kinda weird...
purl, forget change
purl bacek: I forgot change
cotto_work nice bug
bacek ash_, looks like your bug is same as mine... 22:03
chromatic Should we support using .lex on the same lexical name multiple times in the same scope? 22:04
ash_ hmmm i think i found some information related to my issue, trac.parrot.org/parrot/wiki/Creatin...h%20NQP-rx seems to work properly, which I wouldn't expect when you look at the issue I was having 22:05
that has a hand crafted pir::newclosure__PP op though, which I think might be nice if it was automattically done for you, at least in nqp
bacek chromatic, why not?
0032 find_lex P4, "ANOTHER" P4=PMCNULL 22:06
Breakpoint 2, Parrot_find_lex_p_sc (cur_opcode=0x8102df0, interp=0x8051040)
at src/ops/var.ops:114
114
(gdb) s
95\t STRING * const lex_name = $2;
(gdb) n
96\t PMC * const lex_pad = Parrot_find_pad(interp, lex_name, ctx);
(gdb) p lex_name
$1 = (STRING * const) 0xb7e8eb7d
(gdb) p *lex_name
$2 = {flags = 1435550665, _bufstart = 0xec83e589, _buflen = 138775320,
strstart = 0xc708508b <Address 0xc708508b out of bounds>,
bufused = 201598020, strlen = 2298478592, hashval = 2466194436,
encoding = 0x84, charset = 0x5590c3c9}
holy shit...
purl only in the Vatican, my friend.
bacek We do need to rework packfiles...
chromatic I could characterize double .lex declaration as a bug.
bacek When we unpack non-constant string in ImageIO thawed Strings have PObj_external_FLAG set. 22:07
chromatic Why are they not constant?
bacek They are.
But problem is - we move buffers behind them.
chromatic I added the external flag to STRING thawing from PBC so we didn't have to allocate buffers. 22:08
bacek chromatic, and it's wrong if Buffer isn't constant.
chromatic Assuming the PBC is still in memory, that should be okay.
bacek check runtime/parrot/library/config.pir 22:09
We read content into normal String, thaw it, free content.
Bang.
chromatic That'd do it.
Can we detect when that optimization is safe? 22:10
Do I have any Thai food in the fridge? oh yes! 22:11
bacek Not with current PackFile API...
(Removing external flag doesn't help in this case... $1 still garbage in last find_lex) 22:12
And this string come directly from IMCC... Not from PBC.
davidfetter mmm...thai fudz 22:13
bacek Actually, all constant strings looks like a garbage.
ash_ gist.github.com/388632 i got nqp to function as expected, well, sorta, i had to coerce it to 22:15
cotto_work ash_: trac.parrot.org/parrot/wiki/Creatin...h%20NQP-rx 22:17
ash_ i saw that
is there a reason nqp-rx doesn't do newclosure automattically?
chromatic I hate to remove that optimization, but until we know when we can use it correctly.... 22:18
Austin ash_: Probably because it's expensive, and not always needed. (Expensive, both in performance terms and in terms of patrick's time to implement.) 22:19
ash_ but if its the wrong behavior? 22:20
Austin Wrong how?
ash_ gist.github.com/388632 for instance 22:21
you can't curry in nqp unless you specifically call newclosure, i know its a known issue in rakudo too, but maybe its not something that should be fixed in nqp-rx? 22:22
Austin What's wrong with that? 22:23
You have different source code, you get different answers.
ash_ sorry, thats probably confusing
one sec
Austin It's not confusing. In fact, I kind of like the way you pass the block as a parameter to newclosure. That's clever. 22:24
ash_ yeah, but you shouldn't have to manually call newclosure 22:25
Austin Heh. You're in the wrong channel, dude.
davidfetter mischans to keep ash_ company 22:26
ash_ i never know where to go for nqp issues ><
Austin Heh.
This isn't an nqp issue. :) If you want automatic closures, you should be in #perl6. 22:27
:)
22:27 tcurtis joined
ash_ its not a nqp issue? because that is kinda unexpected behaviour for nqp, but maybe i am to influenced by perl6... 22:31
darbelo Crap. Forgot to squash. 22:32
Austin Remember what the NQ stands for.
ash_ yeah, true 22:33
but why even have closures in nqp then?
darbelo dalek is going to be quite spammy ina bit...
Austin There's no spec for nqp, other than "nq", so it's only an NQP defect if it prevents you from being able to do something. Since there's a pretty obvious work-around, this isn't much of a blocker..
Because they're almost free?
dalek rrot: r46247 | darbelo++ | trunk/src/sub.c:
Remove '#if 0' from src/sub.c
 22:34
Austin Patrick is a pretty smart guy, and he's involved with p6 as well as nqp. So if he happens to "borrow" some design bits for nqp, and closures are almost free, then it's a win.
dalek rrot: r46248 | darbelo++ | trunk/src/spf_render.c:
Remove '#if 0' from src/spf_render.c
rrot: r46249 | darbelo++ | trunk/src/runcore/cores.c:
Remove '#if 0' from src/runcore/cores.c
rrot: r46250 | darbelo++ | trunk/src/packfile/pf_items.c:
Remove '#if 0' from src/packfile/pf_items.c
ash_ it seems odd though that you have to be aware of the underlying implementation if you expect closures to function in the way they do in other languages, thats my gripe, but maybe its not an issue?
rrot: r46251 | darbelo++ | trunk/compilers/imcc/pbc.c:
Remove '#if 0' from compilers/imcc/pbc.c
rrot: r46252 | darbelo++ | trunk/src/pmc/bigint.pmc:
Remove '#if 0' from src/pmc/bigint.pmc
rrot: r46253 | darbelo++ | trunk/src/interp/inter_create.c:
Remove '#if 0' from src/interp/inter_create.c
rrot: r46254 | darbelo++ | trunk/src/interp/inter_cb.c:
Remove '#if 0' from src/interp/inter_cb.c
rrot: r46255 | darbelo++ | trunk/src/debug.c:
Remove '#if 0' and nearby commented out code from src/debug.c
rrot: r46256 | darbelo++ | trunk/compilers/imcc/cfg.c:
Remove '#if 0' from compilers/imcc/cfg.c
Austin shrugs.
At least you aren't coding in assembly.
ash_ true
darbelo Aw. C'mon, assembly's *fun*. 22:36
ash_ i like to abstract away my assembly with a few layers of indirection, personally :P 22:37
darbelo That's what C is for, yes.
;)
cotto_work darbelo: did you check if any of those #if 0 pieces were worth keeping? 22:38
darbelo cotto_work: Not really. The few I looked at were out of sync enough with the surrounding code that they weren't worth keeping. 22:40
Or amounted to little more than the comments surounding them.
cotto_work fair enough. bitrot can set in pretty quickly.
darbelo The upside of me forgetting to squash the commits is that now you can review/revert separately! 22:41
cotto_work are you using git-svn? 22:42
darbelo I'm trying it out, yes.
After merging my last branch with svn, I'm not confident in svn's ability to carry me through GSoC in a branch. 22:44
cotto_work I found some information that started to look like it'd give me a solution to the merge problem. 22:45
I haven't gotten far enough to figure out if it'll work or if it's the info I'll need.
darbelo Does it make svn 4x faster when merging?
cotto_work I'm going for "doesn't leave me with a broken and useless checkout". 22:46
darbelo I had to sit through an endless parade of mergeinfo updates and resolve a big wad of self-inflicted tree conflicts for a merge that edited three files. 22:47
cotto_work I'm going to try to put more effort into making svn work. If nothing else, I'll at least have a more legitimate gripe with it. 22:48
Being able to merge would certainly be a bonus.
darbelo Well, to be fair, svn *merged* in my case. It just took me less time to patch/add/remove/ the files by hand. 22:50
Oh, and that yielded me 0 conflicts! It was, overall, a lot less effort. 22:51
So, doing stuff by hand is easier than using the tool. That means I don't need the tool.
Full disclosure: I'm not a git apologist either. It's just hurt me less so far. 22:56
bacek I'm not git apologist either. 22:57
Git is just "right tool for the job" 22:58
At least for now.
darbelo It maps better to my workflow, at the very least. 22:59
chromatic Same
dalek rrot: r46257 | chromatic++ | trunk/tools/docs/filename_and_chapter.pl:
[tools] Made tools/docs/filename_and_chapter.pl compile again, then removed the
 23:07
mikehh tools/docs/filename_and_chapter.pl FAILs perlcritic - Subroutine prototypes used at line 14 and 70 23:14
all other tests PASS (pre/post-config, make corevm/make coretest, smoke (#33614), fulltest) at r46256 - Ubuntu 10.04 amd64 (g++)
bah - forgot to commit 23:16
chromatic I just fixed that anyway.
mikehh I noticed :-} 23:20
BTW why does headerizer NOT remove stuff - it only seems to add
sorear Coke: Hi 23:21
purl niihau, sorear.
darbelo mikehh: Nobody patched it to remove ;) 23:22
mikehh maybe it should start with a clean slate
darbelo holds up a sign with 'patches welcome' scrawled on it. 23:23
dalek rrot: r46258 | mikehh++ | trunk/src/packfile/pf_items.c:
fix codetest failure - unused assertmacros (headerizer does not seem to remove definitions/macros)
mikehh maybe you should do the sackcloth and ashes bit :-} 23:24
mikehh remembers looking at it when we did the PCC hackathon a while back 23:28
23:33 Whiteknight joined
cotto_work g'day Whiteknight 23:33
This is odd. Someone hacked out a C to HLL (Lisp, C, Lua, js, Java) compiler. cluecc.sourceforge.net/ 23:38
Whiteknight hello cotto_work
tcurtis cotto_work: The really odd part of that is the C to C-without-integers-or-single-floats compiler. 23:45
sorear not particularly
if you want to target lua...
tcurtis Why compile C to C at all, though? 23:56
cotto_work There's a similar project called CIL that compiles C to a subset of C. 23:58
cil? 23:59
purl somebody said cil was the .NET assembly language. or C Intermediate Language or hal.cs.berkeley.edu/cil/

Powered by Cro and the Raku® Programming Language.

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

Thank you!