On Wednesday 23 January 2008 20:10:48 Bob Rogers wrote:
>From: "Will Coleda via RT" <[EMAIL PROTECTED]>
>My apologies to your sanity, but with r25175 on osx/intel, this prints:
>
>hey, it's working.
>done.
>
> Phooey. Thanks for trying, though. (Did you try it after renaming
> o
On Wed Feb 14 09:09:14 2007, coke wrote:
> Trying to build with GMP support on OSX intel. I have libgmp in
> /opt/local/bin/
>
> if I run:
>
> CC="ccache gcc-4.0"
> CX="ccache g++-4.0"
> perl Configure.pl --cc="$CC" --cxx="$CX" --link="$CX" --ld="$CX"
> --ccflags="-L/opt/local/lib -I/opt/local/i
From: "Will Coleda via RT" <[EMAIL PROTECTED]>
Date: Wed, 23 Jan 2008 18:15:43 -0800
On Sun Jan 20 19:11:26 2008, rgrjr wrote:
>The attached tarball has a test case in which one file
> (gc-debug-test.pir) loads another (structures.pir), where the second has
> a :load sub that
On Fri Jan 11 13:46:02 2008, [EMAIL PROTECTED] wrote:
> On Wed Feb 14 16:38:10 2007, coke wrote:
> > Turns out the bug isn't quite what I described. You need to use --
> > linkflags to specify for the linker: when doing this, the library is
> > correctly found in a full run of Configure.pl
> >
On Sun Jan 20 19:11:26 2008, rgrjr wrote:
>The attached tarball has a test case in which one file
> (gc-debug-test.pir) loads another (structures.pir), where the second has
> a :load sub that calls a sub defined in the first file. The bug is
> that, under what must be fairly arcane conditions,
On Mon Jul 24 13:16:41 2006, chip wrote:
> On Mon, Jul 17, 2006 at 07:17:09PM +0200, Leopold Toetsch wrote:
> > A PMC method definition, e.g.
> > METHOD void load_library(PMC* ar, PMC* h) {...}
> > is processed by the PMC compiler, which generates a signature:
> > "vOPP" # SELF being the impl
On Sun Jun 03 20:18:28 2007, [EMAIL PROTECTED] wrote:
> On Thursday 19 April 2007 19:45:29 Ryan Hinton wrote:
>
> > Here is my machine info:
> > FreeBSD 5.3-STABLE i386
> >
> > Here is the complete report.
>
> Thanks for the report. How does a current checkout fare?
Checking our smoke server, l
Am Donnerstag, 24. Januar 2008 00:18 schrieb Leopold Toetsch:
> a) help the register allocator with the 'tmp' reallocation (the register
> allocator is currently very dumb)
The answer was probably a bit terse, more info is here:
In src/pic_jit.c are some tests, if a subroutine (plus it's call/ret
Am Donnerstag, 24. Januar 2008 00:03 schrieb chromatic:
> On Wednesday 23 January 2008 14:35:22 [EMAIL PROTECTED] wrote:
> > Author: leo
> > Date: Wed Jan 23 14:35:19 2008
> > New Revision: 25177
> >
> > Modified:
> >trunk/examples/shootout/recursive.pir
> >
> > Log:
> > speed up shootout/recur
Hi,
with a few modifications (r25177, r25178) the speed of that test is again at
parrot's peak (it was at some 4m14s before):
23:43 <@leo> $ time ./parrot -Oc -Cj examples/shootout/recursive.pir 11
23:43 <@leo> real0m2.307s
23:43 <@leo> $ time ./recursive 11 # gcc version 4.1.0 w/ -O3
On Wednesday 23 January 2008 14:35:22 [EMAIL PROTECTED] wrote:
> Author: leo
> Date: Wed Jan 23 14:35:19 2008
> New Revision: 25177
>
> Modified:
>trunk/examples/shootout/recursive.pir
>
> Log:
> speed up shootout/recursive.pir by x100
I can see that this does improve performance, but I can't
On Wed, 23 Jan 2008, chromatic wrote:
> On Wednesday 23 January 2008 10:20:03 Andy Dougherty wrote:
>
> > my suggested reordering is unlikely to fix this. ?The undefined
> > symbol '_Parrot_set_executable_name' is referenced in pbc_to_exe.o, so
> > the linker should have been looking for it alrea
On Wednesday 23 January 2008 10:20:03 Andy Dougherty wrote:
> my suggested reordering is unlikely to fix this. The undefined
> symbol '_Parrot_set_executable_name' is referenced in pbc_to_exe.o, so
> the linker should have been looking for it already when it encountered
> -lparrot. This indeed l
On Wed, 23 Jan 2008, Andy Dougherty wrote:
> On Wed, 23 Jan 2008, Allison Randal via RT wrote:
>
> Summary (edited for clarity)
>
> > > c++ -o pbc_to_exe pbc_to_exe.o -Lblib/lib -lparrot src/parrot_config.o
>
> Fails. But adding $O_FILES to the end works:
>
> >> c++ -o pbc_to_exe pbc_to_exe.o
On Tue, 22 Jan 2008, jerry gay wrote:
> it's rather annoying that some variables in Parrot::Config::Generated
> contain make-related variable expansion values, and others contain
> literal values, and that it's impossible to tell by the variable name
> which type the value may be. however, changin
On Jan 23, 2008 8:05 AM, <[EMAIL PROTECTED]> wrote:
> + So if you see the integer stream C<0x69 0x30F>, it
> +needs to be replaced by C<0x30F>.
Typo - that second 0x30F should be 0x209.
--
Mark J. Reed <[EMAIL PROTECTED]>
Author: simon
Date: Wed Jan 23 05:05:28 2008
New Revision: 25172
Modified:
trunk/docs/pdds/draft/pdd28_character_sets.pod
Log:
[docs][pdds] A little bit more. Implementation section next week.
Modified: trunk/docs/pdds/draft/pdd28_character_sets.pod
==
On Wed, 23 Jan 2008, Allison Randal via RT wrote:
Summary (edited for clarity)
> > c++ -o pbc_to_exe pbc_to_exe.o -Lblib/lib -lparrot src/parrot_config.o
Fails. But adding $O_FILES to the end works:
>> c++ -o pbc_to_exe pbc_to_exe.o -Lblib/lib -lparrot src/parrot_config.o
>> $(O_FILES)
This
It also works as a shared binary if I append the following to the
compile line (pretty much exactly the contents of $O_FILES in the Makefile):
c++ -o pbc_to_exe pbc_to_exe.o -L/usr/local/lib -L/opt/local/lib
-L/sw/lib -L/sw/lib -L/opt/local/lib -L/sw/lib
-L/Users/allison/projects/svn/parrot/blib/
On 23/01/2008, Allison Randal via RT <[EMAIL PROTECTED]> wrote:
> On Tue Jan 22 15:38:11 2008, [EMAIL PROTECTED] wrote:
> >
> > Are you building a static or a shared binary? Did this problem only
> > show up after Coke switched the default to shared?
>
> Shared. I don't know the exact timing of th
20 matches
Mail list logo
