Re: [perl #61522] build trouble on win32
Xiao Yafeng wrote: On Sat, Dec 20, 2008 at 6:56 AM, Ronald Blaschke via RT parrotbug-follo...@parrotcode.org wrote: ..\..\parrot.exe ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir --ouput=PGE\builtins_gen.pir PGE\builtins.pg MAKE : fatal error U1077: '..\..\parrot.exe' : return code '0xc005' top. MAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2' top. What version of Parrot is this? Are you passing any options to 'perl Configure.pl'? Please also add the Configure output. Version is 0.8.2 Here is output of Configure: [...] auto::jit - Determine JIT capability...Can't spawn .\test_2816.exe: Bad file descriptor at lib/Parrot/Configure/Utils.pm line 85. .yes. auto::cpu - Generate CPU specific stuff...Can't spawn .\test_2816.exe : Bad file descriptor at lib/Parrot/Configure/Utils.pm line 85. Can't spawn .\test_2816.exe: Bad file descriptor at lib/Parrot/Configure/Utils .pm line 85. .done. [...] The above looks wrong. There shouldn't be any errors during Configure. But I don't know what could cause this. I know this sounds stupid, but have you tried restarting the system? Any antivirus program active? Ron
Re: [perl #52198] [BUG]: Test failures on Win32: t/op/arithmetics.t t/op/sprintf.t t/pmc/complex.t t/pmc/float.t
Will Coleda wrote: On Wed, Jul 30, 2008 at 7:09 PM, James Keenan via RT parrotbug-follo...@parrotcode.org wrote: Interestingly enough, we are also getting failures on these 4 test files on the OpenBSD Smolder tester: http://smolder.plusthree.com/app/public_projects/report_details/3135 But, AFAICT, the Smolder server doesn't identify the particular tests within the file which are failing. kid51 Click Goto first failure. Click Failed. Click the box of the same color as the failed box: You should see the tap output: not ok 5 - Float NaN # Failed test 'Float NaN' # at t/compilers/imcc/syn/veracity.t line 113. # got: '' # expected: 'NaN is true # ' # Looks like you failed 1 test of 5. BTW, this happens because atof does not handle the 'NaN' string. I've fixed this in /branches/vc9. Ron
Re: [perl #52198] [BUG]: Test failures on Win32: t/op/arithmetics.t t/op/sprintf.t t/pmc/complex.t t/pmc/float.t
James Keenan via RT wrote: On Wed Jul 30 16:58:55 2008, jk...@verizon.net wrote: t/op/arithmetics.t t/pmc/complex.t t/pmc/float.t For the record, according to our Smolder reports for MSWin32, these 3 files have tests that are either still TODO-ed out or are failing outright on some builds. There are a number of tests skipped that pass for me on Windows using VC9. I'll have to check with MinGW, but many may no longer be relevant. I'm working on that in /branches/vc9. Unless I'm mistaken, many issues came up because of VC7.1's strange floating point handling. Ron
Re: [perl #41243] [TODO] Link on Win32 with Borland C++
Andrew Whitworth wrote: I'll pick up borland and play with it, although I won't get to it until the next cycle. I've got a really old version of Turbo C++ 4.52 left over from school, and free versions of Turbo C++ Explorer are available for download. I don't promise any miracles, but at least I will be able to prove that some errors still exist or not. --Andrew Whitworth On Tue, Dec 16, 2008 at 12:49 AM, Will Coleda via RT parrotbug-follo...@parrotcode.org wrote: On Thu Jan 11 09:55:40 2007, stmpeters wrote: On Thu Jan 11 08:57:22 2007, coke wrote: Need details. A recent patch has gotten Parrot to the point that it can be compiled with Borland C++ on Win32. Unfortunately, it does not link correctly to actually create a valid parrot executable. Additional configuration is needed to make Borland compile and link Parrot so that it can actually be run and tested. Without a champion for this compiler, there's not much we can do; Our current targets for Windows include, as I understand it, cygwin, strawberry perl and its build system, and recent versions of VisualC++. Borland isn't in our core list for the upcoming 1.0 release. If we do find a Borland champion, they should open a new ticket at https://trac.parrot.org/. Rejecting this ticket; Regards. Some time ago, because of this ticket, I tried with Borland C++ 5.5.1 and 5.82, and failed miserably. But that may just be my bad bcc-foo. Unless someone's keen for this platform and has access to a fairly new (within two years) version (is it called C++ Builder now?), I'm not sure if this is worth pursuing. Ron
Re: [perl #60678] Configure.pl manifest problem on Win32
Will Coleda wrote: On Thu, Nov 20, 2008 at 4:12 PM, Will Coleda [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 3:45 PM, Peter Schwenn [EMAIL PROTECTED] wrote: Will Coleda You can drop this thread if you like. This is a waste of your time. What I need to do is to find someone who is building parrot with XP, Cygwin or mingw -- who has been through most of what I'm going to encounter. I often build with Strawberry Perl's toolkit on windows with no problem, and we have several active windows developers; I tend to build right out of the repository, though, and not off the releases. At first blush it sounds like the filenames got case-mangled when the package was unzipped. How did you unpack the file? -- Will Coke Coleda As a data point, I just grabbed parrot-0.8.1-tar.gz from CPAN and was able to run Configure.pl with no issues using a recent Strawberry perl. I'm not seeing the case mangled filenames; they match up with what's in the MANIFEST for me. Regards. I second Will's examination. trunk and the 0.8.1 release tarball Configure just fine for me as well. That's Windows XP SP3, Perl 5.10 and VC++ 9. Ron
Re: [perl #54372] [BUG] test failures on win32/msvc
Will Coleda wrote: On Wed, Sep 10, 2008 at 10:51 PM, James Keenan via RT [EMAIL PROTECTED] wrote: Coke, particle: Where do we stand on this ticket? thank you very much. kid51 I haven't touched a win32 build of parrot in some months now, msvc or otherwise. Smolder is probably a better place to look for information at this point. Do we have anyone in the audience building on these tools that can give us a more up to date answer? I haven't seen this using Visual C++ 9.0. I'll also run a test with 6.0, 7.1 and 8.0. Is it okay if I close this ticket if nothing special shows up? (There are some test failure, but not a serious breakdown like this.)
Re: [perl #58704] [BUG] t/src/compiler.t failures with VC++ / Win32
Tim Heckman wrote: NotFound wrote: On Tue, Sep 9, 2008 at 5:23 AM, via RT Tim Heckman [EMAIL PROTECTED] wrote: # New Ticket Created by Tim Heckman # Please include the string: [perl #58704] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58704 link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib But, if I run this command using the documented linker option of /LIBPATH it *still* fails. link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib What are the error messages in this case? It seems to ignore /LIBPATH C:\work\parrotlink -nologo -nodefaultlib -debug -machine:x86 -debug t/src/c ompiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib compiler_2.obj : error LNK2001: unresolved external symbol _PMCNULL t\src\compiler_2.exe : fatal error LNK1120: 1 unresolved externals C:\work\parrot /LIBPATH adds a path to the library search path, which isn't used here for libparrot.lib because the path to the library is already specified, i.e. your FC:\work\parrot\libparrot.lib. Note that there are two libparrot.lib files: $PARROT_HOME/libparrot.lib, the import library for the dynamic libparrot.dll, and $PARROT_HOME/blib/lib/libparrot.lib, the static Parrot library. Try deleting your $PARROT_HOME/libparrot.lib and you should see LIBPATH working. Embedding Parrot on Windows using the DLL is currently broken because PMCNULL is not properly exported. That's why you receive the latter unresolved symbol error. The static library (in blib/lib) doesn't suffer from this. Ron
NCI and Calling Conventions (esp. on Windows)
AFAICT, Parrot uses function pointers for NCI. This means NCI uses whatever calling convention the compiler uses by default. Unfortunately, there's More Than One Way To Do It. On Windows, there's the C calling convention (__cdecl), which is usually used by default by the Visual C++ compiler. There's also the standard (__stdcall) and fast (__fastcall) calling convention. I haven't seen any use of fastcall, but stdcall is used by the Win32 API. Using the wrong calling convention most certainly blows the stack. I think we need a way to select the calling convention for a function, similar to, or maybe even part of, the signature. Also, it would be good to have a way to select a calling convention when loading a library, as a calling convention is usually used consistently, and providing defaults for well known libraries. Ron
[Link] Deep Dynamic Language Runtime
A quick overview of Microsoft's Dynamic Language Runtime (DLR). http://channel9.msdn.com/shows/Going+Deep/John-Lam-and-Martin-Maly-Deep-DLR/ Ron
Windows Symbol Export/Import
Currently, PARROT_API is declared similar to this. #if defined(PARROT_IN_EXTENSION) #define PARROT_API __declspec(dllimport) #else #define PARROT_API __declspec(dllexport) #endif That is, only import if we're in an extension, otherwise export. IMHO, this isn't quite right. Export and import should be set depending on whether we're compiling libparrot or using it, with the default set to using libparrot, for example like so. #if defined(PARROT_EXPORTS) #define PARROT_API __declspec(dllexport) #else #define PARROT_API __declspec(dllimport) #endif And then define PARROT_EXPORTS when compiling units that should make its way into libparrot. In Makefile terms that's O_FILES. This is the one thing I haven't figured out yet. Does anyone know how to set a compiler flag for the O_FILES only? Any other thoughts on this? Thanks, Ron
Re: time op inconsistent on Win32
Jonathan Worthington wrote: Hi, I've just been looking at the time op, and what it returns is somewhat platform specific. * On Win32, it's the number of seconds since January 1, 1601 If I remember correctly, some parts of Windows use 100ns ticks since 1601 to represent time. Not sure if computers were in common use in the 17th century, though. * In other codepaths, it appears to be the number of seconds since January 1, 1970. I'm thinking we should correct the Win32 version to do the same as the others for consistency? Or should we keep these platform specific and make code that cares check what OS we are on and work it out (don't like this option so much, since we're meant to be abstracting the OS away...) Opinions? +1 for using seconds since 1970. I can adjust this if you guys agree. Ron
Re: YAPC::EU 2008
Bernhard Schmalhofer wrote: Jonathan Worthington schrieb: Allison Randal wrote: Bernhard Schmalhofer wrote: We could always do the 12th AND the 16th, just for fun and bonus productivity (if everyone isn't exhausted from a day of hacking and three days of conference)? ;-) Patrick and I will be hacking on the 12th and the 16th. If you've not seen Copenhagen before, I could forgive you for wanting to spend a day enjoying the city rather than hacking though - it's nice! :-) Hi, I've also booked flight and hotel for August 11th to 17th. So I will be around on the 12th and the 16th. I'll be there 11th to 17th as well. See you, Ron
Re: [perl #56756] [BUG] t\pmc\pmc.t failure on win32
Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #56756] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56756 On a win32 build with AS perl and the MS tools, I get the following results: C:\research\parrotprove t/pmc/pmc.t t/pmc/pmcok 4/19 t/pmc/pmcNOK 5# Failed test 'PMC type check' # at t/pmc/pmc.t line 102. # Exited with error code: 255 # Received: # All names and ids ok. # # Expected: # /All names and ids ok/ # t/pmc/pmcok 19/19# Looks like you failed 1 test of 19. t/pmc/pmcdubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 5 Failed 1/19 tests, 94.74% okay (less 1 skipped test: 17 okay, 89.47%) Failed Test Stat Wstat Total Fail Failed List of Failed --- t/pmc/pmc.t1 256191 5.26% 5 Which Parrot and MSVC version? I'm not seeing this with r29242 using Visual C++ 9.0. $ prove -v t\pmc\pmc.t t\pmc\pmc 1..19 ok 1 - newpmc ok 2 - illegal min newpmc ok 3 - illegal max newpmc ok 4 - typeof ok 5 - PMC type check ok 6 - find_method ok 7 - new with a native type ok 8 - eq_addr same ok 9 - eq_addr diff ok 10 - if_null ok 11 - Random PMCs are singletons ok 12 - issame ok 13 # SKIP no instantiate ok 14 - .const - Sub constant ok 15 - pmc constant 1 ok 16 - pmc constant 2 ok 17 - pmc constant PASM ok 18 - logical or, and, xor ok 19 - new_p_s ok All tests successful. Files=1, Tests=19, 1 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU) Result: PASS Ron
The long long and The Short of It
Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the following produce a working Parrot, using 64-bit ints? perl Configure.pl --intval=long long int --opcode=long long int If fails for me on Cmake while building PGE. ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg make[1]: *** [PGE.pbc] Segmentation fault make[1]: *** Deleting file `PGE.pbc' The resulting Parrot is partially usable, though. $ ./parrot examples/pasm/hello.pasm Hello World Ron
Re: [perl #56484] Re: The long long and The Short of It
chromatic wrote: On Monday 30 June 2008 13:00:37 Will Coleda wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #56484] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56484 Any time we can produce a segfault, that's bad. CC'ing rt to get a ticket. On Mon, Jun 30, 2008 at 3:55 PM, Ron Blaschke [EMAIL PROTECTED] wrote: Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the following produce a working Parrot, using 64-bit ints? perl Configure.pl --intval=long long int --opcode=long long int If fails for me on Cmake while building PGE. ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg make[1]: *** [PGE.pbc] Segmentation fault make[1]: *** Deleting file `PGE.pbc' The resulting Parrot is partially usable, though. $ ./parrot examples/pasm/hello.pasm Hello World Ron, do you get any warning messages during Configure? I see: Figuring out how to pack() Parrot's types...Configure.pl: Unable to find a functional packtype for intvalsize. 'q' failed: Invalid type 'q' in pack at config/auto/pack.pm line 62. Configure.pl: Unable to find a functional packtype for opcode_t_size. 'q' failed: Invalid type 'q' in pack at config/auto/pack.pm line 62. I'm only seeing this warning during Configure. Determining some sizes... Hmm, I see your chosen INTVAL isn't the same size as your pointers. Parrot should still compile and run, but you may see a ton of warnings. .done. But I'm using a long long Perl build. Sorry, forgot to mention that. $ perl -V:ivtype ivtype='long long'; There are also plenty of build warnings, such as: src/headers.c: In function ‘Parrot_destroy_header_pools’: src/headers.c:912: warning: cast to pointer from integer of different size I suspect that fixing those would fix the segfaults. I'm getting those too. Some pieces don't seem to fit together. On my system, miniparrot crashes; can you provide a backtrace? Here's the one from the PGE segfault above. (gdb) backtrace 10 #0 0xb7deba88 in compact_pool (interp=0x8052040, pool=0x8052b60) at src/gc/resources.c:450 #1 0xb7debe0d in Parrot_go_collect (interp=0x8052040) at src/gc/resources.c:564 #2 0xb7c6aeae in Parrot_dod_ms_run (interp=0x8052040, flags=1) at src/gc/dod.c:1141 #3 0xb7c6afe6 in Parrot_do_dod_run (interp=0x8052040, flags=1) at src/gc/dod.c:1194 #4 0xb7c6cdb0 in more_traceable_objects (interp=0x8052040, pool=0x8072cd8) at src/gc/smallobject.c:163 #5 0xb7c6ce8a in gc_ms_get_free_object (interp=0x8052040, pool=0x8072cd8) at src/gc/smallobject.c:245 #6 0xb7c703a7 in new_pmc_header (interp=0x8052040, flags=1024) at src/headers.c:322 #7 0xb7cc05e2 in get_new_pmc_header (interp=0x8052040, base_type=34, flags=1024) at src/pmc.c:246 #8 0xb7cc012a in pmc_new (interp=0x8052040, base_type=34) at src/pmc.c:71 #9 0xb7ed0591 in Parrot_PMCProxy_nci_parents (interp=0x8052040, pmc=0x8212938) Here's one running parrot examples/shootout/ack.pir. (gdb) backtrace 10 #0 0xb69c19b5 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7d14b4b in compact_pool (interp=0x8052040, pool=0x8052b60) at src/gc/resources.c:473 #2 0xb7d14e0d in Parrot_go_collect (interp=0x8052040) at src/gc/resources.c:564 #3 0xb7b93eae in Parrot_dod_ms_run (interp=0x8052040, flags=1) at src/gc/dod.c:1141 #4 0xb7b93fe6 in Parrot_do_dod_run (interp=0x8052040, flags=1) at src/gc/dod.c:1194 #5 0xb7b95db0 in more_traceable_objects (interp=0x8052040, pool=0x8072cd8) at src/gc/smallobject.c:163 #6 0xb7b95e8a in gc_ms_get_free_object (interp=0x8052040, pool=0x8072cd8) at src/gc/smallobject.c:245 #7 0xb7b993a7 in new_pmc_header (interp=0x8052040, flags=1024) at src/headers.c:322 #8 0xb7be95e2 in get_new_pmc_header (interp=0x8052040, base_type=20, flags=1024) at src/pmc.c:246 #9 0xb7be912a in pmc_new (interp=0x8052040, base_type=20) at src/pmc.c:71 Ron
Re: [perl #44763] [BUG] Assertion fails if PCRE is not available
James Keenan via RT wrote: This is what I'm getting on Linux where Configure.pl says that I do not have PCRE: $ prove -v t/library/pcre.t t/examples/library.t t/library/pcre.. 1..1 ok 1 # SKIP no pcre-config ok t/examples/library.. 1..4 ok 1 - examples/library/getopt_demo.pir ok 2 - examples/library/md5sum.pir ok 3 # SKIP no pcre-config not ok 4 - ncurses_life.pir # TODO ncurses_life.pir not testable yet # Failed (TODO) test 'ncurses_life.pir' # at t/examples/library.t line 77. ok All tests successful. Files=2, Tests=5, 0 wallclock secs ( 0.00 usr 0.00 sys + 0.11 cusr 0.03 csys = 0.14 CPU) Result: PASS Ron, what are you getting now on Windows? Sorry, should have been more specific. The key here is to make PCRE.dll disappear when Parrot tries to load it. The tests now check for PCRE (SKIP no pcre-config), so you don't even get to this point. But r28376 seems to handle this gracefully as well, instead of the failed assertion deep in the guts. Closing this ticket. $parrot examples\library\pcre.pir ab a Failed to load libpcre current instr.: 'parrot;PCRE;init' pc 99 (library/pcre.pir:106) called from Sub 'parrot;PCRE;main' pc 244 (examples\library\pcre.pir:39) Ron
Re: Renaming Plumhead
Bernhard Schmalhofer wrote: Plumhead, from *P*lum*h*eaded *P*arakeet, is the current name of the PHP on Parrot implementation. As Plumhead is a stupid name, cotto proposed to rename to Pharrot. Pharrot is definitly nicer than Plumhead, but maybe too close to Parrot. Furthermore it changes the 'P' sound that is common to PHP and Parrot to an 'F' sound. The last time Pharrot' was used as a project name, it was renamed to Pint. http://blog.coggeshall.org/archives/290-Back-from-the-Int.-PHP-Conference.html So I'm still open for an alternative. If no better suggestion turns up, I'll rename to 'Pharrot' after the June release. Off the top of my head, I think Pharrot isn't a bad choice. Maybe written as Pherrot? As an alternative, maybe Phoebe or PHoePe? ;-) Ron
Re: I need Windows OpenGL headers for study/testing
Geoffrey Broadwell wrote: On Tue, 2008-05-27 at 21:16 +0200, Ron Blaschke wrote: [Answers to all my questions] Forgot to mention, I sent in a new patch a few hours ago incorporating all of the OpenGL Win32/MSVC portability fixes to RT 54868: http://rt.perl.org/rt3/Ticket/Display.html?id=54868 Can you give that latest patch a try, and let me know what breaks? I've applied the patch against a clean r27888 and got: Generating runtime/parrot/includedone. Generating OpenGL bindings... step gen::opengl died during execution: 'GLOBAL_LOGGER_NAME' is defined as 'GLOBAL_LOGGER_NAMEW', but no 'GLOBAL_LOGGER_NAMEW' has been defined at config/gen/opengl.pm line 403. at Configure.pl line 66 Generating NCI signature listdone. The platform is Windows XP, Visual C++ 9.0, Windows SDK 6.0, GLUT 3.7. Ron
Re: I need Windows OpenGL headers for study/testing
Geoffrey Broadwell wrote: On Wed, 2008-05-28 at 20:39 +0200, Ron Blaschke wrote: [snip] In other words, let's assume the *parent* of the /gl/ directory will be in the include path list, and force to only glob the /gl/ child of that parent. The original version would also glob all the files in the parent itself, which is causing the problem you see. I guess you are right. I have changed it as you suggested. Now Configure says: Generating OpenGL bindings...In OpenGL header 'C:/Program Files/Microsoft SDKs/Windows/v6.1/Include/gl/GLU.h', prototype 'gluErrorUnicodeStringEXT', can't handle type 'wchar_t*'; original prototype: const wchar_t* APIENTRY gluErrorUnicodeStringEXT ( GLenum errCode); In OpenGL header 'C:/Program Files/Microsoft SDKs/Windows/v6.1/include/gl/GLU.h', prototype 'gluErrorUnicodeStringEXT', can't handle type 'wchar_t*'; original prototype: const wchar_t* APIENTRY gluErrorUnicodeStringEXT ( GLenum errCode); In OpenGL header 'C:/Program Files/Microsoft SDKs/Windows/v6.1/include/gl/GLU.h', prototype 'gluErrorUnicodeStringEXT', can't handle type 'wchar_t*'; original prototype: const wchar_t* APIENTRY gluErrorUnicodeStringEXT ( GLenum errCode); .done. Ron
Re: I need Windows OpenGL headers for study/testing
Geoffrey Broadwell wrote: On Wed, 2008-05-28 at 21:30 +0200, Ron Blaschke wrote: Geoffrey Broadwell wrote: I guess you are right. I have changed it as you suggested. Now Configure says: Generating OpenGL bindings...In OpenGL header 'C:/Program Files/Microsoft SDKs/Windows/v6.1/Include/gl/GLU.h', prototype 'gluErrorUnicodeStringEXT', can't handle type 'wchar_t*'; original prototype: const wchar_t* APIENTRY gluErrorUnicodeStringEXT ( GLenum errCode); In OpenGL header 'C:/Program Files/Microsoft SDKs/Windows/v6.1/include/gl/GLU.h', prototype 'gluErrorUnicodeStringEXT', can't handle type 'wchar_t*'; original prototype: const wchar_t* APIENTRY gluErrorUnicodeStringEXT ( GLenum errCode); In OpenGL header 'C:/Program Files/Microsoft SDKs/Windows/v6.1/include/gl/GLU.h', prototype 'gluErrorUnicodeStringEXT', can't handle type 'wchar_t*'; original prototype: const wchar_t* APIENTRY gluErrorUnicodeStringEXT ( GLenum errCode); OK, I know what's causing this (no typemap entry for 'wchar_t*', as the error indicates). Not sure about best NCI type type to match this to -- it really wants to be a native Parrot string with encoding UCS2, I believe, but I don't know how to do that off the top of my head, and I need to run now. I'll ruminate on this later -- though if you wanted to try skipping over it and see what else goes wrong later on, just put a typemap in config/gen/opengl.pm for wchar_t = 'void', and it will just pretend wchar_t* is a void buffer. Workaround looks good. Build is okay, Fexamples/opengl/triangle.pir runs fine. Ron
Re: I need Windows OpenGL headers for study/testing
Geoffrey Broadwell wrote:
On Tue, 2008-05-27 at 11:29 +0200, Ron Blaschke wrote:
OK, I'll generate the Win32 header list from $ENV{Include}. What is
that set to on your system, so I know what to expect?
Mine currently is:
INCLUDE=C:\usr\include;C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE;C:\Program Files\Microsoft
SDKs\Windows\v6.1\include;C:\Program Files\Microsoft Visual Studio
9.0\VC\Include;C:\Program Files\Microsoft
SDKs\Windows\v6.1\Include;C:\Program Files\Microsoft
SDKs\Windows\v6.1\Include\gl;;C:\Program Files\Subversion
1.4\include;C:\Program Files\ICU\icu-3.8\include;C:\Program
Files\boost\boost_1_34_1
I guess the two important parts are to ignore empty elements (multiple
semicolons in the middle or at the end) and to make sure it works with
spaces. C:\usr\include is the place I put headers of smaller
libraries, not any system default.
Hmmm. That brings up several questions/thoughts:
1. It looks like I need to add filtering of empty elements, as you said,
but since I'm dealing with globs I doubt the current situation will
actually break things for you.
True.
2. I haven't tried dealing with spaces, but according to the docs
CORE::glob() will do the Wrong Thing. I'll switch that over to
File::Glob::bsd_glob().
Sounds good.
3. I see that you've got 'Include' and 'INCLUDE' for the name of the
environment variable. Which one is correct, or is %ENV case insensitive
on Windows?
The environment is case insensitive on Windows too. Perl will get the
right one either way. In C%ENV the keys are normalized to all
uppercase. Usually, the names are all uppercase in the environment as
well, for example INCLUDE, LIB, PATH. Others are mixed case, e.g.
WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v6.1\
Probably depends which MS developer wrote the stuff.
4. Is the 'C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\gl'
entry always going to be there if the SDK is installed? In other words,
should my globs assume that $PATH/*.h will be valid, or do I need to
search for $PATH/gl/*.h as well?
I think it's safer to search C$INCLUDE/gl/*.h as well. I never
noticed the gl directory before, it might be a recent addition.
Using the Visual Studio 2008 (Express) Command Prompt I get:
INCLUDE=C:\Program Files\Microsoft Visual Studio
9.0\VC\ATLMFC\INCLUDE;C:\Program Files\Microsoft Visual Studio
9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.1\include;
Visual Studio and the Windows SDK feel like different beasts, only by
accident sharing a similar compiler. ;-)
5. For that matter, what happens in Perl on Windows when a path has a
mix of forward and backward slashes? If this is broken, is it safe to
convert them all to forward slashes? Is C:/Foo/Bar valid in Windows
Perl?
Perl can handle it, other programs often as well. Not sure about the
Windows API itself, but I think not. I usually prefer using File::Spec.
Let me know if I can help in any other way. I'm also on #parrot, but
somewhat infrequently.
What is your nick? Mine is japhb.
Sorry, forgot to mention. It's Ron. ;-)
Ron
Re: I need Windows OpenGL headers for study/testing
Hi Geoffrey, I managed to get the Fexamples/opengl/triangle.pir running on Windows XP SP3, VC++ 9.0, using Parrot r27789. There are glitches involved, though. I'll just explain what I did. First I checked the OpenGL install on my box. I have the Windows SDK for Windows Server 2008 and .NET Framework 3.5 installed which contains the necessary OpenGL headers and libs. It's installed at CC:\Program Files\Microsoft SDKs\Windows\v6.1. The relevant files are: Include/gl/GL.h Include/gl/GLU.h Lib/OpenGL32.Lib Lib/GlU32.Lib The DLLs are: C:\WINDOWS\system32\opengl32.dll C:\WINDOWS\system32\glu32.dll I added GLUT [1] (glut.h, glut32.lib and glut32.dll), as it wasn't present. Then I hacked Fconfig/auto/opengl.pm and Fconfig/gen/opengl.pm to look for these files. win32_nongcc= 'opengl32.lib glu32.lib glut32.lib' To answer question 1., the location of the headers depends on the used installation and version. I don't think there's an easy way to specify an absolute file glob. On the bright side, there are the environment variables CInclude, CLib and CPath, containing a semicolon separated list of directories that are searched by the compiler and linker. After that I modfied Fruntime/parrot/library/OpenGL.pir to look for the relevant DLLs by adding the following to the relevant sections. push libnames, 'opengl32' push libnames, 'glu32' push libnames, 'glut32' Interestingly, when saying Copengl32.dll instead of Copengl32 it seems like one needs to specify the full path to the library. Things get a bit more interesting with Fsrc/glut_callbacks.c. First, I needed to modify the link directive in FMakefile to: $(LIBGLUTCB_SO): $(LIBPARROT) $(SRC_DIR)/glut_callbacks$(O) $(LD) $(LD_LOAD_FLAGS) $(LDFLAGS) \ @[EMAIL PROTECTED]@ $(SRC_DIR)/glut_callbacks$(O) $(ALL_PARROT_LIBS) Note the missing C@ncilib_link_extra@ and the replacement of C$(C_LIBS) with C$(ALL_PARROT_LIBS). C@ncilib_link_extra@ contains the directive to export test symbols from libnci, which are not present with the callback library, leading to a link error. I needed to replace CC_LIBS with CALL_PARROT_LIBS because the callback contains references to libparrot. Finally, I added the following to Fsrc/glut_callbacks.c. #define PARROT_IN_EXTENSION And did a Cs/PARROT_API/PARROT_DYNEXT_EXPORT/ on the file. After all this hard work I called Cparrot examples\opengl\triangle.pir and enjoyed the triangle to rotate, and rotate, and rotate (still wondering when it'll stop...) Ron [1] http://www.opengl.org/resources/libraries/glut/ Geoffrey Broadwell wrote: 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. :-)
Re: [perl #42699] r18304 Test failures on NexentaOS (GNU/OpenSolaris)
chromatic via RT wrote: On Sunday 13 April 2008 10:34:22 Ronald Blaschke via RT wrote: Here's the result of r26955. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/examples/shootout.t 13 332820 13 65.00% 1 3 6-11 14-15 17-19 t/op/trans.t 1 256221 4.55% 14 t/pmc/os.t 1 256151 6.67% 9 The details of the failed tests are as follows. t/examples/shootout.. # Failed test (t/examples/shootout.t at line 108) # Exited with error code: [SIGNAL 139] # Received: # # Expected: # Ack(3, 7) = 1021 # I'm skipping the remaining output of t/examples/shootout.t. All segfaults, I think. Which processor? Can you post a backtrace? (If it's Sparc, I think I know what the problem is. If it's not Sparc... well, let's hope the problem is similar.) Sorry for the late response. It's an x86. Here's a backtrace of r27131. Starting program: parrot -Oc -Cj examples/shootout/ack.pir Program received signal SIGSEGV, Segmentation fault. 0x086180c0 in ?? () (gdb) backtrace #0 0x086180c0 in ?? () #1 0x0811db2f in cgp_core (cur_op=0x8624e0c, interp=0x8407ac0) at pic.ops:294 #2 0x081def52 in runops_cgp (interp=0x8407ac0, pc=0x862854c) at src/interpreter.c:776 #3 0x081df19a in runops_int (interp=0x8407ac0, offset=3) at src/interpreter.c:916 #4 0x080e3f99 in runops (interp=0x8407ac0, offs=3) at src/inter_run.c:104 #5 0x080e4239 in runops_args (interp=0x8407ac0, sub=0x86057c0, obj=0x846fa08, meth_unused=0x0, sig=0x83594e7 vP, ap=0x804795c [EMAIL PROTECTED]) at src/inter_run.c:230 #6 0x080e437d in Parrot_runops_fromc_args (interp=0x8407ac0, sub=0x86057c0, sig=0x83594e7 vP) at src/inter_run.c:299 #7 0x080db56a in Parrot_runcode (interp=0x8407ac0, argc=1, argv=0x8047a58) at src/embed.c:941 #8 0x081928af in imcc_run_pbc (interp=0x8407ac0, obj_file=0, output_file=0x0, argc=1, argv=0x8047a58) at compilers/imcc/main.c:781 #9 0x08193340 in imcc_run (interp=0x8407ac0, sourcefile=0x8047b51 examples/shootout/ack.pir, argc=1, argv=0x8047a58) at compilers/imcc/main.c:1069 #10 0x080d54c5 in main (argc=1, argv=0x8047a58) at src/main.c:61 I think it's JIT related? Ron
Re: [perl #52198] [BUG]: Test failures on Win32: t/op/arithmetics.t t/op/sprintf.t t/pmc/complex.t t/pmc/float.t
chromatic wrote: On Friday 28 March 2008 11:55:30 James Keenan via RT wrote: Am confused. What diagnostic output beyond 'prove -v' are you referring to? For example... t/op/arithmetics1..26 ok 1 - take the negative of a native integer ok 2 - take the absolute of a native integer ok 3 - add native integer to native integer ok 4 - subtract native integer from native integer ok 5 - multiply native integer with native integer ok 6 - divide native integer by native integer not ok 7 - turn a native number into its negative ... diagnostic output missing right here... ok 8 - take the absolute of a native number The test expected the output: -0.00 0.00 -123.456789 123.456789 -0.00 0.00 -123.456789 123.456789 Obviously it received something else. What did it receive? As far as I know, Visual C++ is a bit shaky on the arithmetic side with regards to +/- 0.0. For example, the constant C-0.0 is turned into C0.0. One has to revert to hacks like C-1.0 * 0.0, if I recall correctly. t/op/arithmetics.t not ok 7 - turn a native number into its negative # Failed test 'turn a native number into its negative' # at t\op\arithmetics.t line 210. # got: '0.00 # 0.00 # -123.456789 # 123.456789 # 0.00 # 0.00 # -123.456789 # 123.456789 # ' # expected: '-0.00 # 0.00 # -123.456789 # 123.456789 # -0.00 # 0.00 # -123.456789 # 123.456789 # ' t/op/sprintf.t not ok 157 - [%.0g] C99 standard mandates minus sign but C89 does not skip: MSWin32 VMS hpux:10.20 openbsd netbsd:1.5 irix actual: 0 t/pmc/complex.t not ok 48 - sinh of complex numbers # Failed test 'sinh of complex numbers' # at t\pmc\complex.t line 1647. # got: ' # sinh(0-2i) # got 0.00-0.909297i # not -0.00-0.909297i # # sinh(0+2i) # got 0.00+0.909297i # not -0.00+0.909297i # done # ' # expected: 'done # ' t/pmc/float.t not ok 23 - neg 0 # Failed test 'neg 0' # at t\pmc\float.t line 547. # '0' # doesn't match '/^-0/ # ' Ron
PARROT_ASSERT considerations
PARROT_ASSERT is currently defined as:
#ifdef NDEBUG
# define PARROT_ASSERT(x) ((void)0)
#else
# define PARROT_ASSERT(x) Parrot_assert((INTVAL)(x), #x, __FILE__,
__LINE__)
#endif
with
void
Parrot_assert(INTVAL condition, ARGIN(const char *condition_string),
ARGIN(const char *file), unsigned int line)
...
PARROT_ASSERT is used to assert pointers too, for example in src/string.c:
UINTVAL
string_length(SHIM_INTERP, ARGIN(const STRING *s))
{
PARROT_ASSERT(s);
return s-strlen;
}
The cast from all kinds of stuff, including pointers, to INTVAL bothers
me a bit. It ties pointers to INTVALs, which I guess it shouldn't.
One way to improve this (for certain values of improvement) is to change
PARROT_ASSERT to:
# define PARROT_ASSERT(x) Parrot_assert((!!(x)), #x, __FILE__, __LINE__)
Independent of this, pointer assertions should probably be explicit, to
show what condition is actually asserted.
PARROT_ASSERT(s != NULL);
Or maybe PARROT_ASSERT should have friends, like PARROT_ASSERT_PTR to
assert pointers? This might do additional checks, like 0xdeadbeef or
-1 pointer. This may be a bit far fetched, though.
void
Parrot_assert_ptr(void *ptr, ARGIN(const char *condition_string),
ARGIN(const char *file), unsigned int line)
{
if (ptr == NULL || ptr == -1 || ptr == 0xdeadbeef)
Parrot_confess(condition_string, file, line);
}
What do you think?
Ron
Re: PARROT_ASSERT considerations
Leopold Toetsch wrote:
Am Dienstag, 11. März 2008 20:43 schrieb Ron Blaschke:
void
Parrot_assert(INTVAL condition, ARGIN(const char *condition_string),
ARGIN(const char *file), unsigned int line)
...
PARROT_ASSERT is used to assert pointers too, for example in src/string.c:
What about making Parrot_assert a macro too, or probably simpler fixing
PARROT_ASSERT for the ! NDEBUG case:
#define PARROT_ASSERT(x) \
do { \
if (!x) \
Parrot_confess(#x, __FILE__, __LINE__) \
} \
while (0)
- untested - just an idea.
leo
I like it, but I'd rather have you guys make the call.
I'm bringing this up because VC++ has the option to check if a cast
looses information (C-RTCc Convert to smaller type checks), which I
hope to help me with getting Parrot working on Windows x64.
I've just looked up how C's assert is implemented in two libraries.
glibc 2.7
# define assert(expr) \
((expr) \
? __ASSERT_VOID_CAST (0) \
: __assert_fail (__STRING(expr), __FILE__, __LINE__, __ASSERT_FUNCTION))
Windows SDK 6.0
#define assert(_Expression) (void)( (!!(_Expression)) ||
(_wassert(_CRT_WIDE(#_Expression), _CRT_WIDE(__FILE__), __LINE__), 0) )
Ron
Re: PARROT_ASSERT considerations
Andy Lester wrote: On Mar 11, 2008, at 2:43 PM, Ron Blaschke wrote: It ties pointers to INTVALs, which I guess it shouldn't. As I read the mail, it seems like the only problem we have is in casting the pointer to an int to find its truthiness. I'd say use the !!(x) and be done with it. The PARROT_ASSERT_POINTER() idea gives me the willies because of checking for hardcoded magic values. I think you are right. Checking for magic values is useful as a local modification only, when looking for a specific bug. Thanks, Ron
Re: Scheduler, Timer and DOD
James E Keenan wrote: Ron Blaschke wrote: Hi, I've been looking into a failure of Ft/dynoplibs/myops.t on Windows, but I don't think the problem is limited to that platform. $ prove t\dynoplibs\myops.t t\dynoplibs\myops..5/10 t\dynoplibs\myops..6/10 # Failed test 'three alarm' # at t\dynoplibs\myops.t line 118. # Exited with error code: 255 A friend on Win32 reported a failure in this test on March 1, but the only output presented was: t/dynoplibs/myops.t(Wstat: 256 Tests: 10 Failed: 1) Failed test: 5 Non-zero exit status: 1 I was unable to reproduce the error on either Darwin or Linux. Interesting, I haven't seen this one either, even on Windows. But I guess everything goes on Murphy XP. Do you know if there's a ticket for this? Ron
Re: Scheduler, Timer and DOD
chromatic wrote: On Saturday 08 March 2008 07:31:08 Ron Blaschke wrote: I've been looking into a failure of Ft/dynoplibs/myops.t on Windows, but I don't think the problem is limited to that platform. $ prove t\dynoplibs\myops.t t\dynoplibs\myops..5/10 t\dynoplibs\myops..6/10 # Failed test 'three alarm' # at t\dynoplibs\myops.t line 118. # Exited with error code: 255 # Received: # alarm1 # alarm2 # alarm3 # # Expected: # /alarm1 # alarm2 # alarm3/ # The test output is good, but the error code is 255. Actually, the test exits with an access violation. After stepping through things a couple of times with a debugger I think the cause for this is that through the final DOD run (Parrot_exit - Parrot_really_destroy - Parrot_do_dod_run) the scheduler is destroyed *before* the last task. When the task is finally destroyed, the scheduler is already 0xdeadbeef. Here's the final stack trace. Parrot_cx_delete_task Parrot_Timer_destroy Parrot_dod_free_pmc Parrot_dod_sweep Parrot_dod_ms_run Parrot_do_dod_run Parrot_really_destroy Parrot_exit At this line in Parrot_cx_delete_task. VTABLE_delete_keyed_int(interp, interp-scheduler, tid); That's as far as I got. I don't know enough about the DOD details to make a good guess on the cause. Maybe both scheduler and task are determined to be not-reachable, but the destruction sequence is not ordered? The destruction sequence is not ordered, so if a task happens to have a PMC header created prior to the scheduler's PMC header, then this problem will occur. (We reuse PMC headers, so this can happen in not-easily-deterministic ways.) Making the scheduler a constant PMC would likely fix this, but then anything to which the scheduler points also has to be constant. It might be possible to finish the scheduled tasks prior to destroying all PMCs. Not sure if I'm going into the wrong direction here, but can't this happen with any PMC? Say I write my own scheduler and task PMCs, working similarly? Or any other PMCs where destroy calls out to another PMC? I guess this depends on the contract of destroy. If destroy may not call out to any other PMC, a special case for the scheduler is fine, because it really is special. If destroy may call out there needs to be additional or different handling, to ensure the referenced object is not collected first. In that case, it sounds akin to finalizers in a JVMisch, CLRisch senes. With all the fun border cases, like a PMC resurrecting, for example by registering itself at a live PMC. At least this last issue seems to be covered by PDD 17 by ...make sure that you don't leave any references to it in any Parrot structure by the end of the method. In this sense, Cinterp-scheduler in Timer counts as a reference, and doesn't follow the rule. Or does it? I'm confused. Thanks, Ron
Scheduler, Timer and DOD
Hi, I've been looking into a failure of Ft/dynoplibs/myops.t on Windows, but I don't think the problem is limited to that platform. $ prove t\dynoplibs\myops.t t\dynoplibs\myops..5/10 t\dynoplibs\myops..6/10 # Failed test 'three alarm' # at t\dynoplibs\myops.t line 118. # Exited with error code: 255 # Received: # alarm1 # alarm2 # alarm3 # # Expected: # /alarm1 # alarm2 # alarm3/ # The test output is good, but the error code is 255. Actually, the test exits with an access violation. After stepping through things a couple of times with a debugger I think the cause for this is that through the final DOD run (Parrot_exit - Parrot_really_destroy - Parrot_do_dod_run) the scheduler is destroyed *before* the last task. When the task is finally destroyed, the scheduler is already 0xdeadbeef. Here's the final stack trace. Parrot_cx_delete_task Parrot_Timer_destroy Parrot_dod_free_pmc Parrot_dod_sweep Parrot_dod_ms_run Parrot_do_dod_run Parrot_really_destroy Parrot_exit At this line in Parrot_cx_delete_task. VTABLE_delete_keyed_int(interp, interp-scheduler, tid); That's as far as I got. I don't know enough about the DOD details to make a good guess on the cause. Maybe both scheduler and task are determined to be not-reachable, but the destruction sequence is not ordered? Ron
Re: [perl #51104] [BUG] bad pointer! segfaults are bad!
Jerry Gay (via RT) wrote: # New Ticket Created by Jerry Gay # Please include the string: [perl #51104] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51104 during the build of languages/c99, specifically: ..\..\parrot.exe -o src\CPP_PGE2AST.pbc --output-pbc src\CPP_PGE2AST.pir boom. msvcr80.dll!strlen(unsigned char * buf=0x0400) Line 81 Asm libparrot.dll!read_macro(YYSTYPE * valp=0x0017fb8c, parrot_interp_t * interp=0x03ab1248, void * yyscanner=0x03be5ec0) Line 991 + 0xb bytes C libparrot.dll!yylex(YYSTYPE * valp=0x0017fb8c, void * yyscanner=0x03be5ec0, parrot_interp_t * interp=0x03ab1248) Line 425 + 0x11 bytes C libparrot.dll!yyparse(void * yyscanner=0x03be5ec0, parrot_interp_t * interp=0x03ab1248) Line 2601 + 0x14 bytes C libparrot.dll!compile_to_bytecode(parrot_interp_t * interp=0x03ab1248, const char * const sourcefile=0x03ab1219, const char * const output_file=0x03ab11f8) Line 951 + 0xd bytes C libparrot.dll!imcc_run(parrot_interp_t * interp=0x03ab1248, const char * sourcefile=0x03ab1219, int argc=1, const char * * argv=0x03ab11c8) Line 1051 + 0x11 bytesC parrot.exe!main(int argc=1, const char * * argv=0x03ab11c8) Line 56 + 0x15 bytesC parrot.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C kernel32.dll!76d019f1() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!7775d109() at line 990 in imcc.l, valp is uninitialized. it's full of bad pointers. i haven't tracked down why. any help? I think this is the same as [perl#47978][C99][IMCC] double free. The issue seems to be caused by languages/c99/src/preamble, where: .local $iter_loop: Consider this test program. $cat m.pir .macro test .local $iter_loop: .endm $ parrot -o m.pbc --output-pbc m.pir compilers/imcc/imcc.l:992: failed assertion 'valp-s' (Remove the colon and it parses again.) I could track it down as far as read_macro in imcc.l, where line 1015 does not fill valp, and returns the token MACRO. c = yylex(valp, yyscanner, interp); Ron
Re: [perl #47978] [C99] [IMCC] double free
chromatic wrote: On Thursday 29 November 2007 20:34:17 Will Coleda wrote: On feather, languages/c99 (et al.) fail with: $ make ../../parrot -o src/CPP_PGE2AST.pbc --output-pbc src/CPP_PGE2AST.pir *** glibc detected *** ../../parrot: double free or corruption (fasttop): 0x0823e328 *** running this through gdb, I get: bt #0 0xb7f41402 in __kernel_vsyscall () #1 0xb6f77a85 in raise () from /lib/i686/nosegneg/libc.so.6 #2 0xb6f794e1 in abort () from /lib/i686/nosegneg/libc.so.6 #3 0xb6faf7dc in __libc_message () from /lib/i686/nosegneg/libc.so.6 #4 0xb6fb7755 in _int_free () from /lib/i686/nosegneg/libc.so.6 #5 0xb6fbb270 in free () from /lib/i686/nosegneg/libc.so.6 #6 0xb7e75ad5 in read_macro (valp=0xbfc40c4c, interp=0x804f008, yyscanner=0x8235678) at compilers/imcc/imcc.l:888 #7 0xb7e71d71 in yylex (valp=0xbfc40c4c, yyscanner=0x8235678, interp=0x804f008) at compilers/imcc/imcc.l:385 #8 0xb7e6b85d in yyparse (yyscanner=0x8235678, interp=0x804f008) at compilers/imcc/imcparser.c:2598 #9 0xb7e7856a in compile_to_bytecode (interp=0x804f008, sourcefile=0xbfc41bb5 src/CPP_PGE2AST.pir, output_file=0xbfc41b94 src/CPP_PGE2AST.pbc) at compilers/imcc/ main.c:960 #10 0xb7e788f6 in imcc_run (interp=0x804f008, sourcefile=0xbfc41bb5 src/CPP_PGE2AST.pir, argc=1, argv=0xbfc40ec4) at compilers/imcc/main.c:1060 #11 0x0804896d in main (argc=1, argv=0xbfc40ec4) at src/main.c:62 compilers/imcc/imcc.l:888 seems to be where it goes off the rails.. IANACP, but there seems to be several calls to 'free(valp-s)' in that function that aren't careful about not freeing that pointer more than once. I think this is the same as [perl#51104][BUG] bad pointer! segfaults are bad!. The issue seems to be caused by languages/c99/src/preamble, where: .local $iter_loop: Consider this test program. $cat m.pir .macro test .local $iter_loop: .endm $ parrot -o m.pbc --output-pbc m.pir compilers/imcc/imcc.l:992: failed assertion 'valp-s' (Remove the colon and it parses again.) I could track it down as far as read_macro in imcc.l, where line 1015 does not fill valp, and returns the token MACRO. c = yylex(valp, yyscanner, interp); Ron
What are the constraints for INTVAL?
Hi, I'm trying to get an intuition how Parrot uses the basic data types, with an eye on INTVAL and opcode_t, what their limits and relationships are. Given a regular 32-bit x86 box, should it be possible to use Parrot with a 16-bit short, or a 64-bit long long, intval? The same question for opcode? One constraint seems to be: ... Invoking Parrot to generate runtime\parrot\include\config.fpmc --cross your fingers .\miniparrot.exe config_lib.pasm runtime\parrot\include\config.fpmc src\pmc_freeze.c:645: failed assertion 'sizeof (opcode_t) == sizeof (INTVAL)' ... Many thanks, Ron
Re: Quick config/auto/pack.pm Question
James E Keenan wrote: Ron Blaschke wrote: l is documented as: l A signed long (32-bit) value. I'm not expert in this, so let me ask: Where is this documented other than 'perldoc -f pack'? Yes, that's where it's documented. Am I missing something obvious here? Ron
Quick config/auto/pack.pm Question
I noticed the following in pack.pm.
sub _set_ptrconst {
my ($conf, $ptrsize, $intsize, $longsize) = @_;
if ( $intsize == $ptrsize ) {
$conf-data-set( ptrconst = u );
}
elsif ( $longsize == $ptrsize ) {
$conf-data-set( ptrconst = ul );
}
else {
warn AARGH;
Configure.pl: Unable to find an integer type that fits a pointer.
AARGH
}
}
The first condition is good, but I don't think the second ($longsize ==
$ptrsize) is. l is documented as:
l A signed long (32-bit) value.
So, this only works okay if $longsize is 4, or am I missing something?
Shouldn't it better be like this?
sub _set_ptrconst {
my ($conf, $ptrsize) = @_;
if ( $ptrsize == 2 ) {
$conf-data-set( ptrconst = us );
}
elsif ( $ptrsize == 4 ) {
$conf-data-set( ptrconst = ul );
}
elsif ( $ptrsize == 8 ) {
$conf-data-set( ptrconst = uq );
}
else {
warn AARGH;
Configure.pl: Unable to find an integer type that fits a pointer.
AARGH
}
}
Ron
Re: [perl #50622] nmake test bug?
jerry gay wrote: On Feb 7, 2008 5:38 AM, via RT Ted Neward [EMAIL PROTECTED] wrote: t/library/pg. Interestingly, a parrot.exe process is left running, even after Ctrl-C'ing the console window in which the tests are running. Could very well be a configuration problem, would love to know how to correct it if it is. it seems that parrot thinks you have postgres libraries installed. do you? you don't need them to run parrot (i don't have them installed on my windows system.) so, you can work around the problem by taking those libs out of your path, so parrot's configure won't find them. of course, that won't fix the problem, it just works around it. i (or someone else, please!) will have to install postgres libs in an environment and configure/build/test parrot to reproduce this behavior. this may take some time. if you intend to work with parrot and postgres specifically, where this integration would be important, let us know so we can bump up the priority. ~jerry This is with r25584, WinXP, VC9, PostgreSQL 8.3. Without PostgreSQL, eveythings skipped, as expected. $ parrot t/library/pg.t 1..43 ok 1 #skip skipped ok 2 #skip skipped ... ok 42 #skip skipped ok 43 #skip skipped With PostgreSQL (that is, adding ...\PostgreSQL\8.3\bin to PATH): $ parrot t/library/pg.t 1..43 ok 1 - load_bytecode ok 2 - load_bytecode Pg ok 3 - Pg class exists Method 'connectdb' not found for invocant of class 'Pg' current instr.: 'main' pc 67 (t/library/pg.t:48) Ron
Re: Let's use snprintf()
Andy Lester wrote: On Feb 5, 2008, at 1:17 PM, [EMAIL PROTECTED] wrote: (He sent this to me directly by mistake) snprintf is problematic on older Solaris systems, for one. At least through 2.7 (2.8?) it's not included in any lib. So other apps needed to test and bring in their own version. This is covered in the ticket that exists already, it turns out: http://rt.perl.org/rt3/Ticket/Display.html?id=39117 Short version: We'll need to make a snprintf() wrapper around sprintf() that ignores the length argument for the systems that don't support it. I'd rather ignore the length and pass on through to sprintf() than to have a parallel implementation. Ignoring the length parameter leaves those platforms without snprintf() exactly where they are today. I'm wondering if we should aim for TR 24731: Extensions to the C Library Part I: Bounds-checking interfaces [1]. I kind of like the idea, but uncertain how much it caught on yet (or will). [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf Ron
Re: Anyone has perl 1 docs?
jesse wrote: If only Perl1 source would compile, then it'd be easier, but it doesn't compile on windows (xp) and can't get it working on cygwin either. That sounds like the sort of situation where VMWare Player and, say, an ubuntu or redhat virtual machine might come in really handy. I don't believe Perl 1 was ever ported to Windows. Well, actually it kinda was. ;-) http://www.nntp.perl.org/group/perl.perl1.porters/2005/11/msg46.html Ron
Re: Anyone has perl 1 docs?
Klaas-Jan Stol wrote:
On Jan 14, 2008 5:57 PM, Mark J. Reed [EMAIL PROTECTED] wrote:
On Jan 14, 2008 11:29 AM, Ron Blaschke [EMAIL PROTECTED] wrote:
jesse wrote:
I don't believe Perl 1 was ever ported to Windows.
Well, actually it kinda was. ;-)
http://www.nntp.perl.org/group/perl.perl1.porters/2005/11/msg46.html
Cool! So where's that patch you mentioned? The attachment doesn't
seem to have made it into the archive there...
Sorry, didn't realize attachments don't make it over the news gateway.
I just got things working on cygwin; in perl.h there's a #define of sprintf,
as sprintf(), which needs to be changed into:
sprintf(char *dest, char * const format, ...)
This worked for me on cygwin; didnt' try yet on win xp 32.
Great, glad you've got it working!
I have attached the patch that worked for me way back then. This is for
Cygwin only, too.
Ron
diff -u -r perl-1.0_16.orig/perl.h perl-1.0_16/perl.h
--- perl-1.0_16.orig/perl.h 2002-12-19 00:44:14.0 +0100
+++ perl-1.0_16/perl.h 2005-11-06 11:21:04.0 +0100
@@ -64,7 +64,7 @@
#ifdef CHARSPRINTF
char *sprintf();
#else
-int sprintf();
+/* int sprintf(); */
#endif
/* A string is TRUE if not or 0. */
diff -u -r perl-1.0_16.orig/perl.y perl-1.0_16/perl.y
--- perl-1.0_16.orig/perl.y 2002-12-19 00:44:14.0 +0100
+++ perl-1.0_16/perl.y 2005-11-06 11:36:22.0 +0100
@@ -16,6 +16,16 @@
#include util.h
#include INTERN.h
#include perl.h
+
+ARG *l(ARG *,...);
+ARG *mod_match(int, ARG *, ARG *);
+ARG *addflags(int, int , ARG*);
+ARG *hide_ary(ARG *);
+ARG *make_list(ARG *);
+ARG *listish(ARG *);
+ARG *cval_to_arg(char *);
+ARG *cmd_to_arg(CMD *);
+
char *tokename[] = {
256,
word,
diff -u -r perl-1.0_16.orig/perly.c perl-1.0_16/perly.c
--- perl-1.0_16.orig/perly.c2002-12-19 00:44:14.0 +0100
+++ perl-1.0_16/perly.c 2005-11-06 11:31:42.0 +0100
@@ -23,7 +23,7 @@
char *filename;
char *e_tmpname = /tmp/perl-eXX;
FILE *e_fp = Nullfp;
-ARG *l();
+ARG *l(ARG *, ...);
main(argc,argv,env)
register int argc;
Chain Smoker
I've started to hack up a little script to chain smoke Parrot. It's quite simple, all it currently does is: for each test configuration * copy (a hopefully clean) 'trunk' to a smoke directory * wipe the environment and replace with a controlled one (mostly Path, Include, Lib and http_proxy, but could contain anything necessary). * perl Configure.pl * $make * $make smoke * $make languages-smoke * delete the temporary smoke directory The current configurations are: Visual C++ 6.0, 7.1, 8.0, 9.0 and (MinGW) GCC 3.4.2, 4.2.1 no dependencies (i.e., no ICU, no GMP, ...) both regular and --optimized Next I'd like to add all optional dependencies as another build configuration dimension, probably bundled together into a smoke chamber to isolate them from my remaining system. If someone is interested in this, or if you have an idea how to make it more useful, please let me know. As a first result, it seems like Parrot r23791 fails to build using Visual C++ 6.0 or 7.1, optimized. ..\..\parrot.exe -o PGE.pbc --output-pbc PGE.pir ..\..\parrot.exe ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir --output=PGE\builtins_gen.pir PGE\builtins.pg NMAKE : fatal error U1077: '..\..\parrot.exe' : return code '0xc005' Stop. NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2' Stop. Ron
Re: [perl #46937] [PATCH] Parenthesis spacing patch (win32)
Applied, thanks! (r22519)
Re: [perl #44291] [PATCH] Fix for suncc
Ron Blaschke wrote:
Joshua Isom wrote:
On Oct 13, 2007, at 7:20 AM, Ron Blaschke wrote:
Attached patch should fix computed goto on Solaris with the Sun C
compiler.
[snip]
Could someone please review the patch if I got it right, and maybe test
it on other computed goto platforms?
Just to clarify, you did reenable CGP in compilers/imcc/main.c,
correct? It's been disabled for a while.
Bummer, no I did not. I thought everything was connected to Configure's
--cgoto. Thanks for noticing, Joshua.
chromatic, thanks for giving it a spin. Since it's working for you I
guess it'll work on Solaris as well, but I'll verify on Monday. This
time, the right way.
I've revised the patch a bit (r22073 introduced an incompatible change)
and tested it against r22101.
$make testC
All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 8 tests and 242
subtests skipped.
Passed TODO Stat Wstat TODOs Pass List of Passed
---
t/op/debuginfo.t21 8
Files=222, Tests=4816, 995 wallclock secs (439.78 cusr + 369.99 csys =
809.77
CPU)
Ron
Index: lib/Parrot/OpTrans/CGP.pm
===
--- lib/Parrot/OpTrans/CGP.pm (revision 22101)
+++ lib/Parrot/OpTrans/CGP.pm (working copy)
@@ -91,7 +91,7 @@
return if ($addr == 0)
return 0;
_reg_base = (char*)interp-ctx.bp.regs_i;
- goto **(cur_opcode = opcode_to_prederef(interp, $addr));
+ goto **(void **)(cur_opcode = opcode_to_prederef(interp, $addr));
}
}
@@ -105,7 +105,7 @@
sub goto_offset {
my ( $self, $offset ) = @_;
-return goto **(cur_opcode += $offset);
+return goto **(void **)(cur_opcode += $offset);
}
=item Cgoto_pop()
@@ -118,7 +118,7 @@
sub goto_pop {
my ($self) = @_;
-return goto **(opcode_t *)(cur_opcode = opcode_to_prederef(interp,
+return goto **(void **)(cur_opcode = opcode_to_prederef(interp,
(opcode_t*)pop_dest(interp)));
}
Index: lib/Parrot/Ops2c/Utils.pm
===
--- lib/Parrot/Ops2c/Utils.pm (revision 22101)
+++ lib/Parrot/Ops2c/Utils.pm (working copy)
@@ -588,7 +588,7 @@
# endif
#endif
_reg_base = (char*)interp-ctx.bp.regs_i;
-goto **cur_opcode;
+goto **(void **)cur_opcode;
END_C
}
Re: [perl #44291] [PATCH] Fix for suncc
Attached patch should fix computed goto on Solaris with the Sun C compiler.
All tests successful (7 subtests UNEXPECTEDLY SUCCEEDED), 11 tests and
621 subtests skipped.
Passed TODO Stat Wstat TODOs Pass List of Passed
---
t/src/intlist.t44 1-4
t/src/io.t 33 16-17 19
Files=349, Tests=7904, 1398 wallclock secs (668.38 cusr + 455.97 csys =
1124.35 CPU)
Could someone please review the patch if I got it right, and maybe test
it on other computed goto platforms?
Ron
Index: lib/Parrot/Ops2c/Utils.pm
===
--- lib/Parrot/Ops2c/Utils.pm (revision 22065)
+++ lib/Parrot/Ops2c/Utils.pm (working copy)
@@ -588,7 +588,7 @@
# endif
#endif
_reg_base = (char*)interp-ctx.bp.regs_i;
-goto **cur_opcode;
+goto **(void **)cur_opcode;
END_C
}
Index: lib/Parrot/OpTrans/CGP.pm
===
--- lib/Parrot/OpTrans/CGP.pm (revision 22065)
+++ lib/Parrot/OpTrans/CGP.pm (working copy)
@@ -91,7 +91,7 @@
return if ($addr == 0)
return 0;
_reg_base = (char*)interp-ctx.bp.regs_i;
- goto **(cur_opcode = opcode_to_prederef(interp, $addr));
+ goto **(void **)(cur_opcode = opcode_to_prederef(interp, $addr));
}
}
@@ -105,7 +105,7 @@
sub goto_offset {
my ( $self, $offset ) = @_;
-return goto **(cur_opcode += $offset);
+return goto **(void **)(cur_opcode += $offset);
}
=item Cgoto_pop()
Index: PLATFORMS
===
--- PLATFORMS (revision 22065)
+++ PLATFORMS (working copy)
@@ -30,8 +30,8 @@
sol8-sparc-ccB--- - - -Y/412 ?
20070917
sol10-sparc-cc_5.8 BY-- Y Y YY/9 ?
20060807
sol10-sparc-gcc_4.0.2BY-- Y Y YY/9 ?
20060807
-sol10-x86-cc_5.9 4 --- - - YY*4 ?
20070914
-sol11-x86-cc_5.8 --- - - - Y/121*4 ?
20070821
+sol10-x86-cc_5.9 4 --- - - YY ?
20071010
+sol11-x86-cc_5.8 --- - - - Y/121 ?
20070821
opensolaris-x86-gcc_4.0.3 4 YY? ? ? YY/3 ?
20070417
tru64-alpha-compaq_c6.5 8 ??? Y ? YY/2 ?
20060203
win32-x86-cygwin_1.5.21 --- - - -- -
20070221
@@ -71,7 +71,6 @@
*2 some tests fail intermittently when building x86 on xeon processor
*3 t/stm/basic_mt.t occasionally hangs. kill it for tests to complete.
1 other test fails. 7 unexpected todos succeed.
-*4 You must run Configure.pl with --cgoto=0, see RT#44291
The following configurations are also working on x86/linux (and possibly
other platforms):
Re: [perl #44291] [PATCH] Fix for suncc
Joshua Isom wrote: On Oct 13, 2007, at 7:20 AM, Ron Blaschke wrote: Attached patch should fix computed goto on Solaris with the Sun C compiler. [snip] Could someone please review the patch if I got it right, and maybe test it on other computed goto platforms? Just to clarify, you did reenable CGP in compilers/imcc/main.c, correct? It's been disabled for a while. Bummer, no I did not. I thought everything was connected to Configure's --cgoto. Thanks for noticing, Joshua. chromatic, thanks for giving it a spin. Since it's working for you I guess it'll work on Solaris as well, but I'll verify on Monday. This time, the right way. Thanks, Ron
Re: mod_perl6 update
Jeff Horwitz wrote: It gives me great pleasure to introduce you to the world's first mod_perl6 handlers! They are run using Parrot's Perl6 compiler on top of mod_parrot, and are compiled on the fly the first time a handler is called. Each handler is passed an [Apache;RequestRec] object instantiated by mod_parrot, and the handlers can call methods on that object from Perl6 land. Wow, very cool! It's been a while since a counter got me addicted like this. Ron
Re: welcome ron to the company of parrots
jerry gay wrote: i've just given ron blaschke (aka ron or rblasch) a commit bit. please join me in welcoming him to the core committers. over the last few years, ron has submitted many high-quality patches, and has always been willing to share his knowledge of windows-based programming. Many thanks! ron has told me privately that he plans to migrate the windows vista source to parrot. we look forward to a future where parrot acts as the virtual machine for an operating system, particularly one so loved and respected by all. The code name for this is Windows Vienna, in honor of this year's YAPC::EU. This is a considerable effort, but should be out by Christmas. Share the love! Ron
Some Thoughts on Windows Linking and Loading
Linking and loading is arguably one of the more difficult things on Windows. I'd like to let you know about how some of the things work. I think this is important because there are still some issues with that we need to sort out. Not sure if I get everything right here, so please feel free to correct me. Let's start with loading. When Windows loads an executable it also checks the import directory of the image. There's one entry for each DLL. Windows searches for DLLs as described in [1] and loads the image, if possible at the preferred load address. If not possible the DLL is relocated. This means the location of the DLL is not fixed, and the code needs to deal with this. Windows uses an Import Address Table (IAT) for this. There's one entry for each imported symbols and all access is done indirectly through this table. If the DLL needs to be relocated only the IAT needs to be updated. This is not important here, but there are actually two tables. An Import Address Table (IAT) and an Import Name Table (INT). If a symbol is to be resolved by name it first searches the Import Name Table for the name and then uses the index for the Import Address Table. Now to compiling and linking. Visual C++ uses two declarations, for exporting symbols from a DLL and importing from one. __declspec(dllexport) void f(); This tells the compiler to pass a directive to the linker (/LINK option) that f should be exported. __declspec(dllimport) void f(); This tells the compiler to resolve symbols through the Import Address Table. When f is called the compiler generates an indirect call through the IAT instead of a simple, direct call. Similar for data access. So, when compiling code for a DLL you need to decorate it with dllexport. When using it you need to decorate it with dllimport. When linking a DLL the linker creates the DLL and an import library (.lib). All information that's needed for linking against the DLL is in the import library. void f(); It's also possible to call functions which are not declared with dllimport. That's possible because for each exported function the linker creates a little magic, a stub function that makes a jump through the Import Address Table. This only works for functions, though, and adds overhead of the indirection. On the other hand, this way the compiler does not, and need not, know if the function is just another function in another compilation unit, a function in a static library or in a DLL, when compiling the function call. One convention that is used to get the declaration right goes like this: #ifdef project_EXPORTS #define project_API __declspec(dllexport) #else #define project_API __declspec(dllimport) #endif Whenever a source file is compiled that should be part of the DLL it's compiled with -Dproject_EXPORTS. Users of the library just need to make sure they don't declare project_EXPORTS. So, why is this relevant for Parrot? Currently it looks like this in Finclude/parrot/config.h #if defined(PARROT_IN_EXTENSION) #define PARROT_API __declspec(dllimport) #define PARROT_DYNEXT_EXPORT __declspec(dllexport) #else #define PARROT_API __declspec(dllexport) #endif PARROT_IN_EXTENSION is only defined in extensions (dynop, dynpmc). As you can see, the default is dllexport, which users and embedders will use. This is not a problem for functions, as the stubs will be used, as described above. But this doesn't work for data, and for example shows during Ft/src/compiler.t tests. error LNK2001: unresolved external symbol _PMCNULL t\src\compiler_2.exe : fatal error LNK1120: 1 unresolved externals Ron [1] http://msdn2.microsoft.com/en-us/library/ms682586.aspx
Re: [perl #43191] [BUG] Parrot doesn't build on Solaris: cannot dereference non-pointer type
Bernhard Schmalhofer via RT wrote: On Di. 12. Jun. 2007, 22:38:24, rblasch wrote: I tried to smoke r18926 on Solaris but failed because of tons of cannot dereference non-pointer type errors. Ronald, can you still verify this with svn HEAD ? Yes, still a problem with HEAD. I should have read PLATFORMS more carefully, though, because it's already known. ... sol11-x86-cc_5.8 --- - - - Y/121*4 ? 20070821 ... *4 You must run Configure.pl with --cgoto=0 ... That is, it won't compile with Cperl Configure.pl because computed gotos are determined but don't seem to compile as used in the ops. Cperl Configure.pl --cgoto=0 compiles just fine. Ron
Re: [perl #44967] Using a freed variable (Coverity CID 98)
I've had another look at this. Here's what I think is going on.
The relevant output is:
Event use_after_free: Using freed pointer (ins)-next
Also see events: [alias][freed_arg]
493 for (ins = unit-instructions; ins; ins = ins-next) {
Event alias: aliasing (ins)-next with ins2
Also see events: [freed_arg][use_after_free]
512 for (ins2 = ins-next; ins2; ins2 = ins2-next) {
Event freed_arg: Pointer ins2 freed by function subst_ins [model]
Also see events: [alias][use_after_free]
536 subst_ins(unit, ins2, tmp, 1);
The key here is the model. While Coverity's model captures the
Cfree quite correctly, I don't think it recognizes the pointer update
in the double linked list, which is done in Csubst_ins, as important.
Coverity probably sees something like the following in the inspected code:
Instruction *ins, *ins2;
for (ins = unit-instructions; ins; ins = ins-next) {
ins2 = ins-next;
free(ins2);
}
So, it's a false positive.
Ron
Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed
Bernhard Schmalhofer (via RT) wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #45109] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45109 In languages/lisp/system.pir there are 4 unused PMCs declared. Removing one of them breaks Lisp. Here is an example session: [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ svn diff Index: system.pir === --- system.pir (Revision 20981) +++ system.pir (Arbeitskopie) @@ -24,7 +24,6 @@ .local pmc dummy_1 .local pmc dummy_2 .local pmc dummy_3 -.local pmc dummy_4 _init_reader_macros( package ) [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ ../../parrot lisp.pbc t/arithmetics_1.l wrong number of arguments to %GET-OBJECT-ATTRIBUTE current instr.: '_error' pc 2065 (read.pir:194) called from Sub '_get_object_attr' pc 7321 (system.pir:12) called from Sub '_setq' pc 14048 (cl.pir:941) called from Sub '_load' pc 7021 (system.pir:436) called from Sub '_common_lisp' pc 17015 (lisp.pir:77) [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ uname -a Linux clou 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ cat /etc/issue Ubuntu 7.04 \n \l [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ My guess is that this is GC-related, but I haven't verified or falsified that yet. I've had a first look at this and I think it's a problem in the compiler. Here's a disassembly comparison between the current version, with the workaround, and a version without .local pmc dummy_4, as in the diff above. --- lisp.pbc.workaround 2007-09-01 17:02:22.0 +0200 +++ lisp.pbc.bad2007-09-01 17:02:05.0 +0200 @@ -1308,8 +1308,8 @@ 0fc1: 0025 0015 get_results_pc 0fc3: 0262 0006 0177 callmethodcc_p_sc 0fc6: 02bb 0003 0045new_p_sc 0fc9: 032f 0012 01c0set_p_pc 0fcc: 02a6 0003 0047 0012 setattribute_p_sc_p 0fc9: 032f 0013 01c0set_p_pc + 0fcc: 02a6 0003 0047 0013 setattribute_p_sc_p 0fd0: 02bb 001a 0035new_p_sc 0fd3: 0336 001a 0168set_p_sc 0fd6: 0024 000d set_args_pc @@ -1325,8 +1325,8 @@ 0ff6: 0025 0015 get_results_pc 0ff8: 0262 0006 008f callmethodcc_p_sc 0ffb: 02bb 0003 0045new_p_sc - 0ffe: 032f 0011 01c4set_p_pc - 1001: 02a6 0003 0047 0011 setattribute_p_sc_p + 0ffe: 032f 0012 01c4set_p_pc + 1001: 02a6 0003 0047 0012 setattribute_p_sc_p 1005: 02bb 001a 0035new_p_sc 1008: 0336 001a 0169set_p_sc 100b: 0024 000d set_args_pc @@ -1342,7 +1342,7 @@ 102b: 0025 0015 get_results_pc 102d: 0262 0006 008f callmethodcc_p_sc 1030: 02bb 0003 0045new_p_sc - 1033: 032f 0013 01b2set_p_pc + 1033: 032f 0011 01b2set_p_pc 1036: 02a6 0003 0047 0013 setattribute_p_sc_p 103a: 02bb 001a 0035new_p_sc 103d: 0336 001a 0161set_p_sc
Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed
Bernhard Schmalhofer (via RT) wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #45109] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45109 In languages/lisp/system.pir there are 4 unused PMCs declared. Removing one of them breaks Lisp. Here is an example session: [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ svn diff Index: system.pir === --- system.pir (Revision 20981) +++ system.pir (Arbeitskopie) @@ -24,7 +24,6 @@ .local pmc dummy_1 .local pmc dummy_2 .local pmc dummy_3 -.local pmc dummy_4 _init_reader_macros( package ) [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ ../../parrot lisp.pbc t/arithmetics_1.l wrong number of arguments to %GET-OBJECT-ATTRIBUTE current instr.: '_error' pc 2065 (read.pir:194) called from Sub '_get_object_attr' pc 7321 (system.pir:12) called from Sub '_setq' pc 14048 (cl.pir:941) called from Sub '_load' pc 7021 (system.pir:436) called from Sub '_common_lisp' pc 17015 (lisp.pir:77) [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ uname -a Linux clou 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ cat /etc/issue Ubuntu 7.04 \n \l [EMAIL PROTECTED]:~/devel/Parrot/repos/parrot/languages/lisp$ My guess is that this is GC-related, but I haven't verified or falsified that yet. I've had a first look at this and I think it's a problem in the compiler. Here's a disassembly comparison between the current version, with the workaround, and a version without .local pmc dummy_4, as in the diff above. --- lisp.pbc.workaround 2007-09-01 17:02:22.0 +0200 +++ lisp.pbc.bad2007-09-01 17:02:05.0 +0200 @@ -1308,8 +1308,8 @@ 0fc1: 0025 0015 get_results_pc 0fc3: 0262 0006 0177 callmethodcc_p_sc 0fc6: 02bb 0003 0045new_p_sc - 0fc9: 032f 0012 01c0set_p_pc - 0fcc: 02a6 0003 0047 0012 setattribute_p_sc_p + 0fc9: 032f 0013 01c0set_p_pc + 0fcc: 02a6 0003 0047 0013 setattribute_p_sc_p 0fd0: 02bb 001a 0035new_p_sc 0fd3: 0336 001a 0168set_p_sc 0fd6: 0024 000d set_args_pc @@ -1325,8 +1325,8 @@ 0ff6: 0025 0015 get_results_pc 0ff8: 0262 0006 008f callmethodcc_p_sc 0ffb: 02bb 0003 0045new_p_sc - 0ffe: 032f 0011 01c4set_p_pc - 1001: 02a6 0003 0047 0011 setattribute_p_sc_p + 0ffe: 032f 0012 01c4set_p_pc + 1001: 02a6 0003 0047 0012 setattribute_p_sc_p 1005: 02bb 001a 0035new_p_sc 1008: 0336 001a 0169set_p_sc 100b: 0024 000d set_args_pc @@ -1342,7 +1342,7 @@ 102b: 0025 0015 get_results_pc 102d: 0262 0006 008f callmethodcc_p_sc 1030: 02bb 0003 0045new_p_sc - 1033: 032f 0013 01b2set_p_pc + 1033: 032f 0011 01b2set_p_pc 1036: 02a6 0003 0047 0013 setattribute_p_sc_p 103a: 02bb 001a 0035new_p_sc 103d: 0336 001a 0161set_p_sc In all three sections a value is loaded into a register and then set as an attribute on an object. In the first hunk only the used register is changed from 0x12 to 0x13. In the second hunks it's register 0x11 to 0x12. With hunk three it's getting interesting because only the first occurrence changes from 0x13 to 0x11. set_attribute still uses 0x13, which is wrong I think. In the end, the wrong (Sub) value is put into the object's attribute because the wrong register is used. The error that comes up later is not because the arguments are wrong, but because the wrong sub is called. Can anyone tell if I'm on the right track? Ron
Re: [perl #45109] [Lisp] Breakage when an unused PMC is removed
Bernhard Schmalhofer wrote:
Ron Blaschke via RT schrieb:
In all three sections a value is loaded into a register and then set as
an attribute on an object.
In the first hunk only the used register is changed from 0x12 to 0x13.
In the second hunks it's register 0x11 to 0x12.
With hunk three it's getting interesting because only the first
occurrence changes from 0x13 to 0x11. set_attribute still uses 0x13,
which is wrong I think.
In the end, the wrong (Sub) value is put into the object's attribute
because the wrong register is used. The error that comes up later is
not because the arguments are wrong, but because the wrong sub is called.
Can anyone tell if I'm on the right track?
Yes, I can see the pattern. One possibility to verify this, is to add a
'dummy_5' PMC.
I'd expect three hunks again, but the third hunk should than conform to
the two first hunks.
Here's what happens if .local pmc dummy_5 is added, compared to the
current repository version with .local pmc dummy_[1-4].
--- lisp.pbc.workaround 2007-09-01 17:02:22.0 +0200
+++ lisp.pbc.workaround22007-09-02 20:24:32.0 +0200
@@ -1445,7 +1445,7 @@
116b: 0262 0006 008f
callmethodcc_p_sc
116e: 02bb 0003 0045new_p_sc
1171: 032f 0019 01a2set_p_pc
- 1174: 02a6 0003 0047 0019
setattribute_p_sc_p
+ 1174: 02a6 0003 0047 0011
setattribute_p_sc_p
1178: 02bb 001a 0035new_p_sc
117b: 0336 001a 015dset_p_sc
117e: 0024 000d set_args_pc
Is this a register allocator bug?
Not sure yet. I think I've found the source that corresponds to the
opcodes. It's CFUNCTION in Finclude/macros/types.pir.
#.macro FUNCTION(F,L)
#
#.F = new LispFunction
116e: 02bb 0003 0045new_p_sc
== new, P3, constant 0x45 (LispFunction)
#.const .Sub _func = .L
1171: 032f 0019 01a2set_p_pc
== set P25, ???
#setattribute .F, body, _func
1174: 02a6 0003 0047 0019setattribute_p_sc_p
== setattribute P3, constant 0x47 (body), P25
# but when this go bad:
1174: 02a6 0003 0047 0011setattribute_p_sc_p
== setattribute P3, constant 0x47 (body), P17
#
#.endm
The constants (0x45 and 0x47) are indexes into the constant pool.
# 69:
[ 'PFC_STRING', {
FLAGS= 0x61100,
CHARSET = 3961080,
SIZE = 12,
DATA = 'LispFunction'
} ],
# 71:
[ 'PFC_STRING', {
FLAGS= 0x61100,
CHARSET = 3961080,
SIZE = 4,
DATA = 'body'
} ],
The situation in the previous posting was this.
#.macro FUNCTION(F,L)
#
#.F = new LispFunction
1030: 02bb 0003 0045new_p_sc
== new, P3, constant 0x45 (LispFunction)
#.const .Sub _func = .L
1033: 032f 0013 01b2set_p_pc
== set P19, ???
# or:
1033: 032f 0011 01b2set_p_pc
== set P17, ???
#setattribute .F, body, _func
1036: 02a6 0003 0047 0013setattribute_p_sc_p
== setattribute P3, constant 0x47 (body), P19
#
#.endm
I'm currently trying to understand the code well enough to step through
this with a debugger when the instructions are generated.
Ron
Re: [perl #44967] Using a freed variable (Coverity CID 98)
Paul Cochrane wrote:
I've had a chance to look at this and the implementation looks quite
good to me.
There's one thing that still bothers me. The snipped output is:
Event alias: aliasing (ins)-next with ins2
Also see events: [freed_arg][use_after_free]
At conditional (1): ins2 != 0 taking true path
512 for (ins2 = ins-next; ins2; ins2 = ins2-next) {
...
Event freed_arg: Pointer ins2 freed by function subst_ins [model]
Also see events: [alias][use_after_free]
536 subst_ins(unit, ins2, tmp, 1);
There's Also see events: [freed_arg][use_after_free] and there's a
line saying Event freed_arg: ...
Then there's Also see events: [alias][use_after_free] and a line
saying Event alias: ...
This makes we wonder if there's any line saying Event use_after_free:
... in the report?
Thanks,
Ron
Re: [perl #44967] Using a freed variable (Coverity CID 98)
Paul Cochrane wrote: On 26/08/07, chromatic [EMAIL PROTECTED] wrote: On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote: The variable ins2 is freed by the call to subst_ins() but is then later assigned to later in the if-block. Um, this isn't a good idea is it? The variable shouldn't be freed in subst_ins() I don't think, so shouldn't we instead have the line: subst_ins(unit, ins2, tmp, 0); (where setting the argument to 0 means *not* freeing the variable). Is this the right thing to do? Just wanted to ask the opinion of our resident gurus before I went and broke something... free() takes a pointer and frees the memory pointed at. The variable itself is just a storage location for that pointer. Maybe reusing the variable name is confusing to humans, but I don't see any particular trouble for the computer here. Ok, I'll just tell the Coverity thing to ignore that particular warning. Just curious, but could you please post the exact wording of the warning? Thanks, Ron
Re: [perl #44967] Using a freed variable (Coverity CID 98)
Paul Cochrane wrote:
On 27/08/07, Ron Blaschke [EMAIL PROTECTED] wrote:
Paul Cochrane wrote:
On 26/08/07, chromatic [EMAIL PROTECTED] wrote:
On Sun, Aug 26, 2007 at 11:14:11AM -0700, Paul Cochrane wrote:
Ok, I'll just tell the Coverity thing to ignore that particular warning.
Just curious, but could you please post the exact wording of the warning?
Sure. I'll have to piece this together a bit from the various pieces
of info from the web app output, so please, bear with me.
Warning:
USE_AFTER_FREE
File: compilers/imcc/optimizer.c
Function: constant_propagation
Description: Using freed pointer (ins)-next
[snip]
Many thanks Paul. The error message talks about (ins)-next. There
are two of those in constant_propagation. Coverity does not show line
numbers, does it? Is there any way to dump the sequence of statements
that triggers the error report?
line 593:
for (ins = unit-instructions; ins; ins = ins-next) {
line 612:
for (ins2 = ins-next; ins2; ins2 = ins2-next) {
^
I don't have time right now to wrap my brain around this right now, but
I'd like to think this through before dismissing it. The two loops with
Cins and Cins2 do make me a bit uncomfortable, if it's a false
positive I'd really like to know why. But don't let me hold you up on
this, continue as you see fit.
Ron
Re: Need JIT help please - JIT broken with optimized build on Windows (VC)
Paolo Molaro wrote: On 08/16/07 Ron Blaschke wrote: This optimization reaches likely back to times, when the opcode engine was designed. It's saving one interpreter push statement [1] per JIT calling one external function, and I've always thought of it as a very cool (and valid) thingy, when I first realized, why the interpreter is the second argument in opcode functions ;) I think it's a really cool idea, too. I'd like to have a way to disable it, though, to measure its effect, and maybe to work around compilers like VC (at least until a better solution comes around). The optimization done by the parrot jit is invalid for the x86 C calling convention: the area of memory containing the passed arguments can be used as scratch space by the called function. If you can make sure it's not harmful that way you could still use it when calling parrot's own jitted functions which could use a different calling convention, but it is wrong when interoperating with other code (gcc can generate the same issues, so it's not just VC). Many thanks for your help. I couldn't find detailed descriptions of the x86 C calling convention, which also talk about this. But as nobody explicitly says you can reuse it, I guess it's undefined and should be avoided. Thanks, Ron
Re: Current win32 linking issues: Summary
Mark Glines wrote: On Tue, 21 Aug 2007 13:08:05 +0200 Ron Blaschke [EMAIL PROTECTED] wrote: The win32 skippage will need to be removed again, once the PMCNULL symbol is exported correctly from libparrot.dll. Not adding the skip on the other t/src tests will cause them to fail. I think it would be best to skip them all, or none of them. I agree. If we can't find a quick fix to get the tests to pass, I can clean things up to make them consistent (all-failing or all-skipped) before the release. I don't have a preference which route we take. Don't know if its a problem if they fail. I don't have a problem with failures as they tell me there's something that needs attention. True. Well, these issues do need attention, so maybe they *should* fail. :) Jerry mentioned yesterday that there shouldn't be any failures for a release, which makes sense as it would only upset users. Maybe there should be a ticket for the failures then? Or an environment variable like PARROT_PORTER which makes all tests fail that are skipped because they are broken, not because the feature is not supported on the platform? 1. Do you have any ideas for how we need to decorate PMCNULL so it gets exported by the dll? PARROT_API doesn't seem to be sufficient. I think maybe its because its a variable, not a function. 2. Do you have any preference on how we fix up the Parrot::Config stuff so we can put libparrot.lib on the link command-line for win32, in the t/src/ tests? Sorry to ask so many questions, but I'm a linux geek, and utterly clueless about win32... Many thanks for helping with the t/src issues, I'm glad you jumped on the Windows train. Some things work differently on Windows and Visual C++, especially the linking and loading part, with symbol exports/imports on the very top. One great way to find out about compiled objects, libraries and executables is the COFF/PE Dumper (dumpbin), which shows details about the binary image. Another fine tool is the Dependency Walker (depends), which exactly shows you which libraries would be loaded, including their full path, what symbols they export and which they import. Please don't hesitate to ask if you have any questions. Depending on $job workload it might take some time before I can get back to you, though. Ron
Re: Current win32 linking issues: Summary
Hi Mark, Mark Glines wrote: On Mon, 20 Aug 2007 18:37:05 -0700 Mark Glines [EMAIL PROTECTED] wrote: Jerry added a workaround in r20641, declaring a local variable PMCNULL within the test code, to get it to pass. Unfortunately, this workaround causes Darwin to fail with the message ld: multiple definitions of symbol _PMCNULL. Quick followup: in r20750, I reverted this portion of r20641. The test passes again on Darwin, and is skipped again on win32. (I kept the typo fixes in compiler.t, and I didn't revert r20641's changes to the other test files.) The win32 skippage will need to be removed again, once the PMCNULL symbol is exported correctly from libparrot.dll. Not adding the skip on the other t/src tests will cause them to fail. I think it would be best to skip them all, or none of them. Failed Test Stat Wstat Total Fail Failed List of Failed --- t\src\atomic.t 4 1024 44 100.00% 1-4 t\src\basic.t 3 768 33 100.00% 1-3 t\src\exit.t 1 256 11 100.00% 1 t\src\extend.t15 384016 15 93.75% 1-15 t\src\hash.t 11 281611 11 100.00% 1-11 t\src\io.t17 435220 17 85.00% 1-15 18 20 t\src\list.t 2 512 22 100.00% 1-2 t\src\sprintf.t3 768 33 100.00% 1-3 t\src\string.t 2 512 32 66.67% 2-3 1 test and 1 subtest skipped. Failed 9/11 test scripts, 18.18% okay. 58/67 subtests failed, 13.43% okay. Don't know if its a problem if they fail. I don't have a problem with failures as they tell me there's something that needs attention. Jerry, any way I can help with this? Ron
Need JIT help please - JIT broken with optimized build on Windows (VC)
Hi, JIT is currently broken on x86 Windows using optimized Visual C++ builds. Here's the reason why. Hopefully someone more familiar with the JIT can pick this up. ... 04e45c9a 68f06fe604 push4E66FF0h 04e45c9f e8370a1c0b call_Parrot_set_returns_pc 04e45ca4 83c404 add esp,4 04e45ca7 68f86fe604 push4E66FF8h 04e45cac e8e6481c0b call_Parrot_returncc 04e45cb1 83c404 add esp,4 ... Both functions(CParrot_set_returns_pc and CParrot_returncc) take Copcode_t *cur_opcode, Parrot_Interp interp as arguments. The stack top contains a pointer to the interpreter, C4E66FF0h and C4E66FF8h are pointers to the opcodes. As you can see, the code is heavily optimized. The pointer to the interpreter is kept on the stack as it should stay the same, only the opcode is exchanged. *should* is the key word here. Visual C++ seems to optimize quite heavily, and it looks like it reuses the memory on the stack where arguments are passed for local variables. libparrot!Parrot_set_returns_pc: pushebp mov ebp,esp At this point, the stack looks like so. * stack frame pointer save (ebp+0h) * return address (ebp+4h) * cur_opcode (ebp+8h) * interp (ebp+Ch) mov eax,dword ptr [ebp+0Ch] mov ecx,dword ptr [eax] ecx now contains interp. pushesi mov esi,dword ptr [ebp+8] mov edx,dword ptr [esi+4] pushedi mov edi,dword ptr [ecx+58h] mov edx,dword ptr [edi+edx*4] mov edx,dword ptr [edx+8] mov dword ptr [eax+0E8h],esi mov edi,dword ptr [ecx+3Ch] mov dword ptr [ebp+0Ch],edx I won't decode above in detail here, but it's the following code. opcode_t * const _this = CUR_OPCODE; parrot_context_t *ctx; PMC *ccont; PMC *signature = $1; INTVAL argc; opcode_t *src_indexes, *dest_indexes; interp-current_returns = _this; ctx = CONTEXT(interp-ctx); ccont = ctx-current_cont; Notice the last mov. This means ccont reuses the memory previously used by interp. That's why returncc does not receive the correct interp. Ron
Re: Need JIT help please - JIT broken with optimized build on Windows (VC)
Leopold Toetsch wrote:
Am Mittwoch, 15. August 2007 20:05 schrieb Ron Blaschke:
Visual C++ seems to optimize quite heavily, and it looks like it reuses
the memory on the stack where arguments are passed for local variables.
mov dword ptr [ebp+0Ch],edx
All I know about intel calling convs would summarize this as a nasty compiler
bug, not an optimization. This statement is clearly overwrting a stack frame
location, which doesn't belong to the called subroutine.
I took this for granted too until today. Now that I think about it I'm
wondering... The caller copies the values in and is responsible for
free(3)ing, but does it also own the data?
What about code that assumes it owns the local variable that represents
the argument.
void f(int x)
{
/* x is mine, and mine alone */
x = ...;
}
This optimization reaches likely back to times, when the opcode engine was
designed. It's saving one interpreter push statement [1] per JIT calling one
external function, and I've always thought of it as a very cool (and valid)
thingy, when I first realized, why the interpreter is the second argument in
opcode functions ;)
I think it's a really cool idea, too. I'd like to have a way to disable
it, though, to measure its effect, and maybe to work around compilers
like VC (at least until a better solution comes around).
For the given example, VC uses the memory available for the local
variable Cccont, and the remaining data fits into the reserved stack
and the registers too, avoiding to allocate memory on the stack for the
local variables. This would probably involve a Csub esp and add
esp, which is likely more lightweight than pushing the Cinterp on the
stack, making the latter probably the better optimization in this case
still.
[1] well at least for ancient architectures like x86, which don't have
register calling convs for parts of the arguments
For Windows there's __fastcall, which would use ECX and EDX for the
first two int or smaller values, but I think it's rarely used
Great analysis of the problem BTW,
thanks,
leo
Many thanks,
Ron
Re: [Win32] There's a new compiler in town (sort of)
Hi Joshua, Joshua Hoblitt wrote: Can you submit a patch for the PLATFORMS file? Here it is. http://rt.perl.org/rt3/Ticket/Display.html?id=44527 Ron
[Win32] There's a new compiler in town (sort of)
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) Ron
Re: [Win32] There's a new compiler in town (sort of)
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
Re: [Win32] There's a new compiler in town (sort of)
Hi Andy, Andy Lester wrote: On Aug 7, 2007, at 10:25 AM, Andy Armstrong wrote: This any use? http://msdn.microsoft.com/vstudio/express/ Beautiful. Sure looks like it. There are a bunch of different editions available. Each edition contains a different compiler with a different feature set! This is really annoying, actually. Here's a feature overview: http://msdn2.microsoft.com/en-us/library/hs24szh9(VS.90).aspx If you need help with the setup let me know. I'm running Visual C++ 2005 Express, I guess there's little difference. Ron
ctags - confused
Jerry noticed that some symbols are missing with ctags, for example
Cmem_sys_free.
This happens for me too with ctags 5.6 on Win32, but other versions or
platforms could suffer from the same problem.
$ ctags --version
Exuberant Ctags 5.6, Copyright (C) 1996-2004 Darren Hiebert
Compiled: Jul 30 2006, 16:12:20
Addresses: [EMAIL PROTECTED], http://ctags.sourceforge.net
Optional compiled features: +win32, +regex, +internal-sort
The issue is that ctags gets confused by definitions like these.
... foo(MACRO(...))
ctags indexes CMACRO instead of Cfoo.
Here's an example:
// test.c
void
f1(void *ptr)
{}
void
f2(NULLOK(void *ptr))
{}
void
f3(NULLOK(void *ptr1), NOTNULL(void *ptr2))
{}
// end
$ ctags -f- test.c
NOTNULL test.c /^f3(NULLOK(void *ptr1), NOTNULL(void *ptr2))$/; f
NULLOK test.c /^f2(NULLOK(void *ptr))$/; f
f1 test.c /^f1(void *ptr)$/; f
My current workaround for this is to grep tags directly for the symbol,
like so:
$ grep mem_sys_free tags
NULLOK .\src\gc\memory.c /^mem_sys_free(NULLOK(void
*from))$/; f
Ron
Re: [perl #44213] docs/faq.pod - fix Lfoo|http://... pod abuse
Will Coleda via RT wrote: Seems like a pretty straightforward patch, but isn't the L syntax used currently proper? Is there a particular pod reader we're trying to make happy? I tripped over this recently too. From perlpod: * Lscheme:... Links to an absolute URL. For example, Lhttp://www.perl.org/. But note that there is no corresponding Ltext|scheme:... syntax, for various reasons.
Re: Odd Memory Corruption
chromatic wrote: In theory, this patch should apply and run cleanly. It doesn't. Thus, something somewhere pokes into memory it shouldn't. Any ideas? Alternately, any comments on this analysis? I think adding memory checks is a brilliant idea, especially because memory is sometimes recycled with GC, thus malloc/free checks being less useful. The bug where a PMC was still used while already being put on the free list, and aggravated by the fact that the free list pointer is put at the same address as the data comes into mind. I really like what Microsoft has done with their memory guards. The Structure of a Page Heap Block http://msdn2.microsoft.com/en-us/library/ms220938(vs.80).aspx It would be great if someone could have a look at patches 43432 and 43529. They might be memory relevant too. Ron
Optimized Build Failures on Win32
Parrot fails with an optimized build on Win32, Visual C++. Here are a few random observations, not sure if they are pointing to the problem or are merely side effects. It seems like the failures only affect JIT execution. I'm only seeing this with some shootout tests during Cnmake test, as those are setting it. Always using the JIT execution (CPARROT_ARGS=-j) makes a whole lot of other tests fail too. $ nmake test ... Failed Test Stat Wstat Total Fail Failed List of Failed --- t/compilers/imcc/imcpasm/optc.t 40 1024043 40 93.02% 1-7 11-43 t/compilers/imcc/reg/alloc.t 6 1536116 54.55% 1-2 4-7 t/compilers/imcc/reg/spill.t 6 1536 96 66.67% 3 5-9 t/compilers/imcc/syn/bsr.t 2 512122 16.67% 8-9 t/compilers/imcc/syn/const.t 6 1536346 17.65% 1-3 6-7 31 t/compilers/imcc/syn/file.t 5 1280135 38.46% 4 6 8-9 13 t/compilers/imcc/syn/labels.t1 256 61 16.67% 6 ... lots of other failures snipped (1 subtest UNEXPECTEDLY SUCCEEDED), 21 tests and 601 subtests skipped. Failed 112/307 test scripts, 63.52% okay. 1001/6979 subtests failed, 85.66% okay. A short program that shows one failure is this. .sub main :main .local pmc stdout stdout = getstdout print before say\n stdout.say(Hello World!) print after say\n .end $ parrot test.pir before say Hello World! after say $ parrot -j test.pir before say Hello World! Parrot segfaults shortly after executing Parrot_callmethodcc_p_sc in this example, which is Fsrc/ops/object.ops Cop callmethodcc(invar PMC, in STR), that is the Csay method call. Now, callmethodcc translates into Fsrc\ops\core_ops.c and compiling just this source file without optimization (I know, compiling with different flags is a thing one should avoid) makes the problem go away, or at least hide really well. $ parrot -j test.pir before say Hello World! after say $ nmake test ... Failed Test Stat Wstat Total Fail Failed List of Failed --- t/distro/file_metadata.t3 768 43 75.00% 1-3 t/doc/pod.t 1 256 11 100.00% 1 (1 subtest UNEXPECTEDLY SUCCEEDED), 21 tests and 601 subtests skipped. Failed 2/307 test scripts, 99.35% okay. 4/6979 subtests failed, 99.94% okay. Something similar can be seen with MinGW. Parrot compiled with C-Os. $ runtests t\examples\shootout.t ... Test Summary Report --- t\examples\shootout.t (Wstat: 2048 Tests: 20 Failed: 8) Failed tests: 3, 6-10, 17-18 Tests skipped: 13 Non-zero exit status: 8 Files=1, Tests=20, 19 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Fsrc\ops\core_ops.c without C-Os. $ runtests t\examples\shootout.t ... t\examples\shootout..ok All tests successful. Test Summary Report --- t\examples\shootout.t (Wstat: 0 Tests: 20 Failed: 0) Tests skipped: 13 Files=1, Tests=20, 16 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Ron
Re: [perl #43187] [BUG] MinGW (build) busted?
chromatic wrote: On Sunday 24 June 2007 04:48:19 Ron Blaschke wrote: Thanks for picking this up. The problem was caused by C#pragma once which MinGW GCC 3.4.2 seems to choke on. There was some discussion on the list (Removing #pragma) too. It looks like r18945 should have fixed the problem; can you confirm? Yep, MinGW gcc doesn't segfault with r18945. Thanks, Ron
Re: [perl #41569] t/distro/file_metadata.t fails on win32
Paul Cochrane wrote: I couldn't get your patch to apply cleanly and so hacked it in by hand. I'm attaching a new patch to this email (which is quite possibly identical to yours) so that you can give it a quick test. If all is happy, then I'll commit the change and close the ticket. I locally applied it to r19058 and works fine. $ prove t/distro/file_metadata.t t/distro/file_metadata# Collecting svn:mime-type attributes... # Collecting svn:keywords attributes... t/distro/file_metadataok 2/4# Collecting svn:eol-style attributes... # Collecting svn:eol-style attributes... t/distro/file_metadataok All tests successful. Files=1, Tests=4, 30 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Thanks heaps for your help! Many thanks for cleaning this up! Ron
Re: [perl #39426] [BUG] Can't build with cygwin.
Paul Cochrane wrote: Paul Cochrane wrote: Without the manual setting of PATH before building? With the manual PATH setting. There are several tickets for cygwin not building in RT; are they all related? Is there something like a hints file where the information about the PATH can be set so that cygwin builds out of the box? Cygwin is building for me without the PATH setting as of r19022. Are other people seeing this behaviour as well? If so, can we get rid of the (three or four) parrot isn't building on cygwin tickets in RT? Doesn't work for me either. Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fingers ./miniparrot.exe config_lib.pasm runtime/parrot/include/config.fpmc make: *** [runtime/parrot/include/config.fpmc] Error 53 Do you have an installed Parrot? Try C which -a libparrot.dll . Ron
Re: [perl #41569] t/distro/file_metadata.t fails on win32
Paul Cochrane wrote:
But if we convert what MANIFEST provides (i.e. Unix directory
separators) into whatever the current platform needs (i.e. what
canonpath() does) then it should agree with whatever svn spits out.
Or am I missing something?
No, that's exactly what I think needs to be done. In the patch
canonpath is used with the result of the svn execution only. That's not
enough. @manifest_files would need to be changed too, otherwise it
contains the file names with forward slashes from MANIFEST. There's
also a regex $lf_files_regexp that seems to filter files, and the part
that uses it would need to be aware of the changed separator, too.
Essentially my patch is just a less fragile version of the patch you
submitted to get this test to work on Windows. (at least, I don't
think I'm changing the functionality that much).
I simple changed the backward slashes to forward slashes, thus forward
slashes everywhere.
Which was what *I* intended to do with my patch, but after staring at
it long enough, I realised that's not what *it* was saying! :-)
Ooops.
Oh, I see. Sorry I didn't get this right.
I'd like to avoid converting the entire MANIFEST from Unix to Windows
directory separators just so that we can have the hash we're
generating in t/distro/file_metadata.t has consistent keys;
converting to explicitly Unix should be enough (and converting the
whole MANIFEST would make the test even slower than it already is).
Even more so considering that there is a ticket in RT trying to get
rid of MANIFEST. Anyway, attached is another patch, which hopefully
does the right thing now. If everyone's happy with the patch, I'll
apply and commit it to trunk.
Ron, would it be ok if you could check the patch to see if it works on
Win32? Thanks heaps in advance.
There's one piece missing: You'd need to splitdir/catdir $directories
too, otherwise it's left as-is.
I have attached a modified patch, and prove-ed it works with r18945 on
Win32.
Ron
Index: t/distro/file_metadata.t
===
--- t/distro/file_metadata.t(revision 18945)
+++ t/distro/file_metadata.t(working copy)
@@ -8,7 +8,8 @@
use Test::More;
use File::Basename qw( fileparse );
-use File::Spec::Functions qw( catfile );
+use File::Spec::Functions qw( catfile splitpath splitdir );
+use File::Spec::Unix;
use Parrot::Config;
use Parrot::Revision;
use ExtUtils::Manifest qw( maniread );
@@ -270,13 +271,22 @@
# This RE may be a little wonky.
if ( $result =~ m{(.*) - (.*)} ) {
-my ( $file, $attribute ) = ( $1, $2 );
+my ( $full_path, $attribute ) = ( $1, $2 );
-# file names are reported with backslashes on Windows,
-# but we want forward slashes
-$file =~ s!\\!/!g if $^O eq 'MSWin32';
+# split the path
+my ( $volume, $directories, $file ) =
+splitpath $full_path;
+my @directories = splitdir $directories;
-$results{$file} = $attribute;
+# put it back together as a unix path (to match MANIFEST)
+$full_path = File::Spec::Unix-catpath(
+$volume,
+File::Spec::Unix-catdir(@directories),
+$file
+);
+
+# store the attribute into the results hash
+$results{$full_path} = $attribute;
}
}
Re: [perl #41569] t/distro/file_metadata.t fails on win32
jerry gay wrote:
On 6/11/07, Paul Cochrane [EMAIL PROTECTED] wrote:
On 09/03/07, chromatic [EMAIL PROTECTED] wrote:
On Friday 09 March 2007 05:00, Ron Blaschke wrote:
Attached patch replaces the backslashes with slashes on Windows.
Would using File::Spec be less fragile?
I've attached a patch which uses File::Spec instead of replacing one
set of slashes with another. Comments welcome! :-)
good idea.
instead of breaking up the path and reconstructing it separately
(since the individual components of the path aren't used anywhere
else,) how about using 'canonpath' to clean up the path in one step.
something like:
if ( $result =~ m{(.*) - (.*)} ) {
my $file = canonpath $1;
my $attribute = $2;
# and add to the results hash
$results{$file} = $attribute;
}
I may be missing something here, but I think the problem was that the
file name sets in MANIFEST and those reported by svn must match up, but
didn't because of the file separator. MANIFEST uses forward slashes,
File::Spec those of the current platform, which probably brings you back
to square one.
If you decide for File::Spec you should also canonicalize
@manifest_files, I guess.
Ron
Re: [perl #41569] t/distro/file_metadata.t fails on win32
Paul Cochrane wrote:
On 11/06/07, Ron Blaschke [EMAIL PROTECTED] wrote:
jerry gay wrote:
On 6/11/07, Paul Cochrane [EMAIL PROTECTED] wrote:
On 09/03/07, chromatic [EMAIL PROTECTED] wrote:
On Friday 09 March 2007 05:00, Ron Blaschke wrote:
Attached patch replaces the backslashes with slashes on Windows.
Would using File::Spec be less fragile?
I've attached a patch which uses File::Spec instead of replacing one
set of slashes with another. Comments welcome! :-)
good idea.
instead of breaking up the path and reconstructing it separately
(since the individual components of the path aren't used anywhere
else,) how about using 'canonpath' to clean up the path in one step.
something like:
if ( $result =~ m{(.*) - (.*)} ) {
my $file = canonpath $1;
my $attribute = $2;
# and add to the results hash
$results{$file} = $attribute;
}
I may be missing something here, but I think the problem was that the
file name sets in MANIFEST and those reported by svn must match up, but
didn't because of the file separator. MANIFEST uses forward slashes,
File::Spec those of the current platform, which probably brings you back
to square one.
But if we convert what MANIFEST provides (i.e. Unix directory
separators) into whatever the current platform needs (i.e. what
canonpath() does) then it should agree with whatever svn spits out.
Or am I missing something?
No, that's exactly what I think needs to be done. In the patch
canonpath is used with the result of the svn execution only. That's not
enough. @manifest_files would need to be changed too, otherwise it
contains the file names with forward slashes from MANIFEST. There's
also a regex $lf_files_regexp that seems to filter files, and the part
that uses it would need to be aware of the changed separator, too.
Essentially my patch is just a less fragile version of the patch you
submitted to get this test to work on Windows. (at least, I don't
think I'm changing the functionality that much).
I simple changed the backward slashes to forward slashes, thus forward
slashes everywhere. But canonpath does on Win32:
$ perl -MFile::Spec::Functions=canonpath
-e print canonpath 'some\file.t'
some\file.t
$ perl -MFile::Spec::Functions=canonpath
-e print canonpath 'some/file.t'
some\file.t
Here are the test results with the patch applied on Win32:
$ prove t\distro\file_metadata.t
many lines snipped...
# svn ps svn:eol-style 'LF' examples/shootout/takfp.pir.output;
# svn ps svn:eol-style 'LF' t/compilers/pge/p5regex/re_tests;
# svn ps svn:eol-style 'LF' t/library/perlhist.txt;
# svn ps svn:eol-style 'LF' t/op/sprintf_tests;
# '
# expected: ''
# Looks like you failed 4 tests of 4.
t\distro\file_metadatadubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 1-4
Failed 4/4 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\distro\file_metadata.t4 1024 44 100.00% 1-4
Failed 1/1 test scripts, 0.00% okay. 4/4 subtests failed, 0.00% okay.
Ron
Re: [perl #39426] [BUG] Can't build with cygwin.
Paul Cochrane wrote: Without the manual setting of PATH before building? With the manual PATH setting. There are several tickets for cygwin not building in RT; are they all related? Is there something like a hints file where the information about the PATH can be set so that cygwin builds out of the box? Some time ago I proposed a patch to change some of the library stuff for Windows platforms. Part of this was to put all binaries into a single directory, often the preferred location and way to handle dependencies on Windows. Ron
Re: odbc.lib still linked?
Klaas-Jan Stol wrote: recently a patch was supplied and applied for odbc32.lib being linked into parrot. This file is not needed for Parrot, but it seems it is still linked (at least, here on my machine, winxp). \parrot\library\PAST-pm.pbc C:\Perl\bin\perl.exe -e chdir shift @ARGV;system 'nmake', '-nologo', @A RGV; exit $? 8; compilers\json link -out:.\pbc_merge.exe src\pbc_merge.obj src\parrot_config.obj lib parrot.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.libcomdlg32 .lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.libws2_3 2.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib -nologo -nodefaultlib -debug -machine:x86 -debug Check the second last line... Should it be there? From your command line you seem to refer to Visual C++, but patch 42950 looks like it's intended for MinGW. For Visual C++ the libraries are pulled in from your Perl (see perl -V:libs). Ron
Limiting Exported Symbols on GCC
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))). If you're trying this, prepare to kill io_4 quickly while t/src/io.t is running, as it would print 16777215: for a very, very long time (there's already a ticket for this). The following is r18140 on Ubuntu, using GCC 4.1.2. prove t/src/io.t ... t/src/iook 15/20# 'cc -L/usr/local/lib -Wl,-E t/src/io_16.o src/parrot_config.o -o t/src/io_16 -Wl,-rpath=/home/rb lasch/src/parrot/trunk/blib/lib -Lblib/lib -lparrot -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm -ldl -lm - lpthread -lcrypt -lrt -lgmp -lreadline -lncurses' failed with exit code 1 # Failed to build 't/src/io_16': t/src/io_16.o: In function `the_test': # t/src/io_16.c:31: undefined reference to `PIO_make_offset' # collect2: ld returned 1 exit status # Failed test (t/src/io.t at line 506) t/src/ioNOK 16# 'cc -L/usr/local/lib -Wl,-E t/src/io_17.o src/parrot_config.o -o t/src/io_17 -Wl,-rpath=/home/rbla sch/src/parrot/trunk/blib/lib -Lblib/lib -lparrot -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm -ldl -lm -lp thread -lcrypt -lrt -lgmp -lreadline -lncurses' failed with exit code 1 # Failed to build 't/src/io_17': t/src/io_17.o: In function `the_test': # t/src/io_17.c:46: undefined reference to `PIO_make_offset' # collect2: ld returned 1 exit status # Failed test (t/src/io.t at line 538) t/src/ioNOK 17# 'cc -L/usr/local/lib -Wl,-E t/src/io_18.o src/parrot_config.o -o t/src/io_18 -Wl,-rpath=/home/rbla sch/src/parrot/trunk/blib/lib -Lblib/lib -lparrot -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm -ldl -lm -lp thread -lcrypt -lrt -lgmp -lreadline -lncurses' failed with exit code 1 # Failed to build 't/src/io_18': t/src/io_18.o: In function `the_test': # t/src/io_18.c:33: undefined reference to `PIO_STDOUT' # collect2: ld returned 1 exit status # Failed test (t/src/io.t at line 593) t/src/ioNOK 18# 'cc -L/usr/local/lib -Wl,-E t/src/io_19.o src/parrot_config.o -o t/src/io_19 -Wl,-rpath=/home/rbla sch/src/parrot/trunk/blib/lib -Lblib/lib -lparrot -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm -ldl -lm -lp thread -lcrypt -lrt -lgmp -lreadline -lncurses' failed with exit code 1 # Failed to build 't/src/io_19': t/src/io_19.o: In function `the_test': # t/src/io_19.c:29: undefined reference to `pio_stdio_layer' # collect2: ld returned 1 exit status # Failed test (t/src/io.t at line 628) t/src/iook 20/20# Looks like you failed 9 tests of 20. t/src/iodubious Test returned status 9 (wstat 2304, 0x900) DIED. FAILED tests 2-4, 6-7, 16-19 Failed 9/20 tests, 55.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/src/io.t 9 2304209 45.00% 2-4 6-7 16-19 Failed 1/1 test scripts, 0.00% okay. 9/20 subtests failed, 55.00% okay. Ron
Re: [Proposed PATCH] Change libparrot Names and Locations
jerry gay wrote:
On 4/12/07, Ron Blaschke [EMAIL PROTECTED] wrote:
Attached is a proposed patch to change the libparrot names and locations
for Windows. I have tested the changes for core Parrot on Win32
Visual C++, Cygwin GCC, MinGW GCC and Ubuntu GCC.
snip reasoning
this looks fabulous. thank you for providing your strategy, and the
detailed references. however, there are some minor problems.
Thanks! Any thoughts are greatly appreciated.
Index: tools/build/ln_rel_sf.pl
===
+
+sub usage {
+my ($arg) = @_;
+print Missing argument: $arg\n;
+print usage: ln_rel_sf target source\n;
+print target existing destination of link\n;
+print source link source to be created\n;
+
+exit 1;
+}
+
+my ($target, $source) = @ARGV;
+
+if (!defined $target) {
+usage('target');
+}
+
+if (!defined $source) {
+usage('source');
+}
+
+
the above logic misses the case where there are too many arguments.
i notice you haven't provided tests, either--that's not a reason for
rejection, just a note that we need to enter a CAGE ticket to write
some after applying this.
True, I should really improve this.
-# If we are building shared, need to include dynamic
libparrot.lib, otherwise
+
+# If we are building shared, need to include dynamic
parrot.lib, otherwise
# the static libparrot.lib.
this code section and this comment in particular interests me. it
shows me that the name of the dynamic lib is different than the static
lib. this reminds me of some time ago when static/dynamic builds of
parrot were overhauled, allowing either type to be built. i always
wondered if we could build *both*. do you think this patch gets us
closer to building both static and dynamic parrot in the same build?
The patch doesn't change that. Previously, the static library was built
at Fblib/lib/libparrot.lib, the import library at Flibparrot.lib (no
blib/lib here!). Now it's Fblib/lib/libparrot.lib and
Fblib/lib/parrot.lib, respectively.
11.04.2007 20:5819.226.530 libparrot.lib
11.04.2007 19:43 2.685.438 parrot.lib
Both libraries get built during make, but I'm not sure if libparrot is
usable. Are we talking about a statically linked parrot.exe? I can
look into this if you like.
Ron
Re: Limiting Exported Symbols on GCC
Nicholas Clark wrote: 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. I thought the same, but I've never seen clear documentation as to how to do it. Just to elaborate a bit further on what I did: There's a macro called PARROT_API (see Finclude/parrot/config.h) which is used to tag all symbols to be exported. On Win32 it expands to C__declspec(dllexport) to export the symbol (see Fconfig/init/hints/mswin32.pm), for others to nothing. For my test I defined it as C__attribute__ ((visibility (default))). Ron
Re: Limiting Exported Symbols on GCC
Nicholas Clark wrote: On the other hand, we've managed very well in Perl 5 with the flag data in embed.fnc and generating the annotated headers programmatically. Interesting. I quite like this. Nicholas Clark Ron
Re: Current State of Building Parrot on Cygwin
Eric Hanchrow wrote: Ron == Ron Blaschke [EMAIL PROTECTED] writes: Ron If you see this error ... Ron the file has Windows line endings Dare I suggest that parrot not be so fussy about line endings? I second that. ;) Actually, both things are supposed only as workarounds until fixed, to get Parrot fly on Cygwin again, if only with a broken wing. Ron
Re: Current State of Building Parrot on Cygwin
Steve Peters wrote: On Sun, Apr 01, 2007 at 04:15:24PM +0200, Ron Blaschke wrote: As recently discussed it is currently necessary to include the absolute path to Fblib/lib in the environment variable PATH. This should be done before trying to built parrot, otherwise one gets a broken Fruntime/parrot/include/config.fpmc and Fsrc/parrot_config.c. One needs a make clean or remove *both* files before trying again. Make sure to export the PATH changes, not just only set them, and use the absolute path, not the relative (otherwise building some libs will fail later on.) I was beginning to think that was the problem with Cygwin. With Perl 5, the build process keeps all the Perl library in the same directory with executable. This seems to make things much easier for Windows, since DLL's need to be on the PATH on Windows (including Cygwin). Once I reboot into Windows, I'll see what I can do to help make this more automatic. See my Link'n'Load on Windows post for more thoughts. If you're interested, here's how Windows loads DLLs. Dynamic-Link Library Search Order http://msdn2.microsoft.com/en-us/library/ms682586.aspx Ron
Re: Current State of Building Parrot on Cygwin
chromatic wrote: On Sunday 01 April 2007 07:15, Ron Blaschke wrote: As recently discussed it is currently necessary to include the absolute path to Fblib/lib in the environment variable PATH. This should be done before trying to built parrot, otherwise one gets a broken Fruntime/parrot/include/config.fpmc and Fsrc/parrot_config.c. One needs a make clean or remove *both* files before trying again. Make sure to export the PATH changes, not just only set them, and use the absolute path, not the relative (otherwise building some libs will fail later on.) Is it possible to pass flags to the linker that hint at a path to libparrot.so? That's how the Linux version works anyway. And that's quite convenient. Haven't seen anything similar on Windows, though. Ron
Link'n'Load on Windows
Hi, I currently looking at some issues on Windows. 1) Linking There are a few symbols not exported which cause link errors in tests. I'll provide a patch to export them. 2) Loading On Windows it's usually best to put the applications and libraries in the same directory, but libparrot is mostly built in blib/lib. There's a hack for MSWin32, though: Makefile #CONDITIONED_LINE(win32):LIBPARROT_SHARED = @libparrot_shared@ #INVERSE_CONDITIONED_LINE(win32):LIBPARROT_SHARED = @blib_dir@/@libparrot_shared@ I'd like to change libparrot_shared and libparrot_static to include the full path, i.e. include build_dir, and simplify above in the Makefile. Actually, I got confused by the difference of libparrot_shared (Configure) and LIBPARROT_SHARED (Makefile). For Windows (native and Cygwin) I'd like to build the libraries near Fparrot, for everyone else it stays in blib/lib. Would these changes be ok? Ron
Current State of Building Parrot on Cygwin
Hi, As recently discussed it is currently necessary to include the absolute path to Fblib/lib in the environment variable PATH. This should be done before trying to built parrot, otherwise one gets a broken Fruntime/parrot/include/config.fpmc and Fsrc/parrot_config.c. One needs a make clean or remove *both* files before trying again. Make sure to export the PATH changes, not just only set them, and use the absolute path, not the relative (otherwise building some libs will fail later on.) If you see this error make runtime/parrot/library/Crow.pbc ./parrot.exe -o runtime/parrot/library/Crow.pbc runtime/parrot/library/Crow.pir error:imcc:syntax error, unexpected $end in file 'runtime/parrot/library/Crow.pir' line 146 make: *** [runtime/parrot/library/Crow.pbc] Error 1 the file has Windows line endings, usually because checked out with Windows' Subversion. Get the Cygwin version and a clean checkout. Ron
Re: [perl #37997] r10604 build failure on Cygwin
Ron Blaschke wrote: Paul Cochrane wrote: I don't know if it's of much help, but I too am getting the Cygwin build barfing when miniparrot goes to build runtime/parrot/include/config.fpmc. I think that's actually a good sign. Try adding the absolute path to Fblib/lib and try again. If this is working please see my previous post in this thread about library loading. Sorry, I guess there was some mental PATH overloading going on. Try adding the absolute path to Fblib/lib to PATH. export PATH=/path/to/parrot/blib/lib:$PATH And then make. Ron
Re: [perl #37997] r10604 build failure on Cygwin
Paul Cochrane wrote: Sorry, I guess there was some mental PATH overloading going on. Try adding the absolute path to Fblib/lib to PATH. export PATH=/path/to/parrot/blib/lib:$PATH And then make. I tried this (although, I appended the blib path to PATH, not sure if that makes a difference) and parrot builds, but it fails a whole heap of tests, and gets to t/src/io.t and eventually runs out of memory. Attached is the 'make test' output of parrot from r17829. The first libparrot.dll in PATH is used, so unless you've got an installed Parrot it shouldn't matter. I'm getting the same test results. That's the current state of Parrot on Cygwin. See http://smoke.parrotcode/org/smoke section i386-cygwin-gcc. Actually, you can't smoke parrot without user intervention. Ft/src/io.t seems to consume an infinite amount of memory, or at least tries to. Haven't look into the details yet, but I think one test creates an executable io_4.exe which doesn't stop printing results, which cause the out of memory situation. I usually just kill io_4.exe. (I know, that's a bad thing, but that's what bad people do.) Not 100% on this, but I think one or two of the stm tests hang, too. Ron
Re: [perl #37997] r10604 build failure on Cygwin
chromatic wrote: On Friday 30 March 2007 07:35, Ron Blaschke wrote: Not 100% on this, but I think one or two of the stm tests hang, too. t/pmc/stmlog.t, test 2? No, I think this one's fine. More like t/stm/queue.t test 2 and t/stm/runtime.t test 4. Actually, t/stm/queue.t sometimes seems to work (see cygwin smokes). Ron
Re: [perl #37997] r10604 build failure on Cygwin
Paul Cochrane wrote: I don't know if it's of much help, but I too am getting the Cygwin build barfing when miniparrot goes to build runtime/parrot/include/config.fpmc. I think that's actually a good sign. Try adding the absolute path to Fblib/lib and try again. If this is working please see my previous post in this thread about library loading. Paul Ron
Re: [perl #37997] r10604 build failure on Cygwin
Joshua Gatcomb wrote: On 3/28/07, Ron Blaschke [EMAIL PROTECTED] wrote: Joshua Gatcomb wrote: If you could hang out on #parrot (irc.perl.org) when myself, Jonathan, particle, etc are around - it would go a long way towards getting a reproduceable test case that can be correctly articulated as to the nature of the problem. A few years ago I used to build parrot on cygwin daily and opened several tickets that years later I was asked if were still applicable. I am not interested in repeating the past. Yes, that's bad. Despite having GMP and bc installed Configure.PL doesn't find them. I am interested in knowing why this is but I doubt it has anything to do with the problem. GMP I don't know, but bc is explicitly disabled on all but selected platforms. I have enabled it on my box a few days ago and will submit a patch to add cygwin if it causes no problems. Also, the message should say skipped on this platform or something similar, instead of no. Here is the tail end of my make output: Don't know if this is any help, but I'm seeing the exact output if I remove C-lparrot while linking miniparrot. Ron
[perl #37997] r10604 build failure on Cygwin
Not sure about the details of this issue, but r17772 seems to build fine on Cygwin. Here's the output of make test on my box. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/codingstd/c_code_coda.t 1 256 21 50.00% 1 t/codingstd/c_indent.t 2 512 22 100.00% 1-2 t/codingstd/cppcomments.t ?? ?? % ?? t/codingstd/tabs.t 1 256 11 100.00% 1 t/codingstd/trailing_space.t1 256 11 100.00% 1 t/op/trans.t1 256211 4.76% 13 t/pmc/iterator.t2 512432 4.65% 42-43 t/pmc/os.t 2 512152 13.33% 6 9 t/src/compiler.t1 256 61 16.67% 1 t/src/extend.t 12 307216 12 75.00% 1-12 t/src/intlist.t 4 1024 44 100.00% 1-4 t/src/io.t 9 2304209 45.00% 2-4 6-7 16-19 t/stm/runtime.t 2 512 52 40.00% 2 4 8 tests and 577 subtests skipped. Failed 13/270 test scripts, 95.19% okay. 39/6675 subtests failed, 99.42% okay. Ron
Re: [perl #41569] t/distro/file_metadata.t fails on win32
Will Coleda wrote:
I expect the first two to pass, but metadata is often often overlooked
on commits.
The last one is a new test, not everything has been updated yet. (And
I'm not sure it *can* be without breaking windows).
Should be passing the second test again as of r17398.
Thanks for your help. I have attached the patch to make the test work
on Windows. The problem is that Subversion reports file names with
backslashes, but the code expects forward slashes. For example:
svn propget svn:eol-style t/distro/*
t\distro\file_metadata.t - native
t\distro\manifest.t - native
t\distro\manifest_skip.t - native
t\distro\test_file_coverage.t - native
Attached patch replaces the backslashes with slashes on Windows.
Here's what I get for r17405.
prove t\distro\file_metadata.t
t\distro\file_metadata# Collecting svn:mime-type attributes...
# Collecting svn:keywords attributes...
t\distro\file_metadataok 1/3# Collecting svn:eol-style attributes...
t\distro\file_metadataok
All tests successful.
Files=1, Tests=3, 12 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Ron
Index: t/distro/file_metadata.t
===
--- t/distro/file_metadata.t(revision 17405)
+++ t/distro/file_metadata.t(working copy)
@@ -172,9 +172,6 @@
=cut
BEGIN {
-plan skip_all = 'RT #41569 - this test is broken on win32'
-if $^O eq 'MSWin32';
-
unless ( $Parrot::Revision::current or `svk ls .` ) {
plan skip_all = 'not a working copy';
}
@@ -231,7 +228,12 @@
# This RE may be a little wonky.
if ( $result =~ m{(.*) - (.*)} ) {
-$results{$1} = $2;
+my ($file, $attribute) = ($1, $2);
+# file names are reported with backslashes on Windows,
+# but we want forward slashes
+$file =~ s!\\!/!g if $^O eq 'MSWin32';
+
+$results{$file} = $attribute;
}
}
Re: [perl #41569] t/distro/file_metadata.t fails on win32
chromatic wrote: On Friday 09 March 2007 05:00, Ron Blaschke wrote: Attached patch replaces the backslashes with slashes on Windows. Would using File::Spec be less fragile? The problem basically boils down to matching a list of MANIFEST (UNIX?) files with the (native file name, attribute) output of svn. Not sure how well specified the svn propget output is to begin with. One way to make things more robust is to take the file names returned by svn, make sure they are relative, parse them with File::Spec and put them together with File::Spec::Unix. That is, use the MANIFEST format as canonical paths. Another solution would be to pull every file name, from the initial list and the Subversion output, through File::Spec-canonpath. Ron
[perl #41569] t/distro/file_metadata.t fails on win32
Hi, Could someone please tell me the expected result of t/distro/file_metadata.pl at revision 17389? After looking into bug #41569 I'm getting the following on Windows (XP, SP2, VC++ 8.0, Subversion). prove t/distro/file_metadata.t t/distro/file_metadata# Collecting svn:mime-type attributes... t/distro/file_metadataok 1/3# Collecting svn:keywords attributes... t/distro/file_metadataNOK 2# Failed test (t/distro/file_metadata.t at l # got: ' # languages/APL/MAINTAINER (Author Date Id Revision) # languages/BASIC/MAINTAINER (Author Date Id Revision) # languages/HQ9plus/MAINTAINER (Author Date Id Revision) # languages/PIR/MAINTAINER (Author Date Id Revision) # languages/WMLScript/MAINTAINER (Author Date Id Revision) # languages/Zcode/MAINTAINER (Author Date Id Revision) # languages/abc/MAINTAINER (Author Date Id Revision) # languages/amber/MAINTAINER (Author Date Id Revision) # languages/befunge/MAINTAINER (Author Date Id Revision) # languages/bf/MAINTAINER (Author Date Id Revision) # languages/c99/MAINTAINER (Author Date Id Revision) # languages/cardinal/MAINTAINER (Author Date Id Revision) # languages/dotnet/MAINTAINER (Author Date Id Revision) # languages/ecmascript/MAINTAINER (Author Date Id Revision) # languages/lazy-k/MAINTAINER (Author Date Id Revision) # languages/lisp/MAINTAINER (Author Date Id Revision) # languages/lua/MAINTAINER (Author Date Id Revision) # languages/ook/MAINTAINER (Author Date Id Revision) # languages/parakeet/MAINTAINER (Author Date Id Revision) # languages/parrot_compiler/MAINTAINER (Author Date Id Revision) # languages/perl6/MAINTAINER (Author Date Id Revision) # languages/pheme/MAINTAINER (Author Date Id Revision) # languages/punie/MAINTAINER (Author Date Id Revision) # languages/pynie/MAINTAINER (Author Date Id Revision) # languages/scheme/MAINTAINER (Author Date Id Revision) # languages/tcl/runtime/builtin/auto_execok.pir (Author Date Id Revision) # languages/tcl/runtime/builtin/auto_load.pir (Author Date Id Revision) # languages/tcl/runtime/builtin/exec.pir (Author Date Id Revision) # languages/tcl/runtime/builtin/fconfigure.pir (Author Date Id Revision) # languages/tcl/runtime/builtin/glob.pir (Author Date Id Revision) # languages/tcl/runtime/builtin/interp.pir (Author Date Id Revision) # languages/tcl/runtime/builtin/trace.pir (Author Date Id Revision) # languages/tcl/runtime/builtin/update.pir (Author Date Id Revision) # languages/unlambda/MAINTAINER (Author Date Id Revision) # languages/urm/MAINTAINER (Author Date Id Revision) # src/pmc/metaattribute.pmc (Author Date Id Revision) # src/pmc/metaclass.pmc (Author Date Id Revision) # src/pmc/object.pmc (Author Date Id Revision) # ' # expected: '' # Collecting svn:eol-style attributes... t/distro/file_metadataNOK 3# Failed test (t/distro/file_metadata.t at l # got: ' # examples/shootout/ack.pir.output (native) # examples/shootout/binarytrees.pir.output (native) # examples/shootout/fannkuch.pir.output (native) # examples/shootout/fasta.pir.output (native) # examples/shootout/knucleotide.pir.input (native) # examples/shootout/knucleotide.pir.output (native) # examples/shootout/nbody.pir.output (native) # examples/shootout/nsieve-bits-2.pir.output (native) # examples/shootout/nsieve-bits.pir.output (native) # examples/shootout/nsieve.pir.output (native) # examples/shootout/partialsums-2.pir.output (native) # examples/shootout/partialsums.pir.output (native) # examples/shootout/pidigits.pir.output (native) # examples/shootout/recursive-2.pir.output (native) # examples/shootout/recursive.pir.output (native) # examples/shootout/regexdna.pir.input (native) # examples/shootout/regexdna.pir.output (native) # examples/shootout/revcomp.pir.input (native) # examples/shootout/revcomp.pir.output (native) # examples/shootout/spectralnorm.pir.output (native) # examples/shootout/sumcol.pir.input (native) # examples/shootout/sumcol.pir.output (native) # examples/shootout/takfp.pir.output (native) # languages/APL/MAINTAINER (native) # languages/BASIC/MAINTAINER (native) # languages/HQ9plus/MAINTAINER (native) # languages/PIR/MAINTAINER (native) # languages/WMLScript/MAINTAINER (native) # languages/Zcode/MAINTAINER (native) # languages/abc/MAINTAINER (native) # languages/amber/MAINTAINER (native) # languages/befunge/MAINTAINER (native) # languages/bf/MAINTAINER (native) # languages/c99/MAINTAINER (native) # languages/cardinal/MAINTAINER (native) # languages/dotnet/MAINTAINER (native) # languages/ecmascript/MAINTAINER (native) # languages/lazy-k/MAINTAINER (native) # languages/lisp/MAINTAINER (native) # languages/lua/MAINTAINER (native) # languages/lua/lib/alarm.pir (native) # languages/lua/t/alarm.t (native) # languages/lua/t/package.t (native) # languages/lua/t/regex.t (native) # languages/lua/t/rx_captures (native) # languages/lua/t/rx_charclass (native) # languages/lua/t/rx_metachars (native) # languages/ook/MAINTAINER (native) # languages/parakeet/MAINTAINER (native) #
Re: Building Parrot::Embed on Windows XP / Visual C++
chromatic wrote: On Saturday 23 December 2006 11:32, Ron Blaschke wrote: It would be great if you could make the change right away. I thought it was just too small of a change to submit an official patch. Thanks, applied as of r16229. This is generally only tricky when building in-tree, as there's no guarantee of an installed Parrot. Outside of the tree, there's no point in continuing if the headers aren't present; I'm not going to scan the attached mount points to try to find a likely target. Right. If in-tree, would it make sense to just ignore parrot.pc and assume the file locations? Maybe under some additional condition - e.g. Windows / Visual C++, not to disrupt the current scheme where it's working? I considered that briefly for all platforms at the start, but I figured I wanted to allow people to install Parrot::Embed to run against an uninstalled Parrot. Perhaps no one will want to do that. I'm not using P::E myself, but like to smoke it and make it work for others. So, for me it would be good if I can keep everything in the smoke chamber, but that's not too important. As you said, P::E needs the header and library path for compiling and linking, and the library path for running. I'd need some help where to look for them / get them from. This is mostly about others, as I have no second thought digging as deep into the guts as necessary to make it work for me. That's probably why I'm not quite sure what to do here. ;-) Ron
Re: Building Parrot::Embed on Windows XP / Visual C++
chromatic wrote: On Friday 22 December 2006 12:54, Ron Blaschke wrote: -void Parrot_register_pmc(Parrot_INTERP, Parrot_PMC); -void Parrot_unregister_pmc(Parrot_INTERP, Parrot_PMC); +PARROT_API void Parrot_register_pmc(Parrot_INTERP, Parrot_PMC); +PARROT_API void Parrot_unregister_pmc(Parrot_INTERP, Parrot_PMC); I thought I'd collect everything necessary together and submit a single patch. That patch works for me, but if you want to hold off it's fine. Anything that embeds Parrot needs to use those APIs anyway, so it's not a P::E specific fix. It would be great if you could make the change right away. I thought it was just too small of a change to submit an official patch. Sorry, no pkg-config here. Not sure if there are other toolkits, like MinGW or Cygwin, that are providing it. I'm not a Linux/UNIX regular, is Fparrot.pc used by this tool? The file is parsed directly by P::E's Build.PL, so I thought it's just a random format. It's a Unix tool that helps linking against installed libraries. FBuild.PL parses it because it's probably close to correct. I see. Maybe it would be enough to come up with some platform specific search code for Windows in P::C's Build.PL. After all, everything we need is the library and the headers. I'm wondering how other Perl modules handle this... There are really only two things that P::E needs in two places: - the header and library path for compiling and linking - the library path for running This is generally only tricky when building in-tree, as there's no guarantee of an installed Parrot. Outside of the tree, there's no point in continuing if the headers aren't present; I'm not going to scan the attached mount points to try to find a likely target. Right. If in-tree, would it make sense to just ignore parrot.pc and assume the file locations? Maybe under some additional condition - e.g. Windows / Visual C++, not to disrupt the current scheme where it's working? Thanks for your help, Ron
Re: Assertions and MMD (on Windows XP)
Leopold Toetsch wrote: Am Mittwoch, 20. Dezember 2006 20:24 schrieb Ron Blaschke: - The assertion seems to check that the lowest two bits of a function pointer are zero. Why's that? That's a bigger hack to discern function from PMC pointers in that table. That hack and the whole table needs to be replaced by a more densly packed infix MMD cache representation (that was mmd_table actually is). Thanks for your explanations! Ron
Building Parrot::Embed on Windows XP / Visual C++
I have managed to build Parrot::Embed on Windows/VC8, and judging from
the test output it works. There are two warnings, but I guess those are
no problem?
$ ./Build test
t\interpok 1/31Parrot VM: Can't stat no file here, code 2.
error:imcc:syntax error, unexpected IDENTIFIER
in file 'EVAL_2' line 1
t\interpok
All tests successful.
Files=1, Tests=31, 0 wallclock secs ( 0.00 cusr + 0.00 csys =
0.00 CPU)
There are three steps necessary (four using VC8).
1) Two additional functions need to be exported.
Parrot_register_pmc
Parrot_unregister_pmc
2) Change the compiler and linker flags.
3) Add the path to parrot.dll to Path, so it can be found during (test)
execution.
Step 2 is the hard part, and I'd like to ask for some advice. The flags
seem to come from Fparrot.pc, generated from the input file
Fconfig/gen/makefiles/parrot.pc.in. The relevant entries are:
Libs: -L${libdir} -lparrot
Cflags: -I${includedir}
The CCflags seem to be added correctly in Module::Build (version
0.2805) to the Cextra_compiler_flags, but they don't get passed to the
compiler. I needed to change Cincpath for this. This seems to be an
issue with Module::Build, but I need to double check this.
Second, CLibs is not right for Visual C++ (but added to
Cextra_linker_flags and passed to the linker.)
Fconfig/gen/makefiles/parrot.pc.in says:
Libs: -L${libdir} -lparrot @icu_shared@ @libs@
Visual C++ needs:
${libdir}/libparrot.lib @icu_shared@ @libs@
or
/LIBPATH:${libdir} libparrot.lib @icu_shared@ @libs@
Any recommended way to get there?
Thanks,
Ron
Re: Building Parrot::Embed on Windows XP / Visual C++
chromatic wrote:
On Friday 22 December 2006 11:08, Ron Blaschke wrote:
There are three steps necessary (four using VC8).
1) Two additional functions need to be exported.
Parrot_register_pmc
Parrot_unregister_pmc
In some .def file somewhere, or marked somehow in the source code?
The necessary change is:
$ svn diff include/parrot/extend.h
Index: include/parrot/extend.h
===
--- include/parrot/extend.h (revision 16218)
+++ include/parrot/extend.h (working copy)
@@ -121,8 +121,8 @@
Parrot_Language Parrot_find_language(Parrot_INTERP, char*);
-void Parrot_register_pmc(Parrot_INTERP, Parrot_PMC);
-void Parrot_unregister_pmc(Parrot_INTERP, Parrot_PMC);
+PARROT_API void Parrot_register_pmc(Parrot_INTERP, Parrot_PMC);
+PARROT_API void Parrot_unregister_pmc(Parrot_INTERP, Parrot_PMC);
Parrot_PMC Parrot_get_dod_registry(Parrot_INTERP);
I thought I'd collect everything necessary together and submit a single
patch.
2) Change the compiler and linker flags.
3) Add the path to parrot.dll to Path, so it can be found during (test)
execution.
That's tough on all platforms. Is it a simple case of adding ../../blib/lib
to $ENV{PATH} before executing the tests?
Yes. ${libdir} points to F../../blib/lib, but on Windows the DLL is
put into the root directory, like Fminiparrot.exe or Fparrot.exe.
Not sure about other platforms. So F../.. would do for Windows.
Step 2 is the hard part, and I'd like to ask for some advice. The flags
seem to come from Fparrot.pc, generated from the input file
Fconfig/gen/makefiles/parrot.pc.in. The relevant entries are:
Libs: -L${libdir} -lparrot
Cflags: -I${includedir}
The CCflags seem to be added correctly in Module::Build (version
0.2805) to the Cextra_compiler_flags, but they don't get passed to the
compiler. I needed to change Cincpath for this. This seems to be an
issue with Module::Build, but I need to double check this.
Is Cincpath a separate M::B option for Win32?
I have to admit I just hacked F_build/build_params to get P::E
compiled. I'm not sure where Cincpath is coming from. On my box it says:
'incpath' = '\\include'
I'll have to keep searching for this.
Cextra_compiler_flags is:
'extra_compiler_flags' = [
'-I/usr/local/include',
'-I..\\..\\include'
],
But I don't see them during the call to the compiler.
Second, CLibs is not right for Visual C++ (but added to
Cextra_linker_flags and passed to the linker.)
Fconfig/gen/makefiles/parrot.pc.in says:
Libs: -L${libdir} -lparrot @icu_shared@ @libs@
Visual C++ needs:
${libdir}/libparrot.lib @icu_shared@ @libs@
or
/LIBPATH:${libdir} libparrot.lib @icu_shared@ @libs@
Any recommended way to get there?
Does pkg-config work on Windows? If not, modifying that file is rather moot,
and Parrot::Embed can work another way. Another option is to use
Parrot::Config, if that'll be available and installed. That might be a
better option.
I'm open to ideas.
Sorry, no pkg-config here. Not sure if there are other toolkits, like
MinGW or Cygwin, that are providing it. I'm not a Linux/UNIX regular,
is Fparrot.pc used by this tool? The file is parsed directly by
P::E's Build.PL, so I thought it's just a random format.
Just thinking loud here, but even if there isn't a pkg-config on Windows
we could reuse the file. Cparrot.pc is generated by Configure using
the template Fconfig/gen/makefiles/parrot.pc.in. One way I can see
would be to put the parrot library options into a variable, like this:
Libs: @libparrot_shared@ @icu_shared@ @libs@
with @libparrot_shared@ == -L${libdir} -lparrot on GCC (not sure where
else, too)
and @libparrot_shared@ == ${libdir}/libparrot.lib on VC.
Another way would be to template all of Cparrot.pc.in, by adding
Cvc_parrot.pc.in, and select the right template during source generation.
In my opinion Parrot::Config is probably not the best way to handle
this. The paths are relative and not expanded, for example:
'cc_inc' = '-I./include',
'libparrot' = '$(LIBPARROT_SHARED)',
'libparrot_ldflags' = 'libparrot$(A)',
'libparrot_shared' = 'libparrot$(SHARE_EXT)',
I guess P::C is more for introspection how Parrot was built, not how to
build an extension.
Maybe it would be enough to come up with some platform specific search
code for Windows in P::C's Build.PL. After all, everything we need is
the library and the headers. I'm wondering how other Perl modules
handle this...
Any thoughts are greatly appreciated,
Ron
Assertions and MMD (on Windows XP)
Sorry to bring this up again, but I hope someone can help me with this.
I'm trying to compile Parrot on Windows XP / Visual C++ with assertions
enabled, that is, without CNDEBUG.
When running miniparrot I receive the following error:
Assertion failed: (PTR2UINTVAL(mmd_table[i].func_ptr) 3) == 0, file
src\mmd.c, line 1709
Here's some context:
-snip-
/*
* register default mmds for this type
*/
for (i = 0; i n; ++i) {
assert((PTR2UINTVAL(mmd_table[i].func_ptr) 3) == 0);
mmd_register(interp,
mmd_table[i].func_nr, type,
mmd_table[i].right, mmd_table[i].func_ptr);
mmd_create_builtin_multi_meth(interp, ns, type, mmd_table + i);
}
-snip-
Now, when I run miniparrot through the debugger Cmmd_table[0].func_ptr
is 0x100036e3, which is CParrot_UnManagedStruct_is_equal.
My questions are:
- Is anyone else smoking / running Parrot with assertions enabled?
- The assertion seems to check that the lowest two bits of a function
pointer are zero. Why's that?
Thanks,
Ron
