[ENH] add function to convert neurovault collections to a NiMARE dataset

references #341

Changes proposed in this pull request:

creates a downloader for neurovault and converts to a NiMARE data, but I did not see the nilearn function referenced in #341, will refactor.

I don't think a nilearn-specific method is necessary. I just figured that, since nilearn already has functions for fetching from neurovault, we should leverage them. I'm happy to have a version that doesn't use nilearn, as long as it's not too bloated/unwieldy.

I don't think a nilearn-specific method is necessary. I just figured that, since nilearn already has functions for fetching from neurovault, we should leverage them. I'm happy to have a version that doesn't use nilearn, as long as it's not too bloated/unwieldy.

I don't have any principled objection to using the nilearn utility, though my experience with it a while back was that it's a bit clunky (but I was doing fairly specific things, so it's possible it was just the use case). @jdkent feel free to look into it, and if you decide it's cleaner to use it, that's fine with me.

I don't have any principled objection to using the nilearn utility, though my experience with it a while back was that it's a bit clunky (but I was doing fairly specific things, so it's possible it was just the use case). @jdkent feel free to look into it, and if you decide it's cleaner to use it, that's fine with me.

I'm not sure if we can assume that NeuroVault "variance" maps correspond to varcopes.

Agreed that it's definitely not safe to assume that maps named "variance" are varcopes; OTOH, without that assumption, there's not going to be any automated way to identify the variance maps, and users will be left to identify all map types manually. So I think it's reasonable to use that as a heuristic, and just make it clear to users that it's their responsibility to verify that the maps mean what they think they mean (either before or after the fact).
If we want to be careful about it, we could check the image arrays to verify that all values are >= 0 (because variances can't be negative), and then issue a warning (or possibly even exception) if that's not the case. But of course that still provides no guarantees.

I'm not sure if we can assume that NeuroVault "variance" maps correspond to varcopes.

Agreed that it's definitely not safe to assume that maps named "variance" are varcopes; OTOH, without that assumption, there's not going to be any automated way to identify the variance maps, and users will be left to identify all map types manually. So I think it's reasonable to use that as a heuristic, and just make it clear to users that it's their responsibility to verify that the maps mean what they think they mean (either before or after the fact).
If we want to be careful about it, we could check the image arrays to verify that all values are >= 0 (because variances can't be negative), and then issue a warning (or possibly even exception) if that's not the case. But of course that still provides no guarantees.

If we want to be careful about it, we could check the image arrays to verify that all values are >= 0 (because variances can't be negative), and then issue a warning (or possibly even exception) if that's not the case. But of course that still provides no guarantees.

I think it would probably be good to (1) try to use other maps to get variance maps when they are available (e.g., T + contrast) instead of the available variance maps and (2) log a warning for any variance maps coming from NeuroStars, since we don't know what units they use. WDYT?

If we want to be careful about it, we could check the image arrays to verify that all values are >= 0 (because variances can't be negative), and then issue a warning (or possibly even exception) if that's not the case. But of course that still provides no guarantees.

I think it would probably be good to (1) try to use other maps to get variance maps when they are available (e.g., T + contrast) instead of the available variance maps and (2) log a warning for any variance maps coming from NeuroStars, since we don't know what units they use. WDYT?

I think it would probably be good to (1) try to use other maps to get variance maps when they are available (e.g., T + contrast) instead of the available variance maps and (2) log a warning for any variance maps coming from NeuroStars, since we don't know what units they use. WDYT?

I'm on board with (2); (1) makes me a bit nervous. It's an empirical question as to whether there are more likely to be mistakes in identification of variance maps, or in other maps we use to generate variance maps... I'm not confident the answer is the former (e.g., I worry that some users will have even more trouble determining what the right maps to use as contrasts are).
I think at minimum the user should probably take some responsibility for this... maybe we need an argument or package-level setting that indicates how maps should be detected, where the default is to assume the user has it exactly correct (unless the map is obtained from a remote source, in which case we issue a warning), and fail with an exception if required maps are missing—but then also allow the user to explicitly indicate they want maps to be automatically computed when we determine that that's possible (though I think we should still prioritize use of existing variance maps over computation from other maps).

I think it would probably be good to (1) try to use other maps to get variance maps when they are available (e.g., T + contrast) instead of the available variance maps and (2) log a warning for any variance maps coming from NeuroStars, since we don't know what units they use. WDYT?

I'm on board with (2); (1) makes me a bit nervous. It's an empirical question as to whether there are more likely to be mistakes in identification of variance maps, or in other maps we use to generate variance maps... I'm not confident the answer is the former (e.g., I worry that some users will have even more trouble determining what the right maps to use as contrasts are).
I think at minimum the user should probably take some responsibility for this... maybe we need an argument or package-level setting that indicates how maps should be detected, where the default is to assume the user has it exactly correct (unless the map is obtained from a remote source, in which case we issue a warning), and fail with an exception if required maps are missing—but then also allow the user to explicitly indicate they want maps to be automatically computed when we determine that that's possible (though I think we should still prioritize use of existing variance maps over computation from other maps).

I'm on board with (2); (1) makes me a bit nervous. It's an empirical question as to whether there are more likely to be mistakes in identification of variance maps, or in other maps we use to generate variance maps... I'm not confident the answer is the former (e.g., I worry that some users will have even more trouble determining what the right maps to use as contrasts are).

TBH, my intuition is that contrast image units are clearer than variance image units, since the actual variance unit varies by package (and I believe even by tool within package- at least for AfNI), but it's also probably not worth the effort. If only modeling software was a field in the NeuroVault metadata! Then we could just hardcode in a dictionary mapping the software to the expected variance units...

I think at minimum the user should probably take some responsibility for this... maybe we need an argument or package-level setting that indicates how maps should be detected

That sounds pretty cool, although it also sounds like it would be difficult to implement.

I'm on board with (2); (1) makes me a bit nervous. It's an empirical question as to whether there are more likely to be mistakes in identification of variance maps, or in other maps we use to generate variance maps... I'm not confident the answer is the former (e.g., I worry that some users will have even more trouble determining what the right maps to use as contrasts are).

TBH, my intuition is that contrast image units are clearer than variance image units, since the actual variance unit varies by package (and I believe even by tool within package- at least for AfNI), but it's also probably not worth the effort. If only modeling software was a field in the NeuroVault metadata! Then we could just hardcode in a dictionary mapping the software to the expected variance units...

I think at minimum the user should probably take some responsibility for this... maybe we need an argument or package-level setting that indicates how maps should be detected

That sounds pretty cool, although it also sounds like it would be difficult to implement.

That sounds pretty cool, although it also sounds like it would be difficult to implement.

Sorry, that was a bit unclear. I didn't mean we would have some kind of DSL the user can use; I was just thinking of a string that indicates which of two or three standard modes to use—i.e., to assume that the passed data are correct and raise no warnings; to always compute the variance map from other maps when possible; etc. So it would involve no additional work beyond what's already under discussion except to give the user some control over what happens.

That sounds pretty cool, although it also sounds like it would be difficult to implement.

Sorry, that was a bit unclear. I didn't mean we would have some kind of DSL the user can use; I was just thinking of a string that indicates which of two or three standard modes to use—i.e., to assume that the passed data are correct and raise no warnings; to always compute the variance map from other maps when possible; etc. So it would involve no additional work beyond what's already under discussion except to give the user some control over what happens.

Updates on this pull request:

I provided an example on how I would expect someone to use this function

(looks like I need to fix formatting)

I added a dictionary option for users to specify how the images are specified on neurovault

EDIT: we could potentially also let users pass a dictionary specifying mappings onto image types. We could even conceivably allow them to pass regexes that operate over the file names. But let's not take that on right now; I'm just mentioning it here for future reference.

I can add a check for variance maps saying they need to be above zero.

@tyarkoni, I think I've covered what we talked about for this pull request, do you or @tsalo have time to give this another quick once-over?

This should fail on NIDM-Results-format NeuroVault collections like the 21 pain study one we use elsewhere, right?

In principle, I think this should be supported, but for right now I'm assuming each neurovault collection represents a single study as that covers the current use case for performing meta-analyses on the output of neuroscout.


[SPARK-44053][BUILD] Update ORC to 1.8.4

What changes were proposed in this pull request?

This PR aims to update ORC to 1.8.4.
Why are the changes needed?

This will bring the following bug fixes.

https://issues.apache.org/jira/projects/ORC/versions/12353041

Does this PR introduce any user-facing change?

No.
How was this patch tested?

Pass the CIs.

cc @dongjoon-hyun

Merged to master for Apache Spark 3.5.0.
Welcome to the Apache Spark community, @guiyanakuang !
I added you to the Apache Spark contributor group and assign SPARK-44053 to you.
I also merged https://github.com/apache/spark/pull/41592 to branch-3.4 for Apache Spark 3.4.1 too.
Also, thank you, @HyukjinKwon and @cxzl25 !


Implement support to the REQBODY_* variables in libmodsecurity

The following variables needs to be implemented inside libModSecurity:

REQBODY_ERROR
REQBODY_ERROR_MSG
REQBODY_PROCESSOR
REQBODY_PROCESSOR_ERROR
REQBODY_PROCESSOR_ERROR_MSG

More information about these variables can be found at ModSecurity reference manual: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual

The variables REQBODY_PROCESSOR_ERROR_MSG and REQBODY_ERROR_MSG are the same.
REQBODY_ERROR_MSG and REQBODY_PROCESSOR_ERROR are also the same.

REQBODY_PROCESSOR implemented at: 7cb27eb9fc80fba0237af72a5560740f10b24b8b

REQBODY_PROCESSOR_ERROR_MSG, REQBODY_ERROR_MSG, REQBODY_ERROR_MSG and REQBODY_PROCESSOR_ERROR were implemented at ebe84247580cbc7d0a68e6f974f12bd333f26fc1


BLD: avoid warnings for fprintf in f2py-generated C code

These happen for a Mingw-w64 based Windows build, where %zd is problematic.
Also pin Windows CI to numpy==1.21.5, because 1.22.1 is broken.

Okay, -D__USE_MINGW_ANSI_STDIO fixes the issues with "%zd" in f2py-generated code, but not these type of warnings coming from cython-generated C code:
scipy/sparse/csgraph/_matching.cp39-win_amd64.pyd.p/_matching.c:26097:13: warning: unknown conversion type character 'z' in format [-Wformat=]
26097 |             "%s.%s size changed, may indicate binary incompatibility. "
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
scipy/sparse/csgraph/_matching.cp39-win_amd64.pyd.p/_matching.c:26098:47: note: format string is defined here
26098 |             "Expected %zd from C header, got %zd from PyObject",
      |                                               ^
scipy/sparse/csgraph/_matching.cp39-win_amd64.pyd.p/_matching.c:26097:13: warning: too many arguments for format [-Wformat-extra-args]
26097 |             "%s.%s size changed, may indicate binary incompatibility. "
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Probably because Cython uses PyOS_snprintf here, which is a wrapper around vsnprintf rather than fprintf.


Is it working properly ?

Hey there
I could install all of it with no error.
" After starting a new game, you will be dropped in the Alternate Start - Live Another Life cell where you can customise your character, then configure your mods before you actually start playing. Stand still and wait until all messages have run through in the upper left corner (check the screenshot below). Then hit ESCAPE and create a manual save before you continue. "
That did not happen to me.
After starting the game i noticed :
1 - No substitles even if I select them to be displayed (I play in english but i'd like english substitles)
2 - It starts @Helgen  I thought we would start with START ANOTHER LIFE mod. I can see the mode ticked and active in MO2.
3 - In the game, MOD menu is empty but the surrounding landscapes are great so definetly modded
4 - When I do start the game using the Top right RUN Elysium SKSE in MO2, it keeps asking if it should start steam or not.
Please note that I did a clean uninstall and reinstall  of the game in C: via steam and as said, all the process of installing ELYSIUM was made with no error.
Can someone help ? I 'm running it on WIN 11.
Thanks

"4 - When I do start the game using the Top right RUN Elysium SKSE in MO2, it keeps asking if it should start steam or not."
To launch Skyrim with Elysium you need to run "Elysium SKSE" in MO2... can you not get past the "start steam" question?  If you are starting Skyrim by starting "SkyrimSE.exe" then you are starting the game without the modlist.

nobody ?


CropView have cropProps pass

Hi @YingtaoGuo ,

My issue is that suppose in the  print preview page of the two image other than cropview page second page, firstly we need to Edit  and crop the view with certain rotation or without rotation ,and save it the.api call and we send the rotation_degree and cropprops(which is topx., topy, bottomx, bottomy) the backend cropthe image and we preview it the second preview page means backend send the cropped image url. then we select suppose intial is square then we change it to Album then backend always send the cropprops which they changes from square to album or any print size change we need to use this croprops when edit the view to the cropview, we need use this cropprops to see the cropview so we and backend in the same flow. But currently i have on crop saved the transformation then edit then present the transformation as we discussed earlier using cropviewpresent type function can make a struct which contain cropprops and rotation degree every time we update they backend send this but we need to use this struct cropprops(topx, topy , bottomx, bottomy), and rotationdegree when edit to see the view     func cropProps(_ info: CropInfo) -> CropProps {
return CropProps(topX: Int(info.cropRegion.topLeft.x * info.originalPixels.width),
topY: Int(info.cropRegion.topLeft.y * info.originalPixels.height),
bottomX: Int(info.cropRegion.bottomRight.x * info.originalPixels.width),
bottomY: Int(info.cropRegion.bottomRight.y * info.originalPixels.height))
} this is for cropprops please provide PR to get this , can you do today this is on urgent basis how can we use that

@rahul6350
It is really hard for me to understand your real purpose. Can you format your post to make it easier to read?
Also what is cropviewpresent type? Mantis doesn't use this type currently.

In the print preview process, we handle images across multiple pages, specifically focusing on the interaction between the crop view and the preview page. Initially, when a user edits and crops an image, they can apply a certain rotation or no rotation at all. Once the image is edited, we save these details and make an API call, sending the rotation degree along with cropping properties (cropProps), which include coordinates: topX, topY, bottomX, and bottomY. The backend uses these details to crop the image and sends back a URL for the cropped image, which we display on the second preview page.
If the user changes the print format from an initial square to another format, such as an album, the backend recalculates and returns updated cropProps reflecting these changes. We must use these updated cropProps to maintain synchronization between the backend and our front-end view, ensuring the crop view is consistent with the backend's processing.
Currently, when a crop is saved, the transformation is retained for future edits. Using the cropViewPresent function, we maintain a struct that contains both cropProps and the rotation degree. This struct is updated whenever the backend sends new data. By employing this struct, we can effectively utilize the cropProps (topX, topY, bottomX, bottomY) and rotation degree to render the crop view accurately during editing. Below is a function that converts a CropInfo instance to CropProps:
func cropProps(_ info: CropInfo) -> CropProps {
return CropProps(
topX: Int(info.cropRegion.topLeft.x * info.originalPixels.width),
topY: Int(info.cropRegion.topLeft.y * info.originalPixels.height),
bottomX: Int(info.cropRegion.bottomRight.x * info.originalPixels.width),
bottomY: Int(info.cropRegion.bottomRight.y * info.originalPixels.height),
rotationDegree: info.rotationDegree // Assuming rotationDegree is a property of CropInfo
)
}cropviewpresenttype means in example project there is function presentcropview in which we present on the basis of transformation

Hi @guoyingtao in simple words When we crop the image we have saved the Transformation on edit we use this saved Transformation then crop region is shown as in presentWithPresetTransformation this function. But the thing is that suppose  func cropProps(_ info: CropInfo) -> CropProps {
return CropProps(topX: Int(info.cropRegion.topLeft.x * info.originalPixels.width),
topY: Int(info.cropRegion.topLeft.y * info.originalPixels.height),
bottomX: Int(info.cropRegion.bottomRight.x * info.originalPixels.width),
bottomY: Int(info.cropRegion.bottomRight.y * info.originalPixels.height))
}  when we crop the image and on the basis of cropping we sent the cropProps which is topx topy bottomx bottomy to backend and backend crop the image on the basis of it suppose we use this cropProps to the cropArea instead of transformation  saving can we do that for so on edit exact cropprops set to image and inside the cropbox crop region contain with complete image so basically instead of transformation struct we have topx topy bottomx bottomy cropprops then can we do that as we are doing transformation does please add and reply as soon as possible

@rahul6350
If the image is rotated, are topX, topY based on the original image or the rotated image?

on the basis of rotation because we send the rotation degree to the backend then backend rotate on the basis and send topx topy bottomx bottom y please do it i need it in urgent basis i did not understand in mantis how can i do that i basically only use transformation saving way  presentWithPresetTransformation in this function which has but now same behaviour want topx topy bottomx bottom y on tha basis

means rotated image

For rotation, it looks like your app only uses angles like 90, 180, 270 etc. Is my understanding correct?

@rahul6350
If no any rotation, you can use PresetTransformationType.presetNormalizedInfo(You may need to build normalized data based on the cropProps (topX, topY, bottomX, bottomY)
If any rotation happened, we have more work to do which may need to add a new type of PresetTransformationType.

@rahul6350
Please try PR #408 to see if it works for you.
You can set Config.cropViewConfig.presetTransformationType = .presetNormalizedInfo when you want to edit the image again after receiving cropProps and rotation data from your backend.
Also you need to build normalized crop info based on the cropProps (topX, topY, bottomX, bottomY) and set ImageRotationType based on your actual rotation.
For example, if the image size is 100 * 200(after rotation) and cropProps is (10, 40, 90, 160), then the normalized crop info should be CGRect(x: 0.1, y: 0.2, width: 0.8, height: 0.6)

how can we convert suppose topx topy bottomx bottom y to normalize info which is CGRect please if no rotation then how can we do that please tell step by step

backend send the cropprops how can we convert to CGrect for normalize info

need to paas CGRECT in presentNormalizeinfo so suppose TOPX topy bottomx bottom y is from backedn then how can convert cgrect and what is cgrect in this so we can paas

@rahul6350
Just did some tests for PR #408 and found some issues. Still need some time to solve them.

but can you need to paas CGRECT in presentNormalizeinfo so suppose TOPX topy bottomx bottom y is from backedn then how can convert cgrect and what is cgrect in this so we can paas explain

please explain once resolve the issues

@rahul6350
The normalized data can be built like below

create a CGRect based on cropProps (topX, topY, bottomX, bottomY)
divide origin.x and width in CGRect by image.width and divide origin.y and height in CGRect by image.height to make sure every value in CGRect is [0, 1]

I updated PR #408 and solved issues I found.
You can have a try to see if it works for you.

func normalizeCropInfo(cropProps: CropProps, imageSize: CGSize) -> CGRect {
// Calculate the origin and size of the crop rectangle
let originX = cropProps.topX / imageSize.width
let originY = cropProps.topY / imageSize.height
let width = (cropProps.bottomX - cropProps.topX) / imageSize.width
let height = (cropProps.bottomY - cropProps.topY) / imageSize.height
// Create and return a normalized CGRect
return CGRect(x: originX, y: originY, width: width, height: height)

} is this correct

not working

no transormation on edit occur of the image

 if let printId = printId,  let transform = cropFrameManager.savedTransFormation[printId], let cropProps = cropConfig.cropProps {
        let createrect = normalizeCropInfo(cropProps: cropProps, imageSize: image.size)

        config.cropViewConfig.presetTransformationType = .presetNormalizedInfo(normalizedInfo: createrect ?? .zero)
    }    func normalizeCropInfo(cropProps: CropProps, imageSize: CGSize) -> CGRect {
    // Calculate the origin and size of the crop rectangle
    let originX = CGFloat(cropProps.topX ?? .zero) / imageSize.width
    let originY = CGFloat(cropProps.topY ?? .zero) / imageSize.height
    let width = CGFloat(cropProps.bottomX ?? .zero) - CGFloat(cropProps.topX ?? .zero)  / imageSize.width
    let height = (CGFloat(cropProps.bottomY ?? .zero) - CGFloat(cropProps.topY ?? .zero) ) / imageSize.height

    // Create and return a normalized CGRect
    return CGRect(x: originX, y: originY, width: width, height: height)
}in this way we create but it is wrong previously when present info paas and use that saved tranformation it works but in this when use cgrect on the basis of cropprops not work can you pleasee explain how can i do that where iam wrong?

Hey @guoyingtao rotation not working in this flow without rotation working fine but in rotation suppose i rotate one time in clockwise direction so roationType is counterclockwise270 but after transform and paasing this roationtype in edit it will rotate to 180 same when 180 rotation it will roate to .none angle is not correct

@rahul6350
I tested by using Example project and it worked fine. I can't tell the why it doesn't work for your case but looks like it calculated with the saved transformation and presetNormalizedInfo.
Also can you format your posts to make it easier to read?

Can you provide the code where you tested because cropprops passing is fine but scale zooming i say this the issue because we do not adjust scale in this i think that why

Below is the video for counterclockwise270
 config.cropViewConfig.presetTransformationType = .presetNormalizedInfo(normalizedInfo: CGRect(x: 0.1, y: 0.2, width: 0.8, height: 0.7), imageRotationType: .counterclockwise270)

https://github.com/user-attachments/assets/46a1e336-acfb-45de-9f46-a50346e7edd7

@rahul6350
You can modify function presentWithPresetTransformation in ViewController in Example project and use some code like below (You need to comment out  config.cropViewConfig.presetTransformationType = .presetInfo(info: transform))
config.cropViewConfig.presetTransformationType = .presetNormalizedInfo(normalizedInfo: CGRect(x: 0.1, y: 0.2, width: 0.8, height: 0.7), imageRotationType: .counterclockwise270)

Can you zoom to the crop area then edit then on edit zooming not to that level i cant share the video video is too loarge not sharable error that why

can you check these 4 screen shots on preview page have cropped image from backend when crop and rotate and when backend send the cropprops and rotationtype then on edit these are the two image usign presentnormalizeinfo huge diffrenece in without rotation it is not zooming to that instant due to which extra  things space inside the box is  show and roation is 270 but on edit rotation is 180 type i dont know

please available need to close help me out

I don't quite understand the cropping logic of your backend server.
In Mantis, after rotating the image, the image scale will change to adapt the editing view but the cropping region is kept the same.
https://github.com/user-attachments/assets/dc6d86f5-0594-400d-891d-a890170183a6

No backend serve the cropping logic of google photos but on presentransform it will scale or zoom to that level , because when cropping i save the whole tranofrmation strut in cropout and on edit it use it will correctly zoom to that level but in this it is not i dont know why and roation is also work fine in presentinfo tranformation logic please check zoom or scaling

If you only want to restore the image editing status based on the data returned from the backend server or Google photos, you don't need to save the whole transformation which is for rotating any angles. I see in your case, you only rotate degrees like 90, 180, 270 etc, right?

I think can you do the scaling or zooming are you understand what iam tried to say can you look at two image in preview and edit page withour roattion extra margins or things in edit not scale to that extent

You mentioned if no rotation, it works fine. Is the scale also correct if no rotation?

If you only want to restore the image editing status based on the data returned from the backend server or Google photos, you don't need to save the whole transformation which is for rotating any angles. I see in your case, you only rotate degrees like 90, 180, 270 etc, right?

yes but when backend not serve the cropprops and rotationdegree when we cropping we saved the whole transformation and use that tranformation in presentInfo and pass the save tranformation it work fine zooming scaling but in this when backend serve cropprops in presentnormalizeinfo when paas cgrect scaling or zooming not working can you skip the rotation part currently zooming and scaling  to that instant. not work in without rotation firstly

You mentioned if no rotation, it works fine. Is the scale also correct if no rotation?

the main problem scale is not correct my main point is this in rotation as well in without rotation scale is not correct before in present info when saved transformaiton it is correct in presentnormalizeinfo it is not correct

cropprops is correct to that tranform but scale is not

please explain how can we solve this

Hi @rahul6350
Can you use some tool like ChatGPT to format your post, it is a little hard for me to follow you since no punctuations in your post.

When the backend does not provide cropProps and rotationDegree, we save the entire transformation during cropping and use that transformation in presentInfo. Passing the saved transformation works fine for zooming and scaling.
However, when the backend provides cropProps, we use presentNormalizedInfo, and when passing a CGRect, the scaling or zooming does not work properly.
Can you skip the rotation part, currently focusing on zooming and scaling? Without rotation, the zooming and scaling should work instantly.

Scale is not correctly work in without rotation are you understand ?

pls explain

Is the cropping region correct if the scale is not correct?

yes cropping region is correct

is this solved?

Can you post two images (They have the same cropping region) and one is with correct scale (calculated with saved transformation data), the other one with wrong scale(calculated with presentNormalizedInfo)? It can help me understand the issue better. Thanks.

sure

Also if you don't zoom manually and only crop the image, is the scale correct when using presentNormalizedInfo?

yes when zoom manually then incorrect otherwise correct

when i think scale issue
?

1st image is presentInfo tranformation and 2nd is presentinfonormalize

pls explain

can we use google meet to solve the issue?

can we use google meet to solve the issue?

Sorry, I still have other work to do. I can not use Google meet

can we use google meet to solve the issue?

Sorry, I still have other work to do. I can not use Google meet

ok but please solve it its very urgent for me

I hope you understand it takes time to figure out the reason of the issue. Especially I don't know the detail of your project.
Please be patient.

I also have other work to do. I can't assure I have enough time to work on it according to your pace.

Will you get the issue these two images show the difference same crop region 1st give correct 2nd not give correct will you get it ?

I also have other work to do. I can't assure I have enough time to work on it according to your pace.

will try please if you take time its ok but i tried not able to figure out

can we use presentinfo scale  in this presentinfonormalize

No matter you manually zoom or not, as long as the normalized info is calculated correctly, the scale is always the same. So no need to use scale for presetNormalizedInfo type because it is automatically calculated based on the  normalized info.
If the scale is not correct, it could be the normalized info is not correct.

means according to you CGRect is not correct

func normalizeCropInfo(cropProps: CropProps, imageSize: CGSize) -> CGRect {
// Calculate the origin and size of the crop rectangle
let originX = CGFloat(cropProps.topX ?? .zero) / imageSize.width
let originY = CGFloat(cropProps.topY ?? .zero) / imageSize.height
let width = CGFloat(cropProps.bottomX ?? .zero) - CGFloat(cropProps.topX ?? .zero)  / imageSize.width
let height = (CGFloat(cropProps.bottomY ?? .zero) - CGFloat(cropProps.topY ?? .zero) ) / imageSize.height
// Create and return a normalized CGRect
return CGRect(x: originX, y: originY, width: width, height: height)

} is this correct method to calculate cgRECT  on the basis of cropprops and always pass the image.size original image size

Looks correct.
If you do a test in presentWithPresetTransformation function with normalizedInfo: CGRect(x: 0.0, y: 0.0, width: 1.0, height: 1.0), you will get the whole image.

so if normalize info is correct then whats the issue

If you do nothing, just crop the whole image, what data will return from the backend?

Let us say you are using Square 4*4 inches, just crop the image with the default crop box without changing the crop region, what data will return from the backend?
Can you post your test image size and the returned data?

sure

for square cgrect without cropping have default x = 0.4 y = 0.5 width = 1.1

For a vertical image like below, using the square crop box and the default crop region will get x = 0 and width = 1
I am not sure why your backend returned the normalized x = 0.4 and the normalized width is greater than 1

(0.0, 0.0, 1.0, 1.0) create rect is this for square default

yes x is o width is 1 it is correct for backend

Hey i check the values of presentInfo and presentNormalizeINfo found one thing is that in offset and scale both are diffrent when cropping i don't know why

Hey @guoyingtao public func getTransformInfo(byNormalizedInfo normalizedInfo: CGRect, imageRotationType: ImageRotationType) -> Transformation  in this function you have made a switch statement on the basis of imageRotationType and write offset and rotation radius , but when rotate suppose one time clockwise it will show like we rotate 2 time one clockwise rotation imagerotation type is counterclockwise270 but it show 180 type if we remove roation radius then on the .none case offset work fine but other case it is not i dont know the reason pls make us such that it rotate perfectly

@rahul6350
You can use presentWithPresetTransformation function in Example project to have a test. For example, you can use
 config.cropViewConfig.presetTransformationType = .presetNormalizedInfo(normalizedInfo: CGRect(x: 0.1, y: 0.2, width: 0.5, height: 0.5), imageRotationType: .counterclockwise270)

I did some tests and the rotation results were correct.

The screenshot below shows the result using config.cropViewConfig.presetTransformationType = .presetNormalizedInfo(normalizedInfo: CGRect(x: 0.1, y: 0.2, width: 0.5, height: 0.5), imageRotationType: .counterclockwise270)

suppose when we rotate and save have we send the rotated image or saved image if we send the rotated image it is incorrect and when we send the original image it is correct rotation but offset slightllt wrong not correctly as we seen but when crop again it break

presetTransformationType is always for the original image

But i have use when rotated in presentInfo rotated imag and crop the rotated image works fine , but in the cropprops case when we send the original image instead of rotated Image and function show the rotation in transform it is correct but when crop the rotated image in this case it is wrong because backend give in response is Wrong dimensions

But i have use when rotated in presentInfo rotated imag and crop the rotated image works fine , but in the cropprops case when we send the original image instead of rotated Image and function show the rotation in transform it is correct but when crop the rotated image in this case it is wrong because backend give in response is Wrong dimensions

I don't quite understand it. What do you mean wrong dimensions? Again, Is the response data from backend based on the original image or the rotated one?

There has been no reply to this ticket for a while, so I am closing it for now. You can reopen it anytime if needed.

There has been no reply to this ticket for a while, so I am closing it for now. You can reopen it anytime if needed.


helm - configmap created is misaligned

Is this a request for help?:
Yes
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
Bug Report
Version of Helm and Kubernetes:
helm version v2.12.3
tiller version v2.12.3
Kubernetes api v1.12.3
What happened:
snippet of server-configmap.yaml
...
data:
{{ range $key, $value := .Values.serverFiles  }}
  {{ $key }}: |-
{{ toYaml $value | default "{}" | indent 4 }}
{{- end -}}
{{- end -}}

after adding the below on values.yml file
serverFiles:
...
- job_name: 'consul_sd'
  consul_sd_configs:
    - server: 'consul_server:8500'

and running helm template .
the configmap shows up as:
- consul_sd_configs:
  - server: consul_server:8500
  job_name: consul_sd

What you expected to happen:
- job_name: consul_sd
  consul_sd_configs:
    - server: consul_server:8500

It seems like the the configmap is saved in alphabetical order.
consul_sd_config comes first and job_name comes underneath it, which causes the app to fail.
is there is any way to stop helm template to stop sorting  (alphabetical order) before it writes to the configmap? or anything i can do to make - job name comes first and consul_sd_configmap underneath it

Try using nindent instead of indent. The former indents all lines, whereas the latter indents only the first line.

Hi Matthew,
I tried using nident but still get the following output when running helm
template .
- consul_sd_configs:
- server: <IP_ADDRESS>:8500
token: aasas
job_name: consul_sd
whereas i wanted it to be :
-  job_name: consul_sd
consul_sd_configs:
- server: <IP_ADDRESS>:8500
On Mon, 25 Feb 2019 at 02:17, Matthew Fisher<EMAIL_ADDRESS>wrote:

Try using nindent instead of indent. The former indents all lines,
whereas the latter indents only the first line.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/5351#issuecomment-466848719, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHN3jf8X1GFQ-j0o2QTExh0qAvFotAlRks5vQ0fRgaJpZM4bO3jw
.

Hi Matthew,
I tried using nident but still get the following output when running helm
template .
- consul_sd_configs:
- server: <IP_ADDRESS>:8500
token: aasas
job_name: consul_sd
whereas i wanted it to be :
-  job_name: consul_sd
consul_sd_configs:
- server: <IP_ADDRESS>:8500
On Mon, 25 Feb 2019 at 02:17, Matthew Fisher<EMAIL_ADDRESS>wrote:

Try using nindent instead of indent. The former indents all lines,
whereas the latter indents only the first line.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/5351#issuecomment-466848719, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHN3jf8X1GFQ-j0o2QTExh0qAvFotAlRks5vQ0fRgaJpZM4bO3jw
.

Hi Matthew,
I tried using nident but still get the following output when running helm
template .
          - consul_sd_configs:
            - server: consul_server:8500
            job_name: consul_sd

whereas i wanted the output to be :
          -  job_name: consul_sd
             consul_sd_configs:
               - server:  consul_server:8500

somehow toYaml is parsing/formatting it alphabetically.
On Mon, 25 Feb 2019 at 02:17, Matthew Fisher<EMAIL_ADDRESS>wrote:

Try using nindent instead of indent. The former indents all lines,
whereas the latter indents only the first line.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/helm/helm/issues/5351#issuecomment-466848719, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHN3jf8X1GFQ-j0o2QTExh0qAvFotAlRks5vQ0fRgaJpZM4bO3jw
.

The suggestion by @bacongobbler was to fix the indentation in the generated yaml. This is the output I get which tidies it up:
 consul_sd_configs:
 - server: consul_server:8500
 job_name: consul_sd

If this did not fix the issue and you need the output in a particular order, can you show the template code that needs this order? It might help give an understanding of the issue.

I'm going to close this ticket due to inactivity, but please re-open if this still needs to be addressed. Thanks!


how to write a matrix with liner label and row label

I wanna write a matrix with liner label and row label.
I have tried some envrionment such as {bordermatrix} and so on, but compiler can`t deal with it correctly.
Code below is the Latex code which I have tried:
$\bordermatrix{%
& 0 & 1 & 2 \cr
0 & A & B & C \cr
1 & d & e & f \cr
2 & 1 & 2 & 3 \cr
}$

oops, I  forget to say : Thanks!

That's neither a bug nor a feature request. I guess you'll find answers on https://tex.stackexchange.com/.


8995: Fix DelayedJobChecker to check DB

Thanks! And your instinct to make DelayedJobChecker its own class was obviously correct!


Prelude file

🚀 Feature request
Hi guys, the project is awesome, but for newcomers from other FP languages would be much easier to start coding if there was some Prelude file with all basic types and combinators, like Array, Option, map, flatMap, filter, find, etc.  This would drammatically decrease effort necessary to adapt to new syntax, would remove necessity to grep the repo to find how to apply, for instance, Filterable type class. This is all basic stuff which usually works out-of-the-box in Scala or Haskell without any imports.
Current Behavior
Necessary to import a lot of files to write something like this (in plain TS):
let xs: number[] = [1,2,3,4,5,6,7];

let result = xs
  .filter(x => x % 2 === 0)
  .map(x => x ** 2)
  .find(x => x % 3 === 0);

console.log(result);

Desired Behavior
Would be awesome if the snippet above would be implementable without more than 1-2 imports and several method renamings.
Who does this impact? Who is this for?
For newcomers from other FP languages like Scala or Haskell.
Describe alternatives you've considered
To add docs page how to import all the core stuff.

Here's something I'm using in a prelude.ts file, it would be interesting to hear from others, too. I don't know whether this would be generalizable, as there's a conflict between wanting to keep the names as short as possible, but not interfering with other people's code.
import * as Ar from "fp-ts/lib/Array";
import * as E from "fp-ts/lib/Either";
import * as Eq from "fp-ts/lib/Eq";
import * as Ma from "fp-ts/lib/Map";
import * as An from "fp-ts/lib/NonEmptyArray";
import * as O from "fp-ts/lib/Option";
import * as Ord from "fp-ts/lib/Ord";
import * as R from "fp-ts/lib/Record";
import * as Te from "fp-ts/lib/TaskEither";
import * as io from "io-ts";
import * as nt from "newtype-ts";

export * from "fp-ts/lib/function";
export * from "fp-ts/lib/pipeable";
export { An, Ar, E, Eq, Ma, O, Ord, R, Te, io, nt };

Also, there's fp-ts-ramda, which @giogonzo is experimenting with, that uses fp-ts under the hood but provides the convenient functions from Ramda.

I wrote my own prelude package for my current projects. It doesn't contain all of fp-ts and io-ts. Just the main stuff I'm using. Below is an example of how I use the imports in a project.
import * as P from 'maasglobal-prelude-ts';
P.Either    // static type
P.Either    // io-ts codec
P.Either_   // fp-ts utils
P.Either__  // fp-ts type class implementations


Update front-door-diagnostics.md

The JSON file contains public IP address, URL and a resource ID with a subscription ID and resource information.
I removed the sensitive information:
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/ResourceName",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "
http://www.example.com:80/"
,
"originName": "
www.example.com"
,
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}

@duongau
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


[material-ui][FilledInput] Remove unapplied classes from filledInputClasses interface

Documentation says following classes are applied when necessary conditions are met but actually none of the classes are applied. I've written test case to validate same here

.MuiFilledInput-sizeSmall
.MuiFilledInput-multiline
.MuiFilledInput-adornedEnd
.MuiFilledInput-adornedStart
.MuiFilledInput-inputSizeSmall
.MuiFilledInput-inputMultiline
.MuiFilledInput-inputAdornedStart
.MuiFilledInput-inputAdornedEnd
.MuiFilledInput-inputTypeSearch

we can do either of the following

to remove above classes from filledInputClasses interface and from docs. that's what this PR does
to add above classes to applicable elements and don't remove any classes from filledInputClasses interface

@DiegoAndai which approach you recommend

[x] I have followed (at least) the PR section of the contributing guide.

This is a difficult one. InputBase also has these classes, should that component host them, or should each of the inputs (Standard, Outlined, Filled) host them 🤔
With the current architecture, it seems more useful for users that each input hosts their own classes. This might also change when we update the styles and theme structure, so we might want to avoid breaking changes until then.
What do you think @aarongarciah

Hey, I think most of the above classes selector behavior can be achieved by combining the FilledInput root class and the has selector. Even if we add them now, they can be deprecated and removed in the future.

The problem is also present in Input, FilledInput, and OutlineInput. So whatever we land on we should apply changes on them, too.
@DiegoAndai I'm inclined to think that every input should host their own classes so consumers can target them individually. If they want to target elements or states common to all inputs, they can target the InputBase classes.
@sai6855 even when :has is widely supported, I think is very valuable for consumers to have these static classes they can target as part of the components' public APIs. By removing classes, consumers would need to know about components' internal DOM structure and other details that classes help abstract.

By removing classes, consumers would need to know about components' implementation details that classes help abstract.

@aarongarciah I'm not sure if you are aware of this issue https://github.com/mui/material-ui/issues/41282 but TL DR; of the issue is, we are deprecating composed classes which can be achieved through css selctors. For example .MuiStepConnector-lineHorizontal is deprecated in favour of .MuiStepConnector-horizontal > .MuiStepConnector-line, so with this change, consumers of compoents are expected to know internal structure of componets.
docs link for same: https://deploy-preview-41740--material-ui.netlify.app/material-ui/migration/migrating-from-deprecated-apis/#composed-css-classes-8

@sai6855 TIL! Thanks for bringing it to my attention. Then removing composed classes that are unused makes sense. Forget my previous comment except:

The problem is also present in Input, FilledInput, and OutlineInput.

we can do either of the following

to remove above classes from filledInputClasses interface and from docs. that's what this PR does
to add above classes to applicable elements and don't remove any classes from filledInputClasses interface

@DiegoAndai which approach you recommend

I think option 3:
From that list, remove the composed classes, and add the ones that are not composed. So for example:

Add  .MuiFilledInput-sizeSmall
Remove .MuiFilledInput-inputAdornedStart. No need to deprecate it if it never worked

Does that make sense?

@DiegoAndai yes, I think that makes sense

@DiegoAndai i went with your suggestion. commit for change -> https://github.com/mui/material-ui/pull/42082/commits/29454775e6fd88c55a9fcf8b697488a8a64f990d
Summary of changes :

Removed following classes

.MuiFilledInput-inputSizeSmall
.MuiFilledInput-inputMultiline
.MuiFilledInput-inputAdornedStart
.MuiFilledInput-inputAdornedEnd
.MuiFilledInput-inputTypeSearch

Added following classes to FilledInput root

.MuiFilledInput-sizeSmall
.MuiFilledInput-multiline
.MuiFilledInput-adornedEnd
.MuiFilledInput-adornedStart
.MuiFilledInput-hiddenLabel

Ping @DiegoAndai


Feature/dataset editions page

What
Added handler and template for dataset editions list page
How to review

Pull feature/dataset-editions-page branch on dp-frontend-renderer
Pull the latest cmd-develop of the dataset API and make sure the editions end point returns the latest_version url for each edition, e.g.

{
     edition: "2016",
          links: {
               dataset: {
                    id: "95c4669b-3ae9-4ba7-b690-87e890a1c67c",
                    href: "http://localhost:22000/datasets/95c4669b-3ae9-4ba7-b690-87e890a1c67c"
               },
               latest_version: {
                    href: "http://localhost:22000/datasets/95c4669b-3ae9-4ba7-b690-87e890a1c67c/editions/2016/versions/2"
               },
               self: {
                    href: "http://localhost:22000/datasets/95c4669b-3ae9-4ba7-b690-87e890a1c67c/editions/2016"
               },
               versions: {
                    href: "http://localhost:22000/datasets/95c4669b-3ae9-4ba7-b690-87e890a1c67c/editions/2016/versions"
               }
          },
     state: "published"
}

Creating a new instance for the edition should create the latest_version field or it can be added to MongoDB manually (e.g. Robo3T)

Who can review
Anyone

:+1:


Limit number of threads used by heavyweight processes for photo scanning

This only affects the case when number of heavy weight processes is more than one. In that case multiprocessing is forced to use spawn instead of fork and env var OMP_NUM_THREADS is set to limit thread usage per process. On my machine (16 cores, 64 gb RAM) I was able to see about ~8x speedup on scanning using 16 heavy processes compared to ~2x before this change.

That sounds like a great improvement! Probably, some forks blocking each other. How does this change impact RAM usage? It should be higher as each process gets its own resources, but the question is by how much.

Thank you for taking a look, @derneuere . I will measure the memory usage difference and comment here.
Just wanted to clarify that the change fork-to-spawn here is only required to apply OMP_NUM_THREADS=<N> to the heavy weight processes. I can observe same speedup for scanning with absolutely no code changes if I just set env var OMP_NUM_THREADS=<N> for the entire backend container (e.g. N==1 when using 16 heavy weight processes).
But there are reasons to not apply that env var to the entire container. Most important reason is because applying OMP_NUM_THREADS=1 to the entire backend container could slow down any other part outside of scanning photos (e.g. CLIP embedding computation would get a huge performance hit on multicore machines - in my case they were ~4-5x slower). It is possible to "undo" the effect for that job, but that would require explicit effort for each case when full threading is required (such as spawning a separate process for CLIP embedding computation).

Regarding memory usage: with 16 heavy processes I've seen peak memory usage of ~16gb before this change and ~19gb with the change. The measurements were done with docker stats command and eyeballing so might not be the most accurate.

I had a chance to look more into the memory usage and also learned about django rq jobs which are used here. With better understanding of what exactly is happening I can now suggest a change which is should improve both memory usage and performance.


Compensate for new warnings and STL changes in VS 16.7

New warnings were added in VS 16.7 and std::map::erase is now noexcept. Update our code to be compatible with the new enforcement.
PR Checklist

[x] Closes broken audit in main after Agents updated to VS 16.7 over the weekend.
[x] I work here.
[x] Audit mode passes now
[x] Am core contributor.

Validation Steps Performed

[x] Ran audit mode locally

Wait a minute they are allowed to do that? I thought noexcept was only a nightmare in users’ code. Isn’t there some kind of regulation to prevent the signatures of std functions from changing?

I believe that removing noexcept is considered a breaking change, but adding it may not be?

@msftbot merge this in like 5 minutes

I swear I'm not crazy. On my machine (with 16.7.1) it says that erase is noexcept despite the CI failing the static analysis build saying it is not:

My machine is using this path for STL: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.27.29110\include
The build machine is using this path for STL:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.26.28801\include
Which would mean the build machine is on Visual Studio 16.6.5.

I'll yank the noexcept from erase until the build machines rev to 16.7. But I have no idea why them going to (apparently) 16.6.5 this weekend broke all the other stuff.
Basically what I'm saying is... GUH.


more reasonable argument types

allows for more precise control. also note that some systems are able to work with 192kHz sample rate frequencies so u16 is not enough for that.
correct me if I'm wrong.

Hi @adsick ,
thanks for your contribution. This is something that is covered by a bigger refactoring that I haven't publish yet. I think I can do it in the next 7 days.

nice)

So I finally had time. I put some work into all audio-related crates I maintain, including this. New and nicer version 0.3.0 released!


Issue/2 add code

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@bdeb9cd). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff            @@
##             main        #4   +/-   ##
========================================
  Coverage        ?   100.00%
========================================
  Files           ?         5
  Lines           ?       161
  Branches        ?        32
========================================
  Hits            ?       161
  Misses          ?         0
  Partials        ?         0

Flag
Coverage Δ

server
100.00% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.


OSPRAY crash on cisl-vapor

There's an Ospray crash bug as described here.
Note: this could well be an issue on the particular test machine (cisl-vapor).

OSPRay loads its libraries dynamically at runtime therefore the build system has no way of knowing what libraries it needs. Since on linux we use the hard library paths for running development builds it will not work. You can add linker paths to the runtime search paths with CMake but it is already configured to do this. It seems that it works on some systems (casper) but not on cisl-vapor. For the installer, the linker search path is manually set with the launchers so it is not an issue. To address the issue on cisl-vapor you can add ospray/lib to your LD_LIBRARY_PATH

Need to verify after #2453 is resolved.


Cylinder

I am creating this PR to implement a new Shape, Cylinder. For the theory, I used this link: https://www.pbr-book.org/3ed-2018/Shapes/Cylinders

In the latest commit, the CI builds are failing because I merged the Cylinder branch with the csg branch. In this branch, some methods of the Shape class have been made abstract, requiring them to be implemented in the child classes, including the Cylinder class. I solve this issue in this commit: 869c938e155b3828295359f46d0e929fc09461a4, disponibile nella PR #16


Let the user select the package version

Looks like the Data plane SDK Release app is only looking at the last version available for a package, instead of all the possible versions. The app should surface the versions and let the user pick it.
This came as a request from Event Grid Namespaces team where they can't get past the Python Generate SDK step. It's saying the API review is not approved but the library is already released. It's showing the next patch version that hasn't been review yet and not the version that was intended for this release plan.

This will require a change in how SDK package cache is maintained in PowerApps side to have one row per package name and version combination. Currently that's not the case since a single DevOps work item is used for all versions with same major.minor combinations. We can also improve current design to fetch API status directly from APIView for a specific package version.

@praveenkuttappan to add workaround for this for now


✅ Add status tests

Run tests through all HTTP status code.

The service always returns 200 when I run these tests locally...

https://github.com/golang/go/blob/de5b418bea70aaf27de1f47e9b5813940d1e15a4/src/net/http/server.go#L148-L153
	// The provided code must be a valid HTTP 1xx-5xx status code.
	// Any number of 1xx headers may be written, followed by at most
	// one 2xx-5xx header. 1xx headers are sent immediately, but 2xx-5xx
	// headers may be buffered. Use the Flusher interface to send
	// buffered data. The header map is cleared when 2xx-5xx headers are
	// sent, but not with 1xx headers.


Implement StaticVecIterConst and StaticVecIterMut in terms of core::slice::{Iter, IterMut}

I changed StaticVecIterConst and StaticVecIterMut to wrap slice iterators, which we can forward all iterator methods to rather than having to implement everything manually, which gets rid of a lot of unsafe.
This change also led me to fix a soundness issue with StaticVecIterMut::as_slice – this now returns a &[T] with the lifetime of &self rather than 'a, so this illegal code no longer compiles:
let mut vec = staticvec![1, 2, 3];
let mut iter = vec.iter_mut();
let slice = iter.as_slice();
dbg!(slice); // [1, 2, 3]
*iter.next().unwrap() = 0;
dbg!(slice); // [0, 2, 3]

But we can't merge this yet, for two reasons:

I wasn't sure what to do with the bounds_to_string methods, so I removed them for now. Don't they already read potentially uninitialized memory when this method is called on an empty iterator? I'm not sure what purpose this method solves if the Debug implementation already shows the entire slice.
slice::Iter::as_slice and slice::IterMut::as_slice aren't currently const, so I'll have to submit a PR to the Rust repo to make those const before I can make the as_slice methods here const again.

Ah, I just found #20, is there any downside to keeping the custom iterator types but replacing their inner workings like I did here?

I tested a similar way of going about it early on, and found it didn't optimize quite as well in several scenarios (likely because it can't benefit from things like LTO quite as directly that way.)
Also as I said in the issue you linked, I do kind of have long term plans for stuff I'd like to do with them once const fn and const generics are somewhat farther along as features (i.e. once we're at the point where -Zunleash-the-miri-inside-of-you is just the normal state of things). So it's still the case that I don't think I want to be restricted to whatever can be built on top of Iter and IterMut, basically.
That said, your points about the as_slice functions and also about bounds_to_string were completely correct and I really appreciate you pointing them out! I've just fixed them both, and added an "empty iterator" scenario to the test for bounds_to_string (which I'd have already had in there if I was thinking!) to make sure it stays correct in the future.

So it's still the case that I don't think I want to be restricted to whatever can be built on top of Iter and IterMut, basically.

Well, you can always add more properties to the iterator structs whether you store pointers or a slice iterator. That is to say, once you add functionality that can't be built on top of slice::Iter, wouldn't you still be able to replace the start and end properties with a slice iterator? I don't know what kind of functionality you have in mind, but it's quite trivial to turn a slice iterator into raw pointers again (using as_slice) so it's not clear to me what we'd be losing here (apart from possibly performance).

So it's still the case that I don't think I want to be restricted to whatever can be built on top of Iter and IterMut, basically.

Well, you can always add more properties to the iterator structs whether you store pointers or a slice iterator. That is to say, once you add functionality that can't be built on top of slice::Iter, wouldn't you still be able to replace the start and end properties with a slice iterator? I don't know what kind of functionality you have in mind, but it's quite trivial to turn a slice iterator into raw pointers again (using as_slice) so it's not clear to me what we'd be losing here (apart from possibly performance).

It's more kind of compile-time stuff that operates directly off of the N parameter I'm thinking about. You might note it's not even currently used in many of the actual iterator functions: I just have it there  as a placeholder for future use, largely.

Also, about the general purpose of bounds_to_string: basically it's meant as a logging function, for when you might want to monitor the "progress" of an iterator with a larger number of elements without displaying the entire underlying slice on each call.

It's more kind of compile-time stuff that operates directly off of the N parameter I'm thinking about. You might note it's not even currently used in many of the actual iterator functions: I just have it there as a placeholder for future use, largely.

N is untouched, so I don't think this change is restricting in any way, given that we could add start_ptr/end_ptr methods at any moment 🙂 [T] has as_ptr_range/as_mut_ptr_range on nightly, that's also an option.
I wasn't able to catch any regressions (or improvements) using the benchmarks you've already written, they fluctuated a lot but each time different benchmarks regressed/improved than the time before. I know how finicky these things can be though, so there might be situations in which this indirection generates worse code, but I haven't found any.
I think the biggest win here is how many unsafe blocks this gets rid of, and I think we can remove a lot more (and perhaps isolate some others). I would have never realized that the return value of as_slice had the wrong lifetime if it weren't for the compiler telling me, after I changed that method to return self.iter.as_slice().

I wasn't able to catch any regressions (or improvements) using the benchmarks you've already written, they fluctuated a lot but each time different benchmarks regressed/improved than the time before. I know how finicky these things can be though, so there might be situations in which this indirection generates worse code, but I haven't found any.

After running this version wrapping Iter and IterMut a bunch of times just now, I definitely consistently get slightly (not massively, granted, but slightly) worse results on the iterator-related tests in the adapted-from-SmallVec benchmark with it.

I think the biggest win here is how many unsafe blocks this gets rid of, and I think we can remove a lot more (and perhaps isolate some others).

I'm not sure I necessarily agree with the idea that simply removing the unsafe from direct visibility by switching to "safe" functions that definitely still use exactly the same amount of unsafe internally is the same thing as actually removing unsafe blocks.
It's basically a PR move at best, that doesn't really change anything in a technical sense but just gives the outward appearance of "X number less unsafes".
Not to say, again, that I don't appreciate you pointing out the two issues that you did.

I'm not sure I necessarily agree with the idea that simply pushing the unsafe out of direct visibility by switching to "safe" functions that definitely still use exactly the same amount of unsafe internally is the same thing as actually removing unsafe blocks.

Unsafe code in core is reviewed by many more people than in any third-party crate, so it's not really relevant how many unsafe lines of code we're relying on. Replacing unsafe blocks by safe abstractions that core provides for us isn't just "simply pushing the unsafe out of direct visibility", it's actually making soundness bugs significantly less likely.

It's basically a PR move at best, that doesn't really change anything in a technical sense but just gives the outward appearance of "X number less unsafes".

I couldn't disagree more. People trust that unsafe code in core is sound, and that soundness bugs (that aren't extremely obscure) are fixed quickly. If a crate (and the crates it depends on) contain no unsafe code, then people will assume it is sound.
It would be unfortunate if this crate ends up with a lot more unsafe code than necessary because it will make people more hesitant to depend on this crate.

I'm not trying to sound annoying, I'd just like to reduce the amount of unsafe code in a crate that I think many people are going to use 🙂 Kind of in the spirit of Rust Safety Dance.

After running this version wrapping Iter and IterMut a bunch of times just now, I definitely consistently get slightly (not massively, granted, but slightly) worse results on the iterator-related tests in the adapted-from-SmallVec benchmark with it.

Maybe it's a platform thing, but on macOS I cannot reproduce this. I've just run each benchmark from that suite 5 times for both implementations and taken the median to hopefully get rid of most fluctuations, and this PR's version actually was 2.6% faster on average – might be nothing though, I wouldn't be surprised if both implementations generate the same assembly.

Unsafe code in core is reviewed by many more people than in any third-party crate, so it's not really relevant how many unsafe lines of code we're relying on. Replacing unsafe blocks by safe abstractions that core provides for us isn't just "simply pushing the unsafe out of direct visibility", it's actually making soundness bugs significantly less likely.

It's true that there's always gonna be more people looking at libcore, of course. That said, for example, my test suite for StaticVec is a couple hundred lines longer than the one for normal Vec is, and gets run under Miri on every single commit (which obviously isn't the case for libcore for practicality reasons.)
Generally speaking I feel like my track record with this kind of thing has been quite good (certainly rather better than some other crates that are out there), and I've never once failed to fix an actual issue basically immediately (as well as take steps to ensure whatever the issue was stays fixed permanently.)

People trust that unsafe code in core is sound, and that soundness bugs (that aren't extremely obscure) are fixed quickly.

Perfectly fair, and why that's the case is obvious, but all I really feel like I'm lacking in that capacity is the vague umbrella of "people's trust" (something I feel confident I can build up over time.)
As far as the amount of unsafe, I'd say it has exactly the amount you might expect a crate that directly implements the things it does rather than always deferring to existing implementations does. Nothing I'm doing is very different from what libcore does or would do in the same scenario.
It mostly amounts to slightly different takes on ways of doing things that I've either found to be more performant in the context of StaticVec and StaticString  or that simply make them more relevant to stack-allocated containers (whereas all the slice stuff is clearly written with heap-allocated memory in mind, which is often not ideal) / making things const fn right now instead of later / etc.

As far as the amount of unsafe, I'd say this crate has exactly the amount of unsafe you might expect a crate that directly implements the things it does rather than always deferring to existing implementations to.

Yes, if you're not using any of the safe abstractions then indeed a large amount of unsafe is expected 😛 But at the same time, for a crate that could demonstrably use many safe abstractions from core, one could reasonably expect a lot less unsafe than there is currently.

Nothing I'm doing is wildly different from what libcore does or would do in the same scenario.

Your code is of a very high quality, I'm not trying to challenge that at all. But core will at least reuse its own safe abstractions whenever appropriate. The BinaryHeap type, for instance, though in alloc and not in core, uses very little unsafe code because it's backed by a Vec. It could have used RawVec as a backing store instead, but it wouldn't have made the code any faster or any more flexible.

Yes, if you're not using any of the safe abstractions then indeed a large amount of unsafe is expected 😛 But at the same time, for a crate that could demonstrably use many safe abstractions from core, one could reasonably expect a lot less unsafe than there is currently.

Don't get me wrong, I know what you mean, but keep in mind that what I'm generally trying to do with this crate is implement nice safe easy-to-use abstractions (that are also as efficient as they can possibly be) ala Vec and String, and if that means not necessarily getting to use every single existing safe abstraction myself in the process (just as their implementations don't of course) I'm fine with it.

Your code is of a very high quality, I'm not trying to challenge that at all.

I really appreciate you saying the first half of this, and to be clear I didn't think you were trying to do the second half of it at all.

The BinaryHeap type, for instance, though in alloc and not in core, uses very little unsafe code because it's backed by a Vec. It could have used RawVec as a backing store instead, but it wouldn't have made the code any faster or any more flexible.

Of course. I think that's generally in keeping with what I'm already doing, though (e.g. StaticString is backed by StaticVec, just as a hypothetical StaticBinaryHeap would also be.)
Lastly, again, I really appreciate your interest in contributing, as well as you pointing out the two bugs  you did, and there's nothing at all "wrong" with your code in the actual PR here.
I just really feel like the "clearly visible benefits" to "potential downsides, even if they're future ones" ratio wasn't quite there, that's all.
So absolutely don't hesitate to open PRs for anything else you might come up with going forwards, as I'm always totally happy to at the very least discuss pretty much anything.


fix: modify sass version

the project use the missing version of sass

the sass's latest version is 1.26.10

thanks so much! may be it's node-sass version


Bug 1931590: [release 4.7] Update rook version to get OSD placement fixes

We update to a version of rook that has placement fixes for OSD.
Also, we now use the ceph pacific latest images and the stretch cluster feature has some fixes which aren't available in the previous image we were using. This means that we will have to live with a moving target of ceph daemon.
This is a manual cherrypick of #1095 as the auto cherry failed.

@jarrpa @agarwal-mudit Please take a look.

@obnoxxx This is another instance where we have to use upstream rook version :(

/test ocs-operator-ci


Finished adding the MusicManager that SimonC4 starting with menu and …

…ingame music.

Refer to this link for build results (access rights to CI server needed):
http://jenkins.terasology.org/job/DestinationSolPRs/17/
Hooray Jenkins reported success with all tests good!

Refer to this link for build results (access rights to CI server needed):
http://jenkins.terasology.org/job/DestinationSolPRs/18/
Hooray Jenkins reported success with all tests good!

Awesome! Sweet to finally hear the music in-game as intended. Seems a really great fit!
One thing we should add: including the music in the volume setting or splitting it out into its own setting.

Refer to this link for build results (access rights to CI server needed):
http://jenkins.terasology.org/job/DestinationSolPRs/19/
Hooray Jenkins reported success with all tests good!

Was actually already in there, however I've made it change the volume of the currently playing music as well. Would like to separate it out and have its own slider in the future.

Haven't forgotten, btw, just slammed at my day job :-)
Do we have @NeonInsect in the credits somewhere yet and/or a little copyright notice from him somewhere? Free for our use for Destination Sol but copyright him.

yay :)
2016-03-18 6:11 GMT+01:00 Rasmus Praestholm<EMAIL_ADDRESS>
Haven't forgotten, btw, just slammed at my day job :-)
Do we have @NeonInsect https://github.com/NeonInsect in the credits
somewhere yet and/or a little copyright notice from him somewhere? Free for
our use for Destination Sol but copyright him.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/MovingBlocks/DestinationSol/pull/86#issuecomment-198210931

--
Nils Sinatsch
Composer & Producer
www.neoninsect.de
<EMAIL_ADDRESS>

Tested it out again, volume settings apply correctly to music now, although we only have said option available in-game, not in the main menu, huh :-)
Thanks @Rulasmur and @SimonC4 for getting it hooked up!
@NeonInsect I added a new soundtrack section to the credits with you and the copyright disclaimer in it plus a link to your soundcloud. If you do the setup on Bandcamp or wherever let us know one or more links to add to that section, or even submit an issue/PR with the details. And thanks again for the great music!
I think this actually concludes our prep for v1.4.0 which we should test out on Android and release as a beta on Steam whenever we get a chance.


Changing image attachment path in mail body

After reading a Message I'm saving attachments to disk. New file-path for image should rewrite original one in message body. Does php-imap have a method for this?

Do you mean altering the original message in the inbox, or changing the path so you can display the message in HTML? I posted some code on https://github.com/Webklex/php-imap/issues/425 which may be useful to you.

Your code is useful because you are using php-imap classes. Thanks.


ffmpeg merging files issue[Bug]:

What happened?
when ffmpeg merging audio and video files it is taking too much time to merge. before it wasn't take that long time.
it is showing some message like this
non-monotonous DTS in output stream 0:1; previous: 37256659, current 8144136; changing to 37987621. this may result in incorrect timestamps in the output file.
please see screenshot

Expected Result
script need to fix this issue and it should merge the files as it was doing before like months ago.
Branch
master/main
What operating systems are you seeing the problem on?
Windows
Relevant log output
No response
Other information
No response

Ffmpeg being slow for you isn't an issue with the script. Get a better PC or something.

@Puyodead1
i am not talking about slow. i am saying about this error before it was not showing but now it is showing so can you help to resolve this timestamp error ?

@Puyodead1
i am not talking about slow. i am saying about this error before it was not showing but now it is showing so can you help to resolve this timestamp error ?

It's not an error and you can ignore it

@Puyodead1  first of all thanks for your update
now your latest updated script is not showing above ffmpeg errors but there is one problem that after dec files  script is not removing enc files and keeping them in folders too and just generating its dec file and tryting to dec again these files and then showing this message
[mov,mp4,m4a,3gp,3g2,mj2 @ 00000131e0dce040] Found duplicated MOOV Atom. Skipped it
Last message repeated 3 times


Improve logging of active environment in CLI

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/3375
Originally created by @cjohnhanson on 2022-04-04 21:33:16

This is a follow-up from this thread in the initial default_environment MR.
Currently, a log line like this:
2022-04-04T21:24:48.976998Z [info     ] No environment is active
is emitted whenever --no-environment or --environment=null flags are provided. However there is a third scenario in which no environment is active, which is when no environment is provided via flag or environment variable and there is no default_environment found in meltano.yml. For consistency, we should emit the same log line in this scenario as well.
We also currently allow users to set default_environment: null in their meltano.yml. We would like to discourage this practice by emitting a warning log line whenever the default_environment is set in this way.

View 1 previous comment from the original issue on GitLab


Add Xcode 7.1 support

/tmp/com.github.kean/NukeIntegrationTests/CocoaPodsTests/iOS/Pods/Nuke-AnimatedImage-Plugin/Source/AnimatedImage.swift:21:1: error: 'required' initializer 'init(imageLiteral:)' must be provided by subclass of 'UIImage'

done


sc-4423 gds ui refresh :  improve the certificate stepper

Codecov Report

Merging #438 (c04fbcc) into main (66aeea6) will decrease coverage by 9.41%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #438      +/-   ##
==========================================
- Coverage   47.12%   37.71%   -9.42%
==========================================
  Files         232      151      -81
  Lines       11610     2368    -9242
  Branches      606      606
==========================================
- Hits         5471      893    -4578
+ Misses       5178     1302    -3876
+ Partials      961      173     -788

Impacted Files
Coverage Δ

directory/pkg/gds/admin/v2/client.go

directory/pkg/gds/gds.go

directory/pkg/sectigo/config.go

directory/pkg/trtl/internal/pagination.go

directory/pkg/utils/logger/logger.go

directory/pkg/gds/store/trtl/mock.go

directory/pkg/gds/store/index/search.go

directory/pkg/gds/service.go

directory/pkg/gds/store/leveldb/iterator.go

directory/pkg/gds/admin/v2/csurf.go

... and 71 more

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 66aeea6...c04fbcc. Read the comment docs.


ESP8266

I use your library with esp8266 nodemcu , but there are some small problems :

library advice about architecture not compatible
some reboots
sometimes codes can't uploaded , device busy
not stable , reboot sometimes after card is read

linked issue : https://github.com/esp8266/Arduino/issues/963

I tested with a Wemos D1 mini. I had no issues, everything worked.

Although "Library advice about architecture not compatible" warning is issued, I'm using it with NodeMCU 1.0, and it's working fine with following pinout:
NodeMCU - RC522
D4 - RST
D5 - SCK
D6 - MISO
D7 - MOSI
D8 - SDA(SS)
"sometimes codes can't uploaded , device busy" I think it's Arduino, not this library.
"not stable , reboot sometimes after card is read" It's not happening here.

At now , with vers 2.0.0 or 2.1.0 i think ti can work , next week i will test it
@Rotzbua it's a informatics  century
@gutierrezps thanks i will report soon

Please add to read compatibility with ESP (it's not wright )
cpu bug resolved
https://github.com/miguelbalboa/rfid/issues/212


Intel Joule SPI not working

Platform
Board:Intel Joule 570X Expansion Board
OS: uname -a
Linux scout-570x-DVT3 4.4.0-1000-joule #0+joule12-Ubuntu SMP PREEMPT Fri Jan 6 04:28:41 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.1 LTS
Release:	16.04
Codename:	xenial
MRAA
mraa-gpio version
Version v1.7.0-11-g47c21e0 on INTEL JOULE EXPANSION
Program:
Source
#include "mraa.h"
#include
#include
#include
int main(int argc, char** argv)
{
    mraa_init();
    //! [Interesting]
    mraa_spi_context spi;
    spi = mraa_spi_init(0);
    printf("Hello, SPI initialised\n");
    std::cout<<"spi init"<
    uint8_t data[] = { 0x00, 0x32 };
    uint8_t* recv;
    std::cout<<"assigning  data"<
    int i=90;
    data[1] = i;
    std::cout<<"spi write coming up"<
    recv = mraa_spi_write_buf(spi, data, 2);
    if (recv==NULL)
        std::cout<<"error in writing"<
   printf("Writing -%i\n", i);
    //printf("RECIVED-%i-%i\n", recv[0], recv[1]);
    usleep(100000);
    //! [Interesting]
}
Output
Hello, SPI initialised
spi init
assigning  data
spi write coming up
error in writing
Writing -90
Debug
journalctl -t libmraa
-- Logs begin at Thu 2017-04-13 12:04:32 EDT, end at Thu 2017-06-01 18:28:10 EDT. --
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: libmraa version v1.7.0-11-g47c21e0 initialised by user 'scout' with EUID 1001
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: Adding i2c bus found on i2c-4 on adapter i2c_designware.0
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: Adding i2c bus found on i2c-9 on adapter i2c_designware.5
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: Adding i2c bus found on i2c-10 on adapter i2c_designware.6
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: Adding i2c bus found on i2c-5 on adapter i2c_designware.1
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: Adding i2c bus found on i2c-6 on adapter i2c_designware.2
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: libmraa initialised for platform 'INTEL JOULE EXPANSION' of type 13
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: spi: Failed opening SPI Device. bus:/dev/spidev32765.0. Error 2 No such file or directory
Jun 01 18:18:37 scout-570x-DVT3 libmraa[2837]: spi: write_buf: context is invalid
Jun 01 18:24:50 scout-570x-DVT3 libmraa[3049]: libmraa version v1.7.0-11-g47c21e0 initialised by user 'scout' with EUID 1001
Jun 01 18:24:50 scout-570x-DVT3 libmraa[3049]: Adding i2c bus found on i2c-4 on adapter i2c_designware.0
Jun 01 18:24:50 scout-570x-DVT3 libmraa[3049]: Adding i2c bus found on i2c-9 on adapter i2c_designware.5
Jun 01 18:24:50 scout-570x-DVT3 libmraa[3049]: Adding i2c bus found on i2c-10 on adapter i2c_designware.6
Jun 01 18:24:50 scout-570x-DVT3 libmraa[3049]: Adding i2c bus found on i2c-5 on adapter i2c_designware.1
Jun 01 18:24:50 scout-570x-DVT3 libmraa[3049]: Adding i2c bus found on i2c-6 on adapter i2c_designware.2
Jun 01 18:24:50 scout-570x-DVT3 libmraa[3049]: libmraa initialised for platform 'INTEL JOULE EXPANSION' of type 13
Jun 01 18:28:04 scout-570x-DVT3 libmraa[3115]: libmraa version v1.7.0-11-g47c21e0 initialised by user 'scout' with EUID 1001
Jun 01 18:28:04 scout-570x-DVT3 libmraa[3115]: Adding i2c bus found on i2c-4 on adapter i2c_designware.0
Jun 01 18:28:04 scout-570x-DVT3 libmraa[3115]: Adding i2c bus found on i2c-9 on adapter i2c_designware.5
Jun 01 18:28:04 scout-570x-DVT3 libmraa[3115]: Adding i2c bus found on i2c-10 on adapter i2c_designware.6
Jun 01 18:28:04 scout-570x-DVT3 libmraa[3115]: Adding i2c bus found on i2c-5 on adapter i2c_designware.1
Jun 01 18:28:04 scout-570x-DVT3 libmraa[3115]: Adding i2c bus found on i2c-6 on adapter i2c_designware.2
Jun 01 18:28:04 scout-570x-DVT3 libmraa[3115]: libmraa initialised for platform 'INTEL JOULE EXPANSION' of type 13
Jun 01 18:28:10 scout-570x-DVT3 libmraa[3116]: libmraa version v1.7.0-11-g47c21e0 initialised by user 'scout' with EUID 1001
Jun 01 18:28:10 scout-570x-DVT3 libmraa[3116]: Adding i2c bus found on i2c-4 on adapter i2c_designware.0
Jun 01 18:28:10 scout-570x-DVT3 libmraa[3116]: Adding i2c bus found on i2c-9 on adapter i2c_designware.5
Jun 01 18:28:10 scout-570x-DVT3 libmraa[3116]: Adding i2c bus found on i2c-10 on adapter i2c_designware.6
Jun 01 18:28:10 scout-570x-DVT3 libmraa[3116]: Adding i2c bus found on i2c-5 on adapter i2c_designware.1
Jun 01 18:28:10 scout-570x-DVT3 libmraa[3116]: Adding i2c bus found on i2c-6 on adapter i2c_designware.2
Jun 01 18:28:10 scout-570x-DVT3 libmraa[3116]: libmraa initialised for platform 'INTEL JOULE EXPANSION' of type 13
Comments
Do I need to enable spidev for libmraa to work. If so how do I enable it?

First of all I'd suggest you to run your app as root (or using sudo) as mraa needs that to work properly. Let's see if that makes any difference. Plus, I'd suggest you to update mraa to the latest version, there have been fixes for Joule recently.

having same issue

@akshaybhagat, th log you posted states the effective user id of the process is 1001 (user "scout"), so it doesn't look like sudo was used.
As for the version - 1.7.0 is the latest, right, but then if you check the specific commit hash (that hex string after version), you'll notice it's behind the current master branch. What I'm suggesting here is either to install the latest dev release (built daily) or build from sources - to make sure you have all the latest fixes.
I also see you have Ubuntu installed, have by chace tried with the default Ref OS for IoT?
In general, if no one tackles this sooner, I plan to look into this over the upcoming weekend.

Hi @AkshayBhagat, as of now SPI only works on the Ref-OS-IoT image.

@propanu that's false
See https://communities.intel.com/thread/115016
And https://communities.intel.com/thread/114441
What are you using?

This. Ref-OS used to be called Ostro. Wouldn't be surprised if SPI was broken in one of the newer releases.

@Propanu are you suggesting to load that Ostro version, before is was named Ref-OS to the Intel Joule because it was in a known working state? Thanks so much for your help!

Yes, although updating the MRAA library on Ostro is a bit of a hassle. Most likely you'll have to compile it from scratch. Looking into it to see if there's a way to fix it for the new Ref-OS images too.

So by now you probably understand this is not mraa's problem, but an OS-level one. I'm currently looking into this and I think I've found the specific reason, running some tests to validate that. Will post back when done.

I've found at least a solid interim solution, but as long as this is an OS-level thing and I see @aj-ptw has already submitted an issue to ref-os-iot's repo (https://github.com/01org/ref-os-iot/issues/2) - let me continue the discussion there and close this one.
On a side note - @arfoll or @tingleby, an "OS issue" label would come in handy for marking such cases, similarly to "hardware issue" we already have. I'm not able to create one, so if you too think it could be useful and have a spare minute - please create it.

@alext-mkrs thanks so much for the follow up.


Flush store on logout

Summary
With the latest performance changes when a user was logged out we were not flushing the redux store.
Ticket Link
https://mattermost.atlassian.net/browse/MM-22973

Building app in separate branch.

Successfully building:
https://circleci.com/gh/mattermost/mattermost-mobile/4029
https://circleci.com/gh/mattermost/mattermost-mobile/4028

Artifact links:
https://4029-70265724-gh.circle-artifacts.com/0/~/mattermost-mobile/Mattermost_Beta.ipa
https://4028-70265724-gh.circle-artifacts.com/0/~/mattermost-mobile/Mattermost_Beta.apk


feat: Upgrade JHipster dependency to v8

Related to #1862
Closes #1841

Remaining CI failures to be looked into separate PRs


fix issue #1381

PR Fixes:

1 Sidebar button toggle inconsistency.

Resolves #1381
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] I assure there is no similar/duplicate pull request regarding same issue

https://github.com/user-attachments/assets/a31aa77e-7bfa-4f06-bb98-4199ef7960ad

Hey @devsargam, Can you check this I have changes only one file but when I committed it automatically changed 23 flies, Is this a problem on my end ??

Someone has raised the pr for same issue but its not a complete solution.


GraphQL : Query - how to get more than the 100 first repo or how to get next 100 till the last

Dear @moollaza
I tried to modify the number of repo returned by the query.
If more than 100, I got an error.
I tried :
query($ghLogin:String!){
  user(login:$ghLogin) {
    id
    name
    login
    avatarUrl
    bioHTML
    repositories(last:100, ownerAffiliations: [OWNER, ORGANIZATION_MEMBER, COLLABORATOR]) {
      nodes {
        id
        viewerCanAdminister
        name
        description
        isFork
        isPrivate
        isArchived
        updatedAt
        url
        parent {
          nameWithOwner
          url
        }
        owner {
          login
          url
        }
      }
    }
  }
}

I got the last 100 repositories.
But finally, how to get from 100 till 200 ?
Best Regards,
Youssef

Duplicate of #138
@yboujraf the API is limited to returning at most 100 repos per page. To get more than 100 results, we need to implement a check for additional pages of results.

@yboujraf the API is limited to returning at most 100 repos per page. To get more than 100 results, we need to implement a check for additional pages of results.


[refactor] Safekeeper push replication

Adds a new command to the page server, START_PUSH_REPLICATION, which (mostly) imitates the usual replication protocol, as if the page server had connected to the safekeeper itself.
The one primary difference is that immediately after receiving the connection, the page server sends a message back to the safekeeper with the starting LSN to stream from (where that would normally be given as part of the START_REPLICATION command).
The bulk of the work is done, just need to iron out the bugs. Pushed here for general review while that's going on.

Cool!
One thing that caught my eye is absense of reconnection loop inside of start_new_connection. I think the following behaviour is  desired (for given timeline):

There is no safekeeper -> pageserver connection unless there is a live walproposer -> safekeeper connection, as keeping the former is pointless and wastes resources.
If connection to pageserver dies but walproposer -> safekeeper connection is ok, the former attempts reconnection.
Obviously, walproposer -> safekeeper reconnections shouldn't produce multiple safekeeper -> pageserver connections.

You have addressed 3) with ACTIVE_PUSH_CONNS. 1) is somewhat out of scope of this PR and can be addressed separately, but 2) should be here I believe.
https://github.com/zenithdb/zenith/issues/636 is also on that.

Final update on bugs blocking this PR:
The first two commits don't introduce any new features and they seem to work correctly.
The bug that's currently causing things to fail is essentially:

The page server times out waiting for some LSN....
Because it never receives it...
Because none of the wal_acceptors send it (even though they received it)...
Because the push replication connection never actually starts....
Because the initial call to copy_both_simple never returns:

https://github.com/zenithdb/zenith/blob/cdd4288fe10fec87ec32fe8d861b19ddcd7c79cc/walkeeper/src/replication.rs#L540-L542
But it also never prompts the handler for START_PUSH_REPLICATION to run either, over here:
https://github.com/zenithdb/zenith/blob/cdd4288fe10fec87ec32fe8d861b19ddcd7c79cc/pageserver/src/page_service.rs#L540
It should be easy enough to verify that this is the case by adding appropriate prints/logging.
I'm not sure what's going on here. I did modify our fork of tokio-postgres, but not copy_both_simple or anything it uses. I thought it might be due to the single-threaded executor being transferred across threads (see below), but changing that didn't affect the issue.
https://github.com/zenithdb/zenith/blob/cdd4288fe10fec87ec32fe8d861b19ddcd7c79cc/walkeeper/src/replication.rs#L446-L451

The bug that's currently causing things to fail is essentially:

JFYI That's because tokio-postgres needs Connection returned from connect to be run as separate task in the background; it wasn't spinned off.
I fixes that and a couple of more bugs, but basic tests still hang apparently due to WAL not reaching pageserver, not yet investigated the details.
Some things I noticed along the way:

Not sure why initial connection attempt in handled differently from main work (and thus we have two retry-sleep loops).
serialize_with_tag could avoid one copy of data
WAL_PUSH_RECEVIERS counter should be decremented on exit

Do we plan to merge this, @arssher , would this fix the issue #707 when it's merged?


Change the Powered By statement to point to PoShLog

Forgot to change this in the default options.

Powered By :scroll: Elizium.PoShLog

Raised this issue in error, should be in Klassy


Avoid browser caching with hashed filenames (like Angular does)

Note: for support questions, please use one of these channels:
https://forum.ionicframework.com/
http://ionicworldwide.herokuapp.com/
Short description of the problem:
The browser caches the generated javascript files because the name stays the same even if the contents of the file has changes. e.g.: main.js, or for the lazy loaded pages: 0.js, 1.js etc.
What behavior are you expecting?
Like Angular 2-5 does (ng build --prod) the filenames have to be suffixed with a hash of the file, e.g.:
main..js, 0..js etc.
So if the contents of the files changes the browser loads the file.
Maybe someone can hack it with a custom webpack.config but i think this is a mandatory thing for a big framework like Ionic.
How are people supposed to write cool PWA's if the browser never loads the new files ??
Steps to reproduce:
run "ionic build --prod" -> no hash in the filenames
insert any relevant code between the above and below backticks

Which @ionic/app-scripts version are you using?
3.1.8
Other information: (e.g. stacktraces, related issues, suggestions how to fix, stackoverflow links, forum links, etc)

+1 It's really a MUST HAVE thing if ionic want to have full support of PWA.

+1

Some workarounds here: https://stackoverflow.com/questions/43415537/ionic-2-change-name-of-main-js-webpack-js-output-filename-setting

still open, is it possible with ionic 4 now ?


CHOOSE ONLY MONTH

I want to choose only the month of the year please help me

Is it possible to select only Month?

No

This is available in version 6
check the example by @DanielYKPan here
https://stackblitz.com/github/DanielYKPan/owl-examples/tree/date-time-picker?file=src%2Fapp%2Fyear-month%2Fyear-month.component.ts

This is available in version 6
check the example by @DanielYKPan here
https://stackblitz.com/github/DanielYKPan/owl-examples/tree/date-time-picker?file=src%2Fapp%2Fyear-month%2Fyear-month.component.ts

this link isn't working anymore


Fixed flat_map and flatten

Current implementations of flat_map and flatten have a bug. If stream returns Poll::Pending while inner_stream is already completed, inner_stream will be polled again after completion as many times as stream returns Poll::Pending.

@olegnn Thanks for PR and sorry for the late review.


[DE-324] Merge Composer and Elementary Monitoring

This PR adds a model (int_merge_logs) to combine the high-level DAG logging coming from our newly-established log syncs and our existing Elementary logging.
Putting this PR up for review but flagging something we'll need to address: we don't currently have a way to know which partners are associated with non-Elementary/dbt syncs. All we're extracting is the dag_id which doesn't contain this info, so we might need to think about:

grabbing more logs
checking the information schema? for some of our "rows updated", etc. metrics I think we'll need to log some information schema bits regardless, maybe we could check to see what tables are being updated that match a naming pattern.
pulling in some sort of reference/lookup table

we don't currently have a way to know which partners are associated with non-Elementary/dbt syncs

Oh... this is an interesting question @jackwelty, and I'd love to get thoughts from @kanelouise and @jitoquinto about how we can track this. We really need some representation somewhere of vendors, partners, and dag_ids - like, a Google Sheet (which we could read into BQ using a container script)? Another config YAML saved in our airflow repo (version control is nice)? This is actually super important for us to have so that when DAGs fail, we can very quickly communicate about which vendors/users are impacted.
As we think about what the best long-term solution is, @jackwelty what do you think would be the most straightforward POC? And do we need any info besides dag_id, vendor, and partner (maybe also "notes" for any qualitative bits that would be useful to... note)?

we don't currently have a way to know which partners are associated with non-Elementary/dbt syncs

Oh... this is an interesting question @jackwelty, and I'd love to get thoughts from @kanelouise and @jitoquinto about how we can track this. We really need some representation somewhere of vendors, partners, and dag_ids - like, a Google Sheet (which we could read into BQ using a container script)? Another config YAML saved in our airflow repo (version control is nice)? This is actually super important for us to have so that when DAGs fail, we can very quickly communicate about which vendors/users are impacted.
As we think about what the best long-term solution is, @jackwelty what do you think would be the most straightforward POC? And do we need any info besides dag_id, vendor, and partner (maybe also "notes" for any qualitative bits that would be useful to... note)?

If we're going for lowest-effort POC, a sheet feels easiest? We can even create it as an external table so no container-scripting required!

we don't currently have a way to know which partners are associated with non-Elementary/dbt syncs

Oh... this is an interesting question @jackwelty, and I'd love to get thoughts from @kanelouise and @jitoquinto about how we can track this. We really need some representation somewhere of vendors, partners, and dag_ids - like, a Google Sheet (which we could read into BQ using a container script)? Another config YAML saved in our airflow repo (version control is nice)? This is actually super important for us to have so that when DAGs fail, we can very quickly communicate about which vendors/users are impacted.
As we think about what the best long-term solution is, @jackwelty what do you think would be the most straightforward POC? And do we need any info besides dag_id, vendor, and partner (maybe also "notes" for any qualitative bits that would be useful to... note)?

If we're going for lowest-effort POC, a sheet feels easiest? We can even create it as an external table so no container-scripting required!

oooh!!! yeah that sounds good! I wrote you a ticket linking to a google sheet to start with. meanwhile this LGTM (approval incoming) 🎉