Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-12

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:08 cotto It sounds like a good way to explain L1 would be microcode.
00:10 darbelo RISP: Reduced Instruction Set Parrot
00:13 gryphon joined #parrot
00:22 mugwump hey, and here's an idea: you should only need to vtable the reduced instruction set instructions
00:37 chromatic I'm not sure about that... but we could turn all vtable entries into multis then.
00:37 mugwump what does multis mean in that context?
00:38 mugwump not selecting on the argument type?
00:38 chromatic They all select on argument type.
00:38 chromatic They select on all argument types?
00:44 dalek parrot: r39513 | jkeenan++ | trunk/src/pmc/handle.pmc:
00:44 dalek parrot: Correct POD syntax error, allowing for what the author probably intended.
00:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39513/
00:44 mugwump Well, say 'repeat' becomes non-L1 but 'concatenate' is L1, does it make sense to have a fixed vtable entry for 'repeat' ?
00:45 mugwump Actually I don't quite understand why functions that take PMC arguments are vtable'd
00:45 mugwump rather than being just methods
00:46 mugwump the thing about argument types, I can see why you'd want to fast-path something like i_add_int or i_add_float, but i_add itself?
00:48 kesselhaus is there already an release schedule for the next parrot? 1.3 or 1.4?
00:48 pmichaud_ 1.3 will be released Tuesday.
00:49 pmichaud_ 1.4 is schedule for release on July 21.
00:49 pmichaud_ *scheduled
00:49 kesselhaus cool, and perl6 will be released again too? ;)
00:50 pmichaud_ The next release of Rakudo will be on Jun 18 (Thu)
00:50 mugwump kesselhaus: Christmas!
00:50 purl somebody said christmas was all jolly goofy shit. weee! or o/~ we wish you a spendy christmas o/~ x3; o/~ and a 'spensive new year o/~ or not yet or next year or when Perl6 is released.
00:50 mugwump ^^ see!  :)
00:50 pmichaud_ the July release of Rakudo will be two days after the July release of Parrot -- likely July 23.
00:50 pmichaud_ We don't have a name for the Rakudo July release yet -- suggestions welcomed.  :-)
00:51 kesselhaus rakudo-1.3? ;)
00:53 Whiteknight cotto: I had the same thought, they do sound quite a bit like microcodes
00:53 pmichaud_ :)
00:54 pmichaud_ well, I already rakudo's july release will be   #19   and rakudo-2009-07
00:54 pmichaud_ *already know
00:54 pmichaud_ I'm looking to see what Perl Mongers group to name it after.
00:55 pmichaud_ It's likely to be DFW.pm, unless I see a reason to put another group in that slot
01:02 Whiteknight irclogs
01:02 Whiteknight irclogs?
01:02 purl i think irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
01:32 pmichaud_ I found the utf8 bug.
01:32 Tene japhb: still having issues or questions?
01:35 japhb Tene: I think I'm doing pretty well muddling through ... I'll let you know if I get stuck again.
01:35 pmichaud_ anyone got a moment to look at a likely utf8 bug?
01:36 pmichaud_ src/string/encoding/utf8.c:591
01:49 pmichaud_ WTF?!?
01:49 Tene hm?
01:49 pmichaud_ okay, I agree with NotFound -- all of the strings code is b0rken.
01:49 pmichaud_ badly b0rken.
01:49 pmichaud_ like, there's no possible way this stuff could work sort of broken.
01:50 Tene :)
01:54 bacek heh... Idea of having thousands of representation for single entity is broken by design.
01:54 japhb What is the deprecation policy on runtime/parrot/library/... ?
01:55 bacek PBC, STRING, you name it...
01:55 bacek Ah. Keys!
01:55 Tene japhb: probably depends on what it is.
01:55 bacek Other way round - having single representation for totally different things
01:55 japhb .../NCI/call_toolkit_init.pir ... which, as far as I can tell, is only used by the OpenGL code
01:56 Tene japhb: then just change it, IMO
01:56 japhb excellent
01:56 pmichaud_ iiuc, libraries have to go through a deprecation cycle.
01:56 pmichaud_ that would include NCI/call_*
01:57 japhb ... sigh
01:58 japhb well, I can always just create NCI/Utils.pir and mark the old one deprecated, yes?
01:58 pmichaud_ japhb: yes.
02:01 japhb Was 1.0 considered a 'supported release'?  Or is 1.4 the first?
02:01 pmichaud_ 1.0
02:01 japhb damn
02:01 pmichaud_ yes, 1.0 is a 'supported release'  (the first)
02:03 japhb OK, so anything marked deprecated by the time 1.4 is released is eligible for removal immediately after 1.4, right?
02:04 japhb (so listed in DEPRECATED.pod as eligible in 1.5)
02:04 pmichaud_ correct.
02:05 japhb OK, so now I just have to see if I have working Trac access ....
02:05 Infinoid Hello, #parrot
02:07 * Infinoid is going through updating his machines to EDT5EDT (silly east coast, scheduling sunrises at 3am)
02:07 Infinoid s/EDT5/EST5/
02:07 eternaleye joined #parrot
02:09 Tene hullo inf
02:09 kid51 joined #parrot
02:16 kid51 Whiteknight ping
02:16 Whiteknight kid51: pong
02:17 kid51 u probably know this, but ... we need a test file t/pmc/handle.t to shut up a codingstd test.
02:19 Whiteknight yeah, I was working on that tonight but got sidetracked.
02:19 Whiteknight I'll get all those tests passing tomorrow
02:20 Whiteknight There's a ticket for it already, so I'm on top of it
02:20 Whiteknight but I'm going to bed now, so I'll talk to you later
02:20 Infinoid Whiteknight++
02:23 kid51 I'll contribute a file just to shut the codingstd test up; it won't contain anything real.
02:23 Infinoid cool.  Odd that the codingstd test didn't break in the branch
02:25 Zak joined #parrot
02:27 eternaleye joined #parrot
02:28 kid51 Perhaps it never got run.  For some reason it's in t/distro (hence, 'make distro_tests') rather than t/codingstd ('make codetest').
02:28 kid51 The former tends to get run only as part of 'make fulltest'.
02:29 kid51 Well, particle wrote the first version, so i assume he had a reason for putting it there.
02:29 kid51 Yeah, I would never think to run make full_test on a branch.
02:36 dalek parrot: r39514 | jkeenan++ | trunk (1 files):
02:36 dalek parrot: Create t/pmc/handle.t.  No real tests of functionality yet.
02:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39514/
02:37 kid51 cotto ping
02:38 Infinoid ah, ok.  I think codetest would be a better place for it
02:38 Infinoid having it in distro_test makes it seem less urgent... but then it places all the burden on the release manager (who should be as unburdened as possible)
02:41 janus joined #parrot
02:46 dalek parrot: r39515 | jkeenan++ | trunk (1 files):
02:46 dalek parrot: 1.  Clarify messages in 3 tests; we're requiring test files for each PMC
02:46 dalek parrot: rather than the other way around.
02:46 dalek parrot: 2.  Move test to t/codingstd/ so that it gets run more frequently, as part of
02:46 dalek parrot: 'make codetest'.
02:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39515/
02:52 dalek parrot: r39516 | jkeenan++ | trunk/t/codingstd/test_file_coverage.t:
02:52 dalek parrot: Correct typo in test message.
02:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39516/
03:20 donaldh joined #parrot
03:28 gryphon joined #parrot
03:30 silug joined #parrot
03:38 dalek rakudo: a2b8ceb | pmichaud++ | src/parser/actions.pm:
03:38 dalek rakudo: Bare parens should return Nil.  TimToady++
03:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​2b8ceb4745a24f50bd4f3a79a51506c838135ef
03:42 eternaleye I suddenly find myself sorely tempted to write a compiler for POSIX sh.
03:44 Infinoid You'd have an easier time of that once the Pipe and PipeHandle PMCs hit trunk
03:44 eternaleye Good, then I might be able to put it off until school finishes.
03:44 Infinoid But other than all the I/O and child process handling, the language itself doesn't seem that complicated
03:45 eternaleye It would also enable people to say "I use Parrot as my shell"
03:45 Infinoid Hmm.  You'd also need a dup2() function, which I don't think parrot currently provides
03:45 Infinoid You'd need a clever name for your parrot shell :)
03:46 eternaleye Parsh - the mushmouthed POSIX shell
03:46 Infinoid heh
03:47 eternaleye "Even parch can parse Parsh"
03:47 eternaleye Gah, "Even parsh can parse Parsh"
04:49 zak_ joined #parrot
05:09 ZeroForce joined #parrot
05:34 Tene eternaleye: if you then write several of the coreutils in Parrot and ship them as PBCs, you could have a pretty nice parrot-only embedded environment.
05:35 Tene or just as functions in the parsh pbc, which checks the name it was called with.
05:35 Tene like busybox
05:37 NotFound And if you call them as internal commands, it may even be a lot faster than conventional shells.
05:38 dalek parrot: r39517 | cotto++ | branches/pmc_pct/compilers (13 files):
05:38 dalek parrot: [codingstd] fix some (but not all) codingstd failures in pmc_pct
05:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39517/
05:39 NotFound msg pmichaud_  src/string/encoding/utf8.c:591 looks wrong, certainly
05:39 purl Message for pmichaud_ stored.
05:39 uniejo joined #parrot
05:42 uniejo joined #parrot
05:54 cotto That's nuts.  I'm amazed that we've got almost 50 people coming to the pmvw.
06:09 cotto I wonder how much awesome can be added to pmc_pct by that time.
06:09 cognominal joined #parrot
06:59 cotto Can I safely assume that a PMC is an aggregate if it doesn't do scalar?
07:03 chromatic I don't think you can; I'm not sure we're aggressive about marking aggregates with or without that metadata.
07:04 cotto I think it'll work in the limited context I'm using it.  I'll make sure to put a big warning on it.
07:11 cotto Is there some existing code I can use to make a deep clone of a PMC?
07:14 mikehh_ joined #parrot
07:21 donaldh joined #parrot
07:27 dalek rakudo: d2b24d8 | tene++ | src/builtins/eval.pir:
07:27 dalek rakudo: Fix the keyword for loading a foreign library (japhb++)
07:27 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​2b24d8564805c66190f086bb7ea1aa9685ebc85
07:28 masak joined #parrot
07:31 viklund_ joined #parrot
07:31 dalek TT #753 created by japhb++: Deprecate NCI/call_toolkit_init.* in favor of NCI/Utils.*
07:37 dalek parrot: r39518 | japhb++ | trunk (4 files):
07:37 dalek parrot: Deprecate r/t/l/NCI/call_toolkit_init.* in favor of .../NCI/Utils.*
07:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39518/
07:39 dalek rakudo: e61569f | tene++ | src/parser/actions.pm:
07:39 dalek rakudo: Oops... fix the keyword in one more place too.
07:39 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​61569fdd4f56640467b2d396df2a4cd81591a5f
07:40 japhb Tene: I'm about to commit my new export() routine in runtime/parrot/languages/parrot/parrot.pir ; will that conflict with anything you are working on?
07:41 Tene japhb: not at all.  you're the first user of the 'parrot' compiler.
07:41 Tene japhb: as long as it still responds to 'load_library' with the same API, you can do whatever you feel is best.
07:41 japhb :-)
07:42 japhb .oO( Oh Subversion, why can't you be Git? )
07:43 Tene japhb: I never use svn for parrot... every time I've tried, I've screwed it up.
07:44 dalek parrot: r39519 | japhb++ | trunk/runtime/parrot/languages/parrot/parrot.pir:
07:44 dalek parrot: New, greatly expanded Parrot::Compiler::export()
07:44 japhb Tene: I wouldn't either -- except that git-svn seems to have shot itself mortally in the leg while trying to rebase, and I don't feel like nuking it and pulling down all of parrot.  Again.
07:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39519/
07:44 Tene I'll review real quick...
07:46 Tene japhb: that's great
07:47 japhb Thanks!  What is?  :-)
07:47 japhb The new export()?
07:47 Tene japhb: yes
07:47 japhb cool, glad you like it
07:47 dalek parrot: r39520 | japhb++ | trunk/runtime/parrot/library/OpenGL.pir:
07:47 dalek parrot: [OpenGL] improve ambiguous names; support new experimental HLL export
07:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39520/
07:48 Tene japhb: do you have an example of using OpenGL from rakudo?
07:48 japhb Tene: working on commit message now.  ;-)
07:48 Tene :D
07:53 japhb OK, with the commit that should be coming through any minute, I believe I am all pushed now.
07:54 dalek parrot: r39521 | japhb++ | trunk/examples/opengl (6 files):
07:54 dalek parrot: [OpenGL] examples: switch to NCI::Utils; better window titles; new SYNOPSES; new Perl6 use Foo:from<parrot>; use 'constant's; unhack stuff hacked up for old Rakudos; more clearly mark remaining Rakudo hackery; misc cleanups and bugfixes
07:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39521/
07:57 nopaste "tene" at 166.70.38.237 pasted "japhb: I don't think it's supposed to do this..." (7 lines) at http://nopaste.snit.ch/16875
07:58 japhb Tene: That looks like you have an insufficient GL driver.
07:58 Tene Spooky.
07:58 japhb Do static-triangle.p6 and triangle.p6 work?
07:58 Tene No.  Same error.
07:59 japhb huh.
07:59 japhb And the .pir versions?
08:01 barney joined #parrot
08:01 Tene same output
08:02 japhb Tene: er ... am I correct in assuming you realcleaned and redid configure and make with the bleed parrot?
08:03 japhb And what is your OS and hardware?
08:03 Tene I did earlier today... I'll try again.
08:03 Tene fedora linux x86_64
08:03 japhb video hardware?
08:03 purl video hardware is probably known to suck
08:03 japhb purl finally gets one right
08:03 purl japhb: what?
08:03 japhb purl, botsnack
08:03 purl thanks japhb :)
08:03 Tene 01:00.0 VGA compatible controller: nVidia Corporation Quadro FX 570M (rev a1)
08:04 japhb Hmmm.  That should not suck.  Are you using the free or proprietary drivers?
08:04 Tene proprietary.  Want me to try again with the free?
08:05 japhb Nope, I'm on proprietary drivers with nvidia hardware, so that's no diff.
08:05 japhb (Mind you, this laptop is 32-bit and running Debian, but I think that's minor.)
08:05 Tene same failure after realclean
08:06 * japhb is nuking everything and rebuilding too
08:06 japhb but it's a laptop, it will be a couple more minutes
08:06 japhb s/laptop/old laptop/
08:07 riffraff joined #parrot
08:09 japhb Tene, would you mind posting 'glxinfo' output, plz?
08:09 nopaste "tene" at 166.70.38.237 pasted "japhb++ glxinfo" (620 lines) at http://nopaste.snit.ch/16876
08:12 mikehh t/op/debuginfo.t - TODO passed:   1, 7-8 smolder http://smolder.plusthree.com/app/pu​blic_projects/report_details/23580
08:12 japhb Tene: are you running compiz or suchlike?  GL compositing for the desktop?
08:13 Tene No.
08:13 japhb Grrr.
08:13 japhb Running out of ideas.
08:14 japhb Trying a build on a 64-bit desktop, to see if its a 64-bit problem
08:16 bacek http://tt.ro.vutbr.cz//file/cmdout///32321.txt
08:16 bacek http://tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk
08:16 bacek Looks good
08:17 zak_ joined #parrot
08:23 cotto anyone here know namespaces?
08:24 Tene kinda
08:24 Tene what's up?
08:24 purl Me, you bitches!  I'm high on crack!
08:24 Tene shut up, purl.
08:24 purl make me
08:24 Tene purl: what's up is <reply>
08:24 purl tene: bugger all, i dunno
08:24 Tene FINE.
08:24 Tene cotto: ?
08:24 cotto I'd like a sanity check on a patch
08:24 Tene I'll try.
08:25 nopaste "cotto" at 75.92.174.97 pasted "patch to simplify pmc2c" (74 lines) at http://nopaste.snit.ch/16877
08:25 cotto The important part is the first chunk.
08:26 Tene That's rather outside of my experience; sorry.
08:26 cotto np
08:26 cotto no, what's up is <reply>
08:26 purl well, <reply> is maybe... or
08:26 cotto no, (what's up) is <reply>
08:27 cotto what's up?
08:27 purl The birds, the sky, and the ceiling.
08:27 cotto what's up?
08:27 purl The Canadian Dollar
08:27 cotto literal what's up?
08:27 chromatic That simplification looks good, but I don't immediately grasp the implications.
08:27 chromatic ... but it appears that the limitations are the same.
08:28 ttbot japhb: Parrot trunk/ r39520 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/32374.txt
08:28 ttbot japhb: Parrot trunk/ r39521 MSWin32-x86-multi-thread make error http://tt.ro.vutbr.cz/file/cmdout/32378.txt
08:29 japhb What is ttbot?
08:29 chromatic A build bot.
08:29 cotto I'm testing to see if using the old get_namespace without the special case causes anything bad to happen.  The patch doesn't cause any test failures.
08:30 cotto btw, chromatic++ for that mj alias
08:30 chromatic You're welcome.
08:30 japhb The txt files it's sending me appear to be garbage.
08:32 chromatic The system doesn't have nmake installed?
08:33 cotto Just deleting the special case also causes no new test failures.  It looks like that function gets test coverage.
08:33 cotto It might just be because multiple threads are very poorly tested.
08:35 chromatic That's true also.
08:37 cotto Is it ok if I commit the nopasted version of the patch?
08:38 mj41 sorry, no path :-(
08:39 mj41 after winXP auto update restart - will fix this soon
08:39 chromatic cotto, go ahead.
08:41 japhb Tene: unfortunately, can't reproduce your failure.  IWFM on AMD64 as well.
08:42 * japhb wonders if Tene's system has some other problem, like a busted freeglut.
08:43 Tene japhb: how would I notice that?
08:43 japhb hmmm
08:43 japhb OK, sanity check: glxgears works?
08:43 Tene yes
08:44 dalek parrot: r39522 | cotto++ | trunk (2 files):
08:44 dalek parrot: [pmc2c] make some special-case code the common case
08:44 dalek parrot: Simply deleting the code from PMCEmitter.pm causes no test failures, but this may result from poor thread test coverage.
08:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39522/
08:44 Tene 8.8k FPS
08:44 japhb wheeee
08:46 japhb Hmmm, one difference is that my drivers report OpenGL version 2.1.2, rather than 3.0.0 ...
08:46 japhb Good old Debian backrev drivers, sigh.
08:47 japhb Although ... that could be because my video cards are just a tad too old for OpenGL 3.  Hmm.
08:49 japhb Tene: grep 'VERSION\|IMPLEMENTATION' /usr/include/GL/freeglut_std.h
08:50 Tene #define  GLUT_API_VERSION     4
08:50 Tene #define  FREEGLUT_VERSION_2_0 1
08:50 Tene #define  GLUT_XLIB_IMPLEMENTATION 13
08:50 japhb damitol
08:56 clinton joined #parrot
08:57 japhb I'm not versed enough with Fedora to know how to do this, but on Debian I'd tell you to 'apt-cache rdepends freeglut3' and pick something fun to try.
08:58 japhb However, it's 2 AM.  I need to get some sleep.
08:59 Tene looks like my freeglut is 2.4
08:59 Tene not 3
08:59 japhb Anyone else, I'd appreciate some testing of the current OpenGL examples.
09:00 japhb Tene: your defines were the same as mine.  :-/
09:00 Tene anyway, I need to go too
09:00 Tene Chat later.
09:00 japhb Tene: any objection to bumping the Parrot revision requirement for Rakudo?
09:01 japhb To 39521, I guess?
09:01 japhb Ah, OK, ttyl
09:01 Tene japhb: you want to ask pmichaud, not me.
09:01 japhb OK, will do tomorrow, thx
09:04 mj41 TapTinder client "pc-strakos" auto start fixed (added "Setting environment for using Microsoft Visual Studio 2008 x86 tools."). http://tt.ro.vutbr.cz/buil​dstatus/pr-Parrot/rp-trunk
09:06 bacek joined #parrot
09:14 bacek oh hai...
09:25 Tene hi bacek
09:25 bacek hi Tene. How is HLL stuff going?
09:25 Tene going very well
09:26 Tene my main blocker is other HLLs to work with. :)
09:26 bacek :)
09:29 Tene Feel free to help me out here... you have a common lisp implementation stashed away anywhere?
09:29 Tene bacek: I just posted this earlier: http://gist.github.com/128499
09:30 bacek wow!
09:30 bacek Tene++ # HLL ftw
09:30 Tene I wrote it two weeks ago, I think, on an airplane.
09:30 Tene Then forgot about it.
09:31 bacek In Soviet Russia code forget YOU! :)
09:31 Tene Oh, I'm also blocking on a weird segfault when trying to load Rakudo or Cardinal from my scheme compiler, steme
09:31 Tene didn't happen a month ago, but it does now.
09:31 bacek have a backtrace?
09:32 Tene https://trac.parrot.org/parrot/ticket/744
09:32 Tene something invalid gets stored in the pmc registers of a context
09:32 Tene 0x21 iirc, as a PMC pointer
09:32 * bacek checking
09:32 purl checking is probably just different
09:34 Tene no, 0x1
09:35 nopaste "tene" at 166.70.38.237 pasted "bt for bacek" (114 lines) at http://nopaste.snit.ch/16879
09:44 bacek Tene: ok... It's all refcounting and Whiteknight faults :)
09:59 Tene purl: msg whiteknight bacek says that you're to blame for TT 744.  Think you can look at it for me?
09:59 purl Message for whiteknight stored.
10:25 bacek Tene: refcounting is bigger problem. OTOH Whiteknight can implement Contexts as GCable PMCs :)
10:44 Infinoid And then he can speed up our GC and make it play nicely with threads, and while he's *that* deep in the woods, other magical ponies should be easy to find
10:52 payload joined #parrot
10:55 muixirt joined #parrot
10:58 nopaste "muixirt" at 91.47.108.143 pasted "/perl6 --target=pir -e 'while 1 { };'" (122 lines) at http://nopaste.snit.ch/16881
10:59 muixirt the while loop leaks lots of memory, is it sole problem of parrot?
11:11 Infinoid Probably.  If you could reduce it further (so it doesn't depend on perl6.pbc), we would know for sure
11:15 muixirt Infinoid, after the loop27_test: label that new $P20, "Int" does allocate mem, right? It seems to be called endlessly in the loop.
11:21 donaldh joined #parrot
11:35 particle1 joined #parrot
11:36 mberends joined #parrot
11:42 kj joined #parrot
11:47 Infinoid muixirt: Right, but the previous Int should eventually get GCed
11:51 muixirt also if you run that p6 snippet there are some calls to mmap2 and according to the comments in parrot/src/gc/malloc.c
11:53 muixirt that is only the case of requests >128kB
12:00 Infinoid muixirt: I think we're using the system malloc in most/all cases, not dlmalloc
12:01 Infinoid at least, on my machine, malloc.c isn't built
12:03 Infinoid mmap could also be used for jit buffers, or something else entirely
12:06 burmas joined #parrot
12:10 elmex joined #parrot
12:10 muixirt Infinoid, you are right, it isn't built on my machine either, but system's malloc calls mmap too
12:16 Infinoid okay.  that just means it's harder to read in strace :)
12:16 Infinoid (though mmap() is arguably a lot cleaner than sbrk()...)
12:51 Whiteknight joined #parrot
12:54 szabgab joined #parrot
13:03 Util joined #parrot
13:04 dalek parrot: r39523 | whiteknight++ | trunk/src/pmc/default.pmc:
13:04 dalek parrot: [codingstd] remove trailing whitespace from default.pmc
13:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39523/
13:22 skids joined #parrot
13:28 Whiteknight irclogs?
13:28 purl it has been said that irclogs is http://irclog.perlgeek.de/parrot/today or see also: infrared clogs
13:38 ruoso joined #parrot
13:39 ruoso joined #parrot
13:41 ruoso joined #parrot
13:41 Whiteknight Tene: ping
13:43 ruoso joined #parrot
13:44 ruoso joined #parrot
13:47 skids joined #parrot
13:48 gryphon joined #parrot
13:48 particle joined #parrot
13:49 * Coke de-cloaks.
13:49 Coke de-cokes?
13:50 particle i see you haven't de-punned
13:54 Coke still cokes run deep.
14:06 Whiteknight wahwah
14:12 Whiteknight (bad puns)--
14:12 Whiteknight karma bad puns
14:12 purl bad puns has neutral karma
14:13 Whiteknight (bad puns)--
14:13 Whiteknight karma bad puns
14:13 purl bad puns has karma of -1
14:24 Coke (bad puns)++ !
14:27 Whiteknight it would be negative karma too, if it wasn't for you meddling kids
14:36 * Coke kills another use of multiple PMC inheritence.
14:39 * Coke tries to think of a way to make tcl's types play nice with parrot's types.
14:39 Coke (for me, an RPA is a scalar. =-)
14:40 Whiteknight great
14:40 burmas left #parrot
14:40 dalek partcl: r478 | coke++ | trunk/ (5 files):
14:40 dalek partcl: Remove TclObject, minor pmc cleanups
14:41 dalek partcl: The only reason to have this abstract type is to help with shimmering
14:41 dalek partcl: between the scalar types; but it was not universally used, and we want
14:41 dalek partcl: more custom behavior, and this will simplify efforts to switch to PIR
14:41 dalek partcl: classes instead of PMCs.
14:41 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=478
14:41 payload joined #parrot
14:48 Theory joined #parrot
14:56 Coke hurm. 'self' should work in a :vtable, no?
14:57 pmichaud should, yes.  Might still need :method.
15:00 Whiteknight Coke: it's unreliable
15:00 Whiteknight not in all vtables
15:01 Whiteknight and usually you need to add :method too
15:08 Tene Whiteknight: pong
15:09 particle joined #parrot
15:13 Coke Whiteknight: that sucks.
15:13 purl The rock is now off.
15:14 Coke hurm.
15:14 Coke doesn't help. minipaste:
15:15 Coke ha. my fault.
15:16 Coke $P1 = get_iter self # get_iter is a method on a TclArray; I wanted 'iter'
15:20 donaldh joined #parrot
15:25 dalek partcl: r479 | coke++ | trunk/ (5 files):
15:25 dalek partcl: Convert the dict PMC to a class.
15:25 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=479
15:41 dalek partcl: r480 | coke++ | trunk/src/pmc/tclint.pmc:
15:41 dalek partcl: remove (now?) useless vtable override.
15:41 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=480
15:45 ascent joined #parrot
15:47 Whiteknight Coke: Yeah, we're working on it
15:50 Tene Whiteknight: pong
15:50 dalek partcl: r481 | coke++ | trunk/src/pmc/tcllist.pmc:
15:50 dalek partcl: remove (now?) useless vtable override
15:50 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=481
15:52 Whiteknight Tene: what's going on with TT #744?
15:52 Whiteknight because I didn't think I had anything to do with it
15:53 Whiteknight besides it being GC-related, and me doing GC stuf
15:53 Tene Whiteknight: Eh, just harassing you because bacek said so.  Nothing more.
15:53 Tene I'm not sure it's GC-related, actually.  It's just that the GC triggers it.
15:54 Tene There's a 0x1 value in a context where a PMC * should be
15:54 Tene (obviously segfault when dereferenced)
15:54 dalek parrot: r39524 | whiteknight++ | trunk/t/pmc/handle.t:
15:54 dalek parrot: [t] fix t/pmc/handle.t do do what it should. Also, rewrite it in PIR not Perl5
15:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39524/
16:04 Coke given a MULTI vtable at the PMC level, I can override it in a PMC subclass also using MULTI. (I just want to override one of the variants.) Is it expected that this should work in a PIR subclass?
16:08 pmichaud you mean specifically for multi vtables?
16:08 pmichaud or for methods in general?
16:09 pmichaud in my experience, defining a method in a PIR subclass hides all similarly-named methods in its parent classes, regardless of :multi
16:09 pmichaud I don't know if that holds for vtables
16:12 Coke I specifically care about the divide vtable.
16:12 Coke if it's divide(integer,_), I want to override, otherwise, don'tcare.
16:12 Coke (This works at the PMC level, but fails in pir.)
16:14 Coke I'm experimenting with eliminating my PMCs to avoid the PBC/C barrier.
16:22 Coke crap. I think I might have missed a namespace declaration in my new class file that might explain the issue.
16:25 Psyche^ joined #parrot
16:25 chromatic joined #parrot
16:58 dalek rakudo: 9aa210f | pmichaud++ | src/setting/Array.pm:
16:58 dalek rakudo: Remove incorrect constraints on splice() arguments.
16:58 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​aa210f6d020950d9de1cf8fd9cab3ebb8b53115
16:58 dalek rakudo: 31443c0 | pmichaud++ | src/classes/Str.pir:
16:58 dalek rakudo: Add some more ranges to Str.succ .
16:58 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​1443c0e53e62b38b67e50c1b26832d3a9eed722
17:32 itrekkie joined #parrot
17:39 itrekkie left #parrot
17:40 japhb pmichaud: What "type" should this experimental deprecation TT be?  "Roadmap"?
17:42 * japhb assumes so ... can always change it later
17:43 dalek TT #754 created by japhb++: Mark new cross-HLL export/import as "experimental" by pre-deprecating it
17:50 japhb OK, TT and DEPRECATED.pod done.
17:50 Coke bah, was just editing deprecated.
17:50 Coke I may have some edits for you. =-)
17:51 Coke japhb: HA! perfect.
17:52 japhb :-)
17:52 Coke I have a more generic experimental notice at the top (already using the same [tag] you did.)
17:52 japhb excellent.
17:52 Coke I'll just remove the more specific version of the text you have for that item.
17:52 japhb np
17:53 dalek parrot: r39525 | japhb++ | trunk/DEPRECATED.pod:
17:53 dalek parrot: Pre-deprecate cross-HLL library loading design and implementation
17:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39525/
17:56 Coke Done.
17:58 Coke ok, now done.
17:59 japhb Wording in footnote is a tad confusing.  Mind if I copy edit?
18:00 HG` joined #parrot
18:00 Coke nope.
18:00 dalek parrot: r39526 | coke++ | trunk/DEPRECATED.pod:
18:00 dalek parrot: Extend the [experimental] notes a bit.
18:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39526/
18:00 dalek parrot: r39527 | coke++ | trunk/DEPRECATED.pod:
18:00 dalek parrot: fix pod-o
18:00 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39527/
18:03 japhb Coke: "For an item to be considered experimental, it can B<never> have shipped in a stable release without the C<[experimental]> tag; otherwise, it must be deprecated normally before removal or incompatible change."
18:03 japhb Better?
18:04 japhb (Only part after semicolon has been changed)
18:05 mikehh_ joined #parrot
18:06 * japhb commits ... it's not like we'll run out of revision numbers if Coke wants to change it again.  :-)
18:07 dalek parrot: r39528 | japhb++ | trunk/DEPRECATED.pod:
18:07 dalek parrot: Clear up confusing wording in [experimental] footnote
18:07 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39528/
18:10 gryphon joined #parrot
18:20 Coke japhb: sorry, yes, that's clearer.
18:21 Coke chromatic: ping.
18:40 japhb Tene: Do you Configure your Parrot with --optimize ?
18:40 japhb It's occurred to me that may be a difference between our systems.
18:41 * japhb tries unoptimized 64-bit build ....
18:44 chromatic pong
18:55 Coke chromatic: based on previous conversations, moving code from C to PIR is, in general, desirable for HLLs?
18:56 chromatic In general, yes.
18:56 Coke k.
18:56 chromatic The results depend on what you can accomplish and how often you might have crossed the Rubicon in the mixed language version however.
18:57 nopaste "muixirt" at 91.47.108.143 pasted "PIR example that leaks memory" (8 lines) at http://nopaste.snit.ch/16885
18:58 Coke I'm just trying to avoid cross the PBC/C boundary as much as possible.
19:00 Zak joined #parrot
19:00 Coke pmichaud (or anyone): with a pmc, I have to do root_new ['parrot'; 'TclList'] - for a PIR based class replacement, should that same call work?
19:01 japhb Is there a way to 1) Tell parrot to say something each time it does a GC run, and 2) to see how long each GC run takes?
19:01 muixirt my example leaks memory, should have the GC prevented that?
19:02 Coke muixirt: leaks as reported by valgrind, or checked manually via top?
19:02 japhb muixirt: it should have, yes.  :-)
19:02 muixirt Coke, via top
19:02 chromatic top lies.
19:02 Coke ok. if you force a GC run each time through the loop, you might see different results.
19:03 japhb chromatic: a simple piece of PIR like that should not cause the process to grow.  As soon as it needs RAM, it should GC, instead of growing.  If not, the GC is off.
19:03 japhb ("off" as in "wonky")
19:03 chromatic Sure, but top lies.
19:04 muixirt Coke, yes with -R gcdebug there is no leakage
19:04 japhb Tene: Still can't reproduce.  Optimized or unoptimized, I can't get the OpenGL stuff to fail.
19:04 muixirt chromatic, but strace -c doesn't lie, at least not on my system ;-)
19:06 japhb chromatic: happen to know the answers to my questions above (regarding logging / timing GC runs), or is there someone better to ask?
19:06 chromatic Nothing really keeps or reports statistics like that.
19:06 japhb awww.
19:07 japhb I keep seeing pauses in the OpenGL rendering, and I suspect I'm actually seeing big GC runs happening -- but wanted to confirm that.
19:07 Coke (i'm just trying to clarify between valgrind-style leak and "gc-doesn't-reclaim-as-fast-as-possible" leak.)
19:07 chromatic I've run that code with 100k, 200k, and 400k iterations, and Valgrind reports no leaks (besides a single context) and a string in main.
19:08 Coke you can dump out the pmcs allocated inside the loop, though.
19:08 japhb Coke: who was that comment to?
19:08 Coke http://code.google.com/p/partcl/sou​rce/browse/trunk/src/macros.pir#156 (Though that hasn't been updated in a while)
19:09 chromatic Sure, all Valgrind proves is that we're not leaking any PMCs when we shut down the end of the process.
19:09 pmichaud Coke: root_new ['parrot';'TclList']  simply says to grab the TclList class that is registered through the ['parrot';'TclList'] namespace
19:09 pmichaud it works for both PIR classes and PMCs
19:09 Coke pmichaud: k.
19:11 nopaste "coke" at 72.228.52.192 pasted "pmc vs pir" (66 lines) at http://nopaste.snit.ch/16886
19:12 pmichaud it's worth noting that PIR classes are currently about 3x slower than PMCs
19:12 pmichaud (at least as far as creating them goes)
19:12 pmichaud I should rephrase
19:12 pmichaud creating objects from PIR classes is 3x slower than creating PMC objects
19:12 chromatic The "die" looks a little severe.
19:13 Coke chromatic: but equivalent to the thrown exception before.
19:13 Whiteknight 3x slower? I'm surprised that it's not worse
19:13 pmichaud well, it depends somewhat on what's being created, yes.
19:14 chromatic Is "die" catchable?
19:14 Coke whoops. I missed a return on check_undef.
19:14 Coke chromatic: yes.
19:15 Whiteknight I've got a very interesting paper here from cotto++ about a GC that should negate pauses entirely
19:16 Whiteknight so that's a very interesting thing to think about
19:16 cotto I actually had some fun reading that paper and picturing the various threads as dinosaurs wearing colored shirts and carrying paintbrushes.
19:16 chromatic Is it the realtime G1 collector?
19:16 Whiteknight no, it's the VCGC collector
19:16 Whiteknight I don't think I know G1
19:17 Whiteknight oh, G1 is the new collector for the Java VM, right?
19:17 chromatic Garbage first.
19:19 muixirt so what is the definition for memory leak around here? what's wrong with the example?
19:19 Whiteknight chromatic: yeah, I'm reading the Garbage First paper now
19:20 Whiteknight muixirt: There are two sources for memory allocations: the GC and direct malloc calls
19:20 Whiteknight we're only worried about leaks from the direct malloc calls
19:20 donaldh joined #parrot
19:21 particle venture capital garbage collector?
19:23 muixirt Whiteknight, so it is a GC problem?
19:25 Whiteknight muixirt: probably not. Our current collector is simplistic, but relatively accurate
19:26 Whiteknight more likely the problem stems from one of the million other places that allocate and manage memory directly from the system
19:26 szabgab joined #parrot
19:26 Whiteknight Very Concurrent Garbage Collector
19:27 japhb Man, that sentence is wrong in so many ways.
19:27 chromatic It could be fragmentation, but it has some of the feel of PObjs living too long.
19:27 muixirt Whiteknight, limiting vir. mem. gives Parrot VM: PANIC: Out of mem! C file src/gc/alloc_memory.c, line 142
19:27 chromatic If it *were* too conservative collection, I'd expect it to run out of memory faster.
19:28 Whiteknight is there more information about this particular bug anywhere?
19:33 bobke joined #parrot
19:37 estrabd joined #parrot
19:41 viklund_ joined #parrot
19:43 dalek rakudo: de1e9f0 | moritz++ | docs/ChangeLog:
19:43 dalek rakudo: [docs] initial changelog for 2009-06 release
19:43 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​e1e9f0eb0ee15c069b39abd27314a24e41d4b9b
19:50 Tene japhb: I do not use --optimize
19:50 mj41 another out of mem https://trac.parrot.org/parrot/ticket/706
19:52 bacek joined #parrot
20:10 * Coke grumbles
20:19 dalek partcl: r482 | coke++ | trunk/runtime/builtin/namespace.pir:
20:19 dalek partcl: use fewer opcodes
20:19 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=482
20:24 dalek TT #755 created by doughera++: 'make install-dev' assumes "modern" File::Path
20:31 mj41 added Mac OS http://tt.ro.vutbr.cz/table/machine/id-11 to TapTinder
20:39 Andy joined #parrot
20:41 eternaleye purl: msg Whiteknight http://cs.nju.edu.cn/gchen/pa​per/ipdps2002/DATA/13_161.PDF (aka MCGC) claims it outperforms VCGC
20:41 purl Message for whiteknight stored.
20:46 eternaleye Oh this is amusing. The google-hosted HTML version of the VCGC paper has effectively been sed'ed with s/fi//g
20:47 chromatic They probably can't render the proper ligature.
20:47 eternaleye Hm, maybe more like s/f+.//g
20:47 eternaleye Since efficiently became eciently
20:53 pmichaud http://nopaste.snit.ch/16885   # why does Parrot GC fail to reclaim things here during runtime?
20:54 chromatic It could be the GC threshold tweak I applied a couple of weeks ago.
20:54 chromatic I doubt that.
20:54 chromatic It could be that something's too aggressive about marking a context as alive.
20:54 chromatic I doubt that too.
20:54 pmichaud there's not a context involved here, though.
20:54 pmichaud I mean, afaict, we aren't creating any new contexts.
20:54 pmichaud unless it's the evil mmd stuff at work again.
20:54 chromatic Sure, but that Integer only gets marked because it's in a context.
20:55 pmichaud I don't understand.
20:55 chromatic It's in a register which is in a context.
20:55 chromatic Nothing else refers to it (that I can see).
20:55 pmichaud right, but the register is constantly being updated to point to a new Integer
20:55 pmichaud so why aren't the old ones being reclaimed?
20:55 chromatic Right, but every time through the GC, that context has to get marked so the current contents of that register don't get reclaimed.
20:56 pmichaud sure, I understand that
20:56 pmichaud iiuc, there's only one context in play here, yes?
20:56 pmichaud that context contains the $P0 register
20:56 pmichaud marking the context causes the PMC that the $P0 register points to to be marked
20:56 chromatic One or two.  I'm not sure if calling main uses the initial context or creates a new one.
20:56 chromatic There should be only one PMC marked in this context though.
20:56 pmichaud either way, while we're in the loop we're not creating new contexts
20:57 pmichaud (note that it's an infinite loop)
20:57 chromatic Right, unless something called from one of the ops creates a context.
20:57 pmichaud I'm guessing that must be the case
20:58 pmichaud because this one context would only be marking one PMC.  That doesn't explain what's eating up all of the memory
20:58 pmichaud i.e., something isn't being reclaimed
20:58 chromatic I think so too.  I haven't had a chance to dig into it yet though.
21:00 bacek morning, good morning
21:01 nopaste "pmichaud" at 72.181.176.220 pasted "This leaks also, only faster." (6 lines) at http://nopaste.snit.ch/16887
21:02 bacek I have a question: why Namspace is-a Hash, not has-a Hash?
21:03 pmichaud bacek: what would Hashes do that Namespaces should not?
21:04 bacek Namespace override every single method in Hash. And than call SUPER sometimes
21:04 pmichaud namespace overrides *every* method in Hash?  are you sure?
21:04 bacek (get|set)_*_keyed_*
21:05 bacek at least all those overrided.
21:05 pmichaud right.  But there are a lot of methods in Hash that probably aren't overridden
21:05 pmichaud get_iter is a big one
21:06 bacek And I want to kill it... It's total kludge.
21:06 pmichaud Hash defines 64 VTABLE functions.
21:06 pmichaud Namespace defines 28.
21:07 pmichaud Therefore, Namespace cannot be overriding all of Hash's methods.
21:07 bacek gimme sec. I'll switch to trunk to check.
21:08 pmichaud but more to the point, the Perl  model for namespaces (and indeed for most dynamic languages) is that they act like hashes.  So it makes very good sense that NameSpace isa Hash.
21:08 pmichaud for something like nopaste 16887, what would normally trigger a GC run?
21:09 pmichaud because afaict there's never any GC taking place.
21:09 chromatic Running out of available PMCs in the free pool should trigger it.
21:09 pmichaud hmmm.
21:09 pmichaud would I see that in a trace?  ISTR seeing things like "DOD" in traces before, but I'm not seeing one here.
21:10 chromatic I think it's Parrot_gc_run something or other.
21:11 pmichaud 773:Parrot_gc_mark_and_sweep
21:11 bacek pmichaud: Namespaces are nested Hashes. Not plain one...
21:11 pmichaud bacek: they can act like hash-of-hash, yes.
21:12 bacek and something like 'get|set_integer_keyed' doesn't make sense for namespaces...
21:12 bacek or I missed something
21:12 pmichaud bacek: get_integer_keyed is just enabling something like      ns[0]   to act the same as ns['0']
21:13 pmichaud that's true for hashes as well.
21:13 pmichaud you can throw it out, but it doesn't really hurt for it to be there.
21:13 bacek pmichaud: not in current Namespace implementation
21:13 pmichaud bacek:  hmm...?
21:13 pmichaud how do you mean "not in current Namespace implementation"?
21:14 pmichaud oh, sorry, I was thinking keyed_int
21:14 bacek ns = ['foo';'bar';'baz']
21:14 pmichaud it's just enabling   $I0 = ns['key'] to work
21:15 pmichaud I agree that   ns['key'] = $I0 might not work properly.  I'd have to look.
21:15 bacek set_pmc_keyed in Namespace treat RSA specially. set_integer_keyed - not
21:15 pmichaud anyway, it's not been a problem I've ever run across.
21:16 bacek I'm trying deuglyfy Keys... And this is one of menay problems I found so far.
21:16 bacek many
21:17 chromatic That's not the worst problem with Keys by far.
21:18 bacek As far as I can see, worst problem of Keys is existence of Keys...
21:20 pmichaud at any rate, it seems natural to me that NameSpace isa Hash.  It would seem unnatural if that's not the case.
21:20 pmichaud in general, perl folks expect namespaces to act like hashes.
21:21 bacek get_pmc_keyed_int?
21:22 bacek LSP totally broken for Namespace/Hash pair.
21:22 pmichaud especially get_pmc_keyed_int
21:22 pmichaud if I do:   my $a = 3 + foo();   my $b = $ns{$a}
21:22 pmichaud I expect it to work, even if $a is an Int
21:23 bacek ok. What about get_integer_keyed?
21:24 pmichaud I did say that one makes less sense.  But just because a few operations might not make sense doesn't necessarily mean we should break isa
21:24 bacek my Int $a = $ns{<a b c>}; vs my $b = $ns{<a b c>}
21:24 pmichaud it might just mean we should convert those methods to throw exceptions
21:25 bacek But Namespace override all operations which make sense for Namespace
21:25 bacek So, If Namespace has-a Hash, all unimplemented methods will throw exception.
21:26 bacek And in meaningful methods Namespace can call VTABLE_get_foo(hash) instead of SUPER().
21:27 pmichaud and   VTABLE_isa ...?
21:27 bacek "Namespace"
21:27 purl hmmm... "Namespace" is like "domain" though
21:28 pmichaud no, I mean if I ask  if Namespace isa Hash ... ?
21:28 bacek But VTABLE_does(hash) == true
21:28 pmichaud you're going to change the isa relationship to be false, yes?
21:28 bacek I claim that "Namespace isa Hash == true" is misleading.
21:29 pmichaud not to perl folks it isn't.
21:29 bacek Why?
21:29 pmichaud because we expect our namespaces to be hashes.
21:29 bacek "to be" or "to act like"?
21:30 pmichaud and, you'll have to add a few methods to the NameSpace PMC -- the ones that are there aren't the complete set
21:30 viklund_ joined #parrot
21:30 bacek e.g.?
21:30 purl e.g. is `exempli gratia', latin for `for example'
21:30 pmichaud get_iter
21:30 purl get_iter is a vtable function
21:30 pmichaud elements
21:30 purl elements is at http://www.privatehand.com/flash/elements.html
21:31 bacek purl: shut up
21:31 purl make me
21:31 pmichaud clone
21:31 bacek get_iter for Namespace is different from Hash.
21:31 pmichaud it is?
21:31 purl Oh no it isn't!
21:31 bacek because Namespace is HoH.
21:31 chromatic A Hash can be a HoH too.
21:31 pmichaud NameSpace doesn't currently define a get_iter, which means it's inheriting the one from hash.
21:32 pmichaud and... what chromatic++ said.
21:32 bacek and rely on weird Key behaviour/implementation
21:32 pmichaud then fix the key behavior in Hash, not just in NameSpace
21:32 bacek agree
21:32 bacek But, Namespace poking into Hash guts.
21:33 bacek Because of "isa".
21:33 pmichaud this is a place where I'd argue that efficiency in namespace is extremely important
21:33 pmichaud even if it means poking into hash guts
21:33 pmichaud I already see measurable differences between
21:34 pmichaud root_new ['parrot';'Integer']
21:34 pmichaud and
21:34 pmichaud new ['Integer']
21:34 bacek That's why I'm trying to separate Hashes and Namespaces.
21:34 pmichaud you think you can make Namespace more efficient by going through the VTABLE instead of poking directly?
21:35 chromatic I don't think the efficiency argument is that compelling here.  Hashes and Keys are a mess, and they'll be easier to make efficient when they're not a mess.
21:35 chromatic (Making them less a mess will likely *improve* efficiency.)
21:36 pmichaud chromatic: fair enough, I'm willing to wait.
21:36 bacek oh... src/global.c... It rely on Namespace guts and iterate over it instead of using interface
21:37 chromatic Key especially has a lot of ad-hoc polymorphism that's much less efficient than it could be.
21:37 pmichaud in some sense it bugs me that there's a lot of time being spent refactoring things that aren't externally broken (and making them slower) while things that are needed aren't getting completed (more)
21:38 pmichaud calling conventions comes to mind
21:38 pmichaud MMD is another
21:38 chromatic Yeah, me too.
21:38 pmichaud IO is a third.
21:39 * bacek feel some similarity in this subsystems
21:40 pmichaud I guess my question would be, what is currently blocking on a refactoring of Key, NameSpace, and Hash ?
21:40 bacek pirc, emitting PBC from PIR
21:41 pmichaud you're saying that it's impossible to emit PBC from PIR without refactoring NameSpace, Key, and Hash?
21:41 bacek ATM pirc doen's support Keyed namespaces.
21:41 pmichaud that sounds like a limitation of pirc, then
21:41 chromatic I thought that was a problem with pirc and constant primitives.
21:42 pmichaud unless your intent is to completely eliminate Keys
21:42 bacek Emitting PBC from PIR require creating Keys.
21:42 pmichaud so, it sounds like you need a way to create keys from PIR
21:42 bacek Yes, I really want eliminate Keys..
21:42 chromatic We can't eliminate Keys anytime soon.
21:42 pmichaud what would you have in their place?
21:42 bacek Keys are quite different depends on context of usage
21:43 bacek pmichaud: Iterators. Aggregate specific.
21:43 bacek chromatic: soon means "5 weeks"
21:44 pmichaud bacek: but what about something like      new $P0, ['Foo';'Bar']
21:44 pmichaud what would that be instead?
21:44 bacek $P0 is ?
21:44 cotto ininitialized
21:44 chromatic I don't think five weeks is realistic for a change this big.
21:44 pmichaud $P0 is the register that gets bound to the new instance of ['Foo';'Bar']
21:44 cotto $P0 = new ['Foo';'Bar']
21:45 bacek ['Foo';'Bar'] is Namespace or RSA?
21:45 pmichaud It's a Key.
21:46 bacek Can it be RSA?
21:46 bacek which handled by "op new" properly?
21:46 pmichaud so, you're talking about having compile-time RSAs/
21:46 pmichaud ?
21:46 pmichaud What would you do with
21:46 bacek yes.
21:46 pmichaud $P0 = new ['parrot';$S0]
21:47 pmichaud note that if this requires creating a gc-able RSA at runtime, I'm a little against it.
21:47 bacek is Namespace is HoH - $root_ns<parrot>{$S0}
21:47 pmichaud I can't write that in PIR like that
21:47 chromatic No kidding, especially when a key can be constant.
21:48 bacek is it "$P0 = new ['parrot'], $S0"?
21:49 pmichaud no
21:49 pmichaud that would be different.
21:49 pmichaud it's still   new_p_pc
21:49 pmichaud it's not   new_p_pc_s
21:50 pmichaud the   ['parrot';$S0]  case I could likely live without.
21:50 pmichaud If you want to change PIR so that ['parrot';'Foo']  becomes a compile-time RSA constant, that's okay with me.
21:50 bacek It can be compile-time constant
21:50 chromatic That's an IMCC change though.
21:50 bacek And Parrot_oo_get_class treat Keys/RSA equally already.
21:51 pmichaud well, you'd also have to fix it for all of the other PMC types
21:51 pmichaud $I0 = hash['foo';'bar']
21:51 Whiteknight joined #parrot
21:51 pmichaud $P0 = array[0;1]
21:51 bacek I'm thinking about add 'VTABLE_hash_value'.
21:52 pmichaud ....what would that do?
21:52 bacek Allow "hash.c" works with PMCs.
21:52 pmichaud uh, that doesn't make any sense to me, but it probably doesn't need to.
21:53 pmichaud anyway, my point is that Keys get used in lots of places already
21:53 pmichaud so if you're going to get rid of them, you have to change IMCC as well.
21:53 bacek Currently we can't use PMC as Hash keys.
21:53 pmichaud and fix all of the places they get used.
21:53 pmichaud We can't?
21:53 pmichaud Rakudo uses PMCs as hash keys all the time.
21:53 pmichaud So does PGE.
21:54 pmichaud oh, you mean as non-string hash keys
21:54 bacek yes
21:54 pmichaud that should probably be a different kind of hash
21:54 pmichaud not replace the existing one
21:54 bacek Why?
21:54 pmichaud value semantics can get really weird with arbitrary PMC types
21:54 pmichaud there's not a generic "are these two things equal" comparison that is reliable enough to work
21:55 bacek We have VTABLE_clone
21:55 bacek to store key.
21:55 bacek We have VTABLE_is_equals to check equivalence.
21:55 pmichaud heh
21:55 pmichaud and you think that works?
21:55 bacek We just need VTABLE_hash_value
21:56 bacek Which part doesn't work?
21:56 bacek current hash.c is polymorphic. So it should work
21:56 pmichaud most of the relational ops currently EPIC FAIL when passed differing types
21:57 bacek oh...
21:57 bacek We don't need relational ops for hashes.
21:57 pmichaud you need at least the equivalence op
21:57 bacek yes
21:57 pmichaud that's also one that EPIC FAILS when passed differing types
21:58 bacek But it works, isn't it?
21:58 cotto bacek, why not just try to make the Key code sane?
21:58 bacek Hash_key_is_equal can check type before calling VTABLE_is_equal
21:58 bacek cotto: because Keys are insane
21:59 pmichaud anyway, keep in mind that you'll have to fix keys for (get|set)(_root|_hll|)(namespace|global)
21:59 pmichaud and for isa
21:59 pmichaud and for new
21:59 pmichaud and for subclass
21:59 pmichaud and for newclass
21:59 pmichaud and for get_class
21:59 pmichaud and for :multi
21:59 bacek pmichaud: Parrot_oo_get_class.
21:59 cotto by implementation they're insane, but you think they can't be fixed?
22:00 bacek cotto: they are insane by design... fsvo "design".
22:00 pmichaud Parrot_oo_get_class doesn't solve the get|set namespace|global issue.
22:00 pmichaud Parrot_oo_get_class doesn't solve the generic keyed interface to hash/array aggregates.
22:01 bacek get_namespace call Parrot_get_namespace_keyed.
22:01 bacek which call "internal_ns_keyed".
22:02 bacek so there is one place to fix.
22:02 bacek hang on
22:02 pmichaud seems like a lot of work, when it would be easier to just get pirc to be able to generate keys.
22:02 bacek "isa", "new", "subclass", "newclass", etc
22:03 bacek All of them uses Keys as RSA.
22:03 bacek Actually LinkedStringList
22:04 * pmichaud decides to wander off somewhere more productive, rather than fight a worthless fight.
22:06 bacek It's not worthless... At least I gather some useful information.
22:08 chromatic allison will have your head if you check in a big change like that a couple of weeks before 1.4.
22:08 chromatic I'm not saying it's not worth doing in general, only that it's a potentially disruptive change right now.
22:09 bacek 5 weeks is right after 1.4
22:09 pmichaud I count 6.
22:09 bacek And I'm not going to hack it in trunk.
22:10 bacek pmichaud: welcome to future! It's Saturday already :)
22:10 chromatic Okay, I misunderstood then.
22:10 pmichaud five weeks from today is July 18.
22:10 pmichaud 1.4 is July 21.
22:11 bacek Ok-ok. 6 weeks.
22:11 bacek Of cause it will not hit 1.4 release.
22:11 pmichaud even so, I'm a bit annoyed by these internal refactors that don't result in measurable changes to HLL implementors.
22:11 pmichaud (or the changes they do present are decidedly negative)
22:12 bacek I treat it as [CAGE] cleanup.
22:12 bacek Not even as [cage]
22:12 pmichaud if nothing breaks, and if performance doesn't go down, I have no objection.
22:12 chromatic Yeah, but there are a lot of bugs that need fixing.
22:12 pmichaud Agreed.
22:13 chromatic I don't mind cleaning up code in addition to fixing bugs, but I'd like to bias us toward more bugfixing now.
22:13 pmichaud To the extent that it takes people's tuits (particularly allison++'s) away from solving the problems that HLLs need solved, I'm against it.
22:14 chromatic That's a different story though.  We have to get allison off of critical paths.
22:14 chromatic At least we have to stop letting allison be the only person on critical tasks.
22:14 pmichaud I agree with that, but still I don't want it to impact a large number of tuits
22:14 pmichaud from any core developer, not just allison.
22:14 chromatic I know, I'm hijacking your rant for my own purposes.
22:14 pmichaud It's my rant as well, I'm just less vocal about that one :-)
22:16 bacek Speaking of bugs
22:16 bacek Can I merge tt24_unicode_numifications?
22:17 bacek Or we still waiting for "final" decision about "Inf" and "NaN" representing in Parrot?
22:17 Whiteknight I'm fine with a merger today
22:17 pmichaud I don't have an objection, if it doesn't break rakudo.
22:17 Whiteknight that gives us a few good days of testing before the release
22:17 pmichaud (or pge, or all the other items)
22:18 bacek pmichaud: It should fix Rakudo
22:18 pmichaud which ticket is it, again?
22:18 bacek tt724
22:19 pmichaud oh.  Rakudo isn't broken there.
22:19 pmichaud i.e., it doesn't fix anything that Rakudo needs fixing on.
22:19 bacek but it stops rakudo to use ucs2 during parsing, afaiu
22:20 pmichaud rakudo doesn't want to use ucs2 parsing.  I switched to using iso-8859-1 instead.
22:20 pmichaud which is actually nicer than ucs2 in many respects.
22:20 bacek hmm. why?
22:20 pmichaud uses less space, for one.
22:21 pmichaud it's a much more straightforward conversion.  Plus, we still have the issue that ucs2 only works when ICU is present.  iso-8859-1 works without ICU.
22:21 pmichaud The only reason I was trying ucs2 was because I knew there were issues with iso-8859-1 (TT #24).  But you and I fixed that already, which meant iso-8859-1 was an option.
22:21 bacek my $s = "Здравствуй мир";...
22:22 pmichaud Rakudo has no problem with that.
22:22 pmichaud That's a utf8 string, not a ucs2 one.
22:22 bacek is Cyrillic covered by iso8859?
22:22 pmichaud And Rakudo does its own string-to-number conversion, it doesn't use Parrot's.
22:23 pmichaud Rakudo has to do its own string-to-number conversion, so it can convert things like    "23_45"   and   ":2(10100101)"
22:23 bacek what about PGE?
22:24 pmichaud yes, PGE would be able to better handle ucs2 strings with the patch.  But I don't know anyone who is using them yet.
22:25 pmichaud anyway, as I said, I don't object if it doesn't break Rakudo.  :-)
22:26 * bacek smoking rakudo on trunk to compare with branch.
22:26 pmichaud I'm getting an intermittent error in t/spec/integration/99-problems-11-to-20.t  with current trunk... trying to track it down.  It feels GC related.
22:26 pmichaud because it disappears with very slight changes to the code.
22:27 pmichaud (Like, adding a blank line to the test file causes it to suddenly pass)
22:27 bacek oh... It's not good...
22:32 rg joined #parrot
22:32 bacek btw, what "array[0;1]" will return?
22:33 * Coke returns.
22:41 chromatic the second element of the nested array in the first array's first position
22:42 bacek same as "array[0][1]"?
22:42 bacek (in some HLL)
22:44 chromatic Yes.
22:45 bacek why do we need it in PIR?
22:46 bacek And what about "array['foo';'bar']"?
22:47 chromatic Same.
22:48 chromatic Except that's keyed access, not indexed.
22:48 bacek ooookey.
22:48 chromatic It's a shortcut for the get_XXX_keyed vtable entry.
22:49 bacek Do we really need this "shortcut"?
22:50 chromatic If you want to make the Universal Turing Machine argument, we don't need any shortcuts.
22:50 chromatic A better question is "Does this make certain coding patterns more convenient?"
22:51 bacek ok. Let me rephrase question.
22:51 chromatic If you get rid of that style of syntax, all code that refers to (for example) nested namespaces or multi-level classes has to perform several individual lookups into several temporary registers dispatching several more ops.
22:51 bacek Should PMC support this behaviour directly or it can be handled in generic way somewhere else?
22:52 chromatic Which behavior, looking something up by a key?  Yes.
22:52 sekimura joined #parrot
22:52 chromatic Multi-value keys?  Hard to say.
22:52 bacek "looking something by linked list of some values"
22:53 chromatic Once you've decided it's (for example) NameSpace's responsibility to look something up by a key, it's NameSpace's responsibility to handle a multi-key Key.
22:53 bacek not really.
22:54 bacek it can be generic loop over Key aside of Namespace
22:54 chromatic How do you propose to analyze code to determine when you can call the appropriate get_keyed vtable entry and when you dispatch... somewhere else?
22:55 chromatic For constant keys frozen into PBC, you *can* determine if they're multi-key keys.
22:55 chromatic For PMCs created within the compilation unit where you access them by key, you *probably* can determine their type.
22:55 chromatic All other uses you can't determine this until runtime.
22:56 bacek yes. Is it bad?
22:56 chromatic Your remaining option (as I see it) is to rewrite the op's behavior inside the op to perform the loop without letting the PMC handle it even if the PMC could handle it.
22:57 bacek something like this.
22:57 purl something like this is, like, tempting: http://www.zones.com/cgi-bin/zones/site/pr​oduct/index.html?id=000878057&amp;zone=zbs
22:57 chromatic In other words, no one now can write a NameSpace equivalent PMC that doesn't store nested namespaces in nested hashes because you've violated the encapsulation of the interface to force all NameSpace like PMCs to use nested hashes to store their nested namespaces.
22:58 bacek chromatic: it's violated in many-many places now.
22:58 chromatic As a matter of implementation, not of interface.
22:58 bacek internal_ns_keyed_key for examples
22:59 chromatic That's never called from ops.
23:00 chromatic It's only ever called from src/global.c which implements some of Parrot's namespacing behavior.
23:00 chromatic You can argue (and I might agree) that that code belongs in the NameSpace PMC, but that's a matter of code organization rather than design principles.
23:02 bacek So, design principle for Key is "All PMCs are equals. But some of them more equal"?
23:02 chromatic I don't know what that means.
23:03 pmichaud Optimization is all about exploiting inequalities for direct gain.
23:03 bacek ok. I've implemented Map PMC. Classical RB-tree based.
23:03 bacek Now, in get_pmc_keyed I have to distinguish Keys from all other PMCs?
23:04 chromatic Same as every other PMC does in get_pmc_keyed.
23:05 bacek yeah... At least 9 pmcs copy-paste code for this...
23:05 bacek ok. 5
23:05 chromatic If I had my druthers and a working L1-based nanoparrot, I'd turn all vtable entries into multis, distinguish between String, RSA, Key, and MultiKey PMCs, and get rid of most of this mess.
23:09 bacek but... we already have switch-optimised VTABLE generation for MULTIs.
23:09 chromatic We turn ALL vtable entries into multis.
23:09 bacek So we probably can start now without sacrificing performance
23:09 chromatic They're not written in C anymore, so we can optimize dispatch the same way we can optimize dispatch with an optimizing compiler.
23:10 chromatic We can share implementations.
23:10 bacek what about blah_int?
23:10 chromatic We can override them from PIR trivially without expensive checks.
23:10 chromatic We can define only those vtable entries that make sense on specific PMCs.
23:10 chromatic We can add vtable entries as they make sense.
23:10 Whiteknight chromatic: I would like to give you your druthers
23:11 bacek we can kill vtables.
23:11 bacek They are just METHODs.
23:11 Whiteknight we can't kill vtables entirely
23:11 Whiteknight otherwise how do you interface with PMCs?
23:12 bacek Question is: what difference between VTABLE and METHOD in L1 parrot?
23:12 chromatic VTABLE is always multi.
23:12 chromatic Any PMC must implement a series of VTABLEs to correspond to the VTABLE interface (though multidispatch takes care of a lot of that).
23:13 chromatic Any defined VTABLE has a well-defined semantic.
23:13 chromatic Other than that?  It's a wad of L1 ops like any other code in the system.
23:14 chromatic We'll probably have to store them in a different way to distinguish them from METHODs, like Python stores its in double-underscored slots.
23:14 bacek "Any PMC must implement a series of METHODs to correspond to.."
23:15 bacek I still don't understand why METHODs and VTABLEs are different.
23:15 bacek (In L1 parrot)
23:15 chromatic VTABLEs can't be user visible.
23:15 bacek why not?
23:15 Whiteknight the traditional difference between VTABLE and METHOD is that VTABLES are rigidly pre-defined
23:15 chromatic So users can't call them directly and accidentally.
23:16 Whiteknight chromatic: I would suggest in a post-L1 world that vtables should be more directly visible
23:16 chromatic To user code?
23:16 Whiteknight specifically, I suggest that just about all vtables will have a one-to-one correlation with L1 opcodes
23:16 chromatic I have no idea what that means.
23:16 Whiteknight so we have a get_number VTABLE, and a get_number L1 op
23:17 chromatic Oh goodness no.
23:17 Whiteknight and why not?
23:17 chromatic That's much too high level for L1 ops.
23:17 Whiteknight a single C function call is too high level?
23:17 chromatic Yes.
23:17 bacek Are t/pmc/packfile*.t failing only for me?
23:17 Whiteknight chromatic: so then what are the L1 ops going to be?
23:18 chromatic I have no small sympathy for libjit's ops.
23:19 Whiteknight okay, let me put it another way. What do you envision will be the L1 sequence to get the string representation of a PMC?
23:19 chromatic If there's an L1 op for each vtable call and if each one only makes a function call to the appropriate C function (or whatever) which implements that vtable entry on a PMC, why have the L1 op?  Why not make an L1 op that can call any vtable entry given its name or an identifier for the vtable entry?
23:19 bacek Whiteknight: I'm going to merge tt24_unicode_numifications into trunk. No new failures in Rakudo/Partcl
23:19 Whiteknight chromatic: we want L1 to be fast and trivially easy to JIT
23:19 chromatic Yeah, so why multiply entities?
23:20 Whiteknight we would be able to divide them down, cleaning out the bloated VTABLE interface as we translated
23:20 chromatic But all of those ops you propose do the same thing!  Look up a function and call it!
23:20 donaldh joined #parrot
23:21 Whiteknight right, but functions have different signatures, return different types of values, and don't all need to be called from L1
23:21 Whiteknight a one-to-one correspondence between the functions we need limits access to the ones we dont
23:21 chromatic L1 op: look up a function by name
23:21 Infinoid so, "lookup_vtable_function; call_vtable_function"?
23:21 chromatic There may need to be variable arity call_vtable_function ops, but yes.
23:22 chromatic Or at least multiple arity versions.
23:22 Whiteknight chromatic, so can we lookup_function_by_name "malloc"?
23:22 Infinoid call_vtable_function_p_s
23:22 chromatic Yes and yes.
23:22 Whiteknight that's madness
23:22 Whiteknight L1 is useless if it's just a new way of writing C
23:22 Infinoid that's simple.
23:22 chromatic man dlfunc
23:23 chromatic Who said anything about writing C?
23:23 Whiteknight well, not useless, but severly impaired
23:23 chromatic The purpose of this exercise is to avoid C.
23:23 Whiteknight you're saying that we're looking up any arbitrary C function by name, and then I assume we're going to have to manage the low-level calling conventions to invoke them
23:23 Infinoid It's simple enough to avoid getting bogged down in implementation details, which means the components should be easily reusable for JIT
23:23 Whiteknight that's C
23:24 Whiteknight if we're going to give it up, give it up wholesale
23:24 chromatic I didn't say VTABLE entries were written in C.
23:24 * japhb whispers innocently "Implement them in Forth ...."
23:25 chromatic I recall writing quite the opposite, really.
23:25 Infinoid $japhb =~ s/Forth/befunge/
23:25 chromatic Quiet, you!  I'm sticking with Smalltalk-80.
23:25 Whiteknight I won't fight you over the vtable issue, but what about other API functions?
23:26 chromatic We'll need a way to call C functions for NCI, yes.
23:26 chromatic We'll need a way to call into Parrot's backing library for some of this code.
23:26 chromatic If we have that, we can migrate more and more of it to L1.
23:26 Whiteknight not if we hardcode in some ops to call specific functions
23:26 Whiteknight by-name function lookups are needlessly slow and wasteful for core API functios
23:26 chromatic Sure, but why in the world would you *do* that?
23:26 dalek parrot: r39529 | bacek++ | trunk (6 files):
23:26 dalek parrot: Merge tt24_unicode_numifications branch into trunk.
23:26 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39529/
23:27 Whiteknight you do that to gain quick access to the functions you need
23:27 chromatic You do that if you hate L1 and kittens.
23:28 Infinoid Or if you really like strcmp() overhead
23:28 Whiteknight it's not hating kittens to think that the L1 "throw" op should internally call Parrot_ex_throw_from_L1_op directly
23:28 chromatic There won't be an L1 throw op.
23:28 chromatic That's too high level for L1.
23:28 chromatic The thought makes me throw op!  (Okay, sorry.  (Okay, I'm not sorry, but I'm a little sorry I'm not sorry.))
23:29 Whiteknight I think you're being needlessly limiting
23:29 Infinoid chromatic: Is there a way to implement this without spending most of your time in string comparison functions?
23:29 chromatic Sure, the same way you optimize other constant lookups.
23:29 Whiteknight L1 ops should atomicly perform the operations that Parrot can understand, and Parrot understand more then just basic arithmetic and pointer munging ops
23:30 Whiteknight if L1 is going to be just another name for an LLVM-style static language bytecode, I want none of it
23:31 chromatic It's pretty easy to assume (as ld does) that when you dlfunc a named function from a shared library, that function won't change very much throughout the process.
23:32 chromatic You have to perform the lookup once, but you can cache it and skip all subsequent lookups.
23:32 Whiteknight okay, I'll even ignore that issue. But what about calling those functions? We're going to have to manually pass low-level arguments
23:33 Infinoid ok, so you're using a runtime cache for imported symbols.  Sounds almost like a PLT.
23:33 Whiteknight and that's going to be a huge nightmare as we try to support more platforms
23:33 Whiteknight and our goal for 3.0 is to support more platforms, not less
23:33 chromatic How is that a nightmare of support?
23:34 Infinoid I would expect the JIT backend to get the C calling conventions right, internally
23:34 Whiteknight managing our own low-level C calling conventions?
23:34 Whiteknight Infinoid: Then we're artificially limited to only the platforms where our JIT engine of choice is supported
23:34 Infinoid no, libjit should handle that
23:34 Whiteknight and neither libJIT or LLVM have expansive platform support
23:35 Infinoid Ok.  What does this have to do with L1?
23:35 chromatic L1 doesn't require a JIT.
23:35 chromatic It makes JIT easier.
23:35 Whiteknight it's a question of scope: how much should L1 be.
23:35 chromatic ... but we can do L1 without a JIT on platforms in environments where JIT doesn't make sense.
23:36 Whiteknight chromatic: then how are we doing NCI calls with arbitrary argument lists?
23:36 chromatic How do we do them now?
23:36 Whiteknight either using JIT, or by painfully pre-constructing thunks in C at compile time
23:36 dalek parrot: r39530 | bacek++ | trunk/src/string/api.c:
23:36 dalek parrot: [cage] Cast to unsigned char in str_to_int and str_to_num.
23:36 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39530/
23:37 Whiteknight the first is too lmiting, and the second is The Wrong Way
23:37 chromatic Thus our possibility for regression is low.
23:37 Whiteknight at least there's a silver lining
23:38 chromatic We don't lose anything NCI-wise this way.
23:39 Whiteknight would you be willing to put together a preliminary list of what you envision the L1 opcode set to look like?
23:39 chromatic Sure.
23:39 Whiteknight because I'm very interested to see what you have in mind specifically
23:39 SpacemanSpiff joined #parrot
23:39 chromatic It looks a lot like libjit's instruction set.
23:40 Whiteknight there is a significant dearth of good libJIT documetation on the interschmoe
23:40 chromatic alloc sized chunk of memory, free sized chunk of memory, read sized chunk of memory by offset, write sized chunk of memory by offset, branch, call function, blah blah
23:40 chromatic You might be able to find the Smalltalk-80 low level instruction set documented somewhere.
23:40 chromatic I think the blue book is available online.
23:41 * Whiteknight is searching no
23:41 Whiteknight now*
23:42 chromatic What's your take on the crackworthiness here, Infinoid?
23:42 Whiteknight meh, can't find it. I'll take your word for it though
23:43 chromatic http://stephane.ducasse.fr​ee.fr/FreeBooks/BlueBook/
23:43 chromatic Part IV
23:43 chromatic http://wiki.squeak.org/squeak/1602
23:44 Whiteknight thanks
23:44 Whiteknight all the links I found were subscription
23:45 Whiteknight i think it's a bad idea to make L1 too low level. We don't gain anything by mindlessly replacing C with a homebrew portable assembly
23:45 Infinoid freezing/thawing L1 is a fascinating idea to me
23:46 Infinoid I think the process of loading L1 will look an awful lot like runtime linker relocation
23:46 Whiteknight C does have it's moments, and a lot of Parrot core is well served by it
23:46 chromatic We gain a lot by avoiding C -- calling conventions, dispatch, memory model.
23:46 Infinoid loading necessary dynpmcs and preloading symbol tables
23:46 Infinoid or loading dyn<whatever>s
23:46 Whiteknight calling conventions and dispatch are already going to be in L1, and that's only a small part of everything.
23:47 Whiteknight we aren't really losing the C memory model with low level "allocate sized chunk" and "write to pointer" ops
23:48 chromatic Depends if we support C pointers.
23:48 Infinoid You have to, if you don't directly support PMC registers
23:48 chromatic I think we can get around that with some cleverness.
23:49 Coke clever?
23:49 Infinoid if the intention is to sit well below the whole OO layer of things, then I suggest supporting C pointers is probably a good idea
23:49 purl There's a fine line between clever and stupid.
23:49 chromatic My guiding principle is that TraceMonkey gets faster every time they write more JavaScript in JavaScript.
23:49 Coke for comparison, partcl gets slower every time I write more of it in tcl.
23:49 Coke (loading init.tcl is SLOOOOW)
23:49 Coke but tcl is just crazy.
23:49 chromatic Let's not even talk about your test.tcl.
23:50 Coke Can I interest you in some pair programming?
23:50 chromatic I'm not sure if you're serious or coming back with a worse pun.
23:52 Coke pun.
23:53 chromatic The average American has one.
23:53 Coke ^_o
23:54 Coke I was thinking it would be interesting to write some of the tcl builtins in nqp.
23:56 Coke how expensive is invoking a PIR sub from a PIR sub? if I can trivially inline it, should I?
23:57 Whiteknight chromatic: but the more JavaScript you have, the more JavaScript you can write in it quickly
23:58 chromatic Right, but they're talking about bootstrapping JS.
23:58 chromatic Coke, it depends on how frequently you call it.  You save a contininuation allocation and a couple of contexts.
23:58 Whiteknight the set of L1 ops needs to be large enough to do the things that Parrot needs to do without having to execute a million ops to make it happen
23:58 Coke well, if contexts leak, that's a win. =-)
23:59 Coke tcl has a lot of subcommands; so [array exists], [array get] are all the same [array] command; I'm dispatching that to other procs, but I could trivially inline them.
23:59 chromatic Op dispatch is cheap, especially if we can JIT them.

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

Parrot | source cross referenced