Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 8 December 2008.
01:14 particle1 joined, particle1 left 10:12 particle joined 14:01 particle1 joined 14:25 Wknight8111 joined 14:51 contingencyplan joined 15:34 contingencyplan joined 16:20 contingencyplan_ joined 16:24 contingencyplan_ joined 16:30 contingencyplan__ joined 16:32 contingencyplan_ joined 16:35 contingencyplan joined 16:51 contingencyplan_ joined 16:56 davidfetter joined 17:24 particle joined 18:03 Whiteknight joined 18:06 rurban joined 18:19 pmichaud joined 18:23 mberends joined 18:26 jhorwitz joined 18:29 barney joined 18:30 cotto joined 18:32 allison joined
Whiteknight hello 18:34
cotto hi
allison hi
pmichaud hello 18:35
jhorwitz hello
rurban hi
Whiteknight who's driving this train?
18:35 Coke joined
pmichaud I blame Coke. 18:36
allison nominates Coke for today's MC
rurban let's wait for chromatic?
Coke Coke, as you recall, said there was no meeting today, but if you wanted to have one, that was fine with him. =-)
18:36 PacoLinux joined
allison rurban: I believe chromatic is in family Christmas stuff 18:36
Coke: ok
Coke I'm at verk, but have half a brain cell to devote. 18:37
allison?
particle hi-o
allison - Mainly worked on integrating other's branches this week.
barney servis
18:37 chromatic joined
Coke allison: hokay. 18:37
allison - Started the branch for the GC refactor, and spent some time planning it with chromatic and Whiteknight.
- Also traveling with family stuff. 18:38
EOR
Coke k. Barney?
barney Pipp:
Remove the alternative frontends from Pipp.
Applied patches from Daniel Keane: 'elsif' and 'do-while'
Add implementation of 'eval'.
Put PHP functions into hll root namespace 'pipp'.
Put internal functions into hll root namespace '_pipp'.
Parrot:
Update function doc for Parrot_register_HLL().
Requested documentation of the default hll root namespace.
Nudge pmichaud++ into implementing .hll() on PAST::Block.
reserve 1 q
.eor
Coke k. chromatic?
chromatic Profiled op-level MMD, found three places to optimize.
Waiting for GC branch tasklets. 18:39
Will look at Gabor's Parrot::Embed questions; hope to improve things for Padre.
Will review lathos's NCI generator update, but it looks good now.
Happy to look at any segfaults reproducable from PIR.
END
Tene Oh, there's a meeting here. I forgot again.
Hi.
Coke see partcl.blogspot.com/ 18:40
now running 5 more spec tests (regressed on one.) Thanks to some folks on #tcl
have a lead on a fix for a dozen more that I hope to complete this week.
(involves getting a barely functional [trace] working.)
exit;
cotto?
cotto * randomized the per-interp hash seed (child interps inherit the seed from their parent so I don't have to mark anything shared)
* knocked off a bunch of Coverity defects
eof
q1q
Coke jhorwitz: ?
jhorwitz mod_parrot is still blocked due to the IO merge. waiting on either a subclassable FileHandle PMC or a string IO version of FileHandle, which i discussed with allison. since all 0.5 milestones are completed, i may branch so i can keep working.
q1q
EOR 18:41
Tene Did we meeting last week?
Coke tene, why don't you report now.
and yes.
Tene Looks like a lot of exceptions work.
CATCH and CONTROL in rakudo
continue/break in given/when
resumable exceptions in rakudo 18:42
started on loops refactor with pmichaud++
still a few issues to work out with that
KTHXBAI
Coke k. rurban?
rurban * started working on the cygwin release and install patches again. 51 .rej files todo. allison already applied some minor stuff, but there's still a lot missing. eor
Coke k. Whiteknight ?
Whiteknight =Misc 18:43
- released 0.8.2
- removed compilers/bcg/*
- refactored Integer.pmc to use VTABLEs instead of direct MMD calls
- closed a few RT tickets that I've been sitting on
- a few updates to old files in docs/
=branches/pdd09gc_part1
- updated gsoc_pdd09 branch to get a clear diff of changes
- created src/gc/marksweep.c to hold the old MS collector. Would like to merge this change to trunk soonish
- tried to slim down the IT collector from branches/gsoc_pdd09 for use in the new branch
=JIT
- Worked on removing exec code from .h files in src/jit/
- Able to update src/jit/amd64/*
- created the branches/jit_h_files/ to work on src/jit/ia32/*. More convoluted then I expected, so going is slow.
- I don't have access to other platforms for testing
- Looking to improve JIT coverage on amd64, idly poking and prodding at this
EOR
Coke any other committers that want to report? 18:44
pmichaud raises hand.
Coke whoops.
Ok, i suppose you can go. =-)
particle !
pmichaud I didn't accomplish much this week. Only:
** Rakudo spectests (r34267): 264 files, 5833 passing, 0 failing
+694 passing tests since last #ps.
== Parrot stuff
: updated non-ICU unicode strings to recognize more ALPHABETIC and WORD types
: corrected .arity method on Sub PMCs
== PGE stuff
== PCT stuff
: added "hll" attribute to PAST::Block nodes, based on barney++ nudge
: working on loop refactor, should finish shortly (< 2 hrs)
== Rakudo stuff
: resolved lots of RT tickets 18:45
: updated 'sort' to be a stable sort
: fixed infix:<cmp> and other Pair methods and functions
: refactored Mapping methods
: refactored initialization, use, and MAIN handling
: converted \\d[...] to \\c[...]
: fixed unicode hyperops »+«
: cleaned up IO.readline and prefix:<=>
: added radix support to string-to-number conversion
: applied patches from cspencer++, bacek++, and others
: added +/- Inf, NaN support
: added whatever * to array slices
EOR
Coke woof.
particle?
particle ~ mainly infrastructure and accounting items this week 18:46
~ some discussions with designers/developers on various parrot/pct/rakudo topics
~ missing io sockets implementation has broken some examples (e.g. http.pir) and blocks progress on an http server written in perl 6 (willing contributers available)
~ i'd like to remove all unused or unfrequently used code from parrot, including stm, certain runcores, and certain garbage collectors
.end
Coke I will interject a question: there's a TT about the old streams.pir library that's now borked, in re: your sockets note. 18:47
ok. barney, you had a question?
allison particle: +1 on removals 18:48
barney Anything speaking against trac.parrot.org/parrot/ticket/85
Coke barney: +0 18:49
barney Being able to set the hll root from embedders
Whiteknight +1 from me
allison Coke: your reservations?
chromatic +0.1
Coke allison: more of a no opinion. 18:50
as opposed to a -1
particle abs(-1)
Coke barney: looks like no one's objecting...
chromatic We need a way to access namespaced symbols, but I'm not sure adding a stateful API call is the right approach.
allison barney: it looks like a workable solution for now, no caps in function names, though so "Parrot_set_hll"
rurban You must set the HLL to find a symbol in other namespaces?
allison or "Parrot_hll_select"
chromatic If we do this, we'll also need a way to access symbols in other HLLs and namespaces. 18:51
Coke rurban: no. you can do get_root_global ['hll'], 'foo'
allison (following the convention that the first word should indicate the subsystem)
chromatic Coke, you can't do that from Parrot::Embed.
It's not easy to do that from C either.
Coke hokay.
jhorwitz if we have that, we will also need a Parrot_get_hll... 18:52
allison jhorwitz: that's a good idea anyway 18:53
barney There is an exported Parrot_get_HLL_id
allison barney: which is a terrible name
jhorwitz concurs
chromatic What we currently export shouldn't imply any design rationale.
allison but, can be simply renamed instead of reinvented 18:54
chromatic That is, there's no coherent rationale behind our list of exported symbols.
allison chromatic: true, but we should clean up as we go along
chromatic I want to change my vote then. -1
allison chromatic: reasoning? 18:55
chromatic The request is to access symbols in a given namespace.
allison i.e. the solution isn't a direct response to the stated problem? 18:56
chromatic Suppose you want to access symbols from multiple HLLs.
Exactly.
barney szabgab wants that for calling PHP function from Padre
chromatic You write: Parrot_hll_set( 'Foo' ); Parrot_get_global( 'bar' ); Parrot_hll_set( 'Baz' ); Parrot_hll_get( 'other_bar' );
... and then you shake your fist at the sky and say: 18:57
allison yes, we should probably have a way of calling a function from a particular HLL without actually setting the current HLL
jhorwitz you can do that now
chromatic "Why didn't you give me Parrot_get_global_from_hll( 'Foo', 'bar' )?"
jhorwitz but it involves knowing the namespace
pmichaud Parrot_get_hll_global (to match the opcode, perhaps)?
chromatic Sure, that's a better name.
jhorwitz i like that, but then you also need Parrot_set_hll 18:58
allison ok, so that's the direct response to the stated problem
chromatic Why do you need Parrot_set_hll?
barney When calling a function in a HLL, the current_HLL might be expected
jhorwitz i guess you don't if you include the HLL in Parrot_get_hll_global
(the opcode doesn't)
allison but, yes, in general most things we can do from PIR, we should also be able to do from C
pmichaud oh, sorry. Parrot_get_root_global( 'Foo', 'bar' ) 18:59
(to match the opcode)
jhorwitz is correct that get_hll_global finds a symbol in the current hll
chromatic I disagree about the necessity to have C and PIR isomorphic through the embedding interface. 19:00
Any non-trivial C program which uses the external interface will end up looking a lot like inlined opcode bodies.
jhorwitz i agree w/ chromatic here. we have Parrot_find_global_*
barney Parrot_find_global_* is really Parrot_find_hll_global_* with the HLL 'parrot' 19:01
chromatic Besides, mostly I (or someone else suitably crazy) can address Gabor's needs within the XS of Parrot::Embed anyway.
I think.
allison the find* alternates were all deprecated years ago 19:02
particle where is namespaces pdd on the roadmap? this seems directly related. 19:03
pmichaud (point of clarification: the find*global alternates are deprecated. Other find* ops still exist.) 19:04
allison pmichaud: yes, good clarification for the record 19:05
Coke so, barney, is your question answered? =-)
allison particle: 1.1, April release
barney A problem is that most HLLs don't use the scheme layed out in PDD21, with hll root namespace 'lang' and '_lang'
Coke barney: tcl does, fwiw.
particle it might be that tcl is the shining example here 19:06
barney Pipp is following that lead
allison barney: would shifting the languages over to using that scheme for private language namespaces resolve part of the problem?
barney No, shifting over to that scheme caused the problem. 19:07
Coke tcl was never embedded, and so never noticed. =-)
allison barney: ah, which raises a question of whether it's a good scheme 19:08
barney find_global() in Parrot::Embed can find symbols below 'parrot', but not below 'pipp'
chromatic Parrot::Embed needs fixing. I haven't done anything until now because no one needed it until now. 19:09
allison this sounds like a bigger problem than just adding 'set_hll'
jhorwitz barney: you can do what you need using the existing embedding interface -- mod_parrot does it.
particle sounds like we need find_root_global that searches from the root, and don't need set_hll at all
barney Another issue is that whoever uses the op get_hll_global depends on the value of current_HLL in the interpreter 19:10
allison barney: where does that cause conflicts? 19:11
should 'get_hll_global' search both 'lang' and '_lang'? (first one and then the other) 19:12
barney If you have one interpreter calling subs from different HLLs
when subs in the HLL use get_hll_global
Coke allison: no.
allison ok, yes *that*'s a huge problem
Coke (search both)
tcl is using _tcl to hide subs from the user at runtime. I don't want them exposed. 19:13
allison should the HLL be set in the context instead of the interpreter
chromatic Again, anyone who's calling ops directly from C has already done something crazy. We shouldn't make it easier for them.
allison Coke: fair enough, and on the whole would prefer to keep them cleanly separated
barney sorry. I think it is set in the context
pmichaud right now, get_hll_global is in the hll of the sub 19:14
allison chromatic: but this isn't just about calling ops from C, the current HLL is also used for selecting HLL-mapped types in C
pmichaud at least from PIR.
allison chromatic: and there are plenty of C functions that are used to support the PIR ops that need access to current HLL information
chromatic The Parrot_sub struct stores an HLL_id. 19:15
barney Coke: It's not about calling ops directly, but calling userspace HLL functions, that execute some bytecode
pmichaud when invoking a sub, the interpreter switches to the HLL of the sub.
allison barney: being set in the context should be safe, it'll only affect the particular execution chain
chromatic If subs don't know their HLLs, we have interesting problems when we export subs.
Coke barney: did you mean chromatic ? 19:16
barney yes
chromatic barney, how are they calling userspace HLL functions that *don't* have an HLL set?
jhorwitz subs may know their HLL, but you have to know how to find the sub in the first place (using either namespace or HLL)
barney jhorwitz++ 19:17
allison jhorwitz: yes 19:18
chromatic Sure, but we're already talking about Parrot_find_root_global() or whatever it's called.
Everyone seems to agree that we need that and should use that. 19:19
barney extending Parrot::Embed::find_global() with a HLL probably a better solution
chromatic Exactly.
allison barney: that sounds good
jhorwitz agrees
rurban much better than set_global
barney Maybe disallow hll names starting with an '_'
chromatic I don't see the point of that. 19:20
If you're controlling Parrot from C, you have access to its pasty white underbelly already.
Document what's available and public, and then laugh long and loud at people who rely on undocumented internals when you break them and they get to keep the pieces. 19:21
allison barney: we need some convention to give languages a private namespace. It doesn't matter what that convention is. '_' works for now, until we come up with something better 19:23
jhorwitz fyi, the *official* API definition isn't due til 1.3 (6/2009)
allison jhorwitz: yes
barney Yes. User defined functions and builtins in 'pipp', internals in '_pipp' 19:24
allison barney: ah, I see, you're saying we should formalize '_' for private language namespaces, so we never get '_foo' as public and '__foo' as private. That seems reasonable. 19:26
barney That's how I understood PDD 21 19:27
allison barney: yes, I took it as so much of a given that at first I thought you were proposing entirely doing away with '_foo' as a *private* namespace 19:28
chromatic Shall we move on to the next questions? 19:29
barney Not at all. I started using '_pipp' today.
jhorwitz had a question when this one is settled 19:30
Coke we've got the queue. =-)
jhorwitz yay
right, i'm behind cotto. :)
Coke chromatic: lets. 19:31
chromatic cotto? 19:33
cotto Can we do one of the following:
- Add a PARROT_EXPORT function to get entropy from the underlying system (and a way to access that function from PIR)
- Use entropy from the system to seed the prng
chromatic Why do we need to export it?
cotto so PIR code that needs randomness can get it
(either option is fine afaict) 19:34
chromatic PARROT_EXPORT has nothing to do with PIR code; it's about whether the symbol is visible from outside libparrot at the dlfunc() level.
allison cotto: sounds like a good addition. go ahead and make it PARROT_EXPORT, we'll decide later if it's also part of the API 19:35
cotto The only issue for me is making it cross-platform.
pmichaud PIR code that needs randomness uses the Random PMC, yes?
allison chromatic: at the moment PARROT_EXPORT is necessary on windows for just about anything that isn't 'static'
chromatic I don't believe that. 19:36
allison chromatic: that's why we changed the name, so people don't think it defines what is and isn't part of the API
chromatic I recall that we changed the name because we're going to cut down on what we export and make part of the API. 19:37
allison chromatic: I'm not sure I do either, but it needs more extensive testing by windows developers, and isn't a priority until 1.3
cotto I'll write a patch for as much as I can figure out and make a TT out of it.
chromatic The reason I added GCC visibility hiding to our default GCC 4.x behavior is to get the same symbol visibility on Windows and non-Windows platforms.
allison chromatic: yes, definite progress. they're not identical, but closer. will still need some more work when we get to that roadmap task 19:38
cotto eoq
Whiteknight cotto: sounds to me like you could add a seed function to the files in config/gen/platforms/* 19:40
cotto Whiteknight, sounds good 19:41
allison looks like we lost chromatic in a network dropoff, are there any other questions?
Coke jhorwitz had one. 19:42
jhorwitz yes...
allison: mod_parrot is blocked due to the IO merge. you and i discussed a branch to start picking at the low level IO functions so we could eventually subclass FileHandle. any progress? 19:43
allison jhorwitz: I'll do that today
Whiteknight need any help with that?
allison it's not a long task
Whiteknight: I want you working on the GC branch
jhorwitz the branch isn't, but the working bits won't take long? 19:44
Whiteknight okay, I'll focus on that tonight then
allison jhorwitz: it's mainly just that I've been traveling non-stop since we talked about it
jhorwitz understood. :)
allison jhorwitz: neither is long, the code is already mostly done, just not checked in anywhere 19:45
jhorwitz ok, so the goal for this branch is to be able to properly subclass FileHandle?
or is this the string IO bit?
allison jhorwitz: which is a higher priority? creating a StringHandle to substitute for FileHandle is fastest
jhorwitz StringHandle is not optimal, but unblocks mod_parrot 19:46
allison jhorwitz: the general ability to polymorphically substitute any PMC with the right interface for FileHandle is the ultimate goal, and will only take a little longer
(and if that's what you really need, I'll just scrap StringHandle and do that instead) 19:47
jhorwitz if by a little longer you mean on the order of a few days, i can wait for the real deal. :)
allison yes, it's on the order of a few days
jhorwitz then +1 for working on the subclassable FileHandle 19:48
allison I'll be back home and settled tomorrow, and will have the rest of this week to finish that off, so should have it for you before next #parrotsketch
19:48 rurban_ joined
jhorwitz works for me. 19:48
Coke Oh, I have a semi-announcement. 19:49
jhorwitz: you all set?
jhorwitz yields the floor
Coke floor.resume()
.join()?
jhorwitz regrets his choice of terminology
Coke I have some volunteers for releases; we have january allocated.
Whiteknight ...and march! 19:50
Coke (that's chromatic). I'll make sure we have february locked in before the january release.
thanks to all who volunteered.
that's it for me; anyone else?
particle weekly reminder: trac.parrot.org/parrot/wiki/ParrotRoadmap
*lots* of tasks this month
Coke particle: any leftover tasks from 0.8.2 that didn't make it in, push them down to 0.9.0 as a higher priority? 19:51
particle already done.
pmichaud I should have pct_loop done today.
and I think we're in very good shape on PCT honors hll
Coke particle++ # coke sees his name on something. whee.
particle: "ticket sprint" doesn't mean anything to me. 19:52
allison Coke: a run of closing tickets
particle aka "bug day"
we've been making steady progress there, i think
do we need to deprecate the runcores/gc/stm? 19:53
i think not. others?
Coke adds trac.parrot.org/parrot/wiki/TicketSprint 19:54
allison: ping. 19:55
allison particle: I'd say it's worth deprecating them. it's only a one month cycle
particle ok, then, i'll updated DEPRECATED.pod and create tickets
Coke eliminating assignment syntax for some opcodes is hard.
Just want to verify that we desire spending the energy (if not now, eventually.) 19:56
particle yeah, that's better left to replacing imcc with pirc
allison Coke: yeah, not an urgent priority
particle let's leave DEPRECATED.pod review for another time, this meeting's gone on long enough.
Coke adios.
allison ok, thanks all! 19:57
19:57 rurban left 19:58 Coke left 20:00 jhorwitz left 20:12 PacoLinux left 22:02 Whiteknight joined 22:24 mberends left
particle ENOTWEETY 22:37
Whiteknight urg, the meeting today didn't get logged? 23:02
Tene I logged it! 23:05
pmichaud Whiteknight: irclog.perlgeek.de/parrotsketch/today 23:12
23:17 pmichaud left 23:43 particle left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!