Hi Below is some simple code that displays the benchmark results form a Julia REPL. In VSCode I have tried
launching the Julia REPL from the Command Pallet and Running the file without Debugging
Execute the active File in Repl from the drop down menu top right
In both cases the println statements are displayed but not the benchmark results. Is this to be expected or have I messed up?
using DifferentialEquations, BenchmarkTools
A = rand(1000,1000); B = rand(1000,1000); C = rand(1000,1000)
println("TX 1 and 2")
test(A,B,C) = A + B + C
#benchmark test(A,B,C)
println("T 1 End")
t(A,B,C) = A .+ B .+ C
#benchmark t(A,B,C)
println("TX 2 End")
readline()
println("After read")
I found a workaround : remove or comment out the #benchmark from the file and
run them directly in the REPL.
This should depend on which setting you have for result type (Julia > Execution: Result Type in the Settings GUI or julia.execution.resultType in settings.json).
With "inline" result type I get:
Hovering over the BenchmarkTools.Trial box, I get:
Note the println line just shows a tick as it has been executed but didn't return anything, instead it printed to the REPL, the terminal at the bottom now looks like this:
Related
I enabled the auto-save-visited-mode in global scope and write such a script
~/D/O/ORG/pySrc [undefined] λ cat sicp.py
#!/usr/bin/env python
def remainder(x, y):
return x % y
def gcd(a, b):
if b == 0:
retunr a
else:
return gcd(b, remainder(a, b))
print(gcd(30, 15))
Run it but find typo-error of retunr, and corrected it immediately.
The auto-save-visited-interval set as default 5, so I count to 10 and run it again
get error
File "sicp.py", line 9
retunr a
^
SyntaxError: invalid syntax
the file was not saved automatically.
Consult with auto save file, which state that files will be saved in place.
What's the problem with my usage?
doom-emacs issue
To enable a minor mode you must call its function: (auto-save-visited-mode +1). Setting the auto-save-visited-mode variable is not enough.
Try adding this to your config.el:
(auto-save-visited-mode +1)
One step of my pipeline involves fetching from an external data source and I'd like to do that in chunks (order doesn't matter). I couldn't find any class that does something similar so I've created the following:
class FixedSizeBatchSplitter(beam.DoFn):
def __init__(self, size):
self.size = size
def start_bundle(self):
self.current_batch = []
def finish_bundle(self):
if self.current_batch:
yield self.current_batch
def process(self, element):
self.current_batch.append(element)
if len(self.current_batch) >= self.size:
yield self.current_batch
self.current_batch = []
However, when I run this pipeline, I get a RuntimeError: Finish Bundle should only output WindowedValue type error:
with beam.Pipeline() as p:
res = (p
| beam.Create(range(10))
| beam.ParDo(FixedSizeBatchSplitter(3))
)
Why is that? How comes that I can yield outputs in process but not in finish_bundle? By the way, if I remove finish_bundle the pipeline works but obviously discards the leftovers.
A DoFn may be processing elements from multiple different windows. When you're in process(), the "current window" is unambiguous - it's the window of the element being processed. When you're in finish_bundle, it's ambiguous and you need to specify the window explicitly. You need to be yielding something of the form yield WindowedValue(something, timestamp, [window]).
If all your data is in the global window, that makes it easier: window will be just GlobalWindow(). If you're using multiple windows, then you'll need to have 1 buffer per window; capture the window in process() so that you add to the proper buffer; and in finish_bundle emit each of them in the respective window.
I have an R function that returns text, including some LaTeX math mode, and I'm trying to use this text from an inline r chunk in an rmarkdown document. However, I get some quite strange behaviour regarding the use of math mode that I don't understand. It may be related to this question.
The following example works:
---
title: "Untitled"
output: pdf_document
---
```{r print_function}
print_fun <- function(x){
return(paste0("$\\mathrm{p}(\\beta < 0)$ > ", x))
}
x <- 0.5
```
Testing our printing function, we get `r print_fun(x)`.
Producing output
A small change breaks it
If I move the $ symbol a few places to the right, in order to also include the > sign within the math mode block, the document no longer compiles:
```{r print_function}
print_fun <- function(x){
return(paste0("$\\mathrm{p}(\\beta < 0) > $", x))
}
x <- 0.5
```
With the following error message:
Error producing PDF.
! LaTeX Error: \mathrm allowed only in math mode.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
...
l.137 ...g our printing function, we get \$\mathrm
Error: pandoc document conversion failed with error 43
Execution halted
This code works in an RSweave document, and I don't see why including the > symbol into math mode would have this effect.
Closing math mode after the numerical reference compiles again
```{r print_function}
print_fun <- function(x){
return(paste0("$\\mathrm{p}(\\beta < 0) > ", x, "$"))
}
x <- 0.5
```
Why?
This problem is to do with the space before the $ symbol in maths mode. From trial and error, this happens when the expression contains any maths function such as \\mathrm{}. So as minimal examples:
Works:
---
output: pdf_document
---
`r paste0("$\\mathrm{p}$")`
$\mathrm{p}$
Doesn't work:
---
title: "Untitled"
output: pdf_document
---
`r paste0("$\\mathrm{p} $")`
$\mathrm{p} $
Solution:
In your case, you are best off pasting the $ symbol after the value of the function:
print_fun <- function(x){
return(paste0("$\\mathrm{p}(\\beta < 0) >", x, "$"))
}
This lets you have the space after the > symbol.
I have tried to get multiple user inputs to print them in Scala IDE.
I have tried the this piece of code
println(scala.io.StdIn.readLine())
which works, as the IDE takes my input and then print it in the line but this works only for a single input.
I want the code to take multiple inputs till only newline is entered. example,
1
2
3
so i decided we needed an iterator for the input, which led me to try the following 2 lines of code seperately
var in = Iterator.continually{ scala.io.StdIn.readLine() }.takeWhile { x => x != null}
and
var in = io.Source.stdin.getLines().takeWhile { x => x != null}
Unfortunately none of them worked as the IDE is not taking my input at all.
You're really close.
val in = Iterator.continually(io.StdIn.readLine).takeWhile(_.nonEmpty).toList
This will read input until an empty string is entered and saves the input in a List[String]. The reason for toList is because an Iterator element doesn't become real until next is called on it, so readLine won't be called until the next element is required. The transition to List creates all the elements of the Iterator.
update
As #vossad01 has pointed out, this can be made safer for unexpected input.
val in = Iterator.continually(io.StdIn.readLine)
.takeWhile(Option(_).fold(false)(_.nonEmpty))
.toList
I have two questions. The first one: is code a pure expression?
lazy val code: Unit = {
// block of code
var s = "abc"
for (i <- 0 until 10) println(i)
s += s concat "def"
println(s)
}
And the second one: What does a pure expression mean? Is this a some code which does not return anything?
A pure expression is a computation that serves only to produce a resulting value - it has no side effects. In the case of your field code above, you make calls to print stuff to the console (println), which is considered a side effect, so it is not a pure expression. An example of a pure expression would be something like:
lazy val foo = 2 + 3
It does nothing apart from generate the final value for foo, and could safely be replaced by the result of the computation (5) without changing the outcome of the program in any way. If you made such a replacement in your code above:
lazy val code: Unit = ()
you would change the program - it no longer prints anything to the console.
Have a look here, for example, for more information about pure functions and pure expressions, and their significance in functional programming.