On approximately 11/22/2003 5:51 PM, came the following characters from the keyboard of $Bill Luebkert:
Glenn Linderman wrote:
Prelude:
Using Perl 5.8.0 ActiveState build 805 on Windows 2000 SP4
I have this script that is 1.2 MB long.... rather than post the whole thing, I've made a test case... surprisingly I was able to get it down to 60 lines. I guess it could have even been a little smaller...
So I'm writing an interpreter, in Perl, for another language (no, this is a real project, not an attempt to bring a Pentium 4 to its knees). The other language is not available on Windows, and my collection of machines that run it is dying... being about 15 years old and orphaned about 12 years. The basic idea is to provide the building blocks of the other language inside perl as perl functions, and then to translate each syntactical construct of the other language into perl syntax, thus building up a perl function that is functionally equivalent to the function in the other language. The perl functions are first built into strings, and then "eval"ed into existance. Of course, as with all automated translation, the resultant Perl is not particularly beautiful to behold, but it is somewhat decipherable for debugging, and with the source of the other language available, it should be an OK environment.
I have the translator mostly finished, and was starting to attempt to execute some code from the other language (and it is the source code in the other language that is the bulk of the Perl script).
Questions, problems, and misunderstandings:
1) Do the initial "use strict" and "use warnings" apply to the eval'd code, or do I need to include them in each eval'd string as shown? Initially, I didn't generate the "use strict" and "use warnings" into each eval'd string, but after I ran into some problems, I went back and added them. Didn't change the problem. And from what I can read, I think I don't really need to do that, that the eval's should inherit the "use strict" and "use warnings" from the lexical scope in which the eval exists.
2) The variables of interest are all lexicals in the scope of the closure where function foo is defined... $scaler, @array, and %hash. The functions, with strict and warnings enabled, seem to compile fine. But when function eval_printall runs, the variables seem to all be undefined, even though they all have been given values in the code immediately after their creation, and even though those values are visible to function printall. I would expect that either the variables would not be visable at all, and function eval_printall would fail to compile OR (more likely, from my reading of the Camel book) that the function would compile successfully, the variables would be visible, and the values of the variables available. This last seems not to be the case, however.
Does anyone have a clue what is going on here? Is this a perl bug? Do I just need some additional magic option? or what?
Interestingly, if you comment out the line in function eval_printall which prints the scaler, you don't even get a warning message... the variables apparently all appear to be undef, and the way the access to @array and %hash are written, they simply don't have values, so nothing gets printed... without warning. This really confused me last night, and until I made this test case this morning.
Not that I'm not still confused, but if all the variables appear undef, it explains why I got some of the symptoms I got.
3) If this is a bug, or a technical question no one here can answer, what forum should I turn to next?
Pared down test case code:
(you should be able to pipe this message to perl -x to execute the test case)
#!perl -w use strict; use warnings;
{ my ( $scaler, @array, %hash );
This should change the results:
our ($scaler, @array, %hash);
or a use vars instead. Another solution would be to move the call to foo () up a line into the enclosing block or remove the enclosing block {} you have around all of your code.
Yes, there are a variety of workarounds. Just moving the variable definitions out of the closure "works", but then it is prone to conflicts with names in other parts of the program (in the real program, not the test program. Once I resolved those conflicts, I'm making progress on the rest of the real program). Which is why I put them inside the closure in the first place.
But...
Should it work as is? If not, why not? I can't find any documented reason why it shouldn't work, and I do find references in Camel that imply that eval'd code inherits the lexical scope at the point of the eval. And it seems to see the variables, just not their values...
-- Glenn -- http://nevcal.com/ =========================== Like almost everyone, I receive a lot of spam every day, much of it offering to help me get out of debt or get rich quick. It's ridiculous. -- Bill Gates
And here is why it is ridiculous:
The division that includes Windows posted an operating profit of $2.26 billion on revenue of $2.81 billion.
--from Reuters via http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html
So that's profit of over 400% of investment... with a bit more investment in Windows technology, particularly in the area of reliability, the profit percentage might go down, but so might the bugs and security problems? Seems like it would be a reasonable tradeoff. WalMart earnings are 3.4% of investment.
_______________________________________________ Perl-Win32-Users mailing list [EMAIL PROTECTED] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
