On Sun Jun 08 19:12:06 2008, coke wrote:
>
> I take this to mean `perl Configure.pl --parrot_is_shared`.
>
Okay. I just ran that command, then ran 'make' and 'make test'.
Everything passed. There were no significant differences in the output
between this run and my last without that option.
On Sun Jun 08 17:57:56 2008, [EMAIL PROTECTED] wrote:
> Patch applied in r28188. Will resolve ticket if no one complains within
> 1-2 days. Thanks, Andy.
I had no problems running the two existing step tests for this step via
'prove -v t/steps/auto_perldoc*.t.
But I got this warning when runnin
On Sun, Jun 8, 2008 at 9:47 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Thu Aug 03 11:58:02 2006, chip wrote:
>> Extern functions and variables must have names that begin with C.
>
>
> Do we indeed have any extern functions or variables whose names do not
> begin with C? How would one
On Sun, Jun 8, 2008 at 9:28 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> On Fri Jul 29 23:36:12 2005, [EMAIL PROTECTED] wrote:
>
>> ---
>> After running make shared, make test fails nearly all of the t/src
>> tests with errors like the following:
>> # Failed test (t/src/exit.t at line 2
On Sunday 21 October 2007 08:24:40 Bram Geron wrote:
> I think attached patch clarifies parameter passing a little.
Agreed. I applied the comment-only portions as r28190.
-- c
On Thu Aug 03 11:58:02 2006, chip wrote:
> Extern functions and variables must have names that begin with C.
Do we indeed have any extern functions or variables whose names do not
begin with C? How would one determine this? Could this be
converted into a coding standards test?
kid51
On Sun Feb 24 17:38:36 2008, [EMAIL PROTECTED] wrote:
> Somewhat apropos the discussion in this old ticket, tonight I noticed
> the following code in config/inter/progs.pm:
>
>
> sub cc_run {
Correction: cc_run() is defined in lib/Parrot/Configure/Compiler.pm.
On Fri Jul 29 23:36:12 2005, [EMAIL PROTECTED] wrote:
> ---
> After running make shared, make test fails nearly all of the t/src
> tests with errors like the following:
> # Failed test (t/src/exit.t at line 21)
> # got: './t/src/exit_1: error while loading shared libraries:
I don't s
On Fri Apr 27 19:39:01 2007, [EMAIL PROTECTED] wrote:
>
> Here's a bit of information about tools/dev/*.pl: last revision for
> each script
>
Here are the results of the same search run today:
svn status -v tools/dev/*.pl | tr -s ' ' | sort -t ' ' -k 7 -k 12 | cut
-d ' ' -f 3,5
18810 tools/d
On Tue Mar 18 12:27:52 2008, [EMAIL PROTECTED] wrote:
But I
> think this ticket should stay open, as there are still more codingstd
> tests to convert, and I haven't even looked at t/distro yet.
>
> Mark
>
Mark:
What with our Parrot buildfest workshop at YAPC coming up within a
fortnight, this
Patch applied in r28188. Will resolve ticket if no one complains within
1-2 days. Thanks, Andy.
James E Keenan wrote:
A couple of points about YAPC:
I've started a page on the YAPC Conference Wiki to provide YAPC
attendees with information about our Parrot/Rakudo Buildfest.
http://conferences.mongueurs.net/yn2008/wiki?node=Parrot%20and%20Perl%206%20Workshop
Those of us who are organ
On 2008 Jun 6, at 23:53, Vasily Chekalkin wrote:
jerry gay wrote:
would you reformat this in universal diff format please? my patch
program doesn't speak git.
Strange... It is 'universal diff' format. Can be applied with
'patch -p1 < eval.diff' in top-level parrot directory. Or with
'patch -
2008/6/5 chromatic <[EMAIL PROTECTED]>:
>
> Look at get_length() in tools/build/c2str.pl. If that's the problem (and
> it
> looks like it is), that's the place to fix it.
>
The length computation (in c2str.pl) is correct.
There are no missing make dependence.
But looks like a missing make depend
Vasily Chekalkin wrote:
This is wrong patch. eval() shouldn't throws any exceptions.
Correct patch for 'eval()' and Test.pm attached.
As Mr Lenz wrote with respect to eval exceptions and this patch:
Are there any exceptions that are not caught by eval?
Currently rakudo seems to catch every
On Sunday 21 October 2007 08:24:40 Bram Geron wrote:
> I think attached patch clarifies parameter passing a little.
>
> Non-comment changes:
> * enum call_state_mode becomes typedef'd call_state_mode
> * call_state_item.mode becomes type call_state_mode instead of int
> * call_state_item.sig bec
On Sunday 04 November 2007 06:00:01 Ronald Blaschke wrote:
> Parrot currently uses indirect DLL linkage, which means that exported
> data, including PMCNULL, used by PMC_IS_NULL, can not be accessed.
> Attached patch introduces a function PMC_is_null which should be used
> instead.
> An alte
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 cleaning in the
> set_readline
18 matches
Mail list logo
