From the original SynthMaker forum (2004–2014), with its members’ names and dates.
mwvdlee ·
While trying to convert my MissingLinks registry modules to use the new System Folders module, I found an issue with what appears to be a combination of Shell Execute and Text Load.
This happens in 1.1.7 public release.
To reproduce; try the following (borrowing a module from Developers' Toolkit):
Specify an existing file, click repeatedly on the trigger control and notice how the tick counters don't all increment at every click. The issue seems to be somewhere between Shell Exec and Text Load and I can't explain why. It almost seems like Shell Exec is no longer a blocking call.
* Update: Fixed in SM v2.0
sunsynth ·
Hmm...
maybe this:
- Made a small tweak to the Shell Execute component to prevent potential delays after execution
is the reason for that behaviour...
the cmd shell needs a little time to fulfill the request - i placed a 250 ms delay and it works fine here!
P.S: the "C:\Path.txt" could also be locked while the dir cmd is active...
mwvdlee ·
sunsynth wrote: Hmm...
maybe this:
- Made a small tweak to the Shell Execute component to prevent potential delays after execution
is the reason for that behaviour...
the cmd shell needs a little time to fulfill the request - i placed a 250 ms delay and it works fine here!
P.S: the "C:\Path.txt" could also be locked while the dir cmd is active...
If Shell Execute ALWAYS needs EXACTLY a 250ms delay, it should be built into Shell Execute.
If the delay is variable, we need to have a way of letting S|M tell us when it's finished.
Having to insert a 250ms delay is unacceptable in so many ways, that I lost count just thinking of them.
Either way, Shell Execute in v1.1.7 breaks backwards compatibility.
It breaks the Developers' Toolkit, which many people use.
And so does it probably break pretty much everything else that uses Shell Execute.
MegaHurtz ·
everything 😉
sunsynth ·
Wow... only a workaround ... better shut my mouth 😉
I'm convinced - it's a bug 😈
mwvdlee ·
sunsynth wrote: Wow... only a workaround ... better shut my mouth 😉
I'm convinced - it's a bug 😈
The 250ms delay hack is not a workaround; it only works in one specific case, on your specific computer when it's not busy doing other things besides SynthMaker and it always adds 250ms overhead doing nothing.
Even if your workaround would work, you'd still have to change every schematic that uses Shell Execute commands, including in modules you borrowed from third party kits such as the Developers' Toolkit.
I don't know if it's a bug, but it IS a problem.
I just wish the release notes were a bit clearer on exactly how the functionality of Shell Execute was changed. From what I see, it seems like it was blocking (synchronous) and is non-blocking (asynchronous) now, which is a significant change in functionality.
mwvdlee ·
I tested this with a test of mine that uses a the dir command to scan directories for browsing.
It appears the calls are indeed non-blocking now. The Shell Execute seems to return immediately.
The longest directories won't load unless I turn the delay hack upto a couple of seconds; clearly unacceptable for most situations and obviously still nog long enough for slow directories such as network disks.
How do I know when the command is finished?
Why not just include a boolean in the Shell Execute for "Run in background" or something like that?
(Actually you wouldn't really need that, because you could just trigger it in a thread and have exactly the same behaviour, but that's besides the point.)
sunsynth ·
I had the same good idea with the boolean!
btw: the following modules like the loader have to test that the file exists, is readable and unlocked(=not in use and u have the rights to read them):
DigitalWhiteByte ·
The trig out now seems to be disconnected from the shell, and its trig runs immediately even if not backed up.
I remember this not happened before.
Also in the example of Sunsynth,
I noticed that the new primitive "SysFolders" does not update the string connected to it,
it seems that send no trig when initialized.
aliasant ·
DigitalWhiteByte wrote: The trig out now seems to be disconnected from the shell, and its trig runs immediately even if not backed up.
I remember this not happened before.
Also in the example of Sunsynth,
I noticed that the new primitive "SysFolders" does not update the string connected to it,
it seems that send no trig when initialized.
Yes. Seems to be a bug in it.
Shouldnt I see my own system folders from that primitive when I open Sunsynths example?
If I trigger the string I see the change and all is well.
sunsynth ·
Yup - good find dudes
To be honest, it's the 1st time i use it! So we have to place an afterload?!
aliasant ·
sunsynth wrote: Yup - good find dudes
To be honest, it's the 1st time i use it! So we have to place an afterload?!
For now that would work but its a bad hack isnt it?
sunsynth ·
Yeah - so Marco please don't forget 2 mention it in a new bug thread!
DigitalWhiteByte ·
sunsynth wrote: Yeah - so Marco please don't forget 2 mention it in a new bug thread!
bugtracker created 😉
McBarGig ·
Just a question, well maybe more of a statement...When did Shell execute ever run Syncronously? It really didn't seem like it did before...
mwvdlee ·
McBarGig wrote: Just a question, well maybe more of a statement...When did Shell execute ever run Syncronously? It really didn't seem like it did before...
It did in version 1.1.6 and prior. Don't know how far back in history, since I've only been using S|M for half a year.
McBarGig ·
Interesting, now all we need is a trigger that tells us when the running shelled process has finished...
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker