[bug #25307] [NSConditionLock tryLockWhenCondition:] shouldn't throw exception when lock is unavailable

Follow-up Comment #5, bug #25307 (project gnustep): > I will go ahead and write one and attach it here. You could add it to tests/testsuite/base/ ___ Reply to this item at: _

[bug #25307] [NSConditionLock tryLockWhenCondition:] shouldn't throw exception when lock is unavailable

Follow-up Comment #4, bug #25307 (project gnustep): > The point of "tryLock" and "tryLockWhenCondition:" is to attempt to do the > lock and return NO, if it can't. Sure ... but the rationale was that, if the lock is held by the current thread then calling it is evidence of a probable bug. Why?

[bug #25284] Adding outlets and actions could be smoother

Update of bug #25284 (project gnustep): Status: In Progress => None ___ Reply to this item at: ___ Me

[bug #25307] [NSConditionLock tryLockWhenCondition:] shouldn't throw exception when lock is unavailable

Follow-up Comment #3, bug #25307 (project gnustep): The point of "tryLock" and "tryLockWhenCondition:" is to attempt to do the lock and return NO, if it can't. For it to return an exception seems wrong in any case. In my opinion it should return NO whether a single thread attempts to lock the

[bug #25243] Art backend Seg Faults

Follow-up Comment #5, bug #25243 (project gnustep): Yes, it did! I just redirected the output of stderr, not stdout, to the file. As for only using Helvetica it's only because there really aren't any available nfonts other than it and the stuff in the backbone CVS repo (at least that I know of)

[bug #25327] NSAnimation no longer works

Follow-up Comment #4, bug #25327 (project gnustep): Great, I would even say better then ever before. ___ Reply to this item at: ___ Nachricht geschickt

[bug #25243] Art backend Seg Faults

Follow-up Comment #4, bug #25243 (project gnustep): Looks like you only have the default font for the art backend installed (Helvetica). Perhaps we should advertise better that there are additional fonts available as a separate package. Did you again get a segmentation fault? __

[bug #25307] [NSConditionLock tryLockWhenCondition:] shouldn't throw exception when lock is unavailable

Follow-up Comment #2, bug #25307 (project gnustep): If this is about the exception thrown if a single thread attempts to lock the same lock twice, it's not a behavior specific to NSConditionLock (only an NSRecursiveLock is allowed to be locked twice by a thread). If the exception is something el