clorb-devel Mailing List for Common Lisp ORB
Status: Alpha
Brought to you by:
lenst
Menu
▾
▴
clorb-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: Lennart S. <le...@ly...> - 2007-10-20 06:51:07
|
James Amundson wrote:
> Clorb doesn't seem to support forward references. For example, I need
> something to do simple like
>
> module Simple {
> union ToySexpr;
> typedef sequence<ToySexpr> list;
> union ToySexpr switch(short) {
> case 1:string atom_val;
> case 2:list list_val;
> };
> };
>
> Clorb dies on the foward reference ("union ToySexpr;"). I don't see any
> way to work around the problem without resorting to using "any".
>
> Is there any chance of getting Clorb to understand forward references?
> I would be happy to try to fix it myself if I could get a little
> direction on where to start.
>
I think this has been fixed after the latest release. Can you try CLORB
from the CVS repository
http://sourceforge.net/projects/clorb/
cvs -d:pserver:ano...@cl...:/cvsroot/clorb login
cvs -z3 -d:pserver:ano...@cl...:/cvsroot/clorb co
-P /clorb
//Lennart Staflin
/
|
|
From: James A. <amu...@fn...> - 2007-10-20 02:43:16
|
Hi,
Clorb doesn't seem to support forward references. For example, I need
something to do simple like
module Simple {
union ToySexpr;
typedef sequence<ToySexpr> list;
union ToySexpr switch(short) {
case 1:string atom_val;
case 2:list list_val;
};
};
Clorb dies on the foward reference ("union ToySexpr;"). I don't see any
way to work around the problem without resorting to using "any".
Is there any chance of getting Clorb to understand forward references?
I would be happy to try to fix it myself if I could get a little
direction on where to start.
Best,
Jim Amundson
|
|
From: Green B. - b. <Bry...@ac...> - 2006-12-24 22:42:48
|
Hmmm, I'll see what I can do. I'll let you know if I get it to work and wh= at is the work-around. -----Original Message----- From: Lennart Staflin on behalf of Lennart Staflin Sent: Sun 12/24/2006 10:27 AM To: Green Bryan - bgreen Cc: clo...@li... Subject: Re: [Clorb-devel] Win32 =20 On 24 dec 2006, at 15:56, Green Bryan - bgreen wrote: > Hello, > I am trying to use CLISP-2.41 with CLORB_0.7. I get the orb =20 > initialized fine. My problem is when I try to > > (corba:idl "syph.idl") > > I get > > Win32 error 2 (ERROR_FILE_NOT_FOUND): The system cannot find the =20 > file specified. > [Condition of type SYSTEM::SIMPLE-OS-ERROR] > That part might be a bit tricky to get working on win32. The IDL =20 parsing uses the systems C pre-processor (cpp), thats probably what =20 is missing. I don't know if there is a cpp as standard, perhaps =20 cygwin or something like that has a cpp. > Backtrace: > 0: #<COMPILED-FUNCTION NET.CDDR.CLORB.INTERNALS:USING-CPP-STREAM> > 1: #<COMPILED-FUNCTION NET.CDDR.CLORB::USING-IDLLEX> > 2: #<COMPILED-FUNCTION #:|783 788 (DEFMETHOD LOAD-REPOSITORY (# =20 > REPOSITORY FILE) ...)-90-1-1|> > 3: #<COMPILED-FUNCTION OMG.ORG/CORBA:IDL> > [...] > > > Any help would be greatly appreciated. > > Bryan Green > //Lennart Staflin ************************************************************************* The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are=20 hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. ************************************************************************* |
|
From: Lennart S. <le...@ly...> - 2006-12-24 16:28:08
|
On 24 dec 2006, at 15:56, Green Bryan - bgreen wrote: > Hello, > I am trying to use CLISP-2.41 with CLORB_0.7. I get the orb > initialized fine. My problem is when I try to > > (corba:idl "syph.idl") > > I get > > Win32 error 2 (ERROR_FILE_NOT_FOUND): The system cannot find the > file specified. > [Condition of type SYSTEM::SIMPLE-OS-ERROR] > That part might be a bit tricky to get working on win32. The IDL parsing uses the systems C pre-processor (cpp), thats probably what is missing. I don't know if there is a cpp as standard, perhaps cygwin or something like that has a cpp. > Backtrace: > 0: #<COMPILED-FUNCTION NET.CDDR.CLORB.INTERNALS:USING-CPP-STREAM> > 1: #<COMPILED-FUNCTION NET.CDDR.CLORB::USING-IDLLEX> > 2: #<COMPILED-FUNCTION #:|783 788 (DEFMETHOD LOAD-REPOSITORY (# > REPOSITORY FILE) ...)-90-1-1|> > 3: #<COMPILED-FUNCTION OMG.ORG/CORBA:IDL> > [...] > > > Any help would be greatly appreciated. > > Bryan Green > //Lennart Staflin |
|
From: Green B. - b. <Bry...@ac...> - 2006-12-24 14:56:16
|
Hello, I am trying to use CLISP-2.41 with CLORB_0.7. I get the orb initialized= fine. My problem is when I try to =20 (corba:idl "syph.idl") =20 I get=20 =20 Win32 error 2 (ERROR_FILE_NOT_FOUND): The system cannot find the file speci= fied. [Condition of type SYSTEM::SIMPLE-OS-ERROR] =20 Backtrace: 0: #<COMPILED-FUNCTION NET.CDDR.CLORB.INTERNALS:USING-CPP-STREAM> 1: #<COMPILED-FUNCTION NET.CDDR.CLORB::USING-IDLLEX> 2: #<COMPILED-FUNCTION #:|783 788 (DEFMETHOD LOAD-REPOSITORY (# REPOSITOR= Y FILE) ...)-90-1-1|> 3: #<COMPILED-FUNCTION OMG.ORG/CORBA:IDL> 4: #<SYSTEM-FUNCTION EVAL> 5: #<COMPILED-FUNCTION SWANK::EVAL-REGION> 6: #<COMPILED-FUNCTION SWANK::LISTENER-EVAL-1> 7: #<COMPILED-FUNCTION #:|281 283 (DEFINTERFACE CALL-WITH-SYNTAX-HOOKS (F= N) ...)-32-3-1-1|> 8: #<COMPILED-FUNCTION SWANK::CALL-WITH-BUFFER-SYNTAX> 9: #<COMPILED-FUNCTION SWANK:LISTENER-EVAL> 10: #<SYSTEM-FUNCTION EVAL> 11: #<COMPILED-FUNCTION SWANK::EVAL-FOR-EMACS-1> 12: #<COMPILED-FUNCTION #:|480 485 (DEFINTERFACE CALL-WITH-DEBUGGER-HOOK (= HOOK FUN) ...)-53-3-1-1|> 13: #<COMPILED-FUNCTION SWANK::EVAL-FOR-EMACS> 14: #<COMPILED-FUNCTION SWANK::READ-FROM-EMACS> 15: #<COMPILED-FUNCTION SWANK::HANDLE-REQUEST-1> 16: #<COMPILED-FUNCTION #:|480 485 (DEFINTERFACE CALL-WITH-DEBUGGER-HOOK (= HOOK FUN) ...)-53-3-1-1|> 17: #<COMPILED-FUNCTION SWANK::CALL-WITH-CONNECTION-1> 18: #<COMPILED-FUNCTION SWANK::CALL-WITH-REDIRECTED-IO> 19: #<COMPILED-FUNCTION SWANK::MAYBE-CALL-WITH-IO-REDIRECTION> 20: #<COMPILED-FUNCTION SWANK::CALL-WITH-CONNECTION> 21: #<COMPILED-FUNCTION SWANK::HANDLE-REQUEST> 22: #<COMPILED-FUNCTION SWANK::SIMPLE-SERVE-REQUESTS-2> 23: #<COMPILED-FUNCTION SWANK::SIMPLE-SERVE-REQUESTS> 24: #<COMPILED-FUNCTION SWANK::SERVE-REQUESTS> 25: #<COMPILED-FUNCTION SWANK::SERVE-CONNECTION> 26: #<COMPILED-FUNCTION SWANK::SETUP-SERVER-SERVE> 27: #<COMPILED-FUNCTION SWANK::SETUP-SERVER> 28: #<COMPILED-FUNCTION SWANK:START-SERVER> 29: #<SYSTEM-FUNCTION SYSTEM::READ-EVAL-PRINT>=20 =20 =20 Any help would be greatly appreciated. =20 Bryan Green =20 =20 *************************************************************************** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. **************************************************************************** |
|
From: Eric M. <ema...@la...> - 2003-07-31 17:33:33
|
>>>>> "ls" == Lennart Staflin <le...@ly...> writes: ls> I had a look at print-object for CORBA:Proxy uses object-id when it ls> should be using proxy-id. The "IDL:omg.org/CORBA/Object:1.0" is not ls> the ID that came with the reference. thanks, I have patched this. ls> 2. the interface repository has objects of types not known to the ls> CLORB implementation, perhaps it implements a repository from some ls> later corba version. this seems to be it: the interface repository contains a LocalInterfaceDef, and the file clorb-ifr-base.lisp doesn't have a definition for this (I can't remember when local interfaces were added to CORBA, but it was quite a while ago). I take it that clorb-ifr-base and ifr-idl are generated from the files in the idl/ directory, using the new IDL parser? I tried to use CORBA:IDL to generate lisp definitions for IDL files from ORBacus, but the IDL parser also doesn't recognize local interfaces; it chokes on the "local" bit of a definition like ,---- | local interface Policy | { | readonly attribute PolicyType policy_type; | Policy copy(); | void destroy(); | }; `---- I guess I'll have to figure out how the parser is generated from the IDL grammar. Thanks, -- Eric Marsden <URL:http://www.laas.fr/~emarsden/> |
|
From: Lennart S. <le...@ly...> - 2003-07-30 21:28:33
|
On m=E5ndag, jul 28, 2003, at 11:24 Europe/Stockholm, Eric Marsden = wrote: > I tried to use DOWNLOAD-IR to populate the local repository, and ran > into the following error: > > No matching method for the generic function=20 > #<standard-generic-function omg.org/features:def_kind (19) > = {489E8C39}>, > when called with arguments (#<omg.org/corba:proxy=20 > "IDL:omg.org/CORBA/Object:1.0" @hobart.laas.fr:39513>). > [Condition of type pcl::no-applicable-method-error] > Inspecting the OP:DEF_KIND generic function tells me that it has the > following methods: > > ,---- > | Its methods are: > [...] > | 19: def_kind ((clorb::obj omg.org/corba:irobject-proxy) &rest=20 > clorb::-args-) > `---- > Is a method missing somewhere? This is with CMUCL, and CLORB from > CVS, and I'm building using my own ASDF defsystem. I think you got everything loaded, the 19th method is the one that=20 should have been used, but the object is a generic proxy instead of a=20 proxy for the particular IR object. Unfortunately CLORB is a bit lax in=20= error reporting when unmarshalling object references. You get a generic=20= proxy if there is not proxy class for the object type or if the object=20= reference lacks type info (and there is no type info from the interface=20= returning the object.) I had a look at print-object for CORBA:Proxy uses object-id when it=20 should be using proxy-id. The "IDL:omg.org/CORBA/Object:1.0" is not the=20= ID that came with the reference. I can see at least two explanations 1. the interface repository returns object references with missing (or=20= incomplete) type info, or 2. the interface repository has objects of types not known to the CLORB=20= implementation, perhaps it implements a repository from some later=20 corba version. You could try to inspect the proxy object to see what the ID slot=20 contains or fix print-object to use proxy-id instead of object-id. Earlier versions of download-ir might have used Dynamic Invocation=20 instead of static stubs as the current version does. That would=20 probably have worked with any version of the interface repository.=20 Ironic :) You could also try loading make-proxies.lisp and see if it works then. //Lennart |
|
From: Eric M. <ema...@la...> - 2003-07-28 09:24:59
|
Hi, I tried to use DOWNLOAD-IR to populate the local repository, and ran into the following error: No matching method for the generic function #<standard-generic-function omg.org/features:def_kind (19) {489E8C39}>, when called with arguments (#<omg.org/corba:proxy "IDL:omg.org/CORBA/Object:1.0" @hobart.laas.fr:39513>). [Condition of type pcl::no-applicable-method-error] Inspecting the OP:DEF_KIND generic function tells me that it has the following methods: ,---- | Its methods are: | 1: def_kind ((clorb::x clorb::fixed-def) &rest clorb::-args-) | 2: def_kind ((clorb::x clorb::array-def) &rest clorb::-args-) | 3: def_kind ((clorb::x clorb::sequence-def) &rest clorb::-args-) | 4: def_kind ((clorb::x clorb::wstring-def) &rest clorb::-args-) | 5: def_kind ((clorb::x clorb::string-def) &rest clorb::-args-) | 6: def_kind ((clorb::x clorb::primitive-def) &rest clorb::-args-) | 7: def_kind ((clorb::x clorb::exception-def) &rest clorb::-args-) | 8: def_kind ((clorb::x clorb::enum-def) &rest clorb::-args-) | 9: def_kind ((clorb::x clorb::union-def) &rest clorb::-args-) | 10: def_kind ((clorb::x clorb::struct-def) &rest clorb::-args-) | 11: def_kind ((clorb::x clorb::alias-def) &rest clorb::-args-) | 12: def_kind ((clorb::x clorb::typedef-def) &rest clorb::-args-) | 13: def_kind ((clorb::x clorb::operation-def) &rest clorb::-args-) | 14: def_kind ((clorb::x clorb::attribute-def) &rest clorb::-args-) | 15: def_kind ((clorb::x clorb::interface-def) &rest clorb::-args-) | 16: def_kind ((clorb::x clorb::constant-def) &rest clorb::-args-) | 17: def_kind ((clorb::x clorb::module-def) &rest clorb::-args-) | 18: def_kind ((clorb::x clorb::repository) &rest clorb::-args-) | 19: def_kind ((clorb::obj omg.org/corba:irobject-proxy) &rest clorb::-args-) `---- Is a method missing somewhere? This is with CMUCL, and CLORB from CVS, and I'm building using my own ASDF defsystem. -- Eric Marsden <URL:http://www.laas.fr/~emarsden/> |
|
From: Eric M. <ema...@la...> - 2003-06-17 16:20:28
|
Hi, In the file clorb-marshal.lisp, function MARSHAL-ALIGN has a second alignment argument declared to be (integer 0 8). The longdouble case in the MARSHAL function calls MARSHAL-NUMBER with a requested alignment of 16, which is passed on to MARSHAL-ALIGN. I guess that the type declaration is incorrect? -- Eric Marsden <URL:http://www.laas.fr/~emarsden/> |
|
From: Eric M. <ema...@la...> - 2002-03-27 15:12:25
|
Hi, I am trying to use CLORB to push untyped events of type struct to the EventService. I use code like the following, which results in a marshalling exception raised by the server. Any ideas whether marshalling of structs into anys works correctly? ,---- | (let ((event-channel (resolve "MyEventChannel"))) | (let ((in-adm (invoke event-channel "for_suppliers"))) | (let ((out (invoke in-adm "obtain_push_consumer")) | (data (CORBA:Any :any-typecode CORBA:tc_struct | :any-value (make-struct "IDL:Time/TimeVal:1.0" | :seconds 4 | :microseconds 2 | :counter 666)))) | (invoke out "connect_push_supplier" nil) | (invoke out "push" data) | (invoke out "disconnect_push_supplier"))))) `---- Thanks, -- Eric Marsden <URL:http://www.laas.fr/~emarsden/> |
|
From: Lennart S. <le...@ly...> - 2001-08-06 14:49:34
|
On 26 Jul 2001, Eric Marsden wrote: > Interfaces declared locally (using the IDEF-DEFINITION macros) are > stored in *IDEF-REPOSITORY*. When constructing a request against an > interface, IR-LOOKUP-ID is called, even if that interface was defined > locally in *IDEF-REPOSITORY*. Is there a reason why it doesn't start > by querying the local repository? The IDEF stuff and the interface repository implementation is a bit experimental yet and not all that well intergrated with the rest. The auto-servant class will use the *IDEF-REPOSITORY* i think... //Lennart |
|
From: Eric M. <ema...@la...> - 2001-07-26 16:10:24
|
Hi, Interfaces declared locally (using the IDEF-DEFINITION macros) are stored in *IDEF-REPOSITORY*. When constructing a request against an interface, IR-LOOKUP-ID is called, even if that interface was defined locally in *IDEF-REPOSITORY*. Is there a reason why it doesn't start by querying the local repository? -- Eric Marsden <URL:http://www.laas.fr/~emarsden/> |
|
From: Lennart S. <le...@ly...> - 2001-06-26 16:14:40
|
Not much new in this release. I plan some major rewrite of I/O in CLORB and the CVS will be very unstable the next few months. -- Lennart Staflin <le...@ly...> |
|
From: Eric M. <ema...@ma...> - 2001-05-10 12:17:50
|
>>>>> "ls" == Lennart Staflin <le...@ly...> writes: ecm> However, the ir.dump file doesn't contain any definitions for ecm> exceptions in the IDL interfaces, so I still get calls to ecm> IR-LOOKUP-ID and thus to the external IR whenever an exception ecm> needs to be resolved. Is the problem in IR-ADD-ALL? ls> Yes, it does not recurese into interfaces and it does not store ls> the typecodes into the iir correctly. I have commited a fixed ls> version of loadup.lisp into the sourceforge CVS. the new version works, many thanks. BTW, in clorb-options.lisp the variable *host* still defaults to "127.0.0.1"; I assume this won't work when sending an IOR to a distant machine. I use ,---- | (defparameter *host* | #+(or cmu sbcl) | (unix:unix-gethostname) | #+clisp | (let ((mi (machine-instance))) | (subseq mi 0 (position #\Space mi)))) `---- -- Eric Marsden <URL:http://www.laas.fr/~emarsden/> |
|
From: Lennart S. <le...@ly...> - 2001-05-10 06:32:21
|
Eric Marsden wrote: > I would like to use CLORB only with a local interface repository. I > have created an ir.dump file with > > (download-ir) > (save-ir) > > and then during application initialization I read the repository with > > (load-ir) > > However, the ir.dump file doesn't contain any definitions for > exceptions in the IDL interfaces, so I still get calls to IR-LOOKUP-ID > and thus to the external IR whenever an exception needs to be > resolved. Is the problem in IR-ADD-ALL? Yes, it does not recurese into interfaces and it does not store the typecodes into the iir correctly. I have commited a fixed version of loadup.lisp into the sourceforge CVS. //Lennart |
|
From: Eric M. <ema...@ma...> - 2001-05-03 13:07:45
|
Hi, I would like to use CLORB only with a local interface repository. I have created an ir.dump file with (download-ir) (save-ir) and then during application initialization I read the repository with (load-ir) However, the ir.dump file doesn't contain any definitions for exceptions in the IDL interfaces, so I still get calls to IR-LOOKUP-ID and thus to the external IR whenever an exception needs to be resolved. Is the problem in IR-ADD-ALL? -- Eric Marsden <URL:http://www.laas.fr/~emarsden/> |
|
From: Eric M. <ema...@ma...> - 2000-07-04 16:25:46
|
>>>>> "ls" == Lennart Staflin <le...@ly...> writes: ecm> ok, I think the problem is in the CMUCL definition of ecm> read-sequence on socket streams. After replacing it by a simple ecm> version, everything works as expected. ls> Does it depend on the CMUCL version. The CMU Common Lisp release ls> x86-linux 2.4.19 8 February 2000 build 455, works fine for me on ls> Linux x86. I don't know; I only have access to CMUCL on Solaris. I reported the problem to the CMUCL maintainers, who have confirmed that it is a bug. You may not see it on Linux: the problem seems to be that #'read-sequence is mapped to a read(), so if the platform read() is able to keep up with the socket you won't see the problem. -- Eric Marsden <URL:http://www.laas.fr/~emarsden> |
|
From: Lennart S. <le...@ly...> - 2000-07-04 15:27:42
|
Eric Marsden <ema...@ma...> writes: > >>>>> "ecm" == Eric Marsden <ema...@ma...> writes: > > ecm> I get the same error whether using native CMUCL sockets, or my > ecm> Solaris port of db-sockets. > > ok, I think the problem is in the CMUCL definition of read-sequence on > socket streams. After replacing it by a simple version, everything > works as expected. Does it depend on the CMUCL version. The CMU Common Lisp release x86-linux 2.4.19 8 February 2000 build 455, works fine for me on Linux x86. -- Lennart Staflin <le...@ly...> |
|
From: Eric M. <ema...@ma...> - 2000-07-01 17:11:21
|
>>>>> "ecm" == Eric Marsden <ema...@ma...> writes:
ecm> I get the same error whether using native CMUCL sockets, or my
ecm> Solaris port of db-sockets.
ok, I think the problem is in the CMUCL definition of read-sequence on
socket streams. After replacing it by a simple version, everything
works as expected.
(defun my-read-sequence (sequence stream &key (start 0) (end nil))
(unless end (setq end (length sequence)))
(do ((index start (1+ index)))
((eql index end) index)
(let ((b (read-byte stream nil :eof)))
(when (eq b :eof) (return index))
(setf (aref sequence index) b))))
There are two calls to read-sequence in clorb-request.lisp to change.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden>
|
|
From: Eric M. <ema...@ma...> - 2000-07-01 14:47:46
|
>>>>> "bc" == Brad Chapman <cha...@ar...> writes: bc> ; Loading #p"/usr/home/chapmanb/clorb-0.2/test-intern.lisp". bc> Warning: This variable is undefined: bc> *R bc> Warning: This function is undefined: bc> INTERNALIZE you need to (load "internalize") before running that test. bc> Could the problem be due to sockets? (since that seems to be a bc> sticking point with the clisp server). The error didn't really bc> seem like it, but I am also still working on getting Dan bc> Barlow's socket code working on FreeBSD, so I am using whatever bc> socket capabilities cmu cl has. Just a random idea because I'm bc> not positive where to go. To talk myself out of that, if Eric bc> has this problem as well, this may not be the case. I get the same error whether using native CMUCL sockets, or my Solaris port of db-sockets. bc> *** - UNIX error 49 (EADDRNOTAVAIL): Can't assign requested bc> address as Lennart said, my idea of the socket already being in use was probably wrong. The error could come from trying to bind to a socket on an address which doesn't belong to the local machine. I don't think the error is in CLORB, since it just does (socket-server port); maybe it's a problem with CLISP. You might be able to find out what's going on using strace. -- Eric Marsden <URL:http://www.laas.fr/~emarsden> |
|
From: Brad C. <cha...@ar...> - 2000-06-30 20:43:20
|
[..snip...server traces from cmu cl...]
> This is from make-string. It must be LEN that is -1. And it must be
> the operation name it is trying to unmarshal. I can't figure out why
> the length is -1.
>
> What kind of machine and OS are you running on?
I'm running this on FreeBSD 3.3 and with CMU CL 18b and clisp
2000-03-06.
> Could you try and load the "test-marshal.lisp" and see if it
produces any
> errors?
test-marshal.lisp loads fine and tests with zero errors. This inspired
me to try out the other tests, and the only one which fails is
test-intern.lisp (this is the cmu cl output, but it also fails on
clisp with similar output):
* (load "test-intern.lisp")
; Loading #p"/usr/home/chapmanb/clorb-0.2/test-intern.lisp".
Warning: This variable is undefined:
*R
Warning: This function is undefined:
INTERNALIZE
;;; In test case Test hello
;;;! Exception
Error in function PCL::FIND-CLASS-FROM-CELL: No class named:
IREPOSITORY.
;;; ------------- Test Internalize finished -----------------
;;; 1 tests executed with 1 errors
Could the problem be due to sockets? (since that seems to be a
sticking point with the clisp server). The error didn't really seem
like it, but I am also still working on getting Dan Barlow's socket
code working on FreeBSD, so I am using whatever socket capabilities
cmu cl has. Just a random idea because I'm not positive where to go.
To talk myself out of that, if Eric has this problem as well, this may
not be the case.
Onward to clisp:
> Eric Marsden:
>
>> bc> [7]> (run-hello :file "hw.ior")
>> bc>
>> bc> *** - UNIX error 49 (EADDRNOTAVAIL): Can't assign requested
address
>>
>> it looks like you already have something running on the port
specified
>> in clorb-options.lisp (maybe simply CLORB in another lisp
instance?).
Lennart:
> I think that that would usually give another error code.
> I wonder what that error code means. It is probably not the same as
> "address already in use". Could you try to find a description of this
> error. The man-pages socket(2), bind(2) and listen(2) might contain
> something. The Linux man-pages doesn't (they say "SVr4 documents
> additional EADDRNOTAVAIL, EADDRINUSE, and ENOSR general error
> conditions").
Okay, I double checked that port and nothing is running on it. For
fun, I modified the port to ones that I've used previously (for
python programming, tho), and added Eric's fixes for defining the
*host* without relieving the errors :-<.
The FreeBSD bind man page has the following to say about
EADDNOTAVAIL:
[EADDRNOTAVAIL]
The specified address is not available from the local
machine.
and I guess if it was the problem Eric mentioned, I would see an error
like:
[EADDRINUSE]
The specified address is already in use.
Of course, now I don't have any idea what kind of problems cause an
address not to be available :-<.
Eric:
>> The hello example works fine for me with CLISP (the
>> InterfaceRepository has to know about the IDL:Hello/World interface
>> first).
Lennart:
> An alternative is to load the hello-idl.lisp file before running
> run-hello. That allows the hello servant to provide the client with
an
> InterfaceDef object for the Hello:World interface.
>
> With (clorb::load-ir) and the above file, it should be possible to
run
> the example without an InterfaceRepository.
The (clorb::load-ir) method is what I've been using to try and get
this working (I'm following almost exactly the information in the
README). So if this way works fine for both of you on Solaris and
Linux, then there must be a problem with clisp and FreeBSD sockets? Is
the best route now to go to the clisp list and see what I can find out
there?
I really appreciate both of you helping me with these problems. If
there is anything else at all I can try, I would be happy to do so.
Thanks again!
Brad
|
|
From: Lennart S. <le...@ly...> - 2000-06-29 15:04:20
|
Eric Marsden <ema...@ma...> writes: > bc> [7]> (run-hello :file "hw.ior") > bc> > bc> *** - UNIX error 49 (EADDRNOTAVAIL): Can't assign requested address > > it looks like you already have something running on the port specified > in clorb-options.lisp (maybe simply CLORB in another lisp instance?). I think that that would usually give another error code. > The hello example works fine for me with CLISP (the > InterfaceRepository has to know about the IDL:Hello/World interface > first). An alternative is to load the hello-idl.lisp file before running run-hello. That allows the hello servant to provide the client with an InterfaceDef object for the Hello:World interface. With (clorb::load-ir) and the above file, it should be possible to run the example without an InterfaceRepository. -- Lennart Staflin <le...@ly...> |
|
From: Lennart S. <le...@ly...> - 2000-06-29 10:57:56
|
Brad Chapman <cha...@ar...> writes: > * (hello-client :file "hw.ior") > Error in function CLORB::UNMARSHAL-GIOP-HEADER: Not a GIOP message > > Restarts: > 0: [ABORT] Return to Top-Level. > > Debug (type H for help) > > (CLORB::UNMARSHAL-GIOP-HEADER > #S(CLORB::BUFFER > :OCTETS #(0 0 0 0 0...) The client seems to have read in a lot of zeros from the stream. That is strange. Could be some error handling that is wrong. Any way, this is probably a consequence on the error on the server side. > The server also crashes when this occurs, with the following backtrace: > > * (run-hello :file "hw.ior") > Compiling LAMBDA (#:G1518 #:G1519 #:G1520 #:G1521 #:G1524 #:G1525): > Compiling Top-Level Form: > ;;; Acception tcp connection: 6 > ;; - to stream: #<Stream for descriptor 6> > ;; Receive (60) > > Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: > -1 is not of type (MOD 536870911) > > Restarts: > 0: [ABORT] Return to Top-Level. > > Debug (type H for help) > > (CLORB::UNMARSHAL-STRING > #S(CLORB::BUFFER > :OCTETS #(71 73 79 80 1...) > :POSITION 32 > :BYTE-ORDER 1 > :START-POS 0)) > Source: > ; File: /usr/home/chapmanb/clorb-0.2/clorb-unmarshal.lisp > (MAKE-STRING LEN) This is from make-string. It must be LEN that is -1. And it must be the operation name it is trying to unmarshal. I can't figure out why the length is -1. What kind of machine and OS are you running on? Could you try and load the "test-marshal.lisp" and see if it produces any errors? > clisp > ----- > On clisp, I get an error immediately upon trying to start up the server, > and it gives the following trace. > > [7]> (run-hello :file "hw.ior") > > *** - UNIX error 49 (EADDRNOTAVAIL): Can't assign requested address I wonder what that error code means. It is probably not the same as "address already in use". Could you try to find a description of this error. The man-pages socket(2), bind(2) and listen(2) might contain something. The Linux man-pages doesn't (they say "SVr4 documents additional EADDRNOTAVAIL, EADDRINUSE, and ENOSR general error conditions"). -- Lennart Staflin <le...@ly...> |
|
From: Eric M. <ema...@ma...> - 2000-06-29 09:28:07
|
I think the following definition of *host* is more useful than
"localhost" as currently defined in clorb-options.lisp (otherwise IORs
are useless on other machines).
(defparameter *host*
#+(or cmu sbcl)
(unix:unix-gethostname)
#+clisp
(let ((mi (machine-instance)))
(subseq mi 0 (position #\Space mi))))
--
Eric Marsden <URL:http://www.laas.fr/~emarsden>
|
|
From: Eric M. <ema...@ma...> - 2000-06-29 09:24:58
|
>>>>> "bc" == Brad Chapman <cha...@ar...> writes: bc> * (hello-client :file "hw.ior") bc> Error in function CLORB::UNMARSHAL-GIOP-HEADER: Not a GIOP message I get the same error (CMUCL on Solaris using db-sockets) when invoking _list on the InterfaceRepository; I haven't tracked down where it comes from. bc> * (run-hello :file "hw.ior") bc> Compiling LAMBDA (#:G1518 #:G1519 #:G1520 #:G1521 #:G1524 #:G1525): bc> Compiling Top-Level Form: bc> ;;; Acception tcp connection: 6 bc> ;; - to stream: #<Stream for descriptor 6> bc> ;; Receive (60) bc> bc> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: bc> -1 is not of type (MOD 536870911) same. bc> On clisp, I get an error immediately upon trying to start up the bc> server, and it gives the following trace. bc> bc> [7]> (run-hello :file "hw.ior") bc> bc> *** - UNIX error 49 (EADDRNOTAVAIL): Can't assign requested address it looks like you already have something running on the port specified in clorb-options.lisp (maybe simply CLORB in another lisp instance?). The hello example works fine for me with CLISP (the InterfaceRepository has to know about the IDL:Hello/World interface first). -- Eric Marsden <URL:http://www.laas.fr/~emarsden> |
