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 14 November 2009.
00:19 Whiteknight joined 00:56 particle joined 01:25 particle joined
japhb DONE: 08:42
* Support fperrad++'s setup.pir system in Plumage
* Fix several portability issues, leading to ...
* ... Plumage's first successful clean test run and project install on Win32!
* Much more use of new NQP-rx features
* Add simple version of 'status' command
* Commit metadata additions/edits from fperrad++
* Reorganize more of the tests to make it easier to identify testing gaps
MAD PROPZ:
* fperrad++ # setup.pir, Win32 testing, new & improved metadata ...
* pmichaud++ # NQP-rx features, w00t!
NEXT UP:
* More tests -- hopefully lots more, if my fellow committers have some spare cycles (hint, hint)
* Several major refactorings just got unblocked by pmichaud++'s NQP-rx variable handling improvements
* Depending on progress of above refactorings, back to adding new user-visible functionality again
BLOCKERS:
* Currently unblocked ...
* ... but always happy to see new features from wiki.github.com/perl6/nqp-rx/plumage-requests
* ... 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
EOR
GRRRRRRR 08:43
... OK, trying this again, slower ...
DONE:
* Support fperrad++'s setup.pir system in Plumage
* Fix several portability issues, leading to ...
* ... Plumage's first successful clean test run and project install on Win32!
* Much more use of new NQP-rx features
* Switch over to parrot-nqp, no longer following NQP-rx git master directly
* More Glue.pir -> Util.nqp conversions
* Refactor action functions to reduce pointless duplication
* Add simple version of 'status' command 08:44
* Commit metadata additions/edits from fperrad++
* Reorganize more of the tests to make it easier to identify testing gaps
MAD PROPZ:
* fperrad++ # setup.pir, Win32 testing, new & improved metadata ...
* pmichaud++ # NQP-rx features, w00t!
NEXT UP:
* More tests -- hopefully lots more, if my fellow committers have some spare cycles (hint, hint)
* Several major refactorings just got unblocked by pmichaud++'s NQP-rx variable handling improvements
* Depending on progress of above refactorings, back to adding new user-visible functionality again
BLOCKERS:
* Currently unblocked ...
* ... but always happy to see new features from wiki.github.com/perl6/nqp-rx/plumage-requests
* ... 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
EOR
09:01 davidfetter joined 09:16 einstein joined 10:07 mikehh joined 11:54 bluescreen joined 13:42 bluescreen joined 14:16 einstein joined 14:23 bluescreen joined 15:31 whiteknight joined
whiteknight WHAT I DID 16:30
* (pla) Fixed installation and major cleanup throughout.
* (pla) Added a new CharMatrix2D type, which bridges a small gap between an array of strings and a matrix of numbers. Necessary for Matrixy
* (pla) Added a new ComplexMatrix2D type
* (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"
* (matrixy) Finished the pla_integration branch and merged into trunk. 16:31
* (matrixy) Fixed the way matrices of different types are generated
* (matrixy) Now passes almost all tests that we were passing before the split/refactor
* (matrixy) Added preliminary Cell Array support using the new PMCMatrix2D PMC type from parrot-linear-algebra
* (parrot) Closed out my remaining RT tickets.
* (parrot) More testing on the libjit_framebuilder branch.
* (parrot) Trying to [finally] fax in my CLA. Tried 3 times now with various errors. Will end up snail-mailing it.
WHAT I WILL DO
* (pla) Test, Test, Test
* (matrixy) Finish adding Cell support, and test
* (matrixy) General cleanup
* (parrot) Add proper :call_sig support for both callee and caller. Add tests
* (parrot) Try to convert more tests from Perl5 to PIR
WHAT I AM BLOCKING ON
* Nothing
Queue 3 Questions
EOR
16:32 darbelo joined 16:57 cotto joined 17:33 NotFound joined
dukeleto What I have Done: 17:55
* Played patch monster for some Perl->PIR test conversions.
* Started the nqptap project, an self-contained TAP test harness written in NQP-rx
github.com/leto/nqptap
* Made progress with PL/Parrot. We now have a functioning 'create language' and
'create function', but no type marshalling or parsing is being done yet. The test
suite will be written in SQL+pgTAP : leto.net/dukeleto.pl/2009/11/parrot...abase.html
* Made small amount of progress with Kea (Factor on Parrot). Still playing learning NQP-rx.
What I will Do:
* More of the same
Blocking On:
* Life 17:56
EOR
darbelo ENOREPORT 17:58
ENOTUITS
.end
dukeleto will try to be back, but has other meetings 17:59
18:01 kj joined, pmichaud joined
pmichaud I will likely miss #ps today -- will post my report when I return. 18:01
18:10 Coke joined, barney joined
Coke Done: 18:12
- RT is gone. Long live TT.
- Updated docs.parrot.org for 1.8.0 release
- added http download links to parrot.org/download
Blockers:
- parrot segfaults blocking partcl
barney Done: Managed release of Parrot 1.8.0 18:17
.eor
18:20 Util joined
cotto_work #done 18:20
* started seriously thinking about how to test the profiling runcore
* made FileHandles store/expose the exit status when running an external command
* this allows basic "Did it explode?" testing of external commands while still capturing output
* started to port pprof2cg.pl to nqp
* spammed the wiki about how Lorito should be opcode-based 18:21
#gonna do
* continue getting pprof2cg.nqp implemented
* learn nqp
* after the profiler is sufficiently awesome, start back on opsc/pmcc with bacek++
#blockers
* rl
eor
q2q
Util # Done:
* TODO-ed a failing op/number.t test that was failing on platforms lacking negative zero.
* Tested 1.8 on MinGW, MSVC 2002, and MSVC 2005. 18:22
* Found issues with todo() in PIR; most uses of it are flawed. Ticket later today.
# Plan for this week:
* Finish TT#1217 , TT#1218 !
* Work to resolve the PIR todo() problem, and possibly its API.
# Blockers:
* Tuit shortage
.end
18:23 allison joined
allison Last week: 18:24
- 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.
- Continuing working my way down AllisonTasklist.
Next week:
- Knock a few more tasks off the list.
Blocking on:
- Time.
EOR
mikehh What I did in the last week: 18:28
* building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
* fixing tests
* testing for release
What I intend to do in the next week:
* testing and fixing
* continue working on checking skipped tests
.eor
18:31 chromatic joined
whiteknight hello 18:32
chromatic good localtime()
mikehh hi there
Util hello
Coke ~~
cotto_work hi
allison hi 18:33
darbelo Hola
chromatic Question to ponder, but don't answer yet. What's the most important thing we can accomplish for 2.0?
barney hi
chromatic Let's review last week's priorities.
How did ops testing go?
whiteknight I did a little. Saw other people doing stuff too 18:34
more or less a success, but hardly rose to the level of "hackathon"
mikehh ditto
cotto_work agreed
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
chromatic Let's review the 1.8 release. 18:36
What went right?
mikehh I am not sure - I spent quite a bit of time on it, nothing like the pcc_reapply hackathon
cotto_work It got out the door, before #ps even. 18:37
whiteknight 1.8 appeared to go very smoothly
barney release instruction were pretty good
whiteknight and quickly
chromatic How about the month of work leading up to 1.8?
NotFound Late again.
whiteknight month went well. Seemed a little slower in my estimation 18:38
NotFound Me, not the question.
chromatic What didn't go right?
barney Some smoke test failures for Win(32|64) 18:39
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.
chromatic They've been slipping from release to release. 18:41
whiteknight yes, windows support still seems very fragile most months
we definitely need to improve testing there
chromatic Anything else? 18:43
allison it's worth reexamining the tasks and deciding if they really are a priority for 2.0
Coke we already have smokes coming in for windows pretty regularly that are not acted upon.
mikehh I've been testing and fixing on linux amd64/i386 but sometimes fixing breaks on MSWin 18:44
allison would a windows testing server be useful, or would people not use id? 18:45
it
mikehh some of the high priority items have slipped over the last 3 releases or so
darbelo What we need the most is people that really know windows. 18:46
NotFound These are Windows problems MSVC problems, or both?
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.
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
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
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
chromatic: in theory, yes, in practice getting access is a long and involved process
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
allison but, I do think windows testing is approaching "critical" on our list
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.
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?
allison has no desire to maintain a windows server if I can avoid it 18:51
cotto_work allison, I'll do that.
I'll stick something on the wiki.
allison cool, thanks! 18:52
chromatic That gets us into the third questoin.
*question
What do we need to change this month?
Util I can move from general Parrot work to Win32-specific. I had not perceived the need prior to this.
whiteknight clear priorities
and clear plans to address them 18:53
chromatic Do we have a single list of potential priorities?
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
NotFound whiteknight: but it took months to reach that point.
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
cotto_work a long period of pain is an excellent motivator
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
NotFound I mean, the point it got clear that that was becoming the bigger blocker.
Coke I would like to see all the language issues at least touched this week. (trac.parrot.org/parrot/report/16)
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.
Okay, let's summarize that then. 18:58
I'll create a Wiki page RIGHT NOW called DevelopmentPriorities.
Everyone gets to put one on the list.
whiteknight +1
chromatic We'll vote and figure out what we most need to work on and then we'll do it.
Coke one what... ticket?
chromatic One priority.
whiteknight one priority
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.
whiteknight I disagree. big nebulous tickets are non-value
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.
cotto_work Should we be adding names to our requests?
chromatic If you want.
whiteknight chromatic: +1 on sufficient detail and individual 1-2 hour tasks
chromatic Okay, the page is there. 19:01
Let's move on.
cotto, you had a question.
cotto_work Can it be Array deprecating time now please?
NotFound +1 19:02
allison which to deprecate?
mikehh you can't have everyone working on the same 1-2 hour task
cotto_work (in favor of RPA, which does the same thing but doesn't pretend to be type-agnostic)
allison, Array
(as in src/pmc/array.pmc
)
allison just the one base class?
ah, sure, it's not particularly useful 19:03
cotto_work Great. I'll file a tt.
Coke +1 on removing at least one of the many array types. =-)
NotFound And his supporting C routines, I suppose.
mikehh we need somthing lixe x tasks and assign/volunterer for specific tasks
allison someday I'd like to deprecate a pile of them, but one is a good start
mikehh like
Coke mikehh: assigning tasks can be done via trac.
cotto_work eoq 19:04
mikehh Coke: something like that
cotto_work For clarification, is the 2.0 release being designated as production-ready?
NotFound Sometimes I think even C is not yet production ready. 19:05
Coke cotto_work: what does that mean?
it's a 'supported' release, anyway.
allison cotto: as targeting production users, yes
"production ready" is vague
Coke Given that we still haven't hit our "stable for HLL users" yet, that seems pretty ambitious.
allison could mean any number of different things
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
allison we did hit what we said, that HLL users could use only supported releases, for a more stable 6 month cycle
(which was all we promised)
Coke ok, then 'the roadmap tickets are too vague'. =-)
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.
allison so, it's important to be clear on what we mean for 2.0 19:07
Coke agreed!
cotto_work yes
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
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
Coke 1) go through the existing roadmap items.
2) See if there are new roadmap items.
allison (largely because it's been our focus for the past several months)
mikehh What's a production user - rakudo?
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
because we are working off a very old roadmap at this point
Coke mikehh: no, that's just 'user'.
NotFound I don't think performance is actually so bad.
Coke NotFound: FSVO bad.
whiteknight bad compared to where we were a few months ago
Coke I find most HLLs seem pretty slow still compared to their non-parrot counterparts. No? 19:10
whiteknight very much so
Coke (PIR is fast. but no one "in production" is likely to use straight PIR, are they?)
allison the new nqp will help with that
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.
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
dukeleto back
whiteknight neither project operates in a vacuum
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
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
chromatic: let me know if you need benchmarks/valgrind output for things
whiteknight dukeleto: agreed 19:13
chromatic cotto_work, you had a second question.
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
NotFound If you need a motivational example: Winxed hand written parser is fast.
dukeleto i think parrot needs to have a community decision about what we consider "production" 19:14
cotto_work chromatic, that was it.
dukeleto then focus on those features for the next 2 months
chromatic whiteknight, you had a question.
whiteknight 3 of them 19:15
1) Can we deprecate the Array PMC type?
NotFound +1 again
whiteknight I saw a ticket with some info from 2008, but I want to get back to the issue
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.
whiteknight so we lose performance in exchange for better memory use on large, sparse arrays
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.
whiteknight which itch?
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
yes, let's deprecate Array
whiteknight excellent. Any decision would have been better then keeping it in limbo. But I'm happy to see it go
cotto_work whiteknight, the itch for sparseness 19:19
whiteknight Okay, second quesion:
cotto_work I'm writing the tt now.
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?
I see a lot of cases where people expect more consistency between like-types then we currently provide
allison a lot of the PMC types would benefit from being deprecated and removed, which may qualify as the vision for them
whiteknight that would be fine too 19:20
allison (or moved to dynpmcs)
NotFound For example, Integer array has no push method, others have.
Coke NotFound: push vs. not is a long standing issue. (see also: "does is not useful")
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
so clarification on points like that would always be good and help move things forward
and clarification on what the various "provides" roles in PMCs mean 19:21
etc
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
NotFound Coke: I'm not for push vs not push ATM, but for consistency.
whiteknight exactly.
Coke NotFound: ... yes, that's been my complaint all along.
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.
allison whiteknight: wait, that's on set_pmc
whiteknight: that's not autovivification, that's just storing a value 19:23
whiteknight allison: there are dozens of tickets at least tangentially related
allison (set_pmc_keyed)
whiteknight any particular case doesn't matter. What we need is clear overarching vision for what kinds of behaviors the various types should implement
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?
NotFound whiteknight: well, not having push in Fixed is reasonable ;)
whiteknight allison: good question. Could set up a wiki page or a .pod in the repo
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: ..."
allison there is a list of core types in PDD17, so that may be a good place for these definitions
whiteknight as an elementary example: arrays are accessible by integer keys, pmc keys with get_integer, etc
PDD17 is probably good, yes 19:26
cotto_work q1q
chromatic Who will work on that?
allison and then, are you willing to draft a start, and put it for the group to review?
whiteknight I'd be happy to make a draft
or at least start one
and then the bikeshedding can begin 19:27
japhb q1q 19:28
whiteknight EOQ
chromatic Other questions, whiteknight?
whiteknight no, that will cover it
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,
but I'd like to bring up here a frustration about our docs ...
that I see as counter to the "production users" goal ... 19:30
Basically, I believe that any documentation that is necessary to understand and use the public interfaces of Parrot
(that is, anything covered by deprecation rules),
should exist in docs/, and not in src/, or the wiki.
I found this particularly acute myself with documentation for Parrot_call_ext and friends, 19:31
but I would bet that it is a problem in general.
Can we work to get this fixed for 2.0?
Or is it too large of a problem?
EOQ
whiteknight japhb: Just add more to docs/ or move some of the inlined documentation from src/ to docs/?
NotFound There is also a problem when functions are dpcumented in both parts... and in contradictoy ways.
Coke any user-visible docs in src should be put in docs via "make docs". if not
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.
japhb whiteknight, yes, both 19:32
NotFound, YES, DEFINITELY
Coke parrotcode.org should be redirecting to parrot.org.
dukeleto whoever controls parrotcode.org : MURDER DEATH KILL
Coke: we have gone over this before
Coke dukeleto: that's uncalled for.
dukeleto: sure. is there a ticket in trac you can assign to me?
allison Coke: docs in src/ are copied into docs/
dukeleto Coke: the main site redirects, but when you search for individual pages, they come up first in google
Coke: i can do that
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
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.
(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..."
allison japhb: and completely agreed
japgb: so, can we break that down into specific tasks
NotFound ...will be the solution.
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.
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
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
dukeleto chromatic: +1
cotto_work chromatic, +1 19:36
allison chromatic: good, but it's hard to judge "sufficient"
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.
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
chromatic It's easy to tell the difference between "does not exist" and "sufficient". Right now, we have far too much "does not exist".
japhb allison, right, but someone using Parrot_call_ext for example should not need to read the parrot src/
chromatic, agreed.
NotFound allison: Only the description of the public API functions, not all source comments and docs.
allison japhb: yes, exactly, the answer to a user question should never be "look at the PDD" or "look at the source" 19:38
japhb: those are answers to developers in "how should I implement X" or "how does Y work internally"
Coke allison: but a cut and paste of wonderful documentation citing the source would be OK. =-)
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
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?
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
japhb (sorry, typing derailed by rampaging toddler, effectively afk ATM)
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
call it "someone treating Parrot as a blackbox"
they need to know what it does, but not any deeper than that
and, the writing has to assume that they start off knowing nothing
NotFound Yes, and he just need a simple documentation of the function arguments, not a lot of literature.
allison really good example: www.python.org/doc/ 19:43
NotFound Python embedding and extending doc is not bad, certainly.
dukeleto the parrot embedding docs leave a lot to be desired 19:44
19:45 mikehh joined
NotFound dukeleto: and the code. 19:45
mikehh lost it again
dukeleto mikehh: you should invest in a shell account with screen
allison chromatic: clear tasks... I can make creating a tasklist my task for the week
dukeleto mikehh: you can ask for one on feather.perl6.nl
chromatic A tasklist would be nice. 19:46
Let's move on.
NotFound I'll try to do some work with the extend/embed, at least to improve the examples with more features usage.
And the tests. 19:47
allison NotFound: the existing embed.pod may be too much of an API specification
NotFound allison: last time I tried, I needed to read the docs, the sources, and fill gaps.
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:48
NotFound dukeleto: I don't know anything about postgress. Other that this, I'm ready to help ;) 19:49
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
Is this a problem? Should they use :subid instead?
pmichaud .const should generally use :subid
:subid should default to the name if no explicit :subid tag is given 19:51
:anon should not affect either of those two items
(this was the design we came up with earlier)
allison .const uses the same IMCC lookup as direct sub calls (not the namespace)
pmichaud that can't be completely right
because const looks for subid, where as direct sub calls do not 19:52
(afaik, they don't)
allison IIRC, when we talked about it, we said subid should be used for that storage (when :subid is set)
pmichaud I'm not sure that's accurate (more)
const should always look up by subid
subid should default to the sub name if not explicitly set
this preserved traditional behavior, while making it possible to refer to a sub by something other than its name 19:53
(especially needed for multisubs, where multiple subroutines may have a common name)
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
pmichaud direct sub calls only look at the name
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
chromatic I noticed the inconsistency the other day and wanted to bring it up.
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
19:56 mikehh joined
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)
allison chromatic: ultimately, the responsibility is the caller's 19:57
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.
cotto_work, you had more questions. 19:59
allison it will be created by the set_args op, or the equivalent C function
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.
allison cotto: it's off the roadmap, but on AllisonTasklist
cotto: no specific timeline, and open for adoption 20:00
cotto_work ok
eog
eoq
chromatic Other questions?
Let's call this a week then. Gentle reminder, nominate and vote on trac.parrot.org/parrot/wiki/Develo...Priorities 20:01
20:02 PacoLinux left
allison thanks all! 20:02
NotFound BTW, nothing to report other than two items in the release NEWS file.
20:05 NotFound left
dukeleto ENOMOREDISHES 20:06
20:14 darbelo left 20:22 Util left 23:10 Whiteknight joined 23:29 Whiteknight 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!