Re: crash in GUI / ProjectCenter

> Am 10.01.2023 um 18:37 schrieb Riccardo Mottola : > > Your fix appears to work > > > I still wonder if the bug is in GNUstep which shouldn't be "picky" about this > delegate or something done in ProjectCenter is fishy, something with the > editor instantiation. > > Observations: > 1)

Re: crash in GUI / ProjectCenter

> Am 10.01.2023 um 01:42 schrieb Riccardo Mottola : > > Hi, > > > Riccardo Mottola wrote: >> y to understand if this is more a GUI or a ProjectCenter issue > > I checked this a little more, also with Fred. The SplitView looses its > delegate.. it must be one of the subviews. I suppose the

NSPopUpButtonCell (was: Disappointed by GNUstep)

> Am 08.02.2022 um 04:16 schrieb Sergei Golovin : > > On 2022-02-08 02:49:26 +0400 Wolfgang Lux wrote: > >>> The attached patch changes the -[dealloc] to do the code chunk equivalent >>> to -[setMenu:nil] >>> avoiding that -[NSPopUpBut

Re: Disappointed by GNUstep

On Sun, 2022-02-06 at 19:50 +0100, Fred Kiefer wrote: > > Am 06.02.2022 um 16:30 schrieb Wolfgang Lux > > : > > ... > > > > No, it doesn't happen for a standard GNUstep application. And while > > it is reproducible for me (in at least one case), it seems ra

Re: Disappointed by GNUstep

Hi Sergei, > On 2022-02-06 22:50:07 +0400 Fred Kiefer wrote: > > > Your change looks great to me, as always. Let's just hope it does > > not > > break > > anything for the other two issues that caused the different changes > > on that > > code. > > That one issue in December was due to

Automated Reference Counting (Was: Disappointed by GNUstep)

Hi Fred, > Am 06.02.2022 um 19:50 schrieb Fred Kiefer : > > Hi Wolfgang, > >> Am 06.02.2022 um 16:30 schrieb Wolfgang Lux : >> >>> There are bugs in GNUstep and probably there always will be. We don’t get >>> enough testing, usage, for GNU

Re: Disappointed by GNUstep

> Am 07.02.2022 um 12:09 schrieb Sergei Golovin : > > On 2022-02-06 22:50:07 +0400 Fred Kiefer wrote: > >> Let's just hope it does not break anything for the other two issues that >> caused the different changes on that code. > > It breaks the @97351199e Sorry, for some reason I deleted one

Re: Disappointed by GNUstep

> Am 05.02.2022 um 23:53 schrieb Gregory Casamento : > > We just had the quarterly meeting, and we discussed this. GNUstep is already > using LLVM/clang, as you likely know. The issue is that libobjc2 does not > function on as wide a variety of platforms as GCC and libobjc. We have, >

Re: Disappointed by GNUstep

Hi Fred, > There are bugs in GNUstep and probably there always will be. We don’t get > enough testing, usage, for GNUstep gun applications, so many bugs may go > unnoticed for a long time. At least the first bug you mention below is > something I already fixed on Christmas. I am surprised that

Disappointed by GNUstep

Hi, when I started looking at GNUstep as means to port macOS (then Mac OS X) applications to Linux/Windows about 15 years ago I found code that was quite buggy and that kept crashing or not working as expected on the application I tried to port at that time. I've contributed a number of

Re: NSControls failing to set status/label on BigEndian/64bit

Am 07.01.2021 um 14:33 schrieb Riccardo Mottola : > > Hi all, > > > Wolfgang Lux wrote: >> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is >> a, errm, not so bright idea. The types are included in the binary archives. >

Re: NSControls failing to set status/label on BigEndian/64bit

Am 06.01.2021 um 23:11 schrieb Fred Kiefer : > > > >> Am 06.01.2021 um 22:57 schrieb Wolfgang Lux : >> >>> good catch. We have two differences here 32bit vs 64bit, but also signed vs >>> unsigned! >> >> the difference between signed and u

Re: NSControls failing to set status/label on BigEndian/64bit

Hi Riccardo, > good catch. We have two differences here 32bit vs 64bit, but also signed vs > unsigned! the difference between signed and unsigned is irrelevant for encoding and decoding, as you pass a pointer to the memory being encoded or decoded. However, the size of the value you want to

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 06.01.2021 um 17:15 schrieb Wolfgang Lux : > >  > >> Am 06.01.2021 um 15:41 schrieb Fred Kiefer : >> >>  >> The next step would be to compare these values with the ones you get on >> amd64. But before that, could you please run the base

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 06.01.2021 um 15:41 schrieb Fred Kiefer : > >  > The next step would be to compare these values with the ones you get on > amd64. But before that, could you please run the base tests on ppc64? Maybe > you get already a failing test there and this would just explain the > behaviour. We

Re: windowmaker - application icon missing at first start

Hi Sergii, > > > Hi, > >> On Oct 17, 2020, at 00:27, Wolfgang Lux wrote: >> >> Hi Riccardo, >> >>> I noticed we recently have a strange behaviour, which is slightly >>> different from setup (= installation on different computers) to

Re: windowmaker - application icon missing at first start

Hi Riccardo, > I noticed we recently have a strange behaviour, which is slightly > different from setup (= installation on different computers) to setup I have > > The first time I start a GNUstep application with windowmaker (I mean > the first GNUstep app started ever after X11 start

Re: libobjc2-clang

> Am 29.06.2020 um 23:23 schrieb Riccardo Mottola : > > I have most applications running.. only SWK+Vespucci give this strange errors. > This linker differences are perhaps also the issues Patrick is seeing? I do > wonder. > > Anyway, do you have further ideas on this strange failure? does

Re: libobjc2-clang

> Am 28.06.2020 um 21:21 schrieb Wolfgang Lux : > > > >> Am 18.06.2020 um 17:21 schrieb Riccardo Mottola : >> >> Hi David, >> >> David Chisnall wrote: >>> >>>> On 18 Jun 2020, at 12:52, Riccardo Mottola >>>> wro

Re: libobjc2-clang

> Am 18.06.2020 um 17:21 schrieb Riccardo Mottola : > > Hi David, > > David Chisnall wrote: >> >>> On 18 Jun 2020, at 12:52, Riccardo Mottola >>> wrote: >>> >>> you guessed correctly and the protocol is also a very common one, NSCopying >> So, part of the question is whether this is the

Re: libobjc2-clang

> Am 17.06.2020 um 13:28 schrieb Riccardo Mottola : > > Hi, > > Wolfgang Lux wrote: >>> Perhaps libobjc? how can I compile libobic2 in debug? I think I need to >>> activate CMAKE_ASM_FLAGS_DEBUG somehow >> No. But you want to reconfigure libobjc2 w

Re: libobjc2-clang

> Am 12.06.2020 um 18:34 schrieb Riccardo Mottola : > > > Perhaps libobjc? how can I compile libobic2 in debug? I think I need to > activate CMAKE_ASM_FLAGS_DEBUG somehow No. But you want to reconfigure libobjc2 with CMAKE_BUILD_TYPE=RelWithDebInfo (or, if you absolutely insist on turning

Re: GSMutableDictionary class cluster and isKindOfClass

Hi Riccardo > I have a strange issue. I get an object and check if it s a Dictionary, else > I spit out an exception. > > if ([obj isKindOfClass: [NSDictionary class]]) > { > do someting; > } > else if ([obj isKindOfClass: [DBSObject class]]) > { > do something els; > } > else > Error!!! >

Re: Lost information converting decoded value to in32_t

> Am 25.05.2020 um 23:57 schrieb Riccardo Mottola : > > What is interesting, if gdb follows the same literal rules and promotions of > GCC: > > (gdb) p (int64_t)-2147483648 > $8 = 2147483648 > (gdb) p (int64_t)-2147483648l > $9 = 2147483648 > (gdb) p (int64_t)-2147483648L > $10 =

Re: Is the GNUstep Objective-C runtime to picky about method signatures?

> Am 14.04.2020 um 12:34 schrieb David Chisnall : > > Calling a method with the wrong signature is undefined behaviour in > Objective-C. The Apple runtime just ignores the type entirely and will > happily corrupt your stack in a few cases. We try to allow it in benign > cases, which

Re: FreeBSD - no luck with libobjc2

> Am 13.04.2020 um 13:56 schrieb Riccardo Mottola : > > So now? Is this not the correct way to change cmake parameters? I've never used ccmake, but I'm using cmake directly in the way suggested in the INSTALL file: cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++

Is the GNUstep Objective-C runtime to picky about method signatures?

Hi, I've just recently come across a strange issue where the MySQL interface in the SQLClient library had stopped working with a weird error when using the libobjc2 runtime. In particular, the code was complaining that the backendQuery:recordType:listType: method was called without a loaded

Re: Incremental linking

On Thu, 2020-04-02 at 18:18 +0200, Wolfgang Lux wrote: > On Thu, 2020-04-02 at 11:06 +0100, David Chisnall wrote: > > Hello, > > > > For various reasons, I have been reading the binutils ld > > documentation > > and there is a note that -Ur is needed

Re: Incremental linking

On Thu, 2020-04-02 at 11:06 +0100, David Chisnall wrote: > Hello, > > For various reasons, I have been reading the binutils ld > documentation > and there is a note that -Ur is needed instead of -r for incremental > linking of C++ programs that contain constructors. I suspect that > this > is

Re: Issues subclassing NSMutableArray

> Am 24.02.2020 um 08:38 schrieb mickb...@posteo.net: > > On 17.11.2019 16:53, Richard Frith-Macdonald wrote: >>> On 17 Nov 2019, at 15:08, Riccardo Mottola >>> wrote: >>> I wanted to subclass NSMutableArray, so that I can easily add some extra >>> methods. >>> I declared my subclass like

Re: [PATCH 0/3] gnustep-make: stage 1 of cross-compile awareness

> Am 13.01.2020 um 19:10 schrieb Ladislav Michl : > > On Mon, Jan 13, 2020 at 06:31:21PM +0100, Wolfgang Lux wrote: >> Hmmm, I guess you tried to include >> MAKE_VERSION=`(${GNUMAKE} --version | head -1 | sed -e 's/^[^0-9]*//')` >> just verbatim in configure.ac

Re: [PATCH 0/3] gnustep-make: stage 1 of cross-compile awareness

> Am 13.01.2020 um 11:39 schrieb Ladislav Michl : > > On Mon, Jan 13, 2020 at 09:14:04AM +0100, Ladislav Michl wrote: >> On Sun, Jan 12, 2020 at 11:37:59PM +0100, Wolfgang Lux wrote: >>>> Am 12.01.2020 um 23:23 schrieb Fred Kiefer : >>>> >>

Re: [PATCH 0/3] gnustep-make: stage 1 of cross-compile awareness

> Am 12.01.2020 um 23:23 schrieb Fred Kiefer : > > Thank you for your patches. The first two are clear improvements. The third > one also looks good to me, but I must admit it is really hard to read through > in a patch mail (and I only read the configure.ac part. After the merge I > would

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

> Am 20.12.2019 um 16:11 schrieb Fred Kiefer : > > ... > > There you just describe that now the popup looks the same whether in pull > down or in popup state. But what is the reason for this change? As I wrote I > am happy with getting rid of all this special code, but last time I tried to

Re: Occasional NSInternalInconsistencyException

> Am 18.11.2019 um 04:43 schrieb Patryk Laurent : > > On a fresh install of Ubuntu 19.04 building from the current master base and > GUI, I get an occasional odd error in a simple NSAlert GUI program: > > “Uncaught exception NSInternalInconsistencyException, reason: registration > with

Re: Missing header file in base?

Yes, it appears a few bogus commits have ended up on trunk tonight. :-( > Am 29.10.2019 um 09:17 schrieb Riccardo Mottola : > > Hi, > > if I compile base, I get this error: > > Compiling file NSMetadata.m ... > In file included from NSMetadata.m:35: > ../Headers/Foundation/NSMetadata.h:33:9:

Re: runtime inclusion, issues

> Am 18.10.2019 um 07:52 schrieb Riccardo Mottola via Gnustep-dev > : > > Hi, > > supporting Mac, gnustep, gcc and clang is a small challenge :-P But I like to > do it. > > For selector issues, some time ago in Graphos I added this: > > #if !defined (GNUSTEP) &&

Re: make error in base on Solaris

> Am 18.10.2019 um 10:36 schrieb Richard Frith-Macdonald > : > > ... > > The idea here (explained in the commnt) is to avoid lengthy unnecessary > reconfigurations: > > # If the generated makefiles are present but their prerequisites have > # changed, let config.status regenerate them.

Debugging on Linux with non-fragile ABI?

Hi all, has anybody tips for how to debug GNUstep executables built with the non-fragile ABI? Gdb seems pretty useless with the non-fragile ABI because all instance variable offsets appear to be 0 so it's impossible to inspect the contents of any instances: (gdb) print *self $1 = {<> = {isa =

Re: Why is this test consistently failing...

Am 02.07.2019 um 00:25 schrieb Gregory Casamento : > > base/GSTLS/basic.m: > Failed test: basic.m:31 ... Expiration date can be retrieved > --- Running tests in base/GSXML - This was a time zone issue. The test was comparing the expiration date of a certificate with a date that was

Re: libs-base fails to compile on OpenBSD

Hi Riccardo, > The base configure script reports: > > checking the Objective-C runtime... GNU > checking for custom shared objc library... NONE > checking objc/runtime.h usability... yes > checking objc/runtime.h presence... yes > checking for objc/runtime.h... yes > checking objc/objc.h

Re: libs-base fails to compile on OpenBSD

> Am 18.12.2018 um 22:01 schrieb Riccardo Mottola : > > Making all for subproject ObjectiveC2... > Compiling file runtime.c ... > runtime.c:35:27: fatal error: objc/objc-api.h: No such file or directory > #include > ^ > compilation terminated. > > > which is

Re: libs-base fails to compile on OpenBSD

> Am 05.12.2018 um 10:38 schrieb Riccardo Mottola : > > Hi Wolfgang, > > Wolfgang Lux wrote: >> I haven't been using OpenBSD for years, so I'm not sure why there is an >> /usr/include/objc header directory that does not match the compiler. But >> anyway,

Re: libs-base fails to compile on OpenBSD

> Am 02.12.2018 um 18:12 schrieb Wolfgang Lux : > > > >> Am 02.12.2018 um 17:28 schrieb Riccardo Mottola : >> >> Sebastian Reitenbach wrote: >>> What platform are you on? Why don’t you take the path the packages take and >>> use base clang

Re: libs-base fails to compile on OpenBSD

> Am 02.12.2018 um 17:28 schrieb Riccardo Mottola : > > Sebastian Reitenbach wrote: >> What platform are you on? Why don’t you take the path the packages take and >> use base clang, and libobjc2? > > because libobjc2 I always have issues with that setup or clang or something. > > I like to

Re: Coverity Scan for GNUstep?

> Am 29.01.2018 um 18:15 schrieb Fred Kiefer : > > > >> Am 29.01.2018 um 11:32 schrieb Richard Frith-Macdonald >> : >> >>> On 29 Jan 2018, at 08:28, Fred Kiefer wrote: >>> >>> re is a problem with these

Re: ANN: GNUstep GUI 0.26.1

> Am 02.01.2018 um 08:37 schrieb David Chisnall : > > On 2 Jan 2018, at 07:29, Yavor Doganov wrote: >> >> В Tue, 02 Jan 2018 07:20:39 +, David Chisnall написа: >> >>> Is there a good reason why we release -back as a separate package? >> >> One

Re: gnustep-make: /etc/GNUstep.conf in case of --prefix and --sysconfdir

> Am 02.04.2017 um 18:19 schrieb Ivan Vučica : > > Hey, > > I'm trying to install GNUstep into /GNUstep with folders such as > /GNUstep/System, /GNUstep/Local, etc. However, GNUstep.conf should live in > /etc/GNUstep/GNUstep.conf. > > ./configure --prefix=/GNUstep

Re: non-flattened filesystem layout

> Am 30.06.2016 um 01:23 schrieb Stefan Bidigaray : > > LIBRARY COMBOS > I don't understand why these are still needed. Can't the library combo be > inferred from the architecture triplet, nowadays? I'm still using both apple-apple-apple and gnu-gnu-gnu on OS X (the

Re: NSView and nil window

> Am 26.05.2016 um 12:10 schrieb Riccardo Mottola : > > Hi, > > it is acceptable to have and manipulate a NSView without it being inside a > window? Yes, you can take out a view from the view hierarchy inside a window to make it invisible (although IIRC Apple

Re: GNUstep Make still passing -fgnu-runtime

Am 16.08.2015 um 18:36 schrieb Ivan Vučica i...@vucica.net: Additionally, output of 'svn diff -r 38886:38887' is bizarre and the probable cause of the failure I'm seeing. I think this has actually broken the build, as the diff randomly inserts 'int[newline]main ()[newline]{' into

Re: Thread IDs on BSD

Am 31.03.2015 um 21:31 schrieb Riccardo Mottola r...@gnu.org: Hi Richard, On 2015-03-31 11:48:53 +0200 Richard Frith-Macdonald r...@gnu.org wrote: I don't have BSD systems to test on, but I've added code which should report the BSD thread ID of a thread in NSLog output, and also

Re: char vs. unsigned char

Hi Riccardo, a developer question. I got LuserNET working again! another application almost saved from bitrot :) I get however a lot of warnings about signedess in char*. In several palces data buffers are specified as unsigned char, while in other places data coming from those buffers

Re: NSData -writeToFile:options:error: on MinGW

Am 07.02.2015 um 08:16 schrieb Germán Arias germanan...@gmx.es: After solve the problem with pthread and nanosleep (change the parts/time.h header on MinGW and change config.h, in gnustep base, to don't use nanosleep) I have other problem. The configure script now defines HAVE_MKSTEMP to

Re: Error while compiling on FreeBSD

Am 04.12.2014 um 19:33 schrieb Riccardo Mottola riccardo.mott...@libero.it: Hi, On 12/02/14 07:57, Richard Frith-Macdonald wrote: It seems there are two variants of pthread_setname_np and the autoconf script didn't know about them; it was just checking for pthread_setname_np or

Re: GWorkspace file operation pause/stop problems

Hi Riccardo Mottola, Wolfgang Lux wrote: I finally got around to upgrade my GNUstep tree and was able to reproduce your problem. Looking at the code, then, the problem is fairly obvious: When you click the pause button for the first time, the paused flag is set to YES and once

Re: GWorkspace file operation pause/stop problems

Hi Riccardo, Wolfgang Lux wrote: Did you check the value of executor? Is it a valid object at all or does the thread perhaps crash inside the NSLog? I can't trap an exception and I hoped to print out something useful. How would you know if it is valid? I can't p executor inside gdb

Re: GWorkspace file operation pause/stop problems

Hi Riccardo. Hi, Riccardo Mottola wrote: NSLog(@perfomring operation); NSLog(@performing operation on executor: %@, executor); The first one prints out. The second not. I do not get an exception raised though. The program flow seems to interrupt. to be more precise, I

Re: Methods +readable/writableTypes

Hi Germán, Some weeks ago I tried to solve a problem with native Open/Save panels at WinUXTheme. These panels don't have accessory view, so the user can't select other type of document. Then I tried use the methods +writableTypes and +readableTypes in NSDocument. However, these methods not

Re: Problem with object sender in -insertTab:

Am 23.01.2014 um 09:53 schrieb Fred Kiefer fredkie...@gmx.de: I think the problem is in NSTextView doCommandBySelector: there we should use the form of performSelector that has an additional argument. The only argument we can use here is self, which might not be what you expect, but it is

Re: Intermediate Summary: Re: GNUstep.org website redesign proposal

Niels Grewe wrote: Am 12.01.2014 um 00:06 schrieb Riccardo Mottola r...@gnu.org: ARC instead is more a taste. It is a new addition in the GC discussion. I personally prefer ref-counting. This seems to be a common misconception: ARC *is* reference counting; it has very little to do with

Re: GNUstep on Mac OS X

Fred Kiefer fredkie...@gmx.de wrote: So in the next step we should explain the problems of that setup. - Why we cannot use the Apple ObjC runtime. Actually why? In the old days, I think we could not use Apple's runtime because of the subtle incompatibilities between the Apple and the gnu

Re: Possible bug in NSDocumentController

Am 24.12.2013 um 19:41 schrieb Germán Arias germanan...@gmx.es: El mar, 24-12-2013 a las 11:23 +0100, Wolfgang Lux escribió: Hi Germán, Is this correct? (line 1218 NSDocumentController.m) name = [[NSBundle mainBundle] localizedStringForKey: type value

Re: Possible bug in NSDocumentController

Hi Germán, Is this correct? (line 1218 NSDocumentController.m) name = [[NSBundle mainBundle] localizedStringForKey: type value: type table: @InfoPlist]; Don't should be NSHumanReadableNameKey the first type. looking

Re: cairo on netbsd undefined symbol problem cairo_xlib_surface_create

Riccardo Mottola wrote: Hi, I just installed the cairo backend on NetBSD 6.1.2. (latest) with all dependencies, including cairo, gotten from the latest binary packages. When i try to start any application, like Ink, I do get:

Latest gnustep-base doesn't build with --disable-tls

If gnustep-base is configured with --disable-tls, compilation fails in NSFileHandle.m with the following error: Compiling file NSFileHandle.m ... NSFileHandle.m: In function '+[NSFileHandle(GNUstepTLS) setData:forTLSFile:]': NSFileHandle.m:716:4: error: 'GSTLSObject' undeclared (first use in

Re: Question about _windowWillClose:

Germán Arias wrote: In _windowWillClose: at NSApplication, why not use GSAllWindows() instead GSOrderedWindows()?. This make more sense. You cannot simply replace GSOrderedWindows by GSAllWindows (incidentally, I think you should use [self windows] instead of GSAllWindows). The purpose of

Re: NSThread test failing

David Chisnall wrote: On 12 Aug 2013, at 03:44, Doug Warren doug.war...@gmail.com wrote: backgroundTid = 0; [backThread performSelectorInBackground:@selector(run:) withObject:backThread]; while(backgroundTid == 0) sleep(1); I don't know if this is your issue, however

Re: Textview problem

Hi Germán, I'm having a problem with Gemas.app when load a file. If I move the scroll knob to the end of the file, the knob stops at bottom. But if you see the attached image, obviously that isn't the end of the file. A click over one arrow or move the knob solves the problem. But if I

Re: MAC_OS_X_VERSION macros

Richard Frith-Macdonald wrote: On 30 Jun 2013, at 16:22, Richard Frith-Macdonald rich...@frithmacdonald.me.uk wrote: On 26 Jun 2013, at 10:33, Wolfgang Lux wolfgang@gmail.com wrote: Ivan Vučica wrote: How about: #ifdef __APPLE__ #include

Re: NSAppKitDefined events not sent by XGServerWindow

Hi Germán Arias, The problem I'm facing with menus in window, is caused by events sent by NSApp (NSAppKitDefined events). But since only XGServerWindow can draw/move/resize a window, I think NSWindow should respond only to events sent by XGServerWindow. Events sent from other objects, don't

Re: MAC_OS_X_VERSION macros

Hi Eric, Hi Frank, Thanks for bringing this up - it's indeed a nasty problem (although hopefully pretty easy to fix :) A year or two ago I was working on updating macports patches for building GNUstep on OS X 10.6/10.7, and ran in to an instance of this here:

Re: MAC_OS_X_VERSION macros

Ivan Vučica wrote: How about: #ifdef __APPLE__ #include WhateverHeaderDefinesMacOSXVersionMacros.h #else // GNUstep's definitions #endif This would only be helpful if OS X's macro definitions exist in a standalone header, by themselves. However, it sounds better than undefining,

Re: NSClassSwapper leaving dangling pointers?

Hi Fred, What I don't understand is why a menu item would use its cell as the target. Or is the main cell of a popup button being used as the target of its menu items? Indeed. The menu items of a pop up button use the NSPopUpButtonCell of the pop up as their target by default (with action

Re: Ubuntu and Debian packages / 2013-04-10

Niels Grewe wrote: On 29.05.2013 10:06CEST Philippe Roussel p.o.rous...@free.fr wrote: DKMethod.m:618:28: error: array index of '2' indexes past the end of an array (that contains 2 elements) [-Werror,-Warray-bounds] NSAssert2((0 == strcmp(@encode(id), [sig methodReturnType])),

Re:

Germán Arias wrote: With current SVN I get this error after install flite: Making all in say ... Making all for tool say... Linking tool say ... ./obj/say.obj/say.m.o:(.data.rel+0x14): undefined reference to `__objc_class_name_NSSpeechSynthesizer' collect2: ld returned 1 exit status

Re: Position of I-beam cursor

Germán Arias wrote: Thanks. I want implement autocomplete for textview. So I need know where to display the window with autocomplete suggestions. I don't understand why you need to know the position of the mouse cursor for that. I think you should present the window at the place where the

Overflow in constant conversion

I just noticed the following warning while compiling NSCalendar.m: NSCalendar.m: In function '-[NSCalendar initWithCalendarIdentifier:]': NSCalendar.m:264:3: warning: overflow in implicit constant conversion [-Woverflow] NSCalendar.m:265:3: warning: overflow in implicit constant conversion

Re: Overflow in constant conversion

Wolfgang Lux wrote: I just noticed the following warning while compiling NSCalendar.m: NSCalendar.m: In function '-[NSCalendar initWithCalendarIdentifier:]': NSCalendar.m:264:3: warning: overflow in implicit constant conversion [-Woverflow] NSCalendar.m:265:3: warning: overflow

Re: Localization of special directories

Riccardo Mottola wrote: Hi, Luboš Doležel wrote: Hi, on Linux related systems, the correct way is to use ~/.config/user-dirs.dirs I couldn't find more information on this, but I think I've heard about desktop environments (in the future) using only English folder names

Re: NSSavePanel test file fails to build

Fred Kiefer wrote: On 07.03.2013 17:35, Quentin Mathé wrote: Le 7 mars 2013 à 16:10, Richard Frith-Macdonald a écrit : On 7 Mar 2013, at 14:52, Quentin Mathé wrote: I don't understand why setDelegate_reload.m isn't built. Try looking at the log file (shouuld be tests.log) in which the

Re: Tooltips in save panels

Fred Kiefer wrote: The problem is fairly obvious if you look at the source: Tool tips are drawn at NSStatusWindowLevel, which is well below NSModalPanelWindowLevel. I guess the tool tips would need to be drawn (at least) at NSPopUpMenuWindowLevel. Actually, I would think it should be even

Re: Tooltips in save panels

Fred Kiefer wrote: On 24.02.2013 00:05, Riccardo Mottola wrote: Fred Kiefer wrote: As I wrote the idea would be to reuse the same timer for both run loop modes. This is definitely better than having two separate timers. The specific problem I talk about was fixed in base a long time ago.

Re: Tooltips in save panels

Riccardo Mottola wrote: On 02/18/13 06:22, Germán A. Arias wrote: As I understand the save panels should display tooltips for buttons: Home, Mount, Unmount. However I don't see these tooltips. that is correct, I just implemented that feature because it was requested in a bug report, but I

Re: Install location for libobjc2

Quentin Mathé wrote: Hi Tom, Le 2 nov. 2012 à 21:35, Tom Davie a écrit : On 2 Nov 2012, at 19:37, Richard Frith-Macdonald rich...@tiptree.demon.co.uk wrote: On 2 Nov 2012, at 19:27, Robert Slover wrote: Isn't the 'sudo' failing there? That seems likely to cause problems. Good

Re: Infinite loop in objc_msg_lookup_sender

Tom Davie wrote: I guess the easiest way to get a hint at this would be to find out which svn commit it was introduced in, as 1.6.1 works nicely. Is it possible to find out at what revision trunk and 1.6.1 matched each other? That way I can spend a bit of time delta debugging where it's

Re: On linux too (was Re: Base compilation broken on NetBSD)

Am 02.11.2012 um 00:27 schrieb Philippe Roussel: Le 01/11/2012 22:07, Riccardo Mottola a écrit : Hi, with the latest changes, if I compile base on NetBSD I get: Compiling file NSProcessInfo.m ... In file included from NSProcessInfo.m:86:0: /usr/include/kvm.h:74:30: error: expected

Re: On linux too (was Re: Base compilation broken on NetBSD)

Am 02.11.2012 um 09:22 schrieb Wolfgang Lux: Am 02.11.2012 um 00:27 schrieb Philippe Roussel: Le 01/11/2012 22:07, Riccardo Mottola a écrit : Hi, with the latest changes, if I compile base on NetBSD I get: Compiling file NSProcessInfo.m ... In file included from NSProcessInfo.m:86:0

Re: On linux too (was Re: Base compilation broken on NetBSD)

Richard Frith-Macdonald wrote: After a bit of testing, I found the issue. Before the change Source/common.h would define _XOPEN_SOURCE only for Linux (and even in that case only if the macro __GNU__ is not defined; I don't know when this is supposed to be defined and when not) and for

Re: On linux too (was Re: Base compilation broken on NetBSD)

Richard Frith-Macdonald wrote: On 2 Nov 2012, at 09:19, Wolfgang Lux wrote: David Chisnall wrote: On 2 Nov 2012, at 09:05, Wolfgang Lux wrote: Do we need to define _XOPEN_SOURCE at all? In the headers on OS X I found this comment: Defining _POSIX_C_SOURCE or _XOPEN_SOURCE restricts

Re: On linux too (was Re: Base compilation broken on NetBSD)

Wolfgang Lux wrote: Yes you NEED _XOPEN_SOURCE ... because it selects which, of different variant of some functions, you actually get to use. So without it the code may compile but not run correctly. The example that springs to mind is strerror_r() ... if you don't have it defined

Re: On linux too (was Re: Base compilation broken on NetBSD)

Am 02.11.2012 um 11:13 schrieb Richard Frith-Macdonald: So how do we test for it? The point is not whether or not we need this behavior but how to control it ... there's a simple ifdef required in one header ... what we are lacking is the knowledge of how we can best determine when we need

Re: On linux too (was Re: Base compilation broken on NetBSD)

Wolfgang Lux wrote: I was going about to write the test, but then I found that autoconf already has a predefined test for it (obviously, we are not the only ones struggling with this dichotomy :-) -- Macro: AC_FUNC_STRERROR_R If `strerror_r' is available, define `HAVE_STRERROR_R

Re: Problem with tooltips

Hi Germán, El lun, 08-10-2012 a las 14:33 +0200, Wolfgang Lux escribió: Hi Germán, Currently (with SVN) the tooltips added to buttons in gorm, aren't displayed. this may (or may not) be a consequence of a change I made on Sat. Can you test if tooltips are ok when you revert the change

Re: Problem with tooltips

Hi Germán, Currently (with SVN) the tooltips added to buttons in gorm, aren't displayed. this may (or may not) be a consequence of a change I made on Sat. Can you test if tooltips are ok when you revert the change in r35645? Also, does this apply only to tooltips in gorm or also to tooltips

Re: NSString bug with test and really dodgy patch.

Richard Frith-Macdonald wrote: We could probably adapt your patch to use precision as string lengh in those cases where it will work, but you can't catch all cases that way ... so maybe it's better if people find out as soon as possible that c-strings have to be nul terminated. Sorry

Re: Graphos: works on Cocoa not on GNUstep

Hi Riccardo, This code works on OS X either because Cocoa is returning a preallocated color (you might try whether copying a text object with some non-standard color works) or because Cocoa uses a cache of color objects. On my version, I did not get a crash for both standard as randomly

Re: Graphos: works on Cocoa not on GNUstep

Riccardo Mottola wrote: Hi, I did a file-frmat change in Graphos: colors are nov saved, represented and copypasted using RGB and not CMYK as it was using as a GDraw derivative. Everything appears to work on Mac. I have problems with copypaste with Graphos on GNUstep when copypasting

Re: Build failed in Jenkins: gnustep #256

Am 10.08.2012 um 17:50 schrieb Gregory Casamento: Yes, I know. I will shut off the notifications and determine the issue. OK, I'll try to be helpful this time. Looking at the full output, I see that Jenkins performs the following build steps: + cd

Re: Build failed in Jenkins: gnustep #256

Gregory Casamento wrote: I turned off notifications for now I'm wondering why I would need to do a distclean since I'm deleting the entire working directory each time. I didn't think I had to. Maybe you intended to clean the working directory before a build, but from the logs it is

  1   2   3   >