Camelia, the Perl 6 bug

IRC log for #parrot, 2011-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:01 lucian NotFound: i think i'll just avoid it, i only really need invoke. python objects that are callable have the attribute __call__
00:01 NotFound Sometimes winxed amazes myself, never though about passing an anonymous functions to init_pmc.
00:02 NotFound lucian: better, the ways to bypass init_pmc limitations are tricky.
00:04 lucian NotFound: yeah, works with __call__
00:04 lucian thanks a lot for all the help. whiteknight and allison too
00:05 lucian and whoever else i pestered :)
00:05 NotFound A pleasure, I'm happy seeing winxed used creatively.
00:07 lucian NotFound: i think i've also found a way to boostrap it quickly :)
00:07 lucian now, __call__ and __new__ and other special methods are attributes pointing to winxed subs
00:08 lucian after i boostrap all the way to python functions, i can replace those attributes in the metaobject
00:08 NotFound Sounds good.
00:09 lucian i'll see if it actually works after i refactor all this to use your methhod
00:10 NotFound It may be tricked to debug, but seems doable.
00:15 lucian yeah, it does seem so
00:17 NotFound Too late for me now, 'night.
00:18 lucian NotFound: good night
00:27 kid51 joined #parrot
00:40 bubaflub joined #parrot
00:47 spinclad left #parrot
00:55 ligne joined #parrot
00:56 mtk left #parrot
00:56 lucian left #parrot
00:57 fperrad left #parrot
00:58 spinclad joined #parrot
01:01 mtk joined #parrot
01:35 whiteknight left #parrot
02:13 dalek parrot: 1e12c83 | soh_cah_toa++ | src/gc/api.c:
02:13 dalek parrot: Noticed a few missing =cut tags
02:13 dalek parrot: review: https://github.com/parrot/parrot/commit/1e12c83fdc
02:13 dalek parrot: ff82af6 | soh_cah_toa++ | / (5 files):
02:13 dalek parrot: Merge branch 'master' of git://github.com/parrot/parrot
02:13 dalek parrot: review: https://github.com/parrot/parrot/commit/ff82af60bd
02:14 soh_cah_toa i have no idea what that second one is... :/
02:15 soh_cah_toa i had to do a 'git pull' first and that's when it appeared in the log
02:15 soh_cah_toa i hope that's normal
02:16 atrodo joined #parrot
02:17 kid51 A couple of the changes in the "Merge branch 'master'..." were made by me yesterday.
02:17 kid51 Did you start out your work in 'master' today by saying 'git pull'?
02:18 soh_cah_toa i made my changes first, then push failed, then pulled, then re-pushed
02:18 soh_cah_toa i'm guessing i did it backwards
02:18 bacek_at_work soh_cah_toa, use "git pull --rebase"
02:18 bacek_at_work or (better) put it into .git/config
02:19 soh_cah_toa yeah, everything is up to date
02:19 bacek_at_work soh_cah_toa, "git config branch.master.autorebase always"
02:20 kid51 Whatever VCS you're working in, and whether you're working in master/trunk or branch, it's always a good idea to start out your workday with a pull (IMHO).
02:20 bacek_at_work soh_cah_toa, and "git config branch.master.rebase true"
02:20 kid51 soh_cah_toa: BTW: Have you added an entry for yourself to CREDITS?
02:20 soh_cah_toa you're right. i'm so used to not having to pull anything on my hbdb branch, that's why
02:21 soh_cah_toa kid51: i should do that now
02:21 soh_cah_toa bacek_at_work: i'm guessing that auto-rebases before a commit?
02:21 bacek_at_work soh_cah_toa, before push actually
02:21 bacek_at_work all your commits before pushing are belong to you :)
02:21 soh_cah_toa right
02:22 bacek_at_work soh_cah_toa, I'm usually do a lot of small commits and then rebase them to bigger logical commits before pushing.
02:22 bacek_at_work But it's kind of "advanced git usage" :)
02:22 bacek_at_work afk # lunch
02:22 soh_cah_toa alright, i'll add that to my config file but i didn't break anything did i?
02:23 soh_cah_toa i know merges can be dangerous
02:25 kid51 No, you did not break anything.
02:25 soh_cah_toa good
02:46 dalek parrot: 5efef65 | soh_cah_toa++ | CREDITS:
02:46 dalek parrot: Giving credit where credit is due
02:46 dalek parrot: review: https://github.com/parrot/parrot/commit/5efef65239
02:47 plobsing joined #parrot
02:53 cotto ~~
02:54 bubaflub plobsing: ping
02:55 cotto allison, are you free for that longer answer?
03:00 plobsing bubaflub: pong
03:00 bubaflub plobsing: got a moment to answer some questions about your Winxed ZeroMQ bindings?
03:00 plobsing go ahead
03:00 kid51 left #parrot
03:03 bubaflub plobsing: so with the deprecation of 't' NCI signatures should use 'p' for strings, right?  in your bindings i notice you've got stoa and atos functions that handle changing Parrot strings into C strings and vice versa.
03:03 plobsing bubaflub: that is correct
03:03 bubaflub plobsing:  so when i want to call a C function that takes a char * i want to call that with stoa(string)
03:04 bubaflub plobsing: and when an NCI function returns a C string i want to return atos(string)
03:04 plobsing bubaflub: yes that would be correct
03:04 bubaflub plobsing: great, thanks.
03:05 plobsing I mean, you can get a little more efficient if the string is guarranteed constant by the C library, and you might have to free the cstring otherwise, but in general that should work.
03:08 bubaflub plobsing: ok.  most of the string stuff is just for either constructing a GMP Integer from a string or string-ifying a GMP Integer
03:09 plobsing the question remains "who frees?" when you get a string returned.
03:25 bubaflub plobsing: how do i explicitly free a var in Winxed?  set it to null?  once i've constructed an INT from a string i can immediately free it, right?
03:29 plobsing no, that will only work for GCed values
03:30 plobsing you need to call (likely via NCI) whatever function the called library specifies for cleanup
03:34 bubaflub plobsing: ok, so i imagine just as there are parrot functions to create cstrings there are parrot functions to free them, right?
03:36 hudnix left #parrot
03:50 bubaflub left #parrot
04:33 soh_cah_toa left #parrot
04:57 particle joined #parrot
04:59 particle1 left #parrot
05:11 particle1 joined #parrot
05:13 particle left #parrot
05:54 dalek parrot/m0-prototype: b293c0a | cotto++ | / (2 files):
05:54 dalek parrot/m0-prototype: add all m0 tests to m0_test, minor text fix
05:54 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/b293c0a2a9
05:54 dalek parrot/m0-prototype: 799bdbf | cotto++ | / (3 files):
05:54 dalek parrot/m0-prototype: add new test (actually a calling conventions brain dump) and a new op
05:54 dalek parrot/m0-prototype:
05:55 dalek parrot/m0-prototype: The new file isn't even remotely valid code yet, so it's blacklisted
05:55 dalek parrot/m0-prototype: from the integration test until it works.  The new op will probably be
05:55 dalek parrot/m0-prototype: permanent, but I don't want to update the spec until there's a
05:55 dalek parrot/m0-prototype: demonstration that what's there can fully implement calling conventions.
05:55 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/799bdbf0bb
05:55 cotto time for sleep
05:59 dalek parrot: 97afcb2 | petdance++ | / (3 files):
05:59 dalek parrot: fix a splint annotation
05:59 dalek parrot: review: https://github.com/parrot/parrot/commit/97afcb25bb
05:59 dalek parrot: f1ebca1 | petdance++ | src/string/api.c:
05:59 dalek parrot: localized a local variable into the inner block
05:59 dalek parrot: review: https://github.com/parrot/parrot/commit/f1ebca1d9e
06:19 Drossel joined #parrot
06:19 Kulag left #parrot
06:55 fperrad joined #parrot
07:12 mj41 joined #parrot
08:42 ligne left #parrot
08:42 mtk left #parrot
08:49 mtk joined #parrot
09:05 klavs joined #parrot
09:20 klavs left #parrot
09:20 ligne joined #parrot
09:20 dalek left #parrot
09:26 dalek joined #parrot
09:54 dalek nqp: 2aa210a | moritz++ | / (2 files):
09:54 dalek nqp: fix and test _ in integer literals
09:54 dalek nqp: review: https://github.com/perl6/nqp/commit/2aa210a467
10:29 mj41 left #parrot
10:31 ambs joined #parrot
10:46 unStatiK joined #parrot
10:48 klavs joined #parrot
10:56 mj41 joined #parrot
11:06 contingencyplan left #parrot
11:27 lucian joined #parrot
11:28 klavs left #parrot
11:45 ambs left #parrot
11:55 dalek nqp: 3fc9a23 | jonathan++ | src/ops/nqp.ops:
11:55 dalek nqp: Soften type_check a little in the face of non-6model types. Unbreaks colonpair logic in Rakudo's Actions.pm.
11:55 dalek nqp: review: https://github.com/perl6/nqp/commit/3fc9a236db
11:57 ambs joined #parrot
12:12 whiteknight joined #parrot
12:16 mtk left #parrot
12:18 whiteknight good morning, #parrot
12:21 lucian 'morning
12:26 whiteknight hello lucian. How are you doing today?
12:27 lucian whiteknight: fine. tweaking the object system
12:27 lucian broke all of my tests, because of better syntax :)
12:28 whiteknight ah, fun
12:28 whiteknight that's the one big downside to testing, that I have seen in practice: If you test too closely too early, things break when you inevitable refactor
12:28 whiteknight no methodology is perfect
12:28 mtk joined #parrot
12:32 bubaflub joined #parrot
12:33 lucian whiteknight: yeah
12:33 lucian whiteknight: not a big deal, just takes some time
12:33 lucian i'm quite satisfied with my rosella/prototype-inspired Python.instance
12:35 lucian whiteknight: i even have overrides for the overrides :)
12:35 lucian that is, it normally it gets things from __dict__
12:36 lucian if __dict__['__getattribute__'] is defined, it uses that instead
12:36 lucian so i can boostrap my way up
12:38 whiteknight awesome
12:38 whiteknight Yeah, the Rosella techniques are not universally-applicable, but it serves as good example code
12:38 whiteknight well, good examples of bad hacks around bad problems in parrot
12:39 whiteknight I think that averages out to a net negative :)
12:39 lucian now i have to figure out a way to implement types with native contens (like int)
12:39 lucian whiteknight: heh
12:49 whiteknight one thing that I really admire about Parrot is that it does so much with so little. The project has been so hamstrung by old systems like the object model, and yet it's still an interesting and even useful platform
12:49 whiteknight If we can really fix up some of those old systems, I suspect Parrot can become a pretty cool VM
12:50 atrodo I appreciate the fact that it depends on so very little.  The trend these days seem to favor the opposite
12:51 whiteknight yes. At the beginning of my involvement of the project I was more worried about the Not Invented Here syndrom, but I start to see it as being more of a benefit
12:51 whiteknight it's easier to get Parrot working on a system with fewer dependencies
12:54 lucian whiteknight: i'm still worried about NIH
12:54 lucian it does do much with little, but it could do a lot more with a few dependencies
12:55 whiteknight no argument. We currently have a philosophy of making external libraries optional
12:55 whiteknight for some things, like ICU, not having it is a pretty big problem and makes Parrot unusable with Rakudo for instance
12:56 lucian and it'd be unusable with python, too
12:56 whiteknight Right
12:56 whiteknight so there's an argument that maybe ICU should be a required dependency
12:56 whiteknight When we pick a solution for implementing locks and some other concurrency primitives, maybe that will want to be a requirement as well
12:56 lucian i don't think there's a serious language out there not requiring unicode
12:58 jnthn__ whiteknight: Back in the good old days, ICU wasn't an external dependency.
12:58 whiteknight jnthn__: yes, that's true
12:58 jnthn__ I wish it'd never been ripped out
12:58 jnthn__ I've never figured out how to get it to work on Win32 since.
12:58 whiteknight jnthn__: what was the argument for that, licensing issues?
12:58 jnthn__ whiteknight: No idea.
12:59 whiteknight well, it's a decision that really needs to be reconsidered
12:59 whiteknight ICU is fundamental, and our fallbacks when it's not available are less than awesome
13:01 lucian whiteknight: that's the thing, i think even having fallbacks for something so basic is a waste of resources
13:01 whiteknight it's negligible, but yeah
13:02 lucian perhaps, but many similar cases can add up
13:03 whiteknight no argument
13:04 lucian hmm. how could i add content to objects that isn't visible to the dict? ideally subclassing Integer i guess
13:05 lucian hmm. i think the set opcodes would replace the PMC, not just its boxed value
13:10 whiteknight assign does that
13:10 whiteknight sort of
13:10 lucian hmm, it does appear to. i'll have to test that
13:16 particle joined #parrot
13:19 particle1 left #parrot
13:20 klavs joined #parrot
13:21 lucian do [optional] args default to null?
13:26 lucian left #parrot
13:27 lucian joined #parrot
13:27 bubaflub lucian: for [optional] arguments i have something like this:
13:27 bubaflub var init[optional], int has_init[opt_flag]
13:27 bubaflub then later in the function you can check if(has_init)
13:27 bubaflub that way you never access an optional flag if it's not set
13:28 lucian i see. that looks quite odd
13:30 lucian bubaflub: thanks, i'll try that
13:32 benabik Good morning, #parrot
13:34 JimmyZ joined #parrot
13:44 whiteknight lucian: yes, pmc and string [optional] arguments default to null
13:44 whiteknight int and floats default to 0
13:44 lucian whiteknight: ok, thanks
13:45 whiteknight I usually test the opt_flag parameter instead of relying on null, because it avoids the semi-predicate problem if null is a valid answer
13:45 whiteknight but your use-case might be different
13:48 theory joined #parrot
13:53 klavs left #parrot
13:54 PacoLinux joined #parrot
13:55 lucian left #parrot
13:55 * Coke_ waves from Philly.
13:56 * benabik waves in Coke_'s general direction.
13:56 benabik Coke_: Welcome to my time zone.  :-)
13:58 lucian joined #parrot
14:01 theory left #parrot
14:01 lucian hmm, i keep getting nulls when trying to reference a function in namespace in another file
14:02 lucian Python.type is a function; using Python.type; type == null -> true
14:03 plobsing left #parrot
14:09 whiteknight weird
14:09 whiteknight is that other file being loaded?
14:09 PacoLinux left #parrot
14:09 whiteknight and is it being loaded before the code you're executing?
14:10 lucian whiteknight: yep
14:10 PacoLinux joined #parrot
14:10 hudnix joined #parrot
14:10 whiteknight well, fudge.
14:11 whiteknight are the two files in the same .HLL namespace?
14:12 lucian uh. no. but that's never stopped me before
14:13 lucian whiteknight: i have other tests that reference classes inside the .HLL namespace that still work
14:13 lucian so i can do new Python.type if type is a class
14:14 lucian but can't do Python.type() if type is just a function
14:14 autark left #parrot
14:15 autark joined #parrot
14:18 NotFound lucian: if Python is a namespace HLL in a source file but the other doesn't know it, "using" will look for it in the wrong place.
14:19 lucian NotFound: hmm. then why does it work for classes, but not functions
14:20 NotFound lucian: using falls back to get_hll_global
14:22 lucian NotFound: so how can i reference that function?
14:24 whiteknight "using MAGIC"
14:24 NotFound I must do some tests. As I told you, the hll modifier is highly experimental.
14:24 whiteknight no, sorry, "using static MAGIC"
14:25 NotFound In the meantime you can use get_root_global via pirops.
14:28 NotFound Uh... not so easy because of the keys....
14:28 jsut_ joined #parrot
14:29 lucian NotFound: i see. so should i just put my tests in the same namespace?
14:29 lucian whiteknight: MAGIC being?
14:29 whiteknight lucian: that's probably prudent to do for now
14:29 whiteknight lucian: MAGIC being a bad joke
14:29 lucian ah, ok :)
14:30 NotFound lucian: yes, for a now that will be the cleaner way.
14:31 NotFound I'm too object oriented, so I worried about declaring external classes before external functions ;)
14:31 whiteknight NotFound.ObjectOrientation​.WorryMoreAboutFunctions()
14:32 NotFound Well, in fact functions just worked in most cases... because they weren't in other HLLs.
14:32 lucian NotFound: heh. i'm even more object oriented and all my functions are objects! :)
14:33 jsut left #parrot
14:33 NotFound But not classes, an to get objects you'll need global vars.
14:34 NotFound Well, I think it's time to add another tweak, a builtin or operator to get namespaces.
14:36 lucian hmm, it doesn't appear to be able to find that function, even in the same namespace
14:37 NotFound lucian: Don't forget the hll modifier.
14:37 lucian didn't
14:38 NotFound And drop the 'Python.' part in the 'using'
14:40 Coke_ benabik - I'm pretty sure I'm always in this time zone.
14:41 lucian NotFound: hmm, back to the initial issue. the functions are null
14:41 lucian bah
14:41 benabik Coke_: I thought you lived farther west.  Ah, well.
14:41 Coke_ just a little southwest of my usual location.
14:41 lucian NotFound: should i just drop the [HLL] modifiers everywhere?
14:41 NotFound lucian: let me do some tests....
14:42 cotto ~~
14:45 lucian NotFound: this is what i have so far https://bitbucket.org/lucian1900/puffin/s​rc/b758c1501b7c/objects/test_type.winxed
14:45 Coke_ ~
14:45 lucian NotFound: in boot(), i try to call type and object. but type == null
14:48 NotFound I think I've found the problem. namespace X [HLL] generates both an .HLL declaration and a parrot namespace.
14:48 NotFound .HLL 'X'  |  .namespace [ 'X ]
14:48 lucian i see. so the function is looked up in the empty namespace?
14:49 lucian but the class in the .hll ?
14:49 NotFound The function lives in Python.Python but is searched in Python
14:49 lucian right
14:49 lucian but the class lives in Python, where it should
14:52 NotFound So the contrary, you nee using Python
14:52 NotFound So the contrary, you nee using Python.type inside namespace Python [HLL]
14:53 lucian right. let me try
14:53 lucian and could i do using Python.Python.type from outside?
14:53 NotFound I need to redo that mess, but later, doing it now risk to break your work.
14:54 NotFound lucian: no, because it doesn't know that the first Python is an hll.
14:54 lucian ah, ok
14:54 lucian well, i'm not particularly dependent on [HLL]
14:54 lucian i could just remove it from everywhere and use just namespaces
14:55 NotFound I have a better idea: let HLL as is, and start working in a new modifier, HLLNS or something like that, that does The Right Thing.
14:56 whiteknight do the right thing? novel.
14:56 NotFound "Better" as in "less confusing to me"
14:56 lucian NotFound: so change all my [HLL] to [HLLNS] ?
14:56 NotFound lucian: yes, but later, when it gets ready and tested.
14:57 NotFound Or stop using HLL in the meantime, if you prefer.
14:58 lucian NotFound: yeah, i think i'll stop using it
14:58 JimmyZ nopaste?
14:58 lucian i'm not yet to the point where i could have name clashes with another language
15:02 NotFound aloha: nopaste?
15:02 aloha NotFound: nopaste is is http://nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl)
15:02 whiteknight left #parrot
15:16 dmalcolm joined #parrot
15:45 cotto_work ~~
15:53 jevin joined #parrot
15:56 klavs joined #parrot
16:30 mtk left #parrot
16:30 davidfetter joined #parrot
16:37 pjcj_ joined #parrot
16:37 mtk joined #parrot
16:42 pjcj left #parrot
16:42 pjcj_ is now known as pjcj
16:46 mj41 left #parrot
16:52 scooter_de joined #parrot
16:53 lucian left #parrot
16:57 JimmyZ left #parrot
16:58 whiteknight joined #parrot
16:59 lucian joined #parrot
17:06 lucian_ joined #parrot
17:06 lucian_ left #parrot
17:08 lucian left #parrot
17:08 lucian joined #parrot
17:10 jsut joined #parrot
17:15 jsut_ left #parrot
17:28 dukeleto joined #parrot
17:29 dukeleto ~~
17:30 * dukeleto is about to invoke the return continuation back to PDX
17:34 bubaflub hola dukeleto
17:37 dukeleto bubaflub: werd
17:37 dukeleto bubaflub: got any questions? I am about to hop on a plane
17:37 bubaflub dukeleto: nadda.  just hanging out.  i'm still working on getting strings and NCI to play nice but it shouldn't take long before i get it to work.
17:39 cotto_work dukeleto: happy flying
17:39 cotto_work also, make sure you're getting on a plane, not a plain.
17:39 cotto_work happens all the time
17:40 * dukeleto verifies his plane is just a plain plane
17:40 atrodo sometimes, i accidentally get on a plan. That's embarrassing
17:40 * dukeleto heads out
18:11 scooter_de left #parrot
18:35 mj41 joined #parrot
18:47 fperrad left #parrot
19:11 theory joined #parrot
19:11 contingencyplan joined #parrot
19:16 theory left #parrot
19:25 allison cotto_work/dukeleto: have time today or this evening to chat about caller/callee setup
19:25 allison cotto_work: looking for papers for you
19:26 allison cotto_work: I'm sure there's some good more recent stuff than what Dan, then Chip, and then I reviewed in the earlier refactors
19:27 theory joined #parrot
19:47 soh_cah_toa joined #parrot
19:49 soh_cah_toa ~~
19:49 klavs left #parrot
19:57 lucian how can i get find_method to not pass 'self' to the method it returns?
19:57 lucian in fact, i think it's parrot that does that
19:57 whiteknight lucian: what do you mean?
19:57 lucian whiteknight: my find_method just returns the sub at that attribute
19:58 whiteknight okay, so what do you want it to do instead?
19:58 lucian whiteknight: but if i try to do bla.meth(a, b), i get an error about it having 3 arguments passed, but expecting two
19:58 whiteknight don't methods in Python take self?
19:59 lucian yes, they do. but it's explicit, and happens differently
19:59 whiteknight ah, okay.
19:59 Tene lucian: "happens diffeerently"?
19:59 whiteknight let me gist you up an example
19:59 lucian Tene: with descritors. object.method(a, b) -> Class.method.__get__(Class, object)
20:00 lucian Tene: that's how methods get bound
20:00 lucian whiteknight: i think i might have to do var sub = bla.meth; meth(a, b);
20:00 Tene lucian: those aren't the same thing.  the latter looks like the first half of the former.
20:00 whiteknight https://gist.github.com/1010969
20:00 Tene you get the method, and then what do you do with it?
20:01 lucian Tene: let me find a link
20:01 whiteknight lucian: Object PMC caches the results of find_method. You can move the search for "f" into the closure to bypass the method cache
20:01 lucian whiteknight: bah, so that's how it worked. thanks
20:02 Tene lucian: method defintions even have 'self' as the first parameter in the argument list
20:02 whiteknight lucian: yeah, it's not pretty but it works
20:02 lucian Tene: http://www.cafepy.com/article/python​_attributes_and_methods/ch01s02.html
20:03 Tene lucian: your 'meth' method would be defined likethis, right? : def meth(self, a, b):
20:03 lucian Tene: yes, and in the class it's the same: Class.meth(obj, a, b)
20:03 Tene lucian: so... that's three arguments, right?
20:03 lucian Tene: yes. but if you call it from an object, a descriptor is invoked
20:03 Tene so why does it expect 2 instead of 3?
20:04 lucian Tene: it expects to receive three, but you send two through the bound method
20:04 lucian Tene: have a look at that link
20:05 * whiteknight goes crosseyed
20:05 Tene lucian: I see.
20:05 Tene whiteknight: instances get a shim installed
20:05 lucian Tene: uh, roughly
20:06 Tene lucian: in that case, you should NOT be using the callmethod op, or whatever; you should be calling it like a function, because that's what it is.
20:07 whiteknight yeah, parrot has two ops for invoking: invokecc and callmethodcc. Method syntax in PIR becomes the former
20:07 whiteknight er, the later
20:07 lucian Tene: i am calling it like a function, i haven't implemented descriptors yet
20:07 lucian whiteknight: hmm, and winxed probably uses callmethodcc and messes up my arguments
20:07 whiteknight for method-looking syntax in winxed, yes
20:08 * lucian is sad
20:08 whiteknight just don't use the "." operator to invoke methods
20:08 whiteknight do something more like "var m = find_method(obj, 'bar'); m(<args>)"
20:08 whiteknight (find_method is a builtin)
20:09 whiteknight it will still go through the find_method vtable so you can override that to search for attributes
20:09 Tene lucian: "descriptors"?
20:09 Tene lucian: I hav eno idea what you're using for codegen.
20:09 lucian Tene: any object in python can implement __get__ or __set__ to modify how it's get/set
20:09 lucian Tene: functions implement __get__ in order to return a bound method
20:09 lucian Tene: my compiler is just python
20:10 Tene lucian: right, but what are you generating?
20:10 NotFound If you make find_method return something different than parrot uses, you'll confuse parrot.
20:10 lucian Tene: pir
20:10 Tene lucian: and are you generating things that look like PIR method calls?
20:10 whiteknight Notfound: what do you mean? I override find_method pretty frequently to return weird invokables, and nothing bad happens
20:10 Tene PIR method calsl *mean* "pass the invocant as the first argument"
20:10 klavs joined #parrot
20:10 NotFound whiteknight: there are degress of weirdness.
20:11 whiteknight Notfound: example?
20:11 lucian Tene: my codegen doesn't use the object system yet, the latter isn't ready
20:11 NotFound whiteknight: it you return something that doesn't expect the object as first argument, fail.
20:11 Tene lucian: can you show me an example of what the generated pir looks like for a python method call?
20:11 lucian Tene: don't have one, as i said i'm still working on the object system
20:11 lucian Tene: i'm using it from python
20:12 lucian s/from python/from winxed/
20:12 whiteknight Notfound: okay, right. You have to return something that looks like a method
20:12 whiteknight ...if you want to use Parrot's method-calling mechanisms
20:12 Tene lucian: oh, okay.  In that case, don't use winxed method calls, because those mean something else.
20:12 lucian Tene: yes, sadly
20:12 NotFound If you don't want, better don't use the find_method vtable,
20:13 whiteknight the way I showed in that gist is probably the most versatile
20:13 lucian i'd have expected parrot's objects to allow overriding the method calling
20:13 lucian apparently only method finding can be overriden
20:13 Tene lucian: however, you could make it work anyway by making your bound method shims accept an invocant and ignore it.
20:14 whiteknight lucian: through find_method and invoke vtables, it does. It depends how far down the rabbit hole you're willing to tumble
20:14 lucian Tene: can't do that, it would break python's descriptors
20:15 NotFound lucian: What is a bound method? Something that has the function and the object?
20:15 Tene lucian: alternately, you could have find_method return something that fetches from the descriptor and redispatches
20:15 lucian NotFound: yes, pretty much
20:15 lucian i think i'll just remove find_method right now
20:17 NotFound lucian: if you are not going to use parrot calling conventions for method, the tricks in find_method are just a waste of cycles.
20:17 Tene lucian: as we discussed quite a while back, since python methods are just attributes, you probably shouldn't be pretending they are anything other than attributes.
20:18 NotFound You can add them later if you want interoperability, but for own usages better provide own ways.
20:18 Tene obj.meth(); is the same as tmp = obj.meth; tmp();
20:18 Tene you can't do that with parrot methods
20:18 lucian Tene: yes, parrot's broken :(
20:18 NotFound Tene: yes we can... with ugly tricks.
20:18 whiteknight not broken, just a different definition of what a "method" is
20:18 Tene lucian: I don't think I agree with you that parrot is broken for providing something else that you can use if you want.
20:19 whiteknight we use the word to describe one type of thing, which is not the same type of thing that a python "method" is
20:19 lucian whiteknight: if it can't be overriden to support a different language, it's broken
20:19 Tene I certainly think that parrot has some big problems, but I wouldn't consider that one of them.
20:19 whiteknight lucian: it's a different type of thing
20:19 Tene lucian: Parrot does have support for what you want; attributes.
20:19 benabik If you call obj.meth() in python, you don't get obj as a parameter?
20:19 lucian right, but it'll kill interop
20:19 Tene You also can't implement python methods with the garbage collector; does that mean the gc is broken?
20:20 lucian benabik: yes you do, read the link :)
20:20 Tene lucian: no, it won't, not at all.
20:20 whiteknight lucian: you can always override the invoke vtable, pull out the object there, set up descriptors, and redispatch
20:20 Tene lucian: however the other language accesses attributes, you do that instead with python objects.
20:20 lucian Tene: other languages will expect find_method to be implemented, won't they?
20:20 whiteknight or do something similar in the find_method call, returning a closure with lots of logic
20:21 Tene lucian: only if they want to call methods on it; if the object doesn't *have* any methods defined, then why would they be doing that?
20:21 Tene Your find_method should always fail with "no such method", Ie xpect
20:21 benabik lucian: obj.meth returns a function that semi-magically passes obj as the first parameter?
20:21 Tene benabik: it's a closure, really
20:21 lucian bacek_at_work: uh, somewhat. it's not magical at all, an explicit protocol (descriptors)
20:22 Tene sub build_shim($obj,$name) { my $meth = find_method($obj,$name); return sub { $meth->($obj, @_) } }
20:23 Tene like that
20:23 Tene *handwave* kinda
20:23 benabik It sounds like PIR would do about the right thing, actually...  It's just that if a Python program used find_method it would get very confused.
20:23 NotFound lucian: just provide the way to create the bound method and call it, and I'll write you a working find_method if you want.
20:24 Tene lucian: I don't think it would be *Wrong* for find_method to return something that does that for you, but it wouldn't necessarily do what python expects in some edge cases.
20:24 dalek nqp: c9a6dba | jonathan++ | / (4 files):
20:24 dalek nqp: Add an Uninstantiable representation, whihc is useful for types that you can't instantiate.
20:24 dalek nqp: review: https://github.com/perl6/nqp/commit/c9a6dbaa14
20:24 Tene if you saved a method, and then changed the method in the class, the saved reference wouldn't necessarily do the right thing
20:24 lucian NotFound: yeah, i'll look at it later
20:25 Tene but, it's certainly possible and reasonable.
20:25 lucian i suppose i'm a little disillusioned
20:25 NotFound Tene: python shouldn't expect nothing in particular from find_method because it's a parrot vtable, doesn't live in the python universe.
20:27 whiteknight we all need to be taking notes. When the time comes to overhaul the parrot object model, we want to get it right
20:27 whiteknight or, less wrong
20:27 lucian NotFound: sure, but it'd help if it was more configurable
20:27 theory left #parrot
20:27 lucian whiteknight: from what i've seen of 6model, it appears to get this particular bit right
20:28 NotFound lucian: we are using tricks to make it more configurable, but even with that, it should return what is expected.
20:28 whiteknight lucian: I'm leaving here in a minute, but if you have a few moments to write up exactly how you think find_method should be improved, or how we can do it in a way that makes python happy, I would love to read it
20:28 lucian whiteknight: i'll think about it, yes
20:28 Tene sub find_method($obj,$name) { return sub { my $inv = @_.shift; my $meth = find_bound_method($inv,$name); $meth->(@_); } } -- you could do this
20:28 whiteknight a big part of the problem is the PIR sugar syntax for method calls hides the fact that we are doing a find_method and an invoke one after the other
20:29 lucian Tene: if i'm reading that right, it's what NotFound/whiteknight's option does
20:29 whiteknight without the PIR sugar syntax, the user would be writing those ops out explicitly, and could use invokecc instead of callmethodcc
20:29 lucian whiteknight: yes, that would help
20:29 whiteknight and in summary: kill PIR with a hammer
20:30 NotFound lucian: yeah, that's what I told you. First provide the way to create the bound method.
20:30 Tene whiteknight: we can already do exactly that by not using method syntax, fwiw
20:30 benabik It feels to me that other HLLs would find it very unexpected that callmethodcc wouldn't work on a Python object.
20:30 Tene lucian: dunno; I haven't been following this quite closely enough; lots happening at work
20:30 lucian NotFound: indeed, it'll take a while though. there are dependencies
20:30 whiteknight and on that note, /me leaves
20:30 whiteknight left #parrot
20:31 Tene benabik: why would you be surprised that you can't call a method on something without that method?
20:31 NotFound benabik: it will work, using the appropiate tricks.
20:31 Tene benabik: python doesn't have methods in the same sense that other languages do; just attributes.
20:31 lucian benabik: Tene: python has something that does look like methods
20:31 lucian bound functions is a more appropriate name
20:31 Tene benabik: foo.bar is attribute access, always, every time; it doesn't do anything different in cases where foo happens to have a closure in bar
20:31 benabik Tene: I guess it depends on how transparent you want Python objects to be outside Pythong.
20:31 Tene lucian: exactly
20:32 NotFound From a parctical point of view, a method is just something that you can all with the appropiate syntax.
20:32 Tene NotFound: in python, some attributes happen to be invocable; if you know which those are and want to invoke them, you can do that.
20:33 cotto_work allison: cool
20:33 NotFound Tene: and that is fine por pyhton but if you want something to ba passed around that works as a parrot object, you shlould provide a way to use parrot method call ways.
20:33 benabik Tene: It feels to me that it would be nice if find_method/callmethodcc would work on Python objects.  That doesn't have to be what Python things do internally, but it would help interop.
20:33 dalek left #parrot
20:34 Tene benabik: It would be *nice*, sure, but it wouldn't be wrong to not do it.
20:34 benabik Tene: It sounds like find_method is wholly inappropriate for Python internally anyway.
20:34 NotFound If you don't want, you just don't need to document such "methods" in the usage from parrot docs.
20:34 Tene NotFound: those objects would work perfectly fine as a parrot object; it just happens to be of a type with no methods defined.
20:35 NotFound Tene: perfectly fine but unusable.
20:35 * lucian brb
20:35 lucian left #parrot
20:36 Tene benabik: find_method is only useful to a python implementation in as much as you want to provide a way for parrot methods to call python attributes, which is a reasonable interop utility, sure, but not necessary for the base object model
20:37 dalek joined #parrot
20:37 Tene NotFound: So if I define a class to hold some data, and I don't have any methods for that class, instances of that class are unusable?  I don't follow, and feel like I'm missing something you're trying to say.
20:37 benabik Tene: Yes, that's what I'm saying.  find_method is only useful for outside things to call into Python, whereas python internally uses just attribute lookup.
20:37 NotFound Now we are talking the same language.
20:38 lucian joined #parrot
20:38 NotFound Tene: if you have a pythin thing with python methods and supposed interoperability, not being able to "parrotcalling" the methods will be a strange interoperability.
20:39 lucian NotFound: i think what Tene means is that semantics are very different and shoehorning them in others isn't always possible
20:39 lucian for example, scheme objects wouldn't have methods either
20:40 Tene lucian +1
20:40 NotFound All is possible. I think the discussions is about providing convenient interfaces.
20:40 lucian but then again, bound functions are similar to functions
20:40 Tene You *can* have a convenience find_method that tries to fudge the semantics, but that's not how python works.
20:42 NotFound Tene: and that was I was telling: provide the pythonic way first, then we'll worry about find_method.
20:42 Tene NotFound: Yes, agreed.
20:42 benabik It really sounds like there's a lot of violent agreement here.
20:42 * lucian nods. that's what i'm doing
20:42 NotFound benabik: just a clarification of concepts and words.
20:43 benabik NotFound: Right.
20:43 benabik Is there a get_attribute vtable?
20:43 Tene benabik: Yes.
20:44 benabik It sounds like it would DTRT if `get_attribute obj, "meth"` returned a bound function and `find_method obj, "meth"` returned an unbound one.  Yes, getting the unbound function is weird for Python, but python wouldn't be trying to do things that way anyway.
20:45 NotFound benabik: is a bit more complicated, but we already have tricks developed.
20:45 Tene benabik: No, that wouldn't work, because individual objects and classes can override the lookup and return a different function instead
20:45 benabik NotFound: Fair enough.
20:45 benabik Tene: Trying to use find_method on one object to call them on another sounds a bit like insanity.
20:46 Tene benabik: I don't understand.
20:46 benabik Tene: $P0 = find_method a, "meth"; b.$P0()
20:47 Tene benabik: that wasn't the use case that I was talking about...
20:47 lucian Tene: actually, even individual attributes can override what they return
20:53 benabik Tene: OIC.  You're saying that obj.meth might not be returning a bound method at all.  It might just be a normal function.
20:53 benabik Tene: So find_method wouldn't DTRT in that case.
20:54 unStatiK left #parrot
20:56 jsut_ joined #parrot
20:56 NotFound Not so hard. find_emthod just needs a way to ask the python attribute for the unbound method, and throw something when is not possible to get such thing.
20:57 klavs Yesterday (yesterday in my timezone) cotto asked me if i want to write a disassambler for m0. i said i will try. Here we go: https//github.com/klavs/dm0
20:57 lucian NotFound: yes, not too hard after i get it done
20:57 benabik Eh.  find_method does some variety of magic so interop works
20:57 NotFound I think that in the most common cases, it will be able to return something appropiate.
20:59 NotFound benabik: yes, and we use some counter-magic to make it work in a different way.
20:59 cotto_work klavs: that was fast.  looking now
20:59 cotto_work klavs++
21:00 NotFound Or meta-magic, maybe.
21:00 klavs Cotto, it needs to be improved, but bot today.
21:00 cotto_work klavs: sure.  The first version is usually rough around the edges.
21:01 jsut left #parrot
21:02 NotFound klavs: What language you finally decided to use?
21:02 cotto_work It doesn't look too bad for something written in less than 24 hours.
21:02 cotto_work NotFound: C
21:02 cotto_work https://github.com/klavs/dm0/blob/master/dm0.c
21:03 NotFound Looks good in a quick view.
21:03 cotto_work looks like it doesn't deal with labels yet, but that's a meaningful chunk of additional complexity.
21:04 * NotFound was expecting Aspect Oriented Cobol with closures and XML
21:04 cotto_work i.e. spitting out goto foo instead of goto x, x, x
21:05 klavs Cotto, thats right. That was not in today's plans.
21:07 klavs NotFound, i took a look at Winxed. I thougt, that it will be too much for this day to learn it in depth.
21:08 klavs There is no syntactic sugar for registers, too.
21:08 NotFound klavs: it's pretty easy, but just one day may be too short, yes.
21:19 ambs left #parrot
21:38 lucian hmm, i'm wondering about exceptions
21:55 TiMBuS left #parrot
21:55 TiMBuS joined #parrot
22:11 dukeleto ~~
22:12 dukeleto klavs: nice m0 disassembler! that was fast.
22:16 klavs Dukeleto, thanks, i found some bugs, and commented the code. Tomorrow i will continue.
22:17 dukeleto klavs: awesome! have you considered writing some tests?
22:18 klavs Dukeleto, i think i should do it.
22:19 mj41 left #parrot
22:21 cotto_work klavs: have you thought about how you'd write the tests?  All of Parrot's tests are written in (or center around) perl.
22:22 klavs Cotto, thats funny, i just realised that.
22:24 klavs No tests from me for a while. Perl looks too strange to me.
22:25 cotto_work klavs: that's fine.  We can hack something up in the m0-prototype branch.  Once one or two tests have been written, I think it'll be relatively easy for you (or others) to add more.
22:28 klavs cotto, then it is fine for me too
22:36 cotto_work klavs: what part of the world are you from?
22:36 kid51 joined #parrot
22:37 klavs Europe, easter europe, Latvia
22:37 cotto_work klavs: nice.  YAPC::EU is happening in Riga.
22:37 klavs Eastern not easter
22:38 cotto_work I'll be talking about Parrot there.
22:39 klavs Interesting, i have never heard about it.
22:39 klavs Not about Parrot, but... You get it.
22:39 cotto_work klavs: it's an excellent dev-organized Perl conference.
22:40 cotto_work highly recommended if you think you might be interested in learning Perl.
22:41 klavs Cotto, everything is possible.
22:42 cotto_work It's a great language if you learn from the right source.
22:42 kid51 aloha, YAPC Europe?
22:42 aloha kid51: Sorry, I don't know.
22:42 kid51 aloha, YAPC::EU::2011 is http://yapceurope.lv/ye2011/
22:42 aloha kid51: Okay.
22:43 kid51 aloha, YAPC Europe is http://yapceurope.lv/ye2011/
22:43 aloha kid51: Okay.
22:43 kid51 aloha, YAPC Europe?
22:43 aloha kid51: YAPC Europe is http://yapceurope.lv/ye2011/
22:45 klavs Cotto, i have no doubts about it. I think i will try perl someday.
22:46 jsut joined #parrot
22:49 cotto_work klavs: cool.  When you do, I recommend http://www.onyxneon.com/bo​oks/modern_perl/index.html (note that the download is free).
22:51 jsut_ left #parrot
22:52 klavs Cotto, thanks.
22:54 * lucian has shivers running down his spine
22:55 cotto_work lucian: good ones or bad ones?
22:55 lucian cotto_work: you know my opinion of perl :)
22:57 lucian it's late, good night everyone!
22:57 lucian left #parrot
23:21 klavs left #parrot
23:34 dalek parrot/m0-spec: 6a5c064 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
23:34 dalek parrot/m0-spec: add the beginnings of a description of M0 calling conventions
23:34 dalek parrot/m0-spec: review: https://github.com/parrot/parrot/commit/6a5c064027
23:34 davidfetter left #parrot
23:36 benabik Does the following just result in two PMC registers pointing to the same object?  `.local pmc outersym, symtable ; outersym = getattribute self, '%!symtable' ; symtable = outersym`

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

Parrot | source cross referenced