Re: Octave-3.3.55 and Octave-3.3.90 on OSX

[Rik]

bpabbott wrote:
> On Jan 31, 2011, at 12:13 PM, Rik <address@hidden> wrote:
> 
>> On Jan 31, 2011, at 10:33 AM, Richard Campbell wrote:
>>
>> > >
>> > > On Jan 31, 2011, at 10:17 AM, bpabbott wrote:
>> > >
>> >> >> On Jan 31, 2011, at 09:18 AM, Richard Campbell
>> <address@hidden <mailto:address@hidden>> wrote:
>> >> >>
>> >>> >>>
>> >>> >>> On Jan 31, 2011, at 8:10 AM, Ben Abbott wrote:
>> >>> >>>
>> >>>> >>>> __gnuplot_get_var__ (gcf, "GPVAL_TERMINALS")
>> >>> >>>
>> >>> >>> Looks the same. I should add that I use this gnuplot with the
>> precompiled Octave.app and it works just fine. I built it from source
>> with no options.
>> >>> >>>
>> >>> >>>
>> >>> >>> octave:2> __gnuplot_get_var__ (gcf, "GPVAL_TERMINALS")
>> >>> >>> ans = canvas cgm corel dpu414 dumb dxf eepic emf emtex
>> epslatex epson_180dpi epson_60dpi epson_lx800 fig gpic hp2623A hp2648
>> hp500c hpdj hpgl hpljii hppj imagen latex mf mif mp nec_cp6 okidata
>> pbm pcl5 postscript pslatex pstex pstricks qms regis starc svg
>> tandy_60dpi tek40xx tek410x texdraw tgif tkcanvas tpic unknown vttek
>> x11 xlib xterm
>> >> >>
>> >> >> Ok. I suspect that regexp isn't working correctly. First check
>> the regexp libs. Mine is below.
>> >> >>
>> >> >> octave:1> octave_config_info.REGEX_LIBS
>> >> >> ans = -L/sw/lib -lpcre
>> >> >>
>> >> >> Now, make sure this is where the problem is.
>> >> >>
>> >> >> octave:1> peaks
>> >> >> octave:2> terms = __gnuplot_get_var__ (gcf, "GPVAL_TERMINALS");
>> >> >> octave:3> terms = regexp (terms, '\b\w+\b', "match");
>> >> >> octave:4> disp(char(terms))
>> >> >> aqua
>> >> >> canvas
>> >> >> cgm
>> >> >> corel
>> >> >> dpu414
>> >> >> dumb
>> >> >> dxf
>> >> >> eepic
>> >> >> emf
>> >> >> emtex
>> >> >> epslatex
>> >> >> epson_180dpi
>> >> >> epson_60dpi
>> >> >> epson_lx800
>> >> >> fig
>> >> >> gif
>> >> >> gnugraph
>> >> >> gpic
>> >> >> hp2623A
>> >> >> hp2648
>> >> >> hp500c
>> >> >> hpdj
>> >> >> hpgl
>> >> >> hpljii
>> >> >> hppj
>> >> >> imagen
>> >> >> jpeg
>> >> >> latex
>> >> >> lua
>> >> >> mf
>> >> >> mif
>> >> >> mp
>> >> >> nec_cp6
>> >> >> okidata
>> >> >> pbm
>> >> >> pcl5
>> >> >> pdf
>> >> >> pdfcairo
>> >> >> png
>> >> >> pngcairo
>> >> >> postscript
>> >> >> pslatex
>> >> >> pstex
>> >> >> pstricks
>> >> >> qms
>> >> >> regis
>> >> >> rgip
>> >> >> starc
>> >> >> svg
>> >> >> tandy_60dpi
>> >> >> tek40xx
>> >> >> tek410x
>> >> >> texdraw
>> >> >> tgif
>> >> >>
>> >> >> Assuming that the regexp command does not give the proper result ...
>> >> >>
>> >> >> In /usr/lib, I see the following pcre libs.
>> >> >>
>> >> >> libpcre.0.0.1.dylib
>> >> >> libpcre.0.dylib
>> >> >> libpcre.dylib
>> >> >> libpcreposix.0.0.0.dylib
>> >> >> libpcreposix.0.dylib
>> >> >> libpcreposix.dylib
>> >> >>
>> >> >> I'm guessing you are configured with libpcre.dylib. Try
>> switching to libpcreposix.dylib.
>> >> >>
>> >> >> Ben
>> >> >>
>> >> >>
>> > >
>> > > It works! So PCRE needs to be listed as 'required', apparently.
>> 1/31/11
>>
>> Octave could move this way and just require PCRE, but I would be
>> interested
>> to know where the actual problem call to regexp lies. Earlier, I did a
>> fair bit of work converting the calls to regexp in the code to be both
>> POSIX and PCRE compliant. It might be that just a simple tweak is
>> required. For example, the regexp call that I saw briefly in one of the
>> e-mails was '/\b\w+\b/' which is in PCRE syntax. The equivalent in POSIX
>> would be '/\<\w+\</'.
>>
>> --Rik
>  
> Rik,
> 
> Will you be submitting a changeset?

I can if I know where the problem lies.  What file did you find the "bad"
regexp in?

I did do a grep through the entire codebase before, but that is a slow way
to find the problem.

--Rik