F.C | 28 Aug 00:05 2014
Picon

serpent serialization

Hi!!


I can't  use Pyro, the pyro remote server is working well, but when i try to connect the client :

flame=Pyro4.utils.flame.connect("192.168.1.72:64444")

i have this error:

Pyro4.errors.ProtocolError: serializer 'serpent' is unknown or not available


------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
Pyro-core mailing list
Pyro-core@...
https://lists.sourceforge.net/lists/listinfo/pyro-core
Irmen de Jong | 7 Aug 23:36 2014
Picon

Pyro 4.27 released! Massive update


Hi,

Pyro 4.27 has just been released!
It's a massive update so the .01 version bump is a bit deceiving.

Get it from Pypi:  http://pypi.python.org/pypi/Pyro4/
Or straight from Github:  https://github.com/irmen/Pyro4
Documentation: http://pythonhosted.org/Pyro4/index.html

Most important new features in this version:

added  <at> Pyro4.expose and  <at> Pyro4.oneway decorators
remote attribute access works on the proxy and also actually honors 'private'
attributes (and methods) in all cases (names starting with underscore)
automatic metadata query: proxy asks server for metadata about the object (methods,
attributes)
this means you no longer have to set _pyroOneway yourself, support for this will be
dropped in the next version
the expose decorator can be used to selectively expose only certain methods. This
does require setting REQUIRE_EXPOSE config item to true (it's not enabled by default
to remain backwards compatible)
DOTTEDNAMES is deprecated and will be removed in the next version
setup script now generates a bunch of console commands such as 'pyro4-ns'
(previously you had to type 'python -m Pyro4.naming' etc.)
requires serpent 1.7 or newer

Exhaustive list of changes can be found in the change log, as usual.

Have fun!

Irmen de Jong
Nicco Kunzmann | 19 Jul 15:02 2014
Picon

Sample Project with Pyro, Pyrolite, C#, Java, Python

Hello,

in a seminar about components and middleware we created a 'slim breakout' version with Pyro.
We successfully used Pyrolite and Pyro with C#, Java and Python. https://github.com/niccokunzmann/ping/
We had a presentation and a discussion about our implementation.
Maybe you can use it to see where we had struggles.

If you have any questions, contact me,
greetings,
Nicco
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Pyro-core mailing list
Pyro-core@...
https://lists.sourceforge.net/lists/listinfo/pyro-core
Justin M Wozniak | 18 Jul 17:57 2014

Trouble with getitem

Hi
     I'm having trouble with Pyro and the getitem syntax.  I am 
basically trying to use __getitem__ on the proxy.  A stand-alone test is 
attached.

In short, the server class has:
     def __getitem__(self, key):
         message("__getitem__")
         return self.getitem(key)

and the client has:
     proxy = Pyro4.Proxy(uri)
     value3 = proxy[key3]

which results in:
TypeError: 'Proxy' object has no attribute '__getitem__'

If anyone can help me get this working it would be greatly appreciated.

     Thanks
     Justin

--

-- 
Justin M Wozniak

Attachment (TestClient1.py): text/x-python, 1250 bytes
Attachment (TestService1.py): text/x-python, 1150 bytes
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Pyro-core mailing list
Pyro-core@...
https://lists.sourceforge.net/lists/listinfo/pyro-core
obrien | 17 Jul 02:52 2014
Picon

(no subject)

Please remove me from your distribution list. I've asked at least twice.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Pyro-core mailing list
Pyro-core@...
https://lists.sourceforge.net/lists/listinfo/pyro-core
Steven Pav | 16 Jul 19:50 2014
Picon

Running Pyro (nameserver for now) in a Docker container

Hello;

I am excited to start using Pyro4. To ease deployment in our organization, I 
plan on running services in Docker containers (see http://docker.io/ or 
http://continuousdelivery.uglyduckling.nl/uncategorized/using-docker-as-a-
python-development-environment/ ). To start, I tried to deploy the nameserver 
in a docker container. However, I am unable to locate the nameserver once it 
is running. I believe this might be related to some of the issues noted in 
this post: http://comments.gmane.org/gmane.comp.python.pyro/2490 , namely 
that the nameserver running within the docker container has funny ideas about 
the name of the localhost, or what port it should be listening on, etc. 

As a MWE, I have posted the Dockerfile and some shell code to run it here: 
https://gist.github.com/shabbychef/72657f769eba7ddeed9d . When I run it, I 
can confirm that the container with the nameserver is running, however, I 
cannot communicate with it, rather I get the error:

  Failed to locate the name server: Failed to locate the nameserver

Any help debugging this would be appreciated. 

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Irmen de Jong | 16 Jul 02:24 2014
Picon

getting rid of DOTTEDNAMES ?

Hi,

During the implementation of the new  <at> decorators and direct attribute access, I've run
into some more issues regarding DOTTEDNAMES.
That feature (disabled by default) doesn't play well with direct attribute access. That
gives you a local copy of the attribute's value so writing something like this:

	proxy.attr.update("new value")

will actually invoke update() on the local copy instead of on the attribute in the
remote object.

This may look silly at first, but if you think of the semantics of directly accessing
the remote attribute's value, it makes sense. Without that feature you'll have to write
a getter method and call that:

	proxy.get_attr().update("new value")

This *also* retrieves a local copy of the attribute value and will call update() on the
local copy instead of the remote.

The only way to directly update the remote attribute's value is to not use the new
metadata system, and setting DOTTEDNAMES to True (or be sane and write an updater
method). In other words, DOTTEDNAMES is only working when the new Metadata feature is
disabled (which it won't be by default).

Also, as you know, enabling DOTTEDNAMES opens up a serious security hole in the server.

(and finally, a theoretical issue; enabling DOTTEDNAMES allows you to break the Law of
Demeter on your remote interfaces)

Bottom line: I want to get rid of DOTTEDNAMES altogether when rolling out the new
metadata feature. It's just too much trouble.

Thoughts? Anyone actually using it?

Irmen

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
Giovanni Porcari | 9 Jul 17:55 2014
Picon

HMAC_KEY server based

Hi Irmen

some month ago i asked you about the possibility to have a different HMAC_KEY 
for each server and not just one based on PYRO config.

I sent you also a possible way to implement it but at this time you was 
not sure about the future of HMAC_key feature.

I think that you use pyro in many server and you have to connect to
more than one in the same context it is not possible unless you use
the same hmac_key.

Do you have now some more thoughts about this problem ?

We created, using pyro4, a session manager to replace the previous
memcached backend. It works very well and in many months of 
work in many server we never had a problem.
So thank you again for your brilliant work :)

G
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Mayavimmer | 8 Jul 16:30 2014
Picon

Some feedback and a few suggestions

Working from the assumption (hehehe) that other people might stumble on 
the same gotchas that tripped me up (see other thread), here are a few 
things that would have saved me several hours and much frustration:

1. An example of a server with explicit IP address (not localhost).
2. An exact equivalence between SimpleServer and the explicit calls to 
the Daemon contructor with host parameter, daemon.register, ns.register. 
(This clears up the business of having the IP included in the published 
name, which CANNOT be set there, but in the Daemon constructor!)

3. Daemon and NameServer not having the same method name "register".
4. An example of how to persist a Pyro object with Shelve or ZODB or other.

5. An example of how a client could disconnect cleanly. Though I suspect 
a solution exists somewhere buried in the examples.

Mayavimmer

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Mayavimmer | 7 Jul 19:31 2014
Picon

Persistent Pyro

I am trying to persist a Pyro4 object. I modified the Warehouse example 
to try to store to a Shelve store. My strategy is to duplicate the 
Warehouse instance when it comes time to save it, creating a non 
Pyroized copy which can the be saved. Here are the steps:

1. Created a Warehouse.dup() with:
     n = Warehouse()
     n.contents[:] = self.contents
     return n

2. def save: # calls dup() and stores its non-Pyroized true Warehouse 
instance into the Shelve object.

3. def store: # if name == 'quit', save etc.

Problem: I now get: ConnectionClosedError: receiving: not enough data
The server undoubtedly attempted to close the connection while the 
client held a live instance of Warehouse.

How do I shut down cleanly?

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
Irmen de Jong | 7 Jul 02:09 2014
Picon

metadata and decorators are coming your way

Hi,

I've just checked in the first batch of changes for Pyro 4.27 where a new feature is
coming: object metadata querying.

This means that the the client (proxy) can ask the server about the methods and
attributes of the remote object. This query is done when the proxy is bound (connected).
For now, only the oneway methods are actually doing something: you don't have to
manually set _pyroOneway all the time on your proxy anymore!

I also want to add some extra features based on this. For instance the method names
could be used for client-side error checking on invalid method calls, and perhaps the
attribute names can be used to implement truly transparent remote attribute access again
(like we had in Pyro 3.x) - but no promises there.

For the oneway method metadata there's a new decorator  <at> Pyro4.oneway that you can use on
the methods in your remote object, to mark them. I expect to add some more decorators,
see issue #44 on github.

If you have the time please check it out in the trunk version and let me know if you
have questions or ideas about all this!

Cheers

Irmen

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft

Gmane