My program seems to be stuck in visible stepping mode. I click the footprints but they have no effect. The program runs at the slow stepping speed whether the footprints are illuminated or not. Clicking the footprints does not get me out of the slow mode. The program ran fine three weeks ago or so. How Can I get out of this quandary.
could you share your project?
ringE is shared.
Project seems to work fine for me (looks very nice BTW)
For others here is link
Did you know that non "warped" loops in run at 60 iterations per second.
Drawing with the "odd?" takes ~20 iterations, or 0.3 seconds.
You can use >"Turbo" mode or "warp" some parts of the code.
But then the screen is updated twice per second.
But how fast is it running. Is there a way to send you a video so you can compare it with how fast it used to run for me.
Well it seems to be doing a lot of stuff so I wasn't expecting it to whizz along
But your 1st post implied that your project was stuck in visible stepping mode which it isn't for me
I'll see if I can do a video of it running at my end
The top row was completed (i.e., the wave arrived at gate 11) after 40 s.
url to video that shows how fast it used to run. Reply will not allow an emedded link. how can I get the link to you?
youtu.be/fSAtEevx20s
This is how fast the program used to run.
youtu.be/fSAtEevx20s
Yep - it doesn't run at that speed for me
I just ran it in version 9 and it runs a lot quicker
So I suspect some recent change in Snap! has caused it to slow down
Yep version 9 is how fast it should be running. How do I figure out what the difference is?
My standard technique is to fork and download the Snap! repository and use git bisect until I find out what change leads to the issue
What is the current version of snap?
Is there a file of updates with issues and dates I know the date of change pretty close.
Are you familar with GitHub hosted software
Snap! is here
you can look at the previous commits
but unless you can guess correctly as to what commit at what dateTime is causing the slowdown, git bisecting is the strategy I recommend to actually finding out for definite what has caused the change affecting your project
Thank you. will pursue.
I'm seeing a bazillion generic "when" hat blocks in your project. I've recently changed how they get evaluated, now they can take longer and also run in parallel, which might slow down your project, because it has a large number of agents.
It's interesting how this project "suffers" from the recent change more than I expected it to. The new evaluation technique should be much more stable and doesn't impose any timeout threshold on generic "When" hat blocks, but, alas! there seem to be downsides...
Hi Jens
thanks for looking. I recently made public ringC and ringD. ringC has almost as many when hat blocks as ringD but ringC still runs at speed. ringD used to run at speed but does not now. The difference between the two is in gate1 odd3 gate5 even2 and in the additions of arbiter and insertwave to ringD. I first noticed the slow behavior 4,2,24. It ran at speed a week or two before that.
wait! is that February 4th or April 2nd of this year? tnx