Applied as r9954.
-J
--
I've imported File::Which 0.05 into the parrot tree as r9959 and I've
applied this patch as r9960. If or when there is a workable parrot
'maintainer' bundle on CPAN and an optional module detection mechanism
as part of the configure system r9959 can be backed out.
Cheers,
-J
--
Resolved by bug #37692. Something on the TODO list actually got done. ;)
-J
--
Committed as r10566 & r10567.
-J
--
Committed as r10571. I decided not to use Module::Pluggable at this
time as it tries to loading things like the 'hints' modules for all
platforms.
-J
--
CLI options are now accessed from a Parrot::Configure::Data object
contained by the Parrot::Configure object that is now passed to every
step as the first paramter. Implimented in a 'large number' of
changesets between r10566 and r10658.
-J
--
FYI - bugs #36835 & #38060 have been merged into #34549.
-J
--
I've commited a possible fix for openbsd, cygwin, & solaris as changesets
r10839 & r10843. I basically applied what Steve Peters proposed but
with the changes in math.c instead of creating init.c (as agreed to on
#parrot).
This doesn't appear to have done anything for gcc/solaris... can someone
Forgot to CC p6i...
> [jhoblitt - Sun Jan 08 14:21:47 2006]:
>
> Is this sufficent as a META.yml or do I also need to explicitly list all
> of the Parrot::* modules as 'provided'?
> ---
> name: parrot
> version: 0.4.1
> author: ~
> abstract: ~
> license: perl
> no_index:
> directory:
>
> [EMAIL PROTECTED] - Sun Jan 01 18:44:33 2006]:
>
> Parrot::Configure::Step::genfile() currently interpolates values in the
> format ${foo}. This is undesirable because ${ BAREWORD } is valid perl5
> syntax and in make files it looks uncomfortable similar to $(foo). It
> should be changed to @f
Please reopen this bug if we're still screwing up the CPAN indexer after
the next release. Thanks for bringing up this issue.
Cheers,
-J
--
The ${foo} interoplation/substitution syntax is no more. It has been
replaced with the autoconf like @foo@ syntax and all of the *.in files
have been updated. The special quoting syntax has also been removed
from parrot.pc.in
Support implimented in r11082 & r7.
Cheers,
-J
--
Per step parameter support implimented in r11203.
-J
--
Just a quick reminder devs as to that to do when you apply a patch.
You need to:
Take ownership of the bug
Set the patch status to Applied
***Set the Status to resolved***
If nothing else, please at least set the Status to resolved so someone
else doesn't have to clean up the bug trac
Please resolve patch bugs after applying the patch.
-J
--
This bug seems to have resolved itself.
-J
--
This bug seems to have resolved itself at least on amd64/linux. Please
re-open this bug if it's still failing for you. Thanks for reporting.
-J
--
Is this bug resolved? If not, what platforms is it still failing on?
-J
--
> [doughera - Mon Feb 13 09:10:50 2006]:
>
> On Fri, 10 Feb 2006, Allison Randal wrote:
>
> > On Feb 10, 2006, at 9:56, Andy Dougherty via RT wrote:
> > >
> > > I too had seen this memory problem before on Solaris/SPAR
As of r11568 all configuration step's ->runstep() method is required to
return $self unless it wants to indicate a fatal error. An error string
is expected to be returned via the ->result() method. The steps we're
previously changed to conform to this behavior but Parrot::Configure now
requires i
This flag is in use by the inter::exp step but it's not doing much.
Should this flag be kept or not?
-J
--
> [coke - Sun Aug 15 13:41:43 2004]:
>
> Add profiling build options
>
> (From the TODO file)
>
>
Is this really worth doing? Since profiling flags are compiler specific
isn't it better to just let them be set as additional CFLAGS?
-J
--
> [EMAIL PROTECTED] - Wed Dec 29 18:22:10 2004]:
>
>
> This code:
>
> new P0, .Undef
> new P1, .Undef
> eq P0, P1, L1
> print "not "
> L1: print "ok\n"
> end
>
> prints "not ok". Should it? If Parrot considers every Undef PMC to
> be distinct, it's going to ma
No one ever made any actualy attempt to impliment the build in scons,
makepp, etc. and since we're moving towards Configure in PASM/miniparrot
I'm going to close out this bug.
-J
--
What happened to the factorial PASM example? It seems to have
disappeared and it hasn't re-appeared as a PIR example either.
-J
--
Does anyone have an old enough Perl to test if this is still an issue?
-J
--
Has handling of SIGFPE been 'well' resolved or is this a TODO item?
-J
> [EMAIL PROTECTED] - Sun Aug 22 17:19:34 2004]:
>
> All~
>
> This patch is an early step in getting a scons based build system for
> parrot. Currently, it leaves the make system in place, the goal being
> to add a SCons system alongside the make system until the scons one is
> entirely ready.
>
[cut from a off list thread between jhoblitt & nickg]
>As a general comment, 36119 makes me a little nervous as 'chmod' isn't
>something you can count on unless your on a POSIX like system and osname
>ne 'MSWin32' certainly would encompass non-POSIX systems. Are you
>planning on retool this patch
> [EMAIL PROTECTED] - Sun Oct 09 23:46:41 2005]:
>
> Hi,
>
> Attached is a patch to change the spelling of librairies to libraries.
>
> Michael Cartmell
> Network & Operating Systems Analyst
> Lawpoint
> Thomson Legal & Regulatory Limited (ABN 64 058 914 668)
> Ph +61 2 9239 4958Fax +612
> [nickg - Mon Oct 10 12:11:00 2005]:
>
> Joshua Hoblitt via RT wrote:
>
> >>>As a general comment, 36119 makes me a little nervous as 'chmod' isn't
> >>>something you can count on unless your on a POSIX like system and
osname
> >>>
Applied as r9496. Thanks.
-J
(gdb) run config_lib.pasm
Starting program: /home/dull/jhoblitt/parrot/miniparrot config_lib.pasm
[Thread debugging using libthread_db enabled]
[New Thread 46912496258176 (LWP 18777)]
[New Thread 1082132832 (LWP 18780)]
[New Thread 1090525536 (LWP 18781)]
Program received signal SIGSEGV, Segmentat
Applied as r9533. Thanks.
-J
> [EMAIL PROTECTED] - Tue Nov 01 04:52:22 2005]:
>
> This patch fixes two classes of issue.
>
> * Don't assign -1 to an unsigned variable; use ~0U instead as it
> makes it clear that the value is intended to be out-of-band (g++
> warned about this, and C compilers will increasingly)
>
> * Ch
34 matches
Mail list logo
