I need Windows OpenGL headers for study/testing
Thanks to tetragon++, I've now got OpenGL header parsing (mostly) working on both Debian Linux/i386 and Mac OS X 10.5. Now I need headers for Windows to continue the porting work. For each of MSVC, MinGW, and cygwin, I need: 1. Path globs [1] for all OpenGL headers, in the form '/path/to/dir1/*.h', '/path/to/dir2/*.h' 2. A tarball or zip archive of all of these headers Any volunteers who can send me the above for one or more of the Windows compiler environments? Thanks in advance! -'f [1] No really, I need the full path globs. I'm actually parsing the headers myself, not just trying to get C code to compile. :-)
[perl #54374] [BUG]: Warning being emitted when harness runs t/steps/inter_libparrot-*.t
Twenty-four-plus hours. No complaints. Applied in r27625. Resolved.
Re: [perl #52276] AutoReply: 0-array and 1-array composer broken
This fix the bug but does not handle multidimensional arrays.
It is dependant on the nqp patch
Index: languages/perl6/src/parser/actions.pm
===
--- languages/perl6/src/parser/actions.pm (revision 27594)
+++ languages/perl6/src/parser/actions.pm (working copy)
@@ -1629,12 +1629,19 @@
method circumfix($/, $key) {
my $past;
-if $key eq '( )' {
-$past := $( $ );
+if $key eq '[ ]' or $key eq '( )' {
+my $statement := $;
+if +$statement == 1 {
+if $statement[0] eq 'infix:,' {
+$past := $( $ );
+} else {
+$past := PAST::Op.new( :node($/), :name('list'),
:pasttype('call') );
+$past.push( $( $statement ) );
+}
+} else {
+ $past := PAST::Op.new( :node($/), :name('list'),
:pasttype('call') );
+}
}
-if $key eq '[ ]' {
-$past := $( $ );
-}
elsif $key eq '{ }' {
$past := $( $ );
}
Index: compilers/nqp/src/Grammar.pg
===
--- compilers/nqp/src/Grammar.pg(revision 27594)
+++ compilers/nqp/src/Grammar.pg(working copy)
@@ -487,3 +487,11 @@
is nullterm
{ ... }
+## loose logical operators
+proto infix: is looser(infix:<,>)
+is pasttype('if')
+{ }
+
+proto infix: is looser(infix:)
+is pasttype('unless')
+{ ... }
--
cognominal stef
Re: [perl #54376] Make runs after make clean
Bernhard, I think it is working now. I think we can close the ticket now. Thanks Bernhard Schmalhofer via RT wrote: On Sa. 17. Mai 2008, 14:31:05, [EMAIL PROTECTED] wrote: After a make realclean, make runs and builds a lot of files, failing more or less in the middle of the compiling step. Probably the makefile should be removed after make realclean, so this does not happens. Or, in other hand, create a dummy makefile asking the user to run configure. Hi Alberto, could you check again? 'Makefile' should already by removed on 'make realclean', as it is in GEN_MAKEFILES. See line 139 in config/gen/makefiles/root.in. Regards, Bernhard -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal
Re: Dynamic libraries under Darwin
Alberto Simões schrieb: Although at the moment this is just important for Mac OS X it might be useful to detect later kernel versions on Linux, and Windows versions and SPs. So, the question is: I am thinking correctly on this? Is this the way to go? If so, I can try to prepare some patches during the week. The upcoming cygwin 1.7 is a major milestone, since it will support the wide io api, for unicode filenames, e.g. perl5 support is ongoing work. I detect it with #include = 181) #include #endif ... -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Dynamic libraries under Darwin
Hi, Folks Probably some of you have noticed these errors during Parrot compilation: config/gen/platform/darwin/dl.c: In function ‘Parrot_dlopen’: config/gen/platform/darwin/dl.c:129: warning: ‘NSCreateObjectFileImageFromFile’ is deprecated (declared at /usr/include/mach-o/dyld.h:145) config/gen/platform/darwin/dl.c:133: warning: ‘NSLinkModule’ is deprecated (declared at /usr/include/mach-o/dyld.h:161) [...] Although I am not sure, I think we used these functions becaude dlopen and such didn't work pretty as expected on older Mac OS X versions. Accordingly with some web pages, now the correct way to do this is using dlopen, as in a normal Unix system. Given that we want parrot to work both on recent and older Mac OS X versions, I think we should not simply get rid of this code, but instead, add a configure step to detect the operating system and its version. Although at the moment this is just important for Mac OS X it might be useful to detect later kernel versions on Linux, and Windows versions and SPs. So, the question is: I am thinking correctly on this? Is this the way to go? If so, I can try to prepare some patches during the week. Cheers ambs -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal
Re: [perl #42393] [TODO] regex - FIXME items in languages/regex/lib/Regex/Grammar.y
On Sun, May 18, 2008 at 12:01:15PM +0200, Bernhard Schmalhofer wrote: > James E Keenan schrieb: > >Patrick R. Michaud via RT wrote: > >> plus I don't know > >>that languages/regex is being used or maintained. I vote to remove > >>languages/regex, either for the May 2008 release or soon thereafter. > > > >FWIW, svn status -v languages/regex/ suggests that François, Barney > >and chromatic have worked in this tree in the last year. So it's > >getting some degree of attention. > > I'd vote to keep it. But I don't have strong feelings either way. Seeing that it is having _some_ work done on it (if only to keep it running), I say we can keep it as well. > How about setting the tickets for the not actively developed languages > to 'STALLED'? I don't know about doing this for all inactive languages, but +1 from me for marking this ticket as 'stalled' in lieu of the options I proposed. Pm
Re: [perl #42393] [TODO] regex - FIXME items in languages/regex/lib/Regex/Grammar.y
James E Keenan schrieb: Patrick R. Michaud via RT wrote: plus I don't know that languages/regex is being used or maintained. I vote to remove languages/regex, either for the May 2008 release or soon thereafter. FWIW, svn status -v languages/regex/ suggests that François, Barney and chromatic have worked in this tree in the last year. So it's getting some degree of attention. kid51 I'd vote to keep it. But I don't have strong feelings either way. How about setting the tickets for the not actively developed languages to 'STALLED'? Regards, Bernhard
