cl-net-snmp-general

(CL Net SNMP) class precedence issue with SNMP + USOCKET-UDP

[William A. <an...@bi...>]

I let my cl-net-snmp get a few weeks stale.  I updated it recently,
and also grabbed the USOCKET-UDP library from your SVN repository.
I've pulled out anything that references USOCKET, but SBCL gives me
this loveliness when I try an SNMP-GET:


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
While computing the class precedence list of the class named USOCKET:STREAM-DATAGRAM-USOCKET.
The class named USOCKET::DATAGRAM-USOCKET is a forward referenced class.
The class named USOCKET::DATAGRAM-USOCKET is a direct superclass of the class named USOCKET:STREAM-DATAGRAM-USOCKET.
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [ABORT] Return to SLIME's top level.
 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {100279D1B1}>)

Backtrace:
  0: (SB-PCL::CPL-ERROR #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> "The class ~A is a forward referenced class.~@
                           The class ~A is ~A.")[:EXTERNAL]
  1: ((LABELS SB-PCL::WALK) #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB-MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
  2: (SB-PCL::COMPUTE-STD-CPL-PHASE-1 #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB-MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
  3: (SB-PCL::COMPUTE-STD-CPL #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB-MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
  4: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> T)
  5: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM-USOCKET> T)[:EXTERNAL]
  6: (SB-PCL::INSTALL-OPTIMIZED-CONSTRUCTOR #<SB-PCL::CTOR {1002DB0139}>)
  7: ((LAMBDA (&REST SB-PCL::ARGS)) #<SB-BSD-SOCKETS:INET-SOCKET descriptor 5 {10026C16F1}> #<SB-SYS:FD-STREAM for "a socket" {10026CEFA1}>)
  8: (OPEN-SESSION "lp2")[:EXTERNAL]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;


I've done a little staring at the code, but this error takes us into
the outer reaches of CLOS, in which I'm no expert.  Any ideas?  I've
seen some of your email to the USOCKET list.  Will your UDP stuff be
getting rolled into the main trunk?  I can always revert to an older
SNMP until that's ready.

--
wm

Re: (CL Net SNMP) class precedence issue with SNMP + USOCKET-UDP

[Chun T. (binghe) <bin...@gm...>]

Hi, Annis

I think your USOCKET source tree is not the latest SVN trunk, these  
CLOS condition indicates that the DATAGRAM-USOCKET class haven't  
defined.

And during these weeks, I have moved usocket-udp dir out of the snmp  
directory. The author of USOCKET seems forget my post or do not want  
to merge my UDP patch at this time. I think it OK. It's him who define  
a DATAGRAM-USOCKET in his own tree, not me. So I think in the future  
there will be a UDP support, if not from me, must from himself.

So I suggest you try following steps:

1. Update your usocket to latest version from this link and make it  
ASDF-loadable:

svn://common-lisp.net/project/usocket/svn/usocket/trunk

2. Check out the USOCKET-UDP sub-project from this link and make it  
ASDF-loadable:

https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/usocket-udp

3. Update snmp directory to at least r226:

https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/trunk

I tested it in SBCL, seems OK now. Try it and tell me your new result.

Thanks.

Chun Tian (binghe)

>
> I let my cl-net-snmp get a few weeks stale.  I updated it recently,
> and also grabbed the USOCKET-UDP library from your SVN repository.
> I've pulled out anything that references USOCKET, but SBCL gives me
> this loveliness when I try an SNMP-GET:
>
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> While computing the class precedence list of the class named  
> USOCKET:STREAM-DATAGRAM-USOCKET.
> The class named USOCKET::DATAGRAM-USOCKET is a forward referenced  
> class.
> The class named USOCKET::DATAGRAM-USOCKET is a direct superclass of  
> the class named USOCKET:STREAM-DATAGRAM-USOCKET.
>   [Condition of type SIMPLE-ERROR]
>
> Restarts:
> 0: [ABORT] Return to SLIME's top level.
> 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl- 
> thread" {100279D1B1}>)
>
> Backtrace:
>  0: (SB-PCL::CPL-ERROR #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM- 
> USOCKET> "The class ~A is a forward referenced class.~@
>                           The class ~A is ~A.")[:EXTERNAL]
>  1: ((LABELS SB-PCL::WALK) #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM- 
> USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB-MOP:FORWARD- 
> REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
>  2: (SB-PCL::COMPUTE-STD-CPL-PHASE-1 #<STANDARD-CLASS USOCKET:STREAM- 
> DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB- 
> MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
>  3: (SB-PCL::COMPUTE-STD-CPL #<STANDARD-CLASS USOCKET:STREAM- 
> DATAGRAM-USOCKET> (#<STANDARD-CLASS USOCKET:STREAM-USOCKET> #<SB- 
> MOP:FORWARD-REFERENCED-CLASS USOCKET::DATAGRAM-USOCKET>))
>  4: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM- 
> USOCKET> T)
>  5: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS USOCKET:STREAM-DATAGRAM- 
> USOCKET> T)[:EXTERNAL]
>  6: (SB-PCL::INSTALL-OPTIMIZED-CONSTRUCTOR #<SB-PCL::CTOR  
> {1002DB0139}>)
>  7: ((LAMBDA (&REST SB-PCL::ARGS)) #<SB-BSD-SOCKETS:INET-SOCKET  
> descriptor 5 {10026C16F1}> #<SB-SYS:FD-STREAM for "a  
> socket" {10026CEFA1}>)
>  8: (OPEN-SESSION "lp2")[:EXTERNAL]
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
>
> I've done a little staring at the code, but this error takes us into
> the outer reaches of CLOS, in which I'm no expert.  Any ideas?  I've
> seen some of your email to the USOCKET list.  Will your UDP stuff be
> getting rolled into the main trunk?  I can always revert to an older
> SNMP until that's ready.
>
> --
> wm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save  
> $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> CL-Net-SNMP-General mailing list
> CL-...@li...
> https://lists.sourceforge.net/lists/listinfo/cl-net-snmp-general

Re: (CL Net SNMP) class precedence issue with SNMP + USOCKET-UDP

[William A. <an...@bi...>]

 >And during these weeks, I have moved usocket-udp dir out of the snmp  
 >directory. The author of USOCKET seems forget my post or do not want  
 >to merge my UDP patch at this time. I think it OK. It's him who define  
 >a DATAGRAM-USOCKET in his own tree, not me. So I think in the future  
 >there will be a UDP support, if not from me, must from himself.

        Ok.  I'll keep a closer eye on those libraries, too.

 >I tested it in SBCL, seems OK now. Try it and tell me your new result.

        I've updated everything - including SBCL to current - and I'm
back in business.

        In a somewhat different matter, I recently used CL-YACC on a
project of my own (http://code.google.com/p/cl-period/).  It seems a
lot less esoteric than ZEBU.  Is it capable of handling ASN.1, or did
you already decide against it for particular faults?

--
wm

Re: (CL Net SNMP) class precedence issue with SNMP + USOCKET-UDP

[Chun T. (binghe) <bin...@gm...>]

Hi, W. A.

>
>> And during these weeks, I have moved usocket-udp dir out of the snmp
>> directory. The author of USOCKET seems forget my post or do not want
>> to merge my UDP patch at this time. I think it OK. It's him who  
>> define
>> a DATAGRAM-USOCKET in his own tree, not me. So I think in the future
>> there will be a UDP support, if not from me, must from himself.
>
>        Ok.  I'll keep a closer eye on those libraries, too.
>
>> I tested it in SBCL, seems OK now. Try it and tell me your new  
>> result.
>
>        I've updated everything - including SBCL to current - and I'm
> back in business.

Good.

>
>
>        In a somewhat different matter, I recently used CL-YACC on a
> project of my own (http://code.google.com/p/cl-period/).  It seems a
> lot less esoteric than ZEBU.  Is it capable of handling ASN.1, or did
> you already decide against it for particular faults?

Thank you for your notes. Actually I do use cl-yacc and cl-lexer on  
earlier version, and soon find too many conflicts which cannot shift  
by cl-yacc and then turn to ZEBU.

There's a ASN.1 Book which talk about the parse of ASN.1:

http://www.oss.com/asn1/dubuisson.html

In this book, author said the ASN.1 BNF, when using a LALR parser, can  
produce hundred of conflicts. And this book suggest that, to parse  
full ASN.1, LALR parser isn't fit to use. Maybe LL parser is better.

I'm still reading this book. I decide to finish reading first, then  
continue to think about my ASN.1 parse job. I think I need more  
knowledge of ASN.1, it's quite complex.

Regards,

Chun Tian (binghe)