Re: [perl #53086] OpenGL detection under MacOS X
OK, I've done some more research on differences between various GLUT
libraries; please try the attached patch rather than the one from tentra
(mine includes his with a couple changes and several additions).
-'f
=== config/auto/opengl/opengl.in
==
--- config/auto/opengl/opengl.in (revision 4810)
+++ config/auto/opengl/opengl.in (local)
@@ -4,9 +4,11 @@
#include stdio.h
#include stdlib.h
-/* : This location is platform dependent. What's the preferred
- way to find headers that move? */
+#ifdef __APPLE_CC__
+#include GLUT/glut.h
+#else
#include GL/glut.h
+#endif
int main(int argc, char *argv[])
@@ -15,6 +17,16 @@
printf(glutInit is NULL\n);
return EXIT_FAILURE;
}
-printf(%d\n, GLUT_API_VERSION);
+
+#ifdef OPENGLUT
+printf(%d OpenGLUT\n,GLUT_API_VERSION);
+#elif FREEGLUT
+printf(%d freeglut\n,GLUT_API_VERSION);
+#elif GLUT_MACOSX_IMPLEMENTATION
+printf(%d MacOSX_GLUT\n, GLUT_API_VERSION);
+#else
+printf(%d GLUT\n,GLUT_API_VERSION);
+#endif
+
return EXIT_SUCCESS;
}
=== config/auto/opengl.pm
==
--- config/auto/opengl.pm (revision 4810)
+++ config/auto/opengl.pm (local)
@@ -66,8 +66,7 @@
eval { $conf-cc_build() };
if ( !$@ ) {
my $test = $conf-cc_run();
-$has_glut = $self-_evaluate_cc_run($test, $verbose);
-_handle_glut($conf, $has_glut);
+$has_glut = _handle_glut($conf, $self-_evaluate_cc_run($test, $verbose));
}
unless ($has_glut) {
# The Parrot::Configure settings might have changed while class ran
@@ -88,6 +87,9 @@
$conf-data-add( ' ', libs = 'glut.lib glu.lib gl.lib' );
}
}
+elsif ( $osname =~ /darwin/i ) {
+$conf-data-add( ' ', libs = '-framework OpenGL -framework GLUT' );
+}
else {
$conf-data-add( ' ', libs = '-lglut -lGLU -lGL' );
}
@@ -96,25 +98,29 @@
sub _evaluate_cc_run {
my ($self, $test, $verbose) = @_;
-chomp $test;
-my $has_glut = $test;
-print (yes, GLUT API $has_glut) if $verbose;
-$self-set_result(yes, GLUT $has_glut);
-return $has_glut;
+my ($glut_api_version, $glut_brand) = split ' ', $test;
+
+print (yes, $glut_brand API version $glut_api_version) if $verbose;
+$self-set_result(yes, $glut_brand $glut_api_version);
+
+return ($glut_api_version, $glut_brand);
}
sub _handle_glut {
-my ($conf, $has_glut) = @_;
+my ($conf, $glut_api_version, $glut_brand) = @_;
+
$conf-data-set(
# Completely cargo culted
opengl = 'define',
-has_opengl = $has_glut,
-HAS_OPENGL = $has_glut,
+has_opengl = 1,
+HAS_OPENGL = 1,
glut = 'define',
-has_glut = $has_glut,
-HAS_GLUT = $has_glut,
+glut_brand = $glut_brand,
+has_glut = $glut_api_version,
+HAS_GLUT = $glut_api_version,
);
+
return 1;
}
=== config/gen/opengl.pm
==
--- config/gen/opengl.pm (revision 4810)
+++ config/gen/opengl.pm (local)
@@ -60,18 +60,25 @@
);
my @GLUT_4_CALLBACKS = (
-[ 'Close','void' ],
-[ 'Menu Destroy', 'void' ],
-[ 'WM Close', 'void' ],
[ 'Window Status','int state' ],
[ 'Keyboard Up', 'unsigned char key, int x, int y' ],
[ 'Special Up', 'int key, int x, int y' ],
-[ 'Mouse Wheel', 'int wheel, int direction, int x, int y' ],
# NOTE: Hardcoded because of special arguments
# [ 'Joystick', 'int buttons, int xaxis, int yaxis, int zaxis' ],
);
+my @MACOSXGLUT_CALLBACKS = (
+# Also works in freeglut
+[ 'WM Close', 'void' ],
+);
+
+my @FREEGLUT_CALLBACKS = (
+[ 'Close','void' ],
+[ 'Menu Destroy', 'void' ],
+[ 'Mouse Wheel', 'int wheel, int direction, int x, int y' ],
+);
+
my $MACRO_FILE = 'runtime/parrot/include/opengl_defines.pasm';
my $C_FILE = 'src/glut_callbacks.c';
@@ -93,23 +100,29 @@
return 1;
}
-$self-gen_opengl_defines($conf);
+my @header_globs = (
+'/usr/include/GL/*.h',
+'/System/Library/Frameworks/OpenGL.framework/Headers/*.h',
+'/System/Library/Frameworks/GLUT.framework/Headers/*.h',
+);
+
+my @header_files = sort map {glob} @header_globs;
+
+$self-gen_opengl_defines($conf, [EMAIL PROTECTED]);
$self-gen_glut_callbacks($conf);
return 1;
}
sub gen_opengl_defines {
-my ( $self, $conf ) = @_;
+my ( $self, $conf, $header_files ) = @_;
my $verbose = $conf-options-get('verbose');
-my @header_files = glob '/usr/include/GL/*.h';
-
my (%defs, @macros);
my $max_len = 0;
-foreach my $file (@header_files) {
+foreach my $file (@$header_files) {
open my
Re: [perl #45015] [TODO] Create a 'Rational' PMC for rational numbers
Markus Mayr via RT schrieb: I am currently working on this. I'll probably finish work on it during the next 10 days. That's great. In case of questions please do not hesitate to ask on #parrot or on the mailing list. Regards, Bernhard
[perl #53094] [TODO] config/auto/perldoc.pm: Recent change needs discussion
# New Ticket Created by James Keenan
# Please include the string: [perl #53094]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53094
This morning I noticed that the following change had been made to
config/auto/perldoc.pm:
$ svn diff -r {2008-04-19} config/auto/perldoc.pm
Index: config/auto/perldoc.pm
===
--- config/auto/perldoc.pm (revision 27027)
+++ config/auto/perldoc.pm (working copy)
@@ -36,7 +36,7 @@
sub runstep {
my ( $self, $conf ) = @_;
-my $cmd = $conf-data-get_p5('scriptdirexp') . q{/perldoc};
+my $cmd = q{perldoc};
my $tmpfile = q{c99da7c4.tmp};
my $content = capture_output($cmd -ud $tmpfile perldoc) || undef;
The log message associated with this commit presented its rationale:
r27056 | fperrad | 2008-04-20 05:57:41 -0400 (Sun, 20 Apr 2008) | 3 lines
[perldoc]
- fix with strawberry Perl 5.10.0
However, IMO it would have been preferable to present this issue in an
RT [BUG] ticket first. As it stands, I have no idea as to the
particular problem which François found with this config step on
Strawberry Perl. More importantly, the patch essentially undoes this
patch which Mark Glines committed a month ago:
r26513 | infinoid | 2008-03-21 16:24:58 -0400 (Fri, 21 Mar 2008) | 9 lines
[config] perldoc check should use $Config{scriptdirexp}, not
$Config{scriptdir}. The scriptdir value from p5 is sometimes
interpreted in strange ways, but the scriptdirexp value is expanded at
compile-time, so it's guaranteed to be sane.
Grep perl-5.10.0's perldelta.pod for Relocatable installations for
details. This was preventing perldoc from being detected properly on a
local install of perl. wolverian++ for reporting it.
I don't know the entire history of this config step or of Parrot's
configuration in general. But I do know that we draw many of our
configuration settings from the Perl 5 Config module found on the box
attempting configuration of Parrot. I also know that we have developers
who have multiple Perls on their machine, hence have multiple 'perldoc's
on their machine. In the past, at least, it has been important to know
which 'perldoc' is being referenced.
So, while this fix might be good for Strawberry Perl, there's a good
chance it will break someone else's Parrot configuration.
François, can you present the problem in this ticket?
Mark, can you evaluate impact?
Thank you very much.
kid51
Re: [perl #53094] [TODO] config/auto/perldoc.pm: Recent change needs discussion
On Sun, 20 Apr 2008 05:36:44 -0700
James Keenan (via RT) [EMAIL PROTECTED] wrote:
-my $cmd = $conf-data-get_p5('scriptdirexp') . q{/perldoc};
+my $cmd = q{perldoc};
Mark, can you evaluate impact?
Well, it looks to me like it'll just run perldoc from the user's
$PATH, rather than trying to find the one that installed with the
currently running perl. So it might lead to a different perldoc being
used, if the user has more than one rev of perl installed (and ran
Configure.pl with the non-default one). Whether that actually matters
or not... I dunno.
Mark
Re: [perl #53086] OpenGL detection under MacOS X
On Sun, 20 Apr 2008 00:02:18 -0700
Geoffrey Broadwell [EMAIL PROTECTED] wrote:
OK, I've done some more research on differences between various GLUT
libraries; please try the attached patch rather than the one from
tentra (mine includes his with a couple changes and several
additions).
I ran into a few minor problems testing this:
1. Some trailing whitespace was flagging a couple of codingstd
failures.
2. fperrad's r27055 checkin (a mingw header name fix) conflicted and
needed to be merged.
3. kid51's tests were breaking because the internals of your opengl
configuration modules changed, and the expected return values didn't
match.
r27058 disabled those tests for now, so they're not an issue. (Thanks,
Jim.) I fixed the trailing whitespace, and reverted r27055. The
attached patch detects successfully, example runs, and passes all tests
for me on linux/amd64. I applied it to r27058.
fperrad, I believe this patch will cover the issue you patched in
r27055, but in a different way. Can you please verify that this works
for you on mingw32?
Thanks,
Mark
Index: runtime/parrot/library/OpenGL.pir
===
--- runtime/parrot/library/OpenGL.pir (revision 27058)
+++ runtime/parrot/library/OpenGL.pir (working copy)
@@ -56,16 +56,19 @@
libnames = new 'ResizableStringArray'
push libnames, 'libGL'
+push libnames, '/System/Library/Frameworks/OpenGL.framework/OpenGL'
libgl = load_lib_with_fallbacks('GL', libnames)
set_global 'libgl', libgl
libnames = new 'ResizableStringArray'
push libnames, 'libGLU'
+push libnames, '/System/Library/Frameworks/OpenGL.framework/OpenGL'
libglu = load_lib_with_fallbacks('GLU', libnames)
set_global 'libglu', libglu
libnames = new 'ResizableStringArray'
push libnames, 'libglut'
+push libnames, '/System/Library/Frameworks/GLUT.framework/GLUT'
libglut = load_lib_with_fallbacks('GLUT', libnames)
set_global 'libglut', libglut
Index: config/auto/opengl.pm
===
--- config/auto/opengl.pm (revision 27058)
+++ config/auto/opengl.pm (working copy)
@@ -66,8 +66,7 @@
eval { $conf-cc_build() };
if ( !$@ ) {
my $test = $conf-cc_run();
-$has_glut = $self-_evaluate_cc_run($test, $verbose);
-_handle_glut($conf, $has_glut);
+$has_glut = _handle_glut($conf, $self-_evaluate_cc_run($test,
$verbose));
}
unless ($has_glut) {
# The Parrot::Configure settings might have changed while class ran
@@ -88,6 +87,9 @@
$conf-data-add( ' ', libs = 'glut.lib glu.lib gl.lib' );
}
}
+elsif ( $osname =~ /darwin/i ) {
+$conf-data-add( ' ', libs = '-framework OpenGL -framework GLUT' );
+}
else {
$conf-data-add( ' ', libs = '-lglut -lGLU -lGL' );
}
@@ -96,25 +98,29 @@
sub _evaluate_cc_run {
my ($self, $test, $verbose) = @_;
-chomp $test;
-my $has_glut = $test;
-print (yes, GLUT API $has_glut) if $verbose;
-$self-set_result(yes, GLUT $has_glut);
-return $has_glut;
+my ($glut_api_version, $glut_brand) = split ' ', $test;
+
+print (yes, $glut_brand API version $glut_api_version) if $verbose;
+$self-set_result(yes, $glut_brand $glut_api_version);
+
+return ($glut_api_version, $glut_brand);
}
sub _handle_glut {
-my ($conf, $has_glut) = @_;
+my ($conf, $glut_api_version, $glut_brand) = @_;
+
$conf-data-set(
# Completely cargo culted
opengl = 'define',
-has_opengl = $has_glut,
-HAS_OPENGL = $has_glut,
+has_opengl = 1,
+HAS_OPENGL = 1,
glut = 'define',
-has_glut = $has_glut,
-HAS_GLUT = $has_glut,
+glut_brand = $glut_brand,
+has_glut = $glut_api_version,
+HAS_GLUT = $glut_api_version,
);
+
return 1;
}
Index: config/auto/opengl/opengl.in
===
--- config/auto/opengl/opengl.in(revision 27058)
+++ config/auto/opengl/opengl.in(working copy)
@@ -4,9 +4,11 @@
#include stdio.h
#include stdlib.h
-/* : This location is platform dependent. What's the preferred
- way to find headers that move? */
+#ifdef __APPLE_CC__
+#include GLUT/glut.h
+#else
#include GL/glut.h
+#endif
int main(int argc, char *argv[])
@@ -15,6 +17,16 @@
printf(glutInit is NULL\n);
return EXIT_FAILURE;
}
-printf(%d\n, GLUT_API_VERSION);
+
+#ifdef OPENGLUT
+printf(%d OpenGLUT\n,GLUT_API_VERSION);
+#elif FREEGLUT
+printf(%d freeglut\n,GLUT_API_VERSION);
+#elif GLUT_MACOSX_IMPLEMENTATION
+printf(%d MacOSX_GLUT\n, GLUT_API_VERSION);
+#else
+printf(%d GLUT\n,GLUT_API_VERSION);
+#endif
+
return EXIT_SUCCESS;
}
Index: config/gen/opengl.pm
[perl #53086] OpenGL detection under MacOS X
1. I tried your patch out. It did not apply cleanly at first, so I had
to do a little editing. I am attaching an 'svn diff' that represents
the changes actually made.
This patch worked for me on Darwin in the sense that it detected OpenGL
where previously the step class had not:
Determining if your platform supports OpenGLyes, MacOSX_GLUT 5.
2. Last night I wrote some tests for this step class along the lines of
those found for other configuration step classes, e.g., testing for
settings of results, testing for verbose output, etc. However, since
the internals of this class are still under development, I have
temporarily disabled some of those tests so that we don't get spurious
failures.
3. May I suggest that this code:
$has_glut = _handle_glut($conf, $self-_evaluate_cc_run($test,
$verbose));
... be rewritten like this:
my $rv = $self-_evaluate_cc_run($test, $verbose);
$has_glut = _handle_glut($conf, $rv);
This would be more consistent with the way other config step classes are
coded in that it gives the method call its own statement.
Thank you very much.
Index: runtime/parrot/library/OpenGL.pir
===
--- runtime/parrot/library/OpenGL.pir (revision 27056)
+++ runtime/parrot/library/OpenGL.pir (working copy)
@@ -56,16 +56,19 @@
libnames = new 'ResizableStringArray'
push libnames, 'libGL'
+push libnames, '/System/Library/Frameworks/OpenGL.framework/OpenGL'
libgl = load_lib_with_fallbacks('GL', libnames)
set_global 'libgl', libgl
libnames = new 'ResizableStringArray'
push libnames, 'libGLU'
+push libnames, '/System/Library/Frameworks/OpenGL.framework/OpenGL'
libglu = load_lib_with_fallbacks('GLU', libnames)
set_global 'libglu', libglu
libnames = new 'ResizableStringArray'
push libnames, 'libglut'
+push libnames, '/System/Library/Frameworks/GLUT.framework/GLUT'
libglut = load_lib_with_fallbacks('GLUT', libnames)
set_global 'libglut', libglut
Index: config/auto/opengl.pm
===
--- config/auto/opengl.pm (revision 27056)
+++ config/auto/opengl.pm (working copy)
@@ -66,8 +66,7 @@
eval { $conf-cc_build() };
if ( !$@ ) {
my $test = $conf-cc_run();
-$has_glut = $self-_evaluate_cc_run($test, $verbose);
-_handle_glut($conf, $has_glut);
+$has_glut = _handle_glut($conf, $self-_evaluate_cc_run($test,
$verbose));
}
unless ($has_glut) {
# The Parrot::Configure settings might have changed while class ran
@@ -88,6 +87,9 @@
$conf-data-add( ' ', libs = 'glut.lib glu.lib gl.lib' );
}
}
+elsif ( $osname =~ /darwin/i ) {
+$conf-data-add( ' ', libs = '-framework OpenGL -framework GLUT' );
+}
else {
$conf-data-add( ' ', libs = '-lglut -lGLU -lGL' );
}
@@ -96,25 +98,29 @@
sub _evaluate_cc_run {
my ($self, $test, $verbose) = @_;
-chomp $test;
-my $has_glut = $test;
-print (yes, GLUT API $has_glut) if $verbose;
-$self-set_result(yes, GLUT $has_glut);
-return $has_glut;
+my ($glut_api_version, $glut_brand) = split ' ', $test;
+
+print (yes, $glut_brand API version $glut_api_version) if $verbose;
+$self-set_result(yes, $glut_brand $glut_api_version);
+
+return ($glut_api_version, $glut_brand);
}
sub _handle_glut {
-my ($conf, $has_glut) = @_;
+my ($conf, $glut_api_version, $glut_brand) = @_;
+
$conf-data-set(
# Completely cargo culted
opengl = 'define',
-has_opengl = $has_glut,
-HAS_OPENGL = $has_glut,
+has_opengl = 1,
+HAS_OPENGL = 1,
glut = 'define',
-has_glut = $has_glut,
-HAS_GLUT = $has_glut,
+glut_brand = $glut_brand,
+has_glut = $glut_api_version,
+HAS_GLUT = $glut_api_version,
);
+
return 1;
}
Index: config/auto/opengl/opengl.in
===
--- config/auto/opengl/opengl.in(revision 27056)
+++ config/auto/opengl/opengl.in(working copy)
@@ -4,9 +4,11 @@
#include stdio.h
#include stdlib.h
-/* : This location is platform dependent. What's the preferred
- way to find headers that move? */
+#ifdef __APPLE_CC__
+#include GLUT/glut.h
+#else
#include GL/glut.h
+#endif
int main(int argc, char *argv[])
@@ -15,6 +17,16 @@
printf(glutInit is NULL\n);
return EXIT_FAILURE;
}
-printf(%d\n, GLUT_API_VERSION);
+
+#ifdef OPENGLUT
+printf(%d OpenGLUT\n,GLUT_API_VERSION);
+#elif FREEGLUT
+printf(%d freeglut\n,GLUT_API_VERSION);
+#elif GLUT_MACOSX_IMPLEMENTATION
+printf(%d MacOSX_GLUT\n, GLUT_API_VERSION);
+#else
+printf(%d GLUT\n,GLUT_API_VERSION);
+#endif
+
return EXIT_SUCCESS;
}
Index:
Re: [perl #53082] rakudo does not use the line numbering feature of imcc. may be hllcompiler does not support it.
On Sat, Apr 19, 2008 at 11:52:04AM -0700, Stephane Payrard wrote: This is part of an probably recurring serie of end-user bugs that ask in substance : making things easier on people... who want to use HLLCompiler and Parrot and the languages derived from them without wanting to be involved in it. Rakudo doesn't use the line numbering feature of imcc because the line numbering feature of imcc doesn't work. See RT#43269 - setline is tied to PIR source. This also probably means standard way of intercepting error like Null PMC access in invoke() to provide error message useful to the end user of a compiler. This has been discussed (without resolution) in RT#49972. I'm going ahead and setting this ticket to depend on the above two tickets. Pm
[perl #53100] The ** operator like in ident ** ',' is missing from PGE. would be a nice feature for writing parsers and minimizing rules
# New Ticket Created by Stephane Payrard # Please include the string: [perl #53100] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53100 I will give it a try but does not promise anything. -- cognominal stef
[perl #53104] dyld: lazy symbol binding failed: Symbol not found: _parrot_i386_cmpxchg (icu?)
# New Ticket Created by Stephane Payrard # Please include the string: [perl #53104] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53104 When testing, got that error message. Probably linked to icu and the version used. I have 3.4.1 and 3.8.1 around.. I am not sure I currently use the later. I can't remember where is the parrot generated config file. It would be nice to have a parrot option to list the full config -- cognominal stef
Re: [perl #53086] OpenGL detection under MacOS X
On Sun, 2008-04-20 at 06:27 -0700, James Keenan via RT wrote: 1. I tried your patch out. It did not apply cleanly at first, so I had to do a little editing. I am attaching an 'svn diff' that represents the changes actually made. Yep, that was because someone else had committed a change before my patch was accepted. (I believe you figured that out on IRC already, this comment is for historical record.) This patch worked for me on Darwin in the sense that it detected OpenGL where previously the step class had not: Determining if your platform supports OpenGLyes, MacOSX_GLUT 5. Excellent. 2. Last night I wrote some tests for this step class along the lines of those found for other configuration step classes, e.g., testing for settings of results, testing for verbose output, etc. However, since the internals of this class are still under development, I have temporarily disabled some of those tests so that we don't get spurious failures. Thank you for both making the tests, and disabling them until we get the code churn settled down a bit. :-) 3. May I suggest that this code: $has_glut = _handle_glut($conf, $self-_evaluate_cc_run($test, $verbose)); ... be rewritten like this: my $rv = $self-_evaluate_cc_run($test, $verbose); $has_glut = _handle_glut($conf, $rv); This would be more consistent with the way other config step classes are coded in that it gives the method call its own statement. Originally it was written in two-line fashion. I merged it into one line because I realized _handle_glut and _evaluate_cc_run were starting to have an API between them that the calling code didn't need to understand. Yes, that's a design smell, but late last night deciding not to try to purge the design smell was the difference between getting a fresh patch done and not. :-) Thank you very much. And thank you; I'm very glad to get all the help I can with the porting issues -- and writing tests for it all is a nice bonus. :-) -'f
Re: [perl #53066] consting vtable methods
On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester [EMAIL PROTECTED] wrote: Just popping in to say that we cannot const any parms to vtable methods. Parrot can't impose promises on the called code. So take for example In default.pmc the method get_class: VTABLE PMC *get_class() :const That is expanded in default.c as: PMC * Parrot_default_get_class(PARROT_INTERP, const PMC *pmc) And inside this function: INTVAL type = VTABLE_type(interp, pmc); And VTABLE_type is: #define VTABLE_type(interp, pmc) \ (pmc)-vtable-type(interp, pmc) The type of the 'type' function is: typedef INTVAL (*type_method_t)(PARROT_INTERP, PMC* pmc); pmc points to non const PMC. So we have a problem. If vtable method params can't be const, a const method can't call any vtable function without a cast removing constnes, as long as the :const attribute is mapped in C to a const in SELF. So it looks like if vtable methods can't be const, then pmc methods can't be const at the C level without a nightmare of casts adding and removing constness. -- Salu2
Re: [perl #53082] rakudo does not use the line numbering feature of imcc. may be hllcompiler does not support it.
Patrick R. Michaud wrote: Rakudo doesn't use the line numbering feature of imcc because the line numbering feature of imcc doesn't work. See RT#43269 - setline is tied to PIR source. I wouldn't say it doesn' work per se, it just doesn't do what you want it to do. :-) There's something spec'd in the bytecode PDD to do what we need for Rakudo, it's just not implemented yet. I will try and get to it soon. Thanks, Jonathan
Re: [perl #53066] consting vtable methods
On Sun, 20 Apr 2008 21:01:01 +0200 NotFound [EMAIL PROTECTED] wrote: On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester [EMAIL PROTECTED] wrote: Just popping in to say that we cannot const any parms to vtable methods. Parrot can't impose promises on the called code. Hi Andy! Sure we can. A :const attribute on an entry in vtable.tbl results in a const added to the PMC *pmc argument in the generated vtable struct. And on the implementation side, everything matches up when you add a :const attribute to your PMC VTABLE method. Failure to do so results in an incompatible pointer warning, just like any other kind of prototype mismatch. (Of course, the writer of the vtable method can cheat and cast around it, but that's no different from any other const function in parrot.) The question isn't whether we *can* enforce a consted invocant constraint, because we certainly can. It's a question of whether we *should*. Frankly, I don't see any compelling reason to allow VTABLE_isa() or VTABLE_get_class() or VTABLE_type() to modify anything in SELF. But whether it's worth the extra constraint placed on pmc authors... I dunno. I just know the current situation is broken. Right now there is quite a bit of consting in the middle of the parrot call stack, and that's the wrong place for it. To fix this, we either need more consting in the backend (starting with some of the vtable methods), or less consting in the frontend (starting with any functions that call vtable methods). I will happily fix up all the method implementations, or all of the callers, depending on what people think about it here. So it looks like if vtable methods can't be const, then pmc methods can't be const at the C level without a nightmare of casts adding and removing constness. Agreed. And since I don't think casts are ever the right answer for this, that would mean backing out a lot of consting. (And probably, quite a bit of work to detect existing casts that hide other consting issues.) Mark
Re: [perl #53066] consting vtable methods
On Apr 20, 2008, at 2:37 PM, Mark Glines wrote: Failure to do so results in an incompatible pointer warning, just like any other kind of prototype mismatch. And that in my mind is equivalent to can't. xoxo, Andy -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
[perl #53112] [PATCH] Fixing C++ build break issue when using GMP
# New Ticket Created by Senaka Fernando # Please include the string: [perl #53112] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53112 The provided patch resolves the C++ build break caused by gmp.h. Regards, Senaka Index: src/pmc/bigint.pmc === --- src/pmc/bigint.pmc (revision 27059) +++ src/pmc/bigint.pmc (working copy) @@ -26,9 +26,13 @@ /* TODO split that out into a separate file */ -#ifdef S_SPLINT_S -# undef PARROT_HAS_GMP /* splint barfs on the gmp.h header */ -#endif /* S_SPLINT_S */ +#ifdef PARROT_HAS_GMP +# ifdef S_SPLINT_S +#undef PARROT_HAS_GMP /* splint barfs on the gmp.h header */ +# elif __cplusplus +#undef PARROT_HAS_GMP /* gmp.h header is C++ incompatible */ +# endif +#endif #ifdef PARROT_HAS_GMP # include gmp.h
[perl #53108] [BUG]
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #53108]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53108
Possible bug in expressions that mix integer and float values.
[EMAIL PROTECTED]:~$ perl6 -e 'say 1.1*1'
1.1
[EMAIL PROTECTED]:~$ perl6 -e 'say 1.1*10'
11
[EMAIL PROTECTED]:~$ perl6 -e 'say 10*1.2'
1.66058e+08
[EMAIL PROTECTED]:~$ perl6 -e 'say 20*1.1'
1.52219e+08
[EMAIL PROTECTED]:~$ for SEQ in 1 2 3 4 5; do perl6 -e say 1*${SEQ}.2; done
1.66058e+08
3.04439e+08
4.4282e+08
5.81201e+08
7.19583e+08
[EMAIL PROTECTED]:~$ uname -a
Linux KanotixBox 2.6.22-6-generic #1 SMP Sun Jun 3 18:08:36 CEST 2007 i686
GNU/Linux
[EMAIL PROTECTED]:~$ perl6 -v
This is Rakudo Perl 6, revision 27058 built on parrot 0.6.1-devel
for i486-linux-gnu-thread-multi.
Copyright 2006-2008, The Perl Foundation.
Re: [perl #53108] [BUG]
On Sun, 20 Apr 2008 11:20:08 -0700 [EMAIL PROTECTED] (via RT) [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:~$ perl6 -e 'say 1.1*10' 11 [EMAIL PROTECTED]:~$ perl6 -e 'say 10*1.2' 1.66058e+08 pmichaud nopasted some simple PIR code which reproduces the issue, and pinpoints things pretty well: [EMAIL PROTECTED]:~/parrot/trunk$ cat x.pir .sub main :main $P0 = subclass 'Integer', 'Int' $P1 = subclass 'Float', 'Num' $P0 = new 'Int' assign $P0, 1 $P1 = new 'Num' assign $P1, 1.1 $P2 = n_mul $P0, $P1 say $P2 .end [EMAIL PROTECTED]:~/parrot/trunk$ ./parrot x.pir 1.50133e+08 [EMAIL PROTECTED]:~/parrot/trunk$
Re: [perl #53112] [PATCH] Fixing C++ build break issue when using GMP
On Sunday 20 April 2008 12:17:58 Senaka Fernando wrote: The provided patch resolves the C++ build break caused by gmp.h. Index: src/pmc/bigint.pmc === --- src/pmc/bigint.pmc (revision 27059) +++ src/pmc/bigint.pmc (working copy) @@ -26,9 +26,13 @@ /* TODO split that out into a separate file */ -#ifdef S_SPLINT_S -# undef PARROT_HAS_GMP /* splint barfs on the gmp.h header */ -#endif /* S_SPLINT_S */ +#ifdef PARROT_HAS_GMP +# ifdef S_SPLINT_S +#undef PARROT_HAS_GMP /* splint barfs on the gmp.h header */ +# elif __cplusplus +#undef PARROT_HAS_GMP /* gmp.h header is C++ incompatible */ +# endif +#endif Is this really correct? My gmp.h file has: #if defined (__cplusplus) #include iosfwd /* for std::istream, std::ostream, std::string */ #include cstdio /* for std::FILE */ #endif ... so I assume that at least some versions of the library attempt to work with C++. -- c
Re: [perl #53112] [PATCH] Fixing C++ build break issue when using GMP
On Sun, 20 Apr 2008 15:08:12 -0700 chromatic [EMAIL PROTECTED] wrote: Is this really correct? My gmp.h file has: No, it's a workaround for an issue that isn't really gmp's fault. Building with g++ barfs when parsing libintl.h, included by gmp.h. Here's what happens: libintl.h defines the following two function prototypes: extern char *textdomain (__const char *__domainname) __THROW; extern char *bindtextdomain (__const char *__domainname, __const char *__dirname) __THROW; Unfortunately, PARROT_HAS_GEXTTEXT (see the typo in that?) isn't defined, so include/parrot/parrot.h does: # define textdomain(d) # define bindtextdomain(p, d) So the compiler actually sees: extern char * throw (); extern char * throw (); And barfs: src/pmc/bigint.c /usr/include/libintl.h:83: error: expected unqualified-id before 'throw' /usr/include/libintl.h:83: error: expected initializer before 'throw' /usr/include/libintl.h:87: error: expected unqualified-id before 'throw' /usr/include/libintl.h:87: error: expected initializer before 'throw' make: *** [src/pmc/bigint.o] Error 1 Fixing the typo fixes the bug. Fixed in r27065. (Still debatable whether the rest of that #else clause in parrot.h is valid, if it's causing issues like this one.) Mark
[perl #53094] [TODO] config/auto/perldoc.pm: Recent change needs discussion
fperrad reverted this in r27062. François, thanks for the quick response. Closing ticket.
[perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
# New Ticket Created by James Keenan # Please include the string: [perl #53126] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53126 I noticed that a new step, auto::digest, has been added to the list of Parrot configuration steps. Two issues: 1. The commit message suggests that this is a refactoring of code previously found elsewhere in the configuration system: r27060 | fperrad | 2008-04-20 15:26:38 -0400 (Sun, 20 Apr 2008) | 2 lines [digest]- refactor digest PMC generation (now a config/gen step) However, when I grep config/*/*.pm for 'digest', the only mention I get (other than in config/gen/digest.pm itself) is here: config/auto/crypto.pm:68:$conf-data-set( has_crypto = $has_crypto );# for dynpmc.in digest.t So I don't see where the code was refactored from, and I don't understand the rationale for the addition of this step. 2. When I now configure with 'perl Configure.pl --test', I get this warning, both at the start of configuration and in t/configure/025- options_test.t andn t/configure/049-options_test.t: No tests exist for configure step gen::digest at Configure.pl line 14 ... which means we've added a configuration step class with no corresponding tests. (Until yesterday, configuration would have simply died at this point, but I acknowledged a request to have it just generate a warning instead.) The test file could be as simple as a two-test file, with one test saying use_ok the new step and another saying 'pass'. Thank you very much. kid51
[perl #53128] PDD13PMC branch work: M2 Bytecode format milestone
# New Ticket Created by Mark Glines # Please include the string: [perl #53128] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53128 This ticket exists to track progress on the M2 Bytecode format milestone. Work on this milestone is occurring in the pdd13pmc branch. I am using RT to track progress on this milestone. I will break down the task into smaller pieces, so look for other (more specific) tickets which this ticket depends on.
Re: [perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
On Sunday 20 April 2008 18:04:34 James Keenan wrote: 2. When I now configure with 'perl Configure.pl --test', I get this warning, both at the start of configuration and in t/configure/025- options_test.t andn t/configure/049-options_test.t: No tests exist for configure step gen::digest at Configure.pl line 14 ... which means we've added a configuration step class with no corresponding tests. (Until yesterday, configuration would have simply died at this point, but I acknowledged a request to have it just generate a warning instead.) The test file could be as simple as a two-test file, with one test saying use_ok the new step and another saying 'pass'. What good would that test file do? It wouldn't tell us *anything* about Parrot and it wouldn't tell us anything interesting or useful about the configuration system. All it would do is shut up an artificial warning, which I presume is there for a very good reason. I suspect that people aren't adding test files for configuration steps because: 1) they don't know how 2) the existing tests for configuration steps are big blobs of messy, duplicated code From what I've seen of the configuration tests so far, we could replace a couple of hundred separate files with a couple of dozen data files and one or two Perl 5 modules which made assertions based on the contents of the data files. Rather than enabling warnings and then trying to shut them off just for the purpose of shutting them off, I think our strategy needs to change. I'm all for getting as much value out of our tests as possible (I could write another book about it), but I keep thinking we're heading down the wrong path with our configuration tests. Our configuration system ought to be getting easier to understand, to maintain, and modify. Is it? Our configuration tests ought to be getting more comprehensive, simpler, and valuable. Are they? -- c
[perl #53130] PDD13PMC work: implement readonly .pbc file access through PMC API
# New Ticket Created by Mark Glines # Please include the string: [perl #53130] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53130 Call into the existing src/pack*.c API if possible; cut new code if necessary.
[perl #53132] PDD13PMC work: test the hell out of PMC-based readonly .pbc file access
# New Ticket Created by Mark Glines # Please include the string: [perl #53132] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53132 Not only should it toss the proper exceptions for erroneous files, but also on erroneous usage. Test the behavior of each method. These classes should be available on the PIR level, so that's where I'll be testing it.
[perl #53134] PDD13PMC work: Move everything in parrot over to the new PMC-based API
# New Ticket Created by Mark Glines # Please include the string: [perl #53134] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53134 Deprecate and remove the src/pack* code; convert everything that breaks. This means pdump will probably have to link against libparrot.so if it doesn't already... I'm not so sure that's a bad thing.
[perl #53136] PDD13PMC work: Convert PMC-based access code to use new on-disk format
# New Ticket Created by Mark Glines # Please include the string: [perl #53136] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53136 Format specified in PDD13.
[perl #53138] PDD13PMC work: test the hell out of PMC-based .pbc file write support
# New Ticket Created by Mark Glines # Please include the string: [perl #53138] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53138 For every .pbc file created during the normal Parrot build process, the PMC based packfile support should be able to read it into memory, and then spit an identical file back out. In addition, test every field to ensure the output was modified as expected. (Fortunately, write support in this context just returns the data as a string, so we shouldn't have to muck around with temp files here.) Mark
[perl #53126] [TODO] config/auto/digest.pm: New config step needs rationale, lacks tests
On Sun Apr 20 18:50:37 2008, [EMAIL PROTECTED] wrote: [snip] . Our configuration system ought to be getting easier to understand, to maintain, and modify. Is it? Our configuration tests ought to be getting more comprehensive, simpler, and valuable. Are they? As to our configuration system in general, please see RT 53142 just filed, which calls for a PDD to document our understanding of what our current configuration system is and where it has to go. As to the tests: About a year ago particle suggested that, having finished writing tests for the build tools, I turn my attention to Configure.pl and the configuration step classes and, essentially, do there what I had done with the build tools. I did so. In fact, some of the first tests for the config step classes were written at the post-YAPC hackathon in Houston, where you were also present. But since that time I haven't had too much guidance from the Parrot leadership on this, other than speaking with Allison a bit about it at Pittsburgh Perl Workshop last October. And since, as I describe in the other RT, we don't have a PDD for configuration, I haven't been able to design from scratch a testing system that better matches our needs. If you could sketch an approach to testing that is simultaneously more comprehensive, simpler, valuable and easier to understand, maintain and modify, I might be able to work on that. As to the question of whether people know how to write tests: I think there is empirical evidence that people know how to write tests for the configuration steps. For example, when François earlier submitted config/auto/crypto.pm, it came with a very nice set of test files right from the start. In the past I have worked with people around this and I pledge to continue to do so in the future. Thank you very much. kid51
Re: [svn:parrot] r27051 - trunk/t/steps
chromatic wrote: On Saturday 19 April 2008 17:06:44 [EMAIL PROTECTED] wrote: Author: jkeenan Date: Sat Apr 19 17:06:44 2008 New Revision: 27051 Added: trunk/t/steps/auto_opengl-03.t - copied, changed from r27050, /trunk/t/steps/auto_opengl-02.t Modified: trunk/t/steps/auto_opengl-02.t Log: Add file to test auto::opengl internal subs where verbose output has been requested. Why a separate file? The Parrot::Configure object is a singleton. From my experiences over the past year, I have found that this means it's difficult to test all the effects of different command-line options in a single file. The more complex the code in a given config step's runstep() method, the more individual objects have to be created, which leads to more files. Thank you very much. kid51
Re: [svn:parrot] r27051 - trunk/t/steps
On Sunday 20 April 2008 19:34:34 James E Keenan wrote: chromatic wrote: Why a separate file? The Parrot::Configure object is a singleton. From my experiences over the past year, I have found that this means it's difficult to test all the effects of different command-line options in a single file. The more complex the code in a given config step's runstep() method, the more individual objects have to be created, which leads to more files. If there were a way to reset the data in the Parrot::Configure object, could we consolidate these files? -- c
