[ell-i-developers] Re: Robot Framework Testing: Test Cases Design, Scripting and other Issues

  • From: Asif Sardar <engr.asif.sardar@xxxxxxxxxxxxxx>
  • To: ell-i-developers@xxxxxxxxxxxxx
  • Date: Sun, 1 Jun 2014 19:05:15 +0300

There is 32 bit python version for Linux ->
http://askubuntu.com/questions/29253/how-can-i-install-a-32bit-python-on-64-bit-ubuntu

I already tried that ...

The problem is that the default linux python is in /usr/bin/ path ... which
I can't change to manual installed one (some system scripts might be
depending on it e.g. Xorg-server amoung others).

I screwed my own Ubuntu system, while messing up the default python over
manual one (by making symbolic link). It took me almost 6 hours of struggle
of recovery broken packages, but all in vain (unfortunately such problems
could be solved who have thorough level of linux operating system software
architecture knowledge at system level). Finally, I decided to reinstall
ubuntu and the ell-i software environment for testing and also runtime. It
was a good practice that took whole full day, I will make some good wiki
pages soon about the ell-i environment setup.

After some google search, I installed the manual 32 bit python in manual
prefix folder, and also alias the 'python' environment variable in
~/.bashrc file and put the manual python path to $PATH following this link
http://stackoverflow.com/questions/19256127/two-versions-of-python-on-linux-how-to-make-2-7-the-default

After this, I installed the robot framework again (keeping in mind it will
use the manual python path) ... then when I run the test case to load
shared library, it still failed.

I am confused, whether the robotframework is still using the default 64 bit
python or manually built 32 bit python ...


On Sun, Jun 1, 2014 at 6:38 PM, Pekka Nikander <pekka.nikander@xxxxxx>
wrote:

> I'm afraid the emulator may not work as a 64-bit version.  Most probably
> it won't.  There are just too many 32-bit dependencies in the Runtime code.
>
> Are there any 32-bit Python builds available for Linux?
>
> If not, then I'm afraid that this way won't work, but we have to treat the
> emulator more like the real device:  either build a separate 32-bit
> Linux-binary that has a Lua interpreter in it, or build separate binaries
> that spit out the register accesses, just like so far.
>
> --Pekka
>
> On 2014–06–01, at 3:35 , Jose Granados Vergara <jose.granados@xxxxxx>
> wrote:
>
> > It looks like you need to rebuild the .so libraries as 64 bits.
> >
> > El 31/05/2014, a las 22:43, Asif Sardar <engr.asif.sardar@xxxxxxxxxxxxxx>
> escribió:
> >
> >> Hi again,
> >>
> >> While loading shared library from test scripts, I got following error:
> >>
> >> [ ERROR ] Error in file
> '/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-suites/ELL-i-PyBot-Tests.wiki/DigitalRead.rest':
> Importing test library
> '/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py'
> failed: OSError: ../libemulator.so: wrong ELF class: ELFCLASS32
> >> Traceback (most recent call last):
> >>   File
> "/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py",
> line 8, in <module>
> >>     emulator = CDLL("../libemulator.so")
> >>   File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
> >>     self._handle = _dlopen(self._name, mode)
> >>
> >> I tried to compile a 32 bit version of python (aliasing
> python=/path/to/32/bit/python), install the robotframework using this
> python. Still same problem ...
> >>
> >> Some kind of problem as 32 bit vs 64 bit incompatibility ->
> http://askubuntu.com/questions/398929/unable-to-load-shared-object-wrong-elf-class-elfclass32
> >>
> >> Am I still using (default 64 bit python from /usr/bin/python/) for
> installing robotframework ? Shall I try manually building the
> robotframework from source code configuring it for 32-bit.
> >>
> >> I don't want uninstall the default python, because some system scripts
> might depend on that.
> >>
> >> Any suggestions please ...
> >>
> >>
> >> On Sat, May 31, 2014 at 10:21 PM, Asif Sardar <
> engr.asif.sardar@xxxxxxxxxxxxxx> wrote:
> >> Hello all,
> >>
> >> Trying to load a shared library such as 'libemulator.so' using ctypes
> modules and running the test cases such as DigitalRead resulted in the
> following error:
> >>
> >> [ ERROR ] Error in file
> '/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-suites/ELL-i-PyBot-Tests.wiki/DigitalRead.rest':
> Importing test library
> '/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py'
> failed: OSError: ../libemulator.so: wrong ELF class: ELFCLASS32
> >> Traceback (most recent call last):
> >>   File
> "/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py",
> line 9, in <module>
> >>     emulator = CDLL("../libemulator.so")
> >>   File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
> >>     self._handle = _dlopen(self._name, mode)
> >>
> >> ---------------------------------------------------------------
> >>
> >> @Pekka ---
> >> Besides that problem. Can you please check the emulator.mk and app.mk
> files attached to this e-mail. I messed my ubuntu system on Thursday and
> Friday while struggling with shared emulator library to start working with
> python scripts ... which resulted some lost files and crashes.
> >>
> >> So, if you can again guide me making shared library please... i get
> following error after applying patch for shared emulator library that you
> sent last week ...
> >>
> >> make PLATFORM=emulator -f ../make/app.mk all
> >> make[1]: Entering directory
> `/home/asif/Ell-i-Working-Directory/Ell-i-Software-Development/Runtime/stm32/build'
> >> g++ -m32 -march=i386 -m32 -demangle -march=i386 -Xlinker -T -Xlinker
> ../scripts//elf_i386.xc -o sketch  main.o sketch.o ellduino.o "-L."
> "-L../variants/ellduino" "-lstm32f0" -lstdc++
> >> /usr/bin/ld: skipping incompatible ../variants/ellduino/libstm32f0.a
> when searching for -lstm32f0
> >> /usr/bin/ld: cannot find -lstm32f0
> >> collect2: error: ld returned 1 exit status
> >> make[1]: *** [sketch] Error 1
> >> make[1]: Leaving directory
> `/home/asif/Ell-i-Working-Directory/Ell-i-Software-Development/Runtime/stm32/build'
> >> make: *** [all] Error 2
> >>
> >>
> >>
> >>
> >>
> >> On Mon, May 26, 2014 at 7:39 PM, Asif Sardar <
> engr.asif.sardar@xxxxxxxxxxxxxx> wrote:
> >> Hello all,
> >>
> >> Instead of using python C API to implement C libraries, it is often
> easier to interact with C code from Python libraries using ctypes module.
> >>
> >> Please have a look at
> https://github.com/Ell-i/ELL-i-PyBot-Tests/blob/master/test-scripts/DigitalRead.py
> >>
> >> This approach leaves much of the coding stuff to python. We can load
> the shared library and call the C functionality easily using the ctypes
> module's primitive C compatible fundamental data types.
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Apr 28, 2014 at 2:05 PM, Asif Sardar <
> engr.asif.sardar@xxxxxxxxxxxxxx> wrote:
> >> > The first thing is to get the c-python modules in the
> arduino-functions/Digital-I-O to include the right subdirectories from the
> >> > Runtime.  The following in setup.py seems to work as a first
> approximation:
> >>
> >> > ---------------
> >> > from os import path
> >>
> >> > runtime='/my/path/to/Runtime'
> >>
> >> > arduelli   = path.join(runtime, 'cores/arduelli')
> >> > system_inc = path.join(runtime, 'system/stm32/inc')
> >> > cmsis      = path.join(runtime, 'system/stm32/CMSIS/Include')
> >> > variant    = path.join(runtime, 'variants/ellduino')
> >>
> >> > include_dirs=[arduelli, system_inc, cmsis, variant]
> >>
> >> > setup(name='digitalRead', version='1.0',
> >>    >   ext_modules=[Extension('
> >> > digitalRead',
> >> >                          ['Digital-I-O/digitalRead.c'],
> >> >                        include_dirs=include_dirs)])
> >> > --------------------
> >>
> >> > The key there is the include_dirs in creating the Extension. See
> >>
> >> >   https://docs.python.org/2.7/distutils/setupscript.html
> >>
> >> > for more information.
> >>
> >> > With that you can include <wiring_digital.h> in digitalRead.c, but
> note that it must be included *before* including <Python.h>.
> >> > That then allows you to call the actual Runtime functions, and it
> compiles.  Python also tries to load the resulting shared library, > but
> that fails.
> >>
> >> With above paths included into the extension modules, we can compile
> the c-python modules. But, we also need the libraries or executable code
> for these functions at runtime. When I run the test cases with c-python
> modules compiled with above setup.py script, the test suite exits with
> segmentation fault.
> >>
> >>
> >> > The next step would then be to actually add the emulator functions to
> the python runtime.  That I don't know yet how to do
> >> > exactly, but I imagine that it would be best to compile the emulator
> into a shared library, through adding a new make target in
> >> > Runtime/stm32/make, and then including the shared library into the
> (DY)LD_LIBRARY_PATH.  That might suffice.
> >>
> >> I think the shared library for emulator functions might help
> eliminating the above weird problems at runtime ...
> >>
> >>
> >>
> >> On Sun, Apr 27, 2014 at 4:42 PM, Pekka Nikander <pekka.nikander@xxxxxx>
> wrote:
> >> > May I get some help regarding linking the c-python modules against
> the emulator? I cannot call the Arduino functions directly from c-python
> code files without linking against emulator and stm32 cores.
> >>
> >> I had a brief look at this today.  While I cannot present a full
> solution, I think I made some progress.
> >>
> >> The first thing is to get the c-python modules in the
> arduino-functions/Digital-I-O to include the right subdirectories from the
> Runtime.  The following in setup.py seems to work as a first approximation:
> >>
> >> ---------------
> >> from os import path
> >>
> >> runtime='/my/path/to/Runtime'
> >>
> >> arduelli   = path.join(runtime, 'cores/arduelli')
> >> system_inc = path.join(runtime, 'system/stm32/inc')
> >> cmsis      = path.join(runtime, 'system/stm32/CMSIS/Include')
> >> variant    = path.join(runtime, 'variants/ellduino')
> >>
> >> include_dirs=[arduelli, system_inc, cmsis, variant]
> >>
> >> setup(name='digitalRead', version='1.0',
> >>       ext_modules=[Extension('digitalRead',
> >>                              ['Digital-I-O/digitalRead.c'],
> >>                              include_dirs=include_dirs)])
> >> --------------------
> >>
> >> The key there is the include_dirs in creating the Extension. See
> >>
> >>   https://docs.python.org/2.7/distutils/setupscript.html
> >>
> >> for more information.
> >>
> >> With that you can include <wiring_digital.h> in digitalRead.c, but note
> that it must be included *before* including <Python.h>.  That then allows
> you to call the actual Runtime functions, and it compiles.  Python also
> tries to load the resulting shared library, but that fails.
> >>
> >> The next step would then be to actually add the emulator functions to
> the python runtime.  That I don't know yet how to do exactly, but I imagine
> that it would be best to compile the emulator into a shared library,
> through adding a new make target in Runtime/stm32/make, and then including
> the shared library into the (DY)LD_LIBRARY_PATH.  That might suffice.
> >>
> >> --Pekka
> >>
> >>
> >>
> >>
> >> --
> >> With Best Regards,
> >> Asif Sardar.
> >> +358 43 8265795
> >>
> >>
> >>
> >> --
> >> With Best Regards,
> >> Asif Sardar.
> >> +358 43 8265795
> >>
> >>
> >>
> >> --
> >> With Best Regards,
> >> Asif Sardar.
> >> +358 43 8265795
> >>
> >>
> >>
> >> --
> >> With Best Regards,
> >> Asif Sardar.
> >> +358 43 8265795
>
>


-- 



*With Best Regards,Asif Sardar.+358 43 8265795*

Other related posts: