You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Richard Eckart de Castilho <re...@apache.org> on 2023/04/06 18:47:32 UTC

Re: UIMA-CPP update

Hi Pablo,

how are things going? Are there any blockers you might need help with?

Cheers,

-- Richard


Re: UIMA-CPP update

Posted by Pablo Duboue <pa...@gmail.com>.
Hi!

I have some great news, but I'll send them in a longer email.

On Sun, Jun 4, 2023 at 9:26 AM Richard Eckart de Castilho <re...@apache.org>
wrote:

> Hi,
>
> > On 10. Apr 2023, at 10:32, Pablo Duboue <pa...@gmail.com> wrote:
> >
> > Last but not least, I have been working on my fork [8]. I see most
> > commits have JIRA issues associated with them. When the time is ready
> > I make a pull request from my project? What would you suggest?
>
> I would say best work directly on the official repo instead of working on
> your own branch. Activity is best visible when performed on the main repo.
>

Very good point. It turns out I was missing registering with the gitbox and
just got access to the repo.


> We do not use JIRA anymore but have switched to using GitHub issues
> exclusively.
>

This is great news!


> The uimacpp repo does not seem to have issues enabled atm because it was
> scheduled for going out of business. However, you can enable those by
> setting
> the `github/features/issues` key in the `.asf.yaml` file. See here
>
>   https://github.com/apache/uima-uimaj/blob/main/.asf.yaml


Yes, thanks for that. I have enabled it now.


> As for things like timelines and such - I usually work without those ;)
> I do work as work comes in and every once in a while, I do a release.
> If you wish to do release planning, I'd say that's completely up to you.
>

Very sane approach.

P

Re: UIMA-CPP update

Posted by Richard Eckart de Castilho <re...@apache.org>.
Hi,

> On 10. Apr 2023, at 10:32, Pablo Duboue <pa...@gmail.com> wrote:
> 
> Last but not least, I have been working on my fork [8]. I see most
> commits have JIRA issues associated with them. When the time is ready
> I make a pull request from my project? What would you suggest?

I would say best work directly on the official repo instead of working on your own branch. Activity is best visible when performed on the main repo.

We do not use JIRA anymore but have switched to using GitHub issues exclusively.

The uimacpp repo does not seem to have issues enabled atm because it was
scheduled for going out of business. However, you can enable those by setting
the `github/features/issues` key in the `.asf.yaml` file. See here

  https://github.com/apache/uima-uimaj/blob/main/.asf.yaml

As for things like timelines and such - I usually work without those ;)
I do work as work comes in and every once in a while, I do a release.
If you wish to do release planning, I'd say that's completely up to you.

Cheers,

-- Richard

Re: UIMA-CPP update

Posted by Pablo Duboue <pa...@gmail.com>.
On Thu, Apr 6, 2023 at 11:47 AM Richard Eckart de Castilho
<re...@apache.org> wrote:
>
> Hi Pablo,
>
> how are things going? Are there any blockers you might need help with?

Hello!

All is good. Too good actually (since last time we talked I started 3
new contracts, trying to see if I can make one of them somewhat
related to UIMA-CPP).

Yes, there are a number of things that'd be good to discuss here:

* The main new work I have done is to write a pkg-config file for
UIMA-CPP that is fed from automake (more on this below).
* I looked at the existing documentation, the README.4bin [1] file
says that only linux is supported (the exact wording is "MacOS and
Windows versions are delayed pending user requests"). If that is the
case, we are much closer to making a release and I can reuse that
wording on the README.md.
* Went through the bug reports [2], most of them relate to either the
MacOS version or the framework failing to compile on newer systems
(feel free to assign the bugs to me or let me know if I can do that
myself and I'll figure out JIRA a bit). Or relate to UIMA-AS which
we're not working on.
* JIRA and the code in the main branch point to a 3.0.0 release. I
have scaled that back to a 2.5.0 release. I'm concerned users will be
confused as being on par with UIMA3.
* The Release Notes [3] contain the following bit:

>> Installing UIMACPP SDK as a system-wide shared library is discouraged since we do not
>> have support for parallel versions.  The include directory does not have version number and
>>  there cannot be multiple versions of executables runAECpp and deployCppService.

As I'm working on getting UIMA-CPP to build with system dependencies,
this is a good moment to talk about the changes to the world since
UIMA CPP came to be:

Most programs these days run on containers. It seems to me that it
makes more sense to ship a UIMA-CPP that will run on a particular
Linux install and/or a base docker image.

That way we ship the UIMA-CPP binary library, include files, etc
installed as system files. There is no longer need for UIMACPP_HOME to
be defined and we can use existing techniques to find dependencies and
command-line arguments (like pkg-config [4]).This allows to do things
like

  g++  `pkg-config uima --cflags` -c DaveAnnotator.cpp

This changes the concept of what the SDK _is_, as it is now tied to
different underlying releases of the OS. Maybe we can use github
actions [5] to support a few distros without extra effort. But let's
discuss what other people think and where to take it.

I'm also thinking about how useful this release will be in a world
where UIMA2 has been retired. So I'm thinking about adding a
non-trivial example wrapping the ONNX C++ runtime [6]. That could be
fun (and useful) (and related to some of my current contracts) but
will further delay the release.

For a future release, I really want to work on aggregate AEs support.
There was an earlier comment when discussing the retirement of
UIMA-CPP in that regard [7] and it has stayed with me. But that'd be
too much for this release.

There is a bit of busy work ahead cleaning up the existing
documentation files. That also needs to be factored in for a timeline
for the release.

Last but not least, I have been working on my fork [8]. I see most
commits have JIRA issues associated with them. When the time is ready
I make a pull request from my project? What would you suggest?

P



[1] https://github.com/apache/uima-uimacpp/blob/main/README.4bin
[2] https://issues.apache.org/jira/browse/UIMA-6175?jql=project%20%3D%20UIMA%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%22C%2B%2B%20Framework%22
[3] https://github.com/apache/uima-uimacpp/blob/main/RELEASE_NOTES.html
 (yes, that is a MS Word HTML file, I'll change it to markdown for the
release.)
[4] https://people.freedesktop.org/~dbn/pkg-config-guide.html
[5] https://docs.github.com/en/actions
[6] https://onnxruntime.ai/docs/build/inferencing.html#supported-architectures-and-build-environments
[7] https://lists.apache.org/thread/f1r3sghgn2oqhvzz27y26zg6j3olv8qq
[8] https://github.com/DrDub/uima-uimacpp