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
Set by moderator on 2 June 2010.
Coke bacek++ #fixing coretest 00:37
is everyone seeing the passing TODO on the packfile test? (I am seeing it pass on ubuntu)
GeJ let me check. 00:38
t/pmc/packfile.t .................... 00:40
not ok 34 # TODO
Coke GeJ: what's your platform?
GeJ FreeBSD 7
Coke Linux halfpint 2.6.31-15-generic #50moblin5-Ubuntu SMP Mon Dec 14 16:04:27 UTC 2009 i686 GNU/Linux
bacek_at_work Coke, just mark packfile test as skipped. 00:43
dalek kudo: 5219aa5 | (Solomon Foster)++ | src/core/ (4 files):
Move Int.Bool to Real.Bool, tweak definition of Rat.Bool, remove Num.Bool.
 00:46
GeJ Coke: x86 or x64? 00:47
Coke bacek_at_work: I don't like skipping tests. =-) 00:52
bacek_at_work Coke, I wrote this test. It was "wishful thinking" for really portable bytecode. 00:53
Coke GeJ: excellent question. =-)
how can I tell?
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.
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 00:57
01:33 kid51 joined
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
so TODO is still the appropriate status for it.
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
Coke kid51: clearly it's not the appropriate status on /my/ platform. =-) 01:45
dukeleto msg kid51 looking for me? 02:20
purl Message for kid51 stored.
Coke ARGH. the dell notebook I got came with some netbookOS (moblin) that is apparently already end of lifed. =-) 02:23
dalek kudo: a1193fe | (Solomon Foster)++ | src/core/ (2 files):
Generic version of infix:<%> for Real, and change the generic infix:<%> to
 02:26
purl dalek: that doesn't look right
02:38 abqar joined 03:13 janus joined 03:18 davidfetter joined
pmichaud exit 04:33
ww
Coke ditches ubuntu moblin for ubuntu netbook. 04:34
pmichaud: you about? 04:42
(quick reboot) 04:43
05:17 fperrad joined 05:21 fperrad_ joined 05:27 aukjan joined 05:32 fperrad_ joined 06:02 uniejo joined
Coke getting a lot of failures in t/pmc/io.t 06:52
cotto none here 07:01
Coke this with a fresh build on ubuntu 10.04 07:06
07:07 aukjan joined
cotto I'll retry 07:07
Coke r47434 07:08
cotto optimized or non? 07:11
bacek_at_work coretest isn't fully fixed 07:18
cotto no failures with a clean build 07:19
bacek_at_work cotto, make corevm/coretest 07:32
after realclean
purl after realclean is all ok
bacek_at_work purl, forget after realclean
purl bacek_at_work: I forgot after realclean
sorear never trust clean targets 07:33
svn st --no-ignore is your frient
eqv. git clean -dnx
07:44 aukjan joined 08:02 particle1 joined 08:35 particle joined 08:49 jjore joined 09:01 eternaleye joined 09:13 clinton joined 09:35 szabgabx joined
bacek aloha, humans 09:52
09:56 lucian joined 10:00 JimmyZ joined 11:04 mats joined 11:17 ruoso joined
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:27
moritz actually pmichaud demonstrated a POST -> LOLCODE translator, which ran ruby on lolcode, or so 11:28
11:53 whiteknight joined, khairul joined
whiteknight good morning, #parrot 11:54
12:06 tetragon joined 12:44 bluescreen joined 12:47 JimmyZ joined
JimmyZ hmm? Topic is none? 12:49
moritz JimmyZ: looks fine here 12:50
might be netsplit issues
moderator 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.
thanks.
13:03 bluescreen joined 13:08 khairul joined 13:09 atrodo joined
dalek kudo: 6f0d81a | (Solomon Foster)++ | src/ (2 files):
Initial implementation of infix:<mod>. In the long run, should maybe be in
 13:42
13:42 davidfetter joined 13:53 plobsing joined 14:03 PacoLinux joined 14:05 gbacon joined 14:18 Andy joined 14:24 ash_ joined 14:30 hudnix joined
ash_ is there a document that goes over PMC macro style guides? 14:37
14:42 bubaflub joined 14:45 patspam joined 14:51 cognominal joined 14:54 dmalcolm joined
whiteknight ash_: not really. Certainly nothing up to date 14:58
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
ash_ i'll get it working, thenworry about matching the styles 15:02
15:13 Ryan52 joined 15:14 Myhrlin joined
whiteknight ash_++ 15:26
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:37
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
ash_ hmm, but thats INTVAL right?
whiteknight yes
ash_ you can't say "make it shorts" or something
whiteknight ash_: If you're interested in testing/prototyping new PMC types for this kind of stuff, check out the parrot-data-structures project
ash_ link? 15:39
purl link is dead
whiteknight ash_: no, can't make it short, at least not in current Parrot
parrot-data-structures?
purl rumour has it parrot-data-structures is github.com/Whiteknight/parrot-data-structures
ash_ cool thanks
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
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
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
NotFound whiteknight: Typo? =item* Sparce Array
whiteknight NotFound: probably lots of typos
15:41 mikehh_ joined
whiteknight NotFound: I'm bad at POD 15:41
ash_ there is structure support already, but i'd like to do others too
NotFound whiteknight: sure, but in a =item looks a bit worse ;) 15:42
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
mikehh opbots, names 15:46
ash_ whiteknight: well my point was more that current data types don't do that, right?
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"
no
NotFound An alternative can be implementing an interface like that to ManagedStruct
ash_ can a ManagedStruct do that? 15:47
make an array of say 8 ints?
whiteknight maybe, but probably not as elegantly
I don't like ManagedStruct anyway
ash_ RawArray seems like an appropriately generic way to do it 15:48
NotFound Is not my favourite thing, but it works.
ash_ although i'd add a size argument personally 15:49
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:50
Since ManagedStruct seems to work, a helper function like that would just make it more usable 15:51
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
not that GSoC students should be immune from pains in the ass, I'm just making an observation :) 15:53
NotFound Good point.
ash_ I already had that speced, for how i planned to implement all of that (alignments an things like that) 15:54
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
whiteknight nothing. It's safe to ignore me most of the time
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:58
NotFound ash_: no, I just read some talk about it. 15:59
ash_ 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:00
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
i|d would be a union { int; double} 16:02
NotFound That code is just an approximation for the few event types actually used.
ash_ do you have a link to the C defintiion?
I found it, nevermind 16:03
NotFound ash_: sure, the Xlib Programming Manual, a +700 pages book ;)
ash_ tronche.com/gui/x/xlib/events/structures.html seems to be it
(i assume)
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
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.
ash_ i don't either really... strings for nci are actually just pointers in most cases 16:06
NotFound ash_: a 't' isn't just a pointer, 16:07
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:08
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 16:22 darbelo joined 16:24 hercynium joined 17:45 lucian_ joined
cotto_work good marooning 17:48
dalek rrot: r47435 | NotFound++ | trunk (2 files):
delete do-nothing mark, simplify coverage and add tests to StringBuilder PMC
 17:49
darbelo o/ 17:51
whiteknight good morning, cotto_work 18:01
dalek rrot: r47436 | darbelo++ | branches/gsoc_nfg (365 files):
Sync with trunk.
 18:06
18:24 ruoso joined 18:33 lucian joined 18:35 dduncan joined
cotto_work seeing the t/pmc/io.t failures when running coretest after realclean/configure 18:36
18:37 dduncan left
Coke are dynops still building with corevm? 18:51
or was that re-re-disabled?
whiteknight un-de-disabled?
cotto_work looks like no
not built, that is
which seems to be causing the failures 18:52
all happy after running make, so confirmed 18:53
darbelo I guess now is not the time to push for using separate harnesses for test vs coretest? 18:56
Coke darbelo: what do you mean, separat harnesses? 18:57
like, t/harnessA, t/harnessB ?
darbelo Kind of, yes. 18:58
Coke how would that help?
darbelo It's all for dogfooding purposes.
Coke I don't think we want to eat our own dogfood on coretest.
is that your point? that we could on test? 18:59
darbelo Yep.
We have our own TAP consumer now. I'd like to see it exercised a bit more. 19:00
We're not there yet, but I would like to see t/harness.pir become the default for 'make test' 19:02
particle darbelo: i expect that post-lorito 19:04
darbelo The file is there now :)
particle there are much higher priorities, and lorito will force us or enable us to make the transition more easily 19:05
darbelo I can live with that. 19:06
19:08 davidfetter joined 19:15 cotto_work joined
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.
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
that way we're getting at least a monthly run
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
darbelo And fulltest takes long enough now, thank you very much.
whiteknight bah. It's shorter now that we've removed the extra cores
cotto_work We just shortened it considerably. 19:26
darbelo Let's not bloat it again for no good reason ;)
cotto_work how many tests are we talking about?
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
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
for lack of a better work, I'm calling the whole process the "build" 19:29
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
we can run a small subset, but we do need to give the harness some exercise
the harness needs to be tested too
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:31
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
then, run the harness over a subset of tests that the regular harness runs, and verify that they agree on the outcome
dalek kudo: b258f5c | (Stéphane Payrard)++ | src/Perl6/Actions.pm:
Awesommify error message for $:a in signature
 19:38
cotto_work yo dawg?
purl, yo dawg?
purl wish i knew, cotto_work
cotto_work yo dawg is qntm.org/responsibility
purl, yo dawg?
purl well, yo dawg is qntm.org/responsibility
cotto_work not nearly as annoying as the typical xzibit macro 19:39
dalek rrot: r47437 | darbelo++ | branches/gsoc_nfg/src/string/grapheme.c:
Fix non-icu builds and add svn props.
 19:46
19:53 tcurtis joined 19:55 cognominal joined
ash_ what is ARGIN used for? 20:01
the C macro
cotto_work argument annotations 20:02
PerlJam ash_: IIRC ARGIN is an "input only" argument. you're promising that it won't be used otherwise. 20:03
20:03 Psyche^ joined
dalek rrot: r47438 | tcurtis++ | branches/gsoc_past_optimization (422 files):
Sync with trunk.
 20:03
20:04 bluescreen joined
ash_ found a doc talking about it, i'll read over that 20:04
cotto_work ash_, you can also look at include/parrot/compiler.h to see what they translate to 20:23
ash_ __in i assume is a gcc compiler directive? 20:24
reading the source of some things doesn't always de-mystify them 20:25
thanks though, :P i'll see if i can figure them out
cotto_work not sure. You'll probably have to dig a bit. 20:26
np
GeJ Good morning everyone.
cotto_work hio GeJ 20:28
cotto_work needs to make a bot named "hio" 20:29
darbelo Hey, where did aloha go? 20:36
moritz probably to hawaii
cotto_work it got in a fight with purl 20:43
GeJ servus cotto. 20:44
darbelo ash_: most __-prefixed things are safe to assume as compiler magic related. 20:57
ash_ yeah
__in is actually MS compiler specific, it adds some compile time warnings if you do certain things to the variable
dalek website: tcurtis++ | The Last Week and a Half in PAST Optimization 20:58
website: www.parrot.org/content/last-week-an...timization
ash_ i found documentation for it
bacek aloha, humans 21:01
21:01 aloha joined
darbelo aloha, aloha 21:01
aloha, bacek
bacek aloha, darbelo 21:02
dalek tracwiki: v5 | jrtayloriv++ | HLL%20Resources 21:03
tracwiki: Add references to introductory materials on writing HLL compilers
tracwiki: trac.parrot.org/parrot/wiki/HLL%20R...ction=diff
cotto_work aloha, cotto_work 21:07
wait. I did that wrong.
dalek rrot: r47439 | darbelo++ | branches/gsoc_nfg/src/string (3 files):
Make various parts of codetest happy again.
 21:09
21:10 lucian_ joined
mikehh bacek: gc_massacre has build problem with g++ last time I tried, gcc builds (slowly) 21:32
21:33 whiteknight joined
mikehh bacek: do you want a nopaste of the error(s) 21:34
21:35 clinton joined
bacek mikehh, I know about them... 21:35
mikehh bacek: 'k 21:36
bacek ms2 gc requires some deep tuning.
mikehh bacek: you did not seem too happy with the linked list implementation 21:38
bacek mikehh, yeah. It's slower than I expected.
And TriColour mark doesn't make sense without Incremental prefix. 21:39
But for Incremental part it will require a lot of effort to implement it. 21:40
whiteknight TriColour doesn't make sense without the incremental part, but it's not impossible to have it 21:46
You could create the tricolor algorithm first, and later insert incremental breaks
bacek whiteknight, not so easy. You have to have way to grey-out already marked objects. 21:48
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
mark the item, move it grey, mark it's children, mark it black
bacek whiteknight, it's exact algorithm in src/gc/gc_tms.c 21:50
Actually I think we can avoid remarking objects in parrot. 21:51
All our live objects referenced by CallContext registers anyway
21:52 szabgabx joined
mikehh mikehh: so anything not referenced in CallContext registers is dead? 21:54
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
mikehh baceK: the problem with multiple interp? 21:56
bacek mikehh, nope.
NotFound bacek: take a look at my comment on TT #1659 22:07
22:08 theory joined
bacek NotFound, nope. Actually impatient_pmcs counter is usually wrong. 22:08
NotFound bacek: don't know, but if the object is marked, it will fail anyway. 22:09
bacek NotFound, GC just stop in lazy mode too early. 22:10
22:10 chromatic joined
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.
bacek NotFound, "hash seed problem". It's just destroyed objects in different order. 22:12
chromatic, aloha!
chromatic aloha 22:13
22:14 darbelo left, darbelo joined
NotFound bacek: What objects? 22:15
purl Objection noted. Proceed.
bacek NotFound, pmcs
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:18
darbelo C89 can regard what it wants as a compiler implementation detail, so long as I can disagree. 22:19
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
22:23 kid51 joined
NotFound darbelo: the better way to disagree with a language is to not use it. 22:25
bacek NotFound, hmm... Looks like it's marked alive... 22:26
NotFound bacek: is alive because it remains in the context signature. Is a known problem. 22:27
Or feature, maybe ;)
chromatic It'd be nice to find a simple solution--even in part--to that problem soon. 22:29
NotFound chromatic: last time I looked at this problem, I find a test that depends on it. Let me remember... 22:30
kid51 make coretest situation unchanged from yesterday: failures in t/pmc/io.t : smolder.plusthree.com/app/projects/...ails/34247 22:31
make test PASS smolder.plusthree.com/app/projects/...ails/34248 22:42
r47439 22:43
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:45
cotto_work you can just revert src/ops/core_ops.c and anything in include to get a usable parrot again 22:46
but yes, it can be a pain
NotFound A big pain. We need a way to use an out-of-tree nqp if we want some agility. 22:47
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:48
compilers/nqp is gone 22:49
NotFound cotto_work: a parrot with nqp already built in another tree, or installed.
darbelo nqp-rx can be installed 'independently' already. 22:51
But that needs an installed parrot, so.
..
cotto_work unix toolbox? 22:54
unix toolbox is cb.vu/unixtoolbox.xhtml
unix toolbox is
unix toolbox? 22:55
purl unix toolbox is cb.vu/unixtoolbox.xhtml
cotto_work epic win there for any aspiring *nix geeks
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:56
22:58 senf_statt_oel joined
NotFound It also chokes on code that uses get_results before callmethodcc. Is this still supported? 22:59
chromatic: ping 23:00
chromatic pong, NotFound 23:01
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?
NotFound chromatic: no, use of invoke with the same set_args two times. 23:03
In t/op/calling.t ...
and t/pmc/eval.t
23:04 tetragon joined
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
chromatic That latter *must* be wrong. 23:05
NotFound Failed test 'named - 5 slurpy array -> named'
at t/op/calling.t line 1852
chromatic get_results shouldn't be there since the last PCC refactor.
NotFound Failed test 'call 2 subs in evaled code 'at t/pmc/eval.t line 58. 23:06
chromatic: is has zero args, probably it got unnoticed because of that.
chromatic t/pmc/eval.t works if I move get_results to after invokecc. 23:07
... but that's obviously without your change in place.
If all of the failures are of that type, we can fix the tests.
23:08 davidfetter left, davidfetter joined
davidfetter oops 23:08
mis-/part'ed
NotFound chromatic: yes, but I don't know if some HLL may be using that... feature?
chromatic We deprecated it.
NotFound chromatic: Move it after the second invokecc? 23:09
chromatic After the first. 23:10
The pattern used to be 1) set up arguments 2) call get_returns to set up the location for return values 3) invoke
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.
chromatic I don't know if we deprecated that. Good point. 23:12
NotFound The eval test doesn't use the results, so it pass just by deleting the get_results. 23:14
Must sleep, will look at it tomorrow. 23:19
23:28 darbelo joined 23:41 senf_statt_oel left
dalek kudo: b497776 | (Solomon Foster)++ | src/core/Int.pm:
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
tcurtis Good evening, chromatic. 23:54
chromatic tcurtis 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!