Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 29 January 2009.
12:03 kid51 joined
kid51 * Preposting because I'll be at $job during meeting time, as usual. 12:04
* Sinus cold kept me inside but made real thinking painful.
* So I decided to plow through old RTs instead. Much easier on the sinuses.
* Focused mainly on those filed in last 3 months of RT's heavy use. 12:05
* Tended to close tickets which merely reported build errors on Linux or Darwin.
* Identified some where the discussion appeared left up in the air, requested update from discussants.
* Identified others where a quick review from a core committer would probably lead to resolution. (Mainly: allison, particle, coke, infinoid, pmichaud)
* One or two that I can work on myself.
* So if you were nudged or nagged by my postings this weekend, please take a look. Aiming to get below 500 RTs open/new/stalled. (529 as of 0316 UCT today).
* Also, we will need to develop a plan to address the dozens of RTs opened by PTC for XXX or TODO items. Some of the TODO comments may simply have been random musings by Parrot developers in eons past. Someone with extensive Parrot history could probably evaluate them quickly. 12:06
* Also, if you're making changes in lib/Parrot/*.pm, please run perl Configure.pl --test before committing to make sure you're not breaking any tests.
* Also, we should urge use of branches for changes that have potential either to break build or cause new failures in 'make test' that can't be resolved in less than an hour. 12:07
EOR
12:25 integral joined 16:10 davidfetter joined 16:21 pmichaud joined
particle i'll likely miss #parrotsketch due to a schedule conflict. 16:33
~ modified config subsystem to allow the use of ccache on windows, with msvc, icc, bcc, and mingw 16:34
.end
please do a review of roadmap tickets in my absense--i'll try to update mine before the meeting, but this may not be possible.
17:18 kj joined
kj preposting my non-report, as I won't make it for #ps: 17:19
no report.
.eor\\
17:19 kj left, masak joined 17:24 rurban joined 17:56 PacoLinux joined 17:58 Whiteknight joined 18:11 Tene joined 18:19 allison joined 18:24 masak joined 18:29 barney joined
cotto HI. 18:30
masak tja! 18:31
barney Servus
rurban hi 18:32
pmichaud hello.
18:33 chromatic joined
Whiteknight hello 18:35
chromatic Who else is here?
pmichaud Present. 18:36
masak here
cotto too
rurban also
allison hi
chromatic Okay, let's go.
allison?
allison - A successful migration of the subversion repository to svn.parrot.org.
- Took up chromatic's ticket challenge and closed a handful a day, applying patches, fixing bugs, clearing out some old TODOs that don't fit with current architecture. 18:37
- Started, completed, and merged in the second string refactor branch, a large-scale function name cleanup.
- A few fixes on the Pod parser, mostly handed it off to kj (with thanks).
18:37 mberends joined
allison EOR 18:37
chromatic barney? 18:38
barney Was and will be busy with new freelance project.
[Pipp]
Added 'standard' and 'Reflection' to get_loaded_extensions().
Re-added support for the phc variant, as James Dupont wants to hack on it.
Plan to move to github this weekend
.eor
chromatic I didn't make much progress.
cotto?
cotto * making slow but steady progress converting PMCs to use ATTR instead of UnionVal macros
* found 2 moderately obscure bugs that I initially missed due to poor formatting of test results
* also found one wierd PCC bug after converting FixedIntegerArray
* am pausing to improve Parrot's test reporting (or get someone else to do so) to avoid more such bugs
* also, attempting to fix any bugs I cause
goto NEXT();
chromatic japhb? 18:39
18:39 Coke joined
chromatic Coke? 18:39
Coke hio. I apparently need a calendar reminder for this meeting. 18:40
I have tried to pull out some more deprecated features in the past week. Tcl is currently failing a bunch of tests against parrot trunk and I haven't figured out why (could be my fault.) working on some
documentation of sorts that will hopefully hit this weekend. 18:41
.
chromatic masak?
masak * big refactor of Druid, taking advantage of some of the OO stuff
* found about the usual number of bugs
* ...with the normal distribution of nastiness
* looking forward to someone acting as a counterweight to my bug reporting :)
eor
chromatic pmichaud
pmichaud Got distracted with various family things this past week. 18:42
Been mainly focusing on adjusting the rakudo repository and re-designing its build sequence.
I expect to have that fairly complete by Thursday.
other than that, just cleaning things up and preparing for Frozen Perl.
EOR
chromatic rurban?
rurban - Shook native_pbc: Enabled t/native_pbc/integer.t and number.t tests to get
this fixed before 1.0.
Found at least 3 bugs with 64-bit, and fixed one and a half, TT #254.
This caused some smokes to blow up but now it should be settled.
I can reproduce all yet detected bugs. I work on solaris-64int on this.
But I still need a bigendian 64int box for smokes and native pbc's, and 18:43
for the funky floattype 1 (12-byte double BE).
- Added missing @linkflags@ to the linker, detected on solaris-64int, TT #262
- Need review for a pbc_disassemble roundtrip patch with new options --bare -b, ...
(assembable disassemblies) => TT #258
- Need review for a PackFile API rename patch: Parrot_loadbc => Parrot_pbc_load,
Parrot_readbc => Parrot_pbc_read plus one new debug argument. => TT #266
Thanks to particle. I need the 3rd arg for easier packfile debugging.
- Created parrot MSVC6 project files (dsp/dsw) which might be of use to someone.
Some files allow /ZI ("Edit and Continue"), some not. #include .str fails
- I'll produce a single RT #40817-track-generated-files against trunk, again.
EOR
chromatic Tene?
Whiteknight? 18:44
Whiteknight * Doing some misc GC-related cleanups
* Going through a lot of old tickes, performing triage and getting things resolved
* Misc twiddling on the various books.
* Sent out a proposal to the list yesterday about changing the way "self" is used. Would appreciate feedback
* Other miscellaneous digging into various issues but nothing to show for it all.
EOR 18:45
chromatic Did I miss anyone?
Question time.
Who has a question?
rurban installable langages, how to proceed? 18:46
chromatic What's the status of the PDD there?
rurban There's none
chromatic Languages without C-based dynpmcs or dynops are just Parrot libraries. 18:47
Those should be easy to install.
Coke there's also the question of how to /build/ them.
rurban there's the draft pdd30, where to install hem? that's not decided
the build question is 2nd (CPAN or a Parrot install.pbc) 18:48
pmichaud in 2008-09 it was suggested that we have parrot/runtime/languages/ 18:49
rurban /usr/lib/parrot/runtime/languages ?
pmichaud sorry
runtime/parrot/languages
i.e., as a sibling to runtime/parrot/library 18:50
(looking up the reference now)
rurban /usr/lib/runtime/parrot/languages ?
allison I was just thinking about this this morning, specifically for building packages
/usr/lib/parrot/languages
rurban We have to think of an absolute path which is acceptable to packagers, not as now, where we still create /usr/runtime ansd such mess 18:51
pmichaud previous discussion was at irclog.perlgeek.de/parrotsketch/200...9#i_559127
allison then /usr/lib/parrot/runtime is our install of the directory runtime/parrot
18:51 diakopter joined
rurban sorry, there's no /usr/lib/parrot/runtime 18:51
allison rurban: not currently, no, but moving to that instead of /usr/runtime 18:52
rurban there's just /usr/lib/parrot/library dynext and include
In my latest package I've toyed with /usr/lib/parrot/languages 18:53
allison library is a reasonable substitute for runtime
rurban /usr/lib/parrot/languages/abc/abc.pbc
allison though, perhaps confusing to have lib/.../library
pmichaud I think 'library' corresponds to runtime/parrot/library of the build tree 18:54
rurban sure
allison pmichaud: yes, but what makes sense in the repository might not make sense in the install
chromatic 'library' is fine as a path component to me; we should not assume that it'll always be under /usr/lib -- it could be under /opt or $HOME or wherever.
allison chromatic: yes, that's determined by the prefix
chromatic: configurable at in config process 18:55
rurban /usr/lib is the default $libdir It's just that some languages also have their runtime subpath and that doesn't fit
chromatic Then who cares if lib/.../library ?
allison chromatic: it's just about sane defaults
rurban We just have to decide where to put the languages and how
allison (because most packaging will use the defaults) 18:56
pmichaud I propose /usr/lib/parrot/languages/abc.pbc
TimToady don't forget to think about versions and authorities
Coke pmichaud: /usr/lib/parrot/languages/abc/abc.pbc, at least, so we can install multiple pbcs for a single lang.
allison pmichaud: which is also what I propose, and what rurban proposed after me, so, consider it done
rurban I proposed /usr/lib/parrot/library/abc.pbc
in my draft 18:57
allison oh, sorry, I missed the extra language directory
pmichaud Coke: no, I'd like additional pbcs to go into .../parrot/languages/abc/
allison what I wrote this morning was /usr/lib/parrot/languages/pynie/pynie.pbc
pmichaud but the base level one should be .../parrot/languages/abc.pbc
Coke pmichaud: I disagree, but don't care enough to write any code. =-)
pmichaud I'm basing this on the notion that 'abc' would be linked to 'parrot' and automatically load abc.pbc 18:58
(as discussed last fall)
Coke pmichaud: adding another dir there doesn't really impact that.
barney but there usually it the exe /usr/lib/parrot/languages/abc
TimToady don't forget to think about versions and authorities :)
allison pmichaud: it does make library loading simpler if there's only one directory to look in
pmichaud TimToady: I haven't forgotten.
TimToady: we'll deal with that in Rakudo, yes.
allison TimToady: noted, and will consider
Coke Also, need a place for oplibs, dynpmcs... 18:59
rurban ok, sounds good. then the call would be load_bytecode 'languages/pynie.pbc'
Coke (versions, authorities) I can't see that going in for 1.0
TimToady just pointing out that if you do the symlink trick to parrot, it might have to find version numbers in the path, not just the final component
allison Coke: yes, I'm thinking it goes languages/foo//oplibs languages/foo/dynpmcs and languages/foo/library
pmichaud I'm okay with /usr/lib/parrot/languages/abc/abc.pbc then. I'm more interested in seeing the "load correct language based on argv[0]" working.
Coke we don't have a way to say "I want version 3.7 of the tcl runtime."
rurban dynpmc's should better be put globally 19:00
Coke rurban: why?
rurban how to call it?
allison We could work that in as languages/tcl37/... but at that point I think we should really have a language config file in /etc
Coke rurban: same way we do now, by using .loadlib?
rurban .loadlib languages/foo/oplib 19:01
pmichaud does .loadlib look in subdirs?
allison rurban: no need for dynpmcs to be global, and it would be troublesome for filenaming
pmichaud: no, but you can add to the search path
pmichaud allison: how does one do that?
allison pmichaud: so, that would be part of installing a language 19:02
pmichaud I thought .loadlib got compiled into the .pbc
allison someone was just working on that code a couple of weeks ago... have to look
or not (too lengthy for the moment) 19:03
but, I'll look at it today
rurban I hope it will work without polluting LD_RUN_PATH / PATH / DYNLIB_PATH
allison I'm going to build a pynie package
pmichaud punie, please?
pynie's broken at the moment, I think.
allison pmichaud: okay, or abc, doesn't really matter which language 19:04
pmichaud right, abc is another good choice.
downside of those languages is that they don't have dynops or dynlibs
rurban WMLScript is the most troublesome
allison yeah, that's why I wanted a meatier one, but not quite as complex as perl6
maybe lua
pmichaud pynie doesn't have dynops or dynlibs either, I don't think.
allison ah, okay, haven't looked yet 19:05
pmichaud a simple (and very useful) one to get working would be nqp.
rurban forth is also problematic because it has multiple unmergable pbc's
pmichaud because it's needed for compiling all of the others.
Perl6Grammar is another one that we need for building other languages.
allison pmichaud: nqp may also be more complex than the average language
rurban nqp and Perl6Grammar are libs not languages 19:06
pmichaud nqp is incredibly simple.
it's just the .pbc file
the whole point of nqp is that it doesn't have a runtime :-)
allison I'd kind of expect that we'd install nqp by default, but it still could go into /usr/lib/languages/nqp
pmichaud rurban: nqp is a compiler.
rurban I know :)
pmichaud rurban: Perl6Grammar is a compiler.
Thus I doubt they're 'libs' 19:07
allison maybe we should have /usr/lib/parrot/compilers too?
though, the distinction between languages and compilers is fairly thin
rurban but it should go into /usr/lib/parrot/library/nqp.pbc shouldn't it?
pmichaud is there a substantial distinction between 'language' and 'compiler'?
rurban: I would expect to be able to run programs written in NQP with just a 'nqp' command.
allison at the notional level yes, but at the install level?
pmichaud in that sense, it acts like a language. 19:08
particle i thought the difference was something like: compilers are shipped with parrot, languages aren't
pmichaud particle: that's been the traditional difference for the naming of the directories, yes.
particle: I don't think that was intended to indicate how they'd be used.
or invoked.
allison pmichaud: yes, that's the other thing I'm working on today, the busybox aliasing so you can run any language as 'languagename' instead of 'parrot languagename.pbc'
pmichaud anyway, I think that 'nqp' should be invokable like any other language.
allison (which requires a standard location for the languagename.pbc file, which is how I got started on this) 19:09
rurban we have now /usr/lib/parrot/library/P6object.pbc /usr/lib/parrot/library/PGE/Perl6Grammer.pir
pmichaud allison: yes. I'm just saying nqp.pbc belongs there also.
allison pmichaud: in that case, I would put nqp in /usr/lib/parrot/languages/nqp (to keep it standard)
pmichaud allison: and that nqp is a very simple test case, and an immediately useful one because rakudo/abc/pynie/punie/pipp/etc. all need to run nqp in order to build.
rurban Files included in the =parrot-perl6= package: 19:10
/usr/bin/perl6.exe
/usr/lib/parrot/dynext/perl6_group.dll
/usr/lib/parrot/languages/perl6/perl6.pbc
allison pmichaud: true, okay I'll dig into it and pick a language to "debianize" as a test case
rurban /usr/lib/parrot/library/P6object.pbc
/usr/lib/parrot/library/P6object.pir
/usr/share/doc/parrot-0.9.0/languages/perl6/MAINTAINER
/usr/share/doc/parrot-0.9.0/languages/perl6/README
/usr/share/doc/parrot-0.9.0/languages/perl6/STATUS
/usr/share/doc/parrot-0.9.0/languages/perl6/compiler_overview.pod
/usr/share/doc/parrot-0.9.0/languages/perl6/glossary.pod
/usr/share/doc/parrot-0.9.0/languages/perl6/spectest-progress.csv
/usr/share/man/man1/perl6.1.gz
pmichaud rurban: all of those are going away.
(well, not P6object)
rurban /usr/lib/parrot/library/PGE/Perl6Grammer.pir is in parrot 19:11
allison rurban: that one stays
pmichaud but should it remain in library/
?
it's really a compiler.
allison yes, it's a core parrot library
pmichaud it's not a library, at least not in the sense of "load this library so one can do xyz"
allison it's also not a language
pmichaud yes it is. 19:12
It's the compiler for Perl 6 grammars.
barney let's call it a 'tool'
pmichaud I'm happy to call it a tool.
allison it's either going in /usr/lib/parrot/library or /usr/lib/parrot/languages/pge, I prefer the former
pmichaud but Perl6Grammar is the thing that takes a grammar (such as the pod grammar) and converts it to executable PIR.
particle it's a compiler/language, not a library like Data/Escape 19:13
languages/Perl6Grammar/ seems best to me
allison yes, the line between tools and languages gets thinner when we're writing DSLs as part of the tools
chromatic bonks you all on the head
pmichaud I'd be very surprised for anyone to do load_bytecode 'Perl6Grammar.pbc'
allison but, in general, I want the core tools to be installed as core libraries
pmichaud the normal invocation for Perl6Grammar is from the command line. 19:14
allison particle: no, it's not a separate language
rurban It's load_bytecode 'PGE/Perl6Grammar.pbc'
No load_bytecode 'PGE/Perl6Grammar.pir'
allison okay, we're bikeshedding now
pmichaud rurban: but nothing actually does that.
allison this part isn't critical
pmichaud allison: it is to rakudo.
allison (have to figure out a strategy for languages, but the rest can wait)
rurban ok,
pmichaud I'll rephrase 19:15
allison rakudo needs a way to load PGE/Perl6Grammar.pbc, it already has that as long as it's installed in a standard library location
pmichaud allison: wrong.
rakudo need a way to *run* PGE/Perl6Grammar.pbc
Rakudo does not load PGE/Perl6Grammar.pbc .
allison ?
pmichaud that has been my point.
PGE/Perl6Grammar.pbc is never loaded as a library. It is always run as a command.
allison pmichaud: you're talking about: 19:16
$(PARROT) $(NQP_DIR)/nqp.pbc $(PGE_LIBRARY)/Perl6Grammar.pir $(SOURCES)
barney Does Rakudo need to run PGE/Perl6Grammar.pbc after rakudo.pbc has been built?
pmichaud barney: no. 19:17
Perl6Grammar is only used for building languages.
allison but, that means it needs to be available as part of the build tools
Whiteknight I thought the intent of Perl6Grammar was to be used in Rakudo
allison that is, part of the 'parrot-dev' package, or some such
pmichaud (yes, it's possible that someone _can_ load it as a library later, but that would be done in the same sense that someone could load perl6.pbc as a library to run Perl 6 code)
allison Whiteknight: no, it's just the standard way of compiling a PGE-based parser 19:18
rurban So it doesn't need to be put in parrot, just parrot-devel
pmichaud the only reason that Perl6Grammar.pbc lives in library/PGE/Perl6Grammar.pbc now is because there's never been anywhere else good to put it.
allison rurban: yes, but that means all language packages have a build requirement of the parrot-devel (which seems reasonable)
pmichaud (perhaps it could've gone into compilers/pge. But that wasn't obvious at the time it was created.) 19:19
what is "parrot-devel"?
rurban a packlage name
pmichaud does it get installed?
rurban we have those names in the MANIFEST
allison pmichaud: an "invented on the fly" name for a package that contains the build tools
rurban users can choose
pmichaud so, not by default?
rurban basic runtime parrot or parrot-devel for more
allison pmichaud: yes, not on for a default install of parrot 19:20
Coke I wouldn't include the language development tools by default, no.
allison pmichaud: like how many C packages don't install the headers by default
barney pre, parrot runtime engine
pmichaud fair enough.
chromatic Is this discussion still useful for #ps, or does it belong on #parrot now?
rurban over to parrot
pmichaud I'm fine either way.
Coke Why don't we table it for a second until we find out if there's anything else.
chromatic Other questions? Milestone review?
Coke then the meeting can close, and this discussion can continue.
rurban for that's all ,thanks 19:21
allison chromatic: so far it's been critical to what I'm working on today, but it's wrappable now
pmichaud I agree with allison.
chromatic Okay, let's go over the milestones quickly then.
PDD 26 AST, pmichaud and Tene -- progress?
pmichaud not this week, but I'm also not feeling behind.
it may be a good plane-task.
chromatic PDD 19 PIR, Whiteknight and Tene? 19:22
pmichaud (since I'll be several hours on a plane this weekend)
particle steps away for another job-related phone call &
chromatic User documentation, allison?
PDD 23 exceptions docs, Tene?
Whiteknight eh?
allison did some documentation cleanup, mostly focused on dev tasks, would like to hand off documentation task 19:23
chromatic trac.parrot.org/parrot/wiki/ParrotRoadmap
Installable dynops and dynpmc tools, pmichaud, allison, particle?
allison (or at least be sure I'm not the only one working on it, it's more of a group sprint than a single person task)
pmichaud installable dynops -- I added rakudo requirements to the ticket, I need to find out more about parrot-devel 19:24
allison pmichaud: what problems did you run into moving Rakudo out of the repository?
pmichaud allison: currently Rakudo depends on having parrot's reconfigure.pl script... but I can get away from that since parrot-config exists.
I expect to have that resolved today/tomorrow. 19:25
(most likely today)
allison pmichaud: okay, that would be a good dependency to eliminate
pmichaud actually, we may get to the point where rakudo distribution is just a .pbc :-)
(and some docs)
allison pmichaud: that works
pmichaud oh, we can't do that. 19:26
darn.
(dynops and dynlibs)
chromatic Support policy: I'll check it in somewhere to the repository. It just needs a name.
Coke chromatic: perhaps a wiki page would be better?
allison docs/project/support_policy.pod
Coke we still have missed tasks from the 0.8.2 release, btw. 19:27
chromatic I'm sure we can link it off of our website.
Coke (according to the roadmap)
chromatic Windows porting, allison, particle?
pmichaud Coke: weren't the missed tasks moved forward?
allison Coke: we're not updating them in the earlier milestones once they've been moved to a later milestone 19:28
Coke allison: that's incredibly confusing.
pmichaud Coke: hopefully we're moving away from the roadmap wiki page anyway :-)
Coke I suggest if we're going to keep that page we at least change the status to 'rescheduled'
pmichaud +1
allison Coke: yes, good idea
Coke I'll do that right now. 19:29
only one left that wasn't brought forward: nan/inf, pdd14-numbers 19:30
allison Coke: IIRC, that was landed. chromatic? 19:31
chromatic particle did the nan/inf, but I haven't made BigInt work with the IBM standard decimal library yet.
Coke also: garbage collectable contexts
particle coke: that was moved to long term roadmap iirc 19:32
allison Coke: those were moved out to 2.0 or so
particle gc contexts
i need to document nan/inf in the pdd
chromatic Windows porting, allison, particle?
particle haven't attacked it this past week
allison Coke: so, move the pdd14-numbers item to 0.9.1
Coke allison: ah. that means they're on a different page. blah.
allison chromatic: also haven't been running compiles on Windows this week 19:33
Coke: just say "rescheduled"
Whiteknight particle: what needs to be done on Windows?
Coke (blah. a better use of my time here is to kill these pages entirely) 19:34
pmichaud (Coke +1)
barney (+ Coke 1)
particle Whiteknight: there are many skip/todo tests on windows, some of which (like threads) are unimplemented or partially implemented features
allison Coke: I created trac.parrot.org/parrot/report/14 so all you have to do is tag a ticket as 'roadmap' and we have our roadmap page
chromatic PDD 20 lexicals, pmichaud? Plane time? 19:35
pmichaud chromatic: yes.
Coke allison: there's already a report page for that.
particle wishes for named report links.
chromatic MMD and tickets resolution, allison?
Tene finally here, was stuck in traffic for an hour.
allison Coke: yes, that one (I created it a while ago)
Coke no, trac.parrot.org/parrot/roadmap
allison Coke: that's different, that's all tickets that are tagged for a milestone, no mater what kind of ticket they are (bug, patch, todo) 19:36
Coke: which means the actual roadmap tasks get lost
Coke I don't think we need yet another ticket status, but if you think it helps, ok. 19:37
allison Coke: the new report is just roadmap tasks, so it exactly corresponds to the old Roadmap wiki page
Coke (we already have critical, blocker...)
Tene Queue a couple question slots for me.
allison Coke: aye, but none of those say whether it's a task on our project plan for a particular release
Coke: I want to eliminate the Roadmap wiki page entirely 19:38
Coke that's why we have /milestones/
pmichaud milestones are our roadmap.
allison Coke: nope, that also includes stuff that isn't part of the project plan
pmichaud tasks not associated with a milestone aren't on the roadmap.
allison but many tasks associated with a milestone aren't on the roadmap
pmichaud right. I think they should not be associated with a milestone then.
i.e., the milestones should be our roadmap. Things not on our roadmap should not be associated with a milestone on that roadmap. 19:39
Coke Nevermind. I'll just leave it the way it is.
(I don't agree with the plan, and I have other ways to spend these tuits.)
allison I don't much care as long as there's a way to record the tasks that are specifically for the roadmap, and keep them from getting buried under a pile of other tickets 19:40
if milestone tag policing is the way to go, go for it
pmichaud allison: here's a question 19:41
(related)
if I come up with a bug that's not specifically on the roadmap, but has to be fixed in order for us to consider the associated item to be "done", how do I mark that?
for example, the fact that Perl6Grammar.pbc isn't being included as part of 'make install'
'make install' is on the roadmap 19:42
as it existed this morning, it didn't install Perl6Grammar.pbc
allison you can link to it from the ticket that depends on it
pmichaud yes, but shouldn't it also be a dependency on the 'roadmap'?
i.e., shouldn't the roadmap indicate that that task has to be completed as part of the release?
because without it, we haven't really gotten 'make install' to work. 19:43
allison The one ticket is a dependency for the roadmap
pmichaud oh -- you're saying modify the roadmap ticket to link to the dependency.
okay.
allison the other ticket is a dependency for the other ticket 19:44
(interrupted by phone)
pmichaud to me it's just easier to say "this has to be done as part of the release also".
but yes, I can try it the way you describe.
allison the other possibility is to tag it for the milestone 19:45
and, I actually prefer that one
pmichaud right, that's what I'm thinking
I'd like the milestone to list all of the things that need to get done
allison so, it's not a "roadmap" task directly, but it is part of our "todo"s for the milestone
yes, I agree with that
pmichaud okay, I agree with you.
so, 'roadmap' is just to identify the tickets that we specifically named at pds
it's a subset of things that need to be done for the milestone 19:46
allison yes
pmichaud the milestone lists all of the things we need for the release.
rurban Perl6Grammar.pbc is just fixed with r36333, RT #40817 should be a dep
allison aye, he roadmap is a particularly important subset, from the overall plan
pmichaud okay, that makes sense to me.
rurban a proper MANIFEST.generated not to miss a built pbc
pmichaud I have to depart... see you all on #parrot or next week here 19:48
Tene Bye.
chromatic Tene, would you like to report now? 19:49
Tene Sure.
I tried to work on making EHs not catch exceptions thrown from themselves, but I couldn't find any way to identify that case uniquely.
What format do I need to use for PDD docs? Does that just mean adding to docs/pdds/* ? 19:50
chromatic Yes.
Tene Okay.
I'm done, then.
allison Tene: there isn't any way for an EH to identify an exception that was thrown within itself (that's not part of the spec) 19:51
Tene: and yes, new PDDs go in docs/pdds/draft
chromatic Are there other questions? 19:53
allison I'm closing the 0.9.0 milestone in Trac 19:54
do we want to move the remaining active tickets to 0.9.1?
chromatic Yes.
allison done 19:56
chromatic Anything else? 19:57
Okay, let's wrap up this week. Close more tickets (especially mine). 19:58
19:58 Coke left
allison Thanks, c! 19:58
19:58 chromatic left 20:03 PacoLinux left 20:06 masak left 20:20 mberends left 20:31 Whiteknight left 20:40 diakopter left 20:54 pmichaud left 21:26 rurban left 22:00 Whiteknight joined 22:59 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!