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
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
At 12:00 on 06/01/2006 BST, David Cantrell [EMAIL PROTECTED] wrote:
Basic I/O is talking to filehandles and nyetwork sockets. Anything
above the UDP / TCP level should not, IMO, be included.
I'd respectfully disagree. Just like text isn't just ascii any more,
content isn't just on local
I think that the distribution approach is a good way to go. I also
think that there could be value in a set of core modules for some basic
functions. The only reason to do this, however, would be to design those
modules to work especially well together. These modules could follow
tighter
I haven't touched parrot in ages at this point. Please go ahead and close
the bug.
--Josh
No, please close it.
--Josh
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
At 9:23 on 09/08/2004 EDT, Dan Sugalski [EMAIL PROTECTED] wrote:
- executing programs in any kind of sophisticated way (fork/exec, pipes)
We do get system and popen, though.
Well, system at least. popen is not part of the c89 spec as far as I know.
This URL is a fairly handy reference:
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,
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
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
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
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
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
At this point in the development cycle you can certainly make such
arguments (although I would tend to fall on the side of consistency
myself, at least for things that really Don't Matter in the grand scheme
of things, such as POD modules).
But once we start expecting people in the real world
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
Thank you! You make some of my cheesy code a bit more respectable :)
--Josh
At 23:35 on 01/20/2004 +0100, Michael Scott [EMAIL PROTECTED] wrote:
I've committed updates to the documentation in the Perl scripts in
build_tools, classes and tools/dev.
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
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
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
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
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
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
abs N2, N2
gt N2, 0.01, .$FPEQNOK
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
:
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
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
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
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
At 11:40 on 06/01/2003 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
Yep. Imcc should definitely move out off languages into its own subdir
under the top level (Not in the top level itself).
... Who should do
this? I'd be willing to help if given direction.
Moving directories
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
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.
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
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
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:
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
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
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
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
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
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
At 20:47 on 11/13/2002 GMT, Nicholas Clark [EMAIL PROTECTED] wrote:
On Wed, Nov 13, 2002 at 03:06:03PM -0500, Dan Sugalski wrote:
The goal is for Parrot to require a C compiler and a platform shell
or Make tool (either one) and that's it. We will ship with bytecode
files that have the
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
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
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
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
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
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
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
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
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
I think this solution is the simplest... i'll go ahead and commit it.
--Josh
At 10:15 on 11/01/2002 PST, Brent Dax [EMAIL PROTECTED] wrote:
Andy Dougherty:
# At the moment, the bytecode fingerprint is built with
# Digest::MD5. Alas, Digest::MD5 wasn't standard with perl
# versions prior
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
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
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
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
At 22:58 on 10/23/2002 EDT, Erik Lechak [EMAIL PROTECTED] wrote:
I fix the errors then It gets all wierd on the def PARROT_STACK_DIR. So
I tried to figure out that problem.
Anyways, I am on Win XP using VC++. I look in Config.pm and I see this
'#define PARROT_STACK_DIR'. It's not
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
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
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
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
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
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
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
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
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]
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
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
belongs in the core libraries, if not the language
itself.
--Josh
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
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
, 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
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
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
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:
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:
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...
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
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
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
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
At 10:23 on 06/07/2002 EDT, Melvin Smith [EMAIL PROTECTED] wrote:
At 03:28 AM 6/7/2002 -0400, Josh Wilmes wrote:
It appears that the mechanism for choosing an os layer for PIO could use
some work, and it also appears that io_stdio is incomplete.
Yes to both.
The mechanism:
#ifndef
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
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
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
[EMAIL PROTECTED] wrote:
On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote:
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
also debian's apt-get.
Which brings me to my pet peeve- I think it's time to start doing binary
packaging in CPAN
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
also debian's apt-get.
Which brings me to my pet peeve- I think it's time to start doing binary
packaging in CPAN, for those who don't want to bother with compilation.
That has interesting implications for how we deal
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
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
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
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
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
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:
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
This one too.
--Josh
At 19:10 on 04/11/2002 EDT, Simon Glover [EMAIL PROTECTED] wrote:
This patch tidies up a few of the comments in string.c, and fixes one
actual documentation bug -- namely, string_chopn removes the last
n _characters_, not the last n _bytes_.
Simon
---
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
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 @@
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
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
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
--- 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
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
1 - 100 of 198 matches
Mail list logo
