Camelia, the Perl 6 bug

IRC log for #parrot, 2010-02-11

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 Whiteknight what other MRO algorithms are there besides C3?
00:00 Whiteknight Wikipedia is strangely silent on the issue
00:00 Austin Well, the C3 paper mentions "the Dylan linearizer", L*Loops, CLOS
00:02 nopaste "Austin" at 68.37.46.53 pasted "Linearization" (5 lines) at http://nopaste.snit.ch/19548
00:05 Austin So apparently, either your language doesn't support MI (Java), or it supports MI but requires explicit MRO input from the coder, or it has an algorithm that is probably named after the language, unless it's a Lisp dialect in which case the algorithm may have its own name if you wrote a paper about it.
00:06 Whiteknight soo...C3 is the only game in town
00:08 tetragon joined #parrot
00:10 chromatic There's also depth first, but that's... complex and not necessary accurate.
00:14 Austin C3 is far from the only game in town.
00:14 Austin It's important because Python uses it, and because of Parrot's historical ties to Python.
00:16 payload left #parrot
00:16 Austin But if someone were to try to implement CLOS atop Parrot, they would need a different MRO, since C3 is definitely not the MRO that CLOS uses.
00:19 cotto_work joined #parrot
00:19 patspam joined #parrot
00:28 Whiteknight so it might very well make sense to encapsulate the C3 linearizer as a PMC, and add an option for HLLs to override it as the default
00:28 dukeleto Whiteknight++
00:28 dukeleto did someone say GSoC project?
00:29 cotto_work joined #parrot
00:29 Whiteknight just encapsulating it isn't a worthy project, but adding a few more options in addition might be
00:29 dukeleto Whiteknight: by the way, i have been enjoying your GSoC project idea blog posts. thanks for mentioning RTEMS. my blog-fu is definitely rusty
00:29 Whiteknight I've been thinking about adding an HLLInfo PMC, which stores HLL-global configuration information like that
00:29 Whiteknight dukeleto: No problems, I like to do it because I'm full of hot air and I spend too much time on the computer
00:30 Austin This may just be "rewrite class.pmc"
00:30 dukeleto Whiteknight: i meant adding a pluggable MRO subsystem, as a GSoC project
00:30 Austin Or maybe it's "rewrite oo.c and class.pmc into a pluggable shape"
00:30 Whiteknight ah, okay. That might be good, but would still have to add at least one other option to prove pluggability
00:30 Austin Since C3 is, for no very good reason, in oo.c
00:31 Austin Fine.
00:31 Austin What's the P5 mro like?
00:31 Whiteknight class.pmc could use plenty of improvements
00:31 dukeleto "Make the Parrot MRO subsystem pluggable, so languages can decide which MRO algorithm to use"
00:31 Whiteknight Ability to properly subclass built-in PMC types is high on the list
00:31 Austin :)
00:32 * Austin gives Whiteknight a biiiiiig *smooch*.
00:32 dukeleto Austin: have you seen http://search.cpan.org/~tt​y/kurila-1.19_0/lib/mro.pm ?
00:32 Austin Nope.
00:32 Austin What is it?
00:32 purl it's it!
00:32 dukeleto Austin: also, http://search.cpan.org/~flora/MR​O-Compat-0.11/lib/MRO/Compat.pm
00:32 dukeleto Austin: C3 + friends for Perl 5
00:32 Austin Okay, reading it now.
00:33 Whiteknight Austin: That's it, you're now on my valentines card giving list
00:33 Austin P5 uses depth-first-search, Whiteknight. There's your "for comparison" alternative.
00:33 dukeleto Austin: doing "prior art" research is almost always very helpful ;)
00:33 dukeleto Austin: depth-first, left-most first ;)
00:34 s1n joined #parrot
00:34 Austin Hmm.
00:34 Austin Not really depth first.
00:34 s1n left #parrot
00:35 Austin preorder?
00:37 Austin dukeleto++
00:37 Austin Thanks for pointing to that.
00:41 Austin Whiteknight: I'm thinking that class.pmc maybe needs to method-ize a bunch of its internal operations, and then the GSC thing would be to do that plus write two sets of methods: C3 and P5dfs
00:42 Whiteknight Austin: And then when the next algorithm comes down the pike we add another set of methods?
00:42 Austin Right.
00:43 Whiteknight better, I think, is a C3Linearizer PMC object, which we can replace with other PMC types later without having to hack into class again
00:43 Austin Eh?
00:43 Austin Sorry. By "set of methods" what I secretly mean is "non-abstract class"
00:45 Austin Maybe you could explain what a PMC offers in this context.
00:45 Austin That is, a separate pmc for the linearization algorithm.
00:46 mikehh_ joined #parrot
00:49 Whiteknight cotto: ping
00:52 mikehh_ joined #parrot
00:52 cotto_work Whiteknight, pong
00:53 Whiteknight cotto: Where does the Parrot_DynOps_core_2_0_0 function get called?
00:53 cotto_work beats me.  Let me dig a bit.
00:54 cotto_work Why do you ask?
00:55 Whiteknight I'm trying to make a PMC type to encapsulate the op_table, and provide access to it from PIR
00:55 Whiteknight so I'm trying to figure out where it gets initialized
00:55 Whiteknight but I think the code is generated, because an ack doesn't turn up any results and I have build errors locally
00:57 cotto_work That function is #defined in op.h to PARROT_CORE_OPLIB_INIT, which appears to be what's used directly.
00:58 cotto_work config.h
00:58 purl hmmm... config.h is guaranteed to be available on systems which didn't build their perl but installed the sources/headers from some package manager?
01:06 cotto_work Is that what you're looking for?
01:12 Whiteknight ah, yes
01:12 Whiteknight that's cotto++
01:14 cotto_work I wonder how such PMCs could affect the pct-based ops and pmc compilers.
01:15 Whiteknight I'm hoping significantly
01:15 Whiteknight especially if we provide the ability to compile an op
01:16 Austin Whiteknight: (re: your blog) Can you cast in C#?
01:16 Austin That is, would (bool)(b[x] & 0x80) work?
01:17 Whiteknight Austin: I don't know if that would work, no
01:17 Austin Oh, well.
01:17 Whiteknight certainly no less verbose than != 0
01:18 Austin Nope.
01:18 Austin http://close-parrot.blogspot.com​/2010/02/more-snow-err-code.html
01:18 Austin More pictures - mostly white.
01:20 jan joined #parrot
01:27 Austin That's weird. I tried calling '.new' on a non-existant class / namespace, and it hung.
01:27 Austin Given that the trace shows a P-register with PMCNULL in it, shouldn't I have received an exception?
01:28 cotto_work nopaste?
01:28 purl i guess nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels)  or http://paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at http://www.extpaste.com/ or http://paste.scsys.co.uk (for #catalyst, #dbix-class, #moose  and others) or http://gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or https://trac.parrot.org/parrot/br​owser/trunk/tools/dev/nopaste.pl
01:29 Austin Aha.
01:29 Austin Inferior runloop doesn't have trace enabled. I *did* receive an exception.
01:30 allison joined #parrot
01:32 Austin Perhaps an nqp bug?
01:35 cotto_work We can't know without a nopaste.
01:48 kid51 re yapc::na::2010 theme:  http://robonperl.blogspot.com/20​10/02/what-is-modern-perl-5.html
01:50 allison joined #parrot
01:52 kid51 pmichaud:  YAPC::NA::2010 Call for Presentations (http://conferences.mongueurs.net/yn2010/) states: "Perl 6 is going to be great, but we can't wait until 'Christmas' for Perl 6."  Which implies that they're not expecting much re Rakudo/Perl 6 at YAPC.  Comment?
02:06 plobsing joined #parrot
02:35 mikehh__ joined #parrot
02:48 Whiteknight NotFound: ping
02:51 Austin Whoa.
02:52 Austin If you automatically generate and compile source code as an accessor method, that method goes into a space where it has offset 0. It's pretty weird making a call from 59131 and landing at 0, but not an error.
02:57 * dukeleto is about to give his parrot talk
02:57 Austin Live feed?
02:57 purl well, Live feed is a little lame right now but there are some nifty archived realaudio dj shows at http://www.groovetech.com
02:57 dalek parrot: r43878 | whiteknight++ | branches/op_pmcs/src/pmc (3 files):
02:58 dalek parrot: remove opfamily PMC, it was a non-starter. Flesh out oplib and opcode a little bit. Now contains all the basic functionality I think we need
02:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43878/
02:58 dalek parrot: r43879 | whiteknight++ | branches/op_pmcs/src/pmc/pmc.num:
02:58 dalek parrot: make pmcrenumber
02:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43879/
02:58 dalek parrot: r43880 | whiteknight++ | branches/op_pmcs/src/pmc (2 files):
02:58 dalek parrot: add some plumbing that I had neglected
02:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43880/
02:58 dalek parrot: r43881 | whiteknight++ | branches/op_pmcs/src/pmc/oplib.pmc:
02:58 dalek parrot: extra vtable + comment
02:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43881/
02:58 kid51 http://portland.pm.org/kwiki/
03:06 dukeleto we have "parrot-curious" people here!
03:06 mugwump joined #parrot
03:07 mugwump git head rakudo test failures on topic?  :)
03:07 mugwump t/spec/S02-literals/quoting-unicode.rakudo Dubious
03:08 eternaleye mugwump: #perl6 on freenode is the canonical rakudo channel
03:08 mugwump ah true
03:08 mugwump I was looking ... rakudo, no
03:08 mugwump forgot it was once called perl 6
03:08 mugwump so long ago
03:08 eternaleye Lots of overlap peoplewise though
03:08 Austin_Hastings joined #parrot
03:08 eternaleye mugwump: rakudo is _a_ perl 6 implementation, but it is explicitly not the only onw
03:09 eternaleye *one\
03:09 Austin_Hastings Well, there went the first inevitable power outage.
03:09 mugwump no, I think that only if the real pumpkin started interpreting perl 6 it could be called that
03:18 Austin_Hastings joined #parrot
03:18 Austin_Hastings And there's another one.
03:27 tetragon joined #parrot
03:29 kid51 vtable_massacre branch:  t/pmc/bigint.t   Failed tests:  35-45    Parse errors: Bad plan.  You planned 34 tests but ran 45.
03:31 kid51 fixed plan
03:32 dalek parrot: r43882 | jkeenan++ | branches/vtable_massacre/t/pmc/bigint.t:
03:32 dalek parrot: Correct quantity of tests in plan.
03:32 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43882/
03:36 mugwump ooo, I like the name of that branch
03:54 janus joined #parrot
03:55 Austin joined #parrot
04:20 notbenh1 joined #parrot
04:41 Austin joined #parrot
04:47 mikehh__ joined #parrot
04:55 JimmyZ joined #parrot
04:55 dukeleto live demo fail! but it went well
04:57 mugwump dukeleto: what?  where?  when?  who?
05:01 plobsing seen japhb
05:01 purl japhb was last seen on #parrot 2 days, 2 hours, 26 minutes and 3 seconds ago, saying: And, as I said, it will currently be incomplete because there are a number of signatures that current Parrot NCI just can't handle.  [Feb  9 02:35:34 2010]
05:02 cotto mugwump, http://portland.pm.org/kwiki/​index.cgi?February2010Meeting
05:02 kurahaupo joined #parrot
05:03 cotto dukeleto, are they generally quick about putting up recordings of presentations?
05:05 cotto I'd also like to listen to Schwern's presentation.  That sounds interesting.
05:10 Coke . o O (BOOYAH!)
05:12 * Coke once again ponders a poker BOF at yapc.
05:25 ashleyb joined #parrot
05:29 patspam joined #parrot
05:29 bacek joined #parrot
06:04 dduncan joined #parrot
06:12 cotto pmichaud, ping
06:31 dalek parrot: r43883 | cotto++ | branches/ops_pct/compilers/opsc (6 files):
06:31 dalek parrot: [opsc] remove a now-unneeded cheat and get closer to passing tests (though still not there)
06:31 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43883/
06:44 chromatic joined #parrot
06:44 kurahaupo joined #parrot
06:45 dduncan left #parrot
06:50 kurahaupo joined #parrot
07:05 baest joined #parrot
07:09 kurahaupo1 joined #parrot
07:09 Austin joined #parrot
07:13 uniejo joined #parrot
07:16 AndChat| joined #parrot
07:34 kurahaupo joined #parrot
08:02 kurahaupo joined #parrot
08:04 eiro joined #parrot
08:07 iblechbot joined #parrot
08:16 barney joined #parrot
08:34 payload joined #parrot
09:11 bacek joined #parrot
09:18 dalek TT #1435 created by gerd++: Tru64 report
09:58 bacek aloha
10:23 eternaleye joined #parrot
10:40 Austin_Hastings joined #parrot
10:49 eternaleye joined #parrot
11:25 dalek parrot: r43884 | bacek++ | trunk/src/gc/api.c:
11:25 dalek parrot: Made block/unblock GC functions optional.
11:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43884/
11:25 dalek parrot: r43885 | bacek++ | trunk/src/interp/inter_create.c:
11:25 dalek parrot: Propogate GC type from parent interpreter in allocate_interpreter.
11:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43885/
11:25 dalek parrot: r43886 | bacek++ | trunk/src/gc/api.c:
11:25 dalek parrot: Mage pmc_needs_early_collection optional.
11:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43886/
11:25 dalek parrot: r43887 | bacek++ | trunk/src/gc/gc_inf.c:
11:25 dalek parrot: Update GC INF to latest GC encapsulation API.
11:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43887/
11:28 cognominal joined #parrot
11:51 bluescreen joined #parrot
11:54 Whiteknight joined #parrot
12:03 Whiteknight good morning #parrot
12:04 mikehh__ hi whiteknight
12:07 bacek Whiteknight, aloha. You are early today :)
12:08 Whiteknight yes, I can't go to work this morning because of snow. So I am working the morning from home
12:08 Austin And the boss believes this?
12:08 Austin :)
12:08 Austin Yaay, snow!
12:08 bacek Show? Do you mean one of water's state?
12:09 bacek On streets???
12:09 bacek NO WAY!
12:09 Austin http://close-parrot.blogspot.com/
12:09 Austin I don't live very far away from Whiteknight.
12:10 Austin Maybe 25 km.
12:10 Whiteknight Austin: They haven't really plowed my apartment complex, I can't get my car out onto a real road
12:11 Whiteknight and from that point, I have zero faith that PennDOT has done any productive work since the storm stopped
12:13 bacek http://img-fotki.yandex.ru/get/4​114/bacek.d/0_335c4_2a738cdc_XL
12:13 bacek Photo was taken less than a month ago :-P
12:14 Austin Yeah, yeah. It's always nicer in the _other_ hemisphere...
12:14 ruoso joined #parrot
12:15 bacek Of course :)
12:15 Austin :)
12:16 Whiteknight replace the sand with snow, then turn all the colors to white, and remove all the people, and take away the beach, and that's exactly what it looks like from my window
12:17 bacek Yay. Like a beautiful dawn but green :)
12:18 bacek btw, gc_inf needs some love.
12:18 bacek Especially of someone with good literacy skills to update documentation :)
12:23 Whiteknight I'll see what I can do about gc_inf now.
12:25 Whiteknight gc_inf doesn't really have an "algorithm", so it's hard to imagine that it's too broken
12:25 mikehh__ fixed some codetest failures - missing function docs still needed
12:28 bacek Whiteknight, it works. But documentation is outdated
12:28 bacek badly
12:28 mikehh joined #parrot
12:29 Whiteknight bacek: doesn't work, I just tried it and segfault magic
12:29 Whiteknight no, wait. now it works. I had something weird before
12:30 dalek parrot: r43888 | mikehh++ | trunk/src/gc/gc_inf.c:
12:30 dalek parrot: fix codetest failure - there should be at least one space between a C keyword and any subsequent open parenthesis
12:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43888/
12:30 dalek parrot: r43889 | bacek++ | branches/boehm_gc_2:
12:30 dalek parrot: Yet another attempt to bring Boehm GC into Parrot
12:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43889/
12:30 dalek parrot: r43890 | bacek++ | branches/boehm_gc_2 (2 files):
12:30 dalek parrot: Copy configure auto::boehm from old branch
12:30 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43890/
12:30 bacek Whiteknight, "it was looong time ago" :)
12:31 Whiteknight I made a hack to get it working with make test
12:31 Whiteknight mv parrot parrot-exe; echo "#!/bin/sh\n./parrot-exe --gc inf $@" > parrot; chmod +x parrot
12:31 Whiteknight urg, it hangs on the stupid string_mem.t test
12:32 Whiteknight I hate that test, because it assumes too much about the operation of the GC
12:34 bacek Whiteknight, +1
12:35 Whiteknight In fact, I might just "accidentally" disable it. On accident
12:36 * bacek looking at nice night sky
12:36 Whiteknight we need to add a selector in interpinfo to get information about the current GC
12:36 Whiteknight each GC needs a string name that we can return
12:36 bacek Sounds reasonable
12:38 Whiteknight that way in tests like this we can detect current GC and disable unnecessary tests
12:38 KingOfKarlsruhe joined #parrot
12:39 mikehh bacek, Whiteknight: doyou want me to fix the documrntation stubs - or shall mI leave it for now?
12:39 Whiteknight which documentation stubs?
12:39 Whiteknight in gc_inf.c
12:39 bacek mikehh, yes please. You can also add ASSERT_ARGS (I missed them)
12:46 dalek parrot: r43891 | bacek++ | branches/boehm_gc_2 (3 files):
12:46 dalek parrot: Copy gc_inf into gc_boehm and add it into build.
12:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43891/
12:46 dalek parrot: r43892 | bacek++ | branches/boehm_gc_2/src (2 files):
12:46 dalek parrot: Add Boehm GC into list of available GCs.
12:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43892/
13:03 dalek parrot: r43893 | bacek++ | branches/boehm_gc_2/src/gc/api.c:
13:03 dalek parrot: Initialize Boehm GC in gc_init.
13:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43893/
13:03 dalek parrot: r43894 | mikehh++ | trunk/src/gc/gc_inf.c:
13:03 dalek parrot: fix codetest failure - correct missing documentation stubs
13:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43894/
13:19 dalek parrot: r43895 | bacek++ | trunk/compilers/imcc (8 files):
13:19 dalek parrot: Fix IMCC to use mem_sys_alloc/mem_sys_realloc/mem_sys_free
13:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43895/
13:19 dalek parrot: r43896 | bacek++ | branches/boehm_gc_2/src/gc/gc_boehm.c:
13:19 dalek parrot: First cut - use GC_* functions in gc_boehm.
13:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43896/
13:19 dalek parrot: r43897 | bacek++ | branches/boehm_gc_2/src/gc/alloc_memory.c:
13:19 dalek parrot: Copy alloc_memory.c from old branch
13:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43897/
13:19 dalek parrot: r43898 | bacek++ | branches/boehm_gc_2 (9 files):
13:19 dalek parrot: Merge branch 'master' into boehm2
13:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43898/
13:23 ttbot Parrot trunk/ r43900 i386-linux-thread-multi make error http://tt.ro.vutbr.cz/file/cmdout/193596.txt ( http://tt.ro.vutbr.cz//buil​dstatus/pr-Parrot/rp-trunk/ )
13:26 bkuhn joined #parrot
13:28 payload joined #parrot
13:28 bacek mikehh, you broke build...
13:30 mikehh bacek: make headerizer failed I think
13:30 mikehh can you try and run it
13:31 mikehh damnit I tested before I commited it
13:33 bacek mikehh, fixed
13:36 dalek parrot: r43899 | mikehh++ | trunk/src/gc/gc_inf.c:
13:36 dalek parrot: add ASSERT_ARGS
13:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43899/
13:36 dalek parrot: r43900 | whiteknight++ | trunk (4 files):
13:36 dalek parrot: add a GC_SYS_NAME option to interpinfo_s_i. Returns the name of the current GC system
13:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43900/
13:36 dalek parrot: r43901 | bacek++ | trunk/src/gc/gc_inf.c:
13:36 bacek ...and whiteknight's commit as well ...
13:36 dalek parrot: Restyle code to make headerizer happy.
13:36 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43901/
13:40 Whiteknight headerizer is broken on pirc, and I can't add my new function because of it
13:57 ilbot2 joined #parrot
13:57 ttbot joined #parrot
13:57 dngor_ joined #parrot
13:57 ingy joined #parrot
13:57 Tene joined #parrot
13:58 ascent joined #parrot
13:58 Ryan52 joined #parrot
13:58 Whiteknight joined #parrot
13:59 ruoso joined #parrot
14:03 particle joined #parrot
14:10 dalek parrot: r43905 | mikehh++ | trunk/src/gc/api.c:
14:10 dalek parrot: add ASSERT_ARGS
14:10 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43905/
14:13 slavorg joined #parrot
14:17 ashleyb joined #parrot
14:21 Coke ... how long has checkdepend been failing most of its tests?
14:21 Coke did someone add a new header file or something?
14:23 Coke cotto: having the FULL text of the comparison is useless when you have 59 deps in one and 60 in the other.
14:23 * Coke looks for that test module that highlights such things...
14:28 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32155), fulltest) at r43905 - Ubuntu 9.10 amd64 (g++ with --optimize)
14:39 rob joined #parrot
14:46 dalek parrot: r43906 | coke++ | trunk/tools/dev/checkdepend.pl:
14:46 dalek parrot: Make the test diagnostics here usable.
14:46 dalek parrot: (comparing very long strings that only differ by a bit is hard.)
14:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43906/
14:47 rob left #parrot
14:53 Coke Whiteknight: ... you probably ran configure with --maintainer.
14:54 Coke and since you have a different version of bison, it makes changes.
14:54 Whiteknight oh, damnit
14:54 Coke shouldn't /hurt/ anything, though.
15:01 janus joined #parrot
15:10 theory joined #parrot
15:15 bubaflub joined #parrot
15:18 dalek parrot: r43907 | coke++ | branches/rm_cflags (5 files):
15:18 dalek parrot: Add a suffix override for PMCs. (but don't do anything with it yet.)
15:18 dalek parrot: Avoid some warnings for imcc that occur in generated code.
15:18 dalek parrot: fix some warnings.
15:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43907/
15:24 Coke svn merge in 1.6 is muuuch nicer.
15:29 dalek pynie: r97 | allisonrandal++ | trunk/ports/plumage:
15:29 dalek pynie: Adding a directory for plumage files.
15:29 dalek pynie: review: http://code.google.com/p/pynie/source/detail?r=97
15:29 dalek pynie: r98 | allisonrandal++ | trunk/setup.py:
15:29 dalek pynie: Cleaning up intermediate executable files.
15:29 dalek pynie: review: http://code.google.com/p/pynie/source/detail?r=98
15:29 dalek pynie: r99 | allisonrandal++ | trunk/p (2 files):
15:29 dalek pynie: Move Plumage files to standard location.
15:29 dalek pynie: review: http://code.google.com/p/pynie/source/detail?r=99
15:34 Coke msg kid51 the merging in svn 1.6 completely removes the need for the tagging 2-step you do.
15:34 purl Message for kid51 stored.
15:39 dalek pynie: r100 | allisonrandal++ | trunk/setup.pir:
15:39 dalek pynie: Fix one character typo in Plumage build file.
15:39 dalek pynie: review: http://code.google.com/p/pynie/source/detail?r=100
15:40 silug_ joined #parrot
15:52 dalek parrot: r43908 | coke++ | failed to fetch changeset:
15:52 dalek parrot: merge from trunk
15:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43908/
15:54 Psyche^ joined #parrot
16:15 tewk_ Oh how I wish pir had native syntax support for closures.
16:16 tewk_ Also no one spoke up yesterday as to why the program counter isn't stored in the ctx or the interpreter.
16:17 moritz (closures) that probably means that you're writing something in PIR where you should really be using a higher level language
16:17 Whiteknight pmc2c--
16:18 darbelo karma pmc2c
16:18 purl pmc2c has karma of -21
16:18 tewk_ I wrote some code that broke out of a runloop early and I had to preserve the pc myself so I could restart the runloop later
16:18 darbelo pmc2c--
16:18 Whiteknight pmc2c--
16:20 tewk_ moritz, I have been converted/warped to believe that scheme is a good low level language to do programming language research on top of.
16:21 tewk_ In hind sight closures instead of subroutines would have been a better primitive for parrot to build on top of.
16:21 tewk_ Closures got added on top of subs, and its just ugly.
16:24 payload joined #parrot
16:25 dalek parrot: r43909 | coke++ | branches/rm_cflags/compilers/imcc (2 files):
16:25 dalek parrot: re-gen generated files
16:25 dalek parrot: (note to self: when merging, ignore merges of generated files and simply regen them.)
16:25 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43909/
16:30 Coke (scheme), ah, if only someone had written scheme-on-parrot 9 years ago.
16:32 Coke I shouldn't assume I can blindly pass -Wno-foo to a non-gcc compiler, right?
16:39 Whiteknight $P1 = $P0["str"] is calling get_pmc_keyed, not get_pmc_keyed_str. Any reason why that would be?
16:40 eternaleye joined #parrot
16:41 darbelo autoboxing?
16:41 purl autoboxing is just a toy thing
16:42 dalek parrot: r43910 | whiteknight++ | branches/op_pmcs/src/pmc (2 files):
16:42 dalek parrot: [pmc2c--] Fix Opcode and OpLib PMCs so they build and pass a few ad hoc tests I threw together.
16:42 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43910/
16:42 Coke purl, forget autobixing
16:42 purl Coke, I didn't have anything matching autobixing
16:42 Coke purl, forget autoboxing
16:42 purl Coke: I forgot autoboxing
16:43 Coke darbelo: autoboxing happens on sub/method calls, not opcodes.
16:44 Whiteknight I guess there is no way to call set_*_keyed_str directly
16:44 Whiteknight ops only support keyed and keyed_int
16:45 Whiteknight that's rediculous
16:45 darbelo Sounds like IMCC is to blame here.
16:47 cotto_w0rk joined #parrot
16:47 lucian joined #parrot
16:48 darbelo Write a ticket so we can reject it after we move to pirc ;)
16:50 Whiteknight geez, I can't even figure out now how to get a string out of this Key PMC
16:51 mikehh joined #parrot
16:58 dalek parrot: r43911 | coke++ | branches/rm_cflags/config/auto/pmc.pm:
16:58 dalek parrot: Avoid most of the warnings in pmc compilation (for gcc, anyway.)
16:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43911/
17:00 iblechbot joined #parrot
17:03 darbelo Crazy idea: Rewrite pbc_merge in PIR to determine the suitability of the packfile PMCs
17:05 NotFound darbelo: Slightly less crazy: rewrite it in some HLL
17:06 darbelo Unless HLL == NQP we can't ship it in the core distribution.
17:08 NotFound darbelo: we can ship generated pir.
17:12 darbelo Yeah, but I've never been too fond of that strategy.
17:12 Whiteknight +1 from me
17:13 Whiteknight PIR or NQP would both be acceptable, and much preferred to the current implementation
17:13 darbelo Hmm. Maybe pbc_dump would be easier.
17:14 darbelo Tht's just inspecting, no twiddling.
17:15 NotFound Dump is a good first step
17:20 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#32156), fulltest) at r43911 - Ubuntu 9.10 amd64 (gcc with --optimize)
17:34 ruoso joined #parrot
17:38 lucian joined #parrot
17:39 mikehh rakudo - make spectest_smolder #32157 - All tests PASS - parrot at r43911 - Ubuntu 9.10 amd64 (gcc with --optimize)
17:43 hudnix joined #parrot
17:49 [hudnix] joined #parrot
17:51 mikehh btw pugs seems to be at r29685 but rakudo make spectest_smolder only updates to r29188
17:52 hudnix joined #parrot
17:54 hudnix joined #parrot
17:57 cotto darbelo, good idea.  Starting with pbc_dump would be a good way to flush out bugs before moving on to a tool that's part of the build.
17:59 darbelo cotto: If this turns out right, we could even make dissasembled byteode rountrip-able.
17:59 cotto Whiteknight, PMCs should use INTERP in internal VTABLE functions and METHODs.
17:59 cotto (instead of interp)
18:00 * cotto goes to w0rk
18:01 Whiteknight ah, yes. I'm normally more consistent about that
18:13 Coke someone just pointed out http://help.github.com/terms/ F3. that seems a little much.
18:14 cognominal joined #parrot
18:16 cotto_w0rk seen pmichaud
18:16 purl pmichaud was last seen on #parrot 19 hours, 16 minutes and 7 seconds ago, saying: (the problem would still exist if there were other subs after this one :)
18:19 darbelo 2. You must be a human.
18:19 darbelo Chimps not allowed.
18:19 dalek parrot: r43912 | whiteknight++ | branches/op_pmcs/src/pmc (2 files):
18:19 dalek parrot: In PMCs, use INTERP instead of interp. cotto++
18:20 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43912/
18:22 cotto_w0rk darbelo, ?
18:22 purl rumour has it darbelo, is there anything in config_lib.pasm that gives us enough information
18:22 darbelo Agh. Wrong window.
18:22 cotto_w0rk I figured
18:33 davidfetter joined #parrot
18:56 cotto_working joined #parrot
18:57 payload joined #parrot
19:14 Coke can someone with a non-gcc compiler give rm_cflags a shot?
19:14 Coke I suspect it's currently broken anywhere that is not gcc.
19:16 Coke can someone explain callcontext pmc's SET_CELL_CELL(cell) to me? that looks like a noop.
19:17 Coke sorrty, SET_CELL_STRING(cell). looks like it does an in place cast and throws it away.
19:19 cotto_working istr that chromatic originally wrote that.  I'll take a look in a minute.
19:20 lucian joined #parrot
19:20 payload joined #parrot
19:22 tewk_ Sorry for being an idiot, CallContext does have a pc struct member.
19:22 Coke I can remove it all with no test failurs.
19:26 cotto_working Coke, I'd ask chromatic about it.  It does look suspiciously like a noop.
19:26 Coke (it is a noop, says the compiler)
19:27 Coke killing it in branch...
19:27 cotto_working It might not be an intentional noop though.
19:27 cotto_working That's the only reason I'd ask first.
19:30 ruoso joined #parrot
19:38 cognominal joined #parrot
19:42 Coke meh. he can revert a patch as easy as the next guy.
19:48 chromatic joined #parrot
19:53 Coke look, it's the next guy.
19:53 Coke chromatic: my latest commit might bother you. we're not sure.
19:54 chromatic r43913?
19:55 Coke ayup
19:55 Coke that look reasonable to you?
19:55 chromatic The diff is a little disturbing.
19:56 Coke INTVAL2PTR just does a cast, yes?
19:56 Coke but the usage of the macro of the macro ignores the return value.
19:58 dalek parrot: r43913 | coke++ | branches/rm_cflags/src/pmc/callcontext.pmc:
19:58 dalek parrot: Remove no-ops pointed out by extra Warnings.
19:58 dalek parrot: review: http://trac.parrot.org/parrot/changeset/43913/
19:58 chromatic Those macros might be wrong.
19:58 Coke entirely possible... but if they're wrong, and they're noops... all tests pass doing nothing.
19:58 Coke so I'd rather explicitly do nothing.
19:58 Coke (all tests pass in branch after that, too)
19:59 chromatic We probably need more tests for them then.
20:00 Coke no doubt.
20:01 chromatic Sounds like I volunteered.
20:02 Coke sorry. :(
20:02 cotto_working joined #parrot
20:02 Coke you could just open a ticket and let some plucky developer grab it!
20:03 pmichaud is there a way to find out how many gc runs are occurring in a given program?
20:03 pmichaud (from PIR, preferably)
20:03 Coke I think so.
20:04 Coke moment.
20:04 Coke pmichaud: in the meantime, have you read the github terms and conditions, specifically F3?
20:04 Coke (you agree to pay github's legal costs.)
20:05 pmichaud hadn't noticed that item particularly, no.
20:06 Whiteknight pmichaud: take a look at t/op/string_mem.t
20:07 chromatic interpinfo
20:07 purl i guess interpinfo is the culprit there.
20:07 Coke Whiteknight++
20:07 chromatic The argument is a constant from interpinfo.pasm... GC_MARK_RUNS or GC_COLLECT_RUNS.
20:10 pmichaud okay, thanks.
20:10 pmichaud I'm impressed with the improvements to GC on fib.nqp then.  bacek++ chromatic++
20:11 chromatic Have you noticed a measurable difference?
20:11 pmichaud bacek posted one, and I was just wanting to confirm  (getting reference)
20:11 pmichaud http://lists.parrot.org/pipermail/p​arrot-dev/2010-February/003775.html
20:12 pmichaud I get the same results on my system; it's a vast improvement over what we were getting in december, where running the .nqp version was taking twice as long as compile+run pir
20:12 cotto_working joined #parrot
20:13 pmichaud so, in december,  fib.nqp was requiring 20+ seconds on my system, today it's running in 10 seconds
20:13 pmichaud I was suspicious that perhaps gc had been inadvertently disabled altogether
20:13 pmichaud but that appears to not be the case
20:14 chromatic I added a couple of algorithmic improvements.
20:14 pmichaud well, whatever changes have been made, they seem to avoid the problems that dynamic compilation was introducing
20:15 chromatic Yeah, that was a nasty one.
20:15 chromatic I have a similar improvement to make in the next couple of days.
20:16 Whiteknight chromatic: what improvement?
20:16 purl improvement is external to the program contruct.. knuth may be saying there is no advantage going multithread inside the program?
20:16 cotto_working Whiteknight, a good test for the op-related PMCs would be to rewrite bacek++'s hello world generator with them.
20:17 chromatic Whiteknight, the XNA trick: run GC only after allocating a threshold.
20:20 Coke oh, that reminds me: let's remove 'make hello'
20:20 cotto_working pmichaud, I'd appreciate it if you could take a look at the ops_pct branch.  Configure/build as normal, run make opsc and prove compilers/opsc/t/01-parse.t.
20:20 Coke since we haven't supported directly generating a .o from .pbc in... some time.
20:21 cotto_working Coke, +1
20:21 joeri joined #parrot
20:24 Whiteknight cotto_working: bacek's hello world generator?
20:24 pmichaud cotto_working: what's the ops_pct branch?
20:25 cotto_working pmichaud, a branch to use pct-based tools to replace ops2c
20:26 pmichaud excellent
20:26 cotto_working Whiteknight, ./examples/pir/make_hello_pbc.pir
20:27 pmichaud cotto_working: I'll take a look, definitely
20:27 cotto_working much appreciated
20:28 cotto_working pmichaud, bacek and I worked on it a couple months ago and I'm trying to get it up-to-date.
20:36 dalek tracwiki: v26 | coke++ | BranchDescriptions
20:36 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Branc​hDescriptions?version=26&action=diff
20:36 dalek tracwiki: v27 | coke++ | BranchDescriptions
20:36 dalek tracwiki: http://trac.parrot.org/parrot/wiki/Branc​hDescriptions?version=27&action=diff
20:42 * Coke tries to build perl5i and fails.
20:44 bacek joined #parrot
20:49 kurahaupo joined #parrot
20:52 Whiteknight cotto_working: that's evil
20:53 cotto_working don't blame me.  bacek wrote it.
20:54 cotto_working (Though I'd argue that it's both evil and awesome.)
20:55 Whiteknight Oh, it is awesome
20:55 Whiteknight but the new Opcode PMC should make it less magical to compile an opcode
20:55 Whiteknight fewer magic numbers
20:55 cotto_working That's just was I was thinking.
20:59 Whiteknight the problem comes that to compile an opcode, we have to know whether each argument is held as a constant or in a register
21:00 Whiteknight urg, quite perplexing
21:01 cotto_working It's an interesting problem.  For now you can at least use "say_sc" and a magic number instead of two magic numbers.
21:03 Coke anyone have cl.exe handy?
21:04 Coke (er, the vc++ compiler)
21:04 particle coke: what do you need?
21:04 Coke particle: can you verify for me that you don't need slashes in makefiles converted to backslashes?
21:05 particle when passed as filenames to cl.exe?
21:05 particle or when used in "#include", or what?
21:05 Coke so we can have targets like src/gc/api$(O) and not src\gc\api$(O), and that yes, they work when used onthe command line.
21:05 particle that's actually cmd, not cl
21:05 Coke I'm fairly certain it's fine in targets or you would have broken after one_make merged.
21:05 particle and nmake.ext
21:05 Coke but in the build line...
21:06 particle yes, forward slashies should be ok, at least if you're not running windows 95
21:06 Coke we don't support win95.
21:06 particle yep
21:06 Coke I'm willing to go out on a limb there.
21:06 particle it's no longer a problem on win32
21:06 Coke ok. good. more crap I can rip out of the build.
21:06 cotto_working wheee
21:07 Coke rm_cflags branch currently borked on strawberry perl due to this.
21:07 particle however, some native commands like 'cd' won't work with forward slashes
21:09 Coke I don't think we should ever be using those.
21:10 Coke (we are for the 3 remaining recursive makes, but we shouldn't be.)
21:11 Coke particle: do you know whatever happened to our remote windows compiler access?
21:11 Coke was it "talk to alias"?
21:11 particle yes, i don't recall it getting past that state
21:12 particle i suppose now that i'm no longer building parrot regularly, it's more of a priority
21:13 NotFound Whiteknight: Will not be easier to put that PMC in trunk, marking it as experimental?
21:16 Coke I pinged alias. I'll let folks know what I hear.
21:19 cotto_working joined #parrot
21:23 davidfetter joined #parrot
21:35 Coke particle : rule seems to be: if it's an argument, slashes are fine. if it's a path-to-a-command, native slashes a must.
21:36 Whiteknight NotFound: we can merge it to truk
21:36 Whiteknight doesnt break the build anymore
21:38 NotFound Great
21:41 Whiteknight actually fails codetests, and no coverage in t/pmc yet
21:42 * Coke finds timethis.exe for windows and compares some stuff.
21:48 Whiteknight can somebody explain to me what a packfile fixup is?
21:48 cotto_working Sure.
21:49 cotto_working It maps sub names to bytecode offsets.
21:50 iblechbot joined #parrot
21:50 cotto_working i.e. sub foo's bytecode starts 24 opcode_t's into the bytecode segment
21:50 Whiteknight but dont the subs themselves contain info about thestart and end offsets?
21:51 Whiteknight In bacek's example, the sub contains that info
21:51 cotto_working It appears to be duplicated
21:51 Whiteknight ok
21:54 payload joined #parrot
21:55 Whiteknight a packfile can have multiple of the same types of segments so long as the have different names?
21:55 particle yes
21:55 particle so you can, for example, have multiple data segments
21:56 cotto_working There's oddness there.  Looking at pbc_to_exe.pbc with pbc_dump, the sub for main says it starts at offset 0 and ends at 161, but the fixup segment says it starts at 30 and ends at 36.
21:57 cotto_working nm.  The fixup table seems to be pointing at the constant table.
21:58 cotto_working s/at/into/
21:58 Whiteknight constant table? why would it point there?
21:59 Whiteknight in bacek's example the fixup has offset 5, but constants only go to idx 4
22:00 dalek TT #1436 created by fperrad++: Crash on Windows
22:01 cotto_working joined #parrot
22:03 cotto_working The offsets into bytecode are stored in the sub in the const table.
22:03 Whiteknight ...LOLWUT?
22:04 Whiteknight ah, nevermind. I see it
22:04 cotto_working Apparently end_offs isn't very important.  I can delete and change it and the example runs fine.
22:04 Whiteknight so fixup points to the Sub PMC in the const table, which points to the bytecode offset
22:05 Whiteknight got it
22:06 cotto_working The sub init code doesn't ignore end_offs.  Possibly it's only important when you have more than one sub.
22:06 cotto_working yup
22:06 cotto_working . o O (worst connection evar)
22:07 Whiteknight Probably used at runtime to prevent non-local jumps
22:14 cotto_working maybe a make_fib is in order.
22:14 cotto_working It wouldn't be much harder.
22:16 cotto_working or something more complex to flesh out what kind of abstractions we'd need for larger-scale pbc generation
22:17 Whiteknight I was just thinking that this whole process was ripe for an abstracting library
22:20 cotto_working quite
22:20 Whiteknight an add_sub() function could take the sub and an array of bytecode, and update the raw segment, constants segment, and add a fixup too in one shot
22:21 Whiteknight combine that with routines to build the bytecode in the first place, and we have a winner
22:21 cotto_working It could be a boon for pir/nqp-based pbc_merge and pbc_dump too.
22:22 NotFound I think end_offs is used when looking for annotations.
22:22 cotto_working self-hosting++
22:22 Whiteknight what bacek's example doesnt show is using a register
22:22 Whiteknight PCT could make big savings if it output PBC directly
22:24 GeJ Good morning everyone.
22:24 Whiteknight hello GeJ
22:24 cotto_working I think you don't have to do anything special to use a register other than call foo_[insp]_... and make sure there's something initialized in the register in quesstion.
22:24 cotto_working hi GeJ
22:24 GeJ Hi Whiteknight
22:25 GeJ hi cotto
22:25 Whiteknight cotto_working, but the one he used was an offset into the constants table
22:25 Whiteknight so how does the op decide if it's a constant or a register?
22:26 darbelo Whiteknight: You can try a simple pasm example and pbc_dump it.
22:26 cotto_working Whiteknight, that's determined by which op is used.
22:27 cotto_working say_sc vs say_s for example
22:27 Whiteknight cotto_working, ah, ok
22:27 cotto_working http://nopaste.snit.ch/19563
22:28 cotto_working In that example note that all the references to the pmc use register 0
22:29 Whiteknight Imagine the runtime savings if PCT could output PMC constant aggregates in bytecode instead of having to build them at runtime!
22:30 * Whiteknight starts to drool
22:33 tewk_ We just need a register allocator in nqp now :)
22:37 Whiteknight that wouldn't be too too hard, I dont think
22:38 Whiteknight assuming NQP could keep track of when registers are used and released
22:38 Whiteknight that's the hard part
22:40 chromatic Not with SSA.
22:42 darbelo We don't do SSA.
22:42 Whiteknight SSA?
22:42 purl rumour has it SSA is *fast*. or Static Single Assignment
22:42 tewk So i wrote a runloop that only allows a few safe instructions (non allocating) to execute.
22:42 Whiteknight ah, ok
22:43 tewk If you try to execute an unsafe instruction it forces the runloop off of a thread and back to the main thread.
22:43 darbelo tewk++
22:44 tewk In nother words unsafe operations are serialized on the main thread.
22:44 darbelo Nice.
22:45 cotto_working sounds safe and expensive
22:45 cotto_working where's the code live?
22:45 tewk The run loop wasn't much code.  I was thinking... Given Lorito's future functionality it should be possible to dynamically create custom runloops at runtime. security sandboxes etc.
22:45 cotto_working I'm always up for a new runloop.
22:46 darbelo tewk: Is this all proof-of-concept or do you expect to merge that work into trunk?
22:46 tewk cotto_working, its just a prototype, in my personal git repo.
22:46 tewk I'm willing to push it somewhere for others to look at.
22:46 chromatic Run loops aren't much code, now.
22:46 * darbelo wants to see the shiny.
22:46 cotto_working nope.  chromatic++ for that work.
22:46 joeri joined #parrot
22:47 tewk I still have to fix gc and allocation.
22:47 cotto_working Well, most runloops aren't much code now.
22:47 slavorg joined #parrot
22:48 tewk I'm not sure runtime generated runloops are useful, but its a cool idea.
22:48 cotto_working In that context, what part of the runloop would be generated?
22:48 darbelo I'm all for "safe runloop sanboxing" if nothing else
22:49 tewk basically the predicate that says whether an opcode is safe or not.
22:49 chromatic Make it table-driven and it's trivial.
22:52 tewk yep, I was think crazy things like a meta runloop that could do arbitrary computations based on the bytecode stream being executed.
22:57 cotto_working joined #parrot
23:01 bacek_at_work joined #parrot
23:02 cotto_working hio bacek_at_work.  Your make_hello_pbc.pir generated some good discussion.
23:02 bacek_at_work cotto_working,  o hai.
23:02 bacek_at_work What about it?
23:03 cotto_working It'll be less mysterious when Whiteknight's oplib PMCs are used to generate the opcodes, and to do more we'll need a library to take care of the low-level details.
23:04 bacek_at_work Ah. Yes, of course.
23:09 cotto_working Whiteknight++ for all the GSoC blogging.  If anyone asks for ideas, there's a good chance you've covered something they'll find interesting.
23:09 darbelo We should move that into an actual 'ideas page'
23:10 cotto_working s/we/darbelo/
23:10 darbelo s/darbelo/whiteknight/
23:11 darbelo See, I can delegate too!
23:12 darbelo Besides, I am unworthy to summarize Whiteknight's uniquely elegant prose in a way that would do it justice.
23:12 cotto_working nice try
23:12 * purl indulges in a bit of evil laughter.
23:13 cotto_working A wiki page with summaries is a good idea.  Maybe I'll tackle that if other Parrot stuff is too frustrating.
23:14 bacek_at_work Is "World domination" in list of GSoC ideas?
23:14 chromatic Next year.
23:14 purl next year is likely to have better beer
23:14 bacek_at_work ah, ok.
23:15 bacek_at_work I'll apply as mentor than
23:15 cotto_working It's right after "dynamic generation of the dtrt op".
23:15 darbelo bacek++ # mentoring world domination
23:16 cotto_work joined #parrot
23:18 patspam joined #parrot
23:37 cotto_work dukeleto, where's the audio from pdx.pm talks posted?
23:40 chromatic http://pdxpm.podasp.com/arch​ive.html?pname=meetings.xml
23:43 cotto_work joined #parrot
23:44 dukeleto 'ello
23:44 davidfetter hai dukeleto
23:44 cotto_work chromatic, thanks
23:44 cotto_work hi
23:44 dukeleto Video of my intro to #parrot talk at #pdxpm last night: http://ping.fm/7rGS5 Slides: http://ping.fm/Qz4QO
23:44 dukeleto davidfetter: ahoy!
23:44 davidfetter oh, cool
23:45 cotto_work 1.5 hours?  That's a lot of parrot.
23:45 * davidfetter watches
23:45 dukeleto cotto_work: indeed. people asked a bunch of questions
23:46 dukeleto i think it was a success. lots of people had heard of parrot but did not know about recent advances
23:46 davidfetter is there some generic system for video + slides?
23:46 cotto_work Sweet.  Maybe we'll get some more Parrot hackers out of the deal.
23:46 dukeleto one person said "i heard of it 8 years ago and that is about it", which made me laugh
23:46 cotto_work or hlls, or libraries...
23:47 dukeleto cotto_work: yes, one attendee is dead set on a new Scheme on Parrot which he calls "NoScheme"
23:47 dukeleto wagle: where is your noscheme repo?
23:48 slavorg joined #parrot
23:48 cotto_work We can never have too many schemes.
23:48 cotto_work or Schemes. ;]
23:50 dukeleto davidfetter: it would be nice for videos and slides to know about each other, but not that I know of
23:51 davidfetter there are some proprietary solutions that have the slides in one window and the video in another

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

Parrot | source cross referenced