In Pharo, it's usual to run code inside Playground, and using Transcript to print the output. But I noticed it's also possible to run code inside Transcript, not only printing things there. For example, if I type:
Transcript clear.
Inside the Transcript window, and run it by Ctrl+D, the window will be cleared. So my question is, when does make sense to run code inside the Transcript window instead of Playground? Is there a use case?
To answer your question, we need to clear some things out:
You can run any code (almost) anywhere in the image. So if you open a method for example, type somewhere there Transcript clear, select it and hit Ctrl+D the transcript window will be cleared.
Transcript is just a "singleton" linked to a window that makes it easy to output some text and see it somewhere. It's not hard to construct a similar functionality on your own, or you can even output to a file for example. Transcript is there just for convenience during a troubleshooting activity. I would still recommend to use the debugger in a first place, but there may be situations where a debugger won't cut it.
Playground is a tool designed to "play" with your code. It's paired with an inspector, so whenever you run some code, you can inspect the resulting object in a user-friendly way. There are also some other features, like browsing variable bindings or storing code snippets, or browsing the playground code history. As I mentioned before you can run any code anywhere, but Playground is optimized for trying out stuff.
Some differences between Transcript and Playground
You can refer to the Transcript from anywhere to print on it. You cannot do the same with Playgrounds.
Since the Transcript is global, your script is exposed to getting dirty or cleared. In fact, there are many methods that print warning messages and the like on the Transcript. You can find them by searching its References.
Temporaries are automatically created in Playgrounds. You have to explicitly declare them in your Transcript scripts.
In some dialects of Smalltalk (not in Pharo), closing the Transcript will close the system. Playgrounds (a.k.a. Workspaces) can be freely open and closed in all dialects.
There is a Find command in the Transcript (guess why.)
The Transcript is a WriteStream: it responds to #nextPutAll:, #flush, etc. You can use it to test code intended to dump contents on any stream-like object (e.g., files).
And important consequence of 3 above is that you can store the result(s) of your evaluation in Playground temporaries. These will remain available until you close the Playground. In the Transcript, instead, the value of any temporary will only last while your code is being evaluated so you will have no chance but to print your result for it to remain visible, which is much more limited than the Playground behavior, where you can come back later and inspect or keep using your result objects for further experimentation.
In my opinion, it is not a good idea to use the Playground for non-trivial scripts. It is much better to create a class and put some methods in it. To try your code use Unit Tests (again classes and methods). That way the code would be organized, searchable, classifiable, etc., and your "scripts" would become so short that you won't need any Playground.
The Transcript should have two areas. One for output and another for input. The output area would display the messages, annotations and results produced by Transcript show: <whatever> and Transcript nextPutAll: <string>. The input area should be equivalent to a simplified Playground, so to save you the task of opening a Playground for evaluating short code snippets that you will soon discard.
Related
Intellij has a really neat feature, that lets me seamlessly extract a block of code into its own method. I can then give this method a nice, descriptive name and move on with life.
However, intellij also tries to find other blocks of code that are similar, and then tries to perusade me that I should also refactor them too, to use this new method its made. And then, when I hit the oddly-named "cancel" button (which implies the whole operation is cancelled, but it's not, it just stops asking about any remaining blocks), it leaves me looking at whatever the block of code it last asked me about.
I really don't like this feature. Here's why: If I'm say comparing two ints - the naming of the code block will depend on the context of those two ints, but intellij will find any comparison between two ints anywhere in that file, and then insist that this is also a candidate for extraction.
Most times it is not, and to make it worse, when I ask intellij to stop it, in a fit of pique, leaves me wherever the last comparison was, so now I have to navigate back to where I was working.
How do I tell intellij just to extract exactly what I selected, and do nothing else?
Please follow/vote/comment the issue created for this usability problem at YouTrack:
https://youtrack.jetbrains.com/issue/IDEA-233201
I often work on very small pieces of code, on the order of max 100 lines, especially in scenarios when I learn something new and just play with the code, or when I debug.
Because I frequently change code and want to see how that changes the contents of my variables and output, it is tedious to either
1) hit the debug button, wait for the debugger to start (in my case I use PyCharm as an IDE) and then inspect the output
or
2) insert some prints for the variables that I want to observe and compile the code (slightly faster than starting the debugger).
To eliminate this time consuming workflow, where I constantly hit the compile or debug button every few seconds, is there an IDE where I can set a watch to a few variables and then each time I change in my source code a single character (or, alternatively, every half a second) the IDE automatically compiles everything and I will see then new values of my variables?
(Of course while I intermediatelychange the code the compilation will give errors, but that is ok. This feature would be a big time saver. Maybe PyCharm has it already implemented? If not, ideally I would hope for a language agnostic IDE, similar to PyCharm, where variants for Java etc. also exist. If not, since I code in Python, a Python IDE would also be great.)
This might not be exactly what you are looking for but PyCharm (and IntelliJ and probably others) can run tests automatically when code changes.
In the PyCharm Run toolbar look for "Toggle auto-test" button.
For example in PyCharm you can create test cases that just runs the code you're interested in and prints the variables you need.
Then create a run configuration that runs only those tests and set it to run automatically.
For more details see PyCharm documentation on rerunning tests.
The Scala plugin for IntelliJ has exactly what you need in the form of "worksheets," where every expression is automatically recompiled when its value or the value of anything it references is changed.
Since (based on your usage of PyCharm), I assume you're using Python primarily, I think Jupyter notebook is your best bet. Jupyter is language agnostic but began as specific to python (it was called IPython notebook for this reason).
I have not tried it, but this guide purports to show to get Jupyter to work with PyCharm
EDIT: Here is another possibility called vim worksheet; I haven't tried it, but it purports to do the same thing as Scala worksheets, but in vim, and for a number of languages, including Python.
The python Spyder IDE (comes with Anaconda) has this feature. When you hit run, you can see all of the variables at the top right of the screen and you can click on them to see their values (this is very helpful with Numpy Arrays too!).
If your interest is in the actual workflow improvement:
I used to program like you, looking at what my variables changed to, and design or debug my code based on such modifications, however is way to inefficient and costly to set what variables to watch over and over again and besides when if it bugs, you have to go all over again for the debugging process.
I changed my design process to better my workflow and adopted Test Driven Development (TDD), with it you can look at tools for you specific implementations or IDEs but the principles and workflow stay with you, with it you stop looking on how the variables changed and instead focus on what the functions should do, meaning faster iteration (with real time tools for testing), easier debugging and far more better, safe refactoring.
My favorite tool for it is Cucumber, and agnostic tool (for IDE or programming language) which help you test your code scenarios and at the same time documenting your features.
Hope it helps, i know its a very opinionated answer but it's an honest advices for improvement in ones workflow.
You should try Thonny. It is developed by Institute of Computer Science of University of Tartu.
The 4 features which might be of help to you are below (verbatim from the website):
No-hassle variables.
Once you're done with hello-worlds, select View → Variables and see how your programs and shell commands affect Python variables.
Simple debugger.
Just press Ctrl+F5 instead of F5 and you can run your programs step-by-step, no breakpoints needed. Press F6 for a big step and F7 for a small step. Steps follow program structure, not just code lines.
Stepping through statements
Step through expression evaluation. If you use small steps, then you can even see how Python evaluates your expressions. You can think of this light-blue box as a piece of paper where Python replaces subexpressions with their values, piece-by-piece.
Visualization of expression evaluation
Faithful representation of function calls.
Stepping into a function call opens a new window with separate local variables table and code pointer. Good understanding of how function calls work is especially important for understanding recursion.
I was wondering if there were a way to compute the size of a reg in Verilog. I researched it quite a bit, and found $size(a), but it's only in SystemVerilog, and it won't work in my verilog program.
Does anyone know an alternative for this??
I also wanted to ask as a side note; I'm having some trouble with my test bench in the sense that when I update a value in the file, that change is not taken in consideration when I simulate. I've been told I might have been using an old test bench but the one I am continuously simulating is the only one available in this project.
EDIT:
To give you an idea of what's the problem: in my code there is a "start" signal and when it is set to 1, the operation starts. Otherwise, it stays idle. I began writing the test bench with start=0, tested it and simulated it, then edited the test bench by setting start to 1. But when I simulate it, the start signal remains 0 in the waveform. I tried to check whether I was using another test bench, but it is the only test bench I am using in this project.
Given that I was on a deadline, I worked on the code so that it would adapt to the "frozen" test bench. I am getting now all the results I want, but I wanted to test some other features of my code, so I created a new project and copy pasted the code in new files (including the same test bench). But when I ran a simulation, the waveform displayed wrong results (even though I was using the exact same code in all modules and test bench). Any idea why?
Any help would be appreciated :)
There is a standardised way to do this, but it requires you to use the VPI, which I don't think you get on Modelsim's student edition. In short, you have to write C code, and dynamically link it to the simulator. In the C code, you can get object properties using routines such as vpi_get. Useful properites might be vpiSize, which is what you want, vpiLeftRange, vpiRightRange, and so on.
Having said all that, Verilog is essentially a static language, and objects have to be declared with a static width using constant expressions. Having a run-time method to determine an object's size is therefore of pretty limited value (since you should already know it), and may not solve whatever problem you actually have. Your question would make more sense for VHDL (and SystemVerilog?), which are much more dynamic.
Note on Icarus: the developers have pushed lots of SystemVerilog stuff back into the main language. If you take advantge of this you may find that your code is not portable.
Second part of your question: you need to be specific on what your problem actually is.
I've been using go for a bigger project and love it, and for my testing i've been using the
func ExampleXxx {
... code ...
//Output:
//...expected output ...
}
method for testing. When it fails it will say
got:
... bunch of lines showing the output of test ...
want:
... the comment you put in to show what you expected ...
is there any way to make it show just the difference? I can take the two and copy to separate files and run a diff etc, but I'd much rather just have it show the parts that were wrong as some of my tests have longer output.
Thanks in advance
EDIT:
I'm using http://golang.org/pkg/testing/#hdr-Examples and want the output to show a diff not the current output. I know I can do the diff manually.
No, you cannot do this. This is not the intended use of Examples.
Examples are a nice way to show how some function will behave: Examples exists to document. The main reason for validating the example output is to make sure the Examples are valid/correct, not that your code is okay. For the later you have Test functions
Most often the output of an Example displays input and output (or just output) of one invocation of a certain function/method per line; sometimes Examples use the different lines to show parts of a complex result, e.g. one line per element of the returned slice.
I think your use of Examples to "verify the flow of my program" contradicts the intention of Examples. I would use Test functions and use any of the available diff tools to generate a got, want, diff output myself if I'd like to test e.g. a text processor on large bunches of input.
If I understand your question correctly, it sounds like GoConvey would do the trick... It's a TDD tool that runs in the browser, and it will show you colored diffs for most failures:
You can use it with your existing tests; if you don't want to convert to the GoConvey DSL, that's okay. You don't have to be using a TDD workflow per-se in order for it to work, but if you can run go test, this tool should be able to pick it up. (I've never used the Example functions for testing... I'm not sure what you mean by that, honestly.)
(There's a new web UI in the works that will still show the diff. See below.)
These are contrived examples, but obviously the diff is more useful with longer output.
Is that kind of what you're looking for?
From the style guide: https://code.google.com/p/go-wiki/wiki/Style#Useful_Test_Failures
if got != tt.want {
t.Errorf("Foo(%q) = %d; want %d", tt.in, got, tt.want) // or Fatalf, if test can't test anything more past this point
}
This will put out only errors of course. There is nothing built into go that lets you show the diff. I think just piping this to whatever diff tool you are using against your last output would still be best.
Go is great, but no reason to re-invent tools that already do fantastic jobs that already exists at the terminal.
I've read the documentation and understand that this is to be expected:
Scripts are injected into the top-level page and any children with HTML sources, such as iframes. Do not assume that there is only one instance of your script per browser tab.
I'm wondering, though:
Other than iframes, what other elements have "HTML sources" (images? objects?)? The term "HTML sources" is uncomfortably vague to my ears.
Is there any way to detect which element is executing the script?
I've filtered out iframes by determining that window === window.top, as recommended, but other elements are still executing the script and it's executing a lot more than I'd like.
Thanks.
It's really my own fault that I'm answering my own question because I didn't really provide enough information in my question. In my defense, I didn't know at the time that I was providing too little information.
Anyway, while traveling down the road to a solution for this, I asked a question on Apple's dev forum and included the following bit of key info:
Everything in the script occurs on the beforeload event of the document (or was supposed to).
What I learned was that the beforeload event only fires for subresources within the document. Not for the document (or window) itself. I removed the event handler and made sure that the script was applied as a start script (it was). I'd already applied the test for the window as top window so I was covered. Now my injection script only fires once.
Other HTML sources may be frames or object tags (with HTML contents). I don't think it can be anything else. However, to the extent of my knowledge, they should also be filtered off with window === window.top. Try console.loging the document.location variable to see which URL runs your injected script, and maybe you can find what loads them.