Here is a small patch on top of #23039
- fix memory corruption for very small programs
- fix misplaced #endif
leo
--- interpreter.c Fri Jul 18 17:53:13 2003
+++ /opt/src/parrot-leo/interpreter.c Sat Jul 19 11:07:48 2003
@@ -202,13 +202,16 @@
void **temp = (void **)Parrot_memalign_i
Benjamin Goldberg wrote:
Maybe someone should write a script like this:
Then run it on all the code, except that which actually defines the
VTABLE_ macros.
Direct access to vtable may only be used .ops files, where a similar
substitions is done by ops2c.pl. Changing the opsfiles needs adaption in
Brent Dax <[EMAIL PROTECTED]> wrote:
>core.ops is...monolithic.
>core.ops could use a good splitting out, definitely
That's ok for me.
leo
JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> nci.c generates a bunch of prototype warnings when compiled with gcc
Applied, thanks.
leo
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Could we try and clean up the parrot/ directory? Specifically, I'd like
> all of the source code itself moved into a single subdirectory, leaving
> at the toplevel only directories, the all-caps files, and a few others
> (ChangeLog, Configure.pl, par
On Fri, Jul 18, 2003 at 05:42:10PM -0400, Benjamin Goldberg wrote:
> AIO is unpopular because it's not widely/portably supported, whereas
> non-blocking event-loop IO is, (one generally does have either select or
> poll), as is blocking threaded IO (even if the thread starting stuff may
> need to b
On Fri, Jul 18, 2003 at 05:58:41PM -0400, Uri Guttman wrote:
> and event loop i/o doesn't usually support async file i/o. many people
> conflate the two. event i/o handles sockets, pipes and such but none
> support files. the issue is that the async file i/o api is so different
> (or non-existant)
On Fri, Jul 18, 2003 at 12:00:55PM -0700, Robert Spier wrote:
> > There doesn't seem to be any documentation anywhere on this, and we
> > thought the QA wiki might be a useful place to try putting it
> > together.
>
> I'd rather something that can actually live on bugs.perl.org.
How about a bugs.
On Fri, Jul 18, 2003 at 06:36:41PM +0100, Tony Bowden wrote:
> What's the current approach to turning perlbugs into tests?
>
> Should they be done as TODOs? Is there a distinct set of test files for
> them? etc? Can they use Test::More? etc. etc. etc.
>
> e.g. http://bugs6.perl.org/rt2/Ticket/Di
On Fri, Jul 18, 2003 at 09:17:26PM -0700, Robert Spier wrote:
> > > I'd rather something that can actually live on bugs.perl.org.
> > How about a bugs.perl.org Kwiki?
>
> I have not yet drunk that particular Kool Aid.
I will unleash Ingy upon you when he gets back.
> I'm happy to accept patch
> At 12:16 on 07/10/2003 PDT, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >At 11:56 AM -0700 7/10/03, Robert Spier wrote:
> >>s/Yet Another Society/The Perl Foundation/g
> >
> >The Perl Foundation is just a dba of YAS. The name should, unless
> >things have changed, be YAS.
We're generally encour
I've been looking around Objective-C a bit, and I would like to turn
over an old rock.
Remember when I suggested that (static) type equivalence should be
based on interface equivalence? Objective-C seems to feel the same
way. It calls an interface a I, and specifying it is
optional. This maps n
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:17 PM +0200 7/13/03, Leopold Toetsch wrote:
>>
>>I think one Env PMC ought to be enough. And that one may have e.g. an
>>Iterator ettached, which simplest is done by deriving it from an hash
>>like PMC.
> Potentially, yes. We still ought not cache, si
On Fri, Jul 18, 2003 at 01:54:24PM -0700, chromatic wrote:
> In general, the person who fixes the bug writes a regression test for
> the bug. The pumpkings and other porters are really good about making
> sure patches have tests.
Yes, but I'm talking about outstanding bugs that don't have tests
Leopold Toetsch wrote:
Direct access to vtable may only be used .ops files,
s/\.ops/in .ops and .pmc/
Sorry,
leo
Out of interest, is there a reason http://testers.cpan.org/
is so slow?
cheers,
--
Iain.
who has written his own version because he was
fed up with the speed of that site.
Luke Palmer wrote:
[...]
[1] It would be totally cool to use a Haskell- or ML-style type
inference system, but those things just don't work in procedural
languages.
And they're very slow when not done at compile-time. Try a Haskell
interpreter like hugs vs. a Haskell compiler like ghc.
Steffen
--
Out of interest, is there a reason http://testers.cpan.org/
is so slow?
Huge size of database ?
Hello,
I've been looking at the testers database (well, downloading the list
via nntp.perl.org really) for Module::CPANTS recently.
In the current version of Module::CPANTS I report the count of PASSes
and FAILs for each distribution. This works well.
I've been looking at gathering the number of
On 19 Jul 2003, Luke Palmer wrote:
> [1] It would be totally cool to use a Haskell- or ML-style type
> inference system, but those things just don't work in procedural
> languages.
Could you clarify what you mean by "don't work" here? ML has both
assignment and type inference, so it seems like it
At 1:31 PM +0200 7/19/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 8:17 PM +0200 7/13/03, Leopold Toetsch wrote:
I think one Env PMC ought to be enough. And that one may have e.g. an
Iterator ettached, which simplest is done by deriving it from an hash
like PMC.
Potentia
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Rather simple stuff like your code calls into a C library via the NCI
> interface, and that C code does a setenv().
Ah. There is always one more possibility ;-)
> The cost of fetching isn't
> much, and the cache just isn't worth the hassle.
Ok. Then
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)
I think you miss the point. It's not just about flags. It's about how
you do a particular task, which could involve one or more commands (or be
impossible).
See libtool for an idea of the size of the problem.
--Josh
At 18:45 on 07/19/2003 EDT, Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
gcc 3.2 has a bug that makes SArray's shift_* not work when compiled
with optimization. This works around it (and is arguably better style
anyway). gcc will receive a bug report if I can manage to reduce the
problem.
Index: classes/sarray.pmc
25 matches
Mail list logo
