Camelia, the Perl 6 bug

IRC log for #parrot, 2011-06-05

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:02 dalek nqp: 5a7f87b | jonathan++ | src/core/NQPMu.pm:
00:02 dalek nqp: Default get_bool override in NQPMu.
00:02 dalek nqp: review: https://github.com/perl6/nqp/commit/5a7f87b63d
01:00 dalek winxed: r1046 | NotFound++ | trunk/winxedst1.winxed:
01:00 dalek winxed: Initialize used subids at the start of the subs.
01:00 dalek winxed: Seems to be the better tradeof right now.
01:00 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=1046
01:08 kid51 joined #parrot
01:46 ligne joined #parrot
02:00 whiteknight left #parrot
02:07 kid51 What does this passage from docs/deprecations/how_to_deprecate.pod mean?
02:07 kid51 "set up automatic usage detection using api.yaml regexes (static usage detection) and/or Parrot_warn_deprecated (dynamic usage detection)"
02:13 dalek parrot: 2d79923 | jkeenan++ | docs/deprecations/how_to_deprecate.pod:
02:13 dalek parrot: Small grammatical and text formatting corrections only.
02:13 dalek parrot: review: https://github.com/parrot/parrot/commit/2d79923dcc
02:13 kid51 The instructions in this document - docs/deprecations/how_to_deprecate.pod - put a much greater burden on the deprecator than was earlier the case.
02:14 preflex left #parrot
02:16 preflex joined #parrot
02:40 kid51 left #parrot
02:45 hudnix left #parrot
02:49 bubaflub joined #parrot
03:03 Khisanth left #parrot
03:22 davidfetter joined #parrot
03:24 Khisanth joined #parrot
03:28 preflex left #parrot
03:31 preflex joined #parrot
04:02 dalek website: soh_cah_toa++ | Breakpoints...Again
04:02 dalek website: http://www.parrot.org/content/breakpoints...again
04:24 klavs joined #parrot
04:29 particle left #parrot
04:33 dukeleto ~~
04:43 bubaflub left #parrot
04:46 cotto hi dukeleto
04:47 cotto dukeleto, do you recall if there was any reason in M0 for the callee to do the work of calling conventions rather than the caller?  istr that there's no strong reason to pick one or the other from a theoretical perspective.
04:49 dukeleto cotto: i was thinking about that
04:49 cotto M0 has a passing test for jumping between chunks, but it may be tricky to do all the calling conventions work on the callee side without clobbering anything potentially important.
04:50 dukeleto cotto: i think there is no *theoretical* reason to choose callee vs. caller, but the design of M0 and some performance reasons will probably pick one or the other
04:50 dukeleto cotto: what do you mean?
04:50 dukeleto cotto: what is the current state?
04:51 dukeleto bubaflub++ and soh_cah_toa++ # blog posts
04:51 * dukeleto reminds the other gsoc students that his blog post radar is on
04:52 cotto dukeleto, when control flow moves to the callee, the caller's call frame is still the active one.  The callee would need to calculate the proper size of a new call frame, point PCF at the current call frame and store the new call frame in CF without overwriting any of the caller's registers.
04:52 cotto dukeleto, the current state is that goto_chunk is tested and works, but nothing more
04:53 cotto dukeleto++ # m0_cover is really nice.
04:53 dukeleto cotto: we are getting to the point where changing the spec means changing many files
04:53 cotto dukeleto, yes
04:54 dukeleto cotto: many test m0 files, that is
04:54 dukeleto cotto: what is the concern? that calling conventions isn't as isolated on one side as it could be?
04:54 theory left #parrot
04:54 dukeleto cotto: do we have any references about that? I would love to read a paper about it
04:55 cotto dukeleto, the concern is that it'll be hard for the callee to create a new call frame, store it in CF and point PCF at the caller's call frame without overwriting any registers in the caller's call frame that the caller might be relying on.
04:55 dukeleto cotto: i feel like we are operating on too little data
04:55 dukeleto cotto: i see you have been adding m0 test files like a madman
04:56 cotto dukeleto, that's possible.  I'm not sure where I'd find some appropriate research to dig through though.
04:56 cotto dukeleto, yes, for the easy ones.
04:56 cotto s/ones/ops/
04:58 cotto I think the most irritating part of updating the spec is updating hello_canon.m0b.  Updating text isn't bad once I get in the flow.
05:01 sorear either amd64 or arm reserves R11 in the default calling convention for "procedure prologue or thunk scratch register"
05:01 cotto dukeleto, I'm inclined to say that the caller needs to take care of calling conventions setup and teardown because it can easily make sure it's not clobbering anything important, but I want to verify that doing so doesn't mean giving up anything important.
05:02 sorear so it can't be used for argument passing, and it isn't call preserved either
05:02 cotto sorear, I was toying with something similar.
05:04 cotto I like having SPC4RENT in the spec, but it's not strictly necessary.
05:08 dukeleto msg allison do you have any more info about the reasons and importance of concentrating work on the callee vs caller?
05:08 aloha OK. I'll deliver the message.
05:10 bubaflub joined #parrot
05:15 cotto dukeleto, I'm thinking that M0 registers should always be 8 bytes to accommodate double and long as N and I.  Thoughts?
05:19 dukeleto cotto: what do other systems use?
05:20 cotto dukeleto, you mean other VMs?
05:20 dukeleto cotto: yeah
05:20 dukeleto cotto: but it seems very reasonable. Just wondering what the possible downsides could be
05:21 dukeleto cotto: bytecode will be larger, but i think supporting doubles and longs is a basic feature that will be quite tasty
05:22 soh_cah_toa i agree and now i sleep
05:22 soh_cah_toa left #parrot
05:22 cotto dukeleto, bytecode will be less bloated if we have the ability to load less than 8 bytes into a register.
05:23 cotto lots of potential for fun and explosions from that though
05:23 sorear Java has a rule where "double" and "long" take up 2 constant table slots or 2 local slots, and you're forbidden to reference the second in any way
05:23 cotto but if we're planning on analyzing M0, it might not be an insane approach
05:23 davidfetter left #parrot
05:23 sorear this rule is often considered a terrible mistake
05:24 cotto sorear, I love the random relevant bits of information you come up with
05:24 cotto sorear, that does sound like an ugly special case
05:26 sorear CLR locals slots can hold up to 0x3f000 bytes of data, but are (more?) statically typed
05:27 sorear can't remember offhand if .class stores type information for locals at all
05:30 dukeleto cotto: seems like knowing how Java attempted to solve the problem is very valuable
05:30 dukeleto how important is bytecode bloat?
05:31 cotto dukeleto, java has a number of primitives
05:31 cotto http://www.javacamp.org/javaI/primitiveTypes.html
05:31 dukeleto harddrives are way under $1/GB these days. Seems like optimizing for disk space isn't nearly as important as optimizing for runtime speed
05:32 sorear bytes take up more than just disk space
05:32 dukeleto for embedded systems, bytecode size is important
05:32 dukeleto sorear: true
05:32 cotto dukeleto, I agree, but that doesn't mean we should throw caution to the wind.
05:32 sorear they also require disk read bandwidth (which hasn't actually changed much in the last few decades) and network bandwidth (which got FAR more expensive in the last ten years)
05:32 cotto CPU caches are pretty important too
05:32 bubaflub hey dukeleto
05:33 dukeleto bubaflub: wazzup
05:33 dukeleto bubaflub: also, nice work on GMP-from-Winxed!
05:33 dukeleto cotto: no caution is being thrown :)
05:34 dukeleto cotto: merely wandering what the relative importance of optimizing for bytecode size vs. runtime speed should be
05:34 bubaflub dukeleto: thanks!  the entire Winxed class with docs is done.  next up is the test suite - the absolute worst case scenario is I roll my own.
05:35 dukeleto bubaflub: you have many options
05:35 sorear dukeleto: optimize for runtime speed of a largish program, and you'll naturally get the right balance because of L1 cache effects
05:35 dukeleto sorear: sounds good to me.
05:36 dukeleto cotto: so what are the concerns if we change to 8 byte opcodes?
05:36 dukeleto cotto: and do we want to emulate how java attempted to solve this (i assume not) ?
05:37 cotto dukeleto, I'm not suggesting 8 byte opcodes, just 8 byte registers.
05:40 dukeleto cotto: ah, yes, meant that.
05:41 bubaflub dukeleto: i'm going to do some more investigation on the testing front, but the project considers a function fully tested if it has at least two tests so maybe the conversion of other test suits can be a wishlist rather than a deliverable.
05:42 cotto dukeleto, wasted space, higher memory use, bytecode bloat
05:42 davidfetter joined #parrot
05:42 dukeleto cotto: i am interested to know more about the bytecode structure of Rubinius (attempting to search for stuff)
05:43 dukeleto cotto: what kind of % change in bytecode is expected from that change?
05:43 dukeleto cotto: % change in the lengh of bytecode
05:43 dukeleto s/lengh/length/
05:44 cotto dukeleto, the bytecode segment would stay the same, constants table would get bigger proportionally to the number of IN values stored there, the metadata segment wouldn't change
05:44 cotto so, not a whole lot, especially because it's easier to use set_imm to generate I values <265^2
05:45 bubaflub left #parrot
05:49 dukeleto cotto: so it seems that bytecode bloat isn't much, since it only effects the constants table
05:49 cotto yes
05:49 cotto so runtime call frame size is the main concern
06:03 theory joined #parrot
06:03 davidfetter left #parrot
06:05 dukeleto cotto: i am 3 hours ahead of you. I am preparing my sleeping call frame
06:06 cotto dukeleto, 'night
06:06 theory left #parrot
06:06 dukeleto cotto: please add your ideas/concerns for register sizes to the spec, if you haven't already
06:06 cotto dukeleto, deal
06:22 davidfetter joined #parrot
06:56 particle joined #parrot
07:05 davidfetter left #parrot
07:12 mj41 joined #parrot
07:30 dalek parrot/m0-spec: 3611fa4 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
07:30 dalek parrot/m0-spec: add a note about call frame size
07:30 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/3611fa4248
07:37 fperrad joined #parrot
08:06 dukeleto left #parrot
08:53 mj41 left #parrot
09:03 klavs left #parrot
09:17 mtk left #parrot
09:25 mtk joined #parrot
09:27 klavs joined #parrot
09:31 particle1 joined #parrot
09:34 klavs pdd32_m0.pod states that const, meta and bc segments define "number of opcode_t-sized units in this segment", but it looks like "number of byte-sized units in this segment". Where the mistake is? (in spec or assembler?)
09:35 particle left #parrot
09:52 klavs left #parrot
10:39 lucian joined #parrot
11:05 lucian left #parrot
11:28 ligne left #parrot
11:39 lucian joined #parrot
12:18 lucian allison: i seek guidance
12:43 ambs joined #parrot
12:46 JimmyZ joined #parrot
12:54 Eclesia joined #parrot
12:54 Eclesia hi
12:55 lucian i'm trying to figure out how to implement scope in puffin
13:06 dalek parrot/m0-spec: 902d905 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
13:06 dalek parrot/m0-spec: switch m0b to be based on 32-bit unsigned integers
13:06 dalek parrot/m0-spec:
13:06 dalek parrot/m0-spec: This doesn't change anything that the assembler or interpreter need to
13:06 dalek parrot/m0-spec: care about (other than a minor change in the header) but should be much
13:06 dalek parrot/m0-spec: less ambiguous than defining everything in terms of the under-defined
13:06 dalek parrot/m0-spec: opcode_t.
13:06 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/902d905033
13:06 cotto hope that works
13:09 zby_home joined #parrot
13:18 JimmyZ_ joined #parrot
13:22 Eclesia is possible to store additional informations in parrot bytecode ?
13:22 ligne joined #parrot
13:22 JimmyZ left #parrot
13:22 JimmyZ_ is now known as JimmyZ
13:30 moritz yes, with annotations
13:35 Eclesia moritz: if I want to express a constraints on a field for example. let's say something like 'Can not be null'
13:36 Eclesia it means It can be add as an as an annotation wish will be available in the bytecode ?
13:37 Eclesia and potentially used by the compiler to ensure this constraint is validate at compilation time
13:37 kid51 joined #parrot
13:38 * ambs is drowning moritz in work O:-)
13:42 mikehh kid51: you commented that the deprecation procedure imposes a bigger burden on the deprecator (yes), any suggestions
13:44 mikehh the idea was to put deprecation info into the docs rather than on the wiki so they are available in the repo
13:44 mikehh I would like to automate as much as possible of course, any ideas on that
13:50 NotFound Eclesia: usually compiler generate bytecode, don't read it.
13:51 kid51 mikehh: I agree that putting it in docs rather than wiki is a good thing.
13:51 kid51 But I was surprised at how *much* must be done to effect deprecations
13:52 kid51 For example, the clause about 'regex': only 2 of 61 items in api.yaml have that feature.
13:52 Eclesia NotFound: if a piece of code declares a dependency to another piece of code of another file. then the compiler might check a few thinks, at least that the called function really exist.
13:53 Eclesia so I could be possible to add more checks
13:53 Eclesia it*
13:53 kid51 It also implies that the "deprecator" -- I'm reading the doc as if it were a single person performing all tasks -- has to do testing in all those HLLs/project.
13:53 kid51 In short, I found it intimidating ...
13:53 kid51 ... which says as much about me as about the doc, to be sure.
13:54 kid51 It also implies that, once agreement to deprecate is reach, there ought to be immediate changes in master to warn that some feature has been deprecated.
13:54 NotFound Eclesia: yes, almost all is technically possible, but I doubt about the practicity of that way in an environment of highly dynamic types and runtime binding.
13:54 kid51 I'm sure I wouldn't know how to do that.
13:55 kid51 mikehh:  Can you look at http://trac.parrot.org/parrot/ticket/1682 and advise the steps that will need to be taken to do deprecation and merge that patch/branch properly?
13:55 mikehh kid51: I just transcribed the docs from the wiki - I think it really is a team effort rather than a burden on a single developer
13:56 kid51 okay, I wasn't up-to-date with what was on the wiki.
13:56 lucian left #parrot
13:58 Eclesia NotFound: I try to build a back-end langage with static types, constraints and blackboxes to reduce errors. I'm not much concerned by dynamic types and script langages :)
13:59 mikehh kid51: I think that any branch that does deprecate something needs to run at least up to fulltest in parrot, and preferably run things like winxed and rakudo tests
14:00 mikehh preferably on different platforms (i.e this is the team effort part)
14:00 kid51 mikehh: I tend to agree with you, and I always run up thru make fulltest -- I just no longer have the disk space to run rakudo tests
14:00 lucian joined #parrot
14:01 NotFound Eclesia: the probably code annotation is not the way to go, it will be probably better to store special purpose pieces of info.
14:01 mikehh this implies that we need to be able to submit a test run on other platforms somewhere else
14:02 mikehh and view the results
14:03 mikehh also we can request that others test on different platforms
14:03 kid51 Yes.
14:03 * kid51 sheds a tear for smolder
14:04 mikehh I am trying to work on that too :-}
14:05 Eclesia NotFound: at least it's possible, I have the answer I wanted. thanks
14:05 Eclesia ++
14:05 Eclesia left #parrot
14:11 kid51 If I am looking at a git pull request from an outside repository, such as this one, https://github.com/parrot/parrot/pull/135
14:11 kid51 ... how do I simply download or obtain the diff so that I can examine it locally before doing any merging?
14:21 mikehh kid51: you could clone and pull into the clone
14:22 kid51 mikehh: That seems like a lot of work.  That's beyond my git-fu.
14:23 kid51 I am requesting that the author of that pull request attach a diff to one of the 3 Trac tickets he's looking at.
14:24 ligne kid51> thanks for looking at that :-)
14:24 ligne i'd have attached it, but i don't seem to have the right magics to comment on tickets.
14:24 kid51 ligne:  Have you created a Trac account?
14:24 ligne kid51> yeah.  i'm 'ligne' there too.
14:25 mikehh kid51: I tend to keep a clean clone of the repo which I pull from origin and use a copy or clone of that for all my work
14:27 kid51 ligne: Well, one thing I *do* know how to do (and have the power) is to grant those permissions.  You have been granted developer status, which enables you to create or comment on tickets.  Please try that attachment.
14:27 ligne fwiw, i'd probably just create a new branch, pull into that, and then delete the branch afterwards
14:27 ligne kid51> thanks!
14:28 kid51 ligne:  AAMOF, I want to apply the patch to a branch I've locally created.  I don't want to directly merge into master.
14:29 ambs_ joined #parrot
14:29 ambs left #parrot
14:29 ambs_ is now known as ambs
14:29 ligne though now i actually try that, it turns out it doesn't work so good if the branch points are out of sync.
14:31 ambs left #parrot
14:31 kid51 ligne:  Well, all I'm currently looking for is a plain-text file holding a diff of your two patches.
14:31 kid51 You could even paste it.
14:31 kid51 aloha, nopaste?
14:31 aloha kid51: nopaste is is http://nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl)
14:31 rohit_nsit08 joined #parrot
14:31 rohit_nsit08 Coke_: hello
14:32 * kid51 generally ignores all github comments and pull requests in order to avoid these problems
14:32 * kid51 acknowledges not being young and hip to all the github goodies; is quite willing to look at patches sent as email attachments.
14:35 lucian_ joined #parrot
14:39 lucian left #parrot
14:43 ligne kid51> added as an attachment to TT#2116.
14:46 bluescreen left #parrot
14:46 bluescreen joined #parrot
14:47 dalek nqp: 44a422b | jonathan++ | src/pmc/sixmodelobject.pmc:
14:47 dalek nqp: Make defined v-table overridable.
14:47 dalek nqp: review: https://github.com/perl6/nqp/commit/44a422b915
14:53 whiteknight joined #parrot
14:53 theory joined #parrot
14:56 kid51 ligne: Got it, testing with it.  Will report results later.  Thanks.
14:57 ligne kid51> cool :-)
15:08 klavs joined #parrot
15:13 mikehh_ joined #parrot
15:16 mikehh left #parrot
15:16 kid51 ligne:  Now that you can create Trac tickets, you may wish to create one for your other patch.
15:22 hudnix joined #parrot
15:29 benabik kid51: (re: examining a separate repo in git) if you `git fetch URL branch` it will put that branch into FETCH_HEAD, which you can use something like a temporary branch.
15:34 ligne kid51> ok, will do
15:35 ligne and it seems that tools/dev/merge_pull_request.pl is meant for exactly this sort of thing
15:43 fperrad_ joined #parrot
15:44 bluescreen left #parrot
15:46 preflex left #parrot
15:46 fperrad left #parrot
15:46 fperrad_ is now known as fperrad
15:46 lucian_ it isn't clear what method adds an item at the beginning of a ResizablePMCArray
15:47 lucian_ is now known as lucian
15:47 whiteknight unshift
15:47 lucian whiteknight: ah, thanks. and push or append for the end? docs are contradictory
15:48 whiteknight push/pop works on the end of the list. shift/unshift works on the beginning
15:48 theory left #parrot
15:48 lucian ok
15:48 whiteknight <insert standard disclaimer about the performance impacts of shift/unshift>
15:48 lucian i really don't care about performance *at all* right now
15:49 whiteknight yeah, i figured
15:49 whiteknight but information is good to have
15:49 preflex joined #parrot
15:49 lucian yes
15:50 lucian whiteknight: right now i'm boxing PMCs in python objects
15:50 lucian trying to figure out functions and scopes, and pir is proving to be worse than useless
15:52 ambs joined #parrot
15:53 lucian whiteknight: after i get a reasonably correct object model, i could perhaps write PMCs for some of the wrappers upon wrappers that i use now
15:53 whiteknight yeah, once you get the semantics working and have tests, you can start optimizing
15:54 lucian don't know if it'd be a waste of time, 6model and all
15:54 jnthn__ 6model natively groks boxing natives
15:55 jnthn__ A Perl 6 Int is an object that contains space for an INTVAL.
15:56 lucian jnthn__: nice. btw, i'm not using 6model for now
15:56 jnthn__ lucian: ok
15:58 lucian jnthn__: likely mostly my fault, i have to figure out both nqp and 6model, with little docs
15:58 jnthn__ Well, lack of docs ain't your fault.
15:58 lucian :)
15:58 lucian how does 6model handle scoping?
15:59 jnthn__ Scoping in what sense?
15:59 lucian namespaces
15:59 jnthn__ Ah
15:59 jnthn__ Mostly, it tries to stay out of that business.
15:59 jnthn__ Parrot classes and namespaces are very tightly tied. I had not interest in repeating that mistake.
16:00 jnthn__ *no
16:00 lucian i see
16:00 lucian so the language is expected to implement its own?
16:00 jnthn__ If you want to have objects that represent namespaces and chain name lookup through that, s-table has a slot (.WHO, get_who/set_who) you can use for that.
16:01 jnthn__ If you want to use Parrot namespaces, then that's fine, just install your 6model meta-object into a Parrot namespace.
16:01 jnthn__ er, not meta-object
16:01 jnthn__ type object
16:01 jnthn__ Or well
16:01 jnthn__ That's the thing. Different langauges want to install different things. :)
16:01 lucian no, parrot namespaces are unsuitable. perhaps even broken
16:01 lucian yes, i agree
16:01 jnthn__ Yeah, nqp nor Rakudo uses them
16:01 lucian it's just that pir makes it hard to ignore them
16:02 jnthn__ Anyway, 6model tries to solve the objects part of the puzzle.
16:02 jnthn__ The other bits of the compiler toolkit are (meant to) help solve other parts.
16:02 lucian i think i'll have a 'scope' class for now
16:02 jnthn__ And oftne do.
16:02 jnthn__ Yeah
16:02 jnthn__ We have a Stash class in Rakudo.
16:02 lucian yes, as i said earlier, 6model does look very nice, and logical when explained
16:03 jnthn__ In Perl 6, few lookups are actually done through packages. Most of it is lexical lookups.
16:03 lucian it has very odd terminology though, and i guess slightly hostile to python devs :)
16:05 jnthn__ Yeah, I still need that glossary. :)
16:05 lucian :)
16:06 mikehh_ is now known as mikehh
16:07 mikehh opbots, names
16:24 klavs left #parrot
16:27 plobsing joined #parrot
16:43 ligne left #parrot
17:00 dalek parrot/tt2116_2117_1979: 0e120b9 | jkeenan++ | t/ (2 files):
17:00 dalek parrot/tt2116_2117_1979: Apply patch submitted by ligne++. But we still have test failures.
17:00 dalek parrot/tt2116_2117_1979: review: https://github.com/parrot/parrot/commit/0e120b96a8
17:01 kid51 Hmm, what I posted to TT #1979 probably didn't reflect application of patch.
17:02 lucian is there an ordered mapping in parrot?
17:02 lucian like Hash, but ordered
17:06 allison lucian: you pinged?
17:07 allison (a while ago)
17:07 mtk left #parrot
17:07 lucian allison: yes, i was struggling with scopes/namespaces
17:07 allison lucian: ah, yes
17:08 allison lucian: should I read backscroll?
17:08 lucian allison: not necessarily
17:08 lucian allison: at first i thought i could use PIR's, and its lexicals
17:08 lucian but they're totally unsuited, largely because they're not dynamic objects themselves (scopes and lexicals)
17:09 lucian i think it's possible that PIR's lexicals are broken in general
17:09 allison lucian: so Parrot has a Namespace object implementation, sort of a default starting point, but as jnthn has mentioned some languages need more/different features
17:09 lucian allison: are there docs somewhere?
17:09 lucian right now, i'm using a Hash
17:09 lucian well, starting to
17:10 allison well, PIR lexicals don't currently really have scopes smaller than a subroutine, which is a problem
17:10 allison NameSpace inherits from Hash
17:10 allison so, Hash is a fine substitute
17:10 lucian now i have a custom class with a Hash inside
17:10 allison but, there are also some methods that a namespace is expected to support
17:11 allison basically, anything can substitute for a NameSpace, as long as it offers the standard API
17:11 lucian as i'm building this now, namespaces are passed to each block explicitly
17:11 lucian so they're only relevant to python objects
17:12 lucian i'm becoming increasingly disappointed with parrot's Object/Class
17:12 allison that's a fine place to start, but it will break cross-HLL communication
17:12 lucian i've already broken that :)
17:13 allison (which is to say, you don't necessarily need to worry about it for the GSoC project, but we will eventually)
17:13 lucian i can't find a way to correctly implement python types without doing that
17:13 allison lucian: parrot's Object/Class is also a default, but not a one-size fits all solution for all languages
17:13 allison my take on this, is to just go for it
17:14 allison don't worry about fitting in with previous language implementors
17:14 allison just make a really good Python implementation on top of Parrot
17:14 allison (and by "Parrot" I mean the VM, not the stock PMCs)
17:14 lucian allison: yeah, that's sort of what i did so far
17:15 lucian i've ignored everything in order to try to reach correct python object behaviour
17:15 lucian as soon as i get functions and modules working, i can retarget the compiler
17:15 mtk joined #parrot
17:15 lucian it'll run slow, but i don't really mind
17:16 allison Parrot's object model is coming up on a re-think soon, so it'll be good to feed the Python needs into that as well as the Perl 6 needs
17:16 allison slow is a fine place to start
17:16 lucian have you had time to look at the code?
17:17 allison a little, but not as much as I'd like
17:17 allison I'll mark that todo in red so I do it in the next couple of days
17:17 lucian ok. let me know if something seems particularly stupid
17:17 allison still puffin on bitbucket?
17:18 lucian yes. also on github
17:19 lucian whiteknight reminded me the rules asked for github hosting, so i'm pushing to both now
17:20 allison the GSoC rules? or parrot as an org?
17:20 lucian second
17:20 rohit_nsit08 left #parrot
17:20 allison ah, we should be more sensible about that next year
17:20 lucian it's not a big deal, hg-git is very good. bzr has a similar plugin
17:21 allison yeah, makes sense
17:21 lucian now i just do 'hg push' and it pushes to both
17:22 lucian i do pull from bitbucket, but i could pull from the github repo if needed
17:22 allison oh, btw, the PSF board said it was fine to use the PSF license alone
17:22 allison (no need for the full Python stack)
17:23 lucian right. i'd like you to have a look at my LICENSE, i'm not sure it's correct
17:23 lucian i want it dual-licensed PSF and AL2
17:23 allison ok, will do
17:23 allison yeah, that makes sense
17:24 lucian afaik, PSF doesn't require copyright attribution for CPython
17:24 allison compatibility is fine with one or the other, but I understand you like AL2, and PSF is a really good idea
17:24 allison so, doing both makes sense
17:24 * lucian nods
17:25 lucian i do like AL2
17:25 allison by copyright attribution, do you mean putting a notice of copyright in each file?
17:25 lucian uh, copyright assignment
17:25 allison oh, yes, they don't do assignment at all, they do copyright license
17:25 allison so, you keep ownership of the copyright
17:26 lucian yep
17:26 allison just give them permission to distribute it to others
17:26 lucian should i include an explicit license?
17:26 allison (Parrot does the same)
17:26 allison you should sign a PSF contributor agreement
17:26 lucian both AL2 and PSF give them permission to distribute it
17:26 allison yes
17:27 allison actually, we probably don't even need to worry about it til the end of the GSoC project, since you'll be the only contributor for now
17:27 allison I'll take a look at what you've got now, should be fine
17:28 lucian when you have time
17:29 lucian allison: i have seen opportunities where i could, maybe, implement some parrot interfaces
17:29 lucian for interop
17:29 lucian all python objects could implement find_method and get_attr
17:29 lucian and function objects could implement invoke
17:29 allison those would be useful for compatibiltiy, yes
17:30 allison *compatibility
17:30 allison but, again, keep an eye on your overall project time, because those can be added later
17:30 lucian they'd also simplify the output of the compiler
17:31 allison ah, well if they're actually useful in the implementation, then definitely go for it
17:31 lucian yeah, i tried to copy whiteknight's design in rosella/unstable/prototype, but it didn't work so i dropped it
17:32 lucian right now, i do obj.__dict__.__class__['__getattribute__'](obj, attr_name) to get an attribute on an object
17:32 lucian the shorthand is obj.get(attr_name)
17:32 lucian but it could be just obj.attr_name with parrot's get_attr *and* find_method
17:32 zby_home_ joined #parrot
17:32 lucian to support obj.attr_name()
17:33 lucian allison: btw, that first syntax example is semantically correct python :)
17:34 zby_home left #parrot
17:42 allison lucian: yeah, python is totally comfortable with multiple levels of indirection
17:42 allison lucian: so, the first absolutely should work
17:42 allison lucian: the second seems like a reasonable addition in the context of Parrot
17:43 klavs joined #parrot
17:43 lucian allison: the first does, on CPython. although it often gets short-cirtuited by caches
17:46 JimmyZ left #parrot
18:01 kid51 left #parrot
18:01 klavs left #parrot
18:05 preflex left #parrot
18:07 preflex joined #parrot
18:10 bubaflub joined #parrot
18:36 lucian left #parrot
18:37 ligne joined #parrot
18:39 lucian joined #parrot
19:42 klavs joined #parrot
19:45 cotto ~~
19:52 klavs left #parrot
19:56 bubaflub ~
20:05 lucian whiteknight: if you have time, i'd like some help with https://gist.github.com/1009353
20:05 lucian i'm trying to steal your rosella prototype
20:14 theory joined #parrot
20:16 cotto fperrad, ping
20:19 klavs joined #parrot
20:19 cotto aloha, clock?
20:19 aloha cotto: LAX: Sun, 13:19 PDT / CHI: Sun, 15:19 CDT / NYC: Sun, 16:19 EDT / UTC: Sun, 20:19 UTC / LON: Sun, 21:19 BST / BER: Sun, 22:19 CEST / TOK: Mon, 05:19 JST / SYD: Mon, 06:19 EST
20:20 cotto I guess if you're in France and it's Sunday evening, there's no reason to be on #parrot. ;)
20:21 lucian_ joined #parrot
20:22 klavs Which timezone is yours?
20:23 lucian left #parrot
20:23 cotto US Left^H^H^H^HWest coast
20:23 cotto LAX
20:26 klavs Thats why you were online when i fell asleep and still online when i woke up.
20:26 perlite left #parrot
20:27 perlite joined #parrot
20:27 cotto It was an early morning.  I was actually asleep for most of the last 6 hours.
20:29 cotto klavs, btw, I updated the M0 spec t be less ambiguous about the size of an opcode.
20:31 klavs I took a look at m0-prototype. Is m0-asm and interpreter written in perl?
20:31 cotto klavs, yes
20:32 cotto src/m0/perl5/
20:36 klavs Cotto, yes, i saw update. I was about to tell you that there is not any word about how edianness constants look like. Am i still not-annoying? :D
20:36 cotto klavs, definitely
20:38 klavs So what are the plans for m0. when everything works fine, it will be implemented in c?
20:41 cotto klavs, I think the C implementation will be the most commonly used one.
20:43 cotto klavs, what do you mean by your question about endianness?
20:44 lucian_ cotto: i'm also curious about m0 bytecode portability
20:44 cotto lucian_, me too.
20:45 lucian_ is now known as lucian
20:45 lucian oh
20:45 lucian well, i'd say it *must* be portable if it is to be the binary format
20:46 cotto I don't want to make the same mistake that we did with pbc where there are numerous permutations of configuration options that need to be tested, but I also don't want to see poor performance due to endianness conversions.
20:46 klavs In header, there is one byte reserved for edianness. But what is the value when we have little e... And what is the value when we have big e... ?
20:47 lucian cotto: uft8's solution is passable, i guess
20:47 lucian cotto: little endian platforms are dominant now, so defaulting to that might not be too bad
20:48 lucian that's how jvm bytecode does it too, i think
20:48 dalek parrot/m0-spec: e331522 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
20:48 dalek parrot/m0-spec: define how the endianness bit is used
20:48 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/e331522f77
20:48 cotto klavs, what a silly question.  Of course I'd define something that important. ;)
20:48 cotto klavs++
20:51 klavs Isn't it possible to write a relatively simple tool, that transforms m0 bytecode into right edianness for the platform? (to increase runtime speed)
20:51 lucian klavs: parrot could even do that before running it
20:52 klavs Lucian, thats how i ment it.
20:52 lucian i see
20:53 cotto It comes back to the question of whether we expect m0 bytecode to be distributed.
20:53 mj41 joined #parrot
20:53 cotto if we can assume that it'll stay one a machine, it can be highly platform-specific.  If not, it should run wherever parrot runs.
20:54 klavs Thats an open question. I have only worked with little ed..., i do not know the answer for my question ;)
20:54 cotto We'll need to close it before too much more progress on M0 can be made.
20:55 lucian cotto: what else to distribute?
20:59 cotto lucian, generated executables
20:59 bubaflub ping whiteknight
20:59 cotto I'm leaning toward saying that m0b need to be portable.
20:59 bubaflub er, unping whiteknight
20:59 bubaflub ping NotFound
20:59 theory left #parrot
21:03 lucian cotto: like native executables? i think that's a really bad idea
21:04 lucian cotto: no other vm i know of does that, besides maybe llvm
21:04 NotFound bubaflub: pong
21:05 lucian cotto: what would m0b be?
21:05 bubaflub NotFound: in Winxed i'm trying to have a constructor with an optional argument like this: Integer(var init[optional], int has_init[opt_flag]).  The constructor can accept either a string, int, or float.   How do i check which type the var is?  Something like instanceof but for primitives and not classes.
21:06 cotto aloha, m0b?
21:06 aloha cotto: I give up.
21:06 cotto aloha, m0b is M0's binary bytecode format
21:06 aloha cotto: Okay.
21:06 NotFound bubaflub: instanceof should do the work.
21:06 lucian cotto: and M0 is the textual assembly, that gets assembled to m0b?
21:06 bubaflub NotFound: so just if (init instanceof string) should work?
21:06 klavs To be clear, we just need to change the order of bytes for every uint32 'cell' in bytecode to change its edianness?
21:07 cotto lucian, yes
21:07 NotFound bubaflub: instanceof 'String'
21:07 bubaflub NotFound: ah, ok
21:07 cotto lucian, One possibility for M0 should be to use an "interpreter" that, instead of running the m0b file, generates C code from it.
21:07 lucian cotto: hmm. why C code?
21:08 lucian i see portable bytecode much more valuable than C binaries
21:09 cotto lucian, it's portable and easy to convert into an executable
21:09 NotFound A poor man's JIT X-)
21:10 lucian cotto: but why bother converting to an executable?
21:10 cotto 1) because we can 2) more efficient execution
21:10 lucian i don't see the advantage over a traditional vm model
21:10 lucian well 2) is untrue
21:11 lucian for dynamic languages
21:11 cotto possibly so.  It's a ways off from being even experimental.
21:12 NotFound That depends. Functions with long loops involving ints, for example, can have huge speed boosts.
21:13 lucian it might work for statically typed languages running on parrot
21:13 lucian NotFound: all the research i've read shows that all the checks you must do kill performance. JITs beat that, always
21:13 NotFound lucian: in theory, theory and practice are equal...
21:14 lucian NotFound: practice too. jvm, .net, mono, pypy, etc
21:14 lucian all the js engines
21:14 NotFound lucian: I've not yet seen any java or C# application beating anything in speed.
21:14 lucian anyway, portable bytecode would not prevent this
21:15 lucian NotFound: have you seen Java native compilers beat HotSpot consistently? that's what's being compared here
21:15 lucian even java's object system is dynamic enough to show this effect to some degree
21:16 lucian but really, my point is that while compiling to C might be useful, making it the main/only method of execution, in favour of portable bytecode, is a bad idea
21:17 NotFound I think that in the current situation any method of execution that work will be highly useful.
21:17 NotFound (any method faster than interpreting codes with perl, that is)
21:18 lucian yes, but this is method that has been repeatedly shown to have severe limitations for dynamic languages
21:18 lucian so i don't think M0 should be designed primarily for this, at the expense of portable bytecode
21:18 NotFound My personal view is that the original idea was preferable: M0 not intended to live outside a running VM.
21:19 lucian NotFound: and what would be used for distribution?
21:19 NotFound lucian: pbc
21:20 lucian NotFound: what would pbc be in the context of m0?
21:20 lucian m0b?
21:20 NotFound m1, m2, mN where N > 0
21:20 ambs left #parrot
21:20 cotto klavs, have you ever wanted to write a disassembler?
21:21 klavs Cotto, do you have something in mind?
21:21 lucian NotFound: so implement pbc on top of m0?
21:21 cotto klavs, m0b needs one
21:22 cotto NotFound, I don't think the idea of distributing pbc excludes the idea of distributing m0b
21:23 klavs Well, i could try.
21:23 klavs but no perl. I do not know this language, yet.
21:23 cotto klavs, sure.  What languages do you know?
21:24 NotFound cotto: no, but having one method makes less urgent to have the other.
21:24 cotto NotFound, quite true
21:26 klavs C, Go, good old Pascal( but i am not going to write anything in it), Java. I prefer first two.
21:27 cotto klavs, +1 on Pascal (and not writing anything in it)
21:28 cotto klavs, have you not discovered the wonderful and wacky world of interpreted (a.k.a scripting) languages?
21:28 klavs Pascal is weird, some days i love its non-c-style syntax, other days i hate it.
21:29 NotFound klavs: you may want to take a look at winxed.
21:29 cotto btw, did you come here after reading dukeleto's "What is M0?" post on hacker news or from somewhere else/
21:29 cotto ?
21:30 klavs I know how jscript looks like :D i prefer compiled languages. It will take some time to learn scripting.
21:32 NotFound klavs: if you know C and java, winxed should take you almost zero time.
21:32 klavs NotFound, i hate spam.:)
21:33 * tadzik look weirdly at the compiled-scripted languages
21:34 NotFound I find your lack of faith distrubing ;)
21:34 klavs Cotto, no, i came here few days before that. I was playing around with x86 asm and wanted to implement a simple vm, searchin vms, i found parrotvm.
21:36 klavs NotFound, i will take a look at it, but not now, currently i do not want to learn new language.
21:37 lucian klavs: winxed runs on parrot, so it'd be a good choice for a dissasembler
21:38 lucian overall, it's an ok language. given parrot's limitations, it's a great language
21:38 NotFound klavs: It was just a suggestion for the disassembler in case you got interested in that idea.... what lucian says.
21:39 klavs Ok, ok. I will take a look at it soon. :)
21:41 preflex left #parrot
21:41 cotto klavs, are you on github?
21:41 lucian NotFound: quick winxed question: how can i instantiate a class with init[vtable,nsentry] ?
21:41 klavs No. I am not.
21:41 NotFound lucian: new without ()
21:42 lucian NotFound: ah, ok. i'll try that
21:43 NotFound lucian: see t/basic/05new.t
21:43 lucian NotFound: thanks. apparently the problem is elsewhere anyway
21:45 NotFound Not sure in nsentry plays well with init, tough.
21:45 dalek parrot: bf1d54a | cotto++ | config/gen/makefiles/root.in:
21:45 dalek parrot: Merge pull request #136 from ligne/missing_dep
21:45 dalek parrot:
21:45 dalek parrot: missing Makefile dep for osutils.pbc
21:45 dalek parrot: review: https://github.com/parrot/parrot/commit/bf1d54ac6c
21:45 cotto ligne++
21:45 preflex joined #parrot
21:47 klavs left #parrot
21:51 lucian NotFound: it's whiteknight's brainchild i'm playing with, not sure myself what's going on
21:52 NotFound brainchild?
21:52 lucian NotFound: rosella/unstable/prototype
21:52 lucian i'm trying to steal the attribute and method resolution, and calling
21:53 NotFound That methods are my idea, so you can blame me.
21:55 lucian NotFound: i see :(
21:55 lucian s/:(/:)/
21:56 NotFound It's a tricky business, it took me some attempts to achieve something that doesn't infinite recurse.
21:57 lucian yeah, i either have that problem, or it crashes
21:57 lucian NotFound: what i have so far https://gist.github.com/1009353
21:58 lucian i'd rather not use Rosella's alloc()
21:58 bubaflub left #parrot
21:59 fperrad left #parrot
22:00 fperrad joined #parrot
22:00 NotFound Looking...
22:01 lucian thanks. if you have time
22:14 fperrad_ joined #parrot
22:14 fperrad left #parrot
22:14 fperrad_ is now known as fperrad
22:18 NotFound lucian: The problem is in init
22:19 NotFound You need something like ${ setattribute self, protoclass, '__dict__', {} }; instead of self.__dict__ = {};
22:19 mj41 left #parrot
22:19 lucian NotFound: oh, that i'm refereincing self.dict
22:19 NotFound I told you it was tricky ;)
22:19 lucian yes, it is
22:19 lucian i'm spoilt by python's short-circuits
22:20 lucian (__dict__ is always just fetched, regardless of defined getters/setters)
22:20 NotFound We are overriding get/set attributes so we must be extra-careful with anything that access atributes.
22:22 lucian NotFound: yay, it works!
22:23 lucian thanks a lot for the help
22:23 NotFound Nothin'
22:24 NotFound In cases like this winxed can fool you: it looks like something higher level but you are tweaking with low level pmc machinery.
22:25 NotFound But in pir it was a lot more confusing one time I tried %-)
22:27 lucian yeah, it is a bit odd
22:27 lucian anyway, as soon as i figure out methods, i won't need to bother with this code
22:28 NotFound It's odd, but is the only way I've been able to bypass the undesired effects of method cache.
22:30 PacoLinux left #parrot
22:47 lucian NotFound: in the meantime, i think i figured out how write everything in python beyond the object system
22:48 NotFound lucian: good
22:48 lucian NotFound: something equivalent to winxed's ${ }
22:49 lucian since python's functions are objects, than inherit from a class, i could expose the 'function' object, so one could do function.__new__(function, code), where 'code' is pir
22:49 lucian more precisely, a sub
22:49 NotFound Looks good
22:50 NotFound And you can even write the sub with winxed ;)
22:50 ligne left #parrot
22:50 lucian yes, why not. could have a flag for that
22:50 lucian as soon as i boostrap the object system :)
22:50 lucian i have functions, namespaces and metaclasses to do
22:53 cotto allison, ping
23:03 NotFound lucian: looking at that code, you don't need to always use the protoclass var, you can use class Python.instance directly inside the pirop.
23:06 lucian NotFound: yeah, that works
23:07 lucian thanks
23:07 lucian NotFound: would you be willing to give me a second helping hand? :)
23:08 NotFound lucian: sure
23:09 lucian NotFound: https://bitbucket.org/lucian1900/puffin/​src/a352f537a542/objects/instance.winxed
23:09 lucian i can't figure out what's wrong in find_method
23:10 lucian apparently obj.__dict__ is evaluated to null
23:13 NotFound lucian: you need to put __dict__ into itself, of provide a shortcircuit,
23:13 lucian NotFound: ah, of course. silly me
23:13 NotFound This works: var dict = {}; dict['__dict__'] = dict; ${ setattribute self, class instance, '__dict__', dict };
23:13 NotFound On iit
23:13 NotFound init
23:14 lucian NotFound: and it works! thanks, master wizard
23:14 NotFound Thanks, young padawan ;)
23:14 lucian so now everything should just work. well, after i rewrite all of it :)
23:16 NotFound I'm glad to see my experiments with pseudo-metaclasses being useful :)
23:17 lucian yes, quite
23:18 lucian all this helped turn the syntax from int.__class__.__dict__['__ge​tattribute__']('__new__')(2) into int.__new__(2)
23:18 jsut_ joined #parrot
23:20 NotFound Just remeber that is only syntax, the runtime cost will still be noticeable.
23:20 zby_home_ left #parrot
23:21 lucian NotFound: yes, i realise
23:21 lucian but the syntax is the interface to the object system
23:22 lucian if i can keep the syntax ok, the object system can be fixed more easily later
23:22 lucian NotFound: hmm, it appears this experiment breaks constructors. or i'm doing something wrong again :)
23:23 jsut left #parrot
23:24 NotFound Constructors?
23:24 lucian class instance { function instance() }
23:25 lucian apparently i need to make the constructors with __dict__
23:25 lucian or add short-cirtuits
23:25 NotFound Yes, winxed constructors are plain methods, so if you change method search...
23:25 lucian yes, exactly
23:25 lucian i think i'll make python's object system even more circular now
23:25 lucian i'll just make instance a python metaclass :)
23:26 whiteknight I ran into that problem *a lot* in rosella. For places where I wanted initialization behavior but needed to override find_method in a transparent way
23:26 NotFound Well, maybe even python can eventually learn something from this.
23:27 whiteknight the solution I found most often was to use a separate factory object for initialization behavior and the 4-argument form of setattr
23:28 lucian NotFound: yes, CPython has much more written in C than it has to. PyPy changes this for the better, i guess
23:28 lucian whiteknight: yes, i think i'll do that as well
23:28 jsut joined #parrot
23:28 lucian i think i'll have factory functions for creating the first python types
23:29 lucian and then use 'object' and 'type' as factories for everything else
23:29 whiteknight this is one of the reasons why I would like to have an object model that supports constructors-which-are-not-methods
23:29 * lucian nods
23:29 lucian although if the object model you're implementing has metaclasses (as is my case), the issue is a lot smaller
23:31 lucian but still present
23:31 lucian for example, exceptions are a tad complicated
23:32 NotFound whiteknight: I thought about using an anonymous function in the namespace of the class, but the problem is how to look for it from child classes in different source files.
23:32 whiteknight right
23:33 whiteknight this just isn't something that PIR handles very well
23:33 whiteknight we need better object model support for it
23:33 jsut_ left #parrot
23:34 NotFound There are old parrot docs that mentions having a property called BUILD or something like that in the class object, but looks like that idea never was implemented.
23:35 lucian whiteknight: i think i'd like a declarative way of implementing an object model
23:35 whiteknight lucian: sure, but as it stands PIR just plain doesn't support that
23:35 lucian yes, i realise that
23:35 whiteknight and there are not many good ways to make it support the necessary operations, as is
23:36 whiteknight doing even simple things, like pretending to have private attributes, requires severe hacking
23:37 lucian hmm. wouldn't that work with just a second namespace?
23:38 whiteknight like a second class? Foo and Foo.__private?
23:38 NotFound Attributes live in the class, not in its associated namespace.
23:38 lucian whiteknight: an instance of NameSpace in that Foo.__private, yes
23:39 whiteknight what rosella Proxy library does currently is to prefix attributes with something obnoxious and uncommon, like "!!!Rosella.Proxy!!!"
23:39 lucian NotFound: sure, but private ones could be hacked into a namespace
23:39 whiteknight and then anything with that in the attribute name is treated as private
23:39 lucian whiteknight: there's a cool and stupid trick one can do in CPython, which is non-string attributes
23:39 whiteknight ah, that would be nice too. The attribute hash in Object PMC uses string keys though
23:40 lucian i know
23:40 whiteknight Parrot hashes can use any type of key, but the ones in Object use strings
23:40 lucian it's actually a point where i'll diverge from CPython behaviour
23:40 lucian i don't really care, no one in their right mind uses non-string attrs in python
23:41 NotFound lucian: You mean using a Namespace object instead of a Hash? You want even more headaches? ;)
23:44 lucian NotFound: heh
23:44 lucian btw, i have another question: how can i call the init_pmc vtable method?
23:48 allison cotto: pong
23:49 NotFound lucian: If I've not fooled myself, the new [ ] variant will do it.
23:50 lucian NotFound: and how can i pass a sub to it with that syntax?
23:50 cotto allison, ouch.  just heading out the door
23:51 cotto allison, the more I think about M0 calling conventions, the more it makes sense to do all the setup/teardown on the caller side.  Do you know where I'd find some academic work on the subject so I understand the tradeoffs I'm making?
23:51 NotFound lucian: haven't tested after the last changes, probably just by name will work,
23:51 cotto allison, part of the difficulty is that it'll be hard for the callee to build its call frame while the caller's call frame is still active without having the callee clobber something important in the caller's call frame.
23:51 cotto If the caller is responsible for building the callee's call frame, the caller can more easily keep some registers free to build/initialize the callee's call frame.
23:51 NotFound lucian: if not, declaring it with using.
23:51 lucian NotFound: so new [instance](sub) ?
23:51 cotto allison, will have to backscroll later.
23:52 NotFound lucian: ['instance'] or ['Python', 'instance']
23:52 lucian right. i'll try
23:53 allison cotto: that's a longer answer anyway, so will take a note and get back to you later
23:54 NotFound I think I should add a modifier or something to do that with the more usual new syntax.
23:56 soh_cah_toa joined #parrot
23:56 lucian NotFound: hmm. new ['Python', 'instance']( function() {} ); doesn't work, "can't find get_iter in class Sub"
23:56 plobsing left #parrot
23:57 NotFound This is a serious candidate for the most misleading error message prize.
23:57 lucian ah, but it is calling init_pmc
23:57 NotFound Ah... yes... this is yet another serious problem of parrot object model.
23:57 lucian exact message is "get_iter() not implemented in class 'Sub'"
23:58 NotFound init_pmc in Object always looks for a hash to initialize attributes,
23:58 lucian really? lame
23:58 lucian i guess i'll just do without invoke, not a big deal
23:58 NotFound Well, not init_pmc itself, but instantiate before calling it.

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

Parrot | source cross referenced