PDS Dec 05 2300 UTC !!! | Priorities for this week: PDS, Google Code-In, MappedByteArray test&merge, fix `make cover`, GC algorithm review | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irc.pugscode.org/
Set by moderator on 2 December 2010.
cotto one or two at a time we can handle 00:00
chromatic whiteknight's API work is a good time to update the API PDD.
whiteknight and a quarterly PDS meeting gives us plenty of time to prepare
chromatic It would be nice to have a single document which gives a good philosophical and design overview of a subsystem.
whiteknight chromatic: assuming there is community support to keep and merge my work, yes
it is a pretty radical change with unilateral design vision
chromatic Assuming so.
nwellnhof do we need PDDs at all? shouldn't we simply have one single documentation? 00:01
whiteknight nwellnof: good question. The Perl6 people might suggest that design before implementation is a good thing
assuming we implement for the design
chromatic Maybe we can retire the concept that the PDD is the design artifact created before any implementation.
cotto The design docs are helpful when they work.
chromatic, +1
whiteknight having something written to inform the decisions of developers is always beneficial
particle specs are important. see perl5 for the anti-pattern. 00:02
whiteknight whether it's worth the effort to prepare beforehand is the question
mikehh I think we still need design docs
particle hell, see imcc for an anti-pattern.
whiteknight but again, if we tackle one or two at a time when they are most relevant, we can really make use of them
chromatic Perl 5 and IMCC have the anti-pattern of "Whatever exists now you may use and we will support it."
mikehh like: this is what we want to do, then this is what we have done, etc
lucian what confused me at first was that PDDs aren't marked for up-to-date-ness or implementation 00:03
chromatic That's very different from "Thou shalt document what you will do and ratify the document before writing a line of code>"
kid51 lucian: I agree.
I started to re-read the PDDs in September after whiteknight started to rant about them.
but it was very difficult to determine which aspects of the design had been implemented, which abandoned, etc. 00:04
whiteknight exactly
atrodo i've wondered if the PDDs are too broad and all encompassing
whiteknight they have no real bearing on reality
plobsing they feel like armchair design to me
kid51 Are there parts of Parrot that are stable enough that we could write a "this is what we have designed" doc?
whiteknight if you have to flip a coin to determine whether each statement is true or false, the docs are worthless
lucian likes python PEPs
mikehh we definately need to re-structure them so that they do reflect reality
whiteknight yes, the PEPs are nice 00:05
Util Plans are worthless, but planning is everything. -- D.D.Eisenhower
chromatic I want to read something that says "Here's what this subsystem tries to do. Here are the assumptions we make. Here are consistent design elements. Here's how we structured the code."
whiteknight each is smaller, more focused, more up-to-date
particle plobsing: the io pdd was designed at the same time as the tests for the io subsystem
so there was a spec and tests, ready and waiting for the implementor. 00:06
mikehh I think that is the approach we need to work on 00:07
chromatic I have my doubts that that spec/tests first approach is viable.
mikehh that is if we are following a TDD approach 00:08
atrodo That approach is good if you want to rewrite a lot of docs and tests. not saying it's a bad thing but
particle i don't think it's viable now, but hand-in-hand approach for docs/tests is valuable
whiteknight The problem with our tests as they are now, is that they were all designed with the assumption that PIR was the star of the show and would always be a central part of Parrot
now we're looking for any opportunities to rip out PIR, but all the tests assume we have it and that it is lord 00:09
particle pir was the star of the show, and a big improvement over perl5
chromatic I suggest tabling *that* discussion while we talk about PDDs.
particle aye.
whiteknight particle: yes, no question that it was good for a while
but now it's clearly not the direction we want to keep going in
cotto Is anyone willing to update PDD0, which describes the PDDs?
particle i have three words for that: GCI
(for whiteknight, not cotto) 00:10
chromatic How would we update PDD 0?
What do we want out of PDDs?
cotto yes
kid51 is confused: In what sense is PIR going away (before I've ever learned it)?
particle reference docs for our next book.
chromatic Reference docs for users, embedders, hackers, language developers, or ... ? 00:11
kid51 Well, maybe someone could blog about that. BAck to discussion about PDDs.
nwellnhof if you have a look at docs.parrot.org/parrot/latest/html/ 00:13
say, you want to find docs about strings or IO, for example...
you have to look at the PDDs, the PMC docs, the developer docs... 00:14
that should be more centralized IMO.
whiteknight kid51: I
'll blog about PIR
and I'll try to avoid curse words
...actually, no. I make no promises about the verbiage
cotto +1 00:15
atrodo nwellnhof> I had exactly that problem when trying to decypher how to embed parrot. And most of the time, reading the headers or code was a better, more centralized refrence 00:16
kid51 Given my hope that we become more focused on Parrot as usable product, the documentation I would most like to see is: "This is our API; use it."
dukeleto kid51: PIR is not going away, but the implementation of PIR will change
kid51: IMCC is on a death bed, PIRC is the new implementation 00:17
cotto *cough*PIRATE*cough*
kid51 PIRC? Didn't we just expel it? Is anyone working on its?
dukeleto kid51: expel? It got it's own repo
PIRATE is what I meant. Sorry
dukeleto gets PIRC and PIRATE confused
cotto with hilarious results 00:18
kid51 Do we have any document or blog post that gives an overview of PIRATE?
Who is working on PIRATE?
Which team?
cotto I have enough familiarity with it to blog about it.
dukeleto kid51: no team is devoted to it
particle what's pirate?
dukeleto kid51: bacek was caring for it, but he has been concentrating on the GC
Util The work to replace IMCC is being done from a separate repo to boost visibility.
chromatic This is what I'd like PDDs to become: <kid51> Do we have any document or blog post that gives an overview of PIRATE? 00:19
dukeleto particle: PIR compiler using nqp-rx
kid51 learns something new every day ;-)
cotto I've had a hand in it too.
Util Soon we will need a diagram filled with boot straps.
particle right. i keep forgetting what it is, since pirate used to be a python impl on parrot 0.0*
cotto I think it's just us two.
particle, yes. I'm glad the name is getting a new life. 00:20
kid51 So, cotto, in terms of resource allocation: What's your focus among Lorito, MOP, PDDs and Pirate?
dukeleto has a commit bit to PIRATE, but hasn't done anything useful
atrodo \\
kid51 or, what should be *our* focus?
atrodo (sorry)
dukeleto IMHO: MOP, Lorito, Pirate, PDDs is the order of importance 00:21
cotto dukeleto, yes ( though the mop only came to the forefront relatively recently)
dukeleto Our MOP changes will dictate Lorito changes, so we should work on MOP first to minimize changing a bunch of stuff unnecessarily
cotto and the PDDs can be interspersed
kid51 (and add Garbage Collection to that list) 00:22
dukeleto cotto: it has been a blocker for a long time, but we only recently have decided to do something about it
cotto dukeleto, I'll be digging into nom as much as I can and will have that in mind while working out Lorito's design.
dukeleto cotto: awesome. We can compare notes.
Lorito and our new MOP will have interaction and they will not be worked on in insolate. 00:23
lucian i also think MOP is important. the main selling point of parrot is language interop
cotto it'll be fun
dukeleto isolation, rather.
diakopter cotto: at the top you mentioned you'd powpow with chromatic and allison to extract braindumps of lorito. do you have an idea of when that'll occur?
kid51 cotto: Can you describe what will be your main focus between now and, say, end of january?
dukeleto kid51: I think each parrot team needs it's own focus 00:24
kid51 Agreed. Wondering what the Architecture and Design Team's will be.
cotto 1) getting Lorito into an iterable state 2)understanding the MOP and how it'll work on Lorito 3)learning other parrot subsystems (and blogging)
diakopter, we're meeting this week 00:25
There may be other priorities. there's a good reason I use the wiki for external memory. 00:26
kid51 notes that we're about 90 minutes into the meeting -- and still have 2 pre-scheduled issues to discuss
dukeleto shall we move to the next issues? 00:27
cotto sure
kid51 The 2 pre-scheduled issues are API and 2011 summits. Which first? 00:28
chromatic summits will likely be shorter and faster
kid51 So here's the gist of my proposal 00:29
Quarterly summits, held on the 2nd weekend after each supported release.
which works out to last weekends of January April July October
cotto We should check that those don't coincide with important conferences. 00:30
kid51 Exact time within a given weekend to be worked out in preceding month.
Rotate start time among quarterly summits so that people in time zone X aren't unnecessarily inconvenienced
Pre-schedule certain issues for discussion. Example: API for today. GSOC 2011 plan for January. MOP plan for January (?) 00:31
dukeleto +1 to rotating times. That is a *great* idea.
kid51 That's the gist
cotto I'd rather try to use doodle and find something minimally inconvenient.
kid51 cotto: Do you agree about the quarterly scheduling?
dukeleto kid51: can we count on you to organize these PDS's? You seem to be the most organized. 00:32
cotto yes
kid51 yes
dukeleto Awesome.
kid51 Does anyone have an alternative vision of the "gist"?
particle please don't rely on one person for this. use group calendaring, task lists, and wiki pages for organizing. 00:33
and mailing lists.
dukeleto Next topic?
kid51 particle: I will use all those means. I will recruit deputies. Can I deputize you?
particle aye.
kid51 next topic: Whiteknight on API
whiteknight perfect timing
dukeleto particle: we use doodle to figure out a time, and try to share the burden. 00:34
whiteknight++ on his embed API write up.
whiteknight a few days ago I sent out an email about the current status of the API to the list. I hope most people read i
it
cotto very helpful
kid51 I liked it, though understood only parts
whiteknight The new API represents a lot of work but as I mentioned before it was entirely designed by myself so I want a lot of feedback before we start talking about merge or whatever else
kid51 and we'll need a lot of testing on all major OSes 00:35
whiteknight the embed_api2 branch is seeing some failures on darwin especially, but otherwise all primary development is complete
Util I like everything I read in the document, but need to spend time with the code.
kid51 "We should really be thinking about Parrot as two parts: libparrot (a language-agnostic bytecode interpreter and runtime) and the Parrot executable (the IMCC PIR/PASM front-end for libparrot). The Parrot executable now embeds libparrot using the new embedding API. And if the Parrot executable can do it, anybody else can too."
dukeleto queues up another topic: Parrot on Mobile platforms
kid51 good
Util +1 to the redesign of the embedded API, especially the libparrot/frontend separation. 00:36
Gentle reminder: Embed/Extend APIs are particularly needy of quality documentation, since their users will often have zero background in Parrot internals.
cotto dukeleto, queued
Util Q: Does the "die_from_exception" change mean that pbc_to_exe should start including code to dissect the Exception and dump its info to STDERR?
whiteknight Util: yes, spending time with the code is a very good idea. It is a very different API from what we used to expose
cotto i.e. useful
whiteknight Util: yes. I did add a basic implementatin to pbc_to_exe in the branch as an example
but it probably needs to be improved. src/main.c is my flagship tester
Util thx, will check both 00:37
chromatic Does this allow us to use PARROT_API liberally? 00:38
Does this allow us to remove several uses of PARROT_EXPORT?
dukeleto whiteknight: perhaps i can create a branch of PL/Parrot to use the new embed api?
kid51 whiteknight: Does your team have a timeframe for its development?
dukeleto whiteknight: so we can actually have rubber hitting the road?
Util: i have a TPF grant to write embedding docs and increase test coverage to 95%. I am on it. 00:39
Util dukeleto++
whiteknight kid51: like I said, primary development of the first wave is complete.
I would like to get it mergable by 3.0 if everybody likes it
there shouldn't be any deprecation issues
chromatic: I'm reserving PARROT_API for the API in src/embed/* 00:41
kid51 whiteknight Can you describe the extent to which this work has been a team effort?
whiteknight I can use a different designator if we need to reuse that one.
PARROT_EXPORT is for all other symbol exports (like the extending API)
kid51 Anything else on API? 00:43
chromatic What changes do Rakudo need? 00:44
dukeleto kid51: it has mostly been whiteknight and bluescreen, from what I can see
kid51: i have been looking on from the sidelines 00:45
kid51 dukeleto: That's my impression. Just trying to gauge whether concept of 'team' is working at all or not?
chromatic: Other than jnthn, I don't see any Rakudo folks here.
dukeleto kid51: a team of 2, it seems 00:46
kid51 which, to be frank, is better than we usually do
chromatic I meant Rakudo changes from the API changes.
dukeleto What rakudo seems to need more nowadays is consisten speed improvements.
kid51 chromatic: Well, then, I guess the question becomes: At what point does the new API have a form and docs we can present to Rakudo for feedback? 00:47
dukeleto We will keep Rakudo well informed of any API changes. 00:48
bluescreen_ kid51: From a newcomer standpoint teams was the perfect approach... as you have somebody mentoring you.. .otherwise the gap it too high
diakopter was the "random segfault when rakudo spectest" issue resolved?
kid51 bluescreen_: Very good feedback!
cotto bluescreen_, yes.
whiteknight the teams approach is working well, but you don't have a team form out of thin air. People have to volunteer and have the time to work on things 00:50
so several people were interested in the embedding work, but were busy or had other parrt things to work on
and that's fine, but we had a team of 2 and got a lot of good work done
bluescreen_ specially and this is something i want to bring up.. is the fact that is hard to grab a ticket from Trac... since there are a bunch of invalid tickets out there
whiteknight A team may mean 1 or 2 people , so we need to allow for that 00:51
kid51 invalid? in what sense?
bluescreen_ meaning that the either were already fixed, deprecated or things we won't implement 00:52
mikehh I'll accept 2 for a team, 1 is a bit of a problem
dukeleto Many trac tickets are old and have not been updated in so long as to be useless.
whiteknight mikehh: 1 is a "potential team"
the important part is that you plan to make it easy for more people to get involved
mikehh whiteknight: 'k, I'll go for that 00:53
whiteknight if the team leader creates some low-hanging fruit, people may come latch on to them
dukeleto I think we need to organize a culling of old Trac tickets, but that is a topic for another time.
dukeleto will need to go AFK soon
kid51 bluescreen_ I'm not surprised, but perhaps after whiteknight is done with you I can guide you in the "art of cage cleaning" ;-)
whiteknight dukeleto: good idea. The trac ticket queue is unmanagably large
bluescreen_ kid51 ;)
whiteknight and it is filled with crufty tickets that don't lead to any work being done 00:54
mikehh The art of getting rid of invalid Trac tickets
chromatic Are we under 600 now? 00:55
kid51 Yes
cotto it's not low enough
better but not good 00:56
chromatic That's good progress from earlier this year though. We've improved our velocity as of late and reduced our ticket count.
00:56 tcurtis left
kid51 Perhaps I could develop a proposal for a Cage Cleaning Week in which everyone suspends their "regular" Parrot work and focuses on tickets. 00:56
A once-a-year clearance sale!
cotto We should ticket validity criteria. Otherwise it'll be too subjective and we'll all worry about stepping on other people's toes. 00:57
dukeleto My philosophy: if a ticket looks stale (hasn't been updated in more than a year), just reject it. If it is important, it will be re-created with recent, relevant info.
bluescreen_ +1
kid51 dukeleto: I tend to agree with that ... but I have had my knuckles rapped when I've done that in the past.
To the point where there are certain people whose tickets I simply will not touch 00:58
whiteknight kid51: a spring cleaning of sorts would be appreciated
cotto one more thing for the queue: roadmap management
mikehh there are some tickets that are still valid but need some ways of handling them, opengl for one,native_pbc and others 00:59
cotto kid51, that's one of the reasons I want a set of generally accepted criteria
dukeleto Are we ready for our next topic?
kid51 It looks as if our discussion on API has petered out. whiteknight/bluescreen: Can you prepare a summary report on where things stand as of mid-January (3.0)?
whiteknight yessir
cotto dukeleto, go for it.
whiteknight side note: we should hammer out a policy on closing tickets. Because we have several users with very different (strongly-held) strategies, which leads to erratic-looking behavior 01:00
cotto whiteknight, noted
whiteknight cotto++ # note taking 01:01
cotto dukeleto, you wanted to talk about Parrot on mobile platforms, didn't you? 01:02
He must have gone afk. 01:03
kid51 cotto: If you're ready about roadmap, why not proceed
cotto sure
I noticed that we have a lot of roadmap tickets in trac that don't seem to be doing much good. Do we want to continue to track roadmap items via trac as we have been? 01:04
kid51 I confess I have not looked at roadmap in many months
dukeleto will start with the next topic
cotto dukeleto, go ahead
roadmaps& 01:05
dukeleto I am hacking on Parrot on Android
Util dukeleto: rooted?
dukeleto There is something called SL4A "Scripting Layer 4 Android"
it allows dynamic languages to run on non-rooted android phones 01:06
see trac.parrot.org/parrot/ticket/1881 for some details
basically, it allows writing scripts on phones with dynamic languages, that normally can't be used.
so it is a first step in porting Parrot. 01:07
so in the case of SL4A, Parrot would be running on top of Dalvik, not replacing it.
I think this is an important first step.
dukeleto is experiencing huge IRC lag, sorry
lucian dukeleto: uh, i don't think that's ow SL4A works 01:08
Util Sounds good; much better than Parrot->JVM transputing
dukeleto I am looking for people who want to be on a "Mobile Parrot" team
lucian right now, CPython for example runs alongside dalvik 01:09
dukeleto lucian: have you read the source of SL4A ?
lucian with a proxy to dalvik APIs
dukeleto: not recently
01:09 tcurtis joined
dukeleto Currently SL4A has ruby, python, javascript, perl 5, lua and a few other languages 01:09
lucian yes. a few run on Dalvik, a few others run natively + dalvik proxy 01:10
dukeleto Util: SL4A would basically expose Parrot or Rakudo Perl 6 as a scripting language for the phone
atrodo i assume that since perl5 is in there, a C layer is inovled?
dukeleto I think getting Parrot in SL4A is a babystep for getting Parrot into the mobile niche.
lucian atrodo: it just runs perl5
whiteknight if parrot were more mature, I might suggest we talk to google and try to *become* the next SL4 01:11
cotto It does look like a good first step.
whiteknight SL4A
but we're not ready for that yet
01:11 diakopter left
kid51 whiteknight: I know others who would agree with you 01:11
lucian whiteknight: i also think you're overestimating SL4A
dukeleto whiteknight: SL4A has nothing to do with google
Util dukeleto: I agree; best first step for Mobile; Palm and iOS are harder roads. 01:12
dukeleto lucian: sounds like I need you on the mobile team 01:13
whiteknight we obviously need working compilers for all those languages before we can look to replace existing runtimes for them
dukeleto SL4A has a hacked up copy of Perl 5 in their source tree.
lucian dukeleto: yeah, they've had to patch bash and CPython too
dukeleto SL4A usually requires modifications to the source of interpreters to actually work.
lucian because Android is ... let's say peculiar 01:14
java stuff is easier in SL4A though, JRuby and beanshell work almost unchanged, and with full access to the Android API (because it's all java)
Util hacked-up is not automatically a negative; most new ports of Perl5(etc...) start just that way, then the hacks get folded into the mother tree. 01:15
Perl5 on Win32 by ActiveState took that route. 01:16
kid51 dukeleto: Can I suggest that you and lucian work up a document which would be a game plan for us?
lucian dukeleto: btw, I'm somewhat familiar with android, but i have no low-level knowledge
kid51 Something that, say, starts out as blog posts and evolves into something on parrot-dev?
Sounds like something that would make good GSOC projects? 01:17
dukeleto Android is very peculiar, but it has become an important mobile platform.
I basically wanted to let everyone know that I am working on this stuff, and invite any and all to give feedback and help.
lucian: I want to recruit you. We need to interview the people who got Perl 5 on Android to work, and understand exactly what was needed.
kid51: sounds reasonable.
lucian: you up to give me some help on that document?
kid51: yes and yes and yes
kid51 And I'd like to have a document to show to other people (non-current-Parrot)
lucian dukeleto: sure, just be aware my free time is tight
Util dukeleto: will you work in a Parrot branch, or separate repo?
lucian however, don't be disillusioned that people will write Android apps on parrot any time soon 01:18
unless you're Java, you're not invited to the party
dukeleto lucian: that is fine. I would greatly appreciate any help you could give. 01:19
Util: not sure yet, does it matter?
lucian: i am not worried about that. I am interested in test-driving and benchmarking Parrot on a mobile platform.
lucian: i fully understand that. My end goal is to replace Dalvik. This is just the first step in that journey.
lucian dukeleto: that's also far off. although dalvik's GC sucks almost as much as parrot's :) 01:20
dukeleto lucian: Yes. I am thinking long term.
Util dukeleto: I just want to follow along. Got my first droid 2 weeks ago
dukeleto needs to go AFK. I will write up more info about Parrot on Android in a blog post soonishly. 01:21
Util: awesome! Will keep everyone in the loop.
lucian dukeleto: ping me if you need help
cotto any other thoughts on mobile parrot?
kid51 Thanks: This will be very interesting to follow.
cotto yes it will
dukeleto lucian: thanks, i appreciate it.
dukeleto will rejoin soon if PDS is still in progress. Excalibur! 01:22
kid51 Can we return to roadmap discussion?
Util mobile thought: Keep keeping kid51++'s "low memory platforms" ideas in mind.
cotto kid51, yes
kid51 my thoughts:
cotto The question pertained to whether we wanted to continue using the roadmaps as before. 01:23
kid51 There are only a few of us who really understand the project will enough to establish a vision, which a roadmap concretizes.
allison could do that.
whiteknight has some vision in his head
the rest of us mostly don't
whiteknight it really is a big project 01:24
kid51 cotto: I think this comes down to: What works for you as architect?
cotto I'll be thinking about that.
kid51 And whiteknight: What works for you as Product Manager?
whiteknight kid51: I
'm on the architecture team too 01:25
but yes, lots of things to keep in mind
kid51 We have a number of people who *could* be working on 6 major areas at once ... if they were paid to do it full-time.
cotto that'll be the day
mikehh roadmap items give a focus on what we would like to achieve by a given release 01:26
kid51 My concern is: What can we persuade cotto, whiteknight, bacek, duke, etc to *focus* on in, say, a given quarter.
cotto or to better phrase it, what can we agree to focus on
kid51 mikehh But I think that past roadmaps have amounted to little more than wishlists
mikehh good for guidance, not always achievable 01:27
cotto kid51, exactly. That's one of the negative criteria.
I've got that on my todo list. 01:29
any other topics?
plobsing q1q
kid51 Concretely: I think that if cotto and whiteknight discussed (off this channel) what you wanted over each of the next 8 quarters, that would be sufficient roadmap for the rest of us.
Anything more than that would be wishlist. 01:30
cotto 2 years is a long time, but we could figure something out for at least a subset of that
kid51 Actually, a realistic roadmap for 4 quarters is better than a wishlist for 8.
Thinking product-wise, what features do we want Parrot to have for each of the supported releases in 2011? 01:31
the answer to that question is our roadmp.
chromatic +1 to that
mikehh +1 01:32
kid51 So (to sound a familiar chord) can you and Andrew work that up in blog posts, then something on parrot-dev?
cotto sure
whiteknight I can work together with cotto on that
kid51 Excellent. 01:33
(I think plobsing's ? is next.)
cotto plobsing, go ahead
plobsing with more of parrot being implemented in parrot (very good thing IMHO), we expose more internals to the outside. Do we want to draw a line about stuff that cannot be touched and how do we want to do that? 01:34
cannot be touched by users
kid51 plobsing: Does this mean "a more strictly defined API" -- or something beyond that? 01:35
plobsing a good example is bytecode structure (which has been "experimental" since forever). experimental isn't a good classification for such things.
chromatic How about "a supported API" and "supported semantics"?
kid51 chromatic: Can you explain supported semantics?
plobsing kid51: a strictly defined API is sort of what I'm getting at. It's something along the lines of "yes, we know you can poke that, but don't whine at us when we change it". I just want to leave us wiggle room. 01:36
chromatic Sure. Suppose we never document that if you pass a STRING to Parrot_pmc_register() the STRING gets registered as live with the GC. Anyone who does that and expects that always to continue working is just out of luck. 01:37
whiteknight we have multiple levels of API, and first step is to define what those are
we have embedding API, extending API, bytecode API, etc
lucian an 'internal' namespace or similar would be nice
cotto chromatic, lol
something like PARROT_INTERNAL? 01:38
as a macro
lucian cotto: i guess. i'm not familiar with parrot C code
plobsing cotto: C functions aren't the only things that are internal though 01:39
ImageIO pmcs, Packfile pmcs, bytecode in general, lorito bits, etc...
whiteknight we've explicitly defined that structure internals should be opaque outside of core parrot
chromatic Does our deprecation policy say "Everything not explicitly supported isn't"? 01:40
cotto we could create an extra pmclass modifier "internal", though I'm not sure how we'd use it apart from documentation.
whiteknight chromatic: no. Nothing is explicitly supported 01:41
that's been my biggest beef with the deprecation policy
it's extremely vague and broad about what we cover
plobsing I'm thinking about the ImageIO pmcs in particular, with which I'm fairly certain I've broken dep-policy several times (but nobody noticed, because they really are internal). 01:42
whiteknight plobsing: so that's a good point. Maybe all PMC types are not external
mikehh how about this is the api, that will be subject to deprecation notices etc
cotto whiteknight, do you think marking PMCs as explicitly internal is workable? 01:44
For functions it's probably too much effort.
whiteknight cotto: we can't prevent people from using them, but we can declare that they don't have a stable API for users 01:45
use at your own risk, etc
cotto of course
whiteknight a simple idea would be to prefix certain type names with an underscore 01:46
_ImageIO, to let people know it's internal-only
cotto Simple yet ugly.
chromatic Ugly yet ugly.
whiteknight like in libc, things with _ are not intended for users
or we could set a flag
PObj_DONT_FREAKING_USE_THIS_FLAG 01:47
cotto POBJ_WE_WILL_SOMETIMES_SHUFFLE_INTERNALS_WITHOUT_REASON_OR_WARNING_FLAG
plobsing what would a runtime flag accomplish? I much prefer something static unless there's a benefit to the flag. 01:48
whiteknight plobsing: we can check the flag in the PIR op to prevent PIR code from instantiating that type 01:49
that's if we really want to make certain PMC types internal-only
if we don't want to go to lengths to prevent it, we need a cultural instead of a technical solution
01:49 tcurtis left
mikehh warning - thisa is an internal function/PMC 01:50
kid51 bbial
chromatic I haven't seen any proposals I love yet.
plobsing We're all grown ups here. If a user really wants to use an internal functionality, and accepts the risks, they should be able to.
cotto They just shouldn't be able to do so without knowing what they're doing.
whiteknight right, the difference is whether we need to jump through hoops when we change the interface for it
for ImageIO, we don't want to do that 01:51
some things we support externally, some we don't
chromatic Let's document what we support and disclaim what we don't.
mikehh +1
whiteknight EXACTLY
lucian almost likes _ImageIO
cotto chromatic, +1 01:52
plobsing +1 to document. where? DEPRECATED.pod? PMC source? other?
cotto support policy seems like the most natural place
whiteknight I've always wanted to have an explicit list of things we supported. A dedicated file for that would be fine
chromatic Yeah, the support policy document.
whiteknight some things are obvious: src/embed/*, src/embed.c, src/extend.c 01:53
dynpmcs
dynops
chromatic I volunteer to make a document listing what we need to consider when we merge a feature branch. 01:54
whiteknight chromatic++
cotto thanks
mikehh we should have a "supported" set of tests for that as well
whiteknight better yet, it isn't supported without a test
so that we know exactly what behaviors we support 01:55
mikehh I was thinking along the lines of api tests to see if we break anything with merges/changes
plobsing whiteknight: I like that idea, but I don't want our testsuite to take as long as rakudo spectest
whiteknight plobsing: good point. Some kind of triage of existing tests may be nice 01:56
some of ours, like the ops parsing ones, already take way too long
mikehh different aspects of the testsuite
whiteknight or different test targets 01:57
coretest vs test, etc
mikehh in that regard the original concept of core has changed a bit 01:58
especially as we use nqp-rx more and more
whiteknight yes 01:59
kid51 notes that we've reached the 3-hour point in this meeting 02:00
whiteknight it seems like we still have some steam. Do we want to continue the meeting? Move to #parrot? call it quits? 02:01
cotto keep on
Util Key question: are we on the last topic for this PDS?
whiteknight okay, good
cotto Util, I got that impression. 02:02
kid51 We have discussed all pre-scheduled topics.
Util keep on
kid51 We are in the "any other business/questions" phase (and have been so for > 1 hour 02:03
cotto Is the deprecation/support question sufficiently resolved? 02:06
chromatic For now I'm satisfied.
Util cotto: I think "enough to move forward"
cotto ok. Any other questions? 02:07
Util I move to adjourn :) 02:09
whiteknight second
cotto It's over.
mikehh good session overall
Util Time well spent. 02:10
cotto agreed
kid51 I will post to parrot-dev a summary focusing on action items, ie.. what people promised they would do 02:11
Util kid51++
whiteknight kid51: great. All I need is a reminder of all the stuff I promise to do
lucian and then some beer to cope with it? :) 02:12
atrodo kid51++ # Very good job 02:13
02:22 lucian left 02:32 nwellnhof left
dukeleto still going? 02:42
plobsing nope. sorry.
dukeleto plobsing: ok, thanks for letting me know :) 02:43
02:43 dukeleto left 03:22 bluescreen_ left 03:44 kid51 left 03:53 atrodo left 04:03 whiteknight left 04:04 plobsing left 06:33 PerlJam left, PerlJam joined 06:45 cotto is now known as clock 06:46 clock is now known as cotto 07:54 bacek joined 08:12 chromatic left 09:28 lucian joined 11:34 lucian left 12:00 lucian joined 12:12 lucian left 12:18 lucian joined 13:43 bluescreen joined 15:53 bluescreen left 16:01 PerlJam left 16:02 PerlJam joined 16:10 bluescreen joined 18:26 bacek left 21:55 bluescreen left 22:30 lucian left 22:31 lucian joined 23:38 kid51 joined 23:39 whiteknight joined 23:47 bluescreen 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!