Re: Generators -- Icon, Python, YAML and YATL
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 a generator), however, Python's newest version supports generators. 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 that if we implement continuations then coroutines and generators will fall out nearly for free. On the other hand, if we don't do continuations then I think this will be quite hard. Simply put, either we figure out how to package up program state into a nice package or we don't. Um, I think. -sam
Re: Building Parrot on Win32
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://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: Generators -- Icon, Python, YAML and YATL
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 that if we implement continuations then | coroutines and generators will fall out nearly for free. On the other | hand, if we don't do continuations then I think this will be quite hard. There is also a nice description of stackless (continuations): http://www.mcmillan-inc.com/stackless.html From my perspective, generators allow for easy processing of multiple input sources (or multiple parallel regular expression matches in the same imput source) without threads. Since this is a common use case for me, I'd love to see it in Parrot. 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 beacuse it is too complicated. ;) Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
recent win32 build errors
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/win32.h to include/parrot/platform.h. Makefile.in has a rule that sets Configure.pl as a dependency to $(STICKY_FILES) ... and platform.h is a member of the $(STICKY_FINGERS) macro. well, Configure.pl's timestamp is newer than win32.h! therefore, nmake will quiet understandably run Configure.pl every time. Configure.pl should forciably touch any file it copies since that copies the file timestamps too. for my testing purpopses, i just removed the dependency in Makefile.in and nmake was happy. 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 string_make) try to do pointer math with it. void pointers have no size; therefore, pointer math won't work. visual c++ enforces this, and i'm a little surprised that gcc doesn't. i guess it just treats it as a char*? everything else seems to compile fine. there are a few compiler warnings due to some functions not returning values (most notiably some files in the classes directory). i'll see about working up a patch tomorrow, but a few questions for the parrot code police. what is the best way to touch a file from inside of perl? also, what is the prefered way of handling the void pointers? casting to char*? some other typedef? change STRING::bufstart from a void* to a char*? ...etc... -lee berger [EMAIL PROTECTED]
Re: Correction to string patch
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 === RCS file: /home/perlcvs/parrot/string.c,v retrieving revision 1.30 diff -c -r1.30 string.c *** string.c30 Dec 2001 21:08:48 - 1.30 --- string.c31 Dec 2001 06:55:56 - *** *** 44,50 encoding = encoding_lookup(type-default_encoding); } ! s = mem_sys_allocate(sizeof(STRING)+buflen); s-bufstart = mem_sys_allocate(buflen+1); s-encoding = encoding; s-flags = flags; --- 44,50 encoding = encoding_lookup(type-default_encoding); } ! s = mem_sys_allocate(sizeof(STRING)); s-bufstart = mem_sys_allocate(buflen+1); s-encoding = encoding; s-flags = flags; --
Re: Generators -- Icon, Python, YAML and YATL
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
beacuse it is too complicated. ;)
Best,
Hi,
I wanted to point out that ruby which is one of parrot's target if I
understand everything correctly support continuations,
here is a short extract of the programming ruby book pertaining to it:
quote
class Continuation Parent: Object
Version: 1.6
Index:
call
Continuation objects are generated by Kernel#callcc . They hold a return
address and execution context, allowing a nonlocal return to the end of the
callcc block from anywhere within a program. Continuations are somewhat
analogous to a structured version of C's setjmp/longjmp (although they
contain more state, so you might consider them closer to threads).
For instance:
arr = [ Freddie, Herbie, Ron, Max, Ringo ]
callcc{|$cc|}
puts(message = arr.shift)
$cc.call unless message =~ /Max/
produces: Freddie
Herbie
Ron
Max
This (somewhat contrived) example allows the inner loop to abandon
processing early:
callcc {|cont|
for i in 0..4
print \n#{i}:
for j in i*5...(i+1)*5
cont.call() if j == 17
printf %3d, j
end
end
}
print \n
produces:
0: 0 1 2 3 4
1: 5 6 7 8 9
2: 10 11 12 13 14
3: 15 16
/quote
so having support for continuation within parrot would really be more than
nice, it would be needed in order to correctly implement ruby on top of it.
Benoit
parrot/examples/mops/mops.php
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 ?php # # mops.php # # A PHP implementation of the mops.pasm example program, # for speed comparisons. # # Copyright (C) 2001 The Parrot Team. All rights reserved. # This program is free software. It is subject to the same # license as The Parrot Interpreter. # # $Id: $ # set_time_limit(0); $i2 = 0; # setI2, 0 $i3 = 1; # setI3, 1 $i4 = 1; # setI4, 1 # print Iterations:$i4\n;# print Iterations: # print I4 # print \n # $i1 = 2; # setI1, 2 $i5 = $i4 * $i1; # mulI5, I4, I1 # print Estimated ops: $i5\n;# print Estimated ops: # print I5 # print \n # $n1 = time();# time N1 # while ($i4 != 0) # REDO: $i4 = $i4 - $i3; # subI4, I4, I3 # if I4, REDO # # DONE: $n5 = time();# time N5 # $n2 = $n5 - $n1; # subN2, N5, N1 # print Elapsed time: $n2\n;# print Elapsed time: # print N2 # print \n # $n1 = $i5; # iton N1, I5 $n1 = $n1 / $n2; # divN1, N1, N2 $n2 = 100.0; # setN2, 100.0 $n1 = $n1 / $n2; # divN1, N1, N2 # print M op/s:$n1\n;# print M op/s: # print N1 # print \n # # end ? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: recent win32 build errors
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 string_make) try to do pointer math with it. void pointers have no size; therefore, pointer math won't work. visual c++ enforces this, and i'm a little surprised that gcc doesn't. i guess it just treats it as a char*? yes by default: cc -O2-I./include -DHAS_JIT -o string.o -c string.c cc -O2-I./include -DHAS_JIT -o encoding.o -c encoding.c but: cc -O2 -Wpointer-arith-I./include -DHAS_JIT -o string.o -c string.c string.c: In function `string_make': string.c:64: warning: pointer of type `void *' used in arithmetic string.c: In function `string_transcode': string.c:171: warning: pointer of type `void *' used in arithmetic string.c:173: warning: pointer of type `void *' used in arithmetic string.c:186: warning: pointer of type `void *' used in subtraction string.c:188: warning: pointer of type `void *' used in arithmetic string.c: In function `string_concat': string.c:229: warning: pointer of type `void *' used in arithmetic string.c: In function `string_substr': string.c:311: warning: pointer of type `void *' used in subtraction string.c:312: warning: pointer of type `void *' used in subtraction string.c:314: warning: pointer of type `void *' used in arithmetic string.c: In function `string_chopn': string.c:328: warning: pointer of type `void *' used in arithmetic string.c:336: warning: pointer of type `void *' used in subtraction string.c:338: warning: pointer of type `void *' used in arithmetic string.c: In function `string_compare': string.c:362: warning: pointer of type `void *' used in arithmetic string.c:364: warning: pointer of type `void *' used in arithmetic string.c: In function `string_to_int': string.c:423: warning: pointer of type `void *' used in arithmetic string.c: In function `string_to_num': string.c:461: warning: pointer of type `void *' used in arithmetic cc -O2 -Wpointer-arith-I./include -DHAS_JIT -o encoding.o -c encoding.c 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. One needs to enforce such stricture early in the project, else it becomes impossible to retrofit it later. I know that turning on gcc bitchiness doesn't directly help anyone testing and committing code who is testing with any other compiler, but assuming that a reasonable proportion of people here (50%?) are using gcc it should cause any problems to be detected fairly early. I'll also volunteer to tidy up all the current code to as many warnings I can find (but not necessarily be the one correcting things hereafter), assuming that this idea is considered worthy. i'll see about working up a patch tomorrow, but a few questions for the parrot code police. what is the best way to touch a file from inside of perl? also, what is the prefered way of handling the void pointers? casting to char*? some other typedef? change STRING::bufstart from a void* to a char*? ...etc... utime is probably the best way to touch a file from inside perl. Nicholas Clark
Re: recent win32 build errors
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 get away with as little as possible. -Wall should be default for gcc. (And please remember that not every compiler supports -Wall, so make it gcc specific!) I'll also volunteer to tidy up all the current code to as many warnings I can find (but not necessarily be the one correcting things hereafter), assuming that this idea is considered worthy. That would be absolutely wonderful. -- Complete the following sentence: People *ought* to weigh bricks, cats and cinnamon in the same units because... - Ian Johnston
Re: Generators -- Icon, Python, YAML and YATL
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 sufficient for most purposes) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Generators -- Icon, Python, YAML and YATL
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 continuations then I think this will be quite hard. Simply put, either we figure out how to package up program state into a nice package or we don't. Um, I think. Parrot's doing coroutines and continuations. It's one of the things that's making the sub calling bits a little interesting. (You can do them all with continuations, but those are really overkill for generators, which you'd kinda like to be efficient if at all possible) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
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 make it gcc specific!) I already submitted a patch for this, and it has been applied. I also added a pedantic option to Configure.pl. That kicks it up anohter notch. (bam.) --Josh
Re: recent win32 build errors
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. 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 make it gcc specific!) 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. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Generators -- Icon, Python, YAML and YATL
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 with yielding, it also only applies to c and c++... I think you mean break is a kind of yield but this is not the same. Can you explain. Benoit
Re: Generators -- Icon, Python, YAML and YATL
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 enough in and out of itself I'm not sure I see what this has to do with yielding, it also only applies to c and c++... I think you mean break is a kind of yield but this is not the same. Can you explain. The details are in the archives for the LL1 list. (Off of ll1.mit.edu somewhere) Basically python fakes it under the hood and uses duff's as a dispatch method to the yielded spot. I didn't dig into it much--it was a clever hack, but insufficient in the general case. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
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 very tempted to throw -Werror on there as well, just to force the issue a little. 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... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Correction to string patch
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--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Minor gcc switch changes
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-align -Wwrite-strings -Wconversion -Waggregate-return -Winline And yes, I see that -Wall's in there twice. (You never notice until after commit) The list of error is rather... impressive. Lets all fix 'em up, shall we? Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
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 list. I'd be very tempted to throw -Werror on there as well, just to force the issue a little. This is *not* a good idea. The problem is that not all warnings are your own fault :) I have seen a lot of examples where a missing prototype or redefinition in OS headers results in a compile-time warning, and -Werror would definately be the wrong thing then. You should use -Werror only if you're afraid of not seeing stderr messages from gcc, or want gcc to stop compiling at the first error to avoid the usual cascade of weird, seemingly incorrect errors. :) -Wall good, -Werror bad. -pedantic could clash with any gcc-specific code such as the calculated-goto. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: recent win32 build errors
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
for gcc. (And please remember that not every compiler supports -Wall, so
make it gcc specific!)
I already submitted a patch for this, and it has been applied. I also
added a pedantic option to Configure.pl. That kicks it up anohter
notch. (bam.)
The problem is that Configure.pl is deciding that it's gcc based on
$Config{ccname} eq gcc. $Config{ccname} doesn't exist in perl5.005_03
(or presumably earlier). That's the undefined warning on line 183 below/
So, there's two or three chances to miss getting gcc. With Configure.pl of 5
minutes ago, on this BSD I get:
nick@thinking-cap [parrot]$ ./Configure.pl
Parrot Version 0.0.3 Configure
Copyright (C) 2001-2002 Yet Another Society
Since you're running this script, you obviously have
Perl 5--I'll be pulling some defaults from its configuration.
Checking the MANIFEST to make sure you have a complete Parrot kit...
Okay, we found everything. Next you'll need to answer
a few questions about your system. Rules are the same
as Perl 5's Configure--defaults are in square brackets,
and you can hit enter to accept them.
Use of uninitialized value at ./Configure.pl line 183.
What C compiler do you want to use? [cc] gcc
How about your linker? [cc] gcc
What flags would you like passed to your C compiler? []
Which libraries would you like your C compiler to include? [-lm -lc -lcrypt]
How big would you like integers to be? [long]
And your floats? [double]
What is your native opcode type? [long]
Probing Perl 5's configuration to determine which headers you have (this could
take a while on slow machines)...
Determining C data type sizes by compiling and running a small C program (this
could take a while):
Building ./test.c from test_c.in...
Figuring out the formats to pass to pack() for the various Parrot internal
types...
Building a preliminary version of include/parrot/config.h, your Makefiles, and
other files:
Building include/parrot/config.hfrom config_h.in...
Building ./Makefile from Makefile.in...
Building ./classes/Makefile from classes/Makefile.in...
Building ./languages/Makefile from languages/Makefile.in...
Building ./languages/jako/Makefile from languages/jako/Makefile.in...
Building ./languages/miniperl/Makefile from languages/miniperl/Makefile.in...
Building ./languages/scheme/Makefilefrom languages/scheme/Makefile.in...
Building Parrot/Types.pmfrom Types_pm.in...
Building Parrot/Config.pm from Config_pm.in...
Checking some things by compiling and running another small C program (this
could take a while):
Building ./testparrotsizes.cfrom testparrotsizes_c.in...
Updating include/parrot/config.h:
Building include/parrot/config.hfrom config_h.in...
Okay, we're done!
You can now use `make' (or your platform's equivalent to `make') to build your
Parrot. After that, you can use `make test' to run the test suite.
Happy Hacking,
The Parrot Team
nick@thinking-cap [parrot]$ make
/usr/bin/perl vtable_h.pl
/usr/bin/perl make_vtable_ops.pl vtable.ops
/usr/bin/perl ops2c.pl C core.ops vtable.ops
/usr/bin/perl ops2c.pl CPrederef core.ops vtable.ops
/usr/bin/perl ops2pm.pl core.ops vtable.ops
/usr/bin/perl -MFile::Copy=cp -e 'cp q|Parrot/Jit/i386-bsd.pm|, q|Parrot/Jit.pm|'
/usr/bin/perl jit2h.pl i386 include/parrot/jit_struct.h
gcc -I./include -DHAS_JIT -o test_main.o -c test_main.c
gcc -I./include -DHAS_JIT -o global_setup.o -c global_setup.c
^C
nick@thinking-cap [130]$ gcc --version
2.95.2
Note that I've even told Configure that I'm using gcc, not cc, and it still
doesn't do the GCC stuff.
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 the tin (whatever the label says) do Dan's
$c{cc_warn} = -Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wredundant-decls -Wall -Wshadow -Wpointer-arith
-Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline;
[hmm it seems that -ansi enables -trigraphs, and -Wall enables -Wtrigraphs,
so that's good (in that I feel we want to know about them if anyone uses them)]
For information, here's what /cc/ stuff I have in %Config:
nick@thinking-cap [parrot]$ /usr/bin/perl -MConfig -lwe 'foreach (keys %Config){print
if /cc/}'
cc
ccflags
Mcc
byacc
cccdlflags
ccdlflags
ccsymbols
cppccsymbols
d_access
d_locconv
gccversion
nick@thinking-cap [parrot]$ /usr/bin/perl -v
This is perl, version
Re: recent win32 build errors
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 the tin (whatever the label says) do Dan's
$c{cc_warn} = -Wall -ansi -pedantic -Wtraditional
-Wstrict-prototypes -Wmissing-prototypes -Winline -Wredundant-decls -Wall
-Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings
-Wconversion -Waggregate-return -Winline;
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
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: recent win32 build errors
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 to start typing; thinking is a worthwhile alternative. -- Kernighan and Pike
Re: recent win32 build errors
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 with cc, which is a symlink to gcc. I ended up hacking an entry into Config.pm for me, as my linux machine's running 5.005_03. If you want fun, try on CygWin--all the generated files get extra ^Ms on their line endings, and GCC doesn't like that in macros... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] The Code Police [1/
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 it's own internal logic, but becomes a nightmare for declaring a pointer to a function that returns a pointer to a function, say. That example's a nightmare no matter how you go. Heck, I use cdecl to try and work 'em out and I still get it wrong. :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
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 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 force the issue a little. This is *not* a good idea. The problem is that not all warnings are your own fault :) I have seen a lot of examples where a missing prototype or redefinition in OS headers results in a compile-time warning, and -Werror would definately be the wrong thing then. You should use -Werror only if you're afraid of not seeing stderr messages from gcc, or want gcc to stop compiling at the first error to avoid the usual cascade of weird, seemingly incorrect errors. :) 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. -Wall good, -Werror bad. -pedantic could clash with any gcc-specific code such as the calculated-goto. -pedantic can go in that case, but since we're not there quite yet it's OK. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Large string patch
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/big endian issue can be dealt with by an I/O filter. Will an IO filter have an opportunity to inject itself when we mmap a file? It was because you said you wanted this capability that I thought we were maintaining the serialized forms of unicode encodings. Otherwise, I would be highly tempted to convert the internal representation of all unicode strings into and array of 4 byte ints (allows for much faster processing). David
Re: Large string patch
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 endian)? I think UTF-16 can be a single encoding. The little/big endian issue can be dealt with by an I/O filter. Will an IO filter have an opportunity to inject itself when we mmap a file? Yep, it's going to have to be. Non-native endianness on UTF files will preclude mmapping them in. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Re: recent win32 build errors
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 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-align -Wwrite-strings -Wconversion
-Waggregate-return -Winline
And yes, I see that -Wall's in there twice. (You never notice until after
commit)
I added -W -Wsign-compare to it, and
-Wformat-nonliteral -Wformat-security -Wpacked -Wpadded -Wdisabled-optimization
for gcc 3.0
We may not want all these.
Patch appended, new gcc test program attached.
Hopefully this is a the right style of doing things.
Nicholas Clark
--- Configure.pl.orig Mon Dec 31 15:32:56 2001
+++ Configure.plMon Dec 31 18:18:26 2001
@@ -178,12 +178,6 @@
$c{PQ} = ';
}
-# If using gcc, crank up its warnings as much as possible and make it behave
-# ansi-ish.
-if ($Config{ccname} eq gcc) {
- $c{cc_warn} = -Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
-Wmissing-prototypes -Winline -Wredundant-decls -Wall -Wshadow -Wpointer-arith
-Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline;
-}
-
# Add the -DHAS_JIT if we're jitcapable
if ($jitcapable) {
$c{cc_hasjit} = -DHAS_JIT;
@@ -225,6 +219,101 @@
prompt(And your floats?, 'nv');
prompt(What is your native opcode type?, 'opcode_t');
+print END;
+
+Determining if your C compiler is actually gcc (this could take a while):
+
+END
+
+{
+my %gnuc;
+
+compiletestc(test_gnuc);
+%gnuc=eval(runtestc()) or die Can't run the test program: $!;
+unlink(test_siz$c{exe}, test$c{o});
+
+unless (exists $gnuc{__GNUC__}) {
+print 'END';
+
+The test program didn't give the expected result - assuming your compiler is
+not gcc.
+
+END
+
+} else {
+ my $major = $gnuc{__GNUC__};
+my $minor = $gnuc{__GNUC_MINOR__};
+unless (defined $major) {
+print 'END';
+
+Your C compiler is not gcc.
+
+END
+} else {
+ print Your C compiler reports itself as gcc, major version $major;
+print , minor version $minor if defined $minor;
+ }
+print .\n\n;
+if ($major =~ tr/0-9//c) {
+print major version '$major' is not an integer,
+ - I don't think that this is gcc.;
+undef $major; # Don't use it
+}
+if (defined $minor and $minor =~ tr/0-9//c) {
+print minor version '$minor' is not an integer.;
+undef $minor; # Don't use it
+}
+if (defined $major) {
+$c{gccversion} = $major;
+$c{gccversion} .= .$minor if defined $minor;
+}
+}
+
+}
+
+if ($c{gccversion}) {
+# If using gcc, crank up its warnings as much as possible and make it
+# behave ansi-ish.
+# Here's an attempt at a list of nasty things we can use for a given
+# version of gcc. The earliest documentation I currently have access to is
+# for 2.95, so I don't know what version everything came in at. If it turns
+# out that you're using 2.7.2 and -Wfoo isn't recognised there, move it up
+# into the next version becone (2.8)
+
+
+my @opt_and_vers =
+(0 = -Wall -ansi -pedantic -Wtraditional -Wstrict-prototypes
+-Wmissing-prototypes -Winline -Wredundant-decls -Wshadow -Wpointer-arith -Wcast-qual
+-Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Winline -W
+-Wsign-compare,
+# others; ones we might like marked with ?
+# ? -Wundef for undefined idenfiers in #if
+# ? -Wbad-function-cast
+# Warn whenever a function call is cast to a non-matching type
+# ? -Wmissing-declarations
+# Warn if a global function is defined without a previous declaration
+# -Wmissing-noreturn
+# ? -Wredundant-decls
+#Warn if anything is declared more than once in the same scope,
+# ? -Wnested-externs
+#Warn if an `extern' declaration is encountered within an function.
+# -Wlong-long
+# Ha. this is the default! with -pedantic.
+# -Wno-long-long for the nicest bit of C99
+ 2.7 = ,
+ 2.8 = ,
+ 2.95 = ,
+ 3.0 = -Wformat-nonliteral -Wformat-security -Wpacked -Wpadded
+-Wdisabled-optimization,
+# -Wsequence-point is part of -Wall
+# -Wfloat-equal may not be what we want
+# We shouldn't be using __packed__, but I doubt -Wpacked will harm us
+# -Wpadded may prove interesting, or even noisy.
+# -Wunreachable-code might be useful in a non debugging version
+);
+while (my ($vers, $opt) = splice
Re: [PATCH] Re: recent win32 build errors
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 --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
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 - From: Lee Berger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 31, 2001 12:51 AM Subject: recent win32 build errors 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/win32.h to include/parrot/platform.h. Makefile.in has a rule that sets Configure.pl as a dependency to $(STICKY_FILES) ... and platform.h is a member of the $(STICKY_FINGERS) macro. well, Configure.pl's timestamp is newer than win32.h! therefore, nmake will quiet understandably run Configure.pl every time. Configure.pl should forciably touch any file it copies since that copies the file timestamps too. for my testing purpopses, i just removed the dependency in Makefile.in and nmake was happy. 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 string_make) try to do pointer math with it. void pointers have no size; therefore, pointer math won't work. visual c++ enforces this, and i'm a little surprised that gcc doesn't. i guess it just treats it as a char*? everything else seems to compile fine. there are a few compiler warnings due to some functions not returning values (most notiably some files in the classes directory). i'll see about working up a patch tomorrow, but a few questions for the parrot code police. what is the best way to touch a file from inside of perl? also, what is the prefered way of handling the void pointers? casting to char*? some other typedef? change STRING::bufstart from a void* to a char*? ...etc... -lee berger [EMAIL PROTECTED] utime.patch Description: Binary data
Re: recent win32 build errors
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 cause of them. Applied, thanks. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Another correction to string patch
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()
calls should go in free_string() rather than one in string_destroy() but I
don't know exactly what you and/or Dan intended here.
Peter Gibbs
EmKel Systems
Index: resources.c
===
RCS file: /home/perlcvs/parrot/resources.c,v
retrieving revision 1.2
diff -c -r1.2 resources.c
*** resources.c 13 Dec 2001 00:51:10 - 1.2
--- resources.c 31 Dec 2001 20:03:28 -
***
*** 27,31
--- 27,32
}
void free_string(STRING *string) {
+ free(string-bufstart);
free(string);
}
Re: Another correction to string patch
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
Unsigned vs. signed ints
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 attributes should probably be unsigned. I'm willing to create a patch for this but considering the amount of work, I wanted to get some feedback first. This also brings up the issue of our int registers. Currently they are treated as signed. Do we want a separate bank of unsigned integers. Or like most processors do, should we create two sets of ops, one that treats the register as signed and the other which treats it as unsigned. Thoughts David
Re: Another correction to string patch
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 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. I'll add the patch anyway, though, since we don't have COW strings yet. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Another correction to string patch
- 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-related parameters (eg bufstart, buflen, bufused) then not be linked to the buffer rather than the string? ie should we have two structs (STRING BUFFER) rather than one combined one, with STRING pointing to BUFFER rather than directly to memory? Peter Gibbs
Re: Unsigned vs. signed ints
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 instead. For example, all the unicode, size and length attributes should probably be unsigned. I'm willing to create a patch for this but considering the amount of work, I wanted to get some feedback first. If you want to implement a UINTVAL, go for it. You'll beat me to it, and that's fine. :) As for the registers, I'd as soon they stay as they are--a single set of signed ints. Larger stuff can live in nums or PMCs, or code can force 'em to be unsigned as need be. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
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 not a good idea for 'real' releases, is what I meant to say. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
How backwards compatible does Configure.pl need to be?
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.00405 vtable_h.pl perl5.00405 make_vtable_ops.pl vtable.ops perl5.00405 ops2c.pl C core.ops vtable.ops perl5.00405 ops2c.pl CPrederef core.ops vtable.ops perl5.00405 ops2pm.pl core.ops vtable.ops Can't locate Data/Dumper.pm in @INC (@INC contains: /usr/local/lib/perl5/i386-freebsd/5.00405 /usr/local/lib/perl5 /usr/local/lib/perl5/site_perl/i386-freebsd /usr/local/lib/perl5/site_perl .) at ops2pm.pl line 11. BEGIN failed--compilation aborted at ops2pm.pl line 11. *** Error code 2 Stop in /stuff/parrot. This doesn't seem the most clean way to do this - should Configure have a list of perl modules that it will need, and issue warnings to the user to go get any that are missing before running make? Nicholas Clark
Re: How backwards compatible does Configure.pl need to be?
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. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: recent win32 build errors
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: ## Warnings to use with gcc. Default to including all of the generally ## useful warnings unless there's something that makes them unsuitable. In ## particular, the following warnings are *not* included: ## ##-ansi Requires messing with feature test macros. ##-Wconversion Too much unsigned to signed noise. ##-Wredundant-decls Too much noise from system headers. ##-Wtraditional We assume ANSI C, so these aren't interesting. ##-Wundef Too much noise from system macros. ## ## Some may be worth looking at again once a released version of gcc doesn't ## warn on system headers. The warnings below are in the same order as ## they're listed in the gcc manual. We suppress warnings for long long ## because of lib/snprintf.c; all uses of long long should be hidden behind ## #ifdef HAVE_LONG_LONG. WARNINGS= -pedantic -Wall -W -Wshadow -Wpointer-arith \ -Wbad-function-cast -Wcast-qual -Wcast-align \ -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes \ -Wnested-externs -Wno-long-long The comment is a little dated, as I believe gcc 3.0 no longer warns on system headers, so -Wredundant-decls possibly could get pulled back in. -Wundef is a style thing. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
SunWorkshop (Solaris) build trouble (Was: Re: Call for parrottinderbox clients)
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: SunWorkshop (Solaris) build trouble (Was: Re: Call for parrot
tinderbox clients)
On Mon, 31 Dec 2001, Dan Sugalski wrote:
Hey, folks,
Parrot's in a state to be built with some regularity, and we could
really use some more machines building into tinderbox. (Especially
non-Linux Unices, and non-Unix systems in general) There's not really
much work--install the tinderbox client, couple of config tweaks, then
fire it off and let it run.
I decided to contribute my Sun Ultra 5 running Solaris 8, which I have
never tried to compile Parrot on before.
I ran into trouble here:
Determining C data type sizes by compiling and running a small C program
(this could take a while):
Building ./test.c from test_c.in...
Figuring out the formats to pass to pack() for the various Parrot
internal types...
Configure.pl: Unable to find a suitable packtype for intvalsize.
It turns out that it can't handle long long for an integer type because
the output for test.c looks like this:
( intvalsize = 8,
numvalsize = 8,
opcode_t_size = 8,
shortsize = 2,
intsize = 4,
longsize = 4,
ptrsize = 4,
floatsize = 4,
doublesize = 8,
);
and it doesn't seem to probe for long long.
I applied this patch:
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.58
diff -u -r1.58 Configure.pl
--- Configure.pl31 Dec 2001 21:58:15 - 1.58
+++ Configure.pl31 Dec 2001 22:19:03 -
@@ -401,6 +401,9 @@
elsif ($c{$_} == 4) {
$c{$which} = 'l';
}
+elsif (($] = 5.006) ($c{$_} == 8)) {
+ $c{$which} = 'q';
+}
else {
die Configure.pl: Unable to find a suitable packtype for $_.\n;
}
I hope this is the right idea...
FYI, using Sun Workshop 6 generates about 100,000 warnings, here's a brief
summary:
cc -DDEBUGGING -I/usr/local/include -I/opt/gnu/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64-I./include -o core_ops.o -c core_ops.c
core_ops.c, line 3212: warning: initialization type mismatch
core_ops.c, line 3213: warning: initialization type mismatch
core_ops.c, line 3214: warning: initialization type mismatch
core_ops.c, line 3215: warning: initialization type mismatch
.and on and on...
cc -DDEBUGGING -I/usr/local/include -I/opt/gnu/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64-I./include -o core_ops_prederef.o -c core_ops_prederef.c
core_ops_prederef.c, line 26: warning: parameter has incomplete type: cur_opcode
core_ops_prederef.c, line 31: warning: parameter has incomplete type: cur_opcode
core_ops_prederef.c, line 36: warning: parameter has incomplete type: cur_opcode
core_ops_prederef.c, line 42: warning: parameter has incomplete type: cur_opcode
.and on and on...
core_ops_prederef.c, line 3213: warning: initialization type mismatch
core_ops_prederef.c, line 3214: warning: initialization type mismatch
core_ops_prederef.c, line 3215: warning: initialization type mismatch
core_ops_prederef.c, line 3216: warning: initialization type mismatch
.and on and on...
There's several prototype mismatches as well. I'll dig in and see if I
can clean it up at all.
- D
[EMAIL PROTECTED]
Re: SunWorkshop (Solaris) build trouble (Was: Re: Call for parrot tinderbox clients)
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. Could you throw the system into tinderbox? It'll give us logs of the zillions of errors or so... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: SunWorkshop (Solaris) build trouble (Was: Re: Call for parrottinderbox clients)
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 part. :) I installed the patch, too, thanks. 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. - D [EMAIL PROTECTED]
Re: SunWorkshop (Solaris) build trouble (Was: Re: Call for parrot tinderbox clients)
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 machines they could enlist if it didn't take any effort on their part. :) I installed the patch, too, thanks. 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, thanks. We definitely can use that, given the slew of errors we're getting. Oh, and CVS sync up. I just silenced about 550 errors... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: SunWorkshop (Solaris) build trouble (Was: Re: Call for parrottinderbox clients)
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, thanks. We definitely can use that, given the slew of errors we're getting. I couldn't help myself; I made three. One builds full 64-bit, one is full 32-bit, and one is 32-bit with 64-bit ints. I guess it's working, I'm not sure how to verify though. - D [EMAIL PROTECTED]
Re: SunWorkshop (Solaris) build trouble (Was: Re: Call for parrot tinderbox clients)
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 (fully 64-bit) and one that is 32-bit with 64-bit ints. Cool, thanks. We definitely can use that, given the slew of errors we're getting. I couldn't help myself; I made three. One builds full 64-bit, one is full 32-bit, and one is 32-bit with 64-bit ints. I guess it's working, I'm not sure how to verify though. http://tinderbox.perl.org/tinderbox/showbuilds.cgi?tree=parrot has the details. They're running, looks like. Cool, thanks. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
pointer warnings in interpreter.c
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 obvious snafu in interpreter.c. Although it's obvious what the error is, it's not obvious to me what the correction should be. gcc reports: nick@Bagpuss [parrot-Wall]$ cc -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I./include -o interpreter.o -c interpreter.c interpreter.c: In function `runops_prederef': interpreter.c:316: warning: passing arg 1 of pointer to function from incompatible pointer type interpreter.c:316: warning: passing arg 2 of pointer to function from incompatible pointer type which is this: ((op_func_prederef_t)*pc_prederef) (pc_prederef, interpreter); where the parameters to the function are struct Parrot_Interp *interpreter void ** pc_prederef and op_func_prederef_t is include/parrot/op.h:typedef void **(*op_func_prederef_t)(struct Parrot_Interp *, void **); ie the types are transposed. But is the correct correction to swap the parameters ((op_func_prederef_t)*pc_prederef) (interpreter, pc_prederef); or to change the typedef? And why do we need the cast? I think it's undefined behaviour (we're casting pointer to data to pointer to function). Not that very many platforms get upset about that sort of thing. IIRC the only thing that turned up on p5p disliking casting function pointers to and from data pointers was some sort of obsolescent Cray. Nicholas Clark
Re: pointer warnings in interpreter.c
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, the second a pointer to the interpreter structure. I've been twiddling with this a bit, but I've no answer and it's time to knock off for dinner, so... if you fix it I'd be much obliged. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Color codes in tinderbox
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]
Re: Color codes in tinderbox
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 and build done mail sent so we can gague how long it takes), and red means a fatal error happened during the build. Compiler warnings don't affect the colors, so a green build can still have warnings. Dan
RE: Color codes in tinderbox
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
RE: Color codes in tinderbox
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]] Sent: Monday, December 31, 2001 4:59 PM To: [EMAIL PROTECTED] Subject: RE: Color codes in tinderbox 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 before it ran, or was it good straight out of the box? Dan
Re: pointer warnings in interpreter.c
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 take the interpreter argument second. First arg is a
pointer to an opcode_t, the second a pointer to the interpreter structure.
I believe that the only clean way to deal with the runops_prederef array
being of lots of Cvoid *s is to make the other parts of parrot honest.
It's not actually an array of bytecode, so this patch makes everything
treat it as void *, not opcode_t.
I've been twiddling with this a bit, but I've no answer and it's time to
knock off for dinner, so... if you fix it I'd be much obliged.
I've not been able to test long long things because Configure.pl barfed:
Configure.pl: Unable to find a suitable packtype for intvalsize.
even when I ran it with perl5.7.1 which was built with IV as long long. :-(
So I may have done something very stupid. But all the compiler warnings go
away. Also, please realise that I've only been looking at this code for a few
hours so I although I think I've figured out roughly what it's doing.
[and I did laugh out loud when I finally realised what cunning tricks it is
doing to replace the deref function with the pointer to the opcode function,
and return the same address so that the run loop calls the real function at
that point]
Nicholas Clark
--- parrot-clean/include/parrot/op.hMon Dec 31 23:13:41 2001
+++ parrot-Wall/include/parrot/op.h Tue Jan 1 01:33:53 2002
@@ -43,7 +43,7 @@
struct Parrot_Interp;
typedef opcode_t *(*op_func_t)(opcode_t *, struct Parrot_Interp *);
-typedef void **(*op_func_prederef_t)(opcode_t *, struct Parrot_Interp *);
+typedef void **(*op_func_prederef_t)(void **, struct Parrot_Interp *);
/*
--- parrot-clean/Parrot/OpTrans.pm Mon Dec 24 03:46:53 2001
+++ parrot-Wall/Parrot/OpTrans.pm Tue Jan 1 01:25:16 2002
@@ -12,6 +12,8 @@
sub new{ return bless { }, shift; }
sub prefix { return 'Parrot_'; }
sub suffix { return ''; }
-
+# The type for the array of opcodes. Usually it's an array opcode_t, but the
+# prederef runops core uses an array of void* to do its clever tricks.
+sub opsarraytype { return 'opcode_t' };
1;
--- parrot-clean/Parrot/OpTrans/CPrederef.pmMon Dec 24 03:46:53 2001
+++ parrot-Wall/Parrot/OpTrans/CPrederef.pm Tue Jan 1 01:29:53 2002
@@ -19,7 +19,6 @@
sub defines
{
return END;
-#define opcode_t void *
#define REL_PC ((size_t)(cur_opcode - interpreter-prederef_code))
#define CUR_OPCODE (((opcode_t *)interpreter-code-byte_code) + REL_PC)
END
@@ -34,6 +33,8 @@
{
return _prederef;
}
+
+sub opsarraytype { return 'void *' };
#
--- parrot-clean/ops2c.pl Mon Dec 31 00:15:28 2001
+++ parrot-Wall/ops2c.plTue Jan 1 01:26:02 2002
@@ -33,6 +33,7 @@
my $prefix = $trans-prefix;
my $suffix = $trans-suffix;
my $defines = $trans-defines;
+my $opsarraytype = $trans-opsarraytype;
my $file = shift @ARGV;
@@ -132,10 +133,10 @@
foreach my $op ($ops-ops) {
my $func_name = $op-func_name;
-my $arg_types = opcode_t *, struct Parrot_Interp *;
-my $prototype = opcode_t * $func_name ($arg_types);
-my $args = opcode_t cur_opcode[], struct Parrot_Interp * interpreter;
-my $definition = static opcode_t *\n$func_name ($args);
+my $arg_types = $opsarraytype *, struct Parrot_Interp *;
+my $prototype = $opsarraytype * $func_name ($arg_types);
+my $args = $opsarraytype *cur_opcode, struct Parrot_Interp * interpreter;
+my $definition = static $opsarraytype *\n$func_name ($args);
my $source = $op-source($trans);
#print HEADER $prototype;\n;
[PATCH] Quadtastic Configure.pl
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: long int format, different type arg (arg 4)
cc -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -Wall -fno-strict-aliasing
-I/usr/local/include -Wall -I./include -DHAS_JIT -o global_setup.o -c global_setup.c
global_setup.c: In function `init_world':
global_setup.c:22: warning: implicit declaration of function
`Parrot_PerlInt_class_init'
global_setup.c:23: warning: implicit declaration of function
`Parrot_PerlNum_class_init'
global_setup.c:24: warning: implicit declaration of function
`Parrot_PerlString_class_init'
global_setup.c:25: warning: implicit declaration of function
`Parrot_PerlArray_class_init'
But no tests have failed yet as I type this. I really should go to bed.
Nicholas Clark
--- Configure.pl~ Mon Dec 31 22:06:48 2001
+++ Configure.plTue Jan 1 02:16:02 2002
@@ -395,15 +395,34 @@
foreach ('intvalsize', 'opcode_t_size') {
my $which = $_ eq 'intvalsize' ? 'packtype_i' : 'packtype_op';
+my $format;
if (($] = 5.006) ($c{$_} == $c{longsize}) ) {
-$c{$which} = 'l!';
+$format = 'l!';
}
elsif ($c{$_} == 4) {
-$c{$which} = 'l';
+$format = 'l';
}
-else {
-die Configure.pl: Unable to find a suitable packtype for $_.\n;
+elsif ($c{$_} == 8 and $Config{quadtype}) {
+ # pp_pack is annoying, and this won't work unless sizeof(UV) = 8
+$format = 'q';
}
+die Configure.pl: Unable to find a suitable packtype for $_.\n
+unless $format;
+
+my $test = eval {pack $format, 0};
+unless (defined $test) {
+die AARGH
+Configure.pl: Unable to find a functional packtype for $_.
+ '$format' failed: $@
+AARGH
+}
+unless (length $test == $c{$_}) {
+die sprintf AARGH, $c{$_}, length $test;
+Configure.pl: Unable to find a functional packtype for $_.
+ Need a format for %d bytes, but '$format' gave %d bytes.
+AARGH
+}
+$c{$which} = $format;
}
$c{packtype_n} = 'd';
Re: Color codes in tinderbox
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]
Re: [PATCH] Quadtastic Configure.pl
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 Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Clean up warnings in global_setup.c
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 -
***
*** 14,21
#define INSIDE_GLOBAL_SETUP
#include parrot/parrot.h
void
! init_world() {
string_init(); /* Set up the string subsystem */
/* Call base vtable class constructor methods! */
--- 14,27
#define INSIDE_GLOBAL_SETUP
#include parrot/parrot.h
+ /* Needed because this might get compiled before pmcs have been built */
+ void Parrot_PerlInt_class_init(void);
+ void Parrot_PerlNum_class_init(void);
+ void Parrot_PerlString_class_init(void);
+ void Parrot_PerlArray_class_init(void);
+
void
! init_world(void) {
string_init(); /* Set up the string subsystem */
/* Call base vtable class constructor methods! */
[PATCH] - Addition of UINTVAL
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
--- 8,14
#define PARROT_CONFIG_H_GUARD
#include stddef.h
typedef ${iv} INTVAL;
+ typedef unsigned ${iv} UINTVAL;
typedef ${nv} FLOATVAL;
typedef ${opcode_t} opcode_t;
Re: pointer warnings in interpreter.c
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); or to change the typedef? The functions all take the interpreter argument second. First arg is a pointer to an opcode_t, the second a pointer to the interpreter structure. I believe that the only clean way to deal with the runops_prederef array being of lots of Cvoid *s is to make the other parts of parrot honest. It's not actually an array of bytecode, so this patch makes everything treat it as void *, not opcode_t. Fair enough. So I may have done something very stupid. But all the compiler warnings go away. Also, please realise that I've only been looking at this code for a few hours so I although I think I've figured out roughly what it's doing. [and I did laugh out loud when I finally realised what cunning tricks it is doing to replace the deref function with the pointer to the opcode function, and return the same address so that the run loop calls the real function at that point] It is rather clever, isn't it? Gregor's done some rather nifty things. Anyway, I've applied your patch. Thanks. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] - Addition of UINTVAL
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] have teddy bears and even teddy bears get drunk
[PATCH] It's a trick, sir...
...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 +++ include/parrot/trace.h 1 Jan 2002 03:56:33 - @@ -27,9 +27,6 @@ void trace_op_b1(struct Parrot_Interp *interpreter, opcode_t * code_start, opcode_t * code_end, opcode_t *pc); -void -trace_op(struct Parrot_Interp *interpreter, opcode_t * code_start, opcode_t * code_end, opcode_t *pc); - #endif /* -- Bryan C. Warnock [EMAIL PROTECTED]
[PATCH] - migrate encodings to UINTVAL
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
warnings while related pieces are waiting to be checked in. I will make
sure that no individual patch fails the test suite.
So here is the first one. The encodings have been changed the strings file
will be in a separate patch.
David
Index: encodings/singlebyte.c
===
RCS file: /cvs/public/parrot/encodings/singlebyte.c,v
retrieving revision 1.6
diff -c -r1.6 singlebyte.c
*** encodings/singlebyte.c 30 Dec 2001 12:04:56 - 1.6
--- encodings/singlebyte.c 1 Jan 2002 04:05:25 -
***
*** 14,25
typedef unsigned char byte_t;
! static INTVAL
! singlebyte_characters (const void *ptr, INTVAL bytes) {
return bytes;
}
! static INTVAL
singlebyte_decode (const void *ptr) {
const byte_t *bptr = ptr;
--- 14,25
typedef unsigned char byte_t;
! static UINTVAL
! singlebyte_characters (const void *ptr, UINTVAL bytes) {
return bytes;
}
! static UINTVAL
singlebyte_decode (const void *ptr) {
const byte_t *bptr = ptr;
***
*** 27,33
}
static void *
! singlebyte_encode (void *ptr, INTVAL c) {
byte_t *bptr = ptr;
if (c 0 || c 255) {
--- 27,33
}
static void *
! singlebyte_encode (void *ptr, UINTVAL c) {
byte_t *bptr = ptr;
if (c 0 || c 255) {
***
*** 41,54
}
static void *
! singlebyte_skip_forward (const void *ptr, INTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr + n;
}
static void *
! singlebyte_skip_backward (const void *ptr, INTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr - n;
--- 41,54
}
static void *
! singlebyte_skip_forward (const void *ptr, UINTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr + n;
}
static void *
! singlebyte_skip_backward (const void *ptr, UINTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr - n;
Index: encodings/utf16.c
===
RCS file: /cvs/public/parrot/encodings/utf16.c,v
retrieving revision 1.5
diff -c -r1.5 utf16.c
*** encodings/utf16.c 30 Dec 2001 12:04:56 - 1.5
--- encodings/utf16.c 1 Jan 2002 04:05:26 -
***
*** 17,27
typedef unsigned short utf16_t;
#endif
! static INTVAL
! utf16_characters (const void *ptr, INTVAL bytes) {
const utf16_t *u16ptr = ptr;
const utf16_t *u16end = u16ptr + bytes / sizeof(utf16_t);
! INTVAL characters = 0;
while (u16ptr u16end) {
u16ptr += UTF16SKIP(u16ptr);
--- 17,27
typedef unsigned short utf16_t;
#endif
! static UINTVAL
! utf16_characters (const void *ptr, UINTVAL bytes) {
const utf16_t *u16ptr = ptr;
const utf16_t *u16end = u16ptr + bytes / sizeof(utf16_t);
! UINTVAL characters = 0;
while (u16ptr u16end) {
u16ptr += UTF16SKIP(u16ptr);
***
*** 35,44
return characters;
}
! static INTVAL
utf16_decode (const void *ptr) {
const utf16_t *u16ptr = ptr;
! INTVAL c = *u16ptr++;
if (UNICODE_IS_HIGH_SURROGATE(c)) {
utf16_t low = *u16ptr++;
--- 35,44
return characters;
}
! static UINTVAL
utf16_decode (const void *ptr) {
const utf16_t *u16ptr = ptr;
! UINTVAL c = *u16ptr++;
if (UNICODE_IS_HIGH_SURROGATE(c)) {
utf16_t low = *u16ptr++;
***
*** 57,66
}
static void *
! utf16_encode (void *ptr, INTVAL c) {
utf16_t *u16ptr = ptr;
! if (c 0 || c 0x10 || UNICODE_IS_SURROGATE(c)) {
INTERNAL_EXCEPTION(INVALID_CHARACTER,
Invalid character for UTF-16 encoding\n);
}
--- 57,66
}
static void *
! utf16_encode (void *ptr, UINTVAL c) {
utf16_t *u16ptr = ptr;
! if (c 0x10 || UNICODE_IS_SURROGATE(c)) {
INTERNAL_EXCEPTION(INVALID_CHARACTER,
Invalid character for UTF-16 encoding\n);
}
***
*** 77,83
}
static void *
! utf16_skip_forward (const void *ptr, INTVAL n) {
utf16_t *u16ptr = (utf16_t*)ptr;
while (n-- 0) {
--- 77,83
}
static void *
! utf16_skip_forward (const void *ptr, UINTVAL n) {
utf16_t *u16ptr = (utf16_t*)ptr;
while (n-- 0) {
***
*** 100,106
}
static void *
! utf16_skip_backward (const void *ptr, INTVAL n) {
utf16_t *u16ptr = (utf16_t*)ptr;
while (n-- 0) {
--- 100,106
}
static void *
! utf16_skip_backward (const void *ptr, UINTVAL n) {
utf16_t *u16ptr = (utf16_t*)ptr;
while (n-- 0) {
Index: encodings/utf32.c
===
RE: Color codes in tinderbox
-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 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. ;-) Know what you mean:-) Prevent it, definitely no, but catching it early will prevent a possibly major problem later? Ilya -- Bryan C. Warnock [EMAIL PROTECTED]
[PATCH] MANIFEST
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.pl packfile.c Parrot/Assembler.pm +Parrot/BuildUtil.pm parrot.c Parrot/Jit/i386-bsd.pm Parrot/Jit/i386-linux.pm -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [PATCH] - migrate encodings to UINTVAL
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 revision 1.6
diff -u -r1.6 singlebyte.c
--- encodings/singlebyte.c 30 Dec 2001 12:04:56 - 1.6
+++ encodings/singlebyte.c 1 Jan 2002 04:40:27 -
@@ -14,12 +14,12 @@
typedef unsigned char byte_t;
-static INTVAL
-singlebyte_characters (const void *ptr, INTVAL bytes) {
+static UINTVAL
+singlebyte_characters (const void *ptr, UINTVAL bytes) {
return bytes;
}
-static INTVAL
+static UINTVAL
singlebyte_decode (const void *ptr) {
const byte_t *bptr = ptr;
@@ -27,8 +27,8 @@
}
static void *
-singlebyte_encode (void *ptr, INTVAL c) {
-byte_t *bptr = ptr;
+singlebyte_encode (const void *ptr, UINTVAL c) {
+byte_t *bptr = (byte_t*)ptr;
if (c 0 || c 255) {
INTERNAL_EXCEPTION(INVALID_CHARACTER,
@@ -41,14 +41,14 @@
}
static void *
-singlebyte_skip_forward (const void *ptr, INTVAL n) {
+singlebyte_skip_forward (const void *ptr, UINTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr + n;
}
static void *
-singlebyte_skip_backward (const void *ptr, INTVAL n) {
+singlebyte_skip_backward (const void *ptr, UINTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr - n;
Index: encodings/utf16.c
===
RCS file: /home/perlcvs/parrot/encodings/utf16.c,v
retrieving revision 1.5
diff -u -r1.5 utf16.c
--- encodings/utf16.c 30 Dec 2001 12:04:56 - 1.5
+++ encodings/utf16.c 1 Jan 2002 04:40:28 -
@@ -17,11 +17,11 @@
typedef unsigned short utf16_t;
#endif
-static INTVAL
-utf16_characters (const void *ptr, INTVAL bytes) {
+static UINTVAL
+utf16_characters (const void *ptr, UINTVAL bytes) {
const utf16_t *u16ptr = ptr;
const utf16_t *u16end = u16ptr + bytes / sizeof(utf16_t);
-INTVAL characters = 0;
+UINTVAL characters = 0;
while (u16ptr u16end) {
u16ptr += UTF16SKIP(u16ptr);
@@ -35,10 +35,10 @@
return characters;
}
-static INTVAL
+static UINTVAL
utf16_decode (const void *ptr) {
const utf16_t *u16ptr = ptr;
-INTVAL c = *u16ptr++;
+UINTVAL c = *u16ptr++;
if (UNICODE_IS_HIGH_SURROGATE(c)) {
utf16_t low = *u16ptr++;
@@ -57,8 +57,8 @@
}
static void *
-utf16_encode (void *ptr, INTVAL c) {
-utf16_t *u16ptr = ptr;
+utf16_encode (const void *ptr, UINTVAL c) {
+utf16_t *u16ptr = (utf16_t*)ptr;
if (c 0 || c 0x10 || UNICODE_IS_SURROGATE(c)) {
INTERNAL_EXCEPTION(INVALID_CHARACTER,
@@ -77,7 +77,7 @@
}
static void *
-utf16_skip_forward (const void *ptr, INTVAL n) {
+utf16_skip_forward (const void *ptr, UINTVAL n) {
utf16_t *u16ptr = (utf16_t*)ptr;
while (n-- 0) {
@@ -100,7 +100,7 @@
}
static void *
-utf16_skip_backward (const void *ptr, INTVAL n) {
+utf16_skip_backward (const void *ptr, UINTVAL n) {
utf16_t *u16ptr = (utf16_t*)ptr;
while (n-- 0) {
Index: encodings/utf32.c
===
RCS file: /home/perlcvs/parrot/encodings/utf32.c,v
retrieving revision 1.2
diff -u -r1.2 utf32.c
--- encodings/utf32.c 30 Dec 2001 12:04:56 - 1.2
+++ encodings/utf32.c 1 Jan 2002 04:40:28 -
@@ -17,12 +17,12 @@
typedef unsigned long utf32_t;
#endif
-static INTVAL
-utf32_characters (const void *ptr, INTVAL bytes) {
+static UINTVAL
+utf32_characters (const void *ptr, UINTVAL bytes) {
return bytes / 4;
}
-static INTVAL
+static UINTVAL
utf32_decode (const void *ptr) {
const utf32_t *u32ptr = ptr;
@@ -30,8 +30,8 @@
}
static void *
-utf32_encode (void *ptr, INTVAL c) {
-utf32_t *u32ptr = ptr;
+utf32_encode (const void *ptr, UINTVAL c) {
+utf32_t *u32ptr = (utf32_t*)ptr;
if (c 0 || c 0x10 || UNICODE_IS_SURROGATE(c)) {
INTERNAL_EXCEPTION(INVALID_CHARACTER,
@@ -44,14 +44,14 @@
}
static void *
-utf32_skip_forward (const void *ptr, INTVAL n) {
+utf32_skip_forward (const void *ptr, UINTVAL n) {
utf32_t *u32ptr = (utf32_t*)ptr;
return u32ptr + n;
}
static void *
-utf32_skip_backward (const void *ptr, INTVAL n) {
+utf32_skip_backward (const void *ptr, UINTVAL n) {
utf32_t *u32ptr = (utf32_t*)ptr;
return u32ptr - n;
Index: encodings/utf8.c
===
RCS file: /home/perlcvs/parrot/encodings/utf8.c,v
retrieving revision 1.6
diff -u -r1.6 utf8.c
--- encodings/utf8.c31 Dec 2001 16:00:59 - 1.6
+++ encodings/utf8.c1 Jan 2002 04:40:28 -
@@ -28,11 +28,11 @@
typedef unsigned char utf8_t;
#endif
-static INTVAL
-utf8_characters (const void *ptr, INTVAL bytes) {
+static UINTVAL
+utf8_characters (const void *ptr, UINTVAL bytes) {
const utf8_t *u8ptr = ptr;
Re: [PATCH] - migrate encodings to UINTVAL
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 checking, I doubt that Parrot is the place to worry
about types, that ought to be done in the language compiled down to
parrot.
For optimization issues, an optimizer should either check the high level
source or, perhaps preferrable, the compiler could write an extra file
with more language independent optimization hints to be used by an
optimizer, when optimization is required.
Boris.
--
Boris Tschirschwitz
University of British Columbia
Mathematics Department
email: [EMAIL PROTECTED]
On Mon, 31 Dec 2001, David Lisa Jacobs wrote:
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
warnings while related pieces are waiting to be checked in. I will make
sure that no individual patch fails the test suite.
So here is the first one. The encodings have been changed the strings file
will be in a separate patch.
David
Index: encodings/singlebyte.c
===
RCS file: /cvs/public/parrot/encodings/singlebyte.c,v
retrieving revision 1.6
diff -c -r1.6 singlebyte.c
*** encodings/singlebyte.c 30 Dec 2001 12:04:56 - 1.6
--- encodings/singlebyte.c 1 Jan 2002 04:05:25 -
***
*** 14,25
typedef unsigned char byte_t;
! static INTVAL
! singlebyte_characters (const void *ptr, INTVAL bytes) {
return bytes;
}
! static INTVAL
singlebyte_decode (const void *ptr) {
const byte_t *bptr = ptr;
--- 14,25
typedef unsigned char byte_t;
! static UINTVAL
! singlebyte_characters (const void *ptr, UINTVAL bytes) {
return bytes;
}
! static UINTVAL
singlebyte_decode (const void *ptr) {
const byte_t *bptr = ptr;
***
*** 27,33
}
static void *
! singlebyte_encode (void *ptr, INTVAL c) {
byte_t *bptr = ptr;
if (c 0 || c 255) {
--- 27,33
}
static void *
! singlebyte_encode (void *ptr, UINTVAL c) {
byte_t *bptr = ptr;
if (c 0 || c 255) {
***
*** 41,54
}
static void *
! singlebyte_skip_forward (const void *ptr, INTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr + n;
}
static void *
! singlebyte_skip_backward (const void *ptr, INTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr - n;
--- 41,54
}
static void *
! singlebyte_skip_forward (const void *ptr, UINTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr + n;
}
static void *
! singlebyte_skip_backward (const void *ptr, UINTVAL n) {
byte_t *bptr = (byte_t*)ptr;
return bptr - n;
Index: encodings/utf16.c
===
RCS file: /cvs/public/parrot/encodings/utf16.c,v
retrieving revision 1.5
diff -c -r1.5 utf16.c
*** encodings/utf16.c 30 Dec 2001 12:04:56 - 1.5
--- encodings/utf16.c 1 Jan 2002 04:05:26 -
***
*** 17,27
typedef unsigned short utf16_t;
#endif
! static INTVAL
! utf16_characters (const void *ptr, INTVAL bytes) {
const utf16_t *u16ptr = ptr;
const utf16_t *u16end = u16ptr + bytes / sizeof(utf16_t);
! INTVAL characters = 0;
while (u16ptr u16end) {
u16ptr += UTF16SKIP(u16ptr);
--- 17,27
typedef unsigned short utf16_t;
#endif
! static UINTVAL
! utf16_characters (const void *ptr, UINTVAL bytes) {
const utf16_t *u16ptr = ptr;
const utf16_t *u16end = u16ptr + bytes / sizeof(utf16_t);
! UINTVAL characters = 0;
while (u16ptr u16end) {
u16ptr += UTF16SKIP(u16ptr);
***
*** 35,44
return characters;
}
! static INTVAL
utf16_decode (const void *ptr) {
const utf16_t *u16ptr = ptr;
! INTVAL c = *u16ptr++;
if (UNICODE_IS_HIGH_SURROGATE(c)) {
utf16_t low = *u16ptr++;
--- 35,44
return characters;
}
! static UINTVAL
utf16_decode (const void *ptr) {
const utf16_t *u16ptr = ptr;
! UINTVAL c = *u16ptr++;
if (UNICODE_IS_HIGH_SURROGATE(c)) {
utf16_t low = *u16ptr++;
***
*** 57,66
}
static void *
! utf16_encode (void *ptr, INTVAL c) {
utf16_t *u16ptr = ptr;
! if (c 0 || c 0x10 || UNICODE_IS_SURROGATE(c)) {
INTERNAL_EXCEPTION(INVALID_CHARACTER,
Invalid character for UTF-16 encoding\n);
}
--- 57,66
}
Re: [PATCH] - migrate encodings to UINTVAL
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 functions) just for being able to use native ints instead of bigints a little longer (*2) wouldn't cost more than it gains. That's not what they are used for. Ops involving generic numbers (like adding two numbers) will always be done with signed values. Anything larger than 31/63 bits will use a BIGINT PMC. Ops involving fixed, unsigned internal entities - like string sizes - will either be coded as such, or be cast appropriately. So we shouldn't have two versions of anything. If it is for type checking, I doubt that Parrot is the place to worry about types, that ought to be done in the language compiled down to parrot. Internal type checking is one reason, yes. It's supposed to be an extra-level of protection, but I'm sure there are a myriad examples of where we'll still go wrong. The occasional bit-shifting (with masks, etc) also need protection from high-bit propogation. For optimization issues, an optimizer should either check the high level source or, perhaps preferrable, the compiler could write an extra file with more language independent optimization hints to be used by an optimizer, when optimization is required. -- Bryan C. Warnock [EMAIL PROTECTED]
