On Monday 31 December 2001 11:57 pm, Boris Tschirschwitz wrote:
> I really don't see what UINTVALS are good for.
Here are reflections on my stance
http:[EMAIL PROTECTED]/msg06913.html
> I wonder if making the interpreter so much bigger (with all the
> unsigned counterparts of int arithmetic
I really don't see what UINTVALS are good for.
I wonder if making the interpreter so much bigger (with all the
unsigned counterparts of int arithmetic functions) just for being able to
use native ints instead of bigints a little longer (*2) wouldn't cost more
than it gains.
If it is for type check
On Monday 31 December 2001 11:14 pm, David & Lisa Jacobs wrote:
{patch}
This patch merges changes I made in the same areas.
Index: encodings/singlebyte.c
===
RCS file: /home/perlcvs/parrot/encodings/singlebyte.c,v
retrieving revisi
Index: MANIFEST
===
RCS file: /home/perlcvs/parrot/MANIFEST,v
retrieving revision 1.78
diff -u -r1.78 MANIFEST
--- MANIFEST30 Dec 2001 12:16:42 - 1.78
+++ MANIFEST1 Jan 2002 04:32:52 -
@@ -134,6 +134,7 @@
ops2pm.
> -Original Message-
> From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 31, 2001 7:10 PM
> To: Sterin, Ilya; 'Dan Sugalski'; [EMAIL PROTECTED]
> Subject: Re: Color codes in tinderbox
>
>
> On Monday 31 December 2001 11:58 pm, Sterin, Ilya wrote:
> > Straight
I have a LOT of changes I want to make with respect to unsigned ints. The
net result will be fewer warnings along with lower chance of errors. To
keep from getting out of sync with everyone I'm going to break it into as
small pieces as I can. Unfortunately, this made lead to a few extra
warning
...there's *two* of them!
Index: include/parrot/trace.h
===
RCS file: /home/perlcvs/parrot/include/parrot/trace.h,v
retrieving revision 1.3
diff -u -r1.3 trace.h
--- include/parrot/trace.h 30 Dec 2001 19:52:57 - 1.3
+++
At 05:43 PM 12/31/2001 -1000, David & Lisa Jacobs wrote:
>Index: config_h.in
Thanks, applied.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 05:33 PM 12/31/2001 -1000, David & Lisa Jacobs wrote:
>Index: global_setup.c
Thanks, applied.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 01:59 AM 1/1/2002 +, Nicholas Clark wrote:
>On Mon, Dec 31, 2001 at 06:19:22PM -0500, Dan Sugalski wrote:
> > At 11:10 PM 12/31/2001 +, Nicholas Clark wrote:
> > >But is the correct correction to swap the parameters
> > >
> > >((op_func_prederef_t)*pc_prederef) (interpreter, pc_prederef
Index: config_h.in
===
RCS file: /cvs/public/parrot/config_h.in,v
retrieving revision 1.13
diff -c -r1.13 config_h.in
*** config_h.in 30 Dec 2001 17:26:55 - 1.13
--- config_h.in 1 Jan 2002 03:41:43 -
***
*** 8,13 *
Index: global_setup.c
===
RCS file: /cvs/public/parrot/global_setup.c,v
retrieving revision 1.11
diff -c -r1.11 global_setup.c
*** global_setup.c 18 Dec 2001 07:05:00 - 1.11
--- global_setup.c 1 Jan 2002 03:32:01 -
***
At 02:21 AM 1/1/2002 +, Nicholas Clark wrote:
>Using long long on a 32 bit machine (x86) gives a whole new way to make
>warnings: :-)
Applied with a bit of fuzz. Thanks.
Dan
--"it's like this"---
Dan
On Monday 31 December 2001 11:58 pm, Sterin, Ilya wrote:
> Straight out of the box:-) I'll be recompiling now daily to make sure
> all patches and new development does not break it.
I don't think daily recompilation is going to prevent that. ;-)
--
Bryan C. Warnock
[EMAIL PROTECTED]
Using long long on a 32 bit machine (x86) gives a whole new way to make
warnings: :-)
cc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -Wall -fno-strict-aliasing
-I/usr/local/include -Wall -I./include -DHAS_JIT -o test_main.o -c test_main.c
test_main.c: In function `main':
test_main.c:207: warning: l
On Mon, Dec 31, 2001 at 06:19:22PM -0500, Dan Sugalski wrote:
> At 11:10 PM 12/31/2001 +, Nicholas Clark wrote:
> >But is the correct correction to swap the parameters
> >
> >((op_func_prederef_t)*pc_prederef) (interpreter, pc_prederef);
> >
> >or to change the typedef?
>
> The functions all
Straight out of the box:-) I'll be recompiling now daily to make sure
all patches and new development does not break it. I'll look into the
warnings sometime tomorrow, see what I can do to resolve.
Happy New Years
Ilya
> -Original Message-
> From: Dan Sugalski [mailto:[EMAIL PROTECTED
On Mon, 31 Dec 2001, Sterin, Ilya wrote:
> Just to let you know, the latest CVS compiled on Win32 VC++ 6.0
> Enterprise SP 5. There are quite a few warning, though it's a big
> progress from yesterday's problems. I haven't done any testing yet,
> though.
Did you need to abuse the makefile any
Just to let you know, the latest CVS compiled on Win32 VC++ 6.0
Enterprise SP 5. There are quite a few warning, though it's a big
progress from yesterday's problems. I haven't done any testing yet,
though.
Ilya
On Mon, 31 Dec 2001, David M. Lloyd wrote:
> When I look at the tinderbox screen, there's green, orange, yellow, and
> red. What to the colors mean? There's no key.
Green means tests passed OK. Orange means tests failed, yellow means a run
has started but not finished (there's a "build start"
When I look at the tinderbox screen, there's green, orange, yellow, and
red. What to the colors mean? There's no key.
You know, it's kind of fun to watch. There should be like an auto-refresh
every 5 minutes or something. :-)
- D
<[EMAIL PROTECTED]>
At 11:10 PM 12/31/2001 +, Nicholas Clark wrote:
>But is the correct correction to swap the parameters
>
>((op_func_prederef_t)*pc_prederef) (interpreter, pc_prederef);
>
>or to change the typedef?
The functions all take the interpreter argument second. First arg is a
pointer to an opcode_t,
I'm attempting to make a start on annihilating the warnings picked up by all
the new gcc stricture, but it seems that there are actually some existing
compiler warnings about pointer confusion.
Aside from the hundreds in core_ops.c and core_ops_prederef.c (which may be
the same cause) there is an
At 05:07 PM 12/31/2001 -0600, David M. Lloyd wrote:
>On Mon, 31 Dec 2001, Dan Sugalski wrote:
>
> > > > Could you throw the system into tinderbox? It'll give us logs of the
> > > > zillions of errors or so...
> > >
> > >I am working on it right now. I will set up two: one that uses sparcv9
> > >(
On Mon, 31 Dec 2001, Dan Sugalski wrote:
> > > Could you throw the system into tinderbox? It'll give us logs of the
> > > zillions of errors or so...
> >
> >I am working on it right now. I will set up two: one that uses sparcv9
> >(fully 64-bit) and one that is 32-bit with 64-bit ints.
>
> Cool,
At 04:49 PM 12/31/2001 -0600, David M. Lloyd wrote:
>On Mon, 31 Dec 2001, Dan Sugalski wrote:
>
> > At 04:43 PM 12/31/2001 -0600, David M. Lloyd wrote:
> > >Dan posted to p5p, which I noticed just after I sent this... whoops. :-)
> >
> > Heh, yep, I was fishing for p5p folks that might have machi
On Mon, 31 Dec 2001, Dan Sugalski wrote:
> At 04:43 PM 12/31/2001 -0600, David M. Lloyd wrote:
> >Dan posted to p5p, which I noticed just after I sent this... whoops. :-)
>
> Heh, yep, I was fishing for p5p folks that might have machines they
> could enlist if it didn't take any effort on their p
At 04:43 PM 12/31/2001 -0600, David M. Lloyd wrote:
>Dan posted to p5p, which I noticed just after I sent this... whoops. :-)
Heh, yep, I was fishing for p5p folks that might have machines they could
enlist if it didn't take any effort on their part. :)
I installed the patch, too, thanks.
Coul
Dan posted to p5p, which I noticed just after I sent this... whoops. :-)
- D
<[EMAIL PROTECTED]>
-- Forwarded message --
Date: Mon, 31 Dec 2001 16:41:43 -0600 (CST)
From: David M. Lloyd <[EMAIL PROTECTED]>
To: Dan Sugalski <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: SunWo
Dan Sugalski <[EMAIL PROTECTED]> writes:
> This is jogging my memory some. Jarkko passed on his "gcc switch list
> from hell" to me a while back--let me dig it out and add them in.
> This is *not* going to be pretty for the next few days...
Here are some notes on what I've managed to live with:
At 08:53 PM 12/31/2001 +, Nicholas Clark wrote:
>I just installed perl 5.00405 on my FreeBSD box to test backwards
>compatibility
>of things (perl5 as well as perl6).
We're saying 5.005_03 as the minimum. We definitely ought to check
dependencies, but we're not at the moment.
I just installed perl 5.00405 on my FreeBSD box to test backwards compatibility
of things (perl5 as well as perl6). Running Configure.pl generates several
warnings about unitialised variables, but nothing disastrous. However, running
make does this:
nick@thinking-cap [parrot]$ make test
perl5.004
At 01:19 PM 12/31/2001 -0800, Jason Diamond wrote:
>The attached
>patch removes the -O1 option if it detects that the compiler is the Standard
>Edition. I made a slight fix to Configure.pl while I was at it.
Applied, thanks.
Dan
--
The default flags for cl.exe includes the -O1 option which enables
optimizations. Unfortunately, the Standard Edition of Visual Studio doesn't
support that option so outputs a warning each time we compile. The attached
patch removes the -O1 option if it detects that the compiler is the Standard
Ed
On Mon, Dec 31, 2001 at 11:17:38AM -0500, Dan Sugalski wrote:
[ Me: Don't use -Werror! ]
> We'll burn those bridges when we get to them. Right now I want to clean up
> all the errors our code throws because of these.
Of course, as long as it appears in the development code, it's fine. It's
no
At 10:32 PM 12/31/2001 +0200, Peter Gibbs wrote:
>- Original Message -
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > Yup. Destroyed strings just get their buffer pointers set to NULL. GC'll
> > collect things up. Also means COW string buffers can share pointers to the
> > same buffer.
> >
At 10:16 AM 12/31/2001 -1000, [EMAIL PROTECTED] wrote:
>I started going through a lot of the warnings today and came across what looks
>like to be a far reaching issue.
>
>In well over half of the uses of INTVAL in structures and parameter passing,
>it seems to me that we really want unsigned ints
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> Yup. Destroyed strings just get their buffer pointers set to NULL. GC'll
> collect things up. Also means COW string buffers can share pointers to the
> same buffer.
>
Dan/David
With regard to COW strings - would the buffer-r
At 10:15 AM 12/31/2001 -1000, [EMAIL PROTECTED] wrote:
> >You have also forgotten to free the second allocation. I see that you call
>
>My understanding is that string destroy will go away or become a noop with GC
>(Dan is this correct?). So I intentionally did not mess with it.
Yup. Destroyed s
I started going through a lot of the warnings today and came across what looks
like to be a far reaching issue.
In well over half of the uses of INTVAL in structures and parameter passing,
it seems to me that we really want unsigned ints instead. For example, all the
unicode, size and length attr
>You have also forgotten to free the second allocation. I see that you call
My understanding is that string destroy will go away or become a noop with GC
(Dan is this correct?). So I intentionally did not mess with it.
David
David
You have also forgotten to free the second allocation. I see that you call
free_string(), which is in resources.c, but don't use the matching
new_string_header() function in that file - are these not intended to be a
matched pair for future GC purposes? I am assuming for now that both free(
At 12:06 PM 12/31/2001 -0800, Jason Diamond wrote:
>Attached is a small patch to Configure.pl that "touches" platform.h and
>platform.c so that Configure.pl isn't run a second time when you do a make.
>This doesn't fix Win32's build problems but it makes it less annoying trying
>to figure out the
Attached is a small patch to Configure.pl that "touches" platform.h and
platform.c so that Configure.pl isn't run a second time when you do a make.
This doesn't fix Win32's build problems but it makes it less annoying trying
to figure out the cause of them.
Jason.
- Original Message -
Fr
At 06:23 PM 12/31/2001 +, Nicholas Clark wrote:
>Patch appended, new gcc test program attached.
>Hopefully this is a the right style of doing things.
It's good enough for now. I'm testing it now--when it's done I'll commit this.
Dan
-
On Mon, Dec 31, 2001 at 11:03:38AM -0500, Dan Sugalski wrote:
> Yes, please. This'll catch the systems based on GCC (like the Mac OS X
> compiler) that don't look like that in Config.pm
On Mon, Dec 31, 2001 at 10:39:54AM -0500, Dan Sugalski wrote:
> Folks,
>
> I've just made a few minor changes
At 06:53 AM 12/31/2001 -1000, David & Lisa Jacobs wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > >Agreed. I'll probably have the encoding structure provide the
>terminating
> > >bytes. As a side note don't we also have to split UTF-16 into UTF-16BE
>and
> > >UTF-16LE (big endian and little
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> >Agreed. I'll probably have the encoding structure provide the
terminating
> >bytes. As a side note don't we also have to split UTF-16 into UTF-16BE
and
> >UTF-16LE (big endian and little endian)?
>
> I think UTF-16 can be a single encoding. The little/
At 04:39 PM 12/31/2001 +0100, Thomas Wouters wrote:
>On Mon, Dec 31, 2001 at 03:21:38PM +, Simon Cozens wrote:
> > On Mon, Dec 31, 2001 at 09:50:08AM -0500, Dan Sugalski wrote:
> > > I committed a patch yesterday that forces -Wall for gcc builds. If
> that's
> > > not cranky enough, give me a
At 10:53 AM 12/31/2001 +, Dave Mitchell wrote:
>Boris Tschirschwitz <[EMAIL PROTECTED]> wrote:
> > int *num;
> >
> > is customary in C, but for some reason C++ people like to write
> >
> > int* num;
>
>The rationale in C is that the variable is delared in the same way it
>is invoked. This has
At 04:10 PM 12/31/2001 +, Simon Cozens wrote:
>On Mon, Dec 31, 2001 at 11:03:38AM -0500, Dan Sugalski wrote:
> > Yes, please. This'll catch the systems based on GCC (like the Mac OS X
> > compiler) that don't look like that in Config.pm
>
>I was just about to complain that my perl was built wi
On Mon, Dec 31, 2001 at 11:03:38AM -0500, Dan Sugalski wrote:
> Yes, please. This'll catch the systems based on GCC (like the Mac OS X
> compiler) that don't look like that in Config.pm
I was just about to complain that my perl was built with cc, which is
a symlink to gcc.
--
Resist the urge t
Boris Tschirschwitz <[EMAIL PROTECTED]> wrote:
> int *num;
>
> is customary in C, but for some reason C++ people like to write
>
> int* num;
The rationale in C is that the variable is delared in the same way it
is invoked. This has it's own internal logic, but becomes a nightmare for
declaring
At 03:55 PM 12/31/2001 +, Nicholas Clark wrote:
>Shall I submit a patch that makes Configure.pl check the the C compiler works
>and if it's gcc (by compiling a test program that looks for gcc's version
>macros, rather than trying to pass the output of ${cc} --version)
>
>And the if it's gcc in
On Mon, Dec 31, 2001 at 10:02:19AM -0500, Josh Wilmes wrote:
> At 13:36 on 12/31/2001 GMT, Simon Cozens <[EMAIL PROTECTED]> wrote:
>
> > You are, of course, correct. gcc is a lot laxer than many other compilers,
> > so we want to get away with as little as possible. -Wall should be default
> > fo
On Mon, Dec 31, 2001 at 03:21:38PM +, Simon Cozens wrote:
> On Mon, Dec 31, 2001 at 09:50:08AM -0500, Dan Sugalski wrote:
> > I committed a patch yesterday that forces -Wall for gcc builds. If that's
> > not cranky enough, give me a list of more gcc switches and I'll add 'em
> > into the lis
Folks,
I've just made a few minor changes to configure.pl regarding the switches
for gcc. Now instead of -Wall being the defaults, it's:
-Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wredundant-decls -Wall -Wshadow
-Wpointer-arith -Wcast-qual -Wcast-
At 09:03 AM 12/31/2001 +0200, Peter Gibbs wrote:
>In your last change (splitting buffer allocation from string) I assume you
>also intended to shorten the initial allocation.
Applied, thanks.
Dan
--"it's like this"-
At 03:21 PM 12/31/2001 +, Simon Cozens wrote:
>On Mon, Dec 31, 2001 at 09:50:08AM -0500, Dan Sugalski wrote:
> > I committed a patch yesterday that forces -Wall for gcc builds. If that's
> > not cranky enough, give me a list of more gcc switches and I'll add 'em
> > into the list.
>
>I'd be ve
At 04:08 PM 12/31/2001 +0100, Benoit Cerrina wrote:
> >
> > If you only allow yeilding from the outermost level of scope in a routine,
> > you can do evil things with Duff's Device. Which is what Python does. (But
> > it's sufficient for most purposes)
> >
> > Dan
> >
>Duff's device being evil eno
On Mon, Dec 31, 2001 at 09:50:08AM -0500, Dan Sugalski wrote:
> I committed a patch yesterday that forces -Wall for gcc builds. If that's
> not cranky enough, give me a list of more gcc switches and I'll add 'em
> into the list.
I'd be very tempted to throw -Werror on there as well, just to for
>
> If you only allow yeilding from the outermost level of scope in a routine,
> you can do evil things with Duff's Device. Which is what Python does. (But
> it's sufficient for most purposes)
>
> Dan
>
Duff's device being evil enough in and out of itself I'm not sure I see what
this
has to do wit
At 01:36 PM 12/31/2001 +, Simon Cozens wrote:
>On Mon, Dec 31, 2001 at 12:51:32PM +, Nicholas Clark wrote:
> > Could I suggest that for gcc we turn on maximal bitchiness, /please/
> > -Wall, -W and everything even bitchier still that we can get away with.
>
>You are, of course, correct. gc
At 13:36 on 12/31/2001 GMT, Simon Cozens <[EMAIL PROTECTED]> wrote:
> You are, of course, correct. gcc is a lot laxer than many other compilers,
> so we want to get away with as little as possible. -Wall should be default
> for gcc. (And please remember that not every compiler supports -Wall, so
At 03:01 AM 12/31/2001 -0500, Sam Tregar wrote:
>After reading that I'm only left wondering how this concept connects with
>continuations. Something tells me that if we implement continuations then
>coroutines and generators will fall out nearly for free. On the other
>hand, if we don't do conti
At 03:47 AM 12/31/2001 -0500, Clark C . Evans wrote:
>It seems that the Python people have figured a simple way to
>implement generators.
If you only allow yeilding from the outermost level of scope in a routine,
you can do evil things with Duff's Device. Which is what Python does. (But
it's su
At 09:55 PM 12/30/2001 -1000, David & Lisa Jacobs wrote:
>From: "Dan Sugalski" <[EMAIL PROTECTED]>
> > We do still need to address the byte-orientation of the strings. Throwing
>a
> > single null byte on the end's not enough for buffers that have 16 or 32
>bit
> > characters.
>
>Agreed. I'll prob
On Mon, Dec 31, 2001 at 12:51:32PM +, Nicholas Clark wrote:
> Could I suggest that for gcc we turn on maximal bitchiness, /please/
> -Wall, -W and everything even bitchier still that we can get away with.
You are, of course, correct. gcc is a lot laxer than many other compilers,
so we want to
On Mon, Dec 31, 2001 at 03:51:37AM -0500, Lee Berger wrote:
> that brings me to the next problem: string.c. there are a slew of
> compile errors in this file, and it all is based on pointer math on void
> pointers. for example, STRING has a void* bufstart member, and various
> functions (like s
In case you're interested (having Python, Ruby, ... around I thought
you might be :-), here's a PHP version of the MOPS test.
#!/usr/bin/php
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist
> As
> for general continuations, I can't remember when I've last used
> co-routines... college?
>
> It seems that the Python people have figured a simple way to
> implement generators. That said... I'd hate to have a generator
> request promoted into a continuation request and then get dumped
>
Ooops :-). Yes I did.
David
- Original Message -
From: "Peter Gibbs" <[EMAIL PROTECTED]>
> In your last change (splitting buffer allocation from string) I assume you
> also intended to shorten the initial allocation.
>
> Index: string.c
>
hello!
after seeing a rash of win32 build problems, i decided to look into what
is going on. one problem i noticed in the emails was Configure.pl was
being run twice. once by the user (as expected), and once by nmake. the
reason is quiet cute:
when Configure.pl is run, it copies platforms/win
On Mon, Dec 31, 2001 at 03:01:44AM -0500, Sam Tregar wrote:
| The generator PEP which contains a more complete discussion:
|
|http://python.sourceforge.net/peps/pep-0255.html
|
| After reading that I'm only left wondering how this concept connects with
| continuations. Something tells me th
"Gregor N. Purdy" wrote:
> On that last call to nmake, if you get dropped back into Configure.pl,
> something is wrong configure-wise.
I did a fresh CVS checkout just now, and nmake calls Configure.pl
again.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpO
On Mon, 31 Dec 2001, Clark C . Evans wrote:
> Hello. I was wondering if Parrot is going to support
> Generators. A generator is a function that returns
> multiple times, and I believe, was first made available
> in the language ICON. Now, ICON may have taken it a
> bit too far (everything is
76 matches
Mail list logo
