Parrot 1.2.0 released | parrot.org/ | Weekly Priority: Profiling | Parrot VM Workshop, Pittsburgh, June 20-21
Set by moderator on 7 June 2009.
cotto It sounds like a good way to explain L1 would be microcode. 00:08
darbelo RISP: Reduced Instruction Set Parrot 00:10
00:13 gryphon joined
mugwump hey, and here's an idea: you should only need to vtable the reduced instruction set instructions 00:22
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?
not selecting on the argument type? 00:38
chromatic They all select on argument type.
They select on all argument types?
dalek rrot: r39513 | jkeenan++ | trunk/src/pmc/handle.pmc:
Correct POD syntax error, allowing for what the author probably intended.
 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' ?
Actually I don't quite understand why functions that take PMC arguments are vtable'd 00:45
rather than being just methods
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:46
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.
1.4 is schedule for release on July 21. 00:49
*scheduled
kesselhaus cool, and perl6 will be released again too? ;)
pmichaud_ The next release of Rakudo will be on Jun 18 (Thu) 00:50
mugwump kesselhaus: Christmas!
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.
mugwump ^^ see! :)
pmichaud_ the July release of Rakudo will be two days after the July release of Parrot -- likely July 23.
We don't have a name for the Rakudo July release yet -- suggestions welcomed. :-)
kesselhaus rakudo-1.3? ;) 00:51
Whiteknight cotto: I had the same thought, they do sound quite a bit like microcodes 00:53
pmichaud_ :)
well, I already rakudo's july release will be #19 and rakudo-2009-07 00:54
*already know
I'm looking to see what Perl Mongers group to name it after.
It's likely to be DFW.pm, unless I see a reason to put another group in that slot 00:55
Whiteknight irclogs 01:02
irclogs?
purl i think irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
pmichaud_ I found the utf8 bug. 01:32
Tene japhb: still having issues or questions?
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?
src/string/encoding/utf8.c:591 01:36
WTF?!? 01:49
Tene hm?
pmichaud_ okay, I agree with NotFound -- all of the strings code is b0rken.
badly b0rken.
like, there's no possible way this stuff could work sort of broken.
Tene :) 01:50
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/... ?
bacek PBC, STRING, you name it... 01:55
Ah. Keys!
Tene japhb: probably depends on what it is.
bacek Other way round - having single representation for totally different things
japhb .../NCI/call_toolkit_init.pir ... which, as far as I can tell, is only used by the OpenGL code
Tene japhb: then just change it, IMO 01:56
japhb excellent
pmichaud_ iiuc, libraries have to go through a deprecation cycle.
that would include NCI/call_*
japhb ... sigh 01:57
well, I can always just create NCI/Utils.pir and mark the old one deprecated, yes? 01:58
pmichaud_ japhb: yes.
japhb Was 1.0 considered a 'supported release'? Or is 1.4 the first? 02:01
pmichaud_ 1.0
japhb damn
pmichaud_ yes, 1.0 is a 'supported release' (the first)
japhb OK, so anything marked deprecated by the time 1.4 is released is eligible for removal immediately after 1.4, right? 02:03
(so listed in DEPRECATED.pod as eligible in 1.5) 02:04
pmichaud_ correct.
japhb OK, so now I just have to see if I have working Trac access .... 02:05
Infinoid Hello, #parrot
Infinoid is going through updating his machines to EDT5EDT (silly east coast, scheduling sunrises at 3am) 02:07
s/EDT5/EST5/
02:07 eternaleye joined
Tene hullo inf 02:09
02:09 kid51 joined
kid51 Whiteknight ping 02:16
Whiteknight kid51: pong
kid51 u probably know this, but ... we need a test file t/pmc/handle.t to shut up a codingstd test. 02:17
Whiteknight yeah, I was working on that tonight but got sidetracked. 02:19
I'll get all those tests passing tomorrow
There's a ticket for it already, so I'm on top of it 02:20
but I'm going to bed now, so I'll talk to you later
Infinoid Whiteknight++
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 02:27 eternaleye joined
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
The former tends to get run only as part of 'make fulltest'.
Well, particle wrote the first version, so i assume he had a reason for putting it there. 02:29
Yeah, I would never think to run make full_test on a branch.
dalek rrot: r39514 | jkeenan++ | trunk (1 files):
Create t/pmc/handle.t. No real tests of functionality yet.
 02:36
kid51 cotto ping 02:37
Infinoid ah, ok. I think codetest would be a better place for it 02:38
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
dalek rrot: r39515 | jkeenan++ | trunk (1 files):
1. Clarify messages in 3 tests; we're requiring test files for each PMC

2. Move test to t/codingstd/ so that it gets run more frequently, as part of
  'make codetest'.		 02:46
rrot: r39516 | jkeenan++ | trunk/t/codingstd/test_file_coverage.t:
Correct typo in test message.
 02:52
03:20 donaldh joined 03:28 gryphon joined 03:30 silug joined
dalek kudo: a2b8ceb | pmichaud++ | src/parser/actions.pm:
Bare parens should return Nil. TimToady++
 03:38
eternaleye I suddenly find myself sorely tempted to write a compiler for POSIX sh. 03:42
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.
Infinoid But other than all the I/O and child process handling, the language itself doesn't seem that complicated
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
You'd need a clever name for your parrot shell :)
eternaleye Parsh - the mushmouthed POSIX shell 03:46
Infinoid heh
eternaleye "Even parch can parse Parsh" 03:47
Gah, "Even parsh can parse Parsh"
04:49 zak_ joined 05:09 ZeroForce joined
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:34
or just as functions in the parsh pbc, which checks the name it was called with. 05:35
like busybox
NotFound And if you call them as internal commands, it may even be a lot faster than conventional shells. 05:37
dalek rrot: r39517 | cotto++ | branches/pmc_pct/compilers (13 files):
[codingstd] fix some (but not all) codingstd failures in pmc_pct
 05:38
NotFound msg pmichaud_ src/string/encoding/utf8.c:591 looks wrong, certainly 05:39
purl Message for pmichaud_ stored.
05:39 uniejo joined 05:42 uniejo joined
cotto That's nuts. I'm amazed that we've got almost 50 people coming to the pmvw. 05:54
I wonder how much awesome can be added to pmc_pct by that time. 06:09
06:09 cognominal joined
cotto Can I safely assume that a PMC is an aggregate if it doesn't do scalar? 06:59
chromatic I don't think you can; I'm not sure we're aggressive about marking aggregates with or without that metadata. 07:03
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:04
Is there some existing code I can use to make a deep clone of a PMC? 07:11
07:14 mikehh_ joined 07:21 donaldh joined
dalek kudo: d2b24d8 | tene++ | src/builtins/eval.pir:
Fix the keyword for loading a foreign library (japhb++)
 07:27
07:28 masak joined 07:31 viklund_ joined
dalek TT #753 created by japhb++: Deprecate NCI/call_toolkit_init.* in favor of NCI/Utils.* 07:31
rrot: r39518 | japhb++ | trunk (4 files):
Deprecate r/t/l/NCI/call_toolkit_init.* in favor of .../NCI/Utils.*
 07:37
kudo: e61569f | tene++ | src/parser/actions.pm:
Oops... fix the keyword in one more place too.
 07:39
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:40
Tene japhb: not at all. you're the first user of the 'parrot' compiler. 07:41
japhb: as long as it still responds to 'load_library' with the same API, you can do whatever you feel is best.
japhb :-)
.oO( Oh Subversion, why can't you be Git? )
 07:42
Tene japhb: I never use svn for parrot... every time I've tried, I've screwed it up. 07:43
dalek rrot: r39519 | japhb++ | trunk/runtime/parrot/languages/parrot/parrot.pir:
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.
Tene I'll review real quick...
japhb: that's great 07:46
japhb Thanks! What is? :-) 07:47
The new export()?
Tene japhb: yes
japhb cool, glad you like it
dalek rrot: r39520 | japhb++ | trunk/runtime/parrot/library/OpenGL.pir:
[OpenGL] improve ambiguous names; support new experimental HLL export
Tene japhb: do you have an example of using OpenGL from rakudo? 07:48
japhb Tene: working on commit message now. ;-)
Tene :D
japhb OK, with the commit that should be coming through any minute, I believe I am all pushed now. 07:53
dalek rrot: r39521 | japhb++ | trunk/examples/opengl (6 files):
[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
nopaste "tene" at 166.70.38.237 pasted "japhb: I don't think it's supposed to do this..." (7 lines) at nopaste.snit.ch/16875 07:57
japhb Tene: That looks like you have an insufficient GL driver. 07:58
Tene Spooky.
japhb Do static-triangle.p6 and triangle.p6 work?
Tene No. Same error.
japhb huh. 07:59
And the .pir versions?
08:01 barney joined
Tene same output 08:01
japhb Tene: er ... am I correct in assuming you realcleaned and redid configure and make with the bleed parrot? 08:02
And what is your OS and hardware? 08:03
Tene I did earlier today... I'll try again.
fedora linux x86_64
japhb video hardware?
purl video hardware is probably known to suck
japhb purl finally gets one right
purl japhb: what?
japhb purl, botsnack
purl thanks japhb :)
Tene 01:00.0 VGA compatible controller: nVidia Corporation Quadro FX 570M (rev a1)
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?
japhb Nope, I'm on proprietary drivers with nvidia hardware, so that's no diff. 08:05
(Mind you, this laptop is 32-bit and running Debian, but I think that's minor.)
Tene same failure after realclean
japhb is nuking everything and rebuilding too 08:06
but it's a laptop, it will be a couple more minutes
s/laptop/old laptop/
08:07 riffraff joined
japhb Tene, would you mind posting 'glxinfo' output, plz? 08:09
nopaste "tene" at 166.70.38.237 pasted "japhb++ glxinfo" (620 lines) at nopaste.snit.ch/16876
mikehh t/op/debuginfo.t - TODO passed: 1, 7-8 smolder smolder.plusthree.com/app/public_pr...ails/23580 08:12
japhb Tene: are you running compiz or suchlike? GL compositing for the desktop?
Tene No. 08:13
japhb Grrr.
Running out of ideas.
Trying a build on a 64-bit desktop, to see if its a 64-bit problem 08:14
bacek tt.ro.vutbr.cz//file/cmdout///32321.txt 08:16
tt.ro.vutbr.cz/report/pr-Parrot/rp-trunk
Looks good
08:17 zak_ joined
cotto anyone here know namespaces? 08:23
Tene kinda 08:24
what's up?
purl Me, you bitches! I'm high on crack!
Tene shut up, purl.
purl make me
Tene purl: what's up is <reply>
purl tene: bugger all, i dunno
Tene FINE.
cotto: ?
cotto I'd like a sanity check on a patch
Tene I'll try.
nopaste "cotto" at 75.92.174.97 pasted "patch to simplify pmc2c" (74 lines) at nopaste.snit.ch/16877 08:25
cotto The important part is the first chunk.
Tene That's rather outside of my experience; sorry. 08:26
cotto np
no, what's up is <reply>
purl well, <reply> is maybe... or
cotto no, (what's up) is <reply>
what's up? 08:27
purl The birds, the sky, and the ceiling.
cotto what's up?
purl The Canadian Dollar
cotto literal what's up?
chromatic That simplification looks good, but I don't immediately grasp the implications.
... but it appears that the limitations are the same.
ttbot japhb: Parrot trunk/ r39520 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/32374.txt 08:28
japhb: Parrot trunk/ r39521 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/32378.txt
japhb What is ttbot? 08:29
chromatic A build bot.
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.
btw, chromatic++ for that mj alias 08:30
chromatic You're welcome.
japhb The txt files it's sending me appear to be garbage.
chromatic The system doesn't have nmake installed? 08:32
cotto Just deleting the special case also causes no new test failures. It looks like that function gets test coverage. 08:33
It might just be because multiple threads are very poorly tested.
chromatic That's true also. 08:35
cotto Is it ok if I commit the nopasted version of the patch? 08:37
mj41 sorry, no path :-( 08:38
after winXP auto update restart - will fix this soon 08:39
chromatic cotto, go ahead.
japhb Tene: unfortunately, can't reproduce your failure. IWFM on AMD64 as well. 08:41
japhb wonders if Tene's system has some other problem, like a busted freeglut. 08:42
Tene japhb: how would I notice that? 08:43
japhb hmmm
OK, sanity check: glxgears works?
Tene yes
dalek rrot: r39522 | cotto++ | trunk (2 files):
[pmc2c] make some special-case code the common case
 08:44
Tene 8.8k FPS
japhb wheeee
Hmmm, one difference is that my drivers report OpenGL version 2.1.2, rather than 3.0.0 ... 08:46
Good old Debian backrev drivers, sigh.
Although ... that could be because my video cards are just a tad too old for OpenGL 3. Hmm. 08:47
Tene: grep 'VERSION\\|IMPLEMENTATION' /usr/include/GL/freeglut_std.h 08:49
Tene #define GLUT_API_VERSION 4 08:50
#define FREEGLUT_VERSION_2_0 1
#define GLUT_XLIB_IMPLEMENTATION 13
japhb damitol
08:56 clinton joined
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:57
However, it's 2 AM. I need to get some sleep. 08:58
Tene looks like my freeglut is 2.4 08:59
not 3
japhb Anyone else, I'd appreciate some testing of the current OpenGL examples.
Tene: your defines were the same as mine. :-/ 09:00
Tene anyway, I need to go too
Chat later.
japhb Tene: any objection to bumping the Parrot revision requirement for Rakudo?
To 39521, I guess? 09:01
Ah, OK, ttyl
Tene japhb: you want to ask pmichaud, not me.
japhb OK, will do tomorrow, thx
mj41 TapTinder client "pc-strakos" auto start fixed (added "Setting environment for using Microsoft Visual Studio 2008 x86 tools."). tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk 09:04
09:06 bacek joined
bacek oh hai... 09:14
Tene hi bacek 09:25
bacek hi Tene. How is HLL stuff going?
Tene going very well
my main blocker is other HLLs to work with. :) 09:26
bacek :)
Tene Feel free to help me out here... you have a common lisp implementation stashed away anywhere? 09:29
bacek: I just posted this earlier: gist.github.com/128499
bacek wow! 09:30
Tene++ # HLL ftw
Tene I wrote it two weeks ago, I think, on an airplane.
Then forgot about it.
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
didn't happen a month ago, but it does now.
bacek have a backtrace?
Tene trac.parrot.org/parrot/ticket/744 09:32
something invalid gets stored in the pmc registers of a context
0x21 iirc, as a PMC pointer
bacek checking
purl checking is probably just different
Tene no, 0x1 09:34
nopaste "tene" at 166.70.38.237 pasted "bt for bacek" (114 lines) at nopaste.snit.ch/16879 09:35
bacek Tene: ok... It's all refcounting and Whiteknight faults :) 09:44
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.
bacek Tene: refcounting is bigger problem. OTOH Whiteknight can implement Contexts as GCable PMCs :) 10:25
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:44
10:52 payload joined 10:55 muixirt joined
nopaste "muixirt" at 91.47.108.143 pasted "/perl6 --target=pir -e 'while 1 { };'" (122 lines) at nopaste.snit.ch/16881 10:58
muixirt the while loop leaks lots of memory, is it sole problem of parrot? 10:59
Infinoid Probably. If you could reduce it further (so it doesn't depend on perl6.pbc), we would know for sure 11:11
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:15
11:21 donaldh joined 11:35 particle1 joined 11:36 mberends joined 11:42 kj joined
Infinoid muixirt: Right, but the previous Int should eventually get GCed 11:47
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:51
that is only the case of requests >128kB 11:53
Infinoid muixirt: I think we're using the system malloc in most/all cases, not dlmalloc 12:00
at least, on my machine, malloc.c isn't built 12:01
mmap could also be used for jit buffers, or something else entirely 12:03
12:06 burmas joined 12:10 elmex joined
muixirt Infinoid, you are right, it isn't built on my machine either, but system's malloc calls mmap too 12:10
Infinoid okay. that just means it's harder to read in strace :) 12:16
(though mmap() is arguably a lot cleaner than sbrk()...)
12:51 Whiteknight joined 12:54 szabgab joined 13:03 Util joined
dalek rrot: r39523 | whiteknight++ | trunk/src/pmc/default.pmc:
[codingstd] remove trailing whitespace from default.pmc
 13:04
13:22 skids joined
Whiteknight irclogs? 13:28
purl it has been said that irclogs is irclog.perlgeek.de/parrot/today or see also: infrared clogs
13:38 ruoso joined 13:39 ruoso joined 13:41 ruoso joined
Whiteknight Tene: ping 13:41
13:43 ruoso joined 13:44 ruoso joined 13:47 skids joined 13:48 gryphon joined, particle joined
Coke de-cloaks. 13:49
de-cokes?
particle i see you haven't de-punned 13:50
Coke still cokes run deep. 13:54
Whiteknight wahwah 14:06
(bad puns)-- 14:12
karma bad puns
purl bad puns has neutral karma
Whiteknight (bad puns)-- 14:13
karma bad puns
purl bad puns has karma of -1
Coke (bad puns)++ ! 14:24
Whiteknight it would be negative karma too, if it wasn't for you meddling kids 14:27
Coke kills another use of multiple PMC inheritence. 14:36
Coke tries to think of a way to make tcl's types play nice with parrot's types. 14:39
(for me, an RPA is a scalar. =-)
Whiteknight great 14:40
14:40 burmas left
dalek rtcl: r478 | coke++ | trunk/ (5 files):
Remove TclObject, minor pmc cleanups

between the scalar types; but it was not universally used, and we want more custom behavior, and this will simplify efforts to switch to PIR classes instead of PMCs.		 14:40
14:41 payload joined 14:48 Theory joined
Coke hurm. 'self' should work in a :vtable, no? 14:56
pmichaud should, yes. Might still need :method. 14:57
Whiteknight Coke: it's unreliable 15:00
not in all vtables
and usually you need to add :method too 15:01
Tene Whiteknight: pong 15:08
15:09 particle joined
Coke Whiteknight: that sucks. 15:13
purl The rock is now off.
Coke hurm. 15:14
doesn't help. minipaste:
ha. my fault. 15:15
$P1 = get_iter self # get_iter is a method on a TclArray; I wanted 'iter' 15:16
15:20 donaldh joined
dalek rtcl: r479 | coke++ | trunk/ (5 files):
Convert the dict PMC to a class.
 15:25
rtcl: r480 | coke++ | trunk/src/pmc/tclint.pmc:
remove (now?) useless vtable override.
 15:41
15:45 ascent joined
Whiteknight Coke: Yeah, we're working on it 15:47
Tene Whiteknight: pong 15:50
dalek rtcl: r481 | coke++ | trunk/src/pmc/tcllist.pmc:
remove (now?) useless vtable override
Whiteknight Tene: what's going on with TT #744? 15:52
because I didn't think I had anything to do with it
besides it being GC-related, and me doing GC stuf 15:53
Tene Whiteknight: Eh, just harassing you because bacek said so. Nothing more.
I'm not sure it's GC-related, actually. It's just that the GC triggers it.
There's a 0x1 value in a context where a PMC * should be 15:54
(obviously segfault when dereferenced)
dalek rrot: r39524 | whiteknight++ | trunk/t/pmc/handle.t:
[t] fix t/pmc/handle.t do do what it should. Also, rewrite it in PIR not Perl5
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:04
pmichaud you mean specifically for multi vtables? 16:08
or for methods in general?
in my experience, defining a method in a PIR subclass hides all similarly-named methods in its parent classes, regardless of :multi 16:09
I don't know if that holds for vtables
Coke I specifically care about the divide vtable. 16:12
if it's divide(integer,_), I want to override, otherwise, don'tcare.
(This works at the PMC level, but fails in pir.)
I'm experimenting with eliminating my PMCs to avoid the PBC/C barrier. 16:14
crap. I think I might have missed a namespace declaration in my new class file that might explain the issue. 16:22
16:25 Psyche^ joined, chromatic joined
dalek kudo: 9aa210f | pmichaud++ | src/setting/Array.pm:
Remove incorrect constraints on splice() arguments.
 16:58
kudo: 31443c0 | pmichaud++ | src/classes/Str.pir:
Add some more ranges to Str.succ .
17:32 itrekkie joined 17:39 itrekkie left
japhb pmichaud: What "type" should this experimental deprecation TT be? "Roadmap"? 17:40
japhb assumes so ... can always change it later 17:42
dalek TT #754 created by japhb++: Mark new cross-HLL export/import as "experimental" by pre-deprecating it 17:43
japhb OK, TT and DEPRECATED.pod done. 17:50
Coke bah, was just editing deprecated.
I may have some edits for you. =-)
japhb: HA! perfect. 17:51
japhb :-) 17:52
Coke I have a more generic experimental notice at the top (already using the same [tag] you did.)
japhb excellent.
Coke I'll just remove the more specific version of the text you have for that item.
japhb np
dalek rrot: r39525 | japhb++ | trunk/DEPRECATED.pod:
Pre-deprecate cross-HLL library loading design and implementation
 17:53
Coke Done. 17:56
ok, now done. 17:58
japhb Wording in footnote is a tad confusing. Mind if I copy edit? 17:59
18:00 HG` joined
Coke nope. 18:00
dalek rrot: r39526 | coke++ | trunk/DEPRECATED.pod:
Extend the [experimental] notes a bit.
rrot: r39527 | coke++ | trunk/DEPRECATED.pod:
fix pod-o
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
Better?
(Only part after semicolon has been changed) 18:04
18:05 mikehh_ joined
japhb commits ... it's not like we'll run out of revision numbers if Coke wants to change it again. :-) 18:06
dalek rrot: r39528 | japhb++ | trunk/DEPRECATED.pod:
Clear up confusing wording in [experimental] footnote
 18:07
18:10 gryphon joined
Coke japhb: sorry, yes, that's clearer. 18:20
chromatic: ping. 18:21
japhb Tene: Do you Configure your Parrot with --optimize ? 18:40
It's occurred to me that may be a difference between our systems.
japhb tries unoptimized 64-bit build .... 18:41
chromatic pong 18:44
Coke chromatic: based on previous conversations, moving code from C to PIR is, in general, desirable for HLLs? 18:55
chromatic In general, yes. 18:56
Coke k.
chromatic The results depend on what you can accomplish and how often you might have crossed the Rubicon in the mixed language version however.
nopaste "muixirt" at 91.47.108.143 pasted "PIR example that leaks memory" (8 lines) at nopaste.snit.ch/16885 18:57
Coke I'm just trying to avoid cross the PBC/C boundary as much as possible. 18:58
19:00 Zak joined
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:00
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?
Coke muixirt: leaks as reported by valgrind, or checked manually via top? 19:02
japhb muixirt: it should have, yes. :-)
muixirt Coke, via top
chromatic top lies.
Coke ok. if you force a GC run each time through the loop, you might see different results.
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
("off" as in "wonky")
chromatic Sure, but top lies.
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.
muixirt chromatic, but strace -c doesn't lie, at least not on my system ;-)
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.
japhb awww.
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.)
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.
Coke you can dump out the pmcs allocated inside the loop, though. 19:08
japhb Coke: who was that comment to?
Coke code.google.com/p/partcl/source/bro...os.pir#156 (Though that hasn't been updated in a while)
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
it works for both PIR classes and PMCs
Coke pmichaud: k.
nopaste "coke" at 72.228.52.192 pasted "pmc vs pir" (66 lines) at nopaste.snit.ch/16886 19:11
pmichaud it's worth noting that PIR classes are currently about 3x slower than PMCs 19:12
(at least as far as creating them goes)
I should rephrase
creating objects from PIR classes is 3x slower than creating PMC objects
chromatic The "die" looks a little severe.
Coke chromatic: but equivalent to the thrown exception before. 19:13
Whiteknight 3x slower? I'm surprised that it's not worse
pmichaud well, it depends somewhat on what's being created, yes.
chromatic Is "die" catchable? 19:14
Coke whoops. I missed a return on check_undef.
chromatic: yes.
Whiteknight I've got a very interesting paper here from cotto++ about a GC that should negate pauses entirely 19:15
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.
chromatic Is it the realtime G1 collector?
Whiteknight no, it's the VCGC collector
I don't think I know G1
oh, G1 is the new collector for the Java VM, right? 19:17
chromatic Garbage first.
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
muixirt: There are two sources for memory allocations: the GC and direct malloc calls 19:20
we're only worried about leaks from the direct malloc calls
19:20 donaldh joined
particle venture capital garbage collector? 19:21
muixirt Whiteknight, so it is a GC problem? 19:23
Whiteknight muixirt: probably not. Our current collector is simplistic, but relatively accurate 19:25
more likely the problem stems from one of the million other places that allocate and manage memory directly from the system 19:26
19:26 szabgab joined
Whiteknight Very Concurrent Garbage Collector 19:26
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.
muixirt Whiteknight, limiting vir. mem. gives Parrot VM: PANIC: Out of mem! C file src/gc/alloc_memory.c, line 142
chromatic If it *were* too conservative collection, I'd expect it to run out of memory faster.
Whiteknight is there more information about this particular bug anywhere? 19:28
19:33 bobke joined 19:37 estrabd joined 19:41 viklund_ joined
dalek kudo: de1e9f0 | moritz++ | docs/ChangeLog:
[docs] initial changelog for 2009-06 release
 19:43
Tene japhb: I do not use --optimize 19:50
mj41 another out of mem trac.parrot.org/parrot/ticket/706
19:52 bacek joined
Coke grumbles 20:10
dalek rtcl: r482 | coke++ | trunk/runtime/builtin/namespace.pir:
use fewer opcodes
 20:19
TT #755 created by doughera++: 'make install-dev' assumes "modern" File::Path 20:24
mj41 added Mac OS tt.ro.vutbr.cz/table/machine/id-11 to TapTinder 20:31
20:39 Andy joined
eternaleye purl: msg Whiteknight cs.nju.edu.cn/gchen/paper/ipdps2002...13_161.PDF (aka MCGC) claims it outperforms VCGC 20:41
purl Message for whiteknight stored.
eternaleye Oh this is amusing. The google-hosted HTML version of the VCGC paper has effectively been sed'ed with s/fi//g 20:46
chromatic They probably can't render the proper ligature. 20:47
eternaleye Hm, maybe more like s/f+.//g
Since efficiently became eciently
pmichaud nopaste.snit.ch/16885 # why does Parrot GC fail to reclaim things here during runtime? 20:53
chromatic It could be the GC threshold tweak I applied a couple of weeks ago. 20:54
I doubt that.
It could be that something's too aggressive about marking a context as alive.
I doubt that too.
pmichaud there's not a context involved here, though.
I mean, afaict, we aren't creating any new contexts.
unless it's the evil mmd stuff at work again.
chromatic Sure, but that Integer only gets marked because it's in a context.
pmichaud I don't understand. 20:55
chromatic It's in a register which is in a context.
Nothing else refers to it (that I can see).
pmichaud right, but the register is constantly being updated to point to a new Integer
so why aren't the old ones being reclaimed?
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.
pmichaud sure, I understand that 20:56
iiuc, there's only one context in play here, yes?
that context contains the $P0 register
marking the context causes the PMC that the $P0 register points to to be marked
chromatic One or two. I'm not sure if calling main uses the initial context or creates a new one.
There should be only one PMC marked in this context though.
pmichaud either way, while we're in the loop we're not creating new contexts
(note that it's an infinite loop) 20:57
chromatic Right, unless something called from one of the ops creates a context.
pmichaud I'm guessing that must be the case
because this one context would only be marking one PMC. That doesn't explain what's eating up all of the memory 20:58
i.e., something isn't being reclaimed
chromatic I think so too. I haven't had a chance to dig into it yet though.
bacek morning, good morning 21:00
nopaste "pmichaud" at 72.181.176.220 pasted "This leaks also, only faster." (6 lines) at nopaste.snit.ch/16887 21:01
bacek I have a question: why Namspace is-a Hash, not has-a Hash? 21:02
pmichaud bacek: what would Hashes do that Namespaces should not? 21:03
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?
bacek (get|set)_*_keyed_*
at least all those overrided. 21:05
pmichaud right. But there are a lot of methods in Hash that probably aren't overridden
get_iter is a big one
bacek And I want to kill it... It's total kludge. 21:06
pmichaud Hash defines 64 VTABLE functions.
Namespace defines 28.
Therefore, Namespace cannot be overriding all of Hash's methods. 21:07
bacek gimme sec. I'll switch to trunk to check.
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
for something like nopaste 16887, what would normally trigger a GC run?
because afaict there's never any GC taking place. 21:09
chromatic Running out of available PMCs in the free pool should trigger it.
pmichaud hmmm.
would I see that in a trace? ISTR seeing things like "DOD" in traces before, but I'm not seeing one here.
chromatic I think it's Parrot_gc_run something or other. 21:10
pmichaud 773:Parrot_gc_mark_and_sweep 21:11
bacek pmichaud: Namespaces are nested Hashes. Not plain one...
pmichaud bacek: they can act like hash-of-hash, yes.
bacek and something like 'get|set_integer_keyed' doesn't make sense for namespaces... 21:12
or I missed something
pmichaud bacek: get_integer_keyed is just enabling something like ns[0] to act the same as ns['0']
that's true for hashes as well. 21:13
you can throw it out, but it doesn't really hurt for it to be there.
bacek pmichaud: not in current Namespace implementation
pmichaud bacek: hmm...?
how do you mean "not in current Namespace implementation"?
oh, sorry, I was thinking keyed_int 21:14
bacek ns = ['foo';'bar';'baz']
pmichaud it's just enabling $I0 = ns['key'] to work
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
pmichaud anyway, it's not been a problem I've ever run across.
bacek I'm trying deuglyfy Keys... And this is one of menay problems I found so far. 21:16
many
chromatic That's not the worst problem with Keys by far. 21:17
bacek As far as I can see, worst problem of Keys is existence of Keys... 21:18
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
in general, perl folks expect namespaces to act like hashes.
bacek get_pmc_keyed_int? 21:21
LSP totally broken for Namespace/Hash pair. 21:22
pmichaud especially get_pmc_keyed_int
if I do: my $a = 3 + foo(); my $b = $ns{$a}
I expect it to work, even if $a is an Int
bacek ok. What about get_integer_keyed? 21:23
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>}
pmichaud it might just mean we should convert those methods to throw exceptions
bacek But Namespace override all operations which make sense for Namespace 21:25
So, If Namespace has-a Hash, all unimplemented methods will throw exception.
And in meaningful methods Namespace can call VTABLE_get_foo(hash) instead of SUPER(). 21:26
pmichaud and VTABLE_isa ...? 21:27
bacek "Namespace"
purl hmmm... "Namespace" is like "domain" though
pmichaud no, I mean if I ask if Namespace isa Hash ... ? 21:28
bacek But VTABLE_does(hash) == true
pmichaud you're going to change the isa relationship to be false, yes?
bacek I claim that "Namespace isa Hash == true" is misleading.
pmichaud not to perl folks it isn't. 21:29
bacek Why?
pmichaud because we expect our namespaces to be hashes.
bacek "to be" or "to act like"?
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
21:30 viklund_ joined
bacek e.g.? 21:30
purl e.g. is `exempli gratia', latin for `for example'
pmichaud get_iter
purl get_iter is a vtable function
pmichaud elements
purl elements is at www.privatehand.com/flash/elements.html
bacek purl: shut up 21:31
purl make me
pmichaud clone
bacek get_iter for Namespace is different from Hash.
pmichaud it is?
purl Oh no it isn't!
bacek because Namespace is HoH.
chromatic A Hash can be a HoH too.
pmichaud NameSpace doesn't currently define a get_iter, which means it's inheriting the one from hash.
and... what chromatic++ said. 21:32
bacek and rely on weird Key behaviour/implementation
pmichaud then fix the key behavior in Hash, not just in NameSpace
bacek agree
But, Namespace poking into Hash guts.
Because of "isa". 21:33
pmichaud this is a place where I'd argue that efficiency in namespace is extremely important
even if it means poking into hash guts
I already see measurable differences between
root_new ['parrot';'Integer'] 21:34
and
new ['Integer']
bacek That's why I'm trying to separate Hashes and Namespaces.
pmichaud you think you can make Namespace more efficient by going through the VTABLE instead of poking directly?
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
(Making them less a mess will likely *improve* efficiency.)
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
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)
calling conventions comes to mind 21:38
MMD is another
chromatic Yeah, me too.
pmichaud IO is a third.
bacek feel some similarity in this subsystems 21:39
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
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.
pmichaud that sounds like a limitation of pirc, then
chromatic I thought that was a problem with pirc and constant primitives.
pmichaud unless your intent is to completely eliminate Keys 21:42
bacek Emitting PBC from PIR require creating Keys.
pmichaud so, it sounds like you need a way to create keys from PIR
bacek Yes, I really want eliminate Keys..
chromatic We can't eliminate Keys anytime soon.
pmichaud what would you have in their place?
bacek Keys are quite different depends on context of usage
pmichaud: Iterators. Aggregate specific. 21:43
chromatic: soon means "5 weeks"
pmichaud bacek: but what about something like new $P0, ['Foo';'Bar'] 21:44
what would that be instead?
bacek $P0 is ?
cotto ininitialized
chromatic I don't think five weeks is realistic for a change this big.
pmichaud $P0 is the register that gets bound to the new instance of ['Foo';'Bar']
cotto $P0 = new ['Foo';'Bar']
bacek ['Foo';'Bar'] is Namespace or RSA? 21:45
pmichaud It's a Key.
bacek Can it be RSA? 21:46
which handled by "op new" properly?
pmichaud so, you're talking about having compile-time RSAs/
?
What would you do with
bacek yes.
pmichaud $P0 = new ['parrot';$S0]
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}
pmichaud I can't write that in PIR like that
chromatic No kidding, especially when a key can be constant.
bacek is it "$P0 = new ['parrot'], $S0"? 21:48
pmichaud no 21:49
that would be different.
it's still new_p_pc
it's not new_p_pc_s
the ['parrot';$S0] case I could likely live without. 21:50
If you want to change PIR so that ['parrot';'Foo'] becomes a compile-time RSA constant, that's okay with me.
bacek It can be compile-time constant
chromatic That's an IMCC change though.
bacek And Parrot_oo_get_class treat Keys/RSA equally already.
pmichaud well, you'd also have to fix it for all of the other PMC types 21:51
$I0 = hash['foo';'bar']
21:51 Whiteknight joined
pmichaud $P0 = array[0;1] 21:51
bacek I'm thinking about add 'VTABLE_hash_value'.
pmichaud ....what would that do? 21:52
bacek Allow "hash.c" works with PMCs.
pmichaud uh, that doesn't make any sense to me, but it probably doesn't need to.
anyway, my point is that Keys get used in lots of places already 21:53
so if you're going to get rid of them, you have to change IMCC as well.
bacek Currently we can't use PMC as Hash keys.
pmichaud and fix all of the places they get used.
We can't?
Rakudo uses PMCs as hash keys all the time.
So does PGE.
oh, you mean as non-string hash keys 21:54
bacek yes
pmichaud that should probably be a different kind of hash
not replace the existing one
bacek Why?
pmichaud value semantics can get really weird with arbitrary PMC types
there's not a generic "are these two things equal" comparison that is reliable enough to work
bacek We have VTABLE_clone 21:55
to store key.
We have VTABLE_is_equals to check equivalence.
pmichaud heh
and you think that works?
bacek We just need VTABLE_hash_value
Which part doesn't work? 21:56
current hash.c is polymorphic. So it should work
pmichaud most of the relational ops currently EPIC FAIL when passed differing types
bacek oh... 21:57
We don't need relational ops for hashes.
pmichaud you need at least the equivalence op
bacek yes
pmichaud that's also one that EPIC FAILS when passed differing types
bacek But it works, isn't it? 21:58
cotto bacek, why not just try to make the Key code sane?
bacek Hash_key_is_equal can check type before calling VTABLE_is_equal
cotto: because Keys are insane
pmichaud anyway, keep in mind that you'll have to fix keys for (get|set)(_root|_hll|)(namespace|global) 21:59
and for isa
and for new
and for subclass
and for newclass
and for get_class
and for :multi
bacek pmichaud: Parrot_oo_get_class.
cotto by implementation they're insane, but you think they can't be fixed?
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.
Parrot_oo_get_class doesn't solve the generic keyed interface to hash/array aggregates.
bacek get_namespace call Parrot_get_namespace_keyed. 22:01
which call "internal_ns_keyed".
so there is one place to fix. 22:02
hang on
pmichaud seems like a lot of work, when it would be easier to just get pirc to be able to generate keys.
bacek "isa", "new", "subclass", "newclass", etc
All of them uses Keys as RSA. 22:03
Actually LinkedStringList
pmichaud decides to wander off somewhere more productive, rather than fight a worthless fight. 22:04
bacek It's not worthless... At least I gather some useful information. 22:06
chromatic allison will have your head if you check in a big change like that a couple of weeks before 1.4. 22:08
I'm not saying it's not worth doing in general, only that it's a potentially disruptive change right now.
bacek 5 weeks is right after 1.4 22:09
pmichaud I count 6.
bacek And I'm not going to hack it in trunk.
pmichaud: welcome to future! It's Saturday already :) 22:10
chromatic Okay, I misunderstood then.
pmichaud five weeks from today is July 18.
1.4 is July 21.
bacek Ok-ok. 6 weeks. 22:11
Of cause it will not hit 1.4 release.
pmichaud even so, I'm a bit annoyed by these internal refactors that don't result in measurable changes to HLL implementors.
(or the changes they do present are decidedly negative)
bacek I treat it as [CAGE] cleanup. 22:12
Not even as [cage]
pmichaud if nothing breaks, and if performance doesn't go down, I have no objection.
chromatic Yeah, but there are a lot of bugs that need fixing.
pmichaud Agreed.
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.
chromatic That's a different story though. We have to get allison off of critical paths. 22:14
At least we have to stop letting allison be the only person on critical tasks.
pmichaud I agree with that, but still I don't want it to impact a large number of tuits
from any core developer, not just allison.
chromatic I know, I'm hijacking your rant for my own purposes.
pmichaud It's my rant as well, I'm just less vocal about that one :-)
bacek Speaking of bugs 22:16
Can I merge tt24_unicode_numifications?
Or we still waiting for "final" decision about "Inf" and "NaN" representing in Parrot? 22:17
Whiteknight I'm fine with a merger today
pmichaud I don't have an objection, if it doesn't break rakudo.
Whiteknight that gives us a few good days of testing before the release
pmichaud (or pge, or all the other items)
bacek pmichaud: It should fix Rakudo 22:18
pmichaud which ticket is it, again?
bacek tt724
pmichaud oh. Rakudo isn't broken there. 22:19
i.e., it doesn't fix anything that Rakudo needs fixing on.
bacek but it stops rakudo to use ucs2 during parsing, afaiu
pmichaud rakudo doesn't want to use ucs2 parsing. I switched to using iso-8859-1 instead. 22:20
which is actually nicer than ucs2 in many respects.
bacek hmm. why?
pmichaud uses less space, for one.
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
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.
bacek my $s = "Š—Š“рŠ°Š²ŃŃ‚Š²ŃƒŠ¹ Š¼Šøр";...
pmichaud Rakudo has no problem with that. 22:22
That's a utf8 string, not a ucs2 one.
bacek is Cyrillic covered by iso8859?
pmichaud And Rakudo does its own string-to-number conversion, it doesn't use Parrot's.
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?
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:24
anyway, as I said, I don't object if it doesn't break Rakudo. :-) 22:25
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.
because it disappears with very slight changes to the code.
(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
bacek btw, what "array[0;1]" will return? 22:32
Coke returns. 22:33
chromatic the second element of the nested array in the first array's first position 22:41
bacek same as "array[0][1]"? 22:42
(in some HLL)
chromatic Yes. 22:44
bacek why do we need it in PIR? 22:45
And what about "array['foo';'bar']"? 22:46
chromatic Same. 22:47
Except that's keyed access, not indexed. 22:48
bacek ooookey.
chromatic It's a shortcut for the get_XXX_keyed vtable entry.
bacek Do we really need this "shortcut"? 22:49
chromatic If you want to make the Universal Turing Machine argument, we don't need any shortcuts. 22:50
A better question is "Does this make certain coding patterns more convenient?"
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.
bacek Should PMC support this behaviour directly or it can be handled in generic way somewhere else?
chromatic Which behavior, looking something up by a key? Yes. 22:52
22:52 sekimura joined
chromatic Multi-value keys? Hard to say. 22:52
bacek "looking something by linked list of some values"
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.
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?
For constant keys frozen into PBC, you *can* determine if they're multi-key keys. 22:55
For PMCs created within the compilation unit where you access them by key, you *probably* can determine their type.
All other uses you can't determine this until runtime.
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.
bacek something like this. 22:57
purl something like this is, like, tempting: www.zones.com/cgi-bin/zones/site/pr...p;zone=zbs
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.
bacek chromatic: it's violated in many-many places now. 22:58
chromatic As a matter of implementation, not of interface.
bacek internal_ns_keyed_key for examples
chromatic That's never called from ops. 22:59
It's only ever called from src/global.c which implements some of Parrot's namespacing behavior. 23:00
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.
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.
pmichaud Optimization is all about exploiting inequalities for direct gain. 23:03
bacek ok. I've implemented Map PMC. Classical RB-tree based.
Now, in get_pmc_keyed I have to distinguish Keys from all other PMCs?
chromatic Same as every other PMC does in get_pmc_keyed. 23:04
bacek yeah... At least 9 pmcs copy-paste code for this... 23:05
ok. 5
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.
bacek but... we already have switch-optimised VTABLE generation for MULTIs. 23:09
chromatic We turn ALL vtable entries into multis.
bacek So we probably can start now without sacrificing performance
chromatic They're not written in C anymore, so we can optimize dispatch the same way we can optimize dispatch with an optimizing compiler.
We can share implementations. 23:10
bacek what about blah_int?
chromatic We can override them from PIR trivially without expensive checks.
We can define only those vtable entries that make sense on specific PMCs.
We can add vtable entries as they make sense.
Whiteknight chromatic: I would like to give you your druthers
bacek we can kill vtables. 23:11
They are just METHODs.
Whiteknight we can't kill vtables entirely
otherwise how do you interface with PMCs?
bacek Question is: what difference between VTABLE and METHOD in L1 parrot? 23:12
chromatic VTABLE is always multi.
Any PMC must implement a series of VTABLEs to correspond to the VTABLE interface (though multidispatch takes care of a lot of that).
Any defined VTABLE has a well-defined semantic. 23:13
Other than that? It's a wad of L1 ops like any other code in the system.
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.."
I still don't understand why METHODs and VTABLEs are different. 23:15
(In L1 parrot)
chromatic VTABLEs can't be user visible.
bacek why not?
Whiteknight the traditional difference between VTABLE and METHOD is that VTABLES are rigidly pre-defined
chromatic So users can't call them directly and accidentally.
Whiteknight chromatic: I would suggest in a post-L1 world that vtables should be more directly visible 23:16
chromatic To user code?
Whiteknight specifically, I suggest that just about all vtables will have a one-to-one correlation with L1 opcodes
chromatic I have no idea what that means.
Whiteknight so we have a get_number VTABLE, and a get_number L1 op
chromatic Oh goodness no. 23:17
Whiteknight and why not?
chromatic That's much too high level for L1 ops.
Whiteknight a single C function call is too high level?
chromatic Yes.
bacek Are t/pmc/packfile*.t failing only for me?
Whiteknight chromatic: so then what are the L1 ops going to be?
chromatic I have no small sympathy for libjit's ops. 23:18
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?
bacek Whiteknight: I'm going to merge tt24_unicode_numifications into trunk. No new failures in Rakudo/Partcl
Whiteknight chromatic: we want L1 to be fast and trivially easy to JIT
chromatic Yeah, so why multiply entities?
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
Whiteknight right, but functions have different signatures, return different types of values, and don't all need to be called from L1 23:21
a one-to-one correspondence between the functions we need limits access to the ones we dont
chromatic L1 op: look up a function by name
Infinoid so, "lookup_vtable_function; call_vtable_function"?
chromatic There may need to be variable arity call_vtable_function ops, but yes.
Or at least multiple arity versions. 23:22
Whiteknight chromatic, so can we lookup_function_by_name "malloc"?
Infinoid call_vtable_function_p_s
chromatic Yes and yes.
Whiteknight that's madness
L1 is useless if it's just a new way of writing C
Infinoid that's simple.
chromatic man dlfunc
Who said anything about writing C? 23:23
Whiteknight well, not useless, but severly impaired
chromatic The purpose of this exercise is to avoid C.
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
Infinoid It's simple enough to avoid getting bogged down in implementation details, which means the components should be easily reusable for JIT
Whiteknight that's C
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.
japhb whispers innocently "Implement them in Forth ...."
chromatic I recall writing quite the opposite, really. 23:25
Infinoid $japhb =~ s/Forth/befunge/
chromatic Quiet, you! I'm sticking with Smalltalk-80.
Whiteknight I won't fight you over the vtable issue, but what about other API functions?
chromatic We'll need a way to call C functions for NCI, yes. 23:26
We'll need a way to call into Parrot's backing library for some of this code.
If we have that, we can migrate more and more of it to L1.
Whiteknight not if we hardcode in some ops to call specific functions
by-name function lookups are needlessly slow and wasteful for core API functios
chromatic Sure, but why in the world would you *do* that?
dalek rrot: r39529 | bacek++ | trunk (6 files):
Merge tt24_unicode_numifications branch into trunk.
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.
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
chromatic There won't be an L1 throw op.
That's too high level for L1.
The thought makes me throw op! (Okay, sorry. (Okay, I'm not sorry, but I'm a little sorry I'm not sorry.))
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?
chromatic Sure, the same way you optimize other constant lookups.
Whiteknight L1 ops should atomicly perform the operations that Parrot can understand, and Parrot understand more then just basic arithmetic and pointer munging ops
if L1 is going to be just another name for an LLVM-style static language bytecode, I want none of it 23:30
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:31
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
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
and our goal for 3.0 is to support more platforms, not less
chromatic How is that a nightmare of support?
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?
Infinoid: Then we're artificially limited to only the platforms where our JIT engine of choice is supported
Infinoid no, libjit should handle that
Whiteknight and neither libJIT or LLVM have expansive platform support
Infinoid Ok. What does this have to do with L1? 23:35
chromatic L1 doesn't require a JIT.
It makes JIT easier.
Whiteknight it's a question of scope: how much should L1 be.
chromatic ... but we can do L1 without a JIT on platforms in environments where JIT doesn't make sense.
Whiteknight chromatic: then how are we doing NCI calls with arbitrary argument lists? 23:36
chromatic How do we do them now?
Whiteknight either using JIT, or by painfully pre-constructing thunks in C at compile time
dalek rrot: r39530 | bacek++ | trunk/src/string/api.c:
[cage] Cast to unsigned char in str_to_int and str_to_num.
Whiteknight the first is too lmiting, and the second is The Wrong Way 23:37
chromatic Thus our possibility for regression is low.
Whiteknight at least there's a silver lining
chromatic We don't lose anything NCI-wise this way. 23:38
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.
Whiteknight because I'm very interested to see what you have in mind specifically
23:39 SpacemanSpiff joined
chromatic It looks a lot like libjit's instruction set. 23:39
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
You might be able to find the Smalltalk-80 low level instruction set documented somewhere.
I think the blue book is available online.
Whiteknight is searching no 23:41
now*
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
chromatic stephane.ducasse.free.fr/FreeBooks/BlueBook/ 23:43
Part IV
wiki.squeak.org/squeak/1602
Whiteknight thanks 23:44
all the links I found were subscription
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
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
chromatic We gain a lot by avoiding C -- calling conventions, dispatch, memory model.
Infinoid loading necessary dynpmcs and preloading symbol tables
or loading dyn<whatever>s
Whiteknight calling conventions and dispatch are already going to be in L1, and that's only a small part of everything.
we aren't really losing the C memory model with low level "allocate sized chunk" and "write to pointer" ops 23:47
chromatic Depends if we support C pointers. 23:48
Infinoid You have to, if you don't directly support PMC registers
chromatic I think we can get around that with some cleverness.
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
purl There's a fine line between clever and stupid.
chromatic My guiding principle is that TraceMonkey gets faster every time they write more JavaScript in JavaScript.
Coke for comparison, partcl gets slower every time I write more of it in tcl.
(loading init.tcl is SLOOOOW)
but tcl is just crazy.
chromatic Let's not even talk about your test.tcl.
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.
Coke pun. 23:52
chromatic The average American has one. 23:53
Coke ^_o
I was thinking it would be interesting to write some of the tcl builtins in nqp. 23:54
how expensive is invoking a PIR sub from a PIR sub? if I can trivially inline it, should I? 23:56
Whiteknight chromatic: but the more JavaScript you have, the more JavaScript you can write in it quickly 23:57
chromatic Right, but they're talking about bootstrapping JS. 23:58
Coke, it depends on how frequently you call it. You save a contininuation allocation and a couple of contexts.
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
Coke well, if contexts leak, that's a win. =-)
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.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!