You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, @showprogress doesn't work for functions, e.g.,
functionfoo(n)
for i in1:n
sleep(0.1)
endend@showprogressfoo(50) # The ideal usage, doesn't work
Why we need this?
In some situations one does need a silent execution, and in some situations one doesn't.
Some package authors don't intend to give any additional execution information other than the results
At present, we could manually do something like this... Not complicated, but this requires some document reading, and when the real kernel function is nested deeply, this requires a bunch of modifications on the APIs.
functionfoo(n; quite =true)
p = quite ?nothing:Progress(n)
for i in1:n
sleep(0.1)
quite ?nothing:next!(p)
endend
Take the case of this foo, I think the reason @showprogress won't work for this is because we can't directly get the definition of foo when calling it so that unable to parse the expression. (Ref: JuliaLang/julia#2625, JuliaLang/julia#24347)
I'm wondering if the following alternative procedure is practical to support this feature. (please excuse me for my current status of lacking of experiences in macros, I'm just plotting the general idea)
1. use a @progress macro to generate two functions: a wrapper and a kernel
Let
@progressfunctionfoo(n)
for i in1:n
sleep(0.1)
endend
generate
functionfoo_(n)
quotefor i in1:$n
sleep(0.1)
endendendfoo(n) =eval(foo_(n))
By doing this, calling foo(n) is still works as usual -- no Progress is involved. But this gives the possibility to parse the function expressions.
2. write a parser to foo_
Let parse(foo_(50)) returns
quote@showprogressfor i in1:50sleep(0.1)
endend
3. modify @showprogress to support calling of parse(foo_(50))
let @showprogress foo(50) actually calling eval(parse(foo_(50))), so that this feature is supported
As a summary,
the package author can simply add a @progress notation to support the feature
@progressfunctionfoo(n)
# some definitions...end
and the package user uses @showprogress notation to plot progress
@showprogressfoo(50)
This's a solution I think is possible. However, since I'm currently not very familiar with macro writing, I'm not very sure of it.
The text was updated successfully, but these errors were encountered:
expands to the normal definition of foo and another one, say foo#with_progress with PogressMeter instrumentation added. Then @showprogress foo(50) just becomes foo#with_progress(50) (possibly with some code to check foo#with_progress is defined provide a useful error message if not.)
Note that this (like the original proposal) solves
In some situations one does need a silent execution, and in some situations one doesn't.
but does not solve
Some package authors don't intend to give any additional execution information other than the results
Currently,
@showprogress
doesn't work for functions, e.g.,Why we need this?
At present, we could manually do something like this... Not complicated, but this requires some document reading, and when the real kernel function is nested deeply, this requires a bunch of modifications on the APIs.
Take the case of this
foo
, I think the reason@showprogress
won't work for this is because we can't directly get the definition offoo
when calling it so that unable to parse the expression. (Ref: JuliaLang/julia#2625, JuliaLang/julia#24347)I'm wondering if the following alternative procedure is practical to support this feature. (please excuse me for my current status of lacking of experiences in macros, I'm just plotting the general idea)
1. use a
@progress
macro to generate two functions: a wrapper and a kernelLet
generate
By doing this, calling
foo(n)
is still works as usual -- noProgress
is involved. But this gives the possibility to parse the function expressions.2. write a parser to
foo_
Let
parse(foo_(50))
returns3. modify
@showprogress
to support calling ofparse(foo_(50))
let
@showprogress foo(50)
actually callingeval(parse(foo_(50)))
, so that this feature is supportedAs a summary,
the package author can simply add a
@progress
notation to support the featureand the package user uses
@showprogress
notation to plot progressThis's a solution I think is possible. However, since I'm currently not very familiar with macro writing, I'm not very sure of it.
The text was updated successfully, but these errors were encountered: