If you want to incorporate these and bounce a .cs back to me, I will send this to Scott and Dan.
I figured out the mail to list issue, and it was User Error :)
Cheers, Bijan.
from preamble:
"Change Set: SmallIRCTweaks Date: 29 April 2002 Author: Bijan Parsia
Two bits: 1) Fixed the '/me' handling (it should convert to an /action, not sure if I hacked it into the best spot. 2) Pulled Stephan's world menu changes and just made the 'irc client' item open the enhanced client. A preference could be added if anyone really wants it."!
D'oh.
That was to steve direct.
Oopsy. But what's a little underwear exposed to the light of public scruitany? *Clean* underwear, that's what!
Cheers, Bijan Parsia.
bparsia@email.unc.edu wrote:
- Pulled Stephan's world menu changes and just made the 'irc client'
item open the enhanced client. A preference could be added if anyone really wants it."!
No! I see no reason to persist with the in-image IRC client. Am I missing anything? Let's burn the old code, and sally forth! :)
Lex
On Mon, 29 Apr 2002, Lex Spoon wrote:
bparsia@email.unc.edu wrote:
- Pulled Stephan's world menu changes and just made the 'irc client'
item open the enhanced client. A preference could be added if anyone really wants it."!
No! I see no reason to persist with the in-image IRC client. Am I missing anything? Let's burn the old code, and sally forth! :)
The burning day will come, and it will be glorious.
Right now, the enhanced client subclasses the old client which is burning my butt in 3.3 :)
So a merge is in the near future I hope ;)
Cheers, Bijan Parsia.
I was looking at the source code for sqUnixSocket.c on sourceforge, then from Ian's Squeak-3.1beta-4478-src.tar.
Lo they are a bit different. So could the real source code step forward?
Hi all!
Quoting John M McIntosh johnmci@smalltalkconsulting.com:
I was looking at the source code for sqUnixSocket.c on sourceforge, then from Ian's Squeak-3.1beta-4478-src.tar.
Lo they are a bit different. So could the real source code step forward?
I would guess that depends on who you ask... :-)
If Ians code includes Lex's enhancements (and I think he said that he had included those - whatever they are) then perhaps we should switch to it.
Ian's opinion of the SF version was... well. Let's say he had opinions.
Anyway, currently neither works in regard with the bug I found. I tried the patch from Ian, and it did solve my little testprog but our app didn't work. With the patch in the readSemaphore didn't get signalled that much... And I applied the patch both to SF (as good as I knew how) and to his 4478-tar, with the same result.
So the patch isn't complete. Today we managed to "fumble" ourselves around it by hacking waitForDataUntil: and doing a "(Delay milliSeconds: 10) wait" instead of the wait with timeout on the readsemaphore. Yep, ugly as hell but it works well enough for us to continue developing...
regards, Göran
PS. I will help in any way I can with this - Squeak needs rock solid Sockets. DS
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
So the patch isn't complete. Today we managed to "fumble" ourselves around it by hacking waitForDataUntil: and doing a "(Delay milliSeconds: 10) wait" instead of the wait with timeout on the readsemaphore. Yep, ugly as hell but it works well enough for us to continue developing...
regards, Göran
PS. I will help in any way I can with this - Squeak needs rock solid Sockets. DS
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
ick!!!
Well lets see if we can fix this.
Now I wonder if there is a race condition on the flag READNOTIFy such that a socketReadable says no but by the time you get to aioHandle, then data lurks?
What if you did this instead
/* answer whether the socket has data available for reading */
int sqSocketReceiveDataAvailable(SocketPtr s) { if (!socketValid(s)) return -1; if (SOCKETSTATE(s) == Connected) { PSP(s)->pendingEvents|= READ_NOTIFY; if (socketReadable(SOCKET(s))) { PSP(s)->pendingEvents &= ~READ_NOTIFY; // I'll run out on a tree branch here and assume that this &= ~ will reset READ_NOTIFY flag bit, but hey it might be wrong C code in fact let's say it is, so please check confirm etc that I'm actually kinda right in wanting to turn just the READ_NOTIFY bit off without mangling the other bits. return true; } aioHandle(SOCKET(s), dataHandler, AIO_RWX); } return false; }
Mind I'm not sure what happens between athe socketReadable and aioHandle logic if data arrives on the socket?
So the patch isn't complete. Today we managed to "fumble" ourselves around it by hacking waitForDataUntil: and doing a "(Delay milliSeconds: 10) wait" instead of the wait with timeout on the readsemaphore. Yep, ugly as hell but it works well enough for us to continue developing...
Okay, Ian has patiently explained to me how the semaphore notification stuff is supposed to work, and it turns out that the SourceForge code is really a mess. Basically, the following line in notify():
int mask= pss->pendingEvents | eventMask;
would cause all events to be signalled that the image is interested in, whether the event has happened or not. Changing the "|" to the proper "&" (duh!) causes many events *not* to be signalled. This led to a cascade of changes to make sure that pendingEvents has all the flags it is supposed to, and that select() gets called on all the events listed in pendingEvents. This is all posted on SourceForge now.
Goran's example code works properly, Scamper works, and with any luck email sending works. :) Hopefully this is better on the whole, but there may well be new problems. It's tricky stuff, and the code is less than clear.
The changes are posted on SourceForge. I haven't looked at Ian's version, but there's a good chance that it has similar issues.
Lex Spoon
Lex Spoon wrote:
Goran's example code works properly, Scamper works, and with any luck email sending works. :) Hopefully this is better on the whole, but there may well be new problems. It's tricky stuff, and the code is less than clear.
It'll be interesting to see if it works on Acorn, since I have thus far been able to use the unix socket code with only a few extra includes hacked in.
tim
squeak-dev@lists.squeakfoundation.org
-
Bijan Parsia -
bparsia＠email.unc.edu
-
Göran Hultgren -
John M McIntosh -
Lex Spoon -
Tim Rowledge