Camelia, the Perl 6 bug

IRC log for #parrot, 2009-10-07

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:13 GeJ dukeleto: thank you.
00:14 TiMBuS wasnt there a parrot function to turn a STRING back into a c string? or am i imagining things
00:15 cotto_work TiMBuS, Parrot_str_to_cstring iirc
00:15 TiMBuS that looks about right
00:15 TiMBuS thanks cotto
00:15 darbelo TiMBuS: Just don't forget to free it.
00:15 cotto_work it's not a very smart function, but cstrings aren't that smart in the first place
00:16 cotto_work np
00:17 darbelo Don't forget to Parrot_str_free_cstring() it, actually.
00:18 TiMBuS ah. yeah i was just grepping for that
00:19 payload joined #parrot
00:20 darbelo The thing is: mem_sys_free() works too, but it's better to use Parrot_str_free_cstring()
00:21 TiMBuS does parrot have a way to allocate automatically collected memory?
00:21 cotto_work TiMBuS, if it did, we'd be using it by now. The closest we have is a ManagedStruct.
00:22 darbelo PMCs and STRINGS are both garbage collected, it dependnds on what you want to do with them.
00:23 darbelo TiMBuS: What are you trying to do?
00:24 TiMBuS oh, i'm just calling some c functions
00:25 darbelo And they want you to allocate a char * for them?
00:25 TiMBuS no they just need a string argument, im assuming STRINGs arent null terminated
00:25 coke STRINGS ain't chars.
00:26 coke don't look under the hood.
00:26 coke -> zz
00:28 darbelo TiMBuS: You're stuck with Parrot_str_to_cstring()
00:29 payload joined #parrot
00:29 TiMBuS that's fine
00:29 darbelo NotFound++ had a trick for making cstrings 'managed' let me look for it.
00:29 darbelo It might help you.
00:30 cotto_work Didn't allison say "Don't do that."?
00:31 darbelo Se said "Don't do that in the parrot core."
00:31 cotto_work important distinction there
00:32 darbelo She also said we should "stop using cstrings".
00:32 TiMBuS wellll im writing a NCI
00:32 darbelo TT#1083 If you want inspiration :)
00:32 darbelo https://trac.parrot.org/parrot/ticket/1083
00:35 darbelo The basic idea is to grab an allocated cstring and stick it into a ManagedStruct PMC so that the garbage collector will track it for you.
00:35 TiMBuS that makes sense
00:35 TiMBuS i might use it in my next language for when i just pass off certain ops to the stdc lib
00:41 pyrimidine joined #parrot
00:44 msmatsko joined #parrot
00:45 Zak joined #parrot
00:47 dalek parrot: r41744 | darbelo++ | trunk/src/io/api.c:
00:47 dalek parrot: Replace anther 'fake' STRING with a real one.
00:47 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41744/
00:55 darbelo Ok, ttbot didn't complain. I'm heading out.
00:55 cotto_work w00t
00:55 darbelo left #parrot
01:02 rhr joined #parrot
01:20 Patterner joined #parrot
01:38 dalek parrot: r41745 | jkeenan++ | branches/detect_llvm:
01:38 dalek parrot: Create branch to work on detection of LLVM.
01:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41745/
01:45 dalek parrot: r41746 | jkeenan++ | branches/detect_llvm (4 files):
01:45 dalek parrot: Rough first draft of code to detect LLVM.
01:45 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41746/
01:55 Ruilov joined #parrot
01:55 rhr joined #parrot
01:58 dalek parrot: r41747 | jkeenan++ | branches/detect_llvm/config/auto/llvm.pm:
01:58 dalek parrot: Add inline comments on module design; remove commented-out code.
01:58 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41747/
02:10 Andy joined #parrot
02:35 janus joined #parrot
03:13 jrtayloriv moritz, ping
03:15 dalek parrot: r41748 | pmichaud++ | trunk/compilers/pct/src/POST/Compiler.pir:
03:15 dalek parrot: [pct]:  Add a 'yield' type to POST::Op.
03:15 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41748/
03:16 rhr joined #parrot
03:18 dalek parrot: r41749 | pmichaud++ | trunk/compilers/nqp/src (2 files):
03:18 dalek parrot: [nqp]:  Allow methods to be named "category:sym<...>".
03:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41749/
03:45 jrtayloriv joined #parrot
03:47 jrtayloriv Sorry if this already came through -- I got cut off (I've got an unbelievably annoying problem with an ethernet jack that doesn't allow the cable to "clip" into it, so I have to tape it into my laptop, and every now and then the tape comes out ... GRRAAARGH!)
03:47 jrtayloriv If I created a closure like: my $closure := PAST::Op.new(:inline('%r = newclosure %0'),$past); ... how would I then go about calling it later from a PAST::Op?
03:48 jrtayloriv (where $past is a PAST::Block representing the body of the sub)
03:49 Tene jrtayloriv: just put the result in a PAST::Op
03:50 jrtayloriv Tene, So just do a PAST::Op 'call' with $closure as the Op's first child?
03:51 Tene Yes.
03:51 jrtayloriv Tene, And I can save $closure into a PAST::Var too right?
03:51 Tene Yes.
03:51 jrtayloriv excellent, thanks
04:14 Zak joined #parrot
04:52 dukeleto 'ello
05:01 GeJ H'
05:14 dukeleto GeJ: are you working on pcc_reapply?
05:28 GeJ I'm C illiterate. The best I can do (unless I missed an obvious task I could accomplish, if so please enlighten me) is run tests from time to time and report failures.
05:28 GeJ Or for this branch in particular report an important increase of failures.
05:30 dukeleto GeJ: yeah, it is kind of rough right now. pcc_reapply does not compile on all platforms, causes infinite loops during the test suite on others, and it only makes sense to do "make corevm" and "make coretest" in pcc_reapply now
05:31 dukeleto last time I checked, test_more.pir wasn't working, which is blocking me from adding tests
05:33 dukeleto GeJ: one thing you can do: some error messages relating to function calls changed slightly, which has caused some tests to start failing. if you find those you can fix 'em
05:34 dukeleto msg japhb looks like plumage expects an installed parrot in a particular hard-coded place
05:34 purl Message for japhb stored.
05:41 dalek TT #1096 created by dukeleto++: Plumage requires an installed parrot in a hard-coded place
05:48 dalek parrot: r41750 | dukeleto++ | trunk (2 files):
05:48 dalek parrot: [TT #1089][t] Convert t/pmc/resizableintegerarray.t to PIR and fix a typo in the implementation, kurahaupo++
05:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41750/
06:01 chromatic joined #parrot
06:02 uniejo joined #parrot
06:19 japhb dukeleto, huh?  Earlier this morning I just tried installing parrot in a different place (from a different build location too, no less) and it worked like a charm
06:20 japhb dukeleto, as long as you run `parrot_nqp Configure.nqp` using the parrot_nqp from the correct parrot, all should be good.
06:21 japhb Man, I hate having to choose between hacking and being even remotely caught up with email ...
06:22 jrtayloriv joined #parrot
06:28 moritz jrtayloriv: pong
06:28 szabgab joined #parrot
06:30 jrtayloriv moritz, Hey -- for some reason the query -- nqp && closure -- breaks irclog. The first page displays and then the second page, it removes closure from the query (try it) ... and is there any way for me to do boolean search where it will only give results where BOTH words were used in same sentence/line?
06:31 jrtayloriv Sorry, first part wasn't clear (2:30am here, and my brain is mush) -- The first results page displays fine, but then when I click '2' to go to second page, it removes "closure" from the query.
06:32 fperrad joined #parrot
06:32 moritz jrtayloriv: the search is mostly broken, and I wanted to re-do it properly for some time now, with KinoSearch or another indexing module - so far I haven't got around to it :(
06:33 jrtayloriv No big deal -- just wanted to point it out. (I was just randomly trying things to see if I could get boolean search to work)
06:34 jrtayloriv But a beefed up search would rock -- I've found that the irc logs are the best docs, but the search is definitely limiting.
06:37 moritz basically I wanted to wait for the 2.0 version of KinoSearch, but I guess I'll just try out the developer releases instead
06:37 viklund joined #parrot
06:37 moritz oooh, there was a dev release on Aug 31
06:38 jrtayloriv looking at their site now ... I'd never heard of it until you mentioned it.
06:39 moritz it's a port of Lucene to perl
06:40 viklund joined #parrot
06:40 jrtayloriv cool -- it's got the two things I wanted most: booleans and quoting
06:41 viklund joined #parrot
06:42 moritz aye
06:42 moritz and stemming, and other stuff
06:42 viklund joined #parrot
06:42 dukeleto japhb: i will try again
06:49 moritz japhb: I saw on the parrotsketch logs that you need some hosting... I could offer some if you still need it
06:50 moritz japhb: basically I have access to a server where I can hand out root access; it's a Debian Lenny box
06:50 dukeleto japhb: i see what is going on. if you run it from a parrot that was never meant to be installed (and hence was given no install prefix), it barfs
06:50 dukeleto japhb: but that is mostly my fault
06:51 japhb heh
06:51 japhb Yeah, you need to have installed your parrot with `make install-dev`.  Same requirement Rakudo has, FWIW.
06:52 jrtayloriv I don't really know how to ask this question -- still trying to hash out what I'm trying to do. But basically, I am trying to figure out how to properly expand Scheme macros for my compiler. I was going to add a new stage originally, between parse and past, but I don't know (a) if that's the right way to do it, and (b) how to do it if it is.
06:53 jrtayloriv Any recommendations for where to look for examples of such a stage in another HLL compiler?
06:53 dukeleto japhb: yes, you are correct
06:54 jrtayloriv I need to expand them before I eval the s-expressions, but I need to have access to lexicals to see if the name of the macro is being shadowed by a more local variable definition.
06:54 japhb As for hosting, moritz, thank you.  (I ride Debian testing on my personal machines, so it would at least be familiar territory.  :-)
06:54 mberends joined #parrot
06:56 japhb moritz, but first I want to give Allison a chance to get back to me ... she was going to look into parrot.org hosting ... and asked that I code the metadata server with mod_parrot.  :-)
06:56 moritz japhb: sure; feel free to come back to my offer at any time if you need it
06:57 moritz you can also use it as a development machine to figure out what modules and other requirements you need on the "real thing" or so
06:58 japhb moritz, that's a good idea
06:59 japhb email or msg me the details, if you like
07:10 cotto joined #parrot
07:10 japhb moritz++ # sucker^W victim^W hosting provider
07:12 moritz ;-)
07:13 japhb Oh, which reminds me, moritz, if you've sent in a signed PaFo CLA, send me your Gitorious nick, and I'll add you as a parrot-plumage committer.
07:14 japhb Now, there's something I'm supposed to be doing right now ....  Oh right, sleeping.
07:14 japhb g'night, all!
07:15 dukeleto japhb: night
07:40 riffraff joined #parrot
07:40 dalek TT #1096 closed by dukeleto++: Plumage requires an installed parrot in a hard-coded place
07:47 dalek TT #1097 created by dukeleto++: Plumage fails to compile on case-insensitive file systems
08:03 * dukeleto is hacking on plumage.
08:03 dalek parrot: r41751 | mikehh++ | trunk/t/op/cmp-nonbranch.t:
08:03 dalek parrot: codetest/distro_tests failure - svn properties
08:03 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41751/
08:18 payload joined #parrot
08:25 dukeleto i am guessing that plumage should have a test suite written in pir and/or nqp
08:35 allison joined #parrot
09:37 Whiteknight joined #parrot
09:45 Whiteknight good morning #parrot
09:47 mikehh hiya Whiteknight
09:47 Whiteknight hello mikehh
09:55 mikehh Test failures with fulltest on testf and testg for t/compilers/imcc/syn/macro.t and t/compilers/imcc/syn/regressions.t
09:55 mikehh t/compilers/imcc/syn/macro.t - Failed tests:  2-4 - Non-zero exit status: 3
09:55 mikehh t/compilers/imcc/syn/regressions.t - Failed test:  7 - Non-zero exit status: 1
09:55 mikehh All other tests PASS (pre/post-config, smoke (#28657), fulltest) at r41750/1 - Ubuntu 9.04 amd64
09:55 mikehh in other words the test passes on the other cores just fails -f and -g
09:56 mikehh with the same failures
09:58 mikehh got to go to the store and also fill up the car - bbl and will open a ticket on it
10:10 jhelwig joined #parrot
11:11 allison joined #parrot
11:32 mikehh joined #parrot
11:43 dalek rakudo: cf8884d | jonathan++ | src/ (3 files):
11:43 dalek rakudo: Keep the main nominal type and constraint type(s) separated out at parse time. This simplifies signature construction and also avoids creating a bunch of one-elements junctions that we don't really need. Between this and yesterday's refactor, we shave about 10% or so off Rakudo's startup time.
11:43 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​f8884dbf8d6a83d59ea466f24b6f090910ef682
11:43 shorten dalek's url is at http://xrl.us/bfquhu
12:01 masak joined #parrot
12:02 whiteknight joined #parrot
12:03 whiteknight good morning again!
12:03 coke afternoon.
12:03 purl hmmm... afternoon is when we eat my lunch.
12:04 whiteknight coke, where are you at?
12:04 coke Leeds, UK
12:04 whiteknight didn't you used to be in NY?
12:04 Coke it's only for a week.
12:04 whiteknight okay.
12:05 moritz there are things called planes, and they allow you to move real fast from NY to UK
12:05 moritz :-)
12:05 Coke not fast enough. :P|
12:13 whiteknight joined #parrot
12:27 fperrad_ joined #parrot
12:34 Ron joined #parrot
12:36 payload joined #parrot
12:46 quek joined #parrot
12:48 Ron_ joined #parrot
12:50 Ron joined #parrot
13:06 PerlJam joined #parrot
13:09 Ron_ joined #parrot
13:11 ruoso joined #parrot
13:14 allison joined #parrot
13:16 slavorg joined #parrot
13:49 iblechbot joined #parrot
13:52 dalek rakudo: a0d1e55 | moritz++ | docs/release_guide.pod:
13:52 dalek rakudo: [docs/release_guide.pod] suggest Lisbon.pm
13:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​0d1e550b0a98597311c6c84c6828ebff715c002
13:52 shorten dalek's url is at http://xrl.us/bfqu2d
14:06 jsut_ joined #parrot
14:08 szabgab joined #parrot
14:11 Andy joined #parrot
14:18 Psyche^ joined #parrot
14:26 Ryan52 joined #parrot
14:33 theory joined #parrot
14:55 whiteknight slow day today
14:59 japhb legal detail: I offered a commit bit for Plumage to moritz, who responded thus: "I submitted a signed CLA to TPF before parrot foundation existed - I hope that qualifies (at least it qualified for a parrot commit bit ;-)"  Is he correct?  Were all the pre-PaFo TPF people grandfathered in?
15:00 NotFound japhb: I hope so. If not, I'm not qualified as commiter.
15:00 PerlJam japhb: I'm pretty sure they were.
15:01 moritz since the perl foundation assigned their copyright to the parrot foundation, the CLAs should also be inherited that way (though IANAL)
15:01 moritz if it should prove to be a problem, I could also sign and send in a parrot CLA
15:04 xenoterracide joined #parrot
15:04 japhb moritz, I think you are correct, I just wanted final confirmation -- because, as NotFound pointed out, it *will* come up again.  And I'd really rather not force people to do useless busywork.
15:05 PerlJam Allison is probably the one to ask for a more definitive answer.
15:05 moritz japhb: I think for final confirmation you have to ask allison++ (and for that mail works great)
15:05 japhb If it turns out that only core Parrot was grandfathered, then we'll have to do the CLA jig, but better to know that now.  :-)
15:12 japhb email sent
15:12 moritz japhb++
15:18 particle all parrot committers must sign a pafo cla
15:19 particle you can scan it and email it, so no postage necessary
15:20 japhb particle, are you saying that all your original Parrot committers need to do it even to work on core Parrot?  That seems borken.
15:20 particle i want signed cla's from all parrot committers
15:20 moritz maybe it would make sense to generate a list of all parrot commiters who haven't yet, and write them an email or so?
15:21 japhb ugh, I hate paperwork ...
15:21 japhb sorry for stirring up this can of worms, guys.
15:22 moritz you're just the message boy, not the bad news he delivers :-)
15:24 particle is it really that difficult?
15:25 particle read a document, sign it, and email, fax, or mail it.
15:25 particle and parrot foundation has better protection of parrot's code.
15:32 japhb particle, every little impediment, no matter how small, causes hacking to be delayed -- and if the prospective hacker isn't in the mood, they don't bother to get around to it, and potential code is lost.  There's nothing that keeps people from jumping through the hoop, but on the modern Internet are a thousand little hoops to jump through, and people tend to focus energy where there are fewer hoops.  If this is a truly necessary hoop, then
15:32 japhb fine, no problem.  But having spent too many painful hours looking at signup process drop-off charts on various web sites, it's clear that people are amazingly lazy when it comes to "paperwork", even when they plan to devote a huge amount of personal time to the site in question later.
15:32 japhb You'd be amazed how often people refuse to do a 10 second task that gets in the way of a 10 hour pile of fun.
15:33 particle oh, brother.
15:33 purl brother is probably home. Gotta go. A+
15:33 particle in the time it took you to write that, you could have completed the task.
15:35 nopaste joined #parrot
15:37 particle feel free to put the task off as long as you want, until someone forces you to do it.
15:37 japhb particle, I've already done it.  Long ago.
15:38 japhb I'm more than average willing to jump through hoops for this project.  :-)
15:38 Ruilov left #parrot
15:38 japhb I'm talking about *other* potential committers.
15:38 japhb But in any case as I said: If it's legally necessary, that's that.
15:39 particle new committers must sign a cla before being granted a commit bit to parrot.
15:39 particle *a parrot foundation cla
16:17 iblechbot joined #parrot
16:24 darbelo joined #parrot
16:28 cotto time for w3rk
16:29 cotto (or at least that's what I'm trying to convince myself of)
16:35 kjeldahl_ joined #parrot
16:37 cognominal joined #parrot
16:38 dukeleto 'ello
16:45 jonathan Anyone familiar with the ops compiler know if there's a way to say that I want to only take a non-constant PMC?
16:46 cotto_work good morning
16:46 cotto_work jonathan, lemme dig
16:47 * jonathan is digging too :-)
16:48 payload joined #parrot
16:50 nopaste joined #parrot
16:50 jonathan Ah
16:50 jonathan Marking them "inout" supresses it.
16:50 jonathan Erm, suppresses the constant variants.
16:54 cotto_work do you're happy?
16:55 cotto_work s/d/s/
16:55 jonathan erm
16:55 jonathan not yet ;-)
16:55 jonathan Is there a maximum number of operands that an op may have?
16:57 particle a long time ago it was 8
16:57 jonathan omg yes
16:57 jonathan It still is.
16:57 dukeleto is that documented?
16:57 jonathan ;^;
16:57 particle wow
16:57 jonathan But I want 9!!
16:58 dukeleto jonathan: please write a failing test :)
16:58 particle recompile.
16:58 particle an op with 9 operands?
16:58 cotto_work What about invar?
16:58 particle excuse me, don't you want to pass a higher-level data structure to that op?
16:59 jonathan No.
16:59 particle sheesh
16:59 jonathan If I wanted to do that, I'd not be wanting to take so many operands. :-P
16:59 particle what's the op do?
16:59 jonathan particle: Tries to set up a signature element Really Fast.
17:00 jonathan particle: It's slow today because we mess around building up a high level data structure.
17:00 jonathan Amongst other things.
17:00 particle ah, well if it's capitalized, i understand.
17:00 jonathan OK WILL BE!
17:00 jonathan ;-)
17:00 jonathan It's OK, I'll cope for now. :-)
17:00 particle what consequence does it have for parrot overall to raise that limit?
17:01 jonathan Probably a memory hit.
17:01 * cotto_work wonders why
17:01 purl cotto_work wo-wo-wo-wo-wooonders o/~
17:01 particle i wonder how much it slows things down, or more likely, uses memory
17:01 moritz the usual answer is "more sanity, less speed"
17:02 jonathan I was just a tad surprised to run into a hard limit there.
17:02 jonathan Thought we'd allocate by the number of things we need.
17:02 jonathan Since most ops take, like, 2 or 3 operands.
17:02 particle whaddayawant, infinite registers *and* infinite operands?
17:02 jonathan 9 isn't infinite. ;-)
17:03 particle it's approaching infinity, though :P
17:03 * jonathan grins and copes with 8 for now.
17:03 cotto_work It practically is.  It's almost TWO DIGITS.
17:03 jonathan "for some values of infinity" :-)
17:03 cotto_work (even more in binary)
17:03 particle it's two digits in base 8
17:05 chromatic joined #parrot
17:07 kurahaupo joined #parrot
17:10 nopaste joined #parrot
17:11 cotto_work btw, it's PARROT_MAX_ARGS in include/parrot/op.h where the limit lives
17:17 jonathan cotto_work: OK, thanks. That's good to know.
17:19 dalek rakudo: 30e2cfd | jonathan++ |  (4 files):
17:19 dalek rakudo: Add in ops that allow for fast construction of low level signatures.
17:19 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​0e2cfdf881ad43bbd0f0ddaa7afe9bcfdbe9d9b
17:19 shorten dalek's url is at http://xrl.us/bfqv9h
17:30 dukeleto particle: is/should the default max args to an opcode of 8 be documented somewhere?
17:31 particle yes, it should be.
17:32 particle heck, it should be configure-time modifiable if you ask me.
17:35 nopaste joined #parrot
17:38 einstein joined #parrot
17:40 cotto_work btw, changing that value to 16 yields no measurable slowdown in oofib fwiw.
17:41 whiteknight besides in IMCC, I can't really imagine that there would be any effect of having a limit of 16 operands
17:42 whiteknight that number doesn't come into play during execution at all
17:42 whiteknight the big question is: how inefficient is IMCC's algorithm for parsing operands. If it's O(N^10) we're not going to want to increase the limit too much
17:43 whiteknight but if it's (more likely) O(n^2) or something, and that's only the worst case in a search for a missing opcode, the performance isn't an issue
17:43 cotto_work Without knowing imcc
17:44 cotto_work 's way of doing that, I'd say +1 to setting the limit to 16 to make jonathan happy
17:44 darbelo Well, if it's an IMCC-only thing you can measure it rather easily.
17:46 darbelo Just a matter of running a PIR file with lots of ops through calgrind before and after.
17:47 cotto_work It wouldn't be a bad idea to have a test op with the maximum number of params just to make sure we don't have some ugly corner case lurking.
17:49 whiteknight test case is a good idea
17:50 whiteknight of course, as soon as we change the limit jonathan is going to want an op that takes 17 parameters :)
17:50 nopaste joined #parrot
17:50 whiteknight if you give a mouse a cookie...
17:50 cotto_work We'll throw him over that bridge when we come to it.
17:51 chromatic I'm backlogging, but ERGH.
17:51 whiteknight I sense a disturbance in the force, as if chromatic is displeased and then is silent
17:52 chromatic Variable-sized ops are the opposite of walking bytecode fast.
17:52 whiteknight we have variable-sized opcodes now
17:53 whiteknight and fixed-size opcodes are the opposite of making bytecode small
17:55 whiteknight ...of course, we could get around both those issues by making opcodes have a fixed number of operands but creating a "dummy" op that only serves as a placeholder for making additional arguments available to the master op
18:01 allison joined #parrot
18:03 joeri joined #parrot
18:06 chromatic If we can make Lorito ops a fixed size (three arg form), I'm happy.
18:10 nopaste joined #parrot
18:17 cotto_work allison, what are your thoughts on bumping the maximum number of params an op can take?  Rakudo apparently wants 9 and the current limit is 8.
18:18 allison cotto: these are for dynamic ops? yes, we should allow more
18:18 allison cotto: I'd say go for 16 next, to keep the binary boundary
18:20 nopaste joined #parrot
18:20 allison cotto: I doubt we'll need to go for 32
18:21 allison cotto: (or by that time we may be on Lorito, and have no limit)
18:21 whiteknight chromatic: I agree. fixed-size ops for lorito is a very very good idea
18:21 cotto_work I don't want to see one of those 32-param ops.
18:21 whiteknight in lorito-world, PBC will only really serve as a compressed interchange format anyway
18:23 cotto_work I shouldn't commit from work, but anyone with a commit bit should feel free to bump PARROT_MAX_ARGS in include/parrot/op.h to 16.
18:23 allison chromatic: fixed-size in general seems unlikely, but a fixed size of one (the call signature) is easily possible
18:23 NotFound I'm looking at rakudo generated pir and see a lot of things like: "unless_null $P21, vivify_30 | new $P21, "Failure" |  vivify_30:" Maybe a new_if_null opcode can speed up and reduce size.
18:23 whiteknight cotto: on it
18:23 chromatic Fixed-size in general seems to work for many, many other machines, virtual and otherwise.
18:24 allison chromatic: are you talking about Lorito's core ops, or the ops defined on top (written in Lorito ops)?
18:24 cotto_work jonathan, there you go.
18:25 whiteknight r41752
18:25 darbelo cotto_work: All your code are belong to MS?
18:25 chromatic Lorito's core ops.
18:25 allison chromatic: if it's the former, I agree, because it's a tightly controlled set
18:25 cotto_work darbelo, only what I write while I'm on the clock.
18:25 allison chromatic: aye, agreed
18:26 whiteknight for lorito I like the idea of three-argument ops
18:26 jonathan cotto_work: Thanks.
18:27 allison 3 may not be enough (depending on how low-level we make them), but 8 certainly would be
18:27 allison dynamic ops, on the other hand likely will need more flexibility
18:27 chromatic Three.  Fixed size.
18:27 dalek parrot: r41752 | whiteknight++ | trunk/include/parrot/op.h:
18:27 dalek parrot: [ops] bump PARROT_MAX_ARGS from 8 to 16 to allow for a new class of overly-complicated ops. cotto++
18:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41752/
18:27 whiteknight LLVM ops are, I believe, three-argument ops.
18:28 whiteknight almost all RISC machines are too
18:28 chromatic libJIT too.
18:28 whiteknight lots of good literature about optimizing those
18:28 whiteknight yes
18:28 allison chromatic: <shrug> we'll see. It's a restriction on complexity in one part of the system, and worth it if it gains us in optimizations. But, if it costs us too much complexity in another part of the system, it's worth sacrificing.
18:30 chromatic Read the code that looks for bytecode annotations.
18:30 allison Horrible code now is not prove that the same job couldn't be done with better code.
18:30 chromatic I can make that horrible code O(log n) +- some constant.
18:31 chromatic Fixed-size opcodes make that horrible code non horrible and O(1).
18:31 chromatic See also: non-local fixups.
18:31 chromatic See also: bytecode splicing.
18:31 chromatic (important for tracing JIT)
18:32 whiteknight lucky for us, a lot of extremely low-level operations lend themselves nicely to three-arg form
18:33 chromatic Exactly.  There's a reason it's common.
18:33 allison Like I said, we'll see. Changes to the bytecode are pretty long-term planning.
18:33 whiteknight yes
18:39 HG` joined #parrot
18:40 nopaste joined #parrot
18:45 viklund joined #parrot
18:51 Zak joined #parrot
18:56 mokurai joined #parrot
19:00 nopaste joined #parrot
19:23 darbelo Hmm. I'm seeing failures in t/compilers/imcc/syn/macro.t
19:24 dukeleto darbelo: yeah, in fulltest?
19:24 darbelo Yup.
19:24 dukeleto darbelo: i was seeing those in trunk as well
19:24 darbelo They pass when I prove -v the file.
19:25 darbelo Same for you?
19:25 chromatic It's a difference in runcores for the line number bugs I fixed yesterday.
19:25 moritz seen Infinoid
19:25 purl Infinoid was last seen on purl 5 days, 9 hours, 28 minutes and 32 seconds ago, saying: <private message>  [Oct  2 09:49:08 2009]
19:25 darbelo The tests expect the number to be wrong?
19:27 chromatic The tests expect the numbers to be right for all runcores.
19:27 chromatic I'm not sure why they're wrong in this case.
19:32 NotFound /parrot --runcore=fast t/compilers/imcc/syn/macro_2.pir
19:32 NotFound Null PMC access in get_string()
19:32 NotFound current instr.: 'test' pc -1 ((unknown file):-1)
19:33 NotFound Doesn't match Null PMC access .*current instr.*:5
19:34 chromatic That's strange, as the fast runcore is also the default runcore.
19:34 chromatic Or should be.
19:34 joeri left #parrot
19:34 NotFound Looks like in linux amd64 is not.
19:35 nopaste joined #parrot
19:35 chromatic see src/runcore/main.c lines 127 and 143.
19:44 NotFound chromatic: putting a printf in Parrot_runcore_switch I see a call with fast followed by a call with slow
19:44 chromatic Hm.
19:44 NotFound Using --runcore=fast I see two calls with fast
19:45 nopaste joined #parrot
19:46 chromatic What if you change compilers/imcc/main.c:358 to:
19:46 chromatic INTVAL                  core = PARROT_FAST_CORE;
19:49 NotFound That way I get two calls with fast in both cases
19:49 NotFound (with or without --runcore=fast)
19:50 chromatic Okay.  Now we need to fix several testf failures.
19:51 nopaste "darbelo" at 200.49.154.173 pasted "Can our win32 users give this a test?" (73 lines) at http://nopaste.snit.ch/18251
19:51 NotFound t/op/annotate.t fails with that change
19:52 chromatic Several tests do.
19:55 whiteknight apparently I'm a group manager for the linked in group now
19:55 cotto_work With great power comes great responsibility.
19:55 darbelo And great potetntial for abuse.
19:58 Tene am I in that group?  I don't log into linkedin often.
19:58 mikehh fulltest failures with testf, testg and testS - these cores all FAIL the same tests
19:58 mikehh t/compilers/imcc/syn/macro.t - Failed tests:  2-4
19:58 mikehh t/compilers/imcc/syn/regressions.t - Failed test:  7
19:58 mikehh All other tests PASS (pre/post-config, smoke (#28676), rest of fulltest) at r41752 - Ubuntu 9.04 amd64
19:59 dalek parrot: r41753 | darbelo++ | trunk/src/io (4 files):
19:59 dalek parrot: Change string-internals poking via ->strstart to poking via Buffer_bufstart().
19:59 purl dalek: that doesn't look right
19:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41753/
20:00 pmichaud phone
20:01 nopaste joined #parrot
20:02 chromatic NotFound, mikehh http://nopaste.snit.ch/18252
20:05 NotFound chromatic: a general solution can be setting in the runloop data a pointer to the pc variable.
20:06 NotFound That way forbids optimizing pc into a register, though.
20:07 whiteknight but we don't need to optimize it into a register in that case either, I don't think
20:08 chromatic The nopaste does that.
20:09 whiteknight Tene: I dont know if you are in the group or not. I don't know your real name :)
20:09 whiteknight Unless it's somethin obvious like Tene Teneson, which I doubt
20:10 nopaste joined #parrot
20:13 NotFound The functions for setting and switching runcore are lame, they convert from numeric to string to numeric for no good reason.
20:13 whiteknight lame indeed
20:14 whiteknight and on that note..
20:14 * whiteknight leaves
20:14 chromatic Backwards compatibility.
20:14 purl i think backwards compatibility is overrated. or important
20:17 xenoterracide_ joined #parrot
20:20 mikehh chromatic: the patch gets fast core through but -g and -S still FAIL
20:22 mikehh make test PASSes but the specific tests fail in _S and -g
20:22 chromatic Same tests?
20:23 mikehh t/compilers/imcc/syn/macro.t - Failed tests:  2-4 and t/compilers/imcc/syn/regressions.t - Failed test:  7
20:23 mikehh in both cores but now -f PASSes
20:24 ruoso joined #parrot
20:24 mikehh with that patch that is
20:30 nopaste joined #parrot
20:34 mikehh but make testf now fails t/op/debuginfo.t - Failed tests:  1, 7-8
20:38 chromatic Doesn't testf run the fast core?
20:42 NotFound opcode_t *current_pc;            /* program counter of Sub invocation */
20:42 NotFound This comment is realistic?
20:42 chromatic Sort of.
20:43 chromatic It's not really a counter and it's not just Sub invocation, but the spirit of the comment is right.
20:43 NotFound I think that the field name without any comment is clearer than that.
20:44 chromatic Makes sense.
20:44 cotto_work +1
20:44 purl 1
20:44 cotto_work < purl-- >
20:44 NotFound Well, my idea is: change that opcode_t * to an opcode_t **, and we only need to set it at the start of the runloop.
20:44 Coke purl += sqrt(i)
20:44 purl Coke: sorry...
20:45 nopaste joined #parrot
20:46 chromatic I'd have to see code to be sure of that, but it's worth trying.
20:46 chromatic mikehh, t/op/debuginfo.t has some workarounds for the fast core, but they're unnecessary now.
20:47 Tene okay, let's see if I can send mail to parrot-dev or not... I remember having some kind of trouble in the past.
20:47 Tene I just replied to Phil... let's see how long it takes to go through.
20:47 Tene Oh, immediately.  That's different from what I remembered.  That's nice.  :)
20:49 cotto_work left #parrot
20:49 cotto_work joined #parrot
20:49 NotFound Thinking better, it can't work. runloops for context of continuations can be gone.
20:53 chromatic Even still, keeping a pointer to the current opcode in the interpreter seems like a hack.
20:53 chromatic "Oh, it *must* be faster, because we're not dereferencing two pointers to read it!"
20:54 dukeleto Tene: any word on test_more.pir on pcc_reapply ?
20:55 Tene dukeleto: last night mostly didn't happen for me.  No word.
20:55 Tene I'm more hopeful about tonight.
20:55 chromatic For introspection to work reliably, we need to know the current opcode we're executing in the PBC.  That's all.
20:55 dukeleto Tene: cool, just checking
20:58 dukeleto Tene: did you see the branches that i pushed to plumage on gitorious? code review?
20:59 Tene dukeleto: I didn't.
20:59 NotFound The reverse way can work: using a pointer to the context current_pc instead of having a pc and updating from it in each runloop iteration.
21:00 nopaste joined #parrot
21:01 NotFound Also bad idea, the current context can change inside the loop.
21:03 chromatic We need to store the pc in one and only one place, I suspect.
21:07 Whiteknight joined #parrot
21:10 nopaste joined #parrot
21:10 japhb dukeleto, why branch for a change to the partcl metadata?
21:10 japhb dukeleto, and why does OS X have problems with Glue.pir being in the repo root?
21:10 dukeleto japhb: Plumage and plumage conflict. there is a TT, one sec
21:11 darbelo plumage has trac?
21:11 dukeleto japhb: i make topic branches for everything. that is how I roll
21:11 Whiteknight I love when new users get interested in parrot!
21:11 dukeleto darbelo: i just started making plumage TT's, no one told me not to :)
21:11 jdv79 what's the possibility of doing stuff like tracing jit compiling to machine code?
21:12 dukeleto japhb: https://trac.parrot.org/parrot/ticket/1097
21:12 jdv79 basically the stuff the js guys are doing with tracemonkey and v8.
21:12 jdv79 missing an "and" in there.
21:12 japhb darbelo, AFAICT, there's no problem at the moment with just piggy backing on the Parrot Trac, since it will be folded into Parrot someday anyway
21:13 dukeleto japhb: i organized PIR files into pir/ and then the problems went away
21:13 japhb dukeleto, ah, yes, brain dead file systems.  Tene gets no biscuit today.  ;-)
21:13 chromatic jdv79, that's one of the goals of Lorito.
21:14 japhb dukeleto, how about 'lib' instead?
21:14 dukeleto japhb: yes, I agree. os x's filesystem should die in a fire while suffocating Steve Jobs
21:14 dukeleto japhb: sure, doesn't matter to me. See, this is why I made a topic branch ;)
21:14 japhb In fact, I was considering making a src/ dir, with src/lib/ underneath.
21:15 japhb The top level would just be the SHOUTING FILES, Configure.nqp, src/, and metadata/ .
21:15 darbelo src++
21:15 japhb And maybe leave probes/ at the top level too, I guess, since it's not really part of src/
21:16 * darbelo likes src/
21:16 japhb Would you mind re-branching with that layout in mind?
21:16 japhb And feel free to merge the one commit for the partcl metadata fix back to master.  ;-)
21:17 dalek tracwiki: v106 | whiteknight++ | WikiStart
21:17 dalek tracwiki: + more info about more hackathons
21:17 dalek tracwiki: https://trac.parrot.org/parrot/wiki/W​ikiStart?version=106&amp;action=diff
21:17 shorten dalek's url is at http://xrl.us/bfqxye
21:17 japhb dukeleto, see above # forgot to use your nick
21:17 dukeleto japhb: sure.
21:17 dukeleto japhb: you want src/lib, correct?
21:18 japhb yeah, src/plumage.nqp, src/lib/Glue.pir, src/lib/Plumage/Downloader.pir
21:18 Tene Whiteknight: did the hackathon targets mentioned during #ps get added anywhere?
21:20 nopaste joined #parrot
21:20 Whiteknight Tene: did just now
21:20 Whiteknight AllHackathons on the wiki
21:20 dalek tracwiki: v1 | whiteknight++ | AllHackathons
21:20 dalek tracwiki: + info about hackathons past and prsent
21:20 dalek tracwiki: https://trac.parrot.org/parrot/wiki/Al​lHackathons?version=1&amp;action=diff
21:20 shorten dalek's url is at http://xrl.us/bfqxyv
21:25 Whiteknight When does 2.0 come out?
21:26 darbelo one month after 1.9?
21:28 PerlJam Whiteknight: isn't it on the roadmap?
21:29 Whiteknight PerlJam: yeah, but I'm really lazy
21:29 Whiteknight plus, I was hoping somebody would just know the answer off the top of their head :)
21:29 PerlJam Whiteknight: oh, the answer is ... it's on the roadmap  :)
21:30 nopaste joined #parrot
21:40 nopaste joined #parrot
21:40 * Whiteknight really wishes that parrot-dev emails replied to the whole list by default
21:40 allison Whiteknight: January
21:40 Coke that'sprobably adjustable.
21:40 * Whiteknight is really tired of sending a reply to just one person
21:41 Whiteknight allison: thanks, but my email already went out without a date in it
21:41 Whiteknight ...and it only went to one person
21:41 Whiteknight >:(
21:41 Coke I don't seem to have this problem, but I use gmail.
21:41 Whiteknight I use gmail too
21:41 darbelo Some mailers have reply-to-all functionality.
21:42 moritz or even reply-to-list
21:42 Whiteknight darbelo: yes, but I never remember to click it
21:42 Whiteknight because all the other mailing lists I belong to have reply-to-list as the default
21:44 GeJ Good morning everyone
21:45 Whiteknight good morning GeJ
21:45 GeJ Heya Whiteknight
21:45 purl i heard Whiteknight was mailto:wknight8111@gmail.com or the grand master funk or http://wknight8111.blogspot.com/
21:45 Whiteknight allison: Do I need to fill out a Parrot CLA?
21:46 Zak joined #parrot
21:46 jrtayloriv I'm trying to figure out how to expand Scheme macros in my compiler. I don't think I can just add another stage and expand them before the 'past' stage, because I need to have access to the lexical environment, since local variables can mask the names of macros. For instance: http://pastebin.ca/1602550 ... I can create a macro named "replace" and shadow it with a local variable of that name.
21:48 jrtayloriv So basically, I'm confused as to how to go about doing this. Can I somehow have a "second grammar" that is specifically for expanding macros? (Does that even make sense?)
21:49 moritz jrtayloriv: not quite... I don't think lisp macros are expanded at text level
21:49 moritz but rather at AST level
21:50 jrtayloriv moritz, Right -- that's why I can't do it before past stage -- I need to do it during past
21:50 jrtayloriv sorry, I don't know right word for what I am after
21:50 purl after is about getting a side effect
21:50 allison Whiteknight: yes
21:50 jrtayloriv purl forget after
21:50 purl jrtayloriv: I forgot after
21:50 moritz jrtayloriv: right, durinig PAST stage, not in a new stage (I think)
21:50 allison Whiteknight: (that is, yes, you need to fill out a Parrot CLA)
21:51 jrtayloriv moritz, But I'm trying to figure out how to check that the define-syntax definition is syntactically correct.
21:51 jrtayloriv My grammar.pg just parses source text into s-expressions -- it doesn't deal with keywords like define or define-syntax
21:52 jrtayloriv Those are defined as variables in the top-level environment
21:52 moritz so you need to post-pone some syntax checks to the PAST level
21:52 jrtayloriv moritz, Yes, that's what I'm asking how to do. Are there any code examples I can look at for this?
21:53 * moritz looks at the rakudo sources
21:53 mokurai left #parrot
21:54 Whiteknight jrtayloriv: expand them at runtime
21:54 Whiteknight call back into your compiler object to compile them at runtime with the dynamic executing environment
21:55 moritz is that how lisp macros are supposed to work?
21:55 jrtayloriv moritz, (you asking about the example I posted?) Scheme macros are different from Lisp macros
21:55 moritz I didn't see the example you posted
21:56 jrtayloriv moritz, Oh, sorry -- yes, they should be expanded at run time -- local vars can shadow the names of macros.
21:57 moritz then forget everything I said ;-)
21:58 jrtayloriv Really? Then I was totally on the wrong track -- I thought you were saying that ... /me is confused
21:59 jrtayloriv Whiteknight, Did you mean expand them during 'eval' stage?
21:59 mokurai joined #parrot
22:00 nopaste joined #parrot
22:00 jrtayloriv The problem is that I need to expand them and then generate the past for the expressions that they expand to.
22:00 allison dukeleto: around?
22:01 Whiteknight jrtayloriv: yeah, I think a runtime eval would be best for those
22:01 moritz jrtayloriv: so you want to separate the text->s-exprs and the s-expr->PAST stages?
22:01 Whiteknight I don't know Scheme, so ignore most of what I say
22:01 moritz and that's why you want a new stage?
22:01 moritz makes some kind of sense :-)
22:03 dukeleto allison: howdy
22:03 purl hi, dukeleto.
22:03 allison dukeleto: I've just committed the hack I mentioned yesterday
22:03 allison dukeleto: you can now go ahead with test develoment on the pcc_reapply branch
22:04 allison dukeleto: we'll fully switchover to the new return handling when it passes the tests
22:04 Zak joined #parrot
22:04 dalek parrot: r41754 | allison++ | branches/pcc_reapply/src/call/args.c:
22:04 dalek parrot: [pcc] Keep the old code in place for testing development, while we finalize the
22:04 dalek parrot: new return handling.
22:04 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41754/
22:04 allison dukeleto: (but this way Tene and I can collaborate on the return handling at the same time)
22:05 jrtayloriv moritz, I'm not clear on the terminology, so bear with me ... the text->s-expr and s-expr->past stages are two different things. text->sexpr is where I take the text and break it up into either lists or literals, which have no meaning yet ... then when I do sexpr->past is when I say things like "the first element of this list is the symbol 'define' which is currently mapped to a builtin primitive, so build the past for that" ...
22:05 Whiteknight I haven't seen any commits on the return handling stuff lately
22:06 dukeleto allison: thanks, that is awesome
22:06 Whiteknight anything joe schmoe code monkey can do to help?
22:06 dukeleto allison++
22:06 Whiteknight that is, joe schmoe code monkey who doesn't know how returns work?
22:06 moritz jrtayloriv: right
22:06 allison Whiteknight: a code review on fill_results
22:06 dukeleto Whiteknight: write CallSignature tests
22:06 Whiteknight allison: On it!
22:06 allison Whiteknight: that's what I've been doing, fixing logic errors a few at a time
22:07 moritz but the default for a HLLCompiler is to translate directly from text to PAST
22:07 nopaste joined #parrot
22:07 moritz and that's what you're trying to change, right?
22:07 jrtayloriv yes
22:07 moritz ok
22:07 jrtayloriv (i think -- I'm not quite clear on it yet)
22:07 allison Whiteknight: the basic idea is that it's the same as the algorithm we worked out for fill_params, except that we're looping over the results array and the returns flags, instead of the args array and params flags
22:08 jrtayloriv I'm trying to get help getting clear on it ;)
22:08 moritz so I know what you want, and why you want it
22:08 moritz just not how to do it :/
22:09 jrtayloriv I've been unable to find any examples or docs that come close to what I'm trying to do, but I'm fairly certain that it's the right way to go about it.
22:09 allison Whiteknight: named returns are going to need slightly different logic, though. It might be worth another pseudocode round
22:09 jrtayloriv Just about everything I've read on Scheme compilers/interpreters is saying this is how it should be done
22:09 moritz jrtayloriv: did you try perldoc compilers/pct/src/PCT/HLLCompiler.pir yet?
22:09 jrtayloriv s/perldoc/less/ and yes
22:10 moritz so
22:11 moritz you need to add a stage after parseactions, I suppose
22:11 jrtayloriv OK I know how to add a stage, I think, I just don't know what my stage should do exactly, and what it would be operating on. That's what I was originally going to do, but then I convinced myself that I should somehow try to do it during past ...
22:11 jrtayloriv Perhaps it's time for some more headscratching time for me.
22:12 moritz I think you should it organize like this:
22:12 jrtayloriv I had parse->expand_syntax->past
22:12 moritz in the parseactions phase you just reduce the match objects to lists of lists
22:12 moritz and then in the new stage you do lists of lists -> past
22:13 moritz but I'm currently at loss about the details too
22:14 jrtayloriv My original idea was to somehow make the second stage look like "lists of lists -> expanded lists of lists"
22:14 jrtayloriv and then in past stage do "expanded lists -> past"
22:15 jrtayloriv But like I said, I think I just need to stare at it longer, because I'm not even sure if what I'm saying right now is any more meaningful than  "bdj9335kdkf"
22:15 moritz that's compile time macro expansion
22:16 moritz if that's what your language specs, that's fine
22:18 jrtayloriv moritz, Thanks for the help -- I'm off to read more about exactly when the expansion happens, so I can come back with clearer question.
22:19 moritz jrtayloriv: you're welcome. I hope somebody more competent can answer then ;-)
22:20 nopaste joined #parrot
22:22 Whiteknight allison: prior to last weekend, I haven't pseudocoded since undergrad
22:22 Whiteknight so I'm happy to flex that muscle a little more :)
22:23 patspam joined #parrot
22:24 * darbelo pseudocodes in C
22:27 Whiteknight darbelo: Normally I call all my pseudocode "perl"
22:27 Whiteknight and the best part is that it runs!
22:28 darbelo Whiteknight: What's the prize on your frame-builder contest?
22:29 darbelo s/prize/no-prize/g
22:29 Whiteknight darbelo: free Parrot T-Shirt
22:30 nopaste joined #parrot
22:30 darbelo I'm looking at DynASM now, ant it loks pretty easy to hack one up.
22:31 darbelo Does it have to work post pcc_realply or is current trunk ok?
22:32 Whiteknight DynASM?
22:32 darbelo Part of the lua jit.
22:34 darbelo http://luajit.org/dynasm.html
22:35 Whiteknight ah yes, okay
22:35 Whiteknight (so many JIT engines, so little brain space)
22:37 darbelo it's x86-only, which sucks. But if there's a free T-Shirt, I'm all for it ;)
22:37 Whiteknight that's the attitude!
22:38 darbelo That's how I got into SoC ;)
22:38 TonyC joined #parrot
22:38 moritz hey, I also got a free t-shirt from SoC this year, and I was only a backup mentor
22:39 darbelo That's why I got my commit bit. So I can get the shirt without having to code next year ;)
22:39 Whiteknight moritz: me too. Thanks Darbelo!
22:39 dukeleto lulz. people go crazy over those shirts
22:40 Whiteknight I don't think I have paid for a new tshirt in about 10 years. People keep giving them to me for free
22:40 nopaste joined #parrot
22:40 moritz I did mentor a student last year, though
22:40 darbelo Whiteknight: Same here, except I just keep wearing the old ones.
22:40 darbelo ;)
22:41 moritz dukeleto: actually of all the geek t-shirts I own, people most often ask me about the SoC ones
22:41 moritz "did you really participate, or did you get that from somewhere else?"
22:42 darbelo "Nah, I stole it from some dude's laundry basket."
22:42 jsut_ joined #parrot
22:42 moritz or people expect that I bought it from ebay or so
22:42 dukeleto moritz: that is funny. just say that you do LH's laundry :)
22:42 Whiteknight I don't understand how anything could work if we turned off argment checking exceptions in Parrot
22:42 moritz ;-)
22:43 Whiteknight I suspect there would be segfaults everywhere, for every violation
22:43 Whiteknight I can't think of a single benefit
22:43 moritz my girlfriend works for Puma, I don't need to buy any t-shirts at all ;-)
22:44 Whiteknight moritz: lucy!
22:44 Whiteknight lucky!
22:44 moritz aye
22:45 Whiteknight I mean, we have :optional and :slurpy parameters, I don't know why we would also need to implicitly pass the wrong number of parameters without warning
22:45 moritz for enhanced confusion mode on April 1st
22:50 nopaste joined #parrot
22:53 dalek parrot: r41755 | mikehh++ | branches/pcc_reapply/src/call/args.c:
22:53 dalek parrot: fix codetest failures - trailing spaces, line length and for( to for (
22:53 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41755/
23:00 nopaste joined #parrot
23:01 nopaste joined #parrot
23:03 jsut joined #parrot
23:05 payload joined #parrot
23:09 dalek parrot: r41756 | whiteknight++ | branches/pcc_reapply/src/call/args.c:
23:09 dalek parrot: [pcc] remove XXX note, we don't need to worry about :flat here
23:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41756/
23:10 nopaste joined #parrot
23:11 * Whiteknight is going to be so happy when it's time to unify args and returns
23:11 darbelo February?
23:11 purl i guess February is not the best month to visit Mtl. A bit cold, you know...
23:12 cotto_work RSN
23:13 darbelo Hmm. We should start taking notes of what we want to deprecate for the January release.
23:14 darbelo I have "In place string modification." on my kill-list.
23:16 Zak joined #parrot
23:17 cotto_work string mutability?
23:17 darbelo The opposite, I want inmutable strings.
23:17 cotto_work right.  You want to kill string mutability.
23:18 darbelo Yes.
23:19 darbelo Some of the work is already done for COW, but there's still a lot of copying arround "Just in case it's modified by someone else."
23:20 nopaste joined #parrot
23:20 darbelo It's likely to speed us up.
23:20 Whiteknight immutable strings would probably be a performance win
23:20 Whiteknight but making it work with our current memory management scheme is going to be a headache
23:21 Whiteknight of course, our current string manager is a headache already, so no change
23:21 darbelo Whiteknight: Making it *attemptable* requires a pretty big deprecation notice in 2.0
23:22 Whiteknight of course, that's a bit of semantic change for us, so you want to make sure that's cool with allison et al first
23:26 TonyC joined #parrot
23:30 nopaste joined #parrot
23:33 TonyC joined #parrot
23:35 TonyC joined #parrot
23:36 TonyC joined #parrot
23:40 nopaste joined #parrot
23:42 dalek parrot: r41757 | mikehh++ | trunk (3 files):
23:42 dalek parrot: clear up some compiler warnings from r41602
23:42 dalek parrot: review: https://trac.parrot.org/parrot/changeset/41757/
23:46 mikehh messages
23:47 cotto_work massages
23:47 purl You have no massages waiting.
23:48 mikehh pity - I could do with one :-}
23:48 cotto_work from purl?
23:48 mikehh if she is a good girl :-}
23:48 purl thanks mikehh :)
23:49 darbelo purl: are you a good girl?
23:49 purl :)
23:53 mikehh darbelo: done anything on decimal_dynpmcs recently - you mentioned quad I think?
23:53 darbelo ENOTUITS
23:54 darbelo But I can probably finish that this week.
23:54 mikehh have to try and send you some :-}
23:56 mikehh you moved it into plumage?
23:57 darbelo First project to correctly complete the fetch-build-test-install cycle :)
23:57 japhb mikehh, well, plumage can happily install it, but of course it remains in a separate repo ....
23:57 kid51 joined #parrot
23:58 chromatic joined #parrot
23:58 Whiteknight allison: ping

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

Parrot | source cross referenced