"Tuesday at 20:30 UTC"
Set by moderator on 20 September 2010.
01:55 kid51 joined
kid51 kid51's report 01:55
* Mostly dealt with fallout of merge of gc_massacre branch into trunk. Without hacking deep inside C source code files, Parrot will no longer build on boxes with smaller resources (e.g., the 256M physical memory iBook G4 I've used since joining the project).
* Opened 2 BZs for problems consequent to gc_massacre merge. Also posted to list.
* This left no time for other cage cleaning other than previously scheduled closing of TT #1130.
* Secured meeting space for Sat Oct 16 Pacific NW Parrot developers' gathering in Portland OR. RSVP. 01:56
EOR
02:29 GeJ joined 02:39 kid51 left
GeJ GeJ's report 02:54
* Per suggestion of several people on #parrot, I sent a new CLA to Whiteknight. CLA was received and forwarded to other directors of ParF.
* This is a follow up of my previous application (see irclog.perlgeek.de/parrotsketch/200...3#i_828199 ). I sent a CLA via snail mail back then but it seems it never crossed the ocean.
* Provided that my application comes back on topic, I'd be glad to offer any help available.
* As a starter, I'll try to enroll in the codingstd brigade. Also in order to brush up my PIR-fu, I intend to resume the Perl2Pir test conversion effort that got me a commit bit offering the first time. In short, any boring and repetitive task so that the real brainiacs of the project can work on things that matter.
dash dash space [return]
04:30 ascent left 04:45 ash_ left 05:48 contingencyplan left 09:00 ascent joined 10:50 particle left, particle joined 12:44 bluescreen joined 12:48 particle1 joined 12:52 particle left 13:33 bluescreen left 13:59 contingencyplan joined 14:09 contingencyplan left 14:11 contingencyplan joined
Coke haven't reported in a while; Discovered that both partcl/partcl-nqp are broken (notfound++ for a patch which should fix one of them.). no parrot-shaped tuits for a while. 16:25
EOR
17:11 ash_ joined 17:59 ash_ left 18:32 luben joined
luben What I did: 18:32
* Removed deprecated logical vtable functions
* Ported logical ops on PMCs to use get_bool vtable function
* Rewrited HashIterator PMC - simplification and optimization
* Optimized hash cloning and other hash operations
What I will do:
* Help bacek and nick with GC internals (if I have some free
time this week)
.EOR
18:52 mikehh joined 19:00 ash_ joined
mikehh What I did since my last report: 19:01
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* branch testing and fixing
* sorted out merge conflicts in html_cleanup branch, brought up to date with trunk today
experimented with bringing all docs to html (haven't commited that yet)
still need to build index pages
* cage cleaning gc branches
What I intend to do in the next week:
* testing and fixing
* do some more work on html_cleanup branch
.eor
19:28 ash_ left 19:31 ash_ joined 19:35 atrodo joined 19:41 nwellnhof joined
nwellnhof what i did 19:41
- worked on new string macros
- worked on gc timing and gc_ms2
plans 19:42
- merge string_macros branch
eor
20:10 dukeleto joined
dukeleto What I did: 20:12
* applied patch from kid51++ to make 'make smoke' respect TEST_JOBS
* wrote some more git-related docs
* kept github in sync
What I will do:
* Help with planning the Parrot Hackathon 20:13
* Work on porting mk_language_shell/create_language
* write more git docs
Blocking on:
* IRL
EOR
20:20 kid51 joined, allison joined
Util # Recently done: 20:28
* Gave a Perl 6 talk at Atlanta.pm
* Posted 2 more Perl 6 solutions to RosettaCode tasks
* Resumed work on TT#1570 and TT#1302 - neither closed yet.
# Plan to do:
* Close tickets
# Blockers:
* $Util += 1 when today =~ /^\\d\\d\\d\\d-09-28$/;
# Ticket changes in the last week:
curl -s 'trac.parrot.org/parrot/timeline?day...ticket=on' | perl -wlne '/<em[^>]+\\(([^"]+)\\)">/ or next; $h{$1}++; END {printf "%7d\\t%s\\n", $h{$_}, $_ for sort keys %h}'
1 closed: done
10 closed: fixed
1 closed: invalid
11 new
( -1 total )
.end
dukeleto Util++ 20:31
meeting time? 20:32
Util yes
Hello
mikehh it is indeed, hello
allison hihi
cotto ~
kid51 hello 20:34
dukeleto looks like we closed 12 tickets this week
i think we closed a lot of easy tickets in the last few weeks, and now we are into the meaty ones. we probably need a more focused weekly strategy 20:35
kid51 the gc_massacre merge led to problems which (a) led to new tickets; (b) diverted time from handling old tickets
dukeleto Util++ again for the nice report on tickets
mikehh it is probably going to get more difficult to close tickets as the easy are probably gone
however I think we should still aim high 20:36
Util I will add that report each week, unless someone beats me to it.
kid51 net increase of 2 tickets this week, by my count: 619 -> 621
dukeleto Util: yes, that would be awesome
any other important announcements? 20:37
Util kid51: perhaps a difference in the "day" cutoff in Trac's calcs?
kid51 Util: I'm just eyeballing it. 20:38
mikehh I thought the blog posts by whiteknight++ quite significant
GeJ bonjour.
dukeleto I enjoyed the blog posts of kid51++, whiteknight++ and chromatic++ as well
mikehh sure 20:39
dukeleto GeJ is up for a commit bit, is that right?
shall we take care of that? I am +1 to giving GeJ++ a bit
GeJ dukeleto: I've heard some rumor about it, but it is not me to tell.
dukeleto Can I get another +1 focurl -s 'trac.parrot.org/parrot/timeline?day...ticket=on' | perl -wlne '/<em[^>]+\\(([^"]+)\\)">/ or next; $h{$1}++; END {printf "%7d\\t%s\\n", $h{$_}, $_ for sort keys %h}' 20:40
sorry, bad pasting happening on my netbook
How do people feel about giving GeJ++ a bit? 20:41
Util +1 # GeJ
mikehh +1
cotto +1 20:42
kid51 +1; have already discussed assignments with him (see his report)
dukeleto who can actually flip the magical bit? 20:43
cotto coke, for one 20:44
20:44 ash_ left
dukeleto what is our next order of business? deciding the priority for the week? 20:45
GeJ: your bit is in transit 20:46
kid51 q1q 20:47
20:47 allison left
dukeleto Shall we focus on the GC this week? 20:47
kid51 +1
luben q1q
dukeleto Perhaps getting smoke reports on GC-related branches, and adding GC-related tests and working on GC-related TTs? 20:48
luben +1 to focus on GC
20:48 Paul_the_Greek joined
kid51 q2q 20:48
mikehh +1
also keep closing tickets
cotto That's a little harder for random people to dive into, but worthwhile for those who can help.
dukeleto ok, our focus will be GC this week, unless anybody can think of something better (and keep closing tickets) 20:49
GeJ dukeleto: thanks.
mikehh well keeping codetest passing also helps
I am not at all happy with the test t/op/gc-non-recursive.t - I have had it lock up a couple of times 20:51
dukeleto cotto: we should work on our wiki page for intro tasks, i think it is out of date. But I agree with you. Anybody can smoke a branch, so that can be given to new-comers.
GeJ mikehh: I'm willing to wear the codingstd sheriff badge if that can free other people.
mikehh and I know others have had problems with it
dukeleto mikehh: we should work on that, then. can you post something to parrot-dev about what problems it gives you?
GeJ: you might have to fight for it :) we need more smokers, definitely 20:52
nwellnhof the problem with t/op/gc-non-recursive.t is only a small typo
dukeleto nwellnhof: feel free to fix it, please :) 20:53
mikehh don't know it passes for me most times - sometimes it just goes into a loop or something, tests should fail gracefully if they do not pass
nwellnhof $I1 should be $I0 in line 38
dukeleto mikehh: agreed, can discussion of that happen on parrot-dev or #parrot ?
Paul_the_Greek Ah, absolute register numbers.
dukeleto whoever pushed the first question on the stack, go for it. 20:54
kid51: it was you :) question? 20:55
Paul_the_Greek I have a question if the stack has become corrupted.
kid51 1st q is actually a statement: Our Sat Oct 16 Pacific NW developers gathering is on!
Paul_the_Greek Have fun! 20:56
kid51 People from Oregon and Washington state are especially encouraged to attend.
Anyone else who wants to travel, you're welcome.
RSVP to me is helpful.
Any questions about that gathering?
dukeleto kid51: thank you very much for setting that up!
kid51 If not ... luben's question is next. 20:57
luben We have deprecated logical vtables. It is not clear if we have deprecated logical ops on PMCs - in the ticket and DEPRECATED.pod are differend versions.
I have also ported logical ops on pmc to use get_bool vtable
is the job done and could I close the ticket
or the intention was also to remove the ops? 20:58
dukeleto I am not sure. Anybody?
luben My feeling is that we should not remove logical ops on PMCs. If we remove them, we have to remove also Boolean PMC - they are useless without operations that work on them 20:59
cotto unless we recommend methods 21:00
Paul_the_Greek Why would we remove them?
luben recomendation was to use get_bool 21:01
Paul_the_Greek Are we talking about AND, OR, etc.?
luben yes
about and_p_p_p or_p_p_p, not_p_p, xor_p_p_p 21:02
cotto My understanding from chromatic is that there's a correlation between the speed of a VM and the number of ops. Removing one op doesn't necessarily make us faster, but there's a general trend.
That's why we're moving away from putting everything and the kitchen sink into core ops. 21:03
Paul_the_Greek Sorry for being dense, but why would we remove those ops?
What would replace them?
dukeleto luben: i think you should pose the question to parrot-dev, a lot of people that are not hear probably have informed things to say about it
s/not hear/not here/
luben ok, I will write a mail
cotto probably because they're used seldom enough that methods wouldn't be much slower
+1 to parrot-dev
dukeleto next question?
Paul_the_Greek I have one. 21:04
dukeleto Paul_the_Greek: go for it.
21:04 ash_ joined
Paul_the_Greek So it seems that we agree that promoting Number to Complex is the wrong way to go. 21:04
So what do we do with complex ranges? I think we should throw an exception.
The alternative is to return NaN, but that seems wrong. 21:05
dukeleto Paul_the_Greek: i have waited to weigh in on that fun discussion :)
Paul_the_Greek For example, sqrt(negative number) should throw an exception.
dukeleto Paul_the_Greek: i agree. sqrt(on reals) should do that. sqrt(on complex) should return a complex number 21:06
Paul_the_Greek: it comes down to there being 2 sqrt functions, one for real input and one for complex input
Paul_the_Greek I believe that all the complex functions do the right thing.
It's Number that's the question. There are many functions with complex ranges that should throw an exception. 21:07
Util Paul_the_Greek: it seems easy enough to achieve any complex ranges with small .maps, or with multiplies by i. +1 for exception on Complex ranges
dukeleto Paul_the_Greek: we should make our system more consistent, while at the same time making it easy for HLL's 21:08
Paul_the_Greek Okay, so now what about native floats? Also throw an exception?
dukeleto Paul_the_Greek: i think you should start a branch for it, and ask people on parrot-dev for feedback.
Paul_the_Greek (not sure there are any operations on native floats that care.)
dukeleto Paul_the_Greek: i am +1 for sqrt(negative real number) to throw an exception
Paul_the_Greek I asked on parrot-dev and a few people responded.
It's better than NaN or a random value, which is what you get now. 21:09
luben the discussion on parrot-dev was more for NaN
if I remember corectly
nwellnhof but we throw an exception on division by zero.
Paul_the_Greek Right, but NaN just isn't correct.
21:10 allison joined
Util floats (Num): +1 to exception. Anything but Complex is "not complex", hence sqrt in not defined 21:10
Paul_the_Greek Well, it's defined, it's just defined as a complex value. But we don't want to promote. Hence an exception.
So I should start a branch, huh? Okay, I'll suck it up. 21:11
Util "not defined" in the current ring (or is it field?). anyway, I agree.
dukeleto Paul_the_Greek: go ahead and make a branch for it. if you are changing the behavior of multiple functions, do each one in a different branch
Paul_the_Greek Whoa.
I'm adding some trig functions and changing the behavior of various ones. Dozens of branches? 21:12
dukeleto Paul_the_Greek: i mean, if you are changing different behaviors
Paul_the_Greek Oh, okay.
dukeleto Paul_the_Greek: so one branch per behavior change
Paul_the_Greek Righto.
dukeleto Paul_the_Greek: don't change 5 behaviors in one branch, is all I am saying 21:13
next question?
cotto same general principle we have for branches
kid51 my 2q:
This is related to GC
dukeleto has to vamos soon
kid51 A number of us -- dukeleto, myself, Andy D, sorear -- have expressed concern that we continue to make sure that Parrot can be compiled and run in what, by today's standards, are low-resource environments. 21:14
But I suspect others amongst us are not as concerned with that. 21:15
Is there some way we can frame that discussion?
(I realize this is very vague.)
dukeleto kid51: some blog posts about it would be nice, see what our users think
Paul_the_Greek Need to specify minimum requirements.
mikehh I think this is important if we are going to run anywhere other than the latest and greatest 21:16
dukeleto kid51: could be something to discuss at the hackathon. i.e. what is the min hardware to run parrot?
cotto and try to build Parrot one a machine with those minimum requirements
dukeleto if we want parrot on RTEMS or other embedded devices, this is an important question
mikehh also smartphones etc 21:17
dukeleto this comes down to parrot not having a buildfarm, which I want to fix. I just haven't figured out how, yet.
nwellnhof i don't think it's as big an issue as it looks. the new GC code has a provisional threshold that is a bit wasteful. but that will be fixed.
luben we are in the middle of major GCsys refactor - we could expect some regressions
kid51 nwellnhof: I'm glad to hear that
Util I see two lobes to the discussion: A) On *this* hardware config (or *this* restricted situation) is it practical to expect Parrot to run. B) Parrot will run faster/better in *any* env if we make certain changes to reduce size.
dukeleto mikehh: yes, embedded devices include smartphones, smart toasters, etc :)
kid51 It would be great if nwellnhof, luben, bacek and others who are deep into the GC efforts could blog ... 21:18
... so that those of us who don't understand those realms can be apprised of our progress.
mikehh I believe NotFound++ got it running on a smartphone
dukeleto recent GC changes made the issue very apparent, but this issue will pop up again and again. it is not directly related to the GC changes. 21:19
Util wants Parrot everywhere, to get Perl 6 everywhere!
mikehh I think things like lorito etc should reduce requirments significantly 21:20
dukeleto mikehh: when they are done. not necessarily so when they are "in progress"
sorear parrot-nqp has O(N) memory usage, and requires 450MB to compile 6000 lines of code 21:21
dukeleto Util: me too. That is why I stuffed parrot in postgres, so I could get perl 6 in postgres!
sorear let's set a goal in kb/line
mikehh dukeleto: yes I agree, but we shold watch that, especially like kid51's ppc platform
dukeleto sorear: i like specifics
sorear currently at 75 (ILP32)
dukeleto sorear: do you have recommendations for ways to reduce kb/line? 21:22
sorear: that sounds like a great email to parot-dev and/or #parrot discussion
Util sorear: OK by me to require tiny platforms to only run .pbc that was pre-compiled on a larger platform. 21:23
nwellnhof sorear: if you tested that with the current GC, the numbers are pretty meaningless.
sorear nwellnhof: the current GC is the only one that matters 21:25
Paul_the_Greek How many passes in parrot-nqp?
sorear anyways, I've run this test monthly since March or so
luben O(N) for a compiler is OK - the problem is that we could not divide the task in small compilation units and link them afterwards because of the shared lexpads 21:26
sorear MB for Rakudo's setting has gone between a low of 350 and a high of 2000
the current 450 doesn't seem like a fluke
nwellnhof sorear: currently, every non-trivial program will consume about 300MB at least.
dukeleto Let's bring that discussion to #parrot or parrot-dev. did we have any more questions?
sorear nwellnhof: oh, I tested that after applying kid51's patch
nwellnhof: the one that cuts gc_threshold to 16mb 21:27
nwellnhof sorear: ok, that should make a difference. have you tried the gc_ms2_tuning branch?
kid51 must leave; will read backscroll 21:28
21:28 kid51 left
dukeleto If there are no more questions, I think we call it a wrap. Please send emails to parrot-dev, create branches, ask people to smoke them on parrot-dev and have an awesome week. 21:30
and take the fun to #parrot
21:30 nwellnhof left, dukeleto left, Paul_the_Greek left 21:31 allison left 21:33 luben left, atrodo left 22:26 kid51 joined 23:00 kid51 is now known as kid51_at_dinner 23:24 ash_ 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!