Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
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.
lucian: better, the ways to bypass init_pmc limitations are tricky. 00:02
lucian NotFound: yeah, works with __call__ 00:04
thanks a lot for all the help. whiteknight and allison too
and whoever else i pestered :) 00:05
NotFound A pleasure, I'm happy seeing winxed used creatively.
lucian NotFound: i think i've also found a way to boostrap it quickly :) 00:07
now, __call__ and __new__ and other special methods are attributes pointing to winxed subs
after i boostrap all the way to python functions, i can replace those attributes in the metaobject 00:08
NotFound Sounds good.
lucian i'll see if it actually works after i refactor all this to use your methhod 00:09
NotFound It may be tricked to debug, but seems doable. 00:10
lucian yeah, it does seem so 00:15
NotFound Too late for me now, 'night. 00:17
lucian NotFound: good night 00:18
00:27 kid51 joined 00:40 bubaflub joined 00:47 spinclad left 00:55 ligne joined 00:56 mtk left, lucian left 00:57 fperrad left 00:58 spinclad joined 01:01 mtk joined 01:35 whiteknight left
dalek rrot: 1e12c83 | soh_cah_toa++ | src/gc/api.c:
Noticed a few missing =cut tags
 02:13
rrot: ff82af6 | soh_cah_toa++ | / (5 files):
Merge branch 'master' of git://github.com/parrot/parrot
soh_cah_toa i have no idea what that second one is... :/ 02:14
i had to do a 'git pull' first and that's when it appeared in the log 02:15
i hope that's normal
02:16 atrodo joined
kid51 A couple of the changes in the "Merge branch 'master'..." were made by me yesterday. 02:17
Did you start out your work in 'master' today by saying 'git pull'?
soh_cah_toa i made my changes first, then push failed, then pulled, then re-pushed 02:18
i'm guessing i did it backwards
bacek_at_work soh_cah_toa, use "git pull --rebase"
or (better) put it into .git/config
soh_cah_toa yeah, everything is up to date 02:19
bacek_at_work soh_cah_toa, "git config branch.master.autorebase always"
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"
kid51 soh_cah_toa: BTW: Have you added an entry for yourself to CREDITS?
soh_cah_toa you're right. i'm so used to not having to pull anything on my hbdb branch, that's why
kid51: i should do that now 02:21
bacek_at_work: i'm guessing that auto-rebases before a commit?
bacek_at_work soh_cah_toa, before push actually
all your commits before pushing are belong to you :)
soh_cah_toa right
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
But it's kind of "advanced git usage" :)
afk # lunch
soh_cah_toa alright, i'll add that to my config file but i didn't break anything did i?
i know merges can be dangerous 02:23
kid51 No, you did not break anything. 02:25
soh_cah_toa good
dalek rrot: 5efef65 | soh_cah_toa++ | CREDITS:
Giving credit where credit is due
 02:46
02:47 plobsing joined
cotto ~~ 02:53
bubaflub plobsing: ping 02:54
cotto allison, are you free for that longer answer? 02:55
plobsing bubaflub: pong 03:00
bubaflub plobsing: got a moment to answer some questions about your Winxed ZeroMQ bindings?
plobsing go ahead
03:00 kid51 left
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
bubaflub plobsing: so when i want to call a C function that takes a char * i want to call that with stoa(string)
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
bubaflub plobsing: great, thanks.
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:05
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:08
plobsing the question remains "who frees?" when you get a string returned. 03:09
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:25
plobsing no, that will only work for GCed values 03:29
you need to call (likely via NCI) whatever function the called library specifies for cleanup 03:30
bubaflub plobsing: ok, so i imagine just as there are parrot functions to create cstrings there are parrot functions to free them, right? 03:34
03:36 hudnix left 03:50 bubaflub left 04:33 soh_cah_toa left 04:57 particle joined 04:59 particle1 left 05:11 particle1 joined 05:13 particle left
dalek rrot/m0-prototype: b293c0a | cotto++ | / (2 files):
add all m0 tests to m0_test, minor text fix
 05:54
rrot/m0-prototype: 799bdbf | cotto++ | / (3 files):
add new test (actually a calling conventions brain dump) and a new op

The new file isn't even remotely valid code yet, so it's blacklisted from the integration test until it works. The new op will probably be permanent, but I don't want to update the spec until there's a demonstration that what's there can fully implement calling conventions.
cotto time for sleep
dalek rrot: 97afcb2 | petdance++ | / (3 files):
fix a splint annotation
 05:59
rrot: f1ebca1 | petdance++ | src/string/api.c:
localized a local variable into the inner block
06:19 Drossel joined, Kulag left 06:55 fperrad joined 07:12 mj41 joined 08:42 ligne left, mtk left 08:49 mtk joined 09:05 klavs joined 09:20 klavs left, ligne joined, dalek left 09:26 dalek joined
dalek p: 2aa210a | moritz++ | / (2 files):
fix and test _ in integer literals
 09:54
10:29 mj41 left 10:31 ambs joined 10:46 unStatiK joined 10:48 klavs joined 10:56 mj41 joined 11:06 contingencyplan left 11:27 lucian joined 11:28 klavs left 11:45 ambs left
dalek p: 3fc9a23 | jonathan++ | src/ops/nqp.ops:
Soften type_check a little in the face of non-6model types. Unbreaks colonpair logic in Rakudo's Actions.pm.
 11:55
11:57 ambs joined 12:12 whiteknight joined 12:16 mtk left
whiteknight good morning, #parrot 12:18
lucian 'morning 12:21
whiteknight hello lucian. How are you doing today? 12:26
lucian whiteknight: fine. tweaking the object system 12:27
broke all of my tests, because of better syntax :)
whiteknight ah, fun 12:28
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
no methodology is perfect
12:28 mtk joined 12:32 bubaflub joined
lucian whiteknight: yeah 12:33
whiteknight: not a big deal, just takes some time
i'm quite satisfied with my rosella/prototype-inspired Python.instance
whiteknight: i even have overrides for the overrides :) 12:35
that is, it normally it gets things from __dict__
if __dict__['__getattribute__'] is defined, it uses that instead 12:36
so i can boostrap my way up
whiteknight awesome 12:38
Yeah, the Rosella techniques are not universally-applicable, but it serves as good example code
well, good examples of bad hacks around bad problems in parrot
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)
whiteknight: heh
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
If we can really fix up some of those old systems, I suspect Parrot can become a pretty cool VM
atrodo I appreciate the fact that it depends on so very little. The trend these days seem to favor the opposite 12:50
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
it's easier to get Parrot working on a system with fewer dependencies
lucian whiteknight: i'm still worried about NIH 12:54
it does do much with little, but it could do a lot more with a few dependencies
whiteknight no argument. We currently have a philosophy of making external libraries optional 12:55
for some things, like ICU, not having it is a pretty big problem and makes Parrot unusable with Rakudo for instance
lucian and it'd be unusable with python, too 12:56
whiteknight Right
so there's an argument that maybe ICU should be a required dependency
When we pick a solution for implementing locks and some other concurrency primitives, maybe that will want to be a requirement as well
lucian i don't think there's a serious language out there not requiring unicode
jnthn__ whiteknight: Back in the good old days, ICU wasn't an external dependency. 12:58
whiteknight jnthn__: yes, that's true
jnthn__ I wish it'd never been ripped out
I've never figured out how to get it to work on Win32 since.
whiteknight jnthn__: what was the argument for that, licensing issues?
jnthn__ whiteknight: No idea.
whiteknight well, it's a decision that really needs to be reconsidered 12:59
ICU is fundamental, and our fallbacks when it's not available are less than awesome
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
lucian perhaps, but many similar cases can add up 13:02
whiteknight no argument 13:03
lucian hmm. how could i add content to objects that isn't visible to the dict? ideally subclassing Integer i guess 13:04
hmm. i think the set opcodes would replace the PMC, not just its boxed value 13:05
whiteknight assign does that 13:10
sort of
lucian hmm, it does appear to. i'll have to test that
13:16 particle joined 13:19 particle1 left 13:20 klavs joined
lucian do [optional] args default to null? 13:21
13:26 lucian left 13:27 lucian joined
bubaflub lucian: for [optional] arguments i have something like this: 13:27
var init[optional], int has_init[opt_flag]
then later in the function you can check if(has_init)
that way you never access an optional flag if it's not set
lucian i see. that looks quite odd 13:28
bubaflub: thanks, i'll try that 13:30
benabik Good morning, #parrot 13:32
13:34 JimmyZ joined
whiteknight lucian: yes, pmc and string [optional] arguments default to null 13:44
int and floats default to 0
lucian whiteknight: ok, thanks
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
but your use-case might be different
13:48 theory joined 13:53 klavs left 13:54 PacoLinux joined 13:55 lucian left
Coke_ waves from Philly. 13:55
benabik waves in Coke_'s general direction. 13:56
Coke_: Welcome to my time zone. :-)
13:58 lucian joined 14:01 theory left
lucian hmm, i keep getting nulls when trying to reference a function in namespace in another file 14:01
Python.type is a function; using Python.type; type == null -> true 14:02
14:03 plobsing left
whiteknight weird 14:09
is that other file being loaded?
14:09 PacoLinux left
whiteknight and is it being loaded before the code you're executing? 14:09
lucian whiteknight: yep 14:10
14:10 PacoLinux joined, hudnix joined
whiteknight well, fudge. 14:10
are the two files in the same .HLL namespace? 14:11
lucian uh. no. but that's never stopped me before 14:12
whiteknight: i have other tests that reference classes inside the .HLL namespace that still work 14:13
so i can do new Python.type if type is a class
but can't do Python.type() if type is just a function 14:14
14:14 autark left 14:15 autark joined
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:18
lucian NotFound: hmm. then why does it work for classes, but not functions 14:19
NotFound lucian: using falls back to get_hll_global 14:20
lucian NotFound: so how can i reference that function? 14:22
whiteknight "using MAGIC" 14:24
NotFound I must do some tests. As I told you, the hll modifier is highly experimental.
whiteknight no, sorry, "using static MAGIC"
NotFound In the meantime you can use get_root_global via pirops. 14:25
Uh... not so easy because of the keys.... 14:28
14:28 jsut_ joined
lucian NotFound: i see. so should i just put my tests in the same namespace? 14:29
whiteknight: MAGIC being?
whiteknight lucian: that's probably prudent to do for now
lucian: MAGIC being a bad joke
lucian ah, ok :)
NotFound lucian: yes, for a now that will be the cleaner way. 14:30
I'm too object oriented, so I worried about declaring external classes before external functions ;) 14:31
whiteknight NotFound.ObjectOrientation.WorryMoreAboutFunctions()
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
NotFound But not classes, an to get objects you'll need global vars. 14:33
Well, I think it's time to add another tweak, a builtin or operator to get namespaces. 14:34
lucian hmm, it doesn't appear to be able to find that function, even in the same namespace 14:36
NotFound lucian: Don't forget the hll modifier. 14:37
lucian didn't
NotFound And drop the 'Python.' part in the 'using' 14:38
Coke_ benabik - I'm pretty sure I'm always in this time zone. 14:40
lucian NotFound: hmm, back to the initial issue. the functions are null 14:41
bah
benabik Coke_: I thought you lived farther west. Ah, well.
Coke_ just a little southwest of my usual location.
lucian NotFound: should i just drop the [HLL] modifiers everywhere?
NotFound lucian: let me do some tests....
cotto ~~ 14:42
lucian NotFound: this is what i have so far bitbucket.org/lucian1900/puffin/sr...ype.winxed 14:45
Coke_ ~
lucian NotFound: in boot(), i try to call type and object. but type == null
NotFound I think I've found the problem. namespace X [HLL] generates both an .HLL declaration and a parrot namespace. 14:48
.HLL 'X' | .namespace [ 'X ]
lucian i see. so the function is looked up in the empty namespace?
but the class in the .hll ? 14:49
NotFound The function lives in Python.Python but is searched in Python
lucian right
but the class lives in Python, where it should
NotFound So the contrary, you nee using Python 14:52
So the contrary, you nee using Python.type inside namespace Python [HLL]
lucian right. let me try 14:53
and could i do using Python.Python.type from outside?
NotFound I need to redo that mess, but later, doing it now risk to break your work.
lucian: no, because it doesn't know that the first Python is an hll. 14:54
lucian ah, ok
well, i'm not particularly dependent on [HLL]
i could just remove it from everywhere and use just namespaces
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:55
whiteknight do the right thing? novel. 14:56
NotFound "Better" as in "less confusing to me"
lucian NotFound: so change all my [HLL] to [HLLNS] ?
NotFound lucian: yes, but later, when it gets ready and tested.
Or stop using HLL in the meantime, if you prefer. 14:57
lucian NotFound: yeah, i think i'll stop using it 14:58
JimmyZ nopaste?
lucian i'm not yet to the point where i could have name clashes with another language
NotFound aloha: nopaste? 15:02
aloha NotFound: nopaste is is nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl)
15:02 whiteknight left 15:16 dmalcolm joined
cotto_work ~~ 15:45
15:53 jevin joined 15:56 klavs joined 16:30 mtk left, davidfetter joined 16:37 pjcj_ joined, mtk joined 16:42 pjcj left, pjcj_ is now known as pjcj 16:46 mj41 left 16:52 scooter_de joined 16:53 lucian left 16:57 JimmyZ left 16:58 whiteknight joined 16:59 lucian joined 17:06 lucian_ joined, lucian_ left 17:08 lucian left, lucian joined 17:10 jsut joined 17:15 jsut_ left 17:28 dukeleto joined
dukeleto ~~ 17:29
dukeleto is about to invoke the return continuation back to PDX 17:30
bubaflub hola dukeleto 17:34
dukeleto bubaflub: werd 17:37
bubaflub: got any questions? I am about to hop on a plane
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.
cotto_work dukeleto: happy flying 17:39
also, make sure you're getting on a plane, not a plain.
happens all the time
dukeleto verifies his plane is just a plain plane 17:40
atrodo sometimes, i accidentally get on a plan. That's embarrassing
dukeleto heads out
18:11 scooter_de left 18:35 mj41 joined 18:47 fperrad left 19:11 theory joined, contingencyplan joined 19:16 theory left
allison cotto_work/dukeleto: have time today or this evening to chat about caller/callee setup 19:25
cotto_work: looking for papers for you
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:26
19:27 theory joined 19:47 soh_cah_toa joined
soh_cah_toa ~~ 19:49
19:49 klavs left
lucian how can i get find_method to not pass 'self' to the method it returns? 19:57
in fact, i think it's parrot that does that
whiteknight lucian: what do you mean?
lucian whiteknight: my find_method just returns the sub at that attribute
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
whiteknight don't methods in Python take self?
lucian yes, they do. but it's explicit, and happens differently 19:59
whiteknight ah, okay.
Tene lucian: "happens diffeerently"?
whiteknight let me gist you up an example
lucian Tene: with descritors. object.method(a, b) -> Class.method.__get__(Class, object)
Tene: that's how methods get bound 20:00
whiteknight: i think i might have to do var sub = bla.meth; meth(a, b);
Tene lucian: those aren't the same thing. the latter looks like the first half of the former.
whiteknight gist.github.com/1010969
Tene you get the method, and then what do you do with it?
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
lucian whiteknight: bah, so that's how it worked. thanks
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
lucian Tene: www.cafepy.com/article/python_attri...01s02.html
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)
Tene lucian: so... that's three arguments, right?
lucian Tene: yes. but if you call it from an object, a descriptor is invoked
Tene so why does it expect 2 instead of 3?
lucian Tene: it expects to receive three, but you send two through the bound method 20:04
Tene: have a look at that link
whiteknight goes crosseyed 20:05
Tene lucian: I see.
whiteknight: instances get a shim installed
lucian Tene: uh, roughly
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:06
whiteknight yeah, parrot has two ops for invoking: invokecc and callmethodcc. Method syntax in PIR becomes the former 20:07
er, the later
lucian Tene: i am calling it like a function, i haven't implemented descriptors yet
whiteknight: hmm, and winxed probably uses callmethodcc and messes up my arguments
whiteknight for method-looking syntax in winxed, yes
lucian is sad 20:08
whiteknight just don't use the "." operator to invoke methods
do something more like "var m = find_method(obj, 'bar'); m(<args>)"
(find_method is a builtin)
it will still go through the find_method vtable so you can override that to search for attributes 20:09
Tene lucian: "descriptors"?
lucian: I hav eno idea what you're using for codegen.
lucian Tene: any object in python can implement __get__ or __set__ to modify how it's get/set
Tene: functions implement __get__ in order to return a bound method
Tene: my compiler is just python
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.
lucian Tene: pir
Tene lucian: and are you generating things that look like PIR method calls?
whiteknight Notfound: what do you mean? I override find_method pretty frequently to return weird invokables, and nothing bad happens
Tene PIR method calsl *mean* "pass the invocant as the first argument"
20:10 klavs joined
NotFound whiteknight: there are degress of weirdness. 20:10
whiteknight Notfound: example? 20:11
lucian Tene: my codegen doesn't use the object system yet, the latter isn't ready
NotFound whiteknight: it you return something that doesn't expect the object as first argument, fail.
Tene lucian: can you show me an example of what the generated pir looks like for a python method call?
lucian Tene: don't have one, as i said i'm still working on the object system
Tene: i'm using it from python
s/from python/from winxed/ 20:12
whiteknight Notfound: okay, right. You have to return something that looks like a method
...if you want to use Parrot's method-calling mechanisms
Tene lucian: oh, okay. In that case, don't use winxed method calls, because those mean something else.
lucian Tene: yes, sadly
NotFound If you don't want, better don't use the find_method vtable,
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
apparently only method finding can be overriden
Tene lucian: however, you could make it work anyway by making your bound method shims accept an invocant and ignore it.
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
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
lucian NotFound: yes, pretty much
i think i'll just remove find_method right now
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.
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();
you can't do that with parrot methods
lucian Tene: yes, parrot's broken :(
NotFound Tene: yes we can... with ugly tricks.
whiteknight not broken, just a different definition of what a "method" is
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.
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
Tene I certainly think that parrot has some big problems, but I wouldn't consider that one of them.
whiteknight lucian: it's a different type of thing
Tene lucian: Parrot does have support for what you want; attributes.
benabik If you call obj.meth() in python, you don't get obj as a parameter?
lucian right, but it'll kill interop
Tene You also can't implement python methods with the garbage collector; does that mean the gc is broken?
lucian benabik: yes you do, read the link :) 20:20
Tene lucian: no, it won't, not at all.
whiteknight lucian: you can always override the invoke vtable, pull out the object there, set up descriptors, and redispatch
Tene lucian: however the other language accesses attributes, you do that instead with python objects.
lucian Tene: other languages will expect find_method to be implemented, won't they?
whiteknight or do something similar in the find_method call, returning a closure with lots of logic
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
Your find_method should always fail with "no such method", Ie xpect
benabik lucian: obj.meth returns a function that semi-magically passes obj as the first parameter?
Tene benabik: it's a closure, really
lucian bacek_at_work: uh, somewhat. it's not magical at all, an explicit protocol (descriptors)
Tene sub build_shim($obj,$name) { my $meth = find_method($obj,$name); return sub { $meth->($obj, @_) } } 20:22
like that 20:23
*handwave* kinda
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.
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.
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 p: c9a6dba | jonathan++ | / (4 files):
Add an Uninstantiable representation, whihc is useful for types that you can't instantiate.
Tene if you saved a method, and then changed the method in the class, the saved reference wouldn't necessarily do the right thing
lucian NotFound: yeah, i'll look at it later
Tene but, it's certainly possible and reasonable. 20:25
lucian i suppose i'm a little disillusioned
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.
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
or, less wrong
lucian NotFound: sure, but it'd help if it was more configurable
20:27 theory left
lucian whiteknight: from what i've seen of 6model, it appears to get this particular bit right 20:27
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
lucian whiteknight: i'll think about it, yes
Tene sub find_method($obj,$name) { return sub { my $inv = @_.shift; my $meth = find_bound_method($inv,$name); $meth->(@_); } } -- you could do this
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
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
lucian whiteknight: yes, that would help
whiteknight and in summary: kill PIR with a hammer
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
benabik It feels to me that other HLLs would find it very unexpected that callmethodcc wouldn't work on a Python object.
Tene lucian: dunno; I haven't been following this quite closely enough; lots happening at work
lucian NotFound: indeed, it'll take a while though. there are dependencies
whiteknight and on that note, /me leaves
20:30 whiteknight left
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.
Tene benabik: python doesn't have methods in the same sense that other languages do; just attributes.
lucian benabik: Tene: python has something that does look like methods
bound functions is a more appropriate name
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
benabik Tene: I guess it depends on how transparent you want Python objects to be outside Pythong.
Tene lucian: exactly
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.
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.
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
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.
NotFound If you don't want, you just don't need to document such "methods" in the usage from parrot docs.
Tene NotFound: those objects would work perfectly fine as a parrot object; it just happens to be of a type with no methods defined.
NotFound Tene: perfectly fine but unusable. 20:35
lucian brb
20:35 lucian left
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:36
20:37 dalek joined
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.
NotFound Now we are talking the same language.
20:38 lucian joined
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:38
lucian NotFound: i think what Tene means is that semantics are very different and shoehorning them in others isn't always possible 20:39
for example, scheme objects wouldn't have methods either
Tene lucian +1 20:40
NotFound All is possible. I think the discussions is about providing convenient interfaces.
lucian but then again, bound functions are similar to functions
Tene You *can* have a convenience find_method that tries to fudge the semantics, but that's not how python works.
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.
benabik It really sounds like there's a lot of violent agreement here.
lucian nods. that's what i'm doing
NotFound benabik: just a clarification of concepts and words.
benabik NotFound: Right. 20:43
Is there a get_attribute vtable?
Tene benabik: Yes.
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:44
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
benabik NotFound: Fair enough.
Tene: Trying to use find_method on one object to call them on another sounds a bit like insanity.
Tene benabik: I don't understand. 20:46
benabik Tene: $P0 = find_method a, "meth"; b.$P0()
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
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
Tene: So find_method wouldn't DTRT in that case.
20:54 unStatiK left 20:56 jsut_ joined
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:56
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
benabik Eh. find_method does some variety of magic so interop works
NotFound I think that in the most common cases, it will be able to return something appropiate.
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
klavs++
NotFound Or meta-magic, maybe. 21:00
klavs Cotto, it needs to be improved, but bot today.
cotto_work klavs: sure. The first version is usually rough around the edges.
21:01 jsut left
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.
NotFound: C
github.com/klavs/dm0/blob/master/dm0.c
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.
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
klavs Cotto, thats right. That was not in today's plans. 21:05
NotFound, i took a look at Winxed. I thougt, that it will be too much for this day to learn it in depth. 21:07
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
lucian hmm, i'm wondering about exceptions 21:38
21:55 TiMBuS left, TiMBuS joined
dukeleto ~~ 22:11
klavs: nice m0 disassembler! that was fast. 22:12
klavs Dukeleto, thanks, i found some bugs, and commented the code. Tomorrow i will continue. 22:16
dukeleto klavs: awesome! have you considered writing some tests? 22:17
klavs Dukeleto, i think i should do it. 22:18
22:19 mj41 left
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:21
klavs Cotto, thats funny, i just realised that. 22:22
No tests from me for a while. Perl looks too strange to me. 22:24
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:25
klavs cotto, then it is fine for me too 22:28
cotto_work klavs: what part of the world are you from? 22:36
22:36 kid51 joined
klavs Europe, easter europe, Latvia 22:37
cotto_work klavs: nice. YAPC::EU is happening in Riga.
klavs Eastern not easter
cotto_work I'll be talking about Parrot there. 22:38
klavs Interesting, i have never heard about it. 22:39
Not about Parrot, but... You get it.
cotto_work klavs: it's an excellent dev-organized Perl conference.
highly recommended if you think you might be interested in learning Perl. 22:40
klavs Cotto, everything is possible. 22:41
cotto_work It's a great language if you learn from the right source. 22:42
kid51 aloha, YAPC Europe?
aloha kid51: Sorry, I don't know.
kid51 aloha, YAPC::EU::2011 is yapceurope.lv/ye2011/
aloha kid51: Okay.
kid51 aloha, YAPC Europe is yapceurope.lv/ye2011/ 22:43
aloha kid51: Okay.
kid51 aloha, YAPC Europe?
aloha kid51: YAPC Europe is yapceurope.lv/ye2011/
klavs Cotto, i have no doubts about it. I think i will try perl someday. 22:45
22:46 jsut joined
cotto_work klavs: cool. When you do, I recommend www.onyxneon.com/books/modern_perl/index.html (note that the download is free). 22:49
22:51 jsut_ left
klavs Cotto, thanks. 22:52
lucian has shivers running down his spine 22:54
cotto_work lucian: good ones or bad ones? 22:55
lucian cotto_work: you know my opinion of perl :)
it's late, good night everyone! 22:57
22:57 lucian left 23:21 klavs left
dalek rrot/m0-spec: 6a5c064 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add the beginnings of a description of M0 calling conventions
 23:34
23:34 davidfetter left
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` 23:36

Powered by Cro and the Raku® Programming Language.

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

Thank you!