Parrot 2.3.0 will be released at 2010-04-20 10:00 UTC | parrot.org/ | Channel log: irclog.perlgeek.de/parrot/today | Priority: documentation sprint and pre-release testing for 2.3, fix line number annotations | Review and vote GSoC applications
Set by moderator on 18 April 2010.
00:00 allison joined
chromatic ... but I'm not holding my breath for that. 00:00
Whiteknight thanks chromatic! you're the bestest!!! 00:03
it seems my gratitude was so moving and so sincere that chromatic had to sign off and weep privately 00:08
Infinoid heh. so moving he fell off the internet :) 00:09
Whiteknight ...and before I do any more good, I'm signing off for the night 00:11
goodnight
GeJ clock? 00:12
purl GeJ: LAX: Sun 5:12pm PDT / CHI: Sun 7:12pm CDT / NYC: Sun 8:12pm EDT / LON: Mon 1:12am BST / BER: Mon 2:12am CEST / IND: Mon 5:42am IST / TOK: Mon 9:12am JST / SYD: Mon 10:12am EST /
00:18 theory joined
japhb allison, ping 00:22
allison japhb: pong 00:23
japhb Will you have a chance to look at my grant proposal draft before #ps? I know 2.3 is probably eating your time .... 00:24
allison I started to look it over and got sucked away 00:25
will finish up now...
japhb ah
thanks!
Any comments appreciated, because I will use this one as a template for any future proposals .... 00:26
allison japhb: it's a good modular task, and seems completable in the time suggested 00:32
japhb Well, that's a good start. :-)
allison japhb: (typing out responses as I go) 00:33
japhb np[
allison japhb: you did a good job of illustrating why this feature is architecturally pervasive, why it has a broad impact on the system. But, the question I was left with "Is this the single most important task to complete next in order to ship Plumage" 00:34
00:35 preflex joined
japhb Ah, good point. 00:35
allison japhb: that could be worked into the text
japhb Perhaps it would help to put in a brief section about what other major tasks I think there are.
I had roughed out plans for 3-4 grant projects of similar size. 00:36
Putting this one in the context of the others seems useful.
allison japhb: also, if there is a C++ MiniSat implementation available which could be linked in via NCI as a fallback, would it not do as an initial prototype?
japhb: yes, the context is helpful 00:37
japhb: (back to MiniSat) especially since there are questions whether NQP is the best language for the task given speed questions
japhb Hmmm. Yes, I could reverse the priority order of the two ... I had been doing NQP plan first in order to reduce the number of native libraries I needed for a base Plumage. 00:38
But if you have no objection, then neither do I ... 00:39
allison japhb: yes, that is a good goal, since we've been avoiding dependencies from Parrot as much as possible
japhb: but, I'm also keeping in mind the duplication of effort
japhb nod
00:41 Mokurai1 left 00:42 cosimo joined
allison japhb: and I do think using SAT solvers for package dependencies is an excellent idea 00:42
japhb :-)
allison japhb: (curiously, I am right now in the middle of an assignment demonstrating that if 3SAT were reducible to a unary language, then P = NP) 00:43
japhb: (a bit of a waste, considering it's highly unlikely that P = NP, but an interesting problem anyway) 00:44
japhb Amazing how often these coincidences happen ...
allison japhb: those were all the comments I had on the proposal, happy to have the board look at it
japhb OK, great. I'll work on the two major edits (switch to C++ MiniSat as primary method, and add section discussing context of other Plumage work), and then send it to you for the board to look at. 00:46
Thanks for reviewing the draft, allison!
00:52 lucian joined
allison jabphb: great! glad to help 00:54
01:13 elmex joined 01:18 Mokurai joined 01:20 Mokurai1 joined 01:21 eternaleye joined
kid51 make fulltest PASS linux/i386 f45789 01:24
01:27 plobsing joined 01:57 abqar joined 02:16 Andy joined 02:21 cosimo joined 02:42 janus joined 03:07 kurahaupo joined 03:29 Andy joined 03:38 allison joined
GeJ make fulltest PASS FreeBSD/amd64 trunk @r45789 03:56
Andy g++ 4.5.0 is more fussy about pointer conversions 04:11
so now t/src/extend.t is failing.
GeJ did anyone try to build Parrot with clang? 04:12
sorear I have clang and parrot, I'll try if someone gives me documentation on how 04:21
last time I tried to build a nontrivial project with clang, clang tried to parse the GNU libstdc++ headers and failed horribly 04:22
Andy I haven't actually installed clang before 04:26
But I want to 04:27
because I like compilers
and their warnings
GeJ I have no previous experience with clang whatsoever. I just read a post this week-end saying that people successfully built FreeBSD with it. 04:28
It got me wondering if someone ever tried to build Parrot. 04:29
Okay. Let's build llvm and see how it goes. 04:31
sorear iirc freebsd is trying to move the base system from gcc to clang anyway, so it's not terribly suprising they've made it work 04:40
04:41 JimmyZ joined
JimmyZ make fulltest failed on windows XP with strawberry perl with --optimize 04:42
Test Summary Report
-------------------
t/pmc/eval.t (Wstat: 512 Tests: 17 Failed: 2)
Failed tests: 10, 12
bacek_at_work wow. All test passed trunk + clang on Debian/testing 04:48
GeJ sorear: GPLv3 problem. FreeBSD is stuck with gcc 4.2 as the base compiler. LLVM/clang licencing fits better FreeBSD (and other *BSDs I suspect) distribution system. 04:59
04:59 rurban_ joined
dalek rrot: r45790 | petdance++ | trunk/t/src/embed.t:
properly consting argv
 05:44
05:45 aukjan joined 05:50 davidfetter joined 05:56 uniejo joined 06:00 allison joined
dalek rrot: r45791 | petdance++ | trunk (9 files):
correcting all the argv to be "const char **argv"
 06:00
rrot: r45792 | petdance++ | trunk/t/src/warnings.t:
fix decaration of argv
rrot: r45793 | petdance++ | trunk/src/gc/alloc_resources.c:
shut down warning on unused interp
sorear attempting to build parrot with clang almost worked 06:03
it got to the very end, then linking libparrot.so failed because src/pmc/bigint.o and src/pmc/bignum.o define a lot of the same symbols starting with __gmp[nqz]_ 06:05
ttbot Parrot trunk/ r45794 i386-linux-thread-multi make error tt.taptinder.org/file/cmdout/269620.txt ( tt.taptinder.org//buildstatus/pr-Pa.../rp-trunk/ ) 06:10
dalek rrot: r45794 | petdance++ | trunk/src/thread.c:
removed unused interp args from static functions
 06:17
szabgab NotFound, so I was told I need to try to convince you to create an Android port of Parrot ? I added a request to the "android-scripting" thing code.google.com/p/android-scripting...ail?id=296 and many people upvoted it already but I guess it will be much faster if you could help them out 06:31
06:32 iblechbot joined
dalek rrot: r45795 | petdance++ | trunk/src/thread.c:
restored interps to a couple of functions that actually need them
 06:33
06:37 chromatic joined
chromatic I keep intending to ask Chris Dibona at Google for some Nexus One hardware. 06:42
szabgab we are going to have a "Perl on Android" talk on the 28th in Haifa in the offices of Qualcomm 06:56
and as I understand they are quite involved in Android too
it would be awesome to show Perl 6 running on Android as well
chromatic If we could get some kit, it should be possible to bring it up. 06:57
szabgab I am mostly using the emulator
it is much more convenient than a real device 06:58
treed Are there any Android devices that are actually open, dev-wise? 06:59
ISTR that some of the bigger ones did not permit you enough freedom to actually muck around with the internals.
szabgab as I understand there are 2
treed Just the G1 was open, I'd heard, and you couldn't use the marketplace because of it.
Which is just... really?
szabgab see "dev phones" developer.android.com/index.html
treed Makes me sad.
chromatic I thought you could use the G1 Dev phone with the marketplace. 07:05
07:06 fperrad joined
szabgab I have an archos 5 that does not have marketplace out of the box but there is an app floating around that allows you to add the marketplace, maybe there is one for G1 Dev as well ? 07:08
treed chromatic: My understanding was that they didn't want to permit it because having root meant that you could break their DRM and pirate apps. 07:11
Or maybe you can have the marketplace, but not any paid apps.
chromatic That may be. I remember hearing something about dev phones being able to subvert the payment mechanism. 07:14
szabgab you know the interesting thing I found is that some of the bugs reported against the perl on Android are fixed by Jarkko 07:18
treed does perl on the android have access to the UI libraries?
szabgab it can create some limited dialogs 07:19
so far that's what I found
treed I'd love to be able to do full apps on android.
But I don't want to do it in Java.
I had hopes for running macruby on the iphone, but the new provision does away with any chances of that. 07:20
szabgab I believe the more people ask for perl related things on the android-scripting list the more chance we have for improves support
treed Assholes.
purl assholes is at www.gopostal.net/GoPostal.html or at www.whitehouse.gov or at www.mastercard.com or at www.manpages.com/ or www.whitehouse.com or no longer at goatse.cx or at www.bezeqint.net or at www.netvision.net.il
szabgab so I opened some 10 tickets 07:21
and Parrot is currently the most requested new feature
treed Heh. 07:22
searching for perl on android
blogs.perl.org/users/gabor_szabo/20...droid.html
Go figure. :-P
07:24 fperrad_ joined
treed bedtime 07:25
kurahaupo q 07:44
07:54 allison joined
dalek rrot: r45796 | mikehh++ | trunk/src/parrot_debugger.c:
fix codetest failure - change function documentation to reflect consting
 07:54
08:06 muixirt joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33280), fulltest) at r45796 - Ubuntu 10.04 beta i386 (g++ with --optimize) 08:09
muixirt good morning
purl Good Morning Mr Rogers
mikehh hi
muixirt there is a memory leak in parrot 08:10
are there issues again with the gc 08:11
?
nopaste "muixirt" at 192.168.1.3 pasted "memory leak" (8 lines) at nopaste.snit.ch/20302 08:13
moritz do we have any such high level tests in the test suite? 08:14
mikehh probably not - there are a lot of areas missing tests - more tests are always welcome 08:16
moritz do we have portable means to obtain the memory usage of a parrot interpreter? 08:17
chromatic That's not a leak. 08:19
muixirt chromatic: why not?
chromatic It grows way too slowly to be a leak.
I've had it running for 2.5 minutes and it's using 158 MB RSS. 08:20
moritz so... fragmentation?
muixirt chromatic: it does bad things to rakudo
mikehh when would it invoke the gc
chromatic There's no upper bound on the GC. 08:21
There should be, but we don't have one.
08:21 iblechbot joined
mikehh I thought you were looking at cases when it got above a certain limit it would invoke 08:21
chromatic Yes, we've had that for several weeks now. 08:22
With a million iterations, Valgrind says: ==516== All heap blocks were freed -- no leaks are possible 08:23
With ten million iterations, Valgrind says: ==546== All heap blocks were freed -- no leaks are possible 08:25
After the 2.3 release, I'll look at the GC threshold to see if we can find a better tuning. 08:26
mikehh switching to amd64 - bbiab 08:27
mikehh well I was going to - need to check something first 08:29
08:29 gerd joined
muixirt chromatic: so what would be the correct wording for that issue? 08:30
chromatic GC tuning request. 08:31
muixirt noted
chromatic It's definitely related to something in the threshold code though. I disabled it and the GC runs a lot more often, but there's no memory growth. 08:36
nopaste "muixirt" at 192.168.1.3 pasted "GC tuning request" (8 lines) at nopaste.snit.ch/20303 08:39
08:41 fperrad joined 08:44 clinton joined
chromatic Informed guess: the growth in memory is from the memory overhead of allocating new pools. 08:56
nopaste "chromatic" at 192.168.1.3 pasted "muixirt: GC tuning patch to test with Rakudo" (13 lines) at nopaste.snit.ch/20304 09:00
dalek rrot: r45797 | gerd++ | trunk/NEWS:
add this important news for HLL developers
kudo: a8e70ac | moritz++ | build/ (2 files):
bump PARROT_REVISION, and change config_lib from .pasm to .pir

  trac.parrot.org/parrot/ticket/1560		 09:06
chromatic ... except that tuning patch ruins performance. 09:10
muixirt chromatic: well it eats up memory more slowly 09:12
chromatic My recommendation: figure out which parts of NQP churn through so many PMCs and possibly STRINGs and fix that. 09:13
I can make Rakudo build really quickly if you have lots of memory. 09:14
I can make Rakudo build in a little bit of memory if you have lots of time.
muixirt chromatic: so it's only a little step to combine that... 09:15
chromatic If you want Rakudo to build quickly and not use lots of memory, someone who is not me will have to profile and tune NQP.
bacek and allison and I will fix the compact_pool shenanigans and continue to tune and adapt Parrot's GC. 09:16
muixirt do you mean NQP itself (as a parrot component) or the NQP scripts in the rakudo repo?
chromatic Probably NQP itself, though perhaps Rakudo's NQP programs. 09:17
muixirt i hope any rakudo dev read what chromatic wrote :-)
chromatic moritz and pmichaud are usually good about that.
I have one more idea I will try in the morning. 09:18
moritz never profiled anything NQPish successfully
chromatic In my experience, it's figuring out what gets called a lot, and then seeing if you can delay the creation/allocation of a resource until it's necessary. 09:19
Lazy error reporting can help a lot. 09:20
muixirt so where is NQP currently developed, in the parrot repo or at github? 09:21
chromatic Github, I think. 09:22
moritz github.com/perl6/nqp-rx 09:27
muixirt and pmichaud updates the parrot repo every now and then? 09:28
moritz yes
09:36 mikehh joined 09:42 allison joined 09:47 riffraff joined
muixirt o boy, with chromatic patch it takes ages to build rakudo 09:47
chromatic Yep. 09:49
bacek o/ 09:52
Good evening, lazybones 09:53
09:59 cotto joined
dalek TT #1561 created by bacek++: Auto-vivification of nested aggregates is deprecated. 10:03
TT #1561: trac.parrot.org/parrot/ticket/1561
mikehh clock 10:04
clock?
purl mikehh: LAX: Mon 3:04am PDT / CHI: Mon 5:04am CDT / NYC: Mon 6:04am EDT / LON: Mon 11:04am BST / BER: Mon 12:04pm CEST / IND: Mon 3:34pm IST / TOK: Mon 7:04pm JST / SYD: Mon 8:04pm EST /
dalek rrot: r45798 | bacek++ | trunk/DEPRECATED.pod:
Deprecate nested aggregates auto-vivification.
 10:05
10:14 allison joined
dalek kudo: 5386067 | moritz++ | src/core/Signature.pm:
work around TT #1560
 10:15
mikehh are we going to do anything regarding deprecating runcores before the release? 10:21
10:24 allison joined
bacek mikehh, just create ticket and put note into DEPRECATION.pod 10:31
mikehh bacek: not quite sure what to say there 10:36
I think it's a good idea to remove 'experimental' perhaps runcores, i.e. those that do not seem to be used and look at adding new ones - i.e. jit 10:37
dalek rrot: r45799 | fperrad++ | trunk (3 files):
[TAP] add options --merge & --ignore-exit
 10:38
muixirt 9.7 GB! And i wondered why it took so long with the profiling runcore :-) 10:43
10:43 aukjan joined 11:07 fperrad_ joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#33285), fulltest) at r45799 - Ubuntu 10.04 beta amd64 (g++ with --optimize) 11:07
11:41 tetragon joined 11:42 bkuhn joined 11:50 petdance joined 12:00 kid51 joined
kid51 make fulltest: PASS: darwin/ppc at r 45789 12:00
12:18 Mokurai1 joined 12:25 whiteknight joined 12:27 iblechbot joined 12:42 ruoso joined
whiteknight good morning, #parrot 12:45
muixirt hi whiteknight 12:48
mikehh hi there, whiteknight 12:49
whiteknight hello muixirt, mikehh
13:00 rurban_ joined 13:18 patspam joined, lucian joined
dalek rrot: r45800 | mikehh++ | trunk/compilers/imcc/instructions.c:
add missing documentation
 13:24
13:27 jozef joined 13:29 khairul joined 13:32 jozef left 13:35 petdance joined
dalek rrot: r45801 | bacek++ | branches/compact_pool_revamp/src/gc (2 files):
Start calculating actually freed space in Memory_Blocks
 13:46
rrot: r45802 | bacek++ | branches/compact_pool_revamp/src/gc (2 files):
Use Memory_Block->freed for calculating skip list
13:50 fperrad_ joined 13:52 PacoLinux joined 13:56 atrodo joined
dalek TT #1562 created by doughera++: Silence Configure.pl warnings about ccwarn when the default compiler is ... 13:57
TT #1562: trac.parrot.org/parrot/ticket/1562
rrot: r45803 | mikehh++ | trunk/compilers/imcc/optimizer.c:
add missing documentation
 14:02
rrot: r45804 | mikehh++ | trunk (2 files):
remove passing tests from TODO list, and fix copyright I missed
14:04 ash_ joined
mikehh hmmnnn - can't seem to find any usage of var_arg_ins from compilers/imcc/parser_util.c 14:14
NotFound <szabgab> NotFound, so I was told I need to try to convince you to create an Android port of Parrot ? --> Just tell google to send me a few phones to test on.
And a few netbooks, for completeness. 14:16
14:17 smash joined
smash hello everyone 14:17
mikehh hi smash 14:18
ash_ i am getting new complaints i have not seen before when i configure parrot, complaining about opengl headers. is that known?
(i am on os x if that makes a difference)
particle did you upgrade your opengl, or get it upgraded?
opengl is particularly finickey
ash_ os x has only 1 version of opengl, so... no, i haven't changed it 14:19
mikehh had the problem before when I added some new opengl functionality
dalek rrot: r45805 | bacek++ | branches/compact_pool_revamp/src/gc/alloc_resources.c:
Don't skip blocks with a lot of _free_ memory.
rrot: r45806 | bacek++ | branches/compact_pool_revamp/src/gc/mark_sweep.c:
Don't try to be smart for Buffer without allocated buffer in free_buffer.
ash_ well, okay, i misspoke, there are 3 version of open gl in os x based off your hardware support (either 2.1, 2.0 or 1.4) but almost all os x machines have the 2.1 14:21
NotFound bacek: ping
bacek NotFound, pong
14:22 bubaflub joined
NotFound bacek: there is no decision about deprecation releases for auto_attrs related things. 14:22
bacek NotFound, and? Just put deprecation notice. Start bailing out on pmcs without (auto|manual)_attrs. 14:23
After 2.3
holy... 14:24
It's tomorrow again.
szabgab NotFound, I'll do that (re talk to Google) could you in the meantime use the emulator ?
it is actually easier to use than a phone 14:25
bacek probably will sleep over tomorrow's #ps
NotFound szabgab: I was joking. I have already more projects than I can manage.
szabgab :(
NotFound Maybe I must create a company to take care, and then sell it to google ;) 14:28
I'm a humble guy, just few million euros will make me happy.
14:30 dmagnus joined
bacek Money doesn't make any difference 14:31
People with 10 millions aren't happier than people with 9.
NotFound bacek: I'm already different enough, just want the money ;) 14:32
bacek anyway 14:33
bed time
purl bed time is probably a good idea
bacek night
szabgab where are you NotFound ? 14:38
NotFound szabgab: Spain 14:39
14:47 davidfetter joined 14:51 ash__ joined
dalek rrot: r45807 | NotFound++ | trunk/DEPRECATED.pod:
add deprecation notice for TT #1506
 14:52
ash__ what kind of internal representation are pmc's in? is there a document that decribes it? or should i go find a header file? 14:53
NotFound ash__: pobj.h 14:55
ash__ thanks, i'll find that 14:56
15:00 ash_ joined 15:06 Andy joined
dalek kudo: 1fc9d8a | moritz++ | docs/release_guide.pod:
masak++ does the June release
 15:12
p-rx: 18c5d12 | pmichaud++ | src/HLL/ (2 files):
Remove \\e from quoted-string handling, it's too P6-specific to

The other escape sequences (\\f, \\0, etc.) can stay, though.		 15:15
p-rx: 3ac0b79 | pmichaud++ | src/NQP/ (2 files):
Add \\e quote_escape to NQP.
kudo: 796c566 | pmichaud++ | docs/release_guide.pod:
Remove myself from the April release manager -- open for others.
 15:17
rrot: r45808 | petdance++ | trunk/t/src/basic.t:
properly consted argv
 15:41
japhb ash_, I'm the guy to take a look at OpenGL header warnings. Can you nopaste, plz? 15:44
ash_ sure
do you want the full output of the configure or just the messages?
paste.lisp.org/display/97988 is just the errors 15:46
japhb ash_, ah. Looks like Apple decided to futz with their header formatting again. 15:50
OK, can you tar up /System/Library/Frameworks/OpenGL.framework/Headers/ please?
ash_ sure
japhb (er, and send it to me)
dalek kudo: fe6ca94 | masak++ | docs/release_guide.pod:
[release_guide.pod] vacant slots more visually distinct
 15:52
ash_ japhb: greaterthaninfinity.com/wp-content/...eaders.zip 15:53
if you need anything else, let me know
japhb What Mac OS release do you have? 15:54
ash_ 10.6.3
japhb thx
ash_ uname -a
purl Infobot 0.43.3 alpha (oznoid+#perl)
ash_ Darwin Strudel.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386
japhb I have a meeting coming up, but I can look at it later today. How long will you be around? 15:55
ash_ i'll be here for another hour, then again this afternoon
japhb Ah, what's your TZ?
ash_ US central 15:56
japhb OK, great. I'll contact you this afternoon, most likely
15:56 fperrad_ joined
dalek kudo: ba591c9 | masak++ | docs/release_guide.pod:
[release_guide.pod] one more slot
 15:58
15:59 rurban joined 16:02 theory joined 16:06 NordQ joined 16:16 NordQ joined 16:18 NordQ joined 16:20 zostay_ joined 16:24 NordQ joined 16:26 NordQ joined 16:28 NordQ joined
dalek TT #1562 closed by coke++: Silence Configure.pl warnings about ccwarn when the default compiler is ... 16:30
TT #1562: trac.parrot.org/parrot/ticket/1562
16:33 brooksbp_ joined
dalek rrot: r45809 | coke++ | trunk/config/init/defaults.pm:
Don't try to use ccwarn in this case, since it doesn't necessarily exist.
 16:34
16:37 NordQ joined 16:39 chromatic joined 16:42 Mokurai joined 16:46 NordQ joined 16:48 NordQ joined 16:49 NordQ left 16:55 Andy joined
Coke ccwarn could be schwern! 17:01
17:02 cotto_work joined
dalek rrot: r45810 | fperrad++ | trunk/runtime/parrot/library/TAP/Parser.pir:
[TAP] small fix
 17:02
rrot: r45811 | fperrad++ | trunk/runtime/parrot/library/TAP/Harness.pir:
[TAP] put extra files in archive
17:04 joeri joined
cotto_work ouch: www.google.com/search?q=site:pasteb...EY-----%22 17:10
17:11 fperrad joined
darbelo Oh look, there's mine! I thought I had lost it for good! 17:11
chromatic What is pastebin doing with my luggage combination?
bubaflub i've seen people use google for reverse md5 hashing too. 17:12
atrodo I've seen it used for searching for credit card numbers
darbelo Why steal dad's credit card when you can just google it? 17:14
17:15 Mokurai1 joined 17:17 fperrad_ joined
cotto_work anyone feel like adding a deprecation notice for some runcores? 17:19
particle sure would be nice to know which ones to deprecate first 17:21
has anyone looked at the source/config? the comments i've seen seem uninformed
cotto_work allison's solution is to deprecate a superset of what we know we'll want to remove 17:22
particle like, deprecate slow core? isn't that the default on non-gcc?
darbelo Slow is only the default due to a bug in fast IIRC.
Or that's teh impression I got from chromatic's comments on it. 17:23
chromatic Exactly. 17:24
particle ok, so let's deprecate the stable one in favor of the buggy one.
or, don't deprecate slow until fast works.
darbelo Deprecation makes sense, once the bug's gone from fast it becomes the default and slow can get the axe. 17:25
Coke or, mark pluggable runcores as 'experimental' for a single release cycle.
particle i thought gc/debug cores were based on slow.
i'm not comfortable deprecating our default core 17:26
we can't prove stability of fast core until it's default
we can deprecate slow in 2.6
if fast is fixed before, say, 2.4
...and made default.
17:27 alexn_org joined
Coke particle: you should probably voice your objection on the mailing list. 17:27
chromatic Deprecating slow makes no sense to me either. 17:28
It's ~20 lines of code.
particle right
Coke: will do, just want to get feedback on this higher-bandwidth communication channell first 17:29
17:38 mj41 joined
Coke in general, the more runcores, the more of a PITA it is to build a HLL with dynamic ops, but really it's no harder for 3 than 2. 17:38
well, not much.
purl same here, dude
darbelo doesn't really care either way. 17:39
cotto_work and the more effort will be needed to complete the nqp-rx based ops compiler
17:40 Mokurai joined
cotto_work (which is great *if* the extra runcores provide some benefit) 17:40
chromatic The number of runcores isn't the problem. The number of extra ops libraries required for those runcores is the problem. 17:41
darbelo I'd guess that cgp should be slightly faster, but I'm not sure it's fast enough to be worth it.
cotto_work no need to guess 17:44
darbelo I don't care enough to benchmark :) 17:45
particle i do, it goes to rakudo adoption rates
can someone get benchmarks of the rakudo spectest suite on cgp vs default? 17:46
chromatic CGP doesn't compile with VS.
particle oh, believe me, i know that :)
chromatic I also don't believe Rakudo's performance is a Parrot issue.
particle still, it's a performance regression
chromatic What's a performance regression? 17:47
particle switching away from cgp on gcc builds needs to be justified
17:47 Andy joined
chromatic We don't use CGP on gcc builds. 17:47
particle well, hell, rip that sucker out. it'll always be in svn history. 17:48
chromatic Fakecutables use the default core, so no one using a Rakudo binary will notice.
japhb We need to connect someone with mounds of cash to someone who worked on Nitro, V8, or Tracemonkey. :-) 17:49
chromatic I don't think that'll speed up Rakudo by a sizeable amount either.
japhb chromatic, I would presume that all three of the above have a half-decent GC as well .... 17:50
Well, maybe not Tracemonkey.
Just based on how big my damn browser gets after a few days.
chromatic Sure, but as the person who's arguably done the most to speed up both Parrot and Rakudo in the past two years, my instinct tells me that we can double Parrot's speed and not speed up Rakudo by that much. 17:51
japhb Ah. Ouch.
(I was (mostly) kidding, anyway)
chromatic NQP generates inefficient code for Rakudo, and I think plenty of Rakudo is inefficient as well.
17:51 zostay_m joined
japhb nodnod 17:51
Did the GSoC for NQP optimization get approved? 17:52
cotto_work japhb: you mean past?
japhb or PAST, I suppose. Same effect.
chromatic As far as I know, approvals are still underway.
cotto_work I think the final decisions will be made today and announced on the 21st. 17:53
japhb cotto_work, ah, thanks.
particle decisions are announced on the 21st 17:54
they are not made today
the deduplication period has begun today. tpf has no duplicates 17:55
(as far as i'm aware, from the webapp view i have)
17:55 mj41 joined
japhb particle, I thought some (two?) of the Parrot submissions were also submitted elsewhere (RTEMS?) 17:56
bubaflub per the suggestion of dukeleto and DrJoel from RTEMS i submitted my app to both TPF and RTEMS
cotto_work yeah. I'm wondering abiout the status of those
bubaflub they said it would be easier this way than having to move an application
darbelo Duplication means 'accepted nyt two orgs' not 'submitted to two orgs' IIRC
*accepted by 17:57
japhb darbelo, yeah, that's what I'd assumed. My point was merely that there could indeed be dupes amongst TPF's collection.
darbelo objects to being called a 'dupe' 17:58
;)
particle bubaflub: i'll recheck the webapp then
japhb heh
bubaflub i also submitted a number of proposals to a few different orgs
Coke chromatic: I'd be curious to see if allowing more non-PMC registers further up the food chain would be helpful. 17:59
I will try to fire up the profiling core on rakudo or partcl this week and see if anything jumps out. 18:00
particle rakudo inefficient? but it's written in perl 6! 18:01
Coke (which is non-sequitor to my previous send.)
chromatic I've offered to make primitives work for lexicals a few times, but pmichaud and jnthn said "Not yet".
Goodness knows I've written more than one opcode to speed up NQP, but as far as I know NQP doesn't use them yet.
particle yes, native typed variable support isn't required for r* 18:02
Coke I thought vivify etc. were used.
chromatic I could be wrong, but I don't think they are.
particle no, that's still todo
japhb I'm guessing NQP has not been receiving a lot of love this year in general.
(calendar year, I mean)
particle as far as i'm aware, the code needs to be converted to use vivify 18:03
chromatic Maybe I'll stop working on optimization for a while then.
Coke you're right, no vivify yet. 18:04
I'll see about that this week too.
japhb Unfortunately I think either the bus number for NQP is lower than for Rakudo, or everyone's sufficiently slammed trying to keep Rakudo* still in Q2 they haven't had time to try to attack NQP perf as well 18:05
(Just my impression from the outside)
chromatic Some people seem to have plenty of time to complain about Parrot performance though. 18:06
Coke I'm not sure those are the same people.
18:07 muixirt joined
chromatic I am. 18:07
Coke in any case, I have commit bits on nqp-rx.
japhb chromatic, sure -- but 1) Every time you pull a miracle out of thin air, you simultaneously make things better for everyone, and cement the impression that Parrot is the primary optimization target, and 2) It's logical for them to try to ask for help from someone outside the Rakudo team, since everyone inside is busy as hell.
18:08 theory joined
japhb (not that you're not, I'm just saying from a purely logical point of view, they're being sane) 18:08
chromatic I don't mind being asked for help, and I certainly don't mind being thanked for help. I'm sure other people who've helped with optimizations -- allison, bacek, whiteknight, Infinoid, et cetera -- don't mind thanks either.
The constant whining and berating grates on me, though.
japhb I get that: "thankless" is bad enough, "complaint target" is something else entirely 18:09
chromatic I mean, yes I did fix a few memory leaks in Parrot the other day.
I also fixed a handful in Rakudo. 18:10
Yes, Parrot's garbage collector has some awful behavior in a couple of conditions, and it needs to find free memory much more cheapy.
japhb But I can say, personally: THANK YOU. The few times this last quarter I've had time for Parrot tasks, I've appreciated the noticeable improvements.
pmichaud 17:51 <chromatic> NQP generates inefficient code for Rakudo, and I think plenty of Rakudo is inefficient as well.
any particular inefficiencies we should be targeting?
chromatic ... but the latest Rakudo benchmark allocates some 5MB of PMCs for every edge in a highly recursive mandlebrot, and you're not going to run quickly if you're generating a graph that costs 5MB per edge. 18:11
Coke we were just discussing taking advantage of vivify.
pmichaud vivify doesn't really make a big speed improvement.
chromatic pmichaud, I suspect that preemptive error-handling code could be expensive.
Coke no, but it's on the list and is something I couldc concevably do. =-)
pmichaud chromatic: I don't quite understand "preemptive error-handling code" 18:12
chromatic I optimized PGE a couple of times by delaying the creation of PMCs used in error handling until after the error occurred. 18:13
pmichaud I don't know that NQP creates any PMCs preemptively this way.
Or, if it does, I'm totally ignorant of it. 18:14
chromatic I'm happy to run an NQP benchmark and explain what I think I see. 18:16
pmichaud That would be welcome.
chromatic Any recommendations on representative code?
pmichaud NQP itself would be one. :-) 18:17
chromatic How do I run it? 18:19
Bootstrap mode, I mean.
pmichaud oh, for a benchmark.
chromatic Right.
pmichaud "make stage1" gives some representative commands.
might need to touch a file somewhere though. hmm. 18:20
chromatic From the github checkout?
pmichaud yes. Actually, perhaps I can come up with a better benchmark.
18:20 pancake joined
chromatic Okay. I'm going to run out for some food, but I'll take a look when I return. 18:21
pmichaud anyway, yes, from the github checkout, "make stage1" creates the stage1 compiler from the bootstrap compiler
"make stage2" creates the stage2 compiler using the stage1 compiler
either of those stages has a number of useful "build a component of nqp" commands that could be benchmarked 18:22
dalek nxed: r443 | julian.notfound++ | trunk/winxed.winxed:
WINXED_PATH environment var to locate stage pbc files
 18:34
chromatic pmichaud, autoboxing strings into String PMCs is fairly expensive. 18:36
pmichaud chromatic: I think that generally happens when a string needs to go into a lexical 18:38
chromatic This isn't from the box opcode, but from conversions during PCC argument/return passing.
pmichaud have a quick example? 18:39
(and my previous comment stands -- I think it happens when a string needs to go into a lexical)
chromatic I don't have a quick example within NQP, but foo( 'some string' ) where foo's first param is .param pmc some_string_pmc 18:40
pmichaud if 'foo' is written in Perl 6 or NQP, then the parameter ends up being a lexical
which means it needs to be a PMC.
chromatic Primitive lexicals would help that then.\\ 18:42
pmichaud if 'foo' is written in PIR and I have good reason to believe the parameter is going to end up being boxed anyway (e.g., because it's going to be stored as an object attribute or as an element of an aggregate), then I typically let the argument passing do the boxing.
18:42 brooksbp joined
pmichaud Primitive lexicals will help *if* we know that the value can safely be held as a string register. 18:42
that works for NQP subs, but very few subroutines in Perl 6 are going to be written as sub foo(str $x) { ... }
chromatic Right.
pmichaud My answer to htis problem has been to cache 'some string' somewhere as a PMC and then call foo() using that cached PMC 18:43
instead of boxing a new PMC on each invocation.
haven't implemented that yet, but it's much better to create the PMC once on first use than to create a new one on each use. 18:44
same would hold true for integer, float, and other constants 18:45
18:48 iblechbot joined
pmichaud (primitive lexicals) and actually, I guess it would have to be written sub foo($x as str) { ... } 18:49
because the first would limit mmd dispatch
although that doesn't seem quite right either, because it doesn't constrain $x to be a str 18:50
Coke smolder failure. 18:53
dalek nxed: r444 | julian.notfound++ | trunk/winxed.winxed:
fix command line options checks
 18:59
chromatic The vtable override performance improvement to Parrot will help NQP a fair amount. 19:02
muixirt pmichaud: is there any chance that functions like '!cursor_start' in ext/nqp-rx/src/stage0/Regex-s0.pir can be simplified? 19:09
19:10 ash_ joined
dalek nxed: r445 | julian.notfound++ | trunk/winxedst (2 files):
new predef function 'cry' ('say' to stderr)
 19:18
Coke muixirt: which part do you think can be simplified?
(it's only about 22 lines...)
muixirt Coke: well that method is pretty short, but it gets called half a million times for instance compiling src/gen/core.pm while building rakudo 19:21
Coke I don't see any obvious optimizations. 19:22
muixirt Coke, but i don't have a clue
Coke avoiding the method call might help.
on that note, I see a lot of method calls that just return an attribute. 19:24
I would if removing the method calls and just doing the getattribute there would help.
(get + set) 19:25
(that's not an algorithmic issue like the one chromatic was expecting, but might be a practical change regardless.) 19:26
cotto_work One glaring error I've noticed is that the parrot executable doesn't respond properly to --halp 19:28
pmichaud 19:24 <Coke> I would if removing the method calls and just doing the getattribute there would help. 19:31
Interesting, since the conversation on #perl6 this morning was about the need to do the opposite (replace getattribute/setattribute with method calls :)
19:31 Mokurai1 joined
pmichaud !cursor_start is the way that we create a new cursor to keep track of a new (sub)match 19:32
PAST::Regex is designed so that it's possible to inline that method.
Coke pmichaud: yah, it's not ideal from an API perspective. just curious to see if it's a speed boost. 19:37
(and if so, let's make method calls faster.) - but I don't know if recent PCC work has improved the situation here. 19:38
chromatic Some. 19:39
pmichaud I can likely inline that code, yes.
Coke ah, you could keep the methods as a fallback and inline their invocations for internal use. =-)
pmichaud right
that's what I meant.
Coke evil but fast!
er. 19:40
faster.
pmichaud the method needs to stick around, definitely.
but the hotpath at the beginning of generated rules could be inlined.
Coke if no one gets to it, that's definitely something within my skill level. =-)
chromatic What's the ratio of removed calls to total calls? An estimate is fine. 19:41
pmichaud don't know that one
I suspect it's smallish. there are a lot of method calls.
but every subrule invocation results in a call to !cursor_start 19:42
I think I can get rid of the internal call to .HOW, too. 19:43
muixirt pmichaud: what is the .local pmc pos good for in that Regex-s0.pir? 19:44
pmichaud muixirt: it's a fossil, can be removed (but doesn't impact the code at all)
Coke it might slow down compilation fractionally, but not the runtime. 19:45
pmichaud right. and this isn't dynamic compilation.
Coke pmichaud: if I wanted to do that in nqp-rx, I'd edit the stage0 files? 19:46
pmichaud Coke: no, the stage# files are all generated
it's in src/Regex/Cursor.pir (and I've already made the change and I'm testing now) 19:47
Coke or Regex/Cur... danke. ok. =-)
pmichaud++
pmichaud I'm also going to bump PARROT_REVISION and make sure nqp is working with latest parrot
moritz pmichaud: did you implement yet any of the discussed changes to match object generation? 19:49
pmichaud moritz: not yet. I'm having to think about it a bit more.
I'm about to fix the CodeString one, though. 19:50
I think the other changes should perhaps wait until after tomorrow's release.
moritz pmichaud: ok
pmichaud: if you want me to pick any LHFs once you decided, just let me know
pmichaud moritz: will definitely do so. 19:51
Coke What's up with Codestring?
pmichaud right now nqp-rx forces all string targets to be instance of CodeString
that's great if you're parsing code, not so great if you're expecting a Perl 6 Str
Coke Yah, PO String seems safer there.
dalek p-rx: 7662467 | pmichaud++ | src/Regex/Cursor.pir:
Remove 'pos' register fossil noticed by muixirt++ .
pmichaud so I'm going to switch it so that conversion to CodeString is handled by the language parser, and the engine just takes whatever type of object you send it for doing the match 19:52
an interesting question is: 123 ~~ /\\d+/; say $/.orig.WHAT # Int? 19:53
moritz if you can have it that way (efficiently)
pmichaud well, I might keep the original value as $!orig but cache the stringified target somewhere
this is a place where being able to store native strings as object attributes could be very efficient 19:54
(so that we don't have to box into a stirng)
*string
Coke String? =-) 19:55
pmichaud did the "install-dev" target disappear?
19:56 mberends joined
moritz pmichaud: it's included in 'make install' by default 19:56
and the old 'install' becaume 'install-bin' or so
pmichaud hmmm. with latest parrot, "make install" isn't.
(when run from nqp-rx's --gen-parrot option)
moritz it should - bug when not (IMHO)
pmichaud hmm, something else deeper seems to be going on 19:57
just a moment
Coke pmichaud: is something missing from the install or is the whole thing failing?
pmichaud whole thing failing
Coke (I use parrot's make install several times a week on my dev box.)
pmichaud I'll watch more closely this time 19:58
oh, it's not able to "make" at all from the script.
it runs parrot's Configure okay, but then fails on the 'make'
Coke build borked?
pmichaud worked fine with earlier versions of Parrot 19:59
I'll start over
Coke r45811 was ok here.
pmichaud aha 20:01
looks like config_lib.pasm changed to config_lib.pir
moritz aye
mberends Can Parrot reveal its Process_ID? Rakudo is faking with a 0 and claiming a success because of a buggy test.
pmichaud afaik Parrot doesn't reveal PIDs yet.
mberends :-( 20:02
Coke it /might/ be available on the interpreter.
checking...
dalek TT #1563 created by mikehh++: Deprecation of unused runcores
TT #1563: trac.parrot.org/parrot/ticket/1563
Coke mberends: github.com/partcl/partcl/blob/maste...in/pid.pir - macro hell, but there's my cheat. 20:03
mberends thanks Coke
Coke np. hope it helps. 20:04
pmichaud basically calling dlfunc to grab getpid() from the C lib? Evil. :-)
mberends Coke: it may be OS dependent, not sure if Win32 would support it. 20:05
I have a corrected test. I'll comment it out of spectest.data if the implementation is not platform independent. (it's in rakudo's cheats anyway) 20:06
Coke mberends: it's deprecated on windows but still there. I think. 20:07
(_getpid) is preferred, says the google.
mberends ah. Coke++
20:14 hercynium joined
dalek p-rx: 72d4125 | pmichaud++ | build/ (2 files):
Bump PARROT_REVISION to latest Parrot, and switch Parrot's
 20:14
kudo: 346e76d | (Martin Berends)++ | t/spectest.data:
[t/spectest.data] remove S02-magicals/pid.t (1 test) because is was crashing instead of passing and $*PID is NYI
 20:16
Coke pmichaud: (config_lib.pir) ugh. I didn't even think to check that when the change was made. 20:17
rakudo will no doubt need the same fix.
(as will partcl-nqp) 20:18
moritz Coke: it already has (rakudo)
Coke ooh, I think I just sweet talked my employer into a yapc donation.
moritz: I just did a pull and didn't see it.
moritz Coke: a8e70acdf61589f29f80d7b840f8c06e7aa5f483 20:19
bump PARROT_REVISION, and change config_lib from .pasm to .pir
Coke moritz: ... these aren't the droids I'm looking for. You can go about your business.
GeJ Good morning everyone. 20:32
20:38 brooksbp_ joined 20:41 Andy joined
bacek yawns 20:54
Good morning, humans
GeJ G'Day bacek. 20:55
bacek G'Day GeJ
21:00 rurban_ joined 21:05 Andy joined 21:08 Whiteknight joined
pancake now's the release status? 21:13
Coke you mean "how" ? 21:29
GeJ make fulltest PASS FreeBSD/amd64 on trunk@45811 21:42
21:52 particle joined 21:54 mmcleric joined
mberends Coke++: thanks for the 'getpid' hint, it works in Rakudo on Linux (only without underscore) but not Windows (needs kernel32.dll). How feasible would it be to build getpid() into Parrot? 21:57
Coke mberends: I'd like to avoid having to use that trick in "real" code, so I think it's pretty reasonable to give a parrot API to hide the evil. 21:58
I think the biggest issue is where to put it. 21:59
but if you put in a generic "would like to get pid from parrot without using <ugly hack from coke>" I think that'll work. =-)
(er, generic trac ticket)
mberends heh, ok 22:00
22:26 davidfetter joined
alexn_org hi guys, I'm evaluating Parrot for a pet language I'd like to build ... my language is dynamic by default, but with optional static typing (striking similarity with Perl6 apparently :)) ... but looking at PIR code this metadata gets lost, so there aren't any planned optimizations based on static-typing, right? ... and another thing ... I'd like the performance to be decent and you guys did a wonderful work but haven't emphasised on performance, and it's 22:35
darbelo alexn_org: You got cut off after "emphasised on performance, and it's" 22:39
alexn_org ... and it's OK ... but do you have plans for a tracing JIT? ... I also think parrot.org/dev needs a section with relevant documentation on Parrot's implementation (like code.google.com/p/unladen-swallow/w...antPapers) 22:43
:)
22:43 hercynium joined
darbelo We've got lots of plans, tracing JIT is on the list. ETA depends on volunteer effort. 22:44
cotto_work alexn_org: Once Rakudo* is out the door, I believe that we'll start to put serious effort into Lorito, which will be a minimal set of ops in which everything else is implemented.
Lorito will open a large number of optimisation possibilities. 22:46
darbelo Lorito will make JIT-oriented work a lot more fun that it is now, that's for sure. 22:47
cotto_work There's also a PAST optimization gsoc proposal that I'm hoping is accepted.
I shouldn't say more than that about the proposal until accepted gsoc projects are officially announced. 22:49
Tene alexn_org: So, yes, there are plans in progress to improve parrot's speed quite a bit, but they haven't been followed through with yet. The focus has been on completeness and correctness so far.
We've been aware of where we want to be for quite a while now.
Whiteknight we have been spending a lot of timing focusing on correctness of implementation for a few of our subsystems 22:50
darbelo There's also chromatic and bacek's recent work on optimization. We're getting faster every day.
Whiteknight performance is an area where we increasingy need to focus
cotto_work alexn_org: whether to use Parrot or not depends on your aim. If you want to learn about VMs and language design, it'll help. If you want a production-ready language asap, not so much.
22:51 tetragon joined
cotto_work We do intend to make Parrot a good production HLL compiler toolset and runtime. It's just not there yet. 22:51
alexn_org cool ... I don't know much theory about VMs, and I don't know where to start ... it would be useful if you provided some papers relevant to parrot's runtime or links to books, because if I'd want to take a look at Parrot, I wouldn't know where to begin :) 22:52
darbelo docs/book/ in the parrot svn tree can serve as an itroduciton to the vm. 22:53
docs.parrot.org/parrot/latest/html/ if you like your docs with more eye-candy ;) 22:54
alexn_org darbelo: I meant about the runtime's implementation ... I'm planning on reading papers on self/smalltalk for instance, but I don't know if those are relevant to parrot 22:57
cotto_work The design of Lorito is partially inspired by the Squeak Smalltalk implementation. 22:58
darbelo There's some of that in docs.parrot.org as well. You might want to read the PDDs (Parrot Design Documents) with the caveat that some are still drafts and others are due for revision. 23:01
GeJ I seem to remember that someone pointed to another language recently wrt very limited number of ops to start with. 23:02
cotto_work GeJ, other than Smalltalk or Inferno's VM? 23:03
GeJ I think so. 23:04
Wasn't it Alan Kay's COLA? 23:12
lambda-the-ultimate.org/node/2483 23:13
"We show that three object types and five methods are sufficient to bootstrap an extensible object model and messaging semantics that are described entirely in terms of those same objects and messages." 23:14
darbelo That's working at a different level than the one we're discussing here. We're talking about the primitive vm operations that those objects and methods should be written in. 23:15
muixirt GeJ: Cola was mentioned some time ago in the wiki trac.parrot.org/parrot/wiki/Languages 23:16
darbelo That's also a different Cola.
GeJ Ah! chromatic mentionned it here : irclog.perlgeek.de/parrot/2010-04-06#i_2203396 23:17
dalek TT #1564 created by mberends++: expose a getpid library function for Rakudo $*PID and other languages 23:20
TT #1564: trac.parrot.org/parrot/ticket/1564
23:22 tcurtis joined
mberends (more than half the search results for PID in trac were in the word 'stupid' :) 23:24
dalek kudo: 35bcd52 | jonathan++ | (9 files):
Get hash slices essentially working. In the process, move Associative role completely into the setting. Nothing in PIR actually did it, plus we now have the ability to augment the role into classes in the core setting anyway, so it's no problem to add to things first defined in PIR anyway. Slight re-think of how we handle non-Perl 6 hashes that seems rather cleaner to me; need to tweak array indexing similarly, will do it soon.
 23:31
kudo: ba19436 | jonathan++ | t/spectest.data:
Turn on hash_ref.t.
23:42 tcurtis_ joined 23:48 Andy joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!