Re: gplot.txt

[Ben Abbott]

> On Mar 2, 2016, at 3:02 PM, Daniel J Sebald <address@hidden> wrote:
> 
> On 03/02/2016 12:37 PM, Rik wrote:
>> On 03/01/2016 05:12 PM, Ben Abbott wrote:
>>>> On Mar 1, 2016, at 3:07 PM, Ben Abbott<address@hidden>  wrote:
>>>> 
>>>> On Mar 1, 2016, at 15:04, Ben Abbott<address@hidden>  wrote:
>>>> 
>>>>>> On Mar 1, 2016, at 11:02, Rik<address@hidden>  wrote:
>>>>>> 
>>>>>> 3/1/16
>>>>>> 
>>>>>> Ben,
>>>>>> 
>>>>>> Things can get weird when tinkering with the build system, and jwe has 
>>>>>> been
>>>>>> doing a lot recently to improve it.  One way to test things cleanly is to
>>>>>> get rid of all the cruft in your source tree and try a fresh build.
>>>>>> 
>>>>>> I do
>>>>>> 
>>>>>> make maintainer-clean
>>>>>> hg stat -u -i>  unknown.list
>>>>>> #look through unknown.list and delete things you don't need like leftover
>>>>>> .o object files.
>>>>>> bootstrap
>>>>>> configure
>>>>>> make
>>>>>> 
>>>>>> However, a quicker test is to update your source repository and then 
>>>>>> clone
>>>>>> it to a new directory.  That will get you only the files under version
>>>>>> control, and skip all the cruft.
>>>>>> 
>>>>>> cd octave-src
>>>>>> hg pull
>>>>>> hg update
>>>>>> cd ..
>>>>>> hg clone octave-src octave-tmp
>>>>>> cd octave-tmp
>>>>>> bootstrap
>>>>>> configure
>>>>>> make
>>>>>> 
>>>>>> --Rik
>>>>> Good idea. I tried the first approach, but the problems persist. I'll try 
>>>>> a fresh archive next (just to be sure)
>>>>> 
>>>>> Ben
>>>> Oops, I spoke too soon. The gui runs for me now! :-)
>>>> 
>>>> Ben
>>> Building default still runs into trouble in doc/interpreter. The first 
>>> seg-fault occurs for gplot.txt. It tracked the problem to speye().
>>> 
>>> speye(10)
>>> panic: Segmentation fault: 11 -- stopping myself...
>>> attempting to save variables to 'octave-workspace'...
>>> save to 'octave-workspace' complete
>>> Segmentation fault: 11
>> Ugh.  So is the code to create the problem as simple as this?
>> 
>> make
>> ./run-octave
>> speye (10)
>> 
>> If so, I'm going to have to suggest bisecting.  You know the tip is broken,
>> I would try going back to 623fc7d08cc6 as the first possible working
>> revision.  jwe has done a lot in liboctave recently to revamp the
>> factorization classes and there have necessarily been some changes to
>> sparse matrices.
>> 
>> --Rik
> 
> There has been discussion about speeding compilation by avoiding multiple 
> compilation of code in header files.  My general feeling is that re-compiling 
> Octave is too slow for development.  To make a minor change takes on the 
> order of a minute or more to recompile.  This wasn't always the case--maybe a 
> couple years ago this became the norm.
> 
> I wonder, is there some type of optimization now that slows things down?  Is 
> it the way that file dates are checked by the make facility?  Is there a way 
> to have a development build configuration which is faster and a release build 
> that is slower with optimizations?
> 
> Anyway, the slow recompile makes bisecting slow.  As an alternative, I 
> typically first search through the changesets that might have caused the 
> problem.  One can simplify this process by identifying which file it might be 
> where the problem lies, i.e., some file that would have to be altered if it 
> were related to the function.  To do this, go to the mercurial log of the 
> project and navigate to the file of interest using the "browse" link.  From 
> the file, click on the "changeset" link to see the difference from the 
> parent.  If nothing looks problematic, follow the link backward and select 
> the parent.  Click "changeset" again, etc.  Do that until roughly the date 
> you think the problem might have occurred.
> 
> Or, there is a more elegant Mercurial feature that will display the log 
> history for just a particular file.  In this case, try the Sparse.cc file:
> 
> http://hg.savannah.gnu.org/hgweb/octave/log/40de9f8f23a6/liboctave/array/Sparse.cc
> 
> From the list one revision I would think to look at is this changeset:
> 
> http://hg.savannah.gnu.org/hgweb/octave/rev/af8118df8292

I’ve just reverted the changeset …

        hg revert —all -r af8118df8292

… and the problem persists.

Ben