|
Parrot 1.0 Released | parrot.org | 380 RTs left! Set by moderator on 28 March 2009. |
|||
| Infinoid uses a separate parrot tree so he can use the normal source control tools | 00:00 | ||
| LylePerl | I offered Jarkko to fix the lists.cpan.org site which hasn't worked for ages. But he declined which was a bit upsetting :( | ||
| bacek_ | good morning | 00:01 | |
| LylePerl | If it was part of TPF you could get a grant to do that kind of thing | ||
| Infinoid | hmm, true | ||
| bacek_ | Infinoid: it's easy to reproduce via pir. | ||
| jonathan | LylePerl: We have a file build/PARROT_REVISION which tells the current version of Parrot we know that we can work with. | ||
| LylePerl: It's rare but has happened that later caused issues. | 00:02 | ||
| bacek_ | $P0 = new 'Packfile'; $P0 = content; $S0 = $P0; | ||
| Infinoid | At the same time, you guys are constantly pushing new features and bugs into parrot, so I doubt rakudo will be very far off of parrot HEAD for the next few months | ||
| bacek_ | "content" is PBC from different architecture | ||
| Infinoid | uh, bug *fixes*, I meant to say :) | ||
| LylePerl | jonathan: when do you think Rakudo will default to the parrot that works for iis? | ||
| bacek_ | then $S0 will contains wrong header. | ||
| Infinoid | jonathan: that would be r37990 (hopefully) | 00:03 | |
| oh, I see, so it just doesn't regenerate it | |||
| Does it cache the old binary string? Hmm. | |||
| LylePerl | jonathan: Just wondering for these guides I'm writing... Whether I'll need to explain the IIS thing, or just leave it as it'll be updated in a few days anyway... | 00:04 | |
| Infinoid | Is it just the header, or all the segments as well? | ||
| jonathan | LylePerl: We can up the rev number for that I think. | 00:06 | |
|
00:07
dmknopp joined
|
|||
| LylePerl | jonathan: Excellent! Looking forward to (hopefully) stirring up some more Perl 6 CGI interest :) | 00:08 | |
|
00:09
AndyA joined,
TiMBuS joined
|
|||
| jonathan | OK, sleep time for me...night | 00:10 | |
| Infinoid | thanks, jonathan | ||
| Whiteknight: Any additional thoughts on the jit buffer stuff? I'd like a solid design spec before I move forward any more on the implementation... Santtu and I have (between us) written 3 patches with different strategies so far :) | |||
| It's proving difficult to avoid overengineering this to infinity. | 00:13 | ||
| Whiteknight | Infinoid: Whatever you do will be fine, all the patches I've seen are sane | 00:14 | |
|
00:14
gryphon joined
|
|||
| Infinoid | Ok, great, thanks | 00:14 | |
| Whiteknight | My personal preference would be to not tack on unrelated functionality to ManagedStruct, but that's just a preference | ||
| plus, I do understand the desire to reuse existing functionality where possible | |||
| Infinoid | I think it's a little overboard, to be honest. It seems like I need to toss a couple new features onto the ever-hungry accretion disc of ManagedStruct just to track a simple pointer. :) | 00:15 | |
| But hey, whatever works | |||
| purl | "whatever works" is not always the best solution. or - but it's good enough | ||
| Infinoid | Thanks, I'll rework a few minor things and check in the whole stack | 00:17 | |
| LylePerl | sleep for me too. night | 00:21 | |
| Infinoid | Thanks again, LylePerl | ||
| LylePerl | No thank you! | ||
| (missing comma after no) | |||
| Infinoid | :) | ||
| Testing oddball combinations we've never tried before is always appreciated. | |||
|
00:38
dmknopp joined
00:39
dmknopp left
00:55
acajou left
|
|||
| Infinoid | allison++ # book | 01:14 | |
|
01:19
Theory joined
|
|||
| GeJ | allison++ # seconded | 01:39 | |
| cotto | allison++ #what they said | 01:43 | |
|
01:45
Theory joined
|
|||
| Infinoid | Well, let's see how badly this breaks things. | 02:03 | |
| dalek | rrot: r37991 | Infinoid++ | trunk (5 files): [core] Extend the mem_free_executable() API to always take a "size" argument. (needed for munmap) |
02:05 | |
| rrot: r37992 | Infinoid++ | trunk/src/pmc/managedstruct.pmc: [core] ManagedStruct needs ATTRs for free() and clone() function pointers. |
|||
| rrot: r37993 | Infinoid++ | trunk (7 files): [jit] Allocate JIT buffers with mmap on linux. Set things up so they're freed properly using munmap(). |
|||
| Infinoid | (although things would probably work just fine if the PARROT_HAS_EXEC_PROTECT check was disabled, and that feature was always on.) | 02:06 | |
|
02:07
davidfetter joined
|
|||
| rg | are there any drawbacks to having it always on? | 02:10 | |
|
02:11
dukeleto joined
|
|||
| Infinoid waves his hands at rg and makes vague claims of some as-yet-undiscovered machine out there which it might break on | 02:12 | ||
| It makes things slightly more complicated, I guess. *shrug* | 02:13 | ||
| rg | my guess would be if it should always work and not have major drawbacks (like slower code), why maintain two codepaths? | 02:14 | |
| Infinoid | It was a 'minimal impact' sort of thing. | ||
| Are there any unix-like machines out there which don't have mmap? | |||
| rg | i'd say not anymore | 02:15 | |
| Infinoid | Great. As long as mmap/munmap/mremap and the various constant defines I've used are always there, I suppose it should work everywhere | ||
| Infinoid doesn't have a lot of non-linux unix experience. | |||
| Infinoid waits for the 100% FAIL smolder reports to roll in | 02:16 | ||
| rg | :) | ||
| hmm well since you still need the other codepath for windows, all you'd gain was extra testing on unix machines | 02:19 | ||
| or do you? | 02:20 | ||
| purl | it has been said that do you is it compulsory? ;) | ||
| rg can't really tell from the diff | 02:21 | ||
| Infinoid | the fix *should* only affect x86 processors with the NX bit, everyone else keeps using the heap as usual | 02:22 | |
| Although the "clone" codepath would probably benefit everyone else, too. If we ever cloned JIT buffers. Which is crazy. | 02:23 | ||
| Sadly, I don't even have such a processor available here for testing. | 02:24 | ||
| rg | hmm my parrot machine seems to have the NX feature, but i'm running it with 64bits, so no jit | 02:25 | |
| Infinoid | Yeah, same here. | ||
| Sad that the nx and lm bits seem to go hand in hand, huh? :) | |||
| Well, ok. Not that sad. | 02:26 | ||
| rg | ok, it's getting late. time for bed. | 02:29 | |
| Infinoid | sleep well | 02:30 | |
|
02:36
janus joined
|
|||
| dalek | rrot: r37994 | Infinoid++ | trunk/config/gen/platform/generic/memexec.c: [core] Various improvements to generic/memexec.c. * Fix the return value for non-win32 realloc. * Improve the documentation slightly. |
02:44 | |
| kudo: 85ab143 | pmichaud++ | src/ops/perl6.ops: Refactor is_uprop opcode a bit. |
02:58 | ||
| shorten | dalek's url is at xrl.us/beocy2 | ||
| dalek | kudo: a2bb078 | pmichaud++ | : Merge branch 'master' of git@github.com:rakudo/rakudo |
||
| shorten | dalek's url is at xrl.us/beocy4 | ||
| dalek | kudo: f545fee | pmichaud++ | src/ops/perl6.ops: Add "Bidi" and "In" support to unicode character properties. |
||
| shorten | dalek's url is at xrl.us/beocy6 | ||
|
03:13
tetragon joined
03:38
dukeleto joined
|
|||
| dalek | kudo: 4ae560c | pmichaud++ | t/spectest.data: Update spectest.data with properties.t tests. |
03:40 | |
| shorten | dalek's url is at xrl.us/beoc4q | ||
|
03:53
particle joined
04:20
jdv79 joined
|
|||
| jdv79 | just skimmed the parrodev book. what i noticed was that there are 1200 ops?! and no mention of GC. | 04:20 | |
|
04:29
dukeleto joined
04:31
Tene_ joined
04:35
dukeleto joined
|
|||
| cotto | jdv79, there are currently 1249 ops, although a large number of them are variations based on argument types. | 05:09 | |
| Infinoid | cotto: Is there a ticket open for these nci-without-jit failures? I've got some free time to look at it now, but I don't know if any work's already been done on it yet | 05:23 | |
| pmichaud | I'm working on travel arrangements for YAPC::NA ... I know there's a Parrot workshop the days before YAPC::NA ... is there a planned hackathon session after YAPC::NA ? | 05:26 | |
| (specifically for parrot) | |||
| (or rakudo) | |||
|
05:27
spofd joined
|
|||
| cotto | Infinoid, I actually just fixed it and am making sure nothing new breaks. | 05:28 | |
| It's a very simple fix. | 05:29 | ||
| Infinoid | Awesome. Staring at nci.c was bending my brain in scary ways. | 05:30 | |
| cotto | Urg. Me too. | ||
| pmichaud | allison: ping | 05:31 | |
| allison | pmichaud: pong | 05:32 | |
| pmichaud | scheduling questions, if you have a moment. (more) | ||
| allison | sure | ||
| pmichaud | (1) do you know anything about hacking activities or meetings post YAPC::NA ? | 05:33 | |
| (I know we have the workshop before YAPC... wondering when to book my return flight.) | |||
| allison | I know that we usually have them, and I know that I plan to stay an extra few days after YAPC | ||
| pmichaud | okay. | ||
| I will plan to stay at least one day after YAPC | |||
| allison | I don't know details of where we'll be hosted yet | ||
| pmichaud | (I can get phenominal airfares if I book now. $200 round trip) | 05:34 | |
| question #2 (last one) | |||
| the oscon schedule shows that the last event is at 11:45 on Friday... is that really the last event, or are there likely to be keynotes friday afternoon (as there have been in years' past?) | |||
| (it affects my return flight.) | 05:35 | ||
| allison | there are keynotes after 11:45am | ||
| we'll be all wrapped up with everything by 2pm | |||
|
05:36
particle joined
|
|||
| pmichaud | well, with southwest I can get really low fares but last flight from SJC is 2:45p, so that might be cutting it close. | 05:36 | |
| allison | you'd likely be fine leaving at 1:30 | ||
| (there's food in there after the final keynote) | |||
| pmichaud | and keynotes would likely be done around 1:30ish? | 05:37 | |
| I've always found the friday keynotes to be particularly good. :-) | |||
| allison | aye, they're planned for 12:30 to 1:30 | 05:38 | |
| pmichaud | okay, that tells me pretty much what i need to know. Many many thanks. | ||
| dalek | rrot: r37995 | cotto++ | trunk/tools/build/nativecall.pl: [NCI] fix NCI sub generation on non-jitcapable Parrots |
||
| Infinoid | ooh, SJC is within driving distance for me. Maybe I should actually go to one of those | 05:39 | |
| pmichaud | Infinoid: if you haven't been to oscon before, it's generally quite awesome. | 05:40 | |
|
05:40
dukeleto joined
|
|||
| pmichaud | It's one of those conferences that is frustrating because there are so many good sessions that you have to pick-and-choose (and inevitably miss some you'd really like to see). | 05:41 | |
| Infinoid | Sounds great, I'll see about getting myself there | 05:42 | |
| wow, conferences are pricey. | 05:52 | ||
| pmichaud | oscon is, yes. | 05:53 | |
| yapc's are not nearly as pricey. | |||
| Infinoid | cotto++, thanks! that fixed 3 test files here | 06:02 | |
| Now my only remaining failure is somehow related to my version of libicu... hope to fix that tomorrow. | 06:03 | ||
|
06:15
spofd left
|
|||
| dalek | kudo: e05aff7 | pmichaud++ | docs/spectest-progress.csv: spectest-progress.csv update: 354 files, 10224 passing, 0 failing |
06:18 | |
| shorten | dalek's url is at xrl.us/beoddn | ||
|
06:21
Theory joined
|
|||
| cotto | Infinoid, great! It's always nice when someone else fixes something you thought you'd have to. | 06:26 | |
| GeJ | pmichaud: the ~2K bump in the passing tests number is from the unicode properties only? | ||
| moritz | GeJ: not only; jonathan also implemented typed arrays and hashes | 06:29 | |
| though the properties account for a much larger number of tests | 06:30 | ||
| pmichaud | yes -- while reviewing spectests last week I noticed a test file with ~1800 tests that were waiting on unicode support. So I added it. | 06:31 | |
| GeJ | nice additions. :) | 06:32 | |
| pmichaud | time for sleep here -- back in a few hrs | 06:33 | |
| GeJ | good night | ||
| moritz | I just skimmed over the parrot_dev_guide.pdf that allison++ linked to on parrot-dev... | 06:46 | |
| I particuarly like how it assumes that every linux has apt-get available ;-) | 06:47 | ||
|
06:56
allison joined
|
|||
| allison | moritz: aye, it's entirely unedited at this point, just a formatted dump of the text from the repository, some parts are quite rough | 06:58 | |
| moritz | but it looks so much more professional in book form ;-) | 07:00 | |
| GeJ | allison: if it's not too much to ask, would it be possible for the next 'preview' to have larger fonts and smaller margins ? | 07:04 | |
| Other than that, terrific job. Thanks. | 07:05 | ||
| allison | GeJ: it's set up for print format, so no, but we can eventually produce a different PDF for online use. | 07:06 | |
| GeJ: (those oddly large margins make the printed space fit exactly within a 6x9 book page) | 07:07 | ||
| moritz: yeah, isn't it odd what a little formatting does psychologically? | 07:08 | ||
| moritz | allison: that's why I write nearly everything in TeX - it does the formatting better than I could ;-) | 07:12 | |
| allison | Pod-to-TeX also works nicely (that's what this is) | 07:14 | |
| cotto | allison, could I get your input on trac.parrot.org/parrot/ticket/452 (avoiding unnecessary MULTIs)? | 07:17 | |
| The patch is simple enough, but I'd like to make sure it's correct before I write a bunch more like it. | |||
| allison | moritz: though I spent a huge amount of time getting the .sty files just right (but that was for the mod_perl2 book, so can just reuse them) | ||
|
07:18
masak joined
|
|||
| allison | cotto: looking now... | 07:19 | |
| cotto: answer added to ticket | 07:23 | ||
| cotto | Thanks. | 07:24 | |
|
07:25
iblechbot joined
08:06
szabgab joined
09:05
szabgab joined
09:36
riffraff joined
10:05
bacek joined
10:25
bacek joined
10:30
schinkelm joined
10:44
ara joined
11:32
joubert joined
|
|||
| dalek | kudo: 43b9e57 | jnthn++ | src/classes/Routine.pir: First cut of wrap and unwrap. |
12:20 | |
| shorten | dalek's url is at xrl.us/beodvq | ||
|
12:37
rg1 joined
13:02
bacek joined
|
|||
| dalek | kudo: 508a18c | (Moritz Lenz)++ | t/spectest.data: fix typo in t/spectest.data, moritz-- |
13:06 | |
| shorten | dalek's url is at xrl.us/beodyn | ||
|
13:33
cognominal joined
13:34
gryphon joined
|
|||
| dalek | kudo: a36c3b2 | jnthn++ | src/classes/Routine.pir: Some tweaks to the first cut of wrap; assign could get things confused, plus also need to track relations of Parrot and Rakudo level subs. |
13:38 | |
| kudo: 6bcccd6 | jnthn++ | src/builtins/control.pir: Implement callwith for the wrapped sub case. |
|||
| kudo: 8abc537 | jnthn++ | t/spectest.data: Add wrap.t to spectest.data. |
|||
| shorten | dalek's url is at xrl.us/beod27 | ||
| kudo: 4561d2f | jnthn++ | : Merge branch 'master' of git@github.com:rakudo/rakudo |
|||
| shorten | dalek's url is at xrl.us/beod29 | ||
| dalek's url is at xrl.us/beod3b | |||
| dalek's url is at xrl.us/beod3d | |||
|
13:41
jimmy joined
13:51
Tene joined
13:54
Andy joined
14:07
cognominal joined
14:10
DietCoke joined
14:16
davidfetter joined
14:47
TimToady joined,
diakopter joined
15:03
Tene joined
15:08
rdice joined
15:15
iblechbot joined
|
|||
| dalek | kudo: 531fe43 | jnthn++ | src/builtins/control.pir: Add a stubby callsame that works for argumnetless case. Not figured out how to handle getting the arguments so well just yet, but this is probably enough to pass some of wrapping.t which only needs that. |
15:28 | |
| shorten | dalek's url is at xrl.us/beoefj | ||
| dalek | kudo: 04f63fc | jnthn++ | src/classes/Routine.pir: Make sure accessing the non-existent return value of unwrap doesn't cause Null PMC Access by handing back Nil. |
||
| shorten | dalek's url is at xrl.us/beoefm | ||
| dalek | kudo: 4866942 | jnthn++ | src/classes/Code.pir: Implement .callwith method for Code objects. |
||
| shorten | dalek's url is at xrl.us/beoefq | ||
|
15:31
nopaste joined
15:40
darbelo joined
15:54
Psyche^ joined
15:58
amoc joined
16:09
Theory joined
16:21
nopaste joined
|
|||
| DietCoke | (quiet today) | 16:35 | |
| particle- | now that dietcoke is gone, we can start chatting again. | 16:38 | |
| Coke | jonathan: ping. | ||
| jonathan: { if (foo) foo=NULL } is better written as "foo=NULL", innit? | 16:39 | ||
| (r37980) | |||
| particle- | otherwise you end up with null or zero | 16:40 | |
|
16:42
Tene_ joined
|
|||
| jonathan | Coke: Heh. Rather pointless chekc, yes. | 16:44 | |
| Coke: I was originally going to copy to a new struct then decided against... | |||
| particle- | (code reviews)++ | ||
| jonathan | Indeed | 16:45 | |
| Coke | meh. just a mindless check. I seem to spend half my day looking at commits. | ||
| (for $work too) | |||
| particle- | that's a nice gig | 16:48 | |
| i'm writing php and c | 16:49 | ||
| and nobody looks at my code. | |||
| jonathan spent some time recetnly doing VBScript, and nobody looked at his code either | |||
| particle- | ho, and sieve scripts. | ||
| dalek | rrot: r37996 | jonathan++ | trunk/src/pmc/sub.pmc: [core] Remove pointless condition spotted by Coke++. |
||
| Coke works in cfmx, so looking at C is actually refreshing. =-) | |||
| jonathan | Me looking at the previous developer's code on the other hand, now that was depressing. | ||
| Coke | I always find cfmx code I take over to be particuarly heinous. | 16:50 | |
| I wonder occasionally if php maintenance devs have the same issue. | |||
| jonathan | Well, depends who wrote the code I guess. | ||
| On one codebase I've worked on recently, some of it wasn't so bad, some of it was pretty awful. | 16:51 | ||
| particle- | i'm just glad that php has eval | ||
| it's made writing code so much easier, because i can generate the boilerplate and eval it | |||
|
16:51
nopaste joined
|
|||
| Coke | Ugh. I try to rip out eval wherever possible. =-) | 16:52 | |
| I find that it's most commonly used in CFMX by people who don't get hash syntax. =-) | |||
| instead of struct[key] you get something like (perl syntax) eval "struct.$key" | 16:53 | ||
| jonathan | .oO( I hope they validated $key! ) |
16:54 | |
| confound | jonathan: valiwhat? | 16:56 | |
| Coke | jonathan: no. | 16:57 | |
| I found that pretty universally in javascript/cfmx here. | |||
| pmichaud | $key validation: if $key != $key { die "$key is invalid." } | ||
| lunch, $otherjob, then blogging and hackathon writing | 16:59 | ||
| bbl | |||
| jonathan | Coke: I can haz arbitary code execution? ;-) | 17:00 | |
| Coke | the code base here is an amazing example of doing things wrong. =-) | 17:03 | |
|
17:06
altious joined
|
|||
| dalek | a: 4b2e14e | (Francois Perrad)++ | src/ (2 files): Now, works with Parrot r37968 (PCT/POST refactor) |
17:08 | |
| shorten | dalek's url is at xrl.us/beoeq4 | ||
| dalek | kudo: 4cc08e8 | jnthn++ | src/parser/actions.pm: Add multiple prefix constraint check, as done by STD.pm. |
17:10 | |
| shorten | dalek's url is at xrl.us/beoeq6 | ||
|
17:11
davidfetter joined
17:21
Infinoid joined
17:31
nopaste joined
17:38
altious joined
17:39
japhb joined
17:43
particle joined
17:50
Khisanth joined
17:56
rdice joined,
nopaste joined
|
|||
| dalek | rrot: r37997 | cotto++ | trunk/src (2 files): [JIT] remove undocumented dependency of jit code on PMC internals, fixing TT #365 Whiteknight++ for the review |
17:59 | |
|
18:02
rdice joined
18:07
barney joined
|
|||
| dalek | kudo: b512bdc | jnthn++ | src/classes/Associative.pir: %h<> should return everything in the hash, like @a[] returns everything in the array. |
18:12 | |
| kudo: 9854f25 | jnthn++ | src/parser/actions.pm: Enforce a single prefix type constraint on parameters. |
|||
| shorten | dalek's url is at xrl.us/beoezk | ||
| shorten | dalek's url is at xrl.us/beoezn | ||
| dalek | kudo: 07ed756 | jnthn++ | src/classes/Range.pir: Implement postcircumfix:[ ] in Range. It doesn't know about infinite ranges, but not much else does yet either. |
||
| shorten | dalek's url is at xrl.us/beoezp | ||
|
18:12
flh joined
18:38
particle joined
|
|||
| dalek | rrot: r37998 | cotto++ | trunk/src/pmc (2 files): [PMC] use VTABLE w/switch instead of MULTI for Integer's is_equal |
19:21 | |
| Coke | is that a behavior switch that we need a dep notice for (does one already exist/) | 19:22 | |
| there it is. n'mind. | 19:23 | ||
| msg chromatic (modern perl, last post s/precide/precise/) | 19:28 | ||
| purl | Message for chromatic stored. | ||
|
20:00
rdice_ joined
20:04
iblechbot joined
20:14
clunker9 joined
20:26
uniejo joined
20:35
contingencyplan joined
21:11
bacek joined
|
|||
| bacek | good morning | 21:19 | |
| Infinoid: around? | 21:22 | ||
| Infinoid | hi bacek | 21:23 | |
| happy ... *thinks about it* ... Friday? | |||
| bacek | Infinoid: hi. Yeah, Good Friday :) | ||
| I've got question about PackFiles. Currently PackFile works as factory for Segments. And it's very hard to represent in PMCs because of memory management. | 21:25 | ||
| Any ideas/suggestions? | |||
|
21:25
joubert joined
|
|||
| bacek need more coffee | 21:25 | ||
| Infinoid | well, eventually it would be nice to move all of packfile.c into the pmcs and use pmc attrs instead of just wrapping the packfile structs | 21:26 | |
| the wrapping stuff is just stage 1. and the readonly stuff I've written is stage 1 of stage 1 :) | |||
| where are you having difficulty representing them in pmcs, though? there's still a 1:1 mapping between c structs and pmc objects | 21:27 | ||
| I suppose the initialization part is a bit weird. | |||
| bacek | For example PackFile_Segment_new followed by PackFile_Segment_destroy will just crash. | 21:28 | |
| Because _destroy uses "virtual functions" from PackFile | |||
| Infinoid | ah, so the underlying packfile api itself is brittle? | 21:29 | |
| bacek | Infinoid: it's good for "pure C" :) | 21:30 | |
| Infinoid | right, but it makes it difficult to make the pmcs bulletproof | ||
| bacek | indeed. | ||
| All possible "bad things" can happen. | 21:31 | ||
| Like adding segment to directory twice will lead to segfault. | |||
| Replacing segment in directory can lead to segfault or leak. | 21:32 | ||
| etc, etc, etc... | |||
| Infinoid | hmm. do you think it'd be easier to put a bunch of management code in the pmc frontend, or to just hold off on creating the underlying structures until the last possible moment? | ||
| bacek | Infinoid: my thought that creating underlying PackFile just on "Packfile.pack" is best option. | 21:33 | |
| And create PMCs on "unpack" | |||
| Infinoid | Can we do that without having PackfilePacked vs PackfileUnpacked objects to keep everything separate? | 21:34 | |
| bacek | Only one disadvantage - we can't create-and-execute on fly. | ||
| Yes, we can. | 21:35 | ||
| Packfile.pack will create "C" objects, serialize and destroy them in single call. | |||
| Infinoid | ok | ||
| hah, so you just won't keep them around, ok | 21:36 | ||
| bacek | "PackfileUnpacked" is what current PMCs became. | ||
| E.g. "PackfileDirectory" is just Hash. | |||
| We can even remove it totally. | 21:37 | ||
| Infinoid | as I understood it from jonathan, the implementation path was to wrap the packfile stuff, migrate all the callers onto the pmc-based api, and then start moving the underlying logic into the pmcs directly | ||
| if you want to do things in a different order, that's ok. but be careful, there's a *lot* of work involved in this stuff | |||
| bacek | It's hard to wrap in bullet-proof manner. | ||
| bacek summon jonathan | 21:38 | ||
| Infinoid | the issue you're raising is that there are too many corner cases that can crash and no way we'll ever catch them all, right? | ||
| bacek | Who currently creates packfiles? IMCC and PIRC? | 21:39 | |
| Infinoid: yes. | |||
| Infinoid | the files, or the objects? | ||
| bacek | both | ||
| Infinoid | so far, the only thing I know of creating pmc objects are the tests | 21:40 | |
| bacek | :) | ||
| particle- | the calling conventions create more pmcs than the tests :) | 21:41 | |
| Infinoid | Packfile PMCs? | ||
| particle- | er, i hope not. | ||
| guess i picked the wrong day to stop sniffing glue. | |||
| Infinoid | never stop, that's my motto | 21:42 | |
| weird. When I did an "ack PackFile_new", I got a hit from tools/dev/pbc_to_exe.pir, but that's really C packfiles, not PIR ones | 21:45 | ||
| bacek | So, if I'll implement PMCs which can create but not hold underlying "C" objects will solve almost all corner cases. | ||
| Andy | such is the limittion of going off file extensions. | ||
| Infinoid | I wasn't blaming ack. It's just kinda confusing to me to see pir generating c | 21:46 | |
| particle- | welcome to the future. your new id is on the dresser floating in your bedroom. | 21:47 | |
| bacek | And will reduce size of code (just because we can reuse other PMCs). E.g. PackfileSegment is just ResizeableIntegerArray. Directory and ConstTable are Hashes. | ||
| Infinoid | if you can do that, it will then be a short step to getting rid of the underlying c stuff altogether | 21:48 | |
| bacek | Infinoid: I can do it. It's actually much easy than properly wrap all stuff :) | 21:49 | |
|
21:49
quassel251 joined
|
|||
| dalek | kudo: 5658a57 | jnthn++ | build/ (2 files): Implement * mathop val and val mathop * generating blocks. Left out infix:<-> for now. |
21:50 | |
| shorten | dalek's url is at xrl.us/beofro | ||
| dalek | kudo: 4a95115 | jnthn++ | perl6.pir: Oops, forgot this file too. Epic git usage fail... |
||
| shorten | dalek's url is at xrl.us/beofrq | ||
|
21:51
bobke joined
22:07
bobke joined
|
|||
| bacek | Infinoid: still around? | 22:17 | |
| "Packfile is Hash" or "Packfile has Hash"? (In terms of Directory handling) | 22:18 | ||
| Infinoid | I kinda figured Packfile itself would just have some ATTRs for the directory and version and uuid and all of that stuff | 22:19 | |
| PackfileDirectory, on the other hand, should probably be "extends Hash" | 22:20 | ||
| bacek | We probably can get rid of Directory. | ||
| Infinoid | ok, ok | ||
| interesting idea. | |||
| bacek | Because Directory is just storage representation. | ||
| Infinoid | yeah, there's no real point in separating those objects | ||
| bacek | I'll implement Packfile as "has Hash". We can change it in future. | 22:21 | |
| Infinoid | ok. Note that that change of object layout will require an update to the API described in pdd13 (and probably be a good idea to get jonathan to sign off on it) | 22:22 | |
| bacek | Infinoid: I'm not going to change layout :) | 22:24 | |
| And will create exactly same PBC as described in pdd13. | |||
| Infinoid | and think about getting rid of Directory later? :) | ||
| cool. | |||
| bacek | But PMCs API will be slightly different | ||
|
22:25
Casan joined
|
|||
| Infinoid | yes, pdd13 specifies the PMC API as well | 22:25 | |
| one problem you'll run into: the Packfile PMC uses the hash API to allow access to the header fields... the exact same vtable functions as Directory uses to allow access to the segments | 22:26 | ||
| so if you merge them, you'll have to special-case certain key names for the header fields | |||
| bacek | pdd13 describes read-only access to binary PBC... | ||
| Infinoid | pdd13 also specifies the PMC API, under the heading "Packfile PMCs | 22:27 | |
| " | |||
| bacek | (I was wrong) | ||
| Infinoid | So yeah, if you want to change the PMC API, you'll have to update the pdd too. | 22:28 | |
| This is probably a good time for that, as the pdd already needs updating for some annotations stuff (which is on jonathan++'s list) | |||
| jonathan notices the list has started to emerge from the pile of stuff under his bed and quickly stuffs it back under | 22:32 | ||
|
22:33
TimToady joined
|
|||
| bacek looking under jonathan's bed - IT'S A LOT OF TREASURES HERE!!! | 22:33 | ||
| ok, there is 4 days long weekend. I'll try to finish packfile pmcs implementation over it. | 22:36 | ||
| afk # family stuff | |||
|
23:02
Whiteknight joined
23:13
tetragon joined
|
|||
| dalek | kudo: f9a2236 | jnthn++ | src/parser/ (2 files): Fix parsing of whatever. |
23:29 | |
| shorten | dalek's url is at xrl.us/beof4k | ||
| dalek | kudo: 70fc009 | jnthn++ | src/classes/ClassHOW.pir: Implement *.foo generating the closure { $^wob.foo }. |
||
| shorten | dalek's url is at xrl.us/beof4n | ||
|
23:38
bacek joined
|
|||
| bacek | jonathan: ping | 23:54 | |
| jonathan | bacek: no route to host | ||
| ;-) | |||
|
23:54
TiMBuS joined
|
|||
| bacek | :) | 23:54 | |
| jonathan | bacek: What're you wanting? :-) | 23:55 | |
| bacek | I'm going to rename Packfile PMC attributes to be in sync with physical packfile header | ||
| any objections? | |||
| e.g. version_major -> major, etc | 23:56 | ||
| jonathan | OK, two things | ||
| purl | two things are giving you a "before" keyword | ||
| jonathan | consistency for the win | ||
| However, I suspect I might have thought about the external names more than the ones in the code. ;-) | 23:57 | ||
| That is, maybe renaming the struct describing the header to match the external interface would be saner. | |||
| bacek | ok. Let's rename header fields :) | 23:58 | |
| next question: we have Packfile.uuid_length attribute. Do we really need it? | |||
| jonathan | in the header? Or externally visible? | 23:59 | |
| bacek | in PMC. | ||
| And in header of cause. | |||
| (We need it in header :) | |||
| jonathan | I think that one does not need to be externally exposed. | ||
| Yeah, in the header I think we gotta have that. | |||
| bacek strikes another line in pdd13 | |||