Re: Releases

[Ivan Vučica]

On Tue 10 Jan 2023 at 19:43, Frederik Seiffert 
wrote:

>
> Am 10.01.2023 um 14:27 schrieb Ivan Vučica :
>
> I really would like to minimise the number of steps we have to go through
>> by automating as much as possible.
>
> I did. :-)
>
> Please see my release jottings on Google Docs. They’re not formal
> documentation, but can be interpreted as a playbook with some reading.
>
>
> I’m not familiar with what needs to be done for releases (can you share a
> link to that Google Doc maybe?), but I’m wondering if released could be
> mostly automated on the GitHub Actions CI.
>

Mainly because it is a mess and it’s mainly my notes on what I did + to
share with maintainers, I am not keen on making it publicly visible. If it
were to be a playbook, I’d put it up somewhere in repos as proper
documentation.

However, I’ve added your corporate email address to the ACL for the doc for
2.9.0/1.28.0/0.29.0 release of ~March 2021:

https://docs.google.com/document/d/1DGumTDgxGwsaamnFvJ5WI1puVHHKk2f1t7GNrwLHfi0/edit?usp=sharing

I can add other interested maintainers to these docs, but again, there’s no
point in making this more visible if it’s just notes and not proper
documentation.

I’ll see if I can turn this into something more widely shareable (maybe
once I finally upgrade the wiki schema on the new gnustep.org machine…).


> For the Android and Windows MSVC toolchains, every build on the master
> branch creates a pre-release on GitHub (overwriting the previous one), and
> then if I want to do a release I test the latest build and then simply
> add/edit the change log and check a box to turn it into a release (which
> also creates a corresponding git tag). Here’s the required Actions code:
>
>
> https://github.com/gnustep/tools-android/blob/d71de40e60f71988b40610e39b5df926e6df1687/.github/workflows/ci.yml#L57-L84
>
> In this case, the "prerelease" step will wait for the two builds (macOS
> and Linux) to complete, and then create a "Latest Build" pre-release on
> GitHub with the artifacts for the two platforms.
>

I think it makes sense if you’re doing binaries, but less so if most of the
tedious process is actually getting documentation (release notes…) in
shape, and invoking the correct commands to create the tag in the first
place (using the release notes in the tag).
-- 
Sent from Gmail Mobile

Re: Releases

[Ivan Vučica]

On Wed 11 Jan 2023 at 10:25, David Chisnall 
wrote:

>
> This is on my to-do list for the runtime.  It's something that we're
> doing with other projects and it means that the release process is just
> creating a tag.  This then builds releases for any targets that we want
> to ship binaries for, creates the GitHub release, pushes the built
> artefacts to the release, and adds a new commit on the main branch
> rolling over versions and so on.
>
> David


There’s the GPG signing part that makes Github Actions less useful. That
is: whether you want to use Github actions depends on where you want to
store this rather secret key. (We should rotate the GPG key anyway, by the
way; the one we use for gnustep make/base/gui/back is still a 1024 bit key,
with no delegation to subkeys and no expiration dates set.)

Besides, making the tarballs themselves is the easiest part.

For the make/base/gui/back stuff, the hardest for me was going through the
history, trying to make sense of everyone’s rather cryptic commit messages
and rather lacking ChangeLog updates, identifying and summarizing the
changes into something that might be useful to a reader, putting the
changes into 2 different places, then generating the new release notes file.

If I recall correctly, I touched up gnustep-make so invoking the magic git
release commands will produce the correct annotated tag containing the
release notes file as the tag’s commit message (meaning I have no need to
do anything on Github releases page to make this text show up).

But at that point, building the tarballs and signing them is easy.
Uploading them to Github is just a drag and drop. Uploading them to FTP
(…and I really need to sit down and bring it up on the ‘new’ DigitalOcean
machine, but in a more secure way than using a password over unencrypted
FTP) is easy. Writing release notes and dealing with GPG’s rejections of
the passphrase on the key is difficult.

I never fully completed the work on our own Debian packages so there’s no
point in having Github Actions for that particular purpose. Besides, Debian
‘source’ packages also need to be GPG signed. (Note, I am not talking about
the code we want to upstream into Debian proper; this would be ‘our’
packages, built with libobjc2 and clang, and preferring ‘steppiness’ over
FHS. It was not to be about making them better than Debian-built packages,
but about providing a different experience. And maybe adding a ‘defaults’
package that configures a different theme and such.)

What about win32? I never built win32 releases with NSIS, either. There
have been improvements on building .msi packages on free platforms (GNOME’s
msitools have gotten some GUI support!), but last time I checked, it was
still not sufficiently similar to WiX Tools on Windows.

-- 
Sent from Gmail Mobile

Re: Releases

[Ivan Vučica]

On Sun 8 Jan 2023 at 12:53, Richard Frith-Macdonald <
richardfrithmacdon...@gmail.com> wrote:

>
>
> > 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).


There is an author and date and a message associated with the release.
There can be a GPG signature associated. Typical tags have no metadata:
they’re just files*  containing hash of the commit they point to. When were
they themselves created? By whom? No clarity there.

With annotated tags, we can embed release notes themselves into the history
in case we move off of Github.


> 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.

I did. :-)

Please see my release jottings on Google Docs. They’re not formal
documentation, but can be interpreted as a playbook with some reading.

I am also happy to give a guided tour over video of how I do a release.
Maintainers who are interested, please let me know. I am available on
weekends or weekday evenings.

-- 
Sent from Gmail Mobile

GNUstep devs on FOSDEM 2023?

[Ivan Vučica]

Hi,

I have booked a trip to Brussels during the FOSDEM weekend. I intend to be
at random talks at ULB Solbosch campus, as is traditional during FOSDEM,
but I will also prefer meeting people.

I doubt there will be space in the hacker room, but it would be a good use
of my time to hack away on something. Or we can just talk.

Please let me know if anyone is attending and also wants to meet!
-- 
Sent from Gmail Mobile

Re: Releases

[Ivan Vučica]

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.

On 3 Jan 2023, at 10:13, Ivan Vučica  wrote:
> 
> I can get FTP set up very. I’ll try to do it over the next few days.
> 
> Wiki upgrade is why I procrastinated: I just know something will go wrong and 
> this demotivates me.
> 
> Then there’s the whole web issue with PHP7.x and MySQL modules.
> 
> I’ll try to sort FTP out and then try to keep going. FTP is easy. (Famous 
> last words.)
> 
>> On 28 Dec 2022, at 10:46, Richard Frith-Macdonald  wrote:
>> 
>> 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: Releases

[Ivan Vučica]

I can get FTP set up very. I’ll try to do it over the next few days.

Wiki upgrade is why I procrastinated: I just know something will go wrong and 
this demotivates me.

Then there’s the whole web issue with PHP7.x and MySQL modules.

I’ll try to sort FTP out and then try to keep going. FTP is easy. (Famous last 
words.)

> On 28 Dec 2022, at 10:46, Richard Frith-Macdonald  wrote:
> 
> 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.
> 
> 
> 

ANN: GNUstep GUI Backend 0.29.0

[Ivan Vučica]

MD5 hashes:
2180291733f000eec5c8e61e49e8a54d  gnustep-back-0.29.0.tar.gz
ab378f01a92d636e3ef2674677b5af4e  gnustep-back-0.29.0.tar.gz.sig

1 Announcement
**

This is version 0.29.0 of the GNUstep GUI Backend ('gnustep-back').

1.1 What is the GNUstep GUI Backend?


It is a back-end component for the GNUstep GUI Library.  The
implementation of the GNUstep GUI Library is designed in two parts.  The
first part is the front-end component which is independent of platform
and display system.  This front-end is combined with a back-end
component which handles all of the display system dependent such as
specific calls to the X Window System.  This design allows the GNUstep
applications to have the "look and feel" of the underlying display
system without any changes to the application, and the library can be
easily ported to other display systems.

   The GNUstep GUI Backend is for platforms using the X-Window System or
Window's Systems.  It works via a DPS emulation engine to emulate the
DPS functions required by the front-end system.

1.2 Noteworthy changes in version '0.29.0'
==

The release includes an alpha version of the wayland backend and a few
bug fixes.

   * Alpha version of the wayland backend.
   * Improved focus handling for WindowMaker interaction.
   * Speed up for font pattern resolving.
   * Improved appicon behavior under WindowMaker.
   * Prevent appicon flickering on WindowMaker at application start.
   * On Windows, consistently use 'GetWindowLongPtr' and
 'SetWindowLongPtr' in place of 'GetWindowLong' and 'SetWindowLong'
 for win32 and cairo for various win64 fixes.

1.3 Where can you get it? How can you compile it?
=

The gnustep-back-0.29.0.tar.gz distribution file has been placed at
.

   It is accompanied by gnustep-back-0.29.0.tar.gz.sig, a PGP signature
which you can validate by putting both files in the same directory and
using:

 gpg --verify gnustep-back-0.29.0.tar.gz.sig

   Signature has been created using the key with the following
fingerprint:

 83AA E47C E829 A414 6EF8  3420 CA86 8D4C 9914 9679

   Read the INSTALL file or the GNUstep-HOWTO for installation
instructions.

1.4 Where do I send bug reports?


Please log bug reports on the GNUstep project page
 or send bug reports to
.

1.5 Obtaining GNUstep Software
==

Check out the GNUstep web site.  () and the GNU
web site.  ()



signature.asc
Description: PGP signature

ANN: GNUstep GUI Library 0.29.0

[Ivan Vučica]

MD5 hashes:
39505b2f56952b49adbf6c524fd93d4c  gnustep-gui-0.29.0.tar.gz
6df3f4e445664fb23a467353b9e8ac67  gnustep-gui-0.29.0.tar.gz.sig

1 Announcement
**

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

1.1 What is the GNUstep GUI Library?


It is a library of graphical user interface classes written completely
in the Objective-C language; the classes are based upon Apple's Cocoa
framework.  The library has been enhanced in a number of ways to take
advantage of the GNU system.  These classes include graphical objects
such as buttons, text fields, popup lists, browser lists, and windows;
there are also many associated classes for handling events, colors,
fonts, pasteboards and images.

   The GNUstep GUI Library is designed in two parts.  The first part is
the front-end component which is independent of platform and display
system.  This front-end is combined with a back-end component which
handles all of the display system dependent such as specific calls to
X/Windows.  This design allows the GNUstep applications to have the
"look and feel" of the underlying display system without any changes to
the application, and the library can be easily ported to other display
systems.

   The GNUstep GUI Library requires the GNU Objective-C compiler, the
GNUstep Base Library, the TIFF Graphics library, Independent JPEG
Group's libjpeg library, and a back-end component from the GNUstep
'Back' library.

   Additional functionality may be enabled by installing additional
libraries.  For example, to build the Cairo backend in the GNUstep Back
library, you will need to install Cairo.

1.2 Noteworthy changes in version '0.29.0'
==

This version adds support for storyboard files and many new classes.
Plus the usual bunch of bug fixes.

   * Support loading of storyboard files.
   * Add classes NSSwitch, NSFontAssetRequest,
 NSMediaLibraryBrowserController, NSScrubberItemView,
 NSScrubberLayout, NSScrubber, NSSharingServicePickerToolbarItem,
 NSPathCell, NSPathComponentCell, NSPathControl, NSPathControlItem,
 NSPersistentDocument, NSAccessibilityCustomAction,
 NSAccessibilityCustomRotor, NSAccessibilityElement, NSStoryboard,
 NSStoryboardSegue, NSPageController, NSSplitViewController,
 NSSplitViewItem, NSTabViewController, NSLayoutAnchor,
 NSLayoutConstraint, NSLayoutGuide, NSStatusBarButton,
 NSTextCheckingController, NSTextFinder, NSTextInputContext,
 NSGridView.  Some of these classes are still skeletons.
   * Fix extraline fragment in text layout.
   * Better encoding handling in RTF files.
   * Add more italian translations.
   * Add MacOSX methods to NSNib, NSMenu and NSWindow.
   * Focus handling fixes for WindowMaker.
   * Fix missing colours when loading old colour lists.
   * Support JPEG export as greyscale image.
   * Fix memory leak in NSPopupButtonCell.
   * Fix toolbar flickering.
   * NSSearchFieldCell use code from GSTheme to display popup.
   * Fix int decoding to get it working on 64 bit big endian machines.
   * Add tab stops after last defined at default intervals.
   * Stop NSWindow from handling windows that are gone, but possibly
 returned by a slow window manager.
   * Fix NSTableView/NSTableColumn bindings.

1.3 Where can you get it? How can you compile it?
=

The gnustep-gui-0.29.0.tar.gz distribution file has been placed at
.

   It is accompanied by gnustep-gui-0.29.0.tar.gz.sig, a PGP signature
which you can validate by putting both files in the same directory and
using:

 gpg --verify gnustep-gui-0.29.0.tar.gz.sig

   Signature has been created using the key with the following
fingerprint:

 83AA E47C E829 A414 6EF8  3420 CA86 8D4C 9914 9679

   Read the INSTALL file or the GNUstep-HOWTO for installation
instructions.

1.4 Where do I send bug reports?


Please log bug reports on the GNUstep project page
 or send bug reports to
.

1.5 Obtaining GNU Software
==

Check out the GNUstep web site.  (), and the
GNU web site.  ()



signature.asc
Description: PGP signature

ANN: GNUstep Base 1.28.0

[Ivan Vučica]

MD5 hashes:
776cc378b35483d046a8bb4da4b9ea18  gnustep-base-1.28.0.tar.gz
4c39ab30fe6b702ab8aaba47390a084b  gnustep-base-1.28.0.tar.gz.sig

1 Announcement
**

The GNUstep Base Library, version 1.28.0, is now available.

1.1 What is the GNUstep Base Library?
=

The GNUstep Base Library is a library of general-purpose, non-graphical
Objective C objects.  For example, it includes classes for strings,
object collections, byte streams, typed coders, invocations,
notifications, notification dispatchers, moments in time, network ports,
remote object messaging support (distributed objects), and event loops.

   It provides functionality that aims to implement the non-graphical
portion of the OpenStep standard (the Foundation library).

   There is more information available at the GNUstep homepage at
'http://www.gnustep.org'.

1.2 Noteworthy changes in version '1.28.0'
==

Aside from an assortment of bugfixes, this release includes a lot of
improvements for Windows support as well as numerous new classes and
methods.

   Not every bugfix, improvement or a new feature will be listed here.

   * Reading and setting File Creation Date attribute on Windows.
   * Added new 'ASSIGNMUTABLECOPY()' macro for consistency with
 'ASSIGNCOPY()'.
   * Replaced character set data headers for URLs with loading these
 from a standard data source, and updated bitmap representation to
 use much less space for character sets residing wholly in the base
 plane, such as the URL charsets (given they are purely ASCII).
   * Updated character set data with newer Unicode data set.
   * '[NSURLProtocol -initWithRequest:cachedResponse:client:]' will now
 retain the client up until the last message is sent to it, which
 improves compatibility with OS X.
   * Percent-escaping code in 'NSURL' simplified.
   * Removed mixed ABI support.
   * Use of Apple runtime now assumes non-fragile ABI (which is true on
 modern systems).
   * Improve typing on method implementation pointers in some classes.
   * In 'NSHTTPCookie', rewritten code for extracting individual cookies
 from the HTTP header.
   * In 'NSKeyedArchiver', implement secure coding methods.
   * New methods in 'NSDateComponents'.
   * Improvements in 'NSCalendar' and 'NSLocale' for calendar locale and
 'NSDateComponents'.
   * In 'NSFileManager', use 'utimensat()' to set file modification
 date, if available.
   * Correctly stop parsing number being decoded in
 'NSJSONSerialization' when encountering a number with an invalid
 exponent.
   * Improve OS X compatibility for 'NSURLQueryItem' initializers.
   * For 'NSFileManager', in 'changeFileAttributes', implement setting
 creation date for Unix-like systems.  Implement reading the
 creation date if a supported method was detected.
   * Support reading Android assets from the main bundle in
 'NSInputStream'.
   * Support Android assets directories in 'NSBundle' and
 'NSFileManager'.
   * Implement '-[NSXMLParser initWithStream:]'.
   * Allow clearer choice between 'sloppy' 'GSSloppyXMLParser' used in
 'NSXMLParser' and the libxml2-based 'GSStrictXMLParser'.
   * Fix building Win32 implementations for 'GSFileHandle' and
 'NSMessagePort' with nonfragile ABI.
   * Use 'NSNumber' and not 'NSString' in '-[NSUserDefaults
 setBool:forKey:]'.
   * Posting notification before 'NSThread' exit.
   * Actually declare optional 'NSFilePresenter' methods as optional.
   * In 'NSConcreteMapTable', fix replacing existing values in a weak
 objects map table.
   * Fix leaks in 'NSOperation'.
   * Various compat fixes for various MSYS systems, particularly around
 sockets code.
   * In 'NSData', 'NSFileManager' and more, various improvements when
 overwriting and creating files with respect to file attributes
 (owners, creation timestamp, etc).
   * Improve 'NSLog' output on Android.
   * Use 'instancetype' in 'NSURLRequest' header.
   * Define 'NSAttributedStringKey' and 'NSNotificationName'.
   * Add new 'NSURL' methods.
   * In 'GSMime', have '-contentFile' check the 'Content-Type' header
 before checking 'Content-Disposition'.
   * Fix a bug linking with WEAK symbols where binutils 2.3.5 would fail
 to link due to not all expected symbols being exported.
   * New 'plutil' utility.
   * Implementation of '[NSData rangeOfData:options:range:]' which finds
 the 'NSRange' in which the passed data occurs.
   * Change 'ENTER_POOL'/'LEAVE_POOL' so they no longer wrap the
 enclosed code in a loop, enabling use in some loops.
   * New 10.5 methods in 'NSRunLoop'/'NSURLConnection'.
   * Improve compatibility when building with ICU 68.
   * Fix compiling libdispatch integration of 'NSRunLoop' on Windows.
   * Add support for building on Windows with MSVC's Clang by passing
 the 'configure' flag '--host=x86_64-pc-windows'.  Use of an MSYS2
 shell without '-devel' 

ANN: GNUstep Makefile Package 2.9.0

[Ivan Vučica]

MD5 hashes:
6ddb71d5b312e50e98a2e6fad8c766d0  gnustep-make-2.9.0.tar.gz
cec74c3453a7187817177abb7de8fb17  gnustep-make-2.9.0.tar.gz.sig

1 Announcement
**

The GNUstep Makefile Package version 2.9.0 is now available.

1.1 What is the GNUstep Makefile Package?
=

The makefile package is a simple, powerful and extensible way to write
makefiles for a GNUstep-based project.  It allows the user to write a
project without having to deal with the complex issues associated with
configuration, building, installation, and packaging.  It also allows
the user to easily create cross-compiled binaries.

1.2 Changes in version '2.9.0'
==

   * Better check for objc runtime on Windows.

   * Split linker flags to better support partial linking: 'ALL_LDFLAGS'
 is now a combination of 'FINAL_LDFLAGS' and 'ALL_LDFLAGS'.

   * Better support for newer gcc versions.

   * Add support for storyboard files.

   * Increase autoconf version to 2.65 and make autoconf handle
 Objective-C++ and OBJCXX variables directly.

   * Fix bug that prevented ARC from getting used.

   * Link subproject object files directly instead of first merging them
 into 'subproject.o'.

   * Support building on Windows with Clang MSVC target.

   * Improve mingw64 support: for instance, adopt the triplet used by
 the mingw-w64 project rather than using the one returned by
 autoconf.  Fixes building Gorm.

1.3 Obtaining gnustep-make
==

You can get the gnustep-make-2.9.0.tar.gz distribution file at


   It is accompanied by gnustep-make-2.9.0.tar.gz.sig, a PGP signature
which you can validate by putting both files in the same directory and
using:

 gpg --verify gnustep-make-2.9.0.tar.gz.sig

   Signature has been created using the key with the following
fingerprint:

 83AA E47C E829 A414 6EF8  3420 CA86 8D4C 9914 9679

   Read the INSTALL file or the GNUstep-HOWTO for installation
instructions.

1.4 Where do I send bug reports?


Please log bug reports on the GNUstep project page
 or send bug reports to
.

1.5 Obtaining GNUstep Software
==

Check out the GNUstep web site.  () and the GNU
web site.  ()


signature.asc
Description: PGP signature

Re: GNUstep releases this month?

[Ivan Vučica]

I'll take these tarballs, upload to usual places and make an announcement
likely tomorrow. Consider the tarballs final, even if I didn't upload them
into usual places yet. Git tags are already pushed.

sent from phone

On Sun 2 May 2021, 15:23 Gregory Casamento, 
wrote:

> I did a build as well and ran the tests.   Seems fine.
>
> GC
>
>
> On Fri, Apr 30, 2021 at 11:25 AM Riccardo Mottola <
> riccardo.mott...@libero.it> wrote:
>
>> Hi
>>
>> I did a build ot base/gui/back on linux/amd64 gcc and found no issues.
>> Maybe this is enough to tell that the packages are complete. Didn't test
>> for bugs on all platforms to know if you caught a good git version or not.
>>
>> Riccardo
>>
>> Ivan Vučica wrote:
>> > (This is not a release announcement)
>> >
>> > A signed build of gnustep-gui / gnustep-back 0.29.0 has been uploaded
>> > at http://badc0de.net/gs/2021.
>> >
>> > Actual final releases will, as always, be distributed via GNUstep FTP.
>> > Please give this test build a go.
>> >
>> > ===
>> >
>> > Psst! If you are using themes such as Rik, you might need to rebuild
>> > them, even if there were no code changes. This is usually the case, I
>> > suspect, as well; but today I was bit by it for the first time. It was
>> > curious as I only saw problems on applications I rebuilt -- which in
>> > retrospect makes sense, given the SO bump.
>> >
>> > ===
>> >
>> > Now that all four libs are prepared, I will give it a few days to
>> > receive a stop signal, or an actively-green-light from maintainers.
>> > Then I will send out announcement emails, create GitHub releases, etc.
>> >
>> > Of course, if you spot a small thing that we _can_ fix post release
>> > (i.e. not a full showstopper), I will be happy to cut a smaller
>> > point-release.
>> >
>> >
>> > On Mon, Apr 26, 2021 at 10:34 PM Ivan Vučica  wrote:
>> >> (This is not a release announcement)
>> >>
>> >> A signed build of gnustep-base 1.28.0 has been uploaded at
>> >> http://badc0de.net/gs/2021.
>> >>
>> >> Actual final releases will, as always, be distributed via GNUstep FTP.
>> >> Please give this test build a go.
>> >>
>> >> I will continue preparing gnustep-gui and gnustep-back.
>> >>
>> >> On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica  wrote:
>> >>> I am resuming work on releases today and hope to prepare at least
>> >>> -base tarball today.
>> >>>
>> >>> On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
>> >>>  wrote:
>> >>>>
>> >>>> Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald <
>> rich...@frithmacdonald.me.uk>:
>> >>>>
>> >>>> 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).
>> >>>>
>> >>>>
>> >>>> I’ve pushed a change in the following PR that fixes the test failure:
>> >>>>
>> https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
>> >>>>
>> >>>> Frederik
>> >>>>
>>
>>
>>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store
>

Re: GNUstep releases this month?

[Ivan Vučica]

(This is not a release announcement)

A signed build of gnustep-gui / gnustep-back 0.29.0 has been uploaded
at http://badc0de.net/gs/2021.

Actual final releases will, as always, be distributed via GNUstep FTP.
Please give this test build a go.

===

Psst! If you are using themes such as Rik, you might need to rebuild
them, even if there were no code changes. This is usually the case, I
suspect, as well; but today I was bit by it for the first time. It was
curious as I only saw problems on applications I rebuilt -- which in
retrospect makes sense, given the SO bump.

===

Now that all four libs are prepared, I will give it a few days to
receive a stop signal, or an actively-green-light from maintainers.
Then I will send out announcement emails, create GitHub releases, etc.

Of course, if you spot a small thing that we _can_ fix post release
(i.e. not a full showstopper), I will be happy to cut a smaller
point-release.


On Mon, Apr 26, 2021 at 10:34 PM Ivan Vučica  wrote:
>
> (This is not a release announcement)
>
> A signed build of gnustep-base 1.28.0 has been uploaded at
> http://badc0de.net/gs/2021.
>
> Actual final releases will, as always, be distributed via GNUstep FTP.
> Please give this test build a go.
>
> I will continue preparing gnustep-gui and gnustep-back.
>
> On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica  wrote:
> >
> > I am resuming work on releases today and hope to prepare at least
> > -base tarball today.
> >
> > On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
> >  wrote:
> > >
> > >
> > > Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
> > > :
> > >
> > > 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).
> > >
> > >
> > > I’ve pushed a change in the following PR that fixes the test failure:
> > > https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
> > >
> > > Frederik
> > >

Re: GNUstep releases this month?

[Ivan Vučica]

(This is not a release announcement)

A signed build of gnustep-base 1.28.0 has been uploaded at
http://badc0de.net/gs/2021.

Actual final releases will, as always, be distributed via GNUstep FTP.
Please give this test build a go.

I will continue preparing gnustep-gui and gnustep-back.

On Thu, Apr 22, 2021 at 8:12 PM Ivan Vučica  wrote:
>
> I am resuming work on releases today and hope to prepare at least
> -base tarball today.
>
> On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
>  wrote:
> >
> >
> > Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
> > :
> >
> > 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).
> >
> >
> > I’ve pushed a change in the following PR that fixes the test failure:
> > https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
> >
> > Frederik
> >

Re: base: running make in Documentation subdir broken

[Ivan Vučica]

Thank you! Seeing the patch was informative and a learning experience.

On Fri, Apr 23, 2021 at 6:58 AM Richard Frith-Macdonald
 wrote:
>
>
>
> > 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: base: running make in Documentation subdir broken

[Ivan Vučica]

On Thu, Apr 22, 2021 at 10:38 PM Ivan Vučica  wrote:
>
> Actually, I'm calling it:
>
> the generated documentation is useless hence this is a show stopper. Most 
> classes are affected and don't generate any documentation.
>
> I will commit the work for this evening, but I will not tag the release. 
> Someone please address the broken doc generator.

This has been filed as https://github.com/gnustep/libs-base/issues/182.

base: running make in Documentation subdir broken

[Ivan Vučica]

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?

Re: [gnustep/libs-base] 79f738: Merge pull request #10 from gnustep/master

[Ivan Vučica]

Can we please all rebase commits before merging, rather than merging
merge commits?

On Fri, Nov 13, 2020 at 2:31 PM 'rfm' via gnustep-commits
 wrote:
>
>   Branch: refs/heads/master
>   Home:   https://github.com/gnustep/libs-base
>   Commit: 79f738ceb1dc9ebd4b39db1914faca61f5b175e7
>   
> https://github.com/gnustep/libs-base/commit/79f738ceb1dc9ebd4b39db1914faca61f5b175e7
>   Author: Adam Fox 
>   Date:   2020-10-12 (Mon, 12 Oct 2020)
>
>   Changed paths:
> M .gitignore
> M .travis.yml
> M ANNOUNCE
> M ChangeLog
> M Documentation/ReleaseNotes.gsdoc
> M Documentation/announce.texi
> M Documentation/news.texi
> M Examples/dictionary.m
> M Examples/nsconnection_client.m
> R Headers/Foundation/MISSING
> M Headers/Foundation/NSAttributedString.h
> M Headers/Foundation/NSCalendar.h
> M Headers/Foundation/NSError.h
> M Headers/Foundation/NSException.h
> M Headers/Foundation/NSFilePresenter.h
> M Headers/Foundation/NSKeyedArchiver.h
> M Headers/Foundation/NSLocale.h
> M Headers/Foundation/NSNotification.h
> M Headers/Foundation/NSObjCRuntime.h
> M Headers/Foundation/NSOperation.h
> M Headers/Foundation/NSPropertyList.h
> M Headers/Foundation/NSURL.h
> M Headers/Foundation/NSURLProtocol.h
> M Headers/Foundation/NSURLRequest.h
> M Headers/Foundation/NSUUID.h
> M Headers/Foundation/NSXMLParser.h
> M Headers/Foundation/NSXPCConnection.h
> M Headers/GNUstepBase/GNUstep.h
> M Headers/GNUstepBase/GSConfig.h.in
> M Headers/GNUstepBase/GSIMap.h
> M Headers/GNUstepBase/GSVersionMacros.h
> M Headers/GNUstepBase/GSXML.h
> M Headers/GNUstepBase/config.h.in
> A MISSING
> M NEWS
> M README.initialize
> M Resources/Languages/Locale.canonical
> M Resources/Languages/README
> M Source/Additions/GSInsensitiveDictionary.m
> M Source/Additions/GSMime.m
> M Source/Additions/GSObjCRuntime.m
> M Source/Additions/GSXML.m
> M Source/Additions/NSArray+GNUstepBase.m
> M Source/Additions/NSData+GNUstepBase.m
> M Source/Additions/NSObject+GNUstepBase.m
> M Source/Additions/NSProcessInfo+GNUstepBase.m
> M Source/Additions/NSPropertyList+GNUstepBase.m
> M Source/Additions/NSURL+GNUstepBase.m
> R Source/CharSets/URLFragmentAllowedCharSet.h
> R Source/CharSets/URLHostAllowedCharSet.h
> R Source/CharSets/URLPasswordAllowedCharSet.h
> R Source/CharSets/URLPathAllowedCharSet.h
> R Source/CharSets/URLQueryAllowedCharSet.h
> R Source/CharSets/URLUserAllowedCharSet.h
> M Source/GSAttributedString.m
> M Source/GSDictionary.m
> M Source/GSNetwork.h
> M Source/GSSocketStream.m
> M Source/GSString.m
> M Source/GSTLS.m
> M Source/NSBundle.m
> M Source/NSCalendar.m
> M Source/NSCharacterSet.m
> M Source/NSCharacterSetData.h
> M Source/NSConcreteMapTable.m
> M Source/NSConnection.m
> M Source/NSData.m
> M Source/NSDateComponentsFormatter.m
> M Source/NSDictionary.m
> M Source/NSError.m
> M Source/NSException.m
> M Source/NSFileManager.m
> M Source/NSFileWrapper.m
> M Source/NSHTTPCookie.m
> M Source/NSHost.m
> M Source/NSISO8601DateFormatter.m
> M Source/NSInvocationOperation.m
> M Source/NSJSONSerialization.m
> M Source/NSKeyValueObserving.m
> M Source/NSKeyedArchiver.m
> M Source/NSKeyedUnarchiver.m
> M Source/NSLocale.m
> M Source/NSLog.m
> M Source/NSNotification.m
> M Source/NSObject.m
> M Source/NSOperation.m
> M Source/NSOrthography.m
> M Source/NSPersonNameComponentsFormatter.m
> M Source/NSPortCoder.m
> M Source/NSPredicate.m
> M Source/NSProcessInfo.m
> M Source/NSSocketPortNameServer.m
> M Source/NSString.m
> M Source/NSTask.m
> M Source/NSThread.m
> M Source/NSTimer.m
> M Source/NSURL.m
> M Source/NSURLProtocol.m
> M Source/NSURLRequest.m
> M Source/NSURLResponse.m
> M Source/NSUUID.m
> M Source/NSUnarchiver.m
> M Source/NSUserDefaults.m
> M Source/NSValueTransformer.m
> M Source/NSXMLParser.m
> M Source/NSXPCConnection.m
> M Source/inet_ntop.m
> M Source/inet_pton.m
> M Source/objc-load.m
> M Source/unix/NSStream.m
> M Source/win32/GSFileHandle.m
> M Source/win32/NSMessagePort.m
> M Tests/GNUmakefile
> M Tests/base/GSTLS/basic.m
> M Tests/base/NSBundle/GNUmakefile.preamble
> M Tests/base/NSBundle/Resources/GNUmakefile
> M Tests/base/NSBundle/resources2.m
> M Tests/base/NSCalendar/features-10-7.m
> M Tests/base/NSCharacterSet/general.m
> M Tests/base/NSDictionary/general.m
> M Tests/base/NSFileManager/general.m
> M Tests/base/NSHTTPCookie/basic.m
> M Tests/base/NSLocale/general.m
> M Tests/base/NSMapTable/weakObjects.m
> M Tests/base/NSNotification/basic.m
> M Tests/base/NSProxy/test00.m
> M Tests/base/NSProxy/test01.m
> M 

Re: GNUstep releases this month?

[Ivan Vučica]

I am resuming work on releases today and hope to prepare at least
-base tarball today.

On Fri, Mar 26, 2021 at 11:43 AM Frederik Seiffert
 wrote:
>
>
> Am 22.03.2021 um 19:03 schrieb Richard Frith-Macdonald 
> :
>
> 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).
>
>
> I’ve pushed a change in the following PR that fixes the test failure:
> https://github.com/gnustep/libs-base/pull/177/commits/e1e661286a6b9d717dc0312bed5f8b4b5e549d6f
>
> Frederik
>

Rotating the dev GPG key

[Ivan Vučica]

Hi all,

We are still using a non-expiring 1024-bit DSA key to sign our
releases. If we're spending time on signing the releases in the first
place, this seems a bit silly.

I propose we phase out this key; after this batch of releases, we
should use it to sign a new key and then discontinue its use. I am not
sure whether to suggest revocation, or setting some short expiration
date.

If we agree to do that, I can do this, and coordinate delivering the
new key(s) to maintainers off-list. If I am generating the new key,
I'd also sign the key with my personal key, which has some
FOSDEM-signing-party signatures on it.

Let me know what you think.

Re: GNUstep releases this month?

[Ivan Vučica]

On Sat, Mar 20, 2021 at 10:48 AM Richard Frith-Macdonald
 wrote:
> > On 19 Mar 2021, at 15:40, Ivan Vučica  wrote:
> >
> > I am thinking of doing it this weekend, any objection?
> >
>
> That sounds good to me.

As usual, I won't send actual announcements or upload to FTP until
we've had a chance to test the builds.

Due to problems with the maintainer key, I've managed only to cut
gnustep-make today. The problems were resolved only by creating a new
GNUPGHOME -- which only too late did I realize is the same that I've
done the last time.

gnustep-make's signed tarball is uploaded here: http://badc0de.net/gs/2021

This is not a release announcement (nor even necessarily the final
tarball for gnustep-make 2.9.0).

Where do we ingest bugreports?

[Ivan Vučica]

Generated ANNOUNCE file for gnustep-make 2.9.0 will still contain the following:

1.4 Where do I send bug reports?


Please log bug reports on the GNUstep project page
 or send bug reports to
.

Do we want to ingest bugs on Savannah or elsewhere? I'm reluctant to
advocate for GitHub, but I believe some maintainers may have voiced a
preference for bugs being sent there.

If so, please ensure you update your project's
Documentation/announce.texi or the equivalent file that is used as the
source for the ANNOUNCE file (which is the basis for git annotated
tag's text and for the announcement emails that I fire off to various
mailing lists).

Re: GNUstep releases this month?

[Ivan Vučica]

I am thinking of doing it this weekend, any objection?

sent from phone

On Wed 3 Mar 2021, 20:05 Riccardo Mottola, 
wrote:

> Hi,
>
> Richard Frith-Macdonald wrote:
> > 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
> :-)
>
> really catastrophic. Since 64bit is only supported since Windows 2000, I
> think that would restrict to  Alpha, since PPC was only supported in NT4
> if I am right :) And no mingw outside intel, AFAIK.
>
> Still, not elegant.. I think I just found the spot and addressed it in
> my last commit.
>
> I'll write some changelog and open a PR, just in time for the release!
>
> Riccardo
>

Re: GNUstep releases this month?

[Ivan Vučica]

I haven't really done releases of core GNUstep project's software beyond
core libraries.

Additionally, this is not in the core project, but in GAP. +Riccardo Mottola
 might know more.

On Sun, Feb 28, 2021 at 9:12 PM Johannes Brakensiek <
johan...@brakensiek.info> wrote:

>
> On 28 Feb 2021, at 20:56, Ivan Vučica wrote:
>
> > 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.
>
> Great.
>
> Riccardo, may I ask you to do a release of PDFKit as well? The currently
> released makefile is not compatible with libobjc2. svn works.
>
> Thank you
> Johannes
>
>

Re: GNUstep releases this month?

[Ivan Vučica]

Noted. I'll try to make it happen during the week, unless tiredness of
work prevents me. I'll check the news.texi etc for new changes.

On Sat, Feb 27, 2021 at 3:17 PM Richard Frith-Macdonald
 wrote:
>
>
>
> > 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: GNUstep releases this month?

[Ivan Vučica]

I'll wait for a thumbs-up.

On Thu, Jan 21, 2021 at 2:02 PM Riccardo Mottola
 wrote:
>
> Hi,
>
> Fred Kiefer wrote:
> > 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.
>
>
> in the meanwhile, I did run the test suite:
>
> Working (before)
> 9231 Passed tests
>  207 Failed tests
>   46 Dashed hopes
>   14 Skipped sets
>1 Failed file
>1 Failed build
>
> Current:
>
> 9236 Passed tests
>  202 Failed tests
>   46 Dashed hopes
>   14 Skipped sets
>1 Failed file
>1 Failed build
>
> so actually we "fixed" some tests :) :)
>
>
> Riccardo
>
>

Re: [ML] Re: Hosting of gnustep.org

[Ivan Vučica]

On Tue, Jan 19, 2021 at 9:32 PM Svetlana Tkachenko
 wrote:
> However, ideally, I would recommend that a mirror of all GitHub content is 
> maintained elsewhere, in case this big company decides to ask for money, 
> disappear, change hosting policies, or something else happens to it.

Use `git clone`?

Re: GNUstep releases this month?

[Ivan Vučica]

On Tue, Jan 19, 2021 at 11:26 AM Riccardo Mottola
 wrote:
> my only "itch" which would be a regression is the bug of the icon, the
> stuff Sergeii did...

Can you clarify this? What action needs to be taken before the
release? Can you link to the bug so I can understand this better?

Re: [ML] Re: Hosting of gnustep.org

[Ivan Vučica]

On Tue, Jan 19, 2021 at 7:18 AM H. Nikolaus Schaller  wrote:
>
>
> > Am 19.01.2021 um 00:36 schrieb Ivan Vučica :
> >
> > Some options:
> >
> > - Should we turn the index into a set of static pages generated from
> > MySQL data, which we then check in?
> > - If we turn each entry into a single .md file, we can perhaps
> > leverage https://github.com/allejo/jekyll-toc
>
> Hm.
>
> The page is highly interactive (searching/filtering/jumping) and accepts
> proposing updates. It is even counting access and building a TOP10 list.
>
> How should that work with static content?

Hypothetically speaking, as I don't want to put that much effort and
I'd rather let it run as-is:

As we stand, there aren't so many items. The list of them can be
fetched all at once, and filtered/searched client-side, if we need
that.

Top 10 is, obviously, not doable. However, I missed that it's based on
an access metric; I thought it was simply the 'last 10'.

Interestingly, we have plenty of pages that are making outgoing
requests and failing; for instance, the number 1 on top 10:
http://www.gnustep.org/softwareindex/showdetail.php?app=61

Should we rethink the index?

>
> > - We could have a tiny nginx host which does nothing but route
> > requests to serving backends based on the path:
> >  - either proxy the request to gnustep.github.io,
> >  - or proxy it to a host with the software index (or even return a
> > 301 to something like index.gnustep.org)
>
> Keep it simple...
>
> Why not just redirect the entry point www.gnustep.org/index.html to
> the new page and leave the remainder like the softwareindex on the
> existing infrastructure (apache, php, mysql)?
>
> This should suffice
>
> www.gnustep.org/index.html;
>
> https://gnustep.github.io/index.html"/>

Because this situation relegates the "main site" to a secondary URL,
permanently. I've done that before and I regret it. And it prevents us
from even attempting to preserve location of other URLs which would be
completely fine as static pages. (Search engines will eventually index
gnustep.github.io as the sole main site. But right now it's not even
on the first page of results on three major search engines I tested
on.)

>
>
> >
> > I can play with moving things around over some weekend, if I get
> > sufficient access to current host.
> >
> >
> > On Mon, Jan 18, 2021 at 6:03 PM H. Nikolaus Schaller  
> > wrote:
> >>
> >> Hi,
> >> I just recognized that making gnustep.org point somewhere else will break
> >>
> >> http://www.gnustep.org/softwareindex/
> >>
> >> unless this is moved as well.
> >> It is long ago that someone did set this up and it still works...
> >>
> >> The Software Index needs php, a httpd and a mysql database to be hosted 
> >> somewhere. I am not sure if gnustep.github.io can provide this.
> >>
> >> BR,
> >> Nikolaus
> >>
> >>> Am 18.01.2021 um 18:26 schrieb Patryk Laurent :
> >>>
> >>> Hi Greg,
> >>>
> >>> Could we make a plan to implement pointing the domain to the Gitub-hosted 
> >>> site and/or delegate someone to do it?
> >>>
> >>> Aside from the navigation menu improvements already committed on the 
> >>> GitHub version of the site, we could also incorporate or link to sites to 
> >>> increase visibility e.g., https://teespring.com/stores/gnustep
> >>>
> >>> Best regards,
> >>> Patryk
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Dec 18, 2019, at 13:01, Ivan Vučica  wrote:
> >>>>
> >>>> On Wed, Dec 18, 2019 at 1:17 PM Manuel Guesdon  
> >>>> wrote:
> >>>>>
> >>>>> - make a CNAME www.gnustep.org => gnustep.github.io (but server hosting
> >>>>>  gnustep.github.io should accept requests for www.gnustep.org)
> >>>>
> >>>> This merely requires creating a file named 'CNAME' in the github repo
> >>>> for gnustep.github.io (i.e.
> >>>> https://github.com/gnustep/gnustep.github.io).
> >>>>
> >>>> See 
> >>>> https://help.github.com/en/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site
> >>>>
> >>>>> I can't make a CNAME gnustep.org => gnustep.github.io (due to the way 
> >>>>> DNS
> >>>>> works) but I can make a 301 redirect http://gnustep.org
> >>>>> => http://www.gnustep.org
> >>>>
> >>>> Looks like Github documents the exact IPs that can be used:
> >>>> https://help.github.com/en/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site#configuring-an-apex-domain
> >>>>
> >>>> Then again, 301 + CNAME for www are probably more maintainable.
> >>
> >>
>

Re: GNUstep releases this month?

[Ivan Vučica]

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.

Re: [ML] Re: Hosting of gnustep.org

[Ivan Vučica]

Some options:

- Should we turn the index into a set of static pages generated from
MySQL data, which we then check in?
- If we turn each entry into a single .md file, we can perhaps
leverage https://github.com/allejo/jekyll-toc
- We could have a tiny nginx host which does nothing but route
requests to serving backends based on the path:
  - either proxy the request to gnustep.github.io,
  - or proxy it to a host with the software index (or even return a
301 to something like index.gnustep.org)

I can play with moving things around over some weekend, if I get
sufficient access to current host.


On Mon, Jan 18, 2021 at 6:03 PM H. Nikolaus Schaller  wrote:
>
> Hi,
> I just recognized that making gnustep.org point somewhere else will break
>
> http://www.gnustep.org/softwareindex/
>
> unless this is moved as well.
> It is long ago that someone did set this up and it still works...
>
> The Software Index needs php, a httpd and a mysql database to be hosted 
> somewhere. I am not sure if gnustep.github.io can provide this.
>
> BR,
> Nikolaus
>
> > Am 18.01.2021 um 18:26 schrieb Patryk Laurent :
> >
> > Hi Greg,
> >
> > Could we make a plan to implement pointing the domain to the Gitub-hosted 
> > site and/or delegate someone to do it?
> >
> > Aside from the navigation menu improvements already committed on the GitHub 
> > version of the site, we could also incorporate or link to sites to increase 
> > visibility e.g., https://teespring.com/stores/gnustep
> >
> > Best regards,
> > Patryk
> >
> >
> >
> >
> >
> >> On Dec 18, 2019, at 13:01, Ivan Vučica  wrote:
> >>
> >> On Wed, Dec 18, 2019 at 1:17 PM Manuel Guesdon  wrote:
> >>>
> >>> - make a CNAME www.gnustep.org => gnustep.github.io (but server hosting
> >>>   gnustep.github.io should accept requests for www.gnustep.org)
> >>
> >> This merely requires creating a file named 'CNAME' in the github repo
> >> for gnustep.github.io (i.e.
> >> https://github.com/gnustep/gnustep.github.io).
> >>
> >> See 
> >> https://help.github.com/en/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site
> >>
> >>> I can't make a CNAME gnustep.org => gnustep.github.io (due to the way DNS
> >>> works) but I can make a 301 redirect http://gnustep.org
> >>> => http://www.gnustep.org
> >>
> >> Looks like Github documents the exact IPs that can be used:
> >>  
> >> https://help.github.com/en/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site#configuring-an-apex-domain
> >>
> >> Then again, 301 + CNAME for www are probably more maintainable.
>
>

Re: GNUstep releases this month?

[Ivan Vučica]

On Thu, Jan 14, 2021 at 7:51 PM Yavor Doganov  wrote:
>
> Ivan Vučica wrote:
> > Debian is soft-freezing on 2021-02-12.
>
> Debian is already in library transition freeze so please don't rush
> with the releases just for the sake of it.  We had a chat with Gürkan
> recently and decided that we won't manage for bullseye should there be
> new GNUstep releases.
>
> Sorry that again I failed to inform you in advance but life's been
> incredibly difficult in our colonized territory.

No worries, thank you for your work in general! I should also pay
closer attention.

On Mon, Jan 18, 2021 at 10:55 AM Richard Frith-Macdonald
 wrote:
> > 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.

Thank you, Fred and Richard. Since Yavor said we'll miss the train
anyway, I won't rush; I'll probably do my part of the work over the
upcoming weekend.

Re: GNUstep releases this month?

[Ivan Vučica]

Hi Fred,

thanks for a quick reply!

I suspect that's where the difference between soft- and hard-freeze
kicks in, but Yavor can maybe provide some insight in this regard.

If I get the green lights from other maintainers, I can cut releases next week.

If a maintainer wishes me to release and upload anything that is not
included in the usual batch of releases on ftp.gnu.org, let me know
and I can try pushing that out as well.

On Thu, Jan 14, 2021 at 6:27 PM Fred Kiefer  wrote:
>
> Hi Ivan,
>
> great that you remind us! The problem at the moment is that there is a know 
> problem for 64bit big endian systems in gui (actually a rather long standing 
> issue) and even two suitable solutions for it. But we haven’t decided which 
> solution to prefer. Either we reach a consensus quickly and deploy the chosen 
> solution to all affected classes or we release with this know issue. This 
> sounds worse than it is. We had the issue for a few years and releases 
> already and nobody noticed.
>
> Apart from that I promise to bring the release notes of gui and back up to 
> date over the weekend.
>
> Cheers,
> Fred
>
> > Am 14.01.2021 um 18:40 schrieb Ivan Vučica :
> >
> > Hi maintainers et al!
> >
> > What's the status of our individual projects? Should I plan on cutting
> > the releases this or the next weekend?
> >
> > Debian is soft-freezing on 2021-02-12. 
> > https://wiki.debian.org/DebianBullseye
> >
> > I'd like to ask maintainers who are interested in a release happening
> > to please update the release documentation (see my commits from
> > just-before-the-previous-release). Obviously, there's no need to
> > update anything that's automatically generated.
> >
> > The less time I need to spend on producing the release notes by
> > reading through the commits and trying to piece together a story, the
> > easier it is to make the release, validate it builds, sign it, upload
> > it, prepare the signed emails for sending to GNU announcements, etc. I
> > am happy to review maintainers' (or other volunteers') PRs updating
> > the docs. If the docs are not updated, I am still ok writing the
> > updates myself, it might just be messy.
> >
> > The faster we can cut a release, the higher the chance that there's
> > enough time for Debian package maintainers to get the package through
> > the bureaucracy and into the bullseye archives.
> >
>
>

GNUstep releases this month?

[Ivan Vučica]

Hi maintainers et al!

What's the status of our individual projects? Should I plan on cutting
the releases this or the next weekend?

Debian is soft-freezing on 2021-02-12. https://wiki.debian.org/DebianBullseye

I'd like to ask maintainers who are interested in a release happening
to please update the release documentation (see my commits from
just-before-the-previous-release). Obviously, there's no need to
update anything that's automatically generated.

The less time I need to spend on producing the release notes by
reading through the commits and trying to piece together a story, the
easier it is to make the release, validate it builds, sign it, upload
it, prepare the signed emails for sending to GNU announcements, etc. I
am happy to review maintainers' (or other volunteers') PRs updating
the docs. If the docs are not updated, I am still ok writing the
updates myself, it might just be messy.

The faster we can cut a release, the higher the chance that there's
enough time for Debian package maintainers to get the package through
the bureaucracy and into the bullseye archives.

Re: Building GNUstep for Windows using Clang

[Ivan Vučica]

I am not in favor of committing binaries into otherwise highly compressible
repositories, those containing primarily source code.

Clone operations become heavyweight and eliminating the binary from history
is, like any other file, difficult.

If we start to commit binaries, can it be in separate optional
repositories, please?

sent from phone

On Wed 2 Dec 2020, 16:08 Gregory Casamento, 
wrote:

> Just a suggestion.  Could you commit the binary resulting from the build?
> While David might disagree, this is a very heavyweight and difficult build
> process.  I would prefer to spare others from having to go through it.  If
> someone else doesn't commit it, I will go through the process and do it
> myself.
>
> GC
>
>
> On Wed, Dec 2, 2020 at 7:24 AM Frederik Seiffert 
> wrote:
>
>>
>> Am 02.12.2020 um 10:50 schrieb David Chisnall > >:
>>
>> You should be able to just do a Windows build with the VS command prompt
>> and CMake.  I normally build clang with CMake + Ninja + either Visual
>> Studio or an existing LLVM install on Windows.  There are no other
>> dependencies.
>>
>>
>> Thanks, it’s building now, fans spinning. :)
>>
>> Frederik
>>
>>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store
>

Re: CMake 3.16

[Ivan Vučica]

On Fri, May 15, 2020 at 11:03 AM David Chisnall
 wrote:
>
> Hi all,
>
> At some point, I'd like to move libobjc2 to requiring at least CMake
> 3.16.  3.15 gained support for driving the GCC-flavoured clang on
> Windows with the Visual Studio ABI (older versions have to use clang-cl,
> which takes Visual Studio-compatible arguments).  3.16 gained native
> support for building Objective-C[++].
>
> Both of these changes will reduce the complexity of the libobjc2 build
> system.  Currently, I have 3.17.2 on Windows and FreeBSD, installed from
> choco on Windows and the default package system on FreeBSD, but I am
> aware that other platforms are less good at updating developer tools.
>
> 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.
>
> David
>
>

Current Debian stable, from July 2019, has 3.13. Debian testing,
eventually becoming stable, has a 3.16 version in it.

Therefore, I can easily use 3.16 myself.

I know you're asking about /our/ /development/ machines, but for
end-users, I'd say most Ubuntu users will still be on 18.04 LTS, some
might be on 16.04 LTS (given 5yr support didn't run out yet). It would
probably be nice to wait at least a bit before nuking support for
18.04 and its derivatives. And I suppose CentOS that Richard mentioned
is also important to keep in mind?

If you want to move to it sooner rather than later, how about an
alternative deprecated CMakeLists.txt for older systems, one which
gets phased out in ~1.5-2y or so?

Re: Next GNUstep release

[Ivan Vučica]

Honestly — it's merely not top of my priority list. I consider it unblocked
and will finish the release "soon".

sent from phone

On Sun, Apr 12, 2020, 17:20 Gregory Casamento 
wrote:

> What is the status of the current release?   I hope this ChangeLog
> discussion is not holding things up.
>
> On Sat, Apr 11, 2020 at 11:58 AM Ivan Vučica  wrote:
>
>> On Thu, Apr 9, 2020 at 9:11 AM Riccardo Mottola
>>  wrote:
>> >
>> > Hi,
>> >
>> > > Should we enforce each commit to be larger before publishing? Should
>> > > we enforce commit chains to end up in a merge commit which is
>> > > detailed? Should we enforce updating changelog-equivalent only when a
>> > > particular feature is finished and ready to be added -- but *enforce
>> > > it consistently*?
>> >
>> > No please not minimum length...
>>
>> To clarify, I mean a human raising a fuss and saying "this can't be
>> merged like this, fix the changelog/miniblog/whatever".
>>
>>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
>

Re: Next GNUstep release

[Ivan Vučica]

On Thu, Apr 9, 2020 at 9:11 AM Riccardo Mottola
 wrote:
>
> Hi,
>
> > Should we enforce each commit to be larger before publishing? Should
> > we enforce commit chains to end up in a merge commit which is
> > detailed? Should we enforce updating changelog-equivalent only when a
> > particular feature is finished and ready to be added -- but *enforce
> > it consistently*?
>
> No please not minimum length...

To clarify, I mean a human raising a fuss and saying "this can't be
merged like this, fix the changelog/miniblog/whatever".

Re: Next GNUstep release

[Ivan Vučica]

Please also see the other thread for my thoughts so I don't repeat
them in detail, but just this:

On Mon, Apr 6, 2020 at 2:46 PM David Chisnall  wrote:
>  Compare these two pages:
>
> The ChangeLog file:
> https://github.com/gnustep/libs-base/blob/master/ChangeLog
>
> The Git history:
> https://github.com/gnustep/libs-base/commits/master
>
> The second is easier to skim, easier to jump to exact changes, and
> easier to use to isolate change in a particular area (only care about
> changes in the tools?  Look here:
> https://github.com/gnustep/libs-base/commits/master/Tools instead of the
> main history page).

If you carefully look into individual messages over the span of a year
with limited time to examine each change -- you are likely going to
share my experience of finding individual commits are very
non-detailed.

Should we enforce each commit to be larger before publishing? Should
we enforce commit chains to end up in a merge commit which is
detailed? Should we enforce updating changelog-equivalent only when a
particular feature is finished and ready to be added -- but *enforce
it consistently*?

Again, I don't want to have to have to distinguish between "this is
adding a new class", "this is fixing a security bug", "this is
*partially* addressing a security bug", "this is a quick compile fix",
"this is a large overhaul of the build system" by having to inspect
each commit in a really long chain of commits. Not necessarily a tree,
even.

FWIW ChangeLog entries *when written* were more useful for this
purpose. The problem was *when they weren't written*.

It's not necessarily true that the ChangeLog format is useful, but we
either need something like it, or we need to hold ourselves to strict
high standards of how we write commit messages, or we need cover
letters / detailed merge commits, or each new commit *must* have a
*tracking* bug ("issue") entry that we can use to write release news.

Git commits as written today are unsustainable.

> In terms of generating the ChangeLog entries automatically: I used to do
> this when we used svn.  I had a little script that would take an svn log
> and write a ChangeLog entry.  I didn't write the script, and when I
> looked no one had written a version that worked with Git.  I take this
> to mean that there is very little perceived requirement for ChangeLog
> files.  Having a non-canonical copy of information that has a canonical
> home doesn't seem valuable.  If people want it, then they can do a git
> log > MyOwnChangeLog.

This is a nonsolution if git messages keep being to the tune of
"Actually fix the implementation" <-- which implementation? how? why?
what's getting fixed? what was broken in the first place?

ChangeLog, *when written*, have been less of a problem *during this
particular release timeframe*.

>
> >
> > 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
>
> The second of these is the difficult bit, but it's *incredibly*
> valuable.  For the runtime, I try to update the ANNOUNCE doc as I go,
> but I still end up having to skim the git logs to check if I missed
> anything.  LLVM and FreeBSD both end up with manual steps and chasing
> contributors to update these just prior to release (FreeBSD has a
> 'Release-Notes: Yes' thing you can put in the commit message so that the
> release engineer will look at it for things to put in release notes).
>
> > 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?
>
> +1.

Yes please. Let's do both. Let's write a note whenever you are halfway
or fully done with a new feature, whenever you fix a bug.

Enforce that commits, when merged, include this.

Whether you put it in news.texi, or write these notes in ChangeLog
(referencing exact files or not), or we keep release notes in a new
directory, with files named '-MM-DD-NN' that we flush as part of
the release process, I don't care much.

But maintainers, please just decide something and proclaim that this
is what will be done. It doesn't have to be consistent among packages,
but *within* a particular release of an individual package, I'd like
to see consistency. We can't have some people "opt-out" of the chosen
process. Maintainers need to be the ones to enforce this, including
possibly writing the log entries ('blogposts'?) themselves.

Re: Changelog and git log hygiene

[Ivan Vučica]

I can concur it can be senseless with 1:1 mapping between commits and the
logs.

However neither is that true, not have the git commit messages been kept up
to date, nor has there been an easily interpretable log of what changes
have been made.

I would propose changelog can be mutable (if you keep working on a change,
update it over time). Or we can keep a differently formed log of changes.
Git messages are inappropriate, in my opinion, because they are about
tracking individual chunks of changes ("tactics"), not the larger change
("strategy"). Think: "there should be a cover message for commits", as is
the case with mailing list based review and merge approach. Pull request
model is a possible way out, but requires everyone to consistently adopt
it; the message ends up in there as a merge commit, editable at the time of
the merge, which is nice.



But either there's more sensible logging of changes over time, or we do
away with announcing changes in a release that happens yearly. Because as
is, it's too much for a person to spend an afternoon being effectively a
journalist of code archaeology.

Is this a fix? Is this a security fix? Is this just a part of a security
fix? Or is this a new feature? Or is this a portion of a new feature? Has
this skeleton implementation been finished before this release -- how do we
announce the work done? "Implemented" or "stubbed out"?



Either everyone please agree to keep a journal in ChangeLog file, or
another change log; or consistently write about large chunks of code you
wrote (e.g. NSOrderedSet as one entry of 3 sentences rather than 30 commits
without anything related among them) so we can put them in release notes.

But whoever is cutting the next release (likely me, I'm ok doing it) should
not have to understand and sift through one sentence commits that describe
what was done, but neither why nor on what. Treat git commits as isolated,
or treat merge commits as a unit of work, or write some descriptive log, or
elect not to announce changes.

Those are the options.

sent from phone

On Mon, Apr 6, 2020, 14:37 Gregory Casamento 
wrote:

> I, honestly, believe that the ChangeLog should be phased out.  Either
> that, or the git log should be used to generate it.   I, need to update the
> ChangeLog as I have not added a LOT of my recent changes since they have
> been extensive.   I realize I am in the wrong here, but I can see the logic
> in David C's previous assertion that the ChangeLog should be done away
> with.   Just my thoughts.
>
> GC
>
> On Sun, Apr 5, 2020 at 11:51 AM Ivan Vučica  wrote:
>
>> Hello!
>>
>> For sake of making future releases easier, can we please:
>>
>> - keep ChangeLog up to date
>> - ensure ChangeLog content is in vague sync with commit messages (not
>> exact, as it would defeat the purpose, but at least approximate)
>> - make sure our commit messages are cleaner
>>
>>
>> Examples with minor edits for formatting follow. Note that this looks
>> to be a problem across the board with all committers, nobody in
>> particular:
>>
>> 
>> git commit message:
>> "Fix crash in gdomap when an invalid hostname is given for the -M option"
>> changelog message:
>> "* Tools/domap.c:
>> Fix crash in donames() when getaddrinfo returns an error"
>>
>> I find the first one much more useful for a newsfile; but the second
>> one is useful implementation detail. I would argue both should be in
>> both changelog and commit message. But this is still fine and
>> understandable.
>>
>> 
>> git commit messages:
>> "Fix wrong \U sequence for leter `i` and short weekdays."
>> "Update ChangeLog for last commit to Ukrainian language."
>> "Merge pull request #35 from trunkmaster/master: Updates for Ukrainian
>> language"
>> changelog message:
>> "* Resources/Lanuages/Ukrainian:
>> Fix wrong \U sequence for letter 'i' and short weekdays."
>>
>> Knowing in commit message that the change was done to the Ukrainian
>> language would be useful. Sure, I can pass --stat to git log -r
>> ${PREVRELEASE}..master --reverse, but a clearer message (especially
>> the first line, the one usually up to 70ch) would be better.
>>
>> Especially since --stat actually makes the whole log way harder to read.
>>
>> 
>> git commit message:
>> "Correct implementation of method."
>> "Correct method names."
>> changelog message:
>> nothing on April 9, but there is a more detailed message on April 12
>> -- presumably this is because this is a merged larger chain of
>> messages?
>>
>> This is generally fine if 

Re: Next GNUstep release

[Ivan Vučica]

I have cut new releases:
- gnustep-make 2.8.0
- gnustep-base 1.27.0
- gnustep-gui 0.28.0
- gnustep-back 0.28.0

They've been pushed to GitHub as commits and signed-tags, signed using
GPG key of yours truly. The signed tags, interpreted as releases by
GitHub, have been marked as 'prerelease', and tarballs + GPG
signatures made using the maintainer key have been attached to them.
  https://github.com/gnustep/tools-make/releases/make-2_8_0
   https://github.com/gnustep/libs-base/releases/base-1_27_0
   https://github.com/gnustep/libs-gui/releases/gui-0_28_0
   https://github.com/gnustep/libs-back/releases/back-0_28_0

As a temporary download URL, they're also available at
  https://badc0de.net/gs/2020/
for anyone who does not use GitHub.

Please, have a go at them, and let me know if there are any critical
issues. Please particularly review ANNOUNCE files as these will
customarily go out to info-...@gnu.org. ANNOUNCE files should be the
same ones that have been committed into our Git repositories.

Please validate .sig files in case I made a mistake; that would be
rather embarrassing.

If there are none, one of the evenings next week I will:

- upload tarballs to the default distribution point at ftp.gnustep.org
- flip the 'prerelease' bit on GitHub
- send ANNOUNCE emails to info-...@gnu.org and to discuss-gnus...@gnu.org

as was done for previous releases.

Thank you everyone for your work! While preparing these was a lot of
work, I am also impressed by the amount of changes all across the
board: tons of new classes, tons of work on Android; very very
impressive amount of changes.

Re: Changelog and git log hygiene

[Ivan Vučica]

gnustep-make tarball for 2.8.0 is timestamped 4:14pm on my machine.
Let's say 4:30pm is when I wrapped that up.

Last update to news.texi file on my machine is 6:03pm. This means I
spent 1h30 nonstop reading through changes that were made over the
last 15 months and updating the newsfile.

Let's please not end up in this state again.

- Please write descriptive commit messages that are useful standalone.
- If you are making large changes over the course of smaller commits
that you intend to merge:
  - make individual commits understandable without inspecting the patchfile
  - either squash them into one descriptive commit when merging, or
ensure merge commit describes exactly what happened
- Definitely update ChangeLog file. It's useful for releases.
- If you can, update Documentation/news.texi with semantic description
of what you've done.

Again: Please maintain the ChangeLog file. Don't drop things just
because "right now" you don't need them. Please make git commits
standalone useful. Please help with news.texi file. If a section for
next release doesn't exist, add it; we can fix the version more easily
than adding semantic description later.

I'll commit 1.27.0 shortly. When I do, note that 1.27.0's news.texi
*is* a mess because *too many changes happened*. There's no way I can
organize this into clear groupings without spending even more time on
this. I don't know what everyone did or why; it took 1h30 to
understand this.

As a counterpoint, I particularly found some Frederik Seiffert's
messages useful, especially in the ChangeLog. Dated 2019-05-23 and
2019-05-20, I could clearly understand *exactly* what happened.

I will include them to demonstrate:


2019-05-23  Frederik Seiffert 

* configure:
* configure.ac:
Link against libandroid on Android.
* Headers/Foundation/NSBundle.h:
* Source/NSBundle.m:
Added methods for passing Android asset manager from Java to GNUstep
and for getting AAsset/AAssetDir for given path in main bundle.
Skip app bundle suffix check on Android. Extended bundle resource
paths backbone to check for known paths directly on Android as we
can't enumerate directories.
Extended -localizations method to check for known localizations
directly (requires setting userLanguages in NSUserDefaults).
Extracted path cache cleaning into separate method.
* Source/GSFileHandle.h:
* Source/GSFileHandle.m:
Added file handle support for reading Android assets from main bundle.
* Source/NSData.m:
Added support for reading Android assets from main bundle in
readContentsOfFile(). This is also used by all other
-initWithContentsOfFile: and related methods from other classes.
* Source/NSFileManager.m:
Added support for Android assets from main bundle in
fileExistsAtPath:isDirectory:, isReadableFileAtPath:,
NSDirectoryEnumerator, and copying from assets. Extended
GSAttrDictionary with basic support for Android assets.
* Source/NSProcessInfo.m:
Added +initialize method to auto-initialize NSProcessInfo on Android
using fake executable path "/data/data//exe" (Android
apps don't have a real executable path).

2019-05-20  Frederik Seiffert 

* Source/NSLog.m: Have all logs go to syslog on android.
* Source/NSThread.m: Spinlock implementation using builtins as
implemented by David in libobjc2
* Source/NSRunLoop.m
* Headers/GNUstepBase/config.h.in:
* configure.ac:
This updates the libdispatch runloop integration to be compatible with
the Swift corelibs libdispatch release at
(https://github.com/apple/swift-corelibs-libdispatch).

In that release, the main queue handle and drain functions have been
renamed with a "_4CF" (for CoreFoundation) suffix and have moved to
private.h, so we now check for the existance of this header and
function names.

Note that libdispatch must be compiled with
INSTALL_PRIVATE_HEADERS=YES.

Also fixes the checks for the HAVE_LIBDISPATCH_RUNLOOP define (was
inverted) and ensures that both the handle and drain functions are
available.

Changelog and git log hygiene

[Ivan Vučica]

Hello!

For sake of making future releases easier, can we please:

- keep ChangeLog up to date
- ensure ChangeLog content is in vague sync with commit messages (not
exact, as it would defeat the purpose, but at least approximate)
- make sure our commit messages are cleaner


Examples with minor edits for formatting follow. Note that this looks
to be a problem across the board with all committers, nobody in
particular:


git commit message:
"Fix crash in gdomap when an invalid hostname is given for the -M option"
changelog message:
"* Tools/domap.c:
Fix crash in donames() when getaddrinfo returns an error"

I find the first one much more useful for a newsfile; but the second
one is useful implementation detail. I would argue both should be in
both changelog and commit message. But this is still fine and
understandable.


git commit messages:
"Fix wrong \U sequence for leter `i` and short weekdays."
"Update ChangeLog for last commit to Ukrainian language."
"Merge pull request #35 from trunkmaster/master: Updates for Ukrainian language"
changelog message:
"* Resources/Lanuages/Ukrainian:
Fix wrong \U sequence for letter 'i' and short weekdays."

Knowing in commit message that the change was done to the Ukrainian
language would be useful. Sure, I can pass --stat to git log -r
${PREVRELEASE}..master --reverse, but a clearer message (especially
the first line, the one usually up to 70ch) would be better.

Especially since --stat actually makes the whole log way harder to read.


git commit message:
"Correct implementation of method."
"Correct method names."
changelog message:
nothing on April 9, but there is a more detailed message on April 12
-- presumably this is because this is a merged larger chain of
messages?

This is generally fine if I could be sure ChangeLog is reliable and
consistently up to date. I'm reviewing logs as I am actually not sure
this is the case. Then, a message that says "fixed method" and nothing
else isn't helpful. File changed is Source/NSString.m, so I suspect
the longer message about character sets actually applies, but still...



Clearly I can and will be happy to release as-is and I will try to
keep release notes useful to anyone that may want to peek at them.
However, continued vigilance *when* making a commit -- it means not
only people stay up to date *at the time of making a commit*, but also
helps whomever happens to be cutting the release 15 months later.

Please, write the commit messages as if people view the commits
standalone. Please, write them as if someone is reading through them
without context over a year later.


Am I myself writing commit messages and changelog entries right? No
idea; I can only share with you the experience while cutting a
release. For entertainment purposes, take 1-2min and try to consider
how you'd write release notes from the output of this:

PREVRELEASE=$(git describe --abbrev=0) # should be: base-1_26_0
git log -r ${PREVRELEASE}..master --reverse
git diff -r ${PREVRELEASE}..master ChangeLog

:-)

Re: Next GNUstep release

[Ivan Vučica]

Sounds good. I will cut Make too. I’m going to start now.

> On 4 Apr 2020, at 15:27, Riccardo Mottola  wrote:
> 
> Hi,
> 
> Richard Frith-Macdonald wrote:
>>> 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.
>> 
>> 
> 
> I would release "base" as it is in master though, not mergein any
> branches.. I have decently tested it on a couple of platforms with gcc.
> 
> Riccardo

Re: Next GNUstep release

[Ivan Vučica]

I'll proceed tomorrow then with releasing whatever is in the master branch.

I'll review if Documentation/news.texi (IIRC the source for other news
files) has been updated and if version has been bumped.


sent from phone

On Sat, Apr 4, 2020, 11:21 Richard Frith-Macdonald <
rich...@frithmacdonald.me.uk> wrote:

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

[Ivan Vučica]

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. From: Gregory CasamentoSent: Thursday 2 April 2020 19:28To: Ivan VučicaCc: Niels Grewe; Developer GNUstepSubject: Re: Next GNUstep release I have a pending change to NSURLComponents in NSURL.m, fred is reviewing.  Once that is done I think we should be good to go.  I leave it up to you whether you believe it too risky to include.  Once you have done your release of make, base, gui and back I will release gorm. Yours, GC Sender notified by Mailtrack 04/02/20, 02:26:27 PM  On Thu, Apr 2, 2020 at 11:49 AM Ivan Vučica <i...@vucica.net> wrote:On Thu, Apr 2, 2020 at 4:46 PM Ivan Vučica <i...@vucica.net> wrote:> I'll cut make, base, gui, back. I'm aiming to do it Sunday.Also: I'll try to be present in #gnustep on Freenode. If you suspect Imight need help or just want to chat, please join me.Also: I'll validate that versions have been bumped. I expect we've hadbinary incompatibility changes, but despite Yavor's information, Inever set up the tools to validate this. -- Gregory CasamentoGNUstep Lead Developer / OLC, Principal Consultanthttp://www.gnustep.org - http://heronsperch.blogspot.comhttps://www.patreon.com/bePatron?u=352392 - Become a Patron 

Re: Next GNUstep release

[Ivan Vučica]

On Thu, Apr 2, 2020 at 4:46 PM Ivan Vučica  wrote:
> I'll cut make, base, gui, back. I'm aiming to do it Sunday.

Also: I'll try to be present in #gnustep on Freenode. If you suspect I
might need help or just want to chat, please join me.

Also: I'll validate that versions have been bumped. I expect we've had
binary incompatibility changes, but despite Yavor's information, I
never set up the tools to validate this.

Re: Next GNUstep release

[Ivan Vučica]

Just noting that I've seen this email and I'll try to tackle the
release this weekend.

I'll of course validate what I'm releasing, and update -base if it's
not done by then.

I'll cut make, base, gui, back. I'm aiming to do it Sunday.

On Sun, Mar 29, 2020 at 9:01 PM Niels Grewe  wrote:
>
> On 28.03.20 09:59, Niels Grewe wrote:
> > Hi Fred,
> >
> > On 27.03.20 20:31, Fred Kiefer wrote:
> >> Hi Ivan,
> >>
> >> is it OK to go ahead with the release as planed?
> >> I just provide short descriptions of the changes in gui and back in the
> >> news-texi files. Everybody that contributed in the last year should have
> >> a short look to see whether I missed something or improve the description.
> >> @Richard could you do the same for base? Or if you don't have the time I
> >> might do that as well, just tell me.
> >> @Niels could you handle "make"?
> >
> > Of course! I also have a bit of documentation to update for the runtime
> > ABI related changes, but I'll surely find time to do it this weekend.
>
> I've tied up a few loose ends and prepared the NEWS file for -make, so
> the masters of the GPG keys may work their magic whenever they like.
>
> Cheers,
>
> Niels
>

Re: Building GNUstep for Windows using Clang

[Ivan Vučica]

On Sat, Mar 7, 2020 at 6:50 PM Johannes Brakensiek
 wrote:
> Everyone clicking on that link accidentally is tracked by Google even if
> he/she did not consent with it. For me that does not fit well to a
> project reaching out for software freedom. No offense, just what I
> thought.

[still OT:] Where does it say that The Mail Track Company, S.L. is
owned by Google?

Re: Next GNUstep release

[Ivan Vučica]

On Tue, Feb 11, 2020 at 8:09 AM Fred Kiefer  wrote:
> And most importantly, Ivan will you have time to cut all these releases? Of 
> course we could move that point around a week or two if that date fits better

I've only now seen this.

This is ok and please coordinate with me closer to the release date.
It's nearly zero effort for me if maintainers keep up to date
Documentation/news.texi and other files you can see me updating by
hand just before release. Most time-consuming is a) sorting out
through 'what changed' and revising news.texi et al, b) getting the
GPG signing key to work, c) coordinating what version we should have
actually bumped to because we might break Debian automated checks etc.

I'm ok doing all these, but more I have to do, more planning do I have
to put into dedicating huge blocks of time to a release.

(Note, having package maintainers and distro packaging maintainers
online -- preferably in a realtime groupchat e.g. on IRC -- when
cutting a release would not be a bad thing. This means we can sort out
and test any issues within hours rather than days.)

On Thu, Feb 27, 2020 at 9:10 PM Riccardo Mottola
 wrote:
> before a release, I would like these issues to find a solution.
>
> - understand why we don't work properly on my ThinkPad T23 neither with
> the Cairo nor with the xlib backend with similar issues

Did you date when things broke and at what change?

I'm afraid that when I'm cutting a release I only use a single
platform (Ubuntu or Debian amd64 with libobjc2 and clang) with usually
one or two backend configs (usually cairo). Sometimes I build with GCC
or with GCC runtime. I don't have other environments around, including
a working environment on Windows.

I don't know what should be release blockers, I'm leaving that to
individual package maintainers.

> - understand/fix/workaround the libobjc2 which impede me to test current
> GNUstep on any FreeBSD 11.x and 12.x I currently have on i386 and amd64

Honestly, I would have expected that libobjc2 FreeBSD should work out
of the box given David is/was working on FreeBSD...

RE: GORM usability enhancements

[Ivan Vučica]

Speaking of outline views, I haven’t used Gorm in a while; is there now an 
outline view of all objects in the nib? That’s what I was missing last time I 
was building things in Gorm. 

From: Gregory Casamento
Sent: Monday 23 December 2019 21:49
To: Sergii Stoian
Cc: GNUstep Developers
Subject: Re: GORM usability enhancements

I don't want to tie people to the outline view.   I already explained the 
rationale of why in the last post.  Classes should be treated like everything 
else and be editable by inspectors.  I, personally, think the Outline view in 
Gorm should be done away with as it would eliminate this confusion.


On Fri, Dec 20, 2019 at 12:09 PM Sergii Stoian  wrote:
I think it's quite confusing to do the same things with different tools in one 
application. Probably some tool will be used more often than other. This is a 
matter of application usability and learning curve.
Could you explain to the evarage user of GORM: what are cases for Class Editor 
and Class Editor Inspector usage and why?
Anyway, it's up to you, Gregory. Thanks.

On Fri, Dec 20, 2019 at 6:46 PM Gregory Casamento  
wrote:
I will not approve #3.  The user should have multiple ways of editing the 
class.  The outline editor should not be the only way.  It is consistent to 
treat a class the same way we do objects via an inspector. 

On Fri, Dec 20, 2019, 11:08 AM Gregory Casamento  
wrote:
Please create a branch to be merged via a pull request.  

On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian  wrote:
Hi, everybody.

I use GORM application a lot. I think it's most comprehensive GNUstep 
application.
After a while I've noticed roughness in a various places across application. 
So, finally, I've decided to spend some time and polish GORM from usability 
point of view. Basically most of the changes will be done at model files, but I 
suppose code will be touched also later.

My plan is the following:
1. Enhancements in model files (conrtols positionning, autosizing, fonts, menu 
items rearrangements).
2. Sort out focus change between controls and windows (I've noticed some 
inconviences).
3. Document window changes: fix selection of objects, make object titles 
editable (get rid of "Set Name" panel), finish and make usable Class Editor 
outline editor (get rid of Class Editor Inspector).

I see several options to do this with Git:
1. Push changes into master branch without pull requests. It seems good for 
model files (1)
2. Create separate branch or fork and merge changes into master after I finish.

My questions to community: what option do you think I should go with?

-- 
Sergii Stoian


-- 
Sergii Stoian, 
ProjectCenter lead developer
NEXTSPACE owner, lead developer



-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: [ML] Re: Hosting of gnustep.org

[Ivan Vučica]

On Wed, Dec 18, 2019 at 1:17 PM Manuel Guesdon  wrote:
>
> - make a CNAME www.gnustep.org => gnustep.github.io (but server hosting
>gnustep.github.io should accept requests for www.gnustep.org)

This merely requires creating a file named 'CNAME' in the github repo
for gnustep.github.io (i.e.
https://github.com/gnustep/gnustep.github.io).

See 
https://help.github.com/en/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site

> I can't make a CNAME gnustep.org => gnustep.github.io (due to the way DNS
> works) but I can make a 301 redirect http://gnustep.org
> => http://www.gnustep.org

Looks like Github documents the exact IPs that can be used:
  
https://help.github.com/en/github/working-with-github-pages/managing-a-custom-domain-for-your-github-pages-site#configuring-an-apex-domain

Then again, 301 + CNAME for www are probably more maintainable.

Re: Occasional NSInternalInconsistencyException

[Ivan Vučica]

Would the bug here, then, be that alerts don't check for this edge case?

Patryk: I'd merge a pull request that makes -[NSAlert runModal] check
for an active runloop.

On Tue, Nov 19, 2019 at 5:49 PM Gregory Casamento
 wrote:
>
> Running modal panels requires the application run loop to be active.
> You're not doing that.   I suggest you take a look at some of the application 
> examples for how to do what you want here.
>
> On Tue, Nov 19, 2019, 10:34 AM Patryk Laurent  wrote:
>>
>>
>> > On Nov 18, 2019, at 09:16, Wolfgang Lux  wrote:
>> >
>> >> Am 18.11.2019 um 04:43 schrieb Patryk Laurent :
>> >> “Uncaught exception NSInternalInconsistencyException, reason: 
>> >> registration with registered client.”
>> >
>> > The error message itself is coming from NSDistributedNotificationCenter 
>> > and it looks like it's caused by a race condition when two threads in your 
>> > program are adding an observer to the distribution notification center at 
>> > about the same time.
>>
>> Thanks, Wolfgang. I find this surprising because my program is minimal 
>> (source code below). I wasn’t getting this before, will look for what has 
>> changed...
>>
>> Patryk
>>
>> #import 
>>
>> int main()
>> {
>>   NSApplication *app;
>>   app = [NSApplication sharedApplication];
>>
>>   NSAlert * alert = [[NSAlert alloc] init];
>>   [alert setMessageText:@"Hello alert"];
>>   [alert addButtonWithTitle:@"All done"];
>>   int result = [alert runModal];
>>   if (result == NSAlertFirstButtonReturn) {
>> NSLog(@"First button pressed");
>>   }
>> }
>>
>>
>>
>>
>>
>>

Re: Gitflow proposal

[Ivan Vučica]

I might be incorrectly following the discussion.

Reviews with the exception for quick fixes — yes.

Someone drew a graph of stable, which is forked into dev branch, which is
forked into individual feature branches. FWIW I personally like the PR
model, and pulling incoming PRs into master; if there is a need for stable
branches, I’d keep separate stable branches. Or not even branches: take the
tag for previous release (let’s say 2.45.0), cherrypick the fix, tag the
new release (2.45.1).

Master is, to me, the “unstable” beast. Stable branches are just that. To
my memory we haven’t really had a need for stable branches, but...

On Fri 15 Nov 2019 at 09:40, Gregory Casamento 
wrote:

>
> Matt,
>
> On Fri, Nov 15, 2019 at 9:08 AM Matt Rice  wrote:
>
>> I think Fred hits the major points quite well,
>>
>
> I agree.
>
>
>> in all the GNU projects i've ever worked on besides GNUstep even
>> maintainers post patches for review for the benefit of other
>> maintainers.
>
>
> Of course.
>
> Certain things are disqualified from this, such as
>> fixing typos, unbreaking master either by reverting or fixing the
>> commit... Things which could be justified as being obvious changes.
>>
>
> Yes, quick fixes are okay to go right to master.
>
> Generally when patches are posted, and do not receive review a
>> maintainer (usually the author but i don't feel like ruling it out),
>> can give a heads up that they intend to commit the patch in the near
>> future within some reasonable timeframe...
>
>
> Ok
>
>>  This adds a bit of delay to the whole process however not entirely
>
> unbounded nor too rigid,
>> but gives others their say.  Personally i would say the lack of any
>> review process was a major factor in my decision to stop
>> contributing...
>>
>>
> Understandable.
>
>
>
>> On Fri, Nov 15, 2019 at 8:16 AM 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.
>> >
>> > Fred
>> >
>> > > Am 15.11.2019 um 05:30 schrieb Gregory Casamento <
>> greg.casame...@gmail.com>:
>> > >
>> > > Guys,
>> > >
>> > > I must say this.  I have been trying to, in general, hold myself to
>> doing this rather formally up until recently.  I admit that I have been
>> more directly pushing things in as of late.
>> > >
>> > > Since, as you say, this could have been avoided by doing PRs... which
>> it could have.  Should we not, as an project, move to this model?  It's
>> known as gitflow and it's what I was following when I would create a branch
>> with large changes and then have it reviewed by yourself and others before
>> merging.   This would slow some development down, but it would have the
>> effect of keeping master in a condition where it always builds and is
>> always releasable (which should always be the case).
>> > >
>> > > Here is a link, for reference:
>> 

Re: Gitflow proposal

[Ivan Vučica]

Oh, also, in GNUstep’s case, honestly, I’m not too keen on making reviews
mandatory even in general case — just a strongly encouraged practice.

On Fri 15 Nov 2019 at 09:45, Ivan Vučica  wrote:

> I might be incorrectly following the discussion.
>
> Reviews with the exception for quick fixes — yes.
>
> Someone drew a graph of stable, which is forked into dev branch, which is
> forked into individual feature branches. FWIW I personally like the PR
> model, and pulling incoming PRs into master; if there is a need for stable
> branches, I’d keep separate stable branches. Or not even branches: take the
> tag for previous release (let’s say 2.45.0), cherrypick the fix, tag the
> new release (2.45.1).
>
> Master is, to me, the “unstable” beast. Stable branches are just that. To
> my memory we haven’t really had a need for stable branches, but...
>
> On Fri 15 Nov 2019 at 09:40, Gregory Casamento 
> wrote:
>
>>
>> Matt,
>>
>> On Fri, Nov 15, 2019 at 9:08 AM Matt Rice  wrote:
>>
>>> I think Fred hits the major points quite well,
>>>
>>
>> I agree.
>>
>>
>>> in all the GNU projects i've ever worked on besides GNUstep even
>>> maintainers post patches for review for the benefit of other
>>> maintainers.
>>
>>
>> Of course.
>>
>> Certain things are disqualified from this, such as
>>> fixing typos, unbreaking master either by reverting or fixing the
>>> commit... Things which could be justified as being obvious changes.
>>>
>>
>> Yes, quick fixes are okay to go right to master.
>>
>> Generally when patches are posted, and do not receive review a
>>> maintainer (usually the author but i don't feel like ruling it out),
>>> can give a heads up that they intend to commit the patch in the near
>>> future within some reasonable timeframe...
>>
>>
>> Ok
>>
>>>  This adds a bit of delay to the whole process however not entirely
>>
>> unbounded nor too rigid,
>>> but gives others their say.  Personally i would say the lack of any
>>> review process was a major factor in my decision to stop
>>> contributing...
>>>
>>>
>> Understandable.
>>
>>
>>
>>> On Fri, Nov 15, 2019 at 8:16 AM 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 b

Re: Embedded blocks...

[Ivan Vučica]

Naive question: What’s the problem #ifdefing out the code that depends on
blocks when building on gcc?

On Tue 29 Oct 2019 at 12:51, David Chisnall 
wrote:

> On 27/10/2019 16:05, Gregory Casamento wrote:
> > We are a GNU / FSF project.  Dropping support for GCC would be bad
> > political mojo.   There is little we can do to bridge the gap other than
> > doing these macros.
>
> I don't really understand how this works.  GCC does not support a
> post-2005 dialect of Objective-C.  GNUstep is a framework that aims to
> provide an implementation of the 2019 Objective-C standard library.  Why
> is it politically problematic for GNUstep to drop support for GCC, but
> not problematic for GCC to drop support for GNUstep?
>
> For what it's worth, I've spoken to a couple of GCC devs over the last
> few years about supporting modern Objective-C (because I would like us
> to have a choice of compilers), but the effort involved for them is huge
> (even a naive ARC implementation is a big piece of effort) and the
> return is small (why would anyone use it?  Basically, the only target
> market is GNUstep developers on platforms that Clang doesn't support,
> which I think is a set containing only Riccardo).  There is some
> interest in supporting blocks, because Apple's libc headers no longer
> support compilers that don't support blocks, but even then I haven't
> seen much progress from GCC.
>
> David
>
> --
Sent from Gmail Mobile

Are releases needed?

[Ivan Vučica]

I'm not sure when I'll have time to do anything immediately, but if
maintainers estimate there's been enough work done to warrant
releases, and my assistance is requested this year, please let me
know. Something should be doable during a weekend.

If you'd like me to do a release, please bring it to a releasable
state and let me know.

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

NSUbiquitousKeyValueStore

[Ivan Vučica]

I saw some activity on NSUbiquitousKeyValueStore.

Is there intention to use one or more cloud-y APIs to do sync of ubiquitous 
preferences?

> On 14 Jul 2019, at 13:52, Fred Kiefer  wrote:
> 
>  Branch: refs/heads/master
>  Home:   https://github.com/gnustep/libs-base
>  Commit: be809143cfa401c3fca5f73eabfb448cecce361f
>  
> https://github.com/gnustep/libs-base/commit/be809143cfa401c3fca5f73eabfb448cecce361f
>  Author: fredkiefer 
>  Date:   2019-07-14 (Sun, 14 Jul 2019)
> 
>  Changed paths:
>M ChangeLog
>M Source/NSUbiquitousKeyValueStore.m
> 
>  Log Message:
>  ---
>  * Source/NSUbiquitousKeyValueStore.m: Change to use GNUstep
> formatting. Move simple methods into base class. Correct the usage
> of long long NSNumber.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "gnustep-commits" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to gnustep-commits+unsubscr...@googlegroups.com.
> To post to this group, send email to gnustep-comm...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/gnustep-commits/gnustep/libs-base/push/refs/heads/master/c44e2b-be8091%40github.com.
> For more options, visit https://groups.google.com/d/optout.


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

Re: Escape from the UK/Brexit ... update

[Ivan Vučica]

Here's a warm welcome.

I've been to Kilkenny once, I think. Lovely place.

On Sat, Mar 30, 2019, 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
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Commit process to source tree on github

[Ivan Vučica]

I usually create a fork if I need a PR.

By the way, maybe I misunderstood; if you do have push access already and
you think something is really, really trivial, go ahead and push small
changes. :-)

On Sun, Mar 24, 2019, 01:18 Sergii Stoian  wrote:

> Hi Ivan,
>
> On Sun, Mar 24, 2019 at 2:34 AM Ivan Vučica  wrote:
>
>> From experience outside GNUstep: I don't think it's necessarily a bad
>> practice to do code review on every commit going in (including
>> trivial), even among core devs. It's perhaps a shame we're not
>> enforcing code review for /every/ submission.
>>
>> Anyway, I think each of the improvements sounds good -- I think it's
>> very good to upstream your changes, so thank you for doing this. They
>> do sound like something where it might be a good idea for a second eye
>> to take a quick look? (I know I wouldn't mind having someone take a
>> look at my changes, when I make them, as even trivial ones could break
>> things.)
>>
> I understand your concerns absolutely. Everybody make a mistakes. :)
> Although there are some corner cases were I'll take a courage to commit
> directly.
> For example, Ukrainian translation file. Is it OK?
>
>>
>> How about we try with PRs for these (incl for trivial changes) and
>> then look at flipping the permissions switch for you?
>>
> It's good if it's make GNUstep code quality better.
> I'm a GNUstep developer since 2001, if I recall correctly (including paper
> signing from FSF).
> Moreover, I'm a perfectionist for quality in code and feel of a UI/UX.
> I don't know if somebody else here is everyday user of GNUstep codebase as
> me (I use NEXTSPACE as production environment for a several months).
> If something goes wrong I'll see it immediately. :)
>
> Anyway, I'll agree with you and will start creating PRs.
> Do I need to create branch or fork? What would your recommend?
>
>>
>> Once again, thank you for offering these patches!
>>
>> On Sat, Mar 23, 2019 at 9:52 PM Sergii Stoian 
>> wrote:
>> >
>> > Hi Fred,
>> >
>> > Thank you. As I've replied to David, I tend to push trivial patches
>> directly to HEAD. More complex I'll create as a pull request so we can
>> discuss details before merge.
>> >
>> > Answering your last question: I have a set of tested changes to older
>> GNUstep release (you may find them here
>> https://github.com/trunkmaster/nextspace/tree/master/Libraries/gnustep).
>> > I want to include these changes into current release of GNUstep. The
>> main areas are:
>> > - focus management and window manager interaction (hide application,
>> minimize window), mouse click on titlebar, appicon, inside window;
>> > - mouse properties: configurable double-click time, line scroll
>> multiplier, left/right menu button (some details:
>> https://github.com/trunkmaster/nextspace/issues/8);
>> > - applications "-autolaunch" behaviour: do not show menus and do not
>> steal focus;
>> > - mouse cursors: I've created a cursor theme which is fully compatible
>> to Awaita (standard `de facto` I guess). You may find my thoughs here:
>> https://github.com/trunkmaster/nextspace/wiki/Mouse-Cursors;
>> >
>> > Also I have several trivial patches:
>> > - prevent blinking of appicon on focus switch/appicon double-click.
>> It's quite noticable with cairo backend;
>> > - Font panel weird look and feel on WM (no resize bar, items must be
>> clicked higher then it drawn)
>> > - use title image in miniwindow
>> > - etc.
>> >
>> > In long-term I want to adopt cairo backend as default for NEXTSPACE. I
>> want to move some functionality from ART backend.
>> > For example, I'd like to have an option and support of font packages
>> (.nfont).
>> > I want to polish UI: some elements draw lines as gray instead of black
>> (I know about half-pixel problem).
>> > I'd like to test and enhance NSBrowser behavior. I want to implement
>> display resolution changes adoption at backend level. May high DPI some
>> day...
>> >
>> > On Sat, Mar 23, 2019 at 12:05 PM Fred Kiefer  wrote:
>> >>
>> >> Hi Sergii,
>> >>
>> >> having a pull request to review and approve is always the nicer way to
>> work with patches. But if this is too much hassle for you feel free to do a
>> direct commit or even to send a patch file to the mailing list. Which area
>> are you planing to work on?
>> >>
>> >> Cheers,
>> >> Fred
>> >>
>> >> On the road
>> >>
>> >

Re: Commit process to source tree on github

[Ivan Vučica]

>From experience outside GNUstep: I don't think it's necessarily a bad
practice to do code review on every commit going in (including
trivial), even among core devs. It's perhaps a shame we're not
enforcing code review for /every/ submission.

Anyway, I think each of the improvements sounds good -- I think it's
very good to upstream your changes, so thank you for doing this. They
do sound like something where it might be a good idea for a second eye
to take a quick look? (I know I wouldn't mind having someone take a
look at my changes, when I make them, as even trivial ones could break
things.)

How about we try with PRs for these (incl for trivial changes) and
then look at flipping the permissions switch for you?

Once again, thank you for offering these patches!

On Sat, Mar 23, 2019 at 9:52 PM Sergii Stoian  wrote:
>
> Hi Fred,
>
> Thank you. As I've replied to David, I tend to push trivial patches directly 
> to HEAD. More complex I'll create as a pull request so we can discuss details 
> before merge.
>
> Answering your last question: I have a set of tested changes to older GNUstep 
> release (you may find them here 
> https://github.com/trunkmaster/nextspace/tree/master/Libraries/gnustep).
> I want to include these changes into current release of GNUstep. The main 
> areas are:
> - focus management and window manager interaction (hide application, minimize 
> window), mouse click on titlebar, appicon, inside window;
> - mouse properties: configurable double-click time, line scroll multiplier, 
> left/right menu button (some details: 
> https://github.com/trunkmaster/nextspace/issues/8);
> - applications "-autolaunch" behaviour: do not show menus and do not steal 
> focus;
> - mouse cursors: I've created a cursor theme which is fully compatible to 
> Awaita (standard `de facto` I guess). You may find my thoughs here: 
> https://github.com/trunkmaster/nextspace/wiki/Mouse-Cursors;
>
> Also I have several trivial patches:
> - prevent blinking of appicon on focus switch/appicon double-click. It's 
> quite noticable with cairo backend;
> - Font panel weird look and feel on WM (no resize bar, items must be clicked 
> higher then it drawn)
> - use title image in miniwindow
> - etc.
>
> In long-term I want to adopt cairo backend as default for NEXTSPACE. I want 
> to move some functionality from ART backend.
> For example, I'd like to have an option and support of font packages (.nfont).
> I want to polish UI: some elements draw lines as gray instead of black (I 
> know about half-pixel problem).
> I'd like to test and enhance NSBrowser behavior. I want to implement display 
> resolution changes adoption at backend level. May high DPI some day...
>
> On Sat, Mar 23, 2019 at 12:05 PM Fred Kiefer  wrote:
>>
>> Hi Sergii,
>>
>> having a pull request to review and approve is always the nicer way to work 
>> with patches. But if this is too much hassle for you feel free to do a 
>> direct commit or even to send a patch file to the mailing list. Which area 
>> are you planing to work on?
>>
>> Cheers,
>> Fred
>>
>> On the road
>>
>> Am 23.03.2019 um 01:42 schrieb Sergii Stoian :
>>
>> Hello everybody,
>>
>> I plan to commit some changes/fixes to GUI and Back.
>> My last GNUstep commit was long time ago to SVN at gna.org. I'm familiar 
>> with git and github.
>>
>> My question is: what is the correct way to submit patches/fixes?
>> Should it be a pull request for approval?
>> May I commit directly to the source tree on github?
>>
>> --
>> Sergii Stoian,
>> ProjectCenter lead developer
>> NEXTSPACE owner, lead developer
>>
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
>
> --
> Sergii Stoian,
> ProjectCenter lead developer
> NEXTSPACE owner, lead developer
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

Re: Building on android....

[Ivan Vučica]

Did you try to analyze what my projects which I shared with you are doing
to produce an APK?

On Fri 15 Feb 2019 at 21:57, Gregory Casamento 
wrote:

> Any possibility that you might be willing to share the cmake files and
> config options you used?   One direction I would like to take the project
> in is to Be able to compile on android and potentially have a uikit
> implementation on top of android.
>
> On Fri, Feb 15, 2019 at 15:24 Jordan Schidlowsky 
> wrote:
>
>> Sorry, ya I'm just seeing that script now, we didn't use that.  Just
>> looked at configuration options for tools-make and gnustep-base...  Then
>> fixed everything that didn't configure properly for cross-compilation and
>> re-wrote a CMakelists.txt for base and have been using that since...
>> Having the whole build (from runtime to base) in cmake makes it much easie
>> to write, run, and debug everything inside android studio (even though the
>> IDE editor doesn't support obj-c syntax).
>>
>>
>> On Feb 15, 2019, at 2:02 PM, Gregory Casamento 
>> wrote:
>>
>> The one we were discussing in this thread.  How are you configuring your
>> app on android?
>>
>> On Fri, Feb 15, 2019 at 14:55 Jordan Schidlowsky 
>> wrote:
>>
>>> Sorry, i'm not sure which script you're referring to!
>>>
>>> On Feb 15, 2019, at 1:44 PM, Gregory Casamento 
>>> wrote:
>>>
>>> Are you talking about how the script configures things?
>>>
>>> On Fri, Feb 15, 2019 at 12:08 Jordan Schidlowsky 
>>> wrote:
>>>
>>>> We will be shipping a large game in a couple weeks on android that is
>>>> built on gnustep.   We've been testing very extensively over the past 3-4
>>>> months and things look quite stable (at least on armv7-a).  The game
>>>> heavily uses ARC, blocks, libdispatch  Lemme just say the configuration
>>>> of gnustep-base, build, and project setup, were not ideal.
>>>>
>>>> On Feb 15, 2019, at 11:04 AM, Gregory Casamento <
>>>> greg.casame...@gmail.com> wrote:
>>>>
>>>> The challenge at this point is to get a working app.
>>>>
>>>> On Wed, Feb 13, 2019 at 14:47 Gregory Casamento <
>>>> greg.casame...@gmail.com> wrote:
>>>>
>>>>> Ivan pointed out that I was using the wrong ninja script.  This solved
>>>>> my problem.   I am now working on getting base to build properly.
>>>>>
>>>>> GC
>>>>>
>>>>> On Wed, Feb 13, 2019 at 12:21 PM Ivan Vučica  wrote:
>>>>>
>>>>>> FTR thank you for that, and for spotting -androideabi16!
>>>>>>
>>>>>> On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky <
>>>>>> jor...@noodlecake.com> wrote:
>>>>>>
>>>>>>> Agreed, just sharing whats working for us via gradle config.
>>>>>>>
>>>>>>> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
>>>>>>>
>>>>>>> Aye; but we should not depend on using Gradle as the end state.
>>>>>>>
>>>>>>> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky <
>>>>>>> jor...@noodlecake.com> wrote:
>>>>>>>
>>>>>>>> Ya you're right,  It should be picked up.  For what it's worth,
>>>>>>>> here's our gradle config, (which ends up passing the correct flags to 
>>>>>>>> cmake
>>>>>>>> for building gnustep):
>>>>>>>>
>>>>>>>> defaultConfig {
>>>>>>>> applicationId "com.noodlecake.ssg4"
>>>>>>>> minSdkVersion 21
>>>>>>>> targetSdkVersion 28
>>>>>>>> versionCode 28
>>>>>>>> versionName "1.0.0"
>>>>>>>> testInstrumentationRunner 
>>>>>>>> "android.support.test.runner.AndroidJUnitRunner"
>>>>>>>> externalNativeBuild {
>>>>>>>> cmake {
>>>>>>>> cppFlags "-std=c++14 -frtti -fexceptions 
>>>>>>>> -fconstant-string-class=NSConstantString"
>>>>>>>> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
>>>>>>>> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
>>>

Re: Building on android....

[Ivan Vučica]

There are two build.ninja files. One is in
$cmakes_magical_build_root/build.ninja, and the other in
$cmakes_magical_build_root/CMake/build.ninja.

The one in CMake subfolder should not be used.

On Wed, Feb 13, 2019 at 5:03 PM Ivan Vučica  wrote:

> Reading through the toolchain file
> <https://android.googlesource.com/platform/ndk/+/master/build/cmake/android.toolchain.cmake>,
> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
> should not be the issue.
>
> I'd start by pepper-spraying message() calls in toolchain .cmake file, and
> in other .cmake files as necessary, too.
>
> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky 
> wrote:
>
>> Ah, i didn't see that shell script...  I think
>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>
>>
>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>>
>> Actually -- it doesn't explain why this is happening, as the shell script
>> (which I failed to notice Gregory attached) matches what I sent him. It's
>> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
>> ...-androideabi23.
>>
>> Strange.
>>
>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>>
>>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>>
>>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
>>>> I think this line in his output indicates he's building for API 16:
>>>>
>>>>  --target=armv7-none-linux-androideabi16
>>>>
>>>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>>>
>>>> Since Greg mentioned me:
>>>>
>>>> Instructions/commands I came up with and that I sent over to Gregory
>>>> should attempt using API level 23. Totally arbitrarily picked. Use of
>>>> pre-21 API is not happening so not an issue.
>>>>
>>>> Needless to say, building works for me. I don’t have a self-contained
>>>> script to share, but it’s super simplistic and what Greg described (incl
>>>> using GUI to install NDK) is what I did.
>>>>
>>>> I’m only sure it builds, not that it works, as I am yet to try running
>>>> the code; I don’t have a build script ready for producing an APK (the old
>>>> approach from 2013 and 2014 is a mess and needs to be reworked).
>>>>
>>>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
>>>> wrote:
>>>>
>>>>> I've got some patches but they are pretty ugly and I want to clean
>>>>> them up properly before submitting...
>>>>>
>>>>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
>>>>> wrote:
>>>>>
>>>>> An NDK app can chose to bundle in a (c++_shared) library in your app,
>>>>> or you can link with a static (c++_static) standard library.   This is
>>>>> actually dependant on what setting you chose for this in your gradle build
>>>>> file, as gradle will pass that along to cmake which will link it in.
>>>>>
>>>>> That cxx runtime test doesn't quite work correctly using an android
>>>>> toolchain.  But if you want to configure your ndk app using c++_static you
>>>>> can remove that test section from CMakeLists.txt and add in manually 
>>>>> below:
>>>>>
>>>>> set(CXXRT_IS_STDLIB true)
>>>>> target_link_libraries(objc c++_static stdc++)
>>>>>
>>>>> I will also note, that I am still thinking about a way to run that
>>>>> test suite while cross compiling...
>>>>>
>>>>>
>>>>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento <
>>>>> greg.casame...@gmail.com> wrote:
>>>>>
>>>>> A little more context...  my build environment is a MacPro 2010
>>>>> running the latest version of Mojave.  I have downloaded and installed the
>>>>> latest of Android studio and installed the latest SDK and NDK using the
>>>>> menu under tools and the SDK manager.  The version of the NDK I'm using 
>>>>> is 19.0.5232133.
>>>>>  I am utterly stumped as to why this is not working.  Also, it seems as
>>>>> though Ivan's installation of this is working which seems to indicate that
>>>>> this is a configuration issue.
>>>>>
>>>>> Any input would be appreciated.
>>>>>
>>>>> On Wed, Feb 13, 2019 a

Re: Building on android....

[Ivan Vučica]

FTR thank you for that, and for spotting -androideabi16!

On Wed, Feb 13, 2019 at 5:20 PM Jordan Schidlowsky 
wrote:

> Agreed, just sharing whats working for us via gradle config.
>
> On Feb 13, 2019, at 11:17 AM, Ivan Vučica  wrote:
>
> Aye; but we should not depend on using Gradle as the end state.
>
> On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky 
> wrote:
>
>> Ya you're right,  It should be picked up.  For what it's worth, here's
>> our gradle config, (which ends up passing the correct flags to cmake for
>> building gnustep):
>>
>> defaultConfig {
>> applicationId "com.noodlecake.ssg4"
>> minSdkVersion 21
>> targetSdkVersion 28
>> versionCode 28
>> versionName "1.0.0"
>> testInstrumentationRunner 
>> "android.support.test.runner.AndroidJUnitRunner"
>> externalNativeBuild {
>> cmake {
>> cppFlags "-std=c++14 -frtti -fexceptions 
>> -fconstant-string-class=NSConstantString"
>> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
>> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
>> "-DANDROID_STL=c++_static",
>> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
>> }
>> }
>> ndk {
>> // Specifies the ABI configurations of your native
>>     // libraries Gradle should build and package with your APK.
>> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
>> //'arm64-v8a'
>> abiFilters 'armeabi-v7a'
>> }
>> }
>>
>>
>>
>>
>> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>>
>> Reading through the toolchain file
>> <https://android.googlesource.com/platform/ndk/+/master/build/cmake/android.toolchain.cmake>,
>> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
>> should not be the issue.
>>
>> I'd start by pepper-spraying message() calls in toolchain .cmake file,
>> and in other .cmake files as necessary, too.
>>
>> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky 
>> wrote:
>>
>>> Ah, i didn't see that shell script...  I think
>>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>>
>>>
>>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>>>
>>> Actually -- it doesn't explain why this is happening, as the shell
>>> script (which I failed to notice Gregory attached) matches what I sent him.
>>> It's using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
>>> ...-androideabi23.
>>>
>>> Strange.
>>>
>>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>>>
>>>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>>>
>>>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
>>>> jor...@noodlecake.com> wrote:
>>>>
>>>>> I think this line in his output indicates he's building for API 16:
>>>>>
>>>>>  --target=armv7-none-linux-androideabi16
>>>>>
>>>>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>>>>
>>>>> Since Greg mentioned me:
>>>>>
>>>>> Instructions/commands I came up with and that I sent over to Gregory
>>>>> should attempt using API level 23. Totally arbitrarily picked. Use of
>>>>> pre-21 API is not happening so not an issue.
>>>>>
>>>>> Needless to say, building works for me. I don’t have a self-contained
>>>>> script to share, but it’s super simplistic and what Greg described (incl
>>>>> using GUI to install NDK) is what I did.
>>>>>
>>>>> I’m only sure it builds, not that it works, as I am yet to try running
>>>>> the code; I don’t have a build script ready for producing an APK (the old
>>>>> approach from 2013 and 2014 is a mess and needs to be reworked).
>>>>>
>>>>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
>>>>> wrote:
>>>>>
>>>>>> I've got some patches but they are pretty ugly and I want to clean
>>>>>> them up properly before submitting...
>>>>>>
>>>>>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky <
>>>>>> jor...@noodlecake.com> wrote:
>>>>>>
>>>>>> An NDK app can chose to bundle

Re: Building on android....

[Ivan Vučica]

Aye; but we should not depend on using Gradle as the end state.

On Wed, Feb 13, 2019 at 5:09 PM Jordan Schidlowsky 
wrote:

> Ya you're right,  It should be picked up.  For what it's worth, here's our
> gradle config, (which ends up passing the correct flags to cmake for
> building gnustep):
>
> defaultConfig {
> applicationId "com.noodlecake.ssg4"
> minSdkVersion 21
> targetSdkVersion 28
> versionCode 28
> versionName "1.0.0"
> testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
> externalNativeBuild {
> cmake {
> cppFlags "-std=c++14 -frtti -fexceptions 
> -fconstant-string-class=NSConstantString"
> cFlags "-DANDROID -fconstant-string-class=NSConstantString"
> arguments "-DCMAKE_VERBOSE_MAKEFILE=ON",
> "-DANDROID_STL=c++_static",
> "-DANDROID_DISABLE_FORMAT_STRING_CHECKS=TRUE"
> }
> }
> ndk {
> // Specifies the ABI configurations of your native
> // libraries Gradle should build and package with your APK.
> //abiFilters 'x86', 'x86_64', 'armeabi', 'armeabi-v7a',
> //'arm64-v8a'
> abiFilters 'armeabi-v7a'
> }
> }
>
>
>
>
> On Feb 13, 2019, at 11:03 AM, Ivan Vučica  wrote:
>
> Reading through the toolchain file
> <https://android.googlesource.com/platform/ndk/+/master/build/cmake/android.toolchain.cmake>,
> ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
> should not be the issue.
>
> I'd start by pepper-spraying message() calls in toolchain .cmake file, and
> in other .cmake files as necessary, too.
>
> On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky 
> wrote:
>
>> Ah, i didn't see that shell script...  I think
>> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>>
>>
>> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>>
>> Actually -- it doesn't explain why this is happening, as the shell script
>> (which I failed to notice Gregory attached) matches what I sent him. It's
>> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
>> ...-androideabi23.
>>
>> Strange.
>>
>> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>>
>>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>>
>>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky <
>>> jor...@noodlecake.com> wrote:
>>>
>>>> I think this line in his output indicates he's building for API 16:
>>>>
>>>>  --target=armv7-none-linux-androideabi16
>>>>
>>>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>>>
>>>> Since Greg mentioned me:
>>>>
>>>> Instructions/commands I came up with and that I sent over to Gregory
>>>> should attempt using API level 23. Totally arbitrarily picked. Use of
>>>> pre-21 API is not happening so not an issue.
>>>>
>>>> Needless to say, building works for me. I don’t have a self-contained
>>>> script to share, but it’s super simplistic and what Greg described (incl
>>>> using GUI to install NDK) is what I did.
>>>>
>>>> I’m only sure it builds, not that it works, as I am yet to try running
>>>> the code; I don’t have a build script ready for producing an APK (the old
>>>> approach from 2013 and 2014 is a mess and needs to be reworked).
>>>>
>>>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
>>>> wrote:
>>>>
>>>>> I've got some patches but they are pretty ugly and I want to clean
>>>>> them up properly before submitting...
>>>>>
>>>>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
>>>>> wrote:
>>>>>
>>>>> An NDK app can chose to bundle in a (c++_shared) library in your app,
>>>>> or you can link with a static (c++_static) standard library.   This is
>>>>> actually dependant on what setting you chose for this in your gradle build
>>>>> file, as gradle will pass that along to cmake which will link it in.
>>>>>
>>>>> That cxx runtime test doesn't quite work correctly using an android
>>>>> toolchain.  But if you want to configure your ndk app using c++_static you
>>>>> can remove that test section from CMakeLists.txt and add in manually 
>>>>> below:
>>>>>
>>>>> set(CXXRT_IS

Re: Building on android....

[Ivan Vučica]

Ah, that doesn't match what I sent out and makes me feel better ;-)

On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky 
wrote:

> I think this line in his output indicates he's building for API 16:
>
>  --target=armv7-none-linux-androideabi16
>
> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>
> Since Greg mentioned me:
>
> Instructions/commands I came up with and that I sent over to Gregory
> should attempt using API level 23. Totally arbitrarily picked. Use of
> pre-21 API is not happening so not an issue.
>
> Needless to say, building works for me. I don’t have a self-contained
> script to share, but it’s super simplistic and what Greg described (incl
> using GUI to install NDK) is what I did.
>
> I’m only sure it builds, not that it works, as I am yet to try running the
> code; I don’t have a build script ready for producing an APK (the old
> approach from 2013 and 2014 is a mess and needs to be reworked).
>
> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
> wrote:
>
>> I've got some patches but they are pretty ugly and I want to clean them
>> up properly before submitting...
>>
>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
>> wrote:
>>
>> An NDK app can chose to bundle in a (c++_shared) library in your app, or
>> you can link with a static (c++_static) standard library.   This is
>> actually dependant on what setting you chose for this in your gradle build
>> file, as gradle will pass that along to cmake which will link it in.
>>
>> That cxx runtime test doesn't quite work correctly using an android
>> toolchain.  But if you want to configure your ndk app using c++_static you
>> can remove that test section from CMakeLists.txt and add in manually below:
>>
>> set(CXXRT_IS_STDLIB true)
>> target_link_libraries(objc c++_static stdc++)
>>
>> I will also note, that I am still thinking about a way to run that test
>> suite while cross compiling...
>>
>>
>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento 
>> wrote:
>>
>> A little more context...  my build environment is a MacPro 2010 running
>> the latest version of Mojave.  I have downloaded and installed the latest
>> of Android studio and installed the latest SDK and NDK using the menu under
>> tools and the SDK manager.  The version of the NDK I'm using is 19.0.5232133.
>>  I am utterly stumped as to why this is not working.  Also, it seems as
>> though Ivan's installation of this is working which seems to indicate that
>> this is a configuration issue.
>>
>> Any input would be appreciated.
>>
>> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
>> greg.casame...@gmail.com> wrote:
>>
>>> ### Build libobjc2
>>> -- The ASM compiler identification is Clang
>>> -- Found assembler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>> -- Check for working C compiler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>> -- Check for working C compiler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>> -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Detecting C compile features
>>> -- Detecting C compile features - done
>>> -- Check for working CXX compiler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>> -- Check for working CXX compiler:
>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>> -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Testing C++ interop
>>> -- Testing C++ standard library
>>> -- No useable C++ runtime found
>>> -- Looking for pthread.h
>>> -- Looking for pthread.h - found
>>> -- Looking for pthread_create
>>> -- Looking for pthread_create - found
>>> -- Found Threads: TRUE
>>> -- GNUstep install type set to NONE
>>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
>>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to:
>>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
>>>
>>> /Users/heron/Dev

Re: Building on android....

[Ivan Vučica]

Reading through the toolchain file
<https://android.googlesource.com/platform/ndk/+/master/build/cmake/android.toolchain.cmake>,
ANDROID_PLATFORM will be calculated from ANDROID_NATIVE_API_LEVEL. So that
should not be the issue.

I'd start by pepper-spraying message() calls in toolchain .cmake file, and
in other .cmake files as necessary, too.

On Wed, Feb 13, 2019 at 5:01 PM Jordan Schidlowsky 
wrote:

> Ah, i didn't see that shell script...  I think
> -DANDROID_PLATFORM=android-21 (or 23) is what you want there.
>
>
> On Feb 13, 2019, at 10:53 AM, Ivan Vučica  wrote:
>
> Actually -- it doesn't explain why this is happening, as the shell script
> (which I failed to notice Gregory attached) matches what I sent him. It's
> using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
> ...-androideabi23.
>
> Strange.
>
> On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:
>
>> Ah, that doesn't match what I sent out and makes me feel better ;-)
>>
>> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky 
>> wrote:
>>
>>> I think this line in his output indicates he's building for API 16:
>>>
>>>  --target=armv7-none-linux-androideabi16
>>>
>>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>>
>>> Since Greg mentioned me:
>>>
>>> Instructions/commands I came up with and that I sent over to Gregory
>>> should attempt using API level 23. Totally arbitrarily picked. Use of
>>> pre-21 API is not happening so not an issue.
>>>
>>> Needless to say, building works for me. I don’t have a self-contained
>>> script to share, but it’s super simplistic and what Greg described (incl
>>> using GUI to install NDK) is what I did.
>>>
>>> I’m only sure it builds, not that it works, as I am yet to try running
>>> the code; I don’t have a build script ready for producing an APK (the old
>>> approach from 2013 and 2014 is a mess and needs to be reworked).
>>>
>>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
>>> wrote:
>>>
>>>> I've got some patches but they are pretty ugly and I want to clean them
>>>> up properly before submitting...
>>>>
>>>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
>>>> wrote:
>>>>
>>>> An NDK app can chose to bundle in a (c++_shared) library in your app,
>>>> or you can link with a static (c++_static) standard library.   This is
>>>> actually dependant on what setting you chose for this in your gradle build
>>>> file, as gradle will pass that along to cmake which will link it in.
>>>>
>>>> That cxx runtime test doesn't quite work correctly using an android
>>>> toolchain.  But if you want to configure your ndk app using c++_static you
>>>> can remove that test section from CMakeLists.txt and add in manually below:
>>>>
>>>> set(CXXRT_IS_STDLIB true)
>>>> target_link_libraries(objc c++_static stdc++)
>>>>
>>>> I will also note, that I am still thinking about a way to run that test
>>>> suite while cross compiling...
>>>>
>>>>
>>>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento <
>>>> greg.casame...@gmail.com> wrote:
>>>>
>>>> A little more context...  my build environment is a MacPro 2010 running
>>>> the latest version of Mojave.  I have downloaded and installed the latest
>>>> of Android studio and installed the latest SDK and NDK using the menu under
>>>> tools and the SDK manager.  The version of the NDK I'm using is 
>>>> 19.0.5232133.
>>>>  I am utterly stumped as to why this is not working.  Also, it seems as
>>>> though Ivan's installation of this is working which seems to indicate that
>>>> this is a configuration issue.
>>>>
>>>> Any input would be appreciated.
>>>>
>>>> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
>>>> greg.casame...@gmail.com> wrote:
>>>>
>>>>> ### Build libobjc2
>>>>> -- The ASM compiler identification is Clang
>>>>> -- Found assembler:
>>>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>>>> -- Check for working C compiler:
>>>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>>>> -- Check for working C compiler:
>>>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darw

Re: Building on android....

[Ivan Vučica]

Actually -- it doesn't explain why this is happening, as the shell script
(which I failed to notice Gregory attached) matches what I sent him. It's
using -DANDROID_NATIVE_API_LEVEL=23 which should make it use
...-androideabi23.

Strange.

On Wed, Feb 13, 2019 at 4:47 PM Ivan Vučica  wrote:

> Ah, that doesn't match what I sent out and makes me feel better ;-)
>
> On Wed, Feb 13, 2019 at 4:41 PM Jordan Schidlowsky 
> wrote:
>
>> I think this line in his output indicates he's building for API 16:
>>
>>  --target=armv7-none-linux-androideabi16
>>
>> On Feb 13, 2019, at 10:07 AM, Ivan Vučica  wrote:
>>
>> Since Greg mentioned me:
>>
>> Instructions/commands I came up with and that I sent over to Gregory
>> should attempt using API level 23. Totally arbitrarily picked. Use of
>> pre-21 API is not happening so not an issue.
>>
>> Needless to say, building works for me. I don’t have a self-contained
>> script to share, but it’s super simplistic and what Greg described (incl
>> using GUI to install NDK) is what I did.
>>
>> I’m only sure it builds, not that it works, as I am yet to try running
>> the code; I don’t have a build script ready for producing an APK (the old
>> approach from 2013 and 2014 is a mess and needs to be reworked).
>>
>> On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
>> wrote:
>>
>>> I've got some patches but they are pretty ugly and I want to clean them
>>> up properly before submitting...
>>>
>>> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
>>> wrote:
>>>
>>> An NDK app can chose to bundle in a (c++_shared) library in your app, or
>>> you can link with a static (c++_static) standard library.   This is
>>> actually dependant on what setting you chose for this in your gradle build
>>> file, as gradle will pass that along to cmake which will link it in.
>>>
>>> That cxx runtime test doesn't quite work correctly using an android
>>> toolchain.  But if you want to configure your ndk app using c++_static you
>>> can remove that test section from CMakeLists.txt and add in manually below:
>>>
>>> set(CXXRT_IS_STDLIB true)
>>> target_link_libraries(objc c++_static stdc++)
>>>
>>> I will also note, that I am still thinking about a way to run that test
>>> suite while cross compiling...
>>>
>>>
>>> On Feb 13, 2019, at 6:41 AM, Gregory Casamento 
>>> wrote:
>>>
>>> A little more context...  my build environment is a MacPro 2010 running
>>> the latest version of Mojave.  I have downloaded and installed the latest
>>> of Android studio and installed the latest SDK and NDK using the menu under
>>> tools and the SDK manager.  The version of the NDK I'm using is 
>>> 19.0.5232133.
>>>  I am utterly stumped as to why this is not working.  Also, it seems as
>>> though Ivan's installation of this is working which seems to indicate that
>>> this is a configuration issue.
>>>
>>> Any input would be appreciated.
>>>
>>> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
>>> greg.casame...@gmail.com> wrote:
>>>
>>>> ### Build libobjc2
>>>> -- The ASM compiler identification is Clang
>>>> -- Found assembler:
>>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>>> -- Check for working C compiler:
>>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>>> -- Check for working C compiler:
>>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>>>> -- works
>>>> -- Detecting C compiler ABI info
>>>> -- Detecting C compiler ABI info - done
>>>> -- Detecting C compile features
>>>> -- Detecting C compile features - done
>>>> -- Check for working CXX compiler:
>>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>>> -- Check for working CXX compiler:
>>>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>>>> -- works
>>>> -- Detecting CXX compiler ABI info
>>>> -- Detecting CXX compiler ABI info - done
>>>> -- Detecting CXX compile features
>>>> -- Detecting CXX compile features - done
>>>> -- Testing C++ interop
>>>> -- Testing C++ standard library
>>>> -- No useable C++ runtime found
>>

Re: Building on android....

[Ivan Vučica]

Since Greg mentioned me:

Instructions/commands I came up with and that I sent over to Gregory should
attempt using API level 23. Totally arbitrarily picked. Use of pre-21 API
is not happening so not an issue.

Needless to say, building works for me. I don’t have a self-contained
script to share, but it’s super simplistic and what Greg described (incl
using GUI to install NDK) is what I did.

I’m only sure it builds, not that it works, as I am yet to try running the
code; I don’t have a build script ready for producing an APK (the old
approach from 2013 and 2014 is a mess and needs to be reworked).

On Wed 13 Feb 2019 at 15:34 Jordan Schidlowsky 
wrote:

> I've got some patches but they are pretty ugly and I want to clean them up
> properly before submitting...
>
> On Feb 13, 2019, at 8:41 AM, Jordan Schidlowsky 
> wrote:
>
> An NDK app can chose to bundle in a (c++_shared) library in your app, or
> you can link with a static (c++_static) standard library.   This is
> actually dependant on what setting you chose for this in your gradle build
> file, as gradle will pass that along to cmake which will link it in.
>
> That cxx runtime test doesn't quite work correctly using an android
> toolchain.  But if you want to configure your ndk app using c++_static you
> can remove that test section from CMakeLists.txt and add in manually below:
>
> set(CXXRT_IS_STDLIB true)
> target_link_libraries(objc c++_static stdc++)
>
> I will also note, that I am still thinking about a way to run that test
> suite while cross compiling...
>
>
> On Feb 13, 2019, at 6:41 AM, Gregory Casamento 
> wrote:
>
> A little more context...  my build environment is a MacPro 2010 running
> the latest version of Mojave.  I have downloaded and installed the latest
> of Android studio and installed the latest SDK and NDK using the menu under
> tools and the SDK manager.  The version of the NDK I'm using is 19.0.5232133.
>  I am utterly stumped as to why this is not working.  Also, it seems as
> though Ivan's installation of this is working which seems to indicate that
> this is a configuration issue.
>
> Any input would be appreciated.
>
> On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
>> ### Build libobjc2
>> -- The ASM compiler identification is Clang
>> -- Found assembler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- Check for working C compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
>> -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Check for working CXX compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> -- Check for working CXX compiler:
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Testing C++ interop
>> -- Testing C++ standard library
>> -- No useable C++ runtime found
>> -- Looking for pthread.h
>> -- Looking for pthread.h - found
>> -- Looking for pthread_create
>> -- Looking for pthread_create - found
>> -- Found Threads: TRUE
>> -- GNUstep install type set to NONE
>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
>> -- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to:
>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build
>>
>> /Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake
>> [1/1] Linking CXX executable test_cxx_runtime
>> FAILED: test_cxx_runtime
>> : &&
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
>> --target=armv7-none-linux-androideabi16
>> --gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64
>>   --sysroot
>> /Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
>> -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables
>> -fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16
>> -fno-addrsig -mthumb -Wa,--noexecstack -Wformat -Werror=format-security
>> -stdlib=libc++  -Wl,--exclude-libs,libgcc.a
>> -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id
>> -Wl,--warn-shared-textrel  -Wl,--exclude-libs,libunwind.a
>> -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,-z,relro
>> -Wl,-z,now -Wl,--gc-sections
>> CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o 

Re: ANN: GNUstep Base 1.26.0

[Ivan Vučica]

On Sat, Jan 12, 2019 at 5:04 PM Richard Frith-Macdonald  wrote:
>
> 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.

Thanks for the kind words!

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

Re: ANN: GNUstep Base 1.26.0

[Ivan Vučica]

Apologies for the noise, I'll resend correctly formatted.

On Mon, Jan 7, 2019 at 9:17 PM Ivan Vucica  wrote:

> MD5 hashes: 7138d50e29ee7c5a7eb724ec5a0af7b7 gnustep-base-1.26.0.tar.gz
> fee2547f529c2c30b3560c3914dbc159 gnustep-base-1.26.0.tar.gz.sig 1
> Announcement ** The GNUstep Base Library, version 1.26.0, is
> now available. 1.1 What is the GNUstep Base Library?
> = The GNUstep Base Library is a
> library of general-purpose, non-graphical Objective C objects.  For
> example, it includes classes for strings, object collections, byte
> streams, typed coders, invocations, notifications, notification
> dispatchers, moments in time, network ports, remote object messaging
> support (distributed objects), and event loops.It provides
> functionality that aims to implement the non-graphical portion of the
> OpenStep standard (the Foundation library).There is more information
> available at the GNUstep homepage at 'http://www.gnustep.org'. 1.2
> Noteworthy changes in version '1.26.0'
> ==* Improve utf8 validity
> checks.* Make point and size subclasses for NSValue interchangable.
>* Add support for TLS SNI. Always request certificate from client and
>  update certificates after 5 minutes.* Don't write deprecated
> fields to desktop link file.* Use NSLock instead of GSLazyLock and
> other improvements for  multithreaded processes.* Clean up of
> NSString cluster.* Update NSAssert() and NSCAssert() to handle
> variable arguments (as  OSX has done) and mark the numbered macros
> as obsolete.* Various improvements in tests.* Require ICU >= 50.
>* ICU is now detected using pkg-config.* Improve XML parsing.
> * Make NSXMLNode ivar a union representing different types, instead
> of assuming it will contain different underlying class types in
> different contexts.  This is important for the new libobjc2 ABI.*
> OSX compatibility changes to NSURL.* NSFileManager call error handle
> on missing file.* Dummy spinlock implementation for platforms that
> don't support it.* Internationalization improvements: Japanese
> translation, Turkish  translation, Polish translation.* Various
> improvements for new libobjc2 "v2 ABI", including things  like a new
> NSConstantString implementation, making  GS_REPLACE_CONSTANT_STRING
> a noop with the new ABI, etc.* Improvements for stack traces,
> exception handling and dead lock  detection.* Other more minor
> bugfixes and cleanups.  Many found by Coverity  scan results.*
> As usual, this release also contains an update to include the most
> recent international timezone data. 1.3 Where can you get it? How can
> you compile it? = The
> gnustep-base-1.26.0.tar.gz distribution file has been placed at
> .Please log bug reports on
> the GNUstep project page 
> or send bug reports to .
>
>
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Cutting a release?

[Ivan Vučica]

On Thu, Jan 3, 2019 at 10:42 PM Fred Kiefer  wrote:
> > Am 02.01.2019 um 17:48 schrieb Ivan Vučica :
> >
> > In the meantime, if maintainers could help me out by updating the
> > non-autogenerated news entries and such, that'd help a lot. Crawling
> > through the ChangeLogs and VCS logs takes a lot of the time when
> > cutting a release I could better spend wrestling with git tagging, GPG
> > signing and uploading to multiple locations.
>
> I have done this for back today and plan to do it for gui tomorrow. We should 
> still merge the pkg config change to base but the other changes will have to 
> wait until after this release.

This is noted. Unless steps are done before, I'll try to do this over
the weekend:

- merge the pkg config change to base
- update/regenerate base newsfiles
- update/regenerate gui newsfiles
- regenerate back newsfiles
- cut base, gui and back releases

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

Re: Cutting a release?

[Ivan Vučica]

On Tue, Jan 1, 2019 at 11:44 PM Yavor Doganov  wrote:
>
> В Tue, 01 Jan 2019 23:28:35 +, Ivan Vučica написа:
> > On Tue, Jan 1, 2019 at 9:43 PM Yavor Doganov  wrote:
> >> I believe it's too late for that.
> >>
> > I could cut a release this weekend, and then we do another one by the
> > end of the month.
>
> It is probably doable, but there should be a combintation of factors in
> our favor to make it work.  We need to get the new release in experimental
> (ideally built on all release architectures) before 11th so that I file a
> transition bug before the deadline [1].


I realized I'm not sure what transition means. Out of curiosity, is it
the transition from e.g.  libgnustep-gui0.26 to libgnustep-gui0.27?
That is, is the problem creation of a new binary package?

>
> So, if you release on Sat/Sun
> and we prepare the package almost immediately, we'll have to wait for a
> sponsor to do the upload and then for ftpmasters to process it as it has
> to pass through the NEW queue.  This is the biggest hurdle; sometimes it
> takes a few days but it may take months.


I think I have a few DDs I might be able to bother for sponsorship if
we agree on a release. I suppose ftpmasters will be a hard block at
that point.

In the meantime, if maintainers could help me out by updating the
non-autogenerated news entries and such, that'd help a lot. Crawling
through the ChangeLogs and VCS logs takes a lot of the time when
cutting a release I could better spend wrestling with git tagging, GPG
signing and uploading to multiple locations.

>
> We are doing a Pantomime
> transition right now despite the fact that 1.3.0 was released long time
> ago; it spent months in the NEW queue and then I had to wait a further
> month to verify that it builds on mipsen (slowest buildds always lagging).
>
> [1] Assuming that the Debian Release Team will process these bugs on the
> basis that they're filed before the deadline; they may well postpone
> these transitions after the buster release.

*sigh* I love bureaucracy.

It's really hard for a non-DD to be aware of these deadlines. It's
even more fun to think about all the other distributions and OSes that
I'm not even trying to track.

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

Re: Cutting a release?

[Ivan Vučica]

On Tue, Jan 1, 2019 at 11:23 PM Ivan Vučica  wrote:

>
>
>>
>> PS: Did you see the two pull requests for back today? The first one, that
>> wasn’t a real pull request rather a question about the code, has triggered
>> me to rethink the removal of RContext. Perhaps somebody else could have a
>> look too?
>>
>
> I'll take a look and see if I can contribute anything useful.
>

I have no real opinion. Except less code is better code. Rollbacks are easy.

Not sure about XSHM branches either. Are they really never used?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Cutting a release?

[Ivan Vučica]

On Tue, Jan 1, 2019 at 9:43 PM Yavor Doganov  wrote:

> I believe it's too late for that.  GUI would need its SONAME bumped which
> would mean we'll have to do a transition, but the transition freeze is on
> 12th Jan.
>

I could cut a release this weekend, and then we do another one by the end
of the month.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Cutting a release?

[Ivan Vučica]

Hi maintainers,

If you want, I can spend some time cutting a release. It has been a while
since the last one. Do we need a one? Are there critical bugs we fixed? Are
there critical bugs blocking the release?

There’s a pull request for icu-config removal that we could apply to -base.
It might warrant a release.

If the answer is yes, if you can help me by updating the
(non-autogenerated) pieces of the release notes, that would help me a bit.

If the answer is yes, I would be cutting the release on a weekend.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: libs-quartzcore won't build

[Ivan Vučica]

Sorry about this. I did the merge on a machine without a working GS,
so I omitted trying to build. It's amazing I only missed this one
thing, really.

Stjepan, I'm happy that the IM hints helped :-)

Please remove the extra newline from ChangeLog and I will
merge this at the earliest convenience. Thanks!
On Sat, Jun 9, 2018 at 2:49 PM Stjepan Brkić  wrote:
>
> Fixed by adding by adding CGFloat _contentsScale ivar to 
> Headers/QuartzCore/CALayer.h (#PR3).
>
> sub, 9. lip 2018. u 13:00 Fred Kiefer  napisao je:
>>
>> I think you are correct here. Could you please fix this yourself? I am still 
>> travelling and won’t be able to do it until next week.
>>
>> Fred
>>
>> Unterwegs
>>
>> Am 09.06.2018 um 07:17 schrieb Stjepan Brkić :
>>
>> Hello all,
>>
>> Couple of days ago I started getting errors while running make in 
>> libs-quartzcore.
>>
>> I was open to the possibility that I broke something, so today I wiped all 
>> GNUstep related files and folders and cloned and rebuilt everything from 
>> scratch. The error message persists.
>>
>> The eror message:
>>
>> CALayer.m:102:13: error: synthesized property 'contentsScale' must either be 
>> named the same as a compatible instance variable or must explicitly name an 
>> instance variable
>> @synthesize contentsScale=_contentsScale;
>>
>> It looks to me that commit 794a903ab800ec3df27787903497b59f7a75bcb6:
>> Author: Ivan Vučica 
>> Date:   Thu Jun 7 22:26:36 2018 +
>>
>> Fixes for borderColor and contentsScale from pull request #2.
>>
>> Clarify definition of borderColor. Fix implementation of
>> borderColor. Introduce synthesis of contentsScale.
>>
>> breaks this, but I'm not entirely sure.
>>
>> Can anyone confirm this?
>>
>> Thanks,
>> Stjepan
>>
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

Re: CA broken; how do I differentiate NSValues for size and point?

[Ivan Vučica]

Thanks for all the attention you've given to this!

On Sun, May 27, 2018 at 10:29 PM Fred Kiefer  wrote:

> Sorry, you seem to be using an unusual mail format that my Apple Mail
isn’t able to properly reply to.

I hit reply-to-all in Gmail, then I hit enter where I want to inline reply.
I don't have insight into what Gmail does before sending.

I'll switch to plaintext only (which I wanted to use anyway), which should
help.

> > I am in favor of leaving the bug open on Savannah and Github, then? I
can no longer reproduce the original issue after updating to the latest
fixes, but if you believe the solution that's in place is hacky, maybe the
bugs can be repurposed.
> >
> > Otherwise, I am fine with them being closed (as the immediate
NSSize/NSPoint problem no longer persists).

> No, keep the two bug reports open. It might be that when we come up with
a fix we will forget to close one of them. Please keep an eye open for that
case and remind me.

Ah -- it's unlikely I'll remember something you won't :-)

Maybe you can assign the bug(s) to yourself, so they appear in bug
dashboards?


> > PS: In your test code the second PASS is missing a „!“.
> >
> > It doesn't; @encode(NSPoint) should be different than @encode(NSSize).
> >
> > I actually added comments to the new test case I pushed to my personal
repo, so it should be clearer what's going on.

> I was referring to this line:

>   PASS(result, "@encoding(NSSize) == pointV objCType“);

> And there you check that the two values are not equal, which in C like
programming languages is done via a negation that is missing in the
description string.

Oh, right. Sorry. That was an oversight which I corrected after sending the
email. :-)

> I really should be more verbose in my writing. The reason here is that I
am no longer used to communications in English. Sorry for that.

I hope to be in that situation again someday ;-)

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

Re: CA broken; how do I differentiate NSValues for size and point?

[Ivan Vučica]

On Sun, May 27, 2018 at 7:47 PM Fred Kiefer  wrote:

> Hi Ivan,
>
> great analysis and nice code to reproduce this, but you seem to have
> missed my mail on the issue (even though it is included in your mail) and
> the work around I added to base.


I saw it, but it was not clear how deeply you've looked into it. That is
why I mentioned that I use the revision from May 20. :-)


> I was already fully aware of this and the patch I added should prevent
> your test code from throwing the exception.


It indeed has; after figuring out what the cause is, I wrote this to be
able to check whether your fixes which you mentioned in the email work:

https://github.com/ivucica/libs-base/commit/4771a84f7fd4d8b1536b9f52ef30ec524ec6357d

Test that no longer fails is setting the size using KVC.

I'm also pleased that I can probably remove "KVO notification does not get
triggered for setting struct properties", as well -- I think you told me
years ago that this was fixed, but only now did I check :-)

If you tell me this test is useful, I can open a PR and we can do a code
review there.


> Of course this is not the real solution. We may have to add the same
> checks for known types in GSObjCSetVal that we already have in other
> places. This is rather ugly code which I would prefer to avoid. I hope to
> see Richard in two weeks time and we may come up with a better solution
> together.
>

I am in favor of leaving the bug open on Savannah and Github, then? I can
no longer reproduce the original issue after updating to the latest fixes,
but if you believe the solution that's in place is hacky, maybe the bugs
can be repurposed.

Otherwise, I am fine with them being closed (as the immediate
NSSize/NSPoint problem no longer persists).

If the issue persists even with my work around in place it would be good to
> know. I have a few ideas for better work arounds but would prefer a cleaner
> solution.
>
> Fred
>
> PS: In your test code the second PASS is missing a „!“.
>

It doesn't; @encode(NSPoint) should be different than @encode(NSSize).

I actually added comments to the new test case I pushed to my personal
repo, so it should be clearer what's going on.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: CA broken; how do I differentiate NSValues for size and point?

[Ivan Vučica]

This has been filed as https://savannah.gnu.org/bugs/index.php?53994 and
https://github.com/gnustep/libs-base/issues/25.

On Sun, May 27, 2018 at 6:44 PM Ivan Vučica <i...@vucica.net> wrote:

> I'll open a bug for -base. In the meantime I'll help Stjepan disable
> shadowOffset.
>
> Minimum repro::
>
> #import 
>
> @interface A : NSObject
> {
>   NSSize _s;
> }
> @end
> @implementation A
> - (NSSize) s {
>   return self->_s;
> }
> - (void) setS: (NSSize) s {
>   self->_s = s;
> }
> @end
> int main() {
>   NSSize in = NSMakeSize(1.0, 2.0);
>   NSValue * v = [NSValue valueWithBytes: 
>objCType: @encode(NSSize)];
>   A * a = [A new];
>   [a setValue: v
>forKey: @"s"];
>
>
>   return 0;
> }
>
>
> Output:
> $ clang `gnustep-config --objc-flags` `gnustep-config --objc-libs`
> `gnustep-config --base-libs` repro.m -o repro && ./repro
> clang: warning: argument unused during compilation: '-fobjc-nonfragile-abi'
> clang: warning: argument unused during compilation: '-fobjc-nonfragile-abi'
> 2018-05-27 18:42:13.137 repro[14432:14432] match! point is {_NSPoint=dd},
> type is {_NSSize=dd}
> ./repro: Uncaught exception NSInvalidArgumentException, reason:
> [GSSizeValue-pointValue] should be overridden by subclass
> Aborted
>
>
>
>
>
> On Sun, May 27, 2018 at 6:18 PM Ivan Vučica <i...@vucica.net> wrote:
>
>> So turns out we don't use shadowOffset in any demo code. So examining
>> CAAnimation was pointless.
>>
>> However I managed to get a backtrace using lldb, and this happens when
>> the code sets the default shadowOffset value. So you pointed to the right
>> place; shadowOffset is the problem. This is the place of the exception, in
>> -[CALayer init] which calls +[CALayer defaultValueForKey:]:
>>
>>   if ([key isEqualToString: @"shadowOffset"])
>>
>> {
>>   CGSize offset = CGSizeMake(0.0, -3.0);
>>   return [NSValue valueWithBytes:  objCType: @encode(CGSize)];
>> }
>>
>> What is strange is that this happens deep inside base, when I am setting
>> valueWithBytes, with a CGSize type.
>>
>> So I looked closer at the backtrace and it's happening in
>> base/Source/Additions/GSObjCRuntime.m. Relevant chunk:
>>
>> frame #2: 0x759e9d7d libgnustep-base.so.1.25`+[NSException
>> raise:format:](self=0x75f69878
>> , _cmd="S", name=0x75f69438, format=0x76003828) + 365 at
>> NSException.m:1376
>> frame #3: 0x75b9ca2f
>> libgnustep-base.so.1.25`-[NSObject(self=0x0148f568, _cmd="\xffa9
>> \x02", aSel="\x0e\x01") subclassResponsibility:] + 255 at
>> NSObject+GNUstepBase.m:134
>> frame #4: 0x75b1d32b libgnustep-base.so.1.25`-[NSValue
>> pointValue](self=0x0148f568, _cmd=
>> "\x0e\x01") + 43 at NSValue.m:394
>> frame #5: 0x75b58649
>> libgnustep-base.so.1.25`GSObjCSetVal(self=0x014591c8, key="shadowOff
>> set", val=0x0148f568, sel="\xffda\e", type="{_NSSize=dd}",
>> size=12, offset=0) + 3497 at GSObjCRun
>> time.m:1794
>> frame #6: 0x75a25857
>> libgnustep-base.so.1.25`SetValueForKey(self=0x014591c8, anObject=0x0
>> 148f568, key="shadowOffset", size=12) + 1079 at
>> NSKeyValueCoding.m:150
>> frame #7: 0x75a253ee
>> libgnustep-base.so.1.25`-[NSObject(self=0x014591c8, _cmd="P\x04", an
>> Object=0x0148f568, aKey=0x762cc560) setValue:forKey:] +
>> 382 at NSKeyValueCoding.m:370
>> frame #8: 0x75a2881d libgnustep-base.so.1.25`-[GSKVOBase
>> setValue:forKey:](self=0x014591c
>> 8, _cmd="P\x04", anObject=0x0148f568, aKey=0x762cc560) +
>> 221 at NSKeyValueObserving.m:238
>> frame #9: 0x760a22ac libQuartzCore.so.0`-[CALayer
>> init](self=0x014591c8, _cmd="\xffa1
>>
>> I added a debug statement to GSObjCSetVal:
>>
>>   case _C_STRUCT_B:
>> if (GSSelectorTypesMatch(@encode(NSPoint), type))
>>   {
>> NSLog(@"match! point is %s, type is %s",
>> @encode(NSPoint), type);
>> NSPoint v = [val pointValue];
>>
>> This is the output:
>> 2018-05-27 17:58:46.980 hello_carenderer[10274:10274] match! point is
>> {_NSPoint=dd}, type is {_NSPoint=dd}
>> 2018-05-27 17:58:46.981 hello_carenderer[10274:10274] match! point is
>

Re: CA broken; how do I differentiate NSValues for size and point?

[Ivan Vučica]

I'll open a bug for -base. In the meantime I'll help Stjepan disable
shadowOffset.

Minimum repro::

#import 

@interface A : NSObject
{
  NSSize _s;
}
@end
@implementation A
- (NSSize) s {
  return self->_s;
}
- (void) setS: (NSSize) s {
  self->_s = s;
}
@end
int main() {
  NSSize in = NSMakeSize(1.0, 2.0);
  NSValue * v = [NSValue valueWithBytes: 
   objCType: @encode(NSSize)];
  A * a = [A new];
  [a setValue: v
   forKey: @"s"];


  return 0;
}


Output:
$ clang `gnustep-config --objc-flags` `gnustep-config --objc-libs`
`gnustep-config --base-libs` repro.m -o repro && ./repro
clang: warning: argument unused during compilation: '-fobjc-nonfragile-abi'
clang: warning: argument unused during compilation: '-fobjc-nonfragile-abi'
2018-05-27 18:42:13.137 repro[14432:14432] match! point is {_NSPoint=dd},
type is {_NSSize=dd}
./repro: Uncaught exception NSInvalidArgumentException, reason:
[GSSizeValue-pointValue] should be overridden by subclass
Aborted





On Sun, May 27, 2018 at 6:18 PM Ivan Vučica <i...@vucica.net> wrote:

> So turns out we don't use shadowOffset in any demo code. So examining
> CAAnimation was pointless.
>
> However I managed to get a backtrace using lldb, and this happens when the
> code sets the default shadowOffset value. So you pointed to the right
> place; shadowOffset is the problem. This is the place of the exception, in
> -[CALayer init] which calls +[CALayer defaultValueForKey:]:
>
>   if ([key isEqualToString: @"shadowOffset"])
>
> {
>   CGSize offset = CGSizeMake(0.0, -3.0);
>   return [NSValue valueWithBytes:  objCType: @encode(CGSize)];
> }
>
> What is strange is that this happens deep inside base, when I am setting
> valueWithBytes, with a CGSize type.
>
> So I looked closer at the backtrace and it's happening in
> base/Source/Additions/GSObjCRuntime.m. Relevant chunk:
>
> frame #2: 0x759e9d7d libgnustep-base.so.1.25`+[NSException
> raise:format:](self=0x75f69878
> , _cmd="S", name=0x75f69438, format=0x76003828) + 365 at
> NSException.m:1376
> frame #3: 0x75b9ca2f
> libgnustep-base.so.1.25`-[NSObject(self=0x0148f568, _cmd="\xffa9
> \x02", aSel="\x0e\x01") subclassResponsibility:] + 255 at
> NSObject+GNUstepBase.m:134
> frame #4: 0x75b1d32b libgnustep-base.so.1.25`-[NSValue
> pointValue](self=0x0148f568, _cmd=
> "\x0e\x01") + 43 at NSValue.m:394
> frame #5: 0x75b58649
> libgnustep-base.so.1.25`GSObjCSetVal(self=0x014591c8, key="shadowOff
> set", val=0x0148f568, sel="\xffda\e", type="{_NSSize=dd}",
> size=12, offset=0) + 3497 at GSObjCRun
> time.m:1794
> frame #6: 0x75a25857
> libgnustep-base.so.1.25`SetValueForKey(self=0x014591c8, anObject=0x0
> 148f568, key="shadowOffset", size=12) + 1079 at
> NSKeyValueCoding.m:150
> frame #7: 0x75a253ee
> libgnustep-base.so.1.25`-[NSObject(self=0x014591c8, _cmd="P\x04", an
> Object=0x0148f568, aKey=0x762cc560) setValue:forKey:] +
> 382 at NSKeyValueCoding.m:370
> frame #8: 0x75a2881d libgnustep-base.so.1.25`-[GSKVOBase
> setValue:forKey:](self=0x014591c
> 8, _cmd="P\x04", anObject=0x0148f568, aKey=0x762cc560) +
> 221 at NSKeyValueObserving.m:238
> frame #9: 0x760a22ac libQuartzCore.so.0`-[CALayer
> init](self=0x014591c8, _cmd="\xffa1
>
> I added a debug statement to GSObjCSetVal:
>
>   case _C_STRUCT_B:
> if (GSSelectorTypesMatch(@encode(NSPoint), type))
>   {
> NSLog(@"match! point is %s, type is %s", @encode(NSPoint),
> type);
> NSPoint v = [val pointValue];
>
> This is the output:
> 2018-05-27 17:58:46.980 hello_carenderer[10274:10274] match! point is
> {_NSPoint=dd}, type is {_NSPoint=dd}
> 2018-05-27 17:58:46.981 hello_carenderer[10274:10274] match! point is
> {_NSPoint=dd}, type is {_NSSize=dd}
>
> Therefore, it's a bug in -base that makes it interpret sizes as points!
>
> I'm still coming up with a minimum repro case.
>
> (n.b. some of the confusion on why CGSize and CGPoint get understood as
> their NS equivalents is this chunk from opal:
>   typedef NSPoint CGPoint;
>   typedef NSSize CGSize;
>   typedef NSRect CGRect;
> I do not believe this to be correct, but I will not be addressing it at
> this time.
>
> Separately: are typedefs of structs meant to be encoded as the original
> struct name? Probably yes?)
>
>
> On Sun, May 27, 2018 at 5:29 PM Ivan Vučica <i..

Re: CA broken; how do I differentiate NSValues for size and point?

[Ivan Vučica]

So turns out we don't use shadowOffset in any demo code. So examining
CAAnimation was pointless.

However I managed to get a backtrace using lldb, and this happens when the
code sets the default shadowOffset value. So you pointed to the right
place; shadowOffset is the problem. This is the place of the exception, in
-[CALayer init] which calls +[CALayer defaultValueForKey:]:

  if ([key isEqualToString: @"shadowOffset"])

{
  CGSize offset = CGSizeMake(0.0, -3.0);
  return [NSValue valueWithBytes:  objCType: @encode(CGSize)];
}

What is strange is that this happens deep inside base, when I am setting
valueWithBytes, with a CGSize type.

So I looked closer at the backtrace and it's happening in
base/Source/Additions/GSObjCRuntime.m. Relevant chunk:

frame #2: 0x759e9d7d libgnustep-base.so.1.25`+[NSException
raise:format:](self=0x75f69878
, _cmd="S", name=0x75f69438, format=0x76003828) + 365 at
NSException.m:1376
frame #3: 0x75b9ca2f
libgnustep-base.so.1.25`-[NSObject(self=0x0148f568, _cmd="\xffa9
\x02", aSel="\x0e\x01") subclassResponsibility:] + 255 at
NSObject+GNUstepBase.m:134
frame #4: 0x75b1d32b libgnustep-base.so.1.25`-[NSValue
pointValue](self=0x0148f568, _cmd=
"\x0e\x01") + 43 at NSValue.m:394
frame #5: 0x75b58649
libgnustep-base.so.1.25`GSObjCSetVal(self=0x014591c8, key="shadowOff
set", val=0x0148f568, sel="\xffda\e", type="{_NSSize=dd}",
size=12, offset=0) + 3497 at GSObjCRun
time.m:1794
frame #6: 0x75a25857
libgnustep-base.so.1.25`SetValueForKey(self=0x014591c8, anObject=0x0
148f568, key="shadowOffset", size=12) + 1079 at
NSKeyValueCoding.m:150
frame #7: 0x75a253ee
libgnustep-base.so.1.25`-[NSObject(self=0x014591c8, _cmd="P\x04", an
Object=0x0148f568, aKey=0x762cc560) setValue:forKey:] + 382
at NSKeyValueCoding.m:370
frame #8: 0x75a2881d libgnustep-base.so.1.25`-[GSKVOBase
setValue:forKey:](self=0x014591c
8, _cmd="P\x04", anObject=0x0148f568, aKey=0x762cc560) +
221 at NSKeyValueObserving.m:238
frame #9: 0x760a22ac libQuartzCore.so.0`-[CALayer
init](self=0x014591c8, _cmd="\xffa1

I added a debug statement to GSObjCSetVal:

  case _C_STRUCT_B:
if (GSSelectorTypesMatch(@encode(NSPoint), type))
  {
NSLog(@"match! point is %s, type is %s", @encode(NSPoint),
type);
NSPoint v = [val pointValue];

This is the output:
2018-05-27 17:58:46.980 hello_carenderer[10274:10274] match! point is
{_NSPoint=dd}, type is {_NSPoint=dd}
2018-05-27 17:58:46.981 hello_carenderer[10274:10274] match! point is
{_NSPoint=dd}, type is {_NSSize=dd}

Therefore, it's a bug in -base that makes it interpret sizes as points!

I'm still coming up with a minimum repro case.

(n.b. some of the confusion on why CGSize and CGPoint get understood as
their NS equivalents is this chunk from opal:
  typedef NSPoint CGPoint;
  typedef NSSize CGSize;
  typedef NSRect CGRect;
I do not believe this to be correct, but I will not be addressing it at
this time.

Separately: are typedefs of structs meant to be encoded as the original
struct name? Probably yes?)


On Sun, May 27, 2018 at 5:29 PM Ivan Vučica <i...@vucica.net> wrote:

> I added a test to the -base from May 20:
>
>   NSPoint point = {.x = 16.0, .y = 32.0};
>   NSValue *pointV = [NSValue valueWithPoint: point];
>
>   result = !strcmp(@encode(NSPoint), [pointV objCType]);
>   PASS(result, "@encoding(NSPoint) == pointV objCType");
>
>   result = strcmp(@encode(NSSize), [pointV objCType]);
>   PASS(result, "@encoding(NSSize) == pointV objCType");
>
> with this temporarly ine:
>   NSLog(@"%s %s %s", @encode(NSPoint), @encode(NSSize), [pointV objCType]);
>
> It passes and prints out:
>
> 2018-05-27 17:27:38.823 size-point-encoding[25395:25395] {_NSPoint=dd}
> {_NSSize=dd} {_NSPoint=dd}
>
> I''m annoyed at how I did not notice that I did use CGSize. I will
> introduce support for NSSize/CGSize.
>
> Thanks!
>
> On Mon, May 21, 2018 at 12:53 AM Fred Kiefer <fredkie...@gmx.de> wrote:
>
>> I added a bit of code in base that allows to use NSValue objects for size
>> and point with methods for the other type. This is a bit closer to the
>> Cocoa behaviour but will require more tweaking to have it fully correct. It
>> will at least allow you to run this test code again.
>>
>> > Am 20.05.2018 um 16:02 schrieb Fred Kiefer <fredkie...@gmx.de>:
>> >
>> > I spend some time to understand this issue. But to be honest it took me
>> more time to understand why this ever worked :-)
>>

Re: CA broken; how do I differentiate NSValues for size and point?

[Ivan Vučica]

I added a test to the -base from May 20:

  NSPoint point = {.x = 16.0, .y = 32.0};
  NSValue *pointV = [NSValue valueWithPoint: point];

  result = !strcmp(@encode(NSPoint), [pointV objCType]);
  PASS(result, "@encoding(NSPoint) == pointV objCType");

  result = strcmp(@encode(NSSize), [pointV objCType]);
  PASS(result, "@encoding(NSSize) == pointV objCType");

with this temporarly ine:
  NSLog(@"%s %s %s", @encode(NSPoint), @encode(NSSize), [pointV objCType]);

It passes and prints out:

2018-05-27 17:27:38.823 size-point-encoding[25395:25395] {_NSPoint=dd}
{_NSSize=dd} {_NSPoint=dd}

I''m annoyed at how I did not notice that I did use CGSize. I will
introduce support for NSSize/CGSize.

Thanks!

On Mon, May 21, 2018 at 12:53 AM Fred Kiefer <fredkie...@gmx.de> wrote:

> I added a bit of code in base that allows to use NSValue objects for size
> and point with methods for the other type. This is a bit closer to the
> Cocoa behaviour but will require more tweaking to have it fully correct. It
> will at least allow you to run this test code again.
>
> > Am 20.05.2018 um 16:02 schrieb Fred Kiefer <fredkie...@gmx.de>:
> >
> > I spend some time to understand this issue. But to be honest it took me
> more time to understand why this ever worked :-)
> >
> > The problem here is that base uses two different ways to provide
> concrete subclasses for NSValue. One being GSValue, which supports generic
> data and the other mechanism is to have a specific subclass for types like
> NSPoint and NSSize. For the later base only generates specific methods for
> that types. Resulting in different classes for NSPoint and NSSize, which
> are incompatible although they have the same underlying data size.
> > In your demo application that animation for shadowOffset tries to set
> the offset size with a suitable default value of class GSSizeValue. But the
> code in GSObjCSetVal only compares the type information without looking at
> the type names. That way NSSize is regarded as the same as NSPoint and the
> pointValue get executed, resulting in the error you reported. Either
> GSObjCSetVal has to be more careful and use a check for the actual type
> first. Or we need to make the NSValue subclasses more general.
> >
> > But why did it work before? Most likely because at that time CGSize and
> CGPoint, where different from NSSize and NSPoint so we did not get the
> specific optimisation in NSValue.
> >
> > Hope this helps,
> > Fred
> >
> >> Am 20.05.2018 um 14:03 schrieb Ivan Vučica <i...@vucica.net>:
> >>
> >> Hi,
> >>
> >> Pretty much all Core Animation demos are currently broken under GNUstep
> with a variation on the following:
> >>
> >> 2018-05-20 12:54:25.464 QuartzCoreDemo[13476:13476] Problem posting
> notification:  NAME:NSInvalidArgumentException
> REASON:[GSSizeValue-pointValue] should be overridden by subclass INFO:(null)
> >>
> >> CA is accessing -pointValue method if it determines that the passed
> NSValue matches the -objCType of NSPoint. It does not check for size values.
> >>
> >> Clearly, sometimes it is trying to interpolate size values, which will
> match the signature and it will incorrectly attempt to access -pointValue
> which is then not implemented by GSSizeValue. I am not sure where might it
> be interpolating size values, but it seems to be doing so. (Alternative bug
> is that NSValue is incorrectly ingesting points as sizes, then complaining
> when the point provided is being interpreted as a point. I can try checking
> this later.)
> >>
> >> I cannot check -respondsToSelector: because the class /does/ in fact
> respond to -pointValue; it just throws an exception.
> >>
> >> Adding a try/catch in this kind of situation would make for some very
> poor code hygiene, in my opinion.
> >>
> >> - Is NSValue supposed to be a class cluster like this? (Not on Mac at
> this time, can't check.)
> >> - Is there a way out?
> >> - Would it make sense to extend GSSizeValue and add -pointValue to it?
> (They're both 2d vectors.)
> >>
> >> Thanks
> >> ___
> >> Gnustep-dev mailing list
> >> Gnustep-dev@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> >
> >
> > ___
> > Gnustep-dev mailing list
> > Gnustep-dev@gnu.org
> > https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

CA broken; how do I differentiate NSValues for size and point?

[Ivan Vučica]

Hi,

Pretty much all Core Animation demos are currently broken under GNUstep
with a variation on the following:

2018-05-20 12:54:25.464 QuartzCoreDemo[13476:13476] Problem posting
notification:  NAME:NSInvalidArgumentException
REASON:[GSSizeValue-pointValue] should be overridden by subclass INFO:(null)

CA is accessing -pointValue method if it determines that the passed NSValue
matches the -objCType of NSPoint. It does not check for size values.

Clearly, sometimes it is trying to interpolate size values, which will
match the signature and it will incorrectly attempt to access -pointValue
which is then not implemented by GSSizeValue. I am not sure where might it
be interpolating size values, but it seems to be doing so. (Alternative bug
is that NSValue is incorrectly ingesting points as sizes, then complaining
when the point provided is being interpreted as a point. I can try checking
this later.)

I cannot check -respondsToSelector: because the class /does/ in fact
respond to -pointValue; it just throws an exception.

Adding a try/catch in this kind of situation would make for some very poor
code hygiene, in my opinion.

- Is NSValue supposed to be a class cluster like this? (Not on Mac at this
time, can't check.)
- Is there a way out?
- Would it make sense to extend GSSizeValue and add -pointValue to it?
(They're both 2d vectors.)

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

State of new abi

[Ivan Vučica]

Hi,

to confirm, is current libobjc2 master incompatible with current gnustep-base 
master?

Stjepan has been building GNUstep using the following instructions:
  http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
and I remembered that the failure could be due to the development of the new 
abi.

I powered on the laptop during my vacation, took a quick look, and told him to 
git checkout 1.9. This seems to have worked.

Is this intentional?

Presumably -base newabi branch is not ready to be merged yet — but should 
libobjc2’s master branch be using the new abi then?

I think that’s fine, apart from breaking scripts that build GS from head. 
Travis CI is also erroring out:
  https://travis-ci.org/gnustep/libs-base

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

Re: New ABI NSConstantString

[Ivan Vučica]

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.

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

Re: New ABI NSConstantString

[Ivan Vučica]

Thank you, this was very informative!

On Thu, Apr 5, 2018 at 6:41 PM, David Chisnall
<gnus...@theravensnest.org> wrote:
> On 5 Apr 2018, at 17:01, Ivan Vučica <i...@vucica.net> wrote:
>>
>> Layman question: does it make sense to optimize for space, too, and have a 
>> smaller structure for tiny constant strings?
>
> With the new ABI, we get much better deduplication across compilation units 
> for selectors and protocols, which should extend to constant strings.
>
> At run time, on 64-bit platforms, we generate GSTinyString instances, which 
> are 64 bits and are hidden inside a pointer.  I’m tempted to make the 
> compiler generate those directly.
>
>> For 32bit ptrs and longs, this would be 20 bytes without the string itself. 
>> I don't think that's a lot, but I thought I'd ask.
>
> 20 bytes isn’t too bad, 36 (for 64-bit platforms) is a bit more.  On a 
> CHERI-like platform, it grows to 52 bytes, which starts to feel a bit 
> excessive.
>
> The absolute minimum structure is an isa pointer immediately followed by the 
> character data, with a null terminator.  That’s not a great idea, because the 
> isa pointer needs to be mutable, which would make the constant string also 
> accidentally mutable.
>
> The next smallest would be an isa pointer and a null-terminated string 
> pointer, so 8 / 16 / 32 bytes on the respective architectures.
>
> The cost of recomputing the hash is sufficiently expensive that it’s probably 
> worth using at least the 28 bits that we provide already for string hashes.
>
> I’ve done some measurements in -base.  In the compiled binary, we have a 
> total of 84976 bytes of strings, in 3307 strings, so an average of just under 
> 26 bytes per string, so 36 bytes of overhead seems quite a lot, and even 20 
> is quite noticeable.  If we exclude strings of 8 or fewer characters, this 
> gives us 81637 bytes in 2586 strings, so an average length of just under 32 
> bytes, so 36 bytes is still more than 100% overhead and adds up to about 90KB 
> in the final binary.
>
> With the current encoding, each constant string is 24 bytes, so that adds up 
> to about 60KB (excluding the string data itself) on 64-bit platforms.  That’s 
> about 0.5% of the total binary size, so I’m not too worried about making it 
> bigger.  Even making it 80KB is a lot of overhead per string (roughly 100%), 
> but isn’t that much of the total binary size.
>
>
> David
>

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

Re: New ABI NSConstantString

[Ivan Vučica]

Layman question: does it make sense to optimize for space, too, and have a
smaller structure for tiny constant strings?

For 32bit ptrs and longs, this would be 20 bytes without the string itself.
I don't think that's a lot, but I thought I'd ask.

On Thu, Apr 5, 2018, 16:25 David Chisnall  wrote:

> On 1 Apr 2018, at 14:06, Richard Frith-Macdonald <
> richard.frith-macdon...@theengagehub.com> wrote:
> >
> >
> > 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).
>
> How about this:
>
> struct {
> // Class pointer
> id isa;
> // Pointer to the buffer.  ro_data section, so immutable.
> NULL-terminated
> const char *data;
> // Number of characters, not including the null terminator
> long count;
> // Number of bytes in the encoding, not including the null
> terminator.
> long length;
> // Murmur 3 hash
> uint32_t hash
> // Flags bitfield:
> // Low 2 bits, enum with values:
> //   0: ASCII string
> //   1: UTF-8 but not ASCII string
> //   2: UTF-16 string
> //   3: Reserved for future encodings
> // (1<<2): has mumur3 hash
> // (1<<3) to (1<<15): Reserved for future compiler-defined flags
> // (1<<16) to (1<<31): Reserved for use by the constant string
> class
> }
>
> I think that this should give everything that we need, plus room for easy
> future expansion.
>
> David
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GSoC candidate introduction / ideas

[Ivan Vučica]

(I'm talking to Stjepan now; yes, this is a duplicate, accidentally
sent from the wrong email address. Please ignore this thread.)

On Thu, Mar 22, 2018 at 2:41 PM, Stjepan Brkić <stjepan.br...@fer.hr> wrote:
> Hi!
>
> My name is Stjepan Brkić and I’m a undergrad computer science student at
> University of Zagreb (Croatia) / FER.
> I’m seriously considering applying to this years GSoC with GNUStep as the
> project I’d like to work on.
>
>
> I would like to thank Ivan Vučica for talking me into this, we talked about
> the project already and I have a basic understanding
> of the project and stuff that needs work.
>
> I have reasonable experience with languages and technologies that are
> relevant -  C, OpenGL, Linux/UNIX, and Objective-C as the last addition to
> the list.
>
> Anyways, I checked out the GSoC Ideas List , as well as some Wishlists and I
> have a rough list of candidate tasks which I’d like to work on.
> Most of them are focused around Core Animation.
>
> I was just wondering if you have any additional tips,tricks,questions or
> wishes regarding GNUStep and GSoC.
>
> Cheers,
> Stjepan
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>

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

Re: NSXMLNode ivar type

[Ivan Vučica]

Got it.

I thought it was more exposed.
On Tue 20 Mar 2018 at 16:14 David Chisnall <gnus...@theravensnest.org>
wrote:

> On 20 Mar 2018, at 15:36, Ivan Vučica <i...@vucica.net> wrote:
> >
> > On Tue 20 Mar 2018 at 14:51 David Chisnall <gnus...@theravensnest.org>
> wrote:
> >> Hello the list,
> >>
> >> I am working on the new ObjC ABI and one of the changes I have made is
> to include the type encoding in the ivar offset variable.  This protects
> against type confusion by causing linker failures when an instance variable
> is referenced with the wrong type (which can happen if it’s in a library
> that changes and someone forgets to bump the SONAME).
> >>
> >> Unfortunately, I have found that -base doesn’t build because it uses
> some complex preprocessor logic to change the type of NSXMLNode’s node ivar
> depending on which subclass you are using.  This is quite dangerous
> because, although the types have a common prefix, the version used in the
> root is not a prefix of the others and so it’s possible for type confusion
> if someone modifies NSXMLNode without realising how the subclasses use this.
> >>
> >> Does anyone object if I commit a patch that turns this into a union?
> >>
> >> David
> >>
> > Please bump the SONAME while at it :)
>
> Why?  It’s an private and hidden ivar.  In the fragile ABI, it’s in the
> secret ‘internal’ structure and not ABI-visible, in the non-fragile ABI
> it’s in a class extension and so not externally visible.
>
> David
>
>
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: NSXMLNode ivar type

[Ivan Vučica]

On Tue 20 Mar 2018 at 14:51 David Chisnall 
wrote:

> Hello the list,
>
> I am working on the new ObjC ABI and one of the changes I have made is to
> include the type encoding in the ivar offset variable.  This protects
> against type confusion by causing linker failures when an instance variable
> is referenced with the wrong type (which can happen if it’s in a library
> that changes and someone forgets to bump the SONAME).
>
> Unfortunately, I have found that -base doesn’t build because it uses some
> complex preprocessor logic to change the type of NSXMLNode’s node ivar
> depending on which subclass you are using.  This is quite dangerous
> because, although the types have a common prefix, the version used in the
> root is not a prefix of the others and so it’s possible for type confusion
> if someone modifies NSXMLNode without realising how the subclasses use this.
>
> Does anyone object if I commit a patch that turns this into a union?
>
> David


Please bump the SONAME while at it :)

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

Re: Out-of-tree builds?

[Ivan Vučica]

On Tue 20 Mar 2018 at 15:18 David Chisnall 
wrote:

> On 20 Mar 2018, at 15:03, Richard Frith-Macdonald <
> richard.frith-macdon...@theengagehub.com> wrote:
> >
> >
> >
> >> 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.
>
> It has nothing to do with disk space, it has to do with my sanity.  With
> libobjc2 (and LLVM, Clang, and most other projects I use), I have a single
> checkout of the code and build directories for release and debug versions
> (and some more exotic ones for cross-compilation or testing newer
> compilers).  If I find a bug in my release build, I can build exactly the
> same sources in a debug config by changing to the correct directory and
> typing ‘ninja’.  If I think I have fixed the bug, I can change to the
> release directory, rebuild there, and see if it’s gone away in the original
> place.
>
> Because they are in separate directories, there is no chance of pollution
> between them and I get incremental rebuilds of all configurations when I
> change any source.  This is invaluable with cross-compiling, if I want to
> test a change on x86, ARM and MIPS, or even just 32- and 64-bit x86
> versions.
>
> And, as an aside, I can often stick the build directories in faster but
> less reliable storage (I don’t care if I lose my build directories if the
> power goes out, I do care if I lose my source directories.  I want my
> source directories to be spread across disks in a RAID configuration with
> redundancy, but I’m happy for my build directories to have no redundancy
> and fewer syncs, so infrequently-written files stay in RAM).
>
> Oh, and for the CMake ones I also typically have a build directory that
> uses XCode so that I can use the static analyser and refactoring tools from
> there, rather than via the command line.


Overlayfs or one of its equivalents?

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

Re: NSAutoreleasePool drain/dealloc

[Ivan Vučica]

On Tue, Mar 6, 2018 at 5:24 PM, Richard Frith-Macdonald <
richard.frith-macdon...@theengagehub.com> wrote:

>
>
> 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.
>

Thank you! I guess I never read that part of the NSAutoreleasePool docs.


> 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).
>

That's what I assumed it was doing: releasing the members of the pool,
while not releasing the pool itself.

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

NSAutoreleasePool drain/dealloc

[Ivan Vučica]

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?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Wayland backend status update & help appeal

[Ivan Vučica]

On Wed, Feb 21, 2018, 09:45 Richard Frith-Macdonald <
richard.frith-macdon...@theengagehub.com> wrote:

>
>
> > - 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?
>

It might be, but that should not affect whether content is drawn on screen,
just how the window behaves? I mean, events seem to be captured, just
there's no content.

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

Wayland backend status update & help appeal

[Ivan Vučica]

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?

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

Dev meeting 2018?

[Ivan Vučica]

Hi,

Meeting with Richard and Fred at FOSDEM was good.

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.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

On Mon, Jan 29, 2018 at 10:32 AM, Richard Frith-Macdonald
 wrote:
>> 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?

Also sounds like it wouldn't be very useful with OS X code unless all
headers and code were stripped of protocols before processing with Coverity.

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

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

On Wed, Jan 24, 2018 at 11:56 PM, Ivan Vučica <i...@vucica.net> wrote:
> On Mon, Jan 22, 2018 at 10:23 PM, Fred Kiefer <fredkie...@gmx.de> 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.

>> 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.
>>
>> Fred
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

Re: Coverity Scan for GNUstep?

[Ivan Vučica]

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.

> 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.
>
> Fred
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev

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

Re: [IMPORTANT] Ideas for Summer of Code 2018

[Ivan Vučica]

Daniel,

did you come up with a blurb?

Any preferences for meeting day? Wed and Thu evenings UTC are taken for me.

On Thu, Jan 18, 2018 at 1:25 AM, Ivan Vučica <i...@vucica.net> wrote:
> On Mon, Jan 15, 2018 at 7:05 AM, Daniel Ferreira (theiostream)
> <bnm...@gmail.com> wrote:
>> On Sun, Jan 14, 2018 at 5:55 PM, Ivan Vučica <i...@vucica.net> wrote:
>>> I don't think that's inappropriate as far as GNUstep is concerned.
>>
>> By inappropriate I mean that if the student wanted to work on anything
>> that's not GS+WebKit (or even that actually) my help would be very
>> limited – they would probably have to rely on Fred, you and others,
>> much like I had to in order to get work done.
>
> While I would prefer to mentor someone mainly if they do CA-related
> work, I am willing to consider helping out on a per-project basis.
>
> It is perfectly valid not to accept a proposal if we believe we can't
> mentor it well.
>
>>> Can you write a blurb that we can ask GNU representatives to put on
>>> the ideas page? See summer-of-code mailing list archive for examples.
>>
>> For GS+WebKit? Definitely. I should have something this week still.
>
> Thanks!
>
>>
>>> Let's sit one weekend to help me reproduce your build steps. (I don't
>>> recall at this point; maybe you left good enough documentation that I
>>> could do it myself, but maybe it's better if we sit down and make this
>>> easily reproducible.)
>>
>> Sure! Can we set this up sometime next week?
>
> As in, week of 22nd Jan? Sure.

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