Update of bug #39072 (project gnustep):
Item Group:None = Bug
___
Follow-up Comment #1:
From the code snippet I would guess that this is caused by className being
freed up right in the
Follow-up Comment #5, bug #35431 (project gnustep):
I don't fully understand the description of how to reproduce this behaviour
with Ink. Or maybe this specific problem was already resolved by your previous
patch? At least I am unable to reproduce the issue on my computer with gui
code from
On 07.08.2013 08:46, Lundberg, Johannes wrote:
Hi
Here's a patch that will fix MyTransparentGL which seems to be broken.
Johannes Lundberg
BRILLIANTSERVICE CO., LTD. http://www.brilliantservice.co.jp
Thank you, applied.
___
Bug-gnustep mailing
Follow-up Comment #1, bug #39900 (project gnustep):
Most likely the problem is that GNUstep detects your system encoding
differently from what you expect.
Now the best way to see what gets detected and why, is to go through the
function GSPrivateDefaultCStringEncoding() with a debugger. If this
Follow-up Comment #3, bug #39900 (project gnustep):
I am no gdb expert, but I normally start it with just the program as argument,
set my breakpoints and then give the arguments to the r command. In this case
something like:
gdb unar
b GSPrivateDefaultCStringEncoding
r arhiva.zip
Which
Follow-up Comment #8, bug #39900 (project gnustep):
I think that Eirc was correct with his answer. I found this link when
searching for issues with nl_langinfo:
http://stackoverflow.com/questions/1558379/whi-is-nl-langinfocodeset-different-from-locale-charmap
It explains that you need to call
On 06.09.2013 20:42, Pirmin Braun wrote:
this was a bug for serveral years. Upload of Files with Umlaute in the
filename didn't work.
With this modification it works.
Hi Pirmin,
could you please give an example of a text wrongly decoded by the old
code and correctly handled by yours? By
On 07.09.2013 14:23, v4hn wrote:
Heya over there,
while updating the gnustep-gui package in lunar-linux I found the
following problem with your build scripts (current svn rev 37027).
When the gnustep-gui library is already installed on the system
building, some module are linked against
On 09.09.2013 11:40, Richard Frith-Macdonald wrote:
On 9 Sep 2013, at 10:24, Pirmin Braun p...@intars.de wrote:
Index: Source/Additions/GSMime.m
===
--- Source/Additions/GSMime.m (revision 37035)
+++ Source/Additions/GSMime.m
On 09.09.2013 03:26, v4hn wrote:
On Sat, Sep 07, 2013 at 06:49:46PM +0200, Fred Kiefer wrote:
On 07.09.2013 14:23, v4hn wrote:
reproduce: 1. corrupt your system library, e.g. via`echo
/usr/lib/libgnustep-gui.so` 2. try to build gnustep-gui via
`./configure; make`
The attached patch
On 23.09.2013 01:08, v4hn wrote:
On Mon, Sep 09, 2013 at 11:23:43PM +0200, Fred Kiefer wrote:
On 09.09.2013 03:26, v4hn wrote:
On Sat, Sep 07, 2013 at 06:49:46PM +0200, Fred Kiefer wrote:
On 07.09.2013 14:23, v4hn wrote:
reproduce: 1. corrupt your system library, e.g. via`echo
/usr/lib
The is onecomponent missing in your list, the window manager. This is
responcible for window placement and most likely thenew one isn't fully
supported by GNUstep.
Fred
On the road
Am 21.10.2013 um 07:50 schrieb Lundberg, Johannes
johan...@brilliantservice.co.jp:
Hi
I experiencing some
Follow-up Comment #1, bug #40671 (project gnustep):
Not sure whether I completely understand your post.
Would it be sufficient to use the same code base is using in its configure
script to sort out the ICU dependencies? There we set the LDFLAGS based on
results from icu-config. I did not see a
Not sure which project your are referring to. If it is really libc
than this is the wrong mailing list. This one is about the GNUstep
project not the general GNU project.
Fred
On 24.11.2013 08:24, carl hansen wrote:
in configure it says:
$as_echo_n checking version of $MAKE... 6; }
Update of bug #36764 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #40761 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #35431 (project gnustep):
Status: Need Info = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #7:
I close this set of
Follow-up Comment #4, bug #40761 (project gnustep):
Please try again, I changed the code to always draw the knob slot.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?40761
___
Follow-up Comment #7, bug #40761 (project gnustep):
Thank you for your patch. I experimented with changes to the _usableParts
myself. But there is the risk that somebody later changes the code in
-rectForPart: to match that in -testPart: and that would again break your
[horizontalScroller
Update of bug #40776 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Follow-up Comment #2, bug #40671 (project gnustep):
Is this still valid or did your last change to base resolve the issue?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?40671
___
Update of bug #40776 (project gnustep):
Open/Closed: In Test = Open
___
Follow-up Comment #3:
Could you please try the code and see if the problem you are expecting really
occures?
I would
Update of bug #40671 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:Open = Closed
Update of bug #39125 (project gnustep):
Category: Backend = Base/Foundation
___
Reply to this item at:
http://savannah.gnu.org/bugs/?39125
___
Update of bug #40798 (project gnustep):
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #39107 (project gnustep):
Category:None = Base/Foundation
Item Group:None = Bug
___
Reply to this item at:
Update of bug #39739 (project gnustep):
Category:None = Base/Foundation
Item Group:None = Bug
___
Reply to this item at:
Update of bug #35671 (project gnustep):
Category:None = Base/Foundation
Item Group:None = Bug
___
Reply to this item at:
Update of bug #35081 (project gnustep):
Category:None = Libraries
___
Reply to this item at:
http://savannah.gnu.org/bugs/?35081
___
Update of bug #34926 (project gnustep):
Category:None = Backend
Item Group:None = Bug
___
Reply to this item at:
Update of bug #34785 (project gnustep):
Category:None = gsweb
___
Reply to this item at:
http://savannah.gnu.org/bugs/?34785
___
Update of bug #34758 (project gnustep):
Category:None = Backend
___
Follow-up Comment #1:
What you see is the normal GNUstep mechanism to determine the window
decoration offset as
Update of bug #34500 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
___
Reply to this item at:
Update of bug #34924 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
___
Reply to this item at:
Update of bug #34738 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
___
Reply to this item at:
Update of bug #34487 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
___
Reply to this item at:
Update of bug #33475 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
___
Reply to this item at:
Update of bug #27637 (project gnustep):
Category:None = Gui/AppKit
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27637
___
Update of bug #25979 (project gnustep):
Category:None = Backend
Item Group:None = Documentation
___
Reply to this item at:
Update of bug #27635 (project gnustep):
Category:None = Gui/AppKit
___
Reply to this item at:
http://savannah.gnu.org/bugs/?27635
___
Update of bug #40776 (project gnustep):
Open/Closed:Open = In Test
___
Follow-up Comment #5:
You screen shot shows the problem quite clearly.
Your original proposal is still wrong though,
Update of bug #40818 (project gnustep):
Item Group:None = Bug
Status:None = Ready For Test
Open/Closed:Open = In Test
Update of bug #39641 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #1:
David did apply your
Update of patch #8232 (project gnustep):
Assigned to:None = CaS
Open/Closed:Open = Closed
___
Reply to this item at:
Update of patch #7822 (project gnustep):
Assigned to:None = thebeing
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #36722 (project gnustep):
Status:None = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #1:
Thank you very much.
Follow-up Comment #1, bug #36721 (project gnustep):
I don't know why this happend and whether it is still the case. in
NSObjCRuntime.h we have this settings (actually twice as they are already in
GSConfig.h):
#ifdef __cplusplus
#ifndef __STDC_LIMIT_MACROS
#define __STDC_LIMIT_MACROS 1
#endif
Update of bug #32845 (project gnustep):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?32845
___
Update of bug #23661 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Declined
___
Follow-up Comment #5:
I declined this bug
Follow-up Comment #1, bug #36487 (project gnustep):
I don't see how the solution you siggested would resolve the issue. Instead I
think we need to include GNUstep.h in all the files where ASSIGN or one of the
other GNUstep macros gets used.
Update of bug #34803 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #7:
The workaround has
Update of bug #41274 (project gnustep):
Category: Gui/AppKit = Backend
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:
Update of bug #41274 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #38393 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #3:
No comment in almost
Update of bug #35192 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #37799 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #41325 (project gnustep):
Status:None = In Progress
___
Follow-up Comment #1:
I just implemented the method keyPathsForValuesAffectingValueForKey, but the
result may not be
Follow-up Comment #3, bug #41325 (project gnustep):
Thank you for spotting this bug. I committed you suggested fix.
As for the real change I hope that Richard is taking this up, I might put it
in the wrong place.
___
Reply to this item
Update of bug #41375 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Declined
___
Follow-up Comment #3:
Rejected because it
Update of bug #41374 (project gnustep):
Category: Application = Gui/AppKit
Status:None = Ready For Test
Assigned to:None = FredKiefer
Open/Closed:
Am 10.02.2014 um 08:11 schrieb Germán Arias germanan...@gmx.es:
On 2014-02-09 21:08:21 -0600 Adam Fedor fe...@gnu.org wrote:
On Feb 8, 2014, at 11:40 PM, Germán Arias germanan...@gmx.es wrote:
[...]
This seems like a different problem then Rol. The current core dlls are
0_24
for gui,
I hope to be able to look into this tomorrow. It would help if you could send a
piece of example code showing the issue.
Fred
On the road
Am 13.02.2014 um 09:16 schrieb Lundberg, Johannes
johan...@brilliantservice.co.jp:
Nope I was wrong..
Using the designated initializer (with
BRILLIANTSERVICE CO., LTD.
On Thu, Feb 13, 2014 at 5:50 PM, Fred Kiefer fredkie...@gmx.de wrote:
I hope to be able to look into this tomorrow. It would help if you could
send a piece of example code showing the issue.
Fred
On the road
Am 13.02.2014 um 09:16 schrieb Lundberg, Johannes
johan
On 15.02.2014 13:39, David Chisnall wrote:
On 14 Feb 2014, at 16:36, Fred Kiefer fredkie...@gmx.de wrote:
Looks like this is rather a question for David. It is more about
the semantic of ARC for different sorts of ivars, than about
NSTextView itself. In the code you did send the tvIvar ivar
I committed my suggested change.
Fred
On 18.02.2014 09:30, Fred Kiefer wrote:
Yes, there is a bug in the initWithDateFormat:allowNaturalLanguage: method.
It should be calling the setDateFormat: method and that on the other side
should be using ASSIGNCOPY.
Hope that somebody beats me
Update of bug #42230 (project gnustep):
Status:None = Confirmed
Assigned to:None = FredKiefer
___
Follow-up Comment #2:
German is correct,
You need to distinguish between the libtiff itself and the website. The
libtiff.org website might be outdated and moved to a different place, but you
will still need this library, from what ever place you should get it for your
specific operating system.
The other question is what are you
Update of bug #34752 (project gnustep):
Status:None = Ready For Test
Assigned to:None = CaS
Open/Closed:Open = In Test
Follow-up Comment #1, bug #42717 (project gnustep):
Looks very similar to the problem that was reported by German Arias on the
GNUstep mailing list in January 2013.
At that time I could not reproduce it on my 64 bit machine.
There is one bit in your stack dump that looks suspicious: aFlag=88
Follow-up Comment #6, bug #42717 (project gnustep):
Thank you for finding the commit that caused this problem. If you look at the
files included in that commit you will find that it also includes a lot of
other changes that actually result in the XIB file being loaded completely not
just parts of
Follow-up Comment #3, bug #42782 (project gnustep):
Could you please re-run this test with valgrind? Don't look at the leak
reports or what ever valgind might generate fpr you. In this specific case we
are only interesting in unitialized variables that the code might be
accessing. Valgrind shoul
Follow-up Comment #8, bug #42717 (project gnustep):
Again, please try to run this code with valgrind. Se my comment on bug #42782.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?42717
Follow-up Comment #5, bug #42782 (project gnustep):
This looks like the image loadign is failing for you and then Gorm tries to
use the nil value to extract the size of the image. Because of a compiler bug
this then results in a segmentation fault.
In the second init... method there was already
Update of bug #42717 (project gnustep):
Status:None = In Progress
Assigned to:None = FredKiefer
___
Follow-up Comment #10:
I now think that
Update of bug #42717 (project gnustep):
Status: In Progress = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #13:
You are correct,
Update of bug #42782 (project gnustep):
Category: Gui/AppKit = Gorm
Status:None = In Progress
___
Follow-up Comment #7:
I am no expert on
Follow-up Comment #10, bug #42782 (project gnustep):
I would expect that this new crash comes from a different place then before.
The question is how we could find out where, given that gdb and valgrind don't
give meaningful results.
It would be great, if you had a bit more information.
BTW,
Update of bug #42782 (project gnustep):
Category:Gorm = Gui/AppKit
Assigned to:None = FredKiefer
___
Follow-up Comment #12:
Thank you for
Update of bug #42782 (project gnustep):
Status: In Progress = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #15:
I think I fixed the
Update of bug #42542 (project gnustep):
Category: Backend = Libraries
___
Follow-up Comment #1:
I changed the category to libraries as you stated in a mail that this
behaviour happens only
Update of bug #42433 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Follow-up Comment #18, bug #42782 (project gnustep):
We should keep the Vindaloo bug separate from the Gorm image problem. The
later one consists of the following:
- when the Imagemagick NSImageBitmap extension is installed info files get
regarded as images
- each gorm directory contains one
Update of bug #42782 (project gnustep):
Category: Gui/AppKit = Gorm
Status: Ready For Test = In Progress
Open/Closed: In Test = Open
Update of bug #37162 (project gnustep):
Status:None = Confirmed
___
Follow-up Comment #3:
My current hypotheses for this problem is that it is caused by the image
caching. If the image
Update of bug #37162 (project gnustep):
Category: Backend = Gui/AppKit
___
Reply to this item at:
http://savannah.gnu.org/bugs/?37162
___
Update of bug #37162 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #4:
Looks like my theory is correct. When replacing the line in NSImage
[_lockedView
Update of bug #37162 (project gnustep):
Status: Confirmed = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #5:
Should be fixed in
Update of bug #37162 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed: In Test = Closed
___
Reply to this item at:
Update of bug #43454 (project gnustep):
Assigned to:None = FredKiefer
___
Follow-up Comment #3:
Could you please provide a stack trace of the issue?
You seem to be describing two different
Follow-up Comment #5, bug #43454 (project gnustep):
I submitted a patch for the specific issue of the last stack trace. This wont
fix the whole issue reported here, but should reduce the visible symptoms.
It would be great if you could send me a stack trace of the other issue as
well. Of course
Follow-up Comment #7, bug #43454 (project gnustep):
I now seem to have an idea what might cause the problem. With the selection
not properly adjusted the text view tries to highlight behind the end of the
text. This results in a glyoh past the end of the text being requested and
this somehow
Update of bug #42782 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #22:
Closed on request
Follow-up Comment #9, bug #43454 (project gnustep):
I am a bit confused that a break point at line 756 could still result in a
loop. As there is no loop inside of _generateGlyphsUpToCharacter: this would
mean that the loop is in _generateGlyphs_char_r:
Which again would mean that you only get the
Follow-up Comment #11, bug #43454 (project gnustep):
I finally managed to reproduce the descriped behaviour with a slight variation
of my code:
[text insertText: @Hola program];
NSLog(@inserting text);
[text setSelectedRange: NSMakeRange(5, 7)];
[textStorage beginEditing];
[text
Follow-up Comment #2, bug #44085 (project gnustep):
This looks completely different to #31311 to me and that bug was also already
marked as a duplicate.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?44085
Follow-up Comment #4, bug #44084 (project gnustep):
I tried with the attached file and a current version of Gorm and was able to
remove the class MiControl from the gorm file.
Steps to reproduce.
- open the Fisica.gorm file
- in the objects window select the classes tab
- make sure you aren't in
Update of bug #44428 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Closed
___
Reply to this item at:
Update of bug #44477 (project gnustep):
Category: Base/Foundation = Libraries
___
Follow-up Comment #1:
Corrected category
___
Reply to this
I haven't compiled GNUstep on Cygwin in may years, so my help might be off a
bit. From your logs I would say that this is an internal issue of Cygwin. Some
of the types used in socket.h aren't defined. What you could do is try to find
out, why this is the case. It could be that some define in
Update of bug #44920 (project gnustep):
Category: ProjectCenter = Gui/AppKit
Status:None = Need Info
Assigned to:None = FredKiefer
1101 - 1200 of 1310 matches
Mail list logo
