orbit-python-list Mailing List for ORBit-Python (Page 9)
Status: Inactive
Brought to you by:
tack
Menu
▾
▴
orbit-python-list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(16) |
Apr
(2) |
May
(5) |
Jun
(2) |
Jul
(1) |
Aug
(61) |
Sep
(10) |
Oct
|
Nov
(31) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(45) |
Feb
(6) |
Mar
(2) |
Apr
(12) |
May
(25) |
Jun
(8) |
Jul
|
Aug
(23) |
Sep
(23) |
Oct
(45) |
Nov
(24) |
Dec
(6) |
| 2002 |
Jan
(34) |
Feb
(24) |
Mar
(5) |
Apr
(4) |
May
(6) |
Jun
(5) |
Jul
(8) |
Aug
(3) |
Sep
(5) |
Oct
|
Nov
(14) |
Dec
|
| 2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(4) |
Aug
(4) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2004 |
Jan
(5) |
Feb
|
Mar
|
Apr
(2) |
May
(3) |
Jun
|
Jul
|
Aug
(4) |
Sep
(4) |
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2005 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Frank R. <Fra...@we...> - 2001-10-03 23:41:01
|
All, why do I need to get an bug-account for reporting a bug? I really get problems to manage all my accounts, will you switch to "passport" **grin** Cheers, Frank -- ------------------------------------------------------------- Frank Rehberger <fre...@cs...> ------------------------------------------------------------- "Global order can arise from local interactions." [A.Turing, 1952] ------------------------------------------------------------- "when all nodes have reached that [stable] state, the whole graph is as dead as a doornail and the diffusing computation is defined to have terminated" [E.W.Dijkstra, 1980] ------------------------------------------------------------- |
|
From: Frank R. <Fra...@we...> - 2001-10-03 22:52:17
|
On Thu, 2001-10-04 at 00:11, Christian Robottom Reis wrote: > On 3 Oct 2001, Frank Rehberger wrote: > > > I got stuck because I cant persuade python-orbit to use INET instead of > > UNIX-sockets, and I cant find a tiny C example that shows me how to > > create a server. > > Are you free to edit orbitrc? You can supply a file like: yes ----------- /etc/orbitrc ----- ORBIIOPIPv4=1 ORBIIOPUSock=0 -- end --- /etc/orbitrc ----- This works, but I assume, after re-login, that the entire GNOME desktop is using this setting now. I did try ./test-server.py -ORBIIOPIPv4=1 -ORBIIOPUSock=0 and also ./test-server.py -ORBIIOPIPv4 1 -ORBIIOPUSock 0 both did not work (orbit-python 0.3, ORBit-0.5.8) > Hey, don't hesitate to write. We don't have a lot of traffic, but it's > supposed to be a friendly list. thanks, it was a prompt help :) > Take care, Cheers, Frank -- ------------------------------------------------------------- Frank Rehberger <fre...@cs...> ------------------------------------------------------------- "Global order can arise from local interactions." [A.Turing, 1952] ------------------------------------------------------------- "when all nodes have reached that [stable] state, the whole graph is as dead as a doornail and the diffusing computation is defined to have terminated" [E.W.Dijkstra, 1980] ------------------------------------------------------------- |
|
From: Christian R. R. <ki...@as...> - 2001-10-03 22:11:51
|
On 3 Oct 2001, Frank Rehberger wrote: > I got stuck because I cant persuade python-orbit to use INET instead of > UNIX-sockets, and I cant find a tiny C example that shows me how to > create a server. Are you free to edit orbitrc? You can supply a file like: - orbitrc --- cut here ---- ORBIIOPIPv4=1 - orbitrc --- cut here ---- and stick it in /usr/local/etc/orbitrc or whereever it is that your system searches by default (could be /etc/orbitrc on other systems IIRC). > 1.) Tell me, why the attached python server does not produce IOR with > INET profile when started as: > ./test-server.py -ORBIIOPUSock=0 Well, don't you need IIOIPv4 too? > As long as I dont have a running server producing INET-profiles, I cant > go on. Hey, don't hesitate to write. We don't have a lot of traffic, but it's supposed to be a friendly list. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL |
|
From: Frank R. <Fra...@we...> - 2001-10-03 21:56:40
|
All, I got stuck because I cant persuade python-orbit to use INET instead of UNIX-sockets, and I cant find a tiny C example that shows me how to create a server. please, perhaps someone can help me: 1.) Tell me, why the attached python server does not produce IOR with INET profile when started as: ./test-server.py -ORBIIOPUSock=0 2.) Or give me a small example server in C that can be compiled doing "configure" "make", and when running produces IOR with INET profiles. currently I am using ORBit-0.5.8, RH7.1-i386 As long as I dont have a running server producing INET-profiles, I cant go on. Cheers, Frank -- ------------------------------------------------------------- Frank Rehberger <fre...@cs...> ------------------------------------------------------------- "Global order can arise from local interactions." [A.Turing, 1952] ------------------------------------------------------------- "when all nodes have reached that [stable] state, the whole graph is as dead as a doornail and the diffusing computation is defined to have terminated" [E.W.Dijkstra, 1980] ------------------------------------------------------------- |
|
From: Christian R. R. <ki...@as...> - 2001-09-30 19:32:52
|
On 29 Sep 2001, Jason Tackaberry wrote: > > ./test-server.py -ORBIIOPUSock=0 > > > > put it still creates unix-sockets, tagged with 0xbadfaeca, who can help > > me. The script is attached. > > These arguments are (should be) just passed along to ORBit. Does it > work when you pass this to a straight ORBit (C) server? If not, it > would be an ORBit bug. I think you can also test this through editing $root/etc/orbitrc -- that way you can see if the parameter is being respected or not. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL |
|
From: Jason T. <ta...@li...> - 2001-09-30 01:40:09
|
> ./test-server.py -ORBIIOPUSock=0 > > put it still creates unix-sockets, tagged with 0xbadfaeca, who can help > me. The script is attached. These arguments are (should be) just passed along to ORBit. Does it work when you pass this to a straight ORBit (C) server? If not, it would be an ORBit bug. Cheers, Jason. |
|
From: Dominik <du...@fa...> - 2001-09-30 00:41:24
|
Hello everyone. For last few days I've been trying to wrap some libOAF functions for use with Python. Everything went flawlessly until it came to execption handling. libOAF calls just return plain CORBA_Evironment and it would be best to just behave as if the call was made in orbit-python, that is raise python exception created by orbit-python during parsing of oaf.idl (import OAF). Therefore I exposed check_corba_ex function into public header (patch included). The problem is that calling it from my module causes python to SEGV soon after. Is there any special semantics connected with this function? Or maybe there is some better way of dealing with CORBA exceptions in C python modules? Regards, Domink. |
|
From: Frank R. <Fra...@we...> - 2001-09-30 00:36:45
|
Hello, ver 0.3x - orbit-0.58 I want to offer a server network wide and need to disable unix-sockets. I tried ./test-server.py -ORBIIOPUSock=0 put it still creates unix-sockets, tagged with 0xbadfaeca, who can help me. The script is attached. cu, Frank |
|
From: Thomas M. <ma...@ma...> - 2001-09-21 03:31:33
|
On Fri, 2001-09-21 at 12:29, Jason Tackaberry wrote: > > the output shows that 'shell' is a CORBA.Object, and that none of the > > evolution/shell methods are available. > > Oh, right. Sorry. :) > > from GNOME import Evolution > > You're fetching an Evolution CORBA object, of course, so you need to > import the IDL for that. > > That should do it. Otherwise I'll let Johan figure it out. :D That's the magic I needed. Thanks a bunch. /mailund -- I believe in God. I just don't trust his ground personnel. |
|
From: Johan D. <zil...@ho...> - 2001-09-21 03:01:37
|
fre 2001-09-21 klockan 04.46 skrev Thomas Mailund:
> On Fri, 2001-09-21 at 12:01, Jason Tackaberry wrote:
> > > Now, my approach to this would be writing something like
> > >
> > > import bonobo
> > > shell = bonobo.get_object("OAFIID:GNOME_Evolution_Shell",
> > > "IDL:GNOME/Evolution/Shell:1.0")
> > >
> > > and then start accessing the evolution shell through 'shell'. The
> > > problem then is, that bonobo.get_object gives me a CORBA.Object, and not
> >
> > Don't forget to import Bonobo too (note the upper case B).
>
> hmm...that, in itself, doesn't quite do it form me. Is there something
> else I need to import or initialize? The program I'm running right now
> is this one:
>
> #!/usr/bin/env python
>
> import bonobo
> import Bonobo
import GNOME.Evolution
instead of Bonobo.
>
> shell = bonobo.get_object("OAFIID:GNOME_Evolution_Shell",
> "IDL:GNOME/Evolution/Shell:1.0")
> print 'shell', shell, dir(shell.__class__)
>
>
> the output shows that 'shell' is a CORBA.Object, and that none of the
> evolution/shell methods are available.
>
> /mailund
>
--
-------------------------------------------------
- Johan Dahlin Address: -
- zi...@as... Nygatan 17, nb -
- zil...@ho... 523 30 Ulricehamn -
- PHONE: +46 (0)321-17559 SWEDEN -
- IRC: zilch @ irc.gnome.org -
-------------------------------------------------
|
|
From: Jason T. <ta...@li...> - 2001-09-21 03:00:48
|
> the output shows that 'shell' is a CORBA.Object, and that none of the > evolution/shell methods are available. Oh, right. Sorry. :) from GNOME import Evolution You're fetching an Evolution CORBA object, of course, so you need to import the IDL for that. That should do it. Otherwise I'll let Johan figure it out. :D Cheers, Jason. |
|
From: Thomas M. <ma...@ma...> - 2001-09-21 02:54:41
|
On Fri, 2001-09-21 at 12:01, Jason Tackaberry wrote:
> > Now, my approach to this would be writing something like
> >
> > import bonobo
> > shell = bonobo.get_object("OAFIID:GNOME_Evolution_Shell",
> > "IDL:GNOME/Evolution/Shell:1.0")
> >
> > and then start accessing the evolution shell through 'shell'. The
> > problem then is, that bonobo.get_object gives me a CORBA.Object, and not
>
> Don't forget to import Bonobo too (note the upper case B).
hmm...that, in itself, doesn't quite do it form me. Is there something
else I need to import or initialize? The program I'm running right now
is this one:
#!/usr/bin/env python
import bonobo
import Bonobo
shell = bonobo.get_object("OAFIID:GNOME_Evolution_Shell",
"IDL:GNOME/Evolution/Shell:1.0")
print 'shell', shell, dir(shell.__class__)
the output shows that 'shell' is a CORBA.Object, and that none of the
evolution/shell methods are available.
/mailund
--
Eagles may soar, but weasels don't get sucked into jet engines.
|
|
From: Jason T. <ta...@li...> - 2001-09-21 02:33:21
|
> Now, my approach to this would be writing something like
>
> import bonobo
> shell = bonobo.get_object("OAFIID:GNOME_Evolution_Shell",
> "IDL:GNOME/Evolution/Shell:1.0")
>
> and then start accessing the evolution shell through 'shell'. The
> problem then is, that bonobo.get_object gives me a CORBA.Object, and not
Don't forget to import Bonobo too (note the upper case B).
Cheers,
Jason.
|
|
From: Thomas M. <ma...@ma...> - 2001-09-21 02:29:55
|
Hi list. I am currently playing around with orbit-python, and decided to
have a look at the bonobo bindings, and as a small project to get
started I wanted to play a bit with Evolution through the bonobo/corba
interface.
Now, my approach to this would be writing something like
import bonobo
shell = bonobo.get_object("OAFIID:GNOME_Evolution_Shell",
"IDL:GNOME/Evolution/Shell:1.0")
and then start accessing the evolution shell through 'shell'. The
problem then is, that bonobo.get_object gives me a CORBA.Object, and not
an object wrapping with an Evolution/Shell interface. Am I on the right
track here? If so, how do I actually access the shell-interface? If not,
how can I get access to the evolution shell by other means?
I am using orbit-python 0.3 and bonobo-python from CVS, btw.
Cheers,
/mailund
--
Keep Smiling Everyone Loves A Moron
|
|
From: Christian R. R. <ki...@as...> - 2001-09-12 13:53:03
|
This looks good to me Jason, though I'm not sure what PortableServer's
final status is. Can we check it in?
On Fri, 7 Sep 2001, Neil Tiffin wrote:
> PortableServermodule.c
> --- PortableServermoduleOld.c Fri Sep 7 07:26:57 2001
> +++ PortableServermodule.c Wed Sep 5 20:07:45 2001
> @@ -1,6 +1,6 @@
> #include "CORBAmodule.h"
>
> -PyObject *servant_base; // PortableServer.Servant
> +extern PyObject *servant_base; // PortableServer.Servant
>
> PyMethodDef PortableServer_methods[] = {
> { NULL, NULL }
>
>
>
> At 8:00 PM -0500 9/5/01, Neil Tiffin wrote:
> >Version 0.3.0 compiles and installs just fine on Mac OS X (10.0.4).
> >however, when I try to run our test programs I get the following
> >error. Can anyone point me to the solution.
> >
> >dyld: python multiple definitions of symbol _servant_base
> >/Volumes/AnagadaII/sw/lib/python2.1/site-packages/CORBAmodule.so
> >definition of _servant_base
> >/Volumes/AnagadaII/sw/lib/python2.1/site-packages/PortableServermodule.so
> >definition of _servant_base
>
>
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL
|
|
From: Brad C. <cha...@ar...> - 2001-09-12 07:30:01
|
Hi Christian; > Brad, I remember you mentioning some testcases, but I dorkishly read the > message with the D key. Can you repost them so we can integrate? Sure, I just had two small demos which showed the Any memory problem and the Boolean "always pass a zero" problem, which are downloadable from: http://www.bioinformatics.org/bradstuff/bc/AnyTest.tar.gz http://www.bioinformatics.org/bradstuff/bc/BooleanTest.tar.gz Feel free to use 'em at will, and let me know if there are problems or anything else you need. Brad |
|
From: Christian R. R. <ki...@as...> - 2001-09-12 03:44:45
|
When we import CORBA, __import__ becomes broken because raw strings are passed in, and not objects, and also because the parameter handling is a bit different. My attached patch tries to solve it; i'd like a review if it looks sane enough or not. Does anywhere/one else expect auto_load_module_idls to take a PyObject parameter instead of a string? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL |
|
From: Christian R. R. <ki...@as...> - 2001-09-11 20:28:25
|
Brad, I remember you mentioning some testcases, but I dorkishly read the message with the D key. Can you repost them so we can integrate? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL |
|
From: Jason T. <ta...@li...> - 2001-09-07 18:58:32
|
> I also took a gander into the code for this one and came up with a > proposed patch to the demarshalling code, which is attached. > Basically, this defines the returned value as being a CORBA_short > instead of CORBA_octet. The patch is a simple one-liner, but the > same caveats apply as in my previous message. Or more correctly it should be CORBA_boolean. Someone from Nokia reported a problem that led me to fix this bug. Unfortunately your report was a lot more concise. :) Anyway, it has been fixed in CVS since shortly after 0.3.0's release and will be included in 0.3.1, whenever I manage to find the time to release. Cheers, Jason. |
|
From: Jason T. <ta...@li...> - 2001-09-07 18:53:58
|
> Basically, I Py_INCREF the tc and value before returning them, which > I think accounts for the reference the calling code will get. But, > than again, I'm no expert :-). Yes, this is correct. I'll merge the patch tonight. Sorry I took so long to reply -- I had a busy week at work. :) Thanks for the fix! Cheers, Jaosn. |
|
From: Neil T. <nt...@ea...> - 2001-09-07 12:52:09
|
I think I solved this problem by adding "extern" to the definition of
servant_base. I have no idea if this is a proper fix, did not
research the source code and have not tested it extensively.
But orbit-python does now work for accessing our GEAS server from
python using our IDL.
Please check and see if this is the correct way to solve this problem.
Here is the diff.
Thank you.
PortableServermodule.c
--- PortableServermoduleOld.c Fri Sep 7 07:26:57 2001
+++ PortableServermodule.c Wed Sep 5 20:07:45 2001
@@ -1,6 +1,6 @@
#include "CORBAmodule.h"
-PyObject *servant_base; // PortableServer.Servant
+extern PyObject *servant_base; // PortableServer.Servant
PyMethodDef PortableServer_methods[] = {
{ NULL, NULL }
At 8:00 PM -0500 9/5/01, Neil Tiffin wrote:
>Version 0.3.0 compiles and installs just fine on Mac OS X (10.0.4).
>however, when I try to run our test programs I get the following
>error. Can anyone point me to the solution.
>
>dyld: python multiple definitions of symbol _servant_base
>/Volumes/AnagadaII/sw/lib/python2.1/site-packages/CORBAmodule.so
>definition of _servant_base
>/Volumes/AnagadaII/sw/lib/python2.1/site-packages/PortableServermodule.so
>definition of _servant_base
--
Neil
ne...@gn...
GNU Enterprise
http://www.gnuenterprise.org/
http://www.gnuenterprise.org/~neilt/sc.html
|
|
From: Neil T. <nt...@ea...> - 2001-09-06 01:01:16
|
Version 0.3.0 compiles and installs just fine on Mac OS X (10.0.4). however, when I try to run our test programs I get the following error. Can anyone point me to the solution. dyld: python multiple definitions of symbol _servant_base /Volumes/AnagadaII/sw/lib/python2.1/site-packages/CORBAmodule.so definition of _servant_base /Volumes/AnagadaII/sw/lib/python2.1/site-packages/PortableServermodule.so definition of _servant_base Thank you. -- Neil ne...@gn... GNU Enterprise http://www.gnuenterprise.org/ http://www.gnuenterprise.org/~neilt/sc.html |
|
From: Christian R. R. <ki...@as...> - 2001-09-04 09:49:52
|
On Tue, 4 Sep 2001, Brad Chapman wrote: > I dug into the code on this, and came up with a proposed patch. The > patch seems to fix the problem (in both my test case and my real > code), but I'm definately not a C expert so someone smarter than I > will have to check it out to see if it causes memory leaks, etc. Apart from the indenting (which should be consistent) this looks smart, r=kiko. Tack? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL |
|
From: Christian R. R. <ki...@as...> - 2001-09-04 09:48:37
|
On Tue, 4 Sep 2001, Brad Chapman wrote: > Hmmm, I'm not exactly sure if this is what you want, but the > attached script will cause the seg-fault with the IDL I posted. I'm > not sure if you want seg-faulting scripts in the Test Suite though It's exactly what I want. Test scripts that SEGV are the latest fashion in ORBit-Python; I've just discovered another three last week with using __import__() after an import CORBA. That's fun. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL |
|
From: Brad C. <cha...@ar...> - 2001-09-04 09:09:48
|
Hello again; Sorry for flooding everyone's boxes -- I guess I shouldn't have saved all of my patches to send all at once :-). While working, I also ran into a problem with boolean values. Basically, ORBit-python seemed to always return zero to the client, independent of the value passed in at the server side. I cooked up an example client and server which demonstrates the problem: http://www.bioinformatics.org/bradstuff/bc/BooleanTest.tar.gz I also took a gander into the code for this one and came up with a proposed patch to the demarshalling code, which is attached. Basically, this defines the returned value as being a CORBA_short instead of CORBA_octet. The patch is a simple one-liner, but the same caveats apply as in my previous message. HTH, Brad |
26 messages has been excluded from this view by a project administrator.
