Apologies again for this test, I'm tracking down reports that
attachements aren't getting through the list and getting to the
bugtracker.
It helps if I actually attach the temp file.
temp
Description: Binary data
Apologies for this test, I'm tracking down reports that attachements
aren't getting through the list and getting to the bugtracker.
-R
Melvin Smith wrote:
> I'm curious, is it possible to carve out an "ICU-lite" in ANSI-C89?
It is possible, but it depends on what you want. From what I understand,
the ICU common library would cover most of your basic Unicode needs, and
most of the effort could be put there.
As I recall, the fol
Aplogies if this has already been discussed, but I haven't been following
p6i too closely of late (the lure of being allowed to mess with 5.7.3
has been too strong :-)
Anyway, I presume that the Perl6 theading model will be like Perl 5
ithreads - that is to say, each thread has its own interprete
> > When I was working on HotSpot JVM, we had some problems with getcontext.
> > They work 99.99% of time. We added many workaround for the .01% cases. I
> > believe the Solaris guys have been improving the code. I am not sure of
> > the current status.
>
> Was that inside of a signal handler or
> *) Expect POSIX's dead-stupid mutexes to magically unlock
Hmmm, are we confident that we can write exception handling and stack
rollback code that will always clean up mutexes?
--
"There's something wrong with our bloody ships today, Chatfield."
Admiral Beatty at the Battle of Jutland, 31st M
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
On Wed, 29 May 2002, Hong Zhang wrote:
> > > I used to be at Sun. I knew those warnings too. If we use longjmp
> > > carefully, we can make it. In the worst case, write our own version.
> >
> > ..Or we could use setcontext/getcontext, could we not?
>
> The setcontext/getcontext will be much worse
> > I used to be at Sun. I knew those warnings too. If we use longjmp
> > carefully, we can make it. In the worst case, write our own version.
>
> ..Or we could use setcontext/getcontext, could we not?
The setcontext/getcontext will be much worse than setjmp/longjmp.
The are more platform specif
On Wed, 29 May 2002, Hong Zhang wrote:
> > Actually I'd been given dire warnings from some of the Solaris folks.
> > "Don't use setjmp with threads!"
> >
> > I've since gotten details, and it's "Don't use setjmp with threads
> > and do Stupid Things."
>
> I used to be at Sun. I knew those warning
> Actually I'd been given dire warnings from some of the Solaris folks.
> "Don't use setjmp with threads!"
>
> I've since gotten details, and it's "Don't use setjmp with threads
> and do Stupid Things."
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it.
At 2:24 PM -0500 5/29/02, David M. Lloyd wrote:
>But in that case I agree with Dan's
>analysis that flags should be used for signal handling just because
>writing portable signal handling code that does much more (in a
>potentially threaded environment) than that is very complicated.
Right, this
> I've checked with some Sun folks. My understanding is that if you
> don't do a list of what I'd consider obviously stupid things like:
>
> *) longjmp out of the middle of an interrupt handler
> *) longjmp across a system call boundary (user->system->user and the
> inner jumps to the outer)
>
On Wed, May 29, 2002 at 03:23:41PM -0400, Dan Sugalski wrote:
> At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
> >On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
> >> Parrot has to handle signals, such as SIGSEGV.
> >
> >That's the one signal I really hope parrot *doesn't* handle.
>
Mike,
The GC benchmarks officially count as a Good Thing, and Daniel's
committed them to the repository. If other folks have benchmark
things (Even, or especially, long running and reasonably stressful
code) we can commit them as well, so we can have some handle as to
how we're performing as
At 5:47 PM -0700 5/28/02, Hong Zhang wrote:
> > Okay, i've thought things over a bit. Here's what we're going to do
>> to deal with infant mortality, exceptions, and suchlike things.
>>
>> Important given: We can *not* use setjmp/longjmp. Period. Not an
>> option--not safe with threads. At thi
At 10:53 AM +0100 5/29/02, Dave Mitchell wrote:
>On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
>> Parrot has to handle signals, such as SIGSEGV.
>
>That's the one signal I really hope parrot *doesn't* handle.
What, you don't think we should wedge ourselves into the system MMU
hand
On Wed, 29 May 2002, Mike Lambert wrote:
> Hey all,
>
> After finding out that life.pasm only does maybe 1KB per collection, and
> Sean reminding me that there's more to GC than life, I decided to create
> some pasm files testing specific behaviors.
>
> Attached is what I've been using to test a
On Wed, 29 May 2002, Jerome Vouillon wrote:
> On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
> > Dan may have been referring to the fact that on some key platforms
> > (Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
> > use inside of threads.
>
> Is it
At 8:24 PM +0200 5/29/02, Jerome Vouillon wrote:
>On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
>> Dan may have been referring to the fact that on some key platforms
>> (Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
>> use inside of threads.
>
>Is i
At 7:15 AM + 5/29/02, Mike Lambert (via RT) wrote:
>We win on the header-intensive stuff. Not sure why it would be slower on
>the gc_header_new tests. My best guess is that we know are touching the
>contents of the buffer header, which we weren't doing before. And when we
>allocate a bunch of
> > > gc_alloc_new.pbc
> > > gc_alloc_reuse.pbc
> >
> > I don't think these two tests are very interesting. They allocate
> > quite large strings, so they don't put much strain on the GC.
> > Instead, they measure how fast Parrot is at copying strings.
>
> I believe that's a very good thing to be
> > gc_alloc_new.pbc
> > gc_alloc_reuse.pbc
>
> I don't think these two tests are very interesting. They allocate
> quite large strings, so they don't put much strain on the GC.
> Instead, they measure how fast Parrot is at copying strings.
I believe that's a very good thing to be testing. If the
On Wed, May 29, 2002 at 11:45:45AM -0500, David M. Lloyd wrote:
> Dan may have been referring to the fact that on some key platforms
> (Solaris included) (sig)setjmp/longjmp are officially marked as unsafe for
> use inside of threads.
Is it really unsafe on these platforms?
- According to the Uni
On Tue, 28 May 2002, Hong Zhang wrote:
> > Important given: We can *not* use setjmp/longjmp. Period. Not an
> > option--not safe with threads. At this point, having considered the
> > alternatives, I wish it were otherwise but it's not. Too bad for us.
>
> I think this statement is not very accur
Dan Sugalski wrote:
> Cool. Can we have a URL when it's done? (An english translation'd be
> keen too, but there's always BabelFish to mangle the heck out of it)
Sure. Currently it looks like it'll be published August or September.
--
Sebastian Bergmann
http://sebastian-bergmann.de/
On Tue, May 28, 2002 at 11:02:05AM -0400, [EMAIL PROTECTED] wrote:
> I also agree its funny we are worrying
> about performance when its not apparent
> the allocation overhead even has anything
> to do with the current performance problem.
I don't think performance is really the issue here. Rath
Now I attached all the files :)
I also added now the target disassemble, it will emit on stdout the
disassemble of a pbc, this output is (should be) ready to assemble.
(it might have some issues with strings).
Daniel Grunblatt.
On 27 May 2002, Daniel Grunblatt wrote:
> # New Ticket Created by
On Tue, May 28, 2002 at 05:47:56PM -0700, Hong Zhang wrote:
> > Important given: We can *not* use setjmp/longjmp. Period. Not an
> > option--not safe with threads. At this point, having considered the
> > alternatives, I wish it were otherwise but it's not. Too bad for us.
>
> I think this stat
At 11:17 AM +0200 5/24/02, Sebastian Bergmann wrote:
> Hello there!
>
> I'm currently preparing an article on Parrot for a German magazine.
Cool. Can we have a URL when it's done? (An english translation'd be
keen too, but there's always BabelFish to mangle the heck out of it)
> While des
On Wed, May 29, 2002 at 02:08:25AM -0400, Mike Lambert wrote:
> gc_alloc_new.pbc
> allocates more and more memory
> checks collection speed, and the ability to grow the heap
>
> gc_alloc_reuse.pbc
> allocates more memory, but discards the old
> checks collection speed, and the ability to reclaim
On Tue, May 28, 2002 at 07:35:43PM -0700, Hong Zhang wrote:
> Parrot has to handle signals, such as SIGSEGV.
That's the one signal I really hope parrot *doesn't* handle.
Dave.
--
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.
> Results are:
> before after
> gc_alloc_new.pbc 4.1559990.18
>
> gc_alloc_new seems to have improved a *lot*. This is because
> gc_alloc_new allocates a lot of memory using the same headers. It
> doesn't tear through headers quickly enou
> I've modified his patch to remove some unnecessary calculations.
>
> before after
> gc_alloc_new.pbc 4.1559993.756002
> gc_alloc_reuse.pbc16.574 9.423002
> gc_generations.pbc4.025 5.278002
> gc
# New Ticket Created by Mike Lambert
# Please include the string: [netlabs #642]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=642 >
This patch, also from Peter's recent patch, ensures that the destination
pool is betw
# New Ticket Created by Mike Lambert
# Please include the string: [netlabs #636]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=636 >
Peter's latest patch also included changes to the logic in terms of what
to do when w
36 matches
Mail list logo
