What to do after step 3 to generate api ?

I have modified all classes according to steps 1 to 3 but i am not able to proceed to 4th step. So for generation of API what to do ? when I am doing npm run dev its throwing issue EntityMetadataNotFoundError:

not a repository maintainer, but EntityMetadataNotFoundError seems like a connection initialization issue, did you make sure all your entities extend BaseEntity from typeorm ?

I have generated one crud by typeorm crud generator. Then I modified it
according to document of Crud api. But after 3rd steap I am trying to
excite npm run command. After that this issue is coming.
On Wed, Jun 19, 2024, 2:28 AM Chihab HAJJI @.***> wrote:

not a repository maintainer, but EntityMetadataNotFoundError seems like a
connection initialization issue, did you make sure all your entities extend
BaseEntity from typeorm ?
—
Reply to this email directly, view it on GitHub
https://github.com/woowabros/nestjs-library-crud/issues/585#issuecomment-2176959972,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5HLQDT7XHCCGN2DGMP5OJ3ZICNORAVCNFSM6AAAAABJQR7IPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZWHE2TSOJXGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

if your repo is minimal so far and doesnt contain any sensitive info, can you share it on github on a public repo?

if your repo is minimal so far and doesnt contain any sensitive info, can you share it on github on a public repo?

https://github.com/shambhulky/node-crud-generator.git

i am just doing demo on address . I have done all changes on address . then why it is not generating for address ?

is it mandatory to do for all module ? will it not generate if i used on specific module ? i am just doing demo on address . I have done all changes on address , then why it is not generating for address ? I have changed the synchronize setting and also deleted the user module . still code not generated in service and controller.
If possible could you provide one working demo so that i can refer how to use.

This library does not generate code, but it makes the controller handle requests for each route properly.
If you send requests to the routes with @Crud applied, you could receive responses.


Unable to find a loader for </data/data/org.test.gpsguide/files/app/none.wav> ffpyplayer

Versions

Python: v3.7.1
OS: Android
Kivy: v1.11.0.dev0
Kivy installation method: pip

Description
So i need to ffpyplayer work. But he's not. When i'm trying to open file by SoundLoader
(i change os.environ['KIVY_AUDIO'] to 'ffpyplayer') he gives me that error: [WARNING] [Audio       ] Unable to find a loader for </data/data/org.test.gpsguide/files/app/none.wav>. Yes, none.wav is in the same folder as main.py and Yes, in buildozer.spec - source.include_exts is empty(to include all files). In my PC all works. But Android open sdl2, but i need ffpyplayer(to use seek() and get_pos()). At the end is that: AttributeError: 'NoneType' object has no attribute 'get_pos'
P.S. sry for my English
Code and Logs
#Peace of code
import os
os.environ['KIVY_AUDIO'] = 'ffpyplayer'
from kivy.lang import Builder
from kivy.app import App
from kivy.properties import StringProperty
from kivy.clock import Clock, mainthread
from kivy.uix.slider import Slider
from kivy.core.image import Image as CoreImage
from kivy.uix.popup import Popup
from kivy.uix.label import Label
from kivy.uix.button import Button
from kivy.uix.togglebutton import ToggleButton
from kivy.uix.floatlayout import FloatLayout
from kivy.uix.image import Image
from kivy.uix.textinput import TextInput
from kivy.graphics import Rectangle

from kivy.core.audio import SoundLoader

sound = SoundLoader.load('none.wav')
sound.play()

position = sound.get_pos()

print(position)

Please provide the full log in debug mode, make sure ffpyplyer is properly installed and that the log indicates that it's in the candidates (not ignored).

I don't know if it's the same error exactly, but for some reason for me on android kivy automatically uses AudioSDL2. I would like to use ffpyplayer, because it can stream music from the internet(radio and so on). I also used os.environ[KIVY_AUDIO] = "ffpyplayer" but it didn't help. On Linux it uses Gstreamer and that works.
log.txt


wow items aren't animated/shown in DOM elements hidden at pageload

I have a situation where my page has hidden content in the DOM (display:none) which is then revealed with user actions on buttons and links using jQuery functions like slideDown().
The problem is wow doesn't detect this and won't animate/show items until the scrollbar is moved, despite the fact that they are already visible as blank placeholders on the screen. Any chance this could be fixed?

I implemented a workaround for this, a small behaviour hack which doesn't modify wow.js itself. We first need access to the wow instance from js, so load wow in this way:

Then, in the JS  responsible for revealing hidden elements, the slideDown() closure looks like this:
element.slideDown(300, function() {
  if (typeof wow !== 'undefined') {
    wow.scrolled = true;
    wow.scrollCallback();
  }
});

Not ideal but certainly workable. It'd be nice to see handling of this kind of situation baked in to wow, since at the moment the behaviour doesn't even fall back gracefully: when a div is unhidden with display:block for example, placeholders for wow elements appear but the elements themselves don't.

This isn't that bad, but wow.scrolled and wow.scrollCallback() certainly aren't APIs. Can't you make this work by calling wow.sync() instead?

The problem is wow doesn't detect this […]

What browser are you using? WOW.js tries to detect DOM mutations, if you're revealing content by mutating the DOM (and how else could you), WOW should detect it.
Perhaps this is a bug, could you please point to a page where this is not working? (Or put together a quick example maybe.)

Can't you make this work by calling wow.sync() instead?

I tried wow.sync() before my workaround above but that didn't fix the problem.

What browser are you using? WOW.js tries to detect DOM mutations, if you're revealing content by mutating the DOM (and how else could you), WOW should detect it.
Perhaps this is a bug, could you please point to a page where this is not working? (Or put together a quick example maybe.)

Chrome and Firefox, latest. Not easy to show the page with the problem at the moment as its on a local server, but when I have a little time I'll knock together a simple fiddle to demo.
Essentially, if we have a div set to display:none at pageload, then some button on the page fires a jQuery scrollDown() to make the block appear (resulting in the hidden div being display:block), any img elements contained within the div show blank placeholders. As soon as the page is scrolled, wow fires and the images appear. From what you say this looks like a bug.

It seems that wow is setting visibility: hidden on the img elements while they're contained within the hidden div. When the div is revealed, the images remain hidden, so something is up with the processing that's fired as a result of the mutation observer.

Oh, I see, that makes this a bug indeed. I'll look into that, thanks for reporting.

More information
I can't reproduce this problem in a simple case, as demonstrated by (this codepen)[http://codepen.io/anon/pen/dPxyox]. Everything works just as expected.
So I've put the page I'm working on in a temp location for you guys to look at:
http://tmp.qgates.com/wowbug.html
Load up the page, scroll down so that the "Detailed Information" button is somewhere near the page center or higher, and click it. First time around, the thumbnails get revealed OK. Refresh the page and, without scrolling, hit the "Detailed information" button again. The gfx remain hidden until you scroll manually.
I've disabled my JS "Detailed Info" button handler on there for clarity as it doesn't affect the problem. If you want to see it with my JS, which essentially adds in some jQuery slidedown sugar, together with an intelligent scrolling algo, swap out lines 127 and 128 of the html. It doesn't really affect the problem, but I left it out to show that its not some knock on from my JS.
 I have a page of boxes that appear with wow. Each box is a trigger to a modal. Everything works great. But if I were to scroll down the page, then refresh the page...wow animates only the viewport boxes. This is to be expected since the other boxes are not in the viewport and thus won't be animated into visibility by wow. If I click on any box after page refresh, they trigger modals that appear with blank content. I have to scroll up to bring all the boxes into visibility before I can get the modals to appear with content.

Any update on this bug? :)

I have the same problem too. I guess there is a limit on elements.

+1 I am also facing the same issue. When switching views in ui-router, after scrolling down in the view, the page loads with div hidden (visibility: hidden) added to it. By removing wow class from the wrapper element, fixes the issue. But is there a better solution available. Any help will be much appreciated.
Here is the HTML i am using:

fixed with this -

using this to initialize wow -

var wow = new WOW({
animateClass: 'animated',
offset: 100,
callback: function(box) {
console.log(box.tagName);
}
});

    wow.init();

Thanks!

thanks guys, work perfectly :) .

You just need to do "new WOW().init();" every time, when you show the hidden content.

I had similar issue and I solved that removing
body, html { overflow-x:hidden; }
from CSS file 🥇

Hi All,
FINALLY!!
I had the same issue, i think: When i loaded the page, my elements would appear without having to scroll, but when i clicked a Filter-Button (Category), i would have to scroll in order for the elements to show. I think i may have tried every option that has been posted on many sites and nothing seemed to work for me..., the exception, that if one or two did work, it caused something else to suffer (slightly)... I found this code that someone posted, which seemed to allow me to keep my Code as is, and when i click any Filter-Button (Category), they all load and animate using
wow FadeInUp. Works great!  So anyway, if anyone is still looking for a solution, this is all i ended up adding in CSS to fix this silly issue:
.wow {
visibility: visible !important;
}

A simple workaround is on browser refresh scroll to top:
//SCROLL TO TOP ON PAGE REFRESH
$(window).on('beforeunload', function() {
 			$(window).scrollTop(0);
});

Hi please help me with Wow.js plugin.
i am using Wow.js with http://www.jqueryscript.net/layout/App-Style-One-Page-Scroll-Plugin-With-jQuery-AppLikeOnePage-js.html this plugin.
After including this plugin..when i load page..first i see the wow effects on second section of page after that page got scroll at top first section of page....but when i scroll again wow.js not working on scroll.


Segmentation Fault closing k4aviewer without stopping stream

The majority of the time if on Linux you close k4aviewer while you have all sensors streaming you will get a segmentation fault and the privacy LED will stay lit indicating that the stop wasn't executed.
To Reproduce

Launch k4aviewer from a command prompt on a Linux machine
Start streaming a camera
Press the X to close k4aviewer
Get a segmentation fault, and notice the privacy light is still on

Expected behavior
The Azure Kinect is stopped and then the application closes without a segmentation fault.
Desktop (please complete the following information):

OS with Version: Ubuntu 18.04
SDK Version: Latest from develop
Firmware version: 1.6.987014

Any solutions to this issue? The camera works fine. But I guess it is not stopped properly. The second time I try to open it, I got segmentation fault.


Add new batching API for time arrays and support for ND batching

This PR:
i) removes the args from TimeArrays
ii) allows for vmapping on time arrays
iii) allows for vmapping on ND time arrays
Note that support for batched times in pwc time arrays is not far, but I keep it for a next PR
Closes #547.
Related to DYN-197.

Thanks for your feedback Pierre. I don't really feel like splitting this one but if it feels hairy we can pair up so as to speed up the reviews and make them less of a headache for you (and @gautierronan too)

See #557 (on which we can work independently, it's really an addition to this PR).

I pushed a few more nits. I hope this doesn't conflict too much with your work @abocquet. 🙇♂ I'll wait for answers to Ronan's comment to finish my review (I reviewed everything up to the line class SummedTimeArray(TimeArray) until the end of the file).

Tell me if I'm wrong, but I think with the current code we loose the information on the type of time array within the solvers? That's an issue.

I pushed a few more nits. I hope this doesn't conflict too much with your work @abocquet.
I'd prefer if you made PRs like https://github.com/dynamiqs/dynamiqs/pull/557 next time 🙏

Tell me if I'm wrong, but I think with the current code we loose the information on the type of time array within the solvers? That's an issue.
We can have {Constant,PWC,Modulated,Callable}BatchedArray classes to identify them, but let's do this later, there is no rush

I'd prefer if you made PRs like https://github.com/dynamiqs/dynamiqs/pull/557 next time 🙏
Yep, and I didn't see but I broke your PR, do you want me to
a) anyway keep it like this
b) revert all commits
c) remove all commits (rebase, force push)

We can have {Constant,PWC,Modulated,Callable}BatchedArray classes to identify them, but let's do this later, there is no rush

I'm confused why the Propagator solver tests don't fail.

No worries, next time is fine 👍

So I guess my commit 7a160e48d3652f0979778a27f613035d5f196b07 introduced a bug right?

It's a bit sad that we can't vmap on values and have to broadcast times and array as well, even if it doesn't really change anything perf-wise.

Yes, please explain the rational behind https://github.com/dynamiqs/dynamiqs/pull/552/commits/7a160e48d3652f0979778a27f613035d5f196b07

Yes, please explain the rational behind https://github.com/dynamiqs/dynamiqs/commit/7a160e48d3652f0979778a27f613035d5f196b07

I just wanted to remove changes related to having arbitrary batching, and mistakenly changed the as_batched_callable by reading too fast.

But maybe there's a better way than this BatchedArray logic, and having to make everything vmap-compatible in the returned PyTree, and changing the object type. See proposition in https://linear.app/dynamiqs/issue/DYN-197/fix-new-nd-batching-feature comment

To make it work with time arrays (which is a bit tricky for summed arrays and pwc/modulated), I think the simplest would be that they have a « compute_in_axes » like function that returns the PyTree we need to pass to vmap.

Would that work @abocquet?

I just wanted to remove changes related to having arbitrary batching for PWCTimeArray

Yes, but why?

To make it work with time arrays (which is a bit tricky for summed arrays and pwc/modulated), I think the simplest would be that they have a « compute_in_axes » like function that returns the PyTree we need to pass to vmap.

This Pytree is what is returned but as_vmappable_callable

This Pytree is what is returned but as_vmappable_callable

Sorry, I meant the PyTree to use as argument for in_axes of vmap.

Sorry, I meant the PyTree to use as argument for in_axes of vmap.

So every TimeArray would natively be a BatchedArray, and we would inform vmap of the structure of the batching for each TimeArray, by specifying the correct in_axes argument.

So every TimeArray would natively be a BatchedArray, and we would inform vmap of the structure of the batching for each TimeArray, by specifying the correct in_axes argument.

That would require nested in_axes. I don't think it is possible. I'll check

Tell me if I'm wrong, but I think with the current code we loose the information on the type of time array within the solvers? That's an issue.

We can have {Constant,PWC,Modulated,Callable}BatchedArray classes to identify them, but let's do this later, there is no rush

Or we could transform only self.f into a BatchedCallable? This way we keep the initial TimeArray PyTree structure, while having all attributes vmappable.
On the subject of the in_axes, I agree with Pierre's solution. This is somewhat similar to what we had before with the compute_in_axes function.

Or we could transform only self.f into a BatchedCallable? This way we keep the initial TimeArray PyTree structure, while having all attributes vmappable.

self.f does not exist for PWC time arrays

I'll revamp the PR, please don't add comments anymore for the moment

My bad for https://github.com/dynamiqs/dynamiqs/commit/7a160e48d3652f0979778a27f613035d5f196b07, the whole commit should stay bc of the current structure (i.e. we need to create a fully vmap-pable structure, thus have arbitrary shape times and array, which we just be broadcasted to values in the end when building the batched array). I thought these bits were rests from a pre-matured implementation of DYN-204 et DYN-205. So yep, ideally specifying the in_axes would allow not doing this. 🤞

Or we could transform only self.f into a BatchedCallable? This way we keep the initial TimeArray PyTree structure, while having all attributes vmappable.

self.f does not exist for PWC time arrays

Only for modulated and callable. For the rest it should not be required to use this self.indices trick.


RegisterBinaryViewInitialAnalysisCompletionEvent and RegisterBinaryViewFinalizationEvent called twice

Binary Ninja Version
2.4.2954-dev
Describe the bug
When registering a callback with BinaryViewType::RegisterBinaryViewInitialAnalysisCompletionEvent or BinaryViewType::RegisterBinaryViewFinalizationEvent, the callback is called multiple times instead of once.
To Reproduce
Steps to reproduce the behavior:
	BINARYNINJAPLUGIN bool CorePluginInit()
	{
            auto completionEvent = [](BinaryView* view) {
                LogInfo("completionEvent");
            };

            BinaryViewType::RegisterBinaryViewFinalizationEvent(completionEvent);
            // or
            // BinaryViewType::RegisterBinaryViewInitialAnalysisCompletionEvent(completionEvent);
        }

Expected behavior
"completionEvent" should only appear in the log once.
Screenshots

Version and Platform (required):

Binary Ninja: Dev 2.4.2954-dev
OS: MacOS
Version 11.4

I believe this is the desired behavior. The callback is called once on each BinaryView that gets finalized (or whose initial analysis has finished). Typically, there will be two views, i.e., the raw view and the actual BinaryView (e.g., ELF, PE, etc) that is useful. It is the callback writer's responsibility to filter out the unwanted views and do nothing for it.
I am closing this issue for now. Feel free to re-open it if the callback is triggered multiple times even on the same binary view


fix: 移除azure policy sync部分

这个 PR 实现什么功能/修复什么问题:
移除azure policy sync部分
是否需要 backport 到之前的 release 分支:

release/3.2

/area region
/cc @zexi

Codecov Report

Merging #6605 into master will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           master    #6605    +/-   ##
========================================
  Coverage    7.15%    7.15%
========================================
  Files         647      647
  Lines      109327   109226   -101
========================================
  Hits         7818     7818
+ Misses     100909   100808   -101
  Partials      600      600

Flag
Coverage Δ

#aFlag
7.15% <ø> (+<0.01%)
:arrow_up:

Impacted Files
Coverage Δ

pkg/cloudprovider/cloudprovider.go
1.56% <ø> (+0.02%)
:arrow_up:

pkg/compute/models/policy_definition.go
14.75% <ø> (+9.12%)
:arrow_up:

pkg/cloudcommon/validators/validators_cert.go
39.77% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c05e243...9e07cda. Read the comment docs.


Allow override of jar instead if assuming assembly target

I'm building a complex Lambda function which needs extra assets and use the universal packager to create a zip (containing the assembly jar under /lib in the zip). I'd like to be able to override the jar parameter of doUpdateLambda and doCreateLambda respectively. I think if the do* functions were not private I could override using standard SBT functionality. Otherwise, using some setting I can define would work too.

So I forked the repo and removed the private modifier for doCreateLambda and doUpdateLambda as a test.
Note the jar arg is now my custom jar. This works, but I can see the merit of keeping the method private and exposing a setting.
updateLambda := doUpdateLambda(
  region = region.value,
  jar = (packageBin in Universal).value,
  s3Bucket = s3Bucket.value,
  lambdaName = lambdaName.value,
  handlerName = handlerName.value,
  lambdaHandlers = lambdaHandlers.value
)
createLambda := doCreateLambda(
  region = region.value,
  jar = (packageBin in Universal).value,
  s3Bucket = s3Bucket.value,
  lambdaName = lambdaName.value,
  handlerName = handlerName.value,
  lambdaHandlers = lambdaHandlers.value,
  roleArn = roleArn.value,
  timeout = awsLambdaTimeout.value,
  memory = awsLambdaMemory.value
)

I second this. The fat jars created by sbt-assembly are unnecessarily large, and on my slow internet connection each jar upload takes minutes. It would be great if sbt-proguard could be supported to trim down the final jar size.


Iterate on interactive end-user demo of RS

User story
As a D/R on ReportStream, I want to run through, analyze, synthesize, and see where I can improve the documentation, value exchanges, and experience of the current interactive end-user demo of ReportStream, so that future less-technical users can better understand the ReportStream platform and the user experience.
Background
This ticket is additive to #14842, where the original task was to create documentation in RS Sharepoint that explains how a non-technical user can best:

1.A As a sender, Send a report to ReportStream
1.B As a sender, Query the history endpoint to see where their report went

As a receiver, view what reports they have potentially received (SFTP)

Risks/Impacts/Considerations

Which step(s) are simply unfamiliar to me as a very non-technical person, versus which steps may have issues and should be improved? Will I be able to discern the difference?
Will being able to demo the 'machine experience' actually let someone understand the end user experience?

Open questions

What will engineers see on their screen verbatim? What will they not see?
Which view(s) can I improve, and which view(s) must remain the same because of SWE requirements?
What is a good stopping point for the demo? What is considered 'complete'?
Should we be testing with folks like Brandon, who are 'lesser-technical' people?

Links

Interactive demo OneDrive folder (private)

Acceptance criteria

[x] Run through demo documentation and see if it works
[x] Analyze the documentation for mental gaps, errors, and other issues
[x] Create recommendations for improving the documentation and demo experience
[x] Implement recommendations

Out of Scope

Create documentation / demo for completely non-technical users
Create an interface or a front-end experience of some sort

Full draft is in the secret folder, separate from Angela's draft! Name: DRAFT_Instructionsv2. cc @arnejduranovic @adegolier. Ready for review.

End-user demo version is complete with reviews from @arnejduranovic and @adegolier. I will also present this demo at Sprint Review tomorrow (9/11). I will finalize some small details tonight, but as such, I am comfortable moving to Closed. cc @Andrey-Glazkv


Add iframe resize sample

explain how resizing works
fixes doc pre font size along the way

@kul3r4 PTAL
https://amp-by-example-staging.appspot.com/components/amp-iframe/#resizeable-iframes

@kul3r4 PTAL - Updated the PR to make the iframe toggle the size following Rowan's input.

thanks!


Tripod Cover

I'm looking to implement a tripod cover.  To start with just a black circle to cover the tripod, eventually I'll want to use different images.  I poked around the examples, docs and the source code but didn't see the obvious way to handle this.  Any suggestions?  Thanks!

You can do this with an embedded hotspot (see the links below). Another
possibility is to add the tripod cover in the panorama itself before
processing it with the Marzipano tool.
http://www.marzipano.net/demos/embedded-hotspots/index.html
https://github.com/google/marzipano/tree/master/demos/embedded-hotspots
On Mon, Apr 23, 2018 at 7:10 PM, Daniel Bohannon<EMAIL_ADDRESS>wrote:

I'm looking to implement a tripod cover. To start with just a black circle
to cover the tripod, eventually I'll want to use different images. I poked
around the examples, docs and the source code but didn't see the obvious
way to handle this. Any suggestions? Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/marzipano/issues/161, or mute the thread
https://github.com/notifications/unsubscribe-auth/AArp0xabEWRBrpPraxikR70VV2IZTLnKks5tromggaJpZM4Tg5I8
.

Thanks for the reply and links to hotspots.  This is definitely the right solution.  After playing with this I am running into one issue, if I move the image around the hotspot won't stay in the same position.  So if I have the hotspot covering the tripod with the photo positioned a certain way, if I move the image then the tripod is no longer covered.  This may make more sense with the screenshots below.  I also included the code I am using in case I am missing something.  Any idea how to force the hotspot to remain in the bottom most position of the 360 photo?
HTML:

CSS:
.tripodCover {
  width: 400px;
  height: 400px;
  background: yellow;
  border: 3px solid red;
  border-radius: 50%;
}
#tripodCover {
  border: 4px green solid;
  border-radius: 50%;
}

JS:
// Get the hotspot container for scene.
const container = scene.hotspotContainer();

// Create hotspot with different sources.
container.createHotspot(document.getElementById('tripodCover'), {
  yaw: 0,
  pitch: 90,
});

You need to set a perspective radius in order to embed the hotspot into the
panorama at a fixed size (as in here
https://github.com/google/marzipano/blob/master/demos/embedded-hotspots/index.js#L55).
The right value for the radius parameter, unfortunately, is not
straightforward to determine (see this post
https://groups.google.com/d/msg/marzipano/MEmXVf-h-So/lYwQZRhABwAJ). But
trial and error usually works.
On Wed, Apr 25, 2018 at 12:50 PM Daniel Bohannon<EMAIL_ADDRESS>wrote:

Thanks for the reply and links to hotspots. This is definitely the right
solution. After playing with this I am running into one issue, if I move
the image around the hotspot won't stay in the same position. So if I have
the hotspot covering the tripod with the photo positioned a certain way, if
I move the image then the tripod is no longer covered. This may make more
sense with the screenshots below. I also included the code I am using in
case I am missing something. Any idea how to force the hotspot to remain in
the bottom most position of the 360 photo?
HTML:

CSS:
.tripodCover {
width: 400px;
height: 400px;
background: yellow;
border: 3px solid red;
border-radius: 50%;
}#tripodCover {
border: 4px green solid;
border-radius: 50%;
}
JS:
// Get the hotspot container for scene.const container = scene.hotspotContainer();
// Create hotspot with different sources.container.createHotspot(document.getElementById('tripodCover'), {
yaw: 0,
pitch: 90,
});
[image: image]
https://user-images.githubusercontent.com/3709575/39269139-e44f4780-4886-11e8-89e4-a088c0d75b4e.png
[image: image]
https://user-images.githubusercontent.com/3709575/39269160-f5630d86-4886-11e8-8957-2e7e3bac837d.png
[image: image]
https://user-images.githubusercontent.com/3709575/39269183-01b7cee6-4887-11e8-9ea1-06a2c42344c7.png
[image: image]
https://user-images.githubusercontent.com/3709575/39269204-123b8f82-4887-11e8-83c7-58b548f010e6.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/google/marzipano/issues/161#issuecomment-384412334,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEKunRT1FSTHykC-eeZ_rSzbaNZTKuHdks5tsNNsgaJpZM4Tg5I8
.

I played with the perspective a bit and was able to get something decent working.  I have to admit though, I have no idea how this works.  The documentation placement for this doesn't exist, I had to look at the source code and the examples you provided to make some guesses.  I'll provide the code below for anyone trying to figure this out in the future.  I just wish I could explain why pitch: -80.1 ended up being straight down covering the tripod.

.tripodCover {
  width: 400px;
  height: 400px;
  background: #000;
  border-radius: 50%;
}

// Get the hotspot container for scene.
const container = scene.hotspotContainer();

// Create hotspot with different sources.
container.createHotspot(
  document.getElementById('tripodCover'),
  { yaw: 0, pitch: -80.1 },
  {
    perspective: {
      extraRotations: 'rotateZ(0deg) rotateY(0deg)',
      radius: 1000,
    },
  },
);

This results in the following:

Pitch and yaw and defined in radians rather than degrees. So the pitch for
the point straight down should be -Math.PI/2 or approximately -1.57.
On Wed, Apr 25, 2018 at 4:06 PM, Daniel Bohannon<EMAIL_ADDRESS>wrote:

I played with the perspective a bit and was able to get something decent
working. I have to admit though, I have no idea how this works. The
documentation placement for this doesn't exist, I had to look at the source
code and the examples you provided to make some guesses. I'll provide the
code below for anyone trying to figure this out in the future. I just wish
I could explain why pitch: -80.1 ended up being straight down covering
the tripod.

.tripodCover {
width: 400px;
height: 400px;
background: #000;
border-radius: 50%;
}
// Get the hotspot container for scene.const container = scene.hotspotContainer();
// Create hotspot with different sources.container.createHotspot(
document.getElementById('tripodCover'),
{ yaw: 0, pitch: -80.1 },
{
perspective: {
extraRotations: 'rotateZ(0deg) rotateY(0deg)',
radius: 1000,
},
},
);
This results in the following:
[image: image]
https://user-images.githubusercontent.com/3709575/39277350-36fd19a6-48a2-11e8-89ea-a8e70dc1ddc1.png
[image: image]
https://user-images.githubusercontent.com/3709575/39277367-41d5d426-48a2-11e8-8460-ce40389c265d.png
[image: image]
https://user-images.githubusercontent.com/3709575/39277388-5054dbd2-48a2-11e8-8322-9137231e7fc5.png
[image: image]
https://user-images.githubusercontent.com/3709575/39277400-6293dcbc-48a2-11e8-8d4d-72df2983b4be.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/google/marzipano/issues/161#issuecomment-384461236,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AArp040aOyiStsrf0kXI3o8ETfxbPkyEks5tsQFvgaJpZM4Tg5I8
.

Ah okay that make more sense, I made the poor assumption it was in degrees.  I'll be researching radians so I get a good understanding of this.  Thank you for your reply, you have been a huge help.
-Math.PI/2 ended up being straight up.  With Math.PI/2 my tripod cover is now straight down.
Here is my updated js for anyone who may be trying to do the same thing:
// Get the hotspot container for scene.
const container = scene.hotspotContainer();

// Create hotspot with different sources.
container.createHotspot(
  document.getElementById('tripodCover'),
  { yaw: 0, pitch: Math.PI / 2 },
  {
    perspective: {
      extraRotations: 'rotateZ(0deg) rotateY(0deg)',
      radius: 1000,
    },
  },
);


Add a "You Won" player screen at the end for the winning player

https://github.com/hto-projects/friendpardy/pull/185


Create Schema for order details

I have pushed the code for the schema on a branch called 'schema for order details'.


'com.android.support:appcompat-v7' has different version for the compile (26.1.0) and runtime (27.0.1) classpath

i receive an error when i run flutter run
flutter run
Launching lib/main.dart on Android SDK built for x86 in debug mode...
Initializing gradle...                                0.7s
Resolving dependencies...                             0.9s
Running 'gradlew assembleDebug'...
Configuration 'debugCompile' in project ':app' is deprecated. Use 'debugImplementation' instead.
Configuration 'profileCompile' in project ':app' is deprecated. Use 'profileImplementation' instead.
Configuration 'releaseCompile' in project ':app' is deprecated. Use 'releaseImplementation' instead.
Configuration 'compile' in project ':app' is deprecated. Use 'implementation' instead.
registerResGeneratingTask is deprecated, use registerGeneratedFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedFolders(FileCollection)
registerResGeneratingTask is deprecated, use registerGeneratedFolders(FileCollection)
Configuration 'debugProvided' in project ':apn_fb_login' is deprecated. Use 'debugCompileOnly' instead.
Configuration 'releaseProvided' in project ':apn_fb_login' is deprecated. Use 'releaseCompileOnly' instead.
Configuration 'debugProvided' in project ':firebase_messaging' is deprecated. Use 'debugCompileOnly' instead.
Configuration 'releaseProvided' in project ':firebase_messaging' is deprecated. Use 'releaseCompileOnly' instead.
Configuration 'debugProvided' in project ':google_sign_in' is deprecated. Use 'debugCompileOnly' instead.
Configuration 'releaseProvided' in project ':google_sign_in' is deprecated. Use 'releaseCompileOnly' instead.
Configuration 'debugProvided' in project ':image_picker' is deprecated. Use 'debugCompileOnly' instead.
Configuration 'releaseProvided' in project ':image_picker' is deprecated. Use 'releaseCompileOnly' instead.
Configuration 'debugProvided' in project ':share' is deprecated. Use 'debugCompileOnly' instead.
Configuration 'releaseProvided' in project ':share' is deprecated. Use 'releaseCompileOnly' instead.
Configuration 'debugProvided' in project ':shared_preferences' is deprecated. Use 'debugCompileOnly' instead.
Configuration 'releaseProvided' in project ':shared_preferences' is deprecated. Use 'releaseCompileOnly' instead.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:preDebugBuild'.
> Android dependency 'com.android.support:appcompat-v7' has different version for the compile (26.1.0) and runtime (27.0.1) classpath. You should manually set the same version via DependencyResolution

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 0s
Gradle build failed: 1

My gradle.build file is:
def localProperties = new Properties()
def localPropertiesFile = rootProject.file('local.properties')
if (localPropertiesFile.exists()) {
    localPropertiesFile.withInputStream { stream ->
        localProperties.load(stream)
    }
}

def flutterRoot = localProperties.getProperty('flutter.sdk')
if (flutterRoot == null) {
    throw new GradleException("Flutter SDK not found. Define location with flutter.sdk in the local.properties file.")
}

apply plugin: 'com.android.application'
apply from: "$flutterRoot/packages/flutter_tools/gradle/flutter.gradle"

android {
    compileSdkVersion 26
    buildToolsVersion '26.0.3'

    lintOptions {
        disable 'InvalidPackage'
    }

    defaultConfig {
        // TODO: Specify your own unique Application ID (https://developer.android.com/studio/build/application-id.html).
        applicationId "com.shuttertop.app"
        minSdkVersion 16
        targetSdkVersion 26
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
        }
    }
}

flutter {
    source '../..'
}

dependencies {
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.1'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
}

apply plugin: 'com.google.gms.google-services'

flutter doctor:
[✓] Flutter (on Linux, locale en_US.UTF-8, channel alpha)
    • Flutter at /home/luca/Programs/flutter
    • Framework revision 8f65fec5f5 (4 weeks ago), 2017-12-12 09:50:14 -0800
    • Engine revision edaecdc8b8
    • Tools Dart version 1.25.0-dev.11.0
    • Engine Dart version 2.0.0-edge.d8ae797298c3a6cf8dc9f4558707bd2672224d3e

[✓] Android toolchain - develop for Android devices (Android SDK 26.0.3)
    • Android SDK at /home/luca/Android/Sdk
    • Android NDK at /home/luca/Android/Sdk/ndk-bundle
    • Platform android-26, build-tools 26.0.3
    • ANDROID_HOME = /home/luca/Android/Sdk
    • Java binary at: /home/luca/Programs/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)

[✓] Android Studio (version 3.0)
    • Android Studio at /home/luca/Programs/android-studio
    • Java version OpenJDK Runtime Environment (build 1.8.0_152-release-915-b01)

[✓] Connected devices
    • Android SDK built for x86 • emulator-5554 • android-x86 • Android 8.0.0 (API 26) (emulator)

I have the exact same problem. Could you post your entire code? I have a hard time adding your solution to the right build.gradle file.
thx

is like this
buildscript {
repositories {
    google()
    jcenter()
}
dependencies {
    classpath 'com.android.tools.build:gradle:3.1.1'

    // NOTE: Do not place your application dependencies here; they belong
    // in the individual module build.gradle files
}

}
allprojects {
repositories {
google()
jcenter()
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
subprojects {
project.configurations.all {
resolutionStrategy.eachDependency { details ->
if (details.requested.group == 'com.android.support'
&& !details.requested.name.contains('multidex') ) {
details.useVersion "26.1.0"
}
}
}
}

This worked for me.Thank you.
Although I do not understand what it does.Please can you explain briefly its function ?

i'am sorry i cannot remember why this happened, i think that this error is due when you migrate a project from an older version (e.g 2.0.1) to a newest (e.g 3.0.1) also you need to make sure you have downloaded the appropiated dependencies.
check this to get more info. https://stackoverflow.com/questions/47448502/could-not-resolve-com-android-supportappcompat-v726-1-0-in-android-studio-new

I had the same issue with flutter map_view plugin, added
subprojects {     project.configurations.all {         resolutionStrategy.eachDependency { details ->             if (details.requested.group == 'com.android.support'                     && !details.requested.name.contains('multidex') ) {                 details.useVersion "26.1.0"             }         }     } }
to the end of android/build.gradle and it solved the issue.
Thanks @lalukz

imagine the hassle when we migrate to android jetpack androidx packages

worked,
i had errors while using both clodfirestore and firebase messaging plgin now its gone by ading the above line
also adding the following line in app level gradle file
dependencies {
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.1'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
}
apply plugin: 'com.google.gms.google-services'
com.google.gms.googleservices.GoogleServicesPlugin.config.disableVersionCheck = true

Same error, but against
> Android dependency 'com.android.support:support-v4' has different version for the compile (27.0.1) and runtime (27.1.1) classpath. You should manually set the same version via DependencyResolution
Added this to resolve.
        resolutionStrategy.eachDependency { details ->
            if (details.requested.group == 'com.android.support'
                    && !details.requested.name.contains('multidex') ) {
                details.useVersion "27.0.1"
            }
        }

When I do this my app compiles, but it crashes at the app start with no error in the logs

I also did the 27.1.0 fix and it crashes at app start with no error in the logs.

I was able to solve this in a different way. Maybe it will work for some of those who are still experiencing difficulty @dannnnthemannnn
In app/build.gradle add this line:
implementation "com.android.support:support-v4:27.1.1"
so it now looks like:
dependencies {
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.2'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
    implementation "com.android.support:support-v4:27.1.1" // added this
}

From a post on react-community.

It works when I add as below
subprojects {
project.configurations.all {
resolutionStrategy.eachDependency { details ->
if (details.requested.group == 'com.android.support'
&& !details.requested.name.contains('multidex') ) {
details.useVersion "26.1.0"
}
}
}
}

the solution works fine.

I had the same issue with flutter map_view plugin, added
subprojects {
    project.configurations.all {
        resolutionStrategy.eachDependency { details ->
            if (details.requested.group == 'com.android.support'
                    && !details.requested.name.contains('multidex') ) {
                details.useVersion "26.1.0"
            }
        }
    }
}

to the end of android/build.gradle and it solved the issue.
Thanks @lalukz

thank you it's working for me

I also had the same issue and solved it by adding
subprojects {
project.configurations.all {
resolutionStrategy.eachDependency { details ->
if (details.requested.group == 'com.android.support'
&& !details.requested.name.contains('multidex') ) {
details.useVersion "26.1.0"
}
}
}
}
at the end of android/build.gradle file

I also had the same issue and solved it by adding
subprojects {
project.configurations.all {
resolutionStrategy.eachDependency { details ->
if (details.requested.group == 'com.android.support'
&& !details.requested.name.contains('multidex') ) {
details.useVersion "26.1.0"
}
}
}
}
at the end of android/build.gradle file

this solution works for my situation.


Specify details for "options" parameter on did.create

Need more info on what this object should contain
options (Optional): Enables customization of the did formation

https://developer.tbd.website/api/web5-js/did/#createmethod-options
From web5.js:
export type Web5ConnectOptions = {
  /** a custom {@link Web5Agent}. Defaults to creating an embedded {@link Web5UserAgent} if one isnt provided */
  web5Agent?: Web5Agent;
  /** additional {@link DidMethodApi}s that can be used to create and resolve DID methods. defaults to did:key and did:ion */
  didMethodApis?: DidMethodApi[];
  /** custom cache used to store DidResolutionResults. defaults to a {@link DidResolutionCache} */
  didResolutionCache?: DidResolverCache;
  /** overrides to defaults configured for technical preview phase. See {@link TechPreviewOptions} */
  techPreview?: TechPreviewOptions;
}

Hey team, I will like to contribute in this project if its still open.

Sorry everyone, this issue is no longer valid


Import custom queries from Legacy Bloodhound

Hi,
Sorry if that's a stupid question, but how can I import the content of /.config/bloodhound/customqueries.json (in legacy Bloodhound) into the new Bloodhound CE?
I've looked in the docs, but couldn't find any leads.
Thank you!

You'd need to parse out the old json file, then use the API to import the queries into BHCE. Be aware of https://github.com/SpecterOps/BloodHound/issues/171 as that is currently blocking this capability, but it's on our radar to fix.

Hi @StephenHinck , thanks for the info
Is there gonna be any easier way to do this in the future?  like a file that could be manually edited or something?

Saved queries are stored in the PostgreSQL database, not in a flat file like they used to be.

thank you for clarifying.
Is there gonna be any user friendly approach to do the import in the future? The API route doesn't look very easy, specially with the lack of examples because it's all still brand new


jail password dead code

delete dead code (backend & frontend) regarding the jail system & the password reset

https://github.com/Couchers-org/couchers/pull/4327/files

Waiting for #4327 and #4254


Unable to click on the game UI

After the injection, the UI of the Osiris was displayed on top, but the UI of the game is not clicked afterwards

have u clicked insert key?

키 삽입을 클릭하셨습니까?

It's settled. Thank you


How to set batch_size properly in Landmark Regression Training？

Hello author, when I tried to Train Adversarial Landmark Regression on a single NVIDIA RTX 3090 24 GB GPU, I had to lower the BATCH_SIZE_PER_GPU parameter in lit_hpc_001.yaml because of the problem: CUDA:out of memory, and when I set BATCH_SIZE_PER_GPU parameter : 2,  it was no longer out of memory, but another error was reported (as shown below), how can I solve it? Do I have to adjust other parameters when adjusting BATCH_SIZE?
Hope you can tell me how to solve this problem in your busy schedule sincerely！
the error in the terminal:
TRAIN:
BATCH_SIZE_PER_GPU: 2
BATCH_SIZE_PER_GPU_ADVERSARIAL_SET: 2
BEGIN_EPOCH: 0
CHECKPOINT:
END_EPOCH: 40
GAMMA1: 0.99
GAMMA2: 0.0
LR: 0.001
LR_FACTOR: 0.1
LR_STEP: [25, 35]
MOMENTUM: 0.9
NESTEROV: False
OPTIMIZER: adam
RESUME: False
SHUFFLE: True
WD: 0.0001
WORKERS: 0
=> init weights from normal distribution
=> loading pretrained model models/pytorch/imagenet/hrnet_w32-36af842e.pth
=> load 47966 samples
=> load 6740 samples
=> load 11994 samples
=> load 6740 samples
/home/zhouzhiyi/anaconda3/envs/pep/lib/python3.8/site-packages/torch/nn/modules/loss.py:529: UserWarning: Using a target size (torch.Size([2, 589824])) that is different to the input size (torch.Size([2, 147456])). This will likely lead to incorrect results due to broadcasting. Please ensure they have the same size.
return F.mse_loss(input, target, reduction=self.reduction)
Traceback (most recent call last):
File "tools/train_da_ms.py", line 315, in
main()
File "tools/train_da_ms.py", line 266, in main
train_da_ms(cfg, train_loader, train_loader2, model, discriminator, criterion, criterion2, optimizer, optimizer2,
File "/home/zhouzhiyi/workspace/6D/spacecraft-pose-estimation-main/landmark_regression/tools/../lib/core/function.py", line 236, in train_da_ms
hm_loss2 = criterion(output2, target2, target_weight2)
File "/home/zhouzhiyi/anaconda3/envs/pep/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "/home/zhouzhiyi/workspace/6D/spacecraft-pose-estimation-main/landmark_regression/tools/../lib/core/loss.py", line 37, in forward
loss += 0.5 * self.criterion(heatmap_pred, heatmap_gt)
File "/home/zhouzhiyi/anaconda3/envs/pep/lib/python3.8/site-packages/torch/nn/modules/module.py", line 1110, in _call_impl
return forward_call(*input, **kwargs)
File "/home/zhouzhiyi/anaconda3/envs/pep/lib/python3.8/site-packages/torch/nn/modules/loss.py", line 529, in forward
return F.mse_loss(input, target, reduction=self.reduction)
File "/home/zhouzhiyi/anaconda3/envs/pep/lib/python3.8/site-packages/torch/nn/functional.py", line 3261, in mse_loss
expanded_input, expanded_target = torch.broadcast_tensors(input, target)
File "/home/zhouzhiyi/anaconda3/envs/pep/lib/python3.8/site-packages/torch/functional.py", line 75, in broadcast_tensors
return _VF.broadcast_tensors(tensors)  # type: ignore[attr-defined]
RuntimeError: The size of tensor a (147456) must match the size of tensor b (589824) at non-singleton dimension 1

Hi, thanks for opening the issue. I tested this code and an older version I have. This definitely looks like a bug. I'll investigate and commit the fix.


Refacor & Optimized string sizes and positions

Made variable sizes and positions depending on digits

Forgot version and ChangeLog

Thanks! I think in future, if you've created a pull request, you can actually just keep updating it by changing whatever branch you used (even master if you never created a branch) - so you don't have to close and reopen if you don't want to :)


Roll Engine from 3cda7f5807db to 5e487ba854cf (2 revisions)

https://github.com/flutter/engine/compare/3cda7f5807db...5e487ba854cf
2021-05-17<EMAIL_ADDRESS>Roll Skia from c1f641104531 to<PHONE_NUMBER>36 (4 revisions) (flutter/engine#26197)
2021-05-17<EMAIL_ADDRESS>fuchsia: Only send different ViewProperties (flutter/engine#26170)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/master/autoroll/README.md

Commit queue failed; closing this roll.


fixed typo in site/protocols.xml

@loadaverage Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@loadaverage Thank you for signing the Contributor License Agreement!

Thank you!


Change withPermission to accept getResourceHrn function

Now getResourceHrn function will define how to create a ResourceHrn out of a ApplicationRequest.
In future, we can have custom Apis with custom url patterns, it might get hard to parse resourceName and resourceInstanceId using a single parsing logic.
The urls that were not able to parsed correctly as of now:

/organizations/{organization_id}/users/{user_name}/attach_policies:
/organizations/{organization_id}/users/{user_name}/detach_policies:

As of now, multiple permissions will create different ActionHrn but it will create a single ResourceHrn to validate against policy.


CI: use GMP from Conan on Windows too

If GMP is available with Conan for windows, we can unset MPIR_INSTEAD_OF_GMP and use GMP on all platforms. Some time ago GMP was not compatible with Windows (or at least that was my impression) and that was why I added MPIR_INSTEAD_OF_GMP to libff. But perhaps now GMP from Conan works fine for Windows.

If GMP is available with Conan for windows, we can unset MPIR_INSTEAD_OF_GMP and use GMP on all platforms. Some time ago GMP was not compatible with Windows (or at least that was my impression) and that was why I added MPIR_INSTEAD_OF_GMP to libff. But perhaps now GMP from Conan works fine for Windows.

@yperbasis 👌 will try

core_test build gets the following errors now:
error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in unit_test.obj
error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in unit_test.obj

in
absl_hash.lib(hash.obj)
absl_city.lib(city.obj)
absl_low_level_hash.lib(low_level_hash.obj)
absl_raw_hash_set.lib(raw_hash_set.obj)
and finally:
C:\build\cmd\test\Debug\core_test.exe : fatal error LNK1319: 8 mismatches detected [C:\build\cmd\test\core_test.vcxproj]

It looks like absl and unit_test.cpp from core_test suddenly use different version of the CRT, but why? 🤔
It doesn't seem related to GMP though, could be that the Debug build on Windows CI is broken.

@mriccobene can you please give this PR a try on your Windows machine? Unfortunately, our Windows CI job does not build the silkworm target because it still suffers an issue (the dreaded compiler out of heap space in step 2).

@canepat I'd like to merge it, because it also fixes #1171 . GMP is used in precompile.cpp from core, and building core is verified by the CI. It is still nice to test the full build on Windows, and if there are any further issues with the silkworm target, I can address it in a new PR.


simple cloud modelling

To include the effect of clouds into exojax, I started from a simple model, like what petitRadtrans uses.
branch: feature/simple_clouds

redefined in #110


Add user defined inline collision boxes.

This adds an option colissionRectangles which takes objects {x, width, y, height} that cause collisions the same way going out of bounds does. Because we needed to keep the dots away from the center region of the page.

Deprecated since the 2.0.0 version, but this is a good feature to implement in the next releases!
Sorry for not merged your PR before :/


[8.2.x] ISPN-6241 Fix compilation error in integration tests

commons-logging 1.1 was exposing HTTPServletResponse, but
commons-logging 1.2 made the servlet-api dependency optional.

LGTM. I'll pull it quickly.

Integrated in 8.2.x. Thanks @danberindei !


Add possibility to add more images on one node

Hi,
A good solution is for all nodes support max 4 image one in top in left in right in down.
And possibility to make space or resize of images.
For make beautiful nodes...
Cordialy

Hi @liberodark,
This is an interesting advanced feature. I move in the queue for a future implementation.
Thanks.


Add controlDict.DDES support

I would suggest the following syntax:
controlDict:
    uses: controlDict.DES # copies the file controlDict.DES to controlDict before any other modifications
    deltaT: 1e-05

For reference, after discussing this topic following syntax to should be considered:
- operation: name
    uses:
        controlDict: controlDict.DES # copies the file controlDict.DES to controlDict before any other modifications
    ... other key-value-pairs ...

closing this as the PR has been merged.


Formula modificaiton for the estimation of recombinaiton rate

In the paper, the original formula is as follows:

r : recombiniation, i : i-th individual, j : j-th locus, seg_i,j : the segregation status of i-th individual and j-th locus.
Two issues are ambiguous.

How many loops does it carry on? If we regard looking for recombination events as comparing differences in segregation between two adjacent loci, it should be two loops. Otherwise, it is not two adjacent loci.
However, if we admit it should be two loops, we couldn't solve the loss of p(seg_j,j+1). That's a controversy.
What is the segregation probability? Should it be "a" float or a vector with a 1x4 dimension? According to the results, it should be a vector with a 1x4 dimension, so I think the indicator function is more likely a matrix with a 4x4 dimension (which is why I wrote indicator function A). We also regard the segregation probability as the maximum value, so seg_i,j will be the segregation status corresponding to the maximum segregation probability. Based on this explanation, it seems to solve this issue.

Further, is the conditional probability necessary? whether we can simplify them? In my perspective, the recombination rate is similar to the genetype error rate. When the peeling process is done, these parameters will be updated according to the output and then input to the next cycle. So they can be calculated, not based on the peeling. In other words, the peeling process has been completed, and the calculation of the recombination rate is supposed to focus on adjacent loci.
Another interesting explanation is that this recombination rate is not the total recombination rate but rather the recob rate per locus. The segregation status of two adjacent loci will have 16 possibilities; this formula manages to sum the 16 possibilities.

But it still loses the p(seg_j,j+1). From this perspective, except for the problem of "p(seg_j,j+1)" and the conditional probability, I came up with an alternative.
segregation status means the "pp","mp","pm","mm".

The formula I modified is as follows:

It is easy to see that I use the basic frame of the second formula, remove the conditional function, and multiply p(seg_i,j+1). This formula can be converted to the following one:

I used the example in the branch "feat_recomb_new" test whether the function works.

The true recombination event is

The column is the gap between adjacent loci, and the row is individual.
My code:

The output matrix is equal to "true recombination event "
Because the Default of segregation probability is [0.25, 0.25, 0.25, 0.25]. For two adjacent loci, basic formula will output 1. In theory, it is correct, but in practice, we prefer to regard them as having the same segregation status.
And the locus 1 and locus 2 of M2 individuals also have similar problems.

I think we should focus on the change between loci, so I set all recombination event with totally consistent segregation possibilities.

@AprilYUZhang
Thank you for the implementation! The result looks good!
Meanwhile, I want to share a few thoughts on the first equation given in the paper that might answer some of your questions. The equation is as follows:
$$
\begin{equation}
\gamma = \frac{1}{n} \sum_i \sum_{seg_{i, j}} \sum_{seg_{i, j + 1}} I(seg_{i, j} \neq seg_{i, j + 1}) p(seg_{i, j} | seg_{i, j - 1}) p(seg_{i, j}, g_i, g_f, g_m) p(seg_{i, j + 1} | seg_{i, j +2}).
\end{equation}
$$
Here, every term of the sum, including $p(seg_{i, j} | seg_{i, j - 1})$,  are scalars. The equation is for the average recombination rate between loci $j$ and $j + 1$ across all the individuals. When the calculation of the recombination rate is implemented, all of the segregation probabilities at the current step of the iteration algorithm are known. For each individual $i$, the variables $seg_{i, j}$ and $seg_{i, j + 1}$ could be one of ${pp, pm, mp, mm}$. So in total, there are $16$ terms to sum. However, $I(seg_{i, j} \neq seg_{i, j + 1})$ indicates only the $14$ terms such that the segregation statuses at the two loci are different are taken into account. The two conditional probabilities $p(seg_{i, j} | seg_{i, j - 1})$ and $p(seg_{i, j + 1} | seg_{i, j + 2})$ can be calculated via the segregation information at loci $j - 1$, $j + 1$, and $j + 2$ at the current iteration, and the recombination rate between loci $j - 1$ and $j$ and the rate between $j + 1$ and $j + 2$ calculated at the previous iteration. The term $p(seg_{i, j}, g_i, g_f, g_m)$ is the segregation probability for the specific $seg_{i, j}$.
The reason why $p(seg_{i, j} | seg_{i, j + 1})$ does not appear is because it involves the recombination rate which is what we are calculating. This sophisticated equation particularly allows the propagation of information across iterations so we can use the results we found before and also allows the propagation of information across all loci so that we can determine the recombination rate with the knowledge of all the neighboring loci.
Your algorithm for the recombination rate is correct, but it assumes that we have full knowledge of the genotypes, which is impossible in practice. It is a good interpreter of the data we have, but it doesn't infer anything more than what we currently have. Depending on what is our goal, whether we want another statistic of the current data or a better recombination rate estimation to improve the algorithm, we may stop here or explore other ways to take into account the uncertainties that lie in the data.

I agree that the true value couldn't be estimated in practice. As your explanation, although some issues still exist, whether we need to simplify it is that whether it must be part of iteration. At same time, It involved we should add this estimation in "Peeling.py" or "PeelingUpdateds.py". I prefer to estimate directly based on current segregation probablity, in other word, r should be updated in "PeelingUpdates.py", like genetype error etc. But It not means the calculation of recombination will not consider the information of adjacent loci and pedigree. When we calculate the segregation probability it should be considered. In theory, the more accurate segragation probability is, the more accurate recombination rate.

I tested again using the "accuracy_test". It supports your view. I read the true segregation probability "true-seg_prob.txt" and the estimated segregation probability "multi_seq_file/.seg_prob.txt". Also, I designed the two new recombination calculations. One is

excluding defualt value.
Another is the difference between adjacent loci.
# One
 def recom_f1(seg_prob_array,nInd,nLociAll):
    default_array=np.array([0.25,0.25,0.25,0.25])
    # Design indicator function
    indicator =np.array([[0, 1 , 1 , 2],
    [1 , 0 , 2 , 1],
    [1 , 2 , 0 , 1],
    [2 , 1 , 1 , 0]])
    # initialize the recombination event array
    recom=np.empty((nInd,nLociAll-1))
    for k in range(0,nLociAll-1):
        for j in range(0,nInd):
            # avoid that the dedault value causes the distortion of recombination event
            if np.all(seg_prob_array[j,k]==default_array) and np.all(seg_prob_array[j,k+1]==default_array) :
                recom[j,k]=0
            else:
                recom[j,k]=np.dot(np.dot(seg_prob_array[j,k],indicator),seg_prob_array[j,k+1])
    return recom

# Another
def recom_f2(seg_prob_array,nInd,nLociAll):
    # Design indicator function
    # initialize the recombination event array
    recom=np.empty((nInd,nLociAll-1))
    for k in range(0,nLociAll-1):
        for j in range(0,nInd):
            recom[j,k]=np.sum(np.abs(seg_prob_array[j,k]-seg_prob_array[j,k+1]))/2
            # avoid that the dedault value causes the distortion of recombination event
    return recom

Data
Method
Recombination events
Run time
total Recombination rate

True seg
-
1636
-
0.000818

Estimated  seg
One
939,659 (rec_prob>0)
6.3989 s
0.03

Estimated  seg
Sedond
496,372 (rec_prob>0)
4.6847 s
0.0012

It looks bad. So I manage to look through the details. The 200 th individual and 1716 th locus have recombiniation, the results as follows:
seg_prob_array_true:

loc-1
loc
loc+1
loc+2

[1. 0. 0. 0.]
[1. 0. 0. 0.]
[0. 1. 0. 0.]
[0. 1. 0. 0.]

seg_prob_array:

loc-1
loc
loc+1
loc+2

[2.875e-01 7.112e-01 4.000e-04 9.000e-04]
[3.330e-01 6.657e-01 5.000e-04 8.000e-04]
[3.796e-01 6.192e-01 5.000e-04 7.000e-04]
[3.796e-01 6.192e-01 5.000e-04 7.000e-04]

For this point
true recombination probability : 1.0
recombination probability (Mothod 1): 0.46257018
recombination probability (Mothod 2): 0.04659999999999998

This figure shows the recombination probability on the one individual (200 th). The pattens of peak fit the true recombination event.

This figure shows the recombination probability on the one individual (210 th).
Although it is not a perfect match, there will be fluctuations in the predicted value near each real recombination event. It is normal, the accuracy of estimation of seg for First and second generation groups is only around 0.1.
But when we see the results of 999 th individual, It is clear.

@XingerTang I agree that the true value couldn't be estimated in practice. As your explanation, although some issues still exist, whether we need to simplify it is that whether it must be part of iteration. At same time, we should add this estimation in "Peeling.py" or "PeelingUpdateds.py". I prefer to estimate directly based on current segregation probability; in other word, r should be updated in "PeelingUpdates.py", like genetype error, etc. But it does not mean the calculation of recombination will not consider the information of adjacent loci and pedigree. When we calculate the segregation probability, it should be considered. In theory, the more accurate the segregation probability, the more accurate the recombination rate.
Or this new formula could look like this:
 k is the pp,pm,mp,mm
Due to  So
And due to
So this formula will have more complex expression if countinue.
In total, I think segregation probability is a "directly estimated" parameter in iteration, while recombination should be a "indirectly estimated" parameter which can be estiamted from segregation probability.

@AprilYUZhang
In my understanding, in the implementation of the equation for the recombination rate proposed in the paper, there shouldn't be any matrix involved. I don't quite understand what $r_{i, j}$ here stands for. And, the terms you expanded also won't be used as a part of the calculation. For each term of the sum, $p(seg_{i, j}, g_i, g_f, g_m)$ is the segregation probability at the current iteration, $p(seg_{i, j + 1} | seg_{i, j + 2})$ can be calculated by
$$
\begin{align}
p(seg_{i, j + 1} | seg_{i, j + 2}) &= \frac{p(seg_{i, j + 1} \cap seg_{i, j + 2})}{p(seg_{i, j + 2})} \
&= \frac{\gamma p(seg_{i, j + 1} = seg_{i, j + 2}) + (1 - \gamma)p(seg_{i, j + 1} \neq seg_{i, j + 2})}{p(seg_{i, j + 2})}
\end{align}
$$
which there are several ways to calculate, but none needs further information on the adjacent loci. A similar calculation can also be applied to the other conditional probability used.
From your implementation, it seems that the simple algorithm may overestimate the occurrence of the recombination events. The equation in the paper involves three probability terms to multiply, which by intuition would yield a much smaller recombination rate. So I think this algorithm is still worth implementing.

I tested again using the "accuracy_test". It supports your view. I read the true segregation probability "true-seg_prob.txt" and the estimated segregation probability "multi_seq_file/.seg_prob.txt". Also, I designed the two new recombination calculations. One is  excluding defualt value. Another is the difference between adjacent loci.
# One
 def recom_f1(seg_prob_array,nInd,nLociAll):
    default_array=np.array([0.25,0.25,0.25,0.25])
    # Design indicator function
    indicator =np.array([[0, 1 , 1 , 2],
    [1 , 0 , 2 , 1],
    [1 , 2 , 0 , 1],
    [2 , 1 , 1 , 0]])
    # initialize the recombination event array
    recom=np.empty((nInd,nLociAll-1))
    for k in range(0,nLociAll-1):
        for j in range(0,nInd):
            # avoid that the dedault value causes the distortion of recombination event
            if np.all(seg_prob_array[j,k]==default_array) and np.all(seg_prob_array[j,k+1]==default_array) :
                recom[j,k]=0
            else:
                recom[j,k]=np.dot(np.dot(seg_prob_array[j,k],indicator),seg_prob_array[j,k+1])
    return recom

# Another
def recom_f2(seg_prob_array,nInd,nLociAll):
    # Design indicator function
    # initialize the recombination event array
    recom=np.empty((nInd,nLociAll-1))
    for k in range(0,nLociAll-1):
        for j in range(0,nInd):
            recom[j,k]=np.sum(np.abs(seg_prob_array[j,k]-seg_prob_array[j,k+1]))/2
            # avoid that the dedault value causes the distortion of recombination event
    return recom

I am a bit confused here as your equation for $r$ doesn't match any of your algorithms. Your first algorithm is your old simple algorithm, and your second algorithm is a modified version of your first algorithm by replacing the indicator with the numerical difference between the two segregation probabilities. Could you explain what is the equation of $r$ for?

@XingerTang I agree that the true value couldn't be estimated in practice. As your explanation, although some issues still exist, whether we need to simplify it is that whether it must be part of iteration. At same time, we should add this estimation in "Peeling.py" or "PeelingUpdateds.py". I prefer to estimate directly based on current segregation probability; in other word, r should be updated in "PeelingUpdates.py", like genetype error, etc. But it does not mean the calculation of recombination will not consider the information of adjacent loci and pedigree. When we calculate the segregation probability, it should be considered. In theory, the more accurate the segregation probability, the more accurate the recombination rate.
Or this new formula could look like this:
 k is the pp,pm,mp,mm
Due to  So
And due to
So this formula will have more complex expression if countinue.
In total, I think segregation probability is a "directly estimated" parameter in iteration, while recombination should be a "indirectly estimated" parameter which can be estiamted from segregation probability.

@AprilYUZhang In my understanding, in the implementation of the equation for the recombination rate proposed in the paper, there shouldn't be any matrix involved. I don't quite understand what ri,j here stands for. And, the terms you expanded also won't be used as a part of the calculation. For each term of the sum, p(segi,j,gi,gf,gm) is the segregation probability at the current iteration, p(segi,j+1|segi,j+2) can be calculated by
p(segi,j+1|segi,j+2)=p(segi,j+1∩segi,j+2)p(segi,j+2)=γp(segi,j+1=segi,j+2)+(1−γ)p(segi,j+1≠segi,j+2)p(segi,j+2)
which there are several ways to calculate, but none needs further information on the adjacent loci. A similar calculation can also be applied to the other conditional probability used.

It sounds good. My formula is not a new formula exactly; it is just a new expression approach, I use the predefined formula in paper to extend my original one. I just want to show more clearly that for every individual and locus, when we calculate whether the separation probability between two loci is the same, it is not as simple as 0 if they are the same, otherwise 1.  For example, for your formula that you mentioned
p(segi,j+1=segi,j+2)
What is your plan to calculate it? they are not only an observed value but also a vector for possibilities. So I guess you mean sum_k(p(segi,j+1,k=segi,j+2,k)), k is the pp,pm,mp,mm. it causes another question, for one individual and two adjanct loci, p(segi,j+1) = [0.1,0.2,0.3,0.4], p(segi,j+2) = [0.3,0.1,0.3,0.3], how can we compare the difference? In the perspective of math, It is simple, we just use p(segi,j+1)-p(segi,j+2), which is my second method I explored. but its total recombination rate is still higher than the real value.

From your implementation, it seems that the simple algorithm may overestimate the occurrence of the recombination events. The equation in the paper involves three probability terms to multiply, which by intuition would yield a much smaller recombination rate. So I think this algorithm is still worth implementing.

I agree that three terms will lead to a much smaller recombination rate, however, I don't think the recombination events are overestimated. As my figure shows, It can indicate that recombination events may happen. For example, Generations 0 and 1 easily get the wrong peak, but it is due to too little information from their parents rather than the recombination calculation formula. Even if we improve our formula to perfection, this issue still exists. But the recombination rate must be overestimated because the probability will repeat itself many times around the real recombination event.

@calculate_time
# the method from Xinger
def recom_f3(seg_prob_array,nInd,nLociAll):
    # Design indicator function
    # initialize the recombination event array
    r= 0.0008
    default_array=np.array([0.25,0.25,0.25,0.25])
    # Design indicator function
    indicator =np.array([[0, 1 , 1 , 2],
    [1 , 0 , 2 , 1],
    [1 , 2 , 0 , 1],
    [2 , 1 , 1 , 0]])
    # initialize the recombination event array
    recom=np.empty((nInd,nLociAll-1))
    for k in range(0,nLociAll-1):
        for j in range(0,nInd):
            # avoid that the dedault value causes the distortion of recombination event
            if np.all(seg_prob_array[j,k]==default_array) and np.all(seg_prob_array[j,k+1]==default_array) :
                recom[j,k]=0
            else:
                recom[j,k]=np.dot(np.dot(seg_prob_array[j,k],indicator),seg_prob_array[j,k+1])
    recom_added =np.empty((nInd,nLociAll-1))
    for j in range(0,recom.shape[0]):
        for k in range(0,recom.shape[1]):
            if k==0:
#                 seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))/seg_prob_array[j,k+2]
# because have zero that will lead to recombinaiton inf and nan, temporarily remove it
                seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))
                seg_i_j_1=1
            elif k == recom.shape[1]-1:
#                 seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))/seg_prob_array[j,k-1]
                seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))
                seg_i_jplus2=1
            else:
#                 seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))/seg_prob_array[j,k-1]
#                 seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))/seg_prob_array[j,k+2]
                seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))
                seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))
            recom_added[j,k]=np.nansum(seg_i_jplus2)*recom[j,k]*np.nansum(seg_i_j_1)

    return recom_added

I tried to realise your formula; is it correct?  if not, let me know, Thank you.
The results are as follows:

Data
Method
Recombination events
Run time
total Recombination rate

True seg
original
1636
5.0966 s
0.000818

True seg
based on difference
1636
3.6935 s
0.000818

True seg
based on Xinger's formula
1636
17.8770 s
0.00081569532128

Estimated seg
original
939,659 (rec_prob>0)
5.0581 s
0.0307

Estimated seg
based on difference
496,372 (rec_prob>0)
3.7187 s
0.00121

Estimated seg
based on Xinger's formula
939,635 (rec_prob>0)
17.9241 s
0.01313

The result looks not good, may I run something wrong?

@XingerTang I agree that the true value couldn't be estimated in practice. As your explanation, although some issues still exist, whether we need to simplify it is that whether it must be part of iteration. At same time, we should add this estimation in "Peeling.py" or "PeelingUpdateds.py". I prefer to estimate directly based on current segregation probability; in other word, r should be updated in "PeelingUpdates.py", like genetype error, etc. But it does not mean the calculation of recombination will not consider the information of adjacent loci and pedigree. When we calculate the segregation probability, it should be considered. In theory, the more accurate the segregation probability, the more accurate the recombination rate.
Or this new formula could look like this:
 k is the pp,pm,mp,mm
Due to  So
And due to
So this formula will have more complex expression if countinue.
In total, I think segregation probability is a "directly estimated" parameter in iteration, while recombination should be a "indirectly estimated" parameter which can be estiamted from segregation probability.

@AprilYUZhang In my understanding, in the implementation of the equation for the recombination rate proposed in the paper, there shouldn't be any matrix involved. I don't quite understand what ri,j here stands for. And, the terms you expanded also won't be used as a part of the calculation. For each term of the sum, p(segi,j,gi,gf,gm) is the segregation probability at the current iteration, p(segi,j+1|segi,j+2) can be calculated by
p(segi,j+1|segi,j+2)=p(segi,j+1∩segi,j+2)p(segi,j+2)=γp(segi,j+1=segi,j+2)+(1−γ)p(segi,j+1≠segi,j+2)p(segi,j+2)
which there are several ways to calculate, but none needs further information on the adjacent loci. A similar calculation can also be applied to the other conditional probability used.

It sounds good. My formula is not a new formula exactly; it is just a new expression approach, I use the predefined formula in paper to extend my original one. I just want to show more clearly that for every individual and locus, when we calculate whether the separation probability between two loci is the same, it is not as simple as 0 if they are the same, otherwise 1. For example, for your formula that you mentioned p(segi,j+1=segi,j+2) What is your plan to calculate it? they are not only an observed value but also a vector for possibilities. So I guess you mean sum_k(p(segi,j+1,k=segi,j+2,k)), k is the pp,pm,mp,mm. it causes another question, for one individual and two adjanct loci, p(segi,j+1) = [0.1,0.2,0.3,0.4], p(segi,j+2) = [0.3,0.1,0.3,0.3], how can we compare the difference? In the perspective of math, It is simple, we just use p(segi,j+1)-p(segi,j+2), which is my second method I explored. but its total recombination rate is still higher than the real value.

From your implementation, it seems that the simple algorithm may overestimate the occurrence of the recombination events. The equation in the paper involves three probability terms to multiply, which by intuition would yield a much smaller recombination rate. So I think this algorithm is still worth implementing.

I agree that three terms will lead to a much smaller recombination rate, however, I don't think the recombination events are overestimated. As my figure shows, It can indicate that recombination events may happen. For example, Generations 0 and 1 easily get the wrong peak, but it is due to too little information from their parents rather than the recombination calculation formula. Even if we improve our formula to perfection, this issue still exists. But the recombination rate must be overestimated because the probability will repeat itself many times around the real recombination event.

One possible way to calculate $p(seg_{i, j + 1} = seg_{i, j + 2})$ is by noting that both $seg_{i, j + 1}$ and $seg_{i, j + 2}$ are $4$-dimensional vectors, the angle $\theta$ that between the two vectors can be used to quantify the similarity between the two segregation probability vectors and hence used as an estimate of the probability $p(seg_{i, j + 1} = seg_{i, j + 2})$.
I understand your points, but if the probabilities around the locus where the real recombination event happened are summing up to more than $1$ then we need to normalize it to prevent the overestimation, the difference in scales of the algorithm and the real data is too large to be ignored.

@calculate_time
# the method from Xinger
def recom_f3(seg_prob_array,nInd,nLociAll):
    # Design indicator function
    # initialize the recombination event array
    r= 0.0008
    default_array=np.array([0.25,0.25,0.25,0.25])
    # Design indicator function
    indicator =np.array([[0, 1 , 1 , 2],
    [1 , 0 , 2 , 1],
    [1 , 2 , 0 , 1],
    [2 , 1 , 1 , 0]])
    # initialize the recombination event array
    recom=np.empty((nInd,nLociAll-1))
    for k in range(0,nLociAll-1):
        for j in range(0,nInd):
            # avoid that the dedault value causes the distortion of recombination event
            if np.all(seg_prob_array[j,k]==default_array) and np.all(seg_prob_array[j,k+1]==default_array) :
                recom[j,k]=0
            else:
                recom[j,k]=np.dot(np.dot(seg_prob_array[j,k],indicator),seg_prob_array[j,k+1])
    recom_added =np.empty((nInd,nLociAll-1))
    for j in range(0,recom.shape[0]):
        for k in range(0,recom.shape[1]):
            if k==0:
#                 seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))/seg_prob_array[j,k+2]
# because have zero that will lead to recombinaiton inf and nan, temporarily remove it
                seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))
                seg_i_j_1=1
            elif k == recom.shape[1]-1:
#                 seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))/seg_prob_array[j,k-1]
                seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))
                seg_i_jplus2=1
            else:
#                 seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))/seg_prob_array[j,k-1]
#                 seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))/seg_prob_array[j,k+2]
                seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))
                seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))
            recom_added[j,k]=np.nansum(seg_i_jplus2)*recom[j,k]*np.nansum(seg_i_j_1)

    return recom_added

I tried to realise your formula; is it correct? if not, let me know, Thank you. The results are as follows:
Data	Method	Recombination events	Run time	total Recombination rate
True seg	original	1636	5.0966 s	0.000818
True seg	based on difference	1636	3.6935 s	0.000818
True seg	based on Xinger's formula	1636	17.8770 s	0.00081569532128
Estimated seg	original	939,659 (rec_prob>0)	5.0581 s	0.0307
Estimated seg	based on difference	496,372 (rec_prob>0)	3.7187 s	0.00121
Estimated seg	based on Xinger's formula	939,635 (rec_prob>0)	17.9241 s	0.01313
The result looks not good, may I run something wrong?

@AprilYUZhang
The main difference between your implementation and my understanding is the way to calculate the conditional probabilities, specifically, it is the following line of your algorithm:
recom[j,k]=np.dot(np.dot(seg_prob_array[j,k],indicator),seg_prob_array[j,k+1])
The problems of the indicator matrix are:

The maximum value of the products is $2$, so if we are going to use it to estimate a probability, the product should always be divided by $2$.
Even for two segregation vectors that are exactly the same (both with a probability of $0.25$ for each possible combination), the indicator matrix can generate a recombination probability of $0.5$ after the normalization (division by $2$).

Both two problems are related to the algorithm for calculating recommendations from segregation probabilities. The expected value of recombination probability between 2 loci is 2 in biology. So when we calculate the recombination rate, the total number of recombination events is divided by 2nIndividual(nloci-1). (Your question reminds me that I make mistakes in the denominator. I used nIndividual*nloci, I will update table later.)
Take the example you mentioned of p(seg_locus 1) =  [0.25, 0.25, 0.25, 0.25] and p(seg_locus 2) =  [0.25, 0.25, 0.25, 0.25]. they looks the same, but they still have high probability of recombination. If the segregation status of loci 1 is "mm" with 0.25, and the segregation status of loci 2 is "pp" with 0.25, they do have a recombination event. So the same vector doesn't mean they have no recombinaiton.
As far as the angle replace indicator matrix, I will try.

Both two problems are related to the algorithm for calculating recommendations from segregation probabilities. The expected value of recombination probability between 2 loci is 2 in biology. So when we calculate the recombination rate, the total number of recombination events is divided by 2_nIndividual_(nloci-1). (Your question reminds me that I make mistakes in the denominator. I used nIndividual*nloci, I will update table later.) Take the example you mentioned of p(seg_locus 1) = [0.25, 0.25, 0.25, 0.25] and p(seg_locus 2) = [0.25, 0.25, 0.25, 0.25]. they looks the same, but they still have high probability of recombination. If the segregation status of loci 1 is "mm" with 0.25, and the segregation status of loci 2 is "pp" with 0.25, they do have a recombination event. So the same vector doesn't mean they have no recombinaiton. As far as the angle replace indicator matrix, I will try.

If the probabilities are truly 0.25, then the occurrence of the recombination events is reasonable, but here the number 0.25 is mostly due to the uncertainty. I am not sure if the dot product would work since it actually just your code with the indicator matrix removed and the computation with the indicator matrix makes more sense as it demonstrates the similarities of different segregation statuses. The only problem that the indicator matrix caused is in your implementation you need to divide it by 2 to make your dot product a proper approximation to the probability.

@calculate_time
# the method from Xinger
def recom_f3(seg_prob_array,nInd,nLociAll):
    # Design indicator function
    # initialize the recombination event array
    r= 0.0008
    default_array=np.array([0.25,0.25,0.25,0.25])
    # Design indicator function
    indicator =np.array([[0, 1 , 1 , 2],
    [1 , 0 , 2 , 1],
    [1 , 2 , 0 , 1],
    [2 , 1 , 1 , 0]])
    # initialize the recombination event array
    recom=np.empty((nInd,nLociAll-1))
    for k in range(0,nLociAll-1):
        for j in range(0,nInd):
            # avoid that the dedault value causes the distortion of recombination event
            if np.all(seg_prob_array[j,k]==default_array) and np.all(seg_prob_array[j,k+1]==default_array) :
                recom[j,k]=0
            else:
                recom[j,k]=np.dot(np.dot(seg_prob_array[j,k],indicator),seg_prob_array[j,k+1])
    recom_added =np.empty((nInd,nLociAll-1))
    for j in range(0,recom.shape[0]):
        for k in range(0,recom.shape[1]):
            if k==0:
#                 seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))/seg_prob_array[j,k+2]
# because have zero that will lead to recombinaiton inf and nan, temporarily remove it
                seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))
                seg_i_j_1=1
            elif k == recom.shape[1]-1:
#                 seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))/seg_prob_array[j,k-1]
                seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))
                seg_i_jplus2=1
            else:
#                 seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))/seg_prob_array[j,k-1]
#                 seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))/seg_prob_array[j,k+2]
                seg_i_j_1=(r*recom[j,k-1]+(1-r)*(1-recom[j,k-1]))
                seg_i_jplus2=(r*recom[j,k+1]+(1-r)*(1-recom[j,k+1]))
            recom_added[j,k]=np.nansum(seg_i_jplus2)*recom[j,k]*np.nansum(seg_i_j_1)

    return recom_added

I tried to realise your formula; is it correct? if not, let me know, Thank you. The results are as follows:
Data	Method	Recombination events	Run time	total Recombination rate
True seg	original	1636	5.0966 s	0.000409
True seg	based on difference	1636	3.6935 s	0.000409
True seg	based on Xinger's formula	1636	17.8770 s	0.000408
Estimated seg	original	939,659 (rec_prob>0)	5.0581 s	0.0153
Estimated seg	based on difference	496,372 (rec_prob>0)	3.7187 s	0.00061
Estimated seg	based on Xinger's formula	939,635 (rec_prob>0)	17.9241 s	0.00656
The result looks not good, may I run something wrong?

@AprilYUZhang I just noticed that your total recombination events are counted based on the rec_prob > 0, which explains why they are this many. Do you have the results of the total recombination events for these methods based on  rec_prob > 0.5? I think those numbers should be much smaller.

@AprilYUZhang
I reimplemented your method in another way. Basically, I calculated the recombination rate of $i$ th individual between the $j$ th locus and $j + 1$ th locus $p(recomb_{i, j})$ by
$$
p(recomb_{i, j}) =
\begin{bmatrix}
p(seg_{i, j} = (0, 0)) & p(seg_{i, j} = (0, 1)) & p(seg_{i, j} = (1, 0)) & p(seg_{i, j} = (1, 1))
\end{bmatrix}^T A
\begin{bmatrix}
p(seg_{i, j + 1} = (0, 0)) \
p(seg_{i, j + 1} = (0, 1))\
p(seg_{i, j + 1} = (1, 0)) \
p(seg_{i, j + 1} = (1, 1))
\end{bmatrix}
\tag{1}
$$
where the matrix $A$ is given by
$$
A =
\begin{bmatrix}
0 & 1 & 1 & 2\
1 & 0 & 2 & 1 \
1 & 2 &  0 & 1 \
2 & 1 & 1 & 0
\end{bmatrix}
$$
counts the number of the recombination events occurring between the loci $j$ and $j + 1$.
I managed to access the real recombination data at each locus for each individual, so I didn't average out the recombination rate across the individual, just that we can see the more precise information about whether the algorithm gives a correct estimation of the occurrence of the recombination events for each locus.
Same as what you've done, I used two datasets, the true segregation data and the estimated segregation data for the measures of the accuracies. The true segregation is obtained via the simulation data, while the estimated segregation data is obtained by the multi-loci peeling performed by the AlphaPeel accuracy test. So, there are 1999000 loci used in total and only 1636 recombination events have occurred, and no two recombination events have occurred at the same locus. Thus, for each locus, there is either no recombination or a single recombination occurred.
Given that we have very few recombination events compared to the total number of loci, I measure the accuracy based on two metrics, the recall rate and the precision rate.
The recall rate is the proportion of predicted positives that are actually positive to the total number of the positives in the original data, while the precision is the proportion of the predicted positives that are indeed positive to the total number of the predicted positives.
As there is no two recombinations have occurred at the same locus, the estimated recombination rates generated by the (1) are in the range of 0 to 1. So it is natural to set some number between 0 to 1 as the threshold for predicting whether a recombination event occurred at one particular locus. For example, if the threshold is 0.5, then we would predict the locus that has an estimated probability greater or equal to 0.5 to have a recombination event occur and the others have no recombination event.
I plotted the precision-recall curve for different values of the threshold that ranged from 0 to 1.
For the true segregation data input, the result is given by the following

While the recall is always 1, which indicates that all the positives have been successfully predicted, the precision is not very satisfying as the highest precision that could be achieved is only 0.004. It indicated that lots of loci which have no recombination event occurred have been classified as having recombination events occurred and this happened so often that 0.996 of the predicted recombinations are wrong.
As you have discussed before, it is probably caused by the $[0.25, 0.25, 0.25, 0.25]$ segregation inputs from the first generation, so I recalculated the precision-recall curve with the inputs from the second generation of the true segregation data, which is the following

Now, we have the desired result that the precision of 1 is also achieved for some thresholds. However, this is for the true segregation data, we may not be able to perform as well as this when we are using the estimated segregation data. So I recalculated the precision-recall curve for the full estimated segregation data, which is the following,

This indicates that the highest precision we could possibly achieve is 0.002 for different values of the thresholds, which means that there are always 0.998 estimated recombination events that are wrong. I also do the same calculation for the estimated data excludes the first generation,

In this case, we can have a relatively higher precision rate (but still very low) compared to the previous case, but it is only possible when the recall rate is very low, which indicates that we cannot classify the true positives and other cases very well based on this algorithm.

Given that the above method cannot find the recombination event without misclassifying locus has no recombination events to be having the recombination events and misclassifying the locus with recombination events occurred to be no recombination has occurred, I implemented several regression on true segregation data and estimated segregation data to find a better matrix $A$ in (1). Most of them suggest that the anti-diagonal should be negative. The matrix $A$ generated from the linear regression on the true segregation data is given by
$$
A =
\begin{bmatrix}
0 & 1 & 1 & -2 \
1 & 0 & -2 & 1 \
1 & -2 & 0 & 1 \
-2 & 1 & 1 & 0
\end{bmatrix},
$$
which is counterintuitive at the first sight. But the $-2$ on the anti-diagonal can be useful given that the it is very rare that two recombination occur at the same time, and with this matrix, for segregation probabilities equal to $[0.25, 0.25, 0.25, 0.25]$, it will give a recombination probability of $0$, which is what we expect from this case.
For the full true segregation data, the precision-recall curve is given by the following

which suggests that it can achieve the most ideal case (the precision and recall can both be 1 at the same time) that every recombination events are classified correctly.
For the full estimate segregation data, the precision-recall curve is given by the following

The precision-recall curve for the segregation data excludes the first generation is the same as this one. We can see that it is better then the previous case that for the same recall rate, this time we can achieve a higher precision rate, which means we can classify the true recombination events better. So for the implementation, this choice of $A$ is a better choice.
However, even for this choice of $A$, we can't find a value of threshold that both precision and recall are both high enough. Thus, I think it is still worth to explore the methods based on segregation probabilities of more of the neighboring loci. What do you think? @AprilYUZhang

@XingerTang , I think the reason why your first result has low precision is mainly the effect of the default value ([0.25,0.25,0.25,0.25]). For this problem, my solution is to set this recombination probability as 0, if x1 and x2 == [0.25,0.25,0.25,0.25]. Your method is good, and I also managed to do this before. I think the solution to getting high ROC is: 1. segregation probability may have space to get more accuracy; 2. we can use the recombination probability curve to estimate the recombination event. Now, Gregor and I try to use the Viterbi algorithm for iterative peeling to improve accuracy, as this issue .

@AprilYUZhang I tried the same method on the data without the first generation so most of [0.25,0.25,0.25,0.25] are already gone but the maximum precision that can be achieved is still about 0.09 with 2 on the anti-diagonal. For the use of the recombination probability curve, we first need to obtain recombination probabilities that are accurate enough. But, given the low precision, I'm afraid it is not that easy to estimate the occurrences of the recombination events based on the current method of the calculation of the recombination probabilities.

which data did you use? true segregation or estimate by AlphaPeel. Sorry, I don't understand your meaning. Do you mean that based on the principal , you agree, but based on the practice, you disagree? Or, you totally disagree, and low precision is one of the reasons.


Zero copy publisher example fails

I have been testing the examples_rclrs_minimal_pub_sub pkg, but zero copy publisher doesn't seem to be working properly.

I have tested the node on Ubuntu 22.04 (ROS2 Humble) and implemented CycloneDDS.

$ ros2 run examples_rclrs_minimal_pub_sub zero_copy_publisher
Error: Unsupported return code (RCL_RET_UNSUPPORTED).

Caused by:
    Loaning is not supported
[ros2run]: Process exited with failure 1

As far as I know, using load messages is considered experimental in ROS2. I would appreciate if one of contributors guide me to resolve this issue? Thanks in advance :)

@bxtbold could you elaborate a bit how you fixed it so that other users who have the same issue can solve it? Thanks


(chore) Updated BDD for Abort Functionality

Signed-off-by: Rahul M Chheda<EMAIL_ADDRESS>
What this PR does / why we need it:

Have updated the BDD testcase
Now, we patch the engine wit stop state, too check for resource deletion
Added a new Case, where the experiment name is wrong, so created resources will be terminated instantly.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Checklist:

[ ] Fixes #
[ ] Labelled this PR & related issue with documentation tag
[ ] PR messages has document related information
[ ] Labelled this PR & related issue with breaking-changes tag
[ ] PR messages has breaking changes related information
[ ] Labelled this PR & related issue with requires-upgrade tag
[ ] PR messages has upgrade related information
[ ] Commit has unit tests
[ ] Commit has integration tests

https://github.com/litmuschaos/chaos-operator/issues/170


java.lang.IndexOutOfBoundsException: Index: 0, Size: -1

I have a test application that is writing to many different databases of a couple different servers(everything remote). I am using OPartitionedDatabasePoolFactory, and again getting the pool and db from 3 db servers, and 3 databases on each server.  There is a great deal of concurrent access to OPartitionedDatabasePoolFactory and OPartitionedDatabasePool (these are threadsafe object right), however I seem to get the following at a random point when trying issue a query:
com.orientechnologies.orient.core.exception.OStorageException: Error on executing command: sql.select from GridElement where MapName = ? AND Key = ?
at com.orientechnologies.orient.client.remote.OStorageRemote.handleException(OStorageRemote.java:1507)
at com.orientechnologies.orient.client.remote.OStorageRemote.command(OStorageRemote.java:1065)
at com.orientechnologies.orient.client.remote.OStorageRemoteThread.command(OStorageRemoteThread.java:436)
at com.orientechnologies.orient.core.sql.query.OSQLQuery.run(OSQLQuery.java:71)
at com.orientechnologies.orient.core.sql.query.OSQLSynchQuery.run(OSQLSynchQuery.java:85)
at com.orientechnologies.orient.core.query.OQueryAbstract.execute(OQueryAbstract.java:33)
at com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx.query(ODatabaseDocumentTx.java:630)
at com.someorg.common.orientdbmapimpl.OrientDBAgentManager$MapBatchLoader.run(OrientDBAgentManager.java:99)
at com.someorg.common.orientdbmapimpl.ParallelExecutor$Runner.run(ParallelExecutor.java:80)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: -1
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at com.orientechnologies.orient.client.remote.OStorageRemote.getCurrentServerURL(OStorageRemote.java:1830)
at com.orientechnologies.orient.client.remote.OStorageRemote.beginRequest(OStorageRemote.java:1812)
at com.orientechnologies.orient.client.remote.OStorageRemote.command(OStorageRemote.java:976)
This is occurring at the client, there is nothing in the server logs, and there is only one ODatabaseDocumentTx per thread.  As a java developer, I have never seen IndexOutOfBounds exception and seen a size of -1, so only thing I can guess is that the arraylist is not being used in thread safe manner, corrupting the list.

What OrientDB version? Please specify always the version.

Sorry, version is 2.0.5, oracle jre 1.8.0_40 on solaris.


Ewwollesen issue3857

Summary
Added the line KillMode=mixed to the systemd service file in the applicable install files based on the issue linked below. Additionally, I fixed one of the files where the file format got messed up somehow.
Ticket Link
https://github.com/mattermost/docs/issues/3857

Hello @ewwollesen,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

Thanks for this, @ewwollesen! Very helpful. I've added Stu, who requested this change, as a reviewer as well as our Support lead just for extra eyes. Editorially this looks good to me!

Thanks for raising this @ewwollesen !
I can't seem to use the reviewer UI in Github right now.  I'm not seeing the approval part of the UI.  @justinegeffen  can you nudge my approval forward manually?

@sadohert - Thanks for reviewing this Docathon 2021 contribution for technical accuracy and completeness! Very much appreciated! Though GitHub's not letting you formally enter your approval, we have your feedback recorded.