Camelia, the Perl 6 bug

IRC log for #parrot, 2011-07-04

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:05 Coke left #parrot
00:06 Coke joined #parrot
00:13 Coke left #parrot
00:13 Coke joined #parrot
00:23 Coke left #parrot
00:23 Coke joined #parrot
00:25 dukeleto cotto: which blog post do you need feedback on? backscrolling is a cruel mistress
00:25 cotto dukeleto, http://reparrot.blogspot.com/2011/07/pa​rrot-weekly-news-for-july-3rd-2011.html
00:26 cotto mostly feedback on the general idea and implementation
00:27 dukeleto cotto: ok
00:27 dukeleto cotto: also, i have feedback re: crc32
00:28 dukeleto cotto: the intent of "implement crc32" is to see that a non-trivial algorithm can be implemented in M0
00:28 cotto dukeleto, especially a stringy one
00:30 dukeleto cotto: i propose that all CRC algorithms are basically the same complexity to implement for N>3, so we can save some time by implementing CRC8 or CRC16
00:30 cotto dukeleto, wfm.  It's largely up to whoever decides to implement it.
00:31 dukeleto cotto: having a crc implementation is a lot more important than having a crc32 implementation. In theory, the implementation can take an arbitrary N param to do CRC(n)
00:31 lucian_ is someone volunteering to write that much assembly by hand?
00:31 lucian_ is now known as lucian
00:32 dukeleto lucian: are you volunteering?
00:32 lucian dukeleto: no :)
00:32 cotto lucian, that's also a question.  I know I'll have trouble getting myself motivated to do it before mole (m0 overlay, a.k.a. M1) becomes a thing.
00:33 benabik I see some x86 asm CRC impls that are only a couple dozen lines.
00:33 lucian i propose that writing crcN in M0 is harder than writing a structured language compiler -> m0
00:33 Coke left #parrot
00:33 Coke joined #parrot
00:33 lucian cotto: are there any docs on this mole?
00:33 cotto lucian, I don't see that, but I do see that it'll be easier after mole is usable.
00:34 lucian or is it just M0-ified winxed/close
00:34 cotto only a gist
00:34 cotto just a sec
00:34 cotto lucian, https://gist.github.com/1048210#file_syntax is as much as exists
00:34 cotto I'm just working through the syntax.
00:35 dukeleto lucian: i propose that i would like to know your reasons for such a statement
00:35 lucian dukeleto: it was exaggerated, perhaps. but not too much
00:35 dukeleto lucian: as benabik describes, there are slow implementations of crc(n) that are a few dozen lines. The very fast implementations with lookup tables and other fancy junk are much longer
00:36 cotto slow is perfectly fine.  It'll just be a proof of concept.
00:36 lucian dukeleto: right, but a small structured language targeting m0 should be relatively easy as well
00:36 cotto lucian, suggestions on mole are more than welcome.
00:37 lucian cotto: reading through that gist, i really recommend a look at Go
00:37 dukeleto lucian: i hope that you are correct, but I wouldn't bet money on it :)
00:37 lucian it gets a lot of syntax decisions much less wrong than C
00:38 cotto lucian, less wrong than C is great.
00:38 lucian dukeleto: :) if i get sick enough of build systems, maybe i'll try
00:38 cotto I'll do that.
00:38 lucian cotto: in particular variable declaration and pointer syntax is somewhat better in Go
00:38 lucian ifs too
00:38 lucian cotto: go's object system is also interesting
00:38 lucian cotto: http://www.syntax-k.de/projekte/go-review
00:39 cotto 6model will be implemented in mole, so it can't have its own built-in object system.
00:39 cotto thanks!
00:40 cotto I've been ignoring Go for now because I don't see it picking up enough traction to actually replace C, but I'm all for stealing ideas.
00:41 lucian cotto: it's really, really nice, except for a few giant ugly warts
00:41 lucian you should read that article when you have time, it's exceptionally well written
00:41 lucian but in short, its object system is "just" structs. there's no inheritance, just composition + dispatch
00:42 lucian ooc has a vaguely similar feature called "covers"
00:42 cotto lucian, the article looks solid so far.
00:42 cotto I'm reading it now.
00:43 cotto I'm not a great artist, but I still like stealing.
00:43 lucian yes, stealing ideas is great
00:44 lucian i like the proposed strings in that gist
00:44 lucian similarly, i'd propose either "fat" pointers like cyclone or slices like Go instead of raw pointer arithmetic
00:46 dukeleto cotto: i like the Parrot Weekly News blog post
00:46 Coke left #parrot
00:46 Coke joined #parrot
00:46 dukeleto cotto: so if we say PWN on a line, it gets starred somehow? Where is that described in a bit more detail?
00:47 cotto dukeleto, there's no magic.  I'll just grep irclog for "PWN".  I figured that'd be the laziest approach.
00:48 cotto It'll require a lot of manual intervention to turn irc into something publishable anyway, so searching won't be much additional work.
00:48 cotto I'll note that in the blog
00:48 cotto post
00:49 dukeleto msg moritz i get XML Parsing Error: undefined entity Location: http://irclog.perlgeek.de/parrot/2011-07-04 Line Number 27, Column 41:
00:49 aloha OK. I'll deliver the message.
00:49 dukeleto msg moritz that error is from FF 3.6.x
00:49 aloha OK. I'll deliver the message.
00:51 dukeleto msg moritz it is complaining about ←
00:51 aloha OK. I'll deliver the message.
00:53 benabik cotto: PWNed?
00:53 lucian cotto: commented on that gist
00:53 cotto benabik, it was hard not to suggest that (or PWN'd)
00:55 cotto lucian, (wrt gist comment) in my head there's not a strong semantic distinction between procedures and functions.  Composed ops, while superficially similar to functions, have different semantics.  I don't want anyone to have to think about which is which.
00:56 lucian cotto: right. then why chunks?
00:56 cotto lucian, that's from M0.  A better name is reasonable.
00:57 lucian i see
00:57 cotto Very little is final.
00:57 lucian i guess i'd prefer "ops" to "composed ops" in the declaration
00:58 cotto It's a wet lump of clay, ready to be shaped by anyone who doesn't mind getting dirty hands.
00:58 lucian so you can declare new ops in M1
00:58 benabik cotto: Composed chunks are more macroish?
00:58 cotto composed ops?  yes
00:59 lucian oh, and about macros. i don't think anything beyond conditional compilation is very useful
00:59 lucian C's preprocessor is just silly, but on the other hand it's already written and can be invoked separately
00:59 cotto lucian, I don't want C-like macros at all.
01:00 lucian there's a feature i like in D, called static if
01:00 benabik composed ops, yes.
01:00 lucian it's just like if, but compile-time
01:00 cotto lucian, what'd the difference between that and #IF ?
01:00 benabik Syntax based instead of text, I'd assume.
01:00 benabik Technically any if that contains a constant value should be able to do that.
01:00 lucian cotto: nicer syntax and less chance of craziness
01:01 * soh_cah_toa agrees that macros are a no-no
01:01 cotto benabik, sure but if you're writing a lot of if statements with constant conditions, you're writing unusual code.
01:01 lucian the other use-case i've seen for macros is pseudo-functions. but there's composed ops for that
01:03 lucian cotto: right, but if the keyword is "static if", the meaning's clear
01:03 Coke left #parrot
01:03 Coke joined #parrot
01:04 cotto I hate the way github does comments on gists.
01:04 cotto They'd be so much more useful if they acted like full repos.
01:05 lucian cotto: also, i'd advocate for "var a int*" instead of "int* a", but i'm not sure that's a great idae
01:05 cotto still pretty great
01:05 cotto lucian, not I am a fan
01:06 benabik Does mole have type*?
01:06 lucian cotto: in any case, i think disallowing "int *" vs "int*" is necessary
01:06 lucian lots of errors in C exist because of things like "int *a, b" vs "int* a, b" confusion
01:06 cotto lucian, I like that.
01:06 cotto sorear had a similar suggestion.
01:07 benabik I personally think that int* should be disallowed.  It attaches to the variable, not the type.  But I'm willing to accept being outvoted.
01:07 lucian benabik: to reference other types?
01:07 benabik lucian: No, where type is int, pmc, string, etc.
01:07 lucian benabik: well, i have the opposite view. i think it should clearly attach to the type
01:08 lucian benabik: good point. mole needs at the very least some sort of typedef
01:08 lucian not C's typedef though, it's broken badl
01:08 lucian y
01:08 benabik lucian: It clearly attaches to the variable in C, and using C syntax without C semantics is just confusing.
01:08 benabik s/clearly //
01:09 lucian benabik: yes, it attaches to the variable in C, to the type in Java/C#/etc
01:09 lucian benabik: i'd argue that the syntax is pervasive enough that not following C's semantics shouldn't be a big deal
01:09 Coke_ joined #parrot
01:09 Coke left #parrot
01:09 benabik lucian: Java doesn't have pointers.  Or, rather, it doesn't have non-pointers.
01:10 lucian benabik: it was a bad example, sorry
01:10 benabik lucian: And I'd argue that the syntax is pervasive enough that changing the semantics is begging for someone to confuse.
01:10 lucian what does C++ do?
01:10 benabik *begging to confuse someone.
01:10 benabik C++ uses C.
01:10 soh_cah_toa i believe it attaches to the type
01:11 lucian soh_cah_toa: yes, i remember the same
01:11 lucian and that would explain why C# does the same
01:11 benabik I'm pretty sure it's as per C, but don't have a reference to point to.
01:13 benabik int *a, b; int c; b = &c;
01:13 benabik g++ says: invalid conversion from ‘int*’ to ‘int’
01:14 kid51 joined #parrot
01:14 lucian i see
01:15 lucian anyway, it's a small issue
01:15 lucian i believe it's much more important to fix arithmetic
01:16 lucian rather, disallow it
01:16 benabik Either way we should probably outlaw either "int*" or "int *", whichever is invalid.
01:16 lucian benabik: yes, certainly
01:17 benabik Pointer arithmetic is very useful in C.  Probably has no place in parrot.
01:17 soh_cah_toa flip a coin, maybe?
01:17 lucian benabik: it has no bounds checking in C, but it could be useful in parrot
01:17 cotto soh_cah_toa, heads
01:17 soh_cah_toa b/c it's all just a matter of personal preference
01:17 soh_cah_toa no one is "better" than the other
01:17 lucian soh_cah_toa: benabik does have a point that the more popular choice is likely "better" overall
01:18 cotto less confusing is better
01:18 lucian how would arrays work in mole?
01:18 cotto or surprising
01:18 soh_cah_toa agreed
01:18 lucian cotto: the issue is thorny since C has promoted the confusing and surprising semantic
01:18 benabik Principle of least surprise.
01:18 cotto lucian, that's a valid concern.
01:18 kid51 cotto: I tried posting a comment in your blog, but when I hit the Preview button, my comment (8-9 minutes of typing) vanished.
01:18 soh_cah_toa kid51: i had the same thing
01:18 cotto kid51, did you try the back button?
01:18 cotto lame
01:19 lucian kid51: i made a habit out of copy-ing what i typed before posting
01:19 kid51 cotto: yes, that was the first thing I tried.
01:19 kid51 lucian:  I try to do that as well.  In this case, I ... forgot.
01:19 JimmyZ joined #parrot
01:20 kid51 So here's the short version of the comments:
01:21 kid51 Each of the 3 wiki pages you cite under Room for Improvement is at least 11 months old, i.e., stale.
01:21 kid51 Which, IMHO, is what inevitably happens with wikis that are not focused on a deadline (like, say, the YAPC wikis).
01:21 kid51 What we should do, IMO, is identify two or three important enough to be made roadmap goals.
01:22 kid51 Also, in same subsection, but different topic ...
01:22 kid51 ... we need to say what the specific function of config_lib.pir is before we start deleting entries from it.
01:23 kid51 I confess I don't know how it differs, really, from lib/Parrot/Config/Generated.pm other than the language it's written in.
01:23 kid51 ENDOFRANT
01:24 cotto kid51, the point of that section is to highlight tasks that would be useful but that aren't big enough for roadmap goals.  I want that to be a place where a potentially bored Parrot hacker can go and find something worthwhile to work on for a few days.
01:24 kid51 k
01:25 cotto The wiki pages are indeed old.  I almost recommended consolidating and pruning them as a task.  Perhaps I should.
01:26 dalek rakudo/nom: 9928a0d | jonathan++ | src/Perl6/ (3 files):
01:26 dalek rakudo/nom: First cut at constant. Only handles simple cases so far (e.g. literal on the RHS, and non-twigil variable or identifier with our/my scope).
01:26 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9928a0d176
01:26 cotto btw, I've enabled anonymous comments.  Hopefully the lameness with dropping comments doesn't happen again.
01:26 soh_cah_toa cotto: to elaborate on lucian's question...how do you feel arrays should be implemented? like c where pointers and arrays can be used interchangeably w/ just different semantics or do you want to make a clear distinction between the two?
01:26 cotto I'm really sorry about that.  I know how frustrating it is.
01:26 lucian soh_cah_toa: also, how do strings fit into that?
01:26 soh_cah_toa yes
01:27 soh_cah_toa strings...maybe just pmc type?
01:27 cotto primitive strings
01:27 cotto object strings will be just another object
01:27 soh_cah_toa ok
01:27 soh_cah_toa so you do want primitive strings then. ok
01:28 cotto I should probably say that the first 8 bytes of a string will be the length and encoding.  Having magic around that may be ill-advised.
01:28 benabik Will it be C-Strings or Parrot STRINGs?
01:28 cotto benabik, yes.
01:28 benabik Hah.
01:28 cotto primtive strings will be fairly close to C-strings
01:28 cotto object strings will be closer to Parrot STRINGS (though more like String PMCs)
01:29 lucian cotto: so are strings backed by arrays? if yes, does stripping the first 8 bytes give you a C array?
01:29 benabik String PMC but immutable??
01:29 benabik Please?
01:29 * benabik dislikes that String PMC responds to assign VTABLE.
01:29 lucian benabik: i don't think immutability is in question here
01:30 benabik lucian: Sorry, I just noticed yesterday that String PMC can change and thinks it was a bad bad plan.
01:30 lucian yes, it is :)
01:30 lucian i think everything should be immutable by default, but that's another matter
01:30 cotto immutable STRINGs happened fairly recently
01:30 benabik lucian++
01:31 lucian the vast majority of langauges/runtimes have immutable strings, so i'd vote for immutable object strings, but mutable primitive strings/arrays
01:31 * cotto mutes lucian
01:31 * cotto unmutes lucian
01:31 * cotto immutes lucian
01:31 soh_cah_toa imho, i think keeping the relationship between strings/arrays/pointers that c has may be a bad idea. it can get very hairy
01:31 benabik It is var easier to build mutable data structures from immutable than the other way around.
01:31 benabik If this is a system level language, then attempting to hide how things really works is a bad idea.
01:32 lucian soh_cah_toa: if there's a distinction between primitive arrays/strings and object ones, i like an approximation of C's relationship
01:32 cotto C is my starting point for array and pointer syntax.  There's no need for it to be the endpoint.
01:32 benabik C strings are character arrays because that's how it's stored in memory.
01:32 soh_cah_toa i thought we were trying to make it a little higher level than c? maybe i misjudged?
01:32 lucian i'd like mole arrays to be like C ones (pointers)
01:33 lucian either with size information in the pointers themselves (fat pointers), or with all arrays having a reserved header like strings
01:33 benabik I thought we were trying to make it "slightly higher than assembler".  :-D
01:33 lucian benabik: too high? too low?
01:33 benabik (i.e. "just like C"  ;-) )
01:34 * benabik likes C.
01:34 * lucian doesn't
01:34 cotto You'll find a brick taped to the bottom of your chairs.  I think you know what to do.
01:34 lucian benabik: but i think we can both agree that having bounds checking on arrays/pointers/strings is a good idea
01:34 cotto ;)
01:34 lucian and that headers or fat pointers provide this
01:34 benabik lucian: Kind of?
01:35 lucian benabik: ah. then what would you prefer?
01:35 benabik lucian: Having the ability to do so is good, but C doesn't have bounds checking for speed.
01:35 soh_cah_toa so we're trying to make it on the same level (as far as abstraction goes) as c?
01:35 cotto That's also my concern for bounds checking.
01:35 lucian benabik: right, but C isn't gc-ed or part of a runtime
01:35 lucian soh_cah_toa: i guess
01:35 cotto soh_cah_toa, approximately
01:35 lucian how about making voluntary bounds checking easier instead?
01:36 lucian in C it's often hard to get to the length info, but if mole arrays are guaranteed to contain a header (like strings), it makes things easier?
01:36 benabik lucian: Yup.  But if we're implementing 99% of our system in this, then we probably want it to be very fast.  :-D
01:36 soh_cah_toa then why not just use c? i mean, isn't mole trying to solve the c -> pir and pir ->c problem?
01:36 benabik soh_cah_toa: It'll be like C, but inside the VM instead of outside.
01:36 soh_cah_toa if it's like c, then we still have that problem
01:37 lucian soh_cah_toa: because C implies a lot of things
01:37 soh_cah_toa oh i see
01:37 cotto soh_cah_toa, M0 solves that.  mole makes M0 usable for non-trivial tasks
01:37 lucian benabik: yes, we do. we also don't want it to crash, i guess
01:37 benabik lucian: Also true.
01:37 soh_cah_toa what will mole compile down to?
01:37 lucian if i get a vote, i put it down for mandatory bounds checking :)
01:37 cotto soh_cah_toa, M0
01:37 lucian soh_cah_toa: m0
01:38 soh_cah_toa then down to c from there?
01:38 lucian ideally, m0 bytecode directly i guess?
01:38 benabik lucian: I'm okay with default bounds checking.  :-D
01:38 cotto mole = "M0 Overlay LanguagE"
01:38 lucian soh_cah_toa: or jitted
01:38 benabik (default implying "able to turn off", of course)
01:39 lucian benabik: are you thinking of a particular granularity for turning it off?
01:39 cotto m0 bytecode and textual m0 are very straightforward to translate between
01:39 benabik lucian: Probably per-variable.
01:39 lucian benabik: so you'd declare a variable as non-bounds-checkable
01:39 soh_cah_toa ah, the way pasm and pbc were supposed to be ;)
01:39 benabik lucian: `unsafe int *x`
01:39 cotto soh_cah_toa, yes
01:40 cotto That's a really interesting idea.
01:40 * benabik wants to resurrect PASM.
01:40 lucian benabik: right. yes, i guess that's reasonable. what do you think of an unsafe { } block instead?
01:40 benabik lucian: unsafe(x) {}, perhaps...  Declaring all pointers to be unsafe in a block is probably not wise?
01:40 lucian benabik: ah, yes, of course
01:40 lucian the whole point of a block would be to reduce the unsafe section
01:41 benabik Exaclty.
01:41 lucian an unsafe variable could live a long and troubled life
01:41 benabik lucian: True.
01:41 lucian perhaps both options could exist,i guess
01:41 lucian it doesn't seem like a high overhead for a compiler
01:41 woosley joined #parrot
01:42 benabik I want to resurrect PASM, with the ability to do a complete round-trip.
01:42 benabik And then kill PIR.  Kill it with fire.
01:42 cotto alternately, be unsafe by default.  It depends on which is more common.
01:42 benabik Safe by default is, well, safer.  :-D
01:42 cotto or make it an interpreter feature
01:42 lucian cotto: i'd argue all the buffer overflows we hear about should suggest for safe by default
01:43 nopaste "kid51" at 192.168.1.3 pasted "hbdb branch: much improved" (27 lines) at http://nopaste.snit.ch/57256
01:43 soh_cah_toa kid51: no build errors. but many segfaults :(
01:43 lucian cotto: gcj has an option just like that, to compile without bounds checks. instead of an exception, you get memory corruption/crashes
01:43 cotto lucian, tasty
01:44 lucian it makes sense i guess for mole to have similar. since it's generating extra M0 for the bounds checks anyway
01:44 lucian default to safe, and override per file, per variable or per block
01:44 cotto lucian, are you thinking that M0 arrays would always have a length, but that without safety it'd be ignored?
01:45 lucian interestingly, some JITs remove bounds checks where it's proven to be safe
01:45 lucian cotto: yes
01:45 lucian cotto: or perhaps remove the header for unsafe pointers/arrays?
01:45 cotto lucian, I love the way a good JIT can cheat flagrantly and get away with it
01:45 lucian i don't know how siginficant the header would be
01:46 cotto lucian, that'd mean changing indexes
01:46 benabik The length is probably available _somewhere_, assuming it's created inside the GC.
01:46 lucian yes, JITs are interesting beasts. on the one hand, they have extreme time&memory constraints, so they can't optimise too much. on the other hand, they have so much more information
01:46 benabik I like GCs that store array lengths at index -1.  :-D
01:46 lucian benabik: right, good point
01:46 lucian could the header be "virtual"?
01:47 lucian or is that a good idea at all?
01:47 soh_cah_toa oh, never seen that before. i like that idea
01:47 cotto I'm not sure if it is.
01:47 lucian benabik: also, not all arrays/pointers have to be GC-ed
01:47 lucian at least that's my understanding
01:47 benabik I'd think at least _most_ of them would be.
01:47 lucian yes, indeed
01:48 benabik Non GC'd memory allocation ideally is reserved for NCI.
01:48 lucian i vote for benabik negatively indexed (potentially virtual) pointers
01:48 soh_cah_toa me too
01:48 lucian s/pointers/headers/
01:49 daniel-s joined #parrot
01:49 cotto lucian, you're right that the pointers could come from multiple sources.
01:49 lucian cotto: right, and in some cases 'length' makes no sense, like a mmap-ed file
01:50 lucian so the headers probably *have* to be optional
01:51 lucian i guess Go's solution may be more elegant. not sure if it's applicable or desirable
01:51 cotto lucian, what is it?  I haven't gotten there yet.
01:51 lucian cotto: slices. basically memory views that "act" like arrays, but aren't necessarily
01:51 lucian sort of like a language-level mmap
01:52 cotto I need to go clear my head.  be back in 15m +/-.
01:52 lucian cotto: they basically map to a subset of an existing (constant-size) array
01:53 soh_cah_toa go actually does a lot of things right, except it's weird syntax ;)
01:53 soh_cah_toa it wouldn't be a bad language to model after. it's compiler, that is
01:55 lucian yes, it has many very nice features. i rather like most of its syntax, but maybe i'm weird
01:55 soh_cah_toa eh, it takes some getting used to
01:55 lucian simple things, like optional ; and optional ( ) around if test expressions
01:55 lucian for me, they help readability
01:56 * benabik enjoys bikeshedding over language design.
01:56 lucian benabik: it's great, isn't it?
01:56 lucian we've debated actually important things too, though
01:56 soh_cah_toa indeed
01:57 soh_cah_toa anyway... so the flow of compilation goes mole -> m0 ops -> m0 bytecode, correct?
01:57 lucian soh_cah_toa: yeah, but it doesn't have to generate m0 textual ops
01:58 lucian if it wants, it can generate m0 bytecode directly, after flattening the AST
01:58 soh_cah_toa ok
01:58 soh_cah_toa does anything sit on top of mole? something -> mole -> ... like pir? pasm?
01:58 soh_cah_toa i'm trying to figure out how "high" it's reach goes
01:59 benabik soh_cah_toa: I think "everything currently called Parrot" goes on top of Mole.
01:59 benabik M0le
02:00 benabik Is the plan to build a PBC interpreter/JIT on top of M0(le)?
02:00 soh_cah_toa i think that's an area of much debate
02:01 benabik Since, AFAIK, the plan it to have most of our ops in M0, it would make sense (to me).
02:01 lucian benabik: i thought the idea was to have PIR->M0 and PASM->M0 for legacy, and Mole->M0 for the future
02:02 lucian and HLLs could generate M0, and use utilities/composed ops/functions/types written in Mole
02:02 lucian of course, i could very well be very wrong
02:03 soh_cah_toa i don't think so
02:03 soh_cah_toa i don't think hll's will see a difference
02:03 lucian well, i'd very much like to not generate PIR anymore
02:03 soh_cah_toa i'm pretty sure dukeleto mentioned that in his talk
02:03 lucian but if there's PIR->M0, sure, HLLs could keep using it
02:04 benabik lucian: I also want to kill PIR, but would want to replace it with PASM/direct PBC gen.
02:05 soh_cah_toa i suppose it depends if backwards compatibility is desired. i personally haven't heard any talk for or against it
02:05 lucian benabik: why not say PASM 2.0 = M0, PBC 2.0 = M0 bytecode?
02:05 soh_cah_toa yeah, that's what i thought
02:06 soh_cah_toa or at least pictured in my head ;)
02:06 benabik lucian: Because we're not looking for an apocolyptic change to parrot?  We want Parrot to still look about as it does now.
02:06 soh_cah_toa from hll's perspective, yes
02:06 benabik M0 is designed to move most things written in C inside the VM instead of outside.
02:07 benabik If PBC is no longer valid, that's a pretty big change.
02:07 lucian benabik: right, but what advantage do you see in PASM over M0?
02:07 bacek_at_work ~~
02:07 lucian i don't really know about the plans for pbc. but i'd expect translation pbc->m0 to be better than interpretation
02:07 soh_cah_toa i don't know of pbc will be deprecated in place of m0b or if m0b is just the temp name for pbc 2.0
02:09 benabik M0 doesn't have all the features HLLs might expect.  It's designed to be just big enough to implement the actual Parrot opcodes in.  So languages still see the current opcode set (or similar), but the ops are written in M0.
02:09 benabik I think the stack is HLL -> PBC -> Ops -> M0
02:10 lucian benabik: hmm. as a HLL writer, i'd rather have M0 + custom functions
02:10 soh_cah_toa hmm...not sure about that
02:10 lucian i don't see the advantage of yet another assembly language with ops, over just some functions
02:10 lucian my problem with PIR is that it's gnarly, not that it's too small
02:10 soh_cah_toa there's a lot of things like this that need to be considered but for now the main focus to be rid of the c -> pir and pir -> c issue to increase optimizations
02:11 lucian soh_cah_toa: yes, and HLL writers can decide this themselves
02:11 lucian PIR would be such "yet another assembly", and necessary for backwards compat.
02:11 lucian so people could use it, or a "use strict" version of PIR
02:11 benabik lucian: Evolution, not revolution, is the big advantage.  You could write dynops in M0, but M0's interface to parrot internals is very very low leve.
02:11 lucian i don't really know
02:12 soh_cah_toa i do know that lots of us want to be rid of pir but i'm not sure if it's relevent to m0 at this stage of development
02:12 soh_cah_toa but in the future, yes
02:12 lucian benabik: i don't know what details i'd prefer. a PIR compiler can do whatever it wants, and itself could just use M0 + functions
02:13 benabik The problem with PIR is that it does too much magic.  It's too high to be an assembly language and too low to be really useful.
02:13 soh_cah_toa agreed
02:13 lucian exactly. an assembly target should be as low and small as possible/makes sense
02:13 lucian M0 looks just like that to me
02:13 benabik This comes back to me wanting to resurrect PASM.
02:14 lucian anyway, my opinion is that it doesn't matters. as soon as parrot can run M0, people can write PIR->M0 and PASM->M0 and just ignore it all and do Python->M0
02:14 lucian but M0 working is important first, dynops seems like a non-issue atm to me
02:14 soh_cah_toa yes
02:15 benabik lucian: I don't know if Python->M0 would really make you happy if "new Class" is written using NCI calls to Parrot C functions.
02:15 lucian benabik: i thought 6model was supposed to be written in mole/m0
02:16 soh_cah_toa it is
02:16 lucian right, then i'd use 6model, with whatever M0 API that has
02:16 lucian compilers don't care about verbose assembly
02:17 benabik I don't think the M0 VM is something we want to expose directly.  I think it's something to write the Parrot VM in.  When needed, we can drop down to M0, but it shouldn't be the norm.
02:17 benabik PBC ops may be JITted to M0 (which may then be JITted to real machine.)
02:18 lucian benabik: i dislike that double JIT-ing
02:18 lucian i don't see the advantage in it
02:18 benabik Having the extra level there is useful to isolate HLL devs from system level M0 changes.
02:18 lucian an API can do that just as well, i would think
02:19 lucian they way i've heard, parrot would become an M0 interpreter + jit + gc
02:19 lucian all that written in C
02:19 lucian just like the JVM, and so many others
02:20 JimmyZ left #parrot
02:20 benabik I really think that the current goal is to replace the C internals of Parrot with M0 internals with HLLs being mostly none-the-wiser.
02:20 lucian right, because they can use the PIR->M0 compiler
02:22 benabik I don't think there are any short-to-mid term plans to have HLLs replace PIR with M0.  M0 is just too different than the current worldview of Parrot-as-a-VM.
02:22 benabik (As opposed to Parrot-as-a-dev-environment)
02:23 lucian and since PIR needs to be supported for legacy reasons, HLLs can keep using it
02:23 lucian but i'd really much prefer M0 to PIR or PASM
02:27 benabik Ah!
02:28 benabik The difference between using PBC with M0-impl opcodes and using M0 with current opcodes as functions is the ability to shoot yourself in the food.
02:28 benabik M0 is designed to do things like directly allocate memory and other things that might make the VM crash.
02:29 benabik PBC is the indirection layer that has things like exceptions.
02:30 benabik And bars HLL devs from shooting themselves in the foot unless they try.
02:30 benabik (Trying = writing new opcodes)
02:30 lucian benabik: hmm. perhaps
02:30 benabik Writing things in M0 is likely to be similar to writing Parrot-flavored C, where you need to worry about things like write-barriers.
02:31 benabik I think at least short-to-mid term we'd be best served by creating a PASM that doesn't suck.
02:31 * lucian shrugs
02:31 lucian i still think M0 may be enough
02:32 atrodo I'm not a fan of the idea that m0 can cause a segfault, especially if m0 is the bytecode
02:32 atrodo if m0 is just a runcore, i'm alright with that idea
02:32 lucian atrodo: that is a good point
02:33 atrodo plus, there's really no good reason to allow that, the cost doesn't appear to be that high
02:33 atrodo but then again, i'm completely out of the m0 loop at this point
02:33 lucian atrodo: benabik++'s argument was that unsafe pointer arithmetic may be useful
02:33 benabik I think M0 has opcodes for memory allocation.
02:34 cotto ~~
02:34 cotto yup
02:34 benabik Anything that can do memory alloc and free can segfault.
02:34 cotto time for some serious backscrolling
02:34 cotto yup
02:34 atrodo i disagree
02:34 benabik cotto: We're bikeshedding/arguing over "Parrot on top of M0" and "Parrot is M0"
02:34 cotto free 299395
02:34 lucian benabik: really?
02:35 lucian benabik: even if you have bound-checked pointers?
02:35 benabik lucian: If I free something another peice of code access, you get a segfault.
02:35 benabik Or at least "undefined behavior".
02:35 cotto they guy with the paintbrush has the final say
02:35 cotto or spraypaint
02:35 atrodo or paintgun
02:35 lucian benabik: right
02:36 atrodo unless, of course, you don't actually get pointers
02:36 lucian cotto: i had a similar point. HLL devs can decide themselves if they like PIR/PASM or prefer moving to M0
02:36 lucian benabik: ideally, everything except NCI would use the GC
02:36 cotto lucian, quite.  PIR will map to M0, so either is fine
02:37 benabik cotto: Is the mid-to-long term goal eliminating PBC in favor of m0b?
02:37 benabik That's my real question, I suppose.
02:38 cotto benabik, that's still an open question.
02:38 atrodo if m0b is an available format, then I'm quite opposed to allowing m0 from being able to access and manipulate all memory
02:39 cotto I suspect that it will start to go away after Parrot is converted to an M0 overlay.
02:39 lucian for NCI purposes, it should be enough for the GC to allow non-movable sections
02:39 atrodo there will be absolutely no way to secure parrot at all
02:39 lucian that's what other VMs do for their FFIs
02:39 lucian or long-lived, very large objects
02:39 atrodo although, not like we can secure parrot as it is
02:39 cotto atrodo, part of the charm of M0 is that we can analyze it.
02:40 * cotto really needed that walk
02:40 atrodo analyze it and say for absolute certainty that it can't cause a seg fault or access outside the sandbox?
02:41 lucian atrodo: if it doesn't alloc/free outside the GC, i'd guess so
02:41 atrodo but if you can manipulate pointers at all, all bets are off.
02:41 benabik M0 : Parrot :: NQP : Rakudo is really my thought.  But experience will tell us if level of indirect needs to survive past "legacy use".
02:41 lucian atrodo: not if the manipulations are bounds checked
02:41 lucian rather, not if you have arrays, but not free pointers
02:42 cotto It's vital that we make PIR->M0 possible for backwards compatibility.
02:42 cotto (from backscrolling)
02:43 rurban_ joined #parrot
02:43 cotto I don't love PIR, but we need to support it.
02:43 atrodo lucian: but then you also have data leakage by knowing the actual pointer location
02:43 lucian atrodo: oh, as a security issue?
02:44 atrodo lucian: yes
02:44 cotto hio bacek_at_work
02:44 lucian atrodo: well, then maybe sandboxed M0 should only have arrays
02:44 atrodo you're exposing the underlying system to the sandbox
02:44 benabik I want to burn PIR with fire.  Sure, let it continue to exist, but have a real assembly language where one line of code = one PBC op.
02:44 lucian cotto: is there a good reason M0 should have pointers?
02:45 cotto lucian, is there a natural way to have the same expressive power as C without them?
02:45 lucian cotto: most of the use-cases can be replaced with arrays
02:46 kid51 left #parrot
02:46 rurban left #parrot
02:46 atrodo lucian: see my lorito prototype, you have pointers into pmcs, but at no point do you have real pointers
02:46 rurban_ is now known as rurban
02:46 lucian cotto: the rest could probably use references, rather than pointers
02:46 atrodo which is really a pmc and an index
02:46 lucian atrodo: right. i'm with you that m0 should be cleaner&safer; others raised expresiveness/performance concerns i can't comment intelligently on
02:47 cotto atrodo, m0 and mole don't and can't know about PMCs
02:47 atrodo what's the point of performance if m0 can't be used in any sandbox?
02:47 lucian cotto: i don't know, really. what i really like is arrays with length headers, and strings based on those arrays, with encoding headers :)
02:47 atrodo cotto: i overused the pmc name.  it's really an allocated blob
02:48 atrodo with just enough magic to allow you to create pmcs on top of it
02:49 cotto lucian, it feels funny talking about one-word "headers", but it's growing on me.
02:50 lucian cotto: presumably there could be other such headers
02:50 atrodo lucian: what magic is this?
02:50 lucian in the end, arrays + references should serve all needs i think
02:50 lucian atrodo: in here https://gist.github.com/1048210, look at the strings
02:51 cotto lucian, are arrays and references, as you're using the terms, similar to what Go does?  I still haven't gotten very far in that article.
02:51 lucian cotto: arrays would be regular C arrays, but with bounds checks
02:52 lucian cotto: references would be C pointers, but with no arithmetic
02:52 lucian cotto: in the presence of a moving GC, they might have to be not-quite-pointers
02:52 cotto copying/compacting gc makes life much more interesting
02:53 lucian yes. PyPy's solution is interesting, i guess
02:53 atrodo cotto: what about symbols?  has that possibility been eliminated from m0?
02:53 benabik copying GC is "more interesting" but also more powerful, AFAICT.
02:53 cotto benabik, yes
02:53 cotto atrodo, I think they're too magical for M0
02:54 lucian in Python, all objects have an id(), which defaults to the C-level address. by default the id is still the pointer. when an object is moved, its header grows a field "id" with the old address
02:54 lucian atrodo: symbols in what sense?
02:54 lucian benabik: and necessary for reasonable performance
02:55 atrodo lucian: lisp symbols.  immutable, only 1 ever exist string
02:55 lucian atrodo: right. it is a nice concept, i agree
02:55 atrodo lucian: makes string compares trivial and fast, but makes them unusable for strings
02:55 lucian would all functions/methods be referenced by symbols?
02:56 lucian atrodo: how about instead of symbols, interned strings?
02:56 cotto symbols would require a symbol table, which is too high-level for M0 in its current iteration
02:56 atrodo which is okay to me, since using an immutable string type register isn't real perfermant anyways
02:56 lucian the implementation can choose to ignore the intern command/op/whatever
02:56 cotto dukeleto, what's the difference?
02:56 atrodo lucian: I believe that it's the same concept
02:56 lucian atrodo: yes, but less "magic"
02:57 cotto @lucian, not dukeleto
02:57 cotto d'oh
02:57 atrodo lucian: how so?
02:57 lucian atrodo: they still look like strings, and are stored as such
02:57 lucian the interpreter can choose to intern them if it thinks it's a good idea
02:58 atrodo lucian: I still don't see the difference between symbols and intern strings
02:58 lucian atrodo: there isn't, really. they're both there for performance in this case
02:58 lucian symbols as a broad concept also afford clarity, which is a dubious advantage in m0's case
02:59 atrodo lucian: okay, then i'm really talking about intern strings
02:59 lucian atrodo: right, so you're not interested in quoting, or symbols-for-clarity?
03:00 lucian atrodo: the reason i'm mentioning interned strings is that many VMs intern all strings by default anyway
03:00 atrodo my lorito prototype's S register are intern strings
03:01 lucian the JVM for example, interns almost all strings. similarly CPython
03:01 atrodo lucian: Yes, which I would avoid doing.  If I had my way, Strings should be PMCs and treated as such (immutable or otherwise), and the S regsister are intern symbols
03:01 bubaflub ~
03:01 lucian atrodo: but it's not necessarily a bad idea to intern them, especially if they're literals
03:01 lucian literals can be even interned at compile-time
03:02 atrodo lucian: exactly
03:02 atrodo for key lookups and internal use, intern symbols are the way to go.  the strings exposed by HLLs should not be intern
03:04 lucian maybe
03:04 lucian is there a good reason not to intern them?
03:05 lucian perhaps interning is too vague a term
03:05 atrodo Performance, especially with a lot of string manipulation
03:05 lucian what i mean is creating new strings only when they haven't been created already
03:05 JimmyZ joined #parrot
03:05 lucian so that the same string created twice is (very likely to be) the same object
03:06 lucian atrodo: uh, maybe. the sun jvm disagrees
03:07 atrodo lucian: Oh yes?  Last I heard, using String to build a large string is frowned upon in java and StringBuilder is the preferred way to go
03:08 lucian atrodo: right, because creating and destroying lots of strings is wasteful. but not because of interning
03:08 lucian in fact, it turns out that interning always beats creating always, overall
03:08 lucian at least on the JVM
03:08 atrodo lucian: link?
03:09 lucian atrodo: i guess my point is that interning need not be so special, and could easily be an implementation detail of strings
03:09 lucian atrodo: uh, not handy
03:10 lucian atrodo: i think the sun jvm ends up doing heuristics to decide whether to bother interning. i believe string length might be a factor
03:10 lucian i should find that article
03:10 atrodo lucian: we're probably not that far apart on thinking
03:10 * benabik still wants to implement Ropes.
03:10 lucian benabik: that is very cool, indeed
03:11 benabik I wonder if I can get credit for it...
03:11 lucian atrodo: also, memory usage is drastically smaller with interning always. which reduces GC pressure, which makes things faster too
03:11 * atrodo still wants more time to actually hack on things
03:11 * lucian is paraphrasing what he read
03:11 cotto benabik, I can credit you for a lot of things
03:11 benabik cotto: Yes, thank you.  :-/
03:12 cotto benabik, you cured the common cold, right?
03:12 benabik cotto: Of course I did.  Several times.  But only for specific instances, not as a general case.
03:12 lucian atrodo: searching for that article, apparently different jvms have different behaviour on this
03:12 benabik It's like solving special relativity.
03:13 lucian atrodo: sometimes wildly different. some intern into a permanent GC arena, some intern forever (never release the string), some intern very smartly
03:14 cotto a lot of innovation happens in jvm implementations
03:15 lucian atrodo: the spec is very lenient apparently http://download.oracle.com/javase/1.4.2​/docs/api/java/lang/String.html#intern()
03:15 lucian cotto: yes, they're cool. best VMs around
03:15 atrodo lucian: interesting
03:16 lucian atrodo: although iirc, all java compilers intern all string literals, always
03:19 atrodo cotto: https://gist.github.com/1062861 # The end of my non-ipfy work from this past week
03:19 atrodo Commits to follow here soon
03:20 cotto atrodo, translating pir to your Lorito prototype?
03:20 cotto or pasm rather
03:20 atrodo cotto: Yea, I started the project some time ago
03:20 lucian as to writing a mole compiler, which was where this started ... :)
03:20 lucian atrodo: that sounds very useful
03:20 atrodo cotto: actually, the output from pbc_dump to alorito lasm
03:21 cotto lucian, thoughts on that are welcome too.
03:21 lucian cotto: i'm likely not the right person to discuss that, as i have little practical C experience
03:21 cotto who said anything about C?
03:22 cotto There are may ways to write a compiler.
03:22 cotto *many
03:22 lucian sure, but which would be acceptable for parrot besides C?
03:23 dalek parrot/opsc_lasm: 5f03cc5 | (Jon Gentle)++ | prototype_pbc2lasm.pl:
03:23 dalek parrot/opsc_lasm: Add $ to the register
03:23 dalek parrot/opsc_lasm: review: https://github.com/parrot/parrot/commit/5f03cc5b74
03:23 dalek parrot/opsc_lasm: f4961a2 | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
03:23 dalek parrot/opsc_lasm: Improve the coverage of outputted lasm
03:23 dalek parrot/opsc_lasm: review: https://github.com/parrot/parrot/commit/f4961a24ef
03:23 dalek parrot/opsc_lasm: 4cfe18c | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
03:23 dalek parrot/opsc_lasm: Make the register allocator in lasm.nqp dealloc all reigsters
03:23 dalek parrot/opsc_lasm: review: https://github.com/parrot/parrot/commit/4cfe18c76e
03:23 dalek parrot/opsc_lasm: 175b29e | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
03:23 dalek parrot/opsc_lasm: Add the ~(not) pirop
03:23 dalek parrot/opsc_lasm: review: https://github.com/parrot/parrot/commit/175b29e3ab
03:23 dalek parrot/opsc_lasm: ff94e27 | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
03:23 lucian cotto: hmm, are you planning something other than registers for mole?
03:23 dalek parrot/opsc_lasm: Fix the if pirop output
03:23 dalek parrot/opsc_lasm: review: https://github.com/parrot/parrot/commit/ff94e27033
03:23 cotto lucian, what do you mean?
03:24 lucian cotto: wait, i may be misunderstanding registers. how do m0 registers work?
03:24 cotto they're a word each.  A few are special, the rest are a bunch of bytes whose meaning depends on which ops access them.
03:24 cotto well, 8 bytes each
03:24 lucian cotto: right. are they limited?
03:25 cotto max of 255 per call frame with the possibility of spilling
03:25 cotto I'm also thinking about how to enable smaller register sets for when <255 are needed
03:25 lucian right. so i'd guess that C-like variables + register allocator aren't necessary
03:26 cotto for M0, no.  for mole, yes
03:26 lucian right, so you're planning non-register variables
03:27 cotto not currently
03:27 lucian ok
03:27 atrodo cotto: one thing before I call it a night.  the one thing to notice is how much is generated for something as simple as get_params_pc
03:27 cotto not sure where they'd go
03:27 lucian i'm not sure if having both is necessary in mole, if it's C-like
03:27 atrodo and it's not quite complete even
03:28 JimmyZ left #parrot
03:28 cotto atrodo, yes.  PIR hides a lot of complexity.  You're just the first one to deal with translating it into something other than C.
03:29 atrodo cotto: besides bacek.  At any rate, it gives me a bad feeling, that's all
03:29 cotto atrodo, since we're talking about PIR, you're probably doing it right
03:40 lucian cotto: bah, i thought gists had pull requests
03:40 lucian anyway, https://gist.github.com/1062879
03:40 lucian you can check out the diff
03:40 JimmyZ joined #parrot
03:41 cotto lamesauce.  the ".diff" trick doesn't work on gists
03:41 lucian lame...
03:41 lucian i didn't change much, just about arrays and strings a little
03:43 lucian cotto: perhaps that gist should move to a repo
03:43 lucian repos can also be edited directly on github, i think
03:45 cotto yes
03:45 cotto lucian, I'll see if I can promote it
03:46 lucian cotto: https://github.com/lucian1900/mole
03:47 cotto lucian, good sho
03:47 cotto w
03:47 lucian the hub gem is nice :)
03:48 cotto fork'd
03:49 Coke_ left #parrot
03:49 cotto lucian++
03:49 lucian cotto: you also have commit rights to mine
03:49 Coke joined #parrot
03:49 cotto ditto
03:49 cotto ;)
03:49 cotto I'll delete mine to minimize confusion
03:49 lucian cotto: so finally https://github.com/lucian1900/mole/commit​/2ac675a59db81d9185e848001c5d0266ea4ae750
03:50 * lucian shrugs. either one was fine by me
03:56 lucian cotto: if i were doing mole on my own for fun, i might use http://code.google.com/p/pycparser/
03:56 cotto actually, I should have my own for as a canonical-ish version
03:56 lucian it uses the PLY parsing framework
03:56 lucian but that might be entirely useless for parrot
03:56 cotto the part I relish least is dealing with flex and yacc
03:56 lucian another option might be hijacking clang, but that might be even worse
03:57 lucian there's also sparse, which is a C-subset compiler
03:57 benabik flex and bison
03:57 lucian and of course the classical tools, yes
03:57 cotto benabik, yes, those
03:57 lucian cotto: if not C, what else could it be?
03:58 cotto benabik, C is the best option.  That doesn't mean I have to like it.
03:58 benabik flex and bison aren't too bad.  If someone needs help with them, I should be able to write the grammars for them, with placeholders for the actual work.
03:58 lucian cotto: ideally such work will be rare afterwards :)
03:58 * lucian also dislikes C
03:58 benabik C++
03:58 cotto benabik, um...
03:59 cotto I dislike++ that.
03:59 lucian benabik: that's like burning the house to dry it :)
03:59 benabik I meant that the way aloha interpreted it.  :-D
03:59 benabik Although I also like C++
03:59 benabik Although I wouldn't say it's appropriate for this.
04:00 cotto ah.  (C)++
04:00 cotto though that might be interpreted as liking copyright
04:00 lucian Go uses bison i think, too
04:01 lucian i think some simplifications of C syntax that Go uses might be nice to borrow
04:18 cotto That Go article gets major cred for mentioning Perl 6 grammars.
04:21 cotto seems to be a true language geek
04:22 cotto This seems to be one of the few long articles that's worth reading to its conclusion.
04:23 lucian cotto: indeed, it's quite thorough
04:24 lucian if go was slightly more mature&popular, i'd prefer just using that as M1 :)
04:24 cotto no kidding about thoroughness
04:25 cotto it makes me want to run the final mole spec by him when we have something final-ish
04:25 lucian :)
04:26 lucian it makes me want to just hijack the Go parser, i guess
04:26 lucian it's C afaik
04:26 lucian hmm, the variable declaration doesn't fit
04:28 cotto I love that he says as part of the intro "here's a useful feature I just thought of that no langauge has."
04:32 lucian cotto: what in particular? can't find it
04:34 cotto lucian, second half of point 9 in the wishlist
04:35 cotto not a direct quote
04:35 lucian cotto: ah
04:35 lucian yeah, i've also had that need occasionally. i also use break/continue a lot
04:36 cotto me too.  It'd be nice.
04:36 lucian in C, a simple goto is enough, but perhaps too general
04:36 benabik Which article is this?
04:37 cotto benabik, http://www.syntax-k.de/projekte/go-review
04:38 benabik oh wow, that's long.
04:38 benabik I will read tomorrow.
04:38 cotto yeah
04:42 lucian cotto: http://golang.org/doc/go_faq​.html#no_pointer_arithmetic
04:42 lucian apparently they agree with me :)
04:47 lucian cotto: apparently some of Jörg's concerns will never be addressed. the creators of Go are strongly opposed to exposing syntax features to libraries (like overloading +, [ ], etc.)
04:48 lucian anyway, it's late
04:48 lucian nice talking to you, bye
04:49 lucian left #parrot
05:25 fperrad joined #parrot
05:25 daniel-s left #parrot
05:35 Drossel joined #parrot
05:37 Kulag left #parrot
05:39 Kulag joined #parrot
05:42 Drossel left #parrot
05:50 Kulag left #parrot
05:52 Kulag joined #parrot
06:01 moritz good morning
06:02 moritz msg dukeleto does the error still persist? according to http://validator.w3.org/check?uri=http%3​A%2F%2Firclog.perlgeek.de%2Fparrot%2F201​1-07-04&amp;charset=%28detect+automatica​lly%29&amp;doctype=Inline&amp;group=0 the markup is valid...
06:02 aloha OK. I'll deliver the message.
06:07 theory left #parrot
06:07 fperrad left #parrot
06:08 theory joined #parrot
06:08 fperrad joined #parrot
06:10 soh_cah_toa left #parrot
06:13 rohit_nsit08 joined #parrot
06:37 preflex left #parrot
06:38 dalek rakudo/nom: c4d4a74 | moritz++ | t/spectest.data:
06:38 dalek rakudo/nom: run three more spectest files, remove one that never passed
06:38 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c4d4a74730
06:39 dalek rakudo/nom: 0562684 | jonathan++ | src/core/IO.pm:
06:39 dalek rakudo/nom: Get print and say to use $*OUT; add note which uses $*ERR.
06:40 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/05626847ab
06:40 dalek rakudo/nom: d586e07 | jonathan++ | src/core/Mu.pm:
06:40 dalek rakudo/nom: Add warning to use of uninitialized value in string context, and make uninitialized value in numeric context warn and give back 0.
06:40 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d586e07840
06:40 dalek rakudo/nom: 34c2983 | jonathan++ | t/spectest.data:
06:40 dalek rakudo/nom: We now pass S03-operators/equality.t.
06:40 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/34c29834fc
06:40 preflex joined #parrot
06:46 dalek rakudo/nom: 23f5fbd | jonathan++ | LHF.markdown:
06:46 dalek rakudo/nom: Add a LHF.
06:46 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/23f5fbd897
06:49 dalek rakudo/nom: 157e4f8 | jonathan++ | LHF.markdown:
06:49 dalek rakudo/nom: Another (hopefully) LHF.
06:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/157e4f8754
06:56 dalek rakudo/nom: abd6769 | moritz++ | t/spectest.data:
06:56 dalek rakudo/nom: we pass a (highly fudged) binding-attributes.t
06:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/abd6769686
06:59 dalek rakudo/nom: 8b36d09 | moritz++ | / (3 files):
06:59 dalek rakudo/nom: infix == for Complex, wins us back any-complex.t. jnthn++
06:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8b36d09793
07:05 dalek rakudo/nom: 78388ab | moritz++ | t/spectest.data:
07:05 dalek rakudo/nom: run constant.t
07:05 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/78388ab031
07:18 dalek rakudo/nom: add464b | jonathan++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
07:18 dalek rakudo/nom: Fix Bool up a bit more; now Bool::True, Bool::False, True and False can all be mentioned.
07:18 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/add464b508
07:18 dalek rakudo/nom: 2ddc07d | jonathan++ | t/spectest.data:
07:19 dalek rakudo/nom: Now we *really* pass parsing-bool.t. :-)
07:19 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2ddc07da4f
07:23 rohit_nsit08 left #parrot
07:23 dalek rakudo/nom: b2b27f6 | jonathan++ | NOMMAP.markdown:
07:23 dalek rakudo/nom: Few nommap updates.
07:23 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b2b27f6503
07:26 mj41 joined #parrot
07:39 Kulag left #parrot
07:40 Kulag joined #parrot
07:45 mib_y8rzjr joined #parrot
07:49 daniel-s joined #parrot
07:59 dalek rakudo/nom: edef5dc | moritz++ | src/core/Num.pm:
07:59 dalek rakudo/nom: add pi and e constants
07:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/edef5dce82
08:00 dalek rakudo/nom: 11972a9 | moritz++ | t/spectest.data:
08:00 dalek rakudo/nom: 3 more passing test files
08:00 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/11972a96dc
08:00 dalek rakudo/nom: 179d411 | moritz++ | / (2 files):
08:00 dalek rakudo/nom: implement Int.Rat, pass unpolar.t
08:00 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/179d411e18
08:10 dalek rakudo/nom: dff16a7 | jonathan++ | / (3 files):
08:10 dalek rakudo/nom: Add Whatever.pm with an ACCEPTS that accepts everything, plus its own new.
08:10 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/dff16a76e8
08:10 dalek rakudo/nom: 362947a | jonathan++ | src/core/Mu.pm:
08:10 dalek rakudo/nom: Turn new into a multi. Add a candidate that dies if you try to give positional arguments. Update bless so it can take * as an initial parameter and create a candidate; inline this rather than calling .CREATE and use it in .new, thus saving a method invocation per .new call.
08:10 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/362947a05c
08:26 fperrad left #parrot
08:33 kurahaupo left #parrot
08:36 contingencyplan joined #parrot
08:42 dalek rakudo/nom: 3cae1b4 | moritz++ | src/core/Num.pm:
08:42 dalek rakudo/nom: constants should be "my", jnthn++
08:42 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3cae1b46d8
08:43 dalek rakudo/nom: c14785b | moritz++ | / (2 files):
08:43 dalek rakudo/nom: make log.t pass again
08:43 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c14785bb30
08:48 dalek parrot: 34af646 | chromatic++ | src/pmc/stringbuilder.pmc:
08:48 dalek parrot: [PMC] Avoided pushing empty strings in SB.
08:48 dalek parrot:
08:48 dalek parrot: This early exit improves the vpm.pir benchmark by 6.7%.
08:48 dalek parrot: review: https://github.com/parrot/parrot/commit/34af646276
08:48 dalek parrot: f64aebc | chromatic++ | src/pmc/stringbuilder.pmc:
08:48 dalek parrot: [PMC] Avoided encoding comparisons in push_string.
08:48 dalek parrot:
08:48 dalek parrot: When there's no need to look for a compatible encoding, don't look. This
08:48 dalek parrot: improves vpm.pir by 0.58%.
08:48 dalek parrot: review: https://github.com/parrot/parrot/commit/f64aebc8f4
08:48 dalek parrot: 0d06396 | chromatic++ | src/pmc/stringbuilder.pmc:
08:48 dalek parrot: [PMC] Optimized StringBuilder's push_string VTABLE.
08:48 dalek parrot:
08:48 dalek parrot: There's plenty of STRING encapsulation violation here, so avoiding a function
08:48 dalek parrot: call improves the SB-heavy benchmark of vpm.pir by 2.9%.
08:48 dalek parrot: review: https://github.com/parrot/parrot/commit/0d063967c8
08:48 dalek parrot: 41d54b9 | chromatic++ | src/string/api.c:
08:48 dalek parrot: [str] Fixed a typo.
08:48 dalek parrot: review: https://github.com/parrot/parrot/commit/41d54b99c6
08:48 dalek parrot: 318f52c | chromatic++ | src/gc/system.c:
08:48 dalek parrot: [GC] Added a PMC/STRING flag check to mem tracer.
08:48 dalek parrot:
08:48 dalek parrot: This should be safe (though feel free to revert if it causes odd GC behavior).
08:48 dalek parrot: In a GC-light vpm.pir benchmark, this improves performance by 0.946%. Depth of
08:49 dalek parrot: C stack as well as memory layout will vary these results.
08:49 dalek parrot: review: https://github.com/parrot/parrot/commit/318f52c503
08:49 dalek parrot: ce6505d | chromatic++ | src/string/api.c:
08:49 dalek parrot: [str] Optimized Parrot_str_join given empty joiner.
08:49 dalek parrot:
08:49 dalek parrot: This improves the vpm.pir benchmark by a whopping further 7.8%.
08:49 dalek parrot: review: https://github.com/parrot/parrot/commit/ce6505dc10
08:55 rohit_nsit08 joined #parrot
08:57 dalek rakudo/nom: a2aea3d | moritz++ | t/spectest.data:
08:57 dalek rakudo/nom: pass num.t
08:57 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a2aea3d35f
09:01 ttbot Parrot ce6505dc MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/27880
09:13 rohit_nsit08 left #parrot
09:14 dalek rakudo/nom: 1f421d3 | moritz++ | t/spectest.data:
09:14 dalek rakudo/nom: more passing tests
09:14 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1f421d3743
09:20 ttbot left #parrot
09:21 ttbot joined #parrot
09:26 dalek rakudo/podparser: e44bddd | tadzik++ | src/Perl6/SymbolTable.pm:
09:26 dalek rakudo/podparser: [SymbolTable] Allow named parameters to type_new in add_constant()
09:26 dalek rakudo/podparser: review: https://github.com/rakudo/rakudo/commit/e44bddd65c
09:26 dalek rakudo/podparser: 836c553 | tadzik++ | src/Perl6/ (2 files):
09:26 dalek rakudo/podparser: Install $POD into the $*UNIT scope as an List (empty so far)
09:26 dalek rakudo/podparser: review: https://github.com/rakudo/rakudo/commit/836c553732
09:27 woosley left #parrot
09:31 moritz tadzik: if you don't want to have your POD classes to have such hacky names, you can look at src/core/Exceptions.pm for a workaround for multi-part names
09:32 tadzik moritz: I'd look into that, thanks
09:32 moritz oh, wrong channel
09:34 tadzik cover blown!
09:37 dalek rakudo/nom: a0d429e | jonathan++ | src/ (3 files):
09:37 dalek rakudo/nom: First cut of support for automatically calling BUILD and initializing public attributes based on named arguments to .new/.bless. Doesn't yet handle default values or auto-vivifying type objects.
09:37 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a0d429e508
09:46 ambs joined #parrot
09:59 Drossel joined #parrot
10:01 Kulag left #parrot
10:04 Drossel left #parrot
10:08 dalek rakudo/nom: 478a82d | jonathan++ | t/spectest.data:
10:08 dalek rakudo/nom: Two more passing test files.
10:08 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/478a82dae2
10:09 dalek rakudo/podparser: 7bec705 | tadzik++ | / (25 files):
10:09 dalek rakudo/podparser: Merge branch 'nom' into podparser
10:09 dalek rakudo/podparser: review: https://github.com/rakudo/rakudo/commit/7bec7059f6
10:12 moritz btw the segfault in rindex.t happens in Parrot_str_concat
10:12 moritz callers: Parrot_scalar_concatenate_str, Parrot_concat_p_p_s, runops_fast_core
10:31 contingencyplan left #parrot
10:34 mib_y8rzjr left #parrot
10:38 mj41 left #parrot
10:42 dalek rakudo/nom: a0c28ce | jonathan++ | src/ (3 files):
10:42 dalek rakudo/nom: First cut of defaults for attributes. Still to do is only to do this to untouched attributes.
10:42 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a0c28ce5f0
10:42 dalek rakudo/nom: abdcbc3 | jonathan++ | src/Perl6/Actions.pm:
10:42 dalek rakudo/nom: Fix attributes refering to others in default value.
10:42 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/abdcbc3d2a
10:43 rurban_ joined #parrot
10:46 rurban left #parrot
10:46 rurban_ is now known as rurban
10:59 dalek rakudo/nom: 91077bf | jonathan++ | src/core/Mu.pm:
10:59 dalek rakudo/nom: Implement $obj.Parent::bar().
10:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/91077bf506
10:59 dalek rakudo/nom: 2302959 | jonathan++ | t/spectest.data:
10:59 dalek rakudo/nom: We now fully (unlike master) pass S12-attributes/inheritance.t.
10:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2302959e1e
10:59 dalek rakudo/nom: 4dd86c6 | jonathan++ | NOMMAP.markdown:
10:59 dalek rakudo/nom: Update nommap.
10:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/4dd86c6ce3
11:02 mj41 joined #parrot
11:06 JimmyZ left #parrot
11:07 ligne joined #parrot
11:11 whiteknight joined #parrot
11:16 dalek rakudo/nom: c3d1dcf | jonathan++ | t/spectest.data:
11:16 dalek rakudo/nom: Run S12-methods/submethods.t.
11:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c3d1dcfb62
11:36 mj41 left #parrot
11:47 dalek rakudo/podparser: c3c1aba | moritz++ | t/spectest.data:
11:47 dalek rakudo/podparser: we pass ord_and_chr.t
11:47 dalek rakudo/podparser: review: https://github.com/rakudo/rakudo/commit/c3c1aba630
11:47 dalek rakudo/podparser: f13f52b | moritz++ | t/spectest.data:
11:47 dalek rakudo/podparser: two more passing test files
11:47 dalek rakudo/podparser: review: https://github.com/rakudo/rakudo/commit/f13f52b3b2
11:50 tadzik moritz: wrong branch?
11:50 JimmyZ joined #parrot
11:50 tadzik oh, ww again
11:59 dalek rakudo/nom: 1b7e7f3 | moritz++ | t/spectest.data:
11:59 dalek rakudo/nom: we pass ord_and_chr.t
11:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1b7e7f31ab
11:59 dalek rakudo/nom: 1f659be | moritz++ | t/spectest.data:
11:59 dalek rakudo/nom: two more passing test files
11:59 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/1f659be45a
12:10 kid51 joined #parrot
12:14 mj41 joined #parrot
12:17 dalek rakudo/nom: 939629a | moritz++ | t/spectest.data:
12:17 dalek rakudo/nom: 5 more passing test files
12:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/939629a58b
12:23 redicaps joined #parrot
13:04 bluescreen_ left #parrot
13:04 bluescreen left #parrot
13:15 bluescreen_ joined #parrot
13:15 bluescreen joined #parrot
13:19 lucian joined #parrot
13:24 JimmyZ_ joined #parrot
13:27 whiteknight After writing so many tests in Winxed with Rosella, going back to write tests in PIR with Test_more.pir is a drag
13:28 whiteknight I have a file here with about 1100 characters written in it, and not a single test
13:28 JimmyZ left #parrot
13:29 JimmyZ_ is now known as JimmyZ
13:37 dalek rakudo/nom: df1de50 | pmichaud++ | src/core/metaops.pm:
13:37 dalek rakudo/nom: Change the NYI metaops to die instead of fail.
13:37 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/df1de50cb9
13:46 PacoLinux joined #parrot
14:24 dalek parrot: 48434d7 | ligne++ | src/string/api.c:
14:24 dalek parrot: fix C++ build failures due to unexpected const-ness
14:24 dalek parrot:
14:24 dalek parrot: VTABLE_push_string() expects a non-const STRING.  c++ says this is Not
14:24 dalek parrot: Allowed.  This fixes it.
14:24 dalek parrot: review: https://github.com/parrot/parrot/commit/48434d747f
14:24 dalek parrot: 5b67022 | cotto++ | src/string/api.c:
14:24 dalek parrot: Merge pull request #138 from ligne/g++-build-error
14:24 dalek parrot:
14:24 dalek parrot: fix C++ build failure due to unexpected const-ness
14:24 dalek parrot: review: https://github.com/parrot/parrot/commit/5b67022518
14:24 cotto ~~
14:25 jsut_ joined #parrot
14:26 cotto chromatic++
14:27 kid51 Hmm, I did not get that build failure that ligne's patch addressed
14:27 fperrad joined #parrot
14:30 cotto It looked like an innocent enough fix that I just merged it.
14:31 mj41 left #parrot
14:32 cotto I wonder if optimizing Parrot is what chromatic does when he can't sleep.
14:32 kid51 I'm not questioning the fix.  It just so happens that my last build was "all g++" and I didn't get any build error.
14:33 cotto kid51, it does break the c++ build for me
14:34 kid51 curious
14:34 cotto yes
14:37 ttbot Parrot 5b670225 MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/28172
14:37 JimmyZ_ joined #parrot
14:39 cotto lolwut
14:42 cotto not sure what to do about that
14:42 JimmyZ left #parrot
14:42 JimmyZ_ is now known as JimmyZ
14:43 cotto Ah.  looks like something chromatic did and mentioned as suspicious
14:45 dalek parrot: b6ba78b | cotto++ | src/gc/system.c:
14:45 dalek parrot: Revert "[GC] Added a PMC/STRING flag check to mem tracer."
14:45 dalek parrot:
14:45 dalek parrot: This reverts commit 318f52c503183a59d4e38e309eb46afba6361d00.  This
14:45 dalek parrot: caused failures in the windows build.
14:45 dalek parrot: review: https://github.com/parrot/parrot/commit/b6ba78be99
14:49 lichtkind joined #parrot
14:49 dalek rakudo/nom: 6c013c1 | jonathan++ | src/core/Mu.pm:
14:49 dalek rakudo/nom: Move a statement to avoid an accidental boxing every time around a loop (pmichaud++ for noticing).
14:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/6c013c1622
14:49 dalek rakudo/nom: 18fe583 | jonathan++ | src/binder/multidispatch.c:
14:49 dalek rakudo/nom: Fix multi-dispatches involving slurpy args.
14:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/18fe5830c2
14:51 kid51 That last series of commits (prior to the revert) also generated a build failure on darwin/ppc:
14:51 kid51 ./parrot-nqp --target=pir --output=compilers/opsc/ge​n/Ops/Compiler/Grammar.pir compilers/opsc/src/Ops/Compiler/Grammar.pm
14:51 kid51 make: *** [compilers/opsc/gen/Ops/Compiler/Grammar.pir] Segmentation fault
14:51 kid51 [parrot] 515 $ git show | head -1
14:51 kid51 commit 5b670225183fbbcc63ab0aee61635f3ab7e4ba99
14:51 cotto kid51, that looks like the windows failure
14:52 cotto is it working now for you?
14:52 kid51 pulling and restarting build; this being the notorious 7-y-o iBook, this will take a while
14:53 Coke left #parrot
14:54 Coke joined #parrot
14:59 whiteknight left #parrot
15:00 whiteknight joined #parrot
15:03 dalek parrot/whiteknight/packfilewrapper: 0b04c1f | Whiteknight++ | t/pmc/packfileview.t:
15:03 dalek parrot/whiteknight/packfilewrapper: add a stub test file for PackfileView
15:03 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/0b04c1f606
15:03 dalek parrot/whiteknight/packfilewrapper: d69738f | Whiteknight++ | MANIFEST:
15:03 dalek parrot/whiteknight/packfilewrapper: Add testfile to MANIFEST
15:03 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/d69738f6cf
15:03 dalek parrot/whiteknight/packfilewrapper: a43d2cc | Whiteknight++ | t/pmc/parrotinterpreter.t:
15:03 dalek parrot/whiteknight/packfilewrapper: Add tests to ParrotInterpreter for getting the current PackfileView
15:04 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/a43d2cc725
15:04 dalek parrot/whiteknight/packfilewrapper: 5613f8c | Whiteknight++ | t/pmc/packfileview.t:
15:04 dalek parrot/whiteknight/packfilewrapper: Add a few tests for PackfileView
15:04 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/5613f8c75a
15:06 kid51 cotto: at HEAD darwin/ppc completed 'make' once again; now running 'make test'
15:06 kid51 AOK on linux/i386 with all-g++ build
15:07 cotto kid51, great
15:07 kid51 whiteknight: What is PackfileView?
15:08 whiteknight it's a PMC wrapper type for packfile internals
15:08 whiteknight exposes things to PIR in a clean way, to allow us to deprecate some old garbage, and keep moving towards the removal of IMCC
15:09 whiteknight I want to have that branch in mergable condition before the release.
15:10 kid51 Sounds interesting.
15:10 cotto It's going in a good direction.
15:10 kid51 Given that we still don't have a working smolder, we don't have a steady stream of smoke reports on our supported platforms.
15:11 kid51 So I think that will require the code freeze to begin earlier than normal, especially since ...
15:11 cotto poking around the Packfile* PMCs is ok, but this provides a much nicer interface for those who don't want to bother with the low-level details
15:11 daniel-s left #parrot
15:11 kid51 ... it's a supported release  and ...
15:11 kid51 ... my first attempt at doing a release
15:11 whiteknight ah, okay
15:11 whiteknight it doesn't need to merge before the release, I just want it in that kind of condition
15:12 cotto I support merging before the release, but it's more up to the release manager.
15:12 cotto (if it's ready)
15:12 kid51 AFAICT, we didn't have a whole lot of new stuff in master since 3.5
15:17 Coke (working smolder) I thought smolder was working these days.
15:17 Coke (also, I just gave it a therapeutic restart)
15:17 fperrad left #parrot
15:20 fperrad joined #parrot
15:30 cotto whiteknight, I have a few small fixed to that branch.  mind if I push?
15:31 cotto just c89 tax payment and some test cleanup
15:36 zby_home joined #parrot
15:37 cotto too late
15:37 dalek parrot/whiteknight/packfilewrapper: 88f9a1a | cotto++ | src/pmc/packfile (2 files):
15:38 dalek parrot/whiteknight/packfilewrapper: C89 tax (no variable declarations after the beginning of a block)
15:38 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/88f9a1a995
15:38 dalek parrot/whiteknight/packfilewrapper: 1041355 | cotto++ | t/pmc/packfileview.t:
15:38 dalek parrot/whiteknight/packfilewrapper: add some test messages, a shebang and a vim coda
15:38 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/1041355f75
15:38 whiteknight okay, I'm doing some codestd stuff now too.
15:38 whiteknight mostly docs in PackfileView
15:41 bubaflub morning, #parrot
15:41 whiteknight hello bubaflub
15:42 bubaflub hello whiteknight - good work on the packfile stuff.
15:42 whiteknight thanks!
15:43 redicaps left #parrot
15:47 kid51 Coke: I guess I've gotten so used to smolder's absence that I didn't even think it would be there ;-)  Thanks.
15:50 kid51 OMG Smolder is indeed back!  http://smolder.parrot.org/a​pp/projects/smoke_reports/1
15:51 dalek parrot/whiteknight/packfilewrapper: fc1ccf8 | Whiteknight++ | / (2 files):
15:51 dalek parrot/whiteknight/packfilewrapper: +docs and some rearranging for PackfileView
15:51 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/fc1ccf88eb
15:51 whiteknight ...and we're back to checkdepend.t. My old nemesis
15:58 cotto whiteknight, you want a hand?
15:58 whiteknight no, I think I have it
15:58 whiteknight I'm building now
15:58 cotto good times
15:59 dalek parrot/whiteknight/packfilewrapper: da61254 | Whiteknight++ | config/gen/makefiles/root.in:
15:59 dalek parrot/whiteknight/packfilewrapper: fix checkdepend.t
15:59 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/da61254816
16:00 whiteknight I have a few more tests that need to get filled in to t/pmc/packfileview.t, then I think I'm basically done
16:00 cotto whiteknight, so you're completely done apart from adding some tests?
16:00 JimmyZ left #parrot
16:01 whiteknight as far as I am concerned, yes. More feedback may change that opinion
16:01 cotto Great.  Are there any tests you feel like delegating?
16:02 whiteknight most of them should be pretty straightforward
16:02 whiteknight you're welcome to put your hands on any tests you want to
16:03 whiteknight using the new PMC is a great way to learn it
16:03 cotto exactly
16:03 dalek parrot-gmp: 5dcb024 | bubaflub++ | / (6 files):
16:03 dalek parrot-gmp: vtable overrides and tests for add, add_int, add_float
16:03 dalek parrot-gmp: review: https://github.com/bubaflub/​parrot-gmp/commit/5dcb024824
16:04 cotto whiteknight++ for the docs
16:05 bubaflub whiteknight: if you've got a moment, i've got a question about Winxed and vtable overrides.
16:05 whiteknight bubaflub: ENOMOMENTS
16:05 whiteknight just kidding. Lots of moments. What do you need?
16:06 bubaflub i've got add, add_int, and add_float - in the tests for add i can do something like x = y + z, but in the tests for add_int and add_float i have to explicitly call ${ add x, y, z}; or i get an error
16:06 whiteknight Hmmm.... I notice that there are no tests for IMCCompiler. I wonder how I missed adding those
16:07 whiteknight bubaflub: yeah, winxed doesn't always generate all the right opcodes
16:07 bubaflub whiteknight: ok, i'm looking at the generated pir
16:07 whiteknight what does it generate for x = y + z, where z is a float or an int?
16:08 bubaflub set $I4, $P2
16:08 bubaflub add $I3, $I4, $I1
16:08 bubaflub box $P1, $I3
16:08 whiteknight oi
16:08 whiteknight what you're most interested in is testing the vtable overrides you've written, not testing winxed syntax does what you like
16:08 bubaflub right
16:09 whiteknight so do whatever you need to do to call your vtables, even if it's ugly winxed code
16:09 bubaflub i'm ok with the ${ add ... } syntax, just wondering if there was a better way
16:09 bubaflub ok, that answers my question.  thanks.
16:09 bubaflub oh, also
16:09 bubaflub ${ add x, y} will hit the i_add vtables, right?
16:10 whiteknight yes
16:10 whiteknight take a look at src/ops/math.ops to see what each opcode does
16:10 bubaflub woot.
16:11 whiteknight but 2-arg arithmetic ops should call the i_* 2-arg vtables
16:15 kid51 whiteknight: In general, are problems with check_depends.t solved by editing config/gen/makefiles/root.in?
16:15 whiteknight kid51: yeah, that's where I usually end up fixing things
16:16 kid51 I ask 'cause I know soh_cah_toa has some failures there to fix in his branch
16:17 cotto kid51, it's also necessary to rebuild the makefile since that's what's being tested by check_depends.t
16:23 lucian left #parrot
16:35 bubaflub whiteknight: another question for ya - GMP has three kinds of divides, rounding the quotient to the ceiling, to the floor, and truncating.  there are vtable overrides specifically for ceiling division, so which one should i use for plain 'ole div?  truncate?
16:36 whiteknight I would say so, yes
16:36 whiteknight coverage?
16:36 whiteknight aloha: coverage?
16:36 aloha whiteknight: coverage is http://cv.perl6.cz or http://tapir2.ro.vutbr.cz/cover/cover-results/
16:41 whiteknight I *really* want to deprecate the automatic execution of :init and :load subs
16:42 whiteknight PackfileView allows us to start doing that
16:45 dalek parrot/whiteknight/packfilewrapper: 93d9a9b | Whiteknight++ | t/pmc/packfileview.t:
16:45 dalek parrot/whiteknight/packfilewrapper: Add more tests for packfileview
16:45 dalek parrot/whiteknight/packfilewrapper: review: https://github.com/parrot/parrot/commit/93d9a9b6d1
16:46 theory left #parrot
17:03 janus joined #parrot
17:07 jlaire joined #parrot
17:08 kid51 Is it considered polite for someone other than a GSOC mentor to commit to a GSOC student's branch?
17:09 contingencyplan joined #parrot
17:09 cotto kid51, go for it.  Just make sure that either the mentor or the student knows what's going on.
17:10 kid51 cotto:  The mentor in question is You! soh_cah_toa is student
17:11 cotto kid51, I figured.  Can you nopaste the patch(es)?
17:11 kid51 Within about 10 min
17:11 cotto wfm
17:12 kid51 This has enabled me to learn about t/src/checkdepends.t
17:12 kid51 Need to run make test
17:32 nopaste "kid51" at 192.168.1.3 pasted "hbdb branch: Eliminate all but one failure in t/src/checkdepends.t; see http://smolder.parrot.org/app/​projects/report_details/16944." (117 lines) at http://nopaste.snit.ch/57477
17:40 cotto kid51, that has a number of files unrelated to the branch.  Let me sync it with master first.
17:42 mj41 joined #parrot
17:44 cotto testing now
17:49 cotto kid51, all yours
17:49 dalek parrot/soh-cah-toa/hbdb: 2a8794f | cotto++ | / (236 files):
17:49 dalek parrot/soh-cah-toa/hbdb: Merge branch 'master' into soh-cah-toa/hbdb
17:49 dalek parrot/soh-cah-toa/hbdb:
17:49 dalek parrot/soh-cah-toa/hbdb: Conflicts:
17:49 dalek parrot/soh-cah-toa/hbdb: .gitignore
17:49 dalek parrot/soh-cah-toa/hbdb: config/gen/makefiles/root.in
17:49 dalek parrot/soh-cah-toa/hbdb: review: https://github.com/parrot/parrot/commit/2a8794f6da
17:50 kid51 BTW just had a successful smolder on packfilewrapper branch
17:51 kid51 cotto: What git command did you use for that?
17:52 cotto git merge
17:52 cotto and manually fix the conflicts
17:52 kid51 git merge master ??
17:52 cotto yes
17:53 kid51 okay.  I have not been in situations where I wanted to merge master into a branch.
17:53 cotto master is just another branch
18:03 dalek parrot/soh-cah-toa/hbdb: 3f13b7f | jkeenan++ | config/gen/makefiles/root.in:
18:03 dalek parrot/soh-cah-toa/hbdb: Fix all but one FAIL in t/src/checkdepends.t.  Thanks for hints from whiteknight++ and cotto++.
18:03 dalek parrot/soh-cah-toa/hbdb: review: https://github.com/parrot/parrot/commit/3f13b7ffb4
18:04 kid51 smolder: http://smolder.parrot.org/app/​projects/report_details/16948
18:04 kid51 afk
18:12 bluescreen_ left #parrot
18:12 bluescreen left #parrot
18:13 bluescreen joined #parrot
18:16 fperrad left #parrot
18:19 dalek TT #1083 closed by NotFound++: Managed cstrings to avoid the need of Parrot_str_free_cstring
18:19 dalek TT #1083: http://trac.parrot.org/parrot/ticket/1083
18:31 ambs left #parrot
18:41 dalek rakudo/nom: d9d8c49 | moritz++ | src/core/Complex.pm:
18:41 dalek rakudo/nom: fix Complex exponentation
18:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d9d8c49428
18:41 dalek rakudo/nom: ce2882f | moritz++ | src/core/Real.pm:
18:41 dalek rakudo/nom: add infix mod
18:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ce2882f06c
18:41 dalek rakudo/nom: d2a8943 | moritz++ | / (2 files):
18:41 dalek rakudo/nom: sub forms of pop, shift, push
18:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d2a8943611
18:43 rurban_ joined #parrot
18:46 rurban left #parrot
18:46 rurban_ is now known as rurban
19:01 dalek rakudo/nom: 97e5710 | moritz++ | t/spectest.data:
19:01 dalek rakudo/nom: nine more passing test files
19:01 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/97e571018b
19:06 dalek TT #1085 closed by coke++: TclLibrary.pir and tcl_lib.t update
19:06 dalek TT #1085: http://trac.parrot.org/parrot/ticket/1085
19:15 cotto msg whiteknight I have some random-esque thoughts on profiling at https://gist.github.com/1063804 .  It's nothing blog-worthy, but it's a starting point for discussion.
19:15 aloha OK. I'll deliver the message.
19:18 cotto I'm out until this evening.
19:41 lucian joined #parrot
19:49 kid51 left #parrot
19:57 dalek rakudo/nom: a2b9926 | masak++ | LHF.markdown:
19:57 dalek rakudo/nom: [LHF.markdown] Int.Rat implemented
19:57 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/a2b99262c2
20:01 whiteknight cotto: okay, I'll take a look soon
20:14 dalek nqp: 8557631 | pmichaud++ | src/core/NQPMu.pm:
20:14 dalek nqp: Add a version of __dump() to NQPMu so that NQP objects can
20:14 dalek nqp: be used by Parrot's Data::Dumper.
20:14 dalek nqp: review: https://github.com/perl6/nqp/commit/8557631585
20:17 dalek rakudo/nom: 59ec8c6 | moritz++ | / (2 files):
20:17 dalek rakudo/nom: infix cmp for Pairs
20:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/59ec8c6a6b
20:24 Eclesia joined #parrot
20:24 Eclesia hi
20:25 Eclesia someone know how to list all variables of an object ?
20:25 Eclesia (in winxed)
20:28 dalek rakudo/nom: 535395f | moritz++ | t/spectest.data:
20:28 dalek rakudo/nom: run arith.t
20:28 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/535395f44e
20:31 Eclesia whiteknight hi
20:33 dalek rakudo/nom: 8f1d810 | moritz++ | t/spectest.data:
20:33 dalek rakudo/nom: two more passing test files
20:33 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/8f1d810c5b
20:35 bluescreen left #parrot
20:35 soh_cah_toa joined #parrot
20:37 varta joined #parrot
20:39 mj41 left #parrot
20:39 dalek rakudo/nom: 56a1e10 | moritz++ | / (2 files):
20:39 dalek rakudo/nom: Complex.sqrt, tests
20:39 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/56a1e10b13
20:39 varta left #parrot
20:46 bluescreen joined #parrot
20:46 Eclesia NotFound you are here ?
20:46 NotFound Eclesia: yes
20:47 Eclesia NotFound: cool, what is the typeof equivalent in winxed ?
20:47 dalek rakudo/nom: 3e5c741 | pmichaud++ | src/core/ (2 files):
20:47 dalek rakudo/nom: Add List.sort and Any.sort.
20:47 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/3e5c741bf4
20:48 NotFound Eclesia: the builtin typeof
20:48 Eclesia NotFound: what I want to do, is make something like : if (obj instanceof something){ ....
20:49 NotFound Eclesia: then instanceof
20:49 Eclesia NotFound: and how can I have a list of all variables of an object ?
20:50 NotFound Eclesia: What do you mean? The attributes?
20:50 mj41 joined #parrot
20:50 Eclesia NotFound: I'm searching some kind of reflexion, get the attributes with there name and value
20:52 NotFound You can get the attributes using inspect_str on the class object. There is no winxed direct support for that but you can use pirops.
20:53 Eclesia NotFound: you have an example ?
20:53 Coke left #parrot
20:54 Coke joined #parrot
20:54 NotFound Eclesia: no
20:55 dalek rakudo/nom: ca93c8a | pmichaud++ | src/core/Any.pm:
20:55 dalek rakudo/nom: Fix Any.join -- default separator should be '' and not ' '.  pmichaud--  S04-statements/for-scope.t now passes.  moritz++
20:55 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ca93c8a891
20:56 dalek rakudo/nom: 2cac886 | pmichaud++ | t/spectest.data:
20:56 dalek rakudo/nom: Add S04-statements/for-scope.t to spectest.data.
20:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/2cac886253
21:00 NotFound Eclesia: $ winxed -e 'var i = new ["Exception"]; var c = typeof(i); var attrs; ${ inspect attrs, c, "attributes" }; for (string attr in attrs) say(attr);'
21:03 Eclesia NotFound: thanks, just one thing missing, how to get the value of attribute 'attr'
21:04 NotFound Eclesia: obj.attr
21:05 Eclesia ho... just like that ...
21:05 * Eclesia is still too much used to java
21:05 NotFound Mmmm.... is you have the name in a variable is different...
21:06 Eclesia NotFound: that's the case here, since I'm in the attributes loop. so I just have the name
21:06 Eclesia (like in your exemple)
21:08 NotFound You can use the builtin getattribute
21:11 NotFound But note the vtable functions that handle attributes can be overriden, so there is no guarantee that the results are consistent with inspect.
21:37 Eclesia left #parrot
21:39 PerlJam left #parrot
21:39 tadzik left #parrot
21:39 pmichaud left #parrot
21:40 Util left #parrot
21:42 Psyche^ joined #parrot
21:44 dalek Rosella: ed0a8f0 | Whiteknight++ | src/unstable/template/ (2 files):
21:44 dalek Rosella: refactor out Logic nodes in template to separate out the behavior of a Logic node from individual logic types. Add support for if/else, and add some features to forloops
21:44 dalek Rosella: review: https://github.com/Whiteknig​ht/Rosella/commit/ed0a8f07ec
21:44 dalek nqp: de23ea5 | pmichaud++ | src/core/NQPMu.pm:
21:44 dalek nqp: Make NQPMu.__dump aware of native types in attributes.
21:44 dalek nqp: review: https://github.com/perl6/nqp/commit/de23ea5261
21:47 Patterner left #parrot
21:47 Psyche^ is now known as Patterner
22:11 tadzik joined #parrot
22:12 Util joined #parrot
22:13 dalek parrot: 62c761d | chromatic++ | src/runcore/cores.c:
22:13 dalek parrot: [rc] Enabled PC tracking in fast core.
22:13 dalek parrot: review: https://github.com/parrot/parrot/commit/62c761d802
22:13 dalek parrot: 273c003 | chromatic++ | frontend/parrot/main.c:
22:13 dalek parrot: [rc] Made fast runcore the default.
22:13 dalek parrot:
22:13 dalek parrot: This should be safe, given the previous commit of dabaf8c. This gives the op
22:13 dalek parrot: dispatch benchmark mops_intval.pasm a 27.56% performance improvement. Other
22:13 dalek parrot: programs will show less benefit, but faster op dispatch is still a good thing.
22:13 dalek parrot: review: https://github.com/parrot/parrot/commit/273c003933
22:13 dalek parrot: 89cf287 | chromatic++ | / (2 files):
22:13 dalek parrot: [OO] Optimized Parrot_pmc_get_type_str() slightly.
22:13 dalek parrot:
22:13 dalek parrot: Because the classname -> integer mapper is an internal implementation detail
22:13 dalek parrot: which should never leak out of the OO subsystem, it's okay to break the VTABLE
22:13 dalek parrot: encapsulation in this case. This provides a 2.33% performance improvement on
22:13 dalek parrot: the OO-heavy stress1.pasm benchmark and should also help any other code which
22:13 dalek parrot: creates objects based on string class names.
22:13 dalek parrot:
22:13 dalek parrot: Arguably Parrot should resolve string literals to class objects at compilation
22:13 dalek parrot: or optimization time, but that's a larger change.
22:13 dalek parrot:
22:13 dalek parrot: As this commit includes a Makefile dependency addition, reconfigure
22:13 dalek parrot: recommended, but not required.
22:13 dalek parrot: review: https://github.com/parrot/parrot/commit/89cf287a73
22:15 PerlJam joined #parrot
22:16 pmichaud joined #parrot
22:17 bubaflub chromatic++ - glad to see him back in action
22:31 lucian left #parrot
22:49 mj41 left #parrot
22:51 dalek parrot-gmp: 588f5bd | bubaflub++ | / (18 files):
22:51 dalek parrot-gmp: finish code for vtable overrides, tests for i_add*, i_mul*, mul_*, sub_*
22:51 dalek parrot-gmp: review: https://github.com/bubaflub/​parrot-gmp/commit/588f5bd35c
22:54 whiteknight chromatic++ indeed
22:55 bubaflub whiteknight: another question for ya - i'm using your rosella testing stuff for parrot-gmp, is there a way to turn on timing for the test suite?
22:55 bubaflub whiteknight: or should i just use "time parrot-nqp t/harness"
22:55 whiteknight timing? no, I don't have anything like that builtin
22:55 bubaflub whiteknight: no prob.
22:55 whiteknight you can use the winxed builtin floattime in the harness
22:56 whiteknight I could add that pretty easily to Test too, for individual files
22:56 bubaflub whiteknight: i don't know how useful such things would be generally
22:59 whiteknight If you run a test file individually, it prints out a little comment at the end with the status. "you failed X tests out of Y", etc
22:59 whiteknight I can easily print a little (14.3s) timestamp
23:00 whiteknight it's similarly easy to output a quick timestamp in the summary from the harness
23:19 mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#16963), fulltest) at 3_5_0-67-g89cf287
23:19 mikehh Ubuntu 11.04 i386 (g++ --optimize)
23:20 mikehh whiteknight: still getting the occaisional Segmentation fault in t/pmc/threads.t (passes on re-run)
23:33 whiteknight mikehh: of course. The test is broken.

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

Parrot | source cross referenced