Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-06-12

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

All times shown according to UTC.

Time Nick Message
00:53 jlaire joined #moarvm
01:12 benabik joined #moarvm
01:12 arnsholt joined #moarvm
01:14 * benabik is looking through validation.c at diakopter's suggestion.
01:16 diakopter don't be too harsh.. that's ... early C for me.
01:17 diakopter .oO( as if even the recent stuff isn't early too... )
01:18 benabik TODO says "validate any cu->strings index".  It seems like it already does that?  l. 130
01:18 benabik diakopter: Haven't noticed anything wrong with the code other than "I have no idea what any of this is."
01:25 FROGGS joined #moarvm
01:33 benabik coderef 1:1 static_frame?
01:34 benabik Ah.  Yes.
01:42 benabik Hm.  Well, I think I wrote the validation for literal code refs, but github seems to be down so I can't share.
01:43 benabik Be back later and hopefully github will be too.
01:59 benabik Well, pushed to https://github.com/Benabik/MoarVM/commit/​a115e378448512a1d9f5b41228e5932253b95d7a but github's slow/dead again.
02:32 arnsholt joined #moarvm
02:32 diakopter benabik: s/lables/labels/
02:33 benabik Hah, yes.
02:33 benabik You know, I should probably compile code before pushing it.  :-/
02:33 diakopter *giggle*
02:34 benabik There probably should be some tests for failed validation.  :-/
02:35 diakopter heh.
02:35 diakopter well..
02:35 diakopter I dunno.
02:35 diakopter I don't like tests.
02:35 diakopter .. and they don't like me.
02:38 benabik Tested now.  74a653a
02:38 benabik I at least didn't break anything.
02:38 diakopter heh.
02:38 benabik Well, didn't break anything that make test tests.  ;)
02:39 diakopter well, you modified that existing commit?
02:39 benabik Yeah.  I'm a fan of amending and rebasing.
02:39 benabik Until it's part of a major repository.
02:40 * benabik wouldn't amend a commit in MoarVM/MoarVM
02:42 benabik Looks like further validation work is, well, real work.
02:43 arnsholt joined #moarvm
02:45 benabik Hm.  The branch comment is interesting.
02:46 diakopter ?
02:46 diakopter which one
02:47 diakopter (it's probably my fault if it's interesting)
02:47 benabik "Also disallow anything that can branch from running between a prepargs and invoke"
02:47 diakopter oh. yeah.
02:47 diakopter well.
02:47 diakopter actually that's wrong :)
02:47 benabik No branches at all, or just nothing that escapes the area between the instructions?
02:48 diakopter the check actually needs to be prevent any branches *to* the region between a prepargs and its invoke
02:48 diakopter <- fail at writing todos
02:48 benabik Ah, full on branch analysis.
02:48 diakopter branching out of it is okay
02:49 diakopter (just can't come back to it)
02:50 benabik Need to propagate call backwards along jumps and ensure there's a prepargs before it?
02:52 diakopter eh, I think it's sufficient to just prevent any destination labels in the region. currently no compiler creates MAST that would violate that, afaik.
02:52 benabik Well, validators is generally not to protect against the friendly compilers.  ;)
02:52 diakopter well, true.
02:52 diakopter well
02:52 diakopter my rule is stronger :P
02:53 diakopter (and vastly simpler)
02:53 arnsholt joined #moarvm
02:53 benabik Yeah.  I'm a little worried about corner cases, but I think it could work.
02:54 benabik Basic rule: No jumps from outside a prep->call region to inside it
02:54 benabik Yes?
02:54 diakopter I'd recommend building up a list of ranges as the bytecode is processed, then using the destination labels array to compare against them
02:54 diakopter yes
02:55 diakopter it's simply to prevent ints and nums values from being interpreted as pointer registers
02:56 benabik Okay, yeah, that works.  Less complete, but perfectly sound.
02:56 diakopter hm, also, we need to verify that all the args are prepped for a given call
02:56 diakopter I don't remember if that's in the todo
02:57 benabik Um, no.
02:57 benabik That's not terribly difficult to do if we forbid branching at all in the region.
02:57 diakopter they can't have stale data
02:57 diakopter k
02:57 diakopter so you'd have to use the MVMCallsite info
03:00 benabik If there's branching amongst the argument setting, then you have to start doing something like data-flow analysis to make sure all args are set along all paths.
03:00 benabik And if we just forbid it now, we can loosen it later.  :-D
03:00 sorear how do you handle foo(1, x ? bar() : baz(), 2) ?
03:00 diakopter yeah. I'm sure if a compiler wanted branches in the logic, it could just create distinct callsites.
03:01 diakopter but actually there's no benefit to such logic
03:01 sorear ?? !! rather :D
03:01 diakopter all teh args are already staged in registers
03:01 benabik if x { temp = bar() } else { temp = baz } ; foo( 1, temp, 2)
03:02 diakopter sorear: args are all evaluated first :P
03:02 diakopter oh, you're teasing.
03:02 diakopter mwahaha
03:03 sorear it was a serious question, but I don't know that much about moarvm yet
03:03 sorear a serious stupid question
03:05 diakopter you're imagining optimization that isn't there. :) each expression's arg result gets its own register slot (not cpu register), so they're all ready before being staged into the args array
03:05 benabik Hm.  No ops to set named args?
03:05 diakopter there are
03:05 diakopter oh.
03:06 sorear why have separate ops for staging and calling?  if it were atomic the verifier's job would be simpler :D
03:07 diakopter sorear: I look forward to your optimization commits. :)  We need a "how fast is sorear's branch yet?" graph
03:08 sorear heh
03:08 sorear need to finish my jvm stuff first :D
03:08 diakopter sorear: in particular, I'm more-than-half-hoping you'll discover some brilliant technique to optimize p6 regexes to some form of automata, even dynamically emitted or something.
03:09 diakopter to find the eventual successful fate before actually creating all the cursors for such a thing.
03:09 diakopter also, keeping a cursor object pool could save some gc runs.
03:10 diakopter maybe not.
03:10 benabik Also: I don't see where argument names are stored.  args.h says named args have two entries in the argument list, I don't see where that would be.
03:10 sorear someday I will have no choice but to learn how to write an escape analyzer
03:10 diakopter benabik: they're just inline
03:10 diakopter as their own args
03:11 diakopter num_pos defines the length of the positional extent
03:11 diakopter the rest will always be an even number
03:11 diakopter (arg_count - num_pos)/2 named args
03:12 benabik So *arg_flags is a pointer to a mix of call site entries and strings?
03:12 diakopter no
03:12 diakopter a ptr to a table of flags that define the type of arg in that position
03:13 benabik So the names aren't hanging off the call site, but something the call site is also attached to?
03:13 diakopter named/positional, optional/required
03:13 diakopter and type
03:13 diakopter they're inline the code
03:13 diakopter they're set as their own args, I think.
03:13 diakopter by the compiler
03:13 diakopter to MAST
03:13 sorear benabik: foo( "bar", $x, "quux", $y ) but with flags
03:13 diakopter er.
03:14 diakopter wait, I don't recall exactly
03:14 diakopter oh yeah.
03:14 benabik Ah, I was trying to see if MVMCallsite knew the names.
03:14 diakopter nope
03:15 diakopter it just knows how many
03:15 benabik So we can't tell if they set the right named args, just that they set enough?
03:16 benabik Hm.  Maybe I should just TODO anything with validating named args.
03:17 diakopter yeah, at least until someone [jnthn] with a working memory [jnthn] comes online [jnthn]
03:19 benabik Well, I very much doubt I'm going to get very far on this tonight given that I'm going to sleep soon.
03:20 sorear i have a working memory!  it has 7±2 slots, most of which are full of $dayjob at the moment
03:20 benabik Mostly trying to sort out what needs to be done.
03:20 diakopter benabik: oh, could you add another todo:
03:21 diakopter optimization: cache all the malloc'd temporaries on the tc
03:21 benabik Huh?
03:21 diakopter (including allocated size of course)
03:21 diakopter all the tables malloc'd during a validation run
03:22 diakopter .... or am I imagining nonexistent things again
03:23 benabik Oh.  tc = thread context.
03:24 arnsholt joined #moarvm
03:24 benabik There's only one malloced thing so far.
03:24 diakopter benabik: it's annoying that a revised commit keeps its original timestamp
03:25 dalek MoarVM: 74a653a | benabik++ | src/core/validation.c:
03:25 dalek MoarVM: Validate literal coderef
03:25 dalek MoarVM:
03:25 dalek MoarVM: Based on bytecode.c:create_code_objects(), there is one coderef object
03:25 dalek MoarVM: per frame, so check the given number against the number of frames.
03:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/74a653adcb
03:25 dalek MoarVM: ccbdedd | (Matthew Wilson)++ | src/core/validation.c:
03:25 dalek MoarVM: Merge pull request #25 from Benabik/master
03:25 dalek MoarVM:
03:25 dalek MoarVM: Validate coderef literal
03:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ccbdedd86f
03:25 diakopter (though perhaps irrationally annoying)
03:25 benabik Well, the commit timestamp changes but the author doesn't unless you explicitly reset it.
03:25 diakopter the timestamp didn't change in the github ui
03:28 benabik I don't know if github bothers to show the author date.
03:29 benabik 74a653a: AuthorDate: Tue Jun 11 21:39:02 2013 -0400, CommitDate: Tue Jun 11 22:38:19 2013 -0400
03:30 benabik git doesn't bother to show it unless you try.  --pretty=fuller for example.
03:35 benabik So: ensure prepargs->invoke is linear.  Ensure nobody jumps to it.  Ensure all positional are set correctly.  Do something magical with named args.
03:36 benabik Probably should also bounds check getting arguments.
03:38 diakopter they're called params there
03:38 diakopter (meh)
03:38 benabik s/wrong names/right names/ while I'm at it.  ;-)
03:39 diakopter params is right there
03:39 diakopter it's just non-intuitive at first glance
03:39 diakopter until you realize they're attached to the callee
03:39 benabik setting is args, getting is params?
03:39 diakopter yes
03:39 diakopter in this case.
03:40 diakopter setting is binding args to params. getting is retrieving args from params
03:40 diakopter params are the slots
03:40 diakopter args are the values
03:41 benabik Digging through interp.c has convinced me that the named param ops exist but the named arg ops don't.  So validation will necessarily have to leave named ops as TODO.
03:41 diakopter they do exist
03:41 diakopter :P
03:42 diakopter I wrote tests (er, *a* test?) for them
03:43 benabik Hm.  OIC.
03:43 diakopter param_Xn_X <- named
03:43 diakopter er.
03:43 diakopter now you got me confused. ;)
03:43 benabik And you set them with arg_s odd, arg_* even.
03:43 diakopter assuming there's an even number of positionals, yes
03:44 benabik Oh, well, yes.
03:44 diakopter brb
03:55 benabik Huh.  A function call brings together an argument array, a call site, and a code object.  The invoked code then needs to validate that the call site is what it needs.  Interesting.
03:56 diakopter interesting?
03:57 benabik I had thought a callsite was a descriptor of a location that could be called.  It's more a descriptor for a capture.
03:57 diakopter yeah, a call origin
03:58 benabik Ah.  call site.  A place that does a call.
04:00 benabik So params just need to be validated against checkarity?  Is checkarity required?
04:01 benabik Can't statically check against the call site there because the call site is dynamic.
04:02 benabik Hm.  Looks like the param ops do the checking.  I guess it should probably validate against a checkarity if present.
04:03 benabik Hm.  Although that heads into data flow stuff again.
04:12 diakopter benabik: yes, some degree of static analysis & optimization is indeed possible
04:13 diakopter each param fetch bounds checks wha
04:13 diakopter what's requested against what was actually sent
04:13 benabik diakopter: Is JIT territory really.  If called with callsite A, then skip these checks and do these exact conversions instead of checking types.
04:14 benabik Hard to do static analysis when the incoming data is dynamic.  :-D
04:21 benabik Anyway, I _really_ should sleep.
04:28 diakopter 'nite
04:47 arnsholt joined #moarvm
05:53 chipdude joined #moarvm
07:46 FROGGS joined #moarvm
07:48 diakopter chipdude: howdy
08:07 diakopter decommute &
09:04 JimmyZ joined #moarvm
09:05 JimmyZ jnthn: will MVMContainerSpec will be different from ContainerSpec in NQP?
09:08 jnthn That particular data structure won't be, nor will the op to set it up. Various aspects of its implementation besides that will be different, however.
09:12 sorear oh, chipdude == chip
09:12 sorear howdy!
09:12 jnthn o/ chip
09:14 jnthn (from backlog) a callsite is a static description of the number/kind of arguments being passed (that is, it's caller side). In general, args = caller side things, params = callee side things.
09:15 * jnthn has tried to stick to that naming everywhere; violators of that naming rule should be fixed...
09:20 diakopter hee
09:20 diakopter oh, you mean violations. ;)
09:20 jnthn oh!
09:21 jnthn .oO( prosecuters will be violated... )
09:21 diakopter hee.
09:26 arnsholt joined #moarvm
09:30 JimmyZ jnthn: thanks
09:35 diakopter anyone know liz' google account address (not necessarily gmail.com address)?
09:37 arnsholt joined #moarvm
09:50 diakopter sorear: plz PM me your google account address so I can share docs with you and invite to hangouts and such
09:54 diakopter sorear: nm, found it. :)
09:55 sorear i have two
09:55 sorear which one did you find
09:57 arnsholt joined #moarvm
09:58 diakopter the one I've emailed before
10:24 cognominal joined #moarvm
11:59 pmichaud joined #moarvm
11:59 masak joined #moarvm
12:32 tgt joined #moarvm
13:01 birdwindupbird joined #moarvm
14:02 tgt joined #moarvm
14:30 benabik ~~
14:32 JimmyZ joined #moarvm
14:35 tgt joined #moarvm
14:35 FROGGS joined #moarvm
14:41 benabik Hm.  I should store my todo list somewhere other than the backscroll.
14:41 jnthn If you put it there, it ends up in the IR clog for free... :)
14:42 benabik But I hate digging up clogs.  Tend to be smelly and full of hair.
14:42 jnthn You'd think the IR would help with the smell...
14:43 JimmyZ sigh.. I got my container.c work lost after git clean -xdf :(
14:43 benabik Well, there's a reason you have to -f to make that happen.  :-/
14:43 benabik IR generally makes things smellier, UV is cleansing.
14:45 FROGGS JimmyZ: you have the editor still open?
14:47 JimmyZ FROGGS: Nope, I misreadjnthn++'s answer and then I did git clean -xdf, due to my poor english
14:48 * jnthn gently suggests that JimmyZ will find it easier to learn "git stash" than jnthn will find it to learn Chinese :P
14:48 FROGGS :/
14:49 JimmyZ I did git stash, but I think before it i did git clean -xdf..
14:49 dalek MoarVM/container: dcc5b46 | jimmy++ | src/ (4 files):
14:49 dalek MoarVM/container: stub in container
14:49 dalek MoarVM/container: review: https://github.com/MoarVM/MoarVM/commit/dcc5b467dc
15:04 bronco_creek joined #moarvm
15:15 jnthn JimmyZ: https://github.com/MoarVM/Moa​rVM/commit/dcc5b467dc#L3R338 - plesae don't comment out code. If it's no longer relevant, just delete it.
15:15 jnthn Otherwise somebody will discover it months on and have no idea what the significance of it's commenting out is...
15:16 jnthn *its
15:16 JimmyZ jnthn: ok, will do it
15:17 masak is there an ANSI C version where using C++ comments like that doesn't trip up the C compiler?
15:17 jnthn Yes, MSVC I think :)
15:17 benabik C99?
15:17 masak ok, that sounds familiar.
15:17 jnthn um, wait
15:17 jnthn MSVC will trip up on those, iirc.
15:17 jnthn Should use /* ... */
15:18 benabik MSVC doesn't do C99?
15:18 jnthn benabik: No
15:18 benabik It's only 14 years later.  :-/
15:20 PerlJam Does moarvm code target a specific version of C?
15:23 nwc10 I assume "what works"
15:24 nwc10 you can't use // comments or have declarations after statements in MSVC
15:25 benabik Perhaps we should use -ansi for gcc to warn about these things.
15:26 benabik Or at least -Werror= for particular things we care about.
15:26 jnthn That may help avoid accidental breakage, yes
15:27 PerlJam so ... C89?
15:27 benabik -ansi == -std=c89
15:27 PerlJam ok
15:27 nwc10 IIRC the only platform I found where you could tell gcc to *error* for non-C89 source was FreeBSD
15:28 PerlJam might want to put that in any docs for developers (if there are any; I haven't looked)
15:28 benabik Documentation good, getting the compiler to complain better.
15:28 benabik nwc10: I would hope that -ansi causes it to complain.
15:29 benabik And even if -ansi doesn't error decl-after-stmt, you can use -Werror=decl-after-stmt
15:29 nwc10 yes, you get warnings
15:29 nwc10 for a new enough gcc.
15:30 nwc10 it's worth doing, but there's a trade off between how far you can crank up gcc's grumpiness, and how fragile your build is on platforms you didn't test on
15:31 benabik Ensuring we don't accidentally break things on a major platform (MSVC) when coding on another major platform (fairly recent GCC on Linux) is probably worth rarer platforms needing to sort out their CFLAGS differently.
15:31 jnthn Well, it's possible to have a "perl Configure.pl --dev" which cranks them up for developers.
15:31 jnthn But not for those who just want to build.
15:31 nwc10 If I'm permitted to comment on something else, the current build system doesn't scale
15:32 nwc10 you're adding a lot of redundant information for every *BSD variant, let alone every *nix like thing
15:32 * benabik would rather it be default...  Or at least default when there's a .git directory or something.
15:33 nwc10 probably a lot of duplication would be reduced by using Perl::OSType and bundling it if needed
15:34 [Coke] nwc10: e.g. when I added darwin, I bemoaned that to myself but erred on the side of "get the build working". ;)
15:40 benabik It's very repetitious now, but could be refactored with some way to specify the default gcc/clang options etc.
15:44 jnthn You can say that again!
15:44 benabik It's very repetitious now, but could be refactored with some way to specify the default gcc/clang options etc.
15:44 jnthn :P
15:44 benabik :D
15:44 jnthn Really, the build system needs love from somebody who knows enough about enough platforms to know how to factor it better.
15:45 nwc10 the suggestion about Perl::OSType is to have it default to good (or good enough) on the other >3 *BSD variants that no-one's tried yet
15:45 jnthn So far it's been a "make something work".
15:45 nwc10 I agree with "make something work"
15:48 benabik Although using Perl::OSType also raises a question...  "Perl::OSType was first released with perl v5.13.9"  "5.13.9        2011-Jan-20"
15:49 nwc10 bundle it. it's smaller than APR :-)
15:49 benabik OS X 10.7 only has 5.12.3
15:49 benabik There's that.
15:51 tgt joined #moarvm
15:53 benabik Huh.  I have 5.12.4 and Perl::OSType.  Apple's so strange sometimes.
15:55 [Coke] I have 5.12.4 and no Perl::OSType.
15:55 [Coke] (on 10.8)
15:55 benabik Huh.  Must have grabbed it with CPAN somewhere along the way.  I thought I hadn't used CPAN on this machine.
16:01 tgt joined #moarvm
16:02 dalek MoarVM/container: f53f66b | jimmy++ | src/ (3 files):
16:02 dalek MoarVM/container: port more container code
16:02 dalek MoarVM/container: review: https://github.com/MoarVM/MoarVM/commit/f53f66b202
16:03 JimmyZ 'night
16:03 nwc10 I have a /usr/bin/perl and Apple haven't applied the CVE fix
16:09 * BinGOs has a pending update for the build system
16:10 BinGOs in fact I have bundled in Perl::OSType and I have done a bit of refactoring.
16:10 BinGOs I need to do compiler preferences, then I'll submit a pull request.
16:12 benabik Good to know.  I'll stop my quick and stupid refactor.  :-D
16:12 BinGOs I just ran out of tuits last night.
16:13 benabik MVMConcatState unused?
16:14 * BinGOs stares blankly.
16:37 diakopter benabik: heh, fossil. :)
16:37 benabik diakopter: Moar's new enough I can't tell the difference between fossil and hasn't been hooked up yet.
16:38 diakopter BinGOs: maybe add an option to specify clang over gcc
16:38 benabik +1
16:38 * diakopter wonders if rurban would test it on cygwin
16:54 tgt joined #moarvm
17:33 patspam joined #moarvm
17:48 cognominal joined #moarvm
17:58 lizmat joined #moarvm
18:04 diakopter chipdude: ping
18:23 eternaleye ...Hm. I have clearly gone insane, because I am suddenly struck with a strange desire to add a DFHack plugin for MoarVM, so that I can automate Dwarf Fortress in NQP (for now) and P6 (in the future)
18:25 diakopter eternaleye: what's its interface?
18:25 eternaleye diakopter: Not entirely sure, but there are already lua and ruby plugins.
18:26 eternaleye diakopter: It's embed rather than extend, from the perspective of the language.
18:27 diakopter ..maybe if I knew what Dwarf Fortress was.... my first guess is a miniaturized version of Team Fortress
18:27 eternaleye diakopter: Nope.
18:27 eternaleye diakopter: More like Sim City meets Nethack meets Oregon Trail
18:28 timotimo_ oooh dwarf fortress
18:28 jnthn .oO( Well, this is one way to get somebody to sort out the embedding support... )
18:29 diakopter speaking of.
18:29 eternaleye diakopter: Its scale is impressive. The game starts by generating a world procedurally, including soil erosion and orographic rain shadows. Then it starts simulating politics among civiliations that form, and war, and then you get to start playing.
18:32 eternaleye It has *one* dev.
18:35 diakopter what made me think Mark Biggar had a hand in designing XS
18:38 benabik joined #moarvm
19:01 tomyan joined #moarvm
19:10 tgt joined #moarvm
19:25 pmurias joined #moarvm
19:25 pmurias has anyone tried to setup moarvm testing on travis?
19:27 nwc10 I'm unaware of anyone *trying*, but I'm not the most likely person to know
19:27 benabik dukeleto's the only person I know of to use travis.
19:29 pmurias is there a better alternative to travis? (me hasn't used travis but something like that seems like a good idea)
19:32 nwc10 I think that dukeleto had expressed some interest in doing it, but I don't know if he has the time. I supsect he's very busy keeping the world bootstrapped with decent coffee
19:32 benabik Not that I'm aware of?  dukeleto just set it up for Parrot and I don't know anyone else who's used it.  ISTR someone saying dukeleto was going to... what nwc10 said.
19:46 * pmurias gives up on adding moarvm to travis as I'll need building parrot,nqp,etc...
19:47 diakopter I'm quite sure dukeleto will get to it at some point
19:59 tomyan joined #moarvm
20:25 chipdude diakopter: g'day
20:27 chipdude I suppose most here have played with the Lua VM, but I'd like to mention that when I embedded it in an app the feature that I didn't expect and most appreciated was the debugging hook called every N opcodes
20:28 chipdude it allowed me to prevent runaway time usage.  and of course the malloc hooks allowed memory caps.
20:29 chipdude I can speak to C99.  There are four C99 features that we can get with MSVC: inline functions, // comments, <stdint.h>, and <inttypes.h>,
20:29 chipdude s/,$//
20:30 chipdude if we're willing to demand the use of MinGW or the like then we can go C99, else not.  pity
20:30 chipdude otoh inline functions is probably the most important C99 feature, possibly tied with mixed-decls-and-statements
22:17 lizmat joined #moarvm
22:53 diakopter jnthn: ping
22:54 jnthn diakopter: pongish
22:56 diakopter oops wrong window

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