Re: GNUstep on a fresh Debian (S1-E4)

[Tristan Bellogi]

Testing the fresh installed Base Library:

Already Done:
configure and make instal make library
configure and make base library
make check
my previous to this thread

Let's start this session..

svn get Richard's commit (NSCalendar issues)
update base library
configure, make and make install

some settings...
defaults write NSGlobalDomain "Local Time Zone" Europe/Paris
defaults write NSGlobalDomain NSLanguages "(french,English)"

sudo nano /etc/init.d/gdomap #should it be located here?

#!/bin/sh
# GNUstep deamon gdomap
### THIS WON'T START THE DEAMON ACTUALLY ?
#
if [ -f /usr/GNUstep/Local/Tools/gdomap ]; then
echo -n "Starting GNUstep services... "
/usr/GNUstep/Local/Tools/gdomap
echo "gdomap "
fi

start gdomap & gdnc manually... OK
stop gdomap & gdnc manually... OK

Playing with gnustep-config:
~~~~~~~~~~~~~~~~~~
gnustep-config --objc-flags
-MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_RUNTIME=1 
-D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing 
-fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC 
-Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 
-fobjc-runtime=gnustep-1.8 -fblocks 
-fconstant-string-class=NSConstantString -I. 
-I/home/ylg/GNUstep/Library/Headers -I/usr/GNUstep/Local/Library/Headers 
-I/usr/GNUstep/System/Library/Headers

gnustep-config --objc-libs
-rdynamic -pthread -fexceptions -fobjc-runtime=gnustep-1.8 -fblocks 
-L/home/ylg/GNUstep/Library/Libraries 
-L/usr/GNUstep/Local/Library/Libraries 
-L/usr/GNUstep/System/Library/Libraries -lpthread -lobjc 
-fobjc-nonfragile-abi -lm
gnustep-config --base-libs
-rdynamic -pthread -fexceptions -fobjc-runtime=gnustep-1.8 -fblocks 
-L/home/ylg/GNUstep/Library/Libraries 
-L/usr/GNUstep/Local/Library/Libraries 
-L/usr/GNUstep/System/Library/Libraries -lgnustep-base -lpthread -lobjc 
-fobjc-nonfragile-abi -lm

gnustep-config --installation-domain-for=make
LOCAL

nustep-config --installation-domain-for=base
LOCAL

run tests using gnustep-tests tool
NSCalendar doesn't failed anymore, woks also for me Richard!

libicu is: version 55.1-7

But now I got:
~~~~~~~~~~~~~~~~~~~~~~~~~
base/NSNumber/test02.m:
Failed test:       test02.m:31 ... rounding 0.009
Failed test:       test02.m:37 ... rounding 0.019
Failed test:       test02.m:51 ... rounding 0.0009
Failed test:       test02.m:57 ... rounding 0.0019
--- Running tests in base/NSNumberFormatter ---

base/NSNumberFormatter/basic10_4.m:
Failed test:         basic10_4.m:145 ... negativeFormat used for -ve number

Le 04/03/2016 17:01, Richard Frith-Macdonald a écrit :
> > On 4 Mar 2016, at 15:57, Richard Frith-Macdonald <richard@frithmacdonald.me.uk> 
> > wrote:
> >
> >
> > > On 3 Mar 2016, at 15:00, Tristan Bellogi <bellogi@orange.fr> wrote:
> > >
> > > # The 2 failed tests
> > > base/NSNumberFormatter/basic10_4.m:
> > > Failed test:         basic10_4.m:145 ... negativeFormat used for -ve number
> > This one I can't reproduce, but it sounds like a very minor bug, unlikely to be 
> > a problem in most software.  It might help to know what the actual format 
> > produced was (should be in tests.log), what version of icu is on your system, 
> > and what your locale is set to, since the icu library and the locale are the 
> > things likely to influence number formatting.  It's possible that the testcase 
> > is wrong.
> What I mean is, while we want to get any bug fixed (and if you can provide more 
> info, it might help with that; if it means someone can reproduce it), I don't 
> think this is one you need to actually worry about.