Re: Releases

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 jo

Re: Releases

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,

Re: Releases

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, b

GNUstep devs on FOSDEM 2023?

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

Re: Releases

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

Re: Releases

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

ANN: GNUstep GUI Backend 0.29.0

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?

ANN: GNUstep GUI Library 0.29.0

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?

ANN: GNUstep Base 1.28.0

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?

ANN: GNUstep Makefile Package 2.9.0

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?

Re: GNUstep releases this month?

gh 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

Re: GNUstep releases this month?

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 distri

Re: GNUstep releases this month?

, 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-Macdon

Re: base: running make in Documentation subdir broken

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 d

Re: base: running make in Documentation subdir broken

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 wil

base: running make in Documentation subdir broken

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

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

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

Re: GNUstep releases this month?

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

Rotating the dev GPG key

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

Re: GNUstep releases this month?

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 t

Where do we ingest bugreports?

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

Re: GNUstep releases this month?

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

Re: GNUstep releases this month?

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 > &g

Re: GNUstep releases this month?

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

Re: GNUstep releases this month?

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

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

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

Re: GNUstep releases this month?

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

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

Re: GNUstep releases this month?

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

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

o 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:1

Re: GNUstep releases this month?

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

Re: GNUstep releases this month?

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

GNUstep releases this month?

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

Re: Building GNUstep for Windows using Clang

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

Re: CMake 3.16

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

Re: Next GNUstep release

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

Re: Next GNUstep release

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

Re: Next GNUstep release

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

Re: Changelog and git log hygiene

y 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! >>

Re: Next GNUstep release

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

Re: Changelog and git log hygiene

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

Changelog and git log hygiene

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

Re: Next GNUstep release

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

Re: Next GNUstep release

ich...@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 f

RE: Re: Next GNUstep release

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>

Re: Next GNUstep release

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

Re: Next GNUstep release

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

Re: Building GNUstep for Windows using Clang

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:]

Re: Next GNUstep release

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

RE: GORM usability enhancements

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: [ML] Re: Hosting of gnustep.org

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.

Re: Occasional NSInternalInconsistencyException

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.

Re: Gitflow proposal

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

Re: Gitflow proposal

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 fi

Re: Embedded blocks...

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.

Are releases needed?

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

NSUbiquitousKeyValueStore

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:

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

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

Re: Commit process to source tree on github

t 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 /ever

Re: Commit process to source tree on github

>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

Re: Building on android....

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

Re: Building on android....

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 >

Re: Building on android....

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 Gr

Re: Building on android....

ibraries 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 th

Re: Building on android....

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, Iva

Re: Building on android....

.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

Re: Building on android....

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

Re: Building on android....

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,

Re: ANN: GNUstep Base 1.26.0

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

Re: ANN: GNUstep Base 1.26.0

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

Re: Cutting a release?

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

Re: Cutting a release?

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 t

Re: Cutting a release?

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

Re: Cutting a release?

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

Cutting a release?

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

Re: libs-quartzcore won't build

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

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

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

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

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

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

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

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

epro: 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

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

t 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}; >

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

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

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

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

State of new abi

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

Re: New ABI NSConstantString

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

Re: New ABI NSConstantString

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 &g

Re: New ABI NSConstantString

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

Re: GSoC candidate introduction / ideas

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

Re: NSXMLNode ivar type

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

Re: NSXMLNode ivar type

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

Re: Out-of-tree builds?

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

Re: NSAutoreleasePool drain/dealloc

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

NSAutoreleasePool drain/dealloc

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:

Re: Wayland backend status update & help appeal

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

Wayland backend status update & help appeal

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:

Dev meeting 2018?

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

Re: Coverity Scan for GNUstep?

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

Re: Coverity Scan for GNUstep?

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 i

Re: Coverity Scan for GNUstep?

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

Re: [IMPORTANT] Ideas for Summer of Code 2018

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:

  1   2   3   4   5   >