Re: [perl #37934] [TODO] build - log file
On Fri, Feb 06, 2009 at 06:35:05PM -0800, James Keenan via RT wrote: On Fri Jan 11 13:17:38 2008, jhobl...@ifa.hawaii.edu wrote: A log would be useful if it contained sufficient information to figure out why a test passed or failed. Similar to autoconf's config.log (an invaluable debugging tool when tracking down configuration problems). Is there any reason why this wouldn't suffice: perl Configure.pl --test --verbose 21 | tee myconfiglog Even that would be helpful but do you really want to document that for every possible shell that a user might be using and then have to point people at that document constantly? In my expirence it's nice to be able to just ask people to attach config.log from the build dir. For some time now, we've also had Parrot::Configure::Trace, which enables you to say: perl Configure.pl --configure_trace ... and then run methods to extract information about the status of the Parrot::Configure object as it changes between configuration steps. That's exactly the sort of verbosity that you want to go into a log file. -J --
Re: [perl #38124] [TODO] build - header file detection w/o perl5
On Fri, Feb 06, 2009 at 06:44:47PM -0800, James Keenan via RT wrote: On Sun Jan 01 19:09:51 2006, jhobl...@ifa.hawaii.edu wrote: auto::headers uses the Config module to detect installed header files. It's ok to get default values and the arch name from Config but it's not OK to depend on it for probing the system as the Configure code will liked be compiled down to PIR someday so it can be executed by miniparrot and systems that don't have perl5 installed. We've long recognized that we will eventually have to jettison our reliance on Perl 5's Config module, not just for header detection but for all of our configuration probes. But that's a post-1.0 project. Are we closing all bugs for things that aren't going to be part of a 1.0 release? -J --
Re: [perl #37933] [TODO] build - tracing cleanup
On Fri, Feb 06, 2009 at 06:37:41PM -0800, James Keenan via RT wrote: On Wed Dec 14 02:04:12 2005, jhobl...@ifa.hawaii.edu wrote: - The debugging traces could be neater Are you talking about the Parrot debugger? gdb backtraces? The w/ glibc stack backtracing that I implimented a couple of years ago. -J --
Re: Parrot with llvm-gcc 4.2
Since llvm-gcc uses the gcc front end this isn't surprising. In fact, if parrot failed to build with that compiler it would only tell us that there is something wrong with their intergration work. IMHO it would be more interesting to test with clang which might actually pick up some sort of portability issue (or just bugs in clang). -J -- On Fri, Aug 01, 2008 at 12:18:39AM +0200, Moritz Lenz wrote: As a followup I added a line to PLATFORMS, as particle and Coke requested. I also ran the benchmark tests with an optimized build both with llvm-gcc 4.2 and ordinary gcc 4.2, here is what I get: ordinary gcc: real1m29.733s user1m22.489s sys 0m7.024s llvm-gcc: real1m55.984s user1m45.987s sys 0m7.588s (llvm is version 2.2). Not better either, but Reini told me that llvm 2.3 might be better. I also did a 'make testexec' on unoptimized builds, and got tons of test errors with both compilers. -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Parrot with llvm-gcc 4.2
On Fri, Aug 01, 2008 at 12:47:28AM +0200, Moritz Lenz wrote: Joshua Hoblitt wrote: Since llvm-gcc uses the gcc front end this isn't surprising. Considering that perl 5 doesn't work with XS modules when compiled with llvm-gcc, I think it's at least worth to mention ;-) I didn't say it wasn't a usefull exercise for finding bugs in llvm-gcc. ;) In fact, if parrot failed to build with that compiler it would only tell us that there is something wrong with their intergration work. IMHO it would be more interesting to test with clang which might actually pick up some sort of portability issue (or just bugs in clang). Go right ahead ;-) It's not going to be me but if someone else is interested you can fetch the code from here: http://clang.llvm.org/ It's rumored that this will be the compiler shipped with the next major version of Xcode, so the OSX folks might want to give this a try. -J --
Re: GCC 4.4
http://gcc.gnu.org/gcc-4.4/changes.html I'm sure the intel specific AES acceleration will come in real handy. ;) On Thu, May 08, 2008 at 10:39:29PM -0500, Andy Lester wrote: I've just built the 5/2/2008 snapshot of GCC 4.4 and Parrot builds fine on it. I wonder what new warning flags 4.4 has that I can exploit. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: [perl #38194] [TODO] build - optimize pmc2c.pl
On Sun, Mar 23, 2008 at 06:21:38PM -0700, James Keenan via RT wrote: On Sat Mar 22 10:38:42 2008, doughera wrote: Just be careful that 'use lib' doesn't look outside of the parrot source tree. If pmc2c.pl is normally invoked from the root directory, then ../lib and ../../lib are looking outside of the parrot source. This is wrong, since there is no guarantee that stuff stored in ../../lib is even remotely suitable for parrot, or indeed for any other use. Suppose that at the top of tools/build/pmc2c.pl, we simply state this: use Getopt::Long (); use FindBin qw($Bin); use lib $Bin/../../lib; use Parrot::Pmc2c::Pmc2cMain (); $Bin here is tools/build/. We go two levels up, then back down to the lib/ underneath the top-level Parrot directory. That lib/ is the one in which we'll start looking for Parrot::Pmc2c::Pmc2cMain. So that should mean we're not looking in the wrong places -- correct? Off hand, that sounds right. To see real gains here we need to avoid loading FindBin.pm completely. So it'll need to be require()'d if the correct information hasn't been passed in. -J -- pgpClNRxiHUEB.pgp Description: PGP signature
Re: [perl #38194] [TODO] build - optimize pmc2c.pl
James, Profiling is generally done with Devel::Profile. http://search.cpan.org/~jaw/Devel-Profile-1.05/Profile.pm Since pmc2c.pl is invoked so many times in the build process improving it's performance would sustainably speed up the overall build time. Cheers, -J -- On Mon, Mar 17, 2008 at 04:31:17PM -0700, James Keenan via RT wrote: On Mon Jan 09 17:05:30 2006, [EMAIL PROTECTED] wrote: Simple profile suggests that pmc2c.pl is spending about 25% of it's total execution time loading FindBin. The lib path use of FindBin::Bin can be replaced with 'use lib qw( . lib ../lib ../../lib );' while the other uses of FindBin::Bin will have be replaced by values that are interpolated by genfile(). Joshua, Do you know if this profiling is still needed? Here's where I find FindBin in files underlying tools/build/pmc2c.pl: $ fnsa lib/Parrot/Pmc2c/ '*.pm' | xargs grep -in FindBin lib/Parrot/Pmc2c/Pmc2cMain.pm:6:use FindBin; lib/Parrot/Pmc2c/Pmc2cMain.pm:91:( ., $FindBin::Bin/../.., $FindBin::Bin/../../src/pmc/ ); lib/Parrot/Pmc2c/Pmc2cMain.pm:103: $self-dump_vtable($FindBin::Bin/../../src/vtable.tbl); If so, can you post your standard profiling command(s)? Thank you very much. kid51 pgpXawHac3bVa.pgp Description: PGP signature
Re: [perl #49762] [configure] JIT configuration problems on OS X
I found someone in my office with Leopard on their laptop. I'll try to take a stab at this over the weekend. -J -- On Tue, Jan 15, 2008 at 02:02:32PM +0900, Simon Cozens wrote: Joshua Hoblitt via RT wrote: What is the OSX toolchain solution for inline asm with fat binaries? Architecture-specific ifdefs. gcc -arch ppc -arch i386 will run the compile twice, and then bundle the two results together, so ifdefs will do the right thing. At some point we have to assume that people who are setting CFLAGS know what they are doing. I am not setting CFLAGS. Configure is. 'perl Configure.pl' on OS X Leopard will try to build fat binaries by default. This is not me doing anything clever; it's just a plain old-fashioned configure bug. pgpsgiZ4amtjF.pgp Description: PGP signature
Re: [perl #49762] [configure] JIT configuration problems on OS X
What is the OSX toolchain solution for inline asm with fat binaries?
At some point we have to assume that people who are setting CFLAGS know
what they are doing. We can't look for or protect against every silly
thing they might do. Perhaps if --jitcapable is set and we're on darwin
the thing to do is print a warning about fat binaries and --jitcapable
being mutually exclusive things.
-J
--
On Mon, Jan 14, 2008 at 08:18:02AM -0800, Simon Cozens wrote:
# New Ticket Created by Simon Cozens
# Please include the string: [perl #49762]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49762
osname= darwin
osvers= 9.0
arch= darwin-thread-multi-2level
cc= cc
---
Flags:
category=core
severity=medium
ack=no
---
Configuring with --jitcapable will fail on OS X with the following
error:
{standard input}:94:Invalid mnemonic 'ret'
I am on an Intel Mac, and 'ret' is a valid mnemonic for Intel assembler.
The problem is that my CFLAGS are set by default to
cc -I./include -arch i386 -arch ppc ...
And 'ret' is not a valid mnemonic for PPC assembler. Good luck writing
assembly code which compiles under both i386 and PPC architectures. If
you want the JIT core, you can't have a fat binary Parrot; if
--jitcapable is set, the CFLAGS need to be adjusted to only contain one
architecture.
---
Summary of my parrot 0.5.1 (r24853) configuration:
configdate='Mon Jan 14 14:37:05 2008 GMT'
Platform:
osname=darwin, archname=darwin-thread-multi-2level
jitcapable=1, jitarchname=i386-darwin,
jitosname=DARWIN, jitcpuarch=i386
execcapable=1
perl=perl
Compiler:
cc='cc', ccflags='-arch i386 -arch ppc -g -pipe -fno-common
-no-cpp-precomp -Wdeclaration-after-statement -I/usr/local/include -pipe
-fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED
-DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL
-DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED
-DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -W -Wall
-Waggregate-return -Wbad-function-cast -Wcast-align -Wcast-qual
-Wchar-subscripts -Wcomment -Wdeclaration-after-statement
-Wdisabled-optimization -Wextra -Wformat-nonliteral -Wformat-security
-Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int
-Wimport -Winit-self -Winline -Winvalid-pch -Wmain -Wmissing-braces
-Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs
-Wmissing-prototypes -Wnested-externs -Wno-endif-labels -Wno-shadow
-Wno-unused -Wnonnull -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type
-Wsequence-point -Ws
ign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default
-Wtrigraphs -Wundef -Wunknown-pragmas -Wvariadic-macros -Wwrite-strings',
Linker and Libraries:
ld='c++', ldflags='-arch i386 -arch ppc -L/usr/local/lib
-L/Users/simon/svn/parrot/blib/lib -flat_namespace -L/sw/lib -L/sw/lib',
cc_ldflags='',
libs='-lm -lutil'
Dynamic Linking:
share_ext='.dylib', ld_share_flags='-dynamiclib -undefined suppress',
load_ext='.bundle', ld_load_flags='-bundle -undefined suppress'
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
---
Environment:
DYLD_LIBRARY_PATH (unset)
HOME =/Users/simon
LANG =C
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH
=/sw/bin:/sw/sbin/:/Users/simon/bin:/sw/bin:/sw/sbin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/usr/local/bin:/usr/local/teTeX/bin/i386-apple-darwin-current:/usr/X11/bin:/usr/local/teTeX/bin/i386-apple-darwin-current
SHELL =/bin/zsh
Re: [perl #37934] [TODO] build - log file
A log would be useful if it contained sufficient information to figure out why a test passed or failed. Similar to autoconf's config.log (an invaluable debugging tool when tracking down configuration problems). -J -- On Fri, Jan 11, 2008 at 12:51:11PM -0800, James Keenan via RT wrote: Can someone describe more specifically what we would need in a log file?
Re: [perl #44607] [CAGE] Hoist slurp_file() into Parrot::Util
On Tue, Aug 14, 2007 at 07:11:36AM -0700, jerry gay wrote: i started Bundle::Parrot to work towards the goal of removing all external modules from the parrot repository. external modules don't belong in the repository unless we need to fork them from their CPAN version. unfortunately, this work has not been completed. Particle++ the idea is that anybody who wants to develop parrot can install Bundle::Parrot from CPAN, and then run through the config/build/test cycle without requiring any other modules. this requires that Bundle::Parrot contain all necessary modules for those tasks. however, it does not require that every nifty module that might in some way benefit parrot should be added to Bundle::Parrot--we're trying to keep this distro (and requirements for developing parrot) lightweight. ~/parrot $ grep -iR Parrot::Bundle docs (notta) I think we should just change the install docs now to say the installing Parrot::Bundle is a prereq to building Parrot and that the bundle will need to be reinstalled periodically (perhaps we could add a test to check for the right versions of modules to be installed). work to be done involves assessing what modules are missing from Bundle::Parrot and adding them. also, testing config/build/test and other development tasks with only core perl and Bundle::Parrot--removing external modules contained in the parrot repository. documentation somewhere inside the parrot repository should mention Bundle::Parrot and how to get it once it's truly required. although i started the work, all of the parrot release managers share co-maintainership, so no one person should be a bottleneck if patches are submitted via parrotbug. A pointer to where the source code lives would be nice. ;) -J -- pgpWcBzzekZyt.pgp Description: PGP signature
Re: [perl #44607] [CAGE] Hoist slurp_file() into Parrot::Util
Why not just pull Slurp or File::Slurp into the tree? Yes, writing a slurp function is trivial but (bare with me here) if it's non-trivial enough to be factored out into a module then it should be non-trivial enough to not re-invent the wheel. -J -- On Mon, Aug 13, 2007 at 07:38:36AM -0700, Andy Lester wrote: # New Ticket Created by Andy Lester # Please include the string: [perl #44607] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44607 Pull slurp_file out of Parrot::Test into Parrot::Util. Then, remove the cut'n'pasted copy called _slurp_file() in config/auto/attributes.pm. -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance pgpGSpeWv6yPo.pgp Description: PGP signature
Re: [perl #44499] Move cstrings to String Structure
On Wed, Aug 08, 2007 at 12:17:17AM -0700, chromatic wrote: The string_from_cstring() function has a slight flaw, in that it has to allocate a piece of memory and create a C-style string from a nice happy STRING. It's the responsibility of the caller to discard the C string appropriately. This is tricky if that string immediately gets passed to real_exception() or some other C function which does not return control; there's no chance to free the string with string_cstring_free(). I hate to sound like the nag here but why don't we just not write code in form 'real_exception(string_from_cstring(foo))'. Part of living with dynamic memory allocating is dealing with the line bloat of shoving that free() call in there. -J -- pgpK4Gu6dTBnK.pgp Description: PGP signature
Re: should Parrot_confess() call abort()? was Re: Thank you so much Josh Hoblitt for the backtracing
Sold. commited as r20532.
-J
--
On Sat, Aug 04, 2007 at 12:57:25PM -0700, chromatic wrote:
On Thursday 02 August 2007 16:39:07 Joshua Hoblitt wrote:
Does anyone object to this patch?
Index: exceptions.c
===
--- exceptions.c(revision 20408)
+++ exceptions.c(working copy)
@@ -771,7 +771,7 @@
{
fprintf(stderr, %s:%u: failed assertion '%s'\n, file, line,
cond);
Parrot_print_backtrace();
-exit(EXIT_FAILURE);
+abort();
}
+1
-- c
pgpgAqVciG4SZ.pgp
Description: PGP signature
Re: [Win32] There's a new compiler in town (sort of)
Hi Ron, Can you submit a patch for the PLATFORMS file? -J -- On Tue, Aug 07, 2007 at 07:05:18PM +0200, Ron Blaschke wrote: jerry gay wrote: On 8/7/07, Ron Blaschke [EMAIL PROTECTED] wrote: Microsoft is working on the next iteration of their compiler, Visual C++ 9.0, currently in Beta2. Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.20706.01 for 80x86 The current setup is: Visual Studio 2008 Beta2 Subversion 1.4.4 Perl 5.8.8 Parrot r20516 It builds right out of the box. Here's the test summary. All tests successful, 25 tests and 627 subtests skipped. Files=307, Tests=7233, 944 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) excellent news! would you also report on an optimized build? in the past, we've had problems with msvc compiling in different behavior wrt -0.0 support in optimized builds. Looks quite good, nothing unexpected. file_metadata.t fails because I did another svn up which brought in t/configure/024-version.t with wrong Subversion properties. shootout.t fails as usual with optimized Win32 builds. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/distro/file_metadata.t3 768 43 75.00% 1-3 t/examples/shootout.t 10 256020 10 50.00% 1 3 7-10 14-15 17-18 25 tests and 627 subtests skipped. Failed 2/308 test scripts, 99.35% okay. 13/7235 subtests failed, 99.82% okay. NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff' Stop. i'll likely install this beta myself someday soon and test things out similarly on x86_64. Great! Ron pgpT7DP9e12PY.pgp Description: PGP signature
should Parrot_confess() call abort()? was Re: Thank you so much Josh Hoblitt for the backtracing
Does anyone object to this patch?
Index: exceptions.c
===
--- exceptions.c(revision 20408)
+++ exceptions.c(working copy)
@@ -771,7 +771,7 @@
{
fprintf(stderr, %s:%u: failed assertion '%s'\n, file, line,
cond);
Parrot_print_backtrace();
-exit(EXIT_FAILURE);
+abort();
}
-J
--
On Mon, Jul 30, 2007 at 12:29:39PM -1000, Joshua Hoblitt wrote:
I've just commit some notes on this into docs/debug.pod along with some
instructions for getting a backtrace with gdb.
It's worth noting that assert() calls abort() while PARROT_ASSERT
currently does not so this change is not really semantically equivalent.
Some people _will want_ a core file as they are particularly useful for
tracing down intermittent issues in production systems. Perhaps we need
a runtime flag to enable/disable core dumps? I would vote for having
the dumps by default as many people (well at least me) like to
control core dumps with ulimit.
-J
--
On Fri, Jul 27, 2007 at 12:42:13AM -0400, Jeff Horwitz wrote:
very nice -- i could have used that THIS AFTEROON! :)
On Thu, 26 Jul 2007, Andy Lester wrote:
Josh putting in the new backtrace behind my new assertions makes debugging
assertions SO MUCH EASIER.
I'm gonna go s/assert/PARROT_ASSERT/ everywhere.
xoxo,
Andy
P.S. sample
# Received:
# 1..1
# Backtrace - Obtained 16 stack frames (max trace depth is 32).
# (unknown)
# Parrot_confess
# Parrot_make_COW_reference
# Parrot_String_get_string
# Parrot_set_s_p
# (unknown)
# (unknown)
# (unknown)
# (unknown)
# Parrot_runops_fromc_args
# Parrot_runcode
# (unknown)
# imcc_run
# (unknown)
# __libc_start_main
# (unknown)
# src/string.c:129: failed assertion 's'
#
# Expected:
# 1..1
# ok 1
#
# Looks like you failed 6 tests of 12.
t/pmc/exporterdubious
Test returned status 6 (wstat 1536, 0x600)
--
Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
pgpn62oisN7l5.pgp
Description: PGP signature
Re: Quality improvement in volunteer software projects
Oops, please ignore the accidental CCs. -J -- On Thu, Aug 02, 2007 at 01:35:51PM -1000, Joshua Hoblitt wrote: This is Martin Michlmayr Ph.d thesis: http://www.cyrius.com/publications/michlmayr-phd.pdf -J -- pgpht9olpUBmS.pgp Description: PGP signature
Quality improvement in volunteer software projects
This is Martin Michlmayr Ph.d thesis: http://www.cyrius.com/publications/michlmayr-phd.pdf -J -- pgpBoYLGg19Mn.pgp Description: PGP signature
Re: [perl #44353] [BUG] Configure.pl: verbose-step option not working with named step
The issue is here is that there is nothing in Configure.pl's output to
correlate the package name of the step with the output seen from a
typical run.
For example, say the test that outputs Determining architecture, OS and
JIT capability... is failing for some reason so you
want to run it verbosely? Unless you are one of the PI number of people
in the world that has fiddled with the configure steps your not going to
know that steps package name is 'auto::jit'. The current system lets
you run that step verbosely with just `perl Configure.pl
--verbose-step=jit` and it just works.
Possible ways forward:
1) Do nothing and document the behavior
2) add an additional test for a step with a package name matching the
string passed to --verbose-step
3) remove the description matching functionality
4) 2 3
5) remove --verbose-step altogether
6) remove the --verbose* options and just write a 'config.log'
on every run that can be searched with your text editor for choice.
This:
- removes code
- removes complexity
- is helpful for user support, please send me your config.log file
7) have ever configure step print it's package name as part of it's
output
My vote would be for (in order of preference) 6, 2, 1.
Cheers,
-J
--
On Thu, Aug 02, 2007 at 07:59:53PM -0700, James Keenan wrote:
# New Ticket Created by James Keenan
# Please include the string: [perl #44353]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44353
---
osname= linux
osvers= 2.6.18.3
arch= i486-linux-gnu-thread-multi
cc= cc
---
Flags:
category=core
severity=medium
ack=no
---
particle reported tonight that the --verbose-step option to Configure.pl
doesn't DWIM. It appears to work okay if you say: perl Configure.pl
--verbose-step=2, but not if you name the step:
[li11-226:parrot] 515 $ perl Configure.pl --verbose-step=init::manifest
Parrot Version 0.4.14 Configure 2.0
Copyright (C) 2001-2007, The Perl Foundation.
Hello, I'm Configure. My job is to poke and prod your system to figure
out
how to build Parrot. The process is completely automated, unless you
passed in
the `--ask' flag on the command line, in which case I'll prompt you for
a few
pieces of info.
Since you're running this program, you obviously have Perl 5--I'll be
pulling
some defaults from its configuration.
Checking
MANIFEST.done.
Setting up Configure's default
values.done.
Setting up installation
paths.done.
I think the suspect code is here. Start at line 274 of
lib/Parrot/Configure.pm:
# by description
elsif ( $description =~ /$args-{verbose_step}/ ) {
$conf-options-set( verbose = 2 );
}
I feel that the regex test in the elsif makes no sense. There's no
fundamental reason why a particular step's $description should match the
contents of $args-{verbose_step} -- which at this point should be
something like init::manifest.
Amazingly, this bad code has been in this package since before I began
to maintain it ... and because (a) no one complained until now and (b) I
didn't write a test, no one ever noticed.
Assignment: Get the --verbose-step option working with a named step.
---
Summary of my parrot 0.4.14 (r20439) configuration:
configdate='Fri Aug 3 02:54:55 2007 GMT'
Platform:
osname=linux, archname=i686-linux
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/usr/local/bin/perl
Compiler:
cc='cc', ccflags=' -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE',
Linker and Libraries:
ld='cc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
---
Environment:
HOME =/home/jimk
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH
=/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/mysql/bin:/home/jimk/bin:/home/jimk/bin/perl
SHELL =/bin/bash
pgpmawiJduTaG.pgp
Description: PGP signature
Re: Floating point comparisons
I'm not sure if 0.0 == -0.0 is true on all platforms. It should be for
IEEE754 compliance but in the real world...
It might be nice to throw in a few tests to see if the example code
below would have the same results on all platforms.
--
#include stdio.h
#include math.h
int main ()
{
printf(0.0 : %f\n, 0.0);
printf(-0.0 : %f\n, -0.0);
printf(0.0 == -0.0 : %d\n, 0.0 == -0.0);
}
--
-J
--
On Wed, Aug 01, 2007 at 08:38:15AM +0200, Paul Cochrane wrote:
A couple of comments on dealing with floats.
- Use FLT_EPSILON/DBL_EPSILON from float.h
- You method is total overkill, return (fabs(x - y) DBL_EPSILON ? 1 : 0);
should be sufficent (note: check with a numerical expert).
This is what I thought in the beginning. However, whether one uses
FLT_EPSILON or DBL_EPSILON depends upon the type of the numbers used
(float or double), so there wasn't a nice general solution. Anyway, I
thought it best to ask on list before I started implementing stuff.
:-)
- What about NANs and INFs? I typical test for one of the values being
NAN but allow INFs to be compared.
Andy Lester's post mentioned that we're only comparing against zero in
each instance so we don't really need the general solution and so
shouldn't need to worry about this case.
Paul
pgpX11dZEkd8H.pgp
Description: PGP signature
Re: Floating point comparisons
A couple of comments on dealing with floats.
- Use FLT_EPSILON/DBL_EPSILON from float.h
- You method is total overkill, return (fabs(x - y) DBL_EPSILON ? 1 : 0);
should be sufficent (note: check with a numerical expert).
- What about NANs and INFs? I typical test for one of the values being
NAN but allow INFs to be compared.
-J
--
On Tue, Jul 31, 2007 at 07:17:15PM +0200, Paul Cochrane wrote:
Hi all,
I'm wanting to remove all the floating point comparison warnings which
appear when compiling parrot and wanted some advice as to how best to
achieve this.
Floating point comparisons appear in code such as (taken from src/string.c):
if (*p == '-' f == 0.0)
I'd like to replace this with
if (*p == '-' is_float_equal(f, 0.0))
where
#define EPSILON 0.005
INTVAL is_float_equal(FLOATVAL x, FLOATVAL y)
{
return (fabs(x - y) = fabs(x + y)*EPSILON) ? 1 : 0;
}
(this code was adapted from equivalent fortran code given here:
http://www.lahey.com/float.htm courtesy of particle++).
Is this a good way to achieve the goal of safe floating point
comparisons? The #define and function need to go somewhere. Where
exactly? And which header gets the declaration? parrot.h? Is there
a better way to do this? Could/should I be using a macro instead?
Thanks heaps in advance!
Paul
pgppSAERTSuvh.pgp
Description: PGP signature
Re: Floating point comparisons
Another issue to consider...
http://www.cygnus-software.com/papers/comparingfloats/Comparing%20floating%20point%20numbers.htm#_Toc135149458
-J
--
On Tue, Jul 31, 2007 at 08:46:41AM -1000, Joshua Hoblitt wrote:
A couple of comments on dealing with floats.
- Use FLT_EPSILON/DBL_EPSILON from float.h
- You method is total overkill, return (fabs(x - y) DBL_EPSILON ? 1 : 0);
should be sufficent (note: check with a numerical expert).
- What about NANs and INFs? I typical test for one of the values being
NAN but allow INFs to be compared.
-J
--
On Tue, Jul 31, 2007 at 07:17:15PM +0200, Paul Cochrane wrote:
Hi all,
I'm wanting to remove all the floating point comparison warnings which
appear when compiling parrot and wanted some advice as to how best to
achieve this.
Floating point comparisons appear in code such as (taken from src/string.c):
if (*p == '-' f == 0.0)
I'd like to replace this with
if (*p == '-' is_float_equal(f, 0.0))
where
#define EPSILON 0.005
INTVAL is_float_equal(FLOATVAL x, FLOATVAL y)
{
return (fabs(x - y) = fabs(x + y)*EPSILON) ? 1 : 0;
}
(this code was adapted from equivalent fortran code given here:
http://www.lahey.com/float.htm courtesy of particle++).
Is this a good way to achieve the goal of safe floating point
comparisons? The #define and function need to go somewhere. Where
exactly? And which header gets the declaration? parrot.h? Is there
a better way to do this? Could/should I be using a macro instead?
Thanks heaps in advance!
Paul
pgpBPJipKUywR.pgp
Description: PGP signature
Re: Thank you so much Josh Hoblitt for the backtracing
I've just commit some notes on this into docs/debug.pod along with some instructions for getting a backtrace with gdb. It's worth noting that assert() calls abort() while PARROT_ASSERT currently does not so this change is not really semantically equivalent. Some people _will want_ a core file as they are particularly useful for tracing down intermittent issues in production systems. Perhaps we need a runtime flag to enable/disable core dumps? I would vote for having the dumps by default as many people (well at least me) like to control core dumps with ulimit. -J -- On Fri, Jul 27, 2007 at 12:42:13AM -0400, Jeff Horwitz wrote: very nice -- i could have used that THIS AFTEROON! :) On Thu, 26 Jul 2007, Andy Lester wrote: Josh putting in the new backtrace behind my new assertions makes debugging assertions SO MUCH EASIER. I'm gonna go s/assert/PARROT_ASSERT/ everywhere. xoxo, Andy P.S. sample # Received: # 1..1 # Backtrace - Obtained 16 stack frames (max trace depth is 32). # (unknown) # Parrot_confess # Parrot_make_COW_reference # Parrot_String_get_string # Parrot_set_s_p # (unknown) # (unknown) # (unknown) # (unknown) # Parrot_runops_fromc_args # Parrot_runcode # (unknown) # imcc_run # (unknown) # __libc_start_main # (unknown) # src/string.c:129: failed assertion 's' # # Expected: # 1..1 # ok 1 # # Looks like you failed 6 tests of 12. t/pmc/exporterdubious Test returned status 6 (wstat 1536, 0x600) -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance pgpgHfmA8KjDc.pgp Description: PGP signature
Re: Is Parrot 1.0 too late?
On Wed, Apr 25, 2007 at 06:20:55PM +0100, Jonathan Worthington wrote: Allison Randal wrote: Nicholas Clark wrote: I guess that the most obvious current thing that ties Parrot to the Perl community is that Parrot requires a copy of Perl to bootstrap, and all the build tools are written in Perl 5. This is slated to change before the 1.0 release. I guess that doing so will involve re-writing a lot of the current Configure system and build tools into something that compiles down to PBC (and then just ship something very basic that can run a PBC). I don't think PIR is the thing to translate them to though - Configure and the build tools are fairly big things. You don't want to be doing that in an intermediate language. Well, I sure don't anyway, and I'm sure I'm not alone in feeling this way. I believe that the intent, or at least my intent, was for the Perl5 cod to be compiled down to PBC that was shipped with the distribution to be executed via miniparrot. Of course, configuring miniparrot without Configure is an unsolved problem. -J -- pgp8tY3fuvJhP.pgp Description: PGP signature
Re: Limiting Exported Symbols on GCC
On Thu, Apr 12, 2007 at 04:56:15PM +0200, [EMAIL PROTECTED] wrote: On Thu, Apr 12, 2007 at 09:13:14AM -0500, Steve Peters wrote: On Thu, Apr 12, 2007 at 01:37:24PM +0200, Ron Blaschke wrote: While poking the GCC documentation I found that there's a feature available to limit the exported symbols (with GCC = 3.3). Maybe worth considering? It's probably a design decision. If there's an option to limit the exported symbols or make all available, which one should be taken? http://gcc.gnu.org/wiki/Visibility http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Function-Attributes.html#Function-Attributes This can be done by adding C-fvisibility=hidden to CFLAGS and setting PARROT_API to C__attribute__ ((visibility(default))). I think that we need to tread very carefully with adding additional gcc-isms to Parrot, lest we break compatibility with additional compilers even further. If Parrot will run everywhere, we need to think about working more towards ANSI and POSIX compliance. I think that the same effect can be achieved using a linker script (although I don't know much about them), in wich case you are not depending on a compiler feature. ld scripts have non-portability issues as well. At my day job, we make heavy use of gcc attributes protected in #ifdef blocks. E.g. ... #ifdef __GNUC__ ) __attribute__((format(printf, 6, 7))); #else // __GNUC__ ); #endif // __GNUC__ While this certainly does clutter up the headers we've decided that the additional features, optimization, error checking allowed by the use of attributes are worth it. Machine generating the headers would be better but we don't have to support non-POSIX like platforms so it hasn't been worth the effort. My guess is that the majority of Parrot users are building it with gcc and just the extra error checking possible from using a rich set of attributes would benefit all platforms (compile time NULL checking, etc.). In fact, I'd vote for using the literal gcc attribute syntax without protective #ifdefs and then mangling and/or removing unsupported constructs for the target platform. -J -- pgpoVwlFWisva.pgp Description: PGP signature
Re: [perl #40803] [BUG] 'make' fails on Darwin at -lgmp
I believe that the attachment containing your make output was truncated. Can you try again or just inline the make error(s)? Thanks, -J -- On Fri, Nov 10, 2006 at 06:10:42PM -0800, James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #40803] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40803 This transaction appears to have no content pgpfRoTBB2miJ.pgp Description: PGP signature
Re: socket related constants
On Thu, Sep 28, 2006 at 09:36:13AM +0100, Nicholas Clark wrote: However, step 2 is easier for Perl because we're not trying to do portable bytecode. Some constants, (such as *most* of the socket constants, but I think not all) are defined in RFCs, so can be baked into bytecode at compile time. But other constants (such as POSIX limits) are per system, so a complete solution needs a way of knowing how to defer baking those constants until load time. Or maybe it doesn't call them constant as far as bytecode interpretation goes, but any JIT or AOT can see that they are, and treat them accordingly. Mentioning sockets got me thinking about APR... Has anyone seriously looked at using it for doing portable I/O? -J -- pgpYE95rRAqhn.pgp Description: PGP signature
Re: PDD 22 - I/O release candidate 1
On Tue, Sep 26, 2006 at 04:44:53PM -0700, Allison Randal wrote: One piece that is currently missing is a discussion of which lightweight concurrency model we're going to use for the asynchronous operations. I've had ongoing back-channel conversations with various people, but I need to congeal them. Pitch in your own 2 cents. Are you referring to the Parrot side API, the actual implementation, or both? As for the implementation side, my gut feeling is that this is going to need to be highly platform specific. For example, on Linux using POSIX aio (assuming a new enough kernel) is probably going to incur much less over head then either clone(2) or POSIX threads. As a point of reference I believe Linux::AIO uses clone(2) but it predates the POSIX aio layer. -J -- pgpUrtz0sRife.pgp Description: PGP signature
Re: [perl #40253] [PATCH] always cast printf(%p) to (void *)
Aww - I was wondering if it was gcc 4. gcc 3.4 seems to let that one by. -J -- On Thu, Aug 31, 2006 at 10:20:39AM -0400, Will Coleda wrote: gcc 4.0.1, os x 10.4.7, PPC, ccflags .= -pipe -fno-common -Wno-long- double -Wno-long-long -std=c89 -pedantic ; (which is still too many warnings, but leo noted this particular one could stand to be fixed, as time permits.) On Aug 31, 2006, at 5:34 AM, Joshua Hoblitt wrote: What compiler is generating warnings? -J -- On Tue, Aug 29, 2006 at 07:03:44PM -0700, Will Coleda wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #40253] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40253 The attached patch casts all the printfs arguments corresponding to % p to be (void *), to avoid compiler warnings. However, the following tests fail after the change: Failed Test Stat Wstat Total Fail Failed List of Failed - --- --- t/dynoplibs/myops.t 1 256 71 14.29% 6 t/examples/library.t1 256 41 25.00% 3 t/library/pcre.t1 256 11 100.00% 1 I leave it to the determined reader to figure out why. =-) -- Will Coke Coleda [EMAIL PROTECTED] pgp7PUmmlVtLu.pgp Description: PGP signature
Re: [perl #40253] [PATCH] always cast printf(%p) to (void *)
What compiler is generating warnings? -J -- On Tue, Aug 29, 2006 at 07:03:44PM -0700, Will Coleda wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #40253] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40253 The attached patch casts all the printfs arguments corresponding to % p to be (void *), to avoid compiler warnings. However, the following tests fail after the change: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/dynoplibs/myops.t 1 256 71 14.29% 6 t/examples/library.t1 256 41 25.00% 3 t/library/pcre.t1 256 11 100.00% 1 I leave it to the determined reader to figure out why. =-) -- Will Coke Coleda [EMAIL PROTECTED] pgpJ3armWHFIg.pgp Description: PGP signature
Re: [perl #40225] Making Makefiles...
On Wed, Aug 23, 2006 at 02:24:45PM -0400, Will Coleda wrote: To sum up: for now, I'm working on being able to support: $(addprefix runtime/builtin,$(notdir $(wildcard languages/tcl/ runtime/builtin/*.pir))) Which looks like gmake, but will be expanded at config time: once we fixup where/when language makefiles are generated, this will simplify to: $(wildcard runtime/builtin/*.pir) I think it's a mistake to use a make-like syntax. That's just going to lead to maintenance confusion down the road. Someone, someday is going to change it thinking that's it's just GNU make syntax. Why don't you just embed blocks of Perl code instead of inventing a new syntax? -J -- pgpDHqnqy4gPJ.pgp Description: PGP signature
Re: [svn:parrot-pdd] r14308 - in trunk: . cage docs docs/art docs/dev docs/imcc docs/pdds docs/pdds/clip docs/stm languages languages/tcl/docs lib/Pod/Simple t/distro
I hope you didn't do that by hand. I wrote a utility last Dec. specifically for formatting Parrot's Pod. http://search.cpan.org/~jhoblitt/Pod-Tidy-0.09/ -J -- pgp5clC56Bbat.pgp Description: PGP signature
Re: multi-line comments, C macros, Pod abuse
On Mon, Aug 21, 2006 at 12:06:36AM +0100, Andrew Suffield wrote:
On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
Why would you care about introducing a new lexical scope? You would
care about that if you used a variable you declared in the commented
code in the code below it, which is broken.
Typically because you have several versions that you want to switch
between, and you'd rather add a few characters of comment rather than
spend the time rearranging the code to use ifs or subs or
something. It's something you might do when debugging or experimenting
(especially under time pressure) - at least, that's how I use '#if 0'
in C.
The more I think about this issue the more I realize that this is really
a very simple case of metaprogramming. Which got me thinking about more
sophisticated compile time flow control. I imagine that defining
something like a compile time switch switch statement is possible with
the existing macros. Would anyone like to take a shot at defining a
macro to do this? Is it possible to jump to something outside of a
macros input that is also evaluated at compile time?
Using '#END' (or rather, q:to'#END') is actually not that bad an
idea... it'd work in most places where #{} would give trouble. Unless
anybody has any better ideas, that could be a useful idiom to
remember.
Using heredocs for commenting code out is slightly undesirable as it
would create a branch that has to be tested at runtime. One would hope
that the compiler would note the conditional on a constant and throw the
heredoc out as dead code but it certainly feels untidy.
-J
--
pgpcqMt6FTL6p.pgp
Description: PGP signature
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 07:28:14PM +0200, Leopold Toetsch wrote: Am Montag, 21. August 2006 17:45 schrieb Chip Salzenberg: Well, that's fair. ?Many of us are old enough to have used such limited hardware, but it's all surely been relegated to the trashheap by now. ?So: Would anyone be inconvenienced by exceeding 80 columns regularly; and, how? 80, or 100, or 132 are all some arbitrary limits. But the latter is already inconvenient on a 12 powermac with reasonable font size [1]. Due to the rather verbose VTABLE macros, 80 looks a bit too limited (given the impressive amount of needed code changes we got recently (ambs++ BTW)). My preference: soft limit 80 - keep lines shorter, if it's easy hard limit ~100 - you SHALL not exceed it I agree. At my $day_job we use 110 as the hard limit and this works fine for most desktop users but is rather annoying for those of us that bought 16:9 format laptops just so we can squeeze 2 x 80 column terminals side by side (at an almost legible font size). -J -- pgpiJGwdQSubD.pgp Description: PGP signature
Re: multi-line comments, C macros, Pod abuse
On Sat, Aug 19, 2006 at 02:26:28AM +, Luke Palmer wrote:
On 8/19/06, Aaron Crane [EMAIL PROTECTED] wrote:
You don't actually need a macro in that case:
if 0 { q
...
}
Which, of course, eliminates the original desire to have a
code-commenting construct where you just change the 0 to a 1. After
all, we already have #{}. Incidentally, you could consider that the
desired construct, because it balances, and a closure at statement
level executes itself:
#{
if $baz {
$foo.bar
}
}
To uncomment, remove the # before the {.
This is exactly the type of construct that I had in mind. A couple of
questions. Is code inside of a #{}:
- parsed and required to be syntacticly correct?
- does it still appear in emitted code?
- what happens when a goto tries to enter into this block
or a nested sub is invoked?
- will the optimizer spend time on this block?
-J
--
pgpq7P6vPqC0y.pgp
Description: PGP signature
multi-line comments, C macros, Pod abuse
It occurred to me that other day that in our in house C code we somewhat frequently use an idiom that's not easily translated into Perl 5. Our rule is that if your commenting out more then 1 or 2 lines of code that you wrap it in a CPP if statement. The logic being that if you haven't deleted the code then it must have some reason of hanging around (and you may actually want to use it again someday). This is most often the case with specialized debugging code. E.g. #if 0 ... #endif The great thing about this is that the you only have to flip the 0 to 1 to re-enable the code. E.g. #if 1 (magic now happens)... #endif The best equivalent I've been able to come up with in Perl 5 is: =for off ... =cut #=for off (magic now happens)... =cut Except that now this requires all sorts of weird voodoo to keep the Pod formatting from breaking. This thread seems to suggest the situation isn't going to change much if at all in Perl 6: http://groups.google.com/group/perl.perl6.language/browse_thread/thread/45f5be3ca97d1d82/cd5f1daa256be9b9?lnk=gstq=multiline+commentsrnum=1#cd5f1daa256be9b9 I guess the point I'm trying to make here is that multi-line comments about the code and disabled chunks of code are or should be distinct functionalities. One can make the argument that any code you want to disable in the manner I've described should be factored out into it's own function, so that just the call to the function can be commented out. The hard reality is that it's not always so easy or desirable to do that. Is there any hope of getting some equivalent disabled code chunk functionality in the perl6 core? Cheers, -J -- pgpbSr20Jlwrk.pgp Description: PGP signature
Re: [perl #39860] [TODO] build - Configure.pl should accept --libdir, etc.
On Tue, Jul 18, 2006 at 02:09:26AM -0700, Joshua Hoblitt wrote:
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #39860]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39860
LIB_DIR gets setup as part of the configure process which is then passed
to the install script as --libdir=$(LIB_DIR). The solution is to make
Configure.pl more autotools like in that it can accept --libdir,
--datadir, etc.
-J
--
Attached is a patch to implement autoconf compatible installation path
options. Keep in mind that this more or less just implements the
options. While all option values are stored in Parrot::Config only a
few of the values are currently used in the build process (prefix,
libdir, etc.). I'd like to get back several reports that this patch
works OK for people and actually resolves their installation issues
before applying it (please, nobody get trigger happy). I suspect
changes to root.in and the install script will be necessary to make
everyone happy. The new options will also need to be documented in
Configure.pl
Cheers,
-J
--
Index: Configure.pl
===
--- Configure.pl(revision 13980)
+++ Configure.pl(working copy)
@@ -385,6 +385,7 @@
my @steps = qw(
init::manifest
init::defaults
+init::install
init::miniparrot
init::hints
init::headers
Index: config/init/install.pm
===
--- config/init/install.pm (revision 0)
+++ config/init/install.pm (revision 0)
@@ -0,0 +1,121 @@
+# Copyright (C) 2001-2005, The Perl Foundation.
+# $Id: defaults.pm 13597 2006-07-27 16:31:35Z leo $
+
+=head1 NAME
+
+config/init/install.pm - autoconf compatabile installation paths
+
+=head1 DESCRIPTION
+
+Sets up the installation paths
+
+=cut
+
+# taken from:
+#
+# autoconf (GNU Autoconf) 2.59
+# Written by David J. MacKenzie and Akim Demaille.
+#
+# Copyright (C) 2003 Free Software Foundation, Inc.
+# This is free software; see the source for copying conditions. There is NO
+# warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# Installation directories:
+# --prefix=PREFIX install architecture-independent files in PREFIX
+# [/usr/local]
+# --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
+# [PREFIX]
+#
+# By default, `make install' will install all the files in
+# `/usr/local/bin', `/usr/local/lib' etc. You can specify
+# an installation prefix other than `/usr/local' using `--prefix',
+# for instance `--prefix=$HOME'.
+#
+# For better control, use the options below.
+#
+# Fine tuning of the installation directories:
+# --bindir=DIR user executables [EPREFIX/bin]
+# --sbindir=DIR system admin executables [EPREFIX/sbin]
+# --libexecdir=DIR program executables [EPREFIX/libexec]
+# --datadir=DIR read-only architecture-independent data
[PREFIX/share]
+# --sysconfdir=DIR read-only single-machine data [PREFIX/etc]
+# --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com]
+# --localstatedir=DIRmodifiable single-machine data [PREFIX/var]
+# --libdir=DIR object code libraries [EPREFIX/lib]
+# --includedir=DIR C header files [PREFIX/include]
+# --oldincludedir=DIRC header files for non-gcc [/usr/include]
+# --infodir=DIR info documentation [PREFIX/info]
+# --mandir=DIR man documentation [PREFIX/man]
+
+package init::install;
+
+use strict;
+use vars qw($description @args);
+
+use base qw(Parrot::Configure::Step::Base);
+
+use Parrot::Configure::Step;
+
+$description = q{Setting up installation paths};
+
[EMAIL PROTECTED] = qw( prefix exec-prefix bindir sbindir libexecdir datadir
sysconfdir
+sharedstatedir localstatedir libdir includedir oldincludedir infodir
+mandir );
+
+sub runstep
+{
+my ($self, $conf) = @_;
+
+my $prefix = $conf-options-get('prefix') || /usr/local;
+my $eprefix = $conf-options-get('exec-prefix') || $prefix;
+# --bindir=DIR user executables [EPREFIX/bin]
+my $bindir = $conf-options-get('bindir') || $eprefix . /bin;
+# --sbindir=DIR system admin executables [EPREFIX/sbin]
+my $sbindir = $conf-options-get('sbindir') || $eprefix . /sbin;
+# --libexecdir=DIR program executables [EPREFIX/libexec]
+my $sbindir = $conf-options-get('sbindir') || $eprefix . /libexec;
+# --datadir=DIR read-only architecture-independent data
[PREFIX/share]
+my $datadir = $conf-options-get('datadir') || $prefix . /share;
+# --sysconfdir=DIR read-only single-machine data [PREFIX/etc]
+my $sysconfdir = $conf-options-get('sysconfdir') || $prefix . /etc;
+# --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com
Re: Review of current stm branch code
On Thu, Aug 10, 2006 at 07:19:21PM -0700, Chip Salzenberg wrote: * enum trailing commas are not standard C89 doesn't allow enum lists to end with a comma. PITA, I know, but we can't require C99 yet. So e.g. 'thread_state_enum' needs a comma removed. Nor does C++ understand the trailing commas and I've run into this issue when trying to link C++ to C with C99 headers. -J -- pgpxHUM1uszSO.pgp Description: PGP signature
Re: Review of current stm branch code
On Thu, Aug 10, 2006 at 07:19:21PM -0700, Chip Salzenberg wrote:
* useless curlies
-if (PMC_IS_NULL(type_hash))
+if (PMC_IS_NULL(type_hash)) {
return core_type;
+}
hash = PMC_struct_val(type_hash);
-if (!hash-entries)
+if (!hash-entries) {
return core_type;
+}
Something I'm hoping to stamp out is the use of curlies for all if/else
clauses, which makes code taller without making it substantially clearer.
I'd appreciate if you'd use a no-curlies-when-possible style.
OTOH, if you don't want to do this right away, I'd be OK with a merge
first, and fixing the curlies later.
OTGH, the project needs automated filters for more coding standards,
including one that that notes (and optionally kills) the excess curlies.
This is a bad joke, right? How much of your life are you intending to
spend on chasing down hard to find missing braces bugs?
-J
--
pgpR245EXzCsy.pgp
Description: PGP signature
random thoughts on making parrot compiler faster
A significant portion of parrots build time is spent running tools/build/pmc2c.pl tools/build/c2str.pl. Neither of these programs loads Parrot::Config and there isn't/shouldn't be any system dependent behavior. Does it make sense for the code generation to be a --maintainer processes only? -J -- pgphkpvJd1LJf.pgp Description: PGP signature
Re: Questions
On Mon, Jul 31, 2006 at 10:30:36PM -0700, chromatic wrote: * What's the best way to integrate building this module from the main Makefile? Should it be part of that process? That depends. Are any of the standard regression tests going to require this module? * Where should the built module go, and how can we make that work in a cross-platform way? Copying the two (for now) necessary files out of blib/lib appropriately is probably the right answer. I'd say let Module::Build handle the install. The install process can invoke Module::Build if it's to be part of the default install. * Parrot::Embed uses Module::Build, mostly because I find EU::MM bletcherous and hateful. Porting it to EU::MM is pretty easy, but I haven't done it because it needs a custom step before testing to build a PBC file. Leaving it as it is makes maintaining it a little easier for me, but it makes M::B a dependency for building Parrot. That may or may not be an issue, depending on what Bundle::Parrot pulls in. I'll vote for adding M::B to Bundle::Parrot. -J -- pgp3vjEjBIIGO.pgp Description: PGP signature
Re: Questions
On Tue, Aug 01, 2006 at 12:30:28PM -0700, chromatic wrote: On Tuesday 01 August 2006 12:24, Joshua Hoblitt wrote: I'd say let Module::Build handle the install. The install process can invoke Module::Build if it's to be part of the default install. How about when just building Parrot but not installing it? I'd also like to run the Parrot::Embed tests as part of the normal Parrot test suite. I'm guessing that Parrot::Embed won't be the last M::B module that were going to stand to ship with Parrot. It would be nice to solve this issue in a somewhat general way so other packages can more or less be mechanically included for use. If not for installation, at least for runtime. While I'd been hoping that M::B had a public method for changing 'blib' this appears not to be the case (just looking at the pod). If this functionality were added we could have the root makefile invoke each module as `perl Build.PL --blib [buildroot/somedir]`, use that path for runtime testing, and still let M::B handle the packages own installation. I admit this scheme is a little hackish but it avoids having to do a custom setup for each bundled package. Thoughts? -J -- pgpd1yK3Vaurb.pgp Description: PGP signature
Re: Questions
On Tue, Aug 01, 2006 at 10:29:52PM -0500, Chris Dolan wrote:
On Aug 1, 2006, at 2:45 PM, Joshua Hoblitt wrote:
While I'd been hoping that M::B had a public method for changing
'blib'
this appears not to be the case (just looking at the pod). If this
functionality were added we could have the root makefile invoke each
module as `perl Build.PL --blib [buildroot/somedir]`, use that path
for
runtime testing, and still let M::B handle the packages own
installation. I admit this scheme is a little hackish but it avoids
having to do a custom setup for each bundled package. Thoughts?
That syntax works:
% perl Build.PL --blib=foobar
Checking whether your kit is complete...
Looks good
Checking prerequisites...
Looks good
Creating new 'Build' script for 'FLV-Info' version '0.11'
% ./Build
lib/FLV/File.pm - foobar/lib/FLV/File.pm
...
% perl -MModule::Build -le'print Module::Build-VERSION'
0.2801
This also works:
my $mb = Module::Build-new(
...
);
$mb-blib('foobar');
$mb-create_build_script;
Well, I guess that's what I get for reading the documentation instead of
the code. ;)
-J
--
pgpDAZkgeUy6C.pgp
Description: PGP signature
Re: PDD review, onward and upward
I'd like to see PPD 25 threads reviewed. The ruff API isn't even layed out in this document -- is there supposed to be a thread PMC or what? I'm also concerned about the performance impact of having to always check if a PMC is shared and having to spin a mutex if it is. At a minimum it should be possible at runtime to disable the automatic locking. -J -- On Sun, Jul 23, 2006 at 03:50:35PM -0700, Allison Randal wrote: I've just finished a read-through of all the PDDs (which I said I'd do by OSCON), and will check in the embedded notes I made while reading when I can connect to svn.perl.org again (known outage, nothing to worry about). The next step is to go through the PDDs one-by-one, updating/expanding them, and then moving them out of the clip directory. To make the best use of available brain power, we'll have open discussions about each PDD on the list as I review it. Starting with... drum roll... PDD 17, Basic Types. So, what's out of date, what has never been implemented (or never will be), what needs to be talked about but isn't mentioned? (The queue of PDDs to review has a semi-random order. If you'd like to see a particular PDD get bumped earlier, drop me an email.) Allison pgpKVQso7zOYz.pgp Description: PGP signature
Re: Help Understanding Configure.pl Output
On Fri, Jul 21, 2006 at 03:04:06PM -0400, Mr. Shawn H. Corey wrote: Determining if your C compiler is actually gcc.yes. Determining if your C compiler is actually Visual C++...no. Enabling optimization...no. The first two makes sense given my system: http://www.magma.ca/~shawnhcorey/2006-07/1153500473.html but what does the last mean? Does it mean only the C compiler or everything? Does it means it has disabled all optimization -O0 or using the default (which I think is -O1)? It means that no optimization is enabled and debugging information is embedded in the object files. It's virtually impossible to debug optimized code and it can dramatically increase compilation times (there are still quadratic algorithms in most compilers!). So it's reasonable to default to no optimization when a project is under heavy development. If you need the speed, pass --optimize to configure. Second: Determining if your platform supports GMP...no. Determining if your platform supports readline..no. Determining if your platform supports gdbm..no. How important are these? Parrot compiles without them but am I missing something? Those are needed for 'Big' math support, readline, and hash files. It's pretty subjective as to whether your missing that functionality or not. Cheers, -J -- pgp1WB9vHbv78.pgp Description: PGP signature
Re: [perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o
On Mon, Jul 17, 2006 at 12:11:55PM -0700, chromatic wrote: After discussing the idea with Allison, we both believe that Parrot should be able to produce a single PBC file from a command like: parrot -o all_files.pbc file1.pir file2.pir ... filen.pir It'd probably make sense to define some clear rules on how symbol conflicts are handled up front. As it's always nice to know which :main to invoke. :) A possible rule could be the version of the symbol that appears in 'left most file has precedence. Alternatively, a symbol collision could just be a fatal error. -J -- pgp9npXdqQKrR.pgp Description: PGP signature
Re: [svn:parrot] r13343 - trunk/compilers/imcc
On Tue, Jul 18, 2006 at 01:38:20AM -0700, Allison Randal wrote: [EMAIL PROTECTED] wrote: * However, the bison interface does not support both interp and yyscanner as flex inputs; so I created a patch file at compiler/imcc/imcparser.c.diff -- it needs to be applied manually whenever imcc.y is regenerated into imcparser.c. This is really suboptimal, and should be folded into the build system. But then again, $(YACC) and $(LEX) are both at this moment hard-coded to echo and not governed by the normal make rules anyway, so I'm not sure how best to address this build problem. Suggestions welcome. This is not a maintainable build solution. Revert and come back when you have one. (It's always okay to say I've gotten this far in implementation but hit a snag. Just don't commit until you resolve the snag.) FYI, $(YACC) and $(LEX) are set to useful values when --maintainer is passed to Configure.pl. If apply a patch as part of the build processes is really the only option then a conditional could be added to root.in to only apply the patch when --maintainer is in effect. -J -- pgpBcM2Cvyz4Z.pgp Description: PGP signature
Re: [perl #39867] Configure.perl --maintainer should check flex/bison versions
I believe ambs I fixed this before the bug was filed. ;) -J -- On Tue, Jul 18, 2006 at 01:31:16PM -0700, Chip Salzenberg wrote: # New Ticket Created by Chip Salzenberg # Please include the string: [perl #39867] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39867 Currently if the user has bison or flex that's too old, he won't be told, and will simply find that a maintainer build fails. Configure.perl should check that flex and bison are adequately modern to handle the imcc grammar and lexical scan. Currently required versions: flex 2.5.33 (or higher) bison 2.2 (or higher) -- Chip Salzenberg [EMAIL PROTECTED]
Re: IMCC Reentarancy
4th Option: fix flex. ;) -J -- On Sun, Jul 16, 2006 at 10:57:07PM -0500, Vishal Soni wrote: Hi, Please disregard the previous mail. Hit the wrong shortcut key!! I have been working on trying to make reenterant and/or thread-safe. There are couple of things that have come up which might make it difficult to make the existing implementation thread-safe/re-entrant. The current implementation is implemented using Flex and YACC. Flex implementation has limitations in C mode. The C lexer generated by flex cannot be reentrant/threadsafe. Flex generates thread-safe parsers only in C++ mode. This limition of flex will defeat the whole effort of removing global variables from IMCC. In my opinion if we cannot get global variable free code from flex there is no sense in proceeding with cleaning up the other global variables. Audrey Tang recommended using re2c as an alternative to flex (Lemon Parser replacement for Yacc). re2c generates reenterant/thread-safe parsers. I also spend some time reading up on the paper published with re2c. Initial indicators are that it produces scanners that run faster than flex. So here are some options that I have come up with that we have. I would like you guys and especially Allison and Chip to provide some feedback on how to proceed further. 1st Option: Hack it and patch it to death !!! --- Since flex is not generating reeentrant code, this option will get rid of flex altogether and replace it with re2c. This would require significant reworking on the code. So the plan of action would be as follows: a. Remove flex and implement re2c b. Remove static and global variables Apart from this we also need to refactor the code to get rid of arrays to a hash table implementation for macros. All in all this would be over hauling lot of code. 2nd: Inaction is the best action !!! --- Lets not do anything a leave the code as it is. Just say IMCC is not re-entrant/thread-safe and leave it there We will address this issue in future. I highly doubt it this is the route we want to take 3rd Option: Back to drawing board !!! This option would require a complete re-write of IMCC ( possibly could call it PIRC). The cons of this approach is we will have to re-implement the whole IMCC again. The programming languages will have to live with IMCC limitations as long as the new version is ready. The pros of this approach are a. A clean implementation rather than a prototypish implementation b. Make PIR compiler production release ready. The way the compiler sits right now it is not a good release candidate. c. Structure the code in a way that is easy to maintain and extend. The 3rd option is lot of work but might be a good option in the long run. These are just some of my thoughts. Please let me know what you guys think or do you have other options in mind. Whatever it is we need to come to consensus to make the IMCC reenterany a reality. As usual please provide feedback. -- Thanks, Vishal On 7/16/06, Vishal Soni [EMAIL PROTECTED] wrote: Hi, I have been working on trying to make reenterant and/or thread-safe. There are couple of things that have come up which might make it difficult to make the existing implemention thread-safe/re-entrant. The current implementation is implemented using Flex and YACC. Flex implementation has limitations in C mode. The C lexer generated by flex cannot be reentrant/threadsafe. Flex generates thread-safe parsers only in C++ mode. This limation of flex will defeat the whole effort of removing global variables from IMCC. In my opinion if we cannot get global variable free code from flex there is no sense in proceeding with cleaning up the other global variables. Audrey Tang reccomended using re2c as an alternative to flex (Lemon Parser replacemet for Yacc). re2c generates reenterant/thread-safe parsers. I also spend some time reading up on the paper published with re2c. Initial indicators are that it produces scanners that run faster than flex. So here are some options that I have come up with that we have. I would like you guys and especially Allison and Chip to provide some feedback on how to proceed further. 1st Option: Hack it and patch it to death !!! --- Since flex is not generating re-eentrant code, this option will get rid of flex altogether and replace it with re2c. This would require significant reworking on the code. So the plan of action would be as follows: a. Remove flex and implement re2c 2nd: Inaction is the best action !!! --- 3rd Option: Back to drawing board !!! -- Thanks, Vishal --
Re: Building a Fedora package
On Sat, Jul 08, 2006 at 07:01:19PM -0500, Steven Pritchard wrote: First, there is a hardcoded lib somewhere that I can't seem to find. On x86_64, libraries should get dropped in /usr/lib64, but make install never creates /usr/lib64/parrot. Pointers on how to override that would be greatly appreciated. When you say, On x86_64 I think what your really mean is a x86_64 system with multilib support. You are correct that the current build system does not support multilib builds or installs (or at least it didn't the last time I looked at it several months ago). While I don't have a recent Fedora build to look at I'd bet that /usr/lib64 on your system is actually a link to /usr/lib while /usr/lib32 is a separate directory. So there shouldn't be any issue with installing under /usr/lib. Is this the case? Cheers, -J -- pgpU2nGZlteG9.pgp Description: PGP signature
Re: [perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris
On Tue, Mar 21, 2006 at 06:42:42AM -0800, Steve Peters via RT wrote: [jhoblitt - Sun Jan 01 18:49:23 2006]: I've commited a possible fix for openbsd, cygwin, solaris as changesets r10839 r10843. I basically applied what Steve Peters proposed but with the changes in math.c instead of creating init.c (as agreed to on #parrot). This doesn't appear to have done anything for gcc/solaris... can someone test openbsd and cygwin? These changes fixed OpenBSD and were used with NetBSD to allow it to pass all of its tests. That leaves the issue open for Solaris and Cygwin. Fantastic. Thanks for the update. Can someone test this on Cygwin? -J -- pgpgBXt5TWSJG.pgp Description: PGP signature
Re: [perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris
Steve, What version of OpenBSD were you running (perhaps something old or direct from CVS)? -J -- On Tue, Mar 21, 2006 at 03:13:18PM -0800, Joshua Isom via RT wrote: On OpenBSD 3.8 x86, I still get the failures with -0.0/0.0. Check the smokes... On Mar 21, 2006, at 3:01 PM, Joshua Hoblitt wrote: On Tue, Mar 21, 2006 at 06:42:42AM -0800, Steve Peters via RT wrote: [jhoblitt - Sun Jan 01 18:49:23 2006]: I've commited a possible fix for openbsd, cygwin, solaris as changesets r10839 r10843. I basically applied what Steve Peters proposed but with the changes in math.c instead of creating init.c (as agreed to on #parrot). This doesn't appear to have done anything for gcc/solaris... can someone test openbsd and cygwin? These changes fixed OpenBSD and were used with NetBSD to allow it to pass all of its tests. That leaves the issue open for Solaris and Cygwin. Fantastic. Thanks for the update. Can someone test this on Cygwin? -J -- pgpPVlDhvis8d.pgp Description: PGP signature
Re: [perl #38597] Build broken on OS X?
I don't believe that this is the correct solution. The 'parrot' binary needs to be linked to the correct library. Currently it's being linked against /usr/local/lib/libparrot.dylib instead of blib/lib/libparrot.dylib. For some reason it does this even when blib/lib is specific to be searched first: $ c++ -o parrot -L/Users/jhoblitt/parrot/blib/lib -L/usr/local/lib\ compilers/imcc/main.o -lparrot -lm -lreadline \ src/parrot_config.o $ otool -L parrot parrot: /usr/local/lib/libparrot.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.3.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0) The fix is to figure out how to make the linker behave. -J -- On Mon, Feb 20, 2006 at 07:21:32PM -0600, Joshua Isom wrote: I've spent a lot of time looking for something that would work(and found some stuff that documentation seemed to say should work but didn't for me), and on darwin, that's the only way I know how, either that or a static parrot. The only other option I can think of that would perhaps do the trick would be far messier, i.e. have parrot load libparrot.dylib instead of link against it. On Feb 20, 2006, at 7:17 PM, Joshua Hoblitt wrote: Is there some reason that this can't be a -L flag passed to CC? IMHO - it's bad policy to go littering makefile with env variable declaration as the effect is global until the end of the makefile. -J -- On Mon, Feb 20, 2006 at 06:40:24PM -0600, Joshua Isom wrote: It was working on 11676, and I got it to build with 11686. But I notice one problem: Library not loaded: /usr/local/lib/libparrot.dylib On darwin, if you want a shared parrot, you must set DYLD_LIBRARY_PATH to include parrot's blib/lib. For tcsh(os x default), it'd be setenv DYLD_LIBRARY_PATH blib/lib:$DYLD_LIBRARY_PATH and for sh it'd be export DYLD_LIBRARY_PATH blib/lib:$DYLD_LIBRARY_PATH if you're in the parrot root directory. On Feb 20, 2006, at 5:34 PM, Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #38597] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38597 r11684 make realclean CXX='ccache g++-4.0' CC='ccache gcc-4.0' /usr/bin/perl Configure.pl --cc=$CC --cxx=$CXX --link=$CXX -- ld=$CXX --optimize --parrot_is_shared $@ Generates the following error: src/parrot_config.c 'runtime/parrot/include/config.fpmc' is truncated. Remove it and rerun make make: *** [src/parrot_config.c] Error 255 So, I follow the directions: CokeZero:~/research/parrot wcoleda$ rm runtime/parrot/include/ config.fpmc CokeZero:~/research/parrot wcoleda$ make Compiling with: xx.c ccache gcc-4.0 -I./include -g -pipe -fno-common -no-cpp-precomp -I/ usr/local/include -pipe -fno-common -Wno-long-double - DDISABLE_GC_DEBUG=1 -DNDEBUG -Os -I/sw/include -I /usr/local/include - Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer- arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return - Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat- security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno- shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c Invoking Parrot to generate runtime/parrot/include/config.fpmc -- cross your fingers ./miniparrot config_lib.pasm runtime/parrot/include/config.fpmc dyld: Library not loaded: /usr/local/lib/libparrot.dylib Referenced from: /Users/wcoleda/research/parrot/./miniparrot Reason: image not found make: *** [runtime/parrot/include/config.fpmc] Error 133 It's been this way for about a day. I can run the which revision introduced this bug if no one sees anything obvious. pgptPrr0FeGtu.pgp Description: PGP signature
Re: [perl #38597] Build broken on OS X?
On Tue, Feb 21, 2006 at 08:06:18AM -0500, Will Coleda wrote: On Feb 21, 2006, at 4:29 AM, Joshua Hoblitt wrote: I don't believe that this is the correct solution. The 'parrot' binary needs to be linked to the correct library. Currently it's being linked against /usr/local/lib/libparrot.dylib instead of blib/lib/libparrot.dylib. Not on my box, at least: ls /usr/local/lib/*parrot* ls: /usr/local/lib/*parrot*: No such file or directory /usr/local/lib doesn't even exist on my system. The linker is doing horribly bad things. Is there an OSX expert lurking this list? -J -- pgpdGSZNWjHF9.pgp Description: PGP signature
[perl #37388] [TODO] build - remove -expnetwork from Configure
This flag is in use by the inter::exp step but it's not doing much. Should this flag be kept or not? -J --
[perl #31156] [TODO] Performance - Add profiling build options
[coke - Sun Aug 15 13:41:43 2004]: Add profiling build options (From the TODO file) Is this really worth doing? Since profiling flags are compiler specific isn't it better to just let them be set as additional CFLAGS? -J --
[perl #33603] Undef != Undef
[EMAIL PROTECTED] - Wed Dec 29 18:22:10 2004]: This code: new P0, .Undef new P1, .Undef eq P0, P1, L1 print not L1: print ok\n end prints not ok. Should it? If Parrot considers every Undef PMC to be distinct, it's going to make tasks like comparing arrays with large numbers of undefined elements much fiddlier than it should be. For instance, the fact that Undef != Undef means that this code: new P0, .ResizablePMCArray set P0, 1 clone P1, P0 eq P0, P1, L1 print not L1: print ok print \n end prints not ok. Simon Can we get a design descision as to wheather or not Undef == Undef will ever have any meaning so we can close out this bug? The current beahvior of ./parrot foo.pasm MMD function __is_equal not found for types (78, 78) current instr.: '(null)' pc 6 (foo.pasm:3) seems wrong to me any way you look at it. -J --
[perl #31138] [TODO] build - Configure - dependencies fix
No one ever made any actualy attempt to impliment the build in scons, makepp, etc. and since we're moving towards Configure in PASM/miniparrot I'm going to close out this bug. -J --
[perl #31980] Factorial example gives incorrect result
What happened to the factorial PASM example? It seems to have disappeared and it hasn't re-appeared as a PIR example either. -J --
Re: Building parrot-0.4.1 on Win32
On Tue, Feb 21, 2006 at 10:06:36AM +1100, Sisyphus wrote: Yes, /usr/local/lib is already in /etc/ld.so.conf. Perhaps you need to run `ldconfig` as root. $LD_LIBRARY_PATH is initially empty. If I don't add '/usr/local/lib' to it, then when I run 'parrot hello.pir', I get (transcribed): parrot: error while loading shared libraries: libparrot.so.0.4.1: cannot open shared object file: No such file or directory It sounds like your build of libparrot is linked against something under /usr/local/lib that your linker doesn't know about. That could be because the linker doesn't know it's supposed to search /usr/local/lib or that it's database is out of date. Either way it's an issue with your local system. Browsing through /usr/local/lib with 'kwrite', I notice that the permissions for 'libparrot.so.0.4.1' are -rwxr-xr-x, whereas for many of the other shared libraries the permissions are 'lrwxr-xr-x'. I don't know if that's relevant to the issue I don't know what the first permission is, or how to change it. (I don't use linux all that much.) That's not relevant. Cheers, -J -- pgp2DGOL46DBA.pgp Description: PGP signature
Re: [perl #37388] [TODO] build - remove -expnetwork from Configure
On Tue, Feb 21, 2006 at 01:01:11AM +0100, Leopold Toetsch wrote: On Feb 20, 2006, at 23:25, Joshua Hoblitt via RT wrote: This flag is in use by the inter::exp step but it's not doing much. Should this flag be kept or not? I'd remove it, The whole step or just the flag? -J -- pgpKWTbvFtZu2.pgp Description: PGP signature
Re: [perl #31156] [TODO] Performance - Add profiling build options
On Tue, Feb 21, 2006 at 01:02:23AM +0100, Leopold Toetsch wrote: On Feb 20, 2006, at 23:28, Joshua Hoblitt via RT wrote: Is this really worth doing? Since profiling flags are compiler specific isn't it better to just let them be set as additional CFLAGS? How do I add to CFLAGS from the perl Configure.pl command? --ccflags=(flags)Use the given compiler flags -J -- pgpsm6uonwUQb.pgp Description: PGP signature
Re: [perl #31980] Factorial example gives incorrect result
On Tue, Feb 21, 2006 at 01:03:59AM +0100, Leopold Toetsch wrote: On Feb 20, 2006, at 23:44, Joshua Hoblitt via RT wrote: What happened to the factorial PASM example? It seems to have disappeared and it hasn't re-appeared as a PIR example either. It used bogus high numbers beyond int32 range and was just broken. Only because it was using integer registers. Limiting it to low factorial values or using Integer pmcs would resolve the issue. I'm going to add a PIR example using Integer pmcs unless there are any objections. -J -- pgpzfTlJbDhom.pgp Description: PGP signature
Re: [perl #38597] Build broken on OS X?
Is there some reason that this can't be a -L flag passed to CC? IMHO - it's bad policy to go littering makefile with env variable declaration as the effect is global until the end of the makefile. -J -- On Mon, Feb 20, 2006 at 06:40:24PM -0600, Joshua Isom wrote: It was working on 11676, and I got it to build with 11686. But I notice one problem: Library not loaded: /usr/local/lib/libparrot.dylib On darwin, if you want a shared parrot, you must set DYLD_LIBRARY_PATH to include parrot's blib/lib. For tcsh(os x default), it'd be setenv DYLD_LIBRARY_PATH blib/lib:$DYLD_LIBRARY_PATH and for sh it'd be export DYLD_LIBRARY_PATH blib/lib:$DYLD_LIBRARY_PATH if you're in the parrot root directory. On Feb 20, 2006, at 5:34 PM, Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #38597] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38597 r11684 make realclean CXX='ccache g++-4.0' CC='ccache gcc-4.0' /usr/bin/perl Configure.pl --cc=$CC --cxx=$CXX --link=$CXX -- ld=$CXX --optimize --parrot_is_shared $@ Generates the following error: src/parrot_config.c 'runtime/parrot/include/config.fpmc' is truncated. Remove it and rerun make make: *** [src/parrot_config.c] Error 255 So, I follow the directions: CokeZero:~/research/parrot wcoleda$ rm runtime/parrot/include/ config.fpmc CokeZero:~/research/parrot wcoleda$ make Compiling with: xx.c ccache gcc-4.0 -I./include -g -pipe -fno-common -no-cpp-precomp -I/ usr/local/include -pipe -fno-common -Wno-long-double - DDISABLE_GC_DEBUG=1 -DNDEBUG -Os -I/sw/include -I /usr/local/include - Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer- arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return - Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat- security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno- shadow -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c Invoking Parrot to generate runtime/parrot/include/config.fpmc -- cross your fingers ./miniparrot config_lib.pasm runtime/parrot/include/config.fpmc dyld: Library not loaded: /usr/local/lib/libparrot.dylib Referenced from: /Users/wcoleda/research/parrot/./miniparrot Reason: image not found make: *** [runtime/parrot/include/config.fpmc] Error 133 It's been this way for about a day. I can run the which revision introduced this bug if no one sees anything obvious. pgp6o7cFsc2ii.pgp Description: PGP signature
Re: [perl #38593] [TODO] JIT compiler improvements
On Sun, Feb 19, 2006 at 03:28:32PM -0800, Leopold Toetsch wrote: *) jit2h.pl doesn't create a .h file - a better util name couldn't harm I've renamed it to jit2c.pl and added a JIT_BUILD_TOOL var in the root makefile so the path of this utility is no longer repeated encoded. -J -- pgpKmgEPzFvGO.pgp Description: PGP signature
[perl #38406] [BUG] PGE - truncating PIR code generated by p6rule
Is this bug resolved? If not, what platforms is it still failing on?
-J
--
[doughera - Mon Feb 13 09:10:50 2006]:
On Fri, 10 Feb 2006, Allison Randal wrote:
On Feb 10, 2006, at 9:56, Andy Dougherty via RT wrote:
I too had seen this memory problem before on Solaris/SPARC, but
I'm
pretty sure I saw it even when running t/past_node_5.pir directly.
However, trying again today, I'm happy to report that that
particular
problem seems to be gone.
Excellent.
Of course an awful lot of the tests still
fail, but I don't know if that's expected or not.
All of the test should be passing (at least, they are on other
platforms).
Could you send me more details on the failing tests? Some of the
generated
.out and .pir files would be a good start (running with
POSTMORTEM=1).
I don't pretend to remotely understand what the code is attempting to
do, let alone how it's failing, but the failures vaguely seem to be
fairly
similar. It looks like 'node.set_node' doesn't actually end up doing
anything. So for t/past_2.pir, for example, we have
.sub _main
load_bytecode 'languages/punie/lib/PAST.pir'
.local pmc node
node = new 'PAST::Code'
$P0 = new PerlString
$P0 = 'bar'
$P1 = new PerlArray
push $P1, $P0
node.set_node('foo', 42, $P1)
$P1 = getattribute node, 'source'
print $P1
print \n
$P1 = getattribute node, 'pos'
print $P1
print \n
$P2 = getattribute node, 'children'
$P3 = $P2[0]
print $P3
print \n
.return ()
.end
and for t/past_2.out, we have
1
1
bar
The other one that looks significantly different is t/past_op_1.pir.
The
pir file is
.sub _main
load_bytecode 'languages/punie/lib/PAST.pir'
.local pmc node
node = new 'PAST::Op'
node.set_node('foo', 42, 'bar')
$P1 = getattribute node, 'source'
print $P1
print \n
$P1 = getattribute node, 'pos'
print $P1
print \n
$P1 = getattribute node, 'op'
print $P1
print \n
.return ()
.end
and the output file is
Null PMC access in get_string()
current instr.: '_main' pc 20 (/home/doughera/src/parrot/parrot-
andy/languages/punie/t/past_op_1.pir:7)
Here's the full output of 'make test'. It accurately reflects the
.out
files (well, I didn't exhaustively check them all, but the ones I did
check matched up.)
perl5.6 -Ilib t/harness t/*.t
t/base_condok
t/base_if..ok
t/base_lex.ok
t/base_pat.ok
t/base_termok
t/io_print.ok
t/op_goto..ok
t/past.
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past.t at line 44)
# got: '1
# 1
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Looks like you failed 6 tests of 7.
dubious
Test returned status 6 (wstat 1536, 0x600)
DIED. FAILED tests 2-7
Failed 6/7 tests, 14.29% okay
t/past_nodeok
t/past_op..
# Failed test (t/past_op.t at line 7)
# got: 'Null PMC access in get_string()
# current instr.: '_main' pc 20 (/home/doughera/src/parrot/parrot-
andy/languages/punie/t/past_op_1.pir:7)
# '
# expected: 'foo
# 42
# bar
# '
# './parrot /home/doughera/src/parrot/parrot-
andy/languages/punie/t/past_op_1.pir' failed with exit code 43
# Failed test (t/past_op.t at line 30)
# got: 'PAST::Op = {
# 'source' = undef,
# 'pos' = undef,
# 'op' = 'bar',
# 'children' = []
# }
# '
# expected: 'PAST::Op = {
# 'source' = 'foo',
# 'pos' = '42',
# 'op' = 'bar',
# 'children' = []
# }
# '
# Looks like you failed 2 tests of 2.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
t/past_val.
# Failed test (t/past_val.t at line 7)
# got: '42
# 42
# bar
# '
# expected: 'foo
# 42
# bar
# '
# Failed test (t/past_val.t at line 30)
# got: 'PAST::Val = {
# 'source' = '42',
# 'pos' = '42',
# 'value' = 'bar',
# 'valtype' = undef,
# }
# '
# expected: 'PAST::Val = {
# 'source' = 'foo',
# 'pos' = '42',
# 'value' = 'bar',
# 'valtype' = undef,
# }
# '
# Looks like you failed 2 tests of 2.
dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
t/post.
# Failed test
[perl #37930] [TODO] build - bailout mechanism
As of r11568 all configuration step's -runstep() method is required to return $self unless it wants to indicate a fatal error. An error string is expected to be returned via the -result() method. The steps we're previously changed to conform to this behavior but Parrot::Configure now requires it. -J --
Re: svn performance
On Fri, Feb 17, 2006 at 05:23:55PM -0500, Andy Dougherty wrote: On Fri, 17 Feb 2006, jesse wrote: Do you, perchance, sit behind an http proxy server? Not that I know of (though I'm not sure how I'd know), and no other mode of communication is similarly affected (i.e. cvs, rsync, etc., all work fine). Perhaps your behind a transparent http proxy. If that's the case I would expect TLS to resolve the issue. -J -- pgp0ONuNQ90HG.pgp Description: PGP signature
[perl #38476] [PATCH] De-tab nativecall.pl
Just a quick reminder devs as to that to do when you apply a patch. You need to: Take ownership of the bug Set the patch status to Applied ***Set the Status to resolved*** If nothing else, please at least set the Status to resolved so someone else doesn't have to clean up the bug tracker after you. Thanks, -J --
[perl #38577] [PATCH] Reduce memory consumption of t/pmc/resizablebooleanarray_17.pasm
Please resolve patch bugs after applying the patch. -J --
[perl #38209] t/library/getopt_obj.t fails on amd64/linux
This bug seems to have resolved itself. -J --
[perl #18189] Test failures with 'long long' on i386/linux
This bug seems to have resolved itself at least on amd64/linux. Please re-open this bug if it's still failing for you. Thanks for reporting. -J --
Re: [perl #38549] pod check test checks wrong files
On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote: t/doc/pod.t currently: 1) starts checking from the current directory. It should start at the parrot root based on Parrot::Config Fixed in r11551. 2) checks every file with pod in that directory hierarchy. It should only check those files that are in MANIFEST. (And *possibly* MANIFEST.generated) It's trivial to parse those files but is there a pre-existing parser module I don't know about? There's no point in getting locked into the current format if we don't have to. -J -- pgpoPofuh7rwC.pgp Description: PGP signature
Re: [perl #38549] pod check test checks wrong files
On Tue, Feb 14, 2006 at 11:52:55PM -1000, Joshua Hoblitt wrote:
On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote:
2) checks every file with pod in that directory hierarchy.
It should only check those files that are in MANIFEST. (And
*possibly* MANIFEST.generated)
It's trivial to parse those files but is there a pre-existing parser
module I don't know about? There's no point in getting locked into the
current format if we don't have to.
It turns out there is a 'maniread()' function in ExtUtils::Manifest that
I'd overlooked.
Attached is a patch to t/doc/pod.t that changes it to only test files in
MANIFEST MANIFEST.generated. It also induces a change in what's
considered a 'Pod' file. Currently only files named 'foo.pod',
'foo.pl', 'foo.pm' are being tested for containing pod. This patch
tests all files in MANIFEST, including '.c' files, to see if they
contain pod. I'd like to get some feedback about this change before
committing the patch.
Cheers,
-J
--
=== t/doc/pod.t
==
--- t/doc/pod.t (revision 11560)
+++ t/doc/pod.t (local)
@@ -5,8 +5,9 @@
use strict;
use warnings;
use lib qw( . lib ../lib ../../lib );
-use vars qw( %docs $n_docs );
+use vars qw(@docs);
use Parrot::Config;
+use ExtUtils::Manifest qw(maniread);
BEGIN {
eval use Pod::Find;
@@ -14,18 +15,23 @@
print 1..1\nok 1 # skip Pod::Find not installed\n;
exit;
}
+
# XXX this should really be using src_dir insetad of build_dir but it
# doesn't exist (yet)
-%docs = Pod::Find::pod_find(
-{ -verbose = 0, -inc = 0 },
-$PConfig{build_dir} # search path(s)
-);
+my $build_dir = $PConfig{build_dir};
+my $manifest = maniread($build_dir/MANIFEST);
+my $manifest_gen = maniread($build_dir/MANIFEST.generated);
-$n_docs = scalar keys %docs;
+foreach my $file (keys(%$manifest), keys(%$manifest_gen)) {
+$file = $build_dir/$file;
+# skip missing MANIFEST.generated files
+next unless -e $file;
+push @docs, $file if Pod::Find::contains_pod($file, 0);
+}
}
-use Test::More tests = $n_docs;
+use Test::More tests = scalar @docs;
=head1 NAME
@@ -45,6 +51,6 @@
eval use Test::Pod 0.95;
SKIP: {
-skip Test::Pod 0.95 not installed., $n_docs if $@;
-Test::Pod::pod_file_ok( $_ ) foreach keys %docs;
+skip Test::Pod 0.95 not installed., scalar @docs if $@;
+Test::Pod::pod_file_ok( $_ ) foreach @docs;
}
pgprJD8ONG4va.pgp
Description: PGP signature
Re: [perl #38549] pod check test checks wrong files
Seems reasonable. I'll commit it once I've fixed the 32 files now being tested that have Pod errrors. -J -- On Wed, Feb 15, 2006 at 06:44:12PM -0500, Will Coleda wrote: Looks good. I note that it doesn't include something I thought I had already committed. Here's a suggested alternative that fails fast instead of slow if *either* module isn't installed, and includes your changes. On Feb 15, 2006, at 5:41 PM, Joshua Hoblitt wrote: On Tue, Feb 14, 2006 at 11:52:55PM -1000, Joshua Hoblitt wrote: On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote: 2) checks every file with pod in that directory hierarchy. It should only check those files that are in MANIFEST. (And *possibly* MANIFEST.generated) It's trivial to parse those files but is there a pre-existing parser module I don't know about? There's no point in getting locked into the current format if we don't have to. It turns out there is a 'maniread()' function in ExtUtils::Manifest that I'd overlooked. Attached is a patch to t/doc/pod.t that changes it to only test files in MANIFEST MANIFEST.generated. It also induces a change in what's considered a 'Pod' file. Currently only files named 'foo.pod', 'foo.pl', 'foo.pm' are being tested for containing pod. This patch tests all files in MANIFEST, including '.c' files, to see if they contain pod. I'd like to get some feedback about this change before committing the patch. Cheers, -J -- parrot-r11558-test_all_pod.patch pgp5flwCdzyU1.pgp Description: PGP signature
Re: [perl #38549] pod check test checks wrong files
I've checked this in as r11565 but with some cleanup (not everything needed to be in a BEGIN block, etc.). I believe Joshua Isom and myself have also fixed all of the newly caught Pod syntax errors. I'll be closing out this bug momentarily. Cheers, -J -- On Wed, Feb 15, 2006 at 06:44:12PM -0500, Will Coleda wrote: Looks good. I note that it doesn't include something I thought I had already committed. Here's a suggested alternative that fails fast instead of slow if *either* module isn't installed, and includes your changes. On Feb 15, 2006, at 5:41 PM, Joshua Hoblitt wrote: On Tue, Feb 14, 2006 at 11:52:55PM -1000, Joshua Hoblitt wrote: On Tue, Feb 14, 2006 at 05:23:39PM -0800, Will Coleda wrote: 2) checks every file with pod in that directory hierarchy. It should only check those files that are in MANIFEST. (And *possibly* MANIFEST.generated) It's trivial to parse those files but is there a pre-existing parser module I don't know about? There's no point in getting locked into the current format if we don't have to. It turns out there is a 'maniread()' function in ExtUtils::Manifest that I'd overlooked. Attached is a patch to t/doc/pod.t that changes it to only test files in MANIFEST MANIFEST.generated. It also induces a change in what's considered a 'Pod' file. Currently only files named 'foo.pod', 'foo.pl', 'foo.pm' are being tested for containing pod. This patch tests all files in MANIFEST, including '.c' files, to see if they contain pod. I'd like to get some feedback about this change before committing the patch. Cheers, -J -- parrot-r11558-test_all_pod.patch pgpE8y1XxBBzV.pgp Description: PGP signature
retrieving bugs from the gulag
There were a large number of open and owner-less bugs in the Parrot bug queue (48 after a cleaning up about half a dozen). I've changed the status on all of these bugs to 'new' as it's really not appropriate to have open and ownerless bugs (can we change RT's behavior to stop change the status to open if there's no owner?). I'd like to ask everyone with RT privs to take a few minutes to look at the 'new' queue and attempt to resolve 2 or 3 bugs. Thanks, -J -- pgp1ta2eiy0GF.pgp Description: PGP signature
Re: OS.pmc patch to add 'ls'
On Mon, Feb 13, 2006 at 09:28:40AM -0600, Chris Dolan wrote: On Feb 12, 2006, at 6:52 PM, Joshua Hoblitt wrote: It would also be 'really nice' have a glob(3) like method that is implemented as a wrapper around *dir methods so the semantics are portable. My outsider opinion is that parrot should focus on exposing basic OS functions (opendir, readdir, closedir) and leave the high-level functions (ls, glob) to the languages or libraries. My justification for that opinion is security lockdown. If there are more op-level ways of accessing the system, then there are more features that sandboxes like Safe.pm have to disable. Even more critical is the potential for creep. If sandboxes have to follow a moving target, then it could make it challenging to make security promises. I think your slightly confusing OPs and PMCs. Presumably the *dir functionality would be implemented as OP codes while glob(3) would be implemented in the OS.pmc. For all intents and purposes PMCs can fill the role of what you referred to as libraries. Doc pointers: http://www.parrotcode.org/docs/ops/ http://www.parrotcode.org/docs/pmc/ Cheers, -J -- pgpaQH6o2RsPs.pgp Description: PGP signature
configuration steps that get parameters from Configure.pl
About a month ago I wrote a example configuration step to show off the
new capability of passing arguments to a step from Configure.pl. It
seems that I forgot to send out an e-mail about this...
The example step is called gen:PodTex and creates plain text files from
Pod documents with Pod::Text. An example of it's usage would be:
=== Configure.pl
==
--- Configure.pl(revision 11517)
+++ Configure.pl(local)
@@ -446,6 +446,9 @@
$Parrot::Configure::Step::conf = $conf;
}
$conf-add_steps(@steps);
+$conf-add_step('gen::PodText',
+'DEPRECATED.pod' = 'DEPRECATED',
+);
$conf-options-set(%args);
# Run the actual steps
$conf-runsteps;
The biggest advantages of this facility is that files names no longer
have to be hard-coded into a configuration step. This allows us to
create more generic steps that can be invoked more than once in the same
configuration run.
Cheers,
-J
--
pgpvueiPIts0w.pgp
Description: PGP signature
Re: OS.pmc patch to add 'ls'
On Mon, Feb 13, 2006 at 12:23:33AM +0100, Leopold Toetsch wrote: On Feb 12, 2006, at 21:13, Alberto Sim?es wrote: Applied as r11511 (wow, a palindrome revision :-)) And reverted in r11512 by ambs. The choosen method name isn't, well, the best choice, the used OS calls (opendir/readdir/closedir) should better be exposed as is, and it didn't compile, because of 'd_namlen' incompatiblities. ambs++ It would also be 'really nice' have a glob(3) like method that is implemented as a wrapper around *dir methods so the semantics are portable. -J -- pgpLEU9UVCQ8q.pgp Description: PGP signature
Re: [PROPOSAL] File pmc, OS pmc, Path pmc and others
On Wed, Jan 25, 2006 at 10:24:51PM +, Alberto Sim?es wrote: For me, both options are reasonable. Chip's proposal have the advantage of caching the info. Using is_dir and is_file to stat everytime, have the advantage of not having a specific Stat PMC object. Other option, is having one is_dir() and one cached_is_dir(). Regardless of what Chip intended to say, please don't go caching the state of a filesystem... -J -- pgp0SMYHIuLqv.pgp Description: PGP signature
Re: Input / Output encoding filters.
On Thu, Jan 26, 2006 at 07:18:55PM +, Nicholas Clark wrote: On Thu, Jan 26, 2006 at 03:22:11PM +0800, Steve Gunnell wrote: 5) Seeking through an encoding filter could be highly problematic. Filters such as utf8 that have a non-deterministic byte per character ratio should politely refuse seeks. Clearly as you say, fixed width encodings are fine, when dealing with an entire file. But if you push a UCS32 filter onto a stream after reading an odd number of bytes, valid seek positions aren't going to be multiples of 4. I guess a seek validator can be coded to know this, but it starts getting fiddly. The other alternative would be that seek/tell locations are always in bytes in the underlying stream, and purposefully ignore any many-to-1 filters atop them. In the case of mis-alignment I think it would entirely reasonable to give the user exactly what they asked for (if possible) or the filter can throw an exception. It also sound like we want to be able to seek/tell both by character and by byte. Cheers, -J -- pgpnQszi1xmX8.pgp Description: PGP signature
Re: [perl #38217] r11124: Cygwin build fails
On Mon, Jan 23, 2006 at 12:13:50AM +, Nick Glencross wrote: Nick Glencross wrote: There seem to be a few recent events which can now trigger a newish problem: snip The real problem is that -L/usr/local/lib is brought in from parrot, so we have a few choices: * Just remove -Ls brought in from 'lddflags', which seems safe to me, or * remove the -L and add it to another config var, or * rearrange the flags in root.in so that LINKFLAGS is after ALL_PARROT_LIBS I've attached two patches, one does the first, and the other the 3rd. Both should solve the problem; so it probably comes down to aesthetics. I prefer just removing -Ls, and if any problems are encountered, introduce them later in linking (as with ICU). I prefer #1 over #3 as #3 would prevent any ldflags being used for the linkage to libparrot. There is also a fourth option of simply not pulling in 'lddflags' from Perl. This would mean setting ldflags as a per platform hints but I think this may be the better long term option. Thoughts? -J -- pgpmbvsHNvTG3.pgp Description: PGP signature
Re: [TODO] tools/dev/genrpt.pl is obsolete
Bernhard++ -J -- On Tue, Jan 17, 2006 at 09:55:47PM +0100, Bernhard Schmalhofer wrote: It looks like the script 'tools/dev/genrpt.pl' does basically the same as 'parrotbug'. In order to decrease the level of confusion I propose to remove genrpt.pl and the associated make targets 'ok', 'okfile', 'nok', 'nokfile'. CU, Bernhard pgpG0htM7mbFm.pgp Description: PGP signature
Re: [perl #38260] [BUG] Parrot::Config contains invalid info
On Tue, Jan 17, 2006 at 12:44:56PM -0800, jerry gay wrote: attached is my lib/Parrot/Config.pm file generated from r11223, on windows using msvc. inside you'll find a few things, like keys given unix file path values, 'bin_dir' = '/usr/local/bin', an invalid key, 'Parrot::Configure::Data=HASH(0x193a650)' = ' ', I'll clean that up... and unexpanded values, 'libparrot' = '$(LIBPARROT_STATIC)', 'libparrot_ldflags' = '$(LIBPARROT_STATIC)', 'libparrot_shared' = 'libparrot$(SHARE_EXT)', I believe those are only intended to be substituted into root.in and are working as designed. The design could made a little cleaner thou... any takers? -J -- pgpgSuMJ1EUMd.pgp Description: PGP signature
Re: [perl #38262] get external modules out of the parrot repo
On Tue, Jan 17, 2006 at 04:55:36PM -0800, jerry gay wrote: i think that better answer should be in the form of CPAN bundles. a development bundle (Bundle::Parrot::Devel), a test bundle (::Test), perhaps a seperate smoke bundle (::Smoke), and perhaps a bundle for end users (::Install.) The whole point of 'Bundles' is so that you don't have to install a bunch of modules by hand. Creating 3 or 4 bundles that all have to be installed just so that you can build and test parrot is really defeating the purpose. There should be just one bundle if any at all. installation of the necessary modules should be checked at configure time, and an informative message should be given to the user if there are missing dependencies. That's just another configure step but it had better be run first... -J -- pgpYqACFsoadF.pgp Description: PGP signature
[perl #37929] [TODO] build - step configuration mechanism
Per step parameter support implimented in r11203. -J --
Re: [perl #38229] [TODO] Make all pod documents(such as README's) end in .pod
On Fri, Jan 13, 2006 at 02:59:44PM -0800, Joshua Isom wrote:
There are a fair number of documentation files in parrot that are pod
files. Most of the README files aren't pod files, but the pge README
and the tcl README are. There are several other files where the same
occurs. If there aren't any objections, I can take care of this later
on. Running(under tcsh):
I renamed all of the '.dev' docs to '.pod' a few days ago.
find -E . -not \( -name .svn -prune \) -type f -not -perm +111 -not
-regex '.*\.([a-z0-9_]+|C)' -not -name Makefile -not -name harness
-exec podchecker '{}' \; | grep -v 'does not contain any pod commands'
This should get everything:
perl -mPod::Find -mFile::Find::Rule -le 'print join \n, grep
!/\.(?:pm|pl|pod|t|pir|pasm|pmc|ops|pbc|dump|c|h)$/,
File::Find::Rule-file-exec(sub {Pod::Find::contains_pod($_[0]) not -x
$_[0]} )-not_name(qw( harness .svn CVS))-in(.)'
Note: Pod::Parser prior to 1.34 (or maybe 1.33 - I can't remember when
I submitted the patch) will miss some valid pod files
seems to find them all(except README.win32) as best I can tell. It's
just a little annoying to me to expect a text file and get a pod file.
I agree. The obvious candidates are:
README.win32
compilers/pge/README
compilers/pge/P6Rule.grammar (- P6Rule_grammar.pod?)
docs/BROKEN
docs/ROADMAP
tools/util/smokeserv-README
src/dynclasses/README
languages/LANGUAGES.STATUS
languages/tcl/README
I'm happy to make these changes if there are no objections.
Cheers,
-J
--
pgpmh8PboMJOC.pgp
Description: PGP signature
Re: [perl #38235] [TODO] Rename src/classes to src/pmc
Bernhard++ -J -- On Sat, Jan 14, 2006 at 05:01:23AM -0800, Bernhard Schmalhofer wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #38235] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38235 Hi, I propose to rename 'src/classes' to 'src/pmc' as IMHO it makes more sene. 't/pmc' is already named 'pmc'. Any comments? CU, Bernhard pgp7DXAUOksIv.pgp Description: PGP signature
[perl #38123] [TODO] build - change genfile() interpolation syntax
The ${foo} interoplation/substitution syntax is no more. It has been
replaced with the autoconf like @foo@ syntax and all of the *.in files
have been updated. The special quoting syntax has also been removed
from parrot.pc.in
Support implimented in r11082 r7.
Cheers,
-J
--
Re: [perl #38216] [PATCH] fix parrot.pc.in
On Thu, Jan 12, 2006 at 07:51:58PM +, Nick Glencross wrote: It looks like only prefix is actually set, and the other paths are set using pkgconfig variables (which look the same as the style that we've just moved away from). I hope that you don't mind, but I've not used your patch per se, but have fixed the problem in r11128 similarly. Before closing the call, it might be worth checking with everyone that libdir/includedir will always be correct, otherwise we'll expand their paths. DOH! I noticed that yesterday when I was editing parrot.pc.in and decided that I should fix it as a separate changeset. Then promptly forgot to fix it... nice catch. -J -- pgpVgocMXf4lB.pgp Description: PGP signature
Re: [perl #38146] [TODO] OS.pmc - file copy
I'd vote for that being the default method that can be overridden on a
per platform basis with a more functional/efficient version.
-J
--
On Thu, Jan 12, 2006 at 12:07:33PM +, Alberto Manuel Brand?o Sim?es wrote:
I'm not implementing copy at the moment as I lack knowledge. I might
just write the default open/while(){write}/close method for cases when
everything else fails.
BTW, it will go for File.pmc accordingly with Leo.
Joshua Juran wrote:
On Jan 11, 2006, at 7:02 PM, Chip Salzenberg wrote:
On Wed, Jan 11, 2006 at 04:16:55PM -0500, Joshua Juran wrote:
Since before System 7 (approaching two decades ago), Mac OS has had a
system call that exchanges the contents of two files. The purpose of
this call is to implement a 'safe save' strategy ...
Is this still a system call in Mac OS X?
Yes, the original FSpExchangeFiles() call persists along with most of
the calls pertaining to FSSpecs. New code written only for Mac OS 9 and
above could also use the newer FSRef-based FSExchangeObjects() call
which subsumes it.
Josh
--
Alberto Sim?es - Departamento de Inform?tica - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
pgpNhiAJKcDYi.pgp
Description: PGP signature
Re: declaration of 'clone'
On Thu, Jan 12, 2006 at 04:53:26PM +0100, Leopold Toetsch wrote: Klaas-Jan Stol wrote: Hi, I'm trying to implement some functions into the Lua PMCs, but I'm having trouble to compile them. I want to add a clone method to the LuaNil PMC (which should extend Null.pmc, not None.pmc, as it does currently; changed that already) However, I get the following error: luanil.c:343: error: conflicting types for `clone' /usr/include/bits/sched.h:72: error: previous declaration of `clone' compile luanil.c failed (256) clone is a standardized vtable function. But it's name is never a bare 'clone', it's always prefixed by 'Parrot_ClassName_. This is also true for METHOD PMC* clone() # dunno if that works, if vtable exists You must have some bug in your PMC code. On Linux clone() is a syscall with a wraper function in the the standard library that is defined in sched.h. On my laptop types.h includes pthreadtypes.h which includes sched.h. You should *probably* use a different function name. ;) -J -- pgp4nRk8BaRkx.pgp Description: PGP signature
Re: [perl #38216] [PATCH] fix parrot.pc.in
On Thu, Jan 12, 2006 at 11:11:13AM -1000, Joshua Hoblitt wrote: On Thu, Jan 12, 2006 at 07:51:58PM +, Nick Glencross wrote: It looks like only prefix is actually set, and the other paths are set using pkgconfig variables (which look the same as the style that we've just moved away from). I hope that you don't mind, but I've not used your patch per se, but have fixed the problem in r11128 similarly. Before closing the call, it might be worth checking with everyone that libdir/includedir will always be correct, otherwise we'll expand their paths. DOH! I noticed that yesterday when I was editing parrot.pc.in and decided that I should fix it as a separate changeset. Then promptly forgot to fix it... nice catch. OK - this issue should be fixed in r11137. Thanks for reporting. Cheers, -J -- pgpauc5c0Gb6g.pgp Description: PGP signature
[perl #38123] [TODO] build - change genfile() interpolation syntax
[EMAIL PROTECTED] - Sun Jan 01 18:44:33 2006]:
Parrot::Configure::Step::genfile() currently interpolates values in the
format ${foo}. This is undesirable because ${ BAREWORD } is valid perl5
syntax and in make files it looks uncomfortable similar to $(foo). It
should be changed to @foo@ where whitespace is not allowed between the
@s. This format is superior as a) it clearly stands out and b) it's
compatible with autoconf.
I've added support for the autoconf compatable @foo@ syntax to genfile()
and experimentally converted root.in (the main makefile). If this
doesn't cause any smoke failures or bug reports in the next day or so
I'll convert the rest of the processed files.
Cheers,
-J
--
[perl #38189] [TODO] sort out CPAN modules incorrectly owned by Parrot
Please reopen this bug if we're still screwing up the CPAN indexer after the next release. Thanks for bringing up this issue. Cheers, -J --
t/library/getopt_obj.t fails on amd64/linux
$ perl t/harness t/library/getopt_obj.t
t/library/getopt_objNOK 13
# Failed test (t/library/getopt_obj.t at line 559)
# got: 'argv = ResizablePMCArray (size:7) [
# --ignored,
# -i,
# --ignored=hello,
# argv,
# stay,
# -,
# with me
# ]
# return = Hash {
# Bar = 12,
# Foo = file.txt,
# FooBar = foobar,
# I = ResizablePMCArray (size:2) [
# /usr/include,
# /usr/local/include
# ],
# alpha = 1,
# ban = 3.14,
# baz = 1,
# beta = 1,
# cab = PMC 'None' { ... },
# code = [EMAIL PROTECTED]cab],
# define = [EMAIL PROTECTED]cab]
# }
# '
# expected: 'argv = ResizablePMCArray (size:7) [
# --ignored,
# -i,
# --ignored=hello,
# argv,
# stay,
# -,
# with me
# ]
# return = Hash {
# Bar = 12,
# Foo = file.txt,
# FooBar = foobar,
# I = ResizablePMCArray (size:2) [
# /usr/include,
# /usr/local/include
# ],
# alpha = 1,
# ban = 3.14,
# baz = 1,
# beta = 1,
# cab = 1,
# code = ResizablePMCArray (size:2) [
# codea,
# codeb
# ],
# define = Hash {
# Bye = Good Bye,
# Defined = 1,
# Hi = Hello,
# hi = hello
# }
# }
# '
# Looks like you failed 1 test of 13.
t/library/getopt_objdubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 13
Failed 1/13 tests, 92.31% okay
Failed TestStat Wstat Total Fail Failed List of Failed
---
t/library/getopt_obj.t1 256131 7.69% 13
Failed 1/1 test scripts, 0.00% okay. 1/13 subtests failed, 92.31% okay.
Summary of my parrot 0.4.1 (r0) configuration:
configdate='Wed Jan 11 17:52:15 2006'
Platform:
osname=linux, archname=x86_64-linux
jitcapable=0, jitarchname=nojit,
jitosname=linux, jitcpuarch=x86_64
execcapable=0
perl=/usr/bin/perl5.8.7
Compiler:
cc='x86_64-pc-linux-gnu-gcc', ccflags=' -pipe -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -fPIC -I /usr/include',
Linker and Libraries:
ld='x86_64-pc-linux-gnu-gcc', ldflags='',
cc_ldflags='',
libs='-lpthread -lnsl -ldl -lm -lcrypt -lutil -lrt -lgmp'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -fPIC',
load_ext='.so', ld_load_flags='-shared -fPIC'
Types:
iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8,
ptrsize=8, ptr_alignment=1 byteorder=12345678,
nv=double, numvalsize=8, doublesize=8
-J
--
pgpwk1yfB6hwq.pgp
Description: PGP signature
Re: [perl #38023] [TODO] build - support pkgconfig
I've add simple install support for pkgconfig as r11035. It's currently
hardcoded as being under libdir as this is what every automake installed
package I know of does. If there's ever compelling reason to install it
someplace else we can add a separate 'pkgconfigdir' option for it.
Cheers,
-J
--
On Mon, Jan 09, 2006 at 03:20:37PM -1000, Joshua Hoblitt wrote:
On Tue, Jan 10, 2006 at 01:06:29AM +, Nick Glencross wrote:
Joshua Hoblitt (via RT) wrote:
Parrot should support pkgconfig by installing a pc data file. It should
probably be named parrot.pc.
Ok, I can do this. I've had an initial stab at it, and one thing that
I've had to do is provide a quoting mechanism into the configuration
file substitution because pkgconfig too uses ${name} for other purpose.
I've going to suggest ${{name}} as something which will be replaced
literally by ${name}.
Great. There is another bug to change the interpolation syntax to @foo@
to avoid just this issue. Since you've already added the escape
mechanism so lets leave it in place but consider it temporary.
As a side note, Parrot::Configure::Step is only partially tested and I'm
rather nervous about messing with it until it has better test coverage.
I think that most projects leave the .pc in the top-level directory; I
don't think that we have anywhere better at the moment.
Seems reasonable. That's what I with my autotool packages too.
The file isn't yet installed because I don't know how to update the
MANIFEST.generated file to place it in .../lib/pkgconfig. Any help would
be great.
Another install type/class will have to be added. I'll take care of
this when I get home this evening. Lets leave the bug open until I've
gotten the install working.
Cheers,
-J
--
pgpca5fMVHXFs.pgp
Description: PGP signature
Re: [perl #38023] [TODO] build - support pkgconfig
On Tue, Jan 10, 2006 at 01:06:29AM +, Nick Glencross wrote:
Joshua Hoblitt (via RT) wrote:
Parrot should support pkgconfig by installing a pc data file. It should
probably be named parrot.pc.
Ok, I can do this. I've had an initial stab at it, and one thing that
I've had to do is provide a quoting mechanism into the configuration
file substitution because pkgconfig too uses ${name} for other purpose.
I've going to suggest ${{name}} as something which will be replaced
literally by ${name}.
Great. There is another bug to change the interpolation syntax to @foo@
to avoid just this issue. Since you've already added the escape
mechanism so lets leave it in place but consider it temporary.
As a side note, Parrot::Configure::Step is only partially tested and I'm
rather nervous about messing with it until it has better test coverage.
I think that most projects leave the .pc in the top-level directory; I
don't think that we have anywhere better at the moment.
Seems reasonable. That's what I with my autotool packages too.
The file isn't yet installed because I don't know how to update the
MANIFEST.generated file to place it in .../lib/pkgconfig. Any help would
be great.
Another install type/class will have to be added. I'll take care of
this when I get home this evening. Lets leave the bug open until I've
gotten the install working.
Cheers,
-J
--
pgpvupY0RiR23.pgp
Description: PGP signature
