Camelia, the Perl 6 bug

IRC log for #parrot, 2009-04-02

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 tetragon joined #parrot
00:09 AndyA joined #parrot
00:40 kid51 joined #parrot
00:42 darbelo left #parrot
00:52 dalek parrot: r37860 | pmichaud++ | trunk (4 files):
00:52 dalek parrot: Merge refactors from p6strings branch into trunk.
00:52 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37860/
01:01 allison Tene: still around?
01:09 eternaleye joined #parrot
01:09 baest joined #parrot
01:09 Tene joined #parrot
01:09 mikehh joined #parrot
01:09 jonathan joined #parrot
01:10 elmex joined #parrot
01:10 Hunger joined #parrot
01:10 dalek joined #parrot
01:11 Maddingue joined #parrot
01:14 pmichaud joined #parrot
01:15 PerlJam joined #parrot
01:24 dalek parrot: r37861 | jkeenan++ | trunk (2 files):
01:25 dalek parrot: Merge dir_simplify branch into trunk.  This eliminates 3 long-deprecated configure attributes as per https://trac.parrot.org/parrot/ticket/524.
01:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37861/
01:25 dalek parrot: r37862 | jkeenan++ | branches/dir_simplify:
01:25 dalek parrot: Branch has been merged into trunk and is no longer needed at HEAD.
01:25 purl i already had it that way, dalek.
01:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37862/
01:40 diakopter Branch has been merged into trunk and?
01:40 purl rumour has it Branch has been merged into trunk and is no longer needed at HEAD
01:54 szabgab joined #parrot
02:01 Andy joined #parrot
02:17 kid51 One follow-up correction on that merge coming up.
02:25 mikehh Coke: Headerizer.pm is failing codetest - r35853 as at r37862
02:27 mikehh s/35853/37853/
02:29 contingencyplan joined #parrot
02:30 dalek parrot: r37863 | jkeenan++ | trunk/config/gen/makefiles/parrot_pc.in:
02:30 dalek parrot: Correct two usages of deprecated configuration attributes (TT #524).
02:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37863/
02:30 dalek parrot: r37864 | jkeenan++ | trunk/lib/Parrot/Headerizer.pm:
02:30 dalek parrot: codingstd:  No cuddled 'else's.
02:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37864/
02:33 dalek parrot: r37865 | jkeenan++ | trunk/lib/Parrot/Headerizer.pm:
02:33 dalek parrot: codingstd:  No trailing whitespace.
02:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37865/
02:36 janus joined #parrot
02:48 Theory joined #parrot
02:54 GeJ joined #parrot
03:06 dalek parrot: r37866 | pmichaud++ | trunk/src/pmc/codestring.pmc:
03:06 dalek parrot: [codestring]: Update charname_to_ord to use unicode extended names
03:06 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37866/
03:08 tetragon joined #parrot
03:16 dalek parrot: r37867 | chromatic++ | trunk/t/pmc/codestring.t:
03:16 dalek parrot: [t] Fixed number of skipped tests when ICU is not present.
03:16 dalek parrot: Removed trailing whitespace.
03:16 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37867/
03:42 mikehh joined #parrot
03:57 dalek rakudo: 4d74d0c | pmichaud++ |  (2 files):
03:57 dalek rakudo: Add initial support for \cC and \c[UNICODE CHAR NAME].
03:57 dalek rakudo: Bump PARROT_REVISION to get latest PGE features.
03:57 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​d74d0c2ed22640413049395568fe144ade63842
03:57 shorten dalek's url is at http://xrl.us/beng7j
03:57 dalek rakudo: 64e33af | pmichaud++ | build/PARROT_REVISION:
03:57 dalek rakudo: Another bump of PARROT_REVISION to get Parrot/PGE bugfixes.
03:57 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​4e33af023a605fab171e789dbb31f6b41177ff6
03:57 shorten dalek's url is at http://xrl.us/beng7m
04:03 cognominal joined #parrot
04:30 bacek_ pmichaud: is it makes sense to generate bytecode directly from POST?
04:30 bacek_ (I'm asking because I'm going to do this :)
04:31 pmichaud bacek_: sure, it makes sense.
04:31 bacek_ pmichaud: good to know.
04:31 purl good to know. is, like, there an ETA for dust starting to settle, or is it just finished when its finished
04:32 dalek parrot: r37868 | pmichaud++ | trunk/compilers/pge/PGE/Perl6Regex.pir:
04:32 dalek parrot: [pge]:  Improve error message on unrecognized char names.
04:32 bacek_ purl: bad girl
04:32 purl bacek_: what?
04:32 dalek joined #parrot
04:33 bacek_ pmichaud: my current idea: implement generating bytecode from POST; implement some kind of POST optimizer (constant folding, etc); implement generating POST from bytecode; ...; Profit!
04:34 bacek_ than we can use IMCC only for bootstrapping. And use PCT to parse PIR.
04:35 pmichaud bacek_: parsing PIR with PCT is likely to be very slow.
04:35 Coke jkeenan++ #codetest fix
04:36 bacek_ pmichaud: yes. But this problem will be reduced with direct generating bytecode from POST.
04:45 cognominal joined #parrot
04:59 tuxdna joined #parrot
05:37 dalek parrot: r37869 | pmichaud++ | trunk/compilers/pge/PGE/Perl6Regex.pir:
05:37 dalek parrot: [pge]:  Allow \x, \c, and \o in enumerated character classes (incl ranges)
05:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37869/
05:58 uniejo joined #parrot
06:25 tuxdna joined #parrot
06:45 flh joined #parrot
06:48 dalek rakudo: 1a618d0 | pmichaud++ | build/PARROT_REVISION:
06:48 dalek rakudo: Bump PARROT_REVISION to handle \c, \x, \o in enumerated character classes
06:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​a618d0bde7038c0f86bc4db04a7055e89fe9f9f
06:48 shorten dalek's url is at http://xrl.us/benhnr
07:03 contingencyplan joined #parrot
07:07 robinsmidsrod joined #parrot
07:08 robinsmidsrod just curious, how good is the javascript language in parrot?
07:12 cotto You can look at its test suite to get an idea of its maturity.
07:18 iblechbot joined #parrot
07:19 robinsmidsrod I tried to get some information about how to use it besides the pure source code, but it's hard to find anything, not even a README in the dist
07:20 dalek rakudo: eda14fa | (Moritz Lenz)++ |  (2 files):
07:20 dalek rakudo: [Configure] use list-form of system() to deal with white spaces in file names
07:20 dalek rakudo: Based on a patch by Vasily Chekalkin, bacek++. Hopefully closes RT #64054.
07:20 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​da14fa060dc08050e21d6703d3aadbc697ab01c
07:20 shorten dalek's url is at http://xrl.us/benhpg
07:25 cotto It looks like pjs hasn't been updated to live outside svn.
07:31 robinsmidsrod cotto: does that mean that the code can be found somewhere else?
07:31 cotto robinsmidsrod: http://code.google.com/p/parrotjs/
07:38 robinsmidsrod is perl5 needed after parrot is installed, or is it just a build dependency?
07:42 cotto I could be forgetting something, but I think it's just needed for the build and test suite.
07:44 dalek rakudo: 685bff1 | (Moritz Lenz)++ | docs/ChangeLog:
07:44 dalek rakudo: [docs] ChangeLog for \c implementation
07:44 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​85bff1e421cbfdd75e6f6a9113a7fdf56c46c37
07:44 shorten dalek's url is at http://xrl.us/benhq2
08:33 alvar joined #parrot
08:47 robinsmidsrod okay, I've installed parrot 1.0, and now I want to add a language to it (pjs) - am I really supposed to have to recompile parrot again to add a language to the runtime as stated in the pjs README? the practical problem is that make doesn't work because there is no Makefile in the pjs folder (pjs checkout from google svn)
08:51 rdice joined #parrot
08:56 cotto robinsmidsrod, that may be necessary for pjs, but it's not typical for a parrot-hosted language.
08:56 cotto Look at Rakudo to see how it should be done.
08:57 * cotto sleeps
08:58 robinsmidsrod cotto: thanks for the input - was just planning on trying out a language I have some experience in before I try out rakudo
09:00 szabgab joined #parrot
09:04 cognominal joined #parrot
09:28 robinsmidsrod seems like the last snapshot of rakudo doesn't make properly with parrot 1.0.0
09:29 moritz robinsmidsrod: no, it requires a fairly recent parrot
09:29 moritz robinsmidsrod: see build/PARROT_REVISION in rakudo
09:30 robinsmidsrod moritz: somewhat boring, I though parrot 1.0 was stable enough to build perl6 on, I guess it's still somewhat of a moving target since you need an SVN build of parrot?
09:31 moritz robinsmidsrod: well, it's too stable :-)
09:31 robinsmidsrod moritz: hehe
09:32 moritz robinsmidsrod: it's mainly that PGE was improved to support Perl 6 better, and we use these features in Rakudo already
09:32 moritz robinsmidsrod: for languages that don't expose the rule engine to the user it shouldn't matter all that much
09:33 moritz that said, there's stable and "stable" :-)
09:33 robinsmidsrod moritz: I have a feeling this is going to cause major headaches to distro builders that are probably anxious to get a parrot version into their repos
09:33 moritz robinsmidsrod: only if they also want to ship Rakudo
09:34 robinsmidsrod moritz: which of the languages are considered "production ready" in parrot?
09:34 moritz robinsmidsrod: and there's usually a Rakudo release two days after each parrot release, which works together with the released parrot
09:34 moritz none?
09:34 purl none is :/
09:34 moritz dunno
09:34 moritz lolcode maybe
09:34 robinsmidsrod hehe
09:34 moritz but who would use that in production anyway?
09:35 moritz oh, and hq9+ (or whatever it's called) is complete, from what I've heard
09:35 moritz and befunge is said to be nearly complete as well :-)
09:36 robinsmidsrod which is the python language that is considered more feature complete, I noticed that there were two available
09:36 moritz I think neither is getting anywhere yet
09:36 moritz but allison mentioned that she wants to work more on pynie
09:37 robinsmidsrod moritz: so basically, the only practical reason for installing parrot is to try out perl6, right?
09:38 moritz robinsmidsrod: or writing your own language
09:38 robinsmidsrod moritz: I assume that the jvm is not very capable either?
09:38 moritz java virtual machine?
09:39 robinsmidsrod moritz: yep, I saw it on the list
09:39 moritz it's very capable, but has different design goals
09:39 moritz or are you talking about parrot-to-jvm translator?
09:39 robinsmidsrod moritz: no, the other way around, running java class files on parrot (isn't that what the jvm is for?)
09:40 moritz robinsmidsrod: I think we're talking about different jvm's :/
09:41 robinsmidsrod moritz: I was thinking of http://code.google.com/p/parrot-jvm/
09:42 moritz ah. I was talking about sun's JVM :-)
09:42 moritz I know nothing about that project
09:42 TiMBuS the language i wrote is technically 'done'
09:42 moritz TiMBuS: which language?
09:42 TiMBuS implementation of joy
09:43 TiMBuS a stack based lisp, would be the best way to put it
09:43 moritz "the power of forth and lisp in one language" :-)
09:43 TiMBuS a stack based language that doesnt really need parsin, implemented using PCT's parser and a register based VM.
09:44 moritz :-)
09:44 TiMBuS i have plans on making an optimizer and stuff for it but ill probably move it off parrot when i do that
09:45 robinsmidsrod how speedy is parrot, anyone got any benchmarks? and is the startup penalty very high?
09:46 TiMBuS parrot itself isnt too bad. languages running on parrot.. hmm
09:46 robinsmidsrod I hope you don't mind me asking some newbish questions
09:47 TiMBuS parrot is on the languages shootout page
09:47 TiMBuS http://shootout.alioth.debian.org/
09:49 bacek good evening
09:53 TiMBuS evenin
09:55 TiMBuS are there any documents that explain how perl 6 laziness is supposed to work? its all kind of vague from what i see. the only thing i can tell for certain is how ranges work lazily.
09:56 moritz TiMBuS: there's an iteration API in a DRAFT spec somehwere...
09:57 moritz TiMBuS: http://perlcabal.org/syn/S07.html
09:58 contingencyplan_ joined #parrot
09:58 TiMBuS i've read that one and its kind of helpful, but some of it isnt really explained
09:59 robinsmidsrod completely off-topic: which (traditional) virtual machine software is simplest (and most stable) for a recent computer running vista x64? there are so many right now, and I just need one that works without problems
10:00 moritz java vm?
10:00 purl java vm is about that size
10:00 TiMBuS .net
10:06 robinsmidsrod left #parrot
10:20 masak joined #parrot
10:27 alvar joined #parrot
10:52 Ademan joined #parrot
11:06 dalek rakudo: ef59b9d | jnthn++ | t/spectest.data:
11:06 dalek rakudo: Add S16-filehandles/unlink.t to the spectests.
11:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/e​f59b9d1e022f6cb2446d31fc4b2aa8edf6c2735
11:06 dalek rakudo: db0264d | jnthn++ | src/ (3 files):
11:06 shorten dalek's url is at http://xrl.us/benh3x
11:06 dalek rakudo: Make various built-ins that should use $*OUT and $*ERR actually use them.
11:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​b0264dfc80dfe0536aaa11112580022f6ea6355
11:06 shorten dalek's url is at http://xrl.us/benh3z
11:06 dalek rakudo: 3ad32e1 | jnthn++ | t/spectest.data:
11:06 dalek rakudo: Add S16-unfiled/rebindstdhandles.t to the spectests that we run.
11:06 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/3​ad32e12815ee9256204794add560eed998df750
11:06 shorten dalek's url is at http://xrl.us/benh33
11:31 cybertom joined #parrot
11:38 dalek rakudo: 46987f7 | jnthn++ | src/parser/ (2 files):
11:38 dalek rakudo: Implement START term; small refactoring so we can use same code as for START statement.
11:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​6987f737a02c03650f3f7c528222d681f8d1bb8
11:38 shorten dalek's url is at http://xrl.us/benh48
11:40 pjcj joined #parrot
11:44 cognominal joined #parrot
11:58 dalek rakudo: d981bae | (Carl Masak)++ | src/builtins/control.pir:
11:58 dalek rakudo: tidied up default warning message slightly
11:58 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/d​981bae46b6d0a3dd1c11dd8c79f2829773bb306
11:58 shorten dalek's url is at http://xrl.us/benh6j
11:58 dalek rakudo: 4c2f0ce | (Carl Masak)++ | :
11:59 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
11:59 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/4​c2f0ced3f19159cbae43688afae0e1c2d7302db
11:59 shorten dalek's url is at http://xrl.us/benh6m
12:14 alvar joined #parrot
12:15 bacek msg Infinoid I have few ideas about TT#385. (I want it resolved 'cause I want actually implement various packfile*.pmc). I'll prepare proposal tomorrow morning (GMT+11)
12:15 purl Message for infinoid stored.
12:36 rg1 joined #parrot
12:37 ruoso joined #parrot
12:43 alvar_ joined #parrot
12:44 alvar joined #parrot
12:48 dalek rakudo: 8bd87bb | jnthn++ | src/parser/actions.pm:
12:48 dalek rakudo: Implement lexical subs for the non-multi case.
12:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​bd87bbe307521e6d66995f26f0439fba689e58c
12:48 shorten dalek's url is at http://xrl.us/benh9e
12:48 dalek rakudo: 8eb5225 | jnthn++ | :
12:48 dalek rakudo: Merge branch 'master' of git@github.com:rakudo/rakudo
12:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/8​eb5225098e7152774fc9352558fb0dd0477c6c6
12:48 shorten dalek's url is at http://xrl.us/benh9g
12:48 dalek rakudo: c40f3b9 | jnthn++ | src/parser/actions.pm:
12:48 dalek rakudo: Corret mistake in anonymising lexical subs.
12:48 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/c​40f3b92451eb802df5d9516fee56b4327c6f8e8
12:48 shorten dalek's url is at http://xrl.us/benh9i
13:08 Coke regarding the languages discussion, 1.0 is supposed to be the base on which to build stuff. most languages are either 1) like rakudo, targeting svn latest for new features., 2) partcl, not yet updated to deal with 1.0, 3) functional but not complete.
13:09 Coke I can't speak to a lot of the languages though, since all I see of them are occasional commits messages here with no real status reports.
13:38 Coke cold fusion makes everything too simple, except for those things it makes impossible. :|
13:38 * Coke hopes someday to get paid to work in a language he actually likes.
13:44 PerlJam Coke: I'll sacrifice a small animal to the karma gods for you.
13:46 Lorn joined #parrot
13:53 cognominal joined #parrot
13:55 * Coke opens a headerizer bug.
14:03 rdice joined #parrot
14:05 gryphon joined #parrot
14:32 amoc joined #parrot
14:38 particle joined #parrot
14:43 Tene_ joined #parrot
14:44 uniejo joined #parrot
14:52 Coke anyone know if the .c files config/ should be headerizerable?
14:53 AndyA joined #parrot
14:54 particle hrmm... probably some of them, *maybe* all.
14:55 particle how many non-generated c files are there under config/?
14:55 Infinoid Those are just test scripts to see whether a header or function is there by running a compiler on it, right?
14:58 uniejo joined #parrot
15:04 Psyche^ joined #parrot
15:10 Coke msg Andy I give up: I tried to sign in to perlbuzz to post a comment. needed an account, created one. tried to sign in to post a comment, invalid account. recreate account? account name in use. Here's my comment: the 10 day of 99$ pricing ended before you posted the link.
15:10 purl Message for andy stored.
15:13 dalek rakudo: 7a56d9e | pmichaud++ | docs/spectest-progress.csv:
15:13 dalek rakudo: spectest-progress.csv update: 340 files, 8049 passing, 0 failing
15:13 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/7​a56d9e718c8f9818af74766efa3eb7c638936eb
15:13 shorten dalek's url is at http://xrl.us/benipm
15:19 davidfetter joined #parrot
15:34 uniejo joined #parrot
15:36 Andy joined #parrot
15:38 dalek rakudo: 13ddade | jnthn++ | src/ (3 files):
15:38 dalek rakudo: First cut at implementing lexical multi subs.
15:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​3ddade4783a9420e4dba60d0c5f1e983259ac3f
15:38 dalek rakudo: 9cdadc2 | jnthn++ | t/spectest.data:
15:38 dalek rakudo: Add S06-multi/lexical-multis.t to spectest.data.
15:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​cdadc2e9220bc42388f3ad846fc67905eb87b8e
15:38 shorten dalek's url is at http://xrl.us/benitd
15:38 shorten dalek's url is at http://xrl.us/benitf
15:40 Coke msg andy AH. I have an email waiting. I didn't get a message that there was a verification step via email, I don't think.
15:40 purl Message for andy stored.
15:41 Coke msg andy HA HA. I followed the "activate your account" link, and am told (again) invalid account.
15:41 purl Message for andy stored.
15:41 Andy Coke: What where?
15:41 Coke check your messages. =-)
15:41 Coke purl, messages/
15:41 purl Coke: what?
15:41 Coke purl, messages?
15:41 purl To access purl's messages, msg me with the word "messages".
15:42 Andy are tou talking about perlbuzz?
15:42 Andy or rakudo.org?
15:42 purl i guess rakudo.org is http://rakudo.org
15:49 alvar joined #parrot
15:49 Theory joined #parrot
16:03 * allison changing locations
16:16 jonathan Anyone remember how to get Parrot to spit out pasm that a bit of PIR maps to?
16:18 pmichaud --pasm
16:18 jonathan ah, pbc_disassemble helps, nm
16:18 pmichaud (from ./parrot --help)
16:18 jonathan pmichaud: That makes it treat the input file as pasm
16:18 pmichaud oh.
16:18 jonathan But yes, I tried that one too. :-)
16:19 pmichaud --output=file.pasm
16:19 jonathan I thought find_sub_not_null_p_sc looked a lexical scopes...
16:20 pmichaud me too -- it just calls find_name
16:20 pmichaud which is supposed to look at lexical scopes, iirc
16:20 jonathan Right.
16:20 jonathan Hmm. So that makes me wonder how at least one of my lexical multi tests pass if it ain't.
16:20 jonathan Yeah, it calls find_name
16:21 jonathan hmm
16:21 pmichaud =item C<PMC * Parrot_find_name_op(PARROT_INTERP, STRING *name, void *next)>
16:21 pmichaud RT #46171 - THIS IS BROKEN - it doesn't walk up the scopes yet
16:21 pmichaud (src/global.c:731)
16:21 jonathan That's curious, because in this case I only expect it to look in the current scope... :-|
16:22 pmichaud but on reading the code, it looks to me as though it does walk up the scopes
16:22 jonathan Also, I think it calls something that does look up them...so it may be bogus.
16:22 pmichaud that's what Parrot_find_pad does
16:22 pmichaud so yes, I'm thinking bogus report.
16:23 jonathan Yes, Parrot_find_pad does
16:23 pmichaud how "current" is the current scope?
16:25 jonathan sub foo($x) { $x + 1 }
16:25 jonathan sub callit(&foo) { foo(1); }
16:25 jonathan callit({ $^x + 2 }) # prints 2, not 3
16:25 jonathan By my reckoning, very current.
16:25 jonathan erm, missing say, but
16:25 pmichaud is &foo being mapped to lexical 'foo' ?
16:26 pmichaud (generally it is... but worth verifying in this case)
16:26 jonathan .lex "foo", param_40
16:26 jonathan yup
16:27 jonathan And the call is emitted as a $P45 = "foo"($P44)
16:27 nopaste "pmichaud" at 72.181.176.220 pasted "lexical calls seem to work (for jonathan++)" (21 lines) at http://nopaste.snit.ch/16062
16:28 jonathan pmichaud: To be more accurate about the issue
16:28 jonathan If you comment out the first line of my example, it works.
16:28 pmichaud ohhhhhhhh
16:28 pmichaud I know _exactly_ what the problem is.
16:28 pmichaud This will suck.
16:29 pmichaud IMCC  translates   $P45 = "foo"($P44)  into a direct call to the 'foo' sub in the namespace, without first looking it up in the lexpad.
16:29 jonathan Well, this is why I was disassembling
16:29 pmichaud nopaste coming
16:29 jonathan But thing is, it uses the op find_sub_not_null
16:29 pmichaud does it?  how do you know?
16:30 nopaste "pmichaud" at 72.181.176.220 pasted "lexical calls dont seem to work (for jonathan++)" (25 lines) at http://nopaste.snit.ch/16063
16:30 pmichaud the pasm that is generated will be different if there's a 'foo' sub in the namespace.
16:31 nopaste "jonathan" at 85.216.157.73 pasted "pmichaud - take a look at this" (28 lines) at http://nopaste.snit.ch/16064
16:31 jonathan See nopaste
16:31 jonathan oh?
16:31 pmichaud yes.  imcc "optimizes" out the calls to find_sub_not_null if there's a sub of the same name in the current namespace.
16:32 pmichaud I'm guessing that imcc also needs to verify that there's not a lexical in scope of the same name first.
16:32 pmichaud nopaste coming
16:32 jonathan dammit, you're right
16:32 jonathan 000000000001-000000000002 000002:       set_p_pc P0,PMC_CONST(6)
16:32 particle brr
16:33 rdice pmichaud:  Hey hey.
16:33 jonathan Optimization fail.
16:33 particle look... a canadian!
16:33 pmichaud rdice: hiya!
16:34 rdice particle:  I'd think you Seattonians would have a passing familiarity with them.
16:34 pmichaud hmm, my nopaste doesn't quite help yet -- the pasm isn't what I expected.
16:34 rdice Like, whenever you drive 3 hours north in order to experience culture.
16:34 particle yeah, it's nice having good indian food that close :)
16:35 rdice Just try to avoid the gang wars and you'll be fine. :-)
16:35 nopaste "pmichaud" at 72.181.176.220 pasted "weird pasm output" (35 lines) at http://nopaste.snit.ch/16065
16:35 pmichaud anyway, I'm *sure* that's the likely problem.
16:35 rdice pmichaud:  Is this a good chan for rakudo tech support?  I'm trying to start up a rakudo project and trying to compile it from a git clone yesterday barfed.
16:36 jonathan pmichaud: I'd make it a PBC and use pbc_disaeesmble to get a better picture.
16:36 jonathan As it says, # IMCC does produce b0rken PASM files
16:37 pmichaud jonathan: I've noticed this before (call to find_sub versus directly invoking) -- just hadn't made the connection to lexicals yet
16:38 pmichaud my nopaste 16063 convinces me it's the issue
16:38 pmichaud in fact
16:38 jonathan pmichaud: I'm pretty convinced.
16:38 jonathan Thing is, changing anything in Parrot for this might well require a deprecation cycle or something.
16:38 pmichaud 16:28 <pmichaud> I know _exactly_ what the problem is.
16:38 pmichaud 16:28 <pmichaud> This will suck.
16:39 jonathan pmichaud: So, workaround in Rakudo? So if we know it's a lexical sub we emit something different?
16:40 pmichaud or we do the workaround in pct
16:40 pmichaud pct knows about lexicals.
16:40 jonathan True.
16:40 jonathan I guess PCT doing the lifting here makes a Parrot solution later easier to offer to different languages.
16:41 jonathan (As in, those built on PCT.)
16:41 nopaste "pmichaud" at 72.181.176.220 pasted "the proof that lexical sub calls are broken" (42 lines) at http://nopaste.snit.ch/16066
16:42 pmichaud the call to foo1 properly goes through find_sub_not_null
16:42 pmichaud the call to foo2 doesn't.
16:42 jonathan Right, that's conclusive for sure.
16:42 pmichaud and the trace shows the difference.
16:42 jonathan Right.
16:43 nopaste "rdice" at 72.137.84.213 pasted "my probably-simple rakudo compile issue" (49 lines) at http://nopaste.snit.ch/16067
16:43 rdice any takers?
16:43 purl Sure rdice, I'll suck pineapple juice through the ham straw!
16:43 pmichaud rdice:  are you using the distributed parrot 1.0.0 ?
16:43 rdice I can give info on my environment 'til the cows come home.
16:43 rdice Yes.
16:43 rdice the .tar.gz
16:43 purl somebody said the .tar.gz was the standard way to distribute file packages on the Internet. Thank you and have a nice day.
16:43 pmichaud rakudo doesn't build from installed parrot yet.
16:44 rdice Okay, that was easy. :-)
16:44 pmichaud parrot's install still has some issues
16:44 particle need install-dev, right?
16:44 pmichaud for latest build instructions, see  http://rakudo.org/how-to-get-rakudo
16:44 particle is there a parrot-devel package, and does that work for rakudo?
16:44 pmichaud even install-dev isn't sufficient yet
16:44 particle sigh.
16:44 rdice aha.
16:45 rdice See, I thought I was _saving_ myself trouble by skipping the --gen-parrot flag.
16:45 rdice Looks like a little knowledge is a dangerous thing.
16:45 pmichaud no, you're making it worse.  But at least you bothered to read the README :-)
16:45 rdice Okay, thanks, I'll be a good little monkey and do what I'm told. :-)
16:45 particle *pat* *pat*
16:45 pmichaud --gen-parrot will likely always dtrt, even when we get to installed parrots
16:46 pmichaud (i.e., it'll look to see if you have a sufficiently advanced parrot install, and if so, use that.)
16:46 pmichaud (if not, get a sufficiently advanced parrot and use it)
16:46 rdice But what if I mean to do evil with rakudo?  Then dtrt will be doing the wrong thing.  And then we're in the realm of Epimethian paradoxes.
16:46 rdice Which aren't good for anything but "I, Mudd."
16:47 pmichaud not at all.  if you mean to do evil with rakudo, you don't use --gen-parrot.
16:47 rdice fair nuff.
16:47 jonathan pmichaud: If it's going to be a PCT fix, would you rather I left that to you?
16:47 pmichaud jonathan: i won't get to it until a bit later today, but I will get it fixed, yes
16:48 pmichaud if you want to take a crack at it, feel free.
16:48 pmichaud but I suspect it's more comfortable for me to do it.
16:48 jonathan It's only going to win us one spectest, which I've todo'd.
16:48 jonathan And isn't blocking me.
16:48 pmichaud let me take a look at it, then.  I also plan to file a parrot ticket about it.
16:48 pmichaud (and that will happen today also)
16:48 jonathan So no rush for me. And yes, agree, you'd find it easier.
16:49 pmichaud this is an interesting one from a deprecation perspective :-)
16:49 jonathan Yes, that was exactly what I was thinking.
16:49 pmichaud on the one hand, the behavior is obviously broken (not according to spec)
16:49 pmichaud so fixing the broken behavior shouldn't require a deprecation cycle
16:49 pmichaud but there may be a lot of code relying on the broken behavior
16:49 jonathan On the other, it's something people can easily have come ot depend on.
16:49 pmichaud actually, I suspect not.
16:49 pmichaud I think I can even prove it.  How many folks are using lexicals outside of pct?
16:50 jonathan Heh, true.
16:50 jonathan Not so many I guess.
16:50 pmichaud and of those that are, how many of them can be depending on the broken behavior?
16:50 pmichaud but it's still a very interesting question.
16:50 jonathan Aye, it may not hit many at all.
16:50 jonathan But yes, interesting to consider how to handle.
16:50 pmichaud so, I'll likely file a ticket, *and* hit the mailing list with an extended discussion
16:50 jonathan Sounds good.
16:51 pmichaud looks like much of the rest of my day is writing tickets, blog posts, and mailing list questions.  :-|
16:51 jonathan Though I've probably just provided yet another distraction for you from PCT hacking...
16:51 jonathan erm, PGE hacking
16:51 pmichaud oh, that reminds me
16:51 pmichaud need to check if there are any very large t/spec files containing unicode characters
16:51 pmichaud I think I have a PGE speed improvement for utf-8 strings
16:52 jonathan Nice
16:52 jonathan Cursor?
16:52 purl Cursor is on resultset
16:52 pmichaud not directly, no
16:52 pmichaud (yes, Cursor is on its way)
16:52 jonathan Or from a refactor that is a preCursor to it? ;-)
16:52 pmichaud but internally in the way that PGE does its matches
16:52 dalek rakudo: 1bf637c | jnthn++ | t/spectest.data:
16:52 dalek rakudo: Add S06-advanced_subroutine_features/lexical-subs.t to spectest.data.
16:52 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/1​bf637c3e13edf33f2967dad5e2ca67ceafcdee8
16:52 shorten dalek's url is at http://xrl.us/beni5q
16:52 jonathan Sounds nice.
16:53 pmichaud another question:  do you currently build with icu?  if so, how difficult is it in your windows environment?
16:53 jonathan I currently don't.
16:53 jonathan I think I have done so before.
16:53 pmichaud okay.
16:53 jonathan In fact, ages back I did some of the initial work to get ICU building on Win32 to happen. But that really was years ago.
16:53 pmichaud There was also mention that icu doesn't work with 64-bit parrot, so that might be another blocker.
16:54 jonathan Are you thinking Rakudo is likely to become unusable without it?
16:54 pmichaud well, a large number of tests fail without it.
16:54 pmichaud (but pass with it)
16:54 jonathan OK
16:54 pmichaud currently we fail ~500 tests because some platforms might not have icu
16:54 pmichaud s/fail/skip/whatever
16:55 pmichaud that number will increase to close to ~3000 as I add more PGE features
16:55 jonathan We really should run those, yes...
16:56 jonathan I guess we just need to try and provide instructions for building with ICU and give people a dire warning if they try and --gen-parrot without it.
16:56 pmichaud another way of looking at it:  of the ~7500 tests we currently skip or ignore, at least ~2500 of those are strictly icu and/or unicode issues.
16:57 pmichaud the other approach would be to fix our harness so that it's smart enough to skip tests requiring icu
16:58 pmichaud I don't mind if people build w/o icu, that's fine --I just don't want false spectest failures because of it.
16:58 pmichaud I think I might go for the harness approach.  That feels cleaner.
16:58 jonathan I guess we either totally require it, or do something in the harness, yes.
16:58 jonathan spectest.data may be a good enough place to provide such a hint
16:58 pmichaud exactly.
16:59 pmichaud and for people who try to use a unicode feature but don't have ICU, they get a "ICU not installed" exception
16:59 jonathan OK, that approach works for me.
16:59 pmichaud yes, wfm also.
16:59 AndyA joined #parrot
16:59 pmichaud it's nice to have a workable plan.  :-)
16:59 jonathan Yes. :-)
17:00 jonathan I'm happy to lexical multi subs in now. :-)
17:00 jonathan I was thinking about the :init / :outer issue though and also some other tickets.
17:00 jonathan my $x = 5; class Foo { say $x }
17:00 jonathan I'm thinking this should output 5?
17:01 jonathan But now, it won't because we run the say $x in an :init :load block
17:01 jonathan I'm wondering why we're doing that.
17:01 jonathan Why we aren't just invoking the class' block which constructs the class at the point we reach the class in the code.
17:01 jonathan Am I wrong in expecting that output, though?
17:03 PerlJam I think the body of the class is run before the execution of the assignment.
17:03 jonathan ah, ok
17:03 jonathan In that case we need to keep it as :init :load
17:03 PerlJam (It's clear from the spec that the body of a class def is run at compile time anyway)
17:04 jonathan *nod*
17:04 jonathan OK, so we really need to fix the :init / :outer bug. :-)
17:05 pmichaud my understanding is that the body of a class or module is BEGIN
17:05 jonathan Yes, you're right actually. Sorry...
17:05 jonathan Just wishful thinking on my part. ;-)
17:06 pmichaud I don't see that in the spec, however.
17:06 pmichaud or I'm not acking for the correct phrase
17:07 jonathan In either case, the code represented by C<...> executes at compile
17:07 jonathan time
17:07 jonathan (below class Bar {...}     # block is class definition
17:07 jonathan )
17:08 flh joined #parrot
17:09 PerlJam jonathan: for it to work, you'd need to have  my $x = BEGIN { 42 };  class Foo { say $x; }
17:09 jonathan *nod*
17:09 PerlJam or whatever the other begin form is that I recall reading about but don't quite remember
17:09 PerlJam is begin maybe?
17:09 * Coke huhs. Seattle is as close to canada as albany is?
17:26 particle my first attempt at installing icu on win32 failed, as icu4c binary install doesn't contain icu-config
17:27 particle coke: ~120mi from vancouver
17:28 particle vancouver, bc, that is. ~140mi from vancouver, wa.
17:28 barney joined #parrot
17:30 Coke ah, you're closer than we are by an 75m
17:30 Coke s/an/
17:31 particle further north than the northernmost point in maine, too
17:34 Infinoid George Vancouver got around, it seems.  I was born in the WA one
17:36 particle i'll wave towards your birthplace next time i'm driving through
17:44 Khisanth joined #parrot
17:45 Theory seen allison
17:45 purl allison was last seen on #parrot 1 hours, 42 minutes and 17 seconds ago, saying: changing locations
17:54 jonathan Hmm. TT#500 is non-trivial to hunt down...
17:56 jonathan Ahhh.
17:57 pmichaud afk # lunch
17:59 jonathan OK, found a hint: if something is the target of an outer, then its return continuation is promoted to a full continuation.
17:59 jonathan And thus we take a different code-path when we returncc from the :init sub.
18:00 cognominal joined #parrot
18:03 Coke Andy: hey, I opened a headerizer bug, if you're looking for a perlian distraction. =-)
18:12 jonathan Oooh. I think I haz a fix...
18:13 Coke for my bug? =-)
18:14 jonathan Coke: No, 'fraid not. For TT#500.
18:17 Infinoid jonathan: Do you think you'll have a chance sometime in the next couple of weeks to update PDD13 with your recent annotations stuff?
18:18 jonathan Infinoid: With regard to the packfile PMCs not matching up?
18:18 Infinoid (well, "recent" relative to PDD13's creation)
18:18 Infinoid Yeah.  I don't really understand it, and it's blocking me
18:18 jonathan Aha.
18:18 jonathan Yes, I will try and do that soon, and if I forget bug me about it now and then.
18:18 Infinoid Thanks!
18:19 Infinoid The roadmap item for packfile PMCs is due next month
18:21 Coke jonathan?
18:21 purl jonathan is mailto:jnthn@jnthn.net or trying to put together a grant application. or however seeing weird issues.
18:21 Coke "don't forget to update pdd133!"
18:21 jonathan :-P
18:22 jonathan I have a patch that fixes TT#500. :-)
18:22 jonathan Just gotta run through the usual make test etc to be sure it doesn't break anything else.
18:26 Andy Coke: not especially.
18:26 Andy but I'm not surprised.
18:26 rg fyi: parrot builds and runs just fine with icu on freebsd/amd64
18:39 jonathan pmichaud: Going for dinner now. Turns out fixing :init being an outer target gets us closer to fixing the Rakudo bug that we want to, but not all of the way.
18:40 jonathan (Due to the auto-close done at init time meaning that we then end up referencing the auto-close outer inside the class rather than the one we want.)
18:52 NordQ joined #parrot
18:59 dalek parrot: r37870 | barney++ | trunk (11 files):
18:59 dalek parrot: allow examples/sdl/blue_rect.pir to be run with installed parrot
18:59 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37870/
19:07 pmichaud jonathan: (for when you get back)   we could potentially provide an option that re-uses an autoclosed lexpad if one was created
19:07 pmichaud or we could come up with a mechanism that re-attaches the BEGIN/INIT inner subs to the outer's new context when it's invoked
19:09 barney Some of the SDL examples are seqfaultint under Linux
19:09 dalek parrot: r37871 | barney++ | trunk/examples/sdl (7 files):
19:09 dalek parrot: get rid of some "library/" in SDL examples
19:09 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37871/
19:44 alvar joined #parrot
19:45 jonathan pmichaud: back
19:45 jonathan pmichaud: The Parrot patch doesn't break anything so far as I can see.
19:45 jonathan (wasn't expecting it would anyway)
19:45 jonathan So going to put that in now.
19:48 dalek parrot: r37872 | jonathan++ | trunk/compilers/imcc/parser_util.c:
19:48 dalek parrot: [core] Patch to resolve TT#500, where during use of the PIR compiler from compreg we would segfault if there was a :init block serving as the :outer of another block.
19:48 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37872/
19:52 * pmichaud looks at the patch.
19:53 jonathan pmichaud: There may be a need for a more general patch, or perhaps the need for this dies during the calling conventions refactor.
19:53 pmichaud or perhaps it dies as part of pirc.
19:53 pmichaud at any rate, it appears to be over my head.  If it works, I'm happy :-)
19:54 jonathan Anyone with more brainz than me is quite welcome to work out a better patch if they find reason to object to this one. :-)
19:54 jonathan Anyway, next I removed in rakudo the .lexical(0)
19:55 jonathan And as expected we no longer get leixcal $x not found errors.
19:55 pmichaud we now get the other problem you described?
19:55 jonathan Just a Null PMC coming back because it looks down the wrong static chain...
19:55 pmichaud right.
19:55 pmichaud any reactions to my two ideas above about that?
19:55 dalek parrot: r37873 | jonathan++ | trunk/t/pmc/sub.t:
19:55 dalek parrot: [t] Add test for TT#500 fix.
19:55 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37873/
19:55 jonathan I don't quite see how to do the first one.
19:56 pmichaud I think the first one is most like the way Perl 5 does things now (more)
19:56 jonathan The thing is that we do a capture_lex of the :init block itself.
19:56 pmichaud but essentially, when a sub is invoked, it ends up getting a new lexpad
19:56 jonathan But that's to late to recapture the block that this referenced.
19:56 jonathan erm, sorry
19:56 jonathan That had the init block as its outer
19:56 pmichaud what we can do instead is that when a sub is invoked the first time, we check to see if there was an autoclosed lexpad, and if so, we use it.
19:57 pmichaud that way any nested BEGIN blocks are referring to the (autoclosed) lexpad that corresponds to the first invocation of the outer block
19:58 jonathan I'm not quite sure I follow...
19:58 pmichaud the capture_lex would end up being essentially a noop, because the inner BEGIN block doesn't get invoked after that.
19:58 pmichaud let's look at it this way
19:58 jonathan (not saying it's wrong, just that my brain hasn't caught up with where yours is at yet :-))
19:58 pmichaud { my $x = 5;  class { method foo() { say $x; } } }
19:59 pmichaud treating the outer { ... }  as the "invocation of the mainline"
19:59 pmichaud so, the class { ... } block gets invoked at BEGIN time
20:00 pmichaud that block gets its own lexpad
20:00 pmichaud it also links to the lexpad of its outer block
20:00 pmichaud since the outer block isn't invoked yet, we "autoclose" and create one for the outer block
20:00 pmichaud the class block also does capture_lex on the block for method foo(), setting the class block as the outer scope for invocations of foo()
20:01 pmichaud all of this happens at :load :init time
20:01 pmichaud when we then execute the outer block (the one that sets $x to 5), it normally receives a new lexpad
20:01 pmichaud however, if we change 'invoke' so that instead of creating a new lexpad it re-uses the autoclosed lexpad
20:02 pmichaud then the class block will be correctly referring to the $x in this first invocatio of the outer block
20:02 pmichaud (and by linkage, foo() will see that $x in its outer scope)
20:04 jonathan You're talking about invoke in the Sub PMC, right?
20:04 pmichaud yes.
20:04 pmichaud and only for the first invocation.
20:04 jonathan The lines below
20:04 purl the lines below are a bit painful too, but relate to the same thing.
20:04 pmichaud (in most cases there's only one invocation so that's not important)
20:04 jonathan if (!PMC_IS_NULL(sub->lex_info)) {
20:04 pmichaud yes.
20:05 pmichaud yes, we'd need some way of detecting that the existing lexpad is a result of an autoclose... but I think that's doable.
20:06 pmichaud the autoclosed lexpad would be in sub->ctx
20:08 jonathan Around line 289 we do blow that away of course...
20:08 jonathan So we'd need to keep hold of it from then.
20:08 pmichaud no.
20:08 pmichaud or I don't understand why that's an issue.
20:09 jonathan if (PObj_get_FLAGS(SELF) & SUB_FLAG_IS_OUTER) {
20:09 jonathan /* release any previously held context */
20:09 jonathan if (sub->ctx)
20:09 jonathan Parrot_free_context(interp, sub->ctx, 1);
20:09 jonathan This comes before setting the new lexpad
20:09 pmichaud ah.
20:09 pmichaud okay, we do have to re-order the steps.
20:09 geof joined #parrot
20:09 jonathan So the original context from the auto-close that the sub had gets freed here.
20:10 pmichaud actually, it's not freed.
20:10 pmichaud because the BEGIN block still has a reference to it.
20:10 jonathan OK, it's ref count is decremented...
20:10 jonathan But on the next line we do sub->ctx = Parrot_context_ref(interp, context);
20:10 pmichaud oh.  hrm.
20:11 pmichaud you're right, I'm confusing contexts and lexpads a bit here.  thinking.
20:12 pmichaud I wonder how hard it would be to get the sub to re-use the autoclosed context that was created.
20:12 pmichaud instead of creating a new one.
20:13 pmichaud but that feels a bit messier.
20:14 pmichaud what about this case...?
20:14 pmichaud my $x;   class A { $x = 5; };   say $x;
20:14 particle pmichaud: sounds like a tailcall, kinda
20:14 pmichaud would we expect $x to be 5 here?
20:15 jonathan That's really tricky to do right now because we never get to put a Perl6Scalar into $x
20:15 jonathan Before the $x = 5 in the block runs
20:15 pmichaud well, those sorts of issues are the major reason for Null PMC's that we get now.
20:15 jonathan Right.
20:16 jonathan That's a separate but probably somewhat related problem to the static chain linkage issues we have now though..
20:17 jonathan One thought
20:17 purl One thought is to make it work like version, and store it in the package variable $AUTHORITY
20:17 jonathan Oh, no, bad thought...
20:17 PerlJam I would expect $x to be 5 whenever the say runs.
20:17 jonathan I was going to say what if after we ran the code that auto-closed we clear up the auto-closed chain.
20:18 jonathan So at runtime it then on the first invocation has to re-close.
20:18 dalek parrot: r37874 | Infinoid++ | trunk/compilers/imcc/parser_util.c:
20:18 dalek parrot: [cage] Fix some trailing whitespace.
20:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37874/
20:18 dalek parrot: r37875 | coke++ | trunk/compilers/imcc/pbc.c:
20:18 jonathan But (a) we don't have a good place to put that and (b) it makes it even harder to do the example you just posted.
20:18 dalek parrot: [t/docs] add placeholders for function docs in this headerizered file
20:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37875/
20:18 dalek parrot: r37876 | coke++ | trunk/src/exceptions.c:
20:18 dalek parrot: [t/docs] more placeholder for real docs.
20:18 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37876/
20:18 pmichaud oh, it might not be so bad.
20:18 pmichaud (thinking)
20:18 pmichaud we just need to re-bind the lexicals
20:19 PerlJam my $x; class A {  $x = Foo.new; } say $x.WHAT;  # I'd expect Foo to be output too
20:19 PerlJam (assuming a class Foo exists in the proper scope)
20:19 pmichaud i.e., we want to take the lexicals from the autoclosed context and make them the defaults in the newly created context
20:19 Ademan joined #parrot
20:20 jonathan That feels kinda messy too.
20:20 pmichaud it might not be so bad.  and it feels somewhat close to the way the perl 6 spec describes it
20:21 pmichaud i.e., the "autoclose" context acts like a compile-time binding
20:21 pmichaud and the invocation ends up copying the bindings of the compile-time binding into its runtime lexpad
20:21 jonathan How would we easily make this work?
20:21 jonathan I guess there's always another slot on the sub for autoclose_context
20:22 dalek parrot: r37877 | coke++ | trunk/config/gen/platform (17 files):
20:22 dalek parrot: [t/docs] fixup some function docs in these (not headerized) files.
20:22 pmichaud I don't know that any of it comes "easy"  :-)
20:22 dalek parrot: These files may never be headerized, but we still enforce c_function_docs.t
20:22 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37877/
20:22 jonathan And we can find that.
20:22 jonathan But it's an extra pointer per sub. :-|
20:22 jonathan Oh, or maybe some flags are free.
20:22 pmichaud I suspect there are other ways.
20:22 jonathan That'd be cheaper.
20:22 pmichaud we can flag the context instead ofthe sub.
20:22 jonathan Why not flag the sub?
20:23 pmichaud because we might have more flag bits available in a context already
20:23 pmichaud also, it's the context that knows about autoclosing, not the sub.
20:23 pmichaud "I'm an autoclose context"
20:23 pmichaud there's also a question of whether second and subsequent invocations of the outer block should also get the autoclose's bindings
20:24 pmichaud sub foo() { my $x;  BEGIN { $x = 5; } say $x; };   foo();  foo();
20:25 jonathan That one is even harder with pre-compilation in the mix.
20:25 dalek parrot: r37878 | coke++ | trunk/examples (5 files):
20:25 dalek parrot: [t/docs] fixup some function docs in these (not headerized) files.
20:25 dalek parrot: These files may never be headerized, but we still enforce c_function_docs.t
20:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37878/
20:25 jonathan Since by the time we emit PIR there is now BEGIN block to run...
20:25 jonathan *is no...
20:25 pmichaud but the BEGIN block would be a :load :init
20:25 pmichaud or run from a :load :init
20:25 pmichaud so it still happens firstish
20:26 jonathan No, they run during the parse, before we even have a complete AST.
20:26 pmichaud they also have to run when loaded.
20:26 pmichaud otherwise precompilation never works -- not even for classes.
20:26 dalek lua: b74499a | (Francois Perrad)++ | src/lib/luaregex.pir:
20:26 dalek lua: fix balanced regex
20:26 dalek lua: review: http://github.com/fperrad/lua/commit/b7​4499a5479348f069574b00fca609a2425dfc31
20:26 shorten dalek's url is at http://xrl.us/benj4j
20:26 jonathan Ah.
20:26 jonathan We ain't doing that ATM.
20:26 pmichaud I think we are.
20:26 Tene_ I also think we are.
20:26 pmichaud I'm pretty sure I put that in when I did the 'use' refactoring.
20:27 jonathan For BEGIN blocks?
20:27 jonathan For classes yes, but not for BEGIN.
20:27 pmichaud oh.  Essentially they're the same.
20:27 pmichaud I might not have it for BEGIN, but it's the same mechanism we use for classes.
20:27 jonathan Though I suspect they only want :load and not :init.
20:27 pmichaud I think they might have only :load and not :init
20:28 jonathan (Since we'll already have run them during the compile in the non-precompiled case.)
20:28 pmichaud I know that there are some blocks I put in that are only :load and not :init
20:28 pmichaud maybe that was the module mainline
20:28 jonathan Yes. Class ones are :load :init because we don't actually do anything (yet) at compile time.
20:28 dalek parrot: r37879 | coke++ | trunk/t/codingstd/c_function_docs.t:
20:28 dalek parrot: [t/docs] cleanup todos based on recent signature fixes in docs.
20:28 dalek parrot: review: https://trac.parrot.org/parrot/changeset/37879/
20:29 pmichaud anyway, I'm certain that can be handled.
20:29 pmichaud going back to
20:29 pmichaud sub foo() { my $x;  BEGIN { $x = 5; } say $x; };   foo();  foo();
20:29 pmichaud do we expect each invocation of foo() to output 5?
20:31 pmichaud if yes, then I think the answer is "invoke auto-binds lexicals from any auto-closed lexpad)
20:32 jonathan I still don't quite get how this is solving the issue though because it's about the chain of outer contexts surely, not just lexpads?
20:32 jonathan That is, we want to re-use the whole auto-closed context.
20:32 pmichaud there's nothing in an auto-closed context but a lexpad.
20:33 pmichaud and a pointer to its outer.
20:33 jonathan Because that's what the inner thingies are pointing at through their outer
20:33 jonathan (their outer_ctx pointer, that is)
20:33 jonathan Ah.
20:33 pmichaud those are the settings to "dummy" starting at line 326
20:33 pmichaud we set
20:34 amoc joined #parrot
20:34 pmichaud dummy->current_sub
20:34 pmichaud dummy->lex_pad
20:34 pmichaud dummy->outer_ctx
20:34 pmichaud (that's all)
20:35 jonathan Yes, I see...
20:36 pmichaud and actually, that's how we can decide if something is an auto-closed context.  it has no return continuation :-)
20:38 jonathan So are we saying that we detect it this way and then take the lexpad from that auto-closed context instead of creating a fresh one for the invocation?
20:38 pmichaud close
20:38 jonathan But wait, that still doesn't help *that* much.
20:38 jonathan my $x = 42; class A { method x { say $x } }; A.x
20:39 pmichaud (yes, there's another problem I just realized with what I was thinking)
20:39 pmichaud that doesn't look like a problem to me.
20:39 jonathan So here we invoke x, which notices its outer is the block of class A.
20:39 jonathan And then uses the context there as its outer_ctx
20:39 pmichaud sure, no problem.
20:39 jonathan But it's that one in turn that references the one with the wrong, auto-closed $x in.
20:40 pmichaud right, which is why we clean up on the invocation of the outer outer
20:40 jonathan Or are you saying that it's invoking the mainline in this case that says "oh hey, I was auto-closed, so re-use the existing context"?
20:40 pmichaud yes.
20:40 pmichaud that's what I've been aiming at.
20:41 jonathan So we don't alloc a new one, but just further populate the existing one?
20:41 pmichaud 19:56 <pmichaud> what we can do instead is that when a sub is invoked the first time, we check to see if there was an autoclosed lexpad, and if so, we use it.
20:41 pmichaud the "sub" in this case being the mainline
20:43 pmichaud and we have to reuse the context, not just the lexpad
20:43 jonathan autoclosed _lexpad_ isn't the issue though, it's the whole context
20:43 pmichaud right.
20:43 jonathan Because that's what is pointed to.
20:43 pmichaud that's what came up later :-)
20:43 pmichaud 20:12 <pmichaud> I wonder how hard it would be to get the sub to re-use the autoclosed context that was created.
20:44 pmichaud 20:12 <pmichaud> instead of creating a new one.
20:44 pmichaud then another approach is to re-bind or copy the autoclosed's lexicals
20:44 pmichaud upon invocation
20:44 pmichaud copy isn't quite good enough, though, because then the nested inner sub isn't in the correct context chain
20:45 pmichaud rebind solves that, but then all of the invocations of the outermost sub share the same storage for $x
20:45 pmichaud so that's not good.
20:46 pmichaud (re)setting the inner closures notion of "outer" is another possibility
20:46 pmichaud that was my #2 from earlier
20:47 pmichaud i.e., when mainline is executed, it finds its BEGIN subs and does fixups
20:48 PerlJam sub foo { my $x; BEGIN  { $x = 5 }; say $x }  seems substantially the same as  sub foo { my $x = BEGIN { 5 }; say $x } to me, btw
20:49 PerlJam (but I don't know if calling foo() twice should give 5 each time)
20:49 pmichaud PerlJam: they're totally different.
20:50 pmichaud my $x = BEGIN { 5 }   evaluates the 5 at BEGIN time but does the assignment at normal runtime
20:50 pmichaud BEGIN { $x = 5 } does the assignment at BEGIN time
20:50 pmichaud (unless I'm reading the spec wrong, or it's changed, or any of other random factors)
20:50 PerlJam yes, I guess that's right.
20:52 alvar joined #parrot
20:52 pmichaud for example (from S04):
20:52 pmichaud $recompile_by = BEGIN { time } + $expiration_time;
20:52 pmichaud evaluates BEGIN { time }   during compilation and uses it as a constant afterwards
20:53 PerlJam Conceptually, then BEGIN { $x = 5 } doesn't make enough sense to me then
20:53 nopaste "jonathan" at 85.216.157.73 pasted "pmichaud - did you mean something like this?" (26 lines) at http://nopaste.snit.ch/16070
20:53 PerlJam each invocation of $foo should get a new $x, but there's only one $x available at BEGIN time
20:53 jonathan pmichaud: See the nopaste...
20:53 jonathan (Note: this doesn't actually seem to work...)
20:54 pmichaud the first part won't work, no.
20:55 pmichaud unless Parrot set_new_context does a lot less initializing than I know about
20:55 pmichaud context               = Parrot_set_new_context(INTERP, sub->n_regs_used)
20:55 pmichaud (line 271)
20:56 jonathan oh, damm
20:56 pmichaud right.  Thus my comment earlier about  "that seems messy"
20:57 jonathan Well, it's just moving the else outside of the ifdef...
20:57 jonathan (so we don't obliterate the context we just kept hold of)
20:58 pmichaud PerlJam: that's why I'm wondering if   BEGIN { $x = 5 }    sets the default $x that subsequent invocations of foo() receive for their $x
20:58 pmichaud jonathan: yes, but those elses aren't even in the code to begin with.
20:58 pmichaud PREMATURE_OPT is false.
20:58 PerlJam pmichaud: kind of like a proto-$x?
20:58 pmichaud In fact, I think we should eliminate that code altogether, because Parrot_dup_context really isn't much of an optimization.
20:58 pmichaud PerlJam: yes.
20:59 pmichaud jonathan: at any rate, the 'else's are commented out by the #ifdef block
20:59 nopaste "jonathan" at 85.216.157.73 pasted "pmichaud - no, I meant this" (32 lines) at http://nopaste.snit.ch/16071
20:59 jonathan However, that causes the most fascinating of errors.
20:59 pmichaud I think that Parrot_set_new_context does more than simply alloc and initialize a context
21:00 pmichaud note that autoclose uses Parrot_alloc_context while   invocation uses Parrot_set_new_context
21:00 jonathan oh yes
21:00 jonathan a fair bit more in fact
21:01 jonathan (copies over various bits from the current context and then - perhaps more importantly - sets CONTEXT(interp)          = ctx;
21:02 * Coke finds a workaround to what he thinks is a headerizer bug, whee.
21:05 pmichaud (on phone)
21:06 pmichaud rakudo:  say "on \c[BLACK TELEPHONE]"
21:06 moritz ENOBOT
21:07 pmichaud if we ignore the possibility of initialization inside of BEGIN blocks, then my #2 approach would seem easiest
21:08 pmichaud i.e.,   when an outer block is executed, it resets any inner block contexts to its newly created ones
21:08 pmichaud (for inner blocks that were :load :init or otherwise used an autoclose semantic)
21:09 pmichaud there's also the note at the bottom of S04.
21:09 pmichaud starting with "Some closure produce ..."
21:10 pmichaud er, "Some closures produce ... "
21:10 pmichaud (off phone)
21:12 jonathan Hmm.
21:15 pmichaud arguably      my $x;  class A { method x() { say $x; } };  #   $x is a file-scoped lexical?
21:15 pmichaud which would be different from
21:15 pmichaud sub foo() { my $x; BEGIN { $x = 5; }; say $x; }
21:15 pmichaud because $x is not file-scoped there.
21:16 pmichaud so perhaps we fix up contexts only at the beginning of the mainline
21:16 pmichaud as opposed to for every sub
21:16 jonathan Hmm, yes.
21:16 jonathan Good point...
21:17 jonathan Meh. Attemtping to get this to work just leads to segfaults. :-~|
21:17 pmichaud yes, I'm thinking that the others are not the right approaches.
21:17 pmichaud $wife says   BEGIN { run to store and pick up supplies }, so I have to go
21:17 pmichaud (i.e., "ASAP")
21:18 jonathan OK
21:18 pmichaud can I suggest that I take an hour or two to think about it more, then I'll write an email to you and you can try implementing what I come up with?
21:18 particle long_running_discussion(); END { argument }
21:18 jonathan Sure.
21:18 pmichaud or, whenever one of us gets to it.
21:19 pmichaud but I'm thinking the "fix it up in mainline" approach is likely easiest.
21:19 jonathan tbh I'm getting kinda tired...I already fixed the Parrot bug and did lexical subs today. ;-)
21:19 pmichaud exactly, I figured that was also the case.  :-)
21:19 jonathan So I think this is best left for another day, or feel free to go ahead and patch if up if you get it clear in your head. :-)
21:20 pmichaud since I'm familiar with the lexicals code, it makes sense for me to explore the space a bit.  But it would also be good if someone else besides me did a bit of the implementing.
21:20 pmichaud but I'm starting to think it'll be a rakudo-or-pct specific solution.
21:20 jonathan Sure. Though if your exploration leads to code anyway... :-)
21:20 pmichaud okay.
21:20 pmichaud anyway, I must leave now.  bbiaw
21:20 jonathan ok, later
21:20 alvar joined #parrot
21:21 pmichaud btw, great work on TT #500
21:21 pmichaud I'll be glad to eliminate the other workarounds related to that from PCT
21:21 nopaste "jonathan" at 85.216.157.73 pasted "pmichaud - for when you're back and for reference, here's as far as I got" (37 lines) at http://nopaste.snit.ch/16072
21:22 jonathan Yeah, I'm glad to have crushed that bit. Just didn't occur to me that we'd then have to deal with a separate issue too.
21:22 jonathan Ah well, we're closer.
21:29 flh hi! so far i had no success with my question on parrot-dev, so i'm retrying here
21:29 jonathan Good luck! ;-)
21:29 flh could someone explain me how i can access arguments from C in a "invoke" vtable function
21:29 jonathan oh my... :-)
21:30 jonathan I think I've actually done that one at some point...
21:30 flh jonathan, but i know that people in the us are awake now :)
21:30 jonathan flh: Hey, no fair, I'm in Slovakia! :-P
21:30 jonathan Let me find you a link to where I did it...
21:30 jonathan If you mean what I think you do, anyway.
21:31 jonathan flh: Look up get_args in http://github.com/rakudo/rakudo/blo​b/bb22e02dc81513539ccc6061604ac89a2​9c000e0/src/pmc/perl6multisub.pmc
21:31 shorten jonathan's url is at http://xrl.us/benkbe
21:31 flh I guess I'm trying to do the same thing that happens with METHODs in PMCs, but I don't understand well the code generated by pmc2c for them
21:31 jonathan Ah, they do something a bit different.
21:32 jonathan Actually I ignore named args in that code...
21:33 flh get_args actually seems fine
21:33 flh I think I'll ignore named args for the moment also
21:33 jonathan Well, I ignore them because I don't need them here. :-)
21:34 flh sure, but I know that at some point in the future I'll have to take care of these
21:35 jonathan Sure. :-)
21:42 flh ok, this is wonderful :) A few days ago I tried to understand the code in iterator.pmc which does the same kind of things, but your (commented) get_args is definitely clearer
21:45 flh so let's try another question :) how can I pass arguments now? (before calling a VTABLE_invoke)
21:48 particle flh: what do you want the pir interface to look like?
21:50 particle $P0 = new ['curriedsub']; $S1 = 'value1'; $P0['named-arg1'] = $S1; $S2 = 'positional 1'; $P0[0] = $S1; # something like that?
21:50 particle then $P0('more args', :more_named_args('bar'));
21:50 particle ?
21:51 flh not exactly, we should only pass arguments by invoking the sub
21:52 particle ok, but if there aren't enough, they're just curried and a new sub generated?
21:52 flh let's say $P0 is a curriedsub which expects 2 positional arguments, then I'd like to have: $P1 = $P0(x); $P1(y)
21:52 flh new subs are generated
21:52 flh yes :)
21:52 moritz flh: so you want something like Haskell, where too few arguments automatically generate a "partial applied" function?
21:52 particle ok, not inplace.
21:53 moritz aka curried
21:53 particle so it seems.
21:53 flh moritz, definitely (it's not for haskell but for a cousin, namely caml)
21:54 particle when invoke is called with too few args, an exception is thrown
21:54 moritz flh: ah, I don't really know caml
21:54 particle the question is, can the exception be caught by the invoked pmc?
21:54 flh moritz, different syntax, eager evaluation (haskell is lazy), and some imperative constructions
21:54 jonathan flh: Ah, you're doing this to implement currying?
21:55 moritz flh: isn't that something you can detect at compile time?
21:55 moritz flh: if it is as statically typed as haskell, you can...
21:55 moritz flh: and generate explicit currying calls for the "too few args" case
21:55 flh good point, maybe yes
21:56 jonathan flh: Also, see how we do it in Rakudo.
21:56 jonathan http://github.com/rakudo/rakudo/blob/1bf637c3e13e​df33f2967dad5e2ca67ceafcdee8/src/classes/Code.pir and see .sub 'assuming'
21:56 shorten jonathan's url is at http://xrl.us/benkej
21:56 flh pmichaud told me some time ago that rakudo implemented that using lexicals
21:56 jonathan Yeah, quite a neat trick. :-)
21:57 flh yet, because of ticket #103, I cannot write a curriedsub class in PIR
21:59 jonathan Will an approach like the one Rakudo is taking not help you?
21:59 jonathan (But yes, #103 is an annoying bug, but also very hard to fix.)
22:00 flh moritz, ok, I'm not sure I want to detect currying at compile time, since it might not be possible because of "rectypes" (these allow to type a function "gargantua" which eats its single argument, and returns itself)
22:02 flh jonathan, with Rakudo's approach, I think I have to curry by hand every sub I create
22:02 Limbic_Region joined #parrot
22:03 jonathan Ah, is this the thing where you may not be sure whether or not a call is currying or a full invocation?
22:03 flh ok, this means I also have to care about too_many arguments :)
22:04 dalek rakudo: 913094f | (Moritz Lenz)++ | docs/compiler_overview.pod:
22:04 dalek rakudo: [docs] extend compiler_overview.pod
22:04 dalek rakudo: Patch courtesy of awwaiid@thelackthereof.org, closes RT #64368
22:04 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​13094f0634b1630f40475cbd19653aac40f5bde
22:04 shorten dalek's url is at http://xrl.us/benkfk
22:06 flh jonathan, btw about #103, if we have a (simple) way to play with arguments, couldn't we add some code in object.pmc (after line 622) to unshift self when invoke is overriden?
22:07 pmichaud when invoke is overridden, self isn't the object being invoked
22:07 pmichaud it's actually the PMC representing the routine that's being invoked
22:08 flh but when we're in object's invoke, SELF is the Object PMC, isn't it?
22:08 pmichaud no
22:08 pmichaud that's what makes #103 a pain.
22:08 pmichaud at least, not for PIR-based vtable overrids.
22:09 flh ok I understand better now :)
22:10 flh so (back to my question), what would be a C equivalent of set_args in PIR?
22:16 pmichaud afk # dinner
22:34 tetragon joined #parrot
22:44 Khisanth joined #parrot
23:00 alvar joined #parrot
23:00 alvar left #parrot
23:02 Theory_ joined #parrot
23:03 bacek_ joined #parrot
23:04 kid51 joined #parrot
23:04 bacek joined #parrot
23:17 TonyC joined #parrot
23:19 GeJ Good morning everyone
23:20 Tene_ Hi.
23:35 TiMBuS joined #parrot

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

Parrot | source cross referenced