Recent

Author Topic: idea for an additional error message  (Read 1309 times)

Nicole

  • Hero Member
  • *****
  • Posts: 970
idea for an additional error message
« on: November 01, 2022, 07:16:22 am »
do this:

- use a shared directory by a Lazarus Win 7 VM and a Win 10 host for your projects
- start your software by Win 10
- open the project within the VM
- does not work (surprise!)

Not every time you may be aware of what you have done wrong.
So my idea: Drop an error message alike
- exe cannot be created
- program already started by another location or so

I use Lazarus 2.2.2, should be the last but one version

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: idea for an additional error message
« Reply #1 on: November 01, 2022, 08:17:24 am »
There's already a Tools -> Options -> IDE Startup -> Lazarus instances setting, but this presumably works by some form of interprocess communication which is (effectively) in-memory (i.e. including local sockets etc.). The problem would be extending this in a reliable way to operate over what are in effect separate systems.

I'm not convinced that having two IDE instances access the same .lpi is an error in all cases. Even if it were treated as such, the question then arises of whether having two IDE instances accessing different projects which happen to share one or more units is an error. The question also arises of how to avoid false positives, allowing that particularly when at least one VM is involved there is no reliably-shared process ID, user ID and so on.

If something did have to be done perhaps a list of possibly-live sessions in the .lps would work, with the user being obliged to sort things out before the IDE would proceed. However I think the support burden would be enormous, with a constant stream of users complaining about a message about such-and-such process ID accessing the project and absolutely no understanding of the technology involved.

I think I'd argue that this is a VM configuration issue: for a VM to allow multiple OS instances to access the same directory is inherently unsafe, and the user/administrator should be aware if he has set up network shares etc. that allow this.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Bogen85

  • Hero Member
  • *****
  • Posts: 595
Re: idea for an additional error message
« Reply #2 on: November 01, 2022, 08:38:10 am »
I think I'd argue that this is a VM configuration issue: for a VM to allow multiple OS instances to access the same directory is inherently unsafe, and the user/administrator should be aware if he has set up network shares etc. that allow this.

I don't think that is necessarily a problem, as VM shares are typically like network shares, and multiple OSes accessing the same directory on a network share at a time is the norm.

The issue here, as you already noted MarkMLI, is Lazarus not understanding multiple instances across machine boundaries, which would not be practical for it to have to do.

Also, this is a Windows issue, and on most *nix likely would not manifest like this.

True, on Windows the executable could not be overwritten, and that should likely have a better error message.

But even though most *nix would act differently in this case, allowing the executable to be overwritten, there would likely be other negative side affects trying to work on the same project from two different instances, where those instances have no knowledge of each other.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: idea for an additional error message
« Reply #3 on: November 01, 2022, 09:19:46 am »
I don't think that is necessarily a problem, as VM shares are typically like network shares, and multiple OSes accessing the same directory on a network share at a time is the norm.

But you'd not usually expect somebody to be working on the same files on a (Windows or other) server and on client systems connected to it.

Not an easy one to sort out, particularly in a cross-platform way.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Nicole

  • Hero Member
  • *****
  • Posts: 970
Re: idea for an additional error message
« Reply #4 on: November 01, 2022, 11:07:41 am »
@Mark
misunderstanding:

Win 10 does not use Lazarus or the IDE, but the software, which is written by it.
The Win 7 VM is the "backstage", which generates and repairs the software, which is in test by everyday use by a direct call under Win 10.

So if you repair a running car, - this is no good idea.
Nevertheless, it sometimes happens by mistake.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: idea for an additional error message
« Reply #5 on: November 01, 2022, 11:25:44 am »
So my idea: Drop an error message alike
- exe cannot be created
- program already started by another location or so

I haven't tested with a VM, but if I start the project1.exe (outside the IDE, which is what the VM would do) and then make changes and try to compile, I get:
Code: Text  [Select][+][-]
  1. project1.lpr(24,1) Error: Can't create object file: C:\Users\martin\AppData\Local\Temp\project1.exe (error code: 5)
  2. project1.lpr(24,1) Error: Can't create executable C:\Users\martin\AppData\Local\Temp\project1.exe

So there is an error.

I don't know what the VM will show, that depends on how the VM implements the shared file system.



If files are edited in both IDE then the other IDE should ask to reload them.
That should at least work outside the VM.

The IDE inside the VM may not... Because, each IDE checks when the IDE is getting Focus.
But if the entire VM was unfocused, then the IDE may not know, and the IDE in the VM may have always had (virtual) focus.





Not sure what else to do...

Maybe create a lockfile for the project. So it can be detected when it is open already.

In any case, this kind of thing is what I would advice to put into a package, and then any 3rd party could implement it.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: idea for an additional error message
« Reply #6 on: November 01, 2022, 12:13:08 pm »
I haven't tested with a VM, but if I start the project1.exe (outside the IDE, which is what the VM would do) and then make changes and try to compile, I get:
Code: Text  [Select][+][-]
  1. project1.lpr(24,1) Error: Can't create object file: C:\Users\martin\AppData\Local\Temp\project1.exe (error code: 5)
  2. project1.lpr(24,1) Error: Can't create executable C:\Users\martin\AppData\Local\Temp\project1.exe

So there is an error.

...and that's why when developing for Windows it is often necessary to rename a running executable before a replacement can be copied into the same folder... at least when working on the same machine.

If that's not working like that, then I'd expect it to be down to whatever disc/file sharing mechanism the VM etc. is using, i.e. it's trying to "enrich the user experience" by disabling all locking. There's also the possibility that a recent linker version has reduced its locking rigour...

The compiled app could, of course, regularly check its own creation time :-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Bogen85

  • Hero Member
  • *****
  • Posts: 595
Re: idea for an additional error message
« Reply #7 on: November 01, 2022, 12:57:57 pm »
I don't think that is necessarily a problem, as VM shares are typically like network shares, and multiple OSes accessing the same directory on a network share at a time is the norm.

But you'd not usually expect somebody to be working on the same files on a (Windows or other) server and on client systems connected to it.

Not an easy one to sort out, particularly in a cross-platform way.

MarkMLl

Ok, what I mean was, multiple OSes accessing the same folder is not a problem in and of itself.

It definitely presents challenges for this situation.

From a file share perspective this can be viewed as 2 computers using a common file share.

The fact that one is a guest VM and the other is it's hypervisor host might not be relevant.




« Last Edit: November 01, 2022, 04:32:36 pm by Bogen85 »

 

TinyPortal © 2005-2018