Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-09-28

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

All times shown according to UTC.

Time Nick Message
01:55 kid51 joined #parrotsketch
01:55 kid51 kid51's report
01:55 kid51 * 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).
01:55 kid51 * Opened 2 BZs for problems consequent to gc_massacre merge.   Also posted to list.
01:55 kid51 * This left no time for other cage cleaning other than previously scheduled closing of TT #1130.
01:56 kid51 * Secured meeting space for Sat Oct 16 Pacific NW Parrot developers' gathering in Portland OR.  RSVP.
01:56 kid51 EOR
02:29 GeJ joined #parrotsketch
02:39 kid51 left #parrotsketch
02:54 GeJ GeJ's report
02:54 GeJ * Per suggestion of several people on #parrot, I sent a new CLA to Whiteknight.  CLA was received and forwarded to other directors of ParF.
02:54 GeJ * This is a follow up of my previous application (see  http://irclog.perlgeek.de/parrotsketch/2009-01-13#i_828199  ).  I sent a CLA via snail mail back then but it seems it never crossed the ocean.
02:54 GeJ * Provided that my application comes back on topic, I'd be glad to offer any help available.
02:54 GeJ * 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.
02:54 GeJ dash dash space [return]
04:30 ascent left #parrotsketch
04:45 ash_ left #parrotsketch
05:48 contingencyplan left #parrotsketch
09:00 ascent joined #parrotsketch
10:50 particle left #parrotsketch
10:50 particle joined #parrotsketch
12:44 bluescreen joined #parrotsketch
12:48 particle1 joined #parrotsketch
12:52 particle left #parrotsketch
13:33 bluescreen left #parrotsketch
13:59 contingencyplan joined #parrotsketch
14:09 contingencyplan left #parrotsketch
14:11 contingencyplan joined #parrotsketch
16:25 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 Coke EOR
17:11 ash_ joined #parrotsketch
17:59 ash_ left #parrotsketch
18:32 luben joined #parrotsketch
18:32 luben What I did:
18:32 luben * Removed deprecated logical vtable functions
18:32 luben * Ported logical ops on PMCs to use get_bool vtable function
18:32 luben * Rewrited HashIterator PMC - simplification and optimization
18:32 luben * Optimized hash cloning and other hash operations
18:32 luben What I will do:
18:32 luben * Help bacek and nick with GC internals (if I have some free
18:32 luben time this week)
18:32 luben .EOR
18:52 mikehh joined #parrotsketch
19:00 ash_ joined #parrotsketch
19:01 mikehh What I did since my last report:
19:01 mikehh * building and testing parrot on amd64/i386, with gcc/g++
19:01 mikehh * some fixes
19:01 mikehh * branch testing and fixing
19:01 mikehh * sorted out merge conflicts in html_cleanup branch, brought up to date with trunk today
19:01 mikehh experimented with bringing all docs to html (haven't commited that yet)
19:01 mikehh still need to build index pages
19:01 mikehh * cage cleaning gc branches
19:01 mikehh What I intend to do in the next week:
19:01 mikehh * testing and fixing
19:01 mikehh * do some more work on html_cleanup branch
19:01 mikehh .eor
19:28 ash_ left #parrotsketch
19:31 ash_ joined #parrotsketch
19:35 atrodo joined #parrotsketch
19:41 nwellnhof joined #parrotsketch
19:41 nwellnhof what i did
19:41 nwellnhof - worked on new string macros
19:41 nwellnhof - worked on gc timing and gc_ms2
19:42 nwellnhof plans
19:42 nwellnhof - merge string_macros branch
19:42 nwellnhof eor
20:10 dukeleto joined #parrotsketch
20:12 dukeleto What I did:
20:12 dukeleto * applied patch from kid51++ to make 'make smoke' respect TEST_JOBS
20:12 dukeleto * wrote some more git-related docs
20:12 dukeleto * kept github in sync
20:12 dukeleto What I will do:
20:13 dukeleto * Help with planning the Parrot Hackathon
20:13 dukeleto * Work on porting mk_language_shell/create_language
20:13 dukeleto * write more git docs
20:13 dukeleto Blocking on:
20:13 dukeleto * IRL
20:13 dukeleto EOR
20:20 kid51 joined #parrotsketch
20:20 allison joined #parrotsketch
20:28 Util # Recently done:
20:28 Util * Gave a Perl 6 talk at Atlanta.pm
20:28 Util * Posted 2 more Perl 6 solutions to RosettaCode tasks
20:28 Util * Resumed work on TT#1570 and TT#1302 - neither closed yet.
20:28 Util # Plan to do:
20:28 Util * Close tickets
20:28 Util # Blockers:
20:28 Util * $Util += 1 when today =~ /^\d\d\d\d-09-28$/;
20:28 Util # Ticket changes in the last week:
20:28 Util curl -s 'http://trac.parrot.org/parrot/timeline?daysback=7&amp;ticket=on' | perl -wlne '/<em[^>]+\(([^"]+)\)">/ or next; $h{$1}++; END {printf "%7d\t%s\n", $h{$_}, $_ for sort keys %h}'
20:28 Util 1 closed: done
20:28 Util 10 closed: fixed
20:28 Util 1 closed: invalid
20:28 Util 11 new
20:28 Util ( -1 total )
20:28 Util .end
20:31 dukeleto Util++
20:32 dukeleto meeting time?
20:32 Util yes
20:32 Util Hello
20:32 mikehh it is indeed, hello
20:32 allison hihi
20:32 cotto ~
20:34 kid51 hello
20:34 dukeleto looks like we closed 12 tickets this week
20:35 dukeleto 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
20:35 dukeleto Util++ again for the nice report on tickets
20:35 mikehh it is probably going to get more difficult to close tickets as the easy are probably gone
20:36 mikehh however I think we should still aim high
20:36 Util I will add that report each week, unless someone beats me to it.
20:36 kid51 net increase of 2 tickets this week, by my count: 619 -> 621
20:36 dukeleto Util: yes, that would be awesome
20:37 dukeleto any other important announcements?
20:37 Util kid51: perhaps a difference in the "day" cutoff in Trac's calcs?
20:38 kid51 Util: I'm just eyeballing it.
20:38 mikehh I thought the blog posts by whiteknight++ quite significant
20:38 GeJ bonjour.
20:38 dukeleto I enjoyed the blog posts of kid51++, whiteknight++ and chromatic++ as well
20:39 mikehh sure
20:39 dukeleto GeJ is up for a commit bit, is that right?
20:39 dukeleto shall we take care of that? I am +1 to giving GeJ++ a bit
20:39 GeJ dukeleto: I've heard some rumor about it, but it is not me to tell.
20:40 dukeleto Can I get another +1 focurl -s 'http://trac.parrot.org/parrot/timeline?daysback=7&amp;ticket=on' | perl -wlne  '/<em[^>]+\(([^"]+)\)">/ or next; $h{$1}++; END {printf "%7d\t%s\n", $h{$_}, $_ for sort keys %h}'
20:40 dukeleto sorry, bad pasting happening on my netbook
20:41 dukeleto How do people feel about giving GeJ++ a bit?
20:41 Util +1 # GeJ
20:41 mikehh +1
20:42 cotto +1
20:42 kid51 +1; have already discussed assignments with him (see his report)
20:43 dukeleto who can actually flip the magical bit?
20:44 cotto coke, for one
20:44 ash_ left #parrotsketch
20:45 dukeleto what is our next order of business? deciding the priority for the week?
20:46 dukeleto GeJ: your bit is in transit
20:47 kid51 q1q
20:47 allison left #parrotsketch
20:47 dukeleto Shall we focus on the GC this week?
20:47 kid51 +1
20:47 luben q1q
20:48 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 #parrotsketch
20:48 kid51 q2q
20:48 mikehh +1
20:48 mikehh also keep closing tickets
20:48 cotto That's a little harder for random people to dive into, but worthwhile for those who can help.
20:49 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.
20:49 mikehh well keeping codetest passing also helps
20:51 mikehh 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.
20:51 GeJ mikehh: I'm willing to wear the codingstd sheriff badge if that can free other people.
20:51 mikehh and I know others have had problems with it
20:51 dukeleto mikehh: we should work on that, then. can you post something to parrot-dev about what problems it gives you?
20:52 dukeleto 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
20:53 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
20:53 nwellnhof $I1 should be $I0 in line 38
20:53 dukeleto mikehh: agreed, can discussion of that happen on parrot-dev or #parrot ?
20:53 Paul_the_Greek Ah, absolute register numbers.
20:54 dukeleto whoever pushed the first question on the stack, go for it.
20:55 dukeleto kid51: it was you :) question?
20:55 Paul_the_Greek I have a question if the stack has become corrupted.
20:55 kid51 1st q is actually a statement:  Our Sat Oct 16 Pacific NW developers gathering is on!
20:56 Paul_the_Greek Have fun!
20:56 kid51 People from Oregon and Washington state are especially encouraged to attend.
20:56 kid51 Anyone else who wants to travel, you're welcome.
20:56 kid51 RSVP to me is helpful.
20:56 kid51 Any questions about that gathering?
20:56 dukeleto kid51: thank you very much for setting that up!
20:57 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.
20:57 luben I have also ported logical ops on pmc to use get_bool vtable
20:57 luben is the job done and could I close the ticket
20:58 luben or the intention was also to remove the ops?
20:58 dukeleto I am not sure. Anybody?
20:59 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
21:00 cotto unless we recommend methods
21:00 Paul_the_Greek Why would we remove them?
21:01 luben recomendation was to use get_bool
21:01 Paul_the_Greek Are we talking about AND, OR, etc.?
21:01 luben yes
21:02 luben 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.
21:03 cotto 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?
21:03 Paul_the_Greek What would replace them?
21:03 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
21:03 dukeleto s/not hear/not here/
21:03 luben ok, I will write a mail
21:03 cotto probably because they're used seldom enough that methods wouldn't be much slower
21:03 cotto +1 to parrot-dev
21:03 dukeleto next question?
21:04 Paul_the_Greek I have one.
21:04 dukeleto Paul_the_Greek: go for it.
21:04 ash_ joined #parrotsketch
21:04 Paul_the_Greek So it seems that we agree that promoting Number to Complex is the wrong way to go.
21:04 Paul_the_Greek So what do we do with complex ranges? I think we should throw an exception.
21:05 Paul_the_Greek 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 :)
21:05 Paul_the_Greek For example, sqrt(negative number) should throw an exception.
21:06 dukeleto Paul_the_Greek: i agree. sqrt(on reals) should do that. sqrt(on complex) should return a complex number
21:06 dukeleto Paul_the_Greek: it comes down to there being 2 sqrt functions, one for real input and one for complex input
21:06 Paul_the_Greek I believe that all the complex functions do the right thing.
21:07 Paul_the_Greek 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
21:08 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?
21:08 dukeleto Paul_the_Greek: i think you should start a branch for it, and ask people on parrot-dev for feedback.
21:08 Paul_the_Greek (not sure there are any operations on native floats that care.)
21:08 dukeleto Paul_the_Greek: i am +1 for sqrt(negative real number) to throw an exception
21:08 Paul_the_Greek I asked on parrot-dev and a few people responded.
21:09 Paul_the_Greek 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
21:09 luben if I remember corectly
21:09 nwellnhof but we throw an exception on division by zero.
21:09 Paul_the_Greek Right, but NaN just isn't correct.
21:10 allison joined #parrotsketch
21:10 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.
21:11 Paul_the_Greek 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.
21:11 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
21:11 Paul_the_Greek Whoa.
21:12 Paul_the_Greek 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
21:12 Paul_the_Greek Oh, okay.
21:12 dukeleto Paul_the_Greek: so one branch per behavior change
21:12 Paul_the_Greek Righto.
21:13 dukeleto Paul_the_Greek: don't change 5 behaviors in one branch, is all I am saying
21:13 dukeleto next question?
21:13 cotto same general principle we have for branches
21:13 kid51 my 2q:
21:13 kid51 This is related to GC
21:13 * dukeleto has to vamos soon
21:14 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:15 kid51 But I suspect others amongst us are not as concerned with that.
21:15 kid51 Is there some way we can frame that discussion?
21:15 kid51 (I realize this is very vague.)
21:15 dukeleto kid51: some blog posts about it would be nice, see what our users think
21:15 Paul_the_Greek Need to specify minimum requirements.
21:16 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?
21:16 cotto and try to build Parrot one a machine with those minimum requirements
21:16 dukeleto if we want parrot on RTEMS or other embedded devices, this is an important question
21:17 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.
21:17 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.
21:17 luben we are in the middle of major GCsys refactor - we could expect some regressions
21:17 kid51 nwellnhof: I'm glad to hear that
21:17 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.
21:17 dukeleto mikehh: yes, embedded devices include smartphones, smart toasters, etc :)
21:18 kid51 It would be great if nwellnhof, luben, bacek and others who are deep into the GC efforts could blog ...
21:18 kid51 ... so that those of us who don't understand those realms can be apprised of our progress.
21:18 mikehh I believe NotFound++ got it running on a smartphone
21:19 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!
21:20 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"
21:21 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!
21:21 sorear let's set a goal in kb/line
21:21 mikehh dukeleto: yes I agree, but we shold watch that, especially like kid51's ppc platform
21:21 dukeleto sorear: i like specifics
21:21 sorear currently at 75 (ILP32)
21:22 dukeleto sorear: do you have recommendations for ways to reduce kb/line?
21:22 dukeleto sorear: that sounds like a great email to parot-dev and/or #parrot discussion
21:23 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.
21:25 sorear nwellnhof: the current GC is the only one that matters
21:25 Paul_the_Greek How many passes in parrot-nqp?
21:25 sorear anyways, I've run this test monthly since March or so
21:26 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
21:26 sorear the current 450 doesn't seem like a fluke
21:26 nwellnhof sorear: currently, every non-trivial program will consume about 300MB at least.
21:26 dukeleto Let's bring that discussion to #parrot or parrot-dev. did we have any more questions?
21:26 sorear nwellnhof: oh, I tested that after applying kid51's patch
21:27 sorear 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?
21:28 * kid51 must leave; will read backscroll
21:28 kid51 left #parrotsketch
21:30 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 dukeleto and take the fun to #parrot
21:30 nwellnhof left #parrotsketch
21:30 dukeleto left #parrotsketch
21:30 Paul_the_Greek left #parrotsketch
21:31 allison left #parrotsketch
21:33 luben left #parrotsketch
21:33 atrodo left #parrotsketch
22:26 kid51 joined #parrotsketch
23:00 kid51 is now known as kid51_at_dinner
23:24 ash_ left #parrotsketch

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