Re: crash in NSPathUtilies / UserDefaults (from PikoPixel)
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)
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)
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
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...
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...
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...
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
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
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
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
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
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
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
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
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
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').