Parrot 1.3.0 "Andean Swift" released | parrot.org | YAPC10 Parrot Implementers BOF: Dowd Room, 2nd floor, 5:00 pm
Set by moderator on 22 June 2009.
bacek_ time to go to $dayjob. 00:01
Infinoid msg cotto Great group photo! needs labels tho, who is who? :) 00:07
purl Message for cotto stored.
00:18 Limbic_Region joined
Infinoid I think top row #2 is jkeenan/kid51 00:22
and I think bottom row #5 is jhorwitz
Coke yes. 00:28
oddly, top #1 looks a bit like me.
dalek rrot: r39729 | coke++ | branches/context_pmc (5 files):
Remove Parrot_context_ref_trace & CTX_LEAK_DEBUG
00:29 s1n_yapc joined
Infinoid The only parroteer I've met in person is particle, and that was unfortunately very brief 00:29
00:42 japhb joined 00:48 wayland76 joined
dalek rrot: r39730 | coke++ | branches/context_pmc (4 files):
Add (unused) Context PMC
 00:51
mikehh bottom row #1 Bruce Grey/Util I think #2? 00:53
Infinoid ah, cool 00:54
mikehh is that cotto (or did he just take the picture?) 00:55
Coke I think that's cotto, yes.
mikehh sorry Gray 00:56
Infinoid Coke: So is that you, or just a doppelganger? 00:58
dalek tracwiki: v2 | bacek++ | Yapc10Bof 01:01
tracwiki: Start describing group photo based on IRC discussions :)
tracwiki: trac.parrot.org/parrot/wiki/Yapc10...ction=diff
mikehh So that gives us -> Coke, kid51, chromatic, whiteknight / Util, cotto, pmichaud, particle, jhorwitz
bacek (someone have to finish it)
Coke mikehh: no, that's not me.
it just looks vaguely like me.
Infinoid s/Coke/unCoke/ 01:02
dalek tracwiki: v3 | Infinoid++ | Yapc10Bof 01:07
tracwiki: I think these are right... apologies if I'm wrong!
tracwiki: trac.parrot.org/parrot/wiki/Yapc10...ction=diff
Infinoid Free karma for whoever gets the other two :) 01:08
01:17 Maddingu1 joined, GeJ joined 01:38 s1n_yapc joined 01:44 guru joined
dalek TT #502 reopened by coke++: [PATCH] build on OpenBSD/ppc 01:46
01:56 wayland76 joined, amuck joined 01:58 amuck__ joined 02:10 amuck joined 02:21 amuck joined 02:53 rg joined 02:54 amuck joined 02:56 guru left 02:58 cotto joined
cotto wb me 02:58
darbelo++ #generated tests 03:00
darbelo++ #generated tests that fail
darbelo++ #generated tests that fail, but will eventually pass
03:01 wayland76 joined
cotto Infinoid, the pictures are labeled 03:03
dalek tracwiki: v4 | cotto++ | Yapc10Bof 03:05
tracwiki: trac.parrot.org/parrot/wiki/Yapc10...ction=diff
TT #734 closed by jkeenan++: Branch cleanup: pdd30_install 03:19
nopaste "tene" at 24.10.252.130 pasted "gl-devel libs for japhb++" (7 lines) at nopaste.snit.ch/17005 03:22
03:24 amuck joined
dalek rrot: r39731 | cotto++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] aggregate a couple adjacent heredocs
 04:01
04:07 s1n_yapc joined 04:25 Theory joined
dalek rrot: r39732 | cotto++ | branches/pmc_pct/compilers/pmcc/src/parser/grammar.pg:
[pmcc] get a nice increase in parsing speed by capturing more than once character at a time from C function bodies
 04:41
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:43
dalek rrot: r39733 | cotto++ | branches/pmc_pct/compilers/pmcc/src/emitter (2 files):
[pmcc] emit more of class_init and some (probably broken) VTABLE function bodies
 04:44
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:47
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
lemme change that
dalek rrot: r39734 | cotto++ | branches/pmc_pct/compilers/pmcc/src/parser (2 files):
[pmcc] parse some more PMC traits
 04:54
04:55 jq joined
Tene japhb: okay, I got my system in a situation where Parrot's GL works. 05:05
japhb: I've got X running under nouveau.
glxinfo reports direct rendering: No and OpenGL renderer string: Software Rasterizer
05:07 flh joined
japhb Interesting 05:27
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
Tene: What method did you use to install the nvidia proprietary packages?
05:41 mikehh joined 06:03 uniejo joined
Tene japhb: rpmfusion 06:05
what did you use?
bacek cotto: are you sure that r39732 didn't break t/06-body.t? 06:08
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
indings then ...
Tene: does RPMFusion have -devel packages for the nVidia drivers?
Tene um, dunno 06:11
nopaste "tene" at 24.10.252.130 pasted "yum search nvidia for japhb++" (66 lines) at nopaste.snit.ch/17006
japhb nVidia: Your "unified driver" is failing to remain unified. By any stretch of the imagination. 06:13
Tene which should I install? 06:14
japhb It looks like "xorg-x11-drv-nvidia-devel" 06:15
Assuming you are using "xorg-x11-drv-nvidia-libs" along with the kmod
nopaste "tene" at 24.10.252.130 pasted "rpm -qa '*nvidia*' for japhb++" (12 lines) at nopaste.snit.ch/17007 06:18
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:22
I will say, though, that 185.18.14 is the release that refused to work on my poor laptop's card (an m7800) 06:23
Tene: Any luck with the installs? 06:37
Tene afk phone 06:38
japhb k
06:48 clunker3 joined 06:59 magnachef joined 07:02 iblechbot joined 07:49 barney joined 08:28 donaldh joined 08:31 masak joined 08:43 clinton joined 09:10 wayland76 joined 09:18 bacek_ joined
bacek_ o hai... 09:24
Infinoid good morning 09:58
purl And good moroning to you, Infinoid.
bacek_ good moroning, Infinoid
Infinoid purl is always so negative 09:59
bacek_ Almost all girls are same. 10:00
dalek rrot: r39735 | bacek++ | branches/tt761_keys_revamp/lib/Parrot/Pmc2c/Method.pm:
[pmc2c] Fix handling trailing spaces in "void" MULTIs.
 10:09
rrot: r39736 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
[pmc] Migrate Hash.set_integer_keyed(_something)? to "brave new world".

Use hash_key_from_TYPE and hash_value_from_TYPE instead of blind cast to void*.		 10:12
rrot: r39737 | Infinoid++ | trunk/compilers/imcc/pbc.c:
[cage] c_parens.t fix.
bacek_ discovered that he has registered at identi.ca more than year ago... 10:15
10:18 mikehh joined
mikehh infinoid: was just about to paste a patch, but you already fixed it 10:19
manifest also needs regenerating
nopaste "Infinoid" at 65.18.171.17 pasted "Serious I/O breakage" (20 lines) at nopaste.snit.ch/17009
Infinoid I got that joyful behavior after turning line buffering on for stdout 10:21
Note that the handles in question have nothing to do with stdout.
mikehh codetest, manifest_tests FAIL, All others PASS make fulltest r39734 10:22
Ubuntu 9.04 i386
bacek_ Infinoid: looks like issue that Whiteknight described couple of days ago.
Incorrect order of destruction
Infinoid bacek_: What, between FileHandle and Handle? hmm, could be 10:23
mikehh: If you have a manifest patch, I'll apply it. I'm using git here, so the manifest scripts fail
I particularly love the way it tries to flush stdin 10:24
bacek_ I'm not sure that it is stdin. It's in forked child afaik 10:25
nopaste "infinoid" at 65.18.171.17 pasted "[patch] line/block buffering for stdout" (62 lines) at nopaste.snit.ch/17010 10:26
Infinoid src/io/unix.c assumes it is stdin
mikehh # Failed test 'No need to regenerate MANIFEST.SKIP'
Infinoid if it were an output handle, the kernel wouldn't have returned EINVAL
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 nopaste.snit.ch/17010 and nopaste.snit.ch/17009. You saw this a couple of days ago, how did you fix it?
purl Message for whiteknight stored.
mikehh infinoid: I see the mystery Coke lookalike was Austin_Hastings 10:29
somewhat obscured by Util 10:30
Infinoid cool
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:32
bacek_ It definitely should 10:38
10:42 wayland76 joined 11:00 JC1 joined 11:05 guru joined
dalek rrot: r39738 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
[pmc] Implement hash_value_to_number. Slightly refactor get_number_keyed_TYPE to use it.
 11:14
rrot: r39739 | bacek++ | branches/tt761_keys_revamp/src/pmc/hash.pmc:
[pmc] Implement (get|set)_value_type in Hash.
bacek_ *incoming*
dalek: hey. One more commit! 11:18
:)
dalek rrot: r39740 | bacek++ | branches/tt761_keys_revamp/t/pmc/hash.t:
[t] Add tests for storing different value-type in Hash.
Infinoid racey bot 11:19
bacek_ good bot :)
purl :)
bacek_ purl: not you!!!
purl Whatever.
Infinoid <purl--> # dork 11:21
11:21 donaldh joined
bacek_ start loving Hash implementation in Parrot. 11:21
It was made by some very clever guy!
O wait...
11:22 szabgab joined
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...
Infinoid: time to use power of gdb and check who call fsync on closed handle. 11:24
11:26 s1n_yapc joined
Infinoid Working on that. There are actually a few issues here 11:26
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:27
bacek_ oh shi... 11:28
bacek_ passing famous book by Stevens to Infinoid 11:30
11:32 guru left
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
But that's a separate patch
11:33 burmas joined
Infinoid (and currently just vaporware) 11:34
11:35 davidfetter joined
bacek_ It's... not easiest thing in the world. 11:38
Infinoid the only difficult part I see is differentiating recursive exceptions from serial exceptions 11:40
because we're calling these things as continuations, I can't just wait for it to return 11:41
or maybe I can. But it means I need to understand PCC better than I currently do :)
11:44 Whiteknight joined
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 :)
bacek_ "ex_throw_from_c" doesn't unwind C stack.
Whiteknight yeah, I have that "I'm an idiot" realization multiple times per day
...and there's purl!
bacek_ second: there is no stack in Parrot :_
Whiteknight bacek_: there is 1 stack left
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
Infinoid Whiteknight: We're talking about detecting recursive exceptions and implementing a failsafe double-fault handler
bacek_ Whiteknight: I'm from future :)
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
That's happened a few other times, so I was thinking it would be nice to be a little smarter about that
But it isn't easy :)
11:49 jdv79_ joined
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
Infinoid yes, preferably with a nasty looking message that tells you where to fix it 11:51
Whiteknight very very nasty messages
Parrot: exception b0rked. STFU and fix it!
Infinoid So the problem I have messing with PIO is, the exception message emission uses PIO 11:52
but a similar case can probably happen with broken encoding plugins
I'd really love a failsafe handler that just falls back on stderr, prints the message if it can, and CANNOT fail
that means... does not call PCC, does not allocate memory, nothing fancy at all 11:53
all of that is fine. But how do you detect when the previous exception handler has exited? 11:54
I want to disambiguate between recursive exceptions and serial exceptions
s/exited/returned/ 11:55
bacek_ Infinoid: welcome to C++ world! :)
All this issues were solved many years ago... 11:56
Whiteknight Infinoid: it is quite a problem
...in a galaxy far far away...
Infinoid I didn't think C++ used continuations, so I'm not quite sure they solved this 11:57
Ok, I'm clueless. I need to understand how parrot calls exceptions better, and then I will revisit this
Whiteknight yeah, we could all use a better understanding of it 11:59
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
Infinoid Do you happen to know if FileHandles buffer by default? Because stdout doesn't 12:01
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
I have no idea about the default settings, I still need some research
that patch I sent you for io_cleanups is very out of date now, I would need to send an update
brb, breakfast
Infinoid oki
back later & 12:06
12:08 jdv79 joined 12:20 Whiteknight joined 12:25 skids joined 12:36 Whiteknight joined 12:37 cotto joined
cotto bacek, ping 12:37
bacek_ cotto: pong
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:38
Having files parse in .5s instead of 5s is a nice change. 12:39
bacek_ I know... But it's failing badly... 12:40
Ok. Our current approach is wrong.
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.
bacek_, how so? 12:41
bacek_ But re-implement pmc2c approach is wrong either.
afk_coke yamp?
Coke yamp?
cotto The code does seem a little convoluted.
bacek_ cotto: look, we don't have to parse current PMCs. 12:43
We have to parse some L1HIGH language.
12:44 Whiteknight joined
bacek_ From which we can emit C code semantically equivalent to current PMCs pseudo-C code. 12:44
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
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.
bacek_ than just use bunch of regexes stolen from pmc2c to replace stuff in. 12:46
stuff in bodies.
12:47 whoppix joined
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
erm...
steal
cotto Is that different from the substr opcode?
masak yes. 12:48
bacek_ "substr" do plain string substitution
masak substr does substrings.
subst does substitutions.
bacek_ "subst" - regexp based
cotto sounds handy
very handy
bacek_ implemented by masak. O wait.
masak well, parts of it. 12:49
purl parts of it are in English
masak purl: parts of you are very annoying.
purl OK, masak.
12:49 s1n_yapc joined
bacek_ masak: it's good part. And probably will be enough for pmcc. 12:50
masak \\o/ 12:51
what's pmcc again? :) 12:52
bacek_ PMC compiler written in PCT 12:53
like... Baron Munhgauzen pulling himself 12:54
cotto bacek++
12:54 cognominal joined
masak ooh, nice. 12:56
so the first time you compile that, you need something to bootstrap?
bacek_ masak: indeed. But we can commit "previously generated C files" to svn. Similar to bison/flex files 12:57
masak ah. nice.
masak likes bootstrapping in all forms 12:58
bacek_ thinking about using STD.pm in "bootstrapped rakudo" :)
pmichaud Good morning #parrot 12:59
bacek_ good mor^ localtime(), pmichaud
13:02 gryphon joined
mikehh snap - how's YAPC 10 etc goin' 13:08
13:10 wayland76 joined
wayland76 Here I am on #parrot 13:10
pmichaud suggested we continue a conversation about both Rakudo and Parrot´s install processes here.
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
I agree with that to some extent
But I don't want HLLs to be limited to using Parrot's build tools
wayland76 No, of course not
I´m just too lazy to write my own :)
pmichaud for example, I have strong disagreements with the structure of gen_makefile (and the Makefiles it generates)
wayland76 All I wanted was the MANIFEST part
pmichaud I have lesser disagreements there :-) 13:12
wayland76 Yeah, I agree
But did you notice the recent refactor that kid51 and I did?
(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
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.
mikehh pmichaud: where would you like gen_makefile to go?
pmichaud mikehh: I'd like us to supply a prototype gen_makefile that HLL implementors can then customize
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
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 ? :)
pmichaud wayland76: how do you mean?
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:16
pmichaud how much freedom is there in "put the files wherever you've specified"? 13:17
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
And they do things like pass in data structures that contain transformation functions that get run on the path
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¨)
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
pmichaud okay.
wayland76 It´s needed for packaging
pmichaud sure.
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 :)
pmichaud okay.
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
pmichaud that's not really what I was saying 13:23
my complaint is that the build tree doesn't look _anything_ like the install tree
wayland76 I'll try to remember to test tomorrow morning whether building the Rakudo RPM against an installed Parrot RPM works for me
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
for example
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 :)
pmichaud Developers (and people who are using more recent copies of rakudo) want to be able to test Rakudo without installing it :-)
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)?
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.
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
(from a command line)
wayland76 how about a command line "parrot_invoke" tool that finds things for you :)
moritz pmichaud: ok
pmichaud Perhaps that means we need a fakecutable NQP. I'm fine with that.
We would also want/need a fakecutable Perl6Grammar.pbc .
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?
pmichaud ...scale well?
moritz adding a fake executable for everything that we need from rakduo
pmichaud This wouldn't be just for rakudo
wayland76 parrot_invoke Perl6Grammar.pbc
pmichaud it's needed for every language that wants to create a compiler for Parrot 13:30
wayland76: that would be great, *if* I didn't have to do
parrot_invoke (some_path_that_frequently_changes)/Perl6Grammar.pbc
Coke I say again, I don't think installing parrot is a hardship.
pmichaud I'm not claiming it is.
wayland76 Maybe I should go to bed -- I'm out of my depth and not helping :)
pmichaud: Yeah, I'm claiming that parrot_invoke should sort out the paths for you 13:31
moritz (and on demand tell you the path it sorted out) 13:32
wayland76 That would be nice too
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")
our "best effort" at that thus far is fakecutables.
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:34
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.
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.
wayland76 Actually, paths could help with this, maybe
Coke (hurm. maybe not all; but certainly nqp) 13:36
pmichaud I'd primarily want nqp and Perl6Grammar
since thsoe are the compilers that are used in building other hll compilers
wayland76 ie. at the command line: PATH=compilers/nqp:lib/parrot/1.3.0/languages/nqp nqp.pbc
pmichaud ugh 13:37
wayland76 Yeah, ugh :)
13:37 ilia joined
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 :) )
pmichaud (within the parrot tree) 13:38
and then "make install" really just does the equivalent of copying that local install image to its ultimate location
wayland76 Did kid51 mention my idea of creating METAFESTs ?
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.
Coke: it was more brainstorming of ideas than making decisions
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.
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.)
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. =-)
pmichaud correct.
Coke thanks for keeping us in mind. Appreciate it.
NotFound pmichaud: please don't forget TT #772 13:45
13:51 Andy_ joined
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:52
Coke it seems saner to have both places be the same. 13:53
have the build generate a layout like install would.
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:54
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. =-)
it's where all the cool committers hang out. =-)
wayland76 Well, I'm a bad boy, I'm not on the list :)
Coke you're not on parrot-dev?
wayland76 No. I'm only here because I want a Rakudo RPM that works on a Parrot RPM 13:56
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
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:57
Maybe I should just give in and join the list, though 13:58
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
It just needs to be turned into a library function :) 14:01
14:05 magnachef joined
wayland76 Ok, I'm on parrot-dev. 14:11
Anyway, bedtime for me. Goodnight
14:15 chromatic joined
chromatic Let's talk about L1 over lunch! Meet by the registration room. 14:15
pmichaud I'll be there. 11:35, yes? 14:18
14:20 Whiteknight joined
dalek rrot: r39741 | whiteknight++ | branches/io_cleanups (16 files):
[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
14:24 ilia joined 14:26 chromatic joined
chromatic 11:35 yes 14:28
Coke chromatic: I propose we rename your L1 to C1 to avoid confusion with whiteknight's L1 (W1) 14:34
Whiteknight Coke: they're the same one now 14:35
basically
Coke ok. then we can call it CW2!
Whiteknight OMGORLYCW2?
Coke there we go. perfectly clear.
Whiteknight: I am stabbing blindly at context_pmc branch; trying to remove stuff without actually doing the conversion yet. =-) 14:36
(stuff that will be not needed when context aren't manually managed)
doesn't help that "make test" fails on feather in trunk. :|
Whiteknight chromatic: where you at right now?
chromatic Earth.
Coke THis chat is coming from inside your own room.
chromatic 12 feet from The Chip.
Coke CHIP! 14:37
chromatic 14 feet?
Coke tell him I said hi.
Whiteknight okay, where is chip?
chromatic Earth.
Whiteknight increase your resolution!
chromatic NORTH AMERICA
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
Coke 5) U.S.
chromatic que paso America!!
Coke que tal, freaks!
chromatic Ay, chulo. No me gusta. 14:38
14:38 cotto joined
chromatic I'm in Rangoon 3 or whatever the R-word is. 14:38
moritz "room"? 14:39
purl it has been said that "room" is something refugees from AOL might say. ITYM "channel".
chromatic The room has a specific name which isn't "Where Schwern and Chip are" but also starts with R.
Roanoke? 14:40
14:40 ruoso joined
Coke Chip Rangoon. 14:41
NotFound ...and most of Spain understand Spanish ;)
Coke verdad?
Whiteknight chromatic: is there a talk right now in rangos 3? 14:42
chromatic Yes. Schwern's talking about perl5i. 14:47
14:48 kid51 joined 14:51 kid51 joined
kid51 Does anyone know why I didn't get opped when I joined the channel? Is some bot down? 14:53
Thanks, slavorg 14:54
moderator Parrot 1.3.0 "Andean Swift" released | 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:54
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
kid51 Raw braindump output is available on YAPC wiki. 14:56
Whiteknight Infinoid: it was very productive I think
kid51 yapc10.org/yn2009/wiki?node=Parrot%...tors%20BOF
There were more attendees than are listed there 14:57
14:57 Theory joined
Infinoid cotto posted some photos on trac.parrot.org/parrot/wiki/Yapc10Bof 14:57
kid51 whiteknight, particle, jhorwitz, Austin_Hastings, etc. 14:58
Plus, some unnamed participants from Deep Corporate! 14:59
cotto Someone should move the transcribed notes to our wiki where we know they won't disappear at an inopportune time. 15:00
Coke (our wiki)++ 15:04
Whiteknight agreed, we'll move them to our wiki (and maybe add fun formatting!) 15:09
dalek rrot: r39742 | whiteknight++ | branches/io_cleanups/src/pmc (3 files):
[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
chromatic s/creates/fixes/ 15:10
Coke when creating context pmcs, do I need to specifically mark anything that is an ATTR? 15:16
or does that get appropriately marked without any effort on my part?
s/context//
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
(pmc2c in trunk)
15:18 kid51 joined
dalek rrot: r39743 | cotto++ | trunk/lib/Parrot/Pmc2c/PMCEmitter.pm:
[pmc2c] only emit custom class_init code if it exists
 15:19
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
pmichaud Chip says "PASM is to real assembly as Legos are to materials engineering" 15:26
(in praise of Parrot, though) 15:27
moritz how's that a praise?
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.
Whiteknight Infinoid: ping
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
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
so the exact quote is something like "it would be like using Legos to learn materials engineering" :-)( 15:30
15:30 masak joined
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.
dalek rrot: r39744 | cotto++ | branches/pmc_pct/compilers/pmcc/src (3 files):
[pmcc] generate some more code in class_init, add actions to support hll and maps traits
 15:33
15:53 s1n_yapc joined
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:57
15:59 Patterner joined 16:11 viklund joined
masak en.wikipedia.org/wiki/Chip_Salzenberg 16:14
16:18 darbelo joined 16:20 MoC joined
Coke if dan is pre-cambrian, chip is permian. 16:28
16:28 st joined, s1n_yapc joined
st hi! does anyone know ho to spawn a new thread from PIR? 16:29
*how 16:30
Coke st: check out examples/pir/thr-primes.pir ?
whoops. 16:31
that's apprently from an old revision.
st yes, i couldn't find it 16:32
Coke examples/sdl/mandel.pir // look for ParrotThread
also perldoc src/pmc/parrotthread.pmc
(ew. that shows PASM, not PIR) 16:33
st thanks! 16:34
Coke also t/pmc/threads.t
good luck. =-) 16:35
16:44 kid51 joined 16:48 Psyche^ joined 16:50 jdv79 joined 16:57 mtk joined 16:58 s1n_yapc joined 16:59 mj41 joined 17:01 ilia joined 17:09 cotto joined 17:11 mjf joined 17:18 jhorwitz joined 17:27 davidfetter joined 17:36 mtk left 17:38 Austin_Hastings joined 17:39 Austin_Hastings left
dalek rrot: r39745 | pmichaud++ | trunk/compilers/pct/src/PCT/Dumper.pir:
[pct]: Correct some documentation in PCT's node dumper. No functional changes.
 17:39
17:44 flh joined, s1n_yapc joined 17:49 chromatic joined
cotto bacek, it turns out that your key refactoring will make the road to L1 easier. 17:49
darbelo bacek++ # paving the road to shiny! 17:51
17:52 kid51 joined
cotto We had a good discussion here about how to make the future happen. Expect a writeup from Whiteknight++ soon. 17:53
cotto looks at darbelo's new and shiny generated decnum tests 17:54
17:54 barney joined
cotto oh noes! It's in Perl. 17:55
17:55 Theory joined 17:56 s1n_yapc joined, magnachef joined, ilia joined
cotto darbelo, lmk if you want help using pct to generate the tests. You've been too low-maintenance lately. 17:58
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:01
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:04
japhb Tene: so, any luck with the nvidia / parrot build? 18:05
18:05 bacek_ joined
moritz well, if it's a *heavy* and robust volt-meter ... ;-) 18:07
PerlJam fluke++ 18:08
dalek kudo: 0e0671a | moritz++ | t/spectest.data:
another passing integration test
 18:09
Tene japhb: eh? last night kind of trailed off for me. 18:10
I don't actually remember where we ended up.
nopaste "kid51" at 70.85.31.226 pasted "auto::gettext warning on Darwin/PPC in io_cleanups branch" (10 lines) at 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:
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)
I will say, though, that 185.18.14 is the release that refused to work on my poor laptop's card (an m7800)
purl i already had it that way, japhb.
japhb throws purl a hush puppy 18:17
18:19 cotto joined
cotto the wireless here is really nice when I can connect 18:19
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.
chromatic Whiteknight's driving back home now.
kid51 Oh, sorry to hear he had to leave early 18:22
cotto I think that was his original plan.
either way, agreed
Where's pmichaud?
purl pmichaud is www.pmichaud.com/ or "Patrick R. Michaud" <mailto:pmichaud@pobox.com> or in charge of toaster experiments
cotto < purl-- > 18:23
pmichaud I'm in the mst talk 18:24
(rangos 1) 18:25
cotto ok. I'll catch you later. I'm playing with writing some functions in hash.pmc in nqp.
pmichaud excellent
cotto does nqp currently support three-part for loops? 18:26
pmichaud no, but we can add it if you need it.
(it's always possible to convert a three-part for loop into a while loop, though)
chromatic It might be useful to see what NQP can do unchanged first. 18:27
cotto struct access? 18:29
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.
pmichaud Although I wonder to what extent we really want to support struct access
18:30 allison joined
kid51 msg Whiteknight smolder.plusthree.com/app/public_pr...ails/24046 18:30
purl Message for whiteknight stored.
cotto The architect appears. 18:31
pmichaud, I don't see how we can do much without it.
of course, this is pre-pre-pre-prototype
pmichaud wouldn't we be dealing with "attributes" more than specific structs? 18:32
chromatic I think so. 18:34
18:34 eternaleye joined
chromatic Mostly we just need to see what the syntax looks like for PMCL. 18:34
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?
chromatic That's a good question.
nopaste "kid51" at 128.237.250.183 pasted "Test of nopaste.pl" (1 line) at nopaste.snit.ch/17014 18:36
Coke any parroteers going to EuroPython?
pmichaud I'm not.
allison ah, thanks to whoever put up the "no ps due to yapc" message 18:37
Coke whoops. yah, thanks. =-)
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.
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
Coke: hopefully next year
NotFound: it would be good to have someone there, if it works out for you
davidfetter allison, how's your head? 18:39
NotFound Ah, no, I mixed conferences X-)
allison NotFound: ah well
cotto I have to say that it's considerably nicer writing PMCs in nqp, even if the syntax is experimental^2.
allison davidfetter: much clearer
davidfetter :)
allison davidfetter: I've only been working a few hours a day, but today I feel almost entirely myself again :) 18:40
davidfetter yay!!!
davidfetter notes that jet lag is more hazardous than he'd originally imagined
allison heh, indeed :)
NotFound No, Birmingham is a little too far to me, sorry.
davidfetter has been pretty continuously jet-lagged for the past year or so :P
nopaste "cotto" at 128.237.230.103 pasted "a couple VTABLE functions from hash.pmc rewritten in nqp" (105 lines) at nopaste.snit.ch/17015 18:41
allison davidfetter: well, beware of sunlit plate glass doors
davidfetter will do
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.
chromatic cotto, that'd be easier to read with the comments at the top, not inlined.
cotto I thought it'd be the opposite.
Coke cotto: s/J/j/
is $iter.vtable.shift_string valid nqp? 18:43
18:43 ilia joined
chromatic I get lost trying to figure them out. 18:43
cotto Coke, there are likely many problems with that nopaste. 18:44
When you get out, I'm in the registration room. 18:45
chromatic There should be snacks.
cotto There's cookies, fruit and drinks.
NotFound Magic cookies?
18:46 athomason joined
cotto they don't look magical, but maybe that's part of the magic 18:47
Maybe the cookies are magic. They're disappearing.
NotFound Amazing! 18:48
purl If you want to see amazing you should look at groditi_gone's collection of ear wax statues
nopaste "cotto" at 128.237.230.103 pasted "a couple VTABLE functions from hash.pmc rewritten in nqp, v2" (120 lines) at nopaste.snit.ch/17016 18:51
cotto and they're gone 18:54
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
but I guess we'll need syntax for that for other reasons
Coke do we have any docs on NQP syntax? 18:57
(nothing in compilers/nqp leaps out at me.)
(aside from the grammar itself)
19:02 bobke joined
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:03
nopaste "coke" at 72.228.52.192 pasted "valid nqp?" (4 lines) at nopaste.snit.ch/17017 19:04
cotto Coke, it looks valid. Does it asplode?
Coke ayup.
error momentarily: 19:05
No applicable methods.
happens on the assignment.
cotto I guess it'd work if you split the declaration and assignment.
Coke hurm. 19:06
nope.
nopaste "coke" at 72.228.52.192 pasted "valid nqp?" (13 lines) at nopaste.snit.ch/17018 19:07
Coke ah. it's just that it's borked in installed parrot.
cotto yeah. It works fine here. 19:08
Coke opens a ticket. 19:14
so much for my just hatched plan of rewriting parts of tcl in NQP to simplify them. =-)
cotto Coke++ #breaking stuff so the rest of us don't have to
Coke is running out of ways to break partcl.
Coke guesses that if NQP isn't working in an installed parrot, PCT might not be either. 19:15
I can't convert any more PMCs to PIR...
I'm too slow but need a profiler...
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
cotto That ticket looks familiar. 19:19
Coke I search for NQP before opening a ticket.
(only int rac, though)
19:20 mikehh_ joined 19:22 ilia joined 19:23 magnachef joined
dalek rrot: r39746 | japhb++ | trunk/runtime/parrot/library/OpenGL/Math.pir:
[OpenGL] Math.pir: Refactor elementwise binops again using macros of macros
 19:34
19:35 cotto joined
dalek rrot: r39747 | japhb++ | trunk (2 files):
[OpenGL] Math: rename binop 'mult' to 'mul'
 19:37
19:41 chromatic joined
NotFound parrot insparrot/lib/1.3.0-devel/languages/nqp/nqp.pbc foo.nqp - hello world 19:42
Works for me 19:43
japhb pmichaud, Tene: do you have brain cells to spend on cross-HLL brainstorming? 19:52
19:59 mtk joined 20:00 mtk left 20:07 Theory joined, jan joined
Tene japhb: I do. 20:10
japhb: do you?
purl hmmm... do you is it compulsory? ;)
japhb I do
I think we need pmichaud as well, because I want to discuss the keyed assign problem 20:11
foo[N] = baz
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
Which goes against the Parrot grain, shall we say.
Tene um... cardinal does it very very wrongly
it just tries to call a method named '[]=' in the object 20:13
I need to fix it.
japhb Well, arguably that's closer to the Parrot expectations than what Rakudo does.
Tene yes
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?
s/Rakudo/PCT/, I guess 20:15
Tene I'd prefer the latter, I think. 20:17
Need to think about it, though.
It might cause some problems...
japhb Yeah, as do pmichaud and jonathon.
Tene my $b := @a[3];
japhb Do we want to support that on foreign objects? 20:18
I guess it comes down to how much foreign objects are expected to behave like natives.
"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.
Coke might be worth seeing how many other HLLs agree with perl6.
japhb How common is the bind operation in dynamic languages? Does the equivalent exist in Ruby, Python, Tcl, et al.? 20:20
Coke: we're on the same wavelength, I think.
Coke something like bind exists in tcl; you can alias a local variable to an outer scope's associative array element.
PerlJam japhb: perl5 does it! :)
japhb Perl 5? Never heard of it. :-) 20:21
OK, that's 3.
PerlJam japhb: scheme, haskell, lisp, etc. all do binding as well.
20:21 Andy_ joined
japhb I think this may be an operation we need to support generally, then 20:21
Coke hurm. I actually can't make my sample there work. 20:22
so nevermind from my side, at least for now. =-)
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:23
Coke for what, now. 20:25
"bind" ?
japhb Coke: minimally, bind to element of collection.
as an lvalue
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
isn't that already bound?
japhb so that @a[3] = 5 can be decomposed into $temp := @a[3]; $temp = 5, even if @a is a foreign object
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.
Coke (in which case it should return a PMC, which...)
japhb So we can't pass a FixedFloatArray, for example.
dalek rrot: r39748 | japhb++ | trunk (2 files):
[OpenGL] Math: fill out vec-num binops using another super-macro; add another sample to math.pir; make math.pir output less confusing
Coke how on earth would you bind that? =-)
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
Coke but then you have to upgrade the value in the original container with the proxy.
or else the next person to ask for the value gets the original constant.
at which point... use pmcs. No? 20:29
japhb Coke: no, because the proxy just passes assigns through.
Coke I can't say I like that plan.
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. =-)
japhb Coke: from an HLL?
Tene HLL isn't at issue here.
Coke You can do that now: 20:31
bigcontainerofPackedfloats[index] = newfloat.
japhb Yes, in PIR. How do I do:
@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')
dalek TT #782 closed by moritz++: src/pmc/env.t confuses compiler specific and platform specific macros
japhb In that latter statement, Rakudo currently wants to do it in two steps, binding a temp first.
Coke japhb: in pir: big_array = somethingThatReturnsArray()
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?"
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.
Tene: if perl6 wants to assign to things that aren't PMCs, it's going to have to be smarter.
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
japhb Coke: exactly 20:35
Tene Coke: so what should "$a := @b[0]" translate into that will work with a fixedfloatarray?
japhb Coke: now -- how does Rakudo know what PIR to write when it doesn't know the type of the array until runtime?
Coke japhb: as I recall, allison's take on that was "explode" 20:36
japhb LOL
allison: bad architect, no biscuit. :-)
Coke japhb: try it and catch it when it throws an exception, falling back to the slow "create a proxy" method? 20:37
japhb Well, that's at least better than exploding 20:38
Seems a heck of a hit, though.
Coke or you could /always/ make the proxy.
moritz how fast are exceptions, compared to other control flow?
japhb Perhaps collections could have a "bindable" attribute/property/whatever that can be detected ....
Coke moritz: they're all slow. 20:39
japhb Then I'd like to do something else.
Working with packed arrays should not be Slow By Design
Coke If you avoid everything in parrot that's slow NOW, you're never going to do anything.
japhb: I'm not saying they're slow by design. I'm saying everything is slow in the current implementation.
japhb Ah. 20:40
Coke doing what's fast in parrot /today/ is a recipe for cleaning up your code later.
moritz CPS should make them fast, in theory, I think
Coke moritz: parrot is SUPER HELLA FAST in theory.
moritz Coke: ;-)
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
cotto Where are all the Parrot hackers at yapc? 20:43
Coke japhb: I think a ContainerProxyKey has some merit, though. 20:45
KeyProxy?
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.
I think once you have that, though, the HLL is responsible for instantiating it when it needs it.
japhb ... but the HLL needs some way to know if it needs it.
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.
Coke (do a test) why not?
(you could cache the results for a given PMC.)
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.
I thought of the cache,
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
if you have a variant get_pmc_keyed, then you need to subclass the core packed type anyway.
japhb but we can't do the cache directly, because the HLL in theory could loop over the whole array making unique binds.
Coke (otherwise it won't behave like the core type.)
You could. why would you do that?
NotFound TT #785 works for me
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.
japhb Coke: not that it's a good idea. We just need to do the right thing, and not get crazy slow.
PerlJam "core collection types"?
Coke it's ok to get crazy slow if your users are doing something stupid. =-)
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.
is checking the type of a pmc container slow?
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
And I think your idea of changing the non-pmc collection types to DTRT is close to what I am looking for.
Coke DTJT.
(japhb)
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.
s/HLL/Perl 6/ 20:54
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.
so then you have to do the check to find out if it that use case is safe... etc.
japhb ... which is why I suggested that instead of modifying the current op/vtable, we add one for the lvalue bind case. 20:56
Because you want both behaviors.
indexing to get rvalue and indexing to get lvalue are fundamentally different.
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.
Coke japhb: there, concensus. =-) 20:57
japhb :-) 20:58
20:59 magnachef joined 21:00 ilia joined 21:03 ilia_ joined
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:09
japhb "investigate slice"? Meaning, figure out how to proxy that? 21:10
Coke if you want an lvalue slice. 21:11
dalek cnum-dynpmcs: r88 | darbelo++ | trunk/ (5 files):
Fix "Inf" handling in the converter script.

doing it on purpose.
japhb Coke: gotcha
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:13
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
All right, what's the best doc to get started with? 21:17
(Assuming Tene++ doesn't beat me to the punch and JFDI)
darbelo docs/pmc.pod has the basics and there's also some stuff in docs/pmc/ on the parrot tree. 21:19
japhb OK.
Thanks, darbelo++
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. ;-)
japhb goes back to the "mental break" activity of writing OpenGL/Math.pir 21:21
21:24 skids joined
GeJ Good morning everyone 21:27
japhb o/
dalek rrot: r39749 | japhb++ | trunk (2 files):
[OpenGL] Math.pir: more compact dump output; math.pir: improve output spacing
 21:32
japhb Huh, that's interesting. dalek ate the __ before 'dump' 21:34
rg would guess trac ate it (underline the empty string) 21:39
japhb :-/
21:41 gryphon_ joined
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:42
moritz refrains from adding a lolcat comment ending in "EATED IT" 21:43
japhb moritz: REFRAIN FAIL
;-)
NotFound ABSTAIN FROM REFRAINING
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.
darbelo I'm looking at "trac.parrot.org/parrot/log/?limit=...ormat=rss" and it doesn't have the __
japhb Ah, I think I found it 21:45
yup, trac--
21:45 bacek_ joined
darbelo and trac.parrot.org/parrot/log/ has an underline running from dump to the "..." at the end of the line. 21:45
TRAC EATED UR UNDERSCOER 21:46
22:01 bacek_ joined
bacek_ good morning 22:02
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
bacek_ read irclog 22:03
hooray! NQP FTW!
22:04 cotto joined
bacek_ cotto++ # C is dead, long live NQP 22:05
cotto not dead, but greatly diminished
and if we do a good job replacing it with nqp, I won't miss it either 22:06
bacek_ :)
NotFound I'll say it one more time: TT #785 does not fail for me.
bacek_ We need static typing in NQP.
And reduced support for MULTIs. 22:07
Or we can use it directly from pmcc. 22:08
cotto bacek_, reduced?
bacek_ Simplified. Not full Perl6 multis. 22:09
22:09 eternaleye joined
cotto Oh. Of course not. 22:09
I thought you meant reduced from where it currently is.
bacek_ btw, "rule body { NQP:::Grammar::statement_block }" in pmc probably will work. 22:10
Currently there is no multis in NQP :)
cotto exactly
bacek_ exactly "multis" or exaclty "rule"? 22:11
"rule body { <NQP::Grammar::statement_block> }" 22:12
cotto multis
22:15 Austin_Hastings joined
dalek cnum-dynpmcs: r89 | darbelo++ | trunk/ (5 files):
Fixup some regexes in decTest2pir.
 22:20
22:22 JC1 joined
dalek rrot: r39750 | japhb++ | trunk (2 files):
[OpenGL] Math: document and show alternate instantiation syntax
 22:30
22:33 rg1 joined 23:11 patspam joined
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
ot implemented in class 'NameSpace'" (most of the other variations I've tried). Any thoughts?
bacek_ OpenGL::Math::Vec4.new?
japhb bacek: I think I tried that one, but let me check again. 23:18
yup, the invoke() error above
dalek tracwiki: v5 | Austin_Hastings++ | Yapc10Bof
tracwiki: Moved photos inline, w/ OCR
tracwiki: trac.parrot.org/parrot/wiki/Yapc10...ction=diff
bacek_ japhb: no idea... 23:23
japhb Yeah, I'm drawing a blank myself.
Perhaps I need some inline PIR for now.
Austin_Hastings Did you 'register' it? 23:24
(I'm assuming you've got lots of these, and this is probably a no-brainer, but ...)
japhb Austin_Hastings: hmmm?
Given that I don't know what you're talking about, I probably missed something key. :-) 23:25
Austin_Hastings Did you write this?
(The OpenGL/Math/whatever stuff?)
japhb YEs.
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,
japhb But now I'm trying to use it from Rakudo,
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.
japhb Ah! Tene's cross-HLL loader must be doing this automatically for the exact classname you 'use' ....
Austin_Hastings Haven't seen it. Maybe?
(But I kind of expect not...) 23:28
japhb Or maybe Rakudo does by itself, hmmm.
Austin_Hastings: OK, where do I look for sample code? 23:29
Austin_Hastings I'm looking for some now. bide
japhb thx
Austin_Hastings Try $PARROT/runtime/parrot/library/PGE/Perl6Grammar.pir 23:30
Search for p6meta.'new_class'
23:31 magnachef joined
Austin_Hastings That's "how you create a p6 class on purpose" 23:31
japhb Hmmmm. This is going to be slightly different for every HLL that wants to load the module, isn't it? 23:32
Austin_Hastings Not really. 23:33
Anyway, then look at the "register" method in P6object.pir (in runtime/library)
That's how you hook a non-P6 class into the P6 object model.
japhb If I register via P6metaclass, am I really registering with PCT's MOP? So any PCT language will recognize the new class?
Austin_Hastings You're registering with P6's MOP, which PCT also uses. 23:34
(I think)
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
Austin_Hastings Can you give me a pointer to "Tene's cross-HLL loader" ?
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:36
Oh nice, my DNS server is deciding to be a pest 23:37
Austin_Hastings LOL
23:37 Limbic_Region joined
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:38
japhb bugger all, looks like it's not coming back from a reboot. 23:41
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:43
Austin_Hastings Is it under "Tene" or some other name 23:44
??
japhb Tene?
purl hmmm... Tene is Stephen Weeks or a madman
Austin_Hastings Thanks
23:46 Whiteknight joined
Austin_Hastings Howdy, WhiteKnight 23:46
Whiteknight howdy 23:47
Infinoid Whiteknight: pong
Whiteknight hiya infinoid 23:48
I actually don't remember why I pinged you. did I msg you?
Infinoid yeah, about your checkin and some test failures
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*
Whiteknight yeah, I had a few really weird failures, although they look mostly related
Infinoid testing now
purl, messages help?
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!
Whiteknight awesome, thanks!
msg is also "msg <username> <message"
purl Message for is stored.
Whiteknight damnit
Infinoid purl, msg is also see messages help
purl Message for is stored.
Infinoid lame.
Whiteknight weak
is . 23:51
[19:51] <purl> You have 6 messages waiting.
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.
purl Message for japhb stored.
Whiteknight oh awesome, kid51 already did a smolder in the branch: smolder.plusthree.com/app/public_pr...ails/24046
so that should give you an idea about what is broken
Infinoid I see broken packfiles (due to PBC_COMPAT yet again) and some failures from t/pmc/io.t 23:55
looks pretty much the same as kid51's 23:56
dinner time, I promise I'll look at the failures after 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!