search for: ratehr

...ure.ac: and that aclocal.m4 was recently regenerated (using aclocal). automake: no `Makefile.am' found for any configure output then the following runs OK autoconf but running configure gives the same BLAS error. But I'm farily sure one shouldn't run to see what's wrong with BLAS,ratehr it's just the configure options not being read properly. The AM_INIT_AUTOMAKE issue definitely seems important. Is there anything I'm missing? Cheers and thanks in advance! [[alternative HTML version deleted]]

Greetings Folks, When R code (as entered or read from a courced file) is executed, is it interpreted from the input form every time having once been read in, or do subsequent invocations use an "intermediate" (pre-interpreted) form? Or, putting it another way, is the execution of R code faster second time time round (and later) because the pre-interpretation has already been done once

...regenerated (using aclocal). > automake: no `Makefile.am' found for any configure output > > then the following runs OK > autoconf > > but running configure gives the same BLAS error. > > But I'm farily sure one shouldn't run to see what's wrong with BLAS,ratehr > it's just the configure options not being read properly. The > AM_INIT_AUTOMAKE > issue definitely seems important. > > Is there anything I'm missing? > > Cheers and thanks in advance! > > [[alternative HTML version deleted]] > > _____________________...

...are they? >> > I am referring to the "new DIE" in DwarfDebug.cpp, and saying that we > should instead call getOrCreate function on a CU. > Perhaps I'll need to go back and check your patch, but generally, I tend to think we should be calling into a CU to build anything ratehr than doing it 'raw' in DwarfDebug.cpp. > > >> >> >>> How much effort is required to make sure these assumptions are true? We >>> also should have the corresponding assertions to make sure the assumptions >>> are not violated. >>> >&...

...; I am referring to the "new DIE" in DwarfDebug.cpp, and saying that we >> should instead call getOrCreate function on a CU. >> > > Perhaps I'll need to go back and check your patch, but generally, I tend > to think we should be calling into a CU to build anything ratehr than doing > it 'raw' in DwarfDebug.cpp. > It is not related to my patch, we are directly constructing DIEs in DwarfDebug in the current code base. Thanks, Manman > > >> >> >>> >>> >>>> How much effort is required to make sure these...

...the "new DIE" in DwarfDebug.cpp, and saying that we >>> should instead call getOrCreate function on a CU. >>> >> >> Perhaps I'll need to go back and check your patch, but generally, I tend >> to think we should be calling into a CU to build anything ratehr than doing >> it 'raw' in DwarfDebug.cpp. >> > > It is not related to my patch, we are directly constructing DIEs in > DwarfDebug in the current code base. > > Thanks, > Manman > > >> >> >>> >>> >>>> >>>&...

...ot; in DwarfDebug.cpp, and saying that we >>>> should instead call getOrCreate function on a CU. >>>> >>> >>> Perhaps I'll need to go back and check your patch, but generally, I tend >>> to think we should be calling into a CU to build anything ratehr than doing >>> it 'raw' in DwarfDebug.cpp. >>> >> >> It is not related to my patch, we are directly constructing DIEs in >> DwarfDebug in the current code base. >> >> Thanks, >> Manman >> >> >>> >>> >>...

...p, and saying that we >>>>> should instead call getOrCreate function on a CU. >>>>> >>>> >>>> Perhaps I'll need to go back and check your patch, but generally, I >>>> tend to think we should be calling into a CU to build anything ratehr than >>>> doing it 'raw' in DwarfDebug.cpp. >>>> >>> >>> It is not related to my patch, we are directly constructing DIEs in >>> DwarfDebug in the current code base. >>> >>> Thanks, >>> Manman >>> >&gt...

On Tue, Oct 15, 2013 at 5:22 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 4:59 PM, Manman Ren <manman.ren at gmail.com> wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 2:24 PM, David Blaikie <dblaikie at gmail.com>wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at

...p, and saying that we >>>>> should instead call getOrCreate function on a CU. >>>>> >>>> >>>> Perhaps I'll need to go back and check your patch, but generally, I >>>> tend to think we should be calling into a CU to build anything ratehr than >>>> doing it 'raw' in DwarfDebug.cpp. >>>> >>> >>> It is not related to my patch, we are directly constructing DIEs in >>> DwarfDebug in the current code base. >>> >>> Thanks, >>> Manman >>> >&gt...

On Tue, Oct 15, 2013 at 4:59 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Tue, Oct 15, 2013 at 2:24 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> >> On Tue, Oct 15, 2013 at 1:56 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >>> >>> >>> >>> On Tue, Oct 15, 2013 at