opening file:line in existing CL instance

General questions regarding the usage of CodeLite
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

opening file:line in existing CL instance

Post by petah »

Hi Eran,

I have a CL project with some javascript files that I pass to an external program (Mixxx). I put a wxFileSystenWatcher on its log, from which I extract a javascript error's file:line then open that js file in CL with wxExecute() and '--line' but it always opens a new CL instance.

Is there a way to open the file with any existing CL instance, say by passing a pid?

It doesn't have to handle multiple CL instances or platforms other than Linux; it's just for debugging.

TIA!

-- p
main: Debian Jessie x64 + custom wxTrunk
User avatar
eranif
CodeLite Plugin
Posts: 6373
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: opening file:line in existing CL instance

Post by eranif »

I am working on a small plugin: "tail" ... (not ready yet, if you need it I can boost the development ...)
will this answer your problem?

Eran
Make sure you have read the HOW TO POST thread
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: opening file:line in existing CL instance

Post by petah »

I don't think so cause I'm filtering the log with cascading regexes to only capture relevant entries. I already got the fswatcher to work, what I need is to talk to an open CL instance. I was looking at codelite_launcher.cpp but it kills an existing instance first and I don't think I can hook into an existing instance.

I think what I need is a CL cmd-line argument like "--existing-instance" whose logic would be somewhere around the "Allow only single instance running" check.

I wrote something like that a while back: instance B checks if an existing instance A exists and if so B sends a message to A, then B quits. It was a bit messy because it used TCP for cross-instance messages so setup a TCP server after that check. There's probably a less verbose method that I don't know.

You already have the codelite indexer as a seperate process, maybe you already have cross-instance messaging?

thx again,

-- p
main: Debian Jessie x64 + custom wxTrunk
User avatar
eranif
CodeLite Plugin
Posts: 6373
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: opening file:line in existing CL instance

Post by eranif »

I have built unix sockets/windows named pipes
But I would rather introduce new messaging system like ZeroMQ which is a built-in Messaging Queue

But maybe adding some regex filtering to the plugin is not such a bad idea... ( I will probably will add it even if you won't be using it )

Eran
Make sure you have read the HOW TO POST thread
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: opening file:line in existing CL instance

Post by petah »

eranif wrote:I have built unix sockets/windows named pipes
Cool, I didn't know they were x-platform.
eranif wrote:But I would rather introduce new messaging system like ZeroMQ which is a built-in Messaging Queue
I read about it, it's fascinating and crazy at the same time :) I wonder how Windows' privilege checker reacts on those non-IP packets.
eranif wrote:But maybe adding some regex filtering to the plugin is not such a bad idea... ( I will probably will add it even if you won't be using it )
Here are the regexes I use:

Code: Select all

const wxString	MIXXX_PRINT_REGEX = "^Debug \\[Controller\\]: \"CDJ2MIDI: (.*)\"";
const wxString	MIXXX_DEBUG_REGEX = "^(Debug|Warning) \\[Controller\\]: (.*)";
// UNGREEDY operator '.*?' (requires wxRE_ADVANCED)
const wxString	MIXXX_JAVSCRIPT_ERROR_REGEX = "ControllerEngine: \"(Incomplete code|Syntax error|Uncaught exception) at line ([[:digit:]]+).*? in file ([^:]+):[[:space:]]*(.*)";
they're in a specific order with conditionals, output is colored by type and errors are formatted to appear as a URL in wxTextCtrl, with a matching event handler. Probably overkill but I hate javascript and the host app's error message box is useless.

-- p
main: Debian Jessie x64 + custom wxTrunk
Post Reply