Re: RFC 208 (v2) crypt() default salt
On Thu, 21 Sep 2000, Mark-Jason Dominus wrote: > And the problem you describe is not really a problem. There has never > been any guarantee that a program would produce the same sequence of > random numbers after a change to the Perl binary. > random numbers after a change to the Perl binary. More recent > versions of Perl use random() or drand48() if they are available, Well, there effectively was such a guarantee for perl1.000 .. perl5.005_03. The drand48() change went in with 5.6.0. This was actually a very big issue for me. I put loud warnings into perldelta.pod and Jarkko and I put hooks into Configure to enable users to preserve the old pre-5.6.0 behavior if necessary. Further, we might eventually want to include our own PRNG into perl6 anyway, if only to work around the really lousy one commonly encountered on Win32. Still, even for me, I have never encountered a case where I wanted to maintain the same rand() sequence and also use a one-arg crypt(). > I will add a note aboput this to the RFC. If there are no other > comments, I will freeze it in 24 hours. I agree this is a non-issue for this RFC.[*] -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042 [*] I'm assuming we'll leave the salt example in the documentation, and that anyone sophisticated enough to rely on getting repeatable values from rand() can also use the example from perlfunc.
Re: Expunge "use English" from Perl? (was Re: Perl6Storm: Intent toRFC #0101)
On Wed, 27 Sep 2000, Nathan Wiger wrote: > Russ Allbery wrote: > > > > I've found the use of use English in code I had to maintain to be annoying > > and unhelpful, and to actually degrade the maintainability of the code > Y'know, I couldn't have said this better myself. :-) I've always felt > that "use English" was a waste of time and effort, a bandaid trying to > act as a tourniquet. Well, I think it has some limited uses. Remember that not everyone programs in perl all day everyday. Many competent people are only occasionally perl programmers. I find that I don't remember many of the less-frequently-used perlvars (where less-frequently-used depends on the types of programs I write, obviously). I certainly couldn't tell you off-hand the differences among $< $> $( and $). I'd have to look them up. I think it's a nice little bit of optional sugar and I don't see any reason to throw it away. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Critique available
On Thu, 2 Nov 2000, Nathan Torkington wrote: > When an article > in perl.com is so overwhelmingly negative about the work so far, do > you think that stirs confidence in what we're doing? To strive for balance, I think perl.com's home page should also have the links to Larry's ALS talk and slides. I know they are not a polished collection of web pages, but they are still quite readable. They also give a different perspective to the RFC collection. An article emphasizing positive aspects of the process so far would also seem like a nice idea, but somebody'd have to write it :-). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Guidelines for internals proposals and documentation
On Wed, 15 Nov 2000, David Grove wrote: > Nat and I argued parts of this (I think this is included) at some length. > Actually, I think I drove him crazy getting specifics out of this. [many thoughtful details omitted] > All in all, I think Dan's doing a good job making this make sense. I'm > just curious about the inner workings of a group. Well, since we don't actually *have* any groups yet, I'm not surprised that the inner workings of groups aren't clearly specified. I think we ought to just improvise as we go along for now. I'd much rather have Dan spend his time and talent trying to specify the api for perl extensions than trying to specify the api for perl development groups. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Backtracking through the source
On Thu, 30 Nov 2000, Bryan C. Warnock wrote: > You don't want the compiler design to be a 'hands-on experiment' for us > inexperienced folk? That's not elitist, that's pragmatic. > > You don't want this to be a learning experience - (corrections, observations, > answers) - to the same? *That's* elitist. Fair enough to a point, but please let's not overburden the experienced folk by also _expecting_ them to always supply "corrections, observations, and answers". -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
On Fri, 15 Sep 2000, Chris Nandor wrote: > You can only avoid breakage with current scripts if you make no changes to > the current facilities (which is what Andy proposed). Well I have to admit that I was unaware that on Mac and VMS (without the wizardry in vms/vms.c) the value returned by time() could jump behind your back if you were running when DST kicked in or out. If it were just different absolute epochs, I would tend to oppose the proposal (and recognize that I am probably in the minority and hence would gracefully yield anyway.) But this OS "feature" sounds to me like something that Perl should hide from the user. So, Yes, I'm tending to think perl6 probably ought to muck with epochs if possible. [Aside: Does this mean that make(1) is useless for one hour after standard time resumes?] -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Now, to try again...
On Sat, 16 Dec 2000, David Grove wrote: > Because what is the parser/lexer/tokenizer parsing? Perl? Pythonic? > Javanese? All of them? Thinking of just the parser as a single entity > seems to me to be headed into trouble unless we can define in advance what > type of role these dialects will play in the language, and at what point > they merge into a single entity and how. Now matter how we slice it, it's going to be very hard for the first person to twist perl6 to parse something that is both complex and very different from Perl6. And I'm unconvinced that this difficulty ought to hold up the entire process. It would be quite ironic if perl6 never gets off the ground because we can't figure out how to make 'use Java;' easy. "Little languages", on the other hand, are a somewhat different matter. They will presumably be not-so-complex and hence won't require such deep hooks, and some redundancy there won't be such a big problem. > Or, perhaps a more direct question. Has anyone given any thought about how > this multiple-input-style thingy is going to work? Can work? Should work? That's a good question. Another route to keep in mind is spending effort working on and with things such as perl-byacc (and maybe even the yet-to-be-written perl-lex) that help turn simple "languages" into perl. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Now, to try again...
On Sun, 17 Dec 2000, David Grove wrote: > > "Little languages", on the other hand, are a somewhat different matter. > > They will presumably be not-so-complex and hence won't require such > deep > > hooks, and some redundancy there won't be such a big problem. > > I'm not sure how this is incongruent with your first paragraph. Could you > elaborate a bit? You had expressed concern about redundancy if each parser had to re-implement a whole slew of stuff: p> a prefilter of some sort, or multiple parsers (or worse, multiple p> "parser/lexer/tokenizer single-entity parts"... meaning redundant p> duplication of extra effort over and over again repeatedly). I was just trying to say that for many small tasks, I would guess that most of the default actions would not need to be overridden, and hence there would not, in practice, be all that much redundancy. > > Another route to keep in mind is spending effort working on and with > > things such as perl-byacc > That sounds too complex for what seems like a more simple solution. When > you say "turn simple 'languages' into perl", that's what Dan's told me is > my source filter. Correct. perl-byacc is a source filter. It takes in yacc source and outputs perl code. It just may not be what folks first think of as a "source filter" in the sense of using the Filter:: modules. For some problems, it's certainly too complex. For others it might not be. Not all problems need be shoe-horned into the same solution box. That's all I'm trying to say. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Now, to try again...
On Sun, 17 Dec 2000, Dan Sugalski wrote: > At 02:24 PM 12/17/00 -0500, Sam Tregar wrote: > >It comes down to what is meant by "little language". When I hear that > >term I immediately think Scheme and TCL. > For my part, at least, I've been thinking of something either LISP-ish or > very simple parameter setting/checking (like stuff in, say, your average > .rc file with a little control flow thrown in) when it's brought up. That's typically what I think of, too. When perl6.0 is released, it would be nice if it were reasonably easy to write the appropriate modules (or whatever) and use such little languages fairly easily. The issues of 'use Python' or 'use Pythonish' are a quite different issue. I don't think anyone believes it ought to be easy to *write* the Pythonish module. But it ought to be *possible*. In between, there is a continuous spectrum of possibilities, and it may sometimes be appropriate to call on other tools to help out. But I don't think this should affect perl6-internals-api-parser very much. If the parser is sufficiently clever to parse something as complex as Perl, then it can probably be coerced into parsing something much simpler. So let's get on with the Perl6 parser. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Now, to try again...
On Mon, 18 Dec 2000, David Grove wrote: > > Andy Dougherty <[EMAIL PROTECTED]> wrote: > > > The issues of 'use Python' or 'use Pythonish' are a quite different > issue. > > I don't think anyone believes it ought to be easy to *write* the > Pythonish > > module. > > I do. > That's the problem. This is a nearly ubiquitously desired objective > (writing the modules or whatever they are), but I have the fear that > actually writing one will be so undaunting that it will be a seldom-used > feature, or one that will be as often avoided as complex perl OOP (beyond > the basics), provided only by the highest levels of perl mastery. I think you misunderstand. I think it should be very easy to *use* a hypothetical Pythonish module. I don't expect it will be very easy to create it, and I don't see it as worthwhile to expend a disproportionate amount of effort in that direction. In another message, you write ... > I also admit that I would, on a purely personal-bias level, prefer not > to > cast too much support in the direction of Python, Java, C#, or ASP at which also seems to aruge for not working too too hard to make it easy to write the Pythonish module. I think one or both of us is confused. > I don't > see these little languages as Perl features, but as programmer features, I don't see Python or Java as a "little language". Perhaps that's the source of the confusion. I see a whole spectrum of "languages" one might want to feed to perl6. Easy ones ("little languages") should be easy. Hard ones (e.g. Tcl, Python) should be possible. In-between-ones should be in between. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
On Wed, 27 Dec 2000, Dan Sugalski wrote: > As for types presented to extensions, we can certainly provide I8, I16, > I32, and friends. But we can't guarantee that every platform has integral types of those sizes. For example, in perl5, I32 is sometimes 32 bits, and sometimes 64 bits. Some Crays simply don't have native 32-bit types. All integral types are 64 bits. So we can provide something called "I32" but we can't guarantee it's 32 bits. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
On Wed, 27 Dec 2000, Dan Sugalski wrote: > I honestly can't think of any reason why the internal representation of an > integer matters to the outside world, but if someone can, do please > enlighten me. :) Passing parameters to library functions via extensions is tricky no matter how you do it. You must have a clear mapping between the types used in the library (e.g. int or void * or some POSIXy_t thingy) and the types used internally in Perl (e.g. IV). Currently we get away with being sloppy since I32 is almost always the same as int. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
On Sat, 30 Dec 2000, Nick Ing-Simmons wrote: > Dan Sugalski <[EMAIL PROTECTED]> writes: > > > >Anyone know of a good bigint/bigfloat library whose terms are such that we > >can just snag the source and use it in perl? > > There was some traffic on gcc list recently about a GNU one (presumably GPL > only). There's a clone of the GPL one that was written specifically to avoid GPL issues. I'll try to dig up more references when I'm in next week. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
On Tue, 2 Jan 2001, Dan Sugalski wrote: > that got wedged into an 8K address space with overlays...) but I'm pretty > sure I could do it on a PDP-11, with it's 64Kwords of I&D space. Probably > not the baseline, all-C version of the source, but perl nonetheless. Oh, then perhaps we should put the PDP-11 memory model probes back into Configure? :-) -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
On Sat, 30 Dec 2000, Andy Dougherty wrote: > > >Anyone know of a good bigint/bigfloat library whose terms are such that we > > >can just snag the source and use it in perl? > There's a clone of the GPL one that was written specifically to avoid GPL > issues. I'll try to dig up more references when I'm in next week. Ah, yes. The original GPL one was called gmp. Since it was released under the GPL and it was the only library with that particular API, there were some interesting copyright implications. See http://www.ptf.com/ptf/products/UNIX/current/0264.0.html for some editorializing. Primarily in response to this, fgmp was written as a public domain library. The most recent version I found in a less-than-exhaustive search was http://munitions.vipul.net/software/libraries/mathematics/fgmp-1.0.1.shar Now that gmp is licensed under the LPGL (see http://www.swox.com/gmp/ ) it isn't obvious to me how much to worry about all this. One other possibility that turned up was 'calc'. http://www.isthe.com/chongo/tech/comp/calc/index.html At first glance, it appears to have much more lenient licensing, but isn't really packaged as an easy-to-build-and-use library. (Again, this was a brief stint with a search engine, not an exhaustive search.) My main conclusion: If you want to experiment with modifying perl5's bigints and bigfloats with a tuned library to get an idea of how much speed we're talking about, gmp is probably the best bet to get a good estimate with the least amount of effort (though it doesn't look as if it's been ported to VMS, and it didn't build for me under Solaris 8 when I just tested it ...). If you want to redistribute the code, of course, then you need to think about licensing issues. (Does the LPGL and the existence of fgmp make it ok to distribute the interface/XS code and rely on the end user to install gmp if they so choose? Ick. I hate licensing problems.) -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: cross-compiling
On Tue, 2 Jan 2001, Jeff Okamoto wrote: > I know this isn't necessarily a topic for -internals, but if someone > could direct me to the right ML to think about how to make Perl easier > to cross-compile, I'll take the discussion there. [EMAIL PROTECTED] would be the right list, but Jarkko and I are already on the -internals list and nothing's happening on the -build list anyway. Making it easier to cross-compile is one of Jarkko's long-standing goals, and he's done work on it here and there even in the Perl5 context. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: standard representations
On Fri, 5 Jan 2001, Bradley M. Kuhn wrote: > I personally think that the relying on LGPL'ed code is completely > reasonable. Some will disagree, so we need to come to a consensus on this > as a community. There are actually a couple of different mostly-independent issues, but yes, we'll need to face them seriously fairly early on, I think. (Not just yet, perhaps, but probably soon.) 1. What are the consequences for those who redistribute software based on or including perl6? This is a licensing issue that I do not feel competent to address, and hence won't. 2. How do we handle build/install issues? a. Do we insist that users install the package first? If so, what do we do about portability problems? For example, gmp (the GNU multiprecision arithmetic library that's at issue here) hasn't been ported to VMS (at least last time I checked) while VMS is a supported platform for perl. b. Do we package our own version of the differently-licensed software along with perl6 and add our own portability and bug fixes at the perl6 release schedule almost inevitably resulting in a fork? [I have argued strongly against doing this with Berkeley DB in perl5, for example, for just such reasons.] c. Maybe we can do both -- supply a not-necessarily-particularly-good- but-at-least-portable version (maybe even in pure perl) with perl6, but have Configure (or its successor) detect the other package if already installed and offer to link with that instead. This is effectively what we do with sdbm/[gno]dbm/db. It is also possibily a possibility with gmp, since there's the public domain fgmp partial re-implementation (as well as the existing perl5 pure perl package). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: licensing issues
> But yes, I see no way to put perl solely under the GPL. That's just about > the worst thing we could do, aside from making perl non-"free." This is now *way way* off topic for perl6-internals. A relevant issue for perl6-internals had been whether we could or should rely on an LPGL library (gmp) to handle automatic conversion of SVs to BigInts or BigFloats if necessary. The current working hypothesis is that we don't *need* to rely on gmp. We can probably avoid significant technical portability and maintenance issues by making it possible to build perl6 without gmp, while also making it possible to link with gmp if a user wants the improved performance. (This is similar to what we do with AnyDBM_File in perl5 -- it's easy to add in Berkeley DB, but not required. Perl5 comes with sdbm.) -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, 31 Jan 2001, Casey R. Tweten wrote: > > Not that there needs to be any discussion on this but IMHO things that > can reasonably live outside the core should. I heard somewhere that > most people think this way too. This is why there hasn't been much discussion on it -- there's not really much to discuss. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, 31 Jan 2001, Bart Lateur wrote: > On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote: > > >Why the urge to move it out of the core? Should perl6 be like Python, > >where you first need to do a gazillion imports before you can do anything > >useful? Say goodbye to quick one-liners then. > > It doesn't have to be like that. Functions that are not in the core can > still be automatically loaded, but only if your code actually uses them. > That could make the perl kernel a lot smaller than it is now, and > hopefully, make it load faster. This is a persistent myth. Moving such functions out of the core may indeed make the perl kernel cleaner, but I seriously doubt it will make it "a lot smaller" or have any significant impact on load time. You can try it and see with perl5, or search the perl5-porters archives for my previous reports on the subject. For example, removing time() from the perl5 core means excising the following from pp_sys.c: PP(pp_time) { djSP; dTARGET; XPUSHi( time(Null(Time_t*)) ); RETURN; } and replacing it by the appropriate auto-loading glue. This is not a big space savings. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Why shouldn't sleep(0.5) DWIM?
On Wed, 31 Jan 2001, Simon Cozens wrote: > God gave man two ears and one tongue so that we listen twice as much as > we speak. > -- Arab proverb ...but alas on the net we have 10 fingers to type but only 2 eyes to read. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Auto-install (was autoloaded...)
On Sat, 10 Feb 2001, Branden wrote: > Another advantage I see on tar and gzip is that they are used by GNU, so I'm > pretty sure there probably wouldn't be any licensing issues, and I'm not > quite sure .zip doesn't use LZW, the same compression method of GIF... Zip uses the same compress method as gzip. In fact gzip's author, Jean-loup Gailly, is also a prominent contributor to InfoZip -- the group behind Zip and Unzip. I don't see any licensing advantage to gzip over zip or vice-versa. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Auto-install (was autoloaded...)
On Tue, 13 Feb 2001, Branden wrote: > Hello. > > I'm working on the PDD for par. I would like to propose a standard directory > structure for the files inside the archive, but I realise this depends > greatly upon the directory structure of Perl itself. > > How does Perl 5 manage its directory structure? See the INSTALL file supplied with Perl5.6.0 or later. If you have any questions after that, let me know and I'll try to answer them. > in. And Perl 5's directory structure is rather clumsy, I think we should set > platform-independent conventions for that too, where it's possible. You might want to build on top of some of the ideas hinted at in perl-5.6.0's "installstyle" Configure variable. See Porting/Glossary for the full definition. The directory structure may also be affected by the goal of allowing the simultaneous installation of multiple versions of modules. (I don't recall the relevant RFC offhand, but I think there's was also a similar idea in Larry's Atlanta speech.) -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Generating Perl 6 source with Perl
On Fri, 16 Feb 2001, Simon Cozens wrote: > Larry has guaranteed that Perl 6 will be built "out of the same source tree" > as Perl 5. This is a major win for us in two areas. Firstly, we can reuse the > information determined by Perl 5's Configure process to help make Perl 6 > portable: > Secondly and more importantly, it guarantees that we've got a copy of Perl on > hand before Perl 6 is built. Hmm. I thought that was more of a transitional idea, not a permanent state of affairs. That is, perl5 re-used a lot of perl4 stuff while still in development; perl6 can probably profitably do the same. However, eventually, perl4 stuff went away (or got absorbed outright). The same should ultimately happen to perl5 stuff, or else we're stuck forever maintaining both perl5 *and* perl6. Still, it indeed may be a very good way to get things going and allow us to postpone worrying about Configure's replacement. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Auto-install (was autoloaded...)
On Fri, 16 Feb 2001, Stephen P. Potter wrote: > How about a perl6-install list? This discussion really doesn't fit into > any of the current top level lists, so we can make a new top level and > cover other installation issues as well. Ask, can you make this, if the > name is agreeable. There already is a perl6-build list. Perhaps you can just use that? -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: PDD 4: Internal data types
On Fri, 2 Mar 2001, Dan Sugalski wrote: > =head2 Intger data types > > Integer data types are generically referred to as Cs. There is an > C typedef that is guaranteed to hold any integer type. [gazing into crystal ball . . . ] I predict some header somewhere is going to already #define "INT". Perhaps PERL_INT and PERL_NUM ? Do you also want an unsigned variant? (trying to spare Nick some of the sign preservation madness he's currently battling in perl5.) > =item Platform-native integer > > These are whatever size native integer was chosen at perl > configuration time. The C-level typedef C and C get you a > platform-native signed and unsigned integer respectively. So presumably PERL_INT could be "long long" but IV might just be "long". Hmm. So how do you carry around a PERL_INT inside the perl6 source? -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Questions about PDD 4: Internal data types
On Fri, 2 Mar 2001, Dan Sugalski wrote: > At 10:31 AM 3/2/2001 -0800, Hong Zhang wrote: > > > Integer data types are generically referred to as Cs. There is an > > > C typedef that is guaranteed to hold any integer type. > > > The intention is that if you need to deal with integers in an abstract way, > you'll use a variable of type INT. That way if you get handed an IV or a > bigint pointer, both will fit fine. Ah. I misread that too. You may safely ignore my question about INT as "long long" then. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: PDD 4 internal data types, version 1.1
On Fri, 30 Mar 2001, Bart Lateur wrote: > On Thu, 29 Mar 2001 19:24:21 +0200 (CEST), Tels wrote: > > >And then, if we have BigFloat, we need a way to specify rounding and > >precision. Otherwise 1/3 eats up all memory or provides limits ;o) > Er... may I suggest ratio's as a data format? It won't work for sqrt(2) > or PI, but it can easily store 1/3 as two (long) integers. The internal details ought to be invisible. Anyway, since you still can't store any irrationals exactly, you still have the same issues of rounding and precision. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Thu, 5 Apr 2001, Michael G Schwern wrote: > One-liners run on a Perl 6 binary should just be Perl 6 code. Do we > really have to worry about backwards compatibility with one liners? [ . . . ] > Hmm... programs that have perl one-liners inside them might be > troublesome. Yes, precisely. I often have one-liners embedded in larger shell scripts. Most of those survived the perl4->perl5 transition intact. I'd hope the same can be said for the perl5->perl6 transition. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Peter Scott wrote: [ -e vs. --cmd vs. -6] > Whatever we come up with, let's figure out how to avoid having to change it > the next time we change Perl. I don't think this is getting us anywhere useful. What happens if perl7 is sufficiently different from perl6 in such a way that you could imagine needing to distinguish for a one-liner between perl6 and perl7? This would be exactly the perl5/perl6 problem we face now. And, I hasten to point out, this is very similar to the perl4/perl5 problem we faced some time ago. Like most challenging design issues, there is probably no single ideal solution, and it's rather pointless to endlessly debate it in a vacuum. One needs to consider each issue individually against the larger backdrop of the goal of being mostly compatible. Perl's history is rich with examples of both keeping and breaking compatibility. Perl6 is likely to continue in that tradition. Let's leave -e alone for now and worry about handling specific incompatibilities when we in fact have some specific incompatibilities to worry about. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Peter Scott wrote: > >I'm still trying to figure out why the flag needs to change. What's wrong > >with -e? It seems perfectly serviceable. > > Because Larry said that by default Perl 6 would assume that its input was > in Perl 5...? So we need a way to tell it that it isn't. perl -M6 -e ... -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Perl_foo() vs foo() etc
On Wed, 11 Apr 2001, Dan Sugalski wrote: > No. That's because you won't include perl.h when you embed perl in your > app--you'll include something like per/embed.h or perlembed.h that has just > the definitions for the bits perl exports for embedding. Ah, ok. That's a change from perl5 practice, but probably a good one. It's worth noting explicitly in the appropriate PDD. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Perl_foo() vs foo() etc
On Wed, 11 Apr 2001, Dan Sugalski wrote: > *) All exported perl functions and functionlike things have a Perl_ prefix > *) All exported data and dataish thigns have a PL_ prefix > *) All private routines have #defines to give them a _Perl_ prefix > *) All private data have #defines to give them a _PL_ prefix > *) Internal data and functions get referenced via the unqualified names > That way the internals can use the utility function str_to_UTF(), while the > world would see it (or, rather, not see it) as _Perl_str_to_UTF(). But think also about embedding applications. If you want to embed perl into another program that has its own str_to_UTF() function, then #include "myprogram.h" #include /* ... */ str_to_UTF(); may get inadvertantly stuck with _Perl_str_to_UTF(). Offhand, I see at least three possible approaches: 1. Don't ever have short names. (Yuck, lots of typing, but that's ultimately how we got in the perl5 state). 2. Don't have the #defines #included by by default (or have them only set #ifdef PERL_CORE or some such). 3. Provide an unembed.h that un-does all those defines #include "myprogram.h" #include #include Of course _that_ could still collide with a #define for str_to_UTF() in myprogram.h, though this is starting to get less likely. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Thu, 12 Apr 2001, Dave Storrs wrote: > We could then just add a -7 flag. That's not necessarily bad; > Perl 7 will probably face the same issue...it needs to be able to eat Perl > [567] code without barfing, but it needs to know what it's getting. Also, > the flag would be a good choice in that it's very human-readable. More readable than the already-supporrted -M7 ? Do we *really* need a new command-line option that is one character shorter than an existing command-line option that can do exactly the same thing? -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Larry's Apocalypse 1
On Sun, 15 Apr 2001, David Grove wrote: > Add Solaris 8 1/01 to the list of OS's that have > completely rejected 5.6, as I discovered last night, This is quite unfair. Sun has supported perl nicely and Sun employees have actively contributed to 5.6.0 and beyond. That Solaris 8 included 5.005_03 and not 5.6.0 is due to a range of factors, including the very long lead time for *any* such bundling to be developed and tested. The timescales of corporations like Sun are not the same as those commonly encountered in the open software arena. It is quite possible that 5.6.1 will be included in future versions of Solaris. > corporate interests now in firm control of Perl 5. I don't think this is accurate either. I certainly don't see any evidence of Jarkko pressing any particular corporate interest. Nor is this list the appropriate place to make such charges. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
RE: So, we need a code name...
On Tue, 24 Apr 2001, Dan Sugalski wrote: > The big reason for Parrot was that I was terribly amused by Simon's joke, > and I have visions of releasing perl 6.0 on April 1 next year... :) > > Other than that, I really don't care much, though a good (or bad) pun is > always a big plus. Starting with 'P' is useful so we can keep our acronyms such as PMC and PDD :-). It's just an internal code name, so it probably doesn't matter if it's taken for another purpose. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Tying & Overloading
On Wed, 25 Apr 2001, James Mastros wrote: > I hate yelling without good reason, but this /is/ good reason. CAN SOMBODY > PLEASE TELL ME A _GOOD_ REASON TO SWITCH TO . FOR METHOD CALLS? It might be prudent to avoid rushing to judgment until the bigger picture becomes clearer. We have yet to see what changes might be in store for how, when, and why we'll be using method calls in perl6 vs. perl5. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Configurators!
On Sun, 26 Aug 2001, Nathan Torkington wrote: > We're about to have a tarball of basic interpreter source (no compiler > yet, only an assembler). Dan's already run into portability problems, > and once it comes out we're going to need to start working on the > configuration and build system. Could you give some examples? For the time being, it might be useful to use the existing perl5 installation to bootstrap the perl6 build somehow. Medium and long term, that's a really terrible maintenance plan, but short term it's probably not too bad. I know one hope bandied about was a portable "microperl" that could be used to write Configure.plx or some such. However, the following entry in perl5's Todo.micro - some of the uconfig.sh really needs to be probed (using cc) in buildtime: (uConfigure? :-) native datatype widths and endianness come to mind makes me wonder how feasible that hope is. Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: reconfiguring configure
On Fri, 11 Nov 2005, Will Coleda wrote: > On Nov 11, 2005, at 5:15 PM, Joshua Hoblitt wrote: > > As in my original proposal, Configure.pl would have to set the order > > that the steps run in. Longer term it'd be nice to build a dependency > > tree between the steps and execute them in order of dependencies. > > That sounds suspiciously like a Makefile. Yes, it does. In fact, metaconfig (the tool used to create perl5's Configure) writes out such a Makefile with the dependencies and then runs 'make' to get all the steps in order. However, note that this Makefile is for the maintainer's use only. The Configure maintainer runs metaconfig which sorts all this stuff out, and then ships the finished Configure file, which has all the steps in the right order. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #37819] Sun4 builds fail linking against jit.o
On Sat, 3 Dec 2005, Leopold Toetsch via RT wrote: > > On Dec 2, 2005, at 19:59, Andy Dougherty (via RT) wrote: > > > Parrot_jit_emit_mov_mr_offs blib/lib/libparrot.a(jit.o) > > Parrot_jit_emit_get_base_reg_no blib/lib/libparrot.a(jit.o) > > Parrot_jit_emit_mov_mr_n_offs blib/lib/libparrot.a(jit.o) > > Parrot_jit_emit_mov_rm_offs blib/lib/libparrot.a(jit.o) > > Parrot_jit_emit_mov_rm_n_offs blib/lib/libparrot.a(jit.o) > > Can you provide dummy subs for the _offs functions and put in a dummy > define for the get_base_reg_no macro that returns some valid register > number. I'll try something, but it'll be nearly blind guessing -- I don't know anywhere near enough about JIT or about SPARC assembler to actually understand what I'm doing, however. > See jit/mips/jit_emit.h (a dummy implementation) or jit/{ppc,x86} - > working. Thanks -- I'll check out the dummy one. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #37819] Sun4 builds fail linking against jit.o
0) +# define Parrot_jit_regbase_ptr(interpreter) ®_INT(0) /* The offset of a Parrot register from the base register */ -#define Parrot_jit_regoff(a, i) (unsigned)(a) - (unsigned)(Parrot_jit_regbase_ptr(i)) +# define Parrot_jit_regoff(a, i) (unsigned)(a) - (unsigned)(Parrot_jit_regbase_ptr(i)) /* interpreter->code */ -#define jit_emit_load_coderef(pc, reg) \ +# define jit_emit_load_coderef(pc, reg) \ emitm_ld_i(jit_info->native_ptr, Parrot_jit_intrp, offsetof(Interp, code), reg); \ /* Load op_map address */ -#define jit_emit_load_op_map(pc, code) \ +# define jit_emit_load_op_map(pc, code) \ emitm_ld_i(jit_info->native_ptr, code, \ offsetof(struct PackFile_ByteCode, jit_info), XSR1); \ emitm_ld_i(jit_info->native_ptr, XSR1, \ @@ -376,7 +376,7 @@ Parrot_jit_opmap); /* Construct the starting address of the byte code (code start) */ -#define jit_emit_load_code_start(pc, code) \ +# define jit_emit_load_code_start(pc, code) \ emitm_ld_i(jit_info->native_ptr, code, offsetof(struct PackFile_Segment, data), \ XSR1); @@ -446,11 +446,11 @@ } /* Generate branch on integer condition codes */ -#define Parrot_jit_bicc(jit_info, cond, annul, disp) \ +# define Parrot_jit_bicc(jit_info, cond, annul, disp) \ Parrot_jit_branch(jit_info, emitm_icc, cond, annul, disp) /* Generate branch on floating-point condition codes */ -#define Parrot_jit_fbfcc(jit_info, cond, annul, disp) \ +# define Parrot_jit_fbfcc(jit_info, cond, annul, disp) \ Parrot_jit_branch(jit_info, emitm_fcc, cond, annul, disp) /* This function loads a value */ @@ -732,7 +732,7 @@ Parrot_jit_bytejump(jit_info, interpreter, emitm_o(0)); } -#undef Parrot_jit_restart_op +# undef Parrot_jit_restart_op void Parrot_jit_restart_op(Parrot_jit_info_t *jit_info, Interp * interpreter) { @@ -784,6 +784,36 @@ Parrot_jit_regbase, Parrot_jit_regoff(mem, interpreter), reg); } +/* XXX Hack to fix the following bug as of 05 Dec 2005: +Hack [perl #37819] Sun4 builds fail linking against jit.o +These dummy definitions blindly copied from jit/mips/jit_emit.h. +Apparently, they need to be inside a JIT_EMIT section of this +file. +See also the "Hack [perl #37819]" section near the bottom of this +file. +*/ +void +Parrot_jit_emit_mov_mr_offs(Interp * interpreter, int base, size_t offs, int reg) +{ +} + +void +Parrot_jit_emit_mov_rm_offs(Interp * interpreter, int reg, int base, size_t offs) +{ +} + +void +Parrot_jit_emit_mov_mr_n_offs(Interp * interpreter, int base, size_t offs, int reg) +{ +} + +void +Parrot_jit_emit_mov_rm_n_offs(Interp * interpreter, int reg, int base, size_t offs) +{ +} +/* XXX end blind hack for [perl #37819] --but see + additional hack section at bottom. +*/ # ifndef NO_JIT_VTABLE_OPS #undef Parrot_jit_vtable1_op @@ -,15 +1141,15 @@ emitm_mov_r(jit_info->native_ptr, Parrot_jit_intrp, emitm_o(0)); } -#endif /* NO_JIT_VTABLE_OPS */ +# endif /* NO_JIT_VTABLE_OPS */ -#else +#else /* JIT_EMIT */ # define REQUIRES_CONSTANT_POOL 0 # define INT_REGISTERS_TO_MAP 6 # define FLOAT_REGISTERS_TO_MAP 6 -#ifndef JIT_IMCC +# ifndef JIT_IMCC char intval_map[INT_REGISTERS_TO_MAP] = { emitm_l(1), emitm_l(2), emitm_l(3), emitm_l(4), emitm_l(5), emitm_l(6) }; @@ -1127,12 +1157,21 @@ char floatval_map[] = { emitm_f(4), emitm_f(6), emitm_f(8), emitm_f(10), emitm_f(12), emitm_f(14) }; -#endif +# endif + +# define PRESERVED_INT_REGS 6 +# define PRESERVED_FLOAT_REGS 0 -#define PRESERVED_INT_REGS 6 -#define PRESERVED_FLOAT_REGS 0 +#endif /* JIT_EMIT */ + +/* XXX Hack [perl #37819] Unlike the functions above, this one apparently +sometimes needs to be defined both in and out of the JIT_EMIT section. +However, at this point, the Parrot_jit_regbase symbol is not +defined, so we replace it with the integer 26 (which is what it +expands to anyway. +*/ +# define Parrot_jit_emit_get_base_reg_no(pc) 26 /*Parrot_jit_regbase */ -#endif #endif /* PARROT_SUN4_JIT_EMIT_H_GUARD */ /* -- Andy Dougherty [EMAIL PROTECTED]
Re: some goals for the next release
On Sun, 4 Dec 2005, Joshua Hoblitt wrote: > What still needs to be done: > - CLI options need some minor tweaks I think they need some major design. In particular, it would be nice to have a documented consistent interface to setting or unsetting various things. Then, it would be *very* nice to have a glossary somewhere (e.g. like perl5's Porting/Glossary.pod) that defined what all the various things are the could be set. Here's an example: Recent changes broke jit compilation on SPARC. How can I re-configure so that parrot tries to build without jit? Running Configure.pl --help gives the following promising-looking option: --jitcapable Use JIT But how do you turn it off? Do you use --no-jitcapable? --jitcapable=undef? --nojitcapable? --jitcapable=0? Short of actually reading the code, there's no way to know. I happen to like perl5's Configure -D and Configure -U option syntax, but I can imagine other syntax too, as long as it's consistent, documented, and easy-to-use. > - The debugging traces could be neater > > - A usable log file would be handy > > - Makefile dependencies still aren't being setup rigorously > > - Last but not least, Leo's point about reviewing what the configuration > steps are actually doing. I'd also add: - An option to just run the generation phase. For example, suppose you're working on fixing up the makefile root.in. It'd be nice to just run Configure.pl --generate (or some such) and have it regenerate the generated files without having to go through and re-run all of the Configure.pl tests. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38141] [PATCH] CFLAGS missed two files in src/ reorganization
On Wed, 4 Jan 2006, Joshua Hoblitt via RT wrote: > Andy, > > Were you caught by either "takes too long" or "Overwhelms some > compilers."? Well, it hadn't quite overwhelmed the compiler yet -- it was swapping like mad for at least 20 minutes and still growing, and several other processes (including spamassassin, alas) had died due to out-of-memory-errors, but the compiler hadn't quite given up yet. I suspect it would have, had I let it continue. > I'm wondering if it's worth disabling optimizations for > those compilation units if nobody noticed a problem in the period > between the tree reorganization and the breakage of --optimize. It's very hard to portably test for this sort of thing. Even in perl5's Configure, I eventually gave up on it, and just made sure it was well documented in the INSTALL file what to do. (The usual culprit there is toke.c.) As to how widespread a problem this could be, I really don't know. It's possible nobody noticed a problem because nobody tested it on anything other than gcc. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38141] [PATCH] CFLAGS missed two files in src/ reorganization
On Wed, 4 Jan 2006, jerry gay via RT wrote: > On 1/4/06, Andy Dougherty <[EMAIL PROTECTED]> wrote: > > On Wed, 4 Jan 2006, Joshua Hoblitt via RT wrote: > > > I'm wondering if it's worth disabling optimizations for > > > those compilation units if nobody noticed a problem in the period > > > between the tree reorganization and the breakage of --optimize. > > > > It's very hard to portably test for this sort of thing. Even in perl5's > > Configure, I eventually gave up on it, and just made sure it was well > > documented in the INSTALL file what to do. (The usual culprit there is > > toke.c.) > > > > As to how widespread a problem this could be, I really don't know. It's > > possible nobody noticed a problem because nobody tested it on anything > > other than gcc. > src/ops/core_ops_switch.c compiles on win32, and i have to say, i > didn't notice it taking any more time. so, i'd like to have > optimizations enabled for this file. since CFLAGS is a generated file, > we can use #conditioned_line to specify when it should or should not > be enabled. And, just to be clear, that's building with Configure.pl --optimize=??? (that is, exactly what optimization flags did you use?) > i'd like reports from a third compiler/arch to know how it should > behave... enabled by default, or disabled. so far, we have: > gcc - disabled I don't know about gcc. I haven't tested it. > cl - enabled > others - ??? The combination that failed for me is Sun/SPARC Workshop cc with optimize=-fast. It may be that other less-aggressive optimizations are fine; I haven't done a systematic search. -- Andy Dougherty [EMAIL PROTECTED]
Re: Heureka - from the -Ofun department
On Wed, 8 Feb 2006, Leopold Toetsch wrote: > Parrot runs the ackermann benchmark faster than C. > > $ time ./parrot -Oc -C ack.pir 11 > Ack(3, 11) = 16381 > > real0m0.567s > user0m0.559s > sys 0m0.008s > > $ time ./ack 11 > Ack(3,11): 16381 > > real0m0.980s > user0m0.978s > sys 0m0.002s This looked like fun, so I tried it on Solaris/SPARC. Alas, I didn't have such great luck. First, though the -C runcore made about a factor of 2 difference in timings (gcc/SPARC), it's only only available (as far as I can tell) with gcc. Still, you might as well use it if you can. On SPARC, I found Parrot took 12 times as long: C: time ./ack 11 Ack(3,11): 16381 real1m7.62s user1m7.36s sys 0m0.05s Parrot: time ./parrot -Oc -C ack.pir 11 Ack(3, 11) = 16381 real11m56.24s user11m52.12s sys 0m0.14s Thinking it might have something to do with the SPARC architecture, I tried it on x86, where Parrot took 80 times as long: C: time ./ack 11 Ack(3,11): 16381 real0m0.759s user0m0.758s sys 0m0.002s Parrot: time ./parrot -Oc -C ../tmp/ack.pir 11 Ack(3, 11) = 16381 real1m1.211s user1m1.087s sys 0m0.021s Something's obviously very goofy there, but I don't know what. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule
On Sat, 4 Feb 2006, Allison Randal wrote: > On Feb 3, 2006, at 17:33, Joshua Isom via RT wrote: > > > > But, I've encountered two major problems. On darwin, I can't finish > > past_node.t, first parrot takes over 100 megs of ram, then perl(5.8.7) > > wants 180 megs. On freebsd, it's actually worse, but more confusing. > > It fails with past_*.t and post_*.t. But past.t is fine. It's > > essentially a lot of out of memory errors(yet swap space isn't touched, > > and there's free ram at that moment). Darwin essentially starts > > "stalling" when freebsd just gives up on allocating more memory. Line > > numbers aren't given in the print out, except for src/memory.c line 92. > > This is a known bug. As far as we can tell so far, it's not the Punie code, > but Parrot::Test causing the problem. On both platforms, try running the > generated .pir files in languages/punie/t directly (e.g. t/past_node_2.pir). > Everyone who's tried it so far has reported that they have no memory errors > running the test code directly, and only get errors running the code through > the test harness. I too had seen this memory problem before on Solaris/SPARC, but I'm pretty sure I saw it even when running t/past_node_5.pir directly. However, trying again today, I'm happy to report that that particular problem seems to be gone. Of course an awful lot of the tests still fail, but I don't know if that's expected or not. Failed 6/15 test scripts, 60.00% okay. 16/41 subtests failed, 60.98% okay. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/past.t6 1536 76 85.71% 2-7 t/past_op.t 2 512 22 100.00% 1-2 t/past_val.t2 512 22 100.00% 1-2 t/post.t2 512 32 66.67% 2-3 t/post_op.t 2 512 22 100.00% 1-2 t/post_val.t2 512 22 100.00% 1-2 *** Error code 2 make: Fatal error: Command failed for target `test' -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule
On Fri, 10 Feb 2006, Allison Randal wrote: > On Feb 10, 2006, at 9:56, Andy Dougherty via RT wrote: > > > > I too had seen this memory problem before on Solaris/SPARC, but I'm > > pretty sure I saw it even when running t/past_node_5.pir directly. > > However, trying again today, I'm happy to report that that particular > > problem seems to be gone. > > Excellent. > > > Of course an awful lot of the tests still > > fail, but I don't know if that's expected or not. > > All of the test should be passing (at least, they are on other platforms). > Could you send me more details on the failing tests? Some of the generated > .out and .pir files would be a good start (running with POSTMORTEM=1). I don't pretend to remotely understand what the code is attempting to do, let alone how it's failing, but the failures vaguely seem to be fairly similar. It looks like 'node.set_node' doesn't actually end up doing anything. So for t/past_2.pir, for example, we have .sub _main load_bytecode 'languages/punie/lib/PAST.pir' .local pmc node node = new 'PAST::Code' $P0 = new PerlString $P0 = 'bar' $P1 = new PerlArray push $P1, $P0 node.set_node('foo', 42, $P1) $P1 = getattribute node, 'source' print $P1 print "\n" $P1 = getattribute node, 'pos' print $P1 print "\n" $P2 = getattribute node, 'children' $P3 = $P2[0] print $P3 print "\n" .return () .end and for t/past_2.out, we have 1 1 bar The other one that looks significantly different is t/past_op_1.pir. The pir file is .sub _main load_bytecode 'languages/punie/lib/PAST.pir' .local pmc node node = new 'PAST::Op' node.set_node('foo', 42, 'bar') $P1 = getattribute node, 'source' print $P1 print "\n" $P1 = getattribute node, 'pos' print $P1 print "\n" $P1 = getattribute node, 'op' print $P1 print "\n" .return () .end and the output file is Null PMC access in get_string() current instr.: '_main' pc 20 (/home/doughera/src/parrot/parrot-andy/languages/punie/t/past_op_1.pir:7) Here's the full output of 'make test'. It accurately reflects the .out files (well, I didn't exhaustively check them all, but the ones I did check matched up.) perl5.6 -Ilib t/harness t/*.t t/base_condok t/base_if..ok t/base_lex.ok t/base_pat.ok t/base_termok t/io_print.ok t/op_goto..ok t/past. # Failed test (t/past.t at line 44) # got: '1 # 1 # bar # ' # expected: 'foo # 42 # bar # ' # Failed test (t/past.t at line 44) # got: '1 # 1 # bar # ' # expected: 'foo # 42 # bar # ' # Failed test (t/past.t at line 44) # got: '1 # 1 # bar # ' # expected: 'foo # 42 # bar # ' # Failed test (t/past.t at line 44) # got: '1 # 1 # bar # ' # expected: 'foo # 42 # bar # ' # Failed test (t/past.t at line 44) # got: '1 # 1 # bar # ' # expected: 'foo # 42 # bar # ' # Failed test (t/past.t at line 44) # got: '1 # 1 # bar # ' # expected: 'foo # 42 # bar # ' # Looks like you failed 6 tests of 7. dubious Test returned status 6 (wstat 1536, 0x600) DIED. FAILED tests 2-7 Failed 6/7 tests, 14.29% okay t/past_nodeok t/past_op.. # Failed test (t/past_op.t at line 7) # got: 'Null PMC access in get_string() # current instr.: '_main' pc 20 (/home/doughera/src/parrot/parrot-andy/languages/punie/t/past_op_1.pir:7) # ' # expected: 'foo # 42 # bar # ' # './parrot "/home/doughera/src/parrot/parrot-andy/languages/punie/t/past_op_1.pir"' failed with exit code 43 # Failed test (t/past_op.t at line 30) # got: ' => { # 'source' => undef, # 'pos' => undef, # 'op' => 'bar', # 'children' => [] # } # ' # expected: ' => { # 'source' => 'foo', # 'pos' => '42', # 'op' => 'bar', # 'children' => [] # } # ' # Looks like you failed 2 tests of 2. dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-2 Failed 2/2 tests, 0.00% okay t/past_val. # Failed test (t/past_val.t at line 7) # got: '42 # 42 # bar # ' # expected: 'foo # 42 # bar # ' # Failed test (t/past_val.t at line 30) # got: ' => { # 'source
Re: svn access (was: [perl #38576] [PATCH] Make DETAIL_MEMORY_DEBUG work. )
On Wed, 15 Feb 2006, Leopold Toetsch via RT wrote: > Andy, I've already asked once: don't you have svn access? If no (and if > you want it) please mail me your auth.perl.org account data, to get you > svn priv bits. I do have priv bits, and have on rare occasion used them, but I don't usually have an svn repository available -- I usually work with the snapshots or releases. And, since a checkout takes about an hour (last time I checked) I tend to be too lazy to fetch one just to make a patch. Still, I'll take your message to heart, and when feasible (and appropriate!) just try to check stuff in directly. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #18189] Test failures with 'long long' on i386/linux
rs/pge/pge_globs.t 22 563222 22 100.00% 1-22 t/compilers/tge/basic.t 1 256 21 50.00% 1 t/compilers/tge/grammar.t1 256 11 100.00% 1 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/compilers/tge/parser.t 1 256 11 100.00% 1 t/examples/pir.t 1 256191 5.26% 5 t/examples/streams.t 1 256121 8.33% 5 t/library/dumper.t 4 1024274 14.81% 6-8 15 t/library/json.t 4 1024224 18.18% 11-14 t/library/md5.t 1 256 61 16.67% 3 t/library/sort.t 9 2304 99 100.00% 1-9 t/library/streams.t 3 768203 15.00% 10 13 17 t/library/test_builder_tester.t 011128 66.67% 9-12 t/library/test_more.t01120 40 200.00% 1-20 t/op/64bit.t 1 256 11 100.00% 1 t/op/bitwise.t 1 256261 3.85% 6 t/op/comp.t 2 512802 2.50% 7-8 t/op/debuginfo.t 1 256 81 12.50% 8 t/op/gc.t4 1024224 18.18% 14-15 17 22 t/op/macro.t 1 256181 5.56% 15 t/op/spawnw.t1 256 71 14.29% 7 t/pmc/boolean.t 1 256 91 11.11% 6 t/pmc/complex.t 6 1536256 24.00% 5-8 24-25 t/pmc/delegate.t 2 512 92 22.22% 8-9 t/pmc/fixedpmcarray.t1 256141 7.14% 10 t/pmc/fixedstringarray.t 1 256131 7.69% 13 t/pmc/float.t 15 384045 15 33.33% 2-9 39-45 t/pmc/hash.t 2 512372 5.41% 9 14 t/pmc/integer.t 1 256161 6.25% 11 t/pmc/managedstruct.t4 1024 64 66.67% 2-5 t/pmc/mmd.t 18 460831 18 58.06% 11-24 26-28 30 t/pmc/n_arithmetics.t9 2304209 45.00% 6 9-13 15-17 t/pmc/nci.t 24 614460 24 40.00% 2-3 5 8 26-37 42 46-48 50-53 t/pmc/object-meths.t 2 512332 6.06% 29 32 t/pmc/objects.t 6 1536636 9.52% 48-52 61 t/pmc/perlhash.t 1 256371 2.70% 13 t/pmc/perlint.t 48 1228870 48 68.57% 10-11 13-17 20-21 23-36 38-40 42-47 49-58 60-61 63 65-66 70 t/pmc/perlnum.t 30 768055 30 54.55% 7-34 45-46 t/pmc/perlstring.t 39 998467 39 58.21% 6 15-18 20-21 24-45 49-57 62 t/pmc/perlundef.t8 2048108 80.00% 1-5 7-8 10 t/pmc/pmc.t 3 768243 12.50% 10-11 23 t/pmc/resizablepmcarray.t1 256231 4.35% 14 t/pmc/resizablestringarray.t 1 256281 3.57% 21 t/pmc/string.t 15 384038 15 39.47% 4 8 11-13 17- 25 28 t/pmc/sub.t 2 512412 4.88% 11-12 t/pmc/tqueue.t 1 256 11 100.00% 1 t/pmc/undef.t1 256101 10.00% 1 t/src/compiler.t 1 256 11 100.00% 1 t/src/io.t 2 512202 10.00% 4 7 Failed 64/228 test scripts, 71.93% okay. 1249/4846 subtests failed, 74.23% okay. 9 tests and 728 subtests skipped. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38577] [PATCH] Reduce memory consumption of t/pmc/resizablebooleanarray_17.pasm
On Wed, 15 Feb 2006, Joshua Hoblitt via RT wrote: > Please resolve patch bugs after applying the patch. In this case, I didn't apply the patch, so I didn't close it. Also, in this case, there's more to it than just the patch -- the underlying problem is that resizeablebooleanarray is taking 64 bytes to store 1 bit of information. When Jerry applied that patch, he agreed that was odd and decided to leave the ticket open pending further investigation. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #18189] Test failures with 'long long' on i386/linux
On Thu, 16 Feb 2006, Leopold Toetsch via RT wrote: > > On Feb 16, 2006, at 17:34, Andy Dougherty wrote: > > > > >> This bug seems to have resolved itself at least on amd64/linux. > >> Please > >> re-open this bug if it's still failing for you. Thanks for reporting. > > A long long is 64 bit on amd64/linux this is the standard config and of > course is working. > > > This configuration (intval=long long, opcode=long long, i386/linux) > > still > > fails. > > sizeof(opcode_t) != sizeof(void*) is for sure broken. Well, it used to work, but that was a long time ago. Configure actually tests for this case and still claims it will work; perhaps that test should be changed to emit a much more dire message, or even die (unless overridden). > But why would one > use 64-bit opcodes on a 32-bit system? At the time I submitted the original bug report, that's what you would get by default if you happened to use a 64-bit perl to run parrot's Configure.pl. Since I could easily see that sort of thing happening, I used to test for it. Now, Configure.pl no longer picks 'long long' by default in such situations, so you have to go out of your way to get this configuration. At this point, I don't particuarly care. I only bothered to test it because I was asked to. -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
On Fri, 17 Feb 2006, Matt Fowles wrote: > All~ > > On 2/17/06, jesse <[EMAIL PROTECTED]> wrote: > > > > > > > > On Fri, Feb 17, 2006 at 08:38:26AM -0800, Robert Spier wrote: > > > > snapshots or releases. And, since a checkout takes about an hour (last > > > > time I checked) I tend to be too lazy to fetch one just to make a patch. > > > > > > Only if you're checking out to a Commodore 64. > > > > Or possibly hand-transcribing the bits. > > I could check it out over iridium dial up... Sigh. I wish it were that simple, or that funny. $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz real0m16.84s user0m0.09s sys 0m0.20s $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk real 2:01:50.3 user 1:02.0 sys44.9 It's something specific to svn. No, I don't know what. -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
On Fri, 17 Feb 2006, Matt Fowles wrote: > > On 2/17/06, Andy Dougherty <[EMAIL PROTECTED]> wrote: > > Sigh. I wish it were that simple, or that funny. > > > > $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz > > > > real0m16.84s > > user0m0.09s > > sys 0m0.20s > > > > $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk > > > > real 2:01:50.3 > > user 1:02.0 > > sys44.9 > > > > It's something specific to svn. No, I don't know what. > > $ svn --version > svn, version 1.1.4 (r13838) > compiled May 13 2005, 06:29:47 $ svn --version svn, version 1.1.3 (r12730) compiled Mar 31 2005, 13:19:13 -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
On Fri, 17 Feb 2006, jesse wrote: > > > On Fri, 17 Feb 2006, Matt Fowles wrote: > > > > > > > > On 2/17/06, Andy Dougherty <[EMAIL PROTECTED]> wrote: > > > > $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz > > > > real0m16.84s > > > > $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk > > > > real 2:01:50.3 > > > > > > > > It's something specific to svn. No, I don't know what. > > Do you, perchance, sit behind an http proxy server? Not that I know of (though I'm not sure how I'd know), and no other mode of communication is similarly affected (i.e. cvs, rsync, etc., all work fine). > Try: > time svn co https://svn.perl.org/parrot/trunk parrot-trunk svn: Unrecognized URL scheme 'https://svn.perl.org/parrot/trunk' I don't know why. I have OpenSSL installed where svn should have found it when building. If I can find the free time, perhaps I'll try upgrading, though I have no reason to think it'll solve the problem. I don't use svn for anything else, and wget works just fine for fetching the snapshots, so this hasn't been a priority for me. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38584] [BUG] Punie test failures in set_node method on Solaris/SPARC
x27; pc 21 (/home/doughera/src/parrot/parrot-andy/languages/punie/t/post_op_2.pir:6) # ' # expected: ' => { # 'source' => 'foo', # 'pos' => '42', # 'op' => 'bar', # 'children' => [] # } # ' # './parrot "/home/doughera/src/parrot/parrot-andy/languages/punie/t/post_op_2.pir"' failed with exit code 1 # Looks like you failed 2 tests of 2. dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-2 Failed 2/2 tests, 0.00% okay t/post_val. # Failed test (t/post_val.t at line 7) # got: '42 # 42 # bar # ' # expected: 'foo # 42 # bar # ' # Failed test (t/post_val.t at line 30) # got: ' => { # 'source' => '42', # 'pos' => '42', # 'value' => 'bar', # 'valtype' => undef, # } # ' # expected: ' => { # 'source' => 'foo', # 'pos' => '42', # 'value' => 'bar', # 'valtype' => undef, # } # ' # Looks like you failed 2 tests of 2. dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-2 Failed 2/2 tests, 0.00% okay t/post_var. # Failed test (t/post_var.t at line 7) # got: '42 # 42 # bar # ' # expected: 'foo # 42 # bar # ' # Failed test (t/post_var.t at line 30) # got: ' => { # 'source' => '42', # 'pos' => '42', # 'varname' => 'bar', # } # ' # expected: ' => { # 'source' => 'foo', # 'pos' => '42', # 'varname' => 'bar', # } # ' # Looks like you failed 2 tests of 2. dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 1-2 Failed 2/2 tests, 0.00% okay Failed 7/19 test scripts, 63.16% okay. 18/55 subtests failed, 67.27% okay. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/past.t6 1536 76 85.71% 2-7 t/past_op.t 2 512 22 100.00% 1-2 t/past_val.t2 512 22 100.00% 1-2 t/post.t2 512 32 66.67% 2-3 t/post_op.t 2 512 22 100.00% 1-2 t/post_val.t2 512 22 100.00% 1-2 t/post_var.t2 512 22 100.00% 1-2 *** Error code 2 make: Fatal error: Command failed for target `test' -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
> On Fri, Feb 17, 2006 Andy Dougherty wrote: [svn co on Solaris 8 is painfully *slow*] > $ time wget http://cvs.perl.org/snapshots/parrot/parrot-latest.tar.gz > > real0m16.84s > user0m0.09s > sys 0m0.20s > > $ time svn co http://svn.perl.org/parrot/trunk parrot-trunk > > real 2:01:50.3 > user 1:02.0 > sys44.9 > > It's something specific to svn. No, I don't know what. > > $ svn --version > svn, version 1.1.3 (r12730) >compiled Mar 31 2005, 13:19:13 Thanks to everyone for suggestions. Here's a summary of what I found: jerry gay: > can't hurt to upgrade... It didn't hurt (too much), but, alas, it didn't help either. Matt Fowles: >Do you, perchance, sit behind an http proxy server? > >Try: >time svn co https://svn.perl.org/parrot/trunk parrot-trunk Me: > svn: Unrecognized URL scheme 'https://svn.perl.org/parrot/trunk' > >I don't know why. I have OpenSSL installed in /usr/local where >svn should have found it when building. Bob Rogers: > I had the same problem just last week. To fix it, I upgraded to > Subversion 1.3.0 from the tarball, and discovered that you don't get > HTTPS support unless you explicitly specify the "--with-ssl" option to > configure, which I hadn't realized when I installed 1.1.3. Alas that didn't work. Even presetting CCFLAGS, CPPFLAGS, and every other sort of flags I could find documented, and passing all the --with-xxx options specifying the full path locations to OpenSSL, the build process would find it using the C compiler, but then trample on the CPPFLAGS and fail to find them with the preprocessor, and then conclude that I didn't have OpenSSL installed (even though it had just successfully correctly identified my OpenSSL version in the previous step!) Much painful hand editing of configure scripts and makefiles later, it turns out that the http: vs. https: stuff doesn't make any significant difference. Oh well. Running svn under truss didn't help either -- no particular type of syscall stood out as being slow. Executive summary -- svn co on Solaris 8 is still *slow*! I"ll stick to fetching snapshots with wget. -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Compiling Parrot on NetBSD
On Wed, 1 Mar 2006, Steve Peters wrote: > Thanks to the work that's already been done, it was very easy to get NetBSD up > and running. The attached patch is all that's needed to add NetBSD support to > Parrot. I don't know the answer myself, but I was wondering: Have all the various *BSD distributions drifted apart far enough that it makes sense to maintain completely independent hints and platform directories for each? -- Andy Dougherty [EMAIL PROTECTED]
Re: svn performance
On Sat, 4 Mar 2006, Leopold Toetsch wrote: > > On Feb 28, 2006, at 19:27, Andy Dougherty wrote: > > > > > Executive summary -- svn co on Solaris 8 is still *slow*! I"ll stick > > to fetching snapshots with wget. > > Dumb question? Why 'svn co' instead of incrementally updating with 'svn up'? It's not a dumb question. I only occasionally have a chance to work on Parrot. For a variety of reasons, including disk space limitations, I find it inconvenient to keep an svn copy locally. -- Andy Dougherty [EMAIL PROTECTED]
Re: Perl 6 on Solaris 10 anyone ?
On Tue, 28 Mar 2006, Stefan Parvu wrote: > Any experiments with Perl6/Parrot and Solaris Express > or Solaris 10 ? Im curious how much the language has > changed and how well the new VM would work in Solaris > ... > > Is there any Solaris x86 or sparc package of the new > Parrot VM ? I'm not aware of any pre-built packages, but the Parrot VM should build and past most of its tests on either Solaris x86 or SPARC. There is no official "Perl6" yet, but there is considerable development in the Pugs project http://www.pugscode.org . In order to run pugs, you'll need the ghc Haskell compiler http://www.haskell.org/ghc/. In order to build ghc, you need a pre-existing ghc, though there are some binary packages available. There is no pre-built Solaris/x86 ghc package. There is one for Solaris/SPARC, but you'll have to install some additional libraries first. (See the ghc download page for details.) Last time I checked, not all those libraries built for me on Solaris 8, so I was never able to get ghc (and hence pugs) up and running. You may have better luck on Solaris 10, or the libraries may have been fixed since then. Hope this helps, -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38957] hash test failures
On Fri, 21 Apr 2006, Will Coleda wrote: > OSX 10.4.6, PPC > > This failure has been pretty persistent the past few weeks: > > t/src/hash.t1 256111 9.09% 6 > > # got: '42 > # hash_6(4373,0xa000ed98) malloc: *** error for object 0x1d14140: > incorrect checksum for freed object - object was probably modified > after being freed, break at szone_error to debug > # hash_6(4373,0xa000ed98) malloc: *** set a breakpoint in szone_error > to debug > # hash_6(4373,0xa000ed98) malloc: *** error for object 0x1d14140: > incorrect checksum for freed object - object was probably modified > after being freed, break at szone_error to debug > # hash_6(4373,0xa000ed98) malloc: *** set a breakpoint in szone_error > to debug > # ' > # expected: '42 That test has been dumping core for me (Solaris 8/SPARC) for quite a long time (since last summer at least, I think). I tried to see if it's still there in the current code, but my build & test script aborted at the Configure.pl stage (due to the changed perl version requirements). -- Andy Dougherty [EMAIL PROTECTED]
What version of perl is required?
README says: You'll also need Perl 5.6 or above to run various configure and build scripts. but Configure.pl complains $ perl Configure.pl Perl v5.8.0 required--this is only v5.6.2, stopped at Configure.pl line 243. BEGIN failed--compilation aborted at Configure.pl line 243. I have no strong opinion on which version to use, but the two files ought to agree. -- Andy Dougherty [EMAIL PROTECTED]
Re: What version of perl is required?
On Fri, 21 Apr 2006, Will Coleda wrote: > There was an agreement on 5.6.1 a few weeks back on IRC, if I recall > correctly, I haven't heard anything about 5.8. That reminds me: Is #parrot logged anywhere? Or, if not, are significant disucssions or decisions logged or archived anywhere? -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] Re: What version of perl is required?
On Sun, 23 Apr 2006, Bernhard Schmalhofer wrote: > Will Coleda schrieb: > > > This change was made here: > > > > r11744 | bernhard | 2006-02-26 05:55:39 -0500 (Sun, 26 Feb 2006) | 7 lines > > > > Bernhard, was the upgrade to 5.8 intentional and necessary? > > In February I was fairly sure that Perl 5.8.0 was already required. But I must > have mixed that up > as I can't find that mentioned on p6i. > > The reason for making an explicit check was that I didn't recall whether > 'our' was introduced in 5.6.0 or 5.8.0. As 'our' was introduced in 5.6.0, > I have lowered the requirements for Configure.pl to 5.006. Thanks, but, alas, it now fails at Determining whether ICU is installedno.Perl v5.8.0 required--this is only v5.6.2, stopped at lib/Parrot/Revision.pm line 25. The patch included below changes lib/Parrot/Revision.pm and lib/Parrot/Distribution.pm back to 5.006, and appears to be the minimal change needed to get back to building with perl-5.6.x. Looking further, the following files still require 5.008: ./languages/m4/lib/Parrot/Test/M4/Gnu.pm:use 5.008; ./languages/m4/lib/Parrot/Test/M4/PIR.pm:use 5.008; ./languages/m4/lib/Parrot/Test/M4.pm:use 5.008; ./languages/m4/tools/scrutinize.pl:use 5.008; I haven't looked in languages/m4 for a long time, so I don't have any useful comment on those. ./lib/Pod/Simple/TranscodeSmart.pm:use 5.008; This contains the singularly unhelpful comment: ## Anything before 5.8.0 is GIMPY! I have no idea what that was intended to mean. ./t/codingstd/cppcomments.t:use 5.008; Offhand, I don't see why ./t/codingstd/cppcomments.t really needs 5.008, but I haven't had time check it out carefully. ./tools/dev/check_source_standards.pl:use 5.008; ./tools/dev/mk_manifest_and_skip.pl:use 5.008; These are developer tools; their requirements needn't be the same as those required for ordinary users to build parrot. As before, I have no strong opinion on which version to use, but the main parrot README certainly ought to reflect reality. diff -r -u parrot-current/lib/Parrot/Distribution.pm parrot-andy/lib/Parrot/Distribution.pm --- parrot-current/lib/Parrot/Distribution.pm Tue Mar 14 19:15:06 2006 +++ parrot-andy/lib/Parrot/Distribution.pm Mon Apr 24 12:07:49 2006 @@ -31,7 +31,7 @@ use strict; use warnings; -use 5.008; +use 5.006; use Data::Dumper; use ExtUtils::Manifest; diff -r -u parrot-current/lib/Parrot/Revision.pm parrot-andy/lib/Parrot/Revision.pm --- parrot-current/lib/Parrot/Revision.pm Sat Mar 4 19:15:04 2006 +++ parrot-andy/lib/Parrot/Revision.pm Mon Apr 24 12:07:43 2006 @@ -22,7 +22,7 @@ use strict; use warnings; -use 5.008; +use 5.006; our $svn_entries = undef; -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38978] [PATCH] Fix unitialized register error in t/pmc/file.t
On Tue, 25 Apr 2006, Leopold Toetsch via RT wrote: > On Apr 25, 2006, at 17:34, Andy Dougherty (via RT) wrote: > > > Previously, I expect the only reason it was passing for some folks is > > that > > unused I registers are somehow automatically set to 0 on Linux/x86. > Unitialized I and N regs have more or less garbage. Sort of. It turns out they are automatically set to 0 only for a debugging build. For a non-debugging build, they also sometimes end up being zero, but not always. This is likely architecture and compiler dependent. In the past, this has masked at least three problems in the test suite where uninitialized registers were inadvertantly used. >See also: > $ ./parrot --help-debug > $ ./parrot -D40 ... Unfortunately, that doesn't necessarily do anything. The problem is that -D40 (unlike many of the other -D flags) is only effective if you are running a debugging build, which I'm not. $ cat try1.pir .sub main :main print "I1 = " print I1 print "\n" .end $ ./parrot try1.pir I1 = 0 $ ./parrot -D40 try1.pir I1 = 0 Here's an example that does generate something in a non-initialized register. It turns out to be rather sensitive to the details of the file. Small changes make the value of '4437328' turn to either '37' or '0'. $ cat try2.pir .sub main :main $P1 = new .File $S1 = "src" $I1 = $P1."is_file"($S1) print "$S1 = " print $S1 print "\n" print "$I1 = " print $I1 print "\n" print "I1 = " print I1 print "\n" ok1: print "ok 1\n" ok2: print "ok 2\n" end .end $ ./parrot try2.pir $S1 = src $I1 = 0 I1 = 4437328 ok 1 ok 2 -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38957] hash test failures
On Fri, 21 Apr 2006, Andy Dougherty wrote: > On Fri, 21 Apr 2006, Will Coleda wrote: > > > OSX 10.4.6, PPC > > > > This failure has been pretty persistent the past few weeks: > > > > t/src/hash.t1 256111 9.09% 6 > > > > # got: '42 > > # hash_6(4373,0xa000ed98) malloc: *** error for object 0x1d14140: > > incorrect checksum for freed object - object was probably modified > > after being freed, break at szone_error to debug > > # hash_6(4373,0xa000ed98) malloc: *** set a breakpoint in szone_error > > to debug > > # hash_6(4373,0xa000ed98) malloc: *** error for object 0x1d14140: > > incorrect checksum for freed object - object was probably modified > > after being freed, break at szone_error to debug > > # hash_6(4373,0xa000ed98) malloc: *** set a breakpoint in szone_error > > to debug > > # ' > > # expected: '42 > > That test has been dumping core for me (Solaris 8/SPARC) for quite a long > time (since last summer at least, I think). I tried to see if it's still > there in the current code, but my build & test script aborted at the > Configure.pl stage (due to the changed perl version requirements). This test still core dumps for me. I've traced it down a good bit -- it's a garbage collection problem. Specifically, in t/src/hash_6.c, the variable 'hash' is declared in the function 'the_test', and memory allocated with hash = PMC_struct_val(h); A big string 'big' is then created. The program then calls string_from_cstring(). The ensuing sequence is something like (This is all from printf() statements -- the debugger gets confused, as do I!): string_from_cstring() -> string_make_direct() -> Parrot_allocate_string() -> mem_allocate() -> Parrot_dod_ms_run() -> Parrot_forall_header_pools() -> sweep_cb() -> Parrot_dod_sweep() ... ??? ... mem_sys_free() -> free(from) where from == hash. (At the ??? point, I lose track of what's happening) Not surprisingly, the program crashes later on at hash_put(interpreter, hash, key, i); Unfortunately, this failure is in the dod_sweep() stuff, which I really don't understand at all, so I don't know how to proceed from here. -- Andy Dougherty [EMAIL PROTECTED]
Re: MSWin32 (Visual C++ 8.0) Test Results (r12442)
On Thu, 27 Apr 2006, jerry gay wrote: > On 4/27/06, Ron Blaschke <[EMAIL PROTECTED]> wrote: > > Here's another round of test results on my box. I've also added the > > details for the tests that failed. The C and > > are not unexpected on Windows. > > > > > Failed Test Stat Wstat Total Fail Failed List of Failed > > --- > > t/doc/pod.t3 768 11663 0.26% 24 738 820 > fixed, r12443. > > > t/op/calling.t 1 256921 1.09% 91 > > t/pmc/complex.t1 256531 1.89% 33 > > t/pmc/env.t2 512122 16.67% 9-10 > > t/pmc/objects.t1 256731 1.37% 73 > these are all expected, at the moment. They are? Is the list of "expected failuers" anywhere obvious? I don't see it anywhere obvious either in the source or in the recent perl6-internals archives. Perhaps I've missed it somewhere. -- Andy Dougherty [EMAIL PROTECTED]
Hundreds of errors?
430-431 433- 434 437-438 441-443 450- 451 456-457 481-482 486 494 497 499 513-514 516- 521 525-526 529-530 533- 535 537-539 542 546-547 550-552 555 558-562 565 567 608 618- 620 622 626 636-638 640 644 654-662 672-680 690- 692 694 698 708-716 726- 734 744-746 748 752 762- 770 780-788 798-799 t/compilers/pge/p6rules/backtrack 21 537621 21 100.00% 1-21 t/compilers/pge/p6rules/builtins. 68 1740873 68 93.15% 1-60 63-70 t/compilers/pge/p6rules/capture.t 45 1152045 45 100.00% 1-45 t/compilers/pge/p6rules/cclass.t58 1484862 58 93.55% 1-18 20-55 57- 60 t/compilers/pge/p6rules/closure.t6 1536 66 100.00% 1-6 t/compilers/pge/p6rules/context.t 19 486420 19 95.00% 1-15 17-20 t/compilers/pge/p6rules/metachars 192 49152 208 192 92.31% 1-65 68 70-78 81 85 87 89-95 97-101 107-208 t/compilers/pge/p6rules/modifiers 94 2406498 94 95.92% 1-86 88-91 93- 96 t/compilers/pge/p6rules/subrules.6 1536 66 100.00% 1-6 t/compilers/pge/p6rules/text_brk. 11 281612 11 91.67% 2-12 t/compilers/pge/pge-hs.t 1 256 11 100.00% 1 t/compilers/pge/pge_examples.t 2 512 22 100.00% 1-2 t/compilers/pge/pge_globs.t 22 563222 22 100.00% 1-22 t/compilers/pge/pge_util.t 1 256 11 100.00% 1 t/compilers/tge/basic.t 2 512 32 66.67% 1 3 t/compilers/tge/grammar.t1 256 11 100.00% 1 t/compilers/tge/parser.t 1 256 11 100.00% 1 Failed Test Stat Wstat Total Fail Failed List of Failed --- t/library/dumper.t 24 614426 24 92.31% 1-15 18-26 t/library/test_more.t1 256308 26.67% 27-30 t/op/calling.t 1 256921 1.09% 91 t/op/jitn.t 2 512142 14.29% 8 11 t/pmc/complex.t 6 1536536 11.32% 32-33 42-43 46-4Failed 28/233 test scripts, 87.98% okay. 972/4650 subtests failed, 79.10% okay. 7 t/pmc/intlist.t 2 512102 20.00% 3-4 t/pmc/objects.t 2 512732 2.74% 62 73 t/pmc/resizablebooleanarray.t1 256211 4.76% 16 t/pmc/resizablestringarray.t 1 256281 3.57% 21 t/src/hash.t 1 256111 9.09% 6 11 tests and 387 subtests skipped. -- Andy Dougherty [EMAIL PROTECTED]
Re: Hundreds of errors?
On Fri, 28 Apr 2006, Patrick R. Michaud wrote: > On Fri, Apr 28, 2006 at 11:02:53AM -0400, Andy Dougherty wrote: > > Something's gone horribly wrong after the recent PGE check-in. I don't > > actually think it's in PGE, just that the new PGE is triggering some other > > bugs elsewhere in parrot (that have been showing up in t/library/dumper.t > > recently). I don't recall such problems in parrot-0.4.2. I didn't test > > parrot-0.4.3. > > > > The first sign of trouble is during the build process: > > It seems to be working for me -- could you give us more details > about your build environment? OS, Platform, etc? Oh, yes, sorry about that. This is Solaris 8/SPARC with Sun's C compiler. As I said, I don't think it's PGE itself, but rather that PGE is running into some more basic problem. On further investigation, I've found that the t/library_dumper.t problems were also present in parrot-0.4.3, but not in parrot-0.4.2. The failures also seem at least superficially similar to those I've reported in languages/punie/past* (see [perl #38406]). On a possibly-related, but also possibly-unrelated note, I'm also getting a failure on test t/pmc/objects_62.pasm: # Failed test (t/pmc/objects.t at line 1866) # got: '11 # 11 # 20 # 21 # 11 # 20 # ' # expected: '10 # 11 # 20 # 21 # 10 # 20 # ' This looks similar, but this test was also failing for me in 0.4.2, so it may be unrelated. > I will note that I've noticed a few oddities in dealing with Hashes > and PMCs lately, but nothing that I've been able to boil down to a > reasonable test case. I know the feeling, have spent way too much time this week chasing a core dump in t/src/hash_6.c. -- Andy Dougherty [EMAIL PROTECTED]
Re: Getting to hello world?
On Sun, 21 May 2006, James Peregrino wrote: > You folks took me too literally :) I meant: Given a system without > pugs/parrot/haskell (I assume perl5 is required), what are the things you > need to install so that you can say > > perl6 -e "say 'hello world'" > > i.e. > > tar xf ghc.tar.gz > ./configure > make > make install To build GHC, you need a pre-existing, relatively recent version of GHC. Cross-compiling GHC is documented fairly carefully, but I haven't tried it myself. There are pre-built binaries available for a few of the most common architecture/operating system combinations. > tar xf parrot.tar.gz > make > make test > make install Here too, the core developers only have access to a limited set of architecture/operating system combinations. In principle, parrot ought to build and run just fine on many of the places where perl 5 currently does. In practice, it doesn't. Patches to make it do so would likely be welcome. > tar xf pugs.tar.gz > perl Makefile.PL > make > make test > make install I've never made it past the haskell barrier, so I can't comment on how well this works. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #39188] imcc dumps core when called with -o file.pasm.
On Wed, 24 May 2006, Leopold Toetsch via RT wrote: > Am Dienstag, 23. Mai 2006 19:09 schrieb Andy Dougherty: > > As of this morning's snapshot (Tue May 23 07:15:07 2006 UTC) The > > following additional 90 tests dump core. They didn't do that last > > week. > > Silly error fixed. /Me wonders though, why this tested ok on x86/linux and > OS/X darwin. It's a Test.pm bug. I just filed an analysis of it in [perl #39197] lib/Parrot/Test.pm ignores core dumps failures! -- Andy Dougherty [EMAIL PROTECTED]
Re: RFC: Patch for mingw-msys
On Fri, 26 May 2006, Joshua Gatcomb wrote: > All: > In tracking down why building parrot with mingw was failing, I discovered > that the culprit was having msys in my PATH even if I wasn't intentionally > trying to use it. > > There are 3 interesting things to note: > 1. It does not matter what msys is actually called - renaming the directory > to foo has the same effect > 2. It does not matter where in the PATH it appears - placing it after mingw > has no effect > 3. Changing the PATH has no effect on the configuration cycle - only the > build cycle > > Running mingw32-make with the -d (debug) flag on revealed what is going on. > It scans PATH, using an internal routine called find_and_set_shell, looking > for sh.exe which changes path delimiters and shell escapes. > > The obvious fix is to do exactly what mingw32-make is doing and warn the > user that the subsequent mingw32-make is going to fail. > > This is where the request for comments comes in. > > config/init/hints/mswin32.pm is where the mingw specific settings are set > up. The $make variable obtained at this point is nmake, but it would still > be possible to probe $ENV{PATH}, discover if sh.exe exists, and warn the > user. > > Configure.pl ends by telling the user the next step. Use $make, which has > changed from nmake to mingw32-make along the way, which is bound to fail. > Perhaps this is the spot where it is appropriate to warn the user. > > I don't mind writing the patch but as I have been away for 1.5 years I would > really like to hear the opinions of where is the best way to do it. I don't know anything about either msys or mingw, so I don't really know what to recommend. I'm afraid I don't understand what a patch would actually try to do. >From your previous message, it looks like sh.exe is changing the path delimiters and shell escapes so that things don't work anymore. Are you trying to patch Configure.pl to handle those changed delimiters and shell esacapes? Or do you have something else in mind? Also, what's the preliminary setting of $make got to do with it? You've still got to call some sort of make command in the end. If you're just wondering where '$make' gets set, then config/inter/make.pm is where to look -- it seems to prefer mingw32-make over nmake. Perhaps that's wrong. -- Andy Dougherty [EMAIL PROTECTED]
Stepping Away.
I will be stepping away from Parrot for the foreseeable future. As part of my clean-up process, I have sent in any patches I still had pending. Apply them, or not, as seems appropriate. I have also gone through my unresolved RT tickets and verified that they are still relevant, though I will likely not be available to test any proposed solutions. Again, feel free to deal with them, or not, as appropriate. Good luck to you all. -- Andy Dougherty [EMAIL PROTECTED]
Perl6 without GHC or Parrot?
Intriguied by the recent posts on Audrey's blog (http://pugs.blogs.com/pugs) about Deploying Perl6 Now, I decided to take a look and see what was possible on a system which runs neither GHC or Parrot. I recall hearing about misc/pX/Common/lrep before, but it looks like it's only a very beginning implementation -- it handles a few simple constructs, but fails on many others. Today's blog post says there's a "new Perl5-based Perl6 compiler:" use v6-pugs; "hello, world".say; $ perl -Ilib hello_world.pl So I thought I'd try it out. Alas, it doesn't work either. First, I had to install Module::Compile (which, in turn, required Test::Base, which, in turn, required Spiffy). Then I had to install PadWalker. When all that was done, it failed with: Can't locate object method "compile" via package "Pugs::Compiler::Perl6" at lib/v6.pm line 41. Compilation failed in require at lib/../../Pugs-Compiler-Rule/lib/Pugs/Grammar/Rule.pm line 18. BEGIN failed--compilation aborted at lib/../../Pugs-Compiler-Rule/lib/Pugs/Grammar/Rule.pm line 18. Compilation failed in require at lib/../../Pugs-Compiler-Rule/lib/Pugs/Compiler/Regex.pm line 10. BEGIN failed--compilation aborted at lib/../../Pugs-Compiler-Rule/lib/Pugs/Compiler/Regex.pm line 10. Compilation failed in require at (eval 1) line 3. ...propagated at /opt/perl/lib/5.8.8/base.pm line 85. BEGIN failed--compilation aborted at lib/../lib/Pugs/Compiler/Perl6.pm line 9. Compilation failed in require at lib/v6.pm line 40. What am I missing? Or is it just not possible to run any of this stuff without GHC? -- Andy Dougherty [EMAIL PROTECTED]
Re: Perl6 without GHC or Parrot?
On Thu, 22 Jun 2006, Flavio S. Glock wrote: Please install Pugs::Compiler::Rule (from CPAN or Pugs repo). Thanks for testing! Ah. Ok. Installing Module::Compile, Test::Base, Spiffy, PadWalker, Parse::Yapp, and then Pugs::Compiler::Rule, I get to the point where $ cd misc/pX/Common/Pugs-Compiler-Perl6 $ perl -Ilib hello_world.pl actually works. Well done! Still, it fails the following tests in 01-sanity: 07-for.t 07-isa.t 07-range.t 07-ref.t 07-simple-multisubs.t 07-tailcall.t 08-test.t as well as nearly all of the other tests under t/. I imagine you already knew that, but I didn't, and others reading the blog might not be aware either. One other oddity: You can't run the test file twice without cleaning up the generated .tc files first. Specifically: $ perl -Ilib 01-sanity/01-tap.t [ works ] $ perl -Ilib 01-sanity/01-tap.t Unmatched right curly bracket at 01-sanity/01-tap.tc line 7, at end of line syntax error at 01-sanity/01-tap.tc line 7, near "}" Anyway, it's remarkable how much you've accomplished. Thanks, and good luck. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #39050] Build failure in compilers/pge/pgc.pir
On Thu, 29 Jun 2006, Patrick R. Michaud via RT wrote: > > The build process for the current (Tue May 2 07:15:06 2006 UTC) > > parrot snapshot dies when trying to run compilers/pge/pgc.pir: > > Is this still the case with later versions of Parrot -- i.e., can I > close this ticket? The last time I looked, on May 30, the problem was still there. Beyond that, I wouldn't know. -- Andy Dougherty [EMAIL PROTECTED]
Re: the CGI.pm in Perl 6
On Wed, 13 Sep 2006, David Cantrell wrote: > I wonder how many people really use the HTML-generating bits of CGI.pm? I'd guess a lot, since they are prominently documented in the CGI.pm documentation and are used extensively throughout many of the examples there. It would be quite natural for anyone who learned to use CGI.pm by reading its documentation to use those bits. Also, a simple Google search for them turns up lots and lots of hits. > I know I never have, nor have they been used that I can remember > anywhere that I've worked, or in any of the non-work projects I've > collaborated in. It's always been 'print ""' or more recently > using a templating language like TT. Yep, I'm sure there's a lot of that too. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38584] [BUG] Punie test failures in set_node method on Solaris/SPARC
called from Sub 'parrot;PGE::P6Regex;compile_p6regex' pc 6463 (compilers/pge/PGE/P6Regex.pir:95) called from Sub 'parrot;PGE::P6Grammar::Compiler;__onload' pc 45 (runtime/parrot/library/PGE/P6Grammar.pir:80) called from Sub 'main' pc 3 (pgc.pir:48) *** Error code 1 make: Fatal error: Command failed for target `PGE.pbc' Current working directory /home/doughera/src/parrot/parrot-andy/compilers/pge *** Error code 1 make: Fatal error: Command failed for target `compilers.dummy' Not surprisingly, punie doesn't work: $ cd languages/punie; make ../../parrot ../../compilers/pge/pgc.pir --output=lib/punie_grammar_gen.pir lib/punie.pg Couldn't find file 'PGE.pbc' current instr.: 'parrot;PGE::P6Grammar::Compiler;__onload' pc 22 (runtime/parrot/library/PGE/P6Grammar.pir:71) called from Sub 'main' pc 3 (../../compilers/pge/pgc.pir:48) *** Error code 1 make: Fatal error: Command failed for target `lib/PunieGrammar.pbc' All of which looks vaguely similar to the last time I tried to get anywhere with parrot, though I could have guessed wrong in the patch above. So anyway, go ahead and close the ticket. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38584] [RESOLVED] [BUG] Punie test failures in set_node method on Solaris/SPARC
On Tue, 9 Jan 2007, Will Coleda via RT wrote: > According to our records, your request regarding > "[BUG] Punie test failures in set_node method on Solaris/SPARC" > has been resolved. > > If you have any further questions or concerns, please respond to this message. > > For other topics, please create a new ticket. > > Please don't feel obligated to say "Thanks" or "Kudos" or "I owe you a > beer" -- if you respond to this message it will reopen the ticket. If > you must, please send email directly to the person who handled your > ticket, and not to the tracking system. Of course since the email address of the "person who handled your ticket" doesn't show up in the mail header, that's not easy to do. Sigh. I'll go in and manually re-close the ticket. -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Quiet a few alignment warnings
On Wed, 14 Mar 2007, Will Coleda via RT wrote: > Re: [perl #37178] [PATCH] Quiet a few alignment warnings > Thanks, (belatedly) applied. Wow. I'd completely given up hope on that one. So feeling inspired, I decided to try it out and see how things looked. Alas, my first attempt failed: $ rsync -av --delete svn.perl.org::parrot-HEAD parrot-current failed to connect to svn.perl.org - Connection refused I then tried fetching a snapshot. That seemed to work. There doesn't seem to be an obvious way to get the svn revision number out of it, but here's the timestamp: $ cat .timestamp 1174288505 Mon Mar 19 07:15:05 2007 UTC (time of this svn update) This one falls over immediately during Configure. Even setting verbose=2, I don't see why: Parrot Version 0.4.9 Configure 2.0 Copyright (C) 2001-2007, The Perl Foundation. [ . . . ] Determining what C compiler and linker to use... No compiler found (tried 'cc') Yet 'cc' works perfectly fine, and has for years. I have changed nothing in my build scripts. Oh well, back to other work instead. Thanks for applying my patch, though. Maybe someone else will pick up the task and try to document and check parrot's alignment assumptions -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #41168] graceful "no compiler" error message?
I found the ticket that introduced this failing behavior, so I'm resending my message below with a fixed-up subject line to enter into RT. In brief, this patch incorrectly assumes that all compilers accept a '-h', '--help', or '/?' switch. Any compiler that doesn't is deemed 'not found', and there is no way to override it. Extending the list of options to try is not a sensible forward-looking portable strategy. On Mon, 19 Mar 2007, Andy Dougherty wrote: > On Mon, 19 Mar 2007, chromatic wrote: > > > On Monday 19 March 2007 08:19, Andy Dougherty wrote: > > > > > This one falls over immediately during Configure. Even setting > > > verbose=2, I don't see why: > > > > > > Parrot Version 0.4.9 Configure 2.0 > > > Copyright (C) 2001-2007, The Perl Foundation. > > > > > > [ . . . ] > > > > > > Determining what C compiler and linker to use... > > > No compiler found (tried 'cc') > > > > > > Yet 'cc' works perfectly fine, and has for years. I have changed > > > nothing in my build scripts. > > > > The heuristic for detecting a compiler is to invoke it with some sort of > > help > > flag, where $cc contains the executable name of your compiler: > > > > $cc -h > > $cc --help > > $cc /? > > > > If there's another option to pass to your compiler that causes it to do > > nothing except exit with a successful error code, we can put it in there. > > (Checking $ENV{PATH} and trying to divine the proper extension is another > > option, but I like that one a little less.) > > In my opinion, that way lies madness. Generating a list of options which > all possible current and future compilers will accept is not only > impossible, it's pointless. It's also aggravating that there's no way to > override it or tell Configure "Yes, cc is my compiler even though it's not > in your list." > > The only way to tell for sure if you have a working compiler is to try to > compile and run something. After the user has been prompted for all the > flags, simply try to compile and run a simple test program. If it works, > fine. If it doesn't, then complain with an informative error message. (It > may be appropriate to skip the 'run' step in a cross-compilation > environment and hope that the user got the flags right if the compilation > succeeds.) > > -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Quiet a few alignment warnings
On Mon, 19 Mar 2007, chromatic wrote: > On Monday 19 March 2007 08:19, Andy Dougherty wrote: > > > This one falls over immediately during Configure. Even setting > > verbose=2, I don't see why: > > > > Parrot Version 0.4.9 Configure 2.0 > > Copyright (C) 2001-2007, The Perl Foundation. > > > > [ . . . ] > > > > Determining what C compiler and linker to use... > > No compiler found (tried 'cc') > > > > Yet 'cc' works perfectly fine, and has for years. I have changed > > nothing in my build scripts. > > The heuristic for detecting a compiler is to invoke it with some sort of help > flag, where $cc contains the executable name of your compiler: > > $cc -h > $cc --help > $cc /? > > If there's another option to pass to your compiler that causes it to do > nothing except exit with a successful error code, we can put it in there. > (Checking $ENV{PATH} and trying to divine the proper extension is another > option, but I like that one a little less.) In my opinion, that way lies madness. Generating a list of options which all possible current and future compilers will accept is not only impossible, it's pointless. It's also aggravating that there's no way to override it or tell Configure "Yes, cc is my compiler even though it's not in your list." The only way to tell for sure if you have a working compiler is to try to compile and run something. After the user has been prompted for all the flags, simply try to compile and run a simple test program. If it works, fine. If it doesn't, then complain with an informative error message. (It may be appropriate to skip the 'run' step in a cross-compilation environment and hope that the user got the flags right if the compilation succeeds.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Quiet a few alignment warnings
> On Monday 19 March 2007 11:56, Andy Dougherty wrote: > > > The only way to tell for sure if you have a working compiler is to try to > > compile and run something. After the user has been prompted for all the > > flags, simply try to compile and run a simple test program. If it works, > > fine. If it doesn't, then complain with an informative error message. (It > > may be appropriate to skip the 'run' step in a cross-compilation > > environment and hope that the user got the flags right if the compilation > > succeeds.) On Mon, 19 Mar 2007, chromatic wrote: > > What's the minimally-useful, cross-platform way to compile, link, and run: > > int main() { > return 0; > } > > I'm happy to make the change, but I spent the weekend struggling to figure > out > how MSVC handles shared libraries, and I'm no longer sure that the easy > approach is that easy. You can probably get by with whatever scheme is currently used to compile, link, and run all the other tests in Configure, such as those to determine sizeof(opcode_t) and the like. Perl 5's Configure uses the following program: #include int main() { printf("Ok\n"); return(0); } The program includes output, and Configure tests for that output, because we ran into cases where the program would compile, run, return a 'success' exit value, but wouldn't actually print anything. The underlying problem turned out to be a bug in SFIO's "iffe" configuration script (dealing with _exit vs. exit, and the flushing of output buffers). So our "sanity" test was expanded to include testing whether or not the program actually printed what it was supposed to print. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #41168] graceful "no compiler" error message?
On Tue, 20 Mar 2007, chromatic wrote: > On Tuesday 20 March 2007 12:25, Andrew Dougherty wrote: > > > On Mon, 19 Mar 2007, chromatic wrote: > > > > I realize this patch precludes cross-compilation at the moment, but does > > > it work better for you, Andy? > > > > Alas, no. Here's what I get (again with --verbose=2). I don't know why > > it's reporting that the compiler is failling, and I don't know how to > > coax Configure to give me any more information (short of sprinking > > printf()s throughout). > > > > I can definitely compile that test program with the indicated flags. I > > don't have time to look at this further, however. > > Alright, I'll work on a better patch. We've pulled the previous one from the > upcoming release. Ok. I've figured out what was going wrong: +unless ( eval { cc_build(); 1 } ) { +warn "Compilation failed with '$cc'\n"; +exit 1; +} This has two problems. First, it ignores the return value of cc_build(). That's understandable at the moment since cc_build doesn't seem to have a documented return value. It should, of course. The second problem is that this construct doesn't check for other errors in the eval. Putting in C< warn $@ if $@;> reveals the problem: Determining what C compiler and linker to use...Unknown open() mode '>&' at lib/Parrot/Configure/Step.pm line 437. Configure/Step.pm is apparently using a 3-arg open construct not understood by my perl-5.6.2 version. But according to README: You'll also need Perl 5.6.1 or above to run various configure and build scripts. The README is also consistent with this line in Configure.pl: use 5.006_001; So all that needs to be straightened out somehow, either by changing the 3-arg opens or by upping the perl version requirement. Moving on: +unless ( eval { cc_run(); 1 } ) { +warn $@ if $@; +exit 1; +} This also has the same ignoring-error return problem, but it's more serious. If the program runs but fails (e.g. segfaults, or returns a non-zero status) this bit of code happily continues on. I think it probably shouldn't under such circumstances. Of course, even after fixing those things, it still doesn't even come close to working. More about that tomorrow as I try to sort out all the other problems. Sigh. -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] void functions can't return values.
Void functions can't try to return anything. I haven't checked if this patch is "right" or not. The documentation for Parrot_set_attrib_by_num() claims it returns a PMC *, but the source code uses 'void' and doesn't actually return anything. I don't know what the intended behavior actually is. This patch at least lets it compile. --- parrot-current/src/pmc/parrotobject.pmc 2007-03-16 11:15:15.0 -0400 +++ parrot-andy/src/pmc/parrotobject.pmc2007-03-21 11:50:28.569996000 -0400 @@ -207,8 +207,10 @@ PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v); if (PMC_IS_NULL(sub)) sub = find_meth(interp, SELF, meth); -if (PMC_IS_NULL(sub)) -return Parrot_set_attrib_by_num(INTERP, SELF, idx, value); +if (PMC_IS_NULL(sub)) { +Parrot_set_attrib_by_num(INTERP, SELF, idx, value); +return ; +} (PMC*) Parrot_run_meth_fromc_args(interp, sub, SELF, meth, "vIP", idx, value); } @@ -219,8 +221,10 @@ PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v); if (PMC_IS_NULL(sub)) sub = find_meth(interp, SELF, meth); -if (PMC_IS_NULL(sub)) -return Parrot_set_attrib_by_str(INTERP, SELF, idx, value); +if (PMC_IS_NULL(sub)) { +Parrot_set_attrib_by_str(INTERP, SELF, idx, value); +return; +} (PMC*) Parrot_run_meth_fromc_args(interp, sub, SELF, meth, "vSP", idx, value); } -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] Avoid //-style comments.
Please avoid //-style comments. Older compilers don't understand them. Also, and more importantly, this section of code has several commented out lines, but no comments explaining why those lines are commented out. It makes it more difficult to understand. --- parrot-current/lib/Parrot/Pmc2c/PMETHODs.pm 2007-03-17 19:15:14.0 -0400 +++ parrot-andy/lib/Parrot/Pmc2c/PMETHODs.pm2007-03-21 11:56:34.73000 -0400 @@ -439,7 +439,7 @@ /* if (PMC_cont(ccont)->address) { */ { -//parrot_context_t * const caller_ctx = PMC_cont(ccont)->to_ctx; +/* parrot_context_t * const caller_ctx = PMC_cont(ccont)->to_ctx; */ if (! caller_ctx) { /* there is no point calling real_exception here, because PDB_backtrace can't deal with a missing to_ctx either. */ -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] Hints must come early in Configure.pl
Hints need to come *before* inter/progs. The hints set up various platform-specific callbacks to be performed after the different programs are selected. Actually, I suspect they should even come before the init::install unit. Certainly in perl5's hints, there are a number that modify the default installation directories. However, I don't understand parrot's installation plan, so I have left this alone. --- parrot-current/Configure.pl Sat Mar 17 18:15:17 2007 +++ parrot-andy/Configure.plWed Mar 21 11:05:41 2007 @@ -463,9 +463,9 @@ init::defaults init::install init::miniparrot -inter::progs init::hints init::headers +inter::progs inter::make inter::lex inter::yacc -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] Suppress optimization on core_ops_cgp.c
core_ops_cgp.c usually overwhelms my system. It's a combination of the compiler and the system. It apparently doesn't cause problems elsewhere. Alas, there appears no more narrowly-focused approach other than to turn off optimization for everyone, so that's what this patch does. Better would be a way for specific end-users to specify this -- either via command line options or hints file overrides, or something. --- parrot-current/config/gen/makefiles/CFLAGS.in 2006-08-20 19:15:20.0 -0400 +++ parrot-gcc/config/gen/makefiles/CFLAGS.in 2007-03-21 12:20:04.829996000 -0400 @@ -9,6 +9,7 @@ src/spf_render.c-{-Wformat-nonliteral} # noisy src/tsq.c [EMAIL PROTECTED]@} # never optimize tsq.c! src/ops/core_ops_cg.c [EMAIL PROTECTED]@}# takes too long +src/ops/core_ops_cgp.c [EMAIL PROTECTED]@}# takes too long src/ops/core_ops_switch.c [EMAIL PROTECTED]@}# Overwhelms some compilers. src/py_func.c +{-Ipmc} # include pmc_default.h -- Andy Dougherty [EMAIL PROTECTED]
make test hangs in t/examples/shootout_1.pir
After applying the various build patches I posted earlier today, I tried running make test. Unforutnately, it appears to hang in t/examples/shootout_1.pir. It ran for about 15 hours before I finally killed it. Curiously, it hadn't racked up much CPU time at all -- ps showed '0:00'. A perl version of the same ackerman(3,9) benchmark runs to copmletion just fine, in a little under 4 mintues. This problem may have been around for quite a while. I vaguely recall having to kill this process back in January, but I was on the trail of bigger problems at the time, and just chalked it up to impatience -- not wanting to wait for the program to end. I'll look into this some more in the next week or so as time permits. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #41195] [PATCH] Hints must come early in Configure.pl
On Sat, 24 Mar 2007, chromatic wrote: > On Saturday 24 March 2007 05:26, James E Keenan wrote: > > > Andy Dougherty wrote: > > > > Hints need to come *before* inter/progs. The hints set up various > > > platform-specific callbacks to be performed after the different programs > > > are selected. Actually, I suspect they should even come before the > > > init::install unit. Certainly in perl5's hints, there are a number that > > > modify the default installation directories. However, I don't understand > > > parrot's installation plan, so I have left this alone. > > > Coke moved inter::progs to the position you recommended ($steps[6]) in > > r17671 on 2007-03-20. This essentially reverted to r16268 from a change > > made in 16416. > > We're probably just working around something weird on your system; it would > be > nice if we could figure out what it is and fix it for you. There is something weird in his system -- a broken c++ -- but the problem is that Parrot's Configure wasn't letting him override the broken c++ link with one that works. I don't know what specific issue 41180 (which introduced this problem) was trying to solve, but the proposed fix wasn't the right one. Here's why: Suppose you want to build parrot with a compiler other than the one used to build the perl that is currently running Configure.pl. For example, suppose your perl were built with gcc, but you wanted to build parrot with the vendor's cc. If inter/progs.pm runs before the platform-specific hints, how is it to know which flags to suggest? It can't. That information is in the hints file, which hasn't run yet. A reasonable question to ask then is "How can the hints file know which flags to suggest if the user hasn't even picked a compiler yet?" The answer is that it can't -- but it *can* set up a call-back or "trigger". See config/hints/solaris.pm for examples. I think what was happening in James's case is that when inter/progs.pm ran first, the subsequent run of hints/darwin.pm was *unconditionally* setting ld=c++, overriding his previous setting. A summary: The current state is correct. init::hints comes before inter::progs. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #42151] [PATCH] Assorted casting cleanups - part I
On Tue, 27 Mar 2007, Steve Peters wrote: > # New Ticket Created by Steve Peters > # Please include the string: [perl #42151] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=42151 > Thanks for taking on this Herculean task. However, one thought immediately came to mind: > > Index: src/ops/experimental.ops > === > --- src/ops/experimental.ops(revision 17785) > +++ src/ops/experimental.ops(working copy) > @@ -520,7 +520,7 @@ > Interp * const new_interp = (Interp *)PMC_data($1); > opcode_t *pc; > Interp_flags_SET(new_interp, PARROT_EXTERN_CODE_FLAG); > -pc = VTABLE_invoke(new_interp, $2, NULL); > +pc = (opcode_t *)VTABLE_invoke(new_interp, $2, NULL); > Parrot_runops_fromc_args(new_interp, $2, "P"); > goto NEXT(); > } Instead of sprinking (opcode_t *) casts everywhere, wouldn't it be better to declare the invoke() function as returning an (opcode_t *) ? Similarly for most of the other bits you patched. Wouldn't it make more sense in the long run to change the functions to say they return what they actually return? Of course you can't always do that: > Parrot_new_charset(Interp *interp) > { > -return mem_sys_allocate(sizeof (CHARSET)); > +return (CHARSET *)mem_sys_allocate(sizeof (CHARSET)); > } mem_sys_allocate() obviously can only return one type, but is used in many contexts. -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Hints must come early in Configure.pl
On Tue, 27 Mar 2007, chromatic wrote: > On Sunday 25 March 2007 05:22, James Keenan wrote: > > > On Mar 24, 2007, at 11:53 PM, chromatic wrote: > > > On Saturday 24 March 2007 09:06, James Keenan wrote: > > >> < ld='c++', ldflags=' -L/usr/local/lib > > >> -L/Users/jimk/work/fresh/blib/lib -flat_namespace ', --- > > > >>> ld='/usr/bin/g++-3.3', ldflags=' -L/usr/local/lib > > >>> -L/Users/jimk/work/fresh/blib/lib -flat_namespace ', > > Here's a quick guess; move away or rename /usr/bin/g++-3.3 temporarily, then > try Configure.pl again. Do you remember the versions of the compiler you > installed? Huh? He shouldn't have to do anything. It should all be working now. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #42151] [PATCH] Assorted casting cleanups - part I
On Tue, 27 Mar 2007, Steve Peters via RT wrote: > On Tue Mar 27 10:54:17 2007, doughera wrote: > > Instead of sprinking (opcode_t *) casts everywhere, wouldn't it be better > > to declare the invoke() function as returning an (opcode_t *) ? > > Similarly for most of the other bits you patched. Wouldn't it make more > > sense in the long run to change the functions to say they return what they > > actually return? > > > > I'll have to look into some of these a little more closely as I go > through. I should probably go through and refactor as I work on this > cleanup. I probably should reject this particular patch and look for > some lower level cleanups that might make this whole process much > easier, such as what you two have pointed out. I think you'll find a lot of lower-level cleanups are in order. Leo tended to assume all pointers could equally well point anywhere, and often ignored alignment issues. He often declared stuff (void *) when it really should have been something more specific. Unfortunately, he also tended to reject patches to try to clean it up. I wish you better luck. -- Andy Dougherty [EMAIL PROTECTED]
Warnings pass the 1 000 mark
This morning's compilation on Solaris 8, with gcc-2.8.1, and with perl-5.8.0-RC1 compiled with -Duse64bitint gave the following 1066 warnings. Many of these are, in fact, due to real, complicated, issues about what integral types to use when, and shouldn't be blindly casted away. Others, however, are not. Once perl-5.8.0 is done, I may have some time to look into some of these. In the meantime, It would be helpful if folks making patches would check that they at least don't make matters worse than they already are. Most of these warnings also show up regularly in the Alpha tinderbox clients, so it's not too hard to check if any have been added recently. A SPARC's not required either -- with the same configuration on x86, I get 921 warnings. Here are today's warnings. This is on a system with INTVAL='long long' (64 bits) but with 32-bit pointers. Casts from pointer to integer are ok, but casts the other way are suspect. (An examination of the surrounding context is necessary.) global_setup.c:23: warning: passing arg 1 of `Parrot_Array_class_init' with different width due to prototype global_setup.c:24: warning: passing arg 1 of `Parrot_PerlUndef_class_init' with different width due to prototype global_setup.c:25: warning: passing arg 1 of `Parrot_PerlInt_class_init' with different width due to prototype global_setup.c:26: warning: passing arg 1 of `Parrot_PerlNum_class_init' with different width due to prototype global_setup.c:27: warning: passing arg 1 of `Parrot_PerlString_class_init' with different width due to prototype global_setup.c:28: warning: passing arg 1 of `Parrot_PerlArray_class_init' with different width due to prototype global_setup.c:29: warning: passing arg 1 of `Parrot_PerlHash_class_init' with different width due to prototype global_setup.c:30: warning: passing arg 1 of `Parrot_ParrotPointer_class_init' with different width due to prototype global_setup.c:31: warning: passing arg 1 of `Parrot_IntQueue_class_init' with different width due to prototype interpreter.c:484: warning: passing arg 1 of `mem_sys_allocate' with different width due to prototype interpreter.c:506: warning: passing arg 2 of `pmc_new' with different width due to prototype interpreter.c:588: warning: passing arg 3 of `string_make' with different width due to prototype interpreter.c:588: warning: passing arg 5 of `string_make' with different width due to prototype interpreter.c:590: warning: passing arg 3 of `string_make' with different width due to prototype interpreter.c:590: warning: passing arg 5 of `string_make' with different width due to prototype core.ops:89: warning: cast to pointer from integer of different size core.ops:113: warning: passing arg 3 of `string_make' with different width due to prototype core.ops:113: warning: passing arg 5 of `string_make' with different width due to prototype core.ops:133: warning: cast from pointer to integer of different size core.ops:133: warning: cast from pointer to integer of different size core.ops:143: warning: cast from pointer to integer of different size core.ops:143: warning: cast from pointer to integer of different size core.ops:143: warning: cast from pointer to integer of different size core.ops:143: warning: cast from pointer to integer of different size core.ops:171: warning: cast to pointer from integer of different size core.ops:174: warning: passing arg 3 of `string_make' with different width due to prototype core.ops:174: warning: passing arg 5 of `string_make' with different width due to prototype core.ops:171: warning: cast to pointer from integer of different size core.ops:174: warning: passing arg 3 of `string_make' with different width due to prototype core.ops:174: warning: passing arg 5 of `string_make' with different width due to prototype core.ops:201: warning: passing arg 2 of `string_ord' with different width due to prototype core.ops:201: warning: passing arg 2 of `string_ord' with different width due to prototype core.ops:273: warning: cast to pointer from integer of different size core.ops:273: warning: cast to pointer from integer of different size core.ops:273: warning: cast to pointer from integer of different size core.ops:273: warning: cast to pointer from integer of different size core.ops:288: warning: cast to pointer from integer of different size core.ops:288: warning: cast to pointer from integer of different size core.ops:288: warning: cast to pointer from integer of different size core.ops:288: warning: cast to pointer from integer of different size core.ops:304: warning: cast to pointer from integer of different size core.ops:304: warning: cast to pointer from integer of different size core.ops:304: warning: cast to pointer from integer of different size core.ops:304: warning: cast to pointer from integer of different size core.ops:323: warning: cast to pointer from integer of different size core.ops:323: warning: cast to pointer from integer of different size core.ops:349: warning: passing arg
Minimum perl version ?
According to README, You'll also need Perl 5.005 or above, compiled to support the types you wish to support in Parrot. (Parrot will make, but you'll be unable to assemble anything.) You can find what types are support by typing 'perl -V', and examining the values for ivtype and nvtype. Parrot should work with INTVALs and NUMVALs up to those types. However, trying to build with the Sun-supplied 5.005_03, I get the error cd lib/Parrot && /usr/bin/perl Makefile.PL && make && cd .. Could not eval ' package ExtUtils::MakeMaker::_version; no strict; local $VERSION; $VERSION=undef; do { our $VERSION = '0.01'; }; $VERSION ' in PakFile2.pm: Can't modify subroutine entry in scalar assignment at (eval 6) line 7, at EOF *** Error code 2 make: Fatal error: Command failed for target `lib/Parrot/.dummy' because lib/Parrot/Makefile.PL contains WriteMakefile( 'NAME' => 'Parrot::PakFile2', 'VERSION_FROM' => 'PakFile2.pm', # finds $VERSION and PakFile2.pm says (among other things) require 5.005_62; use warnings; our @ISA = qw(Exporter DynaLoader); none of which will work with 5.005. Is it perhaps time to require 5.6.x? (Note too that perl -V:ivtype and perl -V:nvtype also won't work in 5.005 -- those too were introduced in the 5.6.x series.) -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: vtables and multimethod dispatch
On Wed, 10 Jul 2002, Nicholas Clark wrote: > > Dan Sugalski wrote: > > > > Heh. I never expected to have to dust off my trig skills when I > > > started this. If I need to dig out the calculus books, I think I'll > > > just go run screaming... > > Unless I'm being thick, x² < y² whenever x < y for positive x and y > (ie you don't need to take the square root of the hypotenuse to work out which > hypotenuse is shorter. And all we're actually interested in which one is > shorter, aren't we?) (Assuming, of course, that |x| and |y| are both >= 1, which is obviously true here since they are integers. (That's the sort of trick they like to put in the SAT math section.)) Assuming x and y are coordinates in a 2-d space, and that both are integers >= 0, why not just use what is affectionately called the "taxicab" metric: x+y? It is just as "valid" and even quicker to compute than the Euclidean metric sqrt(x^2 + y^2). Of course the ordering of which is "closer" is different depending on the metric chosen -- which is partly my point. If the actual result obtained from a calculation would differ in any significant way depending on which metric were used, then it might be a warning sign that there's a higher-level problem at hand. Practically, of course, any metric is fine for the moment -- it can always be changed later if warranted. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
[PATCH] MANIFEST update
The following patch brings the MANIFEST file up-to-date with recent additions. I haven't committed this in case some other reorganization (e.g. moving stuff to a src/ or dev/ or doc/ directory) is underway. There are also a few minor shuffles as I've re-sorted the MANIFEST. Andy Dougherty [EMAIL PROTECTED] --- parrot-cvs/MANIFEST Sat Jul 13 13:04:15 2002 +++ parrot-andy/MANIFESTWed Jul 17 11:46:50 2002 @@ -12,16 +12,15 @@ VERSION assemble.pl byteorder.c +byteorder.dev chartype.c chartypes/unicode.c chartypes/usascii.c classes/array.pmc +classes/coroutine.pmc classes/default.pmc classes/genclass.pl classes/intqueue.pmc -classes/coroutine.pmc -classes/pointer.pmc -classes/sub.pmc classes/perlarray.pmc classes/perlhash.pmc classes/perlint.pmc @@ -29,6 +28,8 @@ classes/perlstring.pmc classes/perlundef.pmc classes/pmc2c.pl +classes/pointer.pmc +classes/sub.pmc config/auto/byteorder.pl config/auto/byteorder/test_c.in config/auto/cgoto.pl @@ -85,6 +86,8 @@ debug.ops disassemble.c disassemble.pl +docs/Makefile.in +docs/a5_draft.html docs/embed.pod docs/faq.pod docs/glossary.pod @@ -232,6 +235,7 @@ languages/BASIC/stackops.pasm languages/BASIC/tokenize.pasm languages/BASIC/wumpus.bas +languages/Makefile.in languages/cola/MAINTAINER languages/cola/Makefile languages/cola/README @@ -271,6 +275,7 @@ languages/imcc/symreg.c languages/imcc/symreg.h languages/jako/MAINTAINER +languages/jako/Makefile.in languages/jako/bench.jako languages/jako/euclid.jako languages/jako/fact.jako @@ -284,6 +289,7 @@ languages/jako/primes.jako languages/jako/queens.jako languages/jako/sub.jako +languages/miniperl/Makefile.in languages/miniperl/Miniperl.pm languages/miniperl/Miniperl/Generator.pm languages/miniperl/Miniperl/Makefile.PL @@ -298,6 +304,30 @@ languages/parrot_compiler/gentable.pl languages/parrot_compiler/parrot.pasm languages/parrot_compiler/sample.pasm +languages/perl6/MANIFEST +languages/perl6/P6C/Addcontext.pm +languages/perl6/P6C/Builtins.pm +languages/perl6/P6C/Context.pm +languages/perl6/P6C/IMCC.pm +languages/perl6/P6C/Nodes.pm +languages/perl6/P6C/Parser.pm +languages/perl6/P6C/TestCompiler.pm +languages/perl6/P6C/Tree.pm +languages/perl6/P6C/Util.pm +languages/perl6/README +languages/perl6/mkdistro.sh +languages/perl6/prd-perl6.pl +languages/perl6/t/compiler/1.t +languages/perl6/t/compiler/2.t +languages/perl6/t/compiler/3.t +languages/perl6/t/compiler/4.t +languages/perl6/t/parser/P6CTest.pm +languages/perl6/t/parser/README +languages/perl6/t/parser/basic.t +languages/perl6/t/parser/exe2.t +languages/perl6/t/parser/exe3.t +languages/perl6/t/parser/exe4.t +languages/perl6/t/parser/similar.t languages/regex/MAINTAINER languages/regex/Makefile languages/regex/README @@ -331,6 +361,7 @@ languages/regex/t/star.t languages/regex/t/staralt.t languages/regex/test.pl +languages/scheme/Makefile.in languages/scheme/Scheme.pm languages/scheme/Scheme/Generator.pm languages/scheme/Scheme/Parser.pm @@ -393,6 +424,7 @@ resources.c runops_cores.c rx.c +rx.dev rx.ops rxstacks.c stacks.c
[PATCH] .dev files.
I'm happy to see new documentation, including the .dev files, appearing in parrot. However, I do have a small concern that we not set ourselves in a position of maintaining multiple copies of the same information. To be specific, I looked at byteorder.dev and noted a listing of all the functions. That's fine, but if the list of functions changes in the .c file, someone has to remember to go back and update the list in byteorder.dev as well. (I don't mean to pick on byteorder at all -- in fact quite the contrary -- because it's small, well-commented, and easy-to-follow, it's an easy practice ground for documentation!) I tend to think that a better plan is to not bother listing the functions (unless it makes the implementation discussion easier to understand) and to rely on being able to pull them out of the relevant source file with some sort of tool. Further, keeping them right next to the appropriate source in the .c file makes it more likely that they will be maintained in sync. To be specific, I propose three patches to illustrate how I think these different files ought to work together. 1. docs/pdds/pdd07_codingstd.pod: I clarify where the list of functions goes. 2. byteorder.dev: I took the existing one, put it in POD format, added a few more implementation notes, and removed all the specific functions. 3. byteorder.c: I put in POD documentation for all the functions. The exact format is still to be determined, but I used perl5's utf8.c as an example/model. I chose the arbitrary apiname of 'byteorder'. That's almost certainly wrong but is good enough to get started. I'd welcome discussion on whether this looks like a reasonable way to think about these .dev files, before we get too far along. Andy Dougherty [EMAIL PROTECTED] --- parrot-cvs/docs/pdds/pdd07_codingstd.podWed Jul 17 11:35:19 2002 +++ parrot-andy/docs/pdds/pdd07_codingstd.pod Wed Jul 17 12:14:55 2002 @@ -538,12 +538,17 @@ this is in contrast to PDDs, which describe design decisions). This is the place for mini-essays on how to avoid overflows in unsigned arithmetic, or on the pros and cons of differing hash algorithms, and -why the current one was chosen, and how it works. +why the current one was chosen, and how it works. In principle, someone coming to a particular source file for the first time should be able to read the F<.dev> file and gain an immediate overview of what the source file is for, the algorithms it implements, etc. + +The F<.dev> file is not usually the place for a complete listing of all +functions in the source file. That information is (presumably) already +in the file itself, and duplicating it would only lead to more +maintenance work. Currently no particular format or structure is imposed on the developer file, but it should have as a minimum the following sections: --- parrot-cvs/byteorder.devTue Jul 16 23:31:03 2002 +++ parrot-andy/byteorder.dev Wed Jul 17 13:18:16 2002 @@ -1,57 +1,47 @@ -Overview -The byteorder code will check the endianness of an INTVAL or -an opcode_t value and swap from little to big, or big to little -when appropriate. Functions also exist to convert a 4, 8, 12, -or 16 byte character buffer to big or little endian. -The functions will be placed in the PackFile -vtable and will be called when necessary. It is hoped that -the Parrot interpreter will not call these functions when +=head1 Name + +byteorder.c + +=head1 Overview + +The byteorder code will check the endianness of an INTVAL or an +opcode_t value and swap from little to big, or big to little when +appropriate. Functions also exist to convert a 4, 8, 12, or 16 byte +character buffer to big or little endian. The functions will be placed +in the PackFile vtable and will be called when necessary. It is hoped +that the Parrot interpreter will not call these functions when converting from and to the same byteorder. -Data Structures and Algorithms -The algorithm to change from one endian to another is -identical and simplistic to understand. Basically, -the size of an INTVAL or opcode_t is used to -determine at compile time how many bits should -be shifted around. Then, the correct bits are shifted -the correct amounts (please look at source code for -exact amounts). The buffer change functions are implemented -by a straight forward algorithm that assigns swaps all -of the bytes. - -Important Functions -fetch_iv_le - This function will convert an INTVAL into -little endian format. It is a noop if the native -format is already little endian. -fetch_iv_be - This function will convert an INTVAL into -big endian format. It is a noop if the native -format is already big endian. -fetch_op_be - This function will convert an opcode_t into -big endian format. It is a noop if the native -format is already big endian. -fetch_op_le - This function will convert an opcode_t into -little endian fommat. It is a noop
RE: [PATCH] MANIFEST update
On Wed, 17 Jul 2002, Brent Dax wrote: > There should be no Makefile.in's left in the source--they've been tossed > in favor of config/gen/makefiles. Fair enough. I just took what cvs handed me. It was a fresh checkout as of yesterday, updated this morning. Whoever removes those files from the repository ought to adjust MANIFEST accordingly. -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] .dev files.
On Wed, 17 Jul 2002, John Porter wrote: > As someone else has already said, a better place > for the .dev information might be inside the .c > file itself. > I for one find the separation unnatural, > uncustomary, and de-sync-prone. > Frankly I just don't see what it buys us. Obviously, in principle, documentation could go anywhere, assuming it actually gets written. In practice, what we need is a supporting culture and infrastructure to make it most likely that useful documentation will get written and be in a place you can find it. I think the purpose of the .dev files, as laid out in docs/pdds/pdd07_codinstd.pod, is a reasonable one. Here's an edited excerpt: This text file contains documentation on all the implementation decisions associated with the source file. This is the place for mini-essays on how to avoid overflows in unsigned arithmetic, or on the pros and cons of differing hash algorithms, and why the current one was chosen, and how it works. In principle, someone coming to a particular source file for the first time should be able to read the F<.dev> file and gain an immediate overview of what the source file is for, the algorithms it implements, etc. Suppose, for example, that the author of hash.c chooses hashing algorithm B over algorithm A. At the top of hash.c, it would be a bit odd to see a mini-essay describing A since it's never used. On the other hand, having done all the work to decide B is better than A for parrot, it would be useful to record that decision somewhere. hash.dev is one sensible place for it. Obviously, in practice, judgment will be needed for any particular bit of documentation. For example, take perl5's sv.c. There are certainly many implementation issues related to IV/UV/NV conversion that could be discussed in some sort of mini-essay (and there is such a mini-essay in sv.c). On the other hand, I think many of the extensive comments on those issues belong exactly where they are -- right next to the code in question. Obviously, in practice, judgment will be needed for any particular bit of documentation. If many of the .dev files end up very brief because there were no significant implementation issues to address, or because everything is clear from the .c file, or then so be it. I suspect there will be at least a few files that could benefit from some mini-essay somewhere describing the implementation issues. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: [COMMIT] Major GC Refactoring
warning: cast increases required alignment of target type include/parrot/jit_emit.h:499: warning: cast increases required alignment of target type include/parrot/jit_emit.h:503: warning: cast increases required alignment of target type include/parrot/jit_emit.h:505: warning: cast increases required alignment of target type include/parrot/jit_emit.h:512: warning: cast increases required alignment of target type include/parrot/jit_emit.h:513: warning: cast increases required alignment of target type include/parrot/jit_emit.h:521: warning: cast increases required alignment of target type include/parrot/jit_emit.h:522: warning: cast increases required alignment of target type include/parrot/jit_emit.h:530: warning: cast increases required alignment of target type include/parrot/jit_emit.h:532: warning: cast increases required alignment of target type include/parrot/jit_emit.h:536: warning: cast increases required alignment of target type include/parrot/jit_emit.h:539: warning: cast increases required alignment of target type include/parrot/jit_emit.h:542: warning: cast increases required alignment of target type include/parrot/jit_emit.h:543: warning: cast increases required alignment of target type jit_cpu.c:17: warning: cast increases required alignment of target type jit_cpu.c:18: warning: cast increases required alignment of target type jit_cpu.c:22: warning: cast increases required alignment of target type jit_cpu.c:37: warning: cast increases required alignment of target type jit_cpu.c:53: warning: cast increases required alignment of target type jit_cpu.c:59: warning: cast increases required alignment of target type jit_cpu.c:61: warning: cast increases required alignment of target type jit_cpu.c:66: warning: cast increases required alignment of target type resources.c:186: warning: cast increases required alignment of target type embed.c:212: warning: cast increases required alignment of target type headers.c:364: warning: cast increases required alignment of target type dod.c:277: warning: cast increases required alignment of target type -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042