Re: Oracle ?

[David Wetzel]

Hi

How about

http://en.m.wikipedia.org/wiki/OCILIB

Dave

Von meinem iPhone gesendet

Am 24.01.2012 um 01:28 schrieb Pirmin Braun :

> what's the best approach to talk to an Oracle DB in GNUStep?
> SQLClient with JDBC?


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Oracle ?

[Pirmin Braun]

what's the best approach to talk to an Oracle DB in GNUStep?
SQLClient with JDBC?

-- 
mit freundlichen Gruessen/best regards

Pirmin Braun
seat-1 Software GmbH - Sinziger Str. 29a - 53424 Remagen
+49(0)2642 308288   +49(0)163-6290887 - skype:pirminb
Fax +49(0)2642 308626
http://www.seat-1.com  p...@seat-1.com
http://intars.sourceforge.net

Geschäftsführer: Pirmin Braun, Ralf Engelhardt
Registergericht: Amtsgericht Coburg HRB3136


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Ugly flickering in some views

[Germán Arias]

On 2012-01-23 21:16:01 -0600 Eric Wasylishen  
wrote:


Thanks for the info.. this is bad because it sounds like the 
NSCopyBits is 
causing flickering.


I have another debugging request:
-update gui/back again
-verify the flickering is back.
-open back/Source/cairo/CairoContext.m
and change this section:

//#define _CAIRO_SURFACE_CLASSNAME XGCairoSurface
//#include "cairo/XGCairoSurface.h"
//#define _CAIRO_SURFACE_CLASSNAME XGCairoXImageSurface
//#include "cairo/XGCairoXImageSurface.h"
#define _CAIRO_SURFACE_CLASSNAME XGCairoModernSurface
#include "cairo/XGCairoModernSurface.h"

to this:

//#define _CAIRO_SURFACE_CLASSNAME XGCairoSurface
//#include "cairo/XGCairoSurface.h"
#define _CAIRO_SURFACE_CLASSNAME XGCairoXImageSurface
#include "cairo/XGCairoXImageSurface.h"
//#define _CAIRO_SURFACE_CLASSNAME XGCairoModernSurface
//#include "cairo/XGCairoModernSurface.h"

-make and install back, and try fisicalab again.


This change solves the problem.



I'm assuing you're using the cairo backend. I'm curious if changing 
from 
XGCairoModernSurface to XGCairoXImageSurface will fix the problem. 
Also it 
might be worth trying art or xlib, and see if you still get the same 
flickering.


Yes, I'm using cairo. And with xlib and art all works fine. The 
problem is only with
cairo. I don't understand this problem. But, for example, the 
fisicalab's chalkboard
works fine. Even when is basically the same. An NSView with a lot of 
buttons that
can display images. The only difference is that its content isn't 
copied from another
window. And why this problem occurs only when I move the scrollbar to 
down?


Thanks.



Thanks
Eric





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Ugly flickering in some views

[Eric Wasylishen]

Thanks for the info.. this is bad because it sounds like the NSCopyBits is 
causing flickering.

I have another debugging request:
-update gui/back again
-verify the flickering is back.
-open back/Source/cairo/CairoContext.m
and change this section:

//#define _CAIRO_SURFACE_CLASSNAME XGCairoSurface
//#include "cairo/XGCairoSurface.h"
//#define _CAIRO_SURFACE_CLASSNAME XGCairoXImageSurface
//#include "cairo/XGCairoXImageSurface.h"
#define _CAIRO_SURFACE_CLASSNAME XGCairoModernSurface
#include "cairo/XGCairoModernSurface.h"

to this:

//#define _CAIRO_SURFACE_CLASSNAME XGCairoSurface
//#include "cairo/XGCairoSurface.h"
#define _CAIRO_SURFACE_CLASSNAME XGCairoXImageSurface
#include "cairo/XGCairoXImageSurface.h"
//#define _CAIRO_SURFACE_CLASSNAME XGCairoModernSurface
//#include "cairo/XGCairoModernSurface.h"

-make and install back, and try fisicalab again.

I'm assuing you're using the cairo backend. I'm curious if changing from 
XGCairoModernSurface to XGCairoXImageSurface will fix the problem. Also it 
might be worth trying art or xlib, and see if you still get the same flickering.

Thanks
Eric

On 2012-01-23, at 5:46 PM, Germán Arias wrote:

> With r34605 all works fine.
> 
> On 2012-01-23 17:56:35 -0600 Eric Wasylishen  wrote:
> 
>> It could be cause by gui r34606 because that re-enabled copy-on-scroll which 
>> had been accidentally turned off for several months. See if the problem goes 
>> away if you update gui to r34605
>> Eric
>> 
>> On 2012-01-23, at 4:30 PM, Germán Arias wrote:
>> 
>>> I have a problem with FisicaLab in SVN (I can't reproduce this problem with 
>>> other application).
>>> In the elements for static of rigid bodies, that are inside a scrollview, 
>>> when I use the mouse
>>> wheel to navigate all is OK. But if I use the scrollbar or the arrows, whe

>>> n 
>>> I move to down, the
>>> view show an ugly flickering. The content of this view is a copy of the 
>>> content of a window
>>> (staticRigidBodies.gorm file). This worked fine previously. So, I don't 
>>> understand where is
>>> the problem here. Thanks.
>>> 
>>> 
>>> ___
>>> Gnustep-dev mailing list
>>> Gnustep-dev@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>> 
>> 
>> 
> 


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Ugly flickering in some views

[Germán Arias]

With r34605 all works fine.

On 2012-01-23 17:56:35 -0600 Eric Wasylishen  wrote:

> It could be cause by gui r34606 because that re-enabled copy-on-scroll which 
> had been accidentally turned off for several months. See if the problem goes 
> away if you update gui to r34605
> Eric
> 
> On 2012-01-23, at 4:30 PM, Germán Arias wrote:
> 
>> I have a problem with FisicaLab in SVN (I can't reproduce this problem with 
>> other application).
>> In the elements for static of rigid bodies, that are inside a scrollview, 
>> when I use the mouse
>> wheel to navigate all is OK. But if I use the scrollbar or the arrows, when 
>> I move to down, the
>> view show an ugly flickering. The content of this view is a copy of the 
>> content of a window
>> (staticRigidBodies.gorm file). This worked fine previously. So, I don't 
>> understand where is
>> the problem here. Thanks.
>> 
>> 
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> 
> 


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Ugly flickering in some views

[Eric Wasylishen]

It could be cause by gui r34606 because that re-enabled copy-on-scroll which 
had been accidentally turned off for several months. See if the problem goes 
away if you update gui to r34605
Eric

On 2012-01-23, at 4:30 PM, Germán Arias wrote:

> I have a problem with FisicaLab in SVN (I can't reproduce this problem with 
> other application).
> In the elements for static of rigid bodies, that are inside a scrollview, 
> when I use the mouse
> wheel to navigate all is OK. But if I use the scrollbar or the arrows, when I 
> move to down, the
> view show an ugly flickering. The content of this view is a copy of the 
> content of a window
> (staticRigidBodies.gorm file). This worked fine previously. So, I don't 
> understand where is
> the problem here. Thanks.
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Ugly flickering in some views

[Germán Arias]

I have a problem with FisicaLab in SVN (I can't reproduce this problem 
with other application).
In the elements for static of rigid bodies, that are inside a 
scrollview, when I use the mouse
wheel to navigate all is OK. But if I use the scrollbar or the arrows, 
when I move to down, the
view show an ugly flickering. The content of this view is a copy of 
the content of a window
(staticRigidBodies.gorm file). This worked fine previously. So, I 
don't understand where is

the problem here. Thanks.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls

[Eric Wasylishen]

I just found a bug caused by re-enabling copy-on-scroll.

Open TextEdit (https://github.com/ericwa/TextEdit), open a document or paste in 
some text, Choose "Format->Wrap to Page", set the zoom to 150%, and scroll 
horizontally, slowly. You'll see horizontal blurring. Seems that the regions 
being copied aren't pixel-aligned.

Should we just disable copy-on-scroll for this release? Ship with this bug? Try 
using -centerScanRect in 
-[NSView scrollRect: (NSRect)aRect by: (NSSize)delta]? I just fear trying to 
fix it now will create more bugs at the last minute...

Eric

On 2012-01-20, at 11:54 PM, Eric Wasylishen wrote:

> Hi, 
> This patch reverts part of r32955 which I committed last april but I now see 
> was a mistake, and I just discovered is breaking the  copy-on-scroll 
> behaviour of NSClipView - we end up always redrawing the entire visible 
> portion of the document view right now.
> 
> In r32955 I added [self setNeedsDisplay: YES] calls to -[NSView setBounds:], 
> -setBoundsOrigin:, and -setBoundsSize:, even though these are documented 
> explicitly as not marking the view for needing display. 
> (With r32955 I was trying to fix a bug in TextEdit, which calls 
> setBoundsSize: on NSClipView when you change the page zoom, and expects the 
> view to mark itself as needing display. This is actually a bug in TextEdit - 
> it should mark the clip view as needing redisplay itself.)
> 
> -Eric
> 
> 

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Eric Wasylishen]

I committed a fix. Please test both on-screen display, and the result of saving 
a PDF from Ink (print dialog->save button->foo.pdf). Both work for me with the 
font that was previously causing problems (DejaVu Sans - probably many others 
too).

Eric

On 2012-01-23, at 2:24 PM, Eric Wasylishen wrote:

> I actually narrowed it down and have a fix coming soon. This started when we 
> switched to the "modern" cairo surface I wrote. The bug is in the way 
> CairoFontInfo.m doesn't deal with the hinting settings of cairo_font_info_t.
> 
> Basically, it creates a default font options object and uses that to make 
> measurements of the glyphs. But, when it comes time to draw text with that 
> font on a xlib surface, which defaults to having hinting enabled, cairo draws 
> with hinting - so we have metrics calculated with no hinting, but drawing 
> with hinting, and get the resulting mess.
> 
> Eric
> 
> On 2012-01-23, at 1:55 PM, Fred Kiefer wrote:
> 
>> I would start with checking the screen resolution code as this seems to only 
>> affect monitors with strange geometry.
>> 
>> Sebastian, could you try to re-enable the old code in the method 
>> resolutionForScreen: (XGServerWindow.m) and see whether this make any 
>> difference? Could you also report the result of the command
>> xdpyinfo | grep -B2 resolution
>> on a monitor where this problem exists?
>> 
>> Fred
>> 
>> On 23.01.2012 20:33, Eric Wasylishen wrote:
>>> I just tested the last release (2011-04-14) of base/gui/back, and it
>>> looks like the text overlapping does not occur there. My test case is
>>> pasting a paragraph of text into Ink and setting the font to "DejaVu
>>> Sans". I'll try bisecting to find the revision that introduced the
>>> bug, and maybe it will be a quick fix.
>>> 
>>> Eric
>>> 
>>> On 2012-01-23, at 3:10 AM, Sebastian Reitenbach wrote:
>>> 
 Fred Kiefer  wrote:
> In order to get a full GNUstep release out before FOSDEM, that is
> at least base/gui/back, maybe also make, Richard, Eric and I have
> decided to put a code freeze for these libraries in place. Only
> strict bug fixes should go into the code over the next week (or
> maybe a bit longer) and everybody should try to find time to test
> the current code on as many different machines as possible.
> 
> There hasn't been a gui release in almost a year and now seems as
> good a time as ever. Feel free to report any bugs you find on the
> mailing list or even better in the bug tracker on Savannah.
 
 I hope this strange font drawing problem I've seen, and also
 Riccardo and Philippe have seen will also get fixed?
>> 
>> 
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Eric Wasylishen]

I actually narrowed it down and have a fix coming soon. This started when we 
switched to the "modern" cairo surface I wrote. The bug is in the way 
CairoFontInfo.m doesn't deal with the hinting settings of cairo_font_info_t.

Basically, it creates a default font options object and uses that to make 
measurements of the glyphs. But, when it comes time to draw text with that font 
on a xlib surface, which defaults to having hinting enabled, cairo draws with 
hinting - so we have metrics calculated with no hinting, but drawing with 
hinting, and get the resulting mess.

Eric

On 2012-01-23, at 1:55 PM, Fred Kiefer wrote:

> I would start with checking the screen resolution code as this seems to only 
> affect monitors with strange geometry.
> 
> Sebastian, could you try to re-enable the old code in the method 
> resolutionForScreen: (XGServerWindow.m) and see whether this make any 
> difference? Could you also report the result of the command
> xdpyinfo | grep -B2 resolution
> on a monitor where this problem exists?
> 
> Fred
> 
> On 23.01.2012 20:33, Eric Wasylishen wrote:
>> I just tested the last release (2011-04-14) of base/gui/back, and it
>> looks like the text overlapping does not occur there. My test case is
>> pasting a paragraph of text into Ink and setting the font to "DejaVu
>> Sans". I'll try bisecting to find the revision that introduced the
>> bug, and maybe it will be a quick fix.
>> 
>> Eric
>> 
>> On 2012-01-23, at 3:10 AM, Sebastian Reitenbach wrote:
>> 
>>> Fred Kiefer  wrote:
 In order to get a full GNUstep release out before FOSDEM, that is
 at least base/gui/back, maybe also make, Richard, Eric and I have
 decided to put a code freeze for these libraries in place. Only
 strict bug fixes should go into the code over the next week (or
 maybe a bit longer) and everybody should try to find time to test
 the current code on as many different machines as possible.
 
 There hasn't been a gui release in almost a year and now seems as
 good a time as ever. Feel free to report any bugs you find on the
 mailing list or even better in the bug tracker on Savannah.
>>> 
>>> I hope this strange font drawing problem I've seen, and also
>>> Riccardo and Philippe have seen will also get fixed?
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Fred Kiefer]

I would start with checking the screen resolution code as this seems to 
only affect monitors with strange geometry.


Sebastian, could you try to re-enable the old code in the method 
resolutionForScreen: (XGServerWindow.m) and see whether this make any 
difference? Could you also report the result of the command

xdpyinfo | grep -B2 resolution
on a monitor where this problem exists?

Fred

On 23.01.2012 20:33, Eric Wasylishen wrote:

I just tested the last release (2011-04-14) of base/gui/back, and it
looks like the text overlapping does not occur there. My test case is
pasting a paragraph of text into Ink and setting the font to "DejaVu
Sans". I'll try bisecting to find the revision that introduced the
bug, and maybe it will be a quick fix.

Eric

On 2012-01-23, at 3:10 AM, Sebastian Reitenbach wrote:


Fred Kiefer  wrote:

In order to get a full GNUstep release out before FOSDEM, that is
at least base/gui/back, maybe also make, Richard, Eric and I have
decided to put a code freeze for these libraries in place. Only
strict bug fixes should go into the code over the next week (or
maybe a bit longer) and everybody should try to find time to test
the current code on as many different machines as possible.

There hasn't been a gui release in almost a year and now seems as
good a time as ever. Feel free to report any bugs you find on the
mailing list or even better in the bug tracker on Savannah.


I hope this strange font drawing problem I've seen, and also
Riccardo and Philippe have seen will also get fixed?



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Eric Wasylishen]

I just tested the last release (2011-04-14) of base/gui/back, and it looks like 
the text overlapping does not occur there. My test case is pasting a paragraph 
of text into Ink and setting the font to "DejaVu Sans". I'll try bisecting to 
find the revision that introduced the bug, and maybe it will be a quick fix.

Eric

On 2012-01-23, at 3:10 AM, Sebastian Reitenbach wrote:

> Fred Kiefer  wrote: 
>> In order to get a full GNUstep release out before FOSDEM, that is at 
>> least base/gui/back, maybe also make, Richard, Eric and I have decided 
>> to put a code freeze for these libraries in place. Only strict bug fixes 
>> should go into the code over the next week (or maybe a bit longer) and 
>> everybody should try to find time to test the current code on as many 
>> different machines as possible.
>> 
>> There hasn't been a gui release in almost a year and now seems as good a 
>> time as ever. Feel free to report any bugs you find on the mailing list 
>> or even better in the bug tracker on Savannah.
> 
> I hope this strange font drawing problem I've seen, and also Riccardo and
> Philippe have seen will also get fixed? 
> 
> Sebastian
> 
> 
>> 
>> Fred
>> 
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>> 
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSXML* classes changed to use libxml2 directly... Should we merge this into the trunk?

[Ivan Vučica]

I'm currently working on an app that makes heavy use of NSXML*, with
the final goal of porting to Linux so I'm eager to try this out, and
can't wait for the code to make its way into trunk. Probably
post-FOSDEM?

If you want to test with my code, it is available here:
 http://bitbucket.org/ivucica/opml
Example file to try this out with:
 http://static.curry.com/worldoutline/admin/2012/01/06/archive149.opml

Some details on the code:
Editor was written upon request from Adam Curry who makes heavy use of
a platform called Frontier, which currently doesn't exist for Linux
and doesn't seem portable. This editor is an outliner, and edits .opml
files. These files are basically a way to store text content in
outlines, as well as to "include" other outlines over HTTP. This
editor already contains some GNUstep-related hacks, and opens a blank
file. None of hacks are related to my use of NSXML*, since I never got
it to work with NSXML*; previous GNUstep trunk I tested with died in
NSDocument's initWithData:, apparently because that method wasn't
implemented. Note that GNUstep version of the code currently makes use
of .xib files instead of .gorm or .nib files.

There is no way to add new nodes, to change level of nodes in the
outline. There is also no way to change outline node type nor outline
node attributes, such as the included outline's URL.

Latest committed version also reportedly crashes on OS X upon saving,
but I haven't worked on it since mailing the last build to Adam Curry
so I haven't confirmed this.

23. 1. 2012., u 18:17, Gregory Casamento  napisao:

> Hey guys,
>
> I originally implemented the NSXML(Document,Element,Node,etc) classes
> using NSXMLParser and keeping the information in arrays and
> dictionaries.   This was okay, up to a point, but would never work for
> XPath and XQuery functions unless you were willing to re-implement
> XPath.   By leveraging libxml2 it allows us to use any and all other
> libraries which use libxml2 to do operations on XML content.
>
> For this reason it was decided to change the implementation to use
> libxml2.  Currently the branch I created to develop these changes
> (nsxml_libxml2_changes) is much more mature and functional than the
> code that is currently on the trunk.
>
> I am soliciting the opinion of the group regarding adding this code
> into the trunk once it is ready so that people don't look at the
> already obsolete code on the trunk and begin making changes that are
> not relavant to the current direction it is going.
>
> Please let me know what all of you think.
>
> Thanks, GC
> --
> Gregory Casamento
> Open Logic Corporation, Principal Consultant
> yahoo/skype: greg_casamento, aol: gjcasa
> (240)274-9630 (Cell)
> http://www.gnustep.org
> http://heronsperch.blogspot.com
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

NSXML* classes changed to use libxml2 directly... Should we merge this into the trunk?

[Gregory Casamento]

Hey guys,

I originally implemented the NSXML(Document,Element,Node,etc) classes
using NSXMLParser and keeping the information in arrays and
dictionaries.   This was okay, up to a point, but would never work for
XPath and XQuery functions unless you were willing to re-implement
XPath.   By leveraging libxml2 it allows us to use any and all other
libraries which use libxml2 to do operations on XML content.

For this reason it was decided to change the implementation to use
libxml2.  Currently the branch I created to develop these changes
(nsxml_libxml2_changes) is much more mature and functional than the
code that is currently on the trunk.

I am soliciting the opinion of the group regarding adding this code
into the trunk once it is ready so that people don't look at the
already obsolete code on the trunk and begin making changes that are
not relavant to the current direction it is going.

Please let me know what all of you think.

Thanks, GC
-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSNumberFormater test fails [Was: GNUstep Code Freeze]

[Stefan Bidi]

On Mon, Jan 23, 2012 at 3:01 AM, Fred Kiefer  wrote:

> That bug description is not accurate. When running the NSNumberformatter
> test program we only call setlocale() twice, once with "" and once with
> NULL as the locale. That would be supported behaviour according to the bug
> description, but clearly it is not.
>

I'll attach that modified version to the bug report.

I changed your test program to call setlocale() and now it also reports NaN
> (See attachment). This really makes me wonder whether it is such a great
> idea to use an internationalisation library that only supports English :-(
>

In all fairness, it has been classified as bug in the library.  The
"official" way of setting the locale in ICU is using uloc_setDefault().  To
get the locale it's uloc_getDefault().  But I see your point and am a
little surprised that this is even an issue.  I'm even more surprised that
it keeps getting pushed off to a later release.  It seems to have
originally been scheduled for 4.6, then 4.8 and now 5.0.


> BTW: Is there a reason why the macro STRING_FROM_NUMBER calls the
> conversion twice, even when it was successful on the first attempt? I don't
> like the use of macros that much it really makes it hard to tell what is
> going on and code in macros never gets as much review as normal code.
>

No, it's wrong.  I saw that when mucking around in there, too, but didn't a
fix commit (I'll do so when I get home, today).  Don't ask me how I managed
to screw that up... I don't know either.

On 21.01.2012 23:00, Stefan Bidi wrote:
>
>> After running a few more tests and still not understanding what is going
>> on
>> I went to good and found this bug report:
>> http://bugs.icu-project.org/**trac/ticket/8214
>>
>> Seems that ICU does not like it when we use setlocale().
>>
>> On Sat, Jan 21, 2012 at 1:53 PM, Stefan Bidi
>>  wrote:
>>
>>  I am completely baffled by this bug.  I've been trying to debug this for
>>> the last 3 hrs and have gotten absolutely no where.  I added a unum_open
>>> and unum_formatDouble call in -init and I still get NaN when
>>> LANG=de_DE.UTF-8.  The test program continues to work without a hitch,
>>> though.  Something about how we handle the NSNumberFormatterInternal
>>> structure is screwing up UNumberFormat (I also added a unum_open and
>>> unum_formatDouble call in basic10_4.m and it worked fine).
>>>
>>>
>>> On Sat, Jan 21, 2012 at 11:00 AM, Stefan Bidi**
>>> wrote:
>>>
>>>  On Sat, Jan 21, 2012 at 10:41 AM, Fred Kiefer
  wrote:

  Your test code works fine here and results in 1.234 as expected. My
> $LANG is de_DE.UTF-8. And with $LANG set to C the test run fine.
> Strange enough currentLocale ends up being en_US_POSIX
>
>
 -currentLocale looks for a Locale default, if it exists that's what it
 uses.  Do you have that set?

 This still wouldn't explain why UNumberFormat is returning NaN.  Both
 you
 and Philippe have a valid locale.  On the plus side, if I set
 LANG=de_DE.UTF-8 I can reproduce this.  I'll go try to figure out what's
 going on.

>>>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GNUstep Code Freeze

[Sebastian Reitenbach]

Fred Kiefer  wrote: 
> In order to get a full GNUstep release out before FOSDEM, that is at 
> least base/gui/back, maybe also make, Richard, Eric and I have decided 
> to put a code freeze for these libraries in place. Only strict bug fixes 
> should go into the code over the next week (or maybe a bit longer) and 
> everybody should try to find time to test the current code on as many 
> different machines as possible.
> 
> There hasn't been a gui release in almost a year and now seems as good a 
> time as ever. Feel free to report any bugs you find on the mailing list 
> or even better in the bug tracker on Savannah.

I hope this strange font drawing problem I've seen, and also Riccardo and
Philippe have seen will also get fixed? 

Sebastian


> 
> Fred
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

NSNumberFormater test fails [Was: GNUstep Code Freeze]

[Fred Kiefer]

That bug description is not accurate. When running the NSNumberformatter 
test program we only call setlocale() twice, once with "" and once with 
NULL as the locale. That would be supported behaviour according to the 
bug description, but clearly it is not.


I changed your test program to call setlocale() and now it also reports 
NaN (See attachment). This really makes me wonder whether it is such a 
great idea to use an internationalisation library that only supports 
English :-(


BTW: Is there a reason why the macro STRING_FROM_NUMBER calls the 
conversion twice, even when it was successful on the first attempt? I 
don't like the use of macros that much it really makes it hard to tell 
what is going on and code in macros never gets as much review as normal 
code.



On 21.01.2012 23:00, Stefan Bidi wrote:

After running a few more tests and still not understanding what is going on
I went to good and found this bug report:
http://bugs.icu-project.org/trac/ticket/8214

Seems that ICU does not like it when we use setlocale().

On Sat, Jan 21, 2012 at 1:53 PM, Stefan Bidi  wrote:


I am completely baffled by this bug.  I've been trying to debug this for
the last 3 hrs and have gotten absolutely no where.  I added a unum_open
and unum_formatDouble call in -init and I still get NaN when
LANG=de_DE.UTF-8.  The test program continues to work without a hitch,
though.  Something about how we handle the NSNumberFormatterInternal
structure is screwing up UNumberFormat (I also added a unum_open and
unum_formatDouble call in basic10_4.m and it worked fine).


On Sat, Jan 21, 2012 at 11:00 AM, Stefan Bidiwrote:


On Sat, Jan 21, 2012 at 10:41 AM, Fred Kiefer  wrote:


Your test code works fine here and results in 1.234 as expected. My
$LANG is de_DE.UTF-8. And with $LANG set to C the test run fine.
Strange enough currentLocale ends up being en_US_POSIX



-currentLocale looks for a Locale default, if it exists that's what it
uses.  Do you have that set?

This still wouldn't explain why UNumberFormat is returning NaN.  Both you
and Philippe have a valid locale.  On the plus side, if I set
LANG=de_DE.UTF-8 I can reproduce this.  I'll go try to figure out what's
going on.
#include 
#include 
#include 
#include 

int main (void)
{
  UChar buffer[1024];
  UErrorCode err = U_ZERO_ERROR;
  int32_t len;
  UNumberFormat *fmt;
  UFILE *f;
  float num = 1234.00f;

  setlocale(LC_ALL, "");
  //fmt = unum_open (UNUM_DECIMAL, NULL, 0, NULL, NULL, &err);
  fmt = unum_open (UNUM_PATTERN_DECIMAL, NULL, 0, "de_DE", NULL, &err);
  len = unum_formatDouble (fmt, (double)num, buffer, 1024, NULL, &err);
  
  f = u_finit (stdout, NULL, NULL);
  u_fprintf (f, "%S\n", buffer);
  
  return 0;
}
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev