Camelia, the Perl 6 bug

IRC log for #parrot, 2010-04-19

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 allison joined #parrot
00:00 chromatic ... but I'm not holding my breath for that.
00:03 Whiteknight thanks chromatic! you're the bestest!!!
00:08 Whiteknight it seems my gratitude was so moving and so sincere that chromatic had to sign off and weep privately
00:09 Infinoid heh.  so moving he fell off the internet :)
00:11 Whiteknight ...and before I do any more good, I'm signing off for the night
00:11 Whiteknight goodnight
00:12 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 #parrot
00:22 japhb allison, ping
00:23 allison japhb: pong
00:24 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:25 allison I started to look it over and got sucked away
00:25 allison will finish up now...
00:25 japhb ah
00:25 japhb thanks!
00:26 japhb Any comments appreciated, because I will use this one as a template for any future proposals ....
00:32 allison japhb: it's a good modular task, and seems completable in the time suggested
00:32 japhb Well, that's a good start.  :-)
00:33 allison japhb: (typing out responses as I go)
00:33 japhb np[
00:34 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:35 preflex joined #parrot
00:35 japhb Ah, good point.
00:35 allison japhb: that could be worked into the text
00:35 japhb Perhaps it would help to put in a brief section about what other major tasks I think there are.
00:36 japhb I had roughed out plans for 3-4 grant projects of similar size.
00:36 japhb Putting this one in the context of the others seems useful.
00:36 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?
00:37 allison japhb: yes, the context is helpful
00:37 allison japhb: (back to MiniSat) especially since there are questions whether NQP is the best language for the task given speed questions
00:38 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:39 japhb 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
00:39 allison japhb: but, I'm also keeping in mind the duplication of effort
00:39 japhb nod
00:41 Mokurai1 left #parrot
00:42 cosimo joined #parrot
00:42 allison japhb: and I do think using SAT solvers for package dependencies is an excellent idea
00:42 japhb :-)
00:43 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:44 allison 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 ...
00:44 allison japhb: those were all the comments I had on the proposal, happy to have the board look at it
00:46 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 japhb Thanks for reviewing the draft, allison!
00:52 lucian joined #parrot
00:54 allison jabphb: great! glad to help
01:13 elmex joined #parrot
01:18 Mokurai joined #parrot
01:20 Mokurai1 joined #parrot
01:21 eternaleye joined #parrot
01:24 kid51 make fulltest PASS linux/i386 f45789
01:27 plobsing joined #parrot
01:57 abqar joined #parrot
02:16 Andy joined #parrot
02:21 cosimo joined #parrot
02:42 janus joined #parrot
03:07 kurahaupo joined #parrot
03:29 Andy joined #parrot
03:38 allison joined #parrot
03:56 GeJ make fulltest PASS FreeBSD/amd64 trunk @r45789
04:11 Andy g++ 4.5.0 is more fussy about pointer conversions
04:11 Andy so now t/src/extend.t is failing.
04:12 GeJ did anyone try to build Parrot with clang?
04:21 sorear I have clang and parrot, I'll try if someone gives me documentation on how
04:22 sorear last time I tried to build a nontrivial project with clang, clang tried to parse the GNU libstdc++ headers and failed horribly
04:26 Andy I haven't actually installed clang before
04:27 Andy But I want to
04:27 Andy because I like compilers
04:27 Andy and their warnings
04:28 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:29 GeJ It got me wondering if someone ever tried to build Parrot.
04:31 GeJ Okay. Let's build llvm and see how it goes.
04:40 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:41 JimmyZ joined #parrot
04:42 JimmyZ make fulltest failed on windows XP with strawberry perl with --optimize
04:42 JimmyZ Test Summary Report
04:42 JimmyZ -------------------
04:42 JimmyZ t/pmc/eval.t                       (Wstat: 512 Tests: 17 Failed: 2)
04:42 JimmyZ Failed tests:  10, 12
04:48 bacek_at_work wow. All test passed trunk + clang on Debian/testing
04:59 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 rurban_ joined #parrot
05:44 dalek parrot: r45790 | petdance++ | trunk/t/src/embed.t:
05:44 dalek parrot: properly consting argv
05:44 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45790/
05:45 aukjan joined #parrot
05:50 davidfetter joined #parrot
05:56 uniejo joined #parrot
06:00 allison joined #parrot
06:00 dalek parrot: r45791 | petdance++ | trunk (9 files):
06:00 dalek parrot: correcting all the argv to be  "const char **argv"
06:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45791/
06:00 dalek parrot: r45792 | petdance++ | trunk/t/src/warnings.t:
06:00 dalek parrot: fix decaration of argv
06:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45792/
06:00 dalek parrot: r45793 | petdance++ | trunk/src/gc/alloc_resources.c:
06:00 dalek parrot: shut down warning on unused interp
06:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45793/
06:03 sorear attempting to build parrot with clang almost worked
06:05 sorear 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:10 ttbot Parrot trunk/ r45794 i386-linux-thread-multi make error http://tt.taptinder.org/file/cmdout/269620.txt ( http://tt.taptinder.org//bui​ldstatus/pr-Parrot/rp-trunk/ )
06:17 dalek parrot: r45794 | petdance++ | trunk/src/thread.c:
06:17 dalek parrot: removed unused interp args from static functions
06:17 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45794/
06:31 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 http://code.google.com/p/android​-scripting/issues/detail?id=296 and many people upvoted it already but I guess it will be much faster if you could help them out
06:32 iblechbot joined #parrot
06:33 dalek parrot: r45795 | petdance++ | trunk/src/thread.c:
06:33 dalek parrot: restored interps to a couple of functions that actually need them
06:33 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45795/
06:37 chromatic joined #parrot
06:42 chromatic I keep intending to ask Chris Dibona at Google for some Nexus One hardware.
06:56 szabgab we are going to have a "Perl on Android" talk on the 28th in Haifa in the offices of Qualcomm
06:56 szabgab and as I understand they are quite involved in Android too
06:56 szabgab it would be awesome to show Perl 6 running on Android as well
06:57 chromatic If we could get some kit, it should be possible to bring it up.
06:57 szabgab I am mostly using the emulator
06:58 szabgab it is much more convenient than a real device
06:59 treed Are there any Android devices that are actually open, dev-wise?
06:59 treed ISTR that some of the bigger ones did not permit you enough freedom to actually muck around with the internals.
06:59 szabgab as I understand there are 2
06:59 treed Just the G1 was open, I'd heard, and you couldn't use the marketplace because of it.
06:59 treed Which is just... really?
06:59 szabgab see "dev phones" http://developer.android.com/index.html
06:59 treed Makes me sad.
07:05 chromatic I thought you could use the G1 Dev phone with the marketplace.
07:06 fperrad joined #parrot
07:08 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:11 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 treed Or maybe you can have the marketplace, but not any paid apps.
07:14 chromatic That may be.  I remember hearing something about dev phones being able to subvert the payment mechanism.
07:18 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?
07:19 szabgab it can create some limited dialogs
07:19 szabgab so far that's what I found
07:19 treed I'd love to be able to do full apps on android.
07:19 treed But I don't want to do it in Java.
07:20 treed 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
07:20 treed Assholes.
07:20 purl assholes is at http://www.gopostal.net/GoPostal.html or at http://www.whitehouse.gov or at http://www.mastercard.com or at http://www.manpages.com/ or http://www.whitehouse.com or no longer at http://goatse.cx or at http://www.bezeqint.net or at http://www.netvision.net.il
07:21 szabgab so I opened some 10 tickets
07:21 szabgab and Parrot is currently the most requested new feature
07:22 treed Heh.
07:22 treed searching for perl on android
07:22 treed http://blogs.perl.org/users/gabor_​szabo/2010/03/perl-on-android.html
07:22 treed Go figure. :-P
07:24 fperrad_ joined #parrot
07:25 treed bedtime
07:44 kurahaupo q
07:54 allison joined #parrot
07:54 dalek parrot: r45796 | mikehh++ | trunk/src/parrot_debugger.c:
07:54 dalek parrot: fix codetest failure - change function documentation to reflect consting
07:54 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45796/
08:06 muixirt joined #parrot
08:09 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
08:09 purl Good Morning Mr Rogers
08:09 mikehh hi
08:10 muixirt there is a memory leak in parrot
08:11 muixirt are there issues again with the gc
08:11 muixirt ?
08:13 nopaste "muixirt" at 192.168.1.3 pasted "memory leak" (8 lines) at http://nopaste.snit.ch/20302
08:14 moritz do we have any such high level tests in the test suite?
08:16 mikehh probably not - there are a lot of areas missing tests - more tests are always welcome
08:17 moritz do we have portable means to obtain the memory usage of a parrot interpreter?
08:19 chromatic That's not a leak.
08:19 muixirt chromatic: why not?
08:19 chromatic It grows way too slowly to be a leak.
08:20 chromatic I've had it running for 2.5 minutes and it's using 158 MB RSS.
08:20 moritz so... fragmentation?
08:20 muixirt chromatic: it does bad things to rakudo
08:20 mikehh when would it invoke the gc
08:21 chromatic There's no upper bound on the GC.
08:21 chromatic There should be, but we don't have one.
08:21 iblechbot joined #parrot
08:21 mikehh I thought you were looking at cases when it got above a certain limit it would invoke
08:22 chromatic Yes, we've had that for several weeks now.
08:23 chromatic With a million iterations, Valgrind says: ==516== All heap blocks were freed -- no leaks are possible
08:25 chromatic With ten million iterations, Valgrind says: ==546== All heap blocks were freed -- no leaks are possible
08:26 chromatic After the 2.3 release, I'll look at the GC threshold to see if we can find a better tuning.
08:27 * mikehh switching to amd64 - bbiab
08:29 * mikehh well I was going to - need to check something first
08:29 gerd joined #parrot
08:30 muixirt chromatic: so what would be the correct wording for that issue?
08:31 chromatic GC tuning request.
08:31 muixirt noted
08:36 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:39 nopaste "muixirt" at 192.168.1.3 pasted "GC tuning request" (8 lines) at http://nopaste.snit.ch/20303
08:41 fperrad joined #parrot
08:44 clinton joined #parrot
08:56 chromatic Informed guess: the growth in memory is from the memory overhead of allocating new pools.
09:00 nopaste "chromatic" at 192.168.1.3 pasted "muixirt: GC tuning patch to test with Rakudo" (13 lines) at http://nopaste.snit.ch/20304
09:00 dalek parrot: r45797 | gerd++ | trunk/NEWS:
09:00 dalek parrot: add this important news for HLL developers
09:00 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45797/
09:06 dalek rakudo: a8e70ac | moritz++ | build/ (2 files):
09:06 dalek rakudo: bump PARROT_REVISION, and change config_lib from .pasm to .pir
09:06 dalek rakudo: This introduces a new test failure which is discussed at
09:06 dalek rakudo: http://trac.parrot.org/parrot/ticket/1560
09:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​8e70acdf61589f29f80d7b840f8c06e7aa5f483
09:10 chromatic ... except that tuning patch ruins performance.
09:12 muixirt chromatic: well it eats up memory more slowly
09:13 chromatic My recommendation: figure out which parts of NQP churn through so many PMCs and possibly STRINGs and fix that.
09:14 chromatic I can make Rakudo build really quickly if you have lots of memory.
09:14 chromatic I can make Rakudo build in a little bit of memory if you have lots of time.
09:15 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.
09:16 chromatic 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?
09:17 chromatic Probably NQP itself, though perhaps Rakudo's NQP programs.
09:17 muixirt i hope any rakudo dev read what chromatic wrote :-)
09:17 chromatic moritz and pmichaud are usually good about that.
09:18 chromatic I have one more idea I will try in the morning.
09:18 * moritz never profiled anything NQPish successfully
09:19 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:20 chromatic Lazy error reporting can help a lot.
09:21 muixirt so where is NQP currently developed, in the parrot repo or at github?
09:22 chromatic Github, I think.
09:27 moritz http://github.com/perl6/nqp-rx
09:28 muixirt and pmichaud updates the parrot repo every now and then?
09:28 moritz yes
09:36 mikehh joined #parrot
09:42 allison joined #parrot
09:47 riffraff joined #parrot
09:47 muixirt o boy, with chromatic patch it takes ages to build rakudo
09:49 chromatic Yep.
09:52 bacek o/
09:53 bacek Good evening, lazybones
09:59 cotto joined #parrot
10:03 dalek TT #1561 created by bacek++: Auto-vivification of nested aggregates is deprecated.
10:03 dalek TT #1561: http://trac.parrot.org/parrot/ticket/1561
10:04 mikehh clock
10:04 mikehh clock?
10:04 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 /
10:05 dalek parrot: r45798 | bacek++ | trunk/DEPRECATED.pod:
10:05 dalek parrot: Deprecate nested aggregates auto-vivification.
10:05 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45798/
10:14 allison joined #parrot
10:15 dalek rakudo: 5386067 | moritz++ | src/core/Signature.pm:
10:15 dalek rakudo: work around TT #1560
10:15 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​3860671b6a0a29158251e6e611b44dba1a6b7fe
10:21 mikehh are we going to do anything regarding deprecating runcores before the release?
10:24 allison joined #parrot
10:31 bacek mikehh, just create ticket and put note into DEPRECATION.pod
10:36 mikehh bacek: not quite sure what to say there
10:37 mikehh 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:38 dalek parrot: r45799 | fperrad++ | trunk (3 files):
10:38 dalek parrot: [TAP] add options --merge & --ignore-exit
10:38 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45799/
10:43 muixirt 9.7 GB! And i wondered why it took so long with the profiling runcore :-)
10:43 aukjan joined #parrot
11:07 fperrad_ joined #parrot
11:07 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:41 tetragon joined #parrot
11:42 bkuhn joined #parrot
11:50 petdance joined #parrot
12:00 kid51 joined #parrot
12:00 kid51 make fulltest:  PASS:  darwin/ppc at r 45789
12:18 Mokurai1 joined #parrot
12:25 whiteknight joined #parrot
12:27 iblechbot joined #parrot
12:42 ruoso joined #parrot
12:45 whiteknight good morning, #parrot
12:48 muixirt hi whiteknight
12:49 mikehh hi there, whiteknight
12:49 whiteknight hello muixirt, mikehh
13:00 rurban_ joined #parrot
13:18 patspam joined #parrot
13:18 lucian joined #parrot
13:24 dalek parrot: r45800 | mikehh++ | trunk/compilers/imcc/instructions.c:
13:24 dalek parrot: add missing documentation
13:24 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45800/
13:27 jozef joined #parrot
13:29 khairul joined #parrot
13:32 jozef left #parrot
13:35 petdance joined #parrot
13:46 dalek parrot: r45801 | bacek++ | branches/compact_pool_revamp/src/gc (2 files):
13:46 dalek parrot: Start calculating actually freed space in Memory_Blocks
13:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45801/
13:46 dalek parrot: r45802 | bacek++ | branches/compact_pool_revamp/src/gc (2 files):
13:46 dalek parrot: Use Memory_Block->freed for calculating skip list
13:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45802/
13:50 fperrad_ joined #parrot
13:52 PacoLinux joined #parrot
13:56 atrodo joined #parrot
13:57 dalek TT #1562 created by doughera++: Silence Configure.pl warnings about ccwarn when the default compiler is ...
13:57 dalek TT #1562: http://trac.parrot.org/parrot/ticket/1562
14:02 dalek parrot: r45803 | mikehh++ | trunk/compilers/imcc/optimizer.c:
14:03 dalek parrot: add missing documentation
14:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45803/
14:03 dalek parrot: r45804 | mikehh++ | trunk (2 files):
14:03 dalek parrot: remove passing tests from TODO list, and fix copyright I missed
14:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45804/
14:04 ash_ joined #parrot
14:14 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.
14:16 NotFound And a few netbooks, for completeness.
14:17 smash joined #parrot
14:17 smash hello everyone
14:18 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?
14:18 ash_ (i am on os x if that makes a difference)
14:18 particle did you upgrade your opengl, or get it upgraded?
14:18 particle opengl is particularly finickey
14:19 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
14:19 dalek parrot: r45805 | bacek++ | branches/compact_pool_revam​p/src/gc/alloc_resources.c:
14:19 dalek parrot: Don't skip blocks with a lot of _free_ memory.
14:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45805/
14:19 dalek parrot: r45806 | bacek++ | branches/compact_pool_revamp/src/gc/mark_sweep.c:
14:19 dalek parrot: Don't try to be smart for Buffer without allocated buffer in free_buffer.
14:19 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45806/
14:21 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
14:21 bacek NotFound, pong
14:22 bubaflub joined #parrot
14:22 NotFound bacek: there is no decision about deprecation releases for auto_attrs related things.
14:23 bacek NotFound, and? Just put deprecation notice. Start bailing out on pmcs without (auto|manual)_attrs.
14:23 bacek After 2.3
14:24 bacek holy...
14:24 bacek It's tomorrow again.
14:24 szabgab NotFound, I'll do that (re talk to Google) could you in the meantime use the emulator ?
14:25 szabgab it is actually easier to use than a phone
14:25 * bacek probably will sleep over tomorrow's #ps
14:25 NotFound szabgab: I was joking. I have already more projects than I can manage.
14:25 szabgab :(
14:28 NotFound Maybe I must create a company to take care, and then sell it to google ;)
14:28 NotFound I'm a humble guy, just few million euros will make me happy.
14:30 dmagnus joined #parrot
14:31 bacek Money doesn't make any difference
14:31 bacek People with 10 millions aren't happier than people with 9.
14:32 NotFound bacek: I'm already different enough, just want the money ;)
14:33 bacek anyway
14:33 bacek bed time
14:33 purl bed time is probably a good idea
14:33 bacek night
14:38 szabgab where are you NotFound ?
14:39 NotFound szabgab: Spain
14:47 davidfetter joined #parrot
14:51 ash__ joined #parrot
14:52 dalek parrot: r45807 | NotFound++ | trunk/DEPRECATED.pod:
14:52 dalek parrot: add deprecation notice for TT #1506
14:52 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45807/
14:53 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:55 NotFound ash__: pobj.h
14:56 ash__ thanks, i'll find that
15:00 ash_ joined #parrot
15:06 Andy joined #parrot
15:12 dalek rakudo: 1fc9d8a | moritz++ | docs/release_guide.pod:
15:12 dalek rakudo: masak++ does the June release
15:12 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​fc9d8aed9eea5db24d6eb50d9cf415906541cdd
15:15 dalek nqp-rx: 18c5d12 | pmichaud++ | src/HLL/ (2 files):
15:15 dalek nqp-rx: Remove \e from quoted-string handling, it's too P6-specific to
15:15 dalek nqp-rx: be part of HLL::Grammar.  It's okay to add it to NQP::Grammar, though.
15:15 dalek nqp-rx: The other escape sequences (\f, \0, etc.) can stay, though.
15:15 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/1​8c5d12b9b056f351d814710ca497fd89af459c7
15:15 dalek nqp-rx: 3ac0b79 | pmichaud++ | src/NQP/ (2 files):
15:15 dalek nqp-rx: Add \e quote_escape to NQP.
15:15 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/3​ac0b797bbb5c191ed8ef6abba25b216a1764883
15:17 dalek rakudo: 796c566 | pmichaud++ | docs/release_guide.pod:
15:17 dalek rakudo: Remove myself from the April release manager -- open for others.
15:17 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​96c566ff9fd39af68937c0c838171d254a7a123
15:41 dalek parrot: r45808 | petdance++ | trunk/t/src/basic.t:
15:41 dalek parrot: properly consted argv
15:41 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45808/
15:44 japhb ash_, I'm the guy to take a look at OpenGL header warnings.  Can you nopaste, plz?
15:44 ash_ sure
15:44 ash_ do you want the full output of the configure or just the messages?
15:46 ash_ http://paste.lisp.org/display/97988 is just the errors
15:50 japhb ash_, ah.  Looks like Apple decided to futz with their header formatting again.
15:50 japhb OK, can you tar up /System/Library/Frameworks​/OpenGL.framework/Headers/ please?
15:50 ash_ sure
15:50 japhb (er, and send it to me)
15:52 dalek rakudo: fe6ca94 | masak++ | docs/release_guide.pod:
15:52 dalek rakudo: [release_guide.pod] vacant slots more visually distinct
15:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/f​e6ca942b6fb6d3b357c8ea1cc46877e72a293fe
15:53 ash_ japhb: http://greaterthaninfinity.com/wp-c​ontent/uploads/2010/04/Headers.zip
15:53 ash_ if you need anything else, let me know
15:54 japhb What Mac OS release do you have?
15:54 ash_ 10.6.3
15:54 japhb thx
15:54 ash_ uname -a
15:54 purl Infobot 0.43.3 alpha (oznoid+#perl)
15:54 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
15:55 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
15:55 japhb Ah, what's your TZ?
15:56 ash_ US central
15:56 japhb OK, great.  I'll contact you this afternoon, most likely
15:56 fperrad_ joined #parrot
15:58 dalek rakudo: ba591c9 | masak++ | docs/release_guide.pod:
15:58 dalek rakudo: [release_guide.pod] one more slot
15:58 dalek rakudo: My commit and pmichaud++'s passed each other in mid-air. :)
15:58 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​a591c917d2c7e3596b5eea256178e5a01dc327e
15:59 rurban joined #parrot
16:02 theory joined #parrot
16:06 NordQ joined #parrot
16:16 NordQ joined #parrot
16:18 NordQ joined #parrot
16:20 zostay_ joined #parrot
16:24 NordQ joined #parrot
16:26 NordQ joined #parrot
16:28 NordQ joined #parrot
16:30 dalek TT #1562 closed by coke++: Silence Configure.pl warnings about ccwarn when the default compiler is ...
16:30 dalek TT #1562: http://trac.parrot.org/parrot/ticket/1562
16:33 brooksbp_ joined #parrot
16:34 dalek parrot: r45809 | coke++ | trunk/config/init/defaults.pm:
16:34 dalek parrot: Don't try to use ccwarn in this case, since it doesn't necessarily exist.
16:34 dalek parrot: doughera++ (TT #1562)
16:34 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45809/
16:37 NordQ joined #parrot
16:39 chromatic joined #parrot
16:42 Mokurai joined #parrot
16:46 NordQ joined #parrot
16:48 NordQ joined #parrot
16:49 NordQ left #parrot
16:55 Andy joined #parrot
17:01 Coke ccwarn could be schwern!
17:02 cotto_work joined #parrot
17:02 dalek parrot: r45810 | fperrad++ | trunk/runtime/parrot/library/TAP/Parser.pir:
17:02 dalek parrot: [TAP] small fix
17:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45810/
17:02 dalek parrot: r45811 | fperrad++ | trunk/runtime/parrot/library/TAP/Harness.pir:
17:02 dalek parrot: [TAP] put extra files in archive
17:02 dalek parrot: review: http://trac.parrot.org/parrot/changeset/45811/
17:04 joeri joined #parrot
17:10 cotto_work ouch: http://www.google.com/search?q=site:pastebi​n.com+%22-----BEGIN+RSA+PRIVATE+KEY-----%22
17:11 fperrad joined #parrot
17:11 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?
17:12 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
17:14 darbelo Why steal dad's credit card when you can just google it?
17:15 Mokurai1 joined #parrot
17:17 fperrad_ joined #parrot
17:19 cotto_work anyone feel like adding a deprecation notice for some runcores?
17:21 particle sure would be nice to know which ones to deprecate first
17:21 particle has anyone looked at the source/config? the comments i've seen seem uninformed
17:22 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?
17:22 darbelo Slow is only the default due to a bug in fast IIRC.
17:23 darbelo Or that's teh impression I got from chromatic's comments on it.
17:24 chromatic Exactly.
17:24 particle ok, so let's deprecate the stable one in favor of the buggy one.
17:24 particle or, don't deprecate slow until fast works.
17:25 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.
17:25 particle i thought gc/debug cores were based on slow.
17:26 particle i'm not comfortable deprecating our default core
17:26 particle we can't prove stability of fast core until it's default
17:26 particle we can deprecate slow in 2.6
17:26 particle if fast is fixed before, say, 2.4
17:26 particle ...and made default.
17:27 alexn_org joined #parrot
17:27 Coke particle: you should probably voice your objection on the mailing list.
17:28 chromatic Deprecating slow makes no sense to me either.
17:28 chromatic It's ~20 lines of code.
17:28 particle right
17:29 particle Coke: will do, just want to get feedback on this higher-bandwidth communication channell first
17:38 mj41 joined #parrot
17:38 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 Coke well, not much.
17:38 purl same here, dude
17:39 * 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 #parrot
17:40 cotto_work (which is great *if* the extra runcores provide some benefit)
17:41 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.
17:44 cotto_work no need to guess
17:45 darbelo I don't care enough to benchmark :)
17:45 particle i do, it goes to rakudo adoption rates
17:46 particle can someone get benchmarks of the rakudo spectest suite on cgp vs default?
17:46 chromatic CGP doesn't compile with VS.
17:46 particle oh, believe me, i know that :)
17:46 chromatic I also don't believe Rakudo's performance is a Parrot issue.
17:46 particle still, it's a performance regression
17:47 chromatic What's a performance regression?
17:47 particle switching away from cgp on gcc builds needs to be justified
17:47 Andy joined #parrot
17:47 chromatic We don't use CGP on gcc builds.
17:48 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.
17:49 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.
17:50 japhb chromatic, I would presume that all three of the above have a half-decent GC as well ....
17:50 japhb Well, maybe not Tracemonkey.
17:50 japhb Just based on how big my damn browser gets after a few days.
17:51 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.
17:51 japhb (I was (mostly) kidding, anyway)
17:51 chromatic NQP generates inefficient code for Rakudo, and I think plenty of Rakudo is inefficient as well.
17:51 zostay_m joined #parrot
17:51 japhb nodnod
17:52 japhb Did the GSoC for NQP optimization get approved?
17:52 cotto_work japhb: you mean past?
17:52 japhb or PAST, I suppose.  Same effect.
17:52 chromatic As far as I know, approvals are still underway.
17:53 cotto_work I think the final decisions will be made today and announced on the 21st.
17:53 japhb cotto_work, ah, thanks.
17:54 particle decisions are announced on the 21st
17:54 particle they are not made today
17:55 particle the deduplication period has begun today. tpf has no duplicates
17:55 particle (as far as i'm aware, from the webapp view i have)
17:55 mj41 joined #parrot
17:56 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
17:56 cotto_work yeah.  I'm wondering abiout the status of those
17:56 bubaflub they said it would be easier this way than having to move an application
17:56 darbelo Duplication means 'accepted nyt two orgs' not 'submitted to two orgs' IIRC
17:57 darbelo *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.
17:58 * darbelo objects to being called a 'dupe'
17:58 darbelo ;)
17:58 particle bubaflub: i'll recheck the webapp then
17:58 japhb heh
17:58 bubaflub i also submitted a number of proposals to a few different orgs
17:59 Coke chromatic: I'd be curious to see if allowing more non-PMC registers further up the food chain would be helpful.
18:00 Coke I will try to fire up the profiling core on rakudo or partcl this week and see if anything jumps out.
18:01 particle rakudo inefficient? but it's written in perl 6!
18:01 Coke (which is non-sequitor to my previous send.)
18:01 chromatic I've offered to make primitives work for lexicals a few times, but pmichaud and jnthn said "Not yet".
18:01 chromatic 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.
18:02 particle yes, native typed variable support isn't required for r*
18:02 Coke I thought vivify etc. were used.
18:02 chromatic I could be wrong, but I don't think they are.
18:02 particle no, that's still todo
18:02 japhb I'm guessing NQP has not been receiving a lot of love this year in general.
18:02 japhb (calendar year, I mean)
18:03 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.
18:04 Coke you're right, no vivify yet.
18:04 Coke I'll see about that this week too.
18:05 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 japhb (Just my impression from the outside)
18:06 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 #parrot
18:07 chromatic I am.
18:07 Coke in any case, I have commit bits on nqp-rx.
18:07 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 #parrot
18:08 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.
18:08 chromatic The constant whining and berating grates on me, though.
18:09 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.
18:10 chromatic I also fixed a handful in Rakudo.
18:10 chromatic Yes, Parrot's garbage collector has some awful behavior in a couple of conditions, and it needs to find free memory much more cheapy.
18:10 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.
18:10 pmichaud 17:51 <chromatic> NQP generates inefficient code for Rakudo, and I think plenty of Rakudo is inefficient as well.
18:10 pmichaud any particular inefficiencies we should be targeting?
18:11 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.
18:11 pmichaud vivify doesn't really make a big speed improvement.
18:11 chromatic pmichaud, I suspect that preemptive error-handling code could be expensive.
18:11 Coke no, but it's on the list and is something I couldc concevably do. =-)
18:12 pmichaud chromatic: I don't quite understand "preemptive error-handling code"
18:13 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.
18:14 pmichaud Or, if it does, I'm totally ignorant of it.
18:16 chromatic I'm happy to run an NQP benchmark and explain what I think I see.
18:16 pmichaud That would be welcome.
18:16 chromatic Any recommendations on representative code?
18:17 pmichaud NQP itself would be one.  :-)
18:19 chromatic How do I run it?
18:19 chromatic Bootstrap mode, I mean.
18:19 pmichaud oh, for a benchmark.
18:19 chromatic Right.
18:19 pmichaud "make stage1" gives some representative commands.
18:20 pmichaud might need to touch a file somewhere though.  hmm.
18:20 chromatic From the github checkout?
18:20 pmichaud yes.  Actually, perhaps I can come up with a better benchmark.
18:20 pancake joined #parrot
18:21 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
18:21 pmichaud "make stage2" creates the stage2 compiler using the stage1 compiler
18:22 pmichaud either of those stages has a number of useful "build a component of nqp" commands that could be benchmarked
18:34 dalek winxed: r443 | julian.notfound++ | trunk/winxed.winxed:
18:34 dalek winxed: WINXED_PATH environment var to locate stage pbc files
18:34 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=443
18:36 chromatic pmichaud, autoboxing strings into String PMCs is fairly expensive.
18:38 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.
18:39 pmichaud have a quick example?
18:39 pmichaud (and my previous comment stands -- I think it happens when a string needs to go into a lexical)
18:40 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
18:40 pmichaud which means it needs to be a PMC.
18:42 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 #parrot
18:42 pmichaud Primitive lexicals will help *if* we know that the value can safely be held as a string register.
18:42 pmichaud that works for NQP subs, but very few subroutines in Perl 6 are going to be written as    sub foo(str $x) { ... }
18:42 chromatic Right.
18:43 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 pmichaud instead of boxing a new PMC on each invocation.
18:44 pmichaud 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:45 pmichaud same would hold true for integer, float, and other constants
18:48 iblechbot joined #parrot
18:49 pmichaud (primitive lexicals) and actually, I guess it would have to be written   sub foo($x as str) { ... }
18:49 pmichaud because the first would limit mmd dispatch
18:50 pmichaud although that doesn't seem quite right either, because it doesn't constrain $x to be a str
18:53 Coke smolder failure.
18:59 dalek winxed: r444 | julian.notfound++ | trunk/winxed.winxed:
18:59 dalek winxed: fix command line options checks
18:59 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=444
19:02 chromatic The vtable override performance improvement to Parrot will help NQP a fair amount.
19:09 muixirt pmichaud: is there any chance that functions like '!cursor_start' in ext/nqp-rx/src/stage0/Regex-s0.pir can be simplified?
19:10 ash_ joined #parrot
19:18 dalek winxed: r445 | julian.notfound++ | trunk/winxedst (2 files):
19:18 dalek winxed: new predef function 'cry' ('say' to stderr)
19:19 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=445
19:19 Coke muixirt: which part do you think can be simplified?
19:19 Coke (it's only about 22 lines...)
19:21 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:22 Coke I don't see any obvious optimizations.
19:22 muixirt Coke, but i don't have a clue
19:22 Coke avoiding the method call might help.
19:24 Coke on that note, I see a lot of method calls that just return an attribute.
19:24 Coke I would if removing the method calls and just doing the getattribute there would help.
19:25 Coke (get + set)
19:26 Coke (that's not an algorithmic issue like the one chromatic was expecting, but might be a practical change regardless.)
19:28 cotto_work One glaring error I've noticed is that the parrot executable doesn't respond properly to --halp
19:31 pmichaud 19:24 <Coke> I would if removing the method calls and just doing the getattribute there would help.
19:31 pmichaud 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 #parrot
19:32 pmichaud !cursor_start is the way that we create a new cursor to keep track of a new (sub)match
19:32 pmichaud PAST::Regex is designed so that it's possible to inline that method.
19:37 Coke pmichaud: yah, it's not ideal from an API perspective. just curious to see if it's a speed boost.
19:38 Coke (and if so, let's make method calls faster.) - but I don't know if recent PCC work has improved the situation here.
19:39 chromatic Some.
19:39 pmichaud I can likely inline that code, yes.
19:39 Coke ah, you could keep the methods as a fallback and inline their invocations for internal use. =-)
19:39 pmichaud right
19:39 pmichaud that's what I meant.
19:39 Coke evil but fast!
19:40 Coke er.
19:40 Coke faster.
19:40 pmichaud the method needs to stick around, definitely.
19:40 pmichaud but the hotpath at the beginning of generated rules could be inlined.
19:40 Coke if no one gets to it, that's definitely something within my skill level. =-)
19:41 chromatic What's the ratio of removed calls to total calls?  An estimate is fine.
19:41 pmichaud don't know that one
19:41 pmichaud I suspect it's smallish.  there are a lot of method calls.
19:42 pmichaud but every subrule invocation results in a call to !cursor_start
19:43 pmichaud I think I can get rid of the internal call to .HOW, too.
19:44 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)
19:45 Coke it might slow down compilation fractionally, but not the runtime.
19:45 pmichaud right.  and this isn't dynamic compilation.
19:46 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
19:47 pmichaud 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. =-)
19:47 Coke pmichaud++
19:47 pmichaud I'm also going to bump PARROT_REVISION and make sure nqp is working with latest parrot
19:49 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.
19:50 pmichaud I'm about to fix the CodeString one, though.
19:50 pmichaud I think the other changes should perhaps wait until after tomorrow's release.
19:50 moritz pmichaud: ok
19:50 moritz pmichaud: if you want me to pick any LHFs once you decided, just let me know
19:51 pmichaud moritz: will definitely do so.
19:51 Coke What's up with Codestring?
19:51 pmichaud right now nqp-rx forces all string targets to be instance of CodeString
19:51 pmichaud that's great if you're parsing code, not so great if you're expecting a Perl 6 Str
19:51 Coke Yah, PO String seems safer there.
19:51 dalek nqp-rx: 7662467 | pmichaud++ | src/Regex/Cursor.pir:
19:51 dalek nqp-rx: Remove 'pos' register fossil noticed by muixirt++ .
19:51 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​662467981beb7c0836e60830a079d636eb119fc
19:52 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:53 pmichaud an interesting question is:    123 ~~ /\d+/;   say $/.orig.WHAT  #  Int?
19:53 moritz if you can have it that way (efficiently)
19:53 pmichaud well, I might keep the original value as $!orig but cache the stringified target somewhere
19:54 pmichaud this is a place where being able to store native strings as object attributes could be very efficient
19:54 pmichaud (so that we don't have to box into a stirng)
19:54 pmichaud *string
19:55 Coke String? =-)
19:55 pmichaud did the "install-dev" target disappear?
19:56 mberends joined #parrot
19:56 moritz pmichaud: it's included in 'make install' by default
19:56 moritz and the old 'install' becaume 'install-bin' or so
19:56 pmichaud hmmm.  with latest parrot, "make install" isn't.
19:56 pmichaud (when run from nqp-rx's --gen-parrot option)
19:56 moritz it should - bug when not (IMHO)
19:57 pmichaud hmm, something else deeper seems to be going on
19:57 pmichaud just a moment
19:57 Coke pmichaud: is something missing from the install or is the whole thing failing?
19:57 pmichaud whole thing failing
19:57 Coke (I use parrot's make install several times a week on my dev box.)
19:58 pmichaud I'll watch more closely this time
19:58 pmichaud oh, it's not able to "make" at all from the script.
19:58 pmichaud it runs parrot's Configure okay, but then fails on the 'make'
19:58 Coke build borked?
19:59 pmichaud worked fine with earlier versions of Parrot
19:59 pmichaud I'll start over
19:59 Coke r45811 was ok here.
20:01 pmichaud aha
20:01 pmichaud looks like config_lib.pasm changed to config_lib.pir
20:01 moritz aye
20:01 mberends Can Parrot reveal its Process_ID? Rakudo is faking with a 0 and claiming a success because of a buggy test.
20:01 pmichaud afaik Parrot doesn't reveal PIDs yet.
20:02 mberends :-(
20:02 Coke it /might/ be available on the interpreter.
20:02 Coke checking...
20:02 dalek TT #1563 created by mikehh++: Deprecation of unused runcores
20:02 dalek TT #1563: http://trac.parrot.org/parrot/ticket/1563
20:03 Coke mberends: http://github.com/partcl/partcl/bl​ob/master/runtime/builtin/pid.pir - macro hell, but there's my cheat.
20:03 mberends thanks Coke
20:04 Coke np. hope it helps.
20:04 pmichaud basically calling dlfunc to grab getpid() from the C lib?  Evil.  :-)
20:05 mberends Coke: it may be OS dependent, not sure if Win32 would support it.
20:06 mberends 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:07 Coke mberends: it's deprecated on windows but still there. I think.
20:07 Coke (_getpid) is preferred, says the google.
20:07 mberends ah. Coke++
20:14 hercynium joined #parrot
20:14 dalek nqp-rx: 72d4125 | pmichaud++ | build/ (2 files):
20:14 dalek nqp-rx: Bump PARROT_REVISION to latest Parrot, and switch Parrot's
20:14 dalek nqp-rx: config_lib.pasm to be the new config_lib.pir .
20:14 dalek nqp-rx: review: http://github.com/perl6/nqp-rx/commit/7​2d41258fd2aeb30e7f7e21a814eb5c30b2bebdd
20:16 dalek rakudo: 346e76d | (Martin Berends)++ | t/spectest.data:
20:16 dalek rakudo: [t/spectest.data] remove S02-magicals/pid.t (1 test) because is was crashing instead of passing and $*PID is NYI
20:16 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​46e76db0f23c331281fc630476c3681abc974d3
20:17 Coke pmichaud: (config_lib.pir) ugh. I didn't even think to check that when the change was made.
20:17 Coke rakudo will no doubt need the same fix.
20:18 Coke (as will partcl-nqp)
20:18 moritz Coke: it already has (rakudo)
20:18 Coke ooh, I think I just sweet talked my employer into a yapc donation.
20:18 Coke moritz: I just did a pull and didn't see it.
20:19 moritz Coke: a8e70acdf61589f29f80d7b840f8c06e7aa5f483
20:19 moritz bump PARROT_REVISION, and change config_lib from .pasm to .pir
20:19 Coke moritz: ... these aren't the droids I'm looking for. You can go about your business.
20:32 GeJ Good morning everyone.
20:38 brooksbp_ joined #parrot
20:41 Andy joined #parrot
20:54 * bacek yawns
20:54 bacek Good morning, humans
20:55 GeJ G'Day bacek.
20:55 bacek G'Day GeJ
21:00 rurban_ joined #parrot
21:05 Andy joined #parrot
21:08 Whiteknight joined #parrot
21:13 pancake now's the release status?
21:29 Coke you mean "how" ?
21:42 GeJ make fulltest PASS FreeBSD/amd64 on trunk@45811
21:52 particle joined #parrot
21:54 mmcleric joined #parrot
21:57 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:58 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:59 Coke I think the biggest issue is where to put it.
21:59 Coke 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. =-)
21:59 Coke (er, generic trac ticket)
22:00 mberends heh, ok
22:26 davidfetter joined #parrot
22:35 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:39 darbelo alexn_org: You got cut off after "emphasised on performance, and it's"
22:43 alexn_org ... and it's OK ... but do you have plans for a tracing JIT? ... I also think http://parrot.org/dev needs a section with relevant documentation on Parrot's implementation (like http://code.google.com/p/unlade​n-swallow/wiki/RelevantPapers)
22:43 alexn_org :)
22:43 hercynium joined #parrot
22:44 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.
22:46 cotto_work Lorito will open a large number of optimisation possibilities.
22:47 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.
22:49 cotto_work 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.
22:49 Tene We've been aware of where we want to be for quite a while now.
22:50 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.
22:50 Whiteknight performance is an area where we increasingy need to focus
22:50 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 #parrot
22:51 cotto_work We do intend to make Parrot a good production HLL compiler toolset and runtime.  It's just not there yet.
22:52 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:53 darbelo docs/book/ in the parrot svn tree can serve as an itroduciton to the vm.
22:54 darbelo http://docs.parrot.org/parrot/latest/html/ if you like your docs with more eye-candy ;)
22:57 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:58 cotto_work The design of Lorito is partially inspired by the Squeak Smalltalk implementation.
23:01 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:02 GeJ I seem to remember that someone pointed to another language recently wrt very limited number of ops to start with.
23:03 cotto_work GeJ, other than Smalltalk or Inferno's VM?
23:04 GeJ I think so.
23:12 GeJ Wasn't it Alan Kay's COLA?
23:13 GeJ http://lambda-the-ultimate.org/node/2483
23:14 GeJ "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:15 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:16 muixirt GeJ: Cola was mentioned some time ago in the wiki http://trac.parrot.org/parrot/wiki/Languages
23:16 darbelo That's also a different Cola.
23:17 GeJ Ah! chromatic mentionned it here : http://irclog.perlgeek.de/p​arrot/2010-04-06#i_2203396
23:20 dalek TT #1564 created by mberends++: expose a getpid library function for Rakudo $*PID and other languages
23:20 dalek TT #1564: http://trac.parrot.org/parrot/ticket/1564
23:22 tcurtis joined #parrot
23:24 mberends (more than half the search results for PID in trac were in the word 'stupid' :)
23:31 dalek rakudo: 35bcd52 | jonathan++ |  (9 files):
23:31 dalek rakudo: 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 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​5bcd522471cfade800d4e28c0039128367107b3
23:31 dalek rakudo: ba19436 | jonathan++ | t/spectest.data:
23:31 dalek rakudo: Turn on hash_ref.t.
23:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​a1943626e144dfbd7d8e96b2e64472be048419d
23:42 tcurtis_ joined #parrot
23:48 Andy joined #parrot

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

Parrot | source cross referenced