1. Kat / RDS: File locking
Kat wrote:
>
> Is this two different topics now?
> Re: kat rebooting <<== nothing to do with docs online
> Re: using a language <<== nothing to do with rebooting
>
You're right. I mindlessly replied without changing the subject...
>
> No flames needed, but remember that issue i have brought up many times
> over the years, the file locking that Eu does? The file locking that RDS says
> may occur during the linking, but then stop? It STILL doesn't stop. So pretty
> much for each and every application i do, for each running process, i find
> there's a lot less problems if i drag/drop the required files to a new dir,
> using
> a separate everything for each process. It's really annoying to find 6 Eu apps
>
> tried to start, and only the first one succeeded.
>
> Kat
>
Just thought I'd pipe in about the file locking thing. I've been using
ConText for editing my programs (with hotkey/one-button execution). When
I'm debugging I'll run the program from the editor, read the run-time error
without pressing Enter to continue, fix the error and save the file. But
sometimes the file saves just fine (even with the previous instance still
waiting for my 'Enter'), and other times it refuses to save the file
(presumably locked by the interpreter) until I close the previously-errored
session.
I'd say it's about 50/50 whether I can save it while the errored interpreter
was waiting for my key press to end.
I have no idea if this is related to Kat's issues but thought it might be
relevant enough to mention. Might even be a ConText issue...
-- Brian
2. Re: Kat / RDS: File locking
On Thu, 23 Sep 2004 02:04:46 -0700, Brian Broker
<guest at RapidEuphoria.com> wrote:
>Just thought I'd pipe in about the file locking thing. I've been using
>ConText for editing my programs (with hotkey/one-button execution). When
>I'm debugging I'll run the program from the editor, read the run-time error
>without pressing Enter to continue, fix the error and save the file. But
>sometimes the file saves just fine (even with the previous instance still
>waiting for my 'Enter'), and other times it refuses to save the file
>(presumably locked by the interpreter) until I close the previously-errored
>session.
>
>I'd say it's about 50/50 whether I can save it while the errored interpreter
>was waiting for my key press to end.
>
>I have no idea if this is related to Kat's issues but thought it might be
>relevant enough to mention. Might even be a ConText issue...
>
I can understand an editor not wanting to save a file it thinks
another application is reading. I have suffered this in Code Genie and
Crimson, but never in MEditor. If anything, I've occasionally wanted
MEditor to detect this as well, but the disadvantages it would bring
have so far prevented me from even investigating how it would be done.
Occasionally, when I have a file open in MEditor, my zip program
(presumably written in C) refuses to _read_ that file until I close it
in MEditor. 49 out of 50 times it has no problem.
That I find a bit strange,
Pete
3. Re: Kat / RDS: File locking
On 23 Sep 2004, at 2:04, Brian Broker wrote:
>
>
> posted by: Brian Broker <bkb at cnw.com>
>
> Kat wrote:
> >
> > Is this two different topics now?
> > Re: kat rebooting <<== nothing to do with docs online
> > Re: using a language <<== nothing to do with rebooting
> >
>
> You're right. I mindlessly replied without changing the subject...
>
> >
> > No flames needed, but remember that issue i have brought up many
times
> > over the years, the file locking that Eu does? The file locking that RDS
says
> > may occur during the linking, but then stop? It STILL doesn't stop. So
pretty
> > much for each and every application i do, for each running process, i find
> > there's a lot less problems if i drag/drop the required files to a new dir,
> > using a separate everything for each process. It's really annoying to find 6
> > Eu apps tried to start, and only the first one succeeded.
> >
> > Kat
> >
>
> Just thought I'd pipe in about the file locking thing. I've been using
> ConText for editing my programs (with hotkey/one-button execution).
When
> I'm debugging I'll run the program from the editor, read the run-time error
> without pressing Enter to continue, fix the error and save the file. But
> sometimes the file saves just fine (even with the previous instance still
> waiting for my 'Enter'), and other times it refuses to save the file
(presumably
> locked by the interpreter) until I close the previously-errored session.
>
> I'd say it's about 50/50 whether I can save it while the errored interpreter
was
> waiting for my key press to end.
>
> I have no idea if this is related to Kat's issues but thought it might be
> relevant enough to mention. Might even be a ConText issue...
It's not a ConText issue. I used ConText too for a while, and switched to
TextPad. But the problem occurs also when i start apps with mirc's /run
command. This happens for nearly every include file, nearly every time, for
*every* instance of Eu i start, which is why i use a separate /bin/ and
/include/ for each and every "thread" or instance or application. Sometimes,
a file will be locked up for the duration of the run, making it impossible for
another application (including NotePad/TextPad) to use it.
Kat
