|
www.parrot.org | Parrot 1.6.0 "half-pie" released: The JIT is dead! | Testing priorities: Exception and MultiSub Set by moderator on 20 September 2009. |
|||
|
00:00
mokurai joined
00:01
mokurai left
00:05
mokurai joined
|
|||
| japhb | Tene, it's a good start. I'm going to tweak a couple things (like moving the top of action_fetch() out to an init-time function), but I think the only real thing to think about is where the working directory should be. | 00:05 | |
|
00:05
quek joined
|
|||
| japhb | I'll see if proto has a decent precedent here. | 00:06 | |
| Tene | japhb: IMO, we need a 'mktemp' function. | 00:14 | |
| japhb: and then fetch to that directory | 00:15 | ||
| japhb | Tene, but if configure/build/install fails, people want to examine the wreckage. | ||
| Tene | japhb: Sure, which is why you only rm the directory if all steps succeed properly. | ||
| You only move on to the next step if the last step succeeded, and 'cleanup' is the last step | 00:16 | ||
|
00:16
ash_ joined
|
|||
| japhb | And it could be a significant savings to have a known directory where fetched subdirs go, so that we can later just update and rebuild, rather than doing complete fetch again. | 00:16 | |
| But that may be a later change. | |||
| Tene | Sure. | ||
| japhb: you want a pure parrot http-fetching library? | 00:17 | ||
| japhb: or libcurl wrapper? | |||
| japhb: or config-detected downloader, like wget/curl? | |||
| japhb | I'd prefer pure Parrot. Doesn't have to be fancy yet. | ||
| Tene | Or... what were you thinking? | 00:18 | |
| kk, I'll do something basic this week. I was going to look at Socket refactors anyway. | |||
| That was my inclination too. | |||
| japhb | we *can* do a config-detected downloader, if it's too painful, I suppose. | ||
| Ah good. | |||
| And that puts some real testing on the socket API. | |||
| Tene | I don't think that windows even ships with anything like wget anyway... so we'd need a native parrot solution anyway | 00:19 | |
| AFK dinner. | 00:20 | ||
| japhb | k | ||
| We need some way to stop that. | 00:21 | ||
| Sorry, wrong window. | 00:22 | ||
| Trying to fetch Close, it pulls a pile of stuff and then Subversion wants authentication info for 'Authentication realm: <close.googlecode.com:443> Google Code Subversion Repository' and won't seem to proceed without it. We need some way to stop that. | |||
| (That was the message I was sending to Austin, but I just realized Tene probably cares too.) | 00:23 | ||
| Tene: incoming commits | 00:24 | ||
|
00:29
rhr joined
|
|||
| Tene | Hmm. Don't know enough about svn. :( | 00:33 | |
|
00:33
yanger joined
00:42
yanger left
00:48
Austin joined
00:52
particle joined
|
|||
| allison | anyone around to answer a runcore question? | 00:58 | |
| japhb | use.perl.org/~geoffrey/journal/39682 # Parrot Plumage "Day" 6 | 01:05 | |
| And now, maybe I can start working on actual new code. | |||
| Or maybe eat dinner. | |||
| Austin | japhb: I've changed the externals link on close to use http, which is the read-only approach to the repo. That should reflect what most people do. | 01:14 | |
| japhb | Austin, cool, let me try a fetch again | 01:18 | |
| Austin, seemed to work like a charm. | 01:19 | ||
| Austin | In fact, japhb, my inclination would be to specify no-externals as part of the fetch, since the link in this case is for documentation. | ||
| Are we still using the "I'll give you a command line to use" approach? | 01:20 | ||
| dalek | ose: r167 | Austin++ | trunk: Changed externals on wiki to read-only |
||
| japhb | Austin, at the moment no -- Tene's commit to add fetch is building the command directly from the repository metadata. | 01:21 | |
| s/metadata/section of the metadata/ | |||
| Austin | Okay. | ||
| So I need a setting to tell him to ignore the externals. | 01:22 | ||
| japhb | Whirlpool development: the best kind of suck. :-) | ||
| Yep, was just thinking that. | |||
| Austin | purl, msg tene Plumage needs a mechanism to tell the SVN fetcher to --ignore-externals | ||
| purl | Message for tene stored. | ||
| japhb | You know, I think the refactor that is needed is to change the instructions from having a single 'type' flag to having per-stage info. | 01:24 | |
| Hmmm | |||
| Tene | japhb: agreed. | 01:39 | |
| japhb: require at least a type for each stage, and optionally additional type-specific metadata | 01:40 | ||
| like, say { type : svn, extra-args : --ignore-externals } | 01:41 | ||
| and, as a last-resort fallback, { type : custom, command : "$SVN co --ignore-externals $REPO $DEST" } | |||
| oslt | |||
| japhb | (here for just a sec, cooking dinner): Tene, yeah, sounds like a plan. About time to merge my thoughts about the metadata spec back to the wiki anyway. | 01:44 | |
| Oh, for metadata spec revision, I'm thinking just an incrementing number. So the next rev will be revision 1, then 2, and so on. | |||
| Any objections, let me know. | 01:45 | ||
| Tene | japhb: sounds fine to me... I don't think we're at a stage to worry about trying to support old versions of the spec yet, though. ;) | ||
| japhb: any specific requests for tonight? I'm going offline to hack in not too long. | 01:46 | ||
| If nothing specific, I think I'll work on Socket. | |||
| cconstantine | Tene: Hi :) I think I figured out a possible root-cause of my tailcall problems; the 'let' special form from stene is broken | 01:52 | |
| Tene | broken how? | ||
| cconstantine | either broken or not acting as expected | 01:53 | |
| Tene | explain? | 01:54 | |
| cconstantine | given nopaste.snit.ch/18076 | ||
| the call to func1 in func can't find func1 | |||
| (I changed lambda to fn) | 01:55 | ||
| Tene | I'm not too surprised. I don't remember considering that case. | ||
| Good catch. | |||
| cconstantine | it appears to work for functions because it's somehow able to find it in the global scope | ||
| ie, the code posted works because the '$P0 = 'func1'($P1)' works, even though it should be pulling func1 from the lexical scope | 01:56 | ||
| Austin | Seems like 'let' isn't adding the function to its block symtable | 01:58 | |
| Or setting a lexical, if it happens at runtime. | 01:59 | ||
| cconstantine | I think? | 02:00 | |
| I added a bunch of sentinal 'say's in actions.pm, and it's detecting if the vars inside the val form before registering any vars | 02:02 | ||
| japhb | Tene: No special requests. Socket work and HTTP fetch are excellent next tasks. | 02:03 | |
| Tene | okay, AFK | ||
| japhb | ditto | ||
| Tene | NO I WAS AFK FIRST | ||
| ... oops. ;) | |||
| Austin | So my bank's online banking just rolled out (to me) their new! improved! interface. And about 40 seconds later, I have found a Severity 1 bug. | 02:15 | |
| No, you don't look like complete buffoons. | |||
|
02:16
rhr joined
02:21
integral joined
02:22
TiMBuS joined,
JimmyZ joined
|
|||
| cconstantine | Austin: which bank is that again? ;) | 02:35 | |
| Austin | "TD bank North" | ||
| All your statements will be June 02. | 02:36 | ||
| Good luck on those taxes. | |||
| cconstantine | hehe | 02:38 | |
| So, you found the problem in my 'let' any idea how to get it to add the lexical var before evaluating the val portion? | 02:39 | ||
| Austin | Where's the code? | 02:40 | |
| purl | i think the code is already out | ||
| Tene | purl: msg WhiteKnight re "Add an improved file-like API to the Socket PMC" can you explicitly define what that API is? | 02:41 | |
| purl | Message for whiteknight stored. | ||
| cconstantine | github.com/cconstantine/Reason | ||
| Austin | Is this scheme? | ||
| Or lisp, or whatever? | |||
| cconstantine | kinda | ||
| the lisp I want | |||
|
02:42
janus joined
|
|||
| cconstantine | will be mostly inspired by clojure | 02:42 | |
| Austin | Okay. You know that compiling is a bad idea, right? | ||
| cconstantine | sure? | ||
| purl | But are you sure you're sure? | ||
|
02:42
rhr joined
|
|||
| cconstantine | I started with Tene's stene | 02:42 | |
| Tene | Austin: What do you mean by that? I don't think I know what you're talking about. | ||
| Austin | Ok, so you create an immediate block, add all the symbols to it, and then process statements. | 02:45 | |
| You'll have to R-your-own-FM on this one, but Scheme R5 does not define the order of eval for let args. Let*, on the other hand, is defined left to right. | 02:47 | ||
| So let may be fine, but let* might need to insert each var=val pair as it is found, rather than after they are all found. | 02:48 | ||
| jrtayloriv has a lightbulb come on over his head, and begins to see why Austin told him to make the TOP block immediate ... | 02:49 | ||
| Tene | cconstantine: process each let* item as it's seen, instead of after the fact. | 02:50 | |
| cconstantine | I'm not sure I know how to do that | 02:52 | |
|
02:53
rg joined
|
|||
| cconstantine | does this line "my $val := $<val>.shift.ast;" cause the val evaluate itself? | 02:54 | |
| Tene | .ast | ||
| Austin | Instead of doing {*} #= start, add a call to {*} #= item after each item | ||
| And of course, catch $key eq 'item' in the action | 02:55 | ||
| cconstantine | item? | ||
| purl | hmmm... item is in an =over, so the indent accumulates. | ||
| cconstantine | ah, val-var pair | 02:56 | |
| Austin | Tene: the reason I said that compiling was a bad idea was that the compilation symbol table is unavailable at runtime. Writing lisp-alikes pretty much means doing all the work in the execution environment. | 02:57 | |
|
03:00
kyle_l5l_ joined
|
|||
| cconstantine | so, move the #= begin to after the 'let', add a #= item after ')'? | 03:00 | |
| Tene | cconstantine: you probably want to keep the #= begin | 03:01 | |
| cconstantine: then do some setup in #= begin, handle each item in #= item, then finish up at #= end | |||
| cconstantine | right, move not remove | 03:02 | |
| Austin | cconstantiine: Yes. Use begin to create the block, use item to add individual items to the block, | ||
| cconstantine | will this allow a '(let ( (fun (fn (x) (fun 1)))))' ? | ||
| Tene | cconstantine: yes. | ||
| cconstantine | awesome | 03:03 | |
| Austin | Doctor, will I be able to play the violin after the operation | ||
| Tene | cconstantine: the test you probably want to use is: (let ((a 1)(b (+ a 5))) (say b)) | 03:05 | |
| approximately | |||
| cconstantine | my thing was so that I could do recursion in an anonymous function | 03:06 | |
| without resorting to a special form | |||
| Tene | Yeah, I know. | ||
| cconstantine | that's a good test too | 03:07 | |
| dalek | ose: r168 | Austin++ | trunk/ (34 files): checkpoint: Renamed close::Compiler -> Slam |
03:08 | |
| cconstantine | ok, what is the '@?BLOCKS' in this function? | 03:18 | |
| Austin | global stack of PAST blocks | 03:19 | |
| cconstantine | unshift is a push? | ||
| jrtayloriv | yes | ||
| Austin | In this case, yes. | ||
| cconstantine | shift is a pop? | 03:20 | |
| Tene | unshift is a push onto the *front* | ||
| Austin | I guarantees that the top of the stack is always [0] | ||
| Tene | shift is a pop from the front | ||
| Austin | *I = it | ||
| cconstantine | ok | ||
| so if I don't want to add or remove blocks I better shift and unshift the same number of times | |||
| Tene | Yes. | 03:21 | |
|
03:31
yanger joined
|
|||
| yanger | ping whitenight | 03:31 | |
| purl | I can't find whitenight in the DNS. | ||
| cconstantine | I'm popping from an empty array... is there anyway find out where? all I get is src/gen_grammar.pir:1888 in the trace | 03:32 | |
| Austin | Go look in gen_grammar.pir. | 03:35 | |
| Or read the backtrace | |||
| cconstantine | neither are helpful | 03:38 | |
| at least not to me | |||
| Austin | NoPaste the backtrace | 03:42 | |
|
03:42
rhr joined
|
|||
| nopaste | Someone at 71.98.77.93 pasted "backtrace" (11 lines) at nopaste.snit.ch/18078 | 03:52 | |
| cconstantine | nopaste.snit.ch/18078 | ||
| Austin | First thing to know about a backtrace is that there are two sets of methods: Grammar and Grammar;Actions. If it's in the Grammar, that's from your .pg file. | 03:53 | |
| (Those are rare, but they happen.) | 03:54 | ||
| If it's in Grammar;Actions, then it's from your .nqp file. | |||
| cconstantine | right | ||
| Austin | Unless you put your actions in the same class as your grammar, which would be bad. | 03:55 | |
| :) | |||
| cconstantine | obviously | ||
| nopaste | "tene" at 97.113.17.205 pasted "hackish wget.pir for japhb" (103 lines) at nopaste.snit.ch/18079 | ||
| Austin | (It may not be obvious. But a Grammar is a class, and the rules are method names. And the actions are method names, and they are the same names as the rules.) | ||
| japhb | Tene: looking ... | 03:56 | |
| Tene | japhb: I threw together a proof-of-concept wget.pir. It seems to work on every url I tried it on. | ||
| japhb | Tene, excellent | ||
| reading it now | |||
| Tene | There are (obviously) some rough edges... but I think I can clean it up into a decent library. | ||
| Austin | CConstantine: Is there an updated grammar online? Or can you nopaste that part of it with let? | ||
| japhb | What is the ibm link in the DESCRIPTION there for? | ||
| Tene | japhb: I took it from examples/io/http.pir | 03:57 | |
| cconstantine | Austin: my work-in-progress is in github | ||
| Tene | japhb: Updating the header now | 03:58 | |
| japhb | Tene, nod | ||
| cconstantine | Austin: I kinda knew that. the gramar is compiled to code, and te actions get called based on the gramar targets | ||
| nopaste | "tene" at 97.113.17.205 pasted "Slightly updated wget.pir" (99 lines) at nopaste.snit.ch/18080 | 03:59 | |
| Austin | Are you sure this is the same pg that generated the code? | ||
| cconstantine | yup | ||
| Tene | japhb: I suddenly realize that I could probably have written this in nqp... :P | ||
| japhb | Tene, yeah, I was thinking the same thing. | 04:00 | |
| Austin | I'm wondering why the grammar identifies itself as "Reason::Grammar" but the backtrace says reason;Reason;Grammar | ||
| japhb | Probably a tad less painful. | ||
| May need another builtin or two. | |||
| cconstantine | is it bad that I think the pir is less scary then nqp? | ||
| Austin | no. | ||
| But you'll change your mind. | |||
| cconstantine | I live in asm at work | ||
| Austin | You have my sympathy. | 04:01 | |
| japhb | I'm thinking an 'rx()' or 'regex()' builtin that just compiles a string representing a regex into the regex sub, so you can invoke it on the URI to get matches. | ||
| Austin | First thing to try is make clean; make. | ||
| I really don't understand that namespace thing. | |||
| japhb | Come to think of it, has someone written a URI language yet? | ||
| Tene | japhb: although, there's no infrastructure in Parrot to use NQP libraries yet... | ||
| So, wouldn't be as useful. | 04:02 | ||
| japhb | Tene: What do you mean by that? | ||
| (I mean, I think there's nothing in particular that would stop you from doing it. It just may require a little glue PIR.) | 04:03 | ||
| nopaste | "cconstantine" at 71.98.77.93 pasted "sample code" (3 lines) at nopaste.snit.ch/18081 | ||
| cconstantine | Austin: that's now causing a 'invoke() not implemented in class 'String'' | ||
| Austin | That's better. | ||
| Backtrace? | |||
| purl | Backtrace is not sufficient? | ||
| nopaste | "cconstantine" at 71.98.77.93 pasted "backtrace" (8 lines) at nopaste.snit.ch/18082 | 04:04 | |
| japhb | Tene, you have clearly spent too much time writing PASM ... unless those bits were cribbed from the old example, I suppose. | 04:05 | |
| Austin | This one isn't even in your grammar. You win. | ||
| Tene | japhb: which bits? | ||
| purl | which bits are they? | ||
| Austin | Looks like you're running code you've produced from the script, no? | 04:06 | |
| cconstantine cheers! | |||
| japhb | Tene, the contents of the MORE loop, for example. Using 'ne' and 'eq' as ops, instead of the sugared if statements. | ||
| Tene | japhb: I mean, if I want to write a general-purpose HTTP library, and I write it as an nqp file, there's no infrastructure to put it in the parrot repo so that people can use it. | ||
| japhb: No, I wrote that. I can never remember the sugared syntax. | |||
| Austin | Try running your compiler with --target=pir | ||
| Tene | "does it go before, or after, or in between, or ..." | ||
| I can't go, like, use HTTP:from<nqp>; | 04:07 | ||
| japhb | 'if A OP B goto LABEL' | ||
| nopaste | "cconstantine" at 71.98.77.93 pasted "make && ./reason --target=pir in-2.rl" (47 lines) at nopaste.snit.ch/18083 | ||
| Tene | japhb: Sure, and I could just look it up... I just can never remember. | ||
| japhb | I guess my years writing early BASIC variants got me completely used to that syntax. ;-) | 04:08 | |
| Austin | So you're calling the "+" function. Where is it? | ||
| cconstantine | one of my builtins | ||
| Austin | is it called "+", or "inline:+" | 04:09 | |
| sorry, "infix:+" | |||
| cconstantine | I can call it normally like (+ 1 1) | ||
| japhb | Tene, it took a minute, but I think I see what you meant about using NQP libraries. It's almost there, but not quite. | 04:10 | |
| Austin | So why is it not a tailcall? | ||
| cconstantine | it could be | 04:11 | |
| I invented (^func ...) as a tailcall | |||
| explicit tailcal | |||
| Austin | Yeah, and the example source you gave used ^+ | 04:12 | |
| So why does the pir not have a tailcall? | |||
| japhb | Tene, what's your next step with the http GET code, out of curiosity? | 04:13 | |
| cconstantine | Austin: I may have changed the source from what I posted | ||
| Austin | I see. | ||
| nopaste | "cconstantine" at 71.98.77.93 pasted "make && ./reason --target=pir in-2.rl" (51 lines) at nopaste.snit.ch/18084 | ||
| Tene | japhb: come up with a silly name and make a library for it; add it to runtime/library | ||
| japhb | Tene, :-) | ||
| Austin | Same error? | 04:14 | |
| cconstantine | yeah | ||
| Tene | MECHA-HTTPDownloader | 04:15 | |
| Austin | Does it print "Finding: +" ? | ||
| Tene | HTTPDownloaderZILLA | ||
| cconstantine | and it's definately the '+'.... odd | ||
| Austin | ^^ | 04:16 | |
| nopaste | "cconstantine" at 71.98.77.93 pasted "new infile (works)" (3 lines) at nopaste.snit.ch/18085 | ||
| Austin | Oh. | 04:19 | |
| There's your problem. | |||
| actions.pm:242 | |||
| You're converting from a VAR to a String, and pushing it into the tailcall | 04:20 | ||
| Probably because the Past CALL op lets you do that with function names. | 04:21 | ||
| $op.name("+"), etc. | |||
| cconstantine | right | ||
| so just push the $cmd? | |||
| Austin | So, does it work if you don't do ^+, but just do + ? | 04:22 | |
| cconstantine | with the $cmd = $cmd.name() it doesn't work either time | 04:23 | |
| wait | |||
| scratch that | |||
| Austin | Yeah, I see that in 'simple' now too. | ||
| cconstantine | it works for + but not for ^+ | 04:24 | |
| it came from 'simple' | |||
| mikehh | all tests PASS (pre/post-config, smoke (#28221), fulltest) at r41540 - Ubuntu 9.04 amd64 | ||
| Austin | Right. | ||
| Because simple generates result = "+"(x, 1) | |||
| where tailcall generates $P0 = new String("+") ; $P0(x, 1) | 04:25 | ||
| or whatever | |||
| So the PIR compiler is resolving the "+" for you | |||
| cconstantine | yeah | ||
| Austin | So if you eliminate that conditional block at :242, and just push the function name into the node, what happens? | 04:26 | |
| cconstantine | push $cmd.name() ? | ||
| Austin | Eliminate that. | 04:27 | |
| In tailcall, just always do push($cmd) | |||
| cconstantine | it appears to work :) | 04:28 | |
| Austin | w00t | 04:31 | |
| Austin is da man. | |||
| Go me. | |||
| cconstantine w00ts! | |||
| I could have sworn I tried that | 04:32 | ||
| Austin | You tried it with nobody looking. | ||
| cconstantine | obviously | ||
| I'm reminded of the first story here www.ccil.org/jargon/jargon_47.html#SEC54 | 04:33 | ||
| Austin | jrtayloriv ping | 04:35 | |
| jrtayloriv | pong | ||
| Austin | You doing C or Phemer tonight? | ||
| jrtayloriv | Trying to do phemer. I got it to eval integer constants properly at least. Pretty pitiful state though. Still blocking on the symbol deal ... I must be missing something really obvious :| | 04:36 | |
| Austin | It'll come to you. Can I give you a homework assignment on symbols? | 04:37 | |
| nopaste | "cconstantine" at 71.98.77.93 pasted "recursive lambda" (6 lines) at nopaste.snit.ch/18086 | ||
| cconstantine | so, an anonymous function referencing it'self from the let it's defined in isn't exactly working Is that even possible? | ||
| jrtayloriv | Austin, Please. | ||
| Austin | cconstantine: Yes, it's possible. But you have to do more magic. | 04:38 | |
| cconstantine | I create the var before I cal .ast on the val.. is that not enough? | ||
| Austin | jrtayloriv: In the tcl code, and possibly other languages, coke changes from using LexPad to DynLexpads. I think it's called HLL type mapping. I don't know much about it beyond that it exists. But you need it. | 04:39 | |
| cconstantine: You keep using the word 'package' in your code. You need to start using the word 'lexical' instead. | |||
| jrtayloriv: You need it because you need to be able to insert lexicals into a callers lexpad. | 04:40 | ||
| cconstantine | if I claim all symbols are lexical will it fall back on package if it isn't in the lexical stack? | ||
| jrtayloriv | Austin, Where would I need to do that? | 04:41 | |
| Austin | cconstantine: If you set the symbol_defaults() to have :scope('package') | ||
| cconstantine: But you would be better off paying close attention to what I'm telling JT4 | 04:42 | ||
| Tene | cconstantine: you just need to put the function in a block's symbol table right as it's defined. | ||
| Austin | Jesse, I have no idea where it's done, or how it's done. I do know that Coke is doing it, because he was talking about it the other night. | ||
| Tene | Nothing more than that. | ||
| cconstantine | Tene: could this be an 'immediate' vs. 'declaration' thing? | 04:43 | |
| Tene | cconstantine: No. | ||
| jrtayloriv | Austin, I am starting to look through the partcl code, as we speak. I was just wondering where I would need to insert a lexical into a *caller*'s pad? | ||
| Austin | define. | 04:44 | |
| From the conversation last night, define is basically tcl's upvar with level 1. | |||
| jrtayloriv | Oh, because define function will include something it top level environment block (which it is getting called from) pad, correct? | 04:45 | |
| Austin | right | ||
| cconstantine | Tene: I thought github.com/cconstantine/Reason/blob...ons.pm#L93 did that for me | ||
| jrtayloriv | Austin, Thank you, thank you, and thank you. I'll study partcl tonight and tomorrow (at least) and see what I can glean from the upvar/lexpad code. Whatever I'm trying now is obviously a dead end ... | 04:46 | |
| Austin | I looked at the upvar code. Stay away from that. | ||
| He's doing it differently, because he tracks the call stack separately from Parrot. | 04:47 | ||
| jrtayloriv | OK -- I still want to look at it, so I can understand what you mean by "is basically upvar with level 1". | ||
| Tene | cconstantine: yes, but you're doing that *AFTER* the function is already parsed. | ||
| jrtayloriv | But I'll make sure to treat it like something I should only poke at with a long stick :) | ||
| Tene | cconstantine: github.com/cconstantine/Reason/blob...mar.pg#L66 is the line where the function is being parsed, and the line *after* it is currently where it would get put in the symbol table. | ||
| Austin | That's tcl syntax. Find a tcl book. But basically, uplevel and upvar perform actions in the lexical scope of their n-levels removed caller. | ||
| cconstantine | Tene: so I need another {*} after <var=symbol> ? | 04:48 | |
| jrtayloriv | Austin, OK, so you would recommend then, looking more at how he deals with lexpad/dynlexpad? | 04:49 | |
| Austin | So Tcl's [upvar 1 foo] defines or fetches (I can't recall which) 'foo' from the 1-time removed caller's scope. | ||
| Tene | cconstantine: you need to register the symbol in the symbol table before you try to refer to do it. That's your goal. | ||
| Austin | Yes. See if you can figure out how to do HLL mapping to get DynLexPads used instead of LexPads. | ||
| Tene | cconstantine: So, yes, that's one way to do it. | ||
| cconstantine | hehe, you say that like theres more than one way ;) | 04:50 | |
| I'll give that a shot | |||
| Tene | Sure there's more than one way. | 04:51 | |
| Just keep in mind the order everything happens in, and make sure that it's *registered* before it's *used*, and you're fine. | |||
| cconstantine | does the $block.symbol(...) register it? | 04:53 | |
| Tene | Yes. | 04:54 | |
| cconstantine | awesome | ||
| mikehh | rakudo (0331d60) builds on parrot r41540 - make test / make spectest_smolder (up to 28454 -> #28223) PASS - Ubuntu 9.04 amd64 | 04:55 | |
| partcl r745 builds on parrot r41540 - make test PASS (smolder #28224) - ubuntu 9.04 amd64 | 04:56 | ||
| cconstantine | you guys are so much help | 04:58 | |
| how would I go about keeping $var around for val to bind to it? | 05:00 | ||
| Tene | cconstantine: just pull it out of the AST again. | ||
| cconstantine | doing $<var>.shift.ast causes a shift off an empty array | 05:01 | |
| Austin | Yeah, you're destroying that as you read it. | ||
| Try using $<var>[0] in the first rule, then shift it off in the second. | 05:02 | ||
| cconstantine | *gasp* | ||
| I think it might work! :) | |||
| dalek | TT #1070 created by mikehh++: building parrot with the make -j option fails after r41514 | 05:12 | |
| cconstantine | each 'block' adds to the stack doesn't it | 05:15 | |
| Tene | cconstantine: what? | 05:23 | |
| cconstantine | I'm getting stack overflows at around 1k tail calls | 05:24 | |
| nopaste | "cconstantine" at 71.98.77.93 pasted "attempt at 'last'" (11 lines) at nopaste.snit.ch/18087 | ||
| Tene | cconstantine: write a small PIR program that reproduces the problem. | ||
| nopaste | "tene" at 12.190.38.210 pasted "tailcalls seem to work fine for me..." (10 lines) at nopaste.snit.ch/18088 | 05:25 | |
| Tene | cconstantine: I was able to run that program up past 100k without problem. | 05:26 | |
| over 1M calls | |||
| cconstantine | right, I doubt tailcall is broken... and I'm allocating stack where I think I'm not | ||
| Tene | cconstantine: do you have a small scheme program that reproduces the problem? | 05:27 | |
| and can you give me a link to your repo again? | |||
| cconstantine | github.com/cconstantine/Reason | ||
| Tene | I'll look into it. I've got a bit of time before I need to sleep. | ||
| cconstantine | ok, I've mostly given up for the night | 05:28 | |
| Tene | cconstantine: how can I reproduce the overflow? | ||
| cconstantine | can you compile 'reason'? | ||
| Tene | yes | 05:29 | |
| cconstantine | I do a 'make && ./reason in.rl' | 05:31 | |
| with the stuff in pastebin as the contents of 'in.rl' | |||
| Tene | I don't see the paste you're talking about. | ||
| cconstantine | nopaste.snit.ch/18087 | ||
| nopaste | "tene" at 12.190.38.210 pasted "This runs over 1M for me without problem" (3 lines) at nopaste.snit.ch/18089 | 05:32 | |
| Tene | I will look at your problem now. | ||
| cconstantine | so it oes | 05:34 | |
| so my 'last' is busted | |||
| or 'seq' | |||
| Tene | Yes, every block will add to the stack. | ||
| japhb | Tene: Starting work on changing 'instructions' section of metadata -- does it look like I'm on the right track? trac.parrot.org/parrot/wiki/Module...taProposal | ||
| dalek | tracwiki: v8 | japhb++ | ModuleEcosystem | 05:35 | |
| tracwiki: WIP: Updating metadata instructions section to new design | |||
| tracwiki: trac.parrot.org/parrot/wiki/Module...ction=diff | |||
| cconstantine | Tene: ah, then let creates a block; therefor it adds to the stack on each recurssion | ||
| Tene | cconstantine: yes. | ||
| cconstantine | ok, I'll work on figuring out how to fix that later. | 05:36 | |
|
05:36
mokurai joined
|
|||
| cconstantine | thanks for all the help :) | 05:36 | |
| Tene | cconstantine: you'll have to find a way to make PCT emit a tailcall for (let), or make the last statement in your blocks something that you can explicitly tailcall. | 05:37 | |
| cconstantine: I suspect it might be worthwhile to investigate adding this as an optimization to PCT. | |||
| cconstantine: I think the place to look is going to be compilers/pct/src/POST/Compiler.pir | 05:38 | ||
| cconstantine | oh wow | ||
| Tene | hm? | ||
| cconstantine | that's in parrot | ||
| Tene | Yes | ||
| cconstantine | 's deep dark heart | ||
| Tene | japhb: I think there might need to be an optional stage after fetch... unpack. | 05:39 | |
| japhb | Tene: Oooh, good thinking. | ||
| Tene | japhb: if the fetch stage has a link to a tarball... the unpack stage should be 'tar' | ||
| cconstantine | ok, I"ll sleep on it. if you feel like working on it don't let me stop you :) | ||
| cconstantine is an eastern tmz denizen | 05:40 | ||
| Tene | cconstantine: I just might. :) | ||
| cconstantine | :) | ||
| Tene | Okay, I'm going to sleep now. | ||
| cconstantine | 'night | ||
| Tene | japhb: feel free to leave me a specific task or goal when you finish for the night. | ||
| japhb | Tene: | 05:41 | |
| Did you already get HTTP wired into plumage? | |||
| Tene | japhb: No. | ||
| I'll do that, then. | |||
| japhb | There's your goal. ;-) | ||
| Tene | 'night | ||
| japhb | Thanks for all your help,. | ||
| good night | |||
| Tene | np | ||
| dukeleto | 'ello | 05:52 | |
| jrtayloriv | hoody hoo | 05:57 | |
| mikehh | hi | ||
| dalek | tracwiki: v9 | japhb++ | ModuleEcosystem | 06:03 | |
| tracwiki: WIP: Updating metadata instructions section to new design, part 2 | |||
| tracwiki: trac.parrot.org/parrot/wiki/Module...ction=diff | |||
| tracwiki: v10 | japhb++ | ModuleEcosystem | 06:13 | ||
| tracwiki: WIP: Updating metadata instructions section to new design, part 3 | |||
| tracwiki: trac.parrot.org/parrot/wiki/Module...ction=diff | |||
|
06:15
uniejo joined
|
|||
| Tene | japhb: still up? | 06:16 | |
| purl | Your face, Tene. That's what. | ||
| japhb | Tene, yes indeed | ||
| See most recent version of metadata spec. :-) | 06:17 | ||
| Tene | japhb: I'm going over all of the options on were to put the HTTP module, and the others that we need, and I'm trying to remember the issues... | ||
| We could: | |||
| 1) Keep the http downloader modules in the plumage repo | |||
| 2) add it to parrot as runtime/library/HTTP.pir | 06:18 | ||
| 3) add it to parrot as runtime/library/PlumageUtilitiesNamespaceBlah/HTTP.pir | |||
| Others? | |||
| purl | Others are going to be more guidance than specification | ||
| Tene | japhb: will plumage be shipping with Parrot, eventually? | 06:19 | |
| japhb | 3 is a no-go, I think. When Plumage is slightly more empowered, people will start using it, and it will install itself (and its modules) into Parrot's install tree, presumably. Eventually, the Plumage code base will merge into the Parrot tree wholesale. | ||
| I'd say, for now just leave the hackish one in the Plumage repo (option 1). | 06:20 | ||
| A more powerful/complete version would be something that Plumage would be used to install. ;-) | |||
| Tene | So this *will* end up in the Parrot repo eventually, but not quite yet... | 06:21 | |
| I feel a little hesitant to grab a large/potentially contested namespace like HTTP and Downloader... | 06:22 | ||
| japhb | Allison said that she wants it to cook faster than Parrot deprecation policy would allow. | ||
| Tene, so don't. If it sits in the Plumage repo, we can easily rename it before we do the merge. | 06:23 | ||
| Tene | I keep thinking we need some kind of prefix... CoreUtils, PlumageUtils, PUT (ambiguous on PArrot/Plumage)... | ||
| eh, whatever, okay. | |||
| hardly important. | |||
| japhb | Plumage:: ? We could move the Glue module within that too, I suppose. | ||
| japhb shrugs | 06:24 | ||
| Tene | Once it's merged, is this HTTP stuff intended just to support Plumage, or is it supposed to be available for other secret plans? | ||
| japhb | As I said, we needn't solve the naming now. If we only affect the Plumage repo, no conflicts can occur until we start installing Plumage into the Parrot install tree. | 06:25 | |
| Tene | Yeah, okay. I'll drop it. Having trouble sleeping, and this kept coming up. | ||
| I'll go review your changes ot metadata. | |||
| japhb | My thought is that we should assume a hackish, minimalist HTTP client for Plumage's use that will be shipped with it. A full HTTP client, minus the hackishness, would be a project that Plumage would install (and perhaps could then use, if it did nifty stuff) | 06:26 | |
| np | |||
| Insomnia is Teh Suck. | |||
|
06:27
fperrad joined
|
|||
| Tene | Yeah, okay, that sounds good. | 06:27 | |
| It can' tbe *too* hackish, though... we'll need proxy support, redirects, etc... | |||
| japhb: entertained by considering making 'test' required too. | 06:29 | ||
| japhb | Tene: yes, agreed (re: proxy and redirects) | ||
| Tene, *chuckle* | |||
| jrtayloriv | Austin, ping | 06:30 | |
| Austin | Jesse? | 06:31 | |
| purl | Jesse is obra | ||
| Tene | to go without tests, use: { type : "DontTrustMySoftware" } | ||
| jrtayloriv | I can't find anywhere that Coke is using DynLexPad, although from reading what docs and websites, and the IRC conversation you and coke had, it does seem like DynLexPad is what I want. | ||
| But the docs are pretty skimpy on it. Any languages you know of that use it, that I could look at? | 06:32 | ||
| Austin | Sadly, I am ignorant of it. I know he was talking about it here on irc, but that's all. | 06:33 | |
| jrtayloriv | ahhh nm -- I need to start looking at tests as documentation from now on ... | 06:34 | |
| Austin | code.google.com/p/partcl/source/bro...&r=558 | 06:38 | |
| In a sub called 'mappings', he maps. It's an interpreter call. | |||
| But I can't find any reference to dynlexpad. | 06:41 | ||
| :( | |||
| jrtayloriv | Austin, OK. So basically, my goal is to determine how to use interp.'hll_map'() to make it create dynlexpad's instead lexpad's, correct? | 06:42 | |
| Austin | No. | ||
| jrtayloriv | grrrr | ||
| Austin | Your goal is to determine how to use dynlexpads. Hll mapping may or may not figure in to it. | ||
| Tene | japhb: this wget implementation is *slow*. | 06:43 | |
| japhb | ? | ||
| Tene | japhb: try running it on, say, www.parrot.org/files/parrotify_logo.png | ||
| japhb | I like your non-testing metadata. :-) | ||
| Tene, will do in a couple. Head down in some plumage code | |||
| jrtayloriv | Austin, OK. I am reading the docs for hll_map ... had never heard of it until tonight. Also reading the tests for dynlexpad. Thanks for the pointer -- seems like this is the right area to be looking in for my solution, at least. | 06:44 | |
| Austin | :) | ||
| jrtayloriv | I could not find DynLexPad anywhere in Coke's code either though. I'll have to ask him later what is going on with that. | 06:45 | |
| Austin | Maybe he hasn't committed yet. | 06:46 | |
| Tene | japhb: if I add a counter to the recv loop, it runs through 13 times real quick, and then stalls on the last iteration. | ||
| Austin | Anyway, in $PARROT/t/dynpmc/dynlexpad.t I think is everything you need. | ||
| Test #2 | |||
| japhb | Trying to read the full number of bytes requested in the recv? | 06:47 | |
| Or maybe need to see if the socket is ready for read before trying to recv? | |||
| Tene | Hmm. It looks like it's actually stalling in the 'recv' method. | 06:48 | |
| looks like it's blocking in the 'recv' in libpthread.so | 06:50 | ||
| It's calling string_make many times. | 06:51 | ||
|
06:52
theory joined
|
|||
| Tene | Wait... maybe. | 06:52 | |
| japhb | Need to make socket non-blocking? | ||
| Tene | japhb: no, blocking is the right behavior here. | ||
| purl | okay, Tene. | ||
| Tene | purl: forget blocking | 06:53 | |
| purl | Tene: I forgot blocking | ||
| Tene | japhb: I'll work it out... I'm just talking out loud here. Ignore me. | ||
| japhb | Tene, sorry if silly suggestions, this window is only getting 5% of my brain at the moment. :-) | ||
| Tene | japhb: nah, don't worry about it. | 06:54 | |
|
06:54
iblechbot joined
|
|||
| Tene | Hmm. It works instantly connecting to my local webserver, even on large files... | 06:55 | |
| So maybe it's network errors. | |||
| Eh, I'll troubleshoot it later. | |||
| jrtayloriv | Austin, It looks like I actually do want to use hll_map to use dynlexpad instead of lexpad, like so: interp.'hll_map'(lexpad, dynlexpad) ... that should make it where when I do store_/find_lex it uses the DynLexPad vtables instead. | ||
| Tene | jrtayloriv: make sure to do that at :immediate time, iirc. | 06:56 | |
| Austin | Right. There's another caveat, too. All your subs that might get lex-ified by define, or anything else that makes up its own names at runtime, has to be declared with :lex | ||
| For now, that's just the $TOP block | 06:57 | ||
| jrtayloriv | Austin, Right, saw that (about :lex) too. | ||
| Tene, My TOP method creates an PAST::Block.new(:blocktype('immediate') ...) is that what you mean? | |||
| Tene | jrtayloriv: Yes. | 06:58 | |
| jrtayloriv | ok | ||
| Austin | Tene: the tests show it running in a block marked :init | ||
| Tene | Austin: Oh, okay. nm then. | 06:59 | |
| Austin: I must have been thinking of hll_mapping subs or something else. | |||
| Austin shrugs. | |||
| You know more about it than I do. (Since everything I know has come in the last 10 minutes...) | |||
| jrtayloriv: This is one of those compiling/interpreting moments. If your compiler is an interpreter, you'll want to make sure to add this to the startup of the compier, too. | 07:00 | ||
| *compiler | |||
|
07:04
chromatic joined
|
|||
| jrtayloriv | Austin, What is the "this" that I need to add to startup of the compiler? | 07:05 | |
| Austin | hll mapping the lexpads | ||
| If you're running it as an interpreter, then you might encounter a (define) in your interpreting. | 07:06 | ||
| jrtayloriv doesn't grok ... is going to see if another cup of coffee helps ... brb | 07:12 | ||
| japhb | Tene, plumage.nqp and metadata/* now updated to spec rev 1. Also, plumage now checks spec uri and version before working with the metadata. | 07:19 | |
| Austin, see above WRT Close.json | |||
| Tene | japhb: I also need to make a metadata file for parrot-mysql repo | 07:20 | |
| japhb | Tene, nodnod. Should be cleaner with the new rev. | ||
| Austin, actually, you probably just want to update your copy from gitorious.org/parrot-plumage/parrot...Close.json | 07:21 | ||
| Austin | Works for me. | 07:22 | |
| japhb | (This copying won't be necessary some time from now, but we're not there yet. :-) | ||
| Tene | japhb: pretty sure I have the tree-merging algo done in my head, just need to write it down. | ||
| japhb | Tene, cool beans | 07:23 | |
| Tene | japhb: also, this http work will make it possible to grab the referred-to url, for purposes of merging. | ||
| dalek | ose: r169 | Austin++ | trunk/plumage/Close.json: Incorporated japhb's changes for plumage. |
||
| Austin | Committed. Thank you. #169 | ||
| japhb | Austin, np | 07:24 | |
|
07:24
baest joined
|
|||
| japhb | (accelerating progress)++ | 07:24 | |
| Tene | japhb: maybe I need to go make a curses-based app to build metadata files... ;) | 07:25 | |
| japhb | Tene, heh. We will certainly have tools for generating them some time down the road, but you're welcome to play around whenever. | 07:26 | |
| Once we can actually run through a full build/install, I'll probably write something small to import the proto projects .... | |||
| Or you can, if you like. | |||
| Tene, by the way, don't hesitate to add tasks like that to TASKS, if you're not planning to do it immediately. | 07:27 | ||
| Tene | japhb: I meant it as a joke. :P | 07:30 | |
| japhb | Tene, I tend to interpret such jokes in the same way Parrot was. ;-) | ||
| OK, I think it's really, truly, finally time for me to sleep. G'night all. | 07:42 | ||
| Tene | I'm gonna go try sleeping again too. | 07:43 | |
| 'night | |||
|
08:04
gaz joined
|
|||
| dalek | rrot: r41541 | dukeleto++ | trunk (2 files): [t][TT #763] Fix is_deeply() on hashes with undefs and add tests |
08:31 | |
| jrtayloriv | night #parrot | 08:35 | |
| jrtayloriv zzzzzzzzzzzzzzzzz | |||
| ttbot | Parrot trunk/ r41541 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/108126.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) | 08:37 | |
| dalek | rrot: r41542 | dukeleto++ | trunk/t/library/test_more.t: [t] Add another test for is_deeply() on hashes with undefs |
08:40 | |
| TT #763 closed by dukeleto++: Test/More.pir's is_deeply() needs work with hash corner cases | 08:44 | ||
| ttbot | Parrot trunk/ r41542 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/108167.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) | 08:47 | |
|
08:54
Austin_Hastings joined
09:00
masak joined
|
|||
| mikehh | I am getting an intermittent failure with t/pmc/os.t test 9 - it failed yesterday while running fulltest in testr and just now while running smoke (#28233) - but on retesting it passes | 09:37 | |
| All other tests PASS (pre/post-config, smoke, fulltest) at r41542 - Ubuntu 9.04 amd64 | 09:47 | ||
|
10:05
slavorgn joined
|
|||
| dalek | TT #1071 created by mikehh++: Intermittent failure with t/pmc/os.t test 9 | 10:35 | |
| mikehh | re-ran the my test run: | 10:51 | |
| all tests PASS (pre/post-config, smoke (#28234), fulltest) at r41542 - Ubuntu 9.04 amd64 | 10:52 | ||
| dalek | ose: r170 | Austin++ | trunk/src/close/Compiler/ (19 files): checkpoint: "Class"-ifying node, type, symbol, message |
10:55 | |
|
11:00
einstein joined
|
|||
| einstein | I have got a question, certain hll register there own type of Integer instead of the default parrot integer.pmc type. | 11:07 | |
| my question are there any hll which also store extra information/metadata onto their own Integer type? | |||
| or does these hll only add extra "functionalities" to there own implementation of integer? | 11:09 | ||
| Austin | einstein: I just had a look at tcl, and it just adds extra functionality | 11:11 | |
| Patterner | My "make" is broken. I have to run it 3 times before it doesn't compile anything... | 11:13 | |
| einstein | Austin: ok that could to know, so if class which an integer attribute can store the integer value instead of the, and can recreate the registered hll integer type if it is the integer attribute is retrieved | 11:14 | |
| moritz | Patterner: parallel build is horribly broken atm, try without any -j options (if you have any, that is) | ||
| Patterner | just "make"... what is the "-j" default? | 11:15 | |
| einstein | Austin: ok that could to know, so if I have a class with an integer attribute then can I store the integer value instead class object of the registered hll integer type, and can recreate the registered hll integer type if it is the integer attribute is retrieved | ||
| Patterner | (and yes, my Build script does "make distclean" first :) | 11:16 | |
| moritz | -j defaults to 1 | ||
| Austin | einstein: correct. In fact, you could just return a parrot:int to an int register, if it seems better to do that. | 11:17 | |
| einstein | austin: thanks for the information | 11:18 | |
|
11:33
jsut joined
11:42
bacek joined
12:02
whiteknight joined
|
|||
| whiteknight | good morrow, parrot | 12:04 | |
| purl msg Tene basically add similar methods to Socket like what is in FileHandle. "Readline" is the one I hear most requested, but "read", "put", "printf", etc would all be useful. | 12:05 | ||
| purl | Message for tene stored. | ||
| Austin | Howdy, Whiteknight | 12:11 | |
| whiteknight | good morning Austin | 12:12 | |
|
12:13
ruoso joined
|
|||
| whiteknight | just took a call from a customer who was having "problems with the website" in their browser: IE6 | 12:13 | |
| "sir, your browser IS the problem" | |||
| "please take your computer outside and light it on fire" | |||
| Austin | heh heh heh | 12:15 | |
| jonathan | ewww IE6 | ||
| Austin | NS4 was good enough for grandpa... | ||
| jonathan | There comes a point where the cost to support it is more than you'll ever reap in profit from those using it... | ||
| Austin | Consider Opera: the zero point is now! | 12:16 | |
| jonathan | Austin: That's why I don't test sites I build in Opera. | ||
| slxix | everyone should view their website in w3m. | 12:17 | |
|
12:20
cconstantine joined
|
|||
| whiteknight | the problem is that our customers almost exclusively come from the freight rail industry, who aren't exactly known to be "on the cutting edge | 12:25 | |
| " or "technology literate" | |||
| and everything is so javascripty in modern websites, it's amazing that IE6 is even still functional for everything | 12:26 | ||
| dalek | a: 62fbfec | fperrad++ | (2 files): refactor some test targets |
12:29 | |
| a: 3ef4945 | fperrad++ | : Merge branch 'master' of git@github.com:fperrad/lua |
|||
|
12:34
cconstantine left,
cconstantine joined
13:03
bluescreen joined
13:04
shorten joined
|
|||
| fperrad | ping pmichaud | 13:27 | |
| purl | I can't find pmichaud in the DNS. | ||
| pmichaud | fperrad: pong | 13:48 | |
| fperrad | pmichaud, have you seen my message about parrot_nqp ? | 13:49 | |
| pmichaud | fperrad: not yet -- just got on the computer this morning | ||
|
14:02
bluescreen joined,
PacoLinux joined
|
|||
| Patterner | I have a problem with libpcre... the test fails. | 14:04 | |
| the test gets "/usr" from "pcre-config --prefix", but /usr/lib/libpcre.so is a gentoo "fake" dynamic library (a GNU ld script, pointing to /lib64/libpcre.so.0). Any idea how to handle that? | 14:06 | ||
|
14:10
payload joined
|
|||
| NotFound | Patterner: some time ago I searched some forums about that problem. Looks like the official answer from gentoo is that linker scripts doesn't harm anyone. | 14:19 | |
| Patterner | sigh | ||
| Patterner feels harmed :) | |||
|
14:21
einstein joined
|
|||
| cognominal | moritz++ # Tie::Hash::Indexed as a way to learn ties and XS | 14:24 | |
|
14:29
Psyche^ joined
14:34
iblechbot joined
14:40
theory joined
14:49
AndyA joined
15:01
Andy joined
|
|||
| moritz | hm? | 15:19 | |
| not mine | |||
| moritz not mhx | |||
| dukeleto | 'ello | 15:42 | |
|
15:47
zerhash joined
15:50
allison joined
16:00
theory joined
|
|||
| cotto_working | hi dukeleto | 16:13 | |
|
16:45
kjeldahl_ joined
|
|||
| einstein | can it be that the vtable function instantiate_str can be deprecated, it is only used by imcc/pbc.c ? | 17:05 | |
| japhb | whiteknight, You may already have heard this, but several large web sites are delisting IE 6. Most are starting with a message suggesting upgrade, then not supporting functionality other than the most basic on IE 6, then finally dropping it altogether. | 17:07 | |
| And by big I mean Google, Yahoo!, Digg, ... | 17:08 | ||
| moritz | it's about time | ||
| cotto_work | einstein, that doesn't sound like a bad idea. Please file a ticket about it. | 17:09 | |
| japhb | The only reason Microsoft is still supporting it is ... get this ... the extended support for Windows XP caused by the Vista backlash. | ||
| einstein | cotto_work: ok i will do that | 17:10 | |
| cotto_work | einstein++ | ||
| it's great to get rid of old cruft | |||
| cconstantine has a friend who is stuck with IE6 at work. Hopefully the stuff japhb is talking about forces the hands of IT departments that still require the use of IE6. | 17:18 | ||
| dalek | TT #1072 created by jessevdam++: deprecate vtable function instantiate_str | ||
| NotFound | japhb: I still have a system with a win98 SE partition X-) | 17:21 | |
| moritz | I installed Win98 so often that I knew the registration key by heart at one point | 17:22 | |
| jrtayloriv | Basically, when I do interp.'hll_map'(lexpad, dynlexpad) it will make it where when I explicitly do .lex 'foo', it will use the LexPad vtables, but if I do store_lex 'baz', without declaring 'baz' as .lex, then it uses DynLexPad vtables for store_/find_lex. Is this correct? | 17:30 | |
| Or does it just always use DynLexPad vtables in either case? | |||
| cotto_work | cconstantine, I doubt it. There are a lot of poorly-written legacy apps that depend on ie6. | ||
| jrtayloriv actually got a "you have to use Internet Explorer to view this site" message the other day, at a customer support site ... jaw dropping | 17:32 | ||
| cconstantine | cotto_work: a newb can dream? | 17:35 | |
| japhb | NotFound, moritz: ouch. | ||
| cotto_work | and wake up | 17:36 | |
| whiteknight | japhb: yeah, it's something we're going to do here eventually too: disallow IE6 | 17:37 | |
| because our website is so JS-heavy, older browsers just can't do it | |||
| japhb | whiteknight, for that problem, I just let jQuery handle the pain. | ||
| whiteknight | we don't use JQuery, even though I keep suggesting it :( | 17:38 | |
| japhb | Mind you, IE 6 is by far the slowest browser they still support, but every release they somehow find a way to make it faster anyway, which boggles me. | ||
| whiteknight, :-( | |||
|
17:39
uniejo joined
17:40
mokurai joined
|
|||
| jrtayloriv <-- jQuery makes this guy's life way easier. | 17:41 | ||
|
17:41
particle joined
17:43
Austin joined
|
|||
| NotFound | "a sales assistant at supermarket Tesco told the reporter that netbooks got their name because 'a Japanese man on a plane fell asleep with a laptop on his thighs and was horribly burned, so the industry has dropped the name laptop" | 17:46 | |
|
17:51
joeri joined
18:01
chromatic joined
18:02
iblechbot joined
18:07
darbelo joined,
japhb joined
18:15
kyle_l5l joined
|
|||
| nopaste | "Austin" at 98.235.55.43 pasted "Help! Why does $P0 end up null?" (43 lines) at nopaste.snit.ch/18093 | 18:19 | |
| Austin | Can someone with more PIR savvy than me take a look at the nopaste (nopaste.snit.ch/18093) and help me understand why $P0 winds up null? | 18:20 | |
| pmichaud | looking | ||
| whiteknight | ditto | ||
| pmichaud | rebuilding, too | 18:21 | |
| whiteknight | Austin: it's null at the say? | ||
| Austin | Yeah, the one I commented out gets a NULL PMC access | ||
| pmichaud | it shouldn't. | ||
| whiteknight | you arne't setting $P0 to anything | ||
| pmichaud | it's a lexical, the "store_lex" should be changing it | 18:22 | |
| whiteknight | store_lex overwrites the PMC pointer, doesn't copy to $P0 | ||
| pmichaud | lexicals are mapped to context registers | ||
| the PMC pointer *is* $P0 | |||
| see, for example, $P3 later in the same code snippet | 18:23 | ||
| Austin | Note: This was intended as a test to see what happened when a lexical was re-declared. Is IMCC doing something? | ||
| pmichaud | oh | ||
| right | |||
| the problem is that you're redeclaring 'foo' | |||
| that's a no-no | |||
| redeclaring foo causes it to lose its original mapping | 18:24 | ||
| imcc should probably complain when that happens | |||
| chromatic | I can work on that. | 18:25 | |
| Austin | Okay. I modified the test to print set P6 (which I .lex foo later) early, and then to print it after the .lex foo P0, and sure enough it gets the foo values. | 18:26 | |
| So IMCC is the one responsible for the .lex mapping, and it quietly remaps the binding. | 18:27 | ||
| pmichaud | correct. | 18:28 | |
| Austin | So there can't be two same-named lexicals in the same scope, unlike package's | ||
| *package's = package symbols | |||
| whiteknight | pmichaud: as a general inquiry into lexicals, why does the current system use LexInfo/LexPad pairs, and why does it require lexicals to be declared at compile time? | 18:30 | |
| pmichaud | whiteknight: I'm not the designer, I just repaired the installation (more) :-) | ||
| jrtayloriv | I was wondering the same thing. Why not always use DynLexPad? | 18:31 | |
| pmichaud | s/installation/implementation/ | ||
| Austin | Speaking of package symbols, does anyone know what happens if I have a sub 'foo', and I bring in another declaration of 'foo' via load_* or eval? | ||
| pmichaud | Austin: it overwrites the original, usually | ||
| whiteknight | Austin: locusts | ||
| pmichaud | whiteknight: I think the point of the current implementation was exactly the register mapping | 18:32 | |
| chromatic | LexInfo stores the lexical information for a Sub: which lexicals does the sub have. | ||
| pmichaud | for example, if I have .lex 'foo', $P0 | ||
| chromatic | LexPad stores the lexicals for an *invocation* of the Sub. | ||
| Think recursion. | |||
| pmichaud | and then I call a sub that does store_lex 'foo', $P2 | ||
| whiteknight | chromatic: yes, I think I know *what* the implementation does, just not *why* it was designed this way | ||
| pmichaud | then $P0 is changed | ||
| without having to do a re-fetch | |||
| in order for that to happen, we have to have a structure that maps lexical names to registers | 18:33 | ||
| and that's what LexInfo does | |||
| I don't think it's quite possible to do that with dynlexpad | |||
| at least, not as a declaration. We'd have to have some sort of opcode to associate a lexical symbol with a register | |||
| and getting that mapping correct is likely to be tricky | 18:34 | ||
| whiteknight | okay, that makes a bit more sense then | ||
| pmichaud | jonathan++ and I have also been playing with the notion that subs should also have a "default LexPad" that is used as the template for initializing its lexicals when the sub is invoked | ||
| Austin | Pmichaud: So declaring foo twice in the same file binds the name to the first one, and loading it in later overwrites? | ||
| pmichaud | Austin: rebinds, I think. | 18:35 | |
| Austin | Sure. | ||
| pmichaud | I think the first one is still in memory, unless/until GC'd | ||
| Austin | Is this one of those cases where "get_*_global 'foo'" will find the newly-loaded foo, but anybody that calles 'foo'() will still point to the original? | 18:36 | |
| whiteknight | that's actually a good question | ||
| pmichaud | I don't think so. | ||
| It used to be that way, yes. | |||
| but I think that mis-optimization got removed. | |||
| Austin | It still is, if you leave out the loading. | ||
| whiteknight | would definitely like to see a test to verify operation | ||
| pmichaud | test coming up | ||
| Austin | At least at 41311 | ||
| pmichaud | you're correct, Austin -- the imcc misoptimization is still in place | 18:37 | |
| nopaste coming | 18:38 | ||
| nopaste | "Austin" at 98.235.55.43 pasted "Name-switching code" (66 lines) at nopaste.snit.ch/18094 | ||
| "pmichaud" at 72.181.176.220 pasted "IMCC still optimizes 'foo' incorrectly" (23 lines) at nopaste.snit.ch/18095 | |||
| Austin | In the nopaste above, I found that I had to call Test::foo instead of foo, or the swapping would be ignored. | 18:39 | |
| pmichaud | correct | ||
| IMCC translates the call to 'foo' into a direct call | |||
| instead of doing the symbol lookup | |||
| 2nd nopaste coming | |||
| Austin | What does that mean? | ||
| purl | That boy needs therapy. | ||
| Austin | "direct call" ? | ||
| pmichaud | 2nd nopaste coming | ||
| Austin | Sure. | ||
| whiteknight | at compile time, IMCC translates the call to 'foo'() to a direct link with the sub and doesn't check that the runtime bindings are the same | 18:40 | |
| nopaste | "pmichaud" at 72.181.176.220 pasted "IMCC still optimizes 'foo' incorrectly" (46 lines) at nopaste.snit.ch/18096 | ||
| Austin | I get that, whiteknight, because it matches the data. But I don't understand how it's possible. | ||
| pmichaud | look at the trace output, and the differences between the calls to 'foo' and 'bar' | 18:41 | |
| whiteknight | the literal sub 'foo' is stored in the constants table in PBC | ||
| pmichaud | er, 'baz' | ||
| whiteknight | and the call to 'foo'() calls the item from the constants table | ||
| pmichaud | the call to 'baz' takes place by doing "find_sub_not_null" (which looks it up lexically and in the package) | ||
| the call to 'foo' has been "optimized" by IMCC, which says "oh, I know what 'foo' is, so I'll just jump to it directly" | |||
| the problem is that IMCC _doesn't_ know what 'foo' is at runtime, and so it's calling the wrong sub. | 18:42 | ||
| Rakudo gets hit with this problem a lot. | |||
| whiteknight | do we have a ticket? | ||
| chromatic doesn't think it's a bug. | 18:43 | ||
| whiteknight | chromatic: so a direct call 'foo'() should be a compile-time binding? | ||
| chromatic | Yep. | ||
| whiteknight | (I don't disagree, just want clarification) | ||
| okay, so a dynamic call should always be $P0()? | |||
| pmichaud | chromatic: even if that sub is replaced later? | ||
| chromatic | If your language supports replacing those bindings, you get to do some extra work. Seems fair to me. | 18:44 | |
| whiteknight | pmichaud: technically only the entry in the namespace has been replaced, the literal sub hasn't been | ||
| pmichaud | whiteknight: sure, but the default meaning of 'bar'() is to do a name lookup | ||
| which also looks in the lexical scopes as well | |||
| Austin | I've been hedging around this issue with JRTaylorIV, and to a lesser extent cconstantine. | ||
| whiteknight | pmichaud: I neither agree nor disagree. What we expect that syntax to mean is dependant on the user | ||
| pmichaud | (looking in the lexical scope was fixed by chromatic++, btw) | 18:45 | |
| chromatic | I think I deleted two lines of code to make that work. | ||
| whiteknight | so long as both ways are possible, one is the default, and everything is documented, that's what we have | ||
| pmichaud | if the "direct call to 'foo'" is likely to remain, then I think I'll switch PCT so that it always does a name lookup | 18:46 | |
| Austin | Pmichaud: Don't do that. | ||
| Please? | |||
| pmichaud | Austin: why not? | ||
| whiteknight | a flag to specify behavior might be easier | ||
| Austin | There's a valid way to configure either behavior, and one is definitely faster than the other. | ||
| chromatic | Much, much faster. | ||
| whiteknight | there is plenty of room to opimize both codepaths though | 18:47 | |
| Austin | Leaving the 'foo' as a var node under call produces the lookup, while moving the name into call.name() produces the other. | ||
| The only problem is with tailcall. | |||
| pmichaud | the find_name opcode is that slow...? | ||
| whiteknight | I would like to see something like a :binding("static"|"dynamic") flag there | ||
| Austin | I have no idea. But I'm sure two opcodes are slower than one. | ||
| whiteknight | give PCT either as a default, and let the user decide if they want something else | 18:48 | |
| pmichaud | I can't tell you how many hours jonathan and I have lost because of this particular IMCC misoptimization | ||
| Austin | How so? | ||
| chromatic | The find_name opcode at runtime is much slower than the find_name opcode at runtime for every call. | ||
| Wait, let me rephrase. | |||
| Austin | chromatic: :) | ||
| pmichaud | just because we define a method called 'list', all of our calls to a "list" function end up being mis-optimized to call that method. | ||
| chromatic | The find_name opcode at runtime for every call is much slower than the find_name opcode once at compile time. | ||
| pmichaud, that sounds the like "Don't store methods in namespaces" bug. | 18:49 | ||
| whiteknight | pmichaud: that problem should be resolved by the :nsentry stuff, no? | ||
| pmichaud | should be, isn't. | ||
| Austin | WhiteKnight: Currently, (call name=foo (arg1) (arg2)) produces the static binding, while (call (foo) (arg1) (arg2)) produces the dynamic. | ||
| pmichaud | I'll hold off on a pct switch for now then, yes. | ||
| whiteknight | Austin: so long as there is a way for the compiler-designer to specify, I don't care about syntax or which is the default | 18:50 | |
| pmichaud | however, consider the following Perl 6 code: | ||
| sub foo () { say 'foo'; } | |||
| chromatic | Remember that this isn't callee-side binding; it's callee-side binding. | ||
| pmichaud | sub bar () { say 'bar'; } | ||
| &foo := &bar; | |||
| foo(); | |||
| If IMCC optimizes the call to 'foo', then we end up with wrong results. | 18:51 | ||
| whiteknight | chromatic: rephrase? | ||
| chromatic | Don't put the "I might rebind this!" flag on the sub that you might rebind. | ||
| Put it on the sub where you call something that might be rebound. | |||
| pmichaud | I don't follow. | ||
| whiteknight | I think chromatic is stuck in an infinite loop today! :) | ||
| "Don't do X, do X!" | 18:52 | ||
| PerlJam | whiteknight: that's not what he said :) | ||
| pmichaud | I don't quite understand what he said. :) | ||
| whiteknight | don't put the flag on the sub you might rebind, put the flag on the sub that might be rebound | 18:53 | |
| Austin | What does 'find-sub-not-null" do? | ||
| chromatic | In pmichaud's example, don't put a flag on foo() or bar(). Put the flag on whatever *calls* foo(). | ||
| pmichaud | what "flag"?!? | ||
| I totally don't understand. | |||
| "put a flag on whatever calls foo" simply means "put a flag on every call" | |||
| chromatic | If you add a flag to say "Never allow static lookups." | ||
| pmichaud | because every call in Perl 6 could be rebound | ||
| Austin: looks up a symbol by name in the lexical, package, and global scopes, throws an exception if not found (i.e., if null) | 18:54 | ||
| if there's something that is "a flag set on every instance", then having the flag set should be the default :) | 18:55 | ||
| Austin | Okay. | ||
| pmichaud | thus I think PCT should default to "the name lookup behavior is the default, and you put a flag if you want the optimized behavior" | 18:56 | |
| Austin | So if I have a lexical variable masking a global sub, it's going to try to call the variable? | ||
| pmichaud | Austin: yes. | ||
| PerlJam | pmichaud: that sounds backwards too | ||
| pmichaud | PerlJam: why? | ||
| PerlJam | (from an optimization standpoint) | ||
| pmichaud | we're supporting _dynamic_ languages | 18:57 | |
| in a dynamic language, rebinding is the norm | |||
| chromatic | Rebinding *function calls* is the norm? | ||
| pmichaud | when I say "foo()" in Perl, I'm calling the function associated with the current &foo symbol | ||
| whiteknight | so long as there is a flag provided to keep the current behavior, I see no issue with this | 18:58 | |
| pmichaud | I'm not calling the function that happened to be called foo at the time compilation took place | ||
| Austin | chromatic: putting a function into a lexical variable seems pretty common for the pure-functional guys | ||
| chromatic | That binding is statically bound in Perl 5 though. | ||
| Austin | "Parrot is designed to be the optimal virtual machine for implementing Perl 5" | 18:59 | |
| -- pmichaud @ yapc | |||
| TimToady | it's statically bound in Perl 5 only up to the point you say *foo = sub {...} | 19:00 | |
| chromatic | Sure, but consider \\&foo *before the declaration of* foo. | ||
| PerlJam | TimToady: heh ... I was just typing an that in an example :) | ||
| Austin | So it seems like an obvious question is, Is there a language that allows functions and variables with the same name? | 19:01 | |
| chromatic | Perl 5. | ||
| Austin | C | ||
| PerlJam | chromatic: I thought I understood you until just now. | ||
| chromatic | my $x = \\&foo; | 19:02 | |
| *foo = sub { ... }; | |||
| Austin | Chromatic: I don't think p5 allows that. The sigil separates them, no? | 19:03 | |
| chromatic | Assume no 'sub foo { ... }' in scope. | ||
| Taking a reference to a sub that does not exist binds to the sub that will exist, if it does exist at the point of dereferencing the sub ref. | |||
| Austin | My head just exploded. | ||
| TimToady | trying to make any sane point via Perl 5 examples seems...odd | ||
| pmichaud | heh | 19:04 | |
| chromatic | My point is this: "always static" and "always dynamic" are both wrong. | ||
| whiteknight | chromatic: we don't want IMCC or PCT to flip a coin | ||
| Austin | whiteknight: That's what it's doing now. | ||
| chromatic | I'm not suggesting random behavior either. | ||
| whiteknight | chromatic: are you saying what I'm saying then? Use a flag? | 19:05 | |
| Austin | "If I see foo in scope, heads. Otherwise, tails." | ||
| chromatic | I don't know how you support that Perl 5 behavior with a flag. | ||
| Austin | What perl5 behavior? | ||
| pmichaud | if I want to always bind to a specific sub, then use .const 'Sub' $P0 = 'foo'; $P0() | ||
| PerlJam | Austin: the example he just gave | ||
| Austin | PerlJam: I saw it, but I don't understand how it applies. | 19:06 | |
| pmichaud | _which_ PCT already supports, I might add. :) | ||
|
19:06
cotto_w0rk joined
19:07
japhb joined,
mberends joined
|
|||
| whiteknight | pmichaud: how? | 19:08 | |
| chromatic | If our static bindings were to a *storage location*, we could probably support everything appropriately. | ||
| pmichaud | whiteknight: I don't remember the exact steps -- essentially one takes a reference to the PAST::Block structure and invokes it | 19:09 | |
| whiteknight | You mean like a p5 typeglob? | ||
| chromatic | Only by rough analogy, yes. | ||
| pmichaud | essentially one creates a PAST::Val that refers to the block | ||
| at least, ISTR it's something like that. I know that Rakudo uses it. | |||
| Austin | If IMCC optimized the 'foo' into a reference to the namespace entry, rather than the const table, I think. | ||
| pmichaud | that's better, yes. And if we can prove that there's no 'foo' lexical intervening. | 19:10 | |
| Austin | Umm, no. | ||
| The lexical bit is what gives me the willies. | |||
| pmichaud | why? | ||
| chromatic | It's less scary if lexicals have sigils. | 19:11 | |
| Austin | :) | ||
|
19:11
theory joined
|
|||
| Austin | If I'm calling "foo"(), I expect a sub named foo. Not a reference from a variable named foo. That's where I'd put the onus on the compiler. | 19:12 | |
| pmichaud | what does "sub named 'foo'" have to do with namespaces, though? | 19:13 | |
| i.e., why are namespaces more magical than lexpads as far as subs and references are concerned? | |||
| Austin | I'm in a namespace. I call foo. I get the foo in this namespace. | 19:14 | |
| pmichaud | you're also in a lexical scope, though. | ||
| why shouldn't you get the foo that is in the current lexical scope? | |||
| chromatic | His language doesn't look up functions in lexical scopes. | ||
| pmichaud | sure | 19:15 | |
| Austin | No, it's a more legitimate question than that. | ||
| pmichaud | but saying that functions can only exist in package scopes sounds... limiting | ||
| Austin | I think a large part of it is "that's the way it currently is". | ||
| PerlJam | Austin: where I live, there are several law enforcement agencies that have overlapping jurisdiction: city police, county sherrifs, constables, and state trooper. Just think of lexicals and packages in the same way :) | ||
| Austin | PerlJam: Sure, and when you have an issue involving real property (real estate), it's always the Sheriff. | 19:16 | |
| pmichaud | Austin: would you also expect to look up the global foo as well? | ||
| Austin | Pmichaud: global? | 19:17 | |
| purl | global is mankz.com/code/GlobalCheck.htm | ||
| pmichaud | sure. right now 'foo'() looks in the lexical scope, package scope, and global namespaces for a function called "foo" | ||
| Austin | By global, do you mean hll root namespace? | 19:18 | |
| pmichaud | that's why one can call "_dumper($P0)" from any sub and have it work | ||
| I'm not sure exactly where the global namespace lives. I just know that there is one. | |||
| and that it's separate from the current namespace | |||
| Austin | Man, talk about learning something new every day. | ||
| pmichaud | and (I think) that it's not hll-dependent. | ||
| Austin | So how do I put things in the global namespace? | 19:19 | |
| pmichaud | not sure. | ||
| Austin | :) | ||
| pmichaud | To my knowledge, I've never done it, because that would be Evil. | ||
| Austin | If *you* don't know how to get things in there, then I don't mind if it gets searched, because there's nothing in it. :) | ||
| Except _dumper, apparently. | 19:20 | ||
|
19:21
theory_ joined
|
|||
| whiteknight | So maybe that's just the answer: we have too many overlapping jurisdictions, and we must always manually specify | 19:21 | |
| pmichaud | I don't mind that too much for imcc. PCT will have a default, though. | 19:22 | |
| whiteknight | the invoke PAST node would have a :binding flag that takes "static", "namespace", or "callchain" or "lexical" | ||
| pmichaud | too complex | ||
| currently function calls are PAST::Op with :pasttype('call') | |||
| Austin | Also not compatible with current design | 19:23 | |
| pmichaud | there would be a :pasttype('callstatic') which performs the static version. | ||
| and perhaps generates an exception if there's no sub of the given name in the current compilation unit | 19:24 | ||
| Austin | logs? | ||
| purl | rumour has it logs is irclog.perlgeek.de/parrot/ | ||
|
19:24
preflex joined
|
|||
| pmichaud | keep in mind that the behavior becomes somewhat different if 'foo' is a :multi | 19:25 | |
| Austin | Does it? | 19:26 | |
| If IMCC optimizes the call, what happens to multi-ism? | 19:27 | ||
| Also, if I define 3 multis 'foo', and then create a lexical foo, what happens? | |||
| Can I create a lexical multi? | |||
| (If so, what happens if I define a package sub foo non-multi, and then define a lexical multi foo?) | 19:28 | ||
| whiteknight | too many questions! | ||
| IMCC handles multies correctly, I'm pretty sure about that | 19:31 | ||
| and no idea about the multies and the lexical. Sounds like we need a test about that | |||
| alhough I suspect all the multis disappear | |||
| pmichaud | a lexical would hide the namespace multies | 19:32 | |
| (that's arguably the correct behavior) | |||
| Austin | Whiteknight: If IMCC bind a particular multi, that'll be wrong if I load more at runtime. | ||
| pmichaud | :multi subs are held as a single MultiSub PMC | 19:33 | |
| Austin | Okay, so the load will jam the new ones in, or overwrite pmc? | ||
| *overwrite the pmc | |||
| pmichaud | a load will take any additional :multi's and add them to what exists | ||
| I'm not sure what happens if the load contains non-:multi s of the same name. My guess is that it would re-bind in that case, or throw an exception. | 19:34 | ||
| Austin | :) | ||
| pmichaud | looks like it reinds | 19:35 | |
| *rebinds | |||
| Austin | So if lexical hiding multi is the right behavior, what's the usage model for lexicals? It can't be the perl example, since perl supports multi's, right? | ||
| nopaste | "pmichaud" at 72.181.176.220 pasted "loading a non-multi rebinds" (46 lines) at nopaste.snit.ch/18097 | 19:36 | |
| pmichaud | wait, that was a miskey | ||
| renopasting | |||
| Austin | <whew> I was desperately looking for multi-ism anywhere... | 19:37 | |
| nopaste | "pmichaud" at 72.181.176.220 pasted "loading a non-multi rebinds" (18 lines) at nopaste.snit.ch/18098 | ||
| pmichaud | in Rakudo's case, we won't end up having any package calls anyway | ||
| all sub calls are lexical | |||
| (unless explicitly packaged scoped) | |||
| i.e., foo() always ends up doing a lexical foo() | 19:38 | ||
| adding a multi creates a new MultiSub object that includes the existing multi candidates | |||
| Austin | So how do multi's work? Are you creating a lexical pmc multisub foo? | ||
| pmichaud | sure | 19:39 | |
| we already create lexical subs when someone does "my sub foo() { ... }" | |||
| Austin | Why not just make package foo tailcall lexical foo? | ||
| whiteknight | I think the best practices rule needs to be that loadable libraries should generally define their own namespaces, and not just dump into an existing namespace | 19:40 | |
| Austin | It seems like it would solve your list method problem. | ||
| pmichaud | so, instead of a find_name opcode, you're suggesting we replace it with an extra sub/tailcall? | 19:43 | |
| that'd be worse. | |||
| *much* worse. | |||
| whiteknight | I still hold out hope that the PCC refactors are going to produce lots of opportunities for optimizations | 19:44 | |
| pmichaud | sure, but I'll claim that as a general rule invocation of a single opcode will always be more efficient than a PCC call | 19:45 | |
| chromatic | I agree with pmichaud. | ||
| whiteknight | Oh, i don't disagree with that, in general | ||
| although our ops aren't exactly atomic, and some of them are very complex indeed | 19:46 | ||
| depends which sub and which PCC call | |||
| whiteknight nitpicks | |||
| pmichaud | so, in the final analysis, while I disagree with imcc "optimizing" calls to package subs the way it does now, I'm not going to argue strongly for a change. But PCT might change so that it expresses the behavior I think should be the default, while providing an option to get back to the imcc behavior. | 19:48 | |
| and to completely describe the existing imcc behavior, it's... | 19:49 | ||
| (1) use any lexically available sub | |||
| (2) use any statically available sub in the current package and compilation unit | |||
| (3) use a dynamically looked up sub in the current package (but not in the compilation unit) | 19:50 | ||
| (4) look in the global namespace | |||
| (5) throw a "sub not found exception" | |||
| I'm going back to my regex engine updates :) | 19:52 | ||
|
19:56
bacek joined
|
|||
| whiteknight | Want to hear something funny? | 20:00 | |
| Austin | A horse walks into a bar... | ||
| the bartender says... | |||
| whiteknight | I don't know a lick about SQL or databases, and I'm my companies lead DBA now apparently | ||
| Austin | "Why the long face?" | ||
|
20:00
kjeldahl_ joined
|
|||
| Austin | Congratulations! | 20:00 | |
| purl | Congratulations! are you joel? | ||
| whiteknight | Austin: not a congratulatory thing | 20:01 | |
| I've officially risen to my level of incompetence | |||
| Austin | Why not? DBA's get a boatload of money. | ||
| whiteknight | not this DBA | ||
| pmichaud | I think "Congratulations" might be in the same sense of "funny" :) | ||
| Austin | There's your problem, right there. | ||
| pmichaud++ | |||
| And thank you, patrick, for that explanation of IMCC's behavior. I had no idea about the lexicals. | |||
| whiteknight | exactly: no more money, lots of additional responsibility, and an increased probability that they're going to discover that I'm a bozo and fire my ass | 20:02 | |
| pmichaud | it just does whatever "find_name" does. | ||
| whiteknight: in my limited experience, there's an incompetency tipping point that once you reach it is followed by rapid increases in pay and status for little extra knowledge and achievement. You may be reaching that tipping point. | |||
| whiteknight | and to think I originally responded to a job advertisement for an "embedded C programmer" | 20:03 | |
| Austin | :) | ||
| chromatic | S/Andrew/Peter/ | ||
| pmichaud | of course, it all comes crashing down in the end, so invest wisely while on the upward slope. | ||
| Austin | Andrew, what do you want to be doing? | ||
| NotFound | whiteknight: They embed you in something? | ||
| whiteknight | Austin: "embedded C programmer" | ||
| chromatic | In Afghanistan, NotFound. | ||
| whiteknight | :) | ||
| Austin | NotFound: Testing the linear accelerator... Put a C programmer in this end, press the button, and ... | ||
| whiteknight | and here I am developing websites in C# and doing database/SQL nonsense | ||
| Austin | Would you like to go on a job interview? | 20:04 | |
| NotFound | The Large Hired programmer Collider, I suppose. | ||
| whiteknight | Austin: entirely possibly. Have one handy? | ||
| Austin | Maybe. I have some friends in PennDel doing C/C++ embedded. | 20:05 | |
| whiteknight | Penndel? My wife would cry with Joy | ||
| love you so much she might accidentally become your wife | 20:06 | ||
| Austin | It's not bit-twiddling - it's embedded linux - but there's some DSP and gnarly stuff. | ||
| whiteknight | so watch out | ||
| Austin | You know, I'm laughing and I haven't even written out this next sentence: | ||
| It's for the technology arm of an MLM company. | 20:07 | ||
| Austin laughs hysterically. | |||
| whiteknight | that is pretty funny | ||
| Austin | You'd be safe: they make phones. | ||
| whiteknight | Anything would be a step up from what I'm being paid now | 20:08 | |
| I didn't know receiving bits of string each month satisfied minimum-wage laws | 20:09 | ||
| Austin | Sure. How do you think the government keeps all those pigeons on payroll. | ||
| darbelo | Pigeons? | 20:11 | |
| purl | Pigeons on the grass, alas. | ||
| Austin | Okay. What was I doing when all this started? | 20:13 | |
| Oh yes, name collisions. | |||
| whiteknight | Austin's train of thought: 30 minutes late | ||
| Austin | Still better than flying. | 20:14 | |
| whiteknight | and on that note, I'm leaving. Later | ||
| Austin | purl, msg jrtayloriv There was an interesting discussion on name lookup today at about 18:38 UTC. irclog.perlgeek.de/parrot/2009-09-28#i_1548640 - there's an imcc bug that stands in the way, but function call's are supposed to look in lexical vars and then package. This should make the library issue easier to deal with. | 20:17 | |
| purl | Message for jrtayloriv stored. | ||
| darbelo | Are the "GDB functions" in src/debug.c used by anyone? | ||
| bacek | Good morning | 20:21 | |
| purl | Here I am, brain the size of a planet, and all they say is 'Good Morning' | ||
| darbelo | Hmm. Is src/debug.c used by anyone? | 20:22 | |
| NotFound | darbelo: by parrot_debugger, mainly | 20:23 | |
| darbelo | The second question was retorical :) | 20:24 | |
| jrtayloriv | Austin, I'm here. And I've been trying to follow it. Just didn't want to interrupt the conversation and kill the momentum by having people explain simple things to me ... I'm slowing going through each thing that was said and trying to grok. | ||
| darbelo | It was meant to be a commentary on the state of our debugging facilities :) | 20:25 | |
| Austin | Ok. I wanted to make sure you were aware of it. | ||
| darbelo | rt? | ||
| purl | rt is just RT (bestpractical.com/rt) or (:rt3) or (: rt bugs) or Obra's trouble ticketing system or the first IBM RISC workstation (www.contrib.andrew.cmu.edu/~shadow/ibmrt.html) or the bombsquad or the Right Thing or very very capable and open-source or an application framework that bundles a ticketing system or obra's baby or SOOOO slow :-S or email mailto:perlbug-owner@perl.org for access | ||
| jrtayloriv | Yes, thank you. | ||
| NotFound | darbelo: I located several problems using parrot_debugger | ||
| bacek | seen fperrad | ||
| purl | fperrad was last seen on #parrot 6 hours, 36 minutes and 36 seconds ago, saying: pmichaud, have you seen my message about parrot_nqp ? | ||
| Austin | Did you make any progress on the lexpad thing? | 20:26 | |
| bacek | msg fperrad I can't build latest Lua. make: *** No rule to make target `t/lua-TestMore/src/Test/More.lua', needed by `Test/More.pir'. Stop. | ||
| purl | Message for fperrad stored. | ||
| jrtayloriv | Austin, I've been doing a lot of reading, trying to make sure I understand how LexPads and DynLexPads work. So actual code written, no, but the reading is starting to at least help me understand the problem better. | 20:27 | |
| Austin | ok | 20:28 | |
| pmichaud | I'm not sure that DynLexPads have ever been really "working" | ||
| afk for a bit | |||
| jrtayloriv | Austin, When you said "the library issue" in your message, you are referring to the library of builtins (like 'define', 'set!', etc) that I'm trying to include at startup correct? | 20:30 | |
| einstein | how can i add "include path" for load_bytecode via the console cmd? | 20:31 | |
| NotFound | einstein: load_bytecode uses lib path, not incldue path. | 20:32 | |
| Austin | jrtayloriv: exactly. | ||
| jrtayloriv | ok, just wanted to make sure you were talking about something else I had missed :) | 20:34 | |
| fperrad | ping bacek | ||
| purl | I can't find bacek in the DNS. | ||
| bacek | fperrad: pong | ||
| einstein | hmm oops i gave it a faulty path :) | 20:35 | |
| fperrad | bacek, t/lua-TestMore is a git submodule | 20:36 | |
| take a look on doc/running.pod, there are some instructions | |||
| bacek | fperrad: thanks, looking | ||
| fperrad: (tt#1067) it's failing in t/pmc/userdata for you, isn't it? | 20:38 | ||
| fperrad | bacek, failures on thread.t, thread_hll.t & userdata.t | 20:40 | |
|
20:40
ash_ joined
|
|||
| bacek | fperrad: hmm... PMC_metadata contains garbage... | 20:41 | |
| kyle_l5l | bacek, freeze/thaw of PMCs with metadata gives me trouble | 20:46 | |
| darbelo | The code handling freeze/thaw of PMCs needs the application of fire. | 20:48 | |
| bacek passing flamethrower to darbelo | 20:50 | ||
| darbelo | kyle_l5l: what kind of trouble? | 20:52 | |
| bacek | fperrad: LuaFunction.init looks suspicious. attrs->env stays uninitialised. | 20:53 | |
| fperrad: but id doesn't matter. Still failing... | 20:54 | ||
| kyle_l5l | trouble when cloning libraries and objects. I think that if a PMC has metadata, and something in the metadata has metadata, that causes trouble. | ||
| darbelo | kyle_l5l: do you have an easily-reproducable example? | 20:56 | |
|
20:57
bluescreen joined
|
|||
| kyle_l5l | darbelo, it's reproducible, but it's pretty messy. I'll see what I can do. | 20:58 | |
| NotFound | In LuaFunction getfenv method if (!retval) must not be if (PMC_IS_NULL(retval)) ? | ||
|
20:59
theory joined
|
|||
| darbelo | Nopaste it. I can deal with messy. | 21:00 | |
| I think. | |||
| kyle_l5l | darbelo, sure. but first I must deal with more pressing issues: pizza. | ||
| ash_ | would it be working considering writing a pmcc2cc (C++ version of PMC) ever? just curious | 21:04 | |
| bacek | ash_: probably no. | 21:06 | |
|
21:07
joeri left
|
|||
| ash_ | don't think it would be useful? not even if you ever wanted to link to a C++ library? | 21:07 | |
| NotFound | ash_: What problem are you trying to solve? | 21:09 | |
| ash_ | thinking about linking to LLVM, there are C bindings but they are not at all as easy to use or understand | ||
| darbelo | ash_: You want c++ in the VTABLE and METHOD bodies. Right? | 21:11 | |
| NotFound | VTABLE functions are static, they haven't decoration or linkage problems. | 21:12 | |
| darbelo | NotFound: He's working with a pure c++ api. no extern "C". | 21:13 | |
| He wants to call c++ from inside the vtable. | 21:14 | ||
| NotFound | Bad luck, then. | ||
| I think the policy since long time had been to not require C++ | 21:15 | ||
| darbelo | I would write the code that should go into the VTABLE in a separate file, compile it with c++ (but with extern "C") and make the VTABLE call that code. | 21:16 | |
| jrtayloriv | Anyone here who knows scheme and Perl 6? These two are pretty much equivalent, right? pastebin.com/d6af651c9 | 21:17 | |
| chromatic | I'd change "eval '$a'" to "return $a", but they should otherwise be equivalent. | 21:19 | |
|
21:19
bluescreen joined
|
|||
| jrtayloriv | ok, thanks. | 21:19 | |
|
21:20
hercynium joined
|
|||
| bacek | NotFound: src/gc/api.c lines 260-261 looks suspicious. How we can have metadata without is_special set? | 21:23 | |
| NotFound | Don't know, but if there are no metadata, it doesn't harm. | 21:27 | |
| chromatic | Hm, mark_special() marks the metadata unilaterally, even if there's no (defined) pointer there. | ||
| src/gc/mark_sweep.c:420 | |||
| pt_shared_fixup() in src/thread.c can add metadata without setting the special flag. | 21:28 | ||
| make_prop_hash() in the default PMC doesn't set the special flag. | |||
| darbelo | src/gc/mark_sweep.c:420 was me. That used to be done in a separate pass over the next_for_GC linked list. | 21:29 | |
| chromatic | the Undef PMC's set_pmc() undoubtedly has a bug where it doesn't propagate PMC metadata (line 51). | 21:30 | |
| NotFound | Parrot_gc_mark_PMC_alive already check for nullness | 21:31 | |
|
21:34
Whiteknight joined
|
|||
| darbelo | There's no need for the check in src/gc/api.c then | 21:35 | |
| chromatic | Right. | ||
| We can simplify that control flow. | |||
| pmichaud | is it just me, or has parrot's backtrace become suddenly much less useful? | 21:37 | |
| Whiteknight | pmichaud: why do you say that? | ||
| purl | Because ey thinks it is true. Duh. | ||
| pmichaud | the backtrace lines seem to always identify the line number of the start of the sub, instead of the line that was being executed | 21:38 | |
| nopaste coming | |||
| nopaste | "pmichaud" at 72.181.176.220 pasted "backtrace example" (13 lines) at nopaste.snit.ch/18101 | ||
| chromatic | I'm sure there are bugs. IMCC's line counting has a really bad heuristic. | ||
| pmichaud | it's not just bugs... it's radically different | ||
| NotFound | Is fast the default runcore now? | 21:39 | |
| pmichaud | for example, in the nopaste, the first "called from" line says Compiler-Regex.pir:241 | ||
| chromatic | Yes. | ||
| pmichaud | that's the beginning of the "quant" sub itself | ||
| previously Parrot would give me the line number _within_ the quant sub | |||
| same for the other line numbers given in the backtrace | 21:40 | ||
| they all point to the beginning of the sub, instead of the line that sub was executing at the time the exception is raised | |||
| NotFound | I think is the runcore | ||
| pmichaud | ah, so fast core only tells me the line number of the sub? | ||
| chromatic | I don't think it's the runcore; the context's pc should always be accurate. | 21:41 | |
| pmichaud | let me see if I can come up with a short example | 21:42 | |
| chromatic | The only difference between the fast and slow runcores is that the slow runcore updates the interp's pc for every op dispatch. | ||
| pmichaud | hmmm | 21:44 | |
| I'm not having the issue for a short example | |||
| I'll try another | 21:45 | ||
| NotFound | It may be only when entering new runloops from vtable calls. | ||
| pmichaud | I'm not doing anything funny like that; this is pretty straightforward PIR | 21:46 | |
| weird... I don't seem to be able to duplicate it with a simple example. I'll keep an eye out for it, though. | 21:47 | ||
| chromatic | I plan to fix line number reporting soon anyway. | 21:48 | |
| NotFound | pmichaud: ops use vtable calls, and these enter new runloops for vtable overrides | 21:49 | |
| Whiteknight | how does parrot store line numbers anyway? | 21:50 | |
| darbelo | badly :) | ||
| chromatic | Ugly. | ||
| Whiteknight | do tell | ||
| pmichaud | NotFound: I know that. I'm not using any ops that rely on vtable calls. | 21:51 | |
| chromatic | src/sub.c lines 242 - 266 | ||
| (we can fix that entire counting mess if we have a counter for "number of ops executed in the current segment") | |||
| NotFound | chromatic: that part is not speed critical | 21:56 | |
| Whiteknight | oi! that's horrible | ||
| chromatic | I wouldn't make that argument on speed alone. | 21:57 | |
| NotFound | Whiteknight: is better that try to guess backwards where the previous opcode starts. | ||
| Whiteknight | NotFound: it might be better then that, but it's still not good | ||
| NotFound | Whiteknight: I know, I try to find a better way months ago but failed. | 21:58 | |
| chromatic | We could use a binary heap instead of an array. | 22:00 | |
| Or even a binary tree implemented as an array. | |||
| We don't modify segments after generation. They're effectively read-only. | 22:01 | ||
| Store the annotation information by offset from pc to base.data. | |||
| It uses as much storage as currently, but we don't do weird math and we don't have O(n) lookup. | 22:02 | ||
| What's that, O(log n)? | |||
| nopaste | "darbelo" at 200.49.154.173 pasted "unconditionally call Parrot_gc_mark_PMC_alive on metadata. All tests pass." (67 lines) at nopaste.snit.ch/18103 | 22:04 | |
| NotFound | I don't see a need to speedup that thing. Is used only for reporting errors, isn't it? | ||
| chromatic | It's not about speed, though. (But it does slow down the profiling core a bit.) | ||
| NotFound | Uh, forgot the profiling core | 22:05 | |
| chromatic | For me it's all about the "Wow, that's ugly code -- surely there's a better way!" | 22:06 | |
| Whiteknight | I definitely don't like how it shadows pc | 22:17 | |
|
22:19
cotto_work joined
22:22
bacek joined
|
|||
| chromatic | Sometimes I wonder what happened when my super technical musings completely derail all conversation in the channel. | 22:27 | |
| darbelo | bacek: nopaste.snit.ch/18103 | 22:32 | |
| less suspicious or more? | 22:34 | ||
| chromatic | A little less, but.... | ||
| ... I'd rather flip the "is special" flag whenever we attach metadata. | |||
| Most PMCs don't have metadata. | |||
| We always have to check that flag, which is fine. | |||
| Only in that codepath should we check if there's metadata and then mark it. | |||
| darbelo | So, a non-special PMC should never have metadata? | 22:35 | |
| chromatic | Any PMC with metadata should have the special flag set. | ||
|
22:36
ruoso joined
|
|||
| darbelo | The calls outside of mark_special were workarounds for mismanagement of the special flag, right? | 22:37 | |
| chromatic | I don't know. | 22:38 | |
| I'm still not sure about the intent of the special flag. | |||
| Whiteknight | it was used to determine the existance of PMC_EXT for a while | 22:39 | |
| and maybe _sync too | |||
| NotFound | Will not be easier to drop the special flag, and check all relevant flags in the is_special_PMC_TEST macro? | 22:42 | |
| Whiteknight | I think it will be, yes | 22:43 | |
| chromatic | Works for me. | ||
| bacek | msg fperrad I don't quite understand curr_func in LuaUserdata.pmc. Looks like it trying to fetch "env" field from ordinary Parrot's Sub. | ||
| purl | Message for fperrad stored. | ||
| chromatic | We could add a has_metadata flag too. | 22:44 | |
| NotFound | Will be significant difference between checking the flag and checking the pointer? | 22:45 | |
| bacek | msg fperrad Indeed. It returns some garbage and GC epicly failing during mark. | 22:47 | |
| purl | Message for fperrad stored. | ||
| nopaste | "darbelo" at 200.49.154.173 pasted "Amusingly, this passes all tests too." (22 lines) at nopaste.snit.ch/18104 | 22:48 | |
|
22:51
cconstantine joined
|
|||
| bacek | ok, $dayjob time | 22:51 | |
| see you soon | |||
|
22:53
patspam joined
|
|||
| NotFound | darbelo: that probably only means that in the test suite the metadata is always in special PMC. So we need more tests. | 23:00 | |
| darbelo | NotFound: yeah, I would expect partcl to blow up horribly with that patch. But it shows how much the test-passiness of my previous attempt was worth. | 23:03 | |
|
23:04
rhr joined
23:07
payload joined
23:08
payload1 joined
|
|||
| darbelo | NotFound: The question here is, if there's metadata on that PMC why isn't it special? | 23:12 | |
| chromatic | I looked at all instances of attaching metadata and none of them toggle the special flag. | 23:13 | |
| NotFound | My question is: did we really need that lot of macros for PObj flags? Looks like there is a lot of redundancy. | 23:14 | |
| darbelo | Hmm. We could detach the 'bears metadata' meaning from the special flag and fo "Look! Metadata!" and mark it. | 23:15 | |
| We're halfway there already. It'd be a pretty minimal change. | 23:17 | ||
| NotFound | The current code looks like: if is special, look for metadata. If not, look for metadata. | ||
| chromatic | Yeah, the current code is wrong in a lot of ways. | ||
| cconstantine | Tene: can you describe what 'library', 'export', 'import' and 'hll' do in stene? Or maybe throw me at some docs (I couldn't find any)? | ||
| darbelo | NotFound: Exactly, we could just say 'look for metadata' and leave the special flag out of it. | 23:18 | |
| NotFound | chromatic: maybe we must centralize all that instances in a function. | 23:19 | |
| chromatic | Remember though that I'd like to make the marking code as straightforward and fast as possible. | 23:20 | |
| That means checking as few flags as possible and branching as few times as possible. | |||
| NotFound | chromatic: getting the flags one time and switchIf on it? | 23:21 | |
| switch or if, I mean | |||
| chromatic | Seems sensible to me. | 23:22 | |
| darbelo was wrong. partcl passed make test with the last nopaste. | |||
| Whiteknight | checking a has_metadata patch doesn't save us anything over just checking whether ->metadata is PMCNULL | 23:29 | |
| or NULL | |||
| s/has_metadata patch/has_metadata flag/ | |||
| cotto_work | did someone break the build on src/byteorder.c? | 23:32 | |
| darbelo | not that I've noticed. | 23:33 | |
| cotto_work | It's perfectly possible that it's just my system that's goofy. The win32 build process isn't quite as fun as on linux. | ||
| NotFound | $Id: byteorder.c 37848 | 23:34 | |
| cotto_work | so it's been a while | ||
| darbelo | msvc or strawberry perl? | ||
| cotto_work | strawberry | 23:35 | |
| purl | strawberry is a Perl for Windows that works just like Perl everywhere else. See win32.perl.org/wiki/index.php?title...berry_Perl | ||
| cotto_work | strawberry is also well how about RAWBERRY | ||
| purl | okay, cotto_work. | ||
| cotto_work | although it also broke when I tried using Strawberry + the msvc setup script from the wiki | 23:36 | |
| Whiteknight | any git heads around? | ||
| darbelo | I'm guessing you used -j on make. | ||
| cotto_work | nope | 23:37 | |
| well, yes then no after -j failed | |||
| darbelo | Then I have no idea why you are borked. | 23:38 | |
| Have you tried rebooting? | 23:43 | ||
| ;) | |||
| dalek | rrot: r41543 | darbelo++ | trunk/src/gc/gc_private.h: Remove duplicated ASSERT_ARGS definitions. |
23:44 | |
| ttbot | Parrot trunk/ r41543 MSWin32-x86-multi-thread make error tt.ro.vutbr.cz/file/cmdout/108271.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) | 23:54 | |
| Whiteknight | FAIL | ||
| darbelo | Was that me? | 23:55 | |
| WTF? | |||
| Whiteknight | well, it wasn't not you | 23:56 | |
| darbelo | Acording to the link it's been broken since 41515. | 23:57 | |
| Same error. So, I'm blaming bacek. | |||
| Whiteknight | bacek is TEH FAILZ | 23:58 | |