|
Parrot 4.3.0 "In Which..." | parrot.org | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC Set by moderator on 25 April 2012. |
|||
| whiteknight | bacek_at_work: I don't think it's a problem | 00:00 | |
| bacek_at_work | whiteknight, which one? | ||
| whiteknight | aloha saying karma values | 00:04 | |
| benabik | whiteknight: You appear to be in the minority. | ||
| I was thrown off by it, but there seems to be active vitriol towards it elsewhere. | 00:05 | ||
| whiteknight | where, in #perl6? | 00:06 | |
| benabik | I seem to recall some complaints here, but definitely there, yes | ||
| Coke | I'd rather not have it announced, myself. | ||
| whiteknight | that's fine too. I won't argue about it | 00:13 | |
|
00:32
nbrown joined
|
|||
| cotto | ~~ | 00:34 | |
| nbrown | hey cotto, I saw you were looking for me | 00:38 | |
| cotto | nbrown, yup. been thinking about m0's memory model | 00:45 | |
| I might be making it out to be more complex than necessary. lemme find my gist | |||
| raw.github.com/gist/2581153/8e546e...stions.txt | 00:46 | ||
| nbrown | glad someone has been. I got buried this week and am slowly finding my way ou | ||
| cotto | no worries | ||
| nbrown | first thing, I don't think there's any point to having S type constants, do you? | 00:47 | |
| cotto | they're shorthand for p | 00:48 | |
| we could have INPP | 00:49 | ||
| or have then not be typed at all | |||
| i.e. Rn could be any of insp | |||
| nbrown | oops, I really meant P, not S | ||
| cotto | P will be useful once we have a meaningful way of representing objects | 00:50 | |
| nbrown | so P would be for a serialized object? | ||
| cotto | it'd be an active object | ||
| well, a pointer to one | |||
| nbrown | but isn't a constants section read out of a m0b file? | 00:51 | |
| cotto | they have a runtime meaning too | ||
| nbrown | m0 doesn't really have objects | ||
| cotto | or will | ||
| nbrown | I don't think I understand the runtime meaning of the constants section | ||
| *segment | 00:52 | ||
| I thought the segment was simply a representation of the constants in the m0b file | |||
| cotto | yes, that's the role of the constants segment | ||
| nbrown | ok. I was getting mildly confused between the constants segment and the data segment | 00:53 | |
| cotto | SP registers can point at entries in the constants table or at dynamic objects in the data segment | ||
| nbrown | right, I'm getting the hang of it now. I was misinterpreting things | 00:55 | |
|
00:56
Khisanth joined
|
|||
| nbrown | btw, I really want to write an m0 debugger, I just haven't been sure how to do it yet | 00:58 | |
| cotto | I'd love you forever. | ||
| nbrown | Everytime I've had to debug an m0 test file I've wanted one oh so badly | 00:59 | |
| cotto | you and me both | ||
| nbrown | :) | 01:00 | |
| cotto | I wonder if named registers would be a bad idea. | ||
| nbrown | so on the recursion thing, where would we store the state if we clone after entering? another callframe? | 01:01 | |
| I understand the appeal of named registers, but I see them just complicating anything that wants to generate m0 | |||
| cotto | the current callframe's PCF points at the callframe that called it | 01:02 | |
| (need to verify, but the poke_caller test does this) | |||
| nbrown | the poke_caller test populates the new callframe prior to entering | 01:03 | |
| cotto | ah. I see the question | ||
| nbrown | I was trying to understand what you meant when you said leftover state | 01:04 | |
| cotto | actually, I can see it working like it does now | 01:05 | |
|
01:06
kid51_ joined
|
|||
| nbrown | ok, I think the current approach works pretty well | 01:06 | |
| so on the unresolved questions, if the global data is purely runtime, how do we access it? | 01:09 | ||
| and how much gets allocated? | 01:10 | ||
| cotto | it'd fit nicely with the other global interp info | 01:12 | |
| CONFIG, ARGV, ARGC, etc | |||
| nbrown | right, but those are all known at load time | 01:13 | |
| I guess we can deal with it the same way we deal with the data segment | |||
| fixed size or grow as needed | 01:14 | ||
| cotto | yes | ||
| nbrown | ok | ||
| Your gist seems pretty on point to me | 01:15 | ||
| I don't think you're making it too comlpex | 01:16 | ||
| cotto | how about sbrk? | ||
| and implementing virtual memory? | |||
| nbrown | I don't know enough about it | ||
|
01:16
kid51 joined
|
|||
| cotto | (either that or realloc) | 01:16 | |
| nbrown | I would have used realloc since I know that | 01:17 | |
| I don't see a way around it if we allow the data segment and global data to grow | |||
| cotto | yes | ||
| if realloc doesn't move memory, it'll work nicely | 01:18 | ||
| nbrown | I believe it may | ||
| cotto | realloc would at least be a good first approximation | ||
| nbrown | I just looked it up and it says that it can move the memory block to a new location | 01:19 | |
| I'll go read up on sbrk | |||
| cotto | sbrk is what malloc is implemented on top of | 01:21 | |
| basically increases the amount of memory available to a process | |||
| nbrown | ok | ||
| makes sense to me | 01:22 | ||
| so which part were you concerned you werw overthinking? | 01:23 | ||
| cotto | implementing a virtual memory system | ||
| if I get to that point, it makes me think that something is wrong | |||
| nbrown | fair enough, so if we step back: can we just have an array of data sections? | 01:26 | |
| use the malloc / gc_alloc ops to generate new data segments? | |||
| cotto | possible | 01:27 | |
| interesting idea | |||
| nbrown | it's far simpler | ||
| cotto | I'm not sure about it being *far* simpler than just using realloc to expand the data segment, but the idea definitely is worth considering | 01:28 | |
| nbrown | yeah, as I'm thinking about it *far* is *far* too strong a word | 01:29 | |
| :) | |||
| but it would allow a faster prototype to play with | |||
| scratch that, I meant allow us to write a prototype faster | 01:30 | ||
| cotto | so how would you point to byte 32 in data segment 4? | 01:31 | |
| nbrown | so the part that was starting to trip me up was the array of pointers to data segments.... | 01:32 | |
| is it something that's fixed size? | |||
| cotto | I was jus tthinking about that | 01:33 | |
| there'd need to be a way to expand it | |||
| expanding it implicitly is an option, but that's also slightly magical | 01:34 | ||
| nbrown | we'd need something like a directory segment to point data segments, but that's difficult to grow | ||
| cotto | it could look like cf[DATA][n] | 01:36 | |
| realloc for that would probably be workable, but that's one of the side-effects that M0 should avoid if at all possible | 01:37 | ||
| nbrown | yeah | ||
| if we preallocate space for a decent number of data segment pointers, it's likely we could avoid it | 01:38 | ||
| maybe we could even allow the user to specify the # of desired data segments in the m0 file to help avoid the realloc case | 01:39 | ||
| something like .num_data_segments 20 | |||
| or whatever | |||
| cotto | I'm still not quite sold on it. | 01:40 | |
| nbrown | and if the user didn't provide anything m0 has some reasonable default | ||
| me neither | |||
| cotto | flat memory is very non-magical | ||
| nbrown | flat memory? | 01:41 | |
| cotto | a single data segment that needs to be manually expanded and shrunk | ||
| nbrown | I don't think the array of data segments needs to be magical | 01:42 | |
| dalek | kudo/nom: 7eae9b2 | pmichaud++ | src/ (2 files): Fix [|] and [&] to provide flat junctions (RT #112696, masak++). |
01:43 | |
| cotto | a better word would be "simple" | ||
| nbrown | yes, I'd agree with that | ||
| generating code for multiple data segments would be more complicated | 01:44 | ||
| hmmm, I'm coming back around to the virtual memory idea | 01:49 | ||
| accessing/writing data in multiple data segments would be not a lot of fun | 01:51 | ||
| dalek | kudo/nom: 2d2584a | pmichaud++ | src/core/metaops.pm: Implement triangle forms for junction reducers: [\\|] and [\\&] |
02:06 | |
| rurban_home | github.com/parrot/parrot/pull/762 | 03:33 | |
| aloha | (parrot/parrot) Issues opened : 762 (mark stack-overflow gc for clang -faddress-sanitizer) by rurban : github.com/parrot/parrot/issues/762 | 03:38 | |
| dalek | rrot: 7433886 | rurban++ | src/gc/system.c: mark stack-overflow gc for clang -faddress-sanitizer clang.llvm.org/docs/AddressSanitizer.html fails in trace_mem_block() with a stack invalid READ, which is actually valid in our GC . Since this is the only function we just use the recommended detection and attribute here once. |
03:52 | |
| rrot: 68a170c | jimmy++ | src/gc/system.c: Merge pull request #762 from rurban/master mark stack-overflow gc for clang -faddress-sanitizer |
|||
| aloha | (parrot/parrot) Issues closed : 762 (mark stack-overflow gc for clang -faddress-sanitizer) by rurban : github.com/parrot/parrot/issues/762 | ||
| ttbot | Parrot 68a170c4 i386-linux-thread-multi make error tt.taptinder.org/cmdinfo/81818 | 03:58 | |
|
04:05
travis-ci joined
|
|||
| travis-ci | [travis-ci] parrot/parrot#284 (master - 68a170c : Jimmy Zhuo): The build was broken. | 04:05 | |
| [travis-ci] Change view : github.com/parrot/parrot/compare/b......68a170c | |||
| [travis-ci] Build details : travis-ci.org/parrot/parrot/builds/1242128 | |||
|
04:05
travis-ci left
04:22
alester joined
|
|||
| alester | hey rurban the 7433886ded3df005351e9a0c087ef674771b3488 change to src/gc/system.c breaks my GCC build | 04:22 | |
| benabik | It broke gcc and g++ on travis as well | 04:24 | |
| alester | I think we ought to flag attributes using the same technique in include/parrot/compiler.h for PARROT_PURE_FUNCTION and the like. | ||
| so that the detail of __attribute__((no_address_safety_analysis)) can be hidden in a macro | |||
| I'm watching a movie for the next half hour if you'd like to discuss. | 04:25 | ||
| benabik | Given that we might want to handle the flag differently and that it breaks gcc/g++, perhaps we should revert the change? | 04:29 | |
| alester | I don't have a strong feeling either way. | 04:31 | |
| But I'm writing to parrot-dev right now how I suggest we do it going forward. | |||
| benabik | alester++ | 04:32 | |
| alester | ok sent | 04:36 | |
|
04:55
rurban joined
05:51
contingencyplan_ joined
06:01
woosley joined
|
|||
| cotto | ~~ | 06:04 | |
|
06:33
fperrad joined
06:59
brrt joined
07:08
woosley joined
07:26
plobsing joined
07:36
preflex joined
08:05
lucian joined
|
|||
| moritz | \\o | 08:10 | |
| brrt | \\o | ||
|
08:11
nopaste joined
08:32
woosley joined
08:39
nopaste joined
08:43
nopaste joined
|
|||
| bacek_at_work | jfyi about C99 in VC++ herbsutter.com/2012/05/03/reader-qa...-c99/?nope | 09:36 | |
| answer is "no" | |||
| long answer is "We recommend that C developers use the C++ compiler to compile C code (using /TP if the file is named something.c). This is the best choice for using Visual C++ to compile C code." | |||
| moritz | meh. | 09:37 | |
|
10:26
plobsing joined
|
|||
| dalek | rrot: 1eff807 | NotFound++ | src/gc/system.c: fix check for address_sanitizer feature |
10:40 | |
|
10:58
travis-ci joined
|
|||
| travis-ci | [travis-ci] parrot/parrot#285 (master - 1eff807 : NotFound): The build was fixed. | 10:58 | |
| [travis-ci] Change view : github.com/parrot/parrot/compare/6......1eff807 | |||
| [travis-ci] Build details : travis-ci.org/parrot/parrot/builds/1243696 | |||
|
10:58
travis-ci left
11:03
JimmyZ joined
|
|||
| dalek | kudo/nom: d337e35 | moritz++ | src/Perl6/ (2 files): carry around the name of the to-be-imported module, and use it in an error message |
11:57 | |
|
12:01
whiteknight joined
|
|||
| whiteknight | good morning, #parrot | 12:11 | |
| moritz | \\o whiteknight | 12:12 | |
| whiteknight | hello moritz | ||
|
12:28
JimmyZ joined
13:01
PacoAir joined
|
|||
| dalek | rrot: 5810fe5 | petdance++ | / (3 files): Added the PARROT_NO_ADDRESS_SAFETY_ANALYSIS macro, plus support for it in the Headerizer. |
13:10 | |
| whiteknight | petdance++ indeed | 13:13 | |
| Coke | petdance++ | 13:14 | |
| whiteknight | and rurban++ for coming up with the idea | 13:16 | |
|
13:37
JimmyZ_ joined
13:43
bluescreen joined
13:56
jashwanth joined
14:04
alester joined
14:17
davidfetter joined
14:19
benabik joined
|
|||
| alester | ping rurban | 14:31 | |
| rurban | here | 14:36 | |
| I see, you added a macro for asan | 14:37 | ||
| Parrot_api_string_export_wchar writes one byte too much | 14:49 | ||
| It should be wstrout = (wchar_t *) malloc(sizeof (wchar_t) * (len + 1)); | |||
|
14:52
jashwanth joined,
Infinoid joined,
Tene joined,
jlaire joined,
ttbot joined,
sri joined,
eternaleye joined,
mdupont joined,
schm00ster joined,
dngor joined,
dukeleto joined,
bacek_at_work joined,
perlite joined,
aloha joined,
Patterner joined,
mtk joined,
pjcj joined,
jsut joined,
autark joined,
brambles joined,
particle joined,
atrodo joined,
masak joined,
jtpalmer joined,
GeJ joined,
pmichaud_ joined,
sorear joined,
elmex joined,
nine joined,
TonyC joined,
davidfetter joined,
alester joined,
bluescreen joined,
JimmyZ joined,
preflex joined,
alvis joined,
cotto joined,
tadzik joined,
PerlJam joined,
szbalint joined,
awwaiid joined,
cxreg joined,
Timbus joined,
knewt joined,
wendar joined,
wagle joined,
Util_ joined,
dalek joined,
arnsholt joined,
NotFound joined,
Kovensky joined,
rblackwe joined,
japhb joined,
benabik joined,
whiteknight joined,
lucian joined,
Khisanth joined,
Coke joined,
mj41 joined,
jevin joined,
simcop2387 joined,
Maddingue joined
|
|||
| aloha | (parrot/parrot) Issues opened : 763 (api_string_export_wchar allocated one too less) by rurban : github.com/parrot/parrot/issues/763 | 14:59 | |
| dalek | rrot: df12f34 | rurban++ | src/embed/strings.c: api_string_export_wchar allocated one too less clang -faddress-sanitizer detected this heap-buffer-overflow in t/src/embed/strings.t, allocated 173 bytes only, writing to cstr[173]. |
15:05 | |
| rrot: 8bd397a | rurban++ | include/parrot/compiler.h: avoid PARROT_NO_ADDRESS_SAFETY_ANALYSIS redefinition warnings |
|||
| rrot: ca27ffa | petdance++ | / (2 files): Merge pull request #763 from rurban/master api_string_export_wchar + PARROT_NO_ADDRESS_SAFETY_ANALYSIS redef |
|||
| alester | rurban++ | ||
|
15:06
dmalcolm joined
|
|||
| rurban | one more is coming from make test. t/pmc/structview.t test 5 | 15:07 | |
| Parrot_StructView_set_integer_keyed_orig | 15:08 | ||
| moritz | rurban: are you hunting address violations? | ||
| aloha | (parrot/parrot) Issues closed : 763 (api_string_export_wchar allocated one too less) by rurban : github.com/parrot/parrot/issues/763 | 15:09 | |
| rurban | yes, just asan runs | 15:12 | |
|
15:14
schmooster joined
|
|||
| whiteknight | rurban++ | 15:15 | |
| dalek | rrot: d3dcc4b | petdance++ | src/embed/strings.c: localized and consted some local variables. Parenthesized another malloc call like in df12f34e9465531a89853ce541096fefc7025e0f |
||
| alester | What is "asan"? | 15:16 | |
| Oh, oh, got it. | |||
| I can't get a llvm/clang build working on my box. | |||
| rurban | alester: what's not in the build instructions there: remove a prev. system clang first. | 15:18 | |
| alester | I don't think I have one. | ||
| You're on Mac OS X, right? I've been doing it on Linux | 15:19 | ||
| rurban | an old clang can never boootstrap a new one | ||
| I'm doing both | |||
| alester | Huh. | ||
| rurban | now linux | ||
|
15:19
estrabd joined
|
|||
| alester | oh well, i have plenty of other projects I'm working on, and it's even less important now that you're on the case. | 15:19 | |
| rurban | mac osx is trickier you need no-pie | ||
| alester | "no-pie"? | ||
| rurban | like PIC | ||
| alester | I don't understand. | 15:20 | |
|
15:27
plobsing joined
|
|||
| rurban | no, better like address randomization. developer.apple.com/library/mac/#do.../ld.1.html | 15:27 | |
| similar to windows ASLR | 15:28 | ||
| alester | rurban: I'm surprised your talk got rejected for YAPC::NA. Are you coming anyway? | 15:35 | |
| rurban | sure, I'm coming. My company pays for it :) | 15:37 | |
| alester | I'm going to drop JT a line saying "If anyhting opens up, please run rurban's talk" | 15:38 | |
| whiteknight | what is his talk about | 15:39 | |
| alester | github.com/parrot/parrot/pull/763#...nt-5513148 | 15:40 | |
| Coke | rurban++ # my boss rejected my request. Of course, we don't use perl at work, so I can't complain. ;) | ||
| rurban | code.google.com/p/address-sanitizer.../FoundBugs see perl | ||
| alester | I'm just taking days off. Madison is only 2 hours from my house. | ||
| rurban | and how it works overall, and how to analzye the found bugs. clang is not easy to debug with gdb. most vars are in registers | 15:41 | |
| and that you can just use it and forget about it, since it's so fast. | |||
| alester | rurban, what TZ are you? I'm guessing UTC+0100? | ||
| I'd love to work on this more w/you but I don't have the time right now. | 15:42 | ||
| rurban | I'm in Texas/Houston | ||
| alester | oh, huh, why'd I think you were in .fr? | ||
| rurban | I moved over, working for cPanel at the perl5 compiler | 15:43 | |
| alester | Aha. You're a cpaneler. Now it makes sense. | ||
| rurban | we use the compiler all day long, | ||
| alester | cpanel: The company with the biggest logo on the YAPC::NA T-shirt. :-) | 15:44 | |
| I was just at a planning meeting on Tuesday. | |||
| rurban | like facebook and google you need to have some technological advantage :) | ||
|
15:44
mdupont joined
|
|||
| alester | rurban: Are you in the cpanel recruitment video? | 15:46 | |
| rurban | I also use asan all day long here | ||
| Nope, I don't think so. | |||
| alester | rurban: Aha, so you WERE in .fr. I'm not crazy! | ||
| rurban | No, I'm from Austria, same town as Arnold Schwarzenegger | ||
| But I'm a better surfer than him | 15:47 | ||
| alester | Austria, France, to us Americans it's all the same. | ||
| rurban | We also have french folks here at cPanel | ||
|
15:48
Psyche^ joined
|
|||
| alester | I get the impression that you guys are sending pretty much the whole office up to Madison. | 15:48 | |
| rurban | We are about 200 and we are /only/ coming with 40 :) | 15:49 | |
| I guess Madison must be pretty | |||
| www.kiplinger.com/slideshow/more-gr...9.html#top | 15:50 | ||
| alester | Madison is indeed very nice. | ||
| rurban | maybe that's why everybody wants to come. I have no idea. It's pretty far away from everywhere | 15:51 | |
| alester | I mean, if you don't mind snow. | ||
| and the Green Bay Packers | 15:52 | ||
| rurban | Last years Ashville was worst city for singles www.kiplinger.com/slideshow/worst-c...les/4.html | ||
| But I liked it nevertheless. It's not that you are looking for one night stands at perl conferences | 15:53 | ||
| unaligned FixedIntegerArray is also broken a bit | 15:55 | ||
| alester | rurban: But they seem to happen anyway! :-) | ||
| rurban: Check yr mailbox, you're on the cancellation list for YAPC | |||
| rurban | No mail yet. | 16:02 | |
| alester | rurban@x-ray.at ? | 16:03 | |
| rurban | yes | ||
| alester | spam filter? | ||
| It's mostly quoted text | |||
| rurban | git it, thanks :) | ||
| got it | |||
| I think my talk scared them being too technical | 16:04 | ||
| tempc in structview.pmc:613 is off by one | 16:14 | ||
| Maybe that's why the hi-bit is sometimes wrong (int overflow errors) | |||
|
16:20
jashwanth joined
|
|||
| cotto | ~~ | 16:43 | |
| dalek | kudo/nom: 637197e | moritz++ | t/spectest.data: run new test file |
||
| kudo/nom: ef715f0 | moritz++ | t/spectest.data: [t/spectest.data] bring back in asciibetical order also delete reference to outdated S07 test |
16:46 | ||
|
16:48
PacoAir joined
|
|||
| rurban | How about #if 0 in parrot code? for the sake of understanding | 16:48 | |
| whiteknight | what do you mean? | ||
| rurban | unaligned access in StructView_set_integer_keyed is off-by-one, but you would not understand it without printing out the access patterns | 16:49 | |
| At least I do. But I can also write a comment. | 16:50 | ||
| I send you a pull request and you can decide. At least I fixed the bug. | |||
| dalek | rrot: 1e5f20e | rurban++ | src/pmc/structview.pmc: avoid invalid unaligned StructView_set_integer_keyed access clang -faddress-sanitizer found this invalid read access in two scenarios: 1: cptr[8/8] with uint1 2: off-by-one access on multi-byte values |
17:03 | |
| rrot: a850da6 | petdance++ | src/pmc/structview.pmc: Merge pull request #764 from rurban/master last found asan bug (I hope) |
|||
| rurban | Now let's see if parrot with perl6 survives this treatment :) | 17:06 | |
| moritz | is -faddress-sanitizer now enabled by default on clang builds? | 17:14 | |
| or is that something you add to the compiler options? | |||
| rurban | debian unstable I think so | 17:15 | |
| It's in llvm 3.1 mainline since about a month or so. | |||
| I usually compile from source | |||
| C is pretty stable, there are some bugs in the Windows port and C++ | 17:16 | ||
| bugs = false positives | |||
| One more in parrot: heap-use-after-free in t/run/options.t | 17:17 | ||
| 34 --leak-test fails | 17:22 | ||
|
17:23
contingencyplan joined
|
|||
| dukeleto | ~~ | 17:28 | |
| rurban | Oh my, Parrot_x_exit needs PARROT_NO_ADDRESS_SAFETY_ANALYSIS added | 17:31 | |
| nope, did not help | 17:33 | ||
| But it only fails with --leak-test, so it's probably not important | 17:34 | ||
| whiteknight | That function is having problems? | 17:35 | |
| It should just be some bookkeeping and a longjmp | |||
| rurban | With --leak-test at the final interp->exit_handler_list = NULL; interp is already freed | 17:36 | |
| whiteknight | oh wow | ||
| do you have a backtrace for that? | |||
| rurban | But only with --leak-test. Maybe we should check for this flag and do not write then | ||
| whiteknight | we probably need to rewrite the logic for that flag | 17:37 | |
| nopaste | "rurban" at 208.74.121.102 pasted "With --leak-test at the final interp->exit_handler_list = NULL; interp is already freed" (13 lines) at nopaste.snit.ch/137744 | ||
| "rurban" at 208.74.121.102 pasted "asan warning" (37 lines) at nopaste.snit.ch/137745 | 17:39 | ||
| whiteknight | Hmm... that definitely doesn't look right | ||
| I think what we want there is to call the at_exit handlers and just return 0 | 17:40 | ||
| rurban | calling Parrot_x_jump_out is also not kosher | ||
| whiteknight | no, we don't want to do either there | ||
| aloha | (parrot/parrot) Issues opened : 765 (With --leak-test at the final interp->exit_handler_list = NULL; interp is already freed ) by rurban : github.com/parrot/parrot/issues/765 | 17:45 | |
| whiteknight | rurban: If you're not going to fix that ticket, assign it to me. I can do it tonight | 17:56 | |
| if you want it, that's fine too :) | 17:57 | ||
| rurban | I would if I can. Could not find how to assign | ||
| dalek | kudo/nom: bc520af | moritz++ | t/spectest.data: run caller.t test |
17:58 | |
| rurban | I'd rather not check the fragile gc logic. Yesterday was too frightening already. | 17:59 | |
| whiteknight | I'll assign the ticket | ||
| I'm going to need to learn how to use this analyzer so I can properly test it | 18:00 | ||
| rurban: If you can't give a talk at YAPC, could you write up a short How-To about it for parrot-dev? | |||
| rurban | cat .gdbinit | 18:01 | |
| break __asan_report_error | |||
| That's the best hint | |||
| whiteknight | ok | ||
| rurban | Sure. I'll add to my blog post series about asan blogs.perl.org/users/rurban/2012/03...und-2.html | ||
| whiteknight | nostarch.com/newsletters/dayagainstdrm.htm | 18:03 | |
| rurban | Whow, super offer! thanks | 18:04 | |
| whiteknight | excellent blog post | 18:05 | |
| (I saw that link in my RSS feed and figured I would pass it along to parrot devs) | |||
| rurban | I didn't yet wrote about the CPAN findings (DBI and more), and parrot. | 18:06 | |
| whiteknight | okay, I look forward to it | 18:07 | |
| rurban | If this guy would have used asan he would have been much faster coming up with his exploits: nostarch.com/download/bughunter_ch2.pdf | 18:13 | |
| dalek | kudo/nom: 8fff4e7 | moritz++ | t/spectest.data: run counted.t test file |
18:20 | |
|
18:24
mtk joined
18:27
plobsing joined
18:34
mtk joined
18:39
fperrad_ joined
18:50
brrt joined
|
|||
| rurban | make install: -rw------- 1 root 33576 May 4 13:27 /usr/local/lib/parrot/4.3.0-devel/parrot_config.o | 18:51 | |
| /usr/bin/ld: error: cannot open /usr/local/lib/parrot/4.3.0-devel/parrot_config.o: Permission denied | |||
|
18:57
mtk joined,
aloha joined,
perlite joined,
bacek_at_work joined,
dukeleto joined,
dngor joined,
eternaleye joined,
sri joined,
ttbot joined,
jlaire joined,
Tene joined,
Infinoid joined
18:58
Infinoid joined,
Tene joined,
jlaire joined,
ttbot joined,
sri joined,
eternaleye joined,
dngor joined,
dukeleto joined,
bacek_at_work joined,
perlite joined,
aloha joined,
mtk joined,
Patterner joined,
dmalcolm joined,
pjcj joined,
jsut joined,
autark joined,
brambles joined,
particle joined,
atrodo joined,
masak joined,
jtpalmer joined,
GeJ joined,
pmichaud_ joined,
sorear joined,
elmex joined,
nine joined,
TonyC joined
18:59
brrt joined,
plobsing joined,
contingencyplan joined,
mdupont joined,
benabik joined,
whiteknight joined,
Khisanth joined,
Coke joined,
mj41 joined,
jevin joined,
simcop2387 joined,
Maddingue joined
19:00
davidfetter joined,
alester joined,
bluescreen joined,
preflex joined,
alvis joined,
cotto joined,
tadzik joined,
PerlJam joined,
szbalint joined,
awwaiid joined,
cxreg joined,
Timbus joined,
knewt joined,
wendar joined,
wagle joined,
Util_ joined,
dalek joined,
arnsholt joined,
NotFound joined,
Kovensky joined,
rblackwe joined,
japhb joined
|
|||
| dalek | kudo/nom: cf40f24 | moritz++ | src/core/Str.pm: [Str.match] add :th as alias for :nth |
19:04 | |
|
19:22
lucian joined
19:23
bluescreen joined
|
|||
| dalek | rrot: 6c302cf | jkeenan++ | src/pmc/structview.pmc: [codingstd] Eliminate hard tabs and make indentation nice. |
19:59 | |
|
20:16
rich joined,
rich left
20:22
travis-ci joined
|
|||
| travis-ci | [travis-ci] parrot/parrot#290 (master - 6c302cf : jkeenan): The build was broken. | 20:22 | |
| [travis-ci] Change view : github.com/parrot/parrot/compare/a......6c302cf | |||
| [travis-ci] Build details : travis-ci.org/parrot/parrot/builds/1248054 | |||
|
20:22
travis-ci left
|
|||
| dalek | p/toqast: 6f91998 | jnthn++ | src/QAST/Block.nqp: Generate compilation-unit unique IDs for QAST::Blocks (or allow explicit setting of one). |
20:37 | |
| p/toqast: feb325c | jnthn++ | src/QAST/Compiler.nqp: Code-gen for outer chain. |
|||
| p/toqast: 5f34bad | jnthn++ | src/QAST/Compiler.nqp: Generate with :anon flag to avoid a Parrot namespace installation. |
|||
| p/toqast: 7de618b | jnthn++ | src/QAST/ (2 files): First crack at code-gen for :op('call'). |
21:00 | ||
| benabik | ~~ | 21:25 | |
|
21:27
plobsing joined
|
|||
| cotto | ~, | 21:28 | |
| rurban | thanks jkeenan. I just installed the .el files for parrot for proper formatting | 21:50 | |
|
22:09
bluescreen joined
22:41
davidfetter joined
23:05
whiteknight joined
|
|||
| whiteknight | good evening, #parrot | 23:16 | |
| dalek | Heuristic branch merge: pushed 580 commits to parrot/mem_limit by Whiteknight | 23:30 | |
| whiteknight | benabik: ping | 23:31 | |
| benabik | whiteknight: pong | ||
| whiteknight | benabik: the nqp_pct branch, what's the status of it? | ||
| benabik | whiteknight: Does PIR very slowly, does very little bytecode. | 23:32 | |
| whiteknight | benabik: okay. Is it something we're going to pursue still, or is it completely supplanted by pact? | ||
| benabik | whiteknight: It should probably be replaced with QAST and PACt. | 23:33 | |
| whiteknight | ok | 23:34 | |
| Otherwise I would try to bring it up to date with master or something | |||
| benabik | The speed was so painful. | ||
| whiteknight | ok | ||
| dalek | rrot/manual_args: de203dd | Whiteknight++ | / (8 files): Add in a :manual_args flag to PIR, for testing |
23:40 | |
| rrot/manual_args: d7856f8 | Whiteknight++ | / (217 files): Merge from master. Fix a conflict in IMCC with handling of automagic 'self'. Add some comments too, to explain the code after the merge |
|||
| whiteknight | I'm trying to dig through some of my old branches and either clean them or update them | 23:46 | |
| I have far too many old branch refs on my machine, idle | |||
| benabik | Yeah. | 23:49 | |
| Oh. Forgot pct_winxed. IMHO, that's a better direction for PCT to head. | 23:50 | ||
| whiteknight | ok | 23:56 | |