Parrot | source cross referenced
← Previous day | Index | Channel Index | Today | Search | Google Search | Plain-Text
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 00:00 | hercynium joined #parrot | |
| 00:04 | * Whiteknight | hates that "exit" is an unrecognized command in gdb |
| 00:05 | * darbelo | just Contrlo-D's everything this days. |
| 00:06 | darbelo | Works much more often than quit, exit, etc. |
| 00:08 | Whiteknight | damnit, chromatic disappears when I want to bounce ideas off him |
| 00:08 | dukeleto | Whiteknight: i can pretend that I am him and give you a random answer, if that helps :) |
| 00:08 | Tene | /nick chromatic |
| 00:10 | dukeleto | we really should create a TT to look into cloning chromatic |
| 00:11 | Whiteknight | dukleto: ok. I suggest that for mathematics ops, we should delegate to the proxy first, fallback to MMD second, and default last |
| 00:12 | dalek | winxed: r435 | julian.notfound++ | trunk/examples/pirado.winxed: |
| 00:12 | winxed: .param and .local directives, some register allocation and const string | |
| 00:12 | winxed: arguments in calls in pirado | |
| 00:12 | winxed: review: http://code.google.com/p/winxe[…]urce/detail?r=435 | |
| 00:12 | dukeleto | Whiteknight: these are for regular math ops or the dynops or both? |
| 00:13 | Whiteknight | dukeleto, math vtables for subclasses of numeric bultin types |
| 00:14 | dukeleto | Whiteknight: "the proxy" refers to PMCProxy ? |
| 00:14 | * dukeleto | puts on dunce hat |
| 00:14 | Whiteknight | yes |
| 00:14 | dukeleto | Whiteknight: what is the reasoning behind PMCProxy coming before MMD ? |
| 00:15 | Whiteknight | take a read through the generated code of src/pmc/object.c sometime. It's obnoxious |
| 00:15 | * dukeleto | puts that on my TODO mountain |
| 00:15 | Whiteknight | meh, fugedaboudit |
| 00:15 | dukeleto | Whiteknight: what generates object.c ? |
| 00:16 | Whiteknight | lib/Parrot/pmc2c/PMC/Object.pm |
| 00:16 | dukeleto | Whiteknight: i am hoping that my dumb questions maybe help you answer some of your questions. That may be too much to hope for, though |
| 00:18 | NotFound | Now that pirado is able to do some PCC without generating the stringized hex flags I'm wondering what is the reason to have that things in the pbc. If they are used only to check calls in pasm mode, why we store it in the pbc? |
| 00:20 | darbelo | NotFound: because we don't know better? |
| 00:21 | Coke: ping | |
| 00:23 | NotFound | darbelo: I'm unable to follow imcc internal logic, but maybe someone... |
| 00:24 | darbelo | I tried to understand IMCC once... |
| 00:24 | After that I decided we should migrate to pirc *yesterday* | |
| 00:26 | NotFound | Looks like the problem is that the string is stored in the constant table and checked from it, so is not easy to isolate. |
| 00:28 | dukeleto | darbelo: yeah, reading the source of IMCC is the best motivation to work on pirc |
| 00:30 | NotFound | I'd like better to be freed from lex, yacc and family. |
| 00:30 | nopaste | "whiteknight" at 68.46.29.192 pasted "patch for chromatic++" (38 lines) at http://nopaste.snit.ch/19907 |
| 00:31 | Whiteknight | purl msg chromatic take a look at http://nopaste.snit.ch/19907. Fixes the two tests from TT #542 and TT #768 , but we fail new tests in multidispatch.t and objects.t. I'm looking a those tests now to make sure they are sane |
| 00:31 | purl | Message for chromatic stored. |
| 00:31 | darbelo | purl: msg Coke The rm_dynoplibs_make was introducing some unportable makefile constructs. r44860 fixes BSD make, but I can't vouch for other platforms. |
| 00:31 | purl | Message for coke stored. |
| 00:31 | dalek | parrot: r44860 | darbelo++ | branches/rm_dynoplibs_make/src/dynoplibs/Rules.in: |
| 00:31 | parrot: [Makefile] Avoid using $< in non-suffix rules to make BSD make happy. | |
| 00:31 | parrot: review: http://trac.parrot.org/parrot/changeset/44860/ | |
| 00:37 | snarkyboojum joined #parrot | |
| 00:42 | snarkyboojum_ joined #parrot | |
| 00:48 | eternaleye joined #parrot | |
| 00:57 | abqar joined #parrot | |
| 01:00 | Whiteknight | damnit, I made commits to the wrong branch |
| 01:00 | darbelo | purl: msg Coke Also, see r44859. I think that fixes your liking issues on this branch. |
| 01:00 | purl | Message for coke stored. |
| 01:00 | darbelo | And with that. I'm going to sleep. |
| 01:01 | See y'all later. | |
| 01:02 | cotto_work | night |
| 01:04 | dalek | parrot: r44861 | darbelo++ | branches/rm_dynoplibs_make (2 files): |
| 01:04 | parrot: Read the LINKARGS variable, taken from the old dynoplibs template, and use it for linking. | |
| 01:04 | parrot: review: http://trac.parrot.org/parrot/changeset/44861/ | |
| 01:20 | parrot: r44862 | whiteknight++ | branches/tt389_fix (3 files): | |
| 01:20 | parrot: [tt389_fix] I committed this to the wrong branch. undo. | |
| 01:20 | parrot: review: http://trac.parrot.org/parrot/changeset/44862/ | |
| 01:23 | snarkyboojum joined #parrot | |
| 01:42 | Austin joined #parrot | |
| 01:42 | * Whiteknight | thinks he has the fix_hll_mmd problems licked |
| 01:47 | Austin | I think it's kind of bizarre that I order something from Amazon.com, select "standard shipping", and the package arrives before the confirmation email. |
| 01:47 | Not that I'm complaining, since it showed up overnight... | |
| 01:51 | cotto_work | I'd appreciate thoughts on a more refined plan for Lorito: |
| 01:51 | nopaste | "cotto" at 131.107.0.111 pasted "plan for Lorito" (32 lines) at http://nopaste.snit.ch/19908 |
| 01:53 | * cotto_work | goes home |
| 02:34 | ash_ joined #parrot | |
| 02:44 | patspam joined #parrot | |
| 02:54 | snarkyboojum joined #parrot | |
| 02:55 | Coke | msg cotto - does lorito sit on top of existing bytecode? |
| 02:55 | purl | Message for cotto stored. |
| 02:56 | Coke | -> |
| 03:01 | patspam joined #parrot | |
| 03:21 | preflex joined #parrot | |
| 03:25 | Austin | Coke: I think the idea is the other way around - that existing bytecode sits on pmc/ops that is written in lorito. |
| 03:25 | Essentially, it's the lower-level vm. | |
| 03:28 | patspam joined #parrot | |
| 03:32 | cotto | Coke, what stage of the plan are you talking about? |
| 03:33 | The long-term plan is what Austin said. | |
| 03:35 | janus joined #parrot | |
| 03:41 | plobsing | cotto: what about the ability to have bytecode in the interpreter by default on startup so that core VM features can be implemented in PIR but be transparent to users? |
| 03:41 | do we have that already? | |
| 03:42 | cotto | not sure what you mena |
| 03:42 | *mean | |
| 03:42 | I think what you're saying is part of the plan. | |
| 03:43 | plobsing | yes, but I don't see it explicitly there, and it's a feature I think would help start us along (and might be useful in other areas) |
| 03:44 | cotto | I'm adding it now. It's just something I forgot to mention. |
| 03:44 | Austin | Not only that, but I think a significant fraction of the pmc stuff should already be in pir. |
| 03:44 | eternaleye joined #parrot | |
| 03:44 | plobsing | Austin: exactly. one of the reasons it's not is not wanting to have to "load_bytecode 'RPA.pbc'" |
| 03:45 | cotto | plobsing, I see what you mean. |
| 03:46 | something like parrot_bootstrap.pbc that does all kinds of magical interp init stuff | |
| 03:46 | Austin | Sure, and there's a couple of pmc's that are clearly always going to be in C for performance. But why are there all these "methods" - that are clearly aimed at being called from pir - in C? Why not just write 'em in pir and be done. |
| 03:50 | plobsing | that's a good point. Another point this would improve is ops-based security. If you made Filehandle PMC in PIR over ops/dynops, you eliminate loopholes in op-filter based security (as pitched in TT #1500 ) |
| 03:51 | cotto | plobsing, sure. If everything goes through Lorito we can have a high degree of control over what's allowed to run. |
| 03:53 | tetragon joined #parrot | |
| 03:53 | plobsing | cotto: that depends... If Lorito is as low level as I have come to understand it to be, it may be difficult to distinguish between permissable and forbidden operations. |
| 03:53 | szabgab joined #parrot | |
| 03:54 | cotto | How so? |
| 03:55 | bacek joined #parrot | |
| 03:55 | cotto | a wild bacek appears |
| 03:56 | bacek | I'm not wild. I'm mad! |
| 03:56 | * plobsing | uses sanity. It's not very effective. |
| 03:56 | * cotto | agrees with whatever the mad bacek says and backs off slowly |
| 03:57 | * bacek | keeps silence |
| 03:58 | plobsing | cotto: Say Lorito implements filehandle open as with a syscall op. There will be cases when I cannot statically determine what syscall is being made. Maybe its open, maybe its write, maybe its unlink, etc. |
| 04:00 | cotto | That'll be a good case to bring up when discussion on Lorito starts in earnest. |
| 04:00 | plobsing | Do I a) risk it and allow this or b) explain to an HLL end user why they have to jump through hoops so that their invariants can translate downwards |
| 04:03 | cotto | I don't see requiring a constant to be used for syscalls creating extra difficulty for HLL users. |
| 04:04 | they'll say $f = open("foo","w") and the HLL will eventually generate syscall x, ..., where x is a compile-time constant. | |
| 04:04 | (assuming we go that route) | |
| 04:05 | plobsing | cotto: that's a simple case. There will be cases where the programmer can guarrantee invariance while either the HLL compiler or Lorito analyser cannot |
| 04:07 | cotto | I'd encourage you to send something to the list about it. It sounds like a point that's worth getting right early. |
| 04:21 | bacek, thoughts on a more fine-grained Lorito plan?: | |
| 04:21 | nopaste | "cotto" at 96.26.227.153 pasted "cotto attacks the wild bacek with a Lorito plan" (38 lines) at http://nopaste.snit.ch/19909 |
| 04:21 | bacek | cotto, looks about all right. |
| 04:22 | cotto | Call that v1.1 |
| 04:23 | What would you add or modify? | |
| 04:23 | Austin | What's the purpose of the plan? More to the point, what's the purpose of lorito? |
| 04:24 | bacek | cotto, may be move "pmc" into later stages. |
| 04:25 | cotto | bacek, why? |
| 04:25 | purl | bacek, why is the conditional in mark_context_start() in sub.c? Why do you need to check if it is 0? Why not just do context_gc_mark = 1, and skip the check? |
| 04:26 | bacek | Does almost nothing on early stages. We can implement ops first and than implement pmc in HLL from stage 2 |
| 04:28 | cotto | We'd still need to flesh out how to implement/use core PMCs written in HLLs. |
| 04:28 | i.e. the mangled-C PMCs would have to stick around longer | |
| 04:29 | bacek | But after implementing ops it will be much easier. |
| 04:30 | cotto | So you're saying that we should focus on ops until they're all Lorito-y, then use the lessons from that transition on PMCs? |
| 04:34 | bacek | exactly |
| 04:34 | cotto | That makes sense. |
| 04:34 | bacek | small steps |
| 04:34 | purl | small steps are easier to debug than big ones. We could get :todo<...> working and not know it due to other errors :-) |
| 04:46 | cotto | bacek, are you saying that the nqp-rx pmc compiler should go later or just that we should wait before implementing PMCs in HLLs? |
| 04:46 | bacek | just wait |
| 04:47 | * cotto | waits |
| 04:47 | bacek | nqp-rx pmc compiler is independent stream of work. |
| 04:47 | It can be done in parallel with main ops/lorito work | |
| 04:48 | cotto | I think I understand; once Lorito's sufficiently far along, we won't need a separate pmc compiler to build PMCs? |
| 04:49 | so the pmc compiler eventually becomes irrelevant | |
| 04:51 | dukeleto | 'ello |
| 04:51 | cotto | i |
| 04:52 | * cotto | goes shopping |
| 04:52 | Austin_Hastings joined #parrot | |
| 04:53 | dukeleto | Austin_Hastings: howdy |
| 04:53 | purl | hola, dukeleto. |
| 04:53 | Austin_Hastings | Hey, duke. |
| 04:54 | bacek | not quite true. |
| 04:54 | We still need main Grammar for PMC. | |
| 04:54 | But grammar for vtable/methods bodies will be shared with opsc |
← Previous day | Index | Channel Index | Today | Search | Google Search | Plain-Text