octave-maintainers
[Top][All Lists]
Advanced

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

Re: PCRE library requirement


From: bpabbott
Subject: Re: PCRE library requirement
Date: Mon, 31 Jan 2011 20:05:39 +0000 (GMT)

On Jan 31, 2011, at 02:53 PM, Richard Campbell <address@hidden> wrote:

On Jan 31, 2011, at 2:49 PM, Rik wrote:

> bpabbott wrote:
>> On Jan 31, 2011, at 12:55 PM, Rik <address@hidden> wrote:
>>
>>> bpabbott wrote:
>>>> On Jan 31, 2011, at 12:13 PM, Rik <address@hidden
>>> <mailto: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>
>>> <mailto: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
>>
>> It is in ...
>>
>> .../scripts/plot/private/__gnuplot_has_terminal__.m
>>
>> Ben
>>
> The regular _expression_ '\b\w+\b' can be simplified to just '\w+'. However,
> I'd still like Richard to run a test if possible. It would seem from this
> chart (http://www.regular-expressions.info/refflavors.html) that even '\w+'
> is not supported by POSIX regular expressions. It appears that the reason
> this code works on most UNIX boxes without PCRE is that those machines have
> GNU libraries. Thus, not having PCRE is not the equivalent of POSIX, but
> rather equals GNU regular expressions support. So, I would have Richard
> try the following in an Octave built without PCRE.
>
> str = "a ab abc"
> results = regexp (str, '\w+', "match")
>
> If that fails because the actual libraries are truly POSIX compliant then I
> think we should make PCRE a requirement. It is widely available and a
> number of patterns in the code use the very convenient '\s' or '\w'
> patterns rather than character classes.
>
> --Rik

Okay, how do I force it to build without PCRE now that PCRE is on the machine?

Campbell
 
hmmm. I had the impression that the pcre libs were always present. Were the pcre libs not already in /usr/lib?

Ben




reply via email to

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