Parrot 1.1.0 Released | parrot.org/ | 308 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets
Set by moderator on 18 May 2009.
allison jonathan: mmmhmmm... that's what I'm working on 00:01
apparently, certain chunks of code actually depend on having the proxy created in *every* HLL 00:11
jonathan allison: Oh, hmm. 00:12
allison: In Rakudo, or elsewhere?
00:14 donaldh joined
allison I'm only looking at Parrot core, but it could explain Rakudo too, since the problem is with a Parrot core type used in the perl6 HLL 00:15
jonathan allison: Yes, that'd make sense. 00:16
Whiteknight what did mk_language_shell.pl get renamed to? 00:19
create_language.pl?
darbelo I think create_language.pl is a different script. 00:21
jonathan They're different; I think create_language.pl is the newer.
Whiteknight renamed, superceded, whatever. Which should I write about in the book? 00:22
jonathan Whiteknight: I *think* create_language.pl is the one that pm mentioned the last time I heard him talk on PCT. 00:24
(at NPW)
Whiteknight yeah, I think I heard it recently too 00:25
whatever, it's in the book now
whether it's true or not
purl whether it's true or not is irrelevant; what matters is if people believe it.
allison Whiteknight: mk_language_shell.pl still works 00:26
Whiteknight: create_language.pl is just different
s1n allison: i'm curious about pdd18, has there been any work on this (i'm fairly unfamiliar with parrot internals)? 00:28
jonathan OK, time for me to sleep...
allison: If you have a patch that works on the Parrot tests but still has Rakudo issues, let me know.
night 00:29
00:29 rob joined
allison jonathan: I don't have any way to test the Rakudo issues, but will let you know when it passes the Parrot tests 00:29
Whiteknight allison: So which one should I write about? Both? one or the other?
allison right now, mk_language_shell.pl, because it's more fully featured 00:30
Whiteknight done
allison we'll merge them together at some point
Infinoid Oh, and docs/parrothist.pod has a 4th date format (2009-May-19)
allison s1n: the security PDD is not yet implemented, only specified 00:31
rob any idea why a socket stored in a lexical wont close?
00:32 bacek joined
s1n allison: is there any plan to implement it? i'm interested in this feature; i will be attending the workshop in hopes of learning more about parrot :) 00:32
rob neither sock.close() or close sock work 00:33
allison s1n: yes, there's a plan to implement it, sometime in the next year 00:34
Infinoid All right. So how's everyone's "fulltest" looking? Anything we need to skip? 00:43
dalek rcupinepascal: r75 | robin.ge++ | branches/oo-branch/ (3 files):
* added halt builtin
 00:44
00:54 eternaleye joined
Infinoid gah, I can't pass fulltest on my machine because of TT #578 00:55
Infinoid tries to hack his machine into a usable state 00:56
allison Infinoid: I'm running it on 3 platforms now 00:57
Infinoid restarts it on gentoo/amd64 with a symlinked libpcre.so in place
Whiteknight Infinoid: Except the t/examples/* failures, everything works fine here 01:09
Infinoid Thanks. That's ubuntu/x86-64? 01:10
Whiteknight yes
Ubuntu 9.04 specifically
Infinoid Ubuntu tends to be a little pickier than gentoo, so that means I'll probably be fine here too. Awesome.
Whiteknight viva la bleeding edge
dalek rrot: r38949 | whiteknight++ | trunk/docs/book/ch04_compiler_tools.pod:
[book] big overhaul of chapter 4. Rewrite a lot of stuff for flow and clarity. Add an entire section about HLLCompiler and it's uses.
Whiteknight and with that edit, I think I'm out for the night. Ladies, Gentlemen, I bid thee adieu. 01:15
01:23 cognominal joined
allison Infinoid: on ubuntu/x86-32, I get a failure in t/op/trans.t under testj 01:31
Infinoid Okay. Thanks, I wouldn't have seen that as jit is disabled under my platform 01:33
Which test?
purl rumour has it Which test is for that bit of sugar
cotto no, which test is <reply> 01:34
purl okay, cotto.
allison t/op/trans_13.pasm 01:38
apparently something to do with atan, or floating point equality
it's atan, it keeps returning NaN 01:40
01:40 tewk joined
cotto Haven't we solved that problem already? 01:40
I know there's a tt and I'm mostly certain there's a patch. 01:41
allison maybe so
Infinoid What's the TT? I can put it in the TODO message 01:42
allison TT #530
Infinoid Is testj valid anywhere other than linux/x86? (Do I need to test for linuxness or x86ness, or is jit sufficient?) 01:45
allison jit should be disabled on x86-64
but, I can test 01:46
do you have a todo patch?
Infinoid it is disabled by default on x86-64, yes
and yes, I've got a patch ready to commit
tewk I'm here, what is the current release status? I'm ready to work my way through release_manager_guide.pod
allison if you no paste it, I'll try it here
Infinoid hi tewk, I've kinda taken over the process, working through some fulltest issues right now 01:47
allison tewk: we're doing final cleanup of test failures
Infinoid But you can have the pumpkin back if you really want it. :)
tewk Infinoid: great, thanks, I don't want to butt in, you can run with it. If you need me to do anything let me know. 01:48
Infinoid ok, will do
allison Infinoid: if you commit the todo, I can just svn up and try it
Infinoid allison: r38951 01:49
01:49 Theory joined
dalek rrot: r38950 | Infinoid++ | trunk/docs/project/release_manager_guide.pod:
[docs] Update the release manager guide.

  * ftp.path is another field in release.json which should be updated.		 01:49
rrot: r38951 | Infinoid++ | trunk/t/op/trans.t:
[t] Todo the t/op/trans.t "atan2" test under JIT.
allison Infinoid: t/op/trans.t passes all tests under the jit runcore now 01:50
restarting 'make fulltest'
Infinoid great, thanks
I'm seeing the t/examples/namespace.t failure Whiteknight was talking about earlier
allison Infinoid: ah, I just saw that sweep by on my x86-64 box 01:51
which runcore?
purl well, which runcore is -r?
allison oh, looks like examples_tests
Infinoid other than that, everything looks fine here on linux/x86-64, the only thing I can't really test here is jit 01:52
allison looks like dump_multi is segfaulting 01:54
Infinoid Do you want to try to fix it, or should I just todo it for now? 01:55
Infinoid makes a note to un-todo these things after the release 01:56
allison Infinoid: try r38952. 02:02
dalek rrot: r38952 | allison++ | trunk/examples/namespace/namespace_dump.pir:
[cage] Make the dump smarter about handling multis without a signature.
 02:03
Infinoid Result: PASS
allison PMCNULL is a valid return value from get_multisig, so the dumper needs to handle it 02:05
Infinoid Makes sense. examples_tests and distro_tests are the last things on the fulltest list here, and they both pass, so I think fulltest will go smoothly this time 02:08
02:09 rhr joined
allison same on my OS X box 02:10
rerunning fulltest on it now (after updating namespace test) 02:11
t/op/io.t unexpectedly passes on x86-32 02:15
test 4
(which was recently added and todo'd, and does fail on x86-64) 02:16
Infinoid Is that on a particular runcore, or just in general? 02:17
allison Infinoid: it fails as expected in the default runcore 02:29
Infinoid: checking others 02:30
02:36 janus joined 02:37 particle joined 02:38 kid51 joined
allison Infinoid: seems to be pretty much any runcore 02:38
kid51 pokes his nose in and asks: Have we released yet? 02:40
Infinoid I'm guessing it's the "open pipe for writing" test?
hi kid51, fixing up the last few test failures now
allison Infinoid: 'make fulltest' passes on OS X 02:41
Infinoid kid51: got a passing todo test (on every runcore but the default) on linux/x86-32, so far the other platforms seem pretty good
allison Infinoid: yes, "open pipe for writing"
Infinoid allison: Thanks. that code looks alpha, to be honest. (Have you seen the implementation? Grep for "/bin/sh" to find it.) 02:42
Any objection to just skipping it?
allison Infinoid: skipping it is good
yes, it is a very early implementation 02:43
Infinoid Ok, I'll skip it. Is it the only failure you were seeing on the various runcores?
kid51 Infinoid: are you speaking about tests in general or about the ones I was reporting as part of 'make fulltest' last night? 02:44
Infinoid kid51: I think (and hope) we've fixed those up. More verification of that certainly couldn't hurt 02:45
kid51 489 / 60
purl 8.15
kid51 So the running time of t/benchmarks/benchmark.t has been cut in half on my Linux box. 02:46
Infinoid cotto++ reduced the loop counts to more reasonable values 02:47
dalek rrot: r38953 | Infinoid++ | trunk/t/op/io.t:
[t] Skip testing of opening pipes (executing shell commands) for now, it's alpha and fails inconsistently on various platforms.
 02:48
allison Infinoid: 'make fulltest' passes on x86-32 and x86-64 02:50
Infinoid great, thanks 02:51
kid51: I'm not sure if your t/compilers/imcc/syn/regressions.t issue (with -r) got resolved. Do you know if we found a fix, and/or can you retest it? 02:53
allison Infinoid: the passing TODO on x86-32 is gone too, thanks 02:54
kid51 Infinoid: Am currently running basic 'make test'. When that's done, I'll try that one. I believe we were down to the instance in make testf. 02:55
Infinoid Ok, thanks. I ended up being the release manager, so I'm hoping to make the shiniest parrot possible :) 02:56
02:57 tetragon joined
kid51 Smolder still down, I see. 02:59
Infinoid Yep. At least it's consistent 03:00
kid51 'make test' PASS on Linux/i386
nopaste "kid51" at 70.85.31.226 pasted "t/compilers/imcc/syn/regressions.t: all passing or TODO on various cores" (65 lines) at nopaste.snit.ch/16617 03:04
kid51 That was Linux/i386. 03:05
Infinoid Great, guess it's time to cut the release (unless I'm missing something) 03:06
kid51 t/examples/namespace.t: PASS on Linux/i386. So everything that was an outright FAIL on Linux last night is passing or has been TODOed.
Infinoid you shouldn't get any "TODO passed", either
allison Infinoid: thumbs up! 03:08
purl well, thumbs up is at www.friedmanarchives.com/China/Web/...%20dpi.jpg
kid51 make codetest PASS 03:10
Infinoid: No, on the tests specifically cited above, I got no unexpected passes (if that's what you meant). 03:11
dalek rrot: r38954 | Infinoid++ | trunk (10 files):
[release] Update the necessary bits for the 1.2.0 release.
Infinoid Great! Sounds about as polished as we can get it
kid51 On Darwin/PPC, 'make coretest' PASS (I don't have enough time to run 'make test' there; it's too slow) 03:13
On Darwin/PPC: t/pmc/nci (Wstat: 0 Tests: 70 Failed: 0)
TODO passed: 66, 69-70
... but those have been TODO pass-ing for some time (that JIT thing, IIRC)
Infinoid You had a failure in t/compilers/pge/pge_examples.t with -j on Darwin/PPC 03:14
kid51 (just when I thought I could sneak off to bed ...)
Still failing. 03:15
purl hmmm... failing is bad!
Infinoid You want to TODO it, or should I?
fulltest finally passed here 03:16
nopaste "kid51" at 24.188.182.149 pasted "make testj failure in t/compilers/pge/pge_examples.t persists on Darwin/PPC" (27 lines) at nopaste.snit.ch/16618
03:17 Andy joined
kid51 You should. I'm not fluent in PIR tests enough to do that quickly. 03:17
And I gotta get to bed. Had final Perl Seminar meeting of season tonight, followed by beer. You can figure ... 03:18
Infinoid I see you mentioned it in TT #479, I'll mention that in the TODO message
I've got it covered. thanks, sleep well
kid51 Yes, it is basically unchanged since #479. good night. 03:20
03:20 donaldh joined
dalek rrot: r38955 | Infinoid++ | trunk/t/compilers/pge/pge_examples.t:
[t] TODO pge_examples.t test #2 on Darwin.
 03:21
Infinoid cuts a tarball and tests it 03:22
allison Infinoid: we won't be able to upload until fperrad wakes up, he's the only one with access to the ftp server at the moment 03:23
Infinoid well, having 1 person with upload access is better than the situation last month :)
I'm guessing I should hold off on the announcement stuff until then?
allison you can get it all together 03:25
but, yeah, can't send out a link to it
what timezone are you in? 03:26
Infinoid I've already got it all together :)
Infinoid is in PST8PDT
allison ah, good, so it's some awful hour
it's *not* some awful hour 03:27
Infinoid yeah, it's all good. I'll send fperrad an email to (hopefully) make sure he lets me know when he wakes up 03:28
03:32 japhb_ joined
dalek rrot: r38956 | petdance++ | trunk/src/jit/amd64/jit_defs.c:
changing a 0 to NULL, and shimmed an interp
 03:38
rrot: r38957 | petdance++ | trunk/src/list.c:
removed unnecessary return value
 03:47
03:48 cotto joined
dalek rrot: r38958 | petdance++ | trunk/src/pmc/sub.pmc:
bunch of localizing and consting
 04:10
Infinoid I just noticed another thing about the t/op/io.t test we skipped: it left a lot of idle "parrot <path>/cat.pasm" processes running on my machine 04:19
dalek rrot: r38959 | Infinoid++ | tags/RELEASE_1_2_0:
tagged r38955 as release 1.2.0
 04:23
allison Infinoid: definitely not a good sign
Infinoid I have a tarball, now all I need is an fperrad to upload it 04:24
allison Infinoid: I've got the pile of idle processes too
Infinoid: excellent (on the tarball)
Infinoid: some of the lingering processes are as old as May 15th 04:26
04:26 Theory joined
Infinoid wow 04:27
I've never had to do a "killall parrot" before.
allison definitely want to leave that test as skipped 04:36
Infinoid Ok, I've sent fperrad an email ping and link to the tarball 04:38
particle allison++ Infinoid++ fperrad++ i hope
particle is bedward 04:39
bacek Infinoid++ allison++ 04:41
Infinoid Anyway, feel free to commit all your buggy stuff to trunk again, everyone
And your nonbuggy stuff too, of course :) 04:42
bacek Will do :)
dalek rrot: r38960 | petdance++ | trunk/src/pmc (3 files):
teeny consting
 04:46
rrot: r38961 | Infinoid++ | trunk/src/packfile.c:
[core] mark_1_seg: Marking constant PObjs can't hurt, make sure we do it for all the right types.
 04:47
rrot: r38962 | Infinoid++ | trunk/config/gen/config_pm.pm:
[config] Redo r38804, but whitelist some key items.
04:48 mikehh_ joined
dalek rrot: r38963 | petdance++ | trunk/src/pmc/callsignature.pmc:
consted on pointer, and localized a loop var
 04:50
rrot: r38964 | petdance++ | trunk/src/pmc (5 files):
lots of consting, and using NULL instead of 0 for pointers
Infinoid In TT #530, rg++'s patch solves the atan2 problem by forcing JIT to not use any CPU float registers. It looks like it got warnocked; it could really use some input by a JIT person. I TODOed the test earlier today because I wasn't sure whether the patch was the right solution or not. 04:53
dalek rrot: r38965 | bacek++ | trunk (11 files):
Merge branch 'tt504_annotations'
 04:57
rrot: r38966 | petdance++ | trunk/src/pmc/array.pmc:
consting and proper use of NULL
 05:00
rrot: r38967 | petdance++ | trunk (2 files):
Add a PARROT_IGNORABLE_RESULT for pmc_reuse
Infinoid bacek,cotto: So I'm told pmc_pct is the new hotness. Got a TODO list? 05:05
bacek Infinoid: yeah... sorta. Check TODO in compilers/pmcc :) 05:06
I'll write some todo tonight
Infinoid Thanks. The timestamp on that looked a little old 05:07
cotto well, it's definitely new
Infinoid I can work on item #4 tho
cotto cha-ching!
dalek rrot: r38968 | bacek++ | trunk/t/native_pbc (4 files):
Rebuild native PBCs
 05:20
kudo: 5e2e2c1 | pmichaud++ | src/ (3 files):
Add qx{}, qqx{}, q:x{}, qq:x{}.
 05:25
05:43 flh joined 05:56 eternaleye joined
Infinoid What's trac.parrot.org/parrot/wiki/Parrot...lAppliance all about? 05:57
dalek kudo: 33dd7ac | pmichaud++ | docs/ (2 files):
Some news and announcement updates in preparation for release.
 06:00
cotto I'd guess that it's a downloadable VM image that's got some sort of Parrot environment ready to run.
It looks shiny enough, but I'd rather help get the bird in better shape. ;) 06:01
Infinoid, how well do you understand actions (as in PCT actions.pm)? 06:02
dalek rrot: r38969 | allison++ | trunk/lib/Parrot/Docs/POD2HTML.pm:
[cage] Remove code that overly sanitizes C *'s. Thanks to mikehh.
06:06 japhb__ joined
Infinoid cotto: Not well. 06:10
dalek kudo: 0ce0f62 | pmichaud++ | docs/ChangeLog:
Update ChangeLog a bit.
 06:11
06:14 particle joined
pmichaud cotto: I know a bit about actions :-) 06:14
cotto Heh. I was just probing for where Infinoid might be able to dive into pmc_pct 06:18
pmichaud ah.
That's good, I'm probably not awake enough to answer any questions about it anyway. :-P
perl6: say 'hello'; # does this still work? 06:19
Guess not.
cotto rakudo: OUTPUT["hello"]
or something like that
pmichaud forgot the newline :-P
moritz should I send in p6eval here? 06:20
polyglotbot OUTPUT[helloā¤] 06:21
OUTPUT[Could not find non-existent sub OUTPUTā¤current instr.: '_block14' pc 58 (EVAL_16:40)ā¤called from Sub '!UNIT_START' pc 18229 (src/builtins/guts.pir:321)ā¤called from Sub 'parrot;PCT;HLLCompiler;eval' pc 950 (src/PCT/HLLCompiler.pir:527)ā¤called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc
..1275 (src/PCT/HLLCompiler.pir:688)ā¤called from Sub ...
pmichaud heh
*that* took a long time.
moritz wow
cotto I guess rakudo's really got some speed issues.
pmichaud well, that's also an old version of rakudo. 06:22
(see the backtrace output)
I'm fine with just having an evalbot in #perl6 -- was just curious if one was still here also. 06:23
06:23 chromatic joined
cotto perl6: say 'hi again'; 06:24
pmichaud Is the r38959 the official tagged release? 06:25
dalek rrot: r38970 | allison++ | trunk/docs/pdds/pdd24_events.pod:
[pdd] Update the events PDD to match the actual design and
pmichaud er, r38955, I guess. 06:26
polyglotbot OUTPUT[hi againā¤]
06:31 iblechbot joined
moritz ouch, the rakudo is the one from languages/perl6/, it seems 06:33
pmichaud back later # bedtime 06:34
Tene pmichaud: I can resurrect polyglotbot if you ask me to. 06:39
moritz asks Tene, in the hope that it will help even though he's not pmichaud ;-) 06:40
cotto Tene, can you do it if I ask? ;)
bacek waves to Tene 06:41
Tene Heh. 06:42
For you guys, I might make you do some of the work. :)
I'll try to get at least parrot and rakudo up. 06:43
Wait, feather3 is still dead, isn't it? 06:45
Ah, OK. I'll try to find another host. 06:46
cotto crud. nobody mentioned smolder's downtime at #ps
moritz Tene: no, it's up again 06:47
Tene: that's why polyglotbot is in the channel again...
it's just a *bit* outdated ;-)
Tene ah 06:49
moritz: the outdated part is rakudo... the build script is still trying to fetch it from svn.
moritz: I can give you access to feather3 to fix th ebuild script if you'd like. 06:50
I'm going to sleep soon. 06:51
moritz Tene: I already have access... I'll see if I can find tuits... 06:52
Tene moritz: I'm looking at it now... 06:53
06:55 HG` joined, HG` left, HG` joined
Tene installing git... 06:56
bringing svn up to date from the new repo... 07:08
falling asleep... 07:09
cotto wake up, Tene 07:13
Follow the white rabbit... 07:14
07:17 bsdz joined
bacek offer Tene two pills 07:30
mj41 Hi. r38965 (bacek) broke building "Parrot VM: PANIC: IJPS is an unknown signature type." tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk 07:37
moritz is that before or after the release?
bacek after 07:38
moritz good.
bacek And it require realclean for rebuild
And this machine exactly same as mine... Strange 07:40
Ah. x86_64...
dalek rrot: r38971 | bacek++ | trunk/src/pmc/packfileconstanttable.pmc:
[cage] Traling whitespaces
 07:44
mj41 TapTinder clients do "copy to temp" of not modified local copy every time. So no realcelan required. 07:45
bacek mj41: looking what happened... 07:48
mj41: I hope r38972 will fix it 07:51
dalek rrot: r38972 | bacek++ | trunk/config/gen/call_list/core.in:
Add more NCI signatures. Hope it will fix broken x86_64 builds.
 07:53
bacek Hooray. mj41++ 07:54
mj41 Hmm. TapTinder probably shouldn't run "mate test" if build failed :-). tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk seems odd. 07:57
07:59 donaldh joined
mj41 And some IRC robot to report build failures should be on my todo list. It will help continuous integration while I am sleeping. :-) 08:05
bacek mj41: indeed :) Can we have more boxes with different architectures? Like Darwin/PPC? 08:09
mj41 I think so. I only need to add it manualy to DB :-). tt.ro.vutbr.cz/table/machine and tt.ro.vutbr.cz/table/user But it wasn't tested on another OS. 08:14
And it is on your own risk. I will appreciate any help/interest. :-) 08:18
bacek mj41: can I build different branch on TT? Like tt458_reduce_mmd? 08:24
mj41 Yes and no. There is tt.ro.vutbr.cz/table/machine_job_conf 08:25
And tt.ro.vutbr.cz/table/jobp but it isn't tested yet. 08:26
bacek mj41: looks good. 08:28
purl O_O
bacek purl: forget looks good 08:29
purl bacek: I forgot looks good
bacek afk # going home 08:32
08:52 bacek joined 09:03 riffraff joined
bacek OH HI 09:27
Can someone some tt452_reduce_mmd branch? At r38973
(And run make benchmark_test on it) 09:28
dalek rrot: r38973 | bacek++ | branches/tt452_reduce_mmd/src/pmc/scalar.pmc:
[pmc] Use i_bitwise_shl_int in scalar on integer overflow.
kudo: 34823c9 | masak++ | docs/announce/2009-05:
[docs/announce/2009-05] nitpicked about my home

around. I tried to express this as succinctly-but-still-correct as possible in the announcement. Further edits are appreciated.		 09:46
09:50 flw joined 09:51 flw joined 09:53 flw joined
nopaste "bacek" at 114.73.51.181 pasted "Why --gc-debug is so slooooooow?" (18 lines) at nopaste.snit.ch/16619 09:54
09:55 flw joined
jonathan bacek: 'cus I think it does a gc run after every op. 09:56
bacek oh...
jonathan (so unmarked stuff gets swept as early as possible)
I think the idea is you crash closer to the source of the GC bug. 09:57
bacek We probably have to remove --gc-debug from benchmark_test
(make target)
afk # dinner time 10:02
dalek kudo: dcc0fdd | jnthn++ | build/PARROT_REVISION:
Bump PARROT_REVISION up to the revision of the Parrot release, so we're testing against the Parrot Thursday's release should run on.
 10:09
kudo: 6685755 | jnthn++ | docs/ChangeLog:
Few extras for the ChangeLog.
rrot: r38974 | bacek++ | branches/tt504_annotations:
Branch was merged into trunk. Removing from HEAD
 10:21
10:35 particle joined 10:59 particle joined 11:04 particle joined 11:10 particle joined 11:14 bacek joined 11:15 particle joined
Infinoid Good morning all 11:16
moritz oh hai
pancake morn
bacek OH HAI 11:17
jonathan morning
Infinoid hasn't heard back from fperrad about ftp site access 11:18
bacek wave from future 11:19
seen fperrad
purl fperrad was last seen on #parrot 13 days, 18 hours, 21 minutes and 57 seconds ago, saying: - or add the missing generated code [May 6 16:54:05 2009]
11:20 particle joined, donaldh joined
dalek rrot: r38975 | NotFound++ | trunk/src/list.c:
[cage] return in a void function
 11:21
11:25 particle joined
dalek rrot: r38976 | bacek++ | branches/tt452_reduce_mmd/src/pmc/bigint.pmc:
[pmc] Don't use MULTI for methods with single variant only.
 11:28
rrot: r38977 | bacek++ | branches/tt452_reduce_mmd/src/pmc/bigint.pmc:
[pmc] Rewrite BigInt.bitwise_shr without MULTIs.
rrot: r38978 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Remove useless MULTI Integer.i_add
 11:31
rrot: r38979 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Fix Integer.i_add on overflow.
11:34 burmas joined
bacek git svn dcommit is terribly slow... 11:34
dalek rrot: r38980 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Reimplement Integer.add without MULTIs
 11:35
11:35 particle joined
Infinoid runs it in the background on its own checkout, and ignores it 11:40
11:40 particle joined
bacek Infinoid: I need your opinion about trac.parrot.org/parrot/changeset/38980/ 11:43
bacek spotted few bugs in Integer.pmc. 11:44
Actually all i_foo(BigInt) are broken :/
Infinoid ok, I'm looking 11:45
11:45 particle joined
bacek Ouch... No single test for in-place math... 11:47
O! Found one. Complex.i_sub... 11:48
11:50 particle joined
Infinoid how are the i_* functions broken? 11:50
Infinoid gets a branch checkout and tests it
bacek Infinoid: change 500 back to 5000 in examples/benchmark/primes2.pir and test in branch and trunk :) 11:52
purl bacek: Either 'BACK' or '5000' is an invalid currency symbol, or Yahoo changed its screen format for the currency exchanger. Check finance.yahoo.com/currency for the list of supported symbols.
bacek Infinoid: (i_*) they don't update SELF for BigInt variants. 11:53
Infinoid hmm
11:55 particle joined
nopaste "bacek" at 114.73.51.181 pasted "Simple i_mul test case for Infinoid" (11 lines) at nopaste.snit.ch/16620 11:56
bacek i_add already fixed in branch
Infinoid ... wow, primes2.pir runs a *lot* faster in branch. Still waiting for trunk... 11:58
bacek 3 minutes vs 14 seconds on my box :) 11:59
11:59 ruoso joined
Infinoid hmm, your test pir file doesn't run correctly on trunk either 11:59
bacek Yes. 12:00
Infinoid - mul $P0, $P1
+ mul $P0, $P0, $P1
bacek It's not i_mul
12:00 particle joined
Infinoid or $P0 = mul $P0, $P1 :) 12:01
bacek And this one too. Check src/ops/math.ops 12:02
mul $P0, $P1 calls i_mul. It's different from 3-args mul 12:03
Infinoid ah, yes, different vtable
dalek kudo: 6229131 | jnthn++ | src/classes/Object.pir:
Fix typed array and hash attributes so that the type checking is enforced. Resolves RT#64594.
 12:04
Infinoid ok, I get it 12:05
12:05 particle joined
Infinoid Integer.i_multiply(BigInt) is busted 12:05
I would expect it to upgrade the pmc inplace, not just call the bigint vtable function directly (risking attr array mismatches) 12:06
Integer.i_multiply(Integer) seems to work fine
bacek It assumes that BigInt will call something like VTABLE_assign at the end. But it doesn't 12:08
Infinoid I was wondering if it expected BigInt to call pmc_reuse 12:09
(which would be insane)
I think it should upgrade SELF and re-call, like your i_add patch does
bacek "MULTI PMC *multiply(String value, PMC *dest)" is ... perfect... 12:10
12:10 particle joined
bacek Various checks like "if ((double)c == cf)"... It's insane. 12:12
bacek cursing day when he decided to start pmc_pct branch!
Infinoid: I'm going to reimplement all maths in Integer using "i_add" style. 12:13
Infinoid it's checking for overflows, but not in a very readable way 12:14
12:15 particle joined
Infinoid I think the strategy is good (don't upgrade to bigint until you have to), even if the implementation isn't very easy to read 12:15
bacek Erm. I don't afaiu 12:18
12:20 Whiteknight joined, particle joined
Infinoid no, you don't. I was talking about the multiply() method 12:22
Whiteknight Did the release make it out last night?
Infinoid Whiteknight: I have a tarball, but apparently only fperrad has access to the FTP site
bacek Infinoid: ah. ok
Infinoid bacek: One issue I can see with r38980 is that add() won't detect overflows and upgrade to BigInt 12:23
or am I missing something? 12:24
bacek missing
i_add will call i_add_int. i_add_int with do all checks
12:25 particle joined
Infinoid oh, cool 12:25
12:26 kid51 joined
kid51 msg Infinoid I'll try to ping you tonight re TT #690 12:26
purl Message for infinoid stored.
dalek rrot: r38981 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Refactor Integer.(i_)?subtract without MULTIs.
 12:27
rrot: r38982 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Rework Integer.(i_)?multiply without MULTIs
12:29 iblechbot joined
Infinoid bacek: this all looks good to me, less duplicated code and will run faster too 12:34
bacek Infinoid: indeed. 12:35
Infinoid I never really understood Complex numbers. It looks like Integer.i_add(Complex) will add the "real" numbers but the newly upgraded return value will have a 0 "complex" component? 12:37
(though your changes don't affect that) 12:38
bacek yak... t/pmc/multidispatch failed.
Failed test '1+1=3'
Infinoid heh
bacek I prefer to think that test conflicting with TT#452 12:39
because it overrides Integer.add
Infinoid great, another "pir subclass" issue 12:40
bacek It's not "subclass" issue..
check line 60
12:40 rg1 joined
Infinoid yeah, I'm reading it 12:41
bacek 452 exactly about avoiding mmd for core pmcs.
Infinoid right. 12:42
12:44 Theory joined 12:45 fperrad joined
Infinoid after looking at this test, it seems like MMD has some "spooky action at a distance" 12:45
Okay. If the goal is to make core PMCs fast, then this test is wrong. If we *do* want to override stuff in that way (or if it breaks subclassing in some other way), perhaps we can make an IntegerSubclassable PMC which works slower but is more compatible 12:46
fperrad: Hi! Did you get my email? 12:48
bacek: I think we need some input from the parrot designers on this particular case... I don't know how much the HLLs rely on the current behavior 12:50
allison: ping
bacek Infinoid: heh. I cheated. 12:51
fperrad yes, but currently I can't upload the tarball. I travel with only a netbook. I haven't my dev box with ssh keys. 12:52
Infinoid Ok, thanks. Should I wait, or is there someone at osuosl I should talk to?
fperrad Infinoid, have you seen the jerry gay's mail about ssh keys need ? 12:53
dalek rrot: r38983 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Invoke Complex.i_foo instead of handcrafted code in Integer.pmc
 12:54
rrot: r38984 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Cheat - register default MULTI for Integer.add
bacek Infinoid: Look! r38984 :) It still fast. And t/pmc/mutlidispatch.t is happy
Infinoid bacek++ 12:55
One of these days, I really need to understand exactly what that MULTI keyword does.
fperrad: No. Is it recent?
Whiteknight how does a person get an SSH key? 12:56
Whiteknight is an encryption n00b
Infinoid It's typically generated locally with the ssh-keygen command
Then you send the public key to the server, and tell it to authenticate anyone who has your secret key (which should be only you)
the pubkey is just a line of base64-encoded text. If you stick that in your .ssh/authorized_keys file on a server, you don't have to type your password in any more 12:57
which is awesome.
fperrad Infinoid, i send to you a copy of email 12:59
Infinoid thanks!
bacek Don't forget passphrase and ssh-agent
fperrad Infinoid, you must wait few hours, be 13:00
13:01 Coke joined
Coke msg pmichaud trac.parrot.org/parrot/ticket/691 will be of interest to you. :| 13:01
purl Message for pmichaud stored.
fperrad Infinoid, you must wait few hours, because osuosl support works in Pacific timezone
Coke Infinoid: thanks for doing the release. did we lose tewk? 13:02
Infinoid fperrad: I'm in the Pacific timezone too :) But yeah, it's only 6am here
Coke Infinoid: you didn't fix the test with --run-pbc
Infinoid Coke: he's around, but seemed happy to hand it off
Coke (oh, nevermind.)
Infinoid: I had worked that patch before you fixed it, and committed it after. 13:03
the --run-pbc version turned out to still be needed.
Coke finds yet another reason why I can't build partcl.
Infinoid sorry, what did I miss? 13:05
dalek rtcl: r346 | coke++ | wiki/ParrotIssues.wiki:
Edited wiki page through web user interface.
 13:06
Coke issue #691
ooh. and if I ignore that and just run the PBC directly, I get another.
nopaste "Coke" at 72.228.52.192 pasted "Whee." (6 lines) at nopaste.snit.ch/16621 13:07
Coke That'll be yet another one once I whittle it down to a simple test case without partcl.
Infinoid ok, so it's trying to load the wrong path 13:08
Should /usr/local/runtime/parrot/include/config.fpmc be /usr/local/lib/parrot/1.2.0/include/config.fpmc, or did we install it to the wrong place?
Coke Infinoid: I don't know what the right answer is, only that the way it is now is wrong. =-) 13:09
AHA. 13:10
for the other issue, it's that we don't install Tcl/Glob.pbc
13:10 particle joined
Coke we only install Tcl/Glob.pir 13:10
Infinoid oh! there were a few of those changes recently 13:11
I think we really need to do a fake installation as part of "make test".
Coke $ parrot tcl.pbc
Unable to open filehandle from path '/home/infinoid/parrot-1.2.0/languages/tcl/library/init.tcl'
... And we're attracting language developers how? =-)
13:12 gryphon joined
Infinoid heh 13:12
Coke I would say "make fulltest", but yes, we need to test it.
13:15 particle joined
dalek rtcl: r347 | coke++ | trunk/runtime/tcllib.pir:
parrot doesn't install the PBC of this library;
 13:16
Infinoid So for the config.fpmc issue, the installed path looks right according to PDD30, so I'd say the expected path is wrong 13:18
13:20 particle joined
Coke is that "should be installed in the 1.2.x dir and should be looking there too" ? 13:20
pmichaud coke: (TT #691) -- is that just saying that pbc_to_exe doesn't work for an installed parrot?
Coke pmichaud: that's the upshot, yes. 13:21
is there already a ticket for that? =-)
pmichaud but it still works for the build tree?
Coke I don't have the build tree.
I mean, if 'make test' works, it probably works.
pmichaud Oh. We still don't (even attempt to) build Rakudo from installed parrot, so it doesn't affect rakudo much yet :-)
Coke just another reason why you can't build from an installed. =-) 13:22
pmichaud Correct.
Coke I am finally at the point where I can build tcl.pbc and run it... before it dies trying to find something in the build directory at runtime.
(but only on linux, one of the more permissive platforms. =-)
Infinoid The file '/home/infinoid/parrot-1.2.0/languages/tcl/library/init.tcl' doesn't exist, so it seems irrelevant whether it's looking for an installed or build-local copy of it 13:25
13:25 particle joined
Infinoid The tarball is in my homedir, if you want to test against that 13:25
but I'm not really sure how else I can help to fix it
Coke Infinoid: that file is in MY directory. 13:28
why a file open would magically try to look starting in the build dir... 13:29
... unless I have it set to check the build dir for something. I'll double check.
13:30 particle joined 13:36 davidfetter joined
Coke yah, the "languages/tcl" should have been a clue. 13:38
Infinoid Does partcl still expect to be unpacked in its old subdir of the parrot tree?
ack reports almost 70 references to languages/tcl/... 13:39
Coke Infinoid: given that this is the closest I've ever gotten to even /building/ partcl outside of the tree, very likely. =-) 13:40
Infinoid :)
Coke there. $ parrot tcl.pbc -e "puts {hello world}" 13:41
hello world
so, that's something.
Infinoid cool
dalek rtcl: r348 | coke++ | trunk/runtime/tcllib.pir:
Don't try to find files in the BUILD directory of parrot.
 13:42
Coke I can see why OS X has languished, since linux mostly works. 13:44
guess I should have tried on feather earlier. 13:46
dalek rtcl: r349 | coke++ | trunk/config/makefiles/root.in:
don't try to build tclsh anymore
 13:47
Coke next step would be to run 'make test', which is a task for another time.
13:48 Jimmy joined
Coke Infinoid: thanks for doing the install on feather. Most progress I've made on partcl since 0.9 13:48
Infinoid No problem. Sorry for forgetting about install-dev 13:51
(since parrot is very much a developer tool, it always seems a bit strange that there'd be a distinction)
Jimmy good evening 13:58
Infinoid hi Jimmy 13:59
Jimmy hello Infinoid
bacek Infinoid: my cheat doesn't work... 14:02
14:07 rakudohudson joined
dalek kudo: f62aa0f | jnthn++ | src/ (2 files):
Refactor our handling of attribute initializers. The RHS should become an anonymous method. This should get us in line with the spec, and resolves at least RT#65346.
 14:09
Coke Infinoid: I would have no problem killing "install-dev" and just installing everything. 14:10
that's what the macport bundle is going to do.
Infinoid cool.
I get the reason behind it; it's the same reason there's a jdk and a jre 14:11
but it seems like the kind of thing I wouldn't have added until 2.0 or so
so I keep forgetting it exists 14:12
Coke if only I had a working PDK. =-)
I am excited to get make test running again, if only I could skip $DAYJOB. :| 14:13
14:18 iblechbot joined
pmichaud If I'm in a non-parrot HLL, what's the proper way for me to create a new Integer PMC instance? 14:20
do I have to use: $P0 = get_root_namespace ['parrot';'Integer'] followed by $P1 = new $P0 ? 14:21
dalek rrot: r38985 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Add more MMD registration stubs into Integer.
 14:24
rrot: r38986 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Rework Integer.divide methods without MULTIs.
rrot: r38987 | bacek++ | branches/tt452_reduce_mmd/src/pmc/integer.pmc:
[pmc] Integer.cmp and cmp_num are same.
14:27 masak joined
NotFound pmichaud: looks like a sane way to me. 14:31
pmichaud NotFound: there's a followup :-)
14:31 Theory joined
pmichaud If I have my own custom PMC (a dynpmc), how do I create a new instance of that? 14:31
do I have to use...
$P0 = get_root_namespace ['parrot';'MyDynPMC'] followed by $P1 = new $P0 ? 14:32
NotFound pmichaud: I suppose that it must work, but I don't know 14:33
pmichaud it just seems "very icky" that I'd have to do a namespace lookup every time I want to create an instance of my custom PMC 14:34
NotFound Qualifying PMC with an HLL still doesn't work, isn't it? 14:38
bacek pmichaud: new 'MyDynPMC' will look into current HLL first. (if I read sources correctly)
jonathan bacek: Yeah, but your dynpmcs don't live in the HLL. 14:39
bacek My dynpmcs died waiting for mmd to dispatch call to them :/ 14:40
Coke pmichaud: tcl always just did new 'Integer' 14:49
... but then, I didn't get an Integer, I got my HLL_Map'd version, no doubt. 14:50
oh wait, no, I got Integer. =-)
(that's not an autobox location)
pmichaud Coke: currently new 'Integer' does look in the parrot HLL, although according to allison++'s most recent post on the issue, afaict it shouldn't. 14:56
(where allison's most recent post is from January 2009)
"For class lookups 'newclass', 'subclass', 'get_class', and 'isa' all 14:57
accept a string name or a PMC. That PMC can currently be a Key, String,
ResizableStringArray, or NameSpace. If it's a namespace, the class is
directly extracted from the namespace. If it's one of the other three,
then it does a namespace lookup (HLL-relative) and extracts the class
from that namespace (if it exists).
bacek: I read the above as meaning "look only in the current HLL", not "look in the current HLL first" 14:58
(for those who want the reference: lists.parrot.org/pipermail/parrot-d...00863.html ) 14:59
Coke I'm sure that "what's intended to work" and "how to do it now" are not the same. =-) 15:02
NotFound But new is not newclass 15:05
pmichaud Correct, it's not. But I'd be a little surprised if it treated string/key/array class identifiers substantially differently from the other class-based opcodes. 15:15
15:17 Whiteknight joined 15:20 Andy joined
pmichaud message sent to parrot-dev, we'll see if we get any responses there. 15:20
purl Message for sent stored.
15:20 particle joined, donaldh joined
sent I have several messages X-) 15:21
Coke mmhehehe 15:27
NotFound Actually, if a namespace with the same name as the class does not exist, Parrot_oo_get_class_str uses pmc_type to find a pmc. 15:37
Whiteknight that whole system of looking up classes and proxies needs major overhaul 15:38
NotFound It does not search for the proxy, search the pmc and then create a proxy. 15:39
Whiteknight so it doesn't cache the proxies that it creates? 15:41
NotFound I suppose that if finds the proxy in the previous step, looking for the class in the hll namespace.
Looks like not. 15:47
allison NotFound: yes, I sent a patch to the list yesterday 15:51
I mean, to the channel
Whiteknight okay, that would be a good thing to cache those
allison nopaste.snit.ch/16616 15:52
it solves the problem of not finding the proxy
but, it also causes several test failures
NotFound To cache what? If it is not supposed to find it here, there is no point in cachin' it.
allison apparently from code that expects to have the proxies cached in every hll 15:53
Whiteknight: proxies are cached
NotFound allison: but we were commenting that lookup by string is not supposed to find things outside the current hll.
Whiteknight okay, that makes me feel better
allison Whiteknight: but they're cached in the namespace object attached to the C PMC 15:54
NotFound: it *shouldn't*, I agree
NotFound allison: the we shouldn't fix the wrong thing,.
allison NotFound: but it currently does, and we have code that depends on it working that way
NotFound I don't think we must work on optimizing wrong undesired code. 15:55
allison NotFound: yup, I started out trying to fix up my patch to match the old behavior, then scraped it and went to looking what needs to be modified in the wrong code
NotFound Much better :) 15:56
allison as far as I can tell, the namespace stored attached to the C PMC is the wrong namespace
Whiteknight wrong in what sense? 15:57
allison in the sense that it's not the same namespace found by the lookup
Whiteknight oh wow
15:58 Whiteknight joined
dalek kudo: 14bba5f | masak++ | docs/announce/2009-05:
[docs/announce/2009-05] added details about rakudobugs
 15:58
allison my patch adds a second lookup in whatever namespace is attached to the C PMC 15:59
NotFound BTW, extension C code that wants to be robust must always use a namespace pmc when looking for a class. Otherwise, it doesn't know what is the current HLL, and thus doesn't know where is the search by name or key being done. 16:05
16:09 baest joined
pmichaud allison: you saw my message sent to parrot-dev about proxies? 16:09
NotFound Someoon fixed TT #667 and forget to update the ticket? 16:10
allison pmichaud: aye, and I also saw your repost of my January suggestion for a better interface 16:11
pmichaud any quick answers?
16:12 jan joined
allison the quick answer is yes, it's looking in the current namespace, and only the current namespace, and that doesn't work for HLLs 16:12
in the current HLL
pmichaud same for custom dynpmcs? 16:13
i.e., we'd have to look up in the parrot namespace to use those?
(or otherwise do some funky namespace mapping)
NotFound What's the problem in fixing the HLL PMC declaration? 16:14
allison pmichaud: mmm... yes, it should currently be storing dynpmcs also in the 'parrot' namespace
pmichaud allison: it currently is doing that... I'm more interested in whether it should be doing so
allison because we don't have any way to declare an hll namepsace in the C PMCs 16:15
pmichaud seems like per-HLL dynpmcs ought to go into the HLL given by their 'hll' attribute
NotFound Or is just that no one tried?
pmichaud we don't?
currently Perl6Str is declared with "hll Perl6" although that appears to be (silently) ignored
allison pmichaud: they ought to, but AFAIK, they don't currently
NotFound ETOOMUCHSILENTLYIGNORES 16:16
pmichaud okay. I am asking for both "what they do now" and "what they ought to do"
(for planning purposes)
Coke back in the day, you couldn't create a PMC except in root anyway.
pmichaud it's okay if they currently go in 'parrot', I just need to be able to adjust to it.
NotFound Coke: Back in may 2009?
allison looking to see if pmc2c even does anything with the hll attribute
Coke NotFound: "back in the day" == "very long ago." 16:17
back when the .HLL was added.
allison pmichaud: what should happen is every C PMC should live in an HLL appropriate to its language
NotFound Ah, root. Well, change that to 'parrot'
allison root and parrot are equal
(root is just an alias to the parrot HLL) 16:18
pmichaud It looks like PMCEmitter.pm uses the 'hll' attribute simply for setting up a type mapping.
i.e., along with the 'maps' attribute.
allison so, it needs to be used to to also initialize the _namespace attached to the C PMC's vtable 16:19
pmichaud That seems reasonable.
allison is "Perl6" the name of the HLL or 'perl6'?
pmichaud we're currently using 'perl6' as the name of the HLL. 16:20
The "Perl6" that Perl6Str uses is more historic (and apparently didn't do anything useful anyway)
allison okay, then can change to be consistent?
pmichaud sure.
NotFound Are HLL names converted to lower case? 16:21
pmichaud Anyway, Rakudo's short-to-medium term workaround for all of this: introduce a "new_parrot" dynop that makes it easy to build PMC instances that are actually in the parrot HLL 16:22
allison NotFound: an HLL can pick its case, but it has to be consistent (we're not doing case conversions internally)
NotFound Looks like the HLL namespace has the name of the HLL converted to lower case.
allison pmichaud: if you name it new_hll and let it take a string parameter for the name of the HLL, we can make it core instead 16:23
nopaste "NotFound" at 213.96.228.50 pasted "HLL namespace silly tests" (57 lines) at nopaste.snit.ch/16622 16:24
allison pmichaud: mainly, I would like to implement that Hash argument to get_class
pmichaud $P0 = new_hll 'parrot', 'Integer' # like this? 16:25
allison pmichaud: aye
pmichaud I wasn't going to worry about the keyed case
$P0 = new_hll 'parrot', ['Integer'] # not this
if we want to add the keyed case, I suppose we could do that. 16:26
...what's the Hash argument to get_class ?
allison if it's just the plain string case, then it can be 'new'
the message you reposted earlier
where you can specify 'hll', 'namespace', and 'name'
as hash keys
and pass that in in place of ['Integer'] 16:27
pmichaud class creation isn't currently an issue for me.
so I'm not really pointing to that.
allison when you call 'new' for a low level type, it's calling get_class
pmichaud sure, but get_class isn't class creation.
allison right, I'm talking about the Hash interface for lookups
pmichaud okay, I'm confused. 16:28
allison as in $P0 = new hash_lookup_arg
pmichaud okay, I'm less confused.
Doing the hash lookup for 'new' would generally be even more work (and costly) than simply using get_root_namespace 16:29
allison how so?
pmichaud because I'd need to build the Hash, for one.
allison and the other case is... maybe two calls 16:30
about the same
pmichaud building the hash is definitely more expensive than looking up a namespace 16:31
allison if we can hide it behind an op interface, I don't care what order it does the lookup, since we can always change it later
NotFound The HLL namespace conversion to lower case is a bug, then?
allison NotFound: yes, legacy code
NotFound Can we fix it, or need a deprecation cycle?
allison NotFound: would need a deprecation, since it would break some existing languages 16:32
pmichaud anyway, for the various tools and languages I'm working with, the ability to use a hash for class lookups doesn't seem all that beneficial/helpful 16:33
allison pmichaud: for the immediate answer, let's just add variants to 'new' that take an initial string argument for HLL
NotFound Urgh. Can we do some in the meantime, like storing an alias?
pmichaud allison: there might be a collision there 16:34
jonathan allison: We already do too much stuff with strings for lookups. :-(
allison when we get it, we can know to perform the lookups in the named HLL instead of the current hll
jonathan: HLL names are just strings
pmichaud jonathan: oh, I'm not too concerned with using strings for HLL names
but we already have a new_p_s_p variant
allison this would be new_s_p 16:35
pmichaud so we might end up with a collision on $P0 = new 'parrot', ['Integer']
allison or new_s_p_s_p
oh, no, the initial p is the return
pmichaud there's already a new_p_s_p
NotFound P = new S, S Isn't it?
allison new_p_s_p woul be $P0 = new 'stringname', init_hash
pmichaud right. 16:36
so you're saying new_p_s_s (and _only_ that)
$P0 = new 'parrot', 'Integer' # okay
$P0 = new 'parrot', ['Integer'] # not what you expect.
allison if we add the hash interface, then we can say the hll has to be specified in the init hash if you pass one
I mean, we can take the step of new_hll just like we have get_hll_namespace 16:37
16:37 davidfetter joined
pmichaud I'm comfortable with new_hll. 16:38
allison alternatively, we could finally take the plunge and require all names to be at least keys
pmichaud I also don't have an issue with requiring names to be keys, but that seems orthogonal to the issue we're currently having.
allison it is 16:39
and swapping out one syntax for something that looks the same but behaves differently is confusing
so, new_hll it is
oh, that should be hll_new, I suppose, so people don't think they're creating an HLL like new_class
pmichaud hll_new ++ 16:40
NotFound BTW, there are still some :: class and namespace separators in the code base. Can we kill them all?
Coke you can't start making ops named consistently NOW. it's unseemly.
pmichaud if we think we're going to require names to be keys, perhaps we should only have hll_new_p_s_p ?
and not hll_new_p_s_s ?
allison NotFound: yes, they can be replaced by ; or separated into keys
Coke NotFound: they were supposed to be killed some time ago. if they're in a stdlib, has to wait to 1.4+
allison pmichaud: +1 16:41
purl 1
allison pmichaud: no need to implement the old
NotFound Coke: I was supposing the same, until last week, were I fixed a lot ot them.
pmichaud and should it be "hllnew" instead of "hll_new"?
Coke NotFound: in trunk?
NotFound Coke: yes
Coke GAH
allison pmichaud: we tend to separate words with spaces in ops, at least in the newer ops 16:42
(with underscores)
NotFound When getting rid of the 'library/' prfixes in load_bytecode
pmichaud allison: fair enough.
Coke NotFound: I thought you were just getting rid of library/ not changing the API.
pmichaud okay, so we'll add hll_new_p_s_p
Coke and now it's in a release. whee.
allison and, we may end up with a collection of hll_* ops
also hll_new_p_s_p_p 16:43
NotFound Coke: that was the intention, but lots of things failed if not fixed.
pmichaud the only one that occurs with any frequency that I've encountered is the need for 'new'
allison (with init hash)
yes, but we shouldn't make it impossibly difficult to pass an init hash
pmichaud get_class, isa, etc. can all work equally well with namespaces, and are rare enough that I'm not sure they deserve custom opcodes
Coke allison: do we have yet a policy on how to document breaking our support policy?
(we'll probably need to do that for 1.4 now.) 16:44
pmichaud my "only one that occurs with any frequency" was directed at your "we may end up with a collection of hll_* ops"
allison pmichaud: ah, yes, I wouldn't add hll variants for those
pmichaud not at the "init hash" one.
Tene i've seen some issues with that 'library/' path prefix...
allison right
(the lovely asynchronous nature of IRC)
pmichaud yes, hll_new_p_s_p_p
no problem. Rakudo will use those.
allison so will Pynie
Tene for example, .include 'dumper.pir' @ no such file or directory 16:45
Coke is the 's' there for the name of the hll?
NotFound Coke: we have test that must be change if you change a single char in the code. That way is impossible to use the test suite to verify that we are not breaking anything.
pmichaud jonathan: think it's worth trying to fix Rakudo to get the speed improvement for the release, or should we just let the release be slow and then convert Rakudo to the new opcode?
Tene .include 'library/dumper.pir' # works
pmichaud Coke: yes.
$P0 = hll_new 'parrot', ['Integer']
and
$P0 = hll_new 'parrot', ['AClass'], init_hash
Tene so something broken with the search path if that doesn't work.
jonathan pmichaud: Write the op as a dynop. Ship it. Then after the release, copy paste it into var.ops and remove it from Rakudo and bump us to the latest revision.
Coke NotFound: that's certainly a stupid test, yes.
pmichaud jonathan: yes, I was thinking of that possibility also. 16:46
allison jonathan: no, I want it as a core op
pmichaud allison: we'll dynop it only until we can move it into Parrot.
jonathan allison: plz re-read :-)
Coke but it sounds like you changed something like Data::Dumper to ['Data';'Dumper']. No?
allison oh, I see, for the immediate Rakudo release
yes
pmichaud Since 1.2 released yesterday, we can't rely on the dynop for Rakudo's release tomorrow.
jonathan :-)
NotFound Coke: yes, and all test passed like a charm
jonathan Right. And shipping a Rakudo that performs awfully kinda feels bad.
Not to mention that the op will look exactly the same in Rakudo as it would in Parrot, so it really should be a "just move it" job. 16:47
pmichaud Correct.
It's not a problem to do the move.
Coke NotFound: anyone using the library file will be broken when 1.4 is now shipped, though.
allison hmmm... adding the op won't fix Rakudo
pmichaud I think it will.
allison at least, not the PMC proxy lookup problem
pmichaud I think it will.
Coke if they're trying to load 'Data::Dumper' and not ['Data';'Dumper'] ...
allison well, if you implement it to completely avoid get_class for the moment, it can work around the problem 16:48
pmichaud I think the fundamental issue with the PMC proxy lookup problem is that every call to 'new' is generating a new Proxy PMC
(because 'new' does a 'get_class')
Coke I would love to see this discussion sumarized on list for discussion before the op is added. =-)
allison a Proxy is supposed to be generated for every C PMC that's used
NotFound Coke: all usages I've seen used dumper, not Data;Dumper 16:49
pmichaud and there are a lot of places where Rakudo does things like $P0 = new ['ResizablePMCArray']
allison the problem is that it's not finding the cached PMCProxies
pmichaud or even
$P0 = new ['Perl6Scalar']
as a result, every one of those calls to 'new' is generating a new PMCProxy
and not looking up the correct one in the parrot namespace
but if we switch those to be
16:49 gryphon joined
Coke NotFound: even if we're not testing it, that still smells like an API change to me. 16:49
allison right, they should be generating one proxy, and reusing it
pmichaud $P0 = hll_new 'parrot', ['Perl6Scalar'] 16:50
NotFound Coke: my aplogies, then,.
Coke Just like if we renamed a C function that we weren't calling directly from the tests.
pmichaud then the dynop is going to look it up in the correct place
and no additional PMCProxy will get created.
Tene allison: can you confirm that 'dumper.pir' is going to be the preferred path over 'library/dumper.pir'?
Coke NotFound: no one complained on the commits. What can you do.
Tene for load_bytecode?
pmichaud currently the places where we do "get_class" is because we didn't have a way to do hll_new
allison Tene: yes libraries should never prefix 'library/' to the path
dalek kudo: 01ec2a7 | jnthn++ | src/pmc/perl6multisub.pmc:
Fix up Perl6MultiSub to not let named paramters get in the way in various cases. Resolves two RT tickets. Also name a magic value and a little visual tweak.
 16:51
Coke We can use this as an opportunity to decide what the path should be if we ever /have/ to violate our support policy.
(or if we do it again by accident.)
allison pmichaud: for now just make it work
pmichaud allison: no problem. :-)
Tene allison: the former doesn't work.
NotFound BTW, the usage message of dumper.pir is about Data::Dumper, not about himself
Tene Wait, nm. i was using .include
allison pmichaud: once we fix get_class, then hll_new should be using the same "lookup Class/Proxy" code as new 16:52
Coke allison: is it intentionally that we're not installing, e.g. Tcl/Glob.pbc ?
s/ly//
nopaste "tene" at 166.70.38.237 pasted ".include path fail for allison++" (3 lines) at nopaste.snit.ch/16623
NotFound I also killed several wrong .include in the library
pmichaud allison: you're going to change get_class to always take a hll argument?
allison I'm talking about the C Parrot_oo_get_class 16:53
pmichaud right. All hll_new is going to do is to look up the correct hll namespace, and pass it to Parrot_oo_get_class
allison Coke: do you mean in Tcl?
NotFound afk_coke: uh, wait, looks like Data::Dumper was not between the things already changed
allison pmichaud: or even better, will just pass a string argument for hll name to get_class, which will do the hll lookup 16:54
pmichaud using string names for class identifiers is Evil.
allison (for consistency)
pmichaud I refuse to go that path.
we should identify classes by namespaces.
allison pmichaud, not for class identifiers, for HLL identifiers
pmichaud but Parrot_oo_get_class doesn't currently take a hll argument. 16:55
allison the classname key and hll name are separate
nope, but it should
pmichaud thus my earlier question: "you're going to change get_class to always take a hll argument"?
personally, I prefer that we just pass the namespace to get_class. 16:56
having already obtained it from the correct hll.
allison yes, on the C side, but it could be null
well, that's what we're going to do for now
pmichaud okay.
allison since changing the signature of Parrot_oo_get_class would require a deprecation cycle
pmichaud "just make it work". Got it.
allison aye :) 16:57
Tene: those .includes of 'library/' are just plain wrong
pmichaud Coke: What do you need summarized on the list -- the details of the 'hll_new' op? 16:58
Tene allison: remove the 'library/' and it fails. file not found.
allison Tene: if something is going to be included, it should be stored in the 'runtime/parrot/include'
not stored in 'runtime/parrot/library/'
Tene Ah. You shouldn't be including something in library/
:)
OK
NotFound So how can we deprecate the library classes with :: separator? Having two versions of each during the transition?
pmichaud Using .include on 'library/' is an artifact of very old-designed libraries.
NotFound: which libraries have :: separators, out of curiosity? 16:59
allison Tene: historically, parrot looked in 'runtime/parrot' for both include files and library files
NotFound pmichaud: Data, SDL, PostgreSQL, ncurses...
Tene nods.
allison Tene: then we separated them out into two directories, but some legacy code still expects the old way
NotFound ack '::' runtime/ 17:00
pmichaud NotFound: yes, I see, there are quite a few. (more)
Keep in mind that the '::'s that are in the PGE libraries are intentional and should not be removed.
NotFound Well, some '::' are just wrong examples and messages 17:01
pmichaud same for P6object
most of the ::'s that appear there look as though they come from before we really supported segmented namespaces and classnames
i.e., ['SDL::Class'] instead of ['SDL';'Class']
NotFound: I'd say that we put in deprecation notices for the affected libraries and classes, and then start moving them across after 1.4 17:02
it won't be _that_ difficult for others to keep up with the changes.
i.e., we don't really need two versions.
NotFound I suppose not, given that I already change some and no one complained X-) 17:03
pmichaud beyond that, there's a good question as to whether those libraries really want a complete re-design and implementation anyway
many of them were written _long_ before we had anything like PCT
NotFound I think SDL is actually not working
Tene Then it wouldn't hurt anyone to change it. :) 17:04
pmichaud so perhaps deprecating the library is really just slating it for removal entirely
allison I'd like to see the ones that aren't "core" moved out as external modules
NotFound At least I was unable to make it work all times I tried.
pmichaud yes, allison says it better.
we should deprecate them from core and make them into external modules or libraries.
allison in the Ubuntu packages, I don't even install most of those libraries 17:05
pmichaud Getopts should be deprecated anyway in favor of whatever particle++ is designing/building :-)
NotFound Can we have a list of those that are "core"? 17:06
pmichaud (although there's a lot of stuff still using getopts, so it probably can't disappear too quickly)
NotFound A wiki page?
purl hmmm... a wiki page is nice, but not newbie-friendly
17:08 darbelo joined 17:10 flh joined
allison NotFound: if you look in ports/debian/parrot.install.in and ports/debian/parrot-devel.install.in, you'll have a list of what's core 17:12
NotFound allison: nice
dalek cnum-dynpmcs: r46 | darbelo++ | trunk/t/rounding_mode.t:
Fix the tests. OpenBSD remains partialy hosed, but now I'm closer to knowing
allison (just looking at the library/ paths)
pmichaud afk # lunch 17:13
allison everything in runtime/parrot/include is currently core
(AFAIK)
afk_coke: I'm looking into the Tcl/Glob.pbc
NotFound message Coke I was wrong, Data::Dumper is still not converted to ['Data';'Dumper'] 17:15
purl Message for coke stored.
allison wow! I just svn up'd Partcl and it's not only successfully building, it's passing most of its tests! 17:22
"198/1314 subtests failed"
Whiteknight that is quite a nice change 17:23
allison D'oh! I just realized what Coke was asking. Tcl/Glob.pbc is in the Parrot repository, not in the Tcl repository. 17:25
message Coke Tcl/Glob.pir and .pbc should move into the Tcl svn repository, to be built and installed with Tcl. Any objections if I go ahead and do that? 17:26
purl Message for coke stored.
afk_coke Yes. =-) 17:44
Coke that's not a tcl-specific glob.
it's just called that for lack of a better name. Feel free to rename it. 17:45
NotFound: whee!
NotFound Coke: you guilty, you put Data;Dumper in my head ;)
Coke it was just an example! =-)
NotFound I think I must take notes more frequently about the thing I change. 17:46
Coke message allison Tcl/Glob.pbc isn't really tcl-specific; it's just a glob variant of PGE, like p5 or p6 regexen.
purl Message for allison stored.
Coke message allison; that's why it wasn't in languages/tcl, so other languages could share it; so I think it should stay in core, perhaps renamed, sure. 17:47
purl Sorry, I've never seen allison; before.
Coke message allison that's why it wasn't in languages/tcl, so other languages could share it; so I think it should stay in core, perhaps renamed, sure.
purl Message for allison stored.
Coke purl, idiot.
purl i heard idiot was someone who goes to an encyclopedia looking for something specific, reads it, and puts the encyclopedia away, looking at no other entries. or flyingpenguinproductions.com/boards/
Coke purl is an idiot?
Whiteknight purl
purl yes, Whiteknight?
Whiteknight purl purl? 17:48
purl i am a she. or captain obvious or so corny sometimes or creepy or a he or is also is also is also or retarded or NOT STEVAN or kd's quotefile
Coke message allison my original question is, should we be installing the .pbc of library stuff at all, or only .pir?
purl Message for allison stored.
Coke message allison (if only pir, then we shouldn't build it to .pbc in the build dir.) 17:49
purl Message for allison stored.
Coke that's a lot of messages
NotFound Coke: I think that the better way for library installs will be to copy the pir files and compile them to pbc. 17:50
Coke so, more like the build dir is now? 17:51
I would expect loading the .pbc would be faster, but have no data to confirm. =-)
NotFound In package installer terms, a post-install task 17:52
Coke: if we keep using load_bytecode '....pir', we'll never know if loading pbc is slow ;-) 17:53
Coke (keep using) I wasn't using it! I only switched to it because that's all I'm given now. =-) 17:55
eh. if we're going to ship them, we might as well build them as we already do.
NotFound Or even if it works. When I dropped the 'library/' prefixes I found some problems.
Coke: if we build them for distribution, we add a platform dependency that might not be required otherwise. 17:56
Coke ... huh? 17:57
NotFound Well, not a dependecy in strict sense if we're able of loading non-native pbc, but...
Coke my concern with not doing it during 'make' is that then "running out of a build dir" and "running against an install" means you can't do both.
which is fine, I suppose, since I can't really do either atm. 17:58
NotFound Ah, no. You can build them. I just say that we must not copy them to packages for installers.
Coke wait, allison could run "make test" in partcl!?
NotFound: I don't know what those nouns mean here, I guess. 17:59
NotFound Instead, the installer must compile
Coke didn't the installer already compile it when he ran 'make' ?
why does he have to compile them again?
or why shouldn't he use those copies he already built?
-> $DAYJOB
NotFound Maybe I mixing concepts %-) 18:00
18:02 particle1 joined 18:16 bsdz joined, davidfetter joined
Tene pmichaud: how about a method on the parrot compiler object that accepts a (space-delimited string|list of strings|other) of symbols in the local namespace to arrange for exporting (support tags would be nice) (presumably putting them in an EXPORT::TAG sub namespace) 18:21
18:23 Theory joined
allison Coke: ah, okay, then we could change the name of Tcl/Glob to something general and install it. Perhaps in the PGE namespace? 18:26
Coke: since the install is all in versioned directories, it's okay to go ahead and install the .pbc 18:28
Coke: the pbc installed in the 1.0.0 directories will always be compatible with the 1.0.0 libraries
Whiteknight irclogs? 18:29
purl irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
18:29 japhb joined
pmichaud Tene: that's similar to what I had been thinking/doing -- see '!EXPORT' in Rakudo for an example. 18:30
allison Coke: you're not able to run 'make test' in partcl?
pmichaud except that !EXPORT was of course exporting to the global scope; this one should simply make them available via the appropriate hash.
Tene pmichaud: exactly. 18:31
allison NotFound/Coke: oh, but if you load all the files as .pbc, Parrot is smart enough to fall back to .pir if the .pbc files don't exist
pmichaud I don't know that the parrot compiler object should be explicitly sticking them into namespaces, though -- simply making them available via the interface we described via load_library should be sufficient.
Tene .sub :load :init { a = compreg parrot; a.omgexport('foo bar baz lol wtf etc') }
pmichaud OTOH, if you want to go ahead and make the extra namespaces, I'm okay with that for the time being. It just sounds too perl6-centric to do that. 18:32
Tene pmichaud: where else could it put the symbols? Some global registry object?
pmichaud the compiler can keep track of them
in a hash or hash of hashes or something like that.
Tene Sure, OK. 18:33
allison pmichaud/Tene: I like that
NotFound allison: I'm not sure if it's still trying to load pbc as pir or pir as pbc
pmichaud that way it could be more generic than just for the 'parrot' compiler, but also work for other compilers as well without polluting their namespaces.
18:34 NotFound left, NotFound joined
NotFound What happened? 18:34
purl We don't know what happened, so tell everyone nothing happened.
allison NotFound: .pir falls back to .pbc, .pasm falls back to .pbc, and .pbc falls back to first .pir, and then .pasm 18:35
18:51 Theory_ joined 19:01 donaldh left
Coke allison: no. 'make test' is assuming too much about where things are. do you have a local patch you need to commit? =-) 19:10
NotFound t/pmc/namespace.t has "add_sub() with error # TODO needs full implementation of PDD 17" However, I don't see what hat has pdd17 to do with the reason of his fail
Coke allison: no, when I did load_bytecode "Tcl/Glob.pbc", it barfed most heavily, even though the .pir was present. 19:11
(this was on feather in a recent checkout of partcl running against the installed 1.2.0
said it wasn't a valid bytecode file.
NotFound It fails mainly beacuse the Closure pmc does not exist.
Coke NotFound: once something is todo'd, the message immediately starts to rot. 19:12
pmichaud allison: ping
NotFound Coke: yes, I've seen that too. It falls back to .pir in the filename, but not in the expected format of the content. 19:13
The Closure pmc was dropped some time ago, isn't it?
Coke NotFound: makes sense (in that it explains the bizarre, unexplainable error message. =-) 19:14
I'll open a ticket.
NotFound The other error is that it uses pir_error_output_like, but it ends without error, beacause the exception is catched.
Coke message infiniod - I added a 1.2.0 version on trac for bugreporting. 19:15
purl Sorry, I've never seen infiniod before.
Coke message infinoid - I added a 1.2.0 version on trac for bugreporting.
purl Message for infinoid stored.
NotFound purl: good bot
purl thanks NotFound :)
NotFound Well, if what the test chekcs is just that it can add several things in the namespace, and fails when adding as sub something that's not a sub, it can easily be DOed 19:16
Coke ticket opened in #692 19:17
message infinoid - should we add trac tickets to the noise in here? 19:18
purl Message for infinoid stored.
Coke makess 1.2.0 the default version for bugreports.
NotFound Well, not so easily, first I must make sure I don't broke the latin-1 depending tests :D 19:19
19:20 donaldh joined
NotFound By the way, those tests are broken, I can corrupt the file and they still pass 19:20
The characters just get corrupted in both places X-) 19:22
19:23 fperrad joined
dalek kudo: 60f709d | jnthn++ | src/parser/grammar.pg:
Follow a STD.pm addition.
 19:27
rrot: r38988 | NotFound++ | trunk/t/pmc/namespace.t:
[test] fix and unTODO a namespace broken test
 19:28
Infinoid Coke: Thanks. Still waiting to hear back from osuosl on ftp perms 19:31
Coke: I also don't have a problem with tracking trac ticket activity in here... the actual comments at least (the metadata stuff would probably get very spammy) 19:32
fperrad Infinoid, now, I'm at home, could I help ? 19:33
dalek kudo: ba0b2be | jnthn++ | src/ (2 files):
Some tweaks to handle has &!foo and has &.foo. Resolves RT#64650 and RT#64270.
Infinoid fperrad: Sure! If you still have permission, you can upload the tarball for me :)
fperrad Infinoid, ok, I try 19:34
Infinoid fperrad++
19:36 Theory joined
Coke Infinoid: figured just "open ticket" and "close ticket" would be enough. 19:36
Infinoid I'll see if I can throw together some oneliners with the ticket number, state (or activity) and summary 19:38
fperrad Infinoid, done 19:40
Infinoid Thanks! I'll update the various webby things and send out the announcements
moderator Parrot 1.2.0 released | parrot.org/ | 308 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets 19:44
19:49 Theory joined
Infinoid Ok, 1.2.0 has hit the lists, the website, and en.wikipedia. The es, ja and ru translations of that page could use updating, if any of you speak any of those languages 19:51
Heh, it.wikipedia.org/wiki/Parrot seems to be saying the latest version is 0.4.10. 19:52
(I think. I don't speak italian.)
NotFound Mmm... I don't remember if I have a wikipedia account
Infinoid Use it if you have it, but you don't need one to edit pages 19:53
jonathan sk.wikipedia.org/wiki/Parrot doesn't even exist. :-|
jonathan ponders changing that
Infinoid jonathan++
NotFound Infinoid: I don't like execessive publicty of my IP
pmichaud jonathan: I decided the new op should be <root_new> instead of <hll_new>, and the hll is part of the key (more)
jonathan: i.e. $P0 = root_new ['parrot';'Integer']
Infinoid NotFound: Fair enough :)
pmichaud this seems far more consistent with the other opcodes.
jonathan pmichaud: fairy nuff
Infinoid they're not hard to create though. 19:54
jonathan Yes.
pmichaud it also makes it easier to get PCT to dtrt with it. 19:55
(because PCT already knows how to handle keys)
jonathan ;-)
works for me
I'm currently pondering how to get $.foo(1,2,3) to do the Right Thing.
pmichaud oh, I already know how to fix that.
jonathan Ah, what had you got in mind? 19:56
pmichaud first the parser has to be adjusted
jonathan ah, ok
NotFound pmichaud: agreed, hll_new looked like it were for the opposite purpose
pmichaud NotFound: right -- everywhere else that 'hll' appears in an opcode, it always means "the current HLL".
Infinoid fperrad: Thanks again for the uploading help, fperrad++
Whiteknight: You're up next :) 19:57
pmichaud well, not the parser so much as the grammar has to be adjusted.
but $.foo no longer looks like a variable
(which it shouldn't be anyway)
jonathan pmichaud: Ah, hwo's std parsing it these days? 19:58
dalek tracwiki: v69 | Infinoid++ | WikiStart
tracwiki: News item for 1.2.0
jonathan It sounds like it's a bigger change than I thought though.
dalek tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
pmichaud it's not huge but also not minor
jonathan OK, let's leave it until after release. 19:59
pmichaud I think std parses it as part of the <variable> token, but treats it like a methodop
it's a relatively recent change to std
(i.e., within the past two months)
TimToady phone 20:00
pmichaud TimToady: be there in 2
allison NotFound: I have a wikipedia account, but I think I'm not allowed to update anything about Parrot since I work on the project 20:04
Whiteknight I'll update it
At least, the en one 20:05
NotFound allison: Then I think none of us must be allowed.
Whiteknight you are "allowed", you just have to be careful about the COI and NPOV policies
and you have to cite anything that sounds too much like a sales pitch
NotFound The vigilantes of the spanish version are famous to be a lot less tolerant than the en 20:06
darbelo That and the spain vs latin america edit wars. 20:07
Whiteknight How do you say "May" in es? 20:08
darbelo Mayo
NotFound darbelo: and don't even talk about spanish civil war related ones
rg infinoid: are you sure the release announcement has hit the website? i don't see it.
darbelo doesn't see it either 20:09
allison it's up now 20:10
Whiteknight w00t
rg can't confirm that, sorry 20:11
allison I didn't see it at first, but reloaded and it was there
Whiteknight yeah, PacoLinux just added it
If the es.wikipedia folk raise a stink about it let me know
allison oh, wait, it's not there again if I log out 20:12
rg i've shift-reloaded a couple of times already. i must be hitting a cache somewhere that's not under my control
allison there it is
Whiteknight es.wikipedia.org/w/index.php?title=...tion=purge 20:13
rg ah yes. thanks.
Whiteknight that link should purge the mediawiki cache
dalek website: Infinoid++ | Parrot 1.2.0 "Bird Brain" released!
website: www.parrot.org/news/2009/Parrot-1.2.0
rg now dalek found it too :)
Whiteknight out. Talk to you guys later
darbelo sees it too. 20:14
rg: You are alone in the world :)
rg darbelo: no, i've got it now 20:15
NotFound The translation "un bytecode para regirlos a todos" looks odd to me. The translation of The Lord Of The Ring I've readed use "gobernarlos", not "regirlos"
darbelo The translation I know is "Un Anillo para gobernarlos a todos" too. 20:18
rg maybe whoever translated the page didn't get the reference? 20:20
NotFound Given that it mentions it explicitly, I doubt X-)
rg ok :)
darbelo also "lista de correa de portadores de Perl" is probaly not what you mean. 20:21
NotFound Yeah, but that kind of errors are usual in programming things
Infinoid What's this about it not being on the website? (did I miss a site?)
rg infinoid: it's been fixed (corrected itself?) 20:22
darbelo Infinoid: It was a 'reload an you'll see it' thing.
NotFound "regirlos" is not wrong, just looks ugly in that context
Infinoid ok 20:23
allison Coke: I do have a local patch, but it should only be affecting a couple of test files, not the whole lot 20:30
fperrad: ping 20:31
fperrad allison, pong
allison fperrad: could you add my ssh key to the ftp server? I'm happy to add everyone else's 20:32
it's a simple 'cat' command 20:33
fperrad allison, have you seen Jerry Gay's email "ssh keys needed" 20:35
allison yes (I asked him to send it)
but, we don't actually have to get osuosl to add the keys
we can add them ourselves
we just need one person with a valid login 20:36
fperrad allison, send me a email with your public key and the recipe
dalek kudo: b4f301d | jnthn++ | docs/ChangeLog:
ChangeLog tweaks.
 20:37
allison fperrad: okay, thanks!
fperrad allison, I see already your dss key : allison@onji 20:44
allison hmmm... I wonder if they added it after my email last night?
20:44 donaldh_ joined
fperrad allison, authorized_keys was updated today at 16:07 20:46
allison okay, I just logged in 20:47
whoot!
Infinoid Great, so we shouldn't have that problem next time 20:57
PerlJam What causes stuff to appear as news on www.parrot.org?
Infinoid its a categorization thing when you post the story 20:58
PerlJam the 1.2.0 announcement doesn't show up under News
Infinoid double checks the publishing stuff 20:59
PerlJam: It's docs/project/release_manager_guide.pod sections 10(b) and 10(d)
allison PerlJam: for that it needs to be tagged with both 'News' and 'Release'
Infinoid: ah, I'll add a note on that to the release manager guide. 21:00
Infinoid The 1.1.0 posting is just in News, not Releases
1.2.0 is the opposite
Infinoid fixes
PerlJam: That should do it, try now? 21:01
PerlJam bueno
jonathan oh joy, seems Parrot doesn't allow a unicode literal as an arguemnt to the concat op.
oh, my bad
you hae to use double quotes
dalek rrot: r38989 | allison++ | trunk/docs/project/release_manager_guide.pod:
[release] Add a note about ssh keys on the FTP server, and the 'News'
 21:08
NotFound What do you mean by "unicode literal"?
utf8 encoded? 21:09
allison NotFound: I'm pretty sure he means a string literal tagged with unicode: 21:10
NotFound That defaults to ut8, if I remember well. 21:11
21:23 Whiteknight joined
jonathan allison: Yes, that's what I mean.t 21:28
allison: It's fine, I'd just used single quotes by accident.
21:31 szabgab joined
dalek rrot: r38990 | fperrad++ | trunk/tools/install/smoke_languages.pl:
[install] fix test of PrimitiveArc
 21:44
Infinoid mj41 has an interesting challenge if anyone's looking for an inscrutible GC bug to fix 21:46
nopaste.snit.ch/16625 (apparently somehow caused/triggered by r38962) 21:47
urkle I'm playing with Parrot on Mac OS X.. I just downloaded the 1.2 release and ran tests... and several (5) of the tests caused segfaults.. What info is needed for a bug report? (and how do I easily identify WHICH tests caused the segfault? ) 21:48
NotFound I have the same fail... sometimes, unable to reproduce
Infinoid NotFound: In the same alarm test?
NotFound Infinoid: yeah
Infinoid I suspect a race condition, but I can't reproduce it here (I ran it in a shell loop for half an hour, no failures) 21:49
NotFound I can't even reproduce it in the machine were it happens
Whiteknight msg allison: Thanks, the ssh ftp login works like a charm 21:53
purl Message for allison stored.
dalek tracwiki: v93 | fperrad++ | Languages 21:54
tracwiki: Update with Parrot 1.2.0
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
allison Whiteknight: excellent!
purl zwooshes
mj41 Seems like tapir2 (TapTinder client) can reproduce it each time tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk
Whiteknight I'm learnding!
mj41 This failings was probably similar tt.ro.vutbr.cz/report/pr-Parrot/do?...un-1518=on
NotFound urkle: you can try prove -v t/...whatever says in the final report 22:07
urkle NotFound: Thanks.. 22:10
purl thanks is, like, works now :D
urkle NotFound: is there a way to run a specific sub-test in the test file?
NotFound urkle: if is a perl test, he mus generate ...._nn files 22:11
22:12 bacek joined, ruoso joined
dalek tracwiki: v94 | fperrad++ | Languages 22:13
tracwiki: Update with Parrot 1.2.0
tracwiki: trac.parrot.org/parrot/wiki/Langua...ction=diff
urkle NotFound: ahh.. wait.. it generates the individual PIR/PASM files for each sub:) so I can just manually run those with parrot.. cool.... I'm going to make sure all of these segfalts are tracked in a bug 22:14
NotFound urkle: yes, that's a way
urkle I know I ran across a link talking about migrating from RT to Trac.. recall where there is? 22:15
Infinoid mj41: does "./parrot -G t/dynoplibs/myops_7.pir
" run successfully?
NotFound Infinoid: I also have failures with myops in the amd64 machines I test at daywork 22:17
Infinoid Consistent or random? 22:18
I know I rewrote at least one of those alarm tests in the past, to try to avoid races
mj41 Infinoid: -G is ok
NotFound Randomly, I've still not found a pattern.
darbelo NotFound, Infinoid: I jut ran make test now on OpenBSD-current amd64, and I'm seeing both.
Infinoid mj41: Ok, I suspect it's a GC issue and probably dependent on memory pressure or process memory layout or somesuch. That means it's not easy to debug :) 22:19
NotFound Unfortunately, I can't spend too much time with parrot on that systems
Infinoid But if you are seeing it reliably, that certainly helps
22:23 Theory joined
afk_coke . 22:23
Coke allison: ping. 22:25
dalek rrot: r38991 | chromatic++ | trunk/src/hash.c:
[src] Replaced an unnecessary calloc() with a malloc() and an initialization
 22:26
rrot: r38992 | chromatic++ | trunk/src/pmc/codestring.pmc:
[PMC] Delayed a STRING fetch in CodeString's lineof() method until absolutely
nopaste "darbelo" at 200.49.154.172 pasted "backtrace of the failure on t/pmc/io_37.pir for OpenBSD-current amd64" (65 lines) at nopaste.snit.ch/16626 22:29
dalek rrot: r38993 | chromatic++ | trunk/src/pmc/nci.pmc:
[PMC] Avoided some relatively expensive C string conversions and malloc/frees
 22:30
rrot: r38994 | chromatic++ | trunk/src/pmc/resizablepmcarray.pmc:
[PMC] Improved the resizing logic in the ResizablePMCArray PMC to avoid
rrot: r38995 | chromatic++ | trunk/src/string/charset.c:
[string] Tidied some code; no functional changes.
Infinoid darbelo: Hmm. can you print obj and arena_base, to make sure both pointers are valid? 22:31
22:32 particle1 joined
Infinoid It looks like that segfault was from accessing either arena_base->gc_mark_ptr or obj->pmc_ext 22:33
darbelo I just did a realclean and svn up. It's still building.
Infinoid oki
darbelo Oh, wait, the .core is still there. Are there any magic incantations I can use on it to help you? 22:35
Infinoid yeah, "print arena_base->gc_mark_ptr" and "print obj->pmc_ext"
22:35 kid51 joined
Infinoid See if either of those result in an error message 22:35
darbelo (gdb) print arena_base->gc_mark_ptr 22:36
$1 = (PMC *) 0x2036a0ae0
(gdb) print obj->pmc_ext
$2 = (struct PMC_EXT *) 0x1
dalek rrot: r38996 | jkeenan++ | trunk/lib/Parrot/Docs/Item.pm:
Delete unexplained TODO item per rt.perl.org/rt3/Ticket/Display.html?id=43713.
 22:37
Infinoid ok, so the pmc_ext pointer is wrong 22:38
NotFound Maybe some pointer<->integer conversion hardcoded for 32 bits 22:40
dalek rrot: r38997 | jkeenan++ | trunk/lib/Parrot/Docs/Group.pm:
Delete unexplained TODO item per rt.perl.org/rt3/Ticket/Display.html?id=43709.
Infinoid the caller is marking the context's string registers (S0..Sn)
darbelo Infinoid: Shouldn't that be harmless? 22:43
dalek rrot: r38998 | jkeenan++ | trunk/lib/Parrot/Docs/File.pm:
Applying patch submitted in rt.perl.org/rt3/Ticket/Display.html?id=43687. Refactors some code handling abstract section of html docs.
Infinoid src/gc/mark_sweep.c:359 seems to have been written with the assumption that if pmc_ext is non-NULL, it's a valid pointer 22:44
darbelo Ouch!
jonathan That doesn't sound like an especially crazy assumption. 22:45
moderator Parrot 1.2.0 released | parrot.org/ | 306 RTs left | Weekly Priority: Apply Patches, Fix Bugs, Close Tickets 22:45
Infinoid right, except we're not feeding it a PMC, we're feeding it a STRING 22:45
darbelo: what's your sizeof(UINTVAL)? 22:46
jonathan Ah.
Infinoid If gdb doesn't understand that, you might be able to find it in include/parrot/config.h... one sec
I think PMC's pmc_ext lines up with STRING's strlen
depending on the sizes of things on x86-64
darbelo parrot_config --dump | grep intvalsize 22:47
hugeintvalsize => '8'
intvalsize => '8'
kid51 Infinoid ping
Infinoid hi kid51
ok, same as me then, and same as pointer size
kid51 Congratulations on completing the release. Was that your first?
Infinoid thanks, yes (and it felt a bit rushed) 22:48
darbelo I *think* INTVAL is guranteed to be 'able to hold a pointer'
Infinoid I would have preferred a couple of extra weeks to work on trunk/NEWS
kid51 Can you guide me re reproducing the problem you described in TT #690?
Infinoid Yeah. All I did was unpack the tarball, configure and run make fulltest 22:49
Coke we really should be updating news as we go. =-)
Infinoid kid51: but all you really need is "make manifest_tests"
kid51 ... which I wrote
particle1 coke: it can be a question during parrotsketch, perhaps
Infinoid fulltest runs all the targets on the same make command line, but when those tests are skipped, manifest_tests apparently returns false
Coke what's to question?
kid51 So, I should download a tarball from our site?
particle1 any updates to NEWS this week? 22:50
Coke we can't make people update as they go.
particle1 friendly reminder form.
Coke I would find it annoying. =-)
Infinoid kid51: Yeah. I was using the 1.2.0 tarball, same one that was uploaded to the site
The same exact set of files worked fine in an svn checkout, so I think it's depending on svn metadata
kid51 I've never actually used a release tarball. Any tricks, suggestions, gotchas?
Infinoid nah, it should Just Work
building and testing is identical to a checkout 22:51
kid51 Yes, it always works in svn checkout
22:52 szabgab joined
Infinoid darbelo: So I don't think it should have called mark_special() on that STRING 22:53
which probably means a special flag bit was set when it shouldn't have been
but since this is the GC, that could be a fairly deep rabbit hole
dalek kudo: 6381427 | jnthn++ | src/ (2 files):
Implement generation of meta-ops for user-defined operators. Resolves RT#65660.
 22:54
Infinoid Coke: Updating NEWS should be a suggested step for branch merges, at the very least 22:55
the vast majority of non-branch-merges were minor fixes, but the branch merges tended to be more noteworthy
NotFound There is no windows developper wanting to navigate the beautiful waters of CreateProcess, CreatePipe and other nice beasts?
Infinoid NotFound: I went onto MSDN and looked up the API, but I only test on win32, I don't have an editor with nice pretty colors there so I don't do much win32 devel 22:56
(Which probably explains why I still haven't fixed the socket warnings there)
dalek rrot: r38999 | chromatic++ | trunk (3 files):
[GC] Changed the n_regs_used member of Parrot_Context from a raw pointer into a

creation/destruction code to avoid expensive malloc()/free() calls to manage fixed-size data that should be part of the context directly. The result is that the fib.pir benchmark runs 6.84% faster. Other code with heavy use of PIR function calls will see similar -- or larger -- improvements.
NotFound I have code that can be borrowed from, but is C++ and I haven't touched it for years. 22:57
To translate it to C, you probaly need lots of if to avoid leaking resources on error conditions. 22:58
Infinoid error unwinding is the only place I regularly use goto 22:59
it's *so* much cleaner than enumerating every case with ifs and curlies
dalek kudo: 3c425eb | jnthn++ | t/spectest.data:
Add S13-overloading/metaoperators.t to spectest.data.
NotFound If you want to try: blassic.org/bin/blassic-0.10.2.tgz -> fileopen.cpp 23:00
Infinoid maybe this weekend, I'm running out of parrot time for the moment
NotFound Is GPL code, but is mine, feel free to borrow anything 23:01
Infinoid NotFound++
in the meantime, I can do build tests if you want to knock something together
NotFound I hate to write code if I can't even compile it. 23:02
Infinoid no worries, I'll work on it sometime in the next few days
NotFound s/fileopen/filepopen 23:03
23:20 donaldh joined
dalek rrot: r39000 | jkeenan++ | trunk/t/manifest (5 files):
Modify manifest tests to work in release tarballs (by skipping all but one test). Cf.: trac.parrot.org/parrot/ticket/690.)
 23:23
kid51 Infinoid: If you 'svn up' and copy the new files into your release checkout, you should be able to confirm the fix. 23:24
Infinoid creates a test tarball with "make release" and tries it 23:26
cotto time to see if a kernel update makes all my problems go away
Infinoid Usually those add new problems at the same time. :) 23:27
kid51++ # looks good
Now a "make manifest_tests distro_tests" allows the latter target to run as well
so fulltest should work too 23:28
kid51 Good. I'll close 690.
Infinoid Thanks!
Tene Okay, driving home, and then working on apl 23:33
23:34 tetragon joined 23:35 cotto joined 23:42 cotto joined 23:45 ilia joined
cotto good enough 23:47
Infinoid there's an extremely large team of kernel coders working to fix bugs, and a (rather smaller but just as effective) team of kernel coders working to add new ones 23:48
So at any given time, there's a fairly constant number of bugs
rg lol. who said that? ;) 23:49
Infinoid so from a certain perspective, you can call it a form of "stability"
sailboat racing & 23:52
darbelo Hmm, ".include foo.pir" isn't working as intended in the abvsence of .pbc files. 23:57
.include 'test_more.pir'
PackFile_unpack: This is not a valid Parrot bytecode file 23:58
Parrot VM: Can't unpack packfile /home/darbelo/parrot/instdir/lib/1.2.0-devel/library/Test/More.pir.
Unable to append PBC to the current directory

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!