Roadmap for this repo

I noticed that PRs for LwM2M v1.1 are available for a while already but none of them have been merged (for an unknown reason).
Can I have a roadmap for continuing the work on wakaama?

Hi @hannestschofenig,
A lot of PRs was provided by contributors but without any answer from actual development team. :worried:
After a while contributors asked Eclipse foundation to find a solution. Eclipse foundation tried to contact current development team and in particular current project lead @dnav, but after several mails and time waiting without any answer ... The Eclipse foundation recently decides to create a new team for this project.
Too bad that so many time was lost just because previous team abandoned the project without any news... :disappointed:
Anyway, there are currently at least 2 active contributors which should revive the project soon. Stay tuned :wink:

To say I am surprised by this announcement is an understatement. I have not received any communication from the Eclipse Foundation in the last six months.
The last communication we had was in February with Frédéric. I had the impression that there was an understanding of the status of Wakaama. Wakaama is a LwM2M 1.0 reference implementation. It is a foundational baseline and was never intended to be a complete product. To quote my discourse from that discussion:

The consensus among users of Wakaama is that the project is complete. I had discussions with various industry people, and they are all satisfied with the current feature set. Of course, most have implemented additional features, but few want to contribute their features to Wakaama. This part should illustrate why new contributions did not get meaningful feedback: people are happy with the status quo and are reluctant to see new features coming to Wakaama. Yes, even LwM2M 1.1. They see that as a disruption of their current deployed setup.

Some additional points we should consider about the Wakaama project:

This is an open-source project.
The license is permissive. If you are not satisfied with the direction, or the content of this project, fork it, as Scott did. Authorization is not required.

This project is free (as in beer). No one owes anything to anyone.
As previously mentioned, many large corporations have benefitted from this Wakaama, and added needed functionality in their self-interest without contributing in any way, shape, or form, and that is okay.  If you need something missing from it, and if your employer is okay for you to spend time and money working on this, do it. Otherwise, get something with additional features, complete documentation, and a full-time team supporting it like https://github.com/IOTEROP/IOWA.

To all the users of Wakaama during these years, thank you for your interest. Just remember that software, like any other work, has value.
Sincerely,
dnav

@dnav
AFAIK, Jens Reimann (@ctron) from the IoT-PMC tried to reach you multiple times, the last time via e-mail on 25.03.2020. Maybe, his e-mails didn't reach you, or your answers didn't reach him.
For myself, I have to say, that I spent my time into Californium, because it's too hard for me to switch to frequently between C and Java. It was also too much to work in that project.

Hi @dnav,
I didn't follow precisely what happens with wakaama last month, but I can maybe give some hints about the current situation.
About communication issue :

I have not received any communication from the Eclipse Foundation in the last six months.

Email was sent as you can see : https://www.eclipse.org/lists/iot-pmc/msg06997.html (your were in copy, your ioterop.com address was used)
Maybe an issue with your email provider ?
About scope of the project :

Wakaama is a LwM2M 1.0 reference implementation.

It seems this was not clear for the community and we can not blame it as there is nothing about this in documentation(readme or websites).
And by the past you let understand that wakaama will support LWM2M 1.1 : https://www.eclipse.org/lists/wakaama-dev/msg00506.html
So not really supprising that people expect LWM2M 1.1 support.
About community expectation :

The consensus among users of Wakaama is that the project is complete
people are happy with the status quo and are reluctant to see new features coming to Wakaama.

This sounds clearly not the case when you see all the open PRs and issues.

Yes, even LwM2M 1.1. They see that as a disruption of their current deployed setup.

I do not understand, generally this problem is solved using semantic versioning (or something like this).

one stable branch (1.x or 1.0.x) with bug fixes and not so much changes.
another one (2.x) for new feature with big API changes.

Of course people who are happy with the current version is not forced to upgrade.

The license is permissive. If you are not satisfied with the direction, or the content of this project, fork it, as Scott did. Authorization is not required.
No one owes anything to anyone.

Maybe, I'm wrong and @fdesbiens  will correct me, but I think this is not so true for eclipse project. An eclipse project is more than that. Committer are responsible to make the project "alive" at least by answering to community. It should also facilitate contribution and integration of new committers etc etc .. (see https://www.eclipse.org/projects/dev_process/#2_1_Open_Source_Rules_of_Engagement)
If they are no time or willingness to continue to make the project alive, they should at least help to pass the torch.(I'm not sure this expression is really used in English :sweat_smile:)
If nobody is interested by the project anymore it should be archived.

If you need something missing from it, and if your employer is okay for you to spend time and money working on this, do it

Community try to do it but nobody integrate the changes :confused:

Otherwise, get something with additional features, complete documentation, and a full-time team supporting it like https://github.com/IOTEROP/IOWA.

Maybe, I didn't get you but you seems a bit disappointed that there is not enough contribution to Wakaama project but at same time you encourage people to use your new closed-source solution. It sounds confusing to me.
But to be honest, I still don't get what is your position about Wakaama project. Do you still feel as project lead ? or are you considering that the project is "finished" and should be archived ? I don't get it ?

Hi @dnav.
I am glad to see you are still around.
I am surprised you think we had reached an understanding. In my last private to reply to you, send of January 20, I wrote this:

I understand that a large part of the user base is happy with the code and not looking for new features. However, at least a few members of your community seem to have a different opinion.
Obviously, it is up to the project team to decide where Wakaama will be headed. That being said, I would strongly recommend to explore ways to accommodate people like Scott. A possible way, for example, would be to declare the current 1.0 release train as a long term support (LTS) branch that would live in parallel to a 2.x branch implementing new features. There are many other ways to achieve the same result. What do you think?

You never replied to me. This led me to bring the matter to the PMC.
Jens sent several emails to the PMC list and to the same ioterop.com address my email had been sent to. You never replied to any of them.
In the last one, he wrote this.

Shouldn't I hear back from you in the next week (which should make this a period of 4 weeks), my recommendation to EMO would be, to declare the project dysfunctional, so that we can elect new project leads and/or committers.

We are well past that date.
Since April, I worked hard to find people willing to continue working on the project. We now have four potential committers willing to jump in.
If you consider Wakaama is complete, what you have is not a project but just a dead repository. Projects have roadmaps, respond to issues and have commits. Dead repositories do not have a community around them and certainly do not contribute to the improvement of the Eclipse ecosystem. Moreover, as @sbernard31 mentioned, projects and committers have obligations to the community. I am sure @waynebeaton can provide more details.
The simple fact this issue exists shows there are people who wish to push Wakaama forward.
So, David, the choice is yours.
If all you care about is a reference implementation set in stone, then you can create your own static fork of the current repository and live happily ever after.
If you still wish to be part of the team, then I am sure the new committers will welcome your leadership and contributions. However, this means you will have to agree with them on a new course and scope for the project in an open and democratic fashion.
Since you saw the previous messages in this thread, I expect you will read this one very soon. Please let us know as soon as possible if you wish to be part of the project's future.

I am not aware of any reason why this project should be prevented from moving forward. Hypothetically, there may be some limitations on what can be claimed with regard to a specification, but I am not aware of any such limitations. Without having specific knowledge of the governance of the specification process to which Eclipse Wakaama contributes a reference implementation, I have to assume that as long as the 1.0 version remains tagged, it may continue to be the reference implementation while the project progresses.
Independent of any claims regarding specifications, the project is open source and the Eclipse Foundation's definition of open source requires that a project be both open and transparent. Note that our particular definition of open means "open to input from others" (we often refer to this as a "level playing field").
With respect, "you can fork it and do what you want" does not conform to the Eclipse Foundation's definition of open source.
Having said all that, a Eclipse open source project is required to operate within its defined scope. If the contributions are within scope of the Eclipse Wakaama project, then the contributions need to be given fair consideration for merging. It is completely reasonable, however, for a project team to reject contributions that fall outside of the project scope. It is not reasonable for a project team to completely ignore contributions (FWIW, there are a lot of open source projects that would love to have twenty pull requests).
By my observation, the project is no longer active. According to our process, in the absence of a compelling reason to do otherwise, the project should be terminated and archived. Alternatively, the project leadership chain (which includes the PMC and EMO) may declare the project dysfunctional and replace the development team. How shall we proceed?

Thanks for everyone, summing up what already has happened in the last months. So I don't need to do it :)

To say I am surprised by this announcement is an understatement. I have not received any communication from the Eclipse Foundation in the last six months.

As people already mentioned, that is not true. And I do think that this is indeed a big problem. If the people leading the project cannot be contacted.

By my observation, the project is no longer active. According to our process, in the absence of a compelling reason to do otherwise, the project should be terminated and archived. Alternatively, the project leadership chain (which includes the PMC and EMO) may declare the project dysfunctional and replace the development team. How shall we proceed?

I think the PMC already came to the same conclusion a while back. We already asked EMO to declare the project dysfunctional a while back. And we also took quite some extra time to discuss options, alternatives, …
To me, this issues doesn't change the current situation of the project, and I would propose to continue with the plan do declare the project dysfunctional.
As @waynebeaton already mentioned, curating a specific version/tag/state of the repository is no problem at all. But development should be allowed to progress. The project still continues to be an Eclipse project, and thus allows current and new committers to work in the defined project scope. Existing committers can still work on the project, as they can now, if they wish to do so.
@waynebeaton if you need any additional +1 from the PMC, please let me know and I will start another e-mail thread.

OK. It seems I need to remind people of a fundamental fact:
I am not an employee of the Eclipse Foundation.
 I explained my position in February. It seems you found people willing to take care of this repo. There are other committers. Why the drama ?

Gently and then wish them the best.
From: David Navarro<EMAIL_ADDRESS>Sent: Monday, September 28, 2020 3:53 PM
To: eclipse/wakaama<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: Re: [eclipse/wakaama] Roadmap for this repo (#482)
OK. It seems I need to remind people of a fundamental fact:
I am not an employee of the Eclipse Foundation.
 I explained my position in February. It seems you found people willing to take care of this repo. There are other committers. Why the drama ?

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://t.sidekickopen79.com/s1t/c/5/f18dQhb0S7lM8dDMPbW2n0x6l2B9nMJN7t5XWPfhMynW2zWXr88rBCLdW56dvYD4BGhcv102?te=W3R5hFj4cm2zwW3P28X24hCPvhW43T4NV3F9cmbW4cHY_X3zcJ8_W3_R0414cPVPfW4cgtPs1RY32cW4cQJkD43TbcQW41YspN1N4h9Cf1Q3fwv04&si=8000000002614771&pi=671359a7-9aae-49b9-a14a-0567a248cace, or unsubscribehttps://t.sidekickopen79.com/s1t/c/5/f18dQhb0S7lM8dDMPbW2n0x6l2B9nMJN7t5XWPfhMynW2zWXr88rBCLdW56dvYD4BGhcv102?te=W3R5hFj4cm2zwW3P28X24hCPvhW43T4P243X5bgW3SYLpP3T1MdZW1LFyV_4hCWypW49M7TJ1Gy80dW3Qzvpw2CF0LCW2CHY7J1XcS1lW3g7t901XcRkcW2PCb4G2HDGcQW2TqDYK32mtXWw36m5DG77g2&si=8000000002614771&pi=671359a7-9aae-49b9-a14a-0567a248cace.

I am not an employee of the Eclipse Foundation.

I don't think that anybody has made any consideration of your employment status. To be clear, while we do need certain paperwork from committers to ensure that they have their employer's approval to contribute to open source projects, employment status is otherwise irrelevant. In case there is any confusion, with a very small number of exceptions (mostly the Eclipse Dash and Eclipse CBI projects), the Eclipse Foundation does not employ any project leads or committers.
There appears to be some confusion regarding the project lead and committer roles, so I'd like to spend a minute to discuss what we're doing here in the larger sense.
The Eclipse Foundation Development Process (EDP), which all committers and project leads agree to implement, is all about building a community and ecosystem around open source technology. This means that committers and project leads agree to build up and, at least in part, serve a community around their technology. At least in part, that means that committers and project leads sign up to court contributor participation and help them with the contribution process. To do this successfully requires giving up any idea of absolute control and allowing others to participate on a level playing field (with in the scope of the project). Our most successful open source projects have committers representing a wide diversity of interests, employers, and backgrounds.
I don't see any drama here. Only a community trying to participate in and grow the project.

@waynebeaton if you need any additional +1 from the PMC, please let me know and I will start another e-mail thread.

The project has zero active committers and so I agree with the PMC's assertion that we are in an exceptional situation.
So now what?
My strong preference is that the existing project team return to an active state and that they start an election to bring aboard new committers to increase their diversity. Are any of the committers on this thread prepared to do that? FWIW, the project has three committers: all of them will need to vote in order for a committer election to conclude successfully.
That failing, as is outlined in the EDP, the project leadership chain (the project lead, PMC, and EMO) has responsibility to adjust the composition of the project team to get the project back into an active state. Who should be removed and who should be added?
My recommendation is that we (the PMC or EMO) take this to the wakaama-dev list.

It is good to hear that you guys are looking into the project management. I am looking forward to hear how the work on Wakaama will go forward.

FWIW I am interested to see whether this LwM2M v1.1 branch (see https://github.com/sbertin-telular/wakaama/tree/lwm2m_1.1) will get advanced because we are in the process of releasing LwM2M v1.2 and it would be unfortunate if the implementation work falls too far behind the specification development.
I am also interested to hear whether there is interest in integrating Mbed TLS into Wakaama.

@dnav
let me first say thank you for all the work you spend into LwM2M and this open-source offering.
I'm not sure, if I understand, how you want to continue. I don't want to force something nor someone nor offend someone. As many others feel, that it's better to have "fresh committers", I would go to start such an committer-election, as @ctron has requested in an e-mail.
@dnav
@sbernard31
@jvermillard
I would do so on Thursday, 01. October, Evening, if no-one objects that. So, is that OK for all?

@hannestschofenig,

it would be unfortunate if the implementation work falls too far behind the specification development.

At least for Leshan we have difficulty to follow you (OMA). Maybe a little part of explanation could be that sometime this is hard to get answer from OMA on not so clear parts of the specification or blind spots. I think investing more time on OMA github issues could help a bit.
In a perfect world, we(implementer and specifier) should be synchronized (we should start to implement version which is currently writing, not an already released one)
This way we could report you issue that could be fixed before you release the version.
Currently, we are de-synchronized and when  we find issue sometime this is too late to fix in the specification. Sometime this issue generates more effort for implementer and can slow us a bit more.
@boaks,
I have no objection (but as I'm not committer on Wakaama not sure my word is useful :slightly_smiling_face: )
Hoping the project will be on track quickly :crossed_fingers:

@sbernard31
My bad!
I always thought, you're a committer here as well. But sure it's, David, Julien, and me.

@hannestschofenig

I am also interested to hear whether there is interest in integrating Mbed TLS into Wakaama.

This something Sierra Wireless is interested in and whiling to help
@sbernard31

At least for Leshan we have difficulty to follow you (OMA).

IMO sensible standard body should follow the implementation and not the reverse (e.g.: spitting tons of doc which clearly not implementable as-is and wait for fix).

@boaks

@sbernard31
My bad!
I always thought, you're a committer here as well. But sure it's, David, Julien, and me.

I think he was in the initial project proposal, but his name was lost in the project creation process. If Simon is ready to code more C I think he would be a great addition :smile:

This is not about coding more C, this is more about having time to do it. :sweat_smile:
Already difficult to manage Leshan and  SBULB. I haven't time enough for Californium, I'm inactive on tinyDTLS and already abandon LDT :cry:. I don't feel I could add one project more.
But there are already, very active contributors which are identified to renew the team.

@jvermillard

@sbernard31

At least for Leshan we have difficulty to follow you (OMA).

IMO sensible standard body should follow the implementation and not the reverse (e.g.: spitting tons of doc which clearly not implementable as-is and wait for fix).

Allow me to reply to this particular comment. The work on the LwM2M specification at the OMA is following implementations.
Each feature from 1.0 to 1.2 is coming from a real world usage and the technical solution comes from what was implemented to answer it. OMA members then contribute to the standard for the sake of interoperability.
The best proof that the specifications are implementable is the several testfests organized by the OMA.

@sbernard31  and @jvermillard: Point taken regarding paying more attention to the Github issues. I will take a look at the raised issues and bring them up in our weekly conference calls.

Regarding "IMO sensible standard body should follow the implementation and not the reverse (e.g.: spitting tons of doc which clearly not implementable as-is and wait for fix)." I believe you need to have a healthy middle-ground. For the v1.2 spec we have had protoyping efforts for selected features but some features are exploratory.

The election of @sbertin-telular has failed : "This election failed to receive the required number of votes in the alotted time."
What now? is this the time to formally replace the current team and reboot the project with a new one?

What now? is this the time to formally replace the current team and reboot the project with a new one?

FMPOV, I think it is.

Now that he got elected, what are the next steps? I would love to see the 1.1 LWM2M branch of @sbertin-telular finally getting merged and then moving on with cleaning up the PRs, improving the infrastructure, etc. so that new stuff can be more easily get added.

I have now been successfully elected as a committer. In order to officially be a committer and be able to merge pull requests, I need to complete an ICA.
Since I was first approached about becoming a committer back in January, my manager has left the company. I'm working with upper management to get approval to sign the ICA, but encountering some resistance.

Hi @sbertin-telular!
Please let me know if there is anything I can do to help.

Project should be back on track now. See #488
I think we can close this one.
(Do not hesitate to reopen if needed)

IoTerop is proud to receive recognition for our contributions to the advancement of the the Smart Metering industry!
ioterop_logo (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR6t3pdrLV1-WJV7CgSs_W2XhpxF50svXnN7b8K-WvfrXNW6fgXXT170KhhW7vF_3T2L4q1CW30XVLd5nl6xCW590NrJ3BkGyBVJDpBZ34RwYdW8wV-cY6h6GhXW6ZgC7v1g2NqQW9kX4WX6Q4fTMN1NGlyJm_RGhW1G66qw2SqSG0W1620n85rjFczW3kmsg129kmv3W1PqR2W7s5nsNW6F5nF01L6PRVW2-CVNz5NgxKSW2v-09127ZZpRW9070L019BNwjW2vqTMS4dSjLLW9gd7Bg5W8KLdW4b4r0q79rTJ4W8jLc3n99z8yDW6Fx7Fg5XDYx5W4_snxT2GjHw6W1tYc0H1B1Tyv3dt-1 )
email-header-frost-and-sullivan-award (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR4_5mNXrV3Zsc37CgJBrW7qsCgG3sLm6NW1Vbyl95vBMLjW5sVQR-23_8tPN7cZGrgPbWHRW5tdQC33Q1yVTN3q3M4c7gGvRW8PjM895QZnF8W66YR2-8DTV5VW3WpxwW3PjCf6W4Mzn8l6-ntXNW3mT_DC3rRSDcVNfN2j8KYPZMW141YJ-8lstQnW7z1d8b5J3V6wW5XBb3B1L5nCjW5fq5jZ5_cCJtW9fzwN94Swf4gW5Ql1VX6m5ykpW8bkF4b7R7p_KN6DDZFv40lk1W1L7ft87cg3qZW36D0np18ybmHW8NqnLS6s8nK9W6v508X1_NYgcW81X-pg56Y_fWN8g_ctd4NdW9W9bxWvl1W1xp3N9lkpGRf-4vnN7CSc9Wpz83-W7m9DJd4zHyhcW4tc1B5657QbJW3244WQ1TWQh932Nf1 )
IoTerop Earns Frost & Sullivan Leadership Award
IoTerop is incredibly proud to receive the 2022 Global Enabling Technology Leadership Award in the IoT management solutions category for our work in the smart metering industry.
F&S Award Report Circle (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR4_5mNXrV3Zsc37CgJBrW7qsCgG3sLm6NW1Vbyl95vBMLjW5sVQR-23_8tPN7cZGrgPbWHRW5tdQC33Q1yVTN3q3M4c7gGvRW8PjM895QZnF8W66YR2-8DTV5VW3WpxwW3PjCf6W4Mzn8l6-ntXNW3mT_DC3rRSDcVNfN2j8KYPZMW141YJ-8lstQnW7z1d8b5J3V6wW5XBb3B1L5nCjW5fq5jZ5_cCJtW9fzwN94Swf4gW5Ql1VX6m5ykpW8bkF4b7R7p_KN6DDZFv40lk1W1L7ft87cg3qZW36D0np18ybmHW8NqnLS6s8nK9W6v508X1_NYgcW81X-pg56Y_fWN8g_ctd4NdW9W9bxWvl1W1xp3N9lkpGRf-4vnN7CSc9Wpz83-W7m9DJd4zHyhcW4tc1B5657QbJW3244WQ1TWQh932Nf1 )
"IoTerop enables utilities, solution providers, and device manufacturers to develop and deploy their IoT-enabled smart meter solutions rapidly and cost-effectively. IoTerop stands out from competitors based on its commitment to innovation, creativity, and ability to launch new solutions with far-reaching impact and application..."
Read Award Publication
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR4_5mNXrV3Zsc37CgJBrW7qsCgG3sLm6NW1Vbyl95vBMLjW5sVQR-23_8tPN7cZGrgPbWHRW5tdQC33Q1yVTN3q3M4c7gGvRW8PjM895QZnF8W66YR2-8DTV5VW3WpxwW3PjCf6W4Mzn8l6-ntXNW3mT_DC3rRSDcVNfN2j8KYPZMW141YJ-8lstQnW7z1d8b5J3V6wW5XBb3B1L5nCjW5fq5jZ5_cCJtW9fzwN94Swf4gW5Ql1VX6m5ykpW8bkF4b7R7p_KN6DDZFv40lk1W1L7ft87cg3qZW36D0np18ybmHW8NqnLS6s8nK9W6v508X1_NYgcW81X-pg56Y_fWN8g_ctd4NdW9W9bxWvl1W1xp3N9lkpGRf-4vnN7CSc9Wpz83-W7m9DJd4zHyhcW4tc1B5657QbJW3244WQ1TWQh932Nf1 )
Find Out What Makes Us Leaders
Our staff have deep expertise on what it takes to deploy a successful IoT project, and we'd be happy to share that knowledge with you.
Get started today.
email-f-and-s-award-alaska-circle (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR6N3pds1V1-WJV7CgJS4W1DKCTy2mnJKhW1cG7RJ6sF923W7HnMc17QCBnJW3vrjX54wVGRgW7KyF572k_wC7F7Z98vMxpG4W6JFfK29htlB6W1-83rT1YrHCRN2FM0rMT3R2JW6w-Jjj42s0CmW2lqsCW2sMwS5W1MlLcv4htWycMx80ywG-JtTW4Y4XtF1JSysDW8s02yM37Rj21W7BdnFT35NJ2kW8-vKXN58M0sJW6pJqrM5rJ9DDW2VmwtQ4NcFQtW3TLrk583y3_gW7hdyqZ72dBC4W68hgy18YpKZnW6Fqp0Z20BfzdW5rxVWT150ctpN4r5tRmRqmL_W6h3Ks05P5kZwW7VxnbB3jcrDGVKZMcJ3XMg_Y3qc51 )
ALASKA
IoT Device Manager
ALASKA Free Trial
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR6N3pds1V1-WJV7CgJS4W1DKCTy2mnJKhW1cG7RJ6sF923W7HnMc17QCBnJW3vrjX54wVGRgW7KyF572k_wC7F7Z98vMxpG4W6JFfK29htlB6W1-83rT1YrHCRN2FM0rMT3R2JW6w-Jjj42s0CmW2lqsCW2sMwS5W1MlLcv4htWycMx80ywG-JtTW4Y4XtF1JSysDW8s02yM37Rj21W7BdnFT35NJ2kW8-vKXN58M0sJW6pJqrM5rJ9DDW2VmwtQ4NcFQtW3TLrk583y3_gW7hdyqZ72dBC4W68hgy18YpKZnW6Fqp0Z20BfzdW5rxVWT150ctpN4r5tRmRqmL_W6h3Ks05P5kZwW7VxnbB3jcrDGVKZMcJ3XMg_Y3qc51 )
email-f-and-s-award-iowa-circle (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR6N3pds1V1-WJV7CgJS4W1DKCTy2mnJKhW1cG7RJ6sF923W7HnMc17QCBnJW3vrjX54wVGRgW7KyF572k_wC7F7Z98vMxpG4W6JFfK29htlB6W1-83rT1YrHCRN2FM0rMT3R2JW6w-Jjj42s0CmW2lqsCW2sMwS5W1MlLcv4htWycMx80ywG-JtTW4Y4XtF1JSysDW8s02yM37Rj21W7BdnFT35NJ2kW8-vKXN58M0sJW6pJqrM5rJ9DDW2VmwtQ4NcFQtW3TLrk583y3_gW7hdyqZ72dBC4W68hgy18YpKZnW6Fqp0Z20BfzdW5rxVWT150ctpN4r5tRmRqmL_W6h3Ks05P5kZwW7VxnbB3jcrDGVKZMcJ3XMg_Y3qc51 )
IOWA
Software Development Kit
IOWA Free Trial
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR6N3pds1V1-WJV7CgJS4W1DKCTy2mnJKhW1cG7RJ6sF923W7HnMc17QCBnJW3vrjX54wVGRgW7KyF572k_wC7F7Z98vMxpG4W6JFfK29htlB6W1-83rT1YrHCRN2FM0rMT3R2JW6w-Jjj42s0CmW2lqsCW2sMwS5W1MlLcv4htWycMx80ywG-JtTW4Y4XtF1JSysDW8s02yM37Rj21W7BdnFT35NJ2kW8-vKXN58M0sJW6pJqrM5rJ9DDW2VmwtQ4NcFQtW3TLrk583y3_gW7hdyqZ72dBC4W68hgy18YpKZnW6Fqp0Z20BfzdW5rxVWT150ctpN4r5tRmRqmL_W6h3Ks05P5kZwW7VxnbB3jcrDGVKZMcJ3XMg_Y3qc51 )
Would you like to talk?
We'd be pleased to speak with you. Schedule a meeting with our team at your convenience.
Schedule a Meeting
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR733pdskV1-WJV7CgSz4N4Fsh_r1sxDrW4KMtLy1VY2ZmVs7cM91GXj_XW55KSp972prdHW53rkS43mbVKKW390d2f6XB6LDW3v7DX016_5_JW8y9K8W4RpvxlW3Qr8mR4t7k7-W1RgKvq2pXSGXW2-5qft7gznM9W882kTq5dDVKtW4z3YDQ57jQMDW4CwpPm2g6PrfW8x8ktk8CRj6jW15jx8q23SZLRW1bhr2G51-wwDW6wklHM65xzl6W6S9BC_2l3_vQW3S1TB_5PkkdmW52Ktnm6XfL-mW37Tvb53_4jqHW94P4Qk2jdD7lM5jqjGV3BFVN3bQrF7SthK4W5MjtqK6JjdxnW1glhrq3Zg8J3W6XMDmm5s5jHdW6Gw2Fq4bWgdmW28fVlv5z9KD13jp11 )
LinkedIn (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR6N3pds1V1-WJV7CgGTJW5cy2471LpSfFW1JzjBp1c6wC3N2PzDPTgCRbLV9Hwn019x1DmW6CWd866qjTMyW8dmRDP4Mp9qKVQTnb49h2NvYW65KM0265mdrdW7MJTKh77TV4sW7fq3gM3dz4-2W3wQvmC4bkJNDW2v-63V8BzW0MW7jHBWM23l0RXW4vQs1n51Dnd-W3mQ0kF5Q9jMKW7pxN9b6Tmpg7W99wC8Q68bWZqW1-4x-M7CjDyPW7fHqQX6rmDKVW4zNcKV78R-6kW80QVTv8cQ9LPN8FN5rzNdCq1VlpmNZ179cZvW8hKwp_8-SncZN4pVjZ4V87kcW9fYvDr298_XTW6JlTks3yjC2RN8CVqpTZvVHp3dbl1 )
Twitter (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR6N3pds1V1-WJV7CgSN5W65P9Qk7jlm1pW5cP9Hp8S3DhqF891WSWsXCMW4ZD7H66fD91gMp11cDTCJ5xW3G8vHd4Djzw8W5Wp7fY3bvpntW8-PWk357H13_VnL86C5xbM6HW8nGtP76KYffZW7wZJF12PfHvRW4djLNG20wbRDW3fB_WY1dvmbkW6X49vs3xksmDW6-Q0sV15f0l9W46mkvy5vz57PW68l4gb45__k3W1jGDXT8p2YGCW1w9-Ny3f5G8vVjzk0B37N1FNW1kQ78h2F1WlfVq5vj-4KNtQYW5DntT24jG5zbW8QKsyQ1ZMHR9W8dx0x75C5_YCW1vzyH54tKW49W8Rr0Vy5W9lKpW5G9hSv12gV3d315y1 )
Facebook (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWhPFT7MN7BhW3xTbl_1L2n3xW9k7knf4LV6s-N8BHR6N3pds1V1-WJV7CgZw_VtYqsQ6z-8gqW1g3dgk8XdTFRW4XTqTm6fkjnYW58HTrr62LX3fW2lslCY5H3_QZN8B2H2Tk65nyW49QplY5MKkLvW3S02NX5Nb4l_Tsjyh4RCkgYW4H3rMv2nF63hVW9PJB30M4DdW65KjDZ7Q4pPqW77StnV2HsBCsVL7cbD7Mrkm5W3x41Xj5143WfW8k4CSF1ThDZtW6YtT3k7wJhYSW7W1Xx95_JfGfW1ZpHf01r_sVZW3p_FM91khQ3qW2d3fsf56Scg2W113JyW1yMJc7VbxyRj18z32_W6tp12M86062yW8y6Mc61TFrJpW58DF-s79z9YBW21hx1t10k1KHW63c8y_8_b6LX31YM1 )
www.ioterop.com, 621 Rue Georges Méliès, Montpellier, Herault 34000, France
Unsubscribe (https://email.ioterop.com/hs/manage-preferences/unsubscribe-all?languagePreference=en&d=Vnzr3b6NRQzXW49KwbH4r48VrW3P0R2g3zkz0xW3R41vr21k00lW4fhF6R3LG-nsW3LG7NQ4kBrC-W3Q-cG64rxk1cW2m8Bdx3-1rV9W3T3R4J3BKSWwW3_fV8V4MxMllVmWcPL5ND7YFN62ChS025zR2W7dtHxP7qjc68W8DtDYx5Fd7WyV1yf0N30Wb37W8Twb-Z6N-pzwW8RY1C01SxW8C24k3&v=3&_hsenc=p2ANqtz-_E3PHHkpiPGJBfvum2b9xeWd1Rs7xhb7KJLj1_kxgy_JdoVP7QcB8b_qIJ0wzvoAuRCrBMNrI9a_GTkecNgnzGfkgwqVVi7EvjWM-YDWb3U2ekumSOR67fhzmhvbHNaiZrMZoN1SKJnNajN1664TAvv_HFQg&_hsmi=218016782 )
Manage preferences (https://email.ioterop.com/hs/manage-preferences/unsubscribe?languagePreference=en&d=Vnzr3b6NRQzXW49KwbH4r48VrW3P0R2g3zkz0xW3R41vr21k00lW4fhF6R3LG-nsW3LG7NQ4kBrC-W3Q-cG64rxk1cW2m8Bdx3-1rV9W3T3R4J3BKSWwW3_fV8V4MxMllVmWcPL5ND7YFN62ChS025zR2W7dtHxP7qjc68W8DtDYx5Fd7WyV1yf0N30Wb37W8Twb-Z6N-pzwW8RY1C01SxW8C24k3&v=3&_hsenc=p2ANqtz-_E3PHHkpiPGJBfvum2b9xeWd1Rs7xhb7KJLj1_kxgy_JdoVP7QcB8b_qIJ0wzvoAuRCrBMNrI9a_GTkecNgnzGfkgwqVVi7EvjWM-YDWb3U2ekumSOR67fhzmhvbHNaiZrMZoN1SKJnNajN1664TAvv_HFQg&_hsmi=218016782 )

should I delete it ?

Yes please. Sorry for this.
I'm investigating to see how this email could end up here.

To be frank, sometimes I miss really some advertisement demonstrating the usage of eclipse open source projects.
But I don't think, that an more than year old closed issue is the intended place.

Deleted.

Join us for this unique online event on 8 Sept. where we discuss LwM2M and its capabilities from a developer and engineering perspective.
ioterop_logo (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpb_V5mNXLV3Zsc37CgSnpW1lycCL2gnlYnW1QrLjm6jwp-zW1c3s4R7RrXysN24F51QRxz6jW18nLBR59KTw1W1PJCj89l1rCZW35wtQ63BFl_7W3B5S1k8scFTJW4fnB9K8lzQl6W189J5B7YYHCgW6_3dFZ1cQ6BPN1FdBrJCR8rFW76wrXY8rrNKFW8SsZcW2NhQ7tW2kWGqP8Xt_zbVnK_Nn5BtTCyW54NLNm3k_8_7W6c58VM1jC157W97vbnV2DxCGRV9vDXH6FH45zW18ymlt8mp_d0W8w5NG_6hgX1MN5SQcw1LBX2QW4FXnNS3JSkYpW5QW-MT3LkBkwW54PM4y2GMSVMW5StS0w2MWGJKW5s0r3z3dJ2q4W1_0cF-1xVrb5W7Gcw3L7_qVyRW5Th4FK6Zg_wmW19JbJs7BKzvpW5W-WW37n_DzpW4WRrjK7m4F_-3jmh1 )
email-header-dev-forum-unlock-your-organizations-iot-device-management-capabilities-with-lwm2m-2r (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc1m5mNZcV3Zsc37Cg-hXW67SL8S6ppH05VC3Pjd7h6HQFW31q5NY2fZPQQW2fY0pW3CVT8vW2xy8HK2Lzth7N7_JXc8bC3XTW8ZRHH14YCC72N983RnS9bxSfW9lYzb-2HnDc6W7pCR098zc8rgW4BCB7P7-_HSTW3gf6rf7B94CqW5fKWmw4Mrm9xW7C2sqP23lHG_W8M4qp2658gDpW9bRJ7D39_wT-W3zqVwt232Dw0W3NRqZY8kXl58W9j68sw3Kgc0GW4T6_Pp6Qzj0BW4PRK0X7P0-WmW4dgszV6QQ4HWW13hVsZ5-sR6WW204mG48RycsqW1Pv5Wf4lPLpyVnfVY73ZBlN0W4rbkd14xzDKBW45mM0t2QbvChW83VTCn55cP-nW5FKptz5_bK_QW7cpFrH7xp5jsW2xhwg51BQmFMW2F_3H46rwN2tW6dYYFR1NQftjW7WknY-7gK2zSW7xk3PP2FcRPsW5W6mBf30_S52W8JLjsP4v3fq1W22SXQx87GbM6N1FGj_xdF4TFN3kLXlrH6gTDVDnTvk2s75ppN7D4wSvnL7jWW5TPYyl48-N9s3kZn1 )
[Developer's Forum]
Unlock Your Organization's IoT Device Management Capabilities with LwM2M
The benefits of using the Lightweight Machine to Machine (LwM2M) protocol to connect and manage IoT devices are noteworthy: reduced power and data consumption, firmware over the air (FOTA) updates and using latest security are just a few of the highlights. The freedom of not having to rely on a proprietary technology or build and maintain your own network is why many organizations looking for a sustainable IoT solution have chosen LwM2M.
But what exactly is LwM2M, and how does it stack up against the other technologies, such as MQTT? How difficult is it to implement, and what are the implications for an engineering or dev team? Join us for this free forum on 8 September at 16:00 CET and discover the potential that LwM2M has to offer.
Register + Learn More
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc1m5mNZcV3Zsc37CgQLfW8s1FBq107WGKW3mpsD7146M5fW2LVwP010W_-QW83P3L6698DZmW7qTlHf1WRh22W4cFj232KPVs-W7FtxLk34Jys_W929ttC597s60W5TK-FG8RpV0cM1CpCQHRh58W6lmBbY6TblhrW40ZPKZ4Qkn5KW6x8FsF55Lt-2W6pmV_H4lHnLFW4M07Bh387T_ZW9711tS8Bbjg3VQtgkC5vW_7nW8_3QzR65-mZ3W3wLPwN8Jj-PQVGzyZc28RF70W2v7JrX8vZVDvW5NwwhZ6js_qtW5KqZYD28dP3ZW4TWW9529Kv-NW5_h7jm8tKQymW8lVfzX63Hzx-W6slMpL1dxKZdW1BPTLr5n4Z9gN79VRzycb6bSW3NcyZd7G5Ht4W51hNdg4F78gzW5LsNXm5SlzxlW2h1_V41n7LhyW8hKjzV3mrHHsM_XRBGQLNpZN773NfPVLS0mW65qdd05Hlw_CW3N_Nx93c_nC2W2_CZdd17P5lwW8lmw924H7f9tW1NRVJH8z9_T-W1QgSyq3CYt5CW3_6wkR8G8S-_W8jr-lF6zV7V13pc31 )
Webinar Speakers Include
bio-photo-circle-harald-naumann (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc095mNY1V3Zsc37CgXTNW1b61ck3KXy-bW7MFnTl897YjzW1czFmW4fCxQbW54TKq06yp_NTW5w8jhr17yv-mW1yc0Mn7TVzy2W3DQ4Y26t1zKgN8GRvfgd3mjpW1F2BmR5jHp1RN5YlN9XjdB9YW6GcBZN184w8kW1b_RnZ1SX1XlW5r584B1xhJy3W3x1_cB3b8WrHW87lNRR2YD2LTW1HwzFG7mB1C9W4kj8kK65JC4-W4krfl_72whKcW8-tshB8l0Zt8N5MX1BpWF57dVDHVml43q49bW8pGzyk4nYs1zVDL6lG8KHYCWW6yBg1G2QSZ7SW644Xg54YR3W0Vkk6T72h_XV7W2Gr9V94Bg9GpW76zH6l4wg-2SW7CQ4NF82-mW8W8v597k58gKt9N2Sxw85vbdBtW1RDLVK8H58WvW800Sg28KhsLDW64FgYr5V5dTVVJds682lPywvW3c3zP68qCPfb35Yz1 )
Harald Naumann
email-logo-crout (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpb_V5mNXLV3Zsc37CgGDSW2twTFy7jndQtW2skdft8R2v5pW4-FvqJ5xwjsHW2N2r-F55GZZ5N2NNVwhSpG4-W6DDQRc3zGK2VW314hW567xbxcW5Rg-0w47ZC5HW8Ky9QJ18QslYW8tW9db496TR3W8Yl8yx62z2gGW94CDHT5ZMCpjW1Lgw_05VgFdhW783pVj4dG2lTV-fx6x30b1JjW1Mc7_-5f2tClW7RjFBZ4_TvnrW9dmcnF9hG5SbW3PJ1zw60tvWMW6-GWnN74QGYmW6_PPzg8S4R4WW5pFDKC7L3nr9W7hB1g299w1PyW1pYwgT7hgYN4W6WpDFK1yBqvxW4f-PWd1Dtch_W5ZNZH21q6S7cW57YQLB2RLPVXN5gYgBYzPNJfW8kTQSJ6BsDflW6QC9Bk5XGl8xW1BX5p18YH1g_W8rfDBt8R7mJyW5vHScT51pmFp3mc71 )
bio-photo-circle-friedhelm-rodermund (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc0t5mNYkV3Zsc37CgzSmW8VV46y5V4CzVW3ZMky06Ln2CmW8FSSKN4dBrz3VvTcqS7YKP1nW671FH76TQjq_W7F65kq57Y_xhW7Q3xj_7BHy46N3cVJq3sLps2W8zcZjY8wv_FHW2z_61t2LtVrbW1MmzQK9fqNcvW1gJSJm6krF4qW1QXptY1zFV0-W5wfGLX4S_JTqW1rkV8T7PJG3TW5Zs92H3N7jYHW5P340N6HJVHzVQ7CVB4zV5pcW7QS7Bs7ppq3MW8sY5VC3Hv2rpW6K3Q5g7c7xYQN7gR-96qJX1pN5Yp5r2GGGXvW33Cbvg4tXSMrW3FS_G98fD5thW70cVNm80CpyDW2J-pKk612JlcW50-Jw376mTgpW6028Rf8-fmJXW56zT6D1246mxW91XM5R47HhvvW1lmWD28lMnPkW2qfVL98vvmcBW3gk6FW7PLFB1W5yjWbX8hxpfdW7sfwjw6j--DTW8kV6tK6FwHX3Vb_QfP1Xc_wD3bGp1 )
Friedhelm Rodermund
email-logo-iotecc (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpb_V5mNXLV3Zsc37CgHL_W33HZH14b9-XKN2sBNQxDtBWmTL9R_8w9PPMW8F_b9x7c35PdW6TJqkx8l-65WVy7S584CCV2ZW4lQs3q7X8qq6W70_7tW7ZHR4MVDjn1J4ljy15W896wvF4DyW7dW8r3g9W2ntxmfW7MqtHJ6y1tG3W6_6sLW1sCs_-W8Db1y63428PxW1Pt6_x5FfJm0W7Q9Cpk2Dsn5lVFx6Y52TKJdNW1CtKsf658hxVW7nsYG13GCXgRW6XSht_7DFvKJW3W9FFZ2K3xcTW8CVl2l5tQXPJW4B-MHp4gJNdJW4YhBYx83NcwcW7p7W-53CDPLGW74mzb_2yzsdpW5FhnHk6SZh3kW49vqwK3Jd9H5VnW8wn49z84wVn7fxS9kQZjDW5TBWMM1f0FSJVL7NFl3jyd-7W32StwZ4vjG8pW6BstMg8BvSNZ3j1x1 )
bio-photo-circle-david-navarro (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc0t5mNYkV3Zsc37CgNvyW7JJNcW4nPTbyW2057rx45qlLGW4hK9JR7XCw_ZW3nv_Vv8PMfFYW5yF8Wp2T8FTnW27HnpP1CzRnmW4DYlzJ2YqzkBW1lHcJZ5wWvm6W2vWw28181QxrW9kr7lK53T5sMW3bLBBp3xzrnsW6Zjm4W4v2f2DW4z0QH04WY2NqW22K7yS8qZYr1VN7_TT9cBhb_W91w8np2QN-XhW5nJt5w278lsbW4jG2lX6Dv8sLW6PZflM1PJkFrW7g0MZ44BlqCFW3rcgXZ5yrLqqW4g85Yk2TkCj6W1Z1Jd54rZ62NMghbCXvbgdmW4LV3mD5JDg-zW6cGydb38Gr5MVGQ22X24BM78W2MHbPG74zCKQN47KT_fVY1djW4FYJ0Z18VxDMW64MtVg5C9BfrVl827f6zcLgVW2BJDG54p78gKW7gbzQ26GXTVnW2kG-nJ17MZ9cW99ZS7y84tTd7W1yr7Xr98DHSLW98qhHc5T__rX3hkF1 )
David Navarro
email-logo-ioterop (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpb_V5mNXLV3Zsc37CgSnpW1lycCL2gnlYnW1QrLjm6jwp-zW1c3s4R7RrXysN24F51QRxz6jW18nLBR59KTw1W1PJCj89l1rCZW35wtQ63BFl_7W3B5S1k8scFTJW4fnB9K8lzQl6W189J5B7YYHCgW6_3dFZ1cQ6BPN1FdBrJCR8rFW76wrXY8rrNKFW8SsZcW2NhQ7tW2kWGqP8Xt_zbVnK_Nn5BtTCyW54NLNm3k_8_7W6c58VM1jC157W97vbnV2DxCGRV9vDXH6FH45zW18ymlt8mp_d0W8w5NG_6hgX1MN5SQcw1LBX2QW4FXnNS3JSkYpW5QW-MT3LkBkwW54PM4y2GMSVMW5StS0w2MWGJKW5s0r3z3dJ2q4W1_0cF-1xVrb5W7Gcw3L7_qVyRW5Th4FK6Zg_wmW19JbJs7BKzvpW5W-WW37n_DzpW4WRrjK7m4F_-3jmh1 )
Would you like to talk?
We'd be pleased to speak with you. Schedule a meeting with our team at your convenience.
Schedule a Meeting
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc0t5mNYkV3Zsc37CgJKQW8X901b1QQbB5N3tWTdnvXJ_GW6LmfGc39XLcpW2rtbKc2jXQ-5W5gsppG2dkZDLW6c4gZw5Dy-rXW1dR2mZ3Vbg5xW6rl8CN9h1FtsW1P-Xd036S1t_W8YVN3v8hxVjDW8BlX5t5wSRYWW8SPY8-7KRbK4W5lM1lP7z6Xx_N581SBQd2QPlW4XVVKc6B7KQJVZMGZ46JJgNSW59wWbY1ZmtTHW7sGZKt6WcMCTW7KXR9w1yxc4kW1BmLDQ61q0nkW6CSxmy4hg9b2N7k9L9v1kjZRW1cts3W1vS3BgW27B8006S8MmnV8hwDN5gNZYXW6n9J8s1bfVX8N5QlFZf_7Fx_W1_hvNj7s_8HBW11pbWd7cnKx9W7N98dD93GFxtW2J1zC14X7qT_VmwTP445vwrbW2SC-K_7FDgbfW3Py0dd3RvZ-hN3RdyvvHQYhLW62p_5D7j1bBgW8mv6z47Fc7MwW8kFZHz2GwT143jj31 )
LinkedIn (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc095mNY1V3Zsc37Cg-4yW4LCsTQ7rKpWKW5g_z0g5gq-yNN4s4XVc2H1CZW4tZkp28qbs9_MM9kvHyv-xbW1ghV6b18SZHYW5k7NtT4m0hF-W8kDRP87_MqX4W8WY5KQ1vLFWxW1QLmJT2Kv5YpV2lVdG5q8-hkN1HnSW0jXZ2-VPQX_v5sytl3VqpG5z8d4xZwW3yrgtf6_HkKQW6DPlX81-YkCRW888RV_29Z_SkN1kVfP-DdZKgW2DLwPh4-Ss3YN4m0yrjygXftW5zkxhz5sKppzW3HPZNy3P22QZW1KbyPt58bnWSW2G-mpx3dspglVjWH_97BlVt6N2S3YzRB_yXwW77H-744ThSkzV7g55M7lk4JyW2l5YMV2c7PZlW8chYk_8KL9p0W5m2rN915dCHkW3Q_2l218S54JW1sFrV73FDBtGW2STyMT2L89ktW7RWQhv3-YhlyW3qTlLH3pDlRl3dh81 )
Twitter (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc095mNY1V3Zsc37CgTRkW4XvcpW8P7XXBW7W8D4n7dRMCLN9j5byzHnGcVVFWchT3MMGQMW4vYhbF2-PzgxW6Sf9bw3qbMs4W4vPQX-169K3dW4mfQd_5pmXmkW2lYmpy7NT9V5W6yZxY88jHyD1VRsVwj6zVgBRW36tlmp7ggRs3W529nVk51tRYRW2SGcqP56g2KXW8bPS1y4XfSzwW1rNGXF7rGQChW3RqMRM8JlVjzW1RG0xV2RDxT5W2YZrTB3cXkbNW90ftJc665fJJW7LfGQD22nB2sW30qC3Z4KR60nW83c-4x6z3XQWW5WT_xp5K5jwzW6dYK7c7Q4b9XW4gbrf74dgbkTW5xppn0307l2nW7pB6T31lXryRW7Nk6tn8n4Xy0W8LKT0h701S3wW2t56yL6dpZs1N22sHVWr93djW11psgf2_3k3jW1MJLkY9kDz-2W8DsJ2b7Cylr5W17SBXg2zWZP5366z1 )
Facebook (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VWJwXw6TW_V3W1s5MmF8D0V5nW67tPB74Pk_c6N2bpc095mNY1V3Zsc37Cg-jxW6_3V5l2JC33GW7VNkGH82Fh8qW7M11m_74NyFmW8FmVvY31KK_LW1vwg-c7K5HRsW5xRkfc4v7pMXW6R22w95PD16bW2MHWG17MVjtkW3PnG8S6wwyjYW2KRNnw2cwW1hW65D3QZ89p9wrW32t58k23b2SGW3sYVd55Qsbx1W7CwdXT4KVjLzW404n6s8LbVjDW8wGdDg6n0TpKW7-wWcL933qFMW6gBJVs47-wxBV4XWpN65fnk9W6gSrQ572XZRQW9kj8wl5KsB99W8FD4kc8hCxt6W1JRJZf4cvlJ2W7GRvWV6w-RjQW3G_8kS48MT-4W63kmNx2BbtJ9VqR6H86Zz8bVW8xv-qk4m7Ww4W8L2hhk1sxQCJW45qTGg8MH2P0W7SjJsB5GZCBdN8rt9JQvRcvgN1ZdYW1mN4sfW4zT7z083SX0pVlCpb791t-7tW690D6V8PtzJ934X51 )
www.ioterop.com, 621 Rue Georges Méliès, Montpellier, Herault 34000, France
Unsubscribe (https://email.ioterop.com/hs/manage-preferences/unsubscribe-all?languagePreference=en&d=VnzSxR6NRQzXW49KwbH4r48VrW3P0R2g3zkz0xW3R41vr21k00lW4fhF6R3LG-nsW3LG7NQ4kBrC-W3Q-cG64rxk1cW2m8Bdx3-1rV9W3T3R4J3BKSWwW3_fV8V4MxMlmVmWFdM5MWYy-N5MR9GW25tQnW9gWYzw85_vB7VWQBjh8KYxDxMXk_7QbvV00W3YK8Q04FgN3DN6sPZKFpDTC33gfV2&v=3&_hsenc=p2ANqtz-_1ZRpq1YrA6ztOMpkLSP_n-E2peKP8qHoOb9d-6RAxU148CIXySL5jRP7BRGPkiKk-GdLygDVQWhlxaOS5PQ351xQGM6o7AVI7DaVvRTob1VxlVad_SyTrsOOc5dYyRthZcX7k0q4ZqVieel0M7eiIOby23w&_hsmi=224359241 )
Manage preferences (https://email.ioterop.com/hs/manage-preferences/unsubscribe?languagePreference=en&d=VnzSxR6NRQzXW49KwbH4r48VrW3P0R2g3zkz0xW3R41vr21k00lW4fhF6R3LG-nsW3LG7NQ4kBrC-W3Q-cG64rxk1cW2m8Bdx3-1rV9W3T3R4J3BKSWwW3_fV8V4MxMlmVmWFdM5MWYy-N5MR9GW25tQnW9gWYzw85_vB7VWQBjh8KYxDxMXk_7QbvV00W3YK8Q04FgN3DN6sPZKFpDTC33gfV2&v=3&_hsenc=p2ANqtz-_1ZRpq1YrA6ztOMpkLSP_n-E2peKP8qHoOb9d-6RAxU148CIXySL5jRP7BRGPkiKk-GdLygDVQWhlxaOS5PQ351xQGM6o7AVI7DaVvRTob1VxlVad_SyTrsOOc5dYyRthZcX7k0q4ZqVieel0M7eiIOby23w&_hsmi=224359241 )

I'm investigating to see how this email could end up here.

@dnav, it seems the problem is still there :)

Learn how South East Water is bringing leadership to the Utilities market using innovative IoT and water saving measures.
ioterop_logo (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp1c3kWF5V1-WJV7CgFbvW1X6Jf81cBM94W3MZ6rr2sQd8-W4VLB8T4tfhX7MpGM-TZLbmtW1DgkHz5gR2hpN8BszYnM8GMBW8hKRGn6H3Gx9W7JQdp31F2skGW4hD_kK55VRffW1dLZlr71fQCRW3nn-2v9dgj6hW7PYCtL8Mv31LW2l2_RX5bqFnXW56xzzp4r5vMPN6GpYVhx43jnW8-CXNK3Q3MKxW7QJhF74rwb_7W1xKJ1h1-qCjTW5L-Jkg7jjQW3W8RDhxG4yPzVjW67yWgs74qh5PW1J7Db31Zl4y93c-x1 )
email-header-from-our-blog-july-2022 (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp1w3kWFpV1-WJV7CgZ7tW4nvMhX8wpbZYW11xvwV2JbhgNVvH4YQ46l7V2W9cDMBK5XqQ6KW14Y0q71jhXLmW25t9CD4dtwkwW2wx0yQ1QMYtWW2xCntK4WjxTdN6pFg8jhP0fQW44Znr01D96zcW7nGP_F5DhGpjW79Pwt176qz_YW7tTc8k5nxcScVXKDWW1gqzPlW3wz29l4L_1bcW8LdcVB4HTG8rW5sqhr94Wq663W1rqRDJ7Rtn93W3yBrG933lsbyW36lY_k8n5R6JW7-xtLT5MHmTCW7JnMpL8B_N4cW1BtdQK10w-VsW7HnJ7g13V7Jz3kcd1 )
From Our Blog
Don't miss our most recent blog posts, featuring a visionary use case from a major Australian utilities company (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp2p3kWGhV1-WJV7CgSF9W5hblkS4MG7f7W5-63hZ7MK9BhN934y7SfSRF_W2kd6Zs8qZCLzW35rmjW70Frt2W6Sb7f11Sz0vSW3_K49t4H3wFNN54KL2J1DDlsW7H3mRk80rK07W563Xvd90lKSjN3-_6-JFJDCwN2JJ2bFjw7qzW34FddR3Vn0XSW16bz9K7YZYP7W2zmxpL8LnJKTVt91Gv6K0pzTW5TNLTz1Pvtz1W3pHfjD5rBSkGN4vdm-zlySYJW3nPTz03JG1P1W7f2Ry41ss4FWVBDGm72stbFxW6TJLg64d8_04W3WsMLF199L4yW2cNGJy58jDzjW2JynH480tzflVr3T8s645h2SVsy6QY7TcKZTW6V1wss3-KGxFW8KnJ5P6BTxMw2w11 ) , an overview of the benefits of Cellular IoT, and Counterpoint Technology Market Research's perspective on IoTerop's offer.
Why IoT is Vital for Water Utilities Struggling to Meet Demand
email-from-our-blog-july-2022-img-1 (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp2p3kWGhV1-WJV7CgSF9W5hblkS4MG7f7W5-63hZ7MK9BhN934y7SfSRF_W2kd6Zs8qZCLzW35rmjW70Frt2W6Sb7f11Sz0vSW3_K49t4H3wFNN54KL2J1DDlsW7H3mRk80rK07W563Xvd90lKSjN3-_6-JFJDCwN2JJ2bFjw7qzW34FddR3Vn0XSW16bz9K7YZYP7W2zmxpL8LnJKTVt91Gv6K0pzTW5TNLTz1Pvtz1W3pHfjD5rBSkGN4vdm-zlySYJW3nPTz03JG1P1W7f2Ry41ss4FWVBDGm72stbFxW6TJLg64d8_04W3WsMLF199L4yW2cNGJy58jDzjW2JynH480tzflVr3T8s645h2SVsy6QY7TcKZTW6V1wss3-KGxFW8KnJ5P6BTxMw2w11 )
IoT-driven smart water solutions could help optimize water scarcity issues, but they will have to be standardized to be viable as one of the biggest water utilities in Australia is currently pioneering.
Read More
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp2p3kWGhV1-WJV7CgSF9W5hblkS4MG7f7W5-63hZ7MK9BhN934y7SfSRF_W2kd6Zs8qZCLzW35rmjW70Frt2W6Sb7f11Sz0vSW3_K49t4H3wFNN54KL2J1DDlsW7H3mRk80rK07W563Xvd90lKSjN3-_6-JFJDCwN2JJ2bFjw7qzW34FddR3Vn0XSW16bz9K7YZYP7W2zmxpL8LnJKTVt91Gv6K0pzTW5TNLTz1Pvtz1W3pHfjD5rBSkGN4vdm-zlySYJW3nPTz03JG1P1W7f2Ry41ss4FWVBDGm72stbFxW6TJLg64d8_04W3WsMLF199L4yW2cNGJy58jDzjW2JynH480tzflVr3T8s645h2SVsy6QY7TcKZTW6V1wss3-KGxFW8KnJ5P6BTxMw2w11 )
IoT Industry Converges on Cellular as the Wireless Platform of the Future
email-from-our-blog-july-2022-img-2 (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp0k5js6pV3Zsc37CgSd8N1Dpdf3R5pDdW8V2-Xm1r3w2fW4Z5K-n5BcJ0ZW8x_8ly8yXSYhW6DVz5z1Fy2vYN8x41lPgfdL5N3tl-3HycX_xW2SJ0984Hlxt-W7S6B7B39QsC9W2fhzFn2D02SkW22LlhM6C1ZPsVh95fz8kyhBrW704s_Q7nyw9YVgcxYg35R1ryW9k0KKP3pX6sdW7PcFcC93nkjGW8GYDlS9ksYnYW6nz3JK25FX_jW4g9lWj1HhwxgW6Mndp74JT7S-N4Kb4GkNh2PvW8yznv03Jq2S-W3rSg2g9f32VnW1P_rYV8Ck0RJW8SH4bH2Mlf5qW77kF6J9gbC27W6ZbcmJ2_FRqfW1XZZCc2XBSPSW5dWSRq2HXDl6VgqjB47G_QtBW6X7-Fm3TcxP1W7dND712Mv0Qs3qhp1 )
Recently announced changes in France around LoRaWAN will cause pain for customers in the short-term but could lead to a brighter future if it leads to more standardization in low power, wide area IoT networking.
Read More
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp0k5js6pV3Zsc37CgSd8N1Dpdf3R5pDdW8V2-Xm1r3w2fW4Z5K-n5BcJ0ZW8x_8ly8yXSYhW6DVz5z1Fy2vYN8x41lPgfdL5N3tl-3HycX_xW2SJ0984Hlxt-W7S6B7B39QsC9W2fhzFn2D02SkW22LlhM6C1ZPsVh95fz8kyhBrW704s_Q7nyw9YVgcxYg35R1ryW9k0KKP3pX6sdW7PcFcC93nkjGW8GYDlS9ksYnYW6nz3JK25FX_jW4g9lWj1HhwxgW6Mndp74JT7S-N4Kb4GkNh2PvW8yznv03Jq2S-W3rSg2g9f32VnW1P_rYV8Ck0RJW8SH4bH2Mlf5qW77kF6J9gbC27W6ZbcmJ2_FRqfW1XZZCc2XBSPSW5dWSRq2HXDl6VgqjB47G_QtBW6X7-Fm3TcxP1W7dND712Mv0Qs3qhp1 )
IoTerop in the News
Article by Counterpoint Technology Market Research
email-from-our-blog-july-2022-img-3 (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp2p3kWGhV1-WJV7CgMWHW5NKLV-6nHbcrW3KWt1w29hHKDW5qfWBS4n-TYFN2PTRplnpZymW480JL74chjJ8W37svRc3F6WchW8MmDmT3yPN8xW2Z0JdQ3bkhfXW7Hxpb24T13Y8W5f8vfK8fnVJRV7knG62FqQgLW8CHdSj1nlVmcW3fBv7r4yWG8sW4kt3vm8C8bXGW6dKLfN5zTdZmW3BYNr-4d1ZXgMYHZyJlXHxKW5hHjvv94tMzQW2MHD8s1975w9W4vwW9W1mwhpqVsNg8z36bSvnN4H6JVH6SnsGW85r2J758PzPQW6jw0G-4jNxBZW54HyTQ1G27sLW7GdZ5B5gLQmWW2Hntbq99bjn9W4HC4zP5zC-hhW3l2rW653135XW41v4Kq71HvJ23fx91 )
IoTerop Betting on LwM2M for Massive IoT Adoption
The IoT ecosystem is maturing and the entire IoT module/device connectivity to the cloud is now managed by IoT platforms. The IoT platform space is getting crowded as players have just started to capitalize on this blue ocean opportunity.
Continue reading (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp2p3kWGhV1-WJV7CgMWHW5NKLV-6nHbcrW3KWt1w29hHKDW5qfWBS4n-TYFN2PTRplnpZymW480JL74chjJ8W37svRc3F6WchW8MmDmT3yPN8xW2Z0JdQ3bkhfXW7Hxpb24T13Y8W5f8vfK8fnVJRV7knG62FqQgLW8CHdSj1nlVmcW3fBv7r4yWG8sW4kt3vm8C8bXGW6dKLfN5zTdZmW3BYNr-4d1ZXgMYHZyJlXHxKW5hHjvv94tMzQW2MHD8s1975w9W4vwW9W1mwhpqVsNg8z36bSvnN4H6JVH6SnsGW85r2J758PzPQW6jw0G-4jNxBZW54HyTQ1G27sLW7GdZ5B5gLQmWW2Hntbq99bjn9W4HC4zP5zC-hhW3l2rW653135XW41v4Kq71HvJ23fx91 )
Would you like to talk?
We'd be pleased to speak with you. Schedule a meeting with our team at your convenience.
Schedule a Meeting
(https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp253kWF_V1-WJV7CgZDsW5c4jPn94KT6fW5QnmNy1ylfp7W5w3T_G8Df7c4W772XN79d4nM_W5Jvvq21CmjHdW8dwh7d3tV6GfW6yf21T1J0cfVW5xTDx76xTry7N6KjNvB2jt76W2x_BMd1vRjpdW64TXzP2scJTfN3F7wysqy6wWW5-D_JT4K_0wyW5TSQKV3XhtkSV72G4H2LTsXHW2K_xjF5Cw6WcW3X4hcG3P9JdCVSM9dd7q5zN9W73cCgb4RbX6lW5SdFRy27h64TW4pmrDZ20ztWWW8_87MK5Z3RCwW4Jxf5l7xkvvsVjmJGS795KGXW6pDb2q8_-z2HW33jB9q8WNR7RW1NXtVX6fF9yrW595JHj4rgYzY3nnT1 )
LinkedIn (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp1Q3kWFJV1-WJV7CgJP3W6rXt_V23WKzfW69Zpc34yGtPQW5q9wtR98zQJ5W23hlyT3l9q3kMvYVV4llbmYW5Kgt6P6vL1nPW3HYcW51zjhtZW2F9M0r6vmmHRW4NftkD62G-gkW3P-CYt1fl8shVsXVGG65G6l0W4sqj1689tzHZW89qN0-1-bc8KW4QhZq97Bd3X1W4r3fND4DF4tBN4x19W0Kd_7xW8k95Bx5JhZrfN8gQ_JcFv0pWW8mM5Gt13pw5fW7HL3cr88B8n7W5_MLNl7WQYNHVGJLb_1TS72gW7CZWM5219d3YVRbrJ343FXw9W3PCNb56dsQs8THC7_8FgbDk360S1 )
Twitter (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp1w3kWFpV1-WJV7CgGQHW82ZY5t57ftc5W3sy6vp8lqkS6W5FlYS146NjvWW6j73xT8X1BNtW8sDmZg88_Gg6W58D5922WBrnkVZpvNZ2mSkzVW3DyThX5Kr_q0W6yNHv82xdXtXW26g64K4wFfLgW5nwYkV2KkHDHMPbSGNdYrD1W60chmS4s-FS3W7F9Nd16-MLsVW9lTvVK3xrD1sW7W6-3y83CXD8W5J28Ry49YnMMW7R9px_2nGxtKW3Rb9XH2wxc1pW6Y-p_q4s6pKmW2Pkbpy3s-lwCW53GPkG7XklBwW1f5q_d4ymvy1V9ksRk6bX_fN3p0R1 )
Facebook (https://email.ioterop.com/e3t/Ctc/ZP+113/cb-tY04/VVYzkB58m6kRW2X3YLH5D1HwPW2x7JLQ4MnYDJN2lhp1Q3kWFJV1-WJV7CgRybW4B3HYK1KhxCxW6FrTjK5LyZ7PW6nGctR2-QbQwVRT9ky1wFNTnW2F1Z0s38QmkcW3nY-BT2lzXnzW1b3XJ671KjDxW8n7c4j78VdxtW7_NDjd75gNhkVnfWDM92kpP7V_f-J_3CMh51W6GMt5Q7s7dHzW4FvX2Y6_g2PmW7GhCCj1m93B5W2Pn_t456yxg1W4w8Wt897_FcyW9b84kL3rjpKLW3F1s_l3qWhLFW932tpL2Fh3BvW4sCpP_1HJnfNW5tZW8c7dtglhW6xc_gY3c1dCxW5BnY1F3VJB1JW70NRVz4VXnNWW3ff_PD2SBQZCW4xkns-90Xqt-3dLl1 )
www.ioterop.com, 621 Rue Georges Méliès, Montpellier, Herault 34000, France
Unsubscribe (https://email.ioterop.com/hs/manage-preferences/unsubscribe-all?languagePreference=en&d=Vnzr3b6NRQzXW49KwbH4r48VrW3P0R2g3zkz0xW3R41vr21k00lW4fhF6R3LG-nsW3LG7NQ4kBrC-W3Q-cG64rxk1cW2m8Bdx3-1rV9W3T3R4J3BKSWwW3_fV8V4MxMllVmWcNG8w4bSGN7MhMGk25yk2W6bGb2_4R0YtbW71V4fH5R4VqtV1yf0N3067xqW475k0X32B_wQW6Lk0nt3V-0l32473&v=3&_hsenc=p2ANqtz-_CLi4vRCcd8db9aCM8kN7yjOQvXjKF7DggrZy5SRyHfTAEF5ZK8kRMaMU0vX1IjHRZAVO-zCl4ctG4AeGKflsg7_uG_nqAHkn5GiTCp3G8HK_tUJXTbJuzdW6i0NL26x5v4NLMrHkV1TcAAo3qNvbW0in8eQ&_hsmi=219317894 )
Manage preferences (https://email.ioterop.com/hs/manage-preferences/unsubscribe?languagePreference=en&d=Vnzr3b6NRQzXW49KwbH4r48VrW3P0R2g3zkz0xW3R41vr21k00lW4fhF6R3LG-nsW3LG7NQ4kBrC-W3Q-cG64rxk1cW2m8Bdx3-1rV9W3T3R4J3BKSWwW3_fV8V4MxMllVmWcNG8w4bSGN7MhMGk25yk2W6bGb2_4R0YtbW71V4fH5R4VqtV1yf0N3067xqW475k0X32B_wQW6Lk0nt3V-0l32473&v=3&_hsenc=p2ANqtz-_CLi4vRCcd8db9aCM8kN7yjOQvXjKF7DggrZy5SRyHfTAEF5ZK8kRMaMU0vX1IjHRZAVO-zCl4ctG4AeGKflsg7_uG_nqAHkn5GiTCp3G8HK_tUJXTbJuzdW6i0NL26x5v4NLMrHkV1TcAAo3qNvbW0in8eQ&_hsmi=219317894 )

I'm investigating to see how this email could end up here.

@dnav, or somebody from interop could you try resolve this or at least give us an update about this ?
On my side I will try to contact eclipse support to maybe block this @slurfer71 user.

Once again I'm deeply sorry for this.
We purged our distribution lists for any github email address. But apparently the problem is coming from elsewhere as we did not send any newsletter in the last days. And the one published here this morning was sent in July...
Anyway we investigate it.

@dnav thx for update.
The user was blocked by eclipse support, so this should not affect projects in eclipse organization anymore.
If at sometime, you think the user should be unblock let us know.


Add source infos: text chunk and its page number, possibility to hide document link

Hi, congrats to such a well-conceived app. I have a feature request. Currently when using sources, h2oGPT adds to its reply a score and a link to each document used. What I would like to see added here:

A snippet of the actual document chunk used to create the reply. GPT4all and localGPT both offer this.  It's not copyable though. It would be an improvement if the chunk could be even made copyable.
The page number the chunk can be found on. Again GPT4all already shows this, see the screenshot.
A way to deactivate the link to the document that h2oGPT currently provides (but keeping the document's name, page number on its own makes no sense, of course!).

Why is this a desirable feature?
Sometimes laws only allow to data mine documents and use them in AIs but prohibit to share the original documents in full. That is, if the GPT app is provided publicly, for example. That's why it would be great to be able to deactivate linking to documents but still have a way to inspect the sources.

Sounds like a great idea.  Right now I only provide link to source document, but a link to chunks and meta data would be useful I agree.

Thanks a lot for looking at it! Being able to access those snippets would also make replies much more transparent and comprehensible, the one thing basic chatbot replies are currently missing.

It's maximally hidden in accordion, and has the actual snippets now.  I'll add other metadata soon.

I tested it and it looks good. Thanks a lot for implementing this! The accordion is a good idea so it doesn't get too cluttered. Now I'm only missing the page number and a switch to deactivate the linking to the document.

FYI @PsychicBirdy you can see full meta data from database here, although  not in references yet:

Looks good. However, I thought of the switch in a different way: When set to False, I would keep the path and filename - without them the other source information is kind of vague - and only remove the linking to the files. So for example "user_path_many/HAI_AI-Index_Report_2023_(2).pdf" is still shown, but you cannot click on it anymore, disabling the possibility to download files.


Switch to go 1.20 for CI jobs

What type of PR is this?
/kind ci
What this PR does / why we need it:
Update CI jobs to use go 1.20.
Which issue(s) this PR fixes:

None
Special notes for your reviewer:
None
Does this PR introduce a user-facing change?

None

/lgtm


Allow drag & drop uploads

The entire page should be a target

This now works on the upload dialog:

But should work on the whole page.


Fix bug when the negate sign is before a space

Fixes #294
Description of the changes:
Ignore None characters while parsing the clipboard, so '4--6' would be correctly interpreted.
The issue was that isPreviousOperator was set to Falsebecause of the space character, ignore it solve the issue.
How changes were validated:

tested with different values

Hey @rudyhuyn I signed off on this, but could you fix the formatting before I merge it in?
Thanks!


Add session(venv_backend='conda') option to use Conda environments.

Also adds a session.conda_install() function to install packages with
conda, instead of pip.
Towards #199
Closes #183

Tested locally, but needs unit tests and CI tests. I'm thinking of using CircleCI for the conda tests, since it supports a docker base image. See use of conda in pandas-gbq config:
https://github.com/pydata/pandas-gbq/blob/9460ad6444ef750cbd46aae12897001ce72867ac/.circleci/config.yml#L40-L42

For some reason Travis builds aren't triggering anymore.
I'm having trouble getting this PR to work on Windows with AppVeyor. It seems there are many more possible paths for binaries in the Windows version of conda.
https://github.com/conda/conda/blob/3ca57b16effb02f961631305fcd941d96cd856eb/conda/activate.py#L511-L517

PackagesNotFoundError: The following packages are not available from current channels:
  - python
  - pip
Current channels:
  - https://conda.anaconda.org/conda-forge/win-64
  - https://conda.anaconda.org/conda-forge/noarch
  - https://repo.anaconda.com/pkgs/main/win-64
  - https://repo.anaconda.com/pkgs/main/noarch
  - https://repo.anaconda.com/pkgs/r/win-64
  - https://repo.anaconda.com/pkgs/r/noarch
  - https://repo.anaconda.com/pkgs/msys2/win-64
  - https://repo.anaconda.com/pkgs/msys2/noarch

No idea why it's working for Python 3.5, but not Python 3.6.

And now AppVeyor is passing. It was probably the --use-index-cache that was messing it up.
Anyone know how to trigger Travis? It seems to have given up on this PR.

@tswast I tried to get CI to respond but it seems the path forward is to close this pr and reopen :(


How to access router params?

For example, when we have routers like /foo/:id, how can we get the id parameter?

Sorry. it is getRouteParams.


ClickHouse calculate hash functions with seed = 0, while Spark calculates hash functions with seed = 42

Use case
xxHash64 function in CH behaves differently with xxhash64 function in Spark. Because in Spark the seed is 42

But in ClickHouse the seed is 0

Do you think it is possible that adding a new settings default_hash_seed which enables clickhouse users calculating hash functions like xxHash64 in the same way with Spark ?

duplicated with https://github.com/ClickHouse/ClickHouse/issues/46063
close now.


[Feature] Zigzag Ring attention

📌 Checklist before creating the PR

[ ] I have created an issue for this PR for traceability
[x] The title follows the standard format: [doc/gemini/tensor/...]: A concise description
[x] I have added relevant tags if possible for us to better distinguish different PRs
[x] I have installed pre-commit: pip install pre-commit && pre-commit install

🚨 Issue number

Link this PR to your issue with words like fixed to automatically close the linked issue upon merge
e.g. fixed #1234, closed #1234, resolved #1234

📝 What does this PR do?

Implements Ring Attention from https://arxiv.org/abs/2310.01889 and adapts Llama. Adopts the zigzag batch splitting scheme for load-balancing (see illustration below).

Use two streams in forward pass to overlap the low-occupancy output correction with next step's flash attn kernel. Carefully optimizes buffers to minimize memory pressure. Provides a experimental Triton kernel for output correction

Save comm & compute by replacing the gather sequence op in cross entropy wtih reducing loss

Enable TP + SP in plugin and update corresponding llama and command policies

💥 Checklist before requesting a review

[ ] I have linked my PR to an issue (instruction)
[ ] My issue clearly describes the problem/feature/proposal, with diagrams/charts/table/code if possible
[x] I have performed a self-review of my code
[x] I have added thorough tests.
[x] I have added docstrings for all the functions/methods I implemented

⭐ Do you enjoy contributing to Colossal-AI?

[x] 🌝 Yes, I do.
[ ] 🌚 No, I don't.

Tell us more if you don't enjoy contributing to Colossal-AI.


Sync App API

This adds:

Network transport implementation for JVM and KN including:

Reorginazation of JNI utility source code to keep it out of realm.i
CinteropCallback for error propagation from C-APIinterface CinteropCallback {
    fun onSuccess(pointer: NativePointer)
    fun onError(throwable: Throwable)
}

Minimal App, AppConfig, User and Credentials to do an app.login(credentials)

There are still some rough corners, but as library-sync is not released we can postpone them for later.
Most notable discussion point is:

User facing API for errors
suspend fun App.login(credentials: Credentials): Result<User>

Merged master and fixed linting, added issue references to TODOs, etc. So only lacking the actual server tests running on CI.

I have ignored the sync tests as the CI build doesn't spin up the server image. We will target automation of tests in a separate PR as it not only involves spinning up the server, but also requires ability to do admin logins and register users programatically as in https://github.com/realm/realm-java/blob/master/realm/realm-library/src/androidTestObjectServer/kotlin/io/realm/admin/ServerAdmin.kt and https://github.com/realm/realm-java/blob/master/realm/realm-library/src/syncTestUtils/kotlin/io/realm/mongodb/SyncTestUtils.kt#L57.


Nested CDATA sections

Proposal for handling of nested CDATA sections.
Solution based on https://stackoverflow.com/a/12860902/761771

This is now published in v1.6.10.


Can't run - Unusual Behavior

Summary
Got a new PC and now it's saying this when I try to import from discord.ext import commands.     from discord.ext import commands ModuleNotFoundError: No module named 'discord.ext'
Reproduction Steps
Fresh Install, Install discord.py-self from git url,  from discord.ext import commands
Code
from discord.ext import commands

Expected Results
It runs
Actual Results
It gives error
System Information
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\__main__.py", line 304, in <module>
    main()
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\__main__.py", line 301, in main
    args.func(parser, args)
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\__main__.py", line 54, in core
    show_version()
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\__main__.py", line 43, in show_version
    pkg = pkg_resources.get_distribution('discord.py')
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\pkg_resources\__init__.py", line 466, in get_distribution
    dist = get_provider(dist)
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\pkg_resources\__init__.py", line 342, in get_provider
    return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\pkg_resources\__init__.py", line 886, in require
    needed = self.resolve(parse_requirements(requirements))
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\pkg_resources\__init__.py", line 772, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'discord.py' distribution was not found and is required by the application

C:\Users\a>python -m discord -v
Traceback (most recent call last):
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\__main__.py", line 304, in <module>
    main()
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\__main__.py", line 301, in main
    args.func(parser, args)
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\__main__.py", line 54, in core
    show_version()
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\discord\__main__.py", line 43, in show_version
    pkg = pkg_resources.get_distribution('discord.py')
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\pkg_resources\__init__.py", line 466, in get_distribution
    dist = get_provider(dist)
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\pkg_resources\__init__.py", line 342, in get_provider
    return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\pkg_resources\__init__.py", line 886, in require
    needed = self.resolve(parse_requirements(requirements))
  File "C:\Users\a\AppData\Local\Programs\Python\Python39\lib\site-packages\pkg_resources\__init__.py", line 772, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'discord.py' distribution was not found and is required by the application```

### Checklist

- [X] I have searched the open issues for duplicates.
- [X] I have shared the entire traceback.
- [X] I am using a user token (and it isn't visible in the code).

### Additional Information

_No response_

Is this the v1.x branch?

No idea, just did pip install git+https://github.com/dolfies/discord.py-self

Install through pip.

Update: It worked, I just had to pip install discord and pip install discord.py and pip uninstall discord.py
no idea why this made it work, but it did

Uhhh, now you're using the regular discord.py

No, i'm not idk but it works lmao


D3.2.3 Summary documentation for final Lasair

Final here refers to the last version from Phase B i.e V4.5

change request C036 approved at 01/MAR/22 Exec
title changed from “Design and implementation of web
front-end for LASAIR (public and the data-rights version)” to instead be “Summary documentation for final Lasair”.

23/NOV/22
as reported at [Lasair meeting](https://lsst-uk.atlassian.net/wiki/spaces/LUSC/pages/3097755649/23+November+2022

Documentation alpha Readthedocs – move from lasair_api repo to lasair4)

24/MAR/23

deliverable sent out for review

03/MAY/23

submitted to 10/MAY/23 Exec for approval


WIP: Add tag entity to work with ApiPlatform DataProvider and DataPer…

…sister with all filters and order !
need to test DB Fixtures importer

fix #120

fix #117

Tag exists as ORM & ApiResource class at the same time, but is overrided by a DataProvider (no DataPersister, we keep the original usage)
Also, added Reader & Loan with full DataProvider & DataPersister. But in that case, for instance, the DataProvider doesn't return books node in /api/readers. There is the good length of items in the node, but each rows are empty. I've looked around groups annotations and normalization_context but i don't see mistakes.


Plotting code should not call show

Calling show in some cases leads to warning messages, for example if using an inline backend in colab:
/home/maffoo/.virtualenvs/3.6/lib/python3.6/site-packages/matplotlib/figure.py:445: UserWarning: Matplotlib is currently using module://ipykernel.pylab.backend_inline, which is a non-GUI backend, so cannot show the figure.
  % get_backend())

We could try to detect which backend is running, but I think that way lies pain. Better IMO would be to just not call show, since in common environments (colab, ipython with matplotlib integration) it's not needed.

The reason I wanted these calls included is because, without them, the plot method fails to show a plot when running from the command line, from python's interpreter, and from within pycharm.
We could perhaps have plot and show_plot? Seems confusing...
Intercept the warning message and dump it? Seems dangerous...
Detect the backend and react appropriately? Sounds like massive jank...
Do we have data on how often users are using each environment?

I would bet that most users will be in a notebook environment (colab or jupyter) or ipython, but I don't have data to say what the ratios are. We certainly have lots of colab examples for introductory purposes and it seems to me that emitting warnings for plots in those examples is not great. If there's a way to detect whether the matplotlib backend is a "GUI" backend and do it robustly, then we could have a helper method like try_show_plot that we would call instead.

FWIW, on the commandline you can just append ; plt.show()...

I agree that we want to fix the warning in notebook environments, but I'd strongly prefer to not require different code in different environments to make the plots pop up. I want to be able to say "call .plot to see a plot" in the documentation, instead of "if you are in a notebook environment such as ipython or jupyer call .plot to see a plot. If you are not, then you also need to import matplotlib.pyplot as plt and then call plt.show()".

We now have both patterns in Cirq.  Probably we should make a decision on this.

Coming here from @cduck 's xref on #1992. Library code should never call show

I agree that we shouldn't call show by default.  We could have a show bool parameter, so that people who really want to call show would do plot(show=True).  I do think we should optimize the plotting for common environments, which means colab / ipython type setups, which also argues against calling show.

It also leads to lots of warnings in our tests
=============================== warnings summary ===============================
/usr/local/google/home/dabacon/git/cirq/cirq/study/visualize.py:64: UserWarning: Matplotlib is currently using pdf, which is a non-GUI backend, so cannot show the figure.
  plt.show()

/usr/local/google/home/dabacon/git/cirq/cirq/vis/examples/bristlecone_heatmap_example.py:15: UserWarning: Matplotlib is currently using agg, which is a non-GUI backend, so cannot show the figure.
  plt.show()

/usr/local/google/home/dabacon/git/cirq/cirq/experiments/qubit_characterizations.py:57: UserWarning: Matplotlib is currently using agg, which is a non-GUI backend, so cannot show the figure.
  fig.show()
/usr/local/google/home/dabacon/git/cirq/cirq/experiments/qubit_characterizations.py:99: UserWarning: Matplotlib is currently using agg, which is a non-GUI backend, so cannot show the figure.
  fig.show()
/usr/local/google/home/dabacon/git/cirq/cirq/experiments/qubit_characterizations.py:124: UserWarning: Matplotlib is currently using agg, which is a non-GUI backend, so cannot show the figure.
  fig.show()

/usr/local/google/home/dabacon/git/cirq/cirq/experiments/cross_entropy_benchmarking.py:47: UserWarning: Matplotlib is currently using agg, which is a non-GUI backend, so cannot show the figure.
  fig.show()

@pingyeh could you comment on the pattern you used in heatmap and why?

Library codes that create plots on an Axes should not call show(), so the caller of the library can decide when to show it, e.g., only after adding more stuff to the plot.
Some codes are supposed to make visible plots, e.g., the example codes in cirq.vis.examples.bristlecone_heatmap_example.main. They have to call show().
How about replacing calls to Figure.show() with Figure.show(warn=False)? The doc and the source both shows that the warning is suppressed. That should make our tests cleaner.

warn=False sounds like an ideal solution

So warn=False for example code and like that has to call show.  But in general library code should take in an Axes (so that people can control where it is shown)?  And if Axes is not passed in, should it create a Figure and Axes and then do show (with warn=False)?

I thought about making the ax argument of the Heatmap.plot() method optional and creating a Figure and an Axes if it's not specified, but I decided against it. My rationale is:

It is a library which should have no side effects like showing a plot on the screen,
It allows the caller a full control of the plot.

The down side is that it is a bit less convenient in interactive sessions. But I think that's a good trade-off for a library.
We can create a SupportsPlot protocol and a cirq.plot function that takes any object with a __plot__ or plot method (to be determined) and shows the plot. That is, it creates a figure and ax if not specified, and calls the __plot__ or plot method to plot on the ax, and show it. That should solve the use case of interactive sessions.

The pattern that is recommend is documented in docs/dev/plotting.md.


Allow logged-in users to bookmark a case/method/organization

[ ] define API (in /api)
[ ] implement API (in /api), with tests
[ ] connect bookmark button to said API call (in /frontend), with tests

Blocked on #33

I'm happy to help w/ the back-end bits.

@davidascher these are the API calls I would need help with for this feature.

get /bookmarks/userid --> list of all the bookmarks the user has.

post /bookmark/new --> create new bookmark with user_id, item_type (case, method, organization, etc) and item_id.

delete /bookmark/id --> delete bookmark.

done in #185


Class C support for 0.0.10

Note: Not yet final.
Also pending outcome of https://github.com/mastercoin-MSC/spec/issues/281.
This PR adds Class C support for both encoding and decoding.  Class C in the current context (but open to change) is:

Data packet moved to OP_RETURN output
Data packet is not obfuscated
Exodus marker removed and replaced with omni bytes at beginning of OP_RETURN output

A singular send function (ClassAgnostic_send) is now used which will default to Class C if the packet is small enough, otherwise falling back to class B.

I think it would be useful to provide an option to disable OP_RETURN, e.g. via CLI command, but this would only be nice to have. I shared my opinion on the topic in general in the other thread, and this PR reflects the discussion pretty well, but I insist on a short marker.. ;)
The spock tests require a minimal change, which I'm going to address tomorrow.
What I'm wondering about though: what exactly is MIN_PACKET_SIZE_CLASS_C and why is it required?
Quick side note: as I know have merge rights, I think we should discuss and define a simple merge/contribution process over the next days.

I think it would be useful to provide an option to disable OP_RETURN

You can disable OP_RETURN simply by setting datacarrierbytes to 0 :)

What I'm wondering about though: what exactly is MIN_PACKET_SIZE_CLASS_C and why is it required?

Supposed to be the smallest supported cleartext payload, to avoid passing in knowingly too short data payloads for further processing.

Quick side note: as I know have merge rights, I think we should discuss and define a simple merge/contribution process over the next days.

Oh - congrats!  Re merge/contribution process um I'm not sure to be honest mate no-one has talked to me about this so I'm not sure - to date @m21 has always been the merge guy (though he's been trying to encourage me to take over which I try to avoid hehe) but I guess a more community driven model is appropriate now he's focused on Factom...

Supposed to be the smallest supported cleartext payload, to avoid passing in knowingly too short data payloads for further processing.

Ah gotcha, so this is basically a range/length check to prevent other parsing steps try to process what's not there. I was just wondering, because step1() only parses version and type and I couldn't find the relation to the actual data embedding mechanism. Maybe rename it to MIN_PAYLOAD_SIZE or so?

Maybe rename it to MIN_PAYLOAD_SIZE or so?

Good suggestion :)  FYI the value is also wrong, I forgot about the 'close crowdsale' transaction which is even smaller.

@zathras-crypto:

Can you think of a way where parseTransaction() is transformed into something that doesn't use GetTransaction() to fetch the previous transactions, but instead, where the previous transactions are provided or so? I'm thinking about unit tests here, and in it's current form it seems impossible to create any, because without a history, it basically seems impossible to grap previous transactions via GetTransaction(), if I'm not mistaken.

For the first tests, it would be sufficient to test, whether parseTransaction() is able to extract payloads and doesn't fail. For the future, it would be awesome, if parseTransaction() were side effect free, in particular I'm referring to the calls of TXExodusFundraiser() and DEx_payment().

We could create a bunch of RPC/spock tests to simulate all this, and test parseTransaction() indirectly, but unit tests are much faster and much easier to execute (./test_bitcoin), and would also allow to just create a bunch fo raw transactions as hex (including previous transactions) and really test every aspect. Do you roughly understand where I'm going here..? :)

@dexX7 not off the top of my head mate, initial thoughts would be breaking down parseTransaction() into smaller chunks (checkMarker, parseSender, parsePayload, and so on).
FYI on the topic of tests, I'm nearly through with my work on missing transactions which is quite a change to sending and will require a bunch of testing (it removes send_INTERNAL_1packet entirely for example) - I should be pushing something close-to-complete over the next day or so :)
Thanks
Z

initial thoughts would be breaking down parseTransaction() into smaller chunks (checkMarker, parseSender, parsePayload, and so on)

Yeah, that's probably the way to go, long term at least, and I'm testing some parts of that already (+ there is a Java implementation with a similar approach), but this seems too complex to quickly add it into the class C pull request.. ;) I was just wondering, if you may have had some other idea, which might have been easier.

FYI on the topic of tests, I'm nearly through with my work on missing transactions which is quite a change to sending and will require a bunch of testing

Please push! :) I already have your 0.0.10-Z-TechDebt_MissingTransactions locally, and it's just waiting to be used. :)
Did you already consider RPC commands?
The RPC interface should probably be "checked" sooner or later, and this is something, I have in mind for some days, actually a bit similar to what you mentioned with "let's map all events for the UI", and in particular: it would be helpful, if there were a clean list for each command / transaction type with requirements  to pass to finalize the transaction creation or broadcat. For example: "does the user have enough balance?", "does this or that property exist?", ...

Yeah I did already consider the RPC interface, basically class*_send has been morphed into classAgnosticWalletTXBuilder and the process is largely to simply do some checks, call CreatePayload_type and pass that into classAgnosticWalletTXBuilder from each RPC call (or UI element) that wants to create a transaction.
There are bits I put in too like for example you can start with ---autocommit=false and then all send RPC commands will return the raw hex for the created tx instead of committing and broadcasting and returning a txid (figured that would help with testing after talking with @msgilligan).
I'm fleshing it all out and it'll be ready to push soon, though it's all merged with Class C stuff now so I may close this PR and open another (sadly larger in scope) PR to reflect what I've changed properly.
Speaking of RPC, pinging everyone here for commentary on whether the nomenclature is OK?
zathras@zlappy:~/github/build/mastercore$ grep _OMNI src/rpcserver.cpp
    { "omni layer",   "send_OMNI",                    &send_OMNI,                     false,  false,  true },
    { "omni layer",   "senddexsell_OMNI",             &senddexsell_OMNI,              false,  false,  true },
    { "omni layer",   "senddexaccept_OMNI",           &senddexaccept_OMNI,            false,  false,  true },
    { "omni layer",   "sendissuancecrowdsale_OMNI",   &sendissuancecrowdsale_OMNI,    false,  false,  true },
    { "omni layer",   "sendissuancefixed_OMNI",       &sendissuancefixed_OMNI,        false,  false,  true },
    { "omni layer",   "sendissuancemanual_OMNI",      &sendissuancemanual_OMNI,       false,  false,  true },
    { "omni layer",   "sendsto_OMNI",                 &sendsto_OMNI,                  false,  false,  true },
    { "omni layer",   "sendgrant_OMNI",               &sendgrant_OMNI,                false,  false,  true },
    { "omni layer",   "sendrevoke_OMNI",              &sendrevoke_OMNI,               false,  false,  true },
    { "omni layer",   "sendclosecrowdsale_OMNI",      &sendclosecrowdsale_OMNI,       false,  false,  true },
    { "omni layer",   "sendtrade_OMNI",               &sendtrade_OMNI,                false,  false,  true },
    { "omni layer",   "sendchangeissuer_OMNI",        &sendchangeissuer_OMNI,         false,  false,  true },

Note aliases for send_MP > send_OMNI and sendtoowners_MP > sendsto_OMNI and so on will be employed for backwards compatibility.

There are bits I put in too like for example you can start with ---autocommit=false and then all send RPC commands will return the raw hex ...

Interesting approach. I'm very curious about the code, because this is really, really an awesome feature, but requiring a restart is pretty harsh. On the other hand, duplicated commands, one with createXX, and one with broadcastXX might create a significant overhead. Adding more flags, such as broadcast, which defaults to true could be an alternative. But let's see.. :)

Speaking of RPC

We should get a working document for all transaction types. This document should list RPC commands and parameters, a short name, and a long, descriptive name. This is something I stumbled upon so many times, and I always ended up with slightly different results, whether it's during tests, the spec, or some documentation. And there is also the Omniwallet API. Maybe it's time to normalize it once and for all? :)
Regarding the actual commands:

I still hate the case-sensitive (!) suffix... ._." ... whether it's _MP or _OMNI. The commands are plain strings, so it would even be fine to use something like abc::de->f--=send@ as command (just an example). Is there really no other way? :/

Replacing send_MP with send_OMNI breaks all integrations. There is a nice feature since 0.10: the category can be set to "hidden", to hide the commands from help. Maybe the old commands could still be available, but hidden, at least for one version, which nevertheless call send_OMNI in the end?

Oh, nevermind, you actually mentioned aliasing.

sadly larger in scope

Given that omnicore-0.0.10 is a WIP branch anyway, we should probably get changes in more often, and in smaller pieces, instead of complete features in one larger chuck, even if this might end up with some back-and-forth or code moving.

 ... whether it's _MP or _OMNI

I'm fully open to changing the naming convention :)  I just felt MP was inappropriate/outdated so changed in line with our existing convention.  Feel free to suggest alternatives and see if we can get a consensus on alternate nomenclature (though I would insist on keeping the old _MP commands around (aliased) for a while at least).

Given that omnicore-0.0.10 is a WIP branch anyway, we should probably get changes in more often, and in smaller pieces, instead of complete features in one larger chuck

Yeah, I don't disagree mate and I'm probably being a bit of a PITA with these large chunks.  The problem is a lot of my work is experimental - for example I spent about 6 hours on an alternate approach before deciding it was worse than what we have now and abandoning it in favour of this other approach I'm now working on.  I always felt committing (crap) like that was bad form which is why I usually only commit work I intend to ask to be put into the project (I have all kinds of rubbish local that never made it up onto GitHub hehe).  Perhaps I need to adjust my workflow a bit.

Interesting approach. I'm very curious about the code, because this is really, really an awesome feature, but requiring a restart is pretty harsh

That can be avoided very easily just by allowing that flag (default bool autoCommit = true;) to be set via the RPC interface as well as (instead of?) a startup param.
I started with multiple cloned commands but it blew out with huge amounts of duplicate code very quickly.  I also looked at adding a parameter to the sendX_OMNI calls but some of these have optional parameters which need to be last and it would break backwards compat to put other params in earlier in the call (plug it seemed somewhat 'ugly' to have to specificially say for every transaction that you want to commit it).  Having a (it's a global) flag that we can just flip on/off for the commit stage of transaction creation makes things much simpler from a code PoV.

though I would insist on keeping the old _MP commands around (aliased) for a while at least)

Definitely, otherwise it would probably break some integrations.

alternate nomenclature

It's tricky, and I have no good solution in mind, unfortunally. A lower case prefix with underscore feels more intuitive, but this is just a feeling. Alternatively, commands could be grouped (e.g. dex_xxx, mdex_xxx, sto_xxx, ...), or there might be no explicit part at all, but instead the names are changes to something conflict free (e.g. instead of getbalance_MP, something like gettokenbalance or get_token_balance).

'ugly' to have to specificially say for every transaction that you want to commit it

I see your point. Let me think of this.. I could imagine there might be a way where a flag (hidden or visible) is used at very end, even with default parameters, combined with some alias/forwarding calls. For example: create_xxx internally calls send_xxx ... ... false.

That can be avoided very easily just by allowing that flag (default bool autoCommit = true;) to be set via the RPC interface as well as (instead of?) a startup param.

This is a good idea.

I could imagine there might be a way where a flag (hidden or visible) is used at very end, even with default parameters, combined with some alias/forwarding calls.

Great minds and all that hehe, yep I played with this too - the problem is the way the RPC code calls the method, it seemed to be built around always having the same structure and I couldn't find workable way to have two different RPC commands call the same Value blahblah_OMNI with a third param eg (const json_spirit::Array& params, bool fHelp, bool shouldICommit) without butchering the RPC code sadly.

For example: create_xxx internally calls send_xxx ... ... false

FYI that is kind of how it works now - the last parameter to ClassAgnosticWalletTXBuilder is a bool on whether to commit it or not.  I'm bouncing between some family stuff at the mo (Easter and all, the kids love it - probably all that chocolate!) but I'll get the final pieces finished and push it up - probably tomorrow - for you to take a look at bud :)

it seemed to be built around always having the same structure

Yup, it's very strict.
What I had in mind was something like: https://gist.github.com/dexX7/273529eebd07967f484c
But ... actually, when I think about it: to broadcast a transaction, the transaction has to be created first anyway, right? So "broadcast_xxx" might just call "create_xxx" and then broadcast it's result?

I don't like the idea of a configuration flag that requires a restart, nor do I like the idea of an RPC that creates global state. Since the "don't commit" flag would probably be used mostly for testing, why not just make it the very last parameter and require that the preceding optional parameters be explicitly specified?

@msgilligan can you please be more specific & elaborate?  "I don't like it" isn't super helpful :)

Since the "don't commit" flag would probably be used mostly for testing

FYI the reason there is a global is to put OmniCore into a sort of testing mode (to return raw transactions).  I cannot think of any reason it would be used outside of that context (eg this functionality cannot be used be end users to create unsigned raw transactions etc or non-wallet raw transactions etc).

why not just make it the very last parameter and require that the preceding optional parameters be explicitly specified?

Let's assume we are using the raw signed hex as part of our testing and further let's assume we need to specify all optional parameters and lastly a bool for whether to commit - now we've effectively restricted any ability to test commands without the full suite of optional parameters - eg out of the following two test scenarios, you can only test one of them:
send_OMNI fromAddress toAddress 1 0.01 true (error - cannot test without optional refAmount parameter)
send_OMNI fromAddress toAddress 1 0.01 0 true (ok - can test with optional parameter)
I object to not being able to test common syntax (common syntax eg for send does not include a reference amount).
TL:DR; the whole point of pumping raw hex out instead of committing was to assist you guys with testing, so of course I'm very interested in what is best for you guys - if you can tell me what you don't like/object to about my original method perhaps we can work out a better way to come at this.
Thanks
Z

Sorry for not being clear.
I don't like the idea of a configuration option that requires a restart because the tests as currently written run against a single launch of the server and managing the configuration and restarts would be inconvenient. On that issue, I was pretty much echoing Dexx's point.
And my concern with and RPC that sets/toggles the return hex vs commit transaction is that it adds critical state to the server that could cause problems in production and that requires any tests to manage that state.
The reason I asked for hex output of the various transactions was as a reference for creating/debugging a Java implementation of transaction encoding. There are probably better ways of doing that -- such as using the data from the C++ unit tests.
I'm not sure that getting the hex transactions is that useful in what are supposed to be integration/functional tests anyway.
TL;DR I think we can leave the "return hex" mode entirely out of the RPCs -- unless and until we find a real need for it.

Thanks for the clarification :)

I don't like the idea of a configuration option that requires a restart because the tests as currently written run against a single launch of the server and managing the configuration and restarts would be inconvenient. On that issue, I was pretty much echoing Dexx's point.

Agreed & that had been dealt with via a new RPC command I added yesterday (setautocommit true|false) to enable flipping the flag during runtime.

And my concern with and RPC that sets/toggles the return hex vs commit transaction is that it adds critical state to the server that could cause problems in production and that requires any tests to manage that state.

Not sure I 100% understand your meaning here but that's OK - the idea was to lower risk (by opening up testing avenues) but if the consensus is that it introduces risk I'm comfortable leaving it out.

The reason I asked for hex output of the various transactions was as a reference for creating/debugging a Java implementation of transaction encoding. There are probably better ways of doing that -- such as using the data from the C++ unit tests.

Understood, thanks.

TL;DR I think we can leave the "return hex" mode entirely out of the RPCs -- unless and until we find a real need for it.

Noted.  If it's no value in testing I'm not aware of any other uses for it.

@dexX7 sorry missed this bit:

We should get a working document for all transaction types. This document should list RPC commands and parameters, a short name, and a long, descriptive name. This is something I stumbled upon so many times, and I always ended up with slightly different results, whether it's during tests, the spec, or some documentation. And there is also the Omniwallet API. Maybe it's time to normalize it once and for all? :)

I would say for OmniCore at least the API documentation should be the primary doc?  It'll need updating if my work gets merged in that's for sure :)
https://github.com/OmniLayer/omnicore/blob/omnicore-0.0.10/doc/apidocumentation.md

Closing pull request in favour of consolidated code.  Will link new PR here when ready.


add vcpkg.disable-metrics to gitingore

see title

cc @dan-shaw

cc @dan-shaw

vcpkg.disable-metrics has been added to gitingore now. So close this issue.
Please see
https://github.com/microsoft/vcpkg/blob/e6dcc079c81161786eb7b052209a2047e79f2c6c/.gitignore#L311


add fpgad to fedora spec

Coverage decreased (-0.04%) to 79.948% when pulling 1bcd74a92bfecdfa831be8148d710f8c82adc53c on aravuri/fedora_spec_fpad1 into 91140eee23c2c4e8c85a057562f22466bc265eb6 on master.


Persistant error after HTTP 500 status: getFlash options can only be set once, at a top-level component

Situation: I use getFlash options and my website contains a page with an error which results in a HTTP 500 status. After I visit this page resulting in my own 500 I'll also see this error getFlash options can only be set once, at a top-level component. After that, when I try to visit any normal page on my website, I will still get this error and a 500.
It seems this issue is also described in #30 (especially this comment). I have been able to reproduce it using a default SvelteKit project on StackBlitz:

Visit: https://stackblitz.com/edit/sveltejs-kit-template-default-f28ajv (wait for the homepage on the right to load)
In the address bar above the websitepanel on the right add /testpage en press enter to navigate to this page

You'll see '500 | Internal Error' (this is correct, because I'm throwing a 500 on that page)
Also notice this error in the console below: `[Error: getFlash options can only be set once, at a top-level component.]

In the address bar, remove /testpage again and press enter to navigate back to the homepage

You'll still see '500 | Internal Error', instead of the homepage
And again this error in the console below: `[Error: getFlash options can only be set once, at a top-level component.]

Changes I've made to this default SvelteKit project:

Added to package.json:

  "dependencies": {
    "sveltekit-flash-message": "2.3.0"
  },

Added to src/routes/+layout.svelte:

  import {page} from '$app/stores';
  import {getFlash} from 'sveltekit-flash-message';
  const flash = getFlash(page, {clearOnNavigate: false});

Created src/routes/testpage/+page.svelte containing:

<script>
  import {error} from '@sveltejs/kit';
  throw error(500);
</script>

Hi, thank you for the test case, unfortunately when I add /testpage to the url, Vite crashes with this error:
Error: `line` must be greater than 0 (lines start at line 1)
    at originalPositionFor$1 (/home/projects/sveltejs-kit-template-default-f28ajv/node_modules/vite/dist/node/chunks/dep-R0I0XnyH.js:10341:19)
    at eval (/home/projects/sveltejs-kit-template-default-f28ajv/node_modules/vite/dist/node/chunks/dep-R0I0XnyH.js:50359:25)
    at eval (/home/projects/sveltejs-kit-template-default-f28ajv/node_modules/vite/dist/node/chunks/dep-R0I0XnyH.js:50350:21)
    at ssrRewriteStacktrace (/home/projects/sveltejs-kit-template-default-f28ajv/node_modules/vite/dist/node/chunks/dep-R0I0XnyH.js:50349:10)
    at ssrFixStacktrace (/home/projects/sveltejs-kit-template-default-f28ajv/node_modules/vite/dist/node/chunks/dep-R0I0XnyH.js:50402:24)
    at Object.ssrFixStacktrace (/home/projects/sveltejs-kit-template-default-f28ajv/node_modules/vite/dist/node/chunks/dep-R0I0XnyH.js:60086:13)
    at fix_stack_trace (/home/projects/sveltejs-kit-template-default-f28ajv/node_modules/@sveltejs/kit/src/exports/vite/dev/index.js:271:8)
    at eval (/home/projects/sveltejs-kit-template-default-f28ajv/node_modules/@sveltejs/kit/src/exports/vite/dev/index.js:539:13)

Apparently the Vite crash happens when I use Chrome/Chromium. I have no idea why, but the error is probably related to my issue?.
My error happens when I use Firefox. Can you try it again using Firefox?

I don't think it's a browser issue related to the library. It works locally in Chrome, and hopefully it will be fixed in the next release.

See if this is fixed now with version 2.3.1.

Version 2.3.1 (commit 901a98820760bed4d852005230043dccbfdf6f6e) indeed fixes this issue! Thanks @ciscoheat :tada::pray:!


[NEMO-338] SkewSamplingPass

JIRA: NEMO-338: SkewSamplingPass
Major changes:

SamplingSkewReshapingPass: Inserts SkewSampling and MessageBarrier vertices
SamplingVertex: Instantiated with (originalVertex, desiredSampleRate)
IRDAG: Automatically inserts IREdges from/to SamplingVertex objects, similar to other insert() methods
PhysicalPlanGenerator: Handles SamplingVertex objects appropriately
Stage: Uses getTaskIndices(), returns a subset of tasks for if consists of SamplingVertex objects, to determine the tasks to execute

Minor changes to note:

Refactors other insert() methods to share code as much as possible

Tests for the changes:

PerKeyMedianITCase#testLargeShuffleSamplingSkew (combines large shuffle + skew handling optimizations)

Other comments:

Sanha(@sanha) wrote the original code. I refactored the code and added comments to create this PR.

Closes #GITHUB_PR_NUMBER

@sanha Can you check if I missed out anything? Other reviewers are also welcome to take a look, of course.

Thanks @sanha! I've addressed the comments.


url-shortner solution

This is a url shortener solution in Java and Springboot. I have implemented it as a backend project, developed the core api and other features around it, all microservices.

Please just add a link to your solution on the relevant page.
Thanks, John

I have made the requested changes, also resolved some conflicts with upstream. Pl verify