Parrot 3.5.0 "Menelaus" released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 27 June 2011.
00:05 Coke left 00:06 Coke joined 00:13 Coke left, Coke joined 00:23 Coke left, Coke joined
dukeleto cotto: which blog post do you need feedback on? backscrolling is a cruel mistress 00:25
cotto dukeleto, reparrot.blogspot.com/2011/07/parro...-2011.html
mostly feedback on the general idea and implementation 00:26
dukeleto cotto: ok 00:27
cotto: also, i have feedback re: crc32
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
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.
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
dukeleto lucian: are you volunteering? 00:32
lucian dukeleto: no :)
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.
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, Coke joined
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.
lucian or is it just M0-ified winxed/close 00:34
cotto only a gist
just a sec
lucian, gist.github.com/1048210#file_syntax is as much as exists
I'm just working through the syntax.
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
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
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
cotto lucian, suggestions on mole are more than welcome.
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 :)
lucian it gets a lot of syntax decisions much less wrong than C
cotto lucian, less wrong than C is great. 00:38
lucian dukeleto: :) if i get sick enough of build systems, maybe i'll try
cotto I'll do that.
lucian cotto: in particular variable declaration and pointer syntax is somewhat better in Go
ifs too
cotto: go's object system is also interesting
cotto: www.syntax-k.de/projekte/go-review
cotto 6model will be implemented in mole, so it can't have its own built-in object system. 00:39
thanks!
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:40
lucian cotto: it's really, really nice, except for a few giant ugly warts 00:41
you should read that article when you have time, it's exceptionally well written
but in short, its object system is "just" structs. there's no inheritance, just composition + dispatch
ooc has a vaguely similar feature called "covers" 00:42
cotto lucian, the article looks solid so far.
I'm reading it now.
I'm not a great artist, but I still like stealing. 00:43
lucian yes, stealing ideas is great
i like the proposed strings in that gist 00:44
similarly, i'd propose either "fat" pointers like cyclone or slices like Go instead of raw pointer arithmetic
dukeleto cotto: i like the Parrot Weekly News blog post 00:46
00:46 Coke left, Coke joined
dukeleto cotto: so if we say PWN on a line, it gets starred somehow? Where is that described in a bit more detail? 00:46
cotto dukeleto, there's no magic. I'll just grep irclog for "PWN". I figured that'd be the laziest approach. 00:47
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
I'll note that in the blog
post
dukeleto msg moritz i get XML Parsing Error: undefined entity Location: irclog.perlgeek.de/parrot/2011-07-04 Line Number 27, Column 41: 00:49
aloha OK. I'll deliver the message.
dukeleto msg moritz that error is from FF 3.6.x
aloha OK. I'll deliver the message.
dukeleto msg moritz it is complaining about ← 00:51
aloha OK. I'll deliver the message.
benabik cotto: PWNed? 00:53
lucian cotto: commented on that gist
cotto benabik, it was hard not to suggest that (or PWN'd)
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:55
lucian cotto: right. then why chunks? 00:56
cotto lucian, that's from M0. A better name is reasonable.
lucian i see 00:57
cotto Very little is final.
lucian i guess i'd prefer "ops" to "composed ops" in the declaration
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
benabik cotto: Composed chunks are more macroish?
cotto composed ops? yes
lucian oh, and about macros. i don't think anything beyond conditional compilation is very useful 00:59
C's preprocessor is just silly, but on the other hand it's already written and can be invoked separately
cotto lucian, I don't want C-like macros at all.
lucian there's a feature i like in D, called static if 01:00
benabik composed ops, yes.
lucian it's just like if, but compile-time
cotto lucian, what'd the difference between that and #IF ?
benabik Syntax based instead of text, I'd assume.
Technically any if that contains a constant value should be able to do that.
lucian cotto: nicer syntax and less chance of craziness
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.
lucian the other use-case i've seen for macros is pseudo-functions. but there's composed ops for that
cotto: right, but if the keyword is "static if", the meaning's clear 01:03
01:03 Coke left, Coke joined
cotto I hate the way github does comments on gists. 01:04
They'd be so much more useful if they acted like full repos.
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
lucian, not I am a fan
benabik Does mole have type*? 01:06
lucian cotto: in any case, i think disallowing "int *" vs "int*" is necessary
lots of errors in C exist because of things like "int *a, b" vs "int* a, b" confusion
cotto lucian, I like that.
sorear had a similar suggestion.
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?
benabik lucian: No, where type is int, pmc, string, etc.
lucian benabik: well, i have the opposite view. i think it should clearly attach to the type
benabik: good point. mole needs at the very least some sort of typedef 01:08
not C's typedef though, it's broken badl
y
benabik lucian: It clearly attaches to the variable in C, and using C syntax without C semantics is just confusing.
s/clearly //
lucian benabik: yes, it attaches to the variable in C, to the type in Java/C#/etc 01:09
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, Coke left
benabik lucian: Java doesn't have pointers. Or, rather, it doesn't have non-pointers. 01:09
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.
lucian what does C++ do?
benabik *begging to confuse someone.
C++ uses C.
soh_cah_toa i believe it attaches to the type
lucian soh_cah_toa: yes, i remember the same 01:11
and that would explain why C# does the same
benabik I'm pretty sure it's as per C, but don't have a reference to point to.
int *a, b; int c; b = &c; 01:13
g++ says: invalid conversion from ‘int*’ to ‘int’
01:14 kid51 joined
lucian i see 01:14
anyway, it's a small issue 01:15
i believe it's much more important to fix arithmetic
rather, disallow it 01:16
benabik Either way we should probably outlaw either "int*" or "int *", whichever is invalid.
lucian benabik: yes, certainly
benabik Pointer arithmetic is very useful in C. Probably has no place in parrot. 01:17
soh_cah_toa flip a coin, maybe?
lucian benabik: it has no bounds checking in C, but it could be useful in parrot
cotto soh_cah_toa, heads
soh_cah_toa b/c it's all just a matter of personal preference
no one is "better" than the other
lucian soh_cah_toa: benabik does have a point that the more popular choice is likely "better" overall
cotto less confusing is better 01:18
lucian how would arrays work in mole?
cotto or surprising
soh_cah_toa agreed
lucian cotto: the issue is thorny since C has promoted the confusing and surprising semantic
benabik Principle of least surprise.
cotto lucian, that's a valid concern.
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.
soh_cah_toa kid51: i had the same thing
cotto kid51, did you try the back button?
lame
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.
lucian: I try to do that as well. In this case, I ... forgot.
01:19 JimmyZ joined
kid51 So here's the short version of the comments: 01:20
Each of the 3 wiki pages you cite under Room for Improvement is at least 11 months old, i.e., stale. 01:21
Which, IMHO, is what inevitably happens with wikis that are not focused on a deadline (like, say, the YAPC wikis).
What we should do, IMO, is identify two or three important enough to be made roadmap goals.
Also, in same subsection, but different topic ... 01:22
... we need to say what the specific function of config_lib.pir is before we start deleting entries from it.
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
ENDOFRANT
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
cotto The wiki pages are indeed old. I almost recommended consolidating and pruning them as a task. Perhaps I should. 01:25
dalek kudo/nom: 9928a0d | jonathan++ | src/Perl6/ (3 files):
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
cotto btw, I've enabled anonymous comments. Hopefully the lameness with dropping comments doesn't happen again.
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?
cotto I'm really sorry about that. I know how frustrating it is.
lucian soh_cah_toa: also, how do strings fit into that?
soh_cah_toa yes
strings...maybe just pmc type? 01:27
cotto primitive strings
object strings will be just another object
soh_cah_toa ok
so you do want primitive strings then. ok
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?
cotto benabik, yes.
benabik Hah.
cotto primtive strings will be fairly close to C-strings
object strings will be closer to Parrot STRINGS (though more like String PMCs)
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??
Please?
benabik dislikes that String PMC responds to assign VTABLE.
lucian benabik: i don't think immutability is in question here
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 :)
i think everything should be immutable by default, but that's another matter
cotto immutable STRINGs happened fairly recently
benabik lucian++
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
cotto unmutes lucian
cotto immutes lucian
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
benabik It is var easier to build mutable data structures from immutable than the other way around.
If this is a system level language, then attempting to hide how things really works is a bad idea.
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.
benabik C strings are character arrays because that's how it's stored in memory.
soh_cah_toa i thought we were trying to make it a little higher level than c? maybe i misjudged?
lucian i'd like mole arrays to be like C ones (pointers)
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
lucian benabik: too high? too low?
benabik (i.e. "just like C" ;-) )
benabik likes C. 01:34
lucian doesn't
cotto You'll find a brick taped to the bottom of your chairs. I think you know what to do.
lucian benabik: but i think we can both agree that having bounds checking on arrays/pointers/strings is a good idea
cotto ;)
lucian and that headers or fat pointers provide this
benabik lucian: Kind of?
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.
soh_cah_toa so we're trying to make it on the same level (as far as abstraction goes) as c?
cotto That's also my concern for bounds checking.
lucian benabik: right, but C isn't gc-ed or part of a runtime
soh_cah_toa: i guess
cotto soh_cah_toa, approximately
lucian how about making voluntary bounds checking easier instead?
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
soh_cah_toa then why not just use c? i mean, isn't mole trying to solve the c -> pir and pir ->c problem?
benabik soh_cah_toa: It'll be like C, but inside the VM instead of outside.
soh_cah_toa if it's like c, then we still have that problem
lucian soh_cah_toa: because C implies a lot of things 01:37
soh_cah_toa oh i see
cotto soh_cah_toa, M0 solves that. mole makes M0 usable for non-trivial tasks
lucian benabik: yes, we do. we also don't want it to crash, i guess
benabik lucian: Also true.
soh_cah_toa what will mole compile down to?
lucian if i get a vote, i put it down for mandatory bounds checking :)
cotto soh_cah_toa, M0
lucian soh_cah_toa: m0
soh_cah_toa then down to c from there? 01:38
lucian ideally, m0 bytecode directly i guess?
benabik lucian: I'm okay with default bounds checking. :-D
cotto mole = "M0 Overlay LanguagE"
lucian soh_cah_toa: or jitted
benabik (default implying "able to turn off", of course)
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
benabik lucian: Probably per-variable.
lucian benabik: so you'd declare a variable as non-bounds-checkable
soh_cah_toa ah, the way pasm and pbc were supposed to be ;)
benabik lucian: `unsafe int *x`
cotto soh_cah_toa, yes
That's a really interesting idea. 01:40
benabik wants to resurrect PASM.
lucian benabik: right. yes, i guess that's reasonable. what do you think of an unsafe { } block instead?
benabik lucian: unsafe(x) {}, perhaps... Declaring all pointers to be unsafe in a block is probably not wise?
lucian benabik: ah, yes, of course
the whole point of a block would be to reduce the unsafe section
benabik Exaclty. 01:41
lucian an unsafe variable could live a long and troubled life
benabik lucian: True.
lucian perhaps both options could exist,i guess
it doesn't seem like a high overhead for a compiler
01:41 woosley joined
benabik I want to resurrect PASM, with the ability to do a complete round-trip. 01:42
And then kill PIR. Kill it with fire.
cotto alternately, be unsafe by default. It depends on which is more common.
benabik Safe by default is, well, safer. :-D
cotto or make it an interpreter feature
lucian cotto: i'd argue all the buffer overflows we hear about should suggest for safe by default
nopaste "kid51" at 192.168.1.3 pasted "hbdb branch: much improved" (27 lines) at nopaste.snit.ch/57256 01:43
soh_cah_toa kid51: no build errors. but many segfaults :(
lucian cotto: gcj has an option just like that, to compile without bounds checks. instead of an exception, you get memory corruption/crashes
cotto lucian, tasty
lucian it makes sense i guess for mole to have similar. since it's generating extra M0 for the bounds checks anyway 01:44
default to safe, and override per file, per variable or per block
cotto lucian, are you thinking that M0 arrays would always have a length, but that without safety it'd be ignored?
lucian interestingly, some JITs remove bounds checks where it's proven to be safe 01:45
cotto: yes
cotto: or perhaps remove the header for unsafe pointers/arrays?
cotto lucian, I love the way a good JIT can cheat flagrantly and get away with it
lucian i don't know how siginficant the header would be
cotto lucian, that'd mean changing indexes 01:46
benabik The length is probably available _somewhere_, assuming it's created inside the GC.
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
benabik I like GCs that store array lengths at index -1. :-D
lucian benabik: right, good point
could the header be "virtual"?
or is that a good idea at all? 01:47
soh_cah_toa oh, never seen that before. i like that idea
cotto I'm not sure if it is.
lucian benabik: also, not all arrays/pointers have to be GC-ed
at least that's my understanding
benabik I'd think at least _most_ of them would be.
lucian yes, indeed
benabik Non GC'd memory allocation ideally is reserved for NCI. 01:48
lucian i vote for benabik negatively indexed (potentially virtual) pointers
soh_cah_toa me too
lucian s/pointers/headers/
01:49 daniel-s joined
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
so the headers probably *have* to be optional 01:50
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.
lucian cotto: slices. basically memory views that "act" like arrays, but aren't necessarily
sort of like a language-level mmap
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
soh_cah_toa go actually does a lot of things right, except it's weird syntax ;) 01:53
it wouldn't be a bad language to model after. it's compiler, that is
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
lucian simple things, like optional ; and optional ( ) around if test expressions
for me, they help readability
benabik enjoys bikeshedding over language design. 01:56
lucian benabik: it's great, isn't it?
we've debated actually important things too, though
soh_cah_toa indeed
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
if it wants, it can generate m0 bytecode directly, after flattening the AST 01:58
soh_cah_toa ok
does anything sit on top of mole? something -> mole -> ... like pir? pasm?
i'm trying to figure out how "high" it's reach goes
benabik soh_cah_toa: I think "everything currently called Parrot" goes on top of Mole. 01:59
M0le
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
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
and HLLs could generate M0, and use utilities/composed ops/functions/types written in Mole 02:02
of course, i could very well be very wrong
soh_cah_toa i don't think so 02:03
i don't think hll's will see a difference
lucian well, i'd very much like to not generate PIR anymore
soh_cah_toa i'm pretty sure dukeleto mentioned that in his talk
lucian but if there's PIR->M0, sure, HLLs could keep using it
benabik lucian: I also want to kill PIR, but would want to replace it with PASM/direct PBC gen. 02:04
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?
soh_cah_toa yeah, that's what i thought
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.
soh_cah_toa from hll's perspective, yes
benabik M0 is designed to move most things written in C inside the VM instead of outside.
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?
bacek_at_work ~~
lucian i don't really know about the plans for pbc. but i'd expect translation pbc->m0 to be better than interpretation
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
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
I think the stack is HLL -> PBC -> Ops -> M0
lucian benabik: hmm. as a HLL writer, i'd rather have M0 + custom functions 02:10
soh_cah_toa hmm...not sure about that
lucian i don't see the advantage of yet another assembly language with ops, over just some functions
my problem with PIR is that it's gnarly, not that it's too small
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
lucian soh_cah_toa: yes, and HLL writers can decide this themselves 02:11
PIR would be such "yet another assembly", and necessary for backwards compat.
so people could use it, or a "use strict" version of PIR
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.
lucian i don't really know
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
but in the future, yes
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
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
lucian exactly. an assembly target should be as low and small as possible/makes sense
M0 looks just like that to me
benabik This comes back to me wanting to resurrect PASM.
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
but M0 working is important first, dynops seems like a non-issue atm to me
soh_cah_toa yes
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
soh_cah_toa it is 02:16
lucian right, then i'd use 6model, with whatever M0 API that has
compilers don't care about verbose assembly
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
PBC ops may be JITted to M0 (which may then be JITted to real machine.)
lucian benabik: i dislike that double JIT-ing 02:18
i don't see the advantage in it
benabik Having the extra level there is useful to isolate HLL devs from system level M0 changes.
lucian an API can do that just as well, i would think
they way i've heard, parrot would become an M0 interpreter + jit + gc 02:19
all that written in C
just like the JVM, and so many others
02:20 JimmyZ left
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
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
(As opposed to Parrot-as-a-dev-environment)
lucian and since PIR needs to be supported for legacy reasons, HLLs can keep using it 02:23
but i'd really much prefer M0 to PIR or PASM
benabik Ah! 02:27
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
M0 is designed to do things like directly allocate memory and other things that might make the VM crash.
PBC is the indirection layer that has things like exceptions. 02:29
And bars HLL devs from shooting themselves in the foot unless they try. 02:30
(Trying = writing new opcodes)
lucian benabik: hmm. perhaps
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.
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
i still think M0 may be enough
atrodo I'm not a fan of the idea that m0 can cause a segfault, especially if m0 is the bytecode 02:32
if m0 is just a runcore, i'm alright with that idea
lucian atrodo: that is a good point
atrodo plus, there's really no good reason to allow that, the cost doesn't appear to be that high 02:33
but then again, i'm completely out of the m0 loop at this point
lucian atrodo: benabik++'s argument was that unsafe pointer arithmetic may be useful
benabik I think M0 has opcodes for memory allocation.
cotto ~~ 02:34
yup
benabik Anything that can do memory alloc and free can segfault.
cotto time for some serious backscrolling
yup
atrodo i disagree
benabik cotto: We're bikeshedding/arguing over "Parrot on top of M0" and "Parrot is M0"
cotto free 299395
lucian benabik: really?
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.
Or at least "undefined behavior".
cotto they guy with the paintbrush has the final say
or spraypaint
atrodo or paintgun
lucian benabik: right
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
benabik: ideally, everything except NCI would use the GC
cotto lucian, quite. PIR will map to M0, so either is fine
benabik cotto: Is the mid-to-long term goal eliminating PBC in favor of m0b? 02:37
That's my real question, I suppose.
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
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
atrodo there will be absolutely no way to secure parrot at all
lucian that's what other VMs do for their FFIs
or long-lived, very large objects
atrodo although, not like we can secure parrot as it is
cotto atrodo, part of the charm of M0 is that we can analyze it.
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?
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.
benabik M0 : Parrot :: NQP : Rakudo is really my thought. But experience will tell us if level of indirect needs to survive past "legacy use".
lucian atrodo: not if the manipulations are bounds checked
rather, not if you have arrays, but not free pointers
cotto It's vital that we make PIR->M0 possible for backwards compatibility. 02:42
(from backscrolling)
02:43 rurban_ joined
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
lucian atrodo: oh, as a security issue?
atrodo lucian: yes 02:44
cotto hio bacek_at_work
lucian atrodo: well, then maybe sandboxed M0 should only have arrays
atrodo you're exposing the underlying system to the sandbox
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.
lucian cotto: is there a good reason M0 should have pointers?
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, rurban left
atrodo lucian: see my lorito prototype, you have pointers into pmcs, but at no point do you have real pointers 02:46
02:46 rurban_ is now known as rurban
lucian cotto: the rest could probably use references, rather than pointers 02:46
atrodo which is really a pmc and an index
lucian atrodo: right. i'm with you that m0 should be cleaner&safer; others raised expresiveness/performance concerns i can't comment intelligently on
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?
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 :)
atrodo cotto: i overused the pmc name. it's really an allocated blob
with just enough magic to allow you to create pmcs on top of it 02:48
cotto lucian, it feels funny talking about one-word "headers", but it's growing on me. 02:49
lucian cotto: presumably there could be other such headers 02:50
atrodo lucian: what magic is this?
lucian in the end, arrays + references should serve all needs i think
atrodo: in here gist.github.com/1048210, look at the strings
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
cotto: references would be C pointers, but with no arithmetic 02:52
cotto: in the presence of a moving GC, they might have to be not-quite-pointers
cotto copying/compacting gc makes life much more interesting
lucian yes. PyPy's solution is interesting, i guess 02:53
atrodo cotto: what about symbols? has that possibility been eliminated from m0?
benabik copying GC is "more interesting" but also more powerful, AFAICT.
cotto benabik, yes
atrodo, I think they're too magical for M0
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
atrodo: symbols in what sense?
benabik: and necessary for reasonable performance
atrodo lucian: lisp symbols. immutable, only 1 ever exist string 02:55
lucian atrodo: right. it is a nice concept, i agree
atrodo lucian: makes string compares trivial and fast, but makes them unusable for strings
lucian would all functions/methods be referenced by symbols?
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
atrodo which is okay to me, since using an immutable string type register isn't real perfermant anyways
lucian the implementation can choose to ignore the intern command/op/whatever
cotto dukeleto, what's the difference?
atrodo lucian: I believe that it's the same concept
lucian atrodo: yes, but less "magic"
cotto @lucian, not dukeleto 02:57
d'oh
atrodo lucian: how so?
lucian atrodo: they still look like strings, and are stored as such
the interpreter can choose to intern them if it thinks it's a good idea
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
symbols as a broad concept also afford clarity, which is a dubious advantage in m0's case
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?
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
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
bubaflub ~
lucian atrodo: but it's not necessarily a bad idea to intern them, especially if they're literals
literals can be even interned at compile-time
atrodo lucian: exactly 03:02
for key lookups and internal use, intern symbols are the way to go. the strings exposed by HLLs should not be intern
lucian maybe 03:04
is there a good reason not to intern them?
perhaps interning is too vague a term 03:05
atrodo Performance, especially with a lot of string manipulation
lucian what i mean is creating new strings only when they haven't been created already
03:05 JimmyZ joined
lucian so that the same string created twice is (very likely to be) the same object 03:05
atrodo: uh, maybe. the sun jvm disagrees 03:06
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:07
lucian atrodo: right, because creating and destroying lots of strings is wasteful. but not because of interning 03:08
in fact, it turns out that interning always beats creating always, overall
at least on the JVM
atrodo lucian: link?
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
atrodo: uh, not handy
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
i should find that article
atrodo lucian: we're probably not that far apart on thinking
benabik still wants to implement Ropes.
lucian benabik: that is very cool, indeed
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
atrodo still wants more time to actually hack on things
lucian is paraphrasing what he read
cotto benabik, I can credit you for a lot of things
benabik cotto: Yes, thank you. :-/
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.
lucian atrodo: searching for that article, apparently different jvms have different behaviour on this
benabik It's like solving special relativity.
lucian atrodo: sometimes wildly different. some intern into a permanent GC arena, some intern forever (never release the string), some intern very smartly 03:13
cotto a lot of innovation happens in jvm implementations 03:14
lucian atrodo: the spec is very lenient apparently download.oracle.com/javase/1.4.2/do...l#intern() 03:15
cotto: yes, they're cool. best VMs around
atrodo lucian: interesting
lucian atrodo: although iirc, all java compilers intern all string literals, always 03:16
atrodo cotto: gist.github.com/1062861 # The end of my non-ipfy work from this past week 03:19
Commits to follow here soon
cotto atrodo, translating pir to your Lorito prototype? 03:20
or pasm rather
atrodo cotto: Yea, I started the project some time ago
lucian as to writing a mole compiler, which was where this started ... :)
atrodo: that sounds very useful
atrodo cotto: actually, the output from pbc_dump to alorito lasm
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
cotto who said anything about C?
There are may ways to write a compiler. 03:22
*many
lucian sure, but which would be acceptable for parrot besides C?
dalek rrot/opsc_lasm: 5f03cc5 | (Jon Gentle)++ | prototype_pbc2lasm.pl:
Add $ to the register
 03:23
rrot/opsc_lasm: f4961a2 | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
Improve the coverage of outputted lasm
rrot/opsc_lasm: 4cfe18c | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
Make the register allocator in lasm.nqp dealloc all reigsters
rrot/opsc_lasm: 175b29e | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
Add the ~(not) pirop
rrot/opsc_lasm: ff94e27 | (Jon Gentle)++ | compilers/opsc/lasm.nqp:
Fix the if pirop output
lucian cotto: hmm, are you planning something other than registers for mole?
cotto lucian, what do you mean?
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.
well, 8 bytes each
lucian cotto: right. are they limited?
cotto max of 255 per call frame with the possibility of spilling 03:25
I'm also thinking about how to enable smaller register sets for when <255 are needed
lucian right. so i'd guess that C-like variables + register allocator aren't necessary
cotto for M0, no. for mole, yes 03:26
lucian right, so you're planning non-register variables
cotto not currently 03:27
lucian ok
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
cotto not sure where they'd go
lucian i'm not sure if having both is necessary in mole, if it's C-like
atrodo and it's not quite complete even
03:28 JimmyZ left
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:28
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
lucian cotto: bah, i thought gists had pull requests 03:40
anyway, gist.github.com/1062879
you can check out the diff
03:40 JimmyZ joined
cotto lamesauce. the ".diff" trick doesn't work on gists 03:41
lucian lame...
i didn't change much, just about arrays and strings a little
cotto: perhaps that gist should move to a repo 03:43
repos can also be edited directly on github, i think
cotto yes 03:45
lucian, I'll see if I can promote it
lucian cotto: github.com/lucian1900/mole 03:46
cotto lucian, good sho 03:47
w
lucian the hub gem is nice :)
cotto fork'd 03:48
03:49 Coke_ left
cotto lucian++ 03:49
lucian cotto: you also have commit rights to mine
03:49 Coke joined
cotto ditto 03:49
;)
I'll delete mine to minimize confusion
lucian cotto: so finally github.com/lucian1900/mole/commit/...66ea4ae750
lucian shrugs. either one was fine by me 03:50
cotto: if i were doing mole on my own for fun, i might use code.google.com/p/pycparser/ 03:56
cotto actually, I should have my own for as a canonical-ish version
lucian it uses the PLY parsing framework
but that might be entirely useless for parrot
cotto the part I relish least is dealing with flex and yacc
lucian another option might be hijacking clang, but that might be even worse
there's also sparse, which is a C-subset compiler 03:57
benabik flex and bison
lucian and of course the classical tools, yes
cotto benabik, yes, those
lucian cotto: if not C, what else could it be?
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.
lucian cotto: ideally such work will be rare afterwards :)
lucian also dislikes C
benabik C++
cotto benabik, um...
I dislike++ that. 03:59
lucian benabik: that's like burning the house to dry it :)
benabik I meant that the way aloha interpreted it. :-D
Although I also like C++
Although I wouldn't say it's appropriate for this.
cotto ah. (C)++ 04:00
though that might be interpreted as liking copyright
lucian Go uses bison i think, too
i think some simplifications of C syntax that Go uses might be nice to borrow 04:01
cotto That Go article gets major cred for mentioning Perl 6 grammars. 04:18
seems to be a true language geek 04:21
This seems to be one of the few long articles that's worth reading to its conclusion. 04:22
lucian cotto: indeed, it's quite thorough 04:23
if go was slightly more mature&popular, i'd prefer just using that as M1 :) 04:24
cotto no kidding about thoroughness
it makes me want to run the final mole spec by him when we have something final-ish 04:25
lucian :)
it makes me want to just hijack the Go parser, i guess 04:26
it's C afaik
hmm, the variable declaration doesn't fit
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:28
lucian cotto: what in particular? can't find it 04:32
cotto lucian, second half of point 9 in the wishlist 04:34
not a direct quote 04:35
lucian cotto: ah
yeah, i've also had that need occasionally. i also use break/continue a lot
cotto me too. It'd be nice. 04:36
lucian in C, a simple goto is enough, but perhaps too general
benabik Which article is this?
cotto benabik, www.syntax-k.de/projekte/go-review 04:37
benabik oh wow, that's long. 04:38
I will read tomorrow.
cotto yeah
lucian cotto: golang.org/doc/go_faq.html#no_pointer_arithmetic 04:42
apparently they agree with me :)
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:47
anyway, it's late 04:48
nice talking to you, bye
04:49 lucian left 05:25 fperrad joined, daniel-s left 05:35 Drossel joined 05:37 Kulag left 05:39 Kulag joined 05:42 Drossel left 05:50 Kulag left 05:52 Kulag joined
moritz good morning 06:01
msg dukeleto does the error still persist? according to validator.w3.org/check?uri=http%3A%...mp;group=0 the markup is valid... 06:02
aloha OK. I'll deliver the message.
06:07 theory left, fperrad left 06:08 theory joined, fperrad joined 06:10 soh_cah_toa left 06:13 rohit_nsit08 joined 06:37 preflex left
dalek kudo/nom: c4d4a74 | moritz++ | t/spectest.data:
run three more spectest files, remove one that never passed
 06:38
kudo/nom: 0562684 | jonathan++ | src/core/IO.pm:
Get print and say to use $*OUT; add note which uses $*ERR.
 06:39
kudo/nom: d586e07 | jonathan++ | src/core/Mu.pm:
Add warning to use of uninitialized value in string context, and make uninitialized value in numeric context warn and give back 0.
kudo/nom: 34c2983 | jonathan++ | t/spectest.data:
We now pass S03-operators/equality.t.
06:40 preflex joined
dalek kudo/nom: 23f5fbd | jonathan++ | LHF.markdown:
Add a LHF.
 06:46
kudo/nom: 157e4f8 | jonathan++ | LHF.markdown:
Another (hopefully) LHF.
 06:49
kudo/nom: abd6769 | moritz++ | t/spectest.data:
we pass a (highly fudged) binding-attributes.t
 06:56
kudo/nom: 8b36d09 | moritz++ | / (3 files):
infix == for Complex, wins us back any-complex.t. jnthn++
 06:59
kudo/nom: 78388ab | moritz++ | t/spectest.data:
run constant.t
 07:05
kudo/nom: add464b | jonathan++ | src/Perl6/Metamodel/BOOTSTRAP.pm:
Fix Bool up a bit more; now Bool::True, Bool::False, True and False can all be mentioned.
 07:18
kudo/nom: 2ddc07d | jonathan++ | t/spectest.data:
Now we *really* pass parsing-bool.t. :-)
07:23 rohit_nsit08 left
dalek kudo/nom: b2b27f6 | jonathan++ | NOMMAP.markdown:
Few nommap updates.
 07:23
07:26 mj41 joined 07:39 Kulag left 07:40 Kulag joined 07:45 mib_y8rzjr joined 07:49 daniel-s joined
dalek kudo/nom: edef5dc | moritz++ | src/core/Num.pm:
add pi and e constants
 07:59
kudo/nom: 11972a9 | moritz++ | t/spectest.data:
3 more passing test files
 08:00
kudo/nom: 179d411 | moritz++ | / (2 files):
implement Int.Rat, pass unpolar.t
kudo/nom: dff16a7 | jonathan++ | / (3 files):
Add Whatever.pm with an ACCEPTS that accepts everything, plus its own new.
 08:10
kudo/nom: 362947a | jonathan++ | src/core/Mu.pm:
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:26 fperrad left 08:33 kurahaupo left 08:36 contingencyplan joined
dalek kudo/nom: 3cae1b4 | moritz++ | src/core/Num.pm:
constants should be "my", jnthn++
 08:42
kudo/nom: c14785b | moritz++ | / (2 files):
make log.t pass again
 08:43
rrot: 34af646 | chromatic++ | src/pmc/stringbuilder.pmc:
[PMC] Avoided pushing empty strings in SB.

This early exit improves the vpm.pir benchmark by 6.7%.		 08:48
rrot: f64aebc | chromatic++ | src/pmc/stringbuilder.pmc:
[PMC] Avoided encoding comparisons in push_string.

When there's no need to look for a compatible encoding, don't look. This improves vpm.pir by 0.58%.
rrot: 0d06396 | chromatic++ | src/pmc/stringbuilder.pmc:
[PMC] Optimized StringBuilder's push_string VTABLE.

There's plenty of STRING encapsulation violation here, so avoiding a function call improves the SB-heavy benchmark of vpm.pir by 2.9%.
rrot: 41d54b9 | chromatic++ | src/string/api.c:
[str] Fixed a typo.
rrot: 318f52c | chromatic++ | src/gc/system.c:
[GC] Added a PMC/STRING flag check to mem tracer.

This should be safe (though feel free to revert if it causes odd GC behavior). In a GC-light vpm.pir benchmark, this improves performance by 0.946%. Depth of C stack as well as memory layout will vary these results.
rrot: ce6505d | chromatic++ | src/string/api.c:
[str] Optimized Parrot_str_join given empty joiner.

This improves the vpm.pir benchmark by a whopping further 7.8%.
08:55 rohit_nsit08 joined
dalek kudo/nom: a2aea3d | moritz++ | t/spectest.data:
pass num.t
 08:57
ttbot Parrot ce6505dc MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/27880 09:01
09:13 rohit_nsit08 left
dalek kudo/nom: 1f421d3 | moritz++ | t/spectest.data:
more passing tests
 09:14
09:20 ttbot left 09:21 ttbot joined
dalek kudo/podparser: e44bddd | tadzik++ | src/Perl6/SymbolTable.pm:
[SymbolTable] Allow named parameters to type_new in add_constant()
 09:26
kudo/podparser: 836c553 | tadzik++ | src/Perl6/ (2 files):
Install $POD into the $*UNIT scope as an List (empty so far)
09:27 woosley left
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:31
tadzik moritz: I'd look into that, thanks 09:32
moritz oh, wrong channel
tadzik cover blown! 09:34
dalek kudo/nom: a0d429e | jonathan++ | src/ (3 files):
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
09:46 ambs joined 09:59 Drossel joined 10:01 Kulag left 10:04 Drossel left
dalek kudo/nom: 478a82d | jonathan++ | t/spectest.data:
Two more passing test files.
 10:08
kudo/podparser: 7bec705 | tadzik++ | / (25 files):
Merge branch 'nom' into podparser
 10:09
moritz btw the segfault in rindex.t happens in Parrot_str_concat 10:12
callers: Parrot_scalar_concatenate_str, Parrot_concat_p_p_s, runops_fast_core
10:31 contingencyplan left 10:34 mib_y8rzjr left 10:38 mj41 left
dalek kudo/nom: a0c28ce | jonathan++ | src/ (3 files):
First cut of defaults for attributes. Still to do is only to do this to untouched attributes.
 10:42
kudo/nom: abdcbc3 | jonathan++ | src/Perl6/Actions.pm:
Fix attributes refering to others in default value.
10:43 rurban_ joined 10:46 rurban left, rurban_ is now known as rurban
dalek kudo/nom: 91077bf | jonathan++ | src/core/Mu.pm:
Implement $obj.Parent::bar().
 10:59
kudo/nom: 2302959 | jonathan++ | t/spectest.data:
We now fully (unlike master) pass S12-attributes/inheritance.t.
kudo/nom: 4dd86c6 | jonathan++ | NOMMAP.markdown:
Update nommap.
11:02 mj41 joined 11:06 JimmyZ left 11:07 ligne joined 11:11 whiteknight joined
dalek kudo/nom: c3d1dcf | jonathan++ | t/spectest.data:
Run S12-methods/submethods.t.
 11:16
11:36 mj41 left
dalek kudo/podparser: c3c1aba | moritz++ | t/spectest.data:
we pass ord_and_chr.t
 11:47
kudo/podparser: f13f52b | moritz++ | t/spectest.data:
two more passing test files
tadzik moritz: wrong branch? 11:50
11:50 JimmyZ joined
tadzik oh, ww again 11:50
dalek kudo/nom: 1b7e7f3 | moritz++ | t/spectest.data:
we pass ord_and_chr.t
 11:59
kudo/nom: 1f659be | moritz++ | t/spectest.data:
two more passing test files
12:10 kid51 joined 12:14 mj41 joined
dalek kudo/nom: 939629a | moritz++ | t/spectest.data:
5 more passing test files
 12:17
12:23 redicaps joined 13:04 bluescreen_ left, bluescreen left 13:15 bluescreen_ joined, bluescreen joined 13:19 lucian joined 13:24 JimmyZ_ joined
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:27
I have a file here with about 1100 characters written in it, and not a single test 13:28
13:28 JimmyZ left 13:29 JimmyZ_ is now known as JimmyZ
dalek kudo/nom: df1de50 | pmichaud++ | src/core/metaops.pm:
Change the NYI metaops to die instead of fail.
 13:37
13:46 PacoLinux joined
dalek rrot: 48434d7 | ligne++ | src/string/api.c:
fix C++ build failures due to unexpected const-ness

VTABLE_push_string() expects a non-const STRING. c++ says this is Not Allowed. This fixes it.		 14:24
rrot: 5b67022 | cotto++ | src/string/api.c:
Merge pull request #138 from ligne/g++-build-error

fix C++ build failure due to unexpected const-ness
cotto ~~
14:25 jsut_ joined
cotto chromatic++ 14:26
kid51 Hmm, I did not get that build failure that ligne's patch addressed 14:27
14:27 fperrad joined
cotto It looked like an innocent enough fix that I just merged it. 14:30
14:31 mj41 left
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.
cotto kid51, it does break the c++ build for me 14:33
kid51 curious 14:34
cotto yes
ttbot Parrot 5b670225 MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/28172 14:37
14:37 JimmyZ_ joined
cotto lolwut 14:39
not sure what to do about that 14:42
14:42 JimmyZ left, JimmyZ_ is now known as JimmyZ
cotto Ah. looks like something chromatic did and mentioned as suspicious 14:43
dalek rrot: b6ba78b | cotto++ | src/gc/system.c:
Revert "[GC] Added a PMC/STRING flag check to mem tracer."

This reverts commit 318f52c503183a59d4e38e309eb46afba6361d00. This caused failures in the windows build.		 14:45
14:49 lichtkind joined
dalek kudo/nom: 6c013c1 | jonathan++ | src/core/Mu.pm:
Move a statement to avoid an accidental boxing every time around a loop (pmichaud++ for noticing).
 14:49
kudo/nom: 18fe583 | jonathan++ | src/binder/multidispatch.c:
Fix multi-dispatches involving slurpy args.
kid51 That last series of commits (prior to the revert) also generated a build failure on darwin/ppc: 14:51
./parrot-nqp --target=pir --output=compilers/opsc/gen/Ops/Compiler/Grammar.pir compilers/opsc/src/Ops/Compiler/Grammar.pm
make: *** [compilers/opsc/gen/Ops/Compiler/Grammar.pir] Segmentation fault
[parrot] 515 $ git show | head -1
commit 5b670225183fbbcc63ab0aee61635f3ab7e4ba99
cotto kid51, that looks like the windows failure
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 14:54 Coke joined 14:59 whiteknight left 15:00 whiteknight joined
dalek rrot/whiteknight/packfilewrapper: 0b04c1f | Whiteknight++ | t/pmc/packfileview.t:
add a stub test file for PackfileView
 15:03
rrot/whiteknight/packfilewrapper: d69738f | Whiteknight++ | MANIFEST:
Add testfile to MANIFEST
rrot/whiteknight/packfilewrapper: a43d2cc | Whiteknight++ | t/pmc/parrotinterpreter.t:
Add tests to ParrotInterpreter for getting the current PackfileView
rrot/whiteknight/packfilewrapper: 5613f8c | Whiteknight++ | t/pmc/packfileview.t:
Add a few tests for PackfileView
kid51 cotto: at HEAD darwin/ppc completed 'make' once again; now running 'make test' 15:06
AOK on linux/i386 with all-g++ build
cotto kid51, great 15:07
kid51 whiteknight: What is PackfileView?
whiteknight it's a PMC wrapper type for packfile internals 15:08
exposes things to PIR in a clean way, to allow us to deprecate some old garbage, and keep moving towards the removal of IMCC
I want to have that branch in mergable condition before the release. 15:09
kid51 Sounds interesting. 15:10
cotto It's going in a good direction.
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.
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
kid51 ... it's a supported release and ... 15:11
... my first attempt at doing a release
whiteknight ah, okay
it doesn't need to merge before the release, I just want it in that kind of condition
cotto I support merging before the release, but it's more up to the release manager. 15:12
(if it's ready)
kid51 AFAICT, we didn't have a whole lot of new stuff in master since 3.5
Coke (working smolder) I thought smolder was working these days. 15:17
(also, I just gave it a therapeutic restart)
15:17 fperrad left 15:20 fperrad joined
cotto whiteknight, I have a few small fixed to that branch. mind if I push? 15:30
just c89 tax payment and some test cleanup 15:31
15:36 zby_home joined
cotto too late 15:37
dalek rrot/whiteknight/packfilewrapper: 88f9a1a | cotto++ | src/pmc/packfile (2 files):
C89 tax (no variable declarations after the beginning of a block)
rrot/whiteknight/packfilewrapper: 1041355 | cotto++ | t/pmc/packfileview.t:
add some test messages, a shebang and a vim coda
whiteknight okay, I'm doing some codestd stuff now too.
mostly docs in PackfileView
bubaflub morning, #parrot 15:41
whiteknight hello bubaflub
bubaflub hello whiteknight - good work on the packfile stuff. 15:42
whiteknight thanks!
15:43 redicaps left
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:47
OMG Smolder is indeed back! smolder.parrot.org/app/projects/smoke_reports/1 15:50
dalek rrot/whiteknight/packfilewrapper: fc1ccf8 | Whiteknight++ | / (2 files):
+docs and some rearranging for PackfileView
 15:51
whiteknight ...and we're back to checkdepend.t. My old nemesis
cotto whiteknight, you want a hand? 15:58
whiteknight no, I think I have it
I'm building now
cotto good times
dalek rrot/whiteknight/packfilewrapper: da61254 | Whiteknight++ | config/gen/makefiles/root.in:
fix checkdepend.t
 15:59
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
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?
whiteknight most of them should be pretty straightforward 16:02
you're welcome to put your hands on any tests you want to
using the new PMC is a great way to learn it 16:03
cotto exactly
dalek rrot-gmp: 5dcb024 | bubaflub++ | / (6 files):
vtable overrides and tests for add, add_int, add_float
cotto whiteknight++ for the docs 16:04
bubaflub whiteknight: if you've got a moment, i've got a question about Winxed and vtable overrides. 16:05
whiteknight bubaflub: ENOMOMENTS
just kidding. Lots of moments. What do you need?
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
bubaflub: yeah, winxed doesn't always generate all the right opcodes 16:07
bubaflub whiteknight: ok, i'm looking at the generated pir
whiteknight what does it generate for x = y + z, where z is a float or an int?
bubaflub set $I4, $P2 16:08
add $I3, $I4, $I1
box $P1, $I3
whiteknight oi
what you're most interested in is testing the vtable overrides you've written, not testing winxed syntax does what you like
bubaflub right
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
ok, that answers my question. thanks.
oh, also
${ add x, y} will hit the i_add vtables, right?
whiteknight yes 16:10
take a look at src/ops/math.ops to see what each opcode does
bubaflub woot.
whiteknight but 2-arg arithmetic ops should call the i_* 2-arg vtables 16:11
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
kid51 I ask 'cause I know soh_cah_toa has some failures there to fix in his branch 16:16
cotto kid51, it's also necessary to rebuild the makefile since that's what's being tested by check_depends.t 16:17
16:23 lucian left
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:35
whiteknight I would say so, yes 16:36
coverage?
aloha: coverage?
aloha whiteknight: coverage is cv.perl6.cz or tapir2.ro.vutbr.cz/cover/cover-results/
whiteknight I *really* want to deprecate the automatic execution of :init and :load subs 16:41
PackfileView allows us to start doing that 16:42
dalek rrot/whiteknight/packfilewrapper: 93d9a9b | Whiteknight++ | t/pmc/packfileview.t:
Add more tests for packfileview
 16:45
16:46 theory left 17:03 janus joined 17:07 jlaire joined
kid51 Is it considered polite for someone other than a GSOC mentor to commit to a GSOC student's branch? 17:08
17:09 contingencyplan joined
cotto kid51, go for it. Just make sure that either the mentor or the student knows what's going on. 17:09
kid51 cotto: The mentor in question is You! soh_cah_toa is student 17:10
cotto kid51, I figured. Can you nopaste the patch(es)? 17:11
kid51 Within about 10 min
cotto wfm
kid51 This has enabled me to learn about t/src/checkdepends.t 17:12
Need to run make test
nopaste "kid51" at 192.168.1.3 pasted "hbdb branch: Eliminate all but one failure in t/src/checkdepends.t; see smolder.parrot.org/app/projects/rep...ls/16944." (117 lines) at nopaste.snit.ch/57477 17:32
cotto kid51, that has a number of files unrelated to the branch. Let me sync it with master first. 17:40
17:42 mj41 joined
cotto testing now 17:44
kid51, all yours 17:49
dalek rrot/soh-cah-toa/hbdb: 2a8794f | cotto++ | / (236 files):
Merge branch 'master' into soh-cah-toa/hbdb

Conflicts:
  \t.gitignore
  \tconfig/gen/makefiles/root.in
kid51 BTW just had a successful smolder on packfilewrapper branch 17:50
cotto: What git command did you use for that? 17:51
cotto git merge 17:52
and manually fix the conflicts
kid51 git merge master ??
cotto yes
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
dalek rrot/soh-cah-toa/hbdb: 3f13b7f | jkeenan++ | config/gen/makefiles/root.in:
Fix all but one FAIL in t/src/checkdepends.t. Thanks for hints from whiteknight++ and cotto++.
 18:03
kid51 smolder: smolder.parrot.org/app/projects/rep...ails/16948 18:04
afk
18:12 bluescreen_ left, bluescreen left 18:13 bluescreen joined 18:16 fperrad left
dalek TT #1083 closed by NotFound++: Managed cstrings to avoid the need of Parrot_str_free_cstring 18:19
TT #1083: trac.parrot.org/parrot/ticket/1083
18:31 ambs left
dalek kudo/nom: d9d8c49 | moritz++ | src/core/Complex.pm:
fix Complex exponentation
 18:41
kudo/nom: ce2882f | moritz++ | src/core/Real.pm:
add infix mod
kudo/nom: d2a8943 | moritz++ | / (2 files):
sub forms of pop, shift, push
18:43 rurban_ joined 18:46 rurban left, rurban_ is now known as rurban
dalek kudo/nom: 97e5710 | moritz++ | t/spectest.data:
nine more passing test files
 19:01
TT #1085 closed by coke++: TclLibrary.pir and tcl_lib.t update 19:06
TT #1085: trac.parrot.org/parrot/ticket/1085
cotto msg whiteknight I have some random-esque thoughts on profiling at 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.
cotto I'm out until this evening. 19:18
19:41 lucian joined 19:49 kid51 left
dalek kudo/nom: a2b9926 | masak++ | LHF.markdown:
[LHF.markdown] Int.Rat implemented
 19:57
whiteknight cotto: okay, I'll take a look soon 20:01
dalek p: 8557631 | pmichaud++ | src/core/NQPMu.pm:
Add a version of __dump() to NQPMu so that NQP objects can
 20:14
kudo/nom: 59ec8c6 | moritz++ | / (2 files):
infix cmp for Pairs
 20:17
20:24 Eclesia joined
Eclesia hi 20:24
someone know how to list all variables of an object ? 20:25
(in winxed)
dalek kudo/nom: 535395f | moritz++ | t/spectest.data:
run arith.t
 20:28
Eclesia whiteknight hi 20:31
dalek kudo/nom: 8f1d810 | moritz++ | t/spectest.data:
two more passing test files
 20:33
20:35 bluescreen left, soh_cah_toa joined 20:37 varta joined 20:39 mj41 left
dalek kudo/nom: 56a1e10 | moritz++ | / (2 files):
Complex.sqrt, tests
 20:39
20:39 varta left 20:46 bluescreen joined
Eclesia NotFound you are here ? 20:46
NotFound Eclesia: yes
Eclesia NotFound: cool, what is the typeof equivalent in winxed ? 20:47
dalek kudo/nom: 3e5c741 | pmichaud++ | src/core/ (2 files):
Add List.sort and Any.sort.
NotFound Eclesia: the builtin typeof 20:48
Eclesia NotFound: what I want to do, is make something like : if (obj instanceof something){ ....
NotFound Eclesia: then instanceof 20:49
Eclesia NotFound: and how can I have a list of all variables of an object ?
NotFound Eclesia: What do you mean? The attributes? 20:50
20:50 mj41 joined
Eclesia NotFound: I'm searching some kind of reflexion, get the attributes with there name and value 20:50
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:52
Eclesia NotFound: you have an example ? 20:53
20:53 Coke left 20:54 Coke joined
NotFound Eclesia: no 20:54
dalek kudo/nom: ca93c8a | pmichaud++ | src/core/Any.pm:
Fix Any.join -- default separator should be '' and not ' '. pmichaud-- S04-statements/for-scope.t now passes. moritz++
 20:55
kudo/nom: 2cac886 | pmichaud++ | t/spectest.data:
Add S04-statements/for-scope.t to spectest.data.
 20:56
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:00
Eclesia NotFound: thanks, just one thing missing, how to get the value of attribute 'attr' 21:03
NotFound Eclesia: obj.attr 21:04
Eclesia ho... just like that ... 21:05
Eclesia is still too much used to java
NotFound Mmmm.... is you have the name in a variable is different...
Eclesia NotFound: that's the case here, since I'm in the attributes loop. so I just have the name 21:06
(like in your exemple)
NotFound You can use the builtin getattribute 21:08
But note the vtable functions that handle attributes can be overriden, so there is no guarantee that the results are consistent with inspect. 21:11
21:37 Eclesia left 21:39 PerlJam left, tadzik left, pmichaud left 21:40 Util left 21:42 Psyche^ joined
dalek sella: ed0a8f0 | Whiteknight++ | src/unstable/template/ (2 files):
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
p: de23ea5 | pmichaud++ | src/core/NQPMu.pm:
Make NQPMu.__dump aware of native types in attributes.
21:47 Patterner left, Psyche^ is now known as Patterner 22:11 tadzik joined 22:12 Util joined
dalek rrot: 62c761d | chromatic++ | src/runcore/cores.c:
[rc] Enabled PC tracking in fast core.
 22:13
rrot: 273c003 | chromatic++ | frontend/parrot/main.c:
[rc] Made fast runcore the default.

This should be safe, given the previous commit of dabaf8c. This gives the op dispatch benchmark mops_intval.pasm a 27.56% performance improvement. Other programs will show less benefit, but faster op dispatch is still a good thing.
rrot: 89cf287 | chromatic++ | / (2 files):
[OO] Optimized Parrot_pmc_get_type_str() slightly.

Because the classname -> integer mapper is an internal implementation detail which should never leak out of the OO subsystem, it's okay to break the VTABLE encapsulation in this case. This provides a 2.33% performance improvement on the OO-heavy stress1.pasm benchmark and should also help any other code which creates objects based on string class names.
Arguably Parrot should resolve string literals to class objects at compilation or optimization time, but that's a larger change.
As this commit includes a Makefile dependency addition, reconfigure recommended, but not required.
22:15 PerlJam joined 22:16 pmichaud joined
bubaflub chromatic++ - glad to see him back in action 22:17
22:31 lucian left 22:49 mj41 left
dalek rrot-gmp: 588f5bd | bubaflub++ | / (18 files):
finish code for vtable overrides, tests for i_add*, i_mul*, mul_*, sub_*
 22:51
whiteknight chromatic++ indeed 22:54
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
whiteknight: or should i just use "time parrot-nqp t/harness"
whiteknight timing? no, I don't have anything like that builtin
bubaflub whiteknight: no prob.
whiteknight you can use the winxed builtin floattime in the harness
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
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
I can easily print a little (14.3s) timestamp
it's similarly easy to output a quick timestamp in the summary from the harness 23:00
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#16963), fulltest) at 3_5_0-67-g89cf287 23:19
Ubuntu 11.04 i386 (g++ --optimize)
whiteknight: still getting the occaisional Segmentation fault in t/pmc/threads.t (passes on re-run) 23:20
whiteknight mikehh: of course. The test is broken. 23:33

Powered by Cro and the Raku® Programming Language.

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

Thank you!