Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-09-21

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
04:03 ash_ left #parrotsketch
04:04 ash_ joined #parrotsketch
04:26 ash_ left #parrotsketch
08:17 Tene left #parrotsketch
08:36 mikehh joined #parrotsketch
10:38 kid51 joined #parrotsketch
12:17 kid51 left #parrotsketch
12:19 kid51 joined #parrotsketch
12:19 kid51 kid51's report
12:19 kid51 * Cage cleaning:  Examined several dozen older (4 mo+) tickets.  Posted queries in them to get status update or determine closability.
12:20 kid51 * Planning to apply patch and close http://trac.parrot.org/parrot/ticket/1130 after release.  (Applied, but ticket not yet closed.)
12:20 kid51 * Met with whiteknight to discuss Parrot Foundation issues and status of project.  He blogged; got feedback from chromatic et al; he blogged again.  I blogged about state of PDDs:  http://www.parrot.org/content/parr​ot-design-documents-need-overhaul
12:20 kid51 * Along with dukeleto, trying to arrange space for proposed Sat Oct 16 gathering in Portland.
12:20 kid51 EOR
12:20 kid51 left #parrotsketch
12:50 ash_ joined #parrotsketch
14:22 ash_ left #parrotsketch
14:30 ash_ joined #parrotsketch
16:18 mikehh What I did since my last report:
16:18 mikehh * building and testing parrot on amd64/i386, with gcc/g++
16:18 mikehh * some fixes
16:18 mikehh * branch testing and fixing
16:18 mikehh * working on merging trunk into html_cleanup branch (quite a few conflicts)
16:18 mikehh What I intend to do in the next week:
16:18 mikehh * testing and fixing
16:18 mikehh * do some more work on html_cleanup branch
16:18 mikehh .eor
16:18 mikehh don't know if I will be back in time for #ps
18:31 atrodo joined #parrotsketch
19:02 NotFound joined #parrotsketch
19:28 NotFound What I did:
19:28 NotFound -parrot
19:28 NotFound * Implemented Boolean init_int
19:28 NotFound * Implemented ExceptionHandler init_int
19:28 NotFound * Minor fixes and cleanups
19:28 NotFound -winxed
19:28 NotFound * Closures!
19:28 NotFound * Operators === and !==
19:28 NotFound * Minor fixes and celanups
19:28 NotFound * Constructors are now called in new by id with one arg.
19:28 NotFound What I will do:
19:28 NotFound No fixed plan.
19:28 NotFound EOR
19:32 plobsing joined #parrotsketch
19:44 kid51 joined #parrotsketch
19:53 allison joined #parrotsketch
20:05 plobsing What I Did:
20:05 plobsing * optimizations for rakudo startup time (mostly freeze/thaw)
20:05 plobsing * more optimizations
20:05 plobsing What I Plan:
20:05 plobsing What I Plan:
20:05 plobsing What I Plan:
20:05 plobsing * more optimizations
20:06 plobsing * eliminate tagged union constant table (lots of win to be had here)
20:06 plobsing * allow PMC constant table backreferences (should significantly reduce subs, lexinfos in images)
20:06 plobsing * generalize const table backreferences to pbc linkage requested by jnthn
20:06 plobsing EOR
20:07 cotto #done:
20:07 cotto - wrote more github plugin test cases
20:07 cotto - closed a few tickets, made some minor commits
20:07 cotto #to do:
20:07 cotto - run more manual tests for the github plugin
20:10 ash_ left #parrotsketch
20:16 chromatic joined #parrotsketch
20:20 chromatic What I did: contributed lots of optimizations and profiling, especially hashes, packfiles, and startup.
20:20 chromatic What I will do: deprecations, working on gc_massacre.
20:20 chromatic What I want to do: deprecate NULL as a synonym for STRINGNULL.
20:22 Util # Done:
20:22 Util * Nothing; Tuit crop failure.
20:22 Util # Plan:
20:22 Util * Talk Thurs @Atlanta.pm on Perl 6: Rationals, Reduce, and Refactoring
20:22 Util * TT#1302 - PIR todo() is frequently misused
20:22 Util * TT#1217 - t/dynpmc/foo.t converted to PIR
20:22 Util * TT#1570 - Out-of-date binaries/packages on Parrot.org
20:22 Util = kid51++ for lighting a fire; Can do starting Fri evening.
20:22 Util # Blockers:
20:22 Util * No Tuits until Friday
20:22 Util .end
20:23 allison I shepherded Parrot 2.6 into the next release of Ubuntu (10.10).
20:23 allison EOR
20:23 Paul_the_Greek joined #parrotsketch
20:30 dukeleto joined #parrotsketch
20:30 * dukeleto waves hello
20:30 Util hello
20:30 NotFound Hola
20:30 mikehh howdy
20:30 cotto good day
20:31 Paul_the_Greek Greetings!
20:31 chromatic hello
20:32 chromatic Let's review last week.
20:32 chromatic How'd we do on closing tickets?
20:32 cotto looks like 15 this week
20:32 kid51 By my count (report #11), we went from 629 to 619 net
20:33 chromatic Down a bit, but still progress in the right direction.
20:33 kid51 About 15 gross
20:33 kid51 -15
20:34 chromatic Should we set a goal for next week?
20:34 mikehh keep it the same
20:34 chromatic 25?
20:34 mikehh yeah
20:35 Paul_the_Greek Yup.
20:35 chromatic Next up: removing deprecations?
20:36 mikehh gerd++ released 2.8.0 - no problems with it
20:36 mikehh testing point of view that is
20:36 chromatic Did we finally yank CodeString?
20:38 chromatic I'll take that as a no.
20:38 chromatic How are we on gc_massacre?  bacek called for testing.
20:38 dukeleto chromatic: PGE and data_json still use CodeString
20:38 cotto He's back, so it probably won't be long before a merge.
20:38 mikehh tests ok by me - kid51 had a problem on linux/i386
20:38 chromatic I thought we had a replacement for data_json.
20:39 NotFound We have a candidate.
20:39 chromatic What do we need before we can replace it?
20:41 NotFound No idea, someone fluent with PCT should look at it.
20:41 chromatic Okay, let's set that aside for now.
20:41 chromatic What do we need to accomplish before 2.9.0?
20:43 chromatic Anyone?
20:44 NotFound The roadmap report don't show anything
20:44 dukeleto hmmmmm
20:44 mikehh well we obviously need to get any necessary deprecation notices in place for 3.0
20:45 chromatic Right.
20:45 mikehh improve gc as much as possible
20:46 mikehh bacek said he had to split off some stuff he had planned for gc_massacre, but the tools are in place
20:47 chromatic Merging that as soon as possible helps.
20:47 mikehh it still does not build with g++
20:48 chromatic Shall we make that a priority?
20:48 mikehh most of it due to const problems
20:49 mikehh a lot of things that should by const are not - especially now we ar using immutable strings
20:50 NotFound immutable string aren't const, that is the problem.
20:51 chromatic Is that necessary to merge the branch?
20:52 mikehh g++ tends to pick up things that gcc does not, even if it is a hassle at times
20:53 kid51 (In a couple of hours I will post to list about the problem I'm having with t/pmc/filehandle.t in gc_massacre branch.)
20:53 NotFound I'd like to keep the c++ buildability, but not at the cost of adding lots more of unsafe const casts
20:53 chromatic We should keep C++ buildable, but do we need to fix immutable strings and constness to do so?
20:54 NotFound Making string really const is hard, even if we kill buffer resizing and such, we still have the hasshval mutable
20:54 whiteknight joined #parrotsketch
20:55 NotFound The other way is to drop the const from all STRING parameters and return values,
20:55 chromatic Or we could calculate hashval when we create STRINGs.
20:55 * cotto was thinking that too
20:55 Paul_the_Greek When is it calculated now?
20:56 mikehh kid51: I have not had a chance to look at it yet, but will do later
20:56 chromatic lazily
20:56 Paul_the_Greek Don't need it if string isn't used as a hash key?
20:56 NotFound Yes, if we also kill the buffer manipulations for optimization
20:57 NotFound Or find a way of doing the manipulations without changing the pointer value, but I doubt that's possible.
20:57 chromatic Right.
20:57 chromatic What's the minimal work we have to do to make the branch work with g++?
20:57 Paul_the_Greek Lots of strings aren't.
20:58 chromatic Lots of *big* strings aren't used as hash keys.
20:58 mikehh I think I posted the errors I got to the list in bacek's post on testing
20:58 NotFound I can take a look at the branch tomorrow, maybe is easily fixable.
20:58 Paul_the_Greek Don't want to hash those if it can be avoided.
20:59 chromatic Anything else on this branch to discuss now?
21:01 chromatic Let's move on.
21:01 chromatic Any other priorities for this week?
21:02 chromatic Let's take questions then.
21:03 Paul_the_Greek I need voting on two issues, if that counts as questions.
21:03 chromatic Go ahead.
21:03 Paul_the_Greek We support the full complement of trig functions, except for four.
21:03 Paul_the_Greek Shall I add them?
21:03 mikehh I want to try and work on html_cleanup - I did a merge with trunk just after the release, but quite a few conflicts I need to resolve
21:04 chromatic +1 to dynops
21:05 cotto +1 to dynops
21:05 whiteknight +1 to dynops
21:05 Paul_the_Greek They are supported by Complex already.
21:05 Paul_the_Greek Shall we add support for the inverse hyperbolic trig functions?
21:05 Paul_the_Greek Also supported by Complex.
21:05 chromatic Are these ops or methods?
21:06 dukeleto Paul_the_Greek: as long as they are dynops not loaded by default, I am +1
21:06 Paul_the_Greek If they are to operate on Number, then they would have to be ops, right?
21:06 Paul_the_Greek Dynops.
21:06 Paul_the_Greek Okay, this one is harder ...
21:07 Paul_the_Greek Conversion of float to integer when float is Inf or NaN.
21:07 Paul_the_Greek Raise exception?
21:07 chromatic +1 to exception
21:07 whiteknight +1 to exception
21:07 Paul_the_Greek Even in something like set_i_n ?
21:08 Paul_the_Greek I suspect this is all over the place.
21:08 Paul_the_Greek Every (FLOATVAL) cast is suspect.
21:08 NotFound What about infinities?
21:08 Paul_the_Greek Sorry, (INTVAL) cast.
21:08 dukeleto Paul_the_Greek: does it require that every conversion function check for Inf/NaN? what are the performance ramifications?
21:08 Paul_the_Greek I don't know the performance hit yet.
21:09 dukeleto Paul_the_Greek: I am +1, but that is dependent on performance ramifications
21:09 Paul_the_Greek Okay, I'll put together a benchmark and check it out. I'll do this in a branch.
21:09 NotFound Hard to evaluate. The checks can avoid lots of opportunities for compiler optimizations.
21:09 dukeleto Paul_the_Greek: +1 to making a branch for it so we can test the performance implications
21:09 mikehh it should be just a flag check, shouldn't it?
21:10 mikehh and converting from a float to integer is a fairly bit effort anyway
21:10 Paul_the_Greek I don't know what it involves.
21:10 Paul_the_Greek We could also add a flag like the one we have for overflow.
21:11 Paul_the_Greek If set, exception. If clear, undefined result.
21:11 NotFound mikehh: if it gets in the way of the optimizer, a simple check can have impact.
21:11 Paul_the_Greek I'll do some research.
21:11 * dukeleto is about to go out for a run, but notes that git migration stuff is coming along. Expanding the docs and figuring out how to best port mk_lang/create_language tools
21:12 NotFound I don't like that kind a flag. Fliping such flags in a part of a program can impact completely unrelated parts.
21:12 whiteknight agreed
21:12 chromatic Sounds like we need more data.
21:12 Paul_the_Greek I agree. Let's just signal exception unless it's horribly inefficient.
21:13 Paul_the_Greek I'll get more data.
21:13 chromatic Other questions?
21:13 whiteknight me
21:14 chromatic go ahead
21:14 mikehh the standard has specific bit patterns for Nan's and Inf's
21:14 whiteknight TT #264: Do we want the methods that allison describes there? We do have dynops for the same purpose, but I would argue that the operations are important enough to be methods on ParrotInterpreter
21:15 whiteknight so many programs would use those methods, that the dynops would basically always be loaded
21:15 whiteknight s/would use those methods/would use those dynops/
21:16 chromatic These don't seem like attributes of an interp to me.
21:16 whiteknight we do have the stdhandle method there now. So the question is do we improve it (by breaking it into specific methods) or do we remove it and rely exclusively on the dynops?
21:17 chromatic Slight preference for dynops.
21:17 chromatic Not that I favor having them as dynops, but....
21:17 NotFound That battle was already fought.
21:17 chromatic Yeah.
21:17 whiteknight The methods vs dynops battle was never fought, as far as I have seen
21:18 whiteknight never explicitly, anyway
21:18 NotFound whiteknight: the battle about not having the op. By the way, If I remember well they aren't dyn anymore.
21:19 whiteknight I'm not saying anything about the dynops. The dynops stay. I only care about the fate of the stdhandle method
21:19 allison they're stored in ParrotIOData in the interpreter struct, which was the motivation for the methods
21:19 NotFound They live in src/ops/io.ops right now
21:20 allison that is, the interpreter is acting as the "global" data store for random items like the std* handles
21:20 chromatic They don't seem interpreter specific to me; they seem process global.
21:21 allison if you're running two interpreters/threads, it can be modified locally per interpreter
21:21 allison I think the dynops work
21:21 mikehh Paul_the_Greek: a good source is http://speleotrove.com/decimal/ - mainly decimal floating point but plenty of links to problems with floating point in general
21:21 allison and that it's not modified terribly often
21:22 allison there should be a way to do it, and it should be standard across the three
21:22 NotFound Uh, we have a mix. getstd... are ops and setstd are dynops
21:23 Paul_the_Greek mikehh: Thanks!
21:23 allison NotFound: yup, that's where the problem lies
21:23 allison methods or not isn't terribly important to me
21:23 whiteknight we can table this issue and move discussion to the ticket or #parrot
21:24 chromatic #parrot seems better to me
21:24 chromatic Other questions?
21:24 whiteknight it doesn't seem like strong feelings either way to me
21:25 chromatic My question: for 2.9, any objections to deprecating the use of NULL as equivalent to STRINGNULL?  We'll have to change function signatures to turn ARGIN_NULLOK(STRING *s) to ARGIN(STRING *s).
21:26 NotFound chromatic: I think that external API functions should accept NUL
21:27 chromatic Why?
21:28 NotFound Mainly to avoid segfaulting too much. Secondarily, there is no way to get the STRINGNULL value from the outside.
21:29 chromatic STRING *STRINGULL = Parrot_get_stringnull();
21:29 kid51 left #parrotsketch
21:30 NotFound Did we have that?
21:30 chromatic We could.
21:30 chromatic We have something similar for PMCNULL.
21:32 NotFound Did we? I think tests for PMCnullness in the extern interface got disabled some time ago because they were based in link tricks,
21:33 chromatic I thought it was trying to export the PMCNULL symbol itself, which is silly.
21:35 NotFound Forgot another reason: STRING attributes should be handled with more care to avoid using default zero initalized values.
21:36 chromatic That sounds like something to fix within libparrot.
21:38 NotFound Yes, and probably hard to fix.
21:40 chromatic If we allow NULL in exported functions, there's no point in fixing unexported functions.
21:40 chromatic There are too many ways a NULL pointer could sneak into the string subsystem.
21:43 NotFound I'm not strongly against that change, but I fear that later we may need to undo most of it because of security reasons.
21:44 NotFound (if some day we get security arenas)
21:44 chromatic Anyone else have an opinion pro or con?
21:47 mikehh I like the concept of SRINGNULL not being egual to NULL
21:48 mikehh STRING
21:48 NotFound Is not equal already. Just equivalent from the STRING_IS_NULL point of view.
21:50 chromatic Any other opinions?  We can wind down.
21:53 chromatic Okay, it's a wrap then.  Close tickets!
22:02 chromatic left #parrotsketch
22:09 NotFound left #parrotsketch
22:16 dukeleto left #parrotsketch
22:21 whiteknight left #parrotsketch
22:23 Paul_the_Greek left #parrotsketch
22:45 whiteknight joined #parrotsketch
23:12 ash_ joined #parrotsketch
23:15 kid51 joined #parrotsketch
23:49 kid51 left #parrotsketch
23:53 kid51 joined #parrotsketch
23:56 plobsing left #parrotsketch

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary