Congrats!
On Tue, Jan 26, 2021 at 4:25 AM Piotr Szuberski
wrote:
> Thank you everyone! I really don't know what to say. I'm truly honoured. I
> do hope I will be able to keep up with the contributions.
>
> On 2021/01/22 16:32:45, Alexey Romanenko
> wrote:
> > Hi everyone,
> >
> > Please join me
Hello,
I am exploring Beam ahead of a new job I’m starting soon in which I’ll be using
Beam/Dataflow. I’ve spotted a small typo in the beam docs that I’d like to
correct as (a) its rather misleading and (b) correcting typos is a nice easy
way of getting involved in Beam 😊
Can I be added as a co
I saw this issue on another OSS repo (
https://github.com/apache/hudi/issues/2479), they just removed the spring.io
repository but I'm not sure where their dep would come from then. We could
swap the spring.io repo for the pentaho nexus one public.nexus.pentaho.org
(here probably in Beam
https://gi
I stumbled today on this user request:
BEAM-10982 Wheel support for linux aarch64
It made me wonder if with the advent of ARM64 processors not only in
the client but server side (Graviton and others) if it is worth that
we start to think about having support for this architecture on the
python ins
+dev
Hi Yu,
Which runner are you using for your pipeline? Also it would be helpful to
share your pipeline code as well.
On Mon, Jan 25, 2021 at 10:19 PM wrote:
> Hi Beam Community,
>
> I have a splittable `DoFn` that reads message from some stream and output
> the result to down stream. The ps
I missed this thread and filed a JIRA for it:
https://issues.apache.org/jira/browse/BEAM-11689
> We could swap the spring.io repo for the pentaho nexus one
public.nexus.pentaho.org (here probably in Beam
https://github.com/apache/beam/blob/67989cafecf3f5d4bce879e9f6b9a690955e84d5/buildSrc/src/main
+1
I don't think it would be that hard to build and release arm-based docker
images. (Perhaps just a matter of changing the docker file to depend on a
different base, and doing some cross-compile. That would suss out whether
we're inadvertently taking on any incompatible dependencies.)
Theoretica
Go cross compilation is as simple as setting the right flag env variables
[1], but can be as complicated as requiring a cross compiling GCC instance
installed if CGO[2] is necessary. I think we're probably clear on just
needing the flag though for the various Boot executables.
For go pipelines we'
Cool. Are DoFn (et al) references compatible across cross-compiled
binaries?
On Tue, Jan 26, 2021 at 11:23 AM Robert Burke wrote:
> Go cross compilation is as simple as setting the right flag env variables
> [1], but can be as complicated as requiring a cross compiling GCC instance
> installed i
Welcome, Jamie!
And thanks for the contribution! I've marked you as a contributor on JIRA,
so you can assign issues to yourself now.
Best
-P.
On Tue, Jan 26, 2021 at 9:47 AM Jamie Thomson
wrote:
> Hello,
>
>
>
> I am exploring Beam ahead of a new job I’m starting soon in which I’ll be
> using Be
I believe so.
The Go SDK requires in most instances for a user to Register their DoFns at
package init time, linked to the type/functions fully qualified path as
detemined by Go, which is consistent across architectures, at least with
the standard toochain.
Those strings are used to look things u
+dev
On Tue, Jan 26, 2021 at 1:07 PM Eleanore Jin wrote:
> Hi community,
>
> Does Beam support Flink Async I/O operator? if so, can you please share
> the doc, and if not, is there any workaround to achieve the same in Beam
> semantics?
>
>
> https://ci.apache.org/projects/flink/flink-docs-stab
Hello Beamers!
I just filled a JIRA BEAM-11217 [1] to make some changes and update the
content of the release guide, based on my experiences with running the
2.26.0 release.
Overall, the content is pretty thorough, but it's been added to organically
over time, and is due for a bit of a cleanup. M
> One bigger change to the content that certainly warrants discussion here:
I'd like to remove the manual command level copies of the automation
scripts in the release document.
I approve. I already removed a large chunk of the copies in [1], but I may
have missed some places.
I think BEAM-11217
Dang it. Good catch. Thanks.
https://issues.apache.org/jira/browse/BEAM-11693 is the right JIRA.
On Tue, Jan 26, 2021 at 3:56 PM Robert Burke wrote:
> Hello Beamers!
>
> I just filled a JIRA BEAM-11217 [1] to make some changes and update the
> content of the release guide, based on my experience
This should be fixed now.
On Tue, Jan 26, 2021 at 10:23 AM Kyle Weaver wrote:
> I missed this thread and filed a JIRA for it:
> https://issues.apache.org/jira/browse/BEAM-11689
>
> > We could swap the spring.io repo for the pentaho nexus one
> public.nexus.pentaho.org (here probably in Beam
> ht
Hi Boyuan,
Thanks for replying. We are using beam 2.25.0 and direct runner for testing. We
are trying to develop an unbounded streaming service connector with splittable
DoFn. In our connector.read(), we want to commit the message back to stream
after output the record to downstream user pipel
17 matches
Mail list logo