Re: crash in NSPathUtilies / UserDefaults (from PikoPixel)

[Josh Freeman]

Hi Riccardo,

  If you set a breakpoint at -[NSUserDefaults standardUserDefaults]  
and re-run PikoPixel, what is the backtrace where the breakpoint stops?


Thanks,

Josh


On Oct 22, 2015, at 9:28 AM, Riccardo Mottola wrote:


Hi,

I'm trying to run PikoPixel on current gnustep (almost) on NetBSD/ 
x86 compiled with GCC and its runtime.


The application crashes on startup deep inside base.

I suppose the stack is corrupt because the trace is infinite (check  
below), I don't get where from PikoPixel thi s is called from in the  
stacktrace. Thus I on't know how to create a smaller test program


if I try to check "domainName", I get a segmentation fault in gdb,  
thus it could be that that is invalid.



Riccardo


[Switching to LWP 1]
0xbb45f0e6 in NSUserName () at NSPathUtilities.m:1638
1638{
(gdb) bt
#0  0xbb45f0e6 in NSUserName () at NSPathUtilities.m:1638
#1  0xbb4ef957 in -[NSUserDefaults init] (self=0xb8a33750,
  _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m:1094
#2  0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
  self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
  _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#3  0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogSyslog)
  at NSUserDefaults.m:2116
#4  0xbb44115e in _NSLog_standard_printf_handler (
  message=0xbb70f460 <_OBJC_INSTANCE_1>) at NSLog.m:184
#5  0xbb4819ea in +[NSProcessInfo processInfo] (
  self=0xbb70f080 <_OBJC_Class_NSProcessInfo>,
  _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+400>) at NSProcessInfo.m:1015
#6  0xbb45f49d in InitialisePathUtilities () at NSPathUtilities.m:1154
#7  0xbb466d5b in GSDefaultsRootForUser  
(userName=userName@entry=0xb8cf1830)

  at NSPathUtilities.m:1883
#8  0xbb4efe3f in -[NSUserDefaults initWithUser:]  
(self=self@entry=0xb8a33710,
  _cmd=_cmd@entry=0xbb731850 <_OBJC_SELECTOR_TABLE+624>,  
userName=0xb8cf1830)

  at NSUserDefaults.m:1180
#9  0xbb4ef964 in -[NSUserDefaults init] (self=0xb8a33710,
  _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m:1094
#10 0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
  self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
  _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#11 0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogSyslog)
  at NSUserDefaults.m:2116
#12 0xbb44115e in _NSLog_standard_printf_handler (
  message=0xbb70f460 <_OBJC_INSTANCE_1>) at NSLog.m:184
#13 0xbb4819ea in +[NSProcessInfo processInfo] (
  self=0xbb70f080 <_OBJC_Class_NSProcessInfo>,
  _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+400>) at NSProcessInfo.m:1015
#14 0xbb45f49d in InitialisePathUtilities () at NSPathUtilities.m:1154
#15 0xbb466d5b in GSDefaultsRootForUser  
(userName=userName@entry=0xb8cf1830)

  at NSPathUtilities.m:1883
#16 0xbb4efe3f in -[NSUserDefaults initWithUser:]  
(self=self@entry=0xb8a336d0,
  _cmd=_cmd@entry=0xbb731850 <_OBJC_SELECTOR_TABLE+624>,  
userName=0xb8cf1830)

  at NSUserDefaults.m:1180
#17 0xbb4ef964 in -[NSUserDefaults init] (self=0xb8a336d0,
  _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m:1094
#18 0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
  self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
  _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#19 0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogSyslog)
  at NSUserDefaults.m:2116
#20 0xbb44115e in _NSLog_standard_printf_handler (
  message=0xbb70f460 <_OBJC_INSTANCE_1>) at NSLog.m:184
#21 0xbb4819ea in +[NSProcessInfo processInfo] (
  self=0xbb70f080 <_OBJC_Class_NSProcessInfo>,
  _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+400>) at NSProcessInfo.m:1015
#22 0xbb45f49d in InitialisePathUtilities () at NSPathUtilities.m:1154
#23 0xbb466d5b in GSDefaultsRootForUser  
(userName=userName@entry=0xb8cf1830)

  at NSPathUtilities.m:1883
#24 0xbb4efe3f in -[NSUserDefaults initWithUser:]  
(self=self@entry=0xb8a33690,
  _cmd=_cmd@entry=0xbb731850 <_OBJC_SELECTOR_TABLE+624>,  
userName=0xb8cf1830)

  at NSUserDefaults.m:1180
#25 0xbb4ef964 in -[NSUserDefaults init] (self=0xb8a33690,
  _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m:1094
#26 0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
  self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
  _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#27 0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogSyslog)
  at NSUserDefaults.m:2116
#28 0xbb44115e in _NSLog_standard_printf_handler (
  message=0xbb70f460 <_OBJC_INSTANCE_1>) at NSLog.m:184
#29 0xbb4819ea in +[NSProcessInfo processInfo] (
  self=0xbb70f080 <_OBJC_Class_NSProcessInfo>,
  _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+400>) at NSProcessInfo.m:1015
#30 0xbb45f49d in InitialisePathUtilities () at NSPathUtilities.m:1154
#31 0xbb466d5b in GSDefaultsRootForUser  
(userName=userName@entry=0xb8cf1830)

  at NSPathUtilities.m:1883
#32 0xbb4efe3f in -[NSUserDefaults initWithUser:]  
(self=self@entry=0xb8a33650,
  _cmd=_cmd@entry=0xbb731850 <_OBJC_SELECTOR_T

Re: crash in NSPathUtilies / UserDefaults (from PikoPixel)

[Josh Freeman]

Sorry, that breakpoint should be at +[NSUserDefaults  
standardUserDefaults] (class method not instance method).



On Oct 22, 2015, at 1:12 PM, Josh Freeman wrote:


Hi Riccardo,

 If you set a breakpoint at -[NSUserDefaults standardUserDefaults]  
and re-run PikoPixel, what is the backtrace where the breakpoint  
stops?


Thanks,

Josh


On Oct 22, 2015, at 9:28 AM, Riccardo Mottola wrote:


Hi,

I'm trying to run PikoPixel on current gnustep (almost) on NetBSD/ 
x86 compiled with GCC and its runtime.


The application crashes on startup deep inside base.

I suppose the stack is corrupt because the trace is infinite (check  
below), I don't get where from PikoPixel thi s is called from in  
the stacktrace. Thus I on't know how to create a smaller test program


if I try to check "domainName", I get a segmentation fault in gdb,  
thus it could be that that is invalid.



Riccardo


[Switching to LWP 1]
0xbb45f0e6 in NSUserName () at NSPathUtilities.m:1638
1638{
(gdb) bt
#0  0xbb45f0e6 in NSUserName () at NSPathUtilities.m:1638
#1  0xbb4ef957 in -[NSUserDefaults init] (self=0xb8a33750,
 _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m:1094
#2  0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
 self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
 _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#3  0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogSyslog)
 at NSUserDefaults.m:2116
#4  0xbb44115e in _NSLog_standard_printf_handler (
 message=0xbb70f460 <_OBJC_INSTANCE_1>) at NSLog.m:184
#5  0xbb4819ea in +[NSProcessInfo processInfo] (
 self=0xbb70f080 <_OBJC_Class_NSProcessInfo>,
 _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+400>) at NSProcessInfo.m:1015
#6  0xbb45f49d in InitialisePathUtilities () at NSPathUtilities.m: 
1154
#7  0xbb466d5b in GSDefaultsRootForUser  
(userName=userName@entry=0xb8cf1830)

 at NSPathUtilities.m:1883
#8  0xbb4efe3f in -[NSUserDefaults initWithUser:]  
(self=self@entry=0xb8a33710,
 _cmd=_cmd@entry=0xbb731850 <_OBJC_SELECTOR_TABLE+624>,  
userName=0xb8cf1830)

 at NSUserDefaults.m:1180
#9  0xbb4ef964 in -[NSUserDefaults init] (self=0xb8a33710,
 _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m:1094
#10 0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
 self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
 _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#11 0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogSyslog)
 at NSUserDefaults.m:2116
#12 0xbb44115e in _NSLog_standard_printf_handler (
 message=0xbb70f460 <_OBJC_INSTANCE_1>) at NSLog.m:184
#13 0xbb4819ea in +[NSProcessInfo processInfo] (
 self=0xbb70f080 <_OBJC_Class_NSProcessInfo>,
 _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+400>) at NSProcessInfo.m:1015
#14 0xbb45f49d in InitialisePathUtilities () at NSPathUtilities.m: 
1154
#15 0xbb466d5b in GSDefaultsRootForUser  
(userName=userName@entry=0xb8cf1830)

 at NSPathUtilities.m:1883
#16 0xbb4efe3f in -[NSUserDefaults initWithUser:]  
(self=self@entry=0xb8a336d0,
 _cmd=_cmd@entry=0xbb731850 <_OBJC_SELECTOR_TABLE+624>,  
userName=0xb8cf1830)

 at NSUserDefaults.m:1180
#17 0xbb4ef964 in -[NSUserDefaults init] (self=0xb8a336d0,
 _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m:1094
#18 0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
 self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
 _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#19 0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogSyslog)
 at NSUserDefaults.m:2116
#20 0xbb44115e in _NSLog_standard_printf_handler (
 message=0xbb70f460 <_OBJC_INSTANCE_1>) at NSLog.m:184
#21 0xbb4819ea in +[NSProcessInfo processInfo] (
 self=0xbb70f080 <_OBJC_Class_NSProcessInfo>,
 _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+400>) at NSProcessInfo.m:1015
#22 0xbb45f49d in InitialisePathUtilities () at NSPathUtilities.m: 
1154
#23 0xbb466d5b in GSDefaultsRootForUser  
(userName=userName@entry=0xb8cf1830)

 at NSPathUtilities.m:1883
#24 0xbb4efe3f in -[NSUserDefaults initWithUser:]  
(self=self@entry=0xb8a33690,
 _cmd=_cmd@entry=0xbb731850 <_OBJC_SELECTOR_TABLE+624>,  
userName=0xb8cf1830)

 at NSUserDefaults.m:1180
#25 0xbb4ef964 in -[NSUserDefaults init] (self=0xb8a33690,
 _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m:1094
#26 0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
 self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
 _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#27 0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogSyslog)
 at NSUserDefaults.m:2116
#28 0xbb44115e in _NSLog_standard_printf_handler (
 message=0xbb70f460 <_OBJC_INSTANCE_1>) at NSLog.m:184
#29 0xbb4819ea in +[NSProcessInfo processInfo] (
 self=0xbb70f080 <_OBJC_Class_NSProcessInfo>,
 _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+40

Re: crash in NSPathUtilies / UserDefaults (from PikoPixel)

[Josh Freeman]

Hi Riccardo,

   From the stack trace, it looks like the recursion begins with the  
call to [NSObject respondsToSelector: selector] in  
PPAppBootUtils_PerformNSObjectSelectorAfterAppLoads()  
(PPAppBootUtilities.m:42).


   Apparently on NetBSD, +load methods are called earlier in the app- 
bootup process than on Linux & Mac - on those platforms, I hadn't seen  
any issues from calling respondsToSelector: in +load.


   This'll be fixed in the next release of PikoPixel by delaying the  
respondsToSelector: check until after the app loads. In the meantime,  
you can probably get PikoPixel to run on NetBSD by commenting out the  
selector check (PPAppBootUtilities.m, lines 42-49):


/*
if (!selector || ![NSObject respondsToSelector: selector])
{
NSLog(@"ERROR: Invalid NSObject selector, %@, in "
"PPAppUtils_PerformNSObjectSelectorAfterAppLoads()",
(selector) ? NSStringFromSelector(selector) : @"NULL");

goto ERROR;
}
*/


Josh


On Oct 23, 2015, at 5:26 AM, Riccardo Mottola wrote:


Hallo,

Fred Kiefer wrote:

Hi Riccardo,

if you look at the line NSProcessInfo.m:1015 you will find:

  _NSLog_printf_handler(_GNU_MISSING_MAIN_FUNCTION_CALL);

Now it is definitely a problem that this line leads to a recursion  
and
somebody with more base knowledge should look into that. Most  
liekly the


Interesting is that there is a comment that NSAssert that can't be  
used to avoid recursion.


I put a breakpoint exactly there (NSProcessInfo.m:1015), the stack  
is not yet corrupted. I copy it below.


As one can think,
(gdb) p _gnu_processName
$1 = (struct NSString *) 0x0
(gdb) p _gnu_arguments
$2 = (struct NSArray *) 0x0
(gdb) p _gnu_environment
$3 = (struct NSDictionary *) 0x0

they are all NULL, probably they shouldn't, since that is the  
assert, however again, we shouldn't get a crash in the print  
statement: two bugs in one. I think this is stuff in base.


Thanks to this we know that the PP trace is:
PPAppBootUtilities.m:42
PPGNUstepGlue_TitleablePopUpButton.m:70

It looks as there is an invalid selector and this causes a crash.

I commented out + (void) load of PPGNUstepGlue_TitleablePopUpButton.m

But again I get a stimilar recursive stacktrace where the UserName  
is invalid.


All other application seem to run quite fine, I did run base tests  
and it doesn't look so bad:

7992 Passed tests
 38 Dashed hopes
  6 Failed tests
  5 Skipped sets

Only 6 failures:
Failed test: RecursiveLock.m:36 ... NSRecursiveLock  
isLockedByCurrentThread returns NO when not locked
Failed test: RecursiveLock.m:39 ... NSRecursiveLock  
isLockedByCurrentThread returns YES when not locked
Failed test: RecursiveLock.m:42 ... NSRecursiveLock  
isLockedByCurrentThread returns NO when unlocked

Failed test: basic10_4.m:111 ... format width set correctly
Failed test: basic10_4.m:115 ... positive prefix set correctly
Failed test: basic10_4.m:145 ... negativeFormat used for -ve  
number


and none seems to be related, although... well there should be none.


function GSPrivateDefaultsFlag() needs another safety hatch. But the
problem seems not to be related to PikoPixel directly. The only  
possible
connection that I see is that there user defaults get set from a  
+load
method (PPGNUstepGlue_ModifierKeys.m). You could comment out the  
code in

that +load method and see if this changes the behaviour for you.


Unfortunately, it doesn't help.

Riccardo


trace:
#0  +[NSProcessInfo processInfo] (self=0xbb70f080  
<_OBJC_Class_NSProcessInfo>,

   _cmd=0xbb706b70 <_OBJC_SELECTOR_TABLE+400>) at NSProcessInfo.m:1015
#1  0xbb45f49d in InitialisePathUtilities () at NSPathUtilities.m:1154
#2  0xbb466d5b in GSDefaultsRootForUser  
(userName=userName@entry=0xb8cf1830)

   at NSPathUtilities.m:1883
#3  0xbb4efe3f in -[NSUserDefaults initWithUser:]  
(self=self@entry=0xb8c61cd0,
   _cmd=_cmd@entry=0xbb731850 <_OBJC_SELECTOR_TABLE+624>,  
userName=0xb8cf1830)

   at NSUserDefaults.m:1180
#4  0xbb4ef964 in -[NSUserDefaults init] (self=0xb8c61cd0,
   _cmd=0xbb731778 <_OBJC_SELECTOR_TABLE+408>) at NSUserDefaults.m: 
1094

#5  0xbb4f0369 in +[NSUserDefaults standardUserDefaults] (
   self=0xbb731a60 <_OBJC_Class_NSUserDefaults>,
   _cmd=0xbb731758 <_OBJC_SELECTOR_TABLE+376>) at NSUserDefaults.m:779
#6  0xbb4f2467 in GSPrivateDefaultsFlag (type=type@entry=GSLogThread)
   at NSUserDefaults.m:2116
#7  0xbb441447 in NSLogv (format=format@entry=0xbb6cef44  
<_OBJC_INSTANCE_2>,
   args=args@entry=0xbfbfe768 "\260f 
\302\270\220\034\306\270\220\300\313\270$") at NSLog.m:354
#8  0xbb441957 in NSLog (format=format@entry=0xbb6cef44  
<_OBJC_INSTANCE_2>)

   at NSLog.m:297
#9  0xbb392004 in +[NSAutoreleasePool addObject:] (
   self=0xbb6cecc0 <_OBJC_Class_NSAutoreleasePool>,
   _cmd=0xbb703eb8 <_OBJC_SELECTOR_TABLE+120>, anObj=0xb8c266b0)
   at NSAutoreleasePool.m:538
#10 0xbb456e93 in -[NSObject autorelease] (self=0xb8c266b0,
   _cmd=0xbb6fcda0 <_OBJC_SELECTOR_TABLE+

Re: NSBitmapImageRep scaling/copying issue

[Josh Freeman]

Hi Riccardo,

   Ran PRICE 1.3.0 on OS X and saw some discoloration in an image's  
partially-transparent region after flipping it horizontally.


   The issue seems to be due to mismatched bitmap-formats: Bitmaps  
loaded from external data can be either premultiplied- or  
nonpremultiplied- alpha (in -[MyDocument  
loadDataRepresentation:ofType:], there's some Mac-only code that  
checks whether the loaded bitmap is nonpremultiplied, but the result  
is unused), and bitmaps generated by PRICE for pixel-data operations  
are always in the default premultiplied-alpha format (PRICE only uses  
the version of the -[NSBitmap initWithBitmapDataPlanes:...]  
initializer that doesn't include the bitmapFormat parameter). Copying  
pixel data directly from a nonpremultiplied to a premultiplied bitmap  
without reformatting the data can cause discoloration in partially- 
transparent areas.


   The horizontal-flip issue disappeared after switching the  
NSBitmapImageRep initializer call in -[PRTransforms flipImageHoriz:]  
to the version with the bitmapFormat: parameter (passing [srcImageRep  
bitmapFormat] as the value so the formats matched). Not counting  
flipImageHoriz:'s call, there are 20 more bitmap-initializer calls  
throughout the rest of the app - they'd need to be switched as well to  
fix format-mismatches in other operations.


   Another thing that can cause discoloration on OS X are mismatched  
bitmap color profiles (color management is currently unimplemented on  
GNUstep, so it's not affected): When copying pixel data directly  
between bitmaps, the bitmaps should have the same color profile,  
otherwise they'll render on the screen in different colors (despite  
identical pixel data).


   After generating a destination bitmap for a pixel-data operation,  
it should be assigned the source bitmap's color profile, if it has one:


{
...

destImageRep = [[NSBitmapImageRep alloc]  
initWithBitmapDataPlanes: ... ];


NSData *iccProfile = [srcImageRep valueForProperty:  
NSImageColorSyncProfileData];


if (iccProfile)
{
[destImageRep setProperty: NSImageColorSyncProfileData  
withValue: iccProfile];

}
}


Cheers,

Josh



On Apr 12, 2016, at 9:26 AM, Riccardo Mottola wrote:


Hi,

while trying to debug the issue betweeen GUI and GWorkspace icons  
with multi-page tiffs and high-res versions of our GUI controls, I  
noticed something strange.


I did a test-case on Mac where due to different backgrounds it is  
easier to detect.


The "scale" (but actually any) code I use IN PRICE and thus in also  
in GWorkspace appears to be broken, it produces artefacts with  
images with Alpha channel.


Even verys imple code, where I copy from the source to destination  
all "samples per pixels" copies all colors correctly, copies but  
produces effect around the borders and, apparently, on certain  
images it totally ruins alpha, on others not, just around the borders.


e.g in simplified pseudocode.

for (height)
 for (width)
   for (i in samples per pixel)
destData[xy +  i] = srcData[xy +i];

fails. The actual code is actually smarter and tries to use  
bytesPerRow.


Does a bell ring for anybody? I know that e.g. when scaling, pre- 
multiplied alpha should be considered, but this produces minor  
issues and should not affect just simple copying or flipping or  
such. The nested loops should essentially do a byte-copy.. and they  
do for images without alpha.


Riccardo

___
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: Newbie back again...

[Josh Freeman]

Hi Bertrand,

   Thanks for the info! I'm seeing the same issue - after making a  
clean GNUstep install from the trunk, any app built from it segfaults  
immediately, always in the same location: +[NSGraphicsContext  
setCurrentContext:]. This is on two different virtual machines, one  
with Ubuntu 16.04, the other with Linux Mint MATE 18.1 (both up-to- 
date, 32-bit, Clang 3.8).


   I've tried a few different ways of installing GS, including some  
old scripts that used to work, as well as the current "16.04 & 16.10"  
script from the "GNUstep under Ubuntu Linux" wiki page. I also tried  
disabling blocks & ARC, but still get the same problem: the apps  
(ProjectCenter, Gorm, GWorkspace, SystemPreferences, PikoPixel) build  
fine, then crash when run.


   One thing that still works is building with GCC & its runtime,  
though this means no blocks, ARC, etc. I've attached a modified  
version of the "16.04 & 16.10" wiki script that builds successfully  
with gcc on both of my machines. It doesn't have the 'sudo dpkg --add- 
architecture i386' line you added, so you might need to put that in  
(though it might no longer be an issue with the different runtime).  
Also, the script has libxft-dev uncapitalized, unlike yours where it's  
libXft-dev (didn't work on Ubuntu/Mint), so you might need to change  
it back for your machine.



   Regarding the crashes, here's what I've figured out so far:

- The crash is from trying to send an objc message to a non-object.
- The crash happens inside +[NSGraphicsContext setCurrentContext:] the  
first time it's called.
- Before crashing, setCurrentContext:'s local var, (NSThread *) th, is  
set to the current thread (return value of GSCurrentThread()), which  
is a valid object.
- setCurrentContext:'s passed parameter value, (NSGraphicsContext *)  
context, is also a valid object.
- th's instance var, (id) _gcontext (pointer to the current graphics  
context), however, contains a garbage value: 32.
- The crash happens inside the macro, ASSIGN(th->_gcontext, context) -  
after context is sent a retain message and stored in _gcontext,  
_gcontext's old value (32, non-object) is sent a release message.


   * Where did the 32 come from?

- Looking at NSThread.h, the instance var immediately before _gcontext  
is _autorelease_vars, an autorelease_thread_vars struct (5-member  
struct, defined in NSAutoreleasePool.h).
- When the [NSAutoreleasePool dealloc] method (NSAutoreleasePool.m: 
561) is called (every time an autorelease pool drains), a pointer to  
the current thread object's _autorelease_vars ivar struct is stored in  
dealloc's local var, (struct autorelease_thread_vars *) tv.
- dealloc passes tv to the local function, push_pool_to_cache()  
(NSAutoreleasePool.m:106), where - if the struct needs initialization  
- tv is then passed to another local function, init_pool_cache().
- init_pool_cache() (NSAutoreleasePool.m:98) sets the value of one of  
tv's struct members, (int) pool_cache_size, to the value 32.


   * How does the 32 move from _autorelease_vars to _gcontext?

- Looking at the autorelease_thread_vars definition in  
NSAutoreleasePool.h, pool_cache_size is the second-to-last member in  
the struct, so it's quite close in memory to its neighboring instance  
var, _gcontext: 8 bytes away, assuming no extra padding.


   * How does an address pointer lose/gain 8 bytes?

   Somehow NSAutoreleasePool.m (in base) and NSGraphicsContext.m (in  
gui) are in disagreement about the offsets to an NSThread object's  
instance vars: In NSAutoreleasePool.m, the statement  
(&((GSCurrentThread())->_autorelease_vars)) results in a memory  
address that is less than sizeof(struct autorelease_thread_vars) away  
from the memory address NSGraphicsContext.m calculates as the location  
of GSCurrentThread()->_gcontext; When init_pool_cache() sets the  
current thread's _autorelease_vars' pool_cache_size member near the  
end of the struct, it's writing the value 32 to the same address later  
used by setCurrentContext: as the current thread's _gcontext. (I  
verified this with a gdb memory watchpoint).


   The crash in +[NSGraphicsContext setCurrentContext:] also goes  
away if you add some extra padding bytes in the NSThread struct  
between _autorelease_vars & _gcontext (not that that's a solution - it  
just postpones the crash to a later point, in GSWindowDecorationView.m).


   So I think the ivar offsets disagreement is the condition that  
causes the crash - any ideas what's causing the condition? Possibly a  
config issue that's causing clang to use different struct padding  
settings between base & gui?


Cheers,

Josh




install-current-gnustep-with-gcc.sh
Description: Binary data






On Apr 22, 2017, at 11:03 PM, Bertrand Gmail wrote:

Preamble : sorry for the noise on gnustep-dev mailing list. I've  
reposted the messages here.


And...finally, it still doesn't work.

I thought that the problem had disappeared because I could compile  
and run a sample prog

Re: Newbie back again...

[Josh Freeman]

   Turns out the issue is with the placement of the objc-nonfragile- 
abi build flag in common.make, line 670: For some reason, the affected  
distros (seen so far on: Ubuntu 16.04, Mint 18.1, Debian Jessie;  
32bit, perhaps 64bit?) will build base & gui with mismatched and/or  
broken ABIs if -fobjc-nonfragile-abi is added to INTERNAL_OBJCFLAGS.  
It works fine, however, if fobjc-nonfragile-abi is instead added to  
INTERNAL_LDFLAGS, which is how it was in the trunk until a couple  
weeks ago:

https://github.com/gnustep/make/commit/d0263e4fb47d6529ac2dd1de913e5061618eb15f

   Reverting that change fixes the crashes, however, that will also  
break ARC, according to https://savannah.gnu.org/bugs/?50751 . I also  
tried installing with fobjc-nonfragile-abi added to both  
INTERNAL_OBJCFLAGS and INTERNAL_LDFLAGS (matching the pattern used for  
fobjcexceptions at common.make:662), but the crashes came back; Seems  
the problem is specifically with adding fobjc-nonfragile-abi to  
INTERNAL_OBJCFLAGS, regardless of whether it's also added to  
INTERNAL_LDFLAGS.


   Until we can find a permanent solution that hopefully fixes both  
the broken ABIs and ARC, here are some short-term workarounds to build  
a working GNUstep with clang/objc2 on the affected distros:


1) Build with the fragile ABI: Remove the --enable-objc-nonfragile-abi  
flag from the GS make's ./configure commands (both of them) in the  
build script. This also means you'll need to recompile your apps  
whenever you install new versions of the GS frameworks.


2) Build with an earlier version of make (though this will break ARC):  
In the build script, after changing to the make directory, but before  
configuring make (the first time it's built), add a git checkout  
command to force it to use a source-tree snapshot from before April 7:


...
cd make
git checkout `git rev-list -1 --first-parent --before=2017-04-06`
./configure --enable-debug-by-default --with-layout=gnustep --enable- 
objc-nonfragile-abi --enable-objc-arc

...

3) I attached a modified "16.04 & 16.10" script for Ubuntu/Mint from  
the wiki, which lets you build GS/objc2/libdispatch using checkouts  
from a particular date, set in the script's CHECKOUT_DATE var. (This  
automates the workaround in #2 above, but for all the source trees,  
not just make). It was useful in figuring out the abi issue, because  
then it just became a question of finding when the problem first  
appeared. It can also be helpful for testing apps on older GS versions  
(on Ubuntu or related distros).



Cheers,

Josh




install-gnustep-with-clang-from-date.sh
Description: Binary data






On Apr 23, 2017, at 4:18 PM, Fred Kiefer wrote:


Thank you Josh,

this was an excellent analysis. Did you try to unset  
GNUSTEP_BASE_LIBRARY in NSGraphicsContext.m? That should switch to  
the other code path that won’t use internal structures from base.


As for the problem with the NSThread ivars. What has changed on your  
test system? Do you think the change in on the GNUstep side or was  
there a behaviour change in clang?


Fred


Am 23.04.2017 um 09:39 schrieb Josh Freeman >:


Hi Bertrand,

 Thanks for the info! I'm seeing the same issue - after making a  
clean GNUstep install from the trunk, any app built from it  
segfaults immediately, always in the same location: + 
[NSGraphicsContext setCurrentContext:]. This is on two different  
virtual machines, one with Ubuntu 16.04, the other with Linux Mint  
MATE 18.1 (both up-to-date, 32-bit, Clang 3.8).


 I've tried a few different ways of installing GS, including some  
old scripts that used to work, as well as the current "16.04 &  
16.10" script from the "GNUstep under Ubuntu Linux" wiki page. I  
also tried disabling blocks & ARC, but still get the same problem:  
the apps (ProjectCenter, Gorm, GWorkspace, SystemPreferences,  
PikoPixel) build fine, then crash when run.


 One thing that still works is building with GCC & its runtime,  
though this means no blocks, ARC, etc. I've attached a modified  
version of the "16.04 & 16.10" wiki script that builds successfully  
with gcc on both of my machines. It doesn't have the 'sudo dpkg -- 
add-architecture i386' line you added, so you might need to put  
that in (though it might no longer be an issue with the different  
runtime). Also, the script has libxft-dev uncapitalized, unlike  
yours where it's libXft-dev (didn't work on Ubuntu/Mint), so you  
might need to change it back for your machine.



 Regarding the crashes, here's what I've figured out so far:

- The crash is from trying to send an objc message to a non-object.
- The crash happens inside +[NSGraphicsContext setCurrentContext:]  
the first time it's called.
- Before crashing, setCurrentContext:'s local var, (NSThread *) th,  
is set to the current thread (return value of GSCurrentThrea

Re: Newbie back again...

[Josh Freeman]

Sorry, the git checkout command for workaround #2 in my previous  
message is missing "master" at the end:



git checkout `git rev-list -1 --first-parent --before=2017-04-06`

should be:

git checkout `git rev-list -1 --first-parent --before=2017-04-06 master`


On Apr 23, 2017, at 6:34 PM, Josh Freeman wrote:

2) Build with an earlier version of make (though this will break  
ARC): In the build script, after changing to the make directory, but  
before configuring make (the first time it's built), add a git  
checkout command to force it to use a source-tree snapshot from  
before April 7:


...
cd make
git checkout `git rev-list -1 --first-parent --before=2017-04-06`
./configure --enable-debug-by-default --with-layout=gnustep --enable- 
objc-nonfragile-abi --enable-objc-arc

...



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

Re: error compiling GUI - string constants

[Josh Freeman]

On Jul 26, 2017, at 7:37 AM, Daniel Ferreira (theiostream) wrote:

Also, the reason it just does not assign the same const string to  
the different constants is because the two consts should be the same  
pointer, and doing it explicitly seemed like a good way to make that  
intent clear and guarantee that would happen.



   Changing the second string constant into a macro of the first  
would guarantee they're the same pointer:


APPKIT_EXPORT NSString *NSStringPboardType;

...

#if OS_API_VERSION(MAC_OS_X_VERSION_10_6, GS_API_LATEST)
#define NSPasteboardTypeString NSStringPboardType
#endif


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

Re: parent of a menu

[Josh Freeman]

   GNUstep's NSMenu.h declares some public GS-specific NSMenu methods  
for popup buttons (GNUstepExtra category):


- (BOOL) _ownedByPopUp;
- (NSPopUpButtonCell *)_owningPopUp;
- (void) _setOwnedByPopUp: (NSPopUpButtonCell*)popUp;

   However, unlike the other GNUstepExtra category methods, the above  
methods all have an underscore prefix - does that mean they're for  
internal use only?


Josh


On Sep 7, 2017, at 6:55 PM, Riccardo Mottola wrote:


Hi all,

to "fix" a behaviour in the WinUX Theme I think I need to know if a  
menu is part of a NSPopUpButton.

But how can I know this?
The supermenu appears to be null! I habe only the item and the menu,  
how can I determine that it is coming from a popupbutton (obviously  
I don't know all popupbuttons displayed, as some Cocoa tips&tricks  
suggest to do)..


Riccardo

___
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: freecell.app

[Josh Freeman]

Hi Gürkan,

On Oct 5, 2017, at 2:59 PM, Germán A. Arias wrote:


Hi,

El jue, 05-10-2017 a las 17:53 +0200, Gürkan Myczko escribió:

Hello

I was able to write a GNUmakefile to build Freecell.app for macOS,
however I'm missing
a link. Something with first responder maybe, or something in the
GNUmakefile?

Any help or tip is welcome.

https://github.com/alexmyczko/Freecell.app

Thanks,


Change your Makefile to look like this:

Freecell_LOCALIZED_RESOURCE_FILES=\
MainMenu.nib\
Credits.html\



   Thanks for porting Freecell, and thanks Germán for the fix. After  
changing the Makefile & rebuilding, Freecell seems to run fine, though  
there's a cosmetic issue while playing the game:


   On a Mac build, the selected (last-clicked) card is drawn darker  
than the other cards. On GNUstep, however, the selected card vanishes,  
and stays hidden until you click elsewhere (deselecting the card),  
then the card reappears.


   Turns out this is due to a bug in GNUstep GUI: If you have an  
NSImage that contains only non-cached image representations (such as  
an image that's just been created or loaded, but hasn't been used in a  
drawing operation yet), calling -[NSImage copy] on that image will  
return an empty image rather than a copy.


   This is because GNUstep's -[NSImage copyWithZone:] ignores non- 
cached image representations - only cached reps are moved to the copy.  
This is intentional, as there's a comment in the code saying to do  
this, however, it doesn't mention why. Does someone know the reason?  
(As a further note on -[NSImage copyWithZone:], the rep objects it  
attaches to the copied image should probably be copies themselves  
rather than the original's rep objects, otherwise you could lock focus  
on the copied image, draw onto it, and the original image would also  
be overwritten due to both images sharing the cached rep that was the  
draw target).


   Freecell draws selected cards using a set of darkened images that  
are initialized by copying the corresponding normal (non-selected)  
card's image, so the selected-card images all end up empty & invisible.


   Attached is a patch for Freecell.app that fixes the card-hiding  
issue by setting up the selected-card images without -[NSImage copy].  
The patch modifies only CardView.m - it assumes your GNUmakefile  
already has Germán's change.


Cheers,

Josh




Freecell_selection_fix.patch
Description: Binary data




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

Re: freecell.app

[Josh Freeman]

   In the current version of Freecell's GNUmakefile,  
Freecell_LOCALIZED_RESOURCE_FILES is missing an entry for the  
Localizable.strings file. (The previous version did include  
Localizable.strings, however, it also had an earlier entry that was  
commented-out, which broke the line continuity of the file list, so  
Localizable.strings didn't appear in Freecell_LOCALIZED_RESOURCE_FILES  
in the old version either).


   Try adding Localizable.strings to the  
Freecell_LOCALIZED_RESOURCE_FILES list & see if that fixes the issue.



On Oct 5, 2017, at 5:42 PM, Stefan Bidigaray wrote:

I think I have a similar problem to German's. The change to the  
makefile makes the application correctly, but then the menus do not  
have any text and the cards are not displayed. I'm using gui and  
back from GitHub, about 1 month old.


Free cell is a fun little game, so I look forward to this working.

On Oct 5, 2017 17:40, "Fred Kiefer"  wrote:

> Am 05.10.2017 um 20:59 schrieb Germán A. Arias :
>
>
> El jue, 05-10-2017 a las 17:53 +0200, Gürkan Myczko escribió:
>> Hello
>>
>> I was able to write a GNUmakefile to build Freecell.app for macOS,
>> however I'm missing
>> a link. Something with first responder maybe, or something in the
>> GNUmakefile?
>>
>> Any help or tip is welcome.
>>
>> https://github.com/alexmyczko/Freecell.app
>>
>> Thanks,
>
> Change your Makefile to look like this:
>
> Freecell_LOCALIZED_RESOURCE_FILES=\
>   MainMenu.nib\
>   Credits.html\
>
> However, after this change the app still don't work, because GNUstep
> can't read the nib file. The easy way to solve this, is provide the
> interface in a gorm file (ship both files in your app, the nib and  
the
> gorm file). Use Gorm.app to create this file, GNUstep will search  
for

> gorm file, if not present will try the nib file.

Strange, for me it is sufficient to make the suggested change in the  
GNUmakefile. The NIB file then loads correctly.


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: libobjc2 updates

[Josh Freeman]

Hi David,

   Thank you for your work on these fixes!

Cheers,

Josh


On Mar 31, 2019, at 7:58 AM, David Chisnall wrote:


Hello the list,

A kind volunteer gave me access to a BeagleBone Black running  
FreeBSD, so I have now been able to test the runtime with ARM  
(AArch32) and fixed a few issues:


- [Probably FreeBSD specific], on ARM .init_array initialisers are  
run, but .ctors are not, so the compiler needs to use .init_array  
for the call into the runtime to register a binary.  This is now  
fixed in upstream LLVM.


- The ARM objc_msgSend implementation no longer uses text  
relocations, so can be mapped read-only in the process.  This should  
fix it on 32-bit Android.  I also have a patch in the related issue  
for AArch64 - anyone with a 64-bit ARM system handy, please test it!


- The C++ exception structure used by the runtime did not  
incorporate the extra fields that the ARM EH ABI adds.  This caused  
some state corruption with Objective-C++ exceptions and is now fixed.


- [Possibly FreeBSD specific] the GNU unwinder on ARM appears to not  
quite follow the ARM EH ABI spec.  It calls the personality function  
to install the handler without doing a phase-1 search.  This is now  
worked around in the runtime.


The runtime (master branch, due to be released as 2.0) now passes  
all of the tests on ARM, except for a small number that are not  
architecture specific, but run out of memory on the test platform.


I've also fixed a few other bugs:

- A memory leak in @synchronized that Fred pointed out.  We only  
leaked a few bytes for every object used with @synchronized, but in  
a loop it was easy for this to be a problem.  I had not seen this  
issue because I avoid using @synchronized entirely.  It is a  
horrible feature in Objective-C and using __attribute__((cleanup))  
for the unlock in C (or RAII in C++) lets you accomplish the same  
thing with less inefficiency.  The feature wouldn't be such a  
problem if it were defined to send -lock / -unlock messages to the  
object, but requiring the runtime to maintain a lock for each object  
is awkward.


- There was an issue with static builds where the Protocol class was  
not being linked unless explicitly used outside of the runtime.   
This, in turn, broke the runtime's detection that the __objc_load  
function was being called for the runtime itself, which broke the  
ABI mismatch detection.  This is now fixed and static linking  
probably works again.


- The compiler occasionally emits negative offsets for ivars in the  
non-fragile ABI when, in the fragile ABI version of the class they  
would be within the space allocated by the superclass.  The runtime  
was not handling this correctly and so we were ending up with  
nonsense (sometimes negative) offsets for classes that contained  
BOOLs as their first fields if the compiler could see the layout of  
the superclass and it ended with something less than the size of a  
pointer.  This triggered some very odd behaviour in -gui with some  
non-default defaults values set (and almost certainly broke GSMime,  
though I didn't see any reports of that).


I have now tested and committed Dustin Howett's patches to clang for  
improving the Windows support.  It is now possible to use upstream  
clang (master branch, not any releases yet) to build WinObjC and  
have all of the tests pass (with some not-yet-merged patches to  
WinObjC, including updating their copy of libobjc2 to a recent trunk).


On Windows, we now have fully interoperable exceptions: The 2.0 ABI  
uses SEH-compatible exceptions and Objective-C++ code compiled with  
clang-cl will use the same ABI as the visual studio compiler for C++.


I have now moved the CI over to using Azure Pipelines, so there are  
CI builds on Windows and Ubuntu.  This should help avoiding  
regressions on Windows.


If you see any other issues, please report them on GitHub!

David


___
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: Next GNUstep release

[Josh Freeman]

Thank you, Ivan, and everyone who contributed to the new versions!  
Congratulations!


Cheers,

Josh


On Apr 13, 2020, at 8:13 PM, Ivan Vucica wrote:


And releases are now done!

Missing text in gui apps on Kubuntu

[Josh Freeman]

   Some users of Kubuntu (official flavor of Ubuntu with the KDE  
Plasma desktop) reported that PikoPixel's missing most of its UI text;  
Numbers are the only characters displayed:

https://old.reddit.com/r/Kubuntu/comments/gas88l/pikopixel_strange_graphics_bug_any_suggestions_on/

   I can reproduce this on Kubuntu 20.04, and the missing-text issue  
affects all GNUstep gui apps, whether the apps & GNUstep are from  
packages or from current sources.


   This might be the same issue that Patryk found last August with  
KDE Neon:

https://lists.gnu.org/archive/html/gnustep-dev/2019-08/msg00019.html
   (I couldn't test this, because the current x86_64 builds of KDE  
Neon fail to install on a VirtualBox VM, and older versions don't seem  
to be available).


   Manually installing a different desktop on Kubuntu doesn't fix the  
issue; Text is still missing on GS gui apps when run under GNOME or  
Window Maker, however, switching GS's backend from Cairo to Art fixes  
the text.


   Text displays correctly on Ubuntu 20.04 - even under Plasma - and  
also on a daily build of Ubuntu Studio 20.10 (Plasma is Studio's  
installed desktop as of 20.10).


   The issue's caused by a combination of two factors:

A) The Cairo backend sets up fontconfig patterns for font matching by  
calling the fontconfig library's Fc...Substitute() functions twice on  
each pattern instead of once:
   The backend's FCFaceInfo class has two methods, matchedPattern &  
characterSet, that each call FcConfigSubstitute() &  
FcDefaultSubstitute(), passing the FCFaceInfo instance member,  
_pattern, to be modified. Both methods in turn are called from within  
a single method, -[CairoFontInfo setupAttributes] (itself called from  
the FcFontInfo initializer):
   1. [CairoFontInfo setupAttributes]:[FcFontInfo (super)  
setupAttributes]:[FCFaceInfo characterSet]
   2. [CairoFontInfo setupAttributes]:[CairoFaceInfo fontFace]: 
[FCFaceInfo matchedPattern]
   Note that the font face is only generated after the second set of  
Fc...Substitute() calls.


B) The fontconfig library's font-matching functionality behaves  
differently on Kubuntu vs. other distros (even with the same version  
installed - Kubuntu 20.04 & Ubuntu 20.04 both have libfontconfig1  
2.13.1-2ubuntu3).



   Alone, neither factor causes the issue, however calling the  
Fc...Substitute() functions twice on the same pattern on Kubuntu  
leaves a modified pattern that - when passed to FcFontMatch() - always  
resolves to the "Noto Color Emoji" font. (That font has no alphabet  
characters, but does have digits, which explains why only numbers  
appear in the above linked screenshots).


   To demonstrate this, the attached C file, fc-pattern-check.c,  
builds a standalone diagnostic tool using only the fontconfig library  
- no GNUstep. It creates a fontconfig pattern for matching the "DejaVu  
Sans" font and makes two sets of calls to Fc...Substitute() &  
FcFontMatch(), duplicating the calls made by the Cairo backend. After  
each call, the resulting pattern is printed.


   The attached textfiles, fcpc_out_kubuntu.txt &  
fcpc_out_ubuntu.txt, are the outputs from running the fc-pattern-check  
tool on Kubuntu 20.04 & Ubuntu 20.04.


   Comparing the two output files, the first difference comes after  
the first call to FcConfigSubstitute(): On Kubuntu, the pattern has a  
"rgba" (pixel-format) field inserted - this may not contribute to the  
incorrect match, but it already shows a different behavior between  
Kubuntu & Ubuntu.


   Following the first set of Fc...Substitute() calls, the first call  
to FcFontMatch() correctly returns a resolved pattern for the "DejaVu  
Sans" font on both Ubuntu & Kubuntu. When these same first calls are  
made by the Cairo backend, the resolved pattern's used only to get the  
font's character set, not to generate the font face for drawing.


   After the second call to FcConfigSubstitute() on Kubuntu, the  
pattern's "lang" field for some reason now contains "und-zsye" (emoji  
locale) before its earlier value, "en" (english). The pattern now also  
contains a "color" field with a value of "True" (requiring a match to  
a font that contains color information). With those field values  
present, the second call to FcFontMatch() returns a resolved pattern  
for "Noto Color Emoji"; On Ubuntu, its second FcConfigSubstitute()  
call doesn't add those "lang" & "color" values to the pattern, and its  
second call to FcFontMatch() correctly returns a "Deja Vu Sans"  
resolved pattern.



   The attached patch, libs-back_fontconfig_pattern_fix.diff, fixes  
the missing text by limiting FCFaceInfo's Fc...Substitute() &  
FcFontMatch() calls to once per pattern. The resolved pattern returned  
by FcFontMatch() is now stored in FcFaceInfo's _pattern member (which  
previously only held a pre-matched pattern), and a new bool member,  
_patternIsResolved, keeps track of _pattern's pre-matched/resolved  
state.


   The characterSet method now gets 

Re: Missing text in gui apps on Kubuntu

[Josh Freeman]

ot;(w) 
"Noto Sans CJK SC"(w) "Noto Sans Arabic"(w) "Noto Sans Thai"(w) "Noto Sans 
Devanagari"(w) "Noto Sans Tamil"(w) "Noto Sans Hebrew"(w) "Noto Sans 
Bengali"(w) "Noto Sans Telugu"(w) "Noto Sans Kannada"(w) "Noto Sans 
Malayalam"(w) "Noto Sans Gurmukhi"(w) "Noto Sans Gujarati"(w) "Noto Sans 
Oriya"(w) "Noto Sans Armenian"(w) "Noto Sans Georgian"(w) "Noto Sans Khmer"(w) 
"Noto Sans Lao"(w) "Noto Sans Ethiopic"(w) "Noto Sans Myanmar"(w) "Noto Sans 
Sinhala"(w) "Jomolhari"(w) "Noto Sans Coptic"(w) "Noto Sans Deseret"(w) "Noto 
Sans TaiTham"(w) "Noto Sans CanadianAboriginal"(w) "Noto Sans Yi"(w) "Noto Sans 
Tifinagh"(w) "Noto Sans Adlam"(w) "Noto Sans Cherokee"(w) "Noto Sans Chakma"(w) 
"Noto Sans Osage"(w) "Noto Color Emoji"(w) "Noto Sans Symbols"(w) "Noto Sans 
Symbols2"(w) "DejaVu Sans"(w) "DejaVu Sans"(w) "DejaVu LGC Sans"(w) "DejaVu 
Sans"(w) "Bitstream Vera Sans"(w) "Verdana"(w) "Arial"(w) "Albany AMT"(w) "Luxi 
Sans"(w) "Nimbus Sans L"(w) "Nimbus Sans"(w) "Helvetica"(w) "Lucida Sans 
Unicode"(w) "BPG Glaho International"(w) "Tahoma"(w) "Noto Sans CJK JP"(w) 
"Noto Sans CJK KR"(w) "Noto Sans CJK SC"(w) "Noto Sans CJK TC"(w) "Noto Sans 
CJK HK"(w) "Droid Sans Fallback"(w) "Nachlieli"(w) "Lucida Sans Unicode"(w) 
"Yudit Unicode"(w) "Kerkis"(w) "ArmNet Helvetica"(w) "Artsounk"(w) "BPG UTF8 
M"(w) "Waree"(w) "Loma"(w) "Garuda"(w) "Umpush"(w) "Saysettha Unicode"(w) "JG 
Lao Old Arial"(w) "GF Zemen Unicode"(w) "Pigiarniq"(w) "B Davat"(w) "B 
Compset"(w) "Kacst-Qr"(w) "Urdu Nastaliq Unicode"(w) "Raghindi"(w) "Mukti 
Narrow"(w) "padmaa"(w) "Hapax Berbère"(w) "MS Gothic"(w) "UmePlus P Gothic"(w) 
"Microsoft YaHei"(w) "Microsoft JhengHei"(w) "WenQuanYi Zen Hei"(w) "WenQuanYi 
Bitmap Song"(w) "AR PL ShanHeiSun Uni"(w) "AR PL New Sung"(w) "MgOpen 
Moderna"(w) "MgOpen Modata"(w) "MgOpen Cosmetica"(w) "VL Gothic"(w) 
"IPAMonaGothic"(w) "IPAGothic"(w) "Sazanami Gothic"(w) "Kochi Gothic"(w) "AR PL 
KaitiM GB"(w) "AR PL KaitiM Big5"(w) "AR PL ShanHeiSun Uni"(w) "AR PL SungtiL 
GB"(w) "AR PL Mingti2L Big5"(w) "ＭＳ ゴシック"(w) "ZYSong18030"(w) 
"NanumGothic"(w) "UnDotum"(w) "Baekmuk Dotum"(w) "Baekmuk Gulim"(w) 
"KacstQura"(w) "Lohit Bengali"(w) "Lohit Gujarati"(w) "Lohit Hindi"(w) "Lohit 
Marathi"(w) "Lohit Maithili"(w) "Lohit Kashmiri"(w) "Lohit Konkani"(w) "Lohit 
Nepali"(w) "Lohit Sindhi"(w) "Lohit Punjabi"(w) "Lohit Tamil"(w) "Meera"(w) 
"Lohit Malayalam"(w) "Lohit Kannada"(w) "Lohit Telugu"(w) "Lohit Oriya"(w) 
"LKLUG"(w) "FreeSans"(w) "Arial Unicode MS"(w) "Arial Unicode"(w) "Code2000"(w) 
"Code2001"(w) "sans-serif"(w) "Roya"(w) "Koodak"(w) "Terafik"(w) "Roya"(w) 
"Koodak"(w) "Terafik"(w) "SimHei"(w) "Noto Sans CJK SC"(w) "Noto Sans CJK 
SC"(w) "黑体"(w) "Noto Sans CJK SC"(w) "Noto Sans CJK SC"(w) "sans-serif"(w) 
"sans-serif"(w) "Helvetica"(w) "Helvetica"(w) "Arial"(w) "Arial"(w) "Arial"(w) 
"Helvetica"(w) "Tinos"(w) "Noto Serif"(w) "Noto Serif CJK SC"(w) "Noto Naskh 
Arabic"(w) "Noto Serif Thai"(w) "Noto Serif Armenian"(w) "Noto Serif 
Georgian"(w) "Noto Serif Devanagari"(w) "Noto Serif Hebrew"(w) "Noto Serif 
Bangali"(w) "Noto Serif Gujarati"(w) "Noto Serif Kannada"(w) "Noto Serif 
Malayalam"(w) "Noto Serif Tamil"(w) "Noto Serif Telugu"(w) "Lohit Punjabi"(w) 
"Lohit Oriya"(w) "Noto Serif Khmer"(w) "Noto Serif Lao"(w) "Noto Serif 
Ethiopic"(w) &q

Re: ANN: GNUstep GUI Library 0.29.0

[Josh Freeman]

   Thank you, Ivan, and everyone else who contributed to this release!

Cheers,

Josh


On May 5, 2021, at 5:05 PM, Ivan Vučica wrote:


1 Announcement
**

This is version 0.29.0 of the GNUstep GUI library ('gnustep-gui').