Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 26 April 2009.
01:36 eternaleye joined 02:57 japhb joined 08:33 masak joined 10:53 kid51 joined
kid51 Hello, I wonder if today there could be some discussion of the content and format of the Parrot workshop preceding YAPC in Pittsburgh. 10:53
Need to know the balance between presentations, hackathon, etc. 10:54
Need to get a sense of where I'd fit in, whether it would be worth it for me/others to come early, etc. Thanks.
11:56 Whiteknight joined 14:50 davidfetter joined
Tene prereporting: got absurdly busy with work, did absolutely nothing. EOR. 16:37
18:00 NotFound joined 18:06 masak joined 18:07 fperrad joined 18:09 darbelo joined 18:10 allison joined 18:13 moritz joined 18:15 barney joined 18:18 Util joined 18:23 PacoLinux joined 18:29 Coke joined, pmichaud joined, rgrau joined 18:30 jhorwitz joined
allison Hi all, who's here? 18:30
pmichaud Hello.
NotFound hola
jhorwitz aye
fperrad hello 18:31
darbelo Hi
moritz hi
cotto hi
barney hi
Util Hi 18:32
allison chromatic said he'd be 10-15 mins late, so let's get started
masak hi
allison we'll go in order of hi's
Coke hi
allison pmichaud?
18:33 jonathan joined
allison or, jhorwitz? 18:33
jhorwitz fixed a bunch of regressions on mod_parrot. submitted/updated some tickets for obscure parrot/rakudo bugs. 18:34
refactoring mod_parrot configuration so i can break out mod_perl6 from the distribution. ran into some problems, which leads me to...
queue a question for later
EOR
pmichaud (here now -- wasn't expecting to be called on first)
allison pmichaud: go ahead 18:35
pmichaud * Rakudo now passing 11,187 spectests (+176 since last week)
* Fixed a bug in PCT that would evaluate program results for truth instead of definedness
* Updated PGE to provide the .orig method on Match objects
* Found a Perl6Grammar bug dealing with unicode characters; fixing it
* Cleaned up Rakudo's build system a bit more
* Cleaned up Rakudo's subtyping code
* Worked on fixing @_ and %_ handling in Rakudo
* Working today on defining custom operators in Rakudo
q2q
EOR
18:36 NotFound left
allison NotFound? 18:36
18:36 NotFound joined
allison perfect timing for dropping off 18:36
moritz ;-) 18:37
allison NotFound, do you have a report?
NotFound * A few bug fixes
* Lots of cage cleaning
EOR
allison fperrad?
fperrad * Lua: fix build after Parrot merges
EOR 18:38
allison darbelo?
darbelo decnums-dynpmcs:
* Cleaned up the Makefiles, added examples, no tests yet.
* The per-pmc-context prototype is sort-of-functional. +-/* work as does changing the rounding mode. Exceptions are raised on invalid operations.
* global-context (singleton) PMC is sort-of-functional too. The rounding mode is changeable and has proper singleton semantics.
* the PMC to use the global-context is in the works.
* Blogged some thoughts I had on singleton PMCs too.
* Got my hands on a amd64 machine for testing. I'll see if I can start smoking OpenBSD-amd64.
EOR 18:39
allison moritz?
moritz * my third Perl 6 articles in iX magazine got published, fourth and fine submitted
* blogging about Perl 6 18:40
* more testing, simple patches for Rakudo
EOR
allison cotto?
cotto * renamed the PCT-based PMC compiler to pmcc 18:41
* got ATTR inheritance and header macro generation working in pmc_pct
* pmc_pct will be blocking on pcc_rewiring in a week or so
.eor
q2q
allison barney?
barney nothing to report
allison Util?
barney hope for some quiet days in beginning of june
Util * Tuits ==> wedding( $step_son, Dream $girl, 'Saturday' );
barney .eor
Util * Tried building parrot with --cc=clang. The blocker that moritz++ found last year (#line not honored?) was fixed by the Clang team in February. The build now succeeds all the way to the linking of libparrot, where it fails due to "multiple definitions of symbol" in src/pmc/big{int,num}.o. I do not expect to pursue it further myself.
* Changed the pir_to_exe patch to build a single block from multiple strings at compile-time, but this was defeated by GCC optimizing duplicate strings into single entries in the string table. Currently changing to copy strings to a single block at run-time.
EOR
allison masak? 18:42
masak * Submitted 8 Rakudobugs since last week.
* Quite some work on Web.pm, a lot of work on proto.
eor
allison Coke?
pmichaud (q another q, for a total of 3) 18:43
Coke parrot - Added some regression tests. - Fixed some tests to work properly in 5.8.8 (cxreg++) - Created a script to help figure out what to do with old branches - Ripped out deprecated OS X dynload C calls.
partcl - Still dead.
Q1Q
allison jonathan?
jonathan A few Rakudo bits... 18:44
* Got .WALK looking better, need feedback though...
* $foo.@candidates(...) works now
* Refactored callsame and callwith to work with candidate lists, and added nextsame and nextwith
* Re-wrote .wrap and .unwrap to work in terms of candidate lists; happily a nasty closures issue with the previous cut is not an issue for this one
* Implemented "parallel" dispatch, seems to work nicely
* Procrastinating on the painful refactors P6object needs; will dig in soon otherwise I need to write nasty hacks into Rakudo for other stuff I want to get done
* Did hyper-operators on hashes
* Re-worked Rakudo's role composition - Parrot's "compose early" semantics ain't good for Perl 6
* Few other fixes here and there
Parrot
* Fixed a bug that meant you couldn't inherit from two anonymous parent classes.
.end
allison allison? 18:45
Parrot:
- Prepared packages for inclusion in Ubuntu 9.10.
- Working on editing the book, need to have that finished in the next couple of weeks.
- Working on the calling conventions branch.
- Writing a Parrot article for Linux Magazine.
EOR
Did we miss anyone?
okay, on to questions, starting with jhorwitz 18:46
jhorwitz i'm using parrot_config to grab configs so i can configure mod_* 18:47
some values have Makefiles variables like $(PERL) or $(LIBS)
shouldn't those be expanded?
allison you mean you're getting a value from parrot_config that contains a literal string $(PERL)? 18:48
jhorwitz correct
pmichaud cp => '$(PERL) -MExtUtils::Command -e cp'
allison mmm... that is wrong
moritz => ticket 18:49
allison yes, they should be expanded
jhorwitz now that i know it's an issue i shall open a ticket. :)
Coke I thought that the makefile would expand them, no?
that's how it works in the build dir.
allison it will if you've defined $PERL in the makefile
pmichaud Coke: assuming that config information is only used in a makefile
jhorwitz i'm not using them in a Makefile.
configure scripts won't either 18:50
Coke if you have a configure script, presumably you know how to run 'cp' ?
moritz I don't think that's the point of this discussion.
NotFound There are more than $(PERL) 18:51
jhorwitz better example: libparrot_shared => 'libparrot$(SHARE_EXT).$(SOVERSION)'
NotFound libparrot => '$(LIBPARROT_SHARED)'
barney In Makefile you need to define $(PERL) before you can use $(CP)
allison Coke: likely, yes, but if we're going to provide the default so people don't have to think, it makes sense to provide a default that works in all the contexts we expect it to be used
Coke allison: I thought we had. (makefiles) 18:52
NotFound I'd like better to say "don't have to work" rather than "don't have to think" ;)
allison NotFound: aye 18:53
Coke jhorwitz: how are you configuring mod_* ?
allison Coke: that's one important context, but not the only one
jhorwitz Coke: a Configure.pl script that takes Parrot's config and Apache's and merges them appropriately, using a Makefile.in template 18:54
it needs the config outside the context of a Makefile
Coke ok. so if you already have a makefile.in template, why can't you use the makefile variables?
allison I do wonder how useful knowing the path to the perl used to build Parrot is to the general world, but it doesn't hurt anything 18:55
jhorwitz $(PERL) was just an example. :)
allison Coke: do you see a downside to expanding variables inside parrot_config?
I see one, and that is what if one variable changes?
it'd almost be preferable to perform the substitutions as the value was returned 18:56
Coke <shrug> I don't mind if someone else does it. I just am not seeing why it's necessary. <shrug>
pmichaud isn't the output from parrot_config fairly static, once built? 18:57
Coke nearly hardcoded, yes.
jhorwitz also, configure scripts (autoconf) will likely want to run parrot_config directly to grab all the info
allison once parrot_config is compiled, yes
pmichaud I think that's the use case we're describing here -- i.e., only after compilation.
moritz if somebody builds parrot, and then moves his perl installation, it's hardly parrot's task to track such changes
Coke allison, Whiteknight has a report but is too timid to speak up.
allison so, perhaps it's a substitution during the compilation?
Whiteknight: go ahead 18:58
(and don't be timid :)
jhorwitz Coke: I might be able to put everything into the Makefile at this point, but I know I couldn't before
Whiteknight I cleaned up the GC API (like some feedback on that) and have been planning the switch to Context PMCs
(thanks Coke) EOR
allison thanks, Whiteknight
Whiteknight (sorry I'm late!) 18:59
allison jhorwitz: can you submit an RFC ticket, summarizing the discussion here?
jhorwitz absolutely
allison jhorwitz: I need to think through how we're going to do the "pure install" version of parrot_config, and this might actually help there
jhorwitz i imagine so. 19:00
allison (we could compose more config values in terms of other config values, instead of repeating ourselves in a hundred literal strings)
(especially wiping out those hardcoded /usr/local/lib entries scattered all over, that are causing problems for partcl) 19:01
okay, next question, pmichaud had 3
19:01 Infinoid joined
pmichaud 4 now. :-) 19:02
simple ones first.
1. running "make test" for Parrot seems to run the NQP tests first on my machine -- that seems backwards. Should it run them more towards the end?
(i.e., I'd expect more basic tests first before trying NQP)
allison yes, makes sense 19:03
jonathan (it does the same on my machine too, it's not just pm)
pmichaud I'll file a ticket.
allison after the basic tests and after the PGE tests
pmichaud Q for Util: will copying strings at program startup significantly impact startup time or memory footprint ?
at this point, I'd hate to convert a compile-time cost into a runtime one. 19:04
Util I benchmarked a mock-up, and it increased it by 0.01s. I eliminated CPU cache as a factor in the DEST part of the benchmark, but not in the SRC half, so expect slightly longer real impact, but not much more. 19:05
pmichaud how about memory footprint? Will we effectively end up with two copies of perl6.pbc in memory?
NotFound I'm unable to build rakudo now, thus the runtime cost is infinite 19:06
pmichaud That's a reasonable counter-point.
Util I do not have numbers yet, but I am coding with RLE compression of NULLs, and I would guess 30% overhead of strings, instead of 100% of duplication. 19:07
pmichaud But perhaps we should be creating an executable that mmaps the perl6.pbc into memory and then runs it, instead of placing perl6.pbc bytecode directly into the fakecutable.
(or whatever an appropriate replacement for mmap is)
moritz maybe only enable the copying solution for MSVC, and use the sane "long string" solution everywhere else? 19:08
pmichaud it might be difficult to reliably detect msvc (and possibly not worth the optimization, since pbc_to_exe is afaik supposed to be a stopgap anyway) 19:09
Util Oh, I left out that element. moritz++. If the max block size > bytecode, it can skip the coping completely.
pmichaud anyway, I just want to register that runtime performance strongly outweighs compile-time costs at the moment.
(granted that NotFound's situation notes an infinite compile-time cost) 19:10
3. Are there any plans for a Parrot Developer Summit in 2009?
in particular, are we planning anything around YAPC::EU ? I'm needing to make travel arrangements 19:11
allison We talked about having it at YAPC::EU this year, but need to do a survey of people likely to attend.
quick show of hands who could make it to a European PDS?
jonathan I'd attend.
pmichaud raises hands
Whiteknight not me
jonathan (But also need to make travel arrangements.)
Coke I'd attend if I could afford it. :|
allison too
Coke <broken reord>
"record
allison Coke: needing travel assistance is okay 19:12
quick show of hands of people who could only make it in the US?
(or, if US location would prevent you from attending?)
okay, that's helpful 19:13
Whiteknight I could attend a US one (I will be at YAPC::NA)
jhorwitz i'm almost certain to attend a US one. european is 50/50 depending on schedule 19:14
allison we'll certainly have a hackfest at YAPC::NA, even if not a PDS
Whiteknight that's fine by me, I'll make it to PDS in 2013 to discuss version 5.0
pmichaud at _some_ point I think we need a PDS similar to the one in 2008, if only to flesh out our plans for 2.0 and beyond
allison another possibility is to do PDS unrelated to any conference like we did last year 19:15
pmichaud: yes, we certainly will
and, early August, right after 1.4 is a good time for it
Coke q1moreq
pmichaud I don't need to know that we're having a PDS at YAPC::EU -- I'd only need to know that if we're having one then, what dates would it be? 19:16
allison okay, let's tentatively plan PDS for YAPC::EU this year, I'll ask the organizers if they can help us with space
the two days after PDS
pmichaud It's okay if jonathan+I end up with a couple of extra days in Lisbon :-)
allison after YAPC::EU, I mean
aye
it'll be a hackathon if it's not a PDS 19:17
pmichaud okay, works for me.
NotFound Maybe I can go to Lisboa for a day, but I don't promise
allison pmichaud: is that 3 of the 4 Qs?
pmichaud Last Q, which can be saved for later: Where are concurrency and threading on the Parrot roadmap? They aren't immediately obvious from the trac report. 19:18
barney 2-3 days before and after
in Lisbon
pmichaud EOQ from me
allison pmichaud: they're not on the trac report, yet
jonathan (2 days after Lisbon) works fine for me too 19:19
pmichaud we're starting to get inquiries about threading in Rakudo, and iwbn to know what Parrot's plans are.
allison do you have a dependency on them for a particular time
putting them on for 2.0 may be overly optimistic, but 2.6 is definitely a possibility
pmichaud I don't have a dependency, but I think if we get to 2.0 without concurrency then many will start to have doubts about Parrot.
jonathan allison: It's hard to tie it as a dependency to a date per se, but I know full well that we'd have at least basic threading support in Rakudo now if Parrot could handle it. 19:20
NotFound After Duke Nukem Forever cancellation, all is possible ;)
allison pmichaud: I take it back, there's an advanced concurrency task for 3.0
pmichaud I'm more interested in "basic concurrency" :-) 19:21
jonathan allison: To some degree, the implementation is going to feed into the spec too.
allison pmichaud: but, I think you're looking for more practical immediate fixes
pmichaud: we already have "basic concurrency"
but, it definitely needs more work
jonathan allison: By basic meaning useless for HLLs? 19:22
allison can we break it down into specific things that you need?
pmichaud I can name two items off the top of my head
allison jonathan: if it's useless, then I need to know how and why it's useless
pmichaud (1) some ability to create threads of some sort (because people are asking)
allison we have that, but the interface may need work
pmichaud (2) ability to run processes and capture the output -- immediate need for qx{ } and friends
allison you mean like perl 'system'? 19:23
pmichaud yes, or perl 5 backticks
moritz no, like perl's backticks
jonathan allison: I tried to create a thread from within Rakudo. Parrot, depending on the options I gave for starting the thread, either segfaulted, gave errors, looked like it was trying to clone the world, etc.
pmichaud we have 'system' already
moritz system in perl 5 doesn't capture the output
pmichaud (it's called 'run')
allison jonathan: it does clone the world, a thread is an interpreter 19:24
jonathan allison: I don't remember specifics, I did spend some time trying to make it work.
allison: It shouldn't clone, say, the namespaces surely?
allison: Or at least, you can tell it not to.
I know a one thread has one Parrot_Interpreter struct. That's fine and good. 19:25
allison pmichaud: okay, backticks are the I/O pipe functionality, which does need fixing. IIRC, you have a ticket in for that? If not, put one in and make me owner. Would be nice to have that working for 1.2.
jonathan: depends on what kind of thread
pmichaud I will make sure there's a ticket with your name on it.
allison jonathan: if it's "share nothing" then the namespaces have to be cloned 19:26
NotFound I can take a look at (2) for unixy systems. Did we have some proposal for his API?
pmichaud I think masak++ already posted a message about it to parrot-dev, will resurrect from there.
allison NotFound: the API is already there
NotFound: it's just bug-fixing
jonathan allison: Sure, but that's not the only option, right? 19:27
masak pmichaud: aye. "Getting output from system command invocations"
pmichaud masak: found it, thanks. I'll link to it in the ticket.
allison NotFound: see, for example src/io/unix.c Parrot_io_open_pipe_unix
NotFound Ok 19:28
Whiteknight the "system" opcode needs some work because it's pretty system dependent too. That might be good to dovetail with the pipes issue if we're fixing IO stuff
jonathan allison: Maybe best is if I try and write "async" into Rakudo, send you a patch and a test case, and we can work out where things aren't matching up?
allison jonathan: not the only option for threads? yes, there's also share-everything threads
jonathan: yes, that sounds like a good way to start working through it 19:29
jonathan Even if those things can't be fixed up right away, it'd at least give some concrete goals for things to work on.
allison aye, we need specific tasks
jonathan OK, I'll try and find my original attempt, or I can quickly create a new one.
allison there are quite a few people who can work on it once we break it down
jonathan Aye. 19:30
tbh part of the problem is that I'm not sure Perl 6 knows what it needs just yet, but I figure some basic support for threading will help start to transform the current ideas into something more concrete.
allison indeed, experimentation with a prototype is a great way to figure out what you need 19:31
okay, if that wraps up that one, we've got 1 question from cotto, then two from Coke
cotto I had two. First: 19:32
pmichaud (pipes ticket is #661, assigned to allison)
allison pmichaud: (thanks!)
cotto What's preventing a decision on whether readonly should be shallow or deep (RT #46821)? The RT thread seemed to be leaning toward shallow, but died off before coming to a conclusion.
19:32 fperrad left
allison cotto: I'd say what's preventing it is just that no one's made it 19:33
19:33 fperrad joined
cotto Should I flip a coin? 19:33
pmichaud shallow.
allison doing a quick mental refresh looking over the ticket
moritz coin landed
allison make it shallow for now 19:34
pmichaud I suspect it's very difficult to force deep readonly semantics.
allison we can always add some deep readonly semantics later
NotFound Did we have some test of opening a pipe in pir?
allison NotFound: no 19:35
cotto ok. next question
Was PMC-level multiple inheritance an intentional design decision?
allison NotFound: (It's not easy to test in a platform-independent way)
cotto: you mean did we intend to make it possible for C PMCs to multiply-inherit? 19:36
cotto: or, more context on the question?
cotto yes
allison as in, it works now, but you're wondering if it's accidental, or it doesn't work now and you're wondering if it should? 19:37
(or it half-works now, and wondering which way to push it?)
cotto I'm wondering if it's accidental.
allison it is intentional
many of our target languages support multiple inheritance, so we need to support it too 19:38
cotto ok. If it was accidental I was going to ask for deprecation, but I'll assume that it works as designed.
allison not all languages will use it
cotto eoq then
fperrad and used (LuaFunction for example)
cotto and partcl 19:39
allison If you encounter problems, we can extend/modify it as needed
Coke partcl doesn't require it.
(it may use it, but it doesn't require it.)
allison Coke: you had two questions? 19:40
Coke yes. one, I need your feedback on TT#632
allison pulls up the ticket
Coke two, are we for sure going to have the annual vote at yapc::na ?
Just want to make sure we don't screw up year 1. =-) 19:41
allison Coke: we can do the annual vote entirely virtually, if we need to 19:42
Coke we're going to have to do it virtually. =-) 19:43
we're never going to have all the voting members in a room.
allison Coke: oh, do you mean board, or members?
Coke there's a separate vote?
allison Coke: separate meetings
we have an annual members meeting every year, and an annual board meeting 19:44
the board meeting will always be virtual
the members meeting requires 10% of member to be present to have a face-to-face meeting
so, we could do it as face to face, and take in virtual votes from everyone not present 19:45
on TT#632, yes PIR_TODO is fine, it needs a matching =end PIR_TODO
(and any comments for the TODO reason in a =for block before 19:46
Coke =for what?
allison =for PIR_TODO or =for PIR_TODO_COMMENT 19:47
=for PIR_TODO_DESCRIPTION
Coke would PIR_T_C be rendered in the output?
allison only if we specifically request it
=block PIR_TODO won't be rendered either, by default, but will request that 19:48
I'm guessing we'd want to skip rendering P_T_C blocks?
Coke probably. 19:49
regarding the meetings: just want to make sure that all the ducks are in a row before the yapc meeting. I clearly didn't read the bylaws close enough.
allison aye, thank you, we need to do some work there, and it isn't on the roadmap, so gets forgotten 19:50
hmm... the biggest thing is starting the membership committee, is there anyone interested in volunteering for that? 19:51
maybe a mailing list post is in order
I'll do that 19:52
any more questions?
Coke (nope) 19:53
allison okay, our development priority for this week is bug fixing, patch application, and closing tickets 19:54
generally preparing for the release next week 19:55
Whiteknight sounds good to me 19:56
allison next is roadmap review
trac.parrot.org/parrot/report/14
#504 \t packfile pmcs 19:57
any updates?
I'll move it to 1.3
Whiteknight ENOBACEK
allison #565 \t remove optional features from default config, refactor config probes 19:58
I don't recall any work on this one, so moving to 1.3
#566 \t export conventions (cross hll)
pmichaud I did not get to work on it this week.
It will need to move to 1.3, but we probably need a "hard 1.3" deadline on it.
i.e., it really should not move to 1.4. 19:59
allison I'll move it and mark it as critical
(since it becomes critical at that point)
pmichaud That would be good. It will be a primary task at yapc::na if not completed before then.
(but really need completion before then, even )
allison #567 \t pdd31-hll interop
#568 \t hll interop
Whiteknight what needs to be done for those? 20:00
the ticket descriptions are particularly unhelpful
allison the basic idea is to test running two languages simultaneously, and fix any problems 20:01
note, that perl6 isn't a good test case, because it isn't yet able to fully use namespaces
pmichaud actually, it's pretty much there, I think. 20:02
allison excellent!
pmichaud we still have a few issues here and there to resolve, but the major ones are (afaik) out of the way.
that was the work I did last week.
I've been hoping that Tene++ could pick up on it again.
allison Whiteknight: If you're interested in doing some tests, I'd be happy to work with you planning what needs to be tested 20:03
Whiteknight that would be good. I'm blocking on all big projects for now
so whatever else needs a pair of hands, put me on it
allison okay, let's email or IRC chat right after the meeting 20:04
Whiteknight done. allison++
allison that wraps up roadmap review 20:05
Tene pmichaud: what am I picking up on?
I have time this week.
allison when you're doing ticket review for the week, pay special attention to the tickets tagged for 1.2 trac.parrot.org/parrot/roadmap 20:06
pmichaud getting rakudo to run in its own .HLL
Tene tonight, even.
OK
NotFound Did we have some example code of such interop problems?
Tene I will do.
NotFound: No.
allison NotFound: that's why the first step is testing 20:07
NotFound I don't find any in the examples I wrote. They were very simple, though.
allison Anyone who wants to do stress-testing of running multiple HLLs this week is welcome 20:08
very helpful
any more questions, comments, items to talk about? 20:09
alrighty, let's adjourn to #parrot
thanks everybody!
NotFound The example already in the repo is examples/pir/interlangs.pir 20:10
20:12 Util left 20:13 fperrad left 20:26 Coke left 20:35 masak left 20:39 NotFound left 20:41 darbelo left 20:43 rgrau left 20:50 moritz left 21:27 Whiteknight joined 21:40 Infinoid left 22:16 jonathan left 22:22 Whiteknight joined 22:36 kid51 joined 22:38 kid51 left

Powered by Cro and the Raku® Programming Language.

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

Thank you!