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