Re: Which bugs to focus on for the release?
Am 20.04.2010 00:19, schrieb Riccardo Mottola: Gregory Casamento wrote: Have we established a list of bugs we would like to be fixed prior to the release? I'd like to get a consensus about this before we do it. Fred has a small app which exemplifies breakages in the different backends with regarding rects stroked and filled. We did it during LindauStep. Fred do you think you could fix them for this release? As far as I remember, this was mostly an art issue and I haven't worked on this at all. And at the current state of the release (We are in a code freeze!) I would not except such a patch from anybody else, why should I treat my own code differently? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
Hi Riccardo, Le 20 avr. 2010 à 00:36, Riccardo Mottola a écrit : Hi The switch to cairo as the default backend was a step that I should have done right after the last release. Doing so now is just not advisable. Or is it? I think not, libart should stick for this release, cairo will be for the next. Cairo has some problems here and there, although it is reasonably usable for the day usage. For example cairo has troubles with displaying (big) images, it can suddenly say it cannot allocate shared memory and then gets slooowww Can you give a detailed list of all these problems? Are they reported in the bug tracker? There are problems with Art too. - GSReadRect is broken in Art, see https://savannah.gnu.org/bugs/?2 - Pattern drawing doesn't work well However Art works better than Cairo for -compositeToPoint and - drawInRect without my patch, but it doesn't handle the scaling between the fromRect and toRect correctly. Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: opening problems with GWorkspace
Am 20.04.2010 00:33, schrieb Riccardo Mottola: after the core release, I will do a maintenance release of GWorkspace (since the old one would not compile anyway, causing frustration among the users). I noticed some strange behaviour with the opening of GWorkspace, which did not happen before. Maybe a change in base which needs some improvement or which requires GWorkspace adaptation. 1) when using gopen xxx NSworkspace will launch also gworkspace automatically. Strangely, GWorkspace now opens and asks you are you sure you want to quit ?... 2) gopen GWorkspace will open a double copy of it causing grief!!! Could you be more specific what the problem here is? As far as I understand it NSWorkspace has always relied on a workspace application to do most of the work. GWorkspace being the default one. gopen just uses this mechanism to get it's job done. So yes, starting GWorkspace via gopen could result in it being started twice. The only thing you report that seems strange is that GWorkspace will quit again. This sounds more like an GWorkspace issue. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
On Mon, Apr 19, 2010 at 07:39:14AM +0100, Richard Frith-Macdonald wrote: Well, 'waiting for gdnc indefinitely' is a bit vague ... is that failing to connect, failing to register as an observer, failing to send, failing to receive etc. Maybe gdnc is not even being started? Sorry, that last e-mail was decisively non-helpful. (My doctors tell me I'm suffering from a servere case of email-before-coffee related aphasia.) In concrete terms the problem seemed to be related to the remote side sending replies with a non-sensible type (e.g. 37602) in -[NSConnection _sendOutRmc:type:] and the local side waiting in -[NSConnection _getReplyRmc:]. But I say seemed because after recompiling everything without clang and libobjc2, things are working again. I'll need to go through another recompile cycle to find out what exactly is going wrong there. Cheers, Niels ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: opening problems with GWorkspace
Riccardo Mottola wrote: I noticed some strange behaviour with the opening of GWorkspace, which did not happen before. Maybe a change in base which needs some improvement or which requires GWorkspace adaptation. Did you recompile and reinstall GWorkspace? I'm asking because I was bugged by some strange crashes of Gorm after my last svn update a few days ago. Finally it turned out that these crashes were caused by Eric's patch in svn r30120 silently changing the size of NSWindow, which obviously breaks binary compatibility for the fragile ABI. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
On 20 Apr 2010, at 04:53, Adam Fedor wrote: On Apr 19, 2010, at 5:12 PM, David Chisnall wrote: While we're changing things, maybe we could change the name of the Windows installers too. After reading the descriptions, I'm still not clear what -system and -core mean in the context of GNUstep, which one I should install, and if I should install both which order I should install them in. Maybe I should just explain it better? I don't think the problem is the explanation, it's that -core and -system seem to be meaningless names. Maybe renaming -system to either -dependencies or -development would make sense? David -- This email complies with ISO 3103 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
On Apr 20, 2010, at 6:02 AM, David Chisnall wrote: I don't think the problem is the explanation, it's that -core and -system seem to be meaningless names. Maybe renaming -system to either -dependencies or -development would make sense? Neither of those make sense to me though. -system is the package that contains all the required system components to run GNUstep on a windows machine, such as graphics libraries, a shell, Msys, MingW dlls, etc. -core is just the basic core libraries from GNUstep. There's already a -devel package that is developer related files (svn, autoconf, ssh) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
Am 20.04.2010 um 15:41 schrieb Adam Fedor: On Apr 20, 2010, at 6:02 AM, David Chisnall wrote: I don't think the problem is the explanation, it's that -core and - system seem to be meaningless names. Maybe renaming -system to either -dependencies or -development would make sense? Neither of those make sense to me though. -system is the package that contains all the required system components to run GNUstep on a windows machine, then it should be named -requirements maybe? regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
What happened to the code freeze?
Looks like we have more commit right now during code freeze then we have at normal times. I would suggest that we give up the idea of doing more tests. As long as people cannot stick to a code freeze even for a week, we wont have any stable state that is worth testing. As far as we are aware all the bugs introduced freshly with Richard's and to a lesser extend my restructuring should be fixed by now. We will find out about other problems that went in with the recent commits soon enough. A the situation isn't improving with more waiting, I think we should make a release now and then try to get in all the other important stuff and make another pre-release before the gui/back 1.0. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Which bugs to focus on for the release?
Hi, I don't think the problem is the explanation, it's that -core and -system seem to be meaningless names. Maybe renaming -system to either -dependencies or -development would make sense? Neither of those make sense to me though. -system is the package that contains all the required system components to run GNUstep on a windows machine, such as graphics libraries, a shell, Msys, MingW dlls, etc. -core is just the basic core libraries from GNUstep. There's already a -devel package that is developer related files (svn, autoconf, ssh) I think your names make sense. Especially, core is indeed core and relates to our core libraries. The only name which was not totally clear to me at first was system. I now perfectly understand that it is the msys part and afterward I understand it. Maybe we could call it msys-system. I think it makes sense also for future releases where I will expect more frequent releases of core, where theoretically msys-system will be more stable. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: opening problems with GWorkspace
Hi, 1) when using gopen xxx NSworkspace will launch also gworkspace automatically. Strangely, GWorkspace now opens and asks you are you sure you want to quit ?... 2) gopen GWorkspace will open a double copy of it causing grief!!! Could you be more specific what the problem here is? As far as I understand it NSWorkspace has always relied on a workspace application to do most of the work. GWorkspace being the default one. Correct. gopen just uses this mechanism to get it's job done. So yes, starting GWorkspace via gopen could result in it being started twice. No gnustep application should be open twice as far as I can understand... The only thing you report that seems strange is that GWorkspace will quit again. This sounds more like an GWorkspace issue. Possibly, but it did not happen in the past. It does not quit in the sense crash. It asks me politely like I selected Quit from the menu! Nobody else noticed that? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Looks like we have more commit right now during code freeze then we have at normal times. I would suggest that we give up the idea of doing more tests. As long as people cannot stick to a code freeze even for a week, I thought we were in feature freeze - ie, all commits must be bug fixes as opposed to implementation of new features. A typical pre-release phase to iron out bugs before a release. :-) Instead, you're suggesting we're in code freeze - meaning no commits at all ? Ie, nothing gets done for weeks ? I've never seen a project do that. Anyway it would be easy enough to do, we just all have to stop doing anything. Hmmm. Not sure why that would be useful ? ;-) Having many commits during a feature freeze is very good as it is supposed to mean that a lots of bugs are being fixed. :-) With about 150 bugs open in the bug tracking system, we probably need quite a few weeks of feature freeze / bug fixing to get a good release. :-) If I am the one who misunderstood and we really are in code freeze, please let me know. ;-) Probably Gregory should clarify. I personally suggest we stay in a feature freeze / bug fixing only phase for a while until the bug count is down and the commits slow down because there are no more bugs to fix :-) Finally, it is quite possible you were referring to some specific changes that are new features instead of being bug fixes - presumably in the gui ? If so, you should IMO feel free to point these out, and even revert them. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Am 20.04.2010 um 14:30 schrieb Nicola Pero: Instead, you're suggesting we're in code freeze - meaning no commits at all ? Ie, nothing gets done for weeks ? I've never seen a project do that. Would not make any sense to me. With about 150 bugs open in the bug tracking system, we probably need quite a few weeks of feature freeze / bug fixing to get a good release. :-) True. Cheers, David Wetzel ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
