Re: Regression Testing

Laurent Brack <[email protected]>
Newsgroups gmane.comp.python.pyro
Message-ID <CAO0-goM5boQ5EkM9EzDM1dHMvKm7r0V3AjQGtfw5uCRvMY6TGA@mail.gmail.com>
This is indeed a very interesting problem to solve and honestly I don't
know how a this point.

A few years back, we had started using Lua on our embedded devices as Lua
has a very very small footprint and was really OS independent (all you need
is an ANSI-C toolchain).

With Lua, it is very easy to create extensions to C or C++ code (called lua
bindings) which we had done. While this enabled scripting, the issue was
that the test runner had to run "on board" (being an ASIC company, it was
quite common that our chip would crash in the early stages and out went the
test runner and results.).

At the time, I had created something very similar to Pyro (but a 1000 times
less elegant and powerful) which I called lua_proxy allowing a client PC to
connect to one or more embedded device (where a small lua server was
running) and access those by delegating the calls from the client to the
server (without any change to the client Lua code aside from the "boostrap"
enabling the connection. The backend was basically using lua chunks
(compiled) which is, in essense, very similar to pickling.

A few years later I came across Pyro and needless to say I fell in love and
we have been using in many of your projects involving distributed
computing.

For embedded devices, having python running onboard may be a challenge
(maybe not so much for the hyper powerful mobile devices we have nowadays)
but for small embedded devices with a very small memory foot print.

This is a problem I will have to solve in the upcoming months and right now
I am looking at 2 things, one of them maybe completely impossible.

1- Mono which is a somewhat compatible CLR running on Linux/Mac OS and they
have a small footprint version of this (pre-built of IOS and Android and
somehow I can not find the reference to the generic small foot print
release on their site). This combined with IronPython could be an option
but then since the underlying code to be tested is C and C++ (unmanaged
code), this adds quite a bit of complexity.

2- Obviously the most elegant solution would be to create a bridge between
python and Lua (http://labix.org/lunatic-python) which works with Pyro.
Here, I have no idea what I am talking about since I haven't spent any time
on this.

Regardless this is something I need to solve somehow. Maybe a python client
with a Lua server?

If anybody has ideas or interest in this please let me know. Meanwhile
Prabhu your best bet is what Irmen suggested.

/Laurent




On Thu, May 17, 2012 at 4:45 AM, Irmen de Jong <[email protected]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17-5-2012 13:03, prabhu p wrote:
> > Hi All,
> >
> > I would like to use Pyro for my embedded Automation testing.
> >
> > Can anybody please suggest me, Whether is it possible to use Pyro for
> embedded
> > automation testing.
> >
> > The client is my Machine(Windows XP) connected with embedded
> device(QNX-RTOS).
> >
> > I would like to run some test cases from my machine to validate some
> services
> > which runs only in C on the target machine. My intention is write test
> cases in
> > python and will call C API on server/Target side.
>
> I know very little about QNX but I think getting Python on there could be
> problematic.
> You'll need to have Python 2.6+ running on the QNX device and interface to
> the C API
> from there. Why? Because Pyro can only talk to Python.
>
> (The older version of Pyro, 3.x, also works with Python 2.5)
>
> If you don't have a suitable Python version on the QNX device you're out
> of luck.
> Maybe a better option then is to use something like XML-RPC or JSON-RPC
> (or perhaps
> even basic HTTP via a web server, to trigger your tests on the device).
> These are very
> easy to call from Python, and I'm guessing there's C/C++ libraries for
> those on QNX.
>
>
> Irmen
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPtOTEAAoJEHC9o7RHFlf2hKEH/A8W7GsFaP4TiRLJk578RvY1
> GB/jipeSV3lfUet1hyj7aMlhA8LfisBiZtJDZdQZO686XSxVlvIVhsGT3TDNwiEk
> QBfKm8KoinKh8kyUYGgd/xV1xO2HRqsUY+HolmbINqgYm71OxNEiQVrKtZAm9oMK
> sHf1DJyyDx5NskNnGwX/nV5XLOn9Potpbd+zi938NesUbkrQGCsfCYarBL3d3zJL
> GcdeKDyr5h6OiFvBOE0wziaomRCilZkc21C7q1vX5dYEKVzNZHatunB/ggjQw67u
> /R0RLJtLaeU84k8XlfUOi6Q1NUzXw6DiVZP83KwVlIlECIxs2mcAGpCwaMVI3g4=
> =nU7s
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Pyro-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pyro-core
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Pyro-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyro-core
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.