Parrot 4.2.0 "Ornithopter" | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 10 April 2012.
benabik o/ #parrot, whiteknight 00:01
00:03 tadzik joined
whiteknight hello benabik 00:09
00:42 travis-ci joined
travis-ci [travis-ci] parrot/parrot#256 (master - a760dcf : Christoph Otto): The build was broken. 00:42
[travis-ci] Change view : github.com/parrot/parrot/compare/f......a760dcf
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/1116836
00:42 travis-ci left
bacek_at_work cotto, it can wait until after release. Pretty much harmless branch 00:46
benabik travis error is VM powering down 00:49
whiteknight no dalek tonight 00:53
poor guy must be tired
well, parrotstore has sqlite3 bindings now 00:54
these things are coming together much more quickly than I expected 00:59
I wonder how I am supposed to handle multiple result sets in a sane way with sqlite3_exec 01:06
01:08 GeJ joined
cotto bacek_at_work, thanks 01:26
is there a reason we haven't been updating pbc_compat for stable releases? 02:38
02:39 dalek joined 03:23 sorear_ joined
moritz cotto: it should be done after the release, IMHO 05:43
(re kill_current_object)
cotto moritz, thanks 05:52
06:15 fperrad joined
dalek rrot: a09a954 | cotto++ | / (6 files):
update to 4.3.0
 06:36
rrot: f061523 | cotto++ | tools/release/release.json:
add release.json
moderator Parrot 4.3.0 "In Which..." | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC 06:39
dalek rrot: 1197bf4 | cotto++ | docs/project/release_manager_guide.pod:
one last change for 4.3.0
 06:54
cotto does kill_current_object need any rakudo changes? 06:55
I still need to update docs.parrot.org, but I'm fried. If nobody else jumps on it, I'll do it tomorrow. 06:57
06:59 travis-ci joined
travis-ci [travis-ci] parrot/parrot#257 (master - f061523 : Christoph Otto): The build was fixed. 06:59
[travis-ci] Change view : github.com/parrot/parrot/compare/a......f061523
[travis-ci] Build details : travis-ci.org/parrot/parrot/builds/1117997
06:59 travis-ci left
fperrad cotto, have you pushed the release tag ? 07:10
dalek p: 1b1106c | moritz++ | tools/build/PARROT_REVISION:
bump parrot revision to 4.3.0
 07:26
moritz seems to be missing 07:27
09:16 lucian joined 10:23 lucian joined 11:51 brrt joined 12:08 bluescreen joined 12:59 PacoAir joined 13:00 brrt joined 13:16 awwaiid joined
Coke are there treading tests in "make test" in the threads branch? 13:17
moritz Andy Dougherty mentioned some in his last email to parrot-dev 13:18
no, that was t/pmc/task.t
14:08 lateau joined
Coke (if there are no threading tests, then I didn't really test threads, which is my concern.) 14:10
ah, one test. k.
14:20 hercynium joined 14:26 jashwanth joined 14:48 benabik joined 14:54 dmalcolm joined 15:04 whiteknight joined
whiteknight good morning, #parrot 15:05
benabik o/ whiteknight, #parrot 15:08
whiteknight hello benabik, how are you doing today? 15:10
benabik Congested, but otherwise well. Think I'm going to work on PACT design a little today.
whiteknight awesome 15:12
benabik Did cotto not finish the release yesterday? I saw the release note, but we appear to lack a RELEASE_4_3_0 tag. 15:13
whiteknight the network here at work is crapped up today, so work is proceeding at a very poor rate
benabik Ug, networking problems.
whiteknight srsly. The db server is down so we can't do any testing, the source control is down, tickets are down, etc 15:14
benabik Yay free time? 15:15
whiteknight almost
cotto benabik, forgot to push the tag 15:28
benabik++
benabik cotto: happens 15:29
16:16 dukeleto joined
dukeleto ~~ 16:16
16:30 hercynium_ joined
alvis cotto: ping 16:36
cotto alvis: pong
alvis cotto: hey. do you mind if I run tools/release/parrot_github_release.pl? 16:37
cotto alvis: go for it.
alvis cotto: that way I can watch it a'bit and fix anything that may break?
cotto is it in the release manager guide?
alvis cotto: yep. Section X.
cotto d'oh
I also need to update docs.parrot.org 16:38
now's a good time for that
alvis cotto: 'k. 16:39
dukeleto cotto++ 16:46
16:46 fperrad joined, lucian joined
cotto also updated 4.2.0 docs while I was in there 16:49
that process gets less painful every time I do it
It's really nice not to have to rebootstrap. 16:50
16:51 PacoAir joined
benabik Hm. Does PACT not report to dalek? 17:16
17:16 arnsholt joined
benabik Oh. I think it did, but it probably never got updated when dalek moved. 17:17
Someone with admin access to the Parrot org should check the hooks.
(please) 17:18
lucian waves 17:20
benabik o/ lucian
lucian have i been grossly neglecting my GSoC duties?
benabik Do you have GSoC duties?
dalek CT: d207a53 | benabik++ | src/disasm.winxed:
disasm: Use get_repr to print Keys
 17:22
CT: 509afea | benabik++ | / (4 files):
Typo/whitespace fixes
CT: 450b7b3 | benabik++ | docs/compiling.mkd:
Additional thoughts from tree-optimizer
cotto all better
benabik cotto++ 17:23
cotto benabik++
dalek CT: ee35404 | benabik++ | / (2 files):
Death to POST, long live CFGs

Most of the operations currently done on POST can be sanely handled by either a higher-level AST or on the CFGs. I've also become more convinced about the need of CFGs for reasonable optimization and useful algorithms (like advanced register allocation).
So this commit removes the idea of an opcode tree in favor of control flow graphs. It may be that the AST layer may gain specialty stages or nodes to deal with more low-level operations, but I no longer see a need to deal with it as a completely separate layer.		 17:24
CT: 262c35d | benabik++ | TODO.mkd:
Update TODO with recent news

Mention the GSoC proposal and the src/packfile directories, since they're rather relevant to anyone wanting to work on the project.
cotto I love commit novels.
benabik Commits need to explain the _why_ of a change. :-) 17:25
cotto This'll be a great gsoc.
benabik Sadly, most of what I just updated has more to do with what I can do _after_ my current GSoC proposal. :-/ 17:26
17:27 lucian_ joined
dalek rrot: 5653919 | alvis++ | tools/release/parrot_github_release.pl:
Fixed 'git push' command to 'parrot-docsx' repo.
 17:31
rrot: 468f547 | alvis++ | tools/release/parrot_github_release.pl:
Trying to get the push to 'parrot-docsx' correct.
rrot: 5f6f791 | alvis++ | tools/release/parrot_github_release.pl:
Minor fix: Failed to 'chomp' the 'VERSION' on input.
alvis ok, parrot.github.com is done.
cotto alvis++
alvis cotto: thanks for letting me tweak that script. :)
cotto: just so you know: i do plan to get back on parrotbug; maybe, even this weekend. the shiny new baby's just been ... a handful. 17:34
cotto alvis: no doubt
osuosl still haven't upgrade our drupal instance
not sure what's up with that
atrodo alvis> Shiny? Might want to return it, sounds like someone switched your baby with a robot. 17:36
alvis cotto: 'k. well, i'll let you know when i get to stopping point. 17:37
17:37 hercynium_ joined
alvis atrodo: ha! i wish. maybe there would be so many different fluids, leaking outta her! :) 17:38
dalek CT: c8a35b0 | benabik++ | / (5 files):
Use more obvious header formatting

The # and ## can get lost when skimming the file, and the = and - underlines are far more obvious for the more important headers.
atrodo alvis> Ah yes, the new baby fluids. I remember those days. It's amazing what colors those kids can create when they're new
benabik Things to look forward to... :-/ 17:39
atrodo benabik> Don't worry, you'll forget them quickly. Thats why people have more then one
17:39 hercynium__ joined 17:51 whiteknight joined 18:16 lucian__ joined 18:20 contingencyplan joined
benabik Huh. find_lex just uses {get,set}_pmc_keyed_* for lexicals. I wonder how hard it would be to replace a sub's lexpad with a hash. (Or perhaps a hash per type.) 18:36
benabik is pondering REPLs. 18:37
whiteknight benabik: good question 18:38
benabik Alternatively, a "context" hash could be passed into the evaluated code and the compiler could just emit the appropriate code to retrieve and store to it. But that seems to move the distribution of work in the wrong way. 18:39
moritz you generally don't want separate code paths like that in a sufficiently complex compiler 18:40
benabik Right.
There will already have to be some special casing (like defaulting all variables to be lexicals), but completely unique generation paths are probably to be avoided. 18:41
whiteknight You do raise a good point, there's no reason why the repl needs to generate exactly the same bytecode as would be generated for a normal .pbc file 18:45
Rosella.Template does exactly that, it compiles the code down and you pass it in a context object
benabik Basically, yes. However, if it's simple to (ab)use the lexical system for it, that's probably preferable to requiring the compiler to generate completely unique code for the REPL. 18:46
I'm fairly okay with hand-waving at this point. Actually implementing this stuff is in the mid to long term. I'm just trying to get my ideas straight so I can write down what the concerns are now. 18:50
whiteknight in reality, the code will look up the lexpad in the current context. And whatever the Context says is the lexpad, that's the lexpad 18:51
so if you tell the Context to use something different, it will do that and will be transparent to the code 18:52
there are a lot of benefits to having a context which is a normal object 19:02
As opposed to, say, a C stack frame where if you touch it OMG WHAT ARE YOU DOING STOP DOING IT 19:03
benabik Hah
19:11 mdupont joined
nine Coke: there's also t/src/threads.t though all in all I'm absolutely not satisfied with thread tests. But it's kinda hard to come up with tests which do not take lots of time to run but still exercise the interesting parts of the code, i.e. the GC 19:14
19:16 rich joined, rich left 19:20 brambles joined
whiteknight nine: we can have tests that take a while to run, especially if we don't run them all the time 19:21
we have a folder for benchmark tests or something like that, which take a while
nine whiteknight: good to know :) 19:34
benabik set_returns and get_results appear to be mostly identical to set_args and get_params. Am I missing something? 19:39
So handling return values is just as complex as handling parameters.
moritz no; returning and calling are basically the same operation in CPS
(no to "missing something") 19:40
benabik moritz: I'm very used to CPS, but Parrot doesn't always follow it.
If it was pure CPS, I'd expect to use set_args/get_params both ways, so I wasn't quite sure what the difference was with set_returns/get_results. 19:43
whiteknight benabik: the difference is a small optimization, a return reuses the same CallContext, instead of creating a new one 19:48
Internally, they use the same exact API routines for passing parameters 19:49
benabik whiteknight: Is there a difference between get_results and get_params then? 19:50
whiteknight The differences can go away entirely if we change those ops to take an explicit ctx argument instead of implicitly searching for one
benabik: I don't think so. If there is, it's cosmetic
oh wait, yes. The get_params op searches in the current context, the get_results one uses the return context from the call 19:51
again, the differences go away if we use less magic
benabik Fair enough.
I wonder if it's worthwhile to reduce the magic in the current opcodes a step or two instead of just waiting for M0 killing all magic. 19:52
class & 19:54
cotto benabik: definitely
the more magic gets reduced now, the less we have to reduce it later
whiteknight I had a branch somewhere for adding in a new batch of pcc-related opcodes. I can't remember if that got merged 19:55
Updating get_params and friends should be pretty easy, since people don't use them directly. IMCC outputs those automatically for 'foo'() syntax 19:56
so you can update the opcodes, update IMCC and maybe update a handful of PASM tests
Coke sounds vaguely promising. 19:58
whiteknight I think we're going to need one or two more opcodes to fetch the returns context, but those would be trivial to write 19:59
NotFound We can also add ops and pir syntax without replacing the existing one immediately. 20:00
Then we can change code generators to easily test the approach.
whiteknight yes, we definitely can do that 20:02
I am planning to use Winxed as a guinea pig for some of my proposed PCC changes
If it continues working, and maybe even shows some performance improvements, we can call it a win
NotFound In fact, I think we don't even need pir syntax. Just an improved get_set params and the existing invoke ops may be enough. 20:03
Changing the winxed code generation for that is easy. 20:04
20:13 brrt joined 20:20 perlite joined 20:54 alester joined 20:57 d4l3k_ joined
dalek p: 769b277 | (Arne Skjærholt)++ | src/6model/reprs/CArray.c:
Fix off-by-one bug in CArray.c.
 21:00
21:02 tadzik joined, pmichaud joined, PerlJam joined, Coke joined 21:07 Util joined
dalek p/cstruct-work: 3a23406 | jnthn++ | src/6model/reprs/CStruct.c:
Don't try to allocate 0 bytes in CStruct REPR.
 21:09
p/cstruct-work: 1b1106c | moritz++ | tools/build/PARROT_REVISION:
bump parrot revision to 4.3.0
p/cstruct-work: 769b277 | (Arne Skjærholt)++ | src/6model/reprs/CArray.c:
Fix off-by-one bug in CArray.c.
p/cstruct-work: b85e904 | (Arne Skjærholt)++ | / (3 files):
Merge branch 'master' into cstruct-work
p/cstruct-work: 682e311 | (Arne Skjærholt)++ | src/6model/reprs/CStruct.c:
Implement setting of CArray members in CStructs.

Confirmed working in Perl 6-land, C-land working or breakage to be determined.
21:26 brrt1 joined 22:03 brrt1 left 22:51 whiteknight joined
whiteknight good evening, #parrot 22:51
dalek rrotStore: 0e8b302 | Whiteknight++ | / (36 files):
Move most of the source code into a new src/ folder, to prevent top-level directory clutter
 23:13
rrotStore: cfc3313 | Whiteknight++ | Makefile:
[Memcached] Don't get fancy with memcached dependencies in the makefile. Just build it.
23:23 awwaiid joined
whiteknight I cannot figure out how parrot-nqp's control flow is supposed to work 23:54
because I've got an INIT {} block here that isn't executing, and I can't figure out how it is supposed to work 23:55
23:59 awwaiid 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!