|
Parrot 3.4.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today Set by moderator on 17 May 2011. |
|||
| mikehh | quite an interesting distribution though, not at all geographical | 00:00 | |
| sorear | mikehh: is it geographical if you consider the servers? | ||
| does a DNS round robin like irc.perl.org even TRY to place users with servers on the same continent? | 00:01 | ||
| opbots beleive dalek | |||
| opbots believe dalek | |||
| slavorgn | But I already believe dalek | ||
| slavorg | But I already believe dalek | ||
| sorear | opbots names | ||
| soh_cah_toa actually lol's | 00:02 | ||
| sorear | opbots trust lichtkind | ||
| slavorg | Ok | ||
| slavorgn | Ok | ||
| cotto_work | I like my packets to do a bit of world travel before they arrive at their destination. | ||
| mikehh | sorear: it doesn't seem to be that way, I mean bacek_at_work remained and aloha did not and I thought they were on the same server | ||
| I mean they even have the same hostmark | 00:04 | ||
| sorear | I have a suspicion that multiple MAGnet servers are claiming to all be irc.perl.org on /whois | 00:05 | |
| lichtkind | sorear: thanks | 00:07 | |
| sorear: i still have 2,3 questions :) | |||
| mikehh | sorear: I know I often connect to different servers as part of irc.parrot.org alias irc.perl,org | ||
| sorear wonders if "2,3" means "2 or 3" or en_US "2.3" | 00:08 | ||
| cotto_work | I had 3/10 of a question once. It never got answered. | 00:09 | |
| cotto_work heads home | |||
| soh_cah_toa | yay! | ||
| kid51 | If you are attending YAPC::NA::2011, make sure you are subscribed to yapc@pm.org. | 00:10 | |
| lichtkind | 2 | 3 | ||
| aloha | 3 | ||
| lichtkind | = 5 :) | ||
| soh_cah_toa | kid51: where's the link to subscribe? | ||
| lichtkind | niecza has only 1 branch? | 00:11 | |
| kid51 | soh_cah_toa: Probably: mail.pm.org/mailman/listinfo/yapc | ||
| soh_cah_toa | ok | ||
| kid51 | That mailing list actually pre-dates the conference registration system we now use, so you may not have been aware of it. | 00:12 | |
| In any case, at this time of year traffic on it heats up. | |||
| I just posted re: What do we do for dinner the night before the conference? | |||
| Always the most controversial topic. | |||
| seen autark? | 00:13 | ||
| aloha | autark was last seen in #parrot 9 days 9 hours ago joining the channel. | ||
| kid51 | And speaking of dinner ... | ||
|
00:13
kid51 is now known as kid51_at_dinner
|
|||
| davidfetter | bon appetit, kid51_at_dinner | 00:14 | |
| sorear | lichtkind: this is #parrot... niecza is kind of offtopic here. But yes it only has 1 active branch. | 00:15 | |
|
00:30
theory left
00:47
baest left
|
|||
| soh_cah_toa | cotto: ping | 00:52 | |
| cotto | soh_cah_toa, pong | ||
|
00:53
contingencyplan left
|
|||
| soh_cah_toa | cotto: i noticed something even more interesting. the error i got before was if i ran hbdb w/ parrot-prove.pbc. however, if i use the bytecode from a file that just does 'say("hello world")', it loops and loop and loops w/ no cli | 00:53 | |
| cotto | soh_cah_toa, a pir file? | 00:55 | |
|
00:55
lichtkind left
|
|||
| soh_cah_toa | cotto: no, bytecode | 00:56 | |
| cotto | soh_cah_toa, where did the bytecode come from? | 00:57 | |
| nqp or pir | |||
| or other | |||
| soh_cah_toa | pir | ||
| cotto | So it does. | 00:58 | |
| That's probably not an intentional feature. | |||
| and if it is, it's not a very good one | |||
| ;] | |||
| soh_cah_toa | uhh...definitely not | ||
| i think maybe my hbdb_start() function is never being called | 00:59 | ||
| or one of those | |||
| i have a few functions w/ while loops so i have several to investigate | |||
| the fact that it executes continuously but w/ no cli is weird | 01:00 | ||
| cotto | Wow. One of the comments in Parrot_runcode is from leo in 2003 | 01:01 | |
| Ubuntu's tab completion for makefiles seems to have gotten less smart recently. | 01:04 | ||
|
01:06
hudnix joined
|
|||
| soh_cah_toa | ha! i found it | 01:06 | |
|
01:07
kid51_at_dinner is now known as kid51
|
|||
| soh_cah_toa | i couldn't figure out why there was no cli. that is, until i saw the comment "TODO: Start command-line here" | 01:07 | |
| :) | |||
| cotto | there you go | ||
| soh_cah_toa | alright, so now it echoes input. the right way. before was just a quick fix | 01:08 | |
| now i'm gonna try and get it to print each opcode | 01:09 | ||
| actually, first i want to fix the hbdb_destroy() issue | |||
| cotto | also, strings | 01:11 | |
| soh_cah_toa | egh...parrot strings annoy me | 01:12 | |
| fine... | |||
| cotto | actually, destroying the runloop should go in src/runcore/cores.c. destroying the debugger should go elsewhere | 01:14 | |
| soh_cah_toa | ok. yeah, i do see any of the runcores using a function to destroy the runloop | 01:16 | |
| *don't | |||
| cotto | only the profiling runcore needs it | ||
| soh_cah_toa | yup, there it is | 01:17 | |
| cotto | one nice thing about STRING*s is that you don't have to care about freeing them. | ||
| soh_cah_toa | you don't have to free char * either b/c they're static | 01:19 | |
| cotto | sometimes | ||
| soh_cah_toa | it's just really annoying to perform otherwise simple string operations. assigning to a char *, all you need is an = sign (or strcpy(), it depends). assigning to a STRING, there's a bunch of different functions and you have to identify which one; scrolling through perldoc, generating segfaults if you guess wrong. where otherwise a single '=' would've worked | 01:23 | |
| .1 seconds compared to 1+ minutes of guesswork | 01:24 | ||
| sorear | soh_cah_toa: congratulations, you're starting to understand why Parrotfolk want to stop coding in C ASAP | 01:27 | |
|
01:27
kid51 left
|
|||
| soh_cah_toa | yeah, there's a lot of things i...dislike...about parrot c code. i'm actually planning on bringing those things up at yapc | 01:30 | |
|
01:31
whiteknight left
|
|||
| cotto | soh_cah_toa, keep a list going | 01:31 | |
| soh_cah_toa | yeah, by yapc time, i'd like to have a small proposal. listing the disadvantages to some things and offering alternatives | 01:32 | |
| sorear | C is basically horrible at anything to do with user-defined data types | ||
| C++ is better at that, but has its own problems | |||
| soh_cah_toa | hmm...as much as i love c, i'd have to agree w/ that very much | 01:33 | |
|
01:35
rurban joined
|
|||
| soh_cah_toa | in a nutshell, my concern is mostly ugly naming/style conventions and lack of inline comments. i'd like to just have stricter guidelines for those things | 01:36 | |
| it's definitely not as important as something as m0, but after gsoc i'd definitely be willing to write a draft. i think clean code is very important | |||
| cotto | The thing about changing conventions is that someone has to do it. | 01:41 | |
| dalek | rrot/soh-cah-toa/hbdb: 51aa664 | soh_cah_toa++ | src/hbdb.c: Fixed runtime error about Getopt/Obj.pbc missing. Now echoes command input successfully (the right way) |
||
| rrot/soh-cah-toa/hbdb: 3c48b51 | soh_cah_toa++ | / (3 files): Removed definition of Parrot_api_hbdb_get_command() as hbdb_get_command() is a core function and the frontend shouldn't call it directly |
01:42 | ||
| soh_cah_toa | i'd be more than willing come next semester | ||
| cotto | and the reasons for doing so are less technical and more personal preferential | ||
| soh_cah_toa | hmm...true. but the less strict guidelines are, the crazier code looks over time. regardless of what the actual guidelines would be, i'd just like to see more consistency | 01:45 | |
| bubaflub | NotFound: ping | 01:46 | |
| soh_cah_toa | the actual style conventions we have actually aren't that bad. it's the naming conventions though that'd need improvement | ||
| but anyway, it'd be easier to discuss face-to-face and when i actually have some kind of organized proposal written up | 01:48 | ||
| b/c i don't want it to come off as just a rant :) | |||
| cotto | deal | 01:49 | |
| soh_cah_toa | it's going to be great at the hackathon to have everyone together in one time zone :) | 01:51 | |
| bubaflub | soh_cah_toa: wish i could be there | 01:55 | |
| soh_cah_toa | bubaflub: do you have prior engagements or it's just too far away? | 01:58 | |
|
01:58
kid51 joined
|
|||
| sorear | soh_cah_toa: yapc::eu? | 02:01 | |
| soh_cah_toa | yapc::na | ||
|
02:01
plobsing joined
|
|||
| kid51 | yapc::na::2011? | 02:01 | |
| soh_cah_toa | yeah | 02:02 | |
| kid51 | Hmm, I thought I had taught aloha that. | ||
| aloha, YAPC::NA::2011 is www.yapc2011.us/yn2011/ | |||
| aloha | kid51: Okay. | ||
| kid51 | aloha, YAPC::NA is www.yapc2011.us/yn2011/ | ||
| aloha | kid51: Okay. | ||
| kid51 | aloha, YAPC is www.yapc2011.us/yn2011/ | ||
| aloha | kid51: ... but YAPC is intended as an affordable high-quality conference, but there is a fee of some kind ... | ||
| kid51 | aloha, YAPC is also www.yapc2011.us/yn2011/ | 02:03 | |
| aloha | kid51: Okay. | ||
| kid51 | aloha: YAPC? | ||
| aloha | kid51: YAPC is intended as an affordable high-quality conference, but there is a fee of some kind or www.yapc2011.us/yn2011/ | ||
| kid51 | nice bot | ||
| bubaflub | soh_cah_toa: i originally was going to give a talk, but then my car broke down - i could either afford the conference or, you know, driving. | ||
| cotto | bubaflub, yapc speakers don't have to pay admission | 02:04 | |
| bubaflub | cotto: getting there + hotel would have set me back too much | ||
| cotto | that's true | ||
| and the cost of not going to $dayjob | |||
| bubaflub | cotto: we're finishing paying off my tuition and my wife is going back to school in the fall. | ||
| cotto: yeah, if i were full time at $dayjob i might have gotten a free pass... they usually send a few people every year | 02:05 | ||
| cotto | I should try that. It'd be fun to get a Drupal/.Net shop to pay for me to do a Perl conference. | ||
|
02:06
davidfetter left
|
|||
| dalek | rrot-gmp: 4ce91a5 | bubaflub++ | src/GMP/Integer.winxed (2 files): add vtable override for get_string() |
02:11 | |
| rrot-gmp: 5c6ee5e | bubaflub++ | / (3 files): access the underlying pointer rather than the Winxed object this fixes mpz_add, mpz_mul, mpz_sub, and mpz_swap |
|||
| kid51 | bubaflub: terrestrial location? | 02:12 | |
| bubaflub | kid51: central illinois | ||
| kid51 | Ah, non-trivial drive. | ||
| bubaflub | kid51: yeah, i thought about that - i think it's 10 or 12 hours. which i *could* do but i'm not sure if i can get the time off of $dayjob | 02:14 | |
| benabik | bubaflub: I'm driving 12 hours... Possibly 16 if I detour through my parent's house. | ||
| kid51 | www.yapc2011.us/yn2011/wiki?node=RideShare possibly helpful | 02:18 | |
| kid51 must sleep | 02:19 | ||
| benabik | kid51++ | ||
|
02:20
kid51 left
|
|||
| soh_cah_toa | is there a function where i can print the name of an opcode along w/ it's arguments given its opcode_t value? i'm not sure where to look for this | 02:31 | |
| pretty much, what i want to do is just print all the opcodes in a pbc file one by one | |||
| sorear | look in pbc_disassemble? | 02:38 | |
| cotto | I don't think there's a function, but the op_info_table struct has all that information | ||
| pbc_disassemble should be helpful | 02:39 | ||
| soh_cah_toa | oh yeah | ||
| i may already know the answer to this but i just want to make sure... | 02:46 | ||
| does headerizer "headerizer" a file even if no changes in its respective .c file where made? is it smart enough to just "headerizer" new functions? | |||
| b/c whenever i define a new function and run headerizer and then re-compile, EVERYTHING gets rebuilt | |||
| sorear | you already know the answer | 02:47 | |
| soh_cah_toa | alright, just wanted to make sure my makefile wasn't configured wrong or something | 02:48 | |
| cotto | You can manually headerize a single target by specifying a .o file. I'm usually too lazy. | 02:49 | |
| soh_cah_toa | oh that's right | ||
|
02:55
pjcj joined
|
|||
| dalek | rrot-gmp: bee2a23 | bubaflub++ | t/integer/ (2 files): fix addmul and submul had my order of operations wrong, the real functions compute rop +- (op1 * op2) also remove a debug statement |
03:00 | |
| bubaflub | yay, now my entire test suite passes. time to write more tests. | ||
| soh_cah_toa | lucky ;) | ||
| bubaflub | soh_cah_toa: it's just because i don't have to deal with IMCC, line numbers, PIR, C, parrot guts... | 03:01 | |
| soh_cah_toa | ha! | ||
| cotto | soh_cah_toa, your entire test suite passes too. | 03:02 | |
| bubaflub | soh_cah_toa: how's the project coming along? | 03:03 | |
| cotto | hint hint | ||
| soh_cah_toa | ha! 2x | ||
| hmm...well i was stuck for a long time so i lost a bit of time. now i'm working on things that should've been done from the start | 03:04 | ||
| eh, you learn though | |||
| cotto | yup. learn and write tests | 03:06 | |
|
03:07
slavorgn left,
slavorgn joined
|
|||
| bubaflub | soh_cah_toa: yeah, no plan survives contact with the enemy. | 03:09 | |
| cotto | imcc being the enemy in this case | ||
| soh_cah_toa | you beat me to it :) | ||
| cotto | a lot of things don't survive contact with imcc | ||
| benabik | cotto++ | 03:14 | |
| soh_cah_toa | speaking of tests, that reminds me of something i wanted to ask... | 03:15 | |
| you said that writing tests before you code is a nice way to see how things will work before you even implement it. that makes sense. | |||
| however, doesn't that leave me open to all kinds of bugs that the compiler would otherwise catch right away? i mean, i can't syntax check my tests | |||
| i'm mostly referring to the c_output_* functions where you actually type the tested code inside heredocs. which is what i'm gonna have to use here | |||
| sorear | it doesn't really matter whether the tests are correct, as long as they test something | 03:17 | |
| the idea of testing is that you won't screw up twice in the same way | |||
| just make sure you don't have tests that cannot fail | |||
| cotto | soh_cah_toa, you should really think about how to write hbdb so that it's amenable to automated testing. Testing C internals is not preferable because it means you're often testing the internals rather than the output. | 03:19 | |
| and yes, it's not vitally important that your tests be perfect. You can fix any bugs you find once you're able to start running them. | 03:20 | ||
| soh_cah_toa | well, take t/src/basic.t for example. at line 29 is one of the c_output_is() functions i'm talking about. inside the heredoc, suppose i leave off a semicolon, i'm not gonna get a "syntax error at line blah blah blah" message | 03:21 | |
| cotto | That's one of many reasons to minimize the number of C tests. | 03:22 | |
| soh_cah_toa | but everything i have is c | ||
| cotto | You can check it manually by running the foo_12.c files that Test::More generates, but that's clunky. | ||
| Sure, but you don't need to test C with C. You just care that, for a given input, you get something that looks like the right output. | 03:23 | ||
| It's a little bit trickier because of the interactive nature of a debugger, but there should be a reasonable strategy for writing useful tests. | 03:24 | ||
| soh_cah_toa | well that's another thing. i don't really know how to "think about how to write hbdb so that it's amenable to automated testing." sadly, i'm just not really sure what that means (thank you college) | ||
| cotto | What's your understanding of how a test should work? | 03:25 | |
| soh_cah_toa | it just tests that your code does what it's supposed to do. how it does that... ??? | 03:26 | |
| bubaflub | soh_cah_toa: there are really two ways to go about testing, at least as i see it | 03:27 | |
| soh_cah_toa: unit tests might test individual functions or blocks of code - give it a certain input and a certain output should happen | |||
| soh_cah_toa: integration tests can actually test a full stack of code | 03:28 | ||
| cotto | Tests are a way of running code under controlled and monitored conditions that are known to exercise a specific behavior. | ||
| bubaflub | soh_cah_toa: in your case, you may want both. the unit tests can make sure that, for example, individual functions are doing exactly what you want them to do. even if it's trivial functionality, it can sometimes save your bacon. | ||
| soh_cah_toa: an integration test would actually automate a run of the debugger - say, load a file, set a break point, continue, and verify that you in fact stopped at that point | 03:29 | ||
| soh_cah_toa | integration sounds like it may be a little harder in my case since it's an interactive program | ||
| cotto | yes, but it's also important | 03:31 | |
| bubaflub | soh_cah_toa: it is more difficult - for example, when we do integration tests for websites, we'll have to actually tell a program to go to a certain page, enter a user name and a password, hit the submit, and so on and so forth | ||
| soh_cah_toa: for some integration tests we'll even need to run javascript or automate a browser | |||
| soh_cah_toa: but it's great when we know we broke something | 03:32 | ||
| soh_cah_toa: and the integration test is the real selling point - we want a certain set of actions to work (such as setting a breakpoint, inspecting a variable, etc.) rather than just individual functions | |||
| cotto | bubaflub, I wish my $dayjob did that. The big weakness of (pre 7.0) Drupal is a lack of testing infrastructure. | ||
| bubaflub | cotto: yeah, we've got some Catalyst and other perl frameworks. we use WWW::Mechanize and cousins. | 03:33 | |
| cotto | cpan ftw | ||
| bubaflub | cotto: testing in PHP is just difficult | ||
| cotto: rather, from my limited experience, i'm not sure which testing framework to use in PHP | |||
| cotto | Testing is not an idea generally embraced in PHPland from what I've seen. | ||
| I'm really glad Parrot inherited its testing culture from Perl. Perl definitely gets it right. | 03:34 | ||
| bubaflub | cotto: agreed. | ||
| soh_cah_toa: testing can be a bit overwhelming and non-intuitive at first, but it's just a simple mechanism to *automatically* verify sanity on certain actions. test driven development takes this one step further and says you should write your tests first, then write the code for it to pass. | 03:35 | ||
| soh_cah_toa: and yes, it is probably difficult to test in C or PIR the debugger; you may have to do some heavy lifting in another language to do something as crazy as an integration test. | 03:36 | ||
| soh_cah_toa: and i'm more than happy to look over tests or bounce ideas off of if you need it | 03:37 | ||
| soh_cah_toa | another thing, whenever i learn how to actually do all this, when do know when i have enough coverage? | 03:38 | |
| when is enough, enough? | |||
| cotto | soh_cah_toa, I'm glad you asked. make cover will tell you how much you have. It's up to you to figure out if a bit of code is worth covering or not. | ||
| soh_cah_toa | ok | 03:40 | |
| cotto | You should cover anything that can reasonably be covered. | ||
| Testing if a malloc fails isn't necessary. | |||
|
03:42
theory joined
|
|||
| cotto | soh_cah_toa, if all you did tomorrow was figure out a way to run integration tests on hbdb, I'd consider that a day well spent. Once you get the idea in your head, the rest is a smop. | 03:43 | |
| soh_cah_toa | the thing that frustrates me the most is that i can't even identify what it is i don't understand about testing. | 03:45 | |
| i can clearly see why it's so important. i can see when it needs to be done. | |||
| but when i think about what this means for hbdb, my mind just goes "wait...what?" | |||
| cotto | write some pseudocode | ||
| soh_cah_toa | for? | 03:46 | |
| cotto | for the test harness, for a test, for whatever | 03:47 | |
| sorear | cotto: I thought Parrot used a malloc wrapper that *cannot* return null | 03:50 | |
| cotto | sorear, yes. That's just an example of an unusual corner case. | 03:51 | |
|
04:05
bubaflub left
|
|||
| soh_cah_toa | i think i just thought of something i can test by tomorrow | 04:06 | |
| the next thing i was gonna do is parse the input to check that it's an actual command | |||
| i could write a test that fake inputs a real command and make sure it's recognized and then fake input garbage and make sure it isn't regcognized | |||
| cotto | That'd be a great start. | 04:08 | |
| soh_cah_toa | ah, yes | ||
| +1 for me | |||
|
04:09
losinggeneration joined
|
|||
| cotto | sleep sort is my new favorite algorithm | 04:09 | |
| dis.4chan.org/read/prog/1295544154 (sfw) | 04:10 | ||
|
04:11
lg_quassel left
|
|||
| soh_cah_toa shudders | 04:11 | ||
| sorting algorithms are my greatest weakness | 04:12 | ||
| cotto | It's hilarious. | 04:13 | |
| soh_cah_toa | especially the comment "oh god, it works" :) | ||
| benabik | Guh. I've been staring at code all day and I still have no idea _why_ this fails. | 04:19 | |
| soh_cah_toa | ah, i get it. larger numbers sleep longer so the smaller ones return in order from small to big | 04:22 | |
| that's awesome | |||
| cotto | yup | 04:23 | |
| so ridiculous, yet so brilliant | |||
| soh_cah_toa | yeah, wow. that is pretty genius | ||
| plobsing | personally, I still prefer the bogosort | ||
| soh_cah_toa | it is simple, i'll give it that | 04:25 | |
| benabik | Radixsort blew my mind. O(n) sorting. | 04:28 | |
| cotto | karma lulzsec | 04:33 | |
| aloha | lulzsec has karma of 0. | ||
| soh_cah_toa | cotto: anyway, i'm trying to go through some code thinking "how could this possibly go wrong?" and if there's some way it could, then (i hope) it needs a test | 04:34 | |
| is that a good approach? | |||
| benabik | ... This has to be a bug elsewhere that's just exposed when I make this change. Gah. I hate this. Maybe if I bisect and apply the change on top of random commits... | 04:35 | |
| cotto | soh_cah_toa, you could do worse. The first thing to test is the normal expected usage, though. After that, go nuts. | ||
| benabik is slowly going crazy. | |||
| Crazy going slowly am I. | |||
| soh_cah_toa | oh right. i'm just trying understand what kinds of things would need to be tested | 04:36 | |
| cotto | soh_cah_toa, anything you can write a test for is fair game. | 04:37 | |
| plobsing | soh_cah_toa: a decent goal is at least one run through of every code path | ||
| soh_cah_toa | alright, well atleast i have somewhere to start tomorrow. i have a feeling that i'll be just fine after the first step | 04:38 | |
| cotto | Yeah. Getting the first test written will be the hard part. After that is the slightly less hard part. | 04:39 | |
| well, several of them | |||
| benabik | Yessss... The base tempreg commit passes, so I must have goofed something else! (YOU ALL GET TO HEAR MY MADNESS!) | ||
| Debugging register allocation is "fun". | 04:40 | ||
| soh_cah_toa | hasta la pasta amigos | 04:41 | |
|
04:42
soh_cah_toa left
|
|||
| cotto | www.youtube.com/watch?v=QH2-TGUlwu4 <-nyan cat + extra nyan cat | 04:44 | |
| benabik | How did they do that? That's crazy. | 04:45 | |
|
04:45
davidfetter joined
|
|||
| cotto | step 1: get 15+M views | 04:46 | |
| benabik | Hah | ||
| step 2: amuse some bored Google engineers? | |||
| cotto | I guess so | 04:47 | |
| tadzik | I feel disturbed than the background moves at a different tempo than the music | 04:50 | |
| benabik | Yes, THAT's the disturbing part. | 04:53 | |
| tadzik | also, when people sing a capella and can't hold the pause | 04:54 | |
| benabik | My constant is changing. NQP needs real constants. :-( | 05:15 | |
| ... Incrementing an Integer PMC changes the PMC directly doesn't it. Integers aren't constant. Guh. | 05:17 | ||
| sorear | yeppp | 05:18 | |
| benabik | I think that's what was doing it. I bound a variable to a "constant", incremented the variable and that changed the constant. | 05:19 | |
|
05:24
Kulag left
|
|||
| benabik | I just discovered the bug when I changed enough other code that overlap started happening. Wheeeee... | 05:25 | |
|
05:26
Kulag joined
|
|||
| tadzik | oh | 05:29 | |
| benabik | Looks like I may be done with this bug driving me mad. | 05:36 | |
| Time to find the next thing that'll make me crazy. | |||
| tadzik | how about imcc? :) | ||
| benabik | Oh that keeps popping up, but I've usually found the sorting through the PIR based on method name and error will generally get me to a useful `.annotate 'line'` | 05:37 | |
| Not that that's how I want to spend my time, mind you. | 05:38 | ||
| tadzik | examtime & | 05:39 | |
| benabik | I appear to have caught up with pmichaud's work. Wheee... Now to test nqp-rx's master on it. | 05:42 | |
|
05:49
allison left
05:50
allison joined
05:54
rurban_ joined
05:56
rurban left,
rurban_ is now known as rurban
05:57
theory left
06:10
contingencyplan joined
06:21
janus left
06:30
woosley joined
|
|||
| benabik | codetest is complaining about ops_not_tested.pl missing. :-/ | 06:50 | |
| Oh, reconfig fixed it. *sigh* The coupling between code changes, MANIFEST, and configure is a hazy one. | 06:53 | ||
| cotto | and makefiles | 06:56 | |
| sorear | when in doubt, git clean -dfx | ||
| "realclean" targets are subtly broken most of the time when they exist at all | 06:57 | ||
|
07:02
fperrad joined
07:19
mj41 joined
|
|||
| dalek | rrot/nqp_pct: cff934f | benabik++ | compilers/pct/src/P (22 files): Re-bootstrap PCT to remove broken-ness Old bootstrap had bad code to generate contextuals, making it impossible to rebootstrap without manual intervention. That intervention has now been done and code can move on. |
07:19 | |
| rrot/nqp_pct: 12dba40 | benabik++ | / (6 files): [pct] Add PAST::Stmt, UNIQUE_BASE and TEMPREG_BASE From:\t8392f3192d04c7e8c069d6690b053980208dee6b Author:\tpmichaud <pmichaud@pobox.com> |
|||
| rrot/nqp_pct: c754a26 | benabik++ | compilers/pct/src/PAST/Compiler.pm: [pct]: Code for managing temporary register pools From:\t7e3b1613648d0074e0ab33566d438c0239b20a14 Author:\tpmichaud <pmichaud@pobox.com> |
|||
| rrot/nqp_pct: 3457fe4 | benabik++ | compilers/pct/src/PAST/Compiler.pm: [pct]: Use tempreg in coerse, pirop, and Val Have register coercion, :pasttype<pirop>, and PAST::Val use temporary registers. This greatly reduces the number of registers used in any given sub. From:\te2eab899fb167d40a1c85aa0425e1593c3758dc9 Author:\tpmichaud <pmichaud@pobox.com> |
|||
| rrot/nqp_pct: 04ef874 | benabik++ | compilers/pct/src/PAST/Compiler.pm: [pct]: tempreg in immediate block, if, for, return Use temporary registers in immediate block return values, method/sub calls, :pasttype<if>, :pasttype<for>, and :pasttype<return>. From:\t190bf17a32c0bbdb3fb999496dc2f7874a027c06 Author:\tpmichaud <pmichaud@pobox.com> |
|||
| rrot/nqp_pct: 1d4622f | benabik++ | compilers/pct/src/PAST/Compiler.pm: [pct]: No tempreg inside exception handlers Temporary registers and exception handlers might not mix, so disable temporary register generation while processing handlers. PAST's built-in loop handlers ought to be safe, however. From:\t72a56d9dc12b663a95bcdefa7c666304849c7f06 Author:\tpmichaud <pmichaud@pobox.com> |
|||
| rrot/nqp_pct: 0445396 | benabik++ | compilers/pct/src/PAST/Compiler.pm: [pct]: tempreg in vivi*, force unique in .lex Update 'viviself' and 'as_vivipost' to use shared temporary registers, force ".lex" declarations to always use a non-shared registers. From:\tefc90318a5d1232b02a04b4c4c56d1ac8067b001 Author:\tpmichaud <pmichaud@pobox.com> |
|||
| rrot/nqp_pct: 8783a78 | benabik++ | compilers/pct/src/PAST/ (2 files): [pct]: Let PAST::Block have its own tempregs Add the ability for a PAST::Block to start a completely new temporary register bank. From:\t6a763d7d00d6800c30d5d8b79b8dc4d4a86ffab4 Author:\tpmichaud <pmichaud@pobox.com> |
|||
| rrot/nqp_pct: ea9260c | benabik++ | compilers/pct/src/PAST/Compiler.pm: [pct] Stmt - don't reserve return in void context Don't reserve a Past::Stmt's return register when in void context. From:\tfb77d3c5719dba4f06a2f35672c279d90d47917f Author:\tpmichaud <pmichaud@pobox.com> |
|||
| rrot/nqp_pct: 0ebb103 | benabik++ | compilers/pct/src/P (23 files): Re-bootstrap PCT to get PAST::Stmt Now NQP-ized PCT can compile NQP-rx's master. Excellent. |
|||
| rrot/nqp_pct: 0ab886e | benabik++ | / (13 files): Merge branch 'master' into nqp_pct Conflicts: \tcompilers/pct/src/PAST/Compiler.pir \tcompilers/pct/src/PAST/Node.pir |
|||
| benabik | Okay, that's it. Show's over. ;-) | ||
| moritz | :-) | 08:27 | |
| tadzik | :) | 09:22 | |
|
09:33
Drossel joined
09:34
Kulag left
09:41
Drossel left,
Kulag joined
09:47
Kulag left
09:52
Drossel joined
10:08
lucian joined
10:25
woosley left
10:36
RobertLJ joined
11:03
ambs joined
|
|||
| pmichaud | ~/lastlog pmichaud 5 | 12:24 | |
| oops | |||
| moritz | good morning pmichaud :-) | 12:25 | |
| pmichaud | good morning, #parrot | ||
| still getting used to this new keyboard | |||
|
12:33
bluescreen joined
12:36
GodFather joined
12:37
cosimo joined
12:49
cosimo left
12:50
GodFather left
12:56
benabik left
13:00
mtk joined
13:08
bubaflub joined
|
|||
| tadzik | hello pmichaud | 13:11 | |
|
13:30
whiteknight joined,
mtk left
|
|||
| whiteknight | good morning, #parrot | 13:30 | |
| tadzik | good afternoon whiteknight | 13:31 | |
| whiteknight | hello tadzik, how are you doing today? How is the project going? | ||
| tadzik | not bad. I had a math exam today, which I think I should pass, and I got my shiny Kindle today \\o/ | 13:32 | |
| whiteknight | oh fun. | ||
| I've been kicking around the idea of getting a kindle, but I like having a physical book in my hands too much | |||
| tadzik | and gsoc is doing good, I managed to get no slips due to university mess, everything's to the schedule | ||
| whiteknight | oh nice. Sticking to schedule is the hardest part | ||
| tadzik | I have to many books on my hdd which I really want to read, but reading from the screen sucks so much | ||
| pmichaud | I got a Galaxy Tab for reading e-books (incl Kindle books); now I greatly prefer it to the physical kind of book. | 13:34 | |
| (which surprised me a bit) | |||
|
13:34
redicaps joined
|
|||
| moritz | I've had an ebook reader in my hand once, and it took about 3s to flip to the next page | 13:35 | |
| which annoyed me to no end | |||
| tadzik | it takes about 3/4s on my Kindle | ||
| OTOH, you get a 14-30 days of battery life :) | 13:36 | ||
| pmichaud | yes, a 3s flip would be annoying. | ||
| moritz | 3/4 s sounds tolerable | ||
| atrodo | moritz> Same reason I hate digital cable. Waiting over a second for a channel change when analog is instant drives me bonkers | ||
| tadzik | yeah, it's like flipping a physical page :) | ||
| and I got back to reading HPatMoR :) | |||
| whiteknight | atrodo: yes, channel change delays drive me bonkers. Much more than they really should | 13:37 | |
|
13:37
mtk joined
|
|||
| tadzik has no TV | 13:37 | ||
| whiteknight | it's amazing how such a little inconvenience seems like such a big thing | ||
| pmichaud | I like that I can stand the Tab on its side on the table or desk in front of me and not have to hold it. With a book I have to hold it open or it's not at an appropriate viewing angle. | ||
| tadzik | well, I pay for one, they don't sell internets w/o a TV | ||
| moritz | pmichaud: sounds like it would be very useful for me, since I often have only one hand free when carrying or holding the toddler | 13:38 | |
| tadzik | :) | ||
| whiteknight | I'm also weary of getting anothet gadget. Between my phone, my laptop, and my gameboy, I don't think I have any more love to spread around | ||
| my wife and kid already get the short end of that stick :) | |||
| atrodo | whiteknight> wife and kids are overrated, gadgets are where it's at | 13:39 | |
| pmichaud | pmthium.com/wp/wp-content/uploads/2...asel-1.jpg # picture of Tab standing | ||
| atrodo also glad his wife doesn't get on irc | |||
| tadzik | pmichaud: nice indeed | ||
| whiteknight | atrodo: I've had to put my kid in time-out twice for breaking my laptop. I've never had to put my laptop in time-out for hurting my kid. Not once. Food for thought | 13:40 | |
| atrodo | whiteknight++ infallible logic | 13:41 | |
| pmichaud | whiteknight: that's only because your kid isn't old enough to be hurt by your laptop :) | ||
| whiteknight | pmichaud: that's true. Right around when I turned 15 or 16 was when I was irrepairably damaged by the internet | ||
| atrodo | pmichaud> or he hasn't figured out a screwdriver and which wires not to bridge | ||
| pmichaud | I frequently have to protect the kids here from the laptops... the laptops are always demanding their attention when they should be outside playing or doing homework or cleaning the house :) | 13:42 | |
| atrodo | Now that brings back memories of childhood | ||
| whiteknight | actually, I had a friend back then with a cable descrambler. That did much more damage than the internet at the time. Delivered nudity at much higher bandwidth | 13:45 | |
|
13:46
UltraDM joined
|
|||
| whiteknight | so many things I need to try and keep my kid away from! | 13:47 | |
|
13:55
rurban_ joined
13:58
plobsing left,
rurban left,
rurban_ is now known as rurban
14:01
benabik joined
|
|||
| benabik | Good morning, #parrot | 14:02 | |
| tadzik | good morning benabik | ||
| benabik | tadzik: What's happening? | 14:03 | |
| bubaflub | ~ | 14:04 | |
| tadzik | benabik: playing with my new kindle | 14:06 | |
| benabik | tadzik: Sounds productive! :-D I got a Sony e-Reader a couple years back. It was really nice when I could find properly formatted eBooks. | 14:07 | |
| moritz | tadzik: how does "Using Perl 6" look on the kindle? :-) | 14:08 | |
| tadzik | Calibre is able to convert stuff pretty nicely. I turned my Higher Order Perl into a .mobi, .pdf if free while Kindle dition costs like 30 bucks on amazon | ||
| moritz: haven't tried it yet :) | |||
| Modern Perl looks nice | |||
| the unofficial mobi of it at least | |||
| benabik | The new iterations of eInk screens make me tempted to switch up, but I tend to use my iPad more anyway. | 14:09 | |
|
14:36
hercynium joined
|
|||
| NotFound | whiteknight: I have a phone, a tablet, a miniportable, two laptops and a NDS. | 14:48 | |
| Eh... no... two NDS in fact. | 14:49 | ||
| whiteknight | NotFound: ETOOMANYGADGETS | 14:51 | |
| NotFound | And I still miss an ebook reader, I don't enjoy reading on the tablet. | 14:52 | |
| benabik | NotFound: Which tablet? | ||
| NotFound | Toshiba Folio 100 | 14:53 | |
| BTW the old laptop is useful, I've fixed several parrot win32 problems in its venerable XP Home. | 14:56 | ||
| benabik | Bad screen? I find my iPad pretty good for reading, although sometimes I do miss the page-like eInk. | 14:57 | |
| NotFound | With notepad. | ||
| benabik: I'm getting a bit less young and my eyes are more demanding ;) | 14:59 | ||
| NotFound is older than Emacs | 15:01 | ||
| moritz is older than Perl | |||
| benabik is surprised to be older than Perl. | 15:02 | ||
| szbalint | a couple billion years older :) | ||
| at least the core codebase | 15:03 | ||
| moritz | \\o/ szbalint, long time no see | 15:04 | |
| szbalint | hey :) | ||
| indeed | 15:05 | ||
| NotFound | But hey, I'm almost a child, I have a NDS ;) | ||
|
15:07
JimmyZ joined
|
|||
| whiteknight | what is an NDS? | 15:12 | |
| benabik | Nintendo DS, I'd imagine. | ||
| whiteknight | oh yeah, that makes sense | 15:13 | |
| NotFound | Aye | ||
| benabik | Hopefully a Lite though. The original was bulky as all get out. | ||
| NotFound | A lite and a DSi | ||
| atrodo | I grew up with an original gameboy | ||
| NotFound | I've never had consoles until recently, but now I have a Wii and the DSs. | 15:14 | |
| JimmyZ | Wii U ? | 15:16 | |
| the next generation? | |||
| benabik | I don't see the point in having a Wii U right now. Not a lot of games for it. | ||
| NotFound | That may become my second non-portable console. | 15:17 | |
| JimmyZ | I'm not that like Wii U now. though I like Wii | 15:18 | |
| NotFound | I have no urgence, in a few months maybe. | 15:20 | |
| benabik | Ignoring stupid touchscreen tricks, it appears to be a Wii with actual computing power. Which sounds awesome. | ||
| NotFound: Well it's not supposed to be released for a year or so... | 15:22 | ||
| NotFound | benabik: my lack of urgence is such as not worrying to look for the release date ;) | 15:25 | |
|
15:26
UltraDM left
|
|||
| benabik | I find the variety of types of variable in Parrot slightly confusing. What's the difference between (get|set)_global and \\1_hll_global? | 15:27 | |
| NotFound | benabik: the _hll_ variants look in the current HLL base namespace. | 15:30 | |
| benabik | NotFound: Otherwise it just looks in the current namespace? I suppose that actually makes sense. | ||
| NotFound | benabik: yeah | ||
| And there is also the _root_ variants. | 15:31 | ||
|
15:39
dmalcolm joined
15:48
mj41 left
15:49
redicaps left
|
|||
| benabik | Hm. PAST appears to use .lex to define variables as registers and then proceeds to use find_lex and store_lex instead of the lex register. | 15:53 | |
| PAST & POST could use a _lot_ of optimization love. | |||
| moritz | benabik: yes, but it requires some decent amount of static analysis | 15:55 | |
| benabik: you can only use registers if inner blocks (which are compiled to separate subs) don't access the variable | |||
| benabik: that said, if it's done correctly, such optimizations will be *greatly* appreciated by all users | 15:56 | ||
| benabik | moritz: Well, you could still lift a lot of fetches into a single register at block entry. | ||
| moritz: Yes, it's a decent amount of static analysis but this is a solved problem to some extent. | 15:57 | ||
|
15:57
rurban_ joined
15:58
rurban left
|
|||
| benabik has a dream of generating an SSA form of PIR and doing some basic optimizations from that. | 15:58 | ||
|
15:58
rurban_ is now known as rurban
15:59
theory joined
|
|||
| benabik | moritz: Blocks are separate subs to handle lexical variables properly, ne? | 15:59 | |
|
16:01
darbelo joined
|
|||
| benabik likes the idea of the tree-optimization library but is sad that no actual optimizations seem to be written using it. | 16:01 | ||
| whiteknight | yeah, it's a good concept, it just needs to be put to use | 16:02 | |
| jnthn__ | Thing is, at least for Perl 6, the PAST tree ain't really enough for a bunch of the interesting optimizations. You need to look at the type environment, stuff in the lexpads, packages, etc. | 16:03 | |
| cotto_work | ~~~ | 16:04 | |
| jnthn__ | For other languages I suspect it may be more applicable. | ||
| benabik | jnthn__: You can't get interesting optimizations, but you can probably get some simple ones. | ||
| jnthn__: I'd be very surprised if repeated `fetch_lex`s couldn't be combined in any language. | 16:05 | ||
| NotFound | I still think that the best way to optimize out redundant opcodes is just not generating them. | 16:06 | |
| jnthn__ | benabik: They can be in some langauges, yes. | ||
| benabik: Not in Perl 6 though...at least, not naively. :) | |||
| lucian | hmm, having trouble with an imcc error gist.github.com/1029584 | 16:07 | |
| benabik | jnthn__: The only reason I can see for not collapsing fetch_lex and get_global calls is in case of parallelization. And to some extent, P6 containers should help avoid that problem since the _container_ is unlikely to change. | 16:08 | |
| NotFound | lucian: a=$P01 = builtins["int"] ??? | 16:09 | |
| jnthn__ | benabik: You seem to be confusing binding and assignment. Binding could replace the container. | ||
| So we have to know that the thing will never be re-bound. | |||
| lucian | NotFound: but it's not even complaining about that line | ||
| NotFound: it stops at line 9, which looks innocent | 16:10 | ||
| benabik | lucian: Are you trusting imcc--'s line numbers? | ||
| lucian | benabik: ah, i should not? | ||
| NotFound | lucian: never trust imcc line numbers in reports. | ||
| lucian | NotFound: benabik: ah. ok, thanks | ||
| NotFound | lucian: BTW, always indent pir code. | ||
| lucian | NotFound: it's generated code, i haven't bothered to make it indent nicely yet | 16:11 | |
| NotFound | Non indented made line numbers even worse. | ||
| whiteknight | yeah, IMCC's line-end heuristic helpfully requires indented code | ||
| lucian | but, that makes no sense | 16:12 | |
| benabik | jnthn__: Arg. P6 is a little too mutable in some ways. Can you even rely that packages won't change? If so you could collapse repeated "$P### = get_global ["PAST";"Ops"]" type calls. | ||
| whiteknight | repeat after me: IMCC-- | ||
| lucian | i see | 16:13 | |
| benabik | IMCC-- | ||
| bubaflub | karma imcc | ||
| aloha | imcc has karma of -20. | ||
| NotFound | lucian: reality is unrealistic. | ||
| whiteknight | it should be much lower | ||
| benabik | That seems way too high. Maybe people gave it positive karma once upon a time. | ||
| jnthn__ | benabik: We can resolve type names at compile time, yes. | 16:14 | |
| And actually do in nom. | |||
| Apart from generics, which we have to postpone. | |||
| benabik | Are we doing a code freeze this weekend? | 16:19 | |
| whiteknight | who's the release manager? | ||
| cotto_work | ohai | ||
| benabik is mostly curious because I think the small nqp-rx stmt improvement might be good to get into parrot. | |||
| cotto_work | <- | ||
| benabik: I'll most likely request a freeze starting Sunday. | 16:20 | ||
| benabik | cotto_work: Can/should we update our bundled nqp-rx before then? | 16:21 | |
| cotto_work: The PAST::Stmt addition really cuts down on register usage, which really improves imcc's compile time on generated code. | 16:22 | ||
| Although the insane number of registers used in PAST::Compiler does appear to be stressing the new allocator quite well. | |||
|
16:23
davidfetter left
|
|||
| cotto_work | benabik: when was it last updated? | 16:24 | |
| whiteknight | Can we update nqp-rx to emit 'file' annotations, if we're going to be updating the snapshot? | ||
| cotto_work | looks like Feb | ||
| whiteknight | For somebody familiar with the codebase, I can't imagine that's too hard to do | ||
|
16:25
mj41 joined
|
|||
| benabik | cotto_work: pmichaud++ added PAST::Stmt to nqp-rx a couple days ago. Prior to that the last commit to rx was in Feb. | 16:25 | |
| whiteknight | TT #2132 | 16:26 | |
|
16:27
darbelo left
|
|||
| allison | hackage.haskell.org/trac/ghc/blog/new-gc-preview | 16:31 | |
|
16:35
darbelo joined
|
|||
| benabik | allison: very interesting. | 16:36 | |
| lucian | benabik: i think ghc folks are spoilt though, since haskell's pure | 16:37 | |
| JimmyZ | looks like there are many papers on haskell | ||
| benabik | lucian: That helps some, but the general concept of thread-local young generation mixed with stop-the-world full gen should be applicable anywhere. | ||
| JimmyZ | I always see it here and there | ||
| lucian | benabik: yes, of course. there's just a lot more details to take care of | 16:38 | |
| benabik | lucian: Of course, but they have to be taken care of anyway. :-D | ||
| lucian | and in general, having to support imperative languages requires more locks | ||
| benabik: yes. dreadful, isn't it? :) | |||
| benabik | whiteknight: When I finish working on this bit of PCT, I'll look into NQP file annotations. | 16:39 | |
| It should be a one-liner somewhere obvious. | 16:40 | ||
| benabik knocks on wood. | |||
| cotto_work | github.com/MrMEEE/bumblebee/commit...ce6#diff-1 - ow | 16:45 | |
| benabik | cotto_work: I like the meme image. "I don't always install Bumblebee. But when I do, it deletes my /usr folder." | 16:47 | |
| NotFound | Now you know why some people are reluctant to add a 'uninstall' make target ;) | 16:49 | |
| "Just a bunch of rm -rf as root, what can be wrong?" ;) | 16:50 | ||
| benabik | NotFound: This is why I tend to install as a standard user into a tempdir and then use stow to actually put it in place | 16:51 | |
| (When I don't use .debs) | |||
| cotto_work | benabik: that looks interesting. I just install to /usr/local/parrot-git and make sure to have some symlinks in place. | 16:52 | |
| benabik | cotto_work: My "Make" script uses DEST dir to install into `pwd`/temp and then uses "mv temp/usr/local/* /usr/local/stow/parrot" | 16:53 | |
| cotto_work: I do that sort of thing a lot. | |||
| *DESTDIR | 16:56 | ||
| cotto_work | That commit goes a long way to clarify why allison++ is against a uninstall target. | 16:57 | |
| benabik | Uninstall belongs to package managers. | ||
| cotto_work | +1 | ||
| benabik | Even if your package manager is just stow++ | ||
| When I was going through Linux From Scratch, I used xstow as my package manager. That experience taught me a lot. Mostly it taught me that I don't want to do that again. | 17:01 | ||
|
17:01
janus joined
|
|||
| atrodo | benabik> I had a similar experience, minus stow. Makes me want to use Gobo | 17:09 | |
| benabik | atrodo: Gobo reminds me a lot of the way OS X handles things. | 17:10 | |
| atrodo | benabik> Aye, which is what appeals to me | 17:11 | |
| somewhere in my LFS experience, I discovered how fragile installing software on unix is. Programs don't like being relocated | 17:12 | ||
| benabik wonders if Rootless GoboLinux would make a decent replacement for fink on my next install. | |||
| atrodo | benabik> I had a plan to install gobo on my server running lfs, but they havn't released in 3 years which is a tough pill to swallow | 17:14 | |
| benabik | atrodo: Ew. System looks nice, but being that out of date isn't. | 17:15 | |
| atrodo | benabik> Exactly | ||
| benabik | whiteknight: Isn't quite so simple. Current line annotations in NQP are generated by POST::Compiler and the PAST tree doesn't currently hold a file name. Will investigate deeper. | ||
| On the plus side, if I fix this for NQP, it'll be fixed for all future users of PCT. | 17:18 | ||
| TimToady | benabik: packages are mutable in P6, but almost nothing relies on packages anymore; functions are all lexical, and methods are all off in the metaobject. | 17:21 | |
| and there are strict guarantees about being able to nail down some of the loose things at CHECK time | 17:22 | ||
| unless they've specifically been declared to be loose permanently | |||
| moritz | benabik: ah, *that* is why some few error messages in rakudo have the line number, but not the file name | ||
| benabik | moritz: Yes. PCT::HLLCompiler stashes the file name(s) in a lexical $?FILES, but only variable declaration errors does anything with it. | 17:23 | |
|
17:24
dodathome joined
17:25
davidfetter joined
|
|||
| benabik | I'll look into this later today. I should grab lunch and stop by school to deal with paperwork for my assistantship next year. | 17:27 | |
| Looks like this will involve changes to PCT, but not NQP-rx, so updating our nqp-rx snapshot shouldn't be held up on it. | 17:28 | ||
| benabik assigns the TODO to himeself. | |||
|
17:30
JimmyZ left
17:32
benabik left
|
|||
| pmichaud | 15:56 <benabik> moritz: Well, you could still lift a lot of fetches into a single register at block entry. | 17:35 | |
| No, YOU CANNOT. | 17:36 | ||
| pmichaud always has to have this discussion. | |||
| oh, he left. | |||
| moritz | pmichaud: jnthn__ mentioned re-binding in the backlog | 17:37 | |
| pmichaud | yes, I see that now. I skimmed through looking for it but didn't see it. jnthn++ | ||
| I probably shouldn't let it bother me, but it seems that _everyone_ looks at the code and says "oh, how inefficient" and then blames PCT. It's Parrot's model that is broken. | 17:38 | ||
| pmichaud goes back to hacking list iterators. | 17:40 | ||
| lucian | heh, it took me this long to realise that all literals get interned, in any compiler | 17:48 | |
| Tene | pmichaud: Hah. I remember when I asked you about that. :) | 17:49 | |
| whiteknight | I don't think PCT is the problem. It's a symptom of the problem, but nobody's working to fix the underlying issues | 17:51 | |
| I've said before, several times, that if somebody came up with a good design for a solution I would help implement it. I don't understand the problems enough myself to design it | 17:52 | ||
| pmichaud | whiteknight: I think it requires some fundamental Parrot architectural changes. | ||
| whiteknight | right. What changes? | 17:53 | |
| lucian | allison: ping | ||
| whiteknight | This is one of those areas where I don't even know what I don't know | ||
| brb, irc client fail. | 17:55 | ||
|
17:55
whiteknight left,
whiteknight joined
|
|||
| whiteknight would love to hear an explanation about how, in less than a days worth of light browsing, firefox sucks up more than a gig of ram | 17:56 | ||
| or why, after closing firefox, that memory isn't immediately freed | |||
| cotto_work | trac.parrot.org/parrot/wiki/WhyDoes...icientCode | ||
| whiteknight | I don't think I | 17:57 | |
| 've ever seen that page | |||
| cotto_work | I've put it on my M0 todo list to make sure that M0 will support something sane, even if it also has to support PIR. | 17:58 | |
| lucian | whiteknight: the firefox process doesn't always die with the closing of firefox | ||
| whiteknight | If PIR is going to continue to serve as some for of middle language, we need to fix it eventually | 17:59 | |
| and if what I'm reading is all still right, we need fixes to vtables to differentiate between set_ and assign_ (a difference the PIR syntax sugar seems to obscure more than anything), fix lexpads, and do other stuff | 18:00 | ||
| lucian | cotto_work: heh, coincidentally that's annoying me as well | 18:02 | |
| (the lack of a clear bind) | |||
| i'm working around it by replacing all lexicals with hashes ... | |||
|
18:07
cjh left
18:08
cjh joined,
mj41 left
|
|||
| cotto_work | pmichaud: what's a system that gets lvalue and assignment semantics right? | 18:10 | |
| pmichaud | cotto_work: I don't know of one. I just know Parrot's model isn't workable for P6 (more) | ||
| we also know that it's not workable for languages in general, if everyone looks at the PCT output and says "how inefficient", because PCT is definitely p6-agnostic. | 18:11 | ||
| one of the fundamentally broken things is the assumption that you can fetch a lexical once at the beginning of a Sub and "know" that you can rely on that register being accurate for the remainder of the sub. | 18:12 | ||
| because "store_lex" completely invalidates that. | |||
| so, Parrot either needs an instruction set whereby you can say "tie this register to this lexical slot even if it gets rebound", or we need to face the fact that we'll be doing lexical fetches every time we need to access a lexical (and we need to optimize Parrot to make that efficient) | 18:13 | ||
|
18:14
lucian left
18:15
lucian joined
|
|||
| pmichaud | more generally, I suspect a bit part of the problem is that there's no mechanism for referencing a slot at all | 18:15 | |
| *big | |||
| it's like a language where you're allowed to have a pointer (a PMC register), but not a pointer-to-a-pointer | |||
| Rakudo master "resolves" this difficulty by creating a PMC that can reference another PMC, but that's an awful heavyweight way to implement references. | 18:16 | ||
| another way to think of it -- there's no way that I know of to pass a hash or array slot by reference | 18:17 | ||
| atrodo | pmichaud> Interesting. I hadn't thought of that | 18:18 | |
| pmichaud | if there were, then lexical pads and a ton of things would become easy | ||
| this gets complicated even further by the fact that we have different opcodes depending on the type of slot you want to deal with | 18:19 | ||
| if you want to change the slot of a hash, that's "set" | |||
| cotto_work | pmichaud: so that primitive concept that needs to be supported is passing a hash (or any PMC) by reference? | ||
| pmichaud | not the Hash, but the elements of the Hash | 18:20 | |
| I can already pass a Hash by reference, that's easy. | |||
| but there's not a way for me to pass hash['key'] by reference | |||
| so if you want to change the slot of a hash, that's "set" | |||
| but ifyou want to change the slot of a lexpad, that's "store_lex" | |||
| whiteknight | pmichaud: and what if hash['key'] is set to a different PMC altogether. Does the reference continue to point to the old value or the new value? | ||
| pmichaud | if you want to change the slot of a namespace, that's one of "set_global", "set_hll_global", or "set_root_global" | 18:21 | |
| if you want to change the value of a PMC, that's "assign" | |||
| (*sigh*) | |||
| lucian | i find parrot passing of everything a bit confusing | 18:22 | |
| pmichaud | whiteknight: the point of a reference is that it's one level up from the thing it's referencing | ||
| whiteknight | right, but is it referencing the container, or the value? | ||
| pmichaud | so, if you have a reference to hash['key'], and hash['key'] is rebound, the reference should reflect that | ||
| just like if I have | |||
| whiteknight | okay, so you're talking about a container reference | ||
| conceptually that's not so hard. A reference like that would contain the aggregate and the key. It's a simple pair, with a lot of hand-wavey passthrough logic | 18:23 | ||
| pmichaud | that's the expensive way to do it, I think | ||
| whiteknight | you think there's a cheaper way? | 18:24 | |
| pmichaud | easier would be to have a new register type that represents a reference-to-a-register | ||
| whiteknight | but that's still only registers then. Doesn't cover hashes, lexpads, or namespaces | ||
| pmichaud | or, more directly, reference-to-a-PMC-slot | ||
| it does cover hashes/lexpads/namespaces since those contain PMC slots | |||
| whiteknight | that doesn't work with GC. We need a pointer to the parent aggregate, so the GC doesn't scoop it up from under us | ||
| if GC collects the hash, and we have a pointer into it's guts, we end up with a dangerous dangling pointer | 18:25 | ||
| NotFound | Sometines I think that people just wants references but denying they are. A bit like java not having pointers but having null pointer exception. | ||
| whiteknight | that's why it doesn't cover hashes and lexpads et al | ||
| pmichaud | whiteknight: thinking | ||
| cheaper would then be aggregate + slot, then. | |||
| whiteknight | now if we had a register type that was a (PMC*, PMC**) pair, that work work | ||
| pmichaud | aggregate to prevent gc | 18:26 | |
| right | |||
| whiteknight | s/work work/would work/ | ||
| NotFound | An iterator is a bit like that. | ||
| whiteknight | okay, so that is not unreasonable or difficult to implement. The bigger issue is setting up an opset that works with the new register set | ||
| and then deprecating old ops like the shitty namespace ops, get/set_lex, and whatever else that isn't using reference registers | 18:27 | ||
| pmichaud | set $Q1, aggregate[key] # gets most of the cases | ||
| might need to be setq or something like that | |||
| lucian | NotFound: i would very much prefer references to what parrot has, if i understand it correctly | ||
| whiteknight | pmichaud: and an op set $P1, $Q1 | 18:28 | |
| to get the actual value out of the reference | |||
| unless we expect Q registers to be used transparently wherever a P register is used, which will require a massive retooling of the enter opset | |||
| pmichaud | sure, that works. or let opcodes .... right | ||
| whiteknight | entire | ||
| NotFound | lucian: I don't worry about the name, but about how the thing will work. | ||
| whiteknight | but I'm still not sure that solves the problem. Because then we just replace all find_lex calls with set_p_q calls | 18:29 | |
| pmichaud | it's not a huge retooling -- just lots more opcode variants for all of the existing PMC ones | ||
| whiteknight | but don't reduce our need to constantly fetch | ||
| NotFound | I just worry about wrong names confusing ideas. | ||
| pmichaud | but the fetch becomes much cheaper and more uniform | ||
|
18:29
rurban_ joined
|
|||
| pmichaud | fetch_lex is pretty expensive at the moment | 18:29 | |
| for one, it involves a hash+key lookup | 18:30 | ||
| then you have to search a bunch of hashes | |||
| lucian | NotFound: i meant a pervasive use of references. i don't like things being copied implicitly | ||
|
18:30
rurban left,
rurban_ is now known as rurban
|
|||
| pmichaud | set_p_q would be vastly less expensive | 18:30 | |
| lucian | NotFound: i may just be very confused | 18:31 | |
| pmichaud | also, it means that compiler (toolkits) only have to deal with one set of opcodes for rebinding, instead of the multitude we have now | ||
| whiteknight | pmichaud: besides making the individual operations less expensive, is there a way to reduce the algorithmic complexity of the system? | ||
| that is, do fewer stores and fewer lookups | 18:32 | ||
| pmichaud | you can if your HLL lets you make simplifying assumptions that enable that to happen | ||
| but so far we haven't run into many HLLs that do that. | |||
| whiteknight | if, instead of a new Q register set, we have a ProxyReference which is that same root/valueptr pair but with vtables that all pass through directly to the target, that wouldn't be good? | 18:33 | |
| pmichaud | that's what Rakudo does now | ||
| whiteknight | and that's no good? | ||
| pmichaud | in the case of a Hash data structure, you double the number of PMCs involved | ||
| same for an Array | |||
| because each element ends up being a ProxyReference to the ultimate value | |||
| so, in Rakudo, if I have an Array of 1000 elements, that actually requires (at least) 2000 PMCs | 18:34 | ||
| whiteknight | always? You're always creating a proxy for every one? | ||
| pmichaud | have to | ||
| otherwise we can't support binding and assignment semantics | |||
| otherwise we can't pass @a[3] by reference. | |||
| atrodo | pmichaud> So would a Q holds a aggregate/key pair? Or a pointer to the slot of an aggregate? | 18:35 | |
| lucian | pmichaud: hmm, i might have to do that for python | ||
| pmichaud | atrodo: latest thinking is aggregate/slot pair (due to GC, as whiteknight++ correctly notes) | 18:36 | |
| you don't want to search for a key each time | |||
| atrodo | pmichaud> What about when a hash does a resize? does that invalidate the slot? | ||
| whiteknight | we're still talking "same basic architecture, just slightly faster implementation" | ||
| pmichaud | also, shift/unshift might mean that the keys move | ||
| whiteknight: we're talking same basic architecture *as rakudo*, perhaps. Parrot doesn't support anything like a ProxyReference PMC (more) | 18:37 | ||
| the other thing we discovered with any sort of ProxyReference is that the vtables get very nasty when you're trying to distinguish between the Proxy and the underlying Object | |||
| i.e., can the Reference have methods that are separate from the PMC it references? | |||
| whiteknight | I would say, "no" | ||
| otherwise you lose perfect transparency | 18:38 | ||
| atrodo | I would say yes | ||
| pmichaud | the point of having the Reference is that at least some operations have to be different | ||
| i.e., you have to be able to distinguish "change the reference" from "change the thing it references" | |||
| you also have to be able to ask "is this a reference" in some instances, to know what sort of thing you got. | 18:39 | ||
| whiteknight | and what about the shift/unshift case? How can we possibly square that? | ||
| let the references change what they're pointing at without notice? | |||
| pmichaud | good question. that argues more for a proxyreference sort of approach, yes. | ||
| whiteknight | or do we have to change all our array types to linked list? | ||
|
18:40
benabik joined
|
|||
| whiteknight | Or, re-do shift/unshift to make arrays more like sliding windows | 18:41 | |
| atrodo | whiteknight> So that question basically is how do you make sure you're refering to the same key? | ||
| whiteknight | atrodo: how to make sure you're referencing the same value, if the value hasn't moved (only the aggregate has changed) | ||
| I get the impression that there isn't going to be a "best" solution here | 18:42 | ||
| atrodo | whiteknight> you do know what value you're pointing to, you already know what pmc it's talking about. but the aggregate may have changed to make the key point to another slot | 18:43 | |
| pmichaud | right now the "best" solution is pretty close to what PCT does... if we can make it easier/faster to do aggregate fetches and stores | ||
| atrodo | at least, that's the way i'm reading it | ||
| pmichaud | in november 2009 we proposed the fetch/vivify opcodes as a way of cleaning up the output (and making fetch/store look more uniform), but I never got a chance to update PCT to try to use those. | 18:44 | |
| benabik backlogs. | |||
| whiteknight | pmichaud: okay, so a Q register set and some ops to fetch/set to them? That's a huge change in itself | ||
| doesn't look like it, but it is | |||
| pmichaud | no, fetch/vivify doesn't involve Q registers | 18:45 | |
| whiteknight | I assume we want the ability to pass Q values through PCC? | ||
| pmichaud | iirc, they were $P0 = fetch aggregate, key, default | ||
| and | |||
| whiteknight | right, I'm not talking about those | ||
| I'm just wrapping my head around Q | |||
| and figuring out what we need to do for Q | |||
| pmichaud | note that I haven't thought it through either | ||
| whiteknight | okay | 18:46 | |
| benabik likes that his off-hand optimization comment has sparked a conversation on making lexpads less sucky. | |||
| pmichaud | also, since Rakudo and NQP now have their own storage models altogether, it's not likely that we'd be making use of Q registers anyway, at least not for a long while | ||
| whiteknight | alternative might be to break PMCs up. Pass all PMCs as PMC** | ||
| that extra decoupling might actually help with a copying GC in the future | 18:47 | ||
| lucian | whiteknight: i think i'd very much like that | ||
| pmichaud | passing PMC as PMC** might be interesting, yes. | ||
| that opens up some interesting opcode possibilities. | |||
| whiteknight | pmichaud: well, I'd much rather spend energy doing something Rakudo will make use of | ||
| lucian | not necessarily break them up, just always pass them by pointer/reference | ||
| atrodo | whiteknight> Or decouple the pmc header from the pmc data? | ||
| whiteknight | atrodo: they're already decoupled, in a way | 18:48 | |
| maybe we need to repartition | |||
| pmichaud | whiteknight: right, I've been in the same boat for some time -- I haven't really pushed on doing much with Parrot's binding semantics because I don't know that Rakudo will end up using it anyway. | ||
| atrodo | whiteknight> How so? | ||
| pmichaud | so my energy has been on figuring out how to get them to work in Rakudo and NQP, and then maybe someday Parrot can borrow from that :) | ||
| whiteknight | atrodo: There's a PMC header struct, and each type has its own attributes struct | 18:49 | |
| benabik | pmichaud: +1 for stealing back from 6model/NQP/Parrot | ||
| whiteknight | atrodo: so to get the length of an array, for instance, it would be p->data->length | ||
| pmichaud | benabik: alas, we've had variants of this conversation many times over the years, although I will admit this is the first time that there's been a lot of well-reasoned discussion about it :) | ||
| whiteknight | the problem is that the vtable pointer is on p also, not on p->data. | ||
| benabik | */Rakudo, not from outselves. | ||
| pmichaud | anyway, I have to get back to another pressing task -- I'll backscroll later | 18:50 | |
| whiteknight | pmichaud: okay, thanks for the discussion. Maybe I'll try to write some of this up | ||
| pmichaud | oh, there's one other possibility | 18:51 | |
| benabik | At any rate, even if Rakudo can't use them, I'd like to have the fetch lifting available as an optimization pass. It feels like NQP might be able to use it. I never wanted to bake such things directly into PCT. | ||
| pmichaud | benabik: see my notes earlier about that not being a valid optimization | 18:52 | |
| atrodo | whiteknight> Is there an .c or .h I can look at? My impression until now was that a pmc was one variable sized struct | ||
| benabik | pmichaud: Shouldn't it be valid as long as you don't leave the sub? It could become invalid after every call, I understand. And if we have a multi-threaded system, it could become invalid, but in that case it could become invalid between the fetch and use already anyway. | 18:54 | |
| pmichaud | anyway, another possibility for lexicals would be if there's a way to tie registers to outer lexpad slots, similar to how .lex ties registers now. | ||
| NotFound | The winxed model is to make it optional: you can avoid the fetchs, but at the cost of knowing what you are doing and never rebind the involved vars. | ||
| pmichaud | benabik: how do you know that you haven't "left the sub"? | 18:55 | |
| benabik | pmichaud: vtables, right | ||
| NotFound | And when not, set it as 'volatile' | ||
| pmichaud | you mean, haven't performed any subroutine calls or method calls? or operations involving vtables? | ||
| even in NQP, when I do: | |||
| benabik | pmichaud: I meant calls. vtables changing lexicals seems like a bad idea. | ||
| pmichaud | $a := $a + 1 | 18:56 | |
| that's doing a store_lex and changing the contents | |||
| in other words: | |||
| $P2 = find_lex '$a' | |||
| ... | |||
| $N0 = $P2 | |||
| $N1 = add $N0, 1 | |||
| $P3 = box $N1 | 18:57 | ||
| store_lex '$a', $P3 | |||
| # $P2 no longer valid | |||
| # $P2 still points to the original value for $a | |||
|
18:57
dmalcolm left
|
|||
| benabik | pmichaud: Yes, but I would expect such an optimization pass to try to point all accesses to a lexical to the same register. Otherwise things like that would happen. | 18:57 | |
| pmichaud | benabik: what about nested blocks? | 18:58 | |
| my $a := 1; | |||
| if foo() { | |||
| my $b; | |||
| $a := $a + 1; | |||
| } | |||
| benabik | pmichaud: Those get compiled as separate subs, and I've already noted that lexicals become invalid across calls. | ||
| pmichaud | so, it's an optimization that is rarely useful. | ||
| sorear | the sensible thing to do here is to say that store_lex actually changes $P2, since the lexinfo maps strings to register numbers | 18:59 | |
| pmichaud | that means that $P2 has to be magical somehow | ||
| sorear | what do you mean? | 19:00 | |
| oh, I mean .lex creates the association | |||
| not fetch_lex | |||
| pmichaud | that already happens | ||
| but that doesn't help in blocks where the lexical wasn't declared | |||
| benabik | pmichaud: Possibly. But I'd like to _try_ to explore optimization passes. Perhaps I'll write a pass and discover it's useless. C'est la vie. | ||
| pmichaud: But would help them where it was. And since much of my variable access is limited to the sub where it's declared that would help. | 19:01 | ||
| moritz | you can always look for subs that are inner subs of the current | ||
| sorear | pmichaud: then we need a fetch_lex_fast_p_ic_ic opcode, which uses "# of outer pointers", "lexical number" arguments, and a store counterpart | ||
| pmichaud: requires a small amount of imcc magic to rewrite the arguments in register allocation | |||
| moritz | and don't optimize if they find_lex with that name | ||
| pmichaud | moritz: what about dynamically attached inner subs, such as eval? | 19:02 | |
| moritz lols about "small amount of imcc magic" | |||
| pmichaud: those hurt | |||
| pmichaud | eval("$a = $a + 1") completely hoses that optimization | ||
| NotFound | I think we need less imcc magic, not more. | 19:03 | |
| sorear | Alternatively we could add a pragma to disable the IMCC register allocator, now that PAST::Compiler is doing most of the same job | 19:05 | |
| pmichaud | I think the IMCC register allocator is already just a linear allocator, although I could be wrong about that. | ||
| sorear | note: currently PAST::Compiler likes to generate register numbers like $P2000, with the IMCC register allocation disabled that would have to be fixed | ||
| pmichaud | I thought the register analysis stuff was disabled long ago. | 19:06 | |
| (in imcc) | |||
| NotFound | Allocation not neccesarily the same as aliasing numbers. | ||
| sorear | pmichaud: the issue is that IMCC's register allocation processes make it impossible for PAST::Compiler to spit out the correct low-level register numbers for fetch_lex_fast | ||
| so either IMCC needs to take up the task, or the register allocation needs to be disabled | 19:07 | ||
| pmichaud | cheaper and more reliable would simply be that fetch_lex optimizes the fetch for later passes of the same fetch in the same call frame | ||
| instead of alway searching the outer frame. | |||
| *always *outer frames | |||
| NotFound | Syntax != magic. Just provide clean syntax for whatever you want imcc to do. | ||
| pmichaud | so then $P2 = fetch_lex '$a' # slow the first time, we have to determine the outer frame and register offsets | 19:08 | |
| benabik | We could have a find_lex opcode that returns some kind of reference than fetch_lex_fast can use. | ||
| pmichaud | .... | ||
| $P2 = fetch_lex '$a' # fast this time -- the local call frame already knows where to find it | |||
| benabik | Caching in the call would also work and possibly be smarter. | ||
| *call frame | |||
| pmichaud | and it can be done by changing the LexPad structure instead of the opcode set | 19:09 | |
| NotFound | At least for me, magic is when imcc does something without a clear reason and you must navigate compilers/imcc to know what and maybe why. | ||
| whiteknight | atrodo: src/pmc.c is probably the best. Look for Parrot_pmc_new and it's ilk | 19:10 | |
| atrodo: it allocates a PMC header, looks up in the vtable for what the attributes struct size is, then allocates that separately | |||
| atrodo | whiteknight> I actually found it in pobj.h | 19:11 | |
| lucian | NotFound: i also dislike calling any abstraction magic | ||
| whiteknight | atrodo: that's cool tood | ||
| too | |||
| pmichaud | anyway, othertasks call -- bbl | ||
| NotFound | For example, for me .const 'Sub' is black magic, mostly because is not a const at all. | ||
|
19:12
klavs joined,
soh_cah_toa joined
|
|||
| NotFound | lucian: any sufficiently badly written abstraction is indistinguishable from magic. | 19:12 | |
| klavs | Hello, everyone! I'm back. | 19:13 | |
| lucian | NotFound: heh | ||
|
19:13
lucian left
|
|||
| NotFound | And depending on its (lack of) documentation, it can be arcane magic. | 19:13 | |
|
19:13
lucian joined
19:15
bluescreen left
|
|||
| atrodo | whiteknight> so it looks like PMCs would point to this fairly thin struct. so what's the issue with having a compacting gc? | 19:16 | |
| whiteknight> couldn't we compact the data pointer if the only pointing to it is this PMC struct? | |||
| compact the address space pointed to by the data pointers | 19:17 | ||
| whiteknight | atrodo: well, it's not just a matter of compacting the data structs. We could definitely do that. But we would also want to be compacting the PMC header as well | ||
| and like I said, I want to squash them. We don't need two structs there, it should only be one allocation | |||
|
19:18
alester joined
19:19
hudnix left
|
|||
| NotFound | whiteknight: for auto_attrs it may be doable but what about manual_attrs? | 19:19 | |
| whiteknight | NotFound: how many PMCs need manual_attrs? | 19:20 | |
| benabik | whiteknight: If the PMC header is a fixed size and the data isn't, we can compact the data and just use a fixed size allocator for the headers. Being reasonably smart about fixed sized allocations can really keep allocations tight. (IIRC) | ||
| NotFound | whiteknight: no idea. | ||
| whiteknight | benabik: well, all those allocations are fixed size, and we used fixed-size allocators for all of them | ||
| benabik | whiteknight: The data portion of a PMC is always the same size? | ||
| whiteknight | benabik: the attributes struct is | 19:21 | |
| NotFound | Also, take into account that that may mean definitely banning morphing. | ||
| whiteknight | NotFound: yes. ban in-place morphing | ||
| it's a mess of a semantic now anyway | |||
|
19:21
RobertLJ left
|
|||
| NotFound | I don't have any problem with that, but other may do. | 19:22 | |
| whiteknight | very few types use VTABLE_morph, and of those, some don't use it correctly anway. Parrot_pmc_reuse is dreadfully buggy. Never has worked, might never work right | ||
| NotFound | Then I suggest to start by deprecating it. | 19:23 | |
| benabik | File annotation is `.annotate "file", "FILENAME"`, right? | ||
| whiteknight | benabik: Yes, I think so | ||
| Coke | NotFound: replacing it with what? | 19:25 | |
|
19:25
cotto left,
bluescreen joined
|
|||
| Coke | (given that several HLLs use morph) | 19:26 | |
| lucian | Coke: what for? | ||
| Coke | ... morphing. | ||
| when you have a PMC that changes types, e.g. from a string to a numeric. | 19:27 | ||
| (or in tcl's case, from a list to a string. or a dictionary). | |||
| sorear | pmichaud: I had a new idea | ||
| benabik | Annotations are only valid inside .subs? | ||
| Coke | Definitely other ways to do it, but we've been using morph for... like 9 years. | ||
| pmichaud | "morph" is how HLLs get around the fact that Parrot doesn't have a proper assign opcode for assigning to a container | 19:28 | |
| sorear | pmichaud: fetch_lex_fast_p_ic packs the outer frame index and register number into a single INTVAL (limiting to, say, 16K frame nesting, 64K registers of 4 types) | ||
| pmichaud | .const 'Sub' foo = 'foo' isn't const? | 19:29 | |
| sorear | pmichaud: fetch_lex_p_sc 1. does the lookup 2. if the lookup resulted in an alias to a specific register (and indexes are small enough), rewrites the in-memory code segment to use fetch_lex_fast_p_ic | ||
| NotFound | pmichaud: it creates a foo variable and assign to it the 'real' const, | 19:30 | |
| pmichaud | NotFound: a foo register? | ||
| NotFound | pmichaud: yeah | ||
| whiteknight | parrot has a problem, people rely on a hackjob workaround. Now parrot has two problems | ||
| that's not the way anything gets fixed | |||
| NotFound | The doc doesn't say that, but the doc lies. | ||
| whiteknight | and if morph has been around for 9 years, that proves the point | ||
| use morph, and you're never going to get around to fixing the problem that necessitated morph in the first place, and you're never going to fix the problems morph causes | 19:31 | ||
| pmichaud | who is the 'you' here? ;-) | 19:32 | |
| the hll implementor? | |||
| sorear | parrot was originally designed to run Perl 5, you cannot make Perl 5 work sensisbly without morph because it has morph as a user-exposed operation | ||
| at best you could have all Perl 5 datums be a single PMC type | 19:33 | ||
| pmichaud | I think most hll implementors use 'morph' because parrot doesn't provide an alternative. at that point the choice is either "stop working" or "use the morph workaround". Option 3 ("change parrot") isn't something hll implementors have had much success in achieving. | 19:34 | |
| s/"stop working"/"stop development"/ | |||
| NotFound | That was my concern. We can't make plans under the assumption that we can get rid of morph, and asuming we'll have morph forever at the same time. | 19:35 | |
| At some point, we must choose. | |||
| pmichaud | fwiw, neither rakudo nor nqp-rx nor nqp use 'morph' these days. I haven't used 'morph' since alpha. | ||
| (we do use 'copy' in rakudo/master, however, which was the suggested replacement for 'morph') | 19:36 | ||
| jnthn__ | new-nqp and nom, afaik, don't use copy. | ||
| benabik | Guh. More PIR magic syntax. What is "$P0 .= $P1"? | 19:38 | |
| concat? | 19:39 | ||
| Coke | I'm not saying never get rid of it, just treat it like any other deprecation. | ||
| and certainly, if it makes parrot better, kill partcl. (no, seriously) | |||
| benabik: ye | 19:42 | ||
| benabik | I really don't mind some of PIR's syntactic sugar, but I keep finding new bits. | ||
| Coke | NotFound, pmichaud: hah. apparently morph is no longer used in partcl-old. | 19:43 | |
| pmichaud | Coke will probably shoot me, but I'm thinking of trying to migrate partcl-new to nqp (new) :-) | ||
| Coke | looks like someone (probably me) switched us over to copy already. | ||
| pmichaud: there's a test suite. go right ahead! | 19:44 | ||
| pmichaud | won't happen this week, though. :) | ||
| okay, I _really_ need to get back to my otherstuff now. Closing irc window. | |||
| bbl | |||
| Coke | tta | ||
| NotFound | Coke: I'm not completely surprised, is not the first time a feature assumed as important is found unused. | 19:46 | |
| whiteknight | that's the thing right there. I don't think morph is working well enough for people to be relying on it much anyway | 19:53 | |
| I mean, I know it's broken in a lot of non-trivial cases | |||
| NotFound | I usually assume that nobody uses it except maybe for internal-only vars. | 19:54 | |
| whiteknight | partcl does still rely on some behaviors which use Parrot_pmc_reuse internally. At least, I know partcl-old does. That's a problem but not as big of one | ||
| benabik | If I fix a TODO should I just push it or put it on the ticket for discussion first? | ||
| whiteknight | CallContext uses morph to reset itself. It doesn't morph anything | ||
| benabik | whiteknight: File annotations: github.com/Benabik/parrot/commit/6afb0ae | 19:55 | |
| NotFound | whiteknight: but that is kind of a hack, can be done by other means, isn't it? | ||
| whiteknight | NotFound: yeah, of course it's a hack. We'd be better off deleting morph and adding a VTABLE_user_defined_1() | 19:56 | |
| or something like that | |||
| which, by the way, I'm not against | |||
| it's not pretty, but at least it isn't a blatant lie | 19:57 | ||
| if we're going to lie, damnit let's not be blatant about it! | |||
| NotFound | We can't lie, Pafo doesn't have a PR section yet. | 19:59 | |
| whiteknight | if we get passed the idea that a single PMC can change itself in-place, we can fix a lot of stuff. Having a proxy/reference PMC type around may not be the most economical alternative on large scales, but it should be good enough for most current HLL uses | 20:01 | |
| I could probably fix a hell of a lot of usages in partcl with Rosella.Proxy | |||
| or, we could add a proxy type directly to the parrot repo for more performance win | 20:02 | ||
| benabik | Isn't there a PMCProxy already? | ||
| whiteknight | benabik: different type of thing | ||
| it's not really a proxy | |||
| benabik | Of course. | ||
| sorear | PMCProxy needs to be set on fire | ||
| whiteknight | PMCProxy should be renamed "BuiltinClass" | 20:03 | |
| or BuiltinType | |||
| or, fire. Like sorear said | |||
| hopefully 6model and/or lorito will get us there | |||
| I suspect strongly that a 6model repr designed for built-in C types will fix the problem for us | 20:04 | ||
| or, just rewriting a lot of built-in types in PIR/Winxed/NQP | |||
| NotFound | Talking a bit more short-term... What is the appropiate place for winxed-on-parrot tests? t/compilers ? | 20:08 | |
| benabik | NotFound: I would think ext/winxed/t | ||
| whiteknight | NotFound: yes, I think so | 20:09 | |
| NotFound | benabik: that was my first idea, but is not consistent with the current usages. | ||
| whiteknight | do we have any NQP tests in the repo? | ||
| or t/ext/winxed/ | 20:10 | ||
| benabik | There are some NQP tests in ext/nqp-rx/t | ||
| whiteknight | okay, copy that for winxed | ||
| benabik | Although, I think that's a subset of the tests from nqp-rx.git | ||
| NotFound | I just want to test that load language works and a minimal program compiles right. | 20:11 | |
| benabik | I would think a new t/ext directory would be the best match for tests not from the source, now that I look at it. | ||
| compilers/ appears to be a directory full of compilers in-core. | |||
| NotFound | I think t/ext/ is the way to go. | 20:13 | |
| whiteknight | t/compilers is probably just for stuff in /compilers/ | 20:15 | |
| lucian | whiteknight: would interning all "reference" pmcs into one be possible/useful? | 20:19 | |
| something like ooc's covers | |||
| whiteknight | i don't know | ||
| lucian | actually, just forcing them to only contain a reference should be enough | ||
| they'd share the same header/vtable/w/e | 20:20 | ||
| since proxy pmcs would be considered wasteful | |||
| whiteknight | the tricky bit of all this is the GC | 20:21 | |
| benabik | Have to head out soon. Should I push my file annotation patch now, or should I let it sit for a bit so people can look at it? | ||
| whiteknight | we can create a million fun types of reference if we don't care about GC | ||
| benabik: easier to ask forgiveness than permission | |||
| shoot to kill | 20:22 | ||
| lucian | whiteknight: i was thinking of a single reference type | ||
| just a fat pointer | |||
| dalek | rrot: 6afb0ae | benabik++ | compilers/pct/src/POST/Compiler.pir: [pct] Add file annotations to generated PIR This allows all users of PCT::HLLCompiler to keep knowledge of the source file in the final result. Closes TT #2132 |
20:23 | |
| benabik | Woo, I closed a ticket. | ||
|
20:23
dodathome left
|
|||
| whiteknight | lucian: maybe | 20:23 | |
| dalek | 0: dccffa6 | klavs++ | dm0.c: now supports labels and argumrnt formating |
20:24 | |
| 0: fe03456 | klavs++ | item.c: new function HasItem() |
|||
| 0: d5108c8 | klavs++ | consts.inc: updated convert_x_x |
|||
| lucian | whiteknight: reading the conversation earlier, it seems i'll have a lot of overheard i hadn't thought of in puffin | 20:25 | |
| dalek | TT #2132 closed by benabik++: NQP-rx does not use "file" annotations | ||
| TT #2132: trac.parrot.org/parrot/ticket/2132 | |||
| whiteknight | lucian: start small. Get the basics working before you start on crazy stuff like references | ||
| lucian | whiteknight: well, you see, everything in python is a reference | 20:26 | |
| of course, i have to figure out scoping (namespaces) first | |||
|
20:26
lichtkind joined,
benabik left
|
|||
| lucian | whiteknight: more precisely, there is no assignment, just binding names to objects (by referencing them) | 20:26 | |
| whiteknight | okay, so a big hash somewhere? | 20:27 | |
|
20:31
M_o_C joined
|
|||
| lucian | well, yeah | 20:32 | |
| that's likely what i'll have to do | |||
| a globals hash and a locals hash | |||
|
20:32
bluescreen left
|
|||
| lucian | but re-binding is tricky, i think parrot's default semantics don't match | 20:33 | |
| whiteknight | would a reference pmc type like what rakudo uses be helpful to you? | 20:34 | |
| we could easily add that to parrot, even if just as a dynpmc for the time being | 20:35 | ||
| actually, i have to pack up and go. Talk to you later | |||
|
20:35
whiteknight left
|
|||
| NotFound | Winxed just hides the problem by not providing yet any native global vars. If you want them, you must use the get/set_..global family in your own way. | 20:36 | |
|
20:41
klavs left
21:01
jevin joined
|
|||
| lucian | NotFound: hmm. set/get_..global semantics are most definately wrong for python | 21:16 | |
|
21:32
ambs left
|
|||
| NotFound | lucian: it was a generic comment, not about python in particular. | 21:35 | |
| lucian | NotFound: i know | ||
|
21:35
hercynium left
21:42
PurityControl joined
21:46
Patterner left,
PurityControl is now known as Patterner
21:47
jjore left
22:00
M_o_C left
22:18
lucian left
22:26
plobsing joined
22:41
bubaflub left,
whiteknight joined
22:44
alester left
22:45
fperrad left
|
|||
| whiteknight | my mouse is completely crapped up | 22:48 | |
|
22:59
whiteknight left
|
|||
| soh_cah_toa | what does a definition that looks like "const char *foo()" do? i've seen the const qualifer used in declarations and function parameters but not ever as a return value | 23:06 | |
| i can't seem to find anything on the internet about it. "const functions" gives me nothing but c++ member functions | |||
| cotto_work | soh_cah_toa: where do you see that? | 23:07 | |
| soh_cah_toa | cotto_work: in src/debug.c around line 900 in the definition of get_cmd() | 23:08 | |
|
23:10
jjore joined
23:11
whiteknight joined
|
|||
| whiteknight | ubuntu fail | 23:11 | |
| soh_cah_toa | whiteknight: oh yay, you're back. i have a question... | 23:12 | |
| whiteknight: what does a definition that looks like "const char *foo()" do? i've seen the const qualifer used in declarations and function parameters but not ever as a return value | |||
|
23:13
bubaflub joined
|
|||
| whiteknight | means the function returns a const char * | 23:13 | |
| cotto_work | That just means that the thing it returns shouldn't be modified. | ||
| soh_cah_toa | oh. i didn't realize you could specify that behavior for returns values | 23:14 | |
| i thought it was only for declarations | |||
| whiteknight | technically, that is a declaration | ||
| you're declaring a const char *, which is gotten from a function | |||
| soh_cah_toa | really? that's how the compiler treats it? | 23:15 | |
| whiteknight | sortof | ||
| you can put a call to that function anywhere you can put a const char * | 23:16 | ||
| so you are declaring that whole thing as having that type | |||
| soh_cah_toa | ahhh...right. i could put it in an expression | 23:17 | |
| whiteknight | I hate updating software and having some fundamental piece of hardware stop working | 23:19 | |
| I've been using this touchpad with ubuntu for years, since 8.04, maybe earlier | 23:20 | ||
| and today, bam. Stops working | |||
| soh_cah_toa | uh, yeah. me too | ||
| i just upgraded my laptop from fedora 13 to 14. now selinux stops my nic from working | |||
| cotto_work | selinux is great if you're the nsa | 23:21 | |
| whiteknight | that's the only thing I don't like about linux. Hardware support is shit terrible | ||
| and I know it's not the fault of the linux devs | |||
| soh_cah_toa | i know... :( | ||
| whiteknight | but still, it's hard to use a system that's this unstable. I certainly can't recommend it out to people as I wish I could | ||
| soh_cah_toa | the one thing i hate about linux is poor flash support | 23:22 | |
| whiteknight | "Linux is free and it's awesome, but every now and again the mouse stops working, or the screen stops working, and there are no obvious ways to fix it" | ||
| hardly a convincing sales pitch | |||
| cotto_work | soh_cah_toa: s/linux/adobe/ | 23:23 | |
| soh_cah_toa | hmmmm.... | ||
| whiteknight | I don't use flash, so it's not a big deal for me | ||
| soh_cah_toa | cotto_work: yeah, you're right | 23:24 | |
| whiteknight: that's impossible. you watch no videos? | |||
| whiteknight | nopes | ||
| soh_cah_toa | cotto_work: b/c adobe has is closed source | ||
| whiteknight: alrighty then | 23:25 | ||
| cotto_work | soh_cah_toa: youtube html5 works quite nicely with chrome. I haven't tried it with firefox. | ||
| soh_cah_toa | bleh...chrome | ||
| cotto_work | for videos that are converted | ||
| +1, but it's better than flash | |||
| at least it's wacky open source rather than closed | |||
| soh_cah_toa | i know | 23:26 | |
| i have to say, flash plugins are the ONLY piece of proprietary software i use. i caved in. gnash is just too much of a pain | 23:27 | ||
| whiteknight | And I keep thinking to myself, "if this is what I get with Ubuntu, which is supposed to be one of the most usable linux distros, I shudder to think what other distros are like" | 23:29 | |
| bubaflub | ping plobsing | 23:46 | |
|
23:48
GeJ left,
GeJ joined
|
|||
| mikehh | I dunno about Flash plugins with Ubuntu, I find it works in the i396 version, but not on amd64 | 23:55 | |
| i386 | 23:56 | ||
| soh_cah_toa | that's the thing. sometimes yes, sometimes no | ||
| mikehh | one of the reasons I use the 32 bit version is that some things work there that don't on the 64bit version | 23:58 | |
| soh_cah_toa | same here | 23:59 | |
| mikehh | at least the pae kernel allows me to access more that 4GB | ||