lang/pir tests fail
hi,
I noticed that some tests in languages/PIR are failing. I did not touch
the project for some time, and last time I worked on it, everything was
just fine.
Below some of the output I get. My guess it has something to do with the
test framework (wasn't that being refactored?)
Also, tests in languages/Pynie are also failing for me, and again I
didn't touch those files.
Maybe I'm overlooking something, but I can't find the problem.
===[SNIP]===
t\assigndubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 3-4
Failed 2/7 tests, 71.43% okay
t\branchok
t\call..
t\call..NOK 1# Failed test (t\call.t at line 9)
# got: 'Can't spawn .\parrot.exe languages/PIR/pir.pbc
C:\parrot\languages\PIR\t\call_1.pir: Bad file descriptor at
../../lib/Parrot/Test.
pm line 274.
# '
# expected: 'parse = PMC 'PIR::Grammar' { ... }
# Parse successful!
# '
# '.\parrot.exe languages/PIR/pir.pbc
C:\parrot\languages\PIR\t\call_1.pir' failed with exit code 255
t\call..ok 3/10
t\call..NOK 4# Failed test (t\call.t at line 75)
# got: 'Can't spawn .\parrot.exe languages/PIR/pir.pbc
C:\parrot\languages\PIR\t\call_4.pir: Bad file descriptor at
../../lib/Parrot/Test.
pm line 274.
# '
===[SNIP]===
Regards,
kjs
Re: [perl #41955] [PATCH] Yet Another PIR -- in C
Hi,
Joshua Isom wrote:
Two quick questions, what hackish things in pir are you refering to,
and how much more do you think it would take to get bytecode working?
First of all, my words might have been to harsh. It is certainly not my
goal to step any toes and criticize IMCC. So my apologies if I sound too
critical. However, the sourcefiles of IMCC contain several TODOs, FIXMEs
and Notes indicating that things should be changed in the future.
Working bytecode: I don't know exactly. I guess it shouldn't be too hard
to put in the actions from the yacc file into a new parser, but it's not
trivial I think.
Also, consider that file size alone is not the best indicator of how
well something is programmed, as sometimes a bigger object file is
faster than a smaller one(the difference between macros and functions
is an example).
That's true. (I was thinking a bit of cache memory, but I'm no expert on
that kind of things)
An example of some code not accepted by IMCC, but something that would
be very useful is this:
foo('CODE', 'OUTPUT')
...
CODE
...
OUTPUT
because IMCC can only parse 1 heredoc per statement. Of course, the docs
indicate this, so it is according to spec., but that does not mean
according to the user's wishes.
Again, it's not my goal to criticize imcc, but it does have its bugs and
it might be nice to have a look at some alternatives.
PIR does have an unimplemented #line operator as does c and perl.
I think this was implemented some time ago.
thanks for your feedback.
regards,
klaas-jan
If you include support for it as well, you could consider doing macros
and includes with a preprocessor instead of in the parser itself. It
might make support for certain things easier. But a caveat of that is
handling something like '.Foo())' which requires an understanding of
PIR.
On Mar 21, 2007, at 4:53 PM, Klaas-Jan Stol (via RT) wrote:
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #41955]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41955
hi,
as requested by particle to send this to the list, attached a patch of
an implementation of PIR in C. Instead of using a bottom-up parser
(using Yacc), this is a pure-C top-down approach.
It is explicitly not my goal to do superfluous work, or to distract you
from working on More Important Things, but I send this, as mentioned on
request.
Of course, it's not finished yet, but a lot is working already (please
note it's only parsing).
THe current implementation of PIR, IMCC, is a bit hacky and not very
clean. Moreover, it's not reentrant. This patch tries to resolve this,
and tries to define what PIR should look like (no hacky things allowed
anymore).
Also, I wrote it to see how far I would come, and whether a top-down
approach was feasible. Also, considering that IMCC's parser's object
file is about 180 KB, and this one only about 35 KB (not the executable,
which includes the C lib.) is a good sign. (I know, IMCC does a lot
more...)
Anyway, comments are most certainly welcome.
regards,
klaas-jan
[perl #41956] [TODO] Rename PMETHOD and PMINVOKE
# New Ticket Created by Jonathan Worthington # Please include the string: [perl #41956] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41956 In a discussion with Allison, it was agreed that PMETHOD and PMINVOKE should be renamed to make it clearer that they are to do with the Parrot Calling Conventions. What is now PMETHOD will be known as PCCMETHOD What is now PMINVOKE will be known as PCCINVOKE
Re: [perl #41955] [PATCH] Yet Another PIR -- in C
Two quick questions, what hackish things in pir are you refering to, and how much more do you think it would take to get bytecode working? Also, consider that file size alone is not the best indicator of how well something is programmed, as sometimes a bigger object file is faster than a smaller one(the difference between macros and functions is an example). PIR does have an unimplemented #line operator as does c and perl. If you include support for it as well, you could consider doing macros and includes with a preprocessor instead of in the parser itself. It might make support for certain things easier. But a caveat of that is handling something like '.Foo())' which requires an understanding of PIR. On Mar 21, 2007, at 4:53 PM, Klaas-Jan Stol (via RT) wrote: # New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #41955] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41955 hi, as requested by particle to send this to the list, attached a patch of an implementation of PIR in C. Instead of using a bottom-up parser (using Yacc), this is a pure-C top-down approach. It is explicitly not my goal to do superfluous work, or to distract you from working on More Important Things, but I send this, as mentioned on request. Of course, it's not finished yet, but a lot is working already (please note it's only parsing). THe current implementation of PIR, IMCC, is a bit hacky and not very clean. Moreover, it's not reentrant. This patch tries to resolve this, and tries to define what PIR should look like (no hacky things allowed anymore). Also, I wrote it to see how far I would come, and whether a top-down approach was feasible. Also, considering that IMCC's parser's object file is about 180 KB, and this one only about 35 KB (not the executable, which includes the C lib.) is a good sign. (I know, IMCC does a lot more...) Anyway, comments are most certainly welcome. regards, klaas-jan
[PATCH] void functions can't return values.
Void functions can't try to return anything. I haven't checked if this
patch is right or not. The documentation for Parrot_set_attrib_by_num()
claims it returns a PMC *, but the source code uses 'void' and doesn't
actually return anything. I don't know what the intended behavior
actually is.
This patch at least lets it compile.
--- parrot-current/src/pmc/parrotobject.pmc 2007-03-16 11:15:15.0
-0400
+++ parrot-andy/src/pmc/parrotobject.pmc2007-03-21 11:50:28.569996000
-0400
@@ -207,8 +207,10 @@
PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
if (PMC_IS_NULL(sub))
sub = find_meth(interp, SELF, meth);
-if (PMC_IS_NULL(sub))
-return Parrot_set_attrib_by_num(INTERP, SELF, idx, value);
+if (PMC_IS_NULL(sub)) {
+Parrot_set_attrib_by_num(INTERP, SELF, idx, value);
+return ;
+}
(PMC*) Parrot_run_meth_fromc_args(interp, sub,
SELF, meth, vIP, idx, value);
}
@@ -219,8 +221,10 @@
PMC *sub = Parrot_find_vtable_meth(interp, SELF, meth_v);
if (PMC_IS_NULL(sub))
sub = find_meth(interp, SELF, meth);
-if (PMC_IS_NULL(sub))
-return Parrot_set_attrib_by_str(INTERP, SELF, idx, value);
+if (PMC_IS_NULL(sub)) {
+Parrot_set_attrib_by_str(INTERP, SELF, idx, value);
+return;
+}
(PMC*) Parrot_run_meth_fromc_args(interp, sub,
SELF, meth, vSP, idx, value);
}
--
Andy Dougherty [EMAIL PROTECTED]
[PATCH] Avoid //-style comments.
Please avoid //-style comments. Older compilers don't understand
them.
Also, and more importantly, this section of code has several commented out
lines, but no comments explaining why those lines are commented out. It
makes it more difficult to understand.
--- parrot-current/lib/Parrot/Pmc2c/PMETHODs.pm 2007-03-17 19:15:14.0
-0400
+++ parrot-andy/lib/Parrot/Pmc2c/PMETHODs.pm2007-03-21 11:56:34.73000
-0400
@@ -439,7 +439,7 @@
/* if (PMC_cont(ccont)-address) { */
{
-//parrot_context_t * const caller_ctx = PMC_cont(ccont)-to_ctx;
+/* parrot_context_t * const caller_ctx = PMC_cont(ccont)-to_ctx; */
if (! caller_ctx) {
/* there is no point calling real_exception here, because
PDB_backtrace can't deal with a missing to_ctx either. */
--
Andy Dougherty [EMAIL PROTECTED]
[PATCH] Hints must come early in Configure.pl
Hints need to come *before* inter/progs. The hints set up various platform-specific callbacks to be performed after the different programs are selected. Actually, I suspect they should even come before the init::install unit. Certainly in perl5's hints, there are a number that modify the default installation directories. However, I don't understand parrot's installation plan, so I have left this alone. --- parrot-current/Configure.pl Sat Mar 17 18:15:17 2007 +++ parrot-andy/Configure.plWed Mar 21 11:05:41 2007 @@ -463,9 +463,9 @@ init::defaults init::install init::miniparrot -inter::progs init::hints init::headers +inter::progs inter::make inter::lex inter::yacc -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] Suppress optimization on core_ops_cgp.c
core_ops_cgp.c usually overwhelms my system. It's a combination of the
compiler and the system. It apparently doesn't cause problems elsewhere.
Alas, there appears no more narrowly-focused approach other than to turn
off optimization for everyone, so that's what this patch does. Better
would be a way for specific end-users to specify this -- either via
command line options or hints file overrides, or something.
--- parrot-current/config/gen/makefiles/CFLAGS.in 2006-08-20
19:15:20.0 -0400
+++ parrot-gcc/config/gen/makefiles/CFLAGS.in 2007-03-21 12:20:04.829996000
-0400
@@ -9,6 +9,7 @@
src/spf_render.c-{-Wformat-nonliteral} # noisy
src/tsq.c [EMAIL PROTECTED]@} # never optimize tsq.c!
src/ops/core_ops_cg.c [EMAIL PROTECTED]@}# takes too long
+src/ops/core_ops_cgp.c [EMAIL PROTECTED]@}# takes too long
src/ops/core_ops_switch.c [EMAIL PROTECTED]@}# Overwhelms some compilers.
src/py_func.c +{-Ipmc} # include pmc_default.h
--
Andy Dougherty [EMAIL PROTECTED]
Re: Perl 6 Microgrants. Now accepting proposals.
On Wed, Mar 21, 2007 at 11:04:29PM -0400, Jesse Vincent wrote: I'm pleased to announce the inaugural Perl 6 Microgrants program. Best Practical Solutions (my company) has donated USD5,000 to The Perl Foundation to help support Perl 6 Development. Leon Brocard, representing The Perl Foundation's grants committee, will work with me to select proposals and evaluate project success. We'll be making USD500 grants to worthy Perl 6 related efforts. We're hoping to fund a range of Perl 6-related projects over the life of the grant program. Accepted grants might be for coding, documentation, testing or even writing articles about Perl 6. The program isn't tied to any one implementation of Perl 6 -- We're interested in seeing proposals related to Pugs, Perl 6 on Parrot, Perl 6 on Perl 5 or any other Perl 6 implementation. Generally, we're interested in seeing projects that can be completed in 4-6 calendar weeks. Submitting a grant proposal --- To submit a grant proposal, please email us at perl6- [EMAIL PROTECTED] with the following information: * A two to three paragraph summary of the work you intend to do * A quick bio - Who are you? Is there opensource work you've done that we should have a look at? * A brief description of what success will mean for your project - How will we know you're done? * Where (if anywhere) you've discussed your project in the past * Where you'll be blogging about your progress. (Twice-weekly blog posts are a requirement for getting your grant money) We'll be accepting proposals on a rolling schedule. We expect to pay out these first 10 grants over the course of the summer. Depending on how things go, we'll then either find more money for more grant programs or we'll wind up the program and move on to other endeavors. We're really excited to get rolling. Submit your proposals early and often. Don't let somebody else beat you to the punch ;) I'd like to suggest an idea for *someone else* to submit a proposal for: As part of the work on DBI2 I want to create a Perl API that closely matches the JDBC API. I need a tool that can parse the java .h files that that define the JDBC API, e.g., http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/Statement.h?revision=120621view=markup and generate roughly equivalent Perl 6 (roles etc). Some knowledge of Java would be helpful to get a reasonable initial mapping of concepts from Java to Perl, but that's bound to evolve over time - hence the need for a tool to do, and redo, the translation. [ I'd probably then use the tool to also generate implementation code that bridges the Perl6 JDBC with the Perl5 JDBC module on CPAN. That would give Perl6 a working JDBC API. (The next step might be to parse the Java code of the JDBC test suite and translate that to Perl6...) ] There are two parts to this: a Java parser (good enough for at least the JDBC .h files), and a Perl6 code (role) generator. They could be combined, but I'd like the Java parser to be reusable by others. Here's a related idea: write a tool that reads BNF grammar, such as http://java.sun.com/docs/books/jls/third_edition/html/syntax.html http://java.sun.com/docs/books/jls/third_edition/html/grammars.html and writes a parser in Perl 6 for that grammar. Anyone interested in those ideas? Tim. p.s. The .h files for JDBC can be found here http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/ http://gcc.gnu.org/viewcvs/trunk/libjava/javax/sql/ p.p.s. The funding for these could come from the DBI Development fund (which hasn't been used for anything yet) and so not impact the donation from Best Practical Solutions.
make test hangs in t/examples/shootout_1.pir
After applying the various build patches I posted earlier today, I tried running make test. Unforutnately, it appears to hang in t/examples/shootout_1.pir. It ran for about 15 hours before I finally killed it. Curiously, it hadn't racked up much CPU time at all -- ps showed '0:00'. A perl version of the same ackerman(3,9) benchmark runs to copmletion just fine, in a little under 4 mintues. This problem may have been around for quite a while. I vaguely recall having to kill this process back in January, but I was on the trail of bigger problems at the time, and just chalked it up to impatience -- not wanting to wait for the program to end. I'll look into this some more in the next week or so as time permits. -- Andy Dougherty [EMAIL PROTECTED]
[perl #41763] [PATCH]: fix clone method for iterators
On Fri Mar 09 09:27:22 2007, [EMAIL PROTECTED] wrote: I noticed that if you cloned an iterator that you had already shifted, the clone started at the beginning, rather than at the original's current location. Applied in r17691 with one change: C89 specifies that all variable declarations have to be at the beginning of a block, so I had to move one of the lines so that this was the case. Please watch for this in the future. Thanks! -- Matt Diephouse
Re: [svn:parrot] r17688 - in trunk/config/gen: . makefiles
On Thursday 22 March 2007 01:48, [EMAIL PROTECTED] wrote:
+#INVERSE_CONDITIONED_LINE(win32):$config{ALL_PARROT_LIBS} =
@libparrot_ldflags@ $config{C_LIBS}; $config{ABS_PARROTDIR} =
Cwd::realpath(
File::Spec-rel2abs( $config{PARROTDIR} )
); $config{LDDLFLAGS} = $Config{lddlflags};
@@ -31,9 +30,11 @@
'NAME' = 'Parrot::Embed',
'VERSION_FROM' = 'lib/Parrot/Embed.pm',
'PREREQ_PM' = { 'ExtUtils::CBuilder' = 0 },
- 'LIBS' = [ $config{ALL_PARROT_LIBS} ],
+#CONDITIONED_LINE(win32): 'LIBS' = [ $config{C_LIBS} ],
+#CONDITIONED_LINE(win32): 'OBJECT' = @libparrot_ldflags@
[EMAIL PROTECTED]@, +#INVERSE_CONDITIONED_LINE(win32): 'LIBS' = [
$config{ALL_PARROT_LIBS} ],
These lines are comments in the generated Makefile.PL, so they won't do
anything.
-- c
Re: [PATCH] Avoid //-style comments.
Andy Dougherty [EMAIL PROTECTED] wrote: Please avoid //-style comments. Older compilers don't understand them. Thanks. We have a test for //-style comments, but evidently it doesn't catch all of our generated code. I've changed it to a C-style comment in r17692. -- Matt Diephouse http://matt.diephouse.com
Re: [PATCH] Avoid //-style comments.
On Thu, 22 Mar 2007 08:59:05 -0400 (EDT), Andy Dougherty
[EMAIL PROTECTED] wrote:
Please avoid //-style comments. Older compilers don't understand
them.
Not only 'older' compilers, also 'stricter' compilers.
One of my pet-peeves. Sorry. // comments are bad style.
my $a = 1 // This is comment :);
Also, and more importantly, this section of code has several commented out
lines, but no comments explaining why those lines are commented out. It
makes it more difficult to understand.
--- parrot-current/lib/Parrot/Pmc2c/PMETHODs.pm 2007-03-17
19:15:14.0 -0400
+++ parrot-andy/lib/Parrot/Pmc2c/PMETHODs.pm 2007-03-21 11:56:34.73000
-0400
@@ -439,7 +439,7 @@
/* if (PMC_cont(ccont)-address) { */
{
-//parrot_context_t * const caller_ctx = PMC_cont(ccont)-to_ctx;
+/* parrot_context_t * const caller_ctx = PMC_cont(ccont)-to_ctx; */
if (! caller_ctx) {
/* there is no point calling real_exception here, because
PDB_backtrace can't deal with a missing to_ctx either. */
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
11.23, SuSE 10.0 10.2, AIX 4.3 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
[perl #41975] Makefile is missing dependencies on lib/Parrot/Pmc2c/PMETHODs.pm
# New Ticket Created by Andy Dougherty # Please include the string: [perl #41975] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41975 I had to fix lib/Parrot/Pmc2c/PMETHODS.pm in order to get parrot to compile. However, after fixing it, typing 'make' doesn't regenerate the necessary files. There are missing dependencies. The workaround is to do some sort of 'make clean' and do a lot of unnecessary rebuilds. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #41955] [PATCH] Yet Another PIR -- in C
Klaas-Jan Stol (via RT) wrote: as requested by particle to send this to the list, attached a patch of an implementation of PIR in C. Instead of using a bottom-up parser (using Yacc), this is a pure-C top-down approach. This is quite cool! Keep us updated as you continue working on it. I'm happy to host it in compilers/pirc/ as an experiment-in-progress. If you check it in, take advantage of Parrot's Makefile substitutions so people don't have to manually modify the Makefile for Linux. And standardize on Parrot conventions like a t/ directory instead of test/. Thanks! Allison
Re: Re: Perl 6 Microgrants. Now accepting proposals.
I am very interested in this. I've done a little bit of work like this in the past, for projects like Java::Swing which is a thin Inline::Java facade for coding swing UI front ends in what appears to be pure Perl. But, your plan is more intense. In particular it is more intense than $500. So, are there others that would work with me? Phil Tim Bunce [EMAIL PROTECTED] wrote: On Wed, Mar 21, 2007 at 11:04:29PM -0400, Jesse Vincent wrote: I'm pleased to announce the inaugural Perl 6 Microgrants program. Best Practical Solutions (my company) has donated USD5,000 to The Perl Foundation to help support Perl 6 Development. Leon Brocard, representing The Perl Foundation's grants committee, will work with me to select proposals and evaluate project success. We'll be making USD500 grants to worthy Perl 6 related efforts. We're hoping to fund a range of Perl 6-related projects over the life of the grant program. Accepted grants might be for coding, documentation, testing or even writing articles about Perl 6. The program isn't tied to any one implementation of Perl 6 -- We're interested in seeing proposals related to Pugs, Perl 6 on Parrot, Perl 6 on Perl 5 or any other Perl 6 implementation. Generally, we're interested in seeing projects that can be completed in 4-6 calendar weeks. Submitting a grant proposal --- To submit a grant proposal, please email us at perl6- [EMAIL PROTECTED] with the following information: * A two to three paragraph summary of the work you intend to do * A quick bio - Who are you? Is there opensource work you've done that we should have a look at? * A brief description of what success will mean for your project - How will we know you're done? * Where (if anywhere) you've discussed your project in the past * Where you'll be blogging about your progress. (Twice-weekly blog posts are a requirement for getting your grant money) We'll be accepting proposals on a rolling schedule. We expect to pay out these first 10 grants over the course of the summer. Depending on how things go, we'll then either find more money for more grant programs or we'll wind up the program and move on to other endeavors. We're really excited to get rolling. Submit your proposals early and often. Don't let somebody else beat you to the punch ;) I'd like to suggest an idea for *someone else* to submit a proposal for: As part of the work on DBI2 I want to create a Perl API that closely matches the JDBC API. I need a tool that can parse the java .h files that that define the JDBC API, e.g., http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/Statement.h?revision=120621view=markup and generate roughly equivalent Perl 6 (roles etc). Some knowledge of Java would be helpful to get a reasonable initial mapping of concepts from Java to Perl, but that's bound to evolve over time - hence the need for a tool to do, and redo, the translation. [ I'd probably then use the tool to also generate implementation code that bridges the Perl6 JDBC with the Perl5 JDBC module on CPAN. That would give Perl6 a working JDBC API. (The next step might be to parse the Java code of the JDBC test suite and translate that to Perl6...) ] There are two parts to this: a Java parser (good enough for at least the JDBC .h files), and a Perl6 code (role) generator. They could be combined, but I'd like the Java parser to be reusable by others. Here's a related idea: write a tool that reads BNF grammar, such as http://java.sun.com/docs/books/jls/third_edition/html/syntax.html http://java.sun.com/docs/books/jls/third_edition/html/grammars.html and writes a parser in Perl 6 for that grammar. Anyone interested in those ideas? Tim. p.s. The .h files for JDBC can be found here http://gcc.gnu.org/viewcvs/trunk/libjava/java/sql/ http://gcc.gnu.org/viewcvs/trunk/libjava/javax/sql/ p.p.s. The funding for these could come from the DBI Development fund (which hasn't been used for anything yet) and so not impact the donation from Best Practical Solutions.
Re: rpm package
On Wed, Mar 21, 2007 at 06:39:51PM -0700, Allison Randal wrote: Agreed. And we don't work from the installation paths because the installation paths are broken. Can we break out of this cycle with some automated tests for the installed Parrot? That would be pretty slick. :-) Steve -- Steven Pritchard - KS Pritchard Enterprises, Inc. Email: [EMAIL PROTECTED] http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320
Re: rpm package
On Wed, Mar 21, 2007 at 03:13:55PM -0700, Allison Randal wrote:
Steven Pritchard wrote:
I spent some more time getting a package built for Fedora. It
probably goes without saying, but this is still a bit difficult. If
anyone is interested, here's my current package:
Thanks, Steve. Have you kept a list of the things that are difficult
about the process? Making it easy to package up Parrot for .rpm, .deb,
etc, is definitely one of our goals.
I didn't keep a list, but I do have the spec. Quickly glancing at it,
I see three things that I would classify as problems:
1) lib is hard-coded in a few places. (On x86_64 Fedora and other
RH derivatives, the system library path is /lib64 and /usr/lib64.)
I hack around that in %prep with this:
%{__perl} -pi -e 's,lib/,%{_lib}/, if (/CONST_STRING\(interp,/)' \
src/library.c
%{__perl} -pi -e s,'/usr/lib','%{_libdir}',;s,runtime/lib/,runtime/%{_lib}/, \
tools/dev/install_files.pl \
tools/dev/mk_manifests.pl
Ideally, the install scripts should allow for installing
non-architecture-specific bits in /usr/share and the
architecture-specific binary bits in /usr/lib64.
2) The last time I checked, to get everything to work right I had to
set LD_LIBRARY_PATH to $topdir/blib/lib.
3) The languages/ stuff isn't installed automatically. I'm not even
sure where it should go.
The rest is all minor cleanup and sub-optimal (for my purposes)
defaults. If you look through the spec, it should all be pretty
obvious...
Steve
--
Steven Pritchard - KS Pritchard Enterprises, Inc.
Email: [EMAIL PROTECTED] http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
Re: Perl 6 Microgrants. Now accepting proposals.
On Thu, Mar 22, 2007 at 01:24:58PM +, Tim Bunce wrote: Here's a related idea: write a tool that reads BNF grammar, such as http://java.sun.com/docs/books/jls/third_edition/html/syntax.html http://java.sun.com/docs/books/jls/third_edition/html/grammars.html and writes a parser in Perl 6 for that grammar. Writing a Perl 6 grammar to parse BNF should not be too hard. Writing an emitter to translate that into a Perl 6 grammar should also not be very hard, though I find emitters harder to write. I'm thinking of an architecture similar to Flavio Glock's MiniPerl6. http://svn.pugscode.org/pugs/v6/v6-MiniPerl6/lib/MiniPerl6/ Anyone interested in those ideas? Quite interested, though lacking tuits at the moment. -kolibrie signature.asc Description: Digital signature
Re: Perl 6 Microgrants. Now accepting proposals.
Hi all, I am recently working on the QT4/KDE4 bindings for p5. First cpp headers are parsed by a grammar based on Parse::RecDescent, The production of latest dev release Parse-QTEDI-0.02_01 is quite stable, presenting all related interface information of cpp .h. I will continue to make it available in p5. And myself do have a plan to introduce them in p6. It will be nice if someone can do so in parallel with me (I mean, for p6). Since: 1. my knowledge on p6 sucks ;-) 2. currently I haven't got enough time. PS: It is very glad to see such information, really. In my opinion p6 indeed needs trying to draw as many connections as possible with other outstanding tool/project outside perl world. KDE is such a place too. PS2: my project page: http://code.google.com/p/dongxu/wiki/QTEDI http://code.google.com/p/dongxu/wiki/PerlQT -- Forwarded message -- From: Jesse Vincent [EMAIL PROTECTED] Date: Mar 22, 2007 11:04 AM Subject: Perl 6 Microgrants. Now accepting proposals. To: perl6-internals@perl.org, perl6-language@perl.org, perl6-compiler@perl.org, perl5-porters@perl.org I'm pleased to announce the inaugural Perl 6 Microgrants program. Best Practical Solutions (my company) has donated USD5,000 to The Perl Foundation to help support Perl 6 Development. Leon Brocard, representing The Perl Foundation's grants committee, will work with me to select proposals and evaluate project success. We'll be making USD500 grants to worthy Perl 6 related efforts. We're hoping to fund a range of Perl 6-related projects over the life of the grant program. Accepted grants might be for coding, documentation, testing or even writing articles about Perl 6. The program isn't tied to any one implementation of Perl 6 -- We're interested in seeing proposals related to Pugs, Perl 6 on Parrot, Perl 6 on Perl 5 or any other Perl 6 implementation. Generally, we're interested in seeing projects that can be completed in 4-6 calendar weeks. Submitting a grant proposal --- To submit a grant proposal, please email us at perl6- [EMAIL PROTECTED] with the following information: * A two to three paragraph summary of the work you intend to do * A quick bio - Who are you? Is there opensource work you've done that we should have a look at? * A brief description of what success will mean for your project - How will we know you're done? * Where (if anywhere) you've discussed your project in the past * Where you'll be blogging about your progress. (Twice-weekly blog posts are a requirement for getting your grant money) We'll be accepting proposals on a rolling schedule. We expect to pay out these first 10 grants over the course of the summer. Depending on how things go, we'll then either find more money for more grant programs or we'll wind up the program and move on to other endeavors. We're really excited to get rolling. Submit your proposals early and often. Don't let somebody else beat you to the punch ;) Best, Jesse -- Cheers, Dongxu __END__ http://search.cpan.org/~dongxu PGP.sig Description: PGP signature
