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.
>
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
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
tighte
No, please close it.
--Josh
I haven't touched parrot in ages at this point. Please go ahead and close
the bug.
--Josh
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
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
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 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
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 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
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
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.
>
> http://homepage.mac.com/mich
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 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 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
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
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
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
N2, N1,N0
abs N2, N2
gt N2, 0.01, .$FPEQNOK
--
Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
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
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 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:
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
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 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
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.
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
conf
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
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
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:
> >
> >>
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
> >>
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
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
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 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
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 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
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 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 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 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 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
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
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
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'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
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
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
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 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
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 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
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
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
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
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
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.
>
> &
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
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
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
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
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)
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
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
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 @@
>
> =
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
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
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
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..)
>
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...
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 0
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
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-
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 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
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
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-
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
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
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 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 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 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 so
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 e
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
>
> --- p
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
>
>
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
> =
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
> [parr
--- 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
1 - 100 of 212 matches
Mail list logo
