Parrot 2.10.1 Released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Parrot Developer Summit 2300 UTC today | Please test rakudo with bleeding edge parrot!
Set by moderator on 5 December 2010.
Matt221 I noticed some discussion previously on builds failing on Darwin.. 00:00
cotto_work We want OSX users to be able to build too. It'd be better to fix the issues you're seeing.
do you know how to debug it? 00:01
kid51 Matt221: I was having problems building on Darwin a few days ago, but those problems were fixed. OTOH, I haven't tested there in 2-3 days.
Matt221 cotto_work: nope, just trying to get some tasks done for GCI on the embed_api2 branch
00:01 whiteknight joined
whiteknight can't tell if spam coming to the mailing list is getting more clever, or less clever 00:03
cotto_work whiteknight: Matt221 is seeing a build failure on darwin in embed_api2 in pbc_merge. 00:04
whiteknight hmmm. weird. Last I heard kid51 had a clean test there
kid51 I will try later this evening. smoking master on that machine right now 00:07
cotto_work you can ask him about it. He just reported it.
(him being Matt221)
00:12 hercynium left 00:27 kid51 is now known as kid51_at_dinner 00:33 bluescreen left 00:48 Hunger joined 00:53 bluescreen joined
Coke we have some ubuntu users in here, yes? 00:57
kid51_at_dinner There have been no commits to the embed_api2 branch since my last test, so, not surprisingly, I just successfully built on both Darwin and Linux. 00:58
00:58 kid51_at_dinner is now known as kid51
cotto_work Coke: yes 00:58
Coke whiteknight: last you heard from me, it was broken on os x. ;)
kid51 Coke: me but only at $job
Coke cotto_work: I have bug that is reported fixed by a kernel update. Is there a way for an idiot user (moi) to upgrade the kernel?
kid51 Of course, there's always a chance that a branch will build on 10.4 but not on 10.5 or 10.6.
Coke or do I just get to wait for the next point release?
I'm on 10.6/x86. I'll retest the branch. 00:59
cotto_work Coke: is there a .deb or ppa you can use?
kid51 Coke: On my $job box, where I passively hit the Install Updates button, I get kernel updates every month or so.
Coke kid51: hokay. 01:00
danke.
kid51 whiteknight: Note that on embed_api2 I still get this warning at the conclusion of 'make', regardless of platform: src/install_config.c:2604: warning: no previous prototype for 'Parrot_set_config_hash'
Coke make: *** [runtime/parrot/library/PCT/PAST.pbc] Segmentation fault 01:01
cotto_work Coke: is that when running pbc_merge? 01:02
nopaste "coke" at 192.168.1.3 pasted "embed_api2 build failure" (1474 lines) at nopaste.snit.ch/26827
Coke lots of warnings, too. (and that's not with --cage) 01:04
01:04 Yuki`N joined, Hunger left
Coke I wonder if kid51's is failing the same way but just happens to finish on src/install_config.o 01:05
(I'm getting that warning also)
01:05 Hunger joined
kid51 Coke: Your revision number is not the same as mine. What's the calendar date of your most recent commit in git log in that branch? 01:06
Coke c7def2f52a7860e3fc0a380401bc6c7acc41b6fc
Date: Mon Dec 6 19:26:12 2010 -0500
kid51 Hmm: Then why does your paste suggest a different revision? 01:07
Yuki`N Hey, just wondering, what tool is used to calculate the code coverage statistics found at tapir2.ro.vutbr.cz/cover/cover-results/
kid51 Yuki`N: Can't say for sure, but probably gcov
Coke what revision does it suggest?
kid51 Your Configure.pl step auto::sha1 says: 924acec 01:08
cotto_work Yuki`N: you can generate the same information with make cover with the right compiler and Perl modules.
Yuki`N I see.
That's good to know.
Coke kid51: no clue.
01:09 theory left
Coke kid51: because that's what's in .parrot_current_sha1 01:10
uh... is that file generated? 01:12
I just did an ack -Qa for that file, and it doesn't ever seem to be set anywhere.
ah, lib/Parrot/SHA1.pm ... 01:13
um. why are we caching that value? 01:16
that means if we ever do a git up, we MUST do a realclean to catch the latest version. 01:17
s/git up/git pull/
cotto_work Oh brave new world that has such gits in it. 01:19
Coke presumably this is also the reason I was having trouble building rakudo earlier.
rebuilding embed_api2 branch... 01:20
cotto_work: want me to open a ticket about not caching that file?
cotto_work Coke: sure. 01:21
nopaste "coke" at 192.168.1.3 pasted "embed_api build failure on OSX" (1020 lines) at nopaste.snit.ch/26828 01:22
01:24 kid51_ joined
cotto_work dukeleto: ping 01:26
01:27 kid51 left
Coke ah. just noticed that my "make realclean" was "mmake realclean" because I was testing out the failure of my build script. :P 01:29
so I did not, in fact, realclean first. I still contend I shouldn't have had to.
(that embed_api2 build had a manually realclean in front, though.) 01:30
01:32 lucian left 01:33 theory joined 01:34 theory left
cotto_work msg dukeleto Would it be possible to add a post-recieve hook to update .parrot_current_* to all clones of the git repo or would that have to be added manually? 01:35
aloha OK. I'll deliver the message.
Coke why do that? doesn't git give you an easy way to get the latest sha1? 01:36
01:36 theory joined
dalek TT #1884 created by coke++: don't cache .parrot_current_git_describe 01:39
TT #1884: trac.parrot.org/parrot/ticket/1884
01:44 whiteknight left
Yuki`N Could someone quickly explain to me how PIR works, as I think I'm going to try improving the String PMC test coverage. 01:52
plobsing Yuki`N: (greatly simplifying) a PIR file consists of a set of subroutines (delimited by .sub .end) given as a sequence of parrot ops. it supports predeclared named registers (.local {pmc,string,int,num}) as well as automatic registers ($P0, $N1, $S2, $I33, etc). 01:56
fbrito Yuki`N: take a look at docs.parrot.org/parrot/devel/html/index.html (PIR Book) 01:58
Yuki`N: it helped me a lot :)
Yuki`N So each PMC has a set of "vtable" functions 02:03
And depending on which PIR opcode is called, the appropriate function is used?
plobsing some opcodes invoke vtables, yes. others do more mundane things like copy pointers between registers. 02:14
Yuki`N example being, how do I choose between is_equal, is_equal_num, and is_equal_string? 02:16
cmp $I0, $P0, 1 vs cmp $I0, $P0, "1"?
02:16 Matt221 left
plobsing you'd have to look at the implementation of the ops to find what you are looking for. those are under src/ops/. The two ops you listed call the get_integer and get_string vtables. 02:20
dalek rrot/tt532_headerizer_refactor: 3129b83 | jkeenan++ | / (2 files):
Refactor some code from within Parrot::Headerizer::Object into internal method

test setup code with a subroutine.		 02:30
03:00 fbrito left
Yuki`N I'm still having a bit of trouble running `make cover'; it's not giving me any coverage information for src/pmc/* 03:04
Not even any .pmc files.
kid51_ runs 'make cover' for the first time! 03:12
Is it supposed to provide direct coverage of .pmc files? (I don't see them listed in config/gen/makefiles/root.in.) (Caveat: I'm not in master at the moment.) 03:14
Yuki`N I *think* so. 03:15
I'm not quite sure how the online coverage tool works, because it has data for the .pmc files. 03:16
plobsing it should just be running make cover 03:17
Yuki`N Weird. 03:19
plobsing aloha, coverage?
aloha plobsing: coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
plobsing Yuki`N: examining the vutbr.cz site, the script to run the coverage appears to be tapir2.ro.vutbr.cz/cover/script/makecover.sh.txt 03:20
Yuki`N It does appear to only call make cover.
I'm going to try logging my output from make cover and seeing if there are any perl modules I don't have installed. 03:21
I think I've increased the string.pmc coverage by ~5%.
kid51_ Yuki`N: How would running make cover shed light on missing Perl modules? 03:22
Wouldn't a simple 'make test' do that?
Yuki`N ...true.
Make cover is almost 80% make test anyway. 03:23
kid51_ It's repetitions of 'make test' with different runcores. It's actually closer to 'make fulltest'
03:24 p_l|dmp joined
kid51_ Yuki`N: I've done a lot of coverage testing on the configuration and build tools. 03:25
In my experience, if you FAIL any tests, the script you're running exits before 'cover'. Consequently you don't get results. 03:26
Yuki`N It looks like I just needed to distclean; I see .gcno files in src/pmc now.
kid51_ Fortunately, that does *not* appear to be the case here.
Unfortunately, 'make cover' is set up to produce .html output by default. 03:27
Which doesn't help everybody.
This is a useful overview of the coverage: 03:36
cover -summary 2>/dev/null | grep '^src\\/' | grep -v creating
kid51_ must sleep 03:37
03:37 kid51_ left
dukeleto waves from PDX.pm 03:43
Yuki`N Whoo.
string.pmc is now at 87.6% coverage. 03:44
I think I can up that a bit though./
dukeleto Yuki`N: awesome!
Yuki`N: also, welcome!
Yuki`N xD hi. 03:45
Wow silly copypaste typo 03:46
In the sub testing cmp_num I actually used cmp_str.
I was wondering why cmp_num wasn't shown as covered.
dukeleto Yuki`N: what exactly is your question? 03:51
Yuki`N: i am not sure i understand 03:53
cotto_work: i am not sure i understand your question about .parrot_current_rev 03:55
Yuki`N: are you working in a github fork? 04:00
Yuki`N dukeleto, yes, but I haven't committed yet. 04:04
My question resolved itself.
Coverage up to 91% :) 04:06
dukeleto Yuki`N: awesome!
Yuki`N: i can make you another task for another 5% if you want
Yuki`N: you only need to get it to 88% for this task :)
Yuki`N Ah.
Well, I think I can bump it up another 3% if I figure out how to call methods from PIR 04:07
e.g. METHOD is_integer(STRING *src) {
dukeleto Yuki`N: awesome! Some methods might not be callable from PIR, but I am not sure which aren't and which are
Yuki`N: that is part of the fun :) 04:08
Yuki`N xD
Indeed.
dukeleto Yuki`N: what is your name on github?
Yuki`N github.com/nol888/parrot/commits/master 04:09
nol888
dukeleto Yuki`N: are you ready to send a pull request?
Yuki`N I may go for the extra 2%, but as it stands I can send a pull request. 04:10
dukeleto Yuki`N: does "make fulltest" pass for you? 04:13
Yuki`N It does.
The only 'not ok' tests have comments after them.
So I'm assuming that means ignore result.
dukeleto Yuki`N: they are probably "TODO" tests, which are allowed to fail 04:14
Yuki`N: awesome, send your pull request and I will check it out
Yuki`N Sent.
Also claiming the task on Melange.
dukeleto, If no PIR opcode calls a VTABLE method, can I still call it via callmethod? 04:21
dukeleto Yuki`N: that is a great question 04:23
Yuki`N: want to try and see? :) 04:24
Yuki`N: i don't know off the top of my head
Yuki`N I'll try, lol.
dukeleto Yuki`N++
Yuki`N What's a return continuation? 04:26
04:26 adu joined
dukeleto Yuki`N: it is a thingy that remembers the state of everything when it was created 04:29
plobsing Yuki`N: parrot uses CPS as a generalization of a call stack. calling a function involves the caller capturing a continuation. when the callee is finished, it invokes the continuatoin.
dukeleto Yuki`N: and you can pass it around to other things
Yuki`N Oh, I see.
Is it ok for me to just use callmethodcc? 04:30
dukeleto Yuki`N: in your string tests?
plobsing Yuki`N: you should use the syntax sugar PIR provides for function and method calls 04:31
$N0 = $P0.'method-name'($S0, $I0)
Yuki`N Oh that's nice. 04:32
Does it work for VTABLE functions as well? 04:34
dalek rrot: 19648f1 | plobsing++ | / (2 files):
eliminate static numbering of ops

static numbers for ops has no meaning. also, opsc generates number automatically now, rendering these completely unecessary.
also eliminate a nasty cast (op_func_t* => void** => (void*)() => op_func_t*)		 04:35
rrot: 1660edd | plobsing++ | / (2 files):
eliminate op documentation mentioning defunct CORE_OPS_*
plobsing Yuki`N: vtables and methods are distinct. you can't call vtables using the method call mechanism.
Yuki`N Oh.
plobsing it is a POLS violation we hope to resolve in a couple months 04:37
Yuki`N It's a shame. The only uncovered code left is in an "experimental" method and vtable functions not called in any opcode.
dukeleto, can you accept my claim to the melange task? www.google-melange.com/gci/task/sho...9176557195 04:38
cotto ~~ 04:55
dukeleto, ping
adu Yuki`N: so there are opcodes that are never used? 05:00
Yuki`N No, there are vtable functions that are never used.
dalek rrot: 352fa3c | plobsing++ | src/nci/framebuilder.pod:
add some documentation about pluggable framebuilder subsystem
 05:01
rrot: 1ebb549 | plobsing++ | MANIFEST:
mk_manifest_and_skip
05:14 simcop2387 left
Yuki`N dukeleto, unfortunately there's no simple way to cover the rest of the code in string.pmc 05:15
05:19 Yuki`N left 05:37 Kapace joined 06:22 bluescreen left 06:33 p_l|dmp is now known as p_l|backup 06:45 allison left 06:46 fperrad joined
Kapace Hello, Im am a Google Code-In student and I have claimed this task: socghop.appspot.com/gci/task/show/g...9182043556 06:57
this is what I have so far, if anyone could take a quick look: dpaste.com/284704/ 06:58
sorear Is load_bytecode "xxx.pir" deprecated yet? 06:59
cotto Kapace, I don't see anything obviously wrong with it, though you should be loading the .pbc file, not the .pir. 07:01
Kapace ok, brand new to parrot. whats a pbc file? compiled pir? 07:02
cotto yes
Kapace so, it doesn't do the automatic loading like python does with pyc files? 07:03
sorear Parrot is a multi-language system 07:04
If you load the .pir, you require the PIR compiler to be loaded
Yes, it will use the PBC if available, but it has to hit the PIR compiler first
Right now the PIR compiler is an unmaintainable C blob statically linked to Parrot, so you don't pay extra for "loading" it 07:05
But eventually it's going to be separated out
Kapace ok, but what if the PBC is not available. would it not make sense to load the PIR file in case it isn't, to compile? 07:06
cotto it should be available. It's part of the base install.
Kapace sorry if I'm being reluctant to go for this, but it goes against my python nature 07:07
ok, i guess that makes sense
sorear In Python you have 1 compiler
cotto we go both with and against many natures
Kapace i think that makes parrot a very interesting project
cotto I'm excited to see where we can take it. 07:08
p_l|backup PIR is th txtual representation while PBC files contain compiled bytecode, right? 07:13
*the textual
bacek_at_work p_l|backup, nope. PASM is textual representation. PIR is little bit higher. 07:14
but yes, PBC is Parrot ByteCode
Kapace where would one find the reference for the (builtin?) "say" function? 07:15
p_l|backup ah. Are there any languages that directly output bytecode?
(on parrot, that is)
cotto p_l|backup, not yet. 07:19
There's PIRATE, which outputs pbc from PIR and is written in PIR, but it needs some updates from Parrot before it'll be viable. 07:20
well, in nqp-rx which compiles down to pir
07:27 simcop2387 joined
p_l|backup is there anything using Parrot in "production"? While I know of Perl 6, I have yet to encounter any Perl other than good old 5.x on any machine. 07:27
(I'm looking because I'll be working on my own bytecode VM for Common Lisp implementation and decided to look into existing ones) 07:28
cotto p_l|backup, several Linux distributions include a release of Rakudo *. It's still at the early adopter stage though.
We have some major performance (and other) issues to overcome before we can call it production ready. 07:29
That said, Perl 6 is a great language and a lot of fun to write. I'd highly recommend playing with it if you don't mind the slowness. 07:31
p_l|backup cotto: I'd probably go mad at some point. Not because Perl is bad, but because of how comfortable I got with Lisp :) 07:32
07:35 theory left
Kapace should MappedByteArray have a method returning the filesize, or should I find that using other utility functions in the parrot library? 07:35
cotto Kapace, you can use elements $P0 07:36
that will return the number of bytes in the array 07:37
Kapace ah, didn't see that
is there a way to suppress the newline at the end of say ? 07:38
cotto if it doesn't make things worse, src/vtable.tbl lists all possible vtable functions
Kapace, use print
Kapace awesome, thanks
nopaste "cotto" at 192.168.1.3 pasted "suggested changes in md5sum" (13 lines) at nopaste.snit.ch/26832 07:43
cotto Kapace, ^
not quite complete, but it should be doable from there 07:44
Kapace ah, yes thanks
cotto nice work so far 07:45
nopaste "cotto" at 192.168.1.3 pasted "your program at work" (8 lines) at nopaste.snit.ch/26833 07:46
Kapace :D 07:47
cotto claim accepted, btw. You may now begin work. 07:49
07:50 adu left
Kapace haha 07:50
sorear why only the first 4 bytes? 07:51
Kapace because my test_data only had 4 bytes at the time, and I didn't know how to get filesize 07:52
its fixed now of course
cotto I'm glad you found the md5 library. I'd be sad if you reimplemented it unnecessarily. 07:53
Kapace yeah, its just you linked me to the MD5 wiki page
so i started to read it, and it describes the algorithm..
and I may have gotten carried away :P 07:54
07:54 TypeNameHere_____ left
cotto If you want to implement it knowing that we already have a working and tested version, that's fine too. 07:54
Kapace I would, but I'm a little rushed to get as many tasks done before the contest ends ;) 07:56
cotto your call 07:57
07:57 allison joined
Kapace how's it looking now: dpaste.com/284738/ (action: dpaste.com/284739/ ) 07:58
cotto Google likes us better than these guys: www.loritomgt.com/
Take that, nonsensical artist management people. 07:59
Kapace lol: "This web site is best viewed
with a resolution of
1024 X 768"
cotto It's a highly competitive world out there. 08:00
Kapace, nice work 08:01
stick it on melange and I'll give you a pass.
Kapace awesome, thanks: socghop.appspot.com/gci/task/show/g...9182043556 08:04
cotto done 08:06
Kapace great, I look forward to doing more parrot tasks :D
cotto me too 08:07
rfw oh dear god that website 08:09
Kapace rfw, oh hey rfw
rfw hey Kapace
Kapace melange giving you trouble?
rfw no, loritomgt.com is though
my eyes hurt
Kapace oh lol
rfw well, melange is always giving me trouble 08:10
so i selectively ignore that
Kapace cotto, it /is/ slow... i doubt its the MappedByteArray though 08:12
sorear more boys from Brazil? 08:13
Kapace but I'll compare with normal file 08:14
cotto sleeps, only about an hour late 08:15
Kapace good night!
cotto, quickly made a normal file io test and its still slow.. 08:23
details: dpaste.com/284749/ (main_m is MappedByteArray, main_nfio is normal file io) 08:25
08:42 contingencyplan left 08:54 jsut_ joined 09:00 jsut left
NotFound That program is using MappedByteArray to build a string, it doesn't exercise it's byte addressing ability. 09:15
09:24 rfw left 09:31 lucian joined
bacek aloha, humans 10:15
dalek rrot: ffa881f | (Gerd Pokorra)++ | t/pmc/string.t:
Merge branch 'master' of github.com/nol888/parrot into nol888-master
 11:13
11:32 fbrito joined 11:39 fbrito left 12:00 zby left 12:03 bluescreen joined
dalek rrot: b1b79f3 | (Gerd Pokorra)++ | t/pmc/string.t:
remove whitespace
 12:10
12:43 smash joined
smash hello everyone 12:43
tadzik hello smash 12:51
12:59 Kovensky left 13:09 Kovensky joined 13:19 lucian left
Coke HULK 13:33
ENOPURL.
aloha, HULK is <reply>HULK SMASH!
aloha Coke: Okay.
Coke aloha, hulk?
aloha Coke: HULK SMASH!
Coke close enough.
~~ smash.
13:36 whiteknight joined 13:38 p_l|backup left
whiteknight good morning, #parrot 13:43
14:35 bluescreen left 14:39 bluescreen joined
whiteknight src/packfile.c:Parrot_load_bytecode() is evil 15:02
not only does it load bytecode, but it also helpfully loads .pir and .pasm files too apparently
15:05 AzureStone left 15:10 AzureSto_ joined
cotto whiteknight, I approved the md5 task. I hope you don't mind. 15:11
whiteknight fine by me
I just assigned you a new RFC, I hope you don't mind :)
cotto fine by me 15:13
dalek TT #1885 created by whiteknight++: Parrot_load_bytecode should only load bytecode 15:15
TT #1885: trac.parrot.org/parrot/ticket/1885
rrot: 7842d27 | cotto++ | examples/pir/md5sum.pir:
add md5sum tool using MappedByteArray from Kapace++'s gci task
cotto yuck 15:16
whiteknight yuck? 15:17
Coke I posted a suggestion on the #1885.
cotto referring to the behavior mentioned in that ticket 15:18
whiteknight I want to start putting together an RFC for a standard interface for compiler objects 15:19
then I want to move IMCC over to the new interface 15:20
cotto a fire-based interface, perhaps? 15:22
whiteknight I think a compiler should have .compile_string, .compile_file, .eval_string, .eval_file, .validate_string, and .validate_file methods 15:23
.compile_* compiles the input and returns a Sub or Eval PMC that can be executed. .eval_* should compile and execute immediately, and .validate_* should verify whether it's a valid code file for that compiler 15:24
Coke whiteknight: still makes sense to have a new version with less power than to change the existing version.
whiteknight so .validate_ would parse the input to see if it parsed okay, or would do magic-number and header checking, etc
Coke: what do you mean?
Coke I mean, don't change the behavior of existing functions. 15:25
whiteknight Coke: even if they are stupid and misleadingly-named?
Coke yes.
particle that's what deprecation is for. 15:26
whiteknight particle: this would have to happen after a deprecation boundary, yes
Coke whiteknight: you can't deprecate something /in place/
you need to have the alternative in place ahead of time so people can switch.
whiteknight we have the alternative in place right now: the PIR compreg
people can use that, and they should use that 15:27
load_bytecode is being abused for this behavior, and the abuse should stop
Coke gives up.
whiteknight Coke: I'm not sure what other kind of alternative you think we need
15:27 Coke left
whiteknight if the alternative is to add in a new op that only does one thing and then remove load_bytecode entirely that doesn't really matter to me 15:30
NotFound whiteknight: I fail to see the usefulness, or event tha viability, of validating without compiling.
whiteknight Notfound: so maybe we don't need that part 15:32
I'm trying to think of a way to associate a file with a compiler, so we can say "load this file", and have Parrot go down the list asking each compiler to see if they can do it 15:33
but that may be a little bit too magical and error-prone
.eval_* and .compile_* really seem like the important ones to me, and .eval_* will probably redirect to .compile_* and then invoke the result 15:34
I'm trying to borrow existing interfaces and names from HLLCompiler as much as I can and still keep it general
NotFound A name for the role may also be nice. 15:35
whiteknight yeah. I was thinking does "compiler" is the most straightforward 15:36
NotFound WinxedCompiler isa HLLCompiler -> false
whiteknight Of course
if we create one standard interface, everybody is going to need to change a little bit
NotFound Yes, and "does" should be the way to declare we implement that interface. 15:37
whiteknight right
I want to have a Compiler PMC type too that takes Sub/NCI PMCs to perform each of these tasks. That way we can wrap the existing IMCC compiler into a nicer interface than it has now 15:38
15:39 Patterner left, Psyche^ joined
whiteknight And when IMCC has a nicer PMC-based interface, we can start untangling it from core and register it through the API like everybody else uses 15:39
15:39 Psyche^ is now known as Patterner
cotto <3 15:41
15:42 dmalcolm joined
NotFound Maybe we can do a proof of concept with a Class, and later convert to a PMC if needed. 15:43
whiteknight NotFound: that's fine too, but creates a bootstrapping 15:47
It's going to be hard to write a class in PIR that gets run BEFORE set set up the PIR compiler
15:47 cotto left
NotFound For the proof of concept phase is not a problem. 15:49
whiteknight how is that not a problem? 15:53
actually, nevermind. We could work around that if you really want
we could override VTABLE_invoke on the new compiler object to continue with the old behavior too 15:54
msg plobsing I want to set up a GCI task to move src/packfile.c, src/packout.c, and src/packdump.c into src/packfile/ directory like other subsystems use. This seem reasonable/acceptable to you? 15:56
aloha OK. I'll deliver the message.
NotFound The only problem I see is modifying compreg to return it instead of the current pir interface, but we can use an alternative name for testing. 15:57
whiteknight I've been staring at this code and I think it would be pretty easy 15:58
I need to add an API function to handle compiler registration, but that's trivial
actually, I could set up a GCI task to do that (if bluescreen hasn't already done it)
bluescreen its done whiteknight 15:59
sorry
whiteknight :)
Yes, it is done, though I suspect there is a bug in it 16:00
16:00 theory joined
whiteknight parameter "type" is a Parrot_String, but later you cast it to a char* 16:00
NotFound Maybe we can put all that in a library, leaving the core interpreter free of compiler related parts. That way we can get a nanoparrot almost free. 16:01
whiteknight A compiler registry is just a hash. Removing that doesn't seem like it would save us much
the bigger task is to break IMCC out of libparrot, and have IMCC register itself like any other compiler would
that would make libparrot much smaller 16:02
and we can do that almost 100% if we add the new compiler interface PMC and use the new embedding API
NotFound Just don't put that hash in the interpreter. The library can store in in its namespace.
whiteknight What's the benefit to that? Code in one namespace won't be able to detect and use compilers from other namespaces. 16:03
Perl6's eval("code", :lang(<foo>)) requires that
dalek tracwiki: v3 | whiteknight++ | APIFuncRenaming 16:04
tracwiki: trac.parrot.org/parrot/wiki/APIFunc...ction=diff
NotFound whiteknight: a library for loading and registering compiler, with its namespace inside ['parrot'] 16:05
The benefit is to get out of the interpreter parts that are not always needed. 16:06
whiteknight Okay, I see what you are saying. Again I suggest that the compreg stuff is very small. We can create the compreg hash lazily if we don't need it 16:07
there are other things we should cut out first. Open an RFC
16:07 AzureStone joined
NotFound I think the interpreter struct is already too bloated. 16:07
whiteknight no argument 16:08
cotto_work ~~
16:09 AzureSto_ left
cotto_work plobsing++ for nuking the static op numbers 16:10
whiteknight cotto_work: I want to set up GCI tasks to move the various frontend source files into src/frontends/*
(main.c, pbc_merge.c, pbc_dump.c, etc)
chromatic gave that idea a +1 a while back, but want to get more opinions before I jump on it 16:11
NotFound +1
cotto_work The only thing I'm not sure about is the name src/frontends/
whiteknight see, this is why I ask first :)
NotFound src/exe ? 16:12
cotto_work src/fe?
whiteknight I'm fine with whatever, but I would like to visually separate things that go in libparrot from things which do not
cotto_work absolutely
I could get used to whatever name you feel like using.
whiteknight you don't think src/fe is too obscure?
16:13 contingencyplan joined
cotto_work should it be under src ? 16:13
NotFound fe is faith in Spanish ;)
cotto_work we have compilers/ now
particle spell it out
cotto_work particle: that's probably the best idea 16:14
particle everyone looking at gc/ knows in the context of a compiler's source tree that means garbage collection
whiteknight cotto_work: ah, that makes good sense for src/main.c. But src/pbc_merge.c and src/pbc_dump.c are not compilers
particle nobody knows what fe/ is
cotto_work whiteknight: I mean that it should be under the root of the repo, not under src
NotFound An atom of iron.
whiteknight maybe src/main.c should move to compilers/imcc/main.c (since it really is just a wrapper around IMCC), and move the current compilers/imcc/main.c to compilers/imcc/imcc_main.c 16:15
cotto_work: so like frontends/* instead of src/frontends/*? 16:16
cotto_work yes
particle don't make the dir plural
whiteknight okay, that works fine for me. Subfolders under there?
particle: okay
particle src/pmcs/, src/gcs/ ...
cotto_work compilers/
whiteknight frontend/parrot, frontend/pbc_merge, frontend/pbc_dump? 16:17
NotFound All .c files are under src, except the ones in compilers/imcc
cotto_work there'll be more than one frontend. Why not use the plural? 16:18
whiteknight there is more than one gc, and we do src/gc/
(I'm not arguing for either name, just pointing out a parallel)
cotto_work both have parallels. Use whichever makes the most sense to you at the time. 16:19
whiteknight okay, I'll start setting up the GCI task for this
cotto_work I'd say "frontends", but the person implementing gets the most votes.
particle it'd be easier to fight for one over the other if our dirs were consistent in case 16:22
but they're not... quite.
cotto_work agreed 16:23
particle i really wish when i originally re-organized the src tree 6 years ago or so that i had named docs/ doc/
cotto_work Is it too late now? 16:24
particle it'd be pretty hard, but not impossible. 16:25
16:25 plobsing_ joined
particle it requires updates to things outside the repo, like websites and such 16:25
i'm not sure it's worth it.
16:25 Andy left
plobsing_ ā‰ā‰ 16:27
whiteknight good morning plobsing_
I just aloha'd you an msg to your non-underscored username 16:28
plobsing_ reads logs
whiteknight short version: I want to set up a GCI task to move the packfile-related stuff into src/packfile/* 16:29
plobsing_ moving all packfile related stuff to a separate folder is a *very* good idea.
I'm not sure we should keep the distinction between packfile.c and packout.c. It's kinda blurry. 16:30
whiteknight plobsing_: packfile.c, packout.c and packdump.c. Anything else you think we need moved?
cotto_work there's some stuff in imcc
compilers/imcc/pbc.c for one
whiteknight I am having a hard time figing out where exactly pmc_freeze.c fits in
plobsing_ packdump.c, iirc, only implements stuff for pbc dump. I'd like to see that move out of libparrot eventually. 16:31
cotto_work: ah, but imcc/pbc.c only really makes pseudo-sense in the context of imcc
whiteknight plobsing_: Ah, I'm also looking to move front-end code to frontend/, so I could move that to frontend/pbc_dump/pbc_dump.c
plobsing_ pseudo-sense because nothing in imcc truly makes any sense
cotto_work I got that. Nice wording.
whiteknight okay, I'm going to set up a new GCI task to move packfile.c and packout.c to src/packfile/. We can work on cleaning up that subsystem and redistributing functions to files later 16:32
pbc_dump.c I will move out eventually into frontend/pbc_dump/dump.c, when it's time for that and remove it from libparrot 16:33
plobsing_ whiteknight: pbc_dump is a little tangled up with the packfile struct vtable-ish function tables ATM
whiteknight right
so we can be ginger about it for now
plobsing_ src/pmc_freeze.c could be moved to src/packfile/object_serialization.c or something to that effect 16:34
whiteknight okay, I like that
who do we have that speaks Polish? 16:50
plobsing_ whiteknight: (re: compiler role API) I'd like to suggest that compilers also be able to provide a means of executing a single line (possibly with a persistable context like rakudo's repl). This could be useful in applications which want to have a repl interface (eg: parrot-debugger, vim, etc)
whiteknight plobsing: that would be very nice, though I suspect it would be the hardest to accomplish. Especially for the PIR compreg 16:51
we can definitely give it a shot though
plobsing_ I didn't say all compilers need to implement it.
whiteknight ok
plobsing_ PIR implementation could be "throw new ['NotOnYourLifeException']" 16:52
dalek tracwiki: v178 | whiteknight++ | WikiStart 16:54
tracwiki: trac.parrot.org/parrot/wiki/WikiSta...ction=diff
whiteknight plosbing: is there a way to generate a .pbc file from PIR code? 16:55
pmichaud is suggesting in TT #1885 that there isn't
plobsing_ There is, but you can't readily get at it from PIR.
NotFound The idea, for me, is to provide a standarized way to do common things, not to force compiler doing anything we can imagine.
particle i speak reverse polish ;) 16:56
whiteknight plobsing_: Okay, next question is obvious: how to we get at it from PIR? New opcode? New PMC with methods?
plobsing_ new method on PIR compreg in anticipation of compiler API
whiteknight the PIR compreg is currently an NCI PMC pointing to a function in IMCC
plobsing_ compile-to-file should be part of compiler role as well
whiteknight plobsing_: I'm more envisioning that .compile will return a PackFile PMC or whatever the future equivalent is, and then we can write that to file using a method on PackFile 16:57
though that's probably way out in the long term
plobsing_ well, if we're using packfiles as the means of getting things into files, we could get Eval to give us a handle to its internal packfile. 16:58
Eval is really just a thin, convenient, and crufty wrapper over a packfile. 16:59
whiteknight my thinking is that once we have a packfile PMC, we can execute it directly (which would default to executing :main), or we could write it to file, or we could look like individiual Subs in it like a library and execute those, etc
or, we should be able to do all those things
plobsing_ oh wait, we already have that. Eval.get_string()
whiteknight and that does...? 17:00
plobsing_ gives you a string containing the packfile
whiteknight and don't tell me it returns the stringified packfile
damnit
plobsing_ i could tell you otherwise, but I'd be lying
whiteknight a pity that lies would be so sweet 17:01
The nuclear option of "delete everything and start from scratch" looks just a little bit more attractive every time I talk about this stuff 17:02
plobsing_ Eval.get_string() provides a means of acheiving what pmichaud wants. it's not great, but it'll do. ideally we wouldn't even have an Eval pmc. allison had an RFC about that IIRC.
whiteknight okay, so let's talk about removing it first. What would we need to replace it with? Are the PackFile family of PMCs ready for this kind of use? 17:04
cotto_work whiteknight: no. They don't know about opmaps yet.
17:05 mtk joined
cotto_work bacek++ made a couple commits to the opmap branch though. 17:05
NotFound We should put the PackFile PMCs to full use, otherwise they'll get bitroten every time we chnage something.
cotto_work NotFound: that's exactly what I want to do. 17:06
only have one implementation of packfiles (the PMCs) so that it can't bitrot without horribly breaking everything
plobsing_ packfile pmcs were designed to be convenient as an external API for packfiles. they currently have little to no consideration for internals. we need a two-layer approach (currently the struct/pmc duality, but eventually a delegation-style wrapper)
whiteknight plobsing: I don't see why we can't have a single implementation 17:07
a Packfile structure wrapped inside a PackFile PMC. The get_pointer/set_pointer VTABLEs let us get at the underlying implementation 17:08
the PMC provides nice methods and a nice storage mechanism for the structures, in addition to GC magic, etc
plobsing_ yes. but that is more-or-less the separation I'd like to see.
NotFound plobsing_: I'm fine with a two layer approach, if the front layer is used. 17:09
whiteknight So long as Parrot passes packfiles around in PMC form, and embedders/extenders can use that form to pass them around, I don't really care how the internals look
plobsing_ I explicitly do not want the internals to have to deal with something that has design considerations for convenience of external uses.
NotFound imcc should not be 'internal'
whiteknight that's fine. Anything in src/packfile/* can assume the struct, everything else can pass an opaque PMC
plobsing_ runcores and ops need some pretty intimate details about running packfiles 17:10
NotFound plobsing_: fine with that.
whiteknight okay, those guys can access the guts too
plobsing_ you don't want to VTABLE_get_integer_keyed_int to find the next op do you?
dalek tracwiki: v1 | whiteknight++ | CompilerInterfaceDesign
tracwiki: trac.parrot.org/parrot/wiki/Compile...ction=diff
whiteknight but having access to packfile guts should be opt-in with a very limited guest list
cotto_work +1
plobsing_ agreed. and compilers (including IMCC eventually), should not be on that list. 17:11
NotFound And pir compilers should not be on that list.
whiteknight plobsing_: EXACTLY!
cotto_work PIRATE already isn't
I like where this is going.
NotFound imcc is, now.
whiteknight if you look at src/main.c in the embed_api2 branch you see that idea: I pass IMCC a filename and return a PMC from it. Then, I pass that PMC into libparrot to execute
of course the PMC in question is an UnManagedStruct with a Parrot_Packfile pointer, but I have acheived some level of abstraction 17:12
it is possible to do in the general case
NotFound whiteknight: but to avoid bit roten we need much more.
plobsing_ to avoid bitrot, we need the external api to *not* reimplement the internal implementation 17:13
delegation is key
whiteknight right. The embedder shouldn't even have to be aware of what the PackFile PMC is: The embedder takes a PMC from a compiler and passes it to the execution engine. No questions asked 17:14
plobsing_ must leave
17:14 plobsing_ left
NotFound We need to use it, mainly. Delegation is the way to make it doable. 17:14
whiteknight my thinking is this: A compiler takes code and returns a PackFile PMC. The embedding application can then attempt to execute that, or write it out to a .pbc file, or analyze it, or whatever 17:16
If we try to do it the other way around, where the embedder calls the compiler, and the compiler calls libparrot, the compiler is going to need a pretty big API of it's own 17:17
NotFound The compiler may need to call libparrot, :immediate subs for example. 17:20
cotto_work It makes me really happy to see what the Rakudo hackers are building on top of Parrot. 17:23
atrodo cotto_work> ping 17:27
cotto_work atrodo: pong
dalek tracwiki: v1 | whiteknight++ | IMCCTasklist
tracwiki: trac.parrot.org/parrot/wiki/IMCCTas...ction=diff
tracwiki: v2 | whiteknight++ | IMCCTasklist
tracwiki: More steps.
tracwiki: trac.parrot.org/parrot/wiki/IMCCTas...ction=diff
atrodo cotto_work> Tonight is the Lorito braindump, right?
cotto_work yes
atrodo I'm anxious to see what comes of it
(I would tell you that it kept me up all night, but that would a lie. The dreams last night, however...) 17:28
cotto_work I'm looking forward to it. 17:29
PerlJam hopes atrodo is really eager to see what comes of it. 17:30
atrodo PerlJam> Yes 17:31
cotto_work I don't think we'll get a fully-formed spec out of the meeting, but we will get much closer to one . 17:35
atrodo cotto_work> I am celebrating proto-lorito month this month. But with this coming up, I've not worked on it as much as I wanted.
Hopefully after tonight I can start more on it in a more concrete direction 17:36
17:54 M_o_C joined 17:56 M_o_C_ joined 18:00 M_o_C left 18:06 zarchne left 18:15 M_o_C_ left 18:16 M_o_C joined 18:25 ligne joined 18:33 smash left 18:50 davidfetter joined 19:04 mtk left 19:10 mtk joined 19:14 davidfetter left
cotto_work moritz: ping 19:29
19:30 rfw joined 19:31 fperrad left
dalek nxed: r706 | NotFound++ | trunk/winxedst1.winxed:
refactor Function hyererchy and fix subid generation
 19:33
moritz cotto_work: pong 19:34
cotto_work moritz: can you review the gci task to translate parrot.org/foundation into German? 19:35
socghop.appspot.com/gci/task/show/g...9141648612 19:36
moritz cotto_work: done. It's fine. 19:38
cotto_work thanks
19:42 dngor left 19:44 Yuki`N joined
cotto_work hi Yuki`N 19:45
Yuki`N Hi.
I submitted my work to melange. 19:46
19:47 dngor joined
whiteknight This IMCC crap keeps getting uglier and uglier every time I look at it 20:06
cotto_work Yuki`N: approved
Yuki`N Thanks. 20:07
whiteknight compiling a .pir file causes :init and :immediate (and :postcomp, if that still exists) subs to trigger EXCEPT when we compile it through the load_bytecode op, in which case on the :load ones are triggered
only the :load ones* 20:08
cotto_work Now we have 4 of the top 6 gci students contributing to Parrot. This is kind of amazing.
whiteknight cotto_work: isn't it? 20:09
I need to make more tasks!
cotto_work There's a handful if you look for the gci tag in our ticket queue.
whiteknight how do you view just the tickets with a particular tag? 20:10
cotto_work view tickets->custom query-> filter for keyword 20:11
dalek tracwiki: v2 | whiteknight++ | CompilerInterfaceDesign
tracwiki: redo this page, Add handling of :load/:init. We should be able to tell the compiler to trigger one or the other. Remove literal list of method names, reduce to a list of concepts.
tracwiki: trac.parrot.org/parrot/wiki/Compile...ction=diff
cotto_work trac.parrot.org/parrot/query?col=id...r=priority
sorear let's add src/pmc/IMCC.pmc, and require all access to IMCC to go through that 20:19
create an IMCC pmc and stash it in the compiler hash
it has to implement VTABLE_invoke, obviously
cotto_work there'd be a lot of fakery involved, but that sounds like the kind of interface we'll want other compilers to use. 20:20
sorear of course IMCC.pmc will have almost no code 20:21
it'll just call a bunch of C functions elsewhere 20:22
Yuki`N I was going to try for another 5% to the string PMC but all the methods that aren't covered are inaccessible from PIR. 20:26
moritz are they called at all?
cotto_work aloha, coverage? 20:27
aloha cotto_work: coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
sorear It shouldn't be possible to have a string PMC method be inaccessible
cotto_work Some of those VTABLE functions need to go away. 20:28
You should be able to test unescape pretty easily 20:29
share_ro and substr probably don't need to continue existing
You could also make sure the exception conditions get hit. 20:30
cotto_work goes afk for lunch
NotFound There is a ticket for the substr vtable
20:32 jan left 20:35 jan joined
whiteknight I think I'm going to have to start a pretty big refactor soonish 20:39
I'm going to move all functionality from libparrot that explicitly uses IMCC, and move it all into a die/ folder 20:40
so die/in_a_fire.c for example
then we go through the list, piece by piece, either reimplementing items to not rely on IMCC or eliminating them entirely 20:41
and when the file is empty, we rejoice
Yuki`N I'm not quite sure how to make the exception conditions get hit. :P
whiteknight Yuki`N: which conditions? line numbers?
Yuki`N Umm
whiteknight or what file/function are you in? 20:42
Yuki`N src/pmc/string.pmc
675 and 735
aloha 1410
whiteknight for the one on 675, use a non-ascii literal in PIR with the trans method 20:44
so $P0.trans(unicode:"whatever", ...)
Of course now that I look at it, that method is stupidly named if it only accepts ASCII
for the one on 735, do the same technique 20:45
use unicode: at the beginning of the string to force it to be non-ASCII and that should trigger it
(Again the function is poorly named)
Yuki`N Oh.
That's cool.
whiteknight very cool 20:46
Thanks for the help, Yuki'N
Yuki`N And yes the unescape function is actually simpler than I though now that I look at what unescape actually does.
No problem.
20:46 bluescreen left
whiteknight yeah, it's deceptive 20:46
Yuki`N I assume I should catch the exception thrown.
20:46 Andy joined
whiteknight yeah 20:49
dukeleto Yuki`N++ # adding test coverage! 20:55
Yuki`N: you should also add yourself to CREDITS in your next pull request
karma Yuki`N 20:56
aloha Yuki`N has karma of 0.
Yuki`N xD k.
dukeleto Yuki`N: when you are in CREDITS, our bots keep track of all your ++'s
Yuki`N: which is called "karma"
Yuki`N Ah.
21:03 perlite left 21:04 perlite joined 21:05 bluescreen joined
Yuki`N <Yuki`N> METHOD trans(STRING *src, PMC *table) 21:10
<Yuki`N> What PMC is `table' supposed to be?
whiteknight that's a really good question. Are there any other examples of the trans method being used in the test suite? 21:12
Yuki`N Hmm.
Looks like it's a FixedIntegerArray. 21:13
whiteknight weird
Yuki`N Are the .t files UTF-8? 21:15
whiteknight they might be 21:16
Yuki`N Just wondering; I realized I didn't actually need UTF-8 text.
whiteknight if you specify unicode:, the assembler will automatically setup the encoding 21:17
Yuki`N Yeah.
So there's already a ticket for substr? 21:19
dukeleto Yuki`N: take a look at trac.parrot.org
Yuki`N And how does MULTI INTVAL is_equal(PMC *value) work?
MULTI vs VTABLE. 21:20
dukeleto Yuki`N: MULTI means it is a multimethod
Yuki`N: which means various versions of the function exist, depending on what the input argument types are
Yuki`N: MULTI tells parrot this is not the only definition of the function, others for other input types could exist 21:21
Yuki`N Ah.
dukeleto Yuki`N: that is how I understand it, at least
whiteknight that's how it is
Yuki`N Well I see. 21:22
VTABLE INTVAL is_equal(PMC *value)
MULTI INTVAL is_equal(PMC *value)
The latter is not covered at all, although it's only a return;
whiteknight those two are in the same file? 21:23
Yuki`N Yeah.
whiteknight are there any other MULTIs for is_equal?
Yuki`N Nope.
whiteknight that's a bug. Delete the MULTI
Yuki`N The whole method?
whiteknight hold on, let me double-check
Yuki`N K.
whiteknight yeah, delete it. It's only 3 lines 21:24
Good job finding that!
Yuki`N xD all in the name of test coverage.
whiteknight we can always increase coverage in two ways: add more tests or delete more code 21:25
Yuki`N Indeed.
whiteknight sometimes the second option is better :)
Yuki`N So I believe now the only uncovered code are the two VTABLE methods 21:26
void substr
whiteknight okay, it's time for me to pack up and go home. goodnight
Yuki`N and share_ro
Night. 21:27
21:27 whiteknight left
dukeleto Yuki`N: are you still working on the same task? 21:27
Yuki`N: i need to give you a new task :)
Yuki`N: do you want to work on tests for another subsystem?
Yuki`N Umm, perhaps. :P 21:28
I already more than covered the 5% from my last addition of tests.
I'm going for ~95% now I think.
dukeleto Yuki`N: that sounds great. I want you to get credit for that, though.
Yuki`N: I can make a new task, so you get more GCI points, since you are doing much more work than that task requires. But if you don't care, that is fine with me :) 21:29
Yuki`N: i am very excited that you are increasing our test coverage so much! This is awesome
A GCI student just translated our README to Polish!
Yuki`N xD I saw that pull request. 21:30
If it's not too much trouble to make another task, sure.
And I'm open to increasing coverage for other PMCs too.
dukeleto Yuki`N: of course! I want you to get the credit you deserve
Yuki`N I mean, I took the trouble of learning PIR for one task.
:P
dukeleto Yuki`N: are there any subsystems that interest you? Anything that needs more test coverage is fine for you to work on 21:31
Yuki`N: now that you know PIR, we really want you to work on more tasks! ;)
Yuki`N Not really, I'll look through the list in a bit.
dukeleto Yuki`N: would like to send a pull request for what you have now? I will create a new task right now.
Yuki`N I'm just checking to make sure I really did cover those methods 21:32
Once I typo'd eq_num into eq_str and I ended up re-covering eq_str.
cotto_work Yuki`N: you can always run the test under gdb and set a breakpoint 21:33
dukeleto Yuki`N: are you running "make cover" ?
Yuki`N Yeah.
dukeleto cotto_work: we have our REAME in Polish!
cotto_work Is it polished Polish?
dukeleto cotto_work: i only created the task last night and it is done already!
tadzik: ping
aloha msg tadzik can you take a look at this? github.com/parrot/parrot/pull/22 21:34
aloha dukeleto: OK. I'll deliver the message.
Yuki`N Hmm. 21:35
make library_tests failed.
21:36 M_o_C left
dukeleto Yuki`N: feel free to make a gist of the full error output and we can look at it 21:36
Yuki`N: you only added tests, correct?
Yuki`N I only added tests.
dukeleto Yuki`N: ignore test failures that happen as part of "make cover"
Yuki`N Ah ok.
dukeleto Yuki`N: are these tests failing under "make cover" or "make test"
Yuki`N Make cover.
In the profiling stage. 21:37
dukeleto Yuki`N: our test coverage stuff makes some tests fail because stuff gets printed out and makes tests fail. You can ignore those.
Yuki`N Ah.
dukeleto Yuki`N: that is Less Than Awesome, but that is how it is right now.
Yuki`N src/pmc/string.pmc\t95.3\t95.3 :D 21:38
dukeleto Yuki`N: awesome!
Yuki`N: i have a new task for you, please do a "submit" action on the task you have now 21:39
Yuki`N: socghop.appspot.com/gci/task/show/g...9193070805
21:40 kid51 joined
kid51 I have a colleague who can review the Polish translation of the README submitted earlier today. 21:40
I will not be around tonight. 21:41
Yuki`N dukeleto, sent a pull request, and requesting claim on that task.
kid51 Can someone email me or msg me as to what the next steps would be if colleague either approves or wants corrections? Thanks.
dukeleto Yuki`N: i see. the old task is already closed. Good work!
Yuki`N: claim that new task now! Before someone else does.
kid51: what now? 21:42
Yuki`N Claimed.
dukeleto Yuki`N: approved.
Yuki`N: have fun! 21:43
Yuki`N Submitted for review. :3
dukeleto Yuki`N: wow!
cotto_work Yuki`N: how responsive have other orgs been? I'm wondering if we're doing something special to get so many contributions.
dukeleto cotto_work: it is because I am so awesome...
cotto_work dukeleto: quite possible 21:44
Yuki`N cotto_work, I've found that Parrot has had at least one mentor on 24/7.
And all the mentors are familiar with the subject matter of most of the tasks.
dukeleto Yuki`N: can you make that commit into a pull request?
Yuki`N I have already. :P
dukeleto Yuki`N: you are fast!
Yuki`N Indeed.
atrodo I agree, it's because of dukeleto
dukeleto Yuki`N: why did the is_equal MULTI get deleted? 21:45
Yuki`N [16:23:11] <@whiteknight> those two are in the same file?
[16:23:15] <Yuki`N> Yeah.
[16:23:28] <@whiteknight> are there any other MULTIs for is_equal?
[16:23:33] <Yuki`N> Nope.
[16:23:39] <@whiteknight> that's a bug. Delete the MULTI
21:45 mtk left
dukeleto Yuki`N: sounds good to me. 21:45
Yuki`N Yep.
dukeleto Yuki`N: i completed your task. You need a new task now! 21:46
Yuki`N: do you have one in mind?
Yuki`N Indeed I do.
Let me look through the list.
dukeleto Yuki`N: go claim it! And let me know when you do.
atrodo Can students only have one task at a time?
Yuki`N Yeah.
dukeleto, the scalar pmc has some pretty dreadful test coverage. 21:47
Below 50%.
cotto_work technically they're also supposed to work on only tasks that they've claimed.
Yuki`N Technically.
I find that I'm usually waiting on mentors so I usually am working on like 3 tasks at once.
Time zones and the like.
cotto_work I'd like to kill scalar, but I haven't entirely convinced myself that it's a good idea. 21:48
Yuki`N Oh, so it's not a good candidate to improve coverage for? 21:49
dukeleto Yuki`N: you are very smart to work on things like that 21:50
Yuki`N Thankfully I've only had a task stolen from me once.
21:50 bluescreen left
Yuki`N And I hadn't started work on it at least. 21:50
dukeleto Yuki`N: heh :) Which PMCs have the lowest coverage, other than Scalar ?
Yuki`N socket has some pretty low coverage, but understandably so. 21:51
cotto_work I made a list of PMCs that would be good for gci students to work on. I wish I could remember where I put it.
dukeleto Yuki`N: how about Complex PMC ? Would you like to work on that ?
Yuki`N: that really needs to have 100% test coverage
Yuki`N Complex numbers?
dukeleto Yuki`N: yes. Also, the Integer PMC 21:52
Yuki`N I suppose I can.
dukeleto Yuki`N: and the Iterator PMC
Yuki`N Complex, Integer, and Iterator.
I'll probably tackle the Integer PMC first.
dukeleto Yuki`N: i will make tasks for them. Making an integer PMC task now.
Yuki`N Thanks!
cotto_work OrderedHash might be a good candidate
Yuki`N One task per PMC, I suppose? 21:53
cotto_work at least one task per pmc
you just got two for one, didn't you? ;] 21:54
Yuki`N That is true. :3
Integer is about 55% right now.
Something similar to 75%, 85%, 90% seems like a fair graduation, if not an excess of tasks. 21:55
Perhaps only two tasks, but who knows.
dukeleto Yuki`N: socghop.appspot.com/gci/task/show/g...9193177076 21:57
Yuki`N: that is for 10% increase in coverage of Integer PMC
Yuki`N: i can give you as many tasks it takes to get Integer PMC to 100%
Yuki`N That's a generous amount. :P
dukeleto Yuki`N: Tasks need to get harder, or you won't have the appropriate amount of fun :)
Yuki`N My first suggestion was about a 20% increase. xD 21:58
I see >Currently, the Integer PMC is at 83% code coverage
;P
PIR is fun, but at the same time a unique challenge. 21:59
dukeleto Yuki`N: it has 83% already? You sure?
Yuki`N No.
It's 55%
But the task says 83.
dukeleto Yuki`N: duh! My bad. I will fix that.
Yuki`N I like bytecode intermediate languages just because they blend an ASM feel with higher-level features.
Like MSIL is fun to write short programs in; unfortunately there is no real benefit to writing code in MSIL vs C#, unlike ASM vs C. 22:00
dukeleto Yuki`N: what kinds of assembly have you done before? 22:01
Yuki`N I've looked at and can kinda read x86 asm.
Tried learning SIMD extensions for some VideoLAN tasks but that failed horribly.
I'm rather good at MSIL. I've done some tasks for the Mono Project involving code analysis, and that helped a ton. 22:02
And of course now I'm familiar with the Parrot VM and PIR.
dukeleto Yuki`N: fixed the task info
Yuki`N: that is awesome to hear! We have lots of tasks to keep you learning and having fun. Just ask me about stuff that you want to work on, if there isn't a task about it. 22:03
Yuki`N: i just added tasks for the Iterator and Complex PMCs too
Yuki`N K.
Requesting claim on the Integer task.
dukeleto Yuki`N: approved. 22:06
22:15 kid51 left
Yuki`N How do I use gdb to run a PIR file, btw. 22:16
moritz gdb parrot 22:21
run yourfile.pir
sorear moritz: gdb --args parrot yourfile.pir # best option ever
moritz sorear: I didn't know about that, thanks 22:22
Yuki`N And how would I bp at a specific pir line.
moritz I don't think you can't
because gdb is not a PIR-level debugger
Yuki`N Oh. 22:23
I'm trying to trigger integer overflow.
And it's not working.
sorear $I0 = 1
again:
say $I0
$I0 = $I0 * 2
goto again
Yuki`N There we go. 22:24
dukeleto Yuki`N: there is something called parrot_debugger, but it may still have some bugs itself :) 22:25
Yuki`N Ah.
dukeleto Yuki`N: it can step through PIR, in theory
22:33 dmalcolm left 22:48 whiteknight joined
whiteknight heh. It looks like one of our GSoC students is a 4chaner 22:53
NotFound Integer registers are not Integer PMC
23:11 bluescreen joined
dukeleto whiteknight: what now? 23:11
cotto_work: ping 23:14
23:36 nwellnhof joined
nwellnhof Yuki`N: have you seen my comment to your pull request? 23:36
whiteknight dukeleto: githubber nol888 (who opened a pullrequest with us a while ago) has a 4chanscraper project 23:38
dukeleto whiteknight: ah 23:39
dukeleto is excited about the lorito hacking session tonight 23:40
whiteknight ah right, I forgot about the Lorito magic that is happening soon 23:42
dukeleto ~2ish hours until lorito meeting 23:43
nwellnhof is a lorito meeting scheduled?
in #ps? 23:45
whiteknight cotto, chromatic, and allison are having an in-person meeting
dukeleto nwellnhof: chromatic, cotto, allison and I will be talking about Lorito and creating an action plan, methinks.
allison nwellnhof: it's f2f, but we'll be on IRC too, and on a conf call if anyone wants to join by phone 23:47
sorear I have to leave before the meeting 23:54

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!