Camelia, the Perl 6 bug

IRC log for #parrot, 2010-06-07

Parrot | source cross referenced

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:37 Coke bacek++ #fixing coretest
00:37 Coke is everyone seeing the passing TODO on the packfile test? (I am seeing it pass on ubuntu)
00:38 GeJ let me check.
00:40 GeJ t/pmc/packfile.t ....................
00:40 GeJ not ok 34 # TODO
00:40 Coke GeJ: what's your platform?
00:40 GeJ FreeBSD 7
00:40 Coke Linux halfpint 2.6.31-15-generic #50moblin5-Ubuntu SMP Mon Dec 14 16:04:27 UTC 2009 i686 GNU/Linux
00:43 bacek_at_work Coke, just mark packfile test as skipped.
00:46 dalek rakudo: 5219aa5 | (Solomon Foster)++ | src/core/ (4 files):
00:46 dalek rakudo: Move Int.Bool to Real.Bool, tweak definition of Rat.Bool, remove Num.Bool.
00:46 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/5​219aa5d8f2ae52407122719f05c4f19a6bf3357
00:47 GeJ Coke: x86 or x64?
00:52 Coke bacek_at_work: I don't like skipping tests. =-)
00:53 bacek_at_work Coke, I wrote this test. It was "wishful thinking" for really portable bytecode.
00:53 Coke GeJ: excellent question. =-)
00:53 Coke how can I tell?
00:55 mikehh Coke: I only get the TODO passing on Ubuntu i386 - it does not on amd64
00:55 Coke mikehh, gej - i think my uname would say _64 if it were 64 bit.
00:57 mikehh Coke - uname -a -> Linux mhb-desktop 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64 GNU/Linux
01:33 kid51 joined #parrot
01:34 kid51 coke: the passing TODO on the packfile test has been passing on Linux for >1 month -- but it has never passed on Darwin
01:34 kid51 so TODO is still the appropriate status for it.
01:40 kid51 seen dukeleto
01:40 purl dukeleto was last seen on #parrot 2 days, 7 hours, 20 minutes and 39 seconds ago, saying: Parrot could get funding via running on RTEMS. Parrot on RTEMS opens up many, many doors.  [Jun  4 18:19:32 2010]
01:43 Andy joined #parrot
01:45 Coke kid51: clearly it's not the appropriate status on /my/ platform. =-)
02:20 dukeleto msg kid51 looking for me?
02:20 purl Message for kid51 stored.
02:23 Coke ARGH. the dell notebook I got came with some netbookOS (moblin) that is apparently already end of lifed. =-)
02:26 dalek rakudo: a1193fe | (Solomon Foster)++ | src/core/ (2 files):
02:26 dalek rakudo: Generic version of infix:<%> for Real, and change the generic infix:<%> to
02:26 dalek rakudo: change to Numeric and redispatch to infix:<%> again.
02:26 purl dalek: that doesn't look right
02:26 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/a​1193feb206f966c2d13f50fab5cc0b5eb400d30
02:38 abqar joined #parrot
03:13 janus joined #parrot
03:18 davidfetter joined #parrot
04:33 pmichaud exit
04:33 pmichaud ww
04:34 * Coke ditches ubuntu moblin for ubuntu netbook.
04:42 Coke pmichaud: you about?
04:43 Coke (quick reboot)
05:17 fperrad joined #parrot
05:21 fperrad_ joined #parrot
05:27 aukjan joined #parrot
05:32 fperrad_ joined #parrot
06:02 uniejo joined #parrot
06:52 Coke getting a lot of failures in t/pmc/io.t
07:01 cotto none here
07:06 Coke this with a fresh build on ubuntu 10.04
07:07 aukjan joined #parrot
07:07 cotto I'll retry
07:08 Coke r47434
07:11 cotto optimized or non?
07:18 bacek_at_work coretest isn't fully fixed
07:19 cotto no failures with a clean build
07:32 bacek_at_work cotto, make corevm/coretest
07:32 bacek_at_work after realclean
07:32 purl after realclean is all ok
07:32 bacek_at_work purl, forget after realclean
07:32 purl bacek_at_work: I forgot after realclean
07:33 sorear never trust clean targets
07:33 sorear svn st --no-ignore is your frient
07:33 sorear eqv. git clean -dnx
07:44 aukjan joined #parrot
08:02 particle1 joined #parrot
08:35 particle joined #parrot
08:49 jjore joined #parrot
09:01 eternaleye joined #parrot
09:13 clinton joined #parrot
09:35 szabgabx joined #parrot
09:52 bacek aloha, humans
09:56 lucian joined #parrot
10:00 JimmyZ joined #parrot
11:04 mats joined #parrot
11:17 ruoso joined #parrot
11:27 mats hello =) I'm curious if it'll be possible (though perhaps not sane) to somehow run Parrot on the web via Javascript... or perhaps one day use it as a universal cross-compiler (e.g. if people founds ways to map PASTs back to various languages)?
11:28 moritz actually pmichaud demonstrated a POST -> LOLCODE translator, which ran ruby on lolcode, or so
11:53 whiteknight joined #parrot
11:53 khairul joined #parrot
11:54 whiteknight good morning, #parrot
12:06 tetragon joined #parrot
12:44 bluescreen joined #parrot
12:47 JimmyZ joined #parrot
12:49 JimmyZ hmm? Topic is none?
12:50 moritz JimmyZ: looks fine here
12:50 moritz might be netsplit issues
12:50 Topic for #parrotis now Parrot 2.4.0 "Sulfur Crest" Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | GSOC Students: trac.parrot.org/parrot/wiki/GSoCersStartHere
12:50 moritz JimmyZ: better?
12:50 JimmyZ yes, I see it now.
12:50 JimmyZ thanks.
13:03 bluescreen joined #parrot
13:08 khairul joined #parrot
13:09 atrodo joined #parrot
13:42 dalek rakudo: 6f0d81a | (Solomon Foster)++ | src/ (2 files):
13:42 dalek rakudo: Initial implementation of infix:<mod>.  In the long run, should maybe be in
13:42 dalek rakudo: Integral (Integer?) instead of Real.
13:42 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/6​f0d81a913f85f4b920cd38014b6bf6bed9c88ac
13:42 davidfetter joined #parrot
13:53 plobsing joined #parrot
14:03 PacoLinux joined #parrot
14:05 gbacon joined #parrot
14:18 Andy joined #parrot
14:24 ash_ joined #parrot
14:30 hudnix joined #parrot
14:37 ash_ is there a document that goes over PMC macro style guides?
14:42 bubaflub joined #parrot
14:45 patspam joined #parrot
14:51 cognominal joined #parrot
14:54 dmalcolm joined #parrot
14:58 whiteknight ash_: not really. Certainly nothing up to date
14:59 ash_ hmm okay, i won't worry about that for now
14:59 whiteknight ash_: Probably something we could drum up quick if you needed it
15:02 ash_ i'll get it working, thenworry about matching the styles
15:13 Ryan52 joined #parrot
15:14 Myhrlin joined #parrot
15:26 whiteknight ash_++
15:37 ash_ whiteknight: how are the various array objects stored in memory? like, for instance, if something in NCI takes a pointer to an array of ints, is like the resizable int array an array of ints? (internally somewhere)
15:38 ash_ i think i might have to make some new basic types for the nci to work easily
15:38 whiteknight ash_: yes, currently the array types are stored as contiguous blocks of memory
15:38 ash_ hmm, but thats INTVAL right?
15:38 whiteknight yes
15:38 ash_ you can't say "make it shorts" or something
15:38 whiteknight ash_: If you're interested in testing/prototyping new PMC types for this kind of stuff, check out the parrot-data-structures project
15:39 ash_ link?
15:39 purl link is dead
15:39 whiteknight ash_: no, can't make it short, at least not in current Parrot
15:39 whiteknight parrot-data-structures?
15:39 purl rumour has it parrot-data-structures is http://github.com/Whitekni​ght/parrot-data-structures
15:39 ash_ cool thanks
15:40 whiteknight no problem. You can have a commit bit there if you want to play around at all. It has some framework for testing and benchmarking that you might find useful in your travels
15:40 whiteknight I've intended that project to be a kind of prototyping area where cool new things might eventually be moved to parrot core, if they're good enough
15:41 ash_ i think i will need to make some sort of geneic approach, so you can make basic types nci supports (uint8_t, sint8_t, etc.), then arrays for those (probably of fixed sizes)
15:41 whiteknight also, Parrot core might be getting rid of all it's various array types, so that might be a standard add-on package to add this kind of functionality
15:41 NotFound whiteknight: Typo? =item* Sparce Array
15:41 whiteknight NotFound: probably lots of typos
15:41 mikehh_ joined #parrot
15:41 whiteknight NotFound: I'm bad at POD
15:41 ash_ there is structure support already, but i'd like to do others too
15:42 NotFound whiteknight: sure, but in a =item looks a bit worse ;)
15:45 ash_ i think it would be cool if you could say like, $P0 = 'data_type'("*i[8]") , or something, and that ends up being more or less int *a = malloc(sizeof(int) * 8); and lets you maybe do $P0[0] = 1... etc.
15:45 whiteknight ash_: There's no reason you can't do that. You could either pass an integer or a sting type name and parse it
15:46 mikehh opbots, names
15:46 ash_ whiteknight: well my point was more that current data types don't do that, right?
15:46 whiteknight ash_: something like "new ['RawArray'], 'uint32'" would either create a single new raw array with that size element, or act like a factory to instantiate the correct type"
15:46 whiteknight no
15:46 NotFound An alternative can be implementing an interface like that to ManagedStruct
15:47 ash_ can a ManagedStruct do that?
15:47 ash_ make an array of say 8 ints?
15:47 whiteknight maybe, but probably not as elegantly
15:47 whiteknight I don't like ManagedStruct anyway
15:48 ash_ RawArray seems like an appropriately generic way to do it
15:48 NotFound Is not my favourite thing, but it works.
15:49 ash_ although i'd add a size argument personally
15:50 ash_ I also want to make a helper for making [Un]ManagedStruct's with my signature parser, so you could say "(iqd*f)" and get a struct like: struct { int a; long long b; double c; float* d }
15:51 ash_ Since ManagedStruct seems to work, a helper function like that would just make it more usable
15:52 NotFound ash_: that will be very useful.
15:52 whiteknight ash_: if we had JIT that would work very well. Otherwise it will be a huge pain in the ass to handle things like field offsets and alignments and things
15:53 whiteknight not that GSoC students should be immune from pains in the ass, I'm just making an observation :)
15:53 NotFound Good point.
15:54 ash_ I already had that speced, for how i planned to implement all of that (alignments an things like that)
15:55 NotFound ash_: take a look at the .sub get_event_struct un examples/nci/Xlib.pir
15:55 ash_ i am not exactly sure what you meant by your last statement whiteknight
15:55 whiteknight nothing. It's safe to ignore me most of the time
15:58 ash_ NotFound: have you seen my current target system for signature parsing? (which seems to me to be generic enough for making a parser for making structs)
15:59 NotFound ash_: no, I just read some talk about it.
16:00 ash_ http://gist.github.com/412727 is a gist of it, in theory, you could make that struct example a lot shorter (and hopefully with as much power to specify things)
16:01 NotFound The Xlib Event is a royal pain in the ass because isn't a struct but a union of several overlapping struct types.
16:01 ash_ I was planning on doing unions too
16:02 ash_ i|d would be a union { int; double}
16:02 NotFound That code is just an approximation for the few event types actually used.
16:02 ash_ do you have a link to the C defintiion?
16:03 ash_ I found it, nevermind
16:03 NotFound ash_: sure, the Xlib Programming Manual, a +700 pages book ;)
16:03 ash_ http://tronche.com/gui/x/x​lib/events/structures.html seems to be it
16:03 ash_ (i assume)
16:04 NotFound Yes, but the Event struct uses other Xlib types and structs.
16:04 ash_ yeah, thats umm going to be fun to make sure thats right, but in theory that should be possible given my current definitions, it might be a very long thing to parse, but that looks like its in the relm of possibility
16:05 ash_ Unions are another thing i need to make a PMC for
16:05 NotFound ash_: other point that the current NCI system doesn't handle is the charset/encoding for strings.
16:06 ash_ i don't either really... strings for nci are actually just pointers in most cases
16:07 NotFound ash_: a 't' isn't just a pointer,
16:08 ash_ for me, t is the same a *c which is really just char* (or if your really technical, its implemented as sint8_t *, in libffi )
16:09 NotFound ash_: yes, by "doesn't handle" I mean exactly that.
16:09 ash_ if you need something else, like 16 bit wide stuff, you have to do *s
16:19 theory joined #parrot
16:22 darbelo joined #parrot
16:24 hercynium joined #parrot
17:45 lucian_ joined #parrot
17:48 cotto_work good marooning
17:49 dalek parrot: r47435 | NotFound++ | trunk (2 files):
17:49 dalek parrot: delete do-nothing mark, simplify coverage and add tests to StringBuilder PMC
17:49 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47435/
17:51 darbelo o/
18:01 whiteknight good morning, cotto_work
18:06 dalek parrot: r47436 | darbelo++ | branches/gsoc_nfg (365 files):
18:06 dalek parrot: Sync with trunk.
18:06 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47436/
18:24 ruoso joined #parrot
18:33 lucian joined #parrot
18:35 dduncan joined #parrot
18:36 cotto_work seeing the t/pmc/io.t failures when running coretest after realclean/configure
18:37 dduncan left #parrot
18:51 Coke are dynops still building with corevm?
18:51 Coke or was that re-re-disabled?
18:51 whiteknight un-de-disabled?
18:51 cotto_work looks like no
18:51 cotto_work not built, that is
18:52 cotto_work which seems to be causing the failures
18:53 cotto_work all happy after running make, so confirmed
18:56 darbelo I guess now is not the time to push for using separate harnesses for test vs coretest?
18:57 Coke darbelo: what do you mean, separat harnesses?
18:57 Coke like, t/harnessA, t/harnessB ?
18:58 darbelo Kind of, yes.
18:58 Coke how would that help?
18:58 darbelo It's all for dogfooding purposes.
18:58 Coke I don't think we want to eat our own dogfood on coretest.
18:59 Coke is that your point? that we could on test?
18:59 darbelo Yep.
19:00 darbelo We have our own TAP consumer now. I'd like to see it exercised a bit more.
19:02 darbelo We're not there yet, but I would like to see t/harness.pir become the default for 'make test'
19:04 particle darbelo: i expect that post-lorito
19:04 darbelo The file is there now :)
19:05 particle there are much higher priorities, and lorito will force us or enable us to make the transition more easily
19:06 darbelo I can live with that.
19:08 davidfetter joined #parrot
19:15 cotto_work joined #parrot
19:21 whiteknight darbelo: any reason why t/harness.pir can't be part of an optional test target, like "make test-pir"?
19:21 darbelo Not that I know of, but it's fperrad's code. I'd ask him.
19:24 whiteknight it seems like that would be the first part of the transition: have a make target and maybe add it to fulltest
19:24 whiteknight that way we're getting at least a monthly run
19:25 darbelo Adding it to fulltest seems redundant to me. It'll just run the same stuff again.
19:25 whiteknight fulltest is almost completely redundant
19:25 darbelo And fulltest takes long enough now, thank you very much.
19:25 whiteknight bah. It's shorter now that we've removed the extra cores
19:26 cotto_work We just shortened it considerably.
19:26 darbelo Let's not bloat it again for no good reason ;)
19:26 cotto_work how many tests are we talking about?
19:27 darbelo Technically, none. It's a new harness.
19:27 whiteknight if you want something to get run, we add it to a test target. If we don't run it, we won't ever make it a standard part of the build
19:28 darbelo whiteknight: It's not a 'part of the build', it's a test harness.
19:28 whiteknight darbelo: call it whatever you want. "make test" is a standard part of what we do, and what we tell users to do
19:29 whiteknight for lack of a better work, I'm calling the whole process the "build"
19:30 darbelo My point is that 'testing' the harness by having the other harnesss call it and have it run everything all over again is a waste of time. It tells you nothing new and takes twice as long.
19:30 whiteknight darbelo: I never said to have it test everything again
19:30 whiteknight we can run a small subset, but we do need to give the harness some exercise
19:30 whiteknight the harness needs to be tested too
19:31 darbelo We don't test our current harness at all.  The libraries behind the harness are a different thing altogether, but the harness itslef? I really don't know how to test that.
19:34 whiteknight darbelo: you take a set of simple tests that you expect to pass/fail, run the harness, verify you get the correct result out
19:34 whiteknight then, run the harness over a subset of tests that the regular harness runs, and verify that they agree on the outcome
19:38 dalek rakudo: b258f5c | (Stéphane Payrard)++ | src/Perl6/Actions.pm:
19:38 dalek rakudo: Awesommify error message for $:a in signature
19:38 dalek rakudo: Signed-off-by: Moritz Lenz <moritz@faui2k3.org>
19:38 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​258f5cc1633c4aa5035a3e5ba4c4dd076d50ee2
19:38 cotto_work yo dawg?
19:38 cotto_work purl, yo dawg?
19:38 purl wish i knew, cotto_work
19:38 cotto_work yo dawg is http://qntm.org/responsibility
19:38 cotto_work purl, yo dawg?
19:38 purl well, yo dawg is http://qntm.org/responsibility
19:39 cotto_work not nearly as annoying as the typical xzibit macro
19:46 dalek parrot: r47437 | darbelo++ | branches/gsoc_nfg/src/string/grapheme.c:
19:46 dalek parrot: Fix non-icu builds and add svn props.
19:46 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47437/
19:53 tcurtis joined #parrot
19:55 cognominal joined #parrot
20:01 ash_ what is ARGIN used for?
20:01 ash_ the C macro
20:02 cotto_work argument annotations
20:03 PerlJam ash_: IIRC ARGIN is an "input only" argument.  you're promising that it won't be used otherwise.
20:03 Psyche^ joined #parrot
20:03 dalek parrot: r47438 | tcurtis++ | branches/gsoc_past_optimization (422 files):
20:03 dalek parrot: Sync with trunk.
20:03 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47438/
20:04 bluescreen joined #parrot
20:04 ash_ found a doc talking about it, i'll read over that
20:23 cotto_work ash_, you can also look at include/parrot/compiler.h to see what they translate to
20:24 ash_ __in i assume is a gcc compiler directive?
20:25 ash_ reading the source of some things doesn't always de-mystify them
20:25 ash_ thanks though, :P i'll see if i can figure them out
20:26 cotto_work not sure.  You'll probably have to dig a bit.
20:26 cotto_work np
20:26 GeJ Good morning everyone.
20:28 cotto_work hio GeJ
20:29 * cotto_work needs to make a bot named "hio"
20:36 darbelo Hey, where did aloha go?
20:36 moritz probably to hawaii
20:43 cotto_work it got in a fight with purl
20:44 GeJ servus cotto.
20:57 darbelo ash_: most __-prefixed things are safe to assume as compiler magic related.
20:57 ash_ yeah
20:57 ash_ __in is actually MS compiler specific, it adds some compile time warnings if you do certain things to the variable
20:58 dalek website: tcurtis++ | The Last Week and a Half in PAST Optimization
20:58 dalek website: http://www.parrot.org/content/las​t-week-and-half-past-optimization
20:58 ash_ i found documentation for it
21:01 bacek aloha, humans
21:01 aloha joined #parrot
21:01 darbelo aloha, aloha
21:01 darbelo aloha, bacek
21:02 bacek aloha, darbelo
21:03 dalek tracwiki: v5 | jrtayloriv++ | HLL%20Resources
21:03 dalek tracwiki: Add references to introductory materials on writing HLL compilers
21:03 dalek tracwiki: http://trac.parrot.org/parrot/wiki/HLL​%20Resources?version=5&amp;action=diff
21:07 cotto_work aloha, cotto_work
21:07 cotto_work wait.  I did that wrong.
21:09 dalek parrot: r47439 | darbelo++ | branches/gsoc_nfg/src/string (3 files):
21:09 dalek parrot: Make various parts of codetest happy again.
21:09 dalek parrot: review: http://trac.parrot.org/parrot/changeset/47439/
21:10 lucian_ joined #parrot
21:32 mikehh bacek: gc_massacre has build problem with g++ last time I tried, gcc builds (slowly)
21:33 whiteknight joined #parrot
21:34 mikehh bacek: do you want a nopaste of the error(s)
21:35 clinton joined #parrot
21:35 bacek mikehh, I know about them...
21:36 mikehh bacek: 'k
21:36 bacek ms2 gc requires some deep tuning.
21:38 mikehh bacek: you did not seem too happy with the linked list implementation
21:38 bacek mikehh, yeah. It's slower than I expected.
21:39 bacek And TriColour mark doesn't make sense without Incremental prefix.
21:40 bacek But for Incremental part it will require a lot of effort to implement it.
21:46 whiteknight TriColour doesn't make sense without the incremental part, but it's not impossible to have it
21:46 whiteknight You could create the tricolor algorithm first, and later insert incremental breaks
21:48 bacek whiteknight, not so easy. You have to have way to grey-out already marked objects.
21:49 whiteknight bacek: that's a small piece. It's just a different flag, or a different set of flags, or a different linked list
21:49 whiteknight mark the item, move it grey, mark it's children, mark it black
21:50 bacek whiteknight, it's exact algorithm in src/gc/gc_tms.c
21:51 bacek Actually I think we can avoid remarking objects in parrot.
21:51 bacek All our live objects referenced by CallContext registers anyway
21:52 szabgabx joined #parrot
21:54 mikehh mikehh: so anything not referenced in CallContext registers is dead?
21:55 mikehh that was weird should be:
21:55 bacek mikehh, almost. There is interp with roots. And little bit on stack. But we mark them anyway
21:56 mikehh baceK: the problem with multiple interp?
21:56 bacek mikehh, nope.
22:07 NotFound bacek: take a look at my comment on TT #1659
22:08 theory joined #parrot
22:08 bacek NotFound, nope. Actually impatient_pmcs counter is usually wrong.
22:09 NotFound bacek: don't know, but if the object is marked, it will fail anyway.
22:10 bacek NotFound, GC just stop in lazy mode too early.
22:10 chromatic joined #parrot
22:11 chromatic Working register lifetime analysis could be a big GC improvement.
22:11 NotFound bacek: that doesn't explain the effect of adding the sub call. It works even if you add it before nulling the regiser.
22:12 bacek NotFound, "hash seed problem". It's just destroyed objects in different order.
22:12 bacek chromatic, aloha!
22:13 chromatic aloha
22:14 darbelo left #parrot
22:14 darbelo joined #parrot
22:15 NotFound bacek: What objects?
22:15 purl Objection noted.  Proceed.
22:15 bacek NotFound, pmcs
22:18 sorear darbelo: *all* __ prefixed things are "compiler" magical, for values of "compiler" that include OS and libc (which are regarded as compiler implementation details in C89)
22:19 darbelo C89 can regard what it wants as a compiler implementation detail, so long as I can disagree.
22:23 NotFound bacek: the FileHandle is not destroyed, even if you add a lot more sweeps. Is destroyed in different order because is alive even after nulling the register,
22:23 kid51 joined #parrot
22:25 NotFound darbelo: the better way to disagree with a language is to not use it.
22:26 bacek NotFound, hmm... Looks like it's marked alive...
22:27 NotFound bacek: is alive because it remains in the context signature. Is a known problem.
22:27 NotFound Or feature, maybe ;)
22:29 chromatic It'd be nice to find a simple solution--even in part--to that problem soon.
22:30 NotFound chromatic: last time I looked at this problem, I find a test that depends on it. Let me remember...
22:31 kid51 make coretest situation unchanged from yesterday:  failures in t/pmc/io.t : http://smolder.plusthree.com/ap​p/projects/report_details/34247
22:42 kid51 make test PASS http://smolder.plusthree.com/ap​p/projects/report_details/34248
22:43 kid51 r47439
22:45 NotFound Oh, nice, now if I make a minor mistake in an op I must revert and rebuild parrot to be able to bootstrap ops :(
22:46 cotto_work you can just revert src/ops/core_ops.c and anything in include to get a usable parrot again
22:46 cotto_work but yes, it can be a pain
22:47 NotFound A big pain. We need a way to use an out-of-tree nqp if we want some agility.
22:48 cotto_work what do you mean by out-of-gree nqp?  We include enough of nqp-rx from pmichaud's github repo to get a useful pbc and update that pretty frequently.
22:49 cotto_work compilers/nqp is gone
22:49 NotFound cotto_work: a parrot with nqp already built in another tree, or installed.
22:51 darbelo nqp-rx can be installed 'independently' already.
22:51 darbelo But that needs an installed parrot, so.
22:51 darbelo ..
22:54 cotto_work unix toolbox?
22:54 cotto_work unix toolbox is http://cb.vu/unixtoolbox.xhtml
22:54 cotto_work unix toolbox is
22:55 cotto_work unix toolbox?
22:55 purl unix toolbox is http://cb.vu/unixtoolbox.xhtml
22:55 cotto_work epic win there for any aspiring *nix geeks
22:56 NotFound Several tests use the same args for two consecutive sub calls, so the simpler solution of clearing the context signature in get_results doesn't work.
22:58 senf_statt_oel joined #parrot
22:59 NotFound It also chokes on code that uses get_results before callmethodcc. Is this still supported?
23:00 NotFound chromatic: ping
23:01 chromatic pong, NotFound
23:02 NotFound chromatic: the problem is fixed by adding Parrot_pcc_set_signature(interp, CURRENT_CONTEXT(interp), PMCNULL); in get_results, but a few tests fail with that change.
23:02 chromatic Continuation and coroutine tests?
23:03 NotFound chromatic: no, use of invoke with the same set_args two times.
23:03 NotFound In t/op/calling.t ...
23:03 NotFound and t/pmc/eval.t
23:04 tetragon joined #parrot
23:04 chromatic Which line in t/op/calling.t
23:04 NotFound And also a test in t/pmc/objects.t that uses get_results before callmethodcc
23:05 chromatic That latter *must* be wrong.
23:05 NotFound Failed test 'named - 5 slurpy array -> named'
23:05 NotFound at t/op/calling.t line 1852
23:05 chromatic get_results shouldn't be there since the last PCC refactor.
23:06 NotFound Failed test 'call 2 subs in evaled code 'at t/pmc/eval.t line 58.
23:06 NotFound chromatic: is has zero args, probably it got unnoticed because of that.
23:07 chromatic t/pmc/eval.t works if I move get_results to after invokecc.
23:07 chromatic ... but that's obviously without your change in place.
23:07 chromatic If all of the failures are of that type, we can fix the tests.
23:08 davidfetter left #parrot
23:08 davidfetter joined #parrot
23:08 davidfetter oops
23:08 davidfetter mis-/part'ed
23:08 NotFound chromatic: yes, but I don't know if some HLL may be using that... feature?
23:08 chromatic We deprecated it.
23:09 NotFound chromatic: Move it after the second invokecc?
23:10 chromatic After the first.
23:10 chromatic The pattern used to be 1) set up arguments 2) call get_returns to set up the location for return values 3) invoke
23:11 chromatic Now the proper order is 1, 3, 2.
23:11 NotFound chromatic: yes, but the problem is that these test set up arguments 1 time and invoke 2 or 3 subs with that same args.
23:12 chromatic I don't know if we deprecated that.  Good point.
23:14 NotFound The eval test doesn't use the results, so it pass just by deleting the get_results.
23:19 NotFound Must sleep, will look at it tomorrow.
23:28 darbelo joined #parrot
23:41 senf_statt_oel left #parrot
23:42 dalek rakudo: b497776 | (Solomon Foster)++ | src/core/Int.pm:
23:42 dalek rakudo: Change infix:<div> to return floor($a / $b) as in the spec.  (Same as before for
23:42 purl dalek: that doesn't look right
23:42 dalek rakudo: positive, different rounding direction for negative.)
23:42 dalek rakudo: review: http://github.com/rakudo/rakudo/commit/b​4977768c475f32ffa621d0eae2373cdb19b5ed6
23:54 tcurtis Good evening, chromatic.
23:56 chromatic tcurtis

| Channels | #parrot index | Today | | Search | Google Search | Plain-Text | summary

Parrot | source cross referenced