Dan Sugalski <[EMAIL PROTECTED]> wrote:
> No. If any object has a destructor it should be called as the last
> interpreter is shut down. We're not guaranteeing dead-on immediate
> destruction, or if the timely flag isn't set timely destruction, but we
> *are* guaranteeing eventual destruction.
Oh
I fixed a bug in the readline routine that now allows it to act
like it should. With the ability to toggle linebuffering on IO
handles now with pioctl, do we need the explicit readline op
anymore?
-Melvin
Added pioctl op and PIO_pioctl API call. General purpose op for IO manipulation
in tradition of UNIX ioctl call.
This will be the interface for doing all sorts of IO layer stuff such as
buffering, blocking, async, etc. At least until someone has a better
way to do it.
Also added record separator fi
On Mon, Oct 06, 2003 at 12:14:55PM +0100, Tim Bunce wrote:
> Changing statement column header to Statement Executions and removing the
> colour from that column, or changing it to a very pale green, would help.
I'll be attacking the output a little in the next release (0.25). I'll
see what I can
This is mostly a bug fix release.
Hopefully, the problem with tests which chdir has been fixed. If anyone
still sees problems in this area, normally manifest with cover_db
database directories springing up in unexpected places, please let me
know.
Devel::Cover wouldn't run on Windows systems. F
At 11:05 PM 10/9/2003 +0100, Nicholas Clark wrote:
On Wed, Oct 08, 2003 at 06:43:27PM +0200, Leopold Toetsch wrote:
> Melvin Smith <[EMAIL PROTECTED]> wrote:
>
> > I think if you have the op for dereferencing, you don't need the
> > additional ops for
> > getting the type of the reference.
>
> Too
On Thu, Oct 09, 2003 at 09:53:02AM +, Peter Sinnott wrote:
> # New Ticket Created by Peter Sinnott
> # Please include the string: [perl #24169]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=24169 >
>
>
> Hi,
>p
On Wed, Oct 08, 2003 at 06:43:27PM +0200, Leopold Toetsch wrote:
> Melvin Smith <[EMAIL PROTECTED]> wrote:
>
> > I think if you have the op for dereferencing, you don't need the
> > additional ops for
> > getting the type of the reference.
>
> Too true, thanks
Yes, but if you have to go via anot
Thomas Fjellstrom writes:
> On October 9, 2003 09:57 am, Dan Sugalski wrote:
> > On Thu, 9 Oct 2003, Dave Mitchell wrote:
> > > On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> > > > We've got ordered destruction on the big list 'o things to do, and it
> > > > looks like we need to g
On Thu, Oct 09, 2003 at 08:54:10AM +, Martin Mokrejs wrote:
> # New Ticket Created by Martin Mokrejs
> # Please include the string: [perl #24167]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=24167 >
>
>
> Hi,
>
# New Ticket Created by Michael Scott
# Please include the string: [perl #24177]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24177 >
If someone happens to have dlcompat
http://www.opendarwin.org/projects/dlcompa
On October 9, 2003 09:57 am, Dan Sugalski wrote:
> On Thu, 9 Oct 2003, Dave Mitchell wrote:
> > On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> > > We've got ordered destruction on the big list 'o things to do, and it
> > > looks like we need to get that done sooner rather than late
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Hi,
> test_main.c is not used any more.
parrot.c was built all the time and was unused :)
> Shouldn't test_main.c be removed completely? Maybe as part of the big
> imcc-move.
Yep.
> bye
> boe
leo
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> It turned out, that it was even simpler. The explicit sweeping is
> already in the code, but is only triggered if there are objects which
> need _early_ destruction, not if objects just need
> destruction. Removing this test made it work.
Why can't yo
On Thu, 9 Oct 2003, Dave Mitchell wrote:
> On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> > We've got ordered destruction on the big list 'o things to do, and it
> > looks like we need to get that done sooner rather than later. So, this is
> > a good chance for someone to burn tho
On Thu, Oct 09, 2003 at 11:43:41AM -0400, Dan Sugalski wrote:
> We've got ordered destruction on the big list 'o things to do, and it
> looks like we need to get that done sooner rather than later. So, this is
> a good chance for someone to burn those surplus SAN points and become one
> with the gr
We've got ordered destruction on the big list 'o things to do, and it
looks like we need to get that done sooner rather than later. So, this is
a good chance for someone to burn those surplus SAN points and become one
with the great gibbering chaos at the center of the universe (no, wait,
that's no
Dan Sugalski <[EMAIL PROTECTED]> writes:
> > I disagree :) We already have a 2 stage IO destroy. The first shall
> > flush its files. This get called even if destroy-at-end isn't set.
The two stage IO destroy is a problem that we don't have destruction
ordering yet. Closing the standard handles t
On Thu, 9 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > On Thu, 9 Oct 2003, Juergen Boemmels wrote:
>
> >> Hi,
> >>
> >> I just discovered a really subtele bug:
> >> Normaly the test are not run with --destroy-at-end. This has not many
> >> consequences yet because
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Thu, 9 Oct 2003, Juergen Boemmels wrote:
>> Hi,
>>
>> I just discovered a really subtele bug:
>> Normaly the test are not run with --destroy-at-end. This has not many
>> consequences yet because the only PMCs with active destruction are
>> IOs, in fact
Hi,
test_main.c is not used any more. The only references are from make.pl
(which also does not seem to work), a comment in imcc/main.c that it
is mostly stolen from there, and docs/embed.pod giving test_main.c as
an example.
Shouldn't test_main.c be removed completely? Maybe as part of the big
i
Dan Sugalski <[EMAIL PROTECTED]> writes:
[...]
> Option 2 is the right one. (Well, OK, having parrot do an explicit sweep &
> destroy's the right option, but until then...) Go ahead and add a patch to
> whatever you need to make this happen.
It turned out, that it was even simpler. The explicit
On Thu, 9 Oct 2003, Juergen Boemmels wrote:
> Hi,
>
> I just discovered a really subtele bug:
> Normaly the test are not run with --destroy-at-end. This has not many
> consequences yet because the only PMCs with active destruction are
> IOs, in fact only one test is really sensitive to t/pmc/io_4.
docs/parrot_assembly.pod is just an earlier version of PDD 6.
An empowered person should remove it.
Mike
Hi,
I just discovered a really subtele bug:
Normaly the test are not run with --destroy-at-end. This has not many
consequences yet because the only PMCs with active destruction are
IOs, in fact only one test is really sensitive to t/pmc/io_4.pasm, it
won't flush its buffers without --destroy-at-en
# New Ticket Created by Peter Sinnott
# Please include the string: [perl #24169]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24169 >
Hi,
parrot is not currently building on freebsd as it requires
pthread to be includ
# New Ticket Created by Peter Sinnott
# Please include the string: [perl #24168]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24168 >
Hi,
currently gmake seems to be required to build imcc on freebsd.
When using gm
# New Ticket Created by Martin Mokrejs
# Please include the string: [perl #24167]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24167 >
Hi,
I get from my compiler:
cc: Warning:
/software/@sys/usr/lib/perl5/5.8.1/alpha-
28 matches
Mail list logo
