HAPPY BIRTHDAY #PARROT! | www.parrot.org/ | 1.4.0 | For 1.5: Remove Deprecated Features | planet.parrotcode.org/
Set by moderator on 11 August 2009.
dalek tracwiki: v4 | japhb++ | ModuleEcosystem 00:02
tracwiki: Edits from post-email-thread #parrot chats
tracwiki: trac.parrot.org/parrot/wiki/Module...ction=diff
cotto I think that mysterious "Shane Warden" fellow may have to reveal himself. ;) 00:05
00:06 Psyche^ joined
TimToady I hear he's a colorful character... 00:08
cotto and he scales 00:09
dalek tracwiki: v5 | japhb++ | ModuleEcosystem 00:12
tracwiki: Add an Overview section
tracwiki: trac.parrot.org/parrot/wiki/Module...ction=diff
japhb OK, I think I'm done with editing trac.parrot.org/parrot/wiki/ModuleEcosystem for now.
cotto allison, if you're not going to be able to merge pcc_arg_unify RSN, could you add the corevm make target to trunk? It'd be handy for what I'm doing (and I imagine it'd help other people too). 00:19
allison cotto: sure 00:22
cotto Thanks.
00:28 angoladon joined
dalek kudo: 1e358a9 | pmichaud++ | docs/spectest-progress.csv:
"2009-08-12 00:00",a5dfe96,12303,0,535,2260,15098,17636,428
 01:01
01:03 nperez joined
dalek TT #912 created by darbelo++: [PATHC] remove statement with no effect. 01:05
darbelo Oh crap, I can't believe I just misspelled PATCH. 01:06
cotto: ping 01:29
cotto darbelo, pong
darbelo I had a though today, about reduncing decnum-dynpmcs's dependendecies on perl. Particularly in the makefile. 01:30
We still need it as pmc2s is a perl script, but the best way I found was to reduce *parrot's* use of perl (well $(PERL) ) on makefiles. 01:31
I came up with this (wait for the nopaste). 01:32
nopaste "darbelo" at 200.49.154.172 pasted "less $(PERL) on Makefiles" (25 lines) at nopaste.snit.ch/17529 01:33
darbelo Is this kind of effort worth the trouble? 01:34
For parrot, I mean.
dalek rrot: r40505 | allison++ | trunk/t/op/sprintf.t:
[cage] Remove dependency on PGE in a test file where it's never used.
 01:36
cotto darbelo, I don't think so. We'll eventually need to to do something like that (and I don't think there's any harm in it now), but the main problem is converting existing Perl-based tools to PIR. 01:37
dalek rrot: r40506 | allison++ | trunk/t/pmc/key.t:
[cage] Remove dependency on PGE in test file where it's never used.
 01:40
01:40 eternaleye joined
ttbot allison: Parrot trunk/ r40505 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/69354.txt 01:42
01:42 satrac joined
cotto msg whiteknight Take a look at tt #912. The line that the ticket refers to comes from r40368. 01:43
purl Message for whiteknight stored.
darbelo cotto: Thanks, that's the main reason I was asking. 01:45
ttbot allison: Parrot trunk/ r40506 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/69371.txt
kid51 darbelo: I am testing your patch right now, but, given cotto's message, I won't apply it until whiteknight takes a look at it 01:46
allison whatever ttbot is, the links are unloadable
kid51 allison: I just got the 69354.txt one. 01:47
darbelo That looks suspiciously like a mis-paste or a typo to me. The line just before the one I removed frees interp->arena_base->attrib_pools. The alternative is to "interp->arena_base->attrib_pools = NULL;". 01:48
allison kid51: just hangs for me, never loads
darbelo But that requred more keystrokes ;)
nopaste "kid51" at 68.237.15.24 pasted "bot report 69354" (513 lines) at nopaste.snit.ch/17530 01:50
01:53 dukeleto joined
allison kid51: looks like a flag was added to a function without rerunning make headerizer 01:58
trac.parrot.org/parrot/changeset/40504/trunk
01:59 satrac left
dalek rrot: r40507 | allison++ | trunk/include/parrot/oo.h:
[cage] Rerunning header generation to fix build failure after r40504.
 02:03
02:17 Fr0stify_ joined
dalek rrot: r40508 | allison++ | trunk/t/op/io.t:
[cage] Make pipe test actually test the string read from the pipe,
 02:27
rrot: r40509 | allison++ | trunk (3 files):
[cage] Move PGE regression tests out of core tests and into PGE tests.
 02:37
GeJ FYI As of r40508, make smoke PASSes every tests (+2 TODO) on FreeBSD amd64 02:41
02:42 janus joined
GeJ as of the 2 TODO, it looks like freebsd can be added in the list of the 'tt661_todo_test' sub in t/op/io.t. (line 54 and following) 02:43
kid51 must sleep 02:44
purl $kid51->sleep(8 * 3600);
dalek kudo: 2befdd3 | pmichaud++ | src/ (2 files):
Move infix:<x> to setting.
 02:46
kudo: 4e906bc | pmichaud++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
02:53 contingencyplan joined
dalek rrot: r40510 | allison++ | trunk/t/pmc/sub.t:
[cage] Revising number of Sub PMC tests after deleting two.
 02:57
03:01 Psyche^ joined 03:05 quek joined
dalek rrot: r40511 | allison++ | trunk/t/pmc (2 files):
[cage] Don't depend on PGE in core tests, use 'substr' instead of 'like'.
 03:18
03:20 tetragon joined
dalek rrot: r40512 | allison++ | trunk (2 files):
[build] Alter 'coretest' target so it only builds and tests the core vm.

the core vm. The default build target is still 'all'.		 03:25
03:29 quek left 03:32 chromatic joined
mikehh I am FAILing t/pharness/01-default_tests.t - Failed tests: 9, 13, 23, 28 (post-config) at r40512 03:38
03:39 dukeleto joined
mikehh got '10' expected '3' in each case 03:40
plus some warnings Warning: Building a shared parrot library may conflict with your previously-installed /usr/local/lib/libparrot.so in pre-config tests and config 03:43
Coke eternaleye: thanks for the pointer, but that section (clone locally) is fully of things that I have no idea if I should cut and paste or if I should replace with other info. 04:04
dalek rtcl: r578 | coke++ | trunk/ (17 files):
- use 'get_bool' vtable instead of 'getBoolean' MMD.

   (grammar, toBoolean, [string is]) into the grammar.
   - bump PARROT_VERSION so we can do the vtable override.
   - add tests for [string is boolean/true/false].
   - collapse now very similar prefix:! variants.
Coke msg allison (always have the inferior loop problem) ... isn't that the sign of a fundamental design problem?
purl Message for allison stored.
allison Coke: no, it's a sign of the limitations of C
04:05 Psyche^ joined
allison Coke: but, C has advantages too, like a large number of libraries available to do various tasks 04:06
chromatic We could solve it with a different approach and still take advantage of C. 04:07
allison Coke: we elimination inferior runloop if we entirely eliminate ever loading or running C libraries
eliminate, I mean
if Parrot is embedded in C code, or loads C extensions, the problem is always there 04:08
Coke ok. well, for now, it's affecting more and more of partcl.
(up to six tests that ABEND but pass)
allison the goal is to minimize the effects, push the boundary back as far as possible
PerlJam Wow ... I haven't seen anyone say "ABEND" in a long while.
allison Coke: what specific problem are you running into? 04:09
Coke allison: the same RT that's been open for years.
I'll dig it up.
to sum up: PIR (a) -> C -> PIR (b) ; b throws exception, a catches it, boom.
allison (there's a lot under the general category of inferior runloop, so this might just be a bug, rather than one of those universal constants)
Coke RT #57088 04:10
allison ah "attempt to access code outside of current code segment", got it 04:11
that is a bug 04:12
chromatic Slow core works, CGOTO core doesn't... but progress.
allison that is, it's perfectly possible to switch to the correct code segment before executing code in it
chromatic Hm, I wonder if we could include information about which packfile to switch to when catching an exception.
allison chromatic: the handler is a continuation, which is a sub, so it should know it's packfile 04:13
dalek rtcl: r579 | coke++ | wiki/TestingPartcl.wiki:
more tests failing due to RT #57088
 04:14
rtcl: r580 | coke++ | wiki/ParrotIssues.wiki:
more tests failing due to RT #57088
rtcl: r581 | coke++ | wiki/TestingPartcl.wiki:
Fix typo, clarify what to expect.
 04:19
rrot: r40513 | mikehh++ | trunk/t/compilers/pge/regression.t:
fixed svn properties for t/compilers/pge/regression.t
 04:22
rrot: r40514 | mikehh++ | trunk/t/compilers/pge/regression.t:
copyright up to date for t/compilers/pge/regression.t
 04:36
04:39 MinorToken joined 04:51 petdance joined
Coke nukes git-svn from orbit. it's the only way to be sure. 04:55
mikehh post-config tests FAIL, All others (pre-config, smolder, nqp_test, fulltest) at r40514 - Ubuntu 9.04 amd64 04:57
Coke if only someone with a commit bit was awake to fix them! =-) 04:58
mikehh FAILing t/pharness/01-default_tests.t - Failed tests: 9, 13, 23, 28 (post-config) got '10' expected '3' in each case 04:59
coke : I am looking - trying to figgure it out
05:00 TiMBuS joined
dalek kudo: 69eee0d | pmichaud++ | docs/release_guide.pod:
Add chromatic as December release manager.
 05:01
05:02 nathanmccauley joined
cotto mikehh, good for you. That's how you learn. 05:03
05:08 dukeleto joined
eternaleye Coke: If you want, I could try to walk you through it 05:24
Coke: I'll do a nopaste that encloses everything you should change in {{ ... }} 05:26
Coke: And annotates it with comments
Coke: Better yet, I'll make a shell script 05:27
nopaste "GeJ" at 202.171.79.162 pasted "un-TODO 2 tests that pass fine on FreeBSD (both i386 and amd64)" (11 lines) at nopaste.snit.ch/17531
GeJ if anyone would like to review the patch. 05:28
smolder.plusthree.com/app/public_pr...ails/26098 and smolder.plusthree.com/app/public_pr...ails/26095 prove that the tests pass. 05:29
Just ran a make fulltest locally with the patch applied, and everything ran fine.
NotFound GeJ: I think it will be better to unTODO them completely.
GeJ As you wish. I probably can ask someone in @NetBSD.org for a quick run to get confirmation. I don't know anyone running OpenSolaris though. I just wanted to play on the safe side here and unTODO where I can prove it works. 05:32
NotFound GeJ: that is fine for the first attempts, but the list is getting too long. 05:35
nopaste "GeJ" at 202.171.79.162 pasted "As per NotFound's suggestion, unTODO the tests for everyone." (59 lines) at nopaste.snit.ch/17532 05:38
eternaleye Coke: see dpaste.com/79133/ (a script to do the git-svn cloning, asking you the appropriate questions) 05:39
05:42 dukeleto_ joined
GeJ NotFound: do you think that would do? 05:43
NotFound GeJ: looks good
GeJ Monday, new job. Regular hours. I give myself one month to get that CLA of mine approved. 05:50
Just so you know. Be prepared to get some patches to commit.
dukeleto_ GeJ: is that a threat ? ;) 05:55
GeJ that, it is! :) 05:56
I'm planning to resume my PerlToPIR conversion. Refactor Data::Dumper so it doesn't 'print' by default. use that to convert some more tests. And then I'll ask around what else I could do. 05:59
06:06 uniejo joined 06:08 tetragon joined
Coke eternaleye: thanks for putting that together. Any chance you could add some comments at the bottom indicating the workflow? 06:32
(e.g. can I now dcommit from the clone of the clone?)
(or just push from there, and then dcommit from the primary clone?) 06:33
eternaleye Coke: The result is identical to the original git-svn repo, and interacts directly with SVN
Coke eternaleye: then what is the point of having it be a clone?
eternaleye dcommit
NOT push->dcommit
Coke how is tht different from just doing "git svn clone" 2x?
eternaleye Coke: Using the more efficiant git:// protocol for the clone? Not hammering the SVN server? 06:34
*efficient
Coke but from a /local/ perspective, no different?
eternaleye It's much faster, for one
Coke: Correct
Coke ... ok. that's entirely not what I was trying to do. =-) 06:35
NotFound The LexPad PMC has a PMC attribute but it hasn't a custom mark. Is this correct?
eternaleye Coke: You could also try using a --bare repo for the concentrator, and use 'git --bare /foo/repo svn dcommit' - that avoids the 'push/working copy' problem 06:36
Coke: But I don't know hoe git-svn interacts with bare repos 06:37
*how
Coke at this point, I'm just giving up and having a single git-svn repo that I work directly out of (one per platform). If I have to work on 2 platforms, I'm just going to hope that I don't have to share between the two.
eternaleye laaaaaag
Coke (and if I do, I can probably do it on an svn branch) 06:38
thank you very much for trying to help out.
zzz
06:40 mokurai left 06:42 mberends joined
bacek_at_work "Patrick R. Michaud's birthday Today" (c) Facebook :) 06:48
pmichaud: happy birthday :)
cotto pmichaud, happy birthday! 06:49
mikehh pmichaud: many happies also 06:50
ok I think I figured that test out
dalek rrot: r40515 | mikehh++ | trunk/t/pharness/01-default_tests.t:
fix t/pharness/01-default_tests.t to reflect changes in Parrot::Harness::DefaultTests
 07:10
07:17 chromatic joined
mikehh All tests PASS (pre/post-config, smolder, nqp_test, fulltest) at r40515 - Ubuntu 9.04 amd64 07:32
rakudo (69eee0d) builds on parrot r40515 - make test/make spectest (up to 27976) PASS - Ubuntu 9.04 amd64 07:49
07:53 dukeleto joined 07:56 szabgab joined
mikehh well I managed to get partcl to build and make test comes up with FAIL but seems to pass the tests 08:06
dukeleto mikehh: interesting 08:07
trac.parrot.org/parrot/report/19 is b0rked 08:10
mikehh 6 test files out of 74 come up with FAIL but all display the error message - attempt to access code outside of current code segment and have exit code 1 08:15
for example t/cmd_while.t .................. 1/6 attempt to access code outside of current code segment 08:16
t/cmd_while.t .................. Dubious, test returned 1 (wstat 256, 0x100) 08:17
All 6 subtests passed
dukeleto sounds bad 08:21
what language are *.ops files written in?
eternaleye dukeleto: C with some sugar 08:22
ops2c turns them into straight C
dukeleto eternaleye: good to know, thanks
eternaleye mikehh: ISTR that Coke was talking about having that problem earlier, so it may be a known issue 08:23
dukeleto eternaleye: how does multimethod dispatch work with ops?
eternaleye <Coke> ok. well, for now, it's affecting more and more of partcl. 08:24
<Coke> (up to six tests that ABEND but pass)
<Coke> ok. well, for now, it's affecting more and more of partcl.
<Coke> (up to six tests that ABEND but pass)
dukeleto can I define an op with two different function signatures, or is there some other magic that I need to do? I guess I should read some other *.ops files
eternaleye gahh, lag
mikehh: ^^^^\\
mikehh I think I saw that - but anyway I can now include partcl in my testing 08:26
dukeleto eternaleye: i answered my question about mmd, it seems to work as I thought it would 08:27
eternaleye dukeleto: Cool, I'll remember that (I didn't know either, I've never seen them - the only reason I could answer the previous question was that I lurk here a lot, read all the blogs, and backlog aggressively) 08:28
08:28 bacek joined
cotto dukeleto, there are lots of functions like that. 08:29
mikehh got some other things to sort out - afk for a bit
dukeleto cotto: i don't immediately see ops that "return", only ones that modify the input variables ($1,$2, etc...)
cotto: I am trying to implement the rand op in trac.parrot.org/parrot/ticket/871 08:30
cotto Yeah. Ops don't really return, they just mess with the control flow.
use something like "inline op abs(out NUM)" and put the value into $1 08:31
s/abs/rand/ (but now you know where to look ;) 08:32
dukeleto cotto: yeah, I was looking at the math ops for inspiration
so I will attempt to implement the syntax "rand $N0, $N1" where $N0 gets a random value between 0 and $N1
cotto I'd implement a version that does 0..1, 0..$1 and $1..$2, but it's a pretty simple change. 08:33
s/a version/versions/
s/does/do/
bacek o hai. 08:34
cotto just write functions with the same names and different args and ops2c will dtrt
dukeleto cotto: cool
bacek: 'ello
bacek cotto: you forgot about ops.num 08:35
dukeleto: elho
cotto I think it'll be a dynop, so ops.num won't matter
bacek cotto: ah. ok.
dukeleto yeah, I am implementing rand as a dynop
bacek dukeleto: than ops2c will dtrt 08:36
dukeleto bacek: is ops2c documented anywhere? 08:37
i run ops2c on my .ops file and then what? or do I add my new *.ops file to some other list of dynops ?
bacek dukeleto: sorry. No idea... 08:38
cotto My strategy would involve copypasting from the part of the makefile template that builds the current dynops.
config/gen/makefiles/dynoplibs.in 08:40
dukeleto got it
wow, there is a lot going on in there 08:41
cotto that's why I'd copypaste
08:43 HG` joined
dukeleto cotto: cargo-culting in progress 08:43
cotto I love that expression. 08:46
08:46 masak joined
dukeleto any suggestions for what kind of simple RNG to use at first? 08:46
cotto Isn't there a built-in function for that that's already part of Parrot's API? 08:47
dukeleto cotto: that would make life a bunch easier. I thought I had to write one
cotto Nope. Just use what src/pmc/random.pmc uses. 08:48
sorry to disappoint
We don't have an API for getting random bits from the system. 08:49
dukeleto Parrot_float_rand looks useful
cotto useful and delicious 08:50
nothing hits the spot like a couple K of random data 08:51
dalek rrot: r40516 | NotFound++ | branches/auto_attrs/src/pmc/lexpad.pmc:
set auto_attrs on LexPad PMC
 08:52
dukeleto mmmmmmmm, entropy 08:54
what is the difference between in and invar in an op signature? 08:56
inline op setattribute(invar PMC, in STR, invar PMC) :object_classes {
cotto lemme dig for a minute 09:00
in passes a value, invar passes a variable 09:01
dukeleto interesting 09:02
how do I regenerate just the src/dynoplibs/Makefile ?
cotto rerun Perl Configure.pl 09:03
I think there's a way to be more fine-grained, but I don't remember it. 09:04
dukeleto that works, thanks
i am getting close to seeing if this works 09:05
it compiled and loaded! 09:06
now for some real tests 09:07
cotto good night and happy testing
dukeleto sweet 09:09
cotto: thanks a bunch!
09:21 muixirt joined
muixirt hi 09:22
purl hey, muixirt.
dalek rrot: r40517 | NotFound++ | branches/auto_attrs/src/pmc/codestring.pmc:
set auto_attrs on CodeString PMC
 09:32
dukeleto 'ello 09:44
dukeleto is about to commit-and-pass-out
09:48 donaldh joined, Whiteknight joined 09:51 ComLock joined 10:00 Psyche^ joined
dalek rrot: r40518 | dukeleto++ | trunk (4 files):
[TT #871] Add rand as a dynop, with tests
 10:02
bacek dukeleto: "with tests"??? What 'bout blackjack and hookers??? 10:04
dukeleto bacek: saving that for tomorrow ;) 10:05
bacek it's almost tomorrow here!
dukeleto it is 3am here and I am waaaaay past bedtime 10:06
see you on the flip side
it was really easy to add a dynop to parrot. that fucking rocks
dalek TT #912 closed by whiteknight++: remove statement with no effect 10:18
NotFound Whiteknight: 10-15% faster? That's wonderful :) 10:19
dalek rrot: r40519 | whiteknight++ | trunk/src/gc/api.c:
[tt #912] fix a meaningless statement that should have set pointer to NULL. darbelo++ and kid51++ for finding it
Whiteknight those are just the quick'n'dirty benchmarks I got from Infinoid 10:20
only affects some tests, others showed no improvement
NotFound Nice enough
dalek rrot: r40520 | NotFound++ | branches/auto_attrs/src/dynpmc/dynlexpad.pmc:
set auto_attrs on DynLexPad PMC
 10:33
10:36 rdice joined 10:44 Patterner joined
jonathan Anybody know what writes MANIFEST.generated? 10:53
oh, it's not generated per install 10:55
10:59 mikehh_ joined 11:12 payload joined
dalek rrot: r40521 | jonathan++ | trunk (2 files):
[config][install] A couple of fixes to make installed Parrot work out better for Win32 and MSVC++. With this plus some tweaks in Rakudo, Rakudo now builds on an installable Parrot on this platform.
 11:14
11:22 donaldh joined
dalek rrot: r40522 | NotFound++ | branches/auto_attrs (83 files):
merge from trunk r40521
 11:32
kudo: 75293d3 | jnthn++ | build/PARROT_REVISION:
Bump us up to latest Parrot revision to get Win32/MSVC++ install related fixes.
 11:34
kudo: 0d4fe08 | jnthn++ | (2 files):
A copule of tweaks to get Rakudo building on MS VC++ and Win32 again after the ins2 branch merge. I'm hopeful that this will not break things too much for @other.
11:53 whiteknight joined 12:02 ruoso joined 12:04 cotto joined 12:13 jsut joined
dalek tracwiki: v31 | kjs++ | PIRCDevelopment 12:45
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
tracwiki: v32 | kjs++ | PIRCDevelopment 12:48
tracwiki: trac.parrot.org/parrot/wiki/PIRCDe...ction=diff
Coke finds that he's inadvertently broken 'make spectest' for partcl. 12:54
(even though make test is still ``working'')
dukeleto++ 12:55
dalek rrot: r40523 | fperrad++ | trunk/lib/Parrot/Docs/Section/Parrot.pm:
[doc] add PCT book
 12:57
12:57 uniejo_ joined
dalek rrot: r40524 | fperrad++ | trunk/docs/book/pct (2 files):
[doc] typo
 13:01
13:12 kj joined 13:35 payload joined 13:39 JimmyZ joined
Coke IWBNI if I could tell -t4 "don't bother if you're not in my HLL 13:51
(I don't need to be tracing TGE and PGE) 13:52
AIGH. took 5 minutes with -t4 to tell me I had a bug in my program and I didn't get the output I wanted . =-) 13:57
14:02 pyrimidine joined 14:10 ash_ joined
mikehh Coke: I tried to run make spectest in partcl and it seemed to do nothing except print messages about Method whateever not found for invocant of class 'Sub' and skippiong tests 14:12
Coke RT@: /me finds that he's inadvertently broken 'make spectest' for partcl. 14:16
danke.
mikehh makr test got the same errors you reported earlier - exit 1 for 6 test files but "passes tests" 14:18
make
did make spectest work before? 14:19
Coke at some point. 14:23
moritz at some point after 1.0?
Coke it's probably not broken due to parrot. 14:24
yes. See docs/*progress* for the last good run.
it takes hours to run, so I don't run it every time I change something.
probably broken when I converted the MMD "toList" into individual methods on PMCs. (it takes something like "foo bar" and turns it into a 2 element array) 14:25
no clue why it's trying to invoke that on a Sub.
mikehh looks like it ran at r40228 14:27
14:29 Psyche^ joined
Coke again, it's not a parrot bug. 14:29
at least, it's very likely not. 14:30
treed git bisect? 14:35
purl git bisect is hot
14:35 whoppix joined
pmichaud muixirt: the theory was that compilers could potentially optimize certain codepaths to use the integer and string registers instead of taking everything through PMCs 14:46
14:46 hercynium joined
pmichaud oops 14:47
sorry, was in backscroll and didn't realize it
(nm)
muixirt np
14:49 szabgab joined
muixirt pmichaud, while we are at it, is it possible with pct-based system to make such optimizations at runtime, for the dynamic parts of a program? 14:55
Coke treed; if only partcl was hosted in git! 15:05
(oh wait, I can use that if I have git-svn, I bet.)
dalek rrot: r40525 | mikehh++ | trunk (2 files):
fix svn properties on src/dynoplibs/math.ops and t/dynoplibs.math.t
 15:06
15:07 Psyche^ joined
treed Coke: You can even give it a script to use to automate the search. 15:10
It'll assume that returning 0 means good, non-zero means bad.
(I think; might be the other way around.)
Is there any support in Parrot for private/protected methods? 15:11
mikehh is there any way to set properties on added files for those using git svn? 15:12
moritz wonders if a server side hook could automatically set those
just apply the same rules as the test files use
JimmyZ p6l? 15:13
purl somebody said p6l was often funny. or the perl6-language mailing list
mikehh t/distro/file_metadata.t 15:17
purl t/distro/file_metadata.t is sad
15:20 donaldh joined
dalek ose: r96 | Austin++ | trunk/ (25 files):
Got type-resolution problem with builtins resolved (0 messages\\!)
 15:27
pmichaud muixirt: I don't know what all will be possible there. Currently the biggest stumbling block is that lexicals can only be PMCs, not int/string/num 15:28
muixirt pmichaud, ok thanks 15:29
mikehh All tests PASS (pre/post-config, smolder, nqp_test, fulltest) at r40525 - Ubuntu 9.04 amd64 15:32
15:44 nathanmccauley joined
mikehh rakudo (0d4fe08) builds on parrot r40525 - make test/make spectest (up to 27980) PASS - Ubuntu 9.04 amd64 15:49
dukeleto mikehh++ 15:54
15:56 nperez left
Coke tim bunce? 16:13
bunce?
16:18 pyrimidine joined, pyrimidine_ joined 16:38 bacek joined 16:46 mokurai joined
mikehh there seem to be problems with packfile on i386 - tests failing with failed assertion '(INTVAL)hash->key_type == k_type' 16:48
just looking at smolder - I am not on i386 at the moment
actually they all seem to have been submitted by smoke@smoke 16:55
Coke are those the i686 failures? 17:07
(where one thing was reporting i686 and the other 386, on the same smoke.)
17:13 chromatic joined
mikehh Coke: 1.4.0, Perl 5.8.8 i686-linux, cc (gcc 4.1), i386, linux 17:16
there are no other linux i386 reports available on smolder at the moment (81 failures all packfile tests) 17:18
all the failures were submitted by smoke@smoke 17:20
and we are still getting smolder reports on parrot 0.9 17:21
chromatic Are those 0.9 smolder reports using the svn.perl.org repo? 17:23
mikehh my last smolder on i386 was yesterday at r40493 when everything PASSed 17:24
chromatic: looking - smolder is very slow for me 17:26
Coke mikehh: those smokes are covered in the open TT 17:27
search tickets for packfile.
we need to find out whose machine that is with a 686 perl and a 386 os.
but it's not surpring that would fail, given how we rely on perl's config.
NotFound smoke sent by me now 17:35
mikehh Coke: it just reports the perl build by the distro and gcc - so i686 just means that the compiler was built to run i686 not earlier versions 17:36
for example I think Ubuntu 9.04 i386 reports i486
17:37 allison joined
mikehh I once went and built gcc for i686 - I think it was on Ubuntu 8.10 i386 - it took over a day - I haven't tried since 17:44
Coke mikehh: yes. so when we pull information from the perl built for 686 to run it on a 386, we're probably getting invalid sizes for some things that are screwing up the packfiles
NotFound I don't think any type in gcc changes size between i386 and i686 settings. 17:45
mikehh Coke: no - it don't work like that - it just means that the compiler will generate code that can run on earlier versions - you would only have problemsd if you tried to run on a 486 for example 17:46
l3t0 mornin' 17:47
mikehh if you built on a 486 with a compiler for i686 it wouldn't run 17:48
Coke mikehh: are you aware of what our Configure.pl does with the perl that's used to invoke it?
mikehh more or less
purl thereabouts
mikehh perl is supposed to be crosas-platform 17:49
Coke ok. I'm not saying things aren't going to compile. I'm saying that parrot is probing the perl built for/on 686 for information, and using that when configuring itself.
mikehh cross
sure but it has to be running on at least an i686 to be running if it says so 17:50
Coke I'm just saying it's a potential incompatibility. 17:51
NotFound I think Configure doesn't set gcc platform flags, just use anything gcc has as default. 17:54
17:55 einstein joined
NotFound But meybe is just because perl was built also without that options. 17:55
mikehh there are quite a few potential incompatabilities all the way through parrot integer, long, long long, double etyc.)
einstein I added a patch to ticket #549 to kill the unionval from the pmc struct 17:56
mikehh the most recent smolder report submitted from linux i386 - PASSes (5.10.0 i486-linux-gnu-thread-multi) - same as I run on i386 17:58
NotFound mikehh: that's mine 18:03
allison I don't know how advanced this is, but the git users might find this interesting oreilly.com/go/gitinanhour (free) 18:09
NotFound allison: Have you seen my last report on TT #895 ? 18:12
allison NotFound: looking...
Coke mikehh: the recent partcl spectest failurs are because the foreach command is getting passed in Sub objects, and is then trying to convert them to lists. Why it's getting a sub object, Iunno. (if I catch the exception and just set the list to [], I seem to be able to run the test again. 18:13
18:13 bacek joined
Coke But I have no idea why it's getting Sub objects where it wasn't before. 18:13
18:13 ash_ left
Coke Allison - was there a change recent in the PIR compiler? 18:13
"recently". ISTR seeing something about having it not return an Eval but just a Sub, but I don't know if that happened. 18:14
allison Coke: that hasn't been changed, but it was mentioned in one of the deprecation tickets 18:15
allison digging...
Coke k.
allison trac.parrot.org/parrot/ticket/448
18:16 Andy joined
Coke so in [foreach varname list body], somehow "list" is a sub here. will have to bisect partcl to see when that happene. 18:17
allison Coke: that is odd
Coke Since I don't have tcl's stacktraces working yet, it's harder to setup the test case than it should be. :|
allison NotFound: I'm assuming the "#if 0" sections of the code are going away? 18:20
NotFound allison: they're here just to be able to benchmark the impact of the fixed size allocator.
18:23 brooksbp joined
allison NotFound: if SUPER() is the only thing a vtable function does, you can just delete the VTABLE definition 18:28
(ResizableIntegerArray)
since not defining a vtable function with that name will call the one inherited from the parent anyway
Coke huh. bisect shows that partcl's partcl.googlecode.com/svn/trunk@578 is to blame. 18:30
allison NotFound: (let me know if I should bundle comments into an email) 18:31
Coke er, code.google.com/p/partcl/source/detail?r=578
allison NotFound: how does auto_attrs handle freeing children of the 'data' struct?
NotFound: in the Exception PMC, I see the 'destroy' vtable function handled freeing a context stored as 'thrower' (the context where the exception was thrown) 18:33
NotFound allison: it just take care of the attribute struct, attributes that needs special freeing are the responsability og his PMC
allison NotFound: okay, so that destroy vtable function can't be deleted 18:34
NotFound: will the auto_attrs automatic destruction come after the 'destroy' vtable function is called?
NotFound allison: In one case deleting the destroy function caused problems, I still don't know why.
allison: yes, the gc routines free it after calling destroy. 18:35
nopaste "allison" at 98.173.65.159 pasted "Exception 'destroy' vtable function" (8 lines) at nopaste.snit.ch/17537
allison just pasted the specific one I'm looking at 18:36
so, you can get rid of the single line "mem_sys_free(core_struct);", but you have to keep the rest of the destroy vtable function
Coke allison: you indicated yesterday that the runloop problem I had was fixable. Any idea how? =-)
allison Coke: it involves tracking down where that particular piece of code is being invoked, and why it isn't switching to the right code segment 18:37
NotFound allison: mmm.. maybe I wasn't being as careful as I thinked 18:38
allison it was an exception handler?
18:38 joeri joined 18:41 bacek joined
allison NotFound: I think you need the "do nothing" vtable implementation in default.pmc too, so most PMCs will silently do nothing if they don't define 'destroy' instead of throwing an exception 18:43
18:43 ash_ joined, contingencyplan joined, hercynium joined
NotFound allison: yes, I think that can help to relax a bit the handling of the destroy flag. 18:44
allison NotFound: (a quick search shows every other destroy deleted was simply freeing the data struct, or else correctly kept the destruction of individual attributes) 18:45
l3t0 allison: i implemented the rand() dynop, but it modifies it's first argument instead of returning it, since all ops seemed to work that way. cotto helped me a bunch 18:47
NotFound allison: I'm fixing Exception now.
allison l3t0: yes, the parameter marked as OUT is the result 18:48
l3t0: great work 18:49
l3t0 allison: the trac ticket uses the "$N1 = rand $N0" syntax, so I wanted to ask
allison l3t0: the opcode "rand N1, N0" translates to $N1 = $N0" in PIR 18:50
"$N1 = rand $N0"
l3t0: it's just syntactic sugar in the PIR parser, not real assignment
l3t0 allison: thanks, good to know. i will have to test that then. I wrote tests in PIR but I used the "modifying argument" calling convention 18:52
dalek rrot: r40526 | NotFound++ | branches/auto_attrs/src/pmc/exception.pmc:
restoring destroy on Exception PMC, allison++
 18:55
l3t0 allison: is trac.parrot.org/parrot/ticket/871 closable? I didn't implement srand, is that desirable ?
18:57 payload joined
l3t0 allison: I see that there is a Parrot_srand and a _srand48 in utils.c, so it should be trivial 18:57
Coke l3t0: (srand) yes please.
l3t0 Coke: ye shall get it then
allison l3t0: I was going to say "only if someone needs it", so there's your answer :)
l3t0 i think I didn't add srand last night because I couldn't immediately think of how to test it :) 18:58
Coke hurls www.tcl.tk/man/tcl8.5/TclCmd/mathfunc.htm#M33
l3t0: by setting the seed, getting a number, setting the seed to something else, getting a number, then setting it to the original seed and verifying that 1&3 are the same #. 18:59
(need) www.tcl.tk/man/tcl8.5/TclCmd/mathfunc.htm#M33
tcl defines the seed as being per-interpreter. I wonder if Parrot_srand supports that. 19:00
19:00 MoC joined
cotto hello 19:01
allison NotFound: is the attr_size struct element first or last in the generated struct? 19:09
19:09 iblechbot joined
NotFound allison: the last, after the vtable function pointers 19:10
Just in case someone is depending on the current layout
allison NotFound: makes sense 19:12
19:12 brooksbp joined
allison NotFound: the last thing I'd change deleting those unnecessary init vtable functions: ResizableIntegerArray, ResizableFloatArray, ResizableStringArray 19:14
NotFound allison: I'm looking at tha
t
allison NotFound: overall it's a good branch, happy to have it applied after the 1.5 release
NotFound Good :) 19:15
whiteknight Anybody else see the new patch on TT #549? Quite impressive 19:16
probably worth some serious discussion since it's a major change to the PMC structure
NotFound whiteknight: I took a quick look, looks good but maybe too much changes in one shot 19:17
whiteknight NotFound: yeah, I had that thought too. I'm thinking about creating a branch to test it out and put it through the paces
NotFound And I don't like the macro renaming 19:18
whiteknight well, that's just a preference thing. wouldn't take any effort to un-rename them
NotFound A prefix like 'Buffer' is too generic
19:18 payload joined
whiteknight We do have a data stucture called "Buffer" 19:18
NotFound Macros are much more prone to conflicts than struct names. 19:19
whiteknight true, but we should make a distinction if PMCs aren't any longer isomorphic with PObjs 19:20
so we shouldn't be using PObj_* macros on them
19:20 donaldh joined
NotFound Agreed 19:20
whiteknight either way, regardless of the cosmetic issues, it's a very good patch
NotFound Getting rid of the ext will be good. 19:21
19:24 eternaleye joined 19:42 eternaleye_ joined 19:45 AndyA joined
l3t0 cotto: re: rand in tcl, i am not sure if Parrot_rand is random or quasi-random, but we will find out. the parrot spec should clarify which is wanted, or perhaps have both, like rand() and qrand() 19:52
cotto l3t0, I remember looking into it and it's a prng. It doesn't get entropy from the underlying system. 19:53
We should have some part of the API for that. 19:54
l3t0 cotto: the comments in the source say that it will use system entropy when that is possible, which will make it into an RNG, not a PRNG . so yes, currently it is PRNG, but it should be clarified 19:55
cotto Hmm. I must have missed those comments. 19:56
Coke allison: did you see the recent article about folks trying to come up with a unified RobotOS so they didn't have to keep reinventing the wheel? 20:01
20:02 darbelo joined
l3t0 cotto: there is a comment in src/string/api.c that refers to trac.parrot.org/parrot/ticket/64 20:03
allison I did, it looked fascinating 20:04
(that was for Coke)
cotto I think that's my comment. 20:06
NotFound Coke: reinventing the jam? 20:12
20:17 eternaleye joined
dalek rrot: r40527 | allison++ | trunk/ports/fedora (2 files):
[fedora] 1.4 packaging files.
 20:18
rrot: r40528 | NotFound++ | branches/auto_attrs/src/pmc (3 files):
drop unneeded init functions in resizable arrays PMCs
ash_ do you guys mean the robotos.org project? for my senior design project we are doing a robotics project, we tried that but it was um.... not very good.... 20:21
chromatic CGP core now passes tests.... 20:42
21:02 payload joined
GeJ Good morning everyone 21:03
21:09 Whiteknight joined 21:14 japhb joined 21:20 joeri left 21:31 Psyche^ joined 21:32 allison joined
chromatic INCOMING! 21:34
purl well, incoming is pause.perl.org/incoming/
dalek rrot: r40529 | chromatic++ | branches/pluggable_runcore (20 files):
Refactored runcore handling to improve encapsulation.

their supporting accoutrements. Added Parrot_runcore_register() to register new runcores. Added Parrot_runcore_t parameter to all runcore functions. Moved runops functions to src/runcore/cores.c. Used runcore names in embedding functions. Added Parrot_runcore_switch() function to switch runcores. Changed Parrot_set_run_core() to use Parrot_runcore_switch(). Modified IMCC to use Parrot_set_run_core() and RUNCORE flags, rather than poking in runcores directly. Fixed PCC to switch runcores appropriately. Fixed run_sub() to use new runcore switching code. Fixed the runcore switch in Parrot_set_flag() to use Parrot_runcore_switch(). Fixed most of t/run/options.t to run with new runcore changes. In particular, the trace runcore no longer enables CGP and JIT, if you have them. Fixed coding standards violations. Reheaderized code. Made all runops functions static.		 21:37
jonathan wow! 21:40
chromatic++
szbalint chromatic++ # needs more karma for this one 21:41
whoppix is still looking through the diffs 21:42
Whiteknight that is quite the commit
chromatic All tests pass. 21:43
purl Time to write more tests!
Whiteknight chromatic: you see the patch for TT #549?
chromatic I read the description but I didn't read it yet. 21:44
Whiteknight it's a huge patch. I'll probably create a branch for it to give it some exercise 21:47
chromatic It'd be easier to review in separate chunks.
Yes, my irony detector works today. Stop looking at me that way.
Whiteknight yeah, separate chunks would be nice. It would take more effort to cleanly partition the patch at this point then we would save from just reviewing it wholesale 21:51
chromatic That depends how he made the patch. 21:52
Whiteknight I just assume he made it "the bad way" 21:53
21:53 mokurai joined
dalek rrot: r40530 | whiteknight++ | branches/pmc_sans_unionval:
creating a branch to test the huge patch from TT #549
 21:54
Whiteknight is there any good automated way to uninstall an installed Parrot, or do I have to go rooting around through my drive and delete it manually? 22:00
cotto Whiteknight, there's no uninstall. 22:01
Whiteknight yeah, I figured
darbelo If it's any help, the parrot istall stays inside of whatever '--prefix' you gave to Configure.pl (defaults to /usr/local IIRC) 22:02
dalek rrot: r40531 | whiteknight++ | branches/pmc_sans_unionval (30 files):
[pmc_sans_unionval] apply the patch from jessvdam++ in TT #549. Does not build.
 22:08
cotto chromatic, the profiling runcore isn't active with the -p flag after that commit. 22:09
s/active/activated/
22:10 mokurai joined
chromatic That should be easy to fix. 22:13
Nothing registers a profiling core, yet.
cotto any gotchas I should watch out for? 22:19
chromatic You should be able to copy the behavior of the slow core and switch your function pointers appropriately. 22:20
I left a couple of places for custom behavior. 22:21
You can define your own struct, as long as the first elements are isomorphic. If you need to store additional data for profiling, extend Parrot_runcore_t.
If you need to do once-per-profile initialization, you can swap the function pointer in the profiling runcore after you've done initial setup.
Start by setting the runops function pointer to something like initialize_profiling_runcore. In that function, do your initialization (open filehandles, etc), then swap that pointer to runops_profiling_core (but don't forget to tailcall that function). 22:23
If you have trouble, let me know.
I need to write docs.
I think it should be a lot cleaner and more approachable now though. 22:24
cotto It doesn't look bad from where I'm sitting.
Nice work. 22:25
chromatic More work than I thought.
Still a couple of grotty parts related to PIC and prederefs, but it's cleaner. 22:26
cotto It'll be nice to to separate out the initialization and finalization. 22:29
chromatic That was one of my primary goals, especially for the profiling and debugging cores.
Whiteknight PIC is still supposed to be coming out anyway, right? 22:33
chromatic cotto, www.mail-archive.com/enlightenment-...19458.html
If anyone can figure out how to remove it, yes.
treed Do any languages on Parrot do public/protected/private methods yet? 22:34
cotto chromatic, I suspected there'd be something like that. I think the best solution is to add an abstraction layer around the timing code so that we don't need #ifdefs to use windows performance counters. 22:35
but that can wait for now
moritz I'm not seeing any content on www.oreillynet.com/onlamp/blog/2005..._perl.html - should I?
chromatic moritz, blogs.sun.com/alanbur/entry/dtrace_and_perl 22:36
cotto Thanks for finding that.
22:37 kid51 joined
chromatic GeJ found it. 22:37
cotto GeJ++ 22:38
22:38 rg joined
cotto chromatic, is there an option to make Parrot say which runcores are available? 22:39
chromatic Not currently. 22:40
We could walk through interp->runcores and print each ->name though.
cotto yeah. It'd be pretty easy now. 22:42
GeJ running make smoke on pluggable_runcore. 22:43
I fixed the build based on the enlightenement patch.
Will see how it goes.
cotto chromatic, I also thought that the runcore init function would be enough to make "./parrot --runcore profiling" work. Is there any reason (other than expediency) that it doesn't? 22:45
nopaste "GeJ" at 202.171.79.162 pasted "WORKSFORME: Fix the build for pluggable_runcore branch on FreeBSD 7.x i386" (32 lines) at nopaste.snit.ch/17545
dalek cnum-dynpmcs: r167 | darbelo++ | trunk/cfg/src/pmc/Makefile.in:
[Makefile] Remove nonexistent items from the (pmc) clean target
 22:46
chromatic cotto, you also have to add a line in the appropriate place in compilers/imcc/main.c for now.
cotto yup.
just found it 22:47
GeJ Full disclosure : I don't know C. So there maybe a better way. `make smoke` ran fine. see report_details/26130
running `make fulltest` now. 22:48
cotto GeJ, I think the patch is fine for now. I'd like to abstract the idea of "get high-resolution timing information", but that can wait. 22:50
22:50 bacek joined
GeJ cotto: I'll trust your judgement on the quality of the patch better that I could ever trust mine. :) 22:52
cotto The profiling runcore is working again. 22:53
dalek rrot: r40532 | cotto++ | branches/pluggable_runcore (7 files):
[profiling] make the profiling runcore work with the new interface

first attempt to make calls and returns explicit in the profile		 23:02
purl dalek: that doesn't look right
cotto GeJ, your changes are in the next commit. 23:04
GeJ thank you.
dalek rrot: r40533 | cotto++ | branches/pluggable_runcore/src/runcore/cores.c:
[profiling] add modified patch from GeJ++ to make clock_gettime more portable across POSIXy platforms
 23:06
GeJ cotto++ 23:09
chromatic++
cotto GeJ, do you test all branches or is that one of particular interest to you? 23:13
chromatic, did you test that ->destroy gets called? 23:15
GeJ cotto: usually I stick to trunk, but chromatic's commit size made me curious and I gave it a run. 23:16
running `make fulltest` on branches/pluggable_runcore:r40533
seeing Whiteknight's last commit, I will probably try it too. 23:18
cotto GeJ, you mean the one in a branch that doesn't build? 23:19
GeJ Well, you just saved me some CPU cycles. :)
23:20 donaldh joined
chromatic cotto, I didn't specifically. I'm pretty sure that it does, but I didn't run Valgrind yet. 23:25
cotto also, where'd be the best place to put a custom Parrot_runcore_t-list struct? 23:26
chromatic -list? 23:27
cotto -like 23:28
strange typo
chromatic If it's built into Parrot itself, include/parrot/runcore_api.h should suffice. 23:32
cotto ok
This is odd. Now neither the init nor the destroy functions are being called. 23:39
23:41 Limbic_Region joined
cotto This is especially odd because the init function fired several time when I first tried it. 23:45
GeJ cotto: make fulltest ran mostly fine... it croaked during the manifest_tests suite. but given that the branch is based on 1.3, I'm not too worried about it.
(that is for plugabble_runcore at r40533) 23:46
cotto yeah. It could use a merge from trunk now that chromatic's changes are committed.
GeJ this is the kind of time where I'm happy to not have a commit bit. :)
Best luck to the victi^Wvolunteer. 23:47
dalek rrot: r40534 | cotto++ | branches/pluggable_runcore (2 files):
[profiling] add stub init and destroy function for the profiling runcore, although they don't seem to get called atm
 23:49
23:52 quek joined
cotto chromatic, is the problem obvious to you? 23:53
chromatic Looking. 23:56
Nothing jumps out at me at the moment. 23:58
cotto Interesting. It's called when I run a moderately complex bit of code that uses PGE for pattern matching, but not for a hello world.
nopaste "cotto" at 74.61.2.46 pasted "moderately complex code to test profiling runcore" (91 lines) at nopaste.snit.ch/17546 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!