Re: thinking about variable context for like()
Mark Stosberg wrote in perl.qa : I'm frequently using 'like' to test $agent-content against a regular expression. When I have a lot of these in a new test script and they are all failing, I get a boatload of HTML source floating by, which makes it tedious at times to find out what actually went wrong. I would like a way to tune the amount context that like presents upon failure. For example, the first 1000 characters of the HTML source would do most of the time. I'm not sure what the best way to do this might be. For now, I'll stop at merely suggesting something like this might be useful. :) Write your own test module on top of Test::Builder / Test::More. I faced a similar problem with is() for very long strings and/or strings that may contain non printable characters : http://search.cpan.org/~RGARCIA/Test-LongString-0.02/lib/Test/LongString.pm Now, it seems like your proposed long-string friendly like() is something that could go in Test::LongString. Patches welcome, of course, but I may look at implementing this myself. Other suggestions ?
RE: Calling conventions. Again
At 11:57 AM -0500 11/14/03, Gordon Henriksen wrote: Melvin Smith [EMAIL PROTECTED] wrote: The easy situation is when argument counts change, but the hard situation is when semantics have changed. In that case we have to have some sort of version requirement in the bytecode. Best practice I've seen for this is to have a library advertise 2 version numbers: Compatible version, and current version. When searching for a library to link with, the compatible version must match, and of those the latest current version wins. These versions are usually integers unrelated to the version number of any particular product. -- But maintaining these puts a lot of faith in the library's author. Putting full faith in library authors has, historically, been ill-advised in the general case, but we can do some things to help that out and let folks have at least a chance of getting things right. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Calling conventions
Okay, I've lost any free time I might have and the discussion's gotten to the point where it's obvious that we're not going to get anywhere. So, this is what we're going to do: 1) The changes I proposed are going in. We get arg counts for I/S/N registers if they're used. Everyone can cope. (You may, if you choose, whine about it for a bit--that's OK, if somewhat unbecoming) 2) I'm adding in an alternate, link-time, non-overridable subroutine call sequence. This is for routines which may not change in any way at runtime. They may or may not be sub-PMC based. Probably not. This will cause some issues with perl/python/ruby code that would choose to manipulate the subs, but there are ways around it, and people can cope. 3) We're going to add some metadata (virtually to start) to note library versions, sub signatures, and whatnot so we've some chance of catching signature errors (which usually indicate a deeper versioning problem) at link and, hopefully, runtime. Not much more to say about #1 than I disagree, and I think we've dealt with that problem. #2 will introduce, I think, a: call X, Y op, where X is the start of the bytecode to call and Y is the bytecode segment header, or something like that. *NOTE THAT THIS IS NOT SET IN STONE!* or mud even. I'm fine with a completely different format. Anyway, X and Y are resolved at link time which, for us, is bytecode load time. (Unless we bring in a linker. Maybe for V2) Since these are essentially addresses which are resolved at link time there's no way that they can be overridden, which is arguably a Bad Thing. Certainly will get in the way of folks looking to do exactly that. Well... too bad. Wrap the non-overridable version in an overridable version and be done with it. #3 is going to be important so we can have signatures that we can reliably mark as non-overridable (though I suppose just properties on the sub PMCs that the compiler can note is OK. Still, we need to define those), floor values for library versions so people can note breaks in compatibility, signatures on functions and subs, *versions* on subs and functions (potentially) all will be useful to make sure that we can, hopefully, have some chance of noting that things have changed. Oh, and we need to make sure that the global stash that we're using to store subs checks function signatures when existing subs/methods/whatever are overridden, because we need to be able to pitch a fit if that's the case, even if we don't complain by default. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Calling conventions
Dan Sugalski wrote: 1) The changes I proposed are going in. We get arg counts for I/S/N registers if they're used. What purpose do these individual I/S/N arg counts serve exactly? To simply check how many arguments are passed to a function you would need to get the sum of the number of I/S/N/P argument counts. This is needlessly complicated and slow. And that's just the beginning of the fun - variable argument functions simply cannot be written using this calling convention - just think of the issues with argument ordering, default arguments and type promotion. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: Calling conventions
At 4:00 PM -0800 11/16/03, Joe Wilson wrote: Dan Sugalski wrote: 1) The changes I proposed are going in. We get arg counts for I/S/N registers if they're used. What purpose do these individual I/S/N arg counts serve exactly? You missed a bit when quoting. This bit, specifically: Everyone can cope. (You may, if you choose, whine about it for a bit--that's OK, if somewhat unbecoming) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[COMMIT] IMCC gets high level sub call syntax
Various people have bugged me about this for a long time so I figured it was time, since it was the logical next step in hiding the Parrot calling convention implementation details. I've patched in initial support for IMCC to compile high level sub calls. 0, 1 and multiple return values are supported, but I didn't add flattening support yet as I'm not sure what syntax to use. The following works: _foo() var = _foo() var = _foo(a, b) (var1, var2) = _foo(a, b) (var1) = _foo(a, b) # redundant but supported Notes: * Since this is intermediate language, not HL, arguments to the subs must be either variables or single constants, NOT expressions. * Currently this syntax expects the sub name to be an IDENTIFIER. I'll add a syntax for calling a sub in a variable and possible by name (string constant). * IMCC will default the subs calls to prototyped for now. Currently our calling convention code is a bit broken, but the prototyped version works well. I've attached a couple of working samples. Cheers, -Melvin # Sample 1 .sub _main .local int i .local int j .local string s i = 7 $I1 = 8 s = nine I0 = _foo(7, 8, nine) print return: print I0 print \n end .end .sub _foo .param int i .param int j .param string s print i print print j print print s print \n .pcc_begin_return .return 10 .pcc_end_return .end # Sample 2, multiple return values .sub _main .local int i .local int j .local string s i = 7 $I1 = 8 s = nine (I0, I1) = _foo(7, 8, nine) print return: print I0 print print I1 print \n end .end .sub _foo .param int i .param int j .param string s print i print print j print print s print \n .pcc_begin_return .return 10 .return 11 .pcc_end_return .end
Re: Calling conventions
At 07:51 PM 11/16/2003 -0500, Dan Sugalski wrote: At 4:00 PM -0800 11/16/03, Joe Wilson wrote: Dan Sugalski wrote: 1) The changes I proposed are going in. We get arg counts for I/S/N registers if they're used. What purpose do these individual I/S/N arg counts serve exactly? You missed a bit when quoting. This bit, specifically: Everyone can cope. (You may, if you choose, whine about it for a bit--that's OK, if somewhat unbecoming) Rather than whining, I'm reworking IMCC so we can support multiple parallel calling conventions and select a specific one by a pragma. We can then do side-by-side benchmarks of the same code and play around without breaking existing high level languages. Once I'm done you won't even be able to see the calling convention from IMCC, except in cases where you really want to. (see my last 2 patches) -Melvin
Re: [COMMIT] IMCC gets high level sub call syntax
Various people have bugged me about this for a long time so I figured it was time, since it was the logical next step in hiding the Parrot calling convention implementation details. I've patched in initial support for IMCC to compile high level sub calls. 0, 1 and multiple return values are supported, but I didn't add flattening support yet as I'm not sure what syntax to use. The following works: _foo() var = _foo() var = _foo(a, b) (var1, var2) = _foo(a, b) (var1) = _foo(a, b) # redundant but supported Like the idea of this. Nice! :-) Notes: * Since this is intermediate language, not HL, arguments to the subs must be either variables or single constants, NOT expressions. * Currently this syntax expects the sub name to be an IDENTIFIER. I'll add a syntax for calling a sub in a variable and possible by name (string constant). * IMCC will default the subs calls to prototyped for now. Currently our calling convention code is a bit broken, but the prototyped version works well. I've attached a couple of working samples. Please may I suggest/request that you pop them in the imcc/examples directory? There's very little in there as it stands; it'd be nice to at least put examples in that demonstrate things that are going into IMCC from here on. :-) snip i = 7 $I1 = 8 s = nine I0 = _foo(7, 8, nine) Please can you explain to me why that last line is not:- I0 = _foo(i, $I1, s) snip .pcc_begin_return .return 10 .pcc_end_return If you're plan is hiding the Parrot calling convention implementation details, should that just not be .begin_return .return 10 .end_return Or is there any reason not to do:- return (10) My apologies in advance if I'm way off on any of this stuff. Thanks, Jonathan
IMCC problems with library loading
I've run into a couple of issue with library loading which have their
origin down inside the IMCC code:
1) External libraries are being loaded at parse time.
Inside of INS() in imcc/parser_util.c, Parrot_load_lib() is called at
parse-time when loadlib is encountered. This is causing libraries to be
loaded twice (once at parse-time and once at run-time), which is a
problem in its own right, but it also just seems like generally the
wrong behavior.
2) Code which tries to instantiate a dynamically-loaded PMC fails to
parse.
Code such as this:
loadlib P1, foo
new P0, .Foo
fails to parse, because .Foo is being interpreted as a macro. For
example:
% ./parrot dynclasses/dynfoo.pasm
error:imcc:unknown macro '.Foo'
in file 'dynclasses/dynfoo.pasm' line 7
The problem seems to be the following code, which interprets .Blah as
a macro if Blah isn't an already-registered type:
imcc/imcc.l line 337:
emit,INITIAL{DOT}{LETTER}{LETTERDIGIT}* {
int type = pmc_type(interp, string_from_cstring(interp,
yytext+1, 0));
if (type 0) {
char *buf = malloc(16);
sprintf(buf, %d, type);
valp-s = buf;
return INTC;
}
if (!expand_macro(valp, interp, yytext+1))
fataly(1, sourcefile, line, unknown macro '%s', yytext);
}
I can't find any definitive docs on the macro syntax, so I don't know
if this is pointing out a true ambiguity in the grammar (since
dynamically-loaded PMC types won't be known at parse-time, before the
library defining them is loaded), or if macro usages are always
supposed to have argument-syntax, such as .Blah(), which would mean
that this is just a problem with the parser. There's no example in
t/op/macro.t without parentheses, so I'm thinking it's the latter.
JEff
Re: [COMMIT] IMCC gets high level sub call syntax
At 01:45 AM 11/17/2003 +, Jonathan Worthington wrote: I've attached a couple of working samples. Please may I suggest/request that you pop them in the imcc/examples directory? There's very little in there as it stands; it'd be nice to at least put examples in that demonstrate things that are going into IMCC from here on. :-) Absolutely, I'll do that. snip i = 7 $I1 = 8 s = nine I0 = _foo(7, 8, nine) Please can you explain to me why that last line is not:- I0 = _foo(i, $I1, s) You are correct. I was just toying around with variables and constants and happened to leave that sample as it was when I last tested it. I'll fix it before I commit it. snip .pcc_begin_return .return 10 .pcc_end_return If you're plan is hiding the Parrot calling convention implementation details, should that just not be .begin_return .return 10 .end_return Or is there any reason not to do:- return (10) Absolutely correct. I guess it might not be apparent that I'm phasing stuff in/out little by little. I can't remove the .pcc* directives right now as that will break existing compilers, and I don't typically have the time in one sitting to do a full sweep and implement all the features, so I try to do my commits at logical stopping points and add features in digestible quantities. If I try to implement too much at one time, there is high probability that I'll either break existing stuff, or get so far down the path, then someone will submit a huge patch that won't be compatible and I have to backtrack. I try to sync up daily. That is just my style, which is why you will see me frequently commit unimplemented stubs or messy code with FIXME comments all over the place. My apologies in advance if I'm way off on any of this stuff. Nope, you are right on, you're just looking ahead, which is good. :) -Melvin
Re: Calling conventions
I'll admit I sometimes can't think that far ahead to see all of the problems, but when I have problems sitting in front of me, I can usually solve them. The situation we have now is: Parrot is a VM, and technically we could just punt the whole calling convention issue to a high level languages forum (parrot-languages if there was one) or something, but sadly that wouldn't work, because currently there aren't enough people to go around. What we really need is for some languages group to step up and start a working paper on the possible high level constructs that will present potential issues for Parrot, and show some potential solutions for compiling them, and look at those issues when related to maintaining backwards compatibility for old bytecodes. The paper should probably be language specific. I do like Tim's suggestion of multiple entry points for a given sub in a module, but rather than discuss it much further, I'd like to be presented with a clear sample and clear requirements beforehand. I also do not think the Parrot core developers should have to take responsibility of every possible issue because one language's issues are not an issue for another. The questions is, how much do we specify as a Parrot Standard as opposed to a language specific standard. I see 2 possible paths, both equally viable for us to take. a) Parrot Standard specifies that all bytecodes will be compatible with both prototyped calls and non-prototyped calls, and all high level languages on Parrot will just magically work together, even though the code will probably be a lot fatter. b) Parrot Standard specifies what conventions are _available_, but not which to use. If a high-level language lends itself to prototypes and high levels of optimization, it should not have to suffer. Let library writers write glue code, as they do now, if they wish to interact between languages. Glue code might be as simple as defining certain entry points (subs) as unprototyped. As far as requirements, I don't know whether it is (a) or (b) or neither. Sometimes requirements are a luxury, but its hard for a group of open source developers to get much done without any, and in this case I think we really need them. I like (b) because it is more flexible, and actually accomplishes the same goal in (a), but lets the developer decide when and where it makes sense to work together. -Melvin
RE: thinking about variable context for like()
I would suggest something along the lines of: like_html(actual_value, expected_regex, max_chars_to_output, string_description); You could probably steal most of the code for this from Test::More's like function and add in the functionality for outputting less than or equal to max_chars_to_output if the actual_value does not match the expected_regex. That's just my 2 cents. Toodles, ~~Andrew -Original Message- From: Rafael Garcia-Suarez [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2003 6:43 AM To: [EMAIL PROTECTED] Subject: Re: thinking about variable context for like() Mark Stosberg wrote in perl.qa : I'm frequently using 'like' to test $agent-content against a regular expression. When I have a lot of these in a new test script and they are all failing, I get a boatload of HTML source floating by, which makes it tedious at times to find out what actually went wrong. I would like a way to tune the amount context that like presents upon failure. For example, the first 1000 characters of the HTML source would do most of the time. I'm not sure what the best way to do this might be. For now, I'll stop at merely suggesting something like this might be useful. :) Write your own test module on top of Test::Builder / Test::More. I faced a similar problem with is() for very long strings and/or strings that may contain non printable characters : http://search.cpan.org/~RGARCIA/Test-LongString-0.02/lib/Test/LongString.pm Now, it seems like your proposed long-string friendly like() is something that could go in Test::LongString. Patches welcome, of course, but I may look at implementing this myself. Other suggestions ?
Re: Calling conventions
My unanswered question below was legitimate, but if you insist... Perhaps another register can hold the number of problems with this calling convention. rim shot Dan Sugalski wrote: 1) The changes I proposed are going in. We get arg counts for I/S/N registers if they're used. What purpose do these individual I/S/N arg counts serve exactly? You missed a bit when quoting. This bit, specifically: Everyone can cope. (You may, if you choose, whine about it for a bit--that's OK, if somewhat unbecoming) __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
