Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 18 February 2009.
03:18 japhb joined 04:15 davidfetter joined 05:35 Tene joined 09:05 cotto joined 12:56 masak joined 13:05 kid51 joined
kid51 Pre-reporting, for the usual reason. Would appreciate feedback on these three tickets: 13:05
trac.parrot.org/parrot/ticket/327 (svn ignores) 13:06
trac.parrot.org/parrot/ticket/311 (dual listings in MANIFEST & generated)
trac.parrot.org/parrot/ticket/292 (POD)
EOR Thanks.
16:35 Tene_ joined
masak I'm also pre-reporting today. 16:44
* A bit of fruitful work on proto, and some November nursing.
* Only 9 bugs reported this week. jonathan and pmichaud have caught up a bit.
* Looking forward to the first independent Rakudo release!
* [perl #62730] is at times annoying when developing Perl 6. Please fix Parrot.
.eor
16:59 pmichaud joined 17:37 NotFound joined 17:42 kj joined
kj reporting now, as I'll miss #ps: 17:42
+ released Parrot 0.9.1, which went not too bad for a first time, but there /were/ some failures, which sucks. 17:43
+ no further activities this week, but I do have my hands on improved hardware, which gives me access to multiple platforms (macos,win32,and perhaps a linux distro.) 17:44
EOR
17:56 wknight8111 joined
pmichaud Also prereporting here: 18:01
+ Worked more on Rakudo built system, it's looking pretty good. Will be blogging about that later today.
+ Planning Rakudo's first release for (late) tomorrow sometime
+ Worked with jonathan++ on getting Perl 6 builtins written in Perl 6, that's going well.
+ I'm still needing to work on lexicals and pct documentation, will be doing that in next few days 18:02
EOR
18:17 Util joined, allison joined
cotto im in ur #ps 18:30
whiteknight i can has #ps? 18:31
Util killing ur bugs 18:32
cotto can it be #ps tiem nao plz 18:33
18:34 chromatic joined
allison ah, another outbreak of lolcode-itis, I see :) 18:34
chromatic, will you be leading today? 18:35
chromatic I can. Shall we start?
allison affirmative
NotFound hi
chromatic allison? 18:36
allison - Further progress on building a language from an installed version of Parrot.
- Fixes for the dynops generation scripts.
- Rakudo can now build and test entirely from an installed Parrot (with two patches I submitted to the Rakudo RT queue).
- Partcl can also build from an installed Parrot (with a patch I submitted to the Partcl google code repository), but the test libraries still have some hardcoded paths.
- Converted the build for dynamic PMCs and oplibs in the Parrot repository to pure makefiles.
- Updated all "Perl Foundation" copyrights in the repository to "Parrot Foundation". 18:37
EOR
chromatic I've been working through the TODO/SKIP review, fixing those when possible and filing bugs when not. It's slow going, but I'm making progress. 18:38
I'll work up a draft for the bug triaging guidelines soon.
cotto?
cotto #ps report:
* more UnionVal -> ATTR conversions (String, NCI (workaround: TT #365), LexPad, Iterator)
* broken and unbroke Rakudo with String conversion
* finishing before 1.0 seems attainable
- I may find more blockers like TT #365 which will block removal of the UnionVal, but the conversions are going fine.
.eor
chromatic japhb?
cotto q4q 18:39
chromatic GeJ?
18:39 rurban joined
chromatic NotFound? 18:40
NotFound Skip me, please, I'm busy ATM
chromatic rurban? 18:42
rurban - still working on pbc-compat 32/64bit.
- fixed pbc_header --upd which broke the native_pbc tests on the release.
- one blocking Sparc64 problem which can be solved with a ccflags setting.
- q and proposal how to handle old or incompat pbc's
(option = 1 to Parrot_pbc_read) trac.parrot.org/parrot/ticket/359#comment:2
eor
chromatic Tene_?
Util? 18:43
Util While traveling, I noticed 150+ occurrences of `if (Parrot_str_not_equal(foo,bar)==0)`.
18:43 particle joined
Util Patched all to `if (Parrot_str_equal(foo,bar))`, and tested clean Sunday night. 18:43
Writing up ticket now, but waiting on clean Smolder to commit; tests are failing now (crypto and embed), and I don't want to muddy the waters for those pursuing those issues.
I plan to follow up on other PDD07 violations I spotted, then tackle some Doc tickets.
EOR 18:44
chromatic whiteknight?
whiteknight - Still working on the rename_pccinvoke branch. Think I've got most of the issues figured out, just need to find resolutions. 18:45
- Started updating Parrot_run_meth_* functions from the Object PMC, ran into a few issues but mostly smooth going.
- Finding lots of opportunities for unification and optimization, most will have to wait till much later
- Worked on a few tickets, closed a bunch in RT.
EOR
chromatic Did I miss anyone?
Okay, let's go to questions then. cotto, go ahead.
cotto People are surprised by the email confirmation requirement for trac. 3 people have mentioned this in the past couple days. The current situatio
n when registering is:
* no email -> can create tickets
* (ostensibly optional) email -> unhelpful "acct_mgr.web_ui.MessageWrapper object at 0x80b2f90c" message, can't create tickets
* email + confirmation -> can create tickets
Can some with the proper Trac powers make the error message clearer or add some nice red text to the registration page?
allison cotto: this is a bug in a Trac plugin (known, has a ticket in the Trac system for that plugin) 18:46
cotto Can we make it more newbie-friendly in the meantime? 18:47
allison cotto: we might be able to disable the confirmation requirement, though
cotto Spam from registered users hasn't been a problem. That sounds like a good idea.
allison cotto: it's slightly less spam-proof, but still better than completely anonymous ticket submissions 18:48
cotto: okay, I'll follow up with our admins about that
NotFound ready
cotto NotFound, go ahead then
NotFound * Some extend and embed improvements, fixes, tests and examples
* Miscelaneous fixes
* Applied a few patches
EOR
cotto next question: 18:49
Do we care about the Bound_NCI PMC? It currently has near-zero test coverage.
It's also been broken (at least) since r36896, when I converted the NCI PMC to use ATTRs and nobody's said anything.
allison cotto: how about usage? how heavily used? 18:50
chromatic In theory, something uses it, but I don't remember what nor where.
allison cotto: (if not used, may be a deprecation target)
NotFound I did some checks about that.
Seems to be used in branches never reached in object and default pmcs
cotto It's referenced in object.pmc and default.pmc a total of 3 times. 18:51
whiteknight I haven't been able to isolate a test case that actually does use it yet
NotFound I inserted PARROT_ASSERT(false) in that branches, and all test pass 18:52
allison cotto: if we can remove those uses, let's deprecate it
cotto sounds good. I'll either do it or open a TT. next question: 18:53
The Slice PMC has near-zero test coverage. Do we want to drop it or increase test coverage?
chromatic Isn't it on the deprecated list?
allison cotto: drop, a dedicated PMC is not the right way to implement slice behavior
cotto chromatic, where's that list? 18:54
allison cotto: (again, depending on how heavily used, and if it can be removed without serious disruption)
cotto There's no mention of "slice" in DEPRECATED.
allison cotto: then it can't be removed until after 1.0 18:55
cotto: but it could be changed to throw warnings when anyone tries to use it
chromatic I may have overlooked it in DEPRECATED.
cotto Would it be ok to strip everything except the init-related VTABLE functions? 18:56
then take it out after the 1.0 release?
(or does that mean it needs to be removed before the 1.5 release?)
allison cotto: I'm on the fence about that, I mean, it would technically satisfy the requirement of not deprecating until after 1.0, but if anyone actually was using it, that wouldn't help them, and if no one's using it, then why not just remove it? 18:57
cotto: (means removed sometime between 1.0 and 1.5,... er 1.4 I mean) 18:58
particle *cough* darkpan
chromatic I don't want to get in the habit of second guessing our deprecation policy though.
Also, why didn't particle report? Because I can't read names in a list?
particle because i wasn't on the list. i'm late 18:59
allison chromatic: aye, which means it has to still function exactly as before, though we can add deprecation warnings
particle allison: i prefer that solution. stick to our policies, don't work around them, even for mistakes.
Util languages no longer in the nest == strict deprecation policy
NotFound BTW pmichaud and kj reported earlier 19:00
cotto That'll block the completion of the UnionVal removal until between 1.4 and 1.5, then.
chromatic cotto, or work around it somehow.
allison cotto: because Slice isn't tested, so can't be migrated off the UnionVal?
NotFound We can put a note somewhere recomending check that each parrot feature used have a test in the repo 19:01
cotto I don't trust myself to not introduce bugs when converting untested code.
allison cotto: so write some tests, make sure they pass before and after 19:02
cotto works for me
allison cotto: it doesn't have to test every feature, just that storage and retrieval is still working
cotto Also, Bound_NCI isn't on the list in DEPRECATED. Should I do the same thing there?
allison cotto: yes, but go ahead and remove the core uses if you can 19:03
cotto will do.
final question from me:
allison, what's your reason for deprecating the PMC UnionVal? (I can see some reasons of my own, I'm just curious what you see.)
chromatic It's typeunsafe and it's a premature optimization. 19:04
It makes PIR-level subclassing Very Difficult.
allison cotto: it prevents subclassing, for one (because the child may be trying to use the union val differently)
cotto thanks. eoq
allison cotto: and just generally dangerous, to be using blobs of memory like that
chromatic It violates encapsulation.
allison chromatic: yes, those too 19:05
NotFound And it increases coupling between pmcs
allison cotto: it also bloats the PMC header structure
EOA 19:06
cotto Thanks.
particle EOT
chromatic particle? 19:07
NotFound A quick question: an empty string must be a valid nci signature?
particle i've been bugging folks about commits, and submitting smokes for msvc and cygwin
almost no time or energy for parrot lately
chromatic NotFound, not sure. 19:08
particle it's been frustrating, really, i'm behind on many roadmap items
don't know what i can do to overcome it atm.
.end
allison NotFound: an nci signature should always at least have a 'v' to say it returns nothing 19:09
particle NotFound: ...what she said :)
allison (that is, no arguments, no return)
chromatic Does that mean you volunteer to go through the roadmap today, particle?
particle no, i'm late for work :( 19:10
NotFound allison: that looks correct to me. The problem was that the assumpion was not verified anywhere, I added a check today.
allison NotFound: we might need to check for null strings somewhere to throw a sensible exception (not sure of the context of the question)
NotFound: okay, sounds good
NotFound NULLs are checked at least by ASSERT_ARGS, but "" was not checked anywhere, 19:11
EOQ 19:12
allison chromatic: when we do the milestone review, need to reschedule the missed from last month
chromatic: shall I be roadmap editor for today?
chromatic Go ahead. 19:13
(I find it a little tedious.)
allison (I know, that's why I volunteered)
if you do the review, I'll make the updates
chromatic Bug tracking and triaging guidelines -- me -- on track 19:14
adding attributes to existing classes, remove existing exceptions -- me and jonathan -- no progress
(afaik)
complete language tutorial, abc tutorial, squaak tutorial -- pmichaud? 19:15
pdd29-pct user doc -- pmichaud and Tene? 19:16
move languages out of repo (or tarball) -- coke and fperrad?
allison chromatic: made good progress on that one 19:17
chromatic Let's say that's in progress then.
I know they haven't moved Pheme.
allison particle: what was the name of the general languages repository you set up last year?
(or, alternatively, should we set up a 'languages' repository on svn.parrot.org?) 19:18
it's quick to set up
particle thumbs squawk at googlecode 19:19
chromatic +1
rurban +1
cotto +1
NotFound +1 19:20
allison +1 at squawk or languages on svn.parrot.org?
NotFound languages
chromatic languages
particle thinks it's better done outside parrot.org, zero admin hassle
rurban at svn.parrot.org languages
pmichaud I think better outside parrot.org, also. 19:21
cotto Should the "1.5" milestone be renamed to "1.4", according to the recent version numbering discussion?
allison cotto: yes
pmichaud but really I think we should leave the decision(s) up to whoever decides to lead each language's development. 19:22
chromatic We didn't discuss the new numbering classification. Any objections to the latest proposal?
allison (cotto: it is, and 2.5. is now 2.6)
pmichaud if there is no leader for a specific language, then svn.parrot.org/languages would be okay with me.
NotFound I think that for languages with a more or less stablished support group outside is better, but for tiny or experimental ones our own repo is useful
allison pmichaud: yes, but the question here is just whether we should provide a repository for languages as a playground, and they can decide whether to use it or not
pmichaud: aye, I'm leaning that way too 19:23
so, svn.parrot.org/languages/trunk/pheme or svn.parrot.org/languages/pheme/trunk? 19:24
Util "languages on svn.parrot.org" would *provide* SVN services for new language authors who might not be at the Git level of SCM Zen.
Those who want more (zero admin hassle, etc) can go to GitHub, where many of the existing languages have flown.
We will need a "new language author's guide" of some sort.
pmichaud languages/pheme/trunk 19:25
allison that is, could each language be expected to branch on its own without branching the whole languages repository
pmichaud I wouldn't expect languages/branches/...
but I would expect languages/pheme/branches/...
cotto I'll take care of renaming the milestones after #ps.
allison pmichaud: agreed 19:26
added to my todo list for the day
I'll move one language as an example, and leave the rest for language folks 19:27
particle wonders about trac setup
allison I'll do punie :)
rurban one languages trac for all please
allison particle: we intentionally kept trac with an extra level so we could have trac.parrot.org/something/... 19:28
(the main parrot repository is trac.parrot.org/parrot/...
I think that wraps up that roadmap item for now 19:29
I've been making updates as we went along, so reload your roadmap page
chromatic web site updates -- Infinoid -- anyone know? 19:30
user forum -- anyone know? 19:31
allison what is user forum? 19:32
is that a users mailing list?
chromatic No idea.
pmichaud I think it was intended to be an online forum.
cotto I thought it meant a phpbb-like forum hosted on parrot.org.
allison okay, I'll declare that it's a user mailing list with an associated google group
chromatic clean up core headers -- me -- no progress 19:33
pmichaud +1
allison 'parrot-users' ?
pmichaud +1
NotFound chromatic: core_types.h is a progress
chromatic I saw that, thank you. I was glad to see that. 19:34
allison NotFound: me too
chromatic Quiero lo mismo el pidio. 19:35
integrated language testing -- ??
make html ?? 19:36
allison chromatic: 'make html' landed 19:37
NotFound make html is working well its'n it?
allison chromatic: integrated language testing, rejected, we're moving the languages out of the repo 19:38
rurban I find the "parrot on cygwin" task for 1.1 odd. cygwin had the only installable release
which worked pre-1.0. It should be marked landed or removed, otherwise we would get questions. 19:39
NotFound For those that doesn't fear the power of old style basic, pirric's interlang.bas does a few interlanguage checks
allison rurban: marking it landed (finishing milestones early is always fine)
19:40 PacoLinux joined
particle shall we add cygwin to supported platforms? 19:41
rurban sure. it is
even at the very top
allison NotFound: excellent
particle *supported* 19:42
NotFound allison: thanks
particle in official policy, not in platforms file
chromatic Any other roadmap items? 19:43
rurban s there a portable pbc roadmap?
chromatic No.
rurban 2.0 or 3.0 maybe?
NotFound Do you want a magic number? ;) 19:44
rurban I see. it is 2.5
chromatic Other questions? 19:47
rurban a sparc64 problem/question
broken strict 8-byte ptr_alignment
because we advance the ptr in pbc's in foreign ptr size, which can be 4, 19:48
pbc reading is fundamentally broken on Sparc/64 (ptrsize and ptr_alignment=8),
which can be fixed by relaxing the ptr_alignment, but should be fixed by stricter
alignment writing.
use.perl.org/~rurban/journal/38522
chromatic Does an 8-byte alignment work on all other platforms we care about?
rurban nope. sparc is the only one strict
chromatic Let me rephrase.
Will that 8-byte alignment screw up any other platform? 19:49
rurban no
chromatic Seems like we have no choice then.
rurban for now we can relax it with a hints file
chromatic (unless we move to a bytecode format that doesn't store information in platform-native style)
rurban but later we shoudl produce 2 times bigger pbcs
chromatic (but that's Parrot Infinity)
allison doubling the size of pbcs is painful, we may want to have a "portable" option for our bytecode generator 19:50
rurban good idea!
allison so, compiling native pbc to run on only one platform doesn't take the hit 19:51
rurban we can still support it, just make reading 32-bit slower
particle why doesn't the loader take on that responsibility?
rurban now the loader is a bit broken because we advance by ptrsize 19:52
the native ptrsize, not the foreign ptrsize
so we must ensure to have all ints or ops pairwise.
particle does the magic value in pbc header let you know alignment?
allison advancing by ptrsize is likely a bad assumption anyway
rurban yes, but it is faster on native 19:53
chromatic ... or read just enough.
rurban anyway, I can workaround it for now
chromatic Is *reading* PBC going to be a bottleneck for any worthwhile program, ever?
allison going slower on non-native pmc is fine, just as long as it works
rurban particle: no, ptr_alignment is not stored in the header, it's a native problem only
allison chromatic: it's startup time, which is key for dynamic languages
chromatic: that is, we probably *could* make it slow enough to matter, but we'd have to work at it 19:54
rurban allison: pbc not pmc
allison rurbah: yes, you have to load pbc when you're getting the interpreter started
chromatic If we wanted to fix startup time, we'd make allocating new GCables cheaper. 19:55
... or remove all of the malloc/free pairs required to start up.
allison chromatic: yes, that's more critical
rurban for now it's just Sparc64, any PowerPC with a native strict cc.
But this alignment can be relaxed, so no worry
allison rurban: a reasonable workaround for now 19:56
rurban I'm aiming at 2.5 now
allison rurban: we'll come back to it for 2.6
rurban ok
chromatic Should we rearrange the items in the roadmap in descending order of completedness?
allison chromatic: for the 1.0 milestone? we can 19:57
chromatic: anything you'd sort to the top? 19:58
(reload the page, as all the rescheduled items are now in 1.0) 19:59
I'll move the two landed items to... top or bottom? (which way are we sorting?)
chromatic Landed top.
allison ok, then rejected 20:00
then "on track" then unmarked 20:02
chromatic Anything else for this week? 20:03
Let's call it a week then. Until next time. 20:05
rurban bye
20:05 rurban left
allison thanks, c! 20:06
20:06 Util left, chromatic left 20:09 NotFound left, PacoLinux left 21:01 pmichaud left 23:25 Whiteknight joined 23:58 Tene 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!