Vision for 2.0: Production Users | Priority for 1.8: Testing Sprint | Priority for this week: close RT tickets | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 8 November 2009.
02:04 integral joined 04:18 kid51 joined
kid51 kid51's report 04:18
* Moved all remaining tickets in RT that were owned by 'nobody' into Trac.
* Began work on eliminating dependence on init::defaults from configuration step tests
** configtests branch is main location for this
** but in addition we need to begin to modify config steps after init::defaults to not do look-ups on Perl 5 %Config
** was able to pluck some low-hanging fruit by transforming '$conf->data->get_p5('OSNAME')' to '$conf->data->get('osname') in most locations after auto::arch -- the config step where 'osname' is finally determined: see TT 1194 04:19
** two Parrot tests do look-ups on Perl 5 %Config: see TT 1234 and 1235
** auto::format needs to be modified to avoid this: see TT 1236
** config/gen/platform.pm needs to be reworked so that 'platform' is determined at same time as 'osname'; ticket to be opened after above tickets close
** medium-term objective: no get_p5 calls or lookups to %Config after config step init::default
* libjit
** Does the libjit_framebuilder branch completely supersede the auto_libjit branch? If so, then I'll remove it.
** I don't have libjit installed on either box, so I can only report that libjit_framebuilder does no harm in libjit's absence
* Testing:
** It seems that each week we are merging in a branch (or two) that touches a large number of source code files. We need to test these more thoroughly, or, more precisely, in more environments.
** Specifically, we seem to get a lot of failures on Linux/amd64 that we don't get on Linux/i386.
** And our Smolder reports on Win32 (mostly from Fran�ois, I think) are showing too many failures this close to release.
** Have all issues from pcc_reapply merge been settled? We still have TT 1132 outstanding
* Plan: mainly continue to work on configtests
* Blocker: Family issues likely to escalate in coming weeks.
EOR
08:55 davidfetter joined 12:00 kid51 joined
kid51 libjit_framebuilder branch: Have spotted one codingstd error. Am in process of testing correction. Otherwise, passes 'make fulltest' on Linux/i386 and Darwin/PPC. 12:01
12:03 davidfetter left 12:54 bluescreen joined 13:12 bluescreen joined 14:08 PerlJam joined 16:01 pmichaud joined 16:41 darbelo joined 16:48 plobsing joined
plobsing What I've Done: 16:49
* merge pcc_reapply functionality into libjit framebuilder
* new branch, libjit_framebuilder supercedes auto_libjit branch
* tracked down the bug in libjit framebuilder on i386 that chromatic found
* bug is in libjit 16:50
* workaround in place
* working on a patch to libjit
* tried to make a libffi framebuilder
* framebuilder/nci current implementation makes it difficult
* talked to japhb about weaknesses in NCI system
* details of problems, proposed fixes on the wiki @ NCITasklist
* thought about lorito
* came up with some ideas, a rough plan for a prototype
What I Plan To Do (short term):
* help with libjit_framebuilder merge (my top priority)
* re-work framebuilder/nci system to give framebuilder implentations more autonomy
* take management out of src/nci.c
* implement a libffi framebuilder
What I Plan To Do (longer term):
* implement NCITasklist proposals (in branch(es))
* time frame: some changes will likely require a deprecation cycle
* implement a prototype of what I think lorito should look like 16:51
* mostly interested in backends
* planned backends: llvm, libjit, and of course C
EOR
japhb DONE: 16:55
* Finally starting to feel better, yay!
* Talked at length with Plobsing++ re: current NCI problems
* Brain dumped to trac.parrot.org/parrot/wiki/NCITasklist
WIP:
* Converting Plumage to make use of new NQP-rx features
* Pushing the envelope of what NQP-rx has
* Exchanging feature requests with pmichaud++ via wiki.github.com/perl6/nqp-rx/plumage-requests
* Moving Glue.pir functionality to Util.nqp where possible
* Further expanding Util.nqp to cover more common functionality
* Cleaning up and expanding Plumage's test suite
NEXT UP:
* More of everything in WIP section
BLOCKERS:
* Several local Plumage branches blocked waiting for various NQP-rx features
* Will only rarely be able to make #ps meetings in person for next few months due to time change causing scheduling conflict
EOR
darbelo Behind: * Not much. Life got in the way. * Removed a VTABLE. chromatic reported a 1% performance improvement. * Helped plobsing get his frame builder branch into the repo. 17:05
Ahead: * Not much. * Might kill other under-used VTABLEs if the gains are worth it. * Investigate refactoring IMAGE_IO into a PMC.
Standing in the way: * Life.
.end
17:45 whiteknight joined 17:50 NotFound joined 17:52 kj joined
kj Report: migrated a couple of tickets from RT to Trac. End of report. 17:53
17:53 barney joined
whiteknight WHAT I DID: 17:55
(pla) Add a few random features and more tests
(pla) fix installation, which apparently got broken at some point
(matrixy) pla_integration branch builds and runs tests (but doesn't pass all of them). Work to do
(parrot) talking about JIT, GC, etc. Talk is cheap. 17:56
WHAT I WILL DO:
(pla) Might work on a CharMatrix2D PMC type to implement Matrixy's idiosyncratic string handling
(matrixy) Continuing integration work, trying to get the branch working and merged
(parrot) some optimization avenues I want to look into. Will try to support bacek++ and chromatic++ on the CallSignature stuff
(parrot) testing plobsing++'s branch libjit_framebuilder. Hopeing to get that greenlighted for merge (or, hoping to spark good discussion)
(parrot) need to put some of the JIT plans on the wiki now, so we can start ironing them out
(all) Lots of misc blogging to catch up on
WHAT I AM BLOCKING ON:
* Not enough time
EOR
17:56 Util joined
barney WHAT I DID: 17:58
Started on NEWS for 1.8.0
EOR
dukeleto What I did: 18:02
* Reviewed and applied some patches from bubaflub++
* Worked with kiwichris on the RTEMS port
* Did research into real-time GC algorithms for the RTEMS port.
* Started a new HLL, Kea (Factor on Parrot) : github.com/leto/kea, which will be implemented in NQP-rx and PIR
* Keeping up with Plumage and nqp-rx development
What I will do:
* Review and apply more patches from bubaflub++
Blocking on:
* Time to do stuff.
I will not be back for ~1 to ~1.5 hrs from now.
NotFound What I did: 18:04
* Lots of work on Winxed.
* Fixed NCI PCC problem with 'p' type, I have a question about that.
* TODO'ed the NCI test that creates nci_test linkage problems.
* Fixed problem in parrot-mysql module following Tene++ patch.
What I will do:
* No fixed plan.
q2q
EOR
18:06 fperrad joined
fperrad # What I did this week : 18:08
* library Configure.pir : a genfile()
+ with variable interpolation
+ slash/backslash substitution (for Windows)
+ conditioned line #IF/UNLESS/ELSIF/ELSE
+ with expression evaluation || OR && AND ! NOT (expr) != ==
* library distutils.pir (Python like) :
allows build/test/install/clean
from a setup.pir script
without Makefile and remove a lot of dependencies
handles : dynops, dynpmc, PGE, TGE, NQP, PBC_TO_EXE, ...
* experiments these libraries with : Lua, Markdown, MT19937, Wmlscript, XML
* converts tools/dev/mk_language_shell.pl with these libraries
# What I want to do : 18:09
* fix Plumage on Windows
.eor
18:10 fperrad left 18:12 allison joined 18:18 whiteknight joined
allison Last week: 18:21
- Had some great process conversations this week.
- Working my way through a list of smallish tasks. Converted my private TODO text file into a public wiki page AllisonTasklist, to help avoid blockers (people can pick up or help with tasks, or vote for highest priorities).
- Closed RT tickets.
Next week:
- Knock a few more tasks off the list.
Blocking on:
- Time.
EOR
18:26 mikehh joined
Util # Done: 18:27
* Reviewed patches from bubaflub++ ; TT#1217, TT#1218.
= High quality Perl->PIR refactoring, but invalid; false negatives unless separate instances are used.
# Plan for this week:
* Finish the two tickets; possibly working with author to re-write.
* Play catch-up on tickets.
# Blockers:
* Tuit shortage
* Tropical Storm Ida
.end
mikehh Just testing and fixing codetest failures etc. 18:29
18:29 chromatic joined
chromatic Hello, everyone. 18:31
whiteknight howdy
allison hi
cotto_work hi
barney hi
pmichaud hello 18:32
Util hi
whiteknight actually has to disappear. Will backlog
chromatic Let's review last week. How did we do on our high level goals? 18:33
mikehh hi
allison was our high-level goal closing RT tickets? 18:34
allison missed last week, so had to ask about priorities after
dukeleto back!
chromatic As far as I can tell, yes. 18:35
mikehh a lot of tickets were closed
chromatic Okay, let's pick goals for this week. 18:36
We missed our hackathon on Saturday; how about a new one this Saturday>
mikehh fixing remaining failing tests before release
allison what's the focus of the hackathon?
dukeleto i would like to pick a directory in t/ and help people translate tests to PIR
allison HLL issues?
chromatic My suggestion: opcode testing.
dukeleto warnings.t must be fixed
t/src/warnings.t, that is
chromatic bacek's PMC header moving branch fixes it. 18:37
mikehh get the fix in
I am having a couple of testr failures 18:38
chromatic How about a testing hackathon then?
dukeleto chromatic: t/op/, then ?
chromatic++ # testing hackathon
chromatic trac.parrot.org/parrot/query?statu...estone=1.8
dukeleto will volunteer to herd cats in the right direction for tests 18:39
mikehh a few skipped tests now pass for me but not sure on other platforms eg win32, darwin
allison testing hackathon would be a good fit for the 1.8 milestone tasks 18:40
chromatic Let's make it so then.
NotFound Sorry, got distracted. Hola.
chromatic In other news of focus, did everyone see Patrick's message to the list last week about what Rakudo needs?
darbelo Some of his needs need deprecations. IIRC. 18:41
cotto_work q1q 18:42
chromatic They do, but I think we can still break them down into concrete design and implementation tasks.
mikehh q1q 18:44
darbelo Separating 'actionable now' from 'deprecation needed' items should help people looking for tasks.
cotto_work Is there a wiki page for pmichaud's list? 18:45
chromatic More than that, I suspect if we made a wiki page for "How do we improve speed?", we could brainstorm into concrete tasks.
There's no wiki page yet; do we have a volunteer to make one?
cotto_work I will if I can find his message. Some posts to parrot-dev don't get to my work account. 18:46
dukeleto is excited about a testing hackathon
cotto_work q1q (2 total)
darbelo q1q
pmichaud lists.parrot.org/pipermail/parrot-d...03223.html 18:47
chromatic Thanks, pmichaud.
Let's move on to questions then. cotto_work?
pmichaud the most beneficial ones at this point would be #1, #3, #5, and #4 (in that order) 18:48
afaict, none of those would absolutely need deprecations
cotto_work I was going to remove all the bitwise VTABLE functions, but the bitwise ops depend on them. Are there any objections to deprecating them now so the bitwise ops and VTABLE functions can go away post 2.0? 18:49
chromatic How do users perform bitwise operations without the ops?
darbelo We could add methods.
allison darbelo: bitwise operations have to be fast 18:50
but, do they have to be overloadable?
cotto_work Are they expected to be common?
NotFound Methods to do bit operations pn Integer? And you want speed? =:o
allison could be, get_integer, perform bitwise operation
if a bitwise operation always has the same behavior 18:51
cotto_work If they're needed, there's always dynops
darbelo NotFound: People who want speed should avoid Integer anyway. 18:53
allison cotto: sounds good, my vote's on 1) deprecate bitwise ops and vtable functions, 2) implement bitwise dynops that directly implement the most common bitwise behavior
NotFound darbelo: or maybe avoid parrot.
cotto_work Great. I'll put that in a tt and add a deprecation notice.
next q: Can the Parrot VM Workshop Google group be shut down? It's just spam at this point. 18:54
allison cotto: yes, but I don't know who owns that
cotto_work For some reason, I thought you did.
mikehh pmichaud? 18:56
allison I did create several of our google groups, but not that one. IIRC, ownership is mentioned somewhere in the regular pages for a Google group, will dig for it.
chromatic darbelo, question?
darbelo Can we deprecate the image_io structure and refactor it into a PMC? 18:57
pmichaud (when doing the bitwise ops, please let's not have a repeat of what happened with converting Random PMC into a dynop)
allison pmichaud: for reference, what happened with the Random PMC?
pmichaud the random pmc was removed before the replacement dynops were available 18:58
(in a release)
mikehh broke rakudo
allison pmichaud: ah, yes, let's avoid that
NotFound We must add to our deprecation guidelines: "Provide an alternative *before*"
allison preferably, have the dynops in place before 2.0
NotFound: not necessarily, some things are deprecated to be removed, not replaced
dukeleto um, it was replaced like the same day 18:59
pmichaud dukeleto: yes, but there was no release where both were available.
NotFound allison: in that case the alternative is have other way of doing the thing,
dukeleto i had the replacement random pmc ready, there were build issues that slightly delayed it working
pmichaud and since parrot currently expects hlls to target releases, that is a problem.
18:59 whiteknight joined
dukeleto pmichaud: yes, you are correct 18:59
allison NotFound: I meant cases where we're really removing a feature entirely. the "don't do this anymore" case (which is semi-rare, but does happen) 19:00
NotFound: but agreed in the general case
NotFound allison: there always can be exception, but must be exceptional.
chromatic Now back to darbelo's question. 19:01
What's your motivation for this, darbelo? Correctness? Ease of use? 19:02
darbelo It would help clean up the PMC freeze/thaw process. Also that claims to be "a stand in for a pmc to be written later" 19:03
Since about 2003 IIRC
cotto_work good punchline
whiteknight +1 from me. Anything we can do to clean up and standardize the freeze/thaw process would be great
and document it
chromatic Agreed.
cotto_work +1
chromatic Can you figure out how the PMC interface would look?
dukeleto +1 for darbelo doing stuff 19:04
whiteknight let's draft it up on the wiki
darbelo The struct has a 'fake' vtable it uses to dispatch to the functions in pmc_freeze.c
I'd aim to provide the same interface or something reasonably close. 19:05
chromatic Excellent.
mikehh, question?
mikehh was any decision made on pmichaud's new nqp stuff - as in moving into core or whatever? 19:06
I seem to remember some earlier discussion regards nqp and lorito 19:07
pmichaud ah, that's my fault.
yes, a decision was made.
allison mikehh: yes, ship a copy in core, main repo separate
pmichaud the nqp stuff will go into ext/
I have a proposal I need to write up for that, but I can summarize here
I'd like for nqp-rx to go in as ext/nqp/
I would like for it to build a 'parrot-nqp' binary. 19:08
I would like for the existing 'parrot_nqp' binary to simply go away.
The old NQP library will still be available as NQP.pbc, same as in the 1.4.0 release
(only the 1.7 release had the parrot_nqp binary, so it can disappear w/o needing deprecation)
if this needs a proposal on the wiki or mailing list, I can do that. 19:09
allison pmichaud: would it be useful to you if we go ahead and add build/bin and build/lib, for nqp to build into?
pmichaud: these would be the directories in the build directory that parallel the install directories 19:10
pmichaud allison: it might. But truly, parrot's build of NQP is simply compiling four .pir files into .pbc, and then running pbc_to_exe on one of the .pbc
whiteknight q1q
pmichaud so NQP doesn't need too much of a staging area. If you want me to have the binary and .pbc's go into those directories, that can be done. 19:11
however, for testing I think the .pbc's would still need to go into runtime/parrot/library in order to run nqp-rx's test suite
allison pmichaud: easy enough, and we can move the build results when we move everything else (either way is workable)
pmichaud my preference would be to just get it working within the existing build framework and let someone else take care of setting up the new framework
mikehh++ # thanks for remembering to ask about nqp 19:12
allison sounds good
pmichaud okay, I'll do that in the next day or so
thanks
chromatic NotFound, question? 19:13
NotFound 'p' in NCI. I've fixed it to convert PMCNULL to NULL in argument, and return NULL for PMCNULL. I wan't to know if this is the intenede usage, and put it clearly in the pdd. 19:14
It worked that way before PCC refactor, BTW 19:15
allison for now the intended behavior for NCI is "exactly duplicate the old behavior" 19:16
NotFound Eh.., is retutning PMCNULL for NULL, of course.
allison we may change it later, but that'll be an RFC, and something to talk about around the group
NotFound allison: I think we can't left that undocumented, that makes NCI almost useless. 19:17
allison the old behavior makes NCI almost useless? 19:18
or the new behavior does? 19:19
or not documenting the old behavior does?
NotFound Not documenting does.
allison then let's document it
NotFound That's what I asked.
allison ticket?
would you like to take a stab at phrasing for the PDD? 19:20
NotFound No ticket, I realized the problem just yesterday.
cotto_work q1q
allison okay, cool, let's get a ticket and I'll review a patch 19:21
(if I don't see the patch, poke me)
NotFound After locating why parrot-mysql was failing, and was failing because changed a behavior that was not documented and not tested.
allison ah, mention the need for tests in the ticket too
chromatic NotFound, second question?
NotFound allison: I've already do the fixed and the test, the only remaining task is document. 19:22
Forget the second, I'll better write a proposal.
allison NotFound: excellent!
NotFound EOQ 19:23
chromatic whiteknight, question? 19:25
whiteknight on the wiki we had two tenative hackathons listed: PIRC (oct 24th) and JIT (Nov 21) 19:26
the PIRC one obviously has since passed. Do we still want to focus on these two issues?
and if so, when?
JIT stuff may be coming to a head this month, so I suggest we keep that on the near-term schedule 19:28
chromatic Thoughts?
whiteknight WARNOCKED 19:29
EOQ
chromatic cotto_work, question? 19:30
NotFound Somenone is working on pirc?
cotto_work There's an ambiguous deprecation item that mentions reviewing and cleaning the list of VTABLE functions. Can we tighten that or just eliminate the item?
trac.parrot.org/parrot/ticket/866
chromatic Let's tighten it.
cotto_work That tt lists some *possible* deprecations. 19:31
Actually, I guess it wouldn't be a bad idea to just lock down what's there and start a new TT for post-2.0 VTABLE deprecations. 19:32
chromatic Yes, let's get specific.
mikehh NotFound: kj/kjs
cotto_work also, is it fine to add a tt deprecating both the bitwise ops and VTABLE functions or should that be two tickets? 19:33
allison cotto: sounds combinable 19:34
chromatic Migrating ops to dynops seems like one ticket, removing VTABLE functions sounds like another.
allison or at least link the two tickets 19:35
cotto_work single ticket submitted 19:36
eoq 19:37
chromatic Other questions?
darbelo What's the procedure to nominate someone for a commit bit?
chromatic 1) have that someone submit a CLA 19:38
2) have other people say "Wow, that person should get a commit bit!"
3) nominate in #ps
4) mentor
pmichaud see docs/submissions.pod
"Getting Commit Privileges"
chromatic Other questions? 19:40
Okay, let's call it a week. 19:42
Gentle reminder: RakudoTaskList on the wiki.
RakudoTasklist, that is.
cotto_work bye 19:44
19:45 Util left, darbelo left 19:47 whiteknight left 19:51 pmichaud left, plobsing left 19:52 NotFound left 19:53 chromatic left 20:25 PacoLinux left 20:26 masak joined 20:48 mikehh joined 21:14 bluescreen joined 21:29 mikehh joined 21:53 mikehh joined 22:08 Whiteknight joined 23:41 wknight8111 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!