On 11 Apr 2005 16:01:06 -, Dagobert Michelsen wrote:
># https://rt.perl.org/rt3/Ticket/Display.html?id=34914 >
[...]
>I am currently working with an embedded version of Perl 5.8.3 and
>5.8.6 on Solaris together with OpenLDAP 2.2.23.
>
>Perl seems to have a race condition which mixes up filehand
On Mon, Apr 11, 2005 at 06:41:21PM +0100, Nick Ing-Simmons wrote:
> Dave Mitchell <[EMAIL PROTECTED]> writes:
> >No. The called Perl code could in principle do almost anything: open
> >files, create new threads, delete symbol tables etc; doing any of this in
> >mid thread-creation is heading for di
On Mon, Apr 11, 2005 at 06:35:13PM +0100, Nick Ing-Simmons wrote:
> Appart from speed reasons why not do this as an object rather than a
> class (aka static) method?
The calls would all have to be done before cloning starts, and
its a lot easier to temporarily remember a list of "don't" classes t
> > As far as I know NPTL threads are real kernel threads. There is also a
> > gettid
> > syscall in modern linuxes. Maybe it is better to turn off getppid caching
> > for
> > NPTL threads?
They try to be "real" threads, but haven't fully made it yet (for instance,
just try to write a multi-thre
On Apr 11, 2005 8:46 PM, Torsten Foertsch <[EMAIL PROTECTED]> wrote:
> As far as I know NPTL threads are real kernel threads. There is also a gettid
> syscall in modern linuxes. Maybe it is better to turn off getppid caching for
> NPTL threads?
The main problem is that you can switch (afaik) the k
Nick Ing-Simmons wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
The coolest thing about the DONT_CLONE idea, is that now any CPAN
module can be made perl-thread-safe by just adding this method to the
class.
Yes, in any case Nick's suggestion is not backwards compatible. Even if a
new sub name is
Stas Bekman <[EMAIL PROTECTED]> writes:
The coolest thing about the DONT_CLONE idea, is that now any CPAN
module can be made perl-thread-safe by just adding this method to the
class.
>
>Yes, in any case Nick's suggestion is not backwards compatible. Even if a
>new sub name is
On Monday 11 April 2005 19:49, Ton Hospel wrote:
> In article <[EMAIL PROTECTED]>,
>
> Rafael Garcia-Suarez <[EMAIL PROTECTED]> writes:
> > The PPID caching was introduced on Linux to have a more POSIXly-correct
> > (and thus portable) behaviour of getppid() on non-NPTL kernels, because
> > t
Stas Bekman <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons wrote:
>> Stas Bekman <[EMAIL PROTECTED]> writes:
>>
>>>The coolest thing about the DONT_CLONE idea, is that now any CPAN module
>>>can be made perl-thread-safe by just adding this method to the class.
>>
>>
>> So it would be even coole
Elizabeth Mattijsen wrote:
At 1:59 PM -0400 4/11/05, Stas Bekman wrote:
Nick Ing-Simmons wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
The coolest thing about the DONT_CLONE idea, is that now any CPAN
module can be made perl-thread-safe by just adding this method to the
class.
So it would be ev
On Apr 11, 2005 7:49 PM, Ton Hospel <[EMAIL PROTECTED]> wrote:
> How about simply turning off pid caching on non-threaded perls,
it's already turned off (see hints/linux.sh) when useithreads isn't defined.
> and even on threaded perls until you try to start a thread ?
Yes, that's a solution. My
# New Ticket Created by Dagobert Michelsen
# Please include the string: [perl #34914]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34914 >
Hi,
I am currently working with an embedded version of Perl 5.8.3 and
5.8.6 on S
At 1:59 PM -0400 4/11/05, Stas Bekman wrote:
Nick Ing-Simmons wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
The coolest thing about the DONT_CLONE idea, is that now any CPAN
module can be made perl-thread-safe by just adding this method to
the class.
So it would be even cooler (given that most
Nick Ing-Simmons wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
The coolest thing about the DONT_CLONE idea, is that now any CPAN module
can be made perl-thread-safe by just adding this method to the class.
So it would be even cooler (given that most of them are NOT safe)
if the sense was invert
In article <[EMAIL PROTECTED]>,
Rafael Garcia-Suarez <[EMAIL PROTECTED]> writes:
> The PPID caching was introduced on Linux to have a more POSIXly-correct
> (and thus portable) behaviour of getppid() on non-NPTL kernels, because
> the Linux behaviour was to affect new pids to each thread.
>
Stas Bekman <[EMAIL PROTECTED]> writes:
>
>The coolest thing about the DONT_CLONE idea, is that now any CPAN module
>can be made perl-thread-safe by just adding this method to the class.
So it would be even cooler (given that most of them are NOT safe)
if the sense was inverted so that unless CL
In article <[EMAIL PROTECTED]>,
Rafael Garcia-Suarez <[EMAIL PROTECTED]> writes:
> Ok, select() now returns undef on error as of change #24223.
/me raises the backward compatibility police card
For what it's worth, I think this is a bad idea.
First of all it basically breaks the erro
Dave Mitchell <[EMAIL PROTECTED]> writes:
>On Mon, Apr 11, 2005 at 03:07:54PM +0200, Elizabeth Mattijsen wrote:
>> I _can_ take no for an answer, but want to make sure that we're
>> dismissing this for the right reasons.
>
>fair enough:-)
>
>> >a) Perl-level functions can't be called during the mi
Dave Mitchell <[EMAIL PROTECTED]> writes:
>On Wed, Apr 06, 2005 at 11:02:49PM -0400, Stas Bekman wrote:
>> It's time to write CLONE2 which should be a method, identical to DESTROY,
>> which should be called by perl_clone(), when it sees that the
>> object->can('CLONE2').
>
>After some chatting wi
On Mon, Apr 11, 2005 at 05:25:19PM +0100, Alberto Manuel Brandão Simões wrote:
> Meanwhile, Encode could simplify my life, but I think it is just
> available for 5.8.x. Is this correct?
This is correct.
Doing Unicode with 5.6.x (or even 5.8.0) isn't a good idea. Too many bugs.
Nicholas Clark
Elizabeth Mattijsen wrote:
At 11:34 AM -0400 4/11/05, Stas Bekman wrote:
Elizabeth Mattijsen wrote:
[...]
Hmmm... wouldn't it be handier to have a method CLONED() which is
called for each object (and with the object as parameter) and which
is expected to return a cloned objects, ready to be used
Hi!
I have a module with lot of Encoding problems (just don't know why, and
maybe its fault of the modules I use).
Meanwhile, Encode could simplify my life, but I think it is just
available for 5.8.x. Is this correct?
Thanks.
Alberto
--
Alberto Simões - Departamento de Informática - Universidad
Attached are some cleanups of things that GCC complains about. There
are others on my todo list, like how perlio.c causes all sorts of
squawks.
GCC did report a place where ext/B/B.xs can fall through uninitialized.
* ext/B/B.xs: Hid a couple of static functions, and consted some vars.
Added an
At 11:34 AM -0400 4/11/05, Stas Bekman wrote:
Elizabeth Mattijsen wrote:
[...]
Hmmm... wouldn't it be handier to have a method CLONED() which is
called for each object (and with the object as parameter) and which
is expected to return a cloned objects, ready to be used inside the
thread? If it
Elizabeth Mattijsen wrote:
[...]
Hmmm... wouldn't it be handier to have a method CLONED() which is called
for each object (and with the object as parameter) and which is expected
to return a cloned objects, ready to be used inside the thread? If it
returns undef, then the object should not be c
On Fri, Apr 08, 2005 at 03:01:53PM +0100, Dave Mitchell wrote:
> On Fri, Apr 08, 2005 at 02:20:56PM +0100, Nicholas Clark wrote:
> > Does anyone understand why/how the debugger code wants to save the value
> > of the IV slot inside an IV? Both are conditional on PERLDB_SUB_NN being
> > true:
>
> P
Rafael Garcia-Suarez wrote:
Steve Peters wrote:
Why define a method to return a negative value ? DONT_CLONE() that returns
true seems more logical.
The only problem with DONT_CLONE() is the old issue with negative logic
functions (i.e. return true when false). Thinking in double negatives
is usua
Perl5 Bug Summary
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
Generated at Mon Apr 11 13:00:05 2005 GMT
---
* Total Issues
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors wi
On Mon, Apr 11, 2005 at 04:18:43PM +0200, Rafael Garcia-Suarez wrote:
> Steve Peters wrote:
> > >
> > > Why define a method to return a negative value ? DONT_CLONE() that returns
> > > true seems more logical.
> >
> > The only problem with DONT_CLONE() is the old issue with negative logic
> > fu
At 3:09 PM +0100 4/11/05, Dave Mitchell wrote:
On Mon, Apr 11, 2005 at 03:07:54PM +0200, Elizabeth Mattijsen wrote:
> >a) Perl-level functions can't be called during the middle of cloning,
>as the internal state isn't yet consistent.
I guess some putting these objects to be vivified inside the t
Steve Peters wrote:
> >
> > Why define a method to return a negative value ? DONT_CLONE() that returns
> > true seems more logical.
>
> The only problem with DONT_CLONE() is the old issue with negative logic
> functions (i.e. return true when false). Thinking in double negatives
> is usually co
On Mon, Apr 11, 2005 at 03:07:54PM +0200, Elizabeth Mattijsen wrote:
> I _can_ take no for an answer, but want to make sure that we're
> dismissing this for the right reasons.
fair enough:-)
> >a) Perl-level functions can't be called during the middle of cloning,
> >as the internal state isn't y
On Mon, Apr 11, 2005 at 01:38:51PM +0200, Rafael Garcia-Suarez wrote:
> Dave Mitchell wrote:
> > On Wed, Apr 06, 2005 at 11:02:49PM -0400, Stas Bekman wrote:
> > > It's time to write CLONE2 which should be a method, identical to DESTROY,
> > > which should be called by perl_clone(), when it sees t
At 1:30 PM +0100 4/11/05, Dave Mitchell wrote:
On Mon, Apr 11, 2005 at 01:54:57PM +0200, Elizabeth Mattijsen wrote:
Hmmm... wouldn't it be handier to have a method CLONED() which is
called for each object (and with the object as parameter) and which
is expected to return a cloned objects, ready
On Mon, Apr 11, 2005 at 01:54:57PM +0200, Elizabeth Mattijsen wrote:
> Hmmm... wouldn't it be handier to have a method CLONED() which is
> called for each object (and with the object as parameter) and which
> is expected to return a cloned objects, ready to be used inside the
> thread? If it re
On Mon, Apr 11, 2005 at 01:54:57PM +0200, Elizabeth Mattijsen wrote:
> Hmmm... wouldn't it be handier to have a method CLONED() which is
> called for each object (and with the object as parameter) and which
> is expected to return a cloned objects, ready to be used inside the
> thread? If it r
At 1:38 PM +0200 4/11/05, Rafael Garcia-Suarez wrote:
Dave Mitchell wrote:
On Wed, Apr 06, 2005 at 11:02:49PM -0400, Stas Bekman wrote:
> It's time to write CLONE2 which should be a method, identical to DESTROY,
> which should be called by perl_clone(), when it sees that the
> object->can('CLON
Dave Mitchell wrote:
> On Wed, Apr 06, 2005 at 11:02:49PM -0400, Stas Bekman wrote:
> > It's time to write CLONE2 which should be a method, identical to DESTROY,
> > which should be called by perl_clone(), when it sees that the
> > object->can('CLONE2').
>
> After some chatting with Stas, we've
On Wed, Apr 06, 2005 at 11:02:49PM -0400, Stas Bekman wrote:
> It's time to write CLONE2 which should be a method, identical to DESTROY,
> which should be called by perl_clone(), when it sees that the
> object->can('CLONE2').
After some chatting with Stas, we've come to the conclusion that what
On Mon, 11 Apr 2005 12:07:46 +0100, Steve Hay <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
>
> >After a request from Steve Peters, I've implemented a new probe to
> >Configure.
> >
> >Configure checks for libm/math.h to support _LIB_VERSION
> >For now, Cygwin and Linux do, and HP-UX and AIX
H.Merijn Brand wrote:
>After a request from Steve Peters, I've implemented a new probe to Configure.
>
>Configure checks for libm/math.h to support _LIB_VERSION
>For now, Cygwin and Linux do, and HP-UX and AIX do not
>
>Since I do not know what VMS and Win32 support, and autoprobing might not be
>
On Mon, Apr 11, 2005 at 11:37:43AM +0100, Tim Bunce wrote:
> If assignments to SvIVX() are to be replaced with SVIV_set() then any
> extensions that assign to SvIVX() will also need to be changed to use
> SVIV_set().
I wasn't planning on forcing that.
Just warning that it would be less efficient.
On Sun, Apr 10, 2005 at 08:31:48PM -0500, Steve Peters wrote:
> On Sun, Apr 10, 2005 at 10:54:01PM +0100, Tim Bunce wrote:
> > On Thu, Apr 07, 2005 at 01:51:49PM -0500, Steve Peters wrote:
> > > Attached is the second in a series of patches to migrate the Perl core
> > > to using the Sv*_set() macr
On Mon, 11 Apr 2005 11:13:23 +0100, Steve Hay <[EMAIL PROTECTED]> wrote:
> H.Merijn Brand wrote:
>
> >Change 24217 by [EMAIL PROTECTED] on 2005/04/10 17:08:36
> >
> >Configure now probes for _LIB_VERSION support in math.h/libm
> >LIBM_LIB_VERSION is defined if it does
> >
> >Affec
Rafael Garcia-Suarez wrote:
>I notice also that PerlIO::encoding doesn't seem to be built. Any reason ?
>
PerlIO::encoding is built. It seems that the EXTENSION_C and
EXTENSION_DLL macros in the Win32 makefiles are only used for cleaning
stuff up. They don't actually determine which extensions
Hernan Perez Masci wrote:
>
> I'm attaching a patch to add the other missing comment to the same pod file
> (the one already patched by Rafael).
Thanks, applied to bleadperl as change #24224.
H.Merijn Brand wrote:
>Change 24217 by [EMAIL PROTECTED] on 2005/04/10 17:08:36
>
>Configure now probes for _LIB_VERSION support in math.h/libm
>LIBM_LIB_VERSION is defined if it does
>
>Affected files ...
>
>... //depot/perl/Configure#575 edit
>... //depot/perl/Porting/config_H#16
On Apr 11, 2005 12:08 PM, Steve Hay <[EMAIL PROTECTED]> wrote:
> Math::BigInt::FastCalc builds, tests and cleans OK with this patch.
> Thanks. I should've added that myself.
>
> However, I18N::LangInfo doesn't. It is skipped from the build process
> by win32/FindExt.pm, so your patch would have
Rafael Garcia-Suarez wrote:
>I've applied the change below to the Windows makefiles.
>
>I'd like to know why I18N::Langinfo wasn't built (apparently) on
>Windows, and if the new extensions build correctly, and if "make
>distclean" works... I'm kind of shooting in the dark here.
>
>
Math::BigInt:
Rick Delaney wrote:
> On Thu, Apr 07, 2005 at 08:40:35AM -0700, Yitzchak Scott-Thoennes wrote:
> > On Thu, Apr 07, 2005 at 03:54:45PM +0200, Rafael Garcia-Suarez wrote:
> > >
> > > That's right, however returning 0 on non-error makes sense (see select(2))
> >
> > "0 but true", given the code Gisl
Torsten Foertsch wrote:
>
> my edition of "Programming Perl" states while explaining getpid(): "On the
> typical UNIX system, if your parent process ID changes to 1, it means your
> parent process has died ...".
>
> With modern Perls this is not true because Perl is caching the result of the
> ge
Hi,
my edition of "Programming Perl" states while explaining getpid(): "On the
typical UNIX system, if your parent process ID changes to 1, it means your
parent process has died ...".
With modern Perls this is not true because Perl is caching the result of the
getppid syscall. Once called subsequ
I've applied the change below to the Windows makefiles.
I'd like to know why I18N::Langinfo wasn't built (apparently) on
Windows, and if the new extensions build correctly, and if "make
distclean" works... I'm kind of shooting in the dark here.
Change 24222 by [EMAIL PROTECTED] on 2005/04/11 07:0
53 matches
Mail list logo
