Over past days the option "Run Functional Simulation" (in waveform part) in Altera Quartus 13 here (i use in Ubuntu 11.10) was working fine, but since yesterday It, all of sudden, is not working. When I click in the option, it's opened a tiny grey retangle, and so it disappears. In other words, simulation doesn't work. Does anyone knows how to solve this problem?
Best Regards,
Inácio.
I recommend to start quartus in a console do exactly what you have done before and paste at least everything what is outputs in the console. Otherwise nobody can really help you.
My crystal ball tells me that you could delete or update a library which the simulator needs, or the PATH variable does not include the path of the executable of the simulator.
Related
I'm a high school student in a class that is using Python 2 on Enthought Canopy Windows Edition. I often get stuck in coding loops, but the only way I can get out is by closing out all forms of open Enthought. Is there any more reliable way to do it? I've been using sys.exit(0), but it doesn't work correctly, and is leaving my coding in a jam. I can't even test it without it getting me stuck. Anyone know how to fix this issue?
If your code is already running, then you can't reliably type a command to stop it, because the prompt won't necessarily be live then.
Often you can use the Run menu's "Interrupt kernel" command, and you should usually be able to use "Restart kernel", though this doesn't work all the time.
I try to get the machine learning project of Unity running. The project can be found here: https://github.com/Unity-Technologies/ml-agents
Following all the necessary steps to set everything up, everything works fine until I try to use a pre-trained model in an internal brain, e.g in the 3D-Ball example. On pressing play in the editor, it says to have stopped working and the editor crashes. Same goes for a successfully compiled executable.
Since I can't find any crash logs, I absolutely don't know what's the cause to this. Anybody had the same issue and solved it, or any ideas on this?
I'll just add the steps I made to set my project up, in case somebody wants to reproduce or check for mistakes I made:
Download zipped project from github
Open project with Unity 2018.1.1f1
Add ENABLE_TENSORFLOW to predefined symbols
Download and install TensorflowSharp Plugin
In the 3DBall Scene select the brain and switch BrainType to Internal
Run in editor or compile and run, results both times in a crash
EDIT
What's making me wonder is that I got it working just fine training an external brain in python using a compiled executable. So my thoughts were it should be much more easy to just forward pass a trained net, if it's working doing forward pass and back propagation. But it says though that external brain still is experimental, so not sure if that just will not work until some future patches.
EDIT 2
So I tried using an internal brain in an older version of the githubs project, which then worked quite fine. Also I used an older version of the TensforflowSharp Plugin. I'll try to figure out, which version still works and gonna post my results here ;)
To conclude, the problem was actually the recent version of the TensorflowSharp Plugin. Using an older version, which I found somewhere worked fine. I don't have the link to that version anymore, but in case someone experiences the exact same problem, I could search for it or upload it somewhere.
Bounty Update
I am leaving the question essentially the same, but I just want to point out at the beginning here that I'm most interested in help trying to get the socket between flash (Adobe Animate) and the native debugger working again, as I believe that is the issue I'm having. Or is it a socket between flash and Windows?
Original Question
I've apparently turned something off? Even when I write really bad code (like trying to call a function that isn't there or divide an integer into a fraction), the flash player boots, shows a background color and stops there. No messages in the output window or compiler errors window. If I fix my code, it all runs fine, but for about 30 minutes (ever since I started trying to work with bitmaps for a sprite sheet) I get no runtime errors no matter what kind of mistake I type in my code. Anyone know how to turn it back on?
I've checked my actionscript settings and I have both warning mode and strict mode checked on.
Could it be a socket issue? I admit I have little to no experience working with sockets and only a surface understanding of what that even means. I've added the socket tag. If someone can see that this is clearly nothing to do with sockets, by all means, I'll remove the tag.
UPDATE: 6/22/16
I just reinstalled Adobe Animate CC 2015.2 and no change. I'll try compiling it in flash builder when I get a chance to help pigeon hole the problem. (Edit 6/24: flash builder worked! But my trial version expired the next day so is no longer a viable option).
And I just tried something in the command prompt in Windows 10 as an administrator:
netsh winsock reset catalog
netsh int ip reset reset.log hit
which I found another user on flashdevelop.org used to fix a similar issue, but no change.
And I just tried debugging in Flash Builder. It worked fine (debugger caught bugs) but my trial version expired the next day.
update 6/24
I've tried launching debugger for AIR from within the Adobe Animate CC IDE and it works fine if there are no bugs; it fails to do anything visible (no Iphone emulator, no swf window) if I put a typo or error in the code.
I also just deleted winsock and winsock2, rebooted Windows, then reinstalled winsock and winsock2. No change.
update 6/25
Just tried a system restore in Windows to set all my files and settings and drivers etc. to the way it was a week and a half ago... Also completely uninstalled all Adobe products and reinstalled. No change. I can only imagine that wiping my hard drive and reinstalling Windows would do the trick, but come on, it hasn't come to that has it?
As VC.One suggested, I checked the compile error window (cannot believe I didn't check before! Maybe when I checked before there were no compile errors... Only runtime errors?) and the errors are showing up there. Does this mean that it's catching compile errors but just not runtime errors?
When you force/test a runtime error... make sure you check
Compiler Errors (ALT+F2) and also Output (F2). By Output I mean the window that shows traces (and runtime issues). One of those two should have some feedback for you.
A possible solution is to save a new Workspace. So with those windows for Compiler Errors and Output both open (or tabbed, I tab them next to my Timeline) go to Window (in top options like File/Edit/Debug etc) and choose Workspace, then into that you choose New Workspace. Give it a name in the pop-up and okay everything.
Flash should always load that current workspace (next time, go to Workspace option again, check that your specified workspace [by name] has a tick next to it...).
Possible pitfalls:
1 - Use the debug player
2 - Make sure there isn't somewhere a try/catch enclosing the portion of code that triggers the event that may lead to an error
3 - Socket issue: may be exported in debug mode but swf cannot connect to debugger (it waits in a blank state for 60 seconds I guess)
4 - Does it compile ok? If there are compilation errors you may get an SWF anyway but then it will not start
...
I'm using the "SPIDER" IDE for SICSTUS Prolog development, as instructed by the SICSTUS Manual and the documentation on the SPIDER IDE itself. When debugging, under the 'SICSTUS Debugging' perspective, the variables do not show on the Variables window, as can be seen in the top right in the image shown here (it's the first thing in the Spider page)
I set up everything according to this guide and this is, as far as I can tell, the only thing not working. Are there any additional steps to get the variable bindings while debugging?
Thanks in advance,
edit: I've recently reinstalled everything in the same system after formatting a drive, and it now works perfectly. I have no idea what, but I assume I did something wrong the first time.
Variable bindings should work by default. However, some variables may be omitted depending on compiler optimizations and other factors. Try it with the example program shown in the SPIDER image.
I am having some trouble uploading code to my Seeeduino ADK (essentially a Arduino Mega 2560) using Eclipse. Basically, this thread explains my problem. Sometimes I get a series of timeouts using the Arduino IDE upload, which is usually fixed by removing and re-inserting the USB. Unfortunately enough, this does not help fix the problem in Eclipse.
I have been trying to do the upload using AVRdude via the command line (I even tried the "hacky" solution in the last comment of the above thread), but to no avail. This is the line I am using for this:
"%AVR_DUDE%" -pm2560 -cstk500v2 -P\\.\%COMM_PORT% -b115200 -F -V -D - Uflash:w:"%HEX_FILE%":a -C"%AVR_DUDE_CONF%"
Which gives me:
avrdude.exe: stk500v2_ReceiveMessage(): timeout
I know the above batch variables are OK, because AVRdude runs correctly (but then it times out). If anyone has any ideas or tips that could help me with my uploading I would greatly appreciate it. Thanks beforehand.
EDIT: As it turns out, the reason for this may be that the Arduino IDE sends a reset to the board before uploading, something which the Eclipse AVR plugin does not do. I will test this and write a uploading perl script, but I am fairly certain this is the problem.
Your suspicion is correct. The Arduino IDE uses a patched version of AVRDude to pulse the DTR line and reset the board before each upload. For some reason, some people have had difficulty getting the right command line parameters to replicate this on the Mega2560. I've had the same problem myself - ATMega328's work with no problem, but the 2560 needs to be reset manually.
There's some further explanation and tips for possibly getting it working here (check the comments too): http://false.ekta.is/2011/05/avrdude-5-10-arduino-mega-2560-command-line-uploading/
Check out the detail here... http://false.ekta.is/2011/05/avrdude-5-10-arduino-mega-2560-command-line-uploading/
If using avrdude > version 5.1 change the programmer to -cwiring
This will reset the chip first