|
Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (25 to go), merge outstanding branches; profile your favorite PIR for memory leaks with valgrind Set by moderator on 31 August 2010. |
|||
|
00:02
Psyche^ joined
00:08
Patterner left,
Psyche^ is now known as Patterner
|
|||
| NotFound | whiteknight: I just looked at metadata/kakapo.json | 00:11 | |
|
00:12
nwellnhof left
|
|||
| whiteknight | hmmm | 00:12 | |
| if I generate that file in kakapo now, it gives me parrot_setup | 00:14 | ||
| NotFound | Can't you just hand edit it? | 00:16 | |
| whiteknight | I figured it out | 00:19 | |
| :setup('setup.nqp') | |||
|
00:24
kid51 left
00:29
ruoso joined
|
|||
| cotto | ~~ | 00:39 | |
| headerizer is broken | 00:52 | ||
| actually, it might just need a reconfig | 00:53 | ||
| yup. It's fine now. | |||
| moderator | Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (24 to go), merge outstanding branches; profile your favorite PIR for memory leaks with valgrind | 00:55 | |
| dalek | TT #43 closed by cotto++: auto-headerize PIRC sources | 01:06 | |
| TT #43: trac.parrot.org/parrot/ticket/43 | |||
| TT #29 closed by cotto++: Add more files to the tutorial | |||
| TT #29: trac.parrot.org/parrot/ticket/29 | |||
| moderator | Parrot 2.7.0 "Australian King" Released! | parrot.org Log: irclog.perlgeek.de/parrot/today | Nopaste: nopaste.snit.ch:8001 | close 25 tickets (23 to go), merge outstanding branches; profile your favorite PIR for memory leaks with valgrind | 01:06 | |
|
01:37
whiteknight left
01:38
hercynium left
01:45
hercynium joined
01:50
kid51 joined
|
|||
| dalek | rrot: r48741 | jkeenan++ | trunk (65 files): Merge detect_llvm branch into trunk. Adds configuration step auto::llvm to detect Low Level Virtual Machine (LLVM) and associated test file. |
02:02 | |
| rrot: r48742 | jkeenan++ | branches/detect_llvm: Branch has been merged into trunk and is no longer needed at HEAD. |
|||
| purl | i already had it that way, dalek. | ||
|
02:03
GodFather joined
|
|||
| dalek | rrot: r48743 | jkeenan++ | branches/gsoc_threads/include/parrot/threads.h: [codingstd] c_macro_args: wrap 2 arguments. |
02:19 | |
| rrot: r48744 | jkeenan++ | branches/gsoc_threads/include/parrot/events.h: [codingstd] c_header_guards. |
|||
| rrot: r48745 | jkeenan++ | branches/gsoc_threads/t/src/threads_io.t: [codingstd] Add coda. |
|||
| rrot: r48746 | jkeenan++ | branches/gsoc_threads/src/pmc/pmclist.pmc: [codingstd] c_function_docs. |
|||
| rrot: r48747 | jkeenan++ | branches/gsoc_threads/src/threads.c: [codingstd] c_parens. |
|||
|
02:28
kid51 left
02:35
janus left
02:36
GodFather left
02:38
mikehh left
02:40
bluescreen joined
02:46
Infinoid left
02:48
janus joined
02:51
Infinoid joined
|
|||
| tcurtis | Are comparisons between signed and unsigned types potentially unproductive in C? | 03:02 | |
| s/unproductive/problematic/ | |||
| cotto | they're good to avoid | 03:05 | |
| chromatic | Are you looking at the packfile warnings? | 03:06 | |
|
03:07
mikehh joined
|
|||
| tcurtis | There are a few other warnings about it in charsets and IMCC, also. | 03:07 | |
| chromatic | The problem is losing precision, if you overflow the max signed value or invalid comparisons of a negative to a positive. | 03:08 | |
| Most of the warnings I've seen are using a signed integer as a loop counter compared to an unsigned "How many did we allocate?" value. | |||
| That's C for you; no one expected iterators when devising the PDP memory model. | 03:09 | ||
| tcurtis | Is it worth changing those instances to use an unsigned loop counter? | 03:11 | |
| chromatic | Yes. | 03:13 | |
|
03:28
FullMetalHarlot joined,
FullMetalHarlot left
03:31
hercynium left
03:58
ash_ joined
04:48
sri joined
|
|||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48747 - Ubuntu 10.04 i386 (g++) | 04:54 | |
|
05:28
Coke left
05:34
Coke joined
06:09
uniejo joined
06:21
cxreg left
|
|||
| sorear | seen pmichaud | 06:23 | |
| purl | pmichaud was last seen on #parrot 1 days, 11 hours, 24 minutes and 53 seconds ago, saying: if spectests pass with that line removed, then +1 from me [Aug 30 18:58:07 2010] | ||
| aloha | pmichaud was last seen in #parrot 1 days 11 hours ago saying "if spectests pass with that line removed, then +1 from me". | ||
| sorear | msg bacek #perl6 @ irc.freenode.net needs a seen-bot | ||
| purl | Message for bacek stored. | ||
|
06:28
cxreg joined
06:33
jsut_ joined
|
|||
| dalek | rrot: r48748 | mikehh++ | failed to fetch changeset: [html_cleanup] merge trunk into branch |
06:35 | |
|
06:38
jsut left
07:01
chromatic left
07:04
cxreg left
07:05
cxreg joined
07:09
theory left
07:22
allison left
|
|||
| dalek | rrot: r48749 | NotFound++ | trunk/t/src/extend.t: rearrange other bunch of extend tests to make its coverage reports more useful |
07:25 | |
| rrot: r48750 | NotFound++ | trunk/t/pmc/exception.t: test Exception birthtime attribute and annotations method |
07:42 | ||
|
07:58
cognominal left
|
|||
| dalek | kudo: 606c5fb | moritz++ | src/core/operators.pm: prevent not and so from autothreading |
08:10 | |
| kudo: dc99008 | tadzik++ | src/Perl6/Grammar.pm: Added more info to an error message for <> Signed-off-by: Moritz Lenz <moritz@faui2k3.org> |
|||
| rrot: r48751 | mikehh++ | branches/html_cleanup/docs/index/tools.json: [html_cleanup] fix tools.json to handle moved file |
08:16 | ||
|
08:20
tcurtis left
08:22
mikehh left
08:44
mikehh joined
09:19
bacek joined
|
|||
| aloha | bacek: bacek asked me to tell you Blah | 09:19 | |
|
10:15
cotto_work left
10:54
ruoso left
11:33
bluescreen left
11:37
preflex left
12:09
whiteknight joined
12:13
hudnix left
12:14
hudnix joined
|
|||
| whiteknight | good morning, #parrot | 12:25 | |
| kthakore | whiteknight: good moin | 12:41 | |
| whiteknight | hello kthakore. How are you doing today? | 12:48 | |
|
12:50
bluescreen joined
12:54
cognominal joined
12:57
ruoso joined
13:01
nwellnhof joined
13:09
mikehh left
|
|||
| kthakore | whiteknight: ok | 13:17 | |
| whiteknight: back is killing me | |||
| I was cutting lumber yesterday | |||
|
13:22
luben left
13:23
luben_work joined
|
|||
| particle | nwellnhof: does STRING_iter_skip do the advancing part of STRING_iter_get_and_advance? if so, why not name it STRING_iter_advance for consistency? | 13:44 | |
| nwellnhof | you're right. that would be more consistent. | 13:48 | |
|
13:48
hudnix left
|
|||
| nwellnhof | but STRING_iter_skip also supports skipping of more than one char | 13:49 | |
| you can even skip backwards, so i think we should keep it | 13:51 | ||
|
13:52
hudnix joined
|
|||
| particle | so, is it seek rather than skip? | 14:01 | |
| nwellnhof | yes it's a relative seek. STRING_iter_set_position is an absolute seek. | 14:02 | |
| they could be combined like fseek. | 14:03 | ||
|
14:03
uniejo left
|
|||
| particle | hrmm | 14:04 | |
| is there a tell? | |||
| nwellnhof | the string iterator API has been like that before my changes BTW. but now would be a good time to change it. | ||
| particle | yes, agreed | ||
| nwellnhof | "tell" is reading the bytepos or charpos element of the iterator struct. | 14:05 | |
| there are no macros for that. | |||
| particle | does skip go by byte or grapheme? | 14:06 | |
| nwellnhof | it goes by codepoint | ||
| particle | actually, can you point me to where it's defined? i don't have a branch checkout atm | ||
| i'll look it up with svnweb | |||
| nwellnhof | it's defined for every single encoding. which one do you want? | 14:07 | |
| particle | ah, so that's why it's not in encoding.h... duh | ||
| what i'm thinking, when looking at this api is: if i were implementing e.g. fast boyer-moore, what functions would i want to use? how would i do that with this api? where could this be improved{ | 14:09 | ||
| s/{/?/ | |||
| nwellnhof | you would change the "index" function for each encoding | 14:10 | |
|
14:11
tcurtis joined
|
|||
| particle | i don't like STRING_length and STRING_byte_length, because the first macro assumes 'codepoint' | 14:11 | |
|
14:11
smash joined
|
|||
| smash | hello everyone | 14:11 | |
| particle | hola smash | ||
| nwellnhof | particle: what do you propose instead of STRING_length? | 14:12 | |
| particle | STRING_codepoint_length | ||
| put the units of measurement explicitly in the name | |||
| so later when STRING_grapheme_length comes around... nobody's upset. | 14:13 | ||
| nwellnhof | good point. | ||
| currently, we have Parrot_str_length and Parrot_str_byte_length | 14:14 | ||
| that's why i chose STRING_length and STRING_byte_length | |||
| particle | yes, and currently half our opcodes have underscores between words and half don't. | 14:15 | |
| we're marking a deprecation point here | |||
| let's take the time to get the api right as we change it | |||
| nwellnhof | yes, now would be the best time | ||
| particle | i know this is somewhat beyond what you've proposed, but i can't help but respond to the nagging urge to clean up the string api | 14:16 | |
| nwellnhof | that's perfectly ok, i already did some cleanups | ||
| like renaming get_codepoints to substr | |||
| get_codepoint to ord | 14:17 | ||
| like the parrot opcodes | |||
| particle | yes, it's a good form of consistency | 14:18 | |
|
14:19
patspam joined
|
|||
| nwellnhof | eventually, i'd like to have the code in string.ops call those macros directly | 14:19 | |
| that would save us one function call | |||
| kthakore | Does parrot have different types for numbers? | 14:22 | |
| I mean ... perl interchanges freely between IV,NV,PV, and the other one | 14:23 | ||
| nwellnhof | PV isn't a number type in Perl | 14:25 | |
| particle | kthakore: parrot has integer, number (floating point), string, and abstract data type (pmc) registers | ||
| kthakore | nwellnhof: perl interchanges between it freely | 14:27 | |
| particle: okie | |||
| nwellnhof | perl converts strings to numbers automatically | 14:28 | |
| but i wouldn't consider PV a number type | |||
| kthakore | well if I send a PV* from XS wrapped in a SV* | 14:29 | |
| I can use it as a number | |||
| nwellnhof | but it's converted before | 14:30 | |
| kthakore | sure | ||
| Coke | cotto: I distinctly remember that pirc was NOT fully headerized, and that andy had given up trying to make it so. Did you verify #43 before closing, or is that running on memory? | ||
| (I may have just not been around for the very last bit of fixup on that.) | |||
| cotto | That's from memory. | 15:04 | |
| except that I verified that headerizer didn't generate anything that wasn't already checked in | |||
|
15:07
jsut_ is now known as jsut
|
|||
| cotto | I do remember that some others (possibly bacek) worked on headerizing it. | 15:08 | |
| Coke | yah. and I remember them giving up. ;) | 15:09 | |
| in any case, probably worth double checking that the headerization works for all the pirc files before letting go of the ticket entirely. | |||
| I haven't touched ^/branches/pirc_config in a while, but all it did was add a configure option that controlled the setting of a C #define - it is probably mergable back to trunk, if someone wants to take it. | 15:11 | ||
|
15:11
Andy joined
|
|||
| Coke | ah, even better, it's a single commit. | 15:13 | |
| cotto | I'll do that. | ||
|
15:13
theory joined
|
|||
| Coke | some chunks failed trying to apply to trunk. ping me with problems or questions. | 15:14 | |
| looks trivial, though. | 15:15 | ||
|
15:41
patspam left
15:42
patspam joined
15:46
luben_work_ joined
15:49
luben_work left
16:11
nwellnhof left
16:35
cotto_work joined
|
|||
| sjn | seen jnthn? | 16:42 | |
| purl | jnthn was last seen on #parrot 7 days, 17 hours, 35 minutes and 44 seconds ago, saying: Maybe that link needs breaking at some point. [Aug 24 23:06:43 2010] | ||
| aloha | Sorry, I haven't seen jnthn. | ||
|
16:44
chromatic joined
17:08
luben_work_ left
17:24
nwellnhof joined
17:34
tcurtis left
|
|||
| moritz | jnthn is 1.5 weeks on vacations, or so | 17:53 | |
| cotto_work | lucky fellow | ||
|
17:54
davidfetter joined,
szabgab left,
tcurtis joined
17:55
chromatic left
17:56
szabgab joined
18:06
chromatic joined
|
|||
| dalek | TT #1761 created by dasx++: Inconsistent release tags | 18:11 | |
| TT #1761: trac.parrot.org/parrot/ticket/1761 | |||
|
18:13
chromatic left
18:17
patspam left
18:18
patspam joined
18:21
macroron joined
18:23
chromatic joined,
jsut_ joined
18:25
jan left
18:27
bluescreen left,
ash_ left,
bluescreen joined
18:28
jsut left
|
|||
| Coke | that bug should be easily fixable by anyone with access to drupal and the release guide. | 18:37 | |
|
18:44
ash_ joined
18:47
jsut joined
18:52
jsut_ left
19:07
robin-gvx joined
19:17
hercynium joined
|
|||
| dalek | rrot: r48752 | pmichaud++ | trunk/ext/nqp-rx/src/stage0 (5 files): [nqp-rx]: Update bootstrap with DEBUG fixes for cclass-based builtins. |
19:23 | |
| p-rx: 71b25e6 | pmichaud++ | src/Regex/Cursor-builtins.pir: Add regex debugging for cclass-based builtins. |
19:25 | ||
| p-rx: 29ce78f | pmichaud++ | src/Regex/Cursor-builtins.pir: Add debugging output to <alpha>. |
|||
| p-rx: 5349f17 | pmichaud++ | / (3 files): Comment out split() function for now; it causes the Parrot build to fail is repaired. |
|||
| p-rx: 699da41 | pmichaud++ | src/stage0/ (5 files): Update bootstrap. |
|||
|
19:27
mikehh joined
|
|||
| GeJ | Bonjour everyone. | 19:30 | |
| cotto_work | hi GeJ | 19:31 | |
| GeJ | servus cotto. | 19:37 | |
| dalek | rrot-linear-algebra: c20c635 | Whiteknight++ | src/pmc/complexmatrix2d.pmc: start improving POD for the ComplexMatrix2D type. |
19:53 | |
| rrot-linear-algebra: 973a792 | Whiteknight++ | src/pmc/complexmatrix2d.pmc: finish the documentation for ComplexMatrix2D.pmc |
|||
| rrot-linear-algebra: 0d73c5b | Whiteknight++ | src/pmc/ (2 files): update documentation in NumMatrix2D, and make some fixes/improvements back to ComplexMatrix2D |
|||
| rrot-linear-algebra: 3cc1c0d | Whiteknight++ | src/pmc/ (3 files): ...and documentation for PMCMatrix2D |
19:54 | ||
| rrot-linear-algebra: c2e4804 | Whiteknight++ | s (4 files): add html_pod to the output of the build. Also, fix up some of the pod files to actually pass podcheck |
|||
| rrot-linear-algebra: 0161a22 | Whiteknight++ | src/pmc/ (3 files): add headings to the POD so the generated HTML is more usable |
|||
| TimToady | phone | 20:00 | |
| moritz | speakiing of which, it's been quite some time since I've seen some notes about the phone calls | 20:02 | |
| chromatic | My fault; I'll get to those. | 20:03 | |
| moritz | ++chromatic | ||
|
20:05
luben joined
20:06
whiteknight left
20:12
jan joined,
ruoso left
|
|||
| dalek | TT #1762 created by nwellnhof++: Memory leak in Parrot_find_method_with_cache | 20:16 | |
| TT #1762: trac.parrot.org/parrot/ticket/1762 | |||
| TT #1763 created by nwellnhof++: Memory leak in PackFile_Annotations_new | |||
| TT #1763: trac.parrot.org/parrot/ticket/1763 | |||
| mikehh | All tests PASS (pre/post-config, make corevm/make coretest, test, fulltest) at r48752 - Ubuntu 10.04 i386 (gcc with --optimize) | 20:17 | |
| chromatic | Sweet gorilla of Manila! | 20:18 | |
| I've seen both before. I wanted to ask plobsing about TT #1763. | 20:24 | ||
|
20:24
ash_ left
|
|||
| tcurtis | If Rakudo doesn't work under the profiling core, is the problem likely in Parrot or in Rakudo? | 20:25 | |
| tcurtis wants to know where to submit the bug report. | |||
| cotto_work | probably parrot | ||
| and by "probably" I mean "" | 20:26 | ||
| chromatic | I couldn't get all of TT #1762, but I did get some of it. | 20:27 | |
|
20:30
perlite left,
perlite joined
20:31
robin-gvx left
|
|||
| Tene | chromatic: you ever look at TT #757 yet? | 20:32 | |
| chromatic | Probably. | 20:33 | |
| Oh yeah, I remember that code. | |||
|
20:33
ash_ joined
|
|||
| dalek | TT #1764 created by nwellnhof++: Infinite loop in exit handler | 20:34 | |
| TT #1764: trac.parrot.org/parrot/ticket/1764 | |||
| chromatic | I think cloning is probably the wrong approach there. | 20:35 | |
| Tene | I opened that ticket way back when I was trying to get threading to work at all. I couldn't get past it, and failed at understanding what the code was doing there at all. | ||
| chromatic | The basic idea is "Oh no, what if another thread modifies what the first thread thinks of as a class!" | ||
| Tene | I gave up on getting threading working after attacking that for a few days. | ||
| chromatic | Until we get a policy governing global modifications in threaded systems, I'm comfortable disabling cloning in general to see what happens. | 20:37 | |
| It's awful code, it doesn't work, and it's probably the wrong approach to concurrency anyway. | |||
| Coke misses the phone today due to $DAYJOB | 20:38 | ||
| kthakore | hi chromatic | 20:39 | |
| chromatic | howdy | ||
| kthakore | So I was setting up CUDA for my project and noticed python has pyCUDA (it uses Inline C like stuff) | ||
| is an Inline possible in Perl6 or Parrot? | 20:40 | ||
| chromatic | Parrot's made for that. | ||
| kthakore | chromatic: oh man been writing the Manual. it has pretty pictures! | ||
| chromatic: really! ... will it talk subset of the C language | 20:41 | ||
| as OpenCL and CUDA use other compilers | |||
| nvcc | |||
| but it should be able to make a shared library | |||
| chromatic | A subset of C? That's harder, but ... well Lorito and... hmm. | ||
|
20:41
ash_ left
|
|||
| tcurtis | How reliable is valgrind for finding memory leak problems? Specifically, if it's reporting at least 120-ish kb "definitely lost" on every Rakudo spectest, do I know that that's a problem? | 20:41 | |
| kthakore | tcurtis: you need to use a suppression script | 20:42 | |
| chromatic | I consider it highly reliable. | ||
| kthakore | find useless memleaks and add them to suppression | ||
| tcurtis: like chromatic said for reliability | |||
| chromatic | The only problem I've seen in Parrot without a suppression script is a weird dlerror() leak deep in what I think is Valgrind's ld replacement. | 20:43 | |
| kthakore | oh I have seen that before | ||
| that is acutally fixable | |||
| kthakore looks for linky from long time ago | |||
| issues.asterisk.org/view.php?id=16007 | 20:44 | ||
| err | |||
| so this is another project | 20:45 | ||
| that uses valgrind heavily | |||
| tcurtis | I ran a few of the files from examples/benchmarks and Parrot looked fine. Rakudo, not so much. Are there reasons that are not problematic for Rakudo having more than 120kb memory definitely lost? | ||
| Potential reasons, rather. | |||
| kthakore | chromatic: adding pthread_exit(NULL) at the end fixes this problem | ||
| chromatic | Really? Interesting. | 20:46 | |
| kthakore | tcurtis: what was the valgrind flags you used? | ||
| chromatic | tcurtis, TT #1762 may be a culprit. | ||
| Coke | msg whiteknight - preferred address for addition to directors list? | ||
| purl | Message for whiteknight stored. | ||
| Coke | msg dukeleto - preferred address for addition to directors list? | 20:47 | |
| purl | Message for dukeleto stored. | ||
| Coke | msg kid51 - preferred address for addition to directors list? | ||
| purl | Message for kid51 stored. | ||
| tcurtis | kthakore: --leak-check=full | 20:48 | |
| kthakore | tcurtis: can you paste the output? | 20:49 | |
| tcurtis | kthakore: I'm going to leave the spectests running when I go out to eat in a while. When I get back home, I'll work on sifting through and putting the results somewhere they can be looked at. There will be a lot of output. | 20:53 | |
|
20:55
ash_ joined
|
|||
| Coke | I'll just pick whatever their commonly used emails are at some point this evening if I don't hear back. NBD. | 21:00 | |
|
21:01
whiteknight joined
|
|||
| Coke | nwellnhof++ #leak finder | 21:02 | |
| dalek | TT #1765 created by nwellnhof++: Memory leak in allocate_interpreter | 21:08 | |
| TT #1765: trac.parrot.org/parrot/ticket/1765 | |||
| chromatic | That's a biggie. | 21:17 | |
| nwellnhof | i think it only happens if you create a new interpreter form PIR | 21:18 | |
| s/form/from/ | |||
|
21:19
patspam left
|
|||
| chromatic | Not from C? | 21:19 | |
| dalek | rrot: r48753 | NotFound++ | trunk/t/src/extend.t: rearrange remaining extend tests to make its coverage reports more useful |
21:20 | |
| nwellnhof | no, afaics | ||
| it seems to be specific to t/op/interp_2.pir | |||
|
21:21
patspam joined
|
|||
| chromatic | You'd think ParrotInterpreter's destroy() would destroy the contained interpreter. | 21:25 | |
| nwellnhof | but it doesn't | ||
| easy to fix | |||
| chromatic | Should do it. | 21:26 | |
| (says the person who skimmed the code in between editing the Perl 6 section on advanced method dispatch) | |||
| nwellnhof | hmm, there's no destroy_interpreter function | 21:34 | |
| only Parrot_really_destroy | 21:35 | ||
|
21:35
bluescreen left
|
|||
| nwellnhof | and it doesn't work to call that from the ParrotInterpreter PMC | 21:35 | |
| dalek | rrot: r48754 | Paul C. Anagnostopoulos++ | trunk (3 files): Integer neg and absolute now promote to BigInt |
21:37 | |
| rrot: r48755 | Paul C. Anagnostopoulos++ | trunk/t/op/integer.t: Integer neg and absolute now promote to BigInt (2) |
|||
| chromatic | That sounds like a problem. | ||
| Parrot_really_destroy() has guards if it's a child interp though. | 21:38 | ||
| NotFound | Parrot_destroy, Parrot_exit, and the way they are documented and used need some love. | 21:39 | |
| chromatic | Most of src/interp/ needs attention. | ||
| nwellnhof | calling Parrot_really_destroy from the PMC causes a crash in miniparrot | 21:40 | |
| ok, not so easy to fix | 21:41 | ||
| NotFound | The PMC is an envelope, you can't be sure that the Interpreter is owned bty it. | 21:42 | |
| dalek | TT #1616 closed by Paul_the_Greek++: t/pmc/bigint.t: implement 2 todo-ed items: Minint conversions | ||
| TT #1616: trac.parrot.org/parrot/ticket/1616 | |||
| NotFound | And the interpreter itself isn't garbage collected, so there is no easy solution. | 21:43 | |
| chromatic | Only the case where the PMC has created the interp matters, right? | 21:44 | |
| nwellnhof | i think so | 21:45 | |
| NotFound | I'm not sure, the interpreter mau remain active after the PMC is out of scope | 21:46 | |
| chromatic | We can steal one of the PMC flags. | ||
|
21:48
Paul_the_Greek joined
|
|||
| Paul_the_Greek | Grump. svn commit does a commit even if you list a file that has no changes. It should complain. | 21:49 | |
| cotto_work | orly? | 21:50 | |
| purl | YA RLY. | ||
| cotto_work | I thought it ignored any unchanged files. | 21:51 | |
|
21:51
kthakore left
|
|||
| Paul_the_Greek | It does. But obviously I typed the wrong file if it has no changes, so it should complain. | 21:51 | |
| No real harm done, except there are two revisions for my one change. | 21:52 | ||
| Say, another question: I have gnu patch. Is there some trick to getting it to understand our patch file format? | 21:53 | ||
| cotto_work | It should be fine without any special magic. | ||
| Paul_the_Greek | I enter patch <patch-file | 21:54 | |
| It doesn't recognize the Index: lines, so it asks me which file for each patch. | |||
| cotto_work | how did you get patch-file, i.e. what command? | ||
| NotFound | The problem with git diffs is the a/ and b/ prefixes | 21:55 | |
| Paul_the_Greek | I tried it with one I made (svn diff) and one someone else made attached to a ticket. | 21:57 | |
| Same problem in both cases. | |||
| Once you tell it the file(s), the patches are applied correctly. | |||
| There are some patch options that sound interesting, but I don't know patch-speak. | 21:58 | ||
| chromatic | alias ap='patch -p0 <' | ||
| alias gp='patch -p1 <' | |||
| ap means "Apply patch" | |||
| gp means "Apply patch generated by Git" | |||
| Paul_the_Greek | How does -p0 differ from not specifying it at all? | 21:59 | |
| chromatic | Consistency in my .alias file. | 22:00 | |
| Paul_the_Greek | I will try -p0 next time. Adding to alias file ... | ||
| chromatic | alias realias='chmod u+w $ALIASES; $EDITOR $ALIASES; source $ALIASES; chmod -w $ALIASES' | 22:01 | |
| NotFound | The man page says that omiting -p uses the filename without any dir in the path | 22:02 | |
| Paul_the_Greek | I just tried the same patch again with that option and I got a failed assertion in patch.c. That's amusing. | 22:04 | |
| chromatic | Sometimes I also think about taking up goat farming. | 22:05 | |
| Paul_the_Greek | I'll play with it some more later. | ||
| I'd go with llamas. | |||
| chromatic | There's an alpaca farm down the road here. | ||
|
22:05
mikehh left
|
|||
| Paul_the_Greek | Where are you? | 22:05 | |
| chromatic | Up the road from the alpacas. | ||
| Paul_the_Greek | And I can't get there from here? | 22:06 | |
| particle | realias doesn't pull/push to a github repo of dotfiles? for shame! | ||
| Paul_the_Greek | chromatic: Not sure we can improve Boolean, but I'm going to take a look at it over the next few days. | ||
| chromatic | If you can get a plane to PDX, take the red or blue line MAX west and stop at Sunset TC. Then take a shuttle up the hill. My office is up the hill from the lake. | ||
| Paul_the_Greek | Sounds nice. Never been out that way. | 22:07 | |
| chromatic | If you ever make it out here, maybe you can help me move a piano. | 22:08 | |
| Paul_the_Greek | No, sorry, you would hear very bad sounds from my spine. | ||
| I can help you hire someone, though. | 22:09 | ||
| chromatic | Ah, I already have percussive instruments. | ||
|
22:09
patspam left
|
|||
| Paul_the_Greek | Moving pianos is best done by professionals. | 22:09 | |
|
22:09
mikehh joined
|
|||
| NotFound | Software syntesizers are easier to move. | 22:09 | |
|
22:09
patspam joined
|
|||
| Paul_the_Greek | To make sure I understand: If I stop Boolean from inheriting from Integer or Scalar, it will inherit from Default? | 22:10 | |
| NotFound | I even have one in my pocket. | ||
| chromatic | Yes, that is correct. | ||
| Paul_the_Greek | Okay. | ||
| chromatic | All PMCs inherit from default, even if they don't mention it. They may inherit directly or through a parent, but they all ultimately inherit from default. | 22:11 | |
| NotFound | Default is the default. Sometimes we are consistent ;) | ||
| Paul_the_Greek | That is a reasonable name for the default, I must admit. | 22:12 | |
| Looking at Scalar's logical_and ... strange. logical_xor ... stranger. | 22:15 | ||
|
22:15
patspam left
|
|||
| Paul_the_Greek | Off for dinner, then some investigation. | 22:16 | |
|
22:16
Paul_the_Greek left,
nwellnhof left
22:25
mikehh left
|
|||
| dalek | rrot: r48756 | NotFound++ | trunk/t/pmc/stringiterator.t: test StringIterator get_pmc vtable |
22:29 | |
|
22:30
macroron left
22:32
jsut_ joined
22:37
jsut left,
ash_ left
|
|||
| chromatic | lambda-the-ultimate.org/node/4058 | 23:18 | |
| Articles on Precise GC with Parametric Polymorphism | |||
|
23:19
TiMBuS left
23:20
TiMBuS joined
|
|||
| cotto_work | That sounds too shiny not to look at. | 23:21 | |
| LtUU++ | |||
| LtU++ | |||
| chromatic | academic.research.microsoft.com/Pap...58308.aspx | 23:22 | |
|
23:25
mikehh joined
|
|||
| whiteknight | nice page | 23:26 | |
|
23:27
jsut joined
|
|||
| chromatic | I keep meaning to read that article. | 23:27 | |
| whiteknight | that's one I actually haven't seen yet, I don't think | 23:29 | |
| It's interesting the comment about Mono's GC, and how their JIT doesn't play nice with a precise stack trace | 23:30 | ||
| my one dream for Parrot is to get rid of walking the C stack entirely | 23:31 | ||
| chromatic | What C stack? | ||
| whiteknight | *the* C stack | ||
| there aren't many to choose from | |||
|
23:31
jsut_ left
|
|||
| chromatic | I know what the C stack is. I'm just wondering why your dream for Parrot includes it. | 23:31 | |
| whiteknight | my dream for parrot excludes it. We shouldn't be walking it. Ever | 23:32 | |
| chromatic | Okay, good. | ||
| whiteknight | Lorito should, *should* make it go away | ||
| although we run into a hell of a lot of problems in extensions | |||
| chromatic | That was like saying "My dream for my life includes not getting into slap fights with *clowns*." | 23:33 | |
| Why would you want to get into slap fights with anyone? | |||
| whiteknight | Well, there are some people that just might deserve it | ||
| Justin Beiber, Tiger Woods, most US senators | 23:34 | ||
| chromatic | My IRC client doesn't yet support the RSP. More importantly, neither do the clients of the people who most deserve it. | ||
| whiteknight | RSP? | ||
| purl | RSP is the most trivial perl code inverter possible. or remote strangulation protocol. | ||
| chromatic | I've still never heard Justin Bieber, but I had the TV muted and saw him in a music video with that little girl from the new Karate Kid movie. | 23:35 | |
| whiteknight | The problem with a GC that never walks the C stack though is that your JIT is going to have a hard time with it | 23:36 | |
| really, JIT wants to write it's own control flow. The resulting machine code won't look anything like the lorito runloop | 23:37 | ||
| chromatic | Only if you pass GCables to extensions that use the C stack. | ||
| whiteknight | the JIT will be descending into ops and API calls using the C stack. It won't be using a friendly runloop | 23:38 | |
| and Lorito methods may be block-compiled into functions. or traces might be | |||
| chromatic | Why would the JIT use C semantics? | ||
| whiteknight | they aren't C semantics. They're the semantics of the underlying machine, and the machine code that the JIT generates | 23:39 | |
| we could come up with a crazy system with jumps and no call/ret, but that seems to take more work than it provides benefit | |||
| C is just a shitty, mostly portable overlay of the metal | |||
| and most modern processors have been designed specifically to support and optimize for programms written in C | 23:40 | ||
| where the semantics differ is that we might not be passing parameters on the stack | |||
|
23:45
chromatic left
23:48
chromatic joined
|
|||
| chromatic | The places I've seen C beat out every other language on a real-world program are places where someone's written a custom Scheme that emits the world's ugliest C code (and I've patched Perl 5 itself and read a patch to PHP once) that no one sane would write. | 23:48 | |
| whiteknight | no argument there. | ||
| chromatic | I don't want to assume that our JIT will optimize things to standard C function calls. | 23:49 | |
| I'm not sure that's a good way to JIT a pervasively CPS program. | |||
| whiteknight | I don't either. But making the assumption that we can completely avoid call/ret machine codes is foolhardy | ||
| those aren't going away | |||
| chromatic | ... especially a program intended to achieve parallelism through pervasive CPS. | ||
|
23:49
smash left
|
|||
| chromatic | I'd honestly rather have the JIT emit *something* (register a bitmap for an area of the heap, for example) when it emits code to leave the area of precision and unregister it when it reenters than walk a stack or heap. | 23:53 | |
| That's really the problem: we lose precision at the boundary of untrusted code. | 23:54 | ||