Hi,
sorry for the long, long delay. We had to get in contact with the guys
at savannah to solve some administration problems that couldn't be
solved from our administrative console.
Zhang Weiwu of 3fingers wrote:
On 04/27/2011 03:02 AM, Riccardo Mottola wrote:
I'll speak with Greg
On 06/22/2011 04:08 PM, Riccardo Mottola wrote:
both gap-discuss and gap-dev-discuss are now back online and working!
Ooh, I need to find the piece of paper where I briefly wrote 8 known
problems! I hope still can find them
Congratulations on the coming back of mailing list!
On Wednesday, June 22, 2011 11:04 CEST, Riccardo Mottola
riccardo.mott...@libero.it wrote:
Hi,
I am able to reproduce the problems Sebastian has on my own OpenBSD/x86 box.
I get this problem only on OpenBSD. I use gcc and its standard runtime. The
same combination appears to work
Hi,
given the failure on Sudoku on OpenBSD/x86, I decided to run the test-suite.
gcc (GCC) 4.2.1 20070719
libffi-3.0.9Foreign Function Interface
The output doesn't look that nice:
test: base/GSMime: unknown operand
--- Running tests in base/Functions ---
test: NSPathUtilities.m:
On Wednesday, June 22, 2011 12:35 CEST, Riccardo Mottola
riccardo.mott...@libero.it wrote:
Hi,
given the failure on Sudoku on OpenBSD/x86, I decided to run the test-suite.
This is what I've seen too. Commenting out the line where it goes to generates
the exception in -[NSException
As Sebastian already pointed out not the exception is the problem here,
but the way we currently implement it.
The exception itself is part of the algorithm of that application. It's
a sort of structured long jump, when a solution is found somewhere deep
down in the recursion it jumps back to
Hi,
indeed. Just to be sure, I used a platform where SUdoku and put a
breakpoint. I confirm that the exception is always thrown. Terrible
code, I have the urge to rewrite it properly... it looks like roughly
like tail-recursion.
In any case it is no excuse for exceptions not working on
