Camelia, the Perl 6 bug

IRC log for #parrotsketch, 2009-11-17

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

All times shown according to UTC.

Time Nick Message
00:19 Whiteknight joined #parrotsketch
00:56 particle joined #parrotsketch
01:25 particle joined #parrotsketch
08:42 japhb DONE:
08:42 japhb * Support fperrad++'s setup.pir system in Plumage
08:42 japhb * Fix several portability issues, leading to ...
08:42 japhb * ... Plumage's first successful clean test run and project install on Win32!
08:42 japhb * Much more use of new NQP-rx features
08:42 japhb * Add simple version of 'status' command
08:42 japhb * Commit metadata additions/edits from fperrad++
08:42 japhb * Reorganize more of the tests to make it easier to identify testing gaps
08:42 japhb MAD PROPZ:
08:42 japhb * fperrad++   # setup.pir, Win32 testing, new & improved metadata ...
08:42 japhb * pmichaud++  # NQP-rx features, w00t!
08:42 japhb NEXT UP:
08:42 japhb * More tests -- hopefully lots more, if my fellow committers have some spare cycles (hint, hint)
08:42 japhb * Several major refactorings just got unblocked by pmichaud++'s NQP-rx variable handling improvements
08:42 japhb * Depending on progress of above refactorings, back to adding new user-visible functionality again
08:42 japhb BLOCKERS:
08:42 japhb * Currently unblocked ...
08:42 japhb * ... but always happy to see new features from http://wiki.github.com/per​l6/nqp-rx/plumage-requests
08:42 japhb * ... especially full hash constructor syntax, which would allow quite a few cleanups and allow builds of Plumage itself to switch from Configure.nqp/make to fperrad's make-less setup.nqp
08:42 japhb EOR
08:43 japhb GRRRRRRR
08:43 japhb ... OK, trying this again, slower ...
08:43 japhb DONE:
08:43 japhb * Support fperrad++'s setup.pir system in Plumage
08:43 japhb * Fix several portability issues, leading to ...
08:43 japhb * ... Plumage's first successful clean test run and project install on Win32!
08:43 japhb * Much more use of new NQP-rx features
08:43 japhb * Switch over to parrot-nqp, no longer following NQP-rx git master directly
08:43 japhb * More Glue.pir -> Util.nqp conversions
08:43 japhb * Refactor action functions to reduce pointless duplication
08:44 japhb * Add simple version of 'status' command
08:44 japhb * Commit metadata additions/edits from fperrad++
08:44 japhb * Reorganize more of the tests to make it easier to identify testing gaps
08:44 japhb MAD PROPZ:
08:44 japhb * fperrad++   # setup.pir, Win32 testing, new & improved metadata ...
08:44 japhb * pmichaud++  # NQP-rx features, w00t!
08:44 japhb NEXT UP:
08:44 japhb * More tests -- hopefully lots more, if my fellow committers have some spare cycles (hint, hint)
08:44 japhb * Several major refactorings just got unblocked by pmichaud++'s NQP-rx variable handling improvements
08:44 japhb * Depending on progress of above refactorings, back to adding new user-visible functionality again
08:44 japhb BLOCKERS:
08:44 japhb * Currently unblocked ...
08:44 japhb * ... but always happy to see new features from http://wiki.github.com/per​l6/nqp-rx/plumage-requests
08:44 japhb * ... especially full hash constructor syntax, which would allow quite a few cleanups and allow builds of Plumage itself to switch from Configure.nqp/make to fperrad's make-less setup.nqp
08:44 japhb EOR
09:01 davidfetter joined #parrotsketch
09:16 einstein joined #parrotsketch
10:07 mikehh joined #parrotsketch
11:54 bluescreen joined #parrotsketch
13:42 bluescreen joined #parrotsketch
14:16 einstein joined #parrotsketch
14:23 bluescreen joined #parrotsketch
15:31 whiteknight joined #parrotsketch
16:30 whiteknight WHAT I DID
16:30 whiteknight * (pla) Fixed installation and major cleanup throughout.
16:30 whiteknight * (pla) Added a new CharMatrix2D type, which bridges a small gap between an array of strings and a matrix of numbers. Necessary for Matrixy
16:30 whiteknight * (pla) Added a new ComplexMatrix2D type
16:30 whiteknight * (pla) All matrix types does the "matrix" role. Working to define what, exactly, that role means and what users can expect from a PMC that "does matrix"
16:31 whiteknight * (matrixy) Finished the pla_integration branch and merged into trunk.
16:31 whiteknight * (matrixy) Fixed the way matrices of different types are generated
16:31 whiteknight * (matrixy) Now passes almost all tests that we were passing before the split/refactor
16:31 whiteknight * (matrixy) Added preliminary Cell Array support using the new PMCMatrix2D PMC type from parrot-linear-algebra
16:31 whiteknight * (parrot) Closed out my remaining RT tickets.
16:31 whiteknight * (parrot) More testing on the libjit_framebuilder branch.
16:31 whiteknight * (parrot) Trying to [finally] fax in my CLA. Tried 3 times now with various errors. Will end up snail-mailing it.
16:31 whiteknight WHAT I WILL DO
16:31 whiteknight * (pla) Test, Test, Test
16:31 whiteknight * (matrixy) Finish adding Cell support, and test
16:31 whiteknight * (matrixy) General cleanup
16:31 whiteknight * (parrot) Add proper :call_sig support for both callee and caller. Add tests
16:31 whiteknight * (parrot) Try to convert more tests from Perl5 to PIR
16:31 whiteknight WHAT I AM BLOCKING ON
16:31 whiteknight * Nothing
16:31 whiteknight Queue 3 Questions
16:31 whiteknight EOR
16:32 darbelo joined #parrotsketch
16:57 cotto joined #parrotsketch
17:33 NotFound joined #parrotsketch
17:55 dukeleto What I have Done:
17:55 dukeleto * Played patch monster for some Perl->PIR test conversions.
17:55 dukeleto * Started the nqptap project, an self-contained TAP test harness written in NQP-rx
17:55 dukeleto http://github.com/leto/nqptap
17:55 dukeleto * Made progress with PL/Parrot. We now have a functioning 'create language' and
17:55 dukeleto 'create function', but no type marshalling or parsing is being done yet. The test
17:55 dukeleto suite will be written in SQL+pgTAP : http://leto.net/dukeleto.pl/2009​/11/parrot-in-your-database.html
17:55 dukeleto * Made small amount of progress with Kea (Factor on Parrot). Still playing learning NQP-rx.
17:55 dukeleto What I will Do:
17:55 dukeleto * More of the same
17:55 dukeleto Blocking On:
17:56 dukeleto * Life
17:56 dukeleto EOR
17:58 darbelo ENOREPORT
17:58 darbelo ENOTUITS
17:58 darbelo .end
17:59 * dukeleto will try to be back, but has other meetings
18:01 kj joined #parrotsketch
18:01 pmichaud joined #parrotsketch
18:01 pmichaud I will likely miss #ps today -- will post my report when I return.
18:10 Coke joined #parrotsketch
18:10 barney joined #parrotsketch
18:12 Coke Done:
18:12 Coke - RT is gone. Long live TT.
18:12 Coke - Updated docs.parrot.org for 1.8.0 release
18:12 Coke - added http download links to http://parrot.org/download
18:12 Coke Blockers:
18:12 Coke - parrot segfaults blocking partcl
18:17 barney Done: Managed release of Parrot 1.8.0
18:17 barney .eor
18:20 Util joined #parrotsketch
18:20 cotto_work #done
18:20 cotto_work * started seriously thinking about how to test the profiling runcore
18:20 cotto_work * made FileHandles store/expose the exit status when running an external command
18:20 cotto_work * this allows basic "Did it explode?" testing of external commands while still capturing output
18:20 cotto_work * started to port pprof2cg.pl to nqp
18:21 cotto_work * spammed the wiki about how Lorito should be opcode-based
18:21 cotto_work #gonna do
18:21 cotto_work * continue getting pprof2cg.nqp implemented
18:21 cotto_work * learn nqp
18:21 cotto_work * after the profiler is sufficiently awesome, start back on opsc/pmcc with bacek++
18:21 cotto_work #blockers
18:21 cotto_work * rl
18:21 cotto_work eor
18:21 cotto_work q2q
18:21 Util # Done:
18:21 Util * TODO-ed a failing op/number.t test that was failing on platforms lacking negative zero.
18:22 Util * Tested 1.8 on MinGW, MSVC 2002, and MSVC 2005.
18:22 Util * Found issues with todo() in PIR; most uses of it are flawed. Ticket later today.
18:22 Util # Plan for this week:
18:22 Util * Finish TT#1217 , TT#1218 !
18:22 Util * Work to resolve the PIR todo() problem, and possibly its API.
18:22 Util # Blockers:
18:22 Util * Tuit shortage
18:22 Util .end
18:23 allison joined #parrotsketch
18:24 allison Last week:
18:24 allison - Have no RT tickets left in my name. In fact, no RT tickets left open at all. Thanks to Coke for pushing us through finishing them off.
18:24 allison - Continuing working my way down AllisonTasklist.
18:24 allison Next week:
18:24 allison - Knock a few more tasks off the list.
18:24 allison Blocking on:
18:24 allison - Time.
18:24 allison EOR
18:28 mikehh What I did in the last week:
18:28 mikehh * building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
18:28 mikehh * fixing tests
18:28 mikehh * testing for release
18:28 mikehh What I intend to do in the next week:
18:28 mikehh * testing and fixing
18:28 mikehh * continue working on checking skipped tests
18:28 mikehh .eor
18:31 chromatic joined #parrotsketch
18:32 whiteknight hello
18:32 chromatic good localtime()
18:32 mikehh hi there
18:32 Util hello
18:32 Coke ~~
18:32 cotto_work hi
18:33 allison hi
18:33 darbelo Hola
18:33 chromatic Question to ponder, but don't answer yet.  What's the most important thing we can accomplish for 2.0?
18:33 barney hi
18:33 chromatic Let's review last week's priorities.
18:33 chromatic How did ops testing go?
18:34 whiteknight I did a little. Saw other people doing stuff too
18:34 whiteknight more or less a success, but hardly rose to the level of "hackathon"
18:34 mikehh ditto
18:34 cotto_work agreed
18:35 chromatic Was it a) not that interesting b) timed poorly c) unclear d) too much too fast too soon?
18:35 whiteknight I suspect not interesting
18:36 chromatic Let's review the 1.8 release.
18:36 chromatic What went right?
18:36 mikehh I am not sure - I spent quite a bit of time on it, nothing like the pcc_reapply hackathon
18:37 cotto_work It got out the door, before #ps even.
18:37 whiteknight 1.8 appeared to go very smoothly
18:37 barney release instruction were pretty good
18:37 whiteknight and quickly
18:37 chromatic How about the month of work leading up to 1.8?
18:37 NotFound Late again.
18:38 whiteknight month went well. Seemed a little slower in my estimation
18:38 NotFound Me, not the question.
18:38 chromatic What didn't go right?
18:39 barney Some smoke test failures for Win(32|64)
18:40 barney crow.pir was broken, will file a TT
18:40 cotto_work We have several tasks attached to the 1.8.0 milestone that aren't done.
18:41 chromatic They've been slipping from release to release.
18:41 whiteknight yes, windows support still seems very fragile most months
18:41 whiteknight we definitely need to improve testing there
18:43 chromatic Anything else?
18:43 allison it's worth reexamining the tasks and deciding if they really are a priority for 2.0
18:43 Coke we already have smokes coming in for windows pretty regularly that are not acted upon.
18:44 mikehh I've been testing and fixing on linux amd64/i386 but sometimes fixing breaks on MSWin
18:45 allison would a windows testing server be useful, or would people not use id?
18:45 allison it
18:45 mikehh some of the high priority items have slipped over the last 3 releases or so
18:46 darbelo What we need the most is people that really know windows.
18:46 NotFound These are Windows problems MSVC problems, or both?
18:46 cotto_work allison, it'd be very nice to have one.  I could get an MSDN subscription for a year if it'd be helpful.
18:46 allison mikehh: hll-interop is high-priority, but not well defined. bytecode testing and datastructure pruning aren't really high priority, they're more ongoing tasks
18:47 cotto_work (as in I can arrange to get subscriptions to individual Parrot developers)
18:47 allison cotto: I'm thinking of dropping a green windows server onto chromatic's network, for everyone to use
18:48 chromatic I thought Microsoft's OSTC had servers available.
18:48 allison cotto: I'm just not sure if the problem is access or motivation
18:48 allison chromatic: in theory, yes, in practice getting access is a long and involved process
18:49 NotFound In order to fix the pipe writing test I think we just need a portable way of creating a temporary file name.
18:49 cotto_work AFAICT it just requires a PAUSE id and hanging out in #msopensource long enough to catch alias
18:49 allison but, I do think windows testing is approaching "critical" on our list
18:50 whiteknight it's not enough to just get test reports in. We don't have many developers willing/able to fix bugs on windows
18:50 NotFound Even less if they are MSVC specific.
18:50 allison cotto: okay, would you be willing to volunteer to get access through alias, and then document how you did it so we can all follow?
18:51 * allison has no desire to maintain a windows server if I can avoid it
18:51 cotto_work allison, I'll do that.
18:51 cotto_work I'll stick something on the wiki.
18:52 allison cool, thanks!
18:52 chromatic That gets us into the third questoin.
18:52 chromatic *question
18:52 chromatic What do we need to change this month?
18:52 Util I can move from general Parrot work to Win32-specific. I had not perceived the need prior to this.
18:52 whiteknight clear priorities
18:53 whiteknight and clear plans to address them
18:53 chromatic Do we have a single list of potential priorities?
18:54 whiteknight I've never seen things move as quickly or as smoothly as when everybody knew PCC was the thing to be doing
18:54 mikehh agreed
18:54 NotFound whiteknight: but it took months to reach that point.
18:55 whiteknight NotFound: true, it was a particularly large project
18:55 mikehh I think it was the focus in the last couple of weeks that really got things finalized
18:55 cotto_work a long period of pain is an excellent motivator
18:55 whiteknight but if I have 2 hours a night, and it takes me an hour to figure out what I want to work on, that's a huge waste of my development time
18:55 NotFound I mean, the point it got clear that that was becoming the bigger blocker.
18:55 Coke I would like to see all the language issues at least touched this week. (https://trac.parrot.org/parrot/report/16)
18:56 Coke some of these go back to double digit trac ids.
18:56 chromatic That fits in with pmichaud's message to the list a couple of weeks ago.
18:58 chromatic Okay, let's summarize that then.
18:58 chromatic I'll create a Wiki page RIGHT NOW called DevelopmentPriorities.
18:58 chromatic Everyone gets to put one on the list.
18:58 whiteknight +1
18:58 chromatic We'll vote and figure out what we most need to work on and then we'll do it.
18:58 Coke one what... ticket?
18:58 chromatic One priority.
18:58 whiteknight one priority
18:59 Coke ok. in my mind that == a ticket.
18:59 NotFound I think several of this points are rooted in: kill imcc, use packfile pmc to read, write, and memory manage segments.
18:59 whiteknight I disagree. big nebulous tickets are non-value
19:00 NotFound Not the ticket, but the work required.
19:00 chromatic Let's say that any plan we vote on has to have sufficient detail that we can identify individual hour-or-two tasks.
19:00 cotto_work Should we be adding names to our requests?
19:00 chromatic If you want.
19:00 whiteknight chromatic: +1 on sufficient detail and individual 1-2 hour tasks
19:01 chromatic Okay, the page is there.
19:01 chromatic Let's move on.
19:01 chromatic cotto, you had a question.
19:01 cotto_work Can it be Array deprecating time now please?
19:02 NotFound +1
19:02 allison which to deprecate?
19:02 mikehh you can't have everyone working on the same 1-2 hour task
19:02 cotto_work (in favor of RPA, which does the same thing but doesn't pretend to be type-agnostic)
19:02 cotto_work allison, Array
19:02 cotto_work (as in src/pmc/array.pmc
19:02 cotto_work )
19:02 allison just the one base class?
19:03 allison ah, sure, it's not particularly useful
19:03 cotto_work Great.  I'll file a tt.
19:03 Coke +1 on removing at least one of the many array types. =-)
19:03 NotFound And his supporting C routines, I suppose.
19:03 mikehh we need somthing lixe x tasks and assign/volunterer for specific tasks
19:03 allison someday I'd like to deprecate a pile of them, but one is a good start
19:03 mikehh like
19:03 Coke mikehh: assigning tasks can be done via trac.
19:04 cotto_work eoq
19:04 mikehh Coke: something like that
19:04 cotto_work For clarification, is the 2.0 release being designated as production-ready?
19:05 NotFound Sometimes I think even C is not yet production ready.
19:05 Coke cotto_work: what does that mean?
19:05 Coke it's a 'supported' release, anyway.
19:05 allison cotto: as targeting production users, yes
19:05 allison "production ready" is vague
19:05 Coke Given that we still haven't hit our "stable for HLL users" yet, that seems pretty ambitious.
19:05 allison could mean any number of different things
19:06 cotto_work +1 to what Coke said
19:06 whiteknight Yeah, I don't want to be combative here, but we really haven't done much with a focus on "production ready" yet
19:06 allison we did hit what we said, that HLL users could use only supported releases, for a more stable 6 month cycle
19:06 allison (which was all we promised)
19:06 Coke ok, then 'the roadmap tickets are too vague'. =-)
19:06 cotto_work It doesn't strike me that any production user would reasonably want to use Parrot as it's likely to exist in its 2.0 form.
19:07 allison so, it's important to be clear on what we mean for 2.0
19:07 Coke agreed!
19:07 cotto_work yes
19:07 whiteknight When I think about "production users" and their needs, I think about performance, stability, and scalability. None of which we are going to have in large supply for 2.0
19:08 Coke so, it'll be supported, we all agree on that. I think we should take some time (not right now but perhaps for next week) and (more)
19:08 allison we do have it in substantially larger supply than 1.4
19:08 Coke 1) go through the existing roadmap items.
19:08 Coke 2) See if there are new roadmap items.
19:08 allison (largely because it's been our focus for the past several months)
19:08 mikehh What's a production user - rakudo?
19:09 Coke fill in the blanks on chromatic's page, make sure the high level goals are updated in trac's roadmap.
19:09 whiteknight I would certainly like to do a PDS-esque major planning event sometime
19:09 whiteknight because we are working off a very old roadmap at this point
19:09 Coke mikehh: no, that's just 'user'.
19:09 NotFound I don't think performance is actually so bad.
19:09 Coke NotFound: FSVO bad.
19:09 whiteknight bad compared to where we were a few months ago
19:10 Coke I find most HLLs seem pretty slow still compared to their non-parrot counterparts. No?
19:10 whiteknight very much so
19:10 Coke (PIR is fast. but no one "in production" is likely to use straight PIR, are they?)
19:10 allison the new nqp will help with that
19:11 darbelo At most, they'd use nqp-rx
19:11 NotFound Coke: yes, but I think most of the slowness is in the compiling part, not on parrot running machinery.
19:11 whiteknight we're going to need to do more at the Parrot level to support the kinds of code patterns that NQP is generating though
19:11 dukeleto back
19:11 whiteknight neither project operates in a vacuum
19:11 allison we put all our energy into making a fast virtual machine, but lost sight of the fact that it needs fast tools on top
19:12 chromatic I'll put some work into profiling the new NQP.
19:12 dukeleto i think the issue is that parrot has started to be optimized for itself, but we aren't optimizing for how HLL's are using parrot
19:12 dukeleto chromatic: let me know if you need benchmarks/valgrind output for things
19:13 whiteknight dukeleto: agreed
19:13 chromatic cotto_work, you had a second question.
19:13 dukeleto i think we are still implementing all the features that HLL's want, so it is reasonable to not be optimizing in that sector yet
19:13 NotFound If you need a motivational example: Winxed hand written parser is fast.
19:14 dukeleto i think parrot needs to have a community decision about what we consider "production"
19:14 cotto_work chromatic, that was it.
19:14 dukeleto then focus on those features for the next 2 months
19:14 chromatic whiteknight, you had a question.
19:15 whiteknight 3 of them
19:15 whiteknight 1) Can we deprecate the Array PMC type?
19:15 NotFound +1 again
19:15 whiteknight I saw a ticket with some info from 2008, but I want to get back to the issue
19:16 whiteknight Array does what ResizablePMCArray does, except it uses a (bad) sparse storage mechanism
19:16 allison dukeleto: the point of targeting "production users" was to get devs thinking about speed and stability. It worked.
19:16 whiteknight so we lose performance in exchange for better memory use on large, sparse arrays
19:17 dukeleto allison: i agree. i am willing to focus on speed and stability for the next 2 months
19:17 cotto_work I'd rather see that itch scratched by someone who really needs it.
19:17 whiteknight which itch?
19:18 NotFound I'm for killing Array, and write a sparse array from scratch if the need for it gets evident.
19:18 * allison has a sense of deja vu
19:18 allison yes, let's deprecate Array
19:18 whiteknight excellent. Any decision would have been better then keeping it in limbo. But I'm happy to see it go
19:19 cotto_work whiteknight, the itch for sparseness
19:19 whiteknight Okay, second quesion:
19:19 cotto_work I'm writing the tt now.
19:19 whiteknight A lot of PMC types, especially the array types and numerics, would really benefit from an explicit plan or "vision" regarding what behaviors they are expected to support and not support. Can we prepare something like this for 2.0?
19:19 whiteknight I see a lot of cases where people expect more consistency between like-types then we currently provide
19:19 allison a lot of the PMC types would benefit from being deprecated and removed, which may qualify as the vision for them
19:20 whiteknight that would be fine too
19:20 allison (or moved to dynpmcs)
19:20 NotFound For example, Integer array has no push method, others have.
19:20 Coke NotFound: push vs. not is a long standing issue. (see also: "does is not useful")
19:20 whiteknight for instance, I have a ticket where the autovivification behavior of FixedPMCArray needs fixing. But I remember seeing allison say that those arrays should not autovivify
19:20 whiteknight so clarification on points like that would always be good and help move things forward
19:21 whiteknight and clarification on what the various "provides" roles in PMCs mean
19:21 whiteknight etc
19:21 allison Parrot core types don't autovivify, but I was just looking at that ticket today, and it looks like there was a partial implementation of autovivify
19:21 NotFound Coke: I'm not for push vs not push ATM, but for consistency.
19:21 whiteknight exactly.
19:21 Coke NotFound: ... yes, that's been my complaint all along.
19:22 whiteknight I want consistency, clear expectations that we can follow and the users can rely on, etc
19:22 NotFound And not in theory, this has upset me while implementing winxed features.
19:22 allison whiteknight: wait, that's on set_pmc
19:23 allison whiteknight: that's not autovivification, that's just storing a value
19:23 whiteknight allison: there are dozens of tickets at least tangentially related
19:23 allison (set_pmc_keyed)
19:23 whiteknight any particular case doesn't matter. What we need is clear overarching vision for what kinds of behaviors the various types should implement
19:24 whiteknight I would expect FixedIntegerArray to share similar behaviors with fixedPMCArray, but this isn't always the case. And then people get frustrated and angry
19:24 allison okay, what's a good way to get the clear overall vision?
19:24 NotFound whiteknight: well, not having push in Fixed is reasonable ;)
19:24 whiteknight allison: good question. Could set up a wiki page or a .pod in the repo
19:25 allison and, what will this vision look like? a wiki page? part of the PMC design doc?
19:25 whiteknight Maybe just a list: "These kinds of things do this: ..."
19:25 allison there is a list of core types in PDD17, so that may be a good place for these definitions
19:25 whiteknight as an elementary example: arrays are accessible by integer keys, pmc keys with get_integer, etc
19:26 whiteknight PDD17 is probably good, yes
19:26 cotto_work q1q
19:26 chromatic Who will work on that?
19:26 allison and then, are you willing to draft a start, and put it for the group to review?
19:26 whiteknight I'd be happy to make a draft
19:26 whiteknight or at least start one
19:27 whiteknight and then the bikeshedding can begin
19:28 japhb q1q
19:28 whiteknight EOQ
19:28 chromatic Other questions, whiteknight?
19:28 whiteknight no, that will cover it
19:29 chromatic japhb, your question.  (I have two, then we'll get back to cotto)
19:29 japhb I discussed this in #parrot a couple days ago,
19:29 japhb but I'd like to bring up here a frustration about our docs ...
19:30 japhb that I see as counter to the "production users" goal ...
19:30 japhb Basically, I believe that any documentation that is necessary to understand and use the public interfaces of Parrot
19:30 japhb (that is, anything covered by deprecation rules),
19:30 japhb should exist in docs/, and not in src/, or the wiki.
19:31 japhb I found this particularly acute myself with documentation for Parrot_call_ext and friends,
19:31 japhb but I would bet that it is a problem in general.
19:31 japhb Can we work to get this fixed for 2.0?
19:31 japhb Or is it too large of a problem?
19:31 japhb EOQ
19:31 whiteknight japhb: Just add more to docs/ or move some of the inlined documentation from src/ to docs/?
19:31 NotFound There is also a problem when functions are dpcumented in both parts... and in contradictoy ways.
19:31 Coke any user-visible docs in src should be put in docs via "make docs". if not
19:31 dukeleto can go out on a limb and say that parrotcode.org shows up before parrot.org in a google search and ALL THE DOCS ARE OLD AND WRONG.
19:32 japhb whiteknight, yes, both
19:32 japhb NotFound, YES, DEFINITELY
19:32 Coke parrotcode.org should be redirecting to parrot.org.
19:32 dukeleto whoever controls parrotcode.org : MURDER DEATH KILL
19:32 dukeleto Coke: we have gone over this before
19:32 Coke dukeleto: that's uncalled for.
19:32 Coke dukeleto: sure. is there a ticket in trac you can assign to me?
19:32 allison Coke: docs in src/ are copied into docs/
19:32 dukeleto Coke: the main site redirects, but when you search for individual pages, they come up first in google
19:32 dukeleto Coke: i can do that
19:33 japhb dukeleto, yes, we need to manage Google better.  But I'm more worried about docs/ being complete, correct, and non-contradictory (which I didn't mention above, but IIRC is true in several cases)
19:33 allison japhb: documentation is the primary goal on the roadmap for 1.9
19:33 Coke ok. there's no docs czar, so anyone can work on making things consistent. Certainly docs should be a high priority for a supported release.
19:34 Coke (1.9) excellent.
19:34 NotFound I think that ripping the perldoc from public documented api functions from the source files, and replace with "See PDD..."
19:34 allison japhb: and completely agreed
19:34 allison japgb: so, can we break that down into specific tasks
19:34 NotFound ...will be the solution.
19:34 japhb NotFound, yes, I was about to say that the PDDs and other docs need to work together better, but I'm fine with making PDDs canonical, if that's the consensus.
19:35 japhb allison, yep, I knew about the 1.9 milestone (you mentioned it in #parrot), but I wanted to bring it up here to get more visibility and discussion.
19:35 chromatic We also have to reject patches and block branches without sufficient documentation.
19:35 mikehh joined #parrotsketch
19:35 allison at the moment we're stuck in patching up limited documentation, it would be nice to start instead of what we want them to look like overall
19:35 japhb chromatic, +1
19:35 dukeleto chromatic: +1
19:36 cotto_work chromatic, +1
19:36 allison chromatic: good, but it's hard to judge "sufficient"
19:36 NotFound japhb: I think that two versions of the same doc that we never can have enough care to keep in sync can never work well.
19:37 japhb NotFound, No argument.  I was thinking more of "PDDs stick to pure design points, other docs have details", rather than the mix we have now.
19:37 allison NotFound: the docs in src/ are usually developer documentation, not really designed to make sense to the general user
19:37 chromatic It's easy to tell the difference between "does not exist" and "sufficient".  Right now, we have far too much "does not exist".
19:37 japhb allison, right, but someone using Parrot_call_ext for example should not need to read the parrot src/
19:37 japhb chromatic, agreed.
19:37 NotFound allison: Only the description of the public API functions, not all source comments and docs.
19:38 allison japhb: yes, exactly, the answer to a user question should never be "look at the PDD" or "look at the source"
19:38 allison japhb: those are answers to developers in "how should I implement X" or "how does Y work internally"
19:38 Coke allison: but a cut and paste of wonderful documentation citing the source would be OK. =-)
19:39 * mikehh this stupid internet connection is going to drive me insane - if not already past that point already
19:39 allison Coke: absolutely. :) that is, if we can find any wonderful user-targeted documentation buried in the source
19:40 allison but, I don't have a clear picture of how to write the user-documentation
19:40 chromatic Do we have concrete tasks to meet this milestone?
19:41 NotFound What do you call 'user'? I think someone using Parrot_call_text is not exactly a "..for dummies" reader.
19:41 allison that's someone trying to embed Parrot
19:41 japhb (sorry, typing derailed by rampaging toddler, effectively afk ATM)
19:42 allison user doesn't imply that they're a dummy, just that they shouldn't need to read the Parrot source code to figure out how to use it
19:42 allison call it "someone treating Parrot as a blackbox"
19:42 allison they need to know what it does, but not any deeper than that
19:42 allison and, the writing has to assume that they start off knowing nothing
19:42 NotFound Yes, and he just need a simple documentation of the function arguments, not a lot of literature.
19:43 allison really good example: http://www.python.org/doc/
19:43 NotFound Python embedding and extending doc is not bad, certainly.
19:44 dukeleto the parrot embedding docs leave a lot to be desired
19:45 mikehh joined #parrotsketch
19:45 NotFound dukeleto: and the code.
19:45 * mikehh lost it again
19:45 dukeleto mikehh: you should invest in a shell account with screen
19:45 allison chromatic: clear tasks... I can make creating a tasklist my task for the week
19:45 dukeleto mikehh: you can ask for one on feather.perl6.nl
19:46 chromatic A tasklist would be nice.
19:46 chromatic Let's move on.
19:46 NotFound I'll try to do some work with the extend/embed, at least to improve the examples with more features usage.
19:47 NotFound And the tests.
19:47 allison NotFound: the existing embed.pod may be too much of an API specification
19:47 NotFound allison: last time I tried, I needed to read the docs, the sources, and fill gaps.
19:48 dukeleto NotFound: i will start running into problems with our embed API when I embed Parrot in Postgres. You are first on my list of people to bug :)
19:49 NotFound dukeleto: I don't know anything about postgress. Other that this, I'm ready to help ;)
19:50 chromatic Question.  The :anon attribute of PIR subs hides visibility of the subs in the namespace *after* compile time, but .const directives and such can still refer to those subs by name.
19:50 chromatic Is this a problem?  Should they use :subid instead?
19:50 pmichaud .const should generally use :subid
19:51 pmichaud :subid should default to the name if no explicit :subid tag is given
19:51 pmichaud :anon should not affect either of those two items
19:51 pmichaud (this was the design we came up with earlier)
19:51 allison .const uses the same IMCC lookup as direct sub calls (not the namespace)
19:51 pmichaud that can't be completely right
19:52 pmichaud because const looks for subid, where as direct sub calls do not
19:52 pmichaud (afaik, they don't)
19:52 allison IIRC, when we talked about it, we said subid should be used for that storage (when :subid is set)
19:52 pmichaud I'm not sure that's accurate (more)
19:52 pmichaud const should always look up by subid
19:52 pmichaud subid should default to the sub name if not explicitly set
19:53 pmichaud this preserved traditional behavior, while making it possible to refer to a sub by something other than its name
19:53 pmichaud (especially needed for multisubs, where multiple subroutines may have a common name)
19:54 pmichaud just confirmed:  direct sub calls do not use the subid
19:54 allison agreed on that, I think the only question was whether IMCC should lookup by subid too
19:54 pmichaud direct sub calls only look at the name
19:55 chromatic If this is getting into a long design discussion, we can move it to #parrot.
19:55 pmichaud I'll be glad to continue on #parrot
19:55 chromatic I noticed the inconsistency the other day and wanted to bring it up.
19:56 pmichaud also confirmed that .const is looking up by both subid and name -- I think that const should only look up by subid
19:56 mikehh joined #parrotsketch
19:56 chromatic Next question: bacek's Context and CallSignature merge branch is blocking on a design question.  Who has the responsibility of creating that PMC and where does it happen?
19:56 pmichaud (since subid defaults to name, this shouldn't be an issue for previous uses of .const that were relying on name)
19:57 allison chromatic: ultimately, the responsibility is the caller's
19:58 allison that is, unlike currently, where the context is created inside invoke, if they're merged the context will be created long before reaching the invoke vtable
19:58 chromatic Seems reasonable.  I'll work with bacek on that.
19:59 chromatic cotto_work, you had more questions.
19:59 allison it will be created by the set_args op, or the equivalent C function
19:59 cotto_work What are the plans for implementing the security pdd?  We have a great PDD, but afaict there's been no work done on planning or implementing it since allison kicked it out of draft more than a year ago.
19:59 allison cotto: it's off the roadmap, but on AllisonTasklist
20:00 allison cotto: no specific timeline, and open for adoption
20:00 cotto_work ok
20:00 cotto_work eog
20:00 cotto_work eoq
20:00 chromatic Other questions?
20:01 chromatic Let's call this a week then.  Gentle reminder, nominate and vote on https://trac.parrot.org/parro​t/wiki/DevelopmentPriorities
20:02 PacoLinux left #parrotsketch
20:02 allison thanks all!
20:02 NotFound BTW, nothing to report other than two items in the release NEWS file.
20:05 NotFound left #parrotsketch
20:06 dukeleto ENOMOREDISHES
20:14 darbelo left #parrotsketch
20:22 Util left #parrotsketch
23:10 Whiteknight joined #parrotsketch
23:29 Whiteknight joined #parrotsketch

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