With cvs-latest (9 months later) - the compile works, but the execution fails.
IMCC isn't happy with a .local outside of a sub in RT_initialize.imc, and I think
nested
subs are no longer kosher.
Should I close the call pending a catchup from BASIC with cvs-current?
[leo - Sat Jul 05
Ugh. No more coffee at night!
On the plus side, we're now at 87 new parrot calls, and 38 open calls.
(down from about 150 open calls when I started looking at the queue) (a
good chunk of them were due to a very large influx of spam recently,
which Robert cleared me to get rid of - but there
Will Coleda [EMAIL PROTECTED] wrote:
Josh - if you still want libimcc and it's not there, can you open a
separate ticket?
libparrot hat it all - obsolete.
leo
Will Coleda [EMAIL PROTECTED] wrote:
Attached, find a .tgz that can be exploded in the top level of parrot
which creates the abstract pmc tclobject, with children TclString,
TclInt, TclFloat, and container pmcs TclList (an array) and
TclArray (a hash).
Can we put these PMCs into dynclasses?
Will Coleda [EMAIL PROTECTED] wrote:
Subject: [perl #22767] IMCC/Parrot leak and eventual segfault
Dan, Leo - Can you dig through the long thread here and figure out if
we can close this
call? If there's something left to do, it's above and beyond the
original call, and might be
better off
Will Coleda [EMAIL PROTECTED] wrote:
Subject: [perl #28182] thr-primes.imc segfaults
Created: 2004-04-09 03:37:00
Content: Per Leo, this was fixed in a recent patch -
However, I still get a segfault with an update, realclean, reconfig,
remake (OSX)
Works fine here. Do t/pmc/threads.t pass?
Will Coleda [EMAIL PROTECTED] wrote:
Ugh. No more coffee at night!
On the plus side, we're now at 87 new parrot calls, and 38 open calls.
(down from about 150
Thanks, great
leo
Jens Rieks [EMAIL PROTECTED] wrote:
one can not use the same method name in two different namespaces, if
they have the same number of arguments. Please have a look at the
attached patch for an example.
Thanks for reporting, fixed. (Test will follow later).
jens
leo
# New Ticket Created by Bryan C. Warnock
# Please include the string: [perl #28383]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28383
The email address of record has only been defunct for a year and a half
or
Hi,
I know that I'm getting on everybodies nerves by now, but I got a bunch of new
tests today, mainly sparc64. It's a little bit like collecting stamps,
collecting parrot tests :-).
I actually do a more or less comprehensive stats on
http://www.luusa.org/~marcus/parrottest
by now.
Sparc on
On Thu, 2004-04-08 at 21:14, Robert Spier wrote:
b) Is it kosher/proper to update email references in it?
Sure.
Disagreement. This makes it harder to find relevant email messages in
the archives.
Excellent point.
(Ignore that section of my previously posted patch.)
--
Bryan C.
I've sent my patch in through RT--it's [perl #28405]!
JEff
Thanks to Will Coleda, I finally added docs/submissions.pod - how to
submit bug reports, patches and new files to Parrot.
Mike
I've put in the new scheme for initializer calls.
To test it, set the environment variable CALL__BUILD to some value.
Sample code to set an initializer to _new
new P10, .PerlString
set P10, _new
newclass P1, Foo
setprop P1, BUILD, P10
The BUILD initializer is called for all
Jens Rieks [EMAIL PROTECTED] wrote:
On Wednesday 07 April 2004 17:42, Leopold Toetsch wrote:
Further, in CrawRead P1 is stored away (and invoked later), which
isn't allowed. But cloning it doesn't help because the continuation
context is still wrong.
I've this now running.
$ ../parrot -t
Hi,
On Friday 09 April 2004 14:03, Leopold Toetsch wrote:
Jens Rieks [EMAIL PROTECTED] wrote:
On Wednesday 07 April 2004 17:42, Leopold Toetsch wrote:
Further, in CrawRead P1 is stored away (and invoked later), which
isn't allowed. But cloning it doesn't help because the continuation
Hi,
On Thursday 08 April 2004 23:49, Tim Bunce wrote:
On Thu, Apr 08, 2004 at 08:28:49PM +0200, Jens Rieks wrote:
Data::Replace replaces every occurrence of one PMC in a nested data
structure with another PMC.
I'm not sure what that means, but Data::Replace seems too vague.
What is it?
if
Mike Scott [EMAIL PROTECTED] wrote:
=head1 How To Submit A Patch
Could you pleae add a sentence, that patches should be generated from
parrot root (or one below), so that they apply with -p[01]. Maybe an
example wouldn't hurt.
Thanks,
leo
Marcus Thiesen wrote:
Hi,
I know that I'm getting on everybodies nerves by now, but I got a bunch of new
tests today, mainly sparc64.
Ehem, no. More the opposite.
... It's a little bit like collecting stamps,
collecting parrot tests :-).
Yep. the reason for PLATFORMS too ;)
Sounds like a deep version of map...
Regards,
-- Gregor
On Fri, 2004-04-09 at 06:02, Jens Rieks wrote:
Hi,
On Thursday 08 April 2004 23:49, Tim Bunce wrote:
On Thu, Apr 08, 2004 at 08:28:49PM +0200, Jens Rieks wrote:
Data::Replace replaces every occurrence of one PMC in a nested data
Jens Rieks [EMAIL PROTECTED] wrote:
There is also a new Stream::Writer,
Wasn't The Plan to move over to runtime/parrot/lib or library?
jens
leo
Jeff Clites [EMAIL PROTECTED] wrote:
I've sent my patch in through RT--it's [perl #28405]!
Phew, that's huge. I'd really like to have smaller patches that do it
step by step. But anyway, the patch must have been a lot of work so
lets see and make the best out of it.
Some questions:
First:
-
At 4:19 PM +0200 4/9/04, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I've sent my patch in through RT--it's [perl #28405]!
Phew, that's huge. I'd really like to have smaller patches that do it
step by step. But anyway, the patch must have been a lot of work so
lets see and make
At 3:37 AM -0700 4/9/04, Jeff Clites (via RT) wrote:
2) I need for someone Windows-build-savvy to take a look at
config/gen/icu.pl, and update the MS VC++ requires special treatment
section to implement any changes required to get parrot to link ICU on
Windows (if changes are necessary). I
On Friday 09 April 2004 15:48, Leopold Toetsch wrote:
Wasn't The Plan to move over to runtime/parrot/lib or library?
Hmm, good question.
I'm waiting for a final decision where everyting should be moved to.
I vote for:
- runtime/parrot/library
- t/library
If parrot is modified to search files in
On Apr 9, 2004, at 8:07 AM, Dan Sugalski wrote:
At 4:19 PM +0200 4/9/04, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I've sent my patch in through RT--it's [perl #28405]!
Phew, that's huge. I'd really like to have smaller patches that do it
step by step. But anyway, the patch
Dan Sugalski wrote:
But... this gets us very much closer to where we want to be, and I'm
figuring that we're better off applying this and working out the kinks
than not. I'll leave this one to Leo to make final decision on, though.
Thanks Dan for this easter egg :)
Intermediate results:
-
At 6:29 PM +0200 4/9/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
But... this gets us very much closer to where we want to be, and
I'm figuring that we're better off applying this and working out
the kinks than not. I'll leave this one to Leo to make final
decision on, though.
Thanks Dan for
At 9:20 AM -0700 4/9/04, Jeff Clites wrote:
On Apr 9, 2004, at 8:07 AM, Dan Sugalski wrote:
At 4:19 PM +0200 4/9/04, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I've sent my patch in through RT--it's [perl #28405]!
Phew, that's huge. I'd really like to have smaller patches that
On Fri, 9 Apr 2004, Leopold Toetsch wrote:
Marcus Thiesen wrote:
BTW, I noted that the Parrot PLATFORM file gives more information than
the information I actually collect (like big,lil endian, threaded and
so on). Why doesn't Configure.pl give a comprehension at the end to
show all
Dan Sugalski [EMAIL PROTECTED] wrote:
At 6:29 PM +0200 4/9/04, Leopold Toetsch wrote:
I'll not apply it before tomorrow, though. (If not someone else were faster :)
If you want it in I can commit it now--I've a local version and big
enough pipe for it not to be a big deal.
Put it in. We'll
At 9:59 PM +0200 4/9/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
At 6:29 PM +0200 4/9/04, Leopold Toetsch wrote:
I'll not apply it before tomorrow, though. (If not someone else
were faster :)
If you want it in I can commit it now--I've a local version and big
enough pipe
Once we get the ICU patch all nailed down and working, perhaps it's
time to start a push to 0.1.1. (Or 0.2.0, I guess, if we deem it
sufficiently worth it)
--
Dan
--it's like this---
Dan Sugalski
-Original Message-
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Friday, April 09, 2004 1:45 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: ICU incorporation and string changes heads-up
At 9:59 PM +0200 4/9/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL
At 1:55 PM -0700 4/9/04, Adam Thomason wrote:
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Done. It'll guaranteed kill half the tinderboxen--I think my first
thing to do on monday is to patch up the build procedure to use the
system ICU if it's available.
Does this mean you're resigned to
On Apr 9, 2004, at 7:19 AM, Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
I've sent my patch in through RT--it's [perl #28405]!
Phew, that's huge. I'd really like to have smaller patches that do it
step by step.
Yes, I know it got quite large--sorry about that, I know it makes
On Apr 9, 2004, at 9:29 AM, Leopold Toetsch wrote:
Dan Sugalski wrote:
But... this gets us very much closer to where we want to be, and I'm
figuring that we're better off applying this and working out the
kinks than not. I'll leave this one to Leo to make final decision on,
though.
Thanks Dan
On Apr 9, 2004, at 2:00 PM, Dan Sugalski wrote:
At 1:55 PM -0700 4/9/04, Adam Thomason wrote:
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Done. It'll guaranteed kill half the tinderboxen--I think my first
thing to do on monday is to patch up the build procedure to use the
system ICU if
Hi,
I'm having a crack at getting the ICU changes building on Win32. Here's the
first step. string.c did some C99 stuff:-
* Declared variables at places other than the top of a block
* Used uint8_t, uint16_t, uint32_t, which we don't exists in MS VC++
The attached patch fixes these plus
Hi,
On Friday 09 April 2004 23:11, Jeff Clites wrote:
Hmm, I'll need to figure out how to turn on warnings about this in gcc.
I would expect some unused warning as well.
-Wshadow and -Wunused
-Wuninitialized and -Wunreachable-code can also help
jens
Reminder, when submitting bugs/patches, please use the RT mailing
interface. info at: http://xrl.us/bvho (parrotcode.org) - for patches,
but I think bugs go in the same way (except s/PATCH/BUG/, of course.)
This will help on the rare cases where Leo is asleep, which I'm
beginning to think
On Fri, 2004-04-09 at 04:56, Leopold Toetsch wrote:
I've put in the new scheme for initializer calls.
To test it, set the environment variable CALL__BUILD to some value.
Sample code to set an initializer to _new
new P10, .PerlString
set P10, _new
newclass P1, Foo
I submitted the patch below my sig way back in August 2002, in ticket
16622. It documented the then-current naming conventions for
structures. Is it still accurate and/or a good idea? Should it (or an
up-to-date version of it) be committed?
(It's almost certainly been line-wrapped in this
43 matches
Mail list logo
