tsyijiuyt / muparser Goto Github PK

Hello,

OpenTURNS, an open-source lib dedicated to the treatment of uncertainties, use 
MuParser for some study. By the way, thanks for your work! 
So, for some large study we would like to speed up a little bit the 
computation. So we would like to enable OpenMP inside muParser. 
We know that using a just in time parser would be much faster, but it would 
involve much more work. OpenMP in muParser is the first easy step to speed up 
our code.

I tried to enable OpenMP support on Linux (using autoconf). 
But using the revision 10 of http://muparser.googlecode.com/svn/trunk source, 
if I uncomment the line "#define MUP_USE_OPENMP" it does not enable OpenMP 
compilation  switch and the compilation fails.

I made a patch and the compilation using autoconf runs fine now.
The patch add an --enable-openmp feature (openmp is disabled by default).

  ./configure --enable-openmp
  make
  ...

My system is running on ubuntu 12.04 64bits.

Do you think the patch is good enough? I do not know if it will break 
compilation on other systems (windows ...) as I know only autoconf and cmake.
Could you consider merging this patch to muParser source code?

Beset regards,
Mathieu Souchaud

Incorrect string assignment, causing 1+2+3 to be parsed as "1", "+", and "2+3". 
Though the RPN part fix this and calculates the correct output.

In
  bool ParserTokenReader::IsValTok(token_type &a_Tok)
the line
        strTok.assign(m_strFormula.c_str(), iStart, m_iPos);
should be
        strTok.assign(m_strFormula.c_str(), iStart, m_iPos-iStart);
.

The string assign function uses count, not a second position:
    _Myt& assign(const _Myt& _Right,
        size_type _Roff, size_type _Count)

What steps will reproduce the problem?
1.`export PATH=$PATH:$MY_ANDROID_STANDALONE_TOOLCHAIN/bin`
2.`./configure --disable-samples 
--prefix=$MY_ANDROID_STANDALONE_TOOLCHAIN/sysroot --host=arm-linux-androideabi`

What is the expected output? What do you see instead?
compile everything without any error but it outputs 
checking build system type... x86_64-unknown-linux-gnu
checking host system type... Invalid configuration `arm-linux-androideabi': 
system `androideabi' not recognized
configure: error: /bin/sh build/autoconf/config.sub arm-linux-androideabi 

What version of the product are you using? On what operating system?
Linux localhost.localdomain 3.13.11-100.fc19.x86_64 #1 SMP Wed Apr 23 20:10:57 
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.
SEE: 
http://stackoverflow.com/questions/4594736/configure-does-not-recognize-androide
abi
GET: https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html

NOTE: Android dont support versioned libraries. this did the trick:
Makefile.in 263: 
`@COND_SHARED_1@    $(SHARED_LD_CXX) $@ $(MUPARSER_DLL_OBJECTS)   
$(__muParser_dll___macinstnamecmd) $(__muParser_dll___importlib) 
$(__muParser_dll___macver) $(LDFLAGS)  $(LIBS)`

removed the `$(__muParser_dll___soname_flags)`
perform a conditional check to remove this if compiling for Android.

Alternate solution:
use Android NDK. afaik better and easier (for everyone).

Hello,

Here's a CMake file that allows to build muparser with cmake in a 
cross-platform manner.

Basically removes the need for specific build systems on each platforms (almost 
everything in /build): configure, bakefiles (build/bakefiles), mingw specific 
makefile (makefile.mingw), and msvc projects 
(./build/msvc2013/muparser*.vcxproj)

Usage:
cd [path to muParser]
cmake [-DBUILD_SHARED_LIBS=ON/OFF] [-DBUILD_SAMPLES=ON/PFF]
             [-DCMAKE_BUILD_TYPE=Release/Debug]
make
[sudo*] make install

Also builds tarballs muparser-2.2.4.zip|tar.gz:
make package_source

Has in it almost all that is needed to solve #3. We should then create a 
muParserDef.h.in file to be configured with the conditional definition of 
MUP_USE_OPENMP. Then cmake can take advantage of arguments 
[-DUSE_OPENMP=ON/OFF]. See comments inside.

Tested on linux, mingw-w64, should build on msvc too.

Would you consider this as a build-system replacement ?

fix problems with non set thousands separator on macos

Because of a somewhat confusing usage of "infix" to mean "prefix" in muParser, 
the author of ParserTokenReader::ExtractOperatorToken validates the input 
characters for binary operators against ValidInfixOprtChars(), whereas it 
should be validated against ValidOprtChars().

Attached is a patch for the problem.

What steps will reproduce the problem?
1. Add an extra operator char, eg ";"

    m_parser.DefineOprtChars(
            // standard operator chars as defined in mu::Parser::InitCharSets()
            "abcdefghijklmnopqrstuvwxyz"
            "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
            "+-*^/?<>=#!$%&|~'_"
            // our additions
            ";");

2.

Add the extra binary operator
    m_parser.DefineOprt(";", statementSeparator, -2);

3.

Add some suitable expression

m_parser.SetExpr("12.0 ; 13.0");


4. Call m_parser.Eval();

This will throw with an unexpected token exception.

What version of the product are you using? On what operating system?

2.2.3 compiled on OpenSUSE 12.2

Please provide any additional information below.

What steps will reproduce the problem?
1. Set a mu::Parser's expression to one of the following:
1000*Part_0
1000.2*Part_0
0000.2*Part_0

2. Call mu::Parser::GetUsedVar()

3. 1000, 1000, and 0000 will be returned as variables for the cases listed 
above.

What is the expected output? What do you see instead?
I only expect to see Part_0 as a used variable.

-For the first case, muParser does not throw an exception, but it does say that 
1000 is a variable. I should say that it is a value.

-For the second case (1000.2*Part_0): I get the exception message: "Unexpected 
token ".2*Part_0*Part_1 " found at position 4."

-For the last case (000.2*Part_0): I get the exception message "Unexpected 
token ".2*Part_0*Part_1 " found at position 4."

muParser parses the expressions correctlywhen I use 999 and 999.2 in the 
expressions (instead of 1000 and 1000.2).

What version of the product are you using? On what operating system?
muParser 2.2.3.  I tried this with 2.2.4 taken from the svn repo and it also 
occurred. I'm on OSX version 10.7.5, and I am building muParser with the 
provided configure and make scripts. For my code, I'm compiling it with Apple 
LLVM 4.2 with C++11 support and linking to the libc++ std lib. I compiled 
muParser so that it also uses the same compiler settings as my code.

Please provide any additional information below.
I set some breakpoints in the muParser code to try and track it down. I tried 
to figure it out myself, but it's taking me a long time. Here's what I've got 
so far, and hopefully someone who knows the code better can take it from here:

In ParserBase::CreateRPN(), the line of code on line 1199:
opt = m_pTokenReader->ReadNextToken();

It returns an opt with the following state:
(mu::ParserBase::token_type) opt = {
  m_iCode = cmVAR
  m_iType = tpDBL
  m_pTok = 0x0000000100c038b8
  m_iIdx = -1
  m_strTok = "1000"
  m_strVal = ""
  m_fVal = 6.95322297490987e-310
  m_pCallback = {
    __ptr_ = 0x0000000000000000
  }
}

I believe that m_iCode should NOT be set to cmVAR, and should instead be set to 
cmVAL. I tried to dig deeper, but I didn't get very far.

Thanks for looking at this.