ps
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/src/ops/core_ops_cgp.c
> /var/tmp/portage/dev-lang/parrot-
> 0.4.9/image//usr/src/ops/core_ops_switch.c
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/src/nci.c
> /var/tmp/portage/dev-lang/parrot-0.4.9/image//usr/src/nul
On Tue, Apr 28, 2009 at 10:31 PM, James Keenan via RT
wrote:
> The 'reallyinstall' target is gone, so we can resolve this ticket.
> ___
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
reallyinstall is now just 'install' - it's possible the issue
The 'reallyinstall' target is gone, so we can resolve this ticket.
On Apr 17, 2009, at 5:29 PM, Vasily Chekalkin via RT wrote:
On Sat Nov 17 11:46:09 2007, chroma...@wgz.org wrote:
In tools/build/pbc2c.pl there is the todo item:
/* TODO make also a shared variant of PackFile_new */
There is no more tools/build/pbc2c.pl. Can we close this ticket?
--
Bacek
On Thu, 16 Apr 2009, NotFound via RT wrote:
> Closing this ticket, the patch is very outdated and nobody is reporting
> related problems. If someone found any problem with the Solaris C++
> compiler, or any other, please crate a new ticket in parrot trac.
The files may have moved so
On Sun, Mar 22, 2009 at 2:40 AM, Christoph Otto via RT
wrote:
> On Mon Oct 22 07:02:49 2007, pcoch wrote:
>> In src/pmc/hash.pmc:thaw() there is the todo item:
>>
>> * TODO create hash with needed size in the first place
>>
>> This needs to be implemented
>
> src/hash.c is already messy enough wit
On Tue, Feb 10, 2009 at 9:54 AM, Christoph Otto via RT
wrote:
> On Sun Feb 08 12:09:30 2009, jk...@verizon.net wrote:
>> On Tue Jul 10 05:15:33 2007, pcoch wrote:
>> > In the file lib/Parrot/Docs/POD2HTML.pm there is the todo item:
>> >
>> >
On Tue, Dec 16, 2008 at 12:20 PM, Ron Blaschke wrote:
> Andrew Whitworth wrote:
>> I'll pick up borland and play with it, although I won't get to it
>> until the next cycle. I've got a really old version of Turbo C++ 4.52
>> left over from school, and fre
Tue, Dec 16, 2008 at 1:20 PM, Ron Blaschke wrote:
>> Some time ago, because of this ticket, I tried with Borland C++ 5.5.1
>> and 5.82, and failed miserably. But that may just be my bad bcc-foo.
>> Unless someone's keen for this platform and has access to a fairly new
>>
On Tue, Dec 16, 2008 at 1:20 PM, Ron Blaschke wrote:
> Some time ago, because of this ticket, I tried with Borland C++ 5.5.1
> and 5.82, and failed miserably. But that may just be my bad bcc-foo.
> Unless someone's keen for this platform and has access to a fairly new
> (
Andrew Whitworth wrote:
> I'll pick up borland and play with it, although I won't get to it
> until the next cycle. I've got a really old version of Turbo C++ 4.52
> left over from school, and free versions of Turbo C++ Explorer are
> available for download. I don
I'll pick up borland and play with it, although I won't get to it
until the next cycle. I've got a really old version of Turbo C++ 4.52
left over from school, and free versions of Turbo C++ Explorer are
available for download. I don't promise any miracles, but at least I
will b
> I just tried to build parrot with g++ on darwin/intel to see if I could
> replicate the initial failure
> reported in the ticket, but am unable to. (g++ is detected as gcc, and then
> we pass it an option
> that makes it explode.)
What Configure options do you used? I usually do:
--cc=g++ --c
code; it's hard as it is without analyzing the text replacements of the
> c preprocessor.
>
> Also, given that IMCC will be replaced at some point, is it worth doing
> this task?
>
> If the general consensus to the above questions is "no", we can reject
> this ticket.
>
> Alan: Any update on this?
>
> Question for any Win32 expert: Is the Borland C compiler worth
> expending Parrot tuits on?
>
The Strawberry Perl route produced results, so I stopped whacking the
horse, on the assumption that it was dead.
--
Email and shopping with t
of the --configure_trace option. Read the POD for
> Parrot::Configure::Trace to see how you would then be able to trace the
> evolution of specific values inside the Parrot::Configure object as you
> go through the 60+ config steps.
>
Alan: Any update on this?
Question for any Win32
# New Ticket Created by Christoph Otto
# Please include the string: [perl #60556]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60556 >
If an exception handler catches an exception from a MULTI function implemented
i
# New Ticket Created by Brad Bowman
# Please include the string: [perl #60412]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60412 >
Misspelt "is" and "changed" in src/debug.c comments.
On Tue Sep 23 22:34:38 2008, cotto wrote:
>
> I propose to reject this ticket. Reducing code duplication is a good
> idea, but it's not at all clear to me what this ticket is referring to.
> If someone cares to point out what code should be merged, great.
> Otherwise this ticket is too vague to
On Mon Sep 22 06:37:24 2008, Whiteknight wrote:
>
> Sept 08 milestone came and went. Any updates on this ticket? Maybe this
> ticket should be closed out (since it's vague) and replaced with another
> ticket or tickets for individual places where exit_fatal should be
> replaced with real_except
Done in r31684 after MMD changes, adding the test from the previous patch.
> This check can be removed from default.pmc. Property values should not
> be returned by get_attr_str.
Done in r31509
On Mon Oct 22 09:47:52 2007, pcoch wrote:
> In src/pmc/fixedbooleanarray.pmc there is the todo item;
>
> * TODO merge this with functions from BigInt PMC
>
> The functionality in this file should be merged with that in the
BigInt PMC
I propose to reject this ticket. Reducing code duplication is
converted to real_exception() calls.
> > > internal exceptions are uncatchable, and might as well be called
> > > C. that's bad, ya dig?
> >
> >
> > For reference, I am attaching a list of files which, as of the date
> of
> > this post, contain the st
Marked as rejected.
Christoph Otto via RT wrote:
On Mon Oct 22 07:01:59 2007, pcoch wrote:
In src/pmc/hash.pmc:thaw() there is the todo item:
/* TODO make a better interface for hash creation
... do this.
Where do we want to go with this?
Ax the ticket. Vague plans for future change aren't useful.
Allison
I think you've gone about this in the right way, but need to handle the
various cases a bit more broadly. Specifically, you can't assume that
everyone has strerror() at all (Solaris 8 doesn't, for example) nor that
everyone who uses int strerror_r() will also define either _XOPEN_SOURCE
or _PO
terp, NULL,
EXCEPTION_EXTERNAL_ERROR, -errmsg);
+"%Ss", Parrot_strerror(interp, errno));
}
}
This pattern's almost common enough to tempt me to write
Parrot_ex_throw_strerror().
-- c
It was also almost enough to make me write Parrot_strerr
==
--- config/gen/platform/generic/strerror.c (revision 0)
+++ config/gen/platform/generic/strerror.c (revision 0)
@@ -0,0 +1,85 @@
+/*
+ * $Id$
+ * Copyright (C) 2007-2008, The Perl Foundation.
+ */
+
+/*
+
+=head1 NAME
+
+config/gen/platform/generic/st
Will Coleda via RT wrote:
On Tue Jul 22 23:34:13 2008, [EMAIL PROTECTED] wrote:
Christoph Otto via RT wrote:
This version of the patch should dtrt with all versions of
strerror_r. It
works on my Debian/x86 box and I'll be testing it on any *nix I can
get my
hands on Tuesday. If it works f
d returns an int, but
parrot INTVAL is not guaranteed to be int.
Even worse, "Trying to take the absolute value of the most negative
integer is not defined" (from the linux man page, and the C standard
if I remember well). So is not granted that we can take decisions
based on the result of abs, must be done before.
To obtain a safe implementation, abs must be avoided.
--
Salu2
On Mon Oct 22 07:01:59 2007, pcoch wrote:
> In src/pmc/hash.pmc:thaw() there is the todo item:
>
> /* TODO make a better interface for hash creation
>
> ... do this.
Where do we want to go with this?
On Thu Feb 21 12:15:06 2008, Whiteknight wrote:
> What would be the best way to handle this? We certainly don't need to do
> anything on systems where INT_MAX == -INT_MIN, but a simple compiler
> directive should help to detect that case.
>
> In the event that abs(INT_MIN) > abs(INT_MAX), should
On Fri Feb 15 02:43:05 2008, [EMAIL PROTECTED] wrote:
>
> They're marked as MMD in vtable.tbl, so my guess is that they're not
> directly
> callable by vtable pointer from C. F (though admittedly
> out of
> date) suggests that mmd_dispatch_* is the right approac
Patrick R. Michaud wrote:
On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote:
That's backwards. Loading the language module is what registers the
compiler. The user never needs to access the compiler object for a
particular language directly unless they're compiling code from a st
On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote:
> That's backwards. Loading the language module is what registers the
> compiler. The user never needs to access the compiler object for a
> particular language directly unless they're compiling code from a string.
...or if they w
Will Coleda wrote:
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
That's probably the b
Andy Dougherty schrieb:
On Thu, 28 Aug 2008, Reini Urban wrote:
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wh
On Thu, 28 Aug 2008, Reini Urban wrote:
> Will Coleda schrieb:
> > On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
> > > We could thing of symlinking it to runtime/parrot/library
> > > at make languages, so language_interop can be tested.
> >
> > Are symlinks usable where
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
True, there's no perl -MExtUtils::Comma
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
> 2008/8/28 Patrick R. Michaud <[EMAIL PROTECTED]>:
>> On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
>>> Open problem:
>>> For language pbc's a new dir like script_dir or lib_dir/parrot/bin
>>> would be required
2008/8/28 Patrick R. Michaud <[EMAIL PROTECTED]>:
> On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
>> Open problem:
>> For language pbc's a new dir like script_dir or lib_dir/parrot/bin
>> would be required.
>> They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
> Open problem:
> For language pbc's a new dir like script_dir or lib_dir/parrot/bin
> would be required.
> They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
> pbc's are.
> The language group and op shared libs go
2008/8/28 Moritz Lenz <[EMAIL PROTECTED]>:
> Reini Urban wrote:
>> 2008/8/28 Moritz Lenz <[EMAIL PROTECTED]>:
+=head1 DESCRIPTION
+
+Parrot installation mechanisms are more powerful than perl5's.
+MANIFEST contains also the end location, tools/dev/install_files.pl is
drive
Reini Urban wrote:
> 2008/8/28 Moritz Lenz <[EMAIL PROTECTED]>:
>>> +=head1 DESCRIPTION
>>> +
>>> +Parrot installation mechanisms are more powerful than perl5's.
>>> +MANIFEST contains also the end location, tools/dev/install_files.pl is
>>> driven
>>> +by this definition.
>>
>> To me it's not cle
2008/8/28 Moritz Lenz <[EMAIL PROTECTED]>:
>> +=head1 DESCRIPTION
>> +
>> +Parrot installation mechanisms are more powerful than perl5's.
>> +MANIFEST contains also the end location, tools/dev/install_files.pl is
>> driven
>> +by this definition.
>
> To me it's not clear what the "end location" is
Reini Urban wrote:
> +=head1 DESCRIPTION
> +
> +Parrot installation mechanisms are more powerful than perl5's.
> +MANIFEST contains also the end location, tools/dev/install_files.pl is driven
> +by this definition.
To me it's not clear what the "end location" is - care to elaborate?
Moritz
--
Reini Urban wrote:
I have one more draft.
chromatic told me write up such a thing, but it's not finished yet.
It could go to the cygwin070patches branch which is really a
parrot_install branch, but also to HEAD.
This needs some technical review because but I'm still a beginner
in what is possib
till a beginner
in what is possible and what not.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Index: parrot-svn/docs/pdds/draft/pdd30_install.pod
===
--- /dev/null
+++ parrot-svn/docs/pdds/draft/pdd30_install.pod
@@
Will Coleda wrote:
Moritz Lenz wrote:
Reini Urban wrote:
Actually I stumbled over quite a lot of dangling references in the docs.
Including, but not limited to, references to PDDS that still live in
draft/, but are references to be in docs/pdds/ directly.
What should we do with all these?
You
On Mon, Aug 25, 2008 at 1:52 PM, Moritz Lenz
<[EMAIL PROTECTED]> wrote:
> Reini Urban wrote:
>> pdd19_pir.pod references the not-existing docs/imcc/macros.pod.
>>
>> It would be nice if this documents shows up somewhere, as I found nothing
>> more about macros, besides the section in pdd19_pir.pod
Reini Urban wrote:
> pdd19_pir.pod references the not-existing docs/imcc/macros.pod.
>
> It would be nice if this documents shows up somewhere, as I found nothing
> more about macros, besides the section in pdd19_pir.pod
Actually I stumbled over quite a lot of dangling references in the docs.
In
On Mon, Aug 25, 2008 at 11:25 AM, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
> docs/imcc/macros.pod was integrated into pdd19 some time ago. That's all
> information available on macros, currently
>
> kjs
>
> On Mon, Aug 25, 2008 at 10:08 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
>
>> pdd19_pir.pod
docs/imcc/macros.pod was integrated into pdd19 some time ago. That's all
information available on macros, currently
kjs
On Mon, Aug 25, 2008 at 10:08 AM, Reini Urban <[EMAIL PROTECTED]> wrote:
> pdd19_pir.pod references the not-existing docs/imcc/macros.pod.
>
> It would be nice if this document
pdd19_pir.pod references the not-existing docs/imcc/macros.pod.
It would be nice if this documents shows up somewhere, as I found nothing
more about macros, besides the section in pdd19_pir.pod
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
uncatchable, and might as well be called
> > C. that's bad, ya dig?
>
>
> For reference, I am attaching a list of files which, as of the date of
> this post, contain the string 'internal_exception'.
>
> kid51
internal_exception is no more, it's now call
On Tue Jul 29 07:46:08 2008, coke wrote:
>
> Make this ticket one of the children ticket of the META pdd25cx merge
> ticket, we can close it out after the merge removes it.
>
Allison++'s merge removed shift_pmc from src/pmc/exception.pmc, so this
ticket is now rejected.
Andrew,
Do you know how this ticket stands?
Thank you very much.
kid51
On Tue, Jul 29, 2008 at 12:58 AM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
> On Mon Oct 22 10:02:53 2007, pcoch wrote:
>> In src/pmc/exception.pmc:shift_pmc() there is the todo item:
>>
>> PMC *shift_pmc() {
>> /* fprintf(stderr, "don't do that then\n"); XXX */
>> return
On Mon Oct 22 10:02:53 2007, pcoch wrote:
> In src/pmc/exception.pmc:shift_pmc() there is the todo item:
>
> PMC *shift_pmc() {
> /* fprintf(stderr, "don't do that then\n"); XXX */
> return PMCNULL;
> }
>
> Since the error is commented out, do we need this code (and its as
Will Coleda via RT wrote:
On Sun, Jul 27, 2008 at 1:49 AM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
On Thu Dec 06 08:54:35 2007, pcoch wrote:
Many files in the Parrot repository are lacking descriptions within the
pod DESCRIPTION section. This needs to be done. An appropriate
descrip
On Sun, Jul 27, 2008 at 1:49 AM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
> On Thu Dec 06 08:54:35 2007, pcoch wrote:
>> Many files in the Parrot repository are lacking descriptions within the
>> pod DESCRIPTION section. This needs to be done. An appropriate
> description
>> of what the g
On Thu Jul 24 23:21:19 2008, cotto wrote:
>
> I agreee. I ran with a few different runcores and always got 1000 as
> the number (when Parrot ran and I was patient enough to wait for the
> output). It was the same for cgoto, cgp, fast, slow and switch.
> I ran the following with a normal build of
On Thu Dec 06 08:54:35 2007, pcoch wrote:
> Many files in the Parrot repository are lacking descriptions within the
> pod DESCRIPTION section. This needs to be done. An appropriate
description
> of what the given file does is all that is necessary.
r29788 adds a test for this. Unless the test
gcc
---
Flags:
category=install
severity=medium
ack=no
---
make install -C languages DESTDIR=inst
Help generating parrot packages with parrot-languages and self-hosting
languages.
pbc_to_exe $LANG --install creates now [EMAIL PROTECTED]@
self-hosting binaries with dependencies
On Thu May 15 10:24:00 2008, julianalbo wrote:
> On Thu, Oct 25, 2007 at 5:28 PM, via RT Paul Cochrane
> <[EMAIL PROTECTED]> wrote:
>
> > # XXX
> > # in plain functional run-loop result is 999
> > # other run-loops report 998
> > # TODO investigate this after interpreter strtup is done
> > # see a
On Tue Jul 22 23:34:13 2008, [EMAIL PROTECTED] wrote:
>
> This patch contains a fix and a simplification. It should now be
> cross-platform and thread-safe. I'll test on some other *nixes and go
> on from
> there. If nothing else it works fine on Ubuntu/x86.
It also works in FreeBSD 7.0 and Op
and thread-safe. I'll test on some other *nixes and go
> on from
> there. If nothing else it works fine on Ubuntu/x86.
Based on Christoph's instructions in #parrot, I tested this using an MSVC
compiler, with the
following results:
C:\research\parrot>nmake
Microsoft (R) Program M
Christoph Otto via RT wrote:
This version of the patch should dtrt with all versions of strerror_r. It
works on my Debian/x86 box and I'll be testing it on any *nix I can get my
hands on Tuesday. If it works fine there, if someone can test it on windows
and if the patch looks OK, I'll commi
Andy Dougherty via RT wrote:
On Thu, 17 Jul 2008, Christoph Otto via RT wrote:
On Thu Jul 17 15:53:12 2008, julianalbo wrote:
On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
trick. The attached patch (v5) properly fixes the problem on my system.
There shou
On Thu, 17 Jul 2008, Christoph Otto via RT wrote:
> On Thu Jul 17 15:53:12 2008, julianalbo wrote:
> > On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
> > <[EMAIL PROTECTED]> wrote:
> >
> trick. The attached patch (v5) properly fixes the problem on my system.
> There shouldn't be any rem
On Thu, Jul 17, 2008 at 7:44 PM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
> On Thu Jul 17 15:53:12 2008, julianalbo wrote:
>> On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
>> <[EMAIL PROTECTED]> wrote:
>>
>> > With this patch, the new tests still pass on Linux/x86. The patch uses
On Thu Jul 17 15:53:12 2008, julianalbo wrote:
> On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
> <[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,
ay not be considered kosher in this situation.
>
> Can't you use real_exception(interp, NULL, E_SystemError, "%Ss",
> errmsg_pstring); ?
>
> Using internal details of parrot strings must be avoided.
NotFound's solution is correct; that's the way to go here.
-- c
On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
<[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 situatio
On Thu Jul 17 01:17:51 2008, cotto wrote:
> On Wed Apr 23 18:18:00 2008, [EMAIL PROTECTED] wrote:
> > This thread trailed off about 4 months ago. Could we get an update on
> > its status, i.e., whether it should be applied, what OSes it's passing
> > on, etc.
> >
> > Thank you very much.
> > kid5
On Wed Apr 23 18:18:00 2008, [EMAIL PROTECTED] wrote:
> This thread trailed off about 4 months ago. Could we get an update on
> its status, i.e., whether it should be applied, what OSes it's passing
> on, etc.
>
> Thank you very much.
> kid51
The tests passed because the strerror/strerror_r code
On Tue Feb 19 16:19:14 2008, Whiteknight wrote:
> On Mon Oct 22 09:49:02 2007, ptc wrote:
> > In src/pmc/file.pmc there is the todo item:
> >
> > /* XXX Check if we need to deallocate strerror strings */
> >
> > Do this.
>
> According to:
>
> http://www.cplusplus.com/reference/clibrary/cstring/
On Wed Oct 24 14:23:23 2007, pcoch wrote:
> In t/pmc/resizeablebooleanarray.t there is the todo item:
>
> TODO: {
> local $TODO = "this is broken";
>
> pasm_output_is( <<'CODE', <<'OUTPUT', "clone" );
>
> Which is to say, fix cloning in ResizableBooleanArrays or fix the test (or
> both?)
It
# New Ticket Created by Andrew Johnson
# Please include the string: [perl #56632]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56632 >
More details — needless to say the location of the segfault is nowhere near
the bug, w
On Tue Jul 10 06:46:20 2007, pcoch wrote:
> In the file lib/Parrot/Pmc2c.pm there is the todo item (within the
> vtable_decl() sub):
>
> # TODO gen C line comment
>
> Implement this.
The todo is no longer there but the code doesn't generate a #line
directive
The segfault occurs inside clone_key_arg() inside src/inter_call.c (at
line 871), which has the following leading POD description (committed by
chromatic who also committed most of the implementation):
Replaces any src registers by their values (done inside clone). This
needs a test for tailcalls
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #56448]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56448 >
Parrot segfaults when C functions invoke PIR functions that
perform tailca
Rejected TODO item, closing ticket.
On Thursday 19 June 2008 15:09:53 NotFound via RT wrote:
> Another try. Builds and pass tests both with C and C++.
I wish it were cleaner, but I can live with this for now to get C++ building
again.
Thanks, applied as r28602.
-- c
Another try. Builds and pass tests both with C and C++.
Index: src/string.c
===
--- src/string.c (revisión: 28565)
+++ src/string.c (copia de trabajo)
@@ -265,7 +265,7 @@
/* Set up the cstring cache, then load the basic
Forget previous patch, is broken. I'll keep working on it.
This is a cleaner version.
Index: src/string.c
===
--- src/string.c (revisión: 28553)
+++ src/string.c (copia de trabajo)
@@ -265,7 +265,7 @@
/* Set up the cstring cache, then load the basic encodings and charsets */
if (!i
Given the previous comments, and having now some working code that
depends of *not* throwing, I will close this ticket in a few days if no
one objects.
# New Ticket Created by NotFound
# Please include the string: [perl #55960]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55960 >
C++ building is broken because of differences in struct Hash
declarations and usage.
T
Can anyone provide an update as to where we stand on the issues raised
in this ticket? (Last post > 12 months ago.)
Thank you very much.
kid51
On Thu Sep 21 14:38:40 2006, particle wrote:
> parrot's source is littered with internal_exception() calls, the bulk
> (all?) of which should be converted to real_exception() calls.
> internal exceptions are uncatchable, and might as well be called
> C. that's bad, ya dig?
On Sunday 01 June 2008 04:00:34 NotFound wrote:
> readline is not detected when building with C++, because the detection
> and the usage code declares directly the functions used without C
> linkage specification.
>
> This patch fixes the problem, and also do a minor
ll. It needs to be tested with make testj in win
> 32, and for completeness in other jitable platforms, but the variables
> are only used in the i386 jit files. I already tested in linux i386.
Thanks, applied as r28175.
-- c
gives me the goahead, I'll take care of this today or early
> > next week.
>
> +1
>
> -- c
Andrew, this task ever get completed?
NotFound a écrit :
Looking more carefully at this issue, it seems that those variables
and the code that uses them has no real effect. Without it, make test
pass, make testj pass, make hello and make perl6 builds and runs.
This patch cleans all. It needs to be tested with make testj in win
32,
2008/5/26 NotFound <[EMAIL PROTECTED]>:
> Looks like exec_start.c include jit.h and jit_emit.h but doen't use
> it. This patch drops those includes and solve the problem, at least in
> i386.
>
I experiment this patch (on src/exec_start.c).
On Windows, with MinGW, r28042 :
- linking : OK
- but e
@@
int Parrot_exec_run = 0;
-extern char **Parrot_exec_rel_addr;
-extern int Parrot_exec_rel_count;
-
/*
=item C
@@ -90,7 +87,6 @@
Parrot_exec_objfile_t * const obj =
mem_allocate_zeroed_typed(Parrot_exec_objfile_t);
exec_init(obj);
-Parrot_exec_rel_addr
Hearing no opposition, ticket closed.
# New Ticket Created by NotFound
# Please include the string: [perl #55154]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=55154 >
readline is not detected when building with C++, because the detection
and the usage c
1 - 100 of 920 matches
Mail list logo
