Parrot 4.0.0 "Hyperstasis" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 12 February 2012.
00:03 travis-ci joined
travis-ci [travis-ci] parrot/parrot#76 (master - 33316f8 : Vasily Chekalkin): The build passed. 00:03
[travis-ci] Change view : github.com/parrot/parrot/compare/5......33316f8
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/717789
00:03 travis-ci left 00:14 particle joined 00:31 dmalcolm joined 00:35 particle1 joined
dalek website: ayardley++ | Parrot 4.1.0 "Black-headed Parrot" Released 00:41
website: www.parrot.org/news/2012/Parrot-4.1.0
cotto Is nobody else seeing the checkdepend.t failure? 00:54
whiteknight I haven't tested since yesterday
01:13 alester joined 01:23 benabik joined
dalek href="https://parrot.github.com:">parrot.github.com: b309cc8 | alvis++ | README_gh-pages.pod:
Add skeleton on how to hand-roll the parrot.github.com docs and any relevant repositories.
 02:21
href="https://parrot.github.com:">parrot.github.com: a634719 | alvis++ | README_gh-pages.pod:
Renamed README_gh-pages.pod to README_release.pod which better indicates the purpose of the document.
href="https://parrot.github.com:">parrot.github.com: d35e549 | alvis++ | README_release.pod:
Renamed doc to README_release.pod to better reflect the purpose of the doc.
href="https://parrot.github.com:">parrot.github.com: 48c88df | alvis++ | README_release.pod:
Partial updates to README_release.pod
href="https://parrot.github.com:">parrot.github.com: fcd9af8 | alvis++ | / (434 files):
Remove 4.0.0 docs
href="https://parrot.github.com:">parrot.github.com: f816802 | alvis++ | / (434 files):
Update to 4.1.0 docs
rrot: cb82296 | alvis++ | docs/parrothist.pod:
Update docs/parrothist.pod to correct the year for 4.0.0 and 4.1.0
 02:40
alvis can someone up op me? thanks. 03:05
03:06 travis-ci joined
travis-ci [travis-ci] parrot/parrot#77 (master - cb82296 : Alvis Yardley): The build passed. 03:06
[travis-ci] Change view : github.com/parrot/parrot/compare/3......cb82296
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/718416
03:06 travis-ci left
dalek rrot: 88e81a1 | bacek++ | / (17 files):
Merge remote-tracking branch 'origin/cont_reuse'
 03:13
benabik No idea if this will work... 03:14
opbots, trust alvis
slavorg But I already trust alvis
alvis benabik: thanks. let me try to set the topic again ... 03:19
benabik: #parrot says i'm not a channel operator. do you mind setting the topic? 03:20
03:20 benabik left, benabik joined
benabik Minor client error there, clicked close instead of channel info... 03:20
(PEBCAK error, to be precise.) 03:21
alvis: No problem. 4.1.0 "???"
alvis benabik: here it is: /topic #parrot Parrot 0.4.8 Released | parrot.org/
benabik 0.4.8? 03:22
alvis oops! make that 4.1.0
benabik Oh, dear... I lost op when I closed the window. 03:23
opbots, do your job
benabik fails. 03:24
alvis yeah, i seem to lose op a'lot. don't know why.
benabik I think the opbots may be taking unauthorized naps.
alvis ha! 03:25
well, ok. thanks. i'll try again later. i gotta coupl'a more steps to finish out this release.
my eight month pregnant wife required my attention, slowing things down a'bit. :) 03:26
benabik alvis: They do tend to do that.
03:42 travis-ci joined
travis-ci [travis-ci] parrot/parrot#78 (master - 88e81a1 : Vasily Chekalkin): The build passed. 03:42
[travis-ci] Change view : github.com/parrot/parrot/compare/c......88e81a1
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/718530
03:42 travis-ci left
moderator Parrot 4.1.0 "Black-headed Parrot" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC 04:06
bacek_at_work ~~ 04:10
04:33 alvis joined
moderator Parrot 4.1.0 Released | parrot.org 04:34
alvis 'k. i, think, i've got this release done, except for two items: 04:37
1) i do not have administrative access to parrot.org to complete item IX.5. of the 'docs/project/release_manager_guide.pod' and 04:38
2) the copyright dates in 'docs/html/*.html' still report an ending date of 2011. 04:39
on the former, i need someone to grant me access, and i'll fix it up ...
and on the later, i'll write a script, hopefully, tomorrow -- though it may be later in the evening -- to fix it. to fix the) 04:40
s/to fix the)// 04:41
04:59 particle joined 05:06 jsut joined 05:28 jsut_ joined
dalek p: 052bc4b | moritz++ | tools/build/PARROT_REVISION:
bump parrot requirement to 4.1 release
 06:05
06:38 dngor joined 07:37 he joined 07:47 fperrad joined 07:54 preflex_ joined 08:24 mj41 joined 08:26 lucian joined 08:53 dngor_ joined 09:01 dngor joined 09:31 lucian joined 10:28 alin joined 11:01 particle joined 11:21 JimmyZ joined 11:57 pmichaud joined 11:58 PerlJam joined 12:01 Util joined, masak joined, Coke joined 12:15 tadzik joined 12:57 benabik joined 13:00 jsut joined
benabik o/ #parrot 13:02
dalek kudo/macros2: 913dc7b | masak++ | src/ops/perl6.ops:
[perl6.ops] wrote a real comment

  moritz++ for noticing.		 13:35
14:33 PacoAir joined
dalek kudo/macros2: 161f188 | masak++ | src/Perl6/Actions.pm:
[Perl6::Actions] fixed remaining two macro call types

The recent stuff only worked for calling macros as terms. Now it works for identifiers, terms, and ops.		 14:45
15:01 bluescreen joined 15:26 whiteknight joined 15:27 kj joined
benabik whiteknight: ping? 15:31
msg whiteknight Love the introspection/PACT article. I am, in fact, planning to apply for GSoC with that very topic. 15:35
aloha OK. I'll deliver the message.
15:46 dmalcolm joined 15:48 Psyche^ joined
whiteknight benabik: perfect! 16:07
benabik: I was hoping you would be in this year. I think that PACT has enough space for at least two non-overlapping projects
but if we had you working on it in dedicated fasion, that would be awesome 16:08
benabik The "non-overlapping" bit might be interesting.
whiteknight if we can come to some basic agreements about what an Opcode PMC is going to look like, multiple people can build tools and interactions with that common interface
and if we had that, a single mentor could easily cover two projects, which is good considering the lack of mentors we had last year 16:09
benabik I'd love to be able to build upwards to the CFG level by September.
whiteknight that would be unbelievable
That chart was just off the top of my head. I'm not certain that AST->CFG is a step that is necessary for a compiler
but being able to construct a CFG at some point would be a big help for analysis 16:10
we could just as easily serialize AST->Op stream 16:13
benabik The most reasonable (IMnoHO) front end for a generic compiler backend is a CFG.
whiteknight okay, it is perfectly fine too if that's what you want. 16:14
benabik Providing a generic AST level syntax is really just trying to make people's lives easier.
But languages trying to do more interesting things may need more interesting ASTs.
whiteknight If we have a generic AST and a generic CFG step and then transformations all the way down to packfiles, creating a new compiler is as easy as plugging in a parser and a runtime
benabik Yup. 16:15
whiteknight because if I have, say, a PHP parser written in PHP that generates its own AST, we need a stage to translate it's tree to our AST and then the engine takes care of the rest of it
benabik Or you can have a PHP AST -> CFG stage instead of going PHP AST -> PACT AST -> CFG. 16:16
whiteknight yeah, that's true. However you want to do the transformation
if we have things like optimizers that only operate on the AST stage, it seems like a bad idea to cut that out
dead code analysis will be easy at the CFG level, but certain other manipulations will happen much better in the AST 16:17
and then some peephole optimizations will happen at the opcode/emitter level
benabik Dead code, constant folding, and more existing things can be done at CFG stages.
Most compiler optimizations are designed at the CFG level.
whiteknight Okay, so it seems like the CFG is something that's going to be very central 16:18
benabik I'd think that AST optimizations would really be more macroish thing. "This AST node actually means this more complicated thing"
Maybe some basic re-ordering, elimination, etc.
whiteknight AST level might be more suited for things like macro substitution than optimization then
benabik But my vision was that everything essential could be done at the CFG level.
whiteknight ...which would be an amazingly awesome thing to offer out of the box 16:19
benabik Basically, I want to port Hoopl to parrot.
whiteknight okay
That's as good a design as any
benabik I like any papers called "Complicated thing made simple" 16:20
whiteknight :)
dalek kudo/match-refactor: dd27465 | moritz++ | src/core/Int.pm:
fix signature of an infix:<!=> candidate. No idea if it makes any difference
benabik And by the time summer comes around I should have my head deep into things like data-flow analysis. 16:21
whiteknight awesome
benabik But I don't know if a summer is long enough to get that far upwards in the stack. :-/
whiteknight yeah, that is the big question
What if we had symbolic op PMCs already, and a serialization/deserialization mechanism for them beforehand? 16:22
worded differently, are there any parts of the stack that you think we could and should provide before the summer, to give our GSOC students the most to latch on to 16:23
benabik Oh. I think there's an opcode PMC already. It has a lot of useful information, so you might want PACT.Opcode to just have a reference to it and the arguments.
whiteknight right, that's what I mean
We have a PMC representing an Op. We don't have one representing the grouping of Op+args 16:24
benabik (Which I think would remove the oplib pointer from your article.)
whiteknight yeah, I was being unnecessarily verbose
not all the readers are going to be as familiar with the system as the great and powerful benabil
benabik*
benabik hah
I suppose a basic set of Unit < Sub < Op classes would be a good start point. 16:27
Even if serialization doesn't exist, it would split the job into serialization on the backend and generation on the front. 16:28
whiteknight that's two separate GSOC projects, in my mind
benabik The trick would be ensuring that those had everything they need at the beginning.
whiteknight serializing a stream of symbolic ops to packfile is not trivial, 16:29
benabik Yes. Which is why I worried about getting from PBC all the way up to CFG in a summer.
Deserialization somewhat exists already, so that could be used as an idea of "what do we need for the classes" 16:30
Going from disarm.winxed to a PACT.Disassembler shouldn't be too much work.
benabik knocks on wood.
whiteknight Okay, let's say that I put together an Instruction and InstructionSerializer PMC type to represent an Opcode+Args and write them to packfile. If we had that before the summer started, what would you be able to do with it?
(If that's a part you're dieing to work on yourself, let me know) 16:31
benabik Well, if we had a _De_serializer and the classes it output, we could have a Serializer as it's own project. I'd bet there are fun gotchas in that direction that deserialization doesn't have to worry about. 16:32
Oh...
If we just had something that dealt with a raw stream, you mean?
Hm....
whiteknight My plan is to write up the basics as a single dynpmc group, so we would have Instruction, InstructionSerializer and InstructionDeserializer PMCs in a single loadable library 16:33
the serializer would take an Array of Instructions, and the deserializer woudl output the same
benabik As far as I can tell, it can all be done without more C-level support.
whiteknight maybe also taking pre-allocated register counts, pre-build constant tables, etc
That's what I'm hoping. Accessing the raw packfile needs to be done in C, everything else can happen at higher levels 16:34
and once we have a packfile, we already have tools to write it to file, to load and execute it, etc
benabik The point of my disasm PoC is that the C level stuff exists. :-) I'm pretty sure that the existing Packfile* classes have enough to work with. 16:35
Although I suppose a cleaner interface could be built. It's not really pretty.
(Especially the writing side.)
There are interesting hidden dependencies. 16:38
If a basic serializer existed... hmmm... 16:39
If we created a basic serializer and a set of classes for a protocol, we could have a complex serializer as one project and a CFG as anothger.
whiteknight The Packfile* PMCs don't take a friendly interface for ops. 16:40
A symbolic Instruction PMC would give us the ability to do round-trim asm/disasm
round-trip
benabik True, they deal with raw integers which have to be translated in either direction. Which can be done in-VM. 16:41
whiteknight The serializer might even be able to be written in winxed, if the Packfile PMCs are capable
deserializer is definitely a C-level tool
benabik Oh?
disasm.winxed seemed to be doing a pretty capable job. The biggest gotcha I had left was Key PMCs being unfriendly to build and introspect. 16:42
whiteknight maybe. The system may be more capable than I expect 16:43
I really do want the ability to introspect bytecode from an individual sub, Which we defintely don't have now
Sub doesn't have any decent accessor for its bytecode 16:44
benabik The relation between Sub and bytecode is rather loose.
Which is somewhat helpful, and somewhat not.
whiteknight The Sub basically has a pointer to bytecode, a start index and and length 16:45
we need to be able to get that info back out
benabik Yes-ish. I'm very curious what will happen if we have enough optimizations that subs have overlapping bytecode. 16:46
whiteknight We've talked about that a lot before. I think that's disallowed
In any case, if we have a method that says "get me the bytecode for this sub" that sub can eventually be updated to assemble chunks or tease apart overlapping code 16:47
benabik I see no reason it should be. A DFA with multiple entry points could be output as a sub per entry point where the guts all overlap.
I'm not sure how often that would come up, but there's no technical reason why it wouldn't work. :-D
whiteknight regardless, the abstraction for getting bytecode stands 16:48
benabik Here's what I'd do: 16:49
1) Build a bare-bones deserializer with the minimal-functional classes needed to represent existing PBCs.
2) Build a set of classes to represent PBCs in a "friendly" way. This is the interface between:
3) A more competent serializer. Handles register counting, constant pools, etc (GSoC?)
4) A CFG system that handles more interesting things like register allocation, variables, etc etc.
Ooops. I missed something in there... 16:50
2.5) A basic serializer that uses the classes from 1
whiteknight okay
benabik Step 3 is really "convert between the friendly and unfriendly classes" 16:51
If 4 is done without 3, it would just need to do some very basic translation.
whiteknight yes, that's important. The nicer the interface is, the more people are going to happily use it
We want to wrap the ugly guts in something pretty, and use the pretty where possible
Ideally, what I would like is this: A function that takes (An array of Instructions, an array of PMC constants, an array of String constants, Integers, Floats) and outputs a bytecode 16:52
benabik Right.
whiteknight If the Instructions contained optional metadata like debug symbols or annotations, those could be added in too 16:53
or if we had some null-Instructions which represented annotations but didn't generate actual opcodes, that would work too
whichever
brb, food
benabik ditto.
bak 17:30
whiteknight awesome
I think what we want really is an InstructionBlock, which has a name, number of used registers, and an array of opcodes. An array of InstructionBlocks represents a packfile 17:42
a single InstructionBlock represents a Sub
var pf = new 'Packfile'; for (var ib in blocks) block.add_to(pf); return self.assemble_packfile(pf, constants, etc) 17:43
and to compile a single sub, essentially, we would do this: 17:44
benabik Why label it InstructionBlock instead of Sub? (or SomethingSub or SubSomething)
whiteknight We already have Sub, and in reality it's not a sub because you can't directly execute it
InstructionBlock is more like SubBuilder than Sub
benabik Right.
whiteknight Actually a number of problems in our system stem from the fact that we use the same type to be a Sub as we use to build and serialize a Sub 17:45
benabik Clear introspection requires clear abstractions.
whiteknight right, and if Sub is anything, it's muddled
benabik :-D
Hopefully building clear introspection will help with clear abstractions. 17:46
whiteknight it will be a big motivator 17:47
My sincere goal is to build up the abstractions we need so that we can start cleaning the internals with some protection over our heads
benabik +1k
whiteknight as far as I am concerned, the Sub should be a simple, read-only wrapper around an invokable chunk of bytecode. Inherently it shouldn't be anything more than that 17:48
benabik brb
whiteknight The Sub shouldn't have a name associated with it, it shouldn't have namespace info, it shouldn't have multisig info, it shouldn't have anything like that. It's just invokable bytecode
And so instead of having to subclass Sub to get it to do what you want or stop doing what you don't want, you just write a wrapper for it and use that 17:49
because Sub is a fundamental core component and should be one of the least magical and least unpredictable things in the system 17:50
Then a NameSpace becomes a hash of name->Sub pairs. A multisub becomes a lookup of Sig->Sub Pairs, a Closure becomes a tuple of (Sub,Context) without needing any clones 17:51
Coroutine is a wrapper with a Sub, a Context and a state flag. A method is just a Sub in a name->Sub hash inside the metaobject 17:52
but that's off the topic a little
If I have a single Sub and I want to store it in a namespace under multiple names, or in a MultiSub under multiple Sigs, I should be allowed to do that and right now you can't 17:53
18:00 dngor joined
benabik Back again. 18:04
whiteknight: 100% agreed, really.
Oh! The most core thing needed to get this working is reasonable in-VM introspection and creation of Key objects. They're pretty magical at the moment and I don't see a reasonable way to deal with them. 18:06
work & 18:11
18:12 lucian joined
benabik back 18:17
18:17 zack_s joined
whiteknight okay, we can work on Key objects 18:18
they're linked lists, in case that helps 18:19
benabik I know what they are, there's just limited/no creation or introspection of them.
whiteknight What kinds of operations do you want to do on them?
benabik IIRC, there's no way to create a new one in-VM. That's done solely by IMCC.
And I'd like to be able to introspect them without them trying to access registers that don't exist. 18:20
whiteknight github.com/Whiteknight/parrot-line...ory.nqp#L7
you can make them in-VM, it's just a nightmare
benabik What about int register keys?
Really it's keys with register types that are the problem. 18:21
whiteknight oh, okay. You're right we can't really do anything with those
benabik And they're required for constructs like `$P0[$I0] = $S0`
whiteknight yes
github.com/parrot/parrot/issues/717 18:25
benabik whiteknight++ 18:26
whiteknight feel free to add any details to that ticket that you think are worth remembering
benabik Just added a note about introspection as well. 18:28
aloha (parrot/parrot) Issues opened : 717 (Need a way to make register-ref Keys from PIR) by Whiteknight : github.com/parrot/parrot/issues/717 18:29
18:31 dngor joined
whiteknight I've added a "PACT" label for tickets on github 18:37
If you think of anything else, make a ticket, give it that label and assign it to me
benabik Cool.
aloha (parrot/parrot) Issues closed : 426 ([LHF] Add tests for Plumage's Util.nqp) by japhb : github.com/parrot/parrot/issues/426 18:39
cotto ~~ 18:41
whiteknight hello cotto 18:52
I've cleaned up some of the labels in the issue tracker 18:53
now we just need a consistent scheme for color-coding them and we're set
19:02 kid51 joined
aloha (parrot/parrot) Issues closed : 344 (FileHandle .puts and .print) by Whiteknight : github.com/parrot/parrot/issues/344 19:10
19:29 dmalcolm joined
whiteknight funny/depressing article about kakapo (the birds): io9.com/5886679/this-is-the-worst-r...al-kingdom 19:33
19:36 mj41 joined
benabik That's really strange. 19:39
whiteknight it's highly adapted to a specific environment: Where there are no natural predators and where nutrient-rich food is sparse most years 19:43
benabik "... this also might be why more males survived in the wild. Using the claws to try to mate with a cat is still better than just freezing up and hoping the cat loses interest." 19:44
whiteknight sounds like a guy I knew a while back who joined the army 19:47
PerlJam he used his claws to mate with a cat?
whiteknight it wouldn't surprise me
20:13 bluescreen joined 20:24 kid51 joined 20:25 perlite_ joined 20:44 contingencyplan joined, contingencyplan_ joined 20:59 autark joined 21:20 dngor_ joined 21:21 zby_home joined 21:25 dngor joined
dalek p: 7b8137f | moritz++ | / (3 files):
implement :$var colonpair syntax

Also adds a single test.		 21:28
22:10 alin joined 22:26 lucian joined 22:58 jsut_ joined 23:41 davidfetter joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!