Re: HLLs needing OpenGL support
Geoffrey Broadwell a écrit : On Mon, 2008-07-21 at 09:34 +0200, François Perrad wrote: Geoffrey Broadwell a écrit : fperrad: How do these bindings actually work? There'll work with runtime/parrot/library/OpenGL.pir. OK ... so what could be improved about runtime/parrot/library/OpenGL.pir so that you didn't have to write any bindings at all, or so that your bindings could be greatly simplified? So far, I'm seeing the following: Ok, talking about libraries : Lua compiler & Lua Standard Libraries are complete (as far as the current Parrot supports it). So, since April 2008, I wrote some extension libraries for Lua : - lua/src/lib/base64.pir : wrapper over library/MIME/Base64.pir - lua/src/lib/bc.pir : big number library, currently over the PMC BigInt (waiting for BigFloat) - lua/src/lib/bitlib.pir : bitwise operation library, pure PIR - lua/src/lib/lfs.pir : Lua File System library, over the PMC OS (still incomplete) - lua/src/lib/md5.pir & sha1.pir : wrapper over PMC MD5 & SHA1 (I wrote them on the outside of Lua) - lua/src/lib/random.pir : wrapper over library/Math/Random/mt19937ar.pir (I wrote it on the outside of Lua) - lua/src/lib/uuid.pir : wrapper over library/uuid.pir (I wrote it on the outside of Lua) Since mid-June 2008, I tried to write extension libraries for Pipp (PHP supplies more than 2500 functions !!!, huge work, but I believe that PHP could be the killer application for Parrot) : - pipp/src/common/php_API.pir & php_MACRO.pir : some helpers (argument checking) - pipp/src/common/php_base64.pir : wrapper over library/MIME/Base64.pir (but incomplete because PHP API has more options than MIME/Base64 Perl API) - pipp/src/common/php_ctype.pir : pure PIR - pipp/src/common/php_gmp.pir : started over PMC BigInt, but needs a full NCI binding over gmp - pipp/src/common/php_math.pir : pure PIR - pipp/src/common/php_md5.pir & sha1.pir : wrapper over PMC MD5 & SHA1 - pipp/src/common/php_pcre.pir : wrapper over library/pcre.pir (incomplete because no PhpArray support, and the NCI PCRE is incomplete and seems very old) - pipp/src/common/php_rand.pir : wrapper over PMC Random & library/Math/Random/mt19937ar.pir - pipp/src/common/php_type.pir : pure PIR As I need to write a NCI wrapper over gmp, I begin my study of NCI by using the OpenGL one (with Lua). If I try to summarize my experiment with libraries : Parrot will supply 3 kinds of common libraries for HLL - written in Perl6, but currently not available (I don't know if NQP is suitable for writing library) - written in PIR, but only for bootstrap, because as Bernhard Schmalhofer tell "PIR is not a decent language" + good for libraries not common (in fact equivalent to builtins) - lua/src/lib/bitlib.pir - lua/src/lib/lfs.pir - pipp/src/common/php_ctype.pir - pipp/src/common/php_math.pir - pipp/src/common/php_type.pir + good when no native library available (but a full test suite is needed) - library/Math/Random/mt19937ar.pir (Mersenne Twisted) - binding over native (C/C++) shared libraries + with native PMC (C compile/link) - sometime, for security reason, a static linkage is mandatory (libssl is shared lib, but its subset libcrypto is static lib) - other advantage, PMC allows direct OO interface + with NCI : the best way (no C compile/link) - but only procedural interface (no direct OO) 2 designs choices : - For long term maintenance, I write PIR close to original C. For example, I start Lua on Parrot aligned with version 5.0.2 and now it's 5.1.3. And in most of case, the original C is the only valid (updated) user & requirements documentation. - I try to emit the same (as possible) error or warning messages than the original implementation and to have the same interface. Rule of Least Surprise for the end user. And I could run the test suite against the original implementation. Now, talking about Lua specifics : - Lua Tables are the main (and the only) structured type in Lua, they supply array & hash (like PHP array). They are used to supply the namespace support and the OO mecanism. There are no keyword for namespace. Standard Libraries & others live in their table (ie namespace). So, in the init function of a library, I wrote (or generate) some boring code like : .const .Sub _mod_funct = 'func' _mod_func.'setfenv'(_lua__GLOBAL) set $P1, 'func' _mod[$P1] = _mod_func I wait for a IMCC improvement (hi kjs) in order to support : .macro register(tname, fname) .const .Sub $fname = .fname $fname.'setfenv'(_lua__GLOBAL) set $P1, .fname .tname[$P1] = $fname .endm - Currently, the LuaTable implementation don't support the Parrot namespaces API. But I think it's doable. - Since my first implementation, libraries & generated code use the 2 same patterns for function preamble : .sub 'func_with_vararg' : anon .param pmc arg1 :optional
Re: pbc install_config: howto install perl6 and languages?
2008/7/22 chromatic <[EMAIL PROTECTED]>: > On Monday 21 July 2008 13:48:41 Reini Urban wrote: > >> I did it now this way: >> >> pbc_to_exe accepts a 2nd optional arg. >> If it's --install the exe is prefixed with "installable_", and it's not >> linked against parrot_config.o but against install_config.o >> >> This way I can produce installable languages. For now I did it just for >> perl6. > > Is there any reason to link against parrot_config.o instead of > install_config.o? for testing only. make test and make smoke -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[perl #57188] [PATCH] pbc_to_exe --install
# New Ticket Created by Reini Urban # Please include the string: [perl #57188] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57188 > --- osname= cygwin osvers= 1.5.25(0.15642) arch= cygwin-thread-multi-64int cc= gcc --- Flags: category=install severity=high ack=no --- Attached patch adds --install to pbc_to_exe, adds a basic pod to pbc_to_exe, and applies --install to perl6. link against install_config.o and add installable prefix. Limitation: With --install the first arg infile must have no directory part! Now we can generate make install for the languages. --- Summary of my parrot 0.6.4 (r0) configuration: configdate='Sat Jul 19 07:34:08 2008 GMT' Platform: osname=cygwin, archname=cygwin-thread-multi-64int jitcapable=1, jitarchname=i386-cygwin, jitosname=CYGWIN, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl.exe Compiler: cc='gcc', ccflags='-U__STRICT_ANSI__ -pipe -I/usr/local/include -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wno-missing-format-attribute -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -DDISABLE_GC_DEBUG=1 -DNDEBUG -O3 -DHAS_GETTEXT', Linker and Libraries: ld='gcc', ldflags=' -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib', cc_ldflags='', libs='-lcrypt -lgmp -lreadline -lpcre -lcrypto -lintl' Dynamic Linking: share_ext='.dll', ld_share_flags='-shared', load_ext='.dll', ld_load_flags='-shared' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 Locally applied patches: [perl #51944] [DOCS] Cygwin Readme [perl #56562] [PATCH] root.in: add cygwin importlib [perl #56544] [PATCH] install_files.pl [perl #56558] [PATCH] pdb rename to parrot_pdb [perl #56998] [TODO] rename cygwin dll to cygparrot$MAJOR_$MINOR_$PATCH.dll [perl #57006] [PATCH] add cygwin opengl config quirks [perl #57110] [PATCH] ncurses for cygwin [perl #57112] [PATCH] postgres for cygwin [perl #57114] [PATCH] urm RealBin issue --- Environment: CYGWIN =server HOME =/home/rurban LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =~/bin:/usr/bin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/usr/bin:/cygdrive/c/WINDOWS/System32/Wbem: SHELL (unset) difforig languages/perl6/config/makefiles/root.in tools/dev/pbc_to_exe_gen.pl * add --install to pbc_to_exe to link against install_config.o and add installable prefix. Limitation: With --install the first arg infile must have no directory part! diff -u languages/perl6/config/makefiles/root.in.orig languages/perl6/config/makefiles/root.in --- languages/perl6/config/makefiles/root.in.orig 2008-07-11 06:47:06.0 + +++ languages/perl6/config/makefiles/root.in 2008-07-21 20:14:57.25000 + @@ -113,6 +113,9 @@ perl6.pbc: $(PARROT) $(SOURCES) $(PARROT) $(PARROT_ARGS) -o perl6.pbc perl6.pir +installable_perl6$(EXE): perl6.pbc + $(PBC_TO_EXE) perl6.pbc --install + src/gen_grammar.pir: $(PERL6GRAMMAR) src/parser/grammar.pg src/parser/grammar-oper.pg $(PARROT) $(PARROT_ARGS) $(PERL6GRAMMAR) \ --output=src/gen_grammar.pir \ diff -u tools/dev/pbc_to_exe_gen.pl.orig tools/dev/pbc_to_exe_gen.pl --- tools/dev/pbc_to_exe_gen.pl.orig 2008-07-19 08:18:54.671875000 + +++ tools/dev/pbc_to_exe_gen.pl 2008-07-21 20:41:08.87500 + @@ -54,8 +54,40 @@ argc = args if argc == 2 goto proper_args +if argc == 3 goto check_install .return () +check_install: +.local string infile, install + +$P0= shift args +infile = shift args +install = shift args +if install == '--install' goto proper_install +.return () + +proper_install: +.local string cfile, objfile, obj, exefile, exe + +$P0= '_config'() +obj= $P0['o'] +exe= $P0['exe'] + +.local int infile_len +infi
Re: [perl #56800] [META] merge pdd25cx branch back into trunk
François Perrad a écrit :
Bernhard Schmalhofer via RT a écrit :
In r29552 of https://svn.perl.org/parrot/branches/pdd25cx I ran make test
for: pipp, eclectus, hq9plus, lazy-k, m4, unlambda.
All tests were passing.
in branch_pdd25cx, 221/1109 Lua subtests failed.
Mostly for same reason : exception handling.
$ cat nil.lua
print(- nil)
[trunk] $ parrot luc.pbc nil.lua
lua.pbc: EVAL_1:33: attempt to perform arithmetic on a nil value
stack traceback:
EVAL_1:33 in function '&main_10'
languages/lua/src/lib/luaaux.pir:788 in function 'docall'
lua.pir:303 in function 'handle_script'
lua.pir:123 in function 'main'
[branch_pdd25cx] $ parrot lua.pbc nil.lua
lua.pbc: attempt to perform arithmetic on a nil value
in this example, the exception is raised by the following code in
languages/lua/src/pmc/luaany.pmc (line #216)
PMC* neg(PMC *dest) {
PMC *meth = find_meth(INTERP, SELF, "__unm");
if (!meth)
Parrot_ex_throw_from_c_args(INTERP, NULL,
EXCEPTION_ILL_INHERIT,
"attempt to perform arithmetic on a %Ss value",
SELF.name());
...
The global exception handler for Lua is in
languages/lua/src/lib/luaaux.pir (lines 775-823),
with the function 'docall' and the closure 'traceback'.
Missing data are retrieved with the methods 'where' & 'traceback'
implemented in languages/lua/src/pmc/lua.pmc.
In fact 'docall' uses a pushaction.
François.
How rewrites it in branch_pdd25cx ?
François.
Re: pbc install_config: howto install perl6 and languages?
On Tuesday 22 July 2008 04:43:59 Reini Urban wrote: > > Is there any reason to link against parrot_config.o instead of > > install_config.o? > for testing only. > make test and make smoke Do they not work if it gets linked against parrot_config.o? -- c
Re: [perl #57188] [PATCH] pbc_to_exe --install
On Tuesday 22 July 2008 04:56:53 Reini Urban wrote: > Attached patch adds --install to pbc_to_exe, > adds a basic pod to pbc_to_exe, > and applies --install to perl6. > > link against install_config.o and add installable prefix. > Limitation: With --install the first arg infile must have no > directory part! > > Now we can generate make install for the languages. Hi! When I try to apply your patch, I get: [EMAIL PROTECTED] parrot-trunk % patch -p0 <~/Desktop/installable_pbc_to_exe.patch patching file languages/perl6/config/makefiles/root.in patching file tools/dev/pbc_to_exe_gen.pl misordered hunks! output would be garbled Hunk #4 FAILED at 11. misordered hunks! output would be garbled Hunk #5 FAILED at 70. misordered hunks! output would be garbled Hunk #6 FAILED at 318. 3 out of 10 hunks FAILED -- saving rejects to file tools/dev/pbc_to_exe_gen.pl.rej Any chance of getting an in-order diff? If not, could you just attach your pbc_to_exe_gen.pl? Thanks, Mark
[perl #57196] [RFE] RSS feeds for smolder
# New Ticket Created by Will Coleda # Please include the string: [perl #57196] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57196 > Can we get the tag information included in the RSS summary articles? Will be very helpful for folks trying to triage the reports via the feed. (For example, we have a very energetic netbsd smolder agent who is reporting the same test failure over and over again. His one failure looks suspiciously similar to single MSWin32 failure, but it's drowned out by the other reports.) Thanks. -- Will "Coke" Coleda
[perl #57198] [openbsd] build failure?
# New Ticket Created by Will Coleda # Please include the string: [perl #57198] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57198 > http://smolder.plusthree.com/app/public_projects/report_details/2435#first_failure Looks like the client running the smolder test for openbsd here isn't getting a built parrot, and is then failing much of the test suite as a result. Can whoever is doing that build give us a report as to -how- the build is failing? -- Will "Coke" Coleda
Re: pbc install_config: howto install perl6 and languages?
chromatic schrieb: On Tuesday 22 July 2008 04:43:59 Reini Urban wrote: Is there any reason to link against parrot_config.o instead of install_config.o? for testing only. make test and make smoke Do they not work if it gets linked against parrot_config.o? They work if I keep the build_dir intact on my devel machine. But if a package it and install on a machine without the build_dir it fails. Or if I rename the build_dir: I did this mistake in my first cygwin packages unless somewhen traced the bug down, and I found it out the hard way. With my fix in [perl #57188] [PATCH] pbc_to_exe --install and my build script in the cygwin package 0.6.4-2 it works fine now. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[perl #56958] HLL map of :slurpy's ResizablePMCArray
On Tue Jul 22 08:02:08 2008, tene wrote: > Resolved as of r29673. > > Parrot_process_args() wasn't fetching the appropriate type from the HLL > mapping info when creating an object to store slurpy params in. Thanks. Added a modified version of my original test in r29682. Thanks to tene for pointing out that you need to actually declare a .HLL; Also the subclass is gone, replaced with another PMC; looks like there might be other issues with non-PMC classes, but that's a different test and a different RT. Note that the tcl workaround in languages/tcl/runtime/builtin/list.pir is removed, tene's fix resolved the original issue. -- Will "Coke" Coleda
Re: HLLs needing OpenGL support
On Tue, 2008-07-22 at 09:03 +0200, François Perrad wrote: > Ok, talking about libraries : > Lua compiler & Lua Standard Libraries are complete (as far as the > current Parrot supports it). > So, since April 2008, I wrote some extension libraries for Lua > Since mid-June 2008, I tried to write extension libraries for Pipp > (PHP supplies more than 2500 functions !!!, huge work) >From a couple comments you make later, it sounds like you're aiming to be perfectly API compatible with the original library implementations for Lua and PHP, so that moving to Parrot is a "drop-in" replacement as far as the user's source code is concerned; am I correct in this assumption? > I believe that PHP could be the killer application for Parrot Why PHP in particular? Is it because of what Parrot can do for PHP (performance, stability (we hope), interop, ...), or because of what PHP can do for Parrot (bring lots of eyeballs to Parrot, as Tim Bunce mentioned for embedding Parrot in Java)? > - lua/src/lib/md5.pir & sha1.pir : wrapper over PMC MD5 & SHA1 (I wrote > them on the outside of Lua) > - lua/src/lib/random.pir : wrapper over > library/Math/Random/mt19937ar.pir (I wrote it on the outside of Lua) > - lua/src/lib/uuid.pir : wrapper over library/uuid.pir (I wrote it on > the outside of Lua) Meaning, you wrote the PMCs / Parrot library PIR before working on Lua, without any Lua dependencies? > - lua/src/lib/lfs.pir : Lua File System library, over the PMC OS > (still incomplete) > - pipp/src/common/php_base64.pir : wrapper over library/MIME/Base64.pir > (but incomplete because PHP API has more options than MIME/Base64 Perl API) > - pipp/src/common/php_pcre.pir : wrapper over library/pcre.pir > (incomplete because no PhpArray support, and the NCI PCRE is incomplete > and seems very old) Can you please create tickets for the stuff that's missing that you need? Maybe we can get someone to take on improvements of these, so you don't have to > As I need to write a NCI wrapper over gmp, I begin my study of NCI by > using the OpenGL one (with Lua). Makes sense. > If I try to summarize my experiment with libraries : > Parrot will supply 3 kinds of common libraries for HLL > - written in Perl6, but currently not available (I don't know if NQP is > suitable for writing library) In theory perhaps, but NQP has a lot of limitations (intentionally). > - written in PIR, but only for bootstrap, because as Bernhard > Schmalhofer tell "PIR is not a decent language" > + good for libraries not common (in fact equivalent to builtins) > - lua/src/lib/bitlib.pir > - lua/src/lib/lfs.pir > - pipp/src/common/php_ctype.pir > - pipp/src/common/php_math.pir > - pipp/src/common/php_type.pir > + good when no native library available (but a full test suite is > needed) > - library/Math/Random/mt19937ar.pir (Mersenne Twisted) I'm not sure what you mean by "only for bootstrap" here. Do you mean because of potential performance problems implementing heavy math code in PIR as opposed to C? > - binding over native (C/C++) shared libraries > + with native PMC (C compile/link) >- sometime, for security reason, a static linkage is mandatory > (libssl is shared lib, but its subset libcrypto is static lib) >- other advantage, PMC allows direct OO interface And for security libraries, being able to precisely control buffer copies is important > + with NCI : the best way (no C compile/link) >- but only procedural interface (no direct OO) How many system libraries provide a true OO interface only, with no procedural or procedural-pretending-to-be-OO interface (like GNOME, for instance)? What functionality do we actually *need* to support those stragglers? > 2 designs choices : > - For long term maintenance, I write PIR close to original C. For > example, I start Lua on Parrot aligned with version 5.0.2 and now it's > 5.1.3. And in most of case, the original C is the only valid (updated) > user & requirements documentation. Like the old "Perl 5 (the language) *is* what perl5 (the VM) *does*" problem > - I try to emit the same (as possible) error or warning messages than > the original implementation and to have the same interface. Rule of > Least Surprise for the end user. And I could run the test suite against > the original implementation. Makes sense. > So, in the init function of a library, I wrote (or generate) some boring > code like : > .const .Sub _mod_funct = 'func' > _mod_func.'setfenv'(_lua__GLOBAL) > set $P1, 'func' > _mod[$P1] = _mod_func > I wait for a IMCC improvement (hi kjs) in order to support : > .macro register(tname, fname) > .const .Sub $fname = .fname > $fname.'setfenv'(_lua__GLOBAL) > set $P1, .fname > .tname[$P1] = $fname > .endm Again, what's missing here? Can you write up an RT ticket for the missing fun
[perl #57190] HLL Interoperation
# New Ticket Created by Moritz Lenz # Please include the string: [perl #57190] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57190 > Recently on IRC the matter of HLL interoperation came up frequently, this ticket brings it to RT and the list. Motivation: It should be possible to use libraries written in a different HLL, for example you might want to call a TCL library from Perl 6. Problem: There are actually many problems. For example, if a TCL function returns an integer, what will Perl 6 see? A Perl 6-native Int? or a Int:lang(TCL) (or whatever the syntax for a type name from a different language is)? How will this conversion be made? Can it be done without a separate bridge for each pair of HLLs? And finally, it needs to be documented. For a few notes, and pointers to the discussions on IRC please see http://www.perlfoundation.org/parrot/index.cgi?intra_hll_mapping_notes To not create another unclosable ticket, I consider this ticket closed when 1) there is a proof-of-concept implementation that allows you to call functions/methods from a different HLL, and meaningfully work with its results in one of the major languages (ie not a language built specifically for that purpose) 2) There is documentation on how to make your language cross-HLL-ready, either in PCT or core documentation. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: pbc install_config: howto install perl6 and languages?
On Tuesday 22 July 2008 08:13:06 Reini Urban wrote: > > Do they not work if it gets linked against parrot_config.o? > > They work if I keep the build_dir intact on my devel machine. > But if a package it and install on a machine without the build_dir it > fails. Or if I rename the build_dir: > > I did this mistake in my first cygwin packages unless somewhen traced > the bug down, and I found it out the hard way. > > With my fix in [perl #57188] [PATCH] pbc_to_exe --install > and my build script in the cygwin package 0.6.4-2 it works fine now. If one of the two linking options works both in development mode and in installation mode, let's use that instead of adding options. If we link against install_config.o, can we use the fakecutables within the build tree without having libparrot officially installed? -- c
Re: [perl #56756] [BUG] t\pmc\pmc.t failure on win32
Ron Blaschke wrote: 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. # 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\parrot>prove 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 I have been seeing the same issue through r29684. See http://smolder.plusthree.com/app/public_projects/report_details/2381#first_failure I have Visual C++ 9.0 (Express Edition): C:\work\parrot>cl Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. I do not get the error in my gcc (mingw32) builds on the same machine. --- Tim
Re: [perl #56756] [BUG] t\pmc\pmc.t failure on win32
I don't know if this will help shed any light, but it seems related to the number of data types tested in pmc_5.pasm. I find that if I remove one or more data type tests from this file (say, the section that does TQueue or Eval) and run the pasm directly with parrot, parrot will exit with a status code of 0. When I restore all the code, it exits with nonzero status. It doesn't seem to matter which data type's test I remove. I am also not sure what these lines are for: new P10, 'Hash' new P11, 'Hash' In t/pmc.t they are pasm_output_like( <<"CODE",
[perl #52198] [BUG]: Test failures on Win32: t/op/arithmetics.t t/op/sprintf.t t/pmc/complex.t t/pmc/float.t
t/op/sprintf.t has been passing on Win32 with VC++ (r29667), see http://smolder.plusthree.com/app/public_projects/report_details/2429 http://smolder.plusthree.com/app/public_projects/tap_stream/2429/351 ok 157 - [%.0g] C99 standard mandates minus sign but C89 does not skip: MSWin32 VMS hpux:10.20 openbsd netbsd:1.5 irix However, it does not pass with gcc on Win32 (r29667) http://smolder.plusthree.com/app/public_projects/report_details/2432#first_failure http://smolder.plusthree.com/app/public_projects/tap_stream/2432/351 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< --- Tim
[perl #57190] HLL Interoperation
From: Moritz Lenz (via RT) <[EMAIL PROTECTED]> Date: Tue, 22 Jul 2008 06:34:13 -0700 Recently on IRC the matter of HLL interoperation came up frequently, this ticket brings it to RT and the list. Motivation: It should be possible to use libraries written in a different HLL, for example you might want to call a TCL library from Perl 6. Problem: There are actually many problems. For example, if a TCL function returns an integer, what will Perl 6 see? A Perl 6-native Int? or a Int:lang(TCL) (or whatever the syntax for a type name from a different language is)? Small plea: For numbers at least, and preferably for anything else which can be described in mathematical terms, Parrot ought to have as small a set of representation types as possible, in order to minimize the need for mapping (if not eliminate it entirely) when calling across language boundaries. Start with something "simple," like the meaning of "the integer three divided by the integer five", which differs significantly between languages: In Tcl, this division of two integers produces the integer value 0. In Perl 5 and Lua, this division produces the floating-point value 0.6. In Common Lisp, this division produces "3/5", the mathematically- exact ratio with numerator 3 and denominator 5. One way to implement these different meanings is to provide a common division operator that dispatches on the types of its operands. This fails for operands of mixed type; dividing a Perl integer by a Lua integer is straightforward, but what should we do for division of a Tcl integer by a Lisp integer? Or vice versa? An even bigger problem is that no Perl 5 code, when given two integers to divide, will expect a Common Lisp ratio as a result. Any Perl 5 implementation that does this has a bug, even if both those integers happen to come from Common Lisp. Ditto for a floating-point result from Common Lisp code that happens to get two integers from Perl or Lua (or both!). So I would argue that (1) what seem like differences in numbers in the various languages are really differences in the way those languages define their numeric operators, not in the numbers themselves; and (2) standardizing on common numeric data type will avoid the impossible job of making the Parrot built-in arithmetic be all things to all languages (and all combinations thereof). I would further argue that *any* sort of type mapping is problematic when calling across language boundaries. If I pass an array of arrays of ... of numbers from one language to another, then mapping would seem to require a deep copy. This changes the API: The native call into this routine can see side effects to the passed data structure, whereas the foreign call would not. (Or am I misunderstanding what you mean by "mapping" here?) -- Bob Rogers http://rgrjr.dyndns.org/
Inter-HLL Mapping Notes
The wiki page at: http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_notes seems to be missing the rationale for *why* it's necessary to map types between languages? (Also see "If Perl 6 has to care about the internal storage format of an Integer PMC, it's doing something very wrong.") -- c
Re: Inter-HLL Mapping Notes
On Tue, 2008-07-22 at 15:37 -0700, chromatic wrote: > The wiki page at: > > http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_notes > > seems to be missing the rationale for *why* it's necessary to map types > between languages? (Also see "If Perl 6 has to care about the internal > storage format of an Integer PMC, it's doing something very wrong.") What about HLL-specific container types, above the level of the basic Parrot-provided types? What does Lisp do with a Perl 5 Scalar? What does Forth do with a LuaTable? How do you work with a Perl 6 Capture or Junction in LOLCODE? What about Haskell user-defined types in any language that doesn't understand records or junctive types? If your answer is "Use only Parrot-standard opcodes/vtables on them", I argue that you leave a lot of the source container's functionality on the table, and you may in fact be constrained to do things that are meaningless or absurd. If your answer is "Treat them as opaque objects with methods" then: A) you have just defined a type mapping B) this may be much lower performance than another mapping could be C) what about destination languages without native standardized OO? D) every source language is burdened with defining a complete set of dumbed-down methods to access every type, which it may not need or use internally E) you've lost the syntactic convenience that comes with being able to work with advanced types using native syntax in the destination language, if the source type could map directly If you want to be smarter than either of these, then you need to figure out a better way to do HLL-to-HLL typemapping. Hence our discussion. -'f
Re: Inter-HLL Mapping Notes
On Tuesday 22 July 2008 15:37:33 chromatic wrote: > The wiki page at: > > http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_not >es > > seems to be missing the rationale for *why* it's necessary to map > types between languages? (Also see "If Perl 6 has to care about the > internal storage format of an Integer PMC, it's doing something very > wrong.") Integer is a good example of the problem, actually. The internal storage format doesn't change, but the methods you can call on it definitely will. HLLs wrap the Integer class with their own subclasses, so that they have methods they can call on integers, which are expected by the HLL. But when your perl6 function passes a Perl6Int to a TCL function, TCL HLL code code will try to access the integer, but it's not a TclInt, its a Perl6Int! The value itself is fine, but the methods it expects to find will not be there. Hence the need for conversion/mapping. -- Mark
Re: [perl #57190] HLL Interoperation
On Tue, 2008-07-22 at 22:58 -0400, Bob Rogers wrote: >So I would argue that (1) what seem like differences in numbers in > the various languages are really differences in the way those languages > define their numeric operators, not in the numbers themselves; I disagree. How do you represent Complex in a language that doesn't have a way to represent a number with more than one dimension? This is a fundamentally different kind of thing than any simpler numeric type. > and (2) > standardizing on common numeric data type will avoid the impossible job > of making the Parrot built-in arithmetic be all things to all languages > (and all combinations thereof). That's certainly a possible choice, but it's still a mapping, and I argue not the only sane one. More than one language has a Complex type, but not all of them do. If we make Complex the base Parrot type that everything gets converted to, then some languages will be ... unhappy. If we standardize on some other numeric type, than we fail the round trip test spectacularly. >I would further argue that *any* sort of type mapping is problematic > when calling across language boundaries. If I pass an array of arrays > of ... of numbers from one language to another, then mapping would seem > to require a deep copy. This changes the API: The native call into > this routine can see side effects to the passed data structure, whereas > the foreign call would not. (Or am I misunderstanding what you mean by > "mapping" here?) I have two answers to that: 1. It may not be a deep copy; it may be an autobox of some sort. But that just begs the question of how to explain the source language's semantics to all destination languages. Something we need to discuss, clearly. :-) 2. We may simply decide that when you pass containers between HLLs, you explicitely give up some or all of the source language's guarantees, and the source language compiler is required to treat the data structure after that point as if it had been exposed to hard radiation. -'f
Re: pbc install_config: howto install perl6 and languages?
chromatic schrieb: On Tuesday 22 July 2008 08:13:06 Reini Urban wrote: Do they not work if it gets linked against parrot_config.o? They work if I keep the build_dir intact on my devel machine. But if a package it and install on a machine without the build_dir it fails. Or if I rename the build_dir: I did this mistake in my first cygwin packages unless somewhen traced the bug down, and I found it out the hard way. With my fix in [perl #57188] [PATCH] pbc_to_exe --install and my build script in the cygwin package 0.6.4-2 it works fine now. If one of the two linking options works both in development mode and in installation mode, let's use that instead of adding options. If we link against install_config.o, can we use the fakecutables within the build tree without having libparrot officially installed? No. It only looks up the lib_path up in prefix. It could work in chroot build environments to fake prefix. I came to some surprising results testing the languages with [EMAIL PROTECTED]@ and adding the install target to the Makefiles. At least lua still wants to load compilers/tge/TGE/Rule.pbc at runtime, which is forbidden in an installed setup. I tried to merge the pbc's, but I lack tuits so far. I haven't created yet a good test_installed Makefile strategy to find such runtime errors. [TODO] -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #39738] [BUG] bind fails with errno EADDRNOTAVAIL on darwin and FreeBSD
On Jul 22, 2008, at 6:35 PM, Christoph Otto via RT wrote: On Thu Jul 06 09:21:34 2006, [EMAIL PROTECTED] wrote: With parrot r13181, binding to a non-privileged port on localhost consistently fails with EADDRNOTAVAIL on Mac OS X and FreeBSD boxes for Intel and PPC platforms. The same command succeeds on Linux. Steps to reproduce: 1) ./parrot examples/io/httpd.pir 2) netstat -na | grep 1234 | grep LISTEN Actual results: Socket is not bound Expected results: "netstat -na" should contain a line like this: tcp0 0 127.0.0.1:1234 0.0.0.0:* LISTEN This no longer fails on a FreeBSD 7.0 vm. It'd be nice to confirm that it also works on Darwin, but I'll plan on marking this resolved in a few days if there are no objections. Christoph It works for me too on Mac OSX 10.4 and parrot rev 29370. Thanks for following up! Chris
[perl #43218] Memory leaks (compreg, invokecc)
On Thu Jun 14 16:25:24 2007, [EMAIL PROTECTED] wrote: > On Thursday 14 June 2007 14:42:31 Jurosz Michal wrote: > > > Attached test use compreg P1, "PASM" and invokecc it 100,000 times. > > On win32 (mingw32) it consumes 70MB of RAM with r18834 (107 MB of > RAM > > with r11704). > > With Linux at r19010, the memory use jumped up to 62 MB for me. > > However, Valgrind says: > > ==24190== LEAK SUMMARY: > ==24190==definitely lost: 128 bytes in 2 blocks. > ==24190==indirectly lost: 208 bytes in 1 blocks. > ==24190== possibly lost: 0 bytes in 0 blocks. > ==24190==still reachable: 0 bytes in 0 blocks. > ==24190== suppressed: 0 bytes in 0 blocks. > > ==24190== 252 (44 direct, 208 indirect) bytes in 1 blocks are > definitely lost > in loss record 1 of 3 > ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) > ==24190==by 0x41A1170: mem_sys_allocate > ==24190==by 0x41AF37E: parrot_new_pmc_hash_x > ==24190==by 0x41AF45E: parrot_new_pmc_hash > ==24190==by 0x424930A: Parrot_Hash_init > ==24190==by 0x4203715: Parrot_default_thaw > ==24190==by 0x424934B: Parrot_Hash_thaw > ==24190==by 0x41AD9C0: visit_todo_list_thaw > ==24190==by 0x41AD703: visit_loop_todo_list > ==24190==by 0x41AE1EB: run_thaw > ==24190==by 0x419B518: init_world > > ==24190== 84 bytes in 1 blocks are definitely lost in loss record 2 of > 3 > ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) > ==24190==by 0x41A1170: mem_sys_allocate > ==24190==by 0x41EC1DB: queue_init > ==24190==by 0x41ED08B: Parrot_init_events > ==24190==by 0x419F464: make_interpreter > ==24190==by 0x41D3BEB: Parrot_new > ==24190==by 0x8048860: main > > ==24190== 208 bytes in 1 blocks are indirectly lost in loss record 3 > of 3 > ==24190==at 0x4006620: malloc (vg_replace_malloc.c:149) > ==24190==by 0x41A1170: mem_sys_allocate > ==24190==by 0x41AF2C9: init_hash > ==24190==by 0x41AF45E: parrot_new_pmc_hash > ==24190==by 0x424930A: Parrot_Hash_init > ==24190==by 0x4203715: Parrot_default_thaw > ==24190==by 0x424934B: Parrot_Hash_thaw > ==24190==by 0x41AD9C0: visit_todo_list_thaw > ==24190==by 0x41AD703: visit_loop_todo_list > ==24190==by 0x41AE1EB: run_thaw > ==24190==by 0x419B518: init_world > > I realize the numbers don't add up, but I'm not sure that this is an > actual > leak. > > -- c > Is this something we're still concerned about or can this ticket be closed?
[perl #44967] Using a freed variable (Coverity CID 98)
On Tue Sep 04 11:40:30 2007, rblasch wrote:
>
> The key here is the "model." While Coverity's model captures the
> C quite correctly, I don't think it recognizes the pointer update
> in the double linked list, which is done in C, 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
>
Since this is a false positive, is there any reason to keep this ticket
open?
Christoph
Re: [perl #46681] [TODO] [C] Use strerror_r instead of strerror
Christoph Otto via RT wrote:
This version of the patch should dtrt with all versions of strerror_r. It
works on my Debian/x86 box and I'll be testing it on any *nix I can get my
hands on Tuesday. If it works fine there, if someone can test it on windows
and if the patch looks OK, I'll commit it and close this ticket.
Christoph
This patch contains a fix and a simplification. It should now be
cross-platform and thread-safe. I'll test on some other *nixes and go on from
there. If nothing else it works fine on Ubuntu/x86.
Index: src/pmc/file.pmc
===
--- src/pmc/file.pmc (revision 29691)
+++ src/pmc/file.pmc (working copy)
@@ -24,8 +24,50 @@
#include "parrot/parrot.h"
-/* RT#46681 apparently, strerror_r is thread-safe and should be used instead.*/
+/* strerror_r should truncate the message if it's too long for the supplied
+ * buffer. It's probably best to just specify a sane default buffer size than
+ * to worry about retrying calls. */
+#define ERRBUF_SIZE 128
+#ifndef _GNU_SOURCE
+/* use POSIXy strerror_r */
+# define STRERROR_R_EXCEPTION(interp, func) \
+{ \
+char errmsg[ERRBUF_SIZE]; \
+int err_status; \
+err_status = strerror_r(errno, errmsg, ERRBUF_SIZE); \
+/* Linux's POSIXy strerror_r returns -1 on error, others return an error code */ \
+if (err_status == -1) \
+err_status = errno; \
+\
+if (err_status == 0 || err_status == ERANGE) { \
+STRING *errmsg_pstring = string_make((interp), errmsg, strlen(errmsg), NULL, 0); \
+real_exception((interp), NULL, E_SystemError, "%Ss", errmsg_pstring); \
+} \
+else if (err_status == EINVAL){ \
+real_exception((interp), NULL, E_SystemError, \
+"%s returned an invalid error code (%d)", #func, errno); \
+} \
+else { \
+real_exception((interp), NULL, E_SystemError, \
+"strerror_r() returned an unknown error code: %d", err_status); \
+} \
+}
+#else
+/* use GNU-specific strerror_r */
+# define STRERROR_R_EXCEPTION(interp, func) \
+{ \
+/* GNU strerror_r DTRT for unknown error codes */ \
+char errmsg[ERRBUF_SIZE]; \
+char *errstr = strerror_r(errno, errmsg, ERRBUF_SIZE); \
+STRING *errmsg_pstring = string_make((interp), errstr, strlen(errstr), NULL, 0); \
+real_exception((interp), NULL, E_SystemError, "%Ss", errmsg_pstring); \
+}
+#endif
+
+
+
+
static PMC *File_PMC;
pmclass File singleton {
@@ -89,6 +131,7 @@
*/
+
METHOD is_dir(STRING *path) {
struct stat info;
char *cpath = string_to_cstring(interp, path);
@@ -100,8 +143,11 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+#ifdef WIN32
+STRERROR_R_EXCEPTION(INTERP, stat);
+#else
+STRERROR_R_EXCEPTION(INTERP, lstat);
+#endif
}
if (S_ISDIR(info.st_mode))
@@ -131,8 +177,11 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+#ifdef WIN32
+STRERROR_R_EXCEPTION(INTERP, stat);
+#else
+STRERROR_R_EXCEPTION(INTERP, lstat);
+#endif
}
if (S_ISREG(info.st_mode))
@@ -164,8 +213,7 @@
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION(INTERP, lstat);
}
if (S_ISLNK(info.st_mode))
@@ -199,6 +247,8 @@
string_cstring_free(cfrom);
+char errmsg[ERRBUF_SIZE];
+
if (source) {
char *cto= string_to_cstring(interp, to);
FILE *target = fopen(cto, "w+b");
@@ -223,14 +273,12 @@
fclose(target);
}
else {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION(INTERP, fopen);
}
fclose(source);
}
else {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION(INTERP, fopen);
}
#undef CHUNK_SIZE
}
@@ -254,8 +302,7 @@
string_cstring_free(cto);
if (error) {
-char *errmsg = strerror(errno);
-real_exception(interp, NULL, E_SystemError, errmsg);
+STRERROR_R_EXCEPTION(INTERP, rename);
}
}
}
Index: config/gen/platform/win32/string.h
===
--- config/gen/platform/win32/string.h (revision 29691
