spack-stack installations on Narwhal are broken

Describe the bug
I am not sure what happened, but after installing spack-stack-1.2.0 (skylab-3.0.0) on Narwhal, I get a whole number of ctest failures with the release/skylab-v3 branch of jedi-bundle. I then went back and rebuilt jedi-bundle with the previous installation spack-stack-1.1.0 (skylab-2.0.0), and I get almost the same test failures (a few less, but that could be because the older stack doesn't have all of the libraries to turn on the latest tests/features).
The following tests FAILED:
	 26 - test_util_floatcompare (Failed)
	148 - test_l95_simplifiedl95_DRGMRESR (Child aborted)
	151 - test_l95_simplifiedl95_DRPFOM (Child aborted)
	152 - test_l95_simplifiedl95_DRPLanczos (Child aborted)
	154 - test_l95_simplifiedl95_GMRESR (Child aborted)
	158 - test_l95_simplifiedl95_PCG (Child aborted)
	159 - test_l95_simplifiedl95_PLanczos (Child aborted)
	161 - test_l95_simplifiedl95_RPLanczos (Child aborted)
	287 - saber_test_error_covariance_training_bump_hdiag_1_1-1 (Failed)
	288 - saber_test_error_covariance_training_bump_hdiag_2_1-1 (Failed)
	306 - saber_test_error_covariance_training_bump_nicas_6_1-1 (Failed)
	345 - saber_test_error_covariance_training_bump_hdiag_1_2-1 (Failed)
	346 - saber_test_error_covariance_training_bump_hdiag_2_2-1 (Failed)
	364 - saber_test_error_covariance_training_bump_nicas_6_2-1 (Failed)
	516 - test_ioda_remove_hdf5_variable_cmp (Failed)
	521 - test_ioda_obsspace (Failed)
	541 - test_ioda_obsspace_mpi (Failed)
	550 - test_ioda_obsspace_out_dims_check (Failed)
	578 - test_ioda_time_io_cmp_sondes (Failed)
	579 - test_ioda_time_io_cmp_amsua_n19 (Failed)
	580 - test_ioda_upgrader_amsua_n19 (Failed)
	581 - test_ioda_upgrader_gmi_gpm (Failed)
	582 - test_ioda_upgrader_mhs_metop-b (Failed)
	583 - test_ioda_upgrader_sondes (Failed)
	584 - test_ioda_upgrader_aod (Failed)
	585 - test_ioda_upgrader_gnssro (Failed)
	586 - test_ioda_upgrader_met_office_gpsro (Failed)
	587 - test_ioda_upgrader_zero_obs (Failed)
	596 - test_ioda-convert_aircraft_odc (Failed)
	597 - test_ioda-convert_aircraft_mixed_odc (Failed)
	598 - test_ioda-convert_surface_odc (Failed)
	599 - test_ioda-convert_surface_tcbogus_odc (Failed)
	600 - test_ioda-convert_surface_with_query_odc (Failed)
	603 - test_ioda-convert_sonde_odc (Failed)
	604 - test_ioda-convert_sonde_artificial_odc (Failed)
	605 - test_ioda-convert_sonde_truncate_profiles_odc (Failed)
	606 - test_ioda-convert_sonde_history_odc (Failed)
	607 - test_ioda-convert_sonde_time_displacement_odc (Failed)
	608 - test_ioda-convert_abiclear_odc (Failed)
	609 - test_ioda-convert_ahiclear_odc (Failed)
	610 - test_ioda-convert_amsr_odc (Failed)
	611 - test_ioda-convert_airs_odc (Failed)
	612 - test_ioda-convert_atovs_odc (Failed)
	613 - test_ioda-convert_gmihigh_odc (Failed)
	614 - test_ioda-convert_gmilow_odc (Failed)
	615 - test_ioda-convert_ssmis_odc (Failed)
	616 - test_ioda-convert_satwind_odc (Failed)
	617 - test_ioda-convert_scatwind_odc (Failed)
	618 - test_ioda-convert_gnssro_odc (Failed)
	619 - test_ioda-convert_gnssro_profile_odc (Failed)
	620 - test_ioda-convert_groundgps_odc (Failed)
	621 - test_ioda-convert_aod_odc (Failed)
	622 - test_ioda-convert_cris_odc (Failed)
	623 - test_ioda-convert_crisfsr_odc (Failed)
	624 - test_ioda-convert_hirasfsr_odc (Failed)
	625 - test_ioda-convert_hloswind_odc (Failed)
	626 - test_ioda-convert_mwri_odc (Failed)
	627 - test_ioda-convert_iasi_odc (Failed)
	628 - test_ioda-convert_mwsfy3_odc (Failed)
	629 - test_ioda-convert_sattcwv_odc (Failed)
	630 - test_ioda-convert_seviriclear_odc (Failed)
	631 - test_ioda-convert_atms_odc (Failed)
	632 - test_ioda-convert_geocloud_odc (Failed)
	633 - test_ioda-convert_surfacecloud_odc (Failed)
	634 - test_ioda-convert_altimeter_odc (Failed)
	635 - test_ioda-convert_oceancolour_odc (Failed)
	636 - test_ioda-convert_satsst_odc (Failed)
	637 - test_ioda-convert_seaice_odc (Failed)
	638 - test_ioda-convert_surfacesst_odc (Failed)
	639 - test_ioda-convert_oceansound_odc (Failed)
	640 - test_ioda-convert_oceansound_truncate_profiles_odc (Failed)
	642 - test_ioda-convert_varno_independent_column_odc_compare (Failed)
	644 - test_ioda-convert_varno_dependent_column_odc_compare (Failed)
	646 - test_ioda-convert_varno_independent_bitfield_column_odc_compare (Failed)
	648 - test_ioda-convert_varno_dependent_bitfield_column_odc_compare (Failed)
	650 - test_ioda-convert_varno_independent_bitfield_column_members_odc_compare (Failed)
	652 - test_ioda-convert_varno_dependent_bitfield_column_members_odc_compare (Failed)
	682 - ufo_test_tier1_instrument_sonde_gfs_HofX (Failed)
	683 - ufo_test_tier1_instrument_sonde_gfs_qc (Failed)
	684 - ufo_test_tier1_instrument_sfcLand_gfs_HofX (Failed)
	685 - ufo_test_tier1_instrument_sfcLand_gfs_qc (Failed)
	686 - ufo_test_tier1_instrument_sfcMarine_gfs_HofX (Failed)
	687 - ufo_test_tier1_instrument_sfcMarine_gfs_qc (Failed)
	689 - ufo_test_tier1_test_ufo_obserrorcrossvarcorr (Failed)
	691 - ufo_test_tier1_test_ufo_obserrordiagonal (Failed)
	727 - ufo_test_tier1_test_ufo_qc_grosserrorwholereport (Failed)
	784 - ufo_test_tier1_test_ufo_function_averagetemperaturebelow (Failed)
	832 - ufo_test_tier1_test_ufo_function_orbitangle_ssmis (Failed)
	872 - ufo_test_tier1_test_ufo_opr_composite_GsiSfcModel_SfcPCorrected (Failed)
	873 - ufo_test_tier1_test_ufo_opr_composite_vertInterp_SfcPCorrected (Failed)
	878 - ufo_test_tier1_test_ufo_opr_gnssrorefmetoffice (Failed)
	882 - ufo_test_tier1_test_ufo_opr_gnssrobendmetoffice_nopseudo (Failed)
	884 - ufo_test_tier1_test_ufo_opr_gnssrobendmetoffice_profile (Failed)
	944 - ufo_test_tier1_test_ufo_opr_sfcpcorrected (Failed)
	1001 - ufo_test_tier1_test_ufo_constant_predictor (Failed)
	1002 - ufo_test_tier1_test_ufo_legendre_predictor (Failed)
	1004 - ufo_test_tier1_test_ufo_orbital_angle_predictor (Failed)
	1005 - ufo_test_tier1_test_ufo_satellite_selector_predictor (Failed)
	1008 - ufo_test_tier1_test_ufo_thickness_predictor (Failed)
	1062 - ufo_test_tier1_test_ufo_variabletransforms_rhumidity_part2 (Failed)
	1106 - fv3jedi_test_tier1_convertstate_geos (Failed)
	1107 - fv3jedi_test_tier1_convertstate_geos_cf (Failed)
	1127 - fv3jedi_test_tier1_linearmodel_physics (Failed)
	1130 - fv3jedi_test_tier1_hofx_fv3lm (Failed)
	1155 - fv3jedi_test_tier1_hyb-3dvar (Failed)
	1157 - fv3jedi_test_tier1_hyb-3dvar_p12 (Failed)
	1165 - fv3jedi_test_tier1_hyb-3dvar_gfs_aero (Failed)
	1167 - fv3jedi_test_tier1_hyb-fgat_fv3lm (Failed)
	1169 - fv3jedi_test_tier1_hyb-fgat_gfs_aero (Failed)
	1173 - fv3jedi_test_tier1_hyb-4dvar_pseudo-geos (Failed)
	1179 - fv3jedi_test_tier1_diffstates_gfs (Failed)
	1180 - fv3jedi_test_tier1_diffstates_geos (Failed)
	1182 - fv3jedi_test_tier1_addincrement_gfs (Failed)
	1183 - fv3jedi_test_tier1_addincrement_geos (Failed)
	1184 - fv3jedi_test_tier1_letkf (Failed)
	1186 - fv3jedi_test_tier1_lgetkf (Failed)
	1192 - fv3jedi_test_tier1_eda_3dvar (Failed)
	1194 - fv3jedi_test_tier1_eda_block_3dvar (Failed)
	1196 - test_soca_gridgen (Failed)
	1197 - test_soca_geometry (Failed)
	1198 - test_soca_geometry_iterator_2d (Failed)
	1199 - test_soca_geometry_iterator_3d (Failed)
	1200 - test_soca_state (Failed)
	1201 - test_soca_increment (Failed)
	1202 - test_soca_model (Failed)
	1203 - test_soca_modelaux (Failed)
	1204 - test_soca_getvalues (Failed)
	1205 - test_soca_errorcovariance (Failed)
	1206 - test_soca_linearmodel (Failed)
	1207 - test_soca_varchange_ana2model (Failed)
	1208 - test_soca_varchange_balance (Failed)
	1209 - test_soca_varchange_balance_TSSSH (Failed)
	1210 - test_soca_varchange_bkgerrfilt (Failed)
	1211 - test_soca_varchange_horizfilt (Failed)
	1212 - test_soca_varchange_bkgerrsoca (Failed)
	1213 - test_soca_varchange_bkgerrgodas (Failed)
	1214 - test_soca_varchange_vertconv (Failed)
	1215 - test_soca_obslocalization (Failed)
	1218 - test_soca_forecast_identity (Failed)
	1219 - test_soca_forecast_mom6 (Failed)
	1220 - test_soca_forecast_pseudo (Failed)
	1221 - test_soca_static_socaerror_init (Failed)
	1223 - test_soca_setcorscales (Failed)
	1225 - test_soca_parameters_bump_cor_nicas_scales (Failed)
	1226 - test_soca_parameters_bump_loc (Failed)
	1228 - test_soca_enspert (Failed)
	1229 - test_soca_convertstate (Failed)
	1230 - test_soca_convertstate_changevar (Failed)
	1231 - test_soca_ensvariance (Failed)
	1232 - test_soca_parametric_stddev (Failed)
	1233 - test_soca_ensrecenter (Failed)
	1234 - test_soca_hybridgain (Failed)
	1235 - test_soca_sqrtvertloc (Failed)
	1236 - test_soca_diffstates (Failed)
	1237 - test_soca_dirac_soca_cor_nicas_scales (Failed)
	1238 - test_soca_dirac_soca_cov (Failed)
	1239 - test_soca_dirac_socahyb_cov (Failed)
	1240 - test_soca_dirac_horizfilt (Failed)
	1241 - test_soca_dirac_soca_mask (Failed)
	1242 - test_soca_dirac_soca_nomask (Failed)
	1243 - test_soca_makeobs (Failed)
	1244 - test_soca_hofx_3d (Failed)
	1245 - test_soca_hofx_4d (Failed)
	1246 - test_soca_hofx_4d_pseudo (Failed)
	1247 - test_soca_enshofx (Failed)
	1248 - test_soca_3dvar_soca (Failed)
	1249 - test_soca_3dvarbump (Timeout)
	1250 - test_soca_3dvar_godas (Failed)
	1251 - test_soca_3dvarlowres_soca (Failed)
	1252 - test_soca_3dvarfgat (Failed)
	1253 - test_soca_3dvarfgat_pseudo (Failed)
	1254 - test_soca_3dhyb (Failed)
	1255 - test_soca_3dhybfgat (Failed)
	1256 - test_soca_letkf (Failed)
	1257 - test_soca_letkf_split_observer (Failed)
	1258 - test_soca_letkf_split_solver (Failed)
	1259 - test_soca_addincrement (Failed)
	1260 - test_soca_convertincrement (Failed)
	1261 - test_soca_checkpointmodel (Failed)
Errors while running CTest

To Reproduce
Build jedi-bundle release/skylab-v3 on Narwhal using one of the two latest spack-stack installations and run the ctests.
Expected behavior
ctests pass as on other systems (there can be a small number of known failures)
System:
Narwhal
Additional context
I am not aware of that many test failures when I tested this earlier (after installing spack-stack-1.1.0/skylab-2.0.0). Need to investigate what happened in between (if anything).

Unfortunately, I don't have access to Narwhal. I might be able to figure out some more from the detailed output from these tests:

test_ioda_obsspace
test_ioda_upgrader_amsua_n19
test_ioda-convert_aircraft_odc

Could you post those details? Thanks!

I agree, it would be useful to take a look at the test log output since we can't run there.

I am pretty sure that it's got to do with MPI communication not working properly, some of the basic tests don't seem to work well.

This is the full log of all failed tests on Narwhal. I didn't have time to look into them yet, but wanted to make them available.
log.ctest.rerun-failed.narwhal.gz

I may have answered this question myself ... may need to run serial jobs through srun with -n1 ... let me try that before you spend your time on it.

@fcvdb I didn't use the script you are referring to for loading the modules, all I did was following https://spack-stack.readthedocs.io/en/latest/Platforms.html#navy-hpcmp-narwhal and then loading jedi-fv3-env, jedi-ewok-env, sp-env and building jedi-bundle. I am going to try this again with the latest jedi-bundle develop code ... it will compile overnight.

Actually, we should first do a clean reinstall of the skylab-3.0.0 environment. I'll start with this now and let you know when it is done.

I found that the default module setup on Narwhal is using a weird mix of Intel LLVM compilers (icx/icpx) and Intel classic compilers (ifort). If using icx/icpx, it should also be using ifx, but we don't want any of the new compilers yet. Will change spack-stack to use the classic compilers throughout and see what happens.


Add support for React 16.3 lifecycle methods in sort-comp

Relevant issue: #1767
The new lifecycle methods added in React 16.3 need to be added to the sort-comp rule for compatibility.
Also the rule needs to be updated to allow static method positions to be overridden so that getDerivedStateFromProps can be placed in the ordering that exists in React documentation, which appears to be how the other methods are currently ordered by default (aside from the render method).
Would love to hear any feedback/suggested changes.
I detailed potential issues etc. in my commit notes here:

Add React 16.3 lifecycle methods to default config
Allow static method position to be overriden by specification

Note: this update means that a static method of the same name as a non-static method in the sort-comp will be considered an error if it is not placed in the position corresponding to its name

Add instance-variables to the lifecycle after the constructor and before getDefaultProps

Note: This update is not required, but is a nice to have since the default order has to be updated anyway, and current behavior forces all instance variables to come after componentWillUnmount by default, which is a strange ordering.
Note: The super constructor runs prior to instance variables being instantiated, so this.props can be referenced within an instance variable definition. However, instance variables are defined prior to the current class' constructor executing. Since it is hard to represent this flow I thought it would be better to place instance variables below the constructor so as to make it obvious that this.props is defined, since defining an instance variable then using it in the constructor seems like an unnecessary use case.

Add a test case for a React 16.3 class
Update documentation to reflect changes

I think I would prefer to see the instance-variables removed from this PR so it could be debated further.  This will cause all previously passing source code to fail.  Keep in mind that many methods are defined as instance variables and should not appear before the lifecycle methods.  Further, I don't see any additional tests validating the change to instance-variables.

@webOS101 The nomenclature is a bit strange on instance-variables as they actually explicitly exclude instance-methods even if instance-methods is not a specified key. instance-variables only refers to non-static class property instantiations. Essentially the current behavior if you use class properties is for sort-comp to error out unless you define all your class properties after componentWillUnmount, which is extremely strange, considering that they are essentially equivalent to this.myClassProp = 'my value' in the constructor. I will add an instance variable to the test case I added. Let me know if you still think I should separate it though.

I certainly understand the reasoning and agree that you're probably right about where it belongs.  I'm just concerned about migrating an entire code base to the new rule to take advantage of the new lifecycle methods.  Also, if we had to revert one or the other parts of this PR, they would be tied together and not easy to separate.

I don't believe that there is an auto fix in place for this rule. However, I would argue that the current sorting behavior for instance-variables is broken, and that it would be worse to perpetuate the broken pattern in a code base than to migrate over. I see your point that it could be separated out but I would consider the current behavior a bug and if someone wanted to keep the old behavior due to their code base having been written to that standard that person could copy the default ordering and remove instance-variables from it in their eslintrc. This option seems better to me than potentially exposing new users to broken behavior. Also the addition of instance-variables was extremely simple and could be removed very easily if necessary. Mostly I just didn't want to create a potentially broken commit. Just let me know if you want me to pull it out. Thanks for the feedback!

@ljharb Technically the current behavior catches both arrow functions and regular methods as instance-methods interchangeably, and, as I mentioned above, excludes arrow functions from instance-variables. I can definitely add a prototype method version as well though. I can also make all of the lifecycle methods prototype methods but technically they can use arrow function syntax and still work so it might be good to test both cases.

Arrow functions are not instance methods though :-/

I saw that in the error but I wasn't sure if I could add 'use-strict' anywhere in order to fix the issue. I just attempted a fix by adding 'use-strict' before the test using an ES6 class on the default parser, but adding it there didn't change anything. I can try removing that test as well to see if the issue is actually related to it.

Ok it wasn't related to the test, and it in fact seems to be occurring on npm install inside of npm-cli.js.
$ nvm install 4
Downloading and installing node v4.9.1...
Downloading https://nodejs.org/dist/v4.9.1/node-v4.9.1-linux-x64.tar.xz...
Computing checksum with sha256sum
Checksums matched!
Now using node v4.9.1 (npm v2.15.11)
$ node --version
v4.9.1
$ npm --version
2.15.11
$ nvm --version
0.33.9
before_install
$ nvm install-latest-npm
Attempting to upgrade to the latest working version of npm...
* `npm` v2.x needs to first jump to the latest v2 to be able to upgrade further
/home/travis/.nvm/versions/node/v4.9.1/bin/npm -> /home/travis/.nvm/versions/node/v4.9.1/lib/node_modules/npm/bin/npm-cli.js
<EMAIL_ADDRESS>/home/travis/.nvm/versions/node/v4.9.1/lib/node_modules/npm
* Installing latest `npm`; if this does not work on your node version, please report a bug!
/home/travis/.nvm/versions/node/v4.9.1/bin/npx -> /home/travis/.nvm/versions/node/v4.9.1/lib/node_modules/npm/bin/npx-cli.js
/home/travis/.nvm/versions/node/v4.9.1/bin/npm -> /home/travis/.nvm/versions/node/v4.9.1/lib/node_modules/npm/bin/npm-cli.js
<EMAIL_ADDRESS>/home/travis/.nvm/versions/node/v4.9.1/lib/node_modules/npm
* npm upgraded to: v
$ npm install
/home/travis/.nvm/versions/node/v4.9.1/lib/node_modules/npm/bin/npm-cli.js:79
      let notifier = require('update-notifier')({pkg})

The above shows up in the logs on the Travis CI build, which makes it seem like NPM has pushed an update that has broken compatibility with Node 4. It seems like npm was upgraded to 2.15.12 here but it is hard tell since the "upgraded to" display is broken and has just printed v.

https://github.com/npm/npm/commit/834b46ff48ade4ab4e557566c10e83199d8778c6#diff-fff9baaea61bc82d9999fab7b965272c
This seems to be the commit that introduced the issue.

@joe-denea it's now fixed in nvm itself, on travis - I've reran the errored builds.

@ljharb Looks like AppVeyor is still using<EMAIL_ADDRESS>and getting the error.

Ah, good call. I'll try to fix that too.

@hamlim yes, it should be released in the next few days.

Just curious this was 16 days ago, when will the next release be coming out? 😄

@browne0 This feature was was released in 7.8.0 17 days ago 😉


Printer stops in the middle of printing

So recently while using the printer on my server, i found out that sometimes when i printing builds, and it fails to place a block, it just stops printing for that block. The server has spigot, but no anticheat/build. I changed the config a little, but i dont want to have to go back to defaults because it builds too slow. (Configuration settings below) The buildings i try to build with the printer use a lot of slabs. Please reply soon as this gets very annoying
These are the config settings i have:
Configuration file
~CONFIG_VERSION: 1

debug {
    # Dump all block states on startup.
    B:dumpBlockList=false

    # Display extra information on the debug screen (F3).
    B:showDebugInfo=true
}

general {
    # Extra blocks to consider as air for the schematic renderer.
    S:extraAirBlocks <
     >

    # Schematic directory.
    S:schematicDirectory=schematics

    # Default sort type for the material list.

    B:destroyBlocks=false

    # Destroy all blocks that can be destroyed in one tick.
    B:destroyInstantly=false

    # Place blocks only if there is an adjacent block next to them.
    B:placeAdjacent=true

    # Delay between placement attempts (in ticks).
    I:placeDelay=0

    # Place all blocks that can be placed in one tick.
    B:placeInstantly=false

    # Timeout before re-trying failed blocks.
    I:timeout=0

    swapslots {
        # Allow the printer to use this hotbar slot.
        B:swapSlot0=true

        # Allow the printer to use this hotbar slot.
        B:swapSlot1=true

        # Allow the printer to use this hotbar slot.
        B:swapSlot2=true

        # Allow the printer to use this hotbar slot.
        B:swapSlot3=true

        # Allow the printer to use this hotbar slot.
        B:swapSlot4=true

        # Allow the printer to use this hotbar slot.
        B:swapSlot5=true

        # Allow the printer to use this hotbar slot.
        B:swapSlot6=true

        # Allow the printer to use this hotbar slot.
        B:swapSlot7=true

        # Allow the printer to use this hotbar slot.
        B:swapSlot8=false
    }

}

render {
    # Alpha value used when rendering the schematic (1.0 = opaque, 0.5 = half transparent, 0.0 = transparent).
    D:alpha=0.5

    # Enable transparent textures.
    B:alphaEnabled=false

    # Delta value used for highlighting (if you experience z-fighting increase this).
    D:blockDelta=0.005

    # Highlight invalid placed blocks and to be placed blocks.
    B:highlight=true

    # Highlight blocks that should be air.
    B:highlightAir=true

    # Schematic render distance.
    I:renderDistance=8
}

server {
    # Allow players to load schematics.
    B:loadEnabled=true

    # Amount of storage provided per-player for schematics on the server.
    I:playerQuotaKilobytes=8192

    # Allow players to use the printer.
    B:printerEnabled=true

    # Allow players to save schematics.
    B:saveEnabled=true
}

Don't set the placement delay bellow 1. It's a bug and will be addressed in the following few days.

@Lunatrius Sorry, but does "addressed" mean you'll fix it and be able to set it to 0 without issues? And thanks so much for the quick reply.

It means that it will be changed/fixed.

Fixed in af0a774216ae01c8798dabebbb33a72276ef327f. Turns out it was just a debugging thing that accidentally slipped through...


Add support for Symbol.toStringTag

Could you add support for such a feature for all HTML elements and other Nodes in order that {}.toString.call(node) returns not '[object Object]'?

Now that we require Node v6, this should be a pretty easy feature to add to https://github.com/jsdom/webidl2js, which powers jsdom.

We need to remember before closing this to also set the toStringTag for non-webidl2js objects.


Error connecting to RemoteApp through Remote Desktop Gateway (0x2000D)

I've been trying to get this thing working since I found a site (http://ifconfig.dk/freerdp/) claiming that FreeRDP is the ONLY solution to connect to our RemoteApps through our RDGateway.
Servers: Windows Server 2012R2, 1 broker, 1 gateway/RDWeb and 2 session hosts
Client: running Xfreerdp 1.2.1-dev (git n/a) on Ubuntu Desktop 14.04.1 LTS (kernel 3.16.0-34) xfreerdp binary downloaded from the nightly Ubuntu repo
The same solution works just fine on Windows computer (using browser or the Microsoft Remote Desktop app) and Mac/iOS (using the Microsoft Remote Desktop App) so I know the server side things are working just fine. We're also using fully signed USERTrust certificates so we don't have any certificate errors...
I'm trying to launch through the downloaded RDP files supplied by RDWeb service but a manual connect gives the same error message...
$ bin/xfreerdp Downloads/cpub-WinSCP-ITapps-CmsRdsh.rdp<EMAIL_ADDRESS>/g:remote.company.com /p:password
[10:24:43:190] [3493:3494] [INFO][com.freerdp.client.common.cmdline] - loading channel rdpdr
[10:24:43:190] [3493:3494] [INFO][com.freerdp.client.common.cmdline] - loading channel rdpsnd
[10:24:43:190] [3493:3494] [INFO][com.freerdp.client.common.cmdline] - loading channel cliprdr
[10:24:43:190] [3493:3494] [INFO][com.freerdp.client.common.cmdline] - loading channel rail
[10:24:43:406] [3493:3494] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x2000D]
[10:24:43:411] [3493:3494] [ERROR][com.freerdp.client.x11] - Authentication only, exit status 1
or...
$ bin/xfreerdp /v:BROKER.company.com.no<EMAIL_ADDRESS>/p:password /g:remote.company.com<EMAIL_ADDRESS>/gp:password /app:'||WinSCP'
[10:39:42:043] [3668:3669] [INFO][com.freerdp.client.common.cmdline] - loading channel rail
[10:39:47:367] [3668:3669] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x2000D]
[10:39:47:381] [3668:3669] [ERROR][com.freerdp.client.x11] - Authentication only, exit status 1
I also tried to download the master from git and compile that, but it's the same version and gives the same errors.

I see that you're running from git, but I literally just pushed a fix that looks relevant, so make sure you're running 4e1194c53bb18868a642ba0b655e1e6950537e84 or later.

Unfortunately this fix doesn't help me, just checkout latest master. See log:
[someuser@t2001542]$ /usr/local/bin/xfreerdp /v:someserver /cert-ignore /u:someuser
Password:
[18:38:29:525] [10942:10943] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x2000D]
[18:38:29:526] [10942:10943] [ERROR][com.freerdp.client.x11] - Authentication only, exit status 1
[someuser@t2001542]$ /usr/local/bin/xfreerdp /version
This is FreeRDP version 1.2.2-dev (git bfccc06)

Hi dbungert - I'll be trying this shortly, I've been having some strange issues reinstalling Ubuntu on my VM test machine that I need to sort out before I can try this again on a clean system.

Hi all, is there a fix for this? im running into this issue also on master version 1.2.2-dev

Both master v. 1.2.2 and the latest (git?) 1.2.4 are not working for me in the same way. 1.2.0 works but it is not quite stable through GW. (freezing from time to time)

can confirm that 87c5377 still has this bug
[mak0@rikka ~]$ xfreerdp /g:gw.example.net /cert-ignore /v:mypc /d:example.net /u:user /p:lolpassword
[13:37:49:288] [5841:5842] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x2000D]
[13:37:49:288] [5841:5842] [ERROR][com.freerdp.client.x11] - Authentication only, exit status 1
[mak0@rikka ~]$ xfreerdp --version
This is FreeRDP version 1.2.4-dev (git 87c5377)

Hello,
what distribution of linux do you have?
Why aren’t you using also /gd: /gu: /p: or is it the same? Try it with it aswell… Btw, how do you specify username?
Henry
Von: a-a<EMAIL_ADDRESS>Gesendet: Donnerstag, 02. Juli 2015 13:40
An: FreeRDP/FreeRDP
Cc: Mican Jindrich
Betreff: Re: [FreeRDP] Error connecting to RemoteApp through Remote Desktop Gateway (0x2000D) (#2542)
can confirm that 87c5377https://github.com/FreeRDP/FreeRDP/commit/87c5377f422cc31824d83962289539a19cc9072c still has this bug
[mak0@rikka ~]$ xfreerdp /g:gw.example.net /cert-ignore /v:mypc /d:example.net /u:user /p:lolpassword
[13:37:49:288] [5841:5842] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x2000D]
[13:37:49:288] [5841:5842] [ERROR][com.freerdp.client.x11] - Authentication only, exit status 1
[mak0@rikka ~]$ xfreerdp --version
This is FreeRDP version 1.2.4-dev (git 87c5377https://github.com/FreeRDP/FreeRDP/commit/87c5377f422cc31824d83962289539a19cc9072c)
—
Reply to this email directly or view it on GitHubhttps://github.com/FreeRDP/FreeRDP/issues/2542#issuecomment-118006039.

I've just had some success with with 87c5377 by explicitly telling it /gt:rpc - during this time, the RD gateway manager on server 2012r2 I'm connected through shows me as connected with RPC-HTTP listed under the transport column.
Using /gt:auto, /gt:http or completely omitting the /gt (I believe /auto is the default in this case?) causes the errors, but for me, /gt:rpc seems to work.
I am not great at Git but I will try later when I am not meant to be working, to download an older code and see if this behaviour is the same on 1.2.0, as I recall /gt:auto worked well for me previously.
LGLumi, I am using Arch Linux, installed from only two days ago. As far as I'm aware /gd: and /gu: are recycled from /u: and /p: when you connect via a gateway and don't otherwise specify what credentials to use.

Ah, forgot about that… yeah, /gt:rpc does help aswell… Kinda missed that you didn’t have it there.
Yep, /gd /gu should work in that way, I thought it is better to try out even that option.
But /gt:rpc should be the right fix for W2k12.
Von: a-a<EMAIL_ADDRESS>Gesendet: Donnerstag, 02. Juli 2015 14:05
An: FreeRDP/FreeRDP
Cc: Mican Jindrich
Betreff: Re: [FreeRDP] Error connecting to RemoteApp through Remote Desktop Gateway (0x2000D) (#2542)
I've just had some success with with 87c5377https://github.com/FreeRDP/FreeRDP/commit/87c5377f422cc31824d83962289539a19cc9072c by explicitly telling it /gt:rpc - during this time, the RD gateway manager on server 2012r2 I'm connected through shows me as connected with RPC-HTTP listed under the transport column.
Using /gt:auto, /gt:http or completely omitting the /gt (I believe /auto is the default in this case?) causes the errors, but for me, /gt:rpc seems to work.
I am not great at Git but I will try later when I am not meant to be working, to download an older code and see if this behaviour is the same on 1.2.0, as I recall /gt:auto worked well for me previously.
LGLumi, I am using Arch Linux, installed from only two days ago. As far as I'm aware /gd: and /gu: are recycled from /u: and /p: when you connect via a gateway and don't otherwise specify what credentials to use.
—
Reply to this email directly or view it on GitHubhttps://github.com/FreeRDP/FreeRDP/issues/2542#issuecomment-118010385.

I still see this error 0x2000D sometimes, no matter if  /gt:rpc is set or not.
I can try to connect using the same connection string for a few times  one after another and sometimes I got:
[13:33:01:850] [26660:26661] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x2000D]
[13:33:01:850] [26660:26661] [ERROR][com.freerdp.client.x11] - Authentication only, exit status 1
and sometimes it works.

Same problem here. I tried latest git and I was already using /gt:rpc, that helped with some other servers, but not with the one in Azure.

Encountered this issue too, using /gt:rpc seems to work fine for now

Same problem (with or without /gt:rp) for one user with xfreerdp compile yesterday (version 1.2.4-dev git dfa2980)
I don't have the pb with my account on his computer (Debian 7) (to connect to a Windows 2012 R2 Standard)

I solve my problem by adding users/groups in the Windows 2012 group "remote desktop"

Closing this issue as resolved (/gt:rpc)
Reopen or create a new issue if it should really be detected by /gt:auto


[DOCS]

Issue Description
Hi  PA ,
I would like to add thanks to the contributor section and support section to the readme doc.
Can you please assign this issue to me?
Additional Context
It makes the document look more beautiful and it shows your love towards the contributors.
Screenshots or Examples (if applicable)
screenshot is attached below.

Proposed Solution (optional)
No response
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)

@Yash636261
Can you assign me this issue under gssoc'24?
I have worked on this issue before.
I can fix this issue.
THANK YOU!😊


[FEATURE] expose a DELETE method in upsert URL to remove records from record manager

I was wondering if you could provide a method to delete records from the record manager through the upsert URL, perhaps by implementing a DELETE HTTP method. This would greatly enhance the functionality and user experience of my application.
In my app, users can create "workspaces" similar to channels in Slack or Discord. Within each workspace, users have the ability to upload files. The current Flowise record manager implementation correctly handles duplicate chunks by either inserting, skipping, or deleting them, which works flawlessly.
However, when a user deletes a file from a workspace, my app removes the corresponding points from the vector store (Qdrant), but the associated chunks remain in the Postgres record manager. This prevents the user from re-uploading the same file with identical parameters, as the sha1 chunks persist in the database.
I noticed that there is a function called patchDeleteUpsertHistory in the node_modules/flowise/dist/services/upsert-history/index.js file, but it doesn't seem to be publicly exposed. If this function could be made available or if you could provide an alternative solution, it would greatly improve the usability and consistency of my application.
Thank you for considering my request and for your ongoing support in developing this fantastic tool.

yep patchDeleteUpsertHistory deletes record from Record Manager whenever user clear it from UI. We can support as an external API as well

Available now as API: https://docs.flowiseai.com/api-reference/document-store#/document-store-vectorstore-id


[discuss] do we need to support parsing native ingress yaml?

It is not supported temporarily. If there is a need, you can consider adding
There are mainly the following reasons:
1.In k8s, the coexistence of nginx ingress and apisx ingress can be selected;
2.Because ingress is edge traffic, during the migration from nginx ingress to apisix ingress, you may need to roll back. To facilitate quick rollback to nginx ingress, you should avoid modifying the original configuration of nginx ingress;
3.We are not planning to expand k8s native resources such as ingress;
Therefore, we have defined ApisixRoute, which can be migrated according to a single yaml. The data structure is basically the same as ingress. During the migration process, only a few modifications are required to run, and it is also convenient to roll back.

我的建议如下
1、apisix入口支持标准的种类：ingress，不支持注解部分
2、apisix扩展功能通过apisixRoute支持
3、提供一个转换器，将标准ingress转换成apisixRoute
My suggestions are as follows

The types of apisix entry support standards ingress, no need to support the annotation part
Apache APISIX extension function supporting via apisixRoute
Provide a converter to convert standard ingress to apisixRoute

We can refer to how the Kong ingress controller does it. Does it define a new CRD object or is it compatible with the original ingress configuration?

我的建议如下
1、apisix入口支持标准的种类：ingress，不支持注解部分
2、apisix扩展功能通过apisixRoute支持
3、提供一个转换器，将标准ingress转换成apisixRoute
My suggestions are as follows

The types of apisix entry support standards ingress, no need to support the annotation part
Apache APISIX extension function supporting via apisixRoute
Provide a converter to convert standard ingress to apisixRoute

Yes, this is an idea, but it will cause other problems. For example, the definition of a route will be in multiple files. You need to combine ingress and apisixRoute to determine the configuration of a route, which will cause troubles for operation and maintenance personnel.

We can refer to how the Kong ingress controller does it. Does it define a new CRD object or is it compatible with the original ingress configuration?

We can refer to how the Kong ingress controller does it. Does it define a new CRD object or is it compatible with the original ingress configuration?

We did learn a lot from kong ingress. We still have some ideas of our own, because apisix and kong still have many differences, such as the implementation of route or plugins.
Well, let's continue to explore the definition of inress.
Kong ingress uses kongIngress CRD to extend the definition of inress, uses kongPlugin to define plugins, and then binds ingress and service through annotation.
I don't think the way of using annotation is very intuitive. For example, in order to successfully define a route, we need to define kongIngress and kongPlugin. At the same time, we need to modify the annotation of service and service. This involves the creation and modification of 2-4 files.
Another problem, we can know which kongIngress is associated from the annotation of ingress, but we don't know how many ingress are referenced by kongIngress. So you have to be very careful to modify kongIngress, and be aware of the scope of this change, or strictly regulate the behavior of users.
So, kong provides konga.
However, we distinguish CRD according to the domain boundary, uniformly define the route-related configuration in apisixRoute, and take into account both ingress and extension on the data structure to facilitate rapid migration.
I believe this migration cost is worth it, and the benefit is that it no longer needs to define routes in multiple files.

We have already supported it.


Add function to wait till all sinks are finished

When writing Google Tests it would be really nice to be able to call a function that will hault until all sinks are finished writing so that the log messages show up where the failure happened. This is really only a feature request because the logging is so much faster than any console output methods.
I know this is a weird request that would really only be used during Unit Testing but it would allow people that Unit Test the ability to still use the LOG functionality to log to a console to trace down a logical issue. If you feel this needs to be done in the sinks instead of globally then I can look into that as well.

This was addressed in the closed pull request: https://github.com/KjellKod/g3log/pull/105
I'm planning to re-open the pull request but without the unsafe danling reference that the closed pull request demanded.

this is on hold for now. I don't have a strong enough use case for adding this functionality. Please chime in if you feel that you do

Hi,
I'd like to have this feature for the same reason @amarcum wrote: writing unit tests with gtest and g3log will result a console output where gtest output and testcase output will be incorrectly interleaved. Having a g3log call in test teardowns that says "wait till sinks are complete" would be really nice. The test report tool I use associates test outputs with testcases, but right now it's useless.
BTW, I have a custom sink defined which prints to stdout and flushes the stream after each line, but this is not enough, as it's up to the scheduler to decide when to run the logwriter thread and the logs still don't interleave correctly. I also added an empty function to the sink, and placed a sync call via the SinkHandle (sinkhandle->call(&MySink, nop)->wait();). This effectively waits for processing of all previous logs in the sink's Active queue, and seems to work. But as I see logs go through another queue in LogWorkerImpl, and I can't synchronize on that. Was it really necessary to spawn 2 new threads just for logging?
Long story short, it would be nice to have this feature in the lib.

Each sink has its own queue and its own thread.   If they would share queue and thread it would give rise to another heap of troubles async/synchronization issues.
The way you suggested to call the sinkhandle works.
There was a PR a long time ago which got closed without merging. It had the functionality to remove sinks which would also flush their queues.  Would that be of interest (to re-open) to address this feature request?

It is really important for a unit test to wait for all the threads it starts. Otherwise errors can occur in the test execution engine after it thinks the test is done.
(I'm using Microsoft::VisualStudio::CppUnitTestFramework in Visual Studio 2015 but I think the issue is the same for all frameworks.)
I tried creating a monitor class to init/shutdown logging for each test:
std::unique_ptr<g3::LogWorker> worker;
std::unique_ptr<g3::SinkHandle<CoutSink>> consoleSink;

TempConsoleLog::TempConsoleLog(const LEVELS minLevel)
{
    worker = g3::LogWorker::createLogWorker();
    consoleSink = worker->addSink(std2::make_unique<CoutSink>(), &CoutSink::ReceiveLogMessage);
    g3::initializeLogging(worker.get());
    g3::log_levels::setHighest(minLevel);
}

TempConsoleLog::~TempConsoleLog()
{
    if (worker)
    {
        g3::internal::shutDownLoggingForActiveOnly(worker.get());
        worker.reset();
     }
    consoleSink.reset();
}

~Active joins the thread for the sink so I think all the async activity is finished deterministically when worker is destructed. I am not sure if any new API is needed.
There is one problem: When I run tests under the debugger, the test execution engine has an unhandled access violation after all the tests have completed. Is there a better sequence I could use to shutdown logging so the test execution engine can exit cleanly?

I hear you guys.
There was a PR a long time ago which started off in the wrong direction,..
got on the right track after some input from me but the guy got pissed off
when I didn't agree with a design decision he made and he revoked some of
his code and closed the PR (revoking does nothing of course since it's all
in git history)
The PR is here: https://github.com/KjellKod/g3log/pull/105
If someone wants to take that up again I could quickly explain what needs
to be done to make it work. At this point I have no free  time to spend on
g3log except code reviews, testing and some guidence towards PR work.

Contact Information
Kjell Hedström
Mobile:  +1 -<PHONE_NUMBER>
E-mail<EMAIL_ADDRESS>
On Wed, Nov 29, 2017 at 1:23 PM, Tom Becker<EMAIL_ADDRESS>wrote:

It is really important for a unit test to wait for all the threads it
starts. Otherwise errors can occur in the test execution engine after it
thinks the test is done.
(I'm using Microsoft::VisualStudio::CppUnitTestFramework in Visual Studio
2015 but I think the issue is the same for all frameworks.)
I tried creating a monitor class to init/shutdown logging for each test:
std::unique_ptrg3::LogWorker worker;
std::unique_ptr<g3::SinkHandle> consoleSink;
TempConsoleLog::TempConsoleLog(const LEVELS minLevel)
{
worker = g3::LogWorker::createLogWorker();
consoleSink = worker->addSink(std2::make_unique(), &CoutSink::ReceiveLogMessage);
g3::initializeLogging(worker.get());
g3::log_levels::setHighest(minLevel);
}
TempConsoleLog::~TempConsoleLog()
{
if (worker)
{
g3::internal::shutDownLoggingForActiveOnly(worker.get());
worker.reset();
}
consoleSink.reset();
}
~Active joins the thread for the sink so I think all the async activity
is finished deterministically when worker is destructed. I am not sure if
any new API is needed.
There is one problem: When I run tests under the debugger, the test
execution engine has an unhandled access violation after all the tests have
completed. Is there a better sequence I could use to shutdown logging so
the test execution engine can exit cleanly?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/KjellKod/g3log/issues/106#issuecomment-347984759, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAUP3ieHCgwUfv2TJJ46d009VP1I9bCCks5s7b02gaJpZM4JKjcn
.

There was a PR a long time ago which started off in the wrong direction,..got on the right track after some input from me but the guy got pissed off when I didn't agree with a design decision he made and he revoked some of his code and closed the PR ( revoking does nothing of course since it's all in git history )
The PR is here: https://github.com/KjellKod/g3log/pull/105
If someone wants to take that up again I could quickly explain what needs to be done to make it work. At this point I have no free  time to spend on g3log except code reviews, testing and some guidence towards PR work.

Maybe I am missing something but I don't think I want to remove the sink -- that would mean keeping the log worker around between tests.
I like the approach I took with the monitor class because it did not require any API changes. I'm probably doing it wrong, because of the access violation, but in theory, it should be possible to shut down the log worker cleanly leaving the system in the state it was before logging was initialized.

No activity. Closing this.


Issue installing typings... status code (404)

Hi guys,
I've a bug when try install a typings.
When execute typings install github:aurelia/dialog displays on console the next message:
typings ERR! message Unable to read typings for "aurelia-dialog". You should check the entry paths in "typings.json" are up to date
typings ERR! caused by https://raw.githubusercontent.com/aurelia/dialog/master/dist/aurelia-dialog.d.ts/index.d.ts responded with 404, expected it to equal 200
typings ERR!
typings ERR! cwd C:\TFS\Architecture\Main\Internationalization\Intricom.Internationalization.Web\Intricom.Internationalization.Web
typings ERR! system Windows_NT 10.0.14393
typings ERR! command "C:\Program Files\nodejs\node.exe" "C:\Users\aalonso.CONTRIBUCIONS\AppData\Roaming\npm\node_modules\typings\dist\bin.js" "inst
all" "github:aurelia/dialog"
typings ERR! node -v v7.8.0
typings ERR! typings -v 2.1.1
typings ERR!
typings ERR! If you need help, you may report this error at:
typings ERR!   https://github.com/typings/typings/issues
Any fix?
Ty

The typings.json has not been updated. The typings field in the package.json is OK.

@StrahilKazlachev are you looking at this right now or do I need to create a local workaround (trying to perform a release of software and ran into this issue)

See related PR which I guess should allow this to function again.

@AdamWillden your changes have worked for me. @StrahilKazlachev can you merge to master?


Add sundry badges

Update README.md to include sundry badges (Travis, RTD, etc.).

Added PyPI, Travis and RTD badges.


Upgrade to Unity 2018.4.12 and enable depth buffer sharing

Overview
Unity 2018.4.12 contains some high impact bug fixes, specifically around depth buffer sharing.
https://unity3d.com/unity/whats-new/2018.4.12
Some notable fixes:

XR: Added device name for HoloLens 2. (1161756, 1188263)
XR: Fixed an issue that was causing the depth buffer to lag the color buffer in Windows MR. (1191487, 1191494)
XR: Fixed SPI shader issue that was causing the right depth buffer to have the left depth buffer data. (1190927)

/azp run


clone PVC with deep-flatten

When creating PVC from source pvc, the default behavior is that creating new PVC from source PVC snapshot.
so  it's dependent with parent snapshot.
how can we enable flatten as a default when using cloning PVC?

@qkfrksvl we dont have any flag to do it, you can set these values to 1 and i think it will flatten on creation https://github.com/ceph/ceph-csi/blob/a4e0c696a9f201ca7ed1459752d2d9c550d3df09/cmd/cephcsi.go#L119-L138


How can we best validate the autopkg recipes we produce?

Do we want to have Recipe Robot actually run the recipe and make sure the exitcode is zero? I'm leaning towards no, because of the risks of running newly-created .munki, .install, or .jss recipes on a production Mac.

My argument is that in developing and testing RR on 1000's of products, you're slowly validating the output to a point where it's unlikely that some individual thing is going to deviate so horribly from the capabilities of RR to handle it that it's going to need validation.
I guess if you really wanted to, you could validate the package recipe and parent chain, since that has no side-effects on your system or management server. But, I think that's going to work, so there's no need.
Plus, it would slow things down A LOT.

Agreed — it's been a few versions of RR ago since I saw it output a recipe that straight-up failed. More likely would be creation of a recipe that works but doesn't do what you intend (e.g. linking to a specific version's download URL). I think the readme will sufficiently cover the most common of those cases.


[Fix S360 Broken Issues][HDInsight] Add some APIs and mark some properties as readOnly and provide default value

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

In order to fix completeness issue, add the bellow APIs in both 2018-06-01-preview and 2015-03-01-preview API version

Add API "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.HDInsight/clusters/{clusterName}/applications/{applicationName}/azureasyncoperations/{operationId}" in applications.json
Add API "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.HDInsight/clusters/{clusterName}/extensions/{extensionName}/azureAsyncOperations/{operationId}" in extensions.json
Add API "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.HDInsight/clusters/{clusterName}/executeScriptActions/azureasyncoperations/{operationId}" in scriptActions.json
Add API "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.HDInsight/clusters/{clusterName}/restartHosts/azureasyncoperations/{operationId}" in virtualMachines.json
Add API "/subscriptions/{subscriptionId}/providers/Microsoft.HDInsight/locations/{location}/checkNameAvailability" in locations.json
Add API "/subscriptions/{subscriptionId}/providers/Microsoft.HDInsight/locations/{location}/validateCreateRequest" in locations.json
Add API "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.HDInsight/clusters/{clusterName}/updateClusterIdentityCertificate" in clusters.json

In order to fix correctness issues

mark $.definitions.ApplicationGetHttpsEndpoint.location and $.definitions.ApplicationGetHttpsEndpoint.publicPort as readOnly in applications.json
mark $.definitions.ClusterDefinition.configurations, $.definitions.Role.minInstanceCount, $.definitions.Role.scriptActions as x-ms-secret in clusters.json
Add properties: OsType, VMSizes, ESPApplied and ComputeIsolationSupported to the class $.definitions.VmSizeCompatibilityFilter in locations.json

Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[x] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.   The features already exist.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet. As soon as possible.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[x] No, no need to refresh for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[x] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[x] Please ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[x] Updating API in stable or public preview version with Breaking Change Validation errors
[x] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Hi @JeffreyRichter Could you please help review this PR?  Thank you very much~

Hi @JeffreyRichter and @RamyasreeChakka  Thanks for your comments. I have updated the PR, could you please review it again? Thank you very much~

Hi @leni-msft  This PR has been approved for breaking change, could you please help review this PR? Thank you very much~


Add Ruby 2.7.0 to .travis.yml

https://www.ruby-lang.org/en/news/2019/12/25/ruby-2-7-0-released/

Coverage increased (+0.03%) to 88.581% when pulling 2fa71c09ddfe63d741451990bee986d5b75d6ef4 on smaeda-ks:smaeda-ks/update-travis-config into b9818b8ff36551f95634011089d00b3f399fcebc on twitter:master.


Write STOPBang as on STOPBang.ca

Minor correction to the way the name of the risk assessment tool is spelled out.

Merged with 7-0-stable, thanks!


We Need This For 1.19.4

Hay Dynamic Surroundings Developer's Please Add 1.19.4

For now, you can use an unofficial fork that supports version 1.19.4 of the game.
At least until the developer of the original mod decides to make it for this version.
https://github.com/maksim789456/DynamicSurroundingsFabric

Yeah, i’d use the fork for now - 1.19.4 isn’t very well supported now and wasn’t even when it was the latest version

Closing - no plans for 1.19.x support.


Counting

Noob question:
Can I make it count the number of pages a site has? Example: sitemap-generator -countpage http://www.something.com

You could use sitemap-generator --dry http://www.something.com. At the end you get a summary like this:
Added 12 pages, ignored 0 pages, encountered 0 errors.

Counting is not the  purpose of this module so will probably not add an option for it.


⚠ Bofrost.de has degraded performance

In e1ce55b, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1604 ms

Resolved: Bofrost.de performance has improved in af0b0ae.


Upgrade to @keystone-next 25

https://github.com/keystonejs/keystone/blob/master/packages/keystone/CHANGELOG.md#2500
Came out recently with some breaking changes that we'll need to adapt to. Biggest one is the moving around how types are exported

See draft PR

🤦♂ totally missed that.
Glad I hadn't started work on it myself 😅


A number of auth errors result in status UNAUTHENTICATED without message

They pass through the bubble_up_error function at:
https://github.com/grpc/grpc/blob/master/src/core/security/client_auth_filter.c#L81
It's frustrating and time-wasting to try and debug these without at least a message to search for.

No API change needed. #2829 gets the debug story marginally better. Will address sometime in the GA time-frame.

@ctiller Is this bug still relevant?

Is there an open issue for "the correct thing to do" as stated in #2829:

The correct thing to do is move this string into the status response: this will take a little longer however.

@ctiller @jcanizales is the fix in #2829 good enough for GA? If so, I would like to keep the issue open but drop the milestone.

I wouldn't block GA on it.

Just poked through the code history, looks like this was fixed by #6798


Override xstartup with environment variable

Defines the variable JUPYTER_REMOTE_DESKTOP_PROXY_XSTARTUP to launch a custom xstartup script.
The main benefit of this is launching a different desktop e.g. https://github.com/manics/jupyter-desktop-mate/blob/main/start-mate.sh on a system where a user's home directory may be mounted, meaning ~/.vnc/xstartup doesn't exist.
Ideally this would be done with a traitlets configuration so it could be specified in one of the standard configuration paths, but the VNC server and desktop are launched using a custom jupyter-server-proxy entrypoint
https://github.com/jupyterhub/jupyter-remote-desktop-proxy/blob/4f68d135bde2bc06dd59762d4c70565c031ac34d/setup.py#L62-L64
so as far as I know it's not possible to pass a traitlets configuration object to it.

I've been prototyping a configurable entrypoint in https://github.com/jupyterhub/jupyter-server-proxy/commit/58e56671e5074214216b139013da1d0717c008aa (https://github.com/jupyterhub/jupyter-server-proxy/pull/509)
I'm undecided on what's better though, an env-var or the configurable.


Add the ability to de-list current IP on demand

Make it possible to end access instantly for the IP you're currently using.
Could be done by using special "terminate" keys that contain words like "kill", "stop", "logout" etc.

Implemented in 4a4fe3.


Fully inspect subject when contain elements matching fails

When to contain elements matching fails you usually don't get the details you need as the inspected output dot out sub trees deeper than 3 levels.

Coverage increased (+0.02%) to 93.786% when pulling 5ae0cbc28feba349f66d2523340b0e0327d66264 on ssimonsen/full-inspect-to-contain-element-matching into ff70f84e11876081f116a553bc34307a2f746857 on master.

Looks good! We might want to use this trick in some other assertions as well.

I agree, I'm trying to do a spike at work where I'm using unexpected-dom to test React components, and this was annoying me, but I'll see what else I run into.


onStateChange does not receive page update from infinite hits

🐛 Bug description

🔍 Bug reproduction
Steps to reproduce the behavior:

Go to https://codesandbox.io/s/dark-river-27qdw?file=/src/app.js:229-242
Click on "show more"
See console.log onStateChange was called
see that page did not change

Live reproduction:
https://codesandbox.io/s/dark-river-27qdw?file=/src/app.js:229-242
💭 Expected behavior

page should change, like it does when you don't use onStateChange

Environment

Version: 4.4.0

Additional context

Cannot to make onStateChange at all
         const search = instantsearch({             indexName: 'myindex',             searchClient,             initialUiState: {                 myindex: {                     query: keyword,                     refinementList:presetFacets,                     toggle:{                         is_on_sale: onlyOnSale                     }                 },             },             onStateChange({ uiState, setUiState }) {                 console.log(uiState);                 setUiState(uiState);             },         });
Any idea ?

can you open a new issue with reproduction in a sandbox please? I'm not sure what is meant to happen with just the InstantSearch constructor @giojkd

This is still happening unfortunately.

@logan-jobzmall, do you have a reproduction? The original sandbox works as expected as far as I can tell


add tags to docs view, dag view filters

Closes #6
This PR replaces the node_type filter with tags, as there isn't generally a need to filter by node types in the graph viz.
I needed to re-implement some more of the dbt graph selection code in JS -- I think we'll need to figure out better ways of doing this if/when graph selection gets more complex.
Relevant tags PR: https://github.com/fishtown-analytics/dbt/pull/1014
Test:

[x] model view shows tags for a model, or None
[x] DAG view is filterable by tags in a dropdown filter
[x] --models and --exclude accept tag: and fqn: filter strings
[x] dropdown tag filters play nice with fqn/tag selection using --models and --exclude

Screenshots!

@drewbanin hey sorry I missed this. can you throw a class="meta" or <em> on untagged to differentiate it? then 👍


Sort simulated orders when placed, not when processed

I noticed that simulated orders are sorted each time they are processed: https://github.com/betcode-org/flumine/blob/796ec51060328edac7e14678c6defd63a964d250/flumine/markets/middleware.py#L204 / https://github.com/betcode-org/flumine/blob/796ec51060328edac7e14678c6defd63a964d250/flumine/markets/middleware.py#L214. I think it's enough to sort them as they are added and therefore cut out a lot of unnecessary work.
When I ran this patch against my own recorded data and simple test strategy it finished ~5% faster and the net profit at the end was the same.
I've made this a draft and haven't touched the tests as I am not 100% sure this a safe change to make, so I'm opening for discussion.
If you think it's a good idea and safe to do then I will happily finish it off properly.

My integration tests pass with this branch so happy for it be completed and included in 2.5.0


[AIRFLOW-647] Restore dag.get_active_runs(), without the DB updates

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

https://issues.apache.org/jira/browse/AIRFLOW-647

Simply added a getter back to dag that returns the list
of active dag run execution dates for the dag (without
the DB updates and validity checks) from the DB.
This fixes our DAGs, as many of them relied on this to
validate that there weren't stuck DAGs.
In addition, put in a simple test to validate the function

Current coverage is 65.95% (diff: 100%)

Merging #1899 into master will increase coverage by 0.06%

@@             master      #1899   diff @@
==========================================
  Files           129        129
  Lines          9959       9966     +7
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           6562       6573    +11
+ Misses         3397       3393     -4
  Partials          0          0

Powered by Codecov. Last update 7c94d81...f8f25c5


UI - Pattern Filtering

Changes:

Add ability to filter property values or property keys based on regular expression input
Nodes with properties that don't have matching values to the regex and property specified are filtered out, and nodes that don't have that property to begin with are also filtered out.
If no value is entered, it uses the property specified as a regex pattern instead and filters the properties.
A bunch of refactoring in the filtering code
Basic examples for regex noobs (including yours truly):

Filter out nodes that don't contain at least one 1 in their user_id:

Filter out nodes that don't contain this exact number pattern in their time:

Filter out nodes that don't have at least one property key matching the property pattern specified:

+1

+1

+1

@winder487
@mcsgroi
@agomez-dev
@rwhite226
I added pattern filtering for property keys in addition to property values from before, see extra example above and check everything out.

+1

+1


Fix - Work Experience Website Link Redirects to 404 if manually entered without http/https

Issue - When user enters the "Website" in Work Experience and enters it without http or https, on clicking on that link, the user gets routed to 404 Page
This issue exists in all 6 templates currently
Fix- Added addHttp(url) in link prop in Section.tsx files of all the 6 templates

How silly of me, I missed out on adding the utility function in the most important place 😄  Thank you so much for this, and also kudos to finding out about the existing addHttp function.

Thanks @AmruthPillai and Kudos to you for writing such a developer friendly & readable code, it wasn't hard to find these utility functions 👍🏻 😀


libwpe workaround for rpi to be removed from OE-Core

Please migrate the corresponding workaround code for libwpe to meta-raspberrypi, if still applicable, as it is to be removed from OE-Core.
# Workaround build issue with RPi userland EGL libraries.
CFLAGS:append_rpi = " ${@bb.utils.contains('MACHINE_FEATURES', 'vc4graphics', '', '-D_GNU_SOURCE', d)}"

https://lists.openembedded.org/g/openembedded-core/topic/84653556

I think it is safe to go ahead and migrate. I'm curious why was it done there in the first place.


microej microcontroller for java and Deeplearning4j

Can we use Deeplearning4j on microej java so that we can use this library on modern microcontrollers?
Or can you check and support in future for microcontroller java (microej) ?

@eix128  it's kind of hard to tell from the web page where to get started for supporting the SDK here: https://www.microej.com/product/sdk/ do you have more info? We already support android in the latest 1.0.0-M1 version if you can try that we'd be happy to see if it works or not.

Okay , but android runs on expensive cards.
You can run microej on ESP32 microcontroller
You can check out:
https://developer.microej.com/create-your-first-application/get-started-app-development-on-espressif-esp32-wroverkit-v41/
You may try it without ESP32 chip on QEMU
https://github.com/Ebiroll/qemu-xtensa-esp32

Dl4j is probably requires some disc space to work. MCUs are wery slow and it's cheaper to buy full pc to train plain modern neural networks. They're useful only for relatively small lightweight neural networks. It is possible to launch heavy one, but here is a chance that it will be calculated too long to actually work. Check Jetson Nano. It has pretty fast for it's cost and have GPIO ports.
Anyway it's not too hard to program neural layes on them. Check if you have disk space. If microEJ stuff can provide correct environment it could work. But they are more likely to cut Java, not to provide full PC Java behaviour.

@jljljl javacpp extracts all binaries on disk to work, but we could look in to making libnd4j run on this pretty easily. It's standalone and just runs math operations.
I would defer to seeing what hardware you run on a case by case basis with this. There's a lot of ways to reduce the size of neural networks as well. It's not a simple solution.
Regardless of whether the jetson nano exists or not, there's no reason we can't at least assess different platforms.
You're technically recommending a platform we don't fully support and publishes a cuda version that's fully out of support on any platform now. It really depends on the use cases.

Maybe you can make Deeplearning4j lightweight version that is compatible with microej ?
It would be good if you add something like that.
So Java's WORA action will be success for Deeplearning4j library

@eix128 It is pretty lightweight for now. Removing HDD requirement would make it possible to run on MCUs.

@jljljl @eix128 one of the major issues I see has to do with binary size. We've discovered that the binary size for libnd4j being what it is (~150 MB for all ops) is a bit much. I'd want to find a way to reduce the size of the native dependencies. We have a way of doing that in libnd4j that just allows us to build with specific binaries but haven't did much with it yet.

@agibsonccc I guess it's not a problem to connect micro sd card with few GB of memory. Memory could be helpful for such systems. Rebuilding from 150 MB to 4 MB is very hard. It might be another lib. Right now here is nothing to compress cause lib is bugged. Let's focus on bugfixes instead of new features.

@jljljl  micro sd is how many embedded computers do it. Regarding this, actually no not really. The overhead comes from having a ton of ops built in. A simple thing that just stripped out unneeded ops would more than suffice to cut down the binary size. We already have something like that as I mentioned.

Maybe pure java ND4J solution may work.
So DL4J size will decrease much ?

@eix128  we got rid of that long ago. We used to have a pure java backend but found it to be impractical save for very minor use cases.


Remove http-service-hyper

This removes http-service-hyper. We had trouble bringing this along for the updates, and in general has proven difficult to work with. This removes it from our source, and enables for tests to pass and for us to publish a new round of releases for http-service. Thanks!

This has been signed off on over chat. Thanks!


packager stops without any messages on a Windows host platform

When I try to package my simple application ( https://github.com/ZoolWay/electron-typescript-aurelia-starter ) I run:
D:\Daten\Tech Files\Development\electron-typescript-aurelia-starter>electron-packager . --platform=win32 --arch=x64
  electron-packager Electron Packager 8.3.0 +0ms
  electron-packager Node v6.6.0 +0ms
  electron-packager Host Operating system: win32 (x64) +0ms
  electron-packager Packager Options: {"_":["."],"all":false,"deref-symlinks":true,"download":{"strictSSL":true},"overwrite":false,"prune":true,"platform":"win32","arch":"x64","dir":".","protocols":[]} +0ms
  electron-packager Target Platforms: win32 +0ms
  electron-packager Target Architectures: x64 +0ms
  electron-packager Inferring application name from name in D:\Daten\Tech Files\Development\electron-typescript-aurelia-starter\package.json +15ms
  electron-packager Inferring app-version from version in D:\Daten\Tech Files\Development\electron-typescript-aurelia-starter\package.json +0ms
  electron-packager Inferring target Electron version from electron-prebuilt in D:\Daten\Tech Files\Development\electron-typescript-aurelia-starter\package.json +0ms
  electron-packager Application name: electron-typescript-aurelia-starter +0ms
  electron-packager Target Electron version: 1.4.10 +0ms
  electron-packager Ignored path regular expressions: [ '/node_modules/electron($|/)',
  '/node_modules/electron-prebuilt($|/)',
  '/node_modules/electron-packager($|/)',
  '/\\.git($|/)',
  '/node_modules/\\.bin($|/)',
  '\\.o(bj)?$' ] +0ms
  electron-packager Downloading Electron with options {"strictSSL":true,"platform":"win32","arch":"x64","version":"1.4.10"} +6s
Packaging app for platform win32 x64 using electron v1.4.10
  electron-packager Creating C:\Users\ZoolWay\AppData\Local\Temp\electron-packager\win32-x64-template +243ms
  electron-packager Extracting C:\Users\ZoolWay\.electron\electron-v1.4.10-win32-x64.zip to C:\Users\ZoolWay\AppData\Local\Temp\electron-packager\win32-x64-template +4ms
  electron-packager Initializing app in C:\Users\ZoolWay\AppData\Local\Temp\electron-packager\win32-x64\electron-typescript-aurelia-starter-win32-x64 from C:\Users\ZoolWay\AppData\Local\Temp\electron-packager\win32-x64-template template +1s
  electron-packager Ignored paths based on the out param: [ 'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-darwin-ia32',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-darwin-x64',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-darwin-armv7l',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-linux-ia32',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-linux-x64',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-linux-armv7l',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-mas-ia32',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-mas-x64',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-mas-armv7l',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-win32-ia32',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-win32-x64',
  'D:\\Daten\\Tech Files\\Development\\electron-typescript-aurelia-starter\\electron-typescript-aurelia-starter-win32-armv7l' ] +17ms

Then it finishes without anything else to say. I am back at my console shell, no output generated.
As you see I call it like this:
electron-packager . --platform=win32 --arch=x64

The pure electron-quick-start works but not with this project of myself. Most confusing is exiting without any error message.

Hrm. Try setting DEBUG=*and then pasting the Electron Packager output in a gist (because that's the ultra verbose setting).

Thanks @malept , did not know about DEBUG=*.
Here is the gist: https://gist.github.com/ZoolWay/bee85209aacc45e4114de155b78919f5
To me looks like it is just stopping in the middle of things.

That is extremely strange. The last two debug lines should be flipped, for one.
It looks like your temporary directory is on a different drive than your app's working directory. Could you try having your working directory on the same drive as your temporary directory? (It shouldn't matter, but I have a bad feeling about this.)

I updated the gist using the tmpdir option to use D:\tmp - so everything should be on drive D:. No success.
Also I moved the folder directly under D:\ to have no space in the path and a shorter name. Still no success.

I still think this is Windows-specific. Is it possible to try with a different host platform? (keep the target the same)

I have now tried a different machine but I only got Win 10 machines here. The same result.
Also note that the same command line works for the electron-quickstart project (cloned, npm installed, packaged) - so I am not sure.
Failing the packaging without any error, thats really strange.
I might be able to test it in a Linux VM but not before Sunday. But you could try with my repo by yourself if you got a minute to spare ( https://github.com/ZoolWay/electron-typescript-aurelia-starter ).
Otherwise I will come back after a Linux test. Let me know if I can try something else or make it more verbose in any way.

Ok, found an old VM with Ubuntu and installed nodejs, etc. plus wine.
Building the linux package works and building the win32-x86 package works there too. I updated the gist with the log (DEBUG=*) from the latter in case it helps.

Fair warning, since this appears to be a Windows-specific issue, it may be a while before I find the time to boot up a Windows VM and debug this.
If you would to try debugging this yourself, this is what I'm going to do: put a bunch of debug statements in the initializeApp and win32 code and see which function call it runs before it stops.

Interestingly, this also fails using https://github.com/Microsoft/BashOnWindows

Yeah, I imagine it's Windows-internals-specific.
I still haven't found time to debug this and would appreciate someone else who's motivated to follow the instructions in my earlier comment and post the results here.

><EMAIL_ADDRESS>package C:\Users\Jiaqin Meng\GamempireApp\client
> electron-packager ./ Gamempire --overwrite --app-version=1.0.0 --platform=win32 --arch=all --out=../demo --version=electronVersion

The version parameter is deprecated, use electronVersion instead
Packaging app for platform win32 ia32 using electron v1.4.13`

then it is crashed for no reason and no error log appears.i am looking for a solution to package

@mmmmeng3

--version=electronVersion

That's not what that deprecation message means. Use --electron-version instead of --version. This will be clearer in the next release.
I still need a volunteer to debug this.

i dont know if this help. i add flag with --ignore=node_,modules. it solves all my problem.

I tried --ignore=node_modules too and at least I get a package now. Have to verify if the others errors are mine or by packager.

It would really help if someone could make a minimal testcase that reproduces the problem. Using the electron-quick-start repository as a base, could someone please create a minimal Electron app that illustrates this issue, and post a link to it here?  You need to modify electron-quick-start to be packageable.

@malept I was not going to reproduce the problem. I just confirmed that quick start works and placed the log of cmd for you to see the deps so that you can have the picture. The case is particular so the dev only knows where to dig into.

I am experiencing the same problem on Windows 10 64 bit. Packaging the same project works fine on OSX.
Here is my log: https://gist.github.com/arekkas/bee174bac37357a8910f48693fd5a1b7

@malept here is a reproducible case: https://github.com/arekkas/electron-quick-start/tree/544
npm i
npm run package

@englishextra could you please post the npm i log to gist? It's making the issue so long and the npm install log is not really interesting.

To be clear to future commenters: this only affects Windows.
@arekkas thank you for the log.
This confirms my suspicion from my earlier comment. Someone who has this problem, please try the following: put a bunch of debug statements in the initializeApp function (inside common.js) and win32.js file and see which function call it runs before it stops.

My suspicion is a long path issue in one of the node modules. Nothing concrete yet though.

@malept so apparently we make it past the last statement in common.js:
initializeApp()
// ...
    series(operations, function (err) {
      console.log('cb err', err) // this is never being called
      if (err) return callback(err)
      callback(null, tempPath)
    })
    console.log('end') // this gets executed
  },

but we're not making it in the callback in win32.js:
  createApp: function createApp (opts, templatePath, callback) {
    common.initializeApp(opts, templatePath, path.join('resources', 'app'), function buildWinApp (err, tempPath) {
      console.log('init cb') // we don't make it until here

I've tried this hack to debug which operation is causing the trouble, it seems like it's operation 1:
    series(operations.map((o, k) => (args) => {
      console.log('operation', k) // prints "operation 1", "operation 2"
      return o(args)
    }), function (err) {
      if (err) return callback(err)
      callback(null, tempPath)
    })

@arekkas, I appreciate you taking the time to look at this. This is the first operation. This is the second. I take it you're saying it's the second (because 0-based indexes)?

@malept yes, it's the second. although it seems that we're finishing that one too. my guess is that fs.copy is not calling the callback. I tried wrapping it in a try/catch block which doesn't say anything either. I'm currently investigating if it's a path issue or something.

ok, now it threw an error:
EPERM: operation not permitted, open 'D:\Temp\electron-packager\win32-x64\ORY Sites App-win32-x64\resources\app\.git\objects\05\f8aed8fed644d5c291c1a73b90366152964b24'

Ah, scrap my last comment. It was caused by me removing the filter from fs.copy

Could this be the cause?

@arekkas Nope, I haven't even released that yet :smile:

Ok, damnit. :D
So I just tried this:
        try {
          fs.copy(opts.dir, appPath, {filter: ignore.userIgnoreFilter(opts), dereference: shouldDeref}, () => {
            console.log('GOT CALLED BACK')
          })
        } catch (e) {
          console.error(e)
        }

which yields...nothing. So I guess it's something with the copy task that doesn't call the callback properly.

@arekkas just for completeness's sake, could you try with Electron Packager master? I want to make sure it's still a problem in the latest fs-extra before I go asking that you escalate this to the upstream module's issue tracker.

how does that work, npm i electron-packager@master?

I investigated if the issue is with spaces in the path (D:\Temp\electron-packager\win32-x64\ORY Sites App-win32-x64\resources\app) but it's not. I used the electron template with the same name and packaging that worked. One more indicator that this could be a long filename issue (it's in fs.copy, it's not reproducible with the boilerplate app, it's not the tmp path)

I think you can just say npm install $GIT_URL.

Adding "electron-packager": "git+https://github.com/electron-userland/electron-packager.git", in the package.json did the trick. :)
Unfortunately, the issue persists on the master branch.

upstream: https://github.com/jprichardson/node-fs-extra/issues/358
Let's see what they say.

@arekkas thanks for filing the issue, it is greatly appreciated.

Thank you for being so responsive, not a lot of maintainers are!

I resolved the issue by disabling my AV, see here

Try upgrading to node 7.6.0. It seems to be working with that one!

Any leads on this one? I'm stuck with the same issue for one of my projects. But my another project for win32 is completing without any issue.

Evidently, try the latest Node 7.

I updated to Node 7.7.2 and it is now working as expected. Now that's a relief.
Thanks!

I'm going to close this, since there's a workaround and it appears to be a Node problem, not an Electron Packager problem.

I don't know why but --ignore=node_modules fixed my problem, thanks to @mmmmeng3.
Without it, the only thing I get from the run was :
Packaging app for platform win32 x64 using electron v1.6.8.

With it :
Packaging app for platform win32 x64 using electron v1.6.8
Wrote new app to release-app\cogeo-app-win32-x64

Adding --ignore=node_modules fixed my build issue, though I needed a package in there.
Deleting my node_modules folder and then reinstalling with npm i fixed my problems.


Restore minification as an option

One of the previous versions had the option to choose during compilation, whether to minify the diagram or not. It would be great if you allowed generating a non-minified diagram.

Thank you for your suggestion. I have removed this option of the v2 because I didn't have the time to maintain this feature. However I understand your need, I will add this option as soon as I can.

The option has been restored from V1 and is available as 2.1.0 on NuGet right now!
Don't hesitate to report any bug or suggestion about it.
Thanks for your patience.


Enforce the upwards data flow interface

Allow sending arbitrary name/value pairs upwards via this.fire('name-changed', value) and let them participate in the data flow.
Two use-cases for this:

Generally any data/event producer could just forward or pass new data (from a stream) upwards without storing it locally. Consider <iron-ajax>, instead of this.response = ... we would just notifyUpwards('response', ...) and forget about the response immediately.

The producing element just produces arbitrary name/value pairs that cannot be hardcoded or foreseen at all. The user uses this element like every other element. Consider a typical route-matching element, based on user input (the route pattern) varying symbols (in the example below userId or postId) will pop up. So the element gets a polymorphic shape.

    <x-ample
        pattern="/user/:userId"
        url="[[location]]"
        userId="{{userId}}"
    ></x-ample>
    <x-ample
        pattern="/blog/:postId"
        url="[[location]]"
        postId="{{postId}}"
    ></x-ample>
    <dom-module id="x-ample">
        <script>
            Polymer({
                is: 'x-ample',
                properties: {
                    pattern: String,
                    url: String,
                },
                observers: ['match(pattern, url)'],
                match: function(pattern, url) {
                    /*  m a g i c */
                    for (var name in matches) {
                        this.notifyUp(name, matches[name]);
                    }
                }
            });
        </script>
    <dom-module>

In your example, where is matches defined?

In /*  m a g i c */.

This is essentially blocked by a suspicious comment by @sorvell https://github.com/Polymer/polymer/blob/edb59eb6283074ce54f374b30b884c9f9fcf9f5f/src/lib/bind/accessors.html#L222

// TODO(sorvell): even though we have a value argument, we must
// lookup the current value of the property. Multiple listeners and
// queued events during configuration can theoretically lead to
// divergence of the passed value from the current value, but we
// really need to track down a specific case where this happens.

The problem that lead to this comment was reported by me Oct 2015 (!).
Note that we don't have a test that covers the above comment. What I usually would do is, remove that comment, fix the code, and wait for real, actionable bug reports. Life goes on. (Since this is related to config-phase the new fixes would go into configure.html not into accessors.html.)
That said I was able to produce a test case by thought experiments that leads to said divergence of the passed value. But I had to write a nonsensical tree of custom elements. The final outcome/value that survived the side-effects run was unexpected, and flaky b/c it relied completely on the kind and thus order of effects. So even though I saw a divergence between the passed and the current value, the divergence is not the problem here, the problem is what is the correct value the program should use, the user intends to survive. My perspective here is that it seems undecidable. (I wrote this first pencil-paper, and promptly expected the passed value would survive.)


Error when installing podfile

[!] Unable to satisfy the following requirements:

TwilioVoice (~> 2.0.0) required by Podfile

Specs satisfying the TwilioVoice (~> 2.0.0) dependency were found, but they required a higher minimum deployment target.

Fixed this error


Merged Order and OrderAggregate to create an Aggregate that persisted with both Eventuate and JPA

Added Dockerfile/docker-compose.yml to enable order-service to run as Docker container
Added mysql-cli.sh for viewing database
Misc cleanups

lgtm


Fix bunch of issues with reference related tests

Properly resolve function arguments vs global variables
Treat reassignments as reference, not as definition
Improve CancelAnalysis test (took forever with my 6500 files library)
Fix some dispose issues (queue was not always empty after dispose/cancel)
Dispose of stuff in order
Update signature test to new behavior
Update reference tests to new behavior

Do you want the last change to be part of the same review?

Yes. It actually fixes FindReferences and makes it work as PyCharm does. Also adds test for class local variables.

Ok, I'll take a look tomorrow morning.


[HUDI-113]: Use Tuple2 over # delimited string

@vinothchandar
As outlined in HUDI-113, I've updated the bloom index to use a Tuple2 rather than "#" as the separator.

Caused by: org.apache.spark.SparkException:
Job aborted due to stage failure: Task 1 in stage 40.0 failed 1 times, most recent failure: Lost task 1.0 in stage 40.0 (TID 56, localhost, executor driver): java.lang.ClassCastException: scala.Tuple2 cannot be cast to java.lang.String
	at com.uber.hoodie.index.bloom.BucketizedBloomCheckPartitioner.getPartition(BucketizedBloomCheckPartitioner.java:142)
	at org.apache.spark.shuffle.sort.BypassMergeSortShuffleWriter.write(BypassMergeSortShuffleWriter.java:152)
	at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:96)
	at org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:53)

See some errors due to casting mismatch..
High level question... I see that sorting a List already provides records ordering by the first and second level (in that order). So, can we just go back to Tuple2<String, HoodieKey> or if we have to use a custom comparator, can it just work off that?

Essentially, I saying the following should be sufficient information?
new Tuple2<>(matchingFile,  new HoodieKey(recordKey, partitionPath));

This will also reduce shuffled data.. a nice bonus..

Apologies for the number of rebases. At this point, I think this is good. Settled on using Pair<String, String> and updated the partitioner accordingly.


utils: Add case conversion procedural macro to convert identifier to string literal

This PR add a proceedural cacro to convert camel case identifer to kebba case string literal. close #11189
Signed-off-by: yuqi1129<EMAIL_ADDRESS>
What problem does this PR solve?
Issue Number: close #11189
Problem Summary:
Add a procedural macros to convert camel case identifier to kebba case string literal
What is changed and how it works?
Proposal: xxx
What's Changed:
Related changes

PR to update pingcap/docs/pingcap/docs-cn:
PR to update pingcap/tidb-ansible:
Need to cherry-pick to the release branch

Check List
Tests

Unit test

Side effects
Release note
 None

Thanks for the contribution! This is an interesting PR. Could you also supply some information about its use cases in the TiKV code base?

Thanks for the contribution! This is an interesting PR. Could you also supply some information about its use cases in the TiKV code base?

@breeswish
I'm not sure whether the issue #11189 has show the aim of this PR clearly, but you can read this to get some information about it, If there still some problem, please do not hesitate to leave a message here, thanks.

Seems that CI is not stable...

/merge


Resolve syncing conflicts from repo_sync_working_branch to master

Pull request opened by Docs to resolve syncing conflicts from repo_sync_working_branch to master.

@EdPrice-MSFT - Hi, could you resolve the merge conflicts? They seem to be the same ones we've seen in this type of repo sync PR the past two days . . . I'm not sure what's happening, but I wonder if the repo sync PRs are being successfully merged. You might check with the Pub Desk (@MicrosoftDocs/pubdesk) to ensure that the repos are being synced as scheduled, that syncing is current. Thank you!

@SyntaxC4 It looks like the last repo sync PR from three days ago is stalled in the private repo: https://github.com/MicrosoftDocs/architecture-center-pr/pull/3409
I think that might need to be fixed and merged for public/private syncing to become current and we won't see the same merge conflicts on the public side each day. Could you help out? Thanks very much.

The sync issue is resolved, it looks like. We'll merge this PR to resolve merge conflicts.


Choose which ability defense to roll against and/or set DC

I was simulating a combat and noticed that it would be really helpful if on the combat card we get when we use a power (example Dazzle) When I select a target and then make my attack with the power that I could select against witch defense stat I'm fighting. In the case of Dazzle it would be against Vigilance defense of the target. That way we could apply the damage automatically in the chat.

From user @fougerec in issue #21:

Detecting the appropriate defense so automating if it was a success or not. Even a field where a DC could be inputted for a non-combat roll would be nice.

This should be addressed in the most recent update. You should be able to update from within foundry but if it doesnt seem to be working, always just uninstall and reinstall


[IR] Handle equiJoin and cross

The main thing here is the first commit, which takes care of equiJoin and cross, and changes BaseCodegenTest to use comprehension combination instead of just desugaring.

@ggevay You can also cherry-pick this commit if you want to try the overloaded symbol resolution.

Thanks for the reviews. I've addressed all the comments.

@ggevay I think you might sqush the SQUASH commits now, then we can merge through the GUI once @joroKr21 says OK.

OK, I squashed.

I'll rebase #253 on top of HEAD, so it can be merged automatically as well.


Remove dependency on Dropwizard Auth

Description
Relates to #41

Release notes
(x) This is not user-visible or is docs only, and no release notes are required.

Have you tested this change against an OAuth2 server? I'm not overly confident in the mock tests.

I didn't. Overall I don't feel we have enough tests to cover the auth part. That's why I'm holding this PR as a draft.
I planned to add some tests in a separate PR to ensure the auth doesn't break during migration.
In particular I'd like to test /findQueryHistory and /userinfo endpoint, LDAP authentication and authorization, and OAuth2.

Test on /userinfo added in #321.
Done a manual test on LDAP and OAuth2.
Not sure how to automate the test / mock the required components.

Found some security issues in the current OIDC implementation while I was adding the test using Hydra.
#344 #345 should fix the issues.

Lets chat about all this in the sync tomorrow. I think we should add them all in.


Error: Could not find or load main class edp.davinci.DavinciStarter

Error: Could not find or load main class edp.davinci.DavinciStarter
How to fix it?

Could you provide the full stacktrace ?   On windows or linux

I have solve it, I download the release package.


Add Declarations/providers automatically

It'd be great (if possible) to have yo ng2component add the import and declaration or provider to the app.module.ts file. The Angular Cli does this. If you had this, I wouldn't miss anything from the cli (when I'm using the JavaScriptServices template or Asp .Net).

Yes, I've been thinking this for long time and made some progress already. But since I'm busy in company developing recently, this improvement may take a while. I'll let u know once it's done

No hurry, I understand being busy. I was surprised how quickly you were able to get to my last suggestion. Good luck!

Hi, Kevin, the ability to auto declaring component in app.module now is available in v1.1.0, pls try it and share any feedbacks.
But the ability to add provider is not considered right now cuz I think it's better to let user to make the decision where to put service. Impudently adding provider to somewhere silently will cause some unexpected scope problem. (CLI doesn't auto add provider neither 😃 )
In addition, I'm planing to add the ability to create module/pipe/directive... in short future. Thanks!

looks like it is assuming src in the directory structure:
ex:
c:\git\ng2\myApp\ClientApp\app\app.module.ts
c:\git\ng2\myApp\ClientApp\app\components\
I'm getting Error: ENOENT: no such file or directory, open 'C:\git\ng2\myApp\ClientApp\src\app\app.module.ts'

bug fixed in v1.1.1, now it assuming your component is in the same folder of your module. Do u think is it better to let user to specify where is his xx.module.ts?

yes, I think you should ask the user.
it could default to the current directory. the JavaScriptServices template puts it in c:\git\ng2\myApp\ClientApp\app\app.module.ts

Sorry for late updating, the custom module position is done. You can take a look now ~

It is working! Thanks a lot.
One last suggestion is to put the import at the bottom of the list of imports in app.module. Instead of the top line. However, I won't complain about having to move that down a few rows, once in awhile.
Thanks again!!


Custom Range Slider

Is your feature request related to a problem? Please describe.
Add Custom Range Slider
I would like to work under DCP'21 and I request you to assign me this project.

hey @Ayush7614 please assign it to me


[WIP] Win32 paste (+pasting when bracketed paste is disabled.)

This branch should fix the situation when pasting multiple lines results in bad handling of the line endings.
TODO:

handle win32_asyncio event loop
handle posix + posix_asyncio event loops.

Breaking (internal) change: CommandLineInterface._InterfaceEventLoopCallbacks.feed_key() can raise ComandLineInterfaceIsDoneError when trying to feed keys.

thanks, will test in 2 hours

For me, I just noticed that this doesn't solve the indentation issue yet.
For ptpython, people can press F6 and then it enables paste mode, which disables both auto-ident and accept-on-enter.
Maybe for Windows, we can also use PeekConsoleInputW and if we see that the pending input contains either more than 16 characters, or contains a newline (for instance) consider it a bracketed paste.
(going to try this tomorrow.)

the multi-line copy/paste works \o/

Hi @stonebig,
Can you test again with the following branch instead?
https://github.com/jonathanslenders/python-prompt-toolkit/pull/319
This emulates bracketed paste on Windows. It means that if text is pasted on Windows, no additional indentation will be added, and all input is kept in one input field.

done. so far so good, now going to test the other ptipython fix

Thanks for testing. Closing this branch in favor of: https://github.com/jonathanslenders/python-prompt-toolkit/pull/319


[BUG]: Document Types master data to be filled in properly and used across the application.

Refer to document type master here

closing in favour of #2268


SMA-316: Remove dependence on via-ir for compilation

Summary
While we'll still use via-ir while deploying contracts, having contracts that do not require via-ir to be compiled enables the coverage-tracking plugins to work properly.
I've made very simple modifications that should in theory not affect the gas consumed by these contracts. But still to be on the safe side, what would be the best way to measure gas (before and after) for the updated modules? @filmakarov
Change Type

[ ] Bug Fix
[x] Refactor
[ ] New Feature
[ ] Breaking Change
[ ] Documentation Update
[ ] Performance Improvement
[x] Other

Checklist

[x] My code follows this project's style guidelines
[x] I've reviewed my own code
[x] I've added comments for any hard-to-understand areas
[x] I've updated the documentation if necessary
[x] My changes generate no new warnings
[x] I've added tests that prove my fix is effective or my feature works
[x] All unit tests pass locally with my changes
[x] Any dependent changes have been merged and published

@livingrockrises we should still keep via-ir enabled for deploying contracts to production, these changes are just to make sure when coverage is run (which cannot use via-ir) the contracts still compile.

@filmakarov it would be great to get your review as well, since you're the primary author of these modules.


PBI service dataset/datamart - TOPNSKIP is not supported in direct query mode

Describe the problem
Trying to set a date range generation on auto generated dataset in PBI service from datamart
ERROR 800: exception occured , TOPNSKIP is not supported in direct query mode
Bravo version
0.9.6 (0.9.8291.23631)
Tabular model
Power BI Dataset
Power BI
Power BI desktop Version: 2.108.997.0 64-bit (August 2022)
Steps to reproduce the behavior
No response
Additional context
No response
Screenshots
No response
Anything else ?
No response

Hi @databasedave, thanks for reporting this error!
Unfortunately, I am not able to get this error. Could you share here the steps to reproduce the behavior? Did you connect to the dataset by running Bravo as an external tool from PowerBI Desktop or did you select the dataset from the "Connect to Power BI Service" panel in Bravo ?
Link to #425 for internal reference only.

Hi @databasedave! Does the issue still exist today with the current version of Datamart?
If the problem still persists, could you provide the steps to reproduce?