Re: fallback fonts? remote display - xlib
Hi All! Riccardo Mottola wrote: Have a look into the font cache file to see which fonts are detected. maybe you should delete that file and have it recreated. As you know the xlib backend is no longer supported especially not the XGFont class. You should check, why no better font support is found. after a long evening of hacking, I print out the results so we can keep track of them. font_cacher already generates a cache were several font names and font families are wrong! e.g. "Helvetica" is written as "HelveticA". The issues are between XGFontPropString, which gets it and makes it lowercase and XGFontFamily, which capitalizes it. Debugging with thousands of fonts is hard, so I put some code to debug "Helvetica" and this is what I found out: NSLog(@"|%s! |%@|", value, ret); NSLog(@"capitalized: %@", [ret capitalizedString]); 2020-06-17 22:40:32.606 font_cacher[16321:100855] |Helvetica! |helvetica| 2020-06-17 22:40:32.608 font_cacher[16321:100855] capitalized: HelveticA Here, the C string looks sane, the lowercase string too, but the capitalized string is totally bogus! if I cycle and print out the bytes of the C string they look fine: H 48 e 65 l 6c v 76 e 65 t 74 i 69 c 63 a 61 A bug! but where? in NSString? a short test case: s = [[NSString stringWithCString:"Helvetica"] lowercaseString]; NSLog(@"%@ - %@", s, [s capitalizedString]); which I suppose should be equivalent... works perfectly. I'm a bit clueless now. I admit I did not expect an overwhelming number of replies, still... a hint. I went further though. I thought to see exactly what comes in into NSString's capitalizedString. First question is... how to print out an unichar in NSLog? %c? or %C? I get the same results with both: 2020-06-22 21:43:30.598 font_cacher[22429:100817] capitalizing: semicondensed 2020-06-22 21:43:30.598 font_cacher[22429:100817] capitalizing: |s| 2020-06-22 21:43:30.598 font_cacher[22429:100817] capitalizing: |e| 2020-06-22 21:43:30.599 font_cacher[22429:100817] capitalizing: |c| 2020-06-22 21:43:30.599 font_cacher[22429:100817] capitalizing: |n| 2020-06-22 21:43:30.625 font_cacher[22429:100817] capitalizing: fixed 2020-06-22 21:43:30.625 font_cacher[22429:100817] capitalizing: |f| 2020-06-22 21:43:30.625 font_cacher[22429:100817] capitalizing: |i| I am printing out the string itself before, then any character before the conversion. It seems some skipping occours?
StepSync 0.1 : wrong path and folders empty
Hi Riccardo, I added some subfolders of subfolders... with new files to the source folder. F.e. : TRAVAIL/COURS/3LA/Dictee39 TRAVAIL/COURS/3LA/Dictee310 When I made a sync with StepSync to the target : 'TRAVAIL' on a removable device where the path 'COURS/3LA' was already there, I found two issues : 1) The new subfolders have been appended at the root of the Target folder 'TRAVAIL' : bad path. We should expect the new path to be created like 'mkdir -p in the CLI'. 2) And these folders were empty : we should not expect the files to be copied in each folder when the path is wrong. So the 2nd issue seemed linked to the first. I suspected something went wrong because the status between the two folders showed inconsistent numbers in the window of StepSync after it proceeded. Are you using something like rsync under the UI ? Maybe you already know those issues and planned to correct those in the upcoming release ? -- Regards, Patrick
Re: Trying to build GNUstep from git repo and clang-9 on Raspbian Buster (10.4)
I had no problems compiling gnustep9 on debian9-64bit on a raspberriy-pi. However as always on debian, you must use the gold linker not the default one. Otherwise hell breaks loose. And I didnt even try 32bit version (but it should work too from my experience in the past). The biggest problem for me under 32bit was to get a decent compiler version ( >= clang8) installed as the debian repo version has an issue which bites you with gnustep/libobjc2 badly. compiling clang from source under a Raspi is really no fun, especially if you dont have 8GB of RAM as the latest versions. 4GB might work but 2GB lets it constantly swap and being killed by OOM killer. -- Sent from Canary (https://canarymail.io) > On Friday, Jun 19, 2020 at 7:47 PM, Johannes Brakensiek > mailto:johan...@brakensiek.info)> wrote: > On 18 Jun 2020, at 10:46, David Chisnall wrote: > > > I did. Five years ago. Note that there was a bug until 15 months ago > > where the unwind info was not correctly set, so throwing an exception > > out of +initialize would potentially corrupt some floating point > > state. > > This runtime stuff really is higher arts for me, so I won’t be of much > help debugging. But I ran into an issue that seems to be connected to > something called „unwind“. ;) > > Looking into the git history it seems to be connected to lastest > commit/PR. > > https://github.com/gnustep/libobjc2/issues/164 > > It’s different to what Patrick reported, though. Running cmake with > clang-8 worked without issues. > > Johannes >
