Parrot 3.5.0 "Menelaus" released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 27 June 2011.
00:06 Kulag left, Kulag joined 00:21 kid51 joined 00:36 preflex left 00:39 preflex joined 00:42 rurban_ joined 00:44 rurban left 00:45 rurban_ is now known as rurban 00:51 davidfetter joined
whiteknight For anybody who follows python-related stuff, here's an extremely embarrassing story: www.zdnet.com/blog/violetblue/when-...oversy/509 00:52
I sincerely hope that nothing like that filters into the Parrot world
00:52 davidfetter left 01:04 daniel-s joined
soh_cah_toa eh, yeah...i'm no prude but that is a bit inappropriate 01:21
dalek rrot/soh-cah-toa/hbdb: f2c195e | soh_cah_toa++ | frontend/hbdb/main.c:
Fixed compilation of .pir files by comparing file extension against '.pbc' instead of 'pbc' and calling Parrot_api_load_bytecode_file() inside an 'else' clause (whiteknight++)
 01:36
rrot/soh-cah-toa/hbdb: c8334be | soh_cah_toa++ | / (5 files):
Defined hbdb_load_source() and its associated Parrot_api_* wrapper for loading source files into memory
rrot/soh-cah-toa/hbdb: d01a192 | soh_cah_toa++ | / (2 files):
Added initial implementation of 'list' command and defined get_cmd_argument() for parsing numerical command arguments. Also temporarily de-consted a few declarations to avoid present and future headaches.
whiteknight soh_cah_toa:
soh_cah_toa++
soh_cah_toa yeah, i'm making some headway 01:37
some
whiteknight awesome
okay, I'm off to bed. Back to work tomorrow, which I am not looking forward to
soh_cah_toa see ya 01:38
whiteknight later. Keep up the good work!
01:38 whiteknight left
dalek kudo/nom: 4336ba9 | Coke++ | t/spectest.data:
note more spectest failure modes.
 02:12
rrot-libgit2: a29694c | dukeleto++ | t/001_load.pir:
Add a test which loads git2.pbc
 02:19
02:22 kid51 left
Coke msg cotto if inspect_str can return anything... what is the point? why are attributes not sufficient? 02:34
aloha OK. I'll deliver the message.
Coke msg cotto I recommend just deprecating the whole mess and removing it, unless there's a compelling use case for HLL users. 02:35
aloha OK. I'll deliver the message.
dalek rrot: 27cc427 | util++ | PLATFORMS:
Update PLATFORMS for new gcc version
TT #840 reopened by coke++: t/op/io.t fails on win32 02:38
TT #840: trac.parrot.org/parrot/ticket/840
rrot-libgit2: 5d32e71 | dukeleto++ | t/001_load.pir:
Start a test for git_repository_open
 02:40
02:47 lichtkind left
cotto dukeleto++ 03:03
dalek rrot/soh-cah-toa/hbdb: f8d245d | soh_cah_toa++ | frontend/hbdb/main.c:
Renamed fail() to show_last_error_and_exit(). As much as I hate the name, it is more consistent with the rest of Parrot's other frontend programs.
 03:14
03:14 bubaflub joined
bubaflub ~ 03:17
msg jay great! i'll be working on generating NCI thunks soon. i'll write up some detailed docs on how exactly to do it so two of us won't have to trailblaze. 03:18
aloha OK. I'll deliver the message.
jay Still here.
Quickie: 'vppi' I assume v is void, i is integer, but p? I thought I had a page explaining it but lost track of where it was. 03:19
cotto I need to teach aloha about that.
plobsing jay: p is for pointer 03:20
cotto compilers/pct/src/PAST/Compiler.pir
jay ah. Thanks, will copy that.
dalek rrot-libgit2: e968f76 | dukeleto++ | / (3 files):
Add some tests and update the NCI file for the new dev API

This commit uses the API on the 'development' branch of libgit2, adds a test which actually gets far enough for libgit2 to core dump Parrot in git_repository_open (repo_out=0x0, path=0x13f5538 "") at /home/leto/git/libgit2/src/repository.c:347		 03:21
rrot-libgit2: d04e023 | dukeleto++ | / (5 files):
Tweak our header-reading regex and reap more function bindings
rrot-libgit2: f75cb2e | dukeleto++ | t/001_load.pir:
Correct the function signature of git_repository_open in our test
03:25 bluescreen left 03:30 simcop2387_ joined 03:31 simcop2387 left, simcop2387_ is now known as simcop2387
cotto seen mro 03:58
aloha mro was last seen in #parrot 8 hours 29 mins ago saying "cotto: okay. I'm heading out now. Have a nice day!".
dalek rrot-libgit2: 830e0fd | dukeleto++ | src/git2.winxed:
Add a stub winxed class that generates a StructView for a git_repository data structure
 04:15
rrot/m0-prototype: 436416b | mro++ | t/m0/integration/m0_ (4 files):
Add tests for M0 register ops.
 04:17
rrot/m0-prototype: c8ff7a0 | mro++ | t/m0/integration/m0_ (7 files):
Fix TAP output from M0 integration tests.
rrot/m0-prototype: e7365ae | cotto++ | t/m0/integration/m0_set_ref.m0:
remove a bit of apparently dead code
cotto msg mro I pulled your m0-test branch. Thanks!
aloha OK. I'll deliver the message.
cotto dukeleto, ping 04:27
dalek rrot-libgit2: a891178 | dukeleto++ | src/ (3 files):
Move Winxed code to a new subdir along with generated PIR
 04:29
04:34 logie joined
dukeleto cotto: pong 04:58
cotto dukeleto, I'm thinking about M0 strings. If M0 is based on words, I'm having a hard time avoiding the conclusion that strings manipulation will need to based on blocks of multiple characters. 04:59
dukeleto, not sure if there's a question in there. I'm just trying to figure out what string and character manipulation will look like in that context. 05:01
dukeleto cotto: ok. padding to the nearest word should be possible 05:02
cotto dukeleto, sure. chromatic actually suggested that at os bridge. 05:03
it'd make hashing simpler
I'm tempted to add a couple ops to deal with individual characters. 05:07
05:12 zby_home joined 05:16 fperrad joined
dalek rrot/soh-cah-toa/hbdb: 907e660 | soh_cah_toa++ | frontend/hbdb/main.c:
Moved definition of show_last_error_and_exit() to preserve alphabetical order of functions. Wrapped Parrot_api_destroy_interpreter() inside an 'if' statement. Also, cleaned up POD documentation a little bit.
 05:21
rrot/soh-cah-toa/hbdb: c99d54b | soh_cah_toa++ | / (4 files):
Added initial version of HBDB tutorial in docs/hbdb.pod. It is still in the making.
05:28 soh_cah_toa left 05:29 logie left
dalek kudo/nom: 6d53c0a | moritz++ | / (2 files):
fix chomp
 05:34
05:40 logie joined 05:50 logie left 05:54 theory left
dalek kudo/nom: b901bc0 | moritz++ | / (2 files):
implement &keys, &values, &kv, &pairs
 06:10
06:12 luben left 06:36 zby_home left 07:43 mj41 joined
dalek kudo/nom: 1bb2883 | moritz++ | / (5 files):
Hash.invert, List.end, tests
 08:08
08:42 rurban_ joined 08:44 rurban left, rurban_ is now known as rurban
dalek kudo/nom: 9d969c0 | moritz++ | / (3 files):
classify
 09:26
09:56 simcop2387_ joined 09:57 simcop2387 left, simcop2387_ is now known as simcop2387 10:25 Drossel joined
dalek kudo/nom: 1478b35 | pmichaud++ | src/core/ (2 files):
Let Parcel.values fall back to Any.values.
 10:26
10:27 Kulag left 11:32 dod joined 11:38 contingencyplan left
dalek kudo/nom: d9fcb90 | moritz++ | / (2 files):
Port Hash.push over from master

This doesn't quite work yet, running S32-hash/push.t causes infinite recursion involving some List methods - maybe something that pmichaud++ can investigate?		 11:50
kudo/nom: acda02a | moritz++ | t/spectest.data:
end.t did not pass, my mistake. Sorry.
12:19 mtk joined 12:24 JimmyZ joined 12:25 mtk left 12:31 mtk joined 12:35 bluescreen joined 12:40 whiteknight joined 12:45 ambs joined
whiteknight good morning, #parrot 12:46
12:47 Coke left 12:48 Coke joined
tadzik good morning whiteknight 12:49
12:51 JimmyZ left
whiteknight hello tadzik, how are you doing today? 12:51
tadzik pretty fine. I've just started refactoring yesterday's beast commit
12:52 JimmyZ joined
whiteknight beast commit? I'll have to take a look at that 12:53
tadzik oh, don't worry. That's just mine, and to rakudo/podparser
I officialy... well, maybe just dislike, Pod tables 12:54
whiteknight I've never been a fan of the syntax 12:55
not that there are many good alternatives
13:01 Coke left, Coke joined
whiteknight is running smoke on win64 now 13:01
okay, I've got the spawnw.t failures fixed. I'm tracking down the nci failures now 13:37
bubaflub ~
whiteknight $P0 = dlfunc <null>, "func", "sig" returns an Undef 13:39
passing in PMCNULL as the first in-arg to dlfunc doesn't seem to work on windows
13:51 logie joined
whiteknight trac.parrot.org/parrot/ticket/2148 13:51
dalek rrot: fa9e3a3 | Whiteknight++ | t/op/spawnw.t:
On windows, the path to the perl binary contains backslashes. Changes double quotes to single quotes so the backslashes don't create weird string problems. This fixes spawnw.t on windows
 13:52
13:53 PacoLinux joined
Coke pmichaud: o/ 13:54
jay ping bubaflub 13:55
bubaflub jay: pong
jay bubaflub: If I understand correctly: GMP uses various scripts to get Raw.pir, and you use libffi to get things working? You aren't using the parrot_nci_thunk_gen utility at this point? 13:56
bubaflub jay: yep, that's correct.
jay: i will eventually use parrot_nci_thunk_gen to generate all the signatures that aren't currently included with Parrot and remove the libffi dependency. but for now, it's there. 13:57
jay < phew > Thanks. I'm trying to write some docs with a concise example and discussion of these issues as I learn.
Right. I'm minimalist with dependencies. Don't like them if I can avoid them. Would rather get to a 'best practices' solution sooner rather than later. 13:58
bubaflub jay: yeah. i think libffi is good for development because it's just one less piece you have to worry about.
dalek TT #2148 created by whiteknight++: t/pmc/nci.t fails on windows
TT #2148: trac.parrot.org/parrot/ticket/2148
jay bubaflub++. Will keep you posted on progress. 13:59
bubaflub jay: great. and if i figure out parrot_nci_thunk_gen stuff i'll write up something as well 14:00
whiteknight soh_cah_toa: ping
msg soh_cah_toa t/dynoplibs/debug.t is failing on windows, and I can't figure out why. Do you have any particular insight? 14:01
aloha OK. I'll deliver the message.
14:10 perl left
dalek kudo/podparser: 597985d | tadzik++ | src/Perl6/Pod.pm:
Refactor Pod.pm
 14:24
14:29 logie left 14:34 hercynium joined 14:42 logie joined
cotto ~~ 14:49
whiteknight good morning, cotto 14:57
dukeleto ~~ 14:59
cotto hi whiteknight 15:01
dalek rrot: 2940c80 | Whiteknight++ | src/ (2 files):
On win32, if we don't have a valid library handle in Parrot_dlsym we can try to look up the module handle for 'libparrot'. This fixes t/pmc/nci.t on my system, and shouldn't make anything else any worse
 15:03
15:06 ligne joined
whiteknight hmmm... that fixes t/pmc/nci.t, but doesn't fix t/library/nciutils.t for some reason 15:12
that's disheartening
it looks like exactly the same kind of failure 15:14
cotto Could there be something hanging around that didn't get rebuilt? 15:15
whiteknight I'm doing a reclean+rebuild now 15:17
I really wish we had more devs on windows
as a linux user, I am very sympathetic to the reasons why more of our devs don't do their hacking on that platform, but I wish there were more
dukeleto whiteknight: this may be relevant: perlbuzz.com/2008/12/microsoft-will...hines.html 15:22
i am not sure if it still exists
cotto I think that's still going on. 15:24
If anyone has the tuits to use it, I know who to talk to to find out. 15:27
whiteknight I have windows at work, so I can do some limited testing stuff here
I also have a windows VM on my home computer, but I haven't set that up for hacking yet
I only use it for itunes
Although, I'm getting extremely close to blasting away my current ubuntu install, so that might take the VM with it 15:28
cotto What's wrong with it? 15:29
whiteknight The mouse stopped working correctly after a software update. I can't figure out which update caused the error, and can't get it workign right
so I'm going to try and reinstall Ubuntu 10.04, or something else that was known-good 15:30
of course, with my laptop there's always a chance it's a hardware failure too, so if the software bit fails I don't know what I will do
cotto that sounds like it might be difficult to work around
you can at least see if the same thing happens with a live cd 15:31
whiteknight yeah, that's true. I could try that
cotto those are great
whiteknight The trackpad is no longer recognized as a trackpad, so I can't turn off things like the super-sensitive tap-to-click
so if my palm gets anywhere near it while typing, bad things happen. 15:32
15:32 Kulag joined
whiteknight Also, it's very jumpy and inconsistent. Sometimes it will work fine for a stretch. Sometimes the mouse won't work at all, and sometimes when I touch it it jumps around and activates all sorts of random shortcuts 15:32
benabik That's exactly the sort of thing I use live CDs for. I'd try 10.10 and 11.04. It might be that some config got screwed up with the upgrade. 15:33
benabik doesn't trust Linux distro upgrades.
whiteknight so I go to click on a hyperlink, but the mouse stops moving, so I try again and it bounces all the way to the left side of the screen, the browser minimizes, the volume dialog opens, and I get asked if I really want to shut down my computer
benabik: I'm getting to that point myself.
I've had more hardware-related problems from routine-looking software upgrades than I care to admit 15:34
15:34 Drossel left
whiteknight Last time this happened I used a little bit of forethought and partitioned up my disk to handle just this kind of situation 15:34
so /home is on one partition that I shouldn't need to delete. I have two smaller partitions around for installing an OS on. so I should be able to install a new version of Ubuntu on the second of my smaller partitions and update grup 15:35
grub
*should*
TimToady
.oO("You have a semipredicate problem. You decide to solve it by throwing an exception. Now you have two problems.")
 15:38
whiteknight TimToady: are you referring to our conversation from last night? 15:40
TimToady yes
I would urge y'all to get out the exception-happy mindset and do something more like Go does
whiteknight yeah, not easy problems to solve
and what does go do? 15:41
TimToady exceptions don't solve the must-be-handled part, and they destroy control flow, and with it, any hope for parallelism
Go returns two values, which is clunky, but you'll notice they're really good at parallelism now 15:42
whiteknight so, to take that as our template, we would have a find_method op that returned (status, value)?
TimToady (p6 solves it a different way)
whiteknight At the PIR/PASM level, everythying is clunky and that's fine because humans shouldn't be writing it
TimToady it's one way to do it 15:43
whiteknight I'm perfectly happy with that approach, by the way. I don't like throwing exceptions from C code
atrodo how does p6 solve it? 15:45
whiteknight The idea of a dedicated Failure PMC type has been growing on me as well 15:48
although that would require some non-trivial code slinging
TimToady p6 does it by having lazy exceptions that are returned inband but are pretty easy to tell from normal 15:49
(phone)
returning an exception with fail is different from with return
whiteknight Okay right, so a Failure type could be that. It's easy to differentiate, it would contain an error message, and would have a .throw() method to convert to a real thrown exception 15:50
TimToady it's magic, but knows it needs to be handled
whiteknight We would need to differentiate Failures in most codepaths, however. We run back into the semipredicate problem if we allow set_attr_str with a Failure value
or we simply ignore that hassle and tell users to "don't do that" as hard as they can 15:51
awwaiid dukeleto: non-terminated quote error in 3rd paragraph of TPF grant update 15:53
TimToady anyway, I'm okay with anything that preserves control flow 15:56
whiteknight We're going to get to a point where we need something besides PIR to deal with all the changes we need to make to PIR 15:57
plobsing why do you need to change PIR for this? isn't it just an op change? 16:00
whiteknight depends how consistent we want to be
could be changes to many ops 16:01
plobsing so change the op(s), then bump the oplib version (that's what versions are for no?)
whiteknight deprecation policy. Can't just do that on a dime 16:02
plobsing ah
well, if you go the multi-return route, the signatures on the ops will be different and there will be no conflict in the interim period 16:03
whiteknight unless we had a way to have multiple core oplibs in a single parrot binary, and select between them at runtime
dukeleto awwaiid: danke 16:04
whiteknight that's true. We could add more op variants for this
but the thought of "more ops" really gives me chills 16:05
16:05 lkundrak left
plobsing the increase is only transitional. we'd deprecate the replaced ops. 16:05
and more ops aren't really that big of a problem 16:06
JimmyZ didn't any language follows monthly deprecation policy, since most language is unactive, except NPQ and Rakudo.
plobsing JimmyZ: the dep policy allows for HLL authors to upgrade versions at their own speed 16:07
but not making changes because HLL authors aren't ready is a recipe for stagnation
16:08 theory joined
JimmyZ plobsing: well the only HLL authors are jnthn++ and pmichaud++, anyone else now? 16:11
plobsing you forget NotFound++ and several of our gsocers 16:12
JimmyZ well, Winxed uses pir, not parrot API 16:13
dukeleto JimmyZ: and fperrad++'s Lua and Coke++'s partcl
whiteknight PIR is one of our APIs
JimmyZ partcl doesn't follow policy, and may migrate to new NQP 16:14
whiteknight: well, PRI never is in dep policy
dukeleto also, all parrot-based libraries could be affected by API changes, not just HLL's
JimmyZ: huh? have you read api.yaml ?
JimmyZ I am not saying dep policy is bad 16:15
dukeleto and we increasingly have lots more libraries, such as parrot-gmp and friends
JimmyZ: no one took it that way, but what you said definitely is confusing. what do you mean "PIR is never in dep policy" ?
JimmyZ I am say dep policy now is a more like a blocker.
whiteknight yes 16:16
deprecation policy is a blocker
benabik Depreciation slows the pace of change. That's somewhat the point.
dukeleto seemingly, it is *meant* to be a blocker.
JimmyZ It's useful in the near future, but now it's as usefule as you want 16:17
dukeleto benabik: indeed. It makes the pace of internal development slow enough that our users have a chance of keeping up
whiteknight: more feedback on whiteknight.github.com/2011/07/07/p...inues.html
benabik And with git, we can maintain branches where we do catastrophic changes without injuring our users.
dukeleto whiteknight: near init_top, some code formatting junk
JimmyZ yes, deprecation policy is useful in the near future, but now it's not as usefule as you guys want
whiteknight fuz 16:18
dukeleto whiteknight: and you have a 3. ??? where is seemingly shouldn't be
plobsing JimmyZ: it isn't perfect, but we need some framework for managing changes. unmanaged changes tend to be unpleasant.
dukeleto whiteknight: also, i really like $P0 = load_bytecode "foo.pbc" # NEW version (GOOD) 16:19
whiteknight: what does that do when foo.pbc can't be found?
whiteknight: i hate that currently load_bytecode silently fails
whiteknight dukeleto: At the moment, I think it's an exception
16:20 mj41_nb joined
dukeleto mj41_nb: howdy 16:20
whiteknight I could change it to return PMCNULL or something similar
dukeleto whiteknight: anything is better than silent failure
JimmyZ: we have refactored our dep policy before (from 6 to 3 months), so if you have suggestions for improving it, please let us know 16:21
JimmyZ dukeleto: yes, I know that :)
dukeleto JimmyZ: just reminding you :)
JimmyZ reads irclog everyday 16:23
dalek p: 5335b5b | jonathan++ | src/pmc/sixmodelobject.pmc:
Fix to make sure --trace=1 output is more useful (pmichaud++ for noticing the issue).
 16:24
Coke "partcl doesn't follow policy" excuse me?
dukeleto gets popcorn 16:25
JimmyZ: i think there may have been some "lost in translation" regarding what you meant about partcl
benabik I'm noticing in PIRate that there's some commentary on the difficulty of loading generated bytecode? Has that changed? bacek just wrote the packfile to a tempfile. Is there a way to load it into the interp immediately now? 16:26
dukeleto benabik: have you read whiteknight.github.com/2011/07/07/p...inues.html ?
JimmyZ dukeleto: well, that's most because of my poor english :)
dukeleto benabik: seems like that stuff just changed a bit, for the better
benabik dukeleto: It's in my reading list...
dukeleto: I never quite caught up after YAPC, so I'm a few days behind in my articles. 16:27
dukeleto JimmyZ: yes. I am trying to make sure no one feels offended. Can you explain more about what you meant by that? Coke would appreciate it.
whiteknight it hasn't changed yet. I haven't merged my latest branch
I'm waiting till after 3.6 release
benabik whiteknight++
Coke I'm not offended, btw. I'm just very confused. ;)
dukeleto docs with no examples make me angry, case in point src/pmc/structview.pmc 16:31
JimmyZ I love lua, and tcl, though I didn't use them much or at all. so I'd say partcl doesn't follow policy, just because it's unactive recently 16:32
benabik whiteknight: It looks like a PIR example continues after the code block stops. `init_top:`
JimmyZ s/so//g 16:33
16:35 mj41_nb left, mj41 left
plobsing dukeleto: what are tests but examples by another name? 16:35
dalek rrot-libgit2: 061f14f | dukeleto++ | / (2 files):
Attempt to initialize our StructView for git_repository correctly and add winxed->pbc to makefile
 16:37
dukeleto plobsing: for me and you and parrot core devs, yes. But the argument does not hold water for "real" end-users
plobsing: also, reading t/pmc/structview.t did not enlightenment as much as I wanted
plobsing: i currently have github.com/letolabs/parrot-libgit2...mon.winxed 16:38
16:39 JimmyZ left, ambs left, ambs joined
cotto_work ~~ 16:39
dukeleto plobsing: and I want to create a structview for this: github.com/libgit2/libgit2/blob/de...tory.h#L27
plobsing: can you please give me some guidance? 16:40
whiteknight benabik: fixed. Thanks 16:41
Coke partcl-nqp isn't failing any new tests. 16:42
plobsing dukeleto: it should be telling you it doesn't know how to handle the 'struct' element type. which it does not.
StructView does not magically support nesting
16:42 rurban_ joined
plobsing to support nested structs, you can either inline them, or represent them as buffers 16:43
Coke and neither is partcl-old. 16:44
dukeleto plobsing: ok. is there an example of "represent them as buffers" ? Inlining is fine for now, but I don't quite know what you mean about buffers
Coke (and man does the old partcl seem to be faster than the nqp-rx one. :(
so, \\o/ - it's been months since I tested that, and nothing major has broken.
16:44 rurban left 16:45 rurban_ is now known as rurban
whiteknight that's a good sign 16:45
Coke: how long are you planning to have both? 16:46
Coke setting up benchmarking is hard, but partcl's speed has always been bad.
plobsing dukeleto: there is no example of buffers currently, but its use is documented in src/pmc/structview.pmc.
Coke whiteknight: the plan was: until the -nqp version could do everything the PIR version could.
plobsing and the use is similar to other types
Coke ... which is probably never, given that nqp-rx is now obsolete. 16:47
whiteknight Coke: okay, so how far away is that milestone?
is nqp-rx obsolete? We're not getting rid of it or anything
Coke so, next step: get partcl-nqp running on nqp (not nqp-rx), or on perl6 itself.
whiteknight: given that perl6 is moving to nqp, I can't see we're going to keep it long term.
whiteknight Coke: maybe not. Depends what we need from it. If we decide to keep it around as a Parrot-run system language, it could hang around for a while 16:48
it doesn't conflict with newer NQP, there's no reason we can't have both
Coke (though we still have TGE/PGE, so who can say. I'm not sure why we still need so many toolsets)
atrodo So many, very similar, toolsets 16:49
Coke whiteknight: why? because we only have so many support tuits, mainly.
NotFound Benchmarkig is hard, let's go shopping!
whiteknight Coke: We have TGE/PGE because people still use them. They hardly eat up any support tuits
Breaking lua because we don't like the code but aren't really supporting it is hardly worthwhile 16:50
Coke anyway, hacking on partcl hasn't been fun in ages. I can't imagine any serious work on that front until the tools (and parrot) settle down and get faster.
(and provide better debug and profiling support)
benabik whiteknight: After using it for a bit, I don't see much value in NQP as a system language. It spends a decent amount of time enforcing Perlesque semantics on top of Parrot, which many people don't need. 16:52
whiteknight benabik: that's always sort of been my impression too. Too much perl semantics, not enough parrot semantics
Coke ... or if something catches my eye.
whiteknight That's why I do all my hacking now in Winxed
Coke Given how perl5-ish parrot has tried to be, that's amusing to me. ;) 16:53
atrodo whiteknight> winxed is a much better fit
Coke but, I can't see writing everything yet again in winxed, either.
whiteknight Parrot doesn't try to be perl5-ish anymore. In fact, we're doing our damndest to deprecate and remove everything from those times
benabik Does winxed store variables in registers? And how does it handle lexicals?
whiteknight benabik: yes and well
it doesn't have the built-in parser functionality that nqp has 16:54
Coke does winxed have .hll support?
whiteknight yes
plobsing wrote an o-meta port for winxed. I assume that is still working well
Coke (Given that I need regexes, I think I'll still with nqp of some variety.)
plobsing dukeleto: the jist of representing nested structs as buffers is that StructView supports opaque nested objects (when provided with size and alignment specification). Access is performed through PtrBuf PMCs. Getting returns a PtrBuf to the buffer region, setting performs a memcpy. 16:55
benabik winxed.org needs some updating... It should point at github instead of code.google and a link to whiteknight++ intro stuff would be handy.
plobsing whiteknight: it may need some fixups, but, like winxed, it is very flexible and hard to break.
NotFound The .hll support needs some care, is almost unuseful right now. 17:00
dalek kudo/nom: 6849c6f | jonathan++ | src/core/ (2 files):
Implement nextwith and lastcall.
NotFound benabik: there was some problem in the server, I think they used an old backup to restore it. 17:01
I can't fix it yet, it seems that my ssh key is not restored.
benabik NotFound: Ah. Fair enough.
Hmmmm... server backups. That might be a good idea. >.> <.< 17:02
NotFound Lexicals: it now allows string, int an float lexicals, following recent parrot changes. 17:03
whiteknight once we get 6model and native attribute types, I think many things will become a lot faster 17:04
that is certainly going to require some PIR op additions to leverage it 17:05
dukeleto NotFound: how do you feel about making the winxed.org site something that everyone in the parrot github org can edit and improve? 17:06
17:07 mj41_nb joined, mj41 joined
atrodo cotto_work> ping 17:08
NotFound dukeleto: that server is shared and I use for free, I can't put much load on it. 17:09
cotto_work atrodo: pong
whiteknight NotFound: You can create a webpage on github pages, and forward the winxed.org domain there 17:10
NotFound Yes, but if I spend time administering wikis ot the lke, less time for winxed itself. 17:12
atrodo cotto_work> I'm thinking more about how m0 will affect, and wanted to pick you brain a little since it's a little blurry to me
cotto_work atrodo: how M0 will affect what? 17:13
atrodo yea, had a hard time explaining that...
basically, once m0 is "complete", how will it be integrated into parrot
cotto_work That's something that I've been meaning to blog about for a while. 17:14
atrodo ( since i don't have time for hacking, i end up thinking)
whiteknight cotto_work: please do
cotto_work I also came up with a new batch of M0 issues to work on. Tonight is looking to be a good night for M0 hacking. 17:16
atrodo cotto_work> how much of parrot will be compiled to m0? the runcore? PMCs? All of the C code? 17:17
cotto_work atrodo: as much as we can convert
17:18 darbelo joined
cotto_work I expect C code to become the minority. 17:18
atrodo initially or eventually?
cotto_work eventually
atrodo what about initially then? There will be a time when there will be m0 and C at the same time, or not?
or do you mean "compile c to m0" by convert? 17:19
cotto_work atrodo: yes. That's part of what needs to be planned.
(C + M0 living together)
I don't anticipate compiling C to M0.
atrodo And that's the part that I'm having a hard time conceptualizing, the C + m0 odd couple 17:20
cotto_work It'll require some hackery. 17:21
whiteknight The runcore probably has to remain in C. That's the thing that runs the M0 17:23
After that, it's actually not too hard conceptually to make the switch
There are probably going to be some very big chunks we will want to do as atomic wholes: PMCs for instance might benefit from doing the whole shebang at once 17:24
cotto_work A self-hosted runcore would be tricky.
benabik M0 runcore, GC, some FFI stuff?
whiteknight tricky and no apparent benefit
cotto_work yes
benabik: that's about the extent of it, assuming you include ops as part of the runcore 17:25
whiteknight PIR ops probably need to be rewritten in M0 first, I would imagine
to avoid the need for two runcores
benabik cotto_work: Since M0 has a static set of ops, I would. :-)
I imagine there'd be some level of OS abstraction in C as well. Seems easier to do at that level. 17:26
atrodo whiteknight> That's actually the easier part, thanks to bacek++ work on ops2c_llvm
whiteknight atrodo: yes, I don't suspect it will be hard, only that it should be done early and in one big swoop
atrodo whiteknight> It's the rest of the C code that is core to parrot, not even considering PMCs 17:27
cotto_work I want to plan around avoiding big monolithic changes.
whiteknight cotto_work: I'm not sure how you're going to be able to in some places
cotto_work whiteknight: where possible
whiteknight PIR ops being the big example of something that needs to be done at once. Core PMC types likewise 17:28
atrodo whiteknight> Actually, I would think that PMCs would be doable piece-wise, but that's a gut feeling
whiteknight I don't know how we're going to handle PMC types which are written in M0 trying to coexist with PMCs written in C.
atrodo: Something like VTABLE_foo needs to know how to dispatch itself. If there's not a common dispatch mechanism, we need to insert decision logic there 17:29
atrodo Well, that is part of the whole issue tho
whiteknight If you convert all PIR ops and all PMCs to M0 in one big go, you'll have a much better idea of what to do next. Things that call C -> VTABLE will be causing some of the most obvious slowdowns, so those things can be rewritten first. PCC is probably a good example of something to do early 17:31
PCC would be a hell of a lot easier to convert if I can do those refactors I am talking about, because then all op processing happens in PIR anyway and there will be nothing to be converted 17:32
If we do that refactor first, I think a lot of things actually get much easier
atrodo whiteknight> That's a lot of code to convert in one swoop, and I'd be concerned about timeline
whiteknight atrodo: It is a lot, but if you do those big pieces bit by bit, the intermediate results are going to be unmanagably slow because of an increased number of context switches 17:33
Unless the M0 runloop machinery becomes a hell of a lot less expensive 17:34
In any case, I cant imagine any of this work is mergable into master early on. A lot of it is going to have to be done in branches until we reach a point that is both stable and performant enough to be mergable
Maybe migrating the PIR ops would be a good starting point. That could be done and merged into master pretty quick because it doesn't fundamentally change the abstraction layer or the number of context switches 17:36
atrodo whiteknight> And that's why i'm trying to pick brains. I can't see how having pre-lorito and post-lorito code can live in parallel
cotto_work The first step is to figure out how to make M0 and C interact sanely.
whiteknight but I'm starting to get the feeling like IMCC is going to be a huge impediment
atrodo whiteknight> You may not have seen this: gist.github.com/1062861
whiteknight atrodo: nice 17:37
atrodo it's mostly bacek++ code to parse the C, I just wrote the code to output lasm
karma bacek 17:38
aloha bacek has karma of 1674.
whiteknight cotto: We may want a macroized preparser like ops2c. We could have M0 code fragments inlined into C source code files with something like M0_BEGIN/M0_END. Precompile M0 into C, then compile like normal
once we have entire files converted, we remove the macros and change the file extension, and built it entirely through the M0 assembler
jnthn__ Anyone know offhand if Parrot does :call_sig on the caller side, or just callee? 17:40
dukeleto i see m0 being a long-lived git branch that will not be merged to master for a long-while, until the most basic parts of parrot internals are all m0bified
jnthn__: my gut tells me everything is done callee side, but i don't have evidence
jnthn__ dukeleto: no no :)
dukeleto: The option is potentially valid on both sides :) 17:41
dukeleto: On the callee side as in "just give me the call sig"
(that certainly works since Rakudo relies on it)
And on the caller side as "just use this as the sig"
dukeleto jnthn__: i misunderstood your question
jnthn__ no worries
I kinda asked badly :) 17:42
Aww, it parses it but ignores it 17:43
atrodo cotto_work, whiteknight> take for instance get_params_pc ( github.com/parrot/parrot/blob/mast...e.ops#L467 ) 17:46
That uses several core parrot calls and conventions and raises a few questions. For instance, in a M0 world, how does it handle fill_params?
whiteknight jnthn__: I don't believe it is implemented on the caller side 17:47
I think it's only implemented on callee right now
I could probably fix that pretty quick. I'll play around with it in a branch tonight and see what comes of it
17:48 fivetonsflax joined
whiteknight well, I could add the ability. Adding the syntax to IMCC is always the more tricky beast 17:49
jnthn__ whiteknight: It's already parsed 17:50
whiteknight: So it may not be so bad.
whiteknight: I'm not going to block on it, but I could probably also use it :) 17:51
whiteknight jnthn__: I'm planning to fix up a lot of PCC stuff eventually, and that will definitely be a big part of the refactors if it doesn't happen before that 17:52
basically, I'm planning a new invokecc op which takes a preassembled CallContext op as an additional argument, and a new getcontext op which retrieves the CallContext op without going through fill_params, for custom processing 17:53
then, if everything goes my way, I'm planning to rip out everything that isn't what I just mentioned :)
dalek kudo/nom: da00ab7 | moritz++ | / (2 files):
Str.lines
 17:58
17:59 dmalcolm joined 18:03 zby_home joined
whiteknight jnthn__: that refactor should be a performance win for Rakudo, since you do all your own processing right now anyway. We should be able to cut down significantly on the number of constants in your packfiles and improve call performance 18:04
jnthn__ whiteknight: Sound good. :) 18:07
whiteknight: At some point I'll refactor our processing to resolve lexical names to register numbers and get faster binds too. 18:08
whiteknight "our" = Rakudo's?
18:08 zby_home left
jnthn__ whiteknight: yes 18:09
whiteknight are those capabilities which can be backported into Parrot?
faster binds is nice for everybody, even if not everybody makes use of it
jnthn__ whiteknight: I think Parrot already does bind directly into registers.
whiteknight oh, Rakudo doesn't use Parrot's lexicals implementation?
jnthn__ whiteknight: It does, but not as optimally as it could in this case. 18:10
whiteknight okay
jnthn__ whiteknight: It doesn't show up high in the profiles at the moment really. But every little helps.
whiteknight: What does show up in my profiles these days is that HLL map is *slow*.
whiteknight: In nom and nqp we hll map Lexpad.
whiteknight yeah, I always assumed that wasn't an optimal codepath 18:11
jnthn__ whiteknight: So that slowness hits every time we invoke something
It'd be better if HLL map just had an array
Right now it's a hash, but I dunno why
We only have 70 or so built-in PMCs and it's one array per HLL
whiteknight urg, I would really like to have a lot fewer built-in PMC types 18:12
but that's neither here nor there
jnthn__ Well, I was guessing at the number 18:13
whiteknight either way, I know it's too many
jnthn__ But the point is we don't win anything by it being a hash, and we lose plenty.
whiteknight okay, so let's make the change
jnthn__ Generally, anything that improves Sub invocation is helpful though.
whiteknight it's just a hash idx -> idx, right? No names involved?
jnthn__ That's one of the things we bottleneck on a load. 18:14
Right, it's a hash mapping ints to ints
whiteknight it seems like that's the kind of thing we could cache somewhere
jnthn__ But we know those ints like in the range 0 < x < PMCs
*lie
So an array is fine, and far faster
whiteknight if only C had efficient closures. 18:15
18:16 contingencyplan joined
NotFound whiteknight: note that there are several unused functions in pcc, deleting them will mean less things to fix/change 18:19
tapir2.ro.vutbr.cz/cover/cover-resu...rgs-c.html 18:22
18:28 mj41_nb left
whiteknight NotFound: I'm not sure if all those can be removed. Some of them look useful for extensions 18:28
NotFound whiteknight: then they need tests. 18:29
whiteknight no argument
18:33 Eclesia joined
Eclesia hi 18:33
dalek kudo/nom: 3d5e16b | jonathan++ | src/ (4 files):
Implement nextsame and callsame.
 18:44
18:54 lucian joined
nopaste "NotFound" at 192.168.1.3 pasted "patch: use a FixedIntegerArray for HLL map" (60 lines) at nopaste.snit.ch/59611 18:59
NotFound This pass all tests
whiteknight NotFound++ 19:01
jnthn__ nice
whiteknight I don't think we should merge that before the release. Create a branch for it for testing
NotFound whiteknight: I suck at benchmarking, and even more with HLLs
whiteknight NotFound: just create that branch. Other people will benchmark and test it 19:02
NotFound Every time I create a branch, Shiva kills a dinosaur. 19:04
whiteknight You've created many branches, I guess. I don't see many Dinosaurs left
Eclesia *save dinosaurs, cut branchs* 19:05
dukeleto NotFound: that is svn branch, not git branch, right? 19:07
19:07 soh_cah_toa joined
NotFound dukeleto: don't know, haven't learned enough theology. 19:07
dukeleto NotFound: also, a test for that patch would be awesomesauce
NotFound dukeleto: What kinf of test? 19:08
I hope we already have tests for hll mapping
dukeleto NotFound: a test that covers that code 19:09
NotFound: we might, but we might not for that PMC 19:10
NotFound dukeleto: I don't understand. If HLL map works, that code is necesarily used. 19:12
dukeleto NotFound: "if hll map works", does that mean the code works 19:13
and is tested? or just that it works?
NotFound: it would be interesting to see the coverage output of that patch 19:14
NotFound You guys ask too much for a quick test. 19:17
whiteknight :) 19:18
just create a branch! We'll do the rest!
19:18 SHODAN joined
dukeleto NotFound: no good deed goes unpunished ;) Thanks for the patch. 19:21
NotFound: if you create a branch for it, we can take care of the rest, as whiteknight++ says. 19:22
NotFound That's better :) 19:24
dukeleto Seems like everybody and their grandma has a LOLCODE interpreter code.google.com/p/mailchimp-lolcode-interpreter/
* POOPONIT! - analogous to PHP's var_dump() for variable inspection
wow.
dalek rrot/hllmap_fixed: fd7880a | NotFound++ | src/hll.c:
use a FixedIntegerArray instead of a Hash for HLL mappings

the array is created when the first HLLmap is done		 19:28
dukeleto NotFound: it would be interesting to use the GCC compile farm to run tests or code coverage for a list of specified branches 19:29
NotFound dukeleto: in all tests I've done the speed of the farm machines is less than awesome, we should be careful with automated usages. 19:31
dukeleto NotFound: which machines are you using?
NotFound: some of them have 32 cores or more
NotFound: but yes, some of them are dog-slow
NotFound dukeleto: I'm mostly interested in the architectures less available. But you're right, we can use the more powerful ones for that kind of tasks. 19:32
whiteknight right now, the "architectures less available" includes Windows 19:37
it would be nice if we could get more hackage on that platform
NotFound The only windows machine I have available is an old laptop with XP home. I've done some fixes in it on the past, but is not exactly my favorite sport. 19:38
whiteknight yeah, same. I have a windows XP home VM on my laptop. I can fire it up but it doesn't have much power 19:39
and I have to install git on it, compilers, etc
NotFound Specially considering that when someone does a fix with Strawberry, people complain that it fails with VC++ or something. 19:40
whiteknight right
I'm bummed that my fix to NCI this morning didn't fix all the nciutils.t tests
I can't figure out why, and that's bugging me
NotFound I wonder: Why people want to be buildable with VC++ if they aren't unable to do even a minimal fix on it? 19:41
whiteknight Well, that's a good question. Some of these windows test failures have been around for a while. We're looking at two releases at least where they would have been a problem 19:42
so the question is, is Windows/VC++ still able to be listed as a "supported" platform? Can we support it? 19:43
without a platform champion, it's hard to say that we really need to keep kicking the horse over it
NotFound The only usefulnes I see is that ttbot quickly shows ugly old C violations. 19:46
Coke note one of the 2 primary rakudo developers is using windows. 19:47
NotFound Coke: with VC++?
Coke believe so. 19:49
whiteknight a person who might be willing to jump in and save the day before a release is different from a "platform champion" 19:52
Coke we need to support it. if we don't have someone on the team, we need to advertise for a volunteer. 19:55
It used to be particle, but i think he quit. 19:56
whiteknight I can do a limited amount of testing and fixing. I'm sure jnthn__ could do the same in a pinch. If we need more than that, and we clearly do, we need another person 19:57
dalek kudo/nom: 68a64d7 | moritz++ | t/spectest.data:
more passing test files
nxed/include_2: 2f249e5 | NotFound++ | / (3 files):
Merge branch 'include' into include_2
 20:00
nxed: 2f249e5 | NotFound++ | / (3 files):
Merge branch 'include' into include_2
 20:03
20:06 whiteknight left
dalek nxed: 68b0302 | NotFound++ | winxedst1.winxed:
oops... set utf8 encoding on included files
 20:09
jay I just upgraded from 3.3.0 to the master branch (I think) and my HLL built and tested, no problem. 20:10
dalek kudo/nom: 0056aeb | jonathan++ | src/Perl6/SymbolTable.pm:
Avoid breaking encapsulation of Code objects in SymbolTable.pm.
 20:13
kudo/nom: 6c57fa9 | jonathan++ | src/ (5 files):
Finish up (hopefully) dispatcher for multis, so we can [next|call][same|with] over those too. Makes the sub case work, which never did in master.
20:25 hercynium left
cotto_work ~~ 20:26
jay NCI: recall I had trouble with a function call to a shared library with a non-trivial signature. After upgrading my libffi and upgrading from 3.3.0 to the current, the same code (previously failing) now works. Thanks, whoever, for that fix. 20:30
dalek nxed: 8d4f28d | NotFound++ | pir/winxed_compiler.pir:
update installable compiler
 20:31
20:33 lichtkind joined
lucian should write a blog post about not doing much work ... 20:35
Eclesia Victory . made the "HelloWorld" example working for Eria : nopaste.snit.ch/59666 20:37
Eclesia ... in three weeks :x ...
NotFound Eclesia++ 20:39
Eclesia I have the felling I reinvented the pct tools ... parser, token, pir binding, past tree lol 20:41
NotFound dukeleto++ final grant update 20:43
dalek rrot: f359882 | NotFound++ | ext/winxed/compiler.pir:
update winxed snapshot:

  * builtins are now looked up as ordinary functions
  * $include		 20:46
20:49 Eclesia left
dukeleto NotFound: thanks. time to write more grants! 20:53
20:59 logie left 21:04 logie joined 21:05 simcop2387 left 21:09 nnunley left 21:10 ambs left 21:14 simcop2387 joined
Coke dukeleto: speaking of grants, can you point at a code coverage run for me? 21:19
Ah: tapir2.ro.vutbr.cz/cover/latest-c_c...api-c.html 21:20
cotto_work unsurprisingly, the code that NotFound++ modified has test coverage, apart from a few error conditions 21:22
aloha: coverage?
aloha cotto_work: coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
Coke I thought fd7880aa6706fca4fd2d2a716827081d92f99a98 was not going to make it into this release? 21:23
(notfound's hll FIA instead of Hash patch) 21:24
NotFound Coke: is a branch
parrot/hllmap_fixed 21:25
Coke blargh. looking at the URL for the commit, is the branch it's on listed anywhere?
The commit looks reasonable, anyway. sorry about my confusion about where it landed! 21:26
21:27 fperrad left
NotFound whithenight and dukeleto said "We'll do the rest!", ask them ;) 21:27
cotto_work Coke: no. It's listed in the message to parrot-commits, but not on the page since there's not necessarily a one-to-one mapping between commits and branches.
NotFound Coke: is supposed to be an optimization, so there is no point in merging it before benmarching confirm (or denies) the intuition. 21:29
I'm not chromatic, I can't give you numbers with 3 decimals. 21:31
cotto_work First question: Do we have a benchmark that exercises hllmaps heavily enough to show a change? 21:32
I don't think there's one in Parrot's tests.
jnthn__ cotto_work: nom and nqp HLL-map LexPad, but I guess you're thinking a Parrot benchmark. 21:33
cotto_work: The HLL mapping of LexPad was showing up as more expensive than I'd have expected in the profiling results I was looking at.
21:34 simcop2387_ joined, particle1 joined 21:36 particle left
cotto_work jnthn__: can you recommend a benchmark, or will any long-running nqp code show an change? 21:36
21:36 simcop2387 left, simcop2387_ is now known as simcop2387
jnthn__ cotto_work: Just something invocation heavy. 21:37
cotto_work: 6guts.wordpress.com/2011/06/28/anot...om-update/ - the integer one here 21:38
21:38 Kulag left, Kulag joined
jnthn__ That's the one I profiled a bunch 21:38
Eventually we'll optimize away a lot of the calls, but at the moment we do a bunch.
21:39 perlite_ joined
cotto_work jnthn__: sounds like a plan 21:42
or enough of one to work with
21:42 perlite left, perlite_ is now known as perlite, Psyche^ joined 21:43 mj41 left 21:46 Kulag left, hercynium joined, Kulag joined 21:47 Patterner left, Psyche^ is now known as Patterner 21:50 SHODAN left 22:00 bluescreen left 22:04 whiteknight joined
whiteknight good afternoon, #parrot 22:07
bubaflub afternoon whiteknight 22:08
darbelo o/ 22:17
cotto_work (4340513910-4252558577)/4340513910 22:24
aloha 0.0202638062735756
cotto_work That's the result of my terribly unscientific testing of the impact of NotFound's patch on one of the snippets of Perl 6 from jnthn's blog post. 22:25
modest improvement, nothing amazing
but 2% for a straightforward change is definitely worthwhile 22:26
22:27 lucian left
jnthn__ cotto_work: 2% is around what I was expecting. 22:32
22:32 kid51 joined
jnthn__ cotto_work: That we spent 2% of runtime deciding what lexpad to create is kinda scary :) 22:32
That's not even creating it :)
cotto_work jnthn__: not the best use of time 22:33
thanks for the suggestion
jnthn++
jnthn__ It kinda stood out in the profile.
Sub's invoke v-table is a real hotpath generally
Anything that helps us in there is gonna be good overall 22:34
This was just the most obvious saving.
dalek nxed: dfd1b7d | NotFound++ | winxed (2 files):
fix the checking for include file not open
cotto_work jnthn__: is it worth running spectest_regression on Rakudo nom to make sure that the branch doesn't have any unintended side-effects? 22:38
jnthn__ You can (though it's just "spectest" these days)
Though I suspect it's highly unlikely there'll be any
dalek rrot: 1794255 | NotFound++ | ext/winxed/compiler.pir:
Update winxed snapshot to dfd1b7d222:
 22:39
cotto_work Me too, but I don't like surprises.
dalek nxed: 420d3d2 | NotFound++ | pir/winxed_compiler.pir:
update installable compiler
tracwiki: v80 | tadzik++ | ParrotQuotes 22:40
tracwiki: trac.parrot.org/parrot/wiki/ParrotQ...ction=diff
tadzik SCNR :) 22:41
NotFound Yesterday I was wondering with an idea: Parrot_ext_call can check if the pmc to invoke is a NativePCCMethod and take a shortcut avoiding to create a context in that case. 22:43
Don't know if the difference will be noticeable
whiteknight NotFound: if the check is cheap enough, it should be fine 22:46
NativePCCMethod and NCI too
cotto_work tadzik++ #that page hasn't been getting enough love lately.
NotFound The check itself is cheap, but the shorcut is to copy around ren of lines from call/args.c 22:48
s/ren/ten
cotto_work I wonder if we could get another .5% by poking into the FIA
whiteknight what FIA? 22:50
cotto_work the one that notfound added in his branch 22:54
kid51 whiteknight: Is smolder.parrot.org/app/projects/rep...ails/17429 your most recent smolder on Windows? 22:55
whiteknight kid51: it is my most recent smolder. I have since fixed t/pmc/nci.t
I didn't smolder after that
kid51 Would you be able to smolder that? 22:56
whiteknight tomorrow morning I can
kid51: what time are you planning to cut the release?
kid51 okay. Your report has the fewest number of failing files, so getting fewer failures there is probably as good as we can do. 22:57
release: Next week!
But since I don't have a Win32 box, I need to rely on the kindness of strangers with Windows boxes. 22:58
whiteknight oh shoot. I thought the release was tomorrow 23:00
I really should learn how to read a calendar
dalek kudo/podparser: 06f1c95 | tadzik++ | src/Perl6/ (3 files):
Get rid of table_row_notempty insanity
 23:01
whiteknight I'll take a look at it tomorrow morning too 23:02
nopaste "NotFound" at 192.168.1.3 pasted "patch: shortcut in Parrot_ext_call" (31 lines) at nopaste.snit.ch/59745 23:04
NotFound whiteknight: here is
whiteknight yeah, that's what I was thinking about
NotFound Pass all tests 23:05
whiteknight nice 23:07
cotto_work (4340513910-4233745181)/4340513910 23:10
aloha 0.024598176901131
cotto_work about .4% by poking into the FIA directly 23:11
NotFound I think it were more lines when I tested yesterday, but I lost it by mistake. This new attempts is a bit shorter :?
NM, I always get confused when poking around PCC 23:13
cotto_work: comparing with master, or with the branch? 23:14
cotto_work NotFound: it's a ~2.5% improvement over master and about .4% over branch 23:17
NotFound Ah, yes, I see now. 23:18
cotto_work (4340513910-4233376894)/4340513910
aloha 0.0246830256097486
cotto_work (different run)
23:24 kid51 is now known as kid51_at_dinner
dalek Heuristic branch merge: pushed 203 commits to parrot/nqp_pct by Benabik 23:24
whiteknight holycrap 23:28
benabik Merge with master.
master ran ahead of me before and during YAPC 23:29
23:33 hercynium left 23:34 dmalcolm left, darbelo left, darbelo joined
whiteknight did the vtable_substr branch merge? 23:49
I can't remember
yes, I think it did. Deleting it
23:49 daniel-s left 23:50 daniel-s joined
benabik whiteknight: `git branch --contains origin/vtable_substr` says "master" 23:50
whiteknight yeah 23:51

Powered by Cro and the Raku® Programming Language.

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

Thank you!