Imagine my delight upon reading this in the Perl 6 Design Team minutes:
* also had a contact from someone who wants to port OpenGL to Parrot
* not Geoff Broadwell
* seems like a very serious approach
Ouch! You wound me, sir!
Just for the record, I've attached my OpenGL/GLUT proof of concept
I'm not sure I'm really qualified to answer this, since I'm not really a
Perlistanian, but in general, if something shipping with Parrot depends on
something else, it should be in the Parrot tree (in either source or binary
form, whichever is more convenient and/or makes the most sense). If ther
# New Ticket Created by "Seneca Cunningham"
# Please include the string: [perl #5]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=5 >
This failure is not visible in prove -v output.
herodotus:parrot seneca$ ./parro
# New Ticket Created by "Seneca Cunningham"
# Please include the string: [perl #52224]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52224 >
Parrot::Test uses the full path of the test script to determine which
optimizatio
# New Ticket Created by "Seneca Cunningham"
# Please include the string: [perl #52220]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52220 >
herodotus:parrot seneca$ ./parrot t/op/01-parse_ops_335.pasm
Bus error
Crash rep
On Fri, Mar 28, 2008 at 9:42 PM, via RT Seneca Cunningham
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by "Seneca Cunningham"
> # Please include the string: [perl #52220]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=
On Fri Mar 28 21:03:12 2008, [EMAIL PROTECTED] wrote:
> Parrot::Test uses the full path of the test script to determine which
> optimization flags to pass parrot. The method used causes the bogus
> optimization value '/' to be extracted when running the tests in
> /opt/foo as the character immedia
Coke et al.:
Please evaluate the patch attached for commitment to trunk. As per my
most recent post, it does not eliminate Parrot::Revision completely, but
it does limit its scope to 'svn'.
kid51
Index: tools/build/revision_c.pl
===
chromatic wrote:
On Friday 28 March 2008 11:55:30 James Keenan via RT wrote:
Am confused. What diagnostic output beyond 'prove -v' are you referring
to?
For example...
t/op/arithmetics1..26
ok 1 - take the negative of a native integer
ok 2 - take the absolute of
# New Ticket Created by Stephane Payrard
# Please include the string: [perl #52230]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=52230 >
the code pmc.ops :96-97 seems redundant: pmc_type() is called twice
with the same
As of this morning only the following files still need conversion
for P6Regex, P6Grammar, and/or pgc:
examples/pge/all.pir
languages/tap/Makefile
The examples/pge/all.pir file is a very outdated example of
writing parsers using PGE -- the new way of doing it is
to use Perl6Grammar or som
On Saturday 29 March 2008 06:50:51 jerry gay wrote:
> the contents of t/op/01-parse_ops_335.pasm should be somewhere between
> 2 and 12 lines. could you paste it inline? it would help us find the
> op(s) causing the segfault.
The code is:
end
yield
... and it crashes because the
On Sat, 29 Mar 2008 07:03:17 -0700
"James Keenan via RT" <[EMAIL PROTECTED]> wrote:
> If we simply add a forward slash after 'opt', does that solve the
> problem? (see attached)
Should this code really be checking the absolute pathname? We don't
have any control over where a user places a parrot
On Sat, 29 Mar 2008 11:59:25 -0700
Mark Glines <[EMAIL PROTECTED]> wrote:
> This changes Parrot::Test's behavior: an alternate "-O" option will
> only be used if the *filename* contains "optN", not if a leading
> directory name contains it. I don't see any uses of "optN" in
> directory names in t
On 29/03/2008, James Keenan via RT <[EMAIL PROTECTED]> wrote:
> On Fri Mar 28 21:03:12 2008, [EMAIL PROTECTED] wrote:
> > Parrot::Test uses the full path of the test script to determine which
> > optimization flags to pass parrot. The method used causes the bogus
> > optimization value '/' to b
Oops. I only reported the $extraLibs patch to the mailinglist.
diff -ub ./CREDITS.orig
--- ./CREDITS.orig 2008-03-16 08:15:14.0 +0100
+++ ./CREDITS 2008-03-20 11:31:01.5 +0100
@@ -514,6 +514,10 @@
E: [EMAIL PROTECTED]
W: http://www.bofh.org.uk:8080/
+N: Reini Urban
+E:
On Saturday 29 March 2008 09:01:21 Stephane Payrard wrote:
> the code pmc.ops :96-97 seems redundant: pmc_type() is called twice
> with the same args for no apparent reason. And it seems to be a pure
> function.
> same for another pmc creator.
>
> I recompiled the patched code and tested rakud
On Wednesday 19 March 2008 06:25:32 Klaas-Jan Stol wrote:
> I don't commit this myself, because I want to check whether this
> practice of localizing vars. is ok, as it introduces "else" clauses.
That seems reasonable.
> Not sure whether which is better. My personal preference is the patch,
> ob
On Saturday 29 March 2008 11:58:53 Reini Urban via RT wrote:
> Oops. I only reported the $extraLibs patch to the mailinglist.
Thanks, applied in full as r26632.
-- c
On Saturday 29 March 2008 09:42:55 Patrick R. Michaud wrote:
> As of this morning only the following files still need conversion
> for P6Regex, P6Grammar, and/or pgc:
>
> examples/pge/all.pir
> languages/tap/Makefile
>
> The examples/pge/all.pir file is a very outdated example of
> writing
On Saturday 29 March 2008 07:22:35 James Keenan via RT wrote:
> Please evaluate the patch attached for commitment to trunk. As per my
> most recent post, it does not eliminate Parrot::Revision completely, but
> it does limit its scope to 'svn'.
Remove the commented-out code and +1 from me.
-- c
On Wednesday 19 March 2008 07:15:17 [EMAIL PROTECTED] wrote:
> Attached patch favors make over nmake on cygwin only, because there's
> normally no gmake, but sometimes a nmake in the PATH.
Thanks, applied as r26633.
-- c
On Friday 28 March 2008 11:14:03 James Keenan wrote:
> This is one of a series of tickets reporting issues encountered at a
> Parrot/Rakudo buildfest held at Toronto Perlmongers on March 27, 2008.
>
> On the same Win32 box mentioned in RT 52198, the developer attempted
> to build Rakudo, but '
On Thursday 27 March 2008 18:20:21 Patrick R. Michaud wrote:
> Actually, it can be done without subclassing via the following
>
> .namespace [ 'ResizablePMCArray' ]
>
> .sub 'unshift' :method
> .param pmc list
> .param pmc value
> unshift list, value
> .end
>
> .sub 'shift' :method
>
On Wednesday 19 March 2008 06:57:46 Reini Urban wrote:
> I like the idea of make perl6 only on windows.
> make perl6.exe is just a file, make perl6 is a whole new world :)
>
> One could
>
> ifdef WINDIR
> perl6 : $(PERL6)
> endif
>
> for the GNU-style makefile on cygwin
> and with the appropriate
On Sat, Mar 29, 2008 at 12:42 PM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> As of this morning only the following files still need conversion
> for P6Regex, P6Grammar, and/or pgc:
>
> examples/pge/all.pir
> languages/tap/Makefile
>
> The examples/pge/all.pir file is a very outdated
On Thursday 13 December 2007 19:32:11 Will Coleda wrote:
> For example, parrotclass.pmc, parrotobject.pmc.
>
> ... Should this file be auto-generated?
That's not easy, because config/auto/pmc.pm uses it to allow people to select
at configuration time which PMCs to include and exclude.
I'm not s
S06.pod says (line 2698):
: Ordinarily a top-level Perl "script" just evaluates its anonymous
: mainline code and exits. During the mainline code, the program's
: arguments are available in raw form from the C<@ARGS> array. At the end of
: the mainline code, however, a C subroutine will be calle
On Friday 09 November 2007 00:24:43 Paul Cochrane wrote:
> I'll have a go at testing against the exec runcore and see what turns
> up. This is likely something we should be testing more often right?
Definitely.
I ran a fulltest with this patch applied, and everything's fine on x86 (where
it ma
In general, is
[op] (p1,p2,p3,p4...)
expected to return the same result as
p1 op p2 op p3 op p4...
including precedence considerations?
That is, should
[**](2,3,4)
return 2^(3^4)=2^81, or (2^3)^4 = 4096?
--
Mark J. Reed <[EMAIL PROTECTED]>
Author: larry
Date: Sat Mar 29 20:16:29 2008
New Revision: 14529
Modified:
doc/trunk/design/syn/S06.pod
Log:
fossil noticed by pmichaud++
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod
On Sat, Mar 29, 2008 at 10:18:53PM -0400, Mark J. Reed wrote:
: In general, is
:
: [op] (p1,p2,p3,p4...)
:
: expected to return the same result as
:
: p1 op p2 op p3 op p4...
:
: including precedence considerations?
:
: That is, should
:
: [**](2,3,4)
:
: return 2^(3^4)=2^81, or (2^3)^4 = 40
You anticipated me. So, is there a core method for
foldl/foldr/inject/reduce, or do you have to roll your own as in p5?
On 3/29/08, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 29, 2008 at 10:18:53PM -0400, Mark J. Reed wrote:
> : In general, is
> :
> : [op] (p1,p2,p3,p4...)
> :
> : expec
33 matches
Mail list logo
