Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
00:14 mikehh left 00:15 bubaflub joined 00:16 bubaflub left 00:23 mikehh joined
cotto_work msg dukeleto an interesting first use for M0 metadata would be to store file and line information 00:39
aloha OK. I'll deliver the message.
dukeleto cotto_work: pong 00:43
cotto_work: i have been thinking about bytecode hashing and signing 00:44
whiteknight cotto_work: s/interesting/mandatory/ 00:51
soh_cah_toa yeah. i highly agree :) 01:02
01:05 davidfetter left 01:10 mtk left
cotto ~~ 01:11
dalek TT #2131 created by whiteknight++: pbc_merge discards annotations 01:12
TT #2131: trac.parrot.org/parrot/ticket/2131
01:17 mtk joined
cotto dukeleto, what have you been thinking? 01:23
dukeleto, also, do you have any alternatives to using labels in set_imm? 01:25
dalek TT #2132 created by whiteknight++: NQP-rx does not use "file" annotations 01:28
TT #2132: trac.parrot.org/parrot/ticket/2132
whiteknight it's almost absurd how little annotations are working throughout our entire toolchains 01:40
people must not be using annotations very much, to be missing all these problems 01:41
and we clearly have no tests for them. And no tests for pbc_merge either
cotto pbc_merge is part of the build. It's the underuse of annotations that's left this problem unexposed for so long. 01:42
not a big part though
soh_cah_toa yeah, they've definitely caused me to think about my project a little differently 01:43
01:48 kid51 joined
kid51 NotFound ping 01:49
msg NotFound To which email address should questions about winxed, the winxed web site, etc. be directed? (particularly from newbies or non-parrot folk) 01:51
aloha OK. I'll deliver the message.
dalek sella: e9ee1c3 | Whiteknight++ | src/winxed/Distutils.winxed:
fix the winxed lib again. modern winxed really hates 'using static'
 01:52
sella: f0e7550 | Whiteknight++ | / (5 files):
Rearrange t/harness because FileSystem is a stable lib now
sella: fdebbe0 | Whiteknight++ | t/ (2 files):
Add a new test directory for sanity tests written in winxed (to prove we can use winxed for tests, not just NQP)
01:53 whiteknight left
dukeleto cotto: reading up about cryptographic hashes and digital signatures and whatnot 01:53
dukeleto would love to see more annotation tests
cotto dukeleto, I'm fine with it if we can do what we claim to do well. 01:55
dalek rrot: 0b40e95 | dukeleto++ | runtime/parrot/library/Digest/sha256.pir:
We (sadly) don't yet again have a JIT runcore
 02:04
02:09 kid51 left 02:12 woosley joined
cotto dukeleto, whatever we do, we need to be sure we define it well. 02:17
dalek rrot: 297c935 | dukeleto++ | t/library/sha.t:
[t] Add a sha256 test for a large string containing newlines
 02:18
02:28 shachaf_ left 02:32 soh_cah_toa left
dalek rrot: d9d9df8 | mikehh++ | MANIFEST:
re-generate MANIFEST
 02:57
rrot: 3cd4b91 | mikehh++ | .gitignore:
add generated winxed files to .gitignore
rrot: 256e9da | mikehh++ | MANIFEST.SKIP:
re-generate MANIFEST.SKIP
cotto dukeleto, feel free to add your thoughts to pdd 32 03:05
03:07 janus joined 03:19 hudnix left 03:27 davidfetter joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_4_0-196-g256e9da 03:29
Ubuntu 11.04 i386 (g++ --optimize)
mikehh this is rediculous - what am I doing awake at this time - have an appointment in 4 hours 03:31
cotto goto sleep 03:34
mikehh cotto: ha - ain't working for me at the moment 03:35
sleep that is
03:37 particle left
cotto mikehh, that's because you're on #parrot 03:39
I sleepchat all the time, but I always fall asleep first. 03:40
benabik And trying to sleep on a bird isn't comfortable.
mikehh especially if it pecks me as I try to sleep 03:47
anyway I shall make another attempt - it's nearly 5am for me :-} 03:48
mikehh but better set the alarm first, otherwise I will be in deep trouble :-} 03:49
04:19 davidfetter left 05:37 particle joined 05:42 theory joined
cotto I seriously need someone to stand over me when I'm coding and smack my hands with a ruler every time I start to type something without having thoroughly thought about it first. 06:12
dukeleto, happy time 06:27
dalek rrot/m0-prototype: 14ba3e8 | cotto++ | / (2 files):
make the interp pass around a reference to the current call frame

Passing around a reference to the current call frame makes it possible for ops to change which call frame is currently active. This and an off-by-one fix in poke_caller get poke_caller working as expected.
rrot/m0-prototype: febedca | cotto++ | src/m0/perl5/m0_interp.pl:
simplify op execution loop a bit
rrot/m0-prototype: 0a4fdd0 | cotto++ | t/m0/m0_assembler.t:
update assembler tests
rrot/m0-prototype: 77de53a | cotto++ | t/m0/basic/hello_canon.m0b:
update canonical hello world m0b
rrot/m0-prototype: f1b698f | cotto++ | / (2 files):
remove bogus m0 test
dukeleto cotto++ # making poke caller work 06:53
06:58 theory left 06:59 cjh joined
dalek rrot/m0-prototype: 1754b36 | cotto++ | / (3 files):
add newline parsing to m0 assembler, update poke_caller to use it
 07:05
rrot/m0-prototype: 83b560d | cotto++ | / (19 files):
update tests to use explicit newlines, fix a few minor goofs
rrot/m0-prototype: db498f3 | cotto++ | t/m0/basic/hello_canon.m0b:
update canonical hello world with an explicit newline
cotto and there's another thing that's been bugging me
dalek rrot/m0-prototype: 79cc5c7 | cotto++ | t/m0/integration/m0_poke_caller.m0:
start converting poke_caller to spit out TAP
 07:10
cotto dukeleto, I'd appreciate you taking a look at poke_caller and adding comments to anything that's unclear. 07:11
I've been staring at it for the last few days, so my objectivity is questionable.
It's really nice to have the concept nailed down in runnable code, but that still doesn't mean that it's easy for others to understand or that it's correct. 07:12
Also, it'd be nice to have pasm codas (codae) in the m0 test files. 07:14
dukeleto, also, any references to RETCHUNK can be excised. I thought I might need it but that turns out not to have been the case. 07:15
07:22 mj41 joined 07:31 dngor left 07:33 dngor joined 08:02 jsut joined, jsut_ left 08:16 fperrad joined 08:57 mtk left 08:59 fperrad left 09:04 mtk joined 09:06 cjh left 09:31 cjh joined 09:34 preflex left 09:37 preflex joined 10:24 woosley left 10:55 jsut_ joined 10:57 lucian joined 10:59 jsut left
dalek p: 53824c3 | jonathan++ | src/ (4 files):
Move decontainerization logic into a place where it can be more easily re-used.
 11:05
p: b43dcd1 | jonathan++ | src/ (2 files):
Add some missing decontainerization.
11:06 lucian left 11:12 lucian joined 11:19 PacoLinux left 11:21 PacoLinux joined
dalek p: c6c1df5 | jonathan++ | src/pmc/sixmodelobject.pmc:
Try and fix build breakage.
 11:28
lucian is late with a blog post 11:35
12:39 hudnix joined 12:40 hudnix left 12:46 hudnix joined 12:47 bubaflub joined 13:04 preflex left 13:06 preflex joined 13:11 whiteknight joined, bluescreen joined
whiteknight good morning, #parrot 13:16
dalek website: lucian++ | More objects. 13:21
website: www.parrot.org/content/more-objects.
bubaflub morning whiteknight 13:22
lucian whiteknight: morning 13:24
whiteknight: annotations? 13:25
whiteknight: re your messasge 13:26
lucian reads commit messages 13:27
whiteknight lucian: for prettier backtraces 13:29
lucian so do i have to annotate my tests somehow? 13:30
whiteknight so it gives you the file names and line numbers of the winxed source files, not the generated PIR
lucian btw, i have to steal your setup.winxed
whiteknight: ah, ok. GREAT! thanks
whiteknight lucian: no, winxed compiler generates the annotations automatically
lucian: and if you generate annotations from your python source, you get the same benefits there for free
lucian i was having to grep pir to find those :)
whiteknight: yeah, i realised
still not sure how i'll do python exceptions 13:31
whiteknight setup.winxed is fine to steal. It's pretty Rosella-specific because Rosella is broken down into libraries, but you should be able to find most things you want in it
lucian afaict right now, i won't be able to implement python's stack traces correctly
whiteknight lucian: what do those look like?
if you look at some of the code in Rosella /src/core/Parrot.winxed, you will see how I generate backtraces. You might be able to adapt that same thing 13:32
lucian whiteknight: they don't look particularly special, but require correct line numbers among other things
yeah, i'll have a look. i've put exceptions off for now, will focus on the compiler for a bit
whiteknight okay 13:38
lucian whiteknight: hmm, now the tracebacks only show exceptions bouncing around in rosella/test guts 13:42
whiteknight what do you mean? 13:44
lucian whiteknight: oh, i'm wrong. sorry about that
whiteknight I do plan to filter out some of those internal functions from test failure reports
but i haven't gotten to that point quite yet
lucian apparently that test still fails, but now now with an exception
whiteknight gist the output? 13:45
lucian not needed anymore, it was my fault
whiteknight ok
lucian tracebacks are fine, i just expected a traceback where there was none
i introduced an exception deliberately in a test and it's fine
whiteknight: much better tracebacks, thanks!
whiteknight no problem, I've been hating the current PIR backtraces for a long time, and finally got off my butt to do something about it 14:03
of course, I ran into a million other problems along the way
14:15 lg_quassel joined 14:20 losinggeneration left 14:24 particle left 14:27 particle joined 14:28 ambs joined
lucian is there a straightforward way to inject the contents of a hash in a namespace? 14:36
whiteknight define "straightforward" 14:37
for (string key in hash) ns[key] = hash[key]?
moritz isn't there a "copy" op or so? 14:38
whiteknight there's a clone op 14:39
There's also an Exporter PMC, though I've never used it and don't know what it does
lucian whiteknight: hmm. perhaps i'm doing this backwards 14:41
i need to boot my object system, which involves creating lots of objects 14:42
which i then want in the namespace of the code generated by the compiler
whiteknight: do you think it'd be better to just generate code that does this?? 14:52
whiteknight what do you mean? 14:54
lucian whiteknight: right now, i have a winxed function boot() that returns a hash with python's builtins
whiteknight ok 14:55
lucian and i was intending that my generated PIR would call boot and put everything in it in the local namespace
i was wondering if perhaps it'd be better to just generate PIR that does boot()'s job
then it'd be all .local-ed
(although i'm not even sure if making a python module into a sub is that good an idea) 14:56
lucian is tempted to generate winxed 15:01
whiteknight is tempted to prefer that :) 15:03
lucian bah. annoying 15:04
whiteknight: hmm, i think i'll try calling set_global from winxed 15:14
whiteknight ok 15:16
there are set_global and set_hll_global opcodes
slightly different semantics
lucian whiteknight: i've given up .hll for now since winxed has issues with it 15:17
whiteknight ok
lucian yay, a boot sub also lets me avoid pbc_merge
whiteknight pbc_merge isn't a bad program, it was just never updated to deal with annotations 15:18
lucian i see
whiteknight actually, maybe it's not well-written, but it does mostly work 15:19
jnthn__ whiteknight: iirc, pbc_merge predated annotations. 15:22
whiteknight: So most likely it just never learend about them :)
I'm sure it's teachable though :)
bubaflub whiteknight: could you open a ticket for pbc_merge to keep annotations? 15:24
whiteknight bubaflub: already did
jnthn__: I'm sure that's the case.
bubaflub well then.
whiteknight trac.parrot.org/parrot/ticket/2131 15:25
15:34 alester joined 15:37 mj41 left
bubaflub whiteknight++ 15:43
dalek rrot/m0-prototype: 78e574f | cotto++ | t/m0/integration/m0_poke_caller.m0:
add an explanation of what this test does
 16:00
16:02 dmalcolm joined 16:04 davidfetter joined
cotto_work ~!~ 16:24
16:33 lucian left
cotto_work this might come in handy: github.com/blog/876-repo-transfers 16:41
16:49 dodathome joined
dukeleto ~~ 17:04
17:04 lucian joined
lucian are globals set with 'set_global' accessible in winxed somehow? 17:06
other than get_global ...
mikehh rakudo (Dahut-15-g4a6d216) - builds on parrot (3_4_0-196-g256e9da) - make test, make stresstest [roast (ea22fe5)] PASS 17:09
Ubuntu 11.04 i386 (g++ --optimize)
17:12 bubaflub left
whiteknight lucian: probably not 17:15
lucian: probably requires get_global
get/set_global basically store data in the current namespace
lucian whiteknight: i see
i find parrot's namespacing very confusing 17:16
whiteknight I feel like those ops are stupid, and we should be able to get a reference to the NameSpace object directly and interact with it that way
lucian: don't fret, it *is* confusing
lucian whiteknight: that's reasurring
yes, dammit! a f*ing reference to the namespace object
whiteknight I'm not here to blow smoke up anybody's ass 17:17
lucian of course, i didn't write it, so i shouldn't complain
lucian apologises
whiteknight NameSpaces are one of those things which I've always said are sucky
lucian whiteknight: i think it's another effect of PIR being the recommended interface to parrot
whiteknight yes, exactly
mikehh whiteknight: how much effort would be required to set up a different interface? 17:18
whiteknight mikehh: in terms of code in parrot? Probably not too too much. The killer is the deprecation policy, updating tests, and updating HLLs and projects that rely on the current interface 17:19
mikehh whiteknight: yeah, I think we need to seriously investigate different possible interfaces 17:20
lucian i find it sad to see a deprecation policy, when the rest of the world is convinced the parrot is dead
people think i'm joking when i tell them i'm working on python on parrot 17:21
whiteknight mikehh: I agree strongly. But before we plan anything, we need to figure out a way to offer the new interface in parallel with the old interface so we don't run into problems from users
lucian: I share that sentiment more than you can possibly know
mikehh whiteknight: yeah, but we should start documenting possibilities 17:22
whiteknight mikehh: this is true
mikehh: you have any ideas in mind?
benabik OTOH, if Parrot is to be useful to anyone, it can't change out from under them too quickly. And having those habits ingrained now is better than trying to put them in afterwards.
mikehh we certainly need to start developing it in parralel 17:23
whiteknight I've always said that we should only make guarantees about the parts of Parrot that don't suck, and the interfaces that are good enough to be stabilized
17:23 rdesfo joined
whiteknight we made a blanket guarantee that everything, including the things which were known to be bad and unworkable, were stable and could not be readily changed 17:23
lucian whiteknight++
i think i'll just end up using Hashes for python namespaces 17:24
no, i'll do even better. i'll use python dicts
mikehh whiteknight: one of the things you mentioned was that we had more or less discarded the PASM interface, we should look at reviving that as much as possible 17:26
and provide the necessary tolls that it is generated properly 17:28
from winxed and/or NQP
and have that as the primary interface to parrot not pir 17:29
but always expect generated code and hand written 17:30
this would allow optimizations and jitting etc 17:31
lucian mikehh: i don't know, i can't even remember the last time i had to write assembly for the JVM
mikehh: oh, i think i misunderstood
mikehh lucian: exactly, we should not have to do that
a large part of PIR is syntactic sugar to enable it to be hand written, which causes a lot of the problems 17:33
17:35 rdesfo left
dukeleto "JSIL is a compiler that transforms .NET applications and libraries from their native executable format - CIL bytecode - into standards-compliant, cross-browser JavaScript." jsil.org/ 17:37
at least we aren't the craziest crazy people
lucian dukeleto: actually, there's another one 17:38
17:39 rohit_nsit08 joined
lucian dukeleto: *this* is what the craziest crazy people do jsc.sourceforge.net/ 17:39
rohit_nsit08 hello #parrot 17:40
mikehh what we really need to do is look at how we can build on M0 and perhaps get rid of (eventually) of a lot of "legacy" parrot
lucian mikehh: i'd like to see most of parrot marked as legacy, in fact
there are few things i've though of fondly
mikehh a lot of things were tried in parrot and many do not work properly, but are still being retained 17:41
which gives a lot of "legacy" overhead 17:42
davidfetter thinks it's pretty cool that people are re-examining compiler technologies
mikehh an important aspect is that we are trying to provide a register based VM as opposed to a stack based one 17:43
we need to examine what we have learned, discard what has not worked properly and provide a lean, mean AND working VM 17:44
lucian dukeleto: www.fructoselang.org/ 17:45
17:45 hercynium joined
atrodo mikehh++ 17:47
lucian> I wonder, how do people find the time to keep working on these projects after they're done with the proof of concept
benabik NQP Question: How to store multiple return values? (PIR: `(ops, posargs) = self.'pos_children'(node, 'signature' => signature)`) 17:49
mikehh atrodo: one of the problems with proof-of-concept and prototypes in general is when to move on and start developing the "real" thing :-}
benabik I tried `my ($ops, @posargs) := self.post_children($node, :signature($signature));`
atrodo mikehh> Or when to realize it's only a proof of concept 17:50
mikehh atrodo: definately 17:51
lucian atrodo: maybe they're actually using them 17:52
mikehh we have the M0 project and need to consider what needs to be added in terms of M1, M1+
lucian mikehh: the register-based nature of the vm hasn't bothered me much
mikehh let's not add things that are not needed 17:53
dukeleto benabik: store the return values in an aggregate pmc?
mikehh lucian: the idea is to avoid stack based overhead on mostly register based machines 17:54
lucian mikehh: i know. it's just that PIR spoils it 17:55
benabik dukeleto: Does NQP simply not due multiple return?
mikehh lucian: right, that's where this discussion started, solution -> replace PIR with something more appropriate 17:56
lucian mikehh: i'm not entirely convinced there is a significant overhead for stack VMs, but it sure is trendy 17:57
mikehh lucian: if we had stack based machines, that's ok - most modern machines are not stack based 17:58
we have two problems there - we are trying something new essentially, and are looking at a dynamic languages VM 17:59
17:59 bubaflub joined
lucian mikehh: i don't see how parrot being register-based helps at all 18:03
atrodo lucian> Also, there's a lot more research into efficient register based architectures that we (in theory) can draw from 18:04
lucian atrodo: for VMs?
atrodo However, that may not be as true today
benabik lucian: There's a lot more literature on optimizations for register machines than stack.
atrodo lucian> In general
dukeleto benabik: i would guess that it does not, but could be wrong. Ask on #perl6 on freenode if nobody in here can give you a straight answer
mikehh lucian: it should, but we need to remove a lot of legacy concepts that have crept in
lucian atrodo: i'm not sure hardware knowledge maps to VMs well
benabik There is also some research indicating that Register VMs are more efficient: www.usenix.org/events/vee05/full_pa...-yunhe.pdf 18:05
lucian benabik: perhaps. but parrot's extremely slow anyway, for many reasons
benabik lucian: Yes, but we can fix that. And we're trying.
lucian sure, parrot is already register-based
atrodo benabik++ # Nice find
lucian so changing it to stack-based wouldn't help
mikehh lucian: how much slower would it be otherwise 18:06
18:06 rohit_nsit08 left
lucian mikehh: impossible to ascertain :) 18:06
but really, register-vs-stack is pointless
parrot has much more fundamental issues, and i think the deprecation policy is the biggest culprit 18:07
dukeleto lucian: i think that is because you are new to the project, and you want to see everything change as fast as possible
lucian dukeleto: perhaps
dukeleto Without our deprecation policy, Parrot wouldn't have any users, since nothing can be built on a foundation that is constantly changing. 18:08
lucian dukeleto: but my work sure feels pointless right now
dukeleto lucian: why does your work feel pointless?
lucian dukeleto: not constantly changing, change a lot once
dukeleto: i hope PIR and Class/Object will go away, and i'm using both
dukeleto lucian: i don't think our dep policy is perfect, but I think it helps more than it hurts.
lucian: don't use PIR Class or Object.
lucian dukeleto: ah, but there's no reasonable alternative 18:09
dukeleto lucian: define "reasonable"
lucian: emulate what Rakudo does
lucian dukeleto: actually working, right now, and with a shred of future
dukeleto: i don't have the resources or age that rakudo does, but i guess i will look into what they're doing 18:10
and i have so far with 6model, but it's extremely hard to figure out
dukeleto: what rakudo does is write its own. and it still generates PIR afaict 18:15
mikehh we are still stuck with PIR for the foreseeable future, we need to investigate new possibilities 18:16
lucian sure
but for now, i'm forced to use a Hash for namespaces, unless i find a hack around PIR's sillyness
and this technique will ideally be obsolete soon enough 18:17
mikehh lucian: I feel your pain, wish I could offer more
help not pain that is :-} 18:18
lucian mikehh: i know, perhaps i just complain too much
mikehh: :)) i didn't see that for a moment
mikehh lucian: without complaints we don't necessarily see problems that need to be raised
dukeleto lucian: using a hash should be fine for now. 18:19
lucian: do you have a test suite which you are trying to make pass? I assume python has some spec test suite? 18:20
tcurtis lucian: there's some work being done on compiling from PAST to POST to PBC without going through PIR.
dukeleto lucian: the internals of your implementation will always change. But if you can make a few more tests pass per week of your python implementation, then you are making progress
tcurtis I think benabik++ is working on that for GSoC, I think.
benabik yes 18:21
tcurtis was redundant.
lucian dukeleto: yes, it does have a test suite. and have no tests running at all now
that's largely because python can't run at all without objects
benabik I keep considering using Winxed instead of NQP...
dukeleto lucian: perhaps you can write simpler tests for your implementation?
mikehh tcurtis: nah, we don't all know what is happening :-}
dukeleto lucian: it is a huge positive boost in coding to see some tests pass 18:22
lucian dukeleto: yes, i will. and i have some left over from pynie
dukeleto: so far i have most object system tests passing (in winxed), which is why i'm switching to the compiler for a while
tcurtis: i see. i guess i would prefer PASM, but not fervently
dukeleto lucian: great to hear! I would really love to see another blog post... 18:23
lucian tcurtis: PIR's evils have been cumulative
dukeleto: you just missed it, check the website
dukeleto lucian: you can just copy+paste irc logs and edit a bit if you are really lazy :) You are doing cool stuff and other people want to hear about it.
lucian: oh!
dukeleto evidently lives under a very comfortable rock
lucian well, if you define "just" very loosely
lucian has to go to a friends' birthday 18:24
atrodo loves comfortable rocks
mikehh has to go and meet some people at a greek resturant in 30 minutes, better get ready :-} 18:25
atrodo hopefully it's not 30 minutes away 18:26
mikehh atrodo: nah only about 5
atrodo I've done that before. Didn't even plan for the 20 minutes it takes to drive somewhere 18:27
mikehh need to leave here in 30 minutes, well less than that now
benabik I'm going to take some time and see what it's like to convert this thing to Winxed instead of NQP, now that Winxed is in master. 18:28
mikehh it's about 20 minutes walk away, but not going to do that
mikehh anyway need to get ready
atrodo winxed++ 18:29
karma winxed
aloha winxed has karma of 3.
atrodo karma Winxed
aloha Winxed has karma of 3.
atrodo That is surprisingly low
whiteknight benabik: NQP does not support multi-returns
benabik NQP is much much better than PIR, but the impedance mismatch is becoming more and more of a problem.
whiteknight: pmichaud said it puts multi-returns into an RPA, but I'm having issues unpacking it. 18:30
18:31 lucian left
benabik whiteknight: Didn't you write an intro to Winxed somewhere? 18:31
whiteknight yeah, give me a second 18:32
benabik whiteknight++
whiteknight whiteknight.github.com/Rosella/winxed/index.html 18:33
benabik: also, look for Data::Dumper in runtime/parrot/library. It will help you dump out aggregates so you can see what the contents are 18:34
benabik Does Winxed have contextuals (find_dynamic_lex)? 18:37
dalek rrot/m0-prototype: 8ba3698 | cotto++ | / (2 files):
make semantics of set_ref match deref, update poke_caller
 18:42
rrot/m0-prototype: ce2b99d | cotto++ | t/m0/integration/m0_poke_caller.m0:
add a bunch of comments to poke_caller
whiteknight no, not built-in
cotto_work dukeleto: can you take a look at github.com/parrot/parrot/blob/m0-p..._caller.m0 ? I tried to make it as clear as possible. 18:47
(or anyone interested in M0)
dukeleto looks 18:56
benabik whiteknight: How do I use Data::Dumper? It's documentation seems slightly laking. 18:58
dukeleto whiteknight: from PIR ? 19:01
benabik: from PIR?
benabik dukeleto: From NQP, but I can drop to PIR if needed. 19:02
dukeleto benabik: you do a load_bytecode 'Dumper.pbc' and a _dump(foo) in PIR
benabik: look at t/examples/past_1.pir 19:03
benabik: seems to be load_bytecode 'dumper.pbc' and then _dumper(foo) 19:04
dukeleto dislikes the interface, but lives with it
cotto_work: i like the comments in poke_caller
cotto_work: it is now much clearer what is going on 19:05
cotto_work: also, you use 'x' to mean an ignored argument, correct ?
cotto_work: it would seem to me that it would be an undefined symbol, but I guess that doesn't happen for ignored arguments? 19:06
cotto_work++ # pasm-highlighting for m0
whiteknight there is a way to use it from NQP too 19:07
benabik: here's an old setup.nqp file from kakapo which uses dumper: github.com/Whiteknight/kakapo/blob.../setup.nqp
actually, nevermind. It doesn't use dumper, it only includes it 19:08
weird
benabik whiteknight: It's a short Q:PIR block. Eh.
whiteknight benabik: ok
benabik: normally, calling PIR functions from NQP should be pretty transparent 19:09
19:09 bluescreen left
whiteknight multireturns is the only case I can think of where it would not be 19:09
19:12 soh_cah_toa joined
soh_cah_toa ~~ 19:13
benabik Does Winxed have something like NQP's pir::? 19:17
cotto_work back 19:18
dalek rrot/soh-cah-toa/hbdb: 0ed756c | soh_cah_toa++ | / (2 files):
Added and fixed a few comments
rrot/soh-cah-toa/hbdb: b3a5844 | soh_cah_toa++ | src/hbdb.c:
Defined hbdb_init()
rrot/soh-cah-toa/hbdb: 323a762 | soh_cah_toa++ | src/hbdb.c:
Changed ARGMOD to ARGIN in command function parameters
rrot/soh-cah-toa/hbdb: 0979095 | soh_cah_toa++ | include/parrot/hbdb.h:
Created hbdb_file_t type
cotto_work dukeleto: the assembler translates x to 0
19:19 gbacon_ joined, klavs joined
dukeleto cotto_work: is that a special case? 19:20
cotto_work: if so, we should add to the spec that using "x" is the preferred way to pass arbitrary params
cotto_work dukeleto: it's treated the same as any other constant value by the assembler
dukeleto: it's already in the spc
*spec
dukeleto cotto_work: goodly
19:22 bluescreen joined
cotto_work dukeleto: I'm not sure I like the name of set_ref. Does that strike you as a good name for what the op does? (it's documented in pdd32) 19:32
dukeleto cotto_work: i will brood upon a better name 19:35
dalek rrot: b97f4bf | benabik++ | t/harness:
Return test error status even when submitting smoulder
 19:37
benabik Huh. That wasn't supposed to happen.
cotto_work no taking it back now
19:38 whiteknight left
benabik Well, if someone complains we can revert it. 19:39
dalek rrot/nqp_pct: 8d11940 | benabik++ | compilers/pct/src/PAST/Compiler.pm:
PAST::Compiler - remove simple Q:PIR blocks

There are lots left, but I'm nibbling around the edges.
rrot/nqp_pct: 214f4c5 | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.node_as_post
rrot/nqp_pct: 871b5cb | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.as_post(Control)
rrot/nqp_pct: 53c706e | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler one-liners
rrot/nqp_pct: 39986b5 | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.as_post(Op)
rrot/nqp_pct: 311e374 | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.def_or
rrot/nqp_pct: 92cc051 | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.bind
rrot/nqp_pct: 392a8ae | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.copy
rrot/nqp_pct: ed8f97d | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.inline
rrot/nqp_pct: 62c07be | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.vivify
rrot/nqp_pct: 778bc2b | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.lexical
rrot/nqp_pct: bfb8aab | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.register
rrot/nqp_pct: 1965e1c | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.wrap_handlers
rrot/nqp_pct: d8ccc49 | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.as_post(Block)
rrot/nqp_pct: 723c015 | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - POST::Compiler.pirop

This still have 5 lines of PIR because NQP doesn't handle multiple return values.
19:40 klavs left
benabik ... I thought I had pushed more recently than that. Sorry.
cotto_work You're making it better. Don't apologize for that. 19:44
If you want to flood the channel with commits that change 15-line PIR methods to 2-line nqp methods, I could watch those all day. 19:45
benabik++
bubaflub benabik++
tadzik benabik: and that still works? :)
benabik tadzik: Makes and passes make test. 19:46
*Builds
tadzik cool :) have the incrementation operator from me too
benabik++
19:58 klavs joined 20:00 Hunger left 20:02 Hunger joined
cotto_work good evening, klavs 20:06
klavs Good evening, cotto (or what should i say if it is ~13.10 for you good afternoon? :) ) 20:09
cotto_work "good afternoon" works 20:10
or whatever. If you're contributing code, you can say "asdfkhajkqwehjqlkjagljhalhd" and it'll be fine. ;) 20:11
klavs Then, good afternoon, cotto. 20:12
Damn, i just thougt, i do not feel like coding today. So that means, i cannot say anything i want :D 20:13
cotto_work klavs: it's a general principle. You're golden. 20:14
(contributing testing and bug reports is equally valuable)
klavs Cotto, i could read spec for 7th time, and try to figure out some interesting question ;) 20:16
dukeleto klavs: how is your disassmbler?
cotto_work klavs: go for it. Alternately, I just added a bunch of comments to a calling conventions test. You could look at that: github.com/parrot/parrot/blob/m0-p..._caller.m0 20:17
or take a day off. That's as important as anything. 20:18
klavs dukeleto, i am thinking about it constantly. ;) 20:21
as i said, i do not feel like coding today, but i have a plan for constant detection and outputting as string.
i have a plan for register formating, too
cotto, i will take two next days off, so i just have to do something today. 20:23
cotto_work klavs: I think it'll be a good idea to build a data structure out of the bytecode segment. Unless you're planning on outputting labels for every instruction, making 2 passes over the bytecode segment data will be the best way to intelligently spit out labels. 20:25
different ops have different properties, and it'll be necessary to have the disassembler understand them on some level to output a nice disassembly. 20:26
e.g. if you're disassembling deref S0, CONSTS, S0, it'd be nice if dm0 were smart enough to add the value of that constant to the disassembly as a comment. 20:27
klavs cotto, i thougt about it yesterday, when i asked about ops, which are using labels. I think i will do first pass to check goto and goto_if ops, while saving labels they reffer to and in the second pass, i will insert them. 20:28
cotto_work klavs: ok. Just make sure you're writing the code so that it's reasonably extensible. 20:29
klavs Cotto, thanks, i wiil write it down so i can remember ;)
Cotto, by concept, should m0 assembler support non-ansii charsets? 20:31
*non-ascii 20:37
dukeleto klavs: seems like it should 20:42
klavs: or the spec should at least specify which charset m0 source files are in 20:43
cotto_work klavs: I'm not sure that it will need to be specifically concerned about them. It should just use whatever data is between quotes.
klavs dukeleto, i think there is nothing mentioned about that. my disasm is outputting every constant as hex string and as a string in comment, because i think there is no way to tell, if constant is not ment as a string. I was about checking if constant does not contain tens of newline chars- 'n that way, code will look ugly. 20:48
20:50 bluescreen left
klavs Cotto, is it perfectly clear to define floating point constant using a hex number? 20:50
sorear hex FP uses 'p' 20:51
0x1.800p4
this is to avoid ambiguity with "e"
klavs I will rephrase my queston. Will m0 understand float if it is defined as, e.g., 0xB0B0? 20:55
cotto_work klavs: m0 treats everything as a bunch of bytes. Values have types depending on how they're used. If a value encodes a valid float, the *_n ops will work with it. 20:56
sorear does that mean 45232.0 or 2.23475772926913e-319? 20:57
20:59 dodathome left
benabik local_branch and local_return? Ack. 20:59
cotto_work I wonder if those get much use. 21:00
klavs That means, m0 asm will treat string "abcdefg" as integer 0x6162 if reffered as integer? 21:01
benabik Well, they were used in PAST.
21:05 bluescreen joined
cotto_work klavs: depending on endianness and word size 21:08
klavs Ok, it is clear for me now. I will try to finish working on labels after weekend. 21:12
but now, i am going to sleap.
may you all have a productive day!
cotto_work klavs: 'night 21:13
21:13 klavs left 21:17 ambs left 21:28 hercynium left 21:32 dduncan joined 21:33 dduncan left
dalek rrot/m0-spec: ef992cb | cotto++ | docs/pdds/draft/pdd32_m0.pod:
remove the unneeded RETCHUNK register, put its space up for rent
 21:34
rrot/m0-prototype: b73907c | cotto++ | / (3 files):
remove references to RETCHUNK, update canonical hello world
21:41 Psyche^ joined 21:46 Patterner left, Psyche^ is now known as Patterner 22:02 alester left 22:08 gbacon_ left 22:17 whiteknight joined
cotto_work ohai whiteknight 22:20
whiteknight hola senor cotto_work
sorear reads lucian's post 22:22
davidfetter in spanish, it's possible to make terrible mistakes by substituting n for ñ
frex, "feliz ano nuevo" could be a threat ;)
sorear it seems like Python's objects are very ... circularly defined
22:25 bluescreen left
cotto_work an object is an object that objects objectively 22:25
davidfetter objection! 22:26
cotto_work objectification?
22:53 gbacon_ joined 23:08 Drossel left 23:09 Kulag joined
cotto_work M0 todo: gist.github.com/1019986 23:11
dukeleto: suggestions for that list are welcome 23:13
soh_cah_toa afromi()? i think that sounds really weird
why re-invent the wheel if itoa() is something everybody knows?
cotto_work soh_cah_toa: that's my problem too.
itoa doesn't match the way m0 uses its arguments
sorear why is itoa a M0 op?
cotto_work sorear: how else would you convert? 23:14
sorear cotto_work: while (n != 0) { *--ptr = 48 + n % 10; n /= 10 } 23:15
or ffi call
soh_cah_toa cotto_work: why? how does m0 use its args?
sorear if M0 is at the C level, it doesn't make much sense to me for it to have a single operation for int->str conversion
cotto_work sorear: dest, src1, src2
er, soh_cah_toa 23:16
soh_cah_toa ahh...
i see your dilemma
cotto_work I may end up flipping a coin. 23:17
soh_cah_toa on the one hand you want to be consistent but on the other you have long established conventions
yeah...coin may be the only way 23:18
:)
though it certainly would be in the parrot tradition to break long established conventions ;) 23:21
23:21 cjh left
soh_cah_toa hmm...wordsize. weren't you and dukeleto talking about an 8-byte wordsize the other day? 23:21
did that not work well? 23:22
cotto_work soh_cah_toa: that's the direction it's moving in, but it isn't in the spec yet.
soh_cah_toa ok
cotto_work mostly because I've been focused on the poke caller test
soh_cah_toa i won't even ask what that is :) 23:23
cotto_work Since you didn't ask, I won't tell you that it's a test to see what code that creates, initializes, invokes and returns from a new call frame looks like. 23:24
soh_cah_toa i'm glad i don't know now
23:24 preflex left
soh_cah_toa actually, that sounds kinda cool 23:25
cotto_work It's a fun test. I commented it very heavily so it should be fairly reasonable to read and understand.
github.com/parrot/parrot/blob/m0-p..._caller.m0 23:26
soh_cah_toa yeah, i can see that being quite useful in the future
what's an "imm"? 23:27
23:27 preflex joined
cotto_work immediate value, i.e. one that's taken directly from the op stream 23:28
soh_cah_toa yeah
as opposed to direct
ouch, testing in assembly (m0 assembly, whatever). that's gotta be rough 23:29
i love assembly and even i wouldn't do that
cotto_work It's necessary. 23:31
soh_cah_toa that's true
cotto_work and the interpreter's written in Perl, so it's not as inscrutable as the typical assembly language 23:32
soh_cah_toa yeah, it seems fairly straight forward 23:34
as for endianness, i would definitely support little-endian 23:36
but that's just my personal preference. big-endian--
cotto_work stupid historical leftovers
yet here we are
soh_cah_toa i know! 23:37
sorear why is m0b using big endians?
cotto_work sorear: who says it is? 23:38
sorear cotto_work: reading between soh_cah_toa's lines 23:39
soh_cah_toa sorear: it was in the m0 todo list. that's what i was referring to
sorear cotto_work: clear 'complaining' tone
cotto_work sorear: that wasn't my intent at all. I'm sorry that I communicated that. 23:40
soh_cah_toa looking at this list, i think now is a good time to ask something i've always wondered: calling conventions. what exactly is a "calling convention"? 23:42
dalek p: b289784 | pmichaud++ | src/PAST/SixModelPASTExtensions.pir:
First set of coercion refactors for attribute_6model.
 23:43
p: dd1944b | pmichaud++ | src/ (4 files):
Add :pasttype<bind_6model> to PAST::Compiler, to improve handling of native constants.

PAST::Compiler's :pasttype<bind> doesn't know about native types, and forces the RHS argument to be a PMC. This doesn't play well with 6model's native attributes, though, and caused a lot of unneeded boxing and unboxing of native constants. Rather than try to fix
  :pasttype<bind> in PAST::Compiler (which likely runs into all sorts
of Parrot deprecation issues), we just add a new :pasttype<bind_6model> that can handle binding to attribute_6model variables (albeit in a slightly hacky way). When we rewrite PAST into NQP, we should be able to clean up the bind semantics dramatically and can fix things then.
cotto_work soh_cah_toa: that determines how arguments get passed from one function (or chunk in M0's case) to another.
soh_cah_toa you mean like pushing them on the stack vs. continuations? 23:44
cotto_work soh_cah_toa: exactly 23:45
23:45 lg_quassel left
soh_cah_toa and are those the two ways you are deciding between or are there other types of calling conventions? 23:45
cotto_work soh_cah_toa: M0 will use CPS. What needs to be nailed down is how it'll be used. 23:47
soh_cah_toa ok 23:49
23:49 losinggeneration joined 23:51 cjh joined 23:52 redicaps joined
cotto_work soh_cah_toa: how's the debugger doing? 23:56
soh_cah_toa i'm actually making a lot of progress. for the past several days i've been "defining the control flow." just really designing the structure of how things will work 23:57
b/c i could just use a quick fix to get breakpoints going quickly. however, this would require major refactoring in the future 23:58
i'm really happy w/ where i'm headed :) 23:59
cotto_work soh_cah_toa: I'm glad you're thinking ahead.

Powered by Cro and the Raku® Programming Language.

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

Thank you!