Parrot 1.2.0 released | parrot.org/ | Weekly Priority: Profiling | Parrot VM Workshop, Pittsburgh, June 20-21
Set by moderator on 7 June 2009.
chromatic Coke, that might be a win for you. 00:00
Coke damn is feather slow. 00:01
bacek: Thuesday? 00:13
Infinoid ENOBACEK
Coke msg bacek Thuesday? 00:14
purl Message for bacek stored.
Infinoid oh, heh. I had originally read that as "thursday"
Coke is it possible to make a constant RPA? 00:15
Coke digs for .const
chromatic I don't know how you'd initialize it. 00:16
You'd probably have to declare all of its contents as .const too.
cotto Coke, you could make it ro 00:22
Coke I don't care if it's editable (i just won't edit it.)
chromatic You want it constant and compile-time so. 00:26
nopaste "coke" at 72.228.52.192 pasted "something like this." (18 lines) at nopaste.snit.ch/16888 00:28
Coke that doesn't work, but that sort of thign. 00:30
Bus Error! 00:32
purl Go take a walk.
dalek TT #756 created by coke++: invalid PMC causes bus error with const. 00:36
nopaste "coke" at 72.228.52.192 pasted "this fails on instantiate_str() ." (18 lines) at nopaste.snit.ch/16889 00:37
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
"doing"
chromatic There's a fix for nopaste.snit.ch/16887 . Ugh. 00:45
Whiteknight chromatic: does that snippet cause a problem? 00:50
chromatic r39125 was the culprit.
Coke I always knew consting was evil. 00:51
chromatic I think the fix for that will help Coke tremendously. 00:52
Coke here's hoping.
I presume you're not just reverting 39125, then.
chromatic Nope. 00:53
I don't want to lose the performance gain.
00:57 diegoviola joined
diegoviola hi, is parrot ready for production use? 00:57
Coke FSOV production.
diegoviola ?
Coke "for some values of"
diegoviola if we'd like to embedd parrot in some platforms, such as this: www.freeswitch.org 00:58
and apache, etc
Coke There is a 1.0 that is considered stable.
for apache, see "mod_parrot"
that project is well underway and already supporting higher level languages like perl6.
diegoviola i see 00:59
well, thanks for the info
parrot seems to be really interesting
how does it compares to something like java or mono?
i don't like either of those
is it comparable? 01:00
or they are different things?
for different purposes i mean
Coke There's a FAQ on that. 01:01
diegoviola ok
01:02 ZeroForce joined
Infinoid How would you plug parrot into freeswitch? 01:03
chromatic Hm, the problem is that pool->num_free_objects is very, very wrong.
diegoviola so it's stack-based vs register-based?
Whiteknight parrot is register-based 01:04
tewk ====================================================================================================================================================================/
Whiteknight ?
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)
Infinoid: and i don't want to use either of those
tewk zQ,m ~m3~
]\\'''''''''''''''''''''''''''''''y'y']'6y']]']]]
diegoviola Infinoid: they asked me if it was embeddable 01:05
Coke tewk's cat is in town.
Infinoid diegoviola: We have an embedding API which is sorely in need of more users
diegoviola Infinoid: is there a link on that on the web site? 01:06
Whiteknight I think tewk is broken
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)
diegoviola www.parrotcode.org/docs/embed.html ?
ok thanks
Whiteknight goodnight 01:08
Infinoid parrotcode.org is outdated
diegoviola ok
Infinoid docs.parrot.org/parrot/latest/html/...d.pod.html
pmichaud chromatic: Should I go ahead and file a ticket for nopaste 16887?
Infinoid docs.parrot.org/parrot/latest/html/...g.pod.html
diegoviola yep, thanks
Coke pmichaud: couldn't hoit. 01:09
chromatic pmichaud, I can fix it the easy way, but I want to keep performance where it was. 01:10
pmichaud what's the easy way fix? 01:12
01:13 whoppix joined
Infinoid The easy way is probably reverting r39125 01:13
pmichaud checks 39125 01:14
Coke I'm surprised that consting would do that.
is it putting something into the constant pool and then not getting freed?
chromatic r39215 I meant. 01:15
Infinoid oh
Coke that's much more likely. =-)
dyslexic much?
pmichaud chromatic: I wonder if the reason that Rakudo is 6.79% faster is because there aren't any GCs taking place. 01:16
chromatic Yep. 01:17
pool->num_free_objects is very, very wrong for some reason.
pmichaud #define GC_DEBUG_REPLENISH_LEVEL_FACTOR 0.0 01:18
that looks odd.
chromatic That's only for GC debugging. 01:19
pmichaud ah, right.
okay.
chromatic I'm running the test suite now, but it should be okay. 01:20
A smarter GC wouldn't have had a problem here. 01:23
But whenever we allocate a new pool, we write to it and turn virtual memory into process memory. 01:24
Coke, Tcl may fare far better now.
dalek rrot: r39531 | chromatic++ | trunk/src/gc/gc_ms.c:
[GC] Reverted r39215, which caused the GC to allocate more pools unnecessarily
01:30 Hunger- joined
Coke chromatic: trying one of the spec tests that exploded now. 01:32
memory usage is INSANELY better. 01:34
much better, thanks. 01:37
I'll try all the out of memory ones, unskip them, and do a full run.
mathop.test alone (my test case) gets me another 158 passes. 01:38
of course, now the ones that leak memory slowly take a LONG time to fail. =-) 01:44
hurm. the tests are not magically completing. 02:18
I'll unskip all the ones I can.
02:30 cognominal joined 02:35 Theory joined
diegoviola so does parrot has the potential to replace mono or java? 03:01
even if it's not it's goal
i mean, in a technolgy way
technology
purl philosophy
diegoviola yep but as a technology, can it compete against those? 03:02
in the market today
Coke purl is a bot, btw. 03:05
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?
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.
diegoviola: I'm /typing/ =-)
diegoviola ok
Coke diegoviola: (register based) again, that was a FAQ. That was the supposition, yes.
see docs/faq.pod 03:17
diegoviola thanks
03:17 Zak joined
Coke I'm not sure why that doc isn't visible on docs.parrot.org 03:18
03:20 Maddingu1 joined
Coke chromatic++ 03:20
chromatic-- # for breaking it in the first place.
03:21 donaldh joined
Coke Pretty sure his fix has won me about 750 more passing tests. 03:21
750 / 2162
purl 0.346901017576318
03:27 zak_ joined
pmichaud it's also exposing some GC problems in Rakudo. 03:35
dalek kudo: 4d21e2a | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION.
 03:40
Coke hurm. any idea why code.google.com/p/partcl/source/bro...spectcl.in isn't showing the PANIC in the .results file when it's done? 03:55
bah. it does sometimes. nevermind. 03:57
dalek rtcl: r483 | coke++ | wiki/SpecTestStatus.wiki:
chromatic++ # actually running the GC helps us stay under the limit.
 04:01
04:23 eternaleye joined 04:36 mikehh_ joined 04:39 Theory joined 04:43 eternaleye joined 04:57 eternaleye joined 05:10 Theory joined
dalek rtcl: r484 | coke++ | trunk/docs/spectest- (2 files):
Reclaim several more test files after chromatic++'s recent GC fix.
 05:24
Coke msg chromatic code.google.com/p/partcl/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.
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.
Coke purl 4374 / 60 / 60 ?
purl i haven't a clue, coke
Coke purl 4374 / 60 / 60
purl 1.215
cotto that many hours to run the spec tests? 05:47
05:53 eternaleye joined
dalek rrot: r39532 | tene++ | trunk/runtime/parrot/languages/parrot/parrot.pir:
[languages/parrot]:
 06:04
rrot: r39533 | tene++ | trunk/runtime/parrot/library/Curses.pir:
Add a curses lib Curses.pir (copied from ncurses.pir) that can be used from HLLs.
 06:11
rrot: r39534 | tene++ | trunk (2 files):
SVN metadata and MANIFEST.
 06:14
Coke cotto: (hours) yes.
06:38 f0rk joined
f0rk I have a question about threading and multicore in parrot 06:44
what support for these features will parrot have? 06:45
Tene Parrot currently supports threading. 06:48
f0rk I see 06:49
is there somewhere in the docs where I could read more about it?
06:49 viklund_ joined
Tene docs/pdds/pdd25_concurrency.pod should be a decent start 06:50
also docs/pdds/pdd24_events.pod
also look at the tests
f0rk thanks!
Tene t/pmc/threads.t 06:51
iirc
did you have any more-specific questions?
f0rk not at the moment
Tene Feel free to ask at any time. :)
07:10 f0rk joined 07:20 donaldh joined
japhb Tene: thanks for the catch in t39534. 07:29
er r39534, of course
07:41 cowens joined 07:46 cowens left
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 08:26 barney joined 08:32 chromatic joined
dalek TT #758 created by reezer++: Fix problems o openbsd/hppa 08:32
kudo: e167c92 | moritz++ | t/spectest.data:
3 more files for spectest.t
 11:05
nopaste "Infinoid" at 65.18.171.17 pasted "More opengl configuration warnings on gentoo/amd64 (yes, I upgraded mesa recently)" (274 lines) at nopaste.snit.ch/16892 11:10
11:20 donaldh joined
Infinoid msg bacek Please take a look at TT #758. According to smolder.plusthree.com/app/public_pr...a-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 smolder.plusthree.com/app/public_pr.../23630/187 11:29
purl Message for bacek stored.
11:36 bacek joined
bacek o hai 11:43
Infinoid hey :) 11:44
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
smolder.plusthree.com/app/public_pr...23619/162, smolder.plusthree.com/app/public_pr.../23619/187
rounding errors? 11:47
bacek Infinoid: I'm checking TAP output...
Ok. floor $N1, $N2 call C floor. Probably on this architecture "C floor" is wrong. 11:49
11:49 Whiteknight joined
bacek But ../187 looks suspicious. 11:50
set N25, 1.12589990684262e+15
Does it handle everything in IMCC without call to Parrot_str_to_num? 11:51
ok found it. 11:52
what the heck is "hppa"? 11:55
Infinoid hp pa-risc 11:57
precursor to ia64 I think 11:58
bacek oh...
ok... looks like there is some problems with floating values on this architecture. Do someone have access to box with openbsd-hppa? 12:05
Infinoid the ticket submitter is probably one of the few in the world :) 12:06
Infinoid notices we don't have any openbsd entries in PLATFORMS, not even for x86 12:07
bacek Looks like "powl" produces very strange results... 12:09
12:10 viklund_ joined 12:13 iblechbot joined
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:14
bacek I asked in ticket for results with "pow" instead of "powl". 12:15
Infinoid cool 12:17
bacek How I can check that parrot has long double? 12:18
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:22
s/smoulder/smolder/ 12:23
bacek Is "sizeof(FLOATVAL) == sizeof(HUGEFLOATVAL)" correct?
Infinoid I know it isn't correct on my platform 12:26
I've no idea about openbsd/hppa
nopaste "bacek" at 114.73.52.125 pasted "Infinoid: can you test this patch?" (31 lines) at nopaste.snit.ch/16893 12:32
bacek patch from nopaste passed on my box. 12:33
But I want little bit more coverage...
Infinoid ok, I can test on linux/amd64 12:34
bacek thanks 12:35
Infinoid # Failed test 'sqrt_n_n' 12:37
# at t/op/number.t line 1084.
# got: '1.4142135623731
# 1.41421356237309
# '
# expected: '1.4142135623731
# 1.4142135623731
# '
minor precision issue, otherwise t/op/number.t passes
oh, that fails without the patch too. Never mind. 12:39
if it matters, my sizeof(float) = 4, sizeof(double) = 8, sizeof(long double) = 16 12:40
bacek hmm... 12:41
12:42 kid51 joined
bacek Ok, I attached this patch to ticket. 12:42
Infinoid I'm bisecting to find out where this failure started, it's fairly recent 12:46
bacek Merge point. 12:47
Infinoid probably
bacek commit d52a124471517b38baebdf04919e8831750c1124 12:48
Author: bacek <bacek@d31e2699-5ff4-0310-a27c-f18f2fbe73fe>
Date: Sun May 31 22:45:56 2009 +0000
[t] Remove check for lond double in sqrt_n_n results.
We now parsing floats more precisely so sqrt(2.0) always equal sqrt(2)
git-svn-id: svn.parrot.org/parrot/branches/tt2...ions@39299 d31e2699-5ff4-
It's not quite true on your platform... 12:49
Infinoid I think we can fix it up with a format string tweak
it is a little weird that intval and numval are treated differently, but not really surprising 12:50
bacek welcome to the dark world of floats... 12:51
- f = f * sign; 12:54
+ if (sign < 0)
+ f = -f;
Infinoid ah.
bacek Infinoid: can you try this one? (Actually I'm going to commit it right now. It's more correct)
Infinoid ok, building now 12:55
12:56 skids joined
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
hah, better you than me.
bacek oh... 12:57
12:59 ruoso joined 13:01 ruoso joined
nopaste "bacek" at 114.73.52.125 pasted "Infinoid: this probably will work." (16 lines) at nopaste.snit.ch/16894 13:03
bacek Infinoid: can you try this nopaste? 13:04
13:04 ruoso joined
Infinoid ok, sec 13:04
mj41 bacek bisecting? try TapTinder tt.ro.vutbr.cz/report/pr-Parrot/do?...un-4148=on tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk/page-2 13:05
bacek mj41++ 13:06
Yeah. tapir2 is 64 bits. 13:07
bacek don't like idea of using strings to check floating arithmetic... 13:08
Infinoid bacek: nopaste.snit.ch/16894 didn't fix that failure, and caused a couple of others 13:09
bacek can you nopaste them?
nopaste "Infinoid" at 65.18.171.17 pasted "t/op/number.t failures with trunk+nopaste.snit.ch/16894" (85 lines) at nopaste.snit.ch/16895 13:10
bacek oh shi... 13:11
Ah. Found it! 13:13
nopaste "bacek" at 114.73.52.125 pasted "premature optimisation is root of all evil" (32 lines) at nopaste.snit.ch/16896 13:17
bacek Infinoid: care to test this one? :
Infinoid That's debateable. Floating point is pretty evil too
bacek Yeah. -NaN ftw :)
Infinoid same precision failure in 'sqrt_n_n' test 13:18
bacek yak. 13:19
13:20 viklund_ joined
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 )
bacek smashed by practice
Infinoid in theory, theory and practice are the same :) 13:21
nopaste "bacek" at 114.73.52.125 pasted "Last attempt." (37 lines) at nopaste.snit.ch/16897 13:23
bacek Infinoid: if this patch will not work I'll just relax test... 13:24
Infinoid Still fails. (sorry)
bacek hitting desk with his head. 13:25
dalek TT #760 created by flh++: Interactive sessions with HLLCompiler (and readline) never end 13:30
nopaste "bacek" at 114.73.52.125 pasted "Final last attempt!" (42 lines) at nopaste.snit.ch/16898 13:32
bacek Infinoid: this is really-really final 13:33
Infinoid same failure 13:34
Infinoid adds padding to bacek's desk
bacek running in circles screaming 13:35
Infinoid I've got gdb if you want to get more info 13:37
bacek if ((state == parse_before_dot) && m_is_safe)
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 :)
nopaste "bacek" at 114.73.52.125 pasted "Final-final last-last attempt-attempt" (42 lines) at nopaste.snit.ch/16899 13:38
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
none of these changes have had any effect
(including this last one) 13:40
bacek yeah... But now we preserve little bit more significant bits.
bacek looking for good piece of rope and soap. 13:41
ARGH... 13:43
Whiteknight that's %ARGH
bacek "N0 = 2" doesn't call Parrot_str_to_num
Whiteknight: this idea was rejected by TimTaody afair :) 13:44
nopaste "bacek" at 114.73.52.125 pasted "Tweaked test for Infinoid and Whiteknight." (24 lines) at nopaste.snit.ch/16900 13:59
bacek I gave up.... 14:00
Infinoid Result: PASS 14:01
bacek of cause it PASS... 14:02
bacek searching for some bandaid for broken head. 14:03
Infinoid Floating Point Considered Harmful
One thing I love about embedded systems: many of them don't have any floating point hardware at all. 14:04
bacek My last project for "embedded system" targeted something like "x86, linux, 16 meg" :) 14:06
And it was 2 years ago. And I promised never touch floating point in my life...
Infinoid heh 14:07
gcc for arm has a -msoft-float argument, it's all emulated internally by the compiler. 14:08
or you can say -mhard-float and it's trapped by the kernel and emulated there
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.
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:11
Infinoid qemu's emulation is pretty good. but the hardware varies a lot 14:15
wish they made it easier to write new board-type plugins for it
bacek I know that it's pretty good. At least in floating point emulation :) 14:18
f0rk does anyone know if there are any CSP languages ala Limbo targeting parrot? 14:22
bacek CSP? 14:24
purl hmmm... CSP is the Concordia in St Paul, MN, IIRC.
Infinoid purl, CSP is also Communicating Sequential Processes
purl okay, Infinoid.
f0rk communicating sequential processes 14:25
beat me to it
Infinoid The list of languages we currently know of is at trac.parrot.org/parrot/wiki/Languages, I'm not aware of any CSP languages on that list (yet) 14:26
bacek Implementing Erlang-on-Parrot is interesting ides. 14:27
crazy_bacek Any volunteers? 14:29
purl Any volunteers are welcome and get beer and pizza.
bacek s/ides/idea/
f0rk erlang has hot swapping, can you do that on parrot? 14:31
Infinoid it would need some HLL code, but I don't see why not 14:33
bacek Infinoid: it's not straight forward because such behaviour isn't supported by parrot. So "s/some/lot" looks more appropriate ::) 14:37
bacek must sleep 14:40
purl $bacek->sleep(8 * 3600);
bacek good localtime everyone 14:41
Infinoid: I'll commit test tweak tomorrow Or you can do it if you wish 14:42
15:10 kid51 joined 15:18 Theory joined 15:20 donaldh joined
dalek rrot: r39535 | Infinoid++ | trunk/t/op/number.t:
Apply patch from bacek++ to fix a failing test caused by floating point precision differences on x86-64.
 15:48
15:51 estrabd joined
Whiteknight excellent patch 15:54
16:02 elmex joined 16:06 burmas joined
Whiteknight I'm getting a test failure in distro_tests 16:07
anybody else seeing that?
t/distro/file_metadata.t
purl t/distro/file_metadata.t is sad
Whiteknight doesn't know anything about svn properties, and probably can't fix it himself
Tene fixed, thanks 16:11
dalek rrot: r39536 | tene++ | trunk/runtime/parrot/library/Curses.pir:
File Metadata (Whiteknight++)
16:11 burmas joined
Whiteknight Tene++ 16:12
Tene Whiteknight++ 16:13
Whiteknight karma for everbody!
purl everbody! has neutral karma
Whiteknight everybody++
Tene everybody!++
Infinoid karma everybody
purl everybody has karma of 4
Infinoid karma everybody!
purl everybody! has karma of 1
Infinoid everybody!++ 16:14
Tene Infinoid++
Infinoid Tene++
Whiteknight++
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
Infinoid offline, back later & 16:19
Whiteknight yeah, I get those too 16:22
I think that's an x86-64 thing
16:23 Psyche^ joined
Tene It's always interesting to me to see code written by people who aren't active in the project anymore. 16:24
I just discovered creiss, via git-blame.
anyone know if there's a way I can build and install multis programmatically from PIR? 16:26
16:46 HG` joined 17:42 davidfetter joined 17:44 chromatic joined
Infinoid chromatic: How's the fios treating you? 17:56
chromatic It's more reliable than DSL. Some things are faster, but those are larger downloads (source code checkouts, aptitude upgrades). 17:57
Infinoid Reliability is good. 17:58
chromatic I had a reliable lack of connectivity almost every afternoon around 2 pm.
Infinoid hmm... that actually sounds familiar. Verizon DSL at Lake Tahoe used to drop out for us almost every morning at 8am 18:00
(I just got a new place, fios installs this tuesday) 18:01
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:02
18:18 autark joined
chromatic Hm, could we fix our order of destruction problems by separating "finalize" and "destroy"? 18:29
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.
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
But now that I look further, we can probably already do that with PObj_on_free_list_TEST(obj)
japhb
.oO( WTF is Mesa on Gentoo doing with WGL header files ...? )
 18:37
Infinoid japhb: Crashing whenever I run mplayer, among other things.
chromatic After an object is on the free list, it's already lost its vtable pointer (if it's a PMC).
Infinoid Ok, you'd still need to split delete from destroy
just because you build up the free list at the same time you're calling destruction methods 18:38
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.
finalize, then free
destroy, then delete
japhb Otherwise I'm going to need a windows person to cough up their system headers ....
chromatic Alliteration is important.
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:40
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.
EventScheduler I mean.
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:44
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
EventHandler doesn't look problematic
ack can't find any EventScheduler 18:47
chromatic It's just Scheduler. I'm disorganized this morning.
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:48
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.
FileHandle looks problematic. 18:50
18:51 autark joined
chromatic Ah, it's Timer. 18:52
Infinoid purl, irclog?
purl rumour has it irclog is irclog.perlgeek.de/parrot/today or see also: infrared clogs
Infinoid We last discussed this on 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:55
chromatic Right. Now IO doesn't use as many PMCs. 18:56
Infinoid Ah, google cache. 74.125.47.132/search?q=cache:ZmIpsp...&gl=us 18:57
Well, it doesn't use PCCINVOKE as often...
Util purl, forget infrared clogs
purl Util: I forgot infrared clogs
Util purl, irclog? 18:58
purl i heard irclog was irclog.perlgeek.de/parrot/today or see also: infrared clogs
Infinoid Now the pointer is dangling. :)
Util Infinoid: any way to remove the i.c. answer? 18:59
Infinoid no, irclog is irclog.perlgeek.de/parrot/today
purl okay, Infinoid.
Infinoid purl, irclog?
purl hmmm... irclog is irclog.perlgeek.de/parrot/today
Util thanks! 19:00
Infinoid I don't think we've really fixed any issues here, with regards to I/O handles. 19:01
We're trying to be a little smarter about whether to call using vtable or PCC, but that's all
chromatic Right. 19:02
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.
Infinoid Yeah. Definitely looking for a better alternative 19:05
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.
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.
Infinoid I'm looking at a parrot checkout from 2009-05-19, and I don't understand this backtrace 19:11
These functions should all be referring to the same PMC pointer, but it changed in Parrot_io_is_closed
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
oh, no, I'm an idiot. Yes, interp != pmc. 19:13
It's the object returned by VTABLE_find_method() that had already been freed. 19:15
chromatic I may have just killed dalek. 19:18
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 rrot: r39537 | chromatic++ | trunk/src/gc/gc_ms.c:
[GC] Revised GC pool replenish level calculations. The previous change in

current mark and sweep freed up enough pool items to meet or exceed the replenish threshold. Of course, if the next time the GC runs is because the system has run out of those pool items, there's no choice but to allocate a new arena in the pool, increasing memory usage. This version of the algorithm avoids the skip and instead uses the replenish level to decide whether to allocate a new arena if the sweep didn't free enough pool items to meet the replenish level. This results in no ballooning allocations when one GCable type is both the constraint and frequently recyclable and only a slight performance reduction over the sometimes-pathological case in r39215. (That's fixable by not immediately populating the free list from a freshly-allocated arena.)
chromatic I don't think we'd have to preserve them. 19:20
19:20 donaldh joined
Infinoid For FileHandles, no. I'm worried about subclasses 19:20
chromatic I can't imagine any problems ther. 19:21
there
Infinoid chromatic++ # great commit message 19:22
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:23
Infinoid is very keen on Socket subclassing for (e.g.) ssl 19:24
19:58 Theory joined 20:03 contingencyplan joined 20:22 Limbic_Region joined 20:35 ZeroForce joined 21:11 Theory joined 21:12 bacek joined
bacek morning. good morning 21:31
Coke chromatic: should that last GC fix be another tcl improvement? 21:57
also, did you see partcl blog post?
chromatic+
chromatic++
bacek chromatic+++ 21:58
o wait...
chromatic Coke, a minor one. 22:02
Coke chromatic: danke. 22:05
chromatic You're welcome.
bacek chromatic: I finally understood (fsvo) Keys. 22:06
Biggest problem with Keys (from my POV) they used for 2 very different things. 22:07
1. Describing path in nested aggregates.
2. Iterate over aggregates. 22:08
chromatic Exactly.
bacek My .plan for deuglyfying them:
1. Use keys only for paths.
2. Made Iterator pure interface class.
3. Implement HashIterator and ArrayIterator. 22:09
chromatic That sounds reasonable.
bacek 4. Use MULTIs for handling PMC/Key in (set|get)_*_keyed
5. Remove all code left in Keys for support iterators. 22:10
Any ideas objections?
s/ / or / 22:11
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)
What's wrong with #4?
chromatic It's a little more invasive. That's all. 22:13
bacek Why? We have switch-based multi-to-vtable "optimiser". 22:14
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.
purl Message for whiteknight stored.
22:15 Zak joined
bacek it's only in Namespace. Not in Hash by itself 22:16
Hash only handle Keys differently. 22:18
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)
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.
Util Are we requiring ICU now, or does the test just need to SKIP (or TODO) those 3 tests when ICU is not configured?
chromatic Util, it should skip those tests without ICU.
bacek Ok, I'll put this as RFC ticket and create branch for it.
chromatic I need to go to a meeting now though.
dalek TT #761 created by bacek++: [RFC] Keys/Iterator deuglyfying. 22:28
22:33 rg1 joined
dalek rrot: r39538 | bacek++ | trunk/src/string/api.c:
[cage] Don't use multiplication to change sign in str_to_num. Just change sign.
 22:45
rrot: r39539 | bacek++ | trunk/t/op/stringu.t:
[t][cage] Skip unicode tests when no ICU available. Util++, chromatic++, bacek--.
bacek msg mj41 Can you colour "failed" column in red on tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk? 22:46
purl Message for mj41 stored.
dalek kudo: 77f9d70 | pmichaud++ | docs/ (2 files):
Some more updates in preparation for Thursday's release.
 22:53
mj41 time to sleep, archive file extracting implemented in TapTinder ... try to click on 'bonus', 'ok' in diffs e.g. tt.ro.vutbr.cz/report/pr-Parrot/do?...un-4252=on 22:58
bacek np, tomorrow, thank for first TapTinder request :-) 23:00
bacek mj41: it's second one :) First was for more platforms
mj41++ # TapTinder rocks 23:02
mj41 ok, I plan another win32s (32bit, cygwin, ... ) and opensolaris ... all on vmware
thanks, and good night 23:03
bacek good night 23:05
dalek rrot: r39540 | Infinoid++ | branches/io_rewiring:
This branch has been merged back to trunk; remove it.
 23:11
23:11 ruoso joined 23:20 donaldh joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!