Re: Grand Central
This "block thingy" looks interesting. Oh, while we're on the topic of
multi-processors, I've invented an algorithm that allows parallel
lock-less insertions on a linked list. Could be useful for
NSConnections, as it's WAY more efficient than anything else I've ever
seen (and, yes, I am including NSMutableArray methods here). It does
come at a price: it requires an atomic swap operation i.e. assembly.
The good news is that only one instruction is needed so the
portability issue isn't at the "I feel like kissing the barrel of a
shotgun". I'll submit the paper for it as soon as Ive finished
polishing it, shoulda been this week (I am so fuckin' lazy...and
studying...and trying to work, don't ask).
On Sun, Jun 14, 2009 at 10:27 AM, Jens Ayton wrote:
> On Jun 14, 2009, at 14:53, Pete French wrote:
>>
>>>
>>> http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf
>>
>> Interesting - that ^{ syntax to describe a block is somewhat ugly, and it
>> doesnt
>> give any deats of how you associate data with a block (which is necessary
>> if
>> you want to get rid of locks).
>
> There are two ways to pass data into blocks: constant copies from the parent
> scope, and mutable access to "block variables" in the parent scope (the
> latter makes blocks true closures). Here is a simple example:
>
> typedef int (^IntIntBlock)(int);
>
> IntIntBlock MakeExampleThing(int initial, int delta)
> {
> __block int accum = initial;
> int (^block)(int) = ^(int i) { return accum += i + delta; };
> return Block_copy(block);
> }
>
>
> In the block created above, accum is a block variable, and delta is a const
> copy. If MakeExampleThing() is called twice, they get separate copies of
> accum, so there's your data associated with the block. If two blocks were
> created in the same function, both referring to accum, they would share it.
>
> int main(void)
> {
> int (^a)(int) = MakeExampleThing(5, 2);
> int (^b)(int) = MakeExampleThing(1, 0);
>
> printf("%i\n", a(3)); // prints 10
> printf("%i\n", b(1)); // prints 2
>
> Block_release(a);
> Block_release(b);
> return 0;
> }
>
>
> The block runtime is set up to allow blocks to be ObjC objects, so that
> Block_copy() and Block_release() can be replaced with retain and release
> messages. (Block_copy() is conceptually a retain operation, although it
> actually does copy in the above example because the block is initially
> created on the stack.)
>
> In case the new syntax and manual memory management overhead gets in the way
> in the above code, here's a Javascript equivalent:
>
> function MakeExampleThing(initial, delta)
> {
> return function(i)
> {
> return initial += i + delta;
> }
> }
>
>
>> I can't work out if GCD is supposed to be an extension for OSX or an
>> extension
>> to Objective-C itself. Obviously the block syntax requiures a language
>> extension,
>> but how do the bits fit together from there onward ?
>
> Other than blocks, as far as I can see (I don't have Snow Leopard seeds)
> it's "just" a library and an optimized thread scheduler.
>
>
> --
> Jens Ayton
>
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>
--
Besos, abrazos, confeti y aplausos.
Jamie Ramone
"El Vikingo"
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Grand Central
On Mon, Jun 15, 2009 at 6:42 AM, David Chisnall wrote: > On 15 Jun 2009, at 09:28, Jamie Ramone wrote: > >> This "block thingy" looks interesting. Oh, while we're on the topic of >> multi-processors, I've invented an algorithm that allows parallel >> lock-less insertions on a linked list. Could be useful for >> NSConnections, as it's WAY more efficient than anything else I've ever >> seen (and, yes, I am including NSMutableArray methods here). It does >> come at a price: it requires an atomic swap operation i.e. assembly. >> The good news is that only one instruction is needed so the >> portability issue isn't at the "I feel like kissing the barrel of a >> shotgun". I'll submit the paper for it as soon as Ive finished >> polishing it, shoulda been this week (I am so fuckin' lazy...and >> studying...and trying to work, don't ask). > > We're straying off-topic here, but have you read Keir Fraser's PhD thesis? > He presents a lockless way of inserting into a linked list which only > requires an atomic swap and a proof of its correctness. No I haven't, I'll look it up later. Thanx dude. Not that much off-topic as we're mainly talking about concurrency. If you like, we can just splinter this thread and keep presenting different concurrency algorithms to consider and compare there. > EtoileThread and > MediaKit both use a hybrid structure based on the lockless ring buffer from > this thesis (modified to permit it to enter a locked mode when there is no > traffic and avoid polling; if the buffer stays full, there is no locking, > when it empties the consumer thread waits on a condition variable). He also > describes a concurrency-safe skip list implementation; this would be worth > using for NSMutableArray if people want to use it concurrently (or to > provide a GSConcurrentMutableArray, as a thread-safe NSMutableArray > subclass). I don't know much about that, don't really like Etoile and never heard of MediaKit until now. I should point out that my algorithm was created to replace both NSLocks and NSMutableArrays inside of NSConnecions. It is much simpler and smaller, as well as faster. That said there is room for improvement as the other algorithm included for the case where the only reader removes the last remaining element while the writers insert new ones does actually perform a kind of locking (not the ususual kind), but it does so ALL the sime. This detail I must work out in order to publish something usefull to us. But don't worry, I've already got an idea of how to solve this problem... > Atomic compare-and-swap is one of the builtins provided by clang and recent > GCCs. Assembly is only needed while we continue to support archaic > compilers. Aha, and what does that matter? My algorithm and the one you mentioned require an atomic SWAP. T&C's are another type of atomic operation, what I'm talking about is an instruction like the 80x86 exchg one which exchanges the content of two registers or memory addresses. Is this one included? If so...SWEET! > David -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Reimplementation
I'd like to chime in here and say that this approach IS actually a good idea as : 1 ) it does solve the ABI change breakdown problem and 2 ) it is actually much easier to read because it's a prime example of encapsulation and abstraction, so complexity is hidden. The use here of encapsulation and abstraction are precisely (among other reasons) why the object oriented paradigm exists. Leveraging these concepts allow one to concentrate on a specific problem by hiding away the details of the rest behind an API, that of the other objects you're using from within whichever one you're working on. If the code is hard to read then that api is not well defined, so the real problem would be to redefine it so as to make it understandable (read: actually usable). Depending on being able to see all (or most) of the details at once is not a good idea. Another thing I might add is that readability is something rather subjective (though there are generalities like statistics to allow it to be an objective measurement), so it shouldn't be used to choose or dismiss a program writing method. So locality of reference is gone. It gets replaced by messaging an object. OK. So what? Why depend on locality? Again, I'm hard pressed to find an objective way to choose one over the other. If the API of the messaged object is well defined then I find both forms of the code to be equally understandable. But that's my opinion, some may agree and others disagree. So this reasoning is also a bad one for judging the approach. The performance hurting one I like. This is something that CAN actually be measured, so it's perfect for considering this approach. Now, why exactly does it hurt performance? Is the amount lost so much greater than the amount achieved by the overall algorithm used that it performs slower than if that algorithm wasn't used? How fast does the code need to be, minimally? These are the questions one should ask (and answer) in order to move ahead here. So I agree with Richard here. However, if no one else changes the code and you do, and submit a patch as you did, and it does solve the problems you're looking to solve, then I don't see why your patch wouldn't be accepted. -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSound Reimplementation
On Thu, Jul 16, 2009 at 10:37 AM, David Chisnall wrote: > On 16 Jul 2009, at 14:23, Jamie Ramone wrote: > >> I'd like to chime in here and say that this approach IS actually a >> good idea as : >> >> 1 ) it does solve the ABI change breakdown problem and > > Except that it doesn't, it just hides it. Now people subclassing and > referencing variables in the superclass need to explicitly cast a pointer to > a structure. If this structure changes, they need to manually update their > private copy of the ivars and if they don't thing break in exciting ways. > >> 2 ) it is actually much easier to read because it's a prime example of >> encapsulation and abstraction, so complexity is hidden. > > It is not easier to read, because now you need a separate structure > definition, every ivar access has to go via a macro which will look > something like this: > > #define ivar (((struct private_ivars*)_private)->ivar) > > In no possible way is that clearer code. > >> So locality of reference is gone. It gets replaced by messaging an >> object. OK. So what? Why depend on locality? Again, I'm hard pressed >> to find an objective way to choose one over the other. If the API of >> the messaged object is well defined then I find both forms of the code >> to be equally understandable. But that's my opinion, some may agree >> and others disagree. So this reasoning is also a bad one for judging >> the approach. > > Clearly you have no idea what locality of reference means. See here: > > http://en.wikipedia.org/wiki/Locality_of_reference > > In summary, for good performance you want data that is accessed together to > be close together in memory. Both CPUs (via their cache architecture) and > operating systems (via their paging strategy) optimise heavily for this > case. > > Having ivars dangled off on a separate structure means that we now need two > cache lines per object instead of one. Actually, it's worse if you also > factor in subclasses doing this because you need one cache line for the > object and one for each of the subclass structures. This will increase > cache churn considerably. This is very difficult to identify in a > microbenchmark, but it affect performance in larger programs quite > noticeably. These structures, being separately allocated and of different > sizes, may well be on different pages meaning that you will end up with a > lot of more swapping when you are low on memory, which completely cripples > performance. > > The correct solution is to declare no ivars other than ones you are willing > to commit to maintaining in the future in the header, declare them all in > the implementation file, and use non-fragile ivar support in the runtime, > but this requires people to actually test my patch which adds this. > > At the very least, we should just add an unused pointer for future expansion > so that we can add new ivars later and not use this for ivars that are > likely to remain stable for several releases. > > David > I see where you were going, sorry for the mix-up. I do understand what locality means, I just thought you were talking about scope. My bad, just an honest mistake so don't have a cow man :-P Now, if the compiler optimized in such a way that small enough ivars are packed together as one single piece of data, and the needed one is accessed once loaded into a register then there would be a locality problem by separating them. If not, the cache use increases by one piece of data: the pointer to the object. The individual fields would be accessed separately anyway in this case, whether whitin the object or in two separate ones. So there is an increase it is only limited to the ammount of different classes using the approach. You say there's a problem if subclasses do the same, but that wouldn't happen. The separate object for containing the ivars would only be in the public classes of the library in question. There's no reason for a programmer who makes use of that library to do so in any subclass, except maby in those subclasses that are part of some other api API and it's implementation is based on the former. Now, one could optimize it by moving ivars up the hierarchy. But if the superclasses are also public the ABI would break, and on the other ones (non-public ones) the risk of having potentialy usless ivars, thus increasing memory usage. If the separate-object is used as proposed (not with the non-optimization previously pointed out), the object's creation could be delayed until one of those ivar's are needed i.e. a lazy approach. This way the memory usage is minimal, as far as this aproach allows. That macro puzzles me. Why would you have a macro to access and ivar that way? B
Re: Some questions about GNUStep
On Mon, Jun 14, 2010 at 2:29 PM, Philippe Laporte wrote: > Hi all, > > In order to figure out how to best contribute to the development efforts, I > have a few questions: > > How far are you for MAC OS X 10.5 level support in the AppKit? > > Has anyone started retargeting to other than X11 for Linux, like SDL? Yes, I'm building a GNUstep-specific windowing server whose (included) screen drawing, keyboard and handling modules are SDL based. > How do you avoid needing Core Foundation? > > What exactly is in core/gui/Headers/Additions/GNUStepGUI? > > Thanks and, > Best Regards, > Philippe Laporte > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Some questions about GNUStep
On Mon, Jun 21, 2010 at 6:52 PM, Philippe Laporte wrote: > > > Jamie Ramone wrote: > > On Mon, Jun 14, 2010 at 2:29 PM, Philippe Laporte > wrote: > > > Hi all, > > In order to figure out how to best contribute to the development efforts, I > have a few questions: > > How far are you for MAC OS X 10.5 level support in the AppKit? > > Has anyone started retargeting to other than X11 for Linux, like SDL? > > > Yes, I'm building a GNUstep-specific windowing server whose (included) > screen drawing, keyboard and handling modules are SDL based. > > > What is a GNUStep-specific Windowing Server? What is GNUStep-specific? That means it's written both with GNUstep in mind as the toolkit of choice (until a new one is created) for creating apps with a consistent look and feel, and USING GNUstep to do it. I'm using GNUstep to write the most of the skeletal parts, especially the application communication facillities (through DO), and plain C for things like the ADTs (such as the main window database and depth-ordering list). The idea is that when using this server, you HAVE to use GNUstep as it's completly incompatible with X. As a bonus, if my server catches on, it'll boost GNUstep's popularity. > Have you thought of using OpenGL instead of SDL for the drawing? I prefer SDL, I only need 2D capability. OpenGL has WAY too much stuff I'll probably never use and I would have to learn it's API. SDL is small and I'm already familliar with it. So as you can see, using with it cuts the developement time drastically ;-) SDL also works on MS Windows, OS X and X Windows, as well as from the Linux console. In my experience, it works so-so on X Windows, pathetically on Windows (yes, yes, I know that's MS' fault) and don't know on OS X. So I'll stick to my guns. That being said, it'll be a ) freedomware and b ) easily extensible. So there's no reason OpenGL couldn't be used down the road. In my view, being OpenGL mainly a 3D modeling library and the software backend is the only consistent one across platforms (OK, OK, Quake is my criteria, so sue me!), it only makes sense to use something like SDL for the server's backend and OpenGL for some thing like the 3DKit, and let it either access the hardware directly with some coordination thith the server wia InterceptorKit (yet to come) or using the software backend which would use the server itself. Hope that clears any doubt. > Thanks, > Philippe Laporte > -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Issues on WindowMaker
I know that GCC can localize the messages, that can be enabled at compile time. But I'm afraid I don't know how to choose the locale at run time. Perhaps with the LANG environment variable (like $LANG=en_US or something like that)? A lot of software, GNU included, seems to use it for determining the locale. Also, in the documentation, did you also check the GCC info pages. Distro speciffic docs like pre-installed html how-to and intoduction manuals aren't always helpfull when it comes to "under the hood" things. On Mon, May 30, 2011 at 9:07 PM, Germán Arias wrote: > On dom, 2011-05-29 at 20:53 +0200, Fred Kiefer wrote: >> > >> > I ignore all warnings about unused variables. >> >> All these warnings are rather harmless. (BTW, did you translate them >> back from Spanish into English?) > > Yes, after install GCC I notice all is in spanish and I don't know if > there is an option to switch it to english (at documentation I don't see > anything about this). > >> >> I would be interested in the unused variables warnings you are getting >> for gui and back, though. >> > > Here the unused variables in GUI, none in Back. (I don't translate it, > since all these are unused variables): > > GUI > === > > NSActionCell.m:401:10: aviso: se define la variable ‘dummy’ pero no se > usa [-Wunused-but-set-variable] > > NSPrintOperation.m:1035:14: aviso: se define la variable ‘pageRect’ pero > no se usa [-Wunused-but-set-variable] > > GSLayoutManager.m:501:7: aviso: se define la variable ‘positions’ pero > no se usa [-Wunused-but-set-variable] > > GSHorizontalTypesetter.m:700:13: aviso: se define la variable ‘last_p’ > pero no se usa [-Wunused-but-set-variable] > > GSspell.m:464:7: aviso: se define la variable ‘words’ pero no se usa > [-Wunused-but-set-variable] > > SndfileSource.m:86:11: aviso: variable ‘range’ sin usar > [-Wunused-variable] > > RTFProducer.m:1162:12: aviso: se define la variable ‘loc’ pero no se usa > [-Wunused-but-set-variable] > > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: OT: OPENSTEP on VirtualBox?
I used the same exact instructions to install it on VirtualBox as 4 VMWare. I actually have sound on this 1 ;-) No network though, bummer. The mouse does work better, but not good enough yet. Anyway, on VirtualBox u should use a Sound Blaster (virtual) card to have sound and u don't need any special video driver, just the 2YK patch after installing the system. The rest is pretty much the same. Hope that helps. On Tue, Aug 16, 2011 at 10:53 PM, David Wetzel wrote: > Hi folks, > > which settings should I use for openstep on VirtualBox? > It used to work on my old VMWare fusion but I would like to use it on VB on > my lion machine :-) > > Thanks and greetings from Montreal :-) > > David > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH 21/21] Fixed typo.
Actually, it means "if and only if". It translates to [image: \Leftrightarrow](double implication) or [image: \equiv] (equivalence), which are the same thing, in mathematics and naturally, in computer science. On Wed, Feb 27, 2013 at 7:51 PM, Jean-Charles BERTIN wrote: > Didn't know that "iff" means "if and exactly if" but we have the > same abbreviation in french: "ssi" for "si et seulement si" ! > > On Wed, 2013-02-27 at 22:24 +0100, Fred Kiefer wrote: > > On 27.02.2013 17:29, Jean-Charles BERTIN wrote: > > > --- > > > Headers/Foundation/NSGeometry.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > I think the use of "iff" here wasn't a typo, it was rather intentional. > > In mathematical and computer science contexts "iff" gets used quite > > often to mean "if and exactly if", that is when the implication holds in > > both directions. > > > > -- > Jean-Charles BERTIN > Axinoe - Software Engineer > Tel.: (+33) (0)1.80.82.59.23 > Fax : (+33) (0)1.80.82.59.29 > Skype: jcbertin > Web: <http://www.axinoe.com/> > Certificate Authority: <https://ca.axinoe.com/axinoe-root.crt> > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Objective-C boilerplate header (sort of like boost)
Colorful text is colorful! So what is this "boilerplate" thing exactly?
I've heard the expression before but not quite sure what it refers to.
On Wed, Jun 12, 2013 at 12:25 PM, Maxthon Chan wrote:
> Do you guys have a boilerplate that you are very used to build code on top
> of? I have one like this (sans include guard which depend on header file
> name):
>
> #include
> #include
> #include
> #include
> #include
>
> // Feature testers
>
> #ifndef __has_feature
> #define __has_feature(x) 0
> #endif
>
> #ifndef __has_builtin
> #define __has_builtin(x) 0
> #endif
>
> #ifndef __has_extension
> #define __has_extension(x) 0
> #endif
>
> #ifndef __has_attribute
> #define __has_attribute(x) 0
> #endif
>
> // __inline
>
> #if __has_attribute(always_inline)
> #define __inline static inline __attribute__((always_inline))
> #else // !__has_attribute(always_inline)
> #define __inline static inline
> #endif// __has_attribute(always_inline)
>
> // __restrict
>
> #ifndef __cplusplus
> #ifndef __restrict
> #if __STDC_VERSION__ >= 199901L
> #define __restrict restrict
> #else // __STDC_VERSION__ < 199901L
> #define __restrict
> #endif // __STDC_VERSION__ >= 199901L
> #endif // !defined(__restrict)
> #endif // !defined(__cplusplus)
>
> // noreturn (__noreturn and unreachable())
>
> #if __has_attribute(noreturn)
> #define __noreturn __attribute__((noreturn))
> #if __has_builtin(__builtin_unreachable)
> #define unreachable() __builtin_unreachable()
> #else // !__has_builtin(__builtin_unreachable)
> #define unreachable() do {} while (0)
> #endif // __has_builtin(unreachable)
> #else // !__has_attribute(noreturn)
> #define __noreturn
> #define unreachable() do {} while (0)
> #endif // __has_attribute(noreturn)
>
> // Deprecated/unavalible with messages
>
> #undef __deprecated
> #undef __unavailable
>
> #if __has_attribute(deprecated)
> #if __has_extension(attribute_deprecated_with_message)
> #define __deprecated(_msg) __attribute__((deprecated(_msg)))
> #else // !__has_extension(attribute_deprecated_with_message)
> #define __deprecated(_msg) __attribute__((deprecated))
> #endif // __has_extension(attribute_deprecated_with_message)
> #else // !__has_attribute(deprecated)
> #define __deprecated(_msg)
> #endif // __has_attribute(deprecated)
>
> #if __has_attribute(unavailable)
> #if __has_extension(attribute_unavailable_with_message)
> #define __unavailable(_msg) __attribute__((unavailable(_msg)))
> #else // !__has_extension(attribute_unavailable_with_message)
> #define __unavailable(_msg) __attribute__((unavailable))
> #endif // __has_extension(attribute_unavailable_with_message)
> #else // !__has_attribute(unavailable)
> #define __unavailable(_msg)
> #endif // __has_attribute(unavailable)
>
> #if __has_extension(enumerator_attributes)
> #define __e_deprecated(_msg) __deprecated(_msg)
> #define __e_unavailable(_msg) __unavailable(_msg)
> #else // !__has_extension(enumerator_attributes)
> #define __e_deprecated(_msg)
> #define __e_unavailable(_msg)
> #endif // __has_extension(enumerator_attributes)
>
> // Format strings
>
> #if __has_attribute(format)
> #define __format(...) __attribute__((format(__VA_ARGS__)))
> #else // __has_attribute(format)
> #define __format(...)
> #endif
>
> // C-safe Objective-C type declaration
>
> #if defined(__OBJC__)
> #import
> #define __class @class
> #else // !defined(__OBJC__)
> #include
> #define __class typedef struct objc_object
> #endif // defined(__OBJC__)
>
> // Objective-C instancetype
>
> #if defined(__OBJC__)
> #if !__has_feature(objc_instancetype)
> typedef id instancetype
> #endif // !__has_feature(objc_instancetype)
> #endif // defined(__OBJC__)
>
> // Enumerations
>
> #define __enum(_name, _type) enum _name : _type; enum _name
>
> // Some convenience Objective-C functions and macros
>
> __class NSString;
> #define NSStringConstant(_name, _value) extern NSString *const _name;
>
> #if defined(__OBJC__)
> __BEGIN_DECLS
>
> __inline __format(NSString, 1, 0) NSString *NSSTRv(NSString *format,
> va_list args)
> {
> NSString *string = [[NSString alloc] initWithFormat:format
> arguments:args];
> #if !__has_feature(objc_arc) && !__has_feature(objc_gc)
> [string autorelease];
> #endif
> return string;
> }
>
> __inline __format(NSString, 1, 2) NSString *NSSTR(NSString *format, ...)
> {
> va_list args;
> va_start(args, format);
> NSString *string = NSSTRv(format, args);
> va_end(args);
> return string;
> }
>
> __END_DECLS
> #endif // defined(__OBJC__)
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
--
Besos, abrazos, confeti y aplausos.
Jamie Ramone
"El Vikingo"
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Objective-C boilerplate header (sort of like boost)
Why...would anyone want to do that? The whole point of OOP is to hide
details so as to allow programmers to concentrate on one thing at a time
(while giving us the bonus of modular, reusable, easily maintainable code).
Why would you want/need to unhide details?
On Fri, Jun 14, 2013 at 2:59 AM, Maxthon Chan wrote:
> Copied from Xcode and Mail saved all formatting from code highlighting as
> RTF. The code boilerplate is what I always use as a start point of my code.
> It makes it possible to expose some Objective-C code as plain C/C++ as I
> did in CGIKit 5, and it detects compiler. I have a newer version that does
> easy string constant too.
>
> Sent from my iPhone
>
> On 2013年6月14日, at 13:51, Jamie Ramone wrote:
>
> Colorful text is colorful! So what is this "boilerplate" thing exactly?
> I've heard the expression before but not quite sure what it refers to.
>
>
> On Wed, Jun 12, 2013 at 12:25 PM, Maxthon Chan wrote:
>
>> Do you guys have a boilerplate that you are very used to build code on
>> top of? I have one like this (sans include guard which depend on header
>> file name):
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> // Feature testers
>>
>> #ifndef __has_feature
>> #define __has_feature(x) 0
>> #endif
>>
>> #ifndef __has_builtin
>> #define __has_builtin(x) 0
>> #endif
>>
>> #ifndef __has_extension
>> #define __has_extension(x) 0
>> #endif
>>
>> #ifndef __has_attribute
>> #define __has_attribute(x) 0
>> #endif
>>
>> // __inline
>>
>> #if __has_attribute(always_inline)
>> #define __inline static inline __attribute__((always_inline))
>> #else // !__has_attribute(always_inline)
>> #define __inline static inline
>> #endif// __has_attribute(always_inline)
>>
>> // __restrict
>>
>> #ifndef __cplusplus
>> #ifndef __restrict
>> #if __STDC_VERSION__ >= 199901L
>> #define __restrict restrict
>> #else // __STDC_VERSION__ < 199901L
>> #define __restrict
>> #endif // __STDC_VERSION__ >= 199901L
>> #endif // !defined(__restrict)
>> #endif // !defined(__cplusplus)
>>
>> // noreturn (__noreturn and unreachable())
>>
>> #if __has_attribute(noreturn)
>> #define __noreturn __attribute__((noreturn))
>> #if __has_builtin(__builtin_unreachable)
>> #define unreachable() __builtin_unreachable()
>> #else // !__has_builtin(__builtin_unreachable)
>> #define unreachable() do {} while (0)
>> #endif // __has_builtin(unreachable)
>> #else // !__has_attribute(noreturn)
>> #define __noreturn
>> #define unreachable() do {} while (0)
>> #endif // __has_attribute(noreturn)
>>
>> // Deprecated/unavalible with messages
>>
>> #undef __deprecated
>> #undef __unavailable
>>
>> #if __has_attribute(deprecated)
>> #if __has_extension(attribute_deprecated_with_message)
>> #define __deprecated(_msg) __attribute__((deprecated(_msg)))
>> #else // !__has_extension(attribute_deprecated_with_message)
>> #define __deprecated(_msg) __attribute__((deprecated))
>> #endif // __has_extension(attribute_deprecated_with_message)
>> #else // !__has_attribute(deprecated)
>> #define __deprecated(_msg)
>> #endif // __has_attribute(deprecated)
>>
>> #if __has_attribute(unavailable)
>> #if __has_extension(attribute_unavailable_with_message)
>> #define __unavailable(_msg) __attribute__((unavailable(_msg)))
>> #else // !__has_extension(attribute_unavailable_with_message)
>> #define __unavailable(_msg) __attribute__((unavailable))
>> #endif // __has_extension(attribute_unavailable_with_message)
>> #else // !__has_attribute(unavailable)
>> #define __unavailable(_msg)
>> #endif // __has_attribute(unavailable)
>>
>> #if __has_extension(enumerator_attributes)
>> #define __e_deprecated(_msg) __deprecated(_msg)
>> #define __e_unavailable(_msg) __unavailable(_msg)
>> #else // !__has_extension(enumerator_attributes)
>> #define __e_deprecated(_msg)
>> #define __e_unavailable(_msg)
>> #endif // __has_extension(enumerator_attributes)
>>
>> // Format strings
>>
>> #if __has_attribute(format)
>> #define __format(...) __attribute__((format(__VA_ARGS__)))
>> #else // __has_attribute(format)
>> #define __format(...)
>> #endif
>>
>> // C-safe Objective-C type declaration
>>
>> #if defined(__OBJC__)
>> #import
>> #define __class @class
>> #else // !defined(__OBJC__)
>> #include
>
Re: Preliminary Debian packaging support
Ivan, if you (or anyone else reading this) are interested, here's what I'm using for my distro (see attachment). It's sort of a compromise between NEXTSTEP/OPENSTEP, Rhapsody and Mac OS X. I'll eventually change the System prefix here to the distro's name. For now I'm just using a more generic approach, If anyone wants to include it into GNUstep, I don't mind. On Fri, Sep 20, 2013 at 3:28 AM, Ivan Vučica wrote: > On Friday, September 20, 2013, Philippe Roussel wrote: > >> >> Great, thanks for your work. This could be a great way to offer fresh >> deb packages to potential users, > > > Hopefully that'll be so :-) > > >> even if those packages aren't >> entirely debian compliant. >> >> > I probably won't even try to make them compliant for quite some time :-) > > For example, I'm currently installing stuff into /GNUstep and I'm happy > with that. If we reach the stage where someone sits down and works on a > Debian/Ubuntu remaster which we can give to people as an example GNUstep > system (maybe even a live CD!), I'd even go for moving to an OS X-like > directory structure (/System/Library, /Library, ~/Library and > ~/Library/Preferences). > > Anyway, the .deb packages produced now seems to work and I'm uploading the > test versions. Allnighters rock. > > PS One still needs to add that pesky /etc/ld.so.conf.d/GNUstep.conf file, > but that's tolerable and easily fixable in the future. And, gnustep-make > has been configured to use clang, so -- install clang. Also, > gnustep-make/Master/deb.make has "/GNUstep" hardcoded in one place and was > generally not tested with the various variations of filesystem layouts... > so - caveat. > > PPS The script for installing on Ubuntu that I've put on bitbucket has > also been updated. Set environment variable WITH_DEB to 1 and, besides a > nice up-to-date installation of GNUstep in /GNUstep, you'll also get a set > of .deb packages you can install on other machines or after rm -rf /GNUstep. > > > -- > Ivan Vučica > i...@vucica.net > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > -- Besos, abrazos, confeti y aplausos. Jamie Ramone "El Vikingo" FreedomStep.layout Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Serious GORM bug
Hi there steppers! OK, here's the deal: I'v been playing around with GORM making a demo of an extended scroll view (a subclass of NSScrollView with some practical general purpose extensions) and I came across a connection-related bug in GORM. Apparently, (manually) connecting any object to any object in the document window makes GORM barf with a segfault. Connecting objects inside of a window, panel, or menu (i.e. belonging to the document but NOT dropping the conection icon in the document window but rather in one of there) seems to work fine, though I haven't tested this extensively. I believe I have the most recent version and haven't seen any notice of new versions since building this one. The specific version is 1.2.17. And as far as the GNUstep libs I'm using the previous version and GORM is linked against them. This bug is a total show stopper for me and, if anyone else is affected, I believe it would be for them as well. Greg, could you please look into this? Thanx! -- ¡Besos, abrazos, confetti y aplausos! Jamie "El Vikingo" Ramone ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Well, I'm on an Ubuntu 12.04 system, my computer is a 64bit AMD Phemon (6 processors), I recently recompiled GNUstep from scratch because the entire system died (not sure what caused it but the UI never came back so I had to reinstall the system). Also, I'm using WindowMaker as unity has pretty much...inflamed my gonads by now. I avoid the prebuilt ubuntu like a lepper in the middle ages, everyting is compiled by me here. GNUstep, GORM, Project Center, the whole sh'bang. Anything else you need to know? -- ¡Besos, abrazos, confetti y aplausos! Jamie "El Vikingo" Ramone On Fri, Dec 27, 2013 at 6:24 PM, Gregory Casamento wrote: > Hey Jamie, > > Could you give us some information about your environment? > > Greg > > On Dec 27, 2013, at 4:11 PM, Jamie Ramone wrote: > > > Hi there steppers! OK, here's the deal: I'v been playing around with > GORM making a demo of an extended scroll view (a subclass of NSScrollView > with some practical general purpose extensions) and I came across a > connection-related bug in GORM. Apparently, (manually) connecting any > object to any object in the document window makes GORM barf with a > segfault. Connecting objects inside of a window, panel, or menu (i.e. > belonging to the document but NOT dropping the conection icon in the > document window but rather in one of there) seems to work fine, though I > haven't tested this extensively. I believe I have the most recent version > and haven't seen any notice of new versions since building this one. The > specific version is 1.2.17. And as far as the GNUstep libs I'm using the > previous version and GORM is linked against them. This bug is a total show > stopper for me and, if anyone else is affected, I believe it would be for > them as well. Greg, could you please look into this? Thanx! > > > > -- > > ¡Besos, abrazos, confetti y aplausos! > > Jamie "El Vikingo" Ramone > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Thanx man! Oh just a plus: I don't use the new language runtime (libobjc 2). Also, I found that connecting FROM an object in the document window TO a control on a window seems to work fine. On Sat, Dec 28, 2013 at 10:19 AM, Gregory Casamento < greg.casame...@gmail.com> wrote: > No, nothing more needed I'll check it out thanks. > > > On Friday, December 27, 2013, Jamie Ramone wrote: > >> Well, I'm on an Ubuntu 12.04 system, my computer is a 64bit AMD Phemon (6 >> processors), I recently recompiled GNUstep from scratch because the entire >> system died (not sure what caused it but the UI never came back so I had to >> reinstall the system). Also, I'm using WindowMaker as unity has pretty >> much...inflamed my gonads by now. I avoid the prebuilt ubuntu like a lepper >> in the middle ages, everyting is compiled by me here. GNUstep, GORM, >> Project Center, the whole sh'bang. Anything else you need to know? >> >> -- >> ¡Besos, abrazos, confetti y aplausos! >> Jamie "El Vikingo" Ramone >> >> On Fri, Dec 27, 2013 at 6:24 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> Hey Jamie, >>> >>> Could you give us some information about your environment? >>> >>> Greg >>> >>> On Dec 27, 2013, at 4:11 PM, Jamie Ramone wrote: >>> >>> > Hi there steppers! OK, here's the deal: I'v been playing around with >>> GORM making a demo of an extended scroll view (a subclass of NSScrollView >>> with some practical general purpose extensions) and I came across a >>> connection-related bug in GORM. Apparently, (manually) connecting any >>> object to any object in the document window makes GORM barf with a >>> segfault. Connecting objects inside of a window, panel, or menu (i.e. >>> belonging to the document but NOT dropping the conection icon in the >>> document window but rather in one of there) seems to work fine, though I >>> haven't tested this extensively. I believe I have the most recent version >>> and haven't seen any notice of new versions since building this one. The >>> specific version is 1.2.17. And as far as the GNUstep libs I'm using the >>> previous version and GORM is linked against them. This bug is a total show >>> stopper for me and, if anyone else is affected, I believe it would be for >>> them as well. Greg, could you please look into this? Thanx! >>> > >>> > -- >>> > ¡Besos, abrazos, confetti y aplausos! >>> > Jamie "El Vikingo" Ramone >>> >>> >> > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
K, here's what I got:
(gdb) file /SystemApps/Gorm.app/Gorm
Reading symbols from /SystemApps/Gorm.app/Gorm...done.
(gdb) r
Starting program: /SystemApps/Gorm.app/Gorm
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
2013-12-28 18:09:25.880 Gorm[3541] File GSDictionary.m: 455. In
-[GSMutableDictionary removeObjectForKey:] attempt to remove nil key from
dictionary {}
Program received signal SIGSEGV, Segmentation fault.
-[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xb4bd20)
at NSWindow.m:4288
4288NSWindow.m: No such file or directory.
(gdb) bt
#0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
theEvent=0xb4bd20)
at NSWindow.m:4288
#1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
self=0xc22440, _cmd=, theEvent=0xd52c80, slidePoint=...)
at GSDragView.m:720
#2 0x771e in -[GSDragView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
_cmd=, anImage=0x7b0fe0,
screenLocation=..., initialOffset=..., event=0xda00a0,
pboard=, sourceObject=0xcb8bc0, slideFlag=1 '\001')
at GSDragView.m:290
#3 0x7049b254 in -[XGDragView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
_cmd=, anImage=0x7b0fe0,
screenLocation=..., initialOffset=..., event=0xda00a0, pboard=0xd87800,
sourceObject=0xcb8bc0, slideFlag=1 '\001') at XGDragView.m:228
#4 0x771d361a in -[NSWindow
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcab1a0,
_cmd=, anImage=0x7b0fe0,
baseLocation=..., initialOffset=..., event=0xda00a0,
pboard=, sourceObject=, slideFlag=1
'\001')
at NSWindow.m:4548
#5 0x771bd7a8 in -[NSView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcb8bc0,
_cmd=, anImage=0x7b0fe0,
viewLocation=..., initialOffset=..., event=0xda00a0,
pboard=, sourceObject=, slideFlag=1
'\001')
---Type to continue, or q to quit---
at NSView.m:3858
#6 0x77b2983c in -[GormObjectEditor mouseDown:] (self=0xcb8bc0,
_cmd=, theEvent=0xda00a0) at GormObjectEditor.m:481
#7 0x771df003 in -[NSWindow sendEvent:] (self=0xcab1a0,
_cmd=, theEvent=0xda00a0) at NSWindow.m:3790
#8 0x77052fc5 in -[NSApplication run] (self=0x8b99d0,
_cmd=) at NSApplication.m:1562
#9 0x77032945 in NSApplicationMain (argc=,
argv=) at Functions.m:91
#10 0x75ee676d in __libc_start_main ()
from /lib/x86_64-linux-gnu/libc.so.6
#11 0x00401965 in _start ()
(gdb)
For this I started out with an empty document (Document>New Module>New
Empty), added a window and attempted to make a connection from the window
to NSOwner, within the document window. Next I'll try between a control and
NSOwner.
On Sat, Dec 28, 2013 at 4:52 PM, Gregory Casamento wrote:
> Gorm shouldn't require anything in the new runtime. I've tried creating
> connections between several objects in the document window. I can't seem
> to reproduce this issue.
>
> Could you run in GDB and provide me a backtrace? I will continue to test
> things here to see if I can reproduce the issue.
>
> Greg
>
>
> On Sat, Dec 28, 2013 at 1:40 PM, Jamie Ramone wrote:
>
>> Thanx man! Oh just a plus: I don't use the new language runtime (libobjc
>> 2). Also, I found that connecting FROM an object in the document window TO
>> a control on a window seems to work fine.
>>
>>
>> On Sat, Dec 28, 2013 at 10:19 AM, Gregory Casamento <
>> greg.casame...@gmail.com> wrote:
>>
>>> No, nothing more needed I'll check it out thanks.
>>>
>>>
>>> On Friday, December 27, 2013, Jamie Ramone wrote:
>>>
>>>> Well, I'm on an Ubuntu 12.04 system, my computer is a 64bit AMD Phemon
>>>> (6 processors), I recently recompiled GNUstep from scratch because the
>>>> entire system died (not sure what caused it but the UI never came back so I
>>>> had to reinstall the system). Also, I'm using WindowMaker as unity has
>>>> pretty much...inflamed my gonads by now. I avoid the prebuilt ubuntu like a
>>>> lepper in the middle ages, everyting is compiled by me here. GNUstep, GORM,
>>>> Project Center, the whole sh'bang. Anything else you need to know?
>>>>
>>>> --
>>>> ¡Besos, abrazos, confetti y aplausos!
>>>> Jamie "El Vikingo" Ramone
>>>>
>>>> On Fri, Dec 27, 2013 at 6:24 PM, Gregory Casamento <
>>>> greg.casame...@gmail.com> wrote:
>>>>
>>>>> Hey Jamie,
>>>>>
>>>>> Could you give us some information about your environment?
>>>>>
>>>>> Greg
>&
Re: Serious GORM bug
Here's the 2nd test:
(gdb) file /SystemApps/Gorm.app/Gorm
Reading symbols from /SystemApps/Gorm.app/Gorm...done.
(gdb) r
Starting program: /SystemApps/Gorm.app/Gorm
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
-[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0x10e59a0)
at NSWindow.m:4288
4288NSWindow.m: No such file or directory.
(gdb) bt
#0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
theEvent=0x10e59a0)
at NSWindow.m:4288
#1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
self=0xad5c80, _cmd=, theEvent=0x1110160, slidePoint=...)
at GSDragView.m:720
#2 0x771e in -[GSDragView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
_cmd=, anImage=0x7b2300,
screenLocation=..., initialOffset=..., event=0x8c7470,
pboard=, sourceObject=0xd35030, slideFlag=1 '\001')
at GSDragView.m:290
#3 0x7049b254 in -[XGDragView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
_cmd=, anImage=0x7b2300,
screenLocation=..., initialOffset=..., event=0x8c7470, pboard=0xc49240,
sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228
#4 0x771d361a in -[NSWindow
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900,
_cmd=, anImage=0x7b2300,
baseLocation=..., initialOffset=..., event=0x8c7470,
pboard=, sourceObject=, slideFlag=1
'\001')
at NSWindow.m:4548
#5 0x771bd7a8 in -[NSView
dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030,
_cmd=, anImage=0x7b2300,
viewLocation=..., initialOffset=..., event=0x8c7470,
pboard=, sourceObject=, slideFlag=1
'\001')
at NSView.m:3858
#6 0x77b3f569 in -[GormViewEditor
startConnectingObject:withEvent:] (
self=0xd35030, _cmd=, anObject=,
theEvent=0x8c7470) at GormViewEditor.m:1203
#7 0x77b368b1 in -[GormScrollViewEditor mouseDown:]
(self=0xd35030,
_cmd=, theEvent=0x8c7470) at GormScrollViewEditor.m:123
#8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900,
_cmd=, theEvent=0x8c7470) at NSWindow.m:3790
#9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0,
_cmd=) at NSApplication.m:1562
#10 0x77032945 in NSApplicationMain (argc=,
argv=) at Functions.m:91
#11 0x75ee676d in __libc_start_main ()
from /lib/x86_64-linux-gnu/libc.so.6
#12 0x00401965 in _start ()
(gdb)
Same as before, but with a tableview in a new window, and making the
connection from it to NSOwner.
On Sat, Dec 28, 2013 at 6:19 PM, Jamie Ramone wrote:
> K, here's what I got:
>
> (gdb) file /SystemApps/Gorm.app/Gorm
> Reading symbols from /SystemApps/Gorm.app/Gorm...done.
> (gdb) r
> Starting program: /SystemApps/Gorm.app/Gorm
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 2013-12-28 18:09:25.880 Gorm[3541] File GSDictionary.m: 455. In
> -[GSMutableDictionary removeObjectForKey:] attempt to remove nil key from
> dictionary {}
>
> Program received signal SIGSEGV, Segmentation fault.
> -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xb4bd20)
> at NSWindow.m:4288
> 4288NSWindow.m: No such file or directory.
> (gdb) bt
> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
> theEvent=0xb4bd20)
> at NSWindow.m:4288
> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
> self=0xc22440, _cmd=, theEvent=0xd52c80, slidePoint=...)
> at GSDragView.m:720
> #2 0x771e in -[GSDragView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
> _cmd=, anImage=0x7b0fe0,
> screenLocation=..., initialOffset=..., event=0xda00a0,
> pboard=, sourceObject=0xcb8bc0, slideFlag=1 '\001')
> at GSDragView.m:290
> #3 0x7049b254 in -[XGDragView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
> _cmd=, anImage=0x7b0fe0,
> screenLocation=..., initialOffset=..., event=0xda00a0,
> pboard=0xd87800,
> sourceObject=0xcb8bc0, slideFlag=1 '\001') at XGDragView.m:228
> #4 0x771d361a in -[NSWindow
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcab1a0,
> _cmd=, anImage=0x7b0fe0,
> baseLocation=..., initialOffset=..., event=0xda00a0,
> pboard=, sourceObject=, slideFlag=1
> '\001')
> at NSWindow.m:4548
> #5 0x771bd7a8 in -[NSView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xcb8bc0,
> _cmd=, anImage=0x7b0fe0,
> viewLocation=..., initialOffset=..., event=0xda00a0,
> pboard=, sourceObject=, slideFlag=1
> '\001')
> ---Type to continue, or q
Re: Serious GORM bug
What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent
method. While that doesn't seem right, nil is a valid receiver as far as
the runtime's concerned. So I'n still unsure of the cause of the segfault.
Let me know what you find Greg.
On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone wrote:
> Here's the 2nd test:
>
> (gdb) file /SystemApps/Gorm.app/Gorm
> Reading symbols from /SystemApps/Gorm.app/Gorm...done.
> (gdb) r
> Starting program: /SystemApps/Gorm.app/Gorm
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0x10e59a0)
>
> at NSWindow.m:4288
> 4288NSWindow.m: No such file or directory.
> (gdb) bt
> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
> theEvent=0x10e59a0)
>
> at NSWindow.m:4288
> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
> self=0xad5c80, _cmd=, theEvent=0x1110160,
> slidePoint=...)
> at GSDragView.m:720
> #2 0x771e in -[GSDragView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
> _cmd=, anImage=0x7b2300,
> screenLocation=..., initialOffset=..., event=0x8c7470,
> pboard=, sourceObject=0xd35030, slideFlag=1 '\001')
> at GSDragView.m:290
> #3 0x7049b254 in -[XGDragView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80,
> _cmd=, anImage=0x7b2300,
> screenLocation=..., initialOffset=..., event=0x8c7470,
> pboard=0xc49240,
> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228
> #4 0x771d361a in -[NSWindow
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900,
> _cmd=, anImage=0x7b2300,
> baseLocation=..., initialOffset=..., event=0x8c7470,
> pboard=, sourceObject=, slideFlag=1
> '\001')
> at NSWindow.m:4548
> #5 0x771bd7a8 in -[NSView
> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030,
> _cmd=, anImage=0x7b2300,
> viewLocation=..., initialOffset=..., event=0x8c7470,
> pboard=, sourceObject=, slideFlag=1
> '\001')
> at NSView.m:3858
> #6 0x77b3f569 in -[GormViewEditor
> startConnectingObject:withEvent:] (
> self=0xd35030, _cmd=, anObject=,
> theEvent=0x8c7470) at GormViewEditor.m:1203
> #7 0x77b368b1 in -[GormScrollViewEditor mouseDown:]
> (self=0xd35030,
> _cmd=, theEvent=0x8c7470) at GormScrollViewEditor.m:123
> #8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900,
> _cmd=, theEvent=0x8c7470) at NSWindow.m:3790
> #9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0,
> _cmd=) at NSApplication.m:1562
> #10 0x77032945 in NSApplicationMain (argc=,
> argv=) at Functions.m:91
> #11 0x75ee676d in __libc_start_main ()
>from /lib/x86_64-linux-gnu/libc.so.6
> #12 0x00401965 in _start ()
> (gdb)
>
> Same as before, but with a tableview in a new window, and making the
> connection from it to NSOwner.
>
>
> On Sat, Dec 28, 2013 at 6:19 PM, Jamie Ramone wrote:
>
>> K, here's what I got:
>>
>> (gdb) file /SystemApps/Gorm.app/Gorm
>> Reading symbols from /SystemApps/Gorm.app/Gorm...done.
>> (gdb) r
>> Starting program: /SystemApps/Gorm.app/Gorm
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> 2013-12-28 18:09:25.880 Gorm[3541] File GSDictionary.m: 455. In
>> -[GSMutableDictionary removeObjectForKey:] attempt to remove nil key from
>> dictionary {}
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xb4bd20)
>> at NSWindow.m:4288
>> 4288NSWindow.m: No such file or directory.
>> (gdb) bt
>> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=,
>> theEvent=0xb4bd20)
>> at NSWindow.m:4288
>> #1 0x77201e8c in -[GSDragView(Private) _handleDrag:slidePoint:] (
>> self=0xc22440, _cmd=, theEvent=0xd52c80,
>> slidePoint=...)
>> at GSDragView.m:720
>> #2 0x771e in -[GSDragView
>> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc22440,
>> _cmd=, anImage=0x7b0fe0,
>> screenLocation=..., initialOffset=..., event=0xda00a0,
>> pboard=, sourceObject=0xcb8bc0, slideFlag=1 '\001')
>> at GSDragView.m:290
>> #3 0x7049b254 in -[XGDragView
>> dragImage:at:offset:event:pasteboard:source:slideBack:]
Re: Serious GORM bug
Optimization??? I just use configure and the supplied makefile. Anyway, I'm gonna completely wipe out the current GNUstep installation and build it from scratch. I suspect some corruption crept in with that nasty system crash I had. I reinstalled GNUstep on top of the old installation that time. I'll first use the sources I already had and see if the bug goes away. regardless, I'll update after that. Stand by for updates. On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: > I was not able to reproduce your problem on my system. Maybe more > detailed instructions would be helpful. What I noticed when looking at > your stack trace is that a lot of intermediate methods are left out > there. Which optimisation level are you using for your compiler when > compiling GNUstep gui? > You should also try to print out the event (po theEvent and p *theEvent) > and inspect the window given in the event. This should be the window the > event gets send to. > > Could you please update your GNUstep installation to the latest release? > This makes it easier to compare the line numbers in the stack trace. > > Fred > > On 28.12.2013 22:30, Jamie Ramone wrote: > > What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent > > method. While that doesn't seem right, nil is a valid receiver as far as > > the runtime's concerned. So I'n still unsure of the cause of the > segfault. > > Let me know what you find Greg. > > > > > > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone > wrote: > > > >> Here's the 2nd test: > >> > >> (gdb) file /SystemApps/Gorm.app/Gorm > >> Reading symbols from /SystemApps/Gorm.app/Gorm...done. > >> (gdb) r > >> Starting program: /SystemApps/Gorm.app/Gorm > >> [Thread debugging using libthread_db enabled] > >> Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> -[NSWindow sendEvent:] (self=0x0, _cmd=, > theEvent=0x10e59a0) > >> > >> at NSWindow.m:4288 > >> 4288NSWindow.m: No such file or directory. > >> (gdb) bt > >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, > >> theEvent=0x10e59a0) > >> > >> at NSWindow.m:4288 > >> #1 0x77201e8c in -[GSDragView(Private) > _handleDrag:slidePoint:] ( > >> self=0xad5c80, _cmd=, theEvent=0x1110160, > >> slidePoint=...) > >> at GSDragView.m:720 > >> #2 0x771e in -[GSDragView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, > >> _cmd=, anImage=0x7b2300, > >> screenLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') > >> at GSDragView.m:290 > >> #3 0x7049b254 in -[XGDragView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, > >> _cmd=, anImage=0x7b2300, > >> screenLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=0xc49240, > >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 > >> #4 0x771d361a in -[NSWindow > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900, > >> _cmd=, anImage=0x7b2300, > >> baseLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject=, slideFlag=1 > >> '\001') > >> at NSWindow.m:4548 > >> #5 0x771bd7a8 in -[NSView > >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030, > >> _cmd=, anImage=0x7b2300, > >> viewLocation=..., initialOffset=..., event=0x8c7470, > >> pboard=, sourceObject=, slideFlag=1 > >> '\001') > >> at NSView.m:3858 > >> #6 0x77b3f569 in -[GormViewEditor > >> startConnectingObject:withEvent:] ( > >> self=0xd35030, _cmd=, anObject=, > >> theEvent=0x8c7470) at GormViewEditor.m:1203 > >> #7 0x77b368b1 in -[GormScrollViewEditor mouseDown:] > >> (self=0xd35030, > >> _cmd=, theEvent=0x8c7470) at > GormScrollViewEditor.m:123 > >> #8 0x771df003 in -[NSWindow sendEvent:] (self=0xc40900, > >> _cmd=, theEvent=0x8c7470) at NSWindow.m:3790 > >> #9 0x77052fc5 in -[NSApplication run] (self=0x8b99d0, > >> _cmd=) at NSApplication.m:1562 > >> #10 0x77032945 in NSApplicationMain (argc=, > >> argv=) at Functions.m:91 > >&
Re: Serious GORM bug
OK, recompiled current GNUstep from scratch. Still no luck. Now gonna try the most recent release. Wish me luck! :) On Sat, Dec 28, 2013 at 7:39 PM, Jamie Ramone wrote: > Optimization??? I just use configure and the supplied makefile. Anyway, > I'm gonna completely wipe out the current GNUstep installation and build it > from scratch. I suspect some corruption crept in with that nasty system > crash I had. I reinstalled GNUstep on top of the old installation that > time. I'll first use the sources I already had and see if the bug goes > away. regardless, I'll update after that. Stand by for updates. > > > On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: > >> I was not able to reproduce your problem on my system. Maybe more >> detailed instructions would be helpful. What I noticed when looking at >> your stack trace is that a lot of intermediate methods are left out >> there. Which optimisation level are you using for your compiler when >> compiling GNUstep gui? >> You should also try to print out the event (po theEvent and p *theEvent) >> and inspect the window given in the event. This should be the window the >> event gets send to. >> >> Could you please update your GNUstep installation to the latest release? >> This makes it easier to compare the line numbers in the stack trace. >> >> Fred >> >> On 28.12.2013 22:30, Jamie Ramone wrote: >> > What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent >> > method. While that doesn't seem right, nil is a valid receiver as far as >> > the runtime's concerned. So I'n still unsure of the cause of the >> segfault. >> > Let me know what you find Greg. >> > >> > >> > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone >> wrote: >> > >> >> Here's the 2nd test: >> >> >> >> (gdb) file /SystemApps/Gorm.app/Gorm >> >> Reading symbols from /SystemApps/Gorm.app/Gorm...done. >> >> (gdb) r >> >> Starting program: /SystemApps/Gorm.app/Gorm >> >> [Thread debugging using libthread_db enabled] >> >> Using host libthread_db library >> "/lib/x86_64-linux-gnu/libthread_db.so.1". >> >> >> >> Program received signal SIGSEGV, Segmentation fault. >> >> -[NSWindow sendEvent:] (self=0x0, _cmd=, >> theEvent=0x10e59a0) >> >> >> >> at NSWindow.m:4288 >> >> 4288NSWindow.m: No such file or directory. >> >> (gdb) bt >> >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, >> >> theEvent=0x10e59a0) >> >> >> >> at NSWindow.m:4288 >> >> #1 0x77201e8c in -[GSDragView(Private) >> _handleDrag:slidePoint:] ( >> >> self=0xad5c80, _cmd=, theEvent=0x1110160, >> >> slidePoint=...) >> >> at GSDragView.m:720 >> >> #2 0x771e in -[GSDragView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> >> _cmd=, anImage=0x7b2300, >> >> screenLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') >> >> at GSDragView.m:290 >> >> #3 0x7049b254 in -[XGDragView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> >> _cmd=, anImage=0x7b2300, >> >> screenLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=0xc49240, >> >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 >> >> #4 0x771d361a in -[NSWindow >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900, >> >> _cmd=, anImage=0x7b2300, >> >> baseLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=, slideFlag=1 >> >> '\001') >> >> at NSWindow.m:4548 >> >> #5 0x771bd7a8 in -[NSView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030, >> >> _cmd=, anImage=0x7b2300, >> >> viewLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=, slideFlag=1 >> >> '\001') >> >> at NSView.m:3858 >> >> #6 0x77b3f569 in -[GormViewEditor >> >> startConnectingObject:withEvent:] ( >> >> self=0xd35030, _cmd=, anObject=, >> >> theEvent=0x8c7470) at GormViewEditor.m:1203 >> >> #7 0x00
Re: Serious GORM bug
I'm already on the recent libs (and Gorm). I put it in /SystemLibrary/GNUstep.conf, Tis easier 2 uninstall this way ;-) In any case, no luck. Recent GNUstep, recent Gorm, old bug :-S I DID, however see failed tests in GUI...and looking at the logs it appears to be just because of the backend not being installed yet. Let me check...(goes off to tinker with the code)...Yep, that was it :P On Sat, Dec 28, 2013 at 9:51 PM, Ivan Vučica wrote: > When wiping GNUstep off your system (before a reinstall, of course!), > don't forget /etc/GNUstep.conf -- or something like that. > > > On Sun, Dec 29, 2013 at 12:37 AM, Jamie Ramone wrote: > >> OK, recompiled current GNUstep from scratch. Still no luck. Now gonna try >> the most recent release. Wish me luck! :) >> >> >> On Sat, Dec 28, 2013 at 7:39 PM, Jamie Ramone wrote: >> >>> Optimization??? I just use configure and the supplied makefile. Anyway, >>> I'm gonna completely wipe out the current GNUstep installation and build it >>> from scratch. I suspect some corruption crept in with that nasty system >>> crash I had. I reinstalled GNUstep on top of the old installation that >>> time. I'll first use the sources I already had and see if the bug goes >>> away. regardless, I'll update after that. Stand by for updates. >>> >>> >>> On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: >>> >>>> I was not able to reproduce your problem on my system. Maybe more >>>> detailed instructions would be helpful. What I noticed when looking at >>>> your stack trace is that a lot of intermediate methods are left out >>>> there. Which optimisation level are you using for your compiler when >>>> compiling GNUstep gui? >>>> You should also try to print out the event (po theEvent and p *theEvent) >>>> and inspect the window given in the event. This should be the window the >>>> event gets send to. >>>> >>>> Could you please update your GNUstep installation to the latest release? >>>> This makes it easier to compare the line numbers in the stack trace. >>>> >>>> Fred >>>> >>>> On 28.12.2013 22:30, Jamie Ramone wrote: >>>> > What's common in both is self == nil (self=0x0) in NSWindow's >>>> -sendEvent >>>> > method. While that doesn't seem right, nil is a valid receiver as far >>>> as >>>> > the runtime's concerned. So I'n still unsure of the cause of the >>>> segfault. >>>> > Let me know what you find Greg. >>>> > >>>> > >>>> > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone >>>> wrote: >>>> > >>>> >> Here's the 2nd test: >>>> >> >>>> >> (gdb) file /SystemApps/Gorm.app/Gorm >>>> >> Reading symbols from /SystemApps/Gorm.app/Gorm...done. >>>> >> (gdb) r >>>> >> Starting program: /SystemApps/Gorm.app/Gorm >>>> >> [Thread debugging using libthread_db enabled] >>>> >> Using host libthread_db library >>>> "/lib/x86_64-linux-gnu/libthread_db.so.1". >>>> >> >>>> >> Program received signal SIGSEGV, Segmentation fault. >>>> >> -[NSWindow sendEvent:] (self=0x0, _cmd=, >>>> theEvent=0x10e59a0) >>>> >> >>>> >> at NSWindow.m:4288 >>>> >> 4288NSWindow.m: No such file or directory. >>>> >> (gdb) bt >>>> >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, >>>> >> theEvent=0x10e59a0) >>>> >> >>>> >> at NSWindow.m:4288 >>>> >> #1 0x77201e8c in -[GSDragView(Private) >>>> _handleDrag:slidePoint:] ( >>>> >> self=0xad5c80, _cmd=, theEvent=0x1110160, >>>> >> slidePoint=...) >>>> >> at GSDragView.m:720 >>>> >> #2 0x771e in -[GSDragView >>>> >> dragImage:at:offset:event:pasteboard:source:slideBack:] >>>> (self=0xad5c80, >>>> >> _cmd=, anImage=0x7b2300, >>>> >> screenLocation=..., initialOffset=..., event=0x8c7470, >>>> >> pboard=, sourceObject=0xd35030, slideFlag=1 >>>> '\001') >>>> >> at GSDragView.m:290 >>>> >> #3 0x7049b254 in -[XGDragView >>>> >> dragImage:at:offset:event:pasteboard:so
Re: Serious GORM bug
Dragons??? Are you doing acid Greg? :P Hmm, maybe there's a problem with drag & drop. I'll go ahead and check that. On Sun, Dec 29, 2013 at 1:40 AM, Gregory Casamento wrote: > Part of the problem could be with Dragon and drop itself. Try another > application which uses Dragon to see if that fans. On some systems there > might be a problem with the drag-and-drop daemon. > > > On Saturday, December 28, 2013, Jamie Ramone wrote: > >> OK, recompiled current GNUstep from scratch. Still no luck. Now gonna try >> the most recent release. Wish me luck! :) >> >> >> On Sat, Dec 28, 2013 at 7:39 PM, Jamie Ramone wrote: >> >> Optimization??? I just use configure and the supplied makefile. Anyway, >> I'm gonna completely wipe out the current GNUstep installation and build it >> from scratch. I suspect some corruption crept in with that nasty system >> crash I had. I reinstalled GNUstep on top of the old installation that >> time. I'll first use the sources I already had and see if the bug goes >> away. regardless, I'll update after that. Stand by for updates. >> >> >> On Sat, Dec 28, 2013 at 7:29 PM, Fred Kiefer wrote: >> >> I was not able to reproduce your problem on my system. Maybe more >> detailed instructions would be helpful. What I noticed when looking at >> your stack trace is that a lot of intermediate methods are left out >> there. Which optimisation level are you using for your compiler when >> compiling GNUstep gui? >> You should also try to print out the event (po theEvent and p *theEvent) >> and inspect the window given in the event. This should be the window the >> event gets send to. >> >> Could you please update your GNUstep installation to the latest release? >> This makes it easier to compare the line numbers in the stack trace. >> >> Fred >> >> On 28.12.2013 22:30, Jamie Ramone wrote: >> > What's common in both is self == nil (self=0x0) in NSWindow's -sendEvent >> > method. While that doesn't seem right, nil is a valid receiver as far as >> > the runtime's concerned. So I'n still unsure of the cause of the >> segfault. >> > Let me know what you find Greg. >> > >> > >> > On Sat, Dec 28, 2013 at 6:27 PM, Jamie Ramone >> wrote: >> > >> >> Here's the 2nd test: >> >> >> >> (gdb) file /SystemApps/Gorm.app/Gorm >> >> Reading symbols from /SystemApps/Gorm.app/Gorm...done. >> >> (gdb) r >> >> Starting program: /SystemApps/Gorm.app/Gorm >> >> [Thread debugging using libthread_db enabled] >> >> Using host libthread_db library >> "/lib/x86_64-linux-gnu/libthread_db.so.1". >> >> >> >> Program received signal SIGSEGV, Segmentation fault. >> >> -[NSWindow sendEvent:] (self=0x0, _cmd=, >> theEvent=0x10e59a0) >> >> >> >> at NSWindow.m:4288 >> >> 4288NSWindow.m: No such file or directory. >> >> (gdb) bt >> >> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, >> >> theEvent=0x10e59a0) >> >> >> >> at NSWindow.m:4288 >> >> #1 0x77201e8c in -[GSDragView(Private) >> _handleDrag:slidePoint:] ( >> >> self=0xad5c80, _cmd=, theEvent=0x1110160, >> >> slidePoint=...) >> >> at GSDragView.m:720 >> >> #2 0x771e in -[GSDragView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> >> _cmd=, anImage=0x7b2300, >> >> screenLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=0xd35030, slideFlag=1 '\001') >> >> at GSDragView.m:290 >> >> #3 0x7049b254 in -[XGDragView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xad5c80, >> >> _cmd=, anImage=0x7b2300, >> >> screenLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=0xc49240, >> >> sourceObject=0xd35030, slideFlag=1 '\001') at XGDragView.m:228 >> >> #4 0x771d361a in -[NSWindow >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc40900, >> >> _cmd=, anImage=0x7b2300, >> >> baseLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=, slideFlag=1 >> >> '\001') >> >> at NSWindow.m:4548 >> >> #5 0x771bd7a8 in -[NSView >> >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xd35030, >> >> _cmd=, anImage=0x7b2300, >> >> viewLocation=..., initialOffset=..., event=0x8c7470, >> >> pboard=, sourceObject=> >> > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Not sure yet, but I'd like to note that the upgrade borked the alpha blending on all D&D images :-/ Still looking... Oh, any idea as to which app would be best suited for this test, is there a useful one in the examples tarball? On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento wrote: > Yeah, I know. :( Any ideas with respect to what is wrong with drag and > drop? > > > On Sunday, December 29, 2013, David Chisnall wrote: > >> On 29 Dec 2013, at 12:04, Gregory Casamento >> wrote: >> >> > Well, If I'm doing to dictate, I should at least proofread >> ^ >> >> Good start... >> >> David >> >> >> >> >> -- Sent from my Cray X1 >> >> > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > > ___ > 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: Serious GORM bug
I thought so. So far nothing. I've moved files and folders around, as well as color swatches and nothing. My only gripe is no alpha but apart from that, I'm not having any D&D troubles. In fact, the only app with this problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento wrote: > GWorkspace may be good. > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > >> Not sure yet, but I'd like to note that the upgrade borked the alpha >> blending on all D&D images :-/ Still looking... >> Oh, any idea as to which app would be best suited for this test, is there >> a useful one in the examples tarball? >> >> >> On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> Yeah, I know. :( Any ideas with respect to what is wrong with drag and >>> drop? >>> >>> >>> On Sunday, December 29, 2013, David Chisnall wrote: >>> >>>> On 29 Dec 2013, at 12:04, Gregory Casamento >>>> wrote: >>>> >>>> > Well, If I'm doing to dictate, I should at least proofread >>>> ^ >>>> >>>> Good start... >>>> >>>> David >>>> >>>> >>>> >>>> >>>> -- Sent from my Cray X1 >>>> >>>> >>> >>> -- >>> Gregory Casamento >>> Open Logic Corporation, Principal Consultant >>> yahoo/skype: greg_casamento, aol: gjcasa >>> (240)274-9630 (Cell) >>> http://www.gnustep.org >>> http://heronsperch.blogspot.com >>> >>> ___ >>> Gnustep-dev mailing list >>> Gnustep-dev@gnu.org >>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >>> >>> >> > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Something from the outside? What do you mean, like from another app? But what, could you be more specific? Thanx. In any case here's my most recent test: made two new folders and dragged them around, into the shelf, from there inside of the other one, back home, same thing in revers order...nothing. The only thing that crashed GWorkspace was closing the Trash viewer. On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento wrote: > Moving files and folders around is not what I'm talking about try dragging > something in from outside. > > GC > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > >> I thought so. So far nothing. I've moved files and folders around, as >> well as color swatches and nothing. My only gripe is no alpha but apart >> from that, I'm not having any D&D troubles. In fact, the only app with this >> problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. >> >> >> On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> GWorkspace may be good. >>> >>> >>> On Sunday, December 29, 2013, Jamie Ramone wrote: >>> >>>> Not sure yet, but I'd like to note that the upgrade borked the alpha >>>> blending on all D&D images :-/ Still looking... >>>> Oh, any idea as to which app would be best suited for this test, is >>>> there a useful one in the examples tarball? >>>> >>>> >>>> On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < >>>> greg.casame...@gmail.com> wrote: >>>> >>>>> Yeah, I know. :( Any ideas with respect to what is wrong with drag >>>>> and drop? >>>>> >>>>> >>>>> On Sunday, December 29, 2013, David Chisnall wrote: >>>>> >>>>>> On 29 Dec 2013, at 12:04, Gregory Casamento >>>>>> wrote: >>>>>> >>>>>> > Well, If I'm doing to dictate, I should at least proofread >>>>>> ^ >>>>>> >>>>>> Good start... >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- Sent from my Cray X1 >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Gregory Casamento >>>>> Open Logic Corporation, Principal Consultant >>>>> yahoo/skype: greg_casamento, aol: gjcasa >>>>> (240)274-9630 (Cell) >>>>> http://www.gnustep.org >>>>> http://heronsperch.blogspot.com >>>>> >>>>> ___ >>>>> Gnustep-dev mailing list >>>>> Gnustep-dev@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >>>>> >>>>> >>>> >>> >>> -- >>> Gregory Casamento >>> Open Logic Corporation, Principal Consultant >>> yahoo/skype: greg_casamento, aol: gjcasa >>> (240)274-9630 (Cell) >>> http://www.gnustep.org >>> http://heronsperch.blogspot.com >>> >> >> > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
OK, got it, I'll try that now (between windows, not sure how to do the "between applications" yet). Just a heads up: I did eventually, er, "erase" the folders by selecting them and dragging them to the Recycler's pseudo-appicon and it worked without a hitch. Since Recycler.app is another app I guess that would count. On Sun, Dec 29, 2013 at 5:58 PM, Gregory Casamento wrote: > Between windows or between applications. I believe you’re hitting the > same bug Fred may be hitting, I’m working on a potential fix now. > > Greg > > On Dec 29, 2013, at 3:56 PM, Jamie Ramone wrote: > > > Something from the outside? What do you mean, like from another app? But > what, could you be more specific? Thanx. In any case here's my most recent > test: made two new folders and dragged them around, into the shelf, from > there inside of the other one, back home, same thing in revers > order...nothing. The only thing that crashed GWorkspace was closing the > Trash viewer. > > > > > > On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > > Moving files and folders around is not what I'm talking about try > dragging something in from outside. > > > > GC > > > > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > > I thought so. So far nothing. I've moved files and folders around, as > well as color swatches and nothing. My only gripe is no alpha but apart > from that, I'm not having any D&D troubles. In fact, the only app with this > problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. > > > > > > On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > > GWorkspace may be good. > > > > > > On Sunday, December 29, 2013, Jamie Ramone wrote: > > Not sure yet, but I'd like to note that the upgrade borked the alpha > blending on all D&D images :-/ Still looking... > > Oh, any idea as to which app would be best suited for this test, is > there a useful one in the examples tarball? > > > > > > On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > > Yeah, I know. :( Any ideas with respect to what is wrong with drag and > drop? > > > > > > On Sunday, December 29, 2013, David Chisnall wrote: > > On 29 Dec 2013, at 12:04, Gregory Casamento > wrote: > > > > > Well, If I'm doing to dictate, I should at least proofread > > ^ > > > > Good start... > > > > David > > > > > > > > > > -- Sent from my Cray X1 > > > > > > > > -- > > Gregory Casamento > > Open Logic Corporation, Principal Consultant > > yahoo/skype: greg_casamento, aol: gjcasa > > (240)274-9630 (Cell) > > http://www.gnustep.org > > http://heronsperch.blogspot.com > > > > ___ > > Gnustep-dev mailing list > > Gnustep-dev@gnu.org > > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > > > > > > > -- > > Gregory Casamento > > Open Logic Corporation, Principal Consultant > > yahoo/skype: greg_casamento, aol: gjcasa > > (240)274-9630 (Cell) > > http://www.gnustep.org > > http://heronsperch.blogspot.com > > > > > > > > -- > > Gregory Casamento > > Open Logic Corporation, Principal Consultant > > yahoo/skype: greg_casamento, aol: gjcasa > > (240)274-9630 (Cell) > > http://www.gnustep.org > > http://heronsperch.blogspot.com > > > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Just dragged around folders between 2 viewer windows without a hitch. Let's have a look at the tabbed shelf, that holds just about anything. On Sun, Dec 29, 2013 at 6:02 PM, Jamie Ramone wrote: > OK, got it, I'll try that now (between windows, not sure how to do the > "between applications" yet). Just a heads up: I did eventually, er, "erase" > the folders by selecting them and dragging them to the Recycler's > pseudo-appicon and it worked without a hitch. Since Recycler.app is another > app I guess that would count. > > > On Sun, Dec 29, 2013 at 5:58 PM, Gregory Casamento < > greg.casame...@gmail.com> wrote: > >> Between windows or between applications. I believe you’re hitting the >> same bug Fred may be hitting, I’m working on a potential fix now. >> >> Greg >> >> On Dec 29, 2013, at 3:56 PM, Jamie Ramone wrote: >> >> > Something from the outside? What do you mean, like from another app? >> But what, could you be more specific? Thanx. In any case here's my most >> recent test: made two new folders and dragged them around, into the shelf, >> from there inside of the other one, back home, same thing in revers >> order...nothing. The only thing that crashed GWorkspace was closing the >> Trash viewer. >> > >> > >> > On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> > Moving files and folders around is not what I'm talking about try >> dragging something in from outside. >> > >> > GC >> > >> > >> > On Sunday, December 29, 2013, Jamie Ramone wrote: >> > I thought so. So far nothing. I've moved files and folders around, as >> well as color swatches and nothing. My only gripe is no alpha but apart >> from that, I'm not having any D&D troubles. In fact, the only app with this >> problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. >> > >> > >> > On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> > GWorkspace may be good. >> > >> > >> > On Sunday, December 29, 2013, Jamie Ramone wrote: >> > Not sure yet, but I'd like to note that the upgrade borked the alpha >> blending on all D&D images :-/ Still looking... >> > Oh, any idea as to which app would be best suited for this test, is >> there a useful one in the examples tarball? >> > >> > >> > On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> > Yeah, I know. :( Any ideas with respect to what is wrong with drag >> and drop? >> > >> > >> > On Sunday, December 29, 2013, David Chisnall wrote: >> > On 29 Dec 2013, at 12:04, Gregory Casamento >> wrote: >> > >> > > Well, If I'm doing to dictate, I should at least proofread >> > ^ >> > >> > Good start... >> > >> > David >> > >> > >> > >> > >> > -- Sent from my Cray X1 >> > >> > >> > >> > -- >> > Gregory Casamento >> > Open Logic Corporation, Principal Consultant >> > yahoo/skype: greg_casamento, aol: gjcasa >> > (240)274-9630 (Cell) >> > http://www.gnustep.org >> > http://heronsperch.blogspot.com >> > >> > ___ >> > Gnustep-dev mailing list >> > Gnustep-dev@gnu.org >> > https://lists.gnu.org/mailman/listinfo/gnustep-dev >> > >> > >> > >> > >> > -- >> > Gregory Casamento >> > Open Logic Corporation, Principal Consultant >> > yahoo/skype: greg_casamento, aol: gjcasa >> > (240)274-9630 (Cell) >> > http://www.gnustep.org >> > http://heronsperch.blogspot.com >> > >> > >> > >> > -- >> > Gregory Casamento >> > Open Logic Corporation, Principal Consultant >> > yahoo/skype: greg_casamento, aol: gjcasa >> > (240)274-9630 (Cell) >> > http://www.gnustep.org >> > http://heronsperch.blogspot.com >> > >> >> > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Hmm, I was able to drag a red color swatch from Ink's color panel to the tabbed shelf. Then wrote some text in black and selected one letter. Finally I dragged the swatch from the shelf onto the selected text, which changed from black to red as expected. Still poking around... On Sun, Dec 29, 2013 at 6:06 PM, Jamie Ramone wrote: > Just dragged around folders between 2 viewer windows without a hitch. > Let's have a look at the tabbed shelf, that holds just about anything. > > > On Sun, Dec 29, 2013 at 6:02 PM, Jamie Ramone wrote: > >> OK, got it, I'll try that now (between windows, not sure how to do the >> "between applications" yet). Just a heads up: I did eventually, er, "erase" >> the folders by selecting them and dragging them to the Recycler's >> pseudo-appicon and it worked without a hitch. Since Recycler.app is another >> app I guess that would count. >> >> >> On Sun, Dec 29, 2013 at 5:58 PM, Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> Between windows or between applications. I believe you’re hitting the >>> same bug Fred may be hitting, I’m working on a potential fix now. >>> >>> Greg >>> >>> On Dec 29, 2013, at 3:56 PM, Jamie Ramone wrote: >>> >>> > Something from the outside? What do you mean, like from another app? >>> But what, could you be more specific? Thanx. In any case here's my most >>> recent test: made two new folders and dragged them around, into the shelf, >>> from there inside of the other one, back home, same thing in revers >>> order...nothing. The only thing that crashed GWorkspace was closing the >>> Trash viewer. >>> > >>> > >>> > On Sun, Dec 29, 2013 at 4:08 PM, Gregory Casamento < >>> greg.casame...@gmail.com> wrote: >>> > Moving files and folders around is not what I'm talking about try >>> dragging something in from outside. >>> > >>> > GC >>> > >>> > >>> > On Sunday, December 29, 2013, Jamie Ramone wrote: >>> > I thought so. So far nothing. I've moved files and folders around, as >>> well as color swatches and nothing. My only gripe is no alpha but apart >>> from that, I'm not having any D&D troubles. In fact, the only app with this >>> problem is GORM. I'll keep fiddling with GWorkspace and see if it shows up. >>> > >>> > >>> > On Sun, Dec 29, 2013 at 2:42 PM, Gregory Casamento < >>> greg.casame...@gmail.com> wrote: >>> > GWorkspace may be good. >>> > >>> > >>> > On Sunday, December 29, 2013, Jamie Ramone wrote: >>> > Not sure yet, but I'd like to note that the upgrade borked the alpha >>> blending on all D&D images :-/ Still looking... >>> > Oh, any idea as to which app would be best suited for this test, is >>> there a useful one in the examples tarball? >>> > >>> > >>> > On Sun, Dec 29, 2013 at 9:59 AM, Gregory Casamento < >>> greg.casame...@gmail.com> wrote: >>> > Yeah, I know. :( Any ideas with respect to what is wrong with drag >>> and drop? >>> > >>> > >>> > On Sunday, December 29, 2013, David Chisnall wrote: >>> > On 29 Dec 2013, at 12:04, Gregory Casamento >>> wrote: >>> > >>> > > Well, If I'm doing to dictate, I should at least proofread >>> > ^ >>> > >>> > Good start... >>> > >>> > David >>> > >>> > >>> > >>> > >>> > -- Sent from my Cray X1 >>> > >>> > >>> > >>> > -- >>> > Gregory Casamento >>> > Open Logic Corporation, Principal Consultant >>> > yahoo/skype: greg_casamento, aol: gjcasa >>> > (240)274-9630 (Cell) >>> > http://www.gnustep.org >>> > http://heronsperch.blogspot.com >>> > >>> > ___ >>> > Gnustep-dev mailing list >>> > Gnustep-dev@gnu.org >>> > https://lists.gnu.org/mailman/listinfo/gnustep-dev >>> > >>> > >>> > >>> > >>> > -- >>> > Gregory Casamento >>> > Open Logic Corporation, Principal Consultant >>> > yahoo/skype: greg_casamento, aol: gjcasa >>> > (240)274-9630 (Cell) >>> > http://www.gnustep.org >>> > http://heronsperch.blogspot.com >>> > >>> > >>> > >>> > -- >>> > Gregory Casamento >>> > Open Logic Corporation, Principal Consultant >>> > yahoo/skype: greg_casamento, aol: gjcasa >>> > (240)274-9630 (Cell) >>> > http://www.gnustep.org >>> > http://heronsperch.blogspot.com >>> > >>> >>> >> > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
I'm not sure how much more details you need. I stated that dragging a connection to any of the objects in the document window (i.e. the main project window) caused a segfault. I later discovered that dragging from these objects toward any other one, outside that window, worked OK. And it seems to be present in the current version of Gorm and updating the GNUstep libs didn't alleviate the problem, which says to me that it's Gorm-specific. Oh and the GDB backtrace is from the old code. Would it help to make another one with the new code? If so just let me know and I'll produce one. On Sun, Dec 29, 2013 at 6:20 PM, Fred Kiefer wrote: > On 29.12.2013 21:58, Gregory Casamento wrote: > > Between windows or between applications. I believe you’re hitting > > the same bug Fred may be hitting, I’m working on a potential fix > > now. > > You might be wrong here. German's bug, that I investigated, was Gorm > specific. If you advice Jamie to drag between another application and > GWorkspace it may never trigger the same bug. It might trigger a similar > bug in GWorkspace if it has similar code to Gorm, but how likely is that? > > And I wasn't able to reproduce Jamie's bug with Gorm. But then he never > gave enough details to be sure. > > As you may remember German's bug did not include a segmentation fault, > which is the symptom Jamie is getting. What I would like to see is a > stack trace from Jamie with the current GNUstep code. With his old one I > was never sure whether I was looking at the same line of code. For me > NSWindow.m:4288 is in the middle of the GSPerformVoidDragSelector macro, > which isn't very likely. > > I really would like to establish the facts before coming to conclusions > about the nature of the bug. > > Fred > > ___ > 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: Serious GORM bug
OK, here it is: (gdb) file /SystemApps/Gorm.app/Gorm Reading symbols from /SystemApps/Gorm.app/Gorm...done. (gdb) r Starting program: /SystemApps/Gorm.app/Gorm [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xe121e0) at NSWindow.m:4414 4414NSWindow.m: No such file or directory. (gdb) bt #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0xe121e0) at NSWindow.m:4414 #1 0x771ef09c in -[GSDragView(Private) _handleDrag:slidePoint:] ( self=0xc55d00, _cmd=, theEvent=0x1061780, slidePoint=...) at GSDragView.m:720 #2 0x771ed20e in -[GSDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, _cmd=, anImage=0x9dc150, screenLocation=..., initialOffset=..., event=0x11073a0, pboard=, sourceObject=0xf2e5f0, slideFlag=1 '\001') at GSDragView.m:290 #3 0x7045e344 in -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, _cmd=, anImage=0x9dc150, screenLocation=..., initialOffset=..., event=0x11073a0, pboard=0x9d9470, sourceObject=0xf2e5f0, slideFlag=1 '\001') at XGDragView.m:228 #4 0x771bebda in -[NSWindow dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb140b0, _cmd=, anImage=0x9dc150, baseLocation=..., initialOffset=..., event=0x11073a0, pboard=, sourceObject=, slideFlag=1 '\001') at NSWindow.m:4674 #5 0x771a8c08 in -[NSView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xf2e5f0, _cmd=, anImage=0x9dc150, ---Type to continue, or q to quit--- viewLocation=..., initialOffset=..., event=0x11073a0, pboard=, sourceObject=, slideFlag=1 '\001') at NSView.m:3860 #6 0x77b2983c in -[GormObjectEditor mouseDown:] (self=0xf2e5f0, _cmd=, theEvent=0x11073a0) at GormObjectEditor.m:481 #7 0x771ca953 in -[NSWindow sendEvent:] (self=0xb140b0, _cmd=, theEvent=0x11073a0) at NSWindow.m:3896 #8 0x770343e3 in -[NSApplication run] (self=0x8c8450, _cmd=) at NSApplication.m:1562 #9 0x770130d5 in NSApplicationMain (argc=, argv=) at Functions.m:91 #10 0x75eab76d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #11 0x00401965 in _start () (gdb) On Sun, Dec 29, 2013 at 6:50 PM, Fred Kiefer wrote: > Yes! That was what I was asking for. > > Thank you, > Fred > > On 29.12.2013 22:28, Jamie Ramone wrote: > > I'm not sure how much more details you need. I stated that dragging a > > connection to any of the objects in the document window (i.e. the main > > project window) caused a segfault. I later discovered that dragging from > > these objects toward any other one, outside that window, worked OK. And > it > > seems to be present in the current version of Gorm and updating the > GNUstep > > libs didn't alleviate the problem, which says to me that it's > > Gorm-specific. Oh and the GDB backtrace is from the old code. Would it > help > > to make another one with the new code? If so just let me know and I'll > > produce one. > > > > > > On Sun, Dec 29, 2013 at 6:20 PM, Fred Kiefer wrote: > > > >> On 29.12.2013 21:58, Gregory Casamento wrote: > >>> Between windows or between applications. I believe you’re hitting > >>> the same bug Fred may be hitting, I’m working on a potential fix > >>> now. > >> > >> You might be wrong here. German's bug, that I investigated, was Gorm > >> specific. If you advice Jamie to drag between another application and > >> GWorkspace it may never trigger the same bug. It might trigger a similar > >> bug in GWorkspace if it has similar code to Gorm, but how likely is > that? > >> > >> And I wasn't able to reproduce Jamie's bug with Gorm. But then he never > >> gave enough details to be sure. > >> > >> As you may remember German's bug did not include a segmentation fault, > >> which is the symptom Jamie is getting. What I would like to see is a > >> stack trace from Jamie with the current GNUstep code. With his old one I > >> was never sure whether I was looking at the same line of code. For me > >> NSWindow.m:4288 is in the middle of the GSPerformVoidDragSelector macro, > >> which isn't very likely. > >> > >> I really would like to establish the facts before coming to conclusions > >> about the nature of the bug. > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
No idea about the NSWindow.m not found. I am running it on the machine it was compiled for. I did delete the sources afterward, but doesn't the code info get included with -g? If necessary, I can unpack the sources where I did the build last time. Would that help in the bug hunt? Just let me know. Here's the ldd output: jamie@MyPC:~$ ldd /SystemApps/Gorm.app/Gorm linux-vdso.so.1 => (0x7fff0cfff000) libGormCore.so.1 => /SystemLibrary/Libraries/libGormCore.so.1 (0x7fd04788e000) libGorm.so.1 => /SystemLibrary/Libraries/libGorm.so.1 (0x7fd04767e000) libGormPrefs.so.1 => /SystemLibrary/Libraries/libGormPrefs.so.1 (0x7fd047465000) libgnustep-gui.so.0.24 => /SystemLibrary/Libraries/libgnustep-gui.so.0.24 (0x7fd046c46000) libgnustep-base.so.1.24 => /SystemLibrary/Libraries/libgnustep-base.so.1.24 (0x7fd04649b000) libobjc.so.3 => /usr/lib/x86_64-linux-gnu/libobjc.so.3 (0x7fd04625f000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fd046049000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd045c89000) libGormObjCHeaderParser.so.1 => /SystemLibrary/Libraries/libGormObjCHeaderParser.so.1 (0x7fd045a7b000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd04585e000) libicuuc.so.48 => /usr/lib/libicuuc.so.48 (0x7fd0454f4000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7fd0452cb000) libgif.so.4 => /usr/lib/x86_64-linux-gnu/libgif.so.4 (0x7fd0450c2000) libtiff.so.4 => /usr/lib/x86_64-linux-gnu/libtiff.so.4 (0x7fd044e5e000) libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x7fd044c0d000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fd044911000) libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x7fd044655000) libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x7fd0443d6000) libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 (0x7fd04419a000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x7fd043e3e000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7fd043c35000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd043a31000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fd04381a000) libicui18n.so.48 => /usr/lib/libicui18n.so.48 (0x7fd043451000) /lib64/ld-linux-x86-64.so.2 (0x7fd047bf5000) libicudata.so.48 => /usr/lib/libicudata.so.48 (0x7fd0420e1000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fd041de) libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x7fd041bcf000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7fd0419bc000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7fd0417b8000) On Mon, Dec 30, 2013 at 1:55 PM, Fred Kiefer wrote: > I asked for it, I got it and now it doesn't help me :-( > > Thank you for the stack trace. But now I am completely clueless. > Do you have an idea why the message "NSWindow.m: No such file or > directory." shows up? I would expect that you are running Gorm on the > same machine that you did compile GNUstep. If this is the case gdb > should be able to find the source file, as long as you did not strip > that information from the library. But you wrote that you did not > request any optimization. > > One last thing, could you please run ldd against your Gorm executable > and report back the result? Just to make sure that the correct GNUstep > library files get used. > > Looking at the code in NSWindow sendEvent: I see no way how self could > ever become nil. > > Fred > > On 30.12.2013 00:32, Jamie Ramone wrote: > > OK, here it is: > > > > (gdb) file /SystemApps/Gorm.app/Gorm > > Reading symbols from /SystemApps/Gorm.app/Gorm...done. > > (gdb) r > > Starting program: /SystemApps/Gorm.app/Gorm > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > > > Program received signal SIGSEGV, Segmentation fault. > > -[NSWindow sendEvent:] (self=0x0, _cmd=, > theEvent=0xe121e0) > > at NSWindow.m:4414 > > 4414NSWindow.m: No such file or directory. > > (gdb) bt > > #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, > > theEvent=0xe121e0) > > at NSWindow.m:4414 > > #1 0x771ef09c in -[GSDragView(Private) _handleDrag:slidePoint:] > ( > > self=0xc55d00, _cmd=, theEvent=0x1061780, > slidePoint=...) > > at GSDragView.m:720 > > #2 0x771ed20e in -[GSDragView > > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xc55d00, > > _cmd=, anIma
Re: Serious GORM bug
Hmm, interesting. What could be a good workaround? Can it safely be removed or downgraded? Keep in mind that I'm on Ubuntu 12.04. On Mon, Dec 30, 2013 at 3:27 PM, Germán Arias wrote: > El lun, 30-12-2013 a las 15:30 -0200, Jamie Ramone escribió: > > No idea about the NSWindow.m not found. I am running it on the machine > > it was compiled for. I did delete the sources afterward, but doesn't > > the code info get included with -g? If necessary, I can unpack the > > sources where I did the build last time. Would that help in the bug > > hunt? Just let me know. > > > > Here's the ldd output: > > > > jamie@MyPC:~$ ldd /SystemApps/Gorm.app/Gorm > > linux-vdso.so.1 => (0x7fff0cfff000) > > > linux-vdso.so is used only in recent kernels at 64 bits machines. So, > could be a problem with this library? Searching on internet, seems there > are people having problems with this. > > Germán. > > > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
So, I'll have to wait for 14 to come out then. I can live with that I guess. In any case I'll give it a go on a VM with 13.10 (wish me luck).As for GWorkspace I never use it's desktop. It interferes with everything else. And no, it doesn't work on both as I stated earlier. On Wed, Jan 1, 2014 at 4:38 PM, Riccardo Mottola wrote: > Jamie Ramone wrote: > >> OK, got it, I'll try that now (between windows, not sure how to do the >> "between applications" yet). Just a heads up: I did eventually, er, >> "erase" >> the folders by selecting them and dragging them to the Recycler's >> pseudo-appicon and it worked without a hitch. Since Recycler.app is >> another >> app I guess that would count. >> >> Depends if you are using the recycler in the desktop+dock, or if you are > using the separate recycler app. They should, of course, work both. > > Riccardo > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
Well $hit! I ran on a VM with Ubuntu 13.10...same problem: Starting program: /SystemApps/Gorm.app/Gorm [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 2014-01-03 20:09:11.042 Gorm[6849] QueryTree window is 25186477 (root 373 cwin root 373) 2014-01-03 20:09:11.102 Gorm[6849] QueryTree window is 25186476 (root 373 cwin root 373) 2014-01-03 20:09:11.573 Gorm[6849] QueryTree window is 25186511 (root 373 cwin root 373) 2014-01-03 20:09:11.574 Gorm[6849] QueryTree window is 25186510 (root 373 cwin root 373) Program received signal SIGSEGV, Segmentation fault. -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0x1080810) at NSWindow.m:4409 4409NSWindow.m: No such file or directory. (gdb) bt #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, theEvent=0x1080810) at NSWindow.m:4409 #1 0x771ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] (self=0xb4aa70, _cmd=, theEvent=0x1052960, slidePoint=...) at GSDragView.m:720 #2 0x771e88e3 in -[GSDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70, _cmd=, anImage=0x8866a0, screenLocation=..., initialOffset=..., event=0xab2760, pboard=, sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290 #3 0x72208769 in -[XGDragView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=self@entry=0xb4aa70, _cmd=_cmd@entry=0x775f0fb0 <_OBJC_SELECTOR_TABLE+7952>, anImage=anImage@entry=0x8866a0, screenLocation=..., initialOffset=..., event=event@entry=0xab2760, pboard=pboard@entry=0x10d12d0, sourceObject=sourceObject@entry=0xd536c0, slideFlag=slideFlag@entry=1 '\001') at XGDragView.m:228 #4 0x771bfc36 in -[NSWindow dragImage:at:offset:event:pasteboard:source:slideBack:] (self=self@entry=0xad8630, _cmd=_cmd@entry=0x775e6730 <_OBJC_SELECTOR_TABLE+5168>, anImage=anImage@entry=0x8866a0, baseLocation=..., initialOffset=..., event=event@entry=0xab2760, pboard=pboard@entry=0x10d12d0, sourceObject=sourceObject@entry=0xd536c0, slideFlag=slideFlag@entry=1 '\001') at NSWindow.m:4674 #5 0x771a9464 in -[NSView dragImage:at:offset:event:pasteboard:source:slideBack:] (self=self@entry=0xd536c0, _cmd=_cmd@entry=0x77da5ff0 <_OBJC_SELECTOR_TABLE+3120>, anImage=0x8866a0, viewLocation=..., initialOffset=..., event=event@entry=0xab2760, pboard=pboard@entry=0x10d12d0, sourceObject=sourceObject@entry=0xd536c0, slideFlag=slideFlag@entry=1 '\001') at NSView.m:3860 #6 0x77b291d4 in -[GormObjectEditor mouseDown:] (self=0xd536c0, _cmd=, theEvent=0xab2760) at GormObjectEditor.m:481 #7 0x771c93d0 in -[NSWindow sendEvent:] (self=0xad8630, _cmd=, theEvent=0xab2760) at NSWindow.m:3896 #8 0x7704c6f3 in -[NSApplication run] (self=0x87e2f0, _cmd=) at NSApplication.m:1562 #9 0x7702cfe5 in NSApplicationMain (argc=, argv=) at Functions.m:91 #10 0x75ed5de5 in __libc_start_main (main=0x4019c0 , argc=1, ubp_av=0x7fffdc78, init=, fini=, rtld_fini=, stack_end=0x7fffdc68) at libc-start.c:260 #11 0x00401a05 in _start () At least it's now showing the NSWindow.m info. I'll see if I can dig up anything else. On Fri, Jan 3, 2014 at 1:36 AM, Jamie Ramone wrote: > So, I'll have to wait for 14 to come out then. I can live with that I > guess. In any case I'll give it a go on a VM with 13.10 (wish me luck).As > for GWorkspace I never use it's desktop. It interferes with everything > else. And no, it doesn't work on both as I stated earlier. > > > On Wed, Jan 1, 2014 at 4:38 PM, Riccardo Mottola wrote: > >> Jamie Ramone wrote: >> >>> OK, got it, I'll try that now (between windows, not sure how to do the >>> "between applications" yet). Just a heads up: I did eventually, er, >>> "erase" >>> the folders by selecting them and dragging them to the Recycler's >>> pseudo-appicon and it worked without a hitch. Since Recycler.app is >>> another >>> app I guess that would count. >>> >>> Depends if you are using the recycler in the desktop+dock, or if you >> are using the separate recycler app. They should, of course, work both. >> >> Riccardo >> >> > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
On Sat, Jan 4, 2014 at 7:59 AM, Fred Kiefer wrote: > > Am 04.01.2014 um 00:17 schrieb Jamie Ramone : > > Well $hit! I ran on a VM with Ubuntu 13.10...same problem: > > Starting program: /SystemApps/Gorm.app/Gorm > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > 2014-01-03 20:09:11.042 Gorm[6849] QueryTree window is 25186477 (root 373 > cwin root 373) > 2014-01-03 20:09:11.102 Gorm[6849] QueryTree window is 25186476 (root 373 > cwin root 373) > 2014-01-03 20:09:11.573 Gorm[6849] QueryTree window is 25186511 (root 373 > cwin root 373) > 2014-01-03 20:09:11.574 Gorm[6849] QueryTree window is 25186510 (root 373 > cwin root 373) > > > Could you please explain where these messages come from? Are you using > unaltered GNUstep code, or if you have changes would you mind telling us > about them? This looks a bit like the debugging code I used in the backend > to track down the other Gorm bug, which actually turned out to be a Gorm > bug. > If you want to see more information on what is happening inside of the > running Gorm application start it with parameters such as > "--GNU-Debug=dflt", "--GNU-Debug=NSEvent" or "--GNU-Debug=NSDragging" > (typed from memory, better check the correct names in the source code). > To my knowledge, it's unaltered. I didn't touch any line of Gorm's code, just downloaded and compiled it. OK, I'll try those. Program received signal SIGSEGV, Segmentation fault. > -[NSWindow sendEvent:] (self=0x0, _cmd=, > theEvent=0x1080810) at NSWindow.m:4409 > 4409NSWindow.m: No such file or directory. > > > Again you seem to have deleted the source code. Why do you keep on doing > this. > Aw crap, it's still popping up! Actually, I didn't. I left the GNUstep code as it was after installing it in the VM, which makes this line even more mysterious. (gdb) bt > #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, > theEvent=0x1080810) at NSWindow.m:4409 > > > As I already wrote, nil as self is only possible if something in the method > sets this explicitly or due to a compiler bug, which is not very likely. > Which complier and runtime are you using here? > > The GNU runtime. I checked that line, there's a macro there and seems harmless. if self's nil at that point it's being changed somewhere in that method, but before the macro is expanded. I'll have to keep digging. > > #1 0x771ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] > (self=0xb4aa70, _cmd=, theEvent=0x1052960, > slidePoint=...) at GSDragView.m:720 > #2 0x771e88e3 in -[GSDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70, > _cmd=, anImage=0x8866a0, screenLocation=..., > initialOffset=..., event=0xab2760, pboard=, > sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290 > #3 0x72208769 in -[XGDragView > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xb4aa70, > > _cmd=_cmd@entry=0x775f0fb0 <_OBJC_SELECTOR_TABLE+7952>, > anImage=anImage@entry=0x8866a0, screenLocation=..., > initialOffset=..., event=event@entry=0xab2760, > pboard=pboard@entry=0x10d12d0, > sourceObject=sourceObject@entry=0xd536c0, > slideFlag=slideFlag@entry=1 '\001') at XGDragView.m:228 > #4 0x771bfc36 in -[NSWindow > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xad8630, > > _cmd=_cmd@entry=0x775e6730 <_OBJC_SELECTOR_TABLE+5168>, > anImage=anImage@entry=0x8866a0, baseLocation=..., > initialOffset=..., event=event@entry=0xab2760, > pboard=pboard@entry=0x10d12d0, > sourceObject=sourceObject@entry=0xd536c0, > slideFlag=slideFlag@entry=1 '\001') at NSWindow.m:4674 > #5 0x771a9464 in -[NSView > dragImage:at:offset:event:pasteboard:source:slideBack:] > (self=self@entry=0xd536c0, > > _cmd=_cmd@entry=0x77da5ff0 <_OBJC_SELECTOR_TABLE+3120>, > anImage=0x8866a0, viewLocation=..., initialOffset=..., > event=event@entry=0xab2760, pboard=pboard@entry=0x10d12d0, > sourceObject=sourceObject@entry=0xd536c0, > slideFlag=slideFlag@entry=1 '\001') at NSView.m:3860 > #6 0x77b291d4 in -[GormObjectEditor mouseDown:] (self=0xd536c0, > _cmd=, theEvent=0xab2760) > at GormObjectEditor.m:481 > #7 0x771c93d0 in -[NSWindow sendEvent:] (self=0xad8630, > _cmd=, theEvent=0xab2760) at NSWindow.m:3896 > #8 0x7704c6f3 in -[NSApplication run] (self=0x87e2f0, > _cmd=) at NSApplication.m:1562 > #9 0x00007702cfe5 in NSApplicationMain (argc=, > argv=) at Functions.m:91 >
Re: Serious GORM bug
For the VM test I used the ones on the webpage (I do believe they're up to date), same ones I used on my machine after running into this problen in the previous version. That would be: - make 2.6.6 - base 1.24.6 - gui 0.24.0 - back 0.24.0 - Gorm 1.2.18 On Sat, Jan 4, 2014 at 10:47 AM, Gregory Casamento wrote: > Please make sure you install a recent version of Gorm and GNUstep. I'm not > certain which version of base and GUI you're using. > > GC > > > On Saturday, January 4, 2014, Jamie Ramone wrote: > >> >> >> >> On Sat, Jan 4, 2014 at 7:59 AM, Fred Kiefer wrote: >> >>> >>> Am 04.01.2014 um 00:17 schrieb Jamie Ramone : >>> >>> Well $hit! I ran on a VM with Ubuntu 13.10...same problem: >>> >>> Starting program: /SystemApps/Gorm.app/Gorm >>> [Thread debugging using libthread_db enabled] >>> Using host libthread_db library >>> "/lib/x86_64-linux-gnu/libthread_db.so.1". >>> 2014-01-03 20:09:11.042 Gorm[6849] QueryTree window is 25186477 (root >>> 373 cwin root 373) >>> 2014-01-03 20:09:11.102 Gorm[6849] QueryTree window is 25186476 (root >>> 373 cwin root 373) >>> 2014-01-03 20:09:11.573 Gorm[6849] QueryTree window is 25186511 (root >>> 373 cwin root 373) >>> 2014-01-03 20:09:11.574 Gorm[6849] QueryTree window is 25186510 (root >>> 373 cwin root 373) >>> >>> >>> Could you please explain where these messages come from? Are you using >>> unaltered GNUstep code, or if you have changes would you mind telling us >>> about them? This looks a bit like the debugging code I used in the backend >>> to track down the other Gorm bug, which actually turned out to be a Gorm >>> bug. >>> If you want to see more information on what is happening inside of the >>> running Gorm application start it with parameters such as >>> "--GNU-Debug=dflt", "--GNU-Debug=NSEvent" or "--GNU-Debug=NSDragging" >>> (typed from memory, better check the correct names in the source code). >>> >> >> To my knowledge, it's unaltered. I didn't touch any line of Gorm's code, >> just downloaded and compiled it. OK, I'll try those. >> >> Program received signal SIGSEGV, Segmentation fault. >>> -[NSWindow sendEvent:] (self=0x0, _cmd=, >>> theEvent=0x1080810) at NSWindow.m:4409 >>> 4409NSWindow.m: No such file or directory. >>> >>> >>> Again you seem to have deleted the source code. Why do you keep on doing >>> this. >>> >> >> Aw crap, it's still popping up! Actually, I didn't. I left the GNUstep >> code as it was after installing it in the VM, which makes this line even >> more mysterious. >> >> (gdb) bt >>> #0 -[NSWindow sendEvent:] (self=0x0, _cmd=, >>> theEvent=0x1080810) at NSWindow.m:4409 >>> >>> >>> >> As I already wrote, nil as self is only possible if something in the >>> method sets this explicitly or due to a compiler bug, which is not very >>> likely. Which complier and runtime are you using here? >>> >>> >> The GNU runtime. I checked that line, there's a macro there and seems >> harmless. if self's nil at that point it's being changed somewhere in that >> method, but before the macro is expanded. I'll have to keep digging. >> >> >> >> #1 0x771ea46e in -[GSDragView(Private) _handleDrag:slidePoint:] >> (self=0xb4aa70, _cmd=, theEvent=0x1052960, >> slidePoint=...) at GSDragView.m:720 >> #2 0x771e88e3 in -[GSDragView >> dragImage:at:offset:event:pasteboard:source:slideBack:] (self=0xb4aa70, >> _cmd=, anImage=0x8866a0, screenLocation=..., >> initialOffset=..., event=0xab2760, pboard=, >> sourceObject=0xd536c0, slideFlag=1 '\001') at GSDragView.m:290 >> #3 0x72208769 in -[XGDragView >> dragImage:at:offset:event:pasteboard:source:slideBack:] >> (self=self@entry=0xb4aa70, >> >> _cmd=_cmd@entry=0x775f0fb0 <_OBJC_SELECTOR_TABLE+7952>, >> anImage=anImage@entry=0x8866a0, screenLocation=..., >> initialOffset=..., event=event@entry=0xab2760, >> pboard=pboard@entry=0x10d12d0, >> sourceObject=sourceObject@entry=0xd536c0, >> slideFlag=slideFlag@entry=1 '\001') at XGDragView.m:228 >> #4 0x771bfc36 in -[NSWindow >> dragImage:at:offset:event:pasteboard:source:slideBack:] >> (self=self@entry=0xad8630, >> >> _cmd=_cmd@entry=0x775e6730 <
Problem installing bundles without GNUSTEP_INSTALLATION_DIR
Hi steppers, me again. So here's the deal: I built a modular application thru the use of bundles and the app searches several paths obtained from the domains upon start up, and can manually add them later on if a valid bundle is dropped on the app (not implemented yet tho). Any way, the thing is some modules are meant to be included inside the app's bundle, but I can't find a way to get the bundles included there upon building the app in ProjectCenter. Can this be done at all? I mean in an automated way, other than manually copying the module bundle into the app bundle itself. Thanx! ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem installing bundles without GNUSTEP_INSTALLATION_DIR
How do u mean, using one of those *:: targets (like after-all::), or are u talking about another means? I wouldn't have a problem with that but PC f@*#ing does whatever it wants to the make files. I'm beginning to manage to coax it into doing what I want by poking around in the .PC files. I'll give it a try. On Fri, Jan 20, 2017 at 7:40 PM, Ivan Vučica wrote: > I don't know the capabilities of ProjectCenter, but if you use makefiles > directly, it could be rather easy to copy the bundle in "manually". > > > On Fri, Jan 20, 2017, 21:50 Jamie Ramone wrote: >> >> Hi steppers, me again. So here's the deal: I built a modular >> application thru the use of bundles and the app searches several paths >> obtained from the domains upon start up, and can manually add them >> later on if a valid bundle is dropped on the app (not implemented yet >> tho). Any way, the thing is some modules are meant to be included >> inside the app's bundle, but I can't find a way to get the bundles >> included there upon building the app in ProjectCenter. Can this be >> done at all? I mean in an automated way, other than manually copying >> the module bundle into the app bundle itself. Thanx! >> >> ___ >> Discuss-gnustep mailing list >> discuss-gnus...@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem installing bundles without GNUSTEP_INSTALLATION_DIR
Hmm, it seems PC DOESN'T clobber the GNUMakefile.pre- and post-amble. So basically yeah, this approach works! :) But I know u can't do anything to the main make file. It uses the PC.project file to generate it and happily stomps all over any change you've made to that one. I just had to manually edit out a stale file reference from the PC.project file just to be able to compile the project again as it failed to recognize a name change and included that reference into the makefile, borking all compilations...ProjectCenter is a dick sometimes is what I'm saying :-/ What other ideas did you have. On Sat, Jan 21, 2017 at 1:04 PM, Ivan Vučica wrote: > If it generates the lines that include GNUmakefile.postamble, you can use > that to patch up ProjectCenter-generated makefiles. > > Exactly which targets you should use, I don't know without looking closer. > > Also, someone else may have better ideas. > > On January 21, 2017 12:22:55 AM GMT+00:00, Jamie Ramone > wrote: >> >> How do u mean, using one of those *:: targets (like after-all::), or >> are u talking about another means? I wouldn't have a problem with that >> but PC f@*#ing does whatever it wants to the make files. I'm beginning >> to manage to coax it into doing what I want by poking around in the >> .PC files. I'll give it a try. >> >> On Fri, Jan 20, 2017 at 7:40 PM, Ivan Vučica wrote: >>> >>> I don't know the capabilities of ProjectCenter, but if you use makefiles >>> directly, it could be rather easy to copy the bundle in "manually". >>> >>> >>> On Fri, Jan 20, 2017, 21:50 Jamie Ramone wrote: >>>> >>>> >>>> Hi steppers, me again. So here's the deal: I built a modular >>>> application thru the use of bundles and the app searches several paths >>>> obtained from the domains upon start up, and can manually add them >>>> later on if a valid bundle is dropped on the app (not implemented yet >>>> tho). Any way, the thing is some modules are meant to be included >>>> inside the app's bundle, but I can't find a way to get the bundles >>>> included there upon building the app in ProjectCenter. Can this be >>>> done at all? I mean in an automated way, other than manually copying >>>> the module bundle into the app bundle itself. Thanx! >>>> >>>> >>>> >>>> Discuss-gnustep mailing list >>>> discuss-gnus...@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
linking a C++ lib to an objc tool.
Hello world! I'm trying to build a project of mine in GNUstep which
requires some functionality provided by an external library, which is
in C++. I tried to build it with portions in Objc++ but faild. I said
it couldn't find the symbols it needed (calls to the methods of c++
objects). So I rewrote the thing moving the c++ dependencies to a
function in a plain c++ file. Strike 2. I checked around on the web
and discovered i needed the 'extern "C" {' thingy, so I added that. I
even rebuilt the external library, knowing that Ubuntu has more bugs
than rotting wood. Didn't help. I'm all out of ideas. Can anyone help?
Please let me know what information you need. Thanx!
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: linking a C++ lib to an objc tool.
o `poppler::document::load_from_raw_data(char
const*, int, std::__cxx11::basic_string,
std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&)'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:24:
undefined reference to `poppler::document::create_page(int) const'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:28:
undefined reference to `poppler::page_renderer::page_renderer()'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:29:
undefined reference to
`poppler::page_renderer::render_page(poppler::page const*, double,
double, int, int, int, int, poppler::rotation_enum) const'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:29:
undefined reference to `poppler::image::operator=(poppler::image
const&)'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:29:
undefined reference to `poppler::image::~image()'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:30:
undefined reference to `poppler::image::data()'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:31:
undefined reference to `poppler::image::height() const'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:31:
undefined reference to `poppler::image::bytes_per_row() const'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:16:
undefined reference to `poppler::image::~image()'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:29:
undefined reference to `poppler::image::~image()'
/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source/rendering.cc:16:
undefined reference to `poppler::image::~image()'
collect2: error: ld returned 1 exit status
/home/jamie/Developer/System/SystemDeveloper/Makefiles/Instance/tool.make:89:
recipe for target 'obj/WindowServer' failed
make[4]: *** [obj/WindowServer] Error 1
/home/jamie/Developer/System/SystemDeveloper/Makefiles/Instance/tool.make:74:
recipe for target 'internal-tool-all_' failed
make[3]: *** [internal-tool-all_] Error 2
/home/jamie/Developer/System/SystemDeveloper/Makefiles/Master/rules.make:311:
recipe for target 'WindowServer.all.tool.variables' failed
make[2]: *** [WindowServer.all.tool.variables] Error 2
/home/jamie/Developer/System/SystemDeveloper/Makefiles/Master/tool.make:71:
recipe for target 'internal-all' failed
make[1]: *** [internal-all] Error 2
make[1]: Leaving directory
'/home/jamie/Developer/Projects/FREEDOMSTEP/GNUWindowServer-I/Source'
/home/jamie/Developer/System/SystemDeveloper/Makefiles/Master/serial-subdirectories.make:53:
recipe for target 'internal-all' failed
make: *** [internal-all] Error 2
On Sat, Aug 26, 2017 at 7:07 PM, Daniel Ferreira (theiostream)
wrote:
> Could you point us out to:
> 1) the output of running `nm libYourLibrary.so`
> 2) the header declarations for the functions you are using
> 3) the error output of the linker?
>
> -- Daniel.
>
> Em 26 de ago de 2017 19:03, "Jamie Ramone" escreveu:
>>
>> Hello world! I'm trying to build a project of mine in GNUstep which
>> requires some functionality provided by an external library, which is
>> in C++. I tried to build it with portions in Objc++ but faild. I said
>> it couldn't find the symbols it needed (calls to the methods of c++
>> objects). So I rewrote the thing moving the c++ dependencies to a
>> function in a plain c++ file. Strike 2. I checked around on the web
>> and discovered i needed the 'extern "C" {' thingy, so I added that. I
>> even rebuilt the external library, knowing that Ubuntu has more bugs
>> than rotting wood. Didn't help. I'm all out of ideas. Can anyone help?
>> Please let me know what information you need. Thanx!
>>
>> ___
>> 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: linking a C++ lib to an objc tool.
On Sat, Aug 26, 2017 at 9:59 PM, Ivan Vučica wrote: > Order in which you specify things to be linked (object files and libraries) > may matter. Have you tried moving -lpoppler-cpp around? Hmm, I must admit I hadn't even thought about that. I'll give it a go and see what happens. > Has the code you're building ever been successfully linked? It worked before adding the PDF rendering requirement (I was concentrating on other parts of the system). > Is this code published? Not as of yet, hold your horses! :P > On Sat, Aug 26, 2017 at 11:25 PM Jamie Ramone wrote: >> >> 1) Are you referring to the external library I'm trying to link >> against? It's poppler-cpp >> >> Output: >> >> U abort@@GLIBC_2.2.5 >> 002125b8 B __bss_start >> 002125b8 b completed.7585 >> ebe0 r CSWTCH.189 >> ebc0 r CSWTCH.191 >> U __cxa_atexit@@GLIBC_2.2.5 >> w __cxa_finalize@@GLIBC_2.2.5 >> 8670 t deregister_tm_clones >> 8700 t __do_global_dtors_aux >> 00211d68 t __do_global_dtors_aux_fini_array_entry >> 002125a8 d __dso_handle >> 00211d78 d _DYNAMIC >> 002125b8 D _edata >> 002125d8 B _end >> U __errno_location@@GLIBC_2.2.5 >> U fclose@@GLIBC_2.2.5 >> eab4 T _fini >> U fopen@@GLIBC_2.2.5 >> 8740 t frame_dummy >> 00211d48 t __frame_dummy_init_array_entry >> 000114c8 r __FRAME_END__ >> U free@@GLIBC_2.2.5 >> 00212000 d _GLOBAL_OFFSET_TABLE_ >> U globalParams >> 85e0 t _GLOBAL__sub_I_poppler_global.cpp >> 8610 t _GLOBAL__sub_I_poppler_private.cpp >> 8640 t _GLOBAL__sub_I_poppler_rectangle.cpp >> w __gmon_start__ >> ec9c r __GNU_EH_FRAME_HDR >> U iconv_close@@GLIBC_2.2.5 >> U iconv@@GLIBC_2.2.5 >> U iconv_open@@GLIBC_2.2.5 >> 7a80 T _init >> w _ITM_deregisterTMCloneTable >> w _ITM_registerTMCloneTable >> 00211d70 d __JCR_END__ >> 00211d70 d __JCR_LIST__ >> w _Jv_RegisterClasses >> U malloc@@GLIBC_2.2.5 >> U memcpy@@GLIBC_2.14 >> U memmove@@GLIBC_2.2.5 >> U memset@@GLIBC_2.2.5 >> 86b0 t register_tm_clones >> U __stack_chk_fail@@GLIBC_2.4 >> U strlen@@GLIBC_2.2.5 >> 002125b8 d __TMC_END__ >> U tolower@@GLIBC_2.2.5 >> U _Z16dateStringToTimeP9GooString >> U _Z16setErrorCallbackPFvPv13ErrorCategoryxPcES_ >> U _Z16timeToDateStringPl >> U _Z5error13ErrorCategoryxPKcz >> U _ZdlPv@@GLIBCXX_3.4 >> da50 t >> >> _ZL21stderr_debug_functionRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPv >> U _ZN10JpegWriterC1ENS_6FormatE >> U _ZN10TiffWriterC1ENS_6FormatE >> U _ZN11OutlineItem4openEv >> U _ZN12GlobalParamsC1EPKc >> U _ZN12GlobalParamsD1Ev >> U _ZN12NetPBMWriterC1ENS_6FormatE >> U _ZN13TextOutputDev7getTextE >> U _ZN13TextOutputDev8takeTextEv >> U _ZN13TextOutputDevC1EPcbdbb >> U _ZN13TextOutputDevD1Ev >> U _ZN14PageTransitionC1EP6Object >> U _ZN14PageTransitionD1Ev >> U _ZN15FontInfoScanner4scanEi >> U _ZN15FontInfoScannerC1EP6PDFDoci >> U _ZN15FontInfoScannerD1Ev >> U _ZN15SplashOutputDev18setFreeTypeHintingEbb >> U _ZN15SplashOutputDev18setVectorAntialiasEb >> U _ZN15SplashOutputDev8startDocEP6PDFDoc >> U >> _ZN15SplashOutputDevC1E15SplashColorModeibPhb18SplashThinLineModeb >> U _ZN15SplashOutputDevD1Ev >> U _ZN4Dict6getKeyEi >> U _ZN4XRef10getDocInfoEP6Object >> U _ZN4XRef10okToChangeEb >> U _ZN4XRef12okToAddNotesEb >> U _ZN4XRef12okToAssembleEb >> U _ZN4XRef12okToFillFormEb >>
Re: linking a C++ lib to an objc tool.
Well that was a colossal waste of time. Interestingly, I found I cud get
rid of the other dependencies, SDL1 and Freetype, as they are no longer
needed by the main binary. So the ONLY requirement is poppler-cpp, so
shuffling it is pointless.
Here's the contents of the make files (if it helps):
*Main GNUMakefile*
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = WindowServer
TOOL_INSTALL_DIR = /usr/lib/GnuStep
WindowServer_OBJC_FILES =hash.m\
tree.m\
stack.m\
WSFeedback.m\
WSComponent.m\
WSModule.m\
WSModuleManager.m\
WSDisplayModule.m\
WSKeyboardModule.m\
WSPointerModule.m\
WSMiscModule.m\
WSEvent.m\
WSWindowManager.m\
WSConfigurationReader.m\
WSServerCore.m\
WSWindow.m\
main.m
WindowServer_OBJC_HEADERS = WSFeedback.h\
WSComponent.h\
WSEvent.h\
WSModule.h\
WSModuleManager.h\
WSDisplayModule.h\
WSKeyboardModule.h\
WSPointerModule.h\
WSMiscModule.h\
WSWindow.h\
WSWindowMAnager.h\
WSConfigurationReader.h\
WSServerCore.h\
Algorithm/hash.h\
Algorithm/stack.h\
Algorithm/tree.h
WindowServer_CC_FILES =rendering.cc
WindowServer_CC_HEADERS =rendering.h
SUBPROJECTS =Modules/Display\
Modules/Input\
Modules/Misc
CC=${CXX}
-include GNUmakefile.preamble
include $(GNUSTEP_MAKEFILES)/aggregate.make
include $(GNUSTEP_MAKEFILES)/tool.make
-include GNUmakefile.postamble
*GNUmakefile.preamble*OPTFLAG=-Os -fomit-frame-pointer -Wall -Werror
ADDITIONAL_CXXFLAGS += -fno-operator-names
ADDITIONAL_CFLAGS += -pipe -s
ADDITIONAL_INCLUDE_DIRS += -I../Headers
ADDITIONAL_INCLUDE_DIRS += -I${HOME}/Developer/System/include
ADDITIONAL_LIB_DIRS = -L${HOME}/Developer/System/lib
ADDITIONAL_LDFLAGS += -lpoppler-cpp
# -lfreetype -lSDL
*GNUmakefile.postamble*
after-install::
@cp -v ../Resources/* $(TOOL_INSTALL_DIR)
after-uninstall::
@rm -rfv $(TOOL_INSTALL_DIR)
after-all::
#strip obj/$(TOOL_NAME) || strip obj/$(TOOL_NAME)
chmod 0555 obj/$(TOOL_NAME) || chmod 0555 obj/$(TOOL_NAME)
(I put the 'after-all::' rule a long time ago, not sure why I had to leave
it like that, pay it no mind).
On Sat, Aug 26, 2017 at 10:52 PM, Jamie Ramone wrote:
> On Sat, Aug 26, 2017 at 9:59 PM, Ivan Vučica wrote:
> > Order in which you specify things to be linked (object files and
> libraries)
> > may matter. Have you tried moving -lpoppler-cpp around?
>
> Hmm, I must admit I hadn't even thought about that. I'll give it a go
> and see what happens.
>
> > Has the code you're building ever been successfully linked?
>
> It worked before adding the PDF rendering requirement (I was
> concentrating on other parts of the system).
>
> > Is this code published?
>
> Not as of yet, hold your horses! :P
>
> > On Sat, Aug 26, 2017 at 11:25 PM Jamie Ramone
> wrote:
> >>
> >> 1) Are you referring to the external library I'm trying to link
> >> against? It's poppler-cpp
> >>
> >> Output:
> >>
> >> U abort@@GLIBC_2.2.5
> >> 002125b8 B __bss_start
> >> 002125b8 b completed.7585
> >> ebe0 r CSWTCH.189
> >> ebc0 r CSWTCH.191
> >> U __cxa_atexit@@GLIBC_2.2.5
> >> w __cxa_finalize@@GLIBC_2.2.5
> >> 8670 t deregister_tm_clones
> >> 8700 t __do_global_dtors_aux
> >> 00211d68 t __do_global_dtors_aux_fini_array_entry
> >> 002125a8 d __dso_handle
> >> 00211d78 d _DYNAMIC
> >> 002125b8 D _edata
> >> 002125d8 B _end
> >> U __errno_location@@GLIBC_2.2.5
> >> U fclose@@GLIBC_2.2.5
> >> eab4 T _fini
> >> U fopen@@GLIBC_2.2.5
> >> 8740 t frame_dummy
> >> 00211d48 t __frame_dummy_init_array_entry
> >> 000114c8 r __FRAME_END__
> >> U free@@GLIBC_2.2.5
> >> 00212000 d _GLOBAL_OFFSET_TABLE_
> >> U globalParams
> >> 000
Re: linking a C++ lib to an objc tool.
On Sun, Aug 27, 2017 at 5:05 AM, David Chisnall wrote:
> Most of the code that I’ve written recently using GNUstep has been
> Objective-C++, so I can confirm that this work well (though I’m not using
> gcc, where I believe Objective-C++ still has some rough corners). Looking
> at your nm output, it appears as if the symbols are actually there (at
> least, `_ZN7poppler5imageC2Ev` demangles to `poppler::image::image()`,
> which is one of the missing symbols.
>
> Your nm output looks like it’s from a .a file though, not a .so. When
> resolving symbols in static libraries, GNU linkers only look forwards in
> the command line, so if you specify `ld a.a b.a` then undefined symbols in
> `a.a` will be resolved to point to `b.a`, but undefined symbols in `b.a`
> will not be resolved to point to `a.a`. You can solve this by either
> providing the libraries twice (e.g. `ld a.a b.a a.a b.a`), or by using
> --start-group and --end-group (e.g. `ld --start-group a.a b.a
> --end-group`), which searches the archives in the group exhaustively until
> it stops resolving all of the symbols. Or you can use lld, which doesn’t
> have this braindead behaviour (which is both user hostile and increases the
> algorithmic complexity of linking).
>
No, I specifically typed in "nm ~/Developer/System/lib/libpoppler-cpp.so",
so it's not a static lib. Furthermore, I didn't use the -static flag
anywhere, and the libs included are done so using -lib_in_question, which
is only fore shared libs (static ones are just globed onto the collection
of object files during the link stage i.e. gcc a.o b.o c.o static_lib.a,
which I don't know how to do in GNUstep make).
> I’ve found in the past that GNUstep Make’s interfaces for adding linker
> flags leaves a lot to be desired, because it doesn’t give much control over
> where things go on the linker command line, but I believe that using the
> relevant ADDITIONAL_*_LIBS variable will put the -lpoppler-cpp flag at the
> end of the linker command line, which will make it work.
>
Is there one for C++ libs? I checked the docs and it mentions GUI, OBJC,
and TOOLS. These indicate where, relative to the GNUstep libs in the
command line the added libs would go, but I'm not sure where I should put
it. I guess it's time to experiment with these...
Thanx!
> David
>
>
> On 26 Aug 2017, at 23:03, Jamie Ramone wrote:
> >
> > Hello world! I'm trying to build a project of mine in GNUstep which
> > requires some functionality provided by an external library, which is
> > in C++. I tried to build it with portions in Objc++ but faild. I said
> > it couldn't find the symbols it needed (calls to the methods of c++
> > objects). So I rewrote the thing moving the c++ dependencies to a
> > function in a plain c++ file. Strike 2. I checked around on the web
> > and discovered i needed the 'extern "C" {' thingy, so I added that. I
> > even rebuilt the external library, knowing that Ubuntu has more bugs
> > than rotting wood. Didn't help. I'm all out of ideas. Can anyone help?
> > Please let me know what information you need. Thanx!
> >
> > ___
> > 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: linking a C++ lib to an objc tool.
OK, it seems to compile well if poppler if if comes before base (ADDITIONAL_TOOLS_LIBS) and before the objective c runtime lib (ADDITIONAL_OBJC_LIBS), but not before everything (using ADDITIONAL_LDFLAGS). But now, no matter the order, it can't start, claiming that it can't find libgnustep-base.so.1.24. What things can cause this kind or error? On Sun, Aug 27, 2017 at 9:42 AM, David Chisnall wrote: > On 27 Aug 2017, at 13:29, Jamie Ramone wrote: > > > > > > > > On Sun, Aug 27, 2017 at 5:05 AM, David Chisnall > wrote: > > Most of the code that I’ve written recently using GNUstep has been > Objective-C++, so I can confirm that this work well (though I’m not using > gcc, where I believe Objective-C++ still has some rough corners). Looking > at your nm output, it appears as if the symbols are actually there (at > least, `_ZN7poppler5imageC2Ev` demangles to `poppler::image::image()`, > which is one of the missing symbols. > > > > Your nm output looks like it’s from a .a file though, not a .so. When > resolving symbols in static libraries, GNU linkers only look forwards in > the command line, so if you specify `ld a.a b.a` then undefined symbols in > `a.a` will be resolved to point to `b.a`, but undefined symbols in `b.a` > will not be resolved to point to `a.a`. You can solve this by either > providing the libraries twice (e.g. `ld a.a b.a a.a b.a`), or by using > --start-group and --end-group (e.g. `ld --start-group a.a b.a > --end-group`), which searches the archives in the group exhaustively until > it stops resolving all of the symbols. Or you can use lld, which doesn’t > have this braindead behaviour (which is both user hostile and increases the > algorithmic complexity of linking). > > > > No, I specifically typed in "nm ~/Developer/System/lib/libpoppler-cpp.so", > so it's not a static lib. Furthermore, I didn't use the -static flag > anywhere, and the libs included are done so using -lib_in_question, which > is only fore shared libs (static ones are just globed onto the collection > of object files during the link stage i.e. gcc a.o b.o c.o static_lib.a, > which I don't know how to do in GNUstep make). > > > > I’ve found in the past that GNUstep Make’s interfaces for adding linker > flags leaves a lot to be desired, because it doesn’t give much control over > where things go on the linker command line, but I believe that using the > relevant ADDITIONAL_*_LIBS variable will put the -lpoppler-cpp flag at the > end of the linker command line, which will make it work. > > > > Is there one for C++ libs? I checked the docs and it mentions GUI, OBJC, > and TOOLS. These indicate where, relative to the GNUstep libs in the > command line the added libs would go, but I'm not sure where I should put > it. I guess it's time to experiment with these... > > The linker doesn’t know or care what language the libraries are written > in. The GUI, OBJC, and TOOLS refer to the kind of thing you are building > (thing that uses AppKit, thing that doesn’t use Foundation or AppKit, thing > that uses only Foundatiion), not the kind of thing that you are linking it > with. > > David > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: linking a C++ lib to an objc tool.
On Sun, Aug 27, 2017 at 3:44 PM, Ivan Vučica wrote:
> Based on your makefile, I suspect you may have installed GNUstep's
> libraries into ${HOME}/Developer/System/lib, and have not taught the
> dynamic loader where to find the .so. Just because you've linked with the
> .a/.so correctly does not mean dynamic loader knows where to find the .so
> at runtime.
>
Well, yes. I don't like to mix it with system components lest installing
other things stomp all over it. I don't trust Ubuntu. But it's weird 'cause
it works just fine the way I have it set up with everything else that uses
GNUstep (TextEditor, PicoPixel, Terminal, etc)
> That is: Is the path to libgnustep-base.so* specified in /etc/ld.so.conf
> (or in a file in /etc/ld.so.conf.d)? Which libgnustep-base.so.1.24 is
> specified in the binary (use ldd on your binary)? I would not put something
> in ${HOME} into /etc/ld.so.conf, but it can be useful for diagnostics. You
> can also set LD_LIBRARY_PATH environment variable to expand the search path
> of the dynamic loader. See https://linux.die.net/man/8/ld.so
>
I've had LD_LIBRARY_PATH set to /home/jamie/Developer/System/lib for a long
time. GNUstep is installed into /home/jamie/Developer/System/ (i.e.
/home/jamie/Developer/System/LocalApps,
/home/jamie/Developer/System/LocalLibrary,
/home/jamie/Developer/System/SystemApps,
/home/jamie/Developer/System/SystemDeveloper, and
/home/jamie/Developer/System/SystemLibrary). GNUstep is not and never was
IN the linker's path. I just assumed this was taken care of by GNUstep.sh
(called at session start), since everything just worked
> Or, if what I suggest is not the case, try setting environment variable
> LD_DEBUG to value 'all' (no quotes) and try running your binary to see what
> the dynamic loader is doing.
>
Or, you can strace your binary and see which paths to
> libgnustep-base.so.1.24 are being open()ed.
>
I'll try that, thanx.
>
> On Sun, Aug 27, 2017 at 6:49 PM Jamie Ramone wrote:
>
>> OK, it seems to compile well if poppler if if comes before base
>> (ADDITIONAL_TOOLS_LIBS) and before the objective c runtime lib
>> (ADDITIONAL_OBJC_LIBS), but not before everything (using
>> ADDITIONAL_LDFLAGS). But now, no matter the order, it can't start, claiming
>> that it can't find libgnustep-base.so.1.24. What things can cause this kind
>> or error?
>>
>> On Sun, Aug 27, 2017 at 9:42 AM, David Chisnall
>> wrote:
>>
>>> On 27 Aug 2017, at 13:29, Jamie Ramone wrote:
>>> >
>>> >
>>> >
>>> > On Sun, Aug 27, 2017 at 5:05 AM, David Chisnall
>>> wrote:
>>> > Most of the code that I’ve written recently using GNUstep has been
>>> Objective-C++, so I can confirm that this work well (though I’m not using
>>> gcc, where I believe Objective-C++ still has some rough corners). Looking
>>> at your nm output, it appears as if the symbols are actually there (at
>>> least, `_ZN7poppler5imageC2Ev` demangles to `poppler::image::image()`,
>>> which is one of the missing symbols.
>>> >
>>> > Your nm output looks like it’s from a .a file though, not a .so. When
>>> resolving symbols in static libraries, GNU linkers only look forwards in
>>> the command line, so if you specify `ld a.a b.a` then undefined symbols in
>>> `a.a` will be resolved to point to `b.a`, but undefined symbols in `b.a`
>>> will not be resolved to point to `a.a`. You can solve this by either
>>> providing the libraries twice (e.g. `ld a.a b.a a.a b.a`), or by using
>>> --start-group and --end-group (e.g. `ld --start-group a.a b.a
>>> --end-group`), which searches the archives in the group exhaustively until
>>> it stops resolving all of the symbols. Or you can use lld, which doesn’t
>>> have this braindead behaviour (which is both user hostile and increases the
>>> algorithmic complexity of linking).
>>> >
>>> > No, I specifically typed in "nm ~/Developer/System/lib/libpoppler-cpp.so",
>>> so it's not a static lib. Furthermore, I didn't use the -static flag
>>> anywhere, and the libs included are done so using -lib_in_question, which
>>> is only fore shared libs (static ones are just globed onto the collection
>>> of object files during the link stage i.e. gcc a.o b.o c.o static_lib.a,
>>> which I don't know how to do in GNUstep make).
>>> >
>>> > I’ve found in the past that GNUstep Make’s interfaces for adding
>>> linker flags leaves a lot to be desired, because it doesn’t give much
>>> control over where things go on the linker command line, bu
Re: linking a C++ lib to an objc tool.
file=libsndfile.so.1 [0]; generating link map
19318: dynamic: 0x7f6763163d70 base: 0x7f6762eff000
size: 0x00267f20
19318: entry: 0x7f6762f057c0 phdr: 0x7f6762eff040
phnum: 7
19318:
19318:
19318: file=libao.so.4 [0]; needed by
/home/jamie/Developer/System/bin/LevelEditor [0]
19318: find library=libao.so.4 [0]; searching
19318: search path=/home/jamie/Developer/System/lib
(LD_LIBRARY_PATH)
19318: trying file=/home/jamie/Developer/System/lib/libao.so.4
19318: search cache=/etc/ld.so.cache
19318: trying file=/usr/lib/x86_64-linux-gnu/libao.so.4
19318:
19318: file=libao.so.4 [0]; generating link map
19318: dynamic: 0x7f6762efdda8 base: 0x7f6762cf6000
size: 0x002087a8
19318: entry: 0x7f6762cf7e70 phdr: 0x7f6762cf6040
phnum: 7
19318:
19318:
19318: file=libgnustep-gui.so.0.25 [0]; needed by
/home/jamie/Developer/System/bin/LevelEditor [0]
19318: find library=libgnustep-gui.so.0.25 [0]; searching
19318: search path=/home/jamie/Developer/System/lib
(LD_LIBRARY_PATH)
19318: trying file=/home/jamie/Developer/
System/lib/libgnustep-gui.so.0.25
19318: search cache=/etc/ld.so.cache
19318: search path=/lib/x86_64-linux-gnu/
tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/
x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/
x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-
gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/
lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/
usr/lib/x86_64:/usr/lib(system search path) 19318:
trying file=/lib/x86_64-linux-gnu/tls/x86_64/libgnustep-gui.so.0.25
19318: trying file=/lib/x86_64-linux-gnu/
tls/libgnustep-gui.so.0.25
19318: trying file=/lib/x86_64-linux-gnu/
x86_64/libgnustep-gui.so.0.25
19318: trying file=/lib/x86_64-linux-gnu/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64-linux-
gnu/tls/x86_64/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64-linux-
gnu/tls/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64-linux-
gnu/x86_64/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64-linux-
gnu/libgnustep-gui.so.0.25
19318: trying file=/lib/tls/x86_64/libgnustep-gui.so.0.25
19318: trying file=/lib/tls/libgnustep-gui.so.0.25
19318: trying file=/lib/x86_64/libgnustep-gui.so.0.25
19318: trying file=/lib/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/tls/x86_64/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/tls/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/x86_64/libgnustep-gui.so.0.25
19318: trying file=/usr/lib/libgnustep-gui.so.0.25
19318:
/home/jamie/Developer/System/bin/LevelEditor: error while loading shared
libraries: libgnustep-gui.so.0.25: cannot open shared object file: No such
file or directory
So it's not finding gnustep libs (gui in this case) it on its own, but when
loaded via openapp it does. To confirm this I ran openapp with no
arguments. It would spit out a message about its usage and exit, but should
load gui and/or base. Sure enough, when I run that command I get the same
27 MB of diagnostic messages. So I tried running my program via opentool.
Now I'm getting a segfault, this means it's running. I'll sort out the
cause of the segfault but I'm puzzled as to why openapp and opentool seem
to have this "linker independence".
On Sun, Aug 27, 2017 at 7:26 PM, Jamie Ramone wrote:
>
>
> On Sun, Aug 27, 2017 at 3:44 PM, Ivan Vučica wrote:
>
>> Based on your makefile, I suspect you may have installed GNUstep's
>> libraries into ${HOME}/Developer/System/lib, and have not taught the
>> dynamic loader where to find the .so. Just because you've linked with the
>> .a/.so correctly does not mean dynamic loader knows where to find the .so
>> at runtime.
>>
>
> Well, yes. I don't like to mix it with system components lest installing
> other things stomp all over it. I don't trust Ubuntu. But it's weird 'cause
> it works just fine the way I have it set up with everything else that uses
> GNUstep (TextEditor, PicoPixel, Terminal, etc)
>
>
>> That is: Is the path to libgnustep-base.so* specified in /etc/ld.so.conf
>> (or in a file in /etc/ld.so.conf.d)? Which libgnustep-base.so.1.24 is
>> specified in the binary (use ldd on your binary)? I would not put something
>> in ${HOME} into /etc/ld.so.conf, but it can be useful for diagnostics. You
>> can also set LD_LIBRARY_PATH environment variable to expand the search path
>> of the dynamic loader. See https://linux.die.ne
Re: linking a C++ lib to an objc tool.
Yes, of course it does. Open...how? You mean being able to view it's contents in mcedit? Yes. On Sun, Sep 3, 2017 at 7:36 AM, Ivan Vučica wrote: > Let's go back :) > > Does /home/jamie/Developer/System/lib/libgnustep-base.so.1.24 exist? Can > you open it? > > On Sun, Sep 3, 2017, 11:30 Jamie Ramone wrote: > >> Well, isn't this an interesting turn of events! So I tried your (Ivan's) >> idea of looking at what the linker's doing when the binary is run. This is >> the output: >> 19216: >> 19216: file=libpoppler-cpp.so.0 [0]; needed by >> Source/obj/WindowServer [0] >> 19216: find library=libpoppler-cpp.so.0 [0]; searching >> 19216: search path=/home/jamie/Developer/ >> System/lib/tls/x86_64:/home/jamie/Developer/System/lib/ >> tls:/home/jamie/Developer/System/lib/x86_64:/home/jamie/ >> Developer/System/lib (LD_LIBRARY_PATH) >> 19216: trying file=/home/jamie/Developer/ >> System/lib/tls/x86_64/libpoppler-cpp.so.0 >> 19216: trying file=/home/jamie/Developer/ >> System/lib/tls/libpoppler-cpp.so.0 >> 19216: trying file=/home/jamie/Developer/ >> System/lib/x86_64/libpoppler-cpp.so.0 >> 19216: trying file=/home/jamie/Developer/ >> System/lib/libpoppler-cpp.so.0 >> 19216: >> 19216: file=libpoppler-cpp.so.0 [0]; generating link map >> 19216: dynamic: 0x7f8f1c191d78 base: 0x7f8f1bf8 >> size: 0x002125d8 >> 19216: entry: 0x7f8f1bf885e0 phdr: 0x7f8f1bf80040 >> phnum: 7 >> 19216: >> 19216: >> 19216: file=libgnustep-base.so.1.24 [0]; needed by >> Source/obj/WindowServer [0] >> 19216: find library=libgnustep-base.so.1.24 [0]; searching >> 19216: search path=/home/jamie/Developer/System/lib >> (LD_LIBRARY_PATH) >> 19216: trying file=/home/jamie/Developer/ >> System/lib/libgnustep-base.so.1.24 >> 19216: search cache=/etc/ld.so.cache >> 19216: search path=/lib/x86_64-linux-gnu/ >> tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/ >> x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/ >> x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux- >> gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/ >> lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/ >> usr/lib/x86_64:/usr/lib(system search path) 19216: >> trying file=/lib/x86_64-linux-gnu/tls/x86_64/libgnustep-base.so.1.24 >> 19216: trying file=/lib/x86_64-linux-gnu/ >> tls/libgnustep-base.so.1.24 >> 19216: trying file=/lib/x86_64-linux-gnu/ >> x86_64/libgnustep-base.so.1.24 >> 19216: trying file=/lib/x86_64-linux-gnu/ >> libgnustep-base.so.1.24 >> 19216: trying file=/usr/lib/x86_64-linux- >> gnu/tls/x86_64/libgnustep-base.so.1.24 >> 19216: trying file=/usr/lib/x86_64-linux- >> gnu/tls/libgnustep-base.so.1.24 >> 19216: trying file=/usr/lib/x86_64-linux- >> gnu/x86_64/libgnustep-base.so.1.24 >> 19216: trying file=/usr/lib/x86_64-linux- >> gnu/libgnustep-base.so.1.24 >> 19216: trying file=/lib/tls/x86_64/libgnustep-base.so.1.24 >> 19216: trying file=/lib/tls/libgnustep-base.so.1.24 >> 19216: trying file=/lib/x86_64/libgnustep-base.so.1.24 >> 19216: trying file=/lib/libgnustep-base.so.1.24 >> 19216: trying file=/usr/lib/tls/x86_64/libgnustep-base.so.1.24 >> 19216: trying file=/usr/lib/tls/libgnustep-base.so.1.24 >> 19216: trying file=/usr/lib/x86_64/libgnustep-base.so.1.24 >> 19216: trying file=/usr/lib/libgnustep-base.so.1.24 >> 19216: >> >> It's not finding libgnustep-base.so.1.24, but we knew that. Yet I had >> been using GNUstep apps with no problem. So I checked doing openapp >> LevelEditor and it worked fine, as I expected, and spewed out some 27 MB of >> diagnostic messages to the console. Clearly it was finding >> libgnustep-base.so.1.24. So why did the app work but not my binary. I tried >> running LevelEditor directly. Then this happened: >> >> LD_DEBUG=all ~/Developer/System/bin/LevelEditor >> 19318: >> 19318: file=libxmp.so.4 [0]; needed by >> /home/jamie/Developer/System/bin/LevelEditor [0] >> 19318: find library=libxmp.so.4 [0]; searching >> 19318: search path=/home/jamie/Developer/ >> System/lib/tls/x86_64:/home/jamie/Developer/System/lib/
