Perl 6 - the future is here, just unevenly distributed

IRC log for #plparrot, 2010-07-29

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

All times shown according to UTC.

Time Nick Message
00:56 davidfetter cxreg, so about Form_pg_proc.proretset ...
01:12 * cxreg looks at the "arrayizer" thing
01:12 cxreg weird.
01:13 cxreg bc5452c1 is even weirder
01:14 davidfetter ?
01:14 cxreg just looking at dukeleto's recent commits on msater
01:14 cxreg master
01:14 cxreg the ones that moritz helped with
01:15 cxreg i'm gonna take a swing at srf
01:15 davidfetter thanks! :)
01:28 cxreg 9.0 is september now?
01:31 davidfetter well, it kinda looks that way :(
01:31 davidfetter but 9.1 is already branched :)
02:35 cxreg heh
02:35 cxreg the git switchover is in august, right?
02:35 cxreg is 9.0 still going to be cut from cvs?
04:08 davidfetter i don't think so
07:39 dukeleto cxreg: what do you find weird about those commits?
07:48 cxreg the voodoo involved
07:51 cxreg &infix:<,> turns a parrot array into a perl6 array?
07:53 cxreg and this hunk, wtf?
07:53 cxreg -    $P2 = $P1(args)
07:53 cxreg +    $P2 = $P1()
07:53 cxreg +    $P3 = $P2(args)
07:54 cxreg anyway, moritz++ indeed :)
08:06 dukeleto &infix:<,> is the name of the infix comma operator
08:07 dukeleto gotta go
08:07 * dukeleto will explain more later
15:13 justatheory joined #plparrot
15:19 davidfetter mornin'
15:25 * davidfetter nudges cxreg
17:42 dukeleto mornin'
17:49 dukeleto cxreg: as for the $P1(), that executes the sub { .. }, which really just compiles it, and then the $P2(args) actually runs the sub { ... }, giving it the arguments that have been converted to a Perl 6 Parcel object from a ResizablePMCArray
18:20 cxreg ohh
18:29 dukeleto i will refactor it to use better variable names, which will hopefully make that more transparent
18:45 davidfetter dukeleto++
18:45 davidfetter cxreg, so about that first cut at SETOF...
18:46 cxreg havent had time
18:46 cxreg i have a deadline at $work tomorrow
18:46 davidfetter any idea when you might?
18:47 cxreg hopefully tonight, i did start poking at it
18:48 davidfetter got anything?
18:50 * davidfetter not super clear on how pl/perl does this, or what things are consonant in pl/parrot
18:50 dukeleto what is the gist of what we need to do with SETOF ?
18:50 dukeleto consonant?
18:50 davidfetter well, analogous, let's say
18:51 davidfetter basically, a function in PL/mumble can return what amounts to a table-like thing
18:51 dukeleto the postgresy things are the same for SETOF, but instead of creating a Perl 5 array ref, we would create a ResizablePMCArray
18:51 davidfetter take SELECT * FROM generate_series(1,10)
18:52 davidfetter ok, then what?
18:53 dukeleto davidfetter: best thing is to write a test first, then iterate on writing the implementation
18:53 dukeleto in a branch for SETOF, of course
18:54 dukeleto davidfetter: you will probably have to modify the sausage function to know about SETOF
18:54 davidfetter k
18:55 cxreg it looks like plperl does 2 things
18:55 cxreg one is that it provides a return_next() function
18:56 cxreg the other is that it seems to have some automagic conversion of arrayref-of-hashrefs
18:56 cxreg the sausage function is definitely affected
18:56 cxreg we'll want to provide return_next too
18:56 dukeleto and the plparrot_push_pgdatatype_pmc may need to know about SETOF as well
18:57 cxreg that part i'm not sure about yet
18:57 davidfetter yes, the return_next thing would be pretty crucial. allows for spill-to-disk in giant result sets
18:58 cxreg i started plumbing this all last night but i didnt get too far yet
18:58 cxreg mostly just trying to understand how plperl works
18:59 davidfetter dukeleto, i'm a little bummed that our sentence didn't get into the r* announcement :(
18:59 dukeleto cxreg: i spent a few months reading the plperl source code to see what it is doing. Fun times :)
19:00 dukeleto davidfetter: "our sentence" ?
19:01 cxreg dukeleto: yeah, I think I mostly understand, but it's the little details that arent sticking yet
19:01 davidfetter "Rakudo Star has already been embedded in PostgreSQL: http://pl.parrot.org/"
19:01 dukeleto davidfetter: well, nobody has actually tried PL/Parrot with Rakudo*, have they?
19:02 dukeleto davidfetter: who did you send that sentence to?
19:02 davidfetter pmichaud in #perl6 yesterday
19:03 dukeleto well, i understand his caution. We don't have an easily downloadable/installable/documented thing to release, it is still kind of alpha-ish
19:04 davidfetter k
19:04 dukeleto davidfetter: but i understand your disappointment as well
19:04 davidfetter heh
19:05 * dukeleto knows the guy who runs the Parrot twitter/identi.ca accounts, we can strum up some interest today, but we should still tell people we are in alpha
19:05 dukeleto we need to attract devs that want to hack on PL/Parrot now, and we need to attract HLL authors that want their language embedding in Postgres
19:05 davidfetter indeed
19:06 dukeleto cxreg: which version of PL/Perl source are you reading?
19:06 dukeleto cxreg: you should read the PL/Perl from the 9.0 or 9.1 branch, lots of improvements have happened since 8.4
19:06 cxreg 9.0
19:06 davidfetter can we just bag <9.0 support for pl/parrot?
19:07 cxreg i follow pg development as closely as i do rakudo :)
19:07 cxreg i was wearing a pg9 shirt the other day
19:07 davidfetter heh
19:07 davidfetter for *real* database needs, use a 9!
19:07 dukeleto i am not attached to supporting < 9.0, but it gives us a larger possible audience if we support the latest 8.x release
19:07 cxreg hm
19:07 dukeleto i don't care much about <= 8.3
19:08 * davidfetter wonders how to convince snoop to write & perform something about pg
19:08 cxreg dukeleto: i wouldnt sweat it
19:08 dukeleto 8.3 sucks pretty bad, but many people will be using 8.4 for quite a while, until 9.1 goes out
19:08 dukeleto most DBA's are allergic to X.0 releases
19:08 davidfetter are there post-8.4 things we'd really miss?
19:08 cxreg the only thing i did so far that would break in 8.4 is that i added SPI_* stuff new in 9.0 in the spi branch
19:09 davidfetter that'd be a pretty big deal, actually
19:09 dukeleto it is easy to have some #ifdefs
19:09 dukeleto our Makefile creates a bunch of variable so it is easy to see which version of PG we are compiling against
19:10 dukeleto the top of plparrot.c has some macros that depend on which version it is
19:10 dukeleto my philosophy is: if it is easy to support back to 8.3, do it. If it is annoying, don't.
19:10 davidfetter heh
19:10 davidfetter ok
19:10 dukeleto People who really want support <=8.3 can donate to the cause
19:12 dukeleto i think we should all take 9.x as our main target, and support older versions if it is a simple #ifdef or something
19:12 davidfetter good plan
19:13 davidfetter much as i'm amazed at what's happening, i'd be pretty amazed if we managed to get a 1.0 out with 9.0
19:13 davidfetter (same day)
19:18 davidfetter but who knows? :)
19:18 dukeleto when is 9.0 supposed to be cut? late august?
19:19 davidfetter looking like september, so maybe i wouldn't be so amazed after all :)
19:19 dukeleto cxreg: i wonder if we can just have a data file with all of the SPI functions, and then auto-generate the PIR that does all of the set_global, dlfunc stuff
19:21 dukeleto it could be a YAML file with : function name, signature and then we autogenerate some PIR from that
19:21 davidfetter yuck faml. JSON forever!
19:21 dukeleto hahaha
19:22 dukeleto JSON makes a lot of sense if you are actually going to use the data from JS, but we aren't. I love JSON, but YAML seems better for this scenario
19:22 davidfetter i'm mentioning this because pg is going to have JSON as a first-class type in the sense that it has XML now
19:22 davidfetter well, among other reasons, for that one
19:25 cxreg dukeleto: yes, we could generate that stuff
19:25 cxreg but since we need to augment the functions anyway, i'm not sure if that's worthwhile
19:28 cxreg it turns out that ash_ is almost finished with the new NCI interface
19:28 cxreg but it's not merged yet
19:28 cxreg i'll have to try it out
19:32 dukeleto cxreg: very cool. it should be done by late august, since that is when GSoC is over :)
19:33 dukeleto cxreg: i am only talking about auto-generating the set_global/dlfunc stuff, not the function bodies
19:38 cxreg yeah, i know
19:39 cxreg honestly it may turn out that we don't even want to expose the SPI functions to users
19:39 cxreg which would solve the problem
19:40 cxreg if all we provide is the interface, there's less issue
20:03 dukeleto cxreg: how hard is it to get the symbolic constants for elog?
20:03 dukeleto cxreg: can we automate it?
20:03 cxreg that i'm not sure about
20:03 cxreg yeah, i guess so
20:03 cxreg they're in utils/elog.h
20:04 cxreg parrot has dlvar for globals
20:05 cxreg but constants are not variables
20:05 cxreg maybe we could just parse that
20:06 cxreg and produce some pir
20:06 eggyknap FWIW, that's what most PLs do.
20:09 dukeleto eggyknap: good to see ya around
20:09 eggyknap Yeah, sometimes I actually pay attention. :)
20:09 dukeleto how does PL/Perl get at the constants?
20:10 dukeleto eggyknap: we have irc logs now, if your backscroll is too short :)
20:12 * davidfetter has scaled back a good deal on the purple prose since those logs started. this is probably a good thing
20:16 eggyknap dukeleto: actually I take that all back :) I don't speak enough XS to know precisely what it does.
20:17 eggyknap PL/LOLCODE does parse it, but PL/LOLCODE parses everything.
20:18 davidfetter CAN HAZ JSONZ?
20:20 szbalint but I am on PL/Parrot
20:20 davidfetter heh
20:20 szbalint just ENOTIME lately :S
20:21 szbalint anyone coming to YAPC::EU btw?
20:21 * davidfetter dcc's over a few tuits
20:21 davidfetter when is it?
20:21 szbalint next week
20:21 davidfetter d'oh!
20:21 davidfetter well, r/t air fare would probably be under usd10k
20:21 davidfetter ...if i bought it *today*
20:22 szbalint it's Pisa, Italy
20:26 davidfetter aw, heck, it's only usd6500 or so
20:26 davidfetter for air tix
20:27 davidfetter think you can get me that in advance? ;)
20:28 davidfetter found a fare for usd3400
20:29 szbalint the hotel (where the venue is at) is booked full, but it only has double rooms, so if you don't mind sharing one, it should be easy to get a room :)
20:30 szbalint davidfetter: nice try, but no :p
20:30 davidfetter heh
20:30 * davidfetter suspects $gf would not approve
20:31 davidfetter "oh. you're going to pisa. alone. make up the couch. you'll be there awhile."
20:31 szbalint hehe
20:32 szbalint Bring the $gf then? :)
20:33 davidfetter sure. it's only usd5k extra, or so
20:33 davidfetter i'm down with sharing a room, but i doubt she will be
20:39 szbalint ah well, there's another FOSDEM next year in the worst case :)
20:40 davidfetter yeah. i hope they still pay :)
20:40 dukeleto you guys are hilarious
20:41 dukeleto eggyknap: when are you gonna port PL/LOLCODE to PL/Parrot?
20:41 davidfetter it should be pretty simple
20:42 davidfetter dukeleto, you've met sarah. feel like crossing her? ;)
20:42 eggyknap dukeleto: if I find time to do stuff like that, I'll use it for, I dunno, something more useful :)
20:43 davidfetter so you don't see PL/LOLCODE as a good canonical PL/Parrot language for study?
20:43 eggyknap True, that might be worth it.
20:44 eggyknap Might be better to use the existing Parrot LOLCODE implementation, though.
20:44 * davidfetter was vaguely contemplating PL/Squaak
20:59 dukeleto yes, PL/Squaak would be pretty cool
20:59 davidfetter does Squaak have file operations? socket? network?
21:00 dukeleto eggyknap: with an existing Parrot-based LOLCODE, making PL/LOLCODE should only take a few hours
21:00 eggyknap Kinda what I thought.
21:00 dukeleto davidfetter: tcurtis in #parrot is the best person to ask about that, he just took over maintainership of the Squaak tutorial
21:01 dukeleto davidfetter: he is one of the gsoc students
21:01 davidfetter oh, cool
21:01 davidfetter i was asking about those re: PL/Squaak vs. PL/SquaakU
21:01 davidfetter but if Squaak doesn't have any such ops, it's a "free" PL/Squaak :)
21:02 dukeleto davidfetter: indeed
21:03 dukeleto we need an abstraction layer for adding HLL's on PL/Parrot. The way I implemented PL/Perl6 knows too much about PL/Parrot internals and there is a bunch of duplicated code
21:03 davidfetter should we try for another language or two to see what such an abstraction might look like, or can you already tell?
21:03 dukeleto or maybe even something like make_new_lang.pl in Parrot which gives you the proper PL/Parrot glue for a new language
21:04 davidfetter :)
21:04 dukeleto davidfetter: i can mostly tell, but one other HLL would probably be best, because it would give us something to contrast PL/Perl6 to
21:05 dukeleto basically, my thought is, all HLLs on PL/Parrot will use the same code to turn PG datatypes into Parrot datatypes. Then each HLL will provide a function to turn Parrot datatypes back to the HLL datatypes
21:05 dukeleto so they all use the same code to do PG -> Parrot, and each provides their own to do Parrot -> PG
21:06 davidfetter makes sense
21:07 davidfetter although of course it would be smashing if they could use common infra for both
23:01 dukeleto davidfetter: only the HLL knows how to turn PG datatypes back into HLL datatypes, but I agree, the least code duplication possible, the better
23:36 harrisonpartch joined #plparrot
23:36 harrisonpartch left #plparrot

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