Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
00:07 davidfetter left 00:14 dmalcolm left
soh_cah_toa whiteknight++ indeed. finally some decent docs for winxed. very nice 00:22
00:30 lucian_ is now known as lucian
lucian hugs whiteknight in a totally non-awkward way 00:30
whiteknight thanks! It's clearly not complete or anything
a good starting point 00:31
lucian still very useful, especially the list of builtins
whiteknight also it's in the rosella repo now, so pull requests accepted
dalek rrot: 88938d0 | soh_cah_toa++ | src/call/pcc.c:
Added missing =cut that was messing up perldoc
 00:37
whiteknight lucian++ on the blogpost 00:42
lucian whiteknight: thanks, it's just narration 00:43
whiteknight lucian++ on the narration 00:45
lucian :) 00:46
whiteknight++: in winxed, is using an expression? 00:47
whiteknight i don't think so 00:48
I thnk it's a statement
lucian it bothers me that the last name in the chain is just bound locally 00:49
whiteknight yeah 00:50
i never liked that too much either
there is a "using namespace" statement that's newer and probably does more of what you want
lucian yeah, that does sound better 00:51
whiteknight but that's for static searches only. Doesn't work for dynamically loaded libaries 00:52
lucian hmm
bleah, the named arg calling syntax is yucky 00:53
declaring syntax isn't much better, but i understand why
Tene somehow, the only code that I've actually written for personal projects in the past year or so has all been tiny little toys doing shit with dynamically loaded libraries.
soh_cah_toa cotto: i've run into an issue. Parrot_sub_get_line_from_pc() only reports the line number if there's an opcode. if there's anything else like ".local pmc foo", it does nothing 00:57
cotto: not only that but it seems to be giving me -1 randomly. sometimes a legimate number, sometimes -1. it's weird
lucian i think i found a bug in winxed, or at least a missing feature 00:58
whiteknight lucian: what? 00:59
lucian it uses .line for marking line numbers, and the docs recommend .annotate
if i understand this correctly, that's the reason parrot doesn't report line numbers on failures in winxed files 01:00
whiteknight where, in the generated PIR?
lucian yeah
whiteknight when I do it, I see ".annotate 'line' XX" 01:01
lucian you do? odd. let me try again
cotto ~~ 01:02
lucian oh, me too. i'm confused, why did i see .line yesterday
cotto need nom
lucian whiteknight: oh, btw, i ended up writing a python distutils command for building winxed and pir
cotto will investimagate in a bit
whiteknight lucian: oh, nice 01:03
lucian if it works out well, i'll probably put it on PyPI or something
01:06 benabik_ joined 01:08 benabik left, benabik_ is now known as benabik
soh_cah_toa man, i am so stumped. there really is no legimate way to find line numbers in pir code 01:16
even w/ annotations it's difficult b/c (at least in winxed) annotations only start at the first statement. any comments or "function foo()"'s before the first statement don't get annotated
scratch that. comments aren't annotated at all
sorear comments don't need to be annotated 01:17
soh_cah_toa but what if i want to stop at one?
break that is
whiteknight soh_cah_toa: I figured it was going to be hard. I didn't think it was impossible
sorear gdb doesn't allow breaking on comments
why should you?
only allow breaking on executable code
soh_cah_toa it doesn't? i was pretty sure it did 01:18
soh_cah_toa checks
sorear if the user tries to break on a comment, gdb instead breaks on the first executable code after the comment
cotto If someone wants to do something silly like break at a comment, cheat.
do what sorear said
soh_cah_toa yeah, i just tried it. that's exactly what it does 01:19
cotto I'm not sure if you'd even call that cheating. 01:20
soh_cah_toa i also can do a "run to main" type thing b/c things like "function foo()" aren't annotated as well 01:21
*can't
cotto You don't need annotations for that. Just check the current context for the function name. 01:22
benabik One last NQP question for the night: Is `self.meth(|%hash)` the same as PIR's `self.'meth'(hash :flat :named)`?
sorear yes 01:23
soh_cah_toa agh, i'm not even gonna try going into context's tonight. i have a big enough headache already. stopping at function definitions will be another day
benabik Converting PIR to NQP is very educational about what PCT does. 01:24
bubaflub benabik: are you rewriting stuff that was in the Q:PIR { } blocks into NQP? 01:25
benabik bubaflub: Yes.
bubaflub benabik: fantastic.
benabik bubaflub: github.com/Benabik/parrot/commits/nqp_pct
bubaflub benabik: great work - that's much much simpler 01:26
benabik bubaflub: The resulting PIR is much larger in most cases. 01:28
bubaflub benabik: really? is that because of the inefficiency of generated PIR? 01:29
benabik bubaflub: Mostly, yes. PCT is not smart enough to do things once and cache the results, and it spends a decent amount of time boxing and unboxing. 01:30
bubaflub: I don't expect that the final result will be too much slower. (timewise) 01:31
01:31 bacek left
bubaflub benabik: interesting. i imagine having stuff in NQP will be easier to optimize later, right? 01:32
benabik bubaflub: It will make it easier to change, really. Making the computer work a bit harder in order to reduce programmer time.
bubaflub: Also, I hope that PCT will learn to be better.
bubaflub benabik: great. 01:34
benabik bubaflub: An earlier GSoC project: github.com/parrot/tree-optimization - should make it possible to do nice optimizations. 01:37
cotto soh_cah_toa, no problem. I think you'll discover that finding the function name is much easier than dealing with annotations.
bubaflub benabik: ah, i remember that one.
soh_cah_toa cotto: i hope so 01:38
cotto soh_cah_toa, I see you made a commit to master. Do you want to move your branch to parrot/parrot? 01:48
soh_cah_toa sure
01:55 kid51 joined 01:58 whiteknight left 02:00 bubaflub left 02:02 kid51 left
soh_cah_toa what header file do i need to #include to use CONST_STRING()? gcc is whining about an undefined reference 02:03
cotto It's a magic macro that gets converted by c2str.pl 02:04
The easier answer is to use Parrot_str_new_from_cstring (or the similarly named function that exists)
Parrot_str_new_constant 02:05
benabik I should probably move the stable bits of my fork into parrot/parrot. Of course, I made a bunch of changes to what I thought was stable earlier.
cotto Go for it. We're adventurous.
benabik And I could close my ticket on PDD 19. :-D 02:07
dalek rrot: 51ee42f | (Brian Gernhardt)++ | docs/pdds/pdd19_pir.pod:
PDD 19: Explain :method :multi(_)

I didn't expect :multi to need to add the type of the invocant. So let's add an explanation to the first place I looked for an answer.		 02:12
cotto benabik, you can add yourself to CREDITS with an a: line for your irc nick and an e: line for your github email address and dalek will credit your irc nick 02:16
benabik cotto: That sounds clever.
cotto we love our hacks
why do you think we have so many? ;)
benabik Alphabetical by N: field? 02:17
cotto something like that
t
dalek rrot: c2e3158 | benabik++ | CREDITS:
Add myself to CREDITS

I like getting credit for things.		 02:19
soh_cah_toa cotto: i'm not sure if i already asked this but is there a way to retrieve any annotations that are in effect given the current opcode (pc)? maybe a pc->anno that returns a PackFileAnnotation pmc? 02:20
cotto benabik, and it worked
benabik Let's see if the other thing worked. 02:21
dalek Heuristic branch merge: pushed 1500 commits to parrot/nqp_pct by Benabik
benabik :-D
GSoC week 2 and I've already pushed 1502 commits. 02:23
cotto soh_cah_toa, I think so. Let me check. 02:24
actually, I remember my answer: the annotations ops 02:25
lucian i think my commit messages are getting a bit too long
soh_cah_toa oh yeah
benabik lucian: I generally like descriptive commits, although I try to keep the first line short. 02:26
cotto lucian, benabik has the right idea. put a short summary as the first line, leave a blank line and then go nuts.
lucian hmm, good point
cotto Long commit messages are great if properly formatted.
benabik Strangely enough, my current commits all have short messages. But I'm not doing much complicated yet. 02:27
lucian i realised it was getting a bit silly when i started detailing future plans in them :)
cotto There's a line between what belongs in a commit message and what deserves its own blog post.
lucian nods 02:28
usually it's things like "did this in way Foo, should change to Bar soon"
cotto on a completely unrelated note, "time sync" is a very self-descriptive command
lucian let me guess: it syncs time? 02:29
dalek TT #2122 closed by benabik++: :method and :multi 02:32
TT #2122: trac.parrot.org/parrot/ticket/2122
cotto it's a time sink 02:33
soh_cah_toa cotto: PackFile_Annotations_lookup() returns a hash pmc. 1) how can i make sure this is a line annotation and not something else and 2) how do i get a pmc hash value in c code? 02:39
cotto Use the vtable interface. It's a little clunky but quite doable.
you'll probably want to iterate through it 02:40
02:40 bubaflub joined
cotto Personally, I'd focus on getting PIR-only breakpoints working first. You should try to get a minimal viable debugger going as your first goal. 02:41
soh_cah_toa yeah but Parrot_sub_get_line_from_pc() is a pain in my ass 02:42
cotto soh_cah_toa, yes it is, but you only have to write that code once.
soh_cah_toa sometimes i get -1 and it only reports line #'s for opcodes
cotto Keep in mind your long-term goals, but you'll understand how the whole system fits together once you have something workable.
soh_cah_toa i wan't to be able to break on lines like ".local pmc foo" and i can't do that w/ Parrot_sub_get_line_from_pc() 02:43
cotto That's because that line doesn't compile to anything meaningful in bytecode. It's just a macro that says that "foo" gets allocated a P register. 02:45
it's essentially the same as a comment for purposes of the debugger 02:46
soh_cah_toa well, that's gonna cause problems later b/c i plan on using breakpoints internally to implement single step 02:47
cotto soh_cah_toa, that wouldn't work anyway. A PIR instruction doesn't always correspond to a single op. 02:50
often, but not always 02:51
soh_cah_toa well then i have no idea how to do stepping then. i'll worry about it later though. 02:53
i still have the -1 problem though
cotto You might consider sorear's recommendation of modifying the op stream for that. I don't think it'll be quite as hard as you're worried about.
02:54 lucian left
cotto Just make the first byte of an op something that'll never appear as the first byte of a normal op and check for that in the runloop. 02:54
You'll have to make sure to restore the op correctly, but that's doable.
soh_cah_toa ??? i thought that was a bad idea? that's what i was gonna do for breakpoints but it's ok for stepping? 02:55
cotto You just have to be careful, that's all. 02:56
After thinking about it some, I've warmed up to the idea.
soh_cah_toa how am i able to ready the actual byte value of an opcode though? 02:57
*read
cotto same way that DO_OP does. Look at *pc 03:01
soh_cah_toa well, i'm thinking a few steps ahead actually. i still have the issue of line numbers 03:04
right now, using Parrot_sub_get_line_from_pc(), i'm able to print a few line #'s but then all of a sudden i'll get a bunch of -1's. that's what i gotta fix first but i have no idea why it's doing that
soh_cah_toa will be right back 03:05
benabik Line numbers may be one of the harder things due to how crazy IMCC is. 03:07
dalek rrot/m0-prototype: 3c050e5 | cotto++ | t/m0/ (26 files):
reorganize tests and files, fix m0_noop.m0
cotto benabik, yeah. It's unfortunate that it's also such a natural starting place when working on a debugger. 03:09
soh_cah_toa is back 03:19
03:23 preflex left
soh_cah_toa cotto: do you think you could take a look at hbdb_get_line_number() in src/hbdb.c? i pretty much copy/pasted the code that the profiling core uses so i don't understand why it's acting like this 03:23
cotto soh_cah_toa, sure 03:25
03:25 preflex joined
cotto soh_cah_toa, what do you mean "acting like this"? 03:25
soh_cah_toa cotto: line #: 3, 4, 5, 6, -1, -1, -1, -1, -1, -1, -1 03:27
03:27 SteveH joined
soh_cah_toa cotto: it's supposed to just print the line #, execute opcode, and repeat 03:27
cotto soh_cah_toa, imcc-- is why
soh_cah_toa imcc: i make crappy code 03:29
imcc: i make coders cry
imcc has become my enemy 03:30
cotto If you're questioning your sanity and imcc is involved, you're probably sane. 03:33
soh_cah_toa i now see (at least one reason) why pirate is being written in it's place 03:35
benabik soh_cah_toa: One possible end point of my GSoC is an IMCC-less parrot.
soh_cah_toa benabik: that would be great 03:37
benabik: one possible end point for my gsoc project is intense therapy
cotto soh_cah_toa, take all the frustration you
're experiencing, multiply it by everyone who's had to work on imcc and you'll learn a lot about our motivations. 03:38
soh_cah_toa is intermediate code generation really that difficult? i mean, do all java vm developers hate their intermediate code generater too like we do? or is imcc just the wrong solution to the right problem? 03:42
b/c i don't think i've ever seen a parrot dev around here going "man, i just love imcc! it's fantastic!" 03:43
cotto imcc was a prototype that was put into parrot over the objections of the guy who wrote it
It was not intended to be a long-term solution.
There are some features of PIR that make compilation harder than it needs to be. 03:44
soh_cah_toa i had a feeling that maybe imcc was something very old left over from the early stages of development that maybe worked at the time but not in the long run 03:45
between pirate and m0, parrot is really getting a nice makeover
cotto now you understand why a bit more
soh_cah_toa well, i can't just do an "if (line_num == -1) { return; }" b/c there's supposed to be an actual number there. i'm completely clueless on how to work around this 03:48
cotto Don't pull your hair out trying to work around imcc. Just go with what works. 03:49
soh_cah_toa well, nothing works. ;) if i use annotations, it's only useful for hll's (which is what i want, just not right now). and if i want pir support, i need...imcc :( 03:51
cotto What's your example code? 03:54
soh_cah_toa i'm making a nopaste now
cotto great 03:55
03:58 SteveH left
nopaste "soh_cah_toa" at 192.168.1.3 pasted "-1" (111 lines) at nopaste.snit.ch/49472 04:01
cotto It's pretty broken. 04:08
soh_cah_toa yeah, i'd say so 04:09
plobsing looks like all the ops in the first sub get numbered fine. 04:19
what happens when you switch the order in which the subs are defined? 04:20
soh_cah_toa good idea. let me try. i get similar behavior even when i don't call a subroutine. all i had was a bunch of say()'s and it still borked 04:22
nopaste "soh_cah_toa" at 192.168.1.3 pasted "Flipped definition of count_args() and main()" (25 lines) at nopaste.snit.ch/49473 04:24
04:26 theory joined
dalek lrskate: d4c3d2c | tcurtis++ | src/LALR/Grammar.winxed:
Add comments describing the LALR.Grammar class and its methods.
 04:27
plobsing those look vaguely like the right numbers for the count_args function taken from the beginning of said function (as opposed to beginning of file)
dalek lrskate: 832df2e | tcurtis++ | src/LALR/Grammar.winxed:
Rework the Grammar API a little bit.
lrskate: 8d3adc9 | tcurtis++ | src/LALR/Grammar/Prettyprint/BNF.winxed:
Update the prettyprinter to work after the Grammar changes.
lrskate: 1550136 | tcurtis++ | examples/ (2 files):
Update the example grammars.
nopaste "soh_cah_toa" at 192.168.1.3 pasted "Without any subroutine calls" (36 lines) at nopaste.snit.ch/49474
lrskate: ff39ff2 | tcurtis++ | t/lalr-grammar.t:
Update the test file.
bubaflub plobsing: i had a few questions about handling strings through NCI if you've got a moment
plobsing bubaflub: shoot
tcurtis ~~
bubaflub plobsing: i was looking at how you handled strings in your ZeroMQ bindings and I think I might do the same. Correct me if I'm wrong, but everytime I need to pass in a string i use the 'p' NCI type and then do some Parrot_cstring type method calls to convert it, right? 04:29
plobsing bubaflub: yes.
there are other ways, but that is the easiest (if not the most efficient)
bubaflub plobsing: great. also, i noticed you had some destructor functions to make sure the pointer that you're encapsulating gets freed. i imagine i need something similar as well? my GMP.Integer is just a convenience wrapper around a single var ptr that represents a GMPz object. 04:30
plobsing: i think that string stuff will work - there aren't many functions for strings, just formatted output and converting input.
plobsing bubaflub: you don't *always* have to attach destructors to encapsulated memory. if you are using StructView.alloc(), a default destructor is already provided. 04:32
but when you get memory from an external library which you are expected to free, you can either pass the buck to your caller or attach a destructor.
bubaflub plobsing: ok, well, it's pretty easy to just attach a destructor so i'll do that. 04:33
soh_cah_toa cotto: i'm gonna call it a night. tomorrow i think i'll work on something else like listing the source or something b/c i'm sick and tired of having zero progress. i still don't know what to do about this line number business though
cotto: i'll talk to you tomorrow
cotto soh_cah_toa, ok
04:33 soh_cah_toa left
bubaflub plobsing: just wondering - will Winxed handle multiple constructors with different signatures - i.e. init a blank GMP Integer, init from an int, init from a string? 04:40
plobsing bubaflub: not without multi 04:45
bubaflub plobsing: okey dokey. thanks for all your help.
plobsing: ah, one last question. i'm looking for a destructor function for GMP, but it doesn't really seem necessary. Quoth the manual, "Applications that need to return memory to the heap at some particular point can use mpz_realloc2, or clear variables no longer needed." Does that mean I can just set ptr = null and be on my merry way? 04:50
hmm, well, mpz_clear seems to do the trick as well 04:51
dalek rrot-gmp: f52fa99 | bubaflub++ | src/GMP.winxed:
make sure we have a destructor so we free our allocated space
 04:53
rrot-gmp: c830b46 | bubaflub++ | gmph2ncidef.pl:
annotate each line in the NCI def with the convenient name of the function
04:56 bubaflub left 05:11 hudnix left 05:12 theory left 05:17 Khisanth left
sorear would it be out of line for me to offer to attack single-stepping and the breakpoint kernel the next time soh_cah_toa shows up? :| 05:25
dalek rrot/m0-prototype: c15bc7c | cotto++ | t/m0/ (4 files):
move a couple m0 test files that don't output TAP
 05:29
rrot/m0-prototype: 020ab89 | cotto++ | / (3 files):
update integration test to run anything in t/m0/integration and parse the TAP

This test now requires TAP::Parser.
rrot/m0-prototype: e6953c4 | cotto++ | / (3 files):
fix instruction count calculation in m0 assembler
rrot/m0-prototype: dd7ba4c | cotto++ | t/m0/ (3 files):
rewrite remaining failing integration tests
05:29 Khisanth joined
cotto sorear, it's tempting to say go ahead, but it'd go against the spirit of gsoc. You could give him a description of what to do. 05:31
I don't like seeing him so frustrated. I think he's trying too hard to fight against imcc instead of moving on to more productive areas.
sorear what features does his debugger have? 05:35
obviously no breakpoints or single-stepping
cotto right now there's not much
sorear does it have a command loop?
is it online anywhere?
cotto just a sec 05:36
no command loop so far (iirc)
github.com/soh-cah-toa/parrot/tree...toa%2Fhbdb
sorear I'll maybe spend an hour or two tommorrow trying to implement break $IP, go, singlestep? 05:37
sorear checks out 05:38
would having a Parrot 2.8 installed in /usr/local interfere with building a Parrot 3.4 for /home/stefan/dl/rakudo-ng/parrot_install ? 05:40
cotto shouldn't 05:41
not sure why you'd want 2.8, but you should be fine
sorear well... "make" in rakudo-ng segfaults during the build
it's the last version of Parrot I installed 05:42
cotto awesome 05:43
dukeleto ~~ 05:46
cotto hio dukeleto 05:47
dukeleto cotto: wazzup
dukeleto is about to go to a wedding on the east coast
cotto: i plane to do some m0 hacking on the plane 05:48
cotto: other than m0_cover, what else is top priority?
cotto dukeleto, increasing coverage
I found a bug in the assembler by chasing down a warning earlier this evening 05:49
dukeleto cotto: coolio
cotto dukeleto, do you have TAP::Parser installed?
dukeleto cotto: yes, 3.17 05:52
cotto: it is a dependency of most test modules
cotto great
dukeleto cotto: many people may have a 2.x version, tho 05:53
cotto: but that shouldn't matter much
cotto I'm not using it very sophisitcatedly.
I'm shooting for "correct", but that'll need verification. ;)
05:53 woosley joined
dukeleto cotto: i will take a look 05:54
cotto dukeleto, thanks
dukeleto cotto: i spent most of the day preparing for my trip, and haven't backlogged or looked at he repo
but I just updated all my repos for the flight ;)
cotto dukeleto, what trip? 05:55
dukeleto cotto: going to a wedding of a good friend 06:00
cotto dukeleto, sounds like a good time 06:01
cotto is done for the night 06:05
dalek rrot/m0-prototype: a7424dd | cotto++ | / (2 files):
add add_i test, fix goto_if bug in assembler
dukeleto grabs the latest Devel::Cover and m0-prototype 06:06
cotto dukeleto++ 06:07
dukeleto .fly($east_coast)
06:09 fperrad joined 06:21 unStatiK left, preflex left 06:24 preflex joined 06:40 preflex left 06:42 preflex joined 07:12 mj41 joined 07:31 jsut_ joined 07:35 jsut left 08:54 Kulag left 08:57 Kulag joined 09:00 ligne_pub is now known as ligne_work 09:31 woosley left 10:02 JimmyZ joined 10:08 mtk left 10:15 mtk joined 10:40 contingencyplan left 10:46 contingencyplan joined 10:53 contingencyplan left 11:12 lucian joined
dalek nxed: r1033 | NotFound++ | trunk/winxedst1.winxed:
fix the lexical workarounds and reorganize LocalFunction var search methods
 11:37
11:38 lucian left 11:40 lucian joined 12:19 davidfetter joined 12:22 dodathome joined 12:29 lucian left 12:32 whiteknight joined 12:33 davidfetter left, bluescreen joined
whiteknight good morning, #parrot 12:36
tadzik good morning whiteknight
12:37 bluescreen left 12:40 bubaflub joined
dalek rrot/m0-prototype: 85dc95c | dukeleto++ | config/gen/makefiles/root.in:
Add a m0_cover target to generate coverage with Devel::Cover
 12:47
rrot/m0-prototype: 180e23f | dukeleto++ | t/m0/ (2 files):
Add a todoed test for add_n and make tests care about exit codes
rrot/m0-prototype: 886300e | dukeleto++ | t/m0/ (2 files):
Add a test+coverage for invalid registers
rrot/m0-prototype: 7512e60 | dukeleto++ | t/m0/ (2 files):
Add a test for invalid register numbers
rrot/m0-prototype: d68fcb6 | dukeleto++ | t/m0/ (2 files):
Add todo test for invalid register types
rrot/m0-prototype: 3b38c4d | dukeleto++ | t/m0/m0_assembler.t:
Also test that one of the invalid m0 tests didn't create a m0b file
12:52 bluescreen joined
bubaflub ~ 12:53
dalek nxed: r1034 | NotFound++ | trunk/t/basic/02hashexpr.t:
basic tests for hash expresions
 12:55
13:00 SteveH joined
NotFound whiteknight++ Winxed doc! 13:03
whiteknight NotFound: you like? I have more that I haven't uploaded yet. Will upload tonight
I also need to break it into smaller files 13:04
13:05 lucian joined
NotFound whiteknight: just one pitfall: you call the modifiers "flags" in some places. I think being consistent in that bit is important. 13:06
whiteknight they should always be called modifiers? 13:07
NotFound Yes, even the ones that act like flags.
whiteknight ok
13:15 SteveH left
NotFound About the doubt on "using": the current state in using and family are a bit inconsistente, but the idea is that they are declarations, so they'll never be expresions. 13:18
About the breakpoints: there is a pir problem in that regard, there is no reliable way to annotate the start of a .sub 13:21
Since a recent change in annotations handling is possible to put an annotation before a .param block, but fails in case of :method 13:23
mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_4_0-153-gc2e3158
Ubuntu 11.04 i386 (g++ --optimize)
whiteknight I hate PIR 13:25
seriously. Hate
hate hate hate
hate hate hate hate hate hate hate hate hate hate hate hate hate hate hate hate hate hate hate hate hate
oh, and IMCC-- too
lucian whiteknight: come in, the bar is on the right hand side as you go in, straight ahead there's the head-smashing wall, there'll be someone to assist you in calling the ambulance afterwards 13:27
whiteknight yay assistance! 13:30
PIR and IMCC are the anchors that are holding Parrot's head under water
Coke_ Us old timers will just sit over here and cry into our beer. 13:33
mikehh winxed (r1034) builds on parrot (3_4_0-153-gc2e3158) make test/tset1/test2 PASS, some examples tested (opengl/fly others) Ubuntu 11.04 i386 (g++ --optimize)
s/tset1/test1/ 13:34
I don't really see PIR as the problem, IMCC is 13:37
whiteknight mikehh: the two are one and the same problem. Also PIR syntax forces certain semantics and assumptions that Parrot can't seem to get around 13:39
mikehh once you can modularize parrot sufficiently to be able to replace IMCC you could fix PIR
13:41 davidfetter joined
mikehh the whole problem is that IMCC is a virus that mutated without proper control 13:41
PIRC was an attempt to get rid of IMCC, but unfortunately had a very low bus number 13:43
atrodo to me, it looks like parrot was improved while imcc was ignored 13:44
mikehh I tried to get on the bus but unfortunately other things intervened
13:45 ambs joined
mikehh also I was told that it was not a high priority and other things needed to be done first 13:45
whiteknight it's not that IMCC was ignored. IMCC was changed, but not with any particular direction in mind 13:46
lucian mikehh: i can tell you right now that implementing python's frame semantics on PIR is impossible without interpretation
whiteknight People kept changing IMCC and PIR syntax to have more features, beause too many people were writing PIR code by hand
we didn't have alternatives like Winxed or even NQP for a whole hell of a lot of time
lucian PIR is much, much too high-level to be generated, and much, much too unstructured and low-level to be written 13:47
whiteknight PIR is an assembly language that should only ever have been generated by HLL compilers
for that matter, PIR shouldn't exist. It should have all been PASM
atrodo whiteknight++
whiteknight code generators can generate PASM sequences just as easily as PIR.
NotFound The problem I see is that pasm is too low level and pir a bit too high.
whiteknight NotFound: PIR is too high-level, yes. PASM is not too low. We want low 13:48
atrodo whiteknight> That always seemed like a strange move to me. I never quite understood why compilers would target pir instead of pasm
whiteknight the biggest problem with PASM is that as IMCC has been updated, PIR gained capabilities that PASM does not have
several directives from PIR don't exist in PASM mode
NotFound pasm lack several features.
whiteknight right, because they were added to PIR as "sugar" and never backported 13:49
originally, PIR was just an overlay for PASM with nicer syntax.
PIR has a register allocator, for instance. PASM code doesn't use it
which means the HLL would have to use PIR or provide it's own register allocator 13:50
I don't think PASM currently has nice support for lexicals either
NotFound We can strip-down some pir features. For example, a modifier that works like :method minus the automatic 'self' may be useful.
whiteknight maybe it does, I can't remember
NotFound: yes, automatic self is a problem
jnthn__ Rakudo and new nqp don't use :method fwiw. 13:52
It's too tied to Parrot's object model.
whiteknight I really don't think it should exist at the Parrot level either, in the long run
a :method is just an ordinary .sub with some magic for making self appear and keeping it out of the namespace
actually, it doesn't avoid the namespace. It's still in there, we just have no API to look it up 13:53
which is the same thing, from the user perspective
NotFound Don't know the long run, but *now* we need that magic. And that magic must not neccesarily go together with 'self'.
whiteknight NotFound: The problem with getting rid of self is that we break a lot of existing PIR code 13:54
lots of code in t/, lots of code in runtime/parrot/library/
and lots of user code written in PIR
we need a lengthy deprecation, at least
jnthn__ I don't really see the automatic self as the real problem with :method. It's the fact that methods and namespaces have anything to do with each other. 13:55
NotFound No need to break things, add a new modifier. Later, we can think about deprecating the old.
jnthn__ A method installation should go in a meta-object, and how that and a namesapce relate - if they do - is quite langauge-specific.
NotFound jnthn__: the problem is the one with annotations I said a few lines ago.
whiteknight jnthn__: well, the namespace serves that purpose in PIR. We don't have a syntax for defining class objects at compile time
the only place to store the sub PMCs is in the namespace PMC 13:56
jnthn__ Sure, at the moment. But that shouldn't be the end goal.
whiteknight and when we get to runtime, we have to do the magic dance of creating the class in an :init :load sub, and pull the methods out of the namespace
jnthn__: so a PIR syntax for defining classes at compile time? 13:57
jnthn__ Anyway, with meta-objects you don't really need a syntax for defining classes etc. You just need to be able to make method calls. :)
mikehh along with M0 specification we should consider what is needed in M1+
NotFound Someone said: "In the Long Run, We're All Dead"
whiteknight jnthn__: right. But when do we make those method calls? And where do we store the subs until we call the methods?
jnthn__ whiteknight: if you're going to generate code to build it, just use .const 'Sub' $P0 = 'subid' syntax and .add_method it 13:58
mikehh NotFound: yes but hopefully we will have replacements :-}
jnthn__ whiteknight: But really the compiler would make those method calls and have the entire bunch of stuff get serialized.
whiteknight jnthn__: so .add_method it at runtime? Explicitly or implicitly?
jnthn__ whiteknight: That's where nqp and Rakudo are heading.
NotFound mikehh: yeah, and that replacements wil solve his problems at his time. 13:59
jnthn__ whiteknight: You could add some sugar for it in PIR.
whiteknight okay, that's what I figure we want to do.
jnthn__ whiteknight: But I dunno that it's worth it. I didn't think encouraging people to write PIR was helpful.
whiteknight we're still talking about a hell of a lot of breakage. At that point it's better to ditch PIR/PASM entirely and build something with less suck from scratch
jnthn__ Make it a pain and people will write/use HLLs.
NotFound Code generators write pir. They need ways to do what they need.
mikehh we really need to consider backporting what is needed into PASM and generators for that 14:00
jnthn__ NotFound: Yes, but a code generator is quite happy to build meta-objects, or build code to create them.
whiteknight of course, it's not going to be a clean break, where we drop IMCC and replace it with the new shiney. Parrot makes a hell of a lot of assumptions internally that need to be changed
NotFound I can't annotate method's entry point, that is an actual problem.
whiteknight like the relationships between NameSpace and Class, or NameSpace and PMCProxy
and the differences between Sub and Method
mikehh documentation of some form is needed to specify these problems and possible solutions 14:01
NotFound jnthn__: we don't have a meta object system yet.
whiteknight mikehh: yes, that's a good point
jnthn__ NotFound: I'm not talking about now. I'm talking about ideal future.
NotFound jnthn__: I'm thiking about the future but working in the opresent. 14:02
14:02 hudnix joined
whiteknight We have two questions: First, what do we want the end goal to be? Second: How do we get from here to there? 14:02
mikehh my problem here is that we often seem to be taking one step forward and two back 14:03
whiteknight mikehh: any recent examples?
NotFound I think decoupling some chunks of pir magic is a good start towards anything.
mikehh whiteknight: mainly that we are being help up by things like IMCC and as you said PIR, we improve a lot of things but are being held back by that, gc also 14:06
we are looking at a new low level interface, but we also need to consider the next level or it will not improve things 14:08
whiteknight true 14:13
14:16 mikehh left, arnsholt left, estrabd left, sorear left, TimToady left, p6eval left, dalek left, ingy left, krunen left, cxreg left, jnthn__ left, marc left, tadzik left, JimmyZ left, Kulag left, mj41 left, wagle left, tty234 left, pjcj left, PacoLinux left, spinclad left, Coke_ left, eternaleye left, slavorgn left, GeJ left, davidfetter left, lucian left, dodathome left, mtk left, autark left, bubaflub left, Khisanth left, ligne_work left, TonyC left, AzureSto_ left, tcurtis left, allison left, NotFound left, simcop2387 left, dngor left, baest left, rblackwe left, ttbot left, Maddingue left, Infinoid left, bluescreen left, jsut_ left, preflex left, perlite left, shachaf left, plobsing left, TiMBuS left, cotto left, cotto_work left, KaeseEs left, cosimo left, frodwith left, Hunger left, ascent left, janus left, PerlJam left, dukeleto left, bacek_at_work left, aloha left, slavorg left, Tene left, Util left, knewt left 14:30 GeJ joined, slavorgn joined, eternaleye joined, Coke_ joined, spinclad joined, PacoLinux joined, pjcj joined, tty234 joined, wagle joined, mj41 joined, Kulag joined, JimmyZ joined, hercynium joined, knewt joined, Util joined, Tene joined, slavorg joined, aloha joined, bacek_at_work joined, dukeleto joined, PerlJam joined, janus joined, ascent joined, Hunger joined, frodwith joined, cosimo joined, KaeseEs joined, cotto_work joined, cotto joined, TiMBuS joined, plobsing joined, shachaf joined, perlite joined, preflex joined, jsut_ joined, bluescreen joined, lucian_ joined, mikehh joined, arnsholt joined, estrabd joined, sorear joined, TimToady joined, p6eval joined, dalek joined, ingy joined, krunen joined, cxreg joined, marc joined, jnthn__ joined, tadzik joined 14:34 lucian_ is now known as lucian
lucian i missed the method discussion earlier 14:35
never mind, after reading the backlog, what i was going to say wouldn't have been relevant 14:36
whiteknight does PASM have .const 'Sub' syntax? 14:41
14:45 dmalcolm joined, davidfetter joined, bubaflub joined, dodathome joined, mtk joined, Khisanth joined, autark joined, baest joined, ligne_work joined, TonyC joined, AzureSto_ joined, tcurtis joined, allison joined, simcop2387 joined, NotFound joined, dngor joined, rblackwe joined, ttbot joined, Maddingue joined, Infinoid joined 14:52 lucian left 14:54 lucian joined
ambs seen moritz 15:02
aloha moritz was last seen in #parrot 32 mins 45 seconds ago joining the channel.
lucian whiteknight: in your lovely winxed docs, there's mention of multiple return 15:03
whiteknight yessir 15:04
lucian there's an example of caller syntax, but i can't figure out the syntax for return from the callee
whiteknight :(<params>) = func(<args>)
:(a [slurpy], b [named,optional], has_b [opt_flag]) = func(...) 15:05
lucian right, that's the caller. how about the callee?
whiteknight oh, right
"return 1, 2, 3, 4, 5"
lucian oh, ok
whiteknight or "return 1, 2, 3, b:[flat]" 15:06
it's exactly the same as the argument list on the caller
lucian right, thanks
whiteknight "return 4:[named("foo")], ..."
lucian whiteknight: i'm starting to get used to Rosella.Test 15:13
i think i may ignore the harness though, and do it from setup.py 15:14
whiteknight lucian: Let me know if you have any feedback at all. it's not set in stone
I'm happy to make improvements for my users :) 15:15
15:18 lucian_ joined
lucian_ whiteknight: uh, i do. i can't find anything for identify in the asserter 15:18
i really need to set up some client-server irc client
right now options are ctrlproxy, irssi, quassel, smuxi, weechat 15:19
whiteknight what do you mean "identify"? 15:20
lucian_ whiteknight: determine if two names reference the same object
15:21 lucian left, lucian_ is now known as lucian
whiteknight oh. There's a "same" and "not_same" to test if they are the same reference or not 15:21
and "equal" and "not_equal" to test for equality
lucian ah, ok
didn't spot same 15:22
dalek rrot/m0-spec: 5112b61 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
make the args for iton and ntoi more intuitive
lucian again, i'm spoilt. this time by py.test
whiteknight the list of assertions has grown too large
15:22 bluescreen left
whiteknight I need to look at py.test 15:22
15:23 bluescreen joined
lucian just so you know, py.test isn't very popular 15:23
it lets you use python's assert, so you can do "assert 1 == 1" for equal or "assert 1 is 1" for identity
for rosella, it's possible that xunit style is better, since it's supposed to be usable by different languages 15:24
15:29 bluescreen left, autark left, mtk left, davidfetter left, dodathome left, ttbot left, NotFound left, simcop2387 left, bubaflub left, dmalcolm left, baest left, allison left, tcurtis left, AzureSto_ left, Khisanth left, ligne_work left, Infinoid left, Maddingue left, rblackwe left, dngor left, TonyC left, lucian left, jnthn__ left, krunen left, p6eval left, estrabd left, arnsholt left, mikehh left, TimToady left, sorear left, marc left, cxreg left, tadzik left, ingy left, dalek left, JimmyZ left, wagle left, PacoLinux left, spinclad left, Coke_ left, eternaleye left, GeJ left, Kulag left, hercynium left, tty234 left, pjcj left, mj41 left, slavorgn left, shachaf left, plobsing left, TiMBuS left, cotto left, cotto_work left, cosimo left, bacek_at_work left, aloha left, jsut_ left, slavorg left, Hunger left, janus left, KaeseEs left, frodwith left, PerlJam left, dukeleto left, Tene left, Util left, preflex left, perlite left, ascent left, knewt left 15:53 Infinoid joined, Maddingue joined, ttbot joined, rblackwe joined, dngor joined, NotFound joined, simcop2387 joined, allison joined, tcurtis joined, AzureSto_ joined, TonyC joined, ligne_work joined, baest joined, autark joined, Khisanth joined, mtk joined, dodathome joined, bubaflub joined, davidfetter joined, dmalcolm joined 15:54 hercynium joined, JimmyZ joined, Kulag joined, mj41 joined, wagle joined, tty234 joined, pjcj joined, PacoLinux joined, spinclad joined, Coke_ joined, eternaleye joined, slavorgn joined, GeJ joined, jsut_ joined, preflex joined, perlite joined, shachaf joined, plobsing joined, TiMBuS joined, cotto joined, cotto_work joined, KaeseEs joined, cosimo joined, frodwith joined, Hunger joined, ascent joined, janus joined, PerlJam joined, dukeleto joined, bacek_at_work joined, aloha joined, slavorg joined, Tene joined, Util joined, knewt joined 15:55 lucian joined, mikehh joined, arnsholt joined, estrabd joined, sorear joined, TimToady joined, p6eval joined, dalek joined, ingy joined, krunen joined, cxreg joined, marc joined, jnthn__ joined, tadzik joined
cotto_work ~~ 15:59
whiteknight: ping 16:01
whiteknight pong
cotto_work whiteknight: what does your intuition say about github.com/parrot/parrot/commit/5112b61c3a ? 16:02
16:02 theory joined
whiteknight so iton i n x? 16:02
cotto_work whiteknight: I'm thinking about the order of the arguments 16:03
whiteknight how are the m0 ops usually structured? source, dest, other? dest, source, source2?
cotto_work yes
whiteknight i think it's more important to be consistant about ordering than it is for any one op to make slightly more sense 16:04
cotto_work usually the destination is first. That's why I ask.
ok
I don't like the cognitive dissonance between the name and the order of the arguments though.
whiteknight so rename the op 16:05
NotFound Then change te name.
whiteknight ifromn, nfromi
cotto_work deal
whiteknight how is the float->int conversion done? truncation? Rounding?
16:05 lucian_ joined
whiteknight that's an important detail to mention 16:05
cotto_work whiteknight: atm it's whatever perl 5 does. 16:06
whiteknight ok
in the final version, we need to be *very* specific
cotto_work whiteknight: sure.
Doing so now wouldn't hurt either. It's in an hll, so a slow explicit conversion wouldn't cause a meaningful slowdown unless we emulated a CPU to do it. 16:08
Now's a great time to start refining the semantics of M0. 16:09
16:10 lucian left
jnthn__ I suspect you'd want to provide "CPU semantics" for these things at some level. It's fast, and some langagues specify "CPU semantics" for such things. 16:10
cotto_work jnthn__: what do you mean by that? Do what a CPU would do? 16:11
jnthn__ cotto_work: Yeah
16:12 lucian_ is now known as lucian 16:14 lucian left
NotFound "a" CPU or "the" CPU? 16:15
cotto_work also, which cpu? 16:16
sorear also, which cpu semantics?
a lot of cpus have no native rounding mode
NotFound I don't think it makes more sense to delegate behavior to the CPU in a virtual machine so isolated to the hardware as parrot. 16:17
cotto_work NotFound: I don't think jnthn__ is saying that, just that it should behave similarly.
NotFound Then the question: similarly to what? 16:18
I prefer to clearly document what an operation do rather than aluding to some mitical generic CPU. 16:19
jnthn__ I probably mis-phrased. I mostly meant, it's good to have a way to do whatever is typical/fast on whatever current hardware platform we're running on (e.g., what would a smart C compiler do for (int)f or (float)i)
NotFound A C compiler do what the C standard says. 16:20
(in the best cases) 16:21
16:23 bluescreen joined 16:24 JimmyZ left 16:25 mj41 left
cotto_work would "round like ansi C" work? 16:26
jnthn__ cotto_work: Probably.
whiteknight I think we should specify exactly what Parrot does. On some machines maybe int->float will be a little faster than on other machiens using our semantics
if we want software to have native performance, write in a natively-compiled language like C 16:27
if you want better semantics than C, at cost, use a VM
cotto_work "better"? 16:29
NotFound But a cast to int is not a rounding operation.
C has "implementation defined" semantic in a lot of operations because of historical reasons and, in some cases, speed. 16:33
I don't think we have that reasons in low level operations.
('historical' here means 'the past millenium') 16:34
cotto_work It's something that deserves more thought than I've been giving it. 16:36
NotFound I don't think so. If for some reason we want to provide lower level loosely defined speed critical operations, we can do it later, but start with well defined semantics. 16:37
Not being sure about the valueof an int in mundane situations is the road to nowhere. 16:39
dalek p: 473c265 | tadzik++ | src/HLL/Compiler.pm:
Quit REPL and print a newline on ^D

This also works in Rakudo/nom, which makes RT #70297 fixed in nom.		 16:45
16:58 [hudnix] joined 16:59 hudnix left 17:16 ligne_work left 17:34 plobsing left 17:43 zby_home joined 17:55 lucian joined 17:56 lucian left
Coke_ tadzik++ 17:59
tadzik now messing in HLLCompiler.pir is not something I really want 18:01
I'm fine with "in nom" part 18:02
18:05 lucian joined
lucian wishes winxed allowed global vars 18:24
18:33 contingencyplan joined
NotFound lucian: maybe someday, but in the meantime is good to avoid depending on them. 18:33
whiteknight NotFound: is there a way to get a reference to the NameSpace PMC? 18:37
like the class keyword as a statement?
NotFound whiteknight: You mean at compile time? 18:39
whiteknight NotFound: like the statement: "var c = class Foo.Bar.Baz;" 18:40
but with the namespace instead of the calss
class
if we had that, we could use normal keyed access to put data into and retrieve out of the namespace 18:41
NotFound Not a bad idea, but I still need some fixes and improvements in scope handling before adding more features, specially if HLL namespaces are involved. 18:44
lucian whiteknight: +1 18:50
whiteknight okay
dalek nxed: r1035 | NotFound++ | trunk/winxedst (2 files):
Put the compiler into a namespace:

in stage 0 to make it able to compile stage 1 after the changes. Fix hash values emision. Drop all using and using static from the stage 1 compiler. And add the namespaces opening and closing.		 19:26
NotFound That was hard. 19:28
lucian whiteknight: is there an easy way to mark a test for skipping? 19:37
whiteknight I think so
lucian whiteknight: other than commenting it? 19:38
whiteknight there's self.status.todo() and self.status.unimplemented()
lucian ah, ok 19:39
thanks
whiteknight but I don't have a .skip() yet. I assume skip() would immediately end the test as TODO?
or "# SKIP"
I can't remeber the tap protocol for it off the top of my head
lucian whiteknight: i don't really know TAP, todo is fine 19:40
whiteknight .todo() marks the test TODO and ignores any failures
I need to add a .skip() method. I'll figure that out tonight 19:41
lucian iirc skip is used for reducing noise when you have a lot of unimplemented features in the code 19:43
(not in the tests)
19:44 lucian left 19:45 lucian joined
bubaflub lucian: todo is for a test that is written correctly but not passing; skip is for a test that might actually segfault the entire test suite or some such disastrous code that *should* work but doesn't 19:56
lucian bubaflub: ah, so i'm wrong
bubaflub lucian: well, to each his own 19:58
lucian as i said earlier, i haven't much used any xunit clone
bubaflub lucian: the way i've seen it done / the way i understand it is that TODO runs the code block but ignores a failure, SKIP will not run the code block 19:59
mikehh yeah - TODO is for tests that fail (hopefully with a failure message) - SKIP is to avoid tests that can break things 20:01
lucian right, i'm perfectly fine with todo then 20:03
mikehh and on my TODO list is to check the SKIPped tests in the parrot test suite to see which can be TOTOed and which might even pass now 20:05
TODOed
the whole problem with a SKIP is that the test is not performed, so you don't know if it is still failing or maybe even passing 20:08
whiteknight lucian: if you don't want the test to run, comment out all the asserts 20:14
any test with no failiing asserts is considered a pass
lucian yeah, i figured that
whiteknight or mark it todo or unimplemented
all those things will cut down on noise
mikehh NotFound: ping 20:15
NotFound mikehh: pong
mikehh NotFound: I just noticed that I still had fly.winxed running (^+ hours), when I stopped it my memory usage dropped from 1.2GB to 1.0GB (System Monitor) 20:17
6+ hours
NotFound mikehh: my girlfrien has had older versions running for weeks, without noticeable leaks, 20:18
Looks like our GC is not so bad ;)
mikehh was just wondering if 200MB is what is expected? 20:19
20:21 lucian_ joined
NotFound In my amd-64 right now top says is using 3.5% od mem, and free says Total mem is 4065608 20:21
20:21 bluescreen left
NotFound I'm not sure about what we should expect, haven't checked other usages. 20:22
20:22 mj41 joined 20:23 lucian__ joined
NotFound fly has a lot of objects plus the opengl module, 200 MB doesn't seem bad. 20:23
20:25 lucian left 20:27 lucian_ left 20:29 whiteknight left
mikehh NotFound: looks like 115.5MB Resident memory in the Processes window (the Resources window reports the same (1.2GB dropping to 1.0GB when stopped) 20:34
20:36 bluescreen joined
mikehh thats on 2.6.38-9-generic-pae #43-Ubuntu SMP - Ubuntu 11.04 i386 20:37
I'll check on amd64 version later 20:39
dalek rrot/m0-prototype: 37d6ea8 | cotto++ | / (4 files):
tighten assembler register parsing, fix a couple tests

For reals this time, all tests pass.		 20:43
20:50 dodathome left
dalek lrskate: aa018a6 | tcurtis++ | src/LALR/Grammar.winxed:
Add comments describing the newly added aspects of the grammar api.
 20:54
mikehh I am getting an error building rakudo 20:58
20:58 mj41 left
mikehh /home/mht/install/lib/bin/parrot perl6.pbc --target=pir --output=Test.pir Test.pm 20:58
No such attribute '$!storage'
21:01 lucian joined 21:05 lucian__ left
jnthn__ mikehh: What are you trying to build? The nom branch? 21:05
If so, it won't compile Test.pm yet. 21:06
mikehh jnthn__: nah just master 21:08
cotto_work Rakudo master looked fine a couple days ago with Parrot master. 21:09
or at least built
jnthn__ mikehh: ah, ok, then it's probably an issue. 21:11
21:11 lucian left, lucian joined 21:13 mj41 joined
nopaste "mikehh" at 192.168.1.3 pasted "rakudo build failure" (20 lines) at nopaste.snit.ch/49579 21:14
21:18 lucian_ joined 21:20 fperrad left 21:21 preflex left 21:23 lucian left 21:24 ambs left 21:25 preflex joined 21:28 lucian__ joined 21:31 lucian__ is now known as lucian 21:33 lucian_ left 21:35 soh_cah_toa joined 21:39 bluescreen left 21:46 Psyche^ joined 21:51 Patterner left, Psyche^ is now known as Patterner
dalek rrot/m0-spec: da50c14 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
change xtoy to yfromx, add a note to about semantics and op arg usage

I'm still on the fence about the "yfromx" naming convention but it is less cognitively dissonant from "iton N0, I0, x".		 21:55
21:58 bluescreen joined 22:00 davidfetter left 22:01 mj41 left 22:02 kid51 joined
cotto_work trying to build rakudo master with parrot master now 22:04
22:15 hercynium left
mikehh cotto_work: any luck? 22:18
22:20 bluescreen left
cotto_work mikehh: the build looks fine for me 22:21
22:22 bluescreen joined
mikehh cotto_work: 'k let me do some fresh checkouts 22:22
NotFound Has someone tested the with_winxed branch? 22:27
mikehh which branch? 22:28
ah ok, will do that after the rakudo test 22:29
NotFound origin/with_winxed
I've tested it with i386 and amd64, more platforms welcome. 22:30
22:35 bluescreen left
mikehh NotFound: that's all I've got at the moment 22:36
NotFound Anyway, some test out of my house will be good ;) 22:37
22:37 lucian left 22:39 bluescreen joined 22:43 bluescreen left
dalek rrot/m0-prototype: 731de5b | cotto++ | src/m0/perl5/m0_assembler.pl:
remove an unused sub from the assembler
 22:45
p: 7ca852e | jonathan++ | src/ (2 files):
More decontainerization twiddling.
 22:46
22:46 bluescreen joined
cotto_work dukeleto++ for m0_cover 22:47
22:47 bluescreen left
dalek rrot/tt1682/vtable_substr: fb1cc04 | jkeenan++ | / (2 files):
Begin process of deprecating VTABLE_substr. Eliminate instances of usage.
 22:48
22:49 lucian joined
cotto_work unsurprisingly, the only un-covered parts of the M0 interp are ops. 22:49
22:51 whiteknight joined, lucian left
cotto_work other than some bits that need invalid m0b to exercise 22:52
23:02 bluescreen joined
mikehh cotto_work: rakudo builds, but there is an error building Test.pir and thus the tests won't run 23:11
I tried it with gcc --optimize and g++ --optimize - Ubuntu 11.04 i386 23:12
23:13 bluescreen left
mikehh and perl 5.14.0 23:13
cotto_work mikehh: spectest_regression is running for me 23:15
slow, but that's expected
mikehh cotto_work: definately failing to build Test.pir with -> No such attribute '$!storage' 23:19
cotto_work: what platform?
cotto_work mikehh: 32-bit ubuntu 23:25
mikehh cotto_work: 'k - not sure what is going wrong, parrot passes all tests - up to fulltest, but I amstill getting that failure with Test.pm -> Test.pir 23:28
I am on Ubuntu 11.04 i386 with perl 5.14.0 23:29
dalek rrot/tt1682/vtable_substr: 1d125de | jkeenan++ | / (10 files):
Substitute 'substr' for 'substr_str' throughout.
 23:34
cotto_work mikehh: try blowing away the Rakudo directory and doing git reset --hard
there might be some leftover messing up your results 23:35
sorear mikehh: edit the makefile and add -g ms2 23:49
mikehh: I have the exact same problem
mikehh: jnthn says that it's almost certainly a missing write barrier in the MMD core and he's queued a TODO 23:50
benabik I <3 git-bisect so much.
23:52 silug joined, kid51 is now known as kid51_at_dinner
sorear now if only there were a way to pass gc options to fakecutables 23:52
dalek rrot/m0-prototype: 82eeb68 | cotto++ | t/m0/integration/m0_sub_ (2 files):
add tests for sub_i and sub_n
 23:57
rrot/m0-prototype: b9ef0c5 | cotto++ | t/m0/integration/m0_ (4 files):
add mult_i and mult_n tests, fix copy/pate goof in sub_x tests
rrot/m0-prototype: e85566c | cotto++ | t/m0/integration/m0_div_ (2 files):
add tests for div_i and div_n
rrot/m0-prototype: 4a29187 | cotto++ | t/m0/integration/m0_mod_ (2 files):
add tests for mod_n and mod_i

Powered by Cro and the Raku® Programming Language.

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

Thank you!