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
[perl #40145] [PATCH] t/compilers/imcc/syn/macro.t segfault
# New Ticket Created by Autrijus Tang # Please include the string: [perl #40145] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40145 The segfault (exhibited in 0.4.6) was caused by a missing str_dup in dan's r4236; passing yytext to other functions would need to preserve its content first. Also the original code was misindented from jonathan's r9526. Please regen imclexer.c in maintainer mode after applying this patch. Thanks, Audrey compilers-imcc-imcc.l.diff Description: Binary data PGP.sig Description: PGP signature
http://arstechnica.com/news.ars/post/20060810-7462.html
http://arstechnica.com/news.ars/post/20060810-7462.html : .NET and J2EE to get better dynamic language support To partially quote: Many dynamic language enthusiasts are also interested in Parrot, an open source virtual machine designed specifically for dynamic languages. Initially conceived as the foundation for Perl 6, Parrot provides some extremely impressive features including a built-in grammer engine that vastly simplifies the process of language development. -- Will Coke Coleda [EMAIL PROTECTED]
Re: [perl #40145] [PATCH] t/compilers/imcc/syn/macro.t segfault
Am Donnerstag, 10. August 2006 03:13 schrieb Autrijus Tang: The segfault (exhibited in 0.4.6) was caused by a missing str_dup in dan's r4236; passing yytext to other functions would need to preserve its content first. Which segfault - I didn't see one? Anyway, applied - r13984, with a little addition that keeps parrot's macro tests silent re error reporting. Thanks, leo
Review of current stm branch code
I appreciate the quality of the stm code in general. You're being careful,
you know what you're doing with C, and you're good at creating abstractions.
I hope when STM is done[*] you'll keep hacking on Parrot.
[*] As if it will ever be really done.
No work of art is ever finished, only abandoned.
Here are my comments. Once these issues and/or questions are addressed
and/or diposed of, we can merge the state-of-stm onto the trunk. Please
correct me wherever I've misunderstood what you're doing.
POSSIBLE BUGS
* START_WRITE_HLL params vs. usage
+#define START_WRITE_HLL(interpreter, hll_info) \
+do { \
+if (PMC_sync(interpreter-HLL_info)) { \
+hll_info = interpreter-HLL_info = \
+Parrot_clone(interpreter, interpreter-HLL_info); \
+if (PMC_sync(interpreter-HLL_info)) { \
+mem_internal_free(PMC_sync(interpreter-HLL_info)); \
+} \
+} \
+} while (0)
But then:
+START_WRITE_HLL(interpreter, interpreter-HLL_info)
That expansion, which is in part:
interpreter-HLL_info = interpreter-HLL_info = Parrot_clone(interpreter,
interpreter-HLL_info);
mem_internal_free(PMC_sync(interpreter-HLL_info));
Looks odd or even broken, offhand. Am I missing something?
* 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.
QUESTIONS/REQUESTS
* You're defining a heck of a lot of macros. Is there any set of them that
can be marked as private (to the STM implementation), e.g. with a leading
single underscore? Say, if the ATOMIC_INT_CAS macro is only used by other
macros and isn't part of the supported interface, then it could be renamed
to _ATOMIC_INT_CAS. This will prevent the abstraction from leaking.
* It's surely a mean trick on the poor user/programmer to have
Parrot_atomic_int actually hold a long. :-, Any reason not to use int?
Or do you want Parrot_atomic_long?
* Is there any need/use for multiple integral atomic types, like an
unsigned or a UINTVAL or something? (I expect the answer is no.)
* Could *_{READ,WRITE}_HLL be named something like *_{READ,WRITE}_HLL_INFO,
assuming they need to be macros at all? An HLL is an abstraction that
currently doesn't have a single concrete representation.
* I see that Parrot_get_HLL_namespace() is now deferring namespace creation.
That could perhaps be problematic. We've told users that
get_root_namespace ['your_own_hll'; 'x']
and
get_hll_namespace ['x']
have identical results. So, what's the payoff for this delayed creation?
* Does your ops.num renumber ops, or is diff just getting confused by
whitespace?
If the former, what's up?
CODING STANDARD^WWHIM ISSUES
I do need to update pdd07. In the meantime, here are some coding standard
issues I'd appreciate if you'd address. For some of them you're going to be
setting the new standard for the rest of the code, but such is the fate of
code reviewed the guy who's writing the new spec. :-,
* Out of all the macros you're defining, will any of them be ever needed by
users of the Parrot extension or embedding interfaces? If so, their full
official names will have to start with PARROT_. But when compiling
Parrot, it's OK to define non-PARROT_-prefix versions as aliases.
For example, if the Parrot_atomic_int is a public type, exposed to
embed/extend, as its name implies, then the ATOMIC_* macros will have to
be PARROT_ATOMIC_*. But then this is OK too:
#ifdef PARROT_IN_CORE
# define ATOMIC_FOO PARROT_ATOMIC_FOO
# define ATOMIC_BAR PARROT_ATOMIC_BAR
...
#endif
* macro args protection
Most of your code is really good careful with macro behaviors.
Just a couple exceptions:
+#define START_WRITE_HLL(interpreter, hll_info) \
+do { \
+if (PMC_sync(interpreter-HLL_info)) { \
+hll_info = interpreter-HLL_info = \
+Parrot_clone(interpreter, interpreter-HLL_info); \
+if (PMC_sync(interpreter-HLL_info)) { \
+mem_internal_free(PMC_sync(interpreter-HLL_info)); \
+} \
+} \
+} while (0)
Macro arguments should be parenthesized when used, and it helps to name
them in all caps so as to distinguish them from the normal names ref'd in
the macro body.
Similarly, when you're not using do {} while (0), the macro expansion
should be parenthesized if it contains an exposed operator. For example,
this:
+# define ATOMIC_INT_INC(result, a) result = ++(a).val
should be paren'd:
+# define ATOMIC_INT_INC(result, a) ((result) = ++(a).val)
* useless curlies
-if (PMC_IS_NULL(type_hash))
+if (PMC_IS_NULL(type_hash)) {
return
More review of current stm branch code
More on the STM branch: ANSWERS, FOR A CHANGE * A comment asks: /* XXX is it okay to combine flatten/slurpy into one flag? */ The answer is No: flat is an output flag, slurpy_array is an input flag, and there's no guarantee that the input and output flags won't conflict with each other. So I guess this means that something has to change. * Another comment asks: # autogenerate for exotic types # (XXX is this appropriate or do we want them to each # be explicitly cleared to have the variant?) Well, that depends. Is there currently any way for a named METHOD to specify whether it is :write, and if so, is this used? If so, then yes, making an automatic ro variant is OK. If not, then I think we might want such a thing...? MORE QUESTIONS * The '@' character for native call signatures is new, and AFAICT is just syntactic sugar, since the caller could do the array creation himself. Could you explain what you would have to do if you didn't introduce this feature? (I'm not necessarily against it, mind you, I just want to know what the deal is.) ANOTHER NAMING THING * Please rename 'ro_variant' to something ending in '_vtable', e.g. 'ro_variant_vtable', to make clear that it's not a class pointer or type number. -- Chip Salzenberg [EMAIL PROTECTED]
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 -- pgpzfK9fw7gSx.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
--
pgpN3uSF9vUYs.pgp
Description: PGP signature
Re: Review of current stm branch code
JH == Joshua Hoblitt [EMAIL PROTECTED] writes: JH On Thu, Aug 10, 2006 at 07:19:21PM -0700, Chip Salzenberg wrote: * useless curlies 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. JH This is a bad joke, right? How much of your life are you intending to JH spend on chasing down hard to find missing braces bugs? heh, this brings me back to my coding standards issues from when i did tons of c. i ALWAYS used braces so you could visually see the conditional or block of code. i was so glad when i switched to perl that braces were manditory. there are so many bug issues with dangling if/else clauses and unless you used pythonicly strict indenting, you were going to have them unless you used braces. the extra lines used are easily offset by better windowing editors, block hiding, and other things and also the reduction in bugs makes that minor sacrifice well worth it. but since i don't hack on parrot code i will just leave it at that. braces RULES!! back to lurking, uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Review of current stm branch code
On Thu, Aug 10, 2006 at 07:11:15PM -1000, Joshua Hoblitt wrote: On Thu, Aug 10, 2006 at 07:19:21PM -0700, Chip Salzenberg wrote: * useless curlies 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? If avoiding the possibility of hard-to-find bugs, were my priority, I wouldn't enjoy writing C and C++. Or Perl. Or PL/I. Seriously: I am serious. Many of the changes I have in mind for the Parrot source code are based on reducing the visual footprint of constructs without changing their meaning, and eliminating needless words^Wbraces is one way to do that. Anyone who needs braces to avoid/detect errors is probably just not acclimated to the C language, and/or failing to indent properly (that's what smart editors are for; no snide Python remarks please). And Parrot is written in the complete C language, not some intersection of C and Perl. I'd rather invest my extra vertical space into some well-chosen comments and blank lines between phrases, which can convey useful meaning, rather than braces around one-line if/else clauses, which are just noise. -- Chip Salzenberg [EMAIL PROTECTED]
