The background for all this: I did not t run into this very often in the past.
I have about 40 library sets that I compile into static libs. A library is one profile set. 10 minimum to about 35 on a largest set, usually in at least three directories. (I made a build system that keeps everybody in its proper place - but this means a couple more files per lib.) After a library is stable, I don't touch it again. For current work, I have a script system that brings up the sets of programs and libraries that I am working on currently. This script set also brings up the needed consoles on each desktop for each particular program/libray I am working on. These consoles are opened outside of geany. Any one library I work on may need 3 to 5 other profiles opened so I can keep everything correctly referenced without opening and closing, opening and closing again and again. (I'm old - I doubt my memory sometimes, these days.) Every so often, I need to go back and adjust an old library (recently, for mutlithreading changes, for example.) I never made a script for those older libraries. In this instance, I bring those profiles up on a clean system manually, and start the consoles from geany. This is when I have these problems frequently. Even on the new scripts, especially because of threading issues, I sometimes bork a console, need to close it, and open a fresh console. This is when I first started to notice this problem, but didn't worry about it. Now that I am going back to some of the old libs to make changes, I am hitting this very frequently. The scripting for multiple sessions and opening the consoles is relatively new - no more than 2 years old. Previously, every session was opened manually, with its consoles from inside geany. I never had this problem, then. One of those scripts, and one library profile is attached for your info. The rdkl directory is on a remote server. This and any system I work on or edit with are in my home. David On Wed, Jul 26, 2017 at 8:45 AM, David Barnes <[email protected]> wrote: > Yes, more than one session of geany. > NOT completely independent. > > --------------------- > > A circumstamce: > > Several geany sessions opened - mulitple files open in each with no files > opened in more than one session. > > No activity in ANY geany instance. > > Open a console in one session, for example on desktop 2. > > Another session - maybe desktop 6 - shows the activity status with that > sessions's build menu blocked. > Close the console, indicator and build menu released. > > When I tested this yesterday, I had no other user programs of any kind up > after a clean boot. > > -------------------- > > Yes, did try the '&' terminator on the command - no difference. > > My new solution: one session I typically open is a reference only session: > I rarely need to edit there. I pop open consoles there until I get the > lock, then I can use the other sessions. NOT elegant. > > I understand about mixed messages and confused sources/destinations in an > OS. But this means that geany is listening for any message to any geany - > even when no build menu item - or any action - was requested. Is THAT > happening? I thought the messaging systems all had client identifiers to > keep things seperated. > > A thought: I imagine geany does broadcast messages that files have been > changed, and every instance does need to listen for that. Perhaps there is > a misidentification of the activity there. > > version: "Rezer" > (built on or after 2016-04-17) > > > David > > On Wed, Jul 26, 2017 at 1:54 AM, Lex Trotman <[email protected]> wrote: > >> On 26 July 2017 at 17:48, David Barnes <[email protected]> wrote: >> > By the way, only ONE session gets locked up. Never noticed more than >> one, no >> > matter how many more sessions or consoles are opened, or opened and >> closed. >> >> When you say "session" what do you mean? Do you mean you are running >> multiple instances of Geany? >> >> If so then they are completely independent processes, so running a >> blocking command in one instance will have no effect on the other >> instances. >> >> Because the output of build commands is parsed and displayed in the >> compiler output tab only one build command can be running at a time or >> their output will get mixed up and confused. >> >> So the build menu is blocked whilst a command is running. So as I >> said before, the command needs to start your terminal as a detached >> process and exit immediately to get the menu back. Did you try using >> &? On *x commands are run in sh so it should work. >> >> > >> > On Wed, Jul 26, 2017 at 12:30 AM, David Barnes <[email protected]> >> wrote: >> >> >> >> Yep. If I start a console from a geany session, that 'process busy' >> >> indicator will show up - somewhere. I open at least three sessions >> anytime I >> >> work. Any one of them may have that indicator, and consequently, the >> build >> >> menu greyed out. When I close the console, it clears. >> >> >> >> A typical project session will have files sourced from as many as four >> >> different directories. That means, I might want to open 4 consoles, >> though >> >> usually it is just 2. >> >> For most sessions, I automatically open 2 consoles. Since this can lock >> >> one geany build menu in some **other** geany session on a different >> desktop, >> >> I would have to close all the consoles to find the offender. That >> could be >> >> ten consoles to drop before I find which is the problem. >> >> >> >> This was not a problem in the past. I never saw that indicator in the >> >> past. >> >> >> >> Now - this is a deal breaker. >> >> >> >> Can that process busy indicator be supressed? >> >> >> >> David >> >> >> >> >> >> On Sun, Jul 23, 2017 at 6:08 PM, Lex Trotman <[email protected]> wrote: >> >>> >> >>> On 24 July 2017 at 06:33, David Barnes <[email protected]> wrote: >> >>> > Thank you for the quick reply. >> >>> > >> >>> > >> >>> > It looks like it may be sitting and waiting when I open a console >> from >> >>> > a >> >>> > build command button I made - sometimes. (I think I made it happen >> once >> >>> > a >> >>> > moment ago.) >> >>> > >> >>> > I typically start an edit session with a script that opens from 4 >> to 6 >> >>> > geany >> >>> > projects on different screens, with up to 3 other terminals/file >> >>> > managers >> >>> > open on a single desktop with geany. So ... minimum 4 geany sessions >> >>> > with >> >>> > 50+ (remote) files total + 7 consoles + 2 file managers with one >> >>> > script. >> >>> > Rarely have a problem. Some of my edit profiles are much larger. >> >>> > >> >>> > >> >>> > My console command ( is: >> >>> > >> >>> > [build-menu] >> >>> > NF_03_LB=console >> >>> > NF_03_CM=lxterminal --geometry=130x30& --working-directory=%d >> >>> > NF_03_WD= >> >>> > >> >>> > >> >>> > Can something be used or option set, like a '&' in a script, to have >> >>> > geany >> >>> > NOT wait for a response? >> >>> > >> >>> >> >>> You just make your command spawn the terminal and return to Geany >> >>> without waiting. >> >>> >> >>> Cheers >> >>> Lex >> >>> >> >>> > >> >>> > >> >>> > David >> >>> > >> >>> > >> >>> > On Sun, Jul 23, 2017 at 10:51 AM, Matthew Brush < >> [email protected]> >> >>> > wrote: >> >>> >> >> >>> >> On 2017-07-23 09:16 AM, David Barnes wrote: >> >>> >>> >> >>> >>> Started recently (during last 12 months, perhaps.) >> >>> >>> >> >>> >>> At times, a side-scrolling status indicator pops up on status bar. >> >>> >>> When this is present, all commands in build menu are greyed out. >> >>> >>> >> >>> >>> **I can find no description of this status indicator.** >> >>> >>> The only way to clear it is to close geany. >> >>> >>> Closing the file or the project doesn't clear it. >> >>> >>> >> >>> >>> Closing all other instances of geany does not clear it. >> >>> >>> >> >>> >>> The files are on a networked drive. I have persistent >> connections. I >> >>> >>> have >> >>> >>> all permissions. >> >>> >>> >> >>> >>> I am able to edit, and save a file while in this condition. >> >>> >>> >> >>> >>> This only happens occasionally, but means I must close down in the >> >>> >>> middle >> >>> >>> of work >> >>> >>> when I may have multiple files setup to make a set of changes. >> >>> >>> >> >>> >>> This is true for several machines I use. >> >>> >>> >> >>> >>> example pics attached >> >>> >>> >> >>> >> >> >>> >> I believe that progress bar only appears while Geany is running a >> >>> >> subprocess. It sounds like you're starting a build command that >> never >> >>> >> exits. >> >>> >> >> >>> >> Regards, >> >>> >> Matthew Brush >> >>> >> _______________________________________________ >> >>> >> Users mailing list >> >>> >> [email protected] >> >>> >> https://lists.geany.org/cgi-bin/mailman/listinfo/users >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > If you don't try - you lose - automatically. >> >>> > >> >>> > _______________________________________________ >> >>> > Users mailing list >> >>> > [email protected] >> >>> > https://lists.geany.org/cgi-bin/mailman/listinfo/users >> >>> > >> >>> _______________________________________________ >> >>> Users mailing list >> >>> [email protected] >> >>> https://lists.geany.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >> >> >> >> >> -- >> >> If you don't try - you lose - automatically. >> > >> > >> > >> > >> > -- >> > If you don't try - you lose - automatically. >> > >> > _______________________________________________ >> > Users mailing list >> > [email protected] >> > https://lists.geany.org/cgi-bin/mailman/listinfo/users >> > >> _______________________________________________ >> Users mailing list >> [email protected] >> https://lists.geany.org/cgi-bin/mailman/listinfo/users >> > > > > -- > If you don't try - you lose - automatically. > -- If you don't try - you lose - automatically.
threads.sh
Description: Bourne shell script
common.geany
Description: Binary data
_______________________________________________ Users mailing list [email protected] https://lists.geany.org/cgi-bin/mailman/listinfo/users
