Re: Next GNUstep release

Thank you, Ivan, and everyone who contributed to the new versions! Congratulations! Cheers, Josh On Apr 13, 2020, at 8:13 PM, Ivan Vucica wrote: And releases are now done!

Re: Next GNUstep release

On Sun, Apr 12, 2020 at 12:19:53PM -0400, Gregory Casamento wrote: > What is the status of the current release? I hope this ChangeLog > discussion is not holding things up. And releases are now done!

Re: Next GNUstep release

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

Re: Next GNUstep release

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

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

Hi, Ivan Vučica wrote: > 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: >>

Re: Next GNUstep release

Hi! Richard Frith-Macdonald wrote: > What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, > in that we could auto-generate ChangeLog entries from the repository, either > by an automated commit hook or (assuming that's not easy to do readily), > using a script to get

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

On 06/04/2020 12:56, Richard Frith-Macdonald wrote: Yes, thanks to Ivan. I have spent some time thinking about this, and while in the past I've argued against dropping ChangeLog (it's more convenient than the git logs, and of course is there for peple who download tarballs etc and don't have

Re: Next GNUstep release

Richard, On Mon, Apr 6, 2020 at 7:56 AM Richard Frith-Macdonald < rich...@frithmacdonald.me.uk> wrote: > > > > On 6 Apr 2020, at 09:53, David Chisnall > wrote: > > > > I second that, thank you Ivan, but Fred your proposed solution is going > to add more barriers to entry. > > > > ChangeLog

Re: Next GNUstep release

> On 6 Apr 2020, at 09:53, David Chisnall wrote: > > I second that, thank you Ivan, but Fred your proposed solution is going to > add more barriers to entry. > > ChangeLog files made sense when people were submitting patches on the mailing > list and distributing code in tarballs. > >

Re: Next GNUstep release

I second that, thank you Ivan, but Fred your proposed solution is going to add more barriers to entry. ChangeLog files made sense when people were submitting patches on the mailing list and distributing code in tarballs. They were slightly anachronistic when CVS became standard for F/OSS

Re: Next GNUstep release

Thank you Ivan for the great work you are doing here. And I promise to try to lighten the work on the next release by making sure every pull request gets it proper ChangeLog entry. Fred > Am 05.04.2020 um 22:42 schrieb Ivan Vučica : > > I have cut new releases: > - gnustep-make 2.8.0 > -

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

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 >

Re: Next GNUstep release

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 <

Re: Next GNUstep release

> On 3 Apr 2020, at 01:26, Ivan Vučica wrote: > > It’s mainly up to the maintainer to decide to release including whether > things like that NSURLComponents change are risky. I suppose I should perhaps > get a final thumbs up from Richard (or you) regarding -base, but otherwise > it’s just

RE: Re: Next GNUstep release

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

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

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

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

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

Re: Next GNUstep release

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

Re: Next GNUstep release

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

Re: Display issues (Was: Next GNUstep release)

Hi Sergii, Sergii Stoian wrote: You forgot to mention one important detail. This problem only shows up with 16 bit depth. Most likely this happens as some data structure that holds the intermediate pixel information rounds the line length to a multiple of 8, 16, 32 or even 64 and we use one

Re: Next GNUstep release

Hi! Ivan Vučica wrote: - 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... Me

Re: Display issues (Was: Next GNUstep release)

> On Feb 28, 2020, at 13:17, Fred Kiefer wrote: > > > >> Am 28.02.2020 um 11:37 schrieb Riccardo Mottola : >> Sergii Stoian wrote: >>> On Feb 27, 2020, at 23:09, Riccardo Mottola wrote: before a release, I would like these issues to find a solution. -

Re: Display issues (Was: Next GNUstep release)

Hi, > On Feb 28, 2020, at 12:37, Riccardo Mottola > wrote: > > Hi, > > Sergii Stoian wrote: >> Hi, >> >>> On Feb 27, 2020, at 23:09, Riccardo Mottola >>> wrote: >>> >>> Hi, >>> >>> before a release, I would like these issues to find a solution. >>> >>> - understand why we don't work

Re: Display issues (Was: Next GNUstep release)

> Am 28.02.2020 um 11:37 schrieb Riccardo Mottola : > Sergii Stoian wrote: >> >>> On Feb 27, 2020, at 23:09, 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

Display issues (Was: Next GNUstep release)

Hi, Sergii Stoian wrote: Hi, On Feb 27, 2020, at 23:09, Riccardo Mottola wrote: Hi, 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 Could you

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

Hi, > On Feb 27, 2020, at 23:09, Riccardo Mottola > wrote: > > Hi, > > 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 Could you please be

Re: Next GNUstep release

Hi, 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 - understand/fix/workaround the libobjc2 which impede me to test current GNUstep on any FreeBSD

Re: Next GNUstep release

Hi, > On Feb 11, 2020, at 15:14, Sergii Stoian wrote: > > Hi Fed, > > On Tue, Feb 11, 2020 at 10:09 AM Fred Kiefer > wrote: > Dear GNUsteppers, > > I would like to schedule a shared new release for the core GNUstep packages > (make, base, gui, back) around the end

Re: Next GNUstep release

Hi! Fred Kiefer wrote: I would like to schedule a shared new release for the core GNUstep packages (make, base, gui, back) around the end of March. We have a lot of excellent new features and it would be great to bring those out to more distributions and users. We are a bit later than in

Re: Next GNUstep release

Hi Fed, On Tue, Feb 11, 2020 at 10:09 AM Fred Kiefer wrote: > Dear GNUsteppers, > > I would like to schedule a shared new release for the core GNUstep > packages (make, base, gui, back) around the end of March. We have a lot of > excellent new features and it would be great to bring those out

Re: Next GNUstep release

Fred, On Tue, Feb 11, 2020 at 3:08 AM Fred Kiefer wrote: > Dear GNUsteppers, > > I would like to schedule a shared new release for the core GNUstep > packages (make, base, gui, back) around the end of March. We have a lot of > excellent new features and it would be great to bring those out to

Next GNUstep release

Dear GNUsteppers, I would like to schedule a shared new release for the core GNUstep packages (make, base, gui, back) around the end of March. We have a lot of excellent new features and it would be great to bring those out to more distributions and users. We are a bit later than in previous

Re: Next GNUstep release?

On 9 Nov 2011, at 19:53, Fred Kiefer wrote: So far there has been only Riccardo's reply whether there should be a release at all. Those this mean we shouldn't do a shared release now? Then we could thing about just a gui/back release, which shoudl make Riccardo happy. I like your idea of

Re: Next GNUstep release?

Am Thu, 10 Nov 2011 09:33:08 + schrieb Richard Frith-Macdonald rich...@tiptree.demon.co.uk : I'm not actually clear on what Riccardo wants here , so I won't try to comment on other alternatives, but it seems to me we want to get things back in sync properly ASAP. yes. -- mit

Re: Next GNUstep release?

Just a small comment. On Wed, Nov 9, 2011 at 19:13, Riccardo Mottola riccardo.mott...@libero.itwrote: We are not Apple, nor Microsoft nor whatever. We value freedom, which has many aspects. How tedious. It works both ways: bigger companies can sometimes afford supporting a somewhat wider

Re: Next GNUstep release?

On 9 Nov 2011, at 05:32, Gregory Casamento wrote: As I remember it, we agreed on GCC 4.0 and later. Yup, the rationale was that 2.9x - 3.x was where most of the platforms were dropped. Excluding 3.x gives us a more modern compiler with better language support and doesn't lose us any

Re: Next GNUstep release?

Hi, I don't remember about this and agreeing on that. We spoke about 2.95 because it had serious limitations and limited c99 compatibility which was fine to drop and I agreed on that because the inconvenience of maintaining it outweighed the benefits eventually. I'd be against dropping 3.x

Re: Next GNUstep release?

On 9 Nov 2011, at 13:15, Riccardo Mottola wrote: 3.2 especially was essentially the second best portable option after 2.95. Portability of gcc got quite worse after 3.4. Examples please. What platforms: - Are supported by GCC 3.2 - Are not supported by GCC 4.0 or Clang - Are supported by

Re: Next GNUstep release?

Hi Examples please. What platforms: - Are supported by GCC 3.2 - Are not supported by GCC 4.0 or Clang - Are supported by GNUstep? Don't twist the question. It is not a matter of which platform could be supported by a newer version of gcc. We are not Apple or some commercial company, oh

Re: Next GNUstep release?

On 9 Nov 2011, at 12:56, David Chisnall wrote: On 9 Nov 2011, at 05:32, Gregory Casamento wrote: As I remember it, we agreed on GCC 4.0 and later. Yup, the rationale was that 2.9x - 3.x was where most of the platforms were dropped. Excluding 3.x gives us a more modern compiler with

Re: Next GNUstep release?

On 9 Nov 2011, at 18:13, Riccardo Mottola wrote: Examples please. What platforms: - Are supported by GCC 3.2 - Are not supported by GCC 4.0 or Clang - Are supported by GNUstep? Don't twist the question I'm not twisting the question. Supporting older compilers increases the

Re: Next GNUstep release?

Hi Fred, I agree we should do a gui release as soon as possible - if I tested correctly, the latest gui release 0.20.0 doesn't work the the latest base, 1.23.0. I would like to get the changes you suggest in (font rewrite and filter services), but on the other hand, I think doing a release soon

Re: Next GNUstep release?

To scale this discussion down a bit. The only thing that currently stops you from using an older version of gcc. Is the GCC_VERSION variable in the Version file of base. I am not aware of any specific change that would deliberately break older compilers. It is just that we don't officially

X style offset [Was: Next GNUstep release?]

On 09.11.2011 20:05, Eric Wasylishen wrote: I agree we should do a gui release as soon as possible - if I tested correctly, the latest gui release 0.20.0 doesn't work the the latest base, 1.23.0. I would like to get the changes you suggest in (font rewrite and filter services), but on the other

Re: Next GNUstep release?

Hi, this sounds good and sensible. I don't have any blocking issues with the new backend, I will do further tests this weekend though. Only under certain operationswe see flickering and this may be the hint for the slowdowns. (try a full-screen slide-show in LaternaMagica.. sometimes it

Re: Next GNUstep release?

Hi, Fred Kiefer wrote: To scale this discussion down a bit. The only thing that currently stops you from using an older version of gcc. Is the GCC_VERSION variable in the Version file of base. I am not aware of any specific change that would deliberately break older compilers. It is just that

Next GNUstep release?

For over a month I have been suggesting a new release of all GNUstep code components (perhaps including Gorm as well), but got no reply at all. Many of us have been pretty busy fixing the bugs Julian reported and there is still plenty to do in this area. Anyway I would like to start a

Re: Next GNUstep release?

Hi, I think it is a good idea to release guiback. Things are piling up and diverging from base, so they are indeed needed. I am feeling some itches lately though, but they can surely be solved. The new cairo surface usage is not prefect, but it is quite good, if some of the performance and

Re: Next GNUstep release?

As I remember it, we agreed on GCC 4.0 and later. On Tuesday, November 8, 2011, Riccardo Mottola r...@gnu.org wrote: Hi, I think it is a good idea to release guiback. Things are piling up and diverging from base, so they are indeed needed. I am feeling some itches lately though, but they can

Re: Next GNUstep release

This sounds fine to me. On Wed, Mar 9, 2011 at 3:37 AM, Richard Frith-Macdonald rich...@tiptree.demon.co.uk wrote: On 7 Mar 2011, at 21:09, Fred Kiefer wrote: GNUstep base is making excellent progress in the moment, still I would suggest that we keep to our original plan of making a new

Re: Next GNUstep release

On 7 Mar 2011, at 21:09, Fred Kiefer wrote: GNUstep base is making excellent progress in the moment, still I would suggest that we keep to our original plan of making a new release soon. Yes ... though I'm not sure exactly when soon is. Certainly this month would be good. For this we

Next GNUstep release

GNUstep base is making excellent progress in the moment, still I would suggest that we keep to our original plan of making a new release soon. For this we would need a few days of code freeze to allow for testing of a stable code base. What about having another week of happy hacking and then a

Re: Next GNUstep release

On Mar 7, 2011, at 2:09 PM, Fred Kiefer wrote: GNUstep base is making excellent progress in the moment, still I would suggest that we keep to our original plan of making a new release soon. For this we would need a few days of code freeze to allow for testing of a stable code base. What

Re: Next GNUstep release?

Richard made a final change that allows us to continue doing a gui/back release. At least as far as I know, we have less known issues then for previous releases. Fred Am 08.05.2010 18:22, schrieb Adam Fedor: I plan on making a release of make and base by tomorrow. Please let me know when I

Re: Next GNUstep release?

OK, I'll make a gui/back release early tomorrow. On May 9, 2010, at 5:57 AM, Fred Kiefer wrote: Richard made a final change that allows us to continue doing a gui/back release. At least as far as I know, we have less known issues then for previous releases.

Re: Next GNUstep release?

Great! Could everybody please stop committing to these two projects until then? I am planing to have another release of GNUstep gui this summer so don't worry, any changes that didn't make it into this release wont be delayed as long as they were this time. To start planing for that next release

Re: Next GNUstep release?

I plan on making a release of make and base by tomorrow. Please let me know when I can make a release of gui/back as well. On May 4, 2010, at 9:50 AM, Gregory Casamento wrote: Fred, I'm still trying to reproduce it, but even so I don't believe it's a problem with GUI or anything that

Re: Next GNUstep release?

Riccardo, On Wed, May 5, 2010 at 6:51 PM, Riccardo Mottola mul...@ngi.it wrote: Hi, Fred Kiefer wrote: Thank you for the bug report. For me this isn't a show stopper for the next GNUstep release. It only affects Windows and mostly the WinUX theme. It may be a show stopper for that theme

Re: Next GNUstep release?

Hi, Fred Kiefer wrote: Thank you for the bug report. For me this isn't a show stopper for the next GNUstep release. It only affects Windows and mostly the WinUX theme. It may be a show stopper for that theme, but we already decided not to make it the default theme on Windows. Agreed

Re: Next GNUstep release?

Thank you for the bug report. For me this isn't a show stopper for the next GNUstep release. It only affects Windows and mostly the WinUX theme. It may be a show stopper for that theme, but we already decided not to make it the default theme on Windows. From my side the only know open issue

Re: Next GNUstep release?

On May 4, 2010, at 2:44 AM, Fred Kiefer wrote: Thank you for the bug report. For me this isn't a show stopper for the next GNUstep release. It only affects Windows and mostly the WinUX theme. It may be a show stopper for that theme, but we already decided not to make it the default theme

Re: Next GNUstep release?

a show stopper for the next GNUstep release. It only affects Windows and mostly the WinUX theme. It may be a show stopper for that theme, but we already decided not to make it the default theme on Windows. From my side the only know open issue is still the Gorm segmentation fault I get from

Re: Next GNUstep release?

Hi, If these exceptions were Uncaught exception NSInvalidArgumentException, reason: NSObject(class) does not recognize type the issue is fixed now (the latest base changes had inadvertently made GSObjCAllSubclassesOfClass return all superclasses of the class). The problem on Linux/x86 is

Re: Next GNUstep release?

Riccardo Mottola wrote: On my laptop today I cannot start *any* application even after a full, clean build of core. On my letux Grr throws exceptions. On both machines things worked enough to be of daily use about 1-2 months ago... If these exceptions were Uncaught exception

Re: Next GNUstep release?

Fred, I've been testing for a while with vairous nibs in Gorm since you made the changes to nib loading and haven't found any ill effects. Are you aware of any issues I may have overlooked? GC On Fri, Apr 30, 2010 at 4:39 PM, Gregory Casamento greg.casame...@gmail.com wrote: Fred, On Fri,

Re: Next GNUstep release?

I think we should decide what to do with the planed GNUstep release. There hasn't been much progress over the last week. More bugs got reported than fixed over that time. We can either make a release now, with a lot of known issues, even some that weren't there a few weeks ago. Or delay the

Re: Next GNUstep release?

Fred, On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de wrote: I think we should decide what to do with the planed GNUstep release. There hasn't been much progress over the last week. More bugs got reported than fixed over that time. We can either make a release now, with a lot

Re: Next GNUstep release?

Hi, There hasn't been much progress over the last week. More bugs got reported than fixed over that time. We can either make a release now, with a lot of known issues, even some that weren't there a few weeks ago. Or delay the release indefinitely. Not fixed doesn't mean that it is not

Re: Next GNUstep release?

Am 30.04.2010 um 22:39 schrieb Gregory Casamento: Fred, On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de wrote: I think we should decide what to do with the planed GNUstep release. There hasn't been much progress over the last week. More bugs got reported than fixed over

Re: Next GNUstep release?

Yes. On Friday, April 30, 2010, Lars Sonchocky-Helldorf lars.sonchocky-helld...@hamburg.de wrote: Am 30.04.2010 um 22:39 schrieb Gregory Casamento: Fred, On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de wrote: I think we should decide what to do with the planed GNUstep

Re: Next GNUstep release?

Gregory Casamento escribió: An issue arises when the app doesn't bring up a window by default. I'm concerned that, if we bring up a window/menu in the absence of a window that the framework is making assumptions about what the developer wants. I think the developer must decide whether to

Re: Next GNUstep release?

Hi Fred! Mhm, I already did all of that yesterday... But there is more to do. We now need to change all the places where we load NIB (or Gorm or XIB) files to free the top level objects. The code is a lot cleaner now, but as far as memory leaks are concerned we are almost back to square

Re: Next GNUstep release?

Am 29.03.2010 20:47, schrieb Fred Kiefer: But there is more to do. We now need to change all the places where we load NIB (or Gorm or XIB) files to free the top level objects. The code is a lot cleaner now, but as far as memory leaks are concerned we are almost back to square one. We now leak

Re: Next GNUstep release?

Am 30.03.2010 08:45, schrieb Wolfgang Lux: Mhm, I already did all of that yesterday... But there is more to do. We now need to change all the places where we load NIB (or Gorm or XIB) files to free the top level objects. The code is a lot cleaner now, but as far as memory leaks are concerned

Re: Next GNUstep release?

Fred Kiefer wrote: Just imagine an NSDocument NIB file with plenty of top level objects that go unhandled. What should we do in this case? Try to be clever in our own NIB loading code? E.g. provide an array for the top level objects and free them later on? Most likely this isn't what Cocoa is

Re: Next GNUstep release?

Riccardo, On Mon, Mar 29, 2010 at 5:06 PM, Riccardo Mottola mul...@ngi.it wrote: [ SNIP ] Although I generally agree with leaving the default theme as is on Unix, where we can theoretically strive for a complete environment, on Windows we always will be hosted, thus I consider it correct to

Re: Next GNUstep release?

Hey guys... Matt and I just talked via IM and he reminded me of a really important point. The functionality using proxies works fine on 32bit machines, but is broken on 64 bit machines due to the fact that this bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700 has not seen release yet on

Re: Next GNUstep release?

On Sun, Mar 28, 2010 at 11:37 PM, Gregory Casamento greg.casame...@gmail.com wrote: Hey guys...  Matt and I just talked via IM and he reminded me of a really important point. The functionality using proxies works fine on 32bit machines, but is broken on 64 bit machines due to the fact that

Re: Next GNUstep release?

On 29 Mar 2010, at 07:37, Gregory Casamento wrote: Hey guys... Matt and I just talked via IM and he reminded me of a really important point. The functionality using proxies works fine on 32bit machines, but is broken on 64 bit machines due to the fact that this bug:

Re: Next GNUstep release?

On 26 Mar 2010, at 20:55, Fred Kiefer wrote: Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, Is gnustep-base really ready for a release so shortly after a large rewrite ? I assume

Re: Next GNUstep release?

On 29 Mar 2010, at 13:44, Nicola Pero wrote: On 26 Mar 2010, at 20:55, Fred Kiefer wrote: Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, Is gnustep-base really ready for a release so

Re: Next GNUstep release?

Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, Is gnustep-base really ready for a release so shortly after a large rewrite ? I assume we're talking of an unstable release ? ;-) Most

Re: Next GNUstep release?

Wolfgang... The patch looks good. Please go ahead and apply it and make the change in GSNibLoading.m as well, if you wish. Thanks, GC On Sun, Mar 28, 2010 at 4:45 PM, Wolfgang Lux wolfgang@gmail.com wrote: Gregory Casamento wrote: Top level objects in the nib are the responsibility of

Re: Next GNUstep release?

Mhm, I already did all of that yesterday... But there is more to do. We now need to change all the places where we load NIB (or Gorm or XIB) files to free the top level objects. The code is a lot cleaner now, but as far as memory leaks are concerned we are almost back to square one. We now leak

Re: Next GNUstep release?

Hi I haven't kept up with the state of development/readiness of the windows theme, but I really don't agree with forcibly changing the default theme ... I know it makes me really irate on the odd occasion when Apple change default behaviors on OSX, and I have to look for the way to revert to

Re: Next GNUstep release?

On 27 Mar 2010, at 22:33, Riccardo Mottola wrote: Hi, Additionally, for the Windows packages the default theme should be the WinUXTheme and not the NeXT theme on that system. Completely agree. I heartily disagree, even if I am the one that started working on it after the

Re: Next GNUstep release?

Richard, On Sun, Mar 28, 2010 at 9:18 AM, Richard Frith-Macdonald rich...@tiptree.demon.co.uk wrote: I haven't kept up with the state of development/readiness of the windows theme, but I really don't agree with forcibly changing the default theme ... I know it makes me really irate on the

Re: Next GNUstep release?

Gregory Casamento wrote: Top level objects in the nib are the responsibility of the controller. That is to say that if you load a nib from MyController then any and all top level objects in that nib should be released by MyController when it deallocates itself. Indeed. What I tried to point

Re: Next GNUstep release?

On Sat, Mar 27, 2010 at 3:48 PM, Adam Fedor fe...@qwestoffice.net wrote: On Mar 26, 2010, at 1:55 PM, Fred Kiefer wrote: Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be

Re: Next GNUstep release?

Actually, all of these work for me. If you're using the Windows Classic Theme these things will not show since you're not using UXTHEME.DLL since the Classic theme is *actually* the built in theme and the .DLL is ONLY used when you use something other than the built-in theme (confused yet). I'm

Re: Next GNUstep release?

Hi, yes I find it due, we spoke about that before Fosdem indeed! This time we should really stabilize ad decide that for a period of a fortnight (or longer if deemed needed) where only bugfixes are commited! Not changes to the runtime or other far-reaching things. Also, fixes may produce

Re: Next GNUstep release?

Fred Kiefer wrote: Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, or so it seems from the outside and gui had to play catch up. Then I toyed around with the NIB loading and broke a few

Re: Next GNUstep release?

On 26 Mar 2010, at 19:55, Fred Kiefer wrote: What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. I made some small changes in -gui last night that

  1   2   >