Search
Wednesday, 24th of July 2019, 7:07:30 UTC
12:44:47
sts-q
To move a window programmatically i say (mezzano.gui.compositor:move-window (window viewer) new-xpos new-ypos)
12:45:20
sts-q
Is there a way to resize a window like that way?
12:47:30
froggey
(compositor:resize-window window (mezzano.gui:make-surface new-width new-height))
12:48:14
froggey
and the compositor will send a resize-event when it has completed the resize
12:56:10
sts-q
Yes it works! But the title-bar of the window is not visible but still accessible.
12:58:06
froggey
oh right, you have to tell the frame about your new surface
12:58:32
froggey
(mezzano.gui.widgets:resize-frame window-frame the-surface-returned-by-make-surface)
12:59:17
froggey
you should do that before the call to resize-window so the frame is immediately visible once the compositor switches surfaces
13:00:34
ebrasca
froggey: Have you merged my changes from slime into your branch? ( They are upstream )
13:05:31
ebrasca
Are your slime now in master?
13:07:30
froggey
my repo is up to date, yes
13:17:26
sts-q
Yes it works! Thank you! :)
17:48:02
ebrasca
froggey: I don't like recursive locks. Can you make some automatic fixing function?
17:56:54
froggey
no. I don't know how that would work
18:11:04
ebrasca
Here my function: http://ix.io/1Pmz/lisp
18:12:50
ebrasca
I changed this : ((and listener (eql flags +tcp4-flag-syn+)) ...)
18:15:00
froggey
what's the error? include the backtrace
18:17:06
ebrasca
Here error http://ix.io/1PmE
18:19:31
froggey
look at the backtrace and think about it
18:20:39
froggey
close-tcp-connection is trying to acquire a connection lock that is already held. you can look through the backtrace for calls to call-with-mutex to see what other function are holding locks
18:20:48
froggey
*already held by the current thread
18:21:28
ebrasca
Does mezzano.supervisor:condition-wait-for return some not nil value when it worked?
18:23:10
froggey
it returns a non-nil value if the predicate returns non-nil. it returns nil if the timeout expires
18:25:23
ebrasca
Predicate is same as in tcp-connect , tcp-connect does work.
18:29:23
froggey
ok, there are two problems here: 1) the recursive locking error. 2) the unexpected timeout
18:29:46
froggey
lets focus on problem 1 for now
18:35:04
froggey
oh heh. the original tcp-connect code has the same problem with timeouts
18:36:37
ebrasca
ACTION have no idea how to fix it.
18:39:02
froggey
close-tcp-connection wants to take the connection lock, but can't because it has already been taken by a function higher up on the call stack
18:39:45
froggey
you can identify the function that originally took the lock by looking for call-with-mutex in the backtrace
18:41:07
froggey
in your case it is %tcp4-receive, but the same bug is also present in tcp-connect as I just found out
18:41:58
ebrasca
I can't replicate it in tcp-connect , I suspected it.
18:42:23
froggey
try connecting to an address that doesn't exist and let it time out
18:42:42
froggey
(mezzano.network.tcp:tcp-stream-connect "10.10.10.10" 1) was enough for me to reproduce
18:43:04
froggey
close-tcp-connection doesn't need to do anything fancy with the lock, it does all its work with the lock held
18:43:24
froggey
it could be changed to not take the lock, and to require that it is called with the lock already held
18:43:57
froggey
it is only ever called from tcp-connect and the close method, so that's a viable solution
18:44:12
ebrasca
Only 1 place need to add lock to call it.
18:46:07
froggey
this kind of fix won't work everywhere, and it's not something we want to do for public interfaces. we don't want arbitrary code having to take internal locks
18:47:02
ebrasca
But do you care if it is internal function?
18:51:28
ebrasca
Writing new version of tcp-connect with it.
18:54:00
ebrasca
I can't start my mezzano. Need to recompile to test it.
18:56:07
ebrasca
My idea is this : http://ix.io/1PmS/lisp
18:57:16
ebrasca
But now if it timeout it have 2 locks.
18:58:06
ebrasca
And using 1 temporal variable.
19:01:03
froggey
yeah, simpler to just change close-tcp-connection so that it must be called with the connection lock already held
19:01:20
froggey
your solution should work, but it doesn't seem very elegant to me
19:02:55
ebrasca
I undestand , but do you know someting better?
19:04:26
froggey
like I said, just change close-tcp-connection so it is the caller's responsibility to take the lock
19:04:57
froggey
tcp-connect would be correct with this change and the close method would have to modified to take the lock around the call
19:06:14
ebrasca
But for you it is not elegant and I can't find some elegant method.
Wednesday, 24th of July 2019, 19:07:30 UTC