Camelia, the Perl 6 bug

IRC log for #parrot, 2009-11-10

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 * Whiteknight just updated his kernel, hopes ubuntu becomes slightly more stable
00:01 Whiteknight I've spent the last 45 minutes trying to get online
00:01 darbelo Ubuntu != stable
00:01 cotto_work wb
00:02 |kesselhaus| joined #parrot
00:03 Whiteknight 9.04 was very stable, and I loved it
00:03 Whiteknight the 9.10 upgrade was a little more rocky
00:03 Whiteknight I'm fine with it though, I did adopt it pretty early. I know the risks to a major update like that
00:04 Whiteknight so I'm not upset, I'm just going to do what I need to do to get it working again
00:07 NotFound Whiteknight: for me upgrading to 9.10 has been easier than to 9.04
00:07 NotFound And it solved some pitfalls
00:07 Whiteknight 9.04 was 100% smooth for me. No problems whatsoever
00:07 kid51 joined #parrot
00:08 NotFound Whiteknight: an example: changing the wallpaper from the control center never worked for me. Failed silently.
00:09 plobsing joined #parrot
00:09 NotFound And the same for changing kdm settings.
00:09 NotFound Well, maybe is just kubuntu
00:10 Whiteknight i've been on gnome for a few years now
00:11 NotFound I originally installed ubuntu, but later installed the kubuntu packages, and later uninstalled the gnome ones.
00:11 NotFound Is a mutating system X-)
00:12 darbelo In my experience, ubuntu doesn't handle mutations gracefully.
00:12 NotFound Well, not exactly, in my newest laptop I don't installed it, it comes preinstalled.
00:13 Whiteknight I got ubuntu at 8.04, have upgraded early every release, and this is the first time I've had problems
00:13 Whiteknight so I'd say I'm very very happy with it
00:14 dukeleto my cow-orker upgraded ubuntu today and got bit by libc issues
00:14 dukeleto evidently the new libc shenanigans no longer work on older dell desktops, which is quite unfortunate
00:14 darbelo "libc issues" ?
00:15 Whiteknight I am only bothered by problems that don't get attention. I can put up with any problem if I know people are actively working on it
00:15 Whiteknight so I don't mind a few headaches after an upgrade
00:15 dalek tracwiki: v117 | jkeenan++ | WikiStart
00:15 dalek tracwiki: https://trac.parrot.org/parrot/wiki/W​ikiStart?version=117&action=diff
00:15 chromatic http://doc.cat-v.org/inferno/4t​h_edition/dis_VM_specification
00:15 chromatic http://doc.cat-v.org/infern​o/4th_edition/dis_VM_design
00:15 dukeleto darbelo: libc was forked recently, because the guy who maintains it is not working with people. the libc is going through a schism right now
00:16 darbelo Ah, yes. Godd ol' mr. Drepper, right?
00:16 dalek parrot-plumage: 79842ba | japhb++ | :
00:16 dalek parrot-plumage: Move Glue.pir's exists() and keys() to Util.nqp's .exists and .keys; fix...
00:16 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/79842babe7dcacfdefe8f3c57783e38509562e7b
00:19 dalek TT #1255 created by jkeenan++: fix PARROT_EXPORT visibility=default for gcc other than 4.x
00:20 kthakore chromatic: do you has unix?
00:20 pmichaud japhb: there's not a way to get to PIR's keyed syntax, sorry.  That's one of those "features" that makes things a bit more difficult for compilers :-|
00:20 kthakore chromatic: hi btw ..
00:20 japhb pmichaud, understood
00:20 kthakore anyone got access to a unix box with display?
00:21 * kthakore needs testing done ... oh well
00:21 kthakore oh well
00:21 kthakore gym time
00:21 japhb pmichaud, I see that I forgot to put try and /or CATCH on Plumage Requests.  Do they already exist, or should I add them to the list?
00:22 pmichaud add to list.
00:22 pmichaud try can come quickly... CATCH I'm not so sure yet :-)
00:22 japhb pmichaud, roger dodger
00:22 pmichaud afk, dinner
00:23 japhb added.
00:26 mikehh joined #parrot
00:29 dalek TT #1256 created by jkeenan++: src/pmc/class.pmc:  Need a pluggable MRO in instantiate() PMC
00:33 dalek parrot: r42392 | jkeenan++ | trunk/src/pmc/class.pmc:
00:33 dalek parrot: Change an RT # to a TT #.  Remove references to closed RT tickets.
00:33 purl dalek: that doesn't look right
00:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42392/
00:42 szabgab joined #parrot
00:52 darbelo left #parrot
00:52 dalek TT #1257 created by jkeenan++: src/io/utf8.c:  Does the amount read in Parrot_io_read_utf8() need to be ...
00:53 dalek parrot: r42393 | jkeenan++ | trunk/src/io/utf8.c:
00:53 dalek parrot: Change an RT # to a TT #.
00:53 purl dalek: that doesn't look right
00:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42393/
00:56 dalek TT #1258 created by jkeenan++: Method cache not always invalidated
00:58 Zak joined #parrot
01:02 dalek TT #1259 created by jkeenan++: src/debug.c:  Correctly handle comparisons of PMCs with constants
01:02 kid51 There are no longer any tickets in RT owned by 'nobody'.  All 30 remaining RT tickets have owners.
01:03 kid51 And with that ...
01:03 dalek parrot: r42394 | jkeenan++ | trunk/src/debug.c:
01:03 dalek parrot: Change an RT # to a TT #.
01:03 purl dalek: that doesn't look right
01:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42394/
01:03 * kid51 rests
01:03 abqar joined #parrot
01:20 pmichaud 22:12 <bacek_at_work> japhb, for performance reason. You can avoid second symbolic lookup during iteration
01:21 pmichaud fwiw, I don't quite understand this comment.
01:21 pmichaud (and would like to understand it better.)
01:21 bacek_at_work pmichaud, $S0 = shift it; $P1 = hash[$S0].
01:21 bacek_at_work hash[$S0] is symbolic lookup.
01:22 pmichaud and you're saying that
01:22 bacek_at_work We have to calculate new hashvalue, iterate over buckets, etc.
01:22 pmichaud $P0 = shift it
01:22 pmichaud $P0.value
01:22 pmichaud is faster?
01:22 bacek_at_work yes
01:22 jonathan lol
01:22 pmichaud ...but I've been told recently that PCCMETHODS are incredibly slow
01:22 pmichaud wehreas  hash[$S0]  is a vtable method
01:22 jonathan bacek_at_work: I highly doubt it.
01:22 jonathan For the reasons pmichaud just mentioned.
01:23 pmichaud I'd like to see a performance comparison.
01:23 jonathan $P0.'value' creates probably two gcables.
01:23 jonathan At least.
01:23 jonathan (The CallSignature and the returns thingy)
01:24 pmichaud In fact, I've been told recently that PCCMETHODS can consume almost all of the benefit that might come from implementing a given function in C
01:24 jonathan hash[$S0] creates none.
01:24 pmichaud (obviously depends on the function, but still, that it's a huge amount of overhead)
01:24 jonathan In fact, looking up the method to call involves a lookup in a hash. :-)
01:24 pmichaud lol
01:25 pmichaud via the vtable method
01:25 jonathan Right
01:25 pmichaud *snicker*
01:25 jonathan So I think by definition you *have* to be doing more work!
01:25 pmichaud okay, I think I understand now.
01:25 pmichaud thanks.
01:26 chromatic What's your new understanding, pmichaud?
01:27 jonathan Full marks for another refactor that's probably made Parrot slower again though. :-/
01:30 diakopter it if did call itself, it'd loop forever...
01:30 pmichaud what jonathan said.
01:30 diakopter oh, you're saying two hash lookups instead of 1
01:30 pmichaud diakopter: we're saying that instead of a hash lookup, we now have a hash lookup (in a different hash) and a PCCMETHOD call
01:31 diakopter ok; thnx
01:33 jonathan left #parrot
01:36 Whiteknight the pcc refactor has dividends yet to pay
01:36 pmichaud Whiteknight: I seriously look forward to those.  See my latest message to parrot-dev.  :)
01:37 Whiteknight when did you send it?
01:37 pmichaud last week
01:37 pmichaud on thursday morning
01:38 Whiteknight oh, okay. I have that one
01:38 pmichaud "things parrot can do to help rakudo".   #1 was finish reaping dividends from the pcc refactor
01:39 kiwichris I have found the PDD "Embedded and Extending Parrot. Nice. Is there more I may have missed ?
01:40 Whiteknight chromatic: is there any progress on the CallSignature + Context merger?
01:41 chromatic bacek stalled wondering which part of the code has the responsibility of creating the merged PMC.
01:41 chromatic I suggested he start a writeup on the wiki where we can resolve the questions.
01:41 Whiteknight ah, that is a good question
01:41 plobsing kiwichris: there's a bit more under various pages at http://docs.parrot.org/parro​t/latest/html/developer.html
01:42 kiwichris plobsing, thanks.
01:43 kiwichris I want to understand the constraints the VM when embeddeding. For example can I have more than one intrpt running in different thread active ?
01:44 chromatic Yes.
01:44 chromatic By design, interpreters should never interfere with each other.  In practice, there may be bugs that we need to fix.
01:45 kiwichris My concern is exit(3) being called.
01:45 kiwichris It stops everything.
01:45 kiwichris Sorry to be a pain and head back to this topic.
01:46 Whiteknight the exit opcode calls the exit() libc function
01:46 Whiteknight so yeah, that's a bit of a problem
01:48 kiwichris Another one. If I start an interp and it exits, with my RTEMS specific exit path and avoids libc exit, can I start a new interp and it should run ?
01:51 chromatic Yes.
01:51 chromatic I recommend starting a parent interpreter, then creating children of that interpreter and running code in them though.
01:51 kiwichris Great. I getting an assert in pt_add_to_interpreters. I will take a look. Should I raise a ticket with the details ?
01:53 kiwichris chromatic, the RTEMS shell is just a thread that can run parrot. I am not sure how the parent/child interp model works.
01:54 chromatic It's sort of like the init process model on Unix.
01:54 chromatic Every interpreter has a parent interpreter, except for the first interpreter which has no parent.
01:54 chromatic If you want to create a new interpreter, it needs a parent.
01:55 kiwichris chromatic, interesting. So I do a new but do not call runcode ?
01:57 chromatic Exactly.
01:57 kiwichris chromatic, then I create a child and a thread and let that thread call runcode ?
01:57 chromatic Yes.
01:58 eternaleye joined #parrot
01:58 kiwichris chromatic, nice. I like this. It is a sort of embedded fork.
01:58 elmex joined #parrot
01:59 kiwichris chromatic, does runcode ever return ?
01:59 kiwichris chromatic,  when run as a child ?
02:00 chromatic Yes, when the code run ends.
02:00 kiwichris chromatic, many thanks. I will wander away and play with this.
02:02 s1n joined #parrot
02:03 chromatic If you look at the source code for Parrot::Embed in the Parrot distribution, you'll see similar embedding.
02:03 chromatic There's a file called Embed.xs which creates a parent interpreter at the start and uses it as the parent for all subsequent interpreters.
02:04 integral joined #parrot
02:06 plobsing I fixed the libjit_framebuilder nci.t problems on i386 on the weekend. What do I need to do before it can be merged?
02:08 chromatic If kid51 and Whiteknight have looked over it and approve of their respective parts, we'll discuss it in #ps tomorrow and it should be good.
02:08 Whiteknight I looked at it last week, need to check again
02:24 Whiteknight okay, how do I get libjit?
02:24 Whiteknight I thought I had it on my system, but I don't seem to see it now
02:25 plobsing ftp://ftp.gnu.org/gnu/dotgnu/libjit/
02:26 Whiteknight there it is
02:29 chromatic No Ubuntu packages; you'll have to make a .deb with checkinstall.
02:30 plobsing is there somewhere I can request a package for ubuntu? not being packaged makes installation a pain.
02:32 chromatic No idea; good question.
02:34 diakopter http://bugs.debian.org/cgi-b​in/bugreport.cgi?bug=514063
02:35 diakopter as debian, so ubuntu
03:07 dalek parrot-plumage: aa58298 | japhb++ | :
03:07 dalek parrot-plumage: [plumage] Remove hack for old NQP
03:07 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/aa58298f9006a42ea79c2508049f36f3e9bba212
03:07 dalek parrot-plumage: 88e52c3 | japhb++ | :
03:07 dalek parrot-plumage: [TESTS] Test cleanup, stage 1: Refactor MAIN(), git rid of ARGS and G:PI...
03:07 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/88e52c35ca0ca150a2b6c4342f9fd407a0ec2126
03:07 dalek parrot-plumage: 2c2e0a4 | japhb++ | :
03:07 dalek parrot-plumage: [TESTS] Test cleanup, stage 2: Add 01-sanity.t to test testing framework
03:07 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/2c2e0a41797ced78da01ee916cc9d63f60fd93ad
03:07 dalek parrot-plumage: 8303084 | japhb++ | :
03:07 dalek parrot-plumage: [TESTS] Test cleanup, stage 3: Rename glue.t -> 02-glue.t, util.t -&g...
03:07 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/83030843b41a64579e16bac64f02fab766d1b02d
03:10 dukeleto wow, japhb++ is on a roll
03:10 japhb indeed.  :-)
03:11 dukeleto japhb: nice refactoring. i dig it
03:11 japhb dukeleto, thanks!  :-)
03:12 * japhb is currently filling in 03-util.t to improve coverage of Util.nqp
03:13 dukeleto i have still been thinking of how to make the harness not depend on Util.nqp
03:13 dukeleto is it evil to inline slurp() and rx() in the harness?
03:14 japhb Hmmm.  I think rx() may be able to go away once we have the P6Regex happy place.  I'll think about slurp() when I'm done with current task.
03:15 japhb (P6Regex happy place is blocked on lack of continuable matches in NQP-rx at the moment.)
03:16 japhb dukeleto, if you haven't been watching it, pmichaud and I have been doing low-friction task management for NQP-rx here: http://wiki.github.com/per​l6/nqp-rx/plumage-requests
03:27 hercynium_ joined #parrot
03:31 dukeleto japhb: yes, i have taken a look at plumage-requests, but i will again, since it seems that you two have been burning the candle at both ends lately
03:32 japhb dukeleto, yeah, making up for health problems the last few weeks
03:35 janus joined #parrot
03:37 Essobi_ joined #parrot
03:39 cotto why does plumage need float support?
03:41 JimmyZ joined #parrot
03:41 japhb cotto -- will be used for user interface stuff.
03:44 Andy joined #parrot
03:46 dalek parrot-plumage: 5a3959b | japhb++ | :
03:46 dalek parrot-plumage: [CORE] Util.nqp: Add missing SYNOPSIS entries
03:46 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/5a3959b5c515fa90f503cc78be207539e733d3cf
03:46 dalek parrot-plumage: 8101383 | japhb++ | :
03:46 dalek parrot-plumage: [TESTS] Fill out hash method tests in 03-util.t
03:46 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/8101383dd9542e74ccbb578a75076497cba4e845
03:55 japhb ... and with this next push, time to take a break.
03:56 pmichaud purl message bacek I apologize for some of my earlier comments and remarks about HIK performance; upon reflection my statements were likely more condescending than deserved.  I shall try to be more constructive with my comments in the future.
03:56 purl Message for bacek stored.
03:56 pmichaud thanks, purl
03:57 dalek parrot-plumage: dec4bd5 | japhb++ | :
03:57 dalek parrot-plumage: [TESTS] 03-util.t: Add tests for set_from_array()
03:57 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/dec4bd5adf5ebf58ee379533b5cedb9c3949ff65
04:02 kurahaupo joined #parrot
04:12 pdcawley__ joined #parrot
04:18 kid51 joined #parrot
04:32 pdcawley_ joined #parrot
04:59 nopaste joined #parrot
05:02 bacek_at_work pmichaud, no worries. https://trac.parrot.org/parrot/wiki/ParrotQuote​s?action=diff&amp;version=14&amp;old_version=13 :) (And perfectly accept same in my address)
05:05 kurahaupo ping bacek ?
05:05 purl I can't find bacek in the DNS.
05:08 kurahaupo Is doesn't work; should it? $P0 = new 'Integer' ; $P0 = .MIN_INT ; neg $P0 ; $S0 = typeof $P0 ; is($S0, 'BigInt', 'promotion worked')
05:08 kurahaupo s/Is/This
05:09 chromatic I don't know if we perform overflow detection with neg wraparound.  We probably should.
05:09 kurahaupo We do (so far) for add & sub...
05:11 bacek_at_work kurahaupo, there is no VTABLE_neg in Integer. So it uses Scalar.neg, which doesn't check for overflows. I agree with chromatic, we should check it.
05:12 chromatic Except that neg_i_i can't autopromote.
05:14 bacek_at_work I think it should throw exception than
05:15 kurahaupo It seems like we have a problem. Is an Integer PMC simply a Box in which to put an INTVAL, with identical behaviour to an integer register ($I0 etc), or is it a "small version of BigInt" ?
05:15 kurahaupo I would argue for the former: if you *want* a BigInt, just ask for one.
05:15 chromatic I have no better idea than an exception.
05:16 kurahaupo So should Integer do *any* promotions at all?
05:16 chromatic I think so.
05:16 dukeleto kurahaupo: in which case?
05:16 kurahaupo (This is apropos converting t/pmc/bigint.t to PIR, BTW)
05:16 dukeleto kurahaupo++ # fellow soldier in the Perl->PIR test army
05:17 dukeleto kurahaupo: we need lots more tests for edge cases
05:17 kurahaupo The test suite appears to test autopromotion of addition (and subtraction also works). When I added tests for abs(MININT) and neg(MININT) they both failed.
05:18 chromatic Good, we can fix them then.
05:18 kurahaupo And the "correct" behaviour should be .... ?
05:19 * kurahaupo is leaning towards ripping out the autopromotion and throwing exceptions on all overflow cases
05:19 chromatic That simplifies the implementation, but won't that lead to bugs in certain cases?
05:19 chromatic Bugs of usage, I mean.
05:20 kurahaupo Exceptions are our friends
05:21 diakopter is this an error in PAST __dump: http://parrot.pastebin.com/f3f8bd543   line 30 is missing the var name?
05:22 chromatic Do you want to wrap every integer operation in an exception handler?
05:22 * kurahaupo screws up face with a *yuck* expression
05:24 dukeleto kurahaupo: min/max and friend have lots of bugs lurking near auto-promotion boundaries
05:24 kurahaupo I'm pretty sure we don't need to put an exception handler, say, around an integer iterator over a range where both endpoints are integers. IOW it's cheaper to check the values for prospective overflow, which can then be subject to CSE-type optimisation
05:25 kurahaupo Having checked them, you can be sure they won't overflow and trigger an exception.
05:25 kurahaupo You only blow up if your checking is faulty, which you probably want to know about.
05:26 kurahaupo We might conceivably want to add opcodes for "add-modulo-2^N" (N=32 or 64)
05:26 dukeleto floor and ceiling have lots of bugs/unspecc'ed behavior as well
05:27 dukeleto kurahaupo: that might be a nice candidate for a dynop
05:28 kurahaupo Don't floor & ceil just do whatever the FPU does?
05:29 * kurahaupo wonders why every time he starts looking at code, it's like upending a can of worms...
05:31 dukeleto kurahaupo: look at t/op/inf_nan.t
05:31 dukeleto kurahaupo: they are called "yak holes" and they are deep and wide
05:31 kurahaupo Back to bigint.t -- what should I assert as the "correct" behavour for abs & neg?
05:32 dukeleto kurahaupo: the hairiest yaks burrow into the earth and live in recursive underground dens of complexity
05:32 kurahaupo dukeleto: are those holes sort of like a TARDIS?
05:32 dukeleto kurahaupo: what is the $64,000 dollar question? i haven't backlogged
05:33 * dukeleto has given up on backlogging. i just jump in the river and start swimming
05:33 dukeleto kurahaupo: have you split the test file up?
05:33 dukeleto kurahaupo: into foo-old.t and foo.t ?
05:34 kurahaupo dukeleto: sounds like a good idea, which I've kindof done but probably not in the way you mean.
05:35 kurahaupo The 0.064 million dollar question is: given that "add" autopromotes an Integer PMC to a BigInt PMC, but neg and abs don't, how should I fix it? The old bigint.t tests for the former but not the latter.
05:37 chromatic Add TODO tests for the latter and we'll see how they look.
05:38 dukeleto kurahaupo: add tests, like chromatic says
05:38 dukeleto kurahaupo: if you want to write tests in PIR, svn copy a file called bigint-old.t, then make bigint.t the new, PIR tests
05:39 dukeleto kurahaupo: that way you don't have to translate all tests at once
05:39 dukeleto kurahaupo: t/op/inf_nan.t is a good example for how the PIR test should look
05:40 dukeleto kurahaupo: an then send an email to parrot-dev, giving the link of the trac ticket that the patch is attached to, and ask what the proper behavior should be
05:41 dukeleto then allow the proper amount of bike-shedding, and then make the tests Just Do The Right Thing That Everyone Agrees On
05:41 dukeleto easy, huh ?
05:41 kurahaupo piece of gateau.
05:42 kurahaupo I like the idea of introducing the PIR tests a few at a time -- I'm only at line 400 of 1200 so far; I hope nobody mods the file before I can get it checked in!
05:46 fperrad joined #parrot
05:49 dukeleto kurahaupo: we will hit them with a big stick
05:50 dukeleto kurahaupo: definitely submit a patch of what you have so far, so that we can tell you if you are on the right track
05:50 dukeleto kurahaupo: you can always overwrite the patch on the trac ticket with the newest version of the patch
05:51 dukeleto kurahaupo: incremental translation was needed, because nothing was getting done, since translating an entire file at a time is a huge undertaking
05:51 dukeleto kurahaupo: look for other *-old.t files for tests which need to be translated to PIR
06:07 bacek joined #parrot
06:09 bacek o hai
06:10 JimmyZ helloooooooooooo.
06:14 dalek parrot: r42395 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
06:14 dalek parrot: [distutils] pge allows multi source files
06:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42395/
06:27 JimmyZ whiteknight?
06:27 purl it has been said that whiteknight is mailto:wknight8111@gmail.com or the grand master funk or http://wknight8111.blogspot.com/
06:31 dalek parrot: r42396 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
06:31 dalek parrot: [distutils] step 'test' try first to run 'perl t/harness'
06:31 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42396/
06:37 TiMBuS joined #parrot
06:37 dalek parrot: r42397 | fperrad++ | trunk (2 files):
06:37 dalek parrot: [library] improve variable interpolation
06:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42397/
06:44 dukeleto bacek: good localtime()
06:44 dukeleto bacek: thanks for those links to realtime gc algorithms, there is really cool stuff going on there
06:45 dukeleto bacek: i am concerned that parrot on RTEMS will have to turn off the current gc to be actually real-time.
06:45 dukeleto bacek: but we can support a RTEMS-compatible real-time gc
06:48 mokurai1 joined #parrot
07:20 uniejo joined #parrot
08:17 mikehh joined #parrot
08:24 payload joined #parrot
08:24 Zak joined #parrot
08:26 payload joined #parrot
08:55 davidfetter joined #parrot
08:55 payload joined #parrot
08:57 payload1 joined #parrot
09:05 payload joined #parrot
09:10 payload1 joined #parrot
09:14 dalek parrot: r42398 | barney++ | trunk/NEWS:
09:14 dalek parrot: Went over the news for 1.8.0.
09:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42398/
09:18 AndyA joined #parrot
09:37 mikehh We are still failing t/src/warnings.t - test : 2 with --optimize on i386 and amd64 with both g++ and gcc- see TT #1187
09:38 mikehh I am getting testr failure as well
09:39 mikehh bbiab
10:54 payload joined #parrot
11:00 bacek dukeleto, we have to properly encapsulate our GC. Then we can provide RT version of it.
11:22 mikehh joined #parrot
11:46 dalek parrot: r42399 | fperrad++ | trunk/tools/dev/mk_language_shell.pl:
11:46 dalek parrot: [languages] now works with a Configure.pir or a setup.pir (distutils), instead of Configure.pl.
11:46 dalek parrot: lang.pir was split in 2 parts, and use the opcode 'load_language'.
11:46 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42399/
12:00 kid51 joined #parrot
12:02 kid51 libjit_framebuilder branch:  Have spotted one codingstd error.  Am in process of testing correction.  Otherwise, passes 'make fulltest' on Linux/i386 and Darwin/PPC.
12:06 payload joined #parrot
12:14 dalek parrot: r42400 | jkeenan++ | branches/libjit_framebuilder/config/g​en/libjit/frame_builder_libjit_c.in:
12:14 dalek parrot: Correct codingstd error:  c_indent.
12:14 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42400/
12:24 dalek TT #1232 closed by jkeenan++: t/src/warnings.t:  Test fails when Parrot built with g++ and --optimize
12:24 plobsing joined #parrot
12:25 nopaste joined #parrot
12:32 payload joined #parrot
12:52 cognominal joined #parrot
12:54 bluescreen joined #parrot
12:56 whiteknight joined #parrot
13:12 bluescreen joined #parrot
13:20 whiteknight good morning #parrot
13:21 plobsing morning whiteknight
13:21 whiteknight hello plobsing
13:21 whiteknight I wasn't able to get libjit installed and tested last night before bedtime
13:21 gaz joined #parrot
13:22 whiteknight I swore I already had it, but I must have lost it at some point
13:23 plobsing that's alright.
13:23 whiteknight no it's not. I should have done it earlier
13:28 plobsing so I've been thinking about lorito. If we specify the output of the parser as a tree, we can avoid specifying a language for it for the time being, and I can start hacking away at a prototype
13:28 plobsing with a throwaway language
13:29 whiteknight it's not just the output of the parser, lorito is supposed to be the way that ops are defined
13:29 whiteknight right now they are defined in C
13:29 plobsing lorito = ops defn + backend
13:29 plobsing (s)
13:29 whiteknight right
13:29 plobsing and I'm interested in hacking on the backend
13:30 whiteknight each lorito op should correspond in a trivial way to a jittable operation
13:30 whiteknight ok
13:30 whiteknight so are you talking about the output of the lorito parser?
13:30 plobsing yes
13:30 plobsing and I'll make a makeshift parser
13:31 whiteknight okay, but that's where I'm getting confused. if lorito is trivially simple, the output won't be a "tree"
13:31 plobsing but then it'll be a pain to write the ops.
13:31 plobsing and we want to expose as much of the VM as possible to the JIT, so it makes sense to define it in a structured language
13:32 whiteknight the more structure it has, the more parsing effort it takes to JIT it
13:32 plobsing there are already good examples of converting structured languages to JIT
13:32 whiteknight how structured are you talking? because ops are already written in C and that's far too high level to be JIT'd efficiently
13:32 plobsing not to mention, most JITs operate on a level similar to C operations (eg: store this in such and such an array)
13:33 whiteknight we would basically need to write a whole C parser just to do JIT at runtime
13:33 ruoso joined #parrot
13:34 plobsing um. no. the JIT is free to store the information about jittable things *in a way that is most conveniant to that JIT*
13:34 plobsing so, for llvm, that would be .bc files
13:34 whiteknight okay, so that's where my thought process is derailed
13:34 plobsing how so?
13:35 whiteknight we have .ops files (Written in some language X), gets converted to the JIT-native format at build time, and then the JIT assembles those building blocks together at runtime?
13:35 plobsing that's what I thought we were doing all along.
13:35 whiteknight right, so I'm trying to figure out what you think language X should be
13:36 whiteknight because we also need to be able to convert that directly to machine code at build time to support our non-JIT runcores
13:36 plobsing something like C.
13:36 whiteknight ok. so how is it like C? same syntax? Same capabilities? etc?
13:36 plobsing I was thinking of doing a prototype with pascal (because I have porcupine + libjit's dynamic pascal at my disposal)
13:36 plobsing note however I don't propose pascal for the final product
13:37 whiteknight is that how libjit does it natively, in pascal?
13:37 plobsing no. it has a pascal interpreter
13:37 plobsing as an example
13:37 whiteknight okay
13:37 whiteknight I'm not sure I would recommend pascal as the final product either, especially since that won't work so well with LLVM
13:37 plobsing my understanding is that pascal is easier to parse, and operates at a similar level to C, but with a better type system
13:38 plobsing the better type system ties into the strengths of several VMs, which have better type systems to C
13:39 whiteknight I'm sure the pascal people say that :) Everybody has good things to say about their own product and bad things to say about the competition
13:39 whiteknight ease of parsing is why I think we need something lower level than C or Pascal
13:40 whiteknight and if we had to decide between the two, something more like C would be better (since our codebase is mostly in C), I think
13:40 payload joined #parrot
13:41 whiteknight but, that's just my initial impression
13:41 tetragon joined #parrot
13:41 plobsing whiteknight: JIT's are mostly designed to JIT structured languages initially
13:41 plobsing structured, static languages
13:41 whiteknight I'm not sure I understand what you mean by that
13:41 plobsing llvm, libjit, jvm
13:42 whiteknight LLVM for instance operates on an assembly-like language natively
13:42 whiteknight with opcodes and labels
13:42 plobsing yes. but there are several projects which use structured, static languages that target it
13:42 plobsing it does it very well
13:43 whiteknight Right, but you still need to parse the structured language into the lower-level representation for LLVM to consume natively
13:43 plobsing and you can do that at compile time
13:43 plobsing no big deal
13:43 purl Yes it is!  I hate you I hate you
13:43 plobsing the feeling is mutual purl
13:44 whiteknight it's been said before that we don't want to maintain our own C parser in the repo.
13:44 whiteknight I think we can extend that by analogy to anything that's equally high-level
13:45 whiteknight however, since we already have NQP in the repo, it's not unthinkable to use that
13:45 plobsing what is ncigen then? does it not parse C and generate NCI defn's?
13:45 whiteknight or, a subset of that
13:45 whiteknight ncigen, I believe, parses a list of simplified signatures only
13:45 plobsing oic
13:45 plobsing README was misleading
13:46 plobsing whiteknight: I don't think nqp or anything that targets execution on parrot is a good idea.
13:46 whiteknight src/call_list.txt
13:46 payload joined #parrot
13:46 plobsing no. that's nativecall.pl
13:46 whiteknight oh, then I may be confused
13:46 plobsing compilers/ncigen
13:47 whiteknight far too many of these stupid little tools laying around
13:47 plobsing whiteknight: my argument for a structured lorito is that it makes it less painful, which means we can use it more extensively
13:47 plobsing the more extensive our use of lorito, the more the vm is exposed to JIT, and the better we can inline our hot path
13:48 whiteknight we aren't against bootstrapping. And we can check in generated files and use them to build parrot from scratch
13:48 plobsing for example, i could imagine all of our pmc's available for inlining
13:48 payload joined #parrot
13:48 whiteknight or, a two-stage build process where the first stage parrot isn't JIT capable
13:49 plobsing no more vtable lookups in tight loops
13:49 whiteknight and it generates the JIT libraries for the second stage
13:49 whiteknight agreed: vtable lookups and indirect calls get expensive
13:50 whiteknight missed branch predictions, cache misses, etc
13:50 plobsing anyways, I've got to get to $work.
13:51 plobsing I hope you consider making lorito structured for the reasons I've detailed above.
13:58 payload joined #parrot
14:06 payload1 joined #parrot
14:08 payload joined #parrot
14:08 mberends joined #parrot
14:08 PerlJam joined #parrot
14:48 Austin_away joined #parrot
14:57 patspam joined #parrot
15:13 bubaflub joined #parrot
15:18 * Essobi whispers 'Anger is a gift.'
15:19 whiteknight not what I want for xmas this year
15:21 Psyche^ joined #parrot
15:21 Essobi hahaha
15:21 Essobi you're the second person who said that
15:22 PerlJam I'll take anger for xmas ... i'll just regift it  :)
15:23 cognominal joined #parrot
15:30 redbrain joined #parrot
15:31 redbrain bbredbrain: status
15:31 bbredbrain Debian-ARM-Feroceon: offline
15:31 bbredbrain Debian-PPC-G5-test: idle, last build 2h16m56s ago: build successful
15:31 bbredbrain Debian-UltraSparcII: idle, last build 2h05m05s ago: failed test
15:31 bbredbrain Debian-x86-test: idle, last build 2h31m40s ago: build successful
15:31 purl Since Wed Oct 28 01:13:35 2009, there have been 2542 modifications and 1287 questions.  I have been awake for 13 days, 14 hours, 17 minutes, 6 seconds this session, and currently reference 809289 factoids. Addressing is in optional mode.
15:31 whiteknight impressive
15:31 redbrain some bsd comming soon :)
15:31 whiteknight redbrain++
15:32 redbrain might be some weeks though becasuse i have some work to do and want to get back to playing around with parrot :)
15:32 redbrain http://crules.org:8010/builders/Debian-Ultra​SparcII/builds/1/steps/compile/logs/warnings
15:34 whiteknight hey, no rush. You need to be having fun too :)
15:34 whiteknight I wonder what all those casting problems are caused from
15:35 redbrain thanks its kind of cool isn't it though going to setup some buildbots for my programming language project too ...eventually :P
15:36 NotFound Are you talking about making lorito a language even more complex than pir? I've supposed that the idea was just in the opposite direction.
15:37 whiteknight NotFound: That seems to be plobsing's idea, yes
15:37 whiteknight and I have to admit that I am swayed by it
15:38 PerlJam making lorito more complex than pir?
15:38 redbrain anyways i'll be back later going to make some lunch :)
15:38 NotFound If we talk seriously about using a pascal-alike language for writting ops, I'll just quite the project.
15:38 NotFound Seriously.
15:38 purl I'm totally freaking serious.
15:45 payload joined #parrot
15:47 whiteknight It wouldn't be pascal
15:47 whiteknight if we were going to use a language of that level, it would be C
15:47 whiteknight which raises the prospect, what if C *was* lorito?
15:47 whiteknight LLVM is certainly capable of compiling C down to LLVM bytecode
15:47 redbrain are you redesigning pir?
15:48 whiteknight and all we need at runtime is just that bytecode, we don't need to do any parsing at runtime
15:48 NotFound I think the intention of a lot people was mainly to avoid the need to use C in lots of places.
15:48 whiteknight redbrain: bnot really. We're adding a new abstraction layer "Lorito" that will nicely interface PIR with a JIT engine
15:48 whiteknight at the moment, PIR is not easy to JIT
15:49 whiteknight NotFound: yes, true. But if it means we don't need to rewrite everything, that might be a benefit
15:49 NotFound At the moment, pir mostly works. Something that a lot of proposals seems to not care about.
15:49 whiteknight NotFound: what do you mean by that? It does work, but I don't think it's ideal
15:49 redbrain i was talking to llvm guys few weeks ago and they were saying if you have like a runtime with a basic switch loop and you turn the runtime functions into a library you can compile it with llvm-gcc so you turn it into bytecode which llvm does the jitting for you because apartently there is some trick with linking against it
15:50 NotFound whiteknight: talking about writing a full C compiler is fantasy.
15:50 redbrain NotFound: yeah very true my first experience with compiler stuff i started writing a basic c-compiler it worked but only for very limited subset of c
15:50 whiteknight NotFound: I disagree. We don't need a full C compiler, just whatever subset the ops use
15:51 whiteknight but that's not even the issue, LLVM *is* the C compiler
15:51 whiteknight we use LLVM to compile the .ops files to bytecode, and then use LLVM at runtime to JIT them
15:53 whiteknight so if Lorito is C, all the ops are already written in Lorito and we already have a Lorito compiler
15:53 NotFound whiteknight: try to compile any .pbc file with a limited subset of C.
15:54 whiteknight NotFound: we don't compile .pbc files. it's a two-stage process
15:55 whiteknight we compile C files to LLVM BC files. Then we use the PBC to lookup functions in the BC file, combine them together into methods, JIT them, and execute the machine code
15:56 whiteknight it's the same way we use .pbc files to lookup functions in the Fast Core
15:56 NotFound What's a BC file?
15:56 redbrain yeah thats quite cool :)
15:56 whiteknight "BC" is my shorthand there for "LLVM Bytecode"
15:57 AndyA joined #parrot
15:57 NotFound So the plan is to us full embrace LLVM?
15:57 whiteknight That's what Allison said, yes
15:58 redbrain even though llvm is beast its probably the safest option since its activly developed etc
15:58 whiteknight libjit is active too
15:58 whiteknight but that's neither here nor there, really
15:59 whiteknight LLVM does come with an impressive suite of tools
15:59 whiteknight And there are good possibilities for Parrot to integrate closely with LLVM
16:00 pmichaud #ps in 150
16:00 redbrain yeah good point
16:00 NotFound I'm not against using LLVM or any other platform, but I supposed we pretending to be plaftorm independent.
16:01 moritz is there any platform parrot runs on and llvm doesn't?
16:01 whiteknight I have been arguing for JIT engine independence, yes
16:01 whiteknight LLVM I think is shakey on Windows
16:01 whiteknight but in development
16:02 whiteknight I think the goal is that Parrot will run everywhere, but if we have LLVM too it will just be faster
16:03 redbrain i always wondered how do things like llvm or libjit handle like multi threaded apps wanting to access the same jitted function etc
16:04 NotFound I think if we are going to a way like that, we can also consider targeting jvm, or cli.
16:04 whiteknight I'm not sure JVM or CLI provide any benefits to Parrot
16:04 NotFound whiteknight: same for llvm
16:04 whiteknight LLVM gives us JIT and AOT
16:05 whiteknight and it gives us those things without additional overhead
16:05 whiteknight A translator from PBC -> CLI would be interesting, but not really a benefit
16:05 NotFound whiteknight: you seems to assume that that means speed and some other benfits, but I haven't seen any proof of that.
16:06 darbelo joined #parrot
16:06 whiteknight NotFound: you need proof that JIT brings speed benefits?
16:06 NotFound whiteknight: yes.
16:07 fperrad joined #parrot
16:07 NotFound Our previous JIT is a good counter example.
16:07 whiteknight our previous JIT was not a real JIT
16:07 whiteknight and didn't do anything that a good JIT does
16:07 NotFound whiteknight: and we can't say same about our future JIT, beacause it doesn't exist.
16:07 whiteknight look at projects like smalltalk, or unladen swallow which is approaching 5x speedups
16:08 whiteknight NotFound: We're desiging our future JIT right now. We're desigining it to improve speed
16:08 darbelo IIRC the JIT removal gave us a ~1% speed improvement, by virtue of the struct pruning.
16:08 darbelo just to give NotFound more ammo.
16:08 whiteknight it's not the same thing. Our old JIT wasn't a real JIT
16:08 whiteknight you can't compare it to LLVM
16:09 NotFound whiteknight: give me the resources of google and I buy you at least a 10x speed improvement ;)
16:09 whiteknight And, our old JIT *did* improve runtime performance
16:09 whiteknight it wasn't much, but there was a measurable improvement with it
16:09 whiteknight especially when combined with cgoto and PIC
16:09 whiteknight I don't have the numbers handy
16:10 NotFound whiteknight: at the cost of an immense lose on developpers time and patience.
16:10 whiteknight NotFound: no question.It wasn't good. But it was a performance improvement
16:10 whiteknight and a real JIT will be a bigger improvement without draining developers
16:10 NotFound I don't buy at that cost.
16:11 darbelo whiteknight: The frame builder gives more bang for the buck 30% on start up time. vs I don't know 5% at runtime?
16:12 whiteknight the frame builder is a special case. There are direct tradeoffs to be made
16:12 whiteknight A "smart" frame builder would precompile stubs used by Parrot internally, and delay others until runtime
16:13 whiteknight but we're still early in that development
16:14 whiteknight We got rid of old JIT for a reason, and are replacing it for a reason. We expect improvements
16:15 darbelo True. Hm. Speaking of that. I think plobsing's branch is ready to merge, have you looked at it?
16:17 whiteknight I tried last night but ran out of time
16:17 whiteknight will tonight, if nobody beats me to it
16:19 darbelo I looked at it, but I'm hardly a domain expert.
16:19 NotFound Don't take me too seriously, I'm in a bad mood because of dayjob things.
16:20 szbalint Function aware (as opposed to simplistic op dispatch) JIT in today's world is a necessity, so that a. you don't have to go microoptimizing things for mediocre performance b. to counterbalance the encapsulation penalties c. to be fast enough as a platform for implementing languages on top of. As far as I know the old JIT implementation was quite op specific and didn't do anything about the C/PIR barrier crossings that take up a lot of the execution time...
16:25 redbrain yeah to be honest jitting is somethin i need to learn more about but i am still not convinced it will beat a really well cleanly written runtime because the amount of code to manage the jit and dispatching is an overhead
16:25 redbrain though i still think jitting is a good idea
16:25 redbrain since it gives many more possibilties
16:25 NotFound szbalint: however people keeps using perl, python, and other languages old versions without any jit.
16:27 NotFound And even non jitted jvm's
16:27 szbalint yes, that's why I said a., for Perl 5
16:29 NotFound Perl 5 works. Many teoric better designed projects don't.
16:30 dalek parrot: r42401 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
16:30 dalek parrot: [distutils] add getenv/setenv OS utilities
16:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42401/
16:32 Zak joined #parrot
16:33 dalek lua: 4ec9b26 | fperrad++ | t/object.t:
16:33 dalek lua: untodo a test
16:33 dalek lua: review: http://github.com/fperrad/lua/commit/4e​c9b26c2ca28f3ca712752de90ecfacba09c655
16:33 dalek lua: e81e58d | fperrad++ | setup.pir:
16:33 dalek lua: add custom targets
16:33 dalek lua: review: http://github.com/fperrad/lua/commit/e8​1e58df0a59763f423df67daa907eb88730cfc6
16:39 whiteknight redbrain: JIT is a tradeoff: increased startup time (compilation) in exchange for improved performance over the life of the program
16:39 whiteknight for short programs it's useless, but for longer programs the costs amortize over time
16:40 whiteknight if we use a trace-based approach, we can determine where the biggest gains are, and only compile critical paths to save on startup time
16:41 redbrain whiteknight: yeah thats the thing thats been in the back of my mind :P, though i find it head bending as in what can you jit do you compile the program basicly or jit bits and pieces as they are called throughout the program managing that seems quite hard
16:41 NotFound whiteknight: I've been hearing for years people saying that with that approach java, or cli, will beat C. I've failed to see demonstrations.
16:41 whiteknight yeah, that's true. It's hard to keep track of everything
16:42 whiteknight NotFound: it's never going to beat C. Anybody who says that doesn't know what they are talking abou
16:42 redbrain and what happens if your calling un-jitted libraris etc tbh i wouldn't know where to start and then how do you jit the only thing i can think of doing it is building some kind of shared library with the jitted functions and call it with dlsym functions
16:42 whiteknight A VM+JIT will be a normal VM though. I can find lots of examples to prove that
16:42 szbalint NotFound: Perl 5 works on top of 15 years worth of optimizations and XS, and if you want reasonable speed you're using XS.
16:43 whiteknight redbrain: it's simple. At the machine code level we just jump control flow to the entry point of the library. JIT can do that very easily
16:43 whiteknight JIT isn't some magical process: It's just a normal compiler that compiles code down to normal machine code
16:44 NotFound szbalint: and other approaches work on... They work?
16:44 redbrain yeah that makes more sense but if your generating machine code can you literly ./jittedprogram ? :P
16:44 whiteknight the magic comes from doing the compilation lazily at runtime
16:44 whiteknight redbrain: yes, that's a possibility. AOT (ahead-of-time) compilation can be used to convert our bytecode down to native optimized executables
16:45 szbalint NotFound: you mean that you're doubting whether JIT for Parrot could work?
16:45 whiteknight ...which would use the same mechanism at JIT, just writing the machine code to a file instead of executing it
16:45 NotFound whiteknight: that is one of the things I dislike. A trend to think that we just switch to using some jit library, and magically all will be beautiful.
16:46 NotFound szbalint: We don't have a JIT that works. That is a reality, not a belief.
16:46 whiteknight NotFound: no, it's definitely not that simple. There are modest gains to be had from a naive approach
16:46 whiteknight but the real gains come from deeper integration with the JIT engine, and complex algorithms built on top of JIT
16:47 redbrain whiteknight: wooo thanks very much i think i see how that works properly now i tried starting a thread on comp.compilers some time ago on this got quite interesting http://compilers.iecc.com/​comparch/article/09-07-079 i built a basic jit for some small functions like + / ... but i just generated x86 code and turned it into a shared library i could call with dlsym and i knew this couldnt be the right way to do it :)
16:48 whiteknight nice!
16:48 szbalint NotFound: As far as I know there isn't any JIT in Parrot atm, so it can't have any properties. Worthwhile JIT has been done elsewhere with good results, so _building_ one is in the realms of possibilities
16:49 whiteknight JIT is very hard to do properly. That's why we would rather use a good existing one then try to create our own
16:49 NotFound szbalint: "not work" is not a property, is the absence of a property. A non existent thing obvoiusly don't have that property.
16:50 whiteknight let's not digress into an argument about the philosophy of being
16:50 szbalint indeed
16:50 NotFound And I don't dount that is possible and interesting to work on a JIT. I doubt that we must fully commit to one that isn't ever designed.
16:51 NotFound s/ever/even
16:51 whiteknight Here are the facts: (1) Parrot does not have a JIT right now, (2) Parrot has less-than-optimal performance right now, (3) JIT has been demonstrated to improve performance in other VMs
16:52 whiteknight NotFound: I think it is getting designed quite well. We still have lots to discuss though
16:52 whiteknight a lot of it needs to be put on paper eventually
16:57 NotFound To be burnt? ;)
16:58 * NotFound is the Spanish Inquisition
16:58 szbalint I don't find you unexpected.
16:59 * darbelo hides his books.
17:01 theory joined #parrot
17:01 kj joined #parrot
17:02 NotFound Thinking about the philosophical point... Is possible to set a property on PMCNULL?
17:05 * darbelo hopes not.
17:05 NotFound Answer: no. Null uses his vtable defaults of throwing.
17:05 whiteknight we can try to test it. I assume not
17:23 Andy joined #parrot
17:38 bubaflub joined #parrot
17:40 * kurahaupo regrets UTC+13 and ponders the necessity for sleep which keeps him away from interesting discussions about JIT
17:41 dalek parrot: r42402 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
17:41 dalek parrot: [distutils] revert the :anon logic.
17:41 dalek parrot: Now, some .sub are reusable.
17:41 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42402/
17:42 allison joined #parrot
17:43 kurahaupo good morning Allison
17:43 kurahaupo s/morning/$localtime
17:45 dalek wmlscript: ed47d61 | fperrad++ | setup.pir:
17:45 dalek wmlscript: improve readability
17:45 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/ed47d61d380b0977bca9344ca7e2485c8307f1ce
17:45 dalek wmlscript: aa9c056 | fperrad++ | setup.pir:
17:45 dalek wmlscript: clean up
17:45 purl well, clean up is a breeze
17:46 dalek wmlscript: review: http://github.com/fperrad/wmlscript/commit​/aa9c056e78d880534bd818cf1a0cd13ab14a8d71
17:46 darbelo ps in ???
17:46 dalek markdown: 29d36d7 | fperrad++ | setup.pir:
17:46 dalek markdown: code tidy
17:46 dalek markdown: review: http://github.com/fperrad/markdown/commit​/29d36d75968a46e67d381178d4a56a685bc56a14
17:46 moritz 44
17:46 moritz date --utc is very helpful ;-)
17:47 dalek xml: 91aa291 | fperrad++ | setup.pir:
17:47 dalek xml: code tidy
17:47 dalek xml: review: http://github.com/fperrad/xml/commit/91​aa29195d5fa57636104373cfea9463639cfc5d
17:47 darbelo I know what time it is. I wasn't sure if ps was synched to a clock or the sun.
17:47 darbelo ;)
17:51 iblechbot joined #parrot
17:51 mokurai joined #parrot
17:51 barney joined #parrot
17:51 dalek lua: f7bbc12 | fperrad++ | setup.pir:
17:51 dalek lua: build Lua libraries in a custom step, after the build of the Lua compiler.
17:51 dalek lua: review: http://github.com/fperrad/lua/commit/f7​bbc12c903292815e4b1452ff89cc62a97f73d6
17:55 mikehh joined #parrot
17:56 * whiteknight will miss part of #ps today
17:56 * whiteknight will try to backlog
17:57 payload joined #parrot
17:59 allison kurahaupo: good morning
18:02 * kurahaupo has to leave for $DAYJOB[0]; $DAYJOB[1] =~ s/work/UMTS seminar/
18:03 * diakopter initially read 'seminary' there
18:04 bubaflub any seminary fans here?
18:10 * diakopter guesses that any wouldn't answer that question..
18:11 * darbelo isn't religious enough to enter a seminary.
18:16 chromatic joined #parrot
18:17 bubaflub fair nuff. loaded quesiton.
18:18 whiteknight joined #parrot
18:18 pdcawley__ joined #parrot
18:24 whiteknight allison: I don't see the AllisonTasklist page on the wiki
18:26 ilia joined #parrot
18:26 allison whiteknight: do you see it now?
18:26 allison whiteknight: (it looks like I kept hitting "Preview" but not "Save")
18:26 whiteknight ah yes, it's there now
18:26 pmichaud I have that problem too.
18:26 pmichaud I keep hitting Preview and then later wonder "where did my page go...?"
18:27 allison whiteknight: my 'f' key is dying on this laptop too, need to fix that
18:27 pmichaud doesn't that make it harder to swear?  ;-)
18:27 dalek tracwiki: v1 | allison++ | AllisonTasklist
18:27 dalek tracwiki: https://trac.parrot.org/parrot/wiki/All​isonTasklist?version=1&amp;action=diff
18:28 whiteknight uck no it doesnt
18:28 allison pmichaud: it does kind of take the orce out of "uck" :)
18:29 diakopter kind o, even
18:30 allison diakopter: aye, tryin' out me luck o the irish
18:31 dalek tracwiki: v2 | allison++ | AllisonTasklist
18:31 dalek tracwiki: https://trac.parrot.org/parrot/wiki/All​isonTasklist?version=2&amp;action=diff
18:31 cotto_work #ps in -1
18:31 allison cotto: thanks
18:37 cotto_work http://www.makinggoodsoftware.com/​2009/11/09/the-four-golden-rules-t​o-be-a-better-software-developer/
18:37 hudnix joined #parrot
18:40 mokurai left #parrot
18:40 mokurai joined #parrot
18:41 Topic for #parrotis now Parrot 1.7.0 "African Grey" is out! | Testing hackathon November 14 and 15 -- improve opcode coverage | find out what's up with the slice opcode | Latest modified TT's: http://icanhaz.com/parrotbugs
18:41 dalek tracwiki: v3 | allison++ | AllisonTasklist
18:41 dalek tracwiki: https://trac.parrot.org/parrot/wiki/All​isonTasklist?version=3&amp;action=diff
18:44 dalek tracwiki: v4 | allison++ | AllisonTasklist
18:44 dalek tracwiki: https://trac.parrot.org/parrot/wiki/All​isonTasklist?version=4&amp;action=diff
18:47 chromatic cotto_work, it's from last Thursday, entitled "List of possible rakudo needs from Parrot" -- I can forward if you don't have it.
18:47 cotto_work just found it
18:59 whiteknight joined #parrot
19:01 AndyA joined #parrot
19:02 whiteknight I hadn't ever even heard of libffi
19:02 dalek tracwiki: v1 | cotto++ | RakudoTasklist
19:02 dalek tracwiki: initial version from pm's parrot-dev post with some formatting adjustments
19:02 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Ra​kudoTasklist?version=1&amp;action=diff
19:02 AndyA_ joined #parrot
19:02 whiteknight but it looks very interesting from what I see
19:03 cotto_work It looked promising from what I could tell.
19:05 whiteknight dukeleto: didn't we already have a Kea project on Parrot somewhere?
19:05 chromatic There's a Kea-CL, I think.
19:06 whiteknight maybe that's what I'm thinking of
19:07 whiteknight and when is this testing hackathon going to be? (needs to be advertised on the wiki)
19:08 cotto_work Should the bitwise ops->dynops migration be marked as a milestone?
19:08 chromatic November 14 and 15, whiteknight.
19:09 whiteknight w00t
19:09 ilia joined #parrot
19:10 bubaflub should i just hangout here to help out with the hackathon this weekend?
19:10 dukeleto whiteknight: kea-cl seems to be defunct
19:10 dukeleto whiteknight: and kea != kea-cl :)
19:11 whiteknight gotcha, it was a very fuzzy memory
19:11 Austin Is there any chance of getting a better diagnostic message from the C3 linearization subsystem?
19:11 whiteknight Austin: what kind of diagnostic?
19:11 dukeleto whiteknight: kea is a mountain parrot that occasionally feeds on sheep. or velociraptors...
19:11 dukeleto cotto_work: did someone say dynops?
19:12 Austin *Any* would be nice. Currently, I get 7"Could not build C3 linearization: ambiguous hierarchy" on a class with essentially one parent.
19:12 chromatic bubaflub, that would be great.
19:12 dukeleto has anyone benchmarked the speed difference between a plain op and a dynop?
19:12 * Austin coughs.
19:12 Austin Dukeleto, I could have sworn you just asked about benchmarks.
19:12 dalek tracwiki: v6 | whiteknight++ | AllHackathons
19:12 dalek tracwiki: add info about testing hackathon this month
19:12 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Al​lHackathons?version=6&amp;action=diff
19:12 dukeleto Austin: ?
19:13 Austin If you can't do it with "helloworld.pir" or "fibonacci.pir" and a sandglass, it isn't done.
19:13 chromatic Any measurable difference would surprise me.
19:13 bubaflub chromatic: is the hackathon primarily focused on getting tests converted to PIR?  anything homework i should have done (besides a functioning build of parrot from trunk) before the weekend comes?
19:13 Austin :-(
19:14 chromatic bubaflub, converting tests to PIR will be good.  I'd like to increase test coverage of opcodes as well.
19:14 chromatic A working build and some familiarity with PIR and our test layout should suffice.
19:14 bubaflub cool.  i'm not too familiar with opcodes.  any recommended reading?
19:14 whiteknight testing hackathon is on the wiki and on the calendar now
19:15 dukeleto Austin: i do lots of parrot benchmarks, have you not seen them?
19:15 chromatic docs/overview.pod is a good place to start.
19:15 Austin Whiteknight: I declared a class in NQP ("class Kakapo::Test::Undef") and then tried to add an existing class ("Testcase") as a parent using the P6object calls (add_parent). Naturally, it blew up. (??!) But I have no idea why, since the only diagnostic is "ambiguous hierarchy".
19:15 dukeleto bubaflub: you want to hack on dynops? Bring me a broom.
19:16 whiteknight Austin: so you want a printout of the hierarchy?
19:16 Austin dukeleto: I have not. Where are they?
19:16 Austin whiteknight: That would be spectacular. Or an explanation of which two classes were in conflict, or something.
19:16 whiteknight gotcha
19:19 dukeleto Austin: here is an example that I sent to p5p: http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse2h​tml/perl5-porters/2009-10/msg01591.html?49#mfs
19:21 Austin dukeleto: Looks great! Can we somehow get that added to parrot? "make bench" or something?
19:21 Austin I tried to do some opcode benchmarking, and came up against the imcc O(N^2) limit.
19:22 dukeleto Austin: it has perl 5 cpan module deps right now, but we can attempt to write it in PIR/NQP if we want
19:22 chromatic Austin, benchmark PBCs instead.
19:22 Austin Chromatic: Thanks for the tip. Why do you suppose I was running imcc?
19:22 dukeleto tool_bench is the rewrite of euler_bench that is not tied to the euler project problems
19:22 Austin dukeleto: Why don't we just eat the cpan deps?
19:24 Austin What are the euler project problems? And if tool_bench is the "way forward," does it work yet?
19:25 whiteknight i would like to have a more comprehensive suite of benchmarks
19:25 cotto_work dukeleto, I wouldn't expect much of a penalty for dynops apart from the time it takes to load them.
19:25 chromatic Austin, I'd only run IMCC if I wanted to benchmark the parsing cost of dynops.
19:25 Austin seen bacek?
19:25 purl bacek was last seen on #parrot 8 hours, 24 minutes and 46 seconds ago, saying: dukeleto, we have to properly encapsulate our GC. Then we can provide RT version of it.
19:26 Austin chromatic: So how do I compile pir down to pbc?
19:26 whiteknight it may be good practice to write a benchmark that targets a particular subsystem before we do any performance-related work to that subsystem
19:26 dukeleto cotto_work: that is what i would want to benchmark. but also to verify that they do not incure a large run-time cost, for some unknown reason
19:26 chromatic ./parrot -o output.pbc input.pir
19:26 dukeleto whiteknight: i really like that idea
19:26 cotto_work dukeleto, That's certainly a good idea.  I'm all for sanity checks.
19:26 Austin chromatic: Perhaps I'm confused, but isn't that running imcc?
19:27 Austin (Because that's what I always do to compile pbcs)
19:27 whiteknight dukeleto: so first goal might be a benchmark that exercises the hell out of PCC
19:28 darbelo Austin: Yes, but runing the pbc is IMCC-free
19:28 NotFound If you want to absolutely avoid imcc code you must embed, because parrot main calls imcc_main
19:28 darbelo Austin: for some values of IMCC-free
19:28 chromatic You avoid IMCC's big-O blowup there.
19:29 chromatic By running the PBC directly, I mean.
19:29 Austin darbelo: My problem lies in the effort to get from pir to pbc. I generated a fairly long pir file mechanically, and then tried to compile it.
19:29 dukeleto whiteknight: so do fib.pir and primes.pasm *not* excercise the hell out of pcc?
19:29 dukeleto whiteknight: how do we properly excercise the hell out of pcc?
19:30 whiteknight dukeleto: maybe they do. if so, we can evaluate that
19:30 whiteknight a good PCC benchmark probably has a few phases: lots of sub calls, lots of method calls, lots of tailcalls and method tailcalls, lots of closures, etc
19:30 darbelo Austin: I guess you are in trouble then. I don't think anyone here is willing to invest the time to knock an exponent off IMCC's O()
19:31 Austin Actually, I was wondering about generating the pbc directly.
19:31 Austin From what I recall, Bacek had something working in the pbc generation space.
19:32 darbelo That was a way for pir programs to emit pbc.
19:32 Austin Works for me.
19:33 Austin I'll have to get with him and find out.
19:33 darbelo Austin: If you want pir -> pbc it doesn't help you.
19:34 Austin darbelo: I want ->pbc. My benchmarks are of the form "repeat this set of opcodes 10,000 times". I can write that in nqp.
19:34 Austin (For somewhat large values of 10,000, ideally.)
19:34 desertm4x joined #parrot
19:36 NotFound Austin: Maybe a exponential chain of macros can be parsed easily by imcc?
19:37 treed Anyone have tips for having one git-svn repo that you use on two machines?
19:37 treed (rsync or whatever)
19:37 cotto_work easy karma for someone who wants to add a note to DEPRECATED.pod for https://trac.parrot.org/parrot/ticket/1260
19:37 Austin NotFound: AFAICT, the problem lies in the symbol table. Per chromatic, it is a common table, searched linearly.
19:37 treed Apparently you can't really do it with normal git operation.
19:37 chromatic Searched linearly several times, some of them in nested loops.
19:38 Austin :)
19:38 dalek TT #1260 created by cotto++: [DEPRECATION] bitwise ops and VTABLE functions
19:38 Austin We have a winnah!
19:38 Austin treed: I'd recommend putting the two machines on the git side of that equation.
19:40 chromatic cotto_work, are you handling the wikification of Patrick's message?
19:40 darbelo purl: msg plobsing Can you submit a CLA to the PaFo so we can get you a commit bit?
19:40 purl Message for plobsing stored.
19:41 cotto_work chromatic, it's under RakudoTasklist
19:41 darbelo purl: msg plobsing See http://www.parrot.org/files/parrot_cla.pdf
19:41 purl Message for plobsing stored.
19:42 chromatic Thanks, cotto_work.
19:42 nopaste "NotFound" at 213.96.228.50 pasted "Austin: something like that" (48 lines) at http://nopaste.snit.ch/18629
19:46 cotto_work also, someone should update DEPRECATED.pod to match https://trac.parrot.org/parrot/ticket/866 .  I just updated it to deprecate only the VTABLE functions mentioned in the tt.
19:48 Austin NotFound: Any way via macro do generate a unique label?
19:48 Austin *do=to
19:49 whiteknight Austin: none that I am aware of
19:49 purl i already had it that way, whiteknight.
19:49 NotFound Austin: I think is a feature that never worked.
19:49 Austin :)
19:49 whiteknight dukeleto: where are fib.pir and primes.pasm?
19:49 treed Austin: Sure, but I tried setting one as a remote of the other and push/pulling, but weird things happened that may be related to git-svn. I think it's recommended that you not push/pull git-wise when dealing with git-svn.
19:49 dukeleto whiteknight: examples/benchmark
19:50 NotFound But my trick is nice, anyway ;)
19:50 whiteknight ah right, I was looking in t/benchmark for some reason
19:53 Austin Yeah, it kind of blows up on repeated labels.
19:53 darbelo Austin: I've never used it, but I think the packfile PMC can do what you want.
19:53 Austin Can I say "unless_null foo, +3" or something?
19:53 cotto_work Austin, that works
19:53 NotFound Austin: but if local label worked, surely you'll have the problem with the symbol table.
19:54 cotto_work (iirc)
19:54 Austin NotFound: That's what I was going to test.
19:54 Austin How big is "$P11 = new [ 'Undef' ]"?
19:54 darbelo one opcode.
19:55 darbelo Size of the opcode? You don't want to ask.
19:55 Austin Looks like "3"
19:56 chromatic Three, but the third is a reference to a constant.
19:56 joeri joined #parrot
19:56 Austin Sure, but the 3 is for a branch offset.
19:57 whiteknight primes.pasm doesn't appear to call any functions
19:57 chromatic primes.pasm is about math, PMC, and opcode dispatch.
19:58 whiteknight fib doesn't call nearly as many as I am thinking of, and not with multiple types of signatures
19:58 whiteknight chromatic: right
19:58 whiteknight I want a benchmark that pushes PCC to the limit
19:58 Austin Hmm, it still takes a while.
19:58 cotto_work chromatic, could you do a quick sanity check on TT #1260?
19:58 whiteknight a quick loop that makes 100K function calls would be a good start
19:58 Austin Do we have the source code to that url-rewrite bot that was here for a while?
19:59 whiteknight something similar with permutating argument lists would be very nice
19:59 chromatic fib.pir recurses a lot.
19:59 Austin Because rewriting TT#1111 as a trac.parrot.org url would be a good service.
19:59 whiteknight chromatic: that's a step in the right direction, but not nearly so comprehensive as I think we need
19:59 darbelo Austin: The web irclog does that.
19:59 whiteknight if we want to improve PCC performance, we need a comprehensive way of measuring that
19:59 chromatic It's sane to me, cotto_work.
19:59 Austin That's cool.
20:00 cotto_work Thanks chromatic.
20:00 whiteknight fib.pir makes one type of sub call: I->I
20:00 chromatic I agree we need more comprehensive benchmarking, but I focused on fib.pir because we're never going to get any faster than that type of sub call at its slowest.
20:00 whiteknight fair enough
20:01 whiteknight I would like to know what the relative speed differences are between named and positional parameters, for instance
20:01 whiteknight or how expensive it is to do :slurpy and :flat args
20:16 patspam joined #parrot
20:19 NotFound The PackfileAnnotations PMC does not have METHOD type. This is intentional?
20:20 chromatic Where would you expect it?
20:20 theory joined #parrot
20:20 NotFound All other derived of PackfileSegment, except directory, have it.
20:21 NotFound And if you want to be able to query the type of a directory entry, you need it.
20:22 dukeleto whiteknight: what about oofib.pir ?
20:22 dukeleto whiteknight: i hear what you are saying, you want benchmarks for different calling conventions. i don't think we have that right now
20:25 whiteknight speaking of benchmarks, I would like to get some setup for parrot-linear-algebra eventually
20:26 whiteknight especially being able to compare timings between BLAS calls and pure-PIR versions of the same algorithms
20:26 chromatic Perhaps we should benchmark some NQP-rx examples.
20:26 chromatic That'll give us some concrete numbers to help Rakudo and other HLLs.
20:27 dukeleto whiteknight: i can do some PLA benchmarks with euler_bench for you. let me know what you want.
20:27 dukeleto chromatic: we definitely need nqp-rx benchmarks. it got a lot slower to compile. i hope it got faster to run.
20:27 whiteknight what is euler-bench?
20:28 dukeleto whiteknight: euler_bench is what i use to benchmark parrot, currently
20:28 whiteknight ok. What does it do?
20:28 dukeleto whiteknight: it is being rebranding tool_bench, but that is still being written
20:28 whiteknight or, where is the code?
20:28 purl somebody said the code was already out
20:28 dukeleto whiteknight: http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse2h​tml/perl5-porters/2009-10/msg01591.html?49#mfs
20:28 dukeleto purl, euler_bench?
20:28 purl i heard euler_bench was what i use to benchmark parrot, currently
20:29 dukeleto purl, forget euler_bench
20:29 purl dukeleto: I forgot euler_bench
20:29 dukeleto purl, euler_bench is http://github.com/notbenh/euler_bench and what dukeleto uses to benchmark parrot
20:29 purl dukeleto: i don't know
20:29 dukeleto purl, euler_bench is http://github.com/notbenh/euler_bench
20:29 purl OK, dukeleto.
20:30 dukeleto purl, euler_bench is also what dukeleto uses to benchmark parrot
20:30 purl no idea, dukeleto
20:30 dukeleto purl, die in a fire
20:30 purl HALP
20:30 diakopter purl, euler_bench is also that which dukeleto uses to benchmark parrot
20:30 purl okay, diakopter.
20:33 whiteknight github down
20:33 purl yes
20:33 whiteknight github up?
20:33 diakopter purl, github down is true
20:33 purl ...but github down is <reply>yes...
20:33 diakopter purl, github up is true
20:33 purl OK, diakopter.
20:34 diakopter purl, no, github up is NEVER
20:34 purl okay, diakopter.
20:34 diakopter github up?
20:34 purl github up is, like, NEVER
20:34 diakopter purl, no, github up is <reply>NEVER
20:34 purl okay, diakopter.
20:34 diakopter github up?
20:34 purl NEVER
20:34 diakopter heh
20:35 darbelo purl: github?
20:35 purl github is a repository-centric social network for hackers where $friending eq $cloning_a_repo -- http://github.com/ or a cocoaruby interface to git :  http://github.com/Caged/gitnub/wikis/home or really nice or a good place or neat enough to take nperez's tags ands tarball them up for me
20:36 chromatic dukeleto, I think a recent CodeString commit fixed parsing time.  (Variable-width string encodings are evil.)
20:39 whiteknight gitorious?
20:39 purl gitorious is getting a lot of work atm, it seems.
20:41 jan joined #parrot
20:41 whiteknight I like the angry-looking unicorn that is the github error page
20:42 whiteknight and i especially like how they say to check twitter for status updates, but that hasn't been updated since the 7th
20:42 cotto_work At least you know there'll be a writeup once they get it fixed.
20:43 dukeleto #github on freenode is the best way to get ahold of the github guys
20:44 whiteknight meh, I don't care enough to join another irc network
20:44 darbelo purl: fleanode?
20:44 purl i don't know, darbelo
20:45 darbelo So useless sometimes...
20:46 whiteknight purl isn't useless!
20:46 whiteknight we could use her to weight down papers in a drafty room
20:46 darbelo whiteknight: Electronic bits don't weight.
20:47 japhb darbelo, sure they do!  Just very, very little.
20:48 bacek joined #parrot
20:48 dukeleto whiteknight: irssi can be connected to as many networks as you need :)
20:48 dukeleto darbelo: irc.freenode.net
20:48 purl irc.freenode.net is home of the mirror universe #perl that isn't full of assholes. or where you can find a #perl that's supposedly actually got something to do with perl
20:48 mikehh joined #parrot
20:49 darbelo japhb: I study engineering. Too small to measure := doesn't exist ;)
20:49 japhb whiteknight, plobsing: Saw this a couple days ago, kept forgetting to link it here: http://blog.vlad1.com/2009/11/06/c​anvasarraybuffer-and-canvasarray/
20:50 japhb darbelo, you just need vast quantities, that's all.  :-)
20:50 dukeleto chromatic: i am interested to see if parsing time is noticeably faster
20:50 dukeleto darbelo: get a smaller epsilon :)
20:51 darbelo japhb: Too large to fund == Doesn't exist either.
20:51 darbelo ;)
20:51 bubaflub joined #parrot
20:53 japhb whiteknight, plobsing: The above link is about how the WebGL people are dealing with NCI where you will be filling, modifying, and reading fast arrays of (sometimes mixed) native types.  They essentially separate the concept of a raw buffer and a type mapping into a chunk of that buffer. You can have many type mappings into the same buffer, but those type mappings act as if they were just arrays of the proper type.
20:53 darbelo dukeleto: Oh, I know where fleanode is, I just wanted to know what purl had to say about it.
20:54 japhb darbelo, Funding really large things just requires using some of the creative math during the proposals that you'll end up using on the project itself ...
20:55 dukeleto darbelo: i see, says the blind man
20:56 japhb "... as he spit into the wind -- 'It's all coming back to me now.'"
20:57 dukeleto japhb: i like that!
20:58 whiteknight dukeleto: chatzilla can be connected to other networks too. I don't care, not gonna do it. Too lazy
20:58 dukeleto whiteknight: alrighty then.
20:58 whiteknight never underestimate the force of laziness
20:58 japhb whiteknight, if you're lazy I'm a can of pickles.
20:59 dukeleto whiteknight: i am on too many channels anyway. you don't want to go down the path of >20 irssi panes
21:00 whiteknight on my personal laptop I have xchat setup to open ~20 channels on startup
21:00 whiteknight but here at work, I'm not able to keep up with all that crap
21:00 whiteknight so I don't
21:00 whiteknight japhb: That's a very interesting link. I wonder if/how we could apply that to Parrot-Linear-Algebra
21:01 whiteknight japhb: I would be very happy to setup any types that you need for OpenGL, of course
21:01 dukeleto yes, PLA seems like a good place to put types that OpenGL needs
21:02 whiteknight PLA is really focusing on fast 2D data buffers
21:02 japhb Just being able to get a pointer to the raw buffer (as opposed to the array object header) would be nice.
21:02 whiteknight the numeric ones have bindings to BLAS, but you don't need to do that
21:03 whiteknight japhb: I could set up get_pointer for that purpose
21:03 whiteknight does OpenGL need a float array, or an integral one?
21:03 dukeleto whiteknight: i would assume both
21:03 whiteknight yeah, but I want to ask before I start throwing shit together haphazardly
21:03 japhb whiteknight, yes.  :-)  Part of the interest of that article I linked is that very often you need a mixed type array, or a single large buffer with multiple type blocks within it.
21:04 japhb I know that may be outside of the bounds of PLA,
21:04 whiteknight japhb: we have a PMCMatrix2D type which does that
21:04 japhb but something to think about.
21:04 japhb The other thing (longer term) is being able to lock memory that's being handed off to the video driver.
21:04 whiteknight doesn't acheive the same separation between data/metadata though
21:04 japhb nodnod
21:05 whiteknight lock memory? what do you mean by that?
21:05 whiteknight write-protect it?
21:05 japhb keep it from being paged out.
21:05 japhb or gc moving it to a new location
21:05 whiteknight oh, and how would we accomplish that?
21:05 darbelo whiteknight: With a very clever method you will devise.
21:06 whiteknight you know what would be really hot? Passing databuffers off to the GPU for fast vectorized mathematical processing
21:06 japhb mlock?
21:06 japhb whiteknight, POGL began working on that a few years back.
21:06 whiteknight when we lock it is it write-protected?
21:07 japhb Had some basics working on that to, but then he got a job taking all of his tuits.
21:07 japhb whiteknight, well, that's mmap then
21:07 whiteknight japhb: I'm trying to figure out what you need and what you mean by "lock"
21:07 japhb whiteknight, two thingsL
21:08 japhb 1. OS told not to page the memory out to swap.
21:08 japhb 2. GC told not to move the buffer.
21:08 whiteknight Okay, that should be simple then
21:09 whiteknight what would you need first? FloatMatrix or IntMatrix?
21:09 whiteknight or something entirely different?
21:10 japhb FloatMatrix is most valuable.
21:10 NotFound allison: ping
21:10 dalek TT #1261 created by NotFound++: Document NCI type 'p' behavior for PMCNULL/NULL values
21:10 whiteknight japhb: okay
21:10 japhb Not everything, but *most* GL functionality can use float as a fallback type, just possibly slower than the "native" type for the operation
21:11 japhb Number two most valuable is actually byte arrays -- for color buffers/textures.
21:11 japhb And then at the third tier you get into wanting everything else.
21:12 allison NotFound: pong
21:12 NotFound allison: what dalek just said
21:13 whiteknight japhb: Matrixy has need of a char buffer for it's weird string handling
21:13 whiteknight so that type will be forthcoming
21:14 bluescreen joined #parrot
21:14 allison NotFound: looking...
21:14 whiteknight anyway, I have to pack up and go. Later
21:15 japhb fperrad, backloggin #parrotsketch I notice you saying you wanted to "fix Plumage on Windows" ... um, what's not working?  I thought we had everything resolved ...?
21:15 NotFound japhb: we must fix Windows X-)
21:15 cotto_work NotFound, MS have been trying that for years.
21:16 NotFound cotto_work: you sure? ;)
21:16 fperrad japhb, not all solved, but we made some progress
21:16 japhb NotFound, first, go back in time.  Second, hire an operating system architect with taste.
21:17 japhb fperrad, OK.  What's still broken?
21:17 dalek parrot: r42403 | pmichaud++ | trunk/runtime/parrot/library/P6object.pir:
21:17 dalek parrot: [p6object]:  Make add_parent smarter about adding HLL-specific method types.
21:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42403/
21:17 japhb fperrad, now that I can pass for moderately healthy, I'm anxious to get back into the world domination game ....
21:17 NotFound japhb: my flux condenser is broken, must fix it first.
21:18 fperrad japhb, I've problem with $ENV{HOME} and with space in pathname
21:18 allison NotFound: looks great! change "his" to "its" on line 95, change line 97 to "If this is a return type and the value is NULL, PMCNULL is returned,", and change "some damn thing" to "something" on line 99 (I know, that was there before, but figure we might as well clean it up while we're in there)
21:18 NotFound The "some damn thing" is not mine ;)
21:19 NotFound allison: better we can get rid of that part, the UnmanagedStruct usage seems to be consolidated.
21:19 dalek rakudo: 01c042f | pmichaud++ | build/PARROT_REVISION:
21:19 dalek rakudo: Bump PARROT_REVISION to get p6object and other fixes.
21:19 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/0​1c042fe88248e8e6a650fe4691b17706b65a13a
21:19 NotFound parrot-mysql depends on it.
21:19 allison NotFound: aye, I saw that was in the original, just figured we might as well change it while we're editing
21:20 japhb fperrad, OK.  So what is the $ENV{HOME} problem?  That env var doesn't exist, I'm guessing?  And I assume the space in path problem is during run/qx calls, yes?
21:20 allison NotFound: okay, go ahead and edit the text about UnmanagedStruct
21:20 NotFound allison: ok, thanks
21:21 fperrad japhb, $ENV{HOME} exists but it isn't complete, see
21:21 NotFound allison: BTW the UnmanagedStruct usage was already taken for granted in later parts of the draft.
21:21 fperrad HOME=\Documents and Settings\fperrad
21:21 fperrad HOMEDRIVE=D:
21:22 japhb fperrad, oh, interesting.
21:22 japhb That's just ... wow.
21:22 japhb I'm guessing it's for remappable network drives?
21:22 allison NotFound: it's probably been partially updated
21:23 NotFound Mmmm... I think I was misreading the phrase... The damm thing is not the Unmanaged, but the thing pointed by it.
21:24 japhb fperrad, I've got some Plumage refactorings in a local branch (pending NQP-rx enhancements).  I can either there, or if the branch is blocked for too long, turn home-dir fetch into a method with some logic behind it.
21:26 NotFound allison: I think the "or other" is the confusing part. Just "pointer to something" will be clean.
21:26 japhb fperrad, HOMEDRIVE issue now added to Plumage TODO
21:26 dalek parrot-plumage: a66dee9 | japhb++ | :
21:26 dalek parrot-plumage: [META] More TODOs
21:26 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/a66dee96dc744a2a01ac12421c96e8fa119f3c25
21:27 japhb fperrad, where are you seeing the "space in path" problems, exactly?  (So I can figure out the scope of what needs to be fixed.)
21:27 jsut_ joined #parrot
21:27 fperrad japhb, it's my default env, I try without success to set $ENV{HOME} to current directory (./)
21:27 fperrad For a first time, I prefer set $ENV{HOME}
21:28 japhb I'm not sure I understand.  Prefer over what?
21:29 mikehh joined #parrot
21:29 fperrad japhb, Plumage could use its own env variable (for example PLUMAGE_HOME), instead of HOME
21:29 japhb fperrad, I don't mind having that as an override, but we still need to detect a proper default.
21:30 japhb I really don't want to get back to "early cpan" days when you had to answer a couple dozen questions just to get started.
21:30 japhb zero configuration to get the average person started.  configuration is there for power users and special cases.
21:31 fperrad japhb, I agree with zero configuration
21:32 kj joined #parrot
21:34 NotFound As long as you don't use NOZEROCONF=true to deactivate it, as linux network conf uses in some systems X-)
21:34 AndyA joined #parrot
21:34 dalek parrot: r42404 | NotFound++ | trunk/docs/pdds/draft/pdd16_native_call.pod:
21:34 dalek parrot: [nci] fix doc of 'p' type, TT #1261
21:34 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42404/
21:35 japhb pmichaud, (still backlogging #ps): why do you want the new NQP-rx-in-parrot binary to be called 'parrot-nqp' instead of just 'nqp' as it is now.  What is the benefit to dehuffmanizing there?
21:36 cotto_work NotFound, ping
21:37 NotFound pong
21:37 cotto_work NotFound, can you add a notice to DEPRECATED.pod about TT #1260 and update the entry for TT #866?
21:37 dalek TT #1261 closed by NotFound++: Document NCI type 'p' behavior for PMCNULL/NULL values
21:38 cotto_work Both should be pretty quick changes.  The change for TT #866 is just to make the list of deprecated VTABLE functions explicit, and they're listed in the TT's first post.
21:39 NotFound cotto_work: There is no one with an worse english than me for that task? ;)
21:39 cotto_work I saw that you'd just committed something and I don't want it to get dropped on the floor.
21:39 NotFound I always have problems for writing understandable DEPRECATED entries.
21:39 cotto_work If you prefer, I can msg cotto.
21:39 theory joined #parrot
21:40 NotFound Please do.
21:41 cotto_work msg cotto update DEPRECATED.pod for TT 1260 and TT #866
21:41 purl Message for cotto stored.
21:41 cotto_work botsnack
21:41 purl thanks cotto_work :)
21:47 * japhb checks http://wiki.github.com/per​l6/nqp-rx/plumage-requests ... aww, I was hoping for a visit from the magical feature gnomes during the night!  :-)
21:49 patspam joined #parrot
21:51 dalek parrot: r42405 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
21:51 dalek parrot: [distutils] improve unlink
21:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42405/
21:52 dalek lua: cfdfc77 | fperrad++ | setup.pir:
21:52 dalek lua: some refactor and fix targets for test
21:52 dalek lua: review: http://github.com/fperrad/lua/commit/cf​dfc773899d0effbca848d7c8261c6767adab26
21:53 mikehh joined #parrot
21:58 nopaste "fperrad" at 78.113.94.6 pasted "(for japhb) can't configure Plumage on linux" (24 lines) at http://nopaste.snit.ch/18630
21:59 japhb looking
21:59 japhb fperrad, how recent is your nqp-rx?
22:01 fperrad japhb, I work with nqp, not with nqp-rx
22:01 nopaste "NotFound" at 213.96.228.50 pasted "Object.invoke patch, makes 'object()' works" (17 lines) at http://nopaste.snit.ch/18631
22:01 NotFound allison: ping
22:02 chromatic Clever, but do we need to add 'Pi' to the start of the PCC string?  (I forget if we removed that in the rush to improve speed.)
22:02 NotFound chromatic: for the simple test I have, it works.
22:03 chromatic Also you're missing a space around the assignment operator.
22:03 chromatic But I nitpick.
22:03 NotFound As always :)
22:04 NotFound Be happy don't used hard tabs ;)
22:04 pmichaud japhb: (nqp versus parrot-nqp)  -- the parrot standard appears to be that language translators should be named "parrot-*"
22:04 pmichaud japhb: I'm happy to install it as 'nqp', though.
22:04 pmichaud japhb: I just need someone official-ish to tell me what to do there :)
22:04 japhb bak
22:05 japhb fperrad, Plumage requires nqp-rx.  We were seriously blocked on features missing in old nqp, so needed to switch.
22:05 japhb fperrad, since nqp-rx will (soon) ship with parrot, that's not going to hurt our users, thankfully.
22:06 diakopter I don't suppose someone wants to fix a bug (at least, it seems like a bug to me) in __dump for PAST nodes...
22:06 diakopter it's blocking me, somewhat..
22:06 pmichaud what's the bug?
22:06 purl the bug is http://www.cbttape.org/funny/bug3.jpg or http://img227.imageshack.us​/img227/2596/featureiu1.jpg
22:06 japhb pmichaud, hmm, OK.  I certainly prefer the language translators to just be called by their simple name.  As important as parrot is to us, it doesn't really matter to the end user who just wants to get things done.
22:07 japhb So my vote is just plain 'nqp', as it is right now.
22:07 pmichaud japhb: that kinda doesn't work if the language is 'python', though.  :-|
22:07 diakopter pmichaud: http://parrot.pastebin.com/f3f8bd543   line 30 is missing the var name
22:07 japhb pmichaud, I didn't realize there was a language for which the code name was the same as the original language name ...
22:08 fperrad japhb, thanks, I'll install nqp-rx
22:08 pmichaud japhb: there may not be.  I suppose it could be installed as 'pynie'
22:08 japhb You're saying to install particle as parrot-tcl?
22:08 Whiteknight joined #parrot
22:09 japhb pmichaud, I can see both arguments, but my preference is to use the project name, not parrot- plus the language name.
22:09 pmichaud japhb: I'm saying I'd like to know what parrot's official standard is, and to use that :)
22:09 pmichaud japhb: I personally don't have a strong preference when it comes to nqp versus parrot-nqp
22:10 japhb pmichaud, I know.  I'm under the assumption there isn't a standard, and trying to influence a future choice.  :-)
22:10 pmichaud well, it is mentioned in pdd30, iirc
22:17 dalek TT #1262 created by NotFound++: Simple patch for the overriding of invoke for objects
22:18 NotFound Certainly the pcc refactor has simplified things :)
22:25 fperrad japhb, could you take a fresh parrot-MT19937 and play with setup.pir (distutils).
22:25 fperrad Plumage needs a support for setup.pir interface
22:26 japhb Can you give me the 100-word overview of what setup.pir/distutils is?  Configure replacement, make replacement, both, neither?
22:29 japhb fperrad, ^
22:29 fperrad japhb, setup.pir replaces Configure & generated Makefile,
22:29 fperrad $ parrot setup.pir
22:29 fperrad $ parrot setup.pir test
22:29 fperrad $ parrot setup.pir install
22:29 fperrad setup.pir uses the library distutils.pir (in the parrot tree)
22:30 darbelo fperrad: You a python user?
22:31 fperrad japhb, yes but I prefer Perl
22:31 darbelo Just wondering about the influences to distutils.pir
22:32 japhb fperrad, OK, interesting.  Where is the master source for setup.pir?  (I didn't find it in the parrot tree.)
22:32 fperrad japhb, each project has its setup.pir
22:32 darbelo japhb: If he's using the python custom, it's specific to each project
22:33 darbelo Eh. What he said.
22:33 fperrad japhb, setup.pir is just data + a call setup()
22:33 japhb fperrad, I meant, where do you keep the "canonical version", that you copy/paste into each new project?  Or does distutils have a function to create a skeleton for you?
22:33 japhb fperrad, ah, OK
22:35 fperrad japhb, tools/dev/mk_language_shell.pl generates it
22:37 japhb What's the repo url for parrot-MT19937?
22:37 fperrad japhb, http://github.com/fperrad/parrot-MT19937
22:38 japhb Wow ... distutils.pir feels like it would be WAY simpler in NQP
22:39 darbelo japhb: Well, that *is* the point of NQP ;)
22:40 japhb darbelo, yeah, but even more than usual.  Browse the source a bit.  My carpal tunnels hurt just reading it.
22:41 * darbelo reads it
22:43 payload joined #parrot
22:44 darbelo PIR is such a *high* level assembler.
22:44 darbelo ;)
22:45 NotFound Only a bit not so high as macroassembler ;)
22:46 japhb fperrad, is setup.pir with no arguments basically configure, or build, or both?
22:46 fperrad japhb, 'build' is default target
22:46 japhb fperrad, so no configure step at all?
22:47 japhb (I should say, no *separate* configure step)
22:47 fperrad japhb, no Configure step
22:48 fperrad japhb, see setup.pir examples, I put links in the top distutils.pir
22:48 japhb fperrad, sure, just confirming that it wasn't an accident of example choice, but really intended to be no configure step.
22:48 japhb Which you just did?
22:50 japhb er, s/\?/./
22:51 fperrad japhb, the goal is : remove Configure step and remove Makefile/make/shell dependencies
22:52 NotFound fperrad++
22:52 japhb fperrad, understood
22:58 japhb holy cow ... well, I will say one thing ... setup.pir is FAST
22:59 japhb fperrad, incoming
23:00 NotFound japhb: Even without jit? ;)
23:00 japhb fperrad, U CAN HAZ PLUEMIJ SETUP
23:01 japhb NotFound, one hell of a lot faster than make ....
23:01 fperrad japhb, you would say : parrot is fast
23:01 darbelo japhb: make doesn't JIT  either :)
23:01 dalek parrot-plumage: 9ce5135 | japhb++ | :
23:01 dalek parrot-plumage: [plumage] Support setup.pir tool for new mt19937 project
23:01 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/9ce51356321fa0ae19a8770de925c51d1f0b16b9
23:10 dalek parrot: r42406 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
23:10 dalek parrot: [distutils] use nqp.pbc instead of parrot_nqp.exe
23:10 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42406/
23:15 kid51 joined #parrot
23:27 plobsing joined #parrot
23:27 payload joined #parrot
23:28 plobsing hi parrot
23:28 darbelo hi plobsing
23:28 dalek parrot: r42407 | jkeenan++ | branches/auto_libjit:
23:28 dalek parrot: Branch has been superseded by libjit_framebuilder branch.
23:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42407/
23:28 darbelo saw my purl-o-grams?
23:29 plobsing yes. thanks.
23:29 darbelo Let me know when you send the CLA so I can nominate you on the next #parrotsketch
23:30 plobsing will do.
23:31 kid51 Last call for comments on these 4 TTs:
23:31 kid51 https://trac.parrot.org/parrot/ticket/1194
23:31 kid51 https://trac.parrot.org/parrot/ticket/1234
23:31 kid51 https://trac.parrot.org/parrot/ticket/1235
23:31 kid51 https://trac.parrot.org/parrot/ticket/1236
23:31 darbelo I have a problem with TT#1194
23:32 hercynium joined #parrot
23:32 kid51 Yes?
23:32 darbelo You waited too much to do it ;)
23:32 darbelo Other thatn that it looks goog to me
23:33 chromatic +1 to all four of your suggestions, kid51.
23:35 japhb plobsing, I sent a link to you earlier, but you may have been offline at the time.
23:36 japhb plobsing, it's here: http://blog.vlad1.com/2009/11/06/c​anvasarraybuffer-and-canvasarray/
23:36 plobsing saw it
23:36 japhb ah, ok
23:36 plobsing I was considering something similar
23:36 japhb excellent
23:36 plobsing the only weakness with that approach is requiring at least 2 pmcs for every C object
23:36 plobsing this of course makes the common case suboptimal
23:37 plobsing I propose a variant of this where the first PMC created with a pointer "owns" a pointer
23:37 plobsing other pmcs can refer to this but, defer to the original for GC purposes
23:37 NotFound +1 for all also
23:38 plobsing of course there should be a way of transfering ownership
23:38 japhb plobsing, then that owning PMC needs to have the API for locking memory etc.
23:38 dalek parrot: r42408 | jkeenan++ | trunk/t/op/hacks.t:
23:38 japhb right
23:38 dalek parrot: Delete useless test file per https://trac.parrot.org/parrot/ticket/1234.
23:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42408/
23:38 dalek TT #1234 closed by jkeenan++: t/op/hacks.t:  Delete useless test file
23:39 plobsing japhb: thats the thing, other PMCs will have the same interface and just forward to the owner for that kind of thing
23:40 japhb plobsing, nodnod
23:41 plobsing japhb: regarding your issues with struct creation; we should be able to freeze the descriptor into the PBC
23:41 wknight8111 joined #parrot
23:41 dalek parrot: r42409 | jkeenan++ | trunk/t/op/sysinfo.t:
23:41 dalek parrot: Eliminate dependence on Perl 5 '%Config' in tests.  Cf.:  https://trac.parrot.org/parrot/ticket/1235.
23:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42409/
23:42 plobsing then we won't have to push tokens onto the array at runtime.
23:42 dalek TT #1235 closed by jkeenan++: t/op/sysinfo.t:  Improper dependence on Perl 5 %Config
23:43 japhb plobsing, nice.
23:43 japhb damn, fperrad left.
23:44 japhb purl, msg fperrad With my last push, I believe I've got a fix in for your HOMEDRIVE requirement.  The remaining problem is spaces in paths ... and I need to find out exactly where that fail is occurring, so could use debugging help from you.
23:45 purl Message for fperrad stored.
23:45 kid51 Whiteknight:  Do you have more hours in the day than the rest of us?  Is that how you manage to juggle all these github projects in addition to Parrot?  :-)
23:46 Whiteknight kid51: not nearly so much juggling as you think
23:46 Whiteknight I can keep a few things from hitting the ground
23:46 Whiteknight plobsing: I'm getting test failures in libjit_framebuilder witout libjit installed
23:46 Whiteknight t/pmc/nci.t fails test 611
23:47 dalek parrot-plumage: bdd12b6 | japhb++ | :
23:47 dalek parrot-plumage: [CORE] Util.nqp: Add user_home_dir() portability function
23:47 dalek parrot-plumage: review: http://gitorious.org/parrot-plumage/parrot-plumag​e/commit/bdd12b66115db6ccaf5cdbd2847632af6a98e595
23:48 dalek parrot: r42410 | jkeenan++ | trunk/MANIFEST:
23:48 dalek parrot: Fix MANIFEST to reflect recently deleted file.
23:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42410/
23:49 chromatic Whiteknight, is that on 32-bit Linux?
23:49 plobsing Whiteknight: what is the title of the test?
23:49 Whiteknight 64-bit linux
23:49 Whiteknight "nci_ssc"
23:50 plobsing without you say?
23:52 chromatic That's new.
23:53 pmichaud poll:   $PARROT_INSTALL/bin/nqp  or   $PARROT_INSTALL/bin/parrot-nqp   ?
23:54 moritz nqp
23:54 moritz rakudo doesn't ship a parrot-perl6 binary either
23:55 pmichaud well, the slight difference is that nqp will be part of the parrot distro, while rakudo won't.
23:55 pmichaud (er, that _could_ be a perceived difference)
23:55 moritz it will be?
23:55 dalek parrot: r42411 | jkeenan++ | trunk (71 files):
23:55 dalek parrot: Merge auto_format_no_Config branch into trunk.  Eliminate dependence on Perl 5 '%Config' in auto::format and corresponding test.  Transfer that lookup to init::defaults.
23:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42411/
23:55 dalek parrot: r42412 | jkeenan++ | branches/auto_format_no_Config:
23:55 * moritz thought it was decided the other way round
23:55 dalek parrot: Branch has been merged into trunk and is no longer needed at HEAD.
23:55 purl i already had it that way, dalek.
23:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/42412/
23:55 moritz pmichaud: then I retract my vote
23:56 pmichaud nqp will continue to live in its own repository.  But Parrot will snapshot it into its repo so it can be built along with Parrot.
23:56 dalek TT #1236 closed by jkeenan++: config/auto/format.pm:  Replace direct dependence on Perl 5 %Config
23:56 plobsing Whiteknight: I changed that test to better exercise short->long promotion
23:56 pmichaud i.e., obtaining parrot provides nqp and its libraries as well.
23:56 plobsing it did asser 2*3=6
23:56 plobsing now it asserts -2*3=-6
23:56 Whiteknight plobsing: okay, I'll give it another go in a little while
23:56 plobsing I'm trying to reproduce now

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

Parrot | source cross referenced