octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave-3.3.55 and Octave-3.3.90 on OSX


From: Richard Campbell
Subject: Re: Octave-3.3.55 and Octave-3.3.90 on OSX
Date: Mon, 31 Jan 2011 12:17:25 -0500

On Jan 31, 2011, at 12:13 PM, Rik 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> 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

I wholeheartedly agree that PCRE (and many other dependencies) should be 
optional if at all possible.

I think there needs to be more periodic testing of builds from scratch on 
vanilla machines, to make sure that the list of requirements and optional 
dependencies is up to date, and the warnings and errors encountered if they 
aren't satisfied are actually informative.

Campbell

reply via email to

[Prev in Thread] Current Thread [Next in Thread]