Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 24 May 2009.
00:07 Whiteknight joined 01:47 cotto joined 05:09 davidfetter joined 08:15 cotto joined 08:16 cotto joined 08:17 cotto joined 08:39 cotto joined 08:46 cotto joined 09:56 rdice joined 11:16 masak joined 11:46 contingencyplan joined 16:04 moritz joined, Util joined, NotFound joined 16:31 pmichaud joined 16:39 davidfetter joined 17:42 Whiteknight joined 18:07 Infinoid joined
Infinoid I've got to leave in a few minutes, so I'll post my report now 18:11
* Released 1.2.0 (with a cast of thousands, thanks everyone for your help)
* A bit of patch mongering, a bit of cage cleaning.
* I've been way too busy overall, I hope to resume parroteering around Wednesday of next week.
1;
18:13 fperrad joined 18:14 darbelo joined 18:19 chromatic joined 18:21 barney joined 18:30 allison joined
pmichaud Hello. 18:31
Whiteknight hello
fperrad hello
barney Hallo
Util hi 18:32
darbelo hola
cotto hello
moritz oh hai
NotFound hola
allison hi 18:33
no chromatic? let's get started 18:34
barney?
barney no report
.enor
allison cotto?
chromatic pong
cotto no report this week, but q1q 18:35
allison darbelo?
darbelo .report decnum-dynpmcs :GSoC
* Removed the prototypes
* Started with the DecNum
* renamed a few things
* Cleaned up most of the build warnings
* Added some more VTABLEs.
* Replaced all MULTIs with VTABLEs. 18:36
* Tuned a few library parameters
.end
allison fperrad? 18:37
fperrad * Lua: add generation of .annotate "file" (with $?FILES)
* Lua: implement io.popen (with pipe)
EOR
allison Infinoid pasted his report early, so it's in the logs. 18:38
NotFound?
NotFound * Fix/implment pipes on unix and win32
* Review some old tickets, closed a few
* Applied some patchs
* Some bug fixing and cage cleaning
q3q
eor
allison chromatic?
chromatic Fixed several memory leaks; there are likely others in PMCs with ATTRs. 18:39
Working on fixing Rakudo memory leaks.
Did some profiling. PGE really, really wants to operate on fixed-width encoded STRINGs. 18:40
We could more than double Rakudo's parsing speed if we did that.
EOR
allison pmichaud?
pmichaud * Rakudo now passing 11,343 spectests (+46 since last week) 18:41
* Released Rakudo #17 on Thursday ("Stockholm", +875 tests since #16)
* Added a "root_new" opcode to make it easier to create PMCs in foreign HLLs
* Migrated PGE, Perl6Grammar, a few other items to use root_new
* Still need to update PCT and NQP to use root_new, investigating this
* Seem to have uncovered a problem with creating PMCProxys in foreign HLLs
* Updated PCT so that it gives a better diagnostic for undeclared variables
* Added qx{} and related quoting operators to Rakudo
* Modified Rakudo to use root_new opcode
* We're starting to recover some speed from the HLL switch
* Updated/rewrote Rakudo's ROADMAP
EOR
allison Util? 18:42
Util * Wrote Trac ticket report 16 (Parrot issues affecting languages, by urgency and language) as requested in last #ps meeting.
* Opened&closed TT #708 - Fixed Trac ticket report {8} (Active Tickets, Mine first); it had never worked as advertised. The original (faulty) SQL code, if anyone wants it, or disagrees with my changes.
* Created TT #688 for the pbc_to_exe issue. Brain-dumped history into ticket. Committed patch for GCC. Worked on patch for MSVC; should commit today. I am leaving Non-MSVC_Non-GCC compilers on the original codepath, pending a call for testing on those platforms.
* Working on new issue (no ticket yet): On Win32, huge strings printed by Parrot do not appear in the console output.
* Working on new ticket for last Tuesday's GC bug that makes `parrot_config --dump` segfault on Darwin.
EOR
pmichaud Util++ # nice work
Util glad to help! 18:43
allison Whiteknight?
Whiteknight GC:
* Another GC-related cleanup branch. Cleaned up most of the GC internals
* Starting serious prep work on an Incremental GC core based on the new GC internals
Asynchronous IO:
* Started prototyping some AIO-related stuff. Learned quickly What Not To Do
* Proposed some PDD22 changes to the list. Hoping for more feedback, will prepare a draft soon.
* Serious preparations for AIO, hoping to get started on the implementation this week.
Docs:
* Assorted book writing, trying to fill in empty sections and clean up messy ones
* Assorted cleanup and documentation work
Misc:
* Fixed a problem relating to morphing a PMC to a PIR-defined Object type. Reported by Coke++ and with help from Allison++
* Lots of tasks and tickets blocking on PCC refactors.
Queue 2 Questions.
allison allison? 18:44
chromatic hopes you have a guard condition.
allison - Most of the week spent on the book.
- Decided to scale it down to a small book about PIR. (The book isn't much good if all my development tasks stall finishing it.) The PIR chapter was over 100 pages, plenty for its own book, and much saner split into separate chapters.
- Should have the final PDF ready for proofreading in a couple of days.
EOR
Whiteknight allison++ 18:45
allison did I miss anyone?
moritz me, but I don'T have a report today anyway ;-)
18:45 PacoLinux joined
allison questions, cotto had 1 18:46
cotto Given the recent availability issues with then plusthree-hosted smolder, I'd like to know about the feasibility of hosting it with everything else on parrot.org.
allison cotto: likely possible 18:47
cotto: do you know what resources it needs?
cotto no, but I can look into it
allison we can check with our admins at osuosl
sounds good, let us know what it needs and we'll find out if parrot.org can host it 18:48
cotto I'll send something to the list.
eoq 18:49
allison whiteknight had 2 questions?
Whiteknight First: (TT #470) the branch_cs opcode: Love it or leave it?
allison looking... 18:50
18:51 particle joined
allison Oh, blech! Kill it. 18:51
Whiteknight okay, thanks. Next question:
Propose adding a PObj flag "PObj_uses_malloc_attrs_FLAG" to automatically deallocate Parrot_*_attribute structures in the GC. Thoughts? 18:52
chromatic Alternative: smarten Pmc2C such that it automatically generates mark() and destroy() VTABLEs as necessary.
allison prefer chromatic's solution 18:53
Whiteknight Okay, thanks. EOQ
allison other questions?
pmichaud I have a Q.
allison go ahead 18:54
pmichaud In an earlier #ps (I forget which), we had discussed the possibility of requiring ICU with Parrot. Doing so requires a deprecation -- are we likely to require ICU?
allison yes, there's a good possibility of requiring it for 2.0 18:55
NotFound We are in fact requiring it except for trivial tasks, I think
allison I'd like to have reports from various plaforms making sure it works before we pull the switch 18:56
but, we can enter it as a deprecated item in 1.4, require it in 1.5 and see what feedback we get
pmichaud does the "pull the switch" decision need to be made before 1.4 , or do we just put in a deprecation notice saying we might pull the switch?
okay.
allison yeah, a deprecation item along the lines of "plan to require ICU in 2.0" 18:57
NotFound I have 4 questions
pmichaud Also, I have a comment to 18:40 <chromatic> We could more than double Rakudo's parsing speed if we did that.
allison pmichaud's comment, then NotFound 18:58
pmichaud Rakudo already switches the source to a fixed-width format prior to parsing, when it can. We'd only see a parsing speed improvement for Perl 6 source code that contains non-ascii characters.
(typically « and », which aren't that common yet.)
chromatic Does that same rule apply to building parts of Rakudo? 18:59
moritz « and » are Latin-1 - couldn't that generalized to Latin-1 data?
pmichaud chromatic: NQP assumes ascii as well, so actions.pm is likely already as fast as it's going to be.
the grammar.pg (Perl6Grammar) is indeed utf8, so fixing Perl6Grammar would give us a speed improvement in building that component of Rakudo. 19:00
chromatic I made HLLCompiler transcode actions.pm to UCS-2. Much faster.
pmichaud I'm a bit surprised if actions.pm is faster -- perhaps some utf8 chars were recently added.
chromatic Or maybe it was grammar.pg. Let me check.
pmichaud grammar.pg I'm sure would be faster. Your mail post said grammar.pg 19:01
(and Perl6Grammar)
chromatic Whatever produces src/gen_grammar.pir
pmichaud Yes, that's grammar.pg/Perl6Grammar
I agree that updating Perl6Grammar will make the generation of gen_grammar.pir faster, but that doesn't (afaik) translate into a faster Rakudo. 19:02
Still, it's worth looking into what the requirements are for using ucs-2 (e.g., do we need ICU to be able to do that) 19:03
chromatic I'll do more benchmarks, but everything I've seen shows that it spends a lot of time getting the next codepoint.
pmichaud are you benchmarking the creation of rakudo itself, or rakudo execution?
chromatic Mostly the creation, but I'll look at execution if you can suggest some likely p6 examples. 19:04
pmichaud Beyond improving the code generation for actions.pm, I haven't worried too much about Rakudo generation time.
and as I mentioned, parsing p6 code already does fixed-width when it can transcode to ascii 19:05
(moritz: yes, we could potentially transcode to latin-1... but we run into some other issues when we do that)
end of comment 19:06
allison NotFound, you had questions?
NotFound TT #680: add a setsdin opcode, or deprecate setstdout, setstderr, getstdin, getstderr and getstdout?
allison add setstdin
NotFound TT #707 StringHandle interface 19:07
allison looking...
we may actually be deprecating StringHandle, to speed up filehandles 19:08
was there a use case that prompted the ticket?
NotFound Just looking at improving that pmc. 19:09
allison aye, it was a rather quick proof of concept
Infinoid q2q
allison the only way it's ended up being used is as an example for mod_parrot, but he wrote his own separate PMC 19:10
NotFound So I can play with it without risk of breaking someone's code
?
allison NotFound: yes, certainly
19:10 rdice joined
NotFound On. Next: Can TT #661 be closed? 19:10
allison is the new win32 pipe well tested? 19:11
NotFound Or, is the current state of pipes enough for rakudo needs?
pmichaud I'm fine with closing it -- Rakudo is using write-to-pipe just fine. I haven't tried it on Win32 though.
allison and, did we resolve the problems where the linux pipe was leaving a pile of dead processes around?
NotFound allison: yes, that's fixed and the causes well known 19:12
allison ok, if someone can test Rakudo's write-to-pipe on win32, the ticket is closable
NotFound Last question: Can RT #48034 be closed? 19:13
pmichaud (did we ever get a ticket opened for fixing Parrot's buffered I/O? lists.parrot.org/pipermail/parrot-d...1369.html)
allison NotFound: does the test pass now? 19:14
NotFound allison: AFAIK yes, but the mixing of files in the ticket confuses me 19:15
allison or, are you asking for more of a detailed review of the fix that was committed?
Whiteknight pmichaud: like TT #418? 19:16
NotFound I just don't understand well what that programs and his tests are doing 19:17
allison NotFound: looks like it's fixed (very old issue), ticket can be closed
Whiteknight oh no, sorry. I'm thinking about the wrong issue
NotFound Ok, end of my questions
allison pmichaud: that message looks like it's about calling conventions 19:18
oh, I see, but the subject is buffered I/O 19:19
the real fix for that issue is killing StringHandle, and switching I/O ops back to direct function calls instead of method calls
pmichaud I'm just curious if there's a ticket for it :-) 19:20
allison pmichaud: not that I've seen
but worth searching
Whiteknight do we kill StringHandle, or write it as a subclass of FileHandle?
or better yet, write both as a subclass of an abstract IO PMC type that the functions operate on 19:21
allison Whiteknight: it doesn't make any difference, either would require using methods instead of functions
Infinoid that leads directly into one of my queued questions.
allison (to allow for polymorphism)
Infinoid, go ahead with your questions 19:22
Infinoid ok. I want to significantly improve the IO PMCs
For starters, I want to extract the relevant portions of FileHandle into a base Handle class (which Socket also inherits, and which Pipe and StringHandle can also inherit)
Whiteknight you and me both
Infinoid I also want to implement a Select class, similar to perl5's IO::Select.
In fact, if left to my own devices, the result will look a lot like perl5's IO::* heirarchy.
Does that seem reasonable to you guys? 19:23
Whiteknight Infinoid: I've got a "select" type coming in the AIO work, so that's coming soon
Infinoid WANT
allison there's not really any duplicated behavior between sockets and filehandles
Infinoid the basic read/write/close methods are the same, on unix at least
19:24 barney joined
Whiteknight allison: I think there are plenty of abstractions to be made, especially if we abandon some of the classical unix conventions 19:24
Infinoid my problem with using FileHandle as a base class is that FH has seek() and tell() and open(), which aren't relevant for sockets
or pipes for that matter.
allison having methods with the same names that do completely different things isn't really a grounds for inheritance 19:25
<shrug> it's hard to sell an idea over IRC
how about you write it up in more detail for the list
then the wider group can talk about it
Infinoid Can do. How do I phrase it? An RFC sort of thing? A patch against PDD22?
allison the patch to pdd22 will likely bog you down in details and obscure the advantages of the idea 19:26
Infinoid ok. next question: 19:27
Is there some kind of policy for committers updating NEWS (especially for branch merges), or is it something the release manager is normally expected to do (periodically or at the last minute)?
Having the release manager do it constitutes a huge percentage of the overall release work, and I'm sure I didn't do some things justice
chromatic Committers should update it, but we rarely do.
Infinoid Is it worth calling for NEWS updates here in #ps to act as a reminder? 19:28
or something like that
allison yes, it's a good idea for all committers to update it, but not necessarily practical
Infinoid it's just something I noticed which I think we can scale better
allison another possibility, since the release manager knows they're assigned to the task before the month starts, is to have the release manager track commits all month and add to NEWS
spinclad releaser's checklist item: call for NEWS updates
Infinoid true. if I didn't take over the process at the last minute, I could have done a much better job there 19:29
NotFound 'There's no justice.' Death sighed. No, he said, there's just me.
allison so, it's less of an overwhelming task right before the release, and more of an all-month preparation
pmichaud Normally there's a call for NEWS updates prior to release -- that didn't happen in May.
(at least, I didn't see one)
Infinoid oh well, I'll try to do better next time :) 19:30
EOQ
allison Infinoid: you did quite well, thank you :)
NotFound What happened to our lost release manager?
pmichaud all that said, if a committer wants his/her work to be reflected accurately in NEWS, he/she should make it happen :-)
Infinoid allison: thanks for all your testing, you made things *much* easier.
allison NotFound: PhD demands 19:31
pmichaud and yes, Infinoid++ for picking up the release as quickly as was done.
Whiteknight Infinoid++
NotFound Infinoid++
pmichaud It shows how robust the Parrot release management has become.
Util Infinoid++
allison speaking of which, our next release manager is Whiteknight 19:32
Whiteknight <insert evil laughter here>
allison (I didn't bother to check last month until the day before the release)
pmichaud release date is June 16? Just before PVMW?
Whiteknight yeah, I'm on top of it and have nowhere to disappear to
pmichaud Excellent.
Whiteknight pmichaud: yup, right before YAPC 19:33
allison pmichaud: you had a suggestion for our next weekly development priority? 19:34
pmichaud Whatever my suggestion was two weeks ago, yes.
I forget off the top of my head.
allison me too 19:35
pmichaud profiling.
allison sounds good
pmichaud that's on the roadmap for 1.4, and we haven't made much progress on it.
(iirc)
chromatic I wrote part of a grant proposal for that.
allison set as the weekly priority
Roadmap review: trac.parrot.org/parrot/report/14 19:36
Mainly I just want to move tasks that aren't a priority for 1.3, so we can focus on the ones that are 19:37
Whiteknight has anybody heard from kjs recently? 19:38
allison the HLL tasks are all a priority
pmichaud We're making very good progress on HLL stuff.
I expect it to be well in place for 1.3
(Tene++ for that)
allison excellent! 19:39
packfile pmcs, config probes, vtable swap, and pirc are not a priority and can be moved
the extending/embedding api needs to be defined 19:40
but, lower priority than HLL stuff
NotFound I'm intermitently doing some work on embedding
allison NotFound: great 19:41
NotFound Is there some project using embedding other than mod_parrot?
allison not really 19:42
Whiteknight wasn't Parrot::Interpreter using it?
allison Parrot::Embed?
Whiteknight ah, that's what I was thinking of
barney Padre probably uses embedding 19:43
NotFound Ah, yes, I can take some look at it... even if XS is not one of my favourite things.
allison thanks! 19:44
any other questions, comments, discussion?
pmichaud none here. 19:45
allison thanks everybody, talk to you next week
Whiteknight later
19:45 Util left 19:46 Infinoid left, chromatic left, fperrad left, pmichaud left, PacoLinux left 19:49 darbelo left 19:54 NotFound left 19:55 eternaleye joined 20:25 japhb joined 20:28 japhb_ joined 21:43 Whiteknight joined 23:24 eternaleye joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!