Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-13

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 chromatic Coke, that might be a win for you.
00:01 Coke damn is feather slow.
00:13 Coke bacek: Thuesday?
00:13 Infinoid ENOBACEK
00:14 Coke msg bacek Thuesday?
00:14 purl Message for bacek stored.
00:14 Infinoid oh, heh.  I had originally read that as "thursday"
00:15 Coke is it possible to make a constant RPA?
00:15 * Coke digs for .const
00:16 chromatic I don't know how you'd initialize it.
00:16 chromatic You'd probably have to declare all of its contents as .const too.
00:22 cotto Coke, you could make it ro
00:22 Coke I don't care if it's editable (i just won't edit it.)
00:26 chromatic You want it constant and compile-time so.
00:28 nopaste "coke" at 72.228.52.192 pasted "something like this." (18 lines) at http://nopaste.snit.ch/16888
00:30 Coke that doesn't work, but that sort of thign.
00:32 Coke Bus Error!
00:32 purl Go take a walk.
00:36 dalek TT #756 created by coke++: invalid PMC causes bus error with const.
00:37 nopaste "coke" at 72.228.52.192 pasted "this fails on instantiate_str() ." (18 lines) at http://nopaste.snit.ch/16889
00:38 Coke For now I'll just have an immediate that creates it and shoves it into a global (which I'm already done.)
00:38 Coke "doing"
00:45 chromatic There's a fix for http://nopaste.snit.ch/16887 .  Ugh.
00:50 Whiteknight chromatic: does that snippet cause a problem?
00:50 chromatic r39125 was the culprit.
00:51 Coke I always knew consting was evil.
00:52 chromatic I think the fix for that will help Coke tremendously.
00:52 Coke here's hoping.
00:52 Coke I presume you're not just reverting 39125, then.
00:53 chromatic Nope.
00:53 chromatic I don't want to lose the performance gain.
00:57 diegoviola joined #parrot
00:57 diegoviola hi, is parrot ready for production use?
00:57 Coke FSOV production.
00:57 diegoviola ?
00:57 Coke "for some values of"
00:58 diegoviola if we'd like to embedd parrot in some platforms, such as this: www.freeswitch.org
00:58 diegoviola and apache, etc
00:58 Coke There is a 1.0 that is considered stable.
00:58 Coke for apache, see "mod_parrot"
00:58 Coke that project is well underway and already supporting higher level languages like perl6.
00:59 diegoviola i see
00:59 diegoviola well, thanks for the info
00:59 diegoviola parrot seems to be really interesting
00:59 diegoviola how does it compares to something like java or mono?
00:59 diegoviola i don't like either of those
01:00 diegoviola is it comparable?
01:00 diegoviola or they are different things?
01:00 diegoviola for different purposes i mean
01:01 Coke There's a FAQ on that.
01:01 diegoviola ok
01:02 ZeroForce joined #parrot
01:03 Infinoid How would you plug parrot into freeswitch?
01:03 chromatic Hm, the problem is that pool->num_free_objects is very, very wrong.
01:03 diegoviola so it's stack-based vs register-based?
01:04 Whiteknight parrot is register-based
01:04 tewk ==========================================​==========================================​==========================================​======================================/
01:04 Whiteknight ?
01:04 diegoviola Infinoid: i don't know, i'm not a developer, but i wanted to suggest that to the devs... since they already have mod_java and mod_managed (mono)
01:04 diegoviola Infinoid: and i don't want to use either of those
01:04 tewk zQ,m ~m3~
01:04 tewk ]\'''''''''''''''''''''''''''''''y'y']'6y']]']]]
01:05 diegoviola Infinoid: they asked me if it was embeddable
01:05 Coke tewk's cat is in town.
01:05 Infinoid diegoviola: We have an embedding API which is sorely in need of more users
01:06 diegoviola Infinoid: is there a link on that on the web site?
01:06 Whiteknight I think tewk is broken
01:07 diegoviola found it
01:07 Infinoid there should be embed.pod and pdd10 on docs.parrot.org, digging up links now (I'm on a slow connection here)
01:07 diegoviola http://www.parrotcode.org/docs/embed.html ?
01:07 diegoviola ok thanks
01:08 Whiteknight goodnight
01:08 Infinoid parrotcode.org is outdated
01:08 diegoviola ok
01:08 Infinoid http://docs.parrot.org/parrot/l​atest/html/docs/embed.pod.html
01:08 pmichaud chromatic: Should I go ahead and file a ticket for nopaste 16887?
01:08 Infinoid http://docs.parrot.org/parrot/latest/html​/docs/pdds/draft/pdd10_embedding.pod.html
01:08 diegoviola yep, thanks
01:09 Coke pmichaud: couldn't hoit.
01:10 chromatic pmichaud, I can fix it the easy way, but I want to keep performance where it was.
01:12 pmichaud what's the easy way fix?
01:13 whoppix joined #parrot
01:13 Infinoid The easy way is probably reverting r39125
01:14 * pmichaud checks 39125
01:14 Coke I'm surprised that consting would do that.
01:14 Coke is it putting something into the constant pool and then not getting freed?
01:15 chromatic r39215 I meant.
01:15 Infinoid oh
01:15 Coke that's much more likely. =-)
01:15 Coke dyslexic much?
01:16 pmichaud chromatic: I wonder if the reason that Rakudo is 6.79% faster is because there aren't any GCs taking place.
01:17 chromatic Yep.
01:17 chromatic pool->num_free_objects is very, very wrong for some reason.
01:18 pmichaud #define GC_DEBUG_REPLENISH_LEVEL_FACTOR        0.0
01:18 pmichaud that looks odd.
01:19 chromatic That's only for GC debugging.
01:19 pmichaud ah, right.
01:19 pmichaud okay.
01:20 chromatic I'm running the test suite now, but it should be okay.
01:23 chromatic A smarter GC wouldn't have had a problem here.
01:24 chromatic But whenever we allocate a new pool, we write to it and turn virtual memory into process memory.
01:24 chromatic Coke, Tcl may fare far better now.
01:24 dalek parrot: r39531 | chromatic++ | trunk/src/gc/gc_ms.c:
01:24 dalek parrot: [GC] Reverted r39215, which caused the GC to allocate more pools unnecessarily
01:24 dalek parrot: and caused long programs to run out of memory.  This needs some rethinking.
01:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39531/
01:30 Hunger- joined #parrot
01:32 Coke chromatic: trying one of the spec tests that exploded now.
01:34 Coke memory usage is INSANELY better.
01:37 Coke much better, thanks.
01:37 Coke I'll try all the out of memory ones, unskip them, and do a full run.
01:38 Coke mathop.test alone (my test case) gets me another 158 passes.
01:44 Coke of course, now the ones that leak memory slowly take a LONG time to fail. =-)
02:18 Coke hurm. the tests are not magically completing.
02:18 Coke I'll unskip all the ones I can.
02:30 cognominal joined #parrot
02:35 Theory joined #parrot
03:01 diegoviola so does parrot has the potential to replace mono or java?
03:01 diegoviola even if it's not it's goal
03:01 diegoviola i mean, in a technolgy way
03:01 diegoviola technology
03:01 purl philosophy
03:02 diegoviola yep but as a technology, can it compete against those?
03:02 diegoviola in the market today
03:05 Coke purl is a bot, btw.
03:14 Coke diegoviola: there's a few problems with using parrot to compete with the jvm and mono today;
03:14 diegoviola does the register-based has any advantages over the other?
03:15 diegoviola Coke: which are those problems?
03:15 Coke parrot is generally slower than the original implementations of the target languages; many of the langauges targetted at mono (and all of the big one for java) don't have compilers to parrot.
03:15 Coke diegoviola: I'm /typing/ =-)
03:15 diegoviola ok
03:15 Coke diegoviola: (register based) again, that was a FAQ. That was the supposition, yes.
03:17 Coke see docs/faq.pod
03:17 diegoviola thanks
03:17 Zak joined #parrot
03:18 Coke I'm not sure why that doc isn't visible on docs.parrot.org
03:20 Maddingu1 joined #parrot
03:20 Coke chromatic++
03:20 Coke chromatic++
03:20 Coke chromatic++
03:20 Coke chromatic++
03:20 Coke chromatic-- # for breaking it in the first place.
03:21 donaldh joined #parrot
03:21 Coke Pretty sure his fix has won me about 750 more passing tests.
03:21 Coke 750 / 2162
03:21 purl 0.346901017576318
03:27 zak_ joined #parrot
03:35 pmichaud it's also exposing some GC problems in Rakudo.
03:40 dalek rakudo: 4d21e2a | pmichaud++ | build/PARROT_REVISION:
03:40 dalek rakudo: Bump PARROT_REVISION.
03:40 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​d21e2a707c3f1854ee500edcc93121dc66ba225
03:55 Coke hurm. any idea why http://code.google.com/p/partcl/sourc​e/browse/trunk/config/misc/spectcl.in isn't showing the PANIC in the .results file when it's done?
03:57 Coke bah. it does sometimes. nevermind.
04:01 dalek partcl: r483 | coke++ | wiki/SpecTestStatus.wiki:
04:01 dalek partcl: chromatic++ # actually running the GC helps us stay under the limit.
04:01 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=483
04:23 eternaleye joined #parrot
04:36 mikehh_ joined #parrot
04:39 Theory joined #parrot
04:43 eternaleye joined #parrot
04:57 eternaleye joined #parrot
05:10 Theory joined #parrot
05:24 dalek partcl: r484 | coke++ | trunk/docs/spectest- (2 files):
05:24 dalek partcl: Reclaim several more test files after chromatic++'s recent GC fix.
05:24 dalek partcl: (lost subst, though.)
05:24 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=484
05:27 Coke msg chromatic http://code.google.com/p/p​artcl/source/detail?r=484 - net gain of 810 tests : that pushes to the highest # of passing spec tests ever. (and that's with a loss of a 35 in some other file). also, the tests ran /faster/, even though we ran more tests. (158s faster)
05:27 purl Message for chromatic stored.
05:28 Coke msg chromatic - there are some minor tcl changes in there too, but I'm willing to give you all the credit. =-)
05:28 purl Message for chromatic stored.
05:28 Coke purl 4374 / 60 / 60 ?
05:28 purl i haven't a clue, coke
05:28 Coke purl 4374 / 60 / 60
05:28 purl 1.215
05:47 cotto that many hours to run the spec tests?
05:53 eternaleye joined #parrot
06:04 dalek parrot: r39532 | tene++ | trunk/runtime/parrot/languages/parrot/parrot.pir:
06:04 dalek parrot: [languages/parrot]:
06:04 dalek parrot: * Behave better when a library doesn't explicitly define exports
06:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39532/
06:11 dalek parrot: r39533 | tene++ | trunk/runtime/parrot/library/Curses.pir:
06:11 dalek parrot: Add a curses lib Curses.pir (copied from ncurses.pir) that can be used from HLLs.
06:11 dalek parrot: Not sure about deprecation of ncurses.pir.
06:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39533/
06:14 dalek parrot: r39534 | tene++ | trunk (2 files):
06:14 dalek parrot: SVN metadata and MANIFEST.
06:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39534/
06:14 Coke cotto: (hours) yes.
06:38 f0rk joined #parrot
06:44 f0rk I have a question about threading and multicore in parrot
06:45 f0rk what support for these features will parrot have?
06:48 Tene Parrot currently supports threading.
06:49 f0rk I see
06:49 f0rk is there somewhere in the docs where I could read more about it?
06:49 viklund_ joined #parrot
06:50 Tene docs/pdds/pdd25_concurrency.pod should be a decent start
06:50 Tene also docs/pdds/pdd24_events.pod
06:50 Tene also look at the tests
06:50 f0rk thanks!
06:51 Tene t/pmc/threads.t
06:51 Tene iirc
06:51 Tene did you have any more-specific questions?
06:51 f0rk not at the moment
06:51 Tene Feel free to ask at any time. :)
07:10 f0rk joined #parrot
07:20 donaldh joined #parrot
07:29 japhb Tene: thanks for the catch in t39534.
07:29 japhb er r39534, of course
07:41 cowens joined #parrot
07:46 cowens left #parrot
07:52 Tene I found a nasty crash in clone_interpreter().
07:52 dalek TT #757 created by tene++: Problem with threads and HLLs
08:17 mj41 joined #parrot
08:26 barney joined #parrot
08:32 chromatic joined #parrot
08:32 dalek TT #758 created by reezer++: Fix problems o openbsd/hppa
11:05 dalek rakudo: e167c92 | moritz++ | t/spectest.data:
11:05 dalek rakudo: 3 more files for spectest.t
11:05 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​167c92456b31d6f6c81f6d31d1c4fe5bcfebce2
11:10 nopaste "Infinoid" at 65.18.171.17 pasted "More opengl configuration warnings on gentoo/amd64 (yes, I upgraded mesa recently)" (274 lines) at http://nopaste.snit.ch/16892
11:20 donaldh joined #parrot
11:29 Infinoid msg bacek Please take a look at TT #758.  According to http://smolder.plusthree.com/app/public_projects/​smoke_reports/8?tag=Perl%205.10.0%20hppa-openbsd, r39527 passes almost all tests and r39529 has lots of failures.  (r39528 is just POD, r39529 was your tt24_unicode_numifications merge.)  The failures look like http://smolder.plusthree.com/app/pu​blic_projects/tap_stream/23630/187
11:29 purl Message for bacek stored.
11:36 bacek joined #parrot
11:43 bacek o hai
11:44 Infinoid hey :)
11:46 Infinoid bacek: As I said in the msg, r39527 passes almost all tests, but the two tests it does fail are also floatval-related, so parrot wasn't perfect before the merge either
11:46 Infinoid http://smolder.plusthree.com/app/pu​blic_projects/tap_stream/23619/162, http://smolder.plusthree.com/app/pu​blic_projects/tap_stream/23619/187
11:47 Infinoid rounding errors?
11:47 bacek Infinoid: I'm checking TAP output...
11:49 bacek Ok. floor $N1, $N2 call C floor. Probably on this architecture "C floor" is wrong.
11:49 Whiteknight joined #parrot
11:50 bacek But ../187 looks suspicious.
11:50 bacek set     N25, 1.12589990684262e+15
11:51 bacek Does it handle everything in IMCC without call to Parrot_str_to_num?
11:52 bacek ok found it.
11:55 bacek what the heck is "hppa"?
11:57 Infinoid hp pa-risc
11:58 Infinoid precursor to ia64 I think
11:58 bacek oh...
12:05 bacek ok... looks like there is some problems with floating values on this architecture. Do someone have access to box with openbsd-hppa?
12:06 Infinoid the ticket submitter is probably one of the few in the world :)
12:07 * Infinoid notices we don't have any openbsd entries in PLATFORMS, not even for x86
12:09 bacek Looks like "powl" produces very strange results...
12:10 viklund_ joined #parrot
12:13 iblechbot joined #parrot
12:14 Infinoid looks like the float registers are 64 bits.  it might be an easy test to try using double instead of long double, or something like that
12:15 bacek I asked in ticket for results with "pow" instead of "powl".
12:17 Infinoid cool
12:18 bacek How I can check that parrot has long double?
12:22 Infinoid I don't think you can tell from the smoulder reports, I normally look at config_lib.pasm or the typedefs in include/parrot/config.h
12:23 Infinoid s/smoulder/smolder/
12:23 bacek Is "sizeof(FLOATVAL) == sizeof(HUGEFLOATVAL)" correct?
12:26 Infinoid I know it isn't correct on my platform
12:26 Infinoid I've no idea about openbsd/hppa
12:32 nopaste "bacek" at 114.73.52.125 pasted "Infinoid: can you test this patch?" (31 lines) at http://nopaste.snit.ch/16893
12:33 bacek patch from nopaste passed on my box.
12:33 bacek But I want little bit more coverage...
12:34 Infinoid ok, I can test on linux/amd64
12:35 bacek thanks
12:37 Infinoid #   Failed test 'sqrt_n_n'
12:37 Infinoid #   at t/op/number.t line 1084.
12:37 Infinoid #          got: '1.4142135623731
12:37 Infinoid # 1.41421356237309
12:37 Infinoid # '
12:37 Infinoid #     expected: '1.4142135623731
12:37 Infinoid # 1.4142135623731
12:37 Infinoid # '
12:37 Infinoid minor precision issue, otherwise t/op/number.t passes
12:39 Infinoid oh, that fails without the patch too.  Never mind.
12:40 Infinoid if it matters, my sizeof(float) = 4, sizeof(double) = 8, sizeof(long double) = 16
12:41 bacek hmm...
12:42 kid51 joined #parrot
12:42 bacek Ok, I attached this patch to ticket.
12:46 Infinoid I'm bisecting to find out where this failure started, it's fairly recent
12:47 bacek Merge point.
12:47 Infinoid probably
12:48 bacek commit d52a124471517b38baebdf04919e8831750c1124
12:48 bacek Author: bacek <bacek@d31e2699-5ff4-0310-a27c-f18f2fbe73fe>
12:48 bacek Date:   Sun May 31 22:45:56 2009 +0000
12:48 bacek [t] Remove check for lond double in sqrt_n_n results.
12:48 bacek
12:48 bacek We now parsing floats more precisely so sqrt(2.0) always equal sqrt(2)
12:48 bacek
12:48 bacek git-svn-id: https://svn.parrot.org/parrot/branch​es/tt24_unicode_numifications@39299 d31e2699-5ff4-
12:49 bacek It's not quite true on your platform...
12:49 Infinoid I think we can fix it up with a format string tweak
12:50 Infinoid it is a little weird that intval and numval are treated differently, but not really surprising
12:51 bacek welcome to the dark world of floats...
12:54 bacek -    f = f * sign;
12:54 bacek +    if (sign < 0)
12:54 bacek +        f = -f;
12:54 Infinoid ah.
12:54 bacek Infinoid: can you try this one? (Actually I'm going to commit it right now. It's more correct)
12:55 Infinoid ok, building now
12:56 skids joined #parrot
12:56 bacek *sigh* Two years ago I promised myself never touch floating arithmetic in my life...
12:56 Infinoid that made no difference to t/op/number.t results
12:56 Infinoid hah, better you than me.
12:57 bacek oh...
12:59 ruoso joined #parrot
13:01 ruoso joined #parrot
13:03 nopaste "bacek" at 114.73.52.125 pasted "Infinoid: this probably will work." (16 lines) at http://nopaste.snit.ch/16894
13:04 bacek Infinoid: can you try this nopaste?
13:04 ruoso joined #parrot
13:04 Infinoid ok, sec
13:05 mj41 bacek bisecting? try TapTinder http://tt.ro.vutbr.cz/report/pr-Parr​ot/do?trun-4163=on&amp;trun-4148=on  http://tt.ro.vutbr.cz/repor​t/pr-Parrot/rp-trunk/page-2
13:06 bacek mj41++
13:07 bacek Yeah. tapir2 is 64 bits.
13:08 * bacek don't like idea of using strings to check floating arithmetic...
13:09 Infinoid bacek: http://nopaste.snit.ch/16894 didn't fix that failure, and caused a couple of others
13:09 bacek can you nopaste them?
13:10 nopaste "Infinoid" at 65.18.171.17 pasted "t/op/number.t failures with trunk+http://nopaste.snit.ch/16894" (85 lines) at http://nopaste.snit.ch/16895
13:11 bacek oh shi...
13:13 bacek Ah. Found it!
13:17 nopaste "bacek" at 114.73.52.125 pasted "premature optimisation is root of all evil" (32 lines) at http://nopaste.snit.ch/16896
13:17 bacek Infinoid: care to test this one? :
13:17 Infinoid That's debateable.  Floating point is pretty evil too
13:17 bacek Yeah. -NaN ftw :)
13:18 Infinoid same precision failure in 'sqrt_n_n' test
13:19 bacek yak.
13:20 viklund_ joined #parrot
13:20 dalek TT #759 created by jkeenan++: Reconsider one-test-file-per-PMC policy
13:20 bacek .oO( In theory 2 and 2.0 are equals )
13:20 * bacek smashed by practice
13:21 Infinoid in theory, theory and practice are the same :)
13:23 nopaste "bacek" at 114.73.52.125 pasted "Last attempt." (37 lines) at http://nopaste.snit.ch/16897
13:24 bacek Infinoid: if this patch will not work I'll just relax test...
13:24 Infinoid Still fails.  (sorry)
13:25 * bacek hitting desk with his head.
13:30 dalek TT #760 created by flh++: Interactive sessions with HLLCompiler (and readline) never end
13:32 nopaste "bacek" at 114.73.52.125 pasted "Final last attempt!" (42 lines) at http://nopaste.snit.ch/16898
13:33 bacek Infinoid: this is really-really final
13:34 Infinoid same failure
13:34 * Infinoid adds padding to bacek's desk
13:35 * bacek running in circles screaming
13:37 Infinoid I've got gdb if you want to get more info
13:37 bacek if ((state == parse_before_dot) && m_is_safe)
13:37 Infinoid but I think it's getting late there, and chasing floating point precision issues isn't the funnest thing I can think of to do saturday night :)
13:38 nopaste "bacek" at 114.73.52.125 pasted "Final-final last-last attempt-attempt" (42 lines) at http://nopaste.snit.ch/16899
13:39 bacek If this will not work - I'll tweak test and hang myself...
13:39 Infinoid I'm not even sure the bug is in this part of the code
13:39 Infinoid none of these changes have had any effect
13:40 Infinoid (including this last one)
13:40 bacek yeah... But now we preserve little bit more significant bits.
13:41 * bacek looking for good piece of rope and soap.
13:43 bacek ARGH...
13:43 Whiteknight that's %ARGH
13:43 bacek "N0 = 2" doesn't call Parrot_str_to_num
13:44 bacek Whiteknight: this idea was rejected by TimTaody afair :)
13:59 nopaste "bacek" at 114.73.52.125 pasted "Tweaked test for Infinoid and Whiteknight." (24 lines) at http://nopaste.snit.ch/16900
14:00 bacek I gave up....
14:01 Infinoid Result: PASS
14:02 bacek of cause it PASS...
14:03 * bacek searching for some bandaid for broken head.
14:03 Infinoid Floating Point Considered Harmful
14:04 Infinoid One thing I love about embedded systems: many of them don't have any floating point hardware at all.
14:06 bacek My last project for "embedded system" targeted something like "x86, linux, 16 meg" :)
14:06 bacek And it was 2 years ago. And I promised never touch floating point in my life...
14:07 Infinoid heh
14:08 Infinoid gcc for arm has a -msoft-float argument, it's all emulated internally by the compiler.
14:08 Infinoid or you can say -mhard-float and it's trapped by the kernel and emulated there
14:09 Infinoid the linker doesn't let you mix them, which makes extra work getting $CFLAGS right sometimes, but it's nice to know the hardware isn't to blame (because there is none)
14:09 bacek Looks familiar.
14:11 bacek I've compiled my 20+ klos of C++ code for ARM7 using qemu. All test passed in qemu, but I didn't have chance to run it on real hardware
14:15 Infinoid qemu's emulation is pretty good.  but the hardware varies a lot
14:15 Infinoid wish they made it easier to write new board-type plugins for it
14:18 bacek I know that it's pretty good. At least in floating point emulation :)
14:22 f0rk does anyone know if there are any CSP languages ala Limbo targeting parrot?
14:24 bacek CSP?
14:24 purl hmmm... CSP is the Concordia in St Paul, MN, IIRC.
14:24 Infinoid purl, CSP is also Communicating Sequential Processes
14:24 purl okay, Infinoid.
14:25 f0rk communicating sequential processes
14:25 f0rk beat me to it
14:26 Infinoid The list of languages we currently know of is at https://trac.parrot.org/parrot/wiki/Languages, I'm not aware of any CSP languages on that list (yet)
14:27 bacek Implementing Erlang-on-Parrot is interesting ides.
14:29 crazy_bacek Any volunteers?
14:29 purl Any volunteers are welcome and get beer and pizza.
14:29 bacek s/ides/idea/
14:31 f0rk erlang has hot swapping, can you do that on parrot?
14:33 Infinoid it would need some HLL code, but I don't see why not
14:37 bacek Infinoid: it's not straight forward because such behaviour isn't supported  by parrot. So "s/some/lot" looks more appropriate ::)
14:40 * bacek must sleep
14:40 purl $bacek->sleep(8 * 3600);
14:41 bacek good localtime everyone
14:42 bacek Infinoid: I'll commit test tweak tomorrow Or you can do it if you wish
15:10 kid51 joined #parrot
15:18 Theory joined #parrot
15:20 donaldh joined #parrot
15:48 dalek parrot: r39535 | Infinoid++ | trunk/t/op/number.t:
15:48 dalek parrot: Apply patch from bacek++ to fix a failing test caused by floating point precision differences on x86-64.
15:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39535/
15:51 estrabd joined #parrot
15:54 Whiteknight excellent patch
16:02 elmex joined #parrot
16:06 burmas joined #parrot
16:07 Whiteknight I'm getting a test failure in distro_tests
16:07 Whiteknight anybody else seeing that?
16:07 Whiteknight t/distro/file_metadata.t
16:07 purl t/distro/file_metadata.t is sad
16:07 * Whiteknight doesn't know anything about svn properties, and probably can't fix it himself
16:11 Tene fixed, thanks
16:11 dalek parrot: r39536 | tene++ | trunk/runtime/parrot/library/Curses.pir:
16:11 dalek parrot: File Metadata (Whiteknight++)
16:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39536/
16:11 burmas joined #parrot
16:12 Whiteknight Tene++
16:13 Tene Whiteknight++
16:13 Whiteknight karma for everbody!
16:13 purl everbody! has neutral karma
16:13 Whiteknight everybody++
16:13 Tene everybody!++
16:13 Infinoid karma everybody
16:13 purl everybody has karma of 4
16:13 Infinoid karma everybody!
16:13 purl everybody! has karma of 1
16:14 Infinoid everybody!++
16:14 Tene Infinoid++
16:14 Infinoid Tene++
16:14 Infinoid Whiteknight++
16:15 Whiteknight It seems like the tests are staying very stable, which is good before a release
16:15 Infinoid I've got a few TODO passes in t/op/debuginfo.t
16:19 * Infinoid offline, back later &
16:22 Whiteknight yeah, I get those too
16:22 Whiteknight I think that's an x86-64 thing
16:23 Psyche^ joined #parrot
16:24 Tene It's always interesting to me to see code written by people who aren't active in the project anymore.
16:24 Tene I just discovered creiss, via git-blame.
16:26 Tene anyone know if there's a way I can build and install multis programmatically from PIR?
16:46 HG` joined #parrot
17:42 davidfetter joined #parrot
17:44 chromatic joined #parrot
17:56 Infinoid chromatic: How's the fios treating you?
17:57 chromatic It's more reliable than DSL.  Some things are faster, but those are larger downloads (source code checkouts, aptitude upgrades).
17:58 Infinoid Reliability is good.
17:58 chromatic I had a reliable lack of connectivity almost every afternoon around 2 pm.
18:00 Infinoid hmm... that actually sounds familiar.  Verizon DSL at Lake Tahoe used to drop out for us almost every morning at 8am
18:01 Infinoid (I just got a new place, fios installs this tuesday)
18:02 chromatic I had the guy skip running coax and let me plug my flashed Linksys wireless router into the Ethernet port and haven't had a problem.
18:18 autark joined #parrot
18:29 chromatic Hm, could we fix our order of destruction problems by separating "finalize" and "destroy"?
18:31 Infinoid I like that idea generally, but am not familiar enough with parrot's ordered destruction specifics.  Do we have a test case?
18:31 chromatic Nothing reliable; because it depends on ordering of PMCs in GC arenas, it's susceptible to perturbations in anything that triggers GC.
18:35 Infinoid My first impulse is to say "yes".  As long as we can identify potential problems and use a "look before you leap" strategy in those cases, based on some PObj_finalized_TEST() macro, it should work
18:35 Infinoid But now that I look further, we can probably already do that with PObj_on_free_list_TEST(obj)
18:37 japhb .oO( WTF is Mesa on Gentoo doing with WGL header files ...? )
18:37 Infinoid japhb: Crashing whenever I run mplayer, among other things.
18:37 chromatic After an object is on the free list, it's already lost its vtable pointer (if it's a PMC).
18:37 Infinoid Ok, you'd still need to split delete from destroy
18:38 Infinoid just because you build up the free list at the same time you're calling destruction methods
18:39 japhb OK, are there typedefs for BOOL and HANDLE and such among your system's .h's?
18:39 chromatic During global destruction, we could sweep the pools, finalize everything, and then sweep them again to destroy everything.
18:39 chromatic finalize, then free
18:39 chromatic destroy, then delete
18:39 japhb Otherwise I'm going to need a windows person to cough up their system headers ....
18:39 chromatic Alliteration is important.
18:40 Infinoid japhb: Not that I can find.  I think it's an overzealous installer, and that those files are never supposed to be included
18:43 Infinoid So we're looking at 2-staged deletion as a means of papering over PMCs which blindly call vtables in other PMCs without checking for deletion
18:43 chromatic It's not blindly calling them.  Look at EventHandler, for example.
18:43 chromatic EventScheduler I mean.
18:44 chromatic It's not written as if it were nice to be able to refer to other PMCs.  It's written because it's necessary to refer to other PMCs.
18:46 Infinoid I seem to recall some PMC (I'm trying to remember which one) which had a PMC* ATTR and whose destroy() method called VTABLE_something on that attr, thus assuming the other PMC was still alive
18:46 Infinoid EventHandler doesn't look problematic
18:47 Infinoid ack can't find any EventScheduler
18:47 chromatic It's just Scheduler.  I'm disorganized this morning.
18:48 Infinoid We could just say "thou shalt not call any vtable functions on thine pmc attrs", which seems like a simpler solution to that particular class of ordered destruction issue.
18:49 Infinoid but I think I'd be able to talk more intelligently about this issue if I had an example
18:49 chromatic Hm, Scheduler isn't it either.
18:50 chromatic FileHandle looks problematic.
18:51 autark joined #parrot
18:52 chromatic Ah, it's Timer.
18:52 Infinoid purl, irclog?
18:52 purl rumour has it irclog is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
18:55 Infinoid We last discussed this on http://irclog.perlgeek.de/parrot/2009-05-19.  Unfortunately the nopaste link has fallen off the web, but someone was calling Parrot_PCCINVOKE from within their destroy(), causing a t/pmc/io.t failure
18:56 chromatic Right.  Now IO doesn't use as many PMCs.
18:57 Infinoid Ah, google cache.  http://74.125.47.132/search?q=cache:ZmIpspLMzlQJ​:nopaste.snit.ch/16603+netbsd+sparc64+parrot_pcc​invoke&amp;cd=1&amp;hl=en&amp;ct=clnk&amp;gl=us
18:57 Infinoid Well, it doesn't use PCCINVOKE as often...
18:57 Util purl, forget infrared clogs
18:57 purl Util: I forgot infrared clogs
18:58 Util purl, irclog?
18:58 purl i heard irclog was http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
18:58 Infinoid Now the pointer is dangling. :)
18:59 Util Infinoid: any way to remove the i.c. answer?
18:59 Infinoid no, irclog is http://irclog.perlgeek.de/parrot/today
18:59 purl okay, Infinoid.
18:59 Infinoid purl, irclog?
18:59 purl hmmm... irclog is http://irclog.perlgeek.de/parrot/today
19:00 Util thanks!
19:01 Infinoid I don't think we've really fixed any issues here, with regards to I/O handles.
19:01 Infinoid We're trying to be a little smarter about whether to call using vtable or PCC, but that's all
19:02 chromatic Right.
19:03 Infinoid Of course, we could just add "destroyed object" to the list of special cases for those I/O calls.
19:03 chromatic That reads like it might not flush unwritten data if we do that.
19:05 Infinoid Yeah.  Definitely looking for a better alternative
19:08 sjn ,
19:08 chromatic I despair of telling PMC authors "Don't do anything which might invoke a vtable entry in your destroy()".  That's subtle.
19:10 Infinoid Well, if you're declaring a custom destroy handler, you're taking your life into your own hands anyway
19:10 chromatic I don't think that has to be the case.
19:11 Infinoid I'm looking at a parrot checkout from 2009-05-19, and I don't understand this backtrace
19:11 Infinoid These functions should all be referring to the same PMC pointer, but it changed in Parrot_io_is_closed
19:11 Infinoid I don't think calling a vtable entry on yourself should be a problem; and two-stage deletion will only have an effect for inter-PMC dependencies
19:13 Infinoid oh, no, I'm an idiot.  Yes, interp != pmc.
19:15 Infinoid It's the object returned by VTABLE_find_method() that had already been freed.
19:18 chromatic I may have just killed dalek.
19:19 Infinoid So in this case, two-stage destruction would have fixed this.  Maybe.  FileHandle does declare its own mark() and doesn't call SUPER(); does Class's mark() get called so it can preserve the method PMCs?
19:19 dalek parrot: r39537 | chromatic++ | trunk/src/gc/gc_ms.c:
19:19 dalek parrot: [GC] Revised GC pool replenish level calculations.  The previous change in
19:19 dalek parrot: r39215 had the unfortunate property of skipping the next mark and sweep if the
19:19 dalek parrot: current mark and sweep freed up enough pool items to meet or exceed the
19:19 dalek parrot: replenish threshold.  Of course, if the next time the GC runs is because the
19:19 dalek parrot: system has run out of those pool items, there's no choice but to allocate a new
19:19 dalek parrot: arena in the pool, increasing memory usage.
19:19 dalek parrot: This version of the algorithm avoids the skip and instead uses the replenish
19:19 dalek parrot: level to decide whether to allocate a new arena if the sweep didn't free enough
19:19 dalek parrot: pool items to meet the replenish level.  This results in no ballooning
19:19 dalek parrot: allocations when one GCable type is both the constraint and frequently
19:19 dalek parrot: recyclable and only a slight performance reduction over the
19:19 dalek parrot: sometimes-pathological case in r39215.  (That's fixable by not immediately
19:19 dalek parrot: populating the free list from a freshly-allocated arena.)
19:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39537/
19:20 chromatic I don't think we'd have to preserve them.
19:20 donaldh joined #parrot
19:20 Infinoid For FileHandles, no.  I'm worried about subclasses
19:21 chromatic I can't imagine any problems ther.
19:21 chromatic there
19:22 Infinoid chromatic++ # great commit message
19:23 Infinoid I need to think this through, I'll probably write some filehandle-pir-subclassing tests during that process.  If they pass, great.  If not, I'll make a ticket
19:24 * Infinoid is very keen on Socket subclassing for (e.g.) ssl
19:58 Theory joined #parrot
20:03 contingencyplan joined #parrot
20:22 Limbic_Region joined #parrot
20:35 ZeroForce joined #parrot
21:11 Theory joined #parrot
21:12 bacek joined #parrot
21:31 bacek morning. good morning
21:57 Coke chromatic: should that last GC fix be another tcl improvement?
21:57 Coke also, did you see partcl blog post?
21:57 Coke chromatic+
21:57 Coke chromatic++
21:58 bacek chromatic+++
21:58 bacek o wait...
22:02 chromatic Coke, a minor one.
22:05 Coke chromatic: danke.
22:05 chromatic You're welcome.
22:06 bacek chromatic: I finally understood (fsvo) Keys.
22:07 bacek Biggest problem with Keys (from my POV) they used for 2 very different things.
22:07 bacek 1. Describing path in nested aggregates.
22:08 bacek 2. Iterate over aggregates.
22:08 chromatic Exactly.
22:08 bacek My .plan for deuglyfying them:
22:08 bacek 1. Use keys only for paths.
22:08 bacek 2. Made Iterator pure interface class.
22:09 bacek 3. Implement HashIterator and ArrayIterator.
22:09 chromatic That sounds reasonable.
22:09 bacek 4. Use MULTIs for handling PMC/Key in (set|get)_*_keyed
22:10 bacek 5. Remove all code left in Keys for support iterators.
22:10 bacek Any ideas objections?
22:11 bacek s/ / or /
22:12 chromatic #4 is the only part that concerns me at all, but 1 - 3, 5 are independent of that.
22:12 bacek (I will need HashIteratorKey though)
22:12 bacek What's wrong with #4?
22:13 chromatic It's a little more invasive.  That's all.
22:14 bacek Why? We have switch-based multi-to-vtable "optimiser".
22:15 bacek msg Whiteknight You can check with allison++ and probably close TT#452
22:15 chromatic Because I think that treating String PMCs, Keys, and RSAs as equivalent as Keys is a design flaw, not an implementation detail.
22:15 purl Message for whiteknight stored.
22:15 Zak joined #parrot
22:16 bacek it's only in Namespace. Not in Hash by itself
22:18 bacek Hash only handle Keys differently.
22:22 chromatic That's good.
22:22 Util On my non-icu-enabled 10.4 darwin laptop, `make test` is failing t/op/stringu.t 29-31. (r39537)
22:22 chromatic My biggest problem with Key is that it could contain so many different types of data it has to check on every access to figure out what to produce.
22:22 Util Are we requiring ICU now, or does the test just need to SKIP (or TODO) those 3 tests when ICU is not configured?
22:22 chromatic Util, it should skip those tests without ICU.
22:22 bacek Ok, I'll put this as RFC ticket and create branch for it.
22:22 chromatic I need to go to a meeting now though.
22:28 dalek TT #761 created by bacek++: [RFC] Keys/Iterator deuglyfying.
22:33 rg1 joined #parrot
22:45 dalek parrot: r39538 | bacek++ | trunk/src/string/api.c:
22:45 dalek parrot: [cage] Don't use multiplication to change sign in str_to_num. Just change sign.
22:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39538/
22:45 dalek parrot: r39539 | bacek++ | trunk/t/op/stringu.t:
22:45 dalek parrot: [t][cage] Skip unicode tests when no ICU available. Util++, chromatic++, bacek--.
22:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39539/
22:46 bacek msg mj41 Can you colour "failed" column in red on http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk?
22:46 purl Message for mj41 stored.
22:53 dalek rakudo: 77f9d70 | pmichaud++ | docs/ (2 files):
22:53 dalek rakudo: Some more updates in preparation for Thursday's release.
22:53 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​7f9d7094ae9fef8664cdb154fb8510617a4bd13
22:58 mj41 time to sleep, archive file extracting implemented in TapTinder ... try to click on 'bonus', 'ok' in diffs e.g. http://tt.ro.vutbr.cz/report/pr-Parr​ot/do?trun-4254=on&amp;trun-4252=on
23:00 mj41 bacek np, tomorrow, thank for first TapTinder request :-)
23:00 bacek mj41: it's second one :) First was for more platforms
23:02 bacek mj41++ # TapTinder rocks
23:02 mj41 ok, I plan another win32s (32bit, cygwin, ... ) and opensolaris ... all on vmware
23:03 mj41 thanks, and good night
23:05 bacek good night
23:11 dalek parrot: r39540 | Infinoid++ | branches/io_rewiring:
23:11 dalek parrot: This branch has been merged back to trunk; remove it.
23:11 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39540/
23:11 ruoso joined #parrot
23:20 donaldh joined #parrot

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced