Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-08-17

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

All times shown according to UTC.

Time Nick Message
00:41 kid51 joined #parrotsketch
00:42 kid51 kid51's report
00:42 kid51 DONE/IN PROGRESS
00:43 kid51 TT #1726: documentation for functions in .pmc files:
00:43 kid51 * 1. Merge tt1726_pmc_pod branch into trunk.
00:43 kid51 * 2. Added the POD framework for most of the 23 files identified as having functions which lacked documentation.  Where possible, converted inline comments to POD.
00:43 kid51 * 3. Used 'svn annotate' to identify Parrot committers who had previously contributed to these .pmc files; sent them email requesting assistance.  NotFound++ for replying to two of my requests.  mikehh++ for adding docs even without my prodding him.
00:43 kid51 Other:
00:43 kid51 * 1. *Several* times had to run 'tools/dev/mk_packfile_pbc' to get t/native_pbc/*.t to pass on Darwin/PPC.  (This is getting tiresome.)
00:43 kid51 * 2.  Made sure tools/dev/pprof2cg.pl gets installed -- but not as an executable.
00:43 kid51 * 3. Ran 'make fulltest' to PASS on Linux/i386 and Darwin/PPC at r48536
00:43 kid51 TO DO
00:43 kid51 * TT #1725: clarify headerizer documentation:  For the time being I will probably abandon my attempt to refactor this, write tests, i.e., give headerizer.pl the full Phalanx treatment.  I will simply try to get the docs in better shape.  Spare tuits have to go to learning Rakudo Star.
00:43 kid51 QUESTIONS/COMMENTS
00:43 kid51 * 1. There was discussion on #parrot as to the desirability of writing documentation *in POD format* for *static* functions in the .pmc files (TT #1726).  It was argued that such functions should be documented merely by inline comments on the grounds that they are "implementation details."
00:43 kid51 ** I disagree.  If *all* our functions were documented in *all* our source code files, we could have the luxury of deciding which functions should go into POD and which can be relegated to inline comments.  But we are so far away from that that I believe we should err on the side of getting all functions documented in POD format, which is the only format for which we have (somewhat) good tools to detect the presence of
00:43 kid51 documentation.  The overwhelming majority of static functions in the TT #1726 files lacked comments as well as POD up until last week.
00:44 kid51 ** Another case where the perfect is the enemy of the good.
00:44 kid51 EOR
01:08 pgollucci joined #parrotsketch
01:59 whiteknight joined #parrotsketch
11:55 kid51 joined #parrotsketch
17:45 pgollucci joined #parrotsketch
17:49 NotFound joined #parrotsketch
18:04 pgollucc2 joined #parrotsketch
18:14 atrodo joined #parrotsketch
18:17 NotFound What I did:
18:17 NotFound -parrot
18:17 NotFound * A bit of cleaning and nano-optimization in hashes
18:17 NotFound * Miscellaneous code cleaning and POD improvements.
18:17 NotFound * Added tests for several uncovered cases
18:17 NotFound * Avoid mark when empty in Capture and in string and pmc arrays.
18:17 NotFound -winxed
18:17 NotFound * Implememt and use "using static", plobsing++
18:17 NotFound * Fix constructor calls and use more constructors in stage 1 compiler
18:17 NotFound What I will do:
18:17 NotFound No plan, short of available time
18:17 NotFound EOR
18:25 pgollucci joined #parrotsketch
18:33 pgollucci joined #parrotsketch
18:55 ash_ joined #parrotsketch
18:56 pgollucc2 joined #parrotsketch
19:01 pgollucci joined #parrotsketch
19:15 tcurtis joined #parrotsketch
19:21 pgollucci joined #parrotsketch
19:22 whiteknight joined #parrotsketch
19:22 whiteknight WHAT I DID:
19:22 whiteknight * Final evaluation for Chandon's GSoC project. Reading over all his code and stuff
19:22 whiteknight * Tracking down some errors in Kakapo. With help from Austin_Hastings++ it's working well enough to run the PLA unit tests
19:22 whiteknight * Fixed several bugs in PLA, including a really nasty inferior-runloop one
19:22 whiteknight * Started creating Rakudo bindings for PLA.
19:22 whiteknight * Massive refactor of the PLA test suite, hoping to start adding many more tests soon
19:22 whiteknight * Added implementation of GEMM for PLA complex matrix type, needs testing
19:22 whiteknight * Got nominated, and did some nominating, for PaFo board elections
19:22 whiteknight WHAT I WILL DO:
19:23 whiteknight * PLA test suite is filled with broken and TODO'd tests, so going to rectify that
19:23 whiteknight * Other tweaks and changes to PLA
19:23 whiteknight * Start a new module (Math::LinearAlgebra?) for Rakudo using PLA
19:23 whiteknight WHAT I AM BLOCKING ON:
19:23 whiteknight * Nothing
19:28 PacoLinux joined #parrotsketch
19:43 plobsing_work joined #parrotsketch
19:46 mikehh joined #parrotsketch
19:49 plobsing_work What I Did:
19:49 plobsing_work * merged dynop_mapping branch
19:49 plobsing_work * modify freeze/thaw/packfiles with an eye toward rakudo startup performance
19:49 plobsing_work * completed deepclone library (on github)
19:49 plobsing_work What I Plan:
19:49 plobsing_work * more freeze/thaw/packfile changes
19:49 plobsing_work * general optimizations (suggestions?)
19:49 plobsing_work * documentation
19:49 plobsing_work * gsoc-y stuff
19:49 plobsing_work EOR
19:51 chromatic joined #parrotsketch
19:56 darbelo_ joined #parrotsketch
19:59 darbelo_ DONE
19:59 darbelo_ -   Hit something of a dead end on unshared_buffers.
19:59 darbelo_ -   (The approach has merit, but I have to shave another yak first.)
19:59 darbelo_ -   Put my GSoC pencil down.
19:59 darbelo_ -   Filled out the final evaluation form.
19:59 darbelo_ -   Made a tarball of this summer's work.
19:59 darbelo_ TODO
19:59 darbelo_ -   Upload the code sample tarbal to Google.
19:59 darbelo_ -   Dive into substr_eq_at, this is the yak I mentioned before.
19:59 darbelo_ -   Eventually merge all three branches back to trunk.
19:59 darbelo_ EOR.
20:00 chromatic Done: some optimizations, some helping with optimizations.
20:00 chromatic Undone: GC massacre, MRO email to list.
20:00 chromatic Will do: review a threading patch, help merge branches.
20:11 tcurtis Did:
20:11 tcurtis * Fixed some bugs in PAST::Transformer.
20:11 tcurtis * Wrote some docs for Tree::Optimizer.
20:11 tcurtis * Added TailCallElim::Explicit to simple-optimizations.
20:11 tcurtis * Expanded ConstantFold::Simple.
20:11 tcurtis * Downed pencil
20:11 tcurtis * Worked on GSoC final evaluation.
20:11 tcurtis Will do:
20:11 tcurtis * Final GSoC blog post
20:11 tcurtis * More docs.
20:11 tcurtis * More bug fixes.
20:11 tcurtis EOR.
20:12 smash joined #parrotsketch
20:13 cotto_work #done:
20:13 cotto_work - gave khairul tips on docs, finished his gsoc eval, made a tarball (in case Google wants one)
20:13 cotto_work - finally figured out how to get the github trac plugin installed and working
20:13 cotto_work #hope to:
20:13 cotto_work - write something cool to show what khairul's been doing
20:13 cotto_work - extend the github trac plugin to map svn revisions to git hashes
20:13 cotto_work #eor
20:14 mikehh What I did since my last report:
20:14 mikehh * building and testing parrot on amd64/i386, with gcc/g++
20:14 mikehh * some fixes
20:14 mikehh * testing rakudo, partcl-nqp, partcl, pir/PIRATE, winxed and plumage
20:14 mikehh * worked on documentation, especially for .pmc files
20:14 mikehh * got things ready for the release today
20:14 mikehh should be ready to go after the meeting
20:14 mikehh What I intend to do in the next week:
20:14 mikehh * testing and fixing
20:14 mikehh * work on html_cleanup branch
20:14 mikehh .eor
20:23 Chandon joined #parrotsketch
20:23 Util # Done:
20:23 Util * Researched compiling GMP on Win32 (for bigints, etc). Wiki writeup RSN.
20:23 Util # Plan to do:
20:23 Util * No time this week.
20:23 Util # Blockers
20:23 Util * My cup overfloweth
20:23 Util .end
20:26 Coke joined #parrotsketch
20:27 Coke hacked on partcl-nqp, some RT maintenance for rakudo; will repeat next week. EOR.
20:31 Coke Hello, everyone.
20:31 mikehh hi there
20:31 cotto_work hi
20:32 plobsing_work hi
20:32 NotFound Hola
20:33 tcurtis Hi.
20:33 Util Hello
20:33 Coke Anyone volunteering to run the meeting?
20:34 Coke (I cannot today, and c is coming in late.)
20:35 dukeleto joined #parrotsketch
20:35 mikehh there you go
20:36 mikehh dukeleto: yoiu have just been volunteered to run the meeting
20:36 dukeleto mikehh: oh boy
20:36 dukeleto Did we meet our goals for the week?
20:37 dukeleto did html_cleanup and the gc_* branches get merged?
20:37 Coke I did not.  html_cleanup branch is still idling.
20:37 mikehh I was going to work on it but didn#t find time
20:38 Util Coke: is time the only blocker on html_cleanup?
20:38 Coke interest?
20:38 mikehh We need to set up the indexing
20:39 Coke my goal was to get it done before 2.6; since I missed that, it's a far far lower priority for me now.
20:39 Coke if anyone else thinks it's worthwhile, happy to work with them on it. it's all perl5 ATM.
20:39 Util Just keeping an eye out in case expected 0 time expands to >0.
20:39 NotFound Coke: Maybe that is the reason for the lack of interest.
20:39 dukeleto what should our new goals for the week be?
20:40 dukeleto personally, I vote that we need to get a smolder instance running again. I am not attached to smolder, but some way for people to submit test results is extremely important
20:40 mikehh merging branches after the release and any deprecations that can go
20:41 plobsing_work q2q
20:41 mikehh dukeleto: I was going to bring that up
20:41 Coke particle is on the smolder thign with OSUOSL, I think.
20:41 NotFound dukeleto: good goal, but hardly a general priority.
20:42 dukeleto NotFound: it is a meta-priority, it helps our gears turn smoothly
20:42 NotFound ok then
20:42 cotto_work There's not much most people can do about it, but +1 for those who can help.
20:42 mikehh I think it is very important from the testing point of view
20:42 particle the status from osuosl from late last week was "we're working on it, slowly, cause the guy working on it isn't here"
20:42 dukeleto particle: ok, good to hear you are on top of it
20:42 particle let me know if i need to apply more pressure
20:42 cotto_work Do they know about its memory leak issues?
20:43 NotFound Is a bad month to press people, let's wait until september
20:43 mikehh particle: I tried to email mpeters, but have not had a reply
20:43 dukeleto particle: i would say we should have it working at least 2 weeks before the next stable release, so that gives us about 6 weeks ?
20:43 particle dukeleto: can do
20:43 dukeleto are we into the questions section of #ps or did I miss something?
20:43 particle mikehh: thanks for trying, i don't know why no response.
20:44 particle i can follow up with mpeters, too
20:44 Coke dukeleto: it's your show. do what you like. =-)
20:44 * dukeleto will have to leave for a dentist appointment soonish, and will have to hand-off. maybe chromatic will be here by then
20:44 dukeleto plobsing_work: what is your 1st question?
20:44 mikehh did we decide on goals for the week?
20:45 dukeleto mikehh: touche. Let's decide some goals.
20:45 plobsing_work every time I update native pbc's it seems someone on darwin/ppc (usually kid51) has to do so as well. why?
20:45 dukeleto What is reasonable to accomplish in the next week?
20:45 NotFound +1 for the ones mikehh said
20:45 dukeleto plobsing_work: we will come back to that as soon as we decide some goals
20:46 dukeleto I agree with mikehh, but I think we need our goals to be a bit more specific, so we know if we have actually accomplished them
20:47 mikehh I think there are a few things that were waiting for the release, branch wise
20:48 mikehh merge any branches that are ready (after testing of course)
20:48 darbelo GSoC is done and the release is out. Should we push for the GSoC branches to merge?
20:48 dukeleto darbelo: yes
20:48 darbelo (If ready, and not leaving the nest, of course.)
20:49 dukeleto I know that bubaflub's gsoc work is not done yet, but he seems eager to continue working on it after gsoc, which is promising
20:49 cotto_work khairul's code is leaving the nest, so it's a non-issue for him.
20:49 darbelo tcurtis has already moved his code out, IIRC.
20:50 cotto_work yup
20:50 darbelo And I have performance yaks to shave before merging is an option.
20:51 darbelo I don't know what the other statuses are.
20:51 dukeleto ok, so goals i here so far are merge gsoc branches that are ready, as well as others. Do we want more goals or is that enough?
20:51 chromatic How about closing n open tickets?
20:51 Paul_the_Greek joined #parrotsketch
20:51 dukeleto chromatic: that sounds like a nice goal
20:51 dukeleto chromatic: who gets to choose n ?
20:52 chromatic We do.
20:52 chromatic We have 663 active tickets.
20:52 dukeleto chromatic: what about each person at #ps right now closes at least 2 open tickets this week ?
20:52 darbelo Is one per active committer sane?
20:52 chromatic Close 13 tickets?
20:53 dukeleto darbelo: i think that is sane, and perhaps a bit less than we can do. Let's aim high.
20:54 Paul_the_Greek I'll join in when I return home.
20:54 darbelo That reminds me, we could force a commit bit upon Paul_the_Greek.
20:54 allison joined #parrotsketch
20:54 darbelo I think he's sent a CLA.
20:54 dukeleto who wants to make closing 13 tickets a goal for this week?
20:54 cotto_work +1 if he wants one, though I don't think he does
20:54 Paul_the_Greek Yes, I have.
20:55 Paul_the_Greek You can give it to me, but I'll use it gingerly for awhile.
20:55 chromatic If we're discussing CLAs, I like the work luben karavelov has been doing too.
20:55 * cotto_work too
20:55 mikehh +1 to both
20:55 Paul_the_Greek Cotto knows of two patches I have attached to tickets. They will close those tickets.
20:55 NotFound +1
20:55 chromatic Ditto Nick Wellnhofer, though I don't know if he's on IRC.
20:55 darbelo chromatic: That's the gc patches, right?
20:56 chromatic GC and hash, yes.
20:56 Coke +1 to getting CLAs to both of them.
20:56 Coke (pual & luben) I don't know nick.
20:56 particle Paul_the_Greek's cla has been received, approved, and logged
20:56 dukeleto +1 to more commit bits
20:56 cotto_work let's flip some bits
20:57 mikehh with a bit of mentoring, it works well
20:57 chromatic Nick wrote some patches to fix STRING iteration in January and February, and he's offered some GC patches lately.
20:57 dukeleto So shall we say that the goals for the week are to merge ready branches after the release and close at least 13 tickets ?
20:57 Coke I can flip the bits as soon as we have cla's and mentors.
20:58 Util +1 # goals
20:58 Coke so goal is to get down to 620 tickets?
20:58 Paul_the_Greek Fip my bit and assign me a mentor!
20:58 chromatic +1 to goals of closing 650 tickets and +1 to soliciting CLAs
20:58 particle someone please invite luben and nick to consider a commit bit and submit a cla
20:59 dukeleto Coke: no, because new ones could be added. Our goal is to close at least 13 tickets this week
20:59 particle joy
21:00 Paul_the_Greek I've been reading lots of tickets and some of them have basically pooped out. As if everyone decided that no change should be made.
21:01 Paul_the_Greek There are also tickets in the New Patches set that are quite old.
21:01 Coke dukeleto: that number is harder to track.
21:01 dukeleto Paul_the_Greek: yes, that happens sometimes. We need to review those tickets, and close them if we decide they are invalid or no action should be taken
21:01 Coke Paul_the_Greek: if the patch no longer applies, we can probably reject it as outdated and invite a new one.
21:01 dukeleto Coke: there is an email for every closed ticket, it shouldn't be too hard
21:02 Paul_the_Greek An example: http://trac.parrot.org/parrot/ticket/850
21:06 * dukeleto has to leave, i leave you all in the capable hands of chromatic++
21:07 Paul_the_Greek joined #parrotsketch
21:07 chromatic Do we have agreement on our goals then?
21:07 Paul_the_Greek Good goals.
21:07 darbelo Sounds like it.
21:08 * Coke closes 2 tickets.
21:08 chromatic Agreement on inviting three new committers?
21:08 mikehh +1
21:08 allison +1
21:08 darbelo +1
21:08 NotFound +1
21:08 Coke +1
21:08 Util +1
21:08 Coke (well, +3)
21:09 chromatic Any other questions?
21:09 darbelo plobsing's didn't get an answer.
21:09 mikehh just gonna say that
21:10 plobsing_work Am I doing something wrong when I regenerate the native PBCs? kid51 always has to remake them on darwin/ppc.
21:10 mikehh I think the native code files were created on different platforms
21:10 darbelo plobsing_work: Are you on 32 or 64-bit intel?
21:11 NotFound plobsing_work: the wrong thing is the need to regenerate them.
21:11 mikehh we don't have functions to create them cross-platform wise
21:11 plobsing_work I always remake on 32-bit intel. I thought all the tests were all targetted at that platform's PBCs
21:12 NotFound See my last comment on TT #1712
21:12 mikehh we never decided on a testing policy there, ref the skipped tests
21:12 chromatic Does anyone believe we'll fix the cross-platform nature of PBC in the near future?  Before 2.9?
21:12 NotFound Yes, we skip the test and then add other tests with the same problem.
21:13 darbelo In theory all platforms should be able to read packfiles for all others. Most of the code is there, but we're missing 'cross-reading' functions for some of the combinations.
21:14 NotFound darbelo: but we have the practical problem of regernerating the pbc for the tests.
21:15 whiteknight joined #parrotsketch
21:15 NotFound That's not theory, is hurting us every month.
21:15 chromatic What do the tests gain us?
21:16 NotFound The packfile tests are needed, is the way they work what is wrong.
21:16 mikehh we should be able to recreate any given defined format, without having to generate it on the native platform
21:16 plobsing_work IIUC, they check that all platforms can read intel 32-bit packfiles
21:17 NotFound They should test the packfile pmc, not the pbc format.
21:17 NotFound That's the work of the native_pbc tests, wich are skipped.
21:17 darbelo I thought we were talking about those.
21:18 mikehh we should be able to read any format and transform it to another
21:18 NotFound darbelo: they are skipped, so they don't hurt.
21:18 atrodo is there a reason that the packfiles arn't just in little or big endian across the board?  am I missing something obvious?
21:18 NotFound The practical problem now is the packfile PMCs tests.
21:18 tcurtis joined #parrotsketch
21:19 NotFound atrodo: the problem is just to reuse the native_pbc files for that tests.
21:19 plobsing_work atrodo: not having to convert packfiles generated by your own machine is thought to be a win
21:19 chromatic We're not to the point at which we can mmap yet though.
21:21 whiteknight what will it take us to get to that point?
21:22 darbelo A person who can stand to hack on the packfile code for extended periods of time?
21:22 plobsing_work likely just someone caring enough to make it work
21:22 chromatic What should we do now with regard to the tests?
21:23 darbelo Stop checking in generated packfiles to the repo.
21:23 NotFound What tests? packfile PMCs or native _pbc?
21:23 plobsing_work +1
21:24 darbelo (for packfile PMCs)
21:24 mikehh we should not have to check in binary files
21:24 darbelo We should take whatever process creates them now and use it to create them when the test runs.
21:24 Coke I know rurban has strong feelings on these tests. whoever claims this todo item should at least review his post to the mailing list about it from just before 1.0
21:25 NotFound We just need to generate some pbc for the packfile PMCs tests
21:25 mikehh if we need them they should be generated
21:25 NotFound Coke: he's missing the point. The native_pbc tests are already skipped.
21:25 chromatic +1 to removing generated binary files
21:26 mikehh are those test the only reason we have the binary files?
21:27 NotFound mikehh: yes, the only reason to have it is its use in test that are skipped, and to misuse in unrelated tests.
21:28 mikehh kill 'em
21:28 Coke NotFound: his point was that they should not have been skipped at all, iirc.
21:28 darbelo We can start with the 'stop misusing' part. Then revisit for the kill.
21:28 chromatic I understood rurban's complaint to be "Stop breaking PBC compatibility."
21:28 NotFound Coke: but that point is not for that ticket, here it only adds confusion,
21:28 Coke <whatever/>
21:29 Coke I have no stake in this particular mess, but only wish to point out someone who does.
21:30 chromatic Does anyone believe we can (or should) enforce PBC compatibility across supported releases?
21:30 NotFound I like rurban goal, but looks like we don't have enough access to all platforms required.
21:30 darbelo "It can be solved, but not without more resources than we have now."
21:30 plobsing_work it would be nice to have, but PBC is so far from ideal and ties in to so many other things, it would freeze us up.
21:31 Coke chromatic: yes. we /should/ be drawing a line in the sand and freezing our PBC format at some point.
21:31 chromatic Is that point now?
21:32 Coke it is crazy to have to recompile pir to pbc all the time. At least IME coming from the JVM.
21:32 darbelo No way. At best we could write a pbc 'migrator'.
21:32 Coke chromatic: I'm only answering the 'should' at this point. =-)
21:32 NotFound I don't think so. Frozen PMCs in the pbc means compatibility can compromise all PMCs.
21:32 chromatic Okay, let's skip that part for now.
21:32 sorear chromatic: PBC compatibility means imcc can be dropped in favor of PIRATE, if that's a goal
21:32 chromatic Does changing the tests to generate PBCs before testing them solve our problem now?
21:33 darbelo Yes. One of them, anyway.
21:33 chromatic Objections to doing so?
21:34 chromatic Who's going to make it happen?
21:35 Coke are we sure we're testing the right thing then?
21:35 NotFound We are testing the packfile PMCs
21:36 pmichaud joined #parrotsketch
21:36 NotFound chromatic: I can go for it, but not sure if will have enough time this week.
21:36 chromatic Other questions?
21:37 chromatic If not, I have one.
21:37 mikehh NotFound: it has been hanging around for a year at least, go for it
21:38 chromatic Given the beneficial desire to document all C functions but the meh of adding public POD to static functions, any thoughts on changing the "Does this have documentation?" test to accept mere C comments for static functions instead of full POD?
21:38 cotto_work +1
21:38 Paul_the_Greek +1
21:39 plobsing_work +1
21:39 darbelo +1
21:39 cotto_work (unless it means more boilerplate comments to pass the test instead of documenting the functions)
21:39 Util I thought someone (kid51?) had made huge progress in cleaning up the backlog of un-PODed C functions
21:39 chromatic Any objections?
21:39 mikehh if you can come up with a reliable test that does that, at least with the pod headers we can determine that there is documentation there
21:40 mikehh or would just any comment in the function do? I do't realy think so
21:40 mikehh don't
21:40 chromatic My concern with requiring POD is that these are functions not for public consumption and thus should not be in public documentation.
21:41 NotFound A way to extract and put elsewhere all public api functions, methods and vtables will be better, IMO.
21:41 Paul_the_Greek Which prevents users from relying on some internal feature.
21:41 mikehh who are we documenting for, I think we document for devs as much as users
21:41 NotFound Its PODs, I mean.
21:41 tcurtis Is there any way to make it so that we have POD for both (because POD seems to be easier to check for), but the non-public functions are marked so that they don't show up in public docs?
21:41 plobsing_work I think one multi-line descriptive comment above static functions is appropriate
21:41 chromatic Figuring out how to hide POD seems like more work to me, but if someone can figure it out that's fine too.
21:41 Paul_the_Greek As a new developer, I don't see why I'd want static functions documented externally.
21:42 tcurtis Although, if so, that should probably wait until html_cleanup gets merged, perhaps.
21:42 chromatic Do we have some sort of conclusion as to what we should do?
21:42 mikehh I agree, but from the developer point of view, we definately *need* documentation
21:43 Paul_the_Greek Require a comment preceding a static function, but not a POD. Hide static PODs.
21:43 chromatic I can take a look at fixing the test if we agree on doing so.
21:44 mikehh as long as we have a way of requiring comments for every static function
21:44 Paul_the_Greek Any requirements for data structures?
21:44 chromatic We haven't reached that yet.
21:44 mikehh we should probably go for that too
21:45 Paul_the_Greek At least as important, I think.
21:45 cotto_work no requirements, but more comment patches are welcome
21:45 cotto_work (yet)
21:45 tcurtis +1 to plobsing/Paul_the_Greek's suggestions, at least for now.
21:46 chromatic Other questions?
21:46 Paul_the_Greek A memory management question?
21:46 plobsing_work what is the difference between parrot's baked-in config and config.fpmc?
21:47 darbelo There shouldn't be one.
21:47 darbelo That is, config.fpmc is what we bake into parrot.
21:47 plobsing_work so why do we have runtime/parrot/library/config.pir?
21:47 NotFound plobsing_work: you mean the one in the Interpreter PMC?
21:47 chromatic There's a lot of useless stuff in config.fpmc.
21:47 plobsing_work NotFound: yes, that one.
21:48 NotFound plobsing_work: that is loaded from the other during intialization.
21:48 mikehh IIRC some of that stuff was set up to be sent to smolder
21:48 darbelo I think it's for people talking to libparrot directly and not through a parrot executable.
21:49 whiteknight config.fpmc could easily be broken up into multiple separate caches of data. Information about build/configure is useful for extensions but not so much for a running Parrot
21:50 NotFound But to get the path to load it you need to have it loaded. We should elaborate a btter way.
21:50 chromatic If this is getting into design discussions, perhaps it's better back in #parrot
21:50 NotFound A RFC ticket is better, IMO.
21:51 Paul_the_Greek Memory management question?
21:52 chromatic Probably better in #parrot.
21:52 Paul_the_Greek Okay.
21:52 chromatic Any last questions?
21:53 chromatic Calling it a week then.  Thank you, everyone.
21:53 Paul_the_Greek left #parrotsketch
22:19 plobsing_work left #parrotsketch
22:41 Chandon left #parrotsketch
22:57 kid51 joined #parrotsketch

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