"Tuesday at 20:30 UTC"
Set by moderator on 20 April 2010.
10:08 bakkdoor joined 11:36 mikehh joined 11:59 bluescreen joined 12:43 bluescreen joined 14:40 davidfetter joined 16:28 cotto_work joined 16:36 bakkdoor joined 17:07 allison joined 18:02 NotFound joined
NotFound What I did: 18:14
-parrot
* Several fixes and workarounds.
* Minor optimizations in Hash and Lexinfo PMC and in PackFile debug
and annotations structures.
* Worked in some old tickets.
* Code cleaning.
* Improved embed example "cotorra".
-winxed
* New predef functon "cry" ("say" to stderr).
* Fix and update several examples.
* Set stage 2 as default.
What I will do:
No plan
EOR
Coke parrot - done: 18:28
- remove old json compiler.
- added tickets for most missing them in DEPRECATED.pod; added
experimental tag for gziphandle PMC - Want it, vote for it.
- fixup some makefile deps
- trac spam cleanup 18:29
- pinged SFINK to del old parrot versions from CPAN - Those are gone, but
It seems that every
time we clean up some MORE COME BACK. We now have ones on the list from
JEFF GOFF. (Probably because they're all unauthorized.)
.
18:36 bubaflub joined
Coke Q1Q! 18:49
japhb DONE: 18:52
* First Plumage grant proposal submitted to Allison
* Outline of future proposal sketched out
NEXT:
* Wait for magic funding unicorn :-) 18:53
EOR
mikehh What I did since my last report: 18:59
* testing on Ubuntu 10.04 (beta now RC updated at least twice daily) amd64 and i386 also built and using Perl 5.12.0
* building and testing parrot on amd64/i386, with gcc/g++
* branch testing
* quite a few fixes
* working on replacing in_place string ops in examples_tests, there are a whole bunch there - done about 10 files so far
What I intend to do in the next week:
* testing and fixing
* continue replacing in_place string ops in examples_tests
* although I am not at all sure if I can fix examples/pir/quine_ord.pir
* I am going to document what I needed to get parrot building and testing with new install of Ubuntu 10.04 and Perl 5.12.0
.eor
Coke QQ#2 19:01
19:18 smash joined, tewk joined
cotto_work #did: 19:19
* merged runcore_purge, getting rid of the underused cgoto, cgp and switch runcores 19:20
- libparrot.so is 1.2M smaller on my system, ymmv
- sent the Rakudo hackers a patch to remove the switch ops from the build (committed)
* "fixed" t/op/io.t
- fix wfm but fails for mikehh++ on Ubuntu 10.04 RC 19:21
* worked a bit on TT #888 which broke the build on systems with non-ascii temp dirs
- gave jimmyz++ a patch that fixes his build (though with some test failures)
- will apply a modified version tonight after feedback from chromatic++
#will do:
* PIR line number test based on chromatic++'s work on pbc_dump
#closed TTs:
* #1563 (runcore deprecation)
#eor 19:22
19:25 chromatic joined
chromatic I worked on the compact_strings_revamp branch. It's ready to merge, and it's faster than trunk. 19:26
I also worked on line numbers. I have a lot of confidence in simple PIR line numbering now.
However, I think .include may make things go weird, so test cases are very welcome there.
I also profiled PBC loading and suggested what may be a big optimization to STRING storage for Sub PMCs.
Otherwise, I'd like to profile Rakudo but they need to make some changes related to TT #389 before Rakudo will build with trunk. 19:27
If we can offer a 10% speed improvement (and we can), they might jump on that.
I may miss today's meeting.
cotto_work q1q 19:28
19:53 darbelo joined
darbelo DONE: 20:01
Obliterated deprecated PMCs.
Updated the include_dynpmc_makefile branch, it works well but still needs some deps filled out. Did some more string - io decoupling. Made some progress on making strings (and buffers) smaller. Not ready for prime time yet. Got accepted into GSoC. TODO: Get started on GSoC coding. EOR.
xterm paste: FAIL 20:02
Let's try that again.
DONE: Obliterated deprecated PMCs. Updated the include_dynpmc_makefile branch, it works well but still needs some deps filled out. Did some more string - io decoupling. Made some progress on making strings (and buffers) smaller. Not ready for prime time yet. Got accepted into GSoC.
TODO: Get started on GSoC coding. 20:03
ARGH
DONE:
Obliterated deprecated PMCs.
Updated the include_dynpmc_makefile branch, it works well but still needs some deps filled out.
Did some more string - io decoupling.
Made some progress on making strings (and buffers) smaller. Not ready for prime time yet.
20:03 eternaleye joined
darbelo Got accepted into GSoC. 20:03
TODO:
Get started on GSoC coding.
EOR.
particle EOARGH. 20:06
bubaflub DONE: 20:07
Got accepted into GSoC with RTEMS
TODO:
Get crackin' on GSoC
BLOCKERS:
Life, Finals 20:08
EOR.
Util # Done:
* Tested branch Compact_pool_revamp; looks good on Darwin
# Plan to do:
* Change docs that mention `languages/PIR` (the PCT-based PIR compiler) to point to its new GitHub repo.
# Blockers:
* $WORK
.end
cotto_work addednum: *made contact with my gsoc student (khairul). He won't be free until the 5th due to classes. 20:10
eoa
allison What I did: 20:21
- Built final packages for Debian/Ubuntu for 2.3 release.
- Worked on the task list for GC refactors (have updated trac.parrot.org/parrot/wiki/GCTasklist, comments welcome).
- Read a good chunk of www.cs.rice.edu/~javaplt/311/Readin...cessor.pdf
- Experimented with HLLs that compile to pure assembly (no runtime) and bypassing NQP, for a lightweight language.
What I will do:
- Continue planning GC refactors.
- Start knocking off GC tickets.
- General ticket review.
- Back into Pynie.
Blockers:
- In the midst of final assignments for the year, taking up a good bit of time. (Some are parrot-related.)
EOR
japhb q1q for allison 20:22
darbelo q1q
Coke PS coming up in 5 minutes; we'll need someone to volunteer to lead the meeting today. 20:25
mikehh ain't chromatic gonna be here? 20:27
allison Coke: are you not here the whole time? I can 20:28
Coke allison++ 20:30
allison Hi all, who's here?
mikehh hi
darbelo I am.
japhb o/
bubaflub hello.
cotto_work is 20:31
Util Hello
NotFound Hola
Tene I'm kinda here. I don't have any useful information, though.
allison how did we do on our priorities this week?
lots of deprecations, some branch merges 20:32
cotto_work lots of deprecated stuff got removed
allison looks good
cotto_work fun times
mikehh still working on some of that
NotFound And lots of examples freed from gone stuff.
allison NotFound: excellent 20:33
what should out priority be this week?
more removing deprecated items and branch merges? 20:34
Coke there's still plenty left.
+1 from me.
darbelo Removals are always good.
mikehh compact_pool_revamp is about ready to merge - tests ok
Tene branch merges? If I'm actually awake some evening this week, I might be able to get my exceptions_refactor branch in a mergable state. Not everything planned finished, of course, but some work. 20:35
allison mikehh: we'll mark that as a branch priority
20:35 bluescreen joined
allison Tene: okay, added that one too 20:36
mikehh bacek++ and chromatic++ have done a lot of work - I just did some testin' and fixin'
allison Our 3-month priority is GC
There are some simple tasks for that that I harvested from tickets 20:37
low-hanging fruit in trac.parrot.org/parrot/wiki/GCTasklist
That's priorities and roadmap 20:38
Questions?
Coke first, since he'll have to go part-way through
<Coke>\tone was rakudo & TT #389 - like I said, jonathan was going to look at it, but it would be nice if we had someone on parrot-side who could also take a look. 20:39
I can take a look (I did the first fixes), other eyes welcome 20:41
<Coke> other was CPAN - is it worth it jumping back in for cpantesters on various platforms. 20:42
darbelo A reference for those of us that don't know how cpantesters works? 20:43
allison There are a set of people running smokes on CPAN
mikehh don't know if our tests work properly on an installed parrot
allison they don't
Coke the tests wouldn't be on an installed parrot.
particle new distros released to cpan automatically smoke and report results via cpantesters
Coke they'd be doing the test bit as part of the build.
allison but, tests are run during the build... yeah 20:44
Coke but we never took advantage of that.
omeone on #tooch
darbelo So, no chages to parrot?
Coke avar on #toolchain suggested it might be worth going back for that.
allison Coke: whoever uploaded the release got the reports
Coke win 2
allison on the down side, PAUSE broke on Parrot pretty much every month 20:45
is there anyone who'd like to take on CPAN packaging like we do for Fedora/SuSE/Debian/etc? 20:46
not here. I'll post the question to the mailing list 20:47
cotto, you had a question? 20:48
cotto_work JimmyZ has requested a commit bit. 20:49
NotFound +1
darbelo +1 # We need more multilinagual users.
particle +1
mikehh +1
NotFound Nagual users?
Coke I think we even already have a cla. 20:50
multilingual, no doubt.
NotFound And win32 users.
allison do we have a volunteer to mentor? 20:51
cotto_work I'll mentor him as much as is needed.
allison sounds good
mikehh I'll help as necessary
allison double-check on the cla before flipping the bit
allison checks, we do have one
japhb: you had a question? 20:53
japhb Actually, I can take it out of #ps, np
allison okay, darbelo? 20:54
darbelo Mine's about GSoC.
Do we have a procedure to get students started?
A recomended workflow, etc. 20:55
allison they generally work on a branch or on a git/mercurial/bzr clone
darbelo I can just jump to coding, but the rest of the GSoC students are new to the commuity afaict.
allison hmm... we haven't done that so far, but I like the idea 20:56
particle we're in the 'community bonding' period.
so everybody hold hands.
allison it's partly up to the mentor, but an email message introducing them to the project could be a good idea 20:57
at least make sure they know how to find us on IRC
darbelo Last year cotto did a good job of keeping me oriented through the process. But I was thinking of a "Here's how the parrot guys like to do things doc."
particle submissions.pod? getting_started.pod? 20:58
darbelo Something that's useful beyond GSoC.
allison darbelo: would you be interested in writing that, since you're closest to GSoC students and to the project?
bubaflub also a list of expectations - last year we kept weekly blog posts during the coding period, and it'd be good for new guys to know upfront that they should setup something if they don't already have it
20:59 bacek joined
allison it can start simple, and grow as we run into things the students find helpful to learn 20:59
cotto_work darbelo: feel free to use whatever's useful from my intro message last year. I was going to start a wiki page (or something) based on it.
bacek ~~
cotto_work afk
darbelo Ok. I'll draft something on the wiki.
allison Did I miss anyone's questions? 21:00
mikehh I had one but it has slipped my mind for now 21:01
allison one question that came up during the week is .gitignore files
several revisions on the idea
is the one we have now workable?
mikehh bacek has it down to a single file at the moment in the top directory 21:02
bubaflub i'm happy with what we have now
21:02 eternaleye joined
darbelo One file isn't that big of a deal, and it helps the git-svn guys. 21:02
mikehh had to add svn properties, maybe better to ignore it
allison that seems a tolerable low-grade addition 21:03
Tene git-svn can generate .gitignore from svn props.
allison what are the advantages of having it checked in?
mikehh i.e. add it to svn:ignore
Coke We either need 0 or 1 .gitignore files. any more and it's annoying. =-) 21:04
but 1? meh.
mikehh for those using git-svn
allison does git keep trying to commit it as a change if it isn't added?
mikehh no you need a specific commit
allison Coke: agreed on no more than 1 :) 21:05
Util q1q (in three parts)
allison not getting much discussion, and I think bacek had to leave 21:06
we'll stick with "one file isn't a big deal" for now 21:07
bacek I'm happy with single .gitignore
particle gitignore is the git equivalent of svn:ignore
it's helpful, as long as it's updated.
+1 to keep it.
japhb A single gitignore is fine. I didn't say anything in the discussion because everyone else was already saying it. 21:08
allison sounds good
Util: your question(s)? 21:09
Util (Copied from #parrot)
PDD19 and book draft ch11 both mention a 2-arg form of the .meth_call directive, where the second arg is RETCONT.
1) Is the 2-arg form actually supported?
2) Are there any examples of the 2-arg .meth_call in anyone's working code?
3) Is there an equivalent non-directive form with RETCONT, (like ` r = obj."method"(x, y, z) ` is a alternate way to write a non-RETCONT method call)?
(and deferring this back to #parrot is fine; I just wanted #ps eyes on the question) 21:10
allison Util: it's callmethod_p_p_p and callmethod_p_s_p 21:11
Util: that is, there are working opcodes for it
Util: but no syntactic sugar
darbelo Do we really need the sugar? 21:12
allison Util: though, I believe the .tailcall directive uses it to pass along the existing return continuation (would have to double-check)
darbelo: not necessarily, but it depends on the use 21:13
Util: what is the use?
21:13 Whiteknight joined
Util darbelo: I don't think we need the sugar; I just wondered if I should be searching for another form in the code. 21:14
allison: doc-checking test was getting a bus error trying to compile the 2-arg example in PDD19. 21:15
I was just researching whether the pdd was out-of-date, or if a second example should be added to the pdd
allison Util: You can try a more complete code example, but my guess is that the .meth_call directive doesn't have a 2-arg version 21:16
Util allison: thanks. eoq
allison Util: on the whole, I'd say it *shouldn't* have one, so might as well correct the docs 21:17
Other questions/comments?
smash i have one if i may
Util allison: I'll have a look at .tailcall, then bring up the removing 2-arg in #parrot 21:18
allison smash: go ahead
Util: sounds good, thanks
smash this past week been trying to compile parrot to run on android phones, the problem is (as everyone is aware) parrot is still not cross-compiled friendly, any plans to address this subject in the future ?
allison yes, it's definitely on the roadmap 21:19
particle there's been an 'parrot on rtems' gsoc project accepted by rtems, hasn't there?
allison we need a good test-case
darbelo bubaflub will be working on that for his GSoC project.
allison particle: yes, and the cross-compile fixes are part of that
smash: if you'd like to wait for the rtems fixes you can 21:20
smash sure, anyway let me know if i can help on that particular subject
allison smash: or, you might want to spend some time with bubaflub to work on android at the same time as rtems
smash sure, i can do that
allison testing the fixes for rtems to see if they resolve all the problems for android would be enormously helpful 21:21
smash aye skipper 21:22
allison Sounds like that's the end of the questions.
Thanks to all, and back to hacking!
21:23 particle joined 21:25 chromatic joined 21:29 NotFound 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!