Re: Python method overloading
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: Sam Ruby [EMAIL PROTECTED] wrote: [ snipped - all ok } If I define an __add__ method with 16 arguments, Python will not throw an exception. I didn't write that. I've said: *if* you call it via a + b, Python throws an exception - that one I've shown. Anyway... What you wrote (and snipped) was I'd say, if you define an '__add__' method with 16 arguments, Python will throw an exception,... To which I responded with the above. and after the snipped ellipsis my sentence did continue with if you try to use C+ with an object of that class: You are still not getting the principal of the scheme, IMHO. It has nothing to do with Perl6 or any other language, nor with Python. Either that, or I *am* getting the principle of the scheme. I guess that this is the point where I need to return back to writing code and test cases. Leo - at one point you indicated that you might be interested in helping to factor out the common code again. Sure, and I'm not stopping that. The overall conclusion of (even infix operator) method lookup was that it has to be done at runtime. It is up to the PMCs to provide a proper and language-specific find_method to locate the involved operation, MMD or not. And the runcore is responsible for calling the method. While you seem to admit that it has to be done at runtime you are doubting that it can be done fast and you are rolling your own incompatible dispatch scheme (how should that be faster then?). This made me utter above sentence. Further: The function signature of overloaded infix operations (and maybe others) is currently not appropriate for Python (and likely other languages). - Sam Ruby leo
Re: Devel::Cover cover command uses to much memory
Hi, On Wed, 8 Dec 2004 13:37:14 -0500, Michael G Schwern [EMAIL PROTECTED] said: On Tue, Dec 07, 2004 at 07:21:09PM -0800, Jason Remillard wrote: I ran the codestriker (http://codestriker.sourceforge.net/) test set using Devel::Cover. The test cases ran over a day and a half and generated a cover_db directory that is 127 megs. Attempting to run the cover command keeps using up all of the available memory causing cover to be killed by the OS. I have my swap file up to 1 gig, and after two days of the computer swapping its brains out, it still was not enough memory. How big is this test suite? How long does it usually take to run? Just trying to get an order-of-magnitude feel here. I have a really old system. It takes about 1.5 hours normally for the short version that I ran cover on. On a new computer, it would probably be 20 minutes or so. The cgi script would be invoked at 1,000-2, thousand times. This is the short test set, the full test set takes about 14 hours on my computer. I really don't mind the overhead while running the tests, the real killer is that cover keep using up all of the memory and getting killed before it can generate the html report. Even this, if I need to wait a day, it is ok. Lastly, some documentation on how to use with with a normal cgi script would be helpful. The way I finally got it to work was to rename codestriker.pl (the main cgi perl script), to codestriker_test.pl. Write a new codestriker.pl that just does a system call with the Devel::Cover switch. Perl would not let me add it to the #!/usr/bin/perl line at the start of the script. I would be interested in knowing if a cleaner way is possible, as this is kind of lame. You just have to say use Devel::Cover in your program. That's what -MDevel::Cover means. Ah, I knew I was missing something obvious, thanks!. It would be good to put that in the docs, as I missed that. Thanks Jason
Re: svn
William Coleda wrote: I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, Hi, I'm currently working on moving the implementation of the PerlHash PMC into a Hash PMC. The plan is to let PerlHash be an extension of Hash. Currently there are still some problems with regard to dumping and freezing. When these problems are resolved, I'll try to switch the Parrot core to using the Hash PMC internally. I'll try to provide a patch this weekend or next week. CU, Bernhard -- ** Dipl.-Physiker Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Re: continuation enhanced arcs
[EMAIL PROTECTED] wrote: What this means is that care must be taken when you are writing code that you expects to be invoked multiple times. However, if you are a function that on your second invocation returns via the continuation from you first invocation, you should probably expect to be called again because it happened the first time! The contentious point is precisely that there is no way to tell at the compile time that you will be invoked multiple times. If something you pull from a library or a callback passed to you captures the continuation, you may notice that your return continuation had been promoted, but at that point it's already too late to kill all I/N/S register usage and to double-reference all PMCs. Of course, unless you keep the original AST and keep recompiling it to PIR. I'd argue that it's vastly more complex and error prone than Leo's solution he refered to in his post. It's also no better than refetching all lexicals. Also, note that return-continuation-restores semantics is simply a (possibly premature) optimisation in its own right. CPS is supposed to treat every continuation the same (which turned out to be inefficient), and then return continuations were added to simplify the most common case. So, while return continuation is unpromoted, it's perfectly okay for it to behave any way it wants. Once it does get promoted, I'd argue that it should behave like a normal continuation first because it's more practical (see above) and second because that way it doesn't break CPS semantics. Miro
Re: svn
On Wed, Dec 08, 2004 at 06:21:18PM -0700, Phil Frost wrote: On Wed, Dec 08, 2004 at 07:19:07PM -0500, William Coleda wrote: Is there a plan at any point to move to an svn repository from cvs? I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, and I'll happily wait for svn if we're going that way, since it'll be smoother. If you are planning on switching revision control systems, I suggest something other than svn. There are a number of other systems available to the free software developer which offer serious advantages which might not be aparent to those who have not experienced them. Among them are arch, darcs, and monotone. Arch is out. Its Win32 support is crap. http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support monotone is out. Its too unstable. They just made an incompatible change requiring *lossy* migration. http://www.venge.net/monotone/README.changesets This leaves just Darcs. I would eshew Darcs for a large, Open project for these reasons. * Its immature. What happens if we hit a bug and wedge the repository or worse, corrupt it? What happens if they introduce an incompatible change as monotone did? * We don't have any Darcs experts to solve the hard problems. * The darcs manual proudly proclaims Darcs is refreshingly different from CVS. Because of the different models used by cvs and darcs, it is difficult to provide a complete equivalence between cvs and darcs. Parrot has a lot of CVS users. They do not want refreshingly different. However, this does not mean distributed version control is out. There is an option. SVK. Its distributed version control WITHOUT everybody having to learn and run SVK. SVK is a *client* of a Subversion (or CVS or Perforce) repository. This means Parrot can switch to Subversion and those that want to play with distributed version control can do so without everybody else having to drink their brand of Kool-Aid. For reference, here's the gauntlet I'd make any new revision control system for Parrot run through. 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? 2) Can the command set and workflow be made similar to CVS? You're going to have enough trouble convincing people to leave the warm, familiar, comforting, if slightly demented, embrace of CVS that they have known for years. Its best if the new system works as much like CVS as possible. 3) Do we need distributed version control? Can this be gotten without having to drink their brand of Kool-Aid, such as by individuals using SVK over a Subversion repository? 4) Are these systems mature enough that they're not going to fall apart under a large repository? Or that we don't have to worry about hitting a bug which corrupts the repository or gets it into an inconsistent state? Or that they'll introduce an incompatible change? 5) Do we have any experts with these new version control systems? Someone who knows how to solve the hairy problems. 6) Can we convert the existing CVS repository to it without losing revision histories? 7) Can we supply a read-only CVS mirror of the repository? 8) What's the documentation like? Is there a well-written, comprehensive tutorial? Can I get going in under an hour? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Home of da bomb
Re: svn
On Wed, Dec 08, 2004 at 07:19:07PM -0500, William Coleda wrote: Is there a plan at any point to move to an svn repository from cvs? I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, and I'll happily wait for svn if we're going that way, since it'll be smoother. If you are planning on switching revision control systems, I suggest something other than svn. There are a number of other systems available to the free software developer which offer serious advantages which might not be aparent to those who have not experienced them. Among them are arch, darcs, and monotone. I have used arch extensively, and I found it to be a powerfull tool but with a somewhat poorly designed interface. I have now been using darcs for several weeks and found it to be extremely well designed, but I've not used it long enough to endorse it fully. Monotone I have not used but it offers many of the same advantages.
RE: C implementation of Test::Harness' TAP protocol
--- Clayton, Nik wrote: Any Writing thread safe libraries for dummies texts you could point me at? I recommend Programming with POSIX Threads by David Butenhof. Thanks. Re the varargs ok() business, I assume you'll be using some sort of config.h with your libtap library. Any plans on using autoconf or similar tool? Yes. My TODO list for libtap is basically: http://jc.ngo.org.uk/trac-bin/trac.cgi/report/9 N
Re: Python method overloading
Leopold Toetsch wrote: Leo - at one point you indicated that you might be interested in helping to factor out the common code again. Sure, and I'm not stopping that. The overall conclusion of (even infix operator) method lookup was that it has to be done at runtime. It is up to the PMCs to provide a proper and language-specific find_method to locate the involved operation, MMD or not. I continue to disagree with the part of this conclusion where you insert find_method into the discussion. To give a concrete example: at the moment the lookup involved in abs_p_p does not involve the use of find_method. Nor does the lookup involved in find_method_p_p_s for that matter. If Perl programmers need to know about Parrot method names, then effectively this beomes part of the Perl language specification. I do not have the luxury of changing the Python language specification. I continue to push for the namespace for Parrot internal dispatching and language level method names to be disjoint. If Python metaclasses get surprising results if they happen to define a method named instantiate, expect a bug report. (BTW, a combined instantiate method does not map well to Python which has separate __new__ and __init__ methods. You are going to find issues like these every time you try to put object oriented semantics into the Parrot core. My recommendation is to stick to primitives, and simply provide a new_p_p). There needs to be separate find_method operations for external (i.e., visible at the language level) names and Parrot internal names. And the runcore is responsible for calling the method. While you seem to admit that it has to be done at runtime you are doubting that it can be done fast and you are rolling your own incompatible dispatch scheme (how should that be faster then?). This made me utter above sentence. as long as we have a proper protocol that everyone can conform to, we should be OK. - Dan Sugalski, 2004/11/29 Further: The function signature of overloaded infix operations (and maybe others) is currently not appropriate for Python (and likely other languages). That is only because the design you have in mind conflates Parrot and language operations. There is no reason that __abs__ couldn't call VTABLE_abs, or that __add__ can't make use of MMD_ADD. - Sam Ruby
Re: S05 question
Larry Wall wrote:
I'm still thinking about what «...» might mean, if anything. Bonus points
for interpolative and/or word-splitty.
I'm perhaps not being entirely serious, but if you want something
word-splitty and interpolative, how about this (which may cause unwanted
physiological side effects, I disclaim all responsibility)
«word ws word ws number»
which would mean
word ws word ws number
but with less typing, depending on how many keystrokes it takes to
produce « and » on your keyboard, and how much you put in it.
As far as interpolation goes, it would have to treat
«word ws $foo ws number»
As
word ws $foo ws number
assuming, that is, that $foo would take the value of $foo and use it
as the name of the rule to match against, rather than taking the
contents of $foo and using it as the rule. Or perhaps that's the better
way round, if $foo is a regexp/rule object thingy (not quite sure how
they work for us in Perl 6, can I say my $foo = rule { \d+ }; and expect
something sane?). Perhaps it treats it as a name if it contains a string
and a rule if it contains a rule.
Of course, it then begs the question about
word ws $foo ws number
if we're thinking of parallels with qw//-like constructs, which I
certainly am. I'm not quite sure what that would do, as it collides
slightly with the existing rule match syntax (which I quite like), and
thus it may already have a meaning.
Perhaps I've gone completely barmy; I throw it open for your decision,
good p6lers.
overloaded operator calling conventions
A recent discussion with Sam has shown that the current calling conventions for overloaded operators don't match Python semantics (nor Perl6 when I interpret S06 and S13 correctly). The difference is that Parrot is passing in the destination argument while these languages are returning the operator result. E.g. def myadd(self, r): return self - r class I(int): __add__ = myadd i = I(44) print i, i + 2 Parrot is expecting and calling a subroutine like: .sub __add .param left .param right .param dest ... .end and it's run in void context. This calling convention matches the add opcode, where the destination argument has to exist. But it's not suited for HLLs as the HLL compiler can't track the subroutine usage back to overloading and adjust the emitted code. A short-term solution would be to evaluate the return result (if the function returns something) and assign that value to the dest argument. Parrot would call .sub __add .param left .param right .param dest # HLL can use it or create a temp ... .return(temp) # or .return (dest) if HLL knows about dest .end while this is still a bit sub-optimal because of the additional temp, the HLL might create, it would at least match the semantics. A more radical change would be to just adapt these opcodes to create an appropriate PMC with the result. Comments? leo
Re: continuation enhanced arcs
Matt Fowles [EMAIL PROTECTED] wrote: ... This author may have to be a little wary about value vs reference semantics, but programmers are fairly used to that pitfall by now. Yes. But this still boils down to the question, if an author or compiler knows that a full continuation is involved and that I,S,N registers aren't usable for a piece of code. Matt leo
Re: S05 question
On Thu, Dec 09, 2004 at 10:52:54AM +, Matthew Walton wrote: Of course, it then begs the question about word ws $foo ws number if we're thinking of parallels with qw//-like constructs, which I certainly am. I'm not quite sure what that would do, as it collides slightly with the existing rule match syntax (which I quite like), and thus it may already have a meaning. This already has a meaning, it calls the word assertion with the (rule) expression /ws $foo ws number/ as an argument. At least it's that way unless/until Larry changes (changed?) it. Pm
Re: S05 question
On Wed, Dec 08, 2004 at 08:24:20PM -0800, Ashley Winters wrote: I was working on the (possibly misguided) assumption that there's a cost to capturing, and that perhaps agressive capturing isn't worth having on in a one-liner. Some deep part of my mind remembers $` being bad, I think. If there's no consequence to having capture being on, then ignoring it is fine. I don't have a problem with that. As I said before, ?foo reads fine to me. At least in the current implementation of PGE there's not a big cost to capturing of any sort. Each capture is held as a pair of (start,end) offsets into the target string, so there's no string copying or other overhead until the captured item is actually referred to. It's even easy to determine $` as being the start of the string up to the beginning offset of the $0 capture. (Yes, the perl 5 docs indicate there's a cost to $` that's incurred for all regexps in a program once $` is used, but I don't think that will translate over to PGE.) That might change, of course, especially as we add the ability to modify the target string in the middle of the match. But even then we may be able to keep the offset pairs as a useful optimization. At the moment the bigger cost is calling the subrule itself -- and even here it's basically the equivalent of a method or subroutine call (actually, coroutine calls), since a called rule maintains its own match state just like any other match. Pm
[CVS ci] class refactoring 1 - Integer
* PerlInt isa Integer now - most is inherited * try to improve MMD setup but failed MMD table creation looks now at parent and tries to install inherited MMD functions. But that's error prone and bulky and I'm too dumb to do it right. Currently one test (t/pmc/pmc_43.pasm) is failing due to wrong inheritance. TODO 1) adjust the PMC compiler not to emit MMD setup for inherited methods 2) allow multiple inheritance in PMCs, e.g. pmclass PyInt extends PyObject extends Integer (some hacks are already present in config/*/*.pl to do the same with OrderedHash) Takers wanted, thanks
Re: Python method overloading
Sam Ruby [EMAIL PROTECTED] wrote: I continue to disagree with the part of this conclusion where you insert find_method into the discussion. To give a concrete example: at the moment the lookup involved in abs_p_p does not involve the use of find_method. $ cat abs.imc .sub main .local pmc cl, o cl = newclass A $I0 = typeof cl o = new $I0 $P0 = new Undef $P0 = abs o print $P0 .end .namespace [A] .sub __absolute .param pmc d d = ok\n .end $ parrot abs.imc ok $ parrot -t abs.imc ... # find_method class 'A' method '__absolute': Sub # Calling sub '__absolute' ... ... Nor does the lookup involved in find_method_p_p_s for that matter. ??? If Perl programmers need to know about Parrot method names, then effectively this beomes part of the Perl language specification. I do not have the luxury of changing the Python language specification. If you are targeting Parrot you have to know the opcode names *and* the reserved method names, sorry. I continue to push for the namespace for Parrot internal dispatching and language level method names to be disjoint. That's a different thing that we can consider. ... If Python metaclasses get surprising results if they happen to define a method named instantiate, expect a bug report. Ok. The call syntax should rather be __instantiate to be consistent. ... (BTW, a combined instantiate method does not map well to Python which has separate __new__ and __init__ methods. We have the __init hook too. This is separate. $ parrot -t abs.imc ... 6 new P17, I30 - P17=PMCNULL, I30=72 # find_method class 'A' method '__init': no ... My recommendation is to stick to primitives, and simply provide a new_p_p). What is the second _p for? There needs to be separate find_method operations for external (i.e., visible at the language level) names and Parrot internal names. Maybe. But why is it necessary? That is only because the design you have in mind conflates Parrot and language operations. There is no reason that __abs__ couldn't call VTABLE_abs, or that __add__ can't make use of MMD_ADD. And if the class implements it's own __absolute or __add, we do a separate redispatch? And dynclasses/py* does it differently to dynclasses/perl*. Why don't you just believe me that that's error prone and slow ;-) - Sam Ruby leo
New version of Test::LongString
RGS has just released a new version of Test::LongString with patches I made last night. I added a new function contains_string(), and lots more docs. Test::LongString is one of those modules that you should be using if you're doing testing against large data elements, especially web pages. There are now examples in the docs that I hope make you say Wow, this is cool, thanks RGS! http://search.cpan.org/dist/Test-LongString http://search.cpan.org/~rgarcia/Test-LongString-0.05/lib/Test/LongString.pm xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [CVS ci] class refactoring 1 - Integer
Leopold Toetsch wrote: Currently one test (t/pmc/pmc_43.pasm) is failing due to wrong inheritance. Actually not because of inheritance. The implementation of PerlUndef.logical_xor was bogus. I've fixed this and the test. leo
Devel::Cover error from Storable
My unit test suite recently started spitting out this error when run under Devel::Cover. It runs normally and successfully without. Has anyone seen this before: Magic number checking on storable file failed at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 323, at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/DB/ Structure.pm line 249 END failed--call queue aborted. It seems to infect a certain test case, and then every subsequent test produces this, and fails. The only clue I have at the moment is that the test case in question forks a couple times and is fairly IPC heavy. I'm not sure if I can provide a simple case to reproduce it, as this is pretty proprietary :-( Thanks, Kevin
Re: New version of Test::LongString
On Dec 9, 2004, at 7:22 AM, Andy Lester wrote: Test::LongString is one of those modules that you should be using if you're doing testing against large data elements, especially web pages. There are now examples in the docs that I hope make you say Wow, this is cool, thanks RGS! I use Text::Differences for this, as it will show which lines are different, rather than just the first 50 characters. Much easier for me to diagnose problems. Regards, David
Re: Devel::Cover error from Storable
On Dec 9, 2004, at 9:50 AM, Steve Peters wrote: On Thu, Dec 09, 2004 at 09:34:18AM -0800, Kevin Scaldeferri wrote: My unit test suite recently started spitting out this error when run under Devel::Cover. It runs normally and successfully without. Has anyone seen this before: Magic number checking on storable file failed at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 323, at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/DB/ Structure.pm line 249 END failed--call queue aborted. ... Generally, this means the files you are reading in were created with a different version of Storable. Have you upgraded recently? Are you testing with multiple versions of Storable (or Perl) and using the same cover_db directory? I do not believe there is a new version. Moreover, each nightly run uses a unique cover_db directory, so there should not be any conflict with previous runs. Also, the first 20 or so test scripts run find and then this starts happening. Hmm... if there were two versions of Storable installed, and Devel::Cover initially found one, and then later IPC::Shareable somehow caused the other to be loaded instead, that might cause this... I will go investigate that possibility. Kevin
Re: Devel::Cover error from Storable
On Dec 9, 2004, at 10:16 AM, Kevin Scaldeferri wrote: Hmm... if there were two versions of Storable installed, and Devel::Cover initially found one, and then later IPC::Shareable somehow caused the other to be loaded instead, that might cause this... I will go investigate that possibility. No, that doesn't seem to be it. Running some of the tests outside of the harness though, I see a couple more messages which were hidden before: Devel::Cover: Can't find file ../../lib/Storable.pm: ignored. I'm pretty confused about where that's coming from. I can find messages of the sort Can't open file ... in the source, but not Can't find file. -kevin
Re: S05 question
On Wed, Dec 08, 2004 at 08:24:20PM -0800, Ashley Winters wrote:
: I'm still going to prefer using :=, simply as a good programming
: practice. My mind sees a big difference between building a parse-tree
: object and just grepping for some word I want in a string. Within a
: rule{} block, there is no place except the rule object to keep your
: data (hypothetically -- haha), so it makes sense to have everything
: capture unless otherwise specified. There's no such limitation in a
: regular code block, so I don't see the need.
Since regex results are lexically scoped in Perl 6, in a regular
code block we can do static analysis and determine whether there's
any possibility that $foo is referenced at all, and optimize it
away in many cases, if it turns out to be high overhead. But as Patrick
points out, so far capture seems pretty cheap.
Larry
Re: Devel::Cover error from Storable
On Thu, Dec 09, 2004 at 11:07:21AM -0800, Kevin Scaldeferri wrote: Running some of the tests outside of the harness though, I see a couple more messages which were hidden before: Devel::Cover: Can't find file ../../lib/Storable.pm: ignored. I'm pretty confused about where that's coming from. I can find messages of the sort Can't open file ... in the source, but not Can't find file. That comes from Devel::Cover::use_file(). It's an annoying message and I haven't got around to tracking down exactly what's happening there, but I've always thought it to be benign. It's basically saying that something used Storable and perl located it at ../../lib/Storable.pm. Since then $CWD has changed and now it can't be found any more so you aren't going to get a coverage report about it. Which is normally fine, since you don't want one anyway, and even if you did you couldn't because Devel::Cover uses Storable internally. Whether this is related to your main problem I can't tell, though I have have seen that warning plenty of times before but never encountered your main problem. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Devel::Cover error from Storable
-BEGIN PGP SIGNED MESSAGE- Moin, On Thursday 09 December 2004 19:16, Kevin Scaldeferri wrote: On Dec 9, 2004, at 9:50 AM, Steve Peters wrote: On Thu, Dec 09, 2004 at 09:34:18AM -0800, Kevin Scaldeferri wrote: My unit test suite recently started spitting out this error when run under Devel::Cover. It runs normally and successfully without. Has anyone seen this before: Hmm... if there were two versions of Storable installed, and Devel::Cover initially found one, and then later IPC::Shareable somehow caused the other to be loaded instead, that might cause this... I will go investigate that possibility. I run into this problem this week at work. I installed Perl v5.8.6 (yes, I am upgrade happy :) over 5.8.5 (and originally 5.8.3). v5.8.x is cool because you can still use all the old installed modules. However, newly installed modules go into the 5.8.6 path. So you get two versions. Normally no problem, but on this system /usr/bin/perl was still pointing at Perl v5.8.3 and since most scripts have #!/usr/bin/perl -w as first line, invoking them via: ./script --options will use the old Perl - which of course does not know about updated modules in the 5.8.6 path. Took me quite some time to figure out why certain bugs still appeared - I know added a debug status panel which shows the versions of the loaded modules and Perl just for this reason :) Best wishes, Tels - -- Signed on Thu Dec 9 20:34:23 2004 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. http://www.informatik.hu-berlin.de/~hstamm/beweis.html - Nützliche Beweismethoden für jeden Tag -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iQEVAwUBQbioy3cLPEOTuEwVAQHXFgf+OyKSUs9rij49D3E4kKxe/P3yZMtL5HQZ 6DlbKatFGTMyl8y8WesA2+sL08AcD7dPJtPCYWm+LFEmBpTzNwNa62WkCunzklIW M0wmdz4fB03Es+2p/Ujjm1QudZdnqaLQ35q3YqsQA3wRthR6uO0nskjE7J6bmx0A mZP/UFkn4WLki3XsSYXDg41W6+y+GD5BV+e+vK7JT+/OkE30dIQUnXjJR0w9ug6F 5huRqKg9L+ZHG6DvmnETrln+semDl1Viwx+Uctf8A+Vbq6SrThcklKCbNnt4/0Lu pOspfd8F4X70f4PAcNIQubauTaN0rBG4k/H5l3aCqgThDJ5b8kn0jg== =GJHO -END PGP SIGNATURE-
Re: continuation enhanced arcs
On Wed, Dec 08, 2004 at 04:04:31PM -0500, Matt Fowles wrote: I would disagree. Let me take the above example and work with it a little: $I0 = 10 loop: $P0 = shift array dec $I0 if $I0 goto loop We are (for the moment) assuming that shift array somehow causes a full continuations to be taken and then invoked it in a subsequent call. Then this code would infinite loop; however, so would this code Is shift a vtable method? IIRC Dan said that we're not going to be able to take continuations that cross PMC vtable invocation. Nicholas Clark
Re: Devel::Cover error from Storable
On Dec 9, 2004, at 11:21 AM, Paul Johnson wrote: Whether this is related to your main problem I can't tell, though I have have seen that warning plenty of times before but never encountered your main problem. Yeah, it's probably unrelated. My latest theory was that my forked processes were stomping on each other and corrupting the stored data structure. So I replaced the calls to nstore and retrieve with lock_nstore and lock_retrieve in DB.pm and Structure.pm. This doesn't seem to have helped. I ran Storable::retrieve on all the files in my cover_db after the latest failure. I found that all the files in cover_db/runs were corrupted, while only one out of a couple hundred files in cover_db/structure was bad. I don't know if that's a useful bit of info or not. -kevin
Re: Devel::Cover error from Storable
On Thu, Dec 09, 2004 at 02:06:39PM -0800, Kevin Scaldeferri wrote: My latest theory was that my forked processes were stomping on each other and corrupting the stored data structure. So I replaced the calls to nstore and retrieve with lock_nstore and lock_retrieve in DB.pm and Structure.pm. This doesn't seem to have helped. The run files are named time . .$$. . sprintf %05d, rand 2 ** 16 which should protect against forked processes. It may be that the structure files are not so well protected. I ran Storable::retrieve on all the files in my cover_db after the latest failure. I found that all the files in cover_db/runs were corrupted, while only one out of a couple hundred files in cover_db/structure was bad. I don't know if that's a useful bit of info or not. Are you absolutely certain that there's not another version of Storable around which could be being picked up? Maybe you could try printing out the version of Storable being used before nstore is called? -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Dynamic libs don't seem to work
Hello, I just got a fresh cvs checkout, compiled it, compiled pge and tried to make tcl. This is what I get: (cd ../../ ./parrot --output=languages/tcl/lib/tcllib.pbc languages/tcl/lib/tcllib.imc) Couldn't load 'tcl_group': tcl_group: cannot open shared object file: No such file or directory error:imcc:Unknown PMC type 'TclString' in file 'languages/tcl/lib/commands/upvar.imc' line 13 included from 'languages/tcl/lib/tcllib.imc' line 1 make: *** [lib/tcllib.pbc] Error 17 Also: - when doing make test, all tests with dynamic pmc seem to fail. - following instructions in dynoplibs and trying to execute the test.pasm in dynoplibs/ doesn't work either. Couldn't load 'myops_ops': myops_ops: cannot open shared object file: No such file or directory Couldn't load 'foo': foo: cannot open shared object file: No such file or directory Couldn't load 'libnci': libnci: cannot open shared object file: No such file or directory error:imcc:parse error, unexpected IDENTIFIER, expecting PARROT_OP in file 'dynoplibs/test.pasm' line 43 Obviously, there is something wrong with dynamic libs. I don't get what I'm doing wrong. This should all work right? Perljam (sorry, don't know his real name) told me on IRC he did a fresh checkout, and it all worked. Any ideas? thanks, klaas-jan
Re: Devel::Cover error from Storable
On Dec 9, 2004, at 2:32 PM, Paul Johnson wrote: On Thu, Dec 09, 2004 at 02:06:39PM -0800, Kevin Scaldeferri wrote: My latest theory was that my forked processes were stomping on each other and corrupting the stored data structure. So I replaced the calls to nstore and retrieve with lock_nstore and lock_retrieve in DB.pm and Structure.pm. This doesn't seem to have helped. The run files are named time . .$$. . sprintf %05d, rand 2 ** 16 which should protect against forked processes. It may be that the structure files are not so well protected. I ran Storable::retrieve on all the files in my cover_db after the latest failure. I found that all the files in cover_db/runs were corrupted, while only one out of a couple hundred files in cover_db/structure was bad. I don't know if that's a useful bit of info or not. Are you absolutely certain that there's not another version of Storable around which could be being picked up? Maybe you could try printing out the version of Storable being used before nstore is called? Okay, so it turns out I was being a bit of an idiot and failed to notice that cover_db/runs/ contains directories, not files. So, naturally, Storable can't retrieve a directory. The actual files one level deeper seem fine. So, in reality, I just have one structure file that is bad. I did try adding a line to print out the Storable version, and it doesn't change. However, I also couldn't reproduce the bug with that line in there. Yeah for Heisenbugs! I think this supports the idea that there is some race condition between multiple processes attempting to write the file if the additional I/O slows things down enough that it goes away.. Except that I'm still using lock_retrieve and lock_nstore in Structure.pm and it still happens. Nothing else modifies those files, right? -kevin
Re: Devel::Cover error from Storable
On Thu, Dec 09, 2004 at 09:34:18AM -0800, Kevin Scaldeferri wrote: My unit test suite recently started spitting out this error when run under Devel::Cover. It runs normally and successfully without. Has anyone seen this before: Magic number checking on storable file failed at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_retrieve.al) line 323, at /home/kevin/lib/perl5/site_perl/5.8.0/i686-linux-64int/Devel/Cover/DB/ Structure.pm line 249 END failed--call queue aborted. It seems to infect a certain test case, and then every subsequent test produces this, and fails. The only clue I have at the moment is that the test case in question forks a couple times and is fairly IPC heavy. I'm not sure if I can provide a simple case to reproduce it, as this is pretty proprietary :-( Generally, this means the files you are reading in were created with a different version of Storable. Have you upgraded recently? Are you testing with multiple versions of Storable (or Perl) and using the same cover_db directory? Steve Peters [EMAIL PROTECTED]
Re: New version of Test::LongString
On Dec 9, 2004, at 1:48 PM, Rafael Garcia-Suarez wrote: It's probably better adapted to text pages. I wrote Test::LongString to debug and test a serialization/deserialization protocol that was producing long binary strings. For this purpose, it was most helpful :) Ah, yeah. Test::Differences is line-oriented. So if you have one line, Test::LongString would be much better. :-) David
Re: New version of Test::LongString
David Wheeler wrote in perl.qa : Test::LongString is one of those modules that you should be using if you're doing testing against large data elements, especially web pages. There are now examples in the docs that I hope make you say Wow, this is cool, thanks RGS! I use Text::Differences for this, as it will show which lines are different, rather than just the first 50 characters. Much easier for me to diagnose problems. It's probably better adapted to text pages. I wrote Test::LongString to debug and test a serialization/deserialization protocol that was producing long binary strings. For this purpose, it was most helpful :)
Re: Dynamic libs don't seem to work
Can you give us a copy of the generated myconfig file in the top level parrot directory? Klaas-Jan Stol wrote: Hello, I just got a fresh cvs checkout, compiled it, compiled pge and tried to make tcl. This is what I get: (cd ../../ ./parrot --output=languages/tcl/lib/tcllib.pbc languages/tcl/lib/tcllib.imc) Couldn't load 'tcl_group': tcl_group: cannot open shared object file: No such file or directory error:imcc:Unknown PMC type 'TclString' in file 'languages/tcl/lib/commands/upvar.imc' line 13 included from 'languages/tcl/lib/tcllib.imc' line 1 make: *** [lib/tcllib.pbc] Error 17 Also: - when doing make test, all tests with dynamic pmc seem to fail. - following instructions in dynoplibs and trying to execute the test.pasm in dynoplibs/ doesn't work either. Couldn't load 'myops_ops': myops_ops: cannot open shared object file: No such file or directory Couldn't load 'foo': foo: cannot open shared object file: No such file or directory Couldn't load 'libnci': libnci: cannot open shared object file: No such file or directory error:imcc:parse error, unexpected IDENTIFIER, expecting PARROT_OP in file 'dynoplibs/test.pasm' line 43 Obviously, there is something wrong with dynamic libs. I don't get what I'm doing wrong. This should all work right? Perljam (sorry, don't know his real name) told me on IRC he did a fresh checkout, and it all worked. Any ideas? thanks, klaas-jan
Re: svn
Michael G Schwern [EMAIL PROTECTED] wrote: 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? Can we add are there GUIs for Windows, OS X, and other platforms with wimpy users? ;^) -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
Re: svn
On Thu, Dec 09, 2004 at 04:35:26PM -0800, Brent 'Dax' Royal-Gordon wrote: Michael G Schwern [EMAIL PROTECTED] wrote: 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? Can we add are there GUIs for Windows, OS X, and other platforms with wimpy users? ;^) A) Wimpy users don't hack Parrot and a lack of a GUI for the VC is not going to be what stops them. B) If there's not a GUI now there's nothing stopping someone from writing a GUI tomorrow. So no, I would not consider a GUI to be important. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ 7. It is always something -- RFC 1925
Re: svn
On Thu, 9 Dec 2004, Michael G Schwern wrote: On Thu, Dec 09, 2004 at 04:35:26PM -0800, Brent 'Dax' Royal-Gordon wrote: Michael G Schwern [EMAIL PROTECTED] wrote: 1) Are they easily available on all the platforms Parrot is? Various Unixen, OS X, Windows. Is there any hope for a VMS port? Can we add are there GUIs for Windows, OS X, and other platforms with wimpy users? ;^) A) Wimpy users don't hack Parrot and a lack of a GUI for the VC is not going to be what stops them. B) If there's not a GUI now there's nothing stopping someone from writing a GUI tomorrow. So no, I would not consider a GUI to be important. I chuckled as I read this. I love the term wimpy users. Also, if I may, there are various GUIs for svn. One of them is even written in java so theoretically it should run everywhere. http://jsvn.alternatecomputing.com/ I haven't used that one. The one I used was written for Unix using Qt. I forgot what it was called.. but this jsvn seems pretty cool. My two cents. -Calin
Q: scope exit (was: Exceptions, sub cleanup, and scope exit)
Dan Sugalski [EMAIL PROTECTED] wrote: ... A scope exit action is put in place on the control stack with: pushaction Psub * What is the intended usage of the action handler? * Specifically is this also ment for lazy DOD runs? * How is the relationship to the Cpop_pad opcode? Thanks, leo
