feat: add private properties to contract definition entity

What this PR changes/adds
Add private properties to contract definition entity. The implementation supports in-memory and postgres as a store.
Why it does that
The private properties are required to provide the owner with the possibility to add extra properties which should not be exposed outside. This requirement was initiated when we want to add administrative properties like (createdBy, createdAt, chnagedBy, chnagedAt). We assume that the private properties can be used to store such a requirement after registering a listener on the contract definition.
More information is in this discussion:
https://github.com/eclipse-edc/Connector/discussions/2592#discussioncomment-7162109
Further notes
List other areas of code that have changed but are not necessarily linked to the main feature. This could be method
signature changes, package declarations, bugs that were encountered and were fixed inline, etc.
Linked Issue(s)
Closes https://github.com/eclipse-edc/Connector/issues/3490

@mohannad-ezzo two more things: in a PR description, it's fine to reference a discussion, but giving a brief reason is still needed, so that reviewers don't have to read long threads of discussions.
Also in the PR description, pls use closing keywords when linking the issue, so it gets auto-closed when your PR is merged

Codecov Report
Attention: 106 lines in your changes are missing coverage. Please review.

Comparison is base (beca927) 72.19% compared to head (e66c720) 4.61%.
Report is 6 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #3534       +/-   ##
==========================================
- Coverage   72.19%   4.61%   -67.58%
==========================================
  Files         849     863       +14
  Lines       17124   17395      +271
  Branches      960     992       +32
==========================================
- Hits        12362     803    -11559
- Misses       4354   16572    +12218
+ Partials      408      20      -388

Files
Coverage Δ

...ractdefinition/ContractDefinitionApiExtension.java
0.00% <0.00%> (-88.89%)
:arrow_down:

...efinition/schema/ContractDefinitionStatements.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...m/JsonObjectFromContractDefinitionTransformer.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...actdefinition/schema/BaseSqlDialectStatements.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...r/contract/spi/types/offer/ContractDefinition.java
0.00% <0.00%> (-68.58%)
:arrow_down:

...orm/JsonObjectToContractDefinitionTransformer.java
0.00% <0.00%> (-90.91%)
:arrow_down:

...contractdefinition/SqlContractDefinitionStore.java
0.00% <0.00%> (-86.31%)
:arrow_down:

... and 631 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

generally, I'd follow the SqlTransferProcessStore approach, putting the properties into a JSON column into the same entity table, it will save a lot of code lines and unneeded overcomplication.

I agree, that is an even easier way way to do it. @mohannad-ezzo can you adapt your PR accordingly?
@ndr-brt in a future issue, maybe we should also change the SQL-persistence of Assets so that is follows the JSON approach.

generally, I'd follow the SqlTransferProcessStore approach, putting the properties into a JSON column into the same entity table, it will save a lot of code lines and unneeded overcomplication.

I agree, that is an even easier way way to do it. @mohannad-ezzo can you adapt your PR accordingly? @ndr-brt in a future issue, maybe we should also change the SQL-persistence of Assets so that is follows the JSON approach, wdyt?

@paullatzelsperger @ndr-brt By following the JSON approach, we may loose the flexibility to support search within the private properties across all contract definitions. For sure, for a small set of contract definitions, JSON approach would still work. However, whenever the set becomes bigger and bigger, cross search would be difficult. I still see that the current approach may fit better our current and future requirement. What do you think ?

generally, I'd follow the SqlTransferProcessStore approach, putting the properties into a JSON column into the same entity table, it will save a lot of code lines and unneeded overcomplication.

I agree, that is an even easier way way to do it. @mohannad-ezzo can you adapt your PR accordingly? @ndr-brt in a future issue, maybe we should also change the SQL-persistence of Assets so that is follows the JSON approach, wdyt?

@paullatzelsperger @ndr-brt By following the JSON approach, we may loose the flexibility to support search within the private properties across all contract definitions. For sure, for a small set of contract definitions, JSON approach would still work. However, whenever the set becomes bigger and bigger, cross search would be difficult. I still see that the current approach may fit better our current and future requirement. What do you think ?

Postgres supports JSON operators, and EDC has a way of converting a QuerySpec into such an operator.

@paullatzelsperger @ndr-brt By following the JSON approach, we may loose the flexibility to support search within the private properties across all contract definitions. For sure, for a small set of contract definitions, JSON approach would still work. However, whenever the set becomes bigger and bigger, cross search would be difficult. I still see that the current approach may fit better our current and future requirement. What do you think ?

@mohannad-ezzo Postgres supports JSON operators, and EDC has a way of converting a QuerySpec into such an operator.

@paullatzelsperger @ndr-brt ok, I am going to follow the JSON approach of storing the private properties (instead of a having a separate table) and provide you with an update asap.

generally, I'd follow the SqlTransferProcessStore approach, putting the properties into a JSON column into the same entity table, it will save a lot of code lines and unneeded overcomplication.

I agree, that is an even easier way way to do it. @mohannad-ezzo can you adapt your PR accordingly? @ndr-brt in a future issue, maybe we should also change the SQL-persistence of Assets so that is follows the JSON approach, wdyt?

@paullatzelsperger @ndr-brt By following the JSON approach, we may loose the flexibility to support search within the private properties across all contract definitions. For sure, for a small set of contract definitions, JSON approach would still work. However, whenever the set becomes bigger and bigger, cross search would be difficult. I still see that the current approach may fit better our current and future requirement. What do you think ?

I agree with paul, plus, using the "separate table" approach will lead to issues in trying to query nested properties (see #3424 )

As discussed I adapted the PR so that JSON is used to store private properties of contract definition instead of storing them in a separate tables.

Just avoid those two not necessary changes to the sql store and it's ready to be merged

Thank you for mentioning this. This actually was inherited from the old logic when I started to have another table for private properties. Old logic is back now :)

@mohannad-ezzo you need to fix the broken tests and the checkstyle as well

@mohannad-ezzo you need to fix the broken tests and the checkstyle as well

I just fixed the checksytle issues. Regarding the broken tests, they ran fine this time without any change from me.
As of now, ALL checks are green and have passed :)


[Feature Request] Please consider additional support for the former alternative Archi interface representation

Hi,
please consider readding support for the former alternative Archi interface representation, because they offered an elegant and scalable way of visualizing interfaces in diagrams. The round, colored shape made them identifiable as interfaces at an instant and a (usually) directly to the shape connected composition relationship practically provided the line segment for the alternative interface notation specified in the ArchiMate standard. Therefore I used this notation in most of my diagrams. They potentially have to be readjusted to look proper again with the new representation.
Would it for instance be an option to add the oldstyle representation as an additional alternative shape or to introduce a preference setting that substitutes the old alternative shape for the new one?
Thanks in advance! ;-)

Thanks for dealing with this! ;-)
@jbsarrodie: Opinion regarding the tuning of the composition relationship: To my mind a modification of the composition relation in combination with an interface is not favourable for the following reasons:

A modified composition relationship could easily be confused at first glance with an association relationship (which I often use for instance to provide additional information about the interface or to clarify what data will be transmitted via the interface, etc...).
It could cause user confusion, because many users probably do not know about this special notation of the composition relationship in this particular case (I actually have not known about this as well).
The target side of the composition relationship does not have an arrowhead, so there is no need for an modification at this end, because it looks the same as an association relationship.

There is an AbstractTextControlContainerFigure#getTextControlMarginHeight() method which some of the iconic figures over-ride and return a value of 0 in order to give more space for the figure when the text is at the top or bottom. But with this new way of drawing figures this is no longer needed and if we don't over-ride it, it keeps the margin consistent between alternate and main figures.

@jbsarrodie Do what you think is necessary. The aim is to make the figures as good looking as possible.
BTW - the idea of having text above and below the icon figures came from Nicolas Figay:
https://www.linkedin.com/posts/nfigay_archi-version-49-is-progressing-well-in-activity-6829809625982926848-4f8f


Add rake task to delete stats keys set to 0

This PR adds a rake task to delete the stats keys set to 0. Those keys are useless and occupy Redis memory unnecessarily. They were generated by the bug that was fixed in #247

@unleashed please check the 3 new commits.

@unleashed please check the 3 new commits.

bors r=@unleashed

bors r=@unleashed

bors retry

bors retry


map_magic.py

in attempting to clean up the 2.5<=>3.0 mapping problems, I messed up the SPD => magic mapping
could you have a look?

I see the commit but exactly where are you finding problems?  It looks like you only edited the aniso mappings, and everything seems to still run correctly for me.

I edited the aniso mappings and also the magic mappiing.  maybe we don’t use the spd <=> magic mapping anymore?
lisa

On Mar 17, 2017, at 2:06 PM, moonshoes87<EMAIL_ADDRESS>wrote:
I see the commit but exactly where are you finding problems? It looks like you only edited the aniso mappings, and everything seems to still run correctly for me.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287471192, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKrDZPnEi2LDpetYsvxm0H-mgM8K0STks5rmvXbgaJpZM4MhC4e.

Ok, you're talking about this commit:
b3bed30
Why do you say the mapping is messed up?  Is there an error somewhere I'm not seeing?
The spd2magic_map is used in SPD (according to grep):
./SPD/spd.py:            self.pars = map_magic.mapping(self.pars, map_magic.spd2magic_map)
That's where the SPD parameters are translated to MagIC parameters for Thellier GUI (and maybe Demag GUI).  Note that what is currently implemented is translating SPD to 2.5, not to 3.0.

I haven’t found an actual error resulting from this, but the current list in pmagpy/mapping/map_magic is totally screwed up.    but that is not where we are pulling this from?  we are still using SPD/spd.py?  then that is ok.

On Mar 17, 2017, at 2:19 PM, moonshoes87<EMAIL_ADDRESS>wrote:
Ok, you're talking about this commit:
b3bed30 https://github.com/PmagPy/PmagPy/commit/b3bed302d37eee8ad7a9a5c50863f90b390f4b8d
Why do you say the mapping is messed up? Is there an error somewhere I'm not seeing?
The spd2magic_map is used in SPD (according to grep):
./SPD/spd.py: self.pars = map_magic.mapping(self.pars, map_magic.spd2magic_map)
That's where the SPD parameters are translated to MagIC parameters for Thellier GUI (and maybe Demag GUI). Note that what is currently implemented is translating SPD to 2.5, not to 3.0.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287473890, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKrDcwrMRaHFJvakHVO1Tky9WU2twzNks5rmvjWgaJpZM4MhC4e.

I see what you're saying.
It looks like SPD/that mapping are still using in thellier_gui_lib:
./thellier_gui_lib.py:    Pint_pars = spd.PintPars(Data, str(s), tmin, tmax, 'magic', preferences['show_statistics_on_gui'],acceptance_criteria)
So, that means that that mapping should still matter.  Now that I understand where the potential problem is, I can take a look at it soon.

I think the problem is because you edited the “magic” list with reference to "magic3", not with reference to "spd".  So the SPD mapping got all crazy.  I am going to revert back so that the spd —> magic translation still works as when originally implemented.
I can't find a place where the  “magic3” variable was actually ever used, and when you edited it and “magic” you were actually trying to fix a different translation (it looks like you edited the global variable magic3 and the local variable magic3 from the function convert_intensity_criteria each time you made changes).  But I’m not 100% sure I got this all right.
Can you check Thellier GUI, and make sure it is still working the way you expect it to mapping wise?   It looks fine to me.
  All is now up to date!

i’m using the magic3 mapping in the criteria reading/writing thing and now it works so please don’t touch that.  can we just move the spd <=> magic mapping somewhere else?
lisa

On Mar 18, 2017, at 5:21 PM, moonshoes87<EMAIL_ADDRESS>wrote:
I think the problem is because you edited the “magic” list with reference to "magic3", not with reference to "spd". So the SPD mapping got all crazy. I am going to revert back so that the spd —> magic translation still works as when originally implemented.
I can't find a place where the “magic3” variable was actually ever used, and when you edited it and “magic” you were actually trying to fix a different translation (it looks like you edited the global variable magic3 and the local variable magic3 from the function convert_intensity_criteria each time you made changes). But I’m not 100% sure I got this all right.
Can you check Thellier GUI, and make sure it is still working the way you expect it to mapping wise? It looks fine to me.
The magic --> spd mapping is now back to looking like this:
[('specimen_coeff_det_sq', 'R_corr2'),
('specimen_PCA_sigma_int', 'PCA_sigma_int_Free'),
('specimen_PCA_sigma_max', 'PCA_sigma_max_Free'),
('specimen_int_ptrm_tail_n', 'n_tail'),
('specimen_dpal', 'delta_pal'),
('specimen_tail_drat', 'DRAT_tail'),
('specimen_md', 'MD_VDS'),
('specimen_ac_n', 'n_add'),
('specimen_dac', 'delta_AC'),
('specimen_cm_y', 'y_Arai_mean'),
('specimen_int_mad', 'MAD_Free'),
('specimen_int_ptrm_n', 'n_ptrm'),
('specimen_drat', 'DRAT'),
('specimen_z_md', 'IZZI_MD'),
('specimen_frac', 'FRAC'),
('specimen_cdrat', 'CDRAT'),
('specimen_dec', 'Dec_Free'),
('specimen_mdev', 'mean_DEV'),
('specimen_drats', 'DRATS'),
('specimen_z', 'Z'),
('specimen_maxdev', 'max_DEV'),
('fail_arai_beta_box_scatter', 'fail_arai_beta_box_scatter'),
('specimen_gmax', 'GAP-MAX'),
('specimen_ptrms_mad', 'pTRM_MAD_Free'),
('specimen_ptrms_dec', 'ptrms_dec_Free'),
('specimen_int_mad_anc', 'MAD_Anc'),
('fail_ptrm_beta_box_scatter', 'fail_ptrm_beta_box_scatter'),
('specimen_ptrms_angle', 'ptrms_angle_Free'),
('specimen_scat_bounding_line_low', 'scat_bounding_line_low'),
('specimen_PCA_sigma_min', 'PCA_sigma_min_Free'),
('specimen_int_uT', 'B_anc'),
('specimen_scat', 'SCAT'),
('specimen_r_sq', 'R_det2'),
('specimen_PCA_v1', 'best_fit_vector_Free'),
('specimen_b_beta', 'specimen_b_beta'),
('specimen_YT', 'specimen_YT'),
('specimen_dck', 'delta_CK'),
('lab_dc_field', 'lab_dc_field'),
('specimen_inc', 'Inc_Free'),
('specimen_mdrat', 'mean_DRAT'),
('specimen_theta', 'theta'),
('specimen_ptrm', 'max_ptrm_check'),
('measurement_step_min', 'tmin'),
('specimen_cm_x', 'x_Arai_mean'),
('fail_tail_beta_box_scatter', 'fail_tail_beta_box_scatter'),
('specimen_dtr', 'delta_TR'),
('specimen_int_alpha', 'alpha'),
('specimen_fvds', 'specimen_fvds'),
('specimen_b_sigma', 'specimen_b_sigma'),
('specimen_b', 'specimen_b'),
('specimen_g', 'specimen_g'),
('specimen_f', 'specimen_f'),
('measurement_step_max', 'tmax'),
('specimen_int_n', 'specimen_int_n'),
('specimen_q', 'specimen_q'),
('specimen_int_dang', 'DANG'),
('specimen_ptrms_inc', 'ptrms_inc_Free'),
('specimen_k_sse', 'SSE'),
('specimen_gamma', 'gamma'),
('specimen_scat_bounding_line_high', 'scat_bounding_line_high'),
('specimen_k', 'specimen_k'),
('specimen_int_crm', 'specimen_int_crm'),
('specimen_dt', 'specimen_dt'),
('specimen_k_prime', 'specimen_k_prime'),
('specimen_k_prime_sse', 'specimen_k_prime_SSE')]
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e.

Can you show me where you use the magic3 variable (which file, which approximate line)?  I couldn’t find it.  I want to organize to make sure we don’t have any namespace collisions and that SPD/magic stays separate from magic3/magic2.
The current state of master doesn’t have the magic3 variable, but I’ll stick it back in based on the last commit you did (ce11ee8) where it was working.

On Mar 20, 2017, at 9:22 AM, Lisa Tauxe<EMAIL_ADDRESS>wrote:
i’m using the magic3 mapping in the criteria reading/writing thing and now it works so please don’t touch that. can we just move the spd <=> magic mapping somewhere else?
lisa

On Mar 18, 2017, at 5:21 PM, moonshoes87<EMAIL_ADDRESS>wrote:
I think the problem is because you edited the “magic” list with reference to "magic3", not with reference to "spd". So the SPD mapping got all crazy. I am going to revert back so that the spd —> magic translation still works as when originally implemented.
I can't find a place where the “magic3” variable was actually ever used, and when you edited it and “magic” you were actually trying to fix a different translation (it looks like you edited the global variable magic3 and the local variable magic3 from the function convert_intensity_criteria each time you made changes). But I’m not 100% sure I got this all right.
Can you check Thellier GUI, and make sure it is still working the way you expect it to mapping wise? It looks fine to me.
The magic --> spd mapping is now back to looking like this:
[('specimen_coeff_det_sq', 'R_corr2'),
('specimen_PCA_sigma_int', 'PCA_sigma_int_Free'),
('specimen_PCA_sigma_max', 'PCA_sigma_max_Free'),
('specimen_int_ptrm_tail_n', 'n_tail'),
('specimen_dpal', 'delta_pal'),
('specimen_tail_drat', 'DRAT_tail'),
('specimen_md', 'MD_VDS'),
('specimen_ac_n', 'n_add'),
('specimen_dac', 'delta_AC'),
('specimen_cm_y', 'y_Arai_mean'),
('specimen_int_mad', 'MAD_Free'),
('specimen_int_ptrm_n', 'n_ptrm'),
('specimen_drat', 'DRAT'),
('specimen_z_md', 'IZZI_MD'),
('specimen_frac', 'FRAC'),
('specimen_cdrat', 'CDRAT'),
('specimen_dec', 'Dec_Free'),
('specimen_mdev', 'mean_DEV'),
('specimen_drats', 'DRATS'),
('specimen_z', 'Z'),
('specimen_maxdev', 'max_DEV'),
('fail_arai_beta_box_scatter', 'fail_arai_beta_box_scatter'),
('specimen_gmax', 'GAP-MAX'),
('specimen_ptrms_mad', 'pTRM_MAD_Free'),
('specimen_ptrms_dec', 'ptrms_dec_Free'),
('specimen_int_mad_anc', 'MAD_Anc'),
('fail_ptrm_beta_box_scatter', 'fail_ptrm_beta_box_scatter'),
('specimen_ptrms_angle', 'ptrms_angle_Free'),
('specimen_scat_bounding_line_low', 'scat_bounding_line_low'),
('specimen_PCA_sigma_min', 'PCA_sigma_min_Free'),
('specimen_int_uT', 'B_anc'),
('specimen_scat', 'SCAT'),
('specimen_r_sq', 'R_det2'),
('specimen_PCA_v1', 'best_fit_vector_Free'),
('specimen_b_beta', 'specimen_b_beta'),
('specimen_YT', 'specimen_YT'),
('specimen_dck', 'delta_CK'),
('lab_dc_field', 'lab_dc_field'),
('specimen_inc', 'Inc_Free'),
('specimen_mdrat', 'mean_DRAT'),
('specimen_theta', 'theta'),
('specimen_ptrm', 'max_ptrm_check'),
('measurement_step_min', 'tmin'),
('specimen_cm_x', 'x_Arai_mean'),
('fail_tail_beta_box_scatter', 'fail_tail_beta_box_scatter'),
('specimen_dtr', 'delta_TR'),
('specimen_int_alpha', 'alpha'),
('specimen_fvds', 'specimen_fvds'),
('specimen_b_sigma', 'specimen_b_sigma'),
('specimen_b', 'specimen_b'),
('specimen_g', 'specimen_g'),
('specimen_f', 'specimen_f'),
('measurement_step_max', 'tmax'),
('specimen_int_n', 'specimen_int_n'),
('specimen_q', 'specimen_q'),
('specimen_int_dang', 'DANG'),
('specimen_ptrms_inc', 'ptrms_inc_Free'),
('specimen_k_sse', 'SSE'),
('specimen_gamma', 'gamma'),
('specimen_scat_bounding_line_high', 'scat_bounding_line_high'),
('specimen_k', 'specimen_k'),
('specimen_int_crm', 'specimen_int_crm'),
('specimen_dt', 'specimen_dt'),
('specimen_k_prime', 'specimen_k_prime'),
('specimen_k_prime_sse', 'specimen_k_prime_SSE')]
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287793140, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwGIpC2kisvVtZNwqLvzD-ZwarDxE4aks5rnpmYgaJpZM4MhC4e.

Ok, also, as of your last commit to map_magic (ce11ee8), the mapping between magic and magic3 is definitely broken.  I grabbed the two lists from your last commit (before I had done anything with map_magic) and tried zipping them together, and they are definitely off.  So, if you are using this translation somewhere, you are getting rubbish things like specimen_md —> specimens.int_dac.

On Mar 20, 2017, at 9:33 AM, Lori Jonestrask<EMAIL_ADDRESS>wrote:
Can you show me where you use the magic3 variable (which file, which approximate line)?  I couldn’t find it.  I want to organize to make sure we don’t have any namespace collisions and that SPD/magic stays separate from magic3/magic2.
The current state of master doesn’t have the magic3 variable, but I’ll stick it back in based on the last commit you did (ce11ee8) where it was working.

On Mar 20, 2017, at 9:22 AM, Lisa Tauxe<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
i’m using the magic3 mapping in the criteria reading/writing thing and now it works so please don’t touch that. can we just move the spd <=> magic mapping somewhere else?
lisa

On Mar 18, 2017, at 5:21 PM, moonshoes87<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I think the problem is because you edited the “magic” list with reference to "magic3", not with reference to "spd". So the SPD mapping got all crazy. I am going to revert back so that the spd —> magic translation still works as when originally implemented.
I can't find a place where the “magic3” variable was actually ever used, and when you edited it and “magic” you were actually trying to fix a different translation (it looks like you edited the global variable magic3 and the local variable magic3 from the function convert_intensity_criteria each time you made changes). But I’m not 100% sure I got this all right.
Can you check Thellier GUI, and make sure it is still working the way you expect it to mapping wise? It looks fine to me.
The magic --> spd mapping is now back to looking like this:
[('specimen_coeff_det_sq', 'R_corr2'),
('specimen_PCA_sigma_int', 'PCA_sigma_int_Free'),
('specimen_PCA_sigma_max', 'PCA_sigma_max_Free'),
('specimen_int_ptrm_tail_n', 'n_tail'),
('specimen_dpal', 'delta_pal'),
('specimen_tail_drat', 'DRAT_tail'),
('specimen_md', 'MD_VDS'),
('specimen_ac_n', 'n_add'),
('specimen_dac', 'delta_AC'),
('specimen_cm_y', 'y_Arai_mean'),
('specimen_int_mad', 'MAD_Free'),
('specimen_int_ptrm_n', 'n_ptrm'),
('specimen_drat', 'DRAT'),
('specimen_z_md', 'IZZI_MD'),
('specimen_frac', 'FRAC'),
('specimen_cdrat', 'CDRAT'),
('specimen_dec', 'Dec_Free'),
('specimen_mdev', 'mean_DEV'),
('specimen_drats', 'DRATS'),
('specimen_z', 'Z'),
('specimen_maxdev', 'max_DEV'),
('fail_arai_beta_box_scatter', 'fail_arai_beta_box_scatter'),
('specimen_gmax', 'GAP-MAX'),
('specimen_ptrms_mad', 'pTRM_MAD_Free'),
('specimen_ptrms_dec', 'ptrms_dec_Free'),
('specimen_int_mad_anc', 'MAD_Anc'),
('fail_ptrm_beta_box_scatter', 'fail_ptrm_beta_box_scatter'),
('specimen_ptrms_angle', 'ptrms_angle_Free'),
('specimen_scat_bounding_line_low', 'scat_bounding_line_low'),
('specimen_PCA_sigma_min', 'PCA_sigma_min_Free'),
('specimen_int_uT', 'B_anc'),
('specimen_scat', 'SCAT'),
('specimen_r_sq', 'R_det2'),
('specimen_PCA_v1', 'best_fit_vector_Free'),
('specimen_b_beta', 'specimen_b_beta'),
('specimen_YT', 'specimen_YT'),
('specimen_dck', 'delta_CK'),
('lab_dc_field', 'lab_dc_field'),
('specimen_inc', 'Inc_Free'),
('specimen_mdrat', 'mean_DRAT'),
('specimen_theta', 'theta'),
('specimen_ptrm', 'max_ptrm_check'),
('measurement_step_min', 'tmin'),
('specimen_cm_x', 'x_Arai_mean'),
('fail_tail_beta_box_scatter', 'fail_tail_beta_box_scatter'),
('specimen_dtr', 'delta_TR'),
('specimen_int_alpha', 'alpha'),
('specimen_fvds', 'specimen_fvds'),
('specimen_b_sigma', 'specimen_b_sigma'),
('specimen_b', 'specimen_b'),
('specimen_g', 'specimen_g'),
('specimen_f', 'specimen_f'),
('measurement_step_max', 'tmax'),
('specimen_int_n', 'specimen_int_n'),
('specimen_q', 'specimen_q'),
('specimen_int_dang', 'DANG'),
('specimen_ptrms_inc', 'ptrms_inc_Free'),
('specimen_k_sse', 'SSE'),
('specimen_gamma', 'gamma'),
('specimen_scat_bounding_line_high', 'scat_bounding_line_high'),
('specimen_k', 'specimen_k'),
('specimen_int_crm', 'specimen_int_crm'),
('specimen_dt', 'specimen_dt'),
('specimen_k_prime', 'specimen_k_prime'),
('specimen_k_prime_sse', 'specimen_k_prime_SSE')]
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929 https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e>.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287793140, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwGIpC2kisvVtZNwqLvzD-ZwarDxE4aks5rnpmYgaJpZM4MhC4e.

I think you are just using
            crit3_0=map_magic.convert_intensity_criteria('magic3',crit)

which does not use the global magic3 variable, but a local magic3 variable defined in ‘convert_intensity_criteria’.

On Mar 20, 2017, at 9:39 AM, Lori Jonestrask<EMAIL_ADDRESS>wrote:
Ok, also, as of your last commit to map_magic (ce11ee8), the mapping between magic and magic3 is definitely broken.  I grabbed the two lists from your last commit (before I had done anything with map_magic) and tried zipping them together, and they are definitely off.  So, if you are using this translation somewhere, you are getting rubbish things like specimen_md —> specimens.int_dac.
<Screen Shot 2017-03-20 at 9.36.02 AM.png>

On Mar 20, 2017, at 9:33 AM, Lori Jonestrask<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Can you show me where you use the magic3 variable (which file, which approximate line)?  I couldn’t find it.  I want to organize to make sure we don’t have any namespace collisions and that SPD/magic stays separate from magic3/magic2.
The current state of master doesn’t have the magic3 variable, but I’ll stick it back in based on the last commit you did (ce11ee8) where it was working.

On Mar 20, 2017, at 9:22 AM, Lisa Tauxe<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
i’m using the magic3 mapping in the criteria reading/writing thing and now it works so please don’t touch that. can we just move the spd <=> magic mapping somewhere else?
lisa

On Mar 18, 2017, at 5:21 PM, moonshoes87<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I think the problem is because you edited the “magic” list with reference to "magic3", not with reference to "spd". So the SPD mapping got all crazy. I am going to revert back so that the spd —> magic translation still works as when originally implemented.
I can't find a place where the “magic3” variable was actually ever used, and when you edited it and “magic” you were actually trying to fix a different translation (it looks like you edited the global variable magic3 and the local variable magic3 from the function convert_intensity_criteria each time you made changes). But I’m not 100% sure I got this all right.
Can you check Thellier GUI, and make sure it is still working the way you expect it to mapping wise? It looks fine to me.
The magic --> spd mapping is now back to looking like this:
[('specimen_coeff_det_sq', 'R_corr2'),
('specimen_PCA_sigma_int', 'PCA_sigma_int_Free'),
('specimen_PCA_sigma_max', 'PCA_sigma_max_Free'),
('specimen_int_ptrm_tail_n', 'n_tail'),
('specimen_dpal', 'delta_pal'),
('specimen_tail_drat', 'DRAT_tail'),
('specimen_md', 'MD_VDS'),
('specimen_ac_n', 'n_add'),
('specimen_dac', 'delta_AC'),
('specimen_cm_y', 'y_Arai_mean'),
('specimen_int_mad', 'MAD_Free'),
('specimen_int_ptrm_n', 'n_ptrm'),
('specimen_drat', 'DRAT'),
('specimen_z_md', 'IZZI_MD'),
('specimen_frac', 'FRAC'),
('specimen_cdrat', 'CDRAT'),
('specimen_dec', 'Dec_Free'),
('specimen_mdev', 'mean_DEV'),
('specimen_drats', 'DRATS'),
('specimen_z', 'Z'),
('specimen_maxdev', 'max_DEV'),
('fail_arai_beta_box_scatter', 'fail_arai_beta_box_scatter'),
('specimen_gmax', 'GAP-MAX'),
('specimen_ptrms_mad', 'pTRM_MAD_Free'),
('specimen_ptrms_dec', 'ptrms_dec_Free'),
('specimen_int_mad_anc', 'MAD_Anc'),
('fail_ptrm_beta_box_scatter', 'fail_ptrm_beta_box_scatter'),
('specimen_ptrms_angle', 'ptrms_angle_Free'),
('specimen_scat_bounding_line_low', 'scat_bounding_line_low'),
('specimen_PCA_sigma_min', 'PCA_sigma_min_Free'),
('specimen_int_uT', 'B_anc'),
('specimen_scat', 'SCAT'),
('specimen_r_sq', 'R_det2'),
('specimen_PCA_v1', 'best_fit_vector_Free'),
('specimen_b_beta', 'specimen_b_beta'),
('specimen_YT', 'specimen_YT'),
('specimen_dck', 'delta_CK'),
('lab_dc_field', 'lab_dc_field'),
('specimen_inc', 'Inc_Free'),
('specimen_mdrat', 'mean_DRAT'),
('specimen_theta', 'theta'),
('specimen_ptrm', 'max_ptrm_check'),
('measurement_step_min', 'tmin'),
('specimen_cm_x', 'x_Arai_mean'),
('fail_tail_beta_box_scatter', 'fail_tail_beta_box_scatter'),
('specimen_dtr', 'delta_TR'),
('specimen_int_alpha', 'alpha'),
('specimen_fvds', 'specimen_fvds'),
('specimen_b_sigma', 'specimen_b_sigma'),
('specimen_b', 'specimen_b'),
('specimen_g', 'specimen_g'),
('specimen_f', 'specimen_f'),
('measurement_step_max', 'tmax'),
('specimen_int_n', 'specimen_int_n'),
('specimen_q', 'specimen_q'),
('specimen_int_dang', 'DANG'),
('specimen_ptrms_inc', 'ptrms_inc_Free'),
('specimen_k_sse', 'SSE'),
('specimen_gamma', 'gamma'),
('specimen_scat_bounding_line_high', 'scat_bounding_line_high'),
('specimen_k', 'specimen_k'),
('specimen_int_crm', 'specimen_int_crm'),
('specimen_dt', 'specimen_dt'),
('specimen_k_prime', 'specimen_k_prime'),
('specimen_k_prime_sse', 'specimen_k_prime_SSE')]
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929 https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e>.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287793140, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwGIpC2kisvVtZNwqLvzD-ZwarDxE4aks5rnpmYgaJpZM4MhC4e.

for the mapping in thellier_gui.
I call it here:
m2_name=map_magic.convert_intensity_criteria('magic2',crit['table_column’])
[ this one is fine!]
here:
new_data=map_magic.convert_aniso('magic3',new_aniso_parameters) # turn new_aniso data to 3.0
[which is also fine]
here:
new_data = map_magic.convert_spec('magic3', new_spec_data) # turn new_specimen data to 3.0
[which calls your new maps.all_maps and is also fine]
here:
new_data = map_magic.convert_samp('magic3',new_sample_or_site_data) # convert to 3.0
[which calls maps.all_maps]
here:
meas_data2_5 = meas_data3_0.rename(columns=map_magic.meas_magic3_2_magic2_map)
[also ends up in maps.all_maps]
so i think i avoid that bad spot and we should just remove it.
lisa

On Mar 20, 2017, at 8:41 AM, moonshoes87<EMAIL_ADDRESS>wrote:
I think you are just using
crit3_0=map_magic.convert_intensity_criteria('magic3',crit)
which does not use the global magic3 variable, but a local magic3 variable defined in ‘convert_intensity_criteria’.

On Mar 20, 2017, at 9:39 AM, Lori Jonestrask<EMAIL_ADDRESS>wrote:
Ok, also, as of your last commit to map_magic (ce11ee8), the mapping between magic and magic3 is definitely broken. I grabbed the two lists from your last commit (before I had done anything with map_magic) and tried zipping them together, and they are definitely off. So, if you are using this translation somewhere, you are getting rubbish things like specimen_md —> specimens.int_dac.
<Screen Shot 2017-03-20 at 9.36.02 AM.png>

On Mar 20, 2017, at 9:33 AM, Lori Jonestrask<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Can you show me where you use the magic3 variable (which file, which approximate line)? I couldn’t find it. I want to organize to make sure we don’t have any namespace collisions and that SPD/magic stays separate from magic3/magic2.
The current state of master doesn’t have the magic3 variable, but I’ll stick it back in based on the last commit you did (ce11ee8) where it was working.

On Mar 20, 2017, at 9:22 AM, Lisa Tauxe<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
i’m using the magic3 mapping in the criteria reading/writing thing and now it works so please don’t touch that. can we just move the spd <=> magic mapping somewhere else?
lisa

On Mar 18, 2017, at 5:21 PM, moonshoes87<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I think the problem is because you edited the “magic” list with reference to "magic3", not with reference to "spd". So the SPD mapping got all crazy. I am going to revert back so that the spd —> magic translation still works as when originally implemented.
I can't find a place where the “magic3” variable was actually ever used, and when you edited it and “magic” you were actually trying to fix a different translation (it looks like you edited the global variable magic3 and the local variable magic3 from the function convert_intensity_criteria each time you made changes). But I’m not 100% sure I got this all right.
Can you check Thellier GUI, and make sure it is still working the way you expect it to mapping wise? It looks fine to me.
The magic --> spd mapping is now back to looking like this:
[('specimen_coeff_det_sq', 'R_corr2'),
('specimen_PCA_sigma_int', 'PCA_sigma_int_Free'),
('specimen_PCA_sigma_max', 'PCA_sigma_max_Free'),
('specimen_int_ptrm_tail_n', 'n_tail'),
('specimen_dpal', 'delta_pal'),
('specimen_tail_drat', 'DRAT_tail'),
('specimen_md', 'MD_VDS'),
('specimen_ac_n', 'n_add'),
('specimen_dac', 'delta_AC'),
('specimen_cm_y', 'y_Arai_mean'),
('specimen_int_mad', 'MAD_Free'),
('specimen_int_ptrm_n', 'n_ptrm'),
('specimen_drat', 'DRAT'),
('specimen_z_md', 'IZZI_MD'),
('specimen_frac', 'FRAC'),
('specimen_cdrat', 'CDRAT'),
('specimen_dec', 'Dec_Free'),
('specimen_mdev', 'mean_DEV'),
('specimen_drats', 'DRATS'),
('specimen_z', 'Z'),
('specimen_maxdev', 'max_DEV'),
('fail_arai_beta_box_scatter', 'fail_arai_beta_box_scatter'),
('specimen_gmax', 'GAP-MAX'),
('specimen_ptrms_mad', 'pTRM_MAD_Free'),
('specimen_ptrms_dec', 'ptrms_dec_Free'),
('specimen_int_mad_anc', 'MAD_Anc'),
('fail_ptrm_beta_box_scatter', 'fail_ptrm_beta_box_scatter'),
('specimen_ptrms_angle', 'ptrms_angle_Free'),
('specimen_scat_bounding_line_low', 'scat_bounding_line_low'),
('specimen_PCA_sigma_min', 'PCA_sigma_min_Free'),
('specimen_int_uT', 'B_anc'),
('specimen_scat', 'SCAT'),
('specimen_r_sq', 'R_det2'),
('specimen_PCA_v1', 'best_fit_vector_Free'),
('specimen_b_beta', 'specimen_b_beta'),
('specimen_YT', 'specimen_YT'),
('specimen_dck', 'delta_CK'),
('lab_dc_field', 'lab_dc_field'),
('specimen_inc', 'Inc_Free'),
('specimen_mdrat', 'mean_DRAT'),
('specimen_theta', 'theta'),
('specimen_ptrm', 'max_ptrm_check'),
('measurement_step_min', 'tmin'),
('specimen_cm_x', 'x_Arai_mean'),
('fail_tail_beta_box_scatter', 'fail_tail_beta_box_scatter'),
('specimen_dtr', 'delta_TR'),
('specimen_int_alpha', 'alpha'),
('specimen_fvds', 'specimen_fvds'),
('specimen_b_sigma', 'specimen_b_sigma'),
('specimen_b', 'specimen_b'),
('specimen_g', 'specimen_g'),
('specimen_f', 'specimen_f'),
('measurement_step_max', 'tmax'),
('specimen_int_n', 'specimen_int_n'),
('specimen_q', 'specimen_q'),
('specimen_int_dang', 'DANG'),
('specimen_ptrms_inc', 'ptrms_inc_Free'),
('specimen_k_sse', 'SSE'),
('specimen_gamma', 'gamma'),
('specimen_scat_bounding_line_high', 'scat_bounding_line_high'),
('specimen_k', 'specimen_k'),
('specimen_int_crm', 'specimen_int_crm'),
('specimen_dt', 'specimen_dt'),
('specimen_k_prime', 'specimen_k_prime'),
('specimen_k_prime_sse', 'specimen_k_prime_SSE')]
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929 https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e>.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287793140, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwGIpC2kisvVtZNwqLvzD-ZwarDxE4aks5rnpmYgaJpZM4MhC4e.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287799629, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKrDeng_EAPGl1kx_PPUzV1zIEDbxZAks5rnp4qgaJpZM4MhC4e.

Yes, great.  We should be good with what I removed, then.  Let me know if you spot any sketchy behavior, but I think we are fine.

On Mar 20, 2017, at 10:14 AM, Lisa Tauxe<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
for the mapping in thellier_gui.
I call it here:
m2_name=map_magic.convert_intensity_criteria('magic2',crit['table_column’])
[ this one is fine!]
here:
new_data=map_magic.convert_aniso('magic3',new_aniso_parameters) # turn new_aniso data to 3.0
[which is also fine]
here:
new_data = map_magic.convert_spec('magic3', new_spec_data) # turn new_specimen data to 3.0
[which calls your new maps.all_maps and is also fine]
here:
new_data = map_magic.convert_samp('magic3',new_sample_or_site_data) # convert to 3.0
[which calls maps.all_maps]
here:
meas_data2_5 = meas_data3_0.rename(columns=map_magic.meas_magic3_2_magic2_map)
[also ends up in maps.all_maps]
so i think i avoid that bad spot and we should just remove it.
lisa

On Mar 20, 2017, at 8:41 AM, moonshoes87<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I think you are just using
crit3_0=map_magic.convert_intensity_criteria('magic3',crit)
which does not use the global magic3 variable, but a local magic3 variable defined in ‘convert_intensity_criteria’.

On Mar 20, 2017, at 9:39 AM, Lori Jonestrask<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Ok, also, as of your last commit to map_magic (ce11ee8), the mapping between magic and magic3 is definitely broken. I grabbed the two lists from your last commit (before I had done anything with map_magic) and tried zipping them together, and they are definitely off. So, if you are using this translation somewhere, you are getting rubbish things like specimen_md —> specimens.int_dac.
<Screen Shot 2017-03-20 at 9.36.02 AM.png>

On Mar 20, 2017, at 9:33 AM, Lori Jonestrask<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
Can you show me where you use the magic3 variable (which file, which approximate line)? I couldn’t find it. I want to organize to make sure we don’t have any namespace collisions and that SPD/magic stays separate from magic3/magic2.
The current state of master doesn’t have the magic3 variable, but I’ll stick it back in based on the last commit you did (ce11ee8) where it was working.

On Mar 20, 2017, at 9:22 AM, Lisa Tauxe<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
i’m using the magic3 mapping in the criteria reading/writing thing and now it works so please don’t touch that. can we just move the spd <=> magic mapping somewhere else?
lisa

On Mar 18, 2017, at 5:21 PM, moonshoes87<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
I think the problem is because you edited the “magic” list with reference to "magic3", not with reference to "spd". So the SPD mapping got all crazy. I am going to revert back so that the spd —> magic translation still works as when originally implemented.
I can't find a place where the “magic3” variable was actually ever used, and when you edited it and “magic” you were actually trying to fix a different translation (it looks like you edited the global variable magic3 and the local variable magic3 from the function convert_intensity_criteria each time you made changes). But I’m not 100% sure I got this all right.
Can you check Thellier GUI, and make sure it is still working the way you expect it to mapping wise? It looks fine to me.
The magic --> spd mapping is now back to looking like this:
[('specimen_coeff_det_sq', 'R_corr2'),
('specimen_PCA_sigma_int', 'PCA_sigma_int_Free'),
('specimen_PCA_sigma_max', 'PCA_sigma_max_Free'),
('specimen_int_ptrm_tail_n', 'n_tail'),
('specimen_dpal', 'delta_pal'),
('specimen_tail_drat', 'DRAT_tail'),
('specimen_md', 'MD_VDS'),
('specimen_ac_n', 'n_add'),
('specimen_dac', 'delta_AC'),
('specimen_cm_y', 'y_Arai_mean'),
('specimen_int_mad', 'MAD_Free'),
('specimen_int_ptrm_n', 'n_ptrm'),
('specimen_drat', 'DRAT'),
('specimen_z_md', 'IZZI_MD'),
('specimen_frac', 'FRAC'),
('specimen_cdrat', 'CDRAT'),
('specimen_dec', 'Dec_Free'),
('specimen_mdev', 'mean_DEV'),
('specimen_drats', 'DRATS'),
('specimen_z', 'Z'),
('specimen_maxdev', 'max_DEV'),
('fail_arai_beta_box_scatter', 'fail_arai_beta_box_scatter'),
('specimen_gmax', 'GAP-MAX'),
('specimen_ptrms_mad', 'pTRM_MAD_Free'),
('specimen_ptrms_dec', 'ptrms_dec_Free'),
('specimen_int_mad_anc', 'MAD_Anc'),
('fail_ptrm_beta_box_scatter', 'fail_ptrm_beta_box_scatter'),
('specimen_ptrms_angle', 'ptrms_angle_Free'),
('specimen_scat_bounding_line_low', 'scat_bounding_line_low'),
('specimen_PCA_sigma_min', 'PCA_sigma_min_Free'),
('specimen_int_uT', 'B_anc'),
('specimen_scat', 'SCAT'),
('specimen_r_sq', 'R_det2'),
('specimen_PCA_v1', 'best_fit_vector_Free'),
('specimen_b_beta', 'specimen_b_beta'),
('specimen_YT', 'specimen_YT'),
('specimen_dck', 'delta_CK'),
('lab_dc_field', 'lab_dc_field'),
('specimen_inc', 'Inc_Free'),
('specimen_mdrat', 'mean_DRAT'),
('specimen_theta', 'theta'),
('specimen_ptrm', 'max_ptrm_check'),
('measurement_step_min', 'tmin'),
('specimen_cm_x', 'x_Arai_mean'),
('fail_tail_beta_box_scatter', 'fail_tail_beta_box_scatter'),
('specimen_dtr', 'delta_TR'),
('specimen_int_alpha', 'alpha'),
('specimen_fvds', 'specimen_fvds'),
('specimen_b_sigma', 'specimen_b_sigma'),
('specimen_b', 'specimen_b'),
('specimen_g', 'specimen_g'),
('specimen_f', 'specimen_f'),
('measurement_step_max', 'tmax'),
('specimen_int_n', 'specimen_int_n'),
('specimen_q', 'specimen_q'),
('specimen_int_dang', 'DANG'),
('specimen_ptrms_inc', 'ptrms_inc_Free'),
('specimen_k_sse', 'SSE'),
('specimen_gamma', 'gamma'),
('specimen_scat_bounding_line_high', 'scat_bounding_line_high'),
('specimen_k', 'specimen_k'),
('specimen_int_crm', 'specimen_int_crm'),
('specimen_dt', 'specimen_dt'),
('specimen_k_prime', 'specimen_k_prime'),
('specimen_k_prime_sse', 'specimen_k_prime_SSE')]
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929 https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929 <https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929 https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287584929>>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e <https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e https://github.com/notifications/unsubscribe-auth/AAKrDbz9zVa5Bn6au1eSNlS_6EDTCuVcks5rnHUMgaJpZM4MhC4e>>.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub <https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287793140 https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287793140>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABwGIpC2kisvVtZNwqLvzD-ZwarDxE4aks5rnpmYgaJpZM4MhC4e https://github.com/notifications/unsubscribe-auth/ABwGIpC2kisvVtZNwqLvzD-ZwarDxE4aks5rnpmYgaJpZM4MhC4e>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287799629 https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287799629>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKrDeng_EAPGl1kx_PPUzV1zIEDbxZAks5rnp4qgaJpZM4MhC4e https://github.com/notifications/unsubscribe-auth/AAKrDeng_EAPGl1kx_PPUzV1zIEDbxZAks5rnp4qgaJpZM4MhC4e>.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/PmagPy/PmagPy/issues/164#issuecomment-287810567, or mute the thread https://github.com/notifications/unsubscribe-auth/ABwGIgyX9Wfwo7g9lO6KO7QF3SjLTZ5jks5rnqXIgaJpZM4MhC4e.


feat: introduce usage analytics

Analytics were temporarily removed as we sent them to a third-party
server.
With this new implementation, these are being sent to Kong Inc directly.
Furthermore, to alleviate concerns raised
in https://github.com/Kong/deck/pull/242, we are now providing a flag on
the root-level, in addition to DECK_ANALYTICS environment variable to
tweak the setting.

Codecov Report

Merging #379 (82fd70b) into main (8fa14fe) will decrease coverage by 0.59%.
The diff coverage is 5.63%.

@@            Coverage Diff             @@
##             main     #379      +/-   ##
==========================================
- Coverage   54.19%   53.59%   -0.60%
==========================================
  Files          61       62       +1
  Lines        4971     5034      +63
==========================================
+ Hits         2694     2698       +4
- Misses       1978     2037      +59
  Partials      299      299

Impacted Files
Coverage Δ

cmd/common.go
0.00% <0.00%> (ø)

cmd/dump.go
25.26% <0.00%> (-1.12%)
:arrow_down:

cmd/konnect_diff.go
73.68% <0.00%> (-4.10%)
:arrow_down:

cmd/konnect_dump.go
26.53% <0.00%> (-0.56%)
:arrow_down:

cmd/konnect_ping.go
6.66% <0.00%> (-0.48%)
:arrow_down:

cmd/konnect_sync.go
66.66% <0.00%> (-4.77%)
:arrow_down:

cmd/ping.go
33.33% <0.00%> (-2.39%)
:arrow_down:

cmd/reset.go
26.15% <0.00%> (-1.72%)
:arrow_down:

cmd/validate.go
22.58% <0.00%> (-0.76%)
:arrow_down:

utils/analytics.go
0.00% <0.00%> (ø)

... and 2 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 8fa14fe...82fd70b. Read the comment docs.


Can't load a json file in the .obsidian directory

What happened?
I’m trying to load a json file in the .obsidian directory .
What I’m trying to do
I use this js code :
```dataviewjs
const s = dv.io.normalize("test.json", ".obsidian/");
dv.paragraph(s);

const jsonString = await dv.io.load(s);
dv.paragraph(jsonString);

This code work when test.json in other obsidian path, but can’t read anything in .obsidian directory , and normalize just return "test.json".
DQL
No response
JS
const s = dv.io.normalize("test.json", ".obsidian/");
dv.paragraph(s);

const jsonString = await dv.io.load(s);
dv.paragraph(jsonString);

Dataview Version
0.5.67
Obsidian Version
1.6.7
OS
Windows

I did more experimenting and found that file names or directory names prefixed with “.” can’t be read.

OK, I used these codes for the reading file:
const jsonString = await app.vault.readRaw(“.obsidian/test.json”);
thanks anyway!


Translation still not working

Related to this one: https://github.com/Microsoft/AL/issues/1734
Also related to this one: https://github.com/Microsoft/AL/issues/1692
I'm now using build 21063, with AL 0.15.18566, the very latest build I could find.
I have my app.json set up for translation:

My workspace has a translation file:

The captions are showing up in my dev instance, and also when I publish/install the app file in a separate container, but when I submit the app file it is rejected because they claim that there is no translation file. I'm obviously doing something wrong, but I think I am following all the instructions for the translation files. Am I missing something?

Related question: is there a way for me to verify what is in the app file, so I can check it for the necessary translation file before it is submitted?

I had this same issue for our app when we submitted. The reply I got back from Microsoft was that the auto-generated XLF file cannot be accepted as it does not contain the  tags that a full XLF file would normally contain. As they told me, the generated file should only be used as a source file not a target file, which is confusing since they recently added the source-language tag in the header of the file.
I've not had the chance to blog it yet, but what I did was take that auto-generated file, copy it (and rename to something like .en-US.xlf) and then open it in the Microsoft Multilingual Toolkit and translate it from en-US to en-US, which sounds weird, but the result of that is an XLF file that has the proper  and  tags in it and will be accepted by the AppSource validation team.
You can get the toolkit at the link below, and if you go through the process of hooking it up to a text translator service in Azure, then you can use the tool to generate the XLFs in any language!
https://developer.microsoft.com/en-us/windows/develop/multilingual-app-toolkit

Ah alright now we're getting somewhere, I was actually told that the auto generated xlf file was acceptable for en-US and that I did not need to create one specifically for that language.
Thanks Mike that's something I can try.

This issue has to do with the process of submitting the app and not with the development environment. At one point there was a request to add "target-language" to the generated file but that doesn't change anything with the compilation itself, it's just a cosmetic change. The restriction about having to submit specific set of translated files should not be discussed here. Please contact people related to submitting apps.
One thing to note:
The file generated by the compiler is a compiler output, not a file of your extension. It is not used during the compilation. If you want to use it in some shape or form you have to rename/copy it. It is merely a way to get the source translation items for your translation process.
The reason why the generated translation file doesn’t specify <target> in each of the translation items is because you cannot translate in this file since it’s overwritten on each run.
A simple thing to do (if someone doesn’t want to do proofreading or something else is to simply copy the file and just do a regex repace (below). Just use these expressions in vscode.
(<source>([^<]*)</source>)
$1\n\t\t\t\t\t<target>$2</target>

I'm a little bit offended by your comment there. Here's a screenshot of the email where Microsoft tells me that the auto generated file is what they need

I can see it in my workspace, yet they are telling me it is not in the app file. How is that not about the compiler? How else can I interpret that except that something is wrong with the process of creating the app file?
The documentation should be more specific about that the compiler will ignore translation files that do not have those target tags. Nobody ever said anything about those tags to me until today.
This has absolutely nothing to do with the submission process.

I agree 100% with Daniel here. I was also quite surprised when our solution failed because of the "missing" en-US file. I don't quite understand why an auto-generated file that contains the tag of "target-language=en-US" does not actually conform to a usable file. Since the source = target in this scenario, why can't the compiler just add both the source and target tags throughout the file? I could still then take that file and change the target language and translate the file to override the existing en-US translations.
If I was only publishing my app for the en-US language don't you think it would make sense that since the source language is already en-US, I shouldn't have to do any "translating"?

That regex replace though, that is really cool :)

Update: I used the regex replace and regenerated the app file and sent it to the validation guy, and again he says the translation file is not in there.

I had to copy and rename the auto-generated file to .en-US.xlf before they would accept it. So, my submitted solution actually had 2 XLF files. One being the auto-generated one as-is, and the other being the copy that has the target tags in it and the new naming. Hope that helps!

Another update: using the multilingual tool ended up being the magic bullet.
The only difference that I can tell is an attribute of the target node called 'state' that is set to "translated". Other than that, both versions of the xlf files are identical.
By the way, the translation folder in the app file does not include the standard g.xlf file, so that is definitely ignored somehow.

So the most important thing to note is that we generate the .g file for you and the compiler does not use it so it wont be visible in the package. If you change it's content it doesn't matter. What's important is to copy the file and give the copied file some other name. People usually go with MyExtension.en-US.xlf.
The generate file is good enough buy you have to give it another name

I DID copy/rename the g.xlf file (the OP, although my screenshot only shows the standard file so maybe that's why you think I didn't) and it did not work. Having a copy of the generated file was NOT good enough, it was ignored by the app building process.
I DID add the target nodes with your regex replace (my first update) and it did not work. Having the target nodes in there was not good enough, the file was ignored by the app building process.
What finally did work was the file created by the multilingual tool. I sent you both xlf files by email.

Yes the app was submitted with the final translation file. Did you get my email and take a look at those files? I never heard back from you

Closing this issue as it got solved in an offline mail thread.


Feedback regarding the docs

[Enter feedback here]
It seems this docs is outdated as the kubernetes version shown in the picture is v1.9, however the kubernetes currently supported version is about v1.19 now. Please help to confirm if the same configuration could work for deploying the AKS integrate with AGIC currently.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 549713ae-8a7b-270a-a758-3a439d5518fe
Version Independent ID: a46c18ff-0092-0384-b1ed-3ec076516da4
Content: Create an Application Gateway ingress controller in Azure Kubernetes Service
Content Source: articles/terraform/create-k8s-cluster-with-aks-applicationgateway-ingress.md
Service: terraform
GitHub Login: @TomArcherMsft
Microsoft Alias: tarcher

@JennyLJY Thanks for contacting us. That article is out of date and being rewritten. As we already have many GitHub Issues open against that article, and this issue doesn't point to a specific problem, I'm going to close it. We should have the article updated within the next week.


ARTEMIS-2301 Minor change on Epoll and kQueue.isAvailable

small fix to logging

@franz1981 / @clebertsuconic small fix in logger, that was missed on last pr merge


Update dependencies

Especially includes a major update of turfjs. The GeometryUtil.splitByLine function was rewritten to use the polygon-splitter library.
@terrestris/devs Please review.

Finally!
I cannot judge whether polygon-splitter is a good choice, but the amount of saved code is impressive.
Is splitByLine well tested?

yes, it's actually very well tested, besides the newer turf version and the new library having a different order when calculating results. Keep in mind that I only used the library because polygonize and a few other functions from turf don't work the way they used to.


 If I do it during a compile it says [warn] Canceling execution... and then waits for compilation to finish, then throws an exception and drops me back at the prompt. The only way I know to bail out is to ^Z and then locate the job and kill -9 which is a lot of work relative to one keystroke. Is there a way to turn this off?
> test:compile
[info] Compiling 45 Scala sources to /Users/rnorris/Scala/gem/modules/core/jvm/target/scala-2.12/test-classes ...
[info] Compiling 1 Scala source to /Users/rnorris/Scala/gem/modules/json/target/scala-2.12/test-classes ...
...
^C
[warn] Canceling execution...
...
^C
[warn] Canceling execution...
^C
[warn] Canceling execution...
...
^C
...
[error] 28 errors found
[error] java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ExecutorCompletionService$QueueingFuture@62d6611a rejected from java.util.concurrent.ThreadPoolExecutor@6a29807f[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3520]
[error] 	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
[error] 	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
[error] 	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
[error] 	at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181)
[error] 	at sbt.CompletionService$.submit(CompletionService.scala:32)
[error] 	at sbt.ConcurrentRestrictions$$anon$4.submitValid(ConcurrentRestrictions.scala:169)
[error] 	at sbt.ConcurrentRestrictions$$anon$4.submit(ConcurrentRestrictions.scala:158)
[error] 	at sbt.Execute.submit(Execute.scala:257)
[error] 	at sbt.Execute.ready(Execute.scala:237)
[error] 	at sbt.Execute.notifyDone(Execute.scala:176)
[error] 	at sbt.Execute.$anonfun$retire$2(Execute.scala:147)
[error] 	at sbt.Execute.$anonfun$retire$2$adapted(Execute.scala:146)
[error] 	at scala.collection.immutable.List.foreach(List.scala:389)
[error] 	at sbt.Execute.retire(Execute.scala:146)
[error] 	at sbt.Execute.$anonfun$work$2(Execute.scala:274)
[error] 	at sbt.Execute$$anon$1.process(Execute.scala:20)
[error] 	at sbt.Execute.next$1(Execute.scala:99)
[error] 	at sbt.Execute.processAll(Execute.scala:102)
[error] 	at sbt.Execute.runKeep(Execute.scala:79)
[error] 	at sbt.EvaluateTask$.liftedTree1$1(EvaluateTask.scala:383)
[error] 	at sbt.EvaluateTask$.run$1(EvaluateTask.scala:382)
[error] 	at sbt.EvaluateTask$.runTask(EvaluateTask.scala:401)
[error] 	at sbt.internal.Aggregation$.$anonfun$timedRun$4(Aggregation.scala:96)
[error] 	at sbt.EvaluateTask$.withStreams(EvaluateTask.scala:327)
[error] 	at sbt.internal.Aggregation$.timedRun(Aggregation.scala:94)
[error] 	at sbt.internal.Aggregation$.runTasks(Aggregation.scala:107)
[error] 	at sbt.internal.Aggregation$.$anonfun$applyTasks$1(Aggregation.scala:64)
[error] 	at sbt.Command$.$anonfun$applyEffect$2(Command.scala:121)
[error] 	at sbt.internal.Aggregation$.$anonfun$evaluatingParser$11(Aggregation.scala:216)
[error] 	at sbt.internal.Act$.$anonfun$actParser0$3(Act.scala:310)
[error] 	at sbt.MainLoop$.processCommand(MainLoop.scala:121)
[error] 	at sbt.MainLoop$.$anonfun$next$2(MainLoop.scala:105)
[error] 	at sbt.State$$anon$1.runCmd$1(State.scala:227)
[error] 	at sbt.State$$anon$1.process(State.scala:233)
[error] 	at sbt.MainLoop$.$anonfun$next$1(MainLoop.scala:105)
[error] 	at sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:16)
[error] 	at sbt.MainLoop$.next(MainLoop.scala:105)
[error] 	at sbt.MainLoop$.run(MainLoop.scala:98)
[error] 	at sbt.MainLoop$.$anonfun$runWithNewLog$1(MainLoop.scala:76)
[error] 	at sbt.io.Using.apply(Using.scala:22)
[error] 	at sbt.MainLoop$.runWithNewLog(MainLoop.scala:70)
[error] 	at sbt.MainLoop$.runAndClearLast(MainLoop.scala:52)
[error] 	at sbt.MainLoop$.runLoggedLoop(MainLoop.scala:37)
[error] 	at sbt.MainLoop$.runLogged(MainLoop.scala:29)
[error] 	at sbt.StandardMain$.runManaged(Main.scala:104)
[error] 	at sbt.xMain.run(Main.scala:71)
[error] 	at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:109)
[error] 	at xsbt.boot.Launch$.withContextLoader(Launch.scala:128)
[error] 	at xsbt.boot.Launch$.run(Launch.scala:109)
[error] 	at xsbt.boot.Launch$$anonfun$apply$1.apply(Launch.scala:35)
[error] 	at xsbt.boot.Launch$.launch(Launch.scala:117)
[error] 	at xsbt.boot.Launch$.apply(Launch.scala:18)
[error] 	at xsbt.boot.Boot$.runImpl(Boot.scala:41)
[error] 	at xsbt.boot.Boot$.main(Boot.scala:17)
[error] 	at xsbt.boot.Boot.main(Boot.scala)
[error] java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ExecutorCompletionService$QueueingFuture@62d6611a rejected from java.util.concurrent.ThreadPoolExecutor@6a29807f[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3520]
[error] Use 'last' for the full log.
>

steps
As above.
problem
It's annoying.
expectation
sbt should respect ^C.
notes
sbt version: 1.0

Probably you have cancellable in Global := true in your global settings? How about ^D to exit?
Another thing is even when ^C is supposed to cancel current task, but stay in the sbt shell, it doesn't really work..

I do have cancelable in Global := true in order to ^C out of my running program back to the shell. Is there a way to scope it such that it only applies to run?

@azolotko said he can't reproduce this on 1.3.8 so I am closing this for now.


Sync Stats

Is it possible to synchronize the statistics & logs as well?
I would like to have a complete mirror of both AdGuard instances in case one fails and the access statistics are lost.

@terraboss it's not possible, as it is not supported, by the api.


Empirical loss model for tidy3d mode solver

Users can now empirically model the impact of surface scattering on waveguide propagation loss
This is done by adding a small parametrizable layer of imaginary index at the waveguide boundary as per this reference that can be calibrated to data. Top and side interfaces are treated independently.
While it is less robust than a full scattering treatment as per other references, the latter still requires external knowledge of RMS roughness and correlation length, in practice also calibrated from data. Both approaches also agree somewhat in the sense that ultimately, both only consider the overlap of the mode with the waveguide interface.
Example use:
wg = Waveguide(nmodes=2,
                    wg_width=500*nm,
                    wavelength=1.55,
                    wg_thickness=220 * nm,
                    slab_thickness=90 * nm,
                    ncore=si,
                    nclad=sio2,
                    loss_model=True, # boolean flag to trigger loss evaluation, default to False
                    sidewall_k = 1E-4, # imaginary index of scattering layer (sides)
                    top_k = 1E-4, # imaginary index of scattering layer (top)
                    sidewall_sigma = 20*nm, # thickness of scattering layer (sides)
                    top_sigma = 20*nm, # thickness of scattering layer (top)
                    resolution = 400,
                    cache=None,
                    precision='double'
                    )
wg.plot_index(func=np.imag) # new argument to pass callable to plotting function

This results in
print(wg.neffs)
print(wg.get_loss()) # new function to get loss in dB/cm

[2.58589854+6.95743124e-06j 2.16344   +9.52938134e-06j]
[2.44969153 3.35526776]

Note that fine resolution is required, which makes this method better suited to FEM, see the new package femwell if interested

fixing pre-commit now

Thank you Simon!


How to add serializer mixins

Sorry if this is the wrong place to post this but I have addon that uses mirage but I'd like to expose helper Serializer mixins to the consumer that are based off of mirage's Serializers. How would I go about doing this? I've tried passing multiple arguments to the serializer's extend() method but my serialize() method is never called.
// tests/dummy/mirage/serializers/my-serializer.js
import ApplicationSerializer from './application';
import MySerializerMixin from 'myaddon/mixins/mirage/serializer-mixin'; //same mixin exposed to consumer

export default ApplicationSerializer.extend(MySerializerMixin, {

  serialize() {
    // super call here? or prototype call?
    // do custom serialize stuff here after MySerializerMixin's serialize logic
  }
});

Hy @mkay581. Maybe this can help you
http://www.ember-cli-mirage.com/docs/v0.4.x/serializers/

Yes that page is helpful however it does not explain how to add mixins to the mirage serializer. How would I add a mixin to the serializer?

@mkay581 Sorry for the delayed response!
I know it's confusing but Mirage's classes do not use the Ember Object model, so .extend() does not behave the way it does when using Ember.Component, Ember.Route and so on.
I want to update Mirage's classes to ES6 classes eventually but today they use an extend module borrowed from Backbone.
I would check the guides to see how to call super() (it's a bit involved), and then from there figure out the best way to share Serializers with your consumers.
I'll close this for now because I want to keep these issues actionable - but please feel free to ping me back if you want to follow-up!

The problems with mixin is that it does not actually know its parent. I have my own workaround
My workaround relies on es6 classes which are basement for classic Class.extend in mirage.
Here is my example:
# timestampable-mixin.js for models
export default (superclass) => class extends superclass {

  constructor() {
    super(...arguments);
  }

  save() {
    // created at
    if (!this.attrs.createdAt) {
      this.attrs.createdAt = new Date();
    }

    // updated at
    this.attrs.lastModifiedAt = new Date();

    return super.save(...arguments);
  }

};

# model.js model file using the mixin

import { mixin } from 'addon-toolbox/javascript/es6-classes';
import TimestampableMixin from "../toolbox/model/timestampable-mixin";

export default class ProductInstance extends mixin(Model, TimestampableMixin) {

  getSelfLink() {
    return {href: `/build-management/products/${this.productId}/productInstances/${this.id}`};
  }

}

# implementation of `mixin` function

export function mixin(Klazz, ...Mixins) {
  return Mixins.reduce((Klazz, Mixin) => Mixin(Klazz), Klazz);
}


Update form.yml.erb

Im adding another script to start a bmad and impact utils simulation for facet2.

merging to dev


Pull request submitted on 2023/04/15

Added sources, lookup and schedule files for JD Edwards EnterpriseOne
Changed also the schema.yaml and terraform.tfvars.sample to include the proper sources folders

I added for JDE the modules, scripts and the rest of *.tf files.

@cbalanescuy as I mentioned for PSFT to Ada, we need to put the sources in xml instead of zip file so that users can review changes.

@kgvarun I made the changes.
Replaced zip sources to xml and add grant rules into markdown file (USER_ACCESS_TABLES.md)


Migrate rustless from std::old_io to std::io for compatibility with recent releases of Iron

Allows rustless to build with recent nightlies and recent versions of its dependencies, namely iron.
Changes

Moves from std::old_io -> std::io

old_io::Reader -> io::Read
path::Path
old_io::File -> fs::File

Removes obsolete closure syntax
Removes #![feature(env)], as env is now stable

There were the following issues with your Pull Request

Commit: 3640d0573d5cc211939ab1a7f3b3522745b75c2c
Your subject line is longer than 100 characters

Guidelines are available at https://github.com/rustless/rustless/blob/master/CONTRIBUTING.md

This message was auto-generated by https://gitcop.com

@syakhmi awesome! Thank you for your work. Travis still complains on body-parser, so I'll wait until it will be fixed. I see there is a PR already.

I've merged it with a few minor fixes. Everything is actually working with https://github.com/iron/body-parser/pull/48 (tested locally on my machine).

Excellent! Just started playing around with rust, but none of the crates were building :) Hoping to use rustless in a project


changelog: prepare for v0.0.7

Coverage remained the same at 57.646% when pulling 446247128b34fb0bcc805462479b28c39e3c9f61 on jdef_bump_changelog into 2928a8dad66db875eae3f8b0d9d387ae41934832 on master.


Fix unreadable/writable tty

Sometime the /dev/tty file is not readable and/or writable which let Symfony/Process throws an Exception.
This PR de-activate the call to setTty if the TTY mode is notavailable

Good catch, thanks Jérémy.


Fix TestWorkloadInstances flake

https://prow.istio.io/view/gs/istio-prow/logs/unit-tests_istio_postsubmit/3572
This is not graceful, but currently there is no way to get notified  whether service/endpoint/pod s are populated

if we really really need the sleep can we put it in the local test function instead of making it impact all of the other tests that don't need sleep? We don't need it in the pod or service creation anyways right, just need to make sure endpoint event is updated first

@hzxuzhonghu: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio
4de692547af2ac807fc90bb17e5e01c104a8ab9c
link
/test integ-security-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Follow-up for awesome-python-htmx

Follow-up to https://github.com/lllama/dark-star/issues/6
Would you say this project is appropriate to include? it sounds like it can use HTMX, but perhaps doesn't include it by default? Maybe the project is too much of a WIP?
Either way, as you seem active in this space, if you are interested would you mind introducing yourself on PyHAT-stack/awesome-python-htmx#2?

Early days for the project but it's come from wanting to get html to the browser as easily as possible. There's nothing explicitly htmx-specific in it, but it tries to conform to locality-of-behaviour and similar principles.

Gotcha, I guess pop on over when it's more fleshed out and you are ready to show it off :)


Inference with a Self-Trained Model

Hi! May I ask if there is a script available for performing inference using a self-trained model?
Because when I perform inference using my self-trained SL model, it prompts that config.json and args.yaml are missing.

You can make a try to copy the config.json and args.yaml from our pre-trained models.


Add Envelope/Shell/Box classes + Force Point3D to declare type of data

Most of this PR has been discussed in https://github.com/JulienPeloton/spark3D/pull/22.
I have added few minor things:

Force Point3D to declare the type of data, that is spherical (r, theta, phi) or cartesian. It was optional before.
Integrate the development made in https://github.com/JulienPeloton/spark3D/pull/22 into the Onion partitioning. Now it uses Shells instead of Sphere to partition the space.

Codecov Report

Merging #23 into master will increase coverage by 1.11%.
The diff coverage is 99.33%.

@@            Coverage Diff             @@
##           master      #23      +/-   ##
==========================================
+ Coverage   97.63%   98.75%   +1.11%
==========================================
  Files          10       12       +2
  Lines         127      401     +274
  Branches       32      133     +101
==========================================
+ Hits          124      396     +272
- Misses          3        5       +2

Impacted Files
Coverage Δ

...ark3d/spatialPartitioning/SpatialPartitioner.scala
50% <ø> (ø)
:arrow_up:

...spark3d/spatialPartitioning/OnionPartitioner.scala
100% <100%> (ø)
:arrow_up:

...in/scala/com/spark3d/geometryObjects/Point3D.scala
100% <100%> (ø)
:arrow_up:

src/main/scala/com/spark3d/utils/Utils.scala
100% <100%> (ø)
:arrow_up:

...park3d/spatialPartitioning/OnionPartitioning.scala
100% <100%> (ø)
:arrow_up:

.../main/scala/com/spark3d/geometry/BoxEnvelope.scala
100% <100%> (ø)

...in/scala/com/spark3d/spatial3DRDD/Point3DRDD.scala
100% <100%> (ø)
:arrow_up:

...ain/scala/com/spark3d/geometryObjects/Sphere.scala
100% <100%> (ø)
:arrow_up:

...in/scala/com/spark3d/spatial3DRDD/Shape3DRDD.scala
90% <100%> (+0.52%)
:arrow_up:

...ain/scala/com/spark3d/geometry/ShellEnvelope.scala
97.14% <97.14%> (ø)

... and 2 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 25c7fd6...13e31fa. Read the comment docs.


Glue Connection properties is not permitted for use due to plaintext credentials

connection_properties is required https://www.terraform.io/docs/providers/aws/r/glue_connection.html#connection_properties
I'm writing the rule to fail if PASSWORD is present in the connection_properties.
  - id: GLUE_CONNECTION_PROPERTIES     message: Glue connection properties cannot specify plaintext passwords     resource: aws_glue_connection     severity: FAILURE     assertions:       - key: connection_properties[].PASSWORD | [0]         op: absent     tags:       - glue


Populate global regex with waitforre

put info
waitforre Guild: *(\w+)
var guild $1
That thing does not seem to waitforre

Had a thought on this ... is it not waiting for and matching the text, or is it just not populating the guild variable afterwards?
In this context, var guild $1 is not currently supported.

Confirmed this with a local test - waitforre Guild: *(\w+) does wait and match on the regex, though guild isn't populated with a correct value since that isn't currently supported.

The way I currently solve this is with actions:
action (info) var guild $1;put #var guild $1 when Guild: *(\w+)$
action (info) var circle $1;put #var circle $1 when Circle:\s+(\d+)$

gosub checkinfo
goto end

checkinfo:
  put info
  waitfor Encumbrance
  action (info) off
  return

end:
echo Guild: %guild
echo Circle: %circle

It may just be an issue with the overall script. This is that same long
script I told you about the other day that had a bunch of issues. I tried
going through it line by line for a bit and saw this issue pop up. But it
could be unrelated to waitfor and may be due to something else.
On Mon, Apr 11, 2016 at 2:12 PM, Joe McBride<EMAIL_ADDRESS>wrote:

The way I currently solve this is with actions:
action (info) var guild $1;put #var guild $1 when Guild: *(\w+)$
action (info) var circle $1;put #var circle $1 when Circle:\s+(\d+)$
gosub checkinfo
goto end
checkinfo:
put info
waitfor Encumbrance
action (info) off
return
end:
echo Guild: %guild
echo Circle: %circle
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/joemcbride/outlander-osx/issues/70#issuecomment-208482604

Done in new script engine.


feat: remove golangci-lint mode

Now golangci-lint support suggested fixes: https://github.com/golangci/golangci-lint/pull/5232
So the specific mode can be removed.
I also improved the tests and handled cgo.

Thanks for your time.


Fix documentation navigation links

Please provide a description and rationale for this change, unless the commit title is clearly
sufficient.

Thanks @jucr-vcarvalho ! :+1:

Please provide a description and rationale for this change, unless the commit title is clearly
sufficient.

I was reading this with my very tired eyes for a while and wondering what this description means for the change. :laughing: Please next time, clear the description if you are not going to provide one. :)


Problem with rendering anything on Linux (Manjaro GNOME)

I've installed AvaloniaUI template following the manual and after generating project I'm not able to start app. It just exists with exit code 0. I've followed the app startup and found that it's probably caused by this line: https://github.com/AvaloniaUI/Avalonia/blob/a65a64ad9d103b46d25b8cdcd99ae0eb69f39c24/src/Skia/Avalonia.Skia/SkiaPlatform.cs#L23
My app is exiting just after reaching it. It is normal that options.CostomGpuFactory is null because it occurs in my case? Is it because I'm missing something in configuration?
Here is my Program.cs
class Program
    {
        public static void Main(string[] args) => BuildAvaloniaApp()
            .StartWithClassicDesktopLifetime(args);

        public static AppBuilder BuildAvaloniaApp()
            => AppBuilder.Configure<App>()
                .UsePlatformDetect()
                .LogToDebug()
                .UseReactiveUI();
    }

Manjaro

There were recent reports about  SkiaSharp font-loading issues on Manjaro 19 that are causing a StackOverflowException. Unfortunately we weren't able to reproduce those locally.

Where can I find that font-loading piece? I don't see any exception thrown before calling line mentioned in issue. Even there no exception is thrown, the app just stops.

Please, try running the following code:
        Console.WriteLine(SKTypeface.Default.FamilyName);
        Console.WriteLine(SKTypeface.FromFamilyName("Sans").FamilyName);

I receive following output:
Bitstream Vera Sans
Bitstream Vera Sans

Mkay, it's a different issue then.
Have you updated to 0.9.3? If you did, please, run ControlCatalog.NetCore project from release/0.9.3 branch and check if it works. If it doesn't, please, run it under debugger and try to step through the app initialization process.

My app is exiting just after reaching it.

Could you run

After updating it to 0.9.3 app launches properly. So I guess that those fixes solved my issue and I could close it now.
Thanks for help.


Auto-generate OAI-PMH database

This addresses my incorrect assumption that OAI-PMH is no longer in any
workflows by default and setting up the database is thus optional. It is
still in the retract workflow which will currently fail if the database
was not manually prepared in advance.
This patch changes the code so that an SQL code is generated which works
with all databases and ensures modifications update the modification
date property on OAI-PMH entries. This will already generate a valid
OAI-PMH repository on its own but is still compatible to the previous
trigger approach.
If a user sets up database trigger, that will ensure that the
modification date is not set in the code but the moment it is actually
being persistent in the database. This works in favor of some less
resilient harvesters. For details see background below.
This does not modify any exising database structure. It will only effect
new database table creation and does not require a migration.
Background: What are the triggers for?
OAI-PMH is a harvesting protocol supporting selective harvesting,
meaning that you can e.g. ask only for records being modified after a
given date or time. This allows harvesters to pick up the harvesting
where they last stopped and not harvesting everything every time.
The problem with setting the modification date in code is that an entry
may be written to the database during an active harvest and the
modification date of this new entry may be before the response date of
the harvest. This would mean that if a harvester assumes all records are
contained in the last response, some may get lost.
The Guidelines for Harvester Implementers addresses this problem and
harvesters should deal with this:

http://www.openarchives.org/OAI/2.0/guidelines-harvester.htm

Items in a repository may change or be added during a harvest, or
after a harvest within the same datestamp (i.e. the same day if the
datestamp is YYYY-MM-DD). This means that to incrementally harvest
from a repository, a harvester should overlap successive incremental
harvests by one datestamp increment (i.e. one day if the granularity
is YYYY-MM-DD). Furthermore, since it is repository implementation
dependent whether changes that occur during the harvest will be
reflected in the response, the from argument of the next incremental
harvest should be based on the the responseDate returned in the first
partial-list response of a sequence. When harvesting from repositories
which use a datestamp granularity of one second, it is advisable to
overlap by a small additional amount to account for any discrepancy
between the reported responseDate and the time at the repository when
any search necessary to answer the request was performed.

But at least VideoLaunge did not and the usage of SQL triggers did
protect that harvester implementation from tripping.
This means, the situation after applying this patch is:

OAI-PMH works out of the box with no modifications
If you have a very delicate harvester implementation, you can add
triggers to improve the situation.

Your pull request should…

[x] have a concise title
[x] close an accompanying issue if one exists
[x] be against the correct branch (features can only go into develop)
[x] include migration scripts and documentation, if appropriate
[x] pass automated tests
[x] have a clean commit history
[x] have proper commit messages (title and body) for all commits

This looks right to me, but I don't use OAI-PMH for anything.  @JamesUoM @ts23 any chance you can take a quick look at this and make sure it's sane?

If a OAIPMH object is created in the java with a modification time t_m  just before the start of a harvest t_h0 , but is not committed to the the database until after t_h0 then it will not get harvested during harvest h0 or the subsequent h1 unless h1 overlaps h0 completely.
In theory you only need to set the modification time right before you commit the object to the database, but the time between setting the modification and the database transaction completing causes the edge case. Therefore I'm not sure if the additional modification date assignments do anything useful.

Hi @JamesUoM, that's exactly the problem addressed in OAI's harvester implementation guide I cited above. Harvesters should expect that persisting data takes time and should not harvest from the last point in time they harvested but overlap the last harvest by a bit to avoid this issue.
That said, this does not remove the current behavior: If you continue to use the database trigger (which is still in our docs), you get the exact same behavior you had before. The Java code would set a date, but the trigger would just overwrite that.
But if you have a harvester which does not need that, or you don't use OAI-PMH at all, you can skip setting up the trigger which makes your life a bit simpler.
Right now, even if you do not use OAI-PMH, the retract workflow will fail with an SQL exception if Opencast runs with MySQL, MariaDB or PostgreSQL due to the current internal SQL syntax.
Or to put it in other words: Nothing changes for you, but things will be simpler for everyone else.

This appears to work for me.


index.md

un ejemplo con codigo usando rgba()

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@CiprianoFerdy Thank you for  creating this PR.  However, since it was created, the underlying document has changed.  Can you please review and resolve the current merge conflicts?  It could be the changes to the underlying document are so significant that your changes are no longer relevant.  If the latter is the case, it might be easier to just close this PR and create a new PR with any changes you still feel are important to make.
If you need any assistance or have questions about resolving the merge conflicts, please reply back or contact someone in the Contributors Room on Gitter.
Thank you.

We are restructuring a lot of the code and learning resources referenced in your pull request, so for now I am going to go ahead and close this pull request. Thanks again for opening this pull request and for contributing to the community.


Dynamodb get item nil

Im trying to fetch from dynamodb, but data keeps coming back as nil.
locat host = "example.com"
local result, err = dynamoClient:getItem({
    Key = {
        id = {
            S = host
        }
    },
    TableName = "tablename"
})
ngx.log(ngx.ERR, "err: ", err)
ngx.log(ngx.ERR, "result response: ", result.Item)

Its hard to debug as there is no error, but there is no data returned, so perhaps in the input is incorrect?
Im not familiar with this version of the dynamodb API, or lua, here is how i tested the data was present in Go
package main

import (
	"context"
	"fmt"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb"
	"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

func main() {
	ctx := context.Background()
	cfg, err := config.LoadDefaultConfig(ctx)
	if err != nil {
		panic(err)
	}

	svc := dynamodb.NewFromConfig(cfg)

	resp, err := svc.GetItem(ctx, &dynamodb.GetItemInput{
		Key: map[string]types.AttributeValue{
			"id": &types.AttributeValueMemberS{
				Value: "example.com",
			},
		},
		TableName: aws.String("tablename"),
	})

	if err != nil {
		panic(err)
	}

	fmt.Println(resp.Item["some_field"].(*types.AttributeValueMemberS).Value)
}

Is there somewhere i can look at debug logs from the API request to dynamo so i can see if the input is wrong?

ngx.log(ngx.ERR, "result response: ", result.Item)

The result should be a table which looks like
{ status, headers, reason, body }

You can check if result.body.Item has the correct return value, or if status is not 200 and failed because of some reason


Update Cloudy test and Cloudy notebook

Update Cloudy test to use lognormal priors.
Update Cloudy notebook such that it can be run with the current version of the CES code. @charleskawczynski: I know that you hate that notebook (or notebooks in general), but until we decide to delete it I'll keep updating it from time to time :-)

@charleskawczynski: I know that you hate that notebook (or notebooks in general), but until we decide to delete it I'll keep updating it from time to time :-)

I'm fine with keeping the notebook around if you find that it has value. It may be more efficient to use Literate to generate notebooks from the existing Julia script though, so that you don't need to maintain duplicate versions.

I will look into that, thanks!

bors r+


NFC plugin init error

I was making an app with tauri v2, but I noticed when using the nfc plugin it returns a plugin error.
error[E0425]: cannot find function init in crate tauri_plugin_nfc
--> src/lib.rs:11:35
|
11 |         .plugin(tauri_plugin_nfc::init())
|                                   ^^^^ not found in tauri_plugin_nfc
|
[dependencies]
tauri = { version = "2.0.0-beta", features = [] }
tauri-plugin-shell = "2.0.0-beta"
tauri-plugin-nfc = "2.0.0-beta"
serde_json = "1.0"
#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
tauri::Builder::default()
.plugin(tauri_plugin_shell::init())
.plugin(tauri_plugin_nfc::init())
.invoke_handler(tauri::generate_handler![greet])
.run(tauri::generate_context!())
.expect("error while running tauri application");
}

Have you found solution ?

Hi, thank for answer!
Yep, I just mess up the migration from v1 to v2, although I followed the migration docs step by step, I also close the ticket.

On 30 Mar 2024, at 8:56 PM, gato25 @.***> wrote:
Have you found solution ?
—
Reply to this email directly, view it on GitHub https://github.com/tauri-apps/plugins-workspace/issues/963#issuecomment-2028526879, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJIV7PTFZQSSFQBLNYNJIJTY25UOXAVCNFSM6AAAAABDNTUDQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYGUZDMOBXHE.
You are receiving this because you modified the open/close state.


[WIP] Add consistency check of backward propagation between 2D and ND pooling function

Fix #2109.
This PR adds a test to check consistency of backward methods of 2D and ND pooling.

This PR is replaced with #2124 .


Support Spotify

App doesn't work with spotify, really would be nice since spotify is the only service i use for music now...

Which device do you have and which OS are you on?
For me it works great with Spotify. Have you tried other services as well to see if it works in general?

Samsung A50(sm 5005f), works with music players and YouTube, only shazam seems to ignore the commands

Also works for me with lg v40 for Spotify

@kkarakk Consider leaving a logcat for @Cilenco with the debug setting enabled in the app settings. Sounds like this isn't an issue with Spotify or the app. It wouldn't make any sense that this app doesn't control Spotify, since Spotify uses Android's default media service.adb logcat

The app works for me with Spotify. However, the App was not working at first. It only worked for me after I checked the buttons for "Show Messages" (which prints a Toast when skipping songs) as well as the "Without media" button. It is still working now even when I uncheck these settings.
Maybe you can try these options and see if the app is working then.


HDDS-2202. Remove unused import in OmUtils

Removed unused import.

/label ozone

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
78
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

-1
mvninstall
44
hadoop-hdds in trunk failed.

-1
mvninstall
40
hadoop-ozone in trunk failed.

-1
compile
19
hadoop-hdds in trunk failed.

-1
compile
13
hadoop-ozone in trunk failed.

+1
checkstyle
59
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
940
branch has no errors when building and testing our client artifacts.

-1
javadoc
20
hadoop-hdds in trunk failed.

-1
javadoc
16
hadoop-ozone in trunk failed.

0
spotbugs
1028
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
31
hadoop-hdds in trunk failed.

-1
findbugs
17
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
32
hadoop-hdds in the patch failed.

-1
mvninstall
35
hadoop-ozone in the patch failed.

-1
compile
21
hadoop-hdds in the patch failed.

-1
compile
17
hadoop-ozone in the patch failed.

-1
javac
21
hadoop-hdds in the patch failed.

-1
javac
17
hadoop-ozone in the patch failed.

+1
checkstyle
28
The patch passed checkstyle in hadoop-hdds

+1
checkstyle
33
hadoop-ozone: The patch generated 0 new + 0 unchanged - 1 fixed = 0 total (was 1)

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
823
patch has no errors when building and testing our client artifacts.

-1
javadoc
21
hadoop-hdds in the patch failed.

-1
javadoc
17
hadoop-ozone in the patch failed.

-1
findbugs
30
hadoop-hdds in the patch failed.

-1
findbugs
19
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
30
hadoop-hdds in the patch failed.

-1
unit
24
hadoop-ozone in the patch failed.

+1
asflicense
30
The patch does not generate ASF License warnings.

2558

Subsystem
Report/Notes

Docker
Client=19.03.0 Server=19.03.0 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1543

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux eb0b87def2e8 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 14b4fbc

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/branch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/branch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/branch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/branch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/branch-findbugs-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-mvninstall-hadoop-hdds.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-compile-hadoop-hdds.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-compile-hadoop-hdds.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-findbugs-hadoop-hdds.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/testReport/

Max. process+thread count
306 (vs. ulimit of 5500)

modules
C: hadoop-ozone/common U: hadoop-ozone/common

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1543/1/console

versions
git=2.7.4 maven=3.3.9

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

failures unrelated to patch

Thanks @adoroszlai  & @elek