Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today
Set by moderator on 17 May 2011.
tcurtis ~~ 00:03
00:22 kid51 left 00:26 hercynium left 00:30 kid51 joined
kid51 msg Tene Please take a look at trac.parrot.org/parrot/ticket/88 00:35
aloha OK. I'll deliver the message.
00:47 jsut joined
mikehh kid51: I was getting a failure earlier with t/tools/dev/headerizer/01_functions.t - Failed test: 51 00:47
the change in the re on line 455 of lib/Parrot/Headerizer/Functions.pm is responsible for the error 00:48
t/tools/dev/headerizer/01_functions.t gets 'PARROT_ASSERT_ARG(( _abcDEF123 )' wants 'PARROT_ASSERT_ARG(_abcDEF123)' from 'ARGFREE_NOTNULL(( _abcDEF123 )())' 00:50
00:50 lucian left
mikehh line 460, fails line 471 of t/tools/dev/headerizer/01_functions.t 00:50
pmichaud yes, the problem was a caching proxy 00:52
I'm able to access trac now
00:52 jsut_ left 01:25 woosley joined 01:30 woosley1 joined 01:33 woosley left 01:39 bubaflub left 01:43 woosley1 left
cotto ~~ 01:51
kid51 mikehh: Can you discuss that with alester/petdance? 01:53
mikehh: I can't remember all the details of that test right now. 01:54
It may be as simple as changing the test to match the new expected output.
afk 01:55
01:59 theory joined
cotto soh_cah_toa, how's it going 02:01
soh_cah_toa cotto: well, i made a branch but i can't seem to track it w/ a remote 02:02
all i did was 'git branch soh-cah-toa/pdb'
cotto does git branch tell you that you're on that branch? 02:03
soh_cah_toa yeah
oh wait, i did a checkout -b. sorry
cotto ok. That's what I usually do. 02:04
What's the problem? 02:05
soh_cah_toa 'git checkout -b soh-cah-toa/pdb origin/soh-cah-toa/pdb' complains: 02:06
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'frontend/pdb/origin/soh-cah-toa/pdb' which can not be resolved as commit?
02:07 theory left
cotto is there an origin/soh-cah-toa/pdb? 02:07
or are you starting a new branch
soh_cah_toa i don't know. i'm just doing what docs/project/git_workflow.pod said to do 02:08
cotto You just want to create a branch. You can push it later. 02:09
soh_cah_toa alright. so i have a new branch then 02:10
kid51 git checkout -b soh-cah-toa/pdb ... should suffice
soh_cah_toa kid51: yeah
cotto: you mentioned that i had to modify interpreter.h. well, i was looking around and cores.c doesn't #include this file yet it uses the constants defined in it. how is that possible? 02:16
oh wait...i think it's included indirectly using parrot/embed.h 02:17
cotto soh_cah_toa, yes. It's included indirectly. 02:18
I don't recommend tracing it out unless something goes wrong.
There are more interesting ways to spend your time. ;) 02:19
soh_cah_toa well, i wasn't sure how to include it w/ my runcore
cotto soh_cah_toa, you don't need a new file. Just use cores.c 02:21
soh_cah_toa yeah but the code in functions like Parrot_runcore_fast_init() uses things i need in those headers
i was just copying the functions i needed 02:22
cotto Ah. That should be accessible after you run headerizer
soh_cah_toa h/o...so if i call a function defined in a header that i didn't include, headerizer will #include it for me? 02:23
cotto not quite
soh_cah_toa agh...i knew it was too good to be true :) 02:24
cotto headerizer looks at the functions you have defined and puts their prototypes in the right places
either headers or at the beginning of the file where they're defined
soh_cah_toa hmm...ok 02:26
cotto: how can i make it so that you can see my branch? i wanna make sure i did this right so far 02:37
cotto soh_cah_toa, do you have a fork of parrot on github? If so, git push origin branchnamehere should work 02:39
my brain am tired 02:40
soh_cah_toa alright, i'll try that
wait...i made this branch off of parrot/parrot though 02:44
should i re-branch from my github fork? i'm not too sure of the difference between github forks and git branches 02:47
cotto I don't think that'll be necessary. 02:48
soh_cah_toa alright but i don't think i can do a 'git push origin soh-cah-toa/pdb' w/o a commit bit
cotto right
benabik soh_cah_toa: You should bee able to do something like `git remote add github github_URL` 02:49
02:49 bubaflub joined
soh_cah_toa benabik: ok 02:49
hmmm...it seemed to work but i'm not seeing anything on github 02:52
benabik soh_cah_toa: You then can `git push github branch`. Adding the remote just adds the shortcut. 02:53
cotto looks like your clone got updated
soh_cah_toa i did 'git push github' and then tried 'git push github soh-cah-toa/pdb'
cotto er, fork
benabik I do see a soh-cah-toa/pdb branch on github 02:54
soh_cah_toa benabik: branch from parrot/parrot.git or soh-cah-toa/parrot.git? 02:55
kid51 parrot.org/content/i-think-its-time-break : A well-written blog post
cotto soh_cah_toa, looks like you did something
soh_cah_toa kid51: thanks
02:55 mtk left
benabik soh_cah_toa: In soh-cah-toa/parrot.git 02:55
soh_cah_toa hmm...
kid51 I will have to re-read it as it is showing me things about debuggers I never knew.
02:56 kid51 left
soh_cah_toa well, i see my commit w/ 'git log' but nothing on github. parrot/parrot or soh-cah-toa/parrot 02:57
cotto soh_cah_toa, it 02:58
's there. Look at your branch.
soh_cah_toa github.com/soh-cah-toa/parrot
there?
cotto github.com/soh-cah-toa/parrot/comm...d415b253b1 02:59
soh_cah_toa b/c that's what i'm looking at
cotto or github.com/soh-cah-toa/parrot/comm...-toa%2Fpdb
soh_cah_toa oh yeah. wow, that took longer than usual 03:00
cotto btw, I'd recommend against the name "pdb". It has collisions with other debuggers. 03:01
soh_cah_toa yeah, i was worried about that
cotto that's why we have "parrot_debugger"
03:02 mtk joined
soh_cah_toa parrot_debugger seems like too long though. plus i kinda like one word commands w/ no underscores/hyphens 03:02
if i have too, i will though
cotto I appreciate the laziness, especially since you'll be typing it often.
soh_cah_toa i'm i KISS type of guy
cotto keep it stupid, stupid? 03:03
;)
soh_cah_toa ha
if i went the other route of making up a unique name (maybe a bird name, keeping things close), then people may not realize that that's the debugger 03:05
hmmm...decisions...
cotto "debugger_for_parrot_programs" 03:06
soh_cah_toa no confusing that w/ anything else
benabik d4pp? 03:07
soh_cah_toa numbers in an acronym?! agh! 03:08
cotto this isn't php
soh_cah_toa you will soon see that i am very anal about style conventions
i have an extreme hatred of things like camel case
i like old school unix style naming conventions short and hard to tell what it stands for 03:09
like strpbrk 03:10
03:10 particle left
cotto perfect. 03:10
ship it
soh_cah_toa actually, i was talking about the c function :) 03:11
how its hard to tell what it stands for. lol
03:11 particle joined
soh_cah_toa i've searched far and wide and still don't know what strpbrk() stands for 03:12
anyway, i digress. does my code look ok? i don't think headerizer did anything 03:13
cotto soh_cah_toa, I'd put the runcore code in src/runcore/cores.c with the other similar code. The frontend doesn't need any special access to decide which runcore to use. 03:14
soh_cah_toa i just put it there b/c the old debugger was there. i'll fix it 03:15
ahh...alright. things are starting to make a little more sense
cotto note that the old debugger only has main.c in frontend/
soh_cah_toa right. now i see that even though i may have my own runcore, parrot still needs to "know" about it 03:17
cotto I'm glad it's starting to make sense.
sorear soh_cah_toa: I'm pretty sure strpbrk dates from the times when only the first 6 characters in function names were significant 03:18
soh_cah_toa sorear: right 03:20
cotto That was before people had spent decades looking at "creat"
soh_cah_toa agh! don't get me started
they couldn't just add the extra e?! just one little e?!
cotto There's a funny commit to "go". 03:21
code.google.com/p/go/source/detail?...3c480d995f
soh_cah_toa ha! 03:22
tcurtis soh_cah_toa: stackoverflow.com/questions/500994/...for/501007
soh_cah_toa tcurits: string pointer break? what the heck does that have to do w/ string searching? nothing's "breaking" 03:23
cotto: that reminds me. i wanted to mention go. there's been lots of talk about concurrency and i've heard that go implements concurrency quite well. i was wondering if anybody had ever considered looking at go for guidance 03:25
cotto soh_cah_toa, I don't think there's any place we're not glad to steal good ideas from.
Whether someone's tried I'm not sure. 03:26
tcurtis soh_cah_toa: I believe the idea is that when you see one of the characters, you stop searching or "break".
soh_cah_toa cotto: i should probably mention it to whiteknight 03:27
cotto soh_cah_toa, sure. If you have a more concrete suggestion, even better.
soh_cah_toa tcurtis: hmm...it's a far stretch but i can see it
cotto he's a busy fellow
soh_cah_toa yeah, no kidding
bubaflub note to GSoC-ers, all the tax paperwork is due to Google tomorrow 03:29
soh_cah_toa bubaflub: already done. proof of enrollment too
bubaflub soh_cah_toa++
it's not a big deal if it's not in, it'll just delay the initial payment till the mid-term 03:30
dalek website: bubaflub++ | Introducing Parrot-GMP
website: www.parrot.org/content/introducing-parrot-gmp
soh_cah_toa bubaflub: you're a gsoc student too, right?
bubaflub soh_cah_toa: yep
soh_cah_toa: just uploading my tax forms 03:31
tcurtis soh_cah_toa: quite a stretch, but well... 6 character guaranteed significant in external identifiers doesn't give you a lot of room for self-descriptive names.
soh_cah_toa tcurits: yeah, there is a bit of a trade off
sorear yeah, naming all your external identifiers Parrot_api_x_y_z is a non-starter 03:32
soh_cah_toa bits tongue very hard
cotto: is it worth making my own runcore if it's just an exact copy of the fast runcore? i mean, will i be making a customizations the runcore that make it distinct from the fast runcore? 03:36
cotto soh_cah_toa, you'll definitely be making customizations.
soh_cah_toa cotto: ok 03:37
sorear why? 03:40
soh_cah_toa sorear: why what? 03:41
sorear why to cotto.
cotto sorear, he'll need a custom runcore so the debugger can implement breakpoints and other debuggery things 03:42
soh_cah_toa cotto: ok, i think i got it right this time. you tell me 03:48
cotto looks
soh_cah_toa, looks about right 03:49
soh_cah_toa cotto: good
cotto did you get headerizer working or did you add the function declarations manually?
soh_cah_toa cotto: headerizer
cotto good. It can be fiddly sometimes but overall it's better than doing that stuff manually. 03:50
soh_cah_toa cotto: definitely
cotto: btw, is it alright if i msg you will you're at work. i don't wanna distract you too much 03:51
*while 03:52
cotto soh_cah_toa, I'll let you know if I'm too busy. I'm fortunate to work at a very oss-friendly company.
As long as I get what I need to do done, they don't mind if I do some parrot stuff. 03:53
soh_cah_toa cotto: that's really awesome
cotto If the main language weren't PHP it'd be perfect. 03:54
as it is, it'd still take something really amazing to lure me away 03:55
soh_cah_toa cotto: that's so cool. that's definitely my #1 requirement for a job once i'm finished w/ school: foss-friendly 03:56
cotto: another thing...i never know when to msg "cotto" or "cotto_work". i seems like you're always on both. does it matter which i msg? you're in a different time zone than me so i don't know when you're working 03:57
cotto soh_cah_toa, GSoC will help then. The good companies will look favorably on GSoC. 03:58
soh_cah_toa, I have both irc clients blink for both names. If you ping one here and I'm around, I'll see it.
tcurtis was surprised by how impressed $dayjob seemed by GSoC when he interviewed for it. 03:59
cotto It's good experience with a real software project and effectively demonstrates a certain level of competence. 04:01
sorear maybe next year I'll get in... 04:02
soh_cah_toa i don't think there's any downside to gsoc
sorear cotto: I take objection to the idea that breakpoints require a custom runcore
tcurtis sorear: did you apply for it this year? 04:03
sorear tcurtis: no, couldn't find a project
cotto sorear, what would you suggest? There are certainly other possibilities.
sorear cotto: using the fast runcore
cotto sorear, but what tells the interp when to break? 04:04
sorear same thing that every real debugger uses
a "breakpoint" opcode
soh_cah_toa yes!
04:04 silug left
sorear which generates some kind of resumable control exception 04:05
and/or hands control to a different interp a la parrot-instrument
we *do* need a special function that can single-step a context 04:06
soh_cah_toa agh...i so wanna be a part of this conversation but i really gotta head off. i'll just check out the irc log tomorrow. cotto, that's the other thing i wanted to talk about - a debug opcode. we'll talk tomorrow. hasta la pasta! 04:10
04:10 soh_cah_toa left 04:23 bubaflub left
sorear cotto: other than the runcores themselves, does anything in Parrot want to parse Packfile_Segments in memory? 04:28
pbc_merge and pbc_disassemble don't count because they work only on .pbc files, and the debugger won't modify those
cotto sorear, why do you ask? 04:36
and by "parse in memory", do you mean parse the contents of a pbc? 04:38
04:40 fperrad joined 04:43 fperrad_ joined 04:47 fperrad left, fperrad_ is now known as fperrad 04:57 jevin left 04:58 jevin joined
sorear on second thought, it doesn't matter 04:58
with x86 debuggers, it's conventional to overwrite the first byte of an instruction (of unknown length) with 0xCC, and leave the rest as invalid opcode data 04:59
but with Parrot it wouldn't be unreasonable to overwrite an n opcode_t instruction with n copies of the breakpoint opcode 05:00
cotto It seems easier to have a specialized runcore.
I don't see the advantage of overwriting opcodes. 05:01
I guess it'd be handy if you didn't want to switch runcores or had a running program you wanted to debug. 05:02
sorear that, and it's much faster 05:07
no overhead in breakpoint-free code
if you use a custom runcore, you need a *fast* set data structure to remember where the breakpoints are set 05:08
05:11 fperrad_ joined
dukeleto ~~ 05:13
05:13 fperrad left, fperrad_ is now known as fperrad
cotto hi dukeleto 05:15
dukeleto cotto: howdy
cotto: what are you up to? 05:17
cotto dukeleto, looking at M0 ops and trying to figure out what I was thinking. 05:19
05:19 fperrad left
cotto also looking at how parrot parses cli options and thinking about how to turn it into something reusable 05:20
dukeleto, I'm thinking that mapping a chunk name to a chunk number should be a separate operation from transferring control flow to that chunk. 05:26
Is that sane, and if so what'd be a good name for the op? 05:27
05:29 fperrad joined
sorear Why? 05:30
05:31 theory joined
dukeleto cotto: why should it be a seperate operation? 05:32
cotto: what is the use case?
Tene cotto: explain more about what you're trying to do with cli options? 05:34
cotto dukeleto, my assumption was that a chunk index would be the primary means of indicating which chunk control flow should be transferred to. That may not be necessary. 05:36
Tene aloha: msg kid51 I'll try to do that this weekend.
aloha Tene: OK. I'll deliver the message.
cotto Tene, I'm thinking about how to make a separate frontend for parrot that knows about profiling-specific options and passes anything else to the normal frontend.
05:36 theory left
cotto dukeleto, it actually might make more sense to say that chunk indicies are an implementation detail and that names are the only way to find a chunk. 05:38
dukeleto cotto: i think i like that chunks are identified by their globally unique name only 05:39
cotto: and, during parsing, we bomb out if a chunk name is not unique
sorear cotto: I think you have a combinatorial explosion problem there 05:41
cotto: since we'll also eventually want options that are specific per GC core (nursery size, etc)
it would be better, I think, to have some kind of metasyntax like --gc-OPTION=VALUE, --run-OPTION=VALUE 05:42
cotto sorear, it's clunky but that might be the best option.
sorear -Rprof --run-output-file=/path --run-profile-insns=yes
cotto it's either that, separate frontends, environment variables or a config file 05:44
or a bunch of options that don't apply in all cases but still clutter up the namespace 05:45
a more general way of giving gcs and runcores specific options would be helpful 05:48
dalek rrot/m0-spec: 34d07ac | cotto++ | docs/pdds/draft/pdd32_m0.pod:
simplify goto_cs
 05:53
rrot/m0-spec: ef3e7cf | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add a note about chunk names
sorear cotto: consider -Rprof,out=/path,insns=yes 05:55
cotto sorear, I was thinking of something not too different from that 06:01
I still don't like the big long string of junk, but that's what alias is for. 06:02
sorear also think about how this will interact with fakecutables 06:05
hmm.
if we can make creating interps really cheap, then we could let fakecutables parse their own command line 06:06
cotto that meshes with whiteknight's eventual plan of moving option parsing to pir
sorear then Rakudo could implement S19 style ++PROFILER ++/PROFILER options and translate them
06:25 silug joined 06:30 fperrad_ joined 06:33 fperrad left, fperrad_ is now known as fperrad 06:40 fperrad left, davidfetter joined 06:43 fperrad joined 06:45 mikehh left 06:53 ShaneC joined 06:54 silug left 07:18 mj41 joined 07:28 baest_ joined 07:29 baest_ left 07:31 baest left
bacek ~~ 07:34
07:34 mikehh joined 07:49 rurban_ joined 07:50 baest_ joined 07:52 rurban left 07:53 rurban_ is now known as rurban
tadzik good morning 07:56
08:46 Kulag left
dalek TT #2119 created by mikehh++: t/tools/dev/headerizer/01_functions.t failure 08:58
TT #2119: trac.parrot.org/parrot/ticket/2119
09:29 silug joined 10:04 fperrad left 10:11 silug left 10:26 jsut_ joined 10:31 jsut left 10:42 mtk left 10:50 mtk joined 10:57 Coke left, Coke joined 11:02 Psyche^ joined 11:06 SHODAN joined 11:07 Patterner left, Psyche^ is now known as Patterner
dalek rrot: 6e704bd | NotFound++ | src/pmc/unmanagedstruct.pmc:
don't return NULL STRING* from vtable functions, use STRINGNULL
 11:08
11:22 lucian joined 12:12 whiteknight joined 12:20 mtk left 12:26 mtk joined
whiteknight good morning, #parrot 12:37
12:39 Kulag joined 12:40 silug joined
tadzik good afternoon whiteknight 12:48
whiteknight hello tadzik. how are you doing today? 12:55
12:55 ambs joined
tadzik not bad, Javacoding atm 12:58
whiteknight oh, fun
tadzik yeah, pretty much. Even more because I couldn't stand jUnit in TDD so I wrote my TAP-friendly package :) 13:03
13:04 theory joined 13:05 fperrad joined 13:13 bubaflub joined
benabik Good morning, #parrot! 13:13
benabik is finally done with finals! 13:15
bubaflub morning benabik 13:16
benabik: how did the finals go?
whiteknight msg cotto I'm without internet at home for at least a few days, so no hacking (that I can push) for a while. 13:17
aloha OK. I'll deliver the message.
benabik bubaflub: Pretty good, although I realized I made a stupid mistake on the way out the door. 13:19
bubaflub: Oh, and Rakudo people were discussing using GMP yesterday, so you already have people looking forward to your project. :-D 13:21
bubaflub benabik: cool. maybe i should hang in #perl6
13:49 theory left
lucian allison: ping 13:50
sorear hellloooo benabik ! 13:56
benabik helllooooo sorear!
whiteknight just had a total animaniacs deja vu moment 14:06
14:09 SHODAN left 14:10 davidfetter left 14:21 theory joined 14:43 theory left 14:44 davidfetter joined 14:58 theory joined
dukeleto ~~ 15:00
benabik++ # done with pesky skool stuff 15:01
dalek Heuristic branch merge: pushed 143 commits to parrot/leto/embed_grant by leto 15:03
cotto whiteknight, lame sauce 15:10
whiteknight cotto: tell me about it
I think the lawnmower guy cut the cable yesterday 15:11
why the cable was in a place that the lawnmower guy would have access to it, I don't know
atrodo whiteknight> efficiency 15:12
cotto hands whiteknight a roll of duct and MacGyver on DVD.
atrodo cable goes better when exposed to air
s/better/faster/
cotto er, duct tape
whiteknight I don't even know if it was the lawnmower guy or not. I only suspect it because of the timing
it could easily be something else weather-related
in any case, I was home yesterday most of the day without internet access, and have about two dozen commits that are unpushed 15:13
cotto whiteknight, you can use git bundle and a thumb drive
progit.org/2010/03/10/bundles.html 15:14
whiteknight yeah, I could do a lot of stuff
I'm thinking instead I might "go outside" and get some "sunlight"
things my wife always talks about, but never does either 15:15
cotto That's also a fine option.
15:18 dod left, davidfetter left
dalek nxed: r1015 | NotFound++ | trunk/examples/Mysql.winxed:
rearrange and improve encoding handling and add a command line option to specify
 15:19
website: benabik++ | GSoC 0: School's Out For Summer
website: www.parrot.org/content/gsoc-0-schools-out-summer
sorear cotto: did MacGyver ever have to deal with RF/microwave transmission lines? 15:21
whiteknight I think it's fiber optic 15:22
cotto sorear, probably
15:25 theory left 15:26 theory joined
cotto whiteknight, sorear had that idea that instead of having a specialized frontend for the profiling runcore, we should figure out a metasyntax that allows arbitrary options to be passed to specific subsystems (e.g. gc, runcore) 15:28
something like --Rprofiling:foo=buz:quux=frub 15:30
s/--// 15:31
s/--/-/
stupid fingers not cooperating
whiteknight we could do that. It sounds like a job that is extremely well suited to being written in PIR 15:33
although I have no idea how we would go about doing that
sorear I also had the idea that fakecutables could have a special "parse options" entry point, which is invoked in an "early interpreter", which then creates the "real interpreter" using a parrot-instrument like reflection API 15:34
15:34 mj41 left
sorear then cotto told me that whiteknight was already wanting to do argument parsing in PIR 15:34
whiteknight sorear: yes, we've kicked around that idea in the past as well
sorear: yes, I would love to do an entire entry program in PIR. like a _crt0 kind of function
we have tools in PIR for loading bytecodes, parsing options, handling exceptions etc. Right now we do all that in C and it's a bear 15:35
doing Parrot-related stuff in PIR is the most natural vector for it
look at the code in frontend/parrot/main.c, and tell me most of that crap wouldn't be much better written in PIR 15:38
instead of having a natural exception handler, we have to check every single API call for exceptional exit
cotto You could even cheat and only invoke a second interpreter if the first one gets passed something that needs to be fiddle with interp initialization 15:40
NotFound whiteknight: you can make it simpler by using Parrot_ext_try 15:42
cotto whiteknight, what kind of commits do you have at home?
dukeleto bubaflub: did you blog yet? 15:43
bubaflub dukeleto: yessir 15:44
dukeleto: www.parrot.org/content/introducing-parrot-gmp
dukeleto bubaflub++ 15:45
benabik++
a bloggin' we go
sorear The main worry I have is that if $USER needs to use $OPTION because in $SITUATION default interpreter initialization fails, we've got a problem
NotFound Thinking better about it, no, using Parrot_ext_try and functions available for etensions defeats the purpose of being purely embedding interface.
dukeleto bubaflub: suggestions: add links to your CPAN and github accounts in your blog posts that you mention 15:46
bubaflub: links makes the world go around
bubaflub dukeleto: i'll do that now
dukeleto bubaflub: and spell out GMP the first time
bubaflub: some people aren't math nerds like us :)
bubaflub dukeleto: poor people 15:47
dukeleto: er, not financially poor, but pitiable people
dukeleto bubaflub: lulz. Only professorial mathematicians take the vow of poverty. I am part of the 10% of mathematicians that reject that antiquated notion :) 15:48
bubaflub: good blog post. did you post to gmp-discuss ?
bubaflub dukeleto: yep. got my answers.
dukeleto benabik: i see you are a "cleaned up history" kind of dude :) 15:49
15:50 rurban_ joined
benabik dukeleto: `git rebase -i` is your friend. :-D 15:50
cotto sorear, can you think of an example? 15:51
dukeleto benabik: i use it lovingly, like a bar of soap...
sorear cotto: dunno, working around systems idiocy maybe 15:52
dukeleto bubaflub: looks like supporting GMP 4.2.x - 5.x is a good thing to shoot for
15:52 rurban left
bubaflub dukeleto: agreed 15:52
15:52 rurban_ is now known as rurban
dukeleto bubaflub: whoever wants it to work on 4.1.x can provide the small patch :) Don't worry about supporting old arcane versions. 15:52
sorear cotto: like say the next version of SELinux decides to disable our default runcore, and $USER wants to play with an old Parrot (from before we implemented workarounds on our end) 15:53
lucian begins to hate pmc2c
dukeleto in slightly un-related news, I slayd the dependency hobgoblin yesterday: github.com/bioperl/bioperl-live/co...60cdbaa5d6 15:54
lucian: welcome to the club?
lucian dukeleto: i'll leave my bike outside, wait a tick 15:55
dukeleto paints the bikeshed a new coat of clear 15:57
15:57 alester joined
whiteknight lucian: why hate pmc2c? 15:58
cotto whiteknight, why not?
whiteknight i mean, I have reasons why I hate it, but I'm wondering what other people think as well
sorear dukeleto: I don't get it, what was the problem? 15:59
lucian whiteknight: it's the majority of build time for me, i can't read it and it's a huge hack
dukeleto sorear: just old code that was written at a time where "Test::Warn" was too much of a dependency, but which is now included in the repo
lucian ah great, parrot doesn't build on osx anymore
cotto lucian, there's a tt for that 16:00
dukeleto sorear: nothing particularly amazing except a reason to write a funny commit message :)
cotto something about pcre?
lucian cotto: nope
cotto: gist.github.com/a4079d13d6cb4f93d383 16:02
cotto lucian, can you nopaste how it exploded?
bam
whiteknight lucian: looks like it's stumbling over an existing installed libparrot 16:03
cotto lucian, looks like you have an old version of libparrot somewhere
lucian hmm
benabik didn't expect to have to resolve a merge conflict first thing. Bleh.
lucian ah
cotto though when installing, the libparrot symlink should be updated to the version being installed
lucian ok, i removed the existing libparrot 16:05
same thing
cotto did Configure.pl spit out a warning about a possible conflicting libparrot? 16:06
lucian nope
cotto you might need to reconf
er, make reconfig 16:07
lucian gist.github.com/a4079d13d6cb4f93d383
dukeleto benabik: wouldn't rebasing and squashing just before a merge into master be the least amount of work?
benabik: i am still reading your blog post 16:08
benabik dukeleto: I was hoping to merge the last 5 months of work on master into nqp_pct to reduce surprises later.
dukeleto benabik: so you are starting with bacek++'s branch as a base and working from there? 16:09
benabik dukeleto: Yup.
dukeleto benabik: good blog post. exactly the kind of stuff we want to hear about
benabik: don't be shy about giving too many details :) 16:10
benabik dukeleto: I figured my blog would be an expanded version of a #ps DID/WILL DO/BLOCKERS report.
dukeleto benabik: so you will be rebasing like mad on your local branch and pushing to nqp_pct occasionally, which will be stable?
benabik: yes. Exactly.
benabik dukeleto: Yes. benabik/parrot/nqp_pct will be constantly rebasing on top of parrot/parrot/nqp_pct 16:11
bubaflub lucian: i'm going to try and build on Mac. are you building from HEAD?
lucian benabik: yeah
benabik lucian: what?
bubaflub benabik: probably meant for me. tab complete on b
lucian sorry, bubaflub
stop colliding on one char! :) 16:12
bubaflub lucian: yeah, my last build was 56 commits ago. i'm cleaning and building now
benabik Ah. (I'm only half-paying attention. Wife is in Spring Cleaning mode so I can't just sit in front of IRC.)
lucian ok, seems to be working now 16:13
we'll see if it finishes 16:14
bubaflub lucian: i just finished building off HEAD on Mac OS X 10.6.7
lucian: lemme know if it doesn't work, i'll help ya debug
cotto dukeleto, do you have any unpushed changes to the m0 assembler? 16:15
lucian bubaflub: great, my terminal crashed
lucian hates osx a little now
i thought osx was supposed to be faster and stabler than ubuntu 16:16
i get crashes and lag left and right ...
cotto dukeleto, nm. it's a trivial change
whiteknight hate leads to anger. Anger leads to Linux. Linux leads to the darkside
lucian whiteknight: :D
cotto not likely to cause any problems
dalek rrot/m0-spec: c4ca0f2 | cotto++ | docs/pdds/draft/pdd32_m0.pod:
rename goto_cs to goto_chunk
 16:17
rrot/m0-prototype: 3806816 | cotto++ | src/m0/m0_interp.pl:
implement goto and goto_if_eq
rrot/m0-prototype: 4ce8ab2 | cotto++ | src/m0/m0_assembler.pl:
rename goto_cs to goto_chunk in the assembler
rrot/m0-prototype: f292095 | cotto++ | src/m0/m0_interp.pl:
rename/implement goto_chunk
bubaflub lucian: i've been using iTerm2 on my work laptop for Mac... it has yet to crash for me 16:18
(also ZSH and screen for the win)
lucian bubaflub: i'm using visor, it's usually ok. everything just feels like fighting through sludge 16:19
bubaflub lucian: yeah, i used visor for a bit but sometimes it would leak memory 16:20
16:20 theory left
benabik lucian: In my experience OS X can really bog down on a lot of disk I/O. Parallel compile + Spotlight = lag. 16:20
dukeleto lucian: yes, that is the feeling of developing on OS X
lucian dukeleto: not just developing 16:21
i mean this has a dual core 2.4ghz intel and it's a bit laggier than my 800mhz arm netbook
haha 16:25
Configure.pl made a folder called ~ in my parrot folder
dalek rrot/m0-prototype: 6e46928 | cotto++ | src/m0/m0_interp.pl:
finish implementing goto_chunk
 16:26
16:28 theory joined
dukeleto lucian: that is called the "It Didn't DWIM" folder ;) 16:30
16:30 jsut joined
dukeleto lucian: a feature coded by Steve Jobs himself 16:30
lucian my linux netbook did the right thing 16:31
benabik Hm. "load_bytecode" couldn't find file 'nqp-setting.pbc' 16:35
16:35 jsut_ left, theory left 16:36 theory joined 16:37 theory left
dalek rrot/m0-spec: f977cde | cotto++ | docs/pdds/draft/pdd32_m0.pod:
add CHUNK register, leave space for future changes
 16:48
rrot/m0-prototype: 16d4851 | cotto++ | src/m0/m0_interp.pl:
simplify a context's pc, add a way to get the current chunk's name
rrot/m0-prototype: 8c37cca | cotto++ | src/m0/m0_assembler.pl:
update register numbers in the M0 assembler
16:50 contingencyplan left
lucian i don't get parrot's fakecutables. what's their purpose? 16:51
dukeleto lucian: dressing up PIR/PBC as an executable 16:52
lucian: so you can ./ it
lucian but why? you could just do #! for text or that other thing for binary
dukeleto lucian: wraps PIR/PBC into a C program that executes embedded bytecode, basically
lucian the one mono and wine use
16:52 contingencyplan joined
dukeleto lucian: some dumb operating systems don't have shebang lines 16:52
lucian and is it important to have executables there? python doesn't bother 16:53
dukeleto lucian: the portability gods are fickle
lucian nor does any other language i can think of
dukeleto lucian: parrot isn't python :)
lucian: parrot does sacrifice many goats to our portability gods 16:54
whiteknight lucian: is it hurting anybody?
lucian no, i'm just wondering
it seems like yet another thing to maintain 16:55
whiteknight it really hasn't been any maintenance. It shares most of the code with the frontend and mostly just works 16:56
lucian i see
whiteknight eventually, it's the kind of mechanism I would like to use to bootstrap Parrot with 16:57
get the entry code written in PIR or something on Parrot, get into Parrot execution earlier
lucian yes, that would be nice
it'd be even nicer if GC and other low-level things were written on parrot
whiteknight I don't think that would be nice at all 16:58
lucian how so? 16:59
dalek rrot/m0-prototype: 9efb984 | cotto++ | / (2 files):
fix interp typo, update hello.m0b with recent register change
 17:00
dukeleto lucian: if by nice, you mean slow, then yes :)
lucian dukeleto: that's just an assumption without backing :)
both jikesrvm and pypy have fast GCs, written in not-C 17:01
dukeleto lucian: a GC in a native parrot language really isn't feasiable until we are JITed
lucian: yes, and they have a JIT :)
lucian of course, jit comes first
dukeleto lucian: ok, i can agree with you on that point :)
lucian i'm sort of dreaming
dukeleto lucian: it isn't a bad thing
lucian but JITs can do interesting optimisations across system boundaries
that's part of why i think it'd be nice to first design a system language on parrot, then bother with a better runtime for it (M0, jit, etc.) 17:03
17:04 theory joined
dukeleto whiteknight: do you use straight markdown for your blog, or jekyll too? 17:04
lucian: take a look at Close
Close?
whiteknight dukeleto: jekyll is the rendering engine. All the text is markdown
dukeleto aloha, Close? 17:05
aloha dukeleto: Close is code.google.com/p/close/
whiteknight lucian: That's what I envision Winxed to be
lucian dukeleto: yeah, i had a look. it's, uh, close to what i'm thinking of
whiteknight it's a low-level system language for Parrot
dukeleto Winxed is the new Close
lucian winxed isn't low-level enough if you ask me, though
whiteknight I don't see why not. You have access to all the low-level PIR features, inline PIR ops, etc
lucian right. but no access to raw memory for exampel 17:06
NotFound lucian: One can't be at a lever lowel than non-existence.
whiteknight PIR doesn't give access to raw memory
winxed is as low as the VM allows it to be
lucian yes
but a language to express parrot details would need to be lower level
whiteknight NotFound: I'm glad you're here. I had a question for you from my hacking yesterday
NotFound: is there any way to make a continuation in winxed? It doesn't seem to like treating labels as first-class citizens 17:07
dukeleto whiteknight: i guess i was thinking of something like this: raphinou.github.com/jekyll-base/
NotFound Correction: winxed on parrot can't give you access to raw memory. winxedxx will do.
benabik Winxed : PIR :: C : Assembly. Once M0 becomes the new "lowest level", we might want to create Winxed on M0
NotFound whiteknight: labels in pirops must be used as :label 17:08
whiteknight ${ :label } ?
NotFound Winxedxx is winxed --> C++
whiteknight: ${ goto :label }
whiteknight NotFound: but I don't want to goto. I want a Continuation that I can invoke later
NotFound whiteknight: then use an op other than goto. 17:09
whiteknight ${ set_addr cc, :label }
so that will work?
NotFound whiteknight: if does not work, let me kow.
whiteknight okay
NotFound whiteknight: when you have some example of usage, let me know, and I will think about a possible syntax. 17:12
whiteknight NotFound: Okay. What I'm mostly interested in is creating continuations and jumping around between them
dukeleto reads tom.preston-werner.com/2008/11/17/b...acker.html again and everything becomes clear
whiteknight of course, continuations take arguments, so a syntax that allows that would be fantastic
I almost can't imagine such a thing 17:13
label(var args):
lucian dukeleto: interesting. Cory Doctorow described a similar workflow 17:14
whiteknight NotFound: it works. Thanks 17:16
dalek rrot: eb3d7a9 | (Dan Bolser)++ | docs/project/git_workflow.pod:
Edited docs/project/git_workflow.pod via GitHub
 17:23
rrot: 8d2e649 | bubaflub++ | docs/project/git_workflow.pod:
Merge pull request #130 from dbolser/patch-1

Edited docs/project/git_workflow.pod via GitHub
17:29 dodathome joined
dukeleto is installing ruby gems. Be very afraid. 17:30
cotto_work ~~ 17:37
17:51 hercynium joined
whiteknight gist.github.com/983416 17:52
a little bit more timing information. If we remove the faulty recursion limit code, we can recycle the CallContext throughout the loop and see major time savings 17:53
It's worth noting that doing a morph on that callcontext doesn't reset it like we think it does 17:54
it still trips the recursion limit code eventually
of course, the recursion limit code is...faulty according to my reading of it 17:55
dispatch like this, with a recycled CallContext, cuts almost 50% of the time out of a normal PIR dispatch 17:56
without recycling, we only save about 10%
bubaflub whiteknight: could you clarify what the recursion limit code is currently doing and why we can bin it? 17:58
(just curious)
whiteknight we can't bin it
we do have legitimate needs for user-definable recursion limits
but the implementation now is lacking 17:59
right now, we test the recursion depth in src/pmc/sub.pmc:invoke, which doesn't seem like the right place to do it (considering we can invoke other things besides Sub)
I can't actually find where we decrement the recursion depth 18:01
tadzik whew, 'evening 18:02
whiteknight okay. I found it. When we create a new CallContext (src/call/context.c:init_context) we set the recursion depth of the new CallContext to the same as the parent 18:03
then in Sub.invoke, we increment and test it
Except, we decrement it when we do tailcalls
raise your hand if that sounds wrong to you
bubaflub raises hand
there should be a few other places that happens as well, right? 18:04
whiteknight no, fewer 18:08
we should set the recursion_depth for the new CallContext to the value of the old one +1 18:09
and only check it there
and not spread out the logic through the rest of the system
Sub.invoke shouldn't know or care anything about recursion depth
and the get_params op shouldn't have to be aware of tailcalls
and everywhere else that might cause a recursion should not have to deal with the logic either 18:10
although that's not even a great solution either, because we only have a "caller" context in certain situations. 18:12
we should add CallContext.init_pmc to take a parent context. CallContext.init will redirect to init_pmc passing interp->ctx 18:14
18:14 fperrad left
whiteknight that way we always have an accurate recursion count, and can check the depth logic in the same place all the time 18:14
and that should work fine with return continuations too, since they wouldn't increase the recursion limit if we aren't recreating them fresh 18:15
18:16 fperrad joined
whiteknight actually, we would still need to update it in the invoke opcode, incase the CallContext was created earlier and passed down the chain before being used in an invoke 18:17
so that's two places
although they could both use the same function
bubaflub will having that function in only those two places be faster? or "just" correct? 18:21
18:23 theory left
whiteknight I have to think about it a little bit more, but moving the logic to the correct places is an important step 18:24
and making sure the logic can be shared between more codepaths than just Sub.invoke
I think we really do need to talk about breaking CallContext up into two types, like plobsing mentioned 18:25
here's the exercise: How much logic can we move from Sub.invoke up into the invokecc opcode? 18:27
18:31 Coke left, Coke joined 18:36 hercynium left 18:39 theory joined 18:43 dodathome left 18:44 dodathome joined 18:45 theory left, Coke left, Coke joined
sorear lucian: shebang handling isn't recursive 18:51
lucian: when you have #!/usr/bin/perl6, that file MUST be a binary executable
that file = /usr/bin/perl6
18:53 alester left 19:12 ambs left
rblackwe The YAPC hackathon seems a bit thin. www.yapc2011.us/yn2011/wiki?node=Pa...0Hackathon 19:16
19:17 ambs joined
rblackwe just planning for flights and wondering if I should stay for it. 19:17
Anyone else planning on going?
cotto_work rblackwe: dukeleto and I will be there. 19:18
I think there are others.
rblackwe cotto_work: Woot!
that is enough thanks
cotto_work dukeleto: ping
PerlJam sorear: s/binary//
lucian sorear: and is that an issue?
dukeleto rblackwe: many people just haven't found that wiki page yet, methinks 19:20
cotto_work dukeleto: is it a reasonable testing strategy to have a bunch of .m0 files in t/m0/something/ that either output tap or something like "ok"?
lucian sorear: other than windows support (which is usually handled by registering the interpreter with the shell), i don't see the use-case where shebangs and special binaries don't work 19:21
rblackwe dukeleto: I understand samething happened when I was organizing yapc10.org/yn2009/talk/2045 19:22
Parrot Virtual Machine Workshop at YAPC|1-
cotto_work great showing at that one 19:23
rblackwe about 60 people
so I would say yes
sorear PerlJam: no. 19:24
rblackwe The wiki did not reflect everyone
Having it before YAPC I think we got people that just showed up early for YAPC.
sorear hmm, odd 19:25
rblackwe The crazy thing is we got a few people that came really just for PVMW not YAPC.
have to run off to a meeting. Looking forward to the workshop. Thanks all for the parrot/rakudo work! 19:26
sorear well I just tested it and, at least on Linux 2.6.32, you *can* have a shebang script use another shebang script as an interpreter 19:32
either this is new and 2.6.8 didn't support that, or I am just imagining the tests I did back on 2.6.8 19:33
PerlJam sorear: yep, been that way for a long time.
benabik I think it works in OS X.
sorear PerlJam: like "2.6.0" long time or like "V7" long time?
PerlJam sorear: I'm not sure ... but I think it has worked like that for > 10 years. 19:34
long enough ago that I don't remember when it started working. 19:35
(or when I *noticed* it working)
benabik Whee... My merge of master and nqp_pct won't build. GSoC step 1: Debug. 19:46
Ah! nqp_pct won't build either, so it's nothing I did. Time to pester bacek. 19:54
msg bacek I can't get nqp_pct to build. I keep getting ""load_bytecode" couldn't find file 'nqp-setting.pbc'" Any pointers? 19:55
aloha OK. I'll deliver the message.
19:56 Coke left, Coke joined
dukeleto cotto_work: sure 19:58
cotto_work: the more tests the better
cotto_work: we can sort them out later
cotto_work: we need a lot of tests for error conditions
cotto_work: i think we may need to add at least something to the spec about how errors should be thrown from an M0 assembler and interp 19:59
benabik: posting the full output of attempting to build nqp_pct to parrot-dev would be good 20:00
benabik: bacek++ is a sleepy coding robot now
benabik dukeleto: Yeah, I didn't figure he'd be awake. I've got a clock open to his timezone. :-D But I also figured that nqp_pct was his work and he might know where to start. 20:01
PerlJam benabik: I think that error means that the .pbc hasn't been copied to runtime/parrot/library 20:04
benabik PerlJam: master builds fine, as does `git merge-base origin/nqp_pct master` So something in nqp_pct is doing it. 20:05
dukeleto benabik: bacek++ often breaks branches and does a long sprint of robot coding to get it building again 20:07
benabik: he passed you the baton :)
benabik dukeleto: robot coding?
dukeleto benabik: we have a myth that bacek is a magical coding robot
benabik: try to debug the build issue, and report you finds to parrot-dev, with full output attached of any errors/etc 20:08
cotto_work They say if you speak his name three times in the dark, a heisenbug will mysteriously disappear.
dukeleto benabik: and of course, ask in here first :) 20:09
benabik: we still need to video chat, too
benabik dukeleto: Oh, yes. Buh. Totally forgot about that.
20:12 theory joined 20:15 whiteknight left 20:22 dodathome left 20:28 alester joined 20:30 mspaulding joined 20:32 hercynium joined 20:42 mj41 joined 20:58 ambs left
dalek rrot/m0-prototype: 40ff938 | cotto++ | t/m0/ops/m0_noop.m0:
start adding op-specific M0 tests
 21:04
21:12 fperrad left 21:55 hercynium left 21:57 pjcj left, pjcj joined 22:10 theory left 22:13 pjcj left, pjcj joined 22:15 pjcj left 22:16 pjcj joined 22:18 soh_cah_toa joined
mikehh t/tools/dev/headerizer/01_functions.t - Failed test: 51 (fulltest)- See TT #2119 22:18
all other tests PASS (pre/post-config, make corevm/make coretest, make world/make test, fulltest) at 3_4_0-20-g8d2e649
Kubuntu 11.04 amd64 (g++ --optimize)
22:20 alester left, pjcj left 22:21 pjcj joined, mj41 left
mikehh winxed (r1015) builds on parrot (3_4_0-20-g8d2e649) - test/test1/test2 ok - opengl stuff ok now - Kubuntu 11.04 amd64 (g++ --optimize) 22:27
22:28 pjcj left 22:30 pjcj joined 22:31 jsut_ joined 22:36 jsut left
dalek nxed: r1016 | NotFound++ | trunk/examples/jsonread.winxed:
fix and improve example jsonread
 22:43
22:48 lucian left 22:53 pjcj left 22:54 pjcj joined 22:57 Coke left, Coke joined 22:58 pjcj left 22:59 pjcj joined 23:01 pjcj left
mikehh rakudo (7860993) - builds on parrot (3_4_0-20-g8d2e649) - make test, make stresstest [roast (32c4ff6)] PASS 23:02
Kubuntu 11.04 amd64 (g++ --optimize)
23:07 pjcj joined 23:08 pjcj left 23:17 pjcj joined 23:21 ShaneC left 23:40 bubaflub left 23:42 bubaflub joined 23:50 rurban_ joined 23:52 rurban left, rurban_ is now known as rurban

Powered by Cro and the Raku® Programming Language.

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

Thank you!