On Wednesday 09 July 2008 08:27:35 Andrew Johnson wrote:
> > Done in r29179, please confirm that gives no warning now.
>
> Confirmed, those warnings have gone. I'm still getting loads of "warning:
> statement not reached" but I'll work out how to suppress those and post a
> fix separately.
Does
On Wednesday 09 July 2008 13:46:19 Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Wed, 9 Jul 2008 08:25:52 -0500
>If I understand what you're saying, and then take it to what I see
>as its ultimate conclusion, you're basically claiming that every
>cal
On Wednesday 09 July 2008 15:37:51 Bob Rogers wrote:
>I suspect the motivation for the bizarreness of the specification is the
>desire to make code like this work in Parrot:
>
> {
> my $x;
>
> sub set_x { $x = shift }
> sub get_x
I've just committed a change (r29239) to allow Rakudo to build and run the
basic tests on the pdd25cx branch. Most of it works.
Test Summary Report
---
t/01-sanity/05-sub (Wstat: 256 Tests: 2 Failed: 0)
Non-zero exit status: 1
Parse errors: Bad plan. You planned
On Thursday 10 July 2008 10:29:16 Will Coleda wrote:
> On Thu, Jul 10, 2008 at 1:25 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > I've just committed a change (r29239) to allow Rakudo to build and run
> > the basic tests on the pdd25cx branch. Most of it work
On Thursday 10 July 2008 14:41:50 NotFound wrote:
> I changed the signature from PMC * to const PMC * in r29253, otherwise
> using it with const gives warings in C and fails in C++.
>
> What is the reason to have an interp parameter? Looks like an
> unnecessary overhead in a frequently used functi
On Thursday 10 July 2008 17:33:23 Patrick R. Michaud (via RT) wrote:
> There are a couple of issues with PMCProxy:
>
> 1. The PMCProxy returned from a get_class opcode isn't
> the same as one obtained from using typeof on an instance
> of the type.
>
> 2. Each invocation of typeof return
On Friday 11 July 2008 13:32:40 Will Coleda via RT wrote:
> > Two versions:
> > Full CVS-style version: disassemble-long.patch
> > I don't know how svn handles file renames.
> > After svn renaming it would just be the shorter disassemble_rename.patch
> This seems to have been warnocked. I have n
On Friday 11 July 2008 20:59:05 Patrick R. Michaud wrote:
> You're _completely_ missing my point. If we follow my proposal
> to modify Parrot or code generation such that a capture operation
> is performed for closures at the beginning of every outer sub
> invocation, then by the time we get to a
On Saturday 12 July 2008 08:06:33 Patrick R. Michaud wrote:
> Short answer: cloning is what will enable the following to work:
>
> for 1..10 -> $x {
> sub foo() { say $x; }
> push(@foos, &foo);
> }
Is that really valid Perl 6 code? I can see "my sub foo" working there, b
On Saturday 12 July 2008 01:07:20 chromatic wrote:
> Obviously all Closures need valid captured contexts, but we have a big
> problem when attempting to invoke a named Closure before attaching its
> captured context. In Perl 5 terms, this is the relevant code:
>
> {
>
On Saturday 12 July 2008 14:01:17 [EMAIL PROTECTED] wrote:
> Added:
>trunk/t/op/lexicals-2.t (contents, props changed)
> Modified:
>trunk/MANIFEST
>
> Log:
> * t/op/lexicals-2.t (added), MANIFEST:
>+ Add three more lexical tests, pursuant to RT#56398. The second is
> "todo", wi
On Sunday 13 July 2008 09:33:31 Will Coleda wrote:
> Working on this, I see that we have a ^L before the coda in quite a
> few files in, e.g.: tools/build/; This isn't Tidy.
>
> ISTR this was done purposefully. Anyone remember why?
Emacs needs its read-only marking in the final logical page of t
On Sunday 13 July 2008 15:27:10 Bob Rogers wrote:
> I'm open to suggestions.
>
>(I'm not sure it needs to be a separate file.)
>
> At the time, I was thinking that having a separate file for longer cases
> was a good idea. But "prove t/op/lexicals.t" takes only 4s on my
> machine, so I guess
On Saturday 12 July 2008 21:52:52 Christoph Otto via RT wrote:
> The test now passes, although I'll leave this ticket open until someone
> can confirm that it still does the right thing.
>
> The new version of t/codingstd/c_macro_args.t as of r29372 has several
> special cases: stringification, co
On Sunday 13 July 2008 17:55:59 [EMAIL PROTECTED] wrote:
> Modified:
>branches/gsoc_pdd09/src/gc/gc_it.c
>
> Log:
> [gsoc_pdd09] Stop sweeping const_PMC pools for now (causes weird error).
> Added a note about this.
>
> Modified: branches/gsoc_pdd09/src/gc/gc_it.c
> ===
On Tuesday 15 July 2008 17:23:20 James E Keenan wrote:
> Bernhard Schmalhofer wrote:
> > for Parrot 0.6.4 following Perl 5 modules were not indexed:
> >
> > Parrot::Configure::Options::Test::Prepare
> > Parrot::Pmc2c::PMC::PrintTree
>
> Barney: I know that I wrote the two modules above (or, at l
On Wednesday 16 July 2008 19:54:57 James Keenan via RT wrote:
> This module is written in Perl 5 and is called in a program written in
> Perl 5. In the work I've done in this project, I've taken the approach
> to return values which I think is more Perlish, namely, if a subroutine
> completes and
On Thursday 17 July 2008 08:49:05 Will Coleda wrote:
> I committed a patch (r29559) that updates all the tcl.ops to be more
> like the 'die' opcode in how the exception object is constructed and
> created. Still segfaulting. As long as I'm in here, I'm going to
> eliminate the forms of tcl_error t
On Thursday 17 July 2008 15:44:36 NotFound wrote:
> <[EMAIL PROTECTED]> wrote:
> > With this patch, the new tests still pass on Linux/x86. The patch uses
> > STRING->strstart to avoid leaking a malloc'd buffer when throwing an
> > exception, which may or may not be considered kosher in this situa
On Thursday 17 July 2008 19:15:52 James Keenan via RT wrote:
> + if (! defined $args->{revision}) {
> + $args->{revision} = 'unknown';
> + _print_to_cache($args->{cache}, $args->{revision});
> + return $args->{revision};
> + } else {
> + if (defined ($args->{prev}
On Thursday 17 July 2008 14:16:42 [EMAIL PROTECTED] wrote:
> Added:
>branches/gsoc_pdd09/t/op/gc.old (contents, props changed)
> Modified:
>branches/gsoc_pdd09/t/op/gc.t
>
> Log:
> [gsoc_pdd09] Temporarily remove the t/op/gc.t file. It's messing up like
> crazy and I dont know that my GC
On Saturday 19 July 2008 09:57:02 [EMAIL PROTECTED] wrote:
> Log:
> [PDD13]
> * Implement get_directory().
> * Fix get_string() so it works.
> * Add the beginnings of a test script for the Packfile class.
> --- branches/pdd13pbc/src/pmc/packfile.pmc(original)
> +++ branches/pdd13pbc/src/pmc/p
On Sunday 20 July 2008 17:37:28 James Keenan via RT wrote:
> If no one currently has any more ideas on the subject of this ticket, I
> will close it.
Running it less frequently -- over all PMCs at once -- would speed it up,
especially on Windows. Unfortunately, that would introduce a bottleneck
On Sunday 20 July 2008 18:19:05 James Keenan via RT wrote:
> 1 test still not passing as of r29636:
>
> not ok 36 - invalid label syntax # TODO RT#47978, RT#51104
>
> # Failed (TODO) test 'invalid label syntax'
> # at t/compilers/imcc/syn/macro.t line 469.
> # 'compilers/imcc
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 lang
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?
-- c
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
The wiki page at:
http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_notes
seems to be missing the rationale for *why* it's necessary to map types
between languages? (Also see "If Perl 6 has to care about the internal
storage format of an Integer PMC, it's doing something
On Tuesday 22 July 2008 06:34:13 Moritz Lenz wrote:
> There are actually many problems. For example, if a TCL function returns
> an integer, what will Perl 6 see?
A PMC, which presumably performs the Integer role (in Parrot terms). If Tcl
on Parrot doesn't return this, Tcl on Parrot is wrong an
On Monday 21 July 2008 18:38:55 [EMAIL PROTECTED] wrote:
> --- branches/gsoc_pdd09/src/gc/gc_it.c (original)
> +++ branches/gsoc_pdd09/src/gc/gc_it.c Mon Jul 21 18:38:55 2008
> @@ -239,6 +239,11 @@
> {
> const Arenas * const arena_base = interp->arena_base;
> Gc_it_data * const gc_
On Tuesday 22 July 2008 21:58:10 Mark Glines wrote:
> Integer is a good example of the problem, actually.
>
> The internal storage format doesn't change,
It certainly can. I imagine that Kea-CL's Integers autopromote to BigInts (or
whatever the name is), and that might require a certain precisi
On Thursday 24 July 2008 06:01:59 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/config/init/hints/darwin.pm
>
> Log:
> [darwin] Apply patch from RT #57224. kasei++, rurban++.
> * Reverse the order of @arches in the darwin hints file. Since /ppc/ will
> match both "ppc" and "ppc64", it is imp
On Thu, Jul 24, 2008 at 11:05:28PM -0700, Christoph Otto via RT wrote:
> From what I can tell, t/src/list.t was deleted or moved sometime after
> r22464. Searching for some of the more unique-looking strings in that
> revision of the file (
> http://www.parrotvm.org/svn/parrot/checkout/trunk/t/sr
On Thursday 10 July 2008 13:42:07 Andrew Whitworth wrote:
> I found this while tracking a nasty GC-related bug. In
> src/packfile/pf_items.c:PF_fetch_integer, we have the following two
> notes:
>
> XXX assumes C INTVAL size in the PackFile header
>
> XXX assume sizeof (opcode_t) == sizeof (INTVAL)
On Friday 25 July 2008 01:12:55 Christoph Otto via RT wrote:
> According to make cover, the case where the return was -1 was never hit.
> A simple test case caused a segfault, which definitely isn't the right
> thing. The attached patch fixes and refactors intlist_get() to make the
> coverage mo
"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/
On Friday 25 July 2008 15:46:25 Jeff Lavallee wrote:
> Latest parrot code from svn. During make test, t/example/library.t fails:
>
> t/examples/library...ok 1/4Failed to load libpcre
> current instr.: 'parrot;PCRE;init' pc 110 (library/pcre.pir:111)
> called from Sub 'parr
On Wednesday 30 July 2008 11:20:33 Andy Dougherty wrote:
> Ahh -- it's just an octal/decimal mix-up. Here's the patch:
>
> --- parrot-current/t/steps/auto_icu-01.t 2008-07-30 13:45:19.0
> -0400 +++ parrot-andy/t/steps/auto_icu-01.t 2008-07-30 14:15:44.0
> -0400 @@ -228,7 +2
On Wednesday 30 July 2008 12:10:32 Andy Dougherty wrote:
> Yes, but we might as well clean up the other two cases as well. So this
> goes on top of yours:
>
> --- parrot-svn/t/steps/auto_icu-01.t 2008-07-30 15:05:43.0 -0400
> +++ parrot-x86/t/steps/auto_icu-01.t 2008-07-30 15:06:34.
On Thursday 31 July 2008 13:53:21 Moritz Lenz wrote:
> rurban ask on IRC if somebody already tested parrot with llvm-gcc. So I
> just tried it out, and, *miracle*, it actually worked. Without any
> modifications.
>
> Just a
> make realclean; perl Configure.pl --cc=llvm-gcc && make test
> yields
> A
On Thursday 31 July 2008 16:27:58 James Keenan via RT wrote:
> I tried again today to apply this patch and I still cannot get it to
> apply cleanly. I got this *.rej file:
>
> $ cat config/gen/makefiles/root.in.rej
> ***
> *** 379,384
> \
> $(OPS_DIR)/core_ops$(O) \
On Thursday 31 July 2008 16:38:01 James Keenan via RT wrote:
> Should we still have this patch under consideration, and the related
> issues under discussion?
Yes. I need to check in a test case and see if it's still a problem. (I
believe it is; there's precious little testing of vtable freeze
On Monday 04 August 2008 16:36:15 Andrew Whitworth wrote:
> I edited PDD09 tonight to try and add some details and some
> clarification on points that weren't particularly clear before. I have
> a few questions that need answering before I can do more:
>
> 1) GC_trace_normal and GC_trace_stack_FLA
On Tuesday 05 August 2008 07:51:35 Will Coleda wrote:
> Using svn as a backing store, how can we more easily work with long
> lived branches?
>
> I've some existing branches which are long lived, and doing the svn
> merge either way is extremely slow.
>
> I know much of our community used svk for
On Tuesday 05 August 2008 09:48:22 Will Coleda wrote:
> Branches that don't rebase from trunk regularly are out of
> touch, yes. If you rebase regularly, then you're basically just a
> patch waiting to be applied.
... and, as time goes by, an ever-larger patch waiting to land on trunk with a
big
On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote:
> We will definitely need multiple long-lived branches. Just to make
> explicit the reasoning: data loss, security, or otherwise critical
> bugfixes that should be backported to one or more already released
> versions and re-released im
On Tuesday 05 August 2008 13:14:27 Geoffrey Broadwell wrote:
> > I can see patching the previous release in case of a critical bugfix, but
> > if we get in the habit of encouraging users to expect updates of anything
> > older than the previous stable release for free, we've doomed the
> > project
On Tuesday 05 August 2008 13:19:52 Michael Peters wrote:
> If you deprecate a
> feature in 1 version and then it disappears in the next then the time
> between when my code works and when it doesn't is only 6 months. Some
> distros provide support for several years.
If they want to support ancien
On Tuesday 05 August 2008 01:35:48 Reini Urban wrote:
> Attached patch adds the directory ports/cygwin with
> the most recent cygports file,
> the most recent src patch and the sources for the CYGWIN patches.
> (the contents of parrot-0.6.4-2.cygwin.patch which creates those files
> in CYGWIN-PATC
On Sunday 03 August 2008 05:15:07 Reini Urban wrote:
> Attached patch adds support for the old ctags/etags from XEmacs 21
Thanks, applied as r30049.
-- c
On Thursday 31 July 2008 15:16:33 Donald Hunter wrote:
> This is a patch for t/pmc/os.t to fix test failures on Cygwin. This is
> generated against revision 29913.
Thanks, applied as r30050.
> One anomaly remains. The test was skipping the inode field for Cygwin
> because the installed Perl 5 is
On Monday 04 August 2008 16:22:35 Will Coleda via RT wrote:
> Post pdd25cx mergeback, updating the syntax yet again, and simplifying it
> slightly, we have the attached file, which generates:
>
> ok #test exception from init vtable
> not ok #test exception from init vtable
>
> Even better, remove
On Wednesday 06 August 2008 11:08:13 Will Coleda wrote:
> > Sometimes the register allocator will re-use a register when it's
> > important that the register not be reused.
>
> Can you describe a situation where this occurs that isn't a bug in the
> register allocator?
I can't think of one.
-- c
On Thursday 07 August 2008 08:26:19 Bob Rogers wrote:
> I once suggested a "null register allocator" that would do this
> globally, but this is a better idea. The only use case I can think of
> is debugging, particularly of the register allocator, but that's still
> important.
In theory, that's
On Thursday 07 August 2008 05:16:40 Carl Mäsak wrote:
> r30087:
> $ ./perl6 -e 'subset A of Int where 1; my A $a = 1' # this works
> $ ./perl6 -e 'subset A of Int where 1; my A $a = 0' # this fails (as
> it should) but segfaults
> Type check failed
> [...]
> Segmentation fault
>
> I was not able t
On Thursday 07 August 2008 23:50:54 [EMAIL PROTECTED] wrote:
> Add a return continuation attribute to the Exception pmc and fill it in the
> throw opcode.
>
>
> Modified: trunk/src/ops/core.ops
> ===
>=== --- trunk/src/ops/core
On Saturday 09 August 2008 06:33:46 James Keenan via RT wrote:
> > What purpose remains, then, for either tools/dev/ops_renum.mak or my
> > alternative, tools/dev/opsrenumber.pl? Is such a program only intended
> > to provide a number for newly added opcodes?
> We haven't had any response to thi
On Saturday 09 August 2008 10:30:30 [EMAIL PROTECTED] wrote:
> Log:
> MANIFEST and SKIP were not updated before a recent commit.
>
> Modified: trunk/MANIFEST
> --- trunk/MANIFEST(original)
> +++ trunk/MANIFESTSat Aug 9 10:30:30 2008
> @@ -2820,16 +2821,6 @@
> lib/SmartLink.pm
On Wednesday 06 August 2008 22:42:52 Seneca Cunningham via RT wrote:
> I've stopped the crashes that appear related to this on my box with the
> attached patch. config/gen/platform/darwin/memalign.c has a few unsigned
> variables that were being implicitly handled as (32-bit) ints, those
> variabl
few thousand cycles faster than the const_string version. That's disturbing,
and well worth someone exploring for an explanation. I've put up the
relevant callgrind.out files for anyone who wants to poke around with
callgrind or kcachegrind.
http://www.wgz.org/chromatic/tmp/fib_
On Wednesday 13 August 2008 07:36:45 Andy Dougherty wrote:
> The problem appears to be in config/init/hints/solaris.pm in
> the solaris_link_cb function. That function tries to compile and run a
> simple test.c program. I don't know where the _3877 part of the
> filename is coming from, but it's
On Tuesday 12 August 2008 15:05:58 Andrew Whitworth via RT wrote:
> We could change all the function
> definitions in the IMCC related files to use "struct _IMC_Unit" instead
> of "IMC_Unit" which would resolve the problem. Alternatively, we could
> rearrange the way the header files are ordered/c
On Wednesday 13 August 2008 17:30:39 James Keenan via RT wrote:
> I think this patch is worth considering and I encourage comments from
> those Parrot developers who are knowledgeable about these "file coda"
> issues, how they appear in vi and emacs, etc.
>
> Since this patch is likely to affect a
On Wednesday 13 August 2008 19:39:16 James Keenan via RT wrote:
> Okay, thanks for getting back to me. Could you read the inline comments
> I have inserted into Parrot::OpsRenumber::renum_op_map_file()?
>
> Do the comments accurately reflect what needs to happen re opcode
> renumbering both now a
On Friday 15 August 2008 09:07:46 Geoffrey Broadwell wrote:
> It seems then that we have two remaining options:
>
> 1. Don't run codingstd as part of smolder.
>
> 2. Differentiate a codingstd failure and a "real" failure in smolder.
>
> Which one of these are you proposing?
+1 to either. #1
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
On Sunday 17 August 2008 09:29:14 Bob Rogers wrote:
>I notice that docs/project/release_manager_guide.pod says (line 123):
>
> It is not necessary to quiet all the codingstd tests for a
> release.
>
> Since these tests are on "make test" (and hence visible to
> non-developers), and
On Wednesday 13 August 2008 15:20:08 Andrew Johnson via RT wrote:
> Almost, you just missed the executable itself (-o arg). This patch
> works for me.
Thanks, applied as r30282.
-- c
Author: chromatic
Date: Sun Aug 17 13:26:18 2008
New Revision: 30284
Modified:
trunk/docs/pdds/draft/pdd08_keys.pod
trunk/docs/pdds/pdd09_gc.pod
trunk/docs/pdds/pdd23_exceptions.pod
trunk/docs/pdds/pdd27_multiple_dispatch.pod
Log:
[PDD] Fixed PDD linewrapping at 78 characters, per
On Sunday 17 August 2008 09:22:34 chromatic wrote:
> 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.
Fixed in r30286.
-- c
On Sunday 17 August 2008 11:16:08 Reini Urban wrote:
> Without --optimize ./parrot t/pmc/namespace_65.pir works fine.
> It prints
> bar
> 2
> With --optimize ./parrot t/pmc/namespace_65.pir hangs after the 2.
>
> Attaching the debugger to a non-debug build is too heavy for me now,
> I'll try to ge
On Sun, Aug 17, 2008 at 08:01:32PM -0400, James E Keenan wrote:
> Bob Rogers wrote:
> > *** gmake codingstd_tests
> > Failed Test Stat Wstat Total Fail Failed List of Failed
> >
> > t/codingstd/c_
On Mon, Aug 18, 2008 at 12:55:35PM -0400, Will Coleda wrote:
> This causes languages/tcl/cmd_namespace.t to fail. (Reverting this one
> change locally allows the test to pass).
I'm pretty sure that Rakudo and Tcl want different things from NameSpaces.
This code has a strong smell.
--
Oh yeah.
On Mon, Aug 18, 2008 at 04:49:59PM -0400, Will Coleda wrote:
> > I'm pretty sure that Rakudo and Tcl want different things from NameSpaces.
> > This code has a strong smell.
> Can you be more specific as to the odor?
Do namespaces nest? Can you access them with String keys? How about Key keys?
On Wed, Aug 20, 2008 at 01:00:24PM +0300, Nikolay Ananiev wrote:
> Today I saw Andrew's last post in his blog about the end of gsoc.
> Since I could not find much information about the NCI and GC projects I'm
> asking here: What's the status of these projects?
> Andrew's last post seems discouragi
On Wed, Aug 20, 2008 at 01:22:33PM -0400, Will Coleda wrote:
> On Wed, Aug 20, 2008 at 1:15 PM, chromatic <[EMAIL PROTECTED]> wrote:
> > The overall concepts of the incremental GC are solid, but a couple of
> > details
> > of the implementation need polishing. It
On Thursday 21 August 2008 15:08:22 [EMAIL PROTECTED] wrote:
Mostly minor codingstd nits.
> Modified:
>branches/pdd27mmd/src/pmc/multisub.pmc
>
> Log:
> [pdd09gc] add basic (and probably wrong) implementations for
> MultiSub:get_pmc_keyed and MultiSub:get_pmc_keyed_string
>
> --- branches/pdd
27;
# at t/pmc/threads.t line 164.
# Exited with error code: 139
# Received:
# ok 1
# Null PMC access in get_integer_keyed_str()
# current instr.: 'foo' pc 49
(/home/chromatic/dev/parrot/t/pmc/threads_4.pir:20
)
# Segmentation fault
#
# Expected:
# ok 1
# hello from thread
# ParrotThrea
On Monday 25 August 2008 07:16:08 Will Coleda wrote:
> Hitting enter immediately after successfully starting the debugger
> throws an error.
>
> $ cat foo.pir
> .sub main
> say 'hi'
> .end
> $ ./parrot_debugger foo.pir
> Parrot 0.7.0-devel Debugger
>
> Please note: the debugger is currently under
On Tuesday 26 August 2008 00:16:10 [EMAIL PROTECTED] wrote:
> Log:
> [pipp] more freed and PIR'd phparray tests
> --- trunk/languages/pipp/t/pmc/array.t(original)
> +++ trunk/languages/pipp/t/pmc/array.tTue Aug 26 00:16:09 2008
> @@ -562,9 +567,296 @@
> is_ok = 0
> current_a
On Tuesday 26 August 2008 06:13:07 [EMAIL PROTECTED] wrote:
> --- trunk/compilers/pirc/new/pircompunit.c (original)
> +++ trunk/compilers/pirc/new/pircompunit.c Tue Aug 26 06:13:06 2008
> @@ -24,6 +24,29 @@
> of the parsed PIR code. Through the symbol management, which is done
> in F,
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
On Sunday 31 August 2008 14:23:50 Ron Schmidt wrote:
> Warning occurs when issuing 'perl Configure.pl' under cygwin where the
> LANG environment variable does not have a default value on my system.
> Patch to fix is included below.
>
> Index: lib/Parrot/Revision.pm
> ==
On Sunday 31 August 2008 14:04:53 [EMAIL PROTECTED] wrote:
> +PARROT_API
> +void
> +Parrot_pcc_invoke_sub_from_sig_object(PARROT_INTERP, ARGIN(PMC *sub_obj),
> + ARGIN(PMC *sig_obj))
> +{
> +#define PCC_ARG_MAX 1024
> + /* variables from PCCINVOKE impl in PCCMETHOD.pm */
> + /* args I
On Monday 25 August 2008 08:41:39 Jeff Horwitz wrote:
> rakudo cannot write to %*ENV because the underlying Env PMC apparently
> does not update the environment when using a non-keyed opcode:
The Env PMC is a thin wrapper around setenv(3) and getenv(3). We can change
it to store STRING and PMC
On Tuesday 08 July 2008 20:56:03 jason switzer wrote:
> When trying to use the --optimize flag, building perl6 causes parrot to
> segfault. Attached is the Configure.pl script output. Below is a backtrace
> by manually performing the make step from gdb. You'll notice the second run
> performs the
On Wednesday 20 August 2008 12:48:27 Reini Urban wrote:
> make dotnet work with the new exceptions.
> I'm not sure how to return the jump_point correctly, but it looks fine.
Thanks, applied as r30718.
-- c
On Thursday 04 September 2008 08:44:26 Patrick R. Michaud (via RT) wrote:
> Currently the only (documented) way to set up HLL mapping is
> by using the .HLL_map directive in PIR. However, this leads
> to a bootstrapping problem of sorts when attempting to
> map classes created in PIR (which often
On Saturday 06 September 2008 18:41:25 Patrick R. Michaud wrote:
> On Sat, Sep 06, 2008 at 05:02:44PM -0700, [EMAIL PROTECTED] wrote:
> > Log:
> > Add hll_map method to parrotinterpreter.pmc
>
> ...doesn't seem to work yet, at least not on my system:
>
> $ cat x.pir
> .HLL 'Perl6', ''
>
> .sub 'ma
On Saturday 06 September 2008 20:19:56 James Keenan via RT wrote:
> On Sat Sep 06 16:46:08 2008, doughera wrote:
> > > ... what *else* would I need to have AIO available on Darwin?
> >
> > It looks like you already have it available. If you try with my patch in
> > verbose mode, what, exactly, go
The scalar PMC is abstract, but it contains multis that need registration with
the MMD system at initialization time. PMCs containing multis register those
multis in their Parrot__class_init() functions.
At least, non-abstract PMCs do.
I ran into a similar problem with my vtable cloning work.
On Monday 08 September 2008 07:36:51 jerry gay wrote:
> On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal <[EMAIL PROTECTED]> wrote:
> > a) Do abstract base classes as currently implemented in Parrot serve any
> > useful purpose? If not, eliminate them.
>
> can they be replaced by roles?
Exactly my
Author: chromatic
Date: Mon Sep 8 10:22:15 2008
New Revision: 30892
Modified:
trunk/docs/pdds/draft/pdd30_install.pod
Log:
[PDD] Fixed linebreaking in PDD 30 draft to conform to coding standards.
Modified: trunk/docs/pdds/draft/pdd30_install.pod
On Monday 08 September 2008 12:57:00 Christoph Otto via RT wrote:
> On Tue Sep 11 03:32:51 2007, pcoch wrote:
> > Having a look through PDD03 I noticed the TODO item left by Chip:
> >
> > =head3 Overflow
> >
> > If too many values are provided to fit into the given target
> > registers, Parro
On Tuesday 09 September 2008 09:51:37 Allison Randal wrote:
> jerry gay wrote:
> > can they be replaced by roles?
> Potentially, yes. In the case of the scalar PMC it would make quite a
> bit of sense as a role (composing in behavior common to scalar data
> types). For the default PMC it makes l
t/op/calling_61.pir crashes because Parrot's trying to treat the number -1 as
a PMC. Why?
Parrot_convert_arg (interp=0x804f040, st=0xbf8b70c0) at src/inter_call.c:905
905 if (key->vtable->base_type != enum_class_Key)
(gdb) bt
#0 Parrot_convert_arg (interp=0x804f040, st=0xbf8b70c0)
a
On Tuesday 09 September 2008 15:34:21 [EMAIL PROTECTED] wrote:
> [pdd27mmd] Fix failing coding standards test for line length.
>
>
> Modified: branches/pdd27mmd/src/multidispatch.c
> ===
>=== --- branches/pdd27mmd/src/multidis
On Tuesday 09 September 2008 11:07:09 [EMAIL PROTECTED] (via RT) wrote:
> I attached a tar-file that holds one patch file (generated with diff -u)
> for each modified file.
This makes patches very difficult to review; can you send a single patch file
instead?
-- c
On Wednesday 10 September 2008 10:45:12 Moritz Lenz wrote:
> I tried to build parrot with the clang, an llvm frontend. It provides a
> script called 'ccc', which accepts the same options as gcc.
>
> Configure works fine (perl Configure.pl --verbose --cc=ccc --link=ccc).
>
> src/pmc/default.c:65:36
1 - 100 of 1673 matches
Mail list logo
