I was exploring JupyterLab and one thing that still confuses me is code consoles. At this point it is unclear how one might benefit from using them since they provide nearly the same functionality as notebooks.
According to the documentation the difference between code console and Jupyter notebook is that
The cells of a code console show the order in which code was executed in the kernel, as opposed to the explicit ordering of cells in a notebook document. Code consoles also display rich output, just like notebook cells.
I presume that the idea behind the code console is that one might test and refine the code before running it in the notebook. However one might still do all the same within notebooks, for instance by creating another cells for testing purposes and removing them later if needed which makes code consoles redundant.
Am I failing to see the usefulness of the code consoles when writing a code?
Related
Bear with me, I am an avid Matlab user - debugging here is very convenient: it is flexible, easy to use and fast. Coming from this, I struggle with using the basic debugging provided by Visual Studio Code (when using Python).
My basic code generation routine involves using breakpoints for the generation of new code. That is, I set a breakpoint at where I want to insert new code, then run my code up to the breakpoint and upon stopping at the breakpoint, I extend the code with the desired functionality, using the debug console to move through functions, checking the respective workspace and finally and importantly to check if the logics of my new code are right. This has always worked very well in Matlab, but does not in VS Code.
I use VS Code 1.73.1 (newest as of todays writing) and Python 3. I imagine my problem is more of a VS Code issue than related to Python, i.e. language agnostic.
Questions:
Doing what is described above in VS Code, I randomly receive a debugger notice "Timeout waiting for debuggee to spawn". Sometimes, this disappears when running the debugging button, sometimes it does not. It often appears repeatedly, and sometimes resolves after hitting the "Debug Python Code for the n-th time. Then I can debug my code for a few times without that notice until it appears again. It appears out of the blue and is highly annoying. What can I do about it? Should I need to configure anything in a launch.json, I'd need a complete and self-containing description of what (and ideally why) to do as I am really new to this way of engineering software.
The debugger is incredibly slow to reach the first debugging points. In Matlab, I reach my debugging points "immediately" after hitting "run/debug code" - in VS Code, this may take up to a minute. What can be done about this? It makes my code generation routine described above infeasible, as I frequently repeat that routine while iterating the code's design. It also leads me to the next question.
What are your thoughts on the above approach, given the VS Code and Python context? How to do better without configuring break point options? I just want a simple standard debugging configuration setting breakpoints and then clicking "Debug Python File".
What I did:
Restart VS Code, switch between "Run Python File" and "Debug Python File", randomly configure a launch.json file based on what I read (but likely did not fully understand) on internet fora.
I want to write an extension based application, which means an application contains one or multiple program with a primary program (as core for example) and some extensions that aren't necessary but could be added to core to extend features of application. the extension host of vscode is a very good example and interesting. I tried to understand how it works several times and also searched for this approach but nothing found. I want to know how to write a program that can dynamically add and remove an small pieces of codes as extension. I don't know how this piece of codes should be, I don't know how they must be loaded/unloaded to/from program, I don't know if each of them should be a separate programs or not and such this "I don't know"s in this context.
I welcome to any idea and guides in this problem.
I usually code in cpp/Rust.
I'm someone who solves problems by looking, not asking. So this is new to me. This has been an issue for years, and it crops up with different computers, networks, versions and completely different code. There is a lot here, so, thank you in advance if you are willing to read the whole thing.
Generally speaking, I write MS Access programs that will open Excel and then create multiple worksheets inside of a workbook using data from Access tables and/or Excel sheets. The process can take a couple of minutes to run and occasionally, it will get an error. I could tell you the error message, but it doesn't matter because it will be different depending where the error occurs. When it occurs I simply click debug and click continue and it... continues. If it errors out again (many loops later), it will happen in the exact same spot.
So, what I start with is to make minor changes to the code. In the current program I'm working on, the error happens when I write to a cell and the value is a value directly from a table. I created a variable, copied the value to the variable and then wrote to the cell. The error moved to a completely different part of the program and it became a "paste" error. Generally what fixes it is to put a wait function at the spot where the error occurs. One second is usually good enough. Sometimes it takes a couple of these, but that usually solves it. It only took one delay per loop this time, so it is working. I just hate causing delays in my program. So... Has anyone seen anything like this before, or is it just me. It feels like a timing issue between Access and Excel since the delays are usually helpful. Thanks in advance.
I dug up my last major Access project that interacted with Word (ca. 2016) where I struggled with similar issues. I see many, many Debug.Print statements (some commented, some still active), but unlike what I recalled earlier in my comments, I don't see any "wait" statements anymore! From what I now recall and after re-inspecting the code, most problems were resolved by
implementing robust error handling and best practices for always closing automation objects (and/or releasing the objects if I wanted the instances to persist)
subscribing to and utilizing appropriate automation object events to detect and handle interaction rather than trying to force everything into serialized work-then-wait code. To do this, I placed all automation code in well-structured classes that declared automation objects WithEvents (in VBA of course) and then defined relevant event handlers for actions I was effecting. I now recall finally being able to avoid weird errors and application hangs, etc.
You also may never get a good answer to a question like this, so despite that I am not an absolute expert on Office development, I have had my own experience with frustrating bugs like this and so I'll share my 2 cents. This may not be satisfying, but after experiencing similar behavior using office automation objects, my general understanding is that interaction between OS processes are not deterministic. Especially since VBA generally has no threading or parallelism concerns, it can be strange to deal with objects that behave in unpredictable ways. The time slices given to each process separately is at the mercy of the OS and it will vary greatly with multiple processors/cores, running processes, memory management, etc. Despite the purpose of the automation objects--to control instances of office apps--the API's are not designed well for inter-application processes.
Although it would be great if old automation code would produces more useful errors, perhaps nested exceptions (like in .Net and other modern environments), something that indicates delays and timeouts within callbacks between automation objects, instead you get hodgepodge of various context errors.
My hardware is old, but still ticking. I often get delays, even if only for a second, when switching between apps, etc. Instead of thinking of it as an error, I just perceive it as a slow machine, just wait and continue. It may be useful to consider these type of random errors as similar delays. If a wait call here or there resolves the issue, however annoying, that may just be the best solution... wait and continue.
Every now and then after debugging these types of issues I would actually discover the underlying problem and be able to fix it. At the least I would be able to avoid actual problems with the data, despite errors being raised, just like you describe. But even when I felt that I understood the problem, the answer was still often to do exactly as you have done and just add a short wait.
I do believe now this is a timing issue. After thinking things through, I realized that I could easily (well 3 hours later) separate the database info from the spreadsheet info and then move the updated code that is causing problems into an Excel Macro. I then called that macro from Access. Not only do the errors go away, but it runs about 4 times faster. It's not surprising, I just hadn't thought of that direction before.
Context:
Jupyter notebook has this nice ability to store variable values even when a block of code executed and exited. It is a more powerful version of "break point" in other IDEs. So far, I have noticed some benefits from this jupyter notebook ability:
You can run the lengthy part of your code only once and use its results over and over again without rerunning them.
you can inspect your current variables more flexibility, print them on console or into a file or into a table.
you can try tweaking variables as well, before feed it to the next code block. There can be draw back to this, after tweaking my variables, they are forever changed, so I have to include lines of boilerplate code in my subsequent notebook script after the lengthy script: lengthy_variable_new = lengthy_variable_original.copy()
# do things with lengthy_variable_new
Now, let's imagine a a new ability: "saveState" a script, in which you can save all variables created by the user and all hidden ones, everything that is currently on heap or stack. So you can continue coding after the saveState point but you can restore the saveState point anytime you want.
I understand that python language itself can only pickle things you want. It is handy for some cases but not all.
Question:
Is there a proper term describing my "saveState" concept?
Do we have it in pycharm or any other IDEs?
I personally believe there is either a better way, or what I want is very hard to implement so that is almost easier just to re-run the code compared to restoring everything back to memory.
I think your state may refer to a stack frame (more or less).
PyCharm and probably other IDEs have a similar tool. If you are debugging your code and reach a breakpoint you have the possibility to open an interactive ipython console in which you can inspect all current variables in the stack frame, though you cant alter them.
I personally prefer debugging in PyCharm and use Jupyter Notebooks more for interactive exploring data or some new piece of code. It is kind of hart to debug loops in Notebooks and some other things like iterators too.
I have a stack which was originally built in Hypercard then migrated to Metacard. Obviously, it has expanded greatly over that time. Some core features broke when I tried to migrate to Runrev which is why I've waited till now to finally do that. I'm keeping it as a stack rather than an exe so I can save changes to it. I've built a standalone player to launch it and that is working. I've included the revmessagebox.rev stack in the Standalone Stack settings. This does add it but, incorrectly. I can put messages to it from my stack but, it won't run commands and it's missing all it's icons. I'm also included the revimagelibrary.rev and revtools.rev stacks in the hopes of fixing this but, no dice. I was also hoping that including revimagelibrary.rev would get my old Metacard icons to display but, no dice. I appreciate any help I can get on this.
Rich
I don't think you can. The message box is part of the IDE and requires the development environment to run. When you build a standalone your scripts etc are compiled and an interpreter for commands is no longer present.
To replicate it in a standalone you could use a simple window with a field to accept text and would require you passing the text entered to a "Do" command. The other functions present with the message box (accessed via the icons you mentioned) are also development tools and don't make much sense in a standalone.
The message box is not only integrated into the IDE, the engine also has hooks that directly support it. I'm not sure those hooks are included with the engine that is built into a standalone, so even if you adapt the existing message box for your standalone it still may not work correctly.
The solution, as others have said, is to build your own stack that functions as a pseudo-message box. It is easy to display messages in your own stack, and pretty easy to execute simple commands using the "do" command. It is somewhat more difficult to execute complex or multi-line commands. But I agree with Dunbarx that I'd assess the need for such a thing if you are planning this standalone for distribution. It's a non-standard interface element.
What James said. But note that though the msg box is indeed integral to the IDE, it is still just a stack, and that stack can be replicated to whatever extent you need.
That said, the msg box is usually used as a development tool, to test short scripts (usually one-liners), to get or set property values quickly, as a simple calculator, that sort of stuff. If you need that sort of functionality, you should probably integrate it more comprehensively into the structure of your project.
Craig Newman