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: [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: 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 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: 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: 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: cvs commit: parrot/examples/io http.imc
Very cute! However, i'm curious about the choice of interface. Having individual ops for something like a socket API seems rather peculiar to me. Why do we not have an object oriented interface on a socket class? (ditto for non-trivial file IO) --Josh At 6:45 on 10/30/2003 GMT, Melvin Smith [EMAIL PROTECTED] wrote: cvsuser 03/10/29 22:45:05 Added: examples/io http.imc Log: Sample to grab a home page through HTTP. Revision ChangesPath 1.1 parrot/examples/io/http.imc Index: http.imc === # http client, connects to WWW port and grabs a page. # Be sure to set PARROT_NET_DEVEL to 1 in io/io_private.h # and rebuld Parrot or the network layer won't exist .sub _main .local pmc sock .local string address .local string buf .local int ret .local int len print Creating socket.\n # create the socket handle socket sock, 2, 1, 0 unless sock goto ERR # Pack a sockaddr_in structure with IP and port #sockaddr address, 80, 129.42.18.99 sockaddr address, 80, www.ibm.com print Connecting to http://www.parrotcode.org:80\n; connect ret, sock, address print connect returned print ret print \n send ret, sock, GET /us/ HTTP/1.0\nUser-agent: Parrot\n\n poll ret, sock, 1, 5, 0 MORE: recv ret, sock, buf if ret 0 goto END print buf goto MORE ERR: print Socket error\n end END: close sock end .end
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: [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: [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
cvs commit: parrot chartype.c datatypes.c disassemble.c dod.c encoding.c global (fwd)
FYI- I just re-indented a bunch of code, using the tools/dev/run_indent.pl
script.
--Josh
--- Forwarded Message
Date:02 Nov 2002 14:57:48 +
From:[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: parrot chartype.c datatypes.c disassemble.c dod.c encoding
.c global_setup.c hash.c jit.c key.c method_util.c misc.c packdump.c
packout.c pdb.c pdump.c pmc.c pxs.c register.c res_lea.c resources.c
runops_cores.c rx.c rxstacks.c spf_render.c spf_vtable.c stacks.c str
ing.c sub.c warnings.c
cvsuser 02/11/02 06:57:48
Modified:.chartype.c datatypes.c disassemble.c dod.c
encoding.c global_setup.c hash.c jit.c key.c
method_util.c misc.c packdump.c packout.c pdb.c
pdump.c pmc.c pxs.c register.c res_lea.c
resources.c runops_cores.c rx.c rxstacks.c
spf_render.c spf_vtable.c stacks.c string.c sub.c
warnings.c
Log:
large-scale reindenting (run_indent.pl)
Revision ChangesPath
1.8 +2 -2 parrot/chartype.c
Index: chartype.c
===
RCS file: /cvs/public/parrot/chartype.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -w -r1.7 -r1.8
--- chartype.c18 Jul 2002 04:29:39 - 1.7
+++ chartype.c2 Nov 2002 14:57:47 - 1.8
@@ -1,7 +1,7 @@
/* chartype.c
* Copyright: (When this is determined...it will go here)
* CVS Info
- * $Id: chartype.c,v 1.7 2002/07/18 04:29:39 mongo Exp $
+ * $Id: chartype.c,v 1.8 2002/11/02 14:57:47 josh Exp $
* Overview:
* This defines the string character type subsystem
* Data Structure and Algorithms:
1.3 +7 -7 parrot/datatypes.c
Index: datatypes.c
===
RCS file: /cvs/public/parrot/datatypes.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -w -r1.2 -r1.3
--- datatypes.c 28 Oct 2002 13:58:36 - 1.2
+++ datatypes.c 2 Nov 2002 14:57:47 - 1.3
@@ -3,7 +3,7 @@
* Copyright: (c) 2002 Leopold Toetsch [EMAIL PROTECTED]
* License: Artistic/GPL, see README and LICENSES for details
* CVS Info
- * $Id: datatypes.c,v 1.2 2002/10/28 13:58:36 leo Exp $
+ * $Id: datatypes.c,v 1.3 2002/11/02 14:57:47 josh Exp $
* Overview:
* Parrot and native data types functions.
*/
1.4 +2 -2 parrot/disassemble.c
Index: disassemble.c
===
RCS file: /cvs/public/parrot/disassemble.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -w -r1.3 -r1.4
--- disassemble.c 17 Aug 2002 01:11:08 - 1.3
+++ disassemble.c 2 Nov 2002 14:57:47 - 1.4
@@ -2,7 +2,7 @@
* disassemble.c
*
* CVS Info
- *$Id: disassemble.c,v 1.3 2002/08/17 01:11:08 sfink Exp $
+ *$Id: disassemble.c,v 1.4 2002/11/02 14:57:47 josh Exp $
* Overview:
*Parrot disassembler
* History:
1.26 +69 -72parrot/dod.c
Index: dod.c
===
RCS file: /cvs/public/parrot/dod.c,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -w -r1.25 -r1.26
--- dod.c 28 Oct 2002 13:58:04 - 1.25
+++ dod.c 2 Nov 2002 14:57:47 - 1.26
@@ -1,7 +1,7 @@
/* dod.c
* Copyright: (When this is determined...it will go here)
* CVS Info
- * $Id: dod.c,v 1.25 2002/10/28 13:58:04 leo Exp $
+ * $Id: dod.c,v 1.26 2002/11/02 14:57:47 josh Exp $
* Overview:
* Handles dead object destruction of the various headers
* Data Structure and Algorithms:
@@ -224,7 +224,8 @@
* assumption, but it'll do for now */
for (i = 0; i NUM_REGISTERS; i++) {
Buffer* reg = (Buffer *) interpreter-ctx.string_reg.registers[i];
-if (reg) buffer_lives(interpreter, reg);
+if (reg)
+buffer_lives(interpreter, reg);
}
/* The interpreter has a few strings of its own */
@@ -243,7 +244,8 @@
for (j = 0; j cur_chunk-used; j++) {
for (i = 0; i NUM_REGISTERS; i++) {
Buffer* reg = (Buffer *) cur_chunk-SReg[j].registers[i];
-if (reg) buffer_lives(interpreter, reg);
+if (reg)
+buffer_lives(interpreter, reg);
}
}
}
@@ -287,8 +289,7 @@
/* Run through all the buffer header pools and mark */
for (cur_arena = interpreter-arena_base-pmc_pool-last_Arena;
- NULL != cur_arena;
- cur_arena = cur_arena-prev) {
+ NULL != cur_arena; cur_arena =
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]
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
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
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
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
[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] 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
[Applied] Re: GC Torture Torture Testing
Applied :)
As far as a tinderbox-specific target, i'm all for it. I was thinking that
it might be better to have it be a perl script, since we could then have it
take care of doing the clean and rebuild the makefile appropriately.
I can take a stab at it tomorrow, if nobody else does.
--Josh
At 7:44 on 03/31/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote:
I'm sorry, this new weapon is going to give a quick advantage to the fools
side, but luckily, should help the fool-proofers in the long run.
Below patch should be safe to apply, as it does nothing. Turn on GC_DEBUG
if you want to see the hell that ensues. I'm working on a patch to fix the
issues that this causes, but am posting this now so that it can be applied
separately (or should it go as one big lump?)
On a related note, is it possible to make a 'make tinder' and 'make
tindertest' ? These would have things like GC_DEBUG turned on, which makes
Parrot run much slower, but is also more likely to expose problems in
Parrot. Is this a good idea, or would the possibility for divergance
between regular parrot and tinderbox parrot be too great? I'm not much of
a makefile hacker, so it'd be nice if someone else wanted to do this.
Mike Lambert
Index: resources.c
===
RCS file: /cvs/public/parrot/resources.c,v
retrieving revision 1.37
diff -u -r1.37 resources.c
--- resources.c 30 Mar 2002 05:57:32 - 1.37
+++ resources.c 31 Mar 2002 12:32:09 -
@@ -35,6 +35,9 @@
pool-pool_buffer.buflen = (UINTVAL)(pool-pool_buffer.buflen * 1.2);
}
+#ifdef GC_DEBUG
+Parrot_go_collect(interpreter);
+#endif
/* Okay, so there's space. Add the header on */
((PMC *)to_add)-flags = PMC_on_free_list_FLAG;
@@ -119,6 +122,11 @@
if (!interpreter-arena_base-pmc_pool-entries_in_pool) {
alloc_more_pmc_headers(interpreter);
}
+#ifdef GC_DEBUG
+ else {
+Parrot_do_dod_run(interpreter);
+ }
+#endif
{
/* A stupid temp variable. Our pointer into the pool */
@@ -221,6 +229,11 @@
if (!interpreter-arena_base-buffer_header_pool-entries_in_pool) {
alloc_more_buffer_headers(interpreter);
}
+#ifdef GC_DEBUG
+ else {
+Parrot_do_dod_run(interpreter);
+ }
+#endif
/* Okay, we do this the long, drawn-out, hard way. Otherwise I get
really confused and things crash. This, generally, is a Bad
@@ -280,6 +293,9 @@
pool-pool_buffer.buflen = (UINTVAL)(pool-pool_buffer.buflen * 1.2);
}
+#ifdef GC_DEBUG
+ Parrot_go_collect(interpreter);
+#endif
/* Okay, so there's space. Add the header on */
((Buffer *)to_add)-flags = BUFFER_on_free_list_FLAG;
@@ -635,6 +651,11 @@
if (!interpreter-arena_base-string_header_pool-entries_in_pool) {
alloc_more_string_headers(interpreter);
}
+#ifdef GC_DEBUG
+ else {
+Parrot_do_dod_run(interpreter);
+ }
+#endif
/* Okay, we do this the long, drawn-out, hard way. Otherwise I get
really confused and things crash. This, generally, is a Bad
@@ -841,6 +862,9 @@
if (NULL == interpreter) {
return mem_sys_allocate(size);
}
+#ifdef GC_DEBUG
+ Parrot_go_collect(interpreter);
+#endif
/* Make sure we round up to a multiple of 16 */
size += 16;
Re: [preliminary PATCH] Parrot C Compiler Wrapper
I've been thinking along these lines, but I'd decided on a different
approach. I think that it's better to keep the magic to a minimum.
Rather than relying on extensions, I was thinking about having a different
wrapper for each task:
- lib.pl: build static library from object files
example:
lib.pl --out=libfoo.a foo.o bar.o
- shlib.pl: build dynamic library from object files and libraries
example:
shlib.pl --out=libfoo.so.1.1 --soname=libfoo.so.1 -Llib -llib foo.o bar.o
- compile.pl: build .o file from .c file
example:
compile.pl --out=foo.o -DA=B -UC foo.c
- link.pl: build executable from .o files and libraries
example:
link.pl --out=foo -Llib -llib foo.o bar.o
These wrappers would add compiler-specific flags only, and would accept
compiler-neutral options only. We'd not want to pass through arbitrary
command line arguments to the underlying compiler, as that is bound to
break somewhere. So IMHO the wrapper needs to have well-defined
arguments that it accepts, so that it can rewrite them as needed for weird
platforms. In the examples above, I used some familiar flags (-D, -L,
-l), but I still would have the wrapper intercept and potentially rewrite
them.
Note that the wrappers would always add standard flags which control
compiler behavior (for example warnings for gcc), but would NOT add things
like extra libraries to link in or extra defines for compilation. Those
should be passed on the command line for flexibility. That is, we
shouldn't blindly tack on ccflags or ldflags in the wrappers.
--Josh
At 2:12 on 03/30/2002 PST, Brent Dax [EMAIL PROTECTED] wrote:
This patch adds a new utility to Parrot and modifies Makefile.in to use
it. The utility is for wrapping C compilers and other tools we use, so
we can avoid putting the logic in the Makefile and can potentially use
totally different commands on different platforms.
The patch is by no means ready to be applied to the source tree--it
doesn't touch the shared lib stuff, an important test needs to be added
to Configure, and I haven't even tried it on a Unix. The ability to
create libraries, both static and dynamic, is missing. But you should
be able to build your basic Parrot with this.
If you have a Unix box and ten spare minutes, please apply this to a
fresh checkout of Parrot, run 'make test', and tell me how well it
works.
As for the tool itself:
pccw.pl is a small script that implements a wrapper around several
tools. You use it like this:
perl pccw.pl [--args=(arguments)] (destination file) (source files)
pccw.pl examines the extension of the destination file and uses that to
pick what to do. If the extension is '.c', then it examines the source
files and runs either ops2c or pmc2c as appropriate; otherwise it runs
the appropriate compiler or linker incantations. The --args argument is
used to pass additional flags to the tool.
Patch is attached. Share and enjoy.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: Unicode thoughts...
Someone said that ICU requires a C++ compiler. That's concerning to me, as is the issue of how we bootstrap our build process. We were planning on a platform-neutral miniparrot, and IMHO that can't include ICU (as i'm sure it's not going to be written in pure ansi C) --Josh At 8:45 on 03/30/2002 EST, Dan Sugalski [EMAIL PROTECTED] wrote: At 4:32 PM -0800 3/25/02, Brent Dax wrote: I *really* strongly suggest we include ICU in the distribution. I recently had to turn off mod_ssl in the Apache 2 distro because I couldn't get OpenSSL downloaded and configured. FWIW, ICU in the distribution is a given if we use it. Parrot will require a C compiler and link tools (maybe make, but maybe not) to build on a target platform and nothing else. If we rely on ICU we must ship with it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Misc portability cleanups
You may be interested in the lib_deps target.
--Josh
At 0:49 on 03/31/2002 EST, Melvin Smith [EMAIL PROTECTED] wrote:
I did some browsing of the code for potential problems in compiling
for embedded platforms and/or general porting and here are some of the
things I found.
1- assert.h and use of assert()
assert is easy enough to implement we need to do this and not depend
on its existence on the target because its not guaranteed.
2- errno.h same thing. Any use of errno is typically a system call, so it
should
be wrapped in a platform generic way. On Win32 and WinCE we use
GetLastError(), on UNIX and many others we can use errno.
3- Use of stat and statbuf. embed.c needs to be redone without it, period.
We should go ahead and call the PIO routines instead, and add to PIO
as needed.
We can implement a generic stat routine.
4- Configure.pl needs to prompt for targetting another environment and
have some specific hints file for each targettable environment.
For WinCE stuff it might be worth querying ENV{} for stuff like CC,
TARGETCPU,
PLATFORM, OSVERSION.
5- Other misc includes that should be wrapped in ifdefs are:
sys/types.h, sys/stat.h, fcntl.h (btw parrot.h includes fcntl.h twice,
once
inside an ifdef and then by default).
6- Need to check for definition of size_t and generate one if needed.
Thats enough for now; baby steps. :)
-Melvin
[Applied] Bye, Simon.
Applied, with slight tweaking to make sure we keep simon in there :) --Josh At 23:29 on 03/28/2002 EST, Will Coleda [EMAIL PROTECTED] wrote: --B99DD6E33AE5206FD2C4A8AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I believe this is correct... $ diff -u parrot/docs/parrot.pod parrot-coke/docs/parrot.pod --- parrot/docs/parrot.pod Wed Mar 13 13:02:25 2002 +++ parrot-coke/docs/parrot.pod Thu Mar 28 23:27:17 2002 @@ -87,8 +87,8 @@ Parrot is developed and maintained by the members of the C[EMAIL PROTECTED] mailing list. Dan Sugalski -(C[EMAIL PROTECTED]) is the chief architect, and Simon Cozens -(C[EMAIL PROTECTED]) is the current release manager. +(C[EMAIL PROTECTED]) is the chief architect, and Jeff Goff +(C[EMAIL PROTECTED]) is the current release manager. =head2 Web pages --B99DD6E33AE5206FD2C4A8AF--
Re: [PATCH] stacks.c
It won't go in cleanly any more:
patching file stacks.c
Hunk #1 FAILED at 108.
Hunk #2 FAILED at 153.
Hunk #3 succeeded at 227 (offset 46 lines).
Hunk #4 succeeded at 243 with fuzz 1 (offset 46 lines).
2 out of 4 hunks FAILED -- saving rejects to file stacks.c.rej
If you can submit a patch against the current code, i'll apply it as long
as it doesn't break anything and you think it's a good thing :)
--Josh
At 18:30 on 03/29/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote:
The following was applied by Dan, but from what I can tell, seems to have
become unapplied since.
Mike Lambert
Bryan C. Warnock wrote:
Date: Fri, 22 Mar 2002 01:47:02 -0500
From: Bryan C. Warnock [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [PATCH] stacks.c
Defer allocation as long as possible. Make logic parallel.
Index: stacks.c
===
RCS file: /home/perlcvs/parrot/stacks.c,v
retrieving revision 1.23
diff -u -r1.23 stacks.c
--- stacks.c8 Mar 2002 03:04:03 - 1.23
+++ stacks.c22 Mar 2002 06:45:39 -
@@ -108,7 +108,21 @@
void *thing, INTVAL type, stack_cleanup_method_t cleanup)
{
Stack_Chunk chunk = stack-prev;
-Stack_Entry entry = chunk-entry[chunk-used];
+Stack_Entry entry;
+
+/* Do we need a new chunk? */
+if (chunk-used == STACK_CHUNK_DEPTH) {
+/* Need to add a new chunk */
+Stack_Chunk new_chunk = mem_allocate_aligned(sizeof(*new_chunk));
+new_chunk-used = 0;
+new_chunk-next = stack;
+new_chunk-prev = chunk;
+chunk-next = new_chunk;
+stack-prev = new_chunk;
+chunk = new_chunk;
+}
+
+entry = chunk-entry[chunk-used];
/* Remember the type */
entry-entry_type = type;
@@ -139,16 +153,7 @@
break;
}
-/* Register the new entry */
-if (++chunk-used == STACK_CHUNK_DEPTH) {
-/* Need to add a new chunk */
-Stack_Chunk new_chunk = mem_allocate_aligned(sizeof(*new_chunk));
-new_chunk-used = 0;
-new_chunk-next = stack;
-new_chunk-prev = chunk;
-chunk-next = new_chunk;
-stack-prev = new_chunk;
-}
+chunk-used++;
}
/* Pop off an entry and return a pointer to the contents */
@@ -176,7 +181,10 @@
internal_exception(ERROR_STACK_EMPTY, No entries on stack!\n);
}
-entry = chunk-entry[chunk-used - 1];
+/* Now decrement the SP */
+chunk-used--;
+
+entry = chunk-entry[chunk-used];
/* Types of 0 mean we don't care */
if (type entry-entry_type != type) {
@@ -189,8 +197,6 @@
(*entry-cleanup) (entry);
}
-/* Now decrement the SP */
-chunk-used--;
/* Sometimes the caller doesn't care what the value was */
if (where == NULL)
--
Bryan C. Warnock
[EMAIL PROTECTED]
[Applied] stacks.c
Applied, all tests passing.
--Josh
At 20:31 on 03/29/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote:
It won't go in cleanly any more:
How about the below patch?
Mike Lambert
Index: stacks.c
===
RCS file: /cvs/public/parrot/stacks.c,v
retrieving revision 1.26
diff -u -r1.26 stacks.c
--- stacks.c 29 Mar 2002 20:14:42 - 1.26
+++ stacks.c 30 Mar 2002 01:15:31 -
@@ -149,7 +149,21 @@
void *thing, Stack_entry_type type, Stack_cleanup_method
cleanup)
{
Stack_chunk *chunk = stack_base-prev;
-Stack_entry *entry = chunk-entry[chunk-used];
+Stack_entry *entry;
+
+/* Do we need a new chunk? */
+if (chunk-used == STACK_CHUNK_DEPTH) {
+/* Need to add a new chunk */
+Stack_chunk *new_chunk = mem_allocate_aligned(sizeof(Stack_chunk));
+new_chunk-used = 0;
+new_chunk-next = stack_base;
+new_chunk-prev = chunk;
+chunk-next = new_chunk;
+stack_base-prev = new_chunk;
+chunk = new_chunk;
+}
+
+entry = chunk-entry[chunk-used];
/* Remember the type */
entry-entry_type = type;
@@ -184,17 +198,8 @@
Invalid stack_entry_type!\n);
break;
}
-
-/* Register the new entry */
-if (++chunk-used == STACK_CHUNK_DEPTH) {
-/* Need to add a new chunk */
-Stack_chunk *new_chunk = mem_allocate_aligned(sizeof(Stack_chunk));
-new_chunk-used = 0;
-new_chunk-next = stack_base;
-new_chunk-prev = chunk;
-chunk-next = new_chunk;
-stack_base-prev = new_chunk;
-}
+
+chunk-used++;
}
/* Pop off an entry and return a pointer to the contents */
@@ -222,7 +227,10 @@
internal_exception(ERROR_STACK_EMPTY, No entries on stack!\n);
}
-entry = chunk-entry[chunk-used - 1];
+/* Now decrement the SP */
+chunk-used--;
+
+entry = chunk-entry[chunk-used];
/* Types of 0 mean we don't care */
if (type entry-entry_type != type) {
@@ -234,9 +242,6 @@
if (entry-flags STACK_ENTRY_CLEANUP_FLAG) {
(*entry-cleanup)(entry);
}
-
-/* Now decrement the SP */
-chunk-used--;
/* Sometimes the caller doesn't care what the value was */
if (where == NULL) {
[Applied] Re: Warnings Cleanup
Good enuff, thanks! Applied.
--Josh
At 20:36 on 03/29/2002 EST, Michel J Lambert [EMAIL PROTECTED] wrote:
I've applied portions of this patch. I omitted the parts which use the
byte type, which isn't going to work on all platforms.
I've changed these to use 'char'. Hopefully that will be more portable.
Mike Lambert
Index: misc.c
===
RCS file: /cvs/public/parrot/misc.c,v
retrieving revision 1.19
diff -u -r1.19 misc.c
--- misc.c17 Mar 2002 06:44:41 - 1.19
+++ misc.c30 Mar 2002 01:15:30 -
@@ -89,38 +89,40 @@
void int_to_str(char *, char *, HUGEINTVAL, INTVAL );
*/
-void gen_sprintf_call(char *, char *, SpfInfo, int);
+void gen_sprintf_call(char *, char *, SpfInfo, char);
static void
-uint_to_str(char *buf1, char *buf2, UHUGEINTVAL num, INTVAL base)
+uint_to_str(char *buf1, char *buf2, UHUGEINTVAL num, char base)
{
-int i = 0, cur;
+int i = 0, cur2;
+ char cur;
do {
-cur = num % base;
+cur = (char)(num % base);
if (cur 10) {
-buf2[i] = '0' + cur;
+buf2[i] = (char)('0' + cur);
}
else {
-buf2[i] = 'a' + cur;
+buf2[i] = (char)('a' + cur);
}
i++;
} while (num /= base);
-cur = i;
+cur2 = i;
-for (i = 0; i = cur; i++) {
-buf1[i] = buf2[cur - i];
+for (i = 0; i = cur2; i++) {
+buf1[i] = buf2[cur2 - i];
}
}
static void
-int_to_str(char *buf1, char *buf2, HUGEINTVAL num, INTVAL base)
+int_to_str(char *buf1, char *buf2, HUGEINTVAL num, char base)
{
BOOLVAL neg;
-int i = 0, cur;
+int i = 0, cur2;
+ char cur;
if (num 0) {
neg = 1;
@@ -131,13 +133,13 @@
}
do {
-cur = num % base;
+cur = (char)(num % base);
if (cur 10) {
-buf2[i] = '0' + cur;
+buf2[i] = (char)('0' + cur);
}
else {
-buf2[i] = 'a' + cur;
+buf2[i] = (char)('a' + cur);
}
i++;
@@ -147,10 +149,10 @@
buf2[i++] = '-';
}
-cur = i;
+cur2 = i;
-for (i = 0; i cur; i++) {
-buf1[i] = buf2[cur - i - 1];
+for (i = 0; i cur2; i++) {
+buf1[i] = buf2[cur2 - i - 1];
}
buf1[i] = 0;
@@ -186,7 +188,7 @@
}
void
-gen_sprintf_call(char *buf, char *buf2, SpfInfo info, int thingy)
+gen_sprintf_call(char *buf, char *buf2, SpfInfo info, char thingy)
{
int i = 0;
buf[i++] = '%';
@@ -251,7 +253,7 @@
for (i++; i (INTVAL)string_length(pat)
info.phase != PHASE_DONE; i++) {
-char ch = string_ord(pat, i);
+INTVAL ch = string_ord(pat, i);
switch (info.phase) {
/*@fallthrough@ */ case PHASE_FLAGS:
@@ -411,7 +413,7 @@
case 'f':
dbl = va_arg(*args, double);
-gen_sprintf_call(t1, t2, info, (char)'f');
+gen_sprintf_call(t1, t2, info, 'f');
sprintf(t2, t1, dbl);
targ = string_concat(interpreter, targ,
cstr2pstr(t2), 0);
Index: string.c
===
RCS file: /cvs/public/parrot/string.c,v
retrieving revision 1.64
diff -u -r1.64 string.c
--- string.c 24 Mar 2002 06:57:28 - 1.64
+++ string.c 30 Mar 2002 01:15:32 -
@@ -434,8 +434,6 @@
* end of our piece */
UINTVAL true_offset;
UINTVAL true_length;
-UINTVAL new_length;
-UINTVAL new_size;
INTVAL diff;
true_offset = (UINTVAL)offset;
@@ -791,7 +789,7 @@
* would approach 128 characters in the buffer.
*/
do {
-*--ptr = '0' + i % 10;
+*--ptr = (char)('0' + i % 10);
}
while(i /= 10);
[Patch] Fatal errors for invalid chartype/encoding lookups
I forgot to send this patch last night. I was browsing through the code and
noticed these return NULLs for what I think are probably really fatal
conditions.
Here's a patch which switches them to internal_exceptions. Hopefully i'm
not missing the point here.
--Josh
Index: chartype.c
===
RCS file: /cvs/public/parrot/chartype.c,v
retrieving revision 1.4
diff -u -r1.4 chartype.c
--- chartype.c 17 Mar 2002 06:44:41 - 1.4
+++ chartype.c 28 Mar 2002 17:27:26 -
-27,7 +27,7
return unicode_chartype;
}
else {
-return NULL;
+internal_exception(INVALID_CHARTYPE, Invalid chartype '%s'\n, name);
}
}
Index: encoding.c
===
RCS file: /cvs/public/parrot/encoding.c,v
retrieving revision 1.4
diff -u -r1.4 encoding.c
--- encoding.c 17 Mar 2002 06:44:41 - 1.4
+++ encoding.c 28 Mar 2002 17:27:26 -
-35,7 +35,7
return utf32_encoding;
}
else {
-return NULL;
+internal_exception(INVALID_ENCODING, Invalid encoding '%s'\n, name);
}
}
Index: include/parrot/exceptions.h
===
RCS file: /cvs/public/parrot/include/parrot/exceptions.h,v
retrieving revision 1.16
diff -u -r1.16 exceptions.h
--- include/parrot/exceptions.h 4 Mar 2002 03:17:21 - 1.16
+++ include/parrot/exceptions.h 28 Mar 2002 17:27:26 -
-30,6 +30,8
#define MALFORMED_UTF16 1
#define MALFORMED_UTF32 1
#define INVALID_CHARACTER 1
+#define INVALID_CHARTYPE 1
+#define INVALID_ENCODING 1
#define NEG_REPEAT 1
#define NEG_SUBSTR 1
#define NEG_SLEEP 1
Re: RT is your friend...
Should we be using bugs6 for all patches? --Josh At 15:04 on 03/28/2002 EST, Dan Sugalski [EMAIL PROTECTED] wrote: When you come across bugs, or there are things that should be implemented but aren't, could folks make entries in the perl 6 bugtracking system so we don't lose track? http://bugs6.perl.org. Thanks. (And don't feel like any code I've written is sacrosanct--it's not, and I'm happy to have it yanked out and replaced with stuff that works better) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[Patch] Add support for tests in C
This should enable writing tests which call parrot C functions directly,
which could be useful for increasing coverage to things which aren't easy to
call via opcodes.
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
Index: Makefile.in
===
RCS file: /cvs/public/parrot/Makefile.in,v
retrieving revision 1.141
diff -u -r1.141 Makefile.in
--- Makefile.in 21 Mar 2002 23:47:22 - 1.141
+++ Makefile.in 29 Mar 2002 05:29:24 -
@@ -388,7 +388,7 @@
#
###
-test: $(TEST_PROG) assemble.pl .test_dummy
+test: $(TEST_PROG) libparrot.a assemble.pl .test_dummy
.test_dummy:
$(PERL) t/harness
Index: lib/Parrot/Test.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Test.pm,v
retrieving revision 1.19
diff -u -r1.19 Test.pm
--- lib/Parrot/Test.pm 21 Mar 2002 23:47:25 - 1.19
+++ lib/Parrot/Test.pm 29 Mar 2002 05:29:25 -
@@ -11,7 +11,8 @@
require Test::Builder;
my $Builder = Test::Builder-new;
-@EXPORT = ( qw(output_is output_like output_isnt) );
+@EXPORT = ( qw(output_is output_like output_isnt),
+qw(c_output_is c_output_like c_output_isnt) );
@ISA = qw(Exporter);
sub import {
@@ -102,6 +103,55 @@
unless($ENV{POSTMORTEM}) {
unlink $out_f;
+}
+
+return $pass;
+ }
+}
+
+
+
+my %C_Test_Map = ( c_output_is = 'is_eq',
+ c_output_isnt = 'isnt_eq',
+ c_output_like = 'like'
+ );
+
+foreach my $func ( keys %C_Test_Map ) {
+ no strict 'refs';
+
+ *{'Parrot::Test::'.$func} = sub ($$;$) {
+++$count;
+my( $source, $output, $desc ) = @_;
+$output =~ s/\cM\cJ/\n/g;
+local( *SOURCE );
+my( $source_f, $obj_f, $exe_f, $out_f ) = map {
+ my $t = $0; $t =~ s/\.t$/$count$_/; $t
+} ('.c', $PConfig{o}, $PConfig{exe}, '.out');
+
+open SOURCE, $source_f or die Unable to open '$source_f';
+binmode SOURCE;
+print SOURCE $source;
+close SOURCE;
+
+_run_command($PConfig{cc} $PConfig{ccflags} -I./include -c
+$PConfig{ld_out}$obj_f $source_f);
+_run_command($PConfig{ld} $PConfig{ldflags} $obj_f $PConfig{cc_exe_out}$exe_f
+$PConfig{libs} -L. -lparrot);
+
+_run_command(./$exe_f, 'STDOUT' = $out_f, 'STDERR' = $out_f);
+
+my $prog_output;
+open OUTPUT, $out_f;
+{
+ local $/ = undef;
+ $prog_output = OUTPUT . '';
+ $prog_output =~ s/\cM\cJ/\n/g;
+}
+close OUTPUT;
+
+my $meth = $C_Test_Map{$func};
+my $pass = $Builder-$meth( $prog_output, $output, $desc );
+
+unless($ENV{POSTMORTEM}) {
+unlink $source_f, $obj_f, $exe_f, $out_f;
}
return $pass;
Index: t/harness
===
RCS file: /cvs/public/parrot/t/harness,v
retrieving revision 1.10
diff -u -r1.10 harness
--- t/harness 21 Mar 2002 23:47:37 - 1.10
+++ t/harness 29 Mar 2002 05:29:25 -
@@ -18,5 +18,5 @@
@ARGV = grep $_ ne 'quick', @ARGV;
# Pass in a list of tests to run on the command line, else run all the tests.
-my @tests = @ARGV ? @ARGV : map { glob( t/$_/*.t ) } ( qw(op pmc) );
+my @tests = @ARGV ? @ARGV : map { glob( t/$_/*.t ) } ( qw(op pmc src) );
runtests(@tests);
--- /dev/null Wed Feb 27 00:25:17 2002
+++ t/src/basic.t Fri Mar 29 00:28:14 2002
@@ -0,0 +1,26 @@
+#! perl -w
+
+use Parrot::Test tests = 2;
+
+c_output_is('CODE', 'OUTPUT', hello world);
+#include stdio.h
+
+int main(int argc, char* argv[]) {
+printf(Hello, World!\n);
+}
+CODE
+Hello, World!
+OUTPUT
+
+c_output_is('CODE', 'OUTPUT', direct internal_exception call);
+#include parrot/parrot.h
+#include parrot/exceptions.h
+
+int main(int argc, char* argv[]) {
+internal_exception(0, Blow'd Up(tm)\n);
+}
+CODE
+Blow'd Up(tm)
+OUTPUT
+
+1;
Re: [Patch] Add support for tests in C
Could you be specific? I was careful to do things identically to
Configure.pl (because we lack any common code I can use right now- that's
another problem we need to solve)
--Josh
At 22:03 on 03/28/2002 PST, Brent Dax [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED]:
# This should enable writing tests which call parrot C
# functions directly,
# which could be useful for increasing coverage to things which
# aren't easy to
# call via opcodes.
And it will shatter Windows. Don't even think about committing it.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: [Patch] Add support for tests in C
OK- i assumed that target was OK, since it was in the makefile. I'll
discuss this with you some more- perhaps this is the time to abstract away
some of this building-things stuff.
--Josh
At 22:23 on 03/28/2002 PST, Brent Dax [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
# Could you be specific? I was careful to do things identically to
# Configure.pl (because we lack any common code I can use right
# now- that's
# another problem we need to solve)
libparrot.a isn't even the right name on Windows, and the target itself
isn't portable. On Windows with a Microsoft toolkit, you use a program
called 'lib' to make .lib files:
C:\brent\Visual Studio Projects\Perl 6\parrot\parrotlib -?
Microsoft (R) Library Manager Version 7.00.9254
Copyright (C) Microsoft Corporation. All rights reserved.
usage: LIB [options] [files]
options:
/DEF[:filename]
/EXPORT:symbol
/EXTRACT:membername
/INCLUDE:symbol
/LIBPATH:dir
/LIST[:filename]
/MACHINE:{AM33|ARM|IA64|M32R|MIPS|MIPS16|MIPSFPU|MIPSFPU16|MIPSR41XX|
PPC|PPCFP|SH3|SH3DSP|SH4|SH5|THUMB|TRICORE|X86}
/NAME:filename
/NODEFAULTLIB[:library]
/NOLOGO
/OUT:filename
/REMOVE:membername
/SUBSYSTEM:{CONSOLE|EFI_APPLICATION|EFI_BOOT_SERVICE_DRIVER|
EFI_RUNTIME_DRIVER|NATIVE|POSIX|WINDOWS|
WINDOWSCE}[,#[.##]]
/VERBOSE
I haven't used 'lib' myself, so I can't really give you much usage
information. Sorry. My best guess is that the right command would be
lib -out:libparrot$(A) $(O_FILES)
assuming $(A) were appropriately defined.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
