I'm attaching a patch which adds a "lint" target to the makefile (running
lclint with some very lenient settings) and fixes some of the things it
was griping about.
The changes are all pretty trivial, and fall into the following categories:
- handle return values which were being ignored (
Here's a fixed version of that patch I sent a while back:
Index: Parrot/Opcode.pm
===
RCS file: /home/perlcvs/parrot/Parrot/Opcode.pm,v
retrieving revision 1.7
diff -u -r1.7 Opcode.pm
--- Parrot/Opcode.pm2001/09/20 14:39:17
Dan Sugalski:
# At 04:40 PM 9/28/2001 -0700, Brent Dax wrote:
# >Simon Cozens:
# ># On Fri, Sep 28, 2001 at 12:55:08PM -0400, Pat Eyler wrote:
# ># > On Fri, 2001-09-28 at 12:31, Will Coleda wrote:
# ># > > Due to a bad case of congenital insanity, I have
# ># developed a barely
# ># > > functiona
I'm playing around with running lclint on the current parrot code. I am
not sure of the best fix for one of the problems it's uncovered. All the
functions in memory.c expect IV's as parameters rather than size_t. This
results in a lint warning wherever sizeof() is used to supply that
para
What's the state of the coding standards? This is the last draft of it
i've noticed in the archives:
http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html
Is this going to become a PDD or at least move into the doc directory for
parrot?
--Josh
--
Josh Wilmes ([EMAIL PR
On Sat, Sep 29, 2001 at 05:22:41AM +0200, Buggs wrote:
> if(sin(1) == sin(1.0))
The ubc cc has sin(1) as being 0.000. You have to cast it to a
double. SunPRO handles it fine.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[
On Saturday 29 September 2001 04:45, Gibbs Tanton - tgibbs wrote:
> In perl sin(1) != sin(1.0) or in C or in both?
>
> Also, what version of the OS is this, SunOS 5.8 works fine.
Perl equal and C not equal, that is.
bash-2.03$ perl -le 'if(sin(1) == sin(1.0)){print "equal"}else{print "not equal"
In perl sin(1) != sin(1.0) or in C or in both?
Also, what version of the OS is this, SunOS 5.8 works fine.
-Original Message-
From: Andreas "Buggs" Hauser
To: [EMAIL PROTECTED]
Sent: 9/28/2001 8:07 PM
Subject: Solaris problems with trans.t
Hoi,
the solaris math functions(sin() ...)
do
At 04:40 PM 9/28/2001 -0700, Brent Dax wrote:
>Simon Cozens:
># On Fri, Sep 28, 2001 at 12:55:08PM -0400, Pat Eyler wrote:
># > On Fri, 2001-09-28 at 12:31, Will Coleda wrote:
># > > Due to a bad case of congenital insanity, I have
># developed a barely
># > > functional tcl to pasm compiler.
># >
Hoi,
the solaris math functions(sin() ...)
do not return the same value as perl when
called with an integer.
This causes the trans.t to fail.
On solaris sin(1) != sin(1.0).
Buggs
Simon Cozens:
# On Fri, Sep 28, 2001 at 12:55:08PM -0400, Pat Eyler wrote:
# > On Fri, 2001-09-28 at 12:31, Will Coleda wrote:
# > > Due to a bad case of congenital insanity, I have
# developed a barely
# > > functional tcl to pasm compiler.
# >
# > Okay, I'll step up now too. I'm working on a ru
At 11:56 PM 9/28/2001 +0100, Alan Burlison wrote:
> > > or have entered a mutex,
> >
> > If they're holding a mutex over a function call without a
> > _really_ good reason, it's their own fault.
>
>Rubbish. It is common to take out a lock in an outer functions and then
>to call several other fun
Benjamin Stuhl wrote:
> Again, having a GC makes things easier - we clean up
> anything we lost in the GC run. If they don't actually work
> (are there any platforms where they don't work?), we can
> always write our own ;-).
I eagerly await your design for a mutex and CV garbage collector.
--
> > or have entered a mutex,
>
> If they're holding a mutex over a function call without a
> _really_ good reason, it's their own fault.
Rubbish. It is common to take out a lock in an outer functions and then
to call several other functions under the protection of the lock.
> > > The alternat
> > This is the wrong assumption. If you don't care about the call stack,
> > how can you expect the [sig]longjmp can successfully unwind stack?
> > The caller may have a malloc memory block,
>
> Irrelevant with a GC.
Are you serious? Do you mean I can not use malloc in my C code?
> > or have
--- Hong Zhang <[EMAIL PROTECTED]> wrote:
>
> > > This is fine at the target language level (e.g.
> perl6, python, jako,
> > > whatever), but how do we throw catchable exceptions
> up through six or
> > > eight levels of C code? AFAICS, this is more of why
> perl5 uses the
> > > JMP_BUF stuff - s
> > This is fine at the target language level (e.g. perl6, python, jako,
> > whatever), but how do we throw catchable exceptions up through six or
> > eight levels of C code? AFAICS, this is more of why perl5 uses the
> > JMP_BUF stuff - so that XS and functions like sv_setsv() can
> > Perl_croak
On Friday 28 September 2001 19:55, Gibbs Tanton - tgibbs wrote:
> Ooohh, that's bad. Cygwin works fine for me. What test is it failing on?
> What version of perl?
I reinstalled Cygwin with "Default Text File Type" set to Unix
instead of DOS and the tests went ok.
Don't know if that's good or ba
On Fri, 28 Sep 2001, Benjamin Stuhl wrote:
> Thus did the Illustrious Dan Sugalski <[EMAIL PROTECTED]>
> write:
> > Croak's going to throw an interpreter exception. There's
> > a little bit of
> > documentation about the exception handling opcodes in
> > docs/parrot_assembly.pod, with more to com
Thus did the Illustrious Dan Sugalski <[EMAIL PROTECTED]>
write:
> Croak's going to throw an interpreter exception. There's
> a little bit of
> documentation about the exception handling opcodes in
> docs/parrot_assembly.pod, with more to come soonish.
This is fine at the target language level
> The fun part about async vs sync is there's no common decision on what's
an
> async signal and what's a sync signal. :( SIGPIPE, for example, is one of
> those. (Tru64, at least, treats it differently than Solaris)
>
> I generally divide signals into two groups:
>
> *) Messages from outsid
At 01:03 PM 9/28/2001 -0500, David M. Lloyd wrote:
>On Fri, 28 Sep 2001, Alan Burlison wrote:
>
> > Arthur Bergman wrote:
> >
> > > longjmp in a controlled fashion isn't thread-safe? Or longjmping while
> > > holding mutexs and out from asynchronous handlers is not thread-safe?
> >
> > Arthur It *
At 10:46 AM 9/28/2001 -0700, Hong Zhang wrote:
> > In a word? Badly. :) Especially when threads were involved, though in some
>
> > ways it was actually better since you were less likely to core perl.
> >
> > Threads and signals generally don't mix well, especially in any sort of
> > cross-platfo
On Fri, 28 Sep 2001, Alan Burlison wrote:
> Arthur Bergman wrote:
>
> > longjmp in a controlled fashion isn't thread-safe? Or longjmping while
> > holding mutexs and out from asynchronous handlers is not thread-safe?
>
> Arthur It *may* be possible to use longjmp in threaded programs in a
> restr
Ooohh, that's bad. Cygwin works fine for me. What test is it failing on?
What version of perl?
-Original Message-
From: Andreas "Buggs" Hauser
To: Gibbs Tanton - tgibbs
Cc: [EMAIL PROTECTED]
Sent: 9/28/2001 11:59 AM
Subject: Cygwin Problems (was: [PATCH assemble.pl] Fix binary values i
At 04:53 PM 9/28/2001 +0100, Alan Burlison wrote:
>Michael Maraist wrote:
> > In general I'm brought into agreement. I was never too serious about
> > threading anyway. I've seen what a nightmare it can be in portability. I
> > just hope we don't have to make too many sacrafices in the name of
> In a word? Badly. :) Especially when threads were involved, though in some
> ways it was actually better since you were less likely to core perl.
>
> Threads and signals generally don't mix well, especially in any sort of
> cross-platform way. Linux, for example, deals with signals in thread
27 matches
Mail list logo
