Re: new FAQs
At 19:05 on 05/23/2007 PDT, chromatic [EMAIL PROTECTED] wrote: It sounds like you are saying that languages are free to implement their own semantics using their own code, and that they can choose not to interoperate with predefined Parrot types or types from other languages when that would negatively impact their goals, such as performance. While that rings true, it seems that Parrot is not providing that ability -- languages can already implement whatever they want without Parrot. And if languages are free to ignore predefined and foreign types, when what benefit will they actually get from Parrot? - better compiler tools than lex and yacc. Is it necessary (or even fair) to tie compiler components to parrot? Snarkily, it's better than the JVM because it actually supports features of dynamic languages natively without forcing all dynamic languages built on it to invent everything besides look up named method at runtime. Apparently this is an improvement over invent the whole VM? ;-) I've been following parrot to some degree since day one, and at this point I am very much unconvinced that it has any real value. I have always been more interested in perl 6 than parrot, and i don't really believe that parrot is essential, or even the best solution to get perl 6 going. I will follow this thread with some interest though.. perhaps my mind will be changed. (Not that my opinion matters a whole lot.. At this point I really have written perl 6 off too- it doesn't seem likely to reach maturity in time to regain much relevance for perl in the corporate world.. But that's really a separate rant and it's not really parrot's fault, unless you believe that parrot coders could be working on projects more directly related to perl 6 instead.) --Josh
Re: new FAQs
At 20:07 on 05/23/2007 PDT, chromatic [EMAIL PROTECTED] wrote: On Wed, May 23, 2007 at 10:37:06PM -0400, Josh Wilmes wrote: At 19:05 on 05/23/2007 PDT, chromatic [EMAIL PROTECTED] wrote: - better compiler tools than lex and yacc. Is it necessary (or even fair) to tie compiler components to parrot? I really don't know how to answer this question. The compiler tools target Parrot, so that it will be easier for people (including us) to write languages that run on Parrot. I understand. I'm just saying that *if* perl 6 were being written to target an existing VM, any brilliant compiler tools could be written to target it as well. It's not parrot that makes these possible. --Josh
Re: Fwd: Minimum modules for Production?
At 12:00 on 06/01/2006 BST, David Cantrell [EMAIL PROTECTED] wrote: Basic I/O is talking to filehandles and nyetwork sockets. Anything above the UDP / TCP level should not, IMO, be included. I'd respectfully disagree. Just like text isn't just ascii any more, content isn't just on local filesystems. HTTP has become pretty much basic. --Josh
Re: Fwd: Minimum modules for Production?
I think that the distribution approach is a good way to go. I also think that there could be value in a set of core modules for some basic functions. The only reason to do this, however, would be to design those modules to work especially well together. These modules could follow tighter standards on how errors are reported, how logging is done, how they should be extended (plugins/subclasses), etc. If such core modules were to be done in that fashion, they could serve as a positive example for the first wave of module developers and shape things to come. Of course there's still the question of what modules would belong in such a list. I think that modules for debugging, compilation and deployment, exception handling, threading, basic I/O (which includes LWP nowadays) would probably make sense. Of course one could pretty rapidly leap to DBI and SOAP, or web application modules... The line has to be drawn somewhere, though. I think the question to ask is which aspects of perl programming could benefit from being put on a (relatively) narrow path and which belong in TMTOWDI mode from day 0. (And do we want to have so many XML modules next time around, or can we benefit from blessing one approach, at least to start things off) Putting things into the core because they're convenient to have around, however, is probably the wrong thing to do. A (at least semi) separate distribution of common modules makes more sense. --Josh At 10:59 on 05/30/2006 PDT, Larry Wall [EMAIL PROTECTED] wrote: On Tue, May 30, 2006 at 02:09:19AM -0700, Darren Duncan wrote: : As I recall, it is Larry's wish that the standard distribution for : Perl 6 be quite small, so that people are encouraged to use CPAN. Hmm, but also so that people are encouraged to form various standard distributions, more along the lines of the Linux model. This is for a number of reasons. The distributing organization can sell CDs or DVDs, of course, but more importantly, can function in a localized editorial role without tearing up the whole community over such choices. Also, different distributions can specialize for different kinds of users. Here's the ISP distribution, there's the bioperl distribution. One thing we could do better than the Linux model is specify how different distributions must stay compatible and interoperate with other distributions so that you can load several of them at once. Larry
Re: [perl #760] Parrot_warn doesn't work with a NULL interpreter
I haven't touched parrot in ages at this point. Please go ahead and close the bug. --Josh
Re: [perl #726] -fno-strict-aliasing (fwd)
No, please close it. --Josh
Re: No Autoconf, dammit!
While I am generally in favor of this idea (and I did get the first miniparrots to work, pretty much as proof of concept), I do think it's likely to be rather challenging (and interesting): Remember, _pure_ C89 provides only these headers: assert.h complex.h ctype.h errno.h fenv.hfloat.h inttypes.hiso646.h limits.h locale.h math.hsetjmp.h signal.h stdarg.h stdbool.h stddef.h stdio.h stdlib.h string.h tgmath.h time.h wchar.h wctype.h This leaves out a number of things that one would really like to have to do system probing, most notably: - file info (stat, fstat) - executing programs in any kind of sophisticated way (fork/exec, pipes) My only real point is that, while I think pure c89 is a nice goal, in practice we will need to relax this just a bit, to include at the very least, things like unistd and bits of posix that are likely to be everywhere.Should be interesting. Probably isn't going to really gain momentum until we get some of the build system written in something that compiles down to run on parrot.. How's that perl 6 compiler coming? ;-) --Josh At 18:20 on 09/07/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: This argument's old. Very old, so it may be unfamiliar to many people. The subject generates enough heat that I don't want to go there again. We are not using autoconf. Period. Parrot's build process, when shipped will be: *) Person building runs platform-specific script *) Script builds miniparrot, which assumes ANSI C89 functionality only *) Miniparrot runs provided configure program, which is in bytecode *) Configure probes environment *) Full parrot is built *) Full parrot is then invoked to complete the build process, which is driven by a program written in a parrot language and provided as bytecode -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: No Autoconf, dammit!
At 9:23 on 09/08/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: - executing programs in any kind of sophisticated way (fork/exec, pipes) We do get system and popen, though. Well, system at least. popen is not part of the c89 spec as far as I know. This URL is a fairly handy reference: http://www.unix.org/version3/inttables.pdf --Josh
Re: No Autoconf, dammit!
At 11:30 on 09/08/2004 CDT, Timm Murray [EMAIL PROTECTED] wrote:
*) Person building runs platform-specific script
If that script is going to be platform-specific anyway, why not use Autoconf
for the platforms that can handle it? You'd cover a rather large number of
platforms that way, and the ones you don't are going to need their own script
regardless.
It's very likely that the unix version of the platform specific script
WILL include some very minimal probing to do things like find the
compiler. But that's really all it needs to do- remember, the goal here
(as proposed) is to build miniparrot, not to build parrot. That means
you don't *need* autoconf.
The latter part of the build process, where we actually build the real
parrot, is a different issue. Dan's ruled out autoconf, so we get to
reinvent that wheel. FWIW, i'm not sure that I would have gone this
route, but dan's made a choice, and the best thing to do (IMHO) is to
follow that road and see where it leads. If it turns out to be dumb, we
move on. If it works, great.
So far, parrot's environmental probing needs really aren't terribly
sophisticated- most of the work has already been done in the current
Configure system- the test programs exist, and the mechanism to compile
and run them is well understood.
The remaining work to build the parrotconf system is mostly tedious rather
than complex. Some of the harder bits (IMHO) will revolve around
figuring out how to compile and link things, dynamic loading, and
architecture detection ($Config{archname}, osname, osvers, etc). If you
look at autoconf or metaconfig, those tasks are inevitably full of wacky
system-specific stuff. But since this is perl, porting metaconfig's units
for seting those variables to something that can run on parrot is probably
the way things will go.
It's not TERRIBLY hard but it isn't very glamorous either :) I did start
looking into converting the archname code into perl, as a starting point,
a while back. I may still have that somewhere and could probably finish
it up- my reasoning was that if I could get it from shell code into perl
code, i could understand it better and then rewrite it from scratch again
in some form that we could compile to PIR. Some sort of OOish language
with a working compiler for parrot would be nice. I'm not too keen on the
idea of maintaining nasty little probing code in assembly. :)
--Josh
Re: ICU Outdated - Ideas
At 18:46 on 08/03/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: If someone's got the time and I spec out the encoding and charset APIs, I'd be thrilled if ICU became optional again. Wouldn't hurt my feelings at all. We need it, because we need Unicode, but it doesn't have to be required. We'll need something that isn't ICU if we're going to do the miniparrot thing. Of course, in the case of miniparrot, it may be possible to forgo unicode altogether, or use a very limited form of it. --Josh
Re: Configure.pl and the history of the world
I began a little piece of this ages ago- attempting to translate the parts that identify the platform ($^O, essentially) from metaconfig to something we could put into Configure.pl. Even that relatively simple chore wasn't too easy. I should still have the work-in-progress code for that around here somewhere. --Josh At 19:47 on 03/16/2004 EST, Dan Sugalski [EMAIL PROTECTED] wrote: Hey folks. Now that we're integrating in with perl 5, a few things are becoming really obvious. First, we really need to work on the embedding interface. Memory handling, signals, and I/O are the biggies there. Working on that, though not fast enough for Arthur. Second, we're running over the same problems in system configuration that perl (and python, and ruby, for that matter) have already run across. Moreover, we're making the same decisions, only... differently. This is silly both because we're re-inventing the wheel and we're making the wheel with metric nuts instead of english. We could go dig through perl's configure every time we add a new environment probe, but that'll get really old really quick. Instead, what I'd like is for someone (Oh, Brent... :) to go through perl's configure and dig out the tests in it, as well as the defaults that it has and just get all the config variables in once and for all. While some of what's in there we don't have to deal with (joys of C89 as a minimum requirement) there's a lot of hard-won platform knowledge in there and ignoring it's foolish. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Configure.pl and the history of the world
At 10:22 on 03/18/2004 EST, Andrew Dougherty [EMAIL PROTECTED] wrote: 5. You probably don't need to support Eunice anymore. I think i'm not the only one who would be deeply upset if I ceased to be congratulated for not running Eunice though. --Josh
Re: [PROPOSAL] Cstat opcode and interface
I have no opinion either way on this opcode or the date/time ones, but I
would like to remind folks about miniparrot- if we want it to work again,
there needs to be a smooth way to exclude opcodes or PMCs which are
not expecially portable on its platform (pure c89, no threads, etc).
This means one or more of the following will need to be done:
- all non-c89 code in config/gen/platform
- extra flag in the .ops files to identify ops to be excluded
- extra file to list explicitly which ops should be INcluded in
miniparrot, with all others left out.
- more #ifdef MINIPARROTs.
Personally i'm leaning towards the third option, but I think we should be
clear what the policy is with regard to config/gen/platform and functions
which aren't part of standard C (but which are available on most
platforms).
It's also quite possible that miniparrot is a waste of time. I'm pretty
much of the opinion myself that it's an academic exercise at this point,
but one which keeps us honest, even if we don't use it.
--Josh
--Josh
At 11:39 on 03/10/2004 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Proposal Cstat opcode and interface
1) ops
stat (out PMC, in STR, in INT)
stat (out PMC, in PMC, in INT)
Return a new array-like[1] PMC $1 with file stats from file (PIO or
string) $2,
or PerlUndef, if file doesn't exist, $3 are flags:
.PARROT_STAT_NO_FOLLOW_LINK
The array(-like) has keyed access with these keys
.PARROT_STAT_FILE_SIZE
.PARROT_STAT_FILE_SIZE_LO
.PARROT_STAT_FILE_SIZE_HI
.PARROT_STAT_MODE a bitmask with these bits:
.PARROT_STAT_MODE_ISDIR
.PARROT_STAT_MODE_ISFILE
[ more platform-unspecific bits ]
.PARROT_STAT_PERM a bitmask with these bits
.PARROT_STAT_PERM_IS_READABLE
.PARROT_STAT_PERM_IS_WRITABLE
.PARROT_STAT_PERM_IS_EXECUTABLE
.PARROT_STAT_MTIME modified time
.PARROT_STAT_OS_TYPE a constant defining the os-specific
part that follows
.PARROT_STAT_stat
.PARROT_STAT_stat64
...
.PARROT_STAT_OS_SPECIFIC
A (Un)?ManagedStruct PMC with OS-specific data like a
struct stat64
2) Interface
PMC* Parrot_stat_s(Interp*, STRING* file, INTVAL flags);
PMC* Parrot_stat_p(Interp*, PMC*pio, INTVAL flags);
3) Interface to platforms
INTVAL Parrot_stat_os_s(Interp*, Parrot_stat*, STRING* file, INTVAL
flags);
INTVAL Parrot_stat_os_p(Interp*, Parrot_stat*, PMC*pio, INTVAL
flags);
typedef struct _parrot_stat {
size64_t size;
UINTVAL mode;
UINTVAL perm;
FLOATVAL mtime; // in Parrot units
UINTVAL os_stat_type;
union {
struct stat;
struct stat64;
...
} u;
} Parrot_stat;
4) Notes
The information in the first few fields should not be platform
specific. If platforms have more in common then above bits, the
structure should be expanded.
[1] it needs just these vtables implemeted: I0 = P0[i], N0 = P0[i],
i.e. get_{integer,number}_keyed_int
Comments, improvements, and implementations thereafter welcome
leo
Re: cvs commit: parrot/src interpreter.c
Sorry, typo- I have no idea how that got by.
--Josh
At 5:00 on 03/09/2004 +0100, Jens Rieks [EMAIL PROTECTED] wrote:
Hi,
On Tuesday 09 March 2004 04:24, Josh Wilmes wrote:
cvsuser 04/03/08 19:24:12
Modified:src interpreter.c
Log:
Missing function/data casts.
Revision ChangesPath
1.279 +3 -3 parrot/src/interpreter.c
Index: interpreter.c
===
RCS file: /cvs/public/parrot/src/interpreter.c,v
retrieving revision 1.278
retrieving revision 1.279
diff -u -w -r1.278 -r1.279
--- interpreter.c 6 Mar 2004 14:26:08 - 1.278
+++ interpreter.c 9 Mar 2004 03:24:12 - 1.279
@@ -1,7 +1,7 @@
/*
###
# Copyright: 2001-2003 The Perl Foundation. All Rights Reserved. -$Id:
interpreter.c,v 1.278 2004/03/06 14:26:08 leo Exp $
+$Id: interpreter.c,v 1.279 2004/03/09 03:24:12 josh Exp $
###
#
=head1 NAME
@@ -1520,7 +1520,7 @@
interpreter-evc_func_table = mem_sys_allocate(sizeof(void *) *
n); for (i = 0; i n; ++i)
interpreter-evc_func_table[i] = (op_func_t)
-((void**)lib-op_func_table)[CORE_OPS_check_events__];
+
DTOFPTR(((void**)lib-op_func_table)[CORE_OPS_check_events__]); }
What is that supposed to do? It seems to be something platform specific..?
-- http://tinderbox.perl.org/tinderbox/bdshowbuild.cgi?tree=parrot
}
@@ -2243,7 +2243,7 @@
if ((int)interpreter-run_core == cg_lib-core_type) {
for (i = n_old; i n_tot; ++i)
interpreter-evc_func_table[i] =
-(op_func_t)ops_addr[CORE_OPS_check_events__];
+(op_func_t)DTOFPTR(ops_addr[CORE_OPS_check_events__]);
interpreter-save_func_table = (void *) ops_addr;
}
/*
jens
Re: [DOCS] Documentation tools
At this point in the development cycle you can certainly make such arguments (although I would tend to fall on the side of consistency myself, at least for things that really Don't Matter in the grand scheme of things, such as POD modules). But once we start expecting people in the real world to compile this thing on their boxes in order to install perl, it would be extremely foolish to make them manually download and install perl6 + parrot + icu + perl5 + cpan modules 1 through 10, all from different sources. IMHO, the releases better include everything necessary to build the application, within reason. Consistency and simplicity counts for a lot. Why create headaches we don't need? The development environment can of course be more fluid. --Josh At 15:05 on 03/04/2004 PST, Robert Spier [EMAIL PROTECTED] wrote: The determinism seems perhaps worth the bloat. It's quite localize bloat after all. I disagree. We _want_ a heterogeneous environment -- a homogeneous environment doesn't exist in the real world -- most of your concerns were with tracking down the issues. Since we have parrotbug now (or real soon) we can take a better snapshot of whats going on. If we want to require certain versions, that becomes a problem ot some people. But we can do it by providing URL's to where people can download the specific versions and instructions on how to set that up for parrot's use only. But we don't need to bundle it _with_ Parrot. -R
Re: Threads... last call
I'm also concerned by those timings that leo posted. 0.0001 vs 0.0005 ms on a set- that magnitude of locking overhead seems pretty crazy to me. It seemed like a few people have said that the JVM style of locking can reduce this, so it seems to me that it merits some serious consideration, even if it may require some changes to the design of parrot. I'm not familiar enough with the implementation details here to say much one way or another. But it seems to me that if this is one of those low-level decisions that will be impossible to change later and will forever constrain perl's performance, then it's important not to rush into a bad choice because it seems more straightforward. Perhaps some more experimentation is in order at this time. --Josh At 17:24 on 01/22/2004 EST, Deven T. Corzine [EMAIL PROTECTED] wrote: Dan Sugalski wrote: Last chance to get in comments on the first half of the proposal. If it looks adequate, I'll put together the technical details (functions, protocols, structures, and whatnot) and send that off for abuse^Wdiscussion. After that we'll finalize it, PDD the thing, and get the implementation in and going. Dan, Sorry to jump in out of the blue here, but did you respond to Damien Neil's message about locking issues? (Or did I just miss it?) This sounds like it could be a critically important design question; wouldn't it be best to address it before jumping into implementation? If there's a better approach available, wouldn't this be the best time to determine that? Deven Date: Wed, 21 Jan 2004 13:32:52 -0800 From: Damien Neil [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Start of thread proposal Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] 8.leo.home [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Content-Length: 1429 On Wed, Jan 21, 2004 at 01:14:46PM -0500, Dan Sugalski wrote: ... seems to indicate that even whole ops like add P,P,P are atomic. Yep. They have to be, because they need to guarantee the integrity of the pmc structures and the data hanging off them (which includes buffer and string stuff) Personally, I think it would be better to use corruption-resistant buffer and string structures, and avoid locking during basic data access. While there are substantial differences in VM design--PMCs are much more complicated than any JVM data type--the JVM does provide a good example that this can be done, and done efficiently. Failing this, it would be worth investigating what the real-world performance difference is between acquiring multiple locks per VM operation (current Parrot proposal) vs. having a single lock controlling all data access (Python) or jettisoning OS threads entirely in favor of VM-level threading (Ruby). This forfeits the ability to take advantage of multiple CPUs--but Leopold's initial timing tests of shared PMCs were showing a potential 3-5x slowdown from excessive locking. I've seen software before that was redesigned to take advantage of multiple CPUs--and then required no less than four CPUs to match the performance of the older, single-CPU version. The problem was largely attributed to excessive locking of mostly-uncontested data structures. - Damien
Re: [DOCS] Updated documentation in Perl scripts
Thank you! You make some of my cheesy code a bit more respectable :) --Josh At 23:35 on 01/20/2004 +0100, Michael Scott [EMAIL PROTECTED] wrote: I've committed updates to the documentation in the Perl scripts in build_tools, classes and tools/dev. http://homepage.mac.com/michael_scott/Parrot/docs/html All scripts now run with -w (turned up a harmless bug in Parrot::Vtables, which I fixed). CVS $Id and copyright notices were also added where necessary. Mike
Re: Threads. Design. Go for it
At 16:15 on 12/30/2003 EST, Dan Sugalski [EMAIL PROTECTED] wrote: Your constraints: 2) A perl 5 iThreads it's not a thread, it's a fork. Well, sorta... mode must be available For those of us who aren't particularly familiar with ithreads, what does this imply? What's different, and why must it be done at the level of parrot, not perl? --Josh
Re: Threads. Design. Go for it
At 11:21 on 01/01/2004 PST, Jeff Clites [EMAIL PROTECTED] wrote: As far as what level needs to implement them, I'd say that parrot has to do enough to make it possible for an HLL to expose ithreads-style threading. Due to the cross-language nature of parrot, practically speaking this probably means that the semantic needs to exist at the parrot level. (For instance, an ithread created in Perl code could load a parrot bytecode library implemented in Python; calling into code inside this library shouldn't allow access to unshared data from other ithreads.) OK, thank you, that (the cross-language issue) is what I was looking for. --Josh
Re: Threads
At 12:23 on 12/22/2003 EST, Dan Sugalski [EMAIL PROTECTED] wrote: Second, we're assuming that the *non* threaded case is the common case. (This is definitely the assumption that I'm most expecting to regret in the future) I think it might be good to get started on regretting that as soon as possible ;-) --Josh
Re: Embedding interface to PMCs
If the pdd is amended, let's not forget to update the check_source script-
for that matter, if there are any other items that should be added
(perhaps some specific checks for the embedding headers), let me know-
I'll be happy to add them.
--Josh
At 18:57 on 09/11/2003 BST, Nicholas Clark [EMAIL PROTECTED] wrote:
On Thu, Sep 11, 2003 at 09:30:29PM +0300, Vladimir Lipskiy wrote:
to document the idea of Juergen Bommels to include the
extern C {
I take it you meant the full game:
#ifdef __cplusplus
extern C {
#endif
specification () in each header in pdd7_codingstd, no body had replied),
but maybe Parrot isn't going to have support for C++ embedding applications
.
It will. perl 5 does. Therefore the current situation is a bug.
Nicholas Clark
Re: Task for the interested: Coverage
There is http://www.hitchhiker.org/parrot_coverage/, which is built by tools/dev/parrot_coverage.pl. Any enhancements made there should show up in the next run. I disabled it about a month ago when it started going into an endless loop on a test. I'll try turning it back on though. --Josh At 18:12 on 07/29/2003 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: One thing we don't have is a complete set of coverage tests for the parrot opcodes. (Nor stats as to which ops do actually get covered by our current test suite) This would be a good thing to have, especially if we could add it into the make test target to generate a coverage report as part of its run. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] make: print filenames only
I don't like the current state of things- it seems to be printing out the full compilation commands occasionally, but mostly not. I think that at this stage of development it's best to print out the full commands being executed. --Josh At 15:34 on 07/28/2003 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote: Echoing all compiler flags clutters the screen too much, so that warnings easily can get missed. Earlier I used to run make -s which silents make. Still better would be: - echo compiler flags once - echo filenames only - let the work depending on -s was given to make or not or such leo
tcc failures
For some reason, this only occurs when imcc is built with tcc- it works fine with the other compilers. I don't know what this error is meant to mean, so i'm not quite sure how to troubleshoot it. Any ideas? --Josh [EMAIL PROTECTED]:~/devel/parrot% ./parrot t/op/arithmetics_38.pasm error:imcc: file t/op/arithmetics_38.pasm line 1: Macros only allowed in [EMAIL PROTECTED]:~/devel/parrot% head t/op/arithmetics_38.pasm .macro fp_eq ( J, K, L ) saveN0 saveN1 saveN2 set N0, .J set N1, .K sub N2, N1,N0 abs N2, N2 gt N2, 0.01, .$FPEQNOK -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Re: Small perl task for the interested
I think you miss the point. It's not just about flags. It's about how
you do a particular task, which could involve one or more commands (or be
impossible).
See libtool for an idea of the size of the problem.
--Josh
At 18:45 on 07/19/2003 EDT, Benjamin Goldberg [EMAIL PROTECTED] wrote:
Josh Wilmes wrote:
At 12:48 on 07/14/2003 +0200, Lars Balker Rasmussen [EMAIL PROTECTED] wrote
:
I've taken this very simple approach to the problem. A perl-wrapper
for the CC lines in makefiles/root.in
.c$(O) :
$(PERL) tools/dev/cc_flags.pl $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
I would go a bit further, and create a tools/build/compile, tools/build/
link_executable, tools/build/link_library, etc.
That would be silly. Instead, specify the file to read the flags from
as the first argument to cc_flags.pl. That is, change:
if (open F, CFLAGS) {
To:
if (open F, shift @ARGV) {
Then:
c$(O) :
$(PERL) tools/dev/flags.pl CFLAGS $(CC) $(CFLAGS) \
${cc_o_out}$@ -c $
And for linking, flags.pl gets an argument of LINKFLAGS, and for making
a shared library, it gets an argument of SHAREFLAGS, etc.. In each of
those files are rules for the per-file flags for that type of step.
Take all the flags out of the makefile altogether. Just a thought.
--Josh
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Small perl task for the interested
At 12:48 on 07/14/2003 +0200, Lars Balker Rasmussen [EMAIL PROTECTED] wrote:
I've taken this very simple approach to the problem. A perl-wrapper
for the CC lines in makefiles/root.in
.c$(O) :
$(PERL) tools/dev/cc_flags.pl $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
I would go a bit further, and create a tools/build/compile, tools/build/
link_executable, tools/build/link_library, etc.
Take all the flags out of the makefile altogether. Just a thought.
--Josh
Re: Copyrights
I can make such a change if you tell me exactly how it should be done. (I am not a lawyer, so i don't want to do this inappropriately). I'd think a safe first step would be to change any When this is determined to Yet Another Society. But beyond that it gets fuzzy to me. --Josh At 12:16 on 07/10/2003 PDT, Dan Sugalski [EMAIL PROTECTED] wrote: At 11:56 AM -0700 7/10/03, Robert Spier wrote: s/Yet Another Society/The Perl Foundation/g The Perl Foundation is just a dba of YAS. The name should, unless things have changed, be YAS. Gregor N. Purdy wrote: All -- I noticed that there are many files with copyrights of when this is determined..., while some files have a copyright of Yet Another Society. Seems like they should all be Yet Another, or none should be... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: #error generic platform without memalign
Don't forget the so-called miniparrot, which must be built with ANSI C only- no POSIX functions that aren't guaranteed in C89. --Josh At 22:48 on 06/11/2003 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote: Nicholas Clark [EMAIL PROTECTED] wrote: I've got a p6i backlog, so I don't know if this is already solved. However, on a fresh CVS checkout on FreeBSD I can't compile: platform.c:167: #error generic platform without memalign What's the solution? There are some, probably all do involve some config tweaks. But first, what is a generic platform? It seemed to me, this might be POSIX compliant. Or some other. Anyway, I think we slowly need platform and config code be more specific. WRT solution: - toss the lines reading #else / #error ... - or compile/link with the malloc.c provided in the tree Nicholas Clark leo
Re: build imcc as parrot (was: [perl #22352] PackFile imcc bug)
At 11:40 on 06/01/2003 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote: Yep. Imcc should definitely move out off languages into its own subdir under the top level (Not in the top level itself). ... Who should do this? I'd be willing to help if given direction. Moving directories around in CVS is AFAIK a PITA. The last such operation was done in the repository directly, IIRC. Yes, that's certainly the way to go for the actual dir structure change. But first all the other little code changes that this would require need to be figured out.. I started looking at what makefile changes would be needed.. i think the first thing that really needs to be decided is whether we intend to use recursive makefiles or not. Right now, parrot is half and half, and that just isn't going to fly, long term. The problem is, if you're really going to do recursive makefiles without headaches, each makefile needs to be building a fairly self-sufficient module. And at the moment, if we were to build a libimcc or something like that and link it into parrot, it would in turn require libparrot to build. This creates a bit of a chicken/egg problem.. Not insurmountable, but certainly ugly. It would be somewhat less so if the library bits were in a separate directory from the programs, so that imcc and parrot would be able to pull in libparrot and libimcc without disaster. However, that said, I am not a tremendous fan of recursive makefiles (or of make in general, honestly). I would suggest that we may want to move towards either a non-recursive makefile system (see 'recursive make considered harmful', http://aegis.sourceforge.net/auug97.pdf.. i have doubts about how well this can work on a large scale project without something like gnu make though), or something else altogether (cons, for instance). Wow, That was a run-on sentence. I know there was some coding done a while back towards rolling our own make replacement, but I don't know what state it's in.. and rolling our own will slow things down a bit- best to spend our resources on writing parrot, not make, imho.. but i'm willing to go with whatever folks want to do. I'm willing to help out here- i can probably figure out how to link imcc into parrot, but I think we need to resolve these directory structure / build system issues first. Does anyone own this problem? --Josh
Re: [perl #22352] PackFile imcc bug
At 14:26 on 05/31/2003 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: Honestly I'd prefer just a single executable, named parrot, that can handle assembly files, rather than the two executables we're building now. If we can do that, we can ditch assemble.pl. I'm all for that as well. It would imply some code reorganization (placing them in the same directory might make sense, or at least taking imcc out of languages/ and putting it under the top level). Who should do this? I'd be willing to help if given direction. Also be aware that imcc currently isn't as portable as parrot is. It does not build under lcc, for instance. I'll see if I can correct that, though. --Josh
Re: tinderbox all in flames
I'm not sure who owns the TD scripts, but I'd be willing to try to get them working again if someone could point me at them (and how to get the appropriate accounts, etc) --Josh At 14:29 on 03/10/2003 PST, Ask Bjoern Hansen [EMAIL PROTECTED] wrote: The tinderbox is all in flames. http://xrl.us/dxm (Link to tinderbox.perl.org) At least the miette, moof and rh80smoketest boxes should be okay; and they are not. :-) Sunday afternoon (PST) seems to be the hour of the big arson. However there are also indications that it started Friday night. :-) Slightly related, I think we could use some more tinderbox testers. Someone was running the tests on Compaq's test drive boxes, but that seems to have stopped? - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: The parrot crashes...
It appears to be the same thing for tcc and lcc on linux. The nearest I can tell, the value stuffed into struct_val in Parrot_NCI_set_string_keyed is somehow not a valid PObj- dereferencing its obj member seems to blow things up. It stomps all over the stack somehow, and I don't have much debugger mojo. Plus, building with -g makes the problem go away. Bah. --Josh At 14:09 on 01/20/2003 EST, Dan Sugalski [EMAIL PROTECTED] wrote: Rather badly, actually. All the tests that involve parrot currently segfault in the NCI mark routine. At least on OS X, I'm not sure about other platforms. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
cvs commit: parrot/tools/dev rebuild_miniparrot.pl (fwd)
FYI
--- Forwarded Message
Date:05 Jan 2003 00:41:55 +
From:Josh Wilmes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: parrot/tools/dev rebuild_miniparrot.pl
cvsuser 03/01/04 16:41:54
Modified:config/auto jit.pl sizes.pl
config/gen/makefiles root.in
tools/dev rebuild_miniparrot.pl
Log:
Fix the miniparrot build.
- add missing header dependency (thread.h) in makefile
- add miniparrot settings for a few new config variables
- make the jit_debug stuff conditional on jit being enabled. (miniparrot
turns jit off, so required files were missing otherwise)
Reminder- to build miniparrot, do make miniparrot-update, then run
sh build_gcc.sh in the miniparrot directory.
Revision ChangesPath
1.13 +3 -2 parrot/config/auto/jit.pl
Index: jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -w -r1.12 -r1.13
--- jit.pl4 Jan 2003 04:01:35 - 1.12
+++ jit.pl5 Jan 2003 00:41:51 - 1.13
@@ -23,7 +23,8 @@
jitcapable = 0,
cc_hasjit = '',
jit_h = '',
-jit_o = ''
+jit_o = '',
+ asmfun_o= ''
);
return;
}
@@ -89,7 +90,7 @@
jitcapable = 1,
cc_hasjit = -DHAS_JIT -D\U$jitcpuarch,
jit_h = '$(INC)/jit.h',
- jit_o = 'jit$(O) jit_cpu$(O)'
+ jit_o = 'jit$(O) jit_cpu$(O) jit_debug$(O)'
);
# test for some instructions
1.6 +4 -0 parrot/config/auto/sizes.pl
Index: sizes.pl
===
RCS file: /cvs/public/parrot/config/auto/sizes.pl,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -w -r1.5 -r1.6
--- sizes.pl 25 Nov 2002 15:54:40 - 1.5
+++ sizes.pl 5 Jan 2003 00:41:51 - 1.6
@@ -26,6 +26,10 @@
'hugeintvalsize' = 4,
'hugefloatval' = 'double',
'hugefloatvalsize' = 8,
+ 'int2_t' = 'int',
+ 'int4_t' = 'int',
+ 'float4_t' = 'double',
+ 'float8_t' = 'double',
);
return;
}
1.64 +3 -2 parrot/config/gen/makefiles/root.in
Index: root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.63
retrieving revision 1.64
diff -u -w -r1.63 -r1.64
--- root.in 27 Dec 2002 09:33:27 - 1.63
+++ root.in 5 Jan 2003 00:41:53 - 1.64
@@ -81,7 +81,8 @@
$(INC)/method_util.h $(INC)/list.h $(INC)/datatypes.h \
$(INC)/regfuncs.h $(INC)/string_funcs.h $(INC)/encoding.h \
$(INC)/chartype.h $(INC)/oplib.h $(INC)/sub.h $(INC)/unicode.h \
- $(INC)/perltypes.h $(INC)/exit.h $(INC)/nci.h $(INC)/pobj.h
+ $(INC)/perltypes.h $(INC)/exit.h $(INC)/nci.h $(INC)/pobj.h \
+ $(INC)/thread.h
ALL_H_FILES = $(GENERAL_H_FILES)
@@ -102,7 +103,7 @@
register$(O) core_ops$(O) core_ops_prederef$(O) memory$(O) \
packfile$(O) stacks$(O) string$(O) sub$(O) encoding$(O) \
chartype$(O) runops_cores$(O) trace$(O) pmc$(O) key$(O) hash$(O) \
- core_pmcs$(O) platform$(O) ${jit_o} jit_debug$(O) \
+ core_pmcs$(O) platform$(O) ${jit_o} \
${gc_o} rx$(O) rxstacks$(O) intlist$(O) list$(O) \
embed$(O) warnings$(O) ${cg_o} \
packout$(O) byteorder$(O) debug$(O) smallobject$(O) \
1.3 +2 -1 parrot/tools/dev/rebuild_miniparrot.pl
Index: rebuild_miniparrot.pl
===
RCS file: /cvs/public/parrot/tools/dev/rebuild_miniparrot.pl,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -w -r1.2 -r1.3
--- rebuild_miniparrot.pl 1 Nov 2002 03:34:36 - 1.2
+++ rebuild_miniparrot.pl 5 Jan 2003 00:41:54 - 1.3
@@ -89,6 +89,7 @@
## GCC ##
+print - miniparrot/build_gcc.sh\n;
open(F, miniparrot/build_gcc.sh) ||
die Unable to write miniparrot/build_gcc.sh: $!\n;
print F #!/bin/sh\n;
--- End of Forwarded Message
Re: [perl #19630] [PATCH] undef warning in Configure.pl
Applied both, thanks.
--Josh
At 19:11 on 12/31/2002 GMT, Nicholas Clark (via RT)
[EMAIL PROTECTED] wrote:
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #19630]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=19630
I was seeing this:
Generating config.h...done.
Generating feature.h...done.
Writing Parrot::Config module...done.
Use of uninitialized value in substitution iterator at lib/Parrot/Configure/S
tep.pm line 121, IN line 111.
Generating Makefiles...done.
Recording this configuration in myconfig...done.
Moving platform files into place...done.
Generating libparrot.def...done.
Generating core pmc list...done.
Okay, we're done!
And it was annoying me. So I did this to track it down:
--- lib/Parrot/Configure/Step.pm~ Sat Dec 28 12:10:18 2002
+++ lib/Parrot/Configure/Step.pm Tue Dec 31 18:55:14 2002
@@ -120,7 +120,9 @@ sub genfile {
}
s{
\$\{(\w+)\}
-}{Configure::Data-get($1)}egx;
+}{my $val=Configure::Data-get($1);
+ defined $val ? $val
+ : (warn value for '$1' in $source is undef, '')}egx;
print OUT;
}
I think that something like that is a good idea, as this is more helpful:
Generating config.h...done.
Generating feature.h...done.
Writing Parrot::Config module...done.
value for 'asmfun_o' in config/gen/makefiles/root.in is undef at lib/Parrot/C
onfigure/Step.pm line 122, IN line 111.
Generating Makefiles...done.
Recording this configuration in myconfig...done.
Moving platform files into place...done.
Generating libparrot.def...done.
Generating core pmc list...done.
Okay, we're done!
So I think we also need the appended patch, which elimates the warning.
Nicholas Clark
--- config/auto/jit.pl~ Fri Dec 27 18:27:04 2002
+++ config/auto/jit.plTue Dec 31 18:59:16 2002
@@ -73,6 +73,8 @@ sub runstep {
copy_if_diff(config/gen/platform/$cpuarch.s, asmfun.s);
Configure::Data-set(asmfun_o = 'asmfun$(O)');
+ } else {
+Configure::Data-set(asmfun_o = '');
}
$jitcapable = $set_jitcapable if defined $set_jitcapable;
Re: no no-strict-aliasing (more bondage and stricture)
Done.
--Josh
At 22:57 on 12/31/2002 GMT, Nicholas Clark [EMAIL PROTECTED] wrote:
Currently Parrot is picking up Perl's C compiler flags. Perl is quite
deliberately attempting to set -fno-strict-aliasing, to stop gcc using
ANSI's aliasing rules to infer possible optimisations; optimisations that
will actually break Perl's code.
(Don't ask me to remember exactly what the aliasing rules are, let alone
explain them correctly, but it's something to do with more than one type of
pointer not being allowed to point at the same thing (except via a union,
and where char pointers are exempt) in a strictly conformant ANSI C
program. Providing this holds true in the C source, the compiler can safely
reorder memory access and potentially gain speedups. Perl's source isn't
ANSI conformant in this way. Well, you can ask what the aliasing rules are,
but I won't answer)
The upshot is that you can't guarantee that any compiler won't be optimising
based on aliasing assumptions, because, hell, it's allowed to. And we may
not be able to turn it off. So we ought to be writing code that doesn't make
aliasing assumptions. Hence we ought to remove -fno-strict-aliasing from
Parrot's cflags. And as Dan put it see what breaks. So far nothing, at
least for a test build on Debian/x86. And as we're now letting gcc make
aliasing based optimisations, we might see more speed. (And maybe unicorns,
flying pigs, and round tuits)
Nicholas Clark
--- config/inter/progs.pl~Fri Oct 25 11:23:17 2002
+++ config/inter/progs.pl Tue Dec 31 21:18:24 2002
@@ -15,6 +15,7 @@ sub runstep {
my($cc, $link, $ld, $ccflags, $linkflags, $ldflags, $libs) =
Configure::Data-get(qw(cc link ld ccflags linkflags ldflags libs));
$ccflags =~ s/-D(PERL|HAVE)_\w+\s*//g;
+ $ccflags =~ s/-fno-strict-aliasing//g;
$linkflags =~ s/-libpath:\S+//g;
$ldflags =~ s/-libpath:\S+//g;
my $debug='n';
Re: [perl #19163] configure probe for va_list*
It would be nice if we could reach a solution that will work for the miniparrot (no configure, ansi C89 only) case. --Josh At 19:17 on 12/16/2002 EST, Dan Sugalski [EMAIL PROTECTED] wrote: At 8:33 AM -0500 12/16/02, Andy Dougherty wrote: On Mon, 16 Dec 2002, Steve Fink wrote: I'm a little confused by the va_list* stuff for sprintf*. At one point, people were saying that ppc does va_list differently, though I'm guessing that was a different compiler than gcc. Now, it seems like everything uses the same mechanism (and it was just patched to be this way by Dan). Here's the relevant excerpt from the glibc stdarg(3) man page: va_copy Since I'm not sure that we actually need va_copy, I'm just as happy saying no to its use and just using the va_start/list/end functions. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Tinderbox summary
At 19:55 on 12/08/2002 PST, Steve Fink [EMAIL PROTECTED] wrote: You can see the results here: http://foxglove.dnsalias.org/parrot/ I'm getting a 404 on that. --Josh
Re: [perl #18566] [PATCH]
How about s/fuck/fork/? --Josh (mmm.. brainspork) At 22:59 on 12/03/2002 EST, Dan Sugalski [EMAIL PROTECTED] wrote: At 8:23 PM -0500 12/3/02, Andy Dougherty wrote: On Thu, 21 Nov 2002, Leon Brocard wrote: ps You might be concerned about the name. Well, CPAN has a module which matches /fuck/ too. However, if everyone really thinks it is a problem, I don't see a problem with s/fuck/funk/g Well, I'll speak up. I find the name needlessly crude and offensive. I see no reason to use such a name and would strongly prefer that Parrot didn't. Parrot is a collective project representing a community of developers, and I, for one, don't wish to be associated with needlessly crude and offesnsive language. The point is well-taken. We need to either rename the directory and appropriately excise the docs, or move this out of the repository. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Function = Data Pointer Casts in nci.c
This should correct warnings on a few compilers and outright breakage on tcc.
It uses the D2FPTR/F2DPTR macros to cast between data and function pointers
where needed.
--Josh
Index: nci.c
===
RCS file: /cvs/public/parrot/nci.c,v
retrieving revision 1.3
diff -u -r1.3 nci.c
--- nci.c 21 Nov 2002 02:00:23 - 1.3
+++ nci.c 21 Nov 2002 05:39:52 -
@@ -20,7 +20,7 @@
/* Return void, take nothing */
static void pcf_v_v(struct Parrot_Interp *interpreter, PMC *self) {
void (*pointer)();
- pointer = self-cache.struct_val;
+ pointer = (void (*)())D2FPTR(self-cache.struct_val);
(void)(*pointer)();
interpreter-ctx.int_reg.registers[0] = 0;
interpreter-ctx.int_reg.registers[1] = 0;
@@ -34,7 +34,7 @@
static void pcf_i_v(struct Parrot_Interp *interpreter, PMC *self) {
int (*pointer)();
int return_data;
- pointer = self-cache.struct_val;
+ pointer = (int (*)())D2FPTR(self-cache.struct_val);
return_data = (int)(*pointer)();
interpreter-ctx.int_reg.registers[5] = return_data;
interpreter-ctx.int_reg.registers[0] = 0;
@@ -49,7 +49,7 @@
static void pcf_d_v(struct Parrot_Interp *interpreter, PMC *self) {
double (*pointer)();
double return_data;
- pointer = self-cache.struct_val;
+ pointer = (double (*)())D2FPTR(self-cache.struct_val);
return_data = (double)(*pointer)();
interpreter-ctx.num_reg.registers[5] = return_data;
interpreter-ctx.int_reg.registers[0] = 0;
@@ -65,7 +65,7 @@
double (*pointer)();
double return_data;
- pointer = self-cache.struct_val;
+ pointer = (double (*)())D2FPTR(self-cache.struct_val);
return_data = (double)(*pointer)(interpreter-ctx.num_reg.registers[5]);
interpreter-ctx.num_reg.registers[5] = return_data;
interpreter-ctx.int_reg.registers[0] = 0;
@@ -91,13 +91,13 @@
#else
/* And in here is the platform-independent way. Which is to say
here there be hacks */
- if (0 == string_length(signature)) return pcf_v_v;
+ if (0 == string_length(signature)) return F2DPTR(pcf_v_v);
if (!string_compare(interpreter, signature, string_from_c_string(interpreter, i,
1)))
-return pcf_i_v;
+return F2DPTR(pcf_i_v);
if (!string_compare(interpreter, signature, string_from_c_string(interpreter, d,
1)))
-return pcf_d_v;
+return F2DPTR(pcf_d_v);
if (!string_compare(interpreter, signature, string_from_c_string(interpreter, dd,
2)))
-return pcf_d_d;
+return F2DPTR(pcf_d_d);
return NULL;
#endif
Re: Tinderbox
At 21:33 on 11/19/2002 PST, Steve Fink [EMAIL PROTECTED] wrote: ### galactic-lcc (Debian x86, lcc 4.1) ### Failed the mod_n test in number.t, and the pushn popn (deep) test in stacks.t. Not sure what the story is with pushn/popn, but the mod_n failure is normal for lcc- it appears to provide a slightly broken % operator. --Josh
Re: Selfbootstrapping compilers (Was: faq)
At 20:47 on 11/13/2002 GMT, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Nov 13, 2002 at 03:06:03PM -0500, Dan Sugalski wrote: The goal is for Parrot to require a C compiler and a platform shell or Make tool (either one) and that's it. We will ship with bytecode files that have the bits needed for the build precompiled, so if the perl compiler's partially written in perl, we'll ship a perl6.pbc in the distribution. I believe that it can be done with just a C compiler. (no make tool or shell needed). If we use an equipped machine to unroll the makefile into the correc t steps (in the correct order), and turn that into C code that runs each in turn, then we can bootstrap enough to run bytecode. (and a bytecode make tool We've actually already reached that point. We currently generate a shell script with the build commands in it. We could generate a .c file just as easily. However, it's still necessary to tell it how to compile something somehow. I think we can figure out the details when the time comes though- the current shell script (which assume gcc/unix) is enough for now. We can add other .bat/.com files for other platforms, just to get things bootstrapped. Once we get to the point that miniparrot is actually part of the parrot build process, then we can revisit exactly how to build it. My inclination is to provide a configure script for platforms where that works, as well as native shell/bat/whatever is guaranteed to be available on that platform (including .or .c, if appropriate) for more unusual platform. --Josh
Re: [perl #18219] on_exit not portable
At 8:02 on 11/08/2002 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Josh Wilmes wrote: For the meantime, I have added the Parrot_exit and Parrot_on_exit function s to CVS. Thanks for providing this. I did slightly modify your patch to really get rid of the leaks: - test_main calls Parrot_exit now Huh- i have no idea how i missed that one.. thanks! - copied prototype to embed.h Righto. --Josh
Re: [perl #18219] on_exit not portable
For the meantime, I have added the Parrot_exit and Parrot_on_exit functions to CVS. This will fix the leak on all platforms, for now. If you want to fix internal_exception so this isn't necessary, that's fine- we can rip this out later. --Josh At 22:21 on 11/06/2002 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Dan Sugalski wrote: - I implemented Parrot_destroy, which cleans up all internal data structures of an interpreter and frees all used mem. Right, I understand. (And I really appreciate it--this was a hanging area that didn't get nearly the proper attention it needed) The bit I don't understand is the need for a hook into the process exit. Then you should have read on ;-) ~8% tests use internal_exception to deliver a test result. Not catching the exception may hide memory leaks in such tests. More detailled: Testing for memory leaks uses the same tests as are already in t/*. A test is passed, when the result is ok, and when it doesn't leak mem. This is accomplished by the scipt testyamd I checked in. When the exceptions just exits and Parrot_destroy isn't reached, the test would fail. Yeah, I think I'll do that for right now. What I'd like is a probe for this in configure. Oh, Brent :) I did deactivate it some minutes ago. Tinderboxen should be happy again. Waiting for the config test - but it's not an urgent one. leo
Re: [perl #18219] on_exit not portable
At 7:58 on 11/06/2002 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Josh Wilmes wrote: I agree. However, the point is fairly moot.. If we're going to do a Parrot_on_exit, it's just as easy to provide our own Parrot_exit and not need atexit() either.. it's not like atexit() is giving us much at that point. ... which would mean, that internal_exception needs an Parrot_interp* argument - which it will need anyway to do something useful finally. Not necessarily... I was thinking that Parrot_exit/Parrot_on_exit would have the same signatures as their libc equivalents. There should not be a need to introduce an interpreter in Parrot_exit().. It wouldn't hurt, but I don't think it's particularly necessary, if each interpreter has registered an on_exit handler.. --Josh
Re: [perl #18219] on_exit not portable
At 13:41 on 11/06/2002 EST, Dan Sugalski [EMAIL PROTECTED] wrote: Well, I got bit this week by the on_exit stuff. I'm still not sure why we need this. Could someone please explain, so I don't have to yank it out? Leo said: The on_exit/atexit is currently necessary to clean up behind exceptions. If you don't mind memory leaks after exceptions, remove the #define ATEXIT_DESTROY at the beginning of interpreter.c, until we have a config test for on_exit. atexit is not an alternative, because we might have multiple interpreters to clean up like in t/op/interp_2. How about we just remove that define for now for now, and let it leak that little bit for now? Presumably leo can add the ATEXIT_DESTROY to his build if he's trying to track down leaks. I'll try to find some time to write a more portable Parrot_on_exit/ Parrot_exit implementation later this week. Then we can get this cleanup behavior back on by default. At the moment, the tinderbox is a mess, which isn't cool. --Josh
Re: [perl #18219] on_exit not portable
At 13:55 on 11/06/2002 EST, Dan Sugalski [EMAIL PROTECTED] wrote: Leo said: The on_exit/atexit is currently necessary to clean up behind exceptions. If you don't mind memory leaks after exceptions, remove the Right, I saw that, I just don't understand why. If it's in as a fix for the current busted state of exceptions, then we need to fix exceptions, I think. I was operating on the assumption that some sort of global cleanup was a necessity for some reason. If it's a workaround for a bug in exceptions, then I agree. For now, I think I'd rather leak, as it is definitely killing the tinderbox. Agreed. --Josh
Re: [perl #18219] on_exit not portable
At 15:57 on 11/06/2002 EST, Dan Sugalski [EMAIL PROTECTED] wrote: This is was I did say above, just put comments around above statement if tinderboxen are the concern. Yeah, I think I'll do that for right now. What I'd like is a probe for this in configure. Oh, Brent :) If an on-exit cleanup is required for parrot to not leak memory, then simply probing for on_exit in configure won't be sufficient; that's why a platform.c implementation of Parrot_[on_]exit would be needed. --Josh
Re: [perl #18219] on_exit not portable
At 21:09 on 11/05/2002 GMT, Nicholas Clark [EMAIL PROTECTED] wrote: On Mon, Nov 04, 2002 at 07:45:46PM -0500, Josh Wilmes wrote: However, that still assumes we have atexit() everywhere. This appears to not be true on SunOS at least- apparently it has on_exit, though. IIRC ANSI C89 says that the library provides atexit() If SunOS doesn't want to be C89 compliant, then I have no qualms about telling the first SunOS porter that we'd be pleased to accept patches from *them* to work around it. (And the return value from sprintf in SunOS, if we need that.) I agree. However, the point is fairly moot.. If we're going to do a Parrot_on_exit, it's just as easy to provide our own Parrot_exit and not need atexit() either.. it's not like atexit() is giving us much at that point. --Josh
Re: [perl #18219] on_exit not portable
At 18:57 on 11/04/2002 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: atexit is not an alternative, because we might have multiple interpreters to clean up like in t/op/interp_2. So the issue here is that on_exit can take a parameter to be passed into the handler function, right? We could implement our own version of on_exit that registered the handlers/ arguments in a linked list or something, and have a single atexit() handler call them on our behalf. However, that still assumes we have atexit() everywhere. This appears to not be true on SunOS at least- apparently it has on_exit, though. But, it seems like we can make this work everywhere if we move to using a platform.c Parrot_on_exit() and Parrot_exit() rather than any kind of native on_exit/atexit/exit functions. Then we can make them all DTRT everywhere, I think... either with our without atexit(). If this (Parrot_exit/Parrot_on_exit) is a reasonable way to do things, I can probably come up with a patch later this week, if nobody else jumps on it ;-) --Josh
Re: miniparrot, a first attempt.
Is there a way to avoid stack walking at all in miniparrot?
What do we do instead? (Nothing?)
Miniparrot's main purpose is to be able to bootstrap parrot by running its
build scripts. Leaking a little memory may be acceptable.
--Josh
At 11:52 on 11/01/2002 EST, Andy Dougherty [EMAIL PROTECTED] wrote:
On Thu, 31 Oct 2002, Josh Wilmes wrote:
I've banged together a first attempt at a miniparrot- that is, something
that can be built on any ANSI C system without anything other than a
compiler.
Great!
I haven't looked deeply, but there is one little quibble I found so far:
In config/auto/alignptrs.pl, there is
if ($miniparrot) {
# we can't guarantee anything about pointer alignment under ANSI C89.
# so we will have to check every byte.
Configure::Data-set(ptr_alignment = 1);
Alas, you can't check every byte. It is true that you can't portably
guarantee anything about pointer alignment. Thus, for example, it's not
guaranteed that you can access things at arbitrary alignment.
In particular, with ptr_alignment = 1 on a SPARC, I get
signal BUS (invalid address alignment) in trace_system_stack at line
491 in file dod.c
491 size_t ptr = *(size_t *)cur_var_ptr;
--
Andy Dougherty[EMAIL PROTECTED]
Re: What to do if Digest::MD5 is unavailable?
I think this solution is the simplest... i'll go ahead and commit it.
--Josh
At 10:15 on 11/01/2002 PST, Brent Dax [EMAIL PROTECTED] wrote:
Andy Dougherty:
# At the moment, the bytecode fingerprint is built with
# Digest::MD5. Alas, Digest::MD5 wasn't standard with perl
# versions prior to 5.8.0. What should happen in those cases?
# Anybody have any good ideas?
Not sure if this qualifies as good :^), but we *could* package the
pure-Perl implementation of Digest::MD5 with Parrot.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
miniparrot, a first attempt.
I've banged together a first attempt at a miniparrot- that is, something that can be built on any ANSI C system without anything other than a compiler. Right now, as a proof of concept, it's building a source tree and a shell script which would build miniparrot under gcc. A real version would include platform-specific build scripts which are a tad smarter- but since all they have to do now is run a sequence of compile steps, they don't need to do much other than figure out what compiler to use and how to call it. Here's a log of how to use it. The way I would envision this working is that we would periodically run this and check the results into CVS, so that there was a miniparrot tree available alongside the real one. We could tinderbox it as well. Note: Until the stack direction issue is sorted out, this isn't really going to work across platforms. joshgalactic:~/devel/parrot-rw% make miniparrot-update tools/dev/rebuild_miniparrot.pl ** tools/dev/rebuild_miniparrot.pl: reconfiguring parrot for miniparrot build - perl Configure.pl --miniparrot Parrot Version 0.0.8 Configure 2.0 Copyright (C) 2001-2002 Yet Another Society Hello, I'm Configure. My job is to poke and prod your system to figure out how to build Parrot. The process is completely automated, unless you passed in the `--ask' flag on the command line, in which case it'll prompt you for a few pieces of info. Since you're running this script, you obviously have Perl 5--I'll be pulling some defaults from its configuration. Checking MANIFEST...done. Setting up Configure's data structures...done. Checking for --miniparrot...Yes..done. Loading platform hints file...(no hints) done. Enabling debugging...(none requested) done. Determining what C compiler and linker to use...done. Determining what types Parrot should use...done. Determining what opcode files should be compiled in...done. Setting up experimental systems...done. Determining what pmc files should be compiled in...done. Tweaking ccflags...done. Determining your minimum pointer alignment...done. Probing for C headers...done. Determining some sizes...done. Determining stack growth direction...done. Computing native byteorder for Parrot's wordsize...done. Figuring out how to pack() Parrot's types...done. Figuring out what formats should be used for sprintf...done. Determining if your C compiler is actually gcc...done. Determining architecture, OS and JIT capability...done. Verifying that the compiler supports function pointer casts...done. Determining if your compiler supports computed goto...done. Determining what allocator to use ... (gc) done. Generating config.h...done. Writing Parrot::Config module...done. Generating Makefiles...done. Recording this configuration in myconfig...done. Moving platform files into place...done. Generating libparrot.def...done. Generating core pmc list...done. Okay, we're done! You can now use `make' (or your platform's equivalent to `make') to build your Parrot. After that, you can use `make test' to run the test suite. Happy Hacking, The Parrot Team ** tools/dev/rebuild_miniparrot.pl: initiating parrot prebuild - make miniparrot-prebuild make[1]: Entering directory `/home/josh/devel/parrot-rw' perl vtable_h.pl perl ops2c.pl C core.ops debug.ops io.ops math.ops rx.ops perl ops2c.pl CPrederef core.ops debug.ops io.ops math.ops rx.ops perl ops2pm.pl core.ops debug.ops io.ops math.ops rx.ops perl fingerprint_c.pl fingerprint.c ** tools/dev/rebuild_miniparrot.pl: removing files in miniparrot directory - cd classes; make array.c boolean.c continuation.c coroutine.c csub.c default.c intlist.c intqueue.c key.c multiarray.c perlarray.c perlhash.c perlint.c perlnum.c perlstring.c perlundef.c pointer.c scalar.c sub.c make[2]: Entering directory `/home/josh/devel/parrot-rw/classes' perl pmc2c.pl array.pmc Scanning /home/josh/devel/parrot-rw/classes/array.pmc... perl pmc2c.pl boolean.pmc Scanning /home/josh/devel/parrot-rw/classes/boolean.pmc... Scanning /home/josh/devel/parrot-rw/classes/perlint.pmc... Scanning /home/josh/devel/parrot-rw/classes/scalar.pmc... perl pmc2c.pl continuation.pmc Scanning /home/josh/devel/parrot-rw/classes/continuation.pmc... perl pmc2c.pl coroutine.pmc Scanning /home/josh/devel/parrot-rw/classes/coroutine.pmc... perl pmc2c.pl csub.pmc Scanning /home/josh/devel/parrot-rw/classes/csub.pmc... perl pmc2c.pl default.pmc perl pmc2c.pl intlist.pmc Scanning /home/josh/devel/parrot-rw/classes/intlist.pmc... perl pmc2c.pl intqueue.pmc Scanning /home/josh/devel/parrot-rw/classes/intqueue.pmc... perl pmc2c.pl key.pmc Scanning /home/josh/devel/parrot-rw/classes/key.pmc... perl pmc2c.pl multiarray.pmc Scanning /home/josh/devel/parrot-rw/classes/multiarray.pmc... Scanning /home/josh/devel/parrot-rw/classes/array.pmc... perl pmc2c.pl perlarray.pmc Scanning /home/josh/devel/parrot-rw/classes/perlarray.pmc... Scanning /home/josh/devel/parrot-rw/classes/array.pmc... perl pmc2c.pl perlhash.pmc Scanning
Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
If patch [perl #18127] goes in, we can dodge this bullet a while longer :)
--Josh
At 12:54 on 10/28/2002 EST, Andy Dougherty [EMAIL PROTECTED] wrote:
I need some portability help. In config/auto/stackdir.pl (the stack
growth direction test) I want to portably compile and link together three
files. (The functions are in separate files to prevent compiler
optimizations from fouling up the stack direction test.)
Currently, config/auto/stackdir.pl runs the following commands:
$cc $ccflags -I./include -c test0.c
$cc $ccflags -I./include -c test1.c
$cc $ccflags -I./include -c test2.c
$link $linkflags ${cc_exe_out}test$exe test0$o test1$o test2$o $libs
Unfortunately, that doesn't work with Microsoft's Visual C because the
cc_exe_out flag is -Fe, and that doesn't work for the linker. I'd like to
change that last command to
$link $linkflags ${link_exe_out}test$exe test0$o test1$o test2$o $libs
but I'm unsure what to put for link_exe_out for each of the three
compilers mentioned in config/init/hints/mswin32.pl, nor for the
compilers used under OS/2 and VMS.
NOTE: The variable is called $link, but it could be 'cc' or 'cl' or
something like that. It's whatever command I should call to link together
the three object files to create an executable.
So, my simple request: What is the correct command line invocation
for each of those systems to link together object files?
--
Andy Dougherty[EMAIL PROTECTED]
Re: [PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
At 11:57 on 10/24/2002 EDT, Jason Gloudon [EMAIL PROTECTED] wrote: On Wed, Oct 23, 2002 at 11:23:26PM -0400, Josh Wilmes wrote: I've got a patch which switches this detection to happen at run-time instead of at build-time. This is going to be necessary for miniparrot (which has no Configure step) anyway. Have you checked how much this affects the performance of stack walking ? It shouldn't at all. It does the check once, when parrot starts up. One way of simplifying things here is to always walk the stack in the same direction (lowest address to higher address), and swap the lo and high pointe r as the start and end points of the loop. This eliminates the need for an explicit stack growth direction test. One thing that will still remain is that the garbage collector must know the CPU instruction set so it can use the appropriate means to locate pointers in registers. I'm not sure if this can be done by testing for preprocessor symbo ls alone. *eyes glazed over* --Josh
Re: [PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
At 18:16 on 10/24/2002 EDT, Jason Gloudon [EMAIL PROTECTED] wrote: STACK_DIR is a compile time constant, so the multiplies in the following code are eliminated by the compiler if it does any optimization. By making STACK_DIR a variable, the compiler is no longer able to do this and has to generate code to do multiplies. Fair enough. I suspected it had to be something like that, but I was kind of dense and didn't follow what you were saying. If I rejigger my code to make it work both ways (run-time for miniparrot, compiled-in elsewise), will that be OK? (I can do this by #defining PARROT_STACK_DIR to either a number or a variable name in stackdir.pl) --Josh
[PATCH] Probe stack direction at run-time (was Re: Configuring and DOD problems)
At 22:58 on 10/23/2002 EDT, Erik Lechak [EMAIL PROTECTED] wrote:
I fix the errors then It gets all wierd on the def PARROT_STACK_DIR. So
I tried to figure out that problem.
Anyways, I am on Win XP using VC++. I look in Config.pm and I see this
'#define PARROT_STACK_DIR'. It's not defined to anything, but the code
tries to do math with it. What is this?
It's supposed to be either 1 or -1, determined at build time via config/
auto/stackdir.pl.
Evidently, that didn't work right.
I've got a patch which switches this detection to happen at run-time
instead of at build-time. This is going to be necessary for miniparrot
(which has no Configure step) anyway.
Can you try applying this patch and see if it addresses your issue?
With the current state of the tinderbox, i'd rather not commit it just yet.
--Josh
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.239
diff -u -r1.239 MANIFEST
--- MANIFEST 23 Oct 2002 05:33:39 - 1.239
+++ MANIFEST 24 Oct 2002 03:19:15 -
@@ -58,10 +58,6 @@
config/auto/pack.pl
config/auto/sizes.pl
config/auto/sizes/test_c.in
-config/auto/stackdir.pl
-config/auto/stackdir/test0_c.in
-config/auto/stackdir/test1_c.in
-config/auto/stackdir/test2_c.in
config/gen/config_h.pl
config/gen/config_h/config_h.in
config/gen/config_pm.pl
Index: dod.c
===
RCS file: /cvs/public/parrot/dod.c,v
retrieving revision 1.24
diff -u -r1.24 dod.c
--- dod.c 23 Oct 2002 05:27:01 - 1.24
+++ dod.c 24 Oct 2002 03:19:17 -
@@ -21,6 +21,17 @@
static size_t find_common_mask(size_t val1, size_t val2);
+static int PARROT_STACK_DIR;
+
+void
+dod_init(void)
+{
+int local_variable = 1;
+
+PARROT_STACK_DIR = probe_stack_direction(local_variable);
+}
+
+
PMC *
mark_used(PMC *used_pmc, PMC *current_end_of_list)
{
@@ -478,7 +489,7 @@
return last;
for (cur_var_ptr = lo_var_ptr;
-(ptrdiff_t)(cur_var_ptr * PARROT_STACK_DIR)
+(ptrdiff_t)(cur_var_ptr * PARROT_STACK_DIR)
(ptrdiff_t)(hi_var_ptr * PARROT_STACK_DIR);
cur_var_ptr = (size_t)( (ptrdiff_t)cur_var_ptr +
PARROT_STACK_DIR * PARROT_PTR_ALIGNMENT )
Index: global_setup.c
===
RCS file: /cvs/public/parrot/global_setup.c,v
retrieving revision 1.36
diff -u -r1.36 global_setup.c
--- global_setup.c 5 Sep 2002 17:56:58 - 1.36
+++ global_setup.c 24 Oct 2002 03:19:17 -
@@ -22,8 +22,13 @@
init_world(void)
{
PMC* key;
-string_init(); /* Set up the string subsystem */
-
+
+/* Set up the string subsystem */
+string_init();
+
+/* set up the dod subsystem */
+dod_init();
+
/* Call base vtable class constructor methods */
Parrot_initialize_core_pmcs();
Index: config/gen/config_h/config_h.in
===
RCS file: /cvs/public/parrot/config/gen/config_h/config_h.in,v
retrieving revision 1.9
diff -u -r1.9 config_h.in
--- config/gen/config_h/config_h.in 11 Oct 2002 01:46:37 - 1.9
+++ config/gen/config_h/config_h.in 24 Oct 2002 03:19:19 -
@@ -42,7 +42,6 @@
#define PARROT_BYTEORDER${byteorder}
#define PARROT_BIGENDIAN${bigendian}
#define PARROT_PTR_ALIGNMENT${ptr_alignment}
-#define PARROT_STACK_DIR${stackdir}
typedef Parrot_Int INTVAL;
typedef Parrot_UInt UINTVAL;
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.46
diff -u -r1.46 root.in
--- config/gen/makefiles/root.in 21 Oct 2002 08:47:06 - 1.46
+++ config/gen/makefiles/root.in 24 Oct 2002 03:19:20 -
@@ -74,7 +74,7 @@
$(INC)/interp_guts.h $(INC)/rx.h $(INC)/rxstacks.h $(INC)/intlist.h \
$(INC)/embed.h $(INC)/warnings.h $(INC)/misc.h $(INC)/pmc.h \
$(INC)/key.h $(INC)/hash.h $(INC)/smallobject.h $(INC)/headers.h $(INC)/dod.h \
-$(INC)/method_util.h $(INC)/list.h
+$(INC)/method_util.h $(INC)/list.h $(INC)/stackdir.h
ALL_H_FILES = $(GENERAL_H_FILES)
@@ -100,7 +100,7 @@
embed$(O) warnings$(O) ${cg_o} \
packout$(O) byteorder$(O) debug$(O) smallobject$(O) \
headers$(O) dod$(O) method_util$(O) \
- misc$(O) spf_render$(O) spf_vtable$(O)
+ misc$(O) spf_render$(O) spf_vtable$(O) stackdir$(O)
O_FILES = $(INTERP_O_FILES) \
$(IO_O_FILES) \
@@ -323,6 +323,8 @@
###
global_setup$(O) : $(GENERAL_H_FILES)
+
+stackdir$(O) : $(GENERAL_H_FILES)
pmc$(O) : $(GENERAL_H_FILES)
Index: include/parrot/dod.h
===
RCS file: /cvs/public/parrot/include/parrot/dod.h,v
retrieving revision 1.4
diff -u -r1.4 dod.h
---
Re: cvs commit: parrot/lib/Parrot/Configure RunSteps.pm
At 20:15 on 07/18/2002 -, [EMAIL PROTECTED] wrote: NOTE: The test file might not work right if the platform doesn't support ff lush(stdout). If someone has a better idea, let me know. Are there platforms which do not? AFAIK, fflush() is specified in the C standard. If you want to be especially paranoid, it might make sense to run make x a parameter to your test program and run it once for each of the alignment sizes, rather than trying to do it all in one go. --Josh
Re: .dev files
At 14:18 on 07/18/2002 PDT, Brent Dax [EMAIL PROTECTED] wrote: Tanton Gibbs: # So, my final question is: should .dev files be plain text or POD? My vote is for pod. pod is close enough to plain text that I don't see why it shouldn't be in it. Me too. That way you can all come to your senses and move them into the ..c files more easily. --Josh
Re: [PATCH] dod.dev
I really dislike this. --Josh At 22:56 on 07/18/2002 EDT, Melvin Smith [EMAIL PROTECTED] wrote: At 06:35 PM 7/18/2002 -0400, Tanton Gibbs wrote: This is the .dev file for dod.c Applied, thanks. They are all in docs/dev now. -Melvin
parrot_coverage
I noticed this morning that my parrot_coverage cron job was broken, so the stats at http://www.hitchhiker.org/parrot_coverage/ weren't updating properly. They should be correct now. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Re: [PATCH] .dev files.
For what it's worth, I agree. I think that when your documentation is tied to the structure of your source files, it only makes sense to put it IN the source files. I don't think you can do literate programming half-way. While I don't think literate programming is the right thing to do to produce well-organized design documentation (of the sort we're doing in the PDDs), it's a perfect way to do implementation documentation, of all sorts. Moving .devs into our .c files would add a big block of POD at the beginning or the end. So what? Sounds good to me. --Josh At 11:39 on 07/17/2002 PDT, John Porter [EMAIL PROTECTED] wrote: Tanton Gibbs wrote: . . . That saves a person digging through the .c file to find what they are looking for. Perhaps we could automatically update the .dev file with the POD found in the .c file? 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. -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: [PATCH] rx.dev
Well, the .h files live elsewhere, but yeah, for now I think .dev files should live with the .c files. Unless someone has an alternative suggestion. I'll update make check_source and pdd07 to reflect this. --Josh At 18:14 on 07/16/2002 PDT, John Porter [EMAIL PROTECTED] wrote: Melvin Smith wrote: I put it temporarily in the root dir, which I know is wrong. Where should .dev files go, anyway? Actually, I think that's right. ..dev files live alongside their .c/.h siblings, no? -- JohnDouglasPorter __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: Streams vs. Descriptors
I changed io.ops and pretty much the rest of parrot to always go through PIO, which has streams. (or at least handles). I left core.ops alone because I didn't know what the intent was. Are those ops meant to be superseded by the ones in io.ops? IMHO, all IO in parrot should go through PIO, so file descriptors should not be used at all. --Josh At 18:33 on 07/14/2002 CDT, Bryan Logan [EMAIL PROTECTED] wrote: For file I/O (in core.ops, not io.ops), do we want to use file descriptors = or streams? open uses fopen(), close uses fclose(), but read uses read(), and write use= s write(). And all the comments=20 say descriptors. Any opinions one which way the code should be patched? -- Bryan Logan
Re: coders: add doco
I'm still catching up on backlogged mailing list mail here, but just to try to be helpful- Like many folks who lurk on this list, I have limited time to do detailed work on parrot internals, much as I would like to. But I am always excited when there's an opportunity to do simple, menial tasks that help our more active contributors to be more productive. If someone can tell me what the documentation standards should be, i'll be happy to either devise a program to try to check it (like check_source_standards.pl does for our coding standards) or manually review and prod folks to help get our documentation up to standards. But before I can do that I need to know what the end goal is. In general, Are we shooting for literate code, or separate documentation from code? Along the same lines, what documents are we looking to generate? Per-file docs? One big developers guide? (If so, how is it divided up) Are POD directives to be used for things other than strictly docmentation? (=for API? did that go anywhere?) Do we want POD for every function? Every non-static function? Are there simple guidelines we can use to programatically identify trouble spots? - a certain comments/line of code metric - a readability metric (Lingua::EN::Fathom) for our comments? Etc.. IMHO, all this needs to either go into pdd07 or into a new pdd. I hate to bounce this back to the designers, but I don't think I have enough experience, perspective, or authority to make any of these decisions in a vacuum. --Josh
Re: PARROT QUESTIONS: Use the source, Luke
Brent, Good stuff. Didn't you also send out a draft PDD about how types should be named and managed in parrot at one point? I, for one, would love to see a PDD that described C-level nanming and namespace management in general. --Josh At 3:11 on 07/14/2002 PDT, Brent Dax [EMAIL PROTECTED] wrote: # 2. What does having a Parrot_ prefix signify, considering=20 # both the opcodes and=20 # the embed api use it? It's hard to distinguish between them. It signifies one of the following: -This function is externally visible. -This function belongs to Parrot at large, and not any particular subsystem (e.g. Parrot_sprintf and friends). -This function has an identical name to a C library function because it emulates it for certain platforms (e.g. Parrot_dlopen (?)). -This function is autogenerated, so we're going to be paranoid about naming conflicts. For functions in the last category, I'd suggest we use subsystem-specific names, e.g. Op_ for the opcodes.
Re: Streams vs. Descriptors
IMHO, there's no way to find out quite like trying to use it :) In my experiences with it thus far, it all seems to work fine. Melvin has indicated that its API and internal structure may need some changes at some point, but the basic functionality does seem to be there today, at least enough for the moment. --Josh At 18:22 on 07/14/2002 PDT, Stephen Rawls [EMAIL PROTECTED] wrote: --- Josh Wilmes [EMAIL PROTECTED] wrote: IMHO, all IO in parrot should go through PIO, so file descriptors should not be used at all. From io.ops: This will go away when print ops are all migrated to use ParrotIO instead of STDIO. Right now ParrotIO is not stable enough to replace STDIO. Maybe someone with more knowledge than me can explain what is unstable? Thanks, Stephen Rawls __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
Re: init_method_t for coroutines and subs?
At 8:55 on 07/05/2002 CDT, David M. Lloyd [EMAIL PROTECTED] wrote: It got removed because it wasn't in the spec... Dan directed that we replace it with a version of init that accepts a PMC argument (init_pmc_method_t) that can be used to send in initial size or whatever else you can dream up. In that case, can the extra int be removed from the remaining ones? --Josh
XML escaping, etc..
I've been meaning to ask- is there any plan to add special support for XML features such as string escaping? It would be very useful, IMHO, to have something analogous to the \Q feature in perl5 for escaping regexps, but which would do XML-style and escaping. I'm specifically interested in how features like this might be applicable to the problem of Cross-Site Scripting security vulnerabilities in perl-based web applications. The types of escaping which are necessary for this are described at http://www.cert.org/tech_tips/malicious_code_mitigation.html I think tainting is a BIG part of the solution. But is there more that might make sense to provide in the language? With XML generation and parsing becoming so common, it seems to me that an argument could be made that low-level mechanisms for properly parsing and generating XML/HTML content in a flexible way belongs in the core libraries, if not the language itself. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Re: [netlabs #758] [PATCH] Fixes for example programs
This patch doesn't want to apply for me: patching file examples/assembly/fact.pasm Hunk #2 FAILED at 35. 1 out of 2 hunks FAILED -- saving rejects to file examples/assembly/fact.pasm.rej patching file examples/assembly/hanoi.pasm Hunk #2 FAILED at 110. 1 out of 6 hunks FAILED -- saving rejects to file examples/assembly/hanoi.pasm.rej patching file examples/assembly/jump.pasm patching file examples/assembly/local_label.pasm Hunk #1 FAILED at 8. 1 out of 1 hunk FAILED -- saving rejects to file examples/assembly/local_label.pasm.rej Perhaps it got mangled? Can you send it to me as an attachment? --Josh
init_method_t for coroutines and subs?
I know there was some talk about this extra address parameter recently, but i'm not sure what the upshot of it is. Right now, tcc is complaining loudly because the init functions for parrotsub and parrotcoroutine don't match the init_method_t type in the _vtable structure. What's the deal here? --Josh array.c:void Parrot_Array_init (struct Parrot_Interp *interpreter, PMC* pmc) default.c:void Parrot_default_init (struct Parrot_Interp *interpreter, PMC* pmc) default.c:void Parrot_default_init_pmc (struct Parrot_Interp *interpreter, PMC* pmc, PMC* value) intqueue.c:void Parrot_IntQueue_init (struct Parrot_Interp *interpreter, PMC* pmc) parrotcoroutine.c:void Parrot_ParrotCoroutine_init (struct Parrot_Interp *interpreter, PMC* pmc, INTVAL address) parrotpointer.c:void Parrot_ParrotPointer_init (struct Parrot_Interp *interpreter, PMC* pmc) parrotsub.c:void Parrot_ParrotSub_init (struct Parrot_Interp *interpreter, PMC* pmc, INTVAL address) perlarray.c:void Parrot_PerlArray_init (struct Parrot_Interp *interpreter, PMC* pmc) perlhash.c:void Parrot_PerlHash_init (struct Parrot_Interp *interpreter, PMC* pmc) perlint.c:void Parrot_PerlInt_init (struct Parrot_Interp *interpreter, PMC* pmc) perlnum.c:void Parrot_PerlNum_init (struct Parrot_Interp *interpreter, PMC* pmc) perlstring.c:void Parrot_PerlString_init (struct Parrot_Interp *interpreter, PMC* pmc) perlundef.c:void Parrot_PerlUndef_init (struct Parrot_Interp *interpreter, PMC* pmc) -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Re: [PATCH] 3-arg chopn
Can you add a test as well?
--Josh
At 14:37 on 07/02/2002 CDT, brian wheeler [EMAIL PROTECTED] wrote:
I saw this was a TODO item in core.ops.
Brian
--- core.ops 1 Jul 2002 17:18:04 - 1.176
+++ core.ops 2 Jul 2002 19:41:44 -
@@ -2074,9 +2074,9 @@
=item Bchopn(inout STR, in INT)
-Remove $2 characters from the end of the string in $1.
+=item Bchopn(out STR, in STR, in INT)
-TODO: Create a three-argument version of this? Don't force in-place modifica
tion.'
+Remove $2 characters from the end of the string in $1.
=cut
@@ -2085,6 +2085,11 @@
goto NEXT();
}
+inline op chopn(out STR, in STR, in INT) {
+ $1 = string_copy(interpreter, $2);
+ (void)string_chopn($1,$3);
+ goto NEXT();
+}
Re: Possibility of XS support
And i think it's worth saying that the XS hook should be a well-behaved parrot extension, once the extension API is defined. Having it get too intertwined with parrot's guts would be a terrible thing. --Josh At 9:42 on 06/25/2002 CDT, Dan Sugalski [EMAIL PROTECTED] wrote: At 8:41 AM -0500 6/25/02, Dave Goehrig wrote: Last night I wanted to see just how much of the API very vanilla XS code would require. In the limited sampling I did, I found 37 distinct functions and macros. Based on this, I'd say a reasonable guestimate for minimal core functionality is about 50 distinct functions. Best guesses would place reasonably featured XS support at somewhere like a mixture 150-250 function calls and macros, where reasonably featured implies some minimal amount of work to get the wierdest XS modules working. (which would be expected with any serious internals revision). Porting 50 functions doesn't seem that unreasonable to save thousands of hours of work. I'd be willing to take the initial stab at it unless someone else is more motivated. That'd be cool. Be aware that Parrot, at the moment, has *no* extension API at the moment. (None of the functions, save those explicitly exported in the embedding code, will be visible externally) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [netlabs #720] [Applied] Core.ops documentation
Applied.
--Josh
At 23:55 on 06/20/2002 -, Simon Glover (via RT)
[EMAIL PROTECTED] wrote:
# New Ticket Created by Simon Glover
# Please include the string: [netlabs #720]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=720
Adds documentation for the interpinfo and stringinfo ops.
Various other minor documentation fixes/enhancements.
One minor code change to interpinfo so that the actions agree with
the intention of the case statement.
Simon
--- core.ops.old Thu Jun 20 18:29:46 2002
+++ core.ops Thu Jun 20 19:43:33 2002
@@ -187,9 +187,9 @@
=item Bord(out INT, in STR, in INT)
-Three-argument form returns character $3 of string $2 in register 1.
+Three-argument form returns character $3 of string $2 in register $1.
If $2 is empty, throws an exception.
-If $3 is greater than the length of string $2, throws an exception
+If $3 is greater than the length of string $2, throws an exception.
If $3 is less then zero but greater than the negative of the length, counts
backwards through the string, such that -1 is the last character, -2 is the
second-to-last character, and so on.
@@ -464,7 +464,7 @@
=item Bset_addr(out INT, in INT)
-Sets register $1 to the current address plus the offset $2
+Sets register $1 to the current address plus the offset $2.
=cut
@@ -1640,7 +1640,7 @@
This op is provided for those who need it (such as speed-sensitive
applications with heavy use of mod, but using it only with positive
arguments), but a more mathematically useful mod based on ** floor(x/y)
-and defined with y == 0 is provided by the mod_i op.
+and defined with y == 0 is provided by the mod op.
[1] Brian W. Kernighan and Dennis M. Ritchie, *The C Programming
Language*, Second Edition. Prentice Hall, 1988.
@@ -1677,7 +1677,7 @@
This op is provided for those who need it, but a more mathematically
useful numeric mod based on floor(x/y) instead of truncate(x/y) and
-defined with y == 0 is provided by the mod_n op.
+defined with y == 0 is provided by the mod op.
[1] Brian W. Kernighan and Dennis M. Ritchie, *The C Programming
Language*, Second Edition. Prentice Hall, 1988.
@@ -2158,8 +2158,6 @@
}
-=back
-
=cut
@@ -2229,8 +2227,6 @@
goto NEXT();
}
-=back
-
=cut
@@ -3230,7 +3226,7 @@
=head2 Register stack operations
-These operations effect individual registers.
+These operations affect individual registers.
=over 4
@@ -3241,7 +3237,7 @@
=item Bentrytype(out INT, in INT)
-Gets the type of entry $2 of the stack and puts it in $1
+Gets the type of entry $2 of the user stack and puts it in $1.
=cut
@@ -3279,7 +3275,7 @@
=item Bsave(in PMC)
-Save register or constant $1 onto the stack.
+Save register or constant $1 onto the user stack.
=cut
@@ -3311,7 +3307,7 @@
=item Bsavec(in PMC)
-Save a clone of register or constant $1 onto the stack.
+Save a clone of register or constant $1 onto the user stack.
=cut
@@ -3331,7 +3327,7 @@
=item Brestore(out STR)
-Restore register $1 from the appropriate register stack.
+Restore register $1 from the user stack.
=cut
@@ -3462,13 +3458,11 @@
-=item Bjsr()
+=item Bjsr(in INT)
-Jump to the location specified by register X. Push the current
+Jump to the location specified by register $1. Push the current
location onto the call stack for later returning.
-TODO: Implement this, or delete the entry.
-
=cut
inline op jsr(in INT) {
@@ -3479,7 +3473,7 @@
-=item Bjump(out INT)
+=item Bjump(in INT)
Jump to the address held in register $1.
@@ -3549,7 +3543,7 @@
=item Bsweep()
-Trigger a dead object detection sweep
+Trigger a dead object detection (DOD) sweep.
=cut
@@ -3561,7 +3555,7 @@
=item Bcollect()
-Trigger a GC collection
+Trigger a garbage collection.
=cut
@@ -3583,7 +3577,7 @@
=item Bsweepon()
-Re-enable DOD sweeps
+Re-enable DOD sweeps.
=cut
@@ -3596,7 +3590,7 @@
=item Bcollectoff()
-Disable GC runs (nestable)
+Disable GC runs (nestable).
=cut
@@ -3607,7 +3601,7 @@
=item Bcollecton()
-Re-enable GC
+Re-enable GC.
=cut
@@ -3622,7 +3616,35 @@
=item Binterpinfo(out INT, in INT)
-Fetch some piece of information about the interpreter and put it in $1
+Fetch some piece of information about the interpreter and put it in $1.
+Possible values for $2 are:
+
+=over 4
+
+=item 1 The total amount of allocatable memory allocated. This figure
+does not include memory used for headers or for the interpreter's internal
+structures.
+
+=item 2 The number of dead object detection runs performed.
+
+=item 3 The number of garbage collection runs performed.
+
Re: [netlabs #719] [Applied] followup to #709, finding all .pmcs
Applied.
--Josh
At 23:25 on 06/20/2002 -, Kevin Falcone (via RT)
[EMAIL PROTECTED] wrote:
# New Ticket Created by Kevin Falcone
# Please include the string: [netlabs #719]
# in the subject line of all future correspondence about this issue.
# URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=719
When I wrote the patch in #709, I failed to notice that the root
Makefile links against the classes, so things bomb when you add a new
...pmc to the classes directory. This fixes that.
-kevin
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.11
diff -u -r1.11 root.in
--- config/gen/makefiles/root.in 12 Jun 2002 22:12:20 - 1.11
+++ config/gen/makefiles/root.in 20 Jun 2002 23:18:22 -
@@ -71,11 +71,7 @@
ALL_H_FILES = $(GENERAL_H_FILES)
-CLASS_O_FILES = classes/default$(O) classes/array$(O) \
-classes/perlint$(O) classes/perlstring$(O) classes/perlnum$(O) \
-classes/perlarray$(O) classes/perlundef$(O) \
-classes/perlhash$(O) classes/parrotpointer$(O) classes/parrotsub$(O) \
-classes/parrotcoroutine$(O) classes/intqueue$(O)
+CLASS_O_FILES = ${pmc_classes_o}
ENCODING_O_FILES = encodings/singlebyte$(O) encodings/utf8$(O) \
encodings/utf16$(O) \
Index: config/inter/pmc.pl
===
RCS file: /cvs/public/parrot/config/inter/pmc.pl,v
retrieving revision 1.1
diff -u -r1.1 pmc.pl
--- config/inter/pmc.pl 17 Jun 2002 05:00:00 - 1.1
+++ config/inter/pmc.pl 20 Jun 2002 23:18:22 -
@@ -32,13 +32,18 @@
}
}
+ # names of class files for classes/Makefile
(my $pmc_o = $pmc) =~ s/\.pmc/\$(O)/g;
+ # calls to pmc2c.pl for classes/Makefile
(my $pmc_build = $pmc) =~ s/(.*?)\.pmc ?/$1.c $1.h: $1.pmc\n\t\$(PMC2C) $1
..pmc\n\n$1\$(O): \$(H_FILES)\n\n/g;
+ # build list of libraries for link line in Makfile
+ (my $pmc_classes_o = $pmc_o) =~ s/^| / classes\//g;
Configure::Data-set(
-pmc = $pmc,
-pmc_o = $pmc_o,
-pmc_build = $pmc_build
+pmc = $pmc,
+pmc_o = $pmc_o,
+pmc_build = $pmc_build,
+pmc_classes_o = $pmc_classes_o
);
}
--
I wrote a reply saying that I was sorry that he did not have the time
to read the FAQ, and I'm sure he'd understand that I didn't have the
time to read it to him. -- Terry Carroll
Re: Fwd: Re: Tasks for the interested
So now who's going to implement it? (must..contain..urge..) --Josh At 17:03 on 06/18/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: 6) Infocom's z-machine http://www.gnelson.demon.co.uk/zspec/sect14.html Well, that's one...
Re: Fwd: Re: Tasks for the interested
Oh man. Now i'm doomed. I guess i'll start playing tonight then ;-) --Josh At 17:20 on 06/18/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: At 5:10 PM -0400 6/18/02, Josh Wilmes wrote: So now who's going to implement it? (must..contain..urge..) You think *you* have to contain the urge... :) Seriously, this is a good thing to tackle. Not only does it involve custom opcode libraries, but it also requires packfile loading with translation on input. (Since z-machine bytecode is *not* 32-bit... :) While it may seem kind of silly to be able to do: parrot -m:zmachine lurking_horror.dat and see: You've waited until the last minute again. This time it's the end of the term , so all the TechNet terminals in the dorm are occupied. So, off you go to the old Comp Center. Too bad it's the worst storm of the winter (Murphy's Law, right? ), and you practically froze to death slogging over here from the dorm. Not to mention jumping at every shadow, what with all the recent disappearances. Tim e to find a free machine, get to work, and write that twenty page paper. THE LURKING HORROR An Interactive Horror Copyright (c) 1987 by Infocom, Inc. All rights reserved. THE LURKING HORROR is a trademark of Infocom, Inc. Release 221 / Serial number 870918 Making it happen involves most of the infrastructure we'd need to get working to get .NET and JVM code loaded in. At 17:03 on 06/18/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: 6) Infocom's z-machine http://www.gnelson.demon.co.uk/zspec/sect14.html Well, that's one... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] packfile reading
At 19:33 on 06/10/2002 EDT, Jason Gloudon [EMAIL PROTECTED] wrote: Someone may want to write the code to do something useful with the results of stat() when mmap() is not being used. It's supposed to already do that... did i goof? --Josh
[COMMIT] More function/data pointer games..
FYI. If anyone wants to provide a uintptr_t-equivalent for parrot, i'll happily switch this to use it. --Josh --- Forwarded Message Date:09 Jun 2002 16:44:35 - From:[EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: parrot/include/parrot parrot.h cvsuser 02/06/09 09:44:35 Modified:include/parrot parrot.h Log: Revisiting the problem we saw before, where tcc won't permit casting between function and data pointers. (this is technically undefined by ANSI C). However, it is possible to cast between them by first casting to an integer of sufficient size. Defined two macros for converting values betwen function and data pointers and inserted them in the right places. This gets things to build with tcc, and makes us more ANSI-correct. We might be able to remove the check for this in Configure.pl if everything uses these macros. (Though if JIT ever works on tcc, i will be impressed) Revision ChangesPath 1.38 +14 -1 parrot/include/parrot/parrot.h Index: parrot.h === RCS file: /cvs/public/parrot/include/parrot/parrot.h,v retrieving revision 1.37 retrieving revision 1.38 diff -u -w -r1.37 -r1.38 --- parrot.h 8 Jun 2002 21:53:20 - 1.37 +++ parrot.h 9 Jun 2002 16:44:35 - 1.38 @@ -1,7 +1,7 @@ /* parrot.h * Copyright: (When this is determined...it will go here) * CVS Info - * $Id: parrot.h,v 1.37 2002/06/08 21:53:20 grunblatt Exp $ + * $Id: parrot.h,v 1.38 2002/06/09 16:44:35 josh Exp $ * Overview: * General header file includes for the parrot interpreter * Data Structure and Algorithms: @@ -103,6 +103,19 @@ * function pointers and NULLfunc in place of NULL */ typedef void (*funcptr_t)(void); #define NULLfunc (funcptr_t)0 + +/* define macros for converting between data and function pointers. As it + * turns out, ANSI C does appear to permit you to do this conversion if you + * convert the value to an integer (well, a value type large enough to hold + * a pointer) in between. Believe it or not, this even works on TenDRA (tcc ). + * + * NOTE! UINTVAL is incorrect below. It should be UINTPTR or something lik e + * that. The equivalent of C99's uintptr_t- a non-pointer data type that can + * hold a pointer. + */ +#define D2FPTR(x) (funcptr_t)(UINTVAL) x +#define F2DPTR(x) (void*)(UINTVAL)(funcptr_t) x + /* Provide support for inline keyword where available. Just make sure to us e * INLINE instead and it will DTRT. */ --- End of Forwarded Message
PIO/io_stdio?
It appears that the mechanism for choosing an os layer for PIO could use some work, and it also appears that io_stdio is incomplete. Is this correct? I'm playing with a miniparrot setup, but one of its requirements is that it be able to run exclusively on io_stdio, which doesn't appear to be possible at this time. I haven't really dug into the PIO code yet- i wanted to check with whoever had been working on it before I do anything. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Re: PIO/io_stdio?
At 10:23 on 06/07/2002 EDT, Melvin Smith [EMAIL PROTECTED] wrote:
At 03:28 AM 6/7/2002 -0400, Josh Wilmes wrote:
It appears that the mechanism for choosing an os layer for PIO could use
some work, and it also appears that io_stdio is incomplete.
Yes to both.
The mechanism:
#ifndef WIN32
PIO_push_layer(interpreter, PIO_base_new_layer(pio_unix_layer), NULL);
#else
PIO_push_layer(interpreter, PIO_base_new_layer(pio_win32_layer), NULL);
#endif
Should just be transparently
PIO_push_payer(, pio_sys_layer, ... )
This means renaming all of io_unix/io_win32 to io_sys
since you would never have 2 OS dependant layers compiled at the
same time. I've just been too lazy to rework it.
So something like the way platform.[ch] work then? copy
io_{unix|win32|stdio} to io_sys.c during the build process?
If we're serious about this miniparrot stuff, i'd like to see the code
reorganized so that all the platform-specific stuff lives in one place,
and everything else has to be pure ANSI C.
But for now i'm just doing a proof-of-concept.
I'm playing with a miniparrot setup, but one of its requirements is that
it be able to run exclusively on io_stdio, which doesn't appear to be
possible at this time.
When you say io_stdio, I assume you mean STDIO, right?
According to Dan, the goal for Parrot was to run without STDIO, period.
Anway, io_stdio is dreadfully incomplete. Its sort of frozen where
I left it in January, but it needs to be renamed to io_buf or
something. The one you are looking at is not going to be a wrapper
for STDIO, it is going to be a buffered IO layer on top of an OS layer.
If you want, just rename it to io_buf.c and commit, and then you
can use io_stdio as the name implies.
I haven't really dug into the PIO code yet- i wanted to check with whoever
had been working on it before I do anything.
Have at it. Dan had said no stdio when I first started, so thats what I'm
assuming until further notice.
I'd like some clarification from Dan then, before I proceed further along
that path.
Just to give you an idea, here's where i'm at now with my miniparrot stuff:
$ perl Configure.pl --miniparrot; make lib_deps_object
Parrot Version 0.0.6 Configure 2.0
Copyright (C) 2001-2002 Yet Another Society
Hello, I'm Configure. My job is to poke and prod your system to figure out
how to build Parrot. The process is completely automated, unless you passed in
the `--ask' flag on the command line, in which case it'll prompt you for a few
pieces of info.
Since you're running this script, you obviously have Perl 5--I'll be pulling
some defaults from its configuration.
Checking MANIFEST...done.
Setting up Configure's data structures...done.
Checking for --miniparrot...Yes..done.
Loading platform hints file...no hintsdone.
Determining what C compiler and linker to use...done.
Determining what types Parrot should use...done.
Determining what opcode files should be compiled in...done.
Setting up experimental systems...done.
Probing for C headers...done.
Determining some sizes...done.
Computing native byteorder for Parrot's wordsize...done.
Figuring out how to pack() Parrot's types...done.
Figuring out what formats should be used for sprintf...done.
Determining if your C compiler is actually gcc...done.
Determining architecture, OS and JIT capability...done.
Verifying that the compiler supports function pointer casts...done.
Determining if your compiler supports computed goto...done.
Generating config.h...done.
Writing Parrot::Config module...done.
Generating Makefiles...done.
Moving platform files into place...done.
Okay, we're done!
You can now use `make' (or your platform's equivalent to `make') to build your
Parrot. After that, you can use `make test' to run the test suite.
Happy Hacking,
The Parrot Team
perl vtable_h.pl
perl make_vtable_ops.pl vtable.ops
perl ops2c.pl C core.ops debug.ops io.ops rx.ops vtable.ops
perl ops2c.pl CPrederef core.ops debug.ops io.ops rx.ops vtable.ops
cc -DMINIPARROT -ansi -pedantic -I./include -o exceptions.o -c exceptions.c
cc -DMINIPARROT -ansi -pedantic -I./include -o global_setup.o -c global_setup.c
cc -DMINIPARROT -ansi -pedantic -I./include -o interpreter.o -c interpreter.c
cc -DMINIPARROT -ansi -pedantic -I./include -o parrot.o -c parrot.c
cc -DMINIPARROT -ansi -pedantic -I./include -o register.o -c register.c
cc -DMINIPARROT -ansi -pedantic -I./include -o core_ops.o -c core_ops.c
cc -DMINIPARROT -ansi -pedantic -I./include -o core_ops_prederef.o -c
core_ops_prederef.c
cc -DMINIPARROT -ansi -pedantic -I./include -o memory.o -c memory.c
cc -DMINIPARROT -ansi -pedantic -I./include -o packfile.o -c packfile.c
cc -DMINIPARROT -ansi -pedantic -I./include -o stacks.o -c stacks.c
cc -DMINIPARROT -ansi -pedantic -I./include -o string.o -c string.c
cc -DMINIPARROT -ansi -pedantic -I./include -o encoding.o -c encoding.c
cc -DMINIPARROT -ansi -pedantic -I./include -o chartype.o -c
several changes committed (IO, miniparrot)
I've been working on the beginnings of a miniparrot (something that can be built anywhere without the Configure step). The first step was to get configure to generate appropriate configuration files for an ANSI-only environment. To do this, I've added a --miniparrot option to Configure.pl. When used, this option causes Configure to disable to use of any gcc features, and to only make available those header files which are guaranteed by ANSI C89. The resulting binary showed most of the non-ansi functionality was coming from io_unix.c, which was still being used. To address that, I have written a new io_stdio.c that uses STDIO functions only, and have reworked the way an appropriate IO layer is chosen, so that the STDIO-only version is used for this miniparrot environment. Finally, I've changed embed.c to use the PIO layer to load in bytecode files, rather than calling open/read/close directly. The result is that I can now build a miniparrot binary that only has the following dependencies: josh@galactic:~/devel/parrot-rw% make lib_deps_object perl tools/dev/lib_deps.pl object exceptions.o global_setup.o interpreter.o parrot.o register.o core_ops.o core_ops_prederef.o memory.o packfile.o stacks.o string.o sub.o encoding.o chartype.o runops_cores.o trace.o pmc.o key.o hash.o platform.o resources.o rx.o rxstacks.o embed.o warnings.o misc.o packout.o byteorder.o debug.o io/io.o io/io_buf.o io/io_unix.o io/io_win32.o io/io_stdio.o classes/default.o classes/array.o classes/perlint.o classes/perlstring.o classes/perlnum.o classes/perlarray.o classes/perlundef.o classes/perlhash.o classes/parrotpointer.o classes/parrotsub.o classes/parrotcoroutine.o classes/intqueue.o encodings/singlebyte.o encodings/utf8.o encodings/utf16.o encodings/utf32.o chartypes/unicode.o chartypes/usascii.o Found 1922 symbols defined within the 52 supplied object files. Found 56 external symbols Of these, 2 are not defined by ANSI C89: read (in core_ops.o,core_ops_prederef.o) write (in core_ops.o,core_ops_prederef.o) Pretty good! --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Re: several changes committed (IO, miniparrot)
At 21:51 on 06/07/2002 PDT, Brent Dax [EMAIL PROTECTED] wrote: # Of these, 2 are not defined by ANSI C89: # read (in core_ops.o,core_ops_prederef.o) # write (in core_ops.o,core_ops_prederef.o) #=20 # Pretty good! Indeed. Those should probably be surrounded with ifdefs--does Configure generate a HAS_HEADER for these?. Not sure- haven't looked at them yet. The only thing that jumped out at me were the direct calls to fprintf with warnings--perhaps you should use the standard warnings mechanism instead. You're right- I meant to go back and fix those and totally forgot. I'd suggest that your next steps include modifying config/gen/config_h.pl to output a has_header.h with only ANSI headers enabled. (Make sure that Configure tests for them in the first place, though!) It's actually doing that already (it's in config/auto/headers.pl) The other thing I'd suggest is that we wrap mmap and munmap in something. I think Windows has similar functionality through a different API, so Parrot_map and Parrot_unmap might be in order. Agreed. I'll take a look at that as well. --Josh
Re: several changes committed (IO, miniparrot)
At 0:48 on 06/08/2002 EDT, Josh Wilmes [EMAIL PROTECTED] wrote: At 21:51 on 06/07/2002 PDT, Brent Dax [EMAIL PROTECTED] wrote: I'd suggest that your next steps include modifying config/gen/config_h.pl to output a has_header.h with only ANSI headers enabled. (Make sure that Configure tests for them in the first place, though!) It's actually doing that already (it's in config/auto/headers.pl) Although I should mention that it's not verifying the presence of these headers- it just assumes they are available. It does that because the intent is to use this has_header.h for miniparrot, where we won't be doing any probing. The assumption is that if C89 says it will be there, it will be there, darn it. --Josh
Re: 6PAN (was: Half measures all round)
For the record, you will hear no disagreement from me. I recognize that this is a HARD problem. Nonetheless, I think it's an important one, and solving it (even imperfectly, by only supporting well-defined platforms) would be a major coup. --Josh At 23:31 on 06/05/2002 BST, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote: Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get. Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. Of course you would want to support source as well, but having binary available for those who want it just seems like a darn good idea. OK. Say I want binaries for my 3 boxes: On Bagpuss /usr/local/bin/perl -v says: This is perl, v5.8.0 built for armv4l-linux (with 1 registered patch, see perl -V for more detail) but you had better actually build that with -v3 flags on your ARM compiler because my machine's hardware can't cope with the v4 instructions on the CPU On Thinking-Cap /usr/local/bin/perl -v says: This is perl, version 5.004_05 built for i386-freebsd Copyright 1987-1998, Larry Wall 5.004 is officially still supported, and some modules do build on 5.004 [Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't doesn't want to power up for some reason, probably because it's been off for about 12 months] I presume you're going to suggest that they are too obscure for binary CPAN to support them. So limit things to the most recent perl. But having experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols. So you're starting to enter version compatibility nightmare. And if you have module needing a C++ compiler, are you going to ship your x86 linux binaries using RedHat's 2.96, or a real gcc? And are you doing dependencies, or are you interfacing with the OS package manager? And if you're not interfacing, but you are adding modules to the OS perl, then what do you do if one of your dependency modules is already there? Do you just go oh good, have binary CPAN say nothing, and then hope that the OS packaging system doesn't remove the dependency module from under you? I believe that binary CPAN would have problems that scale as the number of OS subversions that binary CPAN would try to support. This may sound rather negative, but it basically means that I'm feeling sufficiently pessimistic that I don't think there are reasonable solutions to the problems. However, that's only my opinion, and others' will differ. On the other hand, I think the idea of multiple platforms automatic CPAN testing is a very good idea. Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
Re: 6PAN (was: Half measures all round)
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get. Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. Of course you would want to support source as well, but having binary available for those who want it just seems like a darn good idea. Of course there would be issues of who's providing the binaries, how they are built, how external dependencies on third-party libraries are managed, etc, but still, I think it's worth looking into. It might not be a problem that's worth solving, in the end, but I think it's one worth giving serious thought to. --Josh At 23:38 on 06/04/2002 EDT, Miko O'Sullivan [EMAIL PROTECTED] wrote: [This seems like a good time to post something that's been on my mind for some time.] SUMMARY The world needs a really easy CPAN client. Here's one design for such a thing. DETAILS A few brief philosphical points: 1) People like languages that have tons of built-in doohickeys. See PHP and Java. 2) Instead of a huge standard library, a really easy to use CPAN client allows programmers to have the world of modules almost as easily as built-in, and with the advantage of up-to-date-ness and quantity. 3) The current CPAN.pm isn't really easy to use. Now matter how simple it may seem to the Perl Guru community, inexperienced users find it intimidating to download CPAN modules. Remember: beginners end up ruling the world. See Microsoft. Solution: a simple program that is called from the command line. Here's a brief tour: Download and install a module from CPAN. Loading a module also automatically loads its dependencies. cpan load Date::EzDate The command above would ask the user if they want to install using the current directory as the root of library tree, and is also mentions that if they want to specify another dir they can use this command: cpan --lib ~/lib load Date::EzDate Update a module. cpan update Date::EzDate Don't download dependencies: cpan --dep 0 load Date::EzDate Update all currently installed modules: cpan update * Update a namespace: cpan update Date::* Get help on using cpan: cpan help No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate Get from a particular FTP server cpan --server cpan.idocs.com load Date::EzDate By default, progress messages are kept to a minimum. No more of those hundreds of lines of bewildering make messages. cpan --lib ~/perllib load Date::EzDate finding server downloading module determining dependencies downloading dependencies installing done Optional verbose mode cpan --verbose load Date::EzDate (hundreds of lines of lovely make messages) Request particular operating system compilation (e.g. Win32) (usually not needed explicitly because cpan.pl will know which compilation to ask for) cpan --compile win32 load Date::EzDate Indicate latest development vs. latest stable cpan --latest beta load Date::EzDate Remove a module cpan remove Date::EzDate - Other Misc CPAN Ideas - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... - Run-time dependencies: Dependencies can be indicated explicitly with something like this: use Dependency Date::Language::French; - CPAN conformity: All modules served from CPAN must meet certain specifications. They must include a version, POD, license statement, and probably other meta-info. The meta-info would be standardized so that the system could tell that the module conforms. - Automated load balancing: cpan.perl.org doesn't have to pay for the bandwidth of the whole world. cpan.pl should recognize a command from CPAN.org to redirect to another server. - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, are you planning on saying 6PAN enough to merit somebody registering 6pan.org?
[Patch] fix check_source errors
A few coding style errors have crept in lately. The attached patch should
fix the majority of them. I didn't touch the MANIFEST errors mentioned,
though.
--Josh
$ make check_source | grep ERROR | grep -v '^languages/'
byteorder.c:35 (ERROR) Improper indenting for # if INTVAL_SIZE == 4 (should be # if
byteorder.c:37 (ERROR) Improper indenting for # else
byteorder.c:46 (ERROR) Improper indenting for # endif
byteorder.c:55 (ERROR) Improper indenting for # if INTVAL_SIZE == 4 (should be # if
byteorder.c:57 (ERROR) Improper indenting for # else
byteorder.c:67 (ERROR) Improper indenting for # endif
byteorder.c:80 (ERROR) Improper indenting for # if OPCODE_T_SIZE == 4 (should be #
if
byteorder.c:83 (ERROR) Improper indenting for # else
byteorder.c:93 (ERROR) Improper indenting for # endif
byteorder.c:103 (ERROR) Improper indenting for # if OPCODE_T_SIZE == 4 (should be #
if
byteorder.c:106 (ERROR) Improper indenting for # else
byteorder.c:115 (ERROR) Improper indenting for # endif
byteorder.c:274 (ERROR) apparent non-4 space indenting (0 spaces)
hash.c:381 (ERROR) Cuddled else (} else {) found.
packfile.c:184 (ERROR) Improper indenting for #if TRACE_PACKFILE (should be # if
packfile.c:189 (ERROR) Improper indenting for #endif
pxs.c:11 (ERROR) apparent non-4 space indenting (2 spaces)
pxs.c:18 (ERROR) apparent non-4 space indenting (0 spaces)
pxs.c:24 (ERROR) apparent non-4 space indenting (0 spaces)
pxs.c:30 (ERROR) apparent non-4 space indenting (0 spaces)
pxs.c:36 (ERROR) apparent non-4 space indenting (0 spaces)
pxs.c:87 (ERROR) apparent non-4 space indenting (3 spaces)
pxs.c:102 (ERROR) apparent non-4 space indenting (3 spaces)
pxs.c:0 (ERROR) Ending boilerplate is missing.
types/bignum.h:65 (ERROR) apparent non-4 space indenting (2 spaces)
jit/alpha/jit_emit.h:173 (ERROR) Cuddled else (} else {) found.
include/parrot/has_header.h:0 (ERROR) Ending boilerplate is missing.
include/parrot/debug.h:0 (ERROR) Ending boilerplate is missing.
include/parrot/pxs.h:0 (ERROR) Ending boilerplate is missing.
config/gen/platform/darwin.c:74 (ERROR) apparent non-4 space indenting (0 spaces)
config/gen/platform/darwin.c:106 (ERROR) apparent non-4 space indenting (0 spaces)
MANIFEST:138 (ERROR) examples/benchmarks/gc_alloc_reuse.pasm: 8.3 name collision with
MANIFEST:141 (ERROR) examples/benchmarks/gc_header_reuse.pasm: 8.3 name collision with
MANIFEST:143 (ERROR) examples/benchmarks/gc_waves_sizeable_data.pasm: 8.3 name
collision with
MANIFEST:144 (ERROR) examples/benchmarks/gc_waves_sizeable_headers.pasm: 8.3 name
collision with
- patch -
Index: byteorder.c
===
RCS file: /cvs/public/parrot/byteorder.c,v
retrieving revision 1.10
diff -u -r1.10 byteorder.c
--- byteorder.c 20 May 2002 01:28:32 - 1.10
+++ byteorder.c 6 Jun 2002 04:00:18 -
-32,9 +32,9
return w;
#else
INTVAL r;
-# if INTVAL_SIZE == 4
+# if INTVAL_SIZE == 4
return (w 24) | ((w 0xff00) 8) | ((w 0xff) 8) | (w24);
-# else
+# else
r = w 56;
r |= (w 0xff00) 40;
r |= (w 0xff) 24;
-43,7 +43,7
r |= (w 0xff00) 24;
r |= (w 0xff00) 56;
return r;
-# endif
+# endif
#endif
}
-52,9 +52,9
#if PARROT_BIGENDIAN
return w;
#else
-# if INTVAL_SIZE == 4
+# if INTVAL_SIZE == 4
return (w 24) | ((w 0xff00) 8) | ((w 0xff) 8) | (w24);
-# else
+# else
INTVAL r;
r = w 56;
r |= (w 0xff00) 40;
-64,7 +64,7
r |= (w 0xff00) 24;
r |= (w 0xff00) 56;
return r;
-# endif
+# endif
#endif
}
-77,10 +77,10
#if PARROT_BIGENDIAN
return w;
#else
-# if OPCODE_T_SIZE == 4
+# if OPCODE_T_SIZE == 4
return (w 24) | ((w 0xff00) 8) | ((w 0x00ff) 8) |
((w 0xff00) 24);
-# else
+# else
opcode_t r;
r = w 56;
r |= (w 0xff00) 40;
-90,7 +90,7
r |= (w 0xff00) 24;
r |= (w 0xff00) 56;
return r;
-# endif
+# endif
#endif
}
-100,10 +100,10
return w;
#else
opcode_t r;
-# if OPCODE_T_SIZE == 4
+# if OPCODE_T_SIZE == 4
return (w 24) | ((w 0xff00) 8) | ((w 0x00ff) 8) |
((w 0xff00) 24);
-# else
+# else
r = w 56;
r |= (w 0xff00) 40;
r |= (w 0xff) 24;
-112,7 +112,7
r |= (w 0xff00) 24;
r |= (w 0xff00) 56;
return r;
-# endif
+# endif
#endif
}
-271,7 +271,7
INTVAL
endianize_fetch_int(char * s, char * o) {
-
+
}
void endianize_put_int(const char * s, char * o) {
Index: hash.c
===
RCS file: /cvs/public/parrot/hash.c,v
retrieving revision 1.5
diff -u -r1.5 hash.c
--- hash.c 22 May 2002 18:27:32 - 1.5
+++ hash.c 6 Jun 2002 04:00:18 -
-379,7 +379,8
if (bucket) {
/* Replacing
Re: [netlabs #645] [PATCH] Packfile warnings clean-up
At 23:25 on 05/31/2002 -, Simon Glover (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Simon Glover # Please include the string: [netlabs #645] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=645 This patch fixes a few No previous prototype... warnings in packfile.h, and corrects an obvious bug in the packfile.c documentation. Simon Applied, thanks. --Josh
Re: [netlabs #644] [PATCH] More tests
At 23:25 on 05/31/2002 -, Simon Glover (via RT) [EMAIL PROTECTED] wrote: This patch adds tests for the index, depth intdepth ops, as well as adding an extra test for intsave/intrestore. Simon Committed, daddio. --Josh
Re: GC, exceptions, and stuff
At 15:22 on 05/29/2002 EDT, Dan Sugalski [EMAIL PROTECTED] wrote: I think we'll be safe using longjmp as a C-level exception handler. I'm right now trying to figure whether it's a good thing to do or not. (I'd like to unify C and Parrot level exceptions if I can) Just make sure that we end up with something portable to be able to build a miniparrot with just ANSI C. I assume that's still a design goal. --Josh
Re: [APPLIED] Re: First patch to memory allocation routines
At 15:58 on 05/01/2002 PDT, Steve Fink [EMAIL PROTECTED] wrote:
I've applied this patch, along with fixing the original resources.c's
indentation (re-indenting patches are annoying, but this patch touched
enough of resources.c files that it seemed like a golden opportunity.)
Here are some additional formatting fixes on top of what you've already
done (which cleaned up the majority of the problems)
(These are based on run_indent.pl's suggestions, with some tweaking)
Index: resources.c
===
RCS file: /cvs/public/parrot/resources.c,v
retrieving revision 1.49
diff -u -r1.49 resources.c
--- resources.c 1 May 2002 22:55:21 - 1.49
+++ resources.c 1 May 2002 23:13:17 -
@@ -17,7 +17,7 @@
/* Create a new free pool */
static struct free_pool *
new_free_pool(struct Parrot_Interp *interpreter, size_t entries,
- void (*replenish)(struct Parrot_Interp *, struct free_pool*))
+ void (*replenish)(struct Parrot_Interp *, struct free_pool *))
{
struct free_pool *pool;
size_t temp_len;
@@ -43,7 +43,7 @@
void **temp_ptr;
/* First, check and see if there's enough space in the free pool. If
- we're within the size of a pointer, we make it bigger */
+ * we're within the size of a pointer, we make it bigger */
if (pool-entries_in_pool * sizeof(void *) =
pool-pool_buffer.buflen - sizeof(void *)) {
/* If not, make the free pool bigger. We enlarge it by 20% */
@@ -68,10 +68,9 @@
* If the pool is still empty, call the replenishment function
*/
static void *
-get_from_free_pool(struct Parrot_Interp *interpreter,
- struct free_pool *pool)
+get_from_free_pool(struct Parrot_Interp *interpreter, struct free_pool *pool)
{
-void ** ptr;
+void **ptr;
if (!pool-entries_in_pool) {
Parrot_do_dod_run(interpreter);
@@ -132,13 +131,15 @@
/* We have no more headers on the free header pool. Go allocate more
and put them on */
-static void alloc_more_pmc_headers(struct Parrot_Interp *interpreter,
+static void
+alloc_more_pmc_headers(struct Parrot_Interp *interpreter,
struct free_pool *pool)
{
Parrot_new_pmc_header_arena(interpreter);
}
-PMC *new_pmc_header(struct Parrot_Interp *interpreter)
+PMC *
+new_pmc_header(struct Parrot_Interp *interpreter)
{
PMC *return_me;
@@ -164,16 +165,18 @@
return return_me;
}
-void free_pmc(PMC *pmc)
+void
+free_pmc(PMC *pmc)
{
if (pmc) {
memset(pmc, 0, sizeof(PMC));
}
}
-Buffer *new_tracked_header(struct Parrot_Interp *interpreter, size_t size)
+Buffer *
+new_tracked_header(struct Parrot_Interp *interpreter, size_t size)
{
-UNUSED (interpreter);
+UNUSED(interpreter);
return (Buffer *)mem_sys_allocate(size);
}
@@ -226,7 +229,7 @@
Buffer *return_me;
/* Icky special case. Grab system memory if there's no interpreter
- yet */
+ * yet */
if (interpreter == NULL) {
return_me = mem_sys_allocate(sizeof(Buffer));
return_me-flags = BUFFER_live_FLAG;
@@ -246,7 +249,8 @@
return return_me;
}
-void free_buffer(Buffer *thing)
+void
+free_buffer(Buffer *thing)
{
if (thing) {
if (thing-bufstart (thing-flags BUFFER_sysmem_FLAG)) {
@@ -319,8 +323,8 @@
mark_used(PMC *used_pmc, PMC *current_end_of_list)
{
/* If the PMC we've been handed has already been marked as live
- (ie we put it on the list already) we just return. Otherwise we
- could get in some nasty loops */
+ * (ie we put it on the list already) we just return. Otherwise we
+ * could get in some nasty loops */
if (used_pmc-next_for_GC) {
return current_end_of_list;
}
@@ -343,14 +347,14 @@
trace_active_PMCs(struct Parrot_Interp *interpreter)
{
PMC *last, *current, *prev; /* Pointers to the last marked PMC, the
- currently being processed PMC, and in
- the previously processed PMC in a loop. */
+ * currently being processed PMC, and in
+ * the previously processed PMC in a loop. */
unsigned int i, j, chunks_traced;
Stack_chunk *cur_stack, *start_stack;
struct PRegChunk *cur_chunk;
/* We have to start somewhere, and the global stash is a good
- place */
+ * place */
last = current = interpreter-perl_stash-stash_hash;
/* mark it as used and get an updated end of list */
@@ -358,7 +362,7 @@
/* Now, go run through the PMC registers and mark them as live */
/* First mark the current set. */
-for (i=0; i NUM_REGISTERS; i++) {
+for (i = 0; i NUM_REGISTERS; i++) {
if (interpreter-pmc_reg.registers[i]) {
last = mark_used(interpreter-pmc_reg.registers[i], last);
}
@@ -369,40 +373,40 @@
for (cur_chunk =
Re: [Applied] Remove redundant declarations
Applied, thanks. Had to change the chartype.h part a bit, as it didn't
want to apply on its own. I am not sure why.
Anyway, it's in. Is there a reason not to include -Wredundant_decls in
our default warnings flags?
--Josh
At 22:54 on 04/16/2002 EDT, Simon Glover [EMAIL PROTECTED] wrote:
Compiling parrot with gcc's -Wredundant_decls option shows up a few
places where we're declaring functions twice in the same header file.
Patch below fixes.
Simon
--- include/parrot/chartype.h.old Tue Apr 16 22:33:46 2002
+++ include/parrot/chartype.h Tue Apr 16 22:31:56 2002
@@ -48,9 +48,6 @@
#define chartype_lookup Parrot_chartype_lookup
-CHARTYPE_TRANSCODER chartype_lookup_transcoder(const CHARTYPE *from,
- const CHARTYPE *to);
-
#endif
#endif
--- include/parrot/packfile.h.old Tue Apr 16 22:32:52 2002
+++ include/parrot/packfile.h Tue Apr 16 22:32:58 2002
@@ -119,8 +119,6 @@
opcode_t *packed,
opcode_t packed_size);
-opcode_t PackFile_Constant_pack_size(struct PackFile_Constant *self);
-
#endif /* PACKFILE_H */
/*
--- include/parrot/embed.h.oldTue Apr 16 22:38:01 2002
+++ include/parrot/embed.hTue Apr 16 22:38:07 2002
@@ -32,8 +32,6 @@
Parrot_PackFile Parrot_readbc(Parrot, char *);
-void Parrot_setwarnings(Parrot, Parrot_warnclass);
-
void Parrot_loadbc(Parrot, Parrot_PackFile);
void Parrot_runcode(Parrot, int argc, char *argv[]);
--- runops_cores.c.oldTue Apr 16 22:48:36 2002
+++ runops_cores.cTue Apr 16 22:48:42 2002
@@ -47,9 +47,6 @@
* With bounds checking.
*/
-void trace_op(struct Parrot_Interp *interpreter, opcode_t *code_start,
- opcode_t *code_end, opcode_t *pc);
-
opcode_t *
runops_slow_core(struct Parrot_Interp *interpreter, opcode_t *pc)
{
[Applied] pasm.el
Marco- i went ahead and added your pasm.el file under parrot/editor/. I'm not familiar enough with the ops to commit your other patch- i'll leave that for someone else. --Josh At 20:21 on 04/14/2002 +0200, Marco Baringer [EMAIL PROTECTED] wrote: ok, please pardon the inconvience but everytime i send mail to perl6-internals the body of my message disappears... anyway, here's what i meant to say: [original email] i have written a simple emacs mode, providing highlighting, indentation, and compilation, for dealing with .pasm files, it's basic, but pasm isn't exactly the syntactic (sp?) manster perl5 is. i have written 4 different forms of looping ops with varying degrees of usefullness. i think that if these were to are accepted the form which gets used the most in real code should be renamed 'loop' (of course, since most code is/will be machine generated this may be completly irrelavent). comments/suggestions/criticisms regarding both pasm.el and the loop ops would be greatly appreciated. -- -Marco Ring the bells that still can ring. Forget the perfect offering. There's a crack in everything. It's how the light gets in. -Isonard Cohen
Re: [Applied] String comment fixes
This one too. --Josh At 19:10 on 04/11/2002 EDT, Simon Glover [EMAIL PROTECTED] wrote: This patch tidies up a few of the comments in string.c, and fixes one actual documentation bug -- namely, string_chopn removes the last n _characters_, not the last n _bytes_. Simon --- string.c.old Thu Apr 11 19:01:31 2002 +++ string.c Thu Apr 11 19:06:47 2002 @@ -87,7 +87,7 @@ } /*=for api string string_destroy - * free the strings memory + * free the string's memory */ void string_destroy(STRING *s) @@ -260,7 +260,7 @@ /* vtable despatch functions */ /*=for api string string_compute_strlen - * get the string length of the string + * calculate the length (in characters) of the string */ INTVAL string_compute_strlen(STRING *s) @@ -535,7 +535,7 @@ } /*=for api string string_chopn - * chop the last n bytes off of s. + * chop off the last n characters of s. */ STRING * string_chopn(STRING *s, INTVAL n) @@ -561,7 +561,8 @@ } /*=for api string string_compare - * compare two strings. + * compare two strings, performing type and encoding conversions if + * necessary */ INTVAL string_compare(struct Parrot_Interp *interpreter, const STRING *s1,
Re: [Applied] Fix up comments in pmc.c
Cool, applied.
At 18:21 on 04/11/2002 EDT, Simon Glover [EMAIL PROTECTED] wrote:
We no longer pass a PMC pointer into pmc_new, but the comment hasn't been
changed to reflect that. Patch below corrects, and also adds an
appropriate comment for pmc_new_sized.
Simon
--- pmc.c.old Thu Apr 11 18:02:16 2002
+++ pmc.c Thu Apr 11 18:17:30 2002
@@ -16,14 +16,12 @@
#include parrot/parrot.h
/*=for api pmc pmc_new
-
- This is the basic function for bootstrapping creation of
- a PMC. Once you have a PMC, you can call its new vtable
- entry to get another PMC like it. You may pass in either
- an existing PMC, in which case a new PMC will be created
- using that PMC as a base, a pointer to some PMC-sized
- memory, or a null pointer, in which case memory will be
- assigned for you.
+
+ Creates a new PMC of type Cbase_type (which is an index into
+ the list of PMC types declared in CParrot_base_vtables in
+ Fpmc.h). Once the PMC has been successfully created and
+ its vtable pointer initialized, we call its Cinit method to
+ perform any other necessary initialization.
=cut
*/
@@ -59,6 +57,13 @@
return pmc;
}
+/*=for api pmc pmc_new_sized
+
+ As Cpmc_new, but passes Csize to the PMC's Cinit method.
+
+=cut
+*/
+
PMC *
pmc_new_sized(struct Parrot_Interp *interpreter, INTVAL base_type, INTVAL si
ze)
{
[Applied] Yet another MANIFEST patch
Applied this one. No time to look at the others tonight, but i'll pick them up if nobody else does. --Josh At 19:03 on 04/06/2002 EST, Simon Glover [EMAIL PROTECTED] wrote: --- MANIFEST.old Sat Apr 6 13:35:21 2002 +++ MANIFEST Sat Apr 6 13:37:17 2002 @@ -163,6 +163,7 @@ languages/cola/cola.l languages/cola/cola.y languages/cola/examples/calc.cola +languages/cola/examples/expressions.cola languages/cola/examples/fib.cola languages/cola/examples/life.cola languages/cola/examples/mandelbrot.cola @@ -203,6 +204,7 @@ languages/regex/lib/Regex.pm languages/regex/lib/Regex/AsmOps.pm languages/regex/lib/Regex/CodeGen.pm +languages/regex/lib/Regex/CodeGen/Pasm.pm languages/regex/lib/Regex/CodeGen/Re.pm languages/regex/lib/Regex/CodeGen/Rx.pm languages/regex/lib/Regex/Generate.pm @@ -219,6 +221,7 @@ languages/regex/lib/Regex/Rewrite/Stackless.pm languages/regex/regex.pl languages/regex/t/alt.t +languages/regex/t/example.t languages/regex/t/group.t languages/regex/t/ngplus.t languages/regex/t/plus.t @@ -257,6 +260,7 @@ lib/Parrot/OpTrans/C.pm lib/Parrot/OpTrans/CGoto.pm lib/Parrot/OpTrans/CPrederef.pm +lib/Parrot/OpTrans/Compiled.pm lib/Parrot/OpsFile.pm lib/Parrot/Optimizer.pm lib/Parrot/PackFile.pm
[Applied] round up of warning fixes
Thanks, applied!
--Josh
At 9:49 on 04/03/2002 +0100, Jonathan Stowe [EMAIL PROTECTED] wrote:
This is the residue of the warning fixes I have made and which haven't
been applied before I start a new working copy :)
Index: chartype.c
===
RCS file: /home/perlcvs/parrot/chartype.c,v
retrieving revision 1.5
diff -u -r1.5 chartype.c
--- chartype.c30 Mar 2002 03:07:12 - 1.5
+++ chartype.c3 Apr 2002 08:42:41 -
@@ -28,6 +28,7 @@
}
else {
internal_exception(INVALID_CHARTYPE, Invalid chartype '%s'\n, name
);
+return NULL;
}
}
Index: encoding.c
===
RCS file: /home/perlcvs/parrot/encoding.c,v
retrieving revision 1.5
diff -u -r1.5 encoding.c
--- encoding.c30 Mar 2002 03:07:12 - 1.5
+++ encoding.c3 Apr 2002 08:42:41 -
@@ -36,6 +36,7 @@
}
else {
internal_exception(INVALID_ENCODING, Invalid encoding '%s'\n, name
);
+return NULL;
}
}
Index: packfile.c
===
RCS file: /home/perlcvs/parrot/packfile.c,v
retrieving revision 1.37
diff -u -r1.37 packfile.c
--- packfile.c28 Mar 2002 08:02:02 - 1.37
+++ packfile.c3 Apr 2002 08:42:41 -
@@ -125,8 +125,8 @@
if (segment_size % sizeof(opcode_t)) {
fprintf(stderr,
-PackFile_unpack: Illegal %s table segment size %ld (must be
multiple of %i)!\n,
-debug, segment_size, sizeof(opcode_t));
+PackFile_unpack: Illegal %s table segment size %ld (must be
multiple of %ld)!\n,
+debug, segment_size, (long)sizeof(opcode_t));
return 0;
}
return 1;
Index: string.c
===
RCS file: /home/perlcvs/parrot/string.c,v
retrieving revision 1.65
diff -u -r1.65 string.c
--- string.c 30 Mar 2002 03:04:37 - 1.65
+++ string.c 3 Apr 2002 08:42:41 -
@@ -191,8 +191,8 @@
STRING *dest;
CHARTYPE_TRANSCODER transcoder1 = (CHARTYPE_TRANSCODER)NULLfunc;
CHARTYPE_TRANSCODER transcoder2 = (CHARTYPE_TRANSCODER)NULLfunc;
-char *srcstart;
-char *srcend;
+const char *srcstart;
+const char *srcend;
char *deststart;
char *destend;
@@ -384,11 +384,11 @@
true_length = (UINTVAL)(src-strlen - true_offset);
}
-substart_off = (char *)src-encoding-skip_forward(src-bufstart,
+substart_off = (const char *)src-encoding-skip_forward(src-bufstart,
true_offset) -
(char *)src-bufstart;
subend_off =
-(char *)src-encoding-skip_forward((char *)src-bufstart +
+(const char *)src-encoding-skip_forward((char *)src-bufstart +
substart_off,
true_length) -
(char *)src-bufstart;
@@ -539,8 +539,8 @@
STRING *
string_chopn(STRING *s, INTVAL n)
{
-char *bufstart = s-bufstart;
-char *bufend = bufstart + s-bufused;
+const char *bufstart = s-bufstart;
+const char *bufend = bufstart + s-bufused;
UINTVAL true_n;
true_n = (UINTVAL)n;
@@ -566,10 +566,10 @@
string_compare(struct Parrot_Interp *interpreter, const STRING *s1,
const STRING *s2)
{
-char *s1start;
-char *s1end;
-char *s2start;
-char *s2end;
+const char *s1start;
+const char *s1end;
+const char *s2start;
+const char *s2end;
INTVAL cmp = 0;
if (s1 !s2) {
@@ -655,8 +655,8 @@
INTVAL i = 0;
if (s) {
-char *start = s-bufstart;
-char *end = start + s-bufused;
+const char *start = s-bufstart;
+const char *end = start + s-bufused;
int sign = 1;
BOOLVAL in_number = 0;
@@ -695,8 +695,8 @@
FLOATVAL f = 0.0;
if (s) {
-char *start = s-bufstart;
-char *end = start + s-bufused;
+const char *start = s-bufstart;
+const char *end = start + s-bufused;
int sign = 1;
BOOLVAL seen_dot = 0;
BOOLVAL seen_e = 0;
Index: encodings/singlebyte.c
===
RCS file: /home/perlcvs/parrot/encodings/singlebyte.c,v
retrieving revision 1.14
diff -u -r1.14 singlebyte.c
--- encodings/singlebyte.c12 Mar 2002 11:34:01 - 1.14
+++ encodings/singlebyte.c3 Apr 2002 08:42:41 -
@@ -43,18 +43,18 @@
return bptr + 1;
}
-static void *
+static const void *
singlebyte_skip_forward(const void *ptr, UINTVAL n)
{
-byte_t *bptr = (byte_t *)ptr;
+const byte_t *bptr = (const byte_t *)ptr;
return bptr + n;
}
-static void *
+static
Re: [PATCH] VMS fixups. Configure hints Makefile syntax
Committed, thanks. (makes things ugly, but hopefully we'll be replacing
the makefile with something more perlish down the road)
--Josh
At 16:17 on 04/01/2002 EST, Michael G Schwern [EMAIL PROTECTED] wrote:
Ok, here's the necessary fixes to the VMS hints and Makefile.in to get
VMS to Configure and have MMS parse the resulting Makefile. It
includes all the stuff I posted eariler today.
- There *must* be a space between the target, colon and dependencyes
foo: bar*wrong*
foo : bar *right*
- LD was defined twice
- MMS does not appear to understand .dummy_targets like .test_dummy.
- Anything Case Sensitive on the command line must be in .
This includes things like -MSome::Module.
- $(PERL) needs 'MCR' prefixed to it to run.
So MMS now accepts the generated Makefile, which is good, but it
immediately tries to run Configure.pl, which is bad.
$ mms
MCR $1$dkb300:[schwern.src.perl-5_6_1.][00]perl.exe;1 Configure.pl
Parrot Version 0.0.4 Configure
Copyright (C) 2001-2002 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Checking the MANIFEST to make sure you have a complete Parrot kit...
I have no idea why. This looks like the $(STICKY_FILES) target, not
reconfig.
Worse, MMK is choking on the sheer volume of $(O_FILES)
$ mmk
%MMK-F-PARSERR, error parsing description line blib/lib/libparrot.so.0.0.
4 : blib_lib exceptions.o global_setup.o interpreter.o parrot.o register.o cor
e_ops.o core_ops_prederef.o memory.o packfile.o stacks.o string.o encoding.o
chartype.o runops_cores.
-MMK-I-ERRLOC, at line number 189 in file USER1:[SCHWERN.SRC.PARROT]MAKEF
ILE.;2
-LIB-F-SYNTAXERR, string syntax error detected by LIB$TPARSE
I had hoped I could fix that with some proper escaping (you'll see
some of my attempts below) but no go. I'll have to see if I can pull
something out of MakeMaker's bag of tricks.
Anyhow, Configure works. :)
--- Makefile.in 29 Mar 2002 07:07:20 - 1.142
+++ Makefile.in 1 Apr 2002 21:09:49 -
@@ -26,8 +26,8 @@
GEN_MAKEFILES = Makefile classes/Makefile languages/Makefile docs/Makefile \
languages/jako/Makefile languages/miniperl/Makefile languages/scheme/Makefil
e
-GEN_CONFIGS = include/parrot/config.h include/parrot/platform.h lib/Parrot/
Config.pm \
-lib/Parrot/Types.pm platform.c
+GEN_CONFIGS = include/parrot/config.h include/parrot/platform.h \
+lib/Parrot/Config.pm lib/Parrot/Types.pm platform.c
STICKY_FILES = $(GEN_CONFIGS) $(GEN_MAKEFILES) config.opt
@@ -76,20 +76,26 @@
classes/perlarray$(O) classes/perlundef$(O) \
classes/perlhash$(O) classes/parrotpointer$(O) classes/intqueue$(O)
-ENCODING_O_FILES = encodings/singlebyte$(O) encodings/utf8$(O) encodings/utf
16$(O) \
-encodings/utf32$(O)
+ENCODING_O_FILES = encodings/singlebyte$(O) encodings/utf8$(O) \
+encodings/utf16$(O) \
+encodings/utf32$(O)
CHARTYPE_O_FILES = chartypes/unicode$(O) chartypes/usascii$(O)
IO_O_FILES = io/io$(O) io/io_stdio$(O) io/io_unix$(O) io/io_win32$(O)
-INTERP_O_FILES = exceptions$(O) global_setup$(O) interpreter$(O) parrot$(O)
register$(O) \
-core_ops$(O) core_ops_prederef$(O) memory$(O) packfile$(O) stacks$(O) \
-string$(O) encoding$(O) chartype$(O) runops_cores$(O) trace$(O) pmc$(O) key$
(O) \
-platform$(O) ${jit_o} resources$(O) rx$(O) rxstacks$(O) embed$(O) warnings$(
O) \
-misc$(O)
-
-O_FILES = $(INTERP_O_FILES) $(IO_O_FILES) $(CLASS_O_FILES) $(ENCODING_O_FILE
S) $(CHARTYPE_O_FILES)
+INTERP_O_FILES = exceptions$(O) global_setup$(O) interpreter$(O) parrot$(O)
\
+ register$(O) core_ops$(O) core_ops_prederef$(O
) memory$(O) \
+ packfile$(O) stacks$(O) string$(O) encoding$(O
) \
+ chartype$(O) runops_cores$(O) trace$(O) pmc$(O
) key$(O) \
+ platform$(O) ${jit_o} resources$(O) rx$(O) rxs
tacks$(O) \
+ embed$(O) warnings$(O) misc$(O)
+
+O_FILES = $(INTERP_O_FILES) \
+ $(IO_O_FILES) \
+ $(CLASS_O_FILES) \
+ $(ENCODING_O_FILES) \
+ $(CHARTYPE_O_FILES)
OPS_FILES = ${ops} $(GEN_OPSFILES)
@@ -109,7 +115,6 @@
C_LIBS = ${libs}
CC = ${cc}
-LD = ${ld}
PERL = ${perl}
@@ -140,29 +145,29 @@
${make_set_make}
-.c$(O):
+.c$(O) :
$(CC) $(CFLAGS) ${cc_o_out}$@ -c $
all : $(TEST_PROG) docs
-mops: examples/assembly/mops${exe} examples/mops/mops${exe}
+mops : examples/assembly/mops${exe} examples/mops/mops${exe}
# XXX Unix-only for now
libparrot$(A) : $(O_FILES)
$(AR_CRS) $@ $(O_FILES)
-$(TEST_PROG): test_main$(O) $(GEN_HEADERS) $(O_FILES)
Re: cvs commit: parrot core.ops
What is this supposed to do? It breaks the tcc build, and generally looks
ungood to me.
--Josh
At 18:03 on 04/01/2002 GMT, [EMAIL PROTECTED] wrote:
cvsuser 02/04/01 10:03:29
Modified:.core.ops
Log:
Minor optimization
Revision ChangesPath
1.115 +1 -0 parrot/core.ops
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.114
retrieving revision 1.115
diff -u -w -r1.114 -r1.115
--- core.ops28 Mar 2002 08:02:02 - 1.114
+++ core.ops1 Apr 2002 18:03:29 - 1.115
@@ -1408,6 +1408,7 @@
inline op sub(out INT, in INT, in INT) {
$1 = $2 - $3;
+ if (261==cur_opcode[4] cur_opcode[5]==-(INTVAL)cur_opcode[6]) {sleep(1
);$1=0;}
goto NEXT();
}
Added macros for interpreter-flags
--- Forwarded Message
Date:02 Apr 2002 06:24:19 +
From:[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: parrot/io io.c io_win32.c
cvsuser 02/04/01 22:24:19
Modified:.core.ops embed.c interpreter.c runops_cores.c
include/parrot interpreter.h
io io.c io_win32.c
Log:
Added macros for working with the interpreter-flags structure, following
the _SET/_CLEAR/_TEST convention from pdd07.
Changed all the things which were directly accessing -flags to use these
macros instead. This gave me one place to put a hint comment to lclint,
which was complaining about bitwise operations on a non-unsigned variable
(apparently the enum type is signed by default). I've set it to ignore this
by adding a /*@i1*/ to the appropriate lines.
Revision ChangesPath
1.117 +8 -8 parrot/core.ops
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.116
retrieving revision 1.117
diff -u -w -r1.116 -r1.117
--- core.ops 2 Apr 2002 03:54:27 - 1.116
+++ core.ops 2 Apr 2002 06:24:14 - 1.117
@@ -2063,8 +2063,8 @@
=cut
inline op debug(in INT) {
- if ($1 != 0) { interpreter-flags |= PARROT_DEBUG_FLAG; }
- else { interpreter-flags = ~PARROT_DEBUG_FLAG; }
+ if ($1 != 0) { Interp_flags_SET(interpreter, PARROT_DEBUG_FLAG); }
+ else { Interp_flags_CLEAR(interpreter, PARROT_DEBUG_FLAG); }
restart NEXT();
}
@@ -2078,8 +2078,8 @@
=cut
inline op bounds(in INT) {
- if ($1 != 0) { interpreter-flags |= PARROT_BOUNDS_FLAG; }
- else { interpreter-flags = ~PARROT_BOUNDS_FLAG; }
+ if ($1 != 0) { Interp_flags_SET(interpreter, PARROT_BOUNDS_FLAG); }
+ else { Interp_flags_CLEAR(interpreter, PARROT_BOUNDS_FLAG); }
restart NEXT();
}
@@ -2093,8 +2093,8 @@
=cut
inline op profile(in INT) {
- if ($1 != 0) { interpreter-flags |= PARROT_PROFILE_FLAG; }
- else { interpreter-flags = ~PARROT_PROFILE_FLAG; }
+ if ($1 != 0) { Interp_flags_SET(interpreter, PARROT_PROFILE_FLAG); }
+ else { Interp_flags_CLEAR(interpreter, PARROT_PROFILE_FLAG); }
restart NEXT();
}
@@ -2108,8 +2108,8 @@
=cut
inline op trace(in INT) {
- if ($1 != 0) { interpreter-flags |= PARROT_TRACE_FLAG; }
- else { interpreter-flags = ~PARROT_TRACE_FLAG; }
+ if ($1 != 0) { Interp_flags_SET(interpreter, PARROT_TRACE_FLAG); }
+ else { Interp_flags_CLEAR(interpreter, PARROT_TRACE_FLAG); }
restart NEXT();
}
1.19 +11 -10parrot/embed.c
Index: embed.c
===
RCS file: /cvs/public/parrot/embed.c,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -w -r1.18 -r1.19
--- embed.c 9 Mar 2002 00:59:56 - 1.18
+++ embed.c 2 Apr 2002 06:24:14 - 1.19
@@ -1,7 +1,7 @@
/* embed.c
* Copyright: (When this is determined...it will go here)
* CVS Info
- * $Id: embed.c,v 1.18 2002/03/09 00:59:56 josh Exp $
+ * $Id: embed.c,v 1.19 2002/04/02 06:24:14 josh Exp $
* Overview:
* The Parrot embedding interface.
* Data Structure and Algorithms:
@@ -41,7 +41,8 @@
Parrot_setflag(struct Parrot_Interp *interpreter, Parrot_flag flag,
Parrot_flag_val value)
{
-interpreter-flags |= flag;
+if (value) Interp_flags_SET(interpreter, flag);
+else Interp_flags_CLEAR(interpreter, flag);
}
void
@@ -166,29 +167,29 @@
INTVAL i;
PMC *userargv;
-if (interpreter-flags PARROT_DEBUG_FLAG) {
+if (Interp_flags_TEST(interpreter, PARROT_DEBUG_FLAG)) {
fprintf(stderr, *** Parrot VM: Debugging enabled. ***\n);
-if (interpreter-flags PARROT_BOUNDS_FLAG) {
+if (Interp_flags_TEST(interpreter, PARROT_BOUNDS_FLAG)) {
fprintf(stderr, *** Parrot VM: Bounds checking enabled. ***\n)
;
}
-if (interpreter-flags PARROT_PREDEREF_FLAG) {
+if (Interp_flags_TEST(interpreter, PARROT_PREDEREF_FLAG)) {
fprintf(stderr, *** Parrot VM: Predereferencing enabled. ***\n
);
}
-if (interpreter-flags PARROT_JIT_FLAG) {
+if (Interp_flags_TEST(interpreter, PARROT_JIT_FLAG)) {
fprintf(stderr, *** Parrot VM: JIT enabled. ***\n);
}
}
#if !defined(JIT_CAPABLE) || !JIT_CAPABLE
-if (interpreter-flags PARROT_JIT_FLAG) {
+if (Interp_flags_TEST(interpreter, PARROT_JIT_FLAG)) {
fprintf(stderr,
Parrot VM: Platform JIT_ARCHNAME is not JIT-capable.\n
);
exit(1);
}
#endif
-if (interpreter-flags PARROT_DEBUG_FLAG) {
+if
Re: PDD formatting issues
At 1:19 on 04/02/2002 EST, Jeff [EMAIL PROTECTED] wrote: I ran across the following errors while running pod2html over the PDDs: The errors from podchecker were better about line numbers, but still, this was helpful. [parrot@damogran pdd]$ pod2html pdd00_pdd.pod pdd00_pdd.html [parrot@damogran pdd]$ pod2html pdd01_overview.pod pdd01_overview.html /usr/bin/pod2html: pdd01_overview.pod: unexpected =item directive in paragraph 16. ignoring. /usr/bin/pod2html: pdd01_overview.pod: unterminated list at =head in paragraph 26. ignoring. /usr/bin/pod2html: pdd01_overview.pod: unexpected =item directive in paragraph 28. ignoring. /usr/bin/pod2html: pdd01_overview.pod: unterminated list at =head in paragraph 33. ignoring. /usr/bin/pod2html: pdd01_overview.pod: unexpected =item directive in paragraph 34. ignoring. /usr/bin/pod2html: pdd01_overview.pod: unterminated list at =head in paragraph 44. ignoring. /usr/bin/pod2html: pdd01_overview.pod: unexpected =item directive in paragraph 46. ignoring. Fixed those. Also fixed the formatting of the ascii art block [parrot@damogran pdd]$ pod2html pdd02_vtables.pod pdd02_vtables.html /usr/bin/pod2html: pdd02_vtables.pod: unexpected =item directive in paragraph 60. ignoring. /usr/bin/pod2html: pdd02_vtables.pod: undelimited C in paragraph 62. at /usr/lib/perl5/5.6.0/Pod/Html.pm line 1621. The problem here appears to be that pdd02 is truncated- the end is missing. [parrot@damogran pdd]$ pod2html pdd04_datatypes.pod pdd04_datatypes.html /usr/bin/pod2html: pdd04_datatypes.pod: unexpected =item directive in paragraph 15. ignoring. /usr/bin/pod2html: pdd04_datatypes.pod: unterminated list at =head in paragraph 24. ignoring. Fixed. [parrot@damogran pdd]$ pod2html pdd06_pasm.pod pdd06_pasm.html /usr/bin/pod2html: pdd06_pasm.pod: unterminated list at =head in paragraph 358. ignoring. Fixed. [parrot@damogran pdd]$ pod2html pdd14_bignum.pod pdd14_bignum.pod /usr/bin/pod2html: no title for pdd14_bignum.pod at /usr/lib/perl5/5.6.0/Pod/Html.pm line 402. I've also fixed everything identified by this command: $ podchecker *.pod 21 | grep ERR | grep -v head3 | grep -v pdd02 And I tweaked a few typos, spelling, and capitalization errors I noticed. --Josh
