Parrot 2.8.0 released | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | smoke GC-related branches and attack GC tickets
Set by moderator on 1 October 2010.
dukeleto hatseflats: just wondering. the ebuild says scarabeus wrote it 00:02
hatseflats dukeleto: the only files in there are .dump files and one vtable.tbl
don't know if that means something
ellefu Quick question: In a .pmc file, how would I specify a method name (like "METHOD PMC* foobar()") that doesn't conform to C syntax? (Say, if it has a dash in it or something.) 00:03
cotto ellefu, did you try something and get an error?
It's possible pmc2c may need to be smartened up to handle whatever you're trying to do. 00:04
dukeleto ellefu: .pmc files get converted to C by pmc2c, like cotto++ said
cotto says a lot of things
dukeleto even believes a few of them
cotto For some reason, running nqp-rx's build and test suite under the profiling runcore is a bit slower than normal. 00:05
ellefu, what's the name you want to use? 00:07
ellefu 'set-car'. :-) Playing around with implementing a proper Lisp in Parrot. 00:10
Interesting. If I try to quote the method name, like one would in PIR ("METHOD void 'set-car'(PMC* value)") actually causes pmc2c to ignore that method declaration entirely. The generated code just skips right over it. 00:11
cotto pmc2c is like that
bacek_at_work cotto, hey. Time to resurrect pct_pmc? :) 00:12
at least we can bring Grammar to trunk to use as validator
cotto bacek_at_work, I thought that there wouldn't be a need for pct_pmc. 00:13
bacek_at_work cotto, no, but we have functional Grammar for PMC in branch. 00:14
cotto It could be useful, but it'd also be really slow compared to the current process. 00:15
ellefu Slow is fine, as long as it works. 00:16
cotto I don't think you realize how slow it'd be. 00:17
bacek_at_work cotto, we just need profiling to tune nqp-rx. Oh wait...
:)
cotto heh
nqp-rx is looking good so far
Next up is Rakudo's build and spectest. That should only take a couple days. 00:18
00:18 theory left
cotto all tests pass 00:19
woo-hoo!
bacek_at_work ship it! 00:20
cotto bacek_at_work, do you have an x64 machine you could test a patch on? 00:29
bacek_at_work cotto, at home.
nopaste "cotto" at 192.168.1.3 pasted "hard-code profiling runcore as the default (do not commit)" (51 lines) at nopaste.snit.ch/24095 00:30
cotto ok. I'd appreciate it if you could apply that and run Parrot and nqp-rx's build and tests.
cotto needs to go afk
00:47 nopaste left 00:54 nopaste joined 01:07 whiteknight left 01:29 ruoso joined 01:44 theory joined 01:58 kid51 joined 02:24 kid51 left 02:25 jsut_ joined 02:30 jsut left 02:35 janus left 02:41 tcurtis joined
plobsing ellefu: I think you might be able to work around your C-invalid identifier issue by listing the method under a C-valid identifier and then moving the method. 03:01
03:13 janus joined 03:14 treed left
dukeleto 'ello 04:23
04:32 sri left
plobsing hiya duke! 04:37
04:40 sri joined
cotto ~~~~ 04:58
bacek_at_work ENOMATCH 05:01
cotto ENOTSMARTENOUGH 05:09
The Rakudo build works with the profiling runcore. 05:10
Happy times.
I suppose the next task is to make it useful. 05:11
bacek_at_work What about World Domination? And pony? 05:13
cotto World Domination is hard. 05:15
Let's go shopping.
plobsing profiling runcore allows us to dominate a more efficient world.
with turbo-ponies 05:16
cotto I'm getting tired of typing "profiling runcore". How does "profcore" sound? 05:17
05:22 jsut joined
ellefu plobsing: Yeah, that's my backup plan. At the moment, toying around with changing pmc2c to distinguish between C identifiers and method names. We'll see. 05:22
bacek_at_work cotto, PCore is shorter :) 05:24
plobsing let's just call it PR 05:25
as in "our PR is broken again" 05:26
cotto "pcore" has potential 05:27
way easier to type
05:27 jsut_ left
cotto anyone know what the parking situation is at the venue for the Portland meeting next Saturday? 05:41
Hmm. The venue isn't far from omsi. 05:45
05:46 tcurtis left
cotto Maybe that'll be a good time to work on resurrecting khairul's project. 05:47
05:57 theory left
dukeleto cotto: the parking situation? it has a parking lot, which will probably have space during the day. sometimes it fills up at night 06:14
cotto: are you planning on coming to the parrot gathering? that would be awesome!
cotto thanks. I hate looking for a spot.
of course!
It's only a few hours away.
dukeleto cotto: sweet! I am even more excited now. We can complain about Subversion IRL 06:15
cotto Is chromatic in?
dukeleto cotto: hopefully. It would be awesome if particle could come too, but I am not sure. 06:18
cotto: some very nice people spread the word to lots of local tech groups, so I am hoping ot get some other peopl in the virtual machine world to show up, like some Rubinius people 06:19
cotto great idea
we can hardly have too much cross-polination
dukeleto cotto: i think virtual machines can learn from each other. There is no reason why Rubinius and Parrot shouldn't be sharing good ideas. 06:20
cotto *pollination
Though I'd imagine that the Rubinius guys focus more on using the jvm optimally than writing their own. 06:21
but they could tell us what's great about the jvm and what's not 06:22
dukeleto cotto: yeah, I don't expect lots of direct colloboration, but the sharing of good high-level ideas 06:24
06:46 ellefu left, ellefu joined 07:34 mikehh left 07:43 M_o_C joined 07:48 luben_work joined 07:55 fperrad joined
dukeleto how do I regenerate tools/dev/mk_language_shell.pl if I patched the mk_language_shell.in file? 08:51
cotto why does that file add $PConfig{exe} to the end of a perl script? 08:55
reconfig?
dukeleto cotto: it is a file that gets fiddled with and then mk_language_shell.pl is generated from it 08:58
running "make" after applying a patch to it didn't generate the .pl
i guess i can run "make clean" then "make", but that seems suboptimal
there used to be a "tools" target, iirc
ellefu What if you delete mk_language_shell.pl, then make? 09:04
Also, I think I found another bug while futzing with pmc2c -- could someone look at line 798 of default.pmc and confirm that there's really supposed to be a 'VTABLE' in that function definition? 09:06
cotto ellefu++ 09:07
I didn't even know we had a VTABLE slot for that. 09:08
ellefu pmc2c is driving me mad. Its response to anything that it doesn't understand is to just silently give up.
cotto Ah. It's a fairly recent addition by bacek.
ellefu, it's not an especially well-designed tool. 09:09
ellefu Nothing that can't be fixed. :-)
cotto nothing that can be fixed easily, though
though if you have a patch...
dukeleto ellefu: i would like some tests for your patch to mk_language_shell
ellefu Well, I've got the "quoting function names" thing almost done.
bacek cotto, it was added more than year ago. "Fairly recent" :) 09:10
dukeleto ellefu: i am thinking we need to make sure that created languages compile and pass their tests
ellefu: otherwise, every time there is a change in parrot, our scripts will break and we won't know
cotto needs to stop thinking about revisions around 40000 as recent. 09:11
dukeleto goes to sleep and hope for lovely patches in the morning
cotto night
dukeleto cotto: yes, do that. And feed the magic git ponies so we can ride them into the setting sun
ellefu dukeleto: So have mk_language_shell.pl do a "parrot setup.pir test" after generating the boilerplate?
cotto ellefu, yes, but using the newly-built parrot 09:12
as opposed to an installed one from 7 months ago that the user's conveniently forgotten about
dukeleto ellefu: yes, there is a test file called t/tools/mk_language_shell.t 09:13
ellefu Will do.
dukeleto ellefu: the same problem probably exists in create_language.pl, please fix that as well :) They will be merged in the future, but we are maintaining both for now 09:14
ellefu: they use different configure systems (Configure.pl vs setup.pir)
dukeleto actually goes to sleep
cotto too 09:15
ellefu Nope, create_language.pl doesn't appear to generate .pmc files.
cotto It probably needs some convincing. It should have the option there somewhere. 09:16
'night humans and bots
ellefu Night!
bacek: Any reason not to change "warn "FATAL ERROR: Duplicated VTABLE function: " . $method->name" to a die()? 09:20
bacek ellefu, "deprecation policy" 09:27
ellefu Ouch.
bacek check trac. I think it should be deprecated already. Otherwise - create deprecation ticket and we'll fix it after next release in 2 weeks time. 09:28
sorear good timing, btw 09:29
ellefu Trac says that the warning is eligible for removal after Oct 19. 09:31
bacek ellefu, yes. After next supported release (2.9) 09:43
09:53 M_o_C left 10:04 contingencyplan left 10:35 M_o_C joined
dalek rrot: r49476 | bacek++ | branches/generational_gc (2 files):
Add write barriers to CallContext mutable accessors
 11:02
rrot: r49477 | bacek++ | branches/generational_gc/src/gc (4 files):
Rename GC.mark_pobj_header into .mark_str_header to reflect semantics.
rrot: r49478 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Shuffle functions around. Everything is probably broken. Let's start from scratch for mark_and_sweep function
rrot: r49479 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Rewrite generational MS algorithm. Does compile. Doesn't work
rrot: r49480 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Fix typos.
 11:18
11:23 ruoso left 11:33 mikehh joined 11:46 whiteknight joined 11:47 whiteknight left
dalek rrot: r49481 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Don't kill "constant" objects...
 11:49
rrot: r49482 | bacek++ | branches/generational_gc/src/gc/gc_ms2.c:
Fix cleanup flags
mikehh bacek: you got missing docs and asserts 11:58
bacek: you want me to try and sort it out? 11:59
bacek: and c++ comments in generational_gc/src/pmc/default.pmc 12:01
12:27 tadzik joined 12:37 allison joined 12:41 bluescreen joined 12:47 ruoso joined 13:03 tcurtis joined, tcurtis left 13:19 jan left 13:20 Patterner left 13:22 M_o_C left 13:30 Psyche^ joined, Psyche^ is now known as Patterner 13:31 whiteknight joined 13:45 tadzik left 13:49 PerlJam joined 13:51 theory joined 13:55 theory left 13:59 bacek left 14:01 bacek joined 14:08 tadzik joined 14:40 luben_work left 14:42 contingencyplan joined 14:57 jan joined 14:58 tadzik left 15:09 Andy joined 15:14 he_ joined 15:15 theory joined 15:19 smash joined
smash hello everyone 15:19
whiteknight hello smash 15:22
15:25 bacek left, bacek joined 15:30 theory left 15:33 theory joined 15:50 bacek left 15:55 bacek joined 16:07 ruoso left 16:38 brianwisti joined
brianwisti Came on to ask a question and found the answer before I had a chance. So ... um ... hey. 16:44
whiteknight hey! 16:48
we always like answering questions here, even if we answer our own 16:49
moritz will I switch on the light in the next 10 minutes? I think I will, it's getting dark...
brianwisti Well, I sort of answered my question. Good enough for today. But for later: how can I tell if a PMC can be invoked? I went the lazy way and checked if typeof is 'Sub', but that might not work for advanced cleverness. 16:51
plobsing you are likely to be eaten by a grue
whiteknight brianwisti: Most core types implement the role "invocable"
so $I0 = does $P0, "invocable"
er, invokable
it's not a hard-and-fast rule, but invokable core types should implement that role 16:52
brianwisti That works and soothes my easily ruffled sense of code propriety. Thanks, whiteknight 16:53
whiteknight brianwisti: no problem. What kind of fun project are you working on? 16:54
brianwisti I'm poking at the next Parrot Babystep while my work tests run. 16:55
whiteknight oh, nice
brianwisti Finally getting into namespaces. 16:57
17:09 fperrad left 17:37 allison left 17:39 dip left 17:43 theory left 17:45 M_o_C joined
dukeleto hola 17:59
cotto Hmmm. Testing mk_language_shell-generated languages might be tricky. It appears to assume that it's being run with an installed parrot and doesn't work when running from a build tree. 18:01
dukeleto cotto: did some tests get added for that recently? 18:02
cotto I'm adding one. 18:04
I guess I can TODO it for now.
dukeleto cotto: it shouldn't use the installed parrot 18:06
cotto: but something is better than nothing. TODO it and I can try to tweak it
cotto: you should be able to get the path of the compiled parrot binary from parrot_config 18:07
cotto dukeleto, it can run the built parrot just fine, but the language won't built
You can easily repro by making a dummy language and trying to run setup.pir with a parrot from the build tree. 18:08
dukeleto cotto: i think that is what I have been doing 18:09
cotto: what kind of error are you getting? are you using --with-pmc ?
cotto yes 18:11
18:12 plobsing left
dukeleto cotto: have you tried the update_patch at trac.parrot.org/parrot/ticket/1819 ? 18:12
cotto: i didin't want to apply that patch unless I could show that it actually works with the patch 18:13
cotto: if that patch makes your test work, please apply
dalek rrot: r49483 | cotto++ | trunk/src/pmc/default.pmc:
[pmc] add missing VTABLE to a vtable declaration noticed by ellefu++
 18:14
cotto looking now 18:15
also, todo'd tests were just committed
How do you spell >/dev/null on windows? The tests I just added are pretty noisy. 18:18
> NUL seems to be the answer 18:21
18:21 brianwisti left
cotto Is anyone on window to test something? 18:22
dukeleto cotto: you can look at the windows taptinder runs 18:25
cotto This is true. 18:27
dalek rrot: r49484 | cotto++ | trunk/t/tools/mk_language_shell.t:
[t] add a couple TODO'd tests to make sure generated languages build and pass their tests
 18:29
dukeleto cotto++ 18:32
18:39 mj41 left
dukeleto cotto: those TODO's pass on my machine (64bit linux). 18:44
18:44 mj41 joined
dalek rrot: r49485 | cotto++ | trunk/t/tools/mk_language_shell.t:
[t] make language build and test tests less noisy
 18:45
dukeleto cotto: do they fail on your machine? 18:47
cotto: or were you just being defensive with the TODO?
cotto They fail on my machine. 18:49
Testing create_language may have similar problems. 18:54
it does 18:56
18:58 bluescreen left 18:59 bluescreen joined
cotto Assuming an installed parrot is reasonable for language creation scripts, but it does make testing tricky. 19:02
19:17 particle left 19:18 particle joined 19:42 cogno joined 19:48 ruoso joined 20:01 whiteknight left 20:03 he left 20:10 davidfetter joined 20:15 M_o_C left
dukeleto cotto: can you paste what errors you get with your mk_lang_shell tests? 20:18
20:18 M_o_C joined
cotto sure 20:23
it boils down to setup.pir expecting /usr/local/include/parrot/2.8.0-devel to exist when I use the parrot executable from the build tree. 20:25
nopaste "cotto" at 192.168.1.3 pasted "output of failed built (including docs, pmcs and ops) for mk_language_shell" (45 lines) at nopaste.snit.ch/24109 20:26
20:27 cogno left
dukeleto cotto: that dir doesn't exist on my machine, but the tests pass 20:36
cotto: are you using a --prefix when you compile parrot? 20:37
cotto: or are you using the non-installed version of parrot in the build dir?
cotto: perhaps the tests only pass now when --prefix is used
cotto I'm using a non-installed version 20:46
dukeleto, do we want to require --prefix for those tests to pass? 20:47
davidfetter hai dukeleto 20:49
20:54 cogno joined
dukeleto davidfetter: hola 20:58
davidfetter hoping dukeleto's been expired to blog
dukeleto cotto: those test require an "installed" parrot, but not the system install of parrot. Those tests require that parrot be "installed" somewhere to properly work. 21:01
cotto: so, i think they need to be TODO'ed in the case where "make install" has not yet been run. which is kind of crappy. But better than nothing, I guess.
cotto I guess 21:02
Better would be to make them work both ways, though I don't know how feasible that'd be. 21:03
21:05 cogno left
dukeleto cotto: compiling parrot extensions and HLLs doesn't work with a non-installed parrot, methinks 21:09
cotto: it would be nice if that worked, but I don't know about the feasibility of that. Perhaps somebody on parrot-dev can enlighten 21:10
cotto One problem with the mk_language_shell tests right now is that if they depend on an installed parrot, there's no guarantee that the installed parrot is what the user intended to test. 21:12
dukeleto cotto: those tests should only run on the local build of parrot, which is installed "somewhere", which is why I say that those tests require "make install" 21:14
cotto: but installing into a temp dir in the parrot build tree seems to run those tests seems ....
cotto: a bit much. But perhaps that is the best way. It would require running Configure.pl again with a --prefix 21:15
cotto They need to be tested one way or another. 21:16
If it's hacky but can be run as part of make test, I'd call it ok. 21:18
If it can be made non-hacky, even better.
dukeleto cotto: i think it would be workable if those tests were under a different target than "test", but included in "fulltest" 21:19
cotto: like make devtests or something
cotto Do tt machines run fulltest? 21:20
dukeleto cotto: not sure. but mikehh definitely does :) 21:21
cotto Those tests don't need to be run every time we run make test, as long as they're run regularly. 21:22
dukeleto does "make smoke" run fulltest ?
cotto not sure
21:29 bluescreen left 21:33 ruoso left 22:05 whiteknight joined
cotto hio whiteknight 22:13
sorear hello whiteknight 22:15
mikehh cotto: AFAIK smoke can run coretest and test but not fulltest 22:25
22:28 kid51 joined
mikehh cotto: I don't know how it would handle multiple tests of the same name, maybe it could run testb, testf and testr separately 22:28
sorear whiteknight: any chance I could get another fix of PDD review soon? :) 22:29
cotto Is there any reason not to have smolder run fulltest by default? 22:30
s/smolder/make smolder/
mikehh cotto: I don't know how it would handle the archive if there were multiple tests of the same name 22:34
cotto There's not need for the tests to have the same name. 22:45
dukeleto cotto: when does that even happen? 22:47
we should definitely add a smoke_fulltest target
and then ask parrot-dev whether make smoke should run fulltest by default
cotto I don't see where that idea came from.
mikehh cotto, dukeleto: testb, testf and testr run the coretests so you have 3 instances of say t/op/*.t, t/pmc/*.t etc 22:49
cotto Ah. That's what you're talking about. 22:51
23:07 M_o_C left
dukeleto mikehh: we can add a smoke_fulltest target and see how smolder deals with getting that kind of data 23:08
mikehh let me try and see what happens if i try a make fulltest with --archive 23:09
dukeleto mikehh++ 23:10
mikehh dukeleto: after I have finished this test run 23:12
23:18 whiteknight left
kid51 Wow, even if I can't get purl here, I can get her on #pdx.pm! 23:19
23:25 kid51 is now known as kid51_at_dinner 23:32 davidfetter_ joined
sorear you can get purl here, ask #purl 23:34
23:37 davidfetter left, davidfetter_ is now known as davidfetter
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#505) fulltest) at r49485 - Ubuntu 10.10 RC amd64 (g++-4.5 with --optimize) 23:39
t/tools/mk_language_shell.t - TODO passed: 6-7. in smoke and fulltest (library_tests)
dukeleto mikehh: those TODOs are expected, they don't pass in all configurations, yet, so they are TODOed 23:43
mikehh dukeleto: we need to set the TODO's to be platform specific - what platforms are they failing on 23:45
cotto mikehh, it depends on whether you have an installed parrot 23:48
dukeleto mikehh: which makes it tricky to TODO 23:49
cotto if ($user_has_installed_parrot_that_happens_to_work) {...}
mikehh cotto: I don't have parrot installed here 23:52
I remove the installation after I have tested rakudo, partcl etc. 23:53
I haven't insatalled yet 23:54
dukeleto mikehh: we mean those tests depend on using --prefix and running "make install"
mikehh: extensions and compiling HLLs doesn't work on non-installed parrots
mikehh yeah, but I haven't done that yet (well --prefix=/usr/local), but no make install yet 23:55
23:55 bluescreen joined
dukeleto mikehh: and you get rakudo to work with that? are you using --gen-parrot ? 23:56
mikehh I haven't run rakudo tests yet - I do make install before that and use perl Configure.pl --parrot-config=/usr/local/bin/parrot_config when I do 23:57
but, I have not yet run make install, well sudo make install 23:58
dukeleto mikehh: then I don't quite understand when those tests need to be TODOed. They fail for cotto 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!