Problem with (eq? ...) and Serveez

Problem with (eq? ...) and Serveez

[Roland Besserer]

Hi,

I'm at a loss why the code below fails running in serveez
with guile (1.6.x and 1.4.x):

I have a serveez server implemented in guile. Serveez uses a 'sock'
object as an argument to certain callback functions. In one such
callback function I add the 'sock' argument to a list:

(define bcs '())

....

(define (callback-fn1 server sock)
        ...
        (set! bcs (cons sock bcs))
        ...
)

later, in another callback function, I want to remove the 'sock' object:

(define (callback-fn2 sock req len)
        ...
        (set! bcs (remove-if (lambda (x) (eq? x sock)) bcs))
        ...
)

remove-if fails because eq? always returns #f for the comparison case.
I tested eq? against a number of cases and got the following results:

(set! bcs sock)
(eq? bcs sock)  -->  #t
(display sock)  -->  #<svc-socket f1808>
(display bcs)   -->  #<svc-socket f1808>

(define bcs '())
(set! bcs (cons sock bcs))
(eq? sock (car bcs))       --> #f
(display sock)             --> #<svc-socket f1808>
(display (car bcs))        --> #<svc-socket f1808>


Why does eq? fail in the second case?
Any pointers would be welcome.

Regards

roland


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Problem with (eq? ...) and Serveez

[Stephen Compall]

Roland Besserer<roland@motorola.com> writes:

> Why does eq? fail in the second case?
> Any pointers would be welcome.

Because, each time Serveez calls your callback function, it remakes
the smob that contains the socket.  It doesn't matter that the filedes
is the same; that is a case for equal?, just as the characters in a
string are a case for equal? not eq?.

The relevant code is in guile-server.c.  Each of the callbacks has a
wrapper.  Take guile_func_kicked_socket for example.  It calls
MAKE_SMOB (svz_socket, sock), which effectively calls the expansion of
GUILE_CONCAT3(guile_,svz_socket,create), a function that calls the
expansion of SCM_RETURN_NEWSMOB.  A new smob can't be eq? to anything
already in the system.

--
Stephen Compall or s11 or sirian

understand, v.:
	To reach a point, in your investigation of some subject, at which
	you cease to examine what is really present, and operate on the
	basis of your own internal model instead.

Firewalls Roswell Medco Ron Brown counter intelligence kilo class
Noriega espionage Verisign smuggle AMEMB MD5 LABLINK SEAL Team 6 fraud


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Problem with (eq? ...) and Serveez

[Roland Besserer]

Understood and I appreciate the details on the Serveez callback
allocation but ... I had already traversed the equal?, eqv?, eq?
path - identical results.

It appears that neither comparing for actual object equivalence
(which I incorrectly assumed would be the case) nor content
equivalence via equal? returns true. I probably should've been
clearer in my original post.

Regards

roland


Stephen Compall<s11@member.fsf.org> writes:

> Roland Besserer<roland@motorola.com> writes:
> 
> > Why does eq? fail in the second case?
> > Any pointers would be welcome.
> 
> Because, each time Serveez calls your callback function, it remakes
> the smob that contains the socket.  It doesn't matter that the filedes
> is the same; that is a case for equal?, just as the characters in a
> string are a case for equal? not eq?.
> 
> The relevant code is in guile-server.c.  Each of the callbacks has a
> wrapper.  Take guile_func_kicked_socket for example.  It calls
> MAKE_SMOB (svz_socket, sock), which effectively calls the expansion of
> GUILE_CONCAT3(guile_,svz_socket,create), a function that calls the
> expansion of SCM_RETURN_NEWSMOB.  A new smob can't be eq? to anything
> already in the system.
> 
> --
> Stephen Compall or s11 or sirian
> 
> understand, v.:
> 	To reach a point, in your investigation of some subject, at which
> 	you cease to examine what is really present, and operate on the
> 	basis of your own internal model instead.
> 
> Firewalls Roswell Medco Ron Brown counter intelligence kilo class
> Noriega espionage Verisign smuggle AMEMB MD5 LABLINK SEAL Team 6 fraud
> 

-- 
Roland Besserer
Distinguished Member of Technical Staff
Motorola Broadband Communications Sector
55 Las Colinas Lane
San Jose, CA 95119
+1 408 284 6181
+1 408 504 4178 GSM


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Problem with (eq? ...) and Serveez

[Stephen Compall]

Roland Besserer<roland@motorola.com> writes:

> Understood and I appreciate the details on the Serveez callback
> allocation but ... I had already traversed the equal?, eqv?, eq?
> path - identical results.
> 
> It appears that neither comparing for actual object equivalence
> (which I incorrectly assumed would be the case) nor content
> equivalence via equal? returns true. I probably should've been
> clearer in my original post.

eqv? is useless and confusing IMHO.

equal? does not know how to compare every object.  In the case of
smobs, the smob creator must define an equalp C function and register
it with scm_set_smob_equalp.  The only smob in Serveez for which this
is done is "svz-binary".

You could add this somewhere in guile-server.c (wildly untested):

SCM
guile_socket_equalp (SCM self_scm, SCM other_scm)
{
  return SCM_SMOB_DATA (self_scm) == SCM_SMOB_DATA (other_scm);
}

Then add

scm_set_smob_equalp (svz_socket_tag, (SCM (*)(SCM, SCM)) guile_socket_equalp);

to guile_server_init.  This is one solution, that really tests eq?ness
of the underlying svz_socket_t, which should work.  You could also
have guile-server.c cache its socket smobs, rather than re-make them
each time, so you don't get a new one each time.  That might work
better.

--
Stephen Compall or s11 or sirian

-- Scintillate, scintillate, asteroid minikin.
-- Members of an avian species of identical plumage congregate.
-- Surveillance should precede saltation.
-- Pulchritude possesses solely cutaneous profundity.
-- It is fruitless to become lachrymose over precipitately departed
	lacteal fluid.
-- Freedom from incrustations of grime is contiguous to rectitude.
-- It is fruitless to attempt to indoctrinate a superannuated
	canine with innovative maneuvers.
-- Eschew the implement of correction and vitiate the scion.
-- The temperature of the aqueous content of an unremittingly
	galled saucepan does not reach 212 degrees Farenheit.

ANC SP4 sweep propaganda Montenegro fissionable IRA TWA M-14 White
House Ft. Bragg Glock enemy of the state Perl-RSA DES


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: Problem with (eq? ...) and Serveez

[Stephen Compall]

Stephen Compall <s11@member.fsf.org> writes:

> SCM
> guile_socket_equalp (SCM self_scm, SCM other_scm)
> {
>   return SCM_SMOB_DATA (self_scm) == SCM_SMOB_DATA (other_scm);
> }

Well, you'd have to convert that C boolean to SCM, duh.

return (SCM_SMOB_DATA (self_scm) == SCM_SMOB_DATA (other_scm))
         ? SCM_BOOL_T : SCM_BOOL_F;

--
Stephen Compall or s11 or sirian

"...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning."
(By Matt Welsh)

global digicash CISU Europol USDOJ SCUD missile UOP militia
cryptanalysis supercomputer Janet Reno Rand Corporation CIA INS Arnett


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user