<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Alex,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I'll try to migrate my code to the v2 API and describe the process, but please don't take my words as a promise :-D</blockquote><div><br></div><div>No worries. Any help will be greatly appreciated!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">After re-reading my statement I realized that it was too harsh, sorry about that. I rather meant that I was only able to get information post factum, which reminded some of our hardware vendors :)</blockquote><div><br></div><div> No worries. Getting concurrency into ORC (which is the main aim of ORCv2, vs ORCv1) has involved a lot of trial and error, and corresponding churn in the APIs, and that has made documentation challenging. This isn't intended to be a permanent state of affairs though, and the more the APIs settle down, the easier and more rewarding documentation will be (both to write and to use).</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> I plan to add deprecation attributes to the legacy classes on trunk so that clients who use 9.0 receive warnings.<br>That's a very good idea. I think I understand your motivation to force everyone to use the new APIs, but I also think it makes sense to make the migration process a bit more smooth.</blockquote></div><div><br></div><div>I have filed <a href="http://llvm.org/PR41986">http://llvm.org/PR41986</a> if anyone wants to jump on it. :)</div><div><br></div><div>-- Lang. </div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 21, 2019 at 12:51 AM Alex Denisov <<a href="mailto:1101.debian@gmail.com">1101.debian@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello everyone,<br>
<br>
Praveen,<br>
<br>
> You can also take a look at "Updating ORC for Concurrency" talk by lang hames, the talk explains about the new APIs.<br>
<br>
It's a good reference, but it is not sufficient as communication channel, imho.<br>
<br>
> For documentation kaleidoscope, I don't think the updated version is available yet.<br>
<br>
It is very often outdated, so I developed (not on purpose) a mental model of not relying on it.<br>
<br>
Lang,<br>
<br>
> There is no guide yet. It sounds like there is plenty of interest in creating one. I’m also going to try to post a draft of the ORCv2 design document we discussed later tonight.<br>
<br>
I'll try to migrate my code to the v2 API and describe the process, but please don't take my words as a promise :-D<br>
<br>
> It is definitely not closed source.<br>
<br>
After re-reading my statement I realized that it was too harsh, sorry about that. I rather meant that I was only able to get information post factum, which reminded some of our hardware vendors :)<br>
<br>
> I plan to add deprecation attributes to the legacy classes on trunk so that clients who use 9.0 receive warnings.<br>
<br>
That's a very good idea. I think I understand your motivation to force everyone to use the new APIs, but I also think it makes sense to make the migration process a bit more smooth.<br>
<br>
<br>
Stefan,<br>
<br>
Thanks for the summary and for bringing more people into the discussion.<br>
<br>
Thanks a lot for your contributions, folks!<br>
<br>
Cheers,<br>
Alex.<br>
</blockquote></div>