Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
00:10 whiteknight joined
whiteknight good evening, #parrot 00:21
mikehh hi whiteknight 00:28
in c is ux & (1 << n) - 1 the same as ux & ((1 << n) - 1) 00:30
sorear yes 00:32
mikehh sorear: just trying to fix warnings in structview.pmc 00:33
it's horrendous 00:34
8 of the warnings come from -> BEGIN_KEYED(interp, _self, k) a 43 line macro (I think I got it though 00:37
00:44 davidfetter joined
mikehh what is the standard return for a Null PMC * 00:53
sorear NULLPMC 00:54
whiteknight blah, pbc_merge is still not doing what it should 00:56
annotations are a pain
01:04 mtk left
dalek rrot: 618b825 | mikehh++ | src/pmc/structview.pmc:
quiet compiler warnings in structview.pmc
 01:23
01:26 whiteknight left 01:53 kid51 joined
kid51 mikehh: ping 01:53
mikehh kid51: pong 01:54
kid51 Mike: Were you able to look at what I pasted earlier today to fix some build warnings?
nopaste.snit.ch/51399 01:56
mikehh yes - it is the type of thing needed either casting to size-t to int or in to size_t
s/in/int/
kid51 I've never done enough C to get to type-casting, so this was just monkey-patching.
But it's passing tests so I wonder if this is applicable. 01:57
mikehh yes it is
kid51 okay. Am testing now on darwin, and if that looks good, I will commit 01:58
mikehh you might want to look at what I did with src/pmc/structview.pmc -> github.com/parrot/parrot/commit/618b8252f9
I think that got most of the warnings for it 01:59
there were a couple of int/size_t casts to get rid of signed/unsigned comparrison warnings 02:00
kid51 Do you understand what structview.pmc is all about? 02:01
mikehh in general, I have a good idea, it took me a while to work out the bits and peices 02:02
kid51 What is it "for"?
mikehh the thing that caused me a lot of problems were the macros which threw out the line number correspondance 02:03
8 of the warnings were caused by BEGIN_KEYED(interp, _self, k) a 43 line macro on one line of the PMC 02:04
kid51 heh
mikehh which was caused by a size_t/int comparisson in tyhe macro 02:05
kid51 So, did doing a proper comparison in the macro eliminate all 8 of those warnings? 02:06
mikehh yup
kid51 nice
mikehh it took me ages to track it down though - I eventually configured with --no-line-directives and then compared the generated c file to the pmc 02:08
dalek rrot: 3ff579a | petdance++ | frontend/pbc_merge/main.c:
annotated a couple of functions, and do not compare opcodes to pointers
mikehh kid51: as to what it is for - it gives methods to map PMC pointers to C structs, not 100% sure what it is used for though 02:15
kid51 Hmm, I wonder if petdance's commit will fix fails in t/codingstd/c_arg_assert.t
mikehh kid51: probably not, I will look at that a bit later
probably needs aanother run of make hearerizer and then fix any missing ASSERT_ARGS 02:16
kid51 I just ran make codetest for first time today.
But that was on the next-to-last commit 02:17
Can you fix a linelength fail at line 518 of frontend/pbc_merge/main.c? 02:18
mikehh I ran it a lttle while ago and got a bunch of failures mainly with various pbc_merge stuff, but was working on structview.pmc
02:20 kid51_ joined
mikehh kid51: yeah - will try and fix the codetest failures 02:21
02:24 kid51 left
dalek rrot: f2f32f8 | jkeenan++ | src/ (3 files):
Add typecasts to correct 'comparison between signed and unsigned' warnings during build with both gcc and g++.
 02:25
kid51_ I'll nail some of them. 02:31
dalek rrot: 4158916 | jkeenan++ | frontend/pbc_merge/main.c:
[codingstd] Correct 3 lines too long for standard.
 02:35
rrot: 17d97e8 | jkeenan++ | frontend/pbc_merge/main.c:
[codingstd] No space before close paren.
kid51_ That leaves some c_args_assert and c_function_docs codingstd errors. 02:39
There are certain warnings thrown during a g++ build which, if corrected, violate our c_parens codingstd :-( 02:40
Namely: 02:41
warning: suggest a space before ';' or explicit braces around empty body in 'for' statement
But now we're down to only 8 warnings during a gcc build.
dalek rrot: d5eec7a | jkeenan++ | frontend/pbc_merge/main.c:
Amplify TODO comment with notation of warning being generated at that point.
 02:45
mikehh kid51_: will try and clear those up over the next day or so
kid51_ 3 of them are: no previous prototype 02:47
2 are: ignoring return value of '<function>', declared with attribute warn_unused_result 02:48
soh_cah_toa one of those is from a function i wrote a while ago before i knew how to use headerizer ;)
Parrot_new_from_type() or something like that 02:49
kid51_ Corrections welcome!
soh_cah_toa yeah, why not. i think i'll take care of that tomorrow afternoon 02:50
kid51_ thx
mikehh kid51_: will fix the remaining codetest failures after I have had some sleep, it's nearly 4 am for me (again) 02:56
soh_cah_toa you're nuts, man 02:57
dalek website: soh_cah_toa++ | Progress at Last! 03:00
website: www.parrot.org/content/progress-last
03:25 kid51_ left 03:35 hudnix left 03:38 bubaflub joined 03:43 cotto left
dalek rrot/soh-cah-toa/hbdb: 16a9177 | soh_cah_toa++ | src/runcore/cores.c:
Removed code for retrieving line numbers because it didn't work
 03:45
rrot/soh-cah-toa/hbdb: fc40dc7 | soh_cah_toa++ | / (3 files):
Defined INTERP_ATTR as a temporary fix for accessing Parrot_Interp fields
04:04 bubaflub left 04:14 bubaflub joined 04:37 soh_cah_toa left 04:41 bubaflub left 04:55 rohit_nsit08 joined 04:56 JimmyZ joined 04:57 rohit_nsit08 left 05:04 contingencyplan left 05:07 contingencyplan joined 05:18 plobsing joined 05:23 contingencyplan left 05:25 cotto joined
cotto ~~ 05:25
dukeleto cotto: exactly how much padding is there in the m0 bytecode header? 05:30
cotto: i want to store a sha256 sum in the m0 bytecode header, which is the sha256 of everything after the m0b header 05:31
cotto: that way, it will detect a mangled constant table, metadata or bytecode, which is better than only storing a checksum of the bytecode
cotto: does that sound reasonable to you? 05:32
sorear um, why only AFTER the header?
dukeleto sorear: where else do you store it?
sorear well it can't checksum itself, but there's no reason not to check the rest of the header 05:34
perhaps zero out the "checksum" byte range before passing the header to sha256sum
cotto dukeleto: on the phone. will respond in a bit
dukeleto sorear: sure, i can see some value in that. 05:36
cotto: the sha256 can be the first element in the header (after the magic number) and will contain the sha256 of the rest of the m0b file, for extra paranoidness 05:37
cotto: that will add 32 bytes to the header. Should we say that the m0b header will be 64 bytes, for definiteness? 32 for sha256, 6 more for version, register sizes + endianess, and the rest will be padding for now 05:39
cotto and back 05:48
dukeleto: I don't like hard-coding the hashing algorithm, and using something like sha256 can only protect against transmission errors. 05:49
dukeleto cotto: yes. 05:50
cotto dukeleto: what about a distinct checksum segment with a variable-sized checksum
?
also, I need to do some weeding in the header. I think m0b will always be little-endian unless there's a strong reason for it not to be,. 05:51
dukeleto cotto: what does a variable-sized checksum buy us?
cotto: i figure, we can change the m0b version if we want to change checksum algorithms
cotto dukeleto: different algorithms
dukeleto cotto: i don't see us needing to change algorithms. SHA256 being "broken" doesn't make it less useful as a checksum 05:52
cotto: if we wanted to digitally sign bytecode, then I can see the value of flexibility. But digitally signing stuff is a huge vat of worms. 05:53
cotto dukeleto: If we're trying to protect against transmission errors, we might as well use something really simple like crc.
dukeleto: agreed
dukeleto cotto: i forsee sha256 being useful for checksumming in the foreseeable future 05:54
cotto: i guess. we already have a pure-parrot sha256
cotto dukeleto: I don't care all that much. Having a single algorithm does have the advantage of guaranteed compatibility. 05:55
dukeleto cotto: yes. arbitrary algorithms sounds nice, but what is the point? Users just want to run the damn bytecode and not have it catch their computer on fire
cotto catching things on fire is generally underrated 05:56
dukeleto cotto: i am ambivalent to the algorithm. sha256 is just the most sofisticated checksum algorithm that we have currently, in a native parrot language
cotto: it is only computed once per bytecode generation 05:57
cotto: which isn't too often. So the performance of sha256 vs crc doesn't really come into play
cotto dukeleto: my point is that sophistication doesn't matter for the purpose we're proposing. If we use something really simple, nobody will get the impression that we're trying to provide security at that leve.
*level
dukeleto: quite true 05:58
dukeleto cotto: if you are going to rarely compute 1 checksum, it seems like sha256 is more future-proof
cotto dukeleto: what does "future-proof" mean?
dukeleto cotto: we can very loudly tell them that checksumming does not protect against maliciously crafted bytecode
cotto: sha256 has way fewer collisions than crc for large bytecodes 05:59
cotto dukeleto: do we care about collisions?
dukeleto cotto: well, a collision means that the m0 interp will think invalid bytecode is valid 06:00
cotto: and then run mangled bytecode 06:01
cotto: i want to make running mangled bytecode whilst thinking it is unmangled an extremely unlikely prospect
cotto: sha256 makes it many orders of magnitude less likely than crc
cotto dukeleto: in my mind, any checksum will do that.
dukeleto cotto: all checksums are not created equal 06:03
cotto dukeleto: I don't see this as being worth half the thought we're giving it. sha256 will work, let's go with it 06:04
though a pure-pir implementation doesn't mean that we won't need to find a separate C implementation between now and when we have a self-hosted M0 generator. 06:06
sorear dukeleto: I do not think it would be a good idea to "always verify", it would interact badly with OS lazy loading 06:07
dukeleto cotto: actually, verifying the checksum will require calculating it and verifying it once per bytecode load 06:09
cotto www.google.com/codesearch#xsttHqg0w...c/SHA256.c is in the public domain sha256 implementation we could use
dukeleto: either that or some smart laziness 06:10
dukeleto sorear: why so? lazy loading of bytecode? do we support that now?
cotto dukeleto: it's a nice feature. We shouldn't make it impossible. 06:11
dukeleto cotto: what does lazy bytecode loading mean? Only actually loading the bc when it is run? 06:12
cotto dukeleto: I interpret it as being akin to mmapped bytecode files 06:13
so yes
dukeleto cotto: when do you verify then? If not always, then you run the risk of running mangle bytecode, right? 06:14
cotto: "always" meaning once per bc load
06:15 davidfetter left
cotto dukeleto: Hmmm. Having mmapped files would let the OS solve the problem for us by allowing it to swap out unused pages after the checksum was calculated. 06:16
dalek rrot/m0-spec: 0eb454e | dukeleto++ | docs/pdds/draft/pdd32_m0.pod:
Add some updates about checksums
cotto If M0 code is run php-style, it'd be a meaningful cost.
(checksumming always)
maybe turn it on by default but allow it to be disabled 06:17
dukeleto cotto: sure. what is the use case for disabling? "trusting" your own bytecode doesn't mean your harddrive or a neutrino won't flip a bit
cotto dukeleto: it's an optimization with a minor cost for the case where you're running M0 on a heavily-loaded machine. 06:19
dukeleto cotto: sure. how to disable? command-line? 06:25
cotto dukeleto: it depends on how the M0 is run. 06:27
dukeleto: probably either that or an argument passed to the function that loads the m0b
dukeleto: can you think of any reason not to make the checksum optional in m0b? 06:35
sorear dukeleto: your harddrive already checksums every sector 06:40
dukeleto: IMO demand loading is the one way to get Rakudo startup times competitive with Perl5 (anything under 100ms won't be noticed by a casual user) 06:43
we can't reasonably expect to load 30MiB of bytecode in 1/10 of a second 06:44
dalek rrot/leto/embed_grant: 10e42d3 | dukeleto++ | t/src/extend.t:
Add coverage to Parrot_printf
 06:46
dukeleto cotto: git occasionally finds bugs in my encrypted filesystem layer. There are often many layers between the drive checksum and the end user 06:50
sorear: ^^^ 06:51
cotto: if the checksum is optional, will it be defaulted to on?
cotto: if it defaults to on, i am fine with it being optional. Otherwise, it will never get run. 06:52
cotto dukeleto: yes
I agree. People are rightly lazy.
06:54 dodathome joined
cotto dukeleto: consider yourself free to add the right Perl module dependency to the assembler and make it start calculating checksums. I don't have any pending changes atm. 07:03
07:21 fperrad joined 07:23 contingencyplan joined
cotto time for sleep 07:32
07:43 mj41 joined 07:59 mj41 left 08:01 mj41 joined
dalek rrot: 5d77384 | pmichaud++ | compilers/pct/src/PAST/ (2 files):
[pct]: Add a "childorder" property to PAST::Node to allow children
 08:27
09:12 jsut_ joined 09:17 jsut left 09:34 mj41 left 09:49 ligne joined 09:59 whiteknight joined
dalek p: 6a0f778 | pmichaud++ | / (3 files):
Make a common set of pir constants available.
 10:18
p: ce077cd | pmichaud++ | src/stage0/ (6 files):
Update bootstrap to get built-in includes.
p: 9d5b199 | pmichaud++ | src/PAST/Compiler-Regex.pir:
Convert first set of .CCLASS_* constants to remain symbolic in generated PIR.
p: c1aa27f | pmichaud++ | src/PAST/Compiler-Regex.pir:
Eliminate final .CCLASS_* non-symbol constants in regex code gen.
p: 67d1c79 | pmichaud++ | src/NQP/ (2 files):
Add pir::const::CONSTANT to NQP.
p: 285bf9f | pmichaud++ | src/stage0/ (6 files):
Update bootstrap to enable pir::const:: constants in NQP sources.
p: 8adbe89 | pmichaud++ | src/HLL/Compiler.pm:
Update some pir constants to use pir::const:: instead of Q:PIR.
p: c4d0afb | pmichaud++ | src/HLL/Grammar.pm:
Remove more extraneous .include's.
rrot: 6949470 | mikehh++ | compilers/pct/src/PAST/Node.pir:
fix codetest failure - trailing space and update copyright
 10:35
rrot: 25f7097 | mikehh++ | frontend/pbc_merge/main.c:
add missing c_function_docs (this could be expanded)
rrot: d2b5dcb | mikehh++ | frontend/pbc_merge/main.c:
add missing ASSERT_ARGS
11:24 fperrad left
mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_4_0-227-gd2b5dcb 11:40
Ubuntu 11.04 i386 (g++)
JimmyZ parrot never passes all tests here, because my windows username is chinese :( 11:42
moritz have you submitted a bug report?
JimmyZ yes 11:43
two years ago 11:44
moritz ah
JimmyZ TT #888 11:45
moritz even a three-digit track ticket 11:47
mikehh JimmyZ: you should try a Linux implementation, Ubuntu can be installed under Windoze
moritz that's totally the wrong approach
mikehh moritz: just to compare :-} 11:48
11:49 klavs joined
mikehh I know that we need to get the bugs out of our M$ implementations 11:49
I just don't have access to the platform 11:50
I gave up on it a few years back, and never regretted it
moritz trac.parrot.org/parrot/ticket/757 another all-time favorite 11:51
mikehh moritz: we seriously need work on out threads implementation, I keep getting intermittent failures in t/pmc/threads.t (not often, but it keeps happening) 11:55
11:58 klavs left 12:07 Eclesia joined
Eclesia hi 12:07
whiteknight hello Eclesia 12:08
ligne mikehh> that's what's so fun about concurrency bugs :-/ 12:10
i tried running parrot through helgrind and drd last week, which reported a load of "errors" 12:11
i've not had a chance to properly look through them to work out which are the root problems, which are just symptoms, and which are false positives 12:12
12:23 kid51 joined
Eclesia I update the source code, looks like the 'make reconfig' doesn't exist anymore 12:24
has it been renamed ?
12:25 mj41 joined
kid51 It does exist (line 2417 config/gen/makefiles/root.in), but its function may have changed. 12:27
What are you attempting to do?
Eclesia kid51: update and build everything 12:28
I noted thoses commands before :
git pull make realclean make reconfig sudo make install
kid51 If you haven't built in some time, I recommend: 12:29
make realclean;git pull;perl Configure.pl;make;make test;sudo make install
Eclesia so it has changed ^^ 12:30
thanks I'll try that
12:33 mj41 left
Eclesia what is the git command for : hg revert --all --no-backup ? 12:35
12:35 ambs joined 12:42 hudnix joined
whiteknight Eclesia: "make realclean" deletes the makefile 12:42
Eclesia: so you won't be able to make anything after that 12:43
Eclesia: you can try "make clean", which does not delete the makefile, or you can realclean and then "perl Configure.pl"
kid51 But if you haven't built recently, then you probably should run Configure.pl anew in order to capture changes in the source code that creates the Makefile. 12:44
Eclesia ok thanks 12:45
12:58 preflex left 13:02 preflex joined
cotto msg soh_cah_toa Did you delete the line number code because it didn't ever work or because line numbers aren't reliable? 13:07
aloha OK. I'll deliver the message.
13:20 lucian joined 13:27 contingencyplan left 13:29 lucian left 13:30 lucian joined 13:48 Eclesia left 13:50 hudnix left
dalek sella: 76df310 | Whiteknight++ | src/include/FileSystem.winxed:
Quick include file for Filesystem
 14:03
sella: 3aa9f50 | Whiteknight++ | s (2 files):
Harness now relies on FileSystem for walking directories
whiteknight Eclesia: you can try "make clean", which does not delete the makefile, or you can realclean and then "perl Configure.pl" 14:26
....lolwat?
jnthn__ whiteknight: I seem to have caused a complexity explosion with the IMCC register allocator... 14:31
whiteknight jnthn__: doesn't surprise me
jnthn__: what's up?
jnthn__ whiteknight: Turns out generating an extremely large sub with loads of registers with very short lifetimes is...bad.
whiteknight how bad? what does it do? How many registers are we talking about?
jnthn__ Like, it takes more time for Parrot to compile PIR to PBC than it does for Rakudo to do Perl 6 => PIR :) 14:32
whiteknight ouch. how many registers? Can you replace it with either a single register or an array?
jnthn__ It's basically the "deserialization" code
whiteknight I'm pretty sure the register allocator runs in quadratic time or higher. It's not a "performance" algorithm 14:33
jnthn__ Rather than having load init blocks all over the place (as we do in master) we have one central block which builds up the environment.
whiteknight ok
jnthn__ Yes, it's quadratic...I read through what it's doing.
whiteknight I have to go afk for a bit. I'll be back later 14:34
jnthn__ Not quite sure what to do, anyway...
ok :)
14:35 bubaflub joined 14:45 rohit_nsit08 joined
rohit_nsit08 Coke_: hello, just read your mail 14:45
14:46 klavspr joined 14:50 bubaflub left 14:53 kid51 left 15:12 klavspr left 15:22 Coke_ is now known as Coke
Coke rohit_nsit08: are we both here at the same time? ;) 15:23
rohit_nsit08 Coke: hmm.. almost.
I'm here from last 1 hour I guess
Coke (I had sent the email from my mobile and was waiting for the beep back, and didn't get one.
rohit_nsit08 :-)
Coke so, I know you had some questions on Friday - anything left that still needs sorting out? 15:24
rohit_nsit08 Coke: ya, most of them were doubts in the confusing syntax of javascript and now resolved. 15:25
Coke: can u suggest me which features to proceed in starting and features that can take time so that I can do side work in studying them 15:26
Coke so all I had to do was be on travel? ;) 15:27
rohit_nsit08 I am writing a blog post on current situation and will post it tomorrow that will bring both of us in sync of what to expect in coming week
Coke (fyi, will@coleda.com is a google-hosted account. I'm also at wcoleda@gmail.com)
(just got your invite)
digging up email from friday.
rohit_nsit08 loll 15:28
corellascript parser is based on lalr(1) parsing algorithm. I have read about it from wiki ( very good description) do I need to go in details or that will do the job 15:29
basically it is a bottom up parsing with lookahead
Coke that's fine.
rohit_nsit08: there was talk at the beginning of doing blog posts at parrot.org - I see you have one at blogspot.com - is that your ``official'' blog for GSOC? 15:30
(if so, I can aggregate it to planet parrot)
rohit_nsit08 Coke: well that's my personal blog . If that can be the "official blog" I will be happy to do so 15:32
Coke will prevent you from having to re-post to parrot.org
rohit_nsit08 Coke: that will be good . thanks 15:33
I usually give brief information on parrot.org and a link to full post at blogspot
Coke ah, you do? then that's fine. 15:34
rohit_nsit08 actually it seems easy for me to post code snippets there
Coke (getting blogspot to give me a feed of just "parrot" label'd posts is a pain anyway.)
rohit_nsit08 Coke: I was getting into slight confusion by the use of "this" . I'm reading several sources and trying test codes on node to get it clear . can u suggest something ? 15:36
I know "this" refers to the object who own that function
Coke more the context that function is executed in, as i understand it; 15:37
let me see if I can find you a good reference on that (this) is hard to search in google...
rohit_nsit08 ya "this" property is defined in the functions context
usually at the end
Coke developer.mozilla.org/en/JavaScrip...ecial/this 15:38
which looks not at all helpful from an implementor POV, I guess. 15:39
rohit_nsit08 have a look at this. github.com/rohit-nsit08/corellaScr.../js.js#L18 . can u tell me what "this" is referring here to? 15:40
Compiler is a constructor function here and we are extending Compiler.prototype
my guess after analysing its working is that , "this" is referring to the object created from the Compiler constructor function 15:43
Coke hurm. that seems reasonable - I'm trying to parse it in my head right now. ;) 15:44
rohit_nsit08 ok
Coke yah, that looks correct. 15:52
do you have a JS test suite you're going to target? 15:53
(ugh. mozilla is still using cvs?) 15:54
rohit_nsit08 I am still searching for one. 15:55
btw Is there any way to debug code in nodejs?
Coke dunno - I've never used nodejs - but I can definitely check. 15:56
rohit_nsit08 nodejs provide one utility but that gave errors on my system 15:57
that was node-inspector
Coke building node now, but found this: stackoverflow.com/questions/1911015...plications 15:58
which points to the chrome developer tools.
rohit_nsit08 was on the same link ;-) 15:59
Coke ;()
er, ;)
ugh. wish I could still ssh into my home machine - makes it easier to decide where to install stuff for GSOC so I can run it all the time. 16:00
rohit_nsit08 hmm that will be good. btw I've found an eclipse plugin for v8 which can be used to debug scripts 16:01
Coke excellent.
rohit_nsit08 seems a good one , have a look github.com/joyent/node/wiki/using-...s-debugger 16:02
Coke aye.
16:05 hudnix joined
rohit_nsit08 this is the current codegenerator that compiles javascript to javascript itself. I went through winxed's source to see how it emit PIR code as winxed is similar in syntax to javascript. basic things like variable declarations and comments and arithmetic operations are easy to go with. My doubt is regarding functions and scopes. Is my Approach correct or I should follow any other way round? 16:08
github.com/rohit-nsit08/corellaScr...codegen.js
Coke reading 16:09
rohit_nsit08 ya, sure.
Coke er, I see no PIR there - can you describe what's going on? 16:10
rohit_nsit08 well I didn't updated it from sometime . rightnow the code u are seeing is converting javascript to javascript following the usual procedure of parsing , forming AST and then emitting code in new language which happens to be javascript in this case 16:12
Coke ah. so (per the TODO), need to change that to emit PIR instead? 16:13
rohit_nsit08 yup
that is the first part of project all about, getting PIR from it 16:14
and than compile whole compiler into pir and run that on parrot
Coke ok - there's 2 basic options I see here - either emit PIR directly, or emit PAST, and then use one of parrot's builtin tools to convert that (standard) format to PIR --- but I think generating PIR directly is more in line with winxed and with, e.g. partcl(-old). 16:15
rohit_nsit08 ya, winxed is directly generating PIR code, So I am trying to follow similar approach here as well
Coke I think that's reasonable, yah. 16:16
dalek rrot/leto/embed_grant: 43b575e | dukeleto++ | t/src/extend.t:
[t] Parrot_fprintf
rohit_nsit08 for getting PAST, I think I'll have to go through some 1000 lines of parser's code , I have gone through all of it. still learning something new everyday :-) 16:17
getting PIR seems to be a slightly better as I have separate codegenerator functions for eveery node, 16:18
rightnow I'm trying to see how the functions and scopes are being implemented 16:19
Coke there are some things that past->pir step would take care of for you, but no showstoppers.
rohit_nsit08 I have less idea about past, which things? 16:20
I'll keep them in mind for possible problems in getting direct PIR . 16:21
16:23 lucian left
Coke well, if you're doing, e.g. a loop that executes code, past will handle serializing inner code blocks into ``anonymous'' sub blocks for you. 16:25
since in PIR, there isn't a block, just a sub.
but a most of it just convenience - winxed and partcl do fine without it, so can you.
rohit_nsit08 ya, I was thinking about the advanced features of javascript. hope they won't pose any problem. One more thing I wanted to ask was that like winxed runs on parrot and takes input from the file. winxed has a frontend for that file handling . and I think corellaScript also needs to have that feature so will that be implemented in PIR itself later or do I need to do that in current stage? 16:28
Coke I think you can do it in PIR for now, and perhaps move it to JS later. 16:30
rakudo does that a lot - start with stuff in PIR (maybe wrapped in a little NQP), and move it to Perl 6 when more of the work is done.
rohit_nsit08 ok. I think that was all to be discussed for now. and It will be great if u can pull and test any code pushed by me so that I can improve further. did u setup nodejs and pulled corellascript from github ? I can post all the details of corellascript on a blog post to have better collaboration 16:35
Coke I have grabbed both from git. a quick and dirty "here is how you run corellascript" will be great for not only me but other interested parrot folks.
even just in the top level README (though a blog post will get you more visibility) 16:36
rohit_nsit08 ya I'll do it tomorrow morning for sure 16:37
Coke dahnyawaad. (pardon my horrible transliteration) 16:39
rohit_nsit08 loll that's fyn 16:40
dhanyawaad
Coke ;)
one of the things they talked about in our big global tax meeting was cultural awareness - since I am horrible on the timezones, apparently, trying to make up for it in language. ;) 16:41
rohit_nsit08 hmm... nice 16:42
Coke good luck this week - I'll be at my office, so on a much more regular schedule, and able to respond to email/irc much faster. 16:43
(plus I was in a big rush this last month to get stuff done for the con last week, which is now over.) 16:44
rohit_nsit08 thanks for the meeting.. I will read some more about "this" from the source u gave . cheers ;-)
bye
Coke cheers!
16:45 rohit_nsit08 left 16:54 fperrad joined 17:02 bubaflub joined, kid51 joined 17:05 JimmyZ left
benabik Ack! Changes in PAST in master! 17:15
sorear benabik: bind_6model & company? 17:27
kid51 Referring to ?: git show 5d77384daf09
17:28 benabik left
kid51 msg pmichaud Are there any tests which ought to accompany commit 5d77384daf09? 17:28
aloha OK. I'll deliver the message.
17:30 klavspr joined, benabik joined
benabik sorear, kid51: There's a set of them: f2c7baf, 197f878 and 5d77384 17:38
17:38 whiteknight left
benabik I don't mind it too much, just wasn't expecting it. Will put porting the changes over on top of my TODO list. 17:38
kid51 msg pmichaud Also, should there be tests for f2c7baf and 197f878? Pls. touch base with benabik, whose GSOC project touches this area. Thanks. 17:42
aloha OK. I'll deliver the message.
17:44 klavspr left
dalek rrot/leto/embed_grant: 5983b8d | dukeleto++ | t/src/extend.t:
Add coverage to Parrot_eprintf
 17:48
rrot/leto/embed_grant: 9b318f4 | dukeleto++ | t/src/e (2 files):
Properly add coverage to Parrot_free_cstring
17:48 bubaflub left
dalek rrot: 43b575e | dukeleto++ | t/src/extend.t:
[t] Parrot_fprintf
 17:50
rrot: 5983b8d | dukeleto++ | t/src/extend.t:
Add coverage to Parrot_eprintf
rrot: 9b318f4 | dukeleto++ | t/src/e (2 files):
Properly add coverage to Parrot_free_cstring
rrot: 5915303 | dukeleto++ | t/src/e (3 files):
Merge branch 'leto/embed_grant'
17:57 lichtkind joined
lichtkind greetinings 17:57
dukeleto lichtkind: howdy 17:59
lichtkind is the parrot logo under a free license?
i would like to include it in a article about perl
is there anyone that maybe know an answer? 18:03
i would like to write a mail to parrot org, but cant find an adress on the site 18:19
dalek rrot/nqp_pct: 099bc50 | benabik++ | compilers/pct/src/PAST/Compiler.pm:
War on Q:PIR - PAST::Compiler.call

Once again, kept the PIR for the multiple returns.		 18:22
kid51 lichtkind: See LICENSE in the Parrot distribution. 18:42
Artistic License v2.0 18:43
github.com/parrot/parrot/blob/master/LICENSE 18:44
lichtkind: You can post more extensive questions to parrot-dev@lists.parrot.org 18:46
dukeleto lichtkind: i am pretty sure it is under a free license 18:53
lichtkind: where will the article appear?
lichtkind thank you thats what I need 18:54
dukeleto lichtkind: you can send an email to legal@parrot.org for questions, if needed
lichtkind: and cc parrot-directors@lists.parrot.org too 18:55
lichtkind: are you using the new parrot logo, or the older?
lichtkind dukeleto: maybe you write these adreses also on the page
i dont know an difference
i would just grab that from parrot.org/foundation 18:56
dukeleto lichtkind: sounds fine. Please send an email to parrot-dev with a link to your completed article :) What language will the article be in? 19:01
kid51 dukeleto: legal@ aliases to parrot-directors@, so sending a message to legal@ suffices for both (and means less work for the list moderator ;-) ) 19:03
dukeleto kid51: sounds good. I forgot that they were the same 19:12
19:40 klavs joined 19:45 klavs left
cotto ~~ 19:49
seen soh_cah_toa 19:50
aloha soh_cah_toa was last seen in #parrot 16 hours 53 mins ago saying "you're nuts, man".
lichtkind dukeleto: its in german and mostly about history community and philosophy of perl, its just a section about perl 6 where is parrot mentioned with 2,3 sentences 19:59
dukeleto: it will be in next month issue of freiesmagazin.de
does enyone know the author of that image? 20:01
20:01 klavs joined
lichtkind (oft he parrot logo) 20:01
20:03 klavs left
cotto lichtkind: good question 20:05
lichtkind also good answer? :) 20:13
cotto don't have one of those 20:14
allison: ping
20:42 pjcj left 20:43 kid51 left, soh_cah_toa joined 20:44 dodathome left
soh_cah_toa ~~ 20:45
cotto: i deleted the line number code b/c line numbers were unreliable 20:48
mikehh All tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_4_0-236-g5915303 20:49
Ubuntu 11.04 i386 (g++ --optimize)
cotto soh_cah_toa: ok. I think you should keep it. It's unreliable now, but you're not the only one who's annoyed by that problem.
mikehh especially if there are macros involved 20:50
20:50 contingencyplan joined
cotto mikehh: especially if imcc's involved 20:51
soh_cah_toa to be honest...with the problems i was facing, i don't see how i could ever break at line numbers
cotto I can see why you'd think that. 20:52
mikehh cotto: well of course, that too, but that's not just line numbers :-}
dalek p: c0d2879 | jonathan++ | src/NQP/SymbolTable.pm:
Add extra PAST::Stmts nodes to better delimit steps, to allow better code generation.
 20:53
cotto soh_cah_toa: I'm looking at hbdb.h atm. I think you'd get better laziness and the same amount of documentation if you put comments about enum/struct members inline instead of duplicating them before the definition. 20:54
it'd also be more consistent with the rest of Parrot 20:55
I'm glad you've got them there.
soh_cah_toa yeah, you're right 20:56
i just have a patch i need to take care of first i promised kid51 last night
cotto soh_cah_toa: you should delete t/hbdb/main_*c and add that to .gitignore. Those files are leftovers from t/hbdb/main.t and shouldn't be left around. 20:57
20:57 pjcj joined
soh_cah_toa i forgot that was even there 20:58
sure
cotto soh_cah_toa: is the build working for you? 20:59
soh_cah_toa i still have that issue w/ Parrot_Interp/Parrot_PMC 21:00
that assignment that was causing the error...i'd actually like to most it into hbdb_init() and have it take an hbdb_t argument
cotto ok.
soh_cah_toa but that was causing serious errors 21:01
something about imcc. way off
but it may be b/c of the Parrot_Interp/Parrot_PMC thing again
cotto soh_cah_toa: if you're depending on a particular PMC's header, you need to add that dependency to root.in 21:02
soh_cah_toa a pmc's header? 21:03
cotto include/pmc/pmc_foo.h 21:04
soh_cah_toa oh, header file. yeah ok
21:07 ambs left
dalek p: c7bf530 | jonathan++ | src/HLL/SerializationContextBuilder.pm:
Detect whether we're in pre-compilation or run-right-away mode and only code-gen the things we need. Quite a notable speedup for NQP tests; can always put it back if we need to debug it, but problems with this have been pretty rare.
 21:09
cotto soh_cah_toa: a missing semicolon on src/hbdb.c +288 is breaking the build atm 21:10
with that it completes
soh_cah_toa really? let me look
21:11 fperrad left
soh_cah_toa cotto: something's wrong. line 288 is just a while statement 21:12
cotto soh_cah_toa: those need to end in semicolons too. 21:13
soh_cah_toa ah, damn. i always forget that w/ do-while's 21:14
21:41 PurityControl joined
dalek rrot: c4fc9f8 | soh_cah_toa++ | / (4 files):
Fix for compiler warning that parrot_pmc_new_from_type() did not have a prototype
 21:41
rrot/soh-cah-toa/hbdb: db323dd | soh_cah_toa++ | src/hbdb.c:
Added a missing semicolon that was breaking the build
 21:43
21:46 Patterner left, PurityControl is now known as Patterner
soh_cah_toa msg kid51 i took care of that compiler warning about parrot_pmc_new_from_type(). see commit c4fc9f8 21:48
aloha OK. I'll deliver the message.
21:57 PacoLinux left 22:11 kid51 joined 22:22 whiteknight joined
nopaste "kid51" at 192.168.1.3 pasted "We're down to 8 warnings during gcc build" (8 lines) at nopaste.snit.ch/51545 22:23
soh_cah_toa great
some of those seem like an easy fix too 22:24
lichtkind cotto: allright so I write a mail 22:28
dalek TT #1979 closed by jkeenan++: Configure.pl --without-extra-nci-thunks fails tests. 22:29
TT #1979: trac.parrot.org/parrot/ticket/1979
TT #2116 closed by jkeenan++: t/library/nciutils.t fails on a plain parrot
TT #2116: trac.parrot.org/parrot/ticket/2116
TT #2118 closed by jkeenan++: t/src/checkdepend.t fails when extra nci tthunks are disabled
TT #2118: trac.parrot.org/parrot/ticket/2118
cotto lichtkind: ok. I suspect that it's allison but I don't know for sure.
lichtkind: why do you ask?
lichtkind because the editor says we need author and license to publish 22:30
cotto ah
benabik If it's in parrot.git, isn't it owned by PaFo? 22:42
lichtkind benabik: therotically yes :) 22:44
whiteknight if it's in parrot.git, PaFo has certain rights to the content 22:53
but PaFo doesn't "own". PaFo isn't the author 22:54
PaFo has the right to use, to distribute, to sublicense, and a few other rights for the content. It's all in the CLA
ligne kid51> i think the warning about undefined data_cursor is because it's getting post-incremented twice in a single logical line. 22:56
whiteknight oh, I thought I pushed my fix for that 23:07
I guess not
all that code probably needs to just be deleted at this point, I can't make it work 23:08
dalek rrot: 338f2a8 | jkeenan++ | src/platform/generic/file.c:
Name of file in POD NAME section was incorrect; fixed.
 23:10
benabik whiteknight: Your work on pbc_merge?
lichtkind good night 23:39
23:41 contingencyplan left

Powered by Cro and the Raku® Programming Language.

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

Thank you!