Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets; remove deprecated items (especially CodeString); record deprecations; polish for 2.8 release
Set by moderator on 14 September 2010.
00:00 SingAlong left 00:01 SingAlong_ is now known as SingAlong 00:06 tcurtis joined 00:20 davidfetter left 00:21 Chandon left
whiteknight HAH! I think I got it 00:27
00:32 dngor_ joined 00:33 dngor left
chromatic When do we get a parrot-decepticon account? 00:37
whiteknight whenever we finaly accrue enough parrot-energon 00:38
dalek rrot-linear-algebra: 5894091 | Whiteknight++ | t/methods/complexmatrix2d/row_combine.t:
fix a test that was broken but was failing silently
rrot-linear-algebra: 8e06466 | Whiteknight++ | / (2 files):
update so PLA can submit smolder reports. Add a new prove tool, run_test.nqp, which copies some code from t/harness. Eventually I'll move out shared logic into a shared library
rrot: r49029 | whiteknight++ | trunk/runtime/parrot/library/distutils.pir:
fix to distutils to work with the new parrot smolder server. Adds in an optional smolder_credentials option which can be used to specify the login credentals for the server
00:40
dukeleto mumbles "more than meets the eye" 00:45
whiteknight++ # fixing distutils 00:46
whiteknight thanks! I was about to rip some hair out a while back 00:47
chromatic bacek, per your JFYI mail, how long does take to load perl6.pbc by itself, without doing anything else in x1.pir or x2.pir? 00:48
bacek_at_work chromatic, I didn't test it.
chromatic If it's about .350 seconds, we're golden.
parrot-energon for everyone.
bacek_at_work bacek@illusion:~/src/rakudo$ time parrot perl6.pbc -e ''
real\t0m0.531s
user\t0m0.472s
sys\t0m0.048s
I have no idea why current GC is so slow... 00:49
chromatic Maybe it's the Parrot_gc_avian_mark_and_sweep() function I just found.
whiteknight dukeleto: I don
I don't know if you've looked at it recently, but the PLA t/harness is growing quite mature and sophisticated 00:50
we might be able to merge some of it's ideas back into tapir, depending on how you want to develop that project
dukeleto whiteknight: interesting 00:51
whiteknight: i don't quite know what to do with tapir, and I haven't looked at PLA's t/harness, yet. will do now
whiteknight I'm planning to refactor some of the core logic from my harness out into a shared library.
dukeleto whiteknight: feel free to put it into tapir, you should already have a commit bit
whiteknight dukeleto: I have been thinking for a while about taking all the bits of code from around the ecosystem, and combining them into an uber-test-project somewhere 00:52
dukeleto whiteknight: interesting
whiteknight something that ould provide TAP producer and consumer libraries, xUnit-style test frameworks, smolder support, etc
dukeleto whiteknight: that sounds really cool
whiteknight if tapir wants to be the home for that kind of comprehensive project, I would be fine with that
otherwise I could create something new eventually 00:53
dukeleto whiteknight: might as well put that stuff in tapir. feel free to run with it 01:09
whiteknight okay. You might regret you said that :)
dukeleto whiteknight: let's go ahead and find out ;) 01:10
whiteknight: i wonder what the difference is between the feature set of Parrot's builtin TAP parser and Tapir
dukeleto hasn't even run tapir's test suite in quite a while
does it even work with recent parrots?
whiteknight I have no idea. I haven't touched it 01:13
dukeleto whiteknight: it passes all tests with a recent parrot. nice. 01:14
darbelo++ # feeding tapir while I was gone 01:19
whiteknight: i see your harness is in nqp 01:21
whiteknight yeah.
I'm at the stage where I'm pretty much tired of writing PIR
Parrot is a VM for running any programming language we can possibly imagine, I refuse to be writing programs on it in assembly 01:22
atrodo PIR needs more magic and more fun
whiteknight PIR needs much less magic and much less fun 01:23
dukeleto whiteknight: i made this a long time ago but never did anything with it : github.com/leto/nqptap
01:23 dmalcolm left
dukeleto whiteknight: i hear what you are saying. my motivation for tapir was to write something faster than Perl 5, though. NQP is much slower. 01:24
bacek_at_work msg Coke I pushed aloha into gtihub.com/bacek/aloha. Feel free to hack lib/B/B/M/Msg.pm :)
purl Message for coke stored.
aloha OK. I'll deliver the message.
dukeleto whiteknight: which leads to much longer test runs, which makes people unhappy.
whiteknight yeah, I know what you mean
dalek kudo: 39b41ad | colomon++ | src/core/ (4 files):
Split .pick into .pick and .roll.

This is a straightforward effort to split the existing code. There are at least a couple of clear issues with this code, but cleaning them up is probably best left until we have some better tests for these two methods.
chromatic I hope there's a .pick and .pop next. 01:25
dukeleto ponders a .pick, .lick and .flick 01:28
dukeleto stops pondering that
dalek ast: 91aafc5 | colomon++ | / (3 files):
[t/spec] Change pick with :replace to roll, deleting entirely one test which no longer made sense.
whiteknight okay, I'm out for the night. Later 01:29
dalek rrot-linear-algebra: 686322d | Whiteknight++ | setup.nqp:
fix setup.nqp so information about the blas and lapack libraries found is included in the smolder report
01:29 whiteknight left 01:46 bluescreen joined 01:51 hercynium left
kid51 My first PASS on our new Smolder site: smolder.parrot.org/app/projects/rep...details/22 02:12
dalek tracwiki: v7 | jkeenan++ | SmokingParrot 02:13
tracwiki: Change URL for smolder
purl dalek: that doesn't look right
dalek tracwiki: trac.parrot.org/parrot/wiki/Smoking...ction=diff
dukeleto kid51++ 02:18
dalek kudo: e682712 | pmichaud++ | src/ (4 files):
Switch C<time> and C<now> to be 0-ary terms.
02:31
kudo: 4f3d392 | pmichaud++ | src/core/ (4 files):
Merge branch 'master' of github.com:rakudo/rakudo
cotto lights up a parrot 02:33
02:35 janus left
dalek ast: e2e65b2 | pmichaud++ | S29-context/sleep.t:
[sleep.t]: C<time> does not allow parens after it.
02:37
ast: a25207b | colomon++ | S (3 files):
[t/spec] Add about eighty pick and roll tests, including a new S32-list/roll.t file.
02:43
rrot: r49030 | plobsing++ | trunk/src/pmc/hash.pmc:
remove useless default.{freeze,thaw} calls
02:55
plobsing oops. commit r49030 should read "in *rakudo* startup" 02:56
cotto nice
dukeleto plobsing++ 02:57
tcurtis wonders how many unused hashes are created in Parrot startup. 02:58
cotto dukeleto, what do you know about testing code that accepts github post-receive hooks?
tcurtis, I know an easy way to find out 02:59
tcurtis cotto: oh? 03:00
cotto use whatever luben used 03:01
I think he instrumented Parrot_hash_destroy
nopaste.snit.ch/23343 03:02
s/P/p/
plobsing it's not so easy mapping to where those come from though. I wound up scripting gdb and analyzing the output with perl. 03:04
cotto Do you have anything you'd feel good about posting? I haven't played with gdb scripting.
plobsing it's not great, but I'll post it anyways 03:05
nopaste "plobsing" at 192.168.1.3 pasted "unused hashes gdb script" (26 lines) at nopaste.snit.ch/23374
cotto thanks
nopaste "plobsing" at 192.168.1.3 pasted "unused hashes perl postprocessing" (145 lines) at nopaste.snit.ch/23375 03:06
plobsing you can apparently script it with python, but this fell together in about 5 minutes.
03:06 bluescreen left
cotto Now that you mention it, I remember seeing a video about gdb scripting with Python. 03:07
plobsing do you have the url for it? 03:09
cotto I'll see if I can dig it up. 03:10
dukeleto cotto: what do you want to know?
03:10 kid51 left
cotto I remember seeing this blog post: tromey.com/blog/?p=548 03:12
dukeleto, how do I either fake a callback or get github to send some dummy data? 03:13
s/callback/receive/
03:13 janus joined
dukeleto cotto: what language are you working in ? 03:14
03:14 Andy joined
dukeleto cotto: you want to mock the callback 03:14
cotto python
for the github plugin
dukeleto cotto: you need something like this : labix.org/mocker 03:15
cotto: that is just the first I found
cotto Are you mocking me? 03:16
dukeleto cotto: or code.google.com/p/pymox/wiki/MoxDocumentation
cotto: always ;)
cotto: those are the roughly the equivalent of Test::MockObject for Perl 5
cotto I was thinking more along the lines of wget or curl with some hard-coded data 03:17
dukeleto cotto: if you don't want dependencies, you can do it yourself, as well
cotto: describe a full example test to me
cotto make sure trac is set up properly 03:18
call wget on the right url with some extra post data attached
make sure that the hook dtrt
dukeleto cotto: what is the hook, exactly. i don't fully understand 03:19
cotto My terminology may be confused. The github trac plugin adds a url for trac that you can give to github as a post-receive url so that any new commits get propagated to trac from github. 03:21
that's what I'm asking about testing 03:26
dukeleto cotto: ah, i see. so we want to POST to a trac url with JSON and see if trac does the right thing?
cotto: yeah, curl sounds good for that
cotto exactly 03:27
dalek kudo: 358d728 | pmichaud++ | src/core/metaops.pm:
Add meta-op forms of ?&, ?|, ?^, &&. Fixes RT #77864.
03:39
dukeleto cotto: how do you go about seeing if trac DTRT? 04:02
cotto: what does that exactly mean?
cotto add a revision, make sure that the wiki syntax for it works
s/revision/commit/ 04:03
I'll check the code to see what it's supposed to do when writing a full test case. 04:04
chromatic Wow, something really slowed down Rakudo in the past day. 05:00
plobsing any hunches? 05:02
chromatic I'm checking r49018 right now. 05:03
It wasn't the hash thawing or the Parrot_str_escape_truncate change.
05:12 rurban_ joined 05:15 rurban left, rurban_ is now known as rurban
chromatic Trying r49000 now. 05:26
plobsing the minimum hashtable size is now 2 in stead of 8. that would likely kill performance. 05:34
chromatic I tested r48970 and it's still slower there for some reason. 05:35
plobsing do you have a known good revision? 05:36
chromatic Looking for one.
05:41 cognominal left
chromatic Nothing stands out. 05:43
plobsing how are you sure it slowed down then?
chromatic Looking at timings of test runs. 05:44
dalek rrot: r49031 | plobsing++ | trunk/src/hash.c:
eliminate vestigial comment
05:45
plobsing the test suite is always growing. rakudo is a moving target as well. have you pinned those to a specific rev?
chromatic I'm using Parrot's test suite and have stuck with a Rakudo checkout from earlier today. 05:46
Parrot's test suite has been consistently between 23 - 26 seconds with a parallel coretest until today, and now it's somewhere between 40 and 60 seconds. 05:47
plobsing whoa
chromatic 36 now
Almost like I have debugging enabled or something. 05:49
Rakudo builds used to take about three minutes and now they're over six.
plobsing I thought that felt slower, but I dismissed it as impatience. 05:50
chromatic It's definitely slower. 05:52
Rakudo's startup is twice as long too. 05:54
05:55 contingencyplan left
chromatic I remember r49011 being pretty good. 05:56
The weirdness is that Callgrind profiling doesn't show anything. 05:57
plobsing cache locality issues?
chromatic Possibly.
plobsing can valgrind/callgrind help with that somehow?
chromatic Cachegrind does. 05:58
05:59 jan left
chromatic Lots of branch mispredictions. 06:00
20.5% indirect mispredictions.
plobsing is that high? I thought op-dispatch made that figure pretty high already? 06:01
06:02 Andy left
chromatic It's not too bad there. Lots of mispredicts in hashing for some reason. 06:03
06:05 uniejo joined
plobsing hash inlining changes? 06:06
tcurtis I noticed that PCT-based compiler REPLs don't support Unicode when Parrot was built with readline support. However, using rlwrap the give the REPLs readline support without Parrot having been built with readline does support Unicode. 06:09
chromatic Doesn't look like inlining 06:14
tcurtis Are the buffers of Parrot strings guaranteed to be null-terminated? 06:15
bacek_at_work tcurtis, no
tcurtis So, passing foo->strstart to functions expecting C strings is probably a bad idea? 06:16
NotFound tcurtis: readline is wrong, feel free to fix it.
And please, don't optimize it ;) 06:17
chromatic I do it for debugging, but don't check that in! 06:18
Lots of indirect branch mispredictions from memset. 06:19
plobsing memset has branch misprediction problems? woudn't libc make that one as fast as possible? 06:21
chromatic Could be Cachegrind's version. 06:22
plobsing you could probably get rid of all the memsets in src/hash.c they only zero uninitialized memory. 06:23
chromatic I did, but Rakudo seems to go into an infinite loop. 06:24
plobsing probably doesn't play nice with not walking the buckets explicitly 06:25
in gc
chromatic Right. 06:26
I'm out of brilliance for the night though.
IWBNI we had dukeleto's benchmarker running again.
Will resume looking again tomorrow. 06:27
06:33 chromatic left
tcurtis NotFound: I'm tempted, but I'm short on tuits currently, and that sounds tricky. 06:38
dukeleto thinks about the benchmarker some more 06:39
plobsing dreams of having an inexhaustable farm of servers to run smoke testing and benchmarking 06:41
NotFound tcurtis: is tricky if you want to care about possible wide chars encoding, just fixing the null terminating problem is easy.
plobsing: buy rackspace ;)
dukeleto plobsing: i dream of that too.
tcurtis NotFound: ah, yes, that should be simple. 06:42
dukeleto at least we have smolder back
tcurtis will do that.
NotFound tcurtis: just put a banner in parrot.org to accept donations
plobsing NotFound: my funds are quite exhaustable
NotFound "We want to buy rackspace. Please send us funds to do it" 06:43
cotto plobsing, I'll email you a quarter.
That'll work, right?
plobsing if you convince enough people to do it. I think we would crash any social graph if we had that many friends though. 06:44
06:45 esskar joined
tcurtis By the way, is mem_internal_free guaranteed to call free? 06:45
dukeleto mj41: tapir2 has a full disk 06:46
plobsing tcurtis: no. that's why it isn't just free().
NotFound plays Friends will be friends
tcurtis More stuff to fix in readline_interactive! :) 06:47
bacek ~~ 06:55
mj41 dukeleto: these blades has small hdds :-(, removing old coverage reports 07:00
bacek mj41, a-ha! Where is my git support in ttbot? 07:04
Your honeymoon should be over already :) 07:05
(And congratulations)
:)
mj41 bacek: Ahoj. I'm back at $work and busy a bit. But I have finally some free weekends. So Git support is on the way :-). 07:10
bacek mj41, hooray!
07:11 SingAlong left
mikehh bacek: BTW I nopasted some results from testing gc_masacre - nopaste.snit.ch/23367 07:13
bacek mikehh, thanks. They are kind of "expected failures" for now. GC MS2 doesn't fully implement statistics for such tests. 07:14
mikehh baceK: I can fix the codetest etc. failures if you like
bacek mikehh, yes, sure.
dukeleto mj41: i rm'ed a bunch of gigs
mj41: it was mostly me 07:15
07:18 tadzik joined
bacek Shit. 07:18
r49018 is totally wrong.
Our string are immutable. We can't change buffer behind it. 07:19
mj41 dukeleto: CPAN Reporter make 25G log file 07:20
dukeleto mj41: ooh boy 07:21
mj41 dukeleto: back to 42G (70%) of 63G avalilable 07:23
dukeleto aloha, msg chromatic i have my benchmark script working again, let me know what you need benchmarked
aloha dukeleto: OK. I'll deliver the message.
dukeleto aloha: yeah, i rm'ed my openembedded repo ;)
dalek rrot: r49032 | mikehh++ | branches/gc_massacre (22 files):
[gc_massacre] add svn properties and re-generate MANIFEST.SKIP
07:26
moritz dukeleto: fyi, I've managed a first smolder submission with the new system, now doing another test run before I push my changes
(submission for rakudo, that is)
07:28 he joined
bacek hmmm... May be it's not so wrong. 07:32
07:34 theory left
tcurtis Why does FileHandle.readline_interactive print the prompt to stderr? 07:34
dukeleto moritz: very cool!
purl very cool! is this one of those ultra slim ones?
cotto forget very cool! 07:35
purl cotto, I didn't have anything matching very cool
cotto sigh
dukeleto mj41: please check your private messages when you get a chance 07:36
dalek rrot: r49033 | tcurtis++ | trunk/src/pmc/filehandle.pmc:
Fix a potentially incorrect freeing in FileHandle's readline_interactive.

mem_internal_free is not necessarily libc's free.
07:43
07:55 tadzik left
dalek rrot: r49034 | bacek++ | branches/string_gc_split:
Branch for decoupling String GC from PMC GC.
08:00
dukeleto yay, bacek++ is back
dalek rrot: r49035 | mikehh++ | branches/gc_massacre/src/gc/gc_ms2.c:
[gc_massacre] fix codetest failures - add missing ASSERT_ARGS,

there should be at least one space between a C keyword and any subsequent open parenthesis (left c++ comments)
08:17
08:25 tcurtis left
dalek ast: 264f008 | KodiB++ | S02-builtin_data_types/key (3 files):
Additions, corrections, and reformatting for KeySet, KeyBag, and KeyWeight.
08:29
rrot: r49036 | fperrad++ | trunk/t/harness.pir:
[t] works with the new Parrot smolder server
08:34
rrot: r49037 | tcurtis++ | trunk/src/pmc/filehandle.pmc:
Use Parrot_str_to_cstring instead of strstart when passing prompt to functions
rrot: r49038 | dukeleto++ | trunk/t/native_pbc (3 files):
[t] Update native pbc for x86 64bit to make packfile tests pass
rrot: r49039 | bacek++ | branches/string_gc_split/src/gc/gc_private.h:
Add typedef for future string iterator callback.
08:51
rrot: r49040 | dukeleto++ | trunk/NEWS:
[doc] Update NEWS with Smolder info and a github URL
rrot: r49041 | bacek++ | branches/string_gc_split/src/gc/gc_ms.c:
Copy-paste logic for iterating live STRING/Buffer from compact_pool into gc_ms_iterate_live_strings.
rrot: r49042 | bacek++ | branches/string_gc_split/src/gc (2 files):
Add void* data for strings iterator.
rrot: r49043 | bacek++ | branches/string_gc_split/src/gc (2 files):
Switch compact_pool to use GC_Sys iterator over strings instead of direct poking into header pools
rrot: r49044 | bacek++ | branches/string_gc_split/src/gc (2 files):
Made move_header_callback static
rrot: r49045 | bacek++ | trunk/src/gc (3 files):
Merge branch 'string_gc'
rrot: r49046 | bacek++ | branches/string_gc_encapsulate:
Branch for encapsulating String GC as separate subsystem
cotto I remember this game. 09:00
09:01 orc joined
bacek cotto, which one? :) 09:06
09:06 orc left
cotto the one where you push a boatload of commits to svn and I wonder at your robot-like speed 09:07
bacek :)
dalek tracwiki: v4 | cotto++ | GitHubTracPluginTests 09:22
tracwiki: kinda flesh out the hook test
tracwiki: trac.parrot.org/parrot/wiki/GitHubT...ction=diff
szbalint cotto: "ŠÆ, робот". 09:24
bacek szbalint, "ŠÆ - робот" is little bit more correct :) 09:27
jnthn was slightly amused that the word for "worker" actually is "работник" :-)
Wonder if that and robot have similar origins. :-) 09:28
szbalint bacek: hehe, I copied it from wikipedia :)
bacek jnthn, it is, actually. 09:29
cotto That's what I recall from a previous random Wikipedia walk.
szbalint jnthn: in fact they do :)
cotto we have a consensus
jnthn Cute :-)
szbalint en.wikipedia.org/wiki/Robot#Etymology 09:30
dukeleto sent an email to parrot-dev with some benchmark info 09:36
let me know what benchmarks and branches people want to see
dukeleto gets some sleep
cotto good idea 09:37
09:46 elmex left 09:48 elmex joined
dalek kudo: cd151f6 | moritz++ | build/Makefile.in:
update spectest_smolder to new smolder.parrot.org server

see smolder.parrot.org/app/projects/smoke_reports/5 for the reports.
09:51
moritz purl: msg dukeleto github.com/rakudo/rakudo/commit/cd1...ef81b78551 works for me, let's see if it works for others too 09:53
purl Message for dukeleto stored.
10:19 tadzik joined 10:47 jsut joined 10:51 jsut_ left
dalek kudo: f11a044 | colomon++ | src/core/Range.pm:
Try to clean up Range.pick and Range.roll a bit.

Still not completely happy with these, but they work a bit better now...
10:52
kudo: 142ceba | colomon++ | t/spectest.data:
Add S32-list/roll.t to the list of spectests.
bacek msg chromatic After finishing painting your office, can you take a look at string_gc_encapsulate branch? It's almost finished. Just few last touches required. 10:59
purl Message for chromatic stored.
aloha OK. I'll deliver the message.
dalek ast: 091d652 | colomon++ | S02-builtin_data_types/range.t:
[t/spec] Unfudge three tests that work now.
11:00
rrot: r49047 | bacek++ | branches/string_gc_encapsulate (2 files):
Add empty file for future String GC
11:07
rrot: r49048 | bacek++ | branches/string_gc_encapsulate/src/gc (2 files):
Copy-paste string-related functions from gc_ms and make them public.
rrot: r49049 | bacek++ | branches/string_gc_encapsulate/src/gc/gc_private.h:
Remove unused gc_private pointer from Memory_Pools
rrot: r49050 | bacek++ | branches/string_gc_encapsulate/src/gc/gc_private.h:
Broke the build - split String_GC out of Memory_Pools.
rrot: r49051 | bacek++ | branches/string_gc_encapsulate/src (4 files):
Introduce Parrot_gc_str_compact_pool
rrot: r49052 | bacek++ | branches/string_gc_encapsulate/src/gc (2 files):
Use Parrot_str_gc_* functions instead of gc_ms_* for allocating string storage
rrot: r49053 | bacek++ | branches/string_gc_encapsulate/src/gc (3 files):
Implement Parrot_gc_str_free_buffer_storage for freeing allocated resources
rrot: r49054 | bacek++ | branches/string_gc_encapsulate/src/gc (5 files):
Shuffle functions around. Restore build and almost finish String GC encapsulting. Still some polish required
11:43 mikehh left 11:50 mikehh joined 11:51 bluescreen joined 11:59 whiteknight joined
whiteknight good morning, #parrot 12:00
I see that bacek has been on a magical robot coding adventure while I slept
there's nothing quite like reading a 30-chapter novel about the adventures of bacek in Google Reader 12:01
dalek rrot: r49055 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] refactor with get_value()
12:15
mikehh whiteknight: yes - we seriously missed bacek++ in the last month or so
dalek kudo: 705379c | masak++ | src/core/Instant.pm:
[core/Instant] added 'Real' role as per spec
12:17
whiteknight I just had a non-zero exit on t/library/archive_zip.t. Is anybody else seeing that? 12:26
Ah, failure comes because I didn't build Parrot with zlib 12:27
of course, it should fail more gracefully than that
dalek a: 50bc750 | fperrad++ | setup.pir:
works with the new Smolder server
12:39
12:45 Andy joined
whiteknight NotFound: ping 12:46
purl msg NotFound I saw a weird error today where finalize_p didn't look like it returned from an inner runloop. Take a look at r49057 when you get a chance. If you remove the "exit 0" from the end of the file, you'll see inner runloop weirdness 12:48
purl Message for notfound stored.
dalek rrot: r49056 | bacek++ | branches/string_gc_encapsulate/src/gc (3 files):
More split String GC allocations for buffers to be less dependend from Memory_Pools
12:49
rrot: r49057 | whiteknight++ | trunk/t/library/archive_zip.t:
t/library/archive_zip.t was failing with an unhandled exception if parrot is compiled without zlib support builtin. I added an exception handler and finalize_p to fail more gracefully, but that doesn't appear to have worked. I needed to add an exit_i to the end to force a graceful exit from the inner runloop.
12:50 betterworld joined 12:51 patspam joined 13:01 Andy left 13:04 cognominal joined 13:07 tadzik left
arnsholt Is there a fix to the "Configure.pl --gen-parrot doesn't actually gen-parrot" issue? 13:08
I've encountered it with Rakudo a few times, as well as with my own project, and it's a bit annoying
moritz in what way did it not generate a parrot? 13:09
arnsholt It configures Parrot, and then for some reason doesn't run make
moritz that's weird.
no further error message? 13:10
arnsholt Nope. I get the "You can now use `make' to build your Parrot" message, followed by "Building Parrot ..." and then no building and "Reading configuration information from parrot_install/..." 13:11
13:12 rurban_ joined 13:15 rurban left, rurban_ is now known as rurban 13:18 Patterner left
dalek rrot: r49058 | bacek++ | branches/string_gc_encapsulate/src/gc/gc_ms.c:
[cage] Add documentation.
13:23
NotFound whiteknight: ping 13:25
13:27 he left 13:28 Psyche^ joined, Psyche^ is now known as Patterner
NotFound msg whiteknight finalize must be used before pop_eh, it needs the information from its context 13:31
purl Message for whiteknight stored.
aloha OK. I'll deliver the message.
NotFound Ups
I was using "/msg" X-)
whiteknight Ah, thanks 13:33
let me give that a try
works. 13:34
NotFound Good 13:35
dalek rrot: r49059 | whiteknight++ | trunk/t/library/archive_zip.t:
Put finalize_p before pop_eh, on suggestion from NotFound++. Works perfectly.
13:40
NotFound It was not a suggestion. It was an order! ;) 13:41
13:44 contingencyplan joined 13:46 cotto left
dalek rrot: r49060 | bacek++ | branches/string_gc_encapsulate/src/gc (3 files):
Move mem_allocate function into string_gc.c and made static. It's not used anywhere else
13:57
rrot: r49061 | bacek++ | branches/string_gc_encapsulate/src/gc (4 files):
Move String GC related functions from alloc_resources into string_gc
rrot: r49062 | bacek++ | branches/string_gc_encapsulate/src/gc/alloc_resources.c:
Remove leftover function
bacek ookey 13:59
make test passed in string_gc_encapsulate branch
And it's tomorrow already.
moderator smoke string_gc_encapsulate branch | Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets; remove deprecated items (especially CodeString); record deprecations; polish for 2.8 release 14:00
bacek If no one will complain I'll merge string_gc_encapsulate into trunk tomorrow morning. And then into gc_massacre. 14:01
Good night, humans
14:15 uniejo left
dalek TT #1792 created by rg++: return inside void function in integer.pmc breaks build on solaris 14:32
TT #1792: trac.parrot.org/parrot/ticket/1792
rrot: r49063 | NotFound++ | trunk/src/pmc/integer.pmc:
Don't use return in void functions, TT #1792, rg++
14:49
TT #1792 closed by NotFound++: return inside void function in integer.pmc breaks build on solaris
TT #1792: trac.parrot.org/parrot/ticket/1792
whiteknight every time I get a bluescreen on WinXP, I could scream until my eyes bleed 15:11
NotFound whiteknight: there is a simple solution for that.
A registry key that change the background color.
bluescreen or a more drastic approach - changing the OS 15:12
15:13 AzureSto_ joined
NotFound I mention this one first to avoid being called zealot X-) 15:14
15:16 AzureStone left
whiteknight it's my work computer. I can't change the OS on it or IT might kill me 15:19
at home, I use a stable OS 15:20
NotFound whiteknight: MSX? 15:21
whiteknight MSX?
NotFound I mean, MSX_DOS
dalek nxed: r657 | NotFound++ | trunk/winxedst1.winxed:
closures in stage 1, first version, poorly tested
15:22
NotFound en.wikipedia.org/wiki/MSX-DOS
The more stable OS that I know. Years and years without fixes. 15:23
15:28 tadzik joined, nwellnhof joined 15:38 AzureSto_ left 15:45 AzureStone joined 15:49 tadzik left 15:57 AzureSto_ joined
dalek rrot: r49064 | mikehh++ | branches/string_gc_encapsulate/MANIFEST:
re-generate MANIFEST
15:58
15:59 theory joined 16:00 AzureStone left 16:12 tadzik joined 16:16 chromatic joined 16:17 Andy joined 16:32 nwellnhof left 16:33 ruoso joined
dalek rrot: r49065 | mikehh++ | branches/string_gc_encapsulate/src/gc/string_gc.c:
[string_gc_encapsulate] fix some codetest failures - add svn properties
16:33
16:37 dip left 16:45 dngor_ is now known as dngor
whiteknight I'm running that branch through the wringer, and it's looking A-OK 16:50
gcc, g++, clang and icc, all with and without --optimize pass on Ubuntu 10.04 x86 16:51
I'm going to run most of the same battery tonight on x86_64, but I don't expect any problems.
17:02 AzureSto_ left 17:15 davidfetter joined 17:32 AzureStone joined
nopaste "luben" at 192.168.1.3 pasted "updated hash stats, plobsing++" (13 lines) at nopaste.snit.ch/23390 17:46
chromatic Halved our hash usage. 17:48
whiteknight fantastic 17:49
absolutely wonderful improvement
davidfetter kudos! 17:50
chromatic Should cut down on Rakudo memory usage too.
dukeleto ponders about memory benchmarks... 17:59
dalek TT #1793 created by pmichaud++: FileHandles do not properly transcode strings 18:00
TT #1793: trac.parrot.org/parrot/ticket/1793
tadzik that's since the last release? 18:01
chromatic in the last week 18:03
tadzik oh, nice 18:09
(Parrot team)++
dalek rrot: r49066 | fperrad++ | trunk/t/library/archive_zip.t:
[t] refactor with skip_all (missing part of r48955)
18:33
chromatic grr, git-bisect is misbehaving with git-svn. 18:38
NotFound pmichaud: ping 18:39
pmichaud: forget it, someone already commented my issue in the ticket.
purl NotFound, I didn't have anything matching it, someone already commented my issue in the ticket
18:54 jan joined
pmichaud NotFound: oops, glad you folks noticed my think-o. Thanks. 19:10
chromatic I haven't been able to bisect any slowdown in the past week. Other takers welcome. 19:20
plobsing dukeleto: do you have docs anywhere on how you use bin/bench?
dukeleto plobsing: i sent an email to p5p about it. one sec 19:39
plobsing: it is part of euler_bench 19:40
plobsing: github.com/notbenh/euler_bench
plobsing: i am using the leto-report branch, which makes the output the way I like it :) 19:41
plobsing: www.nntp.perl.org/group/perl.perl5....52921.html 19:43
dalek nxed: r658 | NotFound++ | trunk/winxedst1.winxed:
createsubid was not propagated from class and namespace, fixed
19:49
19:50 bluescreen left
dalek kudo: 760c734 | pmichaud++ | src/cheats/process.pm:
Set default filehandles to unicode encoding. Resolves RT #77888.
19:56
chromatic Why does Parrot_str_from_int() reimplement strtoul?
whiteknight I'm not looking at the code, but I assume that strtoul doesn't do what we need 19:57
some platforms define INTVAL as long long, which strtoul definitely doesn't support
(we could use macros, of course. I have no excuse for why we wouldn't)
chromatic Suppose we tried strtoul first, then checked errno for overflow, and only then used the naive, slow version. 19:58
whiteknight we know at compile time whether strtoul will work or not
or, whether it will work universally
but yes, I do agree that a naive, slow, home-brew implementation should not be the first choice 19:59
plobsing strtoul does the opposite of Parrot_str_from_int
whiteknight itoa?
chromatic I meant Parrot_str_to_int, sorry. 20:00
Or whatever... looking at these functions bugs me.
NotFound If I remember well, because of naive versions using strtoul were buggy. 20:01
dalek TT #1793 closed by pmichaud++: FileHandles do not properly transcode strings
TT #1793: trac.parrot.org/parrot/ticket/1793
NotFound Uh, no, I was mixing things. 20:06
I think it was that strtoul is unable to handle the number of digits required for floating point numbers. 20:07
20:07 whiteknight left
NotFound Or maybe that was Parrot_str_num 20:10
In short: no idea %-)
20:11 AzureSto_ joined 20:12 cotto joined
chromatic It's worth trying; dividing and modulus operations take up 25% of the stress_strings benchmark. 20:12
20:13 AzureStone left
bacek ~~ 20:13
strtoul can't handle unicode strings
20:14 AzureStone joined
NotFound Looks like that function were copypasted from Parrot_str_to_num and never cleaned enough well. 20:14
chromatic Neither can Parrot_str_from_int(), if I read it correctly.
... and it's very, very wrong for non-ASCII.
NotFound The pod says that it accepts decimals and exponents, and the function doesn't. 20:15
plobsing whats this? the docs lie? impossible! 20:16
NotFound Incoceivable!
dalek ast: fd2da7e | pmichaud++ | S03-operators/short-circuit.t:
Fudge a failing test in short-circuit.t exposed by Parrot Boolean/Integer changes.
20:17
NotFound Well, I don't think that stress_strings should be so heavily based on string to int conversions. 20:18
20:18 AzureSto_ left
chromatic True. 20:18
NotFound It's more noise than signal
chromatic It's 40% of execution time. 20:20
NotFound Dividing and modulus? That functions does multiplications
plobsing chromatic: yes, but if you look at the biggest changes in costs since 2.7.0, compact_pool appears to be the culprit 20:21
chromatic Yeah, I'm looking at the callback pointer there.
NotFound The div and mose it uses are evaluated at compile time... or it should.
s/mose/mod
20:21 tadzik left
plobsing stress_strings regression goes back at least as far as r48800 20:24
chromatic gc_ms_iterate_live_strings is awful, performance wise. 20:25
I have a 5.45 - 6.26% performance improvement on the benchmark by inlining some of the guard clauses. 20:27
cotto ~~ 20:31
chromatic Hm. Everything on my machine runs at half speed today. Maybe it's not Parrot.
Rakudo uses 25% less memory than it did with Rakudo Star. 20:32
That hash effort paid off. 20:33
Let's try this commit. 20:36
sorear \\o/
luben good evening world 20:37
now, as we have non-significant number of empty hashes I will revert a premature optimization (lazy allocation of hash space and compare the speed) 20:38
20:39 chromatic left
bacek aloha 20:39
any objections on merging string_gc_encapsulate branch? 20:40
NotFound If we are going to do it before the release, do it rigth now. 20:41
bacek testing merge now 20:43
20:45 chromatic joined
bacek done 20:47
chromatic Merge successful? 20:48
bacek of course
afk # breakfast :) 20:49
chromatic I like branches that work so well.
pmichaud note that Rakudo is currently failing a lot of tests in parrot trunk.
I'm waiting for the latest spectest run to finish.
gist.github.com/583142 # rakudo spectests on r49066 20:51
dalek rrot: r49067 | chromatic++ | trunk/src/gc/gc_ms.c:
[GC] Optimized gc_ms_iterate_live_strings().

callback to before calling the callback, the stress_strings.pir benchmark runs
  ~6% faster and the callback gets called less than 10% of the time as before.
This appears to improve Rakudo's performance by about a percent as well. We can live with this ugliness until someone either tries to make this function more general (but please don't do that) or we get a better GC (so please help with gc_massacre and the like). Also the moral of the story is "Don't write C as if it were C++ and expect a
  compiler which can't optimize across function pointer calls or source files to
generate fast code."
rrot: r49068 | bacek++ | branches/string_gc_encapsulate/src/gc/gc_ms.c:
[cage] Add ASSERT_ARGS macros
rrot: r49069 | bacek++ | trunk (7 files):
Merge branch 'string_gc'
rrot: r49070 | bacek++ | trunk/src/gc/string_gc.c:
Remove public version of alloc_new_block. It's not used outside of String GC
atrodo chromatic> nice commit message
chromatic I hope it's helpful. 20:53
pmichaud I can run spectests against r49070
nopaste "NotFound" at 192.168.1.3 pasted "refactor Parrot_str_to_int" (90 lines) at nopaste.snit.ch/23394
chromatic That's cleaner. 20:54
Is there any way we can try the libc functions first, when appropriate? 20:55
NotFound chromatic: I think it will need costly checks and conversions. 20:56
chromatic Seems worth a benchmark at least. 20:57
NotFound chromatic: Testing and benchmarking in all potentially conflictive platforms and configure options is not easy. 20:58
chromatic: And it will need a call to Parrot_str_to_cstring anyway, I seriously doubt it pays. 21:01
chromatic Maybe so. 21:06
Still, look at Parrot_string_from_uint.
For base ten, why do anything other than sprintf?
bacek btw, free karma for someone with svn checkout for removing string_gc_* branches 21:10
NotFound Mmm... that function is called used from Parrot_str_from_int and from spf_render.c 21:12
21:14 rurban_ joined 21:16 whiteknight joined 21:17 rurban left, rurban_ is now known as rurban
plobsing I've managed to narrow the stress_strings performance regression to 48559:48600 21:20
NotFound Uh, that patch was wrong, iter_get_and_advance can return random garbage after the end of the string. 21:22
21:25 jdv79 left 21:26 patspam left, patspam joined
pmichaud Rakudo spectest failures against r49070: gist.github.com/583221 21:39
I'll help narrow down the issues a bit after helping with kid homework and dinner
looks like unicode and/or icu related issues 21:40
chromatic Maybe r48933, but you had a clean run since then. 21:42
plobsing, I rebooted after an upgrade and wallclock times are back to normal. Weirdest thing. 21:43
21:43 Khisanth left
NotFound Maybe you need a new wallclock. 21:48
pmichaud looks like the problem may be that some strings are losing track of their encoding 21:49
21:50 bluescreen joined
plobsing chromatic: OK, I'll stop chasing wild geese then. 21:50
pmichaud I'm guessing that hash keys aren't remembering their encoding. 21:53
But let me see if I can confirm that. 21:54
NotFound total_length += total_length >> 1; ??? 21:55
Is not the weirdest thing I have seen, but...
dalek a: 0108744 | fperrad++ | dynext/pmc/luaany.pmc:
logical VTABLES are gone, see trac.parrot.org/parrot/changeset/49012
21:56
ast: 14f0e95 | KodiB++ | S02-builtin_data_types/instants-and-durations.t:
Unfudged a test of now being a term.
21:57
ast: a41a669 | KodiB++ | S32-temporal/DateTime-Instant-Duration.t:
Fixed fouled-up fudge syntax.
21:59 perlite left 22:00 perlite joined
bluescreen Guys, need some guidance... Is there any way to make ".return" to work over nested closures ? basically from a method I call a closure and I want to return from the method if the closure has an explicit return 22:00
pmichaud bluescreen: rakudo and nqp currently do this using exceptions. 22:01
i.e., the nested closure throws an exception that is caught by the outer routine 22:02
bluescreen is that a best practice or some magic?
NotFound You can also pass continuation
pmichaud the only other way I know to do it is for the nested closure to be able to look up the return continuation of the outer method and invoke it
dalek ast: e0d9631 | KodiB++ | S02-builtin_data_types/instants-and-durations.t:
[instants-and-durations.t] Use .perl so as not to require great accuracy from .Str.
NotFound And invoke it instead of returning
pmichaud (or for the outer method to store a continuation somewhere that the nested closure can invoke) 22:03
bluescreen how well tested continuations are?
NotFound "is that a best practice or some magic?" What's the difference?
bluescreen best practice has the "you should do it this way" implied 22:04
magic is divine inspiration
NotFound Then is magic. We don't tell how you should do things. 22:05
bluescreen NotFound: Com'on everybody loves best practices 22:06
dalek kudo: aa5896d | KodiB++ | t/spectest.data:
[spectest.data] Added tests for Instants and Durations.
kudo: 529f546 | KodiB++ | src/core/ (2 files):
Made Instant.Str more awesome per RT #77802.
kudo: 3ae665f | KodiB++ | src/core/Duration.pm:
Removed &infix:<->(Real, Duration).

It competed with &infix:<->(Instant, Real).
NotFound bluescreen: you know the mottto "There's more than one way to do it"?
bluescreen yeah... tough it takes some time till once gets used to 22:07
s/once/one
NotFound Continuations in parrot are tested heavily. sub calls are continuations. returns are continuations... 22:08
exception handlers are continuations...
closures are continuations...
bluescreen that's good to know, you see. there was a best practice after all 22:09
NotFound That implies that rakudo is not doing the best? ;) 22:10
bluescreen I'm sure rakudo has its motives 22:11
22:11 mikehh left 22:12 ruoso left
pmichaud parrot internal continuations may be well-tested; creating your own continuations and using them is much less well tested. 22:12
it's also the case that Perl 6 allows for returns to be caught by exception handlers, which more naturally leads to an exception-based model. 22:13
NotFound pmichaud: if I read well the docs, a closure is your own continuation plus a lex capture. 22:14
pmichaud NotFound: that's not at all what I think of as being a closure.
NotFound pmichaud: I mean how it's implemented.
pmichaud even in implementation 22:15
NotFound Oh, yes, I was mixing ideas again...
The effort of understanding closures enough to make them work in wixed has been demanding %-) 22:17
bluescreen NotFound: I'd say that solving closure and scope is the greatest deal of an HLL 22:22
NotFound bluescreen: I'm used mainly to languages without closures, but certainly they are very useful. 22:23
pmichaud the unicode-related issue seems to be related to short unicode strings having the final bytes chopped off 22:24
bluescreen well Java survived many years without'em 22:25
pmichaud there seems to be an eight-byte boundary
NotFound pmichaud: uhh... maybe someone mixed byte length and char length?
pmichaud: utf8? 22:26
purl somebody said utf8 was telling perl teh source code is utf8
pmichaud yes, utf8 22:27
gist.github.com/583284 # example
if the variable identifier is long enough, then things seem to work okay.
but if it gets short, then one of the internal symbols confuses byte length with char length 22:28
and it seems to stop working when the byte length goes below 8
NotFound pmichaud: Do you know at wich r started to happen?
pmichaud NotFound: not yet.
haven't had a chance to bisect yet. 22:29
NotFound Let me try to reproduce it with some short pir...
22:32 mikehh joined
dalek rrot: r49071 | NotFound++ | trunk/src/string/api.c:
shorter and cleaner, even if a bit tricky, implementation of Parrot_str_to_int
22:34
NotFound I've tried using as a key in a hash and storing and retriveving in a namespace, and can't reproduce the problem. 22:39
22:40 Khisanth joined
pmichaud yes, I don't think it's hash-related at the moment. 22:53
I'm starting a bisect
dalek nxed: r659 | NotFound++ | trunk/winxedst1.winxed:
store scope in function parameters, fixs its detection as candidates for
23:00
purl lexicals are destroyed in the proper order
23:02 Paul_the_Greek joined
Paul_the_Greek Hey there, folks. 23:02
luben Hi Paul_the_Greek 23:04
Paul_the_Greek Howdy, luben.
NotFound is scary seen casts from pointer to unsigned long to pointer 23:10
sorear should be INTVAL 23:12
IV/INTVAL's main reason for existing is to be a C89-compatible intptr_t, if I understand #p5p correctly
NotFound sorear: I don't know if we've decided to make such a grant explicit. If not, we probably should, is implicit in a lot of places. 23:14
chromatic I'm not comfortable in assuming that the user-visible uses of INTVALs should imply anything about pointers. 23:16
... nor that the probed sizes of INTVAL are necessarily equivalent to the probed sizes of pointers.
NotFound chromatic: the codebase assumes in several places that an INTVAL can contain a pointer. 23:18
23:19 patspam left
chromatic We should fix them. 23:19
sorear What *should* parrot use in place of intptr_t? 23:21
chromatic I don't know. 23:23
I hesitate to call it INTVAL because that may be confusing.
NotFound There is a nice note in parrot.h saying that we should have "UINTPTR or something like that" 23:30
chromatic Even INTPTR is better than INTVAL.
NotFound Well, INTVAL at least exists ;) 23:31
chromatic True.
23:35 elmex_ joined 23:38 elmex left, elmex_ is now known as elmex
Paul_the_Greek Isn't there something like PTR2INTVAL? 23:41
dalek rrot: r49072 | mikehh++ | trunk/src/gc/alloc_resources.c:
fix codetest failure - tidy up pod syntax
23:42
rrot: r49073 | mikehh++ | trunk/src/gc (2 files):
fix missing assert_args - re-ran make headerizer
Paul_the_Greek Yes, there is. It's used about half a dozen times.
23:44 Andy left
NotFound Paul_the_Greek: yes, the comment I mentioned is located where that macros are defined. 23:44
Paul_the_Greek PTR2UINTVAL is used about a dozen times. 23:45
whiteknight hate
Paul_the_Greek Why is there even the concept of casting a pointer to a signed integer? 23:46
NotFound Paul_the_Greek: they were used, and probably still are, to pass pointer to pir registers, to later be used in some ops. 23:47
Paul_the_Greek What's the right way to cast a pointer to an unsigned integer for other purposes? 23:48
NotFound Paul_the_Greek: there is no rigth way, that's the problem.
Paul_the_Greek Doesn't C have ptrint_t or some such? Ah, but maybe not in C89. 23:49
NotFound Paul_the_Greek: recent versions of the standard introuced ways, but we support old compilers.
Paul_the_Greek We can't blow off those old compilers so I can use // comments? :D
There's some hackery in parrot.h to compare the sizes of pointers and integers. 23:50
NotFound Paul_the_Greek: we can introduce our own preprocesor, adding yet another more nice level of complexity to our build process ;)
Paul_the_Greek In there some way to enhance that to do the right thing? 23:51
In particular, it could simply not define INTVAL2PTR if integers are larger than pointers. 23:52
NotFound Paul_the_Greek: sure, but someone have to develop it and to make sure it's appropiate for a lot of platforms.
Paul_the_Greek Do we trust PTR_SIZE and INTVAL_SIZE? 23:53
NotFound Paul_the_Greek: and the parrot simply will not compile.
Paul_the_Greek Right. If Parrot depends on converting a 64-bit integer to a 32-bit pointer, something's amiss.
The xxx_SIZE guys are set up by configure. I presume we can trust them. 23:54
NotFound Anyway, is not a good moment to think about ways of breaking parrot, better wait to the release. 23:55
Paul_the_Greek Okay, I'll trash it later on.
Question, though: Where are INTVAL et all defined?
s/et all/et al/ 23:56
NotFound Paul_the_Greek: the configure stage does it.
Paul_the_Greek I can't find a #define for it. 23:57
NotFound include/parrot/config.h
23:58 mikehh_ joined
Paul_the_Greek Oh, it's a typedef. Uppercase typedef. 23:59
Should I use Parrot_Int or INTVAL?