maxima-discuss

[Maxima-discuss] Reading data from header

[André F. <a.f...@gm...>]

I have been using Maxima now for a few months and I am getting comfortable
with it. But I have problem now with some calculations I have to do. I am
reading in data from hundreds of external files. Each file has a header
that looks like this

/* RGBident=000000 */
/* Press=1.018119e+00 */
/* Density=1.000000e+00 */
/* AutoCalib=0 */
/* Temp=2.228929e+02 */
/* Log=1515870810 */
/* Length=1.000000e+01 */
/* Name=(null) */
/* File: absorbed_pre.csv */

currently I ignore the header completely by using this script here

/* [wxMaxima: subsect start ]
Data files with comments at the top
   [wxMaxima: subsect end   ] */
/* [wxMaxima: input   start ] */
intNumberOfReffiles : length(DataRefFile);
/* [wxMaxima: input   end   ] */
/* [wxMaxima: input   start ] */
read_commented_dataFile(fileName) := block([NumberofComments, SPEData1,
SPEDataLength1, h2, i, n, log10absorption],
 errcatch(
        kill(h2),
        SPEData1 : read_nested_list( fileName),
        SPEDataLength1 : length(SPEData1),
        n : 1,
       for i:1 while  ((numberp(SPEData1[n][1]) = false) and (n <
SPEDataLength1)) do (n : n + 1),
        NumberofComments : n - 1,
     SPEDataLength1 : SPEDataLength1- NumberofComments,
        print("Comment lines: ", NumberofComments),
        h2[x, y] := if y = 2 then SPEData1[x + NumberofComments][2] else
SPEData1[x + NumberofComments][1],
        log10absorption : genmatrix (h2, SPEDataLength1, 2),
        kill(h2),
        log10absorption)[1])$
/* [wxMaxima: input   end   ] */
/* [wxMaxima: input   start ] */
i : 1;
/* [wxMaxima: input   end   ] */
/* [wxMaxima: input   start ] */
for n : 1 thru intNumberOfReffiles do
(
   if errcatch( Data[i] : read_commented_dataFile(concat(workDir,
DataRefFile[n]))) = []
      then
(
     print("ERROR in: ", DataRefFile[n])
   )
      else
     (
   DataFile[i] : DataFile[n],
        print(n, " of ", intNumberOfReffiles, ": ", DataFile[i], " - ",
length(Data[i]), " First cell:", Data[i][1]),
   NumberOfReffiles : i,
        i : i+1
)
 )$
/* [wxMaxima: input   end   ] */
/* [wxMaxima: input   start ] */
NumberOfReffiles;
/* [wxMaxima: input   end   ] */

but now I need to read the numbers in the header into Maxima for
calculation purposes. Any suggestions?

Re: [Maxima-discuss] Reading data from header

[Robert D. <rob...@gm...>]

On 2015-10-16, André Fettouhi <a.f...@gm...> wrote:

> /* RGBident=000000 */
> /* Press=1.018119e+00 */
> /* Density=1.000000e+00 */
> /* AutoCalib=0 */
> /* Temp=2.228929e+02 */
> /* Log=1515870810 */
> /* Length=1.000000e+01 */
> /* Name=(null) */
> /* File: absorbed_pre.csv */

Since these are comments, you'll have to parse the content yourself.
My advice is to open a stream for reading via 'openr' and read the
lines of the header via 'readline', then get all the rest of the data
via read_nested_list(S) where S is the stream. 

To extract the foo=bar stuff, you can call 'substring' and then split
the result via 'split'. You can parse numbers via 'parse_string'
although I guess you'll need to assign ibase:16 before parsing RGBident.

There is a regular expression package in Maxima, although it is not as
powerful as the ones in other languages, and it is Lisp-only. But I'll
explain how you could use it for this if you're interested.

best

Robert Dodier

Re: [Maxima-discuss] Reading data from header

[Robert D. <rob...@gm...>]

On Fri, Oct 16, 2015 at 10:02 AM, André Fettouhi <a.f...@gm...> wrote:

> Thanks for the suggestion. I'll take a crack at it. I would like to hear
> about the regular expression package you mentioned.

Andre, I've take the liberty of cc'ing the mailing list on this reply.
The regex functions are in the package :maxima-nregex, and
the source code is src/nregex.lisp. It can handle character
classes, starting and ending anchors, the quantifiers * + and ?,
and capturing groups; there might or might not be other features.
This is obviously much more limited than, say, Perl or Python,
but it is enough for the task at hand.

Create a matching function like this:

:lisp (setq foo (coerce (maxima-nregex::regex-compile "...") 'function))

where "..." is the regex pattern -- something like "/\\* *([^ ]+)
*[:=] *([^ ]+) *\\*/"
in this case.

Call FOO to look for a match:

:lisp (funcall foo "/* something=whatever */")

which returns T for a hit or NIL for a miss. If T, then look at

:lisp maxima-nregex::*regex-groupings*

to see how many groups were captured and

:lisp maxima-nregex::*regex-groups*

to see the groups. Group 0 is the whole thing. In each group
e.g. (m n), the first character in the group is the m'th character
and the first character beyond the end is the n'th character,
so there are n - m characters in the group.

Here's an initial attempt to parse header lines. Note that
I omitted the code to actually parse strings into numbers --
you can call parse_string(s) for floats and decimal integers
but you'll want block([ibase:16], parse_string(s)) for hex.
Also, note that the regex cannot capture a right-hand side
which contains a space -- you'll have to adjust the regex
if you want to capture spaces. Also I assume you can get
the list of header lines via readline.

(%i1) display2d : false $
(%i2) load ("parse_header.lisp");
(%o2) "parse_header.lisp"
(%i3) l : ["/* foo=123 */", "/* baz=blurf */", "/* quux: sdsdkkds.dfk */"] $
(%i4) parse_header (l);
(%o4) ["foo" = "123","baz" = "blurf","quux" = "sdsdkkds.dfk"]

Hope this helps,

Robert Dodier

PS.
;; copyright 2015 by Robert Dodier
;; I release this work under terms of the GNU General Public License

(defvar foo)
(setq foo (coerce
            (maxima-nregex::regex-compile
              "/\\* *([^ ]+) *[:=] *([^ ]+) *\\*/")
            'function))

;; parse each element of LINES to a Maxima expression "foo" = "bar";
;; assume LINES is a Maxima list, and return a Maxima list.
(defun $parse_header (lines)
  (cons '(mlist)
        (mapcar #'(lambda (l)
                    (if (funcall foo l)
                      (list '(mequal)
                            (group-substring l 1)
                            (group-substring l 2))))
                (rest lines))))

(defun group-substring (l i)
  (let ((group (aref maxima-nregex::*regex-groups* i)))
    (subseq l (first group) (second group))))

Re: [Maxima-discuss] Reading data from header

[Volker v. N. <vol...@gm...>]

In share/stringproc there is an alternative regex parser (portable regex
parser by Dorai Sitaram) with an interface at Maxima level.

It works nicely but it appears to be quite slow.

The header in sregexp.lisp contains the Maxima functions and simple
examples. Meanwhile the manual by Dorai Sitaram moved to

http://ds26gte.github.io/pregexp/index.html

In the following I use Robert's regex. The list returned by regex_match
contains the wanted capturing groups.

(%i1) load(sregex);
(%o1)    /usr/local/share/maxima/5.37post/share/stringproc/sregex.lisp
(%i2) stringdisp: true$

(%i3) input: openr("data.txt");
(%o3)                      #<input stream data.txt>
(%i4) line: readline(input);
(%o4)                       "/* RGBident=000000 */"
(%i5) regex: "/\\* *([^ ]+) *[:=] *([^ ]+) *\\*/"$

(%i6) match: regex_match(regex, line);
(%o6)           ["/* RGBident=000000 */", "RGBident", "000000"]
(%i7) regex_match(regex, "other stuff");
(%o7)                                false
(%i8) close(input);
(%o8)                                true

When parsing RGBident with ibase:16 the parser wants hex-numbers
starting with an alphabet-character to be zero-prefixed,
e.g. "/* RGBident=ff9933 */".

(%i9) match[3]: "ff9933";
(%o9)                              "ff9933"
(%i10) ibase:16.$

(%i11) eval_string(sconcat(match[2],":","0",match[3]));
(%o11)                             16750899
(%i12) RGBident;
(%o12)                             16750899
(%i13) obase:16.$

(%i0E) RGBident;
(%o0E)                              0FF9933

Volker van Nek

Am 18.10.2015 um 06:28 schrieb Robert Dodier:
> On Fri, Oct 16, 2015 at 10:02 AM, André Fettouhi <a.f...@gm...> wrote:
> 
>> Thanks for the suggestion. I'll take a crack at it. I would like to hear
>> about the regular expression package you mentioned.
> 
> Andre, I've take the liberty of cc'ing the mailing list on this reply.
> The regex functions are in the package :maxima-nregex, and
> the source code is src/nregex.lisp. It can handle character
> classes, starting and ending anchors, the quantifiers * + and ?,
> and capturing groups; there might or might not be other features.
> This is obviously much more limited than, say, Perl or Python,
> but it is enough for the task at hand.
> 
> Create a matching function like this:
> 
> :lisp (setq foo (coerce (maxima-nregex::regex-compile "...") 'function))
> 
> where "..." is the regex pattern -- something like "/\\* *([^ ]+)
> *[:=] *([^ ]+) *\\*/"
> in this case.
> 
> Call FOO to look for a match:
> 
> :lisp (funcall foo "/* something=whatever */")
> 
> which returns T for a hit or NIL for a miss. If T, then look at
> 
> :lisp maxima-nregex::*regex-groupings*
> 
> to see how many groups were captured and
> 
> :lisp maxima-nregex::*regex-groups*
> 
> to see the groups. Group 0 is the whole thing. In each group
> e.g. (m n), the first character in the group is the m'th character
> and the first character beyond the end is the n'th character,
> so there are n - m characters in the group.
> 
> Here's an initial attempt to parse header lines. Note that
> I omitted the code to actually parse strings into numbers --
> you can call parse_string(s) for floats and decimal integers
> but you'll want block([ibase:16], parse_string(s)) for hex.
> Also, note that the regex cannot capture a right-hand side
> which contains a space -- you'll have to adjust the regex
> if you want to capture spaces. Also I assume you can get
> the list of header lines via readline.
> 
> (%i1) display2d : false $
> (%i2) load ("parse_header.lisp");
> (%o2) "parse_header.lisp"
> (%i3) l : ["/* foo=123 */", "/* baz=blurf */", "/* quux: sdsdkkds.dfk */"] $
> (%i4) parse_header (l);
> (%o4) ["foo" = "123","baz" = "blurf","quux" = "sdsdkkds.dfk"]
> 
> Hope this helps,
> 
> Robert Dodier
> 
> PS.
> ;; copyright 2015 by Robert Dodier
> ;; I release this work under terms of the GNU General Public License
> 
> (defvar foo)
> (setq foo (coerce
>             (maxima-nregex::regex-compile
>               "/\\* *([^ ]+) *[:=] *([^ ]+) *\\*/")
>             'function))
> 
> ;; parse each element of LINES to a Maxima expression "foo" = "bar";
> ;; assume LINES is a Maxima list, and return a Maxima list.
> (defun $parse_header (lines)
>   (cons '(mlist)
>         (mapcar #'(lambda (l)
>                     (if (funcall foo l)
>                       (list '(mequal)
>                             (group-substring l 1)
>                             (group-substring l 2))))
>                 (rest lines))))
> 
> (defun group-substring (l i)
>   (let ((group (aref maxima-nregex::*regex-groups* i)))
>     (subseq l (first group) (second group))))
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> 

[Maxima-discuss] regex packages, was: Reading data from header

[Robert D. <rob...@gm...>]

On 2015-10-18, Volker van Nek <vol...@gm...> wrote:

> In share/stringproc there is an alternative regex parser (portable regex
> parser by Dorai Sitaram) with an interface at Maxima level.
>
> It works nicely but it appears to be quite slow.

Thanks for the reminder, I had forgotten about that. I suspect that
sregex is strictly more powerful than nregex; I'd be surprised if nregex
were any faster, but that is not a key point. Also it's helpful that
there is a Maxima interface for sregex. Given all that, I'm in favor of
moving sregex into src and nuking nregex. There are a few calls to
nregex in src, but those would be easily replaced by sregex, I believe.

> When parsing RGBident with ibase:16 the parser wants hex-numbers
> starting with an alphabet-character to be zero-prefixed,

Yes, good point. I forgot about that too.

best,

Robert Dodier

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

When I looked at this yesterday I noticed that Dorai Sitaram had fully
revised the portable regex parser which is the file pregexp.lisp in
share/stringproc.

First I would like to replace the old pregexp.lisp by the new one and to
do some tests and to write the documentation for the Maxima interface
functions which are in share/stringproc/sregex.lisp.

Thereafter I will see how I can replace calls to nregex in src. Maybe I
need help at this point to identify and understand all calls to nregex.

The performance of pregexp.lisp will surely improve when it is compiled
in src.

I will keep you informed.

Volker van Nek

Am 18.10.2015 um 23:10 schrieb Robert Dodier:
> On 2015-10-18, Volker van Nek <vol...@gm...> wrote:
> 
>> In share/stringproc there is an alternative regex parser (portable regex
>> parser by Dorai Sitaram) with an interface at Maxima level.
>>
>> It works nicely but it appears to be quite slow.
> 
> Thanks for the reminder, I had forgotten about that. I suspect that
> sregex is strictly more powerful than nregex; I'd be surprised if nregex
> were any faster, but that is not a key point. Also it's helpful that
> there is a Maxima interface for sregex. Given all that, I'm in favor of
> moving sregex into src and nuking nregex. There are a few calls to
> nregex in src, but those would be easily replaced by sregex, I believe.
> 
>> When parsing RGBident with ibase:16 the parser wants hex-numbers
>> starting with an alphabet-character to be zero-prefixed,
> 
> Yes, good point. I forgot about that too.
> 
> best,
> 
> Robert Dodier
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> 

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Michel T. <ta...@lp...>]

Le 18/10/2015 23:10, Robert Dodier a écrit :
>> In share/stringproc there is an alternative regex parser (portable regex
>> >parser by Dorai Sitaram) with an interface at Maxima level.
>> >
>> >It works nicely but it appears to be quite slow.
> Thanks for the reminder, I had forgotten about that. I suspect that
> sregex is strictly more powerful than nregex; I'd be surprised if nregex
> were any faster, but that is not a key point. Also it's helpful that
> there is a Maxima interface for sregex. Given all that, I'm in favor of
> moving sregex into src and nuking nregex. There are a few calls to
> nregex in src, but those would be easily replaced by sregex, I believe.
>

Well, i have looked a little bit at the programes nregex, pregexp, and 
the way nregex is used in maxima. Obviously pregexp is a complete regex
parser, covering more or less the perl regexp syntax, while nregex is
a very basic regex parser covering the standard new regex syntax as in
grep -E except that modern stuff [:alnum:] etc. is not supported. Of 
course only 256 characters alphabets are supported. There are some 
extensions as in emacs regexps, like \w matching words, \b matching 
boundaries, etc. (and their opposites \W, \B etc.). The repeating 
patterns {n,m} are not supported, i am not even sure the alternative 
patterns patt1|patt2 are. But thanks to all these shortcomings nregex
is very small and can use a clever trick to speed up character classes
matching. Basically when encountering [...] it builds a bitstring of 
length 256 having ones at each matching position (with special cases for
\w etc.) or inverted if one has [^...] and this can be very fast to 
match on something. On the contrary pregexp does straightforward 
comparisons. Hence one may expect considerable speed difference between
them. In the way in which regexp is used in maxima (in cl-info.lisp for 
finding stuff and in in commac.lisp for stripping a string of trailing 
zeroes) the speed difference could cause problems.


-- 
Michel Talon

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

Thank you, Michel.

These are very helpful informations.

Volker van Nek

2015-10-19 10:31 GMT+02:00 Michel Talon <ta...@lp...>:

> Le 18/10/2015 23:10, Robert Dodier a écrit :
> >> In share/stringproc there is an alternative regex parser (portable regex
> >> >parser by Dorai Sitaram) with an interface at Maxima level.
> >> >
> >> >It works nicely but it appears to be quite slow.
> > Thanks for the reminder, I had forgotten about that. I suspect that
> > sregex is strictly more powerful than nregex; I'd be surprised if nregex
> > were any faster, but that is not a key point. Also it's helpful that
> > there is a Maxima interface for sregex. Given all that, I'm in favor of
> > moving sregex into src and nuking nregex. There are a few calls to
> > nregex in src, but those would be easily replaced by sregex, I believe.
> >
>
> Well, i have looked a little bit at the programes nregex, pregexp, and
> the way nregex is used in maxima. Obviously pregexp is a complete regex
> parser, covering more or less the perl regexp syntax, while nregex is
> a very basic regex parser covering the standard new regex syntax as in
> grep -E except that modern stuff [:alnum:] etc. is not supported. Of
> course only 256 characters alphabets are supported. There are some
> extensions as in emacs regexps, like \w matching words, \b matching
> boundaries, etc. (and their opposites \W, \B etc.). The repeating
> patterns {n,m} are not supported, i am not even sure the alternative
> patterns patt1|patt2 are. But thanks to all these shortcomings nregex
> is very small and can use a clever trick to speed up character classes
> matching. Basically when encountering [...] it builds a bitstring of
> length 256 having ones at each matching position (with special cases for
> \w etc.) or inverted if one has [^...] and this can be very fast to
> match on something. On the contrary pregexp does straightforward
> comparisons. Hence one may expect considerable speed difference between
> them. In the way in which regexp is used in maxima (in cl-info.lisp for
> finding stuff and in in commac.lisp for stripping a string of trailing
> zeroes) the speed difference could cause problems.
>
>
> --
> Michel Talon
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Leo B. <l_b...@us...>]

One further observation: sregex is written in scheme and uses recursion
extensively. When I looked at sregex a few years ago as a possible
replacement for nregex, I recall that the lisp version ran very slow and
had numerous stack overflows when run against Maxima's info files.

Leo

Volker van Nek <vol...@gm...> writes:

> Thank you, Michel.
>
> These are very helpful informations.
>
> Volker van Nek
>
> 2015-10-19 10:31 GMT+02:00 Michel Talon <ta...@lp...>:
>
>> Le 18/10/2015 23:10, Robert Dodier a écrit :
>> >> In share/stringproc there is an alternative regex parser (portable regex
>> >> >parser by Dorai Sitaram) with an interface at Maxima level.
>> >> >
>> >> >It works nicely but it appears to be quite slow.
>> > Thanks for the reminder, I had forgotten about that. I suspect that
>> > sregex is strictly more powerful than nregex; I'd be surprised if nregex
>> > were any faster, but that is not a key point. Also it's helpful that
>> > there is a Maxima interface for sregex. Given all that, I'm in favor of
>> > moving sregex into src and nuking nregex. There are a few calls to
>> > nregex in src, but those would be easily replaced by sregex, I believe.
>> >
>>
>> Well, i have looked a little bit at the programes nregex, pregexp, and
>> the way nregex is used in maxima. Obviously pregexp is a complete regex
>> parser, covering more or less the perl regexp syntax, while nregex is
>> a very basic regex parser covering the standard new regex syntax as in
>> grep -E except that modern stuff [:alnum:] etc. is not supported. Of
>> course only 256 characters alphabets are supported. There are some
>> extensions as in emacs regexps, like \w matching words, \b matching
>> boundaries, etc. (and their opposites \W, \B etc.). The repeating
>> patterns {n,m} are not supported, i am not even sure the alternative
>> patterns patt1|patt2 are. But thanks to all these shortcomings nregex
>> is very small and can use a clever trick to speed up character classes
>> matching. Basically when encountering [...] it builds a bitstring of
>> length 256 having ones at each matching position (with special cases for
>> \w etc.) or inverted if one has [^...] and this can be very fast to
>> match on something. On the contrary pregexp does straightforward
>> comparisons. Hence one may expect considerable speed difference between
>> them. In the way in which regexp is used in maxima (in cl-info.lisp for
>> finding stuff and in in commac.lisp for stripping a string of trailing
>> zeroes) the speed difference could cause problems.
>>
>>
>> --
>> Michel Talon
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

Am 19.10.2015 um 16:56 schrieb Leo Butler:
> 
> One further observation: sregex is written in scheme and uses recursion
> extensively. When I looked at sregex a few years ago as a possible
> replacement for nregex, I recall that the lisp version ran very slow and
> had numerous stack overflows when run against Maxima's info files.

The regex parser share/stringproc/pregexp.lisp by Dorai Sitaram has been
fully revised and is now completely written in Lisp.

https://github.com/ds26gte/pregexp/

I plan for the next weekend to replace the current pregexp.lisp and to
write a documentation for the interface functions in sregex.lisp.
Hopefully the new version will show better results.

Volker

> 
> Leo
> 
> Volker van Nek <vol...@gm...> writes:
> 
>> Thank you, Michel.
>>
>> These are very helpful informations.
>>
>> Volker van Nek
>>
>> 2015-10-19 10:31 GMT+02:00 Michel Talon <ta...@lp...>:
>>
>>> Le 18/10/2015 23:10, Robert Dodier a écrit :
>>>>> In share/stringproc there is an alternative regex parser (portable regex
>>>>>> parser by Dorai Sitaram) with an interface at Maxima level.
>>>>>>
>>>>>> It works nicely but it appears to be quite slow.
>>>> Thanks for the reminder, I had forgotten about that. I suspect that
>>>> sregex is strictly more powerful than nregex; I'd be surprised if nregex
>>>> were any faster, but that is not a key point. Also it's helpful that
>>>> there is a Maxima interface for sregex. Given all that, I'm in favor of
>>>> moving sregex into src and nuking nregex. There are a few calls to
>>>> nregex in src, but those would be easily replaced by sregex, I believe.
>>>>
>>>
>>> Well, i have looked a little bit at the programes nregex, pregexp, and
>>> the way nregex is used in maxima. Obviously pregexp is a complete regex
>>> parser, covering more or less the perl regexp syntax, while nregex is
>>> a very basic regex parser covering the standard new regex syntax as in
>>> grep -E except that modern stuff [:alnum:] etc. is not supported. Of
>>> course only 256 characters alphabets are supported. There are some
>>> extensions as in emacs regexps, like \w matching words, \b matching
>>> boundaries, etc. (and their opposites \W, \B etc.). The repeating
>>> patterns {n,m} are not supported, i am not even sure the alternative
>>> patterns patt1|patt2 are. But thanks to all these shortcomings nregex
>>> is very small and can use a clever trick to speed up character classes
>>> matching. Basically when encountering [...] it builds a bitstring of
>>> length 256 having ones at each matching position (with special cases for
>>> \w etc.) or inverted if one has [^...] and this can be very fast to
>>> match on something. On the contrary pregexp does straightforward
>>> comparisons. Hence one may expect considerable speed difference between
>>> them. In the way in which regexp is used in maxima (in cl-info.lisp for
>>> finding stuff and in in commac.lisp for stripping a string of trailing
>>> zeroes) the speed difference could cause problems.
>>>
>>>
>>> --
>>> Michel Talon
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Maxima-discuss mailing list
>>> Max...@li...
>>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Robert D. <rob...@gm...>]

On 2015-10-19, Volker van Nek <vol...@gm...> wrote:

> Thereafter I will see how I can replace calls to nregex in src. Maybe I
> need help at this point to identify and understand all calls to nregex.

There are only a few -- grepping the source code, I see they are:

 * src/commac.lisp: strip trailing zeros from floats; parse time/date
 * src/cl-info.lisp: search for help topic
 * share/contrib/unicodedata/unicodedata.lisp: not sure

If you can take a look at this stuff, that will be terrific. Thanks a
lot.

best,

Robert Dodier

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

Am 19.10.2015 um 18:54 schrieb Robert Dodier:
> On 2015-10-19, Volker van Nek <vol...@gm...> wrote:
> 
>> Thereafter I will see how I can replace calls to nregex in src. Maybe I
>> need help at this point to identify and understand all calls to nregex.
> 
> There are only a few -- grepping the source code, I see they are:
> 
>  * src/commac.lisp: strip trailing zeros from floats; parse time/date
>  * src/cl-info.lisp: search for help topic
>  * share/contrib/unicodedata/unicodedata.lisp: not sure
> 
> If you can take a look at this stuff, that will be terrific. Thanks a
> lot.

I put this on my todo-list for the next weekend.

Volker

> 
> best,
> 
> Robert Dodier
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> 

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

I have coded and tested pregexp-replacements for functions using nregex
in src/commac.lisp and src/cl-info.lisp.

This time I used sbcl.
(compile_file doesn't work with gcl 2.6.12 in my gcl-Maxima build)

I compiled pregexp.lisp and the replacements by compile_file.
I.e. I had simply overwritten some functions in an already build Maxima.
(For replacing nregex.lisp by pregexp.lisp in maxima.system I would need
assistance.)


cl-info:
regex-sanitize, find-regex-matches

As far as I can see, find-regex-matches is used by
??, ? and describe. I checked describe:

thru 100 do describe(cint);
7.7080 seconds using 627.061 MB.  <- with nregex
6.8160 seconds using 2378.905 MB. <- with pregexp

thru 100 do describe(subvarp);
7.6560 seconds using 631.239 MB.  <- with nregex
7.9520 seconds using 2382.587 MB. <- with pregexp

thru 100 do describe(foo);
5.4640 seconds using 439.326 MB.  <- with nregex
5.0360 seconds using 1591.035 MB. <- with pregexp

-> same timing results but 4 times more space for pregexp


commac:
strip-float-zeros, $parse_timedate

I don't expect $parse_timedate to be any crucial,
I just checked strip-float-zeros:

The test I performed was essentially printing floats from 1.0 to n
redirected into a string_output_stream.
This test calls two regex matching functions:
trailing-zeros-regex-f-0 (no match) and
trailing-zeros-regex-f-1 (match)

test(n) :=
  block([old_io, redirection],
    old_io : ?\*standard\-output\*,
    redirection : make_string_output_stream(),
    ?\*standard\-output\* : redirection,
    for i:1.0 thru n do print(i),
    ?\*standard\-output\* : old_io,
    close(redirection) )$

test(100000)$
5.3080 seconds using 514.245 MB.  <- with nregex
test(100000)$
9.4680 seconds using 1810.400 MB. <- with pregexp

-> double time and again 4 times more space for pregexp


share/contrib/unicodedata/unicodedata.lisp
uses nregex but I did not look very closely here.
At first sight a replacement seems to be possible.
Maybe Leo Butler wants to reorganize his code by himself if we want to
proceed in that direction.

The question is: Do we want to proceed in that direction?

Volker



Am 19.10.2015 um 18:54 schrieb Robert Dodier:
> On 2015-10-19, Volker van Nek <vol...@gm...> wrote:
> 
>> Thereafter I will see how I can replace calls to nregex in src. Maybe I
>> need help at this point to identify and understand all calls to nregex.
> 
> There are only a few -- grepping the source code, I see they are:
> 
>  * src/commac.lisp: strip trailing zeros from floats; parse time/date
>  * src/cl-info.lisp: search for help topic
>  * share/contrib/unicodedata/unicodedata.lisp: not sure
> 
> If you can take a look at this stuff, that will be terrific. Thanks a
> lot.
> 
> best,
> 
> Robert Dodier
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> 

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Camm M. <ca...@ma...>]

Greetings!

Volker van Nek <vol...@gm...> writes:

> I have coded and tested pregexp-replacements for functions using nregex
> in src/commac.lisp and src/cl-info.lisp.
>
> This time I used sbcl.
> (compile_file doesn't work with gcl 2.6.12 in my gcl-Maxima build)
>

If you'd like to provide the details here I'll try to look into it.

Take care,
-- 
Camm Maguire			     		    ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: [Maxima-discuss] compile_file with gcl 2.6.12, was: regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

Hi Camm,

I hope the following provides enough details.

I put nothing but
(defun eleven () 11)
into a file.

volker@uvw32:~/Maxima/test$ gcl
GCL (GNU Common Lisp)  2.6.12 ANSI    Oct  7 2015 16:20:57

>(load "~/Maxima/test/eleven.lisp")
Loading ~/Maxima/test/eleven.lisp
Finished loading ~/Maxima/test/eleven.lisp
T

>(eleven)
11

>(compile 'eleven)
Compiling /tmp/gazonk_5346_0.lsp.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /tmp/gazonk_5346_0.lsp.
Loading /tmp/gazonk_5346_0.o
start address -T 0x826880 Finished loading /tmp/gazonk_5346_0.o
#<compiled-function ELEVEN>
NIL
NIL

>(compile-file "~/Maxima/test/eleven.lisp")
Compiling ~/Maxima/test/eleven.lisp.
End of Pass 1.
End of Pass 2.

Error:
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by COMPILE-FILE.
Condition in COMPILE-FILE [or a callee]: INTERNAL-SIMPLE-ERROR: Format
error: illegal directive.


                                                  V
"gcc -c -g -fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2  -fsigned-char -Wall -Wno-unused-but-set-variable
-pipe  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c
"~/Maxima/test/eleven.c" -o "~/Maxima/test/eleven.o" "


Broken at COMPILE-FILE.  Type :H for Help.
    1  Return to top level.
>>


Take care

Volker

Am 26.10.2015 um 15:58 schrieb Camm Maguire:
> Greetings!
> 
> Volker van Nek <vol...@gm...> writes:
> 
>> I have coded and tested pregexp-replacements for functions using nregex
>> in src/commac.lisp and src/cl-info.lisp.
>>
>> This time I used sbcl.
>> (compile_file doesn't work with gcl 2.6.12 in my gcl-Maxima build)
>>
> 
> If you'd like to provide the details here I'll try to look into it.
> 
> Take care,
> 

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Robert D. <rob...@gm...>]

On 2015-10-25, Volker van Nek <vol...@gm...> wrote:

> I have coded and tested pregexp-replacements for functions using nregex
> in src/commac.lisp and src/cl-info.lisp.

Thanks, Volker, that's very interesting. Can you post a diff for commac
and cl-info? I'd like to give it a try. I have downloaded Sitaram's
current version of pregexp.

best,

Robert Dodier

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

I had to add two global variables to pregexp.lisp and did some minor
changes in that file (marked with ;; vN).
E.g.
cl-info::regex-sanitize wants a list of special chars and
cl-info::find-regex-matches wants to search case insensitive.

I appended the modified pregexp.lisp.

The other file contains the replacements for the functions in commac and
cl-info which currently use nregex.

I don't fully understand Maxima's building process and I don't know how
to merge these changes into Maxima for building it. One problem to me
are the global variables I introduced. So I don't know how a correct
diff should look like.

Volker

Am 26.10.2015 um 19:23 schrieb Robert Dodier:
> On 2015-10-25, Volker van Nek <vol...@gm...> wrote:
> 
>> I have coded and tested pregexp-replacements for functions using nregex
>> in src/commac.lisp and src/cl-info.lisp.
> 
> Thanks, Volker, that's very interesting. Can you post a diff for commac
> and cl-info? I'd like to give it a try. I have downloaded Sitaram's
> current version of pregexp.
> 
> best,
> 
> Robert Dodier
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> 

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Leo B. <l_b...@us...>]

Volker, I doubt you will get such good results with gcl. Nregex is 31
times faster:

pregex + gcl 2.6.12

(%i5) unicode_add(["GREEK","LATIN","APL","NON-SPACING"]);
Evaluation took 32.3900 seconds (34.2200 elapsed)
(%o5)     [[GREEK, 553], [LATIN, 1478], [APL, 73], [NON-SPACING, 0]]

nregex + gcl 2.6.12

(%i4) unicode_add(["GREEK","LATIN","APL","NON-SPACING"]);
Evaluation took 1.0400 seconds (1.1200 elapsed)
(%o4)     [[GREEK, 553], [LATIN, 1478], [APL, 73], [NON-SPACING, 0]]

Leo

Volker van Nek <vol...@gm...> writes:

> I have coded and tested pregexp-replacements for functions using nregex
> in src/commac.lisp and src/cl-info.lisp.
>
> This time I used sbcl.
> (compile_file doesn't work with gcl 2.6.12 in my gcl-Maxima build)
>
> I compiled pregexp.lisp and the replacements by compile_file.
> I.e. I had simply overwritten some functions in an already build Maxima.
> (For replacing nregex.lisp by pregexp.lisp in maxima.system I would need
> assistance.)
>
>
> cl-info:
> regex-sanitize, find-regex-matches
>
> As far as I can see, find-regex-matches is used by
> ??, ? and describe. I checked describe:
>
> thru 100 do describe(cint);
> 7.7080 seconds using 627.061 MB.  <- with nregex
> 6.8160 seconds using 2378.905 MB. <- with pregexp
>
> thru 100 do describe(subvarp);
> 7.6560 seconds using 631.239 MB.  <- with nregex
> 7.9520 seconds using 2382.587 MB. <- with pregexp
>
> thru 100 do describe(foo);
> 5.4640 seconds using 439.326 MB.  <- with nregex
> 5.0360 seconds using 1591.035 MB. <- with pregexp
>
> -> same timing results but 4 times more space for pregexp
>
>
> commac:
> strip-float-zeros, $parse_timedate
>
> I don't expect $parse_timedate to be any crucial,
> I just checked strip-float-zeros:
>
> The test I performed was essentially printing floats from 1.0 to n
> redirected into a string_output_stream.
> This test calls two regex matching functions:
> trailing-zeros-regex-f-0 (no match) and
> trailing-zeros-regex-f-1 (match)
>
> test(n) :=
>   block([old_io, redirection],
>     old_io : ?\*standard\-output\*,
>     redirection : make_string_output_stream(),
>     ?\*standard\-output\* : redirection,
>     for i:1.0 thru n do print(i),
>     ?\*standard\-output\* : old_io,
>     close(redirection) )$
>
> test(100000)$
> 5.3080 seconds using 514.245 MB.  <- with nregex
> test(100000)$
> 9.4680 seconds using 1810.400 MB. <- with pregexp
>
> -> double time and again 4 times more space for pregexp
>
>
> share/contrib/unicodedata/unicodedata.lisp
> uses nregex but I did not look very closely here.
> At first sight a replacement seems to be possible.
> Maybe Leo Butler wants to reorganize his code by himself if we want to
> proceed in that direction.
>
> The question is: Do we want to proceed in that direction?
>
> Volker
>
>
>
> Am 19.10.2015 um 18:54 schrieb Robert Dodier:
>> On 2015-10-19, Volker van Nek <vol...@gm...> wrote:
>> 
>>> Thereafter I will see how I can replace calls to nregex in src. Maybe I
>>> need help at this point to identify and understand all calls to nregex.
>> 
>> There are only a few -- grepping the source code, I see they are:
>> 
>>  * src/commac.lisp: strip trailing zeros from floats; parse time/date
>>  * src/cl-info.lisp: search for help topic
>>  * share/contrib/unicodedata/unicodedata.lisp: not sure
>> 
>> If you can take a look at this stuff, that will be terrific. Thanks a
>> lot.
>> 
>> best,
>> 
>> Robert Dodier
>> 
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Maxima-discuss mailing list
>> Max...@li...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>> 
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

I can't do better. Compiling pregexp with sbcl I get a factor of about 10,
i.e. nregex is 10 times faster in this situation.

It turns out that there is a significant speed and space advantage for
nregex. On the other hand, as Michel Talon has pointed out earlier in this
thread, nregex is very limited.
'|' is treated as an ordinary character and in case of e.g. "w{3}"
nregex-compile loops endlessly.

I would like to propose the following. We leave nregex in src and pregexp
in share/stringproc and I will modify the Maxima level functions in
share/stringproc in a way that the user can decide which scanner he or she
wants to use. E.g.

regex_match(regex, string) with pregexp as the default,
regex_match(regex, string, 'pregexp) and
regex_match(regex, string, 'nregex).

pregexp also allows to set start and end positions. These might be passed
in as optional arguments.

The documentation then should emphasize the advantages and limitations of
nregex.

Volker


2015-10-26 21:46 GMT+01:00 Leo Butler <l_b...@us...>:

>
> Volker, I doubt you will get such good results with gcl. Nregex is 31
> times faster:
>
> pregex + gcl 2.6.12
>
> (%i5) unicode_add(["GREEK","LATIN","APL","NON-SPACING"]);
> Evaluation took 32.3900 seconds (34.2200 elapsed)
> (%o5)     [[GREEK, 553], [LATIN, 1478], [APL, 73], [NON-SPACING, 0]]
>
> nregex + gcl 2.6.12
>
> (%i4) unicode_add(["GREEK","LATIN","APL","NON-SPACING"]);
> Evaluation took 1.0400 seconds (1.1200 elapsed)
> (%o4)     [[GREEK, 553], [LATIN, 1478], [APL, 73], [NON-SPACING, 0]]
>
> Leo
>
> Volker van Nek <vol...@gm...> writes:
>
> > I have coded and tested pregexp-replacements for functions using nregex
> > in src/commac.lisp and src/cl-info.lisp.
> >
> > This time I used sbcl.
> > (compile_file doesn't work with gcl 2.6.12 in my gcl-Maxima build)
> >
> > I compiled pregexp.lisp and the replacements by compile_file.
> > I.e. I had simply overwritten some functions in an already build Maxima.
> > (For replacing nregex.lisp by pregexp.lisp in maxima.system I would need
> > assistance.)
> >
> >
> > cl-info:
> > regex-sanitize, find-regex-matches
> >
> > As far as I can see, find-regex-matches is used by
> > ??, ? and describe. I checked describe:
> >
> > thru 100 do describe(cint);
> > 7.7080 seconds using 627.061 MB.  <- with nregex
> > 6.8160 seconds using 2378.905 MB. <- with pregexp
> >
> > thru 100 do describe(subvarp);
> > 7.6560 seconds using 631.239 MB.  <- with nregex
> > 7.9520 seconds using 2382.587 MB. <- with pregexp
> >
> > thru 100 do describe(foo);
> > 5.4640 seconds using 439.326 MB.  <- with nregex
> > 5.0360 seconds using 1591.035 MB. <- with pregexp
> >
> > -> same timing results but 4 times more space for pregexp
> >
> >
> > commac:
> > strip-float-zeros, $parse_timedate
> >
> > I don't expect $parse_timedate to be any crucial,
> > I just checked strip-float-zeros:
> >
> > The test I performed was essentially printing floats from 1.0 to n
> > redirected into a string_output_stream.
> > This test calls two regex matching functions:
> > trailing-zeros-regex-f-0 (no match) and
> > trailing-zeros-regex-f-1 (match)
> >
> > test(n) :=
> >   block([old_io, redirection],
> >     old_io : ?\*standard\-output\*,
> >     redirection : make_string_output_stream(),
> >     ?\*standard\-output\* : redirection,
> >     for i:1.0 thru n do print(i),
> >     ?\*standard\-output\* : old_io,
> >     close(redirection) )$
> >
> > test(100000)$
> > 5.3080 seconds using 514.245 MB.  <- with nregex
> > test(100000)$
> > 9.4680 seconds using 1810.400 MB. <- with pregexp
> >
> > -> double time and again 4 times more space for pregexp
> >
> >
> > share/contrib/unicodedata/unicodedata.lisp
> > uses nregex but I did not look very closely here.
> > At first sight a replacement seems to be possible.
> > Maybe Leo Butler wants to reorganize his code by himself if we want to
> > proceed in that direction.
> >
> > The question is: Do we want to proceed in that direction?
> >
> > Volker
> >
> >
> >
> > Am 19.10.2015 um 18:54 schrieb Robert Dodier:
> >> On 2015-10-19, Volker van Nek <vol...@gm...> wrote:
> >>
> >>> Thereafter I will see how I can replace calls to nregex in src. Maybe I
> >>> need help at this point to identify and understand all calls to nregex.
> >>
> >> There are only a few -- grepping the source code, I see they are:
> >>
> >>  * src/commac.lisp: strip trailing zeros from floats; parse time/date
> >>  * src/cl-info.lisp: search for help topic
> >>  * share/contrib/unicodedata/unicodedata.lisp: not sure
> >>
> >> If you can take a look at this stuff, that will be terrific. Thanks a
> >> lot.
> >>
> >> best,
> >>
> >> Robert Dodier
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Maxima-discuss mailing list
> >> Max...@li...
> >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> >>
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Maxima-discuss mailing list
> > Max...@li...
> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

Re: [Maxima-discuss] compile_file with gcl 2.6.12, was: regex packages, was: Reading data from header

[Camm M. <ca...@ma...>]

Greetings, and thanks so much for the report!  I've checked in a fix,
and uploaded to Debian unstable.

Take care,

Volker van Nek <vol...@gm...> writes:

> Hi Camm,
>
> I hope the following provides enough details.
>
> I put nothing but
> (defun eleven () 11)
> into a file.
>
> volker@uvw32:~/Maxima/test$ gcl
> GCL (GNU Common Lisp)  2.6.12 ANSI    Oct  7 2015 16:20:57
>
>>(load "~/Maxima/test/eleven.lisp")
> Loading ~/Maxima/test/eleven.lisp
> Finished loading ~/Maxima/test/eleven.lisp
> T
>
>>(eleven)
> 11
>
>>(compile 'eleven)
> Compiling /tmp/gazonk_5346_0.lsp.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling /tmp/gazonk_5346_0.lsp.
> Loading /tmp/gazonk_5346_0.o
> start address -T 0x826880 Finished loading /tmp/gazonk_5346_0.o
> #<compiled-function ELEVEN>
> NIL
> NIL
>
>>(compile-file "~/Maxima/test/eleven.lisp")
> Compiling ~/Maxima/test/eleven.lisp.
> End of Pass 1.
> End of Pass 2.
>
> Error:
> Fast links are on: do (si::use-fast-links nil) for debugging
> Signalled by COMPILE-FILE.
> Condition in COMPILE-FILE [or a callee]: INTERNAL-SIMPLE-ERROR: Format
> error: illegal directive.
>
>
>                                                   V
> "gcc -c -g -fstack-protector-strong -Wformat -Werror=format-security
> -D_FORTIFY_SOURCE=2  -fsigned-char -Wall -Wno-unused-but-set-variable
> -pipe  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c
> "~/Maxima/test/eleven.c" -o "~/Maxima/test/eleven.o" "
>
>
> Broken at COMPILE-FILE.  Type :H for Help.
>     1  Return to top level.
>>>
>
>
> Take care
>
> Volker
>
> Am 26.10.2015 um 15:58 schrieb Camm Maguire:
>> Greetings!
>> 
>> Volker van Nek <vol...@gm...> writes:
>> 
>>> I have coded and tested pregexp-replacements for functions using nregex
>>> in src/commac.lisp and src/cl-info.lisp.
>>>
>>> This time I used sbcl.
>>> (compile_file doesn't work with gcl 2.6.12 in my gcl-Maxima build)
>>>
>> 
>> If you'd like to provide the details here I'll try to look into it.
>> 
>> Take care,
>> 
>
>
>
>
>

-- 
Camm Maguire			     		    ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: [Maxima-discuss] compile_file with gcl 2.6.12, was: regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

Hi Camm,

thanks a lot for your help.

With gcl_2.6.12-28_i386.deb from debian sid compile-file and
compile_file now both work again for me.

Volker

Am 27.10.2015 um 18:52 schrieb Camm Maguire:
> Greetings, and thanks so much for the report!  I've checked in a fix,
> and uploaded to Debian unstable.
> 
> Take care,
> 
> Volker van Nek <vol...@gm...> writes:
> 
>> Hi Camm,
>>
>> I hope the following provides enough details.
>>
>> I put nothing but
>> (defun eleven () 11)
>> into a file.
>>
>> volker@uvw32:~/Maxima/test$ gcl
>> GCL (GNU Common Lisp)  2.6.12 ANSI    Oct  7 2015 16:20:57
>>
>>> (load "~/Maxima/test/eleven.lisp")
>> Loading ~/Maxima/test/eleven.lisp
>> Finished loading ~/Maxima/test/eleven.lisp
>> T
>>
>>> (eleven)
>> 11
>>
>>> (compile 'eleven)
>> Compiling /tmp/gazonk_5346_0.lsp.
>> End of Pass 1.
>> End of Pass 2.
>> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
>> Finished compiling /tmp/gazonk_5346_0.lsp.
>> Loading /tmp/gazonk_5346_0.o
>> start address -T 0x826880 Finished loading /tmp/gazonk_5346_0.o
>> #<compiled-function ELEVEN>
>> NIL
>> NIL
>>
>>> (compile-file "~/Maxima/test/eleven.lisp")
>> Compiling ~/Maxima/test/eleven.lisp.
>> End of Pass 1.
>> End of Pass 2.
>>
>> Error:
>> Fast links are on: do (si::use-fast-links nil) for debugging
>> Signalled by COMPILE-FILE.
>> Condition in COMPILE-FILE [or a callee]: INTERNAL-SIMPLE-ERROR: Format
>> error: illegal directive.
>>
>>
>>                                                   V
>> "gcc -c -g -fstack-protector-strong -Wformat -Werror=format-security
>> -D_FORTIFY_SOURCE=2  -fsigned-char -Wall -Wno-unused-but-set-variable
>> -pipe  -I/usr/lib/gcl-2.6.12/unixport/../h  -O2  -c
>> "~/Maxima/test/eleven.c" -o "~/Maxima/test/eleven.o" "
>>
>>
>> Broken at COMPILE-FILE.  Type :H for Help.
>>     1  Return to top level.
>>>>
>>
>>
>> Take care
>>
>> Volker
>>
>> Am 26.10.2015 um 15:58 schrieb Camm Maguire:
>>> Greetings!
>>>
>>> Volker van Nek <vol...@gm...> writes:
>>>
>>>> I have coded and tested pregexp-replacements for functions using nregex
>>>> in src/commac.lisp and src/cl-info.lisp.
>>>>
>>>> This time I used sbcl.
>>>> (compile_file doesn't work with gcl 2.6.12 in my gcl-Maxima build)
>>>>
>>>
>>> If you'd like to provide the details here I'll try to look into it.
>>>
>>> Take care,
>>>
>>
>>
>>
>>
>>
> 

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Robert D. <rob...@gm...>]

On 2015-10-27, Volker van Nek <vol...@gm...> wrote:

> I would like to propose the following. We leave nregex in src and pregexp
> in share/stringproc and I will modify the Maxima level functions in
> share/stringproc in a way that the user can decide which scanner he or she
> wants to use. E.g.

I dunno, I'm opposed to making both nregex and pregexp available to
users. I think the confusion and effort involved outweigh the benefit of
it. At this point my recommendation is to move pregexp into src so that
it is compiled at least.

I think it's reasonable to move the rest of stringproc into src as well
but that is a separate issue.

best

Robert Dodier

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Volker v. N. <vol...@gm...>]

Am 27.10.2015 um 20:12 schrieb Robert Dodier:
> On 2015-10-27, Volker van Nek <vol...@gm...> wrote:
> 
>> I would like to propose the following. We leave nregex in src and pregexp
>> in share/stringproc and I will modify the Maxima level functions in
>> share/stringproc in a way that the user can decide which scanner he or she
>> wants to use. E.g.
> 
> I dunno, I'm opposed to making both nregex and pregexp available to
> users. I think the confusion and effort involved outweigh the benefit of
> it. 

Maybe that' true. OK by me.

At this point my recommendation is to move pregexp into src so that
> it is compiled at least.

When a new file moves to src, what is to be done?
As far as I can see there must be an entry in maxima.system and
maxima.asd. Somewhere else?
Is :module miscellaneous the right place in maxima.system and maxima.asd?

Volker

> 
> I think it's reasonable to move the rest of stringproc into src as well
> but that is a separate issue.
> 
> best
> 
> Robert Dodier
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
> 

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Raymond T. <toy...@gm...>]

On Tue, Oct 27, 2015 at 12:12 PM, Robert Dodier <rob...@gm...>
wrote:

> On 2015-10-27, Volker van Nek <vol...@gm...> wrote:
>
> > I would like to propose the following. We leave nregex in src and pregexp
> > in share/stringproc and I will modify the Maxima level functions in
> > share/stringproc in a way that the user can decide which scanner he or
> she
> > wants to use. E.g.
>
> I dunno, I'm opposed to making both nregex and pregexp available to
> users. I think the confusion and effort involved outweigh the benefit of
> it. At this point my recommendation is to move pregexp into src so that
> it is compiled at least.
>

​I don't find that to be a problem.  I use grep and egrep and emacs regexp
all the time.  I also suspect that nregex probably supports enough for most
people and is fast very fast for those cases. For those requiring more,
they can specify pregexp.

Of course, there's also the quip about deciding to use regexp and then
suddenly having one more problem. :-)

And there's nothing preventing stringproc to compile up the code.  After
all, lbfgs and lapack run compiled, not interpreted. ​


>
> I think it's reasonable to move the rest of stringproc into src as well
> but that is a separate issue.
>
> best
>
> Robert Dodier
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>



-- 
Ray

Re: [Maxima-discuss] regex packages, was: Reading data from header

[Camm M. <ca...@ma...>]

Greetings!  Here is a rough attempt at replacing obsolete texi2html with
makeinfo.  If adopted, the makefiles and filenames would need changing.
I have not examined the output in any detail for errors.  Just basically
reworked the scripts to give unique anchor names.

Take care,
-- 
Camm Maguire			     		    ca...@ma...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah