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
I haven't touched parrot in ages at this point. Please go ahead and close
the bug.
--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 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
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
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
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
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 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 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
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
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'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 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
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
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
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
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
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
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
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
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
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...
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
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:
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
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
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?
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
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
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
1 - 100 of 176 matches
Mail list logo