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 we don't officially support them any more. There is nothing stopping you to change that variable and try to use GNUstep with an older version of gcc. What we wont do is process bug reports that result out of such tests. Sounds fine. I shall do some builds. As for releasing gui and back for the last base release, we just missed the point to do so. It would have been possible right after the last base release, but now the code in gui is only tested with the SVN version of base and although I am again not aware of anything that changed in base that is required by gui, it is left to daring users to really test this. What we should aim for is to have a set of modules that work together. If the gui version also works well with an older base version, fine. Well, but we didn't release back then... it becomes a bit inconsistent. Perhaps we should do some tests against the past base release 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 do wonder indeed. Perhaps we are too busy arguing about gcc compatibility that we are missing the original point of the thread. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 evidently flickers) Riccardo Eric Wasylishen wrote: 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 is more important - the font rewrite could be quite a lot of work - and we can simply remove the ImageMagick and Ghostscript image reps for now. As for the new cairo backend I added to back, we can either release with it or not. The resize flickering is definitely worse, but it supports some 16-bit configurations that were previously unsupported, and performs better over SSH. btw, I have an experimental branch of back at svn+ssh://eri...@svn.gna.org/svn/gnustep/libs/back/branches/ericwa-experimental , which only supports x11 and cairo with the new surface. The goal is to try to clean up XGServerWindow/Event, and get rid of all legacy or "magic" code. So far I deleted a lot of code from XGServerWindow, deleted XWindowBuffer, and got rid of styleoffset support. One of the changes I made (I think in XGServerWindow ) got rid of the resize flickering, the only problem is, I'm not sure exactly what the change was. Anyway, it's encouraging, at least. Cheers Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Runtime Call for Testing...
Since release seem to be fashionable these days... Unless I hear any objections / bug reports, I intend to release the current svn of the runtime as 1.6.0. All of the bugs that I have been told about have been fixed, and on OpenBSD/SPARC (where I have done no testing and didn't expect it to work at all), it passed more of the GNUstep test suite than the GCC runtime, so I'm now at a point where I'm happy with the stability and have run out of features that I want to add for at least another week... David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 hand, I think doing a release soon is more important - the font rewrite could be quite a lot of work - and we can simply remove the ImageMagick and Ghostscript image reps for now. That sounds like a reasonable plan. As for the new cairo backend I added to back, we can either release with it or not. The resize flickering is definitely worse, but it supports some 16-bit configurations that were previously unsupported, and performs better over SSH. Not sure about this, on my machine the new surface works reasonable fast, although resize is a bit slower then before. But it may be different for other machines. We could, as long as we still have the code for XWindowBuffer in place, make this a runtime option? btw, I have an experimental branch of back at svn+ssh://eri...@svn.gna.org/svn/gnustep/libs/back/branches/ericwa-experimental , which only supports x11 and cairo with the new surface. The goal is to try to clean up XGServerWindow/Event, and get rid of all legacy or "magic" code. So far I deleted a lot of code from XGServerWindow, deleted XWindowBuffer, and got rid of styleoffset support. One of the changes I made (I think in XGServerWindow ) got rid of the resize flickering, the only problem is, I'm not sure exactly what the change was. Anyway, it's encouraging, at least. How does the interaction between GNUstep and X work without knowing the style offset? I think we needed that to position windows correctly. I will have a look at your branch soon. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 support them any more. There is nothing stopping you to change that variable and try to use GNUstep with an older version of gcc. What we wont do is process bug reports that result out of such tests. As for releasing gui and back for the last base release, we just missed the point to do so. It would have been possible right after the last base release, but now the code in gui is only tested with the SVN version of base and although I am again not aware of anything that changed in base that is required by gui, it is left to daring users to really test this. What we should aim for is to have a set of modules that work together. If the gui version also works well with an older base version, fine. 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. Fred On 09.11.2011 14:15, Riccardo Mottola wrote: 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 support. What's the problem with 3.x vs. 4.x? 3.2 especially was essentially the "second best" portable option after 2.95. Portability of gcc got quite worse after 3.4. Given the past code in gnustep, I never had any problems with gcc3, the only problems where with 2.95. Riccardo PS: additionally I think that the current gui and back release should still be 2.95 compatible, they are the natural match for the past base release. Especially since the past releases of gui and back are unusable with current base. So a coehrent "core" should be released. On 11/09/11 13: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 better language support and doesn't lose us any platforms. Pretty much anything that might reasonably be expected to run GNUstep that was supported by 3.x is also supported by 4.x. David -- Sent from my Apple II ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 is more important - the font rewrite could be quite a lot of work - and we can simply remove the ImageMagick and Ghostscript image reps for now. As for the new cairo backend I added to back, we can either release with it or not. The resize flickering is definitely worse, but it supports some 16-bit configurations that were previously unsupported, and performs better over SSH. btw, I have an experimental branch of back at svn+ssh://eri...@svn.gna.org/svn/gnustep/libs/back/branches/ericwa-experimental , which only supports x11 and cairo with the new surface. The goal is to try to clean up XGServerWindow/Event, and get rid of all legacy or "magic" code. So far I deleted a lot of code from XGServerWindow, deleted XWindowBuffer, and got rid of styleoffset support. One of the changes I made (I think in XGServerWindow ) got rid of the resize flickering, the only problem is, I'm not sure exactly what the change was. Anyway, it's encouraging, at least. Cheers Eric On 2011-11-08, at 3:49 PM, Fred Kiefer wrote: > 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 discussion about > this subject. > > After the last base release we did not make a gui/back release although some > of the changes in base wont work with an old version of gui. This means > anybody wanting to use GNUstep with a graphical user interface either has to > use a very old release of all components or use SVN. The later is especially > bad for distributions as they will have to ship an unclear state of the code. > > I will be away the first two weeks of December and would either like to see a > release before that or after, but wont be available for last minute bug fixes > during that period. > There are a few changes to gui/back which I would like to see done before the > release. One is the conversion of the Ghostscript and the ImageMagick bitmap > implementations into filter services. The other is the integration of the > real cairo font interface (instead of the currently used toy fonts) as > prototyped in Opal. Is there anything important I did forget? > > It would be great if everybody could start to test its favourite application > to find out whether any of the recent changes introduced new issues. What are > the plans for GNUstep make and base? I think there have been enough changes > in base that warrant a new release and gui requires some of these changes. > For make there are a few open bug reports, maybe some of them could be fixed > for the release? > > Please remember that this will be the first GNUstep release that requires gcc > >= 4.0. We decided so at the last base release and gui requires a current > base version. > > ___ > 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: preview: new macports ports
> This is great! Thanks for your effort. Btw. are those ports going to be at > the macports repository? I hope they will be accepted! There are several things I would like to do before submitting them to macports: - more testing - hopefully get them working on OS 10.7 (they probably would work if the gcc46 port wasn't broken :-) - the old ports contained some hacks for installing man pages/documentation... need to check if these are still needed - maybe investigate getting them to compile with clang - submit some of my patches to gnustep trunk - once the next release of GNUstep comes out, get ports working with that release (currently my ports require trunk) Cheers, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 maintenance burden for us. The question always was, what is the newest compiler that we can reasonably expect to be on any platform where people are going to want to run GNUstep. We decided before the release that GCC 4.x or newer provided the best balance between reducing our effort and maintaining support. If you wish to maintain a GCC 3.x (or even 2.x) compatibility branch, then no one will stop you, but if you want everyone else to put effort into maintaining support for a legacy compiler then you need to provide a compelling reason. David -- This email complies with ISO 3103 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: preview: new macports ports
On 2011-11-08, at 1:59 PM, Ivan Vučica wrote: > Hi Eric, > > I'm unable to build GNUstep due to no fault of your own: compiling gcc46 > fails in the linking phase of libgcc_s.1.dylib. This is on Snow Leopard. > Apparently gcc46 uses its own linker to link this library. > > For now, I am giving up. Can some older GCC be used if I am not interested in > objc2.0 niceties? Hm, too bad. :-( When I install gcc46 on 10.6, macports uses this precompiled binary: http://packages.macports.org/gcc46/gcc46-4.6.2_0.darwin_10.x86_64.tbz2 , but maybe your system is not x86_64? I tried gcc44 and it doesn't work, unfortunately. Something wrong with detecting native exceptions. Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 better language > support and doesn't lose us any platforms. Pretty much anything that might > reasonably be expected to run GNUstep that was supported by 3.x is also > supported by 4.x. Yes, we chose 4.0 as the earliest compiler to support because it gave a good feature set to base future code on (and so we wouldn't want to change the version we depend on again for a while), while running on as many platforms as (by now probably rather more than) any version 3.x compiler. At least that was the theory for the choice, and nobody afaik has claimed/demonstrated anything wrong with it. Is there *any* platform where a 3.? compiler will run and a 4.? compiler won't? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 see, Mac 10.99 is out, let's make some incompatible SuperApp. We as free software try to give the broadtest freedom and this implies limiting as little as possible. Most people wanted c99, maintaining the burden of special macros was too much, we dropped it, fine, I agreed. but jumping directly to gcc 4.0, oh pardon, 4.2? If there are no hard, pressing reasons for that, I consider it a gratuitous change. If you just take OpenBSD 4.7, it shipped with gcc 3.3.5. Me are speaking of May 2010, not stone age. Sure, it MAY run gcc 4, it most probably does on x86 too, but why force the person to take the hassle? Take solaris, sunfreeware still offers gcc 3.4.6 . The most commin thing you will find even on the latest IRIX boxen is gcc 3.3, because that is what SGI gave us. Theoretically, up to gcc 4.6 is supported, I wasn't able to build any gcc 4. version yet. I don't know how gcc support is/was on various platforms. On windows gcc 3.x is standard on cygwin (even if gcc4 is provided extra). Also n mingw in our just previous release (not current) we shipped gcc 3..x . Again, it is not stone age. We don't even know how many platforms we support, why do you want to axe them? We support for example NetBSD 2.0.2 with gcc 3.x on sparc. I have it, it works fine and compiles fine. The hardware probably supports newer stuff, but current it works. Supporting a "platform" is not just "latest revision". We are not Apple, nor Microsoft nor whatever. We value freedom, which has many aspects. How tedious. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 GNUstep? David -- Sent from my Apple II ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 support. What's the problem with 3.x vs. 4.x? 3.2 especially was essentially the "second best" portable option after 2.95. Portability of gcc got quite worse after 3.4. Given the past code in gnustep, I never had any problems with gcc3, the only problems where with 2.95. Riccardo PS: additionally I think that the current gui and back release should still be 2.95 compatible, they are the natural match for the past base release. Especially since the past releases of gui and back are unusable with current base. So a coehrent "core" should be released. On 11/09/11 13: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 better language support and doesn't lose us any platforms. Pretty much anything that might reasonably be expected to run GNUstep that was supported by 3.x is also supported by 4.x. David -- Sent from my Apple II ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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 platforms. Pretty much anything that might reasonably be expected to run GNUstep that was supported by 3.x is also supported by 4.x. David -- Sent from my Apple II ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Bean cannot load NIB file
Due to some of my recent changes the Bean application in gap is no longer starting correctly. What happens is rather interesting. I added binding support for the NSColorWell and Bean has been using this feature, but it wasn't supported in GNUstep. Now that it is, a problem on a deeper level got revealed. Bean has a defaults.plist file that stores some user default settings for the application. This includes the default colours for altBackgroundColor and altTextColor. These colours are stored as NSData containing the archived colours. altBackgroundColor BAt0eXBlZHN0cmVhbYED6IQBQISEhAdOU0NvbG9yAISECE5TT2JqZWN0AIWEAWMBhARm ZmZmgzyXxIiDPlaH04M+mOesAYY= altTextColor BAt0eXBlZHN0cmVhbYED6IQBQISEhAdOU0NvbG9yAISECE5TT2JqZWN0AIWEAWMBhARm ZmZmAQEBAYY= gdb reports the later value as: (gdb) po anObject <040b7479 70656473 74726561 6d8103e8 84014084 8484074e 53436f6c 6f720084 84084e53 4f626a65 63740085 84016301 8404 0101 010186> Starting from byte three this reads "typedstream". Now this is Apple format used for NSArchiver and GNUstep isn't able to read this. The simplest solution is of course just to delete this entries from the defaults.plist. On the other hand I remember somebody telling me that he wrote a reader for this archive format. Going down that road would mean to replace all our non-keyed archive implementations. Any ideas on how to handle this best? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
