Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-23

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 bacek_ time to go to $dayjob.
00:07 Infinoid msg cotto Great group photo!  needs labels tho, who is who? :)
00:07 purl Message for cotto stored.
00:18 Limbic_Region joined #parrot
00:22 Infinoid I think top row #2 is jkeenan/kid51
00:22 Infinoid and I think bottom row #5 is jhorwitz
00:28 Coke yes.
00:28 Coke oddly, top #1 looks a bit like me.
00:28 dalek parrot: r39729 | coke++ | branches/context_pmc (5 files):
00:28 dalek parrot: Remove Parrot_context_ref_trace & CTX_LEAK_DEBUG
00:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39729/
00:29 s1n_yapc joined #parrot
00:29 Infinoid The only parroteer I've met in person is particle, and that was unfortunately very brief
00:42 japhb joined #parrot
00:48 wayland76 joined #parrot
00:51 dalek parrot: r39730 | coke++ | branches/context_pmc (4 files):
00:51 dalek parrot: Add (unused) Context PMC
00:51 dalek parrot: Has all elements from Parrot_Context struct. (but Parrot_Context -> PMC)
00:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39730/
00:53 mikehh bottom row #1 Bruce Grey/Util I think #2?
00:54 Infinoid ah, cool
00:55 mikehh is that cotto (or did he just take the picture?)
00:55 Coke I think that's cotto, yes.
00:56 mikehh sorry Gray
00:58 Infinoid Coke: So is that you, or just a doppelganger?
01:01 dalek tracwiki: v2 | bacek++ | Yapc10Bof
01:01 dalek tracwiki: Start describing group photo based on IRC discussions :)
01:01 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​Yapc10Bof?version=2&action=diff
01:01 mikehh So that gives us -> Coke, kid51, chromatic, whiteknight / Util, cotto, pmichaud, particle, jhorwitz
01:01 bacek (someone have to finish it)
01:01 Coke mikehh: no, that's not me.
01:01 Coke it just looks vaguely like me.
01:02 Infinoid s/Coke/unCoke/
01:07 dalek tracwiki: v3 | Infinoid++ | Yapc10Bof
01:07 dalek tracwiki: I think these are right... apologies if I'm wrong!
01:07 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​Yapc10Bof?version=3&action=diff
01:08 Infinoid Free karma for whoever gets the other two :)
01:17 Maddingu1 joined #parrot
01:17 GeJ joined #parrot
01:38 s1n_yapc joined #parrot
01:44 guru joined #parrot
01:46 dalek TT #502 reopened by coke++: [PATCH] build on OpenBSD/ppc
01:56 wayland76 joined #parrot
01:56 amuck joined #parrot
01:58 amuck__ joined #parrot
02:10 amuck joined #parrot
02:21 amuck joined #parrot
02:53 rg joined #parrot
02:54 amuck joined #parrot
02:56 guru left #parrot
02:58 cotto joined #parrot
02:58 cotto wb me
03:00 cotto darbelo++ #generated tests
03:00 cotto darbelo++ #generated tests that fail
03:00 cotto darbelo++ #generated tests that fail, but will eventually pass
03:01 wayland76 joined #parrot
03:03 cotto Infinoid, the pictures are labeled
03:05 dalek tracwiki: v4 | cotto++ | Yapc10Bof
03:05 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​Yapc10Bof?version=4&action=diff
03:19 dalek TT #734 closed by jkeenan++: Branch cleanup:  pdd30_install
03:22 nopaste "tene" at 24.10.252.130 pasted "gl-devel libs for japhb++" (7 lines) at http://nopaste.snit.ch/17005
03:24 amuck joined #parrot
04:01 dalek parrot: r39731 | cotto++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
04:01 dalek parrot: [pmc2c] aggregate a couple adjacent heredocs
04:01 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39731/
04:07 s1n_yapc joined #parrot
04:25 Theory joined #parrot
04:41 dalek parrot: r39732 | cotto++ | branches/pmc_pct/compilers/​pmcc/src/parser/grammar.pg:
04:41 dalek parrot: [pmcc] get a nice increase in parsing speed by capturing more than once character at a time from C function bodies
04:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39732/
04:43 japhb Tene: we have different versions, but the only difference in package *names* is that I had mesa-libGLw-devel installed.  I'm not sure that should matter at all.
04:44 dalek parrot: r39733 | cotto++ | branches/pmc_pct/compilers/pmcc/src/emitter (2 files):
04:44 dalek parrot: [pmcc] emit more of class_init and some (probably broken) VTABLE function bodies
04:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39733/
04:47 japhb Tene: My next thought is that you are running nVidia proprietary drivers, aren't you?  If so, on Debian at least, you have to have the (exactly) matching nvidia-glx-dev package.  Version skew or using just the Mesa -dev packages alone won't work.
04:48 japhb Tene: There may be a similar issue on Fedora.  (I can't tell, because my only Fedora box has ATI hardware.)
04:48 Tene I am using nvidia proprietary
04:48 Tene lemme change that
04:54 dalek parrot: r39734 | cotto++ | branches/pmc_pct/compilers/pmcc/src/parser (2 files):
04:54 dalek parrot: [pmcc] parse some more PMC traits
04:54 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39734/
04:55 jq joined #parrot
05:05 Tene japhb: okay, I got my system in a situation where Parrot's GL works.
05:05 Tene japhb: I've got X running under nouveau.
05:05 Tene glxinfo reports direct rendering: No and OpenGL renderer string: Software Rasterizer
05:07 flh joined #parrot
05:27 japhb Interesting
05:28 japhb Tene: But this is a step forward, in that we can rule out "completely fubar".  And in fact it sounds like things are narrowed down to the combination of driver and devel packages.
05:28 japhb Tene: What method did you use to install the nvidia proprietary packages?
05:41 mikehh joined #parrot
06:03 uniejo joined #parrot
06:05 Tene japhb: rpmfusion
06:05 Tene what did you use?
06:08 bacek cotto: are you sure that  r39732 didn't break t/06-body.t?
06:09 japhb Tene: I've used both the Debian packages, and the nvidia self-extractor.  I vastly prefer the Debian packages, but Debian has a systemic problem with not keeping past package versions, and sometimes the latest one is unusable on my card, and then I have to use some older nVidia self-extractor.  But I haven't yet figured out how to get the nVidia scripts to install the proper -dev bits, so then I'm SOL trying to compile Parrot with OpenGL b
06:09 japhb indings then ...
06:09 japhb Tene: does RPMFusion have -devel packages for the nVidia drivers?
06:11 Tene um, dunno
06:11 nopaste "tene" at 24.10.252.130 pasted "yum search nvidia for japhb++" (66 lines) at http://nopaste.snit.ch/17006
06:13 japhb nVidia: Your "unified driver" is failing to remain unified.  By any stretch of the imagination.
06:14 Tene which should I install?
06:15 japhb It looks like "xorg-x11-drv-nvidia-devel"
06:15 japhb Assuming you are using "xorg-x11-drv-nvidia-libs" along with the kmod
06:18 nopaste "tene" at 24.10.252.130 pasted "rpm -qa '*nvidia*' for japhb++" (12 lines) at http://nopaste.snit.ch/17007
06:22 japhb OK, 185 is the current series, so you should be able to use xorg-x11-drv-nvidia-devel and xorg-x11-drv-nvidia-libs (if they work anything like the Debian equivalents, they're either virtual packages or release-tracking packages, either way they should work)
06:23 japhb I will say, though, that 185.18.14 is the release that refused to work on my poor laptop's card (an m7800)
06:37 japhb Tene: Any luck with the installs?
06:38 Tene afk phone
06:38 japhb k
06:48 clunker3 joined #parrot
06:59 magnachef joined #parrot
07:02 iblechbot joined #parrot
07:49 barney joined #parrot
08:28 donaldh joined #parrot
08:31 masak joined #parrot
08:43 clinton joined #parrot
09:10 wayland76 joined #parrot
09:18 bacek_ joined #parrot
09:24 bacek_ o hai...
09:58 Infinoid good morning
09:58 purl And good moroning to you, Infinoid.
09:58 bacek_ good moroning, Infinoid
09:59 Infinoid purl is always so negative
10:00 bacek_ Almost all girls are same.
10:09 dalek parrot: r39735 | bacek++ | branches/tt761_keys_revamp/​lib/Parrot/Pmc2c/Method.pm:
10:09 dalek parrot: [pmc2c] Fix handling trailing spaces in "void" MULTIs.
10:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39735/
10:12 dalek parrot: r39736 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
10:12 dalek parrot: [pmc] Migrate Hash.set_integer_keyed(_something)? to "brave new world".
10:12 dalek parrot: Use MULTIs for distinguish Keys from other PMCs in set_integer_keyed.
10:12 dalek parrot: Use hash_key_from_TYPE and hash_value_from_TYPE instead of blind cast to void*.
10:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39736/
10:12 dalek parrot: r39737 | Infinoid++ | trunk/compilers/imcc/pbc.c:
10:12 dalek parrot: [cage] c_parens.t fix.
10:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39737/
10:15 * bacek_ discovered that he has registered at identi.ca more than year ago...
10:18 mikehh joined #parrot
10:19 mikehh infinoid: was just about to paste a patch, but you already fixed it
10:19 mikehh manifest also needs regenerating
10:19 nopaste "Infinoid" at 65.18.171.17 pasted "Serious I/O breakage" (20 lines) at http://nopaste.snit.ch/17009
10:21 Infinoid I got that joyful behavior after turning line buffering on for stdout
10:21 Infinoid Note that the handles in question have nothing to do with stdout.
10:22 mikehh codetest, manifest_tests FAIL, All others PASS make fulltest r39734
10:22 mikehh Ubuntu 9.04 i386
10:22 bacek_ Infinoid: looks like issue that Whiteknight described couple of days ago.
10:22 bacek_ Incorrect order of destruction
10:23 Infinoid bacek_: What, between FileHandle and Handle?  hmm, could be
10:23 Infinoid mikehh: If you have a manifest patch, I'll apply it.  I'm using git here, so the manifest scripts fail
10:24 Infinoid I particularly love the way it tries to flush stdin
10:25 bacek_ I'm not sure that it is stdin. It's in forked child afaik
10:26 nopaste "infinoid" at 65.18.171.17 pasted "[patch] line/block buffering for stdout" (62 lines) at http://nopaste.snit.ch/17010
10:26 Infinoid src/io/unix.c assumes it is stdin
10:26 mikehh #   Failed test 'No need to regenerate MANIFEST.SKIP'
10:26 Infinoid if it were an output handle, the kernel wouldn't have returned EINVAL
10:27 bacek_ ah, ok.
10:27 Infinoid msg Whiteknight I tried turning on line buffering for stdout to see if it had a performance impact, and ran into what looks like another ordered destruction issue with FileHandle and Handle.  See http://nopaste.snit.ch/17010 and http://nopaste.snit.ch/17009.  You saw this a couple of days ago, how did you fix it?
10:27 purl Message for whiteknight stored.
10:29 mikehh infinoid: I see the mystery Coke lookalike was Austin_Hastings
10:30 mikehh somewhat obscured by Util
10:30 Infinoid cool
10:32 Infinoid I noticed that by default, parrot's stdout handle has a 0-sized buffer.  I'm not sure if all FileHandles are like that or if stdout is a special case, but I figured stdout should have an impact on the test suite runtimes.
10:38 bacek_ It definitely should
10:42 wayland76 joined #parrot
11:00 JC1 joined #parrot
11:05 guru joined #parrot
11:14 dalek parrot: r39738 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
11:15 dalek parrot: [pmc] Implement hash_value_to_number. Slightly refactor get_number_keyed_TYPE to use it.
11:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39738/
11:15 dalek parrot: r39739 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
11:15 dalek parrot: [pmc] Implement (get|set)_value_type in Hash.
11:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39739/
11:15 bacek_ *incoming*
11:18 bacek_ dalek: hey. One more commit!
11:18 bacek_ :)
11:18 dalek parrot: r39740 | bacek++ | branches/tt761_keys_revamp/t/pmc/hash.t:
11:18 dalek parrot: [t] Add tests for storing different value-type in Hash.
11:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39740/
11:19 Infinoid racey bot
11:19 bacek_ good bot :)
11:19 purl :)
11:19 bacek_ purl: not you!!!
11:19 purl Whatever.
11:21 Infinoid <purl--> # dork
11:21 donaldh joined #parrot
11:21 * bacek_ start loving Hash implementation in Parrot.
11:21 bacek_ It was made by some very clever guy!
11:21 bacek_ O wait...
11:22 szabgab joined #parrot
11:23 Infinoid uh.  I don't think this is an ordered destruction issue, Whiteknight didn't actually check in his filehandle-encapsulates-handle patch
11:23 bacek_ hmm...
11:24 bacek_ Infinoid: time to use power of gdb and check who call fsync on closed handle.
11:26 s1n_yapc joined #parrot
11:26 Infinoid Working on that.  There are actually a few issues here
11:27 Infinoid For instance, if the file ever drops off (stale nfs handle, for instance), PIO_WRITE returns -1 in Parrot_io_flush_buffer(), and parrot will repeatedly toss the same exception until it runs out of stack
11:28 bacek_ oh shi...
11:30 * bacek_ passing famous book by Stevens to Infinoid
11:32 guru left #parrot
11:33 Infinoid I've been thinking about detecting multiple exceptions of the same type from the same place and handling the double-fault differently (and not using pio for that)
11:33 Infinoid But that's a separate patch
11:33 burmas joined #parrot
11:34 Infinoid (and currently just vaporware)
11:35 davidfetter joined #parrot
11:38 bacek_ It's... not easiest thing in the world.
11:40 Infinoid the only difficult part I see is differentiating recursive exceptions from serial exceptions
11:41 Infinoid because we're calling these things as continuations, I can't just wait for it to return
11:41 Infinoid or maybe I can.  But it means I need to understand PCC better than I currently do :)
11:44 Whiteknight joined #parrot
11:47 bacek_ actually there is 2 problems
11:47 Infinoid Whiteknight: I made you a purl msg, but then I realized I'm an idiot, nevermind :)
11:47 bacek_ "ex_throw_from_c" doesn't unwind C stack.
11:47 Whiteknight yeah, I have that "I'm an idiot" realization multiple times per day
11:47 Whiteknight ...and there's purl!
11:47 bacek_ second: there is no stack in Parrot :_
11:47 Whiteknight bacek_: there is 1 stack left
11:48 Infinoid bacek_: Right, so I'd have to use a global.  Which means I couldn't detect flipflopping exceptions
11:48 Whiteknight deprecated in 1.5
11:48 Infinoid Whiteknight: We're talking about detecting recursive exceptions and implementing a failsafe double-fault handler
11:48 bacek_ Whiteknight: I'm from future :)
11:49 Infinoid When PIO_WRITE returns -1 in Parrot_io_flush_buffer(), parrot repeatedly tosses the same exception until it runs out of stack
11:49 Infinoid That's happened a few other times, so I was thinking it would be nice to be a little smarter about that
11:49 Infinoid But it isn't easy :)
11:49 jdv79_ joined #parrot
11:50 Infinoid Then again, it's perfectly ok if handling one kind of exception raises another one
11:50 Whiteknight Infinoid: what's important is that an infinite problem of exceptions causes parrot to exit, not recurse and segfault
11:51 Infinoid yes, preferably with a nasty looking message that tells you where to fix it
11:51 Whiteknight very very nasty messages
11:51 Whiteknight Parrot: exception b0rked. STFU and fix it!
11:52 Infinoid So the problem I have messing with PIO is, the exception message emission uses PIO
11:52 Infinoid but a similar case can probably happen with broken encoding plugins
11:52 Infinoid I'd really love a failsafe handler that just falls back on stderr, prints the message if it can, and CANNOT fail
11:53 Infinoid that means... does not call PCC, does not allocate memory, nothing fancy at all
11:54 Infinoid all of that is fine.  But how do you detect when the previous exception handler has exited?
11:54 Infinoid I want to disambiguate between recursive exceptions and serial exceptions
11:55 Infinoid s/exited/returned/
11:55 bacek_ Infinoid: welcome to C++ world! :)
11:56 bacek_ All this issues were solved many years ago...
11:56 Whiteknight Infinoid: it is quite a problem
11:56 Whiteknight ...in a galaxy far far away...
11:57 Infinoid I didn't think C++ used continuations, so I'm not quite sure they solved this
11:57 Infinoid Ok, I'm clueless.  I need to understand how parrot calls exceptions better, and then I will revisit this
11:59 Whiteknight yeah, we could all use a better understanding of it
12:00 Infinoid In the meantime, I'll see if I can fix up this stdout buffering patch, while waiting for the verizon installation guy
12:00 Whiteknight apparently Allison implemented the current system, so you can prbably put any questions past her
12:01 Infinoid Do you happen to know if FileHandles buffer by default?  Because stdout doesn't
12:02 Whiteknight Infinoid:  what about a linked-list of exceptions (not a stack) and when we reach a list with duplicates or a list above size N, we just exit
12:02 Whiteknight I have no idea about the default settings, I still need some research
12:02 Whiteknight that patch I sent you for io_cleanups is very out of date now, I would need to send an update
12:02 Whiteknight brb, breakfast
12:02 Infinoid oki
12:06 Infinoid back later &
12:08 jdv79 joined #parrot
12:20 Whiteknight joined #parrot
12:25 skids joined #parrot
12:36 Whiteknight joined #parrot
12:37 cotto joined #parrot
12:37 cotto bacek, ping
12:37 bacek_ cotto: pong
12:38 cotto bacek_, in pmcc, is there any reason not to slurp up a VTABLE function's body and apply a bunch of regexes to do SELF.add_int-><dtrt> instead of the current approach?
12:39 cotto Having files parse in .5s instead of 5s is a nice change.
12:40 bacek_ I know... But it's failing badly...
12:40 bacek_ Ok. Our current approach is wrong.
12:40 cotto btw, that test does fail.  I'll dedicate some time to fixing valid failing tests (which includes most or all of them) before the end of YAMP.
12:41 cotto bacek_, how so?
12:41 bacek_ But re-implement pmc2c approach is wrong either.
12:41 afk_coke yamp?
12:41 Coke yamp?
12:41 cotto The code does seem a little convoluted.
12:43 bacek_ cotto: look, we don't have to parse current PMCs.
12:43 bacek_ We have to parse some L1HIGH language.
12:44 Whiteknight joined #parrot
12:44 bacek_ From which we can emit C code semantically equivalent to current PMCs pseudo-C code.
12:45 cotto bacek_, right.  My approach is to do minimal parsing for current PMCs such that we *can* later add different parsers for VTABLE (etc) function bodies.
12:45 cotto actually my current approach is just to spit out code similar to what pmc2c does.  I should probably give extensibility some thought at some point.
12:46 bacek_ than just use bunch of regexes stolen from pmc2c to replace stuff in.
12:46 bacek_ stuff in bodies.
12:47 whoppix joined #parrot
12:47 cotto yeah.  That'll be enough for now, as long as the code that deals with function bodies is reasonably well encapsulated.
12:47 bacek_ I propose to steel "subst" from rakudo to do this
12:47 bacek_ erm...
12:47 bacek_ steal
12:47 cotto Is that different from the substr opcode?
12:48 masak yes.
12:48 bacek_ "substr" do plain string substitution
12:48 masak substr does substrings.
12:48 masak subst does substitutions.
12:48 bacek_ "subst" - regexp based
12:48 cotto sounds handy
12:48 cotto very handy
12:48 bacek_ implemented by masak. O wait.
12:49 masak well, parts of it.
12:49 purl parts of it are in English
12:49 masak purl: parts of you are very annoying.
12:49 purl OK, masak.
12:49 s1n_yapc joined #parrot
12:50 bacek_ masak: it's good part. And probably will be enough for pmcc.
12:51 masak \o/
12:52 masak what's pmcc again? :)
12:53 bacek_ PMC compiler written in PCT
12:54 bacek_ like... Baron Munhgauzen pulling himself
12:54 cotto bacek++
12:54 cognominal joined #parrot
12:56 masak ooh, nice.
12:56 masak so the first time you compile that, you need something to bootstrap?
12:57 bacek_ masak: indeed. But we can commit "previously generated C files" to svn. Similar to bison/flex files
12:57 masak ah. nice.
12:58 * masak likes bootstrapping in all forms
12:58 * bacek_ thinking about using STD.pm in "bootstrapped rakudo" :)
12:59 pmichaud Good morning #parrot
12:59 bacek_ good mor^ localtime(), pmichaud
13:02 gryphon joined #parrot
13:08 mikehh snap - how's YAPC 10 etc goin'
13:10 wayland76 joined #parrot
13:10 wayland76 Here I am on #parrot
13:10 wayland76 pmichaud suggested we continue a conversation about both Rakudo and Parrot´s install processes here.
13:11 pmichaud 13:08 <wayland76> My hope all along has been to make the Rakudo install process use any relevant and useful bits from the parrot install process
13:11 pmichaud I agree with that to some extent
13:11 pmichaud But I don't want HLLs to be limited to using Parrot's build tools
13:11 wayland76 No, of course not
13:11 wayland76 I´m just too lazy to write my own :)
13:11 pmichaud for example, I have strong disagreements with the structure of gen_makefile (and the Makefiles it generates)
13:11 wayland76 All I wanted was the MANIFEST part
13:12 pmichaud I have lesser disagreements there :-)
13:12 wayland76 Yeah, I agree
13:12 wayland76 But did you notice the recent refactor that kid51 and I did?
13:13 wayland76 (recent = within the last month or so, I think)
13:13 Infinoid My $0.02: Rakudo is currently the only HLL which builds and tests successfully against a (non-installed) parrot build tree, I've been wishing other HLLs did
13:13 pmichaud basically my issue is that if the standard in Parrot is that HLLs are supposed to use parrot tools for their own local build/install process, then Parrot's tools need an official API, documentation, etc.
13:13 mikehh pmichaud: where would you like gen_makefile to go?
13:13 pmichaud mikehh: I'd like us to supply a prototype gen_makefile that HLL implementors can then customize
13:14 pmichaud I don't want to be constrained to use the gen_makefile that is in Parrot's install
13:14 mikehh sounds good - what's involved in that
13:15 pmichaud This is what rakudo (and create_language.pl) currently do --they provide a generic gen_makefile when creating the language directory (more)
13:15 wayland76 pmichaud: Were you thinking of something like lib/Parrot/Install.pm ? :)
13:15 pmichaud wayland76: how do you mean?
13:16 wayland76 pmichaud: That´s got an API and documentation, and it´s the part that I want to call from Rakudo.  If the functions in there are called with the right parameters, it can read in a MANIFEST, and put the files wherever you´ve specified
13:17 pmichaud how much freedom is there in "put the files wherever you've specified"?
13:18 wayland76 Lots, I think.  The only things that call it at the moment are tools/dev/install_files.pl and tools/dev/install_dev_files.pl
13:18 wayland76 And they do things like pass in data structures that contain transformation functions that get run on the path
13:19 pmichaud anyway, the actual copying of files isn't the current blocker for this.
13:19 wayland76 (this is for the stage that´s roughly equivalent to ¨make install¨)
13:20 pmichaud so if the issue is handling of MANIFEST and where to place files.... that's not really been a blocker for me (and so I haven't thought about it much)
13:20 wayland76 Well, that´s the thing I´m interested in
13:20 pmichaud okay.
13:20 wayland76 It´s needed for packaging
13:20 pmichaud sure.
13:21 pmichaud but we also need to be able to _build_ the files to be installed in the first place.  :-)
13:21 wayland76 Of course.  But I claim no expertise there, I´m afraid :)
13:21 pmichaud okay.
13:22 pmichaud it's the "build and test" phase of dealing with an installed parrot that's the major issue for me at the moment.  What happens after that stage I've not thought as much about (or worried too much about)
13:22 wayland76 kid51 was saying you don't like the current Parrot MANIFESTs because they move things around too much
13:23 pmichaud that's not really what I was saying
13:23 pmichaud my complaint is that the build tree doesn't look _anything_ like the install tree
13:23 wayland76 I'll try to remember to test tomorrow morning whether building the Rakudo RPM against an installed Parrot RPM works for me
13:24 wayland76 pmichaud: Yes, that's what he actually said.  It was me that misinterpreted you :)
13:24 pmichaud things would be a lot simpler if I didn't have to constantly remap paths based on whether we're working from a build-copy of Parrot versus an install copy of Parrot
13:24 pmichaud for example
13:25 pmichaud to use NQP I have to have my makefile be smart enough to look in either   compilers/nqp/nqp.pbc or  lib/parrot/1.3.0/languages/nqp/nqp.pbc
13:25 wayland76 I never work from a build-copy, I guess, so that's why I haven't run into this :)
13:25 pmichaud Developers (and people who are using more recent copies of rakudo) want to be able to test Rakudo without installing it :-)
13:26 wayland76 Yes, I know that.  I just get the SVN, and turn it into RPMs, and install them :)
13:26 moritz shouldn't the solution be a parrot opcode (or PMC or whatever) that makes it load NQP (so that it doesn't have to appear in any Makefile)?
13:27 wayland76 But I can accept that not everyone works that way, just like I expect others to accept that I *do* work that way
13:27 pmichaud moritz: (parrot opcode) We need to be able to invoke nqp from a command line.  And Perl6Grammar, and a number of other tools.
13:28 pmichaud moritz: what _should_ happen is that there's a standard way for me to invoke parrot .pbc files as if they were executable
13:28 pmichaud (from a command line)
13:28 wayland76 how about a command line "parrot_invoke" tool that finds things for you :)
13:28 moritz pmichaud: ok
13:28 pmichaud Perhaps that means we need a fakecutable NQP.  I'm fine with that.
13:28 pmichaud We would also want/need a fakecutable Perl6Grammar.pbc .
13:29 pmichaud And I don't seem to get people to realize that Perl6Grammar is a command-line compiler, not a library.
13:29 moritz that doesn't really scale well, does it?
13:29 pmichaud ...scale well?
13:29 moritz adding a fake executable for everything that we need from rakduo
13:29 pmichaud This wouldn't be just for rakudo
13:29 wayland76 parrot_invoke Perl6Grammar.pbc
13:30 pmichaud it's needed for every language that wants to create a compiler for Parrot
13:30 pmichaud wayland76: that would be great, *if* I didn't have to do
13:30 pmichaud parrot_invoke (some_path_that_frequently​_changes)/Perl6Grammar.pbc
13:30 Coke I say again, I don't think installing parrot is a hardship.
13:30 pmichaud I'm not claiming it is.
13:30 wayland76 Maybe I should go to bed -- I'm out of my depth and not helping :)
13:31 wayland76 pmichaud: Yeah, I'm claiming that parrot_invoke should sort out the paths for you
13:32 moritz (and on demand tell you the path it sorted out)
13:32 wayland76 That would be nice too
13:32 pmichaud wayland76: that still sounds band-aid ish.  Ultimately we need to be able to compile things in Parrot that can be invoked from the command line (without having to be prefaced by "parrot")
13:32 pmichaud our "best effort" at that thus far is fakecutables.
13:34 wayland76 Ok, I was just suggesting an alternative to moritz complaint about scaling, which I assume was possibly a complaint about "command line namespace clutter", and I effectively suggested introducing a sub-namespace
13:35 pmichaud I'm not saying that NQP needs to be in a users' default PATH  :-)
13:35 Coke I think having fakecutables for all the compilers/ is reasonable.
13:35 pmichaud I think there may be a misconception that NQP is needed to _run_ rakudo.  NQP is only used at this time to _build_ rakudo; once rakudo is built, NQP no longer exists.
13:35 wayland76 Actually, paths could help with this, maybe
13:36 Coke (hurm. maybe not all; but certainly nqp)
13:36 pmichaud I'd primarily want nqp and Perl6Grammar
13:36 pmichaud since thsoe are the compilers that are used in building other hll compilers
13:36 wayland76 ie. at the command line: PATH=compilers/nqp:lib/parrot/1.3.0/languages/nqp nqp.pbc
13:37 pmichaud ugh
13:37 wayland76 Yeah, ugh :)
13:37 ilia joined #parrot
13:37 pmichaud the solution discussed at the workshop was that building parrot creates a local install image
13:37 wayland76 I'll give that idea the boot (the ugg boot, of course :) )
13:38 pmichaud (within the parrot tree)
13:38 pmichaud and then "make install" really just does the equivalent of copying that local install image to its ultimate location
13:38 wayland76 Did kid51 mention my idea of creating METAFESTs ?
13:39 Coke pmichaud: I hope that any discussions like that at the workshop that might influence policy are written up for the wiki or the list so we can all comment.
13:39 pmichaud Coke: certainly.
13:39 pmichaud Coke: it was more brainstorming of ideas than making decisions
13:40 pmichaud there weren't sufficient Parrot core committers there to be able to make any sort of policy decisions
13:40 Coke pmichaud: the last set of brainstorming was presented as decisions made; Just hoping not to repeat that mistake.
13:40 pmichaud The last set of brainstorming was done with a significant quorum of Parrot core committers present.  (Agreed totally that they were communicated badly and did not provide non-attendees with an opportunity to influence the decision.)
13:41 pmichaud Anyway, what happened this past weekend is very different (and had different goals) from the developer's summit
13:41 Coke pmichaud: not being at either of them, you can see where I'd have no clue about that. =-)
13:41 pmichaud correct.
13:41 Coke thanks for keeping us in mind. Appreciate it.
13:45 NotFound pmichaud: please don't forget TT #772
13:51 Andy_ joined #parrot
13:52 wayland76 pmichaud: What would you say to a function/program that you could call where you could tell it the build location of the file, and it would tell you the install location?
13:53 Coke it seems saner to have both places be the same.
13:53 Coke have the build generate a layout like install would.
13:54 wayland76 Coke: I agree as a general rule, and that's what pmichaud was (according to what I've heard) advocating at the brainstorm
13:55 wayland76 It's been suggested that input should be sought from Allison on this, and I'm under the impression that she's indisposed.
13:55 Coke perhaps input should be sought... on list. =-)
13:55 Coke it's where all the cool committers hang out. =-)
13:55 wayland76 Well, I'm a bad boy, I'm not on the list :)
13:55 Coke you're not on parrot-dev?
13:56 wayland76 No.  I'm only here because I want a Rakudo RPM that works on a Parrot RPM
13:56 wayland76 And I've got one that works, but pmichaud doesn't like my code, so this discussion is also part of us negoatiating a solution to that
13:56 ilia joined #parrot
13:57 wayland76 (well, the solution is me writing something that he likes, but he's said that he'll do some makefile hacking for me, and I'll rework things around that, and somehow we ended up here :) )
13:58 wayland76 Maybe I should just give in and join the list, though
14:00 Infinoid Coke: (cool committers) Well, I fail that... haven't been able to keep up with the lists for the last couple of weeks
14:00 wayland76 Coke: Part of my idea is that the code to turn build paths into install paths already exists
14:01 wayland76 It just needs to be turned into a library function :)
14:05 magnachef joined #parrot
14:11 wayland76 Ok, I'm on parrot-dev.
14:11 wayland76 Anyway, bedtime for me.  Goodnight
14:15 chromatic joined #parrot
14:15 chromatic Let's talk about L1 over lunch!  Meet by the registration room.
14:18 pmichaud I'll be there.  11:35, yes?
14:20 Whiteknight joined #parrot
14:20 dalek parrot: r39741 | whiteknight++ | branches/io_cleanups (16 files):
14:20 dalek parrot: [io_cleanups]. Handle is now a separate delegate type that encapsulates the low-level file descriptor, and is included as an attribute (not inherited by) FileHandle, Socket, Pipe, etc. These IO PMCs are now that much closer to being properly subclassable from PIR. Parrot builds with this change but there are some test failures. Likely, these are caused by passing a FileHandle to low-level functions that now expect a Handle, or vice-versa. Need help te
14:20 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39741/
14:24 ilia joined #parrot
14:26 chromatic joined #parrot
14:28 chromatic 11:35 yes
14:34 Coke chromatic: I propose we rename your L1 to C1 to avoid confusion with whiteknight's L1 (W1)
14:35 Whiteknight Coke: they're the same one now
14:35 Whiteknight basically
14:35 Coke ok. then we can call it CW2!
14:35 Whiteknight OMGORLYCW2?
14:35 Coke there we go. perfectly clear.
14:36 Coke Whiteknight: I am stabbing blindly at context_pmc branch; trying to remove stuff without actually doing the conversion yet. =-)
14:36 Coke (stuff that will be not needed when context aren't manually managed)
14:36 Coke doesn't help that "make test" fails on feather in trunk. :|
14:36 Whiteknight chromatic: where you at right now?
14:36 chromatic Earth.
14:36 Coke THis chat is coming from inside your own room.
14:36 chromatic 12 feet from The Chip.
14:37 Coke CHIP!
14:37 chromatic 14 feet?
14:37 Coke tell him I said hi.
14:37 Whiteknight okay, where is chip?
14:37 chromatic Earth.
14:37 Whiteknight increase your resolution!
14:37 chromatic NORTH AMERICA
14:37 purl rumour has it NORTH AMERICA is like 30% Spanish... it's more like 95% in South and Central America... there's out of the way places like the Philipines... and, most of western Europe at least UNDERSTANDS it
14:37 Coke 5) U.S.
14:37 chromatic que paso America!!
14:37 Coke que tal, freaks!
14:38 chromatic Ay, chulo.  No me gusta.
14:38 cotto joined #parrot
14:38 chromatic I'm in Rangoon 3 or whatever the R-word is.
14:39 moritz "room"?
14:39 purl it has been said that "room" is something refugees from AOL might say.  ITYM "channel".
14:39 chromatic The room has a specific name which isn't "Where Schwern and Chip are" but also starts with R.
14:40 chromatic Roanoke?
14:40 ruoso joined #parrot
14:41 Coke Chip Rangoon.
14:41 NotFound ...and most of Spain understand Spanish ;)
14:41 Coke verdad?
14:42 Whiteknight chromatic: is there a talk right now in rangos 3?
14:47 chromatic Yes.  Schwern's talking about perl5i.
14:48 kid51 joined #parrot
14:51 kid51 joined #parrot
14:53 kid51 Does anyone know why I didn't get opped when I joined the channel?  Is some bot down?
14:54 kid51 Thanks, slavorg
14:54 Topic for #parrotis now Parrot 1.3.0 "Andean Swift" released | http://parrot.org
14:54 Infinoid I had a second instance called "slavorgn" running for a while, but the server I was running it on no longer exists
14:55 kid51 Since the BOF is history, I simply wanted to delete it from the channel message.
14:55 Infinoid Cool.  How was it?
14:56 mikehh_ joined #parrot
14:56 kid51 Raw braindump output is available on YAPC wiki.
14:56 Whiteknight Infinoid: it was very productive I think
14:56 kid51 http://yapc10.org/yn2009/wiki?n​ode=Parrot%20Implementors%20BOF
14:57 kid51 There were more attendees than are listed there
14:57 Theory joined #parrot
14:57 Infinoid cotto posted some photos on https://trac.parrot.org/parrot/wiki/Yapc10Bof
14:58 kid51 whiteknight, particle, jhorwitz, Austin_Hastings, etc.
14:59 kid51 Plus, some unnamed participants from Deep Corporate!
15:00 cotto Someone should move the transcribed notes to our wiki where we know they won't disappear at an inopportune time.
15:04 Coke (our wiki)++
15:09 Whiteknight agreed, we'll move them to our wiki (and maybe add fun formatting!)
15:09 dalek parrot: r39742 | whiteknight++ | branches/io_cleanups/src/pmc (3 files):
15:09 dalek parrot: [io_cleanups] fix socket so it doesn't attempt to access it's Handle during destroy. This creates an order-of-destruction bug. Also, plug a leak where socket isn't freeing it's Parrot_Socket_attributes structure
15:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39742/
15:10 chromatic s/creates/fixes/
15:16 Coke when creating context pmcs, do I need to specifically mark anything that is an ATTR?
15:16 Coke or does that get appropriately marked without any effort on my part?
15:16 Coke s/context//
15:18 Coke cotto: as long as you're in there, any chance you can fix the long standing bug about not dropping unknown bits on the floor?
15:18 Coke (pmc2c in trunk)
15:18 kid51 joined #parrot
15:19 dalek parrot: r39743 | cotto++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
15:19 dalek parrot: [pmc2c] only emit custom class_init code if it exists
15:19 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39743/
15:21 cotto Coke, I'll check if it'd be worthwhile.
15:21 Whiteknight some of these io bugs are just obnoxious
15:24 magnachef joined #parrot
15:26 pmichaud Chip says  "PASM is to real assembly as Legos are to materials engineering"
15:27 pmichaud (in praise of Parrot, though)
15:27 moritz how's that a praise?
15:28 * moritz doesn't understand
15:28 cotto Coke, it looks like I can catch some specific things that pmc2c drops on the floor, but it'd need some big changes to ensure that nothing gets dropped silently.
15:28 Whiteknight Infinoid: ping
15:29 pmichaud it's more aimed at the point that Parrot (as a vm) has different goals and constraints from assembly languages designed in silicon
15:29 pmichaud the context is that chip was suggesting that learning assembly is a good skill to have when understanding C (or other languages), and the question arose whether Parrot assembly would qualify
15:30 pmichaud so the exact quote is something like  "it would be like using Legos to learn materials engineering"  :-)(
15:30 masak joined #parrot
15:30 Whiteknight purl msg Infinoid I got that issue fixed and committed it to the io_cleanups branch. Builds now. Have a few interesting test failures if you have  a moment to look at them.
15:30 purl Message for infinoid stored.
15:33 dalek parrot: r39744 | cotto++ | branches/pmc_pct/compilers/pmcc/src (3 files):
15:33 dalek parrot: [pmcc] generate some more code in class_init, add actions to support hll and maps traits
15:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39744/
15:53 s1n_yapc joined #parrot
15:57 Tene I don't know much about chip.  As far as I'm aware, he's some kind of mysterious enigmatic figure in the primordial past of Parrot
15:59 Patterner joined #parrot
16:11 viklund joined #parrot
16:14 masak http://en.wikipedia.org/wiki/Chip_Salzenberg
16:18 darbelo joined #parrot
16:20 MoC joined #parrot
16:28 Coke if dan is pre-cambrian, chip is permian.
16:28 st joined #parrot
16:28 s1n_yapc joined #parrot
16:29 st hi! does anyone know ho to spawn a new thread from PIR?
16:30 st *how
16:30 Coke st: check out examples/pir/thr-primes.pir ?
16:31 Coke whoops.
16:31 Coke that's apprently from an old revision.
16:32 st yes, i couldn't find it
16:32 Coke examples/sdl/mandel.pir // look for ParrotThread
16:32 Coke also perldoc src/pmc/parrotthread.pmc
16:33 Coke (ew. that shows PASM, not PIR)
16:34 st thanks!
16:34 Coke also t/pmc/threads.t
16:35 Coke good luck. =-)
16:44 kid51 joined #parrot
16:48 Psyche^ joined #parrot
16:50 jdv79 joined #parrot
16:57 mtk joined #parrot
16:58 s1n_yapc joined #parrot
16:59 mj41 joined #parrot
17:01 ilia joined #parrot
17:09 cotto joined #parrot
17:11 mjf joined #parrot
17:18 jhorwitz joined #parrot
17:27 davidfetter joined #parrot
17:36 mtk left #parrot
17:38 Austin_Hastings joined #parrot
17:39 Austin_Hastings left #parrot
17:39 dalek parrot: r39745 | pmichaud++ | trunk/compilers/pct/src/PCT/Dumper.pir:
17:39 dalek parrot: [pct]:  Correct some documentation in PCT's node dumper.  No functional changes.
17:39 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39745/
17:44 flh joined #parrot
17:44 s1n_yapc joined #parrot
17:49 chromatic joined #parrot
17:49 cotto bacek, it turns out that your key refactoring will make the road to L1 easier.
17:51 darbelo bacek++ # paving the road to shiny!
17:52 kid51 joined #parrot
17:53 cotto We had a good discussion here about how to make the future happen.  Expect a writeup from Whiteknight++ soon.
17:54 * cotto looks at darbelo's new and shiny generated decnum tests
17:54 barney joined #parrot
17:55 cotto oh noes!  It's in Perl.
17:55 Theory joined #parrot
17:56 s1n_yapc joined #parrot
17:56 magnachef joined #parrot
17:56 ilia joined #parrot
17:58 cotto darbelo, lmk if you want help using pct to generate the tests.  You've been too low-maintenance lately.
18:01 darbelo I've been too low-performance too, I hacked the converter together in perl to get it out of the way and go back to the productive stuff.
18:04 darbelo I get side-tracked by shiny too often. I'm one of those guys who say "Trying to measure voltage with a hammer is stupid, you have to know the proper tool" and then start pounding nails with a volt-meter.
18:05 japhb Tene: so, any luck with the nvidia / parrot build?
18:05 bacek_ joined #parrot
18:07 moritz well, if it's a *heavy* and robust volt-meter ... ;-)
18:08 PerlJam fluke++
18:09 dalek rakudo: 0e0671a | moritz++ | t/spectest.data:
18:09 dalek rakudo: another passing integration test
18:09 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​e0671a13c6f2f21613eb18a458222febd4c7146
18:10 Tene japhb: eh?  last night kind of trailed off for me.
18:10 Tene I don't actually remember where we ended up.
18:16 nopaste "kid51" at 70.85.31.226 pasted "auto::gettext warning on Darwin/PPC in io_cleanups branch" (10 lines) at http://nopaste.snit.ch/17013
18:16 japhb Tene: heh.  Well, you were on the phone when I suggested that you install a couple packages on top of the base proprietary nvidia drivers.  In particular, here's what I said last night:
18:16 japhb OK, 185 is the current series, so you should be able to use xorg-x11-drv-nvidia-devel and xorg-x11-drv-nvidia-libs (if they work anything like the Debian equivalents, they're either virtual packages or release-tracking packages, either way they should work)
18:16 japhb I will say, though, that 185.18.14 is the release that refused to work on my poor laptop's card (an m7800)
18:16 purl i already had it that way, japhb.
18:16 purl i already had it that way, japhb.
18:17 * japhb throws purl a hush puppy
18:19 cotto joined #parrot
18:19 cotto the wireless here is really nice when I can connect
18:21 kid51 seen Whiteknight?
18:21 purl Whiteknight was last seen on #parrot 2 hours, 50 minutes and 39 seconds ago, saying: purl msg Infinoid I got that issue fixed and committed it to the io_cleanups branch. Builds now. Have a few interesting test failures if you have  a moment to look at them.
18:21 chromatic Whiteknight's driving back home now.
18:22 kid51 Oh, sorry to hear he had to leave early
18:22 cotto I think that was his original plan.
18:22 cotto either way, agreed
18:22 cotto Where's pmichaud?
18:22 purl pmichaud is http://www.pmichaud.com/ or "Patrick R. Michaud" <mailto:pmichaud@pobox.com> or in charge of toaster experiments
18:23 cotto < purl-- >
18:24 pmichaud I'm in the mst talk
18:25 pmichaud (rangos 1)
18:25 cotto ok.  I'll catch you later.  I'm playing with writing some functions in hash.pmc in nqp.
18:25 pmichaud excellent
18:26 cotto does nqp currently support three-part for loops?
18:26 pmichaud no, but we can add it if you need it.
18:26 pmichaud (it's always possible to convert a three-part for loop into a while loop, though)
18:27 chromatic It might be useful to see what NQP can do unchanged first.
18:29 cotto struct access?
18:30 pmichaud hmmm, struct access might be a challenge, yes.
18:30 cotto I'm just doing a line-by-line translation, preserving the original in comments.
18:30 pmichaud Although I wonder to what extent we really want to support struct access
18:30 allison joined #parrot
18:30 kid51 msg Whiteknight http://smolder.plusthree.com/app/pu​blic_projects/report_details/24046
18:30 purl Message for whiteknight stored.
18:31 cotto The architect appears.
18:31 cotto pmichaud, I don't see how we can do much without it.
18:31 cotto of course, this is pre-pre-pre-prototype
18:32 pmichaud wouldn't we be dealing with "attributes" more than specific structs?
18:34 chromatic I think so.
18:34 eternaleye joined #parrot
18:34 chromatic Mostly we just need to see what the syntax looks like for PMCL.
18:35 pmichaud I'm not saying we'll never have a need to do struct access... but one of the things we've been doing lately is to try to move PMCs away from direct struct access
18:35 cotto What about things like HashTable?
18:35 chromatic That's a good question.
18:36 nopaste "kid51" at 128.237.250.183 pasted "Test of nopaste.pl" (1 line) at http://nopaste.snit.ch/17014
18:36 Coke any parroteers going to EuroPython?
18:36 pmichaud I'm not.
18:37 allison ah, thanks to whoever put up the "no ps due to yapc" message
18:37 Coke whoops. yah, thanks. =-)
18:38 cotto allison, you're welcome.  In a perfect world someone would have thought of it last #ps.
18:38 NotFound Coke: maybe I can go for a few hours, not sure.
18:38 allison Coke: I didn't hear about EuroPython until I was already in the UK, so didn't manage to plan my latest trip around it
18:38 allison Coke: hopefully next year
18:38 allison NotFound: it would be good to have someone there, if it works out for you
18:39 davidfetter allison, how's your head?
18:39 NotFound Ah, no, I mixed conferences X-)
18:39 allison NotFound: ah well
18:39 cotto I have to say that it's considerably nicer writing PMCs in nqp, even if the syntax is experimental^2.
18:39 allison davidfetter: much clearer
18:39 davidfetter :)
18:40 allison davidfetter: I've only been working a few hours a day, but today I feel almost entirely myself again :)
18:40 davidfetter yay!!!
18:40 * davidfetter notes that jet lag is more hazardous than he'd originally imagined
18:40 allison heh, indeed :)
18:40 NotFound No, Birmingham is a little too far to me, sorry.
18:40 * davidfetter has been pretty continuously jet-lagged for the past year or so :P
18:41 nopaste "cotto" at 128.237.230.103 pasted "a couple VTABLE functions from hash.pmc rewritten in nqp" (105 lines) at http://nopaste.snit.ch/17015
18:41 allison davidfetter: well, beware of sunlit plate glass doors
18:41 davidfetter will do
18:42 Coke allison: I work with a guy named sumit; I just misread your send to great confusion.
18:42 cotto comments welcome.  Check XXX for things that are most questionable.
18:42 chromatic cotto, that'd be easier to read with the comments at the top, not inlined.
18:42 cotto I thought it'd be the opposite.
18:42 Coke cotto: s/J/j/
18:43 Coke is $iter.vtable.shift_string valid nqp?
18:43 ilia joined #parrot
18:43 chromatic I get lost trying to figure them out.
18:44 cotto Coke, there are likely many problems with that nopaste.
18:45 cotto When you get out, I'm in the registration room.
18:45 chromatic There should be snacks.
18:45 cotto There's cookies, fruit and drinks.
18:45 NotFound Magic cookies?
18:46 athomason joined #parrot
18:47 cotto they don't look magical, but maybe that's part of the magic
18:47 cotto Maybe the cookies are magic.  They're disappearing.
18:48 NotFound Amazing!
18:48 purl If you want to see amazing you should look at groditi_gone's collection of ear wax statues
18:51 nopaste "cotto" at 128.237.230.103 pasted "a couple VTABLE functions from hash.pmc rewritten in nqp, v2" (120 lines) at http://nopaste.snit.ch/17016
18:54 cotto and they're gone
18:56 cotto One advantage of hacking pmc2c (and pmcc) to generate destroy/mark and add PObj flag code to a PMC is that the nqp wouldn't have to do it.
18:56 cotto but I guess we'll need syntax for that for other reasons
18:57 Coke do we have any docs on NQP syntax?
18:57 Coke (nothing in compilers/nqp leaps out at me.)
18:57 Coke (aside from the grammar itself)
19:02 bobke joined #parrot
19:03 cotto Coke, this is part of the long-term plan for L1.  Whiteknight should be writing about it soon, but the basic plan is that we implement a prototype of L1 as dynops, make nqp powerful enough to do what our C code does and make PCT emit those dynops.
19:04 nopaste "coke" at 72.228.52.192 pasted "valid nqp?" (4 lines) at http://nopaste.snit.ch/17017
19:04 cotto Coke, it looks valid.  Does it asplode?
19:04 Coke ayup.
19:05 Coke error momentarily:
19:05 Coke No applicable methods.
19:05 Coke happens on the assignment.
19:05 cotto I guess it'd work if you split the declaration and assignment.
19:06 Coke hurm.
19:06 Coke nope.
19:07 nopaste "coke" at 72.228.52.192 pasted "valid nqp?" (13 lines) at http://nopaste.snit.ch/17018
19:07 Coke ah. it's just that it's borked in installed parrot.
19:08 cotto yeah.  It works fine here.
19:14 * Coke opens a ticket.
19:14 Coke so much for my just hatched plan of rewriting parts of tcl in NQP to simplify them. =-)
19:14 cotto Coke++ #breaking stuff so the rest of us don't have to
19:14 * Coke is running out of ways to break partcl.
19:15 * Coke guesses that if NQP isn't working in an installed parrot, PCT might not be either.
19:15 Coke I can't convert any more PMCs to PIR...
19:15 Coke I'm too slow but need a profiler...
19:16 Coke I tink switching from "compile the whole program and run it" to "compile the next command and run it" is probably the best bet.
19:16 dalek TT #785 created by coke++: "hello world" nqp fails when run with installed parrot
19:19 cotto That ticket looks familiar.
19:19 Coke I search for NQP before opening a ticket.
19:19 Coke (only int rac, though)
19:20 mikehh_ joined #parrot
19:22 ilia joined #parrot
19:23 magnachef joined #parrot
19:34 dalek parrot: r39746 | japhb++ | trunk/runtime/parrot/library/OpenGL/Math.pir:
19:34 dalek parrot: [OpenGL] Math.pir: Refactor elementwise binops again using macros of macros
19:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39746/
19:35 cotto joined #parrot
19:37 dalek parrot: r39747 | japhb++ | trunk (2 files):
19:37 dalek parrot: [OpenGL] Math: rename binop 'mult' to 'mul'
19:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39747/
19:41 chromatic joined #parrot
19:42 NotFound parrot insparrot/lib/1.3.0-devel/languages/nqp/nqp.pbc foo.nqp - hello world
19:43 NotFound Works for me
19:52 japhb pmichaud, Tene: do you have brain cells to spend on cross-HLL brainstorming?
19:59 mtk joined #parrot
20:00 mtk left #parrot
20:07 Theory joined #parrot
20:07 jan joined #parrot
20:10 Tene japhb: I do.
20:10 Tene japhb: do you?
20:10 purl hmmm... do you is it compulsory? ;)
20:10 japhb I do
20:11 japhb I think we need pmichaud as well, because I want to discuss the keyed assign problem
20:11 japhb foo[N] = baz
20:12 japhb Since Rakudo and I believe you said cardinal both start by trying to use postcircumfix:[] to get an lvalue for the LHS, and then assign to it.
20:12 japhb Which goes against the Parrot grain, shall we say.
20:12 Tene um... cardinal does it very very wrongly
20:13 Tene it just tries to call a method named '[]=' in the object
20:13 Tene I need to fix it.
20:13 japhb Well, arguably that's closer to the Parrot expectations than what Rakudo does.
20:13 Tene yes
20:14 Tene if I just makr :vtable{'set_pmc_keyed') on them, and switch to keyed assign, it would be fine.
20:14 japhb So do we raise the bar to expect foreign objects to support Rakudo's method, or teach Rakudo to understand set_pmc_keyed?
20:15 japhb s/Rakudo/PCT/, I guess
20:17 Tene I'd prefer the latter, I think.
20:17 Tene Need to think about it, though.
20:17 Tene It might cause some problems...
20:17 japhb Yeah, as do pmichaud and jonathon.
20:17 Tene my $b := @a[3];
20:18 japhb Do we want to support that on foreign objects?
20:18 japhb I guess it comes down to how much foreign objects are expected to behave like natives.
20:19 japhb "Can't bind to sub-objects of foreign objects" might be a passable rule, assuming we go down the restricted route.
20:19 Tene Sure.
20:19 Coke might be worth seeing how many other HLLs agree with perl6.
20:20 japhb How common is the bind operation in dynamic languages?  Does the equivalent exist in Ruby, Python, Tcl, et al.?
20:20 japhb Coke: we're on the same wavelength, I think.
20:20 Coke something like bind exists in tcl; you can alias a local variable to an outer scope's associative array element.
20:20 PerlJam japhb: perl5 does it!  :)
20:21 japhb Perl 5?  Never heard of it.  :-)
20:21 japhb OK, that's 3.
20:21 PerlJam japhb: scheme, haskell, lisp, etc. all do binding as well.
20:21 Andy_ joined #parrot
20:21 japhb I think this may be an operation we need to support generally, then
20:22 Coke hurm. I actually can't make my sample there work.
20:22 Coke so nevermind from my side, at least for now. =-)
20:23 japhb Tene, Coke: So how do we do this in PIR, in a general way?  Do we have existing ops/PMCs for this, or do we need to make new ones?
20:25 Coke for what, now.
20:25 Coke "bind" ?
20:25 japhb Coke: minimally, bind to element of collection.
20:25 japhb as an lvalue
20:26 Coke value = hash[key] - you now have a pmc value that you can pass around. if you change the value of that pmc, it should change the value returned by the next person that asks for the key. no?
20:26 Coke isn't that already bound?
20:26 japhb so that @a[3] = 5 can be decomposed into $temp := @a[3]; $temp = 5, even if @a is a foreign object
20:27 Coke what does "foreign object" have to do with it? aren't you using parrot's "get_pmc_keyed" vtable to get the element, regardless of what the actual type is?
20:27 japhb Hmmm.  That assumes that the only collections we pass around contain PMCs all the way down.
20:27 Coke (in which case it should return a PMC, which...)
20:27 japhb So we can't pass a FixedFloatArray, for example.
20:27 dalek parrot: r39748 | japhb++ | trunk (2 files):
20:27 dalek parrot: [OpenGL] Math: fill out vec-num binops using another super-macro; add another sample to math.pir; make math.pir output less confusing
20:27 Coke how on earth would you bind that? =-)
20:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39748/
20:28 Coke that would be like binding to a constant.. you need a PMC or binding doesn't make sense anyway.
20:28 japhb Coke: with some sort of proxy
20:28 Coke but then you have to upgrade the value in the original container with the proxy.
20:28 Coke or else the next person to ask for the value gets the original constant.
20:29 Coke at which point... use pmcs. No?
20:29 japhb Coke: no, because the proxy just passes assigns through.
20:29 Coke I can't say I like that plan.
20:30 japhb Here's the use case.  Let's say I've got a packed array of say 64K floats.  I don't want to expand that into 64K PMCs, just so I can assign into it.
20:30 Coke you don't have to. just assign into it. =-)
20:30 japhb Coke: from an HLL?
20:30 Tene HLL isn't at issue here.
20:31 Coke You can do that now:
20:31 Coke bigcontainerofPackedfloats[index] = newfloat.
20:31 japhb Yes, in PIR.  How do I do:
20:32 japhb @big_array = ForeignLibrary::Make_me_a_big_packed_Array.  @big_array[5] = 27;
20:32 Tene Coke: rakudo is translating @a[0]='foo'; into 'postcircumfix:[ ]'(0,'foo')
20:32 dalek TT #782 closed by moritz++: src/pmc/env.t confuses compiler specific and platform specific macros
20:32 japhb In that latter statement, Rakudo currently wants to do it in two steps, binding a temp first.
20:32 Coke japhb: in pir: big_array = somethingThatReturnsArray()
20:33 Coke big_array[5] =27
20:33 japhb Coke: I think I'm being confusing.  I mean: "Yes, I know it works in pure PIR.  How do you get a HLL like Rakudo to correctly handle a packed array handed up from a PIR library?"
20:34 Tene Coke: I lied.  Rakudo is translating it into: $P0 = 'postcircumfix:[ ]'(@*a, 0); $P0 = 'foo';
20:34 Coke japhb: you make it generate the appropriate pir.
20:34 Coke Tene: if perl6 wants to assign to things that aren't PMCs, it's going to have to be smarter.
20:35 japhb Coke: Yes.  Er.  And that's what I want to have happen.  But we need to make that work with the postcircumfix:[] thing that Tene just alluded to.
20:35 Coke japhb: it's all just PIR (or c or bytecode) under the covers...
20:35 cotto joined #parrot
20:35 japhb Coke: exactly
20:35 Tene Coke: so what should "$a := @b[0]" translate into that will work with a fixedfloatarray?
20:35 japhb Coke: now -- how does Rakudo know what PIR to write when it doesn't know the type of the array until runtime?
20:36 Coke japhb: as I recall, allison's take on that was "explode"
20:36 japhb LOL
20:36 japhb allison: bad architect, no biscuit.  :-)
20:37 Coke japhb: try it and catch it when it throws an exception, falling back to the slow "create a proxy" method?
20:38 japhb Well, that's at least better than exploding
20:38 japhb Seems a heck of a hit, though.
20:38 Coke or you could /always/ make the proxy.
20:38 moritz how fast are exceptions, compared to other control flow?
20:38 japhb Perhaps collections could have a "bindable" attribute/property/whatever that can be detected ....
20:39 Coke moritz: they're all slow.
20:39 japhb Then I'd like to do something else.
20:39 japhb Working with packed arrays should not be Slow By Design
20:39 Coke If you avoid everything in parrot that's slow NOW, you're never going to do anything.
20:39 Coke japhb: I'm not saying they're slow by design. I'm saying everything is slow in the current implementation.
20:40 japhb Ah.
20:40 Coke doing what's fast in parrot /today/ is a recipe for cleaning up your code later.
20:40 moritz CPS should make them fast, in theory, I think
20:40 Coke moritz: parrot is SUPER HELLA FAST in theory.
20:40 moritz Coke: ;-)
20:42 Coke tene, japhb : so, I have no clue what the /right/ way to solve your problem is. Sorry to have distracted you. =-)
20:42 japhb np, worth discussing
20:43 cotto Where are all the Parrot hackers at yapc?
20:45 Coke japhb: I think a ContainerProxyKey has some merit, though.
20:45 Coke KeyProxy?
20:46 japhb Coke: nodnod.  I was just ruminating on the implementation.
20:46 Coke something that is like a Float, but overrides the Set/Get to coordinate with its host PMC.
20:46 Coke I think once you have that, though, the HLL is responsible for instantiating it when it needs it.
20:46 japhb ... but the HLL needs some way to know if it needs it.
20:47 Coke and there are 3 ways: check the type of the container ahead of time; try it and deal with any exceptions, or always use it.
20:47 japhb And I'd like to not force the HLL to do a test every time.
20:47 Coke (do a test) why not?
20:47 Coke (you could cache the results for a given PMC.)
20:48 Coke s/PMC/Container/
20:48 japhb Because that's slow by design.  A better way might be to have a variant get_pmc_keyed that will return the PMC inside a PMC collection, or return a proxy from a packed collection.
20:48 japhb I thought of the cache,
20:49 Coke you don't know how long the test takes or how often it's going to be invoked. How can you say "slow by design"?
20:49 Coke if you have a variant get_pmc_keyed, then you need to subclass the core packed type anyway.
20:49 japhb but we can't do the cache directly, because the HLL in theory could loop over the whole array making unique binds.
20:49 Coke (otherwise it won't behave like the core type.)
20:49 Coke You could. why would you do that?
20:49 NotFound TT #785 works for me
20:50 japhb I'm saying that perhaps all core collection types ought to have this extra vtable.
20:50 Coke if you're going to loop over the whole array anyway, loop over the array.
20:50 japhb Coke: not that it's a good idea.  We just need to do the right thing, and not get crazy slow.
20:50 PerlJam "core collection types"?
20:50 Coke it's ok to get crazy slow if your users are doing something stupid. =-)
20:51 japhb And I said testing on every index was slow by design because it makes it slightly slower to do the index/bind operation on PMC arrays, which will be most of the uses, to benefit packed arrays, which will be rare.
20:51 Coke I could see a proposal that perhaps changed get_pmc_keyed on the non-pmc collection types to support a containerProxyKey.
20:51 Coke is checking the type of a pmc container slow?
20:52 japhb Coke: it's not that the check is slow.  It's that there are ways to do it that don't do the check at all.
20:52 japhb And I think your idea of changing the non-pmc collection types to DTRT is close to what I am looking for.
20:52 Coke DTJT.
20:52 Coke (japhb)
20:53 japhb I say DTRT because currently in the context of an HLL, they DTWT.  :-)
20:53 Coke of course, that might mean that folks that want to just get a PMC value to play with have to do do extra work.
20:54 Coke s/HLL/Perl 6/
20:55 japhb We just said that most HLLs expect to be able to bind to array elements.  Rakudo just happens to be the one doing it right now.
20:55 Coke "oh, I'll clone the pmc I got so I don't modify any data." - set the clone. clone of the proxy happily goes back and resets the value in the container.
20:55 Coke so then you have to do the check to find out if it that use case is safe... etc.
20:56 japhb ... which is why I suggested that instead of modifying the current op/vtable, we add one for the lvalue bind case.
20:56 japhb Because you want both behaviors.
20:56 japhb indexing to get rvalue and indexing to get lvalue are fundamentally different.
20:56 cotto I was feeling enthusiastic about getting pmcc working before the end of yapc until just now when I looked at METHOD and MULTI rewriting.
20:57 Coke japhb: there, concensus. =-)
20:58 japhb :-)
20:59 magnachef joined #parrot
21:00 ilia joined #parrot
21:03 ilia_ joined #parrot
21:09 Coke japhb: looks like fixedfloatarray is currently creating a PMC and returning it when asked, so that's your rvalue semantics (and not an error to be trapped anyway.); I would expect that you would need to add 3 vtables for: get_pmc_keyed{_int,_str,}_lvalue ; you might also want to investigate slice
21:10 japhb "investigate slice"?  Meaning, figure out how to proxy that?
21:11 Coke if you want an lvalue slice.
21:11 dalek decnum-dynpmcs: r88 | darbelo++ | trunk/ (5 files):
21:11 dalek decnum-dynpmcs: Fix "Inf" handling in the converter script.
21:11 dalek decnum-dynpmcs: Remove tests that perform invalid operations. We have enough failures without
21:11 dalek decnum-dynpmcs: doing it on purpose.
21:11 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=88
21:11 japhb Coke: gotcha
21:13 japhb I know next to nothing about how to write PMC vtables.  Given various projects currently in play in the branches, is it worth learning the current method?  Or should I wait for one or more projects to merge?  (Assuming they plan to merge "soonish")
21:16 darbelo japhb: The current way of writing PMC VTABLEs is unlikely to go away "soonish". You should be good for, at the very least, a deprecation cylce. It's likely to take longer than that though.
21:16 japhb OK
21:17 japhb All right, what's the best doc to get started with?
21:17 japhb (Assuming Tene++ doesn't beat me to the punch and JFDI)
21:19 darbelo docs/pmc.pod has the basics and there's also some stuff in docs/pmc/ on the parrot tree.
21:19 japhb OK.
21:19 japhb Thanks, darbelo++
21:20 darbelo Also look at how other PMCs do what they do, just don't trust 'em to be doing it right ;)
21:20 japhb *chuckle*  Somehow, I was already thinking along those lines.  ;-)
21:21 * japhb goes back to the "mental break" activity of  writing OpenGL/Math.pir
21:24 skids joined #parrot
21:27 GeJ Good morning everyone
21:27 japhb o/
21:32 dalek parrot: r39749 | japhb++ | trunk (2 files):
21:32 dalek parrot: [OpenGL] Math.pir: more compact dump output; math.pir: improve output spacing
21:32 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39749/
21:34 japhb Huh, that's interesting. dalek ate the __ before 'dump'
21:39 * rg would guess trac ate it (underline the empty string)
21:39 japhb :-/
21:41 gryphon_ joined #parrot
21:42 darbelo I think dalek watches the RSS feed and reports based on that. I'd check there if I wanted to be sure of who ate what.
21:43 * moritz refrains from adding a lolcat comment ending in "EATED IT"
21:43 japhb moritz: REFRAIN FAIL
21:43 japhb ;-)
21:43 NotFound ABSTAIN FROM REFRAINING
21:44 japhb darbelo: where would I go on trac.parrot.org to see the RSS Feed?
21:44 NotFound One day I'll write an INTERCAL parrot compiler.
21:44 darbelo I'm looking at "https://trac.parrot.org/parrot/log/?limit​=50&amp;mode=stop_on_copy&amp;format=rss" and it doesn't have the __
21:45 japhb Ah, I think I found it
21:45 japhb yup, trac--
21:45 bacek_ joined #parrot
21:45 darbelo and https://trac.parrot.org/parrot/log/ has an underline running from dump to the "..." at the end of the line.
21:46 darbelo TRAC EATED UR UNDERSCOER
22:01 bacek_ joined #parrot
22:02 bacek_ good morning
22:02 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
22:03 * bacek_ read irclog
22:03 bacek_ hooray! NQP FTW!
22:04 cotto joined #parrot
22:05 bacek_ cotto++ # C is dead, long live NQP
22:05 cotto not dead, but greatly diminished
22:06 cotto and if we do a good job replacing it with nqp, I won't miss it either
22:06 bacek_ :)
22:06 NotFound I'll say it one more time: TT #785 does not fail for me.
22:06 bacek_ We need static typing in NQP.
22:07 bacek_ And reduced support for MULTIs.
22:08 bacek_ Or we can use it directly from pmcc.
22:08 cotto bacek_, reduced?
22:09 bacek_ Simplified. Not full Perl6 multis.
22:09 eternaleye joined #parrot
22:09 cotto Oh.  Of course not.
22:09 cotto I thought you meant reduced from where it currently is.
22:10 bacek_ btw, "rule body { NQP:::Grammar::statement_block }" in pmc probably will work.
22:10 bacek_ Currently there is no multis in NQP :)
22:10 cotto exactly
22:11 bacek_ exactly "multis" or exaclty "rule"?
22:12 bacek_ "rule body { <NQP::Grammar::statement_block> }"
22:12 cotto multis
22:15 Austin_Hastings joined #parrot
22:20 dalek decnum-dynpmcs: r89 | darbelo++ | trunk/ (5 files):
22:20 dalek decnum-dynpmcs: Fixup some regexes in decTest2pir.
22:20 dalek decnum-dynpmcs: Regenerate the test files with the fix in place.
22:21 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=89
22:22 JC1 joined #parrot
22:30 dalek parrot: r39750 | japhb++ | trunk (2 files):
22:30 dalek parrot: [OpenGL] Math: document and show alternate instantiation syntax
22:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39750/
22:33 rg1 joined #parrot
23:11 patspam joined #parrot
23:17 japhb Tene: I have a PIR Module OpenGL/Math.pir, which I use from Rakudo as: "use OpenGL::Math:from<parrot>;".  OpenGL/Math.pir defines various classes within the OpenGL::Math:: namespace, such as OpenGL::Math::Vec4.  I can't seem to find a syntax that allows me to instantiate an OpenGL::Math::Vec4 directly from Rakudo.  Depending on the syntax I use, I end up with "Malformed declaration" (for 'my OpenGL::Math::Vec4 $foo .= new;') to "invoke() n
23:17 japhb ot implemented in class 'NameSpace'" (most of the other variations I've tried).  Any thoughts?
23:17 bacek_ OpenGL::Math::Vec4.new?
23:18 japhb bacek: I think I tried that one, but let me check again.
23:18 japhb yup, the invoke() error above
23:18 dalek tracwiki: v5 | Austin_Hastings++ | Yapc10Bof
23:18 dalek tracwiki: Moved photos inline, w/ OCR
23:18 dalek tracwiki: https://trac.parrot.org/parrot/wiki/​Yapc10Bof?version=5&amp;action=diff
23:23 bacek_ japhb: no idea...
23:23 japhb Yeah, I'm drawing a blank myself.
23:23 japhb Perhaps I need some inline PIR for now.
23:24 Austin_Hastings Did you 'register' it?
23:24 Austin_Hastings (I'm assuming you've got lots of these, and this is probably a no-brainer, but ...)
23:24 japhb Austin_Hastings: hmmm?
23:25 japhb Given that I don't know what you're talking about, I probably missed something key.  :-)
23:25 Austin_Hastings Did you write this?
23:25 Austin_Hastings (The OpenGL/Math/whatever stuff?)
23:25 japhb YEs.
23:26 japhb I've been testing it so far just using PIR callers.
23:26 Austin_Hastings Okay. There's a call you have to make to hook a pir class into the perl6 object model. It's usually in the initload code,
23:26 japhb But now I'm trying to use it from Rakudo,
23:27 japhb like I already use OpenGL (the bindings for which I also wrote), and works swimmingly.  But OpenGL does not have any sub-namespaces ....
23:27 Austin_Hastings and you get a p6meta and eventually call a 'register' method with your class and optionally parent classes, attributes, and what-not.
23:27 japhb Ah!  Tene's cross-HLL loader must be doing this automatically for the exact classname you 'use' ....
23:27 Austin_Hastings Haven't seen it. Maybe?
23:28 Austin_Hastings (But I kind of expect not...)
23:28 japhb Or maybe Rakudo does by itself, hmmm.
23:29 japhb Austin_Hastings: OK, where do I look for sample code?
23:29 Austin_Hastings I'm looking for some now. bide
23:29 japhb thx
23:30 Austin_Hastings Try $PARROT/runtime/parrot/lib​rary/PGE/Perl6Grammar.pir
23:30 Austin_Hastings Search for p6meta.'new_class'
23:31 magnachef joined #parrot
23:31 Austin_Hastings That's "how you create a p6 class on purpose"
23:32 japhb Hmmmm.  This is going to be slightly different for every HLL that wants to load the module, isn't it?
23:33 Austin_Hastings Not really.
23:33 Austin_Hastings Anyway, then look at the "register" method in P6object.pir (in runtime/library)
23:33 Austin_Hastings That's how you hook a non-P6 class into the P6 object model.
23:33 japhb If I register via P6metaclass, am I really registering with PCT's MOP?  So any PCT language will recognize the new class?
23:34 Austin_Hastings You're registering with P6's MOP, which PCT also uses.
23:34 Austin_Hastings (I think)
23:35 Austin_Hastings Anyhow, if you DON'T do this, then you probably have a class and a namespace, but you won't have a global symbol defined in the OpenGL::Math namespace.
23:35 japhb OK.  So that just leaves Tcl out in the cold right now
23:35 Austin_Hastings Can you give me a pointer to "Tene's cross-HLL loader" ?
23:36 japhb It's what makes Rakudo's 'use Foo:from<parrot>' work (and Cardinal as well).  Tene did a journal entry about it, lemme see if I can find it.
23:37 japhb Oh nice, my DNS server is deciding to be a pest
23:37 Austin_Hastings LOL
23:37 Limbic_Region joined #parrot
23:38 Austin_Hastings I just got home from PVMW/YAPC, and plugging my laptop into the docking station caused my X server to go into "only if you're in the top left corner" mode.
23:41 japhb bugger all, looks like it's not coming back from a reboot.
23:43 japhb afk for a few -- Austin_Hastings, I'm pretty sure if you go searching for Tene's blog / use.perl journal, you'll find the article I'm talking about.
23:44 Austin_Hastings Is it under "Tene" or some other name
23:44 Austin_Hastings ??
23:44 japhb Tene?
23:44 purl hmmm... Tene is Stephen Weeks or a madman
23:44 Austin_Hastings Thanks
23:46 Whiteknight joined #parrot
23:46 Austin_Hastings Howdy, WhiteKnight
23:47 Whiteknight howdy
23:47 Infinoid Whiteknight: pong
23:48 Whiteknight hiya infinoid
23:48 Whiteknight I actually don't remember why I pinged you. did I msg you?
23:48 Infinoid yeah, about your checkin and some test failures
23:50 Austin_Hastings purl msg?
23:50 purl msg is Monosodium Glutamate, accelerates cooking of chinese food or a flavor enhancer, to make shitty stuff taste better, increase thirst, and desire to eat more.  the perfect food additive :> or Madison Square Garden or in *everything*
23:50 Whiteknight yeah, I had a few really weird failures, although they look mostly related
23:50 Infinoid testing now
23:50 Infinoid purl, messages help?
23:50 purl To leave a message, say in channel or privmsg purl "msg <nickname> MESSAGE FOR J00".  To read your messages, privmsg purl "messages".  To erase your messages, privmsg purl "messages erase". or Delivery Not Guaranteed!
23:50 Whiteknight awesome, thanks!
23:50 Whiteknight msg is also "msg <username> <message"
23:50 purl Message for is stored.
23:50 Whiteknight damnit
23:50 Infinoid purl, msg is also see messages help
23:50 purl Message for is stored.
23:50 Infinoid lame.
23:50 Whiteknight weak
23:51 is .
23:51 is [19:51] <purl> You have 6 messages waiting.
23:51 Austin_Hastings msg japhb (Re: cross-HLL load) Apparently the nopaste he put his API in has expired. But from what I see, it does look like a mod for every compiler. I'll have to chase it down from one of the compiler source trees. Thanks for pointing me at it.
23:51 purl Message for japhb stored.
23:51 Whiteknight oh awesome, kid51 already did a smolder in the branch: http://smolder.plusthree.com/app/pu​blic_projects/report_details/24046
23:51 Whiteknight so that should give you an idea about what is broken
23:55 Infinoid I see broken packfiles (due to PBC_COMPAT yet again) and some failures from t/pmc/io.t
23:56 Infinoid looks pretty much the same as kid51's
23:59 Infinoid dinner time, I promise I'll look at the failures after

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

Parrot | source cross referenced