On Monday, January 19, 2004, at 06:37 , Gordon Henriksen wrote:
Dan Sugalski wrote:
For a copying collector to work, all the mutators must be blocked,
and arguably all readers should be blocked as well.
True of non-moving collectors, too. [...]
Some of what I've written up addresses why. [...] I
I did a cvs update, and it looks like imcc doesn't properly return
integers anymore from nonprototyped routines. Or maybe it never did,
and the switchover from nonprototype being the default to prototyped
is what triggered it (because I had to add some explicit
non_prototyped declarations, although
At 12:58 AM + 1/20/04, [EMAIL PROTECTED] wrote:
> =item MUTEX
This is a low level, under the hood, not exposed to users, thing that
can be locked. They're non-recursive, non-read/write, exclusive
things. When a thread gets a mutex, any other attempt to get that
mutex will block until the o
On Jan-15, Melvin Smith wrote:
> At 11:20 AM 1/15/2004 +0100, Leopold Toetsch wrote:
> >Melvin Smith <[EMAIL PROTECTED]> wrote:
> >>
> >> For some reason 1 test in pcc.t is failing (the nci call)
> >
> >Off by one error caused by:
> >
> >> -for (j = 0; j < 4; j++) {
> >
> >> +
Here's another obnoxious test case. I started to try to strip it down,
but it starts working again if I even delete nonsense lines from a
subroutine that is never called. And I'm working on something else and
not at all in the mood to re-learn how to debug parrot internals. It
turns out that I don'
At 03:16 PM 1/19/2004 -0700, Luke Palmer wrote:
Will Coleda writes:
> I didn't expect the code to be very usable, merely compilable. =-)
>
> If I want to call myself from myself, how do I do that then?
>
> For anything else, I do:
>
> .local Sub foo_sub
> newsub foo_sub, .Sub, __foo
>
> .pcc_
Ok. I've converted my code over to do this[1]. I am now able to compile
tcl.imc, but all my code fails to run, ala:
bash-2.05a$ make exit
../../../parrot ../tcl.pbc exit.tcl
branch_cs: illegal resume offsetmake: *** [exit] Error 1
So, I'm trying to track down where this badness is happening:
bas
On Tue, 20 Jan 2004 10:45, Dan Sugalski wrote;
> Yes. The recommendation I've always seen for deadlock avoidance is
> to always have all your code grab its mutexes in some fixed order.
Yes; otherwise, you need to back off and start again, if one lock
acquisition fails.
Consider these functio
Dan Sugalski wrote:
> For a copying collector to work, all the mutators must be blocked,
> and arguably all readers should be blocked as well.
True of non-moving collectors, too. Or, let me put it this way: non-
copying *GC* (the sweep or copy phase) can be threadsafe, but the mark
phase is neve
At 5:32 PM -0500 1/19/04, Gordon Henriksen wrote:
Dan Sugalski wrote:
[A] copying collector is generally untenable in a threaded
environment.
Can you elaborate upon the reasoning behind this statement?
Sure. For a copying collector to work, all the mutators must be
blocked, and arguably all re
Dan Sugalski wrote:
> [A] copying collector is generally untenable in a threaded
environment.
Can you elaborate upon the reasoning behind this statement?
> The first thing that any vtable function of a shared PMC must do is to
> aquire the mutex of the PMCs in its parameter list, in ascending
Will Coleda writes:
> I didn't expect the code to be very usable, merely compilable. =-)
>
> If I want to call myself from myself, how do I do that then?
>
> For anything else, I do:
>
> .local Sub foo_sub
> newsub foo_sub, .Sub, __foo
>
> .pcc_begin prototyped
> .arg $S1
> .pcc_call
# New Ticket Created by Will Coleda
# Please include the string: [perl #25144]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25144 >
The attached .imc file fails to compile with:
borked.imc
Description: Binary data
err
I didn't expect the code to be very usable, merely compilable. =-)
If I want to call myself from myself, how do I do that then?
For anything else, I do:
.local Sub foo_sub
newsub foo_sub, .Sub, __foo
.pcc_begin prototyped
.arg $S1
.pcc_call foo_sub
tellmeagainwhyineedthislabel:
.re
At 2:44 PM -0700 1/19/04, Luke Palmer wrote:
Dan's thread proposal mentions:
=item Automatic PMC sharing will be provided
When a PMC is placed into a container which is shared (including
lexical pads and global namespaces) then that PMC will automatically
be marked as shared. It is acceptable
At 4:37 PM -0500 1/19/04, Uri Guttman wrote:
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> =item All shared PMCs must have a threadsafe vtable
DS> The first thing that any vtable function of a shared PMC must do is to
DS> aquire the mutex of the PMCs in its parameter list, in
Dan's thread proposal mentions:
> =item Automatic PMC sharing will be provided
>
> When a PMC is placed into a container which is shared (including
> lexical pads and global namespaces) then that PMC will automatically
> be marked as shared. It is acceptable for this to trigger an
> exception if f
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> =item All shared PMCs must have a threadsafe vtable
DS> The first thing that any vtable function of a shared PMC must do is to
DS> aquire the mutex of the PMCs in its parameter list, in ascending
DS> address order. When the mutexe
Will Coleda <[EMAIL PROTECTED]> wrote:
> (has a .end) Yup.
> Managed to shrink it down to:
> .pcc_sub __interpret prototyped
>newsub P1, .Sub, __interpret
>.pcc_begin_return
>.return 0
>.pcc_end_return
> .end
Two problems: You are overriding the already existing Sub with that nam
Will Coleda <[EMAIL PROTECTED]> wrote:
> 1 .pcc_sub __interpret prototyped
> 2# An array of commands to interpret.
> 3.param PerlArray orig_commands
Please note that between .pcc_sub and .param nothing is allowed, not even
a comment.
leo
Time to add these in.
I'm going to be adding in the following to the chartype vtable:
upcase
downcase
titlecase
to_chartype
To transform things to upper-case, lowercase, titlecase (initial
capital, basically), and to transform the string to an arbitrary
different chartype.
I'd like to
On Mon, Jan 19, 2004 at 10:34:56PM -0200, Gabor Szabo wrote:
> Actually I think there are frameworks in C# to write such Test::More like
> tests. But if there are not and someone writes a Test::More replacement
> in some other language (C# in our case) then why not write a replacement
> for Test::H
Okay, plan is this:
1) We will adopt ICU's formatting template for numeric formats
2) We'll roll our own to start with.
#1 makes sense--we have to use something, and since we're linking in
ICU but not postgres it makes sense to use the ICU format. I've some
qualms about it since the numeric form
At 3:16 PM -0500 1/19/04, Dan Sugalski wrote:
I've not gotten into the technical bits yet. That's next, but rip
this apart first.
First rip -- I left a section unfinished. It should be:
=item "Process-type" threads
The scheme must also support the perl 5 "iThreads" threading
model. In this model
On Mon, 19 Jan 2004, Ed Summers wrote:
> If you are testing from the cmd line
One of the prime problems of my customers is the fact that I don't give
them a nice GUI for the test tool where they can click.
> the nice thing about Perl's testing
> framework is that it would be feasible to write C#
At 12:16 PM -0800 1/19/04, TOGoS wrote:
Hi.
In IMCC, how can I get the address of a label in a
different compilation unit?
Don't. The only way to transfer control to code in a different
compilation unit (arguably in a different sub in the same compilation
unit) is via invoke or one of its relati
I've not gotten into the technical bits yet. That's next, but rip
this apart first.
=head1 DEFINITIONS
So we can all talk about things the same way, the following
definitons apply. Some of these are drawn from the POSIX thread spec,
and as such we should have a translation section at the end.
=o
At 3:11 PM -0500 1/19/04, Dan Sugalski wrote:
I've not gotten into the technical bits yet. That's next, but rip
this apart first.
Whups, wrong list in the autocomplete. Just a hedge, citizen -- move along!
--
Dan
--"it's l
Hi.
In IMCC, how can I get the address of a label in a
different compilation unit? Is there a way to do this
at compile time? I've looked through the latest docs
but according to imcc/docs/parsing.pod, global labels
get stored in global variables that you must look up
at run time (yuck).
It seems
I've not gotten into the technical bits yet. That's next, but rip
this apart first.
=head1 DEFINITIONS
So we can all talk about things the same way, the following
definitons apply. Some of these are drawn from the POSIX thread spec,
and as such we should have a translation section at the end.
=o
On Mon, Jan 19, 2004 at 06:58:38PM +0200, Gabor Szabo wrote:
> One of them has an application written in .NET with C# and they also want
> to run unit tests, regression tests and load tests. They want to know how
> can we do that in Perl.
>
> Obviously for that I will have a number of Windows boxe
On Mon, 2004-01-19 at 04:11, Leopold Toetsch wrote:
> Harry, do you still see these hanging parrot programs?
> chromatic, do you run a DeadRat (sorry) linux too?
Nope, none here. I can try a different pthread library though.
-- c
(has a .end) Yup.
Managed to shrink it down to:
.pcc_sub __interpret prototyped
newsub P1, .Sub, __interpret
.pcc_begin_return
.return 0
.pcc_end_return
.end
It appears that creating a Sub that refers to the sub you're currently
in is the trigger. If I change the sub name to "foo", it co
At 12:55 PM -0500 1/19/04, Will Coleda wrote:
Though the file contains:
1 .pcc_sub __interpret prototyped
2# An array of commands to interpret.
3.param PerlArray orig_commands
...
392 DONE:
393.debug("final retval is '")
394.debug(retval)
395.debug(
(Thanks for the quick response on the last email)
I have another problem. I have a 405-line file (containing a single
.pcc_sub) that is being included from my main .imc.
I get:
error:imcc:pcc_return not inside pcc subroutine
in file 'lib/interpret.imc' line 397
included from 'tcl.imc'
Stefan Lidman <[EMAIL PROTECTED]> wrote:
[ and yet another f'up ]
I've now comitted a fix for unmakeCOW not to turn off GC. So the test
runs fine now with limited memory. *But*:
Total memory allocated = 532480
DOD runs = 9680
Collect runs = 9660
Collect memory = 1388032592
^
Stefan Lidman <[EMAIL PROTECTED]> wrote:
[ VM Panic ]
> SPLIT:
> substr S3, S1, 0, 1
> substr S1, 0, 1, ""
The mem_allocate happens to be triggered by above string_replace, which
does unmake_COW. During that GC is blocked, so we are allocating
increasing blocks of memory until the
At 11:56 AM 1/19/2004 -0500, Will Coleda wrote:
Trying to get the tcl interpreter working with all the changes in the past
few months:
I used to be able to say:
.pcc_sub _dumper prototyped
.param PMC original
... but now PMC isn't a valid type anymore. Is there another way to get an
IMC
To cl
Le Mon, Jan 19, 2004 at 11:56:28AM -0500, le valeureux mongueur Will Coleda a dit:
> Trying to get the tcl interpreter working with all the changes in the
> past few months:
>
> I used to be able to say:
>
> .pcc_sub _dumper prototyped
> .param PMC original
>
> ... but now PMC isn't a valid t
At 11:56 AM -0500 1/19/04, Will Coleda wrote:
Trying to get the tcl interpreter working with all the changes in
the past few months:
I used to be able to say:
.pcc_sub _dumper prototyped
.param PMC original
... but now PMC isn't a valid type anymore. Is there another way to
get an IMC variabl
Trying to get the tcl interpreter working with all the changes in the
past few months:
I used to be able to say:
.pcc_sub _dumper prototyped
.param PMC original
... but now PMC isn't a valid type anymore. Is there another way to get
an IMC variable name tied to a PMC of indeterminate type? (o
On Mon, 19 Jan 2004, Adrian Howard wrote:
>
> On Monday, January 19, 2004, at 06:10 pm, Gabor Szabo wrote:
>
> > If this is OT, please point me to some better place to find an answer.
> [snip]
>
> Not OT in my opinion, but you also might want to try
> http://groups.yahoo.com/group/TestFirstUserIn
Stefan Lidman <[EMAIL PROTECTED]> wrote:
> readline S1, P1
The implementation of readline looks rather bogus. It allocates a huge
(64K) string, sets that to zero, and the calls read, which calls
readline.
This is really suboptimal. It should probably call PIO_buf_readline or
such directl
Stefan Lidman <[EMAIL PROTECTED]> wrote:
> This is a test for the buffer bug that
> was discussed on p6i a few days ago.
Thanks, fine.
> output_is(<<'CODE', < set S0, "buffTest"
> open P1, S0
open P1, S0, ">"
I don't know, if it should even write the test file w/o tha
On Monday, January 19, 2004, at 06:10 pm, Gabor Szabo wrote:
If this is OT, please point me to some better place to find an answer.
[snip]
Not OT in my opinion, but you also might want to try
http://groups.yahoo.com/group/TestFirstUserInterfaces.
On the functional level:
Basic things can be ac
On Tue, 13 Jan 2004, Paul Cochrane wrote:
> This also gives me an opportunity to mention to anyone with more time (and
> possibly ability) than me, that parrot is having problems on LinuxPPC. The
> specifics are:
> - parrot hangs on t/op/arithmetics when doing make test
> - make gives an
On Mon, 19 Jan 2004, Abe Timmerman wrote:
> If you're interested in that, I can send you a pre-alpha version, although I
> haven't got the time to work on it right now...
Yes, please send it over.
BTW One of the specific things I will have to automate is
OWA - Outlook Web Access which is said t
Op een druilerige winterdag (Monday 19 January 2004 19:10), schreef Gabor
Szabo:
> If this is OT, please point me to some better place to find an answer.
>
> I am looking for a way to functional and load test a web site.
>
> On the functional level:
> Basic things can be achieved by WWW::Mechaniz
On Mon 19 Jan 2004 19:10, Gabor Szabo <[EMAIL PROTECTED]> wrote:
>
> If this is OT, please point me to some better place to find an answer.
>
> I am looking for a way to functional and load test a web site.
POE + WWW::Mechanize
> On the functional level:
> Basic things can be achieved by WWW::M
If this is OT, please point me to some better place to find an answer.
I am looking for a way to functional and load test a web site.
On the functional level:
Basic things can be achieved by WWW::Mechanize but I don't know yet how
to deal with Javascript in the response page.
On the load test:
# New Ticket Created by Stefan Lidman
# Please include the string: [perl #25129]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=25129 >
Hello
This is a test for the buffer bug that
was discussed on p6i a few days ago.
It
Luke Palmer wrote:
Benjamin K. Stuhl writes:
Other than the special case of :readonly, can you give me an example
of when you'd need to, rather than simply writing a PMC class that
inherits from some base? I'm having trouble thinking of an example of
when you'd want to be able to do that... After
Some files have CVS version $Id strings, some don't.
While tidying up the documentation I'm visiting every file. I can
either:
1) add them when missing
2) remove them when present
3) do nothing
I was inclined to (1) until I reflected that it did preserve a relation
between local and repository
Leopold Toetsch wrote:
Harry Jackson <[EMAIL PROTECTED]> wrote:
RHAS 2.1 dev edition
Harry, do you still see these hanging parrot programs?
chromatic, do you run a DeadRat (sorry) linux too?
RedHat is well known to provide b0rken patches to otherwise running
software. Could you try to up/down/s
Harry Jackson <[EMAIL PROTECTED]> wrote:
> RHAS 2.1 dev edition
Harry, do you still see these hanging parrot programs?
chromatic, do you run a DeadRat (sorry) linux too?
RedHat is well known to provide b0rken patches to otherwise running
software. Could you try to up/down/side-grade *libpthread*
Chromatic <[EMAIL PROTECTED]> wrote:
> (gdb) bac
This is the main thread, that has suspended itself during exit
processing.
> #0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0
...
> #3 0x0fd0a694 in exit () from /lib/libc.so.6
> (gdb) thread 2
That's the thread-manager thread
Harry Jackson <[EMAIL PROTECTED]> wrote:
> What are the requirements on the pre-processor.
$ perldoc imcc/docs/macros.pod
$ $(EDITOR) imcc/imcc.l
should provide all necessary information.
leo
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch writes:
> I'm working on yet another scheme at the moment, with a special op that
> pushes and clears simultaneously, to see if I can avoid copying
> altogether! It costs another indirection in the core registers,
That would be a major cha
Jeff Clites <[EMAIL PROTECTED]> wrote:
> But if the "event dispatch" thread is setting some flag for the target
> thread to detect, it's going to need to lock (or something similar) to
> make sure that the value of this flag is visible to other threads.
Yep, that's true. The event thread puts an
59 matches
Mail list logo
