Based on my reading of the documentation for get_namespace, this behavior
isn't surprising, but based on what I want to do with the code, this behavior
is very surprising:
works.pir:
.sub 'main' :main
.include 'runtime/parrot/include/test_more.pir'
.end
breaks.p
chromatic wrote:
Based on my reading of the documentation for get_namespace, this behavior
isn't surprising, but based on what I want to do with the code, this behavior
is very surprising:
works.pir:
.sub 'main' :main
.include 'runtime/parrot/include/test_more.pir'
I have just noticed that the trace I posted earlier is one the two
different crash logs that I have seen come out of this. Once in a rare
while, this test doesn't crash, but instead prints two error messages;
the earlier trace is from the one message variant. This next trace is
the no message, tw
# New Ticket Created by "Senaka Fernando"
# Please include the string: [perl #52510]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52510 >
Index: src/global.c
===
Additional testing note. If you try out this patch, you will need to
remove src/ops/*.c before doing a "make". Otherwise ops2c won't be
re-run, and you won't actually be testing the patch.
Extra points for anyone who tests it on something other than gcc. :)
Mark
# New Ticket Created by Mark Glines
# Please include the string: [perl #52506]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52506 >
Sekana Fernando reported that src/ops/core_ops.c didn't compile under
g++. It reports an
On Fri Mar 21 09:03:08 2008, [EMAIL PROTECTED] wrote:
> there is a definition on my system for PARROT_HAS_SNPRINTF, but not a
> definition for PARROT_HAS_C99_SNPRINTF. I assume, on first glance that
> these two macros are one in the same and should be united.
They are not. Please see the code in
Following discussion on #parrot with Infinoid, I created the 'ops2c'
branch in our SVN repository to handle refactoring of this area of the
build system. You can follow developments there with:
svn co https://svn.perl.org/parrot/branches/ops2c
In that branch, I have applied Infinoid's patch
# New Ticket Created by James Keenan
# Please include the string: [perl #52528]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52528 >
Since the Parrot buildfest we held at the March 27 Toronto Perlmongers
meeting, Seneca C
Following discussion on #parrot with Infinoid, I created the 'ops2c'
branch in our SVN repository to handle refactoring of this area of the
build system. You can follow developments there with:
svn co https://svn.perl.org/parrot/branches/ops2c
In that branch, I have applied Infinoid's patch
On Thu, Jan 31, 2008 at 03:05:17AM -0800, Klaas-Jan Stol wrote:
> # New Ticket Created by Klaas-Jan Stol
> # Please include the string: [perl #50424]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=50424 >
>
> as far as I
Larry Wall larry-at-wall.org |Perl 6| wrote:
I only mean that you can't simply rewrite
$foo.($bar)
as
$foo.postcircumfix:<( )>.($bar)
and think you've gotten anywhere, since you'd then have to rewrite it
again:
$foo.postcircumfix:<( )>.postcircumfix:<( )>.($bar)
$foo.postcirc
On Apr 6, 2008, at 12:07 , John M. Dlugosz wrote:
Larry Wall larry-at-wall.org |Perl 6| wrote:
and think you've gotten anywhere, since you'd then have to rewrite it
again:
$foo.postcircumfix:<( )>.postcircumfix:<( )>.($bar)
$foo.postcircumfix:<( )>.postcircumfix:<( )>.postcircumfix:<(
Hi all,
I have almost finished comparing the two interfaces of Harmony and Parrot.
However, I'm not 100% sure on whether I got everything right, but I believe
that most of it is. Therefore, it would be really great if you could review
the wiki page and let me know whether it is correct and precise
On Sunday 06 April 2008 09:33:06 chromatic wrote:
> On Sunday 06 April 2008 02:17:07 Jonathan Worthington wrote:
> > The behavior looks sane to me. .include is, quite literally, textual
> > inclusion, nothing more. The get_namespace instruction is always
> > relative. The code should probably be
Hi all,
I have almost finished comparing the two interfaces of Harmony and Parrot.
However, I'm not 100% sure on whether I got everything right, but I believe
that most of it is. Therefore, it would be really great if you could review
the wiki page and let me know whether it is correct and precise
On Saturday 05 April 2008 20:29:45 Mark Glines wrote:
> Sekana Fernando reported that src/ops/core_ops.c didn't compile under
> g++. It reports an error about "static op_lib_t core_op_lib" being
> declared twice, and rightly so, because it is. There's an initial stub
> declaration, and another d
On Sunday 06 April 2008 02:17:07 Jonathan Worthington wrote:
> The behavior looks sane to me. .include is, quite literally, textual
> inclusion, nothing more. The get_namespace instruction is always
> relative. The code should probably be using an absolute namespace op,
> such as get_hll_namespace
From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 6 Apr 2008 09:52:34 -0700
... compounded by the fact that I can't seem to get any of the existing
namespace ops to do what I want in a concise, non-hacky way. What am I
missing?
I notice that changing "get_root_namespace" to "get_hl
From: Bob Rogers <[EMAIL PROTECTED]>
Date: Sun, 6 Apr 2008 13:25:33 -0400
From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 6 Apr 2008 09:52:34 -0700
... compounded by the fact that I can't seem to get any of the existing
namespace ops to do what I want in a concise, n
On Sun, Apr 6, 2008 at 10:30 AM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
>From: Bob Rogers <[EMAIL PROTECTED]>
>Date: Sun, 6 Apr 2008 13:25:33 -0400
>
>
>
> From: chromatic <[EMAIL PROTECTED]>
> Date: Sun, 6 Apr 2008 09:52:34 -0700
>
> ... compounded by the fact that I can't
From: "James Keenan via RT" <[EMAIL PROTECTED]>
Date: Sun, 16 Mar 2008 10:46:15 -0700
On Sun Mar 16 10:02:32 2008, rgrjr wrote:
> I think it ought to happen, though I think Allison just wanted a ticket
> for updating existing PDDs, and not for a whole new PDD. I asked
> Allison
On 01/04/2008, Mark Glines via RT <[EMAIL PROTECTED]> wrote:
> On Sat Mar 29 15:54:09 2008, [EMAIL PROTECTED] wrote:
> > I ran a fulltest with this patch applied, and everything's fine on x86
> > (where it matters).
>
> Hi,
>
> The root.in portion of this patch breaks non-i386, JIT capable
> platfo
Hallo Bernhard,
On 06/04/2008, Bernhard Schmalhofer via RT
<[EMAIL PROTECTED]> wrote:
> On Di. 10. Jul. 2007, 07:15:27, ptc wrote:
> > In the file lib/Parrot/Test.pm there is the todo item:
> >
> > # TODO: $language should be the name of the test Module
> > #
I notice that C is deprecated in favor of "methods on the
ParrotIO object" (per RT #48589), but I can't figure out what. Is this
because the new methods have not been implemented yet? TIA,
-- Bob Rogers
http://
Pleases direct follow-ups to just perl6-users.
ItÂ’s been about a month and a half since the first time that I
brought up the topic of fundraising. So I want to find out what
the prospects are of decisively resolving the earmarked funding
issue within The Perl Foundation any time soon.
On Fri Mar 07 23:08:14 2008, songmaster wrote:
> On Tue Feb 05 13:41:02 2008, [EMAIL PROTECTED] wrote:
> > The fix is straightforward, but this change should also be made in
> > STD.pm. This fixes RT #49910.
>
> This patch would make 3e-4 a valid integer literal, even though it's not
> an integer
On Sun Apr 06 07:39:09 2008, [EMAIL PROTECTED] wrote:
> Following discussion on #parrot with Infinoid, I created the 'ops2c'
> branch in our SVN repository to handle refactoring of this area of the
> build system. You can follow developments there with:
>
> svn co https://svn.perl.org/parrot/
On Windows, make, make perl6, and make test all function in ops2c branch
with no more than the customary grumbling.
--
Email and shopping with the feelgood factor!
55% of income to good causes. http://www.ippimail.com
Author: rgrjr
Date: Sun Apr 6 18:15:44 2008
New Revision: 26829
Modified:
trunk/docs/pdds/draft/pdd06_pasm.pod
trunk/docs/pdds/pdd03_calling_conventions.pod
Log:
* docs/pdds/draft/pdd06_pasm.pod:
+ Remove refs to old pad ops.
* docs/pdds/pdd03_calling_conventions.pod:
+ Remove unmatc
On Sun, 06 Apr 2008 17:50:27 -0700
"Andrew Whitworth via RT" <[EMAIL PROTECTED]> wrote:
> Just warnings about redefining the snprintf macro. It was defined in
> two different places, and it's definition was based on both of those
> two flags above. I was looking for a way to unify the definitions f
Conrad,
Regarding targeted, earmarked funding - I have investigated the legalities,
tax implications, etc. of what is involved. The result of my investigation
is that it is do-able within the construct of TPF.
The other question is one of creation of a technical platform for
implementing this.
As per discussion on #parrot, the remaining TODO questions posed no
obstacle to merging the branch back into trunk. So I did so in r26830.
On Sun, Apr 6, 2008 at 9:20 PM, Mark Glines via RT
<[EMAIL PROTECTED]> wrote:
> Ok, thanks for the clarification. How do you think we should fix it?
The patch I submitted for this ticket earlier addresses the multiple
redefinitions issue without doing anything funny with the
PARROT_HAS_SNPRINTF
On Sun, Apr 6, 2008 at 4:13 PM, Bob Rogers
<[EMAIL PROTECTED]> wrote:
>I notice that C is deprecated in favor of "methods on the
> ParrotIO object" (per RT #48589), but I can't figure out what. Is this
> because the new methods have not been implemented yet? TIA,
>
precisely. allison and i
Richard,
That's great news!
(The time to get an answer wasn't an issue per se, but whether and when any
answer at all might be forthcoming, especially given the previously
expressed concerns and doubts of others that a positive answer would likely
result. Under such conditions, it would be
36 matches
Mail list logo
