Parrot 3.2.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot is accepted for GSoC 2011! Student application deadline is Apr 8 | Goals: Get more GSoC ideas on wiki; close tickets; stable 3.2 release; assess status of roadmap goals for 3/15 meeting.
Set by moderator on 18 March 2011.
00:09 mj41 left 00:12 lucian left 00:49 lucian joined 01:17 Coke joined 01:38 soh_cah_toa joined
soh_cah_toa hey guys, back again. been looking at upcoming events with parrot and saw something about a parrotsketch meeting. what is parrotsketch? 01:40
whiteknight parrotsketch is a weekly meeting we have in the #parrotsketch channel 01:44
it's like a design and planning meeting
you're welcome to come and watch. If you get involved with hacking, you can post reports about what you're working on, and get involved in the discussions 01:45
soh_cah_toa oh okay. yeah, i think i'll stop by. 01:48
whiteknight awesome 01:49
soh_cah_toa i thought the "sketch" meant it was for the graphics and art side of parrot so i wasn't sure if it was really something for me
atrodo soh_cah_toa: It's a reference to the monty python parrot sketch 01:51
dalek rrot: c30d88c | bacek++ | / (2 files):
Forcefully inline Pointer_Array manipulation functions.

It gives another 2% of speed improvements on building Rakudo's core.pm.		 01:52
rrot: 85e4ffe | bacek++ | src/pmc/packfiledirectory.pmc:
Create PackfileBytecodeSegment instead of RawSegment when we actually unpack bytecode.
rrot: b600dfe | bacek++ | src/pmc/opcode.pmc:
Add OpCode.get_number to simplify usage from nqp.
soh_cah_toa oh alright. sorry, never really got into the monty python thing. i know, i know... :)
ttbot Parrot c30d88cb i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/56543 01:54
Parrot c30d88cb i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/56553
dalek rrot: 2b896f5 | bacek++ | include/parrot/pointer_array.h:
Fix debug builds.
 01:56
soh_cah_toa so let me see if i understand this correctly...the rakudo compiler is written in nqp which itself is a subset of perl 6? 01:57
ttbot Parrot b600dfe5 i386-freebsd-64int make error tt.taptinder.org/cmdinfo/56606
01:59 kid51 joined
kid51 w/ soh_cah_toa 01:59
soh_cah_toa why did parrot need nqp in the first place, though? what does nqp have that perl 5 doesn't? 02:01
i mean, if nqp is "almost-perl6", then why not further develop that?
cotto it's less painful to use a subset of Perl 6 that compiles down to PIR to implement much of Rakudo than to use PIR directly 02:04
soh_cah_toa intersting...so you developed a language for the sole purpose of developing another language 02:08
cotto mostly pmichaud
whiteknight nqp is specifically designed to be a small language with a minimal runtime 02:09
it's perfect for writing the guts of a compiler
ttbot Parrot 2b896f55 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/56666 02:10
cotto pmichaud.com/sandbox/nqp.txt describes its future, if you're interested 02:11
dalek sella/harness_refactor: 2228daf | Whiteknight++ | s (5 files):
merge TestCollection and Results into a single TestRun model type. Refactor the way we keep track of tests by status
 02:15
sella/harness_refactor: 1e84168 | Whiteknight++ | / (3 files):
fix error reporting so we get actual lists of failed files again
sella/harness_refactor: 2b6c89b | Whiteknight++ | src/tap_harness/ (3 files):
rename/remove files to reflect reality
sella/harness_refactor: a14b95d | Whiteknight++ | s (3 files):
remove a lot of unnecessary accessor methods.
sella/harness_refactor: f1b0328 | Whiteknight++ | src/tap_harness/ (2 files):
small cleanups and docs
soh_cah_toa since nqp compiles into pir, i would imagine that compiling perl 6 code would be much very effecient
02:16 whiteknight left
cotto there are several reasons why it's more expensive than it ought to be 02:16
soh_cah_toa really? i would've thought the opposite 02:17
02:17 woosley joined
nopaste "kid51" at 192.168.1.3 pasted "t/pmc/packfilerawsegment.t: new failures: linux/i386" (20 lines) at nopaste.snit.ch/38231 02:21
kid51 That FAIL emerged somewhere after f83909e 02:23
ttbot Parrot 2b896f55 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/56722 02:32
02:39 kurahaupo left 02:40 kurahaupo joined 02:43 kid51 left 02:45 ShaneC joined
dalek rrot: 5f1b1a4 | mikehh++ | include/parrot/pointer_array.h:
fix codetest failures - pod syntax, c_function docs and add ASSERT_ARGS
 02:54
ttbot Parrot 5f1b1a40 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/56763 02:56
Parrot 5f1b1a40 i386-freebsd-64int make error tt.taptinder.org/cmdinfo/56776 02:57
03:03 lucian left 03:06 soh_cah_toa left
dalek rrot: 323edb2 | bacek++ | src/pmc/packfilerawsegment.pmc:
Add more get_*_keyed_* accessors to PackfileRawSegment.
 03:12
rrot: 20e18aa | bacek++ | src/pmc/packfilebytecodesegment.pmc:
Inherit PackfileBytecodeSegment from RawSegment.
ttbot Parrot 5f1b1a40 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/56791
Parrot 20e18aab i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/56817 03:13
Parrot 20e18aab i386-freebsd-64int make error tt.taptinder.org/cmdinfo/56834 03:14
Parrot 323edb2f MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/56837 03:15
Parrot 323edb2f darwin-thread-multi-2level make error tt.taptinder.org/cmdinfo/56827
dalek rrot: c35de5d | mikehh++ | include/parrot/pointer_array.h:
add define for ASSERT_ARGS
 03:19
cotto mikehh, that should be handled by headerizer 03:24
mikehh cotto: tried that 03:28
problem is that it seems to be in the header file rather than the .c file - maybe? 03:29
or that it is defined before the Headerizer info in the file? 03:34
ttbot Parrot c35de5dd MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/56936
Parrot c35de5dd MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/56950 03:40
dalek rrot: 3964642 | bacek++ | include/parrot/pointer_array.h:
Remove "inline" keyword. Looks like VisualStudio can't grok it.
 03:43
mikehh bacek: yeah saw that - C:\\usr\\TapTinder-tt1\\client-data\\Parrot-default-temp\\include\\parrot/pointer_array.h(110) : error C2054: expected '(' to follow 'inline' 03:44
bacek mikehh, yes. VS isn't smartest kid on the block. 03:45
mikehh bacek: :-}
cotto bacek, is there any reason to have functions in header files instead of src/pointer_array.c? 03:46
bacek cotto, for inlining purpose.
they will be static in each .c file. And will be inlined by any reasonable compiler. 03:47
mikehh which MS don't seem to like anyway
bacek 2% of performance improvements on "code.pm test"
tewk MS VS uses __inline 03:53
cotto don't we have PARROT_INLINE dtrt/ 03:54
?
tewk Most projects #define INLINE to inline or __inline depending on platorm.
bacek looks like we have PARROT_INLINE 03:56
dalek rrot: f8a423b | bacek++ | include/parrot/pointer_array.h:
Use PARROT_INLINE. tewk++ for notice.
 03:57
cotto not heavily used though
bacek win32 build should be fine again.
cotto, if you are bored. Extending PackfileOpMap to support lookup ops-by-id will be really helpful. At least for "crazy jit prototype" 03:58
afk # rl
cotto I thought it did that already. 03:59
guess not 04:00
bacek it was other way around 04:01
pushing Op into OpMap with auto-generated mapping
I need set_pmc_keyed_int to lookup Op from loaded PBC.
really afk now
dalek rrot: 58c4c87 | mikehh++ | include/parrot/pointer_array.h:
fix codetest failures - c function docs
 04:16
04:29 jsut_ joined 04:34 jsut left 04:55 woosley left 06:40 Eduardow joined 06:59 theory left 07:29 jimmy joined 07:30 jimmy left 07:47 alin joined
dalek rrot: 0c4badb | bacek++ | t/pmc/packfileopmap.t:
Update test to explicitly skip test when no math_ops lib available.
 08:24
rrot: 0720b34 | bacek++ | / (2 files):
Implement lookup of ops by mapped id in PackfileOpMap
09:04 mj41 joined
dalek umage: e661a25 | fperrad++ | src/lib/Plumage/NQPUtil.nqp:
fix after github.com/parrot/parrot/commit/80b...9ca1dda56f
 09:10
09:16 fperrad joined 09:21 mj41_nb joined 09:25 mj41 left, alin left 09:26 alin joined 09:42 bacek left 09:49 alin left 09:52 bacek joined 09:54 alin joined 09:57 mj41_nb left 09:58 mj41 joined 10:13 contingencyplan joined 10:20 janus` is now known as janus 10:34 contingencyplan left 10:50 whiteknight joined
whiteknight good morning, #parrot 10:54
10:54 JimmyZ joined
dalek rrot: f7e97d3 | bacek++ | src/pmc/packfileopmap.pmc:
Add get_pmc_keyed_int as synonym for .get_string_keyed_int to simplify usage from nqp.
 10:57
rrot: 6bd28a1 | bacek++ | src/pmc/packfilebytecodesegment.pmc:
Partially recreate BytecodeSegment PMC from PackFile_ByteCode.

This PMC is asking for refactor to expose PackFile_ByteCode in more sane way.
11:10 JimmyZ left
dalek rrot/jit_prototype: ac9b1ac | bacek++ | / (8 files):
Merge branch 'master' into jit_prototype
 11:11
rrot/jit_prototype: eaa106e | bacek++ | / (5 files):
Merge branch 'master' into jit_prototype
11:12 giwi joined
dalek rrot/jit_prototype: 25d17b9 | bacek++ | t/jit/ (6 files):
Add test data
 11:18
rrot/jit_prototype: 1e3d95b | bacek++ | t/jit/test.t:
Generate PBC on fly.
rrot/jit_prototype: 4b5ecec | bacek++ | t/jit/jitted.ops:
Small subset of 'jitted' ops
11:44 woosley joined 12:26 samwho joined 12:27 samwho left 12:35 kid51 joined 12:36 kid51 left 12:51 lucian joined
dalek rrot/jit_prototype: 8176fb7 | bacek++ | compilers/opsc/src/Ops/Op.pm:
Add Ops::Op.normalized_args accessor.
 12:59
rrot/jit_prototype: 9a1c739 | bacek++ | compilers/opsc/src/Ops/Trans/C.pm:
Stylish rewrite bit of code-generation.
rrot/jit_prototype: 938d5d7 | bacek++ | compilers/opsc/src/Ops/Trans/C.pm:
Remove unused defines.
rrot/jit_prototype: 82fba92 | bacek++ | t/jit/test.t:
Add more debug output to "test".
rrot/jit_prototype: 854e4ac | bacek++ | compilers/opsc/src/Ops/Op.pm:
Update docs.
rrot/jit_prototype: 1a8551a | bacek++ | compilers/opsc/src/Ops/ (2 files):
Pass whole %context into Op.source to simplify passing additional stuff for Op::Trans
rrot/jit_prototype: caa51cd | bacek++ | compilers/opsc/src/Ops/ (3 files):
Pass %context to Trans from Op
13:07 cogno joined
dalek rrot/jit_prototype: 60c8c62 | bacek++ | compilers/opsc/ (4 files):
Add stub for Ops::Trans::JIT
 13:09
13:11 mj41 left 13:13 giwi left 13:20 zby_home joined 13:21 giwi joined 13:23 cogno left, cogno joined 13:35 cogno left
dalek rrot/jit_prototype: ec9b285 | bacek++ | src/pmc/packfile (2 files):
Merge branch 'master' into jit_prototype
 13:50
rrot/jit_prototype: f020810 | bacek++ | compilers/opsc/src/Ops/Trans/JIT.pm:
Add few register accessors.
rrot/jit_prototype: 88d4cd3 | bacek++ | t/jit/test.t:
Kind of prototype of generated op bodies within current bytecode
rrot/jit_prototype: 920516c | bacek++ | t/jit/data/03.pir:
Extend test
14:11 jsut joined 14:16 jsut_ left 14:25 Eduardow left
dalek rrot/jit_prototype: a44bfe5 | bacek++ | compilers/opsc/src/Ops/Op.pm:
Don't override ctx<level> if provided.
 14:32
rrot/jit_prototype: a31e86f | bacek++ | / (2 files):
Pregenerate 'BasicBlock' for each opcode and replace 'goto offset' with 'goto label' to reflect future semantic of jitted Sub
14:50 ambs joined 15:03 woosley left 15:18 alin left 15:34 alin joined
dalek sella/harness_refactor: 3186125 | Whiteknight++ | s (2 files):
add missing file and update setup.winxed
 15:38
sella/harness_refactor: 0c4d1ed | Whiteknight++ | s (6 files):
move a file back to where it belongs. fix the build. Fix some bugs. Cleanup Loader
sella/harness_refactor: 0670323 | Whiteknight++ | / (8 files):
TestRun objects now have their own factory, and are created separately from the harness. View keeps track of all runs. Update the harness to show what the new logic looks like
15:39 Eduardow joined 15:41 theory joined
dalek rrot: ee2785c | mikehh++ | src/pmc/packfilebytecodesegment.pmc:
fix codetest failure - line length
 15:47
16:02 plobsing left, plobsing joined 16:05 Eduardow left
dukeleto #~~ 16:07
16:12 Hackbinary joined 16:13 giwi left 16:15 giwi joined 16:25 Eduardow joined
dukeleto Eduardow: howdy 16:27
msg bacek some of the code on your blog gets obscured by the column on the right side 16:30
aloha OK. I'll deliver the message.
16:43 alin left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#12712) fulltest) at 3_2_0-32-gee2785c - Ubuntu 10.10 i386 (g++-4.5) 16:46
16:50 rurban joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#12716) fulltest) at 3_2_0-32-gee2785c - Ubuntu 10.10 i386 (g++-4.5 --optimize --gc-gms) 17:33
18:02 Andy_ joined
dalek nxed: r871 | NotFound++ | trunk/winxedst1.winxed:
operator -= used with string is a syntax error, not an internal error
 18:26
18:34 ShaneC left
mikehh rakudo (25e5bd0) - builds on parrot (3_2_0-32-gee2785c) - make test, make spectest_smolder[(#12721), roast (15c1b74)] PASS - Ubuntu 10.10 i386 (g++-4.5 --optimize --gc-gms) 18:34
27,631 ok, 0 failed, 606 todo, 1,799 skipped and 0 unexpectedly succeeded
18:42 Patterner left, ShaneC joined
mikehh winxed (r871) - make all/test/test1/test2 all ok - on parrot (3_2_0-32-gee2785c) - Ubuntu 10.10 i386 (g++-4.5 --optimize --gc-gms) 18:45
18:47 Psyche^ joined, Psyche^ is now known as Patterner
dukeleto i wonder how many slots parrot should ask for in GSoC... 19:22
19:41 contingencyplan joined
Tene all the slots! 19:50
mikehh Tene: :-} 19:51
dukeleto I ACCIDENTALLY .... ALL THE SLOTS! 19:57
dukeleto finished parrot's org app for gsoc 2011 19:58
we need to setup the feed URL still
Coke skips review. 20:24
whiteknight dukeleto: I think we want at least 6 slots 20:36
that seems like the kind of number we fill most years
although we have heard from several prospective students already. We may run hotter this year 20:37
lucian is thinking of applying to other orgs as well for good measure
whiteknight lucian: why, you worried we won't accept you? 20:39
lucian whiteknight: yeah :)
whiteknight lucian: if we liked you any more, we'd be sending flowers and chocolates
lucian heh
whiteknight lucian: and if you can deliver all or most of a working python compiler, we will easily cross that threshold 20:40
PREPARE TO BE CREEPED OUT
lucian NOOOOOOOO! www.youtube.com/watch?v=S2N8eTx8LbE 20:41
20:42 Andy_ left
lucian whiteknight: minecraft's awesome anyway, even with the creepers 20:46
cotto ~~ 20:50
20:50 lucian_ joined
lucian_ hates his ISP 20:50
20:52 kid51 joined
whiteknight I haven't played the "real" minecraft. I only ever played the free alpha 20:52
it was a cool time
cotto I feel like I'd get bored after a while and use (or write, then use) an API to generate stuff for me. 20:53
lucian_ whiteknight: i bought the beta, i felt it was worth it
cotto: that's part of the fun. you can actually implement logic gates with redstone 20:54
cotto lucian_, sure. I've seen the cpu
20:54 lucian left
lucian_ and there are a lot of custom maps "scripted" with redstone like that 20:54
20:54 lucian_ is now known as lucian
cotto I feel like I'm not a full nerd until I've implemented a CPU in something that wasn't designed to support implementing a CPU. 20:55
lucian cotto: custard!
cotto marble tracks would be pretty amazing
lucian also, i find these guys www.youtube.com/show?p=M-_uPjfjVzc&s=1 amusing 20:56
cotto I'm not sure about a custard-based cpu. It'd be delicious, but that's not necessarily a desirable characteristic of a processor. 20:57
dalek tracwiki: v78 | cotto++ | ParrotQuotes
tracwiki: our only problem is that we love our students too much
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
lucian :)) 20:58
tadzik (: 20:59
cotto (:)
cotto gets stuck in an infinite loop trying to parse that 21:00
lucian cotto: gotcha! you could flush stdout if that were true 21:02
*couldn't
cotto I perform async i/o
lucian approves 21:03
cotto melange is getting a new ui 21:04
tadzik nice
like cpan.org
lucian hates melange a little
cotto me too, but it does a pretty good job given its developers' lack of resources 21:06
cotto got schooled about how it's developed during gci
21:14 alin joined 21:18 perlite_ joined
kid51 Is there any branch that needs a smolder right now? 21:20
21:20 robertpeters joined 21:21 perlite left, perlite_ is now known as perlite 21:22 robertpeters is now known as robertpeters_WLS
lucian kid51: it's old photoshopcontest.com/images/fullsiz...730610.jpg 21:22
cotto *groan* 21:25
lucian it wasn't very funny at all, i know
i just always think of very literal thing when "smolder" is mentioned 21:26
21:27 zby_home left
lucian "smouldering parrot" is a very powerful and disturbing mental image 21:27
kid51 lucian: While you were joking, I just got a report done on bacek's opsc_llvm branch 21:29
21:29 alin left
kid51 I look forward to smoke-testing some of your code ... someday ;-) 21:29
lucian kid51: i'll make sure to insulate accordingly 21:30
kid51 msg bacek opsc_llvm branch PASS on linux/i386 at commit 1d4307c913215aeeea43ee2d8a248261bccf77f5
aloha OK. I'll deliver the message.
lucian kid51: btw, you should have plenty opportunity if i get into gsoc this year 21:31
kid51 I look forward to that ... but you needn't wait for that to start!
lucian kid51: yes i do, i don't really have time right now :) 21:32
bacek Good morning, humans 21:33
kid51, which version of llvm did you use?
(for opsc_llvm branch testing)
cotto good morning, bacek 21:34
kid51 bacek: Same as previously reported (but I'll have to wait for the next branch to finish smoking to look that up)
Not the most recent, in any event
bacek kid51, ok, thanks
cotto, aloha slacker 21:35
cotto bacek, do you have any thoughts on the M0 concept of function handles?
bacek cotto, nope. I was pretty much focused on other things.
cotto, actually... If LLVM JIT will fly we can almost kill Lorito. 21:36
cotto basically it's an opaque thingy whose internals depend on the M0 implementation, but that stores the information needed to make (and return from) an ffi call.
orly?
bacek afk # breakfast
lucian bacek: you mean keep the 1k parrot ops and compile them with clang? 21:37
21:38 alin joined
bacek lucian, s/clang/opsc/ 21:44
lucian bacek: right, i forgot ops are written in a weird language
bacek lucian, which we can already parse (almost fully) 21:45
21:45 fperrad left
kid51 msg whiteknight smolder.parrot.org/app/projects/rep...ils/12735; whiteknight/imcc_compreg_pmc branch has failures in 3 tests; linux/i386 HEAD 21:46
aloha OK. I'll deliver the message.
whiteknight kid51: yeah, we're still working on those
kid51 k
21:46 he left
bacek cotto, yes. Lorito consists (mostly) of two parts: "semantically parse ops/pmcs" and "emit jittable M0 from parsed ops/pmcs". 21:48
kid51 bacek: $ /usr/bin/llvm-config --version says: 2.2
bacek kid51, it's strange. Do you have llvm-2.7 installed? 21:49
kid51 No. I just took whatever debian had available.
21:49 soh_cah_toa joined
kid51 IIRC, a couple of weeks back I was NOT passing with that version. 21:49
so this is an improvement.
21:49 he joined
bacek cotto, we now parse ops. If we replace M0 with LLVM than we done - Parrot is JITtable. 21:50
kid51, looks like a bug in LLVM bindings. I have explicit loading of libLLVM-2.7.so inside code.
soh_cah_toa whiteknight: so i've been thinking about the gsoc debugger project and i'm curious: would i have to use any assembly?
bacek afk # $dayjob 21:51
whiteknight soh_cah_toa: what do you mean, assembly language?
lucian bacek: i'm very curious of the results you get with llvm
it sounds a bit like a pasting jit
cotto bacek, jittable is one thing, but we also want to avoid the c/pir boundary
soh_cah_toa yeah. i mean, how else would i be able to read the registers and stuff
or would the debugger look at parrot's virtual registers and memory? 21:52
bacek cotto, M0 will not help with it. 21:53
cotto Not at first, but it will once we start writing core code in an M0 overlay langauge. 21:54
21:54 alin left
cotto *language 21:54
soh_cah_toa for instance, if the programmer using the debugger wanted to see the current state of the internal registers, would the values come from eax or $N1 for example? 21:56
21:56 alin joined
whiteknight soh_cah_toa: only Parrot's virtual registers. There would be no assembly involved 21:57
soh_cah_toa ok, i thought so
whiteknight soh_cah_toa: the lowest you would need to do is C. Depending on how you planned the project, you could do a little C and mostly higher-level stuff, or you could do mostly C and only a little higher-level stuf
soh_cah_toa yeah, i figured mostly c 21:58
lucian i'd guess gdb/valgrind can deal with C-level debugging
soh_cah_toa at what stage would the debugger be examing code? say the programmer wanted to debug a python program, would the debugger be examing the python code or the pir that it compiles to? 21:59
cotto they're pretty good
soh_cah_toa lucian: yeah, i was planning on looking at the source code for gdb soon 22:00
lucian soh_cah_toa: again, i'd say there already are tools for debugging python code
soh_cah_toa: so perhaps pir/pbc-level debugging
soh_cah_toa ok
lucian don't trust what i say too much, though
kid51 msg bacek If you want '99-example.t' in opsc_llvm branch to get tested as part of 'make test', don't put it in subdirectory t/library/llvm/. It won't get tested there. Just put it in t/library/. 22:01
aloha OK. I'll deliver the message.
soh_cah_toa haha. well, i'll take all the help and advice i can get
this is my first open source project so i'm inclined to listen to any of your guys advice 22:02
i've worked on my own for several years but this would be my first time working with a group of developers as a team 22:03
22:04 alin left
kid51 soh_cah_toa: Speaking about "working with a group of developers as a team" ... In the coming month, we will be forming teams to work on roadmap goals for our July supported release. 22:05
soh_cah_toa: so, when you start seeing discussion about that here or in parrot-dev list, put your name forward! 22:06
soh_cah_toa of course
kid51 Those teams will be more tightly focused than "the Parrot project as a whole" and will enable you to work with our leading developers. 22:07
soh_cah_toa is that seperate from gsoc or are the gsoc projects a part of the roadmap for the new release?
kid51 It's distinct from GSOC.
We have begun (slowly) to make teams working on roadmap goals part of our standard operating procedure. 22:08
soh_cah_toa okay
so the new release would be done before gsoc work starts then?
kid51 But we really want GSOC projects to result in code that we can merge into master by the end of the summer.
soh_cah_toa: Actually, we release every month, on the 3rd Tuesday. 22:09
We have "supported releases" in Jan Apr Jul Oct -- quarterly.
soh_cah_toa marks calendar
kid51 Next supported release is 3.3, Tues Apr 19.
We have quarterly online Parrot Developer Summits, the second weekend after each quarterly supported release 22:10
22:10 ambs left
kid51 Hence, next PDS is weekend of Apr 30 - May 1. 22:10
soh_cah_toa that would be great. it would give me more time and experience with parrot development before gsoc
kid51 At that PDS, we will set Roadmap Goals for 3.6 supported release in mid-July 22:11
... and form teams to implement those goals.
soh_cah_toa okay. is the pds in this irc channel?
kid51 So, hopefully, the Roadmap Goals we set for 3.6 will, at least, be consistent with GSOC projects.
Our meetings are held in #parrotsketch.
Weekly meeting Tuesday at 2030 UTC 22:12
soh_cah_toa oh okay. yeah, i saw that on the calendar and asked about it last night
kid51 Quarterly PDS is held on a weekend. Exact day/time rotates to accommodate people in different parts of globe
dalek rrot/opsc_llvm: ff6ba19 | (luben karavelov)++ | t/library/llvm/03-constant.t:
more test for generating constants
rrot/opsc_llvm: aa6f121 | (luben karavelov)++ | / (2 files):
Flesh out LLVM::Constant
whiteknight soh_cah_toa: the best bet is to work at the PBC level. We have annotation metadata in our PBC that typically includes file name and line number information for the HLL
soh_cah_toa: so if you build a debugger that works at the PBC level, it can be used transparently with Perl6 code, Python code, Ruby code, etc 22:13
soh_cah_toa alright then 22:16
kid51 afk 22:17
soh_cah_toa are there any other resource besides docs/parrotbyte.pod where i can learn more about parrot bytecode? google mentions something about pdd 13 but i get a 404 error
lucian whiteknight: with the caveat that it's likely to not be really nice for either of them
whiteknight lucian: I see no reason why not
lucian s/it's likely not to/it's not likely/
whiteknight lucian: especially if the project was a debugger framework, which could be subclassed to provide per-HLL behaviors 22:18
lucian whiteknight: debuggers often know language-specific things that aren't necessarily mapped onto pbc
whiteknight: then yeah, possible
soh_cah_toa true but wouldn't it be best to implent what is common to all parrot supported languages first (pbc) and then worry about language-specific constructs? 22:19
whiteknight right, that's my idea
soh_cah_toa okay
as i've been reading the parrot documentation, i see that a lot of it realies heavily on pmc's. from what i've been able to gather, are pmc's kind of like parrot's implementation of structures/objects? 22:22
cotto soh_cah_toa, something like that 22:24
they're the abstract data types that get to do most of the interesting work
soh_cah_toa alright, that's what it thought 22:26
at what level do they exist? in pdd17 it says that they're delcared with the "pmclass" keyword. is this pir, pasm, or pbc? 22:30
cotto soh_cah_toa, there are C pmcs and pir-level pmcs
whiteknight soh_cah_toa: take a look at the .pmc files in src/pmc
they're defined in C, but the C is heavily preprocessed
22:31 PacoLinux left
whiteknight soh_cah_toa: build Parrot from source. Then look at, for instance, src/pmc/string.pmc and the generated src/pmc/string.c 22:31
soh_cah_toa yeah, i compiled parrot a few days ago. so would a string pmc for perl be different or the same as a string pmc for python? 22:33
whiteknight soh_cah_toa: depends. We offer a basic String type, but HLLs can subclass that if they want custom behavior 22:34
or, they could replace it entirely
Parrot has a concept of "HLL Mappings". You set up a map, and when you are in your HLL, your mapped type is always used instead of the native types
soh_cah_toa alright, i think i'm starting to understand this a little better 22:35
whiteknight so if you're running partcl, Parrot will always use TclString instead of String
soh_cah_toa okay
so a string in a hll will actually be an abstract datatype (pmc) at a lower level (pir). interesting... 22:37
whiteknight well, there are two different things. There are STRING* structures, which are low-level strings, and then there are String PMCs, which contain a STRING and have methods and stuff 22:38
so one is a low-level type, the other is an object wrapper
STRING * is not subclassable. String PMC is 22:39
soh_cah_toa yeah
i like that idea. it adds more functionality and flexibility to regular datatypes 22:40
whiteknight PMCs are nice because they all have a common interface called the VTABLE 22:41
every single PMC type, no matter what, implements the same interface
so you can tell any PMC "give me a STRING of you", or "give me an integer value from you" 22:42
or "Tell me what type you are"
even HLL mapped versions, user-defined Objects, etc
soh_cah_toa right
22:43 lucian left
soh_cah_toa VTABLE is just like a dispatch table, right? an array of function pointers called depending on what the programmer is requested of an object 22:44
whiteknight exactly
take a look at src/vtable.tbl for a list of all vtables in the system
The list is needlessly bloated, as far as I am concerned, but that's what we have
that file is parsed to generate code in src/vtable.c, include/parrot/vtable.h, etc 22:45
soh_cah_toa okay
man, i am loving all this documentation. i was worried that i wouldn't be able to learn the internals of parrot before gsoc but just within one weekend i think i've learned a lot 22:46
whiteknight yeah, it's surprisingly easy to learn the fundamentals
soh_cah_toa i also like how everything's in pod format 22:47
whiteknight that's a holdover from our perl roots 22:48
soh_cah_toa let's me use pod2html so that i can print everything out and read anywhere i need it
whiteknight I think we have most of it online 22:50
docs.parrot.org
yes 22:51
soh_cah_toa yeah, most of it's the same
cotto updating docs.parrot.org is part of the release process
soh_cah_toa that's good 22:52
you guys are very thorough. i like it
cotto I'm glad you're finding it easy to get started. 22:53
whiteknight yes, that is quite a good thing
cotto You'll undoubtedly find dark undocumented corners as you progress. We have a lot of them.
soh_cah_toa that's inevitable though 22:54
bacek_at_work ~~ 22:57
cotto bacek_at_work, ~~
bacek_at_work cotto, aloha 23:00
23:06 rurban_ joined 23:08 rurban left, rurban_ is now known as rurban
dalek rrot/m0-spec: 50d13ca | cotto++ | docs/pdds/draft/pdd32_m0.pod:
change interface for function handles
 23:09
rrot/m0-spec: fdcc556 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
decide how types will work, expand the example
rrot/m0-spec: 8f02e93 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
don't assume that thunks are the only mechanism for ffi calls
rrot/m0-spec: c3c1e4e | cotto++ | docs/pdds/draft/pdd32_m0.pod:
finish initial proposal for ffi
rrot/opsc_llvm: 1c76a45 | bacek++ | runtime/parrot/library/LLVM/Constant.pm:
Use bit of static typing in LLVM bindings.
 23:16
soh_cah_toa whiteknight: you mentioned a few days ago that the current debugger is very buggy. is there a way i can find a list of bug reports?
that way i can have some sort of starting point 23:17
Coke bug reports: trac.parrot.org/ -> View Tickets
but the debugger is, IME, not reported against, because no one expects it to work.
soh_cah_toa wow. it's that bad, huh? 23:18
23:20 kid51 left 23:21 petdance joined
cotto heh. github's yelling at me about pod errors 23:23
I love the future.
dalek rrot/m0-spec: 90d40d3 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
fix pod
 23:25
whiteknight soh_cah_toa: yeah, it just completely doesn't work. 23:45
soh_cah_toa i'm going through the source code now. seeing what i can do with it 23:46
whiteknight what the current debugger does now, if I am remembering correctly, is sets up a second debugger interpreter object, then relies on a series of built-in events to do debuggery things 23:54
the problem is that many of those built-in events have since disappeared
a
As I mentioned the other day, the best way forward is with Parrot-Instrument. That adds in all the features you would need 23:55
the problem is making Parrot-Instrument work, which it does't quite

Powered by Cro and the Raku® Programming Language.

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

Thank you!