Trac maintenance Wed Aug 24 17:00 UTC | Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 23 August 2011.
00:15 whiteknight joined
whiteknight good evening #parrot 00:16
dalek rrot/whiteknight/kill_threads: e385475 | Whiteknight++ | src/thread.c:
Rip out src/thread.c. The rest of this branch is devoted to making parrot build and run without it
 00:20
sella: 6191b53 | Whiteknight++ | s (5 files):
Several fixes and cleanups to the Dumper library. Add it to the build since it compiles and runs now
 00:22
sella: 623b787 | Whiteknight++ | s (9 files):
Big rewrite of several parts of the dumper library. Add more DumpHandlers for various purposes.
00:23 benabik joined
whiteknight NotFound++ for __DEBUG__ 00:24
did the patch so I didn't have to
that patch is going to work awesome with my new Assert library 00:29
Coke allison: you're on IRC a lot lately. How you doing? 00:36
NotFound whiteknight: doing it required stage 0 support, you don't need to mess with it. 00:37
dalek sella/gh-pages: 55b17db | Whiteknight++ | libraries/template.md:
flesh out some of the Template docs
 00:58
bubaflub whiteknight: ping - got a C question for ya 01:03
whiteknight bubaflub: pong. I've got lots of C answers
some of them are even worth the bits I use to transmit them
bubaflub whiteknight: fantastic. i'm trying to write a GMP benchmarking script - i've got stuff in Winxed for native pir, Winxed class without using VTABLEs, and Winxed class using VTABLEs. i'm trying to write a C script that'll do the same benchmark - how do i get a high precision timer in C? 01:04
or rather, what's the standard way? the benchmark isn't really running long enough to use `time` 01:05
(i will write another benchmark that is a bit more intensive)
whiteknight en.wikipedia.org/wiki/Time.h 01:06
plobsing bubaflub: callgrind is good 01:07
whiteknight probably clock() would be the most precise, but not always easily to convert to information you would understand
bubaflub plobsing: ah, good idea.
plobsing but it may need complex analysis. do you only care about instruction count (usually a good first order approximation of performance)? or do you care about cache misses? how do you weight the importance of L1i, L1d, and L2 caches? 01:08
whiteknight plobsing: he's comparing timings against various versions 01:11
a version in versions in winxed, etc
cotto_work If you're writing Parrot C, Parrot_hires_get_time() should dtrt. 01:14
kid51_at_dinner Coke: Could you open a Trac ticket for 'make release' on Windows? Thanks. 01:38
Coke kid51: if it fails, yes. 01:39
kid51 cotto seems to indicate that it's broken, but didn't post any output. 01:40
01:40 woosley joined
kid51 So I don't know what the problem is -- not that I have a Windows box to try to fix it on. 01:40
dalek sella/gh-pages: c758a86 | Whiteknight++ | libraries/template.md:
small formatting fix
 01:42
sella: 58eb23c | Whiteknight++ | setup.winxed:
fix typo in build script
sella: 970809f | Whiteknight++ | / (13 files):
Change around Template.Node and subclasses so they take strings instead of a Token object
kid51 msg cotto trac.parrot.org/parrot/ticket/2178 seems like the sort of thing that you might be able to give quick thumbs up/down on, given pmichaud's comment 01:43
aloha OK. I'll deliver the message.
Coke has a local branch with a dead NEWS file.
Coke just needs to do a sanity check and make sure crow still works. 01:44
./parrot tools/release/crow.pir --type=text 01:47
Invalid character in ASCII string
current instr.: 'parrot;Crow;get_news' pc 121 (runtime/parrot/library/Crow.pir:76)
called from Sub 'main' pc 115 (tools/release/crow.pir:63)
NotFound Coke: make sure the json files are utf8 encoded 02:03
Coke didn't change the json, changed the NEWS to ChangeLog 02:13
$ file ChangeLog
ChangeLog: UTF-8 Unicode English text
NotFound Coke: I'll look at it tomorrow, now must go. 02:15
Coke it's in a branch. I'll push it. 02:16
dalek rrot/tt_2184: 5b0cde3 | Coke++ | ChangeLog:
Remove accidental #1
 02:19
rrot/tt_2184: d357319 | Coke++ | NEWS:
Convert all NEWS entries to be more like Changelog.
rrot/tt_2184: a15b7c8 | Coke++ | ChangeLog:
remove all references to releases (covered by NEWS)
rrot/tt_2184: f6dd8a5 | Coke++ | ChangeLog:
whitespace (headers)
rrot/tt_2184: b9fefa1 | Coke++ | ChangeLog:
Change tabs to spaces.
rrot/tt_2184: bb6a199 | Coke++ | / (2 files):
0.4.10 was the first release with no Changelog.

Move all those over at the head of the file.
rrot/tt_2184: 70e35ef | Coke++ | / (2 files):
Move remaining elements into Changelog
rrot/tt_2184: e5b1ce6 | Coke++ | ChangeLog:
use a consistent date separator.
rrot/tt_2184: e264c8c | Coke++ | ChangeLog:
switch entries that have been out of order.
rrot/tt_2184: e5a7ccf | Coke++ | ChangeLog:
Add dates to the releases (from parrothist)
rrot/tt_2184: 7c5543a | Coke++ | MANIFEST (2 files):
rerun mk_manifest ...
rrot/tt_2184: 4a54ac0 | Coke++ | / (5 files):
Use ChangeLog instead of NEWS
Coke msg NotFound try running crow in tt_2184.
aloha OK. I'll deliver the message.
dalek rrot/tt_2184: 54c28b8 | Coke++ | runtime/parrot/library/Crow.pir:
remove debug output.
 02:21
TT #2185 created by coke++: "nmake release" fails on windows 02:49
TT #2185: trac.parrot.org/parrot/ticket/2185
Coke wonders if you can make archive::tar's bzip2 compress as much as, say, bzip2. 03:00
03:23 benabik joined
benabik o/ 03:23
dalek rrot/tt_2185: 96e72a5 | Coke++ | tools/release/cut.pl:
Add new perl-based release script.
 03:27
rrot/tt_2185: 3df22e1 | Coke++ | config/gen/makefiles/root.in:
Replace unixy release code w/ portable perl
rrot/tt_2185: 9b2356c | Coke++ | MANIFEST (2 files):
rerun mk_manifest_skip, as DEVELOPING is missing.
Coke there, 'nmake release' now works on windows. 03:34
(at least in that branch). cleanups and compressionings wanted. 03:35
03:48 particle joined
Coke particle: I fixed yer windows release process. Take a release, wouldja? ;) 03:52
soh_cah_toa is happy to see some work being done on win32 03:53
Coke eh. perl did all the hard bits. 03:54
04:46 particle1 joined 05:29 fperrad joined 05:52 fperrad joined
NotFound Coke: ping 05:55
dalek rrot/tt_2184: 0041ea6 | NotFound++ | / (2 files):
fix ChangeLog handling in crow:

  - Fix release mark detection: not at the start of line now
  - Delete whitespace in blank lines in ChangeLog		 06:22
NotFound msg Coke Several fixes to tt_2184 in 0041ea637e 06:23
aloha OK. I'll deliver the message.
06:44 Kulag joined 06:48 SHODAN joined
cotto ~~ 07:03
07:21 Kulag joined 07:33 Drossel joined
dalek kudo/nom: 90e66fb | moritz++ | src/Perl6/Actions.pm:
make sure that ..., ??? and !!! pass Perl 6 strings to &fail, &warn, &die

  uvtc++ for discovering it		 07:40
08:27 Kulag joined 08:30 mj41 joined 08:39 cosimo joined, Kulag joined
dalek kudo/nom: 9323ff6 | moritz++ | NOMMAP.markdown:
add lexical regex lookup to nommap, volunteer pmichaud++ for it :-)
 08:57
09:01 Drossel joined 09:25 rfw joined 09:35 Kulag joined
dalek kudo/nom: da40716 | moritz++ | src/core/Cool.pm:
fix Cool.IO for non-Str
 09:36
kudo/nom: f638895 | moritz++ | src/core/IO.pm:
remove debug output, tadzik++, moritz--
09:39 cotto joined 09:42 particle joined 09:43 Kulag joined 09:45 rfw joined, ambs joined 09:46 Kulag joined
dalek kudo/nom: 6e4aa6c | tadzik++ | src/core/IO.pm:
[IO] Add &chdir and &mkdir
 09:59
10:00 Kulag joined 10:08 Kulag joined 10:45 lucian joined 10:54 Drossel joined 11:02 Kulag joined 11:21 kid51 joined 11:29 mj41 joined 11:39 ambs_ joined 11:46 ambs_ joined 11:55 lucian joined 12:04 jsut joined
cotto aloha, clock? 12:13
aloha cotto: LAX: Wed, 05:13 PDT / CHI: Wed, 07:13 CDT / NYC: Wed, 08:13 EDT / UTC: Wed, 12:13 UTC / LON: Wed, 13:13 BST / BER: Wed, 14:13 CEST / TOK: Wed, 21:13 JST / SYD: Wed, 22:13 EST
12:33 whiteknight joined
whiteknight good morning, #parrot 12:34
cotto hio whiteknight
whiteknight good morning cotto
cotto: how jetlagged are you?
cotto right now, not very much, contrary to what you might expect. I slept for 15 hours Monday night and felt pretty normal yesterday. 12:35
whiteknight what time is it there, like 5:30?
cotto yup
13:33 PacoLinux_ joined 13:36 bubaflub joined
cotto whiteknight, what does your day look like after $work? 13:46
13:47 contingencyplan joined
cotto heads to $dayjob 13:50
13:55 PacoLinux_ joined 13:59 bluescreen joined
whiteknight cotto: I don't know. what needs doin? 14:05
cotto_work ~~ 14:07
whiteknight: I've got some thoughts brewing that I'd like to talk about.
14:17 lucian joined
bubaflub whiteknight: can you help me diagnose a C compiling error? 14:27
whiteknight cotto_work: lay it on me, brewmeister
bubaflub: sure thing. What do you need?
bubaflub whiteknight: Eclesia tried building Parrot-GMP and got the following error: nopaste.snit.ch/73810 14:28
whiteknight: the error is building the NCI thunks. those commands are put together from stuff in parrot_config and works on my system (though of course the command to build is different)
whiteknight: i'm wondering what in that line is extraneous - then i can figure out what thing from parrot config i'm adding which i don't need 14:29
whiteknight hmmm.... that's a good question
bubaflub: I'm not sure I can see an obvious problem there 14:30
bubaflub whiteknight: ok, hows about from my build script? github.com/bubaflub/parrot-gmp/blo...inxed#L158
whiteknight: if nothing is obvious, i'll just wait till Eclesia gets back and we'll try a few things
whiteknight it's a problem with linking, not compiling 14:32
I really don't see a problem here 14:33
bubaflub whiteknight: ok. i'll wait till Eclesia gets back and we'll try a few things.
whiteknight bubaflub: plobsing might have insight, if anybody does 14:36
14:37 davidfetter_ joined
bubaflub whiteknight: true. 14:37
ping plobsing
dalek rrot-gmp: a6372e0 | bubaflub++ | setup. (2 files):
updates to setup:

remove one extra call to the config hash clean up NCI thunks if they are built		 14:41
whiteknight msg dukeleto: please fill out your final review for GSoC 14:51
aloha OK. I'll deliver the message.
whiteknight msg allison please fill out your final review for GSoC 14:52
aloha OK. I'll deliver the message.
allison whiteknight: thanks for the reminder
whiteknight msg darbelo please fill out your final review for GSoC.
aloha OK. I'll deliver the message.
whiteknight allison: No problem. I'm trying to remind people without nagging
msg soh_cah_toa please fill out your final review for GSoC 14:53
aloha OK. I'll deliver the message.
whiteknight msg tcurtis please fill out your final review for GSoC
aloha OK. I'll deliver the message.
moritz somtimes it would be nice to have the bots talk to each other
for <list of nicks> { print "msg $nick please fill out your final review for GSoC" } 14:54
whenever I think that, somebody reminds me of my sanity :-)
tadzik insane moritz. It should be $^nick!
moritz ah right :-)
or $_
dukeleto ~~ 14:56
15:07 jsut joined
plobsing bubaflub: pong 15:09
bubaflub plobsing: i was wondering if you could tell me what's wrong nopaste.snit.ch/73810 - Eclesia tried to build Parrot-GMP and got that error. 15:10
plobsing like the first error message says, you need -fPIC to create relocatable object code
bubaflub plobsing: but i see there is a -fPIC on that line 15:11
plobsing I see the .so is being compiled -fPIC (this is a nop)
what you need to do is compile the .o -fPIC
bubaflub plobsing: ok 15:12
plobsing -fPIC generates Position Independant Code, which is done when generating machine instructions (in the .c -> .o stage)
.o -> .so doesn't do assembly
bubaflub plobsing: ok, so i'm generating that command from here: github.com/bubaflub/parrot-gmp/blo...inxed#L158 is there another option from the parrot config hash that i need? 15:13
plobsing ./parrot_config --dump | grep fPIC shows cc_shared 15:15
at one point I tried to make a set of parrot_config keys that were to be all that was needed to compile extensions, but that was tough and there wasn't much enthusiasm for it
bubaflub plobsing: i'm all game for cleaning up the config hash 15:17
plobsing: and that makes sense - on my system cc_shared is ' ' so it would work for me and not for Eclesia 15:18
when he gets back online i'll have him try it out. thanks for all the help. plobsing++
whiteknight we could cut the config hash down to one tenth of its current size, and nothing of value would be lost
plobsing whiteknight: that's the runtime config hash. the hash in parrot_config can afford to be much larger without much cost to anyone. 15:19
bubaflub whiteknight: yup. we have both 'gmp' => 'define' and HAS_GMP => 1 for example
plobsing right now I beleive they are one and the same, but I am of the opinion that that should change
bubaflub plobsing: split to runtime and compile time hash?
plobsing pair down the always-loaded runtime hash to a separately loadable module 15:20
which would be loaded much less frequently (hopefully)
bubaflub how much would that help with our startup time?
whiteknight measurably, not not hugely 15:21
miniparrot is just parrot without the config has. Run it in a loop to see the difference
plobsing not much. I eaked out tenths of a second back when I changed the hash from (string => PMC) to (string => string), but now it doesn't show up high in the profiling data
plus, parrot startup is one of the least important performance metrics ATM 15:22
dukeleto i think it is mostly the memory bloat that the config hash implies, which would matter on small memory/embedded systems 15:24
bubaflub another newbie question - if i want to use Parrot_hires_get_time do i just #include parrot/parrot.h and compile -lparrot ?
plobsing exactly
cotto_work bubaflub: if that's all you want and platform-independence isn't an issue, you can just use clock_gettime(). Parrot_hires_get_time is just a wrapper around that and some other platform-specific code for various platforms. 15:27
which approach is lazier depends on you ;) 15:28
bubaflub cotto_work: i'd like to include this with a C benchmark in Parrot-GMP - will i need some of that platform specific code? theoretically the benchmark should run wherever parrot does
cotto_work bubaflub: if you're using libparrot, it'll take care of the platform abstractions. It just seems odd to me to link to it just for the high-resolution timer code, that's all. 15:29
15:29 atrodo joined
bubaflub cotto_work: ok. i'm open to the clock_gettime() way 15:29
you can tell i don't do much C work
atrodo =~ 15:30
whiteknight hello atrodo 15:31
atrodo morning whiteknight. Barely. Haven't gotten anything done today. Of course the transformer had to go out the one day I need to work from home. 15:32
whiteknight ouch. quake-related? 15:33
atrodo no, squirrel related 15:34
dukeleto ESQUIRRELNOPOWER
atrodo dukeleto++ exactly 15:35
cotto_work So you're saying you've got a new squirrel recipe to try out on your guests? 15:37
atrodo cotto_work: I wish. They didn't find the squirrel crisp
cotto_work skunked again 15:38
whiteknight we got skunked last night some time
or, more specifically, the rooms in the house with open windows smelled very skunkish
benabik o/ 15:42
dukeleto tcurtis: ping 15:53
16:23 PacoLinux_ joined 16:26 dmalcolm joined 16:48 mj41 joined 17:03 tewk__ joined
tadzik tewk__: ping 17:04
tewk__ tadzik: yes? 17:37
tadzik tewk__: there are two select.pmcs in your branch, an ordinary one and a dynpmc. They have slightly different contents, which one is newer/better? 17:38
tewk__ I wrote the ordinary one, I think someone else did the dynpmc. check the logs. 17:39
git logs that is
tadzik okay 17:40
tewk__ tadzik, you goint to get it merged? that would be cool. 17:41
tadzik tewk__: I thought about stealing it for nqp, to use it in Rakudo. I tried to push the merge effort a few times, but Parrot seems to be unsure about the interface it should have 17:42
cotto_work If you pick one, that's all I need. 17:43
tadzik tewk__: if we got it in Rakudo, we can play with it, play with its interface and hopefully produce something that Parrot can adopt
cotto_work or that
tadzik cotto_work: it's just that it's quite difficult to decide on something until you get to know it well
it's just as with the Perl 6 specs, and "why aren't they frozen"
tewk__ tadzik: ah so put the dynpmc nqp? 17:45
tadzik tewk__: I don't know if I'm even able to do that, I'm just fiddling with the thought :P
cotto_work: could we just merge it in Parrot, mark in api.yaml as EXPERIMENTAL, and possibly change it if we don't like it? 17:46
Perl 5 people do that
tewk__ I think you would need to get it in parrot first.
17:46 contingencyplan joined
tadzik P5's select(): metacpan.org/module/IO::Select 17:47
cotto_work tadzik: sure. Which interface do you want in the Select PMC, which will then be marked experimental?
tewk__ tadzik: select.pm was modeled after IO::Select.
dukeleto i am +1 to merging some kind of Select PMC into master for people to play with, and marking it experimental. What is the downside?
tewk__ select.pmc that is
cotto_work trac.parrot.org/parrot/ticket/2034 17:48
whiteknight put the pmc into master as experimental 17:49
pmichaud the advantage (for rakudo) of playing with it in the rakudo repository is that we don't have to bump PARROT_REVISION every time a small change needs to be made to the pmc
whiteknight experimental means that it isn't solidified
cotto_work Sorry about the bad formatting in the last post in that ticket.
whiteknight Rakudo can work on its own version as well, if they want to, and can share back thoughts about it so we can improve the core version 17:50
pmichaud wfm
the parrot repo doesn't seem to be the most efficient place (for hll devs) to play with experimental features
in fact, it's very inefficient. 17:51
tadzik cotto_work: the first interface you propose looks niceish, but I think that if a HLL decides it's a must-have, it'll implement it on top of the Select PMC. HLLs will probably wrap Select with their own stuff anyway, so maybe it's better to keep it more low-level?
I mean, the first one looks nice, but isn't it inefficient if you want just one socket? 17:52
bubaflub tadzik: i think having low-level stuff in Parrot with a sane but minimal interface is the way to go
cotto_work There's no reason to make HLLs do work that we know they'll need to do. I don't care too strongly either way though. 17:53
whiteknight pmichaud: I would be very interested to hear proposals to make it more efficient
cotto_work s/they'll need to do/will need to be done/
whiteknight I don't like the idea that we write off the whole parrot environment as one not amenable to experimentation and improvement 17:54
if anything, it should be the exact opposite. Parrot needs to be more fast-moving and more nimble, considering all the unmet needs of its users
cotto_work whiteknight: then you'll like at least a subset of what I've been thinking about. 17:55
whiteknight oooh, I like subsets
cotto_work still needs refining though, and I'm sleep-deprived atm.
tadzik if anyone could hold my hand I can dedicate some time to it now 17:56
whiteknight cotto_work: spill the beans already
dalek kudo/nom: 40fbe3e | (Martin Berends)++ | / (2 files):
[tools/test_summary.pl] add --timing option for simple benchmarking
pmichaud whiteknight: the way to make it more efficient seems to be to let hll's prototype things on their own, and then let parrot pick and choose the things that make sense to migrate into its "core" 17:58
PerlJam whiteknight: how much experimental baggage is parrot willing to carry around in master?
cotto_work I believe experimental code has yet to become a burden. 17:59
whiteknight pmichaud: I'm fine with that to a degree. There's added effort involved in moving prototypes into core, and then other HLLs can't see it until Rakudo is ready to share it, etc
If it's really the best way, fine. It isn't perfect is my only point
tewk__ select would be hard to prototype on your own. fds need to be better exposed in parrot internals so the select.pmc can get its hands on them. 18:00
whiteknight PerlJam: Quite a lot, I would think, so long as there isn't a huge price to pay. making a dynpmc in the parrot repo makes it available in parrot immediately and to all users, and doesn't affect default memory or performance overhead
and if it's marked experimental, you can tweak it to your hearts content without riling any feathers 18:01
PerlJam whiteknight: okay. (that's the answer I was hoping for :)
whiteknight of course, pmichaud does have a point about a more frequently moving dependency.
having it available in a branch in the parrot repo would allow you to keep the rest of the system stable while you just played with one thing. Merge to master only when it's ready 18:02
tadzik cotto_work: so we've decided to "just merge" select, right? 18:06
with an existing interface? 18:07
cotto_work If you think it'll be a good starting point. I'm not a fan of the current interface, but merging is fine if what's there isn't what we'll eventually call "final". 18:08
tadzik tewk__ said it's supposed to resemble IO::Select from Perl 5, and if it's fine for Perl 5 people, it should be at least a good starting point for us :) 18:09
I succesfully merged master into tewk/select, spectesting 18:11
benabik In PIR, is it possible to get/use the return continuation directly without using .return?
tadzik but! we still have two different Select pmcs. Do we want to remove the ordinary one, keeping dynpmc? 18:12
benabik (i.e. Does .return do something special that something like "$P0 = # get return context somehow; invoke $P0" doesn't?) 18:14
tewk__ cotto_work: one of the key points of the select pmc design was not having to build up lists of fds for every select call. 18:15
dukeleto benabik: there is a .tailcall(), maybe looking at what that does will tell you something useful
cotto_work tewk__: ok. That makes the design clearer.
benabik dukeleto: I can't figure out how to tell what that does. I don't know IMCC guts, so don't' knew where to look.
tadzik cotto_work, tewk__, what are we doing with the old, non-dynamic pmc? Kill it with fire? 18:16
dukeleto benabik: src/ops/core.ops defines the tailcall op
benabik Oh, it's an op. Interesting. 18:17
cotto_work tadzik: good question. I'm not sure. I suspect that someone (possibly me) forgot to delete it.
benabik dukeleto: Do we do special magic for exception handling? Since we use continuations everywhere, I somewhat just expect there to be an exception handler continuation somewhere.
tewk__ My opinion is select is as much a part of core as support for sockets is.
tadzik cotto_work: I'll remove it then 18:18
pmichaud benabik: the return continuation is available through getinterp, iirc.
benabik dukeleto: (My brain is pondering things on #perl6 about control flow and things I've read about continuation based compiler.)
tadzik is the fact that it's experimental affecting the dynamicness of it?
should it? 18:19
tewk__ I see select as part of the socket and file interface. If sockets and files are core, select should be too.
tadzik seen plobsing
aloha plobsing was last seen in #parrot 2 hours 55 mins ago saying "exactly".
tewk__ But, I'll be happy as long as something gets merged. 18:20
pmichaud benabik: $P0 = getinterp; $P1 = $P0['continuation'] # get return continuation
benabik: $P0 = getinterp; $P1 = $P0['continuation';1] # get caller's return continuation
benabik pmichaud: This is somewhat originating from yours and mls's discussion on #perl6. Shouldn't leave() and LEAVE just be a matter of mucking around with which continuations get called? 18:22
tadzik heh, the only failing test is t/pmc/select.t. But the dynpmc one is passing
benabik pmichaud: Yes, there's probably a lot of details I'm papering over with "mucking around". 18:23
pmichaud benabik: LEAVE blocks have to be invoked whenever a sub exits, *including* when a sub is abandoned due to a finalize op.
I suppose we could introduce our own version of finalize that handles the invocation of LEAVE blocks. 18:24
benabik pmichaud: I think I don't quite know how Parrot handles exceptions. I bet it's not quite how I think. 18:25
whiteknight getting access to the return continuation should be much easier 18:28
benabik whiteknight: +1 18:29
whiteknight in true CPS form, we should get rid of the .return statement entirely, and always pass the return continatuation as the first parameter to every function
pmichaud heh
dalek Heuristic branch merge: pushed 783 commits to parrot/tewk/select by tadzik
whiteknight actually, in plobsing's new inside-out-ctx branch, we should do similar to that and put it directly into a register 18:30
tadzik heh
pmichaud whiteknight: that is in fact what Parrot used to do, many years ago.
the return continuation was always in P2
benabik pmichaud: Why'd we stop?
whiteknight pmichaud: we've made many mistakes over the years. Eventually we need to correct all of them
pmichaud ...or have you been reading "Perl 6 and Parrot essentials"?
tadzik github.com/parrot/parrot/compare/m...k%2Fselect -- could someone review and possibly merge this?
pmichaud benabik: beats me -- the switch away from that was largely before my time
whiteknight we've got a lot of refactors in the pipes right now which seem abstract, but are going to lead to big improvements in these kinds of areas 18:31
pmichaud sorry, the return continuation was always in P1, not P2. (Just checked my copy of P6PE.) 18:33
benabik Control flow ops are hard to read. 18:34
Parrot seems to have an odd mix of CPS and non-CPS. 18:35
18:36 PacoLinux_ joined
atrodo Parrot seems to have an odd mix. 18:37
benabik Okay, I'm stumped. Where does finalize go?
whiteknight what the current plan is, is to reduce indirection by turning the CallContext PMC inside out. We're going to have a reference to the register frame, which is going to contain a lot of things that the CallContext was containing. Then those things will be available directly trhough symbolic registers 18:38
the return context is one of those
so you'll be able to get $Pret or something, and invoke that directly
then the ".return()" directive can go shut up somewhere
if we can be more aggressive about more people using generated code and less people writing PIR directly, we can make lots of big improvements 18:39
also, we'll be using lots of macros
benabik pmichaud: LEAVE needs to be called on return and after a exception handler handles an exception? It doesn't get called on throw? 18:40
pmichaud benabik: it can't be called on throw, because the exception might be resumed.
(in which case the intermediate blocks haven't been leaved :)
"finalize" is the way we signal "okay, we're not resuming" 18:41
NotFound I think killing macros will be a better goal. I you are generating code, just generate it, instead og generating a macro that generates the code.
whiteknight NotFound: yes, getting rid of macros in the long run will help simplify IMCC a lot
but if we're making big changes, macros can help to smooth those out
benabik pmichaud: Ah. That is difficult. You need to muck with the continuation chain of "whatever handler finalized the exception". 18:42
pmichaud rakudo's uses of finalize are in src/Perl6/Actions.pm, if you want to look. :) 18:43
essentially, we call finalize when falling out of the exception handler block
I suppose at that point we could have a custom op that finds all of the callers' LEAVE blocks and invokes them 18:44
benabik I somewhat understand exception handling in CPS and am trying to meld LEAVE with it... 18:45
Essentially, each handler has a continuation it want to call after it's handled the exception. LEAVE blocks mean you have things that need to be called before that continuation is called. Which is… odd. 18:46
pmichaud well, in general Parrot has never supported the notion of "on exit" handlers (or even "END blocks"), so it's been an ongoing challenge. :)
I don't understand your last statement. 18:47
(still trying to parse it.)
benabik I'm not sure I expressed it correctly...
whiteknight we would support them, if we could find a good way to do it
benabik And I'm somewhat talking about a more abstract idea of CPS than "what parrot does". 18:48
whiteknight CPS means we can jump all over the call graph, and there's no real way to know what on exit handlers can and cannot be called
benabik Right.
pmichaud well, that's somewhat the purpose of the finalize opcode, iiuc.
tadzik cotto_work: ping
benabik In theory, `throw Exception` is just `exception_handler(Exception)`
whiteknight for instance, contexts can still be kept alive if there is a live closure somewhere attached to it, or we can to a CPS jump to a lateral location, and don't necessarily know if we can or will return back to the caller 18:49
in practice we haven't used CPS to its fullest, and our style of code tends to be very rigid and structural, but there's no reason it needs to stay that way
benabik: more like 'find_handler_for(Exception).call_with(Exception)' 18:50
pmichaud fwiw, the p6 model is that "leave" is an operation on subs (or call contexts) 18:51
dalek rrot/tewk/select: d156fc0 | tadzik++ | src/dynpmc/select.pmc:
Fix a typo in select.pmc Pod
pmichaud i.e., when you want to exit a sub (or when the sub wants to return control to its caller), it does .leave
benabik whiteknight: I'm handwaving here… If you don't have find_handler_for, you just have each handler check to see if it wants to handle it and then call it's own handler if it doesn't want to.
pmichaud and the LEAVE block is simply a hook in which to add additional code to be executed when .leave is invoked 18:52
whiteknight pmichaud: we could support on-exit handlers if we had a leave opcode, but we would only be able to fire a single context's worth of handlers at a time, for reasons I just mentioned
so if we did an exception that went up the chain a few frames, we wouldn't be able to fire exit handlers on all intermediate frames because there's no real way to show which path you took 18:53
not without cheating, and then we break CPS
pmichaud the caller chain should have that
whiteknight if it's a simple chain. If we've used continuations and exceptions to jump around, the caller chain could be twisted up
benabik The caller chain of the resume continuation could be used, I guess... 18:54
The question becomes how do you know when to stop.
whiteknight that's if the resume continuation is only set to always be the location right after a call 18:55
if you pass in a custom continuation as your retcontinuation that points somewhere else, you could jump somewhere else on return
pmichaud the finalize opcode already has the "when to stop" logic, iiuc.
whiteknight the finalize opcode is much lower-level. It uses runloop jump points with setjmp and longjmp, etc 18:56
basically, it's for preventing inferior runloops
it might do a little bit more unwinding, but not much of it
pmichaud not for preventing them, but for making sure they get properly exited.
18:56 schmooster joined
whiteknight right, that's what I mean. preventing problems because of them 18:56
benabik finalize just jumps to somewhere. In true CPS, it's calling another continuation… In parrot it seems to be going… somewhere. 18:57
NotFound "Brutally droping" will be a more reaistic description.
pmichaud okay, so finalize isn't doing unwinding. I wasn't sure how it worked internally.
NotFound finalize discards parts of the C stack, it doesn't jump in op terms. 18:58
whiteknight the exception handler contains a runloop ID. the finalize op takes that ID, looks up the jump point for the owner runloop, and does a longjmp
benabik pmichaud: What I was saying is that in pure-CPS, each exception handler has a series of continuations: resume exception (passed to the handler via callcc or similar), it's own exception handler, and it's own return continuation (which it calls if it handles the exception). LEAVE blocks need to much with the handler's return continuation, which is somewhat awkward. 18:59
*muck 19:00
pmichaud benabik: yeah. it may be that it's something we have to implement at a HLL layer anyway.
benabik pmichaud: I think in that case, throw becomes `call/cc(handler, exception, leave)`, and if a handler handles an exception it does something like `leave(return)`. Chaining together the leave continuations is a bit tricky. 19:02
pmichaud I don't see leave blocks as being parameters to the throw. 19:03
I see them as being attributes of the sub.
cotto_work tadzik: pong 19:04
benabik pmichaud: If you don't pass it, how does the handler find it? 19:05
pmichaud the handler has to be able to see the caller chain somehow 19:06
benabik In pure CPS there is no caller chain, only continuations to call. 19:07
pmichaud well, Perl 6 isn't a pure-CPS language. :)
tadzik cotto_work: how about merging tewk/select now?
benabik But parrot is a (somewhat) CPS based VM.
NotFound We are not pure since we call C that call ops that call C...
cotto_work tadzik: be my guest
tadzik okay, fun 19:08
pmichaud benabik: then we have to figure out how to make the CPS-based VM map onto languages that don't use CPS :)
tadzik cotto_work: we'll be even then :P
benabik pmichaud: By mucking with the continuations! Which is what I've been thinking aloud about. :-D
dalek rrot: 749afc6 | tadzik++ | / (370 files):
Merge branch 'master' into tewk/select
rrot: b6fb910 | tadzik++ | / (4 files):
Regenerate MANIFESTs
rrot: d156fc0 | tadzik++ | src/dynpmc/select.pmc:
Fix a typo in select.pmc Pod
pmichaud benabik: fair enough. It's just that you're speaking in terms that I have trouble following as an HLL implementor. 19:09
tadzik removing tewk/select now
benabik pmichaud: I'm speaking in CS grad student speak. :-D
tadzik and that's it :)
benabik pmichaud: I have no idea how much this maps to "what parrot does", I'll admit.
TimToady wonders whether LEAVE is in the same category as DESTROY, and cannot actually be run until the continuation is GC'd
tadzik tewk__: success, after half a year :) 19:10
pmichaud TimToady: I hope not.
benabik TimToady: That would be another way to do it, yes.
pmichaud TimToady: I think that LEAVE is something that has to be a bit more timely.
at least, for most of the use cases that I can construct for it.
also, we often leave a block but still use some of its parts later 19:11
benabik What?
TimToady CPS is most at home with immutable semantics, where "timely" is a non-concept
pmichaud (e.g., lexicals in closures)
benabik Ah. 19:12
cotto_work a "noncept"?
pmichaud if we consider the lexicals to have a lifetime separate from that of the block, then the block can be destroyed as long as the lexical pad is still available somehow
(that is notably not the case in Parrot today, however) 19:13
TimToady indeed, the lexicals *must* outlive the LEAVE; that's what closure is all about
ttbot Parrot d156fc0b MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/45347 19:23
TimToady s/must/must be able to/ # or sounds like I'm advocating timely LEAVE :)
benabik gets very confused about runloops/interps/contexts and the relationship between them.
cotto_work looking into that failure now 19:28
NotFound benabik: the runloop depends of levels of 'parot call C that call parrot', independently of conitnuations and contexts. 19:30
The finalize opcode discards the possible nested runloops no more needed. 19:31
benabik NotFound: An interp has as many runloops as it's been called to via C code? And a context is vaguely related to continuations? 19:41
NotFound benabik: there is a stack of runloop control structures hanging from the interpreter, but the key point is the C stack associated with each nested level. 19:42
Continuations points to the context it activates when invoked. 19:44
tadzik uh-oh, Select doesn't get installed in the newest Parrot 20:10
cotto_work tadzik: it also makes win32 sad. 20:11
cotto_work cracks the whip
tadzik cotto_work: what, Select?
cotto_work tadzik: yup. I selected the whip to crack. 20:12
tadzik for now it doesn't install, and it makes Rakudo sad 20:13
okay, it makes _me_ sad
could someone with Parrot's build-system-fu make Select installedon make install? 20:15
cotto_work tadzik: just add it to manifest.GENERATED 20:16
tadzik cotto_work: thank you
cotto_work which, as you'd expect, isn't generated and needs to be edited by hand
cotto_work renames it to manifest.NOT.GENERATED 20:17
tadzik yay works 20:18
cotto_work tadzik: your next mission is to fix the windows build 20:19
tadzik /o\\
but I have no windows!
cotto_work could be tricky 20:21
whiteknight manifest.OF.GENERATED.STUFF 20:24
dalek rrot: d5c3815 | tadzik++ | MANIFEST.generated:
Add Select to MANIFEST.generated
ttbot Parrot d5c38153 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/45439 20:37
dukeleto www.modernperlbooks.com/mt/2011/08/...-code.html is pretty hilarious 20:45
dukeleto says as he wipes a single tear from his eye 20:46
cotto_work chromatic's over in #perl6 atm 20:47
or was 10 minutes ago
tadzik: I've taken a shot at fixing the Select dynpmc on windows, but I don't know the right invocation. Can you find someone who knows enough about windows to fix it? 20:54
tadzik jnthn__: ping 20:55
cotto_work heh
dalek kudo/nom: b0da692 | (Martin Berends)++ | tools/test_summary.pl:
[tools/test_summary.pl] do not count plans in fudged files, flussence++
 21:00
jnthn__ As far as I know, there's no direct select() equivalent on Windows :( 21:02
benabik Winsock appears to have a select() function, but it appears to be designed for sockets only. 21:04
pmichaud afk, lunch 21:07
cotto_work I saw "select" and assumed that it was the same thing. 21:10
benabik It appears to throw an error if an fdset contains not-a-socket. ref: msdn.microsoft.com/en-us/library/ms...s.85).aspx 21:11
jnthn__ ah, and it needs msdn.microsoft.com/en-us/library/ms...s.85).aspx 21:14
gah
winsock2.h
NotFound WaitForMultipleObject can be used, if I remember well. 21:17
cotto_work jnthn__: I'm really glad you develop on that platform. 21:18
I can't fathom why, but I won't question it. ;)
21:21 PacoLinux_ joined 21:49 Kulag joined 22:07 not_gerd joined
not_gerd I just got Parrot to build in MSYS mode 22:08
Failed 32/393 test scripts, 91.86% okay. 376/13839 subtests failed, 97.28% okay.
cotto_work not_gerd: is the Select dynpmc to blame? 22:09
not_gerd no, didn't pull in the latest changes 22:11
I'm happs it builds at all
all prior builds using MSYS were in MINGW32 mode (ie producing native Windows binaries instead of MSYS pseudo-POSIX binaries)
dalek lrskate: c158e81 | tcurtis++ | src/LALR/Generator/BuildFollowsSets.winxed:
Fix a NPA bug in follows-set building.
 22:12
lrskate/dsl: 060299f | tcurtis++ | examples/dsl.winxed:
Commit what I currently have of a grammar specification DSL.
 22:14
22:24 particle1 joined
tadzik tewk__: ISTR you were waiting for non-blocking IO in Rakudo. There you go: github.com/tadzik/IO-Select 22:24
not_gerd in MINGW32-mode, there are 54 subtest failures 22:30
had that down to <40, IIRC
I'll probably look into that later this week... 22:31
dalek lrskate: 2cdfe62 | tcurtis++ | src/LALR/Grammar.winxed:
Fix bug with grammar.rule(nonterm) where nonterm is not a nonterminal or is on the lhs of no rules.
 22:43
cotto ~~ 22:46
22:52 kid51 joined 23:09 whiteknight joined
whiteknight good evening, #parrot 23:10
tadzik good evening whiteknight 23:11
whiteknight hello tadzik 23:12
dalek sella: f3ac691 | Whiteknight++ | VERSION:
Add assert, dumper, and reflect to VERSION
 23:15
sella: 81a09c1 | Whiteknight++ | / (44 files):
make template not unstable anymore. Add and fix sevral tests for template
sella: 887ad70 | Whiteknight++ | src/template/ (2 files):
+a some class- and function-level docs, where missing
sella: cca4a96 | Whiteknight++ | rosella/data/templates/test_ (2 files):
start updating some of the standard templates
sella: 4e92acc | Whiteknight++ | VERSION:
Template is version 1
sella: d759cbb | Whiteknight++ | src/unstable/dumper/ (8 files):
cleanup the Emitter a little
sella: 8683cfe | Whiteknight++ | src/unstable/dumper/ (2 files):
fixes to dumper. Set a recursion limit. Enable the InspectAttrs dumper, but cripple it so it doesn't do infinite recursion on basic built-in types.
sella: cafab8d | Whiteknight++ | src/unstable/dumper/Dumper.winxed:
fixes to dumper. Set a recursion limit. Enable the InspectAttrs dumper, but cripple it so it doesn't do infinite recursion on basic built-in types.
sella: 108f0a7 | Whiteknight++ | src/unstable/dumper/Dumper.winxed:
refactor Dumper to be more subclassable. Add in a global dumper instance, so we don't have to build them all the time
sella: 963a20e | Whiteknight++ | src/unstable/dumper/Dumper.winxed:
small fix
tadzik good night #parrot 23:16
whiteknight goodnight, tadzik 23:17
23:19 Coke joined
dalek rrot/tt_2185: 925c6d9 | jkeenan++ | MANIFEST:
Update MANIFEST to include cut.pl.
 23:21
rrot/tt_2185: f69daba | jkeenan++ | config/gen/makefiles/root.in:
Use a Makefile variable for tools/release/.
cotto kid51++ 23:23
I had that fixed but forgot to push
dalek website: tcurtis++ | GSoC: Wrapping up, and some documentation 23:24
website: www.parrot.org/content/gsoc-wrappin...umentation
tcurtis Good evening, whiteknight. 23:25
dukeleto: pong
23:38 jsut_ joined
nopaste "kid51" at 192.168.1.3 pasted "t/dynpmc/select.t fails on Darwin as well as Windows" (25 lines) at nopaste.snit.ch/74254 23:45
kid51 This is a new error on Darwin that wasn't present before a merge today. 23:46
cotto kid51, that dynpmc was just added to master 23:54

Powered by Cro and the Raku® Programming Language.

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

Thank you!