Configuration VC7 Normal is BROKEN.
Step: make test
STDOUT output:
C:\Perl\bin\perl.exe t/harness
t/op/basic..dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/2 tests, 50.00% okay (-1 skipped test: 0 okay, 0.00%)
t/op/integerdubious
At 02:21 PM 9/20/2001 -0400, Andy Dougherty wrote:
>On Thu, 20 Sep 2001, Dan Sugalski wrote:
>
> > At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
> > >On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
> > > > I don't want to do int->pointer casts anywhere in the source if we can
> >
At 01:06 PM 9/20/2001 -0700, Robert Spier wrote:
>Dan,
>
> Could you explain again why you don't want char* anywhere, and prefer
> void*?
Because for character data we're not sure char * is right. (Might be
wchar_t, __int16, __int32, or something else) It's also to shake off the
"Oh, it's c
At 01:08 PM 9/20/2001 -0700, Damien Neil wrote:
>Another approach would be to include a means of defining information
>that must be included by the file implementing the ops. For example:
>
> HEADER {
> #include
> }
>
>This would then be placed into interp_guts.h. (Possibly surrounded
>by
On Thu, Sep 20, 2001 at 04:25:45PM -0400, Dan Sugalski wrote:
> At 01:06 PM 9/20/2001 -0700, Robert Spier wrote:
> > Could you explain again why you don't want char* anywhere, and prefer
> > void*?
>
> Because for character data we're not sure char * is right. (Might be
> wchar_t, __int16, __
Quoting Dan Sugalski <[EMAIL PROTECTED]>:
> > Could you explain again why you don't want char* anywhere, and
> prefer
> > void*?
>
> Because for character data we're not sure char * is right. (Might be
> wchar_t, __int16, __int32, or something else) It's also to shake off the
>
> "Oh, it's
On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
> >
> > What we're going to do is fire up a new interpreter for each thread. (We
> > may have a pool of prebuilt interpreters hanging around for this
> > eventuality) Threading *is* essential at the parrot level, and there are
> >
At 12:33 PM 9/20/2001 -0700, Hong Zhang wrote:
> > DS> I'm also seriously considering throwing *all* PerlIO code into
> > separate
> > DS> threads (one per file) as an aid to asynchrony.
> >
> > but that will be hard to support on systems without threads. i still
> > have that internals async
At 04:36 PM 9/20/2001 -0400, Rocco Caputo wrote:
>On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
> > >
> > > What we're going to do is fire up a new interpreter for each thread. (We
> > > may have a pool of prebuilt interpreters hanging around for this
> > > eventuality) Thread
Dan,
Could you explain again why you don't want char* anywhere, and prefer void*?
You answered this on language-dev, but went off on what seemed to be a tangent
about encodings.
Some ramblings of my own that may be confusing me, are:
char* doesn't necessarily mean "a string".
would t
On Thu, Sep 20, 2001 at 04:24:19PM -0400, Dan Sugalski wrote:
> At 01:08 PM 9/20/2001 -0700, Damien Neil wrote:
> >Another approach would be to include a means of defining information
> >that must be included by the file implementing the ops. For example:
>
> I like that approach. I'd say go for
On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote:
> Nope. Internal I/O, at least as the interpreter will see it is async. You
> can build sync from async, it's a big pain to build async from sync.
> Doesn't mean we actually get asynchrony, just that we can.
For clarification: do you
> DS> I'm also seriously considering throwing *all* PerlIO code into
> separate
> DS> threads (one per file) as an aid to asynchrony.
>
> but that will be hard to support on systems without threads. i still
> have that internals async i/o idea floating in my numb skull. it is an
> api that
At 01:53 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote:
> > Nope. Internal I/O, at least as the interpreter will see it is async. You
> > can build sync from async, it's a big pain to build async from sync.
> > Doesn't mean we actually get asy
> Nope. Internal I/O, at least as the interpreter will see it is async. You
> can build sync from async, it's a big pain to build async from sync.
> Doesn't mean we actually get asynchrony, just that we can.
>
It is trivial to build async from sync, just using thread. Most Unix async
are built
test_main.c still seems to contain a call to _read(), rather than
read(). This breaks compilation under Tru64 for me; the attached
patch removes the _.
- Damien
Index: test_main.c
===
RCS file: /home/perlcv
Arthur Bergman wrote:
> > Arthur Bergman wrote:
> >
> > > In an effort to rest my braine from a coredumping perl5 I started to think a bit
>on threading under parrot?
> > >
> > > While it has been decided that perl should be using ithread like threading, I
>guess that is irelevant at the parrot
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
> Damien, is there any way we could get a similar fix for number.t? That
> would make us at 100% on Tru64.
(Apologies if this shows up twice; something appears to be screwy with
my mail system.)
I'm currently getting segfaul
At 05:23 PM 9/20/2001 -0400, Michael L Maraist wrote:
>There wasn't any code for CHECK_EVENTS w/in Parrot when I first read the
>source-code. I merely assumed that it's role was not-yet determined, but
>considered the possible uses. CHECK_EVENTS seems to be gone at the
>moment, so it's a moot
At 02:04 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
> > >For clarification: do you mean async I/O, or non-blocking I/O?
> >
> > Async. When the interpreter issues a read, for example, it won't assume
> the
> > read completes immediately.
On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
> >For clarification: do you mean async I/O, or non-blocking I/O?
>
> Async. When the interpreter issues a read, for example, it won't assume the
> read completes immediately.
That sounds like what I would call non-blocking I/O. Asy
> you can't do non-blocking i/o on files without aio_read type calls. but
> what dan is saying is that the api the interpreter uses internally will
> be an async one. it will either use native/POSIX aio calls or simulate
> that with sync calls and callbacks or possibly with threads.
>
That sound
At 02:17 PM 9/20/2001 -0700, Damien Neil wrote:
>On Thu, Sep 20, 2001 at 05:09:52PM -0400, Dan Sugalski wrote:
> > Just a reminder--function names shouldn't exceed 31 characters. The C
> > standard doesn't guarantee anything past that...
>
>You think that's bad? You aren't guaranteed more than si
> + cd t; make realclean
( from MM_Unix, sub clean
if ($Is_Win32 && Win32::IsWin95()) {
push @m, <{MAKEFILE}
\$(MAKE) clean
cd ..
EOT
}
else {
push @m, <{MAKEFILE} && \$(MAKE) clean
EOT
}
If you could change it to
cd t
On Thu, Sep 20, 2001 at 04:54:21PM -0500, Brian Wheeler wrote:
> Since all benchmarks are crap anyway, I've written a test which tells
> the average number of instructions per second. On my athlon 700 I get
> 3966053 instructions per second and on my PIII 866 I get 5081485
> instructions per seco
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
> Actually the ops=>C conversion was conceived to do exactly what's being
> done now--to abstract out the body of the opcodes so that they could be
> turned into a switch, or turned into generated machine code, or TIL'd. If
> you're
In message <[EMAIL PROTECTED]>
Simon Cozens <[EMAIL PROTECTED]> wrote:
> So, if you're running on one of the core platforms, please check out a
> *clean* CVS copy, try and build and post the output of make test.
Tests cleanly on linux/x86:
perl t/harness
t/op/basic..ok, 1/2 skippe
27 matches
Mail list logo
