> > This patch trims off the period at the end of executable filenames for
> > C-based tests on unix. (It compiled "t/src/basic_1.c" ->
> > "t/src/basic_1."; this patch makes that "t/src/basic_1")
>
> This patch should also update languages/perl6/P6C/TestCompiler.pm, since
> it hijacks lib/Parrot/
Perl6 on Win32 MS VC++ gives:
Failed TestStatus Wstat Total Fail Failed List of Failed
--
t/compiler/8.t 1 256 61 16.67% 6
t/compiler/a.t 1 256 31 33.33% 2
t/rx/call.t1 256 21 50.
On Fri, Sep 06, 2002 at 12:47:11AM +0200, Leopold Toetsch wrote:
> Steve Fink (via RT) wrote:
>
> ># New Ticket Created by Steve Fink
> ># Please include the string: [perl #17039]
> ># in the subject line of all future correspondence about this issue.
> ># http://rt.perl.org/rt2/Ticket/Displa
Steve Fink (via RT) wrote:
> # New Ticket Created by Steve Fink
> # Please include the string: [perl #17039]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17039 >
Why intarrary.pmc:
> +=item B(in PMC, in PMC)
...
The first enclosed patch quashes "invalid pragma" warnings in platform.h, the
second one makes another exception to imcc requiring (maybe imcc
should come with a sysexits.h instead?)
__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
ht
Jeff wrote:
>
> And some more marked as committed that got missed...
> Patch #17000 -
Ewps. It was recently pointed out to me that I accidentally reversed
#17000. The problem has been fixed, I believe. Sorry, Andy.
--
Jeff <[EMAIL PROTECTED]>
Steve Fink wrote:
>
> I have applied at least one other not on your list (#17008). Should I
> be marking things as applied? I didn't think I had the permissions to
> do that, so I've just been trying to make sure I post a "Thanks,
> applied" so it gets into RT's reply set. Can I do more than that
I have applied at least one other not on your list (#17008). Should I
be marking things as applied? I didn't think I had the permissions to
do that, so I've just been trying to make sure I post a "Thanks,
applied" so it gets into RT's reply set. Can I do more than that?
And a couple others:
#16962 -- (docs) applied
#16938 -- (imcc) applied
/s
On Thu, 5 Sep 2002, Jeff wrote:
> And some more marked as committed that got missed...
>
> Most of the time I'm looking at http://www.parrotcode.org/openpatches/
> in order to find out what needs to be committed. I'm so
And some more marked as committed that got missed...
Most of the time I'm looking at http://www.parrotcode.org/openpatches/
in order to find out what needs to be committed. I'm so far just marking
patches as 'Applied', not closing out the RT report.
(NOte: I'm not claiming that I committed all o
At 8:53 PM -0400 9/5/02, Bryan C. Warnock wrote:
>On Thu, 2002-09-05 at 16:20, Dan Sugalski wrote:
>>
>> *) I think we may have to have separate vtable operations for hyperoperators
>
>> *) I think I've finally given in, and vtables will be hierarchical
>
>Being vtable-ignorant in general:
>
>1)
On Thu, 2002-09-05 at 16:20, Dan Sugalski wrote:
>
> *) I think we may have to have separate vtable operations for hyperoperators
> *) I think I've finally given in, and vtables will be hierarchical
Being vtable-ignorant in general:
1) How big is *too* big (for the regular vtable)
2) How big
On Fri, 2002-09-06 at 02:45, Brent Dax wrote:
> So, building Parrot ought to look something like this (for a Windows
> user):
>
> c:\parrot> cd build
> c:\parrot\build> win32
> Are you using MS VC++? [yn] y
>
> Miniparrot build complete.
> Enter 'miniparrot bu
On Thu, 5 Sep 2002, Andy Dougherty wrote:
> Ok, with the alignment hack now in (see resources.c) and lots of various
> and sundry portability fixes, it looks like we're on our way to turning
> the tinderbox a lovely shade of green. (The solaris failures are timeouts
> unrelated to parrot, and th
Ok, with the alignment hack now in (see resources.c) and lots of various
and sundry portability fixes, it looks like we're on our way to turning
the tinderbox a lovely shade of green. (The solaris failures are timeouts
unrelated to parrot, and the other failures are due to MANIFEST hiccoughs
and
Steve Fink wrote:
> Here is the new PMC I keep babbling about. Before I commit it, any
> comments? Like, does anybody think this should be named differently?
> It's really a dequeue (double-ended queue), ...
I for one think it ought to be called what it is - a dequeue.
--
John Douglas Porter
Piers Cawley wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> writes:
> > But how do I represent them at parrot-level.
>
> { type => '*environment*' value => {scratchpad => aScratchPadPMC}
Etc.
The point being, we're building these things into parrot so that
HLLs can use them natively, rather than
At 6:24 PM +0200 9/5/02, Leopold Toetsch wrote:
>Nicholas Clark wrote:
>
>>1: the value in the register did/didn't change
>>2: the value of the thing referenced by the register did/didn't change
>>
>>(possibly 2a and 2b being that the internals of the object didn't/might've
>>changed)
>
>
>Actuall
Since I'm about to go heads-down, as a deadline jumped a week closer
(to yesterday)
*) I think we may have to have separate vtable operations for hyperoperators
*) Calling conventions are changing *again*. Adding the type of the
return value, and the calling frame
*) We're switching from a tree
At 3:28 PM -0400 9/5/02, Andy Dougherty wrote:
>On Thu, 5 Sep 2002, Tanton Gibbs wrote:
>
>> I just did a cvs update and tried to configure, but it said I was missing
>> the following files:
>>
>> languages/scheme/Scheme/Builtins.pm
>> languages/scheme/t/logic/lists.t
>>
>> Does anyone else h
# New Ticket Created by Steve Fink
# Please include the string: [perl #17039]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17039 >
Here is the new PMC I keep babbling about. Before I commit it, any
comments? Like, does a
Juergen Boemmels <[EMAIL PROTECTED]> writes:
f> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>> At 1:58 PM + 9/5/02, "Jürgen" "Bömmels" (via RT) wrote:
>> >The recent discussion of languages independence rememberd me of an
>> >very old patch of mine which implements scheme pairs. (January 2002)
On Thu, 5 Sep 2002, Tanton Gibbs wrote:
> I just did a cvs update and tried to configure, but it said I was missing
> the following files:
>
> languages/scheme/Scheme/Builtins.pm
> languages/scheme/t/logic/lists.t
>
> Does anyone else have this problem?
Yes. Aargh. And I had *just* fixed the
On Thu, 5 Sep 2002 10:27:05 -0700 Steve Fink <[EMAIL PROTECTED]> wrote:
>Speaking of Sub/Coroutine/Continuation, right now we *really* need
>someone who pretends to understand this stuff to take a look at
>Jonathan Sillito's patches and do something with them. Or give him
>commit privs, or somethi
On Thu, Sep 05, 2002 at 10:33:50AM -0700, Sean O'Rourke wrote:
> Is there a reason you went for a deque instead of a stack? I can
> definitely see the need for a _PMC_ deque (unshift on the current
> PerlArray implementation blows), and for an integer _stack_ (regexes), but
> not for an int-only
Nicholas Clark:
# On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote:
# > 4) The *only* tools you will need to build parrot are a C compiler
# > environment and either a make tool or a shell
#
# I believe we may be able to get away without a make tool or a shell.
The final build system
I just did a cvs update and tried to configure, but it said I was missing
the following files:
languages/scheme/Scheme/Builtins.pm
languages/scheme/t/logic/lists.t
Does anyone else have this problem?
Tanton
BTW, I'm glad to see you still working on/maintaining the African Grey
variation. I think it is important to maintain alternatives. Who knows, at
some point in the future, it may be determined that this is the right way to
go. If memory for embedded systems is the only issue, then I could
defin
Steve Fink wrote:
> Twice as fast seems like a good thing. Is this with the stackwalk
> disabled? What prevents this from being applied to Parrot now?
Yes, stackwalk is disabled, as it still isn't required yet. Enabling
stackwalk takes 112 seconds, so the other differences in grey
seem to have
Is there a reason you went for a deque instead of a stack? I can
definitely see the need for a _PMC_ deque (unshift on the current
PerlArray implementation blows), and for an integer _stack_ (regexes), but
not for an int-only deque. I'm assuming you have a reason for this, which
I have not yet d
On Wed, Sep 04, 2002 at 08:48:29PM -0700, Sean O'Rourke wrote:
> On Wed, 4 Sep 2002, Steve Fink wrote:
> > I tend to create new PMC classes frequently, and they're a pain to
> > maintain without committing, because you have to touch lots of files
> > to add a PMC, and in ways that are sure to caus
On Wed, Sep 04, 2002 at 11:11:45PM -0400, John Porter wrote:
> Thanks, Steve. I agree 100% with everything you said!
>
> Except:
>
> > ... the best way to that
> > goal is to use Perl6 as the driver, at least until something else
> > shows up, because that's the only way to derive realistic req
Nicholas Clark wrote:
> 1: the value in the register did/didn't change
> 2: the value of the thing referenced by the register did/didn't change
>
> (possibly 2a and 2b being that the internals of the object didn't/might've
> changed)
Actually, thinking now of an optimizer, we should know these
Thanks to Joseph Ryan, P6C does interploated strings now, meaning less
underscore, which we can all agree is a Good Thing ;).
/s
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 1:58 PM + 9/5/02, "Jürgen" "Bömmels" (via RT) wrote:
> >The recent discussion of languages independence rememberd me of an
> >very old patch of mine which implements scheme pairs. (January 2002).
> >The languages/scheme directory did not change ve
At 3:04 PM + 9/5/02, Leon Brocard (via RT) wrote:
>I realise that proper Unicode support is coming, but it may be a while
>to get here. We currently have ord() and it makes sense to have a
>chr() as well, so that's what my patch provides. Please apply, thanks ;-)
Done.
--
# New Ticket Created by Leon Brocard
# Please include the string: [perl #17035]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17035 >
I realise that proper Unicode support is coming, but it may be a while
to get here. We
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #17034]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17034 >
Here are today's patches I needed to get parrot building. Again, I had to
guess abou
On Thu, 5 Sep 2002, Sean O'Rourke wrote:
> Changed the main Makefile from
>
> LD_SHARED= -shared
> to
>
> LD_SHARED= -G
Mostly correct. config/init/data.pl is where the bad data is coming from.
My patch to fix it is already entered into the database as perl #16937. (I
also submitted the same
Applied (see also mailing list discussion).
/s
# New Ticket Created by "Sean O'Rourke"
# Please include the string: [perl #17032]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17032 >
>From busunsl on perlmonks (http://perlmonks.org/index.pl?node_id=195334):
The prob
On Thu, 5 Sep 2002, Brent Dax wrote:
> Sean O'Rourke:
> # > # 4 - the other arrays boosted to the highest dimension
> # > It's already been defined to be #4.
> #
> # Argh. Then I need to whinge a bit -- what if it's a ragged
> # array? What if different elements have different dimensions
> # the
At 1:58 PM + 9/5/02, "Jürgen" "Bömmels" (via RT) wrote:
>The recent discussion of languages independence rememberd me of an
>very old patch of mine which implements scheme pairs. (January 2002).
>The languages/scheme directory did not change very much since then,
>but the key system totally ch
Nicholas Clark (via RT) wrote:
> On Thu, Sep 05, 2002 at 04:38:37AM -0400, Dan Sugalski wrote:
[ inout ]
> That makes it sound like we have (at least) 2 directions of out. We seem
> to have
>
> in the register is read,
> (and the value pointed to by the register is read)
> out1
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #17030]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17030 >
Hello,
The recent discussion of languages independence rememberd me of an
very old p
At 1:40 PM +0100 9/5/02, Nicholas Clark wrote:
>I believe applying the patch is the right thing, because it's progress
>on where we are, but I think (not fully formed yet) that we would benefit
>from finer granularity on what can get modified
Point. OK, put 'em in.
--
In message <[EMAIL PROTECTED]>
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> [IIRC the question at one time was whether a const method in C++ could
> change the underlying object, providing the values returned by all public
> methods would not change as a result]
The answer to which is of
On Wed, 4 Sep 2002 22:51:53 -0700 (PDT), Sean O'Rourke wrote:
> On Wed, 4 Sep 2002, Brent Dax wrote:
> > Sean O'Rourke:
> > # On Wed, 4 Sep 2002, Brent Dax wrote:
> > # > What if (say) @b is a two-dimensional array?
> > #
> > # Then you get "interesting values of undef" :). Seriously, I
> > # sus
On Wed, Sep 04, 2002 at 10:27:42PM -0400, Melvin Smith wrote:
>This is no surprise. Parrot documentation will be lacking until
>things settle down.
Actually it's not so much the documentation. I didn't complain about
0.0.7 and 0.0.8 requiring changes to parrot-gen.py, because that's
simply to be
On Thu, Sep 05, 2002 at 08:15:28AM -0400, Dan Sugalski wrote:
> At 1:28 PM +0200 9/5/02, Leopold Toetsch wrote:
> >Dan Sugalski (via RT) wrote:
> >
> >We need to nail down what the directions mean.
> >
> >
> >This is, what I'm trying to do since quite a time.
> >
> >... The IMCC and JIT folks are
At 1:28 PM +0200 9/5/02, Leopold Toetsch wrote:
>Dan Sugalski (via RT) wrote:
>
>We need to nail down what the directions mean.
>
>
>This is, what I'm trying to do since quite a time.
>
>... The IMCC and JIT folks are the ones that care here.
>
>Here is the IMCC folks speaking ;-)
Sorry. I've bee
Dan Sugalski (via RT) wrote:
> We need to nail down what the directions mean.
This is, what I'm trying to do since quite a time.
> ... The IMCC and JIT folks
> are the ones that care here.
Here is the IMCC folks speaking ;-)
>... I've been working on the assumption that
> an out means t
On Thu, Sep 05, 2002 at 12:12:52PM +0100, Nicholas Clark wrote:
> On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote:
> > 4) The *only* tools you will need to build parrot are a C compiler
> > environment and either a make tool or a shell
>
> I believe we may be able to get away withou
On Thu, Sep 05, 2002 at 04:38:37AM -0400, Dan Sugalski wrote:
> At 8:04 AM + 9/5/02, Leopold Toetsch (via RT) wrote:
> >core.ops has currently:
> >
> >- obvious errors e.g.
> > -inline op mul (out PMC, out PMC, out PMC) {
> >
> >- wrong docu and minor typos e.g.
> > -=item B(in PMC, in
Brent Dax wrote:
> Keep in mind how much it could inflate the bytecode if
> we render a ton of generic, N-dimensional hyper-operator logic into
> bytecode.
The main problem I see is that you could spend minutes executing
inside that hyper op. Doesn't that screw with the plan for putting
the even
On Thu, Sep 05, 2002 at 07:03:00AM -0400, Dan Sugalski wrote:
> 4) The *only* tools you will need to build parrot are a C compiler
> environment and either a make tool or a shell
I believe we may be able to get away without a make tool or a shell.
It won't be pretty, but I see no reason why we
I really hadn't planned on going into this now, but the issue's been
raised enough that it can't be left to later. Here's the current set
of long-term goals for Parrot:
1) We *will* run Perl 6, Perl 5, Ruby, Python, JVM bytecode, and .NET
bytecode. Not necessarily in that order
2) [EMAIL PROT
At 8:04 AM + 9/5/02, Leopold Toetsch (via RT) wrote:
>core.ops has currently:
>
>- obvious errors e.g.
> -inline op mul (out PMC, out PMC, out PMC) {
>
>- wrong docu and minor typos e.g.
> -=item B(in PMC, in STR)
>
>- and finally (as discussed in perl6-internals, "core ops ARGDIR"),
>
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17026]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17026 >
core.ops has currently:
- obvious errors e.g.
-inline op mul (out PMC, out PMC,
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17025]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17025 >
If this one is already in queue, bare with me.
find_op does either die or return fa
Sean O'Rourke:
# > # 4 - the other arrays boosted to the highest dimension
# > It's already been defined to be #4.
#
# Argh. Then I need to whinge a bit -- what if it's a ragged
# array? What if different elements have different dimensions
# themselves, e.g. "[1,[2,3]]"? I think there's seri
61 matches
Mail list logo
