Camelia, the Perl 6 bug

IRC log for #parrot, 2009-06-06

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 japhb oddly, given that I work with the Usenet all day long, I actually do want to be on the list.  ;-)
00:03 nopaste "bacek" at 122.110.39.63 pasted "Sub,pmc additional methods." (53 lines) at http://nopaste.snit.ch/16797
00:03 bacek_ joined #parrot
00:04 bacek_ chromatic: any objections about http://nopaste.snit.ch/16797 ? It part of http://nopaste.snit.ch/16791 - emitting PBC from PIR
00:07 chromatic In principle no, but is there a way to accomplish the same thing without referring to raw offset positions?
00:09 bacek_ chromatic: No. At least Subs just frozen into PBC and use those offsets.
00:09 chromatic Is there something else we can pass into those methods to calculate offsets?
00:10 bacek_ without braking encapsulation? Probably no.
00:11 chromatic Perhaps with less encapsulation breaking?
00:13 bacek_ Split Sub into 2 parts. One for storing and manipulating, one for executing.
00:14 chromatic I'm really leery of adding an API that could let people break things horribly if they're not super careful.
00:16 bacek_ me too.
00:16 bacek_ We can hold additional flag "live" for subs that attached to interp and disallow changing offset for them
00:17 bacek_ Actually, disallow change anything in sub.
00:17 chromatic Is the Sub PMC the right place for this?
00:17 dalek parrot: r39417 | chromatic++ | trunk (5 files):
00:17 dalek parrot: [IMCC] Allowed Unicode identifiers in method names, not only when stored in
00:17 dalek parrot: STRINGs but appearing directly in source code.  See TT #730.
00:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39417/
00:18 bacek_ It's about how PBC designed...
00:18 chromatic IMCC (I can't believe I'm writing this) manipulates its own data structures before building a Sub PMC.
00:19 bacek_ And than it pokes inside Sub to set things.
00:20 chromatic Does it?
00:22 bacek_ emit_pbc_instr if I understand it correctly
00:24 bacek_ compilers/imcc/pbc.c 1433
00:26 chromatic Hm, that's true.
00:27 chromatic I'd almost rather write out a serialized version and thaw it.
00:30 kesselhaus joined #parrot
00:31 bacek_ freeze if serialising, isn't it?
00:32 chromatic Right.
00:36 bacek_ So I need created Sub for freeze. Fully created...
00:36 bacek_ Ok, how about check sub->seg before changing offsets? If it's non null - disallow.
00:36 bacek_ oh. it will not work...
00:49 nopaste "bacek" at 122.110.39.63 pasted "chromatic what this approach?" (110 lines) at http://nopaste.snit.ch/16798
00:55 chromatic Tene, the segfault occurs for me (without --gc-debug) when trying to mark a context.  The PMC in the register set is invalid.
00:56 chromatic I don't understand why it has to be in the Sub PMC.
00:57 bacek_ what other place to put it in without implementing full pmc_freeze logic?
00:57 Tene chromatic: That's right.
00:57 Tene That's what I saw too
00:58 chromatic How are you creating these Subs? As PMCs?
00:59 chromatic Tene, it's weird; it's just one PMC in the register set that's wrong.
00:59 Tene Exactly.
00:59 chromatic There are 10 PMC registers, and the ninth one (i = 8) is 0x1.  The tenth one is fine.
00:59 Tene That's what I saw too.
01:00 chromatic I've seen this before, but I could never track it down.
01:00 bacek_ chromatic: yes, as PMCs.
01:01 bacek_ chromatic: and than put them into PackfileConstTable
01:01 chromatic Can you create all of the necessary sub information right now through the PMC interface, except for these four methods?
01:02 afk_coke if I have a PIR sub that is best suited to be a multi, is it faster in PIR to use a multi or just have a non-multi that checks for types itself?
01:02 bacek_ chromatic: almost
01:03 bacek_ what I actually need is FakeSub. Which will be frozen as Sub.
01:03 chromatic And thawed as Sub, where there are no UI parts users can play with.
01:04 bacek_ I don't quite understand last question.
01:04 bacek_ Ah. After thawing I don't need anything else.
01:04 chromatic Build the data with something where you can poke at its internals, then freeze and thaw it as something users can't poke at its internals.
01:04 bacek_ indeed.
01:05 bacek_ Just freezing. Thawed Sub should be constant
01:05 chromatic Tene, my best idea for debugging this is annotating the REG_PMC macro to ASSERT that the PMC isn't 0x1.
01:05 chromatic Otherwise we could try hardware watchpoints after we know which context gets created appropriately.
01:05 chromatic *Something* somewhere assigns a bad value here, and I don't have time to reason through it.
01:11 Tene Hmm.  I don't really understand that part of Parrot.
01:12 Tene I'll try playing with that.
01:13 snarkyboojum joined #parrot
01:18 dalek partcl: r437 | coke++ | trunk/runtime/conversions.pir:
01:18 dalek partcl: split toBoolean into components - checking the boolean value of an int
01:18 dalek partcl: is much more common.
01:18 dalek partcl: timings are inconclusive.
01:18 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=437
01:23 dalek partcl: r438 | coke++ | trunk/t/tcl_misc.t:
01:23 dalek partcl: remove 3 old regression tests that were needed back around parrot 0.2
01:23 dalek partcl: (now that we can run the spec tests, we don't need these.)
01:23 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=438
01:23 Tene Specifically, I can't quite figure out how to add an ASSERT in the middle of a statement in C, which is where that macro expands to.
01:29 mikehh kid51: I have been failing manifest_tests - t/tools/install/dev_overall.t and overall.t - if I change mkpath to make_path it works
01:31 kid51 mikehh:  Am puzzled.  what is 'make_path'?  Can you paste?
01:32 mikehh kid51: in File::Path
01:34 mikehh kid51: File::Path ver 2.07 Ubuntu 9,04 (both i386 and amd64) Perl 5.10
01:35 kid51 mikehh:  In File::Path v2.04 I cannot locate a string 'make_path'.  So I don't know how that could work.
01:35 kid51 Also, 'make manifest_tests' just ran AOK for me on Darwin and Linux.
01:36 kid51 Please open TT.
01:38 nopaste "mikehh" at 90.209.128.185 pasted "Patch that fixes manifest_tests for me" (44 lines) at http://nopaste.snit.ch/16799
01:38 dalek parrot: r39418 | jkeenan++ | trunk (2 files):
01:38 dalek parrot: Eliminate the last traces of deprecated functions Parrot_readbc and
01:38 dalek parrot: Parrot_loadbc.  Remove deprecation notice.  Cf.:
01:38 dalek parrot: https://trac.parrot.org/parrot/ticket/266.
01:38 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39418/
01:40 dalek TT #266 closed by jkeenan++: Packfile API cleanup: rename Parrot_readbc to Parrot_pbc_read, _loadbc => ...
01:41 kid51 mikehh:  Can you paste your test failures?
01:44 Austin_Hastings Any idea what $P0 = getinterp ; $P1 = $P0['namespace';1] is extracting? Is the 'namespace' an array of caller data, or some other wierdness that would need an extra ;1 index?
01:44 kid51 mikehh:  I doubt we'll be able to accept that patch.  File::Path::make_path() was only introduced in v2.07, Nov 2008.  That's much more recent than our minimum version.
01:45 kid51 But pls paste errors anyway.
01:51 nopaste "mikehh" at 90.209.128.185 pasted "manifest_tests failures" (40 lines) at http://nopaste.snit.ch/16800
01:56 mikehh kid51: I tried to get it to work in various ways but it seems to create the dirs with NO permissions using mkpath, but works with make_path
01:59 Austin_Hastings Aha. Yes. parrotinterpreter.pmc has a get_pmc_keyed interface that returns caller data when queried with "<key>";<level> pairs.
02:00 nopaste "back" at 122.110.39.63 pasted "Let's fake Sub!" (198 lines) at http://nopaste.snit.ch/16801
02:01 mikehh kid51: actually in one case the compliers directory and in the other the src directory have mode 000
02:01 bacek_ msg chromatic http://nopaste.snit.ch/16801 is what I actually need. And it works.
02:01 purl Message for chromatic stored.
02:07 dalek partcl: r439 | coke++ | trunk/t/tcl_misc (2 files):
02:07 dalek partcl: Convert most of this file to tcl, throw out some dup tests.
02:07 dalek partcl: review: http://code.google.com/p/p​artcl/source/detail?r=439
02:17 nopaste "kid51" at 70.107.16.159 pasted "mikehh: does this work?" (28 lines) at http://nopaste.snit.ch/16802
02:31 mikehh kid51: nope - syntax error
02:32 kid51 What versions of File::Temp and File::Path are you using?
02:33 kid51 At this point, I recommend you file a new TT.  My patch worked for me with the versions of those two modules that came with Perl 5.10.  I cannot reproduce your failues.
02:33 kid51 this will need further investigation.
02:33 kid51 ... and it's too late at night for me to begin that.
02:34 kid51 I don't know how you got a syntax error for code that I just now ran successfully.
02:36 janus joined #parrot
02:37 mikehh kid51: let me work on it a bit more - I need to look at File::Path a bit more - I have 2.07 - File::Temp 0.21
02:38 kid51 File::Path is apparently a module whose interface has, um, evolved through the years.
02:38 kid51 And in the Parrot distro we have all 3 generations of interfaces for mkpath :-)
02:39 kid51 But 2.07 is probably more recent than that shipped with 5.10 -- and we don't even require 5.10!
02:39 kid51 So we have to get it to work with either the 'traditional' or the 'modern' (but not hyper-modern) interface.
02:40 mikehh kid51: Yeah - any modules I use are generally the latest from CPAN and the latest sometimes break older code
02:42 kid51 I see that lib/Parrot/Install.pm uses the oldest interface.  I'm going to change that now (or maybe tomorrow morning).
02:50 mikehh kid51: I think I need to take a break - it's coming up to 4am for me - I'll work on it later
02:50 dalek parrot: r39419 | jkeenan++ | trunk (3 files):
02:50 dalek parrot: Use the 'modern' interface to File::Path::mkpath(), i.e., explicitly pass mode in hashref final argument.
02:50 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39419/
02:53 kid51 Thanks for reporting the problem.  I grepped repository and realized that there are many usages of 'mkpath' which are succeeding even though they don't match any of the specified interfaces.
02:55 darbelo joined #parrot
02:55 nopaste "bacek" at 122.110.39.63 pasted "chromatic, this FakeSub is better. Any objections?" (80 lines) at http://nopaste.snit.ch/16803
03:10 mikehh kid51: apologies - that patch actually worked - I messed up the test - it works now - I gotta get a nap now
03:11 kid51 np; it led me to some refactoring which you'll see committed shortly.
03:17 dalek parrot: r39420 | jkeenan++ | trunk (10 files):
03:17 dalek parrot: Where directory mode is explicitly passed to File::Path::mkpath(), use the
03:17 dalek parrot: 'modern' interface:  { mode => 0755 } as final argument.
03:17 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39420/
03:22 snarkyboojum joined #parrot
03:23 dalek parrot: r39421 | cotto++ | branches/pmc_pct/compilers/vtdumper/vtdumper.pir:
03:23 dalek parrot: [vtdumper] put the freeze code back, since the vtable dump doesn't actually need to be portable
03:23 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39421/
03:24 bacek_ joined #parrot
04:12 dalek parrot: r39422 | cotto++ | branches/pmc_pct/compilers/vtdumper/vtdumper.pir:
04:12 dalek parrot: [vtdumper] mark the generate_dump stage as a method
04:12 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39422/
04:15 david joined #parrot
04:15 dalek TT #743 created by Austin_Hastings++: Add 'inspect' method to Sub PMC
04:20 darbelo joined #parrot
04:29 cotto Austin_Hastings, ping
04:29 Austin_Hastings cotto, pinf
04:29 Austin_Hastings *ping
04:29 cotto wrt tt #743, the Sub PMC defines an inspect *VTABLE function*, not a method.
04:30 Austin_Hastings Right.
04:30 Austin_Hastings I am asking for method.
04:31 Austin_Hastings (Eventually, I am asking for introspective interfaces throughout, but I thought I'd take it slow.)
04:31 cotto Why not use $P2 = inspect $P0 ?
04:31 Austin_Hastings Because I had no idea it exists.
04:31 cotto Now you know.
04:31 purl It does the boots and shoes.
04:32 cotto Many VTABLE functions can be used like that through opcode wrappers.
04:32 cotto no, Now you know. is And knowing is half the battle.
04:32 cotto purl no, Now you know. is And knowing is half the battle.
04:32 purl i already had it that way, cotto.
04:33 cotto now you know
04:33 purl It does the boots and shoes.
04:33 cotto purl no, Now you know is And knowing is half the battle.
04:33 purl okay, cotto.
04:33 cotto now you know
04:33 purl now you know is And knowing is half the battle.
04:33 cotto purl no, Now you know is <reply>And knowing is half the battle.
04:33 purl okay, cotto.
04:33 cotto purl no, Now you know. is <reply>And knowing is half the battle.
04:33 purl okay, cotto.
04:33 Austin_Hastings w00t! You rock.
04:33 dalek decnum-dynpmcs: r74 | darbelo++ | trunk/src/pmc/decnumcontext.pmc:
04:33 dalek decnum-dynpmcs: Add get_clamp() and set_clamp() METHODs for the 'clamp' field of the decContext
04:33 dalek decnum-dynpmcs: structure. Anything with a get_bool VTABLE can be used as input to the setter
04:33 dalek decnum-dynpmcs: and a bool PMC is returned by the getter.
04:33 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=74
04:33 cotto glad to help
04:33 Austin_Hastings Now if only there was a get_pointer opcode. Is there?
04:34 cotto no, and there shouldn't be.
04:34 Austin_Hastings :)
04:34 Austin_Hastings Well, I'm looking for a unique key for the object...
04:34 Austin_Hastings (the object is a Sub in this case)
04:34 cotto That VTABLE function is used to fiddle with a PMC's internals and should be considered dangerous (but not as dangerous as set_pointer).
04:35 cotto that seems to be a common use case
04:35 Austin_Hastings I'd suggest doing something like "hashcode", but I'm pretty sure everyone would go "Oh, no! They did that in Java so it must be a bad idea."
04:36 darbelo Austin_Hastings, be careful, nothing guarantees that you'll get a valid pointer out of get_pointer().
04:36 Austin_Hastings darbelo, Thanks, but I can't call it from PIR, so it does me no good. I was just bemoaning the lack of a unique-id.
04:37 darbelo Oh, didn't know you were working from PIR. Sorry.
04:37 cotto I wonder how a VTABLE function (plus opcode wrapper) dedicated to that purpose would go over.  It'd be dead simple to implement.
04:37 Austin_Hastings No worries. You've got to expect the occasional (l)user.
04:38 cotto just stick something sane in default.pmc and everyone else gets it for free
04:38 Austin_Hastings cotto, How about a pmc?
04:38 cotto ?
04:38 Austin_Hastings $P0 = new 'UniqueId', my_object
04:39 cotto It seems a little heavyweight for something that simple.
04:39 Austin_Hastings I was thinking the same thing about a new vtable function.
04:40 Austin_Hastings (Since bacek was griping about the huge number of vtable functions just the other day.)
04:41 darbelo Maybe I'm over-simplifying here but wouldn't be "INTVAL get_unique_identifier() { return SELF }" sufficient?
04:41 Austin_Hastings I have no idea. Does the GC ever move things? Should this persist across serialization?
04:41 cotto darbelo, yes but it'd be good to make absolutely sure that it could never be misused.
04:42 Austin_Hastings Misused?
04:42 dalek TT #743 closed by cotto++: Add 'inspect' method to Sub PMC
04:42 cotto Austin_Hastings, we don't currently have a compacting GC, but Whiteknight++ has it on his todo list.
04:43 darbelo Ohhhh. Compacting gcs  are *shiny*.
04:43 cotto misused as in someone uses it as a pointer.  Returning a STRING* would probably be sufficient.
04:44 cotto I'll hack up a patch for that and see how people respond.
04:44 Austin_Hastings Also, does the id ever change? I'm thinking in particular of class pmc's that can get changed, etc.
04:44 cotto I think bacek's problem with VTABLE functions is that there are a ton that are hardly ever used and don't make sense in most contexts.
04:45 cotto id?
04:45 purl id is undef => a breaker
04:45 cotto as in pmc->vtable->base_type?
04:46 Austin_Hastings Cotto, when you talk about this, you need to distinguish two possibles: id as just an id, and id as some kind of metric (hashcode). One is slower than the other, but may have more uses.
04:46 Austin_Hastings Anyway, it'd probably be good to run it past @Parry.
04:51 Austin_Hastings Okay, here's a question for you internals gurus. I have created a new class and add_method'ed a 'new' sub. But it isn't being called. How can I figure out what's going on with the dispatch of this method?
04:56 cotto Austin_Hastings, when you say "id", I think of something used to tell if two PMCs have the same guts.
04:57 cotto Austin_Hastings, unless you need to create the new sub dynamically, you can stick the code in the namespace corresponding to the class.
04:57 Austin_Hastings I did that. I did a bunch of stuff I think should make this a total no-brainer, but I'm talking to the wrong sub.
04:58 darbelo cotto, I'd think of the same PMC header, instead of the guts. Unless you meant that.
04:58 cotto darbelo, that's what I meant.
04:59 cotto Austin_Hastings, nopaste?
04:59 Austin_Hastings gimme a sec to reorg the code
05:00 cotto darbelo, lmk if you get stuck with pct while working on the test suite.
05:00 Austin_Hastings http://nopaste.com/p/aEtPCOuUK
05:02 cotto What language is that?
05:02 purl I'm not sure... but it doesn't sound like any kind of English I know.
05:02 Austin_Hastings close
05:02 cotto purl++
05:03 cotto ioc.  That's your experimental language.
05:03 Austin_Hastings yep. It's not C, but it's close. :)
05:03 cotto My brain can't decide if it's C or PIR.
05:03 cotto It's quite disorienting.
05:04 Austin_Hastings As time goes by, I hope that the percentage of PIR will approach 0.
05:07 cotto I'm not sure what kind of PAST you want to generate for that.  You could cheat and see what Rakudo does.
05:07 cotto --target=past is your friend
05:08 Austin_Hastings If it helps, here's the pir (minus annotations, which just piss me off)
05:08 Austin_Hastings http://nopaste.com/p/a8e1p6Ylqb
05:08 darbelo cotto: I was kinda stumped at the start, but then I just grabbed what create_language.pl generates and edited to suit my purposes. It sort-of parses most stuff now. I'll do some cleanup and commit the grammar later.
05:10 cotto darbelo, ok.
05:10 cotto I like that nopaste.
05:13 Austin_Hastings So I guess my first question is am I doing the right thing by using get_hll_global to load up the sub?
05:14 Austin_Hastings But then I'm still stuck with wondering how $P47 is doing dispatch on "new"?
05:14 Austin_Hastings It's calling SOMETHING, and returning. But not my "new", since no output appears.
05:15 cotto You can use the 'new' opcode.  It dtrt afaik.
05:15 Austin_Hastings My understanding was that it doesn't call the support code. It just creates, without initializing.
05:15 cotto actually, I need to check that
05:15 Austin_Hastings (In fact, 'new' is a builtin in close for this.)
05:16 cotto bbs: shopping
05:16 purl shopping is probably a drag. or a great time, if it's *barber* shopping! </kitch>
05:17 dalek decnum-dynpmcs: r75 | darbelo++ | trunk/src/pmc/decnum.pmc:
05:17 dalek decnum-dynpmcs: Add a multiply_add() method to DecNum, based on decNumberFMA().
05:17 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=75
05:26 Zak joined #parrot
05:32 dalek decnum-dynpmcs: r76 | darbelo++ | trunk/src/pmc/decnum.pmc:
05:32 dalek decnum-dynpmcs: Add exp() and sqrt() METHODs to DecNum.
05:32 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=76
05:36 mikehh joined #parrot
05:38 Austin_Hastings left #parrot
05:46 dalek decnum-dynpmcs: r77 | darbelo++ | trunk/src/pmc/decnum.pmc:
05:46 dalek decnum-dynpmcs: Make DecNum stringification prettier.
05:46 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=77
05:57 dalek decnum-dynpmcs: r78 | darbelo++ | trunk/src/pmc/decnum.pmc:
05:57 dalek decnum-dynpmcs: Add ln() and log10() METHODs to DecNum.
05:57 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=78
06:04 snarkyboojum joined #parrot
06:04 cotto karma darbelo
06:04 purl darbelo has karma of 88
06:12 dalek decnum-dynpmcs: r79 | darbelo++ | trunk/src/pmc/decnum.pmc:
06:12 dalek decnum-dynpmcs: Add a get_eng_string METHOD. It does the same as the get_string VTABLE but using
06:12 dalek decnum-dynpmcs: engineering notation.
06:12 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=79
06:22 viklund_ joined #parrot
06:37 dalek decnum-dynpmcs: r80 | darbelo++ | trunk/src/pmc/decnum.pmc:
06:37 dalek decnum-dynpmcs: Add modulus() and i_modulus() VTABLEs.
06:37 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=80
06:52 darbelo It looks like I'm running out of easy stuff. :)
06:54 darbelo I think I'll try to get some sleep before going back to the tests.
06:57 iblechbot joined #parrot
06:58 cotto Nobody should tell him that writing a grammar is the easy part.
07:25 dalek parrot: r39423 | cotto++ | branches/pmc_pct/compilers/pmcc/pmcc.pir:
07:25 dalek parrot: [pmcc] make pmcc behave well when working with pmcs in the cwd
07:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39423/
07:25 dalek parrot: r39424 | cotto++ | branches/pmc_pct/compilers/​pmcc/src/parser/actions.pm:
07:25 dalek parrot: [pmcc] start making the thawed vtable dump available
07:25 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39424/
08:04 dalek parrot: r39425 | fperrad++ | trunk (2 files):
08:04 dalek parrot: [codingstd] fix svn properties
08:05 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39425/
08:18 HG` joined #parrot
08:22 Zak joined #parrot
08:32 flh joined #parrot
08:38 clinton joined #parrot
08:41 Zak joined #parrot
08:43 barney joined #parrot
09:05 cognominal joined #parrot
09:13 darbelo joined #parrot
09:14 darbelo cotto: ping
09:14 Zak joined #parrot
09:48 Zak joined #parrot
09:54 jq joined #parrot
09:55 dalek decnum-dynpmcs: r81 | darbelo++ | trunk/t/data/d (50 files):
09:55 dalek decnum-dynpmcs: Remove test data for unused decSingle, decDouble and decQuad modules.
09:55 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=81
10:12 flh joined #parrot
10:28 NotFound joined #parrot
10:33 flh I cannot checkout parrot's source using svn: did anything change recently?
10:38 clinton flh: works for me
10:40 clinton although it's quite slow
10:49 flh ok, it is just a problem in the current Debian testing (upgrading libneon27 from v0.28.4-1 to v0.28.4-2 does the trick)
11:02 dalek parrot: r39426 | NotFound++ | trunk/src/embed.c:
11:02 dalek parrot: [cage] fix warning in mem_realloc_n_typed usage
11:02 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39426/
11:02 Whiteknight joined #parrot
11:12 bacek joined #parrot
11:39 dalek TT #744 created by tene++: GC Segfault with steme and rakudo
11:43 skids joined #parrot
12:03 masak joined #parrot
12:12 skids Does Markus (of "added Rational PMC code" fame) have an IRC nick/hang out here at all?
12:14 kid51 joined #parrot
12:22 NotFound joined #parrot
12:22 dalek TT #742 closed by jkeenan++: Parrot::Test::Util::create_tempfile() cannot handle DIR option on Cygwin
12:24 fperrad joined #parrot
12:33 dalek parrot: r39427 | fperrad++ | trunk/tools/dev/create_language.pl:
12:33 dalek parrot: [languages] remove a die in read_parrot_config,
12:33 dalek parrot: like in Rakudo.
12:33 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39427/
12:37 dalek parrot: r39428 | fperrad++ | trunk/tools/dev/create_language.pl:
12:37 dalek parrot: [languages] add a target 'installable'
12:37 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39428/
12:40 dalek parrot: r39429 | jkeenan++ | branches/add_library_path_remove:
12:40 dalek parrot: Create branch to work on https://trac.parrot.org/parrot/ticket/455.
12:40 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39429/
12:50 kid51 Does anyone know whether 'make headerizer' should be run before or after 'make'?
12:52 Infinoid after.  it depends on some autogenerated sources
12:53 Infinoid which does mean it has some chicken and egg problems, sometimes.
12:53 kid51 I'm trying to work on TT #455
12:55 Infinoid so let me guess, "make" doesn't complete due to a missing prototype?
12:57 nopaste "kid51" at 68.237.16.53 pasted "errors during 'make' while trying to eliminate Parrot_add_library_path" (12 lines) at http://nopaste.snit.ch/16806
12:57 kid51 Since I am not a Parrot-level C programmer, I'm just blundering around.
12:59 Infinoid ok.  I can try to help you figure out those warnings
13:00 kid51 I believe the file which has to be changed first is src/library.c
13:01 NotFound Are you passing a C string?
13:01 Infinoid Can you nopaste your current diff, please?  (line 649 is pod for me)
13:02 kid51 Parrot_add_library_path_from_cstring is described as an interface to Parrot_add_library_path.  The latter is what the TT wants to eliminate.
13:02 NotFound I think that we want't to eliminate nothing, just renaming.
13:03 Infinoid Both functions already exist
13:03 NotFound We want both the Parrot string and the C string interface.
13:03 NotFound At least I want.
13:04 Infinoid Okay.  But we want to avoid two unnecessary string conversions in the common case
13:04 nopaste "kid51" at 70.85.31.226 pasted "Attempt at getting rid of Parrot_add_library_path" (57 lines) at http://nopaste.snit.ch/16807
13:04 NotFound The way to avoid unneeded conversions is to call the appropiate version,
13:06 kid51 NotFound:  See TT #455.  I have no personal opinion on the merits of this.  I'm merely trying to handle an item marked for deprecation as of 1.1.
13:07 Infinoid kid51: I think that warning will go away if you call VTABLE_push_string with path_str instead of path
13:07 kid51 Yes, I was looking at that too.  I'll give it a try.
13:07 Infinoid otherwise the diff looks good to me (though some callers will need to be fixed up)
13:08 NotFound kid51: nothing in the ticket contradicts what I said
13:09 NotFound Implementation details apart.
13:11 Infinoid If there's a use for the alternate form, then that's fine.  (It's an extension of the ticket's requested functionality.)  But if we have APIs to handle both kinds of strings, and we have current callers who convert string types before calling this API, those callers should still be fixed up
13:12 kid51 The next file to be fixed is src/packfile.c, around lines 4776
13:12 Infinoid I'd probably remove the old API temporarily anyway, just to make it easier to find the callers
13:12 Infinoid yes, src/packfile.c:4776 is one of the callers
13:13 kid51 If I just do a simple search-and-replace on the function name, I get:
13:13 kid51 src/packfile.c:4776: warning: passing argument 2 of 'Parrot_add_library_path_from_cstring' from incompatible pointer type
13:13 kid51 src/packfile.c:4778: warning: passing argument 2 of 'Parrot_add_library_path_from_cstring' from incompatible pointer type
13:13 Infinoid Right, you should also change CONST_STRING(interp, "include/") to "include/"
13:14 Infinoid (that's an example of the cstring to STRING conversion allison was talking about eliminating)
13:15 kid51 But that gives me:
13:15 kid51 src/packfile.c: In function 'Parrot_load_language':
13:15 kid51 src/packfile.c:4775: warning: passing argument 3 of 'Parrot_str_append' from incompatible pointer type
13:15 kid51 src/packfile.c:4776: warning: passing argument 2 of 'Parrot_add_library_path_from_cstring' from incompatible pointer type
13:15 kid51 src/packfile.c:4777: warning: passing argument 3 of 'Parrot_str_append' from incompatible pointer type
13:15 kid51 src/packfile.c:4778: warning: passing argument 2 of 'Parrot_add_library_path_from_cstring' from incompatible pointer type
13:15 kid51 Let me paste state of that file.
13:15 Infinoid oh, uck.  Parrot_str_append still expects a STRING
13:16 nopaste "kid51" at 70.85.31.226 pasted "packfile.c changes" (16 lines) at http://nopaste.snit.ch/16808
13:17 Infinoid okay.  in this case, I think NotFound is right, preserving the old API will be helpful
13:18 NotFound I don't understand what are you doing. If the function is using parrot string functions, there is no point in usung the c string version
13:18 Infinoid NotFound: It's just a repercussion of removing the STRING-based API as the ticket says, and converting the caller to use cstrings
13:19 kid51 Infinoid:  Do you want to comment in TT 455?  If there are real issues here, I won't proceed.
13:19 NotFound I think you are also misunderstanding the ticket
13:19 purl okay, NotFound.
13:19 Infinoid The ticket says, rename the function.
13:19 Infinoid NotFound says, extend the function with a second API so we can handle both
13:20 Infinoid So NotFound's version is an extension of the functionality requested in the ticket.  That's my understanding, did I miss something?
13:20 NotFound "A new function 'Parrot_lib_add_path' will be added that accepts a Parrot STRING. "
13:20 Infinoid The summary line: Change name of 'Parrot_add_library_path' to 'Parrot_pf_add_library_path_from_cstring'
13:20 Infinoid To me that sounds like "rename"
13:20 NotFound The ticket says that
13:21 NotFound "The C string version will simply convert the C string to a Parrot STRING and call 'Parrot_lib_add_path'."
13:21 NotFound So, the ticket ask for the two versions.
13:22 Infinoid Oh, I see.  So the callers of the old function (who are right to call the old function) should now call Parrot_lib_add_path(), instead
13:22 NotFound The naming used seem confusing, anyway.
13:22 kid51 So this is more than a simple "rip out this feature" deprecation.
13:22 Infinoid It's a "rename this function to that, and add this other function to make some of the callers cleaner"
13:23 NotFound Is reanimg a function and adding another.
13:23 Infinoid You've got the "this other function" part done
13:23 kid51 Okay, that's beyond my C fu.
13:23 Infinoid kid51++ # already more than halfway there
13:24 NotFound The title of the ticket uses one name, but the description uses another. That needs clarification.
13:24 Infinoid please feel free
13:24 Infinoid I can clean up the diff accordingly
13:24 kid51 I will post what I have done in the ticket so it can get wider exposure.
13:25 Infinoid oh, great.  kid51++
13:25 NotFound I think we must ask allison.
13:25 Infinoid I think it's pretty clear now
13:25 Infinoid The summary misses part of the details, that's all
13:26 NotFound Infinoid: not for me. Parrot_lib_add or Parrot_pf_add?
13:26 Infinoid Parrot_lib_add, that's a typo
13:26 NotFound Ah, nice.
13:27 dalek parrot: r39430 | jkeenan++ | branches/add_library_path_remove (3 files):
13:27 dalek parrot: Partially complete work on TT#455.
13:27 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39430/
13:27 Infinoid So we remove Parrot_add_library_path, and add Parrot_lib_add_path (which does the same thing) and Parrot_lib_add_path_from_cstring
13:28 Infinoid so the naming conforms to the rest of parrot, and we have both entry points
13:29 NotFound I think we must maintain Parrot_add_library_path, reinplementing it by just calling the new API, until the end of a deprecation cycle,
13:29 Infinoid from DEPRECATED.pod: =item Parrot_add_library_path [eligible in 1.1]
13:30 Infinoid so we've already done the deprecation cycle
13:30 NotFound That's seems wrong to me. We can't start a deprecation cycle before the alternative even exists,
13:31 Infinoid That sounds like a great #ps question, I don't feel too strongly about that issue
13:31 Infinoid it just says "check in 1.4 or 2.0 for the new names", which seems reasonable to me
13:33 NotFound No big problem ATM, but as a general police looks wrong to me.
13:35 Infinoid I think maintaining parallel implementations of *everything* we deprecate, for an entire deprecation cycle, would be a significant extra amount of maintenance
13:36 kid51 TT 455 updated.
13:36 Infinoid I agree that it would probably be easier for partcl (for example) to keep up to date if both APIs were available and the conversion could happen anywhere within the 6 month deprecation cycle span
13:36 Infinoid But that's a lot more work on the parrot side to maintain that model.
13:37 kid51 Infinoid:  I interpret that line from DEPRECATED.pod as meaning:  "Anyone can work on this right away; we don't have to wait till after the July release."  That's why I attempted this.
13:38 Infinoid kid51: Yes, that's our policy, seems fine to me
13:39 kid51 There are several other 'eligible in 1.1' items, but this one was the only one I could grok.
13:43 NotFound Infinoid: if we don't maintain them, what's the meaning of "deprecated"?
13:44 Infinoid "don't use this"
13:44 pmichaud "deprecated" means "we don't guarantee this will work the same in the next stable release"
13:44 Infinoid or "expect this to break"
13:45 NotFound Infinoid: "don't use this, we still don't have a replacement. Bad luck"
13:46 NotFound pmichaud: that's a nice way, provided we have something that will works in the next, and also works in current.
13:48 pmichaud_ joined #parrot
13:48 pmichaud_ lost my connection to feather
13:49 pmichaud_ NotFound:  deprecation basically means that we expect the API to change
13:49 pmichaud_ it doesn't mean that the feature will definitely be gone in the next release
13:49 Infinoid And it doesn't mean the replacement is already available
13:49 pmichaud_ correct
13:49 Infinoid (I think that's what NotFound is objecting to)
13:49 NotFound Yeah
13:49 pmichaud_ sometimes features are completely eliminated
13:50 NotFound We aren't talking about a feature, just an API minor detail change. No point to break things for that.
13:51 dalek parrot: r39431 | Infinoid++ | branches/add_library_path_remove (4 files):
13:51 dalek parrot: Perform TT #455 API updates, get the callers working.  Everything builds now.
13:51 pmichaud NotFound: that's a slightly separate issue.
13:51 pmichaud Basically a deprecation is a warning that we expect the contract to change
13:51 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39431/
13:52 pmichaud looks like my session restored :-)
13:52 NotFound Changing the API without alternative is not a warning to me, is a full stop.
13:53 pmichaud iirc, most/all C-level functions in Parrot were considered unstable as of the 1.0 release
13:53 pmichaud i.e., they could be changed.
13:53 Infinoid kid51: I'm running tests now, but I think this branch is almost ready for merging back to trunk
13:54 pmichaud anyway, we can declare something as deprecated even before the alternative exists
13:54 NotFound And sometimes is reasonable, when maintaining the old way is costly. But there is no point in doing that just because we can.
13:54 kid51 Infinoid:  Yes I'm doing make and then will test; I'll smolder.
13:54 pmichaud if we *know* something is going to change, then we deprecate it, even if we don't know what we're going to change it to
13:54 pmichaud for example
13:55 pmichaud in NQP, I knew in March that the $(...)  syntax was no longer going to be valid
13:55 pmichaud however, at that time I had no idea what it would change to (because the Perl 6 spec didn't say yet)
13:55 pmichaud so, I went ahead and deprecated $(...)
13:55 NotFound pmichaud: we can warn about that, but is highly unfriendly to use that as the official start of a deprecation cycle.
13:55 pmichaud but I couldn't say "and it will be replaced by XYZ", because XYZ wasn't defined yet
13:55 Infinoid kid51: I failed t/codingstd/pdd_format.t but I think that failure was inherited from trunk.  Otherwise, looks good here
13:59 kid51 Infinoid:  You are correct.  That's an error in trunk.
13:59 Infinoid I don't see any instances of Parrot_add_library_path() in lua, partcl or rakudo
13:59 kid51 =item ([<var1> [:<modifier1> ...], ...]) = <var2>([<arg1> [:<modifier2> ...], ...])
14:00 Infinoid otherwise I'd post a quick patch for those
14:00 kid51 perhaps shorten 'modifier'
14:00 Infinoid I guess
14:03 pmichaud if I have a sequence of bytes in a fixed_8 string
14:03 pmichaud how do I get those to be treated as a utf8 string?
14:04 kid51 Smolder report:  http://smolder.plusthree.com/app/pu​blic_projects/report_details/23243
14:05 kid51 Infinoid:  Shall I merge?
14:06 Infinoid kid51: Please do.
14:13 kid51 Will do in about 10 min.
14:23 clinton left #parrot
14:24 dalek parrot: r39432 | jkeenan++ | trunk (5 files):
14:24 dalek parrot: Merge add_library_path_remove branch into trunk, per https://trac.parrot.org/parrot/ticket/455.  Complete deprecation of Parrot_add_library_path.
14:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39432/
14:24 dalek parrot: r39433 | jkeenan++ | branches/add_library_path_remove:
14:24 dalek parrot: Branch has been merged into trunk and is no longer needed at HEAD.
14:24 purl i already had it that way, dalek.
14:24 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39433/
14:41 snarkyboojum joined #parrot
14:42 ruoso joined #parrot
14:49 HG` joined #parrot
14:54 Infinoid Tene: If you mention steme on https://trac.parrot.org/parrot/wiki/Languages, dalek will give you karma for your commits. :)
15:25 masak joined #parrot
15:42 flh does the Hash PMC work with non-string keys?
15:43 dalek parrot: r39434 | fperrad++ | trunk/tools (2 files):
15:43 dalek parrot: [languages] add steme (Tene++)
15:43 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39434/
15:57 Infinoid flh: Not really.  Integers and PMCs will be stringified.  Keys returned from Iterators are a special case.
15:59 Infinoid Anything else would beg the question "how do you run a hash function on a non-string"
16:09 Theory joined #parrot
16:27 skids ?nopaste
16:32 Psyche^ joined #parrot
16:33 nopaste "skids" at 71.192.212.78 pasted "Meanderings on Parrot's STRING hashval caching." (277 lines) at http://nopaste.snit.ch/16809
16:48 cotto darbelo, pong
16:50 Infinoid Are STRING hashvals stored in PBC?
16:52 darbelo cotto: The test grammar can now parse the tests ( which means I've ran out of easy stuff ;) and wanted to sanity check some code-generations ideas with you.
16:55 darbelo I used an almost-empty actions file and with "--target=parse" I ended up with this:
16:55 nopaste "darbelo" at 200.49.154.172 pasted "snippet of parsed decTest file" (11 lines) at http://nopaste.snit.ch/16810
16:56 bobke joined #parrot
16:59 tetragon joined #parrot
17:00 darbelo Which looks to be what I want. My idea is to not use the ->post->pir path but to just walk the tree and output text (which happens to be pir)
17:01 darbelo Is that sane? Am I abusing the toolchain? Both?
17:02 cotto looking...
17:02 jonathan darbelo: Doesn't sound too abusive but there may be a better way
17:02 jonathan darbelo: e.g. you could transform it to PAST nodes that call the 'is' function.
17:02 cotto what he said
17:02 jonathan And then just let the code generation to PIR happen from that.
17:04 cotto btw, feel free to commit early and often, even if the code is incomplete or doesn't dtrt
17:05 nopaste "darbelo" at 200.49.154.172 pasted "Here's the grammar." (56 lines) at http://nopaste.snit.ch/16811
17:06 darbelo The 'number' token is a mess, but I couldn't get it any simpler than that and still parse all the notations used on the decTest files.
17:08 cotto You could break it into smaller pieces, but it looks mostly sane.
17:09 dihymo joined #parrot
17:09 cotto I'd break out that middle part so you're matching quotes correctly.
17:10 cotto i e ['] <middle part> ['] | ["] <middle part> ["] | <middle part>
17:11 dihymo if two scripts snippets are written for two parrot languages could they actually share the same context as if they were in the same language?
17:11 cotto you mean parrot-level context?
17:12 dihymo yes
17:12 jonathan dihymo: Depends exaclty what "context" means.
17:12 jonathan I guess it works at the block/sub level.
17:12 cotto darbelo, bbs
17:13 jonathan darbelo: BTW, the grammar decTest::Grammar is PCT::Grammar;
17:13 jonathan is near the bottom?
17:13 dihymo <?php $a = 5 ?> <?lisp (+ a 5) ?> <?php echo $a ?>
17:13 dihymo the last one would output 10
17:14 dihymo granted that would probably unleash skynet but...
17:14 darbelo jonathan: It's a the top of the file. Looks like a paste error.
17:15 jonathan I suspect that'd only work if each of those statements was executing in a lexical scope of its own, which implies $a is a global, plus the compilers know how to name-mangle away the $.
17:15 jonathan darbelo: ah, ok
17:16 dihymo doesn't the language implementation do the name-mangling?
17:16 Khisanth joined #parrot
17:16 dihymo i heard there was a php implementation
17:16 jonathan Yes, the language can implement the namespace interface in order to handle this.
17:17 dihymo i mean when you target a language to parrot you convert to parrot code
17:17 jonathan Right.
17:17 jonathan PHP implementation - yes, there is one underway, I don't know much about it but can probably point you at something...moment...
17:18 jonathan http://wiki.github.com/bschmalhofer/pipp
17:18 jonathan (Linked from http://www.parrot.org/languages if you want to look up other language-on-Parrot efforts.)
17:18 dihymo it would cause the sharing and development of scripts in one's favorite or the "the best language for the job" TM at that moment to explode
17:18 dihymo cool thx
17:19 jonathan http://blogs.gurulabs.com/stephen/2009/​05/cross-language-library-loading.html # is a reecnt post on the language interop front
17:20 dihymo what would be great is if you could create objects in say .Net for access to their standard features, and then manipulate them in lisp
17:20 dihymo it would make foreign function interfaces obsolete
17:21 dihymo i actually have a language i'd like to implement and using a host language has been um clumsy i'd like to see what parrot could do
17:22 clinton joined #parrot
17:22 jonathan Parrot has a bunch of compiler tools that help make things easier.
17:38 * skids surprised no languages/busybox yet :-)
17:38 davidfetter joined #parrot
17:54 dalek decnum-dynpmcs: r82 | darbelo++ | trunk/aux (7 files):
17:54 dalek decnum-dynpmcs: Add basic, not-yet functional, unMakefiled starts for a PCT-based decTest
17:54 dalek decnum-dynpmcs: parser.
17:55 dalek decnum-dynpmcs: review: http://code.google.com/p/decn​um-dynpmcs/source/detail?r=82
18:16 polyglotbot joined #parrot
18:25 cotto back
18:31 dalek rakudo: 97f1415 | pmichaud++ | src/ (4 files):
18:31 dalek rakudo: Refactor assignment in terms of STORE.  This brings us somewhat
18:31 dalek rakudo: closer to the spec, eliminates the multi-variants of infix:<=>,
18:31 dalek rakudo: eliminates a few "isa" checks, and paves the way for better
18:31 dalek rakudo: rw and postcircumfix handling.
18:31 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/9​7f1415cb64f7b0dba9bf37a9b69a85f8d237b6b
18:32 cotto rakudo: say "hi"
18:32 cotto perl6: say "hi"
18:33 polyglotbot OUTPUT[error:imcc:syntax error, unexpected $end ('þ')␤   in file '/home/tene/parrot-build2/runt​ime/parrot/library/config.pbc' line 1␤hi␤]
18:33 polyglotbot OUTPUT[error:imcc:syntax error, unexpected $end ('þ')␤   in file '/home/tene/parrot-build2/runt​ime/parrot/library/config.pbc' line 1␤hi␤]
18:39 Zak joined #parrot
18:52 dihymo what if the statements in a language are structure based rather than token based?
18:52 dihymo in pseudo lisp it might be like this
18:53 dihymo say the context is add/subtract
18:53 dihymo so (5 6 nil) -> would respond with (nil nil 11)
18:53 dihymo (5 nil 11) -> (nil 6 nil)
18:54 dihymo (nil 6 11) -> (5 nil nil)
18:54 cotto joined #parrot
19:07 supergiantrobot joined #parrot
19:07 supergiantrobot hello
19:07 purl hey, supergiantrobot.
19:07 supergiantrobot I am trying this...
19:08 supergiantrobot parrot -o sum.pasm sum.pir
19:08 supergiantrobot parrot sum.pasm
19:08 supergiantrobot But the latter command just sits
19:09 supergiantrobot Why?
19:12 NotFound supergiantrobot: if you are trying to compiler to bytecode, the extension is pbc, no pasm
19:12 supergiantrobot right
19:12 supergiantrobot but I want to save pasm
19:12 supergiantrobot (for a demo)
19:12 supergiantrobot and then run pasm
19:12 supergiantrobot should the parrot sum.pasm work?
19:13 supergiantrobot The docs seem to imply it does
19:13 NotFound I don't think imcc has that capability, at least with the -o optio
19:14 supergiantrobot The docs definitely think .pasm should run
19:15 NotFound A .pasm file should run, but Is a pasm what you have?
19:15 supergiantrobot yes
19:15 supergiantrobot Hmmm
19:16 supergiantrobot I created a new pasmand it works
19:16 supergiantrobot the other pasm is generated
19:17 NotFound Please nopatse sum.pir
19:17 supergiantrobot It is here ... http://docs.parrot.org/parrot/​devel/html/docs/intro.pod.html
19:18 NotFound Summing squares?
19:18 supergiantrobot Yes
19:19 dalek TT #745 created by Austin_Hastings++: Make `newclass ` and `newclass ` consistent
19:19 supergiantrobot Seems to loop forever
19:20 Austin_Hastings joined #parrot
19:20 Austin_Hastings Hello, #parrot.
19:20 NotFound Ah, yes, there is a comment in the generated pasm
19:20 supergiantrobot I saw
19:21 supergiantrobot But I looked at the ticket
19:21 NotFound Using -t1, looks like it never gets to start running bytecode.
19:21 supergiantrobot weird
19:22 supergiantrobot any suggestions?
19:22 purl any suggestions are welcome.  (including ripping it out entirely :))
19:23 NotFound I'll take some look
19:27 supergiantrobot If I convert the factorial app example to pasm and run it, it core dumps
19:30 NotFound Same here
19:31 cotto joined #parrot
19:31 supergiantrobot me mac
19:31 supergiantrobot leopard
19:32 NotFound linux i386
19:38 NotFound Breaks at line 333. That's half-demoniac ;)
19:40 NotFound Catched the segfault, r[0] is NULL at that line
19:44 dalek parrot: r39435 | NotFound++ | trunk/compilers/imcc/parser_util.c:
19:44 dalek parrot: [cage] add an assertion
19:44 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39435/
19:56 supergiantrobot joined #parrot
20:01 Austin_Hastings left #parrot
20:07 supergiantrobot NotFound
20:07 purl NotFound is Julián Albo <mailto:julian.notfound@gmail.com>
20:07 supergiantrobot Any luck?
20:07 supergiantrobot Workaround?
20:07 purl Workaround is to force Perl to use magical string
20:08 NotFound Just catched the segfault with that assertion, nothing more by now
20:08 supergiantrobot OK
20:08 supergiantrobot Is it supposed to work?
20:08 NotFound Don't know how to work around ir, I'm not fluent with pasm
20:09 Infinoid purl, forget Workaround
20:09 purl Infinoid: I forgot workaround
20:09 NotFound At leaste is supposed to not segfault and to not loop forever.
20:10 supergiantrobot right
20:14 NotFound Looks like get_params without args has something to do with the segfault
20:15 supergiantrobot command-line args?
20:15 NotFound The get_params opcode
20:15 supergiantrobot ah
20:17 supergiantrobot joined #parrot
20:17 NotFound Yes, if I add "0" to that line it doesn't segfault.
20:18 NotFound Looks like both the pasm generator and the pasm parser are broken,
20:20 NotFound main:
20:20 NotFound get_params
20:20 NotFound end
20:20 NotFound This minimal example segfaults
20:30 dalek parrot: r39436 | NotFound++ | trunk/compilers/imcc/parser_util.c:
20:30 dalek parrot: [imcc] die politely on get_args and other opcodes when compiling pasm
20:30 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39436/
20:32 NotFound That catches the factorial.pasm crash, but not the sum.pasm problem
20:40 Infinoid ./src/pmc/bignum.pmc: In function 'bignum_div_bignum_float':
20:40 Infinoid ./src/pmc/bignum.pmc:483: warning: 'bn' may be used uninitialized in this function
20:41 Infinoid Looking at the code in question, that does indeed look broken.  But it apparently hasn't been touched in months, so I'm not sure why the warning suddenly showed up
20:43 NotFound Infinoid: maybe it has flourished because of the station ;)
20:44 bacek joined #parrot
20:45 jan joined #parrot
20:47 supergiantrobot joined #parrot
20:47 Infinoid Maybe it's exposed because I configured with --optimize *shrug*
20:48 NotFound Infinoid: I think so
20:51 Infinoid Coke: Is it possible to configure partcl against a parrot checkout (non-installed) yet?  I want to expand my benchmarking/profiling suite a bit
20:52 Infinoid opbots, names
20:53 Infinoid hmm, looks like not
20:54 Infinoid lua can't either, but then, lua doesn't even provide a --parrot-config option, so it doesn't get my hopes up.
20:56 NotFound I think I've now a better catch :)
20:57 dalek parrot: r39437 | NotFound++ | trunk/compilers/imcc/parser_util.c:
20:57 dalek parrot: [imcc] die politely on get_args and other opcodes used without args when compiling pasm
20:57 dalek parrot: review: https://trac.parrot.org/parrot/changeset/39437/
20:58 NotFound supergiantrobot: now catches both factorial.pasm and sub.pasm
20:59 NotFound s/sub/sum
21:01 * Infinoid profiles rakudo build step 1 (running PGE to create src/gen_grammar.pir)
21:03 NotFound supergiantrobot++ for the report
21:05 supergiantrobot Hey
21:05 supergiantrobot Does it work?
21:05 purl i heard Does it work was it used? =-)
21:05 supergiantrobot NotFound?
21:05 purl NotFound is Julián Albo <mailto:julian.notfound@gmail.com>
21:06 NotFound supergiantrobot: no, as the comment in the generated code says, generated pasm files are b0rken
21:06 supergiantrobot Hmmm
21:06 supergiantrobot I am working on an article
21:07 supergiantrobot I wanted to include the PASM for sum.pir
21:07 NotFound I think you can fix them by editing the set_returns and get_params opcodes generated
21:07 supergiantrobot I am not down with PASM
21:07 supergiantrobot How?
21:08 supergiantrobot URL to example?
21:08 NotFound supergiantrobot: you can compile the pir to pbc and look at the disassembly
21:08 supergiantrobot k
21:09 NotFound Mmmm... not very useful for the set_returns
21:10 supergiantrobot which tools disassembles?
21:10 NotFound pbc_disassemble
21:11 NotFound Forget it, is not useful for hand written pasm
21:11 purl NotFound, I didn't have anything matching it, is not useful for hand written pasm
21:12 supergiantrobot i disassembled.
21:13 supergiantrobot does it
21:13 supergiantrobot not too different
21:14 NotFound I think you can just delete the no-args set_returns and get_params
21:15 supergiantrobot Deleting set_returns works
21:18 Infinoid PGE spends 65% of its time in utf8_set_position
21:19 NotFound Infinoid: no wonder
21:21 Infinoid All that overhead completely vanishes with --encoding=ascii, and the resulting profile only has 33% as many samples
21:25 jonathan Infinoid: Really? I thought recent changes optimized that somewhat...
21:25 pmichaud for compiling the grammar -- yes, we still do that as utf8
21:26 pmichaud when rakudo itself runs, it's fixed width
21:26 jonathan Ah, OK.
21:26 pmichaud I hadn't tried fixing the grammar yet -- wasn't a huge priority
21:26 Infinoid https://quack.glines.org/upload/inf​inoid/kcachegrind-PGE_with_utf8.png
21:26 Infinoid https://quack.glines.org/upload/infin​oid/kcachegrind-PGE_without_utf8.png
21:26 payload joined #parrot
21:26 Infinoid it's pretty.
21:27 jonathan wow.
21:27 pmichaud Infinoid: You're just running the compile-rakudo-grammar step, yes?
21:27 Infinoid yes, very first thing you get when you type "make" in rakudo
21:27 pmichaud right.
21:28 jonathan Infinoid: Curious, is spending so mcuh time in compact_pool usual?
21:28 Infinoid I don't think I can optimize UTF8SKIP() any farther, but that's where it's spending all of its time
21:28 Infinoid jonathan: Spending 2% in GC doesn't seem too bad to me
21:28 jonathan True.
21:29 jonathan Well, a lot of the cost is in memcpy
21:29 pmichaud okay, I'm confused.
21:29 pmichaud pgc.'command_line'(args, 'target'=>'PIR', 'combine'=>1, 'transcode'=>'iso-8859-1')
21:29 pmichaud it looks to me as though it's already switching to iso-8859-1
21:30 pmichaud (that from runtime/parrot/library/PGE/Perl6Grammar.pir:69)
21:30 Infinoid Seems to me that PGE is a compile-time cost, so it shouldn't be as high a priority for rakudo as runtime performance
21:30 Infinoid Still, it was a bit surprising.
21:30 pmichaud it is a compile-time cost for building the compiler, yes.
21:31 pmichaud for parsing Perl 6 programs it's important
21:31 pmichaud (ie., as part of Rakudo runtime)
21:31 pmichaud but Rakudo already takes care of that.
21:32 pmichaud anyway, I'm surprised that the grammar isn't already transcoding to fixed width.  I wonder if the grammar has any characters outside of the iso-8859-1 set in it.
21:32 Infinoid I can try a spectest, I suppose
21:32 supergiantrobot Is there a roadmap online?
21:32 Infinoid supergiantrobot: https://trac.parrot.org/parrot/wiki/ParrotRoadmap
21:33 Infinoid oops, dead link
21:33 supergiantrobot Thanks
21:33 Infinoid https://trac.parrot.org/parrot/roadmap
21:33 pmichaud the rakudo spectest won't (shouldn't) show any difference
21:33 pmichaud the speed of the Perl6Grammar step doesn't matter once Rakudo is compiled
21:33 Infinoid right, but I was thinking it would show how correct it was
21:34 supergiantrobot Hmmm
21:34 supergiantrobot A little sparse.
21:34 supergiantrobot What's on the menu for 2.0?
21:34 Infinoid (if we hit an encoding error, it would probably show up as methods/operators not found, or the like)
21:34 supergiantrobot Perl 6?
21:34 purl Perl 6 is probably amazing.
21:34 pmichaud HLLCompiler traps transcoding errors and aborts the transcode
21:35 Infinoid ok
21:35 pmichaud so, it tries to convert the source to ascii/iso-8859-1, but if that conversion fails for some reason then things are done using whatever the input source was
21:35 pmichaud (utf8 in this case)
21:35 Infinoid PGE completed successfully with --encoding=ascii, if that helps.  I'm not terribly familiar with the parsing side of parrot, so please excuse my ignorance
21:36 pmichaud well, that would probably ultimately fail.
21:36 * Infinoid <-- low level guy
21:36 pmichaud because the input file isn't ascii.
21:36 pmichaud so, PGE will parse it okay, but the code it generates won't be correct (literals, mainly)
21:37 Infinoid Ok, that's what I was afraid of.  I'll try iso-8859-1
21:37 pmichaud well, the --encoding parameter really needs to be utf8, since that's the encoding of the grammar.pg file
21:37 pmichaud --encoding doesn't do any transcoding, it just tells HLLCompiler how to read the file
21:37 pmichaud more to the point, valid values should be   utf8 and fixed_8
21:37 pmichaud because we're specifying the encoding, not the charset
21:38 Infinoid Right.  So I'm really profiling the wrong thing to begin with
21:39 * Infinoid looks into reducing calls to memcpy
21:42 supergiantrobot Is THE Perl 6 going to run on Parrot?
21:44 bacek good morning
21:44 purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
21:44 NotFound supergiantrobot: there is no THE Perl 6
21:44 NotFound supergiantrobot: anything that meets the specifications will be called Perl 6
21:44 supergiantrobot How about A Perl 6?
21:44 purl A Perl 6 is amazing.
21:45 NotFound supergiantrobot: rakudo in perl 6 on parrot
21:45 NotFound s/in/is
21:46 nopaste "bacek" at 114.73.186.208 pasted "Possible utf8 speedup for Infinoid to check." (39 lines) at http://nopaste.snit.ch/16814
21:46 bacek Infinoid: can you try your benchmark with patch from nopaste?
21:47 bacek It basically select direction of String_iter movement instead of always start from start.
21:48 Infinoid Sure, one moment
21:49 Infinoid hmm, 1 out of 1 hunk FAILED -- saving rejects to file src/string/encoding/utf8.c.rej
21:49 bacek yak. I was sure that diff was against trunk...
21:49 jonathan supergiantrobot: For more info on Rakudo see www.rakudo.org - I think it's probably fair to say that it's the biggest compiler currently built on PCT.
21:49 supergiantrobot Is there a scorecard of which languages are where on Parrot?
21:50 supergiantrobot Will do.
21:50 Infinoid I'm trying to apply it to trunk r39436, plus a couple of other (non-utf8) performance tweaks
21:50 NotFound supergiantrobot: http://www.parrot.org/
21:50 purl http://www.parrot.org/ is the new homepage and feather aka http://www.parrotvm.org/
21:52 nopaste "bacek" at 114.73.186.208 pasted "utf8_set_position full version for Infinoid" (25 lines) at http://nopaste.snit.ch/16815
21:52 bacek Infinoid: in nopaste is how utf8_set_position look after patch. Just in case
21:52 Infinoid oh, I said "non-utf8" but I did put a likely() in there and forgot about it.  My bad.
21:52 * Infinoid hand-merges
21:55 Infinoid Reducing calls (well, macro invocations) of UTF8SKIP would indeed improve performance
21:55 Infinoid profiling now
21:55 Infinoid The last time, it ended up calling UTF8SKIP about 8 billion times
21:56 bacek There is still a lot of UTF8SKIP. But it should be less when we just rollback few characters
21:56 clinton left #parrot
21:56 bacek gotta go soon.
21:57 nopaste "supergiantrobot" at 24.211.234.118 pasted "draft of article about parrot for Linux Pro magazine" (452 lines) at http://nopaste.snit.ch/16816
21:57 Infinoid Ok, this patch didn't make much difference for the PGE use-case
21:58 Infinoid 65% became 63%
21:58 Infinoid But I can give you per-line percentages if you want more detail
21:58 supergiantrobot If anyone has time to proof the article, I would welcome the feedback.
21:58 bacek Infinoid: yes please
22:00 Infinoid bacek: It's about the same as before... 59% of time spent in UTF8SKIP, this time in utf8_skip_forward()
22:00 Infinoid supergiantrobot: Awesome.  I'll have a look as soon as I'm done with this profiling stuff
22:00 jonathan supergiantrobot: will read it also
22:00 supergiantrobot Great.
22:00 supergiantrobot My email is martin.streicher@gmail.com.
22:00 supergiantrobot It is missing Figure 1, because I have to draw it this evening,
22:01 supergiantrobot But it'll depict what is there in words.
22:01 bacek Infinoid: how it distributed over utf8_skip_* in utf8_set_position?
22:01 supergiantrobot If you send me a note, I'll be sure to thank you in the credits.
22:02 supergiantrobot If you have an official role in the project, let me know what it is in the email, too.
22:02 Infinoid bacek: 2284 calls to backward, 117828 calls to forward
22:03 Infinoid It's a little hard to read in kcachegrind, because those functions got inlined
22:04 Infinoid If it helps, utf8_set_position's biggest caller for this PGE benchmark was get_codepoints (called 85857 times)
22:06 supergiantrobot Thank you
22:09 bacek Infinoid: oh shi... get_codepoint always start from start...
22:10 Infinoid bacek: Do you have kcachegrind installed?  If so, I can send you the callgrind data
22:10 bacek No surprise it SLOW.
22:11 Infinoid If you have a better idea, we can always update or extend the API :)
22:11 bacek Infinoid: bacek@bacek.com. I'll check it later
22:12 Infinoid Ok.  I'll rebase on stock trunk so your line numbers will match up
22:18 bacek I have better idea. Separate array-of-bytes and STRING...
22:19 Infinoid (email sent)
22:23 pmichaud separating array-of-bytes doesn't help a lot in PGE's case.  It wants to work with characters/codepoints
22:23 pmichaud and I already know some ways to optimize PGE for the utf8 case
22:24 pmichaud I had already tried a version of utf8_skip_backward and also found it wasn't terribly helpful.
22:25 pmichaud the trick is to keep PGE from always having to start from the beginning of the utf8 string.
22:25 bacek we shouldn't internally work with utf8. Utf8 is transport encoding only...
22:25 pmichaud agreed, but we don't have another representation.
22:26 bacek ucs2?
22:26 purl i heard ucs2 was crippled also
22:26 pmichaud at the moment, ucs2 on Parrot requires ICU.
22:27 bacek afaik ICU is mandatory for Parrot now, isn't it?
22:27 pmichaud not until 2.0
22:27 bacek ah, ok.
22:27 pmichaud (well, 1.5)
22:28 bacek gotta go. See you tomorrow.
22:28 Infinoid that Linux Pro article is a little confusing to read, I think an "if-then-else" construct is an object on the PAST level but definitely not on the PIR level (which is what I originally thought when it said "object")
22:30 Infinoid I guess for me, "Parrot object" == PMC
22:31 rg joined #parrot
22:33 NotFound Will not be easier to recode the utf8 to ucs2?
22:33 NotFound Ah, don't read the last part
22:35 NotFound I don't think recoding utf8 to ucs2 will need to require icu.Is just utf8 decoding, which is just bit manipulations.
22:36 Zak joined #parrot
22:59 Zak joined #parrot
23:12 david joined #parrot
23:16 Austin_Hastings joined #parrot
23:28 NotFound Austin_Hastings: I've seen #745, but I don't think that using semicolons as namespace separator in new 'string' is supported.
23:28 jonathan It's not - use a key.
23:28 NotFound I mean newclass
23:28 jonathan Same.
23:31 jonathan If somebody has tuits, upgrading squawk to use $<foo>.ast rather than $( $<foo> ) would be nice.
23:31 NotFound So the problem is not that it does not take methods from the namespace, is just there is no the same class/namespace.
23:33 Austin_Hastings So the format that parrot reports class names in is not one of the supported ones for newclass?
23:34 NotFound Austin_Hastings: no. I thinked about that some days ago, more consistency will be helpful.
23:35 Austin_Hastings :-X
23:36 jonathan Austin_Hastings: It's just a debug/dumping format for the key. It hadn't occurred to me as confusing before, but I can see the potential for confusion.
23:38 Austin_Hastings Ahh, okay. Using newclass [ 'Foo' ; 'Bar' ; 'Dog' ] produces class-already-register error. Changing to ... 'Cat'] gets better behavior.
23:41 Austin_Hastings Amended, but I cannot close. Will one of you close out #745, please?
23:42 Austin_Hastings Do Iterator's have any kind of performance advantage when looking up the values of a hash?
23:43 Austin_Hastings That is, if I do $P0 = shift iter ; $P1 = iter[$P0]
23:43 Austin_Hastings is that faster than doing $P0 = shift iter ; $P1 = hash[$P0] ?
23:44 dalek TT #745 closed by Infinoid++: Make `newclass ` and `newclass ` consistent
23:45 Austin_Hastings Thank you, Infinoid.
23:47 jonathan Austin_Hastings: Heh, I didn't even know you *could* do that!
23:47 jonathan (on the Iterator)
23:47 Austin_Hastings Oh. Yeah.
23:47 jonathan Austin_Hastings: IIRC though, the Iterator contains a reference to the Hash PMC
23:47 Austin_Hastings It does.
23:47 * purl stays quiet
23:47 jonathan In which case it'd be an extra level of indirection.
23:48 Austin_Hastings So the hash pmc's don't try to cache the last lookup or anything?
23:51 NotFound I hope not.
23:51 Austin_Hastings Actually, that'd be the job of the iterator. Seems like a common case for the indexing behavior - they ought to do it.
23:52 Austin_Hastings (Especially considering how much stuff is built on hashes...)
23:52 Austin_Hastings Well, better for me that they don't. I can generate hash[key] with no guilt.
23:52 Austin_Hastings :)

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

Parrot | source cross referenced