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
tighte
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
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 w
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.
> # 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
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 wi
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" (s
Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote:
> >
> > Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See
> > also debian's apt-get.
> >
> > Which brings me to my pet peeve-
pear 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.
>
> Y
codings/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
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-
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
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 0
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
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..)
>
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.
> # http://bugs6.perl.org/rt2/Ticket/Di
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.
> # http://bugs6.perl.org/rt2/Ticket
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 -05
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 @@
>
> =
y parsing and generating XML/HTML
content in a flexible way belongs in the core libraries, if not the language
itself.
--Josh
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
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 t
nit (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)
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 d
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, s
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
task
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 PROTECTE
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.
>
> &
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:
>
> Me
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 p
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
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
>
>
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 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 necessa
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 t
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 th
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 woul
t;[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 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
> # version
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
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 cou
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, t
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
>
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
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
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 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
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
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 appear
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
r
I haven't touched parrot in ages at this point. Please go ahead and close
the bug.
--Josh
No, please close it.
--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
> >>
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
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:
> >
> >>
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.
> # http://rt.perl.org/rt2
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; optimisatio
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
conf
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
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.
>
>
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.
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 dir
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 kno
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 b
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:
ECTED]> 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
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 PRO
N2, N1,N0
abs N2, N2
gt N2, 0.01, .$FPEQNOK
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
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
A
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 req
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:
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 refer
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
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 <[E
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 Sm
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 soo
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,
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
Thank you! You make some of my cheesy code a bit more respectable :)
--Josh
At 23:35 on 01/20/2004 +0100, Michael Scott <[EMAIL PROTECTED]> wrote:
> I've committed updates to the documentation in the Perl scripts in
> build_tools, classes and tools/dev.
>
> http://homepage.mac.com/mich
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 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
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
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
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
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
This patch adds Dan Sugalski's explanation to the code.
Index: memory.c
===
RCS file: /home/perlcvs/parrot/memory.c,v
retrieving revision 1.9
diff -u -r1.9 memory.c
--- memory.c2001/09/16 01:45:51 1.9
+++ memory.c2001/09
This time i've filtered out all the memory leak related data so all that
shows up are legitimate errors. (hopefully)
I have set up a cheesy script to update the following URL with the current output
of purify on the current CVS test_prog (test,test2,test3,euclid) every hour.
http://www.hitchh
s only running every day. Can we get it to
> run every hour? Perhaps even on demand? I think I have fixed all of the
> memory access errors but one.
>
> -Original Message-
> From: Josh Wilmes
> To: [EMAIL PROTECTED]
> Sent: 9/15/2001 5:16 PM
> Subject: "A
ote:
> The hourly should be fine...can you do me one other favor and run the
> following c snippet through Purify:
>
> int main() {
> char* c = (char*)malloc(0);
> printf( "%.*s\n", 0, c );
> return 0;
> }
>
> -Original Message-
> From:
I just ran purify against the current Parrot CVS as of today at 10 AM PDT.
Here are the results:
jwilmes@jwilmes-sun:/apps/users/jwilmes/devel/parrot$ ./test_prog test.pbc
Purify instrumented test_prog (pid 2187 at Wed Sep 12 10:05:34 2001)
* Purify 5.2 Solaris 2 (32-bit), Copyright (C)
FYI..
There are a few interesting things in here which look like they may be
real errors. (i'd ignore the PLKs for now)
--Josh
perl assemble.pl t/test.pasm > t/test.pbc
./test_prog t/test.pbc > t/test.out
Purify instrumented test_prog (pid 17982 at Thu Sep 13 02:08:41 2001)
* Purify
> wrote:
> On Thu, Sep 13, 2001 at 02:21:16AM -0700, Josh Wilmes wrote:
> > There are a few interesting things in here which look like they may be
> > real errors. (i'd ignore the PLKs for now)
>
> Thanks for doing this, but to be honest, I expect our memory alloc
At 1:30 on 09/18/2001 BST, Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 17, 2001 at 10:38:35AM -0500, Jonathan Scott Duff wrote:
> > Parrot/Opcode.pm only uses Digest::MD5 for fingerprinting the opcode
> > file which could be done without Digest::MD5 IMHO. For instance,
> > using unpack
solaris 2.7
--Josh
At 0:13 on 09/19/2001 CDT, Gibbs Tanton - tgibbs <[EMAIL PROTECTED]> wrote:
> What type of machine is the hourly purify running on. It keeps dieing with
> a SIGBUS on most set_n_nc calls (meaning invalid alignment). This is really
> bad. I would like to know the type of a
Here's a fixed version of that patch I sent a while back:
Index: Parrot/Opcode.pm
===
RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
retrieving revision 1.7
diff -u -r1.7 Opcode.pm
--- Parrot/Opcode.pm2001/09/20 14:39:17
e being ignored (either casting to void
or doing something with them)
- cast IVs to (unsigned int) when printfing them with "%x".
- remove unused variables (only in one function)
- return a value in some places where there was a void return but the
function had a retur
1 - 100 of 212 matches
Mail list logo
