Re: GUI and Back release
> On 29 May 2024, at 22:50, Riccardo Mottola wrote: > > Hi! > > Richard Frith-Macdonald wrote: >> Tanks. I just did make, base, gui and back releases on github. > > Wonderful. If you upload them on FTP I will update the webpage links! Thanks, I just uploaded the tarballs and signatures to the site (pub/gnustep/core).
Re: GUI and Back release
> On 26 May 2024, at 21:28, Fred Kiefer wrote: > > I generated the files that are needed for a GUI and back release. I don’t > have the means to generate the release itself. It would be creat if somebody > (Richard or Ivan) could do that right after the base release. Tanks. I just did make, base, gui and back releases on github.
Re: Object creation error
> NSArray *justSaySay = [NSArray arrayWithObjects: > @"there's NOBODY know CHINA than me", > @"there's NOBODY know AMERICAN than me", > @"there's ANYBODY know GNUSTEP than me" > ]; This will often crash, so it is probably the cause of your problem. The +arrayQWithObjects: method requires that the list of objects must be terminated. Otherwise it will try to interpret the contents of the memory location after the last object in the list as an object, which will usually cause a crash. The correct code is: NSArray *justSaySay = [NSArray arrayWithObjects: @"there's NOBODY know CHINA than me", @"there's NOBODY know AMERICAN than me", @"there's ANYBODY know GNUSTEP than me", nil ];
Re: Releases
> On 3 Jan 2023, at 10:16, Ivan Vučica wrote: > > Lest I forget, please also try to follow the process of adding the annotated > tag (preferably GPG signed, but at least annotated tag) so any release notes > displayed on Github release are also in the repo itself. > > I shared the Google doc with what I did for the last few releases. Happy to > demo over video to any maintainer that wants to see how I was doing the > releases. Please let me know if interested in a demo; I am available weekdays > at GMT evenings. I'm not sure what the point of the annotated tag actually is (I guess it's something that people who use git a lot are familiar with). If we want to make that a standard part of a release, can we add it to gnustep-make so that the 'make git-tag' target produces the annotated tag as well as tagging the release? I really would like to minimise the number of steps we have to go through by automating as much as possible.
Re: Releases
> On 28 Dec 2022, at 14:39, Gregory Casamento wrote: > > Hey Guys, > > I will be doing a corresponding release of Gorm since there have also been > improvements and bug fixes to it in the last year or so. > > Another thing I will be doing in the next couple of weeks is looking at FTP > hosting so that we can look into both restoring access to our historical > files as well as storing new files. I will be contacting the FSF to see if > they can set aside some space for us on their servers. As you know we used > to host our own at OXMIUM, but that is no longer the case (of course). Now > that we have a release and we also are anticipating the Debian release > deadline in January we really need the FTP site back. I discovered how to make the releases available on GitHub (turned out to be very easy), so there *is* somewhere people can download the tarballs from. Having am FSF site would be much better though. Reply encrypted using http://keys.gnupg.net:11371/pks/lookup?op=get&search=0x8fc6fd54cf3da610
Base Release
FYI, I have tagged a new gnustep-base release in the git repository as base-1_28_1
Releases
Happy Christmas. We don't have a gnustep.org machine to put releases on, but I have just made a gnustep-make release, tagged as gnustep-make-2.9.1in the git repository. I intend to make a gnustep-base release shortly too.
Re: Using clang-format for formatting our code
> On 16 Aug 2022, at 10:25, Hugo Melder wrote: > > Hi, > > Having a consistent code style is useful both for reading and writing code, > especially for contributors. The GNUstep base framework currently has a > .clang-format configuration file in the project root, but is not used. We > could use a configuration file from major Objective-C open source projects > like WebKit, or define our own formatting guidelines. > > What is your opinion towards strict code formatting? We have a coding/formatting style defined in the GNUstep base documentation (coding-standards.texi), and we try to make everything conform to that standard. However, I prefer *not* to refuse contributions based on stylistic deviations. Rather I would prefer to thank the contributor, correct any issues, and encourage use of the standard format in future contributions. If the .clang-format could be fixed to implement the GNUstep coding style, it might be useful for those of us who have it installed.
Re: Size difference between BOOL, WinBOOL, and BOOL results in incorrect archiving under Windows MSVC
> On 1 Aug 2022, at 11:10, Hugo Melder wrote: > > Hi Y’all, > > I'm currently investigating various libs-base test failures on Windows 11 > MSVC and I’m stuck on one particular failure involving the archiving and > unarchiving of primitives into a binary bundle > (Tests/base/coding/basictypes.m). > > Apple describes NSArchiver as “[..] a concrete subclass of NSCoder [and] > provides a way to encode objects into an architecture-independent format that > can be stored in a file”. That’s why the test has precomputed .type files > (e.g. BOOL-1.type) to validate the output of the archiver. > > This validation fails: On Windows 11 MSVC a bool is 4-bytes long, thus the > generated .type file is BOOL-4.type and the unarchive routine fails: > > Failed test: (2022-06-17 06:35:35.907 +) basictypes.m:157 ... can > unarchive BOOL from D:/a/libs-base/libs > base/source/Tests/base/coding/BOOL-1.type > > > Now, there has been some issues related to the difference between BOOL, > WinBOOL, and WINBOOL > (https://github.com/gnustep/libs-base/pull/247#discussion_r835060626). > > Here the difference: > • I can’t find the definition of WinBOOL anywhere in the Windows Kit > header files, nor online. > • WINBOOL seems to be implicitly defined by the compiler switch -Ze and > explicitly defined in GNUstep. > • BOOL is defined as typedef int in Windows.h. > > Maybe we can explicitly pack BOOL into one byte while archiving to maintain > the architecture-independent format, or redefine BOOL in GNUstep to the > correct size? I don't think it's easily done. Looking at the objc runtime headers, we have # ifdef STRICT_APPLE_COMPATIBILITY typedef signed char BOOL; # else # if defined(__vxworks) || defined(_WIN32) typedef int BOOL; # else typedef unsigned char BOOL; # endif # endif So for portabilty our coding/archiving ought to tolerate either byte or word length data in the archive as being valid bool data.
Re: Automated Reference Counting (Was: Disappointed by GNUstep)
> On 8 Feb 2022, at 13:01, David Chisnall wrote: > > On 08/02/2022 12:40, Richard Frith-Macdonald wrote: >>> On 8 Feb 2022, at 11:01, David Chisnall wrote: >>> I could write significantly simpler code that ran faster using >>> Objective-C++ and ARC than I could without either and GNUstep would not >>> accept the less-buggy and faster option. Refactoring code to make it less >>> maintainable so that it could compile with an old compiler and spending >>> time finding bugs that are impossible by construction with ARC felt like a >>> complete waste of my time. >> Well that could be a bit misleading: while GNUstep policy has not accepted >> breaking the portability of existing code it has never prohibited the >> addition of new non-portable features (though obviously portable is >> preferred). > > The granularity for enabling ARC is per compilation unit, which meant that it > could be used for entirely new classes, but not for much else, and even then > some of the private GNUstep headers are not ARC-safe (e.g. GSIMap.h) and so > you'd end up with two completely segregated worlds within the same codebase. Sure, it's not a problem at all. New features (substantial ones anyway) almost always mean new classes. The ability to select ARC for some files and not for others has worked very nicely for me.
Re: Automated Reference Counting (Was: Disappointed by GNUstep)
> On 8 Feb 2022, at 11:01, David Chisnall wrote: > I could write significantly simpler code that ran faster using > Objective-C++ and ARC than I could without either and GNUstep would not > accept the less-buggy and faster option. Refactoring code to make it less > maintainable so that it could compile with an old compiler and spending time > finding bugs that are impossible by construction with ARC felt like a > complete waste of my time. Well that could be a bit misleading: while GNUstep policy has not accepted breaking the portability of existing code it has never prohibited the addition of new non-portable features (though obviously portable is preferred). GNUstep has always encouraged contributions, and new contributors often have specific areas of expertise allowing them to contribute valuable code, but lack the expertise to make that portable. This has mostly been a factor with the windows/unix divide, where we would welcome an implementation of a new class for one platform (and work on or hope to get a contribution of another implementation of the other later), but we have compiler-specific areas of code too. There's a big difference between what is preferred (fully portable code for all features) and what is acceptable/unacceptable. We are conservative about keeping existing code working on existing platforms, but very liberal about new functionality. So the issue about moving to clang here is about a process/timescale for potentially refactoring existing core code in ways which would depend on clang.
minimum compiler requirements - fast enumeration
A few years ago we declared gcc-4.0 as our minimum supported compiler version. Does anyone know if gcc-4.0 support for fast enumeration actually works? If it does, it would be good to start using fast enumeration internally (in gnustep-base for instance). I'd like to do that as it gives us not only more readable/maintainable code, but also faster code in almost all cases.
Re: warning when compiling base and other programs
> On 24 Nov 2021, at 08:14, Frederik Seiffert wrote: > > Hi Riccardo, > >> Am 23.11.2021 um 23:34 schrieb Riccardo Mottola : >> >> in this case it is coming from gcc 7.5, but I have seen it in other gcc >> versions too. like gcc 11 > > Not sure then why the warning is happening, according to the GCC docs it > should be supported: > https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/Common-Function-Attributes.html#index-format_005farg-function-attribute > > I can see the warning also in the CI runs for GCC, but not with Clang. I > guess we could just enable it for Clang then (just like in Apple headers), > unless someone has another idea? I had only tried it with clang (assuming that modern gcc behaved the same way), but if it's a clang-specific feature then only enabling it for clang is better than not having it at all.
mail problems
Sorry all ... I have just found out that the reason gnustep mail has been so quiet the last few weeks is that my mail client hasn't been getting it! Specifically, stuff going to rich...@frithmacdonald.me.uk has not been getting to me. I need to find out what's been going on, but I think the service provider started flagging it all as junk mail and discarding it. Please resend anything important to richardfrithmacdon...@gmail.com
Re: Regular expressions
> On 16 Oct 2021, at 14:37, Daniel Santos wrote: > > Hi, > > Does GNUStep have some library for handling regular expressions ? > See the NSRegularExpression class in the GNUstep-base library. It wraps the regular expression support of ICU.
Re: base: running make in Documentation subdir broken
> On 22 Apr 2021, at 22:32, Ivan Vučica wrote: > > Hi, > > when running "Generating reference documentation...", the output is > now full of screenfuls upon screenfuls of: > > ../Headers/Foundation/NSNumberFormatter.h:501 Unexpected char (-) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:502 Unexpected char (-) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:504 Unexpected char (-) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:505 Unexpected char (-) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:507 Unexpected char (-) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:508 Unexpected char (-) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:510 Unexpected char (-) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:511 Unexpected char (-) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:515 Unexpected char (+) in > declaration > ../Headers/Foundation/NSNumberFormatter.h:523 Argh ... read '}' when > looking for ';' > ../Headers/Foundation/NSObject.h:292 Unexpected char (@) in declaration > ../Headers/Foundation/NSObject.h:308 Unexpected char (-) in declaration > ../Headers/Foundation/NSObject.h:312 Unexpected char (-) in declaration > ../Headers/Foundation/NSObject.h:315 Unexpected char (+) in declaration > ../Headers/Foundation/NSObject.h:316 Unexpected char (+) in declaration > ../Headers/Foundation/NSObject.h:317 Unexpected char (+) in declaration > ../Headers/Foundation/NSObject.h:339 Unexpected char (+) in declaration > ../Headers/Foundation/NSObject.h:364 Unexpected char (+) in declaration > > > I'm unfamiliar with how our doc generators work. What could we have > done to break them? Could this be releated to DLLEXPORT changes for > Windows? > > Richard, is this a release stopper? I suppose, but fortunately easy to fix; I added GS_EXPORT_CLASS to the set of 'words' the automatic generation should ignore when building base and base additions documentation.
Re: GNUstep releases this month?
> On 23 Mar 2021, at 10:02, Frederik Seiffert wrote: > > > >> Am 22.03.2021 um 18:19 schrieb Richard Frith-Macdonald >> : >> >>>> Throwing 0x247a578, in flight exception: 0x244e748 >>>> Exception caught by C++: 0 >> >> appears to be a libobjc bug (one that Riccardo mentioned to me). > > I think this is just debug output from libobjc2 exception handling, not an > error: > https://github.com/gnustep/libobjc2/blob/master/eh_personality.c#L197-L198 > > I’ll submit a PR to change these to DEBUG_LOG() so they are suppressed in > release builds. Thanks ... good to know that it's nothing that actually breaks the code.
Re: GNUstep releases this month?
> On 22 Mar 2021, at 17:41, Frederik Seiffert wrote: > > > >> Am 22.03.2021 um 18:19 schrieb Richard Frith-Macdonald >> : >> >> I was just looking at that. The tests are passing for me on debian-10 (gcc) >> and fedora-33 (with both gcc and clang with libobjc2 from some months ago) > > That’s good at least. > >> I'm guessing that the issue is a recent libobjc2 one though. > > This libobjc2 change would fit timing-wise, as it was done 2 days before my > commits but after the previous commits in Base that were still passing: > https://github.com/gnustep/libobjc2/commit/73132a6c9832d939f190742a326663a7dcebd339 > > I saw that in [GSFileHandle dealloc] we are calling -retain, which seems > unusual – not sure if that is supported by the runtime? If not, since we’re > throwing an exception anyway maybe we could just remove that call, or > implement the singleton differently by overriding retain/release? > > Also that test seems a bit misguided, as we’re calling release on an > autoreleased object... IIRC the standard/historic behavior is that an object can retain itself in the -dealloc method, to extend its own lifetime, and I guess that the singletons do that (I haven't checked). I think that behavior changed for ARC, so it could be that the runtime is performing an ARC style deallocation when it should be calling NSDeallocateObject() (or something odd is going on in the NSDeallocateObject() function).
Re: GNUstep releases this month?
> On 22 Mar 2021, at 15:25, Frederik Seiffert wrote: > > >> Am 19.03.2021 um 16:40 schrieb Ivan Vučica : >> >> I am thinking of doing it this weekend, any objection? > > > The NSFileHandle/singleton tests in Base have been failing for the last > couple commits. > > The test logs look like this – trying to release the singletons correctly > throws an exception, but then it seems that the retain count is still zero > for the singleton objects: > >> Passed test: (2021-03-17 16:59:18.407 +) singleton.m:18 ... stdin >> persists >> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:19 ... stdout >> persists >> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:20 ... strerr >> persists >> Throwing 0x244e538, in flight exception: (nil) >> Exception caught by C++: 0 >> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:21 ... Cannot >> dealloc stdin >> Throwing 0x244e748, in flight exception: 0x244e538 >> Exception caught by C++: 0 >> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:22 ... Cannot >> dealloc stdout >> Throwing 0x247a578, in flight exception: 0x244e748 >> Exception caught by C++: 0 >> Passed test: (2021-03-17 16:59:18.408 +) singleton.m:23 ... Cannot >> dealloc stderr >> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:24 ... stdin >> persists >> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:25 ... stdout >> persists >> Failed test: (2021-03-17 16:59:18.408 +) singleton.m:26 ... strerr >> persists > > > The failures started with one of these two commits from myself, but I cannot > figure out how they could have caused the above: > https://github.com/gnustep/libs-base/commit/54ae296b694187b0c92dfd9bb55dfea58f357e84 > https://github.com/gnustep/libs-base/commit/5fb5fb46c404601f6fe8d6bbb7ecaae0af7f0ba7 > > Any ideas about what might be going on here? Could any change in Make or > libobjc2 maybe have caused the above? I compared build logs between the last > successful runs and the failed runs. They were identical except for the > failed tests, but they also don’t show which version of the dependencies was > checked out so there might have been a difference there. I was just looking at that. The tests are passing for me on debian-10 (gcc) and fedora-33 (with both gcc and clang with libobjc2 from some months ago) The text >> Throwing 0x247a578, in flight exception: 0x244e748 >> Exception caught by C++: 0 appears to be a libobjc bug (one that Riccardo mentioned to me). But I don't know if this spurious output is related to the test failure. I'm guessing that the issue is a recent libobjc2 one though.
Re: GNUstep releases this month?
> On 2 Mar 2021, at 23:57, Riccardo Mottola wrote: > > Hi all! > > some important work was done the past fortnight... Richard and I did great > stuff in base! > > I had two concerns for a release > 1) in back we have a strange issue which is going on since past year and > which affects only windowmaker: on launch the app-icon was at first black, > now it is totally grey. It comes from various "fixes" Sergei did, but which > actually caused a regression compared to the old buggy code of the past > release! The bug happens only with the xlib and cairo backend, the art > backend just works fine. > > 2) mingw 64bit stopped working on several installation recently. While the > latest changes where thought to be the cause, actually it was old code using > a mix of old and even older win32 functions. Working with Fred, I cleaned > them all up to the newer level. > > I commited this tonight on a special "win64-fixes" branch - should be merged > before release. > > I think this fix is very important, things just worked "by chance" for a long > time and possibly broke with a mingw or windows update! It absolutely should > get into release if it is confirmed to work (or even not to harm, since it > improves for me and is technically correct) > > I encourage Richard and Gregory to test this branch and if it works for them, > thumbs up. I haven't actually tested, but I did look at the diffs and read up on the difference between Get/SetWindowLong and Get/SetWindowLongPtr, and it all makes sense to me ... I was unable to reproduce the problem on my system simply because, thorugh chance, the windows the system was giving me all existed in the low part of the address space. The only error is spotted in the change was in WIN32Server.m when styling a popup window ... here LONG (32bit) is used to hold the style information, where the API requires LONG_PTR (64bit). This would have the catastrophic effect of losing style information for popup windows for all those many users of 64bit windows on a big-endian CPU :-)
Re: GNUstep releases this month?
> On 27 Feb 2021, at 13:36, Fred Kiefer wrote: > > HI Ivan, > > still waiting for the thumbs up? You definitely got one from me :-) > > Riccardo and Richard fixed a few bugs in the meantime and there are surely a > few more to fix, but there always will be. We really should try to get a new > release out to the world. At the moment I am faced with a few bug fixes for > the GNUstep OBS packages that back port some ICU changes from the current > code over to the old releases. It would have been better to avoid that by > getting the releases out earlier. > > As I already wrote I did update the NEWS files for make, gui and back, but by > now they will be slightly outdated again. And for gui and back I already > increased the version number. For base you will need to extract the NEWS from > the ChangeLog file, but at least that should be updated. > Good point ... I think gnustep-make is in a good place now: I don't know of any outstanding issues that should prevent release. I have just updated ChangeLog for gnustep-base too, so I think that's now up to date and also in a decent state to go ahead and release.
Re: Windows ming64- loading resources in a Framework fails - bundleForClass
> On 25 Feb 2021, at 11:49, Richard Frith-Macdonald > wrote: > > > >> On 25 Feb 2021, at 11:05, Riccardo Mottola >> wrote: >> >> Hi, >> >> Richard Frith-Macdonald wrote: >>> It's a mistake/bug, or maybe they think people using mingw64 actually want >>> to cross-compile for mingw32 (seems perverse). >>> Anyway, it can be overridden by using --host=mingw64 when configuring >>> gnustep-make, as a command line argument takes precedence over information >>> from config.site >>> >> >> I actually found this informative info, which in case would also allow us to >> distinguis between the original mingw and mingw, if needed, the key is the >> w64 vs. pc >> >> Citing: >> >> This triplet specifies where the executables produced by this program (gcc) >> will run. Originally the >> MinGW.org project chose `*-pc-mingw32`, so we selected `*-w64-mingw32` to >> avoid the conflict. >> >> There is no special meaning about `w64` itself. `mingw32` on the other hand >> specifies the ABI, so >> all `i686-*-mingw32` targets are considered ABI-compatible. >> >> Neither does `w64` specify the target is 64-bit, nor does `mingw32` specify >> the target is 32-bit. >> They are just hard-coded names. > > Autoconf refers to the parts of the triplet as > CPU-TYPE-MANUFACTURER-OPERATING_SYSTEM > config.guess returns x86_64-pc-mingw64 > > I don't really buy the argument that mingw32 and mingw64 are ABI compatible > ... maybe it's technically/theoretically true for some definition of ABI, but > it's praqctically false since in practice the two are tied to different > processor architectures. > Certainly Autoconf (in the form opf config.guess) does not believe it. > > Still, since the mingw64 people seem to have chosen to do it this way, and > presumably can't easily change, and the autoconf people probably don't want > to change a standard that they 'own', I guess we will need to find a way to > work around the fact that, depending on where you get the triplet from, it > might say the system is mingw64 or might say it's mingw32. > We will need to find where gnustep-make looks for either, and put additional > checks in place for other parts of the triplet. Given that we can get either x86_64-w64-mingw32 or x86_64-pc-mingw64 depending on whether the information comes from autoconf or from a config file supplied by the mingw-w64 project, it seemd to me that we need to standardise within our system. Since we are currently expecting the 'os' part of the triplet to contain mingw64 on a mingw64 system, the simplest option was for the configure/configure.ac script to map the host vendor-os and target vendor-os from w64-mingw32 to pc-mingw64 and leave everything else unchanged.
Re: Windows ming64- loading resources in a Framework fails - bundleForClass
> On 25 Feb 2021, at 11:05, Riccardo Mottola wrote: > > Hi, > > Richard Frith-Macdonald wrote: >> It's a mistake/bug, or maybe they think people using mingw64 actually want >> to cross-compile for mingw32 (seems perverse). >> Anyway, it can be overridden by using --host=mingw64 when configuring >> gnustep-make, as a command line argument takes precedence over information >> from config.site >> > > I actually found this informative info, which in case would also allow us to > distinguis between the original mingw and mingw, if needed, the key is the > w64 vs. pc > > Citing: > > This triplet specifies where the executables produced by this program (gcc) > will run. Originally the > MinGW.org project chose `*-pc-mingw32`, so we selected `*-w64-mingw32` to > avoid the conflict. > > There is no special meaning about `w64` itself. `mingw32` on the other hand > specifies the ABI, so > all `i686-*-mingw32` targets are considered ABI-compatible. > > Neither does `w64` specify the target is 64-bit, nor does `mingw32` specify > the target is 32-bit. > They are just hard-coded names. Autoconf refers to the parts of the triplet as CPU-TYPE-MANUFACTURER-OPERATING_SYSTEM config.guess returns x86_64-pc-mingw64 I don't really buy the argument that mingw32 and mingw64 are ABI compatible ... maybe it's technically/theoretically true for some definition of ABI, but it's praqctically false since in practice the two are tied to different processor architectures. Certainly Autoconf (in the form opf config.guess) does not believe it. Still, since the mingw64 people seem to have chosen to do it this way, and presumably can't easily change, and the autoconf people probably don't want to change a standard that they 'own', I guess we will need to find a way to work around the fact that, depending on where you get the triplet from, it might say the system is mingw64 or might say it's mingw32. We will need to find where gnustep-make looks for either, and put additional checks in place for other parts of the triplet.
Re: Windows ming64- loading resources in a Framework fails - bundleForClass
> On 23 Feb 2021, at 23:08, Johannes Brakensiek > wrote: > > > yes, my bell is ringing. I went through a very similar issue nearly exactly > one year ago. > > This was the result: ... >> I see the list “frameworkClasses” is meant to be populated during the make >> process running “nm *.o -Pg” as part of EXTRACT_CLASS_NAMES_COMMAND. Defined >> in target.make, this command is used to look for lines output from nm >> starting with “__objc_class_name”. >> >> However, when I tried running nm manually on the objects in >> ProjectCenter.obj, grep shows *no* lines containing __objc_class_name. >> >> @David do you have any insight as to why the names of the classes are not be >> appearing? Should they be appearing? >> >> Regards, >> Patryk > > So I suspect mingw64 is writing class names in a format target.make does not > match when reading and embedding the class list of the framework? > Thanks a lot. That was a great hint. I was able to reproduce Riccardo's problem, and use your hint to investigate. Looking at the symbols in the object files, they began with __ (two underscores) Looking atwhat gnustep-make was doing, I could see it was looking for a prefix of three underscores The difference there is between mingw32 (uses three underscores) and mingw64 (uses two underscores, like linux/bsd etc). So I needed to figure out why gnustep-make was using the command for mingw32 on a mingw64 system. It turns out the culprit was /mingw64/etc/config.site setting the target host type to be mingw32 I don't know why it does that (it comes from the mingw/msys distribution) ... maybe it's a mistake/bug, or maybe they think people using mingw64 actually want to cross-compile for mingw32 (seems perverse). Anyway, it can be overridden by using --host=mingw64 when configuring gnustep-make, as a command line argument takes precedence over information from config.site
Re: all GUI apps crash on window
> On 20 Feb 2021, at 09:48, Richard Frith-Macdonald > wrote: > > > >> On 20 Feb 2021, at 07:59, Richard Frith-Macdonald >> wrote: >> >> >> >>> On 19 Feb 2021, at 23:38, Riccardo Mottola >>> wrote: >>> >>> Hello, >>> >>> >>> Then I tried Ink... it dies the same way. I fear this means "all apps crash" >>> >> >> I didn't have time to try more, but on 64bit windows I rebuilt >> gui/back/thematic using sources checked out a couple of weeks ago, with >> make/base checked out on thursday >> Thematic.app ran without problems. >> Maybe later I'll try the latest gui/back and/or try a completely clean >> install, but now I have to go do shopping etc. > > Actually, I now think my copy of make must not have been up to date ... it > looks like a change there may have broken things. But I've done *lots* of rebuild attempts now, including one where I deleted everything in /mingw64/Local before building/installing base/gui/back using code from git master today. Thematic is still working for me with that.
Re: all GUI apps crash on window
> On 20 Feb 2021, at 07:59, Richard Frith-Macdonald > wrote: > > > >> On 19 Feb 2021, at 23:38, Riccardo Mottola >> wrote: >> >> Hello, >> >> >> Then I tried Ink... it dies the same way. I fear this means "all apps crash" >> > > I didn't have time to try more, but on 64bit windows I rebuilt > gui/back/thematic using sources checked out a couple of weeks ago, with > make/base checked out on thursday > Thematic.app ran without problems. > Maybe later I'll try the latest gui/back and/or try a completely clean > install, but now I have to go do shopping etc. Actually, I now think my copy of make must not have been up to date ... it looks like a change there may have broken things.
Re: all GUI apps crash on window
> On 19 Feb 2021, at 23:38, Riccardo Mottola wrote: > > Hello, > > > Then I tried Ink... it dies the same way. I fear this means "all apps crash" > I didn't have time to try more, but on 64bit windows I rebuilt gui/back/thematic using sources checked out a couple of weeks ago, with make/base checked out on thursday Thematic.app ran without problems. Maybe later I'll try the latest gui/back and/or try a completely clean install, but now I have to go do shopping etc.
Re: GNUstep on Windows using Clang + MSVC ABI
> On 29 Jan 2021, at 16:28, David Chisnall wrote: > > We have given up supporting MinGW for snmalloc and I am considering > optionally supporting snmalloc for Objective-C object allocations since it is > much faster than the system malloc on most platforms and is particularly good > for fixed-size allocations as are common in Objective-C. It would be a shame > for this to be an everywhere-except-Windows thing. Hi David, I am giving snmalloc a try, but I'm wondering if (and why) you think it is actually better than mimalloc? As far as I can tell mimalloc ticks the general performance boxes and is admirably small (ie relatively simple code). My interest is probably unusual in that it's primarity about maintaining a low memeory footprint for long running processes rather than about speed, so if snmalloc does a better job of avoiding fragmentation it would be very appealing.
Re: strnstr errors in tests while on NetBSD
> On 22 Jan 2021, at 07:26, Riccardo Mottola wrote: > > Hi, > > while building tests on NetBSD/sparc I saw that many tests failed for > this reason: > > build.m:7:1: error: conflicting types for 'strnstr' > strnstr(const uint8_t *buf, unsigned len, const uint8_t *str) > ^ > In file included from > /home/multix/gnustep-svc/libs-base/Headers/GNUstepBase/GSConfig.h:430:0, > from > /home/multix/gnustep-svc/libs-base/Headers/GNUstepBase/GSVersionMacros.h:224, > from > /home/multix/gnustep-svc/libs-base/Headers/Foundation/Foundation.h:30, > from build.m:2: > /usr/include/string.h:107:7: note: previous declaration of 'strnstr' was > here > char *strnstr(const char *, const char *, size_t); > > > they don't even build. I don't know how that could fail 'many tests', because the only place in the entire sourcecode that uses strnstr is the GSMime tests. For that file, I simply changed the local function name to avoid conflict with the BSD function.
Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]
> On 21 Jan 2021, at 14:10, Richard Frith-Macdonald > wrote: > > > >> On 20 Jan 2021, at 19:48, Fred Kiefer wrote: >> >> >> >>> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola >>> : >>> >>> Hi, >>> >>> Fred Kiefer wrote: >>>>> I will try to bisect - but I'd liek to track this down before a release, >>>>> especially knowing it is something done these last months. >>>> If this is really a recent bug, not something that went unnoticed for >>>> years as nobody uses SPARC processors any more, than the only possible >>>> change would be the float parsing change that Richard just made. No idea >>>> why this would fail on something as simple as „1“ or „0“ but this is SPARC >>>> specific so you probably should start of by using the test suit of base on >>>> that machine. >>> >>> >>> Yes... I confirm it is a recent commit and I tracked it down to this commit: >>> >>> >>> r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30 >>> Dec 2020) | 2 lines >>> >>> Remove internal GSScanInt and GSScanDouble functions after moving >>> functionality into the -scanDouble: method. Add private class method to >>> support scanning a string for a double without having to create a new >>> scanner each time (use a shared lock-protected, instance with resetting >>> of the string being scanned). >>> >>> before this, all color look fine. >>> >>> I'm running the tests to see if some specific failed tests can be >>> identified ... but apparently they run sequentially on only one CPU and >>> it takes hours >>> >>> Anyway having an exact commit is also a good start. >> >> >> OK, so it is this code in [NSColor colorFromString:] >> >> >> double r, g, b; >> NSScanner *scanner = [[NSScanner alloc] initWithString: str]; >> >> if ([scanner scanDouble: &r] && >>[scanner scanDouble: &g] && >>[scanner scanDouble: &b] && >>[scanner isAtEnd]) >> >> In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. >> The next step would be to write a short test program that feeds these >> strings to the code above and outputs the values for r, g and b and of >> course the result of isAtEnd. That should make it easy to track down the >> issue. But you are the only one with a SPARC processor. > > Looks interesting ... do we have the data this is failing on anywhere? > If I can get a testcase to debug I can see what's going on. Never mind, I found/fixed it. Rather than waiting to find out what 'something like' meant exactly, I just tried testing with 1 1 1 and with 0 0 0 The problem was the second case ... I had placed a check in the code intended to avoid assigning the result of the scan via a nul pointer, but rather than checking the pointer i checked the result. That would mean that, in the case where the scanned value was zero, the result was not returned and the memory pointed to was undefined.
Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]
> On 20 Jan 2021, at 19:48, Fred Kiefer wrote: > > > >> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola : >> >> Hi, >> >> Fred Kiefer wrote: I will try to bisect - but I'd liek to track this down before a release, especially knowing it is something done these last months. >>> If this is really a recent bug, not something that went unnoticed for years >>> as nobody uses SPARC processors any more, than the only possible change >>> would be the float parsing change that Richard just made. No idea why this >>> would fail on something as simple as „1“ or „0“ but this is SPARC specific >>> so you probably should start of by using the test suit of base on that >>> machine. >> >> >> Yes... I confirm it is a recent commit and I tracked it down to this commit: >> >> >> r23416 | richard.frith.macdonald | 2020-12-30 12:58:19 +0100 (Wed, 30 >> Dec 2020) | 2 lines >> >> Remove internal GSScanInt and GSScanDouble functions after moving >> functionality into the -scanDouble: method. Add private class method to >> support scanning a string for a double without having to create a new >> scanner each time (use a shared lock-protected, instance with resetting >> of the string being scanned). >> >> before this, all color look fine. >> >> I'm running the tests to see if some specific failed tests can be >> identified ... but apparently they run sequentially on only one CPU and >> it takes hours >> >> Anyway having an exact commit is also a good start. > > > OK, so it is this code in [NSColor colorFromString:] > > > doubler, g, b; > NSScanner *scanner = [[NSScanner alloc] initWithString: str]; > > if ([scanner scanDouble: &r] && > [scanner scanDouble: &g] && > [scanner scanDouble: &b] && > [scanner isAtEnd]) > > In a previous mail you stated that str is something like „1 1 1“ or „0 0 0“. > The next step would be to write a short test program that feeds these strings > to the code above and outputs the values for r, g and b and of course the > result of isAtEnd. That should make it easy to track down the issue. But you > are the only one with a SPARC processor. Looks interesting ... do we have the data this is failing on anywhere? If I can get a testcase to debug I can see what's going on.
Re: GNUstep releases this month?
> On 18 Jan 2021, at 23:37, Ivan Vučica wrote: > > On Mon, Jan 18, 2021 at 9:49 PM Fred Kiefer wrote: >> I just added the new entries for news.texi for GNUstep make. While doing so >> I stated the upcoming release as 2.9.0 but giving it the number 2.8.1 would >> also be fine with me. There are only minor changes for this release. If you >> decide on a different number please remember to fix that file. >> >> Hope that makes your work easier, >> Fred > > Thanks. I'll wait for Richard's thumbs up and likely work on this over > the weekend. I just committed the merge of git log information into ChangeLog For anyone interested, the command I used to produce output, which I then edited by hand, was: git log --since=2020-04-05 --no-merges --pretty=format:"%ad %an <%ae>%n%n %s" --date=short --name-status | sed -e 's/^[A-Z]\t\(.*\)/\t* \1:/' >/ChangeLog.tmp I arrived at that after a lot of time wasted trying out things on the web that claimed to produce beautiful output or to produce standard/gnu stype ChangeLogs none of them did). Maybe, we could feed that output though further processing (to move the file names to correct position at the start of the ChangeLog entry rather than the end, and to split long commit comments up properly so that they are indented 8 spaces but not longer than 80). On the other hand, maybe going through and editing by hand is worthwhile (I did fix a number of typos).
Re: GNUstep releases this month?
> On 16 Jan 2021, at 19:50, Fred Kiefer wrote: > > I updated the required files and also increased the version number in both > gui and back. I think we normally do this right after a release, but this > time I forgot about it. So for these two modules we are theoretically ready > for a release. I think the base library is functionally OK, but I need to get ChangeLog updated from the git logs, and it turns out there is no tool that does a good job of this so it may take me a day or two.
Re: NSControls failing to set status/label on BigEndian/64bit
> On 7 Jan 2021, at 17:12, Wolfgang Lux wrote:
>
> Am 07.01.2021 um 14:33 schrieb Riccardo Mottola :
>>
>> Hi all,
>>
>>
>> Wolfgang Lux wrote:
>>> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods
>>> is a, errm, not so bright idea. The types are included in the binary
>>> archives. So, trying to decode a value with a different type will give you
>>> an error (for your own safety and sanity). Trying to encode values with a
>>> different type is even worse, as you would be creating archives that cannot
>>> be read by anybody else (because they are expecting some other type). If
>>> you (have to) make such changes, be sure to introduce a new archive version
>>> and be sure to include backward compatibility code for reading the old
>>> archive format.
>>
>> I had a call with Gregory yesterday.. since this is a delciate subject I
>> made a branch with a proposed initial change (as I have other controls
>> failing, it will not be the conly class affected either)
>>
>> BE-64-Fixes
>>
>> What do you think?
>
> I think that introducing a new archive format to address the issue with the
> _highlightsByMask and _altStateMask attributes is a bit over the top. Either
> decoding the attributes as NSUInteger values as Fred mentioned or decoding
> them as unsigned int into a temporary variable and then copying the values
> from those temporary variable into the respective attribute would do. BTW, I
> don't consider the latter a hack. It's a perfectly sane solution for dealing
> with backward compatible archives.
>
I just had a chance for a quick look.
It sounds like the problem is he code
[aCoder encodeValueOfObjCType: @encode(unsigned int)
at: &_highlightsByMask];
where _highlightsByMask is actually NSInteger (signed 64bit)
If you are on a big endian machine, that would presumably encode the upper
32bits of the value ... which are probably all zero ... so the data never gets
into the archive.
So I agree, the bugfix would be to copy _highlightsByMask (lower 32bits) into a
32bit unsigned integer value first
uint32_t tmp = (uint32_t) _highlightsByMask
[aCoder encodeValueOfObjCType: @encode(unsigned int) at: &tmp];
So the correct value is stored in the archive.
A similar change would be needed to decode into a uint32_t and then copy that
into place.
Re: NSControls failing to set status/label on BigEndian/64bit
Changing the type of the masks from NSInteger to uint32_t would also fix the encoding/decoding of course. Maybe that has other issues though.
Re: Crashes in GUI when applying a theme (Thematic)
> On 22 Nov 2020, at 22:09, Riccardo Mottola wrote: > > Hi, > > > Riccardo Mottola wrote: >> #0 0x772103ab in objc_msg_lookup () from >> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libobjc.so.4 >> #1 0x77bf976c in -[NSMenuView sizeToFit] (self=0x55da3560, >> _cmd=) >> at /System/Library/Headers/GNUstepBase/GSIArray.h:237 >> #2 0x77befa79 in -[NSMenu sizeToFit] (self=0x55db63f0, >> _cmd=) at NSMenu.m:1562 > > after a debugging evening with Fred, I know more, but am not much wiser. > > [NSMenuView sizeToFit] calls _attachedMenu and [attachedMenu _owningPopUp] > and the latter must be invalid because, if checked with "po" in gdb, it will > crash. > _owningPopUp just returns _popUpButtonCell which is set and trying to print > directly _attachedMenu->_popUpButtonCell does work, as inspecting it with p > *(_attachedMenu->_popUpButtonCell) but sometimes I found the isa pointer to > be 0x0 or in any case not accessible. > > So we suppose that either somehow has already invalidated the object or there > is memory overwriting. > Where in the chain Thematic - gui - base the issue is, remains open! My investigation confirms (I used NSZombieEnabled=YES and set a breakpoint at the log of the priblem, and lookd at the stack) that we have a deallocated object. Specifically the exception is in [[_attachedMenu _owningPopUp] pullsDown] when the -pullsDown message is sent to the _owningPopUp as a result of an NSMenuView receiving a GSThemeDidActivateNotification. Presumably the reason is that the NSMenuView has been detached from somthing in which the NSPopUpButtonCell has been deleted/deallocated, but as the view has not been deallocated it still receives the notification and tried to redraw. I think adding [_menu _setOwnedByPopUp: nil] and DESTROY(_menu) near the end of NSPopUpButtonCell's -dealloc may be the correct fix, since the popup owns/retains the menu and appears to be leaking it.
Re: Crashes in GUI when applying a theme (Thematic)
U tried playing around a bit, and managed to get an exception with the -pullsDown message being sent to a GSArrayEnumerator object ... that looked like a retain/release issue (message set to an object which had been deallocated and had the memory used by another object), so I set NSZombieEnabled=YES in the environment and retried. This time the zombie code reported -[NSPopUpButtonCell pullsDown]: message sent to deallocated instance So hopefully knowing what type of object was prematurely deallocated will help track the issue down.
Re: Lost information converting decoded value to in32_t
> On 25 May 2020, at 22:57, Riccardo Mottola wrote: > Looking up on the internet, I found the explanation is that the literal is > only the number part without signed, regarless if it is a signed or unsigned > decimal. Then the - operator is performed. For this reason it is usually > written as (-2147483647 -1) in the limits header files. > With that explanation, it is promoted to the "unsinged" type and then the "-" > operation fails and underflows. > > For that reason I propose to change the lower bounds check to an equivalent > easy to read >if (big > 2147483647 || big + 2147483648 < 0 Great ... I copied that t NSPortCoder.m
Re: Lost information converting decoded value to in32_t
> On 25 May 2020, at 19:38, Riccardo Mottola wrote: > > Hi, > > On 25/05/2020 09:50, Fred Kiefer wrote: >>> The first "halt" I get is when loading Attributes.gorm of GWorkspace's >>> Inspector >>> >> Looks like your archive has a value that gets encodes as an NSInteger and >> this is 32 bit on your current machine but the original encoded value was >> actually 64 bit and uses more than the 32 bit you are able to read. The best >> thing to do is to find out which value it is that causes the behaviour and >> encode (and decode) it as a long. >> >> And to answer your question, the message itself is surely not a bug, it just >> shows how clever base tries to deal with different encoded values. The >> actual encoding may be a bug. There it would really help to know where it is >> coming from. >> > > > Yes, I understand the error is not in the Unarchiver - I have seen the check. > > But my question is why should I have an invalid number in a Gorm file. So > either a bug in it, in some archiver or in some compatibility. > > From the stacktrace I couldn't undestand what exactly that value is. > > I hope it is not an issue of creating a gorm file on a 64bit machine and > reading it back on a 32bit or something like that! > > First thing, I will see if I can reproduce this on other machines. I do not > see this on my workstation, but it is running on 64bit, with a different OS > and with a different compiler and runtime :-P Too many differences. My best guess would be either something like NSNotFound (0x on 32bit 0x on 64bit) being encoded, or a negative integer accidentally being encoded as unsigned. Apart from that it's hard to find integer values which would break the 32bit boundary.
Re: 24-bit retain count
> On 21 May 2020, at 15:37, Larry Campbell wrote: > > Currently gnustep-base raises an exception if the retain count exceeds 24 > bits. There's a comment there: > > /* I've seen comments saying that some platforms only support up to > > * 24 bits in atomic locking, so raise an exception if we try to > > * go beyond 0xfe. > > */ > > Is this really true? On what platforms? 24 bits is really not a very big > number. (It is causing me pain right now.) It's probably not true of modern systems (certainly seems unlikely for 64bit systems). However, the code in NSObject.m was written to support a lot of old systems ... On the other hand, while 24bits is not huge (16 million) I think it's big enough so that hitting that limit is more likely to be a timely warning about a memory management error (the same object being retained repeatedly and never released) than a limitation, so making it a configurable limit rather than removing it altogether probably make sense (it is of course trivial to hack NSObject.m to remove it).
Re: CMake 3.16
> On 15 May 2020, at 11:02, David Chisnall wrote: > > What is the most recent cmake that is easy to install on your GNUstep > development systems? I'd like to get an idea of when moving to depending on > 3.16 (released last November) will be viable for most people. CentOS-7 comes with cmake-2.8.12, but there is also cmake-3.14.6 available (though annoyingly it installs using the name cmake3, leaving cmake-2.8.12 in place if you just type 'cmake').
Re: Next GNUstep release
> On 6 Apr 2020, at 09:53, David Chisnall wrote: > > I second that, thank you Ivan, but Fred your proposed solution is going to > add more barriers to entry. > > ChangeLog files made sense when people were submitting patches on the mailing > list and distributing code in tarballs. > > They were slightly anachronistic when CVS became standard for F/OSS projects > and incorporated per-file change messages but they were still useful when > people used them to describe the relationship between changes in multiple > files. > > They were mostly obsolete when projects moved to svn and commits became > atomic. Commit messages then referred to a set of related changes, rather > than to single files. The one remaining argument for them was that VCS > history may get lost in moves between revision control systems. > > There was also a minor justification for them based on tooling: commit > messages for svn were written after code review and some tools did not > support reviewing the commit message along with the code (things like > Phabricator did), so you could enforce a ChangeLog message in code review but > you could not enforce a commit message at the same time. > > We have now seen projects move from CVS to SVN and then to Git, preserving > commit messages. Git commits have evolved a structure that is well supported > by a load of tooling (vim even gives nice syntax highlighting to ensure that > you confirm to this structure, all of the Git GUIs, including GitHub, are > designed to render it), where the first line is short and gives a very > high-level summary of the changes and the remainder gives a detailed > overview. No equivalent tooling exists for ChangeLog files. > > In addition, a branch-and-PR workflow makes it possible to do code review of > commit messages before merging. Git makes it easy to edit and amend commit > messages and force-push a branch, so individual commits can have their > messages edited before a branch is merged. > > I would much rather see code review enforcing good commit messages, which is > a workflow that contributors to any other open source project will be > familiar with. I fail to see any benefit in having ChangeLog entries. > > Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file that > captures high-level user-visible improvements. We don't necessarily need PR > authors to write that, but the person merging a PR probably should if not. > This is far less granular than a commit message and serves a separate purpose. > > David Yes, thanks to Ivan. I have spent some time thinking about this, and while in the past I've argued against dropping ChangeLog (it's more convenient than the git logs, and of course is there for peple who download tarballs etc and don't have ready access to the repositories), but I think overall I kind of agree now. It's very onerous to put comments in multiple places, but there is value to each of these things: Technical information in the repository ChangeLog for easier access Announce/News for summary of important details. What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, in that we could auto-generate ChangeLog entries from the repository, either by an automated commit hook or (assuming that's not easy to do readily), using a script to get details from the repository just before we make a realease, so that anyone getting a release of the software still gets a comprehensive ChangeLog. Then we would be saved the overhead of writing ChangeLog entries and could concentrate on: 1. meaningful commit entries, which of course we should all be doing anyway ;-) 2. writing release notes for any substantive change (rather than ChangeLog entries for even minor changes), to appear in the NEWS when we make a release If we stop writing ChangeLog entries, we should be able to write release notes and still be spending less time, and of course that would make the process of cutting a release less onerous. Does this seem a reasonable approach?
Re: Next GNUstep release
> On 3 Apr 2020, at 01:26, Ivan Vučica wrote: > > It’s mainly up to the maintainer to decide to release including whether > things like that NSURLComponents change are risky. I suppose I should perhaps > get a final thumbs up from Richard (or you) regarding -base, but otherwise > it’s just a matter of ‘do I have the time to do it’, which may mean ‘do I > feel like I’m going to do a good job if I start doing this now’. Fred asked > for a -gui/-back release. > > Sunday would be a good time for me, but I am fine waiting. Also, if it’s not > a binary-breaking change, I can always cut an additional point release. Let > me know what you think. I think it's about time to make a release. I'm looking at the NSURLComponents stuff some more today, but as it's a new class (not in the previous release), as long as it compiler reliably (it does) it's not going to break anything and should not stop us making a release.
Re: compiling GNUstep on OpenBSD - various compiler/runtime options
> On 3 Jan 2020, at 00:34, Riccardo Mottola wrote: > > Hi All! > > > I am testing Niels' fork of make... and OpenBSD is one of the candidates, > since I have since long issues with gcc there. I hope we can fix it because I > like what Niels is doing there. > > Just to make some clarity, let me sum up what is my knowledge: > > We have two compilers: gcc and clang. > > We have two runtime libraries: gcc one and libobjc2 in our repo by David. > David's runtime can be used in "gnu" and "ng" mode. Correct? However there is > no need to configure it, it is the same library built and installed the same > which then supports both (save bugs). > > GCC of course supports only "gnu", its own runtime and and libobjc2 but only > in "gnu" mode. > > Clang can be again used in both ng and gnu, but of course only with libobjc2 > since it has no own runtime. > > This gives us the following combinations possible: > > 1) gcc + own runtime (make detects this config all by itself) > > 2) gcc + libobjc2 (make configured with gnu-gnu-gnu) > > 3) clang + libobjc2 and make configured gnu-gnu-gnu > > 4) clang + libobjc2 and make configured ng-gnu-gnu The introduction of the ng runtime specification was supposed to mean that we *don't* have those four options: it means we support only two setups (1) and (4) above. The combinations you list as (2) and (3) are unsupported/invalid because 1. means the original (also called legacy) objc 4. means all the latest next-gen stuff (next-gen because we didn't want to use the objc-2.0 lable) There's nothing in between as a simple recognition of the realities of what compiler works reliably with each runtime. In practice, clang may be able to build code for the old runtime (so individuals might get 3 to work for them, but we can't support them)
Re: Debugging on Linux with non-fragile ABI?
> On 18 Nov 2019, at 09:35, David Chisnall wrote:
>
> Hi,
>
> Neither debugger currently knows anything about the non-fragile ABI. The
> Apple runtimes have a few introspection functions that are called without
> acquiring the necessary locks, which are intended to be called by the
> debugger, but someone needs to write the relevant code in either gdb or lldb
> and let me know what hooks they'd like. The lldb code is relatively
> approachable and the Objective-C runtime interfaces are quite well
> abstracted, so it would be fairly simple to add.
>
> Note that lldb probably does not give you the correct layout, especially for
> anything that is not a base class. It looks as if it's relying on the
> compiler's guess of where ivars will be, which is not always correct in the
> non-fragile ABI.
>
> Materialising ivar offsets is relatively easy. The change is basically to
> use a different symbol name for the ivar offsets.
>
> If no one has the time or inclination to do this, then I'd recommend calling
> the runtime introspection functions directly from the {g,ll}db command line.
> These will give you the correct layouts. It's a little bit clunky (though
> would be easy to wrap in a plug-in function), but these can give you the type
> and offset of each ivar and let you write some pointer arithmetic that shows
> you the correct ivar.
Interesting. I'd very much like to see support for nonfragile objects in
debuggers.
How could this work for core dumps? Is it even possible to examine instance
variables in core dumps when the nonfragile ABI is used?
Re: Issues subclassing NSMutableArray
> On 17 Nov 2019, at 15:08, Riccardo Mottola wrote:
>
> Hi!
>
>
> I wanted to subclass NSMutableArray, so that I can easily add some extra
> methods.
>
> I declared my subclass like this:
>
> @interface FileArray : NSMutableArray
> {
>
> }
>
>
> However, when I run my app, I get this:
>
> StepSync.app/StepSync: Uncaught exception NSInvalidArgumentException, reason:
> [FileArray-addObject:] should be overridden by subclass
>
> I did override all concrete methods in the easiest possible way, calling
> super. For addObject I did:
>
> - (void)addObject:(id)anObject
> {
> [super addObject:anObject];
> }
>
>
> why is this not enough or not working in any case?
Because NSMutable array is an abstract class. You need to create a concrete
class with actual instance variables to store data in.
In your case you overrode the superclass implementation, but did do by calling
the superclass implementation ... which is abstract and can't do anything. You
have to override the implementation in a way that actually adds the object to a
storage area.
What you could have done to get the effect you seem to want is have a concrete
instance do the work for you:
@interface FileArray : NSMutableArray
{
NSMutableArray*content;
}
@end
@implementation FileArray
- (void) addObject: (id)anObject
{
[content addObject: anObject];
}
- (void) dealloc
{
[content release];
[super dealloc];
}
- (id) initWithCapacity: (NSUInteger)capacity
{
content = [[NSMutableArray alloc] initWithCapacity: capacity];
return self;
}
etc.
In this case the line
content = [[NSMutableArray alloc] initWithCapacity: capacity];
will actually create a GSMutableArray instance (a concrete subclass) that your
class implementation can use to store the objects.
Re: Gitflow proposal
> On 15 Nov 2019, at 08:16, Fred Kiefer wrote: > > First off before I explain why I am strongly against Gitflow let me restate > that I advocate feature branches and pull requests. But I will come back to > that in the end. > > A software workflow should match the organisation and purpose of a project > and the people that defined Gitflow are well aware of that. They describe > what sort of projects Gitflow is suited for. GNUstep does not meet that > criteria. Even in the place where I work we decided against Gitflow as it is > not well suited for our processes. I could go into details here but I believe > you are all able to follow the link below and read the description. > > Also it won’t work. Nobody is getting payed to review pull requests on > GNUstep. If I started to write pull requests for GNUstep gun, they would be > sitting there for a year or so without anybody noticing. > > The bigger problem is that even Gitflow won’t help us with our quality > issues. Over the last few months I have tried to provide comments to most of > the pull requests in the GNUstep repository. I do this a lot at work and > doing so comes naturally to me. Most of the developers react positive by > fixing the issues I point to. There is one exception and please look it up in > git to see the difference. In that case many of my comments did get ignored > others, where flagged as done although no change was made and sometimes > branches where merged even when travis reported them as broken or while I had > objected merging them. So even a workflow that enforces all this is of no use > in this case. > > And it could be even worse. With Gitflow in place as a rule, Riccardo and I > could have been stopped from doing the emergency fixes we did last night to > get master compiling again (and not only for gcc, Riccardo's change must have > fixed compilation of clang as well). As long as we have rogue developers with > full permissions out there, we need ways to counteract. > > So yes, let's use more branches and pull requests but especially those > developers that break the build. And if we ever manage to get them to follow > that rules we might start to think about more process I broadly agree, though my reasoning may be a litte different. I'm someone who finds it very hard (and very time consuming) to try to comment in ways that people won't find offensive, so a system where I'm called upon to comment more is very bad for me (and might end up putting other people off too); with complex changes I also find it much more efficient to speak rather than exchanging comments (and people who know me will know how hard it is to get me to pick up the phone). I rather like committing all small changes directly to trunk so that a maximum number of people in a small team will see them and fix/report errors. I even feel it maks sense to do large/complex things in a branch and then merge the branch into trunk. On the other hand, I sympathise with people who don't like to find trunk broken; we clearly have people who want to keep up to date with trunk but don't want their builds to fail etc. So I guess my ideal would be to mostly work on trunk but have automated build/test environments testing it and updating a another branch only to revisions where all the automated builds/tests have passed. Non developers could then use that branch rather than trunk.
Re: make error in base on Solaris
> On 18 Oct 2019, at 09:36, Richard Frith-Macdonald > wrote: > However, gnu-make (I'm not an expert, just reading the documentation) allows > double-colon rules, where you can huve multiple rules for a target each with > a separate recipe (as long as there are no single colon rules for the same > target). > So it might be possible to change this code to > > base.make:: Version >./configure > > base.make:: config.status base.make.in >./$< $@ > > However I don't know whether that would cause dependency issues (eg the first > rule creates a config.status, and then the second rule gets applied as well). That seemed to work in a few tests I did, so I comitted it ... would be good if someoen more knowledgable could check though. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: make error in base on Solaris
> On 17 Oct 2019, at 22:28, Riccardo Mottola via Gnustep-dev > wrote: > > Stefan Bidigaray wrote: >> Ah... Sorry about that. When I looked at your original email this morning I >> saw the config.status line and just assumed that's where the error was >> coming from. > > --trace was of help > >> >> So it looks like the file comparison options of test are not portable. The >> Heirloom project's sh, for example, does not provide it. [1] >> >> The code in line 105 is quite old, so I'm surprised you haven't run into >> this problem before. Git blame says it's 5 years old [2]. > > It is! to be honest, I remember to have seen this problem before, but I never > experienced it "hard blocking" like today. > I think I was used to always to a clean build or run configure manually, in > that case it disappears. > > Your cited manpages shows the options I have on Solaris, apparently. > >>I wonder how it can be made more portable. Or, having bash, if I >>can run >> >> >> Maybe the solution is to simply revert this particular change? The old code >> in this section of the Makefile looks reasonable. Honestly, I do not >> understand why we would use the "-nt" options in a Makefile, to begin with. >> The purpose of the make utility is exactly to run commands based on the age >> of the files' dependencies, so why would we do this manually with shell >> commands? >> > > Exactly - the goal of make is itself timestamp dependency, so I don't get > that part of the patch, maybe it can be partially reverted. Or it was some > strange kind of workaround? > > It is of Yavor, but Richard applied, maybe he can chime in to the discussion. The idea here (explained in the commnt) is to avoid lengthy unnecessary reconfigurations: # If the generated makefiles are present but their prerequisites have # changed, let config.status regenerate them. This is much faster and # equally safe than running configure again, provided that configure # has not been modified. So the choice here is to do a full (slow) configure if the version has changed, but otherwise do a fast reconfigure, and it looks like a good idea (saving quite a bit of time). The current rules say: base.make: config.status base.make.in Version # If Version is newer than the target, configure must be rerun so that # its variables get AC_SUBST'ed and actually updated in base.make. @if [ Version -nt $@ ]; then ./configure; else ./$< $@; fi I think the reason for this code is that one target (base.make in this case) can only have one 'recipe' to build it, so the recipe makes a decision about what to do based on the age of Version. However, gnu-make (I'm not an expert, just reading the documentation) allows double-colon rules, where you can huve multiple rules for a target each with a separate recipe (as long as there are no single colon rules for the same target). So it might be possible to change this code to base.make:: Version ./configure base.make:: config.status base.make.in ./$< $@ However I don't know whether that would cause dependency issues (eg the first rule creates a config.status, and then the second rule gets applied as well). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: error compiling latest base on FreeBSD (ihex)
> On 15 Apr 2019, at 23:54, Riccardo Mottola wrote: > > Hi, > > just tried to updated base on FreeBSD-amd64 /clang but it fails. I did re-run > configure. > > Linking tool cvtenc ... > Compiling file AGSParser.m ... > ../Source/./obj/libgnustep-base.so: undefined reference to `ishex' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > gmake[4]: *** [/System/Library/Makefiles/Instance/tool.make:89: obj/cvtenc] > Error 1 > > > Any clues? Seems likely to be related to pollution of the global namespace with new functions (though the error message appears to suggest the opposite). I changed that code (getting rid of ishex while fixing a couple of other issues); please try now. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Escape from the UK/Brexit ... update
As usual, things have not been working out as scheduled, but we are finally in to our new home in Kilkenny. We have no furniture and are sleeping on camping mats, but have most of our kitchen stuff installed, so we can cook proper meals. Our broadband installation never happened: because the telegraph poll the cable would be coming from has not been certified as safe to climb. I'm told that means a delay typically 3 to 10 days before I will have a broadband connection again :-( > On 30 Mar 2019, at 10:02, Richard Frith-Macdonald wrote: > > FYI > This week we emptied our house in Cornwall, putting things into storage in > Waterford, Ireland. > We are hoping to complete buying a much smaller place in Kilkenny City in > just over a week. > After that we will need to move in to the new place as quickly as we can > (selecting/discarding any furniture etc that won't fit), and also get an > internet connection there. > So I'm expecting to get some degree of stability (and a decent network > connection) by mid to late April. > Hopefully I will then be able to spend a bit more time on GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Escape from the UK/Brexit ... update
FYI This week we emptied our house in Cornwall, putting things into storage in Waterford, Ireland. We are hoping to complete buying a much smaller place in Kilkenny City in just over a week. After that we will need to move in to the new place as quickly as we can (selecting/discarding any furniture etc that won't fit), and also get an internet connection there. So I'm expecting to get some degree of stability (and a decent network connection) by mid to late April. Hopefully I will then be able to spend a bit more time on GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: GNUstep Base 1.26.0
Thanks for all your work on the release, particularly on base, since I *should* have been the person doing that, and would like to apologise for being out of touch on this. I'm hoping to be much more active in a few months time. It's great to see a new release of GNUstep out. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Runtime / exceptions model configuration options
> On 6 Jun 2018, at 13:55, Riccardo Mottola wrote: > > Hi All, > > I am a bit confused about how to configure different exceptions and runtimes > in gnustep make and gui! > > I notice we have no clear section in a README or INSTALL file or on the wiki, > or, in case, I missed it. > > I need to control of it to correctly test libobjc2 by David and also to avoid > this error: > > "There are two separate exception handling mechanisms available ... one > based on the standard setjmp() function (which does not require special > compiler support), and one 'native' version where the compiler manages the > exception handling. If you try to use both in the same executable, exception > handlers will not work... which can be pretty disastrous. This error is > telling you that the gnustep-base library was built using one form of > exception handling, but that the gnustep-make package you are using is > building code to use the other form of exception handling ... with the > consequence that exception handling would be broken in the program you are > building. So, somehow your gnustep-base and gnustep-make package are > incompatible, and you need to replace one of them with a version configured > to match the other." > > So we have standard and native. > > I understand that standard is default for gcc. Fine. > > The issue is when wanting to use libobjc2 and/or clang. > > gnustep-make if used with clang enables native exceptions (most probably > becausde it is clang's default) > > I think that if I use --with-library-combo=ng-gnu-gnu on gnustep-base I > enable automatically also native exceptions > > How can I build e.g. with clang and standard exceptions? do I need to pass > specific CFLAGS perhaps or do we have ebtter options? I didn't find any. > > For example, would like to compile code with clang but standard exceptions, > so that I can rule out gcc issues with libobjc2. Generally you can use 'configure --help' to find out this sort of thing. In this case, it tells me --disable-native-objc-exceptions Disable native Objective-C exception support (@try / @catch / @finally / @synchronized). If unspecified, Objective-C exception support is enabled if the compiler can compile Objective-C code containing @try / @catch / @finally / @synchronized. Please note that native exceptions also require support in the Objective-C runtime; GNUstep-base will check for that support and may still disable native exceptions if such support is not available. Use this option if you do not want to use the native Objective-C exception support provided by newer compilers. So the default is for gnustep-make to use native exceptions, but you can override it using --disable-native-objc-exceptions, and you may need to be aware that, if the compiler/runtime gnustep-base sees at configure time does not support native exceptions, then the base configure process may override the setting from when you configured make. I don't think there should ever be a problem if you configure gnustep-make to use traditional setjmp based exceptions though. NB. make sure you have a clean instuall when changing this stuff ... if you have some libraries/code built one way and some libraries/code built the other way then you will get problems. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: -make option to specify runtime?
> On 4 May 2018, at 09:52, David Chisnall wrote: > > Hello the list, > > For testing the runtime’s 2.0 ABI, I am patching my post-install Makefiles to > set -fobjc-runtime=2.0 instead of whatever the default is (1.7?). Please can > someone who understands how -make works add a configure-time option so that > you can specify the runtime version? The current objc-runtime flag sets 1.8 If you are talking about overriding normal behavior, gnustep, make already provides the abiliity to filter out flags (even for individual files), so I expect you could add the option in your individual make file to filter out the 1.8 setting and add a 2.0 setting. On the other hand, if you just want a quick global change in gnustep-make behavior then edit library-combo.make to say 2.0 rather than 1.8 If you are talking about changing the normal behavior for everyone, using autoconf is the way to do that ... the autoconf script should, at configure time, execute macros to determine what runtime version your compiler/runtime support. It would then generate the makefiles to use that version. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Segmentation Faults - OpenBSD
> On 13 Apr 2018, at 00:31, Riccardo Mottola wrote:
>
> Hi,
>
> Richard just commited some promising fixes.
>
> Things seem better, but not stable. Here a summary of the current status.
> OpenBSD seems fine on x86, on amd64 I get some strange issues that might not
> be related
>
> FreeBSD/amd64/clang
> - seems to work with all apps I tried
> - One test failure:
> base/NSException/basic.m:
> Failed test: basic.m:51 ... addresses and symbols match
Pretty harmles ... the system doesn't have the code needed to generate
backtrace symbols. I've added a change to report the addresses an the fact
that symbols are not available ... it'll stop the test complaining.
> OpenBSD/i386/gcc
> - seems to work fine
> - Two test failures
> base/NSException/basic.m:
> Failed test: basic.m:51 ... addresses and symbols match
> base/NSProcessInfo/general.m:
> Failed test: general.m:48 ... -systemUptime works
That looks like simple missing information (we lack system specific code to get
the information), and has presumably never passed on that platform.
> NetBSD/amd64/gcc
> things mostly work, but apps spit out an incredible number of errors, like
> below:
>
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without
> pool for object (0x72c8521602f0) of class GSDictionary in thread 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without
> pool for object (0x72c852161c60) of class GSNotification in thread 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without
> pool for object (0x72c854dfed90) of class NSFont in thread 0x72c855daa4c0>{name = (null), num = 126204759418048}
> 2018-04-13 01:03:53.147 Ink[6322:126204759418048] autorelease called without
> pool for object (0x72c854dfe790) of class NSFont in thread 0x72c855daa4c0>{name = (null), num = 126204759418048}
It would be good to know why this system doesn't have an autorelease pool in
place when others do. You could try setting a breakpoint where this is logged
and looking at the stacktrace to see how that point in the code was reached.
> NetBSD/i386/gcc
> plmerge "works" however all gui apps crash
This is the only one that looks really concerning. The log doesn't report the
reason for the crash, but it appears to be in the pthread library code ...
suggesting some form of memory corruption or perhaps linking issue. You might
try running under valgrind to see if that gives any clues.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: New ABI NSConstantString
> On 8 Apr 2018, at 12:41, David Chisnall wrote: > > On 8 Apr 2018, at 10:55, Richard Frith-Macdonald > wrote: >> >> >> >>> On 6 Apr 2018, at 11:00, David Chisnall wrote: >>> >>> It would probably help catch more bugs if we made use of NSString’s >>> class-cluster nature more in -base. I have just fixed a bug in GSString >>> where we were checking one object matched a particular class before >>> dereferencing the _flags ivar of the other. I caught this because the >>> other was a GSTinyString, which is almost never a valid pointer. >> >> Possibly, but performance *is* an issue here. The NSString code was >> rewritten some years ago (moving away from them use of class cluster >> features) as a result of extensive profiling of real-world applications >> which were running too slow, precisely because NSString methods are very >> heavily used in real apps. At the time somethjing like 20% of the CPU was >> wasted in method dispatch overheads (the -characterAtIndex: method is one of >> the cluster primitives and a major culprit) but there were also performance >> issues due to buffer allocation and copying of internal representations. >> The changes made a substantial improvement in general performance as well as >> causing multipler orders of magnitude improvement in a few pathological >> cases. > > I agree that we should be improving performance for critical code, but > unfortunately it appears that we have done so at the expense of correctness > in a number of places. Good guess, but you lack the perspective to appreciate quite how old GNUstep is ... originally there was no unicode, only latin1, then we had both in a class 'cluster' without using a set of primitive methods (wholy different implentations), then we had reorganisations combining the simple methods, then separating out again (but keeping common layout) somewhat. So correctness has nothing to do with performance and everything to do with history. On the one hand the last major reorganisation fixed severe performance problems, on the other it hid (or kept hidden) a few remaining issues. > I also note that a lot of the NSString method implementations are not well > optimised. Yes ... because they are almost never used as we historically had unicode string methods and latin1 string methods. I did optimise the more 'importent' (ie ones causing trouble in the test applications I tried) ones though. > In a number of places, -characterAtIndex: is called repeatedly, when > -getCharacters:range: is normally significantly more efficient. You have to be very careful about using -getCharacters:range: to give more efficiency, and also worry about extra complexity to put buffers on stack or heap (or work in subsections of strings copied to a stack buffer etc). I remember quite a few cases where more complex code 'optimised' to work that way turned out to be slower for common cases. > The ICU UText interface provides something very similar to > -getCharacters:range: as its primitive method (a callback that fills a buffer > with UTF-16 characters) and has some carefully optimised routines. Yes, I have been thinking about implementing an ICU subclass of NSString (on platforms where ICU is available) for some time. My assumption/hope is that it might be both more correct (in odd parts of unicode that people writing our stuff have been unaware of) and faster than our UTF16 code. Even if performance tturned out to be poor, it would be good to have a reference implementation for testing for correctness. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: New ABI NSConstantString
> On 6 Apr 2018, at 11:00, David Chisnall wrote: > > It would probably help catch more bugs if we made use of NSString’s > class-cluster nature more in -base. I have just fixed a bug in GSString > where we were checking one object matched a particular class before > dereferencing the _flags ivar of the other. I caught this because the other > was a GSTinyString, which is almost never a valid pointer. Possibly, but performance *is* an issue here. The NSString code was rewritten some years ago (moving away from them use of class cluster features) as a result of extensive profiling of real-world applications which were running too slow, precisely because NSString methods are very heavily used in real apps. At the time somethjing like 20% of the CPU was wasted in method dispatch overheads (the -characterAtIndex: method is one of the cluster primitives and a major culprit) but there were also performance issues due to buffer allocation and copying of internal representations. The changes made a substantial improvement in general performance as well as causing multipler orders of magnitude improvement in a few pathological cases. All that being said, when I was doing the rewrite a lot of it was making educated guesses at what would help and then benchmarking changes, and I know there were various cases where I made changes which had insignificant performance impact and (because they didn't make things worse) never got round to reverting them. There is therefore probably some scope for removing some 'optimisations' to simplify the code ... as long as we check that we only remove things that are really insignificant. Counterintuitively, the initial introduction of GSTinyString noticably slowed down some applications until the key methods were optimised, but it's now a performance benefit. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSUnicodeString and NSString disagree on rangeOfComposedCharacterSequenceAtIndex:
> On 8 Apr 2018, at 09:38, Fred Kiefer wrote:
>
>
>
>> Am 07.04.2018 um 20:51 schrieb David Chisnall :
>>
>> I am testing out a new version of the compiler / runtime that is producing
>> NSConstantString instances with UTF-16 data. I have currently disabled a
>> lot of the NSConstantString optimisations, on the basis of ‘make it work
>> then make it fast’ and I’m still seeing quite a lot of test failures. The
>> most recent ones seem to come from the fact that GSUnicodeString’s
>> implementation of rangeOfComposedCharacterSequenceAtIndex: calls
>> rangeOfSequence_u(), which returns a different range to NSString’s
>> implementation.
>>
>> I have ls (an GSUnicodeString) and indianLong (a UTF-16 NSConstantString)
>> from the NSString/test00.m. If I call -getCharacters:range: on both, then I
>> get the same set of characters for [indianLong length] characters. This is
>> as expected. When searching for indianLong in ls, it is not found.
>> Sticking in a lot of debugging code, I eventually tracked it down to this
>> disagreement and when I comment out GSUnicodeString’s implementation of
>> rangeOfComposedCharacterSequenceAtIndex: so that it uses the superclass
>> implementation then this test passes.
>>
>> Please can someone who understands these bits of exciting unicode logic take
>> a look and see if there’s any reason for the disagreement?
>
> I am surely no expert here, but I had a quick look at the code and the two
> algorithms seem to be very similar. The only difference is the set of code
> points that the characters get compared to. NSString uses [NSCharacterSet
> nonBaseCharacterSet], which looks correct to me. On the other hand GSString
> uses uni_isnonsp(), which I would read as "non spacing“ but is never
> explained. The code here is as follows:
>
> BOOL
> uni_isnonsp(unichar u)
> {
> /*
> * Treating upper surrogates as non-spacing is a convenient solution
> * to a number of issues with UTF-16
> */
> if ((u >= 0xdc00) && (u <= 0xdfff))
>return YES;
>
> // FIXME check is uni_cop good for this
> if (GSPrivateUniCop(u))
>return YES;
> else
>return NO;
> }
>
> As a side effect this should handle the upper surrogates correctly, but not
> the lower and I have no idea what GSPrivateUniCop does, even after looking at
> the code various times. OK, it is a binary search on uni_cop_table, but what
> is in that table?
I don't think we have an expert on this (I didn't write the original unicode
stuff), but I was able to find out what GSPrivateUniCop() is ... it's checking
for combining characters (diacriticvals etc), so it's use makes sense here if
the idea is to detect runs of 16bit values which are part of the same
'user-perceived character' (important where the 16bit components of that
character cross a range boundary).
I suspect neither uni_isnonsp() nor nonBaseCharacterSet is the correct
mechanism though.
One thing that I do know from looking at cop.h is that the uni_isnonsp[() code,
depending on cop.h is using out of date information;
The NSCharacterSet info is periodically regenerated from the latest unicode
standard (I re-did that quite recently), but the headers in
Source/Additions/unicode are not. The cop.h file is definitely missing
information and I'd therefore consider them other headers untrustworthy. It
would be good to ensure that we machine-generate all unicode related
information rather than depending on header fiels which were (presumably) built
by hand at some point.
Also, reading the unicode documentation it's clear that, even of the cop.h data
was complete, it's only a subset of the characters in the nonBaseCharacterSet,
and those other categories should be included ... so we should not be using
GSPrivateUniCop(), and we should be using nonBaseCharacterSet to get all the
follow-on characters in a multipart user-perceived character.
On the other hand, the earlier comment also looks correct:
/*
* Treating upper surrogates as non-spacing is a convenient solution
* to a number of issues with UTF-16
*/
I checked, and nonBaseCharacterSet does not include the surrogate pair
characters.
So I think we actually need to fix *both* cases to
a. check for the second half of a surrogate pair and
b. check for a non-base character
Probably the best thing to do would be to fix uni_isnonsp() to use
nonBaseCharacterSet and have the NSString code call uni_insnonsp().
Incidentally, I agree that we want ChangeLog entries (git seems very
unfriendly/poor at presenting such information) ...
If it's trivial for David to generate them from git commit entries, I'd rather
have the time spent on writing a few comments be devoted to that trivial change
instead.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: New ABI NSConstantString
> On 7 Apr 2018, at 10:21, Ivan Vučica wrote: > > On Sat, Apr 7, 2018, 09:50 David Chisnall wrote: > > > My current plan is to make the format support ASCII, UTF-8, UTF-16, and > UTF-32, but only generate ASCII and UTF-16 in the compiler and then decide > later if we want to support generating UTF-8 and UTF-32. I also won’t > initialise the hash in the compiler initially, until we’ve decided a bit more > what the hash should be. > > Emojis don't fit UTF-16. Even if one dismisses CJK, ancient scripts etc, > constant strings are not absolutely unlikely to contain emojis. > > Not supporting UTF-8 for internal storage may be reasonable, but not > supporting UTF-32 for strings that require it seems like a bug. Everything fits in UTF-16 (or UTF-8 for that matter). However it's true that many/most emojis don't fit in a *single* 16bit value and require two UTF-16 (or multiple 8bit UTF-8 values) to encode them. Since the NSString APIs assume a 16bit character width, that means an emoji will generally be treated as two characters as far as they are concerned, but that's not really a problem and current gnustep-base can/does work for emojis (for instance, sending UTF16 to mobile phones). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: New ABI NSConstantString
> On 1 Apr 2018, at 12:21, David Chisnall wrote:
>
> On 1 Apr 2018, at 11:36, Fred Kiefer wrote:
>>
>> Wouldn’t the most useful structure be the one we already use for GSString?
>
> That’s certainly a good starting point!
>
>>
>> @interface GSString : NSString
>> {
>> @public
>> GSCharPtr _contents;
>> unsigned int _count;
>
> Is this the number of bytes or the number of characters? I imagine that both
> are useful.
That's the character count.
>> struct {
>> unsigned int wide: 1;// 16-bit characters in string?
>> unsigned int owned: 1; // Set if the instance owns the
>> // _contents buffer
>
> Owned is presumably redundant for constant strings.
Yep. In a constant string you could just consider it a bit reserved for
mutable strings.
>> unsigned int unused: 2;
>> unsigned int hash: 28;
>> } _flags;
>> }
>> @end
>>
>> Of course constant strings won’t require the hidden reference count that
>> come with all ObjC objects. But apart from that it seems to be a more useful
>> structure. Storing the length with the string should speed up some common
>> operations and 28 bit of hash should still be enough. There are even two
>> unused bits in the flags that could encode the specific hash function.
>
> I’d like to have more than 2 bits spare for future expansion. The current
> NXConstantString structure is now 30 years old, and I think there have been
> several times in the past when it would have been nice to add other things to
> it if we’d had a good way of maintaining compatibility.
>
> This structure does have the advantage that it doesn’t need padding on any
> 32- or 64-bit architectures.
> Do we have any measurements to tell us that 28 bits is enough for the hash?
I don't think so, but with a good hash that gets us over a hundred million
strings held efficiently in a set/dictionary, which seems plenty for now.
However, if the idea is to future-proof things in the ABI, perhaps 28bits is
not enough.
> At some point, I’d like to move the hash implementation for NSString to
> MurmurHash3, which should give better distribution and is very fast on modern
> hardware.
Yes. GNUstep-base has MurmurHash3 support, and perhaps it's time it was made
the default.
> I’m also a bit nervous about using C bitfields in static data structures,
> because their layout is ABI dependent (and on some platforms can change
> between compiler versions).
I wasn't aware of that ... it would make sense for your new ABI, when
individual bits, to have them specified as particular bits rather than as a
bitfield, avoiding the possibility of problems with different compilers.
I don't think you should feel constrained to follow the current layout ... IMO
the current one is good for years yet but probably not for decades.
However, I do think that it's more sensible to have pointer, count, hash, and
flags similar to the current GNUstep layout than to follow Apple (and to bear
in mind that its convenient for mutable strings to share a layout with constant
ones).
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: How do I build one test?
> On 22 Mar 2018, at 17:00, Richard Frith-Macdonald > wrote: > > > In any case, gnustep-tests is a fairly small shell script ... if really > stuck you could just hack a copy of it to add the 'messages=yes' I looked, and it turned out to be a tiny alteration to run make with 'messages=yes' when gnustep-tests is invoked with the --verbose option, so I did that; it seems to me the correct behavior for verbose mode. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: How do I build one test?
> On 22 Mar 2018, at 15:38, David Chisnall wrote: > > Hello, > > I am fighting with the GNUstep test suite again. I have one test failing to > build, but I can’t get the build command so that I can debug the failure > properly. If I do gnustep-tests --verbose test/name then it tells me that it > is running 'gmake debug=yes name', but when I try that in the source > directory it complains that it can’t find Testing.h. How do I get it to run > gmake messages=yes so that I can reproduce and debug the failure? When the compiler /linker errors recorded in the log file are not enough to easily tell why something failed to build, 'messages=yes' is quite useful. You would normally type 'make messages=yes' for a testcase just as you would with any other program, so the fact that you apparently can't do that indicates that you are running in a non-standard environment. The gnustep-tests script is apparently successfully setting up the environment in which to build the testcase, so it's not clear why working directly from the command line didn't succeed as well. Possibly you forgot to source GNUstep.sh to set up your environment. If you want to pass messages=yes to the make invocation without setting up your GNUstep environment, you could simply pass it to the gnustep-tests script as in the following commend: messages=yes gnustep-tests mytest.m In any case, gnustep-tests is a fairly small shell script ... if really stuck you could just hack a copy of it to add the 'messages=yes' ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Out-of-tree builds?
> On 20 Mar 2018, at 13:04, David Chisnall wrote: > > Hello the list, > > I need to build GNUstep in a couple of different configurations, for testing. > For most projects, I would do this by using out-of-tree builds, but this > doesn’t appear to work for GNUstep. Is there a mechanism for doing this that > I can’t find, or is it just a limitation of the build system? I'm fairly sure it's not supported; I remember seeing an ancient patch to add this on savannah, but I hadn't noticed it when new. It might be easy to apply, but I suspect it's too old to be helpful. Even if I had seen it I'm not sure I'd have jumped in to apply it myself, since I've never been on a system with so little disk space that I needed/wanted to build that way. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSAutoreleasePool drain/dealloc
> On 6 Mar 2018, at 17:08, Ivan Vučica wrote: > > Hi, > > I was explaining refcounting and NSAutoreleasePool to someone, and I thought > referencing GNUstep might be useful to explain the correct mental model of > the behavior. > > But I'm confused about -drain in the non-ARC implementation: > > https://github.com/gnustep/libs-base/blob/b8185fa6c13172436c070ab3bf60b3f12bce433b/Source/NSAutoreleasePool.m#L546 > > Won't equating drain and dealloc mean that pools will misbehave, and that > after [pool drain], the incorrect pool will get populated (and later drained)? > > Am I correctly interpreting that this happens? If so, is it correct that this > happens? > > NSAutoreleasePool * outerPool = [NSAutoreleasePool new]; > [[NSObject new] autorelease]; // object 0 added to outerPool > > NSAutoreleasePool * innerPool = [NSAutoreleasePool new]; > [[NSObject new] autorelease]; // object 1 added to innerPool > [innerPool drain]; // object 1 released; outerPool is the closest pool > [[NSObject new] autorelease]; // object 2 added to outerPool > [innerPool release]; // object 2 released, object 0 released; new pool > created as the closest pool > > [outerPool release]; // no objects released; new pool created as the closest > pool > > Unless I am missing something, object 0 would be released early here? According to Apple, the -drain method is a synonym for -release (or -dealloc since you don't retain autorelease pools). So yes, if youi drain a pool the next time an object is autoreleased it goes into the parent pool of the one you drained. Your code above should crash at the point where you call [innerPool release] since you are sending the -release message to a deallocated object. I think the -drain method name is unintuitive. To me it sounds like it ought to do the same as the gnustep-specific -emptyPool method (a more efficient equivalent to draining/releasing the pool and immediately creating a new one). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Wayland backend status update & help appeal
> On 20 Feb 2018, at 22:02, Ivan Vučica wrote: > > Hi, > > A while ago Sergio L. Pascual contributed a 'dirty' wayland backend > patch, intended to be used together with cairo. > > At FOSDEM we worked on merging it, but it didn't worked out. I have > not yet merged it as it is not ready for use. > > You can see current work-in-progress: > https://github.com/ivucica/libs-gui/tree/ivucica-wayland > https://github.com/ivucica/libs-back/tree/ivucica-wayland > > Also, I am stumped. > > - xdg_shell's get_xdg_surface_special is not referenced elsewhere on > the interwebs. I have temporarily swapped it for get_xdg_surface; > thus, no longer is a more detailed window style being passed. I don't > see an obvious way to do the same with v5 xdg-shell api. > - Having done so, the window does not appear at all. I cannot find > evidence that a 'map' call is required. The window is there under > weston; events are being printed if I pass --GNU-Debug=dflt. It's > simply not drawing stuff on screen at all. > > What am I missing? I'm just reading around what I can find about xdg-shell and looking at the get_xdg_surface_special() calls I note the extra argument is 2/1/0 for main/background/other window styles. I wonder if the 2 and 1 might correspond to the xdg-shell states for maximised and fullscreen (which seem to have those numerci values). If so, perhaps calling xdg_surface_set_maximized () and xdg_surface_set_fullscreen() might have the same effect? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Dev meeting 2018?
> On 6 Feb 2018, at 15:23, Ivan Vučica wrote: > > Hi, > > Meeting with Richard and Fred at FOSDEM was good. Yews, it was great to saee you again, along with the other GNUstep related people we were able to meet. FOSDEM is a good place to meet old friends again. > If you have an opinion, please answer this: Do we want another meeting later > in 2018? Location to be determined. > > If you believe that 'yes' is the answer, before answering 'yes', consider > also saying why; what concrete goals do you want to achieve? Some other > answers include 'no' and 'not in 2018, but yes in 20YY.' > > What I would not be a fan of is planning a meeting 'just' to meet or discuss > 'what I want'. I think many things we have discussed in 2015 still apply. And > organizing meetings like this is complicated and possibly expensive for the > organizer, and *definitely* expensive for the attendees. > > I'd myself find it more useful to have a multiday hackathon with specific > workgroups agreeing to specific goals and perhaps an overarching theme. Maybe > only a few talks and topics to actually discuss. All that makes sense to me. In particular I would like to meet new people, who have not been core developers in the past, to try and collaborate on their pet projects (concrete goals). We can get a lot done in a hackathon if there are concrete targets. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Coverity Scan for GNUstep?
> On 9 Feb 2018, at 07:43, Fred Kiefer wrote: > > Just to keep you updated. Due to Richard’s work over the last few weeks we > are now down to zero open issues on Coverity. (They display that there still > is one, but in the details they don’t display any open ones. Maybe the web > interface cannot cope with zero?) This is an excellent result and shows how > well written base was even before the analysis started. > It would be great if someone besides me and Richard would be willing to > recheck all the issues we marked as false positives or intentional. Just to > make sure we didn’t hide anything important there. Thanks for being the person to push all this forward Fred. Without your willingness to set up the Coverity project and generate the data to feed it, this wouldn't have happened. I think I have fixed the final issue (had to play with the filter settings in the CoverityGUI to see it), which was a potential buffer overrun if someone tampers with the timezone data files on the system (a very minor risk, since timezone data is normally installed read-only and owned by root, but still a real one). > I will be away from my computer for the next two weeks so either no scans > during that period or somebody else will have to do it. We could now start to > discuss whether setting up scans for other parts of GNUstep would be > worthwhile and maybe even test how to integrate Coverity into Travis on > GitHub. I hope to find time to set up my system to do coverity builds/scans this weekend. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Coverity Scan for GNUstep?
> On 29 Jan 2018, at 08:28, Fred Kiefer wrote: > > re is a problem with these numbers. Coverity did only analyse about one third > of the Objective-C files in GNUstep base and most likely only the smaller > files. Coverity at the moment has issues with Objective-C protocols and only > works with files where there are no references to any. That means we don’t > know how many of the 1 million lines where actually checked for defects. The > number 0.01 is basically meaningless :-) :-( Where do I look to find out about this? I don't think gnustep-base actually *uses* protocols much, so perhaps we can figure out ways to work around this limitation? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Coverity Scan for GNUstep?
> On 22 Jan 2018, at 22:23, Fred Kiefer wrote: > > > In the meantime my connection with GNUstep has been confirmed and I was able > to look at the found issues. Many of them are false positives mostly caused > by Coverity expecting normal program continuation after NSException raise. > Even so it did detect a few potential issues in base. I flagged some of the > false positives so the more interesting bits are left over for somebody to > look at. Especially the „time of check, time of use“ issues should be looked > at. I think the few outstanding defects are all addressed now, Looking at a link from the coverty report I found this: Open Source Defect Density GNUstep base: 999,026 line of code and 0.01 defect density Open Source Defect Density By Project Size Line of Code (LOC) Defect Density Less than 100,000 0.35 100,000 to 499,999 0.5 500,000 to 1 million0.7 More than 1 million 0.65 Note: Defect density is measured by the number of defects per 1,000 lines of code, identified by the Coverity platform. The numbers shown above are from our 2013 Coverity Scan Report, which analyzed 250 million lines of open source code. While it would have been better if it hadn't found any defects, it's still nice to see that our defect density is about a 70th of their normal finding (presumably those ratings are mean values for projects in the four size categories). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Coverity Scan for GNUstep?
> On 25 Jan 2018, at 07:41, Fred Kiefer wrote: > > > >> Am 25.01.2018 um 00:59 schrieb Ivan Vučica : >> >> On Wed, Jan 24, 2018 at 11:56 PM, Ivan Vučica wrote: >>> On Mon, Jan 22, 2018 at 10:23 PM, Fred Kiefer wrote: In the meantime my connection with GNUstep has been confirmed and I was able to look at the found issues. Many of them are false positives mostly caused by Coverity expecting normal program continuation after NSException raise. >>> >>> Some of this type of issues can be fixed with __attribute__ ((noreturn)). >>> >>> Manual says "The attribute noreturn is not implemented in GCC versions >>> earlier than 2.5." which is older than what we support, so it should >>> be fine. >>> >>> Even though it's just silencing this warning, I'm nonetheless creating >>> a patch for gdomap. >> >> Please disregard the mention of creating a patch for gdomap.c. >> >> I've taken a closer look only a few seconds after posting this and it >> looks like gdomap_log exits only sometimes, so the 'breaks are >> missing' warning is probably correct. >> >> I won't be creating the patch adding noreturn. > > I was hoping you would provide such a patch for the NSException methods that > won’t return. That was the type of false positives that showed up the most in > the Coverity list. I'm looking into that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSConnection/NSInvocation compiler optimization
> On 18 Jan 2018, at 23:29, Yavor Doganov wrote: > > In Source/Makefile.postamble, optimization is explicitly turned off > for NSConnection.m and NSInvocation.m. This was made in August 1999 > (commit 90f2d8a). I can imagine the reasoning but is it still > relevant? > > I tried a build with default (-O2) optimization and I don't observe > any regression, at least on GNU/Linux (x86 + x86_64) with GCC. The > testsuite also passes successfully. Good point. Any problem with current compilers is likely to indicate a gnustep bug we should fix, and I can't imagine we are using ancient compilers anywhere. I have tested re-enabling the optimisation with gcc and clang and spotted no problems, so I've re-enabled optimisation for those files (and removed the obsolete settring for mframe.m). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Coverity Scan for GNUstep?
> On 14 Jan 2018, at 18:54, Fred Kiefer wrote: > > I remember we talked about this before, maybe at the Dublin meeting. There is > the option to set up GNUstep on scan.coverity.com to have the code > automatically checked for known vulnerabilities. At the time we did discuss > this there wasn’t support for Objective-C but this seems to have been added: > > https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/CWE-CC-Objective-C.pdf > > What are your opinions on this? In the beginning it will require some extra > effort to fix the found weaknesses and somehow to flag the false positives. > And who should be in charge of getting the reports? The idea here is that > only the person registered for the project will get the report to prevent > 0-day issues becoming public too soon. I don't know anything about coverty (I'd forgotten that we talked about it), but I'm in favour of any automated checks/testing in principle. It must be worth trying ... as long as we don't get so many false positives that it's just too much work. Presumably the only way to know is to try. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Upcoming 0.26.0, please review release notes
> On 12 Dec 2017, at 16:34, Fred Kiefer wrote: > > > >> Am 11.12.2017 um 17:45 schrieb David Chisnall : >> >> On 11 Dec 2017, at 10:46, Ivan Vučica wrote: >>> >>> On Mon, Dec 11, 2017 at 10:43 AM, David Chisnall wrote: On 11 Dec 2017, at 10:33, Ivan Vučica wrote: > I think it's also fine to push a new minor release *after* this > release with just your changes. Does that make sense too? It’s likely to change some of the -base / libobjc2 interfaces and possibly be a requirement of the new libobjc2, so I’d prefer a major version bump then, but it probably doesn’t have to be one. I’ve committed the fixes for NSMapTable where we were using the wrong hash and equality functions if you use the normal constructors - those are probably the most important things to get out. >>> >>> Makes sense. >>> >>> I think that we can still do a major version bump in a few days, even >>> if it includes "just" your new fixes. >>> >>> I've just spent some time cutting -gui and -back so it would be a >>> minor effort for me if I were to do it. >> >> >> I had some time to finish up most of the changes and have sent a pull >> request for review. I think I probably want to add a couple of weak >> functions for refcount manipulation that will allow either the runtime or >> -base to provide them, depending on the versions of each. >> > > I had a short look at your pull request and in my opinion it is too complex > to be merged directly before a release with out proper testing on a lot of > different machines. We should make a release without it and merge directly > after that and with a few months of general testing a new release should be > done. That's my impression also, but I've only had a chance to take a very, very quick skim through part of the changes. I'll try to look through more thoroughly tomorrow. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Upcoming 0.26.0, please review release notes
> On 11 Dec 2017, at 07:45, Fred Kiefer wrote: > > I was hoping for Richard to step up here. If he doesn’t response today, we > should try to go ahead ourselves. I could help later today with the news.texi > file. My impression is that we should use a version number of 1.26.0 as quite > a few changes have piled up. > The release process itself would again be on your side, as you have the > required key for it. It would be great to have this one out tonight to reduce > the confusion that comes from the gui release. > Not sure whether we need another gui release to document the increased base > version. I think we could do without it. I was away, and just got home last night. I had intended to make a release befoire christmas. As far as I know there should be nothng that breaks binary compatibility (so I'd have made it 1.25.1), but if people want a new library version number I don't see any problem with that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Base: networking APIs
> On 15 Aug 2017, at 14:33, Daniel Ferreira (theiostream) > wrote: > > Hi everyone (and Richard in particular), > > Lately a lot of effort in getting WebKit to work has been avoiding its > usage of the Foundation newer networking APIs (NSURLSession, > NSURLDownload...). Does anyone plan on implementing them relatively > soon? > > I believe I can get WK to work using the libsoup networking backend > the GTK port uses, but on the medium-term it'd be nice to be able to > use this part of the Mac port as well. Otherwise, it's a really handy > API I really liked using in my newer applications. > > If nobody has a plan/interest in working on that, I might take it up > some time from now. I don't know of any plans to implement the recent networking APIs (perhaps because most code works fine with the existing APIs), but it would be really good to have them working for use by newer apps/frameworks. My knowledge of the new APIs is minimal, but as far as I can tell the basic HTTP/HTTPS network code doesn't much change/improve on what's already in base, but the way the new API classes are structured to interact with each other is a big improvement in flexibility for things like caching data, pooling low level network connections to allow connection re-use, and managing authentication and proxies. So while it's probably not possible to implement the new APIs on top of the old ones, it may well be possible to do much of the implementation copying/reusing existing code. The exception would be HTTP/2 ... the old APIs don't do it at all, so that part of the networking code would need to be implemented either from scratch or on top of a reliable, portable, LGPL compatible free software library to do it (if such a thing exists). I think it would be great if you could implement the new APIs. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_SYSTEM_ROOT is gone, what replaces it?
> On 13 Aug 2017, at 13:43, David Chisnall wrote: > > Hello, > > I am trying to update the GNUstep ports on FreeBSD, but Preferences.app now > doesn’t build because the new version of GNUstep-Make now errors for any > Makefile that references GNUSTEP_SYSTEM_ROOT. The documentation doesn’t tell > me anything useful for migration. Possibly you are not seeing anything about migration because GNUSTEP_SYSTEM_ROOT was deprecated (and gnustep-make printed warnings about it) over a decade ago ... so any stuff about migration would be in the distant past. Basically, when FHS support was added we started, having variables for where different types of resource are installed, rather than installing everything under one 'root', so the notion of a GNUSTEP_SYSTEM_ROOT no longer made any sense. To avoid having to read the documentation you can get by with a quick summary of the names of locations for the different domains (look in GNUstep.conf or use 'gnustep-config --help'). I would guess you probably want GNUSTEP_SYSTEM_LIBRARY (and to install bundles in the Bundles subdirectory of that location). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
I'm away for two weeks
I won't have access to a computer, but I will occasionally check email on my phone. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CoreBase: necessary additions for WebKit
> On 2 Jul 2017, at 10:07, David Chisnall wrote: > > On 1 Jul 2017, at 22:51, Daniel Ferreira (theiostream) > wrote: >> >> This would require rewriting a good part of CFRunLoop, but it seems >> more approachable than expecting Base's NSRunLoop to depend on >> libdispatch. > > Note that an increasing amount of Cocoa code depends on at least the main > runloop having a libdispatch queue, and libdispatch runs on all > GNUstep-supported platforms (including Windows - there are multiple ports, > and Microsoft maintains one, though I also talked to that team a few months > ago about reimplementing the libdispatch APIs on top of the Windows > concurrency primitives). While, for many years, GNUstep has had a policy of minimising external dependencies (because a common complaint was that it was difficult to install, and we wanted to minimise instrallation problems), I really don't like sending time working on or maintaining code when someons else is doing it and we can leverage their work. In that spirit, I'm very much in favour of using libdispatch where it's available and as efficient as (or better than) existing code. Of course using it without breaking existing code may be a challenge... In particular I worry about breakage on windows since libdispatch, like the I/O and event APIs in Foundation, was not designed with portability to windows in mind. It's good to hear that windows ports exist. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: corebase: use __builtin___CFStringMakeConstantString when available?
> On 28 Jun 2017, at 09:37, David Chisnall wrote: > > On 28 Jun 2017, at 01:19, Daniel Ferreira (theiostream) > wrote: >> >> That said, I need a way to place a valid Objective-C class definition >> in that symbol on compile-time (probably it'd be an empty subclass of >> NSCFString), but I'm totally unaware of any way to do that. Or maybe >> make that point to an ordinary _OBJC_CLASS_* symbol somehow. Any >> hints? > > I’m a bit hesitant to suggest this, as it introduces some Objective-C ABI > dependency that I’d rather avoid, but you could do this by creating an alias > in the base file that declares the NSConstantString class. > > Slightly longer term, I’d like to move to using a better structure for > constant Objective-C strings, with space for unicode flags and a hash (which > we’d compute at compile time, with a flag indicating which hashing algorithm > we used, so that we could recompute it if GNUstep wants to use a different > hash for strings, but have a fast path if the compiler and -base > implementations agree). Yes, storing a hash at compile time would make a substatial difference to performance when using literal strings as dictionary keys. I'd really like that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: corebase: use __builtin___CFStringMakeConstantString when available?
> On 28 Jun 2017, at 01:19, Daniel Ferreira (theiostream) > wrote: > > > If we choose not to implement this right now due to the complexity > being too large, I suppose I *can* export these constant strings as > Objective-C string literals. But it'd still be weird for a CF-only > library to rely on ObjC to export its CFStringRefs. :( I actually think that's the best option ... it's very quick/simple, and afaik we have no intention/policy of ever supporting Carbon beyond the minimum required to support the ObjC (and possibly Swift in future) frameworks. I imagine we'd happily change that policy if some really active developer *wanted* to implement loads of plain C code (and it's be their problem), but until/unless that happens it seems safe to assume the presence of ObjC. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Newbie back again...
> On 19 Jun 2017, at 10:10, David Chisnall wrote:
>
> On 24 Apr 2017, at 09:57, Richard Frith-Macdonald
> wrote:
>>
>> Setting variables in make is fairly straightforward, but I think only you
>> (and clang geeks) understand how these flags are actually supposed to work.
>>
>> How are you supposed to turn use of the non-fragile ABI on/off what flags
>> do you need to supply at compile time and what (if any) are supplied at link
>> time for
>> a. building with the non-fragile ABI and
>> b. building without non-fragile ABI
>
> Non-fragile ABI is the default with all modern runtimes. The correct way of
> specifying a runtime is with -fobjc-runtime={name}-{version}. So, for a
> recent GNUstep runtime, you’d pass -fobjc-runtime=gnustep-1.7. The compiler
> will then enable all of the features that it knows that this version of the
> runtime supports. For example, it will use objc_msgSend on architectures
> where the runtime supports this, but use the two-stage lookup on other
> platforms.
Thanks ... that sounds clear but forgive me for wasting time dopuble-checking;
We should remove support for specifying the fragile/nonfragile option from
gnustep make since it doesn't work on any new systems?
I'm happy with that (while I'd dearly like to be able to inspect variables
under debug without having to make explicit function calls to the runtime, I'm
sure people can live with that limitation).
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Newbie back again...
> On 24 Apr 2017, at 08:42, David Chisnall wrote: > > -fobjc-nonfragile-abi has been a deprecated flag for 2-3 years. Please can > someone who understands GNUstep Make fix the build system to use > -fobjc-runtime= instead? The build system already uses -fobjc-runtime= ... but also still has options that look like they were/are intended to turn nonfragile ABI on/off. Setting variables in make is fairly straightforward, but I think only you (and clang geeks) understand how these flags are actually supposed to work. How are you supposed to turn use of the non-fragile ABI on/off what flags do you need to supply at compile time and what (if any) are supplied at link time for a. building with the non-fragile ABI and b. building without non-fragile ABI To what extent are other features dependent on it? eg. can you have ARC without nonfragile ABI? Incidentally, we really need a patch to make nonfragile abi work with gdb (ie so that looking at object instance variable works with the nonfragile ABI), so that we can make nonfagile ABI the default. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make: /etc/GNUstep.conf in case of --prefix and --sysconfdir
> On 2 Apr 2017, at 17:19, Ivan Vučica wrote: > > Hey, > > I'm trying to install GNUstep into /GNUstep with folders such as > /GNUstep/System, /GNUstep/Local, etc. However, GNUstep.conf should live in > /etc/GNUstep/GNUstep.conf. > > ./configure --prefix=/GNUstep --with-layout=gnustep --sysconfdir=/etc > > Looks like sysconfdir is not used here. And in fact, GNUstep.conf ends up in > /GNUstep/etc/GNUstep/GNUstep.conf, where it presumably won't be found by > things trying to find where GNUstep is installed. I spent quite some time trying to figure out how it might be possible to preserve most of existing behavior while also making the code honor --sysconfdir= There's no way I could find in autoconf to tell whether the use has supplied the --sysconfdir= option, so checking for that would probabaly require us to add code to parse the command line arguments passed to the configure script and see if they contain --sysconfdir=, and that seems like a lot of work for little effect. However, as far as I can see $sysconfdir should always be $prefix/etc when neither -sysconfdir= is used. So perhaps we might use: if --with-config-file= is supplied ... use it else if $sysconfdir is not $prefix/etc ... use $sysconfdir/GNUstep/GNUstep.conf else if on darwin ... use /Library/GNUstep/GNUstep.conf else use current rules based on $GNUSTEP_PREFIX ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNA Shutting Down?
> On 3 Feb 2017, at 21:45, Fred Kiefer wrote: > > Sorry, I must have missed something. Why GitHub as the main repository? We > had a very similar discussion before, but without the time pressure and > there, as far as I remember, we all agreed to move to git on Savannah, plus a > mirror on GitHub and some SVN access to that. Allow me to change my mind ... I've had a few years using git now, enough to have a properly informed opinion: It's trendy and is good for huge projects, but for a small project like GNUstep is overly complex and hard to understand/use relatavie to subversion so, to gain any benefit. we need to have it as easy to use as possible. That means hosting it on a popular site where the best GUI tools (eg SourceTree, though I'm sure people like lots of other tools) work seamlessly. Unfortunately Savannah just isn't integrated with the best new tools/systems. So, while I'd really prefer to use Savannah as a free software hosting site, I now believe it would be a poor option if we hope to encourage new users/contributors; moving to git on Savannah would put an obstacle in the way of contributors. I think we'd want a github master, rgularly copied to savannah so we have a presence there, or possibly a dual-master system (though it's not clear to me that git really supports dual master). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cutting a gnustep-gui release
> On 15 Dec 2016, at 11:23, Ivan Vučica wrote: > > On Wed, Dec 14, 2016, 22:47 Riccardo Mottola > wrote: > Hi, > > Ivan Vučica wrote: > > Let me know if you would like me to delay or to sync with another release. > > current gui has some important fixes done by fred: they could be > backported to stable in case? > > Ok, thanks for the response to both yourself and Fred. > > I am not sure what we should backport, we should probably just cut a release > and not worry much about a separate "stable" branch. Unless a distribution > packager voices interest in us doing so? > > @Richard: Are you interested in cutting a -base release soon? I have this problem that, when I did the last release I announced that it would be the final one of the 1.24.x sequence, and that the next one would be 1.25.0 breaking binary compatibility ... that was because I wanted to get support for the debian multi-arch layout into the code (which means gnustep-make installing some things in slightly different places, and gnustep-base looking up resources differently at runtime). Also I wanted to use the 'ng' runtime library designation work nicely for turning on all the latest objc-2+ features, and I wanted to allow other binary compatibility breakages that people had waiting. Due to ill health this year, I have had very little time to do any of that stuff, and while I made the basic changes for resource lookup, there has been no testing to speak of On the other hand, this should really only effect non-flattened versions of the code (and most people use the flattened filesystem layout) and should not change the actual abi (in terms of symbols exposed in the library). So maybe we could do another release in the 1.24.x series if we think the code is still binary compatible for practical purposes (ie the way distributions like debian currently build it). I am not certain that it is though. There are quite a lot of bugfixes in trunk, so perhaps it would be worth doing another 1.28.x release ... does anyone know how to use the debian tools for checking abi compatibility to see if trunk really is abi compatible with the latest release? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ProjectCenter crash with unichar in parser
> On 26 Nov 2016, at 21:48, Riccardo Mottola wrote: > > Hi, > > > ProjectCenter crashed on me today with Program terminated with signal 11, > Segmentation fault. > > > I opened the core file and seet his trace: > > #0 codeType (ch=0x11491e685000) at PCParser.m:103 > 103 if ( ((*ch > 0x40) && (*ch < 0x5B)) || > > a stacktrace: > > (gdb) bt > #0 codeType (ch=0x11491e685000) at PCParser.m:103 > #1 0x11491839521d in -[PCParser parse] (self=0x114886e4a490, > _cmd=Unhandled dwarf expression opcode 0xf3 > ) >at PCParser.m:219 > #2 0x114918394da0 in -[PCParser classNames] (self=0x114886e4a490, > _cmd=Unhandled dwarf expression opcode 0xf3 > ) >at PCParser.m:81 > #3 0x1148827e9ce6 in -[PCEditor browserItemsForItem:] ( >self=0x1148832aee10, _cmd=Unhandled dwarf expression opcode 0xf3 > ) at PCEditor.m:556 > #4 0x114831eb3f1d in -[PCProjectBrowser(ProjectBrowserDelegate) > browser:createRowsForColumn:inMatrix:] (self=0x11482c42e450, _cmd=Unhandled > dwarf expression opcode 0xf3 > ) >at PCProjectBrowser.m:544 > #5 0x11487858ff93 in -[NSBrowser(Private) _performLoadOfColumn:] ( >self=0x11488d037c10, _cmd=Unhandled dwarf expression opcode 0xf3 > ) at NSBrowser.m:3339 > #6 0x11487858d0e1 in -[NSBrowser addColumn] (self=0x11488d037c10, > _cmd=Unhandled dwarf expression opcode 0xf3 > ) >at NSBrowser.m:954 > > I ask myself, how can it crash in this place? The unichar is valid and there, > I can print it out: > > (gdb) p ch > $1 = (unichar *) 0x11491e685000 > Current language: auto; currently If you look at line 103, it's checking *ch ... so it thinks ch is a pointer to a unichar. But, the code printed for line 103 is incomplete (the || operator at the end implies that there's more in the expession), so the problem could be something els you didn't include in the email. Assuming the problem is the dereference of ch, it will crash if ch points to non-existent/inaccessible memory or (some architectures) if the memory location is not on the correct boundary for the data type. In this case you printed the pointer and it clearly isn't null or on an odd boundary, so I guess it's a non-existent memory location. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Hidden interfaces
> On 23 Sep 2016, at 20:08, Ivan Vučica wrote: > > If the equivalent functionality is exposed on the other implementation, I > don't see why not. > > If not, care should be taken for maintainability reasons. > > I also think it's perfectly fine to not expose functionality. Like on the > other implementation, if you decide to use a private interface and it breaks, > you get to keep the pieces. Agreed ... gnustep-base has a policy of trying to expose the same APIs as Cocoa and move towards ever greater compatibility. So if Cocoa changes to expose new APIs, so should gnustep-base. However, it's not so much exposing equivalent functionality as attempting to expose identical functionality (we aim for compatibility). For extensions to the Cocoa APIs, we have the base-additions library, which is built in to gnustep-base but should build as a separate library on OSX, so that the extensions can be used in conjunction with Apple's Foundation framework. Where gnustep has historically had extension APIs in the standard Cocoa headers, the aim is to gradually remove them (either deprecating/deleting as they become really outdated, or moving them to the additions library if they are still useful). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
I'll be out of touch for a week
>From tomorrow and over all next week I'll be without internet access; so >pplease don't expect email responses until some time the week after that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Away for a week
Just to let you know I'm away from home on an Aikido course for the next week. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: common.make -- debug=yes
> On 19 Aug 2016, at 00:10, Giah de Barag wrote: > > You are of course correct that it does not preclude it. On certain systems I > too have happily debugged optimized code. On my present system (gdb 7.6.1, > gcc 4.9.3, msys/mingw32, Windows Server 2008 R2) I must say debugging -O2 > optimized code is definitely inconvenient, often tiresome, sometimes > impossible. > > GNUstep Makefile Package documentation [1] says if debug=yes, optimization is > off. (It further says that the user must override the optimization flag if > both debugging information and optimization are desired.) > > Note that OPTFLAG := $(filter-out -O%, $(OPTFLAG)) clearly intends to do so > but fails because the optimization flag already entered ADDITIONAL_FLAGS > (hence the suggested patch). > > Ref: > [1] “make debug=yes” at > http://www.gnustep.org/resources/documentation/make_1.html Yep. I applied your patch. Thanks. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: path handling
> On 11 Aug 2016, at 06:43, Giah de Barag wrote:
>
> Path handling is a behavior from cygwin that is in msys and in GNUstep
> (GSPathHandling in NSBundle and NSString) that interprets unix paths and maps
> them to the actual windows path.
>
> I was under the impression it could be disabled.
In an earlier post you mentioned disabling tpath handling in gnustep-make.
So I think we should draw a clear distinction between built-time (how
gnustep-make builds libraries, tools and apps) and runtime (how those
librariews, tools and apps behave when they are running).
At build-time, gnustep-make operates in an msys environment ... so gnustep-make
uses msys paths.
At runtime, GNUstep doesn't support cygwin, and doesn't depend on or change
anything in cygwin, nor does it depend oon or change anything in msys ... it
uses native windows calls to do everything. The APIs that tools and
applications use (Cocoa/OpenStep) provide for portable handling of paths, so
that the same code can work on any operating system.
In neither case does it make sense to talk about path handling being 'disabled'
(obviously a program without path handling can't interasct with the filesystem).
I guess the closest concept would be the GSPathHandling() function; which lets
you tweak the way the path manipulation methods in the NSString class operate
at runtime. It allows for three modes of operation;
The standard mode ('gnustep') is for when you are writing portable code (which
is what we encourage), and are properly using the API to work entirely with
relative paths appended to known locations provided by standard functions in
the API.
The 'unix' mode is for non-portable code on unix, where you are assuming a unix
filesystem with '/' at its root, so any path beginning with '/' is assumed to
be absolute
The 'windows' mode is for non-portable code where you are assuming a windows
filesystem and a path starting with '/' is assumed to be relative unless it's a
windows UNC path.
This is covered at the start of the NSString class documentation.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Debian GNUstep maintainers] request for help: oolite
> On 6 Aug 2016, at 18:54, Ivan Vučica wrote: > > Yes, I think that's what was stated in the sentence "a patch for 1.24.9 in > Debian to add/use exitLock might be an option" means 0:-) > Yes, looks tlike the update was at svn revision 40033, so a patch might be made using svn diff -r40032:40033 Source/Additions/NSObject+GNUstepBase.m ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: 32bit GS on 64bit Win rebuild base from src
> On 6 Aug 2016, at 10:57, Giah de Barag wrote: > > Setup: >w2k8 r2 x64 >GNUstep installed using 32-bit installer > > > Goal: >Rebuild just base from source > > > Procedure: >check out core/base from svn >cd core/base; ./configure > > > Result: >conftest.exe crashes in FFI library test. > > > Question: >Must the host be changed to 32-bit, or can this work somehow? The installer is a 32bit distribution ... uyou can't use it to build 64bit code. If you want a 64bit build, you need to dowload a 64bit development environment (msys2 and a load of 64bit libraries) and then configur/build/install gnustep from source. There are step by step instructions for getting the depedencies into an msys2 64bit environment in svn at tools/scripts/trunk/install-dependencies-msys2-64bit You can see that script via http at http://svn.gna.org/viewcvs/gnustep/tools/scripts/trunk/install-dependencies-msys2-64bit ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Debian GNUstep maintainers] request for help: oolite
> On 1 Aug 2016, at 12:38, Ivan Vučica wrote: > > This was my guess too, but it seemed like the use of exitLock is quite > limited. I was not aware it was a recent change :-) > > Aside from someone trying to ask Oolite to fix their init, should we also cut > a release of base then? I don't think base is anywhere near ready for the 1.25.0 release yet (but it's far too much changed and binary incompatible for another 1.24.?). I would imagine a 1 line fix to explicitly initialise (for instance) NSDate might solve things in Oolite. Alternatively, a patch for 1.24.9 in Debian to add/use exitLock might be an option. Assuming of course that the problem analysis is correct. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Debian GNUstep maintainers] request for help: oolite
> On 1 Aug 2016, at 11:59, Ivan Vučica wrote: > > For context this is the first message in the thread: > http://lists.alioth.debian.org/pipermail/pkg-gnustep-maintainers/2016-July/003934.html > > On Mon, 1 Aug 2016, 11:32 Ivan Vučica, wrote: > Gdb backtrace is sort-of useful, but reading the code I can't tell where the > bug in leakAt: is. It seems to clean up its use of exitLock after itself. > > I will assume you wanted to send this to the list, and I will also cross post > this onto gnustep-dev. > > The curious part is "it works locally, but not on buildd" which you mentioned > earlier in the thread. Is the compiler different remotely? Does it reproduce > with the same compiler? > > On Mon, 1 Aug 2016, 10:44 Nicolas Boulenguez, wrote: > On Sun, Jul 31, 2016 at 11:49:03PM +, Ivan Vučica wrote: > > gdb: I meant, attach to it once it freezes and collect the backtrace. > I did not know that gdb could attach a running process. Thanks. > > #0 0x7fdd098ebe9c in __lll_lock_wait () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x7fdd098e5b92 in pthread_mutex_lock () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #2 0x7fdd0bd115d5 in -[NSRecursiveLock lock] (self=0x55ab20a1a8d0, > _cmd=0x7fdd0c285d90 <_OBJC_SELECTOR_TABLE+144>) at NSLock.m:308 > #3 0x7fdd0be20da9 in +[NSObject(GSCleanup) leakAt:] (self= out>, _cmd=, anAddress=) at > NSObject+GNUstepBase.m:200 > #4 0x7fdd0bd9731b in +[NSTimeZone initialize] (self=, > _cmd=) at NSTimeZone.m:1357 > #5 0x7fdd0a0230d6 in __objc_install_dtable_for_class (cls=0x7fdd0c22cd40 > <_OBJC_MetaClass_NSTimeZone>) at > /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:1030 I would guess this is a multi-threaded application and there's a deadlock between the two threads initialising various classes in an unusual order. The general workaround for that kind of thing is to have a single thread start things up first (eg have the main thread call [NSDate class] before the app goes multithreaded) to ensure that the deadlock can't occur. Maybe the problem doesn't occur on svn trunk because I recently changed the atExit handling code (used by -leakAt:) to use its own lock, rather than sharing the gnustep general lock, precisely so that registering things for cleanup at process exit will not block things initialising in another thread. In an ideal world multiple threads would not be able to deadlock during class initialisation, but the different runtimes have slightly different behaviors in the way they lock things during +initialize and I don't think it's always possible to write code that's safe with all runtimes ... so I think apps need to take some care to initialise things in a single thread (and +initialize and +load implementation shouldn't launch new threads themselves unless they are *sure* they aren't creating potential for deadlock). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [NSData initWithBytesNoCopy:length:deallocator:]
> On 27 Jul 2016, at 01:04, Niels Grewe wrote: > > Hi guys, > > I just implemented the -initWithBytesNoCopy:length:deallocator: initialiser > for NSData and NSMutableData (this appeared in OS X 10.9). This takes a block > as the last argument which allows you to customise how memory will be > deallocated. This is very useful when you have a memory buffer whose lifetime > is tied to some other resource that you want to discard once the NSData is no > longer needed. > > Unfortunately this required adding an ivar to hold the block, so there is a > slight complication: To maintain strict binary compatibility, NSDataMalloc > and NSMutableDataMalloc instances will deallocate themselves if called with > this initialiser and return a new object of the correct subclass instead. > This could be avoided if we added the block ivar to NSDataMalloc and > NSMutableDataMalloc directly, but that’d break any consumers subclassing > these classes (assuming the fragile ABI). > > Now I am of the opinion that since NSData is a class cluster, nobody should > have any business subclassing these anyways, but I wanted to solicit some > input on the issue before making this kind of change: Would it be acceptable > to make this a common ivar? Should we bump the minor version to indicate that > this might be a breaking change or do we regard the internal organisation of > the class cluster as an implementation detail that we can change on a whim? The next release of base is planned to be 1.25.0 (I've already started updating the news/release-notes to that effect in svn) since, as announced in the last release, it will be removing GC support (and making other binrary incompatible changes). There are already too many changes in trunk to realistically make another bugfix release in the 1.29.? series from it. So up until we actually make the 1.25.0 release any binary incompatible changes are fine in trunk. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI updates do not show even from separate thread
> On 14 Jul 2016, at 09:39, Riccardo Mottola wrote: > > Hi, > > Fred Kiefer wrote: >> we get the expected behaviour. You could use this code for now to get >> your application working correctly under GNUstep. But on MacOSX none of >> this hacks should be needed. Riccardo, could you please try to run FTP >> with that runloop line removed on a Mac and report back whether the >> progress bar gets filled smoothly? > > I tested on Mac and my memory decieved me. I tested an old Mac version, but > without the runloop line, the progress bar on mac jumps from the beginning to > the end like on GNUstep. > So the line is needed and that is fine, it confirms we canand should match > that behaviour. > > The only doubt remaining is thus now why we broke Windows :( It took me several hours to track this down because the problem was not actually in the code changes I made, but the change exposed a bug in the low level polling for windows messages. The low level code was not returning YES as it should when an event had been received/handled, so the higher level code depending on that return value was not working properly. This should be fixed in trunk (works for me). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI updates do not show even from separate thread
> On 13 Jul 2016, at 09:41, Niels Grewe wrote: > > >> Am 12.07.2016 um 13:47 schrieb Richard Frith-Macdonald >> : >> >> It also seems that -acceptInputInMode:beforreDate: should fire timers >> (whether there is input available or not) ... but fixing that would be a >> bigger change. > > There are two failing test cases about that in trunk: > > https://travis-ci.org/ngrewe/base/jobs/144390420#L1788 > > Is that a bona-fide failure or should it be marked as hopeful? I've been working on it. Changes comitted. It's not a regression ... but the testcases reflect OSX behavior (and a small note that appeared recently in the Apple docs, saying that a timer does not count as an input source). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI updates do not show even from separate thread
> On 12 Jul 2016, at 10:43, Fred Kiefer wrote: > > I made some progress here although I am still not satisfied with the > result. It turns out that > > [[NSRunLoop currentRunLoop] runUntilDate:[NSDate distantPast]]; > > is a NOP with current GNUstep base. It may have been different some time > ago, but now when the limit is in the past this method returns immediately. > Richard could you please confirm that this is the intended behaviour? > > If we replace that line with > > [[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode > beforeDate:[NSDate distantPast]]; > > we get the expected behaviour. You could use this code for now to get > your application working correctly under GNUstep. But on MacOSX none of > this hacks should be needed. Riccardo, could you please try to run FTP > with that runloop line removed on a Mac and report back whether the > progress bar gets filled smoothly? > > To me this looks like we are having an issue with background threads > that run their own runloop. As this is an area where I am not very > familiar it would be great if Richard could take over. It would help to have more regression tests ... we have a lot of code written to match the documented behavior, and where that can be interpreted in different ways we get differences between OSX behavior and GNUstep. I added a few testcases for this and tried it out under OSX, and it seems -runUntilDate: should cause timers to fire even when called with nil/distantPast. I'v modified svn trunk to do that. It also seems that -acceptInputInMode:beforreDate: should fire timers (whether there is input available or not) ... but fixing that would be a bigger change. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
