Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC
Set by moderator on 17 August 2011.
tcurtis whiteknight: sure. What timeframes would be most convenient for you? 00:02
whiteknight how long do you think such a walkthrough would take?
I have a decent idea about how it all works, I'm mostly trying to figure out what needs to be done on both the input and output sides 00:06
00:06 theory joined
tcurtis Hmm... I am unusued to estimation of how long explaining things takes, but I think I could probably explain its current state in at most 30 minutes. 00:10
whiteknight okay. Have time tonight? 00:11
I'm trying the build now. Looks like it's missing a file MergeRedundantTransitions.winxed 00:13
LALR/Generator/MergeRedundantTransitions.winxed
tcurtis Ah, yes. I had added that temporarily and forgotten to remove it when it became unnecessary. 00:14
I'll fix and push that momentarily. 00:15
dalek lrskate: 22ecc4d | tcurtis++ | setup.winxed:
Fix no longer necessary file being included in the build.
 00:17
tcurtis As far as having time tonight, yes, though preferably not immediately. Would 8:30PM CDT(approximately one hour and ten minutes from now) work for you? 00:18
whiteknight yeah, sounds good to me 00:20
I finally got it building and testing, which is good 00:21
I did a lot of half-assed hacking on rosella, which prevented me from building and installing it locally until I fixed it
dalek kudo/nom: b0d942e | Coke++ | t/spectest.data:
track failure mode
 00:33
benabik o/ 00:39
whiteknight hello benabik 00:40
benabik whiteknight: What's up? 00:41
whiteknight benabik: not too much. you?
benabik whiteknight: Just spent an hour or so moving mulch. 00:42
whiteknight fun tims 00:43
times
benabik Also trying to get these random pile of thoughts in my head about PACT into some kind of readable shape. 00:44
whiteknight benabik: I am looking forward to what else you have to say about it. I started drafting a blog post of my own, but also don't have all my ideas solidified 00:45
benabik whiteknight: Do we have a PDD or other doc describing packfiles? 00:48
whiteknight benabik: maybe, but I'm sure it's no good
benabik whiteknight: Found it
whiteknight where? 00:49
benabik docs/parrotbyte.pod
I'll also consult the Packfile* PMCs.
whiteknight These things all need more documentation, but at the same time I don't really like the design of too much of this stuff and most of it is going to change 00:51
well, it's not just that *I* don't like the design. Enough people don't
benabik I note that the Packfile PMC says it's a parser for .pbc files, but I don't see a way to load a packfile into one. 00:52
Although I guess I could pass the value from PackfileView.get_pointer into Packfile.set_pointer. 00:59
whiteknight yeah 01:00
benabik Or load the pbc into a string and pass it to Packfile.unpack.
Interesting.
whiteknight we could add a method to Packfile like "set_view" or something
it's trivial to do. You could do it yourself if you were feeling adventurous
benabik I'm curious about disassembling pbc files… pbc_disassemble doesn't really give useful output. 01:01
whiteknight no, it does not
the problem is that PIR compilation is destructive. We can't get back anything like the original after we compile it 01:02
PIR uses :immediate subs to run during compilation to create constants. We don't have a way besides with :immediate subs to put arbitrary constants in the constants table
benabik Well, I want to change that. :-D
whiteknight so we can't disassemble a PBC file which contains complex constants
right. So what we need is a syntax to assemble complex constants, then we can disassemble into that syntax 01:03
benabik At the very least, I'm trying to consider what the lowest level of PACT should be. 01:06
Under POST is PIR… But I'm wondering if the bytecode route would benefit from something between POST and PBC. 01:07
Something that is extremely close to the structure of the packfile.
whiteknight PAST is the abstract syntax layer, POST is the layer tailored to the output format
so if POST isn't what PBC needs, then we need something better than POST, or we need to modify POST
but I don't think we need to add another layer 01:08
benabik Well, PACT is about modifying things. :-D
whiteknight true, but I don't want to just add crap for the sake of adding crap
benabik If there's a OO layer there, we can disassemble to it, do introspection, etc etc. 01:11
I want each transformation to be as simple as possible.
whiteknight we do need PAST, or something like PAST to represent the syntax of the input
benabik Right.
whiteknight and we probably do want something tree-like to represent the structure of the output 01:12
it doesn't have to be POST. We can create a new tree interface and give it a fun new acronym
benabik I'm pondering: PAST -> POST -> flattened POST -> output...
POST currently does things like bury subs inside subs. 01:13
whiteknight now, the packfile PMCs are the end goal, but they aren't necessarily the best API to use. We could add an abstraction layer API for them
benabik: can we change POST to not do that?
or do we sincerely need a flattening step? 01:14
benabik There are several post-POST steps we could do. Fun transformations like SSA form or simple things like register allocation. 01:15
(I'm not convinced that PAST::Compiler is the best place to do register allocation.)
whiteknight so what does POST get us, if not these things like register allocation, instruction transformation, and logical ordering of executable blocks? 01:16
benabik Currently, POST is mostly a tree-structured form of PIR. 01:17
PAST::Compiler does the register allocation, instruction bits, etc etc. POST::Compiler is largely serialization. 01:18
whiteknight isn't PAST a tree-structured form of PIR? 01:20
I thought I understood the differences here a little better, but from what you're saying things aren't where I would expect them to be
benabik No, it's a higher level thing. It's a semantic tree.
There's a PAST tree for "a loop"
POST trees contain labels, conditionals, and jumps. 01:21
dalek rrot: c52abd8 | jkeenan++ | config/init/hints/darwin.pm:
Remove import of File::Which, which is no longer needed.
 01:22
whiteknight gotcha. Okay. So the abstraction layer is not quite where I was hoping it would be 01:23
benabik POST trees contain a _lot_ of strings that are intended to be concatenated into PIR in the right order.
I'm also just pondering what's needed. 01:26
01:30 soh_cah_toa joined
benabik Here we go… www.cs.uaf.edu/~cs631/notes/node5.html 01:30
whiteknight the point about nested subs really bothers me 01:31
benabik 6 phases: Lexing, Syntax, Semantics, Intermediate Code, Optimization, Code Gen.
whiteknight I wonder why it does that
01:31 rfw joined
whiteknight lexing and syntax create the PAST tree. Semantics and intermediate code create POST. then we optimize POST and use it to generate output code 01:31
benabik Syntax generates parse tree. 01:32
Semantic is PAST.
Intermediate Code is POST.
I'm thinking about leaving POST in a tree-like state and then as "optimization" steps doing things like dealing with register allocation, temporary values, etc etc. 01:33
whiteknight register allocation definitely should be happening in POST or later 01:34
01:34 bubaflub joined
benabik My thought is that POST would be a tree containing opcodes, then we'd flatten it down over a couple of phases into a just a list of subs containing a list of ops. And then a code gen phase outputs PIR/bytecode. 01:40
This may not be faster than currently, but I hope is more amenable to alteration and optimization.
whiteknight I'm going to need to think about it more. There are a lot of things that have to go into this 01:42
benabik Yes.
whiteknight closures really are the pain in the ass, I think
benabik … Yes.
And no.
soh_cah_toa whiteknight: you saw my message? 01:45
whiteknight soh_cah_toa: recent message? I don't think so 01:46
soh_cah_toa from aloha. sent it last night
whiteknight Oh, I might have gotten it earlier, but I don't remember what
I wish aloha kept records until you deleted them 01:47
soh_cah_toa well, whatever. i was just wondering if you looked at the spec yet? it's mostly designed for a c compiler and it needs to be parrot-ized
whiteknight oh yes, the spec. I did look at it 01:48
a lot of the parrotization will fall out when we start implementing
soh_cah_toa that's another thing. i'm not sure where to begin b/c all the PAST::* and HLL-whatever classes are so vast and unfamiliar to me 01:49
01:49 rfwalrus joined
whiteknight don't worry about PAST. PAST might be up in the air at this point 01:50
benabik PAST is likely PAST for the near future.
whiteknight where we need to start is in the packfile subsystem. src/packfile/*
soh_cah_toa ok
whiteknight We add the new segment to the packfile machinery, including the necessary API for writing and reading it
then, we add support to IMCC to write to it
then we add tools that read from it 01:51
rewriting things in src/sub.c and src/debug.c to use it instead of the old debug segment
then, remove the old debug segment and do a little dance
then, delete IMCC
soh_cah_toa ok good 01:52
benabik beer++
soh_cah_toa so i guess that'd require rewriting the PackfileDebugSegment PMC?
or whatever it's called 01:53
whiteknight we'll make a new segment, and a new wrapper PMC for it
that way the transition from one to the other will be smoother
soh_cah_toa ah, ok
benabik +1
+10 if I'm allowed. :-D
soh_cah_toa :)
01:54 rfw joined
whiteknight msg tcurtis I'm heading to bed now. We'll talk tomorrow. I'll be online most of the day, just come get me when you have time 01:54
aloha OK. I'll deliver the message.
whiteknight and with that, I'm out for the night
benabik 'night!
soh_cah_toa alright, see ya
whiteknight goodnight
tcurtis msg whiteknight Sorry about not contacting you tonight. I didn't wish to interrupt your discussion about POST. 01:56
aloha OK. I'll deliver the message.
tcurtis ~~
01:59 rfwalrus joined 02:00 bubaflub joined
benabik Okay, a cold beer is nice after hard work, but it makes writing a coherent blog post more difficult. 02:03
(Mostly because I'm more relaxed and distractible.) 02:04
02:16 rfw joined
dalek nxed: 585ddb8 | NotFound++ | winxedst1.winxed:
optimize integer == 0 and != 0 in conditions
 02:23
allison how "optional" is libffi? 02:31
benabik allison: It makes NCI easier. 02:32
allison benabik: this is more of a packaging question
that is, for the Debian/Ubuntu packages we can require it, and then it's always built with it 02:33
otherwise, we need a flag to make sure it's never built with it
because currently, it's built with it on some architectures (when libffi just happens to be installed), and then breaks
benabik allison: Parrot can be compiled without it, but that makes NCI harder. It's a tradeoff. 02:34
I'm not sure which is preferable.
allison harder doesn't really matter here
faster or smaller does
NotFound With it is preferable. a lot.
With it, nci can be used with pure pir modules. Without it, you need to require a C compiler and provide the wrappers. 02:36
And 'pure pir' in that sense includes nqp and winxed. 02:37
allison does libffi get rid of the large stack of precompiled thunks for various signatures? 02:39
NotFound It does not need it, but I'm not sure if the build process avoids its compiling and linking. 02:40
plobsing allison: we have a flag to force-dissable libffi usage in Configure.pl: --without-libffi 02:43
likewise we have flags to dissable the building of the large library of builtin thunks: --without-core-nci-thunks and --without-extra-nci-thunks 02:44
benabik plobsing: And with libffi and without thunks, NCI works correctly, ne? 02:45
plobsing benabik: yes, it should
benabik woot
plobsing but not everyone has libffi 02:46
and libffi is much less efficient than the thunks
allison plobsing: in packaging we get to decide if everyone has libffi or not
plobsing: so, the question is which flags to use
NotFound For debian and ubuntu is just a matter of apt-get install libffi
allison plobsing: and, the hard thing is that we have to decide once for everyone 02:47
plobsing I would advise to force the usage of libffi in the case of packaging, since it maximizes utility
NotFound Me too
allison and then --without the nci thunks?
plobsing if you want to cut down on some code size and a couple hundred gcables at startup, then sure
they don't add value to a system with libffi 02:48
allison NotFound: it's not even that hard (apt-get install), it's just an automatic dependency in the packaging
NotFound Yes, I was fooling myself into a developer point of view, not final user. 02:49
plobsing like I alluded to earlier, the thunks are more efficient. but if you're looking for efficiency in your VM<->C barrier, you are doing it wrong
allison plobsing: well, we are doing it wrong, but we'll fix it :)
plobsing: how much less efficient? 02:50
plobsing the thunks require heap allocation where the thunks could do it on the stack
allison which requires heap allocation?
libffi?
plobsing yes. sorry, I'm communicating poorly for some reason. 02:51
allison heap allocation is generally preferable for a stackless VM
NotFound I think that the eficiency of something that just doesn't work is debatable ;)
plobsing allison: heap allocation is not preferable when calling into a C function
we want to stay off the stack while we are staying in the VM. as soon as we are on our way out (or as we are on our way in), all bets are off. 02:52
allison plobsing: it does require remunging to the stack, yes
plobsing the code path to make even a simple PCC->FFI call is rather complicated. the thunks are rather straightforward. 02:53
we build up the call arguments for a call to get_params. then we build up a call for the actual function. then we build up a call for set_returns. 02:54
these are all variable arity calls 02:55
allison is Rakudo faster or slower with libffi? 03:00
plobsing as a result, I count 9 separate heap allocations that occur to call a single NCI function through libffi (src/nci/libffi.c:call_ffi_thunk)
vanilla Rakudo doesn't make ffi calls. it stays inside the VM. 03:01
allison that sounds like a lot of unfortunate overhead, but then it may have very little effect
plobsing I think we have a libgmp benchmark somewhere that would be a more realistic guage of how this affects NCI users 03:02
who was the gsoc student working on gmp bindings again?
benabik bubaflub?
allison something in Rakudo is triggering libffi (I know from the failures it's causing), but it could be the VM itself
plobsing what?
allison either way, it will have a performance effect 03:03
the current failure of Rakudo on Debian
it's caused by parrot being built with libffi
plobsing is it rakudo or rakudo* (which includes an NCI wrapping library, and presumably tests for such)
allison but run on a machine that doesn't have libffi installed
(because the build machine just happened to have it, but the packaging doesn't require it) 03:04
plobsing is that a runtime error or a startup error. missing .so sounds like it should fail at startup.
allison I'm not sure which they're packaging (rakudo or rakudo*) 03:06
bugs.debian.org/cgi-bin/bugreport.cgi?bug=636944
plobsing compile time error 03:07
when parrot is configured to use libffi, the headers will include ffi.h, the lack of which prevents the compilation of any parrot extensions 03:08
that is not Rakudo making use of NCI functionality 03:09
allison so, Parrot and Rakudo both should have build-depends on libffi
but not runtime depends
plobsing I would be surprised if doing that worked 03:10
like I said earlier, I would expect a missing .so to be a startup failure
allison you should never need .h files at runtime
plobsing Parrot and Rakudo should both build-depends on libffi-dev
and runtime-depends on libffi 03:11
need the .so for runtime, not the headers
allison it's not a missing .so
"ffi.h: No such file or directory
compilation terminated."
plobsing it will be when you try to run it
allison try to run what?
plobsing parrot or rakudo
allison you mean the compiled .so from perl6_group? 03:12
remember, the compilation is done once, then all the .so files are installed on every machine precompiled 03:13
build-depends are only required on the build machine
it doesn't make sense to require ffi.h on every machine that installs the precompiled files
plobsing no, but if parrot is built against libffi, the .so is required to run parrot 03:14
allison you mean the libffi.so, not perl6_group.so?
plobsing yes. libffi.so is required to execute parrot if parrot is configured with libffi support 03:15
allison if so, then agreed
what isn't required for runtime depends is libffi-dev
plobsing agreed. which leads to build-depends on libffi-dev, but runtime-depends on libffi only. 03:16
then again, this arrangement would prevent building of any parrot extensions outside the debian module system
which may or may not be desirable
allison libparrot-dev could require libffi-dev 03:17
plobsing that makes sense 03:18
allison (and preventing parrot extensions outside the debian module system from building isn't desirable)
03:19 JimmyZ joined
allison I'll run with that 03:19
benabik But you'd need to install libparrot-dev to build extensions anyway, so if it depends on libffi-dev, that seems optimal.
allison long-term, do you think it's likely that libffi will replace the old thunks?
benabik: yes, that was our conclusion too 03:20
03:20 rfw joined
plobsing allison: based on recent developments, I doubt my views on NCI are consistent with the majority of users and I'd like to see someone else take over. beyond that, I don't know, and I'm trying not to care. 03:22
allison plobsing: your views are pro or against libffi? 03:23
plobsing: or, something else entirely? 03:24
plobsing allison: overarching philosophy of how it should work
it includes the libffi question
allison and, by recent developments, do you mean M0? 03:25
benabik Sometimes #parrot seems to be full of people who don't like parrot but keep working on it anyway for some inexplicable reason.
plobsing no, I mean the problem we had with rakudo/zavolaj this spring, and other, lesser comments and actions
allison benabik: it's a grand tradition that goes all the way back to the beginning of parrot :) 03:27
benabik: the very first people who worked on parrot didn't like it and didn't want to work on it ;)
benabik allison: This seems less than optimal… Although it may explain the odd mishmash of features.
;-) 03:28
plobsing benabik: I like parrot. I like the vision. There are many facets to parrot. I just am not being helpful delivering what the majority apparently wants, so I move elsewhere where I may be prductive.
allison benabik: nah, the odd mishmash of features is a completely different cause: many cooks over many years 03:29
plobsing: I'm not sure rakudo counts as the majority
benabik allison: AFAICT, it is the majority of parrot users.
allison benabik: I sometimes wonder if rakudo devs would be happier just running off and writing their own VM, but hate to suggest it to them 03:30
plobsing allison: perhaps I'm mistaken, but a number of other users have made motions in similar directions 03:31
benabik allison: I'm sure they'll get around to it at some point.
allison benabik: perhaps. It would be an ironic circularity :) 03:32
plobsing: one thing Parrot has plenty of room for is multiple different ways of implementing an idea 03:33
plobsing: don't feel like you're standing in the way of progress because you think a little different
plobsing: your idea may prove to be absolutely critical in the not-to-distant future 03:34
plobsing: parrot is a slim core, with lots of room for varying extensions
plobsing: and will only become more so after M0
plobsing: there is no "majority" and no "one right way" 03:35
plobsing: it's a toolkit
03:35 bubaflub joined
plobsing I have plenty of ideas. NCI is only one side of Parrot. One that has a higher politiking/promotion to hacking ratio than I'd like to deal with. there are other, less user-visible sides to hack on with much less hassle. 03:36
allison plobsing: fair enough 03:39
got to put the kid to bed, biab 03:40
04:15 bubaflub joined
allison thinks there must be some universal rule about falling asleep while putting the kids to bed 04:54
sorear most parents live on the same time zone as their kids-they-have-to-put-to-bed 05:04
05:07 SHODAN joined 06:17 fperrad joined 06:35 mj41 joined
davidfetter has a new kid 06:41
he showed up 5 weeks early 06:42
davidfetter still kinda blown away
07:02 Eclesia joined
Eclesia hi 07:02
dalek nxed: 7f77058 | NotFound++ | / (3 files):
fix new keyed with argument in stage 0
 07:05
07:10 TiMBuS joined 07:13 preflex joined 07:24 mj41 joined 07:33 not_gerd joined
not_gerd good morning, #parrot 07:33
07:36 NotFound joined
not_gerd msg kid51 some info on the state of gerdr/msys: gerdr.github.com/on-parrot/state-of...ranch.html 07:38
aloha OK. I'll deliver the message.
07:44 jsut_ joined
dalek nxed: d6ebd68 | NotFound++ | winxedst1.winxed:
optimize == 0 and != 0 also for non int operands
 07:51
07:58 lucian joined 09:28 slavorgn joined
dalek kudo/nom: 89e9ef2 | tadzik++ | src/ (2 files):
Make --doc take optional value, defaulting to 'text'
 09:32
09:38 JimmyZ joined 09:47 SHODAN joined 10:46 ambs joined 11:09 not_gerd joined 11:31 Kulag joined 11:57 Kulag joined
atrodo =~ 12:07
12:07 whiteknight joined
whiteknight good morning, #parrot 12:09
Eclesia hi whiteknight 12:10
cotto hio 12:11
tadzik hello Parrots 12:12
cotto aloha, clock?
aloha cotto: LAX: Tue, 05:12 PDT / CHI: Tue, 07:12 CDT / NYC: Tue, 08:12 EDT / UTC: Tue, 12:12 UTC / LON: Tue, 13:12 BST / BER: Tue, 14:12 CEST / TOK: Tue, 21:12 JST / SYD: Tue, 22:12 EST
cotto none of those look right
;)
tadzik BER looks right, and not because it looks like BEER :) 12:13
atrodo Uh oh, cotto is in an alternate dimension. watch out!
whiteknight hello Eclesia 12:14
cotto btw, jnthn++ gave a really slick talk about a Perl 6 grammar debugger that he wrote at yapc::eu: tinyurl.com/grammar-debugger 12:15
bug him to port it to nqp if it sounds exciting 12:16
moritz see also: www.jnthn.net/articles.shtml
cotto that too 12:17
not_gerd it would be helpful if the error message 'error:imcc:No such file or directory' mentioned the path name... 12:21
whiteknight not_gerd: yes, I think we have a ticket open for that 12:22
actually, let me take a look now, since I'm reminded of it
moritz we at least have a ticket for reporting file name in incompatiable PBC version error 12:23
not_gerd how do I print a Parrot string (ie STRING) from C? 12:26
cotto not_gerd, gdb, Parrot-internal C or Parrot-external C? 12:27
not_gerd cotto: Parrot-internal C
cotto Parrot_sprintf_c with %Ss
actually, that doesn't sound right. 12:28
whiteknight that's right
not_gerd: are you working on that error message? I'm working on it right now
plobsing not_gerd: Parrot_io_putps
not_gerd whiteknight: just wanted to add some debug output 12:29
whiteknight okay
bleh, I forgot to configure with --maintainer 12:30
dalek rrot: 965e04d | Whiteknight++ | compilers/imcc/imc (2 files):
When IMCC can't find a file, actually tell the user the name of the file that can't be found. not_gerd++ for the find.
 12:34
12:37 bluescreen joined
cotto Is that all it took? I thought it was a much harder fix than that. 12:46
whiteknight++ not_gerd++ 12:47
moritz mostly unrelated, but recently I've had this idea that error messages that mention relative paths should also mention the current working directory 12:49
dalek rrot: 7cd618a | Whiteknight++ | t/compilers/imcc/syn/file.t:
fix a test file that helpfully did a verbatim full-text match of the error message, to guarantee we never added more helpful information to it
whiteknight moritz: patches welcome, but that doesn't sound like a fun thing to work on
moritz whiteknight: indeed, and I don't intend to pursue it right now 12:50
cotto tries to go back to sleep
moritz whiteknight: but it's worth keeping it in the back of the mind, everything that helps people to better understand errors is potentially useful
not_gerd is there a better way to resume an aborted build (after fixing some code) than `make clean`? 12:51
if not, I need a faster machine..
JimmyZ ccache?
moritz not_gerd: `make` 12:52
tadzik oh, I wish we had ccache for compiling Rakudo :)
moritz tadzik: well, if you configure parrot to use ccache, rakudo does it do :-)
whiteknight moritz: no question. I'm not saying it isn't useful. We have to weigh the usefulness against the amount of effort it takes to implement. Some fixes are easy. Some, not 12:53
not_gerd moritz: I get PackFile_Header_validate error when I try that...
moritz ... for compiling the PMCs and ops :-)
not_gerd might be unrelated, though
I'm just wondering where my debug output went :(
whiteknight where did you put it? 12:55
not_gerd I'm working on adding MSYS path translations to Parrot_io_open() and added `Parrot_io_putps(interp, _PIO_STDOUT(interp), path);` to my `#ifdef __MSYS__` block 12:57
tadzik moritz: hmm, did you try that? 12:58
moritz tadzik: yes, but it doesn't really speed up anything, because the huge bottleneck is setting compilation 12:59
tadzik I see 13:00
whiteknight not_gerd: I would expect that to work, unless something is getting redirected 13:02
_PIO_STDERR should work too, and is less likely to be mangled
not_gerd I think STDOUT got somehow redirected into the bytecode file, and that's why the validation failed later on 13:04
it works with STDERR
13:11 bubaflub joined 13:14 ambs_ joined
benabik o/ 13:32
dalek kudo/nom: 4f6018b | tadzik++ | src/Perl6/Grammar.pm:
Allow any number of colonpairs in Pod block configuration
kudo/nom: 380494c | tadzik++ | / (3 files):
Parse Pod block configuration and store it in Pod::Block.config. Add tests.
atrodo not_gerd> ping 13:35
not_gerd atrodo: pong 13:36
atrodo not_gerd> finally catching you about the m0/lorito topic
Your observations don't surprise me much. It was designed when we still had the nebulous topic of Lorito and didn't have m0 13:37
13:37 Eclesia left
atrodo Designed with the requirements at the time, which were to be minimal, simple, and powerful enough to implement all of C's basic functions 13:38
not_gerd Ii's an interesting choice that Parrot guts will be m0-based - that's not generally done on other VMs (PyPy excluded) 13:41
without a JIT, you'll have to pay the dispatch penalty a lot more... 13:42
atrodo Yep, but it has the potential to solve a lot of outstanding speed issues for parrot. 13:45
I'm still not sure if it's the right trade offs, but I think the simplification of the parrot guts is understated.
Making the guts more approachable make the entire project more approachable. I've steered clear of using parrot as a target for many years because it was so difficult for me to grok why things were done a certain way 13:46
whiteknight the question of "why" is often very disappointing. I don't suspect many of the biggest infelicities in parrot have an underlying reason 13:47
a lot of things just happened, in response to things that users claimed they just needed 13:48
atrodo whiteknight> I always suspected that was the case, but I need to know how and the why seemed to be entangled in the answer
s/need/needed/
not_gerd also, has there been any discussion on m0/gc interaction? 13:49
atrodo That and pasm/pir was the interface. I'm sure you know how that went, whiteknight
whiteknight yes, very well
not_gerd in particular, if we want HLLs to generate m0 (we want that?), and also assuming local variables should be mapped to m0 registers, there need to be a way to attach meta-information to registers 13:50
atrodo not_gerd> for instance? 13:51
not_gerd the gc needs to know which registers hold PMCs, and other HLLs (eg Perl6) might want to attach type information/constrants to local variables
moritz don't assume that local variables map directly to registers
I mean, some of them may 13:52
but most don't
benabik The first thing I see a lot of people say about M0 is "if HLLs generate M0". We should probably decide if we want that and make a clear statement about it in the design doc. I've always been under the impression that HLLs should care about M0 in the future as much as they care C today. 13:57
tadzik true
not_gerd so what do HLLs generate? PIR?
tadzik well, pir is supposed to generate m0, isn't it?
JimmyZ well, maybe pir, maybe pbc, maybe M0 13:58
tadzik and pir is supposed to be trashed as well istr, so maybe just PAST, which will be turned to m0/pbc
well, HLLs do generate PAST now, mostly
moritz but PASTs isn't as expressive as PIR
benabik moritz: There's always inline nodes… :-/ 13:59
moritz so much for abandoning PIR
atrodo My vote has been for m0 and pbc available for HLLs to use 14:00
not_gerd how does the current system work, ie how do you go from PAST to something that's actually exected?
tadzik if that's through some toolkit, +1
not_gerd: PAST compiler generates pir, pir gets compiled to pbc
benabik Technically PAST::Compiler generates POST, POST::Compiler generates PIR.
NotFound If m0 is very low level and we allow HLLs to generate it, security arenas and validity checks can become a nightmare. 14:01
benabik Security isn't really Parrot's strong suit. 14:02
atrodo NotFound> That's my worries about it. There's never been many concerns raised around m0 bytecode and security, and when I've seen it come up, it's been very dismissive
benabik> You can say that again.
Which is very disappointing. 14:03
benabik "that again"?
;-)
atrodo Touche
whiteknight what we haven't had a lot of are specific use cases and examples of what users need from a security system 14:08
lots of people are expecting somebody else to figure out what's needed, design a solution, and implement it 14:09
benabik whiteknight: As I progress with PACT, I think "invalid bytecode shouldn't crash the system" will start to come up. :-D
whiteknight benabik: and how do you avoid that without tanking performance?
have a second validation tool that nobody will run? checksums that will be easy to change, and will still lead to crashes? 14:10
we could definitely teach the packfile pmcs how to validate packfiles on creation. that does ignore the idea of a creepy attacker with hand-crafted pbc files 14:11
atrodo whiteknight> And that's the issue with Parrot's security. No one wants to take a stab at it because performance is put at such a higher priority
tadzik I suppose performance is currently much more hurting issue than security 14:12
whiteknight atrodo: we are driven in large part by what users are asking for. Users are asking for security, and in some cases giving us specific benchmarks that need improvements
moritz iirc dukeleto wanted some pretty specific security features for PL/Parrot
whiteknight no users are giving us use-cases for security that we can reach for
moritz let me state a simple one 14:13
I run p6eval
I'd like to be able to tell rakudo that it's not allowed to read files except from it's installation directory 14:14
dalek kudo/nom: 276bfeb | tadzik++ | / (5 files):
Parse =config directives properly
moritz and it's not allowed to write any files, or open sockets, or fork
tadzik and call C code
s/and/or/ probably
whiteknight moritz: and those restrictions need to happen at the parrot level? Many of those things sound like they would almost be better handled by Rakudo 14:15
moritz whiteknight: depends on what you mean by "better" 14:16
whiteknight for example, a flag in your file handle type, or telling p6eval that it can't compile code that creates certain types
not_gerd whiteknight: so PL/Parrot would need to special-cased for every language?
atrodo whiteknight> Yes. Because it's not just Rakudo that wants those security measures. It's every HLL should be able to ask for the same level of security
not_gerd that would somehow defeat its purpose, methinks
whiteknight moritz: yes, it does depend on what I mean by that word
moritz whiteknight: for me it's "better" if parrot does it, in that I as a HLL developer don't have to work hard to get the feature
whiteknight atrodo: we can build in things like that to our own opcode sets, or our own built-in pmc types. But rakudo provides many of its own
atrodo moritz> And probably get it wrong
whiteknight when somebody else runs C code outside the parrot core, we have no defense against it. I can't tell parrot to prevent you from running arbitrary C code in one of your own extensions 14:17
moritz and I don't expect that part to be secure
atrodo whiteknight> What about systems that accepts PBCs? Like imagine a parrot applet
moritz but currently you can only do harm in rakudo through parrot's IO subsystem
whiteknight moritz: okay, but Rakudo is a great example in that it has a *lot* of custom code 14:18
atrodo: what about it?
atrodo whiteknight> what about security with those systems? PL/Parrot being a perfect example.
whiteknight atrodo: again, what about it? 14:19
atrodo How would you purpose to secure it?
whiteknight secure it from what? From whom? What is and is not considered "secure"?
if security means "We should be able to restrict IO". tjat 14:20
that's a flag that we can set
and I suspect people want more than a simple flag
moritz whiteknight: some people want constraints on memory and CPU usage too
NotFound Some upper level must stablish a security arena and its policys, parrot must provide the mechanic to allow that.
atrodo Malicious users. In all aspects. Outside users should never be able to do things that the users in control don't want them to.
whiteknight if it means we should be able to toggle on or off certain opcodes or vtables, that's a simple API that people can say "turn this off"
atrodo: so you have malicious users with the ability to execute arbitrary PBC files, and it's parrot's job to be the last line of defense? 14:21
atrodo: at that point, the battle is long over
atrodo whiteknight> Then what's the difference between a pbc and .jar? Has java already lost the battle then? 14:22
whiteknight if we have a security subsystem that allows certain features to be toggled, and the attacker has access to modify those settings, who cares what the PBC contains?
now, if what we want is the ability to speculatively load packfiles and verify them before we commit their contents to the global environment, that's something that we can do 14:23
NotFound The feature of toggling that features is the first that need access control.
whiteknight NotFound: so we would have certain features in Parrot that would require system user permissions to perform? 14:24
NotFound whiteknight: some upper level has control, it stablishes the policy and call controlled code, probably on a secondary intrepreter/runner/thread/whatever. 14:25
whiteknight I'm not saying that we can't do security, or that we shouldn't, or anything like that. What I'm saying is that it's hard to do and people keep saying "what about applets" or "we need security" without putting forward a lot of specifics
and there are going to be trade-offs. We need users to tell us exactly what they are willing to give back, or go without
because if we start implementing security, and we start to see regressions anywhere in the spectrum, you can be damned sure we're going to hear about it and have to have some kind of emergency intervention to "fix" a release the day before it ships 14:28
NotFound I think that before attempting to implement something we should have a better design of the interpreter/thread/context thing.
whiteknight or if we put in security, and it isn't 100% what somebody wants, they're going to have to implement their own versions and put together ugly workarounds to get past the parrot version, and then complain that Parrot doesn't do what users need
atrodo whiteknight> moritz gave a very simple example and very specific features. The response was "rakudo should do it". I now have no hope that parrot will ever have any security worth anything if that's the response given. I'm out of this. 14:30
whiteknight atrodo: that was not the response. I said it sounds like those are things Rakudo could do better, becuase of the nature of Rakudo
Rakudo has a lot of custom C code, and Parrot can't secure that. That means Rakudo is going to have at least two security systems in place, which it will need to manage 14:31
other HLLs or projects are hardly in the same situation
moritz none of the C code in rakudo is security relevant
whiteknight Rakudo currently has it's own custom object model, so Parrot cannot prevent the creation of specific object types, or prevent the call of specific object methods 14:32
moritz (for this type of security at least)
whiteknight Rakudo has custom Ops, which Parrot can't secure, prevent, or replace
Parrot can put in all the security in the world, and very little of it will be able to help Rakudo
moritz whiteknight: rakudo does all its IO through parrot's IO, which means that it instatiates parrot PMCs 14:33
whiteknight: which are not 6model based at all
whiteknight moritz: like I said, we can do something about IO. That's trivial really, depending on the solution we want
I am highly skeptical that it is going to be more than a drop in the bucket of Rakudo security needs
NotFound I don't think that disabling opcodes, vtables or pmcs is the better way to set barriers. Subsystems can do, and we can ask HLLs to use that subsystems
whiteknight NotFound: Right. That's easy to do, for types and things that Parrot core provides 14:34
but again, almost nobody uses 100% parrot core stuff. Everybody has custom code they're calling, or custom classes, or custom NCI bindings
NotFound NCI is a big issue here. 14:35
whiteknight It seems stupid to me, and maybe that's just my problem, for us to secure 50% of things and tell users that they are on their own
14:36 PacoLinux_ joined
whiteknight or give some kind of guarantee that Parrot is safe, so long as you don't choose to run any code that isn't safe 14:37
atrodo whiteknight> As a epilogue, it's an extremely frustrating subject for me because I've had to pass on two major projects simply because parrot has no security and no easily accessible framework for adding security measures 14:39
whiteknight to secure Parrot core, and to hell with extension code, we would need: the ability to restrict certain opcodes, the ability to prevent creation of certain PMC types, the ability to restrict certain methods and/or vtables on PMCs, the ability for two-stage loading of packfiles, and the ability to prevent a child interp from interacting with a parent interp 14:40
JimmyZ would like to see a detailed rfc lists that users want what security parrot offers
whiteknight atrodo: I understand the frustration. I do. I would like to have these features, and would certainly work to implement them, if we knew exactly what was needed and what users expected
JimmyZ: I would like that too 14:41
the fact that, I think, many of these security features are tightly coupled with various refactors and fixes I already have planned is a good thing 14:42
Here are some simple questions we need answered: Do we want security at the whole VM level, at the level of individual interpreters, or at the level of the context? 14:43
dalek kudo/nom: df376ba | tadzik++ | src/Perl6/Grammar.pm:
Allow any non-whitespace string as a =config type identifier. Fixes S26 parsing
whiteknight are users willing to give up the current NameSpace system, or allow radical backwards-incompatible changes to it? 14:44
14:44 PacoLinux_ joined
whiteknight how are we supposed to verify a pbc file, besides tests for basic structure conformity or checksums? 14:44
JimmyZ well, I don't think security features is important things now 14:45
whiteknight does a single binary of Parrot need to be both securable and open depending on settings, or can we use different compilations for different usages?
not_gerd can I add a header to platform/win32 or is there a better place to put a macro which needs to be used from several platform-specific files?
no other platform dir contains any header files... 14:46
whiteknight how do we handle security issues on Windows? On embedded devices? when Parrot is embedded into a larger program with its own settings?
JimmyZ can we steal some ideas from java?
whiteknight we can
JimmyZ or can parrot
whiteknight if what they do is good
JimmyZ if they are better than parrot :) 14:47
whiteknight if they are better than what parrot would eventually do on it's own
I don't want to copy a design that is not better than something we could do ourselves
M0 is going to decrease our reliance on binary extensions, which is good for security. However, it is going to increase our dependence on FFI, which is bad 14:49
namespace and bytecode refactors are going to do a lot for security, but the transition is going to be very messy, and lead to lower bytecode loading performance, probably 14:50
JimmyZ pays more attention to threads, 6model on parrot, PCC
whiteknight threads raises a whole other bag of worms. If we have a lock-based concurrency model, it will be trivial and undetectable for a malicious user to craft bytecode in such a way that it deadlocks
or hell, in 4 lines of code I can write an infinite loop that would lock up a machine and make it vulernable to DOS attacks 14:51
figuring out exactly what is meant by security is important, because there are lots of different, unrelated things to think about and we can't protect everything from every attack 14:52
dalek kudo/nom: 8336468 | pmichaud++ | NOMMAP.markdown:
Add <!before> to NOMMAP.
 15:07
dukeleto ~~ 15:14
whiteknight dukeleto: We're talking security today. I know you had some ideas from your PL/Parrot work. Want to share your thoughts? 15:31
15:40 dmalcolm joined
dalek kudo/nom: 3f57585 | jonathan++ | src/Perl6/Actions.pm:
Be sure to apply traits for regexes with the same ordering we do methods.
 15:49
kudo/nom: 0999de1 | jonathan++ | src/Perl6/Actions.pm:
Action method for trait_mod:<will>.
dukeleto whiteknight: sure. PL/Parrot needs a lot more security than Parrot provides natively, so I had to fake some of it 15:52
whiteknight dukeleto: What I'm really looking for are some of the specifics. What exactly needs to be secured and how?
dukeleto Parrot has some vague idea of "opcode groups", but they never make it out of the build system. For instance, I want to be able to disable all file I/O in a given Parrot interp 15:53
whiteknight: instead of doing this hackery: github.com/leto/plparrot/blob/mast...secure.pir
whiteknight okay, so we need to be able to disable certain opcodes. I assume we also need to be able to disable certain PMC types?
15:53 rurban joined
whiteknight ewww... 15:54
dukeleto whiteknight: the pmc's that I care about are just wrappers around opcodes, so I think if the opcodes are removed, then that would be enough
whiteknight okay, we don't want that
dukeleto whiteknight: yeah, that is one of the hackiest hacks I've ever done
whiteknight dukeleto: but even in the case of FileHandles, you can call methods on FileHandle that write to output handles without calling any ops 15:55
dukeleto whiteknight: also, interps should not know anything about each other, and definitely I should not have to pass in the first ever created interp to create subsequence interps. I created a TT about that a while back (as well as for opcode groups)
whiteknight any ops besides normal method calls
yeah, the interp parent thing is a problem with the threading system, and it's going to stay until we rip out or fundamentally refactor threading
okay, so let's say I have a new PMC type SandboxInterp, which is like an ordinary interpreter in that it assumes it is the top-level and doesn't try to access a parent interp for anything 15:56
dukeleto whiteknight: it would be preferable to be able to disable opcodes at compile time, i.e. when PL/Parrot is compiled. Not sure exactly how that would work.
whiteknight: i like it
whiteknight so I can create a new SandboxInterp, initialize it, have the parent toggle certain settings like you do in your example (but with an official API), and then set it loose 15:57
dukeleto whiteknight: it would also be nice to disable or selectively disable network IO
whiteknight: that sounds very pleasant
whiteknight dukeleto: We can do the same trick for Socket PMC as you do there for File and FileHandle 15:58
again, with a better API
dukeleto whiteknight: indeed. I think Socket PMC inherits from FileHandle, so that is covered in my hacky example, iirc 15:59
whiteknight: removing the ability to eval code in an interp would be another thing, i.e. the interp can only load already-existing bytecode and PIR, but cannot compile new code at runtime. Again, not sure how hard that would be 16:00
whiteknight okay, so SandboxInterp would have methods on it to remove or replace certain types by name. It would have methods to remove or replace compregs 16:01
dukeleto actually, I can't decide if plparrot_secure.pir is the hackiest thing I've ever done, or plparrot_make_sausage() github.com/leto/plparrot/blob/mast...rot.c#L531
whiteknight you know, these are code examples you should probably keep secret :) 16:02
dukeleto whiteknight: yeah, i think that went out the window when I pushed to github. My only defense is that without the power of whiskey, that code would not exist. 16:03
whiteknight so is that what we need for security, just the ability to create and modify sandboxes?
that seems thin to me
dukeleto whiteknight: it surely would greatly increase the current security features of parrot now, which are basically nil 16:04
whiteknight The whiteknight/frontend_parrot2 branch is going to be a big help in that regard, because we can change all these settings from a PIR bootstrap instead of through a complicated C API
although I don't have an ETA yet for that branch
dukeleto whiteknight: whiskey gave me the fortitude to read all the postgres header files to reverse engineer all that junk, and then I never went back to refactor and make the code pretty. One of these days... 16:05
whiteknight whiskey: is there anything it can't do?
dukeleto whiteknight: i like not having to do stuff from C
whiteknight I rewrote the parrot frontend in winxed. I'm a bit of a fanatic
16:06 theory joined
whiteknight dukeleto: in the time it would take me to put together a sandboxing solution like I described, could we have some concrete plans for where to go next? You said it was a good start, but would it really be a building block for the system we ultimately want? 16:07
or, would it be a distraction from the best possible system? 16:08
benabik "I'm going to open my laptop. If the code isn't refactored in an hour, send more whiskey."
whiteknight "you know what? Just send more whiskey" 16:09
dukeleto whiteknight: would love to get your feedback on trac.parrot.org/parrot/ticket/1500 16:11
whiteknight: it is an old TT that needs love
whiteknight: as well at this one trac.parrot.org/parrot/ticket/1697
whiteknight: and if you could comment on my "not needing a parent interp" TT, describing your sandbox api, that would be awesomesauce: trac.parrot.org/parrot/ticket/1880 16:13
whiteknight: if you had that sandbox solution, that would motivate me to hack on PL/parrot more, and give it a proper security model, which in turn would probably point out some missing features from the Parrot-side, and start a nice code-design whirlpool 16:16
not_gerd can I rely on the fact that Parrot_str_free_cstring() just calls mem_sys_free() on its argument? 16:17
whiteknight not_gerd: no. It won't always, depending on the GC. Only use it if you have a cstring you got from a Parrot string 16:18
not_gerd: in the future we might cache them, so free_cstring won't actually do anything 16:19
or we might not, so call it anyway to avoid leaks
dukeleto whiteknight: looks like this thread patch fell through the cracks, and might fix our intermittent netbsd failing threads test. Can you take a look at it? trac.parrot.org/parrot/ticket/1340 16:20
dalek TT #1917 closed by dukeleto++: Parrot_api_make_interpreter() cause a crash when another interpreter ... 16:22
TT #1917: trac.parrot.org/parrot/ticket/1917
whiteknight threading needs to be deleted, not patched 16:29
16:32 davidfetter joined
whiteknight and before anybody suggests otherwise, we have version control and will always have a record in case we want to salvage some ideas from it 16:32
16:34 contingencyplan joined
not_gerd I'm off for now, but I would appreciate it if someone took a look at github.com/gerdr/parrot/commit/79f...16fe2aff2d and told me if there's a gross violation of Parrot conventions 16:37
whiteknight not_gerd++ 16:39
dukeleto whiteknight: +1 to deprecating current threads. But seemingly we should have a replacement ready before ripping it out. But yes, it isn't really worth fixing at this point. 16:41
jnthn__ figures m0 has a threading plan worked out. 16:42
well, hopes.
whiteknight dukeleto: that's the same thing people have been saying. Let's just keep the garbage around until we have non-garbage to replace it with 16:44
and then, we can keep the garbage and non-garbage around together, so we can make a smooth transition 16:45
jnthn__: We have lots of ideas floating around. Most of them deal only peripherally with M0 16:47
16:57 Eclesia joined
Eclesia hi 16:57
whiteknight hello Eclesia
Eclesia hi bubaflub, found the fix on gmp ? 17:04
bubaflub Eclesia: not yet. going to need some more info from your system parrot.
Eclesia sure, just ask and how to get those
dukeleto jnthn__: i don't think m0 has a threading spec yet 17:12
whiteknight: i understand your frustration. We ripped out the old JIT without having a smooth transition, so there is precedent for not keeping around "garbage"
whiteknight: i think we need to see if anybody is using the current threads at all. I really don't know. 17:13
17:20 ligne joined
cotto_work ~~ 17:25
dalek TT #2179 closed by jkeenan++: Bug in setup-parrot-3.6.0.exe broke PATH 17:26
TT #2179: trac.parrot.org/parrot/ticket/2179
17:30 mj41 joined 17:32 autark joined 17:33 mj41 joined
Coke benabik: (Sometimes #parrot seems to be full of people who don't like parrot but keep working on it anyway for some inexplicable reason.) ... Wow. I think you just summed up my entire involvement. ;) 17:37
nopaste "coke" at 192.168.1.3 pasted "bikeshed changelog" (18 lines) at nopaste.snit.ch/73950 17:46
Coke So, originally, changelog was "changes" which happened intra-release, and were per user. Now all that is in news, which is per release. I honestly don't think we need to note the user or the date at all - those are in parrothist, anyway. 17:50
nopaste "coke" at 192.168.1.3 pasted "bikeshed changelog" (17 lines) at nopaste.snit.ch/73951 17:51
Coke anything in changelog that predates that can keep its date/name marker.
17:56 mikehh joined
whiteknight did anybody else in the area just feel an earthquake? 17:58
atrodo if by area, you mean eastern us, nope 17:59
cotto_work earthquake.usgs.gov/earthquakes/ 18:00
whiteknight 5.8 in virginia. definitely shook our building
Coke FYI, we have 86 releases mentioned in NEWS. 18:01
dalek kudo/nom: c8be361 | tadzik++ | src/Perl6/Pod.pm:
Fix Pod::Config regression
kudo/nom: 16bad5c | tadzik++ | / (2 files):
Allow multi-line Pod block configuration
18:05 not_gerd joined
cotto_work From what I remember, the reason given for keeping the current threading code around wasn't that someone's likely to be using it, rather that there might be enough useful code to benefit a proper implementation. 18:07
plobsing the platform abstractions might be useful, but the stuff for working with interps and the PMC types are utter garbage 18:08
bubaflub can't we just delete it since we have source control? we can always resurrect it later. 18:09
whiteknight like I said, it's not like we're deleting the entire history
the platform abstraction stuff is decent, but it's also a relatively small portion of the total 18:10
plobsing I'd argue that even the platform abstractions, while useful, could be recreated in about 1 person-day of reading win32/posix docs
cotto_work plobsing: weren't you the one who was advocating keeping the existing code around for possible future reuse? 18:11
plobsing I advocated keeping around the platform abstractions. I've since changed my mind. I reserve the right to do that from time to time. 18:12
whiteknight plobsing is one of the big reasons I haven't jumped on it yet
cotto_work Certainly. Anyone may reserve the right to change his or her mind at any time.
whiteknight adds this to the pile of "branches I need to create"
cotto_work If you're going in the wrong direction, progress means turning around. 18:13
whiteknight I love branches where most of the work is Ctrl+A and Del 18:15
makes me feel warm and fuzzy inside
plobsing git rm is always fun to use
whiteknight rm -rf / 18:18
MUAHHAHAHAHA
plobsing rm: it is dangerous to operate recursively on `/'
rm: use --no-preserve-root to override this failsafe
too bad 18:19
whiteknight oh yeah, I forgot they added that
plobsing even if they didn't I don't have the perms
18:19 Eclesia1 joined
whiteknight if you have physical access to the machine, almost exactly the same result can be obtained with a hammer and a chisel, with or without perms 18:20
of course, you will need to buy a new drive
atrodo whiteknight> apparently, some people felt it out here. At least that's what my wife has told me
whiteknight atrodo: I've heard reports as far away as toronto, but I don't know how accurate they are
NYC definitely
I work in a very old stone-and-brick building, so I got the hell out 18:21
plobsing true, but I still think it is a good idea not to run with perms required to blow away your machine unless and until you need to do important configure-y stuff.
bubaflub my Pittsburgh co-workers had to evacuate their office building 18:23
plobsing whiteknight: Didn't feel anything in Waterloo ON (~1hr from T.O.) 18:24
whiteknight that's good. It's nice to hear a sane, first-hand account 18:25
18:34 rohit_nsit08 joined
rohit_nsit08 hello #parrot 18:35
tadzik hello rohit_nsit08
rohit_nsit08 tadzik: hello 18:36
dalek kudo/nom: 6ad7834 | moritz++ | tools/build/Makefile.in:
fix bug from 19cfd13 that made Sub !~~ Callable
 18:37
18:38 theory left
whiteknight hello rohit_nsit08 18:39
rohit_nsit08 whiteknight: hello, have submitted the final report on gsoc site, but was having doubt about what should I do now , I am willing to finish my work as corella is still not complete 18:42
whiteknight rohit_nsit08: I haven't tested it recently. I will have to look at it
rohit_nsit08: can you write a short summary about what is done and what needs to be done?
rohit_nsit08 yes sure,' 18:43
dalek rrot: a136a32 | fperrad++ | tools/dev/mk_inno.pl:
[win32] fix TT#2179
Coke jmckinley.posterous.com/dc-earthqua...evastation 18:49
I think the pencils down date marks the end of code-to-be-considered-for-evaluation.
cotto_work Coke: that's my understanding
Coke Doesn't mean you cannot keep working in that repository.
if that's it, might be worth doing a tag of GSOC_PENCILS_DOWN_2011 or something. 18:50
NotFound In the automake mailing list I've seen a suggestion of creating a new branch to keep working, and let the original branch intact for the evaluation. 18:51
cotto_work Coke++ # that link made my officemates happy 18:52
Coke cotto_work: I opened it actually fearing the worst! 18:53
NotFound: that would also work; as long as there is some way to say "this is what goes to google".
bubaflub NotFound, Coke, and rohit_nsit08: previous years of GSoC we could keep working in the original repo even on the original branch; you are simply required to upload only the code that was written between the start and the end date.
if you're in git, you can filter your commits by start date and end date and then generate a huge diff and upload it to Google 18:54
Coke bubaflub: aye. tag just makes it pretty. ;)
bubaflub agreed.
rohit_nsit08 hmm.. got it . 18:55
tadzik I used git log 'HEAD@{23-05-2011}'..'HEAD@{22-08-2011}' -p --author='Tadeusz Sośnierz'
whiteknight rohit_nsit08: hey, I'm looking at the corellaScript repo, and I don't see the source code for your PIR code generator 19:14
is that not checked in?
19:16 soh_cah_toa joined
rohit_nsit08 whitknight: ?? wait , let me check , all the PIR codegen functions contain the code for PIR generation 19:20
whiteknight rohit_nsit08: so corella.js is the code generation source? There isn't an original file somewhere? 19:21
Coke is corella.js a generated file?
ah, too slow.
rohit_nsit08 corella.js is the original compiler file except the bottom code which is for testing it on node 19:22
the topmost portion contains the parser and after that are the tree node generating functions 19:23
below that are the PIRcodegen functions
program execution starts from the "Program" node
whiteknight okay, so that's the file you wrote, and there aren't original files anywhere?
rohit_nsit08 my code is actually in the code generator part , in the original functions I have tried to get PIR 19:24
by reading the tree and than executing the code generator functions on the specific nodes
19:25 davidfetter joined
rohit_nsit08 the parser and node generating part is similar to the "cafe" compiler's parser.js file 19:25
but it was using commonjs libraries somewhere so I removed them 19:26
Coke hurls: www.modernperlbooks.com/mt/2011/08/...-code.html
19:26 PacoLinux_ joined
Coke a sad read. 19:26
atrodo Coke> I was just reading it 19:27
A sad read indeed
19:29 lucian joined
rohit_nsit08 whiteknight: it is the corella.js file that needs to be compiled at the end , class folder contains the js data types 19:29
whiteknight yeah, I saw that. I'm just making sure I'm not missing anything 19:30
rohit_nsit08: and you used the cafe grammar for javascript, right?
rohit_nsit08 ya the same grammar, It was taking time to understand the whole grammar from various books, so I finally decided to go with the same grammar, but I did cross checked it with ecmascript 19:31
whiteknight okay 19:33
19:35 Eclesia1 left
rohit_nsit08 whiteknight : Isn't there any standard that checks whether a grammar is complete or not, I mean is it possible that cafe's grammar is not exactly what javascript is? 19:36
whiteknight rohit_nsit08: no automated way. The only way we would know is to run lots of tests
cotto_work #ps in now
rohit_nsit08 whiteknight: tests as in ? like I tested different codes and studied the AST generated and I tried to get PIR from the same AST . Don't think it was the best way though 19:40
19:41 schmooster joined
whiteknight rohit_nsit08: I'm sure there are test suites somewhere for other JS implementations 19:41
cotto_work nine: if you're online, we're doing our weekly meeting in #parrotsketch 19:47
rohit_nsit08 whiteknight: ya , actually I was thinking about the grammar part. and it can only be tested after we have a compiler using that grammar 19:50
whiteknight right
19:50 lucian joined 19:53 lucian joined
dalek nxed: f5c6f7c | NotFound++ | winxedst (2 files):
implement predefined constant __DEBUG__, harcoded to false for a now
 19:55
20:01 rohitnsit08 joined, rohitnsit08 left
whiteknight NotFound++ 20:06
20:15 rurban joined 20:27 PacoLinux_ joined
dalek rrot: 2268530 | cotto++ | config/gen/makefiles/root.in:
don't assume $(MAKE) == make in release

make release is broken on windows/msvc. This makes it a little less broken.		 20:50
20:50 davidfetter joined
Coke cotto++ 20:52
that was on my list of things to get around to. ;)
cotto_work Coke: that's not the last step. 20:55
I wish I could fix it further, but I've spent a lot of time on Parrot stuff already and need to do what $dayjob is paying me to do.
Coke will do a make release on windows after killing NEWS. 21:02
dalek TT #2183 closed by cotto++: sha256 problem encountered during 'make release'
TT #2183: trac.parrot.org/parrot/ticket/2183
cotto_work Coke++
dalek nxed: 3004909 | NotFound++ | winxed (3 files):
implement setting __DEBUG__ in stages and non installed driver
 21:06
nxed: cebd3a8 | NotFound++ | winxed_installed.winxed:
implement setting __DEBUG__ in installed driver
 21:13
nxed: 1938085 | NotFound++ | pir/winxed_ (2 files):
update installable files
 21:14
rrot: b84af47 | NotFound++ | ext/winxed/ (2 files):
update winxed snapshot to 1938085ba1:

  * __DEBUG__ predefined constant - --debug command line option		 21:27
allison BTW, a long time ago we talked about a Parrot test suite that could be run on an *installed* Parrot. 21:34
AFAIK, there's been no work on it, but I need it now for packaged Parrot. 21:35
The Rakudo packagers keep finding issues in the installed Parrot, because they are building their own packages on to depend on it.
These are often small install problems, that could have easily been identified by even a simple test suite. 21:36
But they aren't discovered before I upload the Parrot packages, because I run the test suite on the Parrot build directory, not on the installed Parrot.
21:42 particle joined
NotFound allison: the winxed tests exercise a lot of parrot features, and can be run from a installed parrot. 21:45
cotto_work Would such a test suite just be another makefile target that ran against whichever parrot is in the $PATH?
or more precisely, whichever parrot_config is in the path 21:48
allison cotto_work: ideally, yes, they would be able to be run against any parrot, including one specified with a command-line flag to pick out a specific parrot_config 21:54
cotto_work: which means, they could even be run against parrot in the build directory
cotto_work something like make test parrot_config=/usr/local/foo/bin/parrot_config
allison (no point in wasting tests by limiting them to only running on an installed parrot) 21:55
aye
cotto_work: it could be make install_test parrot_config=/path... 21:56
cotto_work: if we still have some tests that can only run in the build directory
cotto_work allison: how urgent is this? 21:57
allison cotto_work: it's affected every package I've built so far this year, so it's enough of a priority for me that I'm willing to invest some time in it
cotto_work: if we have a clear consensus on how to do it that makes the most sense for Parrot 21:58
(or, something roughly approximating consensus)
NotFound: the winxed tests are a good first stab, but over time I'd like to expand the test suite with regression tests from real issues we've found in various language implementations 22:00
NotFound: so, I really want a sensible place to hang the tests within the core Parrot test suite
22:02 mj41_nb joined
NotFound We may need a special purpose harness that does not depend on standard handling of shebang lines. 22:04
cotto_work allison: you can always start a branch. We can maintain a whitelist or blacklist of tests that work (or don't) with an installed parrot. 22:23
22:31 davidfetter joined 23:03 bubaflub joined
dalek kudo/nom: 54e85a2 | tadzik++ | src/Perl6/ModuleLoader.pm:
Accept .pm6 as a module file extensions, prefer it to .pm if both are present
 23:13
23:23 kid51 joined
kid51 aloha, clock? 23:51
aloha kid51: LAX: Tue, 16:51 PDT / CHI: Tue, 18:51 CDT / NYC: Tue, 19:51 EDT / UTC: Tue, 23:51 UTC / LON: Wed, 00:51 BST / BER: Wed, 01:51 CEST / TOK: Wed, 08:51 JST / SYD: Wed, 09:51 EST
moderator Trac maintenance Aug 24 17:00 UTC | Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC 23:59
moderator Trac maintenance Wed Aug 24 17:00 UTC | Parrot 3.7.0 "Wanda" | parrot.org | Log: irclog.perlgeek.de/parrot/today | #parrotsketch meeting Tuesday 19:30 UTC

Powered by Cro and the Raku® Programming Language.

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

Thank you!