Parrot 3.1.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: merge and extensively test gen_gc2 | Green light from lua, partcl-nqp and rakudo on gen_gc2
Set by moderator on 18 February 2011.
00:01 toei left 00:46 mtk left 00:51 mtk joined 01:33 Hackbinary left 02:29 contingencyplan left 03:14 lateau joined
dukeleto ~~ 03:16
msg cotto i think we should just keep in mind that if we have opcode lengths != 2^n, then we will need a padding algorithm like sorear described recently
aloha OK. I'll deliver the message.
cotto ~~ 03:18
oh look. a msg
;)
dukeleto, do you think individual ops will need to be aligned? 03:19
dukeleto cotto: not sure. 03:20
i see gen_gc2 was merged 03:21
cotto yup. It has been arrived.
03:28 bubaflub joined
dukeleto bubaflub: wazzup 03:31
bubaflub: i saw you were doing a bit of cardinal hacking
bubaflub dukeleto: yep, fixed some small bugs 03:32
we're up to 94.5% passing on the tests
cotto nice 03:33
I like seeing languages come back to life.
dalek rdinal: 3567995 | bubaflub++ | t/07-loops.t:
fix test because 1 evaluates to false
03:34
bubaflub could we get #cardinal in irclog.perlgeek.de? 03:35
cotto bubaflub, talk to moritz. He has an open offer for logging iirc. 03:36
bubaflub cool
seen moritz
aloha moritz was last seen in #parrot 5 hours 16 mins ago saying "tadzik: git co master :-)".
bubaflub msg moritz could you please add #cardinal to irc logging? 03:37
aloha OK. I'll deliver the message.
cotto he also apparently added full-text search recently, though I haven't played with it
bubaflub cool
i'll be back tomorrow. goodnight #parrot
03:37 bubaflub left
cotto moritz++ for being awesome 03:37
dalek rrot/m0-spec: 4e146ce | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Add some memory-related M0 ops
cotto dukeleto, mark_unused? 03:38
dukeleto cotto: yeah, pretty terrible name
cotto that seems like an M1 concern
tbf, I'm thinking of an M0-based gc, which won't be something feasible for a while 03:39
dukeleto cotto: could be, but how do we tell the GC that memory, allocated in M0, can be reclaimed?
cotto: i didn't call it mark because that is specific to a mark-sweep GC 03:40
cotto implicitly, same way we do now
dukeleto cotto: and I don't want to call it "free" because that implies the GC will free it immediately, which might not be true
cotto dukeleto, I like avoiding outright lies.
03:43 jsut_ joined 03:47 jsut left
dukeleto cotto: yes 03:48
cotto If we're using malloc, there's no getting around free at some level. If we want to be really masochistic we can use sbrk. 03:49
dukeleto cotto: if you can figure out how to reduce mark_unused to twiddling a bit vector somewhere, that is fine, but we need something like that at M0 or M1
cotto: i was assuming that the GC would take care of free'ing in M0, but perhaps we need an explicit free 03:50
cotto dukeleto, I don't see why M0 needs anything gc-specific. If we look at M0 as equivalent to C, the gc isn't an M0 concern any more than it's a C concern. 03:51
It sounds like this will be one of the first areas where we need to figure out the ffi.
dukeleto cotto: ok, i buy that 03:54
cotto: do we need a dlfunc M0 op?
cotto: i was assuming that we want M0 to be able to tell the current GC, whatever it is "i am done with this memory that was allocated" 03:55
cotto: do you want to rewrite the GC in M0? Because you will need to if M0 can't tell the GC "i am done with this" 03:56
cotto: perhaps I am understanding wrong
cotto dukeleto, why can't the gc continue to work like now, i.e. when nothing references a PMC it gets collected.
dukeleto cotto: perhaps in the future, where we have the GC written in M0, then we can remove GC-related ops from M0 03:57
cotto dukeleto, I'm comfortable with that kind of transitional op, if we can't find something better.
dukeleto cotto: sure, but there are some big wins to be able to tell the GC that you are done with memory before the end of the current scope
dalek rrot: c0c53de | jkeenan++ | t/tools/pmc2cutils/04-dump_pmc.t:
For testing, make sure we copy only .pmc files.
03:58
dukeleto cotto: perhaps that is a premature optimization, tho
cotto dukeleto, are you thinking of chromatic's temporary PMCs?
dukeleto cotto: what do you mean?
cotto Parrot_pmc_new_temporary in src/pmc.c
dukeleto cotto: hadn't seen that yet 04:00
cotto: what about system calls from M0? how do we do that?
cotto dukeleto, also an excellent question without an excellent answer (yet) 04:01
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#10337) fulltest) at 3_1_0-181-g57afed7 - Ubuntu 10.10 i386 (g++-4.5) 04:03
dukeleto cotto: hard thing is that OS syscalls are variable width
cotto: variable number of arguments, rather 04:04
cotto: so i think we will need to make them work off of registers
cotto yes
dukeleto cotto: i.e. syscall $int_for_fread_syscall
and then all arguments to fread are in registers
cotto: this reminds me a lot of asmutils, a project that I worked on in the late nineties
cotto dukeleto, I can see why. 04:05
dukeleto cotto: it was cross-platform assembly, basically had symboic names for all OS syscalls, so you don't have to go insane remembers what syscall number each OS's syscall was
dukeleto has to go out to dinner
cotto sounds rough
have a good time 04:06
dukeleto cotto: i think I may come to visit you for a lorito mini-hackathon sometime soon
cotto: think about it :)
cotto dukeleto, cool.
I'll toss it on the growing list of things I'm thinking about. 04:07
stash++ 04:17
05:02 wagle_ left 05:03 woosley joined 05:07 wagle joined
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#10345) fulltest) at 3_1_0-182-gc0c53de - Ubuntu 10.10 i386 (g++-4.5 with --optimize) 05:10
Coke is there a way to fetch and merge specific commits from upstream? 05:32
sorear git cherry-pick 05:40
dukeleto ~~ 05:47
Coke: git cherry-pick sha1 # take sha1 from some other branch and put it onto the current branch
Coke hurm. Ok. I think I can juggle the mess I've made here and use that to pick the the half dozen commits I need. Thanks. 05:48
dukeleto Coke: newer gits allow you to give multiple sha1's to git 05:49
Coke: older ones only allow one sha1 per cherry-pick 05:50
Coke: multiple sha1's to git cherry-pick, that is
Coke dukeleto: if I want to checkout a local "cleanup" branch to track origin "master", what's the voodoo? 05:51
dukeleto Coke: git checkout -b master_cleanup origin/master 05:52
Coke hurm. that gives me an error - I think I'll just export the six commits I need as patches and re-apply at this point - I have a svn-to-git conversion going on that I've pushed to github and pushed a few more commits on top of. Realized that I screwed up the author file, so I redid the conversion. Just need to tack on those commits and then do a push -force to github to overwrite the initial screwup. 05:55
dukeleto Coke: sure, git format-patch will help you 05:56
Coke aye. 05:57
dukeleto cotto: i think it is instructive to go through src/ops/core.ops and decide what should be in M0 and what shouldn't 06:01
cotto: if we don't have dlfunc and dlvar as M0 ops, how do we implement those?
cotto That wouldn't be a bad idea, but I think most of the ops are too high-level to be in M0. Better might be to figure out how they'd be implemented and if M0 is sufficient to do so. 06:02
dukeleto cotto: sure, maybe only 10% of them will be in M0, but that will guide us
cotto dukeleto, those strike me as magical, but I think there may not be a good way to avoid them.
dukeleto cotto: i just read the implementation of them, it is basically a wrapper around 3 vtable calls and some conditionals 06:03
cotto: they both require creating new PMCs
cotto: which is already pretty high-level in M0 06:04
cotto: they both seem to boil down to wrappers around ParrotLibrary_attributes 06:05
cotto I don't think that's as much a requirement of dl* as of the way we use it.
dukeleto cotto: sure, i buy that
cotto eventually it's a wrapper around Parrot_dlsym 06:06
dukeleto cotto: now that i look into it, they basically just boil down to indexing into memory and filling in some datastructures
cotto: so they don't need to be M0 ops 06:07
cotto dukeleto, M0 will need a way to load libararies or to support it indirectly
dukeleto cotto: sure, but it can be down with a sequence of M0 ops, I don't think it needs to be an opcode 06:08
s/down/done/
cotto: does "switch code segment" need to be an op? Or is that just a number in memory that can be fiddled with? 06:09
cotto: chromatic++ mentioned it in his email
cotto Yes, but one of those ops needs to amount to "load the library that that's been set up".
dukeleto cotto: i.e. a loadlib opcode?
cotto I'm thinking of code segment as being a component of the pc
there's the cs and the pc as an index into that cs 06:10
dukeleto cotto: ah, i see
cotto: well, i don't think we can get around having a "syscall" M0 op
cotto dukeleto, We'll need to make syscalls, but why not do so indirectly through C libraries? 06:11
dukeleto cotto: well, how are you going to implement fopen() in M0 ? 06:12
cotto: won't we need a general way to call any system call from M0 ? Or are you saying that we use something like dlfunc to get at them? 06:13
cotto dlfunc
dukeleto cotto: ok, if you think that will work, wfm
cotto I don't see the value in working directly with syscalls.
dukeleto cotto: so getting dlfunc or something like it is pretty important for everything else 06:14
cotto very
06:14 rurban_ joined
cotto we can cheat for as long as we can assume that M0 will be compiled down to C, but that's not a long-term strategy. 06:14
dukeleto cotto: sure. I envision many bootstrapping layers to M0 06:15
cotto me too
06:17 rurban left, rurban_ is now known as rurban
cotto and the fewer shortcuts we take, the more viable the generated/hand-rolled code will be 06:18
dukeleto cotto: well, it sounds like we should concentrate on the ops that will allow dlfunc/dlvar functionality at M0
cotto yes
dukeleto cotto: what do those look like? 06:19
cotto: do we need a register to read from memory and to assign to memory? 06:20
cotto: s/register/opcode/g
cotto you mean an arbitrary region of memory?
dukeleto cotto: yes
cotto: currently M0 only has get/set on registers 06:21
cotto: how do you copy a register into memory?
cotto It depends on our view of PMCs. 06:22
dukeleto cotto: i currently see that M0 doesn't really know what a PMC is, other than a blob of memory 06:23
cotto yes
I don't think it makes sense for M0 to know more.
dukeleto cotto: so how do you do things to that blob of memory from M0? how do you load a register into that blob of memory, or copy a chunk of that memory into a register?
cotto: atrodo++'s lorito has opcodes for those things 06:24
cotto I'm thinking about P registers as pointers to a region of memory
dukeleto cotto: interesting
cotto possibly with a fixed-size header, but I haven't gotten that far
probably not though, since that'd be magical 06:25
dukeleto cotto: kind of like treating all of our memory as an unmanagedstruct pmc?
cotto yes
dukeleto cotto: could be interesting. It unifies things a bit, which is nice. 06:26
06:26 theory left
cotto Did you have a different idea of how M0 could look at P registers? 06:26
dukeleto cotto: in your mind, how many ops are you imagining the final version of M0 having?
cotto: excluding a few useful but unnecessary debug ops in the beginning 06:27
cotto: i am thinking something less than 20
cotto I don't have a fixed number, but something in the 20-30 range.
dukeleto cotto: just wondering
cotto op polymorphism is an issue, i.e. is there a separate add for I and N 06:29
dukeleto cotto: sure, i am lumping those together 06:31
cotto dukeleto, are you thinking that the ops would know the difference? 06:32
dukeleto cotto: what if add always acts on registers and then detects which type of register was passed to it and dispatches appropriately. Is that possible? 06:33
cotto possible but magical
dukeleto cotto: yes, magical
cotto I like the idea of ops that assume their arguments are of a fixed type and relies on the generated code to be correct.
dukeleto cotto: yes, that is obviosly best for performance 06:34
cotto much nicer to jit
or so I'd think
dukeleto cotto: so we will need add_ii, add_in and add_nn
cotto I'd rather have add_i and add_n and an op to cast/convert 06:35
dukeleto cotto: i was thinking, if we just have add_* and multiply_*, we don't need subtract and divide
cotto: sure, sounds reasonable
cotto yup
negative numbers aren't *that* magical 06:36
dukeleto cotto: heh
cotto: what about a modulus opcode in M0 ? 06:37
cotto I don't want any ops that aren't commonly used
is that necessary?
dukeleto cotto: not sure. it is used as part of many algorithms 06:40
cotto: but of course can be done the long way
cotto: perhaps we can just make it a macro of some kind
cotto dukeleto, I expect that we'll use macros heavily
dukeleto puts on devils advocate uniform and beer helmet 06:41
cotto: so what about exp(), log() and pow() ?
cotto talking about the float versions? 06:42
dukeleto cotto: exp() is not that easy to implement in terms of add and multiply, but it is possible, some goes for log() and pow()
cotto: all would need both
cotto: but i can see them as macros
cotto: they don't need to be opcodes
cotto: it is such a peculiar thing. Very few things need to actually be opcodes
cotto dukeleto, it's great. 06:43
For efficiency's sake, I'm picturing production-quality interpreters that recognize patterns in generated code and optimize as possible. 06:44
after M0 et al have stabilized 06:46
dukeleto cotto: i am going to look at the Factor Language VM for which other things need to be opcodes: github.com/slavapestov/factor/tree/master/vm 06:48
cotto I feel like I need to take a month and bone up on all the languages the cool kids are using. 06:49
dukeleto cotto: github.com/slavapestov/factor/blob.../vm/vm.cpp 06:50
cotto: yeah, i played around with Factor a bit, wrote the beginning of a GSL binding for it
cotto: it is a really cool language that started as a DSL for a game
cotto: "Forth with batteries"
cotto what's special about that file? 06:51
dukeleto cotto: "Forth with an amazing runtime and collection of libraries to do anything"
cotto: it seems to be where the VM starts 06:53
cotto yup. might be a good place to start digging in
dukeleto cotto: it is a very different from parrot, but i think the vm can still give us good ideas 06:54
cotto: how do we handle threads at M0 ?
cotto: we can start fresh with threads in M0, no backcompat will be necessary 06:55
cotto I haven't given it much thought yet, apart from considering contexts to be pretty close to threads in some aspects 06:56
dukeleto cotto: i think the factor VM is bigger than M0.
cotto: M0 is amazingly simple, the more I think about it
cotto that's a huge part of the goal 06:57
dukeleto cotto: does M0 know about read/write barriers?
cotto I don't think it will. 06:58
06:58 zby_home joined
dukeleto cotto: what about bitshifting opcodes? 06:59
cotto there are a handful of those 07:00
how few do we need to be able to implement all of them?
cotto feels like he shouldn't have to look that up
and, not, or, xor, circular shift 07:06
dukeleto cotto: xor can be implemented with and/or/not 07:22
cotto I was just reading about that 07:23
we could almost pick an op
dukeleto cotto: we need a left and right shift opcode, right? 07:24
cotto I need to sleep. Please add things to the M0 spec, especially questions or conclusions.
I'd think so.
we might even do add/multiply in terms of that
'night (for real) 07:25
dukeleto cotto: ok, i will braindump a bit into the m0 spec doc
dalek rrot: 010a389 | jimmy++ | src/platform/win32/file.c:
fixed build with MingW GCC
07:35
rrot/m0-spec: daa63bf | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Clarify more M0 ops
07:37
07:38 rdesfo left
ttbot Parrot 010a3896 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/23850 07:40
Parrot 010a3896 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/23866 07:45
dalek rrot/m0-spec: e3576da | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Clarify and add more M0 ops
rrot: a8596df | jimmy++ | src/platform/win32/file.c:
only include w32api.h when it's MingW GCC
07:49
07:50 ilbot2 joined
moderator Parrot 3.1.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: merge and extensively test gen_gc2 | Green light from lua, partcl-nqp and rakudo on gen_gc2
07:59 fperrad joined 08:11 perlite left 08:13 TiMBuS left, aloha left, TiMBuS joined, woosley1 joined 08:15 aloha joined, woosley left, perlite joined 08:28 perlite left, perlite joined 08:30 TonyC left, TonyC joined 08:31 woosley1 left, woosley joined 08:33 mtk left, JimmyZ joined
tadzik morning parrots 08:36
08:38 mtk joined
tadzik whoa, cardinal passing tests? Super awesome 08:38
dalek rdinal: b43e328 | tadzik++ | t/kernel/exit.t:
Fix t/kernel/exit.t, the test should exit with 0
08:53
dukeleto tadzik: yep, bubaflub fixed some stuff 08:54
dalek rrot/m0-spec: 0bd9bbe | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Clarify description of bytecode triplets with bullets
08:55
rrot/m0-spec: b382ab0 | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Braindump some bits for cotto++
tadzik wklej.org/id/479002/ -- what kind of magic is that? 09:06
Coke the pir syntax is pretty straightforward... 09:11
sets 2 named attributes to 0.
tadzik isn't that the same attribute? Isn't the CardinalArray GC'd immediately? 09:12
Coke what array?
tadzik how self magically becomes $P0, or is it?
oh
tadzik is stupid
nvm
how does if in PIR determine whether a PMC is true? 09:39
nvm, I read more and now I know 09:40
moritz goto foo if $P0 09:43
aloha: msg bubaflub done, see irclog.perlgeek.de/cardinal/today 09:44
aloha moritz: OK. I'll deliver the message.
dalek rdinal: a658acf | tadzik++ | src/classes/Range.pir:
CardinalInteger is always true, fix comparison in Range.pir. Fixing t/range/to_s.t
10:02
rrot: 1af3689 | (Gerd Pokorra)++ | tools/dev/nci_thunk_gen.pir:
change to use new JSON-API
10:12
ttbot Parrot 1af36897 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/24005 10:14
Parrot 1af36897 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/24004
Parrot 1af36897 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/24007 10:18
dalek rrot: a37e709 | (Gerd Pokorra)++ | tools/dev/nci_thunk_gen.pir:
switched back; language not available at this point
10:23
TT #2023 created by bacek++: Improve triggering of GC in GMS. 10:31
TT #2023: trac.parrot.org/parrot/ticket/2023
10:39 JimmyZ left 10:43 jsut joined 10:48 jsut_ left, contingencyplan joined
bacek aloha, humans 10:55
Tene dukeleto: if you actually get hll smoke testing going, I'll start work on hll interop again, at least enough to write up a tech design or plan for what needs to happen. 11:01
So was eventually decided about the default gc used for parrot, compile-time settings for gc choice, etc? 11:08
nopaste "tadzik" at 192.168.1.3 pasted "What am I missing?" (23 lines) at nopaste.snit.ch/33377 11:10
bacek tadzik, erm. Try to use ['CardinalInteger'] 11:14
in :multi
(hope it will help...)
Tene, gms for next 2 weeks. Compile-time choice
tadzik bacek: :multi(['CardinalInteger'], ['CardinalInteger'])? 11:15
Tene bacek: description of the gc options in the configure help would be nice. I don't know which of the named options there is what. 11:16
tadzik bacek: there is 'infix:<' few lines up with :multi('CardinalInteger', 'CardinalInteger')
bacek Tene, "--gc=(type) Which implementation of GC to use. One of ms, ms2 or gms." It definitely can be improved. 11:19
tadzik, hmm. Let me see
tadzik bacek: I can push the code if you want to see there 11:20
bacek tadzik, are you sure you have two CardinalIntegers? 11:21
Try replace on of types with _
tadzik bacek: well, that might be CardinalInteger and Integer actually 11:22
bacek tadzik, try :multi('CardinalInteger', _) 11:23
tadzik trying
bacek: nah, same error
bacek Oookey.
Try _, _ and put debug output into sub 11:24
Just to check types
$S0 = typeof lhs 11:25
tadzik huh, still nothing
bacek mmmm...
Impassible!
nopaste "tadzik" at 192.168.1.3 pasted "impassible!" (14 lines) at nopaste.snit.ch/33381
tadzik it's in namespace [] btw 11:26
bacek current instr.: 'cardinal;CardinalRange;!to_test' pc 9213 (src/classes/String.pir:488) 11:30
"Look ma, there is some strings attached"!
Or it's just another imcc bug?
tadzik oh, why String? 11:31
nopaste "tadzik" at 192.168.1.3 pasted "A string" (24 lines) at nopaste.snit.ch/33382 11:32
bacek hmm 11:35
I'm out of ideas...
Try to put debug into !to_test to check types of pmcs
tadzik yeah, I'm gluing up some say-debugging 11:36
the problem is in "if toexc > 0 goto exclusive_test", toexc being a CardinalInteger, no strings involved 11:38
I'll push what I have and add an issue, time will tell 11:40
dalek rdinal: ad36bd0 | tadzik++ | cardinal.pir:
Add a space in the REPL prompt to improve readability
rdinal: a4f22cb | tadzik++ | src/classes/Range.pir:
Fix few more '0 is true' bugs. Fixes t/range/each.t and t/range/infix-inclusive.t
rdinal: a6a13ee | tadzik++ | t/range/to_s.t:
Add a failing test to t/range/to_s.t for exclusive Ranges
rdinal: 0b9a02b | tadzik++ | README:
Added building instructions to README
11:56
12:13 mikehh left
dalek rdinal: 8306d43 | moritz++ | t/array/values_at.t:
more descriptive test labels in values_at.t
12:33
rdinal: b748ec6 | moritz++ | / (134 files):
delete code files to bring more attention to the moving notice in README
12:35
tadzik uhm, moritz? 12:41
ah, cardinal/cardinal. Carry on :)
moritz curries on 13:08
tadzik after maybe-fixing something in the Squaak tutorial, how do I generate docs to html to see if everything's all right?
13:09 contingencyplan left
dalek TT #1401 closed by jkeenan++: t/library/pcre.t: Test #2 failing on MSWin32 13:13
TT #1401: trac.parrot.org/parrot/ticket/1401
TT #2024 created by jkeenan++: t/library/pcre.t: Not honoring '--without-pcre' configuration flag 13:29
TT #2024: trac.parrot.org/parrot/ticket/2024
13:32 mikehh joined 13:35 Eclesia joined
Eclesia hi 13:35
tadzik he Eclesia
13:35 woosley left
NotFound Proposal to definitely solve the problems of configuring and testing pcre: put it out of parrot. 14:03
14:09 kid51 joined
mikehh NotFound: in what way? 14:09
and/or use what? 14:10
NotFound We use it for anything? 14:11
If it's not needed for core, put it on its own repo and install like any other module. 14:12
plobsing doesn't nqp use it? 14:13
jnthn I'm not aware of nqp using pcre.
NotFound If parrot can be configured without-pcre, I doubt it.
plobsing I thought that differing pcre was the cause of some character-classification bugs in the NQP/Rakudo testsuite 14:14
14:14 rurban_ joined
jnthn msg bacek looks like the issue in nopaste.snit.ch/32991 is that $obj.HOW.add_method($obj, ~$!name, 14:15
aloha OK. I'll deliver the message.
jnthn gah 14:16
msg bacek ...adds the method with name like '$!foo' rather than just 'foo' :)
aloha OK. I'll deliver the message.
NotFound As far as I know, the only problems reported related with pcre are the failures of its own tests.
plobsing maybe I'm thinking of something else
jnthn plobsing: I think you're thinking of ICU.
14:17 rurban left, rurban_ is now known as rurban
NotFound ICU is *required* by rakudo these days, isn't it? 14:17
jnthn It's not a hard requirement. 14:20
But without it, you'll get rather limited unicoe support.
*unicode
dalek rrot: 818fea2 | NotFound++ | src/pmc/fixedpmcarray.pmc:
rearrange a bit fixedpmcarray mark to avoid an unsueful lack of coverage report
14:30
14:35 lateau left 14:39 nwellnhof joined
nwellnhof ~ 14:39
tadzik wave
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#10400) fulltest) at 3_1_0-186-ga37e709 - Kubuntu 10.10 amd64 (g++-4.5 with --optimize) 14:40
dalek rrot: 4783bdf | NotFound++ | t/pmc/fixedpmcarray.t:
two more FPA tests to improve coverage
14:41
nxed: r813 | NotFound++ | trunk/winxedst0.cpp:
backport three args form of indexof to stage 0
14:56
nxed: r814 | NotFound++ | trunk/winxedst1.winxed:
use predef replace instead of substr and concatenations in predef exapansion
15:01
15:22 lucian joined
dalek nxed: r815 | NotFound++ | trunk/winxedst1.winxed:
rearrang a bit CallExpr methods, no functional changes
15:23
15:24 lucian_ left 15:49 kid51 left 16:10 nwellnhof left
lucian dukeleto: i'm starting to hate dalvik's gc 16:12
your dreams of parrot domination might be less crazy than i'd thought 16:13
16:16 rdesfo joined 16:17 Patterner left, Psyche^ joined, Psyche^ is now known as Patterner 16:19 mtk left 16:21 whiteknight joined 16:25 mtk joined
mikehh t/pir/pbc_fallback_1.pbc shows up in git status as an untracked file and is not removed by make realclean (after fulltest I think) 16:45
I really haven't got time to look at it now, will do so later 16:47
afk for a bit
16:49 zby_home left
whiteknight did gen_gc2 merge to master yet? 16:53
tadzik yes 16:54
16:54 dalek left 16:56 dalek joined
dalek nxed: r816 | NotFound++ | trunk/winxedst0.cpp:
diagnose argument modifiers unsupported in stage 0
17:22
17:45 ambs joined
tadzik Method 'stdout_handle' not found for invocant of class 'ParrotInterpreter' -- says Parrot 2.9.1. Since which Parrot is this method available? 18:07
whiteknight tadzik: relatively recent
prior to that, I thnk there was an "stdhandle" method that took an integer
so stdhandle(0) would be stdout, I think
tadzik whiteknight: 2.10? I'm thinking about github.com/parrot/cardinal/issues/#issue/2 18:08
18:08 whiteknight left, theory joined, whiteknight joined
tadzik whiteknight: 2.10? I'm thinking about github.com/parrot/cardinal/issues/#issue/2 18:09
whiteknight tadzik: it's possible. 2.10, 2.11, 3.0. Somewhere in ther
there
tadzik heh
whiteknight Coke: ping 18:14
18:32 Eclesia left
dukeleto lucian: why do you hate it? 18:36
18:54 bacek left
dalek rrot: a8a97d0 | dukeleto++ | t/src/extend_vtable.t:
Fix line number reporting in extend_vtable_output_is and add a failing test for Parrot_PMC_cmp_pmc
18:58
rrot: eed152d | dukeleto++ | t/src/extend_vtable.t:
Improve Parrot_PMC_cmp_pmc test, but it still isn't passing
rrot: 0df6bf4 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_concatenate
rrot: 568d50b | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_concatenate_str
rrot: 190b188 | dukeleto++ | t/src/extend_vtable.t:
Fix Parrot_PMC_floor_divide_int test
rrot: 659a75f | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_get_iter
rrot: 3b5a8a9 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_get_namespace
dukeleto incoming
rrot: 76c8e18 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_get_pmc
rrot: 4b0725d | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_get_pointer
rrot: 6333613 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_hashvalue
18:59
rrot: 953ff8b | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_i_concatenate_str
rrot: 4858121 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_i_concatenate_str
rrot: a406b3e | dukeleto++ | t/src/extend_vtable.t:
Add coverage to thawfinish vtable
rrot: 10e6185 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_shift_pmc
rrot: 82ae832 | dukeleto++ | t/src/extend_vtable.t:
Comment out cmp_pmc test so we can merge to master
dukeleto looks like dalek's heuristic branch merge-fu failed
whiteknight awesome 19:00
dukeleto whiteknight: mornin' 19:01
whiteknight good morning, duke. how are you today?
dukeleto whiteknight: quite well. Bacon and coffee are good motivators 19:02
whiteknight: you still hacking on those imcc branches?
whiteknight: also, what is Rosella/parrot-test ?
whiteknight: i saw commits fly by but I haven't been backlogging enough to know what is up 19:03
whiteknight Rosella is a collection of small modular libraries for various things
dukeleto whiteknight: parrot-test is your solution to kakapo going stale?
whiteknight two of the libraries it implements are xunit-alike unit tests and a tap harness library
yes, basically
dukeleto whiteknight: cool!
whiteknight: those are sorely needed tools
19:04 bacek joined 19:06 cognominal left
lucian dukeleto: it's not very good in general 19:13
and on top of that, it's only optimised for low memory usage
so it's really, really, really slow
19:14 contingencyplan joined 19:15 ShaneC joined
whiteknight lucian: what are you talking about? 19:17
lucian whiteknight: dalvik's gc 19:18
whiteknight oh
dukelet: I am still working on that IMCC stuff. I had to take a little sanity break from it
but I am looking at it again today 19:19
dukeleto whiteknight: very understandable
whiteknight: which imcc-related branch is most likely to merge first?
whiteknight dukeleto: they're all really parts of the same process. I'm not going to merge it piece-wise. whiteknight/imcc_compreg_pmc is the "main" branch right now 19:20
I am going to update that branch now from master, and maybe make a new branch from it to play with exception handling 19:31
moderator Parrot 3.1.0 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Goals: ? 19:38
whiteknight goals: find hairy yak. Shave him. Post pics of result 19:38
dalek Heuristic branch merge: pushed 246 commits to parrot/whiteknight/imcc_compreg_pmc by Whiteknight 19:40
whiteknight that merge actually fixed a few test failures. I think I was having some GC-related problems in the branch 19:41
so that's inice
and it looks like I can reclaim at least one more failed test if I go back and not screw up that merge 19:45
yay me
dukeleto whiteknight++ # yak whisperer 19:49
dalek rrot: dd54b44 | dukeleto++ | t/tools/mk_language_shell.t:
[cage] Remove cargo-culting
19:51
whiteknight my thoughts about IMCC change so often. Sometimes I respect it. Sometimes...I just hate it so badly 19:57
20:01 mikehh left
dalek rrot: 4893367 | dukeleto++ | t/tools/mk_language_shell.t:
[t] Skip all tests unless parrot binary is in the build dir
20:01
dukeleto purely numeric sha1 prefix! I must be lucky. 20:02
msg cotto i found a bug in your git sha1-linking plugin. For purely numeric sha1's, it thinks it is a SVN rev: trac.parrot.org/parrot/ticket/2014#comment:1 20:04
aloha OK. I'll deliver the message.
dukeleto is gen_gc currently the default GC, or optional ? 20:11
whiteknight I think it's optional 20:14
20:18 kid51 joined
dukeleto i think the output of "parrot --help" should give the list of GC's to choose from and which is default 20:18
-g --gc ms|inf set GC type 20:19
that is what it has now, which seems out of date and not as informative as it could be
kid51: top of the mornin'
kid51 Good afternoon, dukeleto 20:20
kid51 discovers old package of coffee singles in cabinet -- needed due to broken carafe 20:22
20:23 Coke left 20:25 ambs_ joined, ambs left, ambs_ is now known as ambs
nopaste "kid51" at 192.168.1.3 pasted "Cage cleaning alert: Which of these branches are removable?" (54 lines) at nopaste.snit.ch/33422 20:25
dukeleto kid51: i just deleted tt1798_ipv6 20:28
20:29 jjore left, Coke joined
dukeleto kid51: nwellnhof has some branches that can be deleted, but since they are under nwellnhof/*, I think he should be the one to do it 20:29
kid51 Agreed
plobsing I should finish up inf/nan handling. 20:30
dukeleto plobsing: i can try to help with that. I remember giving up on some inf/nan bugs a long time ago. I should probably take another hack at it
plobsing: shall we work together?
20:32 jjore joined
plobsing dukeleto: it's not first on my priorities list. If you want to take it and run with it, feel free. I'll look at it sometime in the next 2 weeks. 20:32
The objective of the branch was to make our code work on platforms that raise exceptions on division by zero. Unfortunatly g++ hates me for some reason. 20:33
kid51 dukeleto: git ?: Why does this not DWIM? git push origin :tt1954_eliminate_make_docs 20:34
whiteknight kid51: I'll cleanup the branches with my name in them soon 20:37
kid51 whiteknight: No rush. The fact that you have your name in them means they're not abandoned.
dukeleto kid51: what is your question? 20:38
kid51: git push origin :foo deletes a remote branch. git branch -d foo to delete a local branch
kid51 I'm trying to delete a remote branch.
dukeleto kid51: git push recently learned --delete, but that requires a newish git
kid51: what error do you get? Throw me a bone. 20:39
kid51 I want to delete this remote branch (as listed in paste above):
remotes/origin/tt1954_eliminate_make_docs
dukeleto kid51: and? do you get an error? What happens? 20:40
kid51 git push origin :origin/tt1954_eliminate_make_docs
error: unable to push to unqualified destination: origin/tt1954_eliminate_make_docs
bacek Good morning, humans
kid51 The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@github.com:parrot/parrot.git'
whiteknight: but speaking of abandoned branches ... What about github.com/parrot/parrot/tree/tt389_fix? 20:41
whiteknight kid51: As far as I am concerned it can be deleted. I haven' touched it yet because chromatic once said it was worth keeping to mine ideas from
so, ask chromatic
(if you want to delete, you have my blessing) 20:42
plobsing I'd ask bacek about the bohem gc branch. IIRC that didn't pan out.
bacek jnthn, I already figured out all problems with .add_method. Check t/nqp/58-attrs.t and commit 549d447ffe217bec3afac2394ff06d79d196ac78 :)
kid51 msg chromatic Do we need to keep github.com/parrot/parrot/tree/tt389_fix in github (possibly to mine ideas from?)
aloha OK. I'll deliver the message.
bacek boehm_gc2 branch was deleted few days ago 20:43
kid51 bacek: But we're showing: remotes/origin/boehm_gc_2
bacek kid51, try "git fetch --prune"
kid51, it will delete local copies of remotely deleted branchs 20:44
kid51 error: unknown option `prune'
dukeleto kid51: git push origin :tt1954_eliminate_make_docs
bacek branches
-p, --prune
After fetching, remove any remote tracking branches which no longer
exist on the remote.
dukeleto kid51: i don't like the idea of deleting branches because we won't merge them 20:45
kid51 dukeleto: what you just suggested is what I've been trying
bacek kid51, hmm. I don't know how to do it in older git version.
dukeleto kid51: we should delete branches that have already been merged
kid51: no, you put the wrong refspec
kid51: copy and paste exactly what I just wrote
kid51: you had git push origin :origin/tt1954_eliminate_make_docs , which is wrong
kid51: this is all in git_workflow.pod 20:46
kid51 dukeleto: I copied what you pasted. I hit return. I got the same results each time.
I use your syntax everyday at $job -- so I am puzzled why it doesn't work here 20:47
dukeleto kid51: what error do you get when you copy and paste what I wrote? 20:49
kid51: surely it is not the same error as what you wrote
kid51 This is strange.
dukeleto kid51: if you did it once, then the remote branch is already deleted and you will get an error that it doesn't exist anymore
kid51: no, it makes perfect sense. 20:50
kid51 But it's something I recall encountering once before.
dukeleto kid51: perhaps you have git trolls in your computer?
kid51 The branch is no longer showing up on github.com
dukeleto kid51: because you deleted it
kid51 But it is showing up when I say: git branch -a
dukeleto kid51: git branch -d foo # delete your local branc
jnthn bacek: OK, will check it out - thanks.
20:51 mikehh joined
kid51 dukeleto: My local branch was deleted long ago. I was only concerned with the remote 20:51
dukeleto kid51: what version of git are you using? 20:52
kid51 dukeleto: What do you get when you call: git branch -a | grep 1954
dukeleto guesses 1.5.x
sorear /sb end
kid51 On this machine: git version 1.6.3.2
dukeleto kid51: git fetch --prune will remove local copies of branches that have been rm'ed from your remote, but I don't think your git has that option 20:53
kid51: don't worry to much about it.
kid51: git branches take up just about no space, not like svn branches
kid51 dukeleto: I am not concerned with removing local copies. On this machine, the only branch I have is master.
github.com says we currently have 47 branches. 20:54
dukeleto kid51: there is no more problem then :)
kid51 git branch -a | wc -l says we have 54
dukeleto kid51: your local git has knowledge of deleted branches => FUGGETABOUTIT
kid51 Even accounting for 'master' that's a discrepancy I don't understand
dukeleto kid51: don't worry.
kid51: the discrepancy is the branches that you decided to track locally that were then deleted from github by others 20:55
kid51: make sense?
kid51: git fetch --prune will clean them up, but you need to upgrade git to get that command
kid51: actually, you didn't even have to track them
kid51 Well, is there any git command I can run that will list current branches on the remote ... as I did in that paste?
dukeleto kid51: git branch -r 20:56
kid51: but that will still list the branches that you have locally that were deleted
kid51: git branch --merged will show you all already-merged branches (i.e. those that can be deleted) 20:57
kid51 To be more precise: It lists the branches that I once had locally that have been deleted on remote
dukeleto kid51: but again, you might have too old a git
kid51: it lists all remote-tracking branches
kid51 $ git branch --merged
* master
dukeleto kid51: git branch -a --merged to see remote branches that have been merged 20:58
nopaste "kid51" at 192.168.1.3 pasted "Branches on remote that have been merged (git branch -r --merged)" (8 lines) at nopaste.snit.ch/33423 20:59
20:59 ambs left
dukeleto kid51: this is what it looks like on my machine gist.github.com/836301 20:59
NotFound kid51: Have you fetched the remote?
dukeleto kid51: also, you are slightly out of date, because I already deleted tt1798
kid51: git fetch
kid51 $ git pull 21:00
Already up-to-date.
dukeleto kid51: i would email parrot-dev that list and say "these branches will be deleted, unless you respond that they should be kept alive within $unit_of_time"
21:03 ambs joined, ambs left
kid51 whiteknight: Has your call_context_reset branch indeed been merged? 21:04
whiteknight I dont remember. I have to check 21:05
21:07 benabik left
kid51 Well, don't worry about it. I don't trust the output of git branch -a --merged 21:09
dalek rrot/whiteknight/imcc_compreg_pmc: 8d4a69c | Whiteknight++ | compilers/imcc/imc (2 files):
fix checking if an input file is a directory and reclaim a few tests
rrot/whiteknight/imcc_compreg_pmc: 16d6292 | Whiteknight++ | compilers/imcc/ (5 files):
add line numbers to IMCC exceptions.

We have to rearrange some struct definitions to make this work outside of imcc.l. Fixes a few tests which were testing for the existence and correctness of line numbers in error messages
whiteknight dow to about ~40 test failures 21:10
er, coretest failures 21:11
21:11 kurahaupo joined
whiteknight codestd tests are going to be a travisty 21:11
21:12 gbacon joined
kid51 whiteknight: When you climb out of IMCC hell, can you give a look at trac.parrot.org/parrot/ticket/1948 ? Thx. 21:16
whiteknight: do you want any help on those codingstd tests in that branch? Or is it too early?
whiteknight too eary
early
kid51 eerie? 21:17
whiteknight but eventually, yes
kid51 afk 21:34
21:39 Hackbinary joined 21:49 cognominal joined 21:57 PacoLinux left 22:14 rurban_ joined 22:16 vmspb joined 22:17 rurban left, rurban_ is now known as rurban 22:22 gbacon left
bacek_at_work ~~ 22:31
cotto dukeleto, ping 22:41
msg dukeleto I don't see any problem with that link. Did you fix the code? 22:45
aloha OK. I'll deliver the message.
22:57 plobsing_ joined 23:01 plobsing left 23:06 bacek left
dalek TT #1003 closed by jkeenan++: Call an exited coroutine fails since some time 23:14
TT #1003: trac.parrot.org/parrot/ticket/1003
23:14 cosimo joined 23:18 bacek joined
Coke whiteknight: pong. 23:18
bacek_at_work who is owner of isparrotfastyet.com? 23:21
Coke atrodo, methinks.
doesn't look any faster.
dalek rdinal: 39b8a41 | bubaflub++ | t/array/slice.t:
typo acces -> access
23:23
rdinal: 1643fd2 | bubaflub++ | src/classes/Range.pir:
another range fix
23:42
23:44 bubaflub joined 23:53 fperrad left