Dflags B:C patch
not yet working -- Reini Urban http://phpwiki.org/ http://murbreak.at/ Dflags.patch Description: Binary data
Re: [perl #53494] [BUG] --parrot_is_shared=0 IS shared?
Andrew Dougherty schrieb:
On Tue, 17 Feb 2009, Will Coleda via RT wrote:
On Mon Apr 28 23:52:22 2008, coke wrote:
While trying to put the macport for 0.6.1 together, I noticed that the
install failed.
Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.
Verified, this still fails[1] as of r36803. This, combined with TT #344,
blocks creation of a functioning macport.
[1] Generates a parrot that depends on libparrot.dylib
That's because Configure.pl doesn't allow you any way to override the
hints file. What I had in mind was a more primitive, ruthless editing of
the darwin hints file, something like this (totally untested)
What I have in mind is a more general conf approach.
1. Disallow $conf-data-set('key') at all if $conf-options-get('key')
exists, only allow $conf-data-add('key').
Users try to fix the wrong hints options, and this is not enforced.
Only some keys are cooperative, most not.
2. Allow all keys to be given at the Configure.pl cmdline as in perl5.
Append (Apply after hints), Undefine and Define.
-Dcc_debug=-g3, -Ulibparrot_static, -Alinkflags=-Wl,--stack,8388608
perl5 Configure:
-D : define symbol to have some value:
-D symbol symbol gets the value 'define'
-D symbol=value symbol gets the value 'value'
common used examples (see INSTALL for more info):
-Duse64bitintuse 64bit integers
-Duse64bitalluse 64bit integers and pointers
-DEBUGGING=none DEBUGGING options
-Dcc=gcc choose your compiler
-Dprefix=/opt/perl5 choose your destination
-U : undefine symbol:
-U symbolsymbol gets the value 'undef'
-U symbol= symbol gets completely empty
e.g.: -Uversiononly
-A : manipulate symbol after the platform specific hints have been
applied:
-A append:symbol=value append value to symbol
-A symbol=value like append:, but with a separating space
-A define:symbol=value define symbol to have value
-A clear:symbol define symbol to be ''
-A define:symbol define symbol to be 'define'
-A eval:symbol=value define symbol to be eval of value
-A prepend:symbol=value prepend value to symbol
-A undef:symbol define symbol to be 'undef'
-A undef:symbol= define symbol to be ''
e.g.: -A prepend:libswanted='cl pthread '
-A ccflags=-DSOME_MACRO
--- parrot-current/config/init/hints/darwin.pm 2009-02-01 20:44:27.0
-0500
+++ parrot-andy/config/init/hints/darwin.pm 2009-02-17 09:55:39.0
-0500
@@ -55,20 +55,6 @@
ld_load_flags = '-undefined dynamic_lookup -bundle',
memalign= 'some_memalign',
has_dynamic_linking = 1,
-
-# RT 43147: When built against a dynamic libparrot,
-# installable_parrot records the path to the blib version
-# of the library.
-
-parrot_is_shared = 1,
-libparrot_shared = 'libparrot.$(SOVERSION)$(SHARE_EXT)',
-libparrot_shared_alias = 'libparrot$(SHARE_EXT)',
-rpath = -L,
-libparrot_soname = -install_name
-. $lib_dir
-. $conf-data-get('slash')
-. libparrot
-. $conf-data-get('share_ext')
);
}
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: [perl #47940] [CAGE] mk_native_pbc stale
2009/2/9 Andrew Dougherty dough...@lafayette.edu:
--- tools/dev/mk_native_pbc (revision 36480)
+++ tools/dev/mk_native_pbc (working copy)
@@ -1,32 +1,130 @@
#!/bin/sh
-# generate t/native_pbc_{1,2}.pbc
-# this should be run on i386 systems to regenerate the first two
-# native tests
-# NOTE: This will need a perl compiled with long double support
+# generate t/native_pbc/_{1,2}.pbc
Actually, that hasn't been true for a while.
perl Configure.pl --floatval='long double'
should be all that is needed. I do note, however, that this will
pick the wrong printf format string for floats. The patch in TT #294
fixes that.
I saw that fix.
On cygwin the old comment is true. cygwin perl supports no hugefloat
(long double),
but use64bitint, and perl Configure.pl --floatval='long double' fails in JIT.
src/jit/i386/core.jit:921:75: macro emitm_fldt requires 6
arguments, but only 5 given
perl Configure.pl --floatval='long double' --jitcapable=0 passes.
But on various linux packages it works. I special cased cygwin in
mk_native_pbc,
also because of use64bitint.
--
Reini
Re: [perl #58034] [TODO] save config_args for make reconfig
2009/2/6 James Keenan via RT parrotbug-follo...@parrotcode.org: On Thu Feb 05 01:38:19 2009, rurban wrote: On Tue Jan 13 17:19:39 2009, allison wrote: Ticket rejected, no on automatic reconfiguration. Consult with jkeenan on storing configuration args. Attached patch gets the subject right, make reconfig works now by properly storing and quoting the Configure.pl args. jkeenan, can you please sign this off? If I understand the patch correctly, your objective is simply to find a quick way to repeat Parrot configuration with the same command-line options that you most recently used. If so, then I wonder why you are using 'make clean' instead of 'make realclean'. We've always said that 'make clean' undoes the effect of 'make', whereas 'make realclean' undoes the effect of both 'perl Configure.pl' and 'make'. So I don't know why you aren't using 'make realclean' here. I've changed it to make realclean as discussed on irc. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #58034] [TODO] save config_args for make reconfig
2009/2/6 Reini Urban rur...@x-ray.at: 2009/2/6 James Keenan via RT parrotbug-follo...@parrotcode.org: If so, then I wonder why you are using 'make clean' instead of 'make realclean'. We've always said that 'make clean' undoes the effect of 'make', whereas 'make realclean' undoes the effect of both 'perl Configure.pl' and 'make'. So I don't know why you aren't using 'make realclean' here. I've changed it to make realclean as discussed on irc. This time with attachment, sorry. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ 58034-config_args.patch Description: Binary data
Re: [perl #62204] Errors reported by mingw32-make
2009/1/11 via RT Alan Rocker parrotbug-follo...@parrotcode.org: # New Ticket Created by Alan Rocker # Please include the string: [perl #62204] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=62204 (On Windows XP Home) after mingw32-make realclean and Configure.pl STDERR output attached There are no errors, just harmless warnings. Ticket can be closed
Re: [perl #62206] Errors reported by mingw32-make test
2009/1/11 via RT Alan Rocker parrotbug-follo...@parrotcode.org: # New Ticket Created by Alan Rocker # Please include the string: [perl #62206] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=62206 Under Windows (XP Home) Strawberry Perl Attached are STDERR output and the summary of STDOUT. (I assume that failures with TODO attached are already reported.) The two t/pmc/complex.t tests fixed with r35429. The one # Failed test 'I/O buffering' # at t/pmc/io.t line 434. I cannot reproduce. Looks like a perl5 PERLIO issue to me. Maybe we should set this env in these tests.
Re: [perl #40817] [TODO] track generated files during the configure/make process
2008/12/30 James Keenan via RT: On Tue May 06 17:56:23 2008, jk...@verizon.net wrote: No. I only figured out how to keep track of files generated during configuration, not during build. We need some of what, IIRC, particle termed makefile trickery to keep track of files generated by make. I'm going to relinquish this ticket and give it to Nobody because I frankly don't have any good ideas on the 'makefile trickery' required to identify all the files generated during the build process. makefile trickery could be a simple echo $(filename) [bla] MANIFEST.generated which is platform independent. It even works on windows plain. But most of the examples can be generated more easily during the build step by better utils. Examples are arch specific library names and extensions, now in MANIFEST.generated. But this sucks. E.g. blib/lib/libparrot.so.0.8.2 [main]lib has to be fixed on every VERSION bump. runtime/parrot/dynext/perl6_group.bundle [library] runtime/parrot/dynext/perl6_group.dll [library] runtime/parrot/dynext/perl6_group.dylib [library] runtime/parrot/dynext/perl6_group.so [library] can be collapsed on the actual platform. Also the generated ops for each core can be added during the build step. runtime/parrot/dynext/wmls_ops.dll[library] runtime/parrot/dynext/wmls_ops_cg.dll [library] runtime/parrot/dynext/wmls_ops_cgp.dll[library] runtime/parrot/dynext/wmls_ops_switch.dll [library] All the perl6 ops e.g. are currently missing and are therefore not installed in trunk. (fixed in pdd30install_stage3) I'll work on that in the pdd30install_stage3 branch since it's only needed for make install. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #40817] [TODO] track generated files during the configure/make process
Can you assign it to me? 2008/12/30 Reini Urban rur...@x-ray.at: 2008/12/30 James Keenan via RT: On Tue May 06 17:56:23 2008, jk...@verizon.net wrote: No. I only figured out how to keep track of files generated during configuration, not during build. We need some of what, IIRC, particle termed makefile trickery to keep track of files generated by make. I'm going to relinquish this ticket and give it to Nobody because I frankly don't have any good ideas on the 'makefile trickery' required to identify all the files generated during the build process. makefile trickery could be a simple echo $(filename) [bla] MANIFEST.generated which is platform independent. It even works on windows plain. But most of the examples can be generated more easily during the build step by better utils. Examples are arch specific library names and extensions, now in MANIFEST.generated. But this sucks. E.g. blib/lib/libparrot.so.0.8.2 [main]lib has to be fixed on every VERSION bump. runtime/parrot/dynext/perl6_group.bundle [library] runtime/parrot/dynext/perl6_group.dll [library] runtime/parrot/dynext/perl6_group.dylib [library] runtime/parrot/dynext/perl6_group.so [library] can be collapsed on the actual platform. Also the generated ops for each core can be added during the build step. runtime/parrot/dynext/wmls_ops.dll[library] runtime/parrot/dynext/wmls_ops_cg.dll [library] runtime/parrot/dynext/wmls_ops_cgp.dll[library] runtime/parrot/dynext/wmls_ops_switch.dll [library] All the perl6 ops e.g. are currently missing and are therefore not installed in trunk. (fixed in pdd30install_stage3) I'll work on that in the pdd30install_stage3 branch since it's only needed for make install. I took the task and wrote it. In the makefiles are now various lines such as $(PERL) -Ilib -MParrot::BuildUtil -e add_to_generated $@,[main],bin add_to_generated() also includes the manifest logic for windows. I'll try now to get all the currently MANIFEST.generated files into this, so we don't accidently loose some files again (being installed). patch comes this evening. I will apply to pdd30install_stage3 also. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[Fwd: Perl compiler]
FYI: Another perl5-parrot is in the works. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ ---BeginMessage--- Hi, I saw your post on use.perl about B::C and B::CC. Near the bottom you mention: We might want to convert perl5 to various other formats, such as native code (JIT), perl6 or PIR, but maybe also to java, LISP, scheme, and compile this then to fast native and optimized code. I am currently toying with that; the result is available at https://github.com/mbarbon/language-p/tree At the moment there is a Perl5-on-Perl5 compiler and the beginnings of a parrot backend, but I want to add more as time permits (Java, .Net and LLVM are top of the list). It is definitely not ready for use, but I hope you can take some ideas/code from there. If not, sorry for the wasted time and the unsolicited email. Best regards, Mattia ---End Message---
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
2008/11/17 Andrew Dougherty [EMAIL PROTECTED]: On Sun, 16 Nov 2008, chromatic via RT wrote: Storable 2.18 required in r32744, which should resolve this issue. But the ultimate problem was that the issue was an unnecessary hurdle. At the time of the bug report, I tried building with Storable-2.12 and with 2.18 and observed *no difference*. That means that Storable-2.13 wasn't really *required* at all. I agree that explicitly requiring 2.18 early on gives a failure with a clear error message right away, which is definitely much better than getting a failure a long time after you've started the process and walked away. It's just that no failure is necessary at all. 2.12 worked just fine for parrot. 2.12 only works okay for a newer perl 5.8.6. 5.8.4 fails for sure, and I forgot if it was 5.8.6, which fixed overloading in CORE. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #60098] [BUG] load_bytecode couldn't find file 'P6object.pbc'
2008/10/27 Patrick R. Michaud [EMAIL PROTECTED]: On Sat, Oct 25, 2008 at 06:50:29AM -0700, François PERRAD via RT wrote: In fact, perl6.exe contains some dependencies on build tree. Just after a build, perl6.exe works : This is a known item -- see line 32 of languages/perl6/README: This binary executable feature is still somewhat experimental, and may not work on all platforms. Also, the binary has hardcoded paths to the Parrot build tree (especially the dynamic libraries and modules), so removing the build tree will cause the binary to stop working. We're not likely to do anything about this until Parrot installation is handled properly. I couldn't find a unique ticket for that issue -- when we find or create such a ticket we should probably list this ticket as a dependency on that. In the meantime, I'm marking this ticket as stalled. I would say, RT #56996 fhs-runtime solves that. I'm still away from home, but will come back this weekend and try to prepare the merge of my pdd30_install branch. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #58988] [RFC] Parrot_get_runtime_prefix function
2008/9/17 via RT NotFound [EMAIL PROTECTED]: # New Ticket Created by NotFound # Please include the string: [perl #58988] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58988 The Parrot_get_runtime_prefix in src/library.c return a char *, forcing the places that currently uses it to be more complicated than desired for no real gain. I added and used a STRING * variant named Parrot_get_runtime_path (that name makes more sense to me) in r31216 prefix is the critical config entry which defines the root for the various library searches. And this is the only part which is changed for installables And runtime_prefix defines the prefix to the runtime. This name makes a lot of sense. path is something different. There are three paths after the prefix, not one. I recommend to keep the old name. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #58852] [PATCH] enhance tools/install/smoke.pl
2008/10/18 François PERRAD via RT [EMAIL PROTECTED]: I am not really happy with this patch. Perhaps my initial goal with the script tools/install/smoke.pl wasn't well-known and/or understood. Its main use case is : - a Windows user (without parrot dev tree) downloads and installs the setup of a monthly release. - he runs this script in order to check the result of its installation. - (or I ask him to run it when he tell me that he has a problem). So this script must be *shipped* and it's the reason why I creat the directory tools/install and put it in. The second use case is when I prepare the Windows setup with http://parrotwin32.wiki.sourceforge.net/LaRecetteDuChef So, I agree to add some CLI options, but not to add dependence on specific Parrot-dev Perl modules. The following patch restores the initial behavior and preserves some CLI options. So you want the required dependency to the Parrot::Config and Parrot::Test modules to be gone. I'll make them optional. So you can use it outside a devel installation and I can use it with a (optional) devel installation. But I cannot write the patch right now, as I'm still far away from home and enough time. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [svn:parrot] r31791 - trunk/t/pmc
2008/10/8 jerry gay [EMAIL PROTECTED]: On Wed, Oct 8, 2008 at 1:59 PM, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Oct 08, 2008 at 01:48:17PM -0700, chromatic wrote: In general, filesystems are case-insensitive, not platforms. I believe Mac OS X's Hateful File System Plus is one offender, though you can use UFS instead. HFS+ itself can be set to case sensitive. I have a machine partitioned so that it has a case sensitive partition, as well as a boot partition with the default. I have no idea whether NTFS can be set to case sensitive. I wouldn't be surprised if it can, and that that would thoroughly surprise most programs :-) Likewise, *nix can mount file systems from machines that are not case sensitive. You just can't know. i believe ntfs 5.0 can be set case sensitive--i haven't been crazy enough to try. give me a method of detecting the file system upon which these tests are running, and i'll give you a box of doughnuts. i might even modify the test. ~jerry I've added those tests for cygwin and MSWin32 to blead perl recently. See perl-current\lib\File\Spec\Win32.pm: case_tolerant() Cygwin case-tolerance depends on managed mount settings and as with MSWin32 on GetVolumeInformation() $ouFsFlags == FS_CASE_SENSITIVE, indicating the case significance when comparing file specifications. Since XP FS_CASE_SENSITIVE is effectively disabled for the NT subsystem. See http://cygwin.com/ml/cygwin/2007-07/msg00891.html; -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #59600] [PATCH] Require Storable 2.13 indirectly by requiring perl 5.8.6
2008/10/4 James Keenan via RT [EMAIL PROTECTED]: On Fri Oct 03 08:55:12 2008, coke wrote: This is a patch-response to r31585, which required a particular version of Storable in one file. Attached, find a patch which bumps our core perl requirement to 5.8.6, the first time this particular version of Storable was included as a core module (`corelist -a Storable`). It: [snip] We've been talking about doing this bump to avoid this problem for some time. I'd rather fail during the initial attempt to run configure than have someone with 5.8.0 -then- fail by missing the Storable requirement below. I recall some discussion about going to 5.8.4 -- but not 5.8.6. 5.8.4 is the level of Perl included in many distributions such as Debian. Are you really sure you want to go to 5.8.6 just for one module? Why not require that version of Storable directly? I'm the one who did the change to force a better error message if lower than Storable 2.13 As I recall 5.8.4 adds the core overload support so that Storable-2.13 or greater works. But I'm not sure on my laptop and on my trip I have only limited ressources to check it out again. Tying down the specific perl version would be of course better in the discussed patch, but removing my patch will not help. Storable-2.13 is still required and should be marked as such. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: Revisiting lexicals, part 1
2008/9/24 Patrick R. Michaud [EMAIL PROTECTED]: So, in order to get the behavior you're describing from the interactive prompt, we'll probably need more than just Perl 6's 'eval'. In particular, the interactive prompt mode will need to be able to maintain it's own dynamic lexical pad (i.e., a DynLexPad) and have some way of extracting any lexical changes from whatever code string it evaluates. I wouldn't call them DynLexPad or lexicals at all, I would call them just globals. lexvars could shadow them though, but this a user problem then. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: Parrot 0.7.1 Manu Aloha released
2008/9/17 Patrick R. Michaud [EMAIL PROTECTED]:
On Wed, Sep 17, 2008 at 08:08:47PM +0200, Reini Urban wrote:
http://www.parrotcode.org/release/devel still points to 0.7.0
I sent the appropriate patch to the webmaster, but it hasn't
been applied yet (and I lack a commit bit for the parrotcode.org site).
Once that's applied, the url should be fixed.
FYI:
I thought the best generic method to get the latest release URI should be
SRC_URI=$(lwp-request -m HEAD -x -e
http://www.parrotcode.org/release/devel; 21 | \
grep /authors/id | tail -n1 | perl -ane 'print $F[2]')
The authors id changes in the uri below with every release:
http://search.cpan.org/CPAN/authors/id/P/M/PMIC/parrot-${PV}.tar.gz
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: Parrot 0.7.1 Manu Aloha released
http://www.parrotcode.org/release/devel still points to 0.7.0 -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #58938] [BUG] src/string.c:2241: failed assertion '(s)-encoding'
2008/9/16 via RT Reini Urban [EMAIL PROTECTED]:
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58938
If you don't spot the error immediately, here's a hint:
#5 0x639518e0 in pmc_type () from /usr/bin/cygparrot0_7_0.dll
wrong lib. caused by what?
the lib should be called
/usr/src/parrot/parrot-svn/blib/lib/libparrot.dll but an installed
only config lib and /bin/parrot points to this new name: cygparrot0_7_0.dll
So it's related to the RT#39742 installed-conflict bug, but
I keep this ticket open for this subtle problem until I find the
reason for the mismatch after loadlib.
Since a few days loadlib initialization causes an
src/string.c:2241: failed assertion '(s)-encoding'
See http://nopaste.snit.ch/14072
gdb backtrace:
src/string.c:2241: failed assertion '(s)-encoding'
$ cat encoding-bug.pir
loadlib 'rotest'
$ gdb ./parrot encoding-bug.pir
(gdb) s
Breakpoint 7, string_hash (interp=0x1ef2328, s=0x1f41278, seed=3793)
at src/string.c:2241
2241saneify_string(s);
(gdb) p *s
$1 = {cache = {_b = {_bufstart = 0x69205def, _buflen = 6}, _ptrs = {
_struct_val = 0x69205def, _pmc_val = 0x6}, _i = {_int_val = 1763728879,
_int_val2 = 6}, _num_val = 1.3603372593483627e-313,
_string_val = 0x69205def}, flags = 405760, strstart = 0x69205def ROTest,
bufused = 6, strlen = 6, hashval = 0, encoding = 0x0, charset = 0x0}
(gdb) bt
#0 string_hash (interp=0x1ef2328, s=0x1f41278, seed=3793) at
src/string.c:2241
#1 0x66fa9aa3 in key_hash_STRING (interp=0x1ef2328, s=0x1f41278, seed=3793)
at src/hash.c:153
#2 0x66faaa5e in parrot_hash_get_bucket (interp=0x1ef2328, hash=0x1f6ce88,
key=0x1f41278) at src/hash.c:1093
#3 0x66faaaef in parrot_hash_get (interp=0x1ef2328, hash=0x1f6ce88,
key=0x1f41278) at src/hash.c:1123
#4 0x67166491 in Parrot_NameSpace_get_pointer_keyed_str (interp=0x1ef2328,
pmc=0x1f67d48, key=0x1f41278) at ./src/pmc/namespace.pmc:434
#5 0x639518e0 in pmc_type () from /usr/bin/cygparrot0_7_0.dll
#6 0x63951971 in pmc_register () from /usr/bin/cygparrot0_7_0.dll
#7 0x69203d6a in Parrot_lib_rotest_load (interp=0x1ef2328) at ./rotest.c:1166
#8 0x66f9c9ee in Parrot_init_lib (interp=0x1ef2328,
load_func=0x69203d20 Parrot_lib_rotest_load, init_func=0)
at src/dynext.c:317
#9 0x66f9cb21 in run_init_lib (interp=0x1ef2328, handle=0x6920,
lib_name=0x20e4b78, wo_ext=0x20e4b78) at src/dynext.c:384
#10 0x66f9d0d9 in Parrot_load_lib (interp=0x1ef2328, lib=0x1f412a0,
initializer_unused=0x0) at src/dynext.c:583
#11 0x671a7f46 in do_loadlib (interp=0x1ef2328, lib=0x21066f8 'rotest')
at compilers/imcc/imcc.y:602
#12 0x671a8d0b in yyparse (yyscanner=0x20f2078, interp=0x1ef2328)
at compilers/imcc/imcc.y:737
#13 0x671b5281 in compile_to_bytecode (interp=0x1ef2328,
sourcefile=0xc3cce4 encoding-bug.pir, output_file=0x0)
at compilers/imcc/main.c:955
#14 0x671b562c in imcc_run (interp=0x1ef2328,
sourcefile=0xc3cce4 encoding-bug.pir, argc=1, argv=0x1ef213c)
at compilers/imcc/main.c:1058
#15 0x00401120 in main (argc=1, argv=0x1ef213c) at src/main.c:61
(gdb)
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: [svn:parrot] r31094 - branches/cygwin070patches/runtime/parrot/include
chromatic schrieb: On Saturday 13 September 2008 15:58:20 [EMAIL PROTECTED] wrote: Author: rurban Date: Sat Sep 13 15:58:20 2008 New Revision: 31094 Modified: branches/cygwin070patches/runtime/parrot/include/test_more.pir Log: adopt pdd30 --- branches/cygwin070patches/runtime/parrot/include/test_more.pir (original) +++ branches/cygwin070patches/runtime/parrot/include/test_more.pir Sat Sep 13 15:58:20 2008 @@ -11,7 +11,7 @@ =cut -load_bytecode 'runtime/parrot/library/Test/More.pbc' +load_bytecode 'Test/More.pbc' # get the testing functions .local pmc exports, curr_namespace, test_namespace Why are all these commits in the Cygwin patches branch? Is this specific to Cygwin? Almost nothing in this branch is specific to the cygwin architecture. Everything is specific to pdd30_install plus the new language jvm. I didn't came up with this name. It was choosen probably because the cygwin 0.7.0 release came with all this patches. Rationale: runtime/parrot/library is not valid in an installed parrot. So this path prefix is useless and wrong when installed. It should even be load_bytecode 'Test/More', but there's a bug in load_bytecode, which loads a pbc as pir if the ext is not defined. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
revert r31101
http://www.parrotvm.org/svn/parrot/revision?rev=31101 by cotto leads to make perl6 ../../parrot.exe /usr/src/perl/parrot/parrot-svn/runtime/parrot/library/PGE/Perl6Grammar.pbc \ --output=src/gen_grammar.pir \ src/parser/grammar.pg src/parser/grammar-oper.pg ../../parrot.exe /usr/src/perl/parrot/parrot-svn/compilers/nqp/nqp.pbc --output=src/gen_actions.pir \ --encoding=fixed_8 --target=pir src/parser/actions.pm Null PMC access in get_bool() current instr.: 'parrot;NQP::Grammar::Actions;routine_def' pc 33982 (src/Grammar/Actions.pir:403) called from Sub 'parrot;NQP::Grammar;routine_def' pc 20036 (src/Grammar_gen.pir:7553) called from Sub 'parrot;NQP::Grammar;noun' pc 25828 (src/Grammar_gen.pir:9806) called from Sub 'parrot;NQP::Grammar;term' pc 22730 (src/Grammar_gen.pir:8622) called from Sub 'parrot;PGE::OPTable;parse' pc 1959 (compilers/pge/PGE/OPTable.pir:554) called from Sub 'parrot;NQP::Grammar;statement' pc 7269 (src/Grammar_gen.pir:2617) called from Sub 'parrot;NQP::Grammar;statement_list' pc 3399 (src/Grammar_gen.pir:1204) called from Sub 'parrot;NQP::Grammar;statement_block' pc 2898 (src/Grammar_gen.pir:1013) called from Sub 'parrot;NQP::Grammar;package_declarator' pc 27585 (src/Grammar_gen.pir:10474) Also reported on #parrot. Please revert or fix this -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: revert r31101
Reini Urban schrieb: http://www.parrotvm.org/svn/parrot/revision?rev=31101 by cotto leads to make perl6 Null PMC access in get_bool() Fixed with 31108. Reverted src/pmc/resizablepmcarray.pmc and src/pmc/resizablestringarray.pmc perl6 works now again, but the problem is probably elsewhere. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
2008/6/22 jerry gay [EMAIL PROTECTED]: On Sun, Jun 22, 2008 at 3:38 AM, Bernhard Schmalhofer [EMAIL PROTECTED] wrote: James Keenan via RT schrieb: On Fri Jul 13 09:58:33 2007, bernhard wrote: There are several config probes that are only used for language implementations. Examples are config/auto/m4.pm and config/auto/python.pm. Please find attached two files. The first greps the repository for mentions of 'm4'. The second is a patch which eliminates config/auto/m4.pm and the associated test file and updates the MANIFEST. Configure.pl, make and make test all perform without error after this config step is eliminated. When I switch into languages/m4, then call 'make' and 'make test', I get the same test failures in t/regex/002_tokens.t either way. So my belief is that removing this step causes no harm to the m4 language implementation itself. I will apply this patch to trunk in about 2 days if there is no objection. Thank you very much. kid51 AFAIK 'languages/m4/config/makefiles/root.in' is the only place where the config entry 'has_gnu_m4' is used. It is meant as a doublecheck of the 'm4' tests. If 'GNU m4' is available then the m4 tests should be run with 'GNU m4' as well. This should make sure that the Parrot implementation behaves the same way as the reference implementation. So 'has_gnu_m4' is not essential to the implementation of 'Parrot m4'. In r28633 I removed the use of 'has_gnu_m4' and the config step auto::m4.pm can now be removed. But the real scope of ticket RT#43857 is something different. Language implementations may need config probes that are only relevant for that particular language. Therefore there should be some kind of infrastructure set up, so that those probes can be placed within the language dir. Taking 'Plumhead' as an example, I would have liked to set up probes checking for 'phc', 'antlr' and 'xsltproc'. I didn't do so because I didn't want to clutter the Parrot config. languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. should follow that model. if there are things that can be done to make the process of developing a language-specific configure engine easier, i'd love to hear them. I outlined a Parrot/Install core library for library/languages support in the latest pdd30_install draft. For me a language is nothing more than a parrot library. The languages soon need their own Configure/Makefile support, when core throws them out. It could be driven with a perl5 lib/Parrot/Install.pm library for now, and later with runtime/parrot/library/Parrot/Install.pir or a perl6 library, which should do something along the lines of ExtUtils::MakeMaker. Frontend: parrot Makefile.pir loads Parrot/Install and defines the Makefile methods and properties, with the possibility to start a seperate configure step to check for external bins, libs and headers. RunConfigure() WriteMakefile() Defining the hash entries for the subs in PIR syntax is awful. So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. For p6 we must ensure that every parrot package has a perl6 also then. Not good. So pl, pir or the simple nqp. -- Reini
Re: [perl #57530] Fwd: Parallelize the Perl 6 tests
2008/9/11 James Keenan via RT [EMAIL PROTECTED]: Moritz, I applied parallel-r.patch to trunk at r30978 on Darwin (10.4 PPC), successfully built and tested Parrot, built Perl 6, then got the results below out of 'make test'. Since I build and test Perl 6 infrequently, I'm not sure whether these results are different from what I would have gotten without the patch applied. But everything passed! Wrong make target. You have to run $ cd languages/perl6 $ make spectest_regression to test this patch and the speed difference. Thank you very much. kid51 /usr/local/bin/perl t/harness t/00-parrot t/01-sanity t/00-parrot/01-literalsok t/00-parrot/02-op-math.ok t/00-parrot/03-op-logicok t/00-parrot/04-op-cmp..ok t/00-parrot/05-var-array...ok t/00-parrot/05-var.ok t/00-parrot/06-op-inplace..ok t/00-parrot/07-op-string...ok t/00-parrot/08-regex...ok t/01-sanity/01-tap.ok t/01-sanity/02-counter.ok t/01-sanity/03-equal...ok t/01-sanity/04-if..ok t/01-sanity/05-sub.ok t/01-sanity/06-use.ok t/01-sanity/07-binding.ok t/01-sanity/07-defined.ok t/01-sanity/07-end-blocks..ok t/01-sanity/07-for.ok t/01-sanity/07-isa.ok t/01-sanity/07-range...ok t/01-sanity/07-ref.ok t/01-sanity/07-simple-multisubsok t/01-sanity/07-split...ok t/01-sanity/07-substr..ok t/01-sanity/07-try.ok t/01-sanity/08-say.ok t/01-sanity/09-types...ok All tests successful. Files=28, Tests=232, 82 wallclock secs ( 0.36 usr 0.29 sys + 71.43 cusr 6.98 csys = 79.06 CPU) Result: PASS prove t/pmc t/pmc/mutable...ok t/pmc/mutablevarok t/pmc/perl6multisub-arity...ok t/pmc/perl6multisub-basic...ok t/pmc/perl6multisub-tiebreakok t/pmc/perl6multisub-typeok All tests successful. Files=6, Tests=39, 8 wallclock secs ( 0.10 usr 0.08 sys + 6.45 cusr 1.21 csys = 7.84 CPU) Result: PASS make -C /Users/jimk/work/parrot codetest /usr/local/bin/perl t/harness --gc-debug --running-make-test --code-tests t/distro/file_metadata.# Collecting svn:mime-type attributes... t/distro/file_metadata.1/5 # Collecting svn:keywords attributes... t/distro/file_metadata.3/5 # Collecting svn:eol-style attributes... t/distro/file_metadata.4/5 # Collecting svn:eol-style attributes... t/distro/file_metadata.ok t/codingstd/c_code_codaok t/codingstd/c_cppcomments..ok t/codingstd/c_header_guardsok t/codingstd/c_indent...ok t/codingstd/c_macro_args...ok t/codingstd/c_operator.ok t/codingstd/c_parens...ok t/codingstd/c_returns..ok t/codingstd/c_struct...ok t/codingstd/check_isxxxok t/codingstd/check_toxxxok t/codingstd/copyright..ok t/codingstd/cuddled_else...ok t/codingstd/filenames..ok t/codingstd/gmt_utcok t/codingstd/linelength.ok t/codingstd/pccmethod_deps.ok t/codingstd/pdd_format.ok t/codingstd/perlcritic.ok t/codingstd/pir_code_coda..ok t/codingstd/svn_id.ok t/codingstd/tabs...ok t/codingstd/trailing_space.ok All tests successful. Files=24, Tests=374, 960 wallclock secs ( 0.64 usr 0.37 sys + 628.56 cusr 28.01 csys = 657.58 CPU) Result: PASS -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #53682] [CAGE] Visual Studio compiler for parrot
2008/9/11 Will Coleda [EMAIL PROTECTED]: On Wed, Sep 10, 2008 at 10:56 PM, James Keenan via RT [EMAIL PROTECTED] wrote: Coke, particle: Can we get an update on the issues raised in this RT? 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? Yesterday I did a MSVC attempt with a mingw perl, which I described in cygwin070patches/README_win23.pod = If you want to use MSVC with a mingw-gcc perl you can use C--cc=cl --link=link. Just Far in Fconfig_lib.pasm has to be changed to Flib and CLIBPARROT = $(LIBPARROT_STATIC) in FMakefile. Today I tested mingw fully and found only minor issues in some languages not finding @build_dir@/libparrot.dll (well, perl6 is also involved :) and I hope to patch it away soon. MSVC with ActivePerl will be the next attempt today or tomorrow. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[PATCH] added links to dotnet/doc/contents.pod
Attached patch adds links to external dotnet ressources Jonathan mentioned (his paper, the specs), and the implementations. Jonathan should approve it because it links to a bad poem on VM's in his paper on page 1. No ticket because it's so simple. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ dotnet-links.patch Description: Binary data
[PATCH] cygwin070patches_10
My daily cygwin070patches branch patch for my dear friend moritz. Today on the menu: * Fix hard tabs in languages/tcl/lib/Tcl/Test.pm from yesterday * overhaul dotnet Configure + make * add current novell mono path to dotnet test -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_10.patch.gz Description: GNU Zip compressed data
[PATCH] cygwin070patches_9
for the cygwin070patches branch: * fix a perlcritic test for Compiler.pm * add DESTDIR to languages make install and test-installable * fix forth and tcl build/installed seperation and fixed pbc destination paths * make builds the default targets, all builds all. * fix wrong #ELSEIF to #ELSIF in language makefiles -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_9.patch.gz Description: GNU Zip compressed data
[PATCH] cygwin070patches
Attached is a new patch for the cygwin070patches. This is against svn, so it replaces the patches _6 and _7. Fixed some logical flaw and enhanced the Makefiles. Renamed TMP to HLLNAME. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_8.patch.gz Description: GNU Zip compressed data
Re: [PATCH] cygwin070patches_6+7.patch
Allison Randal schrieb: Reini Urban wrote: A new idea: === #IF(darwin): #ALSO:# MACOSX_DEPLOYMENT_TARGET must be defined for OS X #ALSO:export MACOSX_DEPLOYMENT_TARGET := @osx_version@ Just a little too much complexity, for not enough benefit. The POD for this change: Looks good. For legacy the old syntax #CONDITIONED_LINE(var): and #INVERSE_CONDITIONED_LINE(var): is also supported. Mention that this syntax will be deprecated. For lispers the well-known reader-macro syntax #+(and key1 (not key2)): is also supported, #+ #- with and, or and not, or being the default for multiple keys without operator. But note the ending C:. This syntax is not supported. The primary reason for rejecting the syntax is because it's too much of a burden on maintainers. If we keep the feature someone will certainly use it, and some poor P-language programmer is going to get stuck trying to decipher it. I hope you know that this #+() syntax is the only existing syntax. It is widely used since about 20 years. The rest is something new we came up with. I deleted it. Sigh. * or a key=value expression, which checks for the config key, Note that values may contain no spaces here. Quotes in values are not supported. Seems like a sensible addition, though very limited. Make it '==' instead of '='. A key must only consist of word characters, and is checked case-sensitively against the config key or the platform name. Explicitly say what you mean by word characters, because different languages treat different characters as word forming. If you mean A-Z, a-z, and 0-9, say so. Ok, the cygwin070patches_7.patch includes all of these suggestions. There's still a parser problem with some obscure logic, which I have to fix. See the TODO tests. First I want cygwin070patches_6.patch to be applied, then this patch cygwin070patches_7.patch. ChangeLog for 7. For 6 see other mail: applied Allisons suggestions for key==value, doc improvements, removed lisp-style, more tests, and detected some TODO cases. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_6.patch.gz Description: GNU Zip compressed data cygwin070patches_7.patch.gz Description: GNU Zip compressed data
pdd30_install
[Subject changed to pdd30_install, as we are talking about this the whole time] Allison Randal schrieb: Will Coleda wrote: At the moment I'm planning for language pbcs to go into .../parrot/library/ so they can be easily accessed via load_bytecode. I've found that in a dynamic environment like Parrot there's very little difference between a language and a library [1]. :-) That's probably the best, but we can also think of not installing that at all, and only install executables. But then the new pddxx_language_interop.pod at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded from other languages, only pbc's. Right. We have to (eventually) install the pbcs, no matter if we also install the exes for convenience. Yes. And the exes (or aliases to the parrot exe) should go in the same bin directory as parrot. Problem: Most packages will not accept packages with /usr/bin/scheme, /usr/bin/lisp, /usr/bin/forth, /usr/bin/lua, /usr/bin/tclsh were these are the parrot implementations. So most packages use the parrot- prefix for all language installables, the pbc is without this prefix. With fedora and cygwin, the rest does not install language installables yet. Current exceptions for the parrot- prefix: perl6 Future possible exceptions: cardinal, chitchat, cola, eclectus, pheme, pynie, punie, squaak (wise choice in the names) For consistency I would suggest to introduce no such exceptions, besides perl6. But this is just a personal favor. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd30_install
2008/8/29 Allison Randal: Reini Urban wrote: Current exceptions for the parrot- prefix: perl6 Actually, that probably won't be an exception to the parrot- prefix on the package name, since there are multiple implementations of Perl 6. Ok, so there will be pugs, perl -Mv6 and rakudo | parrot-perl6 Maybe both /usr/bin/rakudo and /usr/bin/perl6 should be symlinked to /usr/bin/parrot-perl6 then. Currently there's only a /usr/bin/perl6 being installed. This really should be made ready for the September release. Again, it should be a configuration option to install aliases for executables with the language nicknames. Not a requirement for the packaged versions, but the $0 handling will be built in to Parrot, so the user could also easily create their own 'ln -s' aliases. Good idea. Within the PCT::HLLCompiler I assume. So the few languages which are not based upon PCT::HLLCompiler will need some minor trickery. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
general rant over older days
2008/8/29 Will Coleda [EMAIL PROTECTED]: On Fri, Aug 29, 2008 at 11:56 AM, Allison Randal [EMAIL PROTECTED] wrote: Reini Urban wrote: I hope you know that this #+() syntax is the only existing syntax. It is widely used since about 20 years. The rest is something new we came up with. It's high time for a little progress. Sheesh, in 1988 we were excited by computers with 1 MB of RAM. ;) Allison Progress is nice, but there is no need for us to re-invent *every* wheel for this project. And I'm tempted to add: Actually even the 1984 version of lisps are still technically and syntax-wise far advanced over the perl and parrot state of today. I see not much of a progress. perl5 even lost undump around that time and the perl compiler was axed last year. Even then I could connect to my life and running lisp image, inspect the variables with all its state and type, and not just staring at hexdumps or intermediate VM ops, test and fix a bug, recompile a function on the fly and saving away an image while the whole image was still running. Zero downtime. Others are now profiling their dynamic compilers [1] and optimizers[2], we are still and again struggling with the basics. At least we have a tri-color generational GC (from 1975 [3]) and not Mark Sweep soon, but I'm not sure if the GC with external objects (nci) is solvable when live PMCs will be allowed to move. Just to make it faster. http://www.memorymanagement.org/news/history.html Nevertheless I do prefer the dirty state of today over the perfect state from ancient times. CPU get faster and cheaper. HDs get bigger. And MSVC supports now almost dynamic recompilation and the stabs can be dumped away. Great. Almost back in the 80-ies. Footnotes: [1] Java and .NET slowly doing now what LISP did in the 90ies. [2] http://hg.mozilla.org/tracemonkey (optimize loops dynamically, nice) [3] http://www.memorymanagement.org/bib/f.html#dlmss76 -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: general rant over older days
2008/8/29 chromatic [EMAIL PROTECTED]: On Friday 29 August 2008 10:04:44 Reini Urban wrote: perl5 even lost undump around that time and the perl compiler was axed last year. Economic realities often trump idealism. I'd like to see a working Perl 5 compiler suite as well, but I don't have the time to do it, and no one seems to want to fund it. That state of affairs does not fill me with glee. Works without funds also: http://search.cpan.org/dist/B-C/ Just a few hairy bugs need to be fixed. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/28 Moritz Lenz [EMAIL PROTECTED]: +=head1 DESCRIPTION + +Parrot installation mechanisms are more powerful than perl5's. +MANIFEST contains also the end location, tools/dev/install_files.pl is driven +by this definition. To me it's not clear what the end location is - care to elaborate? The end location by make install is a string concatation of * the $(DESTDIR) as defined per Makefile argument, * plus the respective Configure defined directoy (prefix,bin_dir, lib_dir, include_dir, mandir, doc_dir, ...) where the directores are defined by default to follow the FHS convention and optional Configure.pl arguments, and the files as defined in one of the three MANIFEST files in the format filename \t [package]lib,doc,include,bin - files from the [library] package go to prefix/lib_dir and either dynext, library or include, * plus the filename as defined by the three MANIFEST files. There's additional logic in the tools/dev/install_files.pl script. prefix defaults to /usr/local and packages define them as /usr lib_dir defaults to prefix + /lib and libraries go to parrot/dynext for shared libs (flat) parrot/library for pbc files (structured according to the namespace) parrot/include for pir and pasm files (flat) bin_dir to prefix + /bin doc_dir to prefix + /share/doc/parrot mandir to prefix + /man, but it should be prefix + /share/man according to the FHS include_dir to prefix + /include/parrot pkgconfig_dir to prefix + /lib/pkgconfig What is missing is the end location of language pbc's and installable exe's. The convention by fedora and cygwin for parrot-language installables is $(DESTDIR)@bin_dir@/parrot-$(LANG)@exe@ Open problem: For language pbc's a new dir like script_dir or lib_dir/parrot/bin would be required. They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other pbc's are. The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext for sure. e.g. tclsh.pbc, APL.pbc, ... -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/28 Patrick R. Michaud [EMAIL PROTECTED]:
On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
Open problem:
For language pbc's a new dir like script_dir or lib_dir/parrot/bin
would be required.
They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
pbc's are.
The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext
for sure.
e.g. tclsh.pbc, APL.pbc, ...
I'd be a bit surprised if the .pbc files went into dynext/ -- that doesn't
seem to match what currently exists there (which is all .so files on
my system).
Sure.
My comment about the tclsh.pbc, APL.pbc, ... was referring to the
language pbc's, not to the group and op shared libs.
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
That's probably the best, but we can also think of not installing that at all,
and only install executables. But then the new pddxx_language_interop.pod
at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded
from other languages, only pbc's.
So each language will need its root namespace reserved for it's lang.pbc.
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Also, I wonder if any of this relates to RT #47992 ('parrot foo'
automatically finds and invokes foo.pbc)?
If foo.pbc is in parrot/library/foo.pbc then it will be found.
The pbc library searchpath is only . and @lib_dir@/parrot/library.
Also PARROT_RUNTIME can be defined in ENV to override
the runtime prefix and therefore the library search path..
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] wrote:
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
True, there's no perl -MExtUtils::Command -e ln_s
But we have LN_S = @lns@
Also, I wonder if any of this relates to RT #47992 ('parrot foo'
automatically finds and invokes foo.pbc)?
If foo.pbc is in parrot/library/foo.pbc then it will be found.
The pbc library searchpath is only . and @lib_dir@/parrot/library.
Also PARROT_RUNTIME can be defined in ENV to override
the runtime prefix and therefore the library search path..
I had always thought that the compiler/compreg opcode would eventually
be extended to load the library we needed for language interop; If
not, I'm not sure there's much point in keeping the ability to
register compilers, is there? If someone wants to use the tcl
compiler, they need to know to load the bytecode first anyway.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: gsoc_nci merge
François Perrad schrieb: The following patch adds NCIGEN in the documentation (HTML generated). Note : needs a better title than 'Native Call Interface Generator'. Why? I find it perfect. It makes sense and it even matches the abbrevation. Java: Java native interface code generator www.freepatentsonline.com/6066181.html Native Call Stub Generator
[PATCH] more packages
Will Coleda schrieb: On Sun, Aug 24, 2008 at 12:26 PM, Moritz Lenz [EMAIL PROTECTED] wrote: Reini Urban wrote: 2008/8/23 François Perrad [EMAIL PROTECTED]: 2008/8/23 Allison Randal [EMAIL PROTECTED]: Moritz Lenz wrote: On #perl6 somebody just asked if there were up-to-date windows builds of parrot somewhere, he had googled for 'parrot windows'. The parrotwin32 project didn't show up in his search (but it's first for 'parrot win32'). I think we should improve that situation. Suggestions: 1) A link on http://www.parrotcode.org/source.html Sure. Already done since 2-3 months, see http://www.parrotcode.org/source.html#Packages, but with the word Win32, not Windows. Cygwin is missing there: a href=http://cygwin.com/;Cygwin/a Attached patch adds that. I don't see the source for the webpage, so I can only do the next ones like this: lia href=http://alioth.debian.org/projects/pkg-parrot/;Debian Packages/a/li + lia href=http://www.gentoo-portage.com/dev-lang/parrot;Gentoo/a/li + lia href=http://www.freebsd.org/cgi/ports.cgi?query=parrot;Freebsd/a/li lia href=http://sourceforge.net/project/showfiles.php?group_id=211372;Windows (Win32)/a/li lia href=http://cygwin.com/;Cygwin/a/li -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[PATCH] cygwin070patches_6.patch
Reini Urban schrieb: Moritz Lenz schrieb: Reini Urban wrote: My latest patch against the cygwin070patches branch r30596. And one more. pdd30_install.pod, silence Parrot/Configure/Compiler.pm, more testcases, parrot_config, $(SHRPENV) $(MINIPARROT) for the last missing build problem. Add cardinal arrays and Nil from trunk. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_6.patch.gz Description: GNU Zip compressed data
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Andy Dougherty schrieb:
On Thu, 28 Aug 2008, Reini Urban wrote:
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] wrote:
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
True, there's no perl -MExtUtils::Command -e ln_s
But we have LN_S = @lns@
But that's not necessarily a symbolic link. It was originally intended
only for use with files, not directories. If symlinks aren't available on
Unix, it falls back to a plain 'ln'. On Win32 versions of perl, lns is
usually defined as 'copy'.
So the short answer is that, at the moment, without additional
Configure.pl work, you can't assume $Config{lns} can be used to make
symbolic links for directories.
I only wanted to link the language pbc files from
languages/lang/lang.pbc to runtime/parrot/library/lang.pbc
And only if someone needs it for hll interop testing.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
[PATCH] cygwin070patches_4.patch
My latest patch against the cygwin070patches branch r30596. * Finished implementation of the makefile expansion - perl-style * Changed all relevant makefile templates. make fulltest and make codetest has the same few mt-thread and resume errors as always. A new idea: === #IF(darwin): #ALSO:# MACOSX_DEPLOYMENT_TARGET must be defined for OS X #ALSO:export MACOSX_DEPLOYMENT_TARGET := @osx_version@ The POD for this change: =item conditioned_lines #IF #UNLESS #ELSIF #ELSE If conditioned_lines is true, then several expressions at the first column are evaluated and replaced by the content after the C: dependending on the evaluation of the expression. Lines beginning with C#IF(expr): are skipped if the expr condition is false, otherwise the content after the C: is inserted. Lines beginning with C#UNLESS(expr): are skipped if the expr condition is true. Lines beginning with C#ELSIF(expr): are evaluated if the former C#IF(expr): evaluated to false. Lines beginning with C#ELSE: are evaluated if the former C#IF(expr): or C#ELSIF(expr): evaluated to false. For legacy the old syntax #CONDITIONED_LINE(var): and #INVERSE_CONDITIONED_LINE(var): is also supported. For lispers the well-known reader-macro syntax #+(and key1 (not key2)): is also supported, #+ #- with and, or and not, or being the default for multiple keys without operator. But note the ending C:. A condition expr may be: * a single key, which is true if a config key is true - not 0 and not undef and not an empty string, * or equal to the platform name, the perl5 osname - case-sensitive, * or a key=value expression, which checks for the config key, Note that values may contain no spaces here. Quotes in values are not supported. * or a logical combination of C| (or), C (and) and C! (not), with the following order of precedence: ! | A key must only consist of word characters, and is checked case-sensitively against the config key or the platform name. For instance: #IF(win32): $(SRC_DIR)/atomic/gcc_x86$(O) will be processed if the platform is win32. #IF(cpuarch=i386): $(SRC_DIR)/atomic/gcc_x86$(O) will be skipped if the value of the config key cpuarch is not i386. #IF(cpuarch=i386): $(SRC_DIR)/atomic/gcc_x86$(O) #ELSIF(cpuarch=sparcv9): $(SRC_DIR)/atomic/sparc_v9.s #ELSE: will use $(SRC_DIR)/atomic/gcc_x86$(O) on cpuarch=i386, $(SRC_DIR)/atomic/sparc_v9.s on cpuarch=sparcv9 and print an empty line otherwise. #IF(win32 glut !cygwin): will be used on win32 and if glut is defined, but not on cygwin. The hairy parts from the testsuite == dummy1=true, dummy2=false, dummy3=xx [IF(dummy1!dummy2dummy3),1], [UNLESS(!(dummy1!dummy2dummy3)), 1], [IF(dummy1(!dummy2dummy3)), 1], [IF(dummy1 (dummy3=xx (!dummy2))), 1], -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_4.patch.gz Description: GNU Zip compressed data
[PATCH] cygwin070patches_5.patch
Moritz Lenz schrieb: Reini Urban wrote: My latest patch against the cygwin070patches branch r30596. applied as 30597 Thanks! And one more. Add docs/pdds/draft/pdd30_install.pod Fix bf and tcl makefiles -- Reini Urban http://phpwiki.org/ http://murbreak.at/ Index: docs/pdds/draft/pdd30_install.pod === --- docs/pdds/draft/pdd30_install.pod (revision 0) +++ docs/pdds/draft/pdd30_install.pod (revision 0) @@ -0,0 +1,213 @@ +# Copyright (C) 2008, The Perl Foundation. +# $Id: pdd30_install.pod 30255 2008-08-23 12:15:46Z rurban $ + +=head1 NAME + +docs/pdds/draft/pdd30_install.pod - Parrot Installation + +=head1 ABSTRACT + +This PDD defines Parrot's installation details. The goal is to provide binary +packages, a working Cmake install for parrot, the installables, FHS compliant +search paths for the installables and solving the problem of not accessing +installed source-only files and the optimization of config bootstrapping +if a frozen config_hash is already linked. + +=head1 VERSION + +$Revision: 30459 $ + +=head1 SYNOPSIS + + make install + make test-installable -C language/lang + make installable -C language/lang + make install -C language/lang DESTDIR=inst + +=head1 DESCRIPTION + +Parrot installation mechanisms are more powerful than perl5's. +MANIFEST contains also the end location, tools/dev/install_files.pl is driven +by this definition. +The three runtime paths for include, library for load_bytecode and dynext +for loadlib should end up in the $prefix/lib/parrot paths. +See #56996-fhs-runtime.patch + +Contrary to perl5, parrot and its language implementions on top of parrot may +be installed as self-hosting single-file executables, with the help of merged +pbc's and pbc2exe --install. + +Bootstrapping the config hash should not read a config file when the hash is +already contained in the pmc or executable. See #57418 [TODO] optimize +_config to omit .include library/config.pir on installables. + +The same problem is for every .include, .loadlib and .load_bytecode statement +in installed files where the target is not installed. This could be solved with +a module system or with pbc_merge removing not needed .load_bytecode statements. + +Test executables are binary different to installable executables because of +this embedded config hash. Test executables contain config hash with +the prefix to the build_dir, installables to the given prefix from Configure.pl. + +There are's also a long-standing conflict in building parrot with an already +installed shared libparrot.so. See #39742-installed-conflict.patch which adds +the blib/lib path to PATH resp. LD_RUN_PATH. + +=head1 DEFINITIONS + +An Binstallable is a pbc or exe which must not access the build_dir +paths. The build_dir is not available in a binary package. This is solved by +generating and linking a special Finstall_config.fpmc. Custom python modules +have a similar packaging problem, which they haven't solved yet. + +Bbuild_dir is the full path where parrot was built. It is defined in the +config hash. When building from source build_dir is also the PARROT_RUNTIME prefix. + +BDESTDIR is the end location of the parrot tree in front of the prefix +(/usr or /usr/local). This allows packaging by installing into a seperate +install tree and do a tar cf there. + +The Bconfig hash is the return value of the global function C_config(), +generated in Fconfig_lib.pasm, and either defined in Flibrary/config.pir, or +as frozen pmc embedded in the test executable (Fconfig.fpmc), the installable +executable (Finstall_config.fpmc) or empty for miniparrot (Fnull_config.fpmc). + +=head1 IMPLEMENTATION + +=head2 make install + +The parrot build system is optimized for building and testing in the +build_dir, but not for building with an already installed parrot due to simple +build system bugs, and not optimized to build and test installables, which should +not access the libraries in the build_dir, but in the DESTDIR. + +The goal is to make install work for parrot, the utils, and all the languages. +For parrot and its utils the install actions are defined in the main Makefile, +for the languages the install actions should be defined in its Makefiles and +is implemented in #56554-make-install-lang.patch. + +Cmake install currently does not work with an already installed shared +libparrot.so on most platforms. There's a patch at #39742. + +make install actions for a language lang: + + copy installables to DESTDIR/bin_dir as parrot-lang + optionally copy lang.pbc to DESTDIR/script_dir (/usr/lib/parrot/bin/ ?) + copy libraries to DESTDIR/lib_dir/parrot/dynext/ + optionally copy pbc's to DESTDIR/lib_dir/parrot/library/ (only php_ext) + optionally copy include pasm and pirs to DESTDIR/lib_dir/parrot/include/ (not yet) + copy docs to DESTDIR/doc_dir/ + generate a man(1) page and copy to DESTDIR/man_dir/ + optionally generate html and copy to DESTDIR/html_dir/lang/ + +=head2 make installable -C
Re: My Parrot 0.7.0 patches (cygwin)
2008/8/26 Allison Randal [EMAIL PROTECTED]: On Mon, 25 Aug 2008, Reini Urban wrote: To clarify my bold statement: The ALGOL-like syntax is not sane because, * it is hard to parse, Not actually true. It's just different to parse. And, in general Parrot optimizes for making code easy to *read* even if it is slightly harder to parse. We have the most powerful parsing tools on the planet at our disposal, there's no reason to push the difficult work on the code maintainers. * it forbids our keywords AND, NOT and OR as config_hash keys and platform names. This isn't an onerous restriction. With lisp syntax there's a clear distinction between operator and arguments, with mixed arg op arg syntax it is not clear and as hard to understand as spoken language. If your background is lisp-like syntax, then yes it's easy to understand. But our primary target audience for Parrot is not people with a background in Lisp, it's people with a background in modern dynamic languages like Lua, Perl, PHP, Python, and Ruby. All of which are more familiar with infix notation. Andy Dougherty wrote: What we did in perl5's build system was to recognize that we didn't have to invent or borrow any new syntax at all. The languages we were using to write the Makefiles (namely /bin/sh and perl) already had sophisticated interpolation and conditional syntax capabilities. We used here-documents and interpolation instead of macro substitution. We used the language's built-in conditional and flow control syntax to express complex ideas. This particular chunk of syntax is indeed parsed by a Perl preprocessor for the Makefile. But, that doesn't necessarily mean that we want to directly eval/interpolate Perl conditional syntax. For one thing, it won't always be parsed by a Perl preprocessor, it'll eventually be parsed by a PGE-based preprocessor. Alternatively, we could use Makefile conditionals, but those are cumbersome. And, this particular pair of preprocessor directives give us a way to block out lines during preprocessing, so that 'make' never has to parse them at all. Picking any one HLL to mimic is problematic in our multi-lingual environment. But, we definitely want to pick syntax that will seem familiar to our primary HLL targets. I'll go now for something like #IF(key1|key2(key3!key4)) #IFNOT(key1|key2(key3!key4)) And probably a shortcut for the negative else clause, like #IF(cygwin): #ELSE: #+ and #- is lisp so I don't want to destroy #+ the syntax rules. #IF(): is quite short and easy to read. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/25 Allison Randal [EMAIL PROTECTED]: (Another way to fix the PDD issues is to eliminate the draft directory and just mark PDDs that are still considered in DRAFT with some decorative POD; that has my vote) I'm almost done with the PDDs in the draft directory. It's very helpful to be able to look at that directory and know exactly how many PDDs are still suffering from severe bit-rot. So, yes, agreed on eliminating the docs/pdds/draft/ directory, but not until we launch the final few PDDs out of it in a comprehensible form. Uh, it will be gone... I have one more draft. chromatic told me write up such a thing, but it's not finished yet. It could go to the cygwin070patches branch which is really a parrot_install branch, but also to HEAD. This needs some technical review because but I'm still a beginner in what is possible and what not. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ Index: parrot-svn/docs/pdds/draft/pdd30_install.pod === --- /dev/null +++ parrot-svn/docs/pdds/draft/pdd30_install.pod @@ -0,0 +1,213 @@ +# Copyright (C) 2008, The Perl Foundation. +# $Id: pdd30_install.pod 30255 2008-08-23 12:15:46Z rurban $ + +=head1 NAME + +docs/pdds/draft/pdd30_install.pod - Parrot Installation + +=head1 ABSTRACT + +This PDD defines Parrot's installation details. The goal is to provide binary +packages, a working Cmake install for parrot, the installables, FHS compliant +search paths for the installables and solving the problem of not accessing +installed source-only files and the optimization of config bootstrapping +if a frozen config_hash is already linked. + +=head1 VERSION + +$Revision: 30459 $ + +=head1 SYNOPSIS + + make install + make test-installable -C language/lang + make installable -C language/lang + make install -C language/lang DESTDIR=inst + +=head1 DESCRIPTION + +Parrot installation mechanisms are more powerful than perl5's. +MANIFEST contains also the end location, tools/dev/install_files.pl is driven +by this definition. +The three runtime paths for include, library for load_bytecode and dynext +for loadlib should end up in the $prefix/lib/parrot paths. +See #56996-fhs-runtime.patch + +Contrary to perl5, parrot and its language implementions on top of parrot may +be installed as self-hosting single-file executables, with the help of merged +pbc's and pbc2exe --install. + +Bootstrapping the config hash should not read a config file when the hash is +already contained in the pmc or executable. See #57418 [TODO] optimize +_config to omit .include library/config.pir on installables. + +The same problem is for every .include, .loadlib and .load_bytecode statement +in installed files where the target is not installed. This could be solved with +a module system or with pbc_merge removing not needed .load_bytecode statements. + +Test executables are binary different to installable executables because of +this embedded config hash. Test executables contain config hash with +the prefix to the build_dir, installables to the given prefix from Configure.pl. + +There are's also a long-standing conflict in building parrot with an already +installed shared libparrot.so. See #39742-installed-conflict.patch which adds +the blib/lib path to PATH resp. LD_RUN_PATH. + +=head1 DEFINITIONS + +An Binstallable is a pbc or exe which must not access the build_dir +paths. The build_dir is not available in a binary package. This is solved by +generating and linking a special Finstall_config.fpmc. Custom python modules +have a similar packaging problem, which they haven't solved yet. + +Bbuild_dir is the full path where parrot was built. It is defined in the +config hash. When building from source build_dir is also the PARROT_RUNTIME prefix. + +BDESTDIR is the end location of the parrot tree in front of the prefix +(/usr or /usr/local). This allows packaging by installing into a seperate +install tree and do a tar cf there. + +The Bconfig hash is the return value of the global function C_config(), +generated in Fconfig_lib.pasm, and either defined in Flibrary/config.pir, or +as frozen pmc embedded in the test executable (Fconfig.fpmc), the installable +executable (Finstall_config.fpmc) or empty for miniparrot (Fnull_config.fpmc). + +=head1 IMPLEMENTATION + +=head2 make install + +The parrot build system is optimized for building and testing in the +build_dir, but not for building with an already installed parrot due to simple +build system bugs, and not optimized to build and test installables, which should +not access the libraries in the build_dir, but in the DESTDIR. + +The goal is to make install work for parrot, the utils, and all the languages. +For parrot and its utils the install actions are defined in the main Makefile, +for the languages the install actions should be defined in its Makefiles and +is implemented in #56554-make-install-lang.patch. + +Cmake install currently does not work with an already installed shared
57548-CONDITIONED_LINE_enh
jerry gay schrieb: On Tue, Aug 26, 2008 at 2:34 AM, Reini Urban [EMAIL PROTECTED] wrote: I'll go now for something like #IF(key1|key2(key3!key4)) #IFNOT(key1|key2(key3!key4)) I went for #UNLESS(expr): here. Also #ELSIF(expr): And probably a shortcut for the negative else clause, like #IF(cygwin): #ELSE: #+ and #- is lisp so I don't want to destroy #+ the syntax rules. #IF(): is quite short and easy to read. i know it was all caps before, but do we need to continue that trend? i find it ugly. stealing the markers from perl 6's test suite compiler directives, and using lower case and full english words, i suggest: #?if(foo|bar) ... #?else if(baz) ... #?else ... #?unless(quux) ... Okay, also fine. With or without the ending double-colon? -- Reini Urban http://phpwiki.org/ http://murbreak.at/
cygwin070patches patch
Remove the Makefile target and remove commented section from the root makefile. Add cardinal.install to languages.in Rename LANG to TMPL in all language makefiles. Conflicts with perl urmc locale. The new compiler not yet. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ 2008-08-26 21:53:14 rurban Remove the Makefile target and remove commented section from the root makefile. Add cardinal.install to languages.in Rename LANG to TMPL in all language makefiles. Conflicts with perl urmc locale. Index: config/gen/makefiles/root.in === --- config/gen/makefiles/root.in (revision 30547) +++ config/gen/makefiles/root.in (working copy) @@ -550,7 +550,6 @@ all : \ flags_dummy \ -Makefile \ PARROT_LIBS \ $(PARROT) \ runtime/parrot/include/parrotlib.pbc \ @@ -623,10 +622,6 @@ vtable.dump : src/vtable.tbl $(PMC2CV) -# regenerate the Makefile -Makefile: config/gen/makefiles/root.in - $(RECONFIGURE) --step=gen::makefiles --target=Makefile - # This is a listing of all targets meant to be called by users help : @echo @@ -1002,20 +997,6 @@ lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(OPS_DIR)/ops.num $(OPS_DIR)/ops.skip $(PERL) $(BUILD_TOOLS_DIR)/ops2pm.pl $(OPS_FILES) -# FIXME: This creates a cycle sometimes -#lib/Parrot/Config/Generated.pm \ -#$(SRC_DIR)/platform.c \ -##CONDITIONED_LINE(platform_asm):$(SRC_DIR)/platform_asm.s \ -##CONDITIONED_LINE(has_opengl):config/gen/call_list/opengl.in \ -##CONDITIONED_LINE(has_glut):$(SRC_DIR)/glut_callbacks.c \ -#config_lib.pasm \ -#$(BUILD_TOOLS_DIR)/dynpmc.pl \ -#$(BUILD_TOOLS_DIR)/dynoplibs.pl \ -# : Configure.pl lib/Parrot/Configure.pm \ -# lib/Parrot/Configure/Step/List.pm lib/Parrot/Configure/Step/Methods.pm -# @echo Makefile out-of-date: reconfigure -# $(PERL) Configure.pl $(CONFIG_ARGS) - ### # # Examples (Assembly): Index: config/gen/makefiles/languages.in === --- config/gen/makefiles/languages.in (revision 30547) +++ config/gen/makefiles/languages.in (working copy) @@ -322,6 +322,12 @@ - $(MAKE) cardinal cardinal.test: - $(MAKE) cardinal test +cardinal.installable: + - $(MAKE) cardinal installable +cardinal.test-installable: + - $(MAKE) cardinal test-installable +cardinal.install: + - $(MAKE) cardinal install cardinal.clean: - $(MAKE) cardinal clean cardinal.realclean: Index: languages/m4/config/makefiles/root.in === --- languages/m4/config/makefiles/root.in (revision 30547) +++ languages/m4/config/makefiles/root.in (working copy) @@ -1,7 +1,7 @@ # $Id$ # Makefile for languages/m4 -LANG = m4 +TMPL = m4 # Setup of some commands PARROT= ../../[EMAIL PROTECTED]@ @@ -72,22 +72,22 @@ # TODO: rename build_dir. basic run for missing libs test-installable : installable - ./installable_$(LANG)@exe@ + ./installable_$(TMPL)@exe@ install : installable - $(CP) installable_$(LANG)@exe@ $(DESTDIR)$(BIN_DIR)/parrot-$(LANG)@exe@ - $(POD2MAN) pod/running.pod $(DESTDIR)$(MANDIR)/man1/parrot-$(LANG).1 - mkdir $(DESTDIR)$(DOC_DIR)/languages/$(LANG) - $(CP) $(DOCS) $(DESTDIR)$(DOC_DIR)/languages/$(LANG) + $(CP) installable_$(TMPL)@exe@ $(DESTDIR)$(BIN_DIR)/parrot-$(TMPL)@exe@ + $(POD2MAN) pod/running.pod $(DESTDIR)$(MANDIR)/man1/parrot-$(TMPL).1 + mkdir $(DESTDIR)$(DOC_DIR)/languages/$(TMPL) + $(CP) $(DOCS) $(DESTDIR)$(DOC_DIR)/languages/$(TMPL) [EMAIL PROTECTED]@: $(LANG).pbc - $(PBC_TO_EXE) $(LANG).pbc [EMAIL PROTECTED]@: $(TMPL).pbc + $(PBC_TO_EXE) $(TMPL).pbc -installable : installable_$(LANG)@exe@ - $(CP) installable_$(LANG)@exe@ $(BUILD_DIR) +installable : installable_$(TMPL)@exe@ + $(CP) installable_$(TMPL)@exe@ $(BUILD_DIR) -installable_$(LANG)@exe@ : $(LANG).pbc - $(PBC_TO_EXE) $(LANG).pbc --install +installable_$(TMPL)@exe@ : $(TMPL).pbc + $(PBC_TO_EXE) $(TMPL).pbc --install html: mkdir docs/html Index: languages/forth/config/makefiles/root.in === --- languages/forth/config/makefiles/root.in (revision 30547) +++ languages/forth/config/makefiles/root.in (working copy) @@ -1,6 +1,6 @@ # $Id$ -LANG = forth +TMPL = forth PERL = @perl@ RM_RF = @rm_rf@ PARROT= ../../[EMAIL PROTECTED]@ @@ -30,7 +30,7 @@ # regenerate the Makefile Makefile: config/makefiles/root.in - cd $(BUILD_DIR) $(RECONFIGURE) --step=gen::languages --languages=$(LANG) + cd $(BUILD_DIR) $(RECONFIGURE) --step=gen::languages --languages=$(TMPL) prompt: all $(PARROT) forth.pbc @@ -76,31 +76,31 @@ # TODO: rename build_dir. basic run for missing libs test-installable : installable - echo 2-1 | ./installable_$(LANG)@exe@ + echo 2-1
pdd19_pir.pod: See Cdocs/imcc/macros.pod
pdd19_pir.pod references the not-existing docs/imcc/macros.pod. It would be nice if this documents shows up somewhere, as I found nothing more about macros, besides the section in pdd19_pir.pod -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: My Parrot 0.7.0 patches (cygwin)
Reini Urban schrieb: 2008/8/24 Allison Randal [EMAIL PROTECTED]: Reini Urban wrote: You want one patch only against HEAD? That's easy. But I dislike the idea, as it violates the usage of single tickets. This is different than the usual case as it's a collection of dependent patches that can't be evaluated independently. Splitting them out is actually more work for the reviewer/tester. I've created a branch cygwin070patches for testing this collection. To do platform or language testing, please check out that branch. Reini, please submit further changes as diffs against that branch instead of updates to your previous patch files. Overall the work is sane. It'll need a few changes before merging in: In runtime/parrot/library/config.pir you add commented-out code, and a mention that certain logic has to be reversed when installed versions should run faster than source builds. Those sorts of configuration changes should never involve commenting out and uncommenting bits of configuration files. Make it a compile-time or run-time configuration flag instead. Just was just an internal TODO comment, and is actually fixed. I will delete the superflous comment. In lib/Parrot/Configure/Data.pm, you changed some double C Pod tags to single C Pod tags. But, those code items contain = separating the key/value arguments, and the '' in the arrow will terminate the code tag. The double C tags avoid terminating on single '' (which is why they were double C tags in the first place). So, I reverted that file before committing. (See the output from 'perldoc' or any Pod parser on your modified file.) Thanks. In lib/Parrot/Configure/Compiler.pm, I agree that 'CONDITIONED_LINE' and 'INVERSE_CONDITIONED_LINE' aren't the clearest names, but '+' and '-' are far less clear. Change them to something meaningful like 'SHOW_LINE_IF' and 'HIDE_LINE_IF'. We can note the change in DEPRECATED.pod now, and remove 'CONDITIONED_LINE' and 'INVERSE_CONDITIONED_LINE' after a standard deprecation cycle (one release). #+ and #- are well known common lisp idioms (the most well-known reader-macros), thats why the reverse polish notation in the logic is used. It's just so much easier to parse and understand. Also in lib/Parrot/Configure/Compiler.pm, change the Polish notation of (and a b (not c d)) to a saner (a and b not (c and d)). This is ALGOL syntax you suggest is really not sane :) To clarify my bold statement: The ALGOL-like syntax is not sane because, * it is hard to parse, * it forbids our keywords AND, NOT and OR as config_hash keys and platform names. With lisp syntax there's a clear distinction between operator and arguments, with mixed arg op arg syntax it is not clear and as hard to understand as spoken language. #+(and foo (not bar)) is a well-established reader-macro syntax in lisp and a general life-safer in lisp, compared to less developed languages. Though really, since you're not implementing the advanced conditions, delete the comment defining the interface and the TODO comments about implementing it, just add a TODO RT ticket or keep it on your private TODO list. I finished now the implementation of this new feature. I'll implement it for sure, but later. First I wanted to bring out the packages and this is just convenience sugar. In config/gen/makefiles/pge.in, config/gen/makefiles/tge.in, and config/gen/makefiles/root.in, pick a more meaningful variable name than 'SHRPENV' and a more meaningful condition name than 'cygchkdll'. SHRPENV is directly from per5, and cygchkdll is they only way to check now for cygwin without the 57548-CONDITIONED_LINE_enh.patch. After that we can check against cygwin, the $^O. I really need some #+(and cygwin win32): sections. Also in config/gen/makefiles/root.in we don't need a makefile target for regenerating the makefile. Delete it. And you added a chunk of commented out code again. Delete it. That was the framework to autodetect configuration changes, to get rid of make clean before perl Configure.pl. I do need to regenerate the makefile, that's why I added it for every makefile. I'll rather add the missing bits to the missings deps, than delete this logic. The commented-out section works in 90%, but has still a flaw somewhere, which could lead to cycles. I'll debug this when I have more time. Since you've touched the config file and core PIR file for every language, this branch will need extensive platform and language testing before it can be merged in. I tested it extensively for the cygwin package. I believe I'm the only one who tested it at all because there were so many errors and still are. And I begin to wonder how others dare to release packages without working installables and with self.build make recipes. deb, gentoo, freebsd, rpm, the win32 build, and now my self-build work, but at least as Makefiles so we will have a standard. Just test-installable is a bit of work TODO. I had to test this by hand so far. The branch is failing one
Re: My Parrot 0.7.0 patches (cygwin)
Attached are updates to the cygwin070patches branch. Forget it. The Data.pm errors were still in. This is better. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ cygwin070patches_3.patch.gz Description: GNU Zip compressed data
Re: [perl #58354] [PATCH] for the file parrot.spec
[EMAIL PROTECTED] (via RT) schrieb: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #58354] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58354 this patch removes the file parrot-config from parrot.spec, because it will no longer installed. Not good. We install now parrot_config -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: My Parrot 0.7.0 patches (cygwin)
Moritz Lenz schrieb:
Reini Urban wrote:
Attached are updates to the cygwin070patches branch.
Thanks for applying the patches!
applied as r30543.
And this one also please.
fix cuddled else and some beautification.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: src/library.c
===
--- src/library.c (revision 30543)
+++ src/library.c (working copy)
@@ -168,7 +168,8 @@
entry = CONST_STRING(interp, lib/parrot/);
VTABLE_push_string(interp, paths, entry);
#ifdef ENABLE_PARROT_LIBRARY_INSTALLED
-} else {
+}
+else {
#endif
entry = CONST_STRING(interp, runtime/parrot/include/);
VTABLE_push_string(interp, paths, entry);
@@ -192,7 +193,8 @@
entry = CONST_STRING(interp, lib/parrot/);
VTABLE_push_string(interp, paths, entry);
#ifdef ENABLE_PARROT_LIBRARY_INSTALLED
-} else {
+}
+else {
#endif
entry = CONST_STRING(interp, runtime/parrot/library/);
VTABLE_push_string(interp, paths, entry);
@@ -214,7 +216,8 @@
entry = CONST_STRING(interp, lib/parrot/dynext/);
VTABLE_push_string(interp, paths, entry);
#ifdef ENABLE_PARROT_LIBRARY_INSTALLED
-} else {
+}
+else {
#endif
entry = CONST_STRING(interp, runtime/parrot/dynext/);
VTABLE_push_string(interp, paths, entry);
Index: config/gen/makefiles/pge.in
===
--- config/gen/makefiles/pge.in (revision 30543)
+++ config/gen/makefiles/pge.in (working copy)
@@ -8,8 +8,8 @@
TOOL_DIR = ../..
CP = @cp@
RECONFIGURE = $(PERL) @build_dir@/tools/dev/reconfigure.pl
-#+(cygchkdll):SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
-#-(cygchkdll):SHRPENV = env [EMAIL PROTECTED]@/blib/lib
+#+(cygwin):SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
+#-(cygwin):SHRPENV = env [EMAIL PROTECTED]@/blib/lib
# Where to put things
PARROT_LIBRARY= ../../runtime/parrot/library
Index: config/gen/makefiles/tge.in
===
--- config/gen/makefiles/tge.in (revision 30543)
+++ config/gen/makefiles/tge.in (working copy)
@@ -7,8 +7,8 @@
RM_F = @rm_f@
PARROT = ../../[EMAIL PROTECTED]@
RECONFIGURE = $(PERL) @build_dir@/tools/dev/reconfigure.pl
-#+(cygchkdll):SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
-#-(cygchkdll):SHRPENV = env [EMAIL PROTECTED]@/blib/lib
+#+(cygwin):SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
+#-(cygwin):SHRPENV = env [EMAIL PROTECTED]@/blib/lib
# Where to put things
PARROT_LIBRARY= ../../runtime/parrot/library
Index: config/gen/makefiles/root.in
===
--- config/gen/makefiles/root.in (revision 30543)
+++ config/gen/makefiles/root.in (working copy)
@@ -107,8 +107,8 @@
INNO_SETUP = iscc
JIT_BUILD_TOOL = $(BUILD_TOOLS_DIR)/jit2c.pl
#+(darwin):export MACOSX_DEPLOYMENT_TARGET := @osx_version@
-#+(cygchkdll):SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
-#-(cygchkdll):SHRPENV = env [EMAIL PROTECTED]@/blib/lib
+#+(cygwin):SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
+#-(cygwin):SHRPENV = env [EMAIL PROTECTED]@/blib/lib
###
#
@@ -893,7 +893,7 @@
$(LIBPARROT_SHARED) : $(O_FILES)
$(MKPATH) @blib_dir@
$(LD) $(LD_SHARE_FLAGS) $(LDFLAGS) @[EMAIL PROTECTED]@ @libparrot_soname@ \
-#+(cygchkdll): -Wl,--out-implib=blib/lib/libparrot.dll.a \
+#+(cygwin): -Wl,--out-implib=blib/lib/libparrot.dll.a \
$(O_FILES) $(C_LIBS) $(ICU_SHARED)
#+(win32): if exist [EMAIL PROTECTED] mt.exe -nologo -manifest [EMAIL PROTECTED] -outputresource:$@;2
#+(libparrot_shared_alias): ( cd @blib_dir@ ; ln -sf @libparrot_shared@ @libparrot_shared_alias@ )
Index: config/gen/makefiles/pct.in
===
--- config/gen/makefiles/pct.in (revision 30543)
+++ config/gen/makefiles/pct.in (working copy)
@@ -10,8 +10,8 @@
TEST_DIR = ../../t/compilers/pct
CP = @cp@
RECONFIGURE = $(PERL) @build_dir@/tools/dev/reconfigure.pl
-#+(cygchkdll):SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
-#-(cygchkdll):SHRPENV = env [EMAIL PROTECTED]@/blib/lib
+#+(cygwin):SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
+#-(cygwin):SHRPENV = env [EMAIL PROTECTED]@/blib/lib
# Where to put things
PARROT_LIBRARY= ../../runtime/parrot/library
Index: config/gen/makefiles/nqp.in
===
--- config/gen/makefiles/nqp.in (revision 30543)
+++ config/gen/makefiles/nqp.in (working copy)
@@ -5,8 +5,8 @@
RM_F = @rm_f@
PARROT = ../../[EMAIL PROTECTED]@
RECONFIGURE = $(PERL) @build_dir@/tools/dev/reconfigure.pl
-#+(cygchkdll): SHRPENV = env PATH=@build_dir@/blib/lib:$(PATH)
-#-(cygchkdll): SHRPENV = env [EMAIL PROTECTED]@/blib/lib
+#+(cygwin): SHRPENV = env PATH
Re: My Parrot 0.7.0 patches (cygwin)
Moritz Lenz schrieb:
Reini Urban wrote:
Moritz Lenz schrieb:
Reini Urban wrote:
Attached are updates to the cygwin070patches branch.
Thanks for applying the patches!
applied as r30543.
And this one also please.
fix cuddled else and some beautification.
Also applied (r30547).
And one more patch to fix more cuddling else and tabs.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: lib/Parrot/Configure/Compiler.pm
===
--- lib/Parrot/Configure/Compiler.pm (revision 30547)
+++ lib/Parrot/Configure/Compiler.pm (working copy)
@@ -354,15 +354,15 @@
last;
}
if ( $options{conditioned_lines} ) {
- # allow multiple keys and nested parens here
+# allow multiple keys and nested parens here
if ( $line =~ m/^#([-+])\((.+)\):(.*)/s ) {
- my $truth = cond_eval($conf, $2);
- next if ($1 eq '-') and $truth;
- next if ($1 eq '+') and not $truth;
+ my $truth = cond_eval($conf, $2);
+ next if ($1 eq '-') and $truth;
+next if ($1 eq '+') and not $truth;
$line = $3;
- }
- # but here not (legacy)
- elsif ( $line =~ m/^#CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
+}
+ # but here not (legacy)
+elsif ( $line =~ m/^#CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
next unless cond_eval($conf, $1);
$line = $2;
}
@@ -475,16 +475,17 @@
my $s = $_[0];
return unless $s;
if ($s =~ /^\((.+)\)\s*(.*)/) { # longest match to matching closing paren
- $_[0] = $2 ? $2 : ; # modify the 2nd arg
- #print ** \$s\ = (\$1\,\$_[0]\)\n;
- return $1;
-} else {
- $s =~ s/^\s+//; # left-trim to make it more robust
- $s =~ m/^([^ \(]+)\s*(.*)?/;# shortest match to next whitespace or open paren
- $_[0] = $2 ? $2 : ; # modify the 2nd arg
- #print ** \$s\ = (\$1\,\$_[0]\)\n;
- return $1;
+$_[0] = $2 ? $2 : ; # modify the 2nd arg
+#print ** \$s\ = (\$1\,\$_[0]\)\n;
+return $1;
}
+else {
+$s =~ s/^\s+//; # left-trim to make it more robust
+$s =~ m/^([^ \(]+)\s*(.*)?/;# shortest match to next whitespace or open paren
+$_[0] = $2 ? $2 : ; # modify the 2nd arg
+#print ** \$s\ = (\$1\,\$_[0]\)\n;
+return $1;
+}
}
# Recursively evaluate AND, OR, NOT for multiple keys as LISP expressions.
@@ -497,30 +498,32 @@
my $key = $expr;
my @count = split /\s+/, $expr;
if (@count 1) { # multiple keys: recurse into
- my $truth;
- my $op = next_expr($expr);
- if ($op =~ /^(or|and|not)$/i) {
- $op = lc($op);
- $key = next_expr($expr);
- } else {
+my $truth;
+my $op = next_expr($expr);
+if ($op =~ /^(or|and|not)$/i) {
+$op = lc($op);
+$key = next_expr($expr);
+}
+else {
$key = $op;
- $op = 'or';
- }
- while ($key) {
- last if $truth and ($op eq 'or'); # logical shortcut on OR and already $truth
- $truth = cond_eval($conf, $key);
- if($op eq 'not') { $truth = $truth ? 0 : 1; }
- elsif ($op eq 'and') { last unless $truth; } # skip on early fail
- $key = next_expr($expr);
- }
- return $truth;
+$op = 'or';
+}
+while ($key) {
+last if $truth and ($op eq 'or'); # logical shortcut on OR and already $truth
+$truth = cond_eval($conf, $key);
+if($op eq 'not') { $truth = $truth ? 0 : 1; }
+elsif ($op eq 'and') { last unless $truth; } # skip on early fail
+$key = next_expr($expr);
+}
+return $truth;
}
if ($key =~ /^(\w+)=(.+)$/) {
- return $conf-data-get($1) eq $2;
-} else {
- return exists($conf-data-{c}-{$key})
-? $conf-data()-get($key)
- : $key eq $^O;
+return $conf-data-get($1) eq $2;
+}
+else {
+return exists($conf-data-{c}-{$key})
+ ? $conf-data()-get($key)
+ : $key eq $^O;
}
}
Index: config/gen/makefiles/root.in
===
--- config/gen/makefiles/root.in (revision 30547)
+++ config/gen/makefiles/root.in (working copy)
@@ -550,7 +550,6 @@
all : \
flags_dummy \
-Makefile \
PARROT_LIBS \
$(PARROT) \
runtime/parrot/include/parrotlib.pbc \
@@ -623,10 +622,6 @@
vtable.dump : src/vtable.tbl
$(PMC2CV)
-# regenerate the Makefile
-Makefile: config/gen/makefiles/root.in
- $(RECONFIGURE) --step=gen::makefiles --target=Makefile
-
# This is a listing of all targets meant to be called by users
help :
@echo
@@ -1002,20 +997,6 @@
lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(OPS_DIR)/ops.num $(OPS_DIR)/ops.skip
$(PERL) $(BUILD_TOOLS_DIR)/ops2pm.pl $(OPS_FILES)
-# FIXME: This creates a cycle sometimes
-#lib/Parrot/Config/Generated.pm \
-#$(SRC_DIR)/platform.c
Re: Windows visibility (was: Re: Parrot 0.7.0 Severe Macaw)
2008/8/23 François Perrad [EMAIL PROTECTED]: 2008/8/23 Allison Randal [EMAIL PROTECTED]: Moritz Lenz wrote: On #perl6 somebody just asked if there were up-to-date windows builds of parrot somewhere, he had googled for 'parrot windows'. The parrotwin32 project didn't show up in his search (but it's first for 'parrot win32'). I think we should improve that situation. Suggestions: 1) A link on http://www.parrotcode.org/source.html Sure. Already done since 2-3 months, see http://www.parrotcode.org/source.html#Packages, but with the word Win32, not Windows. Cygwin is missing there: a href=http://cygwin.com/;Cygwin/a -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: My Parrot 0.7.0 patches (cygwin)
2008/8/24 Allison Randal [EMAIL PROTECTED]: Reini Urban wrote: You want one patch only against HEAD? That's easy. But I dislike the idea, as it violates the usage of single tickets. This is different than the usual case as it's a collection of dependent patches that can't be evaluated independently. Splitting them out is actually more work for the reviewer/tester. I've created a branch cygwin070patches for testing this collection. To do platform or language testing, please check out that branch. Reini, please submit further changes as diffs against that branch instead of updates to your previous patch files. Overall the work is sane. It'll need a few changes before merging in: In runtime/parrot/library/config.pir you add commented-out code, and a mention that certain logic has to be reversed when installed versions should run faster than source builds. Those sorts of configuration changes should never involve commenting out and uncommenting bits of configuration files. Make it a compile-time or run-time configuration flag instead. Just was just an internal TODO comment, and is actually fixed. I will delete the superflous comment. In lib/Parrot/Configure/Data.pm, you changed some double C Pod tags to single C Pod tags. But, those code items contain = separating the key/value arguments, and the '' in the arrow will terminate the code tag. The double C tags avoid terminating on single '' (which is why they were double C tags in the first place). So, I reverted that file before committing. (See the output from 'perldoc' or any Pod parser on your modified file.) Thanks. In lib/Parrot/Configure/Compiler.pm, I agree that 'CONDITIONED_LINE' and 'INVERSE_CONDITIONED_LINE' aren't the clearest names, but '+' and '-' are far less clear. Change them to something meaningful like 'SHOW_LINE_IF' and 'HIDE_LINE_IF'. We can note the change in DEPRECATED.pod now, and remove 'CONDITIONED_LINE' and 'INVERSE_CONDITIONED_LINE' after a standard deprecation cycle (one release). #+ and #- are well known common lisp idioms (the most well-known reader-macros), thats why the reverse polish notation in the logic is used. It's just so much easier to parse and understand. Also in lib/Parrot/Configure/Compiler.pm, change the Polish notation of (and a b (not c d)) to a saner (a and b not (c and d)). This is ALGOL syntax you suggest is really not sane :) Though really, since you're not implementing the advanced conditions, delete the comment defining the interface and the TODO comments about implementing it, just add a TODO RT ticket or keep it on your private TODO list. I'll implement it for sure, but later. First I wanted to bring out the packages and this is just convenience sugar. In config/gen/makefiles/pge.in, config/gen/makefiles/tge.in, and config/gen/makefiles/root.in, pick a more meaningful variable name than 'SHRPENV' and a more meaningful condition name than 'cygchkdll'. SHRPENV is directly from per5, and cygchkdll is they only way to check now for cygwin without the 57548-CONDITIONED_LINE_enh.patch. After that we can check against cygwin, the $^O. I really need some #+(and cygwin win32): sections. Also in config/gen/makefiles/root.in we don't need a makefile target for regenerating the makefile. Delete it. And you added a chunk of commented out code again. Delete it. That was the framework to autodetect configuration changes, to get rid of make clean before perl Configure.pl. I do need to regenerate the makefile, that's why I added it for every makefile. I'll rather add the missing bits to the missings deps, than delete this logic. The commented-out section works in 90%, but has still a flaw somewhere, which could lead to cycles. I'll debug this when I have more time. Since you've touched the config file and core PIR file for every language, this branch will need extensive platform and language testing before it can be merged in. I tested it extensively for the cygwin package. I believe I'm the only one who tested it at all because there were so many errors and still are. And I begin to wonder how others dare to release packages without working installables and with self.build make recipes. deb, gentoo, freebsd, rpm, the win32 build, and now my self-build work, but at least as Makefiles so we will have a standard. Just test-installable is a bit of work TODO. I had to test this by hand so far. The branch is failing one test that passes in trunk, should be a quick fix: t/codingstd/cuddled_else.t Thanks for reviewing! -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: My Parrot 0.7.0 patches (cygwin)
Moritz Lenz schrieb: Reini Urban wrote: See http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series defines the order. I tried to apply those patches stupidly both against HEAD and against parrot-0.7.0, and both had some failures: parrot-0.7.0: cat ../patch-list | while read i; do echo $i; pa tch -p1 ../parrot-patches/$i; done 39742-installed-conflict.patch patching file config/gen/makefiles/dynpmc_pl.in patching file config/gen/makefiles/dynpmc.in patching file config/gen/makefiles/nqp.in patching file config/gen/makefiles/parrot_embed.in patching file config/gen/makefiles/pct.in patching file config/gen/makefiles/pge.in patching file config/gen/makefiles/pirc.in patching file config/gen/makefiles/tge.in patching file config/gen/makefiles/editor.in patching file config/gen/makefiles/ext.in patching file config/gen/makefiles/json.in patching file config/gen/makefiles/root.in Hunk #7 FAILED at 820. Hunk #9 succeeded at 1018 (offset -2 lines). 1 out of 9 hunks FAILED -- saving rejects to file config/gen/makefiles/root.in.r Against which svn revision should I apply those patches for testing? I'll try to be uptodate against HEAD with the patches in my SVN repo. But things are changing fast over there. config/gen/makefiles/root.in was changed by the ncigen merge yesterday. The patches in the cygwin 0.7.0 package are against 0.7.0. See http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/parrot-0.7.0-1.src.patch -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: gsoc_nci merge
Kevin Tew schrieb:
The merge has happened.
Developers/Users should see no visible changes.
Please build and test, should you have any problems, just yell at me on
#irc or parrot-porters.
Some options are still not implemented.
Attached patch does that.
The makefile has also still the C_GROUP in it. This should be removed
and all references to PMC. I did that in my 56554-make-install-lang.patch
Another question:
May I convert the nci_gen.pl to pir? I want a ncigen.pbc.
--
Reini Urban
http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches
diff -bu compilers/ncigen/nci_gen.pl~ compilers/ncigen/nci_gen.pl
--- compilers/ncigen/nci_gen.pl~ 2008-08-22 23:10:02.40625 +
+++ compilers/ncigen/nci_gen.pl 2008-08-23 08:03:04.43750 +
@@ -12,10 +12,12 @@
my $man = 0;
my $help = 0;
my $PARROT = ../../parrot;
-my $incpaths;
+my ($incpaths,$libname,$nsname);
GetOptions('help|?' = \$help,
man = \$man,
+ libname = \$libname,
+ nsname = \$nsname,
I=s@ = \$incpaths) or pod2usage(2);
pod2usage(1) if $help;
pod2usage(-exitstatus = 0, -verbose = 2) if $man;
@@ -49,9 +51,11 @@
my $more_args = ;
unless ( $ARGV[0] ) {
$ARGV[0] = 't/spi.c' unless $ARGV[0];
+$libname = fred unless $libname;
+$nsname = GO::Mojo unless $nsname;
}
#$more_args = --target=parse --libname=fred --nsname=GO::Mojo;
- $more_args = --libname=fred --nsname=GO::Mojo;
+ $more_args = --libname=$libname --nsname=$nsname;
my $preproc_fn = cc_preprocess($ARGV[0]);
Re: My Parrot 0.7.0 patches (cygwin)
Allison Randal schrieb: Reini Urban wrote: Moritz Lenz schrieb: Against which svn revision should I apply those patches for testing? I'll try to be uptodate against HEAD with the patches in my SVN repo. But things are changing fast over there. config/gen/makefiles/root.in was changed by the ncigen merge yesterday. The patches in the cygwin 0.7.0 package are against 0.7.0. See http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/parrot-0.7.0-1.src.patch Tracking a large collection of patches over multiple versions just doesn't work. This needs a branch. Then we can a) let Reini create a single patch of his changes for the branch to avoid complex ordering requirements, b) keep the proposed changes synchronized with trunk, and c) easily get testing on multiple platforms. You want one patch only against HEAD? That's easy. But I dislike the idea, as it violates the usage of single tickets. quilt push -a svn diff | gzip -c against r30499 -- Reini Urban http://phpwiki.org/ http://murbreak.at/ rurban-r30499.diff.gz Description: GNU Zip compressed data
My Parrot 0.7.0 patches (cygwin)
2008/8/17 Reini Urban [EMAIL PROTECTED]: FYI: The cygwin release for parrot-0.7.0-1 will contain the following yet unapplied patches to make it work: (in this order from my quilt series file) 39742-installed-conflict.patch 56544-install_files.patch 57006-opengl-cyg.patch -p0 I've fixed another linking issue here. 58034-config_args.patch 56554-make-install-lang.patch This is now finished. 56998-cygdll_versioning.patch -p0 51944-README_cygwin.patch These were applied: 57476-pdb-version.patch 57546-tags-xemacs.patch These are not stable enough: 56996-fhs-runtime.patch Still working on library.c getting the interpreter interpreter INTERPINFO_RUNTIME_PREFIX or CONFIG_HASH and check for the new installed key if present. This is in, but the new features to make it faster are ifdef'ed out. 57548-CONDITIONED_LINE_enh.patch too early TODO: I'm not yet sure about these patches of mine. Most likely they are already applied. 56562-implib.patch 57110-ncurses-cygwin.patch 57112-pg-cygwin.patch 57114-urm-RealBin.patch These are already in. As my number of patches is too big, and the size is too big, I update them only in my public SVN repo, not in the tickets anymore. And the order in which they should be applied is important. See http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series defines the order. Esp. the 39742-installed-conflict.patch and 56554-make-install-lang.patch are big. I still have issues with the language installables requiring úninstalled files (pbc's from compiler), so the cygwin release will need more time. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #58034] [TODO] save config_args for make reconfig
2008/8/17 Reini Urban [EMAIL PROTECTED]: James Keenan via RT schrieb: Reini, I would argue that we take a different approach with 'make reconfig'. We need to get rid of it entirely. In Parrot years, it's ancient code: $ svn blame config/gen/makefiles/root.in | grep -n -A 3 reconfig ... -- 708: 4916 boemmels @echo reconfig: 'clean' and redo configuration. ... -- 1769: 7554 bernhard reconfig : clean 1770- 22967 bernhard $(PERL) Configure.pl And it doesn't DWIM. Nowadays, if you want to redo configuration, you need to call 'make realclean', as 'make clean' does not delete the files created by Configure.pl. (If you want to re-run one particular configuration step, use tools/dev/reconfigure.pl.) I guess that the existence of 'make reconfig' completely escaped me. If I had known about it, I would have recommended excising it, as it's inconsistent with the way Configure.pl has worked for at least two years. Now, there may very well be other reasons to retain the command-line options. Parrot::Configure::Options processes those options, and the most important of them are available for the lifetime of the Parrot::Configure object. Given that, the question arises as to whether they should be retained in the Makefile and/or in Parrot::Config. I'm now developing file-based configuration in a branch, and in that branch I've chosen to store the parsed version of that file in Parrot::Config. So, my recommendation is to hold off on deciding how to store command-line options for the next week. After I present this patch for file-based configuration, we'll be in a better position to decide how/where to store the command-line options data. Hmm, Attached is my improved version which got the GEN_CONFIG dependencies right. My goal is to get rid of the required make clean and to get all dependencies right. With a required make clean we are loosers. The GEN_CONFIG target does not need clean anymore. It needs to be more fine-tuned though. This solves the Makefile problem. What you plan with the perl libraries is fine, but the driver for the dependencies to finally get rid of make clean should be the Makefiles. The toolkit could be Parrot::Config a la tools/dev/reconfigure.pl I got rid of [perl #39742] [BUG] installed parrot conflicts with dev parrot with my 39742-installed-conflict.patch. Now just the proper dependencies and install are missing. Attached is the version which is in the cygwin 0.7.0 package. CONFIGURE_GENERATED_FILES should use it, The GEN_CONFIGS dep is commented out, because it's not 100% safe yet. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ 2008-08-17 [EMAIL PROTECTED] make reconfig ignores the given Configure.pl command-line args. We need to save the config_args somewhere to be able to do make reconfig like CONFIG_ARGS = @config_args@ $(CONFIGURE_GENERATED_FILES) : Configure.pl $(PERL) Configure.pl $(CONFIG_ARGS) We really should track all dependencies and do a make reconfig automatically. The CONFIG_ARGS should be stored in Makefile. config_args should be stored in config_lib.pasm as in perl5 also. Index: parrot-svn/config/gen/makefiles/root.in === --- parrot-svn.orig/config/gen/makefiles/root.in +++ parrot-svn/config/gen/makefiles/root.in @@ -19,6 +19,7 @@ DEVEL = @DEVEL@ VERSION = @[EMAIL PROTECTED](DEVEL) SOVERSION = @VERSION@ +CONFIG_ARGS = @config_args@ # Override at least PREFIX with the install location if you're going # to be using this outside of your build area. @@ -999,6 +1000,20 @@ $(INC_DIR)/oplib/ops.h lib/Parrot/OpLib/ lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(OPS_DIR)/ops.num $(OPS_DIR)/ops.skip $(PERL) $(BUILD_TOOLS_DIR)/ops2pm.pl $(OPS_FILES) +# FIXME: This creates a cycle sometimes +#lib/Parrot/Config/Generated.pm \ +#$(SRC_DIR)/platform.c \ +##CONDITIONED_LINE(platform_asm):$(SRC_DIR)/platform_asm.s \ +##CONDITIONED_LINE(has_opengl):config/gen/call_list/opengl.in \ +##CONDITIONED_LINE(has_glut):$(SRC_DIR)/glut_callbacks.c \ +#config_lib.pasm \ +#$(BUILD_TOOLS_DIR)/dynpmc.pl \ +#$(BUILD_TOOLS_DIR)/dynoplibs.pl \ +# : Configure.pl lib/Parrot/Configure.pm \ +# lib/Parrot/Configure/Step/List.pm lib/Parrot/Configure/Step/Methods.pm +# @echo Makefile out-of-date: reconfigure +# $(PERL) Configure.pl $(CONFIG_ARGS) + ### # # Examples (Assembly): @@ -1774,7 +1789,7 @@ svnclobber : .svn $(PERL) tools/dev/svnclobber.pl reconfig : clean - $(PERL) Configure.pl + $(PERL) Configure.pl $(CONFIG_ARGS) manitest : $(PERL) tools/dev/manicheck.pl Index: parrot-svn/Configure.pl === --- parrot-svn.orig/Configure.pl +++ parrot-svn/Configure.pl @@ -63,6 +63,8 @@ $conf-add_steps( get_steps_list() ); # from Parrot
Re: [perl #56996] [TODO] remove non FHS-compliant searchpaths
This is where I stand now, and as it is in the 0.7.0 cygwin package.
It works fine, but slow.
There's a new installed key in the config hash, and the code to check this in
library.c is ifdef'ed out as it generates a VM out of memory error.
2008/8/9 Reini Urban [EMAIL PROTECTED]:
Reini Urban schrieb:
Reini Urban schrieb:
Geoffrey Broadwell via RT schrieb:
On Sun, 2008-07-27 at 13:13 +0200, Reini Urban wrote:
+stat $I0, conf_file, 0
+if $I0 goto conf
++# If installed into /usr/lib/parrot, not /usr/runtime/parrot
+# This logic has to be reversed when installed versions should
run faster
+# than source builds.
Reverse it now; we'll never remember to get back to this in the future.
+conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX
+conf_file .= /lib/parrot/include/config.fpmc
+conf:
+name = interpinfo .INTERPINFO_RUNTIME_PREFIX
+concat name, lib/parrot/dynext/
concat name, request
Since we're using PIR in both places, we should probably use the .=
sugar in both places. Yes, I know the second file has some 'concat's in
it already. Here's an opportunity to fix that. :-)
Ok. concat to .= is easy.
Why I don't want to fix that as you suggest is that I wait for feedback
how it was designed to be. This patch is just a intermediate hack. Someone
like particle or Allison should comment on that.
It is fine for benchmarks that the source build uses
runtime/parrot/include/config.fpmc.
But the installed version either should NOT need to load the frozen
config file when it is already linked in, or check with some global or
interpinfo magic and look up the right prefix then.
No useless stats please.
My current plan is this:
Source builds should be allowed to access
runtime/parrot/include/config.fpmc and the various other config fpmc's, but
the installable version, linked to install_config.fpmc must change its
lib_path to allow only FHS-compliant paths,
i.e remove runtime/parrot and runtime/parrot/include in favor of
lib/parrot and lib/parrot/include.
This must be fixed in config.pir, parrotlib.pir and src/library.c with
this ticket. (Hope I forgot no other file)
I'll work on that, but I have a business trip for the next two weeks.
An optimization for another ticket would be to remove the run-time access
to include/config.pir for linked installable's, where the frozen config.fpmc
is already linked. There the sub _config should use some config detection
logic (suggestion: new config key 'installed') to omit .include
library/config.pir
See the ticket perl #57418 [TODO] optimize _config to omit .include
library/config.pir on installables
Attached is an improved version with a fix in src/library.c, to decide
between installed and not installed configs.
This solves at least the /usr/runtime problem.
However config.pir still unnecessarily tries to access some runtime files,
esp. interpinfo.pasm to get the index of .INTERPINFO_RUNTIME_PREFIX
I'm toying with the idea to fill that macro in parrotlib.pir and config.pir
with config/gen/parrot_include.pm.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Remove stats to /usr/runtime/parrot at installed versions
(/usr being the prefix).
Check the config_hash for the installed key and the
interpreter INTERPINFO_RUNTIME_PREFIX or CONFIG_HASH if present.
The library.c code is not working yet with ENABLE_PARROT_LIBRARY_INSTALLED
Parrot VM: PANIC: Out of mem!
Not enough tuits yet to fix and debug it.
Index: parrot-svn/runtime/parrot/library/config.pir
===
--- parrot-svn.orig/runtime/parrot/library/config.pir
+++ parrot-svn/runtime/parrot/library/config.pir
@@ -48,12 +48,28 @@ undefined values) is undefined, and may
.sub _config
.local pmc CONF
.local string conf_file
+
+#unless find_sub('_config') goto runtime
+#$P0 = _config()
+#.return( $P0 )
+
+runtime:
+# conf_file = Parrot_locate_runtime_file_str(interp, config.fpmc, 2)
conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX
conf_file .= /runtime/parrot/include/config.fpmc
+stat $I0, conf_file, 0
+if $I0 goto conf
+# If installed into /usr/lib/parrot, not /usr/runtime/parrot
+# This logic has to be reversed when installed versions should run faster
+# than source builds.
+conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX
+conf_file .= /lib/parrot/include/config.fpmc
+conf:
open CONF, conf_file,
$I0 = defined CONF
if $I0 goto ok1
+
printerr Can't read '
printerr conf_file
printerr ':
Index: parrot-svn/runtime/parrot/library/parrotlib.pir
===
--- parrot-svn.orig/runtime/parrot/library/parrotlib.pir
+++ parrot-svn/runtime/parrot/library/parrotlib.pir
@@ -24,14 +24,13 @@ parrotlib's interface functions.
.local pmc includes
.local string root
-
-# XXX todo: get root from config
Re: [perl #39742] [BUG] installed parrot conflicts with dev parrot.
Attached is my latest version.
make works with already installed shared lib,
make installable fails on some languages with already installed
/usr/lib/parrot and /usr/include/parrot.
Fixing make installable belongs to a new ticket, as there's more involved.
2008/8/3 Reini Urban [EMAIL PROTECTED]:
Reini Urban schrieb:
Andy Dougherty schrieb:
On Sat, 14 Jun 2008, James Keenan via RT wrote:
Can we get an update as to the issues raised in this ticket?
The general issue
installeld parrot conflicts with dev parrot -- at least when a
shared libparrot.so is used
is, as far as I know, unsolved. A longer discussion can be found here
(and the surrounding thread):
http://www.nntp.perl.org/group/perl.perl6.internals/2006/03/msg33340.html
It should be added that this does not affect cygwin and mingw.
just shared a libparrot.so
It is still true that
gcc ... -L/usr/local/lib ... -L.../blib/lib -lparrot -L/usr/local/lib
-lgmp -lreadline
would prefer a /usr/local/lib/libparrot.dll.a if there would be some,
(there is even a /usr/lib/libparrot.dll.a)
but the nature of this import lib is affected by PATH,
which is so constructed that blib/lib prepends the installed libparrot.
Just the perl5 ldflags setting have to fixed in the config hints step.
-L/usr/local/lib can be stripped at all, if some parrot lib pulls that in.
If not it has to be put after -lparrot.
With the recent merge which changed the exception handling,
I was able to reproduce and fix the problem not being able to compile a
fresh parrot with an already installed shared libparrot.
So my previous comment was wrong.
The reason for the problem is simple and two-fold:
1. libs belongs to the end.
first LDFLAGS, then LD_LOAD_FLAGS, then libparrot,
then LIBS + EXTRALIBS.
dynpmc got this wrong.
It had LIBS at the front.
a. One should not put libs before the LDFLAGS.
b. One should reverse the LIBS line in order of dependencies.
We have the problem that the libs line is generated automatically and
may contain -L/usr/lib (pulled in from libicu) and -L/usr/local/lib, so the
already installed -lparrot will be found.
So our -Lblib/lib should be at the front, best in LDFLAGS.
Note that parrot.pc got that right:
Libs: -L${libdir} -lparrot @icu_shared@ @libs@
2. remove the perl5 -L/usr/local/lib LDFLAGS which would pull in
a shared /usr/local/lib/libparrot.so before checking -Lblib/lib
-lparrot.
One fix could be to check this in Configure and move all -L from LDFLAGS
to the LIBS flag at the front.
The other fix would be to explicitly link to blib/lib/libparrot.so,
without path hacks, which could be easily fooled.
This patch adds PATH resp. LD_RUN_PATH to the parrot invocations, similar as
in perl5.
It moves a -Lpath from @ldflags@ to @libs@ in config.
It also adds emacs/vim modes to the Makefiles.
It also adds Makefile targets to regenerate the Makefiles automatically.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
-*- diff -*-
The reason for the problem to make shared libparrot with an already installed
shared libparrot is simple and has several reasons:
1. libs belongs to the end.
first LDFLAGS, then LD_LOAD_FLAGS, then libparrot,
then LIBS + EXTRALIBS.
dynpmc got this wrong.
It had LIBS at the front.
a. One should not put libs before the LDFLAGS.
b. One should reverse the LIBS line in order of dependencies.
We have the problem that the libs line is generated automatically
and may contain -L/usr/lib (pulled in from libicu) and -L/usr/local/lib,
so the already installed -lparrot will be found.
So our -Lblib/lib should be at the front, best in LDFLAGS.
Note that parrot.pc got that right:
Libs: -L${libdir} -lparrot @icu_shared@ @libs@
2. remove the perl5 -L/usr/local/lib LDFLAGS which would pull in
a shared /usr/local/lib/libparrot.so before checking -Lblib/lib
-lparrot.
One fix could be to check this in Configure and move all -L from LDFLAGS
to the LIBS flag at the front. I went this way.
The other fix would be to explicitly link to blib/lib/libparrot.so,
without -L path hacks.
3. Now an already installed libparrot.dll/.so does not conflict with make anymore.
The remaining problem is at make installable esp. for the languages
and already installed /usr/lib/parrot, /usr/include/parrot and
/usr/lib/libparrot.dll.a
This patch adds PATH resp. LD_RUN_PATH to the parrot invocations, similar as in perl5.
It moves a -Lpath from @ldflags@ to @libs@ in config.
It also adds emacs/vim modes to the Makefiles.
It also adds Makefile targets to regenerate the Makefiles automatically.
Index: parrot-svn/config/gen/makefiles/dynpmc_pl.in
===
--- parrot-svn.orig/config/gen/makefiles/dynpmc_pl.in
+++ parrot-svn/config/gen/makefiles/dynpmc_pl.in
@@ -72,8 +72,15 @@ sub partial_link_cmd {
my $liblist;
if ($^O =~ /mswin32/i) {
-# Need to put various libraries
Re: My Parrot 0.7.0 patches (cygwin)
2008/8/22 Allison Randal [EMAIL PROTECTED]: As my number of patches is too big, and the size is too big, I update them only in my public SVN repo, not in the tickets anymore. And the order in which they should be applied is important. See http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series defines the order. What are we lacking to get the stable patches from this set merged in? All the ones from the series file are current and stable. The others are outdated. Do we need a code review? For 56996-fhs-runtime.patch. Testing on other platforms to make sure they don't cause problems elsewhere? Sure. That would be nice. But cygwin is usually less forgiving than other platforms, so I'm pretty sure it should work elsewhere. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: Parrot 0.7.0 Severe Macaw - permissions
2008/8/20 Allison Randal [EMAIL PROTECTED]: Will Coleda wrote: Please open a ticket tracking this if we're not going to apply it right now so we don't miss it for next release. CPAN is great for distributing Perl modules, but simply can't handle Parrot. As soon as we have the alternate FTP site up, we're done with CPAN. The issue is not the CPAN SW, which can easily be fixed somewhen (no-index), the CPAN mirror network and the popularity is what parrot should look forward to, IMHO -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[perl #57006] [PATCH] add cygwin opengl config quirks
One more fix on this issue on parsing the headers.
X freeglut only if DISPLAY is set, otherwise use native w32api GLUT
--
Reini Urban
difforig config/auto/opengl.pm lib/Parrot/Configure/Step/Methods.pm
header parsing:
need to match the linker logic. On cygwin without DISPLAY
leave out freeglut.
linking:
same logic.
revised to add -L/usr/X11R6/lib and /usr/bin/glut32.dll directly
Index: config/auto/opengl.pm
===
--- config/auto/opengl.pm.orig
+++ config/auto/opengl.pm
@@ -114,14 +114,16 @@ FGLUT for Win32 (Lhttp://www.xmission
The Cygwin/w32api for native opengl support
-F-lglut32 -lglu32 -lopengl32
-
+Fopengl, Fw32api
=head3 Cygwin/X
Requires a X server.
-Ffreeglut, Flibglut-devel
+Ffreeglut, Flibglut-devel, Fxorg-x11-devel
+
+This is detected if freeglut is installed and DISPLAY is set.
+It requires an X server.
=cut
@@ -168,24 +170,20 @@ sub runstep {
my $osname = $conf-data-get_p5('OSNAME');
# Prefer Cygwin/w32api over Cygwin/X, but use X when DISPLAY is set
-if ($^O eq 'cygwin' and $ENV{DISPLAY}) {
-$self-_add_to_libs( {
-conf= $conf,
-osname = $osname,
-cc = $cc,
-cygwin = '-lglut -L/usr/X11R6/lib -lGLU -lGL'
-} )
-}
-else {
-$self-_add_to_libs( {
+$self-_add_to_libs( {
conf= $conf,
osname = $osname,
cc = $cc,
+# Prefer Cygwin/w32api over Cygwin/X, but use X when DISPLAY is set
+($^O eq 'cygwin') ?
+ ($ENV{DISPLAY} ? (cygwin = '-lglut -L/usr/X11R6/lib -lGLU -lGL')
+: (cygwin = '/usr/bin/glut32.dll -lglu32 -lopengl32'))
+ : (),
win32_gcc = '-lglut32 -lglu32 -lopengl32',
win32_nongcc= 'opengl32.lib glu32.lib glut32.lib',
darwin = '-framework OpenGL -framework GLUT',
default = '-lglut -lGLU -lGL',
-} ) };
+} );
# On OS X check the presence of the OpenGL headers in the standard
# Fink/macports locations.
Index: lib/Parrot/Configure/Step/Methods.pm
===
--- lib/Parrot/Configure/Step/Methods.pm.orig
+++ lib/Parrot/Configure/Step/Methods.pm
@@ -119,6 +119,7 @@ sub _handle_darwin_for_macports {
cc = $cc,
win32_gcc = '-lalpha32 -lalpha32 -lopenalpha32',
win32_nongcc= 'alpha.lib',
+cygwin = '-lalpha32 -lXalpha32', # optional
darwin = 'alphadarwin.lib',
default = '-lalpha',
} );
@@ -138,6 +139,8 @@ combinations. We currently support sett
=item * MSWin32 with any C-compiler other than Fgcc.
+=item * Cygwin to override Mingw.
+
=item * Darwin.
=back
@@ -173,7 +176,7 @@ supersede the value in Cdefault.
=item * Cwin32_gcc
-Libraries to be added where OS is mswin32 and C-compiler is Fgcc.
+Libraries to be added where OS is mswin32 or cygwin and C-compiler is Fgcc.
Single whitespace-delimited string.
=item * Cwin32_nongcc
@@ -181,6 +184,12 @@ Single whitespace-delimited string.
Libraries to be added where OS is mswin32 and C-compiler is not Fgcc.
Single whitespace-delimited string.
+=item * Ccygwin
+
+Optional libraries to be added where OS is cygwin. This overrides Cwin32_gcc
+if defined.
+Single whitespace-delimited string.
+
=item * Cdarwin
Libraries to be added where OS is Darwin. Do not supply a value if the value
@@ -197,7 +206,8 @@ sub _add_to_libs {
my $args = shift;
croak _add_to_libs() takes hashref: $! unless ref($args) eq 'HASH';
my $platform =
- (($args-{osname} =~ /mswin32/i ||
+ $args-{osname} =~ /cygwin/i ? 'cygwin'
+:(($args-{osname} =~ /mswin32/i ||
$args-{osname} =~ /cygwin/i)
$args-{cc} =~ /^gcc/i) ? 'win32_gcc'
: $args-{osname} =~ /mswin32/i? 'win32_nongcc'
Index: config/gen/opengl.pm
===
--- config/gen/opengl.pm.orig
+++ config/gen/opengl.pm
@@ -447,6 +447,9 @@ sub runstep {
# $ENV{HOME}/src/osx-insane/usr/X11R6 1/include/GL/*.h,
);
+# X freeglut only if DISPLAY is set, otherwise use native w32api GLUT
+shift @header_globs if $^O eq 'cygwin' and !$ENV{DISPLAY};
+
print \nChecking for OpenGL headers using the following globs:\n\t,
join(\n\t, @header_globs), \n
if $verbose;
Re: [perl #58034] [TODO] save config_args for make reconfig
James Keenan via RT schrieb:
Reini,
I would argue that we take a different approach with 'make reconfig'.
We need to get rid of it entirely. In Parrot years, it's ancient code:
$ svn blame config/gen/makefiles/root.in | grep -n -A 3 reconfig
...
--
708: 4916 boemmels @echo reconfig: 'clean' and redo
configuration.
...
--
1769: 7554 bernhard reconfig : clean
1770- 22967 bernhard $(PERL) Configure.pl
And it doesn't DWIM. Nowadays, if you want to redo configuration, you
need to call 'make realclean', as 'make clean' does not delete the files
created by Configure.pl. (If you want to re-run one particular
configuration step, use tools/dev/reconfigure.pl.)
I guess that the existence of 'make reconfig' completely escaped me. If
I had known about it, I would have recommended excising it, as it's
inconsistent with the way Configure.pl has worked for at least two years.
Now, there may very well be other reasons to retain the command-line
options. Parrot::Configure::Options processes those options, and the
most important of them are available for the lifetime of the
Parrot::Configure object. Given that, the question arises as to whether
they should be retained in the Makefile and/or in Parrot::Config. I'm
now developing file-based configuration in a branch, and in that branch
I've chosen to store the parsed version of that file in Parrot::Config.
So, my recommendation is to hold off on deciding how to store
command-line options for the next week. After I present this patch for
file-based configuration, we'll be in a better position to decide
how/where to store the command-line options data.
Hmm,
Attached is my improved version which got the GEN_CONFIG dependencies right.
My goal is to get rid of the required make clean and to get all
dependencies right. With a required make clean we are loosers.
The GEN_CONFIG target does not need clean anymore. It needs to be more
fine-tuned though.
This solves the Makefile problem.
What you plan with the perl libraries is fine, but the driver for the
dependencies to finally get rid of make clean should be the Makefiles.
The toolkit could be Parrot::Config a la tools/dev/reconfigure.pl
I got rid of [perl #39742] [BUG] installed parrot conflicts with dev
parrot with my 39742-installed-conflict.patch.
Now just the proper dependencies and install are missing.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
2008-08-17 [EMAIL PROTECTED]
make reconfig ignores the given Configure.pl command-line args.
We need to save the config_args somewhere to be able to do
make reconfig like
CONFIG_ARGS = @config_args@
$(GEN_CONFIGS) : Makefile
$(PERL) Configure.pl $(CONFIG_ARGS)
We really should track all dependencies and do a make reconfig automatically.
The CONFIG_ARGS should be stored in Makefile.
config_args should be stored in config_lib.pasm as in perl5 also.
Index: parrot-svn/config/gen/makefiles/root.in
===
--- parrot-svn.orig/config/gen/makefiles/root.in
+++ parrot-svn/config/gen/makefiles/root.in
@@ -19,6 +19,7 @@
DEVEL = @DEVEL@
VERSION = @[EMAIL PROTECTED](DEVEL)
SOVERSION = @VERSION@
+CONFIG_ARGS = @config_args@
# Override at least PREFIX with the install location if you're going
# to be using this outside of your build area.
@@ -999,6 +1000,19 @@ $(INC_DIR)/oplib/ops.h lib/Parrot/OpLib/
lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(OPS_DIR)/ops.num $(OPS_DIR)/ops.skip
$(PERL) $(BUILD_TOOLS_DIR)/ops2pm.pl $(OPS_FILES)
+lib/Parrot/Config/Generated.pm \
+$(SRC_DIR)/platform.c \
+#CONDITIONED_LINE(platform_asm):$(SRC_DIR)/platform_asm.s \
+#CONDITIONED_LINE(has_opengl):config/gen/call_list/opengl.in \
+#CONDITIONED_LINE(has_glut):$(SRC_DIR)/glut_callbacks.c \
+config_lib.pasm \
+$(BUILD_TOOLS_DIR)/dynpmc.pl \
+$(BUILD_TOOLS_DIR)/dynoplibs.pl \
+ : Configure.pl lib/Parrot/Configure.pm \
+ lib/Parrot/Configure/Step/List.pm lib/Parrot/Configure/Step/Methods.pm
+ @echo Makefile out-of-date: reconfigure
+ $(PERL) Configure.pl $(CONFIG_ARGS)
+
###
#
# Examples (Assembly):
@@ -1774,7 +1788,7 @@ svnclobber : .svn
$(PERL) tools/dev/svnclobber.pl
reconfig : clean
- $(PERL) Configure.pl
+ $(PERL) Configure.pl $(CONFIG_ARGS)
manitest :
$(PERL) tools/dev/manicheck.pl
Index: parrot-svn/Configure.pl
===
--- parrot-svn.orig/Configure.pl
+++ parrot-svn/Configure.pl
@@ -63,6 +63,8 @@ $conf-add_steps( get_steps_list() );
# from Parrot::Configure::Data
$conf-options-set( %{$args} );
+# save the command-line
+$conf-data-set(config_args = join( , @ARGV));
# Log files created by Configure.pl in MANIFEST.configure.generated
$conf-{active_configuration} = 1;
Re: [perl #57668] [BUG][PATCH] Iterate through the current namespace causes a segfault
chromatic schrieb: On Saturday 16 August 2008 15:36:42 Bob Rogers wrote: This test (t/pmc/namespace.t:65) seems to cause an unbounded memory-gobbling loop on my configuration (GNU/Linux/x86). It only happens rarely ( 1 in 35 so far), though it eats my machine when it does . . . I take that back; I can reproduce this every time using t/harness, and not at all with prove. I have been using the following Makefile target: small-test : $(PERL) t/harness $(EXTRA_TEST_ARGS) t/pmc/namespace.t If I set ulimit -v, I get a segfault in test #65 (without the todo). Ah good, Christoph and I tried to track that down the other day. I'll do my best to fix it, but I may not have reliable network access. If you don't see a patch from me before the release, +1 to SKIP it. 1+ to SKIP it also. On cygwin the namespace test 65 just hangs. $ ./parrot t/pmc/namespace_65.pir bar 2 hangs for several minutes $ -- Reini Urban http://phpwiki.org/ http://murbreak.at
[perl #57694] You are nominated for an Associates
Spam -- Reini Urban
Re: [perl #57548] [TODO] enhance #CONDITIONED_LINE by recursive logical expressions as in LISP
2008/8/3 Reini Urban via RT [EMAIL PROTECTED]:
First patch was wrong, this is ok. (conf arg was missing)
And this patch actually implements this feature for 90%. (and or not mult.keys)
Just the parenthesis grouping is missing. (and key (not key))
I'll commit more useful examples later, where I actually need them.
For now just
the root Makefile is changed.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: parrot-svn/lib/Parrot/Configure/Compiler.pm
===
--- parrot-svn.orig/lib/Parrot/Configure/Compiler.pm
+++ parrot-svn/lib/Parrot/Configure/Compiler.pm
@@ -181,17 +181,41 @@ to '#', Creplace_slashes to enabled, a
If the name of the file being generated ends in CMakefile, this option
defaults to true.
-=item conditioned_lines
+=item conditioned_lines and #+(): #-():
-If conditioned_lines is true, then lines in the file that begin with:
-C#CONDITIONED_LINE(var): are skipped if the var condition is false. Lines
-that begin with C#INVERSE_CONDITIONED_LINE(var): are skipped if
-the var condition is true. For instance:
+If conditioned_lines is true, then lines in the file that begin with
+C#+(expr): are skipped if the expr condition is false.
+Lines that begin with C#-(var): are skipped if the expr condition is true.
+For legacy the old syntax #CONDITIONED_LINE(var): and
+#INVERSE_CONDITIONED_LINE(var): is also supported.
+
+A condition expr may be a single keyword, which is true if a config key is true
+or equal to the platform name,
+or a logical combination or (and expr1 expr2...) or (or expr1 expr2...) or
+(not expr) as in the common lisp reader, 'OR' being the default for multiple keys.
+Multiple keys are space seperated.
+
+TODO: Keys may also consist of key=value pairs, where the key is checked for
+equalness to the value. Note that values may contain no spaces here.
+TODO: support quotes in values
- #CONDITIONED_LINE(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
+ #+(var1 var2...) defaults to #+(or var1 var2...)
+ #-(var1 var2...) defaults to #-(or var1 var2...)
+
+For instance:
+
+ #+(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
will be processed if the platform is win32.
+ #-(win32 cygwin): $(SRC_DIR)/atomic/gcc_x86$(O)
+
+will be skipped if the platform is win32 or cygwin.
+
+ #+(and win32 glut (not cygwin)):
+
+will be used on win32 and if glut is defined, but not on cygwin.
+
=item comment_type
This option takes has two possible values, C# or C/*. If present and
@@ -320,12 +344,20 @@ sub genfile {
last;
}
if ( $options{conditioned_lines} ) {
-if ( $line =~ m/^#CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
-next unless $conf-data-get($1);
+ # allow multiple keys and nested parens here
+if ( $line =~ m/^#([-+])\((.+)\):(.*)/s ) {
+ my $truth = cond_eval($conf, $2);
+ next if ($1 eq '-') and $truth;
+ next if ($1 eq '+') and not $truth;
+$line = $3;
+ }
+ # but here not (legacy)
+ elsif ( $line =~ m/^#CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
+next unless cond_eval($conf, $1);
$line = $2;
}
elsif ( $line =~ m/^#INVERSE_CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
-next if $conf-data-get($1);
+next if cond_eval($conf, $1);
$line = $2;
}
}
@@ -425,6 +457,42 @@ sub genfile {
move_if_diff( $target.tmp, $target, $options{ignore_pattern} );
}
+# Just checks the logical truth of the hash value (exists and not empty).
+# Also check the platform name if the hash key does not exist.
+# Recursive, evaluate AND, OR, NOT with multiple keys.
+# Check for key=value, like #+(ld=gcc)
+sub cond_eval {
+my $conf = shift;
+my $expr = shift;
+# TODO: parse parenthesis groups, (and (not win32) has_glut)
+$expr =~ s/[\(\)]/ /g; # currently ignored
+my @keys = split /\s+/, $expr;
+my $key = $expr;
+if (@keys 1) { # multiple keys: recurse into
+ my $truth;
+ my $op = pop @keys;
+ if ($key =~ /^(or|and|not)$/i) {
+ $op = lc($key);
+ $key = pop @keys;
+ }
+ while (!$truth and $key) {
+ $truth = cond_eval($conf, $key);
+ if ($op eq 'not') { $truth = $truth ? 0 : 1; }
+ elsif ($op eq 'and') { $truth = (@keys1) if $truth; }
+ $key = pop @keys;
+ }
+ return $truth;
+}
+if ($key =~ /^(\w+)=(.+)$/) {
+ return $conf-data-get($1) eq $2;
+} else {
+ #FIXME: return $conf-data()-exists($key)
+ return exists($conf-data-{c}-{$key})
+? $conf-data()-get($key)
+ : $key eq $^O;
+ }
+}
+
sub append_configure_log {
my $conf = shift;
my $target = shift;
@@ -452,6 +520,6 @@ sub append_configure_log {
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
-# fill-column: 100
+# fill-column: 80
# End:
# vim: expandtab shiftwidth=4:
Index: parrot-svn/lib/Parrot/Configure/Data.pm
Re: [perl #57548] [TODO] enhance #CONDITIONED_LINE by recursive logical expressions as in LISP
2008/8/6 Reini Urban [EMAIL PROTECTED]:
2008/8/3 Reini Urban via RT [EMAIL PROTECTED]:
First patch was wrong, this is ok. (conf arg was missing)
And this patch actually implements this feature for 90%. (and or not
mult.keys)
Just the parenthesis grouping is missing. (and key (not key))
I'll commit more useful examples later, where I actually need them.
For now just the root Makefile is changed.
Adding testcases actually helps.
This patch adds tests, and fixes a nasty recursion bug.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: parrot-svn/lib/Parrot/Configure/Compiler.pm
===
--- parrot-svn.orig/lib/Parrot/Configure/Compiler.pm
+++ parrot-svn/lib/Parrot/Configure/Compiler.pm
@@ -1,5 +1,5 @@
-# Copyright (C) 2001-2007, The Perl Foundation.
-# $Id: Compiler.pm 26761 2008-04-05 02:32:23Z jkeenan $
+# Copyright (C) 2001-2008, The Perl Foundation.
+# $Id: Compiler.pm 29966 2008-08-03 16:09:47Z jkeenan $
=head1 NAME
@@ -175,23 +175,47 @@ replacement syntax assumes the source te
=item makefile
-If set to a true value, this flag sets (unless overriden) Ccomment_type
+If set to a true value, this flag sets (unless overridden) Ccomment_type
to '#', Creplace_slashes to enabled, and Cconditioned_lines to enabled.
If the name of the file being generated ends in CMakefile, this option
defaults to true.
-=item conditioned_lines
+=item conditioned_lines and #+(): #-():
-If conditioned_lines is true, then lines in the file that begin with:
-C#CONDITIONED_LINE(var): are skipped if the var condition is false. Lines
-that begin with C#INVERSE_CONDITIONED_LINE(var): are skipped if
-the var condition is true. For instance:
+If conditioned_lines is true, then lines in the file that begin with
+C#+(expr): are skipped if the expr condition is false.
+Lines that begin with C#-(var): are skipped if the expr condition is true.
+For legacy the old syntax #CONDITIONED_LINE(var): and
+#INVERSE_CONDITIONED_LINE(var): is also supported.
+
+A condition expr may be a single keyword, which is true if a config key is true
+or equal to the platform name,
+or a logical combination or (and expr1 expr2...) or (or expr1 expr2...) or
+(not expr) as in the common lisp reader, 'OR' being the default for multiple keys.
+Multiple keys are space seperated.
+
+TODO: Keys may also consist of key=value pairs, where the key is checked for
+equalness to the value. Note that values may contain no spaces here.
+TODO: support quotes in values
- #CONDITIONED_LINE(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
+ #+(var1 var2...) defaults to #+(or var1 var2...)
+ #-(var1 var2...) defaults to #-(or var1 var2...)
+
+For instance:
+
+ #+(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
will be processed if the platform is win32.
+ #-(win32 cygwin): $(SRC_DIR)/atomic/gcc_x86$(O)
+
+will be skipped if the platform is win32 or cygwin.
+
+ #+(and win32 glut (not cygwin)):
+
+will be used on win32 and if glut is defined, but not on cygwin.
+
=item comment_type
This option takes has two possible values, C# or C/*. If present and
@@ -219,21 +243,21 @@ a very helpful option when writing Makef
=item expand_gmake_syntax
-If set to a true value, then certain types of gmake syntax will be expanded
+If set to a true value, then certain types of Igmake syntax will be expanded
into their full equivalents. For example:
$(wildcard PATTERN)
-Will be replaced Iat config time with the list of files that match this
+Will be replaced Bat config time with the list of files that match this
pattern. Note! Be very careful when determining whether or not to disable
-this expansion during config time and letting gmake evaluate these: the
+this expansion during config time and letting Igmake evaluate these: the
config system itself may change state of the filesystem, causing the
directives to expand differently depending on when they're run. Another
potential issue to consider there is that most makefiles, while generated
-from the root directory, are Irun from a subdirectory. So relative path names
+from the root directory, are Brun from a subdirectory. So relative path names
become an issue.
-The gmake replacements are done repeatedly on a single line, so nested
+The Igmake replacements are done repeatedly on a single line, so nested
syntax works ok.
=over 4
@@ -277,7 +301,9 @@ sub genfile {
}
if ( $options{comment_type} ) {
-my @comment = ( DO NOT EDIT THIS FILE, Generated by . __PACKAGE__ . from $source );
+my @comment = ( 'ex: set ro ft=c:',
+'DO NOT EDIT THIS FILE',
+'Generated by ' . __PACKAGE__ . from $source );
if ( $options{comment_type} eq '#' ) {
foreach my $line (@comment) {
@@ -294,8 +320,7 @@ sub genfile {
else {
die Unknown comment type '$options{comment_type}';
}
-foreach my $line (@comment) { print $out $line; }
-print $out
Re: [perl #57548] [TODO] enhance #CONDITIONED_LINE by recursive logical expressions as in LISP
2008/8/6 Reini Urban [EMAIL PROTECTED]:
2008/8/6 Reini Urban [EMAIL PROTECTED]:
2008/8/3 Reini Urban via RT [EMAIL PROTECTED]:
First patch was wrong, this is ok. (conf arg was missing)
And this patch actually implements this feature for 90%. (and or not
mult.keys)
Just the parenthesis grouping is missing. (and key (not key))
I'll commit more useful examples later, where I actually need them.
For now just the root Makefile is changed.
Adding testcases actually helps.
This patch adds tests, and fixes a nasty recursion bug.
And this tests the key=value feature also.
Now my laptop battery is over soon...
Index: parrot-svn/lib/Parrot/Configure/Compiler.pm
===
--- parrot-svn.orig/lib/Parrot/Configure/Compiler.pm
+++ parrot-svn/lib/Parrot/Configure/Compiler.pm
@@ -1,5 +1,5 @@
-# Copyright (C) 2001-2007, The Perl Foundation.
-# $Id: Compiler.pm 26761 2008-04-05 02:32:23Z jkeenan $
+# Copyright (C) 2001-2008, The Perl Foundation.
+# $Id: Compiler.pm 29966 2008-08-03 16:09:47Z jkeenan $
=head1 NAME
@@ -175,23 +175,47 @@ replacement syntax assumes the source te
=item makefile
-If set to a true value, this flag sets (unless overriden) Ccomment_type
+If set to a true value, this flag sets (unless overridden) Ccomment_type
to '#', Creplace_slashes to enabled, and Cconditioned_lines to enabled.
If the name of the file being generated ends in CMakefile, this option
defaults to true.
-=item conditioned_lines
+=item conditioned_lines and #+(): #-():
-If conditioned_lines is true, then lines in the file that begin with:
-C#CONDITIONED_LINE(var): are skipped if the var condition is false. Lines
-that begin with C#INVERSE_CONDITIONED_LINE(var): are skipped if
-the var condition is true. For instance:
+If conditioned_lines is true, then lines in the file that begin with
+C#+(expr): are skipped if the expr condition is false.
+Lines that begin with C#-(var): are skipped if the expr condition is true.
+For legacy the old syntax #CONDITIONED_LINE(var): and
+#INVERSE_CONDITIONED_LINE(var): is also supported.
+
+A condition expr may be a single keyword, which is true if a config key is true
+or equal to the platform name,
+or a logical combination or (and expr1 expr2...) or (or expr1 expr2...) or
+(not expr) as in the common lisp reader, 'OR' being the default for multiple keys.
+Multiple keys are space seperated.
+
+TODO: Keys may also consist of key=value pairs, where the key is checked for
+equalness to the value. Note that values may contain no spaces here.
+TODO: support quotes in values
- #CONDITIONED_LINE(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
+ #+(var1 var2...) defaults to #+(or var1 var2...)
+ #-(var1 var2...) defaults to #-(or var1 var2...)
+
+For instance:
+
+ #+(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
will be processed if the platform is win32.
+ #-(win32 cygwin): $(SRC_DIR)/atomic/gcc_x86$(O)
+
+will be skipped if the platform is win32 or cygwin.
+
+ #+(and win32 glut (not cygwin)):
+
+will be used on win32 and if glut is defined, but not on cygwin.
+
=item comment_type
This option takes has two possible values, C# or C/*. If present and
@@ -219,21 +243,21 @@ a very helpful option when writing Makef
=item expand_gmake_syntax
-If set to a true value, then certain types of gmake syntax will be expanded
+If set to a true value, then certain types of Igmake syntax will be expanded
into their full equivalents. For example:
$(wildcard PATTERN)
-Will be replaced Iat config time with the list of files that match this
+Will be replaced Bat config time with the list of files that match this
pattern. Note! Be very careful when determining whether or not to disable
-this expansion during config time and letting gmake evaluate these: the
+this expansion during config time and letting Igmake evaluate these: the
config system itself may change state of the filesystem, causing the
directives to expand differently depending on when they're run. Another
potential issue to consider there is that most makefiles, while generated
-from the root directory, are Irun from a subdirectory. So relative path names
+from the root directory, are Brun from a subdirectory. So relative path names
become an issue.
-The gmake replacements are done repeatedly on a single line, so nested
+The Igmake replacements are done repeatedly on a single line, so nested
syntax works ok.
=over 4
@@ -277,7 +301,9 @@ sub genfile {
}
if ( $options{comment_type} ) {
-my @comment = ( DO NOT EDIT THIS FILE, Generated by . __PACKAGE__ . from $source );
+my @comment = ( 'ex: set ro ft=c:',
+'DO NOT EDIT THIS FILE',
+'Generated by ' . __PACKAGE__ . from $source );
if ( $options{comment_type} eq '#' ) {
foreach my $line (@comment) {
@@ -294,8 +320,7 @@ sub genfile {
else {
die Unknown comment type '$options{comment_type
Re: [perl #57548] [TODO] enhance #CONDITIONED_LINE by recursive logical expressions as in LISP
2008/8/6 Reini Urban [EMAIL PROTECTED]:
2008/8/6 Reini Urban [EMAIL PROTECTED]:
2008/8/6 Reini Urban [EMAIL PROTECTED]:
2008/8/3 Reini Urban via RT [EMAIL PROTECTED]:
First patch was wrong, this is ok. (conf arg was missing)
And this patch actually implements this feature for 90%. (and or not
mult.keys)
Just the parenthesis grouping is missing. (and key (not key))
I'll commit more useful examples later, where I actually need them.
For now just the root Makefile is changed.
Adding testcases actually helps.
This patch adds tests, and fixes a nasty recursion bug.
And this tests the key=value feature also.
Now my laptop battery is over soon...
A little bit of power is still left. This patch is against the current
svn of Compiler.pm actually. Sorry.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: parrot-svn/lib/Parrot/Configure/Compiler.pm
===
--- parrot-svn.orig/lib/Parrot/Configure/Compiler.pm
+++ parrot-svn/lib/Parrot/Configure/Compiler.pm
@@ -181,17 +181,41 @@ to '#', Creplace_slashes to enabled, a
If the name of the file being generated ends in CMakefile, this option
defaults to true.
-=item conditioned_lines
+=item conditioned_lines and #+(): #-():
-If Cconditioned_lines is true, then lines in the file that begin with:
-C#CONDITIONED_LINE(var): are skipped if the Cvar condition is false. Lines
-that begin with C#INVERSE_CONDITIONED_LINE(var): are skipped if
-the Cvar condition is true. For instance:
+If conditioned_lines is true, then lines in the file that begin with
+C#+(expr): are skipped if the expr condition is false.
+Lines that begin with C#-(var): are skipped if the expr condition is true.
+For legacy the old syntax #CONDITIONED_LINE(var): and
+#INVERSE_CONDITIONED_LINE(var): is also supported.
+
+A condition expr may be a single keyword, which is true if a config key is true
+or equal to the platform name,
+or a logical combination or (and expr1 expr2...) or (or expr1 expr2...) or
+(not expr) as in the common lisp reader, 'OR' being the default for multiple keys.
+Multiple keys are space seperated.
+
+TODO: Keys may also consist of key=value pairs, where the key is checked for
+equalness to the value. Note that values may contain no spaces here.
+TODO: support quotes in values
- #CONDITIONED_LINE(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
+ #+(var1 var2...) defaults to #+(or var1 var2...)
+ #-(var1 var2...) defaults to #-(or var1 var2...)
+
+For instance:
+
+ #+(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
will be processed if the platform is win32.
+ #-(win32 cygwin): $(SRC_DIR)/atomic/gcc_x86$(O)
+
+will be skipped if the platform is win32 or cygwin.
+
+ #+(and win32 glut (not cygwin)):
+
+will be used on win32 and if glut is defined, but not on cygwin.
+
=item comment_type
This option takes has two possible values, C# or C/*. If present and
@@ -321,12 +345,20 @@ sub genfile {
last;
}
if ( $options{conditioned_lines} ) {
-if ( $line =~ m/^#CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
-next unless $conf-data-get($1);
+ # allow multiple keys and nested parens here
+if ( $line =~ m/^#([-+])\((.+)\):(.*)/s ) {
+ my $truth = cond_eval($conf, $2);
+ next if ($1 eq '-') and $truth;
+ next if ($1 eq '+') and not $truth;
+$line = $3;
+ }
+ # but here not (legacy)
+ elsif ( $line =~ m/^#CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
+next unless cond_eval($conf, $1);
$line = $2;
}
elsif ( $line =~ m/^#INVERSE_CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
-next if $conf-data-get($1);
+next if cond_eval($conf, $1);
$line = $2;
}
}
@@ -426,6 +458,41 @@ sub genfile {
move_if_diff( $target.tmp, $target, $options{ignore_pattern} );
}
+# Just checks the logical truth of the hash value (exists and not empty).
+# Also check the platform name if the hash key does not exist.
+# Recursive, evaluate AND, OR, NOT with multiple keys.
+# Check for key=value, like #+(ld=gcc)
+sub cond_eval {
+my $conf = shift;
+my $expr = shift;
+# TODO: parse parenthesis groups, (and (not win32) has_glut)
+$expr =~ s/[\(\)]/ /g; # currently ignored
+my @keys = split /\s+/, $expr;
+if (@keys 1) { # multiple keys: recurse into
+ my ($truth, $key);
+ my $op = $key = shift @keys;
+ if ($op =~ /^(or|and|not)$/i) {
+ $op = lc($op);
+ $key = shift @keys;
+ }
+ while (!$truth and $key) {
+ $truth = cond_eval($conf, $key);
+ if ($op eq 'not') { $truth = $truth ? 0 : 1; }
+ elsif ($op eq 'and') { $truth = (@keys1) if $truth; }
+ $key = shift @keys;
+ }
+ return $truth;
+}
+if ($expr =~ /^(\w+)=(.+)$/) {
+ return $conf-data-get($1) eq $2;
+} else {
+ #FIXME: return $conf-data()-exists($key)
+ return exists($conf-data-{c}-{$expr
Re: Branching
2008/8/5 Will Coleda [EMAIL PROTECTED]: So these branch commands actually create branches on the svn repository that's doing the hosting, so they're defacto shared with the community in the obvious location? (presuming you're online and pushing changes back?) That seems to be the best of both worlds, presuming it handles the merging better/faster/cleaner than 'svn merge' does. But this is only the best for committers. For non-committers who would have to wait longer time to get their patches applied it would be better to use a git branch and merge it more often to get in the upstream updates. Like my bigger patches, which are often heavily outdated by other changes when they are applied. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: Merged pdd25cx branch
2008/8/3 Allison Randal [EMAIL PROTECTED]: Keep an eye out for exception-related problems in the next couple of weeks before the release. parrot_debugger has some unresolved symbols. -- Reini Urban
Re: [perl #38392] [BUG] FreeBSD bugs with JIT on t/op/trans.t
James Keenan via RT schrieb: On Sat Aug 02 05:06:31 2008, rurban wrote: On Sat Jun 14 17:17:03 2008, [EMAIL PROTECTED] wrote: Can anyone on FreeBSD give us an update on this issue? freebsd7, recent parrot svn (r29922) passes the t/op/trans.t tests Thanks for looking into this, Reini. Now, would these failures have cleared up because you're working on FreeBSD 7 as distinct from the FreeBSD 6 on which the problems were reported? I have no idea of the difference of freebsd6 to 7. I assume there's nothing important, and that recent parrot fixes fixed that. perl is still 5.8.8, gcc is now higher: 4.2.1 -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #39742] [BUG] installed parrot conflicts with dev parrot.
Reini Urban schrieb:
Andy Dougherty schrieb:
On Sat, 14 Jun 2008, James Keenan via RT wrote:
Can we get an update as to the issues raised in this ticket?
The general issue
installeld parrot conflicts with dev parrot -- at least
when a shared libparrot.so is used
is, as far as I know, unsolved. A longer discussion can be found here
(and the surrounding thread):
http://www.nntp.perl.org/group/perl.perl6.internals/2006/03/msg33340.html
It should be added that this does not affect cygwin and mingw.
just shared a libparrot.so
It is still true that
gcc ... -L/usr/local/lib ... -L.../blib/lib -lparrot -L/usr/local/lib
-lgmp -lreadline
would prefer a /usr/local/lib/libparrot.dll.a if there would be some,
(there is even a /usr/lib/libparrot.dll.a)
but the nature of this import lib is affected by PATH,
which is so constructed that blib/lib prepends the installed libparrot.
Just the perl5 ldflags setting have to fixed in the config hints step.
-L/usr/local/lib can be stripped at all, if some parrot lib pulls that
in. If not it has to be put after -lparrot.
With the recent merge which changed the exception handling,
I was able to reproduce and fix the problem not being able to compile a
fresh parrot with an already installed shared libparrot.
So my previous comment was wrong.
The reason for the problem is simple and two-fold:
1. libs belongs to the end.
first LDFLAGS, then LD_LOAD_FLAGS, then libparrot,
then LIBS + EXTRALIBS.
dynpmc got this wrong.
It had LIBS at the front.
a. One should not put libs before the LDFLAGS.
b. One should reverse the LIBS line in order of dependencies.
We have the problem that the libs line is generated automatically
and may contain -L/usr/lib (pulled in from libicu) and -L/usr/local/lib,
so the already installed -lparrot will be found.
So our -Lblib/lib should be at the front, best in LDFLAGS.
Note that parrot.pc got that right:
Libs: -L${libdir} -lparrot @icu_shared@ @libs@
2. remove the perl5 -L/usr/local/lib LDFLAGS which would pull in
a shared /usr/local/lib/libparrot.so before checking -Lblib/lib
-lparrot.
One fix could be to check this in Configure and move all -L from LDFLAGS
to the LIBS flag at the front.
The other fix would be to explicitly link to blib/lib/libparrot.so,
without path hacks, which could be easily fooled.
This patch adds PATH resp. LD_RUN_PATH to the parrot invocations,
similar as in perl5.
It moves a -Lpath from @ldflags@ to @libs@ in config.
It also adds emacs/vim modes to the Makefiles.
It also adds Makefile targets to regenerate the Makefiles automatically.
There's still some problem though with this env PATH=blib/lib prefix,
which looks weird and is very likely and unrelated.
./parrot.exe -o runtime/parrot/include/parrotlib.pbc \
runtime/parrot/library/parrotlib.pir
Parrot VM: PANIC: Out of mem!
C file src/gc/memory.c, line 137
Parrot file (not available), line (not available)
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
-*- diff -*-
The reason for the shared libparrot problem is simple and two-fold:
1. libs belongs to the end.
first LDFLAGS, then LD_LOAD_FLAGS, then libparrot,
then LIBS + EXTRALIBS.
dynpmc got this wrong.
It had LIBS at the front.
a. One should not put libs before the LDFLAGS.
b. One should reverse the LIBS line in order of dependencies.
We have the problem that the libs line is generated automatically
and may contain -L/usr/lib (pulled in from libicu) and -L/usr/local/lib,
so the already installed -lparrot will be found.
So our -Lblib/lib should be at the front, best in LDFLAGS.
Note that parrot.pc got that right:
Libs: -L${libdir} -lparrot @icu_shared@ @libs@
2. remove the perl5 -L/usr/local/lib LDFLAGS which would pull in
a shared /usr/local/lib/libparrot.so before checking -Lblib/lib
-lparrot.
One fix could be to check this in Configure and move all -L from LDFLAGS
to the LIBS flag at the front. I went this way.
The other fix would be to explicitly link to blib/lib/libparrot.so,
without -L path hacks.
This patch adds PATH resp. LD_RUN_PATH to the parrot invocations, similar as in perl5.
It moves a -Lpath from @ldflags@ to @libs@ in config.
It also adds emacs/vim modes to the Makefiles.
It also adds Makefile targets to regenerate the Makefiles automatically.
Index: parrot-svn/config/gen/makefiles/dynoplibs_pl.in
===
--- parrot-svn.orig/config/gen/makefiles/dynoplibs_pl.in
+++ parrot-svn/config/gen/makefiles/dynoplibs_pl.in
@@ -46,7 +46,7 @@ if ($^O eq 'MSWin32') {
}
# OPS2C Config
-our $OPS2C = $PERL -I $PATHQUOTE .
+our $OPS2C = $PERL -I $PATHQUOTE .
[EMAIL PROTECTED]@@[EMAIL PROTECTED] .
$PATHQUOTE $PATHQUOTE .
[EMAIL PROTECTED]@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] .
@@ -73,7 +73,7 @@ sub compile_cmd {
sub partial_link_cmd {
my ($target, $libs, $sources
Re: [perl #57476] [pdb] parrot version
Will Coleda (via RT) schrieb:
# New Ticket Created by Will Coleda
# Please include the string: [perl #57476]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57476
The parrot_debugger version should, IMO, be identical to the parrot
version. (e.g., it's currently reporting as 0.4 instead of 0.6.x.)
Attached patch does that.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: src/parrot_debugger.c
===
--- src/parrot_debugger.c (revision 29965)
+++ src/parrot_debugger.c (working copy)
@@ -244,7 +244,7 @@
static void
PDB_printwelcome(void)
{
-fprintf(stderr, Parrot Debugger 0.4.x\n);
+fprintf(stderr, Parrot Debugger PARROT_VERSION \n);
fprintf(stderr, \nPlease note: );
fprintf(stderr, the debugger is currently under reconstruction\n);
}
[perl #57548] [TODO] enhance #CONDITIONED_LINE by recursive logical expressions as in LISP
First patch was wrong, this is ok. (conf arg was missing)
--
Reini Urban
Index: parrot-svn/lib/Parrot/Configure/Compiler.pm
===
--- parrot-svn.orig/lib/Parrot/Configure/Compiler.pm
+++ parrot-svn/lib/Parrot/Configure/Compiler.pm
@@ -183,15 +183,38 @@ defaults to true.
=item conditioned_lines
-If conditioned_lines is true, then lines in the file that begin with:
-C#CONDITIONED_LINE(var): are skipped if the var condition is false. Lines
-that begin with C#INVERSE_CONDITIONED_LINE(var): are skipped if
-the var condition is true. For instance:
+If conditioned_lines is true, then lines in the file that begin with
+C#+(var): are skipped if the var condition is false.
+Lines that begin with C#-(var): are skipped if the var condition is true.
+For legacy the old syntax #CONDITIONED_LINE(var): and #INVERSE_CONDITIONED_LINE(var):
+is also supported.
+
+A condition var may be a single keyword, which is true if a config key is true
+or equal to the platform name,
+or a logical combination or (and var1 var2...) or (or var1 var2...) or (not var1...)
+as in common lisp macro expansion, OR being the default for multiple keys.
+Keys are space seperated.
+Keys may also consist of key=value pairs, where the key is checked for equalness
+to the value. Note that values may contain no spaces here. (TODO: support quotes
+in values)
- #CONDITIONED_LINE(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
+ #+(var1 var2...) defaults to #+(or var1 var2...)
+ #-(var1 var2...) defaults to #-(or var1 var2...)
+
+For instance:
+
+ #+(win32): $(SRC_DIR)/atomic/gcc_x86$(O)
will be processed if the platform is win32.
+ #-(win32 cygwin): $(SRC_DIR)/atomic/gcc_x86$(O)
+
+will be skipped if the platform is win32 or cygwin.
+
+ #+(and win32 glut (not cygwin)):
+
+will be used on win32 and if glut is defined, but not on cygwin.
+
=item comment_type
This option takes has two possible values, C# or C/*. If present and
@@ -321,12 +344,20 @@ sub genfile {
last;
}
if ( $options{conditioned_lines} ) {
-if ( $line =~ m/^#CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
-next unless $conf-data-get($1);
+ # allow nested parens here
+if ( $line =~ m/^#([-+])\((.+)\):(.*)/s ) {
+ my $truth = cond_eval($conf, $2);
+ next if ($1 eq '-') and $truth;
+ next if ($1 eq '+') and not $truth;
+$line = $3;
+ }
+ # but here not (legacy)
+ elsif ( $line =~ m/^#CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
+next unless cond_eval($conf, $1);
$line = $2;
}
elsif ( $line =~ m/^#INVERSE_CONDITIONED_LINE\(([^)]+)\):(.*)/s ) {
-next if $conf-data-get($1);
+next if cond_eval($conf, $1);
$line = $2;
}
}
@@ -426,6 +457,18 @@ sub genfile {
move_if_diff( $target.tmp, $target, $options{ignore_pattern} );
}
+# Just checks the logical truth of the hash value (exists and not empty)
+# TODO: also check the platform name if the hash key does not exist
+# TODO: recursive (), evaluate AND, OR, NOT with multiple keys
+# TODO: check for key=value, like #+(ld=gcc)
+sub cond_eval {
+my $conf = shift;
+my $expr = shift;
+# TODO: parse for parens and multiple keys in the expression and
+# evaluate it recursively.
+return $conf-data-get($expr);
+}
+
sub append_configure_log {
my $conf = shift;
my $target = shift;
Re: [perl #40817] [TODO] track generated files during the configure/make process
James Keenan via RT schrieb: On Tue May 06 17:15:39 2008, coke wrote: If the patch is applied, can we close this ticket? No. I only figured out how to keep track of files generated during configuration, not during build. We need some of what, IIRC, particle termed makefile trickery to keep track of files generated by make. My patch 39742-installed-conflict.patch also adds targets and dependencies for all generated Makefiles. So 39742 would satisfy this ticket also a bit. Still no full make depends which adds to the Makefile dynamically as in perl5 e.g. By far not all generated files are tracked correctly. make reconfig still needed. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[perl #38392] [BUG] FreeBSD bugs with JIT on t/op/trans.t
On Sat Jun 14 17:17:03 2008, [EMAIL PROTECTED] wrote: Can anyone on FreeBSD give us an update on this issue? freebsd7, recent parrot svn (r29922) passes the t/op/trans.t tests Determining JIT capability.yes It even works with freebsd's make, not only gmake. Summary of my parrot 0.6.4 (r0) configuration: configdate='Sat Aug 2 13:08:54 2008 GMT' Platform: osname=freebsd, archname=i386-freebsd-64int jitcapable=1, jitarchname=i386-freebsd, jitosname=FREEBSD, jitcpuarch=i386 execcapable=1 perl=perl Compiler: cc='cc', ccflags='-DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.8/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -pipe -Wdeclaration-after-statement -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 -fvisibility=hidden -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 -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -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 -Wvariadic-macros -Wwrite-strings -Wbad-function-cast -Wc++-compat -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -DHAS_GETTEXT', Linker and Libraries: ld='cc', ldflags=' -Wl,-E -L/usr/lib -L/usr/local/lib', cc_ldflags='', libs='-lm -lcrypt -lutil -pthread -lgmp -lreadline -lpcre -lcrypto -lintl' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/lib -L/usr/local/lib', load_ext='.so', ld_load_flags='-shared -L/usr/lib -L/usr/local/lib' 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 -- Reini Urban
Re: [perl #39742] [BUG] installed parrot conflicts with dev parrot.
Andy Dougherty schrieb: On Sat, 14 Jun 2008, James Keenan via RT wrote: Can we get an update as to the issues raised in this ticket? The general issue installeld parrot conflicts with dev parrot -- at least when a shared libparrot.so is used is, as far as I know, unsolved. A longer discussion can be found here (and the surrounding thread): http://www.nntp.perl.org/group/perl.perl6.internals/2006/03/msg33340.html It should be added that this does not affect cygwin and mingw. just shared a libparrot.so It is still true that gcc ... -L/usr/local/lib ... -L.../blib/lib -lparrot -L/usr/local/lib -lgmp -lreadline would prefer a /usr/local/lib/libparrot.dll.a if there would be some, (there is even a /usr/lib/libparrot.dll.a) but the nature of this import lib is affected by PATH, which is so constructed that blib/lib prepends the installed libparrot. Just the perl5 ldflags setting have to fixed in the config hints step. -L/usr/local/lib can be stripped at all, if some parrot lib pulls that in. If not it has to be put after -lparrot. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #56996] [TODO] remove non FHS-compliant searchpaths
Reini Urban schrieb: Geoffrey Broadwell via RT schrieb: On Sun, 2008-07-27 at 13:13 +0200, Reini Urban wrote: +stat $I0, conf_file, 0 +if $I0 goto conf ++# If installed into /usr/lib/parrot, not /usr/runtime/parrot +# This logic has to be reversed when installed versions should run faster +# than source builds. Reverse it now; we'll never remember to get back to this in the future. +conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX +conf_file .= /lib/parrot/include/config.fpmc +conf: +name = interpinfo .INTERPINFO_RUNTIME_PREFIX +concat name, lib/parrot/dynext/ concat name, request Since we're using PIR in both places, we should probably use the .= sugar in both places. Yes, I know the second file has some 'concat's in it already. Here's an opportunity to fix that. :-) Ok. concat to .= is easy. Why I don't want to fix that as you suggest is that I wait for feedback how it was designed to be. This patch is just a intermediate hack. Someone like particle or Allison should comment on that. It is fine for benchmarks that the source build uses runtime/parrot/include/config.fpmc. But the installed version either should NOT need to load the frozen config file when it is already linked in, or check with some global or interpinfo magic and look up the right prefix then. No useless stats please. My current plan is this: Source builds should be allowed to access runtime/parrot/include/config.fpmc and the various other config fpmc's, but the installable version, linked to install_config.fpmc must change its lib_path to allow only FHS-compliant paths, i.e remove runtime/parrot and runtime/parrot/include in favor of lib/parrot and lib/parrot/include. This must be fixed in config.pir, parrotlib.pir and src/library.c with this ticket. (Hope I forgot no other file) I'll work on that, but I have a business trip for the next two weeks. An optimization for another ticket would be to remove the run-time access to include/config.pir for linked installable's, where the frozen config.fpmc is already linked. There the sub _config should use some config detection logic (suggestion: new config key 'installed') to omit .include library/config.pir See the ticket perl #57418 [TODO] optimize _config to omit .include library/config.pir on installables -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #57418] [TODO] optimize _config to omit .include library/config.pir on installables
Parrot via RT schrieb: A useful optimization would be to remove the run-time access to include/config.pir for linked installable's, where the frozen config.fpmc is already linked. There the sub _config should use some config detection logic (suggestion: new config key 'installed') to omit .include library/config.pir It should be investigated if the interpinfo .INTERPINFO_RUNTIME_PREFIX would allow this without a new magic key, but this check would require a .include interpinfo.pasm which has the same problems. I found an old gentoo patch which did exactly this. It doesn't work as-is but the idea is the same. Here they used a getinterp[.IGLOBALS_CONFIG_HASH] I guess some years ago someone axed it with some plan how to do it later. http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/parrot/files/parrot-config.patch?rev=1.1view=log Submitted as http://bugs.gentoo.org/show_bug.cgi?id=101858 by Adrian Lambeck [EMAIL PROTECTED] -- Reini Urban http://phpwiki.org/ http://murbreak.at/ --- parrot-0.2.3/parrot-config.imc 2005-04-11 11:54:11.0 +0200 +++ parrot/parrot-config.imc 2005-08-06 13:33:29.0 +0200 @@ -27,9 +27,11 @@ .local int argc argc = argv if argc 2 goto usage -.local pmc conf_hash +.local pmc interp, conf_hash .local string key -conf_hash = _config() +.include iglobals.pasm +interp = getinterp +conf_hash = interp[.IGLOBALS_CONFIG_HASH] .local int i i = 1 loop: @@ -70,4 +72,3 @@ printerr : config-key\n exit 1 .end - .include library/config.imc
Re: [perl #55978] [PATCH] [OpenGL] cygwin fixes from donaldh++
Just found someone breaking my code...
Index: src/dynext.c
===
--- src/dynext.c(revision 28459)
+++ src/dynext.c(working copy)
@@ -276,12 +276,10 @@
/* And on cygwin replace a leading lib by cyg. */
#ifdef __CYGWIN__
if (!STRING_IS_EMPTY(lib) memcmp(lib-strstart, lib, 3) == 0) {
-strcpy(path-strstart, lib-strstart);
+path = string_append(interp,
+string_from_cstring(interp, cyg, 3),
+string_substr(interp, lib, 3, lib-strlen - 3, NULL, 0));
-path-strstart[0] = 'c';
-path-strstart[1] = 'y';
-path-strstart[2] = 'g';
-
*handle = Parrot_dlopen(path-strstart);
if (*handle)
That string_from_cstring could almost probably be CONST_STRING. If we can
swing that, it's usually much better.
I wrote this heavily optimized code which was now patched away with an
inferior solution.
Is it because of possible multibyte char paths? Then it would be better
indeed. But without mb-path support I see no advantage.
The patch for the next file:
--- lib/Parrot/Configure/Step/Methods.pm(revision 28459)
+++ lib/Parrot/Configure/Step/Methods.pm(working copy)
@@ -198,7 +198,8 @@
my $args = shift;
croak _add_to_libs() takes hashref: $! unless ref($args) eq 'HASH';
my $platform =
- ($args-{osname} =~ /mswin32/i
+ (($args-{osname} =~ /mswin32/i ||
+ $args-{osname} =~ /cygwin/i)
$args-{cc} =~ /^gcc/i) ? 'win32_gcc'
: $args-{osname} =~ /mswin32/i? 'win32_nongcc'
: $args-{osname} =~ /darwin/i ? 'darwin'
This also caused me headaches. cygwin is definitely more posix than
win32_gcc. OpenGL is the only case where it's more like mingw
(win32_gcc). But this should be done in the opengl logic then, and not
in this general case here.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: [perl #57344] [TODO] Change runtime/parrot/* to runtime/*
2008/7/28 jerry gay [EMAIL PROTECTED]: On Sun, Jul 27, 2008 at 1:56 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 10:08:06AM -0700, Geoffrey Broadwell wrote: In the source repository, the 'parrot' in runtime/parrot/foo is pointless. It's a singleton directory, and it's redundant. I think that the point of runtime/parrot/ is that we may also someday have runtime/perl6/, runtime/pynie/, runtime/cardinal/, etc. directories, which will be the canonical location for language-specific runtime libraries. yes, that was the point at the time it was introduced. however, it confuses the source tree with the install tree, and goes against a parrot policy. in the source tree (a.k.a. your working copy), we've set up the infrastructure for runtime/ to contain multiple language-level subdirs for runtime components (library, include, pmc, etc.) the intent is precisely as you suggest above. however, the project team has set a clear policy which states that in the source tree, languages must be self-contained. this policy is in place so it will be easy to transition any language from the parrot repository to an external repository. we still have some work to do to make this policy both true and easy for hll developers to implement, which will happen before parrot 1.0. following the policy, the intent is that each language in the source tree have its own runtime directory under the language root directory (e.g. languages/perl6/runtime/). if it is determined that installations of the parrot vm and parrot hlls will use a common prefix for a runtime root directory (e.g. /usr/lib/parrot/runtime/), then runtime components for both the vm and hlls may be installed to that shared location. that's an install tree policy, and as far as i'm concerned, it hasn't been addressed yet (along with many other install-related policies.) If that is the idea I will be happy to work on such a patch. But I thought that the generated runtimes go to /usr/lib/parrot/dynpmc and /usr/lib/parrot/library merged with the libs from the src_dir. But then the config logic is wrong. Is there any document which describes how the config logic for self-contained installables should work so that I can fix it? It does not work now and I want to package perl6 before 1.0 without run-time access to several /usr/runtime dirs, so that people can play with it even in its current state. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #56996] [TODO] remove non FHS-compliant searchpaths
Geoffrey Broadwell via RT schrieb: On Sun, 2008-07-27 at 13:13 +0200, Reini Urban wrote: +stat $I0, conf_file, 0 +if $I0 goto conf + +# If installed into /usr/lib/parrot, not /usr/runtime/parrot +# This logic has to be reversed when installed versions should run faster +# than source builds. Reverse it now; we'll never remember to get back to this in the future. +conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX +conf_file .= /lib/parrot/include/config.fpmc +conf: +name = interpinfo .INTERPINFO_RUNTIME_PREFIX +concat name, lib/parrot/dynext/ concat name, request Since we're using PIR in both places, we should probably use the .= sugar in both places. Yes, I know the second file has some 'concat's in it already. Here's an opportunity to fix that. :-) Ok. concat to .= is easy. Why I don't want to fix that as you suggest is that I wait for feedback how it was designed to be. This patch is just a intermediate hack. Someone like particle or Allison should comment on that. It is fine for benchmarks that the source build uses runtime/parrot/include/config.fpmc. But the installed version either should NOT need to load the frozen config file when it is already linked in, or check with some global or interpinfo magic and look up the right prefix then. No useless stats please. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #56996] [TODO] remove non FHS-compliant searchpaths
Reini Urban (via RT) schrieb: Remove /usr/runtime/parrot/include /usr/runtime/parrot /usr paths from the .include searchpath. I found this out via strace on cygwin. Attached patch tries at least /usr/lib/parrot when /usr/runtime/parrot fails. As soon as installed versions should run faster than source builds the logic has to be reversed. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ difforig runtime/parrot/library/config.pir runtime/parrot/library/parrotlib.pir diff -u runtime/parrot/library/config.pir.orig runtime/parrot/library/config.pir --- runtime/parrot/library/config.pir.orig 2008-07-05 10:04:43.0 + +++ runtime/parrot/library/config.pir 2008-07-27 11:06:40.84375 + @@ -50,10 +50,19 @@ .local string conf_file conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX conf_file .= /runtime/parrot/include/config.fpmc - +stat $I0, conf_file, 0 +if $I0 goto conf + +# If installed into /usr/lib/parrot, not /usr/runtime/parrot +# This logic has to be reversed when installed versions should run faster +# than source builds. +conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX +conf_file .= /lib/parrot/include/config.fpmc +conf: open CONF, conf_file, $I0 = defined CONF if $I0 goto ok1 + printerr Can't read ' printerr conf_file printerr ': diff -u runtime/parrot/library/parrotlib.pir.orig runtime/parrot/library/parrotlib.pir --- runtime/parrot/library/parrotlib.pir.orig 2008-02-23 18:27:07.0 + +++ runtime/parrot/library/parrotlib.pir 2008-07-27 11:07:12.734375000 + @@ -143,8 +143,19 @@ stat $I0, name, 0 if $I0 goto END -name = runtime/parrot/dynext/ +concat name, ext +stat $I0, name, 0 +if $I0 goto END + +# This logic has to be reversed when installed versions should run faster +# than source builds. +.include interpinfo.pasm +name = interpinfo .INTERPINFO_RUNTIME_PREFIX +concat name, lib/parrot/dynext/ concat name, request +stat $I0, name, 0 +if $I0 goto END + concat name, ext stat $I0, name, 0 if $I0 goto END
Re: Clue! (or, Attention Crazy People Looking for a Project)
chromatic schrieb: Clue is an ANSI C compiler (C89, some C99) that targets high-level languages such as Lua, Javascript or Perl. It supports the entire C language, including pointer arithmetic, and can be used to run arbitrary pure-C programs. http://cluecc.sourceforge.net/ It compiles C code to Lua, Javascript or Perl5. And for LuaJIT it is only half as slow as the gcc backend. So this is a project to run C code dynamically at half-speed. Wonder how fast a parrot backend would be, compared to our c99. I have the vague idea that c99 would be faster just looking at the code. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
[perl #57224] [BUG] darwin hints with -arch ppc64
Discussed at #parrot. Attached patch was confirmed to work. Why did it not fail before? Because the op added -arch ppc64 by himself, default darwin perl does not contain ppc64. -- Reini Urban
Re: [perl #57188] [PATCH] pbc_to_exe --install
2008/7/22 Mark Glines [EMAIL PROTECTED]: 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? Because my patch is on top of another open ticket of mine for this file. Here are both. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ difforig tools/dev/pbc_to_exe_gen.pl 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-20 16:13:26.65625 +0200 +++ tools/dev/pbc_to_exe_gen.pl 2008-07-22 13:43:04.62500 +0200 @@ -11,6 +11,22 @@ __END__ #! parrot +=head1 TITLE + +pbc_to_exe + +=head2 SYNOPSIS + + pbc_to_exe my.pbc + = my.exe + + pbc_to_exe my.pbc --install + = installable_my.exe + +Warning! With -install there must be no directory prefix in the first arg yet. + +=cut + .include 'library/config.pir' .sub 'main' :main @@ -54,8 +70,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 +infile_len = length infile +infile_len -= 3 + +cfile = substr infile, 0, infile_len +cfile .= 'c' + +dec infile_len +objfile = substr infile, 0, infile_len +exefile = 'installable_' +exefile.= objfile +exefile.= exe +objfile.= obj +.return(infile, cfile, objfile, exefile) + proper_args: .local string infile, cfile, objfile, obj, exefile, exe @@ -270,6 +318,7 @@ .sub 'compile_file' .param string cfile .param string objfile +.param int install :optional $P0 = '_config'() .local string cc, ccflags, cc_o_out, osname, build_dir, slash @@ -318,6 +367,7 @@ .sub 'link_file' .param string objfile .param string exefile +.param int install :optional $P0 = '_config'() .local string cc, ld, link_dynamic, linkflags, ld_out, libparrot, libs, o @@ -336,11 +386,17 @@ slash= $P0['slash'] icushared= $P0['icu_shared'] -.local string config, pathquote +.local string config, pathquote, exeprefix +exeprefix = substr exefile, 0, 12 config = concat build_dir, slash config.= 'src' config.= slash +if exeprefix == 'installable_' goto config_install config.= 'parrot_config' +goto config_cont + config_install: +config.= 'install_config' + config_cont: config.= o pathquote = '' unless osname == 'MSWin32' goto not_windows @@ -361,6 +417,8 @@ link .= objfile link .= pathquote link .= ' ' +link .= config +link .= ' ' link .= rpath link .= ' ' link .= libparrot @@ -372,8 +430,6 @@ link .= libs link .= ' ' link .= icushared -link .= ' ' -link .= config say link .local int status
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/
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/
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/
pbc install_config: howto install perl6 and languages?
How is make install for the pbc_to_exe generated languages supposed to work? For the utils you simply link to a fixed install_config.o with fixed builddir. But the languages are generated from a .pir file with hardcoded, wrong builddir. I think about adding support for an optional --install arg in all pir's for the pbc_to_exe step sub 'compile_file', and use the install builddir then. Maybe also replace in 'link_file' parrot_config with install_config. Or is there a possibility to override the config hash in the pbc somehow? -- Forwarded message -- From: Reini Urban [EMAIL PROTECTED] Date: 2008/7/21 Subject: Re: [ANNOUNCEMENT] Updated: parrot-0.6.4-1 with parrot-perl6 and parrot-languages To: [EMAIL PROTECTED] 2008/7/21 Michael Schaap: On 20-Jul-2008 17:36, Michael Schaap wrote: On 19-Jul-2008 21:42, Reini Urban wrote: Michael Schaap schrieb: Is perl6 supposed to (somewhat) work, yet? I get: % perl6 -e 'say Hello, World!' load_bytecode couldn't find file 'P6object.pbc' current instr.: 'onload' pc 0 (src/gen_builtins.pir:28) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) P6object does exist, in /usr/lib/parrot/library. If I cd to this directory first, I get: % cd /usr/lib/parrot/library; perl6 -e 'say Hello, World!' Null PMC access in get_string() current instr.: 'parrot;P6metaclass;add_parent' pc 119 (runtime/parrot/library/P6object.pir:137) called from Sub 'parrot;P6metaclass;add_parent' pc 241 (runtime/parrot/library/P6object.pir:215) called from Sub 'parrot;P6metaclass;register' pc 411 (runtime/parrot/library/P6object.pir:295) called from Sub 'parrot;Str;onload' pc 965 (src/gen_builtins.pir:619) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Hmm... I see in /usr/share/doc/parrot-0.6.4/languages/perl6/README: If you want to create a binary executable of the compiler that can be invoked as perl6 from the command line, then try make perl6. This will create a perl6 (or perl6.exe) binary that can be directly used from the command line: $ ./perl6 hello.pl This binary executable feature is still somewhat experimental, and may not work on all platforms. Also, the binary has hardcoded paths to the Parrot build tree (especially the dynamic libraries and modules), so removing the build tree will cause the binary to stop working. You are right. perl6 and all the similarlily generated parrot-languages binaries do not work. They have hardcoded paths to the builddir, which I thought I have fixed, but my fix only affected parrot itself not the dumped (with pbc_to_exe generated) languages executables. And my test did not include renaming the builddir. Best is to remove these two packages from the release dir until I fix it. I'm behind a strict firewall now, can someone do this for me? -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pbc install_config: howto install perl6 and languages?
Reini Urban schrieb: How is make install for the pbc_to_exe generated languages supposed to work? For the utils you simply link to a fixed install_config.o with fixed builddir. But the languages are generated from a .pir file with hardcoded, wrong builddir. I think about adding support for an optional --install arg in all pir's for the pbc_to_exe step sub 'compile_file', and use the install builddir then. Maybe also replace in 'link_file' parrot_config with install_config. Or is there a possibility to override the config hash in the pbc somehow? 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. Good? Bad? -- Forwarded message -- From: Reini Urban [EMAIL PROTECTED] Date: 2008/7/21 Subject: Re: [ANNOUNCEMENT] Updated: parrot-0.6.4-1 with parrot-perl6 and parrot-languages To: [EMAIL PROTECTED] 2008/7/21 Michael Schaap: On 20-Jul-2008 17:36, Michael Schaap wrote: On 19-Jul-2008 21:42, Reini Urban wrote: Michael Schaap schrieb: Is perl6 supposed to (somewhat) work, yet? I get: % perl6 -e 'say Hello, World!' load_bytecode couldn't find file 'P6object.pbc' current instr.: 'onload' pc 0 (src/gen_builtins.pir:28) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) P6object does exist, in /usr/lib/parrot/library. If I cd to this directory first, I get: % cd /usr/lib/parrot/library; perl6 -e 'say Hello, World!' Null PMC access in get_string() current instr.: 'parrot;P6metaclass;add_parent' pc 119 (runtime/parrot/library/P6object.pir:137) called from Sub 'parrot;P6metaclass;add_parent' pc 241 (runtime/parrot/library/P6object.pir:215) called from Sub 'parrot;P6metaclass;register' pc 411 (runtime/parrot/library/P6object.pir:295) called from Sub 'parrot;Str;onload' pc 965 (src/gen_builtins.pir:619) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Hmm... I see in /usr/share/doc/parrot-0.6.4/languages/perl6/README: If you want to create a binary executable of the compiler that can be invoked as perl6 from the command line, then try make perl6. This will create a perl6 (or perl6.exe) binary that can be directly used from the command line: $ ./perl6 hello.pl This binary executable feature is still somewhat experimental, and may not work on all platforms. Also, the binary has hardcoded paths to the Parrot build tree (especially the dynamic libraries and modules), so removing the build tree will cause the binary to stop working. You are right. perl6 and all the similarlily generated parrot-languages binaries do not work. They have hardcoded paths to the builddir, which I thought I have fixed, but my fix only affected parrot itself not the dumped (with pbc_to_exe generated) languages executables. And my test did not include renaming the builddir. Best is to remove these two packages from the release dir until I fix it. I'm behind a strict firewall now, can someone do this for me? -- Reini Urban http://phpwiki.org/ http://murbreak.at/ difforig languages/perl6/config/makefiles/root.in tools/dev/pbc_to_exe_gen.pl 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 +infile_len = length infile +infile_len -= 3 + +cfile = substr infile, 0, infile_len +cfile .= 'c' + +dec infile_len +objfile = substr infile, 0, infile_len +exefile = 'installable_' +exefile.= objfile +exefile.= exe +objfile.= obj +.return(infile, cfile, objfile, exefile) + proper_args: .local string infile, cfile, objfile, obj
Re: Loading libs under different names
Geoffrey Broadwell schrieb: I've noticed several patches from you today in which you're adding code to try to load an existing library under additional library names for cygwin support. It's beginning to look like this is a common operation. See =item loadlib DLL versioning in README_cygwin.pod I posted such a proposal some time ago to some ffi knowledgeable lists. (parrot, cffi, ...) Recently I had the idea that mingw/cygwin/MSVC can profit from resolving the needed dll names from the resp. import library. This name is always fixed without versioning and arch prefixes. I needed this for the OpenGL bindings, so I wrote a utility routine in runtime/parrot/library/OpenGL.pir called _load_lib_with_fallbacks() that encapsulates this sort of fallback behavior. It would be easy to split that routine out into a utility library, and use it everywhere, but I've got some concerns for which I'd like input from the Parrot Porters: 1. If this is indeed a really common operation, it might be worth moving it down the stack. Instead of using a PIR library, perhaps we should allow the loadlib opcode to take arguments other than a single simple string, and use the additional info to define fallbacks that are automatically tried. Arguments yes, but no list of fallback names please. As optional argument the version number is okay. 2. It's not clear to me that a simple list of names is appropriate everywhere. It works when all the variations are unique (and fully compatible), but it doesn't work so well when the name of library A on one platform is the same as library B on another platform. But perhaps this is a problem that doesn't exist in the wild, or is so rare it's simpler just to special case it. It exists in the ffi world since ages and has not been solved. 3. If we try to do something smarter for #2, I fear being sucked into a vortex of complexity, and I really don't want to go there. It's not too much of a complex technical problem. I report my proposal here because I cannot find it anymore. Thanks to the Windows DLL Hell Lhttp://en.wikipedia.org/wiki/DLL_hell and the impossibility of file hardlinks, windows dll names are hopefully versioned, so either the loadlib function or the various pir's needs more logic for maintainance convenience. Keep the lib_paths and share_ext search, add more name munging for special platforms. Either 1) add the version to each loadlib call, and stem the version from POSIX versions within get_path(). loadlib lib, 'libSDL-1.2.so.0' = try: libSDL-1.2.so.0, libSDL-1.2.so stemmed:libSDL.so on WIN32: SDL-1.2.dll, SDL.dll on cygwin: cygSDL-1.2.dll, cygSDL.dll Maybe also detect the -1.2.so.0 and convert it to -1.2.0.dll 2) add an optional version argument to loadlib. (preferred) loadlib lib, 'SDL', '1.2.0' = Try: first always prefix with lib libSDL-1.2.0.so, libSDL-1.2.so.0, libSDL-1.2.so, libSDL.so other rules stay as they are. (lib_paths + share_ext) on WIN32: no lib prefix and try versions. SDL-1-2-0.dll, SDL-1-2.dll, SDL-1.2.0.dll, SDL-1.2.dll, SDL.dll on cygwin: cyg prefix and try versions with '.' and '-'. cygSDL-1.2.dll, cygSDL-1.2.0.dll, cygSDL-1-2-0.dll, cygSDL-1-2.dll All the pir's for the latest packaged libraries are fixed with RT#51328. RT#51328 also applies the addional lib = cyg dll logic, but does not help with versioned dll's, as for ncurses and SDL most prominently. Examples what we want to avoid: loadlib $P1, 'libform' +if $P1 goto has_lib +loadlib $P1, 'cygform-8' +has_lib: loadlib $P1, 'libncurses' +if $P1 goto has_lib1 +loadlib $P1, 'cygncurses-8' +has_lib1: # third try loadlib libsdl, 'libSDL-1.2.so.0' +loadlib libsdl, 'cygSDL-1-2-0' +$I0 = typeof libsdl +if $I0 != .Undef goto OK loadlib image_lib, 'libSDL_image-1.2.so.0' $I0 = typeof image_lib if $I0 != .Undef goto OK_HINT2 +loadlib image_lib, 'cygSDL_image-1-2-0' +$I0 = typeof image_lib +if $I0 != .Undef goto OK + See also other ffi's, such as cffi, how they do deal or not with this problem. Years ago I wrote an overview at http://autocad.xarch.at/lisp/ffis.html
[CORE] gcc: objects after libs, linker switches after libs.
I see that on 0.6.4 within cygwin my linker does not work anymore. Latest svn smokes from before the release built fine. Checking the Makefiles I see that some objects had been added to the end of the linker lines which is invalid on newer gcc versions and windows. First the objects, then the linker switches, then the libs. If noone changed that in tghe recent past it could be that my switch to link against an windows importlibrary and not directly to the dll anymore caused that bug to emerge. I had to fix tools/dev/pbc_to_exe_gen.pl (config at last is wrong) and config/gen/makefiles/root.in In the exe targets in root.in the switches were even completely reversed. -$(ALL_PARROT_LIBS) $(LINKFLAGS) +$(LINKFLAGS) $(ALL_PARROT_LIBS) @@ -801,15 +801,15 @@ # TODO build the real miniparrot $(MINIPARROT) : $(SRC_DIR)/main$(O) $(GEN_HEADERS) $(LIBPARROT) \ lib/Parrot/OpLib/core.pm $(SRC_DIR)/null_config$(O) - $(LINK) @[EMAIL PROTECTED]@ $(SRC_DIR)/main$(O) \ -@rpath_blib@ $(ALL_PARROT_LIBS) $(LINKFLAGS) $(SRC_DIR)/null_config$(O) + $(LINK) @[EMAIL PROTECTED]@ $(SRC_DIR)/main$(O) $(SRC_DIR)/null_config$(O) \ +@rpath_blib@ $(LINKFLAGS) $(ALL_PARROT_LIBS) Note the null_config at the end. Similar through the whole files. Should I open a ticket and submit my patch or am I wrong? -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #51944] [DOCS] Cygwin Readme
2008/7/16 Will Coleda [EMAIL PROTECTED]: On Wed, Jul 16, 2008 at 2:31 AM, Reini Urban via RT [EMAIL PROTECTED] wrote: 2008/7/15 Reini Urban [EMAIL PROTECTED]: Will Coleda via RT schrieb: On Tue May 13 05:21:32 2008, rurban wrote: 2008/5/13 Andrew Whitworth via RT bugs-parrot- [EMAIL PROTECTED]: is this ticket (#51944) resolved? I don't see any outstanding todo items here that need to be considered further, and the submitted patch has already been applied. Can we close this, or is this a placeholder for us to further improve cygwin documentation? The list os build preq's is required. Well, the tip for smoke to do cpan Test::TAP::HTMLMatrix could be added. But this should be added in the general README for all platforms. Then platform specific is only that pg.t fails due to missing loadlib exceptions and that cygwin perl-5.10.0 fails to send the smoke report. perl-5.8.8 works ok. I'll send that as extra README_cygwin.pod patch. ENOPATCH. =-) Can someone with cygwin access go through the README once more so we can get this ticket closed? Thanks. Ok, since there's now almost an official parrot package, the updates are easy. Patch attached. The parrot-0.6.4-1 packages are in the works. I found a better link for the SDL link. Yesterday the http://cygwinports.dotsrc.org/ site was down, but now it is up again. Please use the attached revised patch instead. This looks good; I'd ask you double check which deps are required vs. optional: I'm pretty sure we don't -require- any of those packages. Ditto for their correspond build deps. (e.g. libgdbm-devel) Note, there are more cygwin-side updates to come to this README, which I will commit after my parrot-0.6.4 release (in 1-2 days). In which pod should we document the non-windows package requirements? Most of those packages have similar names anyway for every unix/posix platform. parrot is recursively listed as a build requirement oops. For the optional items, perl's Moose should be on the list (for smartlink), and Test::Perl::Critic/Perl::Critic for the critic tests. (Honestly we should have this documented somewhere else and just refer to it from here.) Good. Where? Here are some notes about the build/tests.. ** I get this warning on configure: Determining CPU architecture and OS...done. Determining JIT capability... 10 [main] test 1944 _cygtls::handle_exceptions : Error while dumping state (probably corrupted stack) 10 [main] test 4596 _cygtls::handle_exceptions: Error while dumping state ( probably corrupted stack) ..yes. There's a cygwin jit patch outstanding. [perl #56824] [PATCH] Configure - fix SEGV in JIT has_exec_protect test on Cygwin Generating CPU specific stuff.done. Verifying that the compiler supports function pointer castsyes. ** Get a similar error running t/src/extend.t ** Bug in t/doc/pod.t - few warnings of the type: Error: /cygdrive/d/sandbox/parrot/pbc_to_exe is unreadable: No such file or dire ctory Yes, this needs to be fixed, but it's not so urgent. Just the test is wrong. ... But all tests pass. More urgent for me is fixing the .include search path. [perl #56996] [TODO] remove non FHS-compliant searchpaths -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: [perl #57006] [PATCH] add cygwin opengl config quirks
Donald Hunter via RT schrieb:
Sorry rurban, this patch will break on my cygwin installation. I think
the problem is caused by more than an assumption that mingw eq cygwin.
The real problem is that Cygwin hosts three flavours of library for
OpenGL: mingw, cygwin/w32api, cygwin/X11.
All your patch does is switch from Cygwin/w32api to Cygwin/X11.
Please see rt#56628 for more details.
Ah thanks. I missed your recent common on this.
http://rt.perl.org/rt3/Public/Bug/Display.html?id=56628
The problem I had with the w32api libs was -lglut32. with linking
directly to the dll /usr/bin/glut32.dll everything works fine, and I'll
get rid of freeglut as default.
Now I only have to find out whatÄs wrong with that importlib, then I
send the revised patch. for now it is:
--- origsrc/parrot-0.6.4/config/auto/opengl.pm 2008-06-02
17:35:05.0 +
+++ src/parrot-0.6.4/config/auto/opengl.pm 2008-07-17 19:14:11.0
+
@@ -89,7 +89,6 @@
On Windows, Parrot supports three different compiler environments, each of
which has different requirements for OpenGL support:
-
=head3 MSVC
=over 4
@@ -104,16 +103,21 @@
=back
-
=head3 MinGW
: No details yet
+=head3 Cygwin/w32api
-=head3 cygwin
+The Cygwin/w32api for native opengl support
- : No details yet
+F-lglut32 -lglu32 -lopengl32
+
+=head3 Cygwin/X
+
+Requires a X server.
+Ffreeglut, Flibglut-devel
=cut
@@ -159,15 +163,23 @@
my $osname = $conf-data-get_p5('OSNAME');
-$self-_add_to_libs( {
-conf= $conf,
-osname = $osname,
-cc = $cc,
-win32_gcc = '-lglut32 -lglu32 -lopengl32',
-win32_nongcc= 'opengl32.lib glu32.lib glut32.lib',
-darwin = '-framework OpenGL -framework GLUT',
-default = '-lglut -lGLU -lGL',
-} );
+# Prefer Cygwin/w32api over Cygwin/X, but use X when DISPLAY is set
+if ($^O eq 'cygwin' and $ENV{DISPLAY}) {
+ $self-_add_to_libs( {
+ conf= $conf,
+ osname = $osname,
+ cc = $cc,
+ cygwin = '-lglut -L/usr/X11R6/lib -lGLU -lGL'
+} ) } else {
+ $self-_add_to_libs( {
+ conf= $conf,
+osname = $osname,
+cc = $cc,
+win32_gcc = '-lglut32 -lglu32 -lopengl32',
+win32_nongcc= 'opengl32.lib glu32.lib glut32.lib',
+darwin = '-framework OpenGL -framework GLUT',
+default = '-lglut -lGLU -lGL',
+} ) };
# On OS X check the presence of the OpenGL headers in the standard
# Fink/macports locations.
