|
Parrot 1.0 Released | parrot.org | 367 RTs left! Set by moderator on 12 April 2009. |
|||
|
00:09
AndyA joined,
TiMBuS joined
00:15
s1n left,
s1n joined
00:38
wayland76 joined
01:37
allison joined
01:40
Andy joined
01:47
Tene joined
02:05
kid51 joined
|
|||
| dalek | rrot: r38097 | Util++ | trunk/docs/book (9 files): [book] Typo corrections |
02:23 | |
| rrot: r38098 | allison++ | branches/pcc_rewiring/src/pmc/cpointer.pmc: [pcc] Don't mark the PMC and String children of a CPointer (have made |
02:39 | ||
| rrot: r38099 | allison++ | branches/pcc_rewiring/src/ops/core.ops: [pcc] Remove unnecessary reset on unused interpreter struct member. |
|||
|
02:47
janus joined
03:10
eternaleye_ joined
03:31
workbench joined
03:32
ab5tract joined
|
|||
| dalek | rrot: r38100 | allison++ | branches/pcc_rewiring (2 files): [pcc] Implement parameter filling from C arguments, to be used by |
04:31 | |
| purl | pccmethods are my friends | ||
|
05:31
Theory joined
|
|||
| Tene | any parroters around boston, ayone know? | 05:37 | |
|
05:53
szabgab joined
05:57
eternaleye joined
06:10
ruoso joined
06:31
uniejo joined
06:45
japhb joined
07:21
amoc joined
07:26
skv_ joined
07:27
skv__ joined
07:28
iblechbot joined
07:29
krunen joined
07:57
masak joined
|
|||
| cotto | Cool. Now I know what "segfault" is in German. | 08:07 | |
| wayland76 | zegvault? | 08:09 | |
| cotto | Speicherzugriffsfehler | 08:12 | |
| I love how you can stick together random words in German like that. | 08:13 | ||
| It's too bad that hasn't migrated to English. | |||
| mikehh | we do have some - like busstop | 08:16 | |
| wayland76 | and goatherd :) | ||
| But if I understand correctly, the Germans do it in a more free-form fashion | 08:17 | ||
| cotto | Yup. | ||
| masak | as do the Swedes, and other speakers of the nordic languages. and Finnish. | 08:19 | |
| wayland76 | You know how sometimes in English, people say "is that even a word", and yet it's a perfectly legitimate word that just has a lot of suffixes/prefixes and stuff? | ||
| Well, the Germans do that, but with words, instead of prefixes and suffixes | |||
|
08:19
riffraff joined
|
|||
| wayland76 | (or that's the impression I get) | 08:20 | |
| masak | but we're suffering from English influences, and people increasingly tend to spell compond words apart. | ||
| wayland76 | I didn't know about the North Germanic languages being that way | ||
| It's interesting how others influence your speech | |||
| masak | totally legit Swedish word: "kyrkogƄrdsvaktmƤstare". "graveyard janitor". | 08:21 | |
| wayland76 | (I guess I'm just thinking about how I know lots of big words, but rarely use them in order to accomodate those around me) | ||
| masak | note the extra "s" in the middle, functioning as a sort of priority marker. a primitive parenthesizing system. | 08:22 | |
| wayland76 | What's the vakt part mean? | ||
| masak | watch. | 08:23 | |
| wayland76 | (I don't know Swedish, but I know enough Old English to make sense of the rest, I think) | ||
| masak | so, "watchmaster" | ||
| wayland76 | Ah, ok :) | ||
| masak | or "guard", rather. | ||
| wayland76 | kirk-yard--watch-master, yes? | ||
| masak | something like that. :) | ||
| wayland76 | (kirk is Scots for church) | 08:24 | |
| masak | it's from the Nordic languages originally, I believe. | ||
| wayland76 | Well, I suppose that's possible. I guess I was under the impression that it was OE, but I couldbe wrong | 08:28 | |
| Incidentally, the English have aglommerated: www.u.arizona.edu/~ctb/wordhord.html | 08:29 | ||
| But no longer :) | |||
| Cathode ray tube in Old English: niưerstigendescimapipe :) | 08:30 | ||
| English "church": O.E. cirice "church," from W.Gmc. *kirika, from Gk. kyriake (oikia) "Lord's (house)," from kyrios "ruler, lord." | 08:31 | ||
| The OE would probably be pronounced something like kee-ri-keh (not IPA, I know :) ), which isn't far from kirk | 08:32 | ||
| But this probably belongs on #perl6 -language, not perl6^Wparrot compiler :) | 08:33 | ||
| Anyway, food. afk& | 08:34 | ||
|
09:42
TiMBuS joined
10:22
gaz joined
10:37
ruoso joined
10:39
bacek joined
10:48
kid51 joined
11:30
clunker3 joined
11:36
AndyA joined
12:00
iblechbot joined
12:03
TiMBuS joined
|
|||
| dalek | rrot: r38101 | Util++ | trunk/docs/book/ch13_reference.pod: [book] Typo correction |
12:12 | |
|
12:33
flh joined
|
|||
| dalek | rrot: r38102 | Util++ | trunk/docs/book/ch13_reference.pod: [book] PASM Quick Reference - Added new opcodes from io.ops |
12:46 | |
| rrot: r38103 | Util++ | trunk/docs/book/ch13_reference.pod: [book] PASM Quick Reference - Renumbered tables |
12:49 | ||
| mikehh | t/codingstd/copyright.t fails at r38100 - Kubuntu Intrepid Amd64 | 13:00 | |
| I think someone mentioned that it worked on perl 5.8.8 - I am on 5.10.0 | 13:01 | ||
| the rest of make codetest passes just fails t/codingstd/copyright.t - Failed test: 3 | 13:07 | ||
|
13:09
gryphon joined
13:10
ruoso joined
|
|||
| mikehh | running make fulltest_all while I go shoping - afk& | 13:11 | |
|
13:37
DietCoke joined
13:50
Tene_ joined
|
|||
| dalek | rrot: r38104 | Util++ | trunk/docs/book/ch13_reference.pod: [book] Typo correction |
14:18 | |
| Coke | so I'm looking at enabling a compiler warning, unused-parameter | 14:21 | |
| basically enforces the use of UNUSED or SHIM (we're already doing that most places). PMCs are a bit tricky. | |||
| we have some methods that are unimplemented, those are easy enough to generate UNUSED() for. we have a few cases, though, where the body of a VTABLE or METHOD doesn't refer to the interp that was passed in. It seems a bit onerous to the PMC designer to force them to add UNUSED(INTERP) in the body decl. in the PMC, no? | 14:23 | ||
| particle- | by doesn't refer, you mean interp is unused? | 14:24 | |
| Coke | yes. | ||
| and interp doesn't even appear in the VTABLE decl. | |||
| dalek | rrot: r38105 | Util++ | trunk/docs/book/ch13_reference.pod: [book] PASM Quick Reference - Removed old dotgnu.ops opcodes |
||
| particle- | yes, that's tricky. | 14:25 | |
| i don't want to force folks to add that there, it doesn't make sense. | |||
| so how do you tell the warning to shut up, skip pmc files? | |||
| Coke | ok. but if an explicitly mentioned arg is unused, that's OK, neh? | ||
| particle-: I'd rather not skip PMC files. | |||
| particle- | yes | ||
| i'd rather not skip, too. | 14:26 | ||
| but how do you stop the warnings? | |||
| Coke | I'd rather have the code generation DTRT. | ||
| particle- | ah, yeah, static analysis during codegen | ||
| Coke | easy, generate UNUSED(INTERP) properly. =-) | ||
| particle- | yep, that's the way to do it. | ||
| Coke | just wanted to verify that forcing the PMC to add it manually was wrong. | ||
| Util | You both out-typed me, w.r.t code generation. idea++ | 14:27 | |
|
14:30
pyrimidine joined
|
|||
| Coke | hurm. default.pmc and null.pmc share a bit of codegen. | 14:32 | |
| er, /should/, but it's cut and pasted. | |||
| particle- | refactoring will probably cause failing tests | 14:33 | |
|
14:34
iblechbot joined
|
|||
| Coke | nothing functional. | 14:35 | |
| particle- | si, es verdad. | 14:36 | |
|
14:36
Theory joined
15:00
bsdz joined
15:04
davidfetter joined
15:09
buildbot joined
15:20
rg joined
|
|||
| particle- | rakudobug? | 15:39 | |
| purl | i heard rakudobug was mailto:rakudobug@perl.org | ||
| dalek | kudo: 8062a1b | (Moritz Lenz)++ | t/spectest.data: three more passing tests for t/spectest.data |
15:46 | |
| shorten | dalek's url is at xrl.us/beoxpr | ||
| dalek | kudo: 48c2042 | (Moritz Lenz)++ | Test.pm: fix logic error in unary nok() function in Test.pm |
||
| shorten | dalek's url is at xrl.us/beoxpt | ||
| dalek | kudo: 13c2c7c | (Moritz Lenz)++ | (2 files): The sub form of split() expects the delimiter as second parameter |
||
| shorten | dalek's url is at xrl.us/beoxpv | ||
| dalek | kudo: f989187 | (Moritz Lenz)++ | t/spectest.data: return2.t was merged into return.t; remove it from spectest.data |
||
| shorten | dalek's url is at xrl.us/beoxpx | ||
| dalek | kudo: 9ee6477 | (Moritz Lenz)++ | t/spectest.data: we pass angle-brackets.t |
||
| shorten | dalek's url is at xrl.us/beoxpz | ||
| dalek | kudo: d208e1c | (Moritz Lenz)++ | (2 files): Hash.reverse is now called .invert |
16:00 | |
| shorten | dalek's url is at xrl.us/beoxti | ||
|
16:13
Tene joined
16:15
contingencyplan joined
16:16
iblechbot joined
16:53
davidfetter joined
|
|||
| Coke_afk | is thawfinish a vtable? | 17:08 | |
| Coke | (it is) - why is not declared VTABLE in most PMCs? | 17:09 | |
|
17:19
braceta joined
|
|||
| rg | ok, i believe i've figured out why t/op/trans.t is failing on jit for freebsd aswell as some linux platforms | 17:21 | |
| what's interesting is that my workaround makes gives me a segfault on other tests | 17:22 | ||
| makes me wonder how useable this jit implementation really is :( | 17:24 | ||
|
17:27
kj joined,
barney joined
|
|||
| dalek | rrot: r38106 | coke++ | trunk/src/pmc (6 files): [cage] mark these VTABLE implementations. |
17:30 | |
|
17:31
masak joined
17:34
Theory joined
|
|||
| Coke | someone needs to take up a marketing position for parrot and for perl6. | 18:01 | |
| Util | In .ops files, what is the difference between `invar` and `inout` parameters? | 18:02 | |
|
18:07
mikehh_ joined
|
|||
| allison | Util: 'invar' just means it's a variable rather than a constant. 'inout' means it's a result (a "destination" register) | 18:10 | |
| Util: 'in' can be either a register or a constant | 18:11 | ||
| Util | thanks, allison | 18:19 | |
|
18:20
chromatic joined
|
|||
| bsdz | hi, anyone have any ideas how i can trace a "set_pmc_keyed() not implemented in class 'Integer'" error in a 'parrot;PCT;HLLCompiler;eval' sub? it says (EVAL_7:168) for the location; i wonder if that's the same as i woudl see in --target=pir? | 18:20 | |
| chromatic | Should be. | 18:21 | |
| bsdz | oh cool. i'll take a closer look. thanks | ||
| Coke | ah, great, parrot and perl6 abuse. | 18:27 | |
| (other server) | |||
| to get the EVAL files to stick around, use -D60, IIRC. | 18:28 | ||
| bsdz | very cook | 18:29 | |
| i meant cool :) | |||
| rg | ok, the segfault is just another jit bug | ||
| allison | Util: I have a pile of uncommitted changes to the book chapters. Is it easier for me to go ahead and commit them, or to integrate your changes into my changes? (How far along are you?) | 18:30 | |
| Util: and, thanks for the typo fixes, and work on the book! | |||
| chromatic | #ps time | 18:31 | |
| moritz | I don't have time for #ps right now; but I have nothing to report either | ||
| have the appropriate amount of fun ;-) | |||
|
18:44
eggyknap joined
|
|||
| eggyknap | Question: per #parrotsketch, calls to PIR subs/methods from C work. How stable can I assume the API involved to be? (in other words, I wanna play - should I expect to have to rewrite a bunch of stuff b/c of API changes) | 18:45 | |
| chromatic | That depends on which API you use. | ||
| eggyknap | Fair 'nuff. I admit to not having done my homework recently enough to know what my choices are. | 18:46 | |
| allison | If you're using the Parrot_pcc_invoke set of routines, you're fine | ||
| If you're using any of the other variants, they're on the way out | |||
| eggyknap | Sweet... many thx. | 18:47 | |
| Coke | so, the boston.pm mailing list is suggesting that the perl6 community has dumped parrot and has moved on the CLR. | 19:06 | |
| www.mail-archive.com/boston-pm@mail...05520.html | |||
| News to me. | 19:07 | ||
| chromatic | s/News/Crack/ | 19:08 | |
| gravity | That makes me feel better that I've not gone to boston.pm | ||
| particle- | no, no, that's just mitchell charity, who is somewhat wacky. | 19:09 | |
| bsdz | They'd have more luck if they targeted the DLR not the CLR. Perhaps they should forget Perl altogether and use Powershell - dog slow mind you. | ||
| chromatic | "Elf is based on the hypothesis that developers could be found if the implementation language was itself Perl 6." | 19:11 | |
| I question that hypothesis, based on the history of Elf. | |||
| PerlJam | chromatic: you noticed that too, eh? :) | ||
| chromatic | I've been saying that for a few years. | ||
| particle- | one lone developer, who never sent a mailing list message about it until now. | 19:12 | |
| masak | maybe it just Isn't Ready for developers yet? | ||
| chromatic | If you want to run Perl 6, you have to invent most of Parrot. | ||
|
19:12
altious joined,
uniejo joined
|
|||
| PerlJam | masak: release early, release often. | 19:13 | |
| masak | PerlJam: true. | ||
| chromatic | "Perl 5 suffers from [its] lack of sufficient testing." | 19:14 | |
| Perl 5 suffers from many things. That is not on the first page of my list. | |||
| masak | frankly, I'm impressed by Elf simply because it's a fairly large piece of runnable Perl 6 code. | ||
| particle- | but by definition, it's throwaway. | 19:15 | |
| 'Any large project written in p6 now is almost by definition throw away code. ... "I'd have architected this differently if I had full p6"... ' | |||
| masak | I'm not sure I agree fully to that. | 19:17 | |
| Half a year ago, yes. | |||
| particle- | i don't agree at all. | ||
| masak | Today, I'd guess the code in Druid is pretty close to Perl 6.0.0 code. | ||
| particle- | except laziness, and some other small things :) | ||
| chromatic | "Raise enough funds for TPF to hire a full time, dedicated project manager (someone from the Perl community willing to work on minimal income)." | ||
| As if lack of project management were a problem. | 19:18 | ||
| particle- | yeah, it's the lack of contributors that's closer to the problem | ||
| chromatic | "Break down the features into self-contained projects, and put them out to bid. Something a contract programmer could work on for a month or two between projects. " | ||
| particle- | what's a paid pm going to manage? volunteers with limited, unpredictable tuits? | 19:19 | |
| chromatic | As if TPF can afford to pay contract rates. | ||
| Coke | if we really did need a paid PM, would we want the cheapest one we could find? =-) | ||
| how do we fix a lack of contributors? I know some very sharp people who have told me flat out they'd never work on parrot. | |||
| chromatic | You show visible, frequent progress. | 19:20 | |
| Coke | because of issues with the architecture, or crappy docs, or... | ||
| chromatic: our progress isn't as visible as you might like. | |||
| chromatic | I agree, but imagine if we had one release a year. | ||
| Coke | (I'm not saying we gear ourselves towards the vocal idiots I deal with.) | ||
| true. even worwse. | |||
| chromatic | What would have happened if we'd set the 1.0 release date and failed to meet it? | ||
| Coke | but I can't answer questions like "are anything of the languages that run on parrot feature complete? fast?" | ||
| particle- | coke, do you really hear "i'd never contribute to that project. there aren't enough docs." | ||
| chromatic | When we set the release date, a lot of people said "You'll never hit it." | 19:21 | |
| particle- | coke: lua is "complete" | ||
| Coke | not not enough docs. quality thereof. | ||
| particle-: ... really? | |||
| particle- | yes. | ||
| Coke | interesting how someone on the board had no idea. =-) | ||
| chromatic | Lua's been complete for at least a year. | ||
| Lua needs profiling and optimization (and shows how our JIT just isn't cutting it), but it's been complete. | 19:22 | ||
| barney | put that on reddit | ||
| bsdz | parrot would certainly have a lot more uptake if it was bundled as a vm in ie, firefox and chrome. also if it had the same systray applet that java has. probably need to be locked down security-wise first. | 19:23 | |
| chromatic | "One could certainly imagine doing a javascript implementation of the p5 vm for instance." | ||
| I can't imagine anyone familiar with Perl 5's internals doing that. | 19:24 | ||
| particle- | bsdz: yes, if parrot 1.0 were parrot 2.0, it would be more useful for all users | ||
| we targeted high-level language developers with the 1.0 release, not business or casual users. | 19:25 | ||
| that's targetted for 2.0 and beyond, so we'll be working on it this year. | |||
| bsdz | small steps first then take larger ones. i for one can see parrot doing what sage math does but more efficiently. a unifying vm that brings together lisp, python, m-script and perl. | 19:26 | |
| PerlJam | bsdz: while I like the sentiment, that list makes me go ugh. | ||
| bsdz | ha ha. it has that effect on some :) | 19:27 | |
| i must admit i don't like lisp but that's what maxima is written in (perhaps even emacs?) | 19:28 | ||
|
19:36
PerlJam joined
|
|||
| bsdz | on a different topic. are there any known issues using a keyed PAST::Var and vivibase on a multidimensional pmc when extending the dimensions. pseudo code like this x[1] = 5; /* x= ( undef, 5 ) */; x[1][2] = 3; /* x= ( undef, (undef, undef, 3) ) */. ignoring the fact i'm also clobbering one of my elements. | 19:37 | |
| Coke | particle-: I'm not sure that 1.0 was really a stable release for HLL developers. | 19:39 | |
| all we did was move our deprecation window from 1 month to six months there. | |||
| everything is still subject to change. | 19:40 | ||
| PerlJam | Coke: that sounds slightly more stable :) | ||
| Coke | for large values of everything. (if not actually everything) | ||
| I just want to be careful about overselling as well as underselling. | |||
| particle- | it's a stable platform for hll developers. | 19:41 | |
| last year saw a significant number of segfaults and memory leaks eliminated | |||
| many apis were standardized | |||
| deprecation pace was slowed | 19:42 | ||
| a release policy was implemented. | |||
| a support policy, too | |||
| Coke | particle-: I call bullshit. =-) | ||
| the 1.0 release basically said that all the api's were up for shuffle before the 1.4 release. | 19:43 | ||
| chromatic | stable != complete | ||
|
19:43
riffraff joined
|
|||
| Coke | s/before/in/ | 19:43 | |
| particle- | coke: java deprecates apis, so does .net. how is this different than those production products? | ||
| PerlJam | particle, Coke: If I'm interested in implementing a language on parrot, what advantages do I get? (That's the only marketing question that needs to be answered based on the claims of 1.0 IMHO) | 19:44 | |
| Coke | PerlJam: right now? none? | ||
| all of the good bits are in the future, no? | |||
| PerlJam | Coke: I think "none" is a little severe. | ||
| bsdz | software is never complete - it's like Aristotle's Arrow | ||
| Coke | PerlJam: I'm a little jaded, and have just spent an hour listening to someone rant about such things, apologies. | 19:45 | |
|
19:45
uniejo joined
|
|||
| particle- | coke: obviously, you listen too much. | 19:45 | |
| tell raye i said that. | |||
| Coke | lua? | 19:46 | |
| purl | lua is at www.lua.org/ | ||
| chromatic | I've always see 1.0 as a shift in focus. "Here is the minimum supported feature set we believe will allow an HLL developer without commit access to the project to begin to build a usable, real-world language." | ||
| s/(?<incomplete>see)/$+{incomplete}n/ | 19:47 | ||
| particle- | unlike perl 6, which is a perfect-world language :) | ||
| Coke | it would be interesting to see current benchmarks of lua on parrot vs. other lua.s | 19:48 | |
| msg fperrad it would be interesting to see current benchmarks of lua on parrot vs. other lua.s | |||
| purl | Message for fperrad stored. | ||
| cotto | Coke, I think fperrad's Lua does too much reinventing of the wheel to be a meaningful benchmark of a Parrot-hosted language implementation. | 19:49 | |
| PerlJam | cotto: which wheels? | 19:50 | |
| chromatic | Dispatch, for one. | ||
| cotto | PerlJam, verifying so I don't feel stupid later. | 19:52 | |
| Coke | cotto: well, partcl was also godawful slow. | ||
| PerlJam | "was"? | ||
| purl | i think "was" is "what" | ||
| Coke | PerlJam: yes. now it's just broken. | ||
| PerlJam | oh, bummer | ||
| Coke | the patch allison used to test building against an installed parrot is broken in 1.0. I haven't had the tuits to fix it, and am basically waiting for rakudo to do it for me. | 19:53 | |
| chromatic | We still don't have good profiling tools to figure out why, though. | ||
| (Random guess: PMCs.) | |||
| Coke | partcl has to use PMCs for pretty much everything anyway, at least the last I checked. | 19:54 | |
| if parrot is using too many of them internally, well... | |||
| but yes. need profiling. | |||
| chromatic,particle- : so, for partcl at least, the promise of 1.0 hasn't been realized, and probably won't be until at least 1.1 | 19:55 | ||
| I'm not sure it's nicely fixable without fixing parrot_config | 19:56 | ||
| (that is, I'm not sure it'll ever work against a pristine 1.0) | |||
| chromatic | Now we know. | ||
| Coke | yup. | ||
| chromatic | When would we have managed to get to that point without trying to put out a 1.0? | ||
| Coke | chromatic: I'm not saying there's a better path. I'm just saying, let's clearly label the sign posts. | 19:57 | |
| chromatic | Sure, that's fine. | ||
| masak | which would be the least work, building an XML parser in PGE, or hooking up an existing C library? | ||
| chromatic | Were we wrong about some of our goals? Yep. Were we right about some of them? Yep. | ||
| masak, depends on the library. If the shared library does SAXy callbacks, PGE is easier. | 19:58 | ||
| Coke | masak: I would say that depends on if you're a perl6 programmer or a C programmer. | ||
| chromatic | Do we know more about what we need to do to support HLL developers? Yep. | ||
| masak | definitely a Perl 6 programmer. | ||
| Coke | then I'd probably push you towards PGE. I can't imagine it's going to be fast, though. | ||
| PerlJam | masak: didn't moritz or someone write a simplish XML parser a while back? | ||
| masak | PerlJam: aye. | ||
| PerlJam | masak: then you could reuse the grammar with PGE ;) | 19:59 | |
| masak | PerlJam: indeed. just wondering what is the best way to do it. | ||
| PerlJam | masak: I don't know about "best" but I know I'd go with PGE before C | 20:00 | |
| masak | understood. | ||
| purl | understood. are you on schedule? | ||
| masak | purl: no. :) | ||
| purl | masak: excuse me? | ||
| bsdz | any one have any expertise on vivibase capability in pct? | 20:01 | |
| particle- | vivibase is when you try to create a hash key, and the key doesn't exist, right? | 20:02 | |
| bsdz | yes, and same for arrays too | ||
| particle- | what expertise do you need? | ||
| PerlJam | (I know what it is too now ... am I an expert? ;) | 20:03 | |
| bsdz | well. i need to extend my array by another dimension and i'm getting "et_pmc_keyed() not implemented in class 'Integer'" errors. i see the same thing in squaak. i'm wondering if it's a limitation of the implementation. | 20:04 | |
| my squaak code looks like this: var y; y[1] = 5; y[1][2] = 3; | 20:05 | ||
| Coke | i don't think arrays are implicity multidimensional. | 20:10 | |
| I imagine that's (under the covers) trying to set 5[2] = 3; | |||
| particle- | we don't have multidim arrays | ||
| you have to implement your own pmc for that | |||
|
20:11
Theory joined
|
|||
| Coke | wierd, given all the theoretically optimized pmc variants we have. | 20:11 | |
| (tell me again why we have those?) | |||
| chromatic | Because C is fast! | 20:12 | |
| Coke | liar. | 20:13 | |
| rg | actually multidimensional arrays work in squaak (or did some time in the past). however, i guess there is no auto vivification | ||
| bsdz | well i am creating my own multidimensional array using my own :inline past::op in my vivibase. thing is it stumbles before it gets there. | ||
| chromatic | Perceptively, C is fast. If Ruby is too slow, write parts of your app in C. If Python is too slow, write parts of your app in C. If Perl is too slow, write parts of your app in C. | 20:14 | |
| If JavaScript is too slow, write more of your JavaScript compiler in JavaScript. | |||
|
20:14
eggyknap left
|
|||
| bsdz | chromatic: i couldn't agree more. C is fast but assembly can be even faster as i proved to some colleagues some time back | 20:15 | |
| chromatic | It's not that C isn't fast, but that memory is slow. | 20:16 | |
| PerlJam | chromatic: In your perl testing book do you talk about when one should create test data versus mocking a database for tests that require a database? | 20:18 | |
| PerlJam is looking for a good rule of thumb. | |||
| Coke | rule of thumb? | ||
| wow, thought purl would have something. =-) | |||
| chromatic | Some, yes. | ||
| PerlJam | One of my coworkers asked about it and I couldn't give a good answer as to when one approach would be favored over the other (except when the size of data needed for the test is large) | 20:20 | |
| chromatic | My rule of thumb re: mocking is to mock only those things that are horribly difficult to set up or for which exceptional conditions are unlikely to occur. | ||
| Disk full! Abort! LP1 on fire! Socket connection broken! IPv6 implemented everywhere! | |||
| particle- | porn! | 20:21 | |
| PerlJam | heh | ||
| chromatic | Mocking is appropriate in about 5% of the cases, I believe. | 20:22 | |
| The BDD folks (I hate that initialism) pull out the mock card at the start. | |||
| To their credit, some of them replace the mocks as they write real code. | |||
| particle- | bdd? | ||
| chromatic | It's like test-driven development, but with more awesome. | ||
| particle- | mock turtles. | 20:23 | |
| chromatic | Instead of programming, YOU'RE A ROCK STAR. | ||
| PerlJam | the ruby folks have taken BDD to great extremes. | ||
| chromatic | At the end of a successful day of BDD, they smash their keyboards. | ||
| allison | purl: bdd is Behavior Driven Development | ||
| purl | OK, allison. | ||
| chromatic | Never mind the Sex Pistols, here come the BDDers! | 20:24 | |
| allison | purl: bdd is also en.wikipedia.org/wiki/Behavior_Driv...evelopment | ||
| purl | okay, allison. | ||
| PerlJam | oddly, some of the arguments for BDD tools sound very familiar ... "*managers* can write tests. *clients* can write tests" etc. | 20:25 | |
| chromatic | That's because they're written in English! | ||
| Well, a domain-specific language. | |||
| Okay, Ruby. | |||
| Well, Ruby with a lot of stupid helper methods like .a .the .an .and | |||
| Just like English. | 20:26 | ||
| PerlJam | chromatic: wiki.github.com/aslakhellesoy/cucumber | ||
| chromatic | If you're a three year old. | ||
| PerlJam | (that's the latest thing my ruby friend is crazy about) | ||
| chromatic | Those who do not know Prolog are condemned to reinvent it, poorly. | 20:27 | |
|
20:29
Tene_ joined
20:32
gryphon joined
20:40
jan joined
|
|||
| bsdz | msg pmichaud i think there's an issue in PAST::Compiler::vivify. An example in Squaak "var y; y[1] = 5; y[1][2] = 3;" gives "get_pmc_keyed() not implemented in class 'Integer'. This seems to be because storeop does not check name/basepost is an aggregate before setting. Also seems to be no way PCT way around it. | 21:02 | |
| purl | Message for pmichaud stored. | ||
| bsdz | purl? | 21:03 | |
| purl | bsdz? | ||
| rg | bsdz: what would you expect y[1] to be after the second assignment? | 21:11 | |
| particle- | bsdz: parrot has an op for checking what type of interface a pmc provides | ||
| is it the 'provides' op? i forget whether that was renamed from 'does'. | 21:12 | ||
| bsdz | the best thing would be y_before = (, 5) and y_after = ((, 5, ), (,,3)) | 21:13 | |
| particle- | hopefully it was, and 'does' properly checks roles now instead of interfaces. | ||
| rg | and you couldn't set y[0][1] = 5 instead? | 21:14 | |
| bsdz | i imagine same problem would occur. | 21:15 | |
| yes same problem | 21:16 | ||
| particle: the op is "does" i think | |||
| "provides" is mentioned in .pmc files | 21:17 | ||
| rg | ok, so it does not auto-create an array. but even perl (5) refuses to coerce a scalar into an array | ||
| bsdz | rg: it would be useful if there was some way that PCT allowed you to specify what happened. like a morphbase parameter. | 21:18 | |
| in M-script (matlab/octave/freemat) it does exactly this. | 21:19 | ||
| particle- | bsdz: a custom pmc can implement this behavior | 21:20 | |
|
21:20
Whiteknight joined
|
|||
| particle- | much better than a compiler | 21:20 | |
| bsdz | particle: i'm not sure how. the pmc has no control on how/when PCT calls vivibase. | 21:21 | |
| particle- | no, the emitted vtable call on the pmc, get_int_keyed... | ||
| bsdz | ah i see. override the vtable method | ||
| particle- | is implemented in the custom pmc to recognize, oh, he wants a new dimension, let's create one and upgrade | 21:22 | |
| bsdz | i mean the vtable function | ||
| particle- | yep. | ||
| bsdz | i was hoping to stick to pure parrot types mind you | ||
| particle- | you'll need a RPA of RPAs | 21:25 | |
| ResizablePMCArray that is | |||
| bsdz | yes. i've got a routine to create an n-dim rpa already | ||
|
21:28
braceta left
|
|||
| Coke | OOC, in your example, do you still expect to have a [1] when you've set [1][2] ? | 21:29 | |
| bsdz | Coke: yes. (what does ooc mean?) | 21:30 | |
| particle- | out of curiousity | ||
| Coke | ooc? | 21:33 | |
| purl | rumour has it ooc is Out of curiosity. or out of commission or out of control or out of cocaine or out of context or Out of Character | ||
| bsdz | i dig purl! :) | ||
| Coke | hurm. so not only does your array have multiple dimensions it both 1D /and/ 2D /and/ ... ND ? huh. | ||
| I am more used to fixed-dimensional arrays, but then, I've been staring at CFMX for months. | 21:34 | ||
| bsdz | yep. manage to do the n dimensional stuff with a recursive tree algorithm. tbh that's all working | ||
| particle- | i'm still getting over that fortnight i spent in the eight-and-a-halfth dimension | 21:35 | |
| bsdz | sounds trippy! i think partial dimensions have something to do with fractals | ||
|
21:36
davidfetter joined
|
|||
| Coke | ayup. | 21:40 | |
| not that math has anything to do with reality, mind you. | 21:41 | ||
| bsdz | plato might disagree | ||
| particle- | i beat plato in a verbal debate last night. | 21:42 | |
| bsdz | it's not a fair challenge when the other party speaks ancient greek | 21:43 | |
| particle- | i can sing better than elvis, too. | ||
| cotto | and is dead | ||
| Coke | poo EE-ne ee too-ah-LEH-tah? | 21:45 | |
|
21:46
Limbic_Region joined
|
|||
| cotto | Are there any gotchas about branching/merging that aren't covered in docs/project/branching_guide.pod? | 21:49 | |
|
21:51
Whiteknight joined
21:56
contingencyplan joined
|
|||
| dalek | tracwiki: v6 | cotto++ | BranchDescriptions | 21:58 | |
| tracwiki: updating list of branches, descriptions still needed | |||
| tracwiki: trac.parrot.org/parrot/wiki/Branch...ction=diff | |||
| shorten | dalek's url is at xrl.us/beozhh | ||
| mj41 | Hi. Seems like TapTinder is a little bit more useful. tt.ro.vutbr.cz/buildstatus/pr-Parrot/rp-trunk | 22:10 | |
| rg is about to give up on the current jit. is there anyone around who could help me? | 22:11 | ||
| nopaste | "bsdz" at 78.105.78.157 pasted "pass by ref on derived type seems to drop data" (29 lines) at nopaste.snit.ch/16270 | ||
| bsdz | a little puzzle in my nopaste. seems that a derived parrot class loses data when you assign to it in a pass by ref. any one see me doing something wrong? | 22:12 | |
| particle- | bsdz: what is setref p, p supposed to do? | 22:15 | |
| bsdz | it sets p to p as past by reference | ||
| basically points one to the other. i use it in my pir subs to make a var pass by ref usually. | 22:16 | ||
| particle- | um. | 22:18 | |
| src/pmc/fixedpmcarray.pmc, line 386 | |||
| VTABLE void set_pmc(PMC *value) | |||
| if (SELF == value) return; | |||
| ...which is exactly what i would expect. it's a noop | 22:19 | ||
| particle- heads home & | 22:20 | ||
| bsdz | i can see that if p[0] == x and you try setting p[0] = x then should be no op. but in the example i pasted. seems to be different behavoir for base class to derived class? | ||
| good night particle | 22:21 | ||
| pmichaud | bsdz: PCT isn't intended to directly support every operation one might imagine. | 22:27 | |
| instead, it provides common primitives to make whatever operation might be wanted | |||
| so, in the case of attempting to convert a scalar to an aggregate, either the PMC itself should do it, or the thing generating the PAST should do the checks for an aggregate prior to attempting the assignment | 22:28 | ||
| It's also possible to create custom PAST node behaviors (derive from PAST::* and override the behavior) | |||
| one could also set an exception handler that traps the "get_pmc_keyed in class Integer" and decides how to handle it. | 22:29 | ||
| bsdz | okay thanks pmichaud. i think i'll try a custom pmc for now. it would be nice if PCT had a hook already. actually the EH idea sounds interesting. it would need to be sure it was getting thrown from the right place. would that be done in PCT? | 22:30 | |
| pmichaud | I'm not sure... we haven't explored that part of PCT yet | 22:31 | |
| at any rate, in general PCT (and parrot) doesn't like the "check if an operation is valid prior to attempting it" | |||
| usually we go with an exception-based model. | |||
| not only that, there's not a reliable way to determine if a given PMC is an aggregate or understands the set_pmc_keyed, short of actually doing it. | 22:32 | ||
| (which is why PCT leaves it up to the HLL compiler to decide when a check is needed and how to handle it) | |||
|
22:32
Xrblackwe joined
|
|||
| bsdz | thanks. that's very useful. | 22:32 | |
| pmichaud decides to wander around the airport a bit to find a power outlet. | 22:33 | ||
| bsdz | i seem to recall seeing exceptions being used for returning values. | ||
| pmichaud | yes. | ||
| that's pretty standard. | |||
| bsdz | standard as in dynamic languages i guess? i recall c/c++ shoving everything back on the stack | 22:34 | |
| Tene_ | pmichaud: did you see my issues with HLL line numbers recently? | 22:37 | |
| pmichaud | tene: no | ||
| Tene_ | pmichaud: I created a branch for it, but changing that message would break many tests. | ||
| pmichaud: I'd like confirmation that Parrot wants it changed before cleaning up many tests. | 22:38 | ||
| maybe I should implamant it at the PCT or Rakudo level for now? | |||
| argh spelling. | 22:39 | ||
| EKEYBOARDWAYTOOSMALL | |||
| pmichaud | perhaps have it change in Parrot in response to a switch? | ||
| so that Parrot by default uses its traditional error message, but if some global switch is set it uses the new error message? | 22:40 | ||
| we could potentially do it in PCT as well... but having Parrot do the basic reporting seems cleaner. | |||
| Tene_ | hmm | 22:41 | |
| pmichaud | bsdz: well, doing ".return" in a Parrot Sub doesn't result in an exception. The exceptions are currently used to handle the case where a HLL subroutine has nested blocks (i.e., nested Parrot Subs) | ||
| Tene_ | and PCT turns on that switch? | ||
|
22:41
bacek joined
|
|||
| pmichaud | Tene_: yes, or the HLL could. | 22:41 | |
| (it would probably make sense for PCT to do it by default) | |||
| bsdz: that said, I'd really like us to extend Parrot a bit so that we could easily invoke a Sub's return continuation (returning values) without having to do exceptions. | 22:42 | ||
| Tene | any idea where to store that flag? | ||
| bsdz | ah yes. that makes perfect sense now. quite good too since we need to implement nested functions at some point. | ||
| pmichaud | Tene: no, it was just a thought to avoid having to develop additional PCT code to do it. | ||
| Tene | 'kay | 22:43 | |
| pmichaud | Tene: do lots of tests check for the specific text of the error message? | ||
| Tene | Yes. | 22:44 | |
| pmichaud | ick. | ||
| oh well. | |||
| another possibility might be to change _only_ if annotations are detected. | |||
| i.e., if we have an annotation, then use the new report, otherwise fall back to the old style. | |||
| Tene | That was behaving oddly... I was getting a 0 in some cases instead of pmcnull, it looked like. | 22:45 | |
| bsdz | pmichaud,tene: on a different topic. i'm thinking of filing a trac on setref and derived aggregate classes. i posted a nopaste a little earlier. can either of you see if there's something i;ve done fundamentally wrong before i file it? | ||
| Tene | Was almost sleephacking at that point, though. | ||
| pmichaud | bsdz: I've never seen definitive documentation for what setref is supposed to do. | ||
| Tene | need to re-check. | ||
| pmichaud | I think setref is PMC specific. | ||
| (i.e., it ends up calling the set_pointer vtable) | 22:46 | ||
| bsdz | yes. usually works to pass by ref. seems to break if i use a derived aggregate pmc type. i better file a trac. | ||
| pmichaud | there are a number of problems with derived pmc types in Parrot still, I think. | ||
| bsdz | okay thanks again. | 22:47 | |
| Tene | pmichaud: I'll try keeping it the same if no annotations are found. Think you could get filename and HLL annotaions in PCT soon? | 22:50 | |
| pmichaud | filename, yes. | ||
| hll, yes. Not exactly sure what that should be -- I guess a special PAST::Node for that | |||
| there's always :inline(...) :-P | 22:51 | ||
| PAST::Op.new(:inline('.annotate "foo", "bar"')) | |||
| Tene | :pirop('annotate') | 22:52 | |
| pmichaud | I try to avoid too many special pirops | ||
| especially since annotate isn't really an op. | |||
| Tene | ah | ||
| right | |||
| pmichaud | it kind of feels like a PAST::Val or PAST::Var somehow | 22:53 | |
| since it has name+value attributes | |||
| I'll think about it on the plane. | |||
| Tene | I'm not sure we need HLL | 22:54 | |
| pmichaud | if there's an easy way to insert annotation nodes into the PAST, then having an HLL compiler insert HLL and filename information is pretty straightforward. | ||
| Tene | pmichaud: should fatal exceptions print a full stack trace, and resumed warnings just source? That's my current plan. | 22:55 | |
| pmichaud | I wonder if fatals should print the full trace. | ||
| right now the major complaint I hear is that the traces are too long. | 22:56 | ||
| Tene | ah | ||
| pmichaud | TimToady says that the error message should contain a url to the trace :-) | ||
| Tene | file:// | ||
| is doable | |||
| pmichaud | if the traces can be made shorter (and aren't obscure) then I think it's okay to include them. | 22:57 | |
| Tene | one big issue is printing a line for evessue is printing a line for every nested block. | 22:58 | |
| pmichaud | perhaps we should annotate whether blocks get an entry in the stack trace | 22:59 | |
| Tene | we could add a 'sub' annotation. | 23:00 | |
| pmichaud | yes, something like that. | ||
| purl | something like that. is, like, that true | ||
| Tene | this reminds me of the 'inline' attribute of contexts mentioned in the P6 specs. | 23:01 | |
| pmichaud | yes, I suspect tehre are some similarities. | ||
| okay, I think I need to move closer to my gate -- they're starting to call people to board. | 23:02 | ||
| I'll catch you all later/tomorrow/whenever. | |||
| Tene | seeya | 23:03 | |
|
23:07
tetragon joined
|
|||
| nopaste | "coke" at 72.228.52.192 pasted "why is this a c90 error?" (11 lines) at nopaste.snit.ch/16271 | 23:09 | |
| chromatic | Coke, no trailing semicolon? | 23:11 | |
| Coke_afk | I thought UNUSED didn't require one. checking... | ||
| Coke | nope. semicolon doesn't help. | 23:12 | |
| rg | can't hurt and looks less wrong | ||
| Coke | rg; I'm following the style elsewhere in the codebase. | ||
| rg | ok, i guess it wouldn't hurt elsewhere either ;) | ||
| so it complains about the UNUSED line? | 23:13 | ||
| Coke | it's complaining about the following line. | ||
| rg | is the following line a declaration? | 23:14 | |
| nopaste | "coke" at 72.228.52.192 pasted "patch that result in error" (14 lines) at nopaste.snit.ch/16272 | ||
| rg | ok, so it's correct | 23:15 | |
| you need to put the UNUSED last (behind the declarations) | |||
| it expands to 'if (0) (void)(a);' i.e. code. | |||
| Coke | bah. you're right. | ||
| rg++ | |||
| rg | (and you're right it doesn't need the semicolon, but imho it still looks better with one) | 23:16 | |
| bsdz | not too keen on languages that insist declarations are always at the top | ||
| Coke | welcome to C. =-) | ||
| bsdz | tell me about it | ||
| purl | it is, like, a hack | ||
| rg is giving up the fight with jit. a workaround is all i will offer (if it's going to pass all tests) | 23:17 | ||
| bsdz | is there the equivalent of SUPER in pir? | ||
| Coke prepares to commit a bunch of non-functional changes. :| | 23:21 | ||
|
23:27
TiMBuS joined
|
|||
| bsdz | good night all | 23:29 | |
| dalek | rrot: r38107 | coke++ | trunk (25 files): [cage] reduce -unused-parameter warnings (*) |
23:44 | |
|
23:56
bacek joined
23:58
megazooch joined
|
|||