Re: Can't drag&drop menu in Gorm
Hi Greg, could you please describe what you did try? I had problems to understand the original report and therefore had to experiment a bit to get the same situation. Fred On the road Am 28.12.2013 um 06:10 schrieb Gregory Casamento : > Hey guys, > > I just tried this with a recent build on my x86 based Debian Linux build of > GNUstep and Gorm. It works for me. I also did a fresh build on my x86-64 > machine also running Debian. Both machines are using Debian wheezy. > > Could you provide me with some additional details with respect to your > installation? I'm unable to reproduce this with my current setup. > > Greg > > >> On Thu, Dec 26, 2013 at 12:43 PM, Fred Kiefer wrote: >> On 26.12.2013 18:14, Germán Arias wrote: >> > El jue, 26-12-2013 a las 16:27 +0100, Fred Kiefer escribió: >> >> On 25.12.2013 22:33, Germán Arias wrote: >> >>> Actually isn't possible drag&drop a menu in Gorm. Open an empty >> >>> documento and try to add a menu, you can't. >> >> >> >> I am not sure whether I understand this problem. By "open and empty >> >> document" do you mean "Document->New Application"? In that case you >> >> already get a main menu and I was able to drag a menu entry into this >> >> menu. Is this not working for you or don't you get the initial menu? And >> >> is D&D otherwise working for you in Gorm? It wasn't for me a few days >> >> ago and I had to fix the x11 backend for this to work. >> >> >> >> Fred >> >> >> >> >> > >> > Select "Document -> New Module -> New Empty", in this case I can't add a >> > menu. This is also the case when use in-window menu, you can't add a >> > menu in untitled document. >> >> Ah, I think I understand now. You create an empty module as described >> above and then drag a window into that module and as the next step you >> would like to drag in a menu as well but this isn't working. I am able >> to reproduce this. >> Maybe the window that holds all the objects (no idea how this is called >> internally) does not allow for what ever drag type the menu is? This is >> the spot where Gregory should take over, he knows a lot more about Gorm. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Profiling Traces
Hi Ivan, TESLA has a web site, which covers getting started: http://www.cl.cam.ac.uk/research/security/ctsrd/tesla/build.html For the traces, I actually replaced the debugging printf handler to log the raw events. We're hopefully going to separate TESLA into some cleaner layering, so the event-generation code is more isolated from the event-handling code and we can more easily plug other bits of tracing into it. If you just want traces of message sends, then the latest version of the runtime has a mechanism for interposing on a particular selector, which is what TESLA uses. David On 23 Dec 2013, at 15:49, Ivan Vučica wrote: > Thread necromancy! > > During GSoC2013, I would have loved to have something like the contents of > "Drawing.log", annotated with screenshots and perhaps some additional state > etc. As you mentioned, it would have helped a lot in development of the Opal > backend. > > Is something like generating screenshots (or making a function call), then > integrating an inside the log, possible with TESLA? > > Any instructions on using TESLA? > > On Wed Oct 02 2013 at 3:59:25 PM, David Chisnall wrote: > Hello all of the GNUstep developers, > > We've recently been working on a tool called TESLA that allows you to write > temporal assertions (e.g. before you get here, this other function must have > been called and returned this value) that are checked at run time, but also > provides a convenient way of adding instrumentation to programs. > > I've uploaded a couple of profiling traces to give people an idea of the > kinds of thing this can generate: > > http://theravensnest.org/Drawing.log > http://theravensnest.org/NSCursor.log > > The first is a log of all of the drawing messages in the protocol defined by > NSGraphicsContext (i.e. the thing used to communicate between -gui and > -back), indented based on the current view and cell that is responsible for > the drawing. This doesn't provide a full stack trace, just some context. > The motivation for this is Ivan's work on the Opal back end, and looking at > exactly how the back end is used. Are we doing too many pushes and pops of > graphics state, or saving and restoring when we don't need to? Are we > calling methods a lot that are poorly optimised in the back end? > > The second is a stack trace, generated in every place where we call a push or > pop method. The motivation for this was the recent work trying to find bugs > in the NSCursor balancing code. Unfortunately, I wasn't able to reproduce > the bugs when I tried (maybe they're all fixed?) and so this isn't very > useful, although it might be interesting. > > Can anyone else think of other useful traces that we might want to generate? > > David > > -- Sent from my Apple II > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Can't drag&drop menu in Gorm
I first of the clean build of core then installed then did a clean build a corn and installed open quorum and then dragged and dropped into the empty document than the sick On Saturday, December 28, 2013, Fred Kiefer wrote: > Hi Greg, > > could you please describe what you did try? I had problems to understand > the original report and therefore had to experiment a bit to get the same > situation. > > Fred > > On the road > > Am 28.12.2013 um 06:10 schrieb Gregory Casamento > 'greg.casame...@gmail.com');> > >: > > Hey guys, > > I just tried this with a recent build on my x86 based Debian Linux build > of GNUstep and Gorm. It works for me. I also did a fresh build on my > x86-64 machine also running Debian. Both machines are using Debian wheezy. > > Could you provide me with some additional details with respect to your > installation? I'm unable to reproduce this with my current setup. > > Greg > > > On Thu, Dec 26, 2013 at 12:43 PM, Fred Kiefer > > > wrote: > >> On 26.12.2013 18:14, Germán Arias wrote: >> > El jue, 26-12-2013 a las 16:27 +0100, Fred Kiefer escribió: >> >> On 25.12.2013 22:33, Germán Arias wrote: >> >>> Actually isn't possible drag&drop a menu in Gorm. Open an empty >> >>> documento and try to add a menu, you can't. >> >> >> >> I am not sure whether I understand this problem. By "open and empty >> >> document" do you mean "Document->New Application"? In that case you >> >> already get a main menu and I was able to drag a menu entry into this >> >> menu. Is this not working for you or don't you get the initial menu? >> And >> >> is D&D otherwise working for you in Gorm? It wasn't for me a few days >> >> ago and I had to fix the x11 backend for this to work. >> >> >> >> Fred >> >> >> >> >> > >> > Select "Document -> New Module -> New Empty", in this case I can't add a >> > menu. This is also the case when use in-window menu, you can't add a >> > menu in untitled document. >> >> Ah, I think I understand now. You create an empty module as described >> above and then drag a window into that module and as the next step you >> would like to drag in a menu as well but this isn't working. I am able >> to reproduce this. >> Maybe the window that holds all the objects (no idea how this is called >> internally) does not allow for what ever drag type the menu is? This is >> the spot where Gregory should take over, he knows a lot more about Gorm. >> > -- 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: Can't drag&drop menu in Gorm
I really need to learn to stop using my phone dictation to send emails. I did a clean build of core, then a clean build of GORM. I then created a new empty document, then I went to the pallete and dragged a menu into it. I did this on both platforms precisely the same and it worked for me please let me know if I'm missing something. On Saturday, December 28, 2013, Gregory Casamento wrote: > I first of the clean build of core then installed then did a clean build > a corn and installed open quorum and then dragged and dropped into the > empty document than the sick > > On Saturday, December 28, 2013, Fred Kiefer wrote: > >> Hi Greg, >> >> could you please describe what you did try? I had problems to understand >> the original report and therefore had to experiment a bit to get the same >> situation. >> >> Fred >> >> On the road >> >> Am 28.12.2013 um 06:10 schrieb Gregory Casamento < >> greg.casame...@gmail.com>: >> >> Hey guys, >> >> I just tried this with a recent build on my x86 based Debian Linux build >> of GNUstep and Gorm. It works for me. I also did a fresh build on my >> x86-64 machine also running Debian. Both machines are using Debian wheezy. >> >> Could you provide me with some additional details with respect to your >> installation? I'm unable to reproduce this with my current setup. >> >> Greg >> >> >> On Thu, Dec 26, 2013 at 12:43 PM, Fred Kiefer wrote: >> >>> On 26.12.2013 18:14, Germán Arias wrote: >>> > El jue, 26-12-2013 a las 16:27 +0100, Fred Kiefer escribió: >>> >> On 25.12.2013 22:33, Germán Arias wrote: >>> >>> Actually isn't possible drag&drop a menu in Gorm. Open an empty >>> >>> documento and try to add a menu, you can't. >>> >> >>> >> I am not sure whether I understand this problem. By "open and empty >>> >> document" do you mean "Document->New Application"? In that case you >>> >> already get a main menu and I was able to drag a menu entry into this >>> >> menu. Is this not working for you or don't you get the initial menu? >>> And >>> >> is D&D otherwise working for you in Gorm? It wasn't for me a few days >>> >> ago and I had to fix the x11 backend for this to work. >>> >> >>> >> Fred >>> >> >>> >> >>> > >>> > Select "Document -> New Module -> New Empty", in this case I can't add >>> a >>> > menu. This is also the case when use in-window menu, you can't add a >>> > menu in untitled document. >>> >>> Ah, I think I understand now. You create an empty module as described >>> above and then drag a window into that module and as the next step you >>> would like to drag in a menu as well but this isn't working. I am able >>> to reproduce this. >>> Maybe the window that holds all the objects (no idea how this is called >>> internally) does not allow for what ever drag type the menu is? This is >>> the spot where Gregory should take over, he knows a lot more about Gorm. >>> >> > > -- > 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
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 '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: Can't drag&drop menu in Gorm
On 28.12.2013 14:17, Gregory Casamento wrote: > I really need to learn to stop using my phone dictation to send emails. But it was fun to read :-) > I did a clean build of core, then a clean build of GORM. I then created a > new empty document, then I went to the pallete and dragged a menu into it. > I did this on both platforms precisely the same and it worked for me please > let me know if I'm missing something. Yes, that is what needs to be tested. In the meantime I tried with my Windows virtual machine and there it works. Looks like German and I have a local problem we need to solve ourselves. Still it would help if you could point me to the class that should be accepting the drag of the menu. Is it GormObjectEditor? > On Saturday, December 28, 2013, Gregory Casamento wrote: > >> I first of the clean build of core then installed then did a clean build >> a corn and installed open quorum and then dragged and dropped into the >> empty document than the sick >> >> On Saturday, December 28, 2013, Fred Kiefer wrote: >> >>> Hi Greg, >>> >>> could you please describe what you did try? I had problems to understand >>> the original report and therefore had to experiment a bit to get the same >>> situation. >>> >>> Fred >>> >>> On the road >>> >>> Am 28.12.2013 um 06:10 schrieb Gregory Casamento < >>> greg.casame...@gmail.com>: >>> >>> Hey guys, >>> >>> I just tried this with a recent build on my x86 based Debian Linux build >>> of GNUstep and Gorm. It works for me. I also did a fresh build on my >>> x86-64 machine also running Debian. Both machines are using Debian wheezy. >>> >>> Could you provide me with some additional details with respect to your >>> installation? I'm unable to reproduce this with my current setup. >>> >>> Greg >>> >>> >>> On Thu, Dec 26, 2013 at 12:43 PM, Fred Kiefer wrote: >>> On 26.12.2013 18:14, Germán Arias wrote: > El jue, 26-12-2013 a las 16:27 +0100, Fred Kiefer escribió: >> On 25.12.2013 22:33, Germán Arias wrote: >>> Actually isn't possible drag&drop a menu in Gorm. Open an empty >>> documento and try to add a menu, you can't. >> >> I am not sure whether I understand this problem. By "open and empty >> document" do you mean "Document->New Application"? In that case you >> already get a main menu and I was able to drag a menu entry into this >> menu. Is this not working for you or don't you get the initial menu? And >> is D&D otherwise working for you in Gorm? It wasn't for me a few days >> ago and I had to fix the x11 backend for this to work. >> >> Fred >> >> > > Select "Document -> New Module -> New Empty", in this case I can't add a > menu. This is also the case when use in-window menu, you can't add a > menu in untitled document. Ah, I think I understand now. You create an empty module as described above and then drag a window into that module and as the next step you would like to drag in a menu as well but this isn't working. I am able to reproduce this. Maybe the window that holds all the objects (no idea how this is called internally) does not allow for what ever drag type the menu is? This is the spot where Gregory should take over, he knows a lot more about Gorm. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Can't drag&drop menu in Gorm
Fred, On Sat, Dec 28, 2013 at 8:33 AM, Fred Kiefer wrote: > On 28.12.2013 14:17, Gregory Casamento wrote: > > I really need to learn to stop using my phone dictation to send emails. > > But it was fun to read :-) > > LOL, they often are. ;) > > I did a clean build of core, then a clean build of GORM. I then created a > > new empty document, then I went to the pallete and dragged a menu into > it. > > I did this on both platforms precisely the same and it worked for me > please > > let me know if I'm missing something. > > Yes, that is what needs to be tested. In the meantime I tried with my > Windows virtual machine and there it works. Looks like German and I have > a local problem we need to solve ourselves. Still it would help if you > could point me to the class that should be accepting the drag of the > menu. Is it GormObjectEditor? Yes, that is one of the places you need to look. Also look at GormPalettesManager. There is code there which specifically handles dragging of menus and windows in the method draggedImage:endedAt:deposited: near line 105. Are you both using Ubuntu? Perhaps I could help further by using a VM that runs Ubuntu instead of debian. Greg -- 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: Can't drag&drop menu in Gorm
On 28.12.2013 15:28, Gregory Casamento wrote: > Fred, > > On Sat, Dec 28, 2013 at 8:33 AM, Fred Kiefer wrote: > >> On 28.12.2013 14:17, Gregory Casamento wrote: >>> I really need to learn to stop using my phone dictation to send emails. >> >> But it was fun to read :-) >> >> > LOL, they often are. ;) > >>> I did a clean build of core, then a clean build of GORM. I then created a >>> new empty document, then I went to the pallete and dragged a menu into >> it. >>> I did this on both platforms precisely the same and it worked for me >> please >>> let me know if I'm missing something. >> >> Yes, that is what needs to be tested. In the meantime I tried with my >> Windows virtual machine and there it works. Looks like German and I have >> a local problem we need to solve ourselves. Still it would help if you >> could point me to the class that should be accepting the drag of the >> menu. Is it GormObjectEditor? > > > Yes, that is one of the places you need to look. Also look at > GormPalettesManager. There is code there which specifically handles > dragging of menus and windows in the method draggedImage:endedAt:deposited: > near line 105. Thank you that seems to be the drag source. I also found the drag destination it is the class GormDocumentWindow. > Are you both using Ubuntu? Perhaps I could help further by using a VM that > runs Ubuntu instead of debian. No I am using OpenSuse with a KDE window system. One of the problems here seems to be that the D&D code always finds a window added by the kwin window manager. That in itself might be the whole issue. But I am wondering why this only happens for the menu, not for the window. Dragging any sort of window works as expected. On the other hand dragging a menu fails all the time. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Can't drag&drop menu in Gorm
Hi, Fred Kiefer wrote: Ah, I think I understand now. You create an empty module as described above and then drag a window into that module and as the next step you would like to drag in a menu as well but this isn't working. I am able to reproduce this. Maybe the window that holds all the objects (no idea how this is called internally) does not allow for what ever drag type the menu is? This is the spot where Gregory should take over, he knows a lot more about Gorm. I just tried: 1) Start Gorm 2) new empty module 3) drag menu into the gorm document works fine, NSMenu gets added, opened and contains "Hide" and "Quit"... i386 / NetBSD / clang + libobjc2 in the test I just tried. Riccardo ___ 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
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 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 >> > > -- 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: Can't drag&drop menu in Gorm
Just for context... I did it on: Wheezy on x86 using GCC Wheezy on x86_64 using clang + libobjc2 Wheezy on ARM (raspberrypi) using GCC GC On Sat, Dec 28, 2013 at 1:30 PM, Riccardo Mottola wrote: > Hi, > > > Fred Kiefer wrote: > >> Ah, I think I understand now. You create an empty module as described >> above and then drag a window into that module and as the next step you >> would like to drag in a menu as well but this isn't working. I am able >> to reproduce this. >> Maybe the window that holds all the objects (no idea how this is called >> internally) does not allow for what ever drag type the menu is? This is >> the spot where Gregory should take over, he knows a lot more about Gorm. >> >> I just tried: > 1) Start Gorm > 2) new empty module > 3) drag menu into the gorm document > > works fine, NSMenu gets added, opened and contains "Hide" and "Quit"... > > i386 / NetBSD / clang + libobjc2 in the test I just tried. > > Riccardo > > > ___ > 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
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
>
> 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.
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 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=0
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:] (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
>>
Re: Serious GORM bug
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
>> #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,
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 > >> #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 remo
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 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. >> >
Re: Serious GORM bug
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: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
Re: Can't drag&drop menu in Gorm
El sáb, 28-12-2013 a las 15:50 -0500, Gregory Casamento escribió: > Just for context... > > > I did it on: > > > Wheezy on x86 using GCC > Wheezy on x86_64 using clang + libobjc2 > Wheezy on ARM (raspberrypi) using GCC > > > GC > > My problem is at Trisquel 6 (Ubuntu 12.04 based) with Gnome3 as desktop. Could be a problem of desktop? I will try with WindowMaker later (I changed my hard disk so I don't have all installed yet). Germán. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Serious GORM bug
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
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: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=, th
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
