Re: Anyone using the current regex ops?
At 7:34 PM -0500 3/16/02, Melvin Smith wrote: At 04:34 PM 3/16/2002 -0500, Dan Sugalski wrote: Now's your time to speak up, please. Well I was about to try to add simple regexes to my little language before checking in the first version. I think one of the reasons noone is using them is noone likes to compile regexes in their head. Are you considering doing something evil with them? I'm considering removing them entirely. Potentially replacing them with something else, but probably just removing them and beefing up the generic set of opcodes a little. Normal regexes, like /fo+ba?r/ don't see any speed advantage with the current set and, with the JIT enabled, are slower than doing it with 'normal' opcodes. Perl 5's regex engine still kicks our butts rather handily, which is darned annoying, but I'm not sure a custom set of regex opcodes to the extent we have now is the right solution. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: OpenVMS can't get past configure
Michael G Schwern:
# Using 5.005_03 on OpenVMS 7.3...
#
#
# Determining if your C compiler is actually gcc (this could
# take a while):
#
#
# Your C compiler is not gcc.
#
#
# Probing Perl 5's configuration to determine which headers you
# have (this could
# take a while on slow machines)...
# Out of memory!
# %SYSTEM-F-ABORT, abort
Lines in question:
foreach(grep {/^i_/} keys %Config) {
$c{$_}=$Config{$_};
$c{headers}.=defineifdef((/^i_(.*)$/));
}
I think VMS is too lame to handle the grep line. Honestly, I'd rather
not change it to bow to a retarded OS, but apparently we have to. You
can probably just say:
foreach(keys %Config) {
next unless /^i_/;
$c{$_}=$Config{$_};
$c{headers}.=defineifdef((/^i_(.*)$/));
}
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
RE: 64 bit Debian Linux/PowerPC OK but very noisy
Michael G Schwern:
# On Sat, Mar 16, 2002 at 02:36:45PM -0800, Hong Zhang wrote:
#
# Can you check what is the sizeof(INTVAL) and sizeof(void*)?
# Some warnings should not have happened.
#
# (Note: Not a C programmer)
#
# INTVAL? I can't find where its defined.
INTVAL is in config.h. Make sure you #define PARROT_IN_CORE--or you can
just test Parrot_Int, which should be the same thing and is publicly
defined.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
RE: OpenVMS can't get past configure
At 10:13 AM -0800 3/17/02, Brent Dax wrote:
# Probing Perl 5's configuration to determine which headers you
# have (this could
# take a while on slow machines)...
# Out of memory!
# %SYSTEM-F-ABORT, abort
Lines in question:
foreach(grep {/^i_/} keys %Config) {
$c{$_}=$Config{$_};
$c{headers}.=defineifdef((/^i_(.*)$/));
}
I think VMS is too lame to handle the grep line.
No, it's not. Perl works fine on VMS, just as it does on dozens of
other platforms. If that code's throwing a fit, then either perl
itself is broken, or the configure script is broken.
Likely the error is someplace else.
Honestly, I'd rather not change it to bow to a retarded OS
I think, perhaps, that namecalling at software would best be saved
for other places.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: OpenVMS can't get past configure
Dan Sugalski:
# At 10:13 AM -0800 3/17/02, Brent Dax wrote:
# # Probing Perl 5's configuration to determine which headers you
# # have (this could
# # take a while on slow machines)...
# # Out of memory!
# # %SYSTEM-F-ABORT, abort
#
# Lines in question:
#
#
# foreach(grep {/^i_/} keys %Config) {
# $c{$_}=$Config{$_};
# $c{headers}.=defineifdef((/^i_(.*)$/));
# }
#
# I think VMS is too lame to handle the grep line.
#
# No, it's not. Perl works fine on VMS, just as it does on dozens of
# other platforms. If that code's throwing a fit, then either perl
# itself is broken, or the configure script is broken.
#
# Likely the error is someplace else.
We saw this error on VMS before, and that was the cause. That line
_does_ take a lot of memory:
-the hash
-a list of the keys
-the result list from the grep
# Honestly, I'd rather not change it to bow to a retarded OS
#
# I think, perhaps, that namecalling at software would best be saved
# for other places.
The namecalling was because it couldn't handle grep's memory
requirements (which, granted, are non-trivial), not because of any
personal dislike for VMS. I don't know enough about VMS to form an
opinion on it--its popular days were before my time. ;^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: OpenVMS can't get past configure
I suspect that it's not that VMS can't handle it- it's more likely that
VMS does a better job of placing quotas on memory usage than other OSes.
There's probably something analogous to ulimit which would fix the
issue, but requiring that in order to build parrot isn't really reasonable.
If we can make it take less memory, that'd be preferable.
Though if it's running out of memory on that grep, i hesitate to imagine
what it will do on trying to compile some of those giant autogenerated .c
files.
--Josh
At 11:52 on 03/17/2002 PST, Brent Dax [EMAIL PROTECTED] wrote:
Dan Sugalski:
# At 10:13 AM -0800 3/17/02, Brent Dax wrote:
# # Probing Perl 5's configuration to determine which headers you
# # have (this could
# # take a while on slow machines)...
# # Out of memory!
# # %SYSTEM-F-ABORT, abort
#
# Lines in question:
#
#
# foreach(grep {/^i_/} keys %Config) {
# $c{$_}=$Config{$_};
# $c{headers}.=defineifdef((/^i_(.*)$/));
# }
#
# I think VMS is too lame to handle the grep line.
#
# No, it's not. Perl works fine on VMS, just as it does on dozens of
# other platforms. If that code's throwing a fit, then either perl
# itself is broken, or the configure script is broken.
#
# Likely the error is someplace else.
We saw this error on VMS before, and that was the cause. That line
_does_ take a lot of memory:
-the hash
-a list of the keys
-the result list from the grep
# Honestly, I'd rather not change it to bow to a retarded OS
#
# I think, perhaps, that namecalling at software would best be saved
# for other places.
The namecalling was because it couldn't handle grep's memory
requirements (which, granted, are non-trivial), not because of any
personal dislike for VMS. I don't know enough about VMS to form an
opinion on it--its popular days were before my time. ;^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
RE: OpenVMS can't get past configure
At 11:52 AM -0800 3/17/02, Brent Dax wrote:
Dan Sugalski:
# At 10:13 AM -0800 3/17/02, Brent Dax wrote:
# # Probing Perl 5's configuration to determine which headers you
# # have (this could
# # take a while on slow machines)...
# # Out of memory!
# # %SYSTEM-F-ABORT, abort
#
# Lines in question:
#
#
# foreach(grep {/^i_/} keys %Config) {
# $c{$_}=$Config{$_};
# $c{headers}.=defineifdef((/^i_(.*)$/));
# }
#
# I think VMS is too lame to handle the grep line.
#
# No, it's not. Perl works fine on VMS, just as it does on dozens of
# other platforms. If that code's throwing a fit, then either perl
# itself is broken, or the configure script is broken.
#
# Likely the error is someplace else.
We saw this error on VMS before, and that was the cause. That line
_does_ take a lot of memory:
-the hash
-a list of the keys
-the result list from the grep
In which case it's not a VMS problem, but a memory one. I expect the
quotas on the test drive machines that Schwern's using are pretty low
to keep any one user from adversely impacting another. Odds are that
an attempt at another time would work, if there were fewer users on
the system--the system will hand out extra memory to a process if its
available, but makes no guarantees on having overflow.
More importantly, this is a sign we're going to have problems on
systems without ample memory. (I'm not looking forward to the
expected footprint for a compile of core.ops with full optimization
on...)
I'm going to try and get a VMS test system out of some of the folks I
know in VMS engineering. Won't be the latest and greatest, but
there'll be fewer limits.
# Honestly, I'd rather not change it to bow to a retarded OS
#
# I think, perhaps, that namecalling at software would best be saved
# for other places.
The namecalling was because it couldn't handle grep's memory
requirements (which, granted, are non-trivial), not because of any
personal dislike for VMS. I don't know enough about VMS to form an
opinion on it--its popular days were before my time. ;^)
Still, the namecalling's inappropriate. Operating systems are
software, and all software sucks. Singling out a particular piece of
it's pretty pointless--might as well point out that one particular
spot on the sun's awfully bright. ;)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: 64 bit Debian Linux/PowerPC OK but very noisy
It looks like you are running in 32-bit environment, but
using 64-bit INTVAL. The INTVAL must be the same size as
void* in order to cast between them without warning.
Please try to reconfig using 32-bit INTVAL, or running
process in 64-bit mode.
Hong
-Original Message-
From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 16, 2002 2:54 PM
To: Hong Zhang
Cc: [EMAIL PROTECTED]
Subject: Re: 64 bit Debian Linux/PowerPC OK but very noisy
On Sat, Mar 16, 2002 at 02:36:45PM -0800, Hong Zhang wrote:
Can you check what is the sizeof(INTVAL) and sizeof(void*)?
Some warnings should not have happened.
(Note: Not a C programmer)
INTVAL? I can't find where its defined.
int main (void) {
printf(int %d, long long %d, void %d\n,
sizeof(int), sizeof(long long), sizeof(void*));
}
int 4, long long 8, void 4.
From perl -V:
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=87654321
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=8, usemymalloc=n, prototype=define
--
Michael G. Schwern [EMAIL PROTECTED]
http://www.pobox.com/~schwern/
Perl Quality Assurance[EMAIL PROTECTED]
Kwalitee Is Job One
The key, my friend, is hash browns.
http://www.goats.com/archive/980402.html
Re: 64 bit Debian Linux/PowerPC OK but very noisy
On Sun, Mar 17, 2002 at 10:16:13AM -0800, Brent Dax wrote: Michael G Schwern: # On Sat, Mar 16, 2002 at 02:36:45PM -0800, Hong Zhang wrote: # # Can you check what is the sizeof(INTVAL) and sizeof(void*)? # Some warnings should not have happened. # # (Note: Not a C programmer) # # INTVAL? I can't find where its defined. INTVAL is in config.h. Make sure you #define PARROT_IN_CORE--or you can just test Parrot_Int, which should be the same thing and is publicly defined. From config.h typedef long long INTVAL; typedef unsigned long long UINTVAL; -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Out of ammunition. God save the King.
Re: 64 bit Debian Linux/PowerPC OK but very noisy
On Sun, Mar 17, 2002 at 12:50:57PM -0800, Hong Zhang wrote: It looks like you are running in 32-bit environment, but using 64-bit INTVAL. The INTVAL must be the same size as void* in order to cast between them without warning. Please try to reconfig using 32-bit INTVAL, or running process in 64-bit mode. Huh? Remember, I am not a C programmer. I just took my perl 5.6.1 that's compiled with 64 bit ints and ran Configure.pl with it. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Out of ammunition. God save the King.
RE: OpenVMS can't get past configure
personal dislike for VMS. I don't know enough about VMS to form an opinion on it--its popular days were before my time. ;^) I never cared for the VMS command shell (I think it was DCL, been a few years since I worked on it), but there is a lot to be learned from the VMS architecture itself. For one, it has security features that would make you cringe. Also, it just plain doesn't crash. That aside, to each his own. You'll take my UN*X when you pry it from my cold, dead, hardware. -Melvin
Cygwin build results
This is off a clean rsync of parrot-HEAD The build is almost completely clean, with only the following errors. packfile.c: In function `PackFile_check_segment_size': packfile.c:129: warning: long int format, int arg (arg 5) encodings/singlebyte.c: In function `singlebyte_skip_forward': encodings/singlebyte.c:49: warning: cast discards qualifiers from pointer target type encodings/singlebyte.c: In function `singlebyte_skip_backward': encodings/singlebyte.c:57: warning: cast discards qualifiers from pointer target type encodings/utf8.c: In function `utf8_skip_forward': encodings/utf8.c:113: warning: cast discards qualifiers from pointer target type encodings/utf8.c: In function `utf8_skip_backward': encodings/utf8.c:125: warning: cast discards qualifiers from pointer target type encodings/utf16.c: In function `utf16_skip_forward': encodings/utf16.c:87: warning: cast discards qualifiers from pointer target type encodings/utf16.c: In function `utf16_skip_backward': encodings/utf16.c:112: warning: cast discards qualifiers from pointer target type encodings/utf32.c: In function `utf32_skip_forward': encodings/utf32.c:54: warning: cast discards qualifiers from pointer target type encodings/utf32.c: In function `utf32_skip_backward': encodings/utf32.c:62: warning: cast discards qualifiers from pointer target type Test results are also promising: perl t/harness t/op/basic..ok t/op/bitwiseok t/op/debuginfo..ok t/op/hacks..ok t/op/ifunless...ok t/op/integerok t/op/interp.ok t/op/macro..ok, 1/9 skipped: Await exceptions t/op/number.ok t/op/rx.ok, 2/27 skipped: various reasons t/op/stacks.ok, 1/15 skipped: Await exceptions t/op/string.ok t/op/time...ok t/op/trans..ok t/pmc/array.ok, 1/1 skipped: Wait until this works t/pmc/perlarray.ok, 5/5 skipped: Arrays need a little rejigging t/pmc/perlhash..ok, 8/8 skipped: No tests for things we know don't work quite yet t/pmc/perlstringok, 1/8 skipped: Pending new version of concat_p_p_s t/pmc/pmc...ok, 1/56 skipped: string-int not finished yet All tests successful, 20 subtests skipped. Files=19, Tests=313, 350 wallclock secs (237.31 cusr + 87.91 csys = 325.23 CPU) Cheers, Owen Landgren
RE: [PATCH Configure.pl] (still broken) Re: OpenVMS can't get past configure
Michael G Schwern:
# On Sun, Mar 17, 2002 at 10:13:58AM -0800, Brent Dax wrote:
# Lines in question:
#
#
# foreach(grep {/^i_/} keys %Config) {
# $c{$_}=$Config{$_};
# $c{headers}.=defineifdef((/^i_(.*)$/));
# }
#
# I think VMS is too lame to handle the grep line. Honestly,
# I'd rather
# not change it to bow to a retarded OS, but apparently we
# have to. You
# can probably just say:
#
# foreach(keys %Config) {
# next unless /^i_/;
# $c{$_}=$Config{$_};
# $c{headers}.=defineifdef((/^i_(.*)$/));
# }
#
# If one wanted to do that in a memory efficient manner...
#
# --- Configure.plSun Mar 17 15:53:06 2002
# +++ Configure.pl Sat Mar 16 15:00:00 2002
# @@ -483,9 +481,10 @@
# # Set up HAS_HEADER_
# #
#
# -foreach(grep {/^i_/} keys %Config) {
# -$c{$_}=$Config{$_};
# -$c{headers}.=defineifdef((/^i_(.*)$/));
# +while(my($k, $v) = each %Config) {
# +next unless $k =~ /^i_/;
# +$c{$k} = $v;
# +$c{headers} .= defineifdef(($k =~ /^i_(.*)$/));
# }
#
# print END;
#
#
# But even with this in place it still takes forever with 5.005_03. So
# I'll just chalk it up to a perl bug. 5.7.2 fares much better, but
# still bombs later on...
#
#
# Your C compiler is not gcc.
#
#
# 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...
# Figuring out what integer type we can mix with pointers...
# We'll use 'unsigned int'.
#
# 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...
# Use of uninitialized value in substitution iterator at
# configure.pl line 803.
# Building ./classes/Makefile from classes/Makefile.in...
# Building ./docs/Makefilefrom docs/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 lib/Parrot/Types.pmfrom Types_pm.in...
# Building lib/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...
#
#
# #include parrot/parrot.h
# #include parrot/parrot.h
# ..^
# ..^
# %CC-F-NOINCLFILEF, Cannot find file parrot/parrot.h
# specified in #include directive.
# %CC-F-NOINCLFILEF, Cannot find file parrot/parrot.h
# specified in #include directive.
# at line number 9 in file USER1:[SCHWERN.SRC.PARROT]TESTPARROTSIZES.C;1
# at line number 9 in file USER1:[SCHWERN.SRC.PARROT]TESTPARROTSIZES.C;1
# C compiler died! at (eval 1) line 13.
# %RMS-E-FNF, file not found
Yikes. Does the C compiler recognize that sort of path? How about
the -I switch (it may be set differently by VMS's hints file) that tells
it to look in ./include?
# PS You're not qualified to yell at VMS until you grok the mystery of:
# $ rm foo
# $ rm foo
# $ rm foo
# $ rm foo
# $ rm foo
# $ rm foo
# $ rm foo
# $ rm foo
# $ rm foo
# $ rm foo
# $ rm foo
# rm.exe: foo: no such file or directory
#
# :)
Nine versions of foo. A nice feature, IMHO. ;^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: [PATCH Configure.pl] (still broken) Re: OpenVMS can't get past configure
On Sun, Mar 17, 2002 at 05:06:35PM -0800, Brent Dax wrote:
# Checking some things by compiling and running another small C
# program (this
# could take a while):
#
# Building ./testparrotsizes.cfrom testparrotsizes_c.in...
#
#
# #include parrot/parrot.h
# #include parrot/parrot.h
# ..^
# ..^
# %CC-F-NOINCLFILEF, Cannot find file parrot/parrot.h
# specified in #include directive.
# %CC-F-NOINCLFILEF, Cannot find file parrot/parrot.h
# specified in #include directive.
# at line number 9 in file USER1:[SCHWERN.SRC.PARROT]TESTPARROTSIZES.C;1
# at line number 9 in file USER1:[SCHWERN.SRC.PARROT]TESTPARROTSIZES.C;1
# C compiler died! at (eval 1) line 13.
# %RMS-E-FNF, file not found
Yikes. Does the C compiler recognize that sort of path? How about
the -I switch (it may be set differently by VMS's hints file) that tells
it to look in ./include?
main::(configure.pl:668): compiletestc(testparrotsizes);
DB2 s
main::CODE(0x7a1c8c)((eval 4)[configure.pl:297]:10):
10: my $name;
DB2 n
main::CODE(0x7a1c8c)((eval 4)[configure.pl:297]:11):
11: $name = shift;
DB2
main::CODE(0x7a1c8c)((eval 4)[configure.pl:297]:12):
12: $name = test unless $name;
DB2
main::CODE(0x7a1c8c)((eval 4)[configure.pl:297]:13):
13: system($c{cc} $c{ccflags} $name.c) and die C compiler
died!;
DB2 x $c{cc} $c{ccflags} $name.c
0 'CC/DECC
/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/NOANSI_ALIAS/include=([.include],/here)
testparrotsizes.c'
DB3 use Cwd
DB4 x cwd
0 'USER1:[SCHWERN.SRC.PARROT]'
DB5 n
#include parrot/parrot.h
#include parrot/parrot.h
..^
..^
%CC-F-NOINCLFILEF, Cannot find file parrot/parrot.h specified in #include directive.
%CC-F-NOINCLFILEF, Cannot find file parrot/parrot.h specified in #include directive.
at line number 9 in file USER1:[SCHWERN.SRC.PARROT]TESTPARROTSIZES.C;3
at line number 9 in file USER1:[SCHWERN.SRC.PARROT]TESTPARROTSIZES.C;3
C compiler died! at (eval 4)[configure.pl:297] line 13.
main::__ANON__[(eval 4)[configure.pl:297]:15]('testparrotsizes') called
Debugged program terminated. Use q to quit or R to restart,
Poking around in the DECC manual, there's two problems.
http://www.openvms.compaq.com/commercial/c/5492p004.htm#index_x_113
First, its INCLUDE_DIRECTORY, not INCLUDE (although INCLUDE works).
Second, there seems to be some confusing rules about mixing VMS and
Unix style paths. It seems that the style used in INCLUDE_DIRECTORY
has to match the style used in the #include.
Search the places specified in the /INCLUDE_DIRECTORY qualifier, if
any. A place that can be parsed successfuly as an OpenVMS file-spec
and that does not contain an explicit file type or version
specification is edited to append the default header file type
specification (.h or .).
A place containing a / character is considered to be a UNIX-style
name. If the name in the #include directive also contains a /
character that is not the first character and is not preceded by a
! character (it is not an absolute UNIX-style pathname), then the
name in the #include directive is appended to the named place,
separated by a / character, before applying the decc$to_vms
pathname translation function. The result of the decc$to_vms
translation is then used as the filespec to try to open.
so this works:
CC/DECC /INCLUDE=(./include) testparrotsizes.c
but you might want to get independent confirmation from the vmsperl
folks about that.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Not king yet
Re: Solaris8 32bit GCC3.0.3 on 64bit Ultra10 OK but...
On Sunday 17 March 2002 00:23, Melvin Smith wrote: Makes ok, alignment warnings. Tests run ok. Most warnings are from -Wpadded. I was able to eliminate 1 or 2 by rearranging members in structs, but some are due to unions of different size types. We can either turn off -Wpadded or manually pad the structs by changing types or adding placeholders (yucky). This warning is typically only useful if you are looking for something specific, so unless there is a specific case, I say turn it off. I agree. Ditching BOOLVAL in favor of UINTVAL might fix a couple as well. Using char types might be a minor memory save, but I'm not sure which platforms actually see it due to alignment. Until we want to add another one. In either case, UINTVAL is the wrong type. We'd want the natural word size, which I haven't figured out (beyond benchmarking) how to test for.) Leave it as a char, and turn off the warning. I cleared up the one warning from io_unix.c. Follows is a grep -v of the padding warnings leaving other interesting stuff. packfile.c:123: warning: long int format, unsigned int arg (arg 5) key.c:265: warning: cast increases required alignment of target type key.c:291: warning: cast increases required alignment of target type key.c:319: warning: cast increases required alignment of target type key.c:389: warning: cast increases required alignment of target type key.c:464: warning: cast increases required alignment of target type jit.c:301: warning: cast increases required alignment of target type jit.c:352: warning: cast increases required alignment of target type jit.c:368: warning: cast increases required alignment of target type jit.c:510: warning: cast increases required alignment of target type I *think* I'm stamping those out as soon as 0.0.4 is out. embed.c:121: warning: passing arg 1 of `mem_sys_allocate' as unsigned due to prototype embed.c:122: warning: passing arg 3 of `read' as unsigned due to prototype embed.c:149: warning: cast increases required alignment of target type Same as those. misc.c:399: warning: format not a string literal, argument types not checked misc.c:407: warning: format not a string literal, argument types not checked misc.c:415: warning: format not a string literal, argument types not checked misc.c:423: warning: format not a string literal, argument types not checked misc.c:431: warning: format not a string literal, argument types not checked Nothing we can do about that. io/io_unix.c:206: warning: comparison of unsigned expression = 0 is always true encodings/singlebyte.c:49: warning: cast discards qualifiers from pointer target type encodings/singlebyte.c:57: warning: cast discards qualifiers from pointer target type encodings/utf8.c:113: warning: cast discards qualifiers from pointer target type encodings/utf8.c:125: warning: cast discards qualifiers from pointer target type encodings/utf16.c:87: warning: cast discards qualifiers from pointer target type encodings/utf16.c:112: warning: cast discards qualifiers from pointer target type encodings/utf32.c:54: warning: cast discards qualifiers from pointer target type encodings/utf32.c:62: warning: cast discards qualifiers from pointer target type Is this solvable? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: 64 bit Debian Linux/PowerPC OK but very noisy
On Saturday 16 March 2002 13:24, Michael G Schwern wrote: This is parrot built using a 5.6.1 with 64 bit integers. The tests pass ok, but there's a heap of warnings in the build. Here's the complete make output. Known problem. We currently suck at most things not long or double. My stomping grounds for after 0.0.4, I think. (Or before, if I can get to them. But I'd rather just caveat that it doesn't work, because, in general, it doesn't. )-: -- Bryan C. Warnock [EMAIL PROTECTED]
Re: I'm about to do something really evil
On Saturday 16 March 2002 12:03, Dan Sugalski wrote: And make immortal Buffers and PMCs. It's a nasty hack, but it solves the what happens if I allocate a bunch of PMCs and the DOD collects them before I can use them problem. Now'd be a good time to object if you've a better option. :) Immortal sounds a little scary. What are you *really* doing? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Showstopper allocation bug
On Saturday 16 March 2002 07:48, Simon Cozens wrote: 645 return_me = *foo; On a separate note, metasyntactic variable names aren't the best choice in actual code. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [bugs-parrot@netlabs.develooper.com: [netlabs #423] Fwd: Parrot segfaults on substr]
On Tuesday 12 March 2002 12:06, Melvin Smith wrote: Just my 2 pesos. When CPUs are 10% faster, would this little optimization matter? Well, yes, since the optimization will then be 10% faster, too. ;-) A typical CPU traps invalid derefs by segfaulting the process, but the CPU itself doesn't explode. I do see Dan's point, but I also predoct people gravitating towards the safe interpreter because of that extra fuzzy. I don't. With untested stuff, sure. But with known good code? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: [bugs-parrot@netlabs.develooper.com: [netlabs #423] Fwd: Parrot segfaults on substr]
On Monday 11 March 2002 20:24, Alex Gough wrote: On Mon, 11 Mar 2002, Simon Glover wrote: For more fun in the same vein, try this: length S0 end In both cases the problem is that we're not checking the STRING* pointer passed to the function before we start trying to dereference it. This seems to be a fairly generic problem in the string functions, unfortunately - a brief look suggests that string_ord is the only one doing the right thing. I seem to remember someone unpatching a couple of if (NULL == string) statements recently. I'll be blunt and say: DON'T DO THAT. Defensive programming is good, segfaulting is bad, remember? It depends on what your defending against. If it's legal, within the design, for string to be NULL, then yes, you have to check. If it's not *supposed* to happen - i.e., somebody's implementaton on top of Parrot is busted, I'd prefer the segfault. It makes tracking the problem so much easier, Logically speaking, I don't think any Parrot string function should take a null string - every string should be, at a minimum, empty. So I'd say ditch the guards and let the Parrto squawk its heart out. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: pmc_init
On Sunday 10 March 2002 01:32, Melvin Smith wrote: I think it would be useful to add an init method for PMCs which takes a size argument constructor since there will be times when a language implementor wants to created a sized type. Right now init takes no arguments. It will definitely be important for C style languages where most things are structs, classes or static arrays. I personally think that it should take this argument by default rather than being overloaded (all in interest of less bloat, I'd rather just modify the existing init). Any objections? On a side note, did anyone read the Is Java's 'new' harmful? article in DDJ? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Reformatting code/coding standards
On Friday 08 March 2002 23:02, Melvin Smith wrote: Just my 2 cents. This is my only nitpick with the coding standards. I never cared for the style of putting return type on a separate line above the function declaration header. I like it just as the prototype. I vote for non-enforcement of this one. Er, did you mean removal? Having rules that aren't enforced is counter-productive in the long run. -- Bryan C. Warnock [EMAIL PROTECTED]
RE: 64 bit Debian Linux/PowerPC OK but very noisy
Michael G Schwern:
# On Sun, Mar 17, 2002 at 12:50:57PM -0800, Hong Zhang wrote:
#
# It looks like you are running in 32-bit environment, but
# using 64-bit INTVAL. The INTVAL must be the same size as
# void* in order to cast between them without warning.
# Please try to reconfig using 32-bit INTVAL, or running
# process in 64-bit mode.
#
# Huh?
#
# Remember, I am not a C programmer. I just took my perl 5.6.1 that's
# compiled with 64 bit ints and ran Configure.pl with it.
Okay. When Configure asks:
How big would you like integers to be? [long long]
just type 'long' (without quotes) and hit enter. You won't get 64-bit
support, but you will get a building Parrot, which is usually a good
thing. ;^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: Solaris8 32bit GCC3.0.3 on 64bit Ultra10 OK but...
At 10:29 PM 3/17/2002 -0500, Bryan C. Warnock wrote: Ditching BOOLVAL in favor of UINTVAL might fix a couple as well. Until we want to add another one. In either case, UINTVAL is the wrong type. We'd want the natural word size, which I haven't figured out (beyond benchmarking) how to test for.) Leave it as a char, and turn off the warning. I'm not sure why I said UINTVAL. ? I meant whatever the word size was (16, 32??), but also I agree, as soon as you add 2 boolean fields, then you lose. encodings/utf16.c:112: warning: cast discards qualifiers from pointer target type encodings/utf32.c:54: warning: cast discards qualifiers from pointer target type encodings/utf32.c:62: warning: cast discards qualifiers from pointer target type Is this solvable? Good question. :) -Melvin
RE: Solaris8 32bit GCC3.0.3 on 64bit Ultra10 OK but...
Bryan C. Warnock:
# On Sunday 17 March 2002 00:23, Melvin Smith wrote:
# Makes ok, alignment warnings. Tests run ok. Most warnings are
# from -Wpadded. I was able to eliminate 1 or 2 by rearranging
# members in structs, but some are due to unions of different size
# types.
#
# We can either turn off -Wpadded or manually pad the structs
# by changing types or adding placeholders (yucky). This warning
# is typically only useful if you are looking for something specific,
# so unless there is a specific case, I say turn it off.
#
# I agree.
Agree.
#
# Ditching BOOLVAL in favor of UINTVAL might fix a couple as well.
# Using char types might be a minor memory save, but I'm not sure
# which platforms actually see it due to alignment.
#
# Until we want to add another one. In either case, UINTVAL is
# the wrong
# type. We'd want the natural word size, which I haven't
# figured out (beyond
# benchmarking) how to test for.)
#
# Leave it as a char, and turn off the warning.
Agree.
#
# I cleared up the one warning from io_unix.c.
#
# Follows is a grep -v of the padding warnings leaving other
# interesting
# stuff.
#
# packfile.c:123: warning: long int format, unsigned int arg (arg 5)
# jit.c:510: warning: cast increases required alignment of target type
#
# I *think* I'm stamping those out as soon as 0.0.4 is out.
#
# embed.c:121: warning: passing arg 1 of `mem_sys_allocate'
# as unsigned due
# to prototype
# embed.c:122: warning: passing arg 3 of `read' as unsigned
# due to prototype
# embed.c:149: warning: cast increases required alignment of
# target type
#
# Same as those.
#
# misc.c:431: warning: format not a string literal, argument
# types not
# checked
#
# Nothing we can do about that.
Dumb warning.
# io/io_unix.c:206: warning: comparison of unsigned
# expression = 0 is
# always
# true
Doesn't hurt to test it.
# encodings/utf32.c:62: warning: cast discards qualifiers
# from pointer
# target
# type
#
# Is this solvable?
Not unless there's a 'notconst' keyword or something. I've tried
getting rid of these, and as far as I can tell it's impossible. If
you've got something like
void foo(STRING* arg);
void bar(const STRING* arg) {
foo(arg);
}
it warns--but it does the same if you do:
foo((STRING*)arg);
I'd suggest that this be deactivated--I can't see any good coming from
it.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
Re: Reformatting code/coding standards
At 11:15 PM 3/17/2002 -0500, Bryan C. Warnock wrote: On Friday 08 March 2002 23:02, Melvin Smith wrote: I vote for non-enforcement of this one. Er, did you mean removal? Having rules that aren't enforced is counter-productive in the long run. No, I meant, I want a special get out of jail free card. :) Anyway, this particular formatting topic has been fought tooth and nail just like many others on many other forums, however, I'm not one to be quiet about losing little freedoms either. The argument for this little coding standard is: I want to be able to find function Foo by saying: grep ^Foo. So I have to write void Foo() instead of void Foo() That is ALL it is useful for, in my opinion, and that is not enough for me to write in a style that is generally against the grain. I come from the linux-kernel-dev boot camp, where most of the coding standards are for putting as many lines of code on a screen as is reasonably readable. Cuddled elses are so snuggly. -Melvin
Re: Solaris8 32bit GCC3.0.3 on 64bit Ultra10 OK but...
as you add 2 boolean fields, then you lose. Where is my grammar cap? As soon as you add 1 boolean you lose. +2 would put you back to where you started. -Melvin
Re: 64 bit Debian Linux/PowerPC OK but very noisy
On Sun, Mar 17, 2002 at 09:21:12PM -0800, Brent Dax wrote: # Remember, I am not a C programmer. I just took my perl 5.6.1 that's # compiled with 64 bit ints and ran Configure.pl with it. Okay. When Configure asks: How big would you like integers to be? [long long] just type 'long' (without quotes) and hit enter. You won't get 64-bit support, but you will get a building Parrot, which is usually a good thing. ;^) Well, the point isn't that Parrot builds. The point is that Configure should DWIM when I throw it Interesting (in the Chinese sense) perl configurations. Currently it doesn't. If Parrot is busted wrt 64 bit ints on 32 bit platforms, could Configure just throw a warning? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One rocking chairIn the old days (say, Amiga :-) we had only kilobytes of stack. And the road to school was surrounded by hungry wolves. And it was steep uphill. Both ways./rocking chair -- Jarkko Hietaniemi in [EMAIL PROTECTED]
RE: 64 bit Debian Linux/PowerPC OK but very noisy
Michael G Schwern:
# On Sun, Mar 17, 2002 at 09:21:12PM -0800, Brent Dax wrote:
# # Remember, I am not a C programmer. I just took my perl
# 5.6.1 that's
# # compiled with 64 bit ints and ran Configure.pl with it.
#
# Okay. When Configure asks:
#
# How big would you like integers to be? [long long]
#
# just type 'long' (without quotes) and hit enter. You won't
# get 64-bit
# support, but you will get a building Parrot, which is usually a good
# thing. ;^)
#
# Well, the point isn't that Parrot builds. The point is that Configure
# should DWIM when I throw it Interesting (in the Chinese sense) perl
# configurations. Currently it doesn't.
#
# If Parrot is busted wrt 64 bit ints on 32 bit platforms, could
# Configure just throw a warning?
How do we detect if you've chosen a 64-bit int type? How do we detect
if we're on a 32-bit platform?
Actually, I may have just figured out how to do this. Nevermind. ;^)
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
