Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
dalek p: 5a7f87b | jonathan++ | src/core/NQPMu.pm:
Default get_bool override in NQPMu.
 00:02
nxed: r1046 | NotFound++ | trunk/winxedst1.winxed:
Initialize used subids at the start of the subs.
 01:00
01:08 kid51 joined 01:46 ligne joined 02:00 whiteknight left
kid51 What does this passage from docs/deprecations/how_to_deprecate.pod mean? 02:07
"set up automatic usage detection using api.yaml regexes (static usage detection) and/or Parrot_warn_deprecated (dynamic usage detection)"
dalek rrot: 2d79923 | jkeenan++ | docs/deprecations/how_to_deprecate.pod:
Small grammatical and text formatting corrections only.
 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 02:16 preflex joined 02:40 kid51 left 02:45 hudnix left 02:49 bubaflub joined 03:03 Khisanth left 03:22 davidfetter joined 03:24 Khisanth joined 03:28 preflex left 03:31 preflex joined
dalek website: soh_cah_toa++ | Breakpoints...Again 04:02
website: www.parrot.org/content/breakpoints...again
04:24 klavs joined 04:29 particle left
dukeleto ~~ 04:33
04:43 bubaflub left
cotto hi dukeleto 04:46
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:47
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.
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
cotto: what do you mean?
cotto: what is the current state?
bubaflub++ and soh_cah_toa++ # blog posts 04:51
dukeleto reminds the other gsoc students that his blog post radar is on
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
dukeleto, the current state is that goto_chunk is tested and works, but nothing more
dukeleto++ # m0_cover is really nice. 04:53
dukeleto cotto: we are getting to the point where changing the spec means changing many files
cotto dukeleto, yes
dukeleto cotto: many test m0 files, that is 04:54
cotto: what is the concern? that calling conventions isn't as isolated on one side as it could be?
04:54 theory left
dukeleto cotto: do we have any references about that? I would love to read a paper about it 04:54
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
cotto: i see you have been adding m0 test files like a madman
cotto dukeleto, that's possible. I'm not sure where I'd find some appropriate research to dig through though. 04:56
dukeleto, yes, for the easy ones.
s/ones/ops/
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. 04:58
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.
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.
I like having SPC4RENT in the spec, but it's not strictly necessary. 05:04
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
cotto dukeleto, I'm thinking that M0 registers should always be 8 bytes to accommodate double and long as N and I. Thoughts? 05:15
dukeleto cotto: what do other systems use? 05:19
cotto dukeleto, you mean other VMs? 05:20
dukeleto cotto: yeah
cotto: but it seems very reasonable. Just wondering what the possible downsides could be
cotto: bytecode will be larger, but i think supporting doubles and longs is a basic feature that will be quite tasty 05:21
soh_cah_toa i agree and now i sleep 05:22
05:22 soh_cah_toa left
cotto dukeleto, bytecode will be less bloated if we have the ability to load less than 8 bytes into a register. 05:22
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
cotto but if we're planning on analyzing M0, it might not be an insane approach
05:23 davidfetter left
sorear this rule is often considered a terrible mistake 05:23
cotto sorear, I love the random relevant bits of information you come up with 05:24
sorear, that does sound like an ugly special case
sorear CLR locals slots can hold up to 0x3f000 bytes of data, but are (more?) statically typed 05:26
can't remember offhand if .class stores type information for locals at all 05:27
dukeleto cotto: seems like knowing how Java attempted to solve the problem is very valuable 05:30
how important is bytecode bloat?
cotto dukeleto, java has a number of primitives 05:31
www.javacamp.org/javaI/primitiveTypes.html
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
sorear bytes take up more than just disk space 05:32
dukeleto for embedded systems, bytecode size is important
sorear: true
cotto dukeleto, I agree, but that doesn't mean we should throw caution to the wind.
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)
cotto CPU caches are pretty important too
bubaflub hey dukeleto
dukeleto bubaflub: wazzup 05:33
bubaflub: also, nice work on GMP-from-Winxed!
cotto: no caution is being thrown :)
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.
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
dukeleto sorear: sounds good to me.
cotto: so what are the concerns if we change to 8 byte opcodes? 05:36
cotto: and do we want to emulate how java attempted to solve this (i assume not) ?
cotto dukeleto, I'm not suggesting 8 byte opcodes, just 8 byte registers. 05:37
dukeleto cotto: ah, yes, meant that. 05:40
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:41
cotto dukeleto, wasted space, higher memory use, bytecode bloat 05:42
05:42 davidfetter joined
dukeleto cotto: i am interested to know more about the bytecode structure of Rubinius (attempting to search for stuff) 05:42
cotto: what kind of % change in bytecode is expected from that change? 05:43
cotto: % change in the lengh of bytecode
s/lengh/length/
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
so, not a whole lot, especially because it's easier to use set_imm to generate I values <265^2
05:45 bubaflub left
dukeleto cotto: so it seems that bytecode bloat isn't much, since it only effects the constants table 05:49
cotto yes
so runtime call frame size is the main concern
06:03 theory joined, davidfetter left
dukeleto cotto: i am 3 hours ahead of you. I am preparing my sleeping call frame 06:05
cotto dukeleto, 'night 06:06
06:06 theory left
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 06:56 particle joined 07:05 davidfetter left 07:12 mj41 joined
dalek rrot/m0-spec: 3611fa4 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add a note about call frame size
 07:30
07:37 fperrad joined 08:06 dukeleto left 08:53 mj41 left 09:03 klavs left 09:17 mtk left 09:25 mtk joined 09:27 klavs joined 09:31 particle1 joined
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:34
09:35 particle left 09:52 klavs left 10:39 lucian joined 11:05 lucian left 11:28 ligne left 11:39 lucian joined
lucian allison: i seek guidance 12:18
12:43 ambs joined 12:46 JimmyZ joined 12:54 Eclesia joined
Eclesia hi 12:54
lucian i'm trying to figure out how to implement scope in puffin 12:55
dalek rrot/m0-spec: 902d905 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
switch m0b to be based on 32-bit unsigned integers

This doesn't change anything that the assembler or interpreter need to care about (other than a minor change in the header) but should be much less ambiguous than defining everything in terms of the under-defined opcode_t.		 13:06
cotto hope that works
13:09 zby_home joined 13:18 JimmyZ_ joined
Eclesia is possible to store additional informations in parrot bytecode ? 13:22
13:22 ligne joined, JimmyZ left, JimmyZ_ is now known as JimmyZ
moritz yes, with annotations 13:30
Eclesia moritz: if I want to express a constraints on a field for example. let's say something like 'Can not be null' 13:35
it means It can be add as an as an annotation wish will be available in the bytecode ? 13:36
and potentially used by the compiler to ensure this constraint is validate at compilation time 13:37
13:37 kid51 joined
ambs is drowning moritz in work O:-) 13:38
mikehh kid51: you commented that the deprecation procedure imposes a bigger burden on the deprecator (yes), any suggestions 13:42
the idea was to put deprecation info into the docs rather than on the wiki so they are available in the repo 13:44
I would like to automate as much as possible of course, any ideas on that
NotFound Eclesia: usually compiler generate bytecode, don't read it. 13:50
kid51 mikehh: I agree that putting it in docs rather than wiki is a good thing. 13:51
But I was surprised at how *much* must be done to effect deprecations
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.
so I could be possible to add more checks 13:53
it*
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.
In short, I found it intimidating ...
... which says as much about me as about the doc, to be sure.
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.
kid51 I'm sure I wouldn't know how to do that.
mikehh: Can you look at 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
kid51 okay, I wasn't up-to-date with what was on the wiki. 13:56
13:56 lucian left
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:58
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 13:59
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
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
and view the results 14:02
also we can request that others test on different platforms 14:03
kid51 Yes.
kid51 sheds a tear for smolder
mikehh I am trying to work on that too :-} 14:04
Eclesia NotFound: at least it's possible, I have the answer I wanted. thanks 14:05
++
14:05 Eclesia left
kid51 If I am looking at a git pull request from an outside repository, such as this one, github.com/parrot/parrot/pull/135 14:11
... how do I simply download or obtain the diff so that I can examine it locally before doing any merging?
mikehh kid51: you could clone and pull into the clone 14:21
kid51 mikehh: That seems like a lot of work. That's beyond my git-fu. 14:22
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:23
ligne kid51> thanks for looking at that :-) 14:24
i'd have attached it, but i don't seem to have the right magics to comment on tickets.
kid51 ligne: Have you created a Trac account?
ligne kid51> yeah. i'm 'ligne' there too.
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:25
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
kid51> thanks!
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:28
14:29 ambs_ joined, ambs left, ambs_ is now known as ambs
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:29
14:31 ambs left
kid51 ligne: Well, all I'm currently looking for is a plain-text file holding a diff of your two patches. 14:31
You could even paste it.
aloha, nopaste?
aloha kid51: nopaste is is nopaste.snit.ch (works with the script in $_PARROT/tools/dev/nopaste.pl)
14:31 rohit_nsit08 joined
rohit_nsit08 Coke_: hello 14:31
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 14:39 lucian left
ligne kid51> added as an attachment to TT#2116. 14:43
14:46 bluescreen left, bluescreen joined
dalek p: 44a422b | jonathan++ | src/pmc/sixmodelobject.pmc:
Make defined v-table overridable.
 14:47
14:53 whiteknight joined, theory joined
kid51 ligne: Got it, testing with it. Will report results later. Thanks. 14:56
ligne kid51> cool :-) 14:57
15:08 klavs joined 15:13 mikehh_ joined 15:16 mikehh left
kid51 ligne: Now that you can create Trac tickets, you may wish to create one for your other patch. 15:16
15:22 hudnix joined
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:29
ligne kid51> ok, will do 15:34
and it seems that tools/dev/merge_pull_request.pl is meant for exactly this sort of thing 15:35
15:43 fperrad_ joined 15:44 bluescreen left 15:46 preflex left, fperrad left, fperrad_ is now known as fperrad
lucian_ it isn't clear what method adds an item at the beginning of a ResizablePMCArray 15:46
15:47 lucian_ is now known as lucian
whiteknight unshift 15:47
lucian whiteknight: ah, thanks. and push or append for the end? docs are contradictory
whiteknight push/pop works on the end of the list. shift/unshift works on the beginning 15:48
15:48 theory left
lucian ok 15:48
whiteknight <insert standard disclaimer about the performance impacts of shift/unshift>
lucian i really don't care about performance *at all* right now
whiteknight yeah, i figured 15:49
but information is good to have
15:49 preflex joined
lucian yes 15:49
whiteknight: right now i'm boxing PMCs in python objects 15:50
trying to figure out functions and scopes, and pir is proving to be worse than useless
15:52 ambs joined
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
lucian don't know if it'd be a waste of time, 6model and all 15:54
jnthn__ 6model natively groks boxing natives
A Perl 6 Int is an object that contains space for an INTVAL. 15:55
lucian jnthn__: nice. btw, i'm not using 6model for now 15:56
jnthn__ lucian: ok
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.
lucian :)
how does 6model handle scoping?
jnthn__ Scoping in what sense? 15:59
lucian namespaces
jnthn__ Ah
Mostly, it tries to stay out of that business.
Parrot classes and namespaces are very tightly tied. I had not interest in repeating that mistake.
*no 16:00
lucian i see
so the language is expected to implement its own?
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.
If you want to use Parrot namespaces, then that's fine, just install your 6model meta-object into a Parrot namespace. 16:01
er, not meta-object
type object
Or well
That's the thing. Different langauges want to install different things. :)
lucian no, parrot namespaces are unsuitable. perhaps even broken
yes, i agree
jnthn__ Yeah, nqp nor Rakudo uses them
lucian it's just that pir makes it hard to ignore them
jnthn__ Anyway, 6model tries to solve the objects part of the puzzle. 16:02
The other bits of the compiler toolkit are (meant to) help solve other parts.
lucian i think i'll have a 'scope' class for now
jnthn__ And oftne do.
Yeah
We have a Stash class in Rakudo.
lucian yes, as i said earlier, 6model does look very nice, and logical when explained
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 :)
jnthn__ Yeah, I still need that glossary. :) 16:05
lucian :)
16:06 mikehh_ is now known as mikehh
mikehh opbots, names 16:07
16:24 klavs left 16:27 plobsing joined 16:43 ligne left
dalek rrot/tt2116_2117_1979: 0e120b9 | jkeenan++ | t/ (2 files):
Apply patch submitted by ligne++. But we still have test failures.
 17:00
kid51 Hmm, what I posted to TT #1979 probably didn't reflect application of patch. 17:01
lucian is there an ordered mapping in parrot? 17:02
like Hash, but ordered
allison lucian: you pinged? 17:06
(a while ago) 17:07
17:07 mtk left
lucian allison: yes, i was struggling with scopes/namespaces 17:07
allison lucian: ah, yes
lucian: should I read backscroll? 17:08
lucian allison: not necessarily
allison: at first i thought i could use PIR's, and its lexicals
but they're totally unsuited, largely because they're not dynamic objects themselves (scopes and lexicals)
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
lucian allison: are there docs somewhere?
right now, i'm using a Hash
well, starting to
allison well, PIR lexicals don't currently really have scopes smaller than a subroutine, which is a problem 17:10
NameSpace inherits from Hash
so, Hash is a fine substitute
lucian now i have a custom class with a Hash inside
allison but, there are also some methods that a namespace is expected to support
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
so they're only relevant to python objects
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
lucian i've already broken that :)
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
allison lucian: parrot's Object/Class is also a default, but not a one-size fits all solution for all languages
my take on this, is to just go for it
don't worry about fitting in with previous language implementors 17:14
just make a really good Python implementation on top of Parrot
(and by "Parrot" I mean the VM, not the stock PMCs)
lucian allison: yeah, that's sort of what i did so far
i've ignored everything in order to try to reach correct python object behaviour 17:15
as soon as i get functions and modules working, i can retarget the compiler
17:15 mtk joined
lucian it'll run slow, but i don't really mind 17:15
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
slow is a fine place to start
lucian have you had time to look at the code?
allison a little, but not as much as I'd like 17:17
I'll mark that todo in red so I do it in the next couple of days
lucian ok. let me know if something seems particularly stupid
allison still puffin on bitbucket?
lucian yes. also on github 17:18
whiteknight reminded me the rules asked for github hosting, so i'm pushing to both now 17:19
allison the GSoC rules? or parrot as an org? 17:20
lucian second
17:20 rohit_nsit08 left
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
allison yeah, makes sense 17:21
lucian now i just do 'hg push' and it pushes to both
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
(no need for the full Python stack)
lucian right. i'd like you to have a look at my LICENSE, i'm not sure it's correct 17:23
i want it dual-licensed PSF and AL2
allison ok, will do
yeah, that makes sense
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
so, doing both makes sense
lucian nods
i do like AL2 17:25
allison by copyright attribution, do you mean putting a notice of copyright in each file?
lucian uh, copyright assignment
allison oh, yes, they don't do assignment at all, they do copyright license
so, you keep ownership of the copyright
lucian yep 17:26
allison just give them permission to distribute it to others
lucian should i include an explicit license?
allison (Parrot does the same)
you should sign a PSF contributor agreement
lucian both AL2 and PSF give them permission to distribute it
allison yes
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
I'll take a look at what you've got now, should be fine
lucian when you have time 17:28
allison: i have seen opportunities where i could, maybe, implement some parrot interfaces 17:29
for interop
all python objects could implement find_method and get_attr
and function objects could implement invoke
allison those would be useful for compatibiltiy, yes
*compatibility 17:30
but, again, keep an eye on your overall project time, because those can be added later
lucian they'd also simplify the output of the compiler
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
right now, i do obj.__dict__.__class__['__getattribute__'](obj, attr_name) to get an attribute on an object 17:32
the shorthand is obj.get(attr_name)
but it could be just obj.attr_name with parrot's get_attr *and* find_method
17:32 zby_home_ joined
lucian to support obj.attr_name() 17:32
allison: btw, that first syntax example is semantically correct python :) 17:33
17:34 zby_home left
allison lucian: yeah, python is totally comfortable with multiple levels of indirection 17:42
lucian: so, the first absolutely should work
lucian: the second seems like a reasonable addition in the context of Parrot
17:43 klavs joined
lucian allison: the first does, on CPython. although it often gets short-cirtuited by caches 17:43
17:46 JimmyZ left 18:01 kid51 left, klavs left 18:05 preflex left 18:07 preflex joined 18:10 bubaflub joined 18:36 lucian left 18:37 ligne joined 18:39 lucian joined 19:42 klavs joined
cotto ~~ 19:45
19:52 klavs left
bubaflub ~ 19:56
lucian whiteknight: if you have time, i'd like some help with gist.github.com/1009353 20:05
i'm trying to steal your rosella prototype
20:14 theory joined
cotto fperrad, ping 20:16
20:19 klavs joined
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
cotto I guess if you're in France and it's Sunday evening, there's no reason to be on #parrot. ;) 20:20
20:21 lucian_ joined
klavs Which timezone is yours? 20:22
20:23 lucian left
cotto US Left^H^H^H^HWest coast 20:23
LAX
klavs Thats why you were online when i fell asleep and still online when i woke up. 20:26
20:26 perlite left 20:27 perlite joined
cotto It was an early morning. I was actually asleep for most of the last 6 hours. 20:27
klavs, btw, I updated the M0 spec t be less ambiguous about the size of an opcode. 20:29
klavs I took a look at m0-prototype. Is m0-asm and interpreter written in perl? 20:31
cotto klavs, yes
src/m0/perl5/ 20:32
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
klavs So what are the plans for m0. when everything works fine, it will be implemented in c? 20:38
cotto klavs, I think the C implementation will be the most commonly used one. 20:41
klavs, what do you mean by your question about endianness? 20:43
lucian_ cotto: i'm also curious about m0 bytecode portability 20:44
cotto lucian_, me too.
20:45 lucian_ is now known as lucian
lucian oh 20:45
well, i'd say it *must* be portable if it is to be the binary format
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... ?
lucian cotto: uft8's solution is passable, i guess 20:47
cotto: little endian platforms are dominant now, so defaulting to that might not be too bad
that's how jvm bytecode does it too, i think 20:48
dalek rrot/m0-spec: e331522 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
define how the endianness bit is used
cotto klavs, what a silly question. Of course I'd define something that important. ;)
klavs++
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
klavs Lucian, thats how i ment it. 20:52
lucian i see
cotto It comes back to the question of whether we expect m0 bytecode to be distributed. 20:53
20:53 mj41 joined
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:53
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.
lucian cotto: what else to distribute? 20:55
cotto lucian, generated executables 20:59
bubaflub ping whiteknight
cotto I'm leaning toward saying that m0b need to be portable.
bubaflub er, unping whiteknight
ping NotFound
20:59 theory left
lucian cotto: like native executables? i think that's a really bad idea 21:03
cotto: no other vm i know of does that, besides maybe llvm 21:04
NotFound bubaflub: pong
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.
cotto aloha, m0b? 21:06
aloha cotto: I give up.
cotto aloha, m0b is M0's binary bytecode format
aloha cotto: Okay.
NotFound bubaflub: instanceof should do the work.
lucian cotto: and M0 is the textual assembly, that gets assembled to m0b?
bubaflub NotFound: so just if (init instanceof string) should work?
klavs To be clear, we just need to change the order of bytes for every uint32 'cell' in bytecode to change its edianness?
cotto lucian, yes 21:07
NotFound bubaflub: instanceof 'String'
bubaflub NotFound: ah, ok
cotto lucian, One possibility for M0 should be to use an "interpreter" that, instead of running the m0b file, generates C code from it.
lucian cotto: hmm. why C code?
i see portable bytecode much more valuable than C binaries 21:08
cotto lucian, it's portable and easy to convert into an executable 21:09
NotFound A poor man's JIT X-)
lucian cotto: but why bother converting to an executable? 21:10
cotto 1) because we can 2) more efficient execution
lucian i don't see the advantage over a traditional vm model
well 2) is untrue
for dynamic languages 21:11
cotto possibly so. It's a ways off from being even experimental.
NotFound That depends. Functions with long loops involving ints, for example, can have huge speed boosts. 21:12
lucian it might work for statically typed languages running on parrot 21:13
NotFound: all the research i've read shows that all the checks you must do kill performance. JITs beat that, always
NotFound lucian: in theory, theory and practice are equal...
lucian NotFound: practice too. jvm, .net, mono, pypy, etc 21:14
all the js engines
NotFound lucian: I've not yet seen any java or C# application beating anything in speed.
lucian anyway, portable bytecode would not prevent this
NotFound: have you seen Java native compilers beat HotSpot consistently? that's what's being compared here 21:15
even java's object system is dynamic enough to show this effect to some degree
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:16
NotFound I think that in the current situation any method of execution that work will be highly useful. 21:17
(any method faster than interpreting codes with perl, that is)
lucian yes, but this is method that has been repeatedly shown to have severe limitations for dynamic languages 21:18
so i don't think M0 should be designed primarily for this, at the expense of portable bytecode
NotFound My personal view is that the original idea was preferable: M0 not intended to live outside a running VM.
lucian NotFound: and what would be used for distribution? 21:19
NotFound lucian: pbc
lucian NotFound: what would pbc be in the context of m0? 21:20
m0b?
NotFound m1, m2, mN where N > 0
21:20 ambs left
cotto klavs, have you ever wanted to write a disassembler? 21:20
klavs Cotto, do you have something in mind? 21:21
lucian NotFound: so implement pbc on top of m0?
cotto klavs, m0b needs one
NotFound, I don't think the idea of distributing pbc excludes the idea of distributing m0b 21:22
klavs Well, i could try. 21:23
but no perl. I do not know this language, yet.
cotto klavs, sure. What languages do you know?
NotFound cotto: no, but having one method makes less urgent to have the other. 21:24
cotto NotFound, quite true
klavs C, Go, good old Pascal( but i am not going to write anything in it), Java. I prefer first two. 21:26
cotto klavs, +1 on Pascal (and not writing anything in it) 21:27
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.
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/
?
klavs I know how jscript looks like :D i prefer compiled languages. It will take some time to learn scripting. 21:30
NotFound klavs: if you know C and java, winxed should take you almost zero time. 21:32
klavs NotFound, i hate spam.:)
tadzik look weirdly at the compiled-scripted languages 21:33
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.
NotFound, i will take a look at it, but not now, currently i do not want to learn new language. 21:36
lucian klavs: winxed runs on parrot, so it'd be a good choice for a dissasembler 21:37
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.
klavs Ok, ok. I will take a look at it soon. :) 21:39
21:41 preflex left
cotto klavs, are you on github? 21:41
lucian NotFound: quick winxed question: how can i instantiate a class with init[vtable,nsentry] ?
klavs No. I am not.
NotFound lucian: new without ()
lucian NotFound: ah, ok. i'll try that 21:42
NotFound lucian: see t/basic/05new.t 21:43
lucian NotFound: thanks. apparently the problem is elsewhere anyway
NotFound Not sure in nsentry plays well with init, tough. 21:45
dalek rrot: bf1d54a | cotto++ | config/gen/makefiles/root.in:
Merge pull request #136 from ligne/missing_dep

missing Makefile dep for osutils.pbc
cotto ligne++
21:45 preflex joined 21:47 klavs left
lucian NotFound: it's whiteknight's brainchild i'm playing with, not sure myself what's going on 21:51
NotFound brainchild? 21:52
lucian NotFound: rosella/unstable/prototype
i'm trying to steal the attribute and method resolution, and calling
NotFound That methods are my idea, so you can blame me. 21:53
lucian NotFound: i see :( 21:55
s/:(/:)/
NotFound It's a tricky business, it took me some attempts to achieve something that doesn't infinite recurse. 21:56
lucian yeah, i either have that problem, or it crashes 21:57
NotFound: what i have so far gist.github.com/1009353
i'd rather not use Rosella's alloc() 21:58
21:58 bubaflub left 21:59 fperrad left 22:00 fperrad joined
NotFound Looking... 22:00
lucian thanks. if you have time 22:01
22:14 fperrad_ joined, fperrad left, fperrad_ is now known as fperrad
NotFound lucian: The problem is in init 22:18
You need something like ${ setattribute self, protoclass, '__dict__', {} }; instead of self.__dict__ = {}; 22:19
22:19 mj41 left
lucian NotFound: oh, that i'm refereincing self.dict 22:19
NotFound I told you it was tricky ;)
lucian yes, it is
i'm spoilt by python's short-circuits
(__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.
lucian NotFound: yay, it works! 22:22
thanks a lot for the help 22:23
NotFound Nothin'
In cases like this winxed can fool you: it looks like something higher level but you are tweaking with low level pmc machinery. 22:24
But in pir it was a lot more confusing one time I tried %-) 22:25
lucian yeah, it is a bit odd 22:27
anyway, as soon as i figure out methods, i won't need to bother with this code
NotFound It's odd, but is the only way I've been able to bypass the undesired effects of method cache. 22:28
22:30 PacoLinux left
lucian NotFound: in the meantime, i think i figured out how write everything in python beyond the object system 22:47
NotFound lucian: good 22:48
lucian NotFound: something equivalent to winxed's ${ }
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
more precisely, a sub
NotFound Looks good
And you can even write the sub with winxed ;) 22:50
22:50 ligne left
lucian yes, why not. could have a flag for that 22:50
as soon as i boostrap the object system :)
i have functions, namespaces and metaclasses to do
cotto allison, ping 22:53
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:03
lucian NotFound: yeah, that works 23:06
thanks 23:07
NotFound: would you be willing to give me a second helping hand? :)
NotFound lucian: sure 23:08
lucian NotFound: bitbucket.org/lucian1900/puffin/sr...nce.winxed 23:09
i can't figure out what's wrong in find_method
apparently obj.__dict__ is evaluated to null 23:10
NotFound lucian: you need to put __dict__ into itself, of provide a shortcircuit, 23:13
lucian NotFound: ah, of course. silly me
NotFound This works: var dict = {}; dict['__dict__'] = dict; ${ setattribute self, class instance, '__dict__', dict };
On iit
init
lucian NotFound: and it works! thanks, master wizard 23:14
NotFound Thanks, young padawan ;)
lucian so now everything should just work. well, after i rewrite all of it :)
NotFound I'm glad to see my experiments with pseudo-metaclasses being useful :) 23:16
lucian yes, quite 23:17
all this helped turn the syntax from int.__class__.__dict__['__getattribute__']('__new__')(2) into int.__new__(2) 23:18
23:18 jsut_ joined
NotFound Just remeber that is only syntax, the runtime cost will still be noticeable. 23:20
23:20 zby_home_ left
lucian NotFound: yes, i realise 23:21
but the syntax is the interface to the object system
if i can keep the syntax ok, the object system can be fixed more easily later 23:22
NotFound: hmm, it appears this experiment breaks constructors. or i'm doing something wrong again :)
23:23 jsut left
NotFound Constructors? 23:24
lucian class instance { function instance() }
apparently i need to make the constructors with __dict__ 23:25
or add short-cirtuits
NotFound Yes, winxed constructors are plain methods, so if you change method search...
lucian yes, exactly
i think i'll make python's object system even more circular now
i'll just make instance a python metaclass :)
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.
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:27
lucian NotFound: yes, CPython has much more written in C than it has to. PyPy changes this for the better, i guess 23:28
whiteknight: yes, i think i'll do that as well
23:28 jsut joined
lucian i think i'll have factory functions for creating the first python types 23:28
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
lucian nods
although if the object model you're implementing has metaclasses (as is my case), the issue is a lot smaller
but still present 23:31
for example, exceptions are a tad complicated
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
this just isn't something that PIR handles very well 23:33
we need better object model support for it
23:33 jsut_ left
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:34
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
lucian yes, i realise that
whiteknight and there are not many good ways to make it support the necessary operations, as is
doing even simple things, like pretending to have private attributes, requires severe hacking 23:36
lucian hmm. wouldn't that work with just a second namespace? 23:37
whiteknight like a second class? Foo and Foo.__private? 23:38
NotFound Attributes live in the class, not in its associated namespace.
lucian whiteknight: an instance of NameSpace in that Foo.__private, yes
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
whiteknight and then anything with that in the attribute name is treated as private
lucian whiteknight: there's a cool and stupid trick one can do in CPython, which is non-string attributes
whiteknight ah, that would be nice too. The attribute hash in Object PMC uses string keys though
lucian i know 23:40
whiteknight Parrot hashes can use any type of key, but the ones in Object use strings
lucian it's actually a point where i'll diverge from CPython behaviour
i don't really care, no one in their right mind uses non-string attrs in python
NotFound lucian: You mean using a Namespace object instead of a Hash? You want even more headaches? ;) 23:41
lucian NotFound: heh 23:44
btw, i have another question: how can i call the init_pmc vtable method?
allison cotto: pong 23:48
NotFound lucian: If I've not fooled myself, the new [ ] variant will do it. 23:49
lucian NotFound: and how can i pass a sub to it with that syntax? 23:50
cotto allison, ouch. just heading out the door
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,
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.
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.
NotFound lucian: if not, declaring it with using.
lucian NotFound: so new [instance](sub) ?
cotto allison, will have to backscroll later.
NotFound lucian: ['instance'] or ['Python', 'instance'] 23:52
lucian right. i'll try
allison cotto: that's a longer answer anyway, so will take a note and get back to you later 23:53
NotFound I think I should add a modifier or something to do that with the more usual new syntax. 23:54
23:56 soh_cah_toa joined
lucian NotFound: hmm. new ['Python', 'instance']( function() {} ); doesn't work, "can't find get_iter in class Sub" 23:56
23:56 plobsing left
NotFound This is a serious candidate for the most misleading error message prize. 23:57
lucian ah, but it is calling init_pmc
NotFound Ah... yes... this is yet another serious problem of parrot object model.
lucian exact message is "get_iter() not implemented in class 'Sub'"
NotFound init_pmc in Object always looks for a hash to initialize attributes, 23:58
lucian really? lame
i guess i'll just do without invoke, not a big deal
NotFound Well, not init_pmc itself, but instantiate before calling it.

Powered by Cro and the Raku® Programming Language.

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

Thank you!