Parrot 1.0 Released | parrot.org | 380 RTs left!
Set by moderator on 28 March 2009.
00:00 tetragon joined 00:09 AndyA joined 00:40 kid51 joined 00:42 darbelo left
dalek rrot: r37860 | pmichaud++ | trunk (4 files):
Merge refactors from p6strings branch into trunk.
 00:52
allison Tene: still around? 01:01
01:09 eternaleye joined, baest joined, Tene joined, mikehh joined, jonathan joined 01:10 elmex joined, Hunger joined, dalek joined 01:11 Maddingue joined 01:14 pmichaud joined 01:15 PerlJam joined
dalek rrot: r37861 | jkeenan++ | trunk (2 files):
Merge dir_simplify branch into trunk. This eliminates 3 long-deprecated configure attributes as per trac.parrot.org/parrot/ticket/524.
 01:24
rrot: r37862 | jkeenan++ | branches/dir_simplify:
Branch has been merged into trunk and is no longer needed at HEAD.
purl i already had it that way, dalek.
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 02:01 Andy joined
kid51 One follow-up correction on that merge coming up. 02:17
mikehh Coke: Headerizer.pm is failing codetest - r35853 as at r37862 02:25
s/35853/37853/ 02:27
02:29 contingencyplan joined
dalek rrot: r37863 | jkeenan++ | trunk/config/gen/makefiles/parrot_pc.in:
Correct two usages of deprecated configuration attributes (TT #524).
 02:30
rrot: r37864 | jkeenan++ | trunk/lib/Parrot/Headerizer.pm:
codingstd: No cuddled 'else's.
rrot: r37865 | jkeenan++ | trunk/lib/Parrot/Headerizer.pm:
codingstd: No trailing whitespace.
 02:33
02:36 janus joined 02:48 Theory joined 02:54 GeJ joined
dalek rrot: r37866 | pmichaud++ | trunk/src/pmc/codestring.pmc:
[codestring]: Update charname_to_ord to use unicode extended names
 03:06
03:08 tetragon joined
dalek rrot: r37867 | chromatic++ | trunk/t/pmc/codestring.t:
[t] Fixed number of skipped tests when ICU is not present.
 03:16
03:42 mikehh joined
dalek kudo: 4d74d0c | pmichaud++ | (2 files):
Add initial support for \\cC and \\c[UNICODE CHAR NAME].
 03:57
shorten dalek's url is at xrl.us/beng7j
dalek kudo: 64e33af | pmichaud++ | build/PARROT_REVISION:
Another bump of PARROT_REVISION to get Parrot/PGE bugfixes.
shorten dalek's url is at xrl.us/beng7m
04:03 cognominal joined
bacek_ pmichaud: is it makes sense to generate bytecode directly from POST? 04:30
(I'm asking because I'm going to do this :)
pmichaud bacek_: sure, it makes sense. 04:31
bacek_ pmichaud: good to know.
purl good to know. is, like, there an ETA for dust starting to settle, or is it just finished when its finished
dalek rrot: r37868 | pmichaud++ | trunk/compilers/pge/PGE/Perl6Regex.pir:
[pge]: Improve error message on unrecognized char names.

  [pge]: Allow \\x, \\c, and \\o in enumerated character classes (incl ranges)		 04:32
bacek_ purl: bad girl
purl bacek_: what?
04:32 dalek joined
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:33
than we can use IMCC only for bootstrapping. And use PCT to parse PIR. 04:34
pmichaud bacek_: parsing PIR with PCT is likely to be very slow. 04:35
Coke jkeenan++ #codetest fix
bacek_ pmichaud: yes. But this problem will be reduced with direct generating bytecode from POST. 04:36
04:45 cognominal joined 04:59 tuxdna joined
05:58 uniejo joined 06:25 tuxdna joined 06:45 flh joined
dalek kudo: 1a618d0 | pmichaud++ | build/PARROT_REVISION:
Bump PARROT_REVISION to handle \\c, \\x, \\o in enumerated character classes
 06:48
shorten dalek's url is at xrl.us/benhnr
07:03 contingencyplan joined 07:07 robinsmidsrod joined
robinsmidsrod just curious, how good is the javascript language in parrot? 07:08
cotto You can look at its test suite to get an idea of its maturity. 07:12
07:18 iblechbot joined
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:19
dalek kudo: eda14fa | (Moritz Lenz)++ | (2 files):
[Configure] use list-form of system() to deal with white spaces in file names
 07:20
shorten dalek's url is at xrl.us/benhpg
cotto It looks like pjs hasn't been updated to live outside svn. 07:25
robinsmidsrod cotto: does that mean that the code can be found somewhere else? 07:31
cotto robinsmidsrod: code.google.com/p/parrotjs/
robinsmidsrod is perl5 needed after parrot is installed, or is it just a build dependency? 07:38
cotto I could be forgetting something, but I think it's just needed for the build and test suite. 07:42
dalek kudo: 685bff1 | (Moritz Lenz)++ | docs/ChangeLog:
[docs] ChangeLog for \\c implementation
 07:44
shorten dalek's url is at xrl.us/benhq2
08:33 alvar joined
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:47
08:51 rdice joined
cotto robinsmidsrod, that may be necessary for pjs, but it's not typical for a parrot-hosted language. 08:56
Look at Rakudo to see how it should be done.
cotto sleeps 08:57
robinsmidsrod cotto: thanks for the input - was just planning on trying out a language I have some experience in before I try out rakudo 08:58
09:00 szabgab joined 09:04 cognominal joined
robinsmidsrod seems like the last snapshot of rakudo doesn't make properly with parrot 1.0.0 09:28
moritz robinsmidsrod: no, it requires a fairly recent parrot 09:29
robinsmidsrod: see build/PARROT_REVISION in rakudo
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:30
moritz robinsmidsrod: well, it's too stable :-) 09:31
robinsmidsrod moritz: hehe
moritz robinsmidsrod: it's mainly that PGE was improved to support Perl 6 better, and we use these features in Rakudo already 09:32
robinsmidsrod: for languages that don't expose the rule engine to the user it shouldn't matter all that much
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
moritz robinsmidsrod: only if they also want to ship Rakudo
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
none?
purl none is :/
moritz dunno
lolcode maybe
robinsmidsrod hehe
moritz but who would use that in production anyway?
oh, and hq9+ (or whatever it's called) is complete, from what I've heard 09:35
and befunge is said to be nearly complete as well :-)
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
but allison mentioned that she wants to work more on pynie
robinsmidsrod moritz: so basically, the only practical reason for installing parrot is to try out perl6, right? 09:37
moritz robinsmidsrod: or writing your own language 09:38
robinsmidsrod moritz: I assume that the jvm is not very capable either?
moritz java virtual machine?
robinsmidsrod moritz: yep, I saw it on the list 09:39
moritz it's very capable, but has different design goals
or are you talking about parrot-to-jvm translator?
robinsmidsrod moritz: no, the other way around, running java class files on parrot (isn't that what the jvm is for?)
moritz robinsmidsrod: I think we're talking about different jvm's :/ 09:40
robinsmidsrod moritz: I was thinking of code.google.com/p/parrot-jvm/ 09:41
moritz ah. I was talking about sun's JVM :-) 09:42
I know nothing about that project
TiMBuS the language i wrote is technically 'done'
moritz TiMBuS: which language?
TiMBuS implementation of joy
a stack based lisp, would be the best way to put it 09:43
moritz "the power of forth and lisp in one language" :-)
TiMBuS a stack based language that doesnt really need parsin, implemented using PCT's parser and a register based VM.
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
robinsmidsrod how speedy is parrot, anyone got any benchmarks? and is the startup penalty very high? 09:45
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
TiMBuS parrot is on the languages shootout page 09:47
shootout.alioth.debian.org/
bacek good evening 09:49
TiMBuS evenin 09:53
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:55
moritz TiMBuS: there's an iteration API in a DRAFT spec somehwere... 09:56
TiMBuS: perlcabal.org/syn/S07.html 09:57
09:58 contingencyplan_ joined
TiMBuS i've read that one and its kind of helpful, but some of it isnt really explained 09:58
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 09:59
moritz java vm? 10:00
purl java vm is about that size
TiMBuS .net
10:06 robinsmidsrod left 10:20 masak joined 10:27 alvar joined 10:52 Ademan joined
dalek kudo: ef59b9d | jnthn++ | t/spectest.data:
Add S16-filehandles/unlink.t to the spectests.
 11:06
kudo: db0264d | jnthn++ | src/ (3 files):
Make various built-ins that should use $*OUT and $*ERR actually use them.
shorten dalek's url is at xrl.us/benh3x
shorten dalek's url is at xrl.us/benh3z
dalek kudo: 3ad32e1 | jnthn++ | t/spectest.data:
Add S16-unfiled/rebindstdhandles.t to the spectests that we run.
shorten dalek's url is at xrl.us/benh33
11:31 cybertom joined
dalek kudo: 46987f7 | jnthn++ | src/parser/ (2 files):
Implement START term; small refactoring so we can use same code as for START statement.
 11:38
shorten dalek's url is at xrl.us/benh48
11:40 pjcj joined 11:44 cognominal joined
dalek kudo: d981bae | (Carl Masak)++ | src/builtins/control.pir:
tidied up default warning message slightly
 11:58
shorten dalek's url is at xrl.us/benh6j
dalek kudo: 4c2f0ce | (Carl Masak)++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/benh6m
12:14 alvar joined
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 12:37 ruoso joined 12:43 alvar_ joined 12:44 alvar joined
dalek kudo: 8bd87bb | jnthn++ | src/parser/actions.pm:
Implement lexical subs for the non-multi case.
 12:48
shorten dalek's url is at xrl.us/benh9e
dalek kudo: 8eb5225 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
shorten dalek's url is at xrl.us/benh9g
dalek kudo: c40f3b9 | jnthn++ | src/parser/actions.pm:
Corret mistake in anonymising lexical subs.
shorten dalek's url is at xrl.us/benh9i
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:08
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:09
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.
PerlJam Coke: I'll sacrifice a small animal to the karma gods for you. 13:44
13:46 Lorn joined 13:53 cognominal joined
Coke opens a headerizer bug. 13:55
14:03 rdice joined 14:05 gryphon joined 14:32 amoc joined 14:38 particle joined 14:43 Tene_ joined 14:44 uniejo joined
Coke anyone know if the .c files config/ should be headerizerable? 14:52
14:53 AndyA joined
particle hrmm... probably some of them, *maybe* all. 14:54
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 15:04 Psyche^ joined
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.
dalek kudo: 7a56d9e | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 340 files, 8049 passing, 0 failing
 15:13
shorten dalek's url is at xrl.us/benipm
15:19 davidfetter joined 15:34 uniejo joined 15:36 Andy joined
dalek kudo: 13ddade | jnthn++ | src/ (3 files):
First cut at implementing lexical multi subs.
 15:38
kudo: 9cdadc2 | jnthn++ | t/spectest.data:
Add S06-multi/lexical-multis.t to spectest.data.
shorten dalek's url is at xrl.us/benitd
dalek's url is at xrl.us/benitf
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.
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.
Andy Coke: What where?
Coke check your messages. =-)
purl, messages/
purl Coke: what?
Coke purl, messages?
purl To access purl's messages, msg me with the word "messages".
Andy are tou talking about perlbuzz? 15:42
or rakudo.org?
purl i guess rakudo.org is rakudo.org
15:49 alvar joined, Theory joined
allison changing locations 16:03
jonathan Anyone remember how to get Parrot to spit out pasm that a bit of PIR maps to? 16:16
pmichaud --pasm 16:18
jonathan ah, pbc_disassemble helps, nm
pmichaud (from ./parrot --help)
jonathan pmichaud: That makes it treat the input file as pasm
pmichaud oh.
jonathan But yes, I tried that one too. :-)
pmichaud --output=file.pasm 16:19
jonathan I thought find_sub_not_null_p_sc looked a lexical scopes...
pmichaud me too -- it just calls find_name 16:20
which is supposed to look at lexical scopes, iirc
jonathan Right.
Hmm. So that makes me wonder how at least one of my lexical multi tests pass if it ain't.
Yeah, it calls find_name
hmm 16:21
pmichaud =item C<PMC * Parrot_find_name_op(PARROT_INTERP, STRING *name, void *next)>
RT #46171 - THIS IS BROKEN - it doesn't walk up the scopes yet
(src/global.c:731)
jonathan That's curious, because in this case I only expect it to look in the current scope... :-|
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.
pmichaud that's what Parrot_find_pad does
so yes, I'm thinking bogus report.
jonathan Yes, Parrot_find_pad does 16:23
pmichaud how "current" is the current scope?
jonathan sub foo($x) { $x + 1 } 16:25
sub callit(&foo) { foo(1); }
callit({ $^x + 2 }) # prints 2, not 3
By my reckoning, very current.
erm, missing say, but
pmichaud is &foo being mapped to lexical 'foo' ?
(generally it is... but worth verifying in this case) 16:26
jonathan .lex "foo", param_40
yup
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 nopaste.snit.ch/16062
jonathan pmichaud: To be more accurate about the issue 16:28
If you comment out the first line of my example, it works.
pmichaud ohhhhhhhh
I know _exactly_ what the problem is.
This will suck.
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
pmichaud nopaste coming
jonathan But thing is, it uses the op find_sub_not_null
pmichaud does it? how do you know?
nopaste "pmichaud" at 72.181.176.220 pasted "lexical calls dont seem to work (for jonathan++)" (25 lines) at nopaste.snit.ch/16063 16:30
pmichaud the pasm that is generated will be different if there's a 'foo' sub in the namespace.
nopaste "jonathan" at 85.216.157.73 pasted "pmichaud - take a look at this" (28 lines) at nopaste.snit.ch/16064 16:31
jonathan See nopaste
oh?
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.
I'm guessing that imcc also needs to verify that there's not a lexical in scope of the same name first. 16:32
nopaste coming
jonathan dammit, you're right
000000000001-000000000002 000002: set_p_pc P0,PMC_CONST(6)
particle brr
rdice pmichaud: Hey hey. 16:33
jonathan Optimization fail.
particle look... a canadian!
pmichaud rdice: hiya!
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.
rdice Like, whenever you drive 3 hours north in order to experience culture.
particle yeah, it's nice having good indian food that close :)
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 nopaste.snit.ch/16065
pmichaud anyway, I'm *sure* that's the likely problem.
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.
jonathan pmichaud: I'd make it a PBC and use pbc_disaeesmble to get a better picture. 16:36
As it says, # IMCC does produce b0rken PASM files
pmichaud jonathan: I've noticed this before (call to find_sub versus directly invoking) -- just hadn't made the connection to lexicals yet 16:37
my nopaste 16063 convinces me it's the issue 16:38
in fact
jonathan pmichaud: I'm pretty convinced.
Thing is, changing anything in Parrot for this might well require a deprecation cycle or something.
pmichaud 16:28 <pmichaud> I know _exactly_ what the problem is.
16:28 <pmichaud> This will suck.
jonathan pmichaud: So, workaround in Rakudo? So if we know it's a lexical sub we emit something different? 16:39
pmichaud or we do the workaround in pct 16:40
pct knows about lexicals.
jonathan True.
I guess PCT doing the lifting here makes a Parrot solution later easier to offer to different languages.
(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 nopaste.snit.ch/16066
pmichaud the call to foo1 properly goes through find_sub_not_null 16:42
the call to foo2 doesn't.
jonathan Right, that's conclusive for sure.
pmichaud and the trace shows the difference.
jonathan Right.
nopaste "rdice" at 72.137.84.213 pasted "my probably-simple rakudo compile issue" (49 lines) at nopaste.snit.ch/16067 16:43
rdice any takers?
purl Sure rdice, I'll suck pineapple juice through the ham straw!
pmichaud rdice: are you using the distributed parrot 1.0.0 ?
rdice I can give info on my environment 'til the cows come home.
Yes.
the .tar.gz
purl somebody said the .tar.gz was the standard way to distribute file packages on the Internet. Thank you and have a nice day.
pmichaud rakudo doesn't build from installed parrot yet.
rdice Okay, that was easy. :-) 16:44
pmichaud parrot's install still has some issues
particle need install-dev, right?
pmichaud for latest build instructions, see rakudo.org/how-to-get-rakudo
particle is there a parrot-devel package, and does that work for rakudo?
pmichaud even install-dev isn't sufficient yet
particle sigh.
rdice aha.
See, I thought I was _saving_ myself trouble by skipping the --gen-parrot flag. 16:45
Looks like a little knowledge is a dangerous thing.
pmichaud no, you're making it worse. But at least you bothered to read the README :-)
rdice Okay, thanks, I'll be a good little monkey and do what I'm told. :-)
particle *pat* *pat*
pmichaud --gen-parrot will likely always dtrt, even when we get to installed parrots
(i.e., it'll look to see if you have a sufficiently advanced parrot install, and if so, use that.) 16:46
(if not, get a sufficiently advanced parrot and use it)
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.
Which aren't good for anything but "I, Mudd."
pmichaud not at all. if you mean to do evil with rakudo, you don't use --gen-parrot. 16:47
rdice fair nuff.
jonathan pmichaud: If it's going to be a PCT fix, would you rather I left that to you?
pmichaud jonathan: i won't get to it until a bit later today, but I will get it fixed, yes
if you want to take a crack at it, feel free. 16:48
but I suspect it's more comfortable for me to do it.
jonathan It's only going to win us one spectest, which I've todo'd.
And isn't blocking me.
pmichaud let me take a look at it, then. I also plan to file a parrot ticket about it.
(and that will happen today also)
jonathan So no rush for me. And yes, agree, you'd find it easier.
pmichaud this is an interesting one from a deprecation perspective :-) 16:49
jonathan Yes, that was exactly what I was thinking.
pmichaud on the one hand, the behavior is obviously broken (not according to spec)
so fixing the broken behavior shouldn't require a deprecation cycle
but there may be a lot of code relying on the broken behavior
jonathan On the other, it's something people can easily have come ot depend on.
pmichaud actually, I suspect not.
I think I can even prove it. How many folks are using lexicals outside of pct?
jonathan Heh, true. 16:50
Not so many I guess.
pmichaud and of those that are, how many of them can be depending on the broken behavior?
but it's still a very interesting question.
jonathan Aye, it may not hit many at all.
But yes, interesting to consider how to handle.
pmichaud so, I'll likely file a ticket, *and* hit the mailing list with an extended discussion
jonathan Sounds good.
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...
erm, PGE hacking
pmichaud oh, that reminds me
need to check if there are any very large t/spec files containing unicode characters
I think I have a PGE speed improvement for utf-8 strings
jonathan Nice 16:52
Cursor?
purl Cursor is on resultset
pmichaud not directly, no
(yes, Cursor is on its way)
jonathan Or from a refactor that is a preCursor to it? ;-)
pmichaud but internally in the way that PGE does its matches
dalek kudo: 1bf637c | jnthn++ | t/spectest.data:
Add S06-advanced_subroutine_features/lexical-subs.t to spectest.data.
shorten dalek's url is at xrl.us/beni5q
jonathan Sounds nice.
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.
I think I have done so before.
pmichaud okay.
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.
pmichaud There was also mention that icu doesn't work with 64-bit parrot, so that might be another blocker.
jonathan Are you thinking Rakudo is likely to become unusable without it? 16:54
pmichaud well, a large number of tests fail without it.
(but pass with it)
jonathan OK
pmichaud currently we fail ~500 tests because some platforms might not have icu
s/fail/skip/whatever
that number will increase to close to ~3000 as I add more PGE features 16:55
jonathan We really should run those, yes...
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.
the other approach would be to fix our harness so that it's smart enough to skip tests requiring icu 16:57
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
I think I might go for the harness approach. That feels cleaner.
jonathan I guess we either totally require it, or do something in the harness, yes.
spectest.data may be a good enough place to provide such a hint
pmichaud exactly.
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.
pmichaud yes, wfm also.
16:59 AndyA joined
pmichaud it's nice to have a workable plan. :-) 16:59
jonathan Yes. :-)
I'm happy to lexical multi subs in now. :-) 17:00
I was thinking about the :init / :outer issue though and also some other tickets.
my $x = 5; class Foo { say $x }
I'm thinking this should output 5?
But now, it won't because we run the say $x in an :init :load block 17:01
I'm wondering why we're doing that.
Why we aren't just invoking the class' block which constructs the class at the point we reach the class in the code.
Am I wrong in expecting that output, though?
PerlJam I think the body of the class is run before the execution of the assignment. 17:03
jonathan ah, ok
In that case we need to keep it as :init :load
PerlJam (It's clear from the spec that the body of a class def is run at compile time anyway)
jonathan *nod* 17:04
OK, so we really need to fix the :init / :outer bug. :-)
pmichaud my understanding is that the body of a class or module is BEGIN 17:05
jonathan Yes, you're right actually. Sorry...
Just wishful thinking on my part. ;-)
pmichaud I don't see that in the spec, however. 17:06
or I'm not acking for the correct phrase
jonathan In either case, the code represented by C<...> executes at compile 17:07
time
(below class Bar {...} # block is class definition
)
17:08 flh joined
PerlJam jonathan: for it to work, you'd need to have my $x = BEGIN { 42 }; class Foo { say $x; } 17:09
jonathan *nod*
PerlJam or whatever the other begin form is that I recall reading about but don't quite remember
is begin maybe?
Coke huhs. Seattle is as close to canada as albany is?
particle my first attempt at installing icu on win32 failed, as icu4c binary install doesn't contain icu-config 17:26
coke: ~120mi from vancouver 17:27
vancouver, bc, that is. ~140mi from vancouver, wa. 17:28
17:28 barney joined
Coke ah, you're closer than we are by an 75m 17:30
s/an/
particle further north than the northernmost point in maine, too 17:31
Infinoid George Vancouver got around, it seems. I was born in the WA one 17:34
particle i'll wave towards your birthplace next time i'm driving through 17:36
17:44 Khisanth joined
Theory seen allison 17:45
purl allison was last seen on #parrot 1 hours, 42 minutes and 17 seconds ago, saying: changing locations
jonathan Hmm. TT#500 is non-trivial to hunt down... 17:54
Ahhh. 17:56
pmichaud afk # lunch 17:57
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
And thus we take a different code-path when we returncc from the :init sub.
18:00 cognominal joined
Coke Andy: hey, I opened a headerizer bug, if you're looking for a perlian distraction. =-) 18:03
jonathan Oooh. I think I haz a fix... 18:12
Coke for my bug? =-) 18:13
jonathan Coke: No, 'fraid not. For TT#500. 18:14
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:17
jonathan Infinoid: With regard to the packfile PMCs not matching up? 18:18
Infinoid (well, "recent" relative to PDD13's creation)
Yeah. I don't really understand it, and it's blocking me
jonathan Aha.
Yes, I will try and do that soon, and if I forget bug me about it now and then.
Infinoid Thanks!
The roadmap item for packfile PMCs is due next month 18:19
Coke jonathan? 18:21
purl jonathan is mailto:jnthn@jnthn.net or trying to put together a grant application. or however seeing weird issues.
Coke "don't forget to update pdd133!"
jonathan :-P
I have a patch that fixes TT#500. :-) 18:22
Just gotta run through the usual make test etc to be sure it doesn't break anything else.
Andy Coke: not especially. 18:26
but I'm not surprised.
rg fyi: parrot builds and runs just fine with icu on freebsd/amd64
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:39
(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:40
18:52 NordQ joined
dalek rrot: r37870 | barney++ | trunk (11 files):
allow examples/sdl/blue_rect.pir to be run with installed parrot
 18:59
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
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
barney Some of the SDL examples are seqfaultint under Linux 19:09
dalek rrot: r37871 | barney++ | trunk/examples/sdl (7 files):
get rid of some "library/" in SDL examples
19:44 alvar joined
jonathan pmichaud: back 19:45
pmichaud: The Parrot patch doesn't break anything so far as I can see.
(wasn't expecting it would anyway)
So going to put that in now.
dalek rrot: r37872 | jonathan++ | trunk/compilers/imcc/parser_util.c:
[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
pmichaud looks at the patch. 19:52
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.
at any rate, it appears to be over my head. If it works, I'm happy :-)
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
Anyway, next I removed in rakudo the .lexical(0)
And as expected we no longer get leixcal $x not found errors. 19:55
pmichaud we now get the other problem you described?
jonathan Just a Null PMC coming back because it looks down the wrong static chain...
pmichaud right.
any reactions to my two ideas above about that?
dalek rrot: r37873 | jonathan++ | trunk/t/pmc/sub.t:
[t] Add test for TT#500 fix.
jonathan I don't quite see how to do the first one.
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.
pmichaud but essentially, when a sub is invoked, it ends up getting a new lexpad
jonathan But that's to late to recapture the block that this referenced.
erm, sorry
That had the init block as its outer
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.
that way any nested BEGIN blocks are referring to the (autoclosed) lexpad that corresponds to the first invocation of the outer block 19:57
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.
let's look at it this way
jonathan (not saying it's wrong, just that my brain hasn't caught up with where yours is at yet :-))
pmichaud { my $x = 5; class { method foo() { say $x; } } }
treating the outer { ... } as the "invocation of the mainline" 19:59
so, the class { ... } block gets invoked at BEGIN time
that block gets its own lexpad 20:00
it also links to the lexpad of its outer block
since the outer block isn't invoked yet, we "autoclose" and create one for the outer block
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()
all of this happens at :load :init time 20:01
when we then execute the outer block (the one that sets $x to 5), it normally receives a new lexpad
however, if we change 'invoke' so that instead of creating a new lexpad it re-uses the autoclosed lexpad
then the class block will be correctly referring to the $x in this first invocatio of the outer block 20:02
(and by linkage, foo() will see that $x in its outer scope)
jonathan You're talking about invoke in the Sub PMC, right? 20:04
pmichaud yes.
and only for the first invocation.
jonathan The lines below
purl the lines below are a bit painful too, but relate to the same thing.
pmichaud (in most cases there's only one invocation so that's not important)
jonathan if (!PMC_IS_NULL(sub->lex_info)) {
pmichaud yes.
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:05
the autoclosed lexpad would be in sub->ctx 20:06
jonathan Around line 289 we do blow that away of course... 20:08
So we'd need to keep hold of it from then.
pmichaud no.
or I don't understand why that's an issue.
jonathan if (PObj_get_FLAGS(SELF) & SUB_FLAG_IS_OUTER) { 20:09
/* release any previously held context */
if (sub->ctx)
Parrot_free_context(interp, sub->ctx, 1);
This comes before setting the new lexpad
pmichaud ah.
okay, we do have to re-order the steps.
20:09 geof joined
jonathan So the original context from the auto-close that the sub had gets freed here. 20:09
pmichaud actually, it's not freed. 20:10
because the BEGIN block still has a reference to it.
jonathan OK, it's ref count is decremented...
But on the next line we do sub->ctx = Parrot_context_ref(interp, context);
pmichaud oh. hrm.
you're right, I'm confusing contexts and lexpads a bit here. thinking. 20:11
I wonder how hard it would be to get the sub to re-use the autoclosed context that was created. 20:12
instead of creating a new one.
but that feels a bit messier. 20:13
what about this case...? 20:14
my $x; class A { $x = 5; }; say $x;
particle pmichaud: sounds like a tailcall, kinda
pmichaud would we expect $x to be 5 here?
jonathan That's really tricky to do right now because we never get to put a Perl6Scalar into $x 20:15
Before the $x = 5 in the block runs
pmichaud well, those sorts of issues are the major reason for Null PMC's that we get now.
jonathan Right.
That's a separate but probably somewhat related problem to the static chain linkage issues we have now though.. 20:16
One thought 20:17
purl One thought is to make it work like version, and store it in the package variable $AUTHORITY
jonathan Oh, no, bad thought...
PerlJam I would expect $x to be 5 whenever the say runs.
jonathan I was going to say what if after we ran the code that auto-closed we clear up the auto-closed chain.
So at runtime it then on the first invocation has to re-close. 20:18
dalek rrot: r37874 | Infinoid++ | trunk/compilers/imcc/parser_util.c:
[cage] Fix some trailing whitespace.
rrot: r37875 | coke++ | trunk/compilers/imcc/pbc.c:
[t/docs] add placeholders for function docs in this headerizered file
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.
rrot: r37876 | coke++ | trunk/src/exceptions.c:
[t/docs] more placeholder for real docs.
pmichaud oh, it might not be so bad.
(thinking)
we just need to re-bind the lexicals
PerlJam my $x; class A { $x = Foo.new; } say $x.WHAT; # I'd expect Foo to be output too 20:19
(assuming a class Foo exists in the proper scope)
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
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
i.e., the "autoclose" context acts like a compile-time binding 20:21
and the invocation ends up copying the bindings of the compile-time binding into its runtime lexpad
jonathan How would we easily make this work?
I guess there's always another slot on the sub for autoclose_context
dalek rrot: r37877 | coke++ | trunk/config/gen/platform (17 files):
[t/docs] fixup some function docs in these (not headerized) files.
 20:22
pmichaud I don't know that any of it comes "easy" :-)
jonathan And we can find that.
But it's an extra pointer per sub. :-|
Oh, or maybe some flags are free.
pmichaud I suspect there are other ways.
jonathan That'd be cheaper.
pmichaud we can flag the context instead ofthe sub.
jonathan Why not flag the sub?
pmichaud because we might have more flag bits available in a context already 20:23
also, it's the context that knows about autoclosing, not the sub.
"I'm an autoclose context"
there's also a question of whether second and subsequent invocations of the outer block should also get the autoclose's bindings
sub foo() { my $x; BEGIN { $x = 5; } say $x; }; foo(); foo(); 20:24
jonathan That one is even harder with pre-compilation in the mix. 20:25
dalek rrot: r37878 | coke++ | trunk/examples (5 files):
[t/docs] fixup some function docs in these (not headerized) files.
jonathan Since by the time we emit PIR there is now BEGIN block to run...
*is no...
pmichaud but the BEGIN block would be a :load :init
or run from a :load :init
so it still happens firstish
jonathan No, they run during the parse, before we even have a complete AST. 20:26
pmichaud they also have to run when loaded.
otherwise precompilation never works -- not even for classes.
dalek a: b74499a | (Francois Perrad)++ | src/lib/luaregex.pir:
fix balanced regex
shorten dalek's url is at xrl.us/benj4j
jonathan Ah.
We ain't doing that ATM.
pmichaud I think we are.
Tene_ I also think we are.
pmichaud I'm pretty sure I put that in when I did the 'use' refactoring.
jonathan For BEGIN blocks? 20:27
For classes yes, but not for BEGIN.
pmichaud oh. Essentially they're the same.
I might not have it for BEGIN, but it's the same mechanism we use for classes.
jonathan Though I suspect they only want :load and not :init.
pmichaud I think they might have only :load and not :init
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
maybe that was the module mainline
jonathan Yes. Class ones are :load :init because we don't actually do anything (yet) at compile time.
dalek rrot: r37879 | coke++ | trunk/t/codingstd/c_function_docs.t:
[t/docs] cleanup todos based on recent signature fixes in docs.
pmichaud anyway, I'm certain that can be handled. 20:29
going back to
sub foo() { my $x; BEGIN { $x = 5; } say $x; }; foo(); foo();
do we expect each invocation of foo() to output 5?
if yes, then I think the answer is "invoke auto-binds lexicals from any auto-closed lexpad) 20:31
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
That is, we want to re-use the whole auto-closed context.
pmichaud there's nothing in an auto-closed context but a lexpad.
and a pointer to its outer. 20:33
jonathan Because that's what the inner thingies are pointing at through their outer
(their outer_ctx pointer, that is)
Ah.
pmichaud those are the settings to "dummy" starting at line 326
we set
20:34 amoc joined
pmichaud dummy->current_sub 20:34
dummy->lex_pad
dummy->outer_ctx
(that's all)
jonathan Yes, I see... 20:35
pmichaud and actually, that's how we can decide if something is an auto-closed context. it has no return continuation :-) 20:36
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
jonathan But wait, that still doesn't help *that* much.
my $x = 42; class A { method x { say $x } }; A.x
pmichaud (yes, there's another problem I just realized with what I was thinking) 20:39
that doesn't look like a problem to me.
jonathan So here we invoke x, which notices its outer is the block of class A.
And then uses the context there as its outer_ctx
pmichaud sure, no problem.
jonathan But it's that one in turn that references the one with the wrong, auto-closed $x in.
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"?
pmichaud yes.
that's what I've been aiming at.
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.
the "sub" in this case being the mainline
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
pmichaud right.
jonathan Because that's what is pointed to.
pmichaud that's what came up later :-)
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:44
then another approach is to re-bind or copy the autoclosed's lexicals
upon invocation
copy isn't quite good enough, though, because then the nested inner sub isn't in the correct context chain
rebind solves that, but then all of the invocations of the outermost sub share the same storage for $x 20:45
so that's not good.
(re)setting the inner closures notion of "outer" is another possibility 20:46
that was my #2 from earlier
i.e., when mainline is executed, it finds its BEGIN subs and does fixups 20:47
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:48
(but I don't know if calling foo() twice should give 5 each time) 20:49
pmichaud PerlJam: they're totally different.
my $x = BEGIN { 5 } evaluates the 5 at BEGIN time but does the assignment at normal runtime 20:50
BEGIN { $x = 5 } does the assignment at BEGIN time
(unless I'm reading the spec wrong, or it's changed, or any of other random factors)
PerlJam yes, I guess that's right.
20:52 alvar joined
pmichaud for example (from S04): 20:52
$recompile_by = BEGIN { time } + $expiration_time;
evaluates BEGIN { time } during compilation and uses it as a constant afterwards
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 nopaste.snit.ch/16070
PerlJam each invocation of $foo should get a new $x, but there's only one $x available at BEGIN time
jonathan pmichaud: See the nopaste...
(Note: this doesn't actually seem to work...)
pmichaud the first part won't work, no. 20:54
unless Parrot set_new_context does a lot less initializing than I know about 20:55
context = Parrot_set_new_context(INTERP, sub->n_regs_used)
(line 271)
jonathan oh, damm 20:56
pmichaud right. Thus my comment earlier about "that seems messy"
jonathan Well, it's just moving the else outside of the ifdef... 20:57
(so we don't obliterate the context we just kept hold of)
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
jonathan: yes, but those elses aren't even in the code to begin with.
PREMATURE_OPT is false.
PerlJam pmichaud: kind of like a proto-$x?
pmichaud In fact, I think we should eliminate that code altogether, because Parrot_dup_context really isn't much of an optimization.
PerlJam: yes.
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 nopaste.snit.ch/16071
jonathan However, that causes the most fascinating of errors.
pmichaud I think that Parrot_set_new_context does more than simply alloc and initialize a context
note that autoclose uses Parrot_alloc_context while invocation uses Parrot_set_new_context 21:00
jonathan oh yes
a fair bit more in fact
(copies over various bits from the current context and then - perhaps more importantly - sets CONTEXT(interp) = ctx; 21:01
Coke finds a workaround to what he thinks is a headerizer bug, whee. 21:02
pmichaud (on phone) 21:05
rakudo: say "on \\c[BLACK TELEPHONE]" 21:06
moritz ENOBOT
pmichaud if we ignore the possibility of initialization inside of BEGIN blocks, then my #2 approach would seem easiest 21:07
i.e., when an outer block is executed, it resets any inner block contexts to its newly created ones 21:08
(for inner blocks that were :load :init or otherwise used an autoclose semantic)
there's also the note at the bottom of S04. 21:09
starting with "Some closure produce ..."
er, "Some closures produce ... " 21:10
(off phone)
jonathan Hmm. 21:12
pmichaud arguably my $x; class A { method x() { say $x; } }; # $x is a file-scoped lexical? 21:15
which would be different from
sub foo() { my $x; BEGIN { $x = 5; }; say $x; }
because $x is not file-scoped there.
so perhaps we fix up contexts only at the beginning of the mainline 21:16
as opposed to for every sub
jonathan Hmm, yes.
Good point...
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.
$wife says BEGIN { run to store and pick up supplies }, so I have to go
(i.e., "ASAP")
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?
particle long_running_discussion(); END { argument }
jonathan Sure.
pmichaud or, whenever one of us gets to it.
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. ;-)
pmichaud exactly, I figured that was also the case. :-)
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. :-)
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
but I'm starting to think it'll be a rakudo-or-pct specific solution.
jonathan Sure. Though if your exploration leads to code anyway... :-)
pmichaud okay.
anyway, I must leave now. bbiaw
jonathan ok, later
21:20 alvar joined
pmichaud btw, great work on TT #500 21:21
I'll be glad to eliminate the other workarounds related to that from PCT
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 nopaste.snit.ch/16072
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
Ah well, we're closer.
flh hi! so far i had no success with my question on parrot-dev, so i'm retrying here 21:29
jonathan Good luck! ;-)
flh could someone explain me how i can access arguments from C in a "invoke" vtable function
jonathan oh my... :-)
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 :)
jonathan flh: Hey, no fair, I'm in Slovakia! :-P
Let me find you a link to where I did it...
If you mean what I think you do, anyway.
flh: Look up get_args in github.com/rakudo/rakudo/blob/bb22e...ltisub.pmc 21:31
shorten jonathan's url is at xrl.us/benkbe
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
jonathan Ah, they do something a bit different.
Actually I ignore named args in that code... 21:32
flh get_args actually seems fine 21:33
I think I'll ignore named args for the moment also
jonathan Well, I ignore them because I don't need them here. :-)
flh sure, but I know that at some point in the future I'll have to take care of these 21:34
jonathan Sure. :-) 21:35
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:42
so let's try another question :) how can I pass arguments now? (before calling a VTABLE_invoke) 21:45
particle flh: what do you want the pir interface to look like? 21:48
$P0 = new ['curriedsub']; $S1 = 'value1'; $P0['named-arg1'] = $S1; $S2 = 'positional 1'; $P0[0] = $S1; # something like that? 21:50
then $P0('more args', :more_named_args('bar'));
?
flh not exactly, we should only pass arguments by invoking the sub 21:51
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)
new subs are generated
yes :)
moritz flh: so you want something like Haskell, where too few arguments automatically generate a "partial applied" function?
particle ok, not inplace.
moritz aka curried 21:53
particle so it seems.
flh moritz, definitely (it's not for haskell but for a cousin, namely caml)
particle when invoke is called with too few args, an exception is thrown 21:54
moritz flh: ah, I don't really know caml
particle the question is, can the exception be caught by the invoked pmc?
flh moritz, different syntax, eager evaluation (haskell is lazy), and some imperative constructions
jonathan flh: Ah, you're doing this to implement currying?
moritz flh: isn't that something you can detect at compile time? 21:55
flh: if it is as statically typed as haskell, you can...
flh: and generate explicit currying calls for the "too few args" case
flh good point, maybe yes
jonathan flh: Also, see how we do it in Rakudo. 21:56
github.com/rakudo/rakudo/blob/1bf63...s/Code.pir and see .sub 'assuming'
shorten jonathan's url is at xrl.us/benkej
flh pmichaud told me some time ago that rakudo implemented that using lexicals
jonathan Yeah, quite a neat trick. :-)
flh yet, because of ticket #103, I cannot write a curriedsub class in PIR 21:57
jonathan Will an approach like the one Rakudo is taking not help you? 21:59
(But yes, #103 is an annoying bug, but also very hard to fix.)
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:00
jonathan, with Rakudo's approach, I think I have to curry by hand every sub I create 22:02
22:02 Limbic_Region joined
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 :)
dalek kudo: 913094f | (Moritz Lenz)++ | docs/compiler_overview.pod:
[docs] extend compiler_overview.pod
 22:04
shorten dalek's url is at xrl.us/benkfk
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:06
pmichaud when invoke is overridden, self isn't the object being invoked 22:07
it's actually the PMC representing the routine that's being invoked
flh but when we're in object's invoke, SELF is the Object PMC, isn't it? 22:08
pmichaud no
that's what makes #103 a pain.
at least, not for PIR-based vtable overrids.
flh ok I understand better now :) 22:09
so (back to my question), what would be a C equivalent of set_args in PIR? 22:10
pmichaud afk # dinner 22:16
22:34 tetragon joined 22:44 Khisanth joined 23:00 alvar joined, alvar left 23:02 Theory_ joined 23:03 bacek_ joined 23:04 kid51 joined, bacek joined 23:17 TonyC joined
GeJ Good morning everyone 23:19
Tene_ Hi. 23:20
23:35 TiMBuS joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!