Hi Michal, Alexey
Thank you for your email. I am using macOS Catalina and JDK 8 with IntelliJ
IDEA 2019.1
I will try to setup IntelliJ from scratch and see if the error resolves.
Regards,
Saikat
On Tue, Oct 22, 2019 at 7:05 AM Alexey Romanenko
wrote:
> Hi,
>
> Thank you for your interest
+1 on this, having the ability to create timers based on data would make a
bunch of use cases easier to write.
Any thoughts on having a isSet() / read() / setMinimum(timeStamp) type
ability?
On Wed, 23 Oct 2019 at 00:52, Reuven Lax wrote:
> Kenn:
> +1 to using TimerFamily instead of TimerId
Thank you Aizhamal
Regards,
Saikat
On Tue, 22 Oct 2019 at 7:00 AM, Aizhamal Nurmamat kyzy
wrote:
> Welcome Saikat!
>
> On Sun, Oct 20, 2019, 5:55 AM Saikat Maitra
> wrote:
>
>> Hi Kenneth,
>>
>> Thank you, much appreciate your help.
>>
>> Warm regards,
>> Saikat
>>
>> On Sat, Oct 19, 2019 at
Your proposal will only affect the seed job (which doesn't do color outputs
AFAIK).
I think you want to add colorizeOutput() here:
https://github.com/apache/beam/blob/bfebbd0d16361f61fa40bfdec2f0cb6f943f7c9a/.test-infra/jenkins/CommonJobProperties.groovy#L79-L95
Otherwise no concerns from me.
On
I've had a one-line bug fix PR open since last week that I'd love to get
merged for 2.17.
Would a committer be willing to take a look at it?
https://github.com/apache/beam/pull/9784
Thank you!
On Tue, Oct 22, 2019 at 4:52 PM Jean-Baptiste Onofré
wrote:
> Hi Israel,
>
> Welcome aboard !
>
> I just added you in contributors on Jira.
>
> Regards
> JB
>
> On 22/10/2019 21:43, Israel Herraiz wrote:
> > Hi,
> >
> > My name is Israel, and I work in the Professional Services team
Hi Israel,
Welcome aboard !
I just added you in contributors on Jira.
Regards
JB
On 22/10/2019 21:43, Israel Herraiz wrote:
> Hi,
>
> My name is Israel, and I work in the Professional Services team at Google.
>
> I have created a JIRA issue and submitted the corresponding pull request
> (see
Hi,
My name is Israel, and I work in the Professional Services team at Google.
I have created a JIRA issue and submitted the corresponding pull request
(see https://issues.apache.org/jira/browse/BEAM-8458), and I would like to
be able to assign the issue to myself.
That's my second pull request
thanks, so IIUC, I’m going to update job_00_seed.groovy like this:
wrappers {
colorizeOutput()
timeout {
absolute(60)
abortBuild()
}
}
Then add the comment run seed job
Does anyone have any concerns with me trying this out now?
-chad
On Tue, Oct 22, 2019 at 11:42
Also note that changing the job DSL doesn't take effect until the "seed"
job runs. (use the "run seed job" phrase)
On Tue, Oct 22, 2019 at 11:06 AM Chad Dombrova wrote:
> Thanks, I'll look into this. I have a PR I'm building up with a handful
> of minor changes related to this.
>
>
>
> On Tue,
Thanks, I'll look into this. I have a PR I'm building up with a handful of
minor changes related to this.
On Tue, Oct 22, 2019 at 10:45 AM Yifan Zou wrote:
> Thanks, Udi! The ansicolor plugin was applied to ASF Jenkins universally.
> You might need to explicitly enable the coloroutput in
Seems to be already installed:
https://issues.apache.org/jira/browse/INFRA-16944
Do we just need to enable it somehow?
This might work:
https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.helpers.wrapper.WrapperContext.colorizeOutput
BTW, our Jenkins is maintained by ASF's
Hi all,
As a user trying to grok failures in jenkins I think it would be a huge
help to have color output support. This is something that works out of the
box for CI tools like gitlab and travis, and it really helps bring that
21st century feel to your logs :)
There's a Jenkins plugin for
+1 for moving. This is just a left-over from the fist "reference" runner
implementation for portability.
On 22.10.19 16:59, Łukasz Gajowy wrote:
+1 for moving/renaming. I agree with Kyle and Michał - there indeed
seems to be some confusion. The name "runners/reference" suggests that
it's a
Kenn:
+1 to using TimerFamily instead of TimerId and TimerMap.
Jan:
This is definitely not just for DSLs. I've definitely seen cases where the
user wants different timers based on input data, so they cannot be defined
statically. As a thought experiment: one stated goal of state + timers was
to
Would approach 1 be akin to abort semantics?
On Mon, Oct 21, 2019 at 8:01 PM jincheng sun
wrote:
> Hi Luke,
>
> Thanks a lot for your reply. Since it allows to share one SDK harness
> between multiple executable stages, the control service termination may
> occur much later than the completion
+1 for moving/renaming. I agree with Kyle and Michał - there indeed seems
to be some confusion. The name "runners/reference" suggests that it's a not
production-ready "Runner" (it seems to be neither of those). If possible,
maybe sdks/java/portablility is a good place for this?
Łukasz
wt., 22
Hi Max,
wouldn't that be actually the same as
class MyDoFn extends DoFn {
@ProcessElement
public void process(
ProcessContext context) {
// "get" would register a new TimerSpec
Timer timer1 = context.getTimer("timer1");
Timer timer2 = context.getTimer("timer2");
The idea makes sense to me. I really like that Beam gives upfront specs
for timer and state, but it is not flexible enough for timer-based
libraries or for users which want to dynamically generate timers.
I'm not sure about the proposed API yet. Shouldn't we separate the timer
specs from
I agree this should be moved. PortableRunner.java is analogous to
portable_runner.py, which resides under
sdks/python/apache_beam/runners/portability. Maybe PortableRunner.java
should be moved to somewhere under sdks/java, as it's not actually a runner
itself. The nomenclature is confusing,
Hi,
I found the Java PortableRunner class in org.apache.beam.runners.reference
package, where ReferenceRunner used to reside prior to its deletion. The
PortableRunner implementation however is one that can be used with real
JobServers in production code.
It seems that this class shouldn’t be in
Hi,
Thank you for your interest to contribute!
Did you properly imported a project (as explained on page [1]) and all deps
were resolved successfully?
[1]
https://cwiki.apache.org/confluence/display/BEAM/Set+up+IntelliJ+from+scratch
Welcome Saikat!
On Sun, Oct 20, 2019, 5:55 AM Saikat Maitra wrote:
> Hi Kenneth,
>
> Thank you, much appreciate your help.
>
> Warm regards,
> Saikat
>
> On Sat, Oct 19, 2019 at 10:40 PM Kenneth Knowles wrote:
>
>> Welcome! I've added you to the Contributors role.
>>
>> Kenn
>>
>> On Sat, Oct
Hi,
can you give some more context on which tests are you running, what
system/version are you using and which IntelliJ version gives you errors?
It's hard to tell anything from just the errors.
Regards,
Michal
On Tue, Oct 22, 2019 at 2:29 AM Saikat Maitra
wrote:
> Hi,
>
> I am interested to
Hi Kenn,
On 10/22/19 2:48 AM, Kenneth Knowles wrote:
This seems extremely useful.
I assume you mean `@OnTimer("timers")` in your example. I would
suggest that the parameter annotation be something other than @TimerId
since that annotation is already used for a very similar but different
Hi Reuven,
first of all big +1 for this.
Next, couple of questions that arise. Do you target DSLs only, or do you
suppose that this would be used by end-users as well? If only DSLs would
be in concern, then I think:
a) it is not only about timers, but state has to be managed in the
same
26 matches
Mail list logo
