IOSTAT variable needs initializing

In share/ioModule.f90 Subroutine read_snow17_parameters(), the IOSTAT variable ios is non-zero upon subsequent  calls to this subroutine.
Current behavior
When running multiple catchments, variable ios is set to zero by a compile time setting. However, in subsequent calls to Subroutine read_snow17_parameters() this variable has a non-zero value.
Resolution
Explicitly set ios = 0 after variable declarations

ios is initialized in the variable declarations on each call to the subroutine, then is only assigned by the read statements and checked for each readline to see if one has failed (ie non-zero return value).  are you sure this doesn't work?
ln 27:  integer    	            :: ios=0

@andywood the ios assignment works for the initial invocation of read_snow17_parameters() but not successive calls. For example, adding a print statement before the input file is read has ios=-1 during the 2nd invocation:
% ./cmake_build/ngen data/catchment_data.geojson all data/nexus_data.geojson nex-26 data/example_bmi_multi_realization_config_w_snow17.json NGen Framework 0.1.0 Building Nexus collection Building Catchment collection Initializing formulations [   {           name :    bmi_c++,           params :         {                allow_exceed_end_time :            true,                init_config :       /dev/null,                library_file : ./extern/sloth/cmake_build/libslothmodel.so,                main_output_variable :               z,                model_params :              {                     sloth_ice_fraction_schaake(1,double,m,node) :                    0,                     sloth_ice_fraction_xinanjiang(1,double,1,node) :                    0,                     sloth_smp(1,double,1,node) :                    0,               },                model_type_name :   bmi_c++_sloth,                uses_forcing_file :           false,          },     },    {           name : bmi_fortran,           params :         {                allow_exceed_end_time :            true,                forcing_file :                ,                init_config : ./data/bmi/fortran/snow17-init-{{id}}.namelist.input,                library_file : ./extern/snow17/cmake_build/libsnow17bmi,                main_output_variable :            raim,                model_type_name : bmi_fortran_snow17,                uses_forcing_file :           false,                variables_names_map :              {                     precip : atmosphere_water__liquid_equivalent_precipitation_rate,                     tair : land_surface_air__temperature,               },          },     },    {           name :      bmi_c,           params :         {                allow_exceed_end_time :            true,                forcing_file :                ,                init_config : ./data/bmi/c/pet/{{id}}_bmi_config.ini,                library_file : ./extern/evapotranspiration/cmake_build/libpetbmi,                main_output_variable : water_potential_evaporation_flux,                model_type_name :       bmi_c_pet,                registration_function : register_bmi_pet,                uses_forcing_file :           false,                variables_names_map :              {                     water_potential_evaporation_flux : potential_evapotranspiration,               },          },     },    {           name :      bmi_c,           params :         {                allow_exceed_end_time :            true,                forcing_file :                ,                init_config : ./data/bmi/c/cfe/{{id}}_bmi_config.ini,                library_file : ./extern/cfe/cmake_build/libcfebmi,                main_output_variable :           Q_OUT,                model_type_name :       bmi_c_cfe,                registration_function : register_bmi_cfe,                uses_forcing_file :           false,                variables_names_map :              {                     atmosphere_air_water~vapor__relative_saturation :   SPFH_2maboveground,                     ice_fraction_schaake : sloth_ice_fraction_schaake,                     ice_fraction_xinanjiang : sloth_ice_fraction_xinanjiang,                     land_surface_air__pressure :         PRES_surface,                     land_surface_air__temperature :    TMP_2maboveground,                     land_surface_radiation~incoming~longwave__energy_flux :        DLWRF_surface,                     land_surface_radiation~incoming~shortwave__energy_flux :        DSWRF_surface,                     land_surface_wind__x_component_of_velocity :  UGRD_10maboveground,                     land_surface_wind__y_component_of_velocity :  VGRD_10maboveground,                     soil_moisture_profile :            sloth_smp,                     water_potential_evaporation_flux : potential_evapotranspiration,               },          },     },  ]  SUBROUTINE initialize_from_file  Calling readNamelist()  Reading namelist   -- simulating basin cat-67               with            1  snowbands  Calling initInfo()  Calling initForcing()  Calling initModelVar()  Calling initParams()  Calling read_snow17_parameters()  Opening parameter file: extern/snow17/test_cases/ex1/input/params/snow17_params.HHWM7.txt                                                                                Reading Snow17 parameters
ios:            0
  hru_id HHWM8IL HHWM8IU    hru_area 2994.7 1271.3    latitude 47.78 47.78    elev 1612.50 2153.35    scf 2.15177 1.86124    mfmax 0.930472 0.754924    mfmin 0.137 0.160    uadj 0.003103 0.208042    si 1515.00 1515.00    pxtemp 0.713424 0.220934    nmf 0.150 0.150    tipm 0.200 0.050    mbase 0.000 0.000    plwhc 0.030 0.030    daygm 0.300 0.200    adc1 0.050 0.050    adc2 0.090 0.090    adc3 0.160 0.160    adc4 0.310 0.310    adc5 0.540 0.540    adc6 0.740 0.740    adc7 0.840 0.840    adc8 0.890 0.890    adc9 0.930 0.930    adc10 0.970 0.970    adc11 1.000 1.000 Config file details - Line Count: 22 | Max Line Length 40 Config Value - Param: 'forcing_file' | Value: 'BMI' | Units: '(null)' Config Value - Param: 'verbosity' | Value: '0' | Units: '(null)' Config Value - Param: 'surface_partitioning_scheme' | Value: 'Schaake' | Units: '(null)' Config Value - Param: 'soil_params.depth' | Value: '2.0' | Units: '(null)' WARNING: [units] expected for 'soil_params.depth' in config file  Config Value - Param: 'soil_params.b' | Value: '4.05' | Units: '(null)' Config Value - Param: 'soil_params.mult' | Value: '1000.0' | Units: '(null)' Config Value - Param: 'soil_params.satdk' | Value: '0.00000338' | Units: '(null)' WARNING: [units] expected for 'soil_params.satdk' in config file  Config Value - Param: 'soil_params.satpsi' | Value: '0.355' | Units: '(null)' WARNING: [units] expected for 'soil_params.satpsi' in config file  Config Value - Param: 'soil_params.slop' | Value: '1.0' | Units: '(null)' WARNING: [units] expected for 'soil_params.slop' in config file  Config Value - Param: 'soil_params.smcmax' | Value: '0.439' | Units: '(null)' WARNING: [units] expected for 'soil_params.smcmax' in config file  Config Value - Param: 'soil_params.wltsmc' | Value: '0.066' | Units: '(null)' WARNING: [units] expected for 'soil_params.wltsmc' in config file  Config Value - Param: 'max_gw_storage' | Value: '16.0' | Units: '(null)' WARNING: [units] expected for 'max_gw_storage' in config file  Config Value - Param: 'Cgw' | Value: '0.01' | Units: '(null)' WARNING: [units] expected for 'Cgw' in config file  Config Value - Param: 'expon' | Value: '6.0' | Units: '(null)' Config Value - Param: 'gw_storage' | Value: '50%' | Units: '(null)' WARNING: [units] expected for 'gw_storage' in config file  Config Value - Param: 'alpha_fc' | Value: '0.33' | Units: '(null)' Config Value - Param: 'soil_storage' | Value: '66.7%' | Units: '(null)' WARNING: [units] expected for 'soil_storage' in config file  Config Value - Param: 'K_lf' | Value: '0.01' | Units: '(null)' Config Value - Param: 'K_nash' | Value: '0.03' | Units: '(null)' Config Value - Param: 'nash_storage' | Value: '0.0,0.0' | Units: '(null)' Config Value - Param: 'giuh_ordinates' | Value: '0.06,0.51,0.28,0.12,0.03' | Units: '(null)' Found configured GIUH ordinate values ('0.06,0.51,0.28,0.12,0.03') Config Value - Param: 'num_timesteps' | Value: '720' | Units: '(null)' Config param 'soil_params.expon' not found in config file, defaulting to 1 (linear) Config param 'soil_params.expon_secondary' not found in config file, defaulting to 1 (linear) Schaake Magic Constant calculated All CFE config params present GIUH ordinates string value found in config ('0.06,0.51,0.28,0.12,0.03') Counted number of GIUH ordinates (5) Finished function parsing CFE config At declaration of smc_profile size, soil_reservoir.n_soil_layers = 0  SUBROUTINE initialize_from_file  Calling readNamelist()  Reading namelist   -- simulating basin cat-27               with            1  snowbands  Calling initInfo()  Calling initForcing()  Calling initModelVar()  Calling initParams()  Calling read_snow17_parameters()  Opening parameter file: extern/snow17/test_cases/ex1/input/params/snow17_params.HHWM8.txt                                                                                Reading Snow17 parameters
ios:           -1
Read            0  SNOW17 params, but need 26.  Quitting.

Yes, assignment at declaration is usually a no-no in Fortran. A simple change to the following should suffice.
integer :: ios
ios = 0

@drakest123 do you see assignment at declaration anywhere else in the code?
Additionally, can someone explain line 41 to me:
    do while(ios .eq. 0)
      read(unit=51,FMT='(A)',IOSTAT=ios) readline

      if(ios == 0) then

If the do loop only runs when ios == 0, what purpose does the if(ios == 0) then serve?

I think the practice of assigning simple vars at declaration is not uncommon - maybe grew out of card reader days when you could save a line by doing so.  after googling it, I do see it's frowned upon.  we can add revising these assignments where we find them to the code cleanup list if it's not already there.
I think the logic you mention is a clunky way to exit the case loop when you hit the end of the file (or some other error) -- ie the last attempt to read a line fails, no cases are triggered, and you don't go through it again.  perhaps otherwise you need a break statement.  I agree there are other ways you could set this up.

btw -- that is in other subroutines as well, even in that same module (and it's scattered through SUMMA, fwiw; also in some of the orig noah-mp code)

Thanks for the heads-up. I'll look for other instances of this issue. After that, it would be good to compare the output with a previous version. FYI, I'm using gfortran on a Mac M1:
% gfortran -v  Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/13.2.0/bin/../libexec/gcc/aarch64-apple-darwin23/13/lto-wrapper Target: aarch64-apple-darwin23 Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-13 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 13.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --with-system-zlib --build=aarch64-apple-darwin23 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 (Homebrew GCC 13.2.0)
A quick test verifies the behavior that we are seeing:
% cat main.f90
      program TEST1

      call test()
      call test()

      end

% cat test.f90
      SUBROUTINE test()

      integer ::  ios = 0

      print*,'ios: ', ios

      ios = -1

      return
      end subroutine test

% ./a.out
 ios:            0
 ios:           -1

@drakest123 just a +1 that I have also noticed a similar issue in our Clear Creek modeling, where the initialization is fine for the first catchment, but not subsequent ones, e.g.:
(base) [hydrofcst@wendian001 snow17_test]$ /beegfs/projects/hydrofcst/SHARP/models/ngen/cmake_build/ngen clear_ck.v201.catchment_data.geojson all clear_ck.v201.nexus_data.geojson all realization_file.06719505.snow17_only.2020_2022.json NGen Framework 0.1.0 Building Nexus collection Building Catchment collection  Reading namelist   -- simulating basin wb-1561662           with            1  snowbands  Reading Snow17 parameters  Reading namelist   -- simulating basin wb-1561693           with            1  snowbands  Reading Snow17 parameters  Read            0  SNOW17 params, but need 26.  Quitting.

An inventory of INTEGER, REAL and CHARACTER definitions for the NGEN version of the snow17 codebase indicates that, for variables that are not parameters, initialization during declaration occurs only in two files in the share/ directory:
dateTimeUtilsModule.f90:    integer :: y = 4716, j = 1401, m = 2, n = 12, r = 4, p = 1461
dateTimeUtilsModule.f90:    integer :: v = 3, u = 5, s = 153, w = 2, b = 274277, c = - 38
ioModule.f90:    integer                    :: ios=0   ! specify i4b with nrtype?
ioModule.f90:    integer        :: ierr=0   ! error code returned by open(iostat = ierr)
ioModule.f90:    integer                                                     :: nh, ierr=0
ioModule.f90:    integer                      :: ios = 0

digging some more, in 'modern' fortran (post F90) the
integer           :: ierr=0
equates to
integer,save  :: ierr=0
which means its first initialization is subsequent ones are not.  definitely worth going through to upgrade these statements.  It's possible a compiler flag like -std=legacy would avoid that, but easy enough to make the change.  there's probably no harm in using this for constants (e.g., real :: g=9.80665) but not for variables that will change.

In the example test.f90 above I tried:
integer,save :: ierr=0
but the result remains:
 ios:            0
 ios:           -1

sorry, I probably wasn't clear -- that's the default behavior if you leave out ',save' -- (which is causing the problem).
ok to update the codes and close this issue, now that we understand it?

Keith's suggested change fixed it for me, i.e., changing line 27 to:
integer :: ios
and then adding the assignment below the local variables:
ios = 0


3D run by using NEMO output

Hello everyone, I have a question on the 3D module.
We are trying to use 3D velocity fields from a NEMO model. The model uses the z-level coordinate system with bottom partial steps and nonlinear free surface is implemented using the variable volume level (VVL) scheme, which allows the stretching and compression of the thickness of vertical layers according to the changes of sea surface height. How should we use such model output with OceanParcels 3D module?
We noticed NEMO w is the velocities relative to the grid and ignores the movement of the levels, e.g., w at the free surface is always zero. Do we need to bring in the time dependent depth and add the movement of the levels to the w variable? Or does OceanParcels expect velocities relative to the moving grid?
Could you please give us some suggestions and examples on how to deal with the w output from NEMO with a time and space dependent vertical coordinate? The tutorial on the moving grid only includes u and v velocities. Thanks!

Hi @Novaoceans, thanks for your question and sorry for the delay in responding. It's summer here ;-)
As for the surface layer: I am not aware of anyone who has already used the NEMO-VVL scheme in Parcels. While support for time-varying depth layers is implemented (see https://docs.oceanparcels.org/en/latest/examples/tutorial_timevaryingdepthdimensions.html), so far we haven't used it. You could give it a try?
As for the bottom layer: we have discussed bottom partial steps with @cpierard before, and came up with an idea how to deal with it, but haven't implemented or tested it yet. It will require writing a custom kernel for the advection, and having an extra Field that gives the partial cell for each horizontal grid cell (which is likely already in the mesh file?)


Prevent a second lookup of user for image volumes

Instead of forcing another user lookup when mounting image volumes, just use the information we looked up when we started generating the spec.
This may resolve #1817

/approve
LGTM

LGTM but I am not sure it fixes #1817 as it seems like a race-condition that might blow up somewhere else once this PR gets merged.

The good news is there are seemingly only two places we need to read /etc/passwd in the run path, and this is the second of the two... Everything else reading passwd should be strictly optional

Looks like access.redhat.com is having issues, hence our flake

bot, retest this please

One nit, otherwise LGTM.  F28 Cloud is unhappy yet again.

LGTM

fix tom's comment and ill merge

Fixed

bot, retest this please

/lgtm

Can we get a comment on https://bugs.launchpad.net/tripleo/+bug/1803544 when this fix is released and available for consumption on by tripleo jobs?


Do not call watchConfig() when not in watch mode

See #1772

@spf13, does this look okay to you?  :-)

(Note to self: Next time, test before pushing a commit for the first time.  :wink:)
Finally got my PR to work as expected.  My initial push erroneously used viper.GetBool("watch") which was never set and thus simply disabled watchConfig() indiscriminately... Oops!
I then discovered that the config watch only worked the first time when I do echo "" >> docs/config.toml, and then it got stuck, hence I added one more line to fix the problem.  From the commit log:

Also, force DisableLiveReload to true when running "hugo --watch" (build-only non-server mode) to prevent livereload.ForceRefresh(), which would end up blocking watchConfig() forever, from being called because livereload.Initialize() is never called in this case.
This fixes the bug where "hugo --watch" could only reload config.toml once before it gets stuck for good at livereload.ForceRefresh().
This is also consistent with Hugo's existing behaviour: Non-server "hugo --watch" has never injected livereload.js since the inception of the "watch" feature in Hugo v0.12.

This looks great. You've fixed two bugs in one commit. Merged as e8eb618


Handle (white)space in command mode autocompletion

Autocompletition in command mode doesn't handle etries with spaces correctly.

When dropping a filesystem based suggestion (in favour of another one: ie, choosing another) for command (e, chdir) parameters, only the last word (or Word?) gets deleted.

The command mode's state machine should delete the currently selected completition entry when a discard transition occours.

When selecting an entry with spaces, it doesn't get escaped (like it did in Oni), and argument will be invalid for the command - for example chdir fails to folders with spaces in them (on Windows at least)

The wrong insertion is probably caused by the fact that we determine the position at which to insert the autocompletion by going backwards through the entered string and looking for the first space we find. See https://github.com/onivim/oni2/blob/3fb7276cdef066316caaf08ab7822c5f9a719567/src/editor/Core/Utility.re#L112
(bryphe provided me with this insight :) )
I'm not sure if this is the logic we want - are there commands that include multiple spaces which are not part of a path? Otherwise we might be able to just take the first space instead?
FWIW, original vim keeps track of the autocomplete starting point itself and doesn't retroactively calculate it. It might be necessary that we do the same, see xp->xp_pattern in https://github.com/onivim/libvim/blob/07e5aa155c887b8efbe023544c26f680a221abf1/src/ex_getln.c#L5556

About the missing escaping: We seem to use vimCommandLineGetCompletions from libvim, which in turn directly hooks into expand_cmdline. The native vim flow has a lot of complexity around it which also makes sure that things like ~ are retained correctly in the suggestions, unnecessary prefixes are left out and other variables are expanded. This is more understandable by comparing screenshots:
Native vim

Oni2

Some of these things seem to happen inside showmatches after expand_cmdline in the native flow - I think we might need to add these steps in a similar form to our vimCommandLineGetCompletions to get the same behavior. I'm unsure which parts exactly though since I can't quite figure out where exactly the escaping etc. happens. Will need some more investigations and drawing things up to figure this out.

I'm not sure if this is the logic we want - are there commands that include multiple spaces which are not part of a path? Otherwise we might be able to just take the first space instead?
FWIW, original vim keeps track of the autocomplete starting point itself and doesn't retroactively calculate it. It might be necessary that we do the same

I thought almost this when I said "The command mode's state machine should delete the currently selected completition entry when a discard transition occours."
I meant to say (quite clumsily), that if you keep track of the currently selected autocompletion entry you can remove it accurately too. But the reason behind it was sane - do NOT try to calculate (guess) the point after-the-fact, but store some information when choosing an entry.
Quite possibly choosing the vim approach (store the starting point) is better, as not un
I thought about implementing this, as this seemed a possibly good first issue but: I do not know Reason.
Maybe if you think the first part can be solved as a stand alone issue, I'll give it a shot.

Issues 1) and 2) called out at the root issue should be fixed with #2005
However, the escaping didn't seem necessary in my testing - let me know if you have case that is failing w/ the latest that I can try.

On first skimming, it seems fine!
I plan to spend some more time with oni2 in the weekend though, so I'll report if I've found some missed parts!

Great news! Thank you @Samonitari

Unfortunately there is still a quirk.
Issue 1) is fixed,
Issue 2) is half okay - on linux I won't get autocompiletion of the contents, if I select a folder with whitespaces in its name.
On Windows this doesn't seem to happen

I just checked this after reporting #3751, and this has been fixed since some time ago.
Original sub-issue 2) is gone on linux also.


Add in new assets

[x] dirt path
[x] poops
[x] main menu
[ ] preloader
[x] settings
[x] spell activation screen
[x] level select
[x] game screen (spell bottle and points)
[x] pause menu
[x] end game win/lose
[x] latrine spell steps

Sprite sheets:

[x] various villagers
[x] snakes
[x] scorpions

@esalling23 when you have a chance, can you check off what is done so far?

@johnnycrich all of the assets are in the sprites folders except for the preloader loading bar


Resolved the docker CI Workflow section from referenced snippet

Resolves Issue #357 from meshery repo

Nice work, @GenericStudent!


Error about collect.py file

Dear professor,
Sorry for bothering.
When I run the collect.py file. I got this error,
AttributeError: 'pyscipopt.scip.Model' object has no attribute 'getNNodesLeft'
This is my 'paths' setting
paths = {
    'MYSYSTEM': {
       'out_dir': 'new_dataset',
       'instances_dir': 'branch-search-trees-dataset/train_instances/',
       'cutoff_dict': 'branch-search-trees-dataset/cutoff_dict.pkl',
    },
}
This is my run command
python collect.py -n air05.mps.gz \
                  -s 0 \
                  -k 10 \
                  --setting sandbox \
                  --system MYSYSTEM \
                  -v
The version of PySCIPOpt is 1.4.9, which is the same as in requirements.txt and I checked the functions inside the model through the dir(model) method, and did not find functions such as getNNodesLeft, getCandsState, getNodeState, and getMIPState.
Could you help me? How do you think about this error? Thank you very much, professor.
Sincerely.

It's not a bother at all.
I suspect you are using the default version of PySCIPOPT, but like we note here in our readme https://github.com/ds4dm/branch-search-trees#installation-and-dependencies, you have to install our customized version of PySCIPOPT. We coded up our own customized version that has all the corresponding data collection methods that you mentioned. Please refer to the above link in our readme for installation instructions.
Can you verify that you are getting this error with our custom version of PySCIPOPT?

Thank you very much for your help, my problem has been solved.
Sincerely.


Navigation bar background color

Is there a way to change the background color for the navigation bar generated by _meta.json?

nope, there is no way of configuring the background color, only manually with CSS


Feature to get target refresh rate

Is your feature request related to a problem? Please describe.
Hi, I'm developing an emulator that uses egui for its front end. I'm currently experiencing an issue where I need to synchronise emulation with when egui repaints the screen. Currently, I'm utilizing the request_repaint function, but it's proving quite a struggle to work without knowing the framerate this function is targeting.
Describe the solution you'd like
A way to know the refresh rate/frame rate egui/eframe targets when using request_repaint (or even without it, say if the user was just moving their cursor around or doing something that would require a repaint)
Describe alternatives you've considered
I've tried implementing a similar method as showcased egui.rs, where on the backend tab, if you set the Mode to Continuous, it will calculate the FPS. However, this value is not entirely accurate because if the window loses focus (either via minimizing or switching tabs), it stops painting and ruins the average time between each frame.
Additional context

Try calling request_repaint() every time in update().
And try to solve other problem.
(Repaint does not work in the minimized state. - There seems to be no reason to measure invisible FPS.)

Try calling request_repaint() every time in update()
That's what I've been doing, and as you say, it does not work in the minimized state. Because of this, it's impossible to use the time between frames to calculate the FPS (as done in the demo), and as far as I can see, there's also no way to see if repainting has been paused, so I believe a feature that simply allows developers to get the refresh rate egui is targeting would be beneficial.

Try calling request_repaint() every time in update()

That's what I've been doing, and as you say, it does not work in the minimized state. Because of this, it's impossible to use the time between frames to calculate the FPS (as done in the demo), and as far as I can see, there's also no way to see if repainting has been paused, so I believe a feature that simply allows developers to get the refresh rate egui is targeting would be beneficial.

See FPS handling in egui_demo_app.
There is also a way to handle this by checking the ‘minimized’ status.

See FPS handling in egui_demo_app.

As I said, the demo has the same problem. The way FPS handling is done in the demo has this flaw.
Additionally, the minimized status does not work in WASM and, therefore, cannot be used to solve my problem.


init_tensor survives until VerifyLoweringToTensorsPass

Describe the bug
VerifyLoweringToTensorsPass diagnoses a linalg.init_tensor that should not be there
https://gist.github.com/silvasean/c5afa1a66af773f8ff590406a74907ca
To Reproduce
iree-compile --iree-hal-target-backends=dylib-llvm-aot core-input.mlir

#map0 = affine_map<(d0, d1, d2) -> (d0, d1, d2)>
#map1 = affine_map<(d0, d1, d2) -> (0, d1, 0)>
module attributes {torch.debug_module_name = "NativeBatchNorm1DModule"} {
  func @forward(%arg0: tensor<?x?x?xf32>, %arg1: tensor<?xf32>, %arg2: tensor<?xf32>, %arg3: tensor<?xf32>, %arg4: tensor<?xf32>) -> (tensor<?x?x?xf32>, tensor<0xf32>, tensor<0xf32>) {
    %c1 = arith.constant 1 : index
    %c2 = arith.constant 2 : index
    %c0 = arith.constant 0 : index
    %c0_i64 = arith.constant 0 : i64
    %c3_i64 = arith.constant 3 : i64
    %c1_i64 = arith.constant 1 : i64
    %cst = arith.constant 1.000000e-05 : f64
    %0 = arith.addi %c1_i64, %c3_i64 : i64
    %1 = arith.cmpi sge, %c1_i64, %c0_i64 : i64
    %2 = arith.select %1, %c1_i64, %0 : i64
    %3 = arith.cmpi sge, %2, %c0_i64 : i64
    cf.assert %3, "dim must be greater or equal to zero"
    %4 = arith.cmpi slt, %2, %c3_i64 : i64
    cf.assert %4, "dim must be smaller than inputRank"
    %5 = tensor.expand_shape %arg3 [[0, 1, 2]] : tensor<?xf32> into tensor<1x?x1xf32>
    %6 = tensor.expand_shape %arg4 [[0, 1, 2]] : tensor<?xf32> into tensor<1x?x1xf32>
    %7 = tensor.dim %arg0, %c0 : tensor<?x?x?xf32>
    %8 = tensor.dim %arg0, %c1 : tensor<?x?x?xf32>
    %9 = tensor.dim %arg0, %c2 : tensor<?x?x?xf32>
    %10 = tensor.dim %arg3, %c0 : tensor<?xf32>
    %11 = arith.cmpi eq, %8, %10 : index
    cf.assert %11, "mismatched size for broadcast"
    %12 = linalg.init_tensor [%7, %8, %9] : tensor<?x?x?xf32>
    %13 = linalg.generic {indexing_maps = [#map0, #map1, #map0], iterator_types = ["parallel", "parallel", "parallel"]} ins(%arg0, %5 : tensor<?x?x?xf32>, tensor<1x?x1xf32>) outs(%12 : tensor<?x?x?xf32>) {
    ^bb0(%arg5: f32, %arg6: f32, %arg7: f32):
      %29 = arith.sitofp %c1_i64 : i64 to f32
      %30 = arith.mulf %arg6, %29 : f32
      %31 = arith.subf %arg5, %30 : f32
      linalg.yield %31 : f32
    } -> tensor<?x?x?xf32>
    %14 = tensor.dim %arg4, %c0 : tensor<?xf32>
    %15 = linalg.init_tensor [1, %14, 1] : tensor<1x?x1xf32>
    %16 = linalg.generic {indexing_maps = [#map1, #map0], iterator_types = ["parallel", "parallel", "parallel"]} ins(%6 : tensor<1x?x1xf32>) outs(%15 : tensor<1x?x1xf32>) {
    ^bb0(%arg5: f32, %arg6: f32):
      %29 = arith.truncf %cst : f64 to f32
      %30 = arith.sitofp %c1_i64 : i64 to f32
      %31 = arith.mulf %29, %30 : f32
      %32 = arith.addf %arg5, %31 : f32
      linalg.yield %32 : f32
    } -> tensor<1x?x1xf32>
    %17 = linalg.generic {indexing_maps = [#map1, #map0], iterator_types = ["parallel", "parallel", "parallel"]} ins(%16 : tensor<1x?x1xf32>) outs(%15 : tensor<1x?x1xf32>) {
    ^bb0(%arg5: f32, %arg6: f32):
      %29 = math.rsqrt %arg5 : f32
      linalg.yield %29 : f32
    } -> tensor<1x?x1xf32>
    %18 = arith.cmpi eq, %8, %14 : index
    cf.assert %18, "mismatched size for broadcast"
    %19 = linalg.generic {indexing_maps = [#map0, #map1, #map0], iterator_types = ["parallel", "parallel", "parallel"]} ins(%13, %17 : tensor<?x?x?xf32>, tensor<1x?x1xf32>) outs(%12 : tensor<?x?x?xf32>) {
    ^bb0(%arg5: f32, %arg6: f32, %arg7: f32):
      %29 = arith.mulf %arg5, %arg6 : f32
      linalg.yield %29 : f32
    } -> tensor<?x?x?xf32>
    %20 = tensor.expand_shape %arg1 [[0, 1, 2]] : tensor<?xf32> into tensor<1x?x1xf32>
    %21 = tensor.dim %arg1, %c0 : tensor<?xf32>
    %22 = arith.cmpi eq, %8, %21 : index
    cf.assert %22, "mismatched size for broadcast"
    %23 = linalg.generic {indexing_maps = [#map0, #map1, #map0], iterator_types = ["parallel", "parallel", "parallel"]} ins(%19, %20 : tensor<?x?x?xf32>, tensor<1x?x1xf32>) outs(%12 : tensor<?x?x?xf32>) {
    ^bb0(%arg5: f32, %arg6: f32, %arg7: f32):
      %29 = arith.mulf %arg5, %arg6 : f32
      linalg.yield %29 : f32
    } -> tensor<?x?x?xf32>
    %24 = tensor.expand_shape %arg2 [[0, 1, 2]] : tensor<?xf32> into tensor<1x?x1xf32>
    %25 = tensor.dim %arg2, %c0 : tensor<?xf32>
    %26 = arith.cmpi eq, %8, %25 : index
    cf.assert %26, "mismatched size for broadcast"
    %27 = linalg.generic {indexing_maps = [#map0, #map1, #map0], iterator_types = ["parallel", "parallel", "parallel"]} ins(%23, %24 : tensor<?x?x?xf32>, tensor<1x?x1xf32>) outs(%12 : tensor<?x?x?xf32>) {
    ^bb0(%arg5: f32, %arg6: f32, %arg7: f32):
      %29 = arith.sitofp %c1_i64 : i64 to f32
      %30 = arith.mulf %arg6, %29 : f32
      %31 = arith.addf %arg5, %30 : f32
      linalg.yield %31 : f32
    } -> tensor<?x?x?xf32>
    %28 = linalg.init_tensor [0] : tensor<0xf32>
    return %27, %28, %28 : tensor<?x?x?xf32>, tensor<0xf32>, tensor<0xf32>
  }
}

    %28 = linalg.init_tensor [0] : tensor<0xf32>
    return %27, %28, %28 : tensor<?x?x?xf32>, tensor<0xf32>, tensor<0xf32>

@MaheshRavishankar would know the real intent, but AFAIK this isn't an intended way of using init tensors. If this were an arith.constant instead it would be converted to a flow.tensor.empty and be handled ok I believe.

its again returning a tensor<0xf32> that is strange, also, returning an init_tensor this way is undefined behavior...

There is a batch norm op, and in inference mode it returns 0-size tensors:
>>> import torch
>>> t = torch.ops.aten.native_batch_norm(torch.rand(3, 4, 5), torch.rand(3, 4), torch.rand(3,  4), torch.rand(4), torch.rand(4), False, 0.001, 1e-6)
>>> print(t[0].shape, t[1].shape, t[2].shape)
torch.Size([3, 4, 5]) torch.Size([0]) torch.Size([0])

We decompose the last two return value into "torch.empty" which creates an uninitialized tensor, which then gets lowered to init_tensor. I know we've discussed in the past that init_tensor is one of multiple things -- how would you suggest that we lower the torch.empty op to linalg-on-tensors if not through init_tensor? https://pytorch.org/docs/stable/generated/torch.empty.html
In this specific case, since we know they are 0-size, it wouldn't harm to turn them into "zeros" instead of "empty", but generally patterns like torch.empty(sizes).uniform_(low, high) (or fill_ -- the trailing _ means "in place") are pretty common, and it seems like an arbitrary and (difficult to describe for users) restriction to say that "torch.empty cannot be returned from a function" (which might only happen through multiple levels of inlining and simplification).

torch.empty is fine - we support that lowering through flow.tensor.empty - I think the issue here is the lowering of torch.empty to linalg.init_tensor

flow.tensor.empty seems to be "metadata-only", but torch.empty is not metadata-only -- it has an allocated buffer, just with uninitialized data. So if a user returns torch.empty(10) from a function, they should be able to write 10 elements into what is returned.
We discussed at length in https://discourse.llvm.org/t/rfc-promoting-linalg-init-tensor-to-the-bufferize-dialect/5000 and weren't able to come up with an op on builtin.tensor (i.e. value semantics) that had the"intuitive" properties we wanted (besides init_tensor's sketchiness). Can IREE turn these init_tensor's into empty allocs at an appropriate point during compilation? Based on that thread, I don't think we are going to find any consensus on defining a well-defined op on tensors that meaningfully improves on init_tensor.

oh, so empty means zeroed? I thought we were talking about 0-length tensors - which by virtue of having 0 elements have no associated buffer. Having a zeroed tensor is flow.tensor.splat 0.

torch.empty returns a buffer with uninitialized data, it is not guaranteed to be zeroed.

In this particular case, the empty tensor also happens to be of size 0, but that's an independent thing specific to this particular situation. If a user writes torch.empty(10) they will get 10 uninitialized elements.

That's an insanely dangerous user-level API, and I can't imagine why someone would want it when operating at that level ;)
We can do that with a stream.resource.alloc uninitialized, but that's just a hint and the runtime may decide to zero it. I'm not sure we care too much about optimizing returns of uninitialized tensors - that feels like an overoptimization. If you want it to be faster to return garbage data then don't return it.

I agree, it's a pretty low-level API, but it is a common pattern in PyTorch to do things like torch.empty(sizes).uniform_(low, high) (in fact, there is no variant of "uniform" that returns uniform random values -- it has to be done in-place via this pattern)
I don't expect it to be use-case load-bearing that we match the performance characteristics of "allocated but uninitialized" in all cases[1]. However, it's quite difficult to identify ahead of time which of these "empty" are going to be written to as outs of a subsequent linalg operation, or returned (e.g. IREE might later inline a function and recognize that this is an operand to an outs). I think the request here is that IREE just does something with it, and materializes an appropriate buffer (much like we have to materialize tensor.dim ops around ops that aren't shape carrying).
[1] I don't think PyTorch can realistically guarantee 'no work done initializing the buffer' either -- e.g. if you ask for a large torch.empty, and have to request more memory from the OS, then the OS will probably have to zero it out anyway for security reasons before giving it to your process, negating the "uninitialized" performance benefit.

I'm not sure I follow the pytorch details, but I'm also not sure I need to :)
By the time we see it in IR create-empty-and-fill-contents-in-place (torch.empty(sizes).uniform_(...)) is the same as create-new-with-filled-contents (hypothetical torch.uniform(sizes, ...)) and we handle that fine. This issue is the create-empty-with-uninitialized-memory (torch.empty(sizes)), and I'm not sure what (reasonable) use there is to supporting that as uninitialized data that can escape the program - sounds like just a programmer using pytorch to allocate for them instead of returning sizes and allocating if desired. We will make that work of course but I'd hesitate to expose gaping security holes for such behavior :)

Is there a point in the IREE compilation pipeline where "we've handled all the create-empty-and-fill-contents-in-place and now we know that any other init_tensor's are from create-empty-with-uninitialized-memory"? I'd be fine with converting all such remaining init_tensor's to zero-filled buffers (good point about security).
The problem is that we can't really reliably tell at the frontend level which init_tensor's will or will not end up escaping (without being unnecessarily conservative IMO). E.g.
if cond():
  x = torch.empty(10)
else:
  x = torch.empty(20)
return x

One can imagine arbitrarily complex variants of that where the escaping torch.empty is hidden behind control flow, calls, etc. (or alternatively, where arbitrarily complex control flow leads to a subsequent x.uniform_(...) call).
I also want to preserve the ability of the user to write code like this and compile it without having to inline it for correctness:
def get_empty():
  return torch.empty(10)
def uniform():
  return get_empty().uniform_(1.5, 3.5)

Yep! I think mahesh just cleaned that part up and has a good place where we could handle this. Totally agree that a user should be able to write it.

We could at the very point where the error is thrown (or just before that) convert all linalg.init_tensors into flow.tensor.splat of zero. Down side is that we might miss the cases where this linalg.init_tensor shouldnt have been there in the first place and compile it with the overhead of setting buffer to zero. That is a fine thing to do actually. Its a simple pass... I can take care of it tomorrow. if this solution is acceptable.

SGTM! Whenever we get around to tracking the dispatch/transfer stats we'll be able to see if there are more fills than we would expect coming from init_tensor.

It looks like this test case is still failing. I reduced it to just:
module attributes {torch.debug_module_name = "NativeBatchNorm1DModule"} {
  func @forward() -> tensor<1xf32> {
    %0 = linalg.init_tensor [1] : tensor<1xf32>
    return %0 : tensor<1xf32>
  }
}

The error is:
/tmp/repro2.mlir:77:11: error: 'stream.tensor.sizeof' op type set has 0 dynamic dimensions but only 1 dimension values are attached
    %28 = linalg.init_tensor [0] : tensor<0xf32>
          ^
/tmp/repro2.mlir:4:3: note: called from
  func @forward(%arg0: tensor<?x?x?xf32>, %arg1: tensor<?xf32>, %arg2: tensor<?xf32>, %arg3: tensor<?xf32>, %arg4: tensor<?xf32>) -> (tensor<?x?x?xf32>, tensor<0xf32>, tensor<0xf32>) {
  ^
/tmp/repro2.mlir:77:11: note: see current operation: %39 = "stream.tensor.sizeof"(%0) {encoding = tensor<0xf32>} : (index) -> index
    %28 = linalg.init_tensor [0] : tensor<0xf32>
          ^
compilation from source to vm failed

I'm seeing if I can debug this. It looks like it might be pretty simple.

Sorry about that. I did try the test you had, but maybe I changed something after that.

I'm not sure what the expected behavior is. The issue goes away if I replace
flow.tensor.empty : tensor<1xf32>{%c1}

with
flow.tensor.empty : tensor<1xf32>

-- is tensor<1xf32>{%c1} legal, or should it only be dynamic dims in the {...}?

btw, @benvanik I noticed that we don't have any verifiers for this IR construct -- e.g. I can change it to tensor<1xf32>{%c1, %c1} and nothing complains. Can we improve that?

it should only be dynamic values in there
I have those verifiers for the stream types - they just need to be copied out to the flow types.

Okay, then the bug is in InitializeEmptyTensors. WIll send out a fix and add more verifiers.

Ok, Thats how I had it initially, and the example above compiled. I mis-understood Ben's comment on the PR and changed it to have all shapes (instead of just dynamic).
@silvasean if you havent gotten to it already, I can take a look.


[Improvement] HDD friendly deployment

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

What would you like to be improved?
Motivation
Due to Uniffle's multi-storage design, it's crucial that the second storages perform well.

Currently, the recommend deploy choices are MEMORY_LOCALFILE, MEMORY_HDFS and MEMORY_LOCALFILE_HDFS, and such deployments are used in production in iQiyi, Didi, Tencent, etc.
For MEMORY_HDFS deployment, it might be suitable for large shuffle. Due to HDFS' I/O model, it may not handle small shuffles very well. Therefore, MEMORY_LOCALFILE and MEMORY_LOCALFILE_HDFS are the de facto choices to cover most shuffle scenarios.
The storage choice of LOCALFILE could be traditional HDD disks, or SSD or higher-speed NVMe SSDs.  The SSD storages are preferred. However due to its cost and hardware constraints, SSD cannot be deployed widely.
Therefore, I'd like to propose some improvements to Uniffle's HDD deployment, make it more widely applicable.
How should we improve?

Reduce small I/Os of local storages:

The flush strategy of shuffle server could be improved, to wait for more shuffle data before flush to disk.
Leverages range partition to merge multiple partition's shuffle data in one file.
Defer flush of index file, which normally causes a small I/O.

I/O capability report, the shuffle worker shall report the local storage's hard drive type: HDD, SSD, etc and the disk numbers.
Better balancing strategy in coordinate and shuffle worker side:

coordinate side: partition size/throughput aware assignment to balancing workload in shuffle workers.
shuffle server side: distributes workload evenly to leverages multiple HDD disks. A new disk selection strategy should be deployed and I/O stats aware. cc @zuston

Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Leverages range partition to merge multiple partition's shuffle data in one file.

I heard from @jerqi that the range partition should be removed in the future.

I/O capability report, the shuffle worker shall report the local storage's hard drive type: HDD, SSD, etc and the disk numbers.

If owning this, I think we could support different local storages in single uniffle cluster.
For example, shuffle-server-1 has the HDD, but shuffle-server-2 uses the SSD. We could make single app use  the same local storage to avoid w/r speed gap.


windows/svc/mgr: Service.Control: populate Status when returning certain errors

For https://github.com/golang/go/issues/59015

In the next few days I'll look into whether adding a test for this is feasible.

~In the next few days I'll look into whether adding a test for this is feasible.~
Added a test.

Let's continue conversation in Gerrit
https://go-review.googlesource.com/c/sys/+/484895
Alex


Add Schematic/Block diagrams in README to explain LItmusChaos Workflow

The litmus README needs to contain a schematic/block diagram to explain the operational functional flow of LitmusChaos. While the demo video is helpful, it would help greatly if accompanied by the above

Fixed by https://github.com/litmuschaos/litmus/pull/1589


Applied theme in 4.0 looks real bad in Windows

I followed the theme installation instruction for Slack 4.0 and the theme was successfully update with no errors, but it looks terrible...

Background is dark but text is unchanged. Message backgrounds turn white on hover.

Yes, for some reason, in Windows it looks awful. I will try to find time to understand why.

Same on linux (mint). :penguin:

Yes, for some reason, in Windows it looks awful. I will try to find time to understand why.

Thanks!
Love the work you're doing here.
I just miss my dark theme so badly.

This is not the problem with this repo, but with Slack itself. Do the full Slack reset and after that this style will look great. Simply, use Help -> Troubleshoot -> Reset Slack to have the theme fully applied.
For details see this pull request or the source of this information.

This is not the problem with this repo, but with Slack itself. Do the full Slack reset and after that this style will look great. Simply, use Help -> Troubleshoot -> Reset Slack to have the theme fully applied.
For details see this pull request or the source of this information.

I can confirm that resetting Slack works.  (the menu entry is Help -> Troubleshooting -> Reset App Data). Thanks!

I have crafted a short memo about this: http://onezeronull.com/2019/07/19/dark-theme-in-slack-4/

Thing is, I have to Reset App Data each time I laucnh slack to apply the theme.

Maybe it’s time to just let it go and stick to the default theme 😔

Thing is, I have to Reset App Data each time I laucnh slack to apply the theme.

Well I don't have to do that: the dark theme is there even after restarting Slack. What I did was: reset app data, quit Slack, apply this theme, start Slack. Then, even if I restart Slack, the theme is still applied.

Either you did some magic or followed some secret combination that I cannot reproduce. I think I have repeated your step exactly as you wrote and still nothing. Each time I start Slack, theme is applied, but looks as awfully as in the initial comment in here (i.e. most things not readable). Each time I have to reset data to get Slack looking correctly.

Thanks for the help. For now this works fine

Would be nice to know exact steps you both undertook to have this working fine. Because some of us are still struggling with this issue and are still forced to reset Slack data each time Slack is started, in order to get dark theme in slack. So, congrats on success, but for part of us this doesn't work fine.

Yeah, I know, sorry. I'll get back on this as soon as possible. I'll even uninstall Slack and repeat the process on a clean install.

trejder, I had to do the same as you, I just leave slack running all the time so I don't need to reset as often unless I reboot.  hopeful a fix will be shortcoming.

I've got no idea where to ask (or how to debug electron apps) so I'll try to ask here: what css tag defines the background color of the div block which surrounds user name when you mention some user with "@"?

@kumamonishe Slack runs in web browser as well. And 99% uses the same layout and style sheet as the packed Electron version. So, simply run Slack web version in your browser and debug whatever you need using standard browser's debug / developers tools.

Yeah, I know, sorry. I'll get back on this as soon as possible. I'll even uninstall Slack and repeat the process on a clean install.

Alright guys, here's what I did:

Uninstall Slack
Delete %USERPROFILE%\Appdata\Local\Slack
Reinstall Slack
Quit Slack
git clone https://github.com/mallowigi/slack-one-dark-theme.git
npm install
npm run apply
Apply the theme
Start Slack (looks awful)
Reset app data
Theme looks as it should.

Then I rebooted the machine and started Slack -> the theme is still fine.
So I don't know what I'm doing wrong here :) I'm running Windows 10 Pro.
A couple of things to consider though: before applying the theme did you guys really quit Slack or just hit the X at the top right corner, as it doesn't quit the app, it just minimizes it to the tray.
And btw, you can see the developer tools in Slack too, just add the environment variable SLACK_DEVELOPER_MENU with the value true, and restart Slack. Then, you can summon the dev tools by hitting Ctrl+Alt+I. I have that env variable set, but I doubt it has any effect on this issue.

Just updated the styles a bit. I'm redoing it from scratch, but it is taking a hellova time.
Don't know about the Windows/Linux workaround though, but anyway try to run "update theme" to take the latest changes.

@pbloigu Then there must be something really weird in my PC or in my installation of Slack or something really unusual at your side. I have followed your guide step-by-step (thank you for providing it!) and unfortunately see no difference. Cool looking dark theme says only until next Slack restart.
I think I am going to give up on this thing. Bastards at Slack did a really good job in preventing us from using dark theme and keeping our eyes in comfort. I think I learn to live with the fact that I need to reset Slack data (which particularly means -- login again) each time I start this damn application.

Alright, how about enabling the dev tools, just for the heck of it? I know it's a long shot, but I have it enabled. I won't have an access to my laptop for a few days, so can't try disabling.

I am not sure, if enabling dev tools in Slack would bring me any closer to answering the question "Why dark theme isn't replicated each time I restart Slack?" or "Why do I have to reset all my data each time I restart Slack to get dark theme working?".
I think that dev tools are rather for dark theme's author to check some elements that needs additional styling in order to turn them into dark versions.
If you have any suggestion on how I should use dev tools to resolve problem with not applied dark style then I will be more than happy to hear it. Because, I am right now out of options and out of ideas.

FYI https://www.reddit.com/r/Slack/comments/cesgjb/dont_update_to_the_newest_version_of_slack_no/

I just want you to know @trejder. You are not alone. I have the same issue.

https://slack.engineering/rebuilding-slack-on-the-desktop-308d6fe94ae4?source=collection_home---4------0-----------------------&gi=37d81d672375


Dynamic u-posAbsoluteCenter (no explicit height required)

What about either replacing u-posAbsoluteCenter or adding a new class that didn't require a height:
.u-posAbsoluteCenter {
 position: absolute !important;
 top: 50%  !important;
 left: 50%  !important;
 transform: translate(-50%, -50%) !important;
}

Something I always add to a project already.
Thoughts @giuseppeg @simonsmith?

I think this would be a nice upgrade.

We lose the pinning to the corners ability

Not sure I follow...you mean if you're doing height/width 100%?

As written in this comment

Got it...Hmmm

If we care about losing corner pinning

I can't think of a use case for it if u-posFullScreen existed, so perhaps we can replace the existing implementation


Bug fixing sending ID with each json package

ID (package number) value wasn't being sent with each json package

Codecov Report

Merging #122 (204ffef) into master (728a673) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master     #122   +/-   ##
=======================================
  Coverage   33.95%   33.95%
=======================================
  Files          67       67
  Lines        3549     3549
=======================================
  Hits         1205     1205
  Misses       2344     2344

Impacted Files
Coverage Δ

src/telemetry/writer.cpp
29.35% <0.00%> (ø)

Continue to review full report at Codecov.

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


Training data

How I can get the training data of HICO?
you said that the data come from iCAN, but I found the training data of V-COCO dataset is different from iCAN(test data are the same), so how did you get the training data of HICO and V-COCO?
Thanks

No, I create a HICO data by myself using Detectron


Idesai tpm2 nvwrite size fix and add nice-name handling for nv attributes

This replaces PR #359 and adds to it.
This starts to get rid of specifying the attributes for nv indexes during nvdefine in raw numerical format.
I still need to modify tom2_nvdefine to use it, and update it's man page.
Unit tests are in place for the new attribute keyword parser.
System test is in place for writing a big nvindex.

@martinezjavier - this helps coalesce the options for dealing with policy enforcement as well.

@williamcroberts yes, is just that I'm still not that familiar with the TPM2 NV features to properly review nv related code...
Once I've tpm2_unseal working properly (and AFAICT it's only missing my last PR #365), I'll dig into the NV support to fix issue #348 and so I should be able to review this.

@martinezjavier sounds good, im gonna leave this up through the weekend and look at landing this on Monday. It fixes the nvread and nvwrite issues, as well as putting tests in place at both the unit level, but also making sure that nvread/write behavior across large files works. It also is now verifying the results of read, that it matches the bytes written.

@williamcroberts I very much like this concept. Thanks!


How to use it

You haven't mention how to use this mod like where to paste the files and how to uninstall it if it crashes your pc so pls try putting it in reader.md

It is given in the Readme file with the files.

What a dumbo

What a dumbo

well what create the scripts folder? was not the Ultimate ASI Loader? because now its just a dll

Copy & Paste VHUD content to GTA SA folder... You just need ASI Loader, you don't need Ultrimate ASI Loader. Troubleshoot it yourself.


Uncaught ReferenceError: iziToast is not defined

{{define "scripts"}}

{{end}}
Although I define it as a script, I cannot get the message on the site when I run it.

I got the same problem, iziToast v1.5.0 is loaded to the page (status 200 in devtools) but iziToast is not defined. I tried replace the script src with v1.4.0 and it works normally so I wonder what's the change here.

According to my guess, there is a problem while importing, the problem was
solved when I imported the source codes from the izitoast page to my
izitoastmin.js file.
Lã Ngọc Hải @.***>, 3 Ara 2024 Sal, 06:16 tarihinde
şunu yazdı:

I got the same problem, iziToast v1.5.0 is loaded to the page (status 200
in devtools) but iziToast is not defined. I tried replacing the script
src with v1.4.0 and it works normally so I wonder what's the change here.
—
Reply to this email directly, view it on GitHub
https://github.com/marcelodolza/iziToast/issues/221#issuecomment-2513459309,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BDEFV7YT4DOPSPZLBWRLFD32DUO7ZAVCNFSM6AAAAABPPSSVKOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJTGQ2TSMZQHE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Feat: Last Data Sync APIs and Frontend Trigger Functionality: Enhancing User Experience for Farmer Members and Produce

This PR includes,

Handing APIs for Last Data Sync for Farmer Member and Farmer Produce
Trigger Data Sync from Frontend
UI for Sync Now button and Last Data Sync

Also make sure that json files are sorted. connect with me on this if needed.


Fix UT random failure

Add 1 second waiting after receive ping because send ping is a separate task which might have some delay to update the _lastSendTimestamp and leads to test case failure.

ServiceConnectionDispatchTest still failed.


Update to contracts 3.1.0

Description

update to contracts 3.1.0 one mumbai and oneMumbai
bumped version to 1.2.0
updated the CI to use contracts 3.1.0

Is this PR related with an open issue?
Related to Issue #
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] Follows the code style of this project.
[x] Tests Cover Changes
[ ] Documentation

supersed by #98


Added rippers for rule34.paheal.net, xbooru.com and e621.net

e621.net support includes image pools

just checked the new ripme update
it can download from paheal now, there are some random "failed to download" errors popping up butat  other than that, its mostly functional

Can you provide a log file (with log level "DEBUG")?

nevermind that, it seems after a few uses the ripper has been able to download 100% of the images on paheal galleries no problem


[Aura-safe][CreateSafe] Display incorrect status of Scan QR screen when opening

Description

[ ] ISSUE: Display incorrect status of Scan QR screen when opening

Environment

Browser: Microsoft Edge
Wallet: Keplr
Safe: https://safe.serenity.aura.network/open
Environment: Serenity

Steps to reproduce

Go to https://safe.serenity.aura.network/welcome
Connect wallet Serenity Testnet
Click + Create new Safe button
Click Scan QR in B3

Obtained result
Display "The QR could not be read" and red highlight
Screenshots

Expected result

Chỗ này đang bị chặn camera nên hiển thị lỗi, không phải bug


Features/UI rebuild 107 themes

Integrated the theme template from Primevue.
Added a demo sidebar to toggle the themes of light/dark.

The v4.0 of Primevue is not applied:

It's still the beta version.
Some of the features aren't completely ready. Such as the multiple themes.
Some bugs for the beta version. Such as the auto import function.
We can do some refactor to update to v4,0 after the GA version is released.

Good basic setup - at some point we will need to move the dark mode button to the navbar, but good to have the functionality in place.


Proper "top level" name space for all yaml

[ ] YAML: Cleanup logging.yaml
[ ] YAML: Cleanup ssl_server_name.yaml

We should have a consistent top-level naming scheme, for all YAML formats. For logging, we would want to add something like:
logging:
   ....

We should make sure all existing, and new YAML formats have this.

Blocks #5457

IMO, we should just make the top-level tag the same as the config file name. I'm ok with renaming config files if that's a problem :).

+1

Sounds reasonable ssl_server_name for the top level tag sounds good.

These 2 files updated.

Awesome!


Focus color contrast ratio for non text element is less than 3:1.

Environment Details:
VSCode Version : 1.46.0 Insider
OS Version : Win10
Additional Details:
Screenreader: NVDA[2019.3.1], JAWS[2020.70]
GitHubTags:#A11ySev2;#A11yTCS;#A11yMAS;#Benchmark;#DesktopApp;#MAS1.4.11;#Win10;#Visual Studio Code;#CAITestPass_May2020;#FTP;
Repro Steps:
1.Open Visual studio code insider editor.
2.Using "Ctrl+`" key open the Integrated Terminals.
3)Using  "Ctrl+" key to split the terminal
4)Navigate to Spilt terminal icon using tab and turn on color contrast analyzer.
Steps to Reproduce:

Actual:
Contrast ratio of focus line when it is on Spilt screen icon is less that 3:1.
Expected:
Color contrast ration of non text contrast content should be more that 3:1
Attachment For Reference:

Does this issue occur when all extensions are disabled?: Yes/No

If this is a requirement for this non-text part, then it doesn't just affect the panel actions:

1.81:1:

This is regarding color contrast of icons.
@misolori and me are having a disucssion and we will decide what to do here.

I think in this case it’s referring to the focus border color.

You are correct. Renamed the issue.

Updated this issue to reflect all focus treatments in all areas (from #99426) like Activity Bar, Sidebar, Tabs, etc.

@isidorn in order for us to properly fix this issue, we'll need to make sure that the focus border color passes the 3:1 ratio on our lightest background (in this case it's the activity bar). After playing with the blue color, it appears that #007FD4 is the one that will pass the contrast ratio, but that color is significantly brighter than before (which personally I am fine with).

@misolori thanks for looking into this and for finding a good color. I think the focus being more visible is perfectly fine, and the new color still blends well with everything. I personally prefer it to the previous one, simply because it makes the focus more clear.
So feel free to push this, especialy since this is a start of the iteration so we get feedback.
fyi @bpasero

Will add this today and we can gauge the feedback. This also applies to our Light theme, so will update that color to #0090F1

Great, also works for me in Light.


unset the FIX_ENV when executing the real rustc

close https://github.com/rust-lang/cargo/issues/9706

r? @alexcrichton
(rust-highfive has picked a reviewer for you, use r? to override)

@bors: r+
Thanks for this!

:pushpin: Commit 4c11002b9d0547d50922073142c42e58d54c6128 has been approved by alexcrichton

:hourglass: Testing commit 4c11002b9d0547d50922073142c42e58d54c6128 with merge 3f68ff4fe3debc2ebfb049be80c35bcce32f80c1...

:sunny: Test successful - checks-actions
Approved by: alexcrichton
Pushing 3f68ff4fe3debc2ebfb049be80c35bcce32f80c1 to master...


Test: Tune tests to support MS Windows

Summary

This PR aims to tune the code to make the test runnable on Microsoft Windows.
Unfortunately, my MacBook got damaged and I have to use a Windows machine these days, when I try to run the test with .\gradlew.bat clean test, I get the following errors
xenon.clickhouse.HashSuite *** ABORTED *** (0 milliseconds)
  java.lang.RuntimeException: Unable to load a Suite class xenon.clickhouse.HashSuite that was discovered in the runpath: requirement failed: illegal path: D:\Projects\spark-clickhouse-connector\clickhouse-core-it\build\classes\scala\test
  at org.scalatest.tools.DiscoverySuite$.getSuiteInstance(DiscoverySuite.scala:80)
  at org.scalatest.tools.DiscoverySuite.$anonfun$nestedSuites$1(DiscoverySuite.scala:38)
  at scala.collection.TraversableLike.$anonfun$map$1(TraversableLike.scala:286)
  at scala.collection.Iterator.foreach(Iterator.scala:943)
  at scala.collection.Iterator.foreach$(Iterator.scala:943)
  at scala.collection.AbstractIterator.foreach(Iterator.scala:1431)
  at scala.collection.IterableLike.foreach(IterableLike.scala:74)
  at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
  at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
  at scala.collection.TraversableLike.map(TraversableLike.scala:286)

this is because Windows uses backslash as the path separator while UNIX-like OS uses the slash, it can be easily fixed by replacing path string match with Java NIO methods.
for developers who want to run tests on Windows, you need to:

install JDK 8 or 11 or 17 - download and unarchive a JDK tarball, set env JAVA_HOME and add %JAVA_HOME%\bin to PATH
install Hadoop winutils - just clone the repo and set HADOOP_HOME to the-path-of\hadoop-3.0.0
install Docker Desktop

after applying patch, I can run tests successfully
 .\gradlew.bat clean test

...

Tests: succeeded 74, failed 0, canceled 0, ignored 0, pending 0
All tests passed.

BUILD SUCCESSFUL in 4m 18s
26 actionable tasks: 26 executed

Checklist
Delete items not relevant to your PR:

[x] Unit and integration tests covering the common scenarios were added
[ ] A human-readable description of the changes was provided to include in CHANGELOG
[ ] For significant changes, documentation in https://github.com/ClickHouse/clickhouse-docs was updated with further explanations or tutorials

cc @wForget, can you do me a favor to test it on Windows if you have time? thanks

cc @wForget, can you do me a favor to test it on Windows if you have time? thanks

Sure, , I will do it later.


Build errors with RTI Connext 6.0.0

Hey guys,
I just found this awesome project and had some issues building with the latest RTI Connext DDS 6.0.0.
It looks like the -stl command was removed and the -stl behavior is not the default. As a result the files generated by rtiddsgen don't match the files expected to be generated by the build system.
Additionally I had a problem with namespaces. I had to manually add -namespace to the generation command line, otherwise Visual Studio 2017 was reporting that the value FIXED (an enum value) was already defined somewhere else. Turning namespaces on fixed this because the enum value is generated into a namespace.
I just wanted to let you guys know, so this can be fixed in upstream.

Hi,
You can go back to the old behavior and generate code with the old mapping by using the command-line option -legacyPlugin.
Thanks for the feedback on the -namespace.

Fernando

Thank you very much for the quick answer.
I totally overlooked the command line option -legacyPlugin. That could work, however this would also require modifying files in resources/cmake. So I guess the correct fix would be to add -legacyPlugin in case STL containers are turned off instead of changing the default behavior for Connext 6.0.0?
Side question regarding STL containers: Is the STL container option exposed as an option in CMake? I haven't found it a switch to turn on STL containers for the files generated by connextdds_generate_ros_dds_types.
For reference, I'm using CMake's FetchContent to download this project at configure time and make it available in my project. That means it's rather inconvenient to apply changes to the source code.

Hi @slietzau,
Sorry for my delay.
We have the solution to build the project using RTI Connext DDS 6.0.0. If you want to test it before we make the merge to master you can find it in the branch feature/1
Thanks for your feedback!

Hi @slietzau,
The branch feature/1 was already merged to master. Please give it a try and let me know how it goes.

Hi @Antoniolm,
thank you very much for the update!
I will have a look and see if it works.


Fix imports

This addresses #41 with one caveat:
I had to rename compare_mt.py to main.py (and compare_ll.py to main_ll.py for consistency). This was to avoid conflicts with the package name.
So now you can either run python compare_mt.py [...] or install and run compare-mt [...]

I made a few small changes to the files main.py->compare_mt_main.py, main_ll.py->compare_ll_main.py, because the asymmetry in the naming bugged me. Other than that looks good, and I'll merge after I fix tests.


How can we help?
None
Please read and ensure the following

[X] The installer meets the above requirements

Please provide the following information
Download Page Url: https://github.com/AmrDeveloper/FileQL/releases
Publisher: https://github.com/AmrDeveloper
Package Name:fileql
Description: A tool that allow you to run SQL-like query on local files
Package Version: 0.2.0
Installer URL: https://github.com/AmrDeveloper/FileQL/releases/download/0.2.0/fileql-x86_64-windows.exe

Since 0.2.0 is on the repo now, this can be closed @AmrDeveloper

@stephengillie


Update State using setState()

Thanks for your PRs - can you tell me why this is better than modifying the state directly?

I was getting an error when I ran 'npm rum dev' on my computer. I've
reported the issue with the error msg I was getting.
I'm a React developer for over an year and I've  noticed that updating
state using setState not only keeps the dom reactive, it is very secure.
I went through all of the code and I changed many pieces to check what was
causing the problem. I noticed it was the state update. State values are
never recommended to be updated directly in React. I changed the lines
where state was updated and the error never came again.
Test it before merging in the master repo. I've tested on two machines and
its working fine now.
On Mon, Aug 20, 2018, 3:32 PM Marcel Pociot<EMAIL_ADDRESS>wrote:

Thanks for your PRs - can you tell me why this is better than modifying
the state directly?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/botman/web-widget/pull/15#issuecomment-414271572, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AWa28MHkpgDsLKu6OuHf2PF7PRSdAzHcks5uSpBEgaJpZM4V6dFT
.

This is the issue: https://github.com/botman/web-widget/issues/14
On Mon, Aug 20, 2018, 4:08 PM Malik Mohsin Hayat FastNU <
<EMAIL_ADDRESS>wrote:

I was getting an error when I ran 'npm rum dev' on my computer. I've
reported the issue with the error msg I was getting.
I'm a React developer for over an year and I've  noticed that updating
state using setState not only keeps the dom reactive, it is very secure.
I went through all of the code and I changed many pieces to check what was
causing the problem. I noticed it was the state update. State values are
never recommended to be updated directly in React. I changed the lines
where state was updated and the error never came again.
Test it before merging in the master repo. I've tested on two machines and
its working fine now.
On Mon, Aug 20, 2018, 3:32 PM Marcel Pociot<EMAIL_ADDRESS>wrote:

Thanks for your PRs - can you tell me why this is better than modifying
the state directly?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/botman/web-widget/pull/15#issuecomment-414271572,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWa28MHkpgDsLKu6OuHf2PF7PRSdAzHcks5uSpBEgaJpZM4V6dFT
.

Thanks for your PRs - can you tell me why this is better than modifying the state directly?

The build fails. as mohsinht explained this will fix all build errors and I confirm

Please merge the branch.


Support series row mutation

Does anyone see cases where this might produce undesired results?

Actually, the proposed solution fails because changes to df.x do not affect df, so df.x[condition] = value does not operate as expected.  This possibly affects dask.array as well, where users are probably accustomed to memory view semantics.


vscode closes when cancelling a save file dialog

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.60
OS Version: Windows

Steps to Reproduce:

Open vscode without a workspace
Create a new file (CTRL + N)
Start typing in the new file
Press CTRL + S
Once the file dialog box appears, press Escape

The dialog dismisses but vscode also closes, without prompting you to save the file you just made changes on

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

@bpasero so interesting development. it does not happen once i upgraded to 1.60.2 - didn't know there was a new version at the time of writing this (i was currently on 1.60.1) I don't use nightly. Also, some minor feedback, weird that i would need to download an entirely different type of vscode just to test it, when i included the steps to reproduce, but that's not a big deal, just my 2 cents :)
I have a theory, but don't want to throw out assumptions or create unnecessary red herrings for anyone. For now it's not reproducible on 1.60.2! I'll reopen if it is because what i think it is and can definitively recreate the issue based off that. Thanks for the quick response!


Split chapters out into seperate asciidoc files

Adoc Cross References
Instead of the main adoc file having information on all the tools and guides for the H3EK, I was thinking of taking chapters out of the main file and putting them into separate adoc files, which then can be referenced in the main adoc file.
For example, the guides should be their adoc files respectively, referenced in the main adoc file, to reduce clogging. Ideally, the main file should reference a collection of many adoc files that isolate information making it easier for the viewer to read.
Cross-Reference Tasks

[ ] Figure out how to navigate between source-files
[ ] Separate chapters from the main adoc file into their adoc files
[ ] Reference new adoc files in the main adoc files

Addtitional Information

AsciiDoc Syntax Quick Reference
Document to Document Cross References

I Agree that this would be the best way to approach this, and makes for cleaner source-control


Select doesn`t lose focus after open dropdown menu within it

[ ] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
After picking an option from Select and clicking outside the select container, Select must lose focus.

Current Behavior
After picking an option from Select and clicking outside the select container, Select doesn`t lose focus.

via GIPHY
https://media.giphy.com/media/5WicPCbBlK8t7Fl6nU/giphy.gif
Steps to Reproduce (for bugs)

1.Pick an option from Select
2.Clisk outside from Select container
3.Notice, Select stayed in focus state
Context
Top part:

import React from 'react';
import TextField from 'material-ui/TextField';
import Input, { InputLabel } from 'material-ui/Input';
import MenuItem from 'material-ui/Menu/MenuItem';
import { FormControl, FormHelperText } from 'material-ui/Form';
import Select from 'material-ui/Select';
import {inject, observer} from 'mobx-react';
import ButtontForStepper from './ButtontForStepper';
import {FIRST_STEP} from 'constants/RacConstrains';
import uploadDefaultImg from 'images/uploadBg.png'
import validate from 'validate.js';
import classNames from 'classnames'
import _ from 'lodash';
import {PARSE_GEO_CODE} from './parseGeoCode';
import FullDatePickerInput from 'blocks/FullDatePickerInput';
const MEGABYTE = 1024 * 1024;
const RACE_TYPES = [ 'mass', 'wave', 'interval', 'one_by_one'];
@inject('raceStore')
@inject('alertStore')
@inject('httpClient')
@observer
export default class CreateStepFirst extends React.Component {
state = {
errors: {}
};
componentWillMount(){
this.geocoder = new google.maps.Geocoder();
}
handleChange = (e) => {
this.props.raceStore.handleChange({[e.target.name]: e.target.value});
};
componentDidMount() {
console.log('clicked');
const input = document.getElementById('autocomplete');
const autocomplete = new google.maps.places.Autocomplete(input);
autocomplete.addListener('place_changed', () => {
let place = autocomplete.getPlace();
if(place.formatted_address)
this.handleChange( { target: { name: 'race_location', value: place.formatted_address } } )
});
}
handleSubmit = e => {
e.preventDefault();
const errors = validate(this.props.raceStore.dirtyRace, FIRST_STEP, {fullMessages: false}) || {};
this.setState({errors: errors});
if(_.isEmpty(errors)){
this.getComponentAddress().then(location => {
this.props.raceStore.setLocation(location);
this.props.raceStore.createRace(true);
});
}
};

Working Code inside component:

      <FormControl error={!!errors.sport_id} className='custom-select'>
        <InputLabel htmlFor="sport_id">Sport</InputLabel>
        <Select
          id='sport_id'
          label='Sport'
          name='sport_id'
          onChange={this.handleChange}
          value={race.sport_id}
        >
          {sportTypes.map(option => (
            <MenuItem key={option.title} value={option.id}>
              {option.title}
            </MenuItem>
          ))}
        </Select>
        <FormHelperText>{errors.sport_id}</FormHelperText>
      </FormControl>

      <FormControl className='custom-select'>
        <InputLabel htmlFor="type">Type</InputLabel>
        <Select
          label='Type'
          name='start_type'
          input={<Input id='type'  onChange={this.handleChange} value={race.start_type || ''}/>}
          MenuProps={{animated: false}}
        >
          {RACE_TYPES.map(option => (
            <MenuItem key={option} value={option}>
              {option}
            </MenuItem>
          ))}
        </Select>
      </FormControl>

Your Environment

Tech
Version

Material-UI
1.0.0-beta.27

React
15.6.2

browser
Chrome, Firefox

@vadimnike I have the same problem with Select, may I know how did you fix it?

I'm experiencing this as well in my app, but I can't reproduce it in a sandbox.
The culprit is the ignoreNextBlur flag. It depends on the browser firing an initial blur event when the Select is first opened. If this does not occur, then the flag is still set to true when we arrive here.
In the case where this is not working, handleBlur is not running that first time. In the working case (the sandbox I linked to), it does run, this flipping the flag back to false.
I get the same behavior in Firefox as well as Chrome (Mac). There must be something specific to the DOM in our apps that is preventing the initial blur event from firing.
I'm on beta 47, fyi (and my sandbox link is using that version as well)

Further testing reveals that this is only an issue on React 15:

Broken React 15 version
Working React 16 version

@ericbiewener Hum, v1.0.0-beta47 is supposed to support React 15. I agree it's confusing. I hope upgrading to React 16 isn't a burden for your team.

For me both of these 2 examples are broken - the inputs never loose focus again.
I am also experiencing a similar issue with a TextField when using it together with downshift for autocomplete.
This issue should be opened again I think.

@oliviertassinari we're in the process of upgrading, so this just gives us more motivation :)

I am experiencing the same issue with a Select inside a FormControl. Once the Select is opened, its state changes so that focused is true and is never able to change back to false.
As a bit of an experiment, using React dev tools I am able to change the state of the FormControl so that focused is set to false, but this does not propagate down to the Select/Input components. If I update the state of the Select component so that focused is set to false then I can see it does update the styling. I haven't been able to figure out how to get this to work programatically by accessing refs and changing state as everything appears to be wrapped with WithStyles making this a little difficult, so I am affected by this bug.
I am using<EMAIL_ADDRESS>

@azcn2503 This will be fixed with #13487 in Input.

@eps1lon This "feature" is still present "@material-ui/core": "^3.9.2".

@ifier It's still present in v4 too.

we're experiencing this issue on v4 and react 16
"@material-ui/core": "4.5.2",
"react": "16.8.6",

Also experiencing this issue in v4/react 16:
    "react": "^16.9.0"```

I have same issue. But I think is hard to say if it is issue?
This may be here because of accesibility and navigation, If you close select, you are still able enter and change option. If you lose completly the focus it will be hard move to next select in some Form for example.
So I can see we need this behavior, but also will be nice to have easy option to turn off this behavior with some prop.
I try useRef and then blur(). Also onClose, onExit props I try blur() with callback, but this have no effect.
My suggestion is: add props which is bool, and I cant turn on/off.
If its ON? It will stay focused after exiting
If its OFF? It will remove focus after exiting

Same issue. Mui version is ^5.14.4, react - ^18.2.


Fails under python2.7

The last commit included a python 3.0 only feature, the extended destructuring *_ in common.py:79.

Thanks for the report. I fixed it. Version 0.1.31.


Update Lootly,Loox Update Arc publishing -> Arc XP

update categories, add requires
website:
https://www.arcxp.com/
examples:
https://www.infobae.com/america/
https://www.lanacion.com.ar/
https://www.leparisien.fr/
https://tw.appledaily.com/home/
https://www.reuters.com/

There is a version with an error in the master, couldn't fix
I also upgraded Arc Publishing to Arc XP.


Collapse pages per default above threshold

Motivation

Since pagination doesn't work well on trees, we should implement a different measure to prevent too many entries which can be overwhelming at first sight.
Proposed Solution

Collapse all subpages until the total amount of visible pages in the tree is below a certain threshold.
Probably use the same setting which is planned for pagination: https://github.com/Integreat/integreat-cms/blob/15099b61c28afa5f290e8ace5da904d139ddc075/src/backend/settings.py#L533
Different collapsing algorithms are possible:

Radically collapse all subpages

Pro: less effort
Con: More effort to expand the subpages

Collapse only subpages of root pages

Pro: Also not much effort
Con: Many pages expanded at once, which can be confusing

Collapse and expand subpages based on number of pages on the sub-level (e.g. if the number of descendants is above threshold, only expand the direct children, otherwise expand all descendants)

Pro: Good balance between clicks needed to expand tree and number of entries expanded at once... so best user experience???
Con: More effort

Alternatives

Additional Context

Additionally, add the possibility to collapse and expand all pages at once.

As our current system uses the first option, we should collapse all sub pages by default.


line 2 column 54 - Error:  is not recognized! dependency check maven plugin

Describe the bug
We upgrade to version 7.3.1 and 7.3.2 of dependency check maven, the execution is completed successfully but we get this message
line 2 column 54 - Error: < goal-name > is not recognized!
owasp_db : "7.3.2"
while executing this command:   ./mvnw help:describe -Dplugin=org.owasp:dependency-check-maven $MAVEN_ARGS "${MAVEN_ADDITIONAL_ARGS_ARRAY[@]}" | grep Version:
We don't have this message with version 7.3.0 of plugin neither with dependency check gradle v 7.3.2 and 7.3.1.
We make some other tests by changing the owasp DB version to 7.3.0, we have the same behavior. So, We assume that this message is related to the plugin not to the BD.
We even changed the version of maven-help-plugin with the latest one , we get the same result.
We used the grep with another plugin and it works without problem. So, we can confirm that the message comes from dependency-check-maven plugin.
We checked the plugin changes between version 7.3.2 and 7.3.0 https://github.com/jeremylong/DependencyCheck/compare/v7.3.0...v7.3.2 and there are only same visibility changes
Version of dependency-check used
The problem occurs using version 7.3.2 and 7.3.1 of dependency check maven plugin
Expected behavior
We expect to get the dependency check version as output.

Likely due to https://github.com/jeremylong/DependencyCheck/pull/5034.
Although, when I run this I get:
$ mvn help:describe -Dplugin=org.owasp:dependency-check-maven | grep 'Version'
line 2 column 54 - Error: <goal-name> is not recognized!
Version: 7.3.2

The warning is being written to standard error - so could be hidden by running:
$ mvn help:describe -Dplugin=org.owasp:dependency-check-maven 2>/dev/null | grep 'Version'
Version: 7.3.2

Also - your call has a several variables(maven args) that might be affecting the output. For instance, if the variable included -q - you would only get the warning message:
$ mvn help:describe -Dplugin=org.owasp:dependency-check-maven -q
line 2 column 54 - Error: <goal-name> is not recognized!

Thank you @jeremylong for your quick response.
We are asking this question since we haven't see this warning in versions under 7.3.1 and we are wondering if there are some changes in goal-name or something.


Fix address search

I didn't do string interpolation correctly.
Carto doesn't like however the string turns out using object interpolation for something like WHERE x = 'y', so I just used the plus sign notation to build the string.

👍


"No Signal" display w/ no projects or errors

A basic screen that's likely only going to be seen in a development context - probably says "no signal" in the middle of a blue screen (or something like that, nothing crazy). This will be shown:

If no projects are available to be displayed (project list is empty)
A rendering error is caught

Should probably just be its own overlay - not a Project subclass. This will make it easier to integrate in situations where we don't have a ProjectViewer ready to rock.

https://stackoverflow.com/questions/76141595/client-side-global-error-handling-in-sveltekit


Likely memory leak in use of TSF_REALLOC in new sf3 code in out of memory conditions

These look like potential memory leaks to me:
https://github.com/schellingb/TinySoundFont/blob/d21fe7b22c8c906e749e4be4bb389efc2e761964/tsf.h#L908
https://github.com/schellingb/TinySoundFont/blob/d21fe7b22c8c906e749e4be4bb389efc2e761964/tsf.h#L918
...in case the allocation fails. The old res pointer will leak then, I think the right way would be to never realloc() to the same pointer variable in one line and in case of failure, make sure the old one is free()'d if it's no longer used (as is the case here). My bad if I'm mistaken, I didn't actually confirm a memory leak via valgrind or something.

Fixed this one, too!
There certainly was a potential for a memory leak with the previous code.
As always, thank you so much for reporting this!


Add Power Bi Metadata and Telemetry Capture Function

Download of Power Bi metadata & telemetry from the Power BI Admin API to Azure Storage:

[ ] Must provide list of all power bi reports in tenant
[ ] Must provide list of all power bi datasets in tenant
[ ] Must provide list of all power bi workspaces in tenant
[ ] Must provide list of all power bi dashboards in tenant
[ ] Must provide list of all power bi dataflows in tenant
[ ] Must allow for incremental & full load
[ ] Must provide history of all usage activity available from the power bi admin api (eg Report Views etc) .

Auto population of the above data sets has been completed as part of the development 1.0 branch


PATH troubles

If you switch to the besh branch, you may notice that some programs, like pastebin fail to run. This happens because these programs are in subdirectories in /rom/programs. In case of pastebin, this is /rom/programs/http iirc.
This is a problem and our only options are pretty much:

Put all subdirectories into the PATH. This is how CraftOS does it.
Modify system.paths.resolve to search recursively. (=> Optional parameter?)

I'm actually not sure which way would be best. Probably CraftOS style to prevent people running turtle programs on a computer.

Good point, I'll just copy the CraftOS path over for now.


DataLabelsPlugin weird behaviour on stacked bar chart with multiple labels

Hi!
We're using some Charba charts for our new dashboard. One of the charts we are making is a stacked-bar-chart with two dataset. We want to use data labels for both of these data sets, but each will have a different position. It's working very nicely except for one small detail that we cannot make sense of. One of the two labels also results in a black spot at the top of the chart:

If i hide the 'minimale'-dataset, the spot dissappears. If I don't set this datalabel in the code it dissappears. If i make the datalabel longer with some text, the black-thing will also become longer like so:

Changing anything on the 'netto'-dataset has no effect whatsoever (or even removing it). The code for both labels is very similar, even when brought back to its basics without any layout-settings, the behaviour persists.
The simplest code, where the issue still presents itself, where '1' is the correctly-working net-dataset and '2' is the min-data set with weird black dot:
DataLabelsOptionsBuilder builder = DataLabelsOptionsBuilder.create();
        builder.createLabel("1")
                .setFormatter((context, dataItem) -> {
                    if (context.getDatasetIndex() == 0) {
                        return "";
                    }
                    return "1";
                }).getOptionsBuilder();
        builder.createLabel("2")
                .setFormatter((context, dataItem) -> {
                    if (context.getDatasetIndex() == 1) {
                        return "";
                    }
                    return "2";
                }).getOptionsBuilder();
        getOptions().getPlugins().setOptions(DataLabelsPlugin.ID, builder.build());

So it seems a very strange issue to us. Perhaps we are missing something obvious. Are we mis-using the datalabels plugin somehow? The chart incl datalabels are otherwise working very well!
Do you have an idea what could cause this and if we can fix it?
Let me know if you need any more code or other information!
Kind regards,
Annemijn

@AHijner this should be a normal behavior of datalabels plugin where the data at a specific index is NaN or null.
Could you share the datasets options?

Ah yes, that makes sense!
With this hint we found the problem. We had a request to make the y-axis slightly higher than te max value, so we set:
yAxis.setSuggestedMax(context -> {
            List<Double> data = context.getChart().getData().getDatasets().get(0).getData(); //min
            data.addAll( context.getChart().getData().getDatasets().get(1).getData()); //net
            return Math.max(5 + data.stream().max(Double::compare).orElse(0D), 15);
        });

Which of course will add the extra data-points to the first set. Silly mistake.
With something like
yAxis.setSuggestedMax(context -> {
            List<Double> minData = context.getChart().getData().getDatasets().get(0).getData(); //min
            List<Double> singletonData = context.getChart().getData().getDatasets().get(1).getData(); //net
            return Math.max(5 +
                   Stream.concat(minData.stream(), singletonData.stream())
                    .max(Double::compare).orElse(0D), 15);
        });

the problem is fixed!
Thank you so much for the input, it was very helpful! :)


[feature] Add more tests for TRW's specific commit sha1 for v0.2

We need to verify that that generated  provenance is correct. Unit tests and scheduled tests within this repo.
The feature was introduced in https://github.com/slsa-framework/slsa-github-generator/pull/2078

this should include verification for both v0.2 and v1.0 predicates

Removing this issue from the BYOB milestone, because we want to support v1.0 first.


Contribution Learning Materials

In a general since, what would be the table of contents for learning materials to be a useful contributor for libuv, e.g. things you must know about?

In general I'd say wanting to do it is the most important part. libuv is organized quite nicely so you may not need to touch many places to add a feature or fix an existing problem in a specific area.
I'd recommend taking a look at this: http://docs.libuv.org/en/v1.x/design.html and then starting the user guide: http://docs.libuv.org/en/v1.x/guide.html Now, the guide hasn't gone through a lot of scrutiny so it may contain mistakes! All the mistakes you find and problems you ran into which can be fixed in the guide would be great starting contributions.

I don't think there is anything left to do here, so I'm going to close this issue out. Feel free to follow up with any questions though.


Update the Algolia records when deleting a user

Currently, the app does not delete a record from Algolia, when deleting a user. Deleting a user should also delete a record on Algolia.

Separate the issue about the review into #318


Facilities ranking for each goal

Ranking by characteristics, like indexing for choosing matching facility

should be integrated into rt::TheFastestGet


Performance issues for larger trees

Thanks for the great work! I noticed that editing in a larger tree is pretty slow making typing sluggish. It would be great if the editing behaviour could be changed so that the edits are only applied after a few seconds of inactivity or when the editor is closed?

@MeneDev I'm aware of the issue but only in really really large trees like: https://saqimtiaz.github.io/sq-tw/streams-tiddlytoolmap.html
As mentioned on the Roadmap, the plan is to eventually use something similar to the draft mechanism the core uses to avoid this issue. However that wont be for a while until I have the time to dedicate to what will be a pretty extensive refactoring.
For now your best option would to open a part of the subtree and close the main tree when editing. Or if you are willing to tweak and experiment a bit, you could try setting the nodes to have the field: throttle.refresh
See https://tiddlywiki.com/#RefreshThrottling
Another option is to collapse parts of the tree that are not in use. A "collapse all" feature would be useful here and is planned, but there is no specific timeline for when I might be able to work on that.

Thanks, wasn't aware of those tw features. I dug a bit deeper and the main performance issue seems to be the styleRefresh which is currently applied with each keystroke, even if I set throttle.refresh. For testing I set $:/config/Drafts/TypingTimeout to 2000, yet the style changes are applied immediately. It's happening in $:/core/modules/startup/render.js:51. I'll try to investigate further.

@MeneDev could you please confirm if styleRefresh() is also called with every keystroke in an empty TiddlyWiki with no plugins, when typing in a tiddler?

No, I did some changes and that improved performance massively: I have Stroll installed, the backreferences were reevaluated when typing, I removed that part of Stroll, I also disabled all other plugins.
One surprising finding: using the Vanilla theme with enabled Sticky titles causes [[200]subtract<currentTiddler>] (in wiki/tiddlers/$__themes_tiddlywiki_vanilla.json) to be reevaluated. Adding a single character increases the counter by exactly 300 invocations.

No, I did some changes and that improved performance massively:

That is good to hear. I had been rather surprised that you were having such significant performance issues. I have some further performance optimizations planned for after the release of TiddlyWiki 5.1.23

One surprising finding: using the Vanilla theme with enabled Sticky titles causes [[200]subtract<currentTiddler>] (in wiki/tiddlers/$__themes_tiddlywiki_vanilla.json) to be reevaluated. Adding a single character increases the counter by exactly 300 invocations.

Oh wow. If that happens without any plugins, I highly recommend reporting an issue at https://github.com/Jermolene/TiddlyWiki5

PS: I am going to leave this issue open for now until I've had a chance to work on the planned performance optimizations.

In Streams 0.2 (still in preview, code in performance branch), rendering time for very large streams is reduced by over 3 fold.
You can compare the rendering time for the tiddler "TiddlyWiki Toolmap" on the old version versus the new one.

In Streams 0.2 (still in preview, code in performance branch), rendering time for very large streams is reduced by over 3 fold.
You can compare the rendering time for the tiddler "TiddlyWiki Toolmap" on the old version versus the new one.

Streams 0.21 is now available and has significant performance improvements. Let me know if you still have any issues with performance.

One surprising finding: using the Vanilla theme with enabled Sticky titles causes [[200]subtract<currentTiddler>] (in wiki/tiddlers/$__themes_tiddlywiki_vanilla.json) to be reevaluated. Adding a single character increases the counter by exactly 300 invocations.

Oh wow. If that happens without any plugins, I highly recommend reporting an issue at https://github.com/Jermolene/TiddlyWiki5

I know, where this comes from. It's how the "sticky titles" CSS is created. It uses z-index.
It's the dynamic CSS creation in $:/themes/tiddlywiki/vanilla/sticky ... May be we should "hardcode" those settings in the tiddler


Update EU/RU server Discord invite link

Old one is expired

Thanks.
I suggest you avoid using Discord since they use user information to make a profit


Whitespace in template path won't work

I have my template in $(System.DefaultWorkingDirectory)/Terraform Storage, which will not work:
pwsh /home/vsts/work/_tasks/RunARMTTKTestsXPlat_cb27e003-8534-4da9-aaa0-35ca8756ae29/1.2.0\powershell\ps-runner.ps1 -templateLocation /home/vsts/work/1/s/Terraform Storage -resultLocation /home/vsts/work/1/s/results -cliOutputResults -ignoreExitCode -recurse
##[error]The input file path cannot be specified multiple times

##[error]The input file path cannot be specified multiple times

Sounds like a pretty glaring bug, will take a look at it shortly

Sorry for the delay, I've just released a new version that should fix this, please test and let me know.


Feature engineering refactoring

This is a major change in the sam model interface (v3).
Goal is to separate feature engineering and model part, which makes it a lot easier to customize feature engineering. Also creating new types of models will require less code. Instead of providing FE parameters to a model, only provide a FE class. The FE class can incorporate any parameters. To make feature engineering still quite simple (rolling features and time components), new classes will be available.
Feature engineering checklist:

[x] New feature engineering classes
[x] Unit tests
[x] Tutorials
[ ] Documentation incl. examples
[ ] Resolve TODO's

Model checklist

[x] integrate new feature engineering
[ ] reconsider default parameters for base model & mlp
[ ] performance / speed comparison (e.g. refactor some things to numpy?)
[ ] documentation incl. examples
[ ] tutorials
[ ] model unit tests
[ ] Resolve TODO's

What to do with CyclicalMaxes/decompose_datetime/etc. ?

Should force_monotonic_quantiles be part of BaseTimeseriesRegressor.predict()?


Don't swallow touch events for form inputs.

TouchEmulator doesn't play nicely with form inputs (specifically text <input>s and <textarea>s): you can't click to focus them, and when they are focused, you can't move the cursor or change the selection.
I'm not sure if this is the best fix, but it seems to work in my very limited testing.

Not sure if i should merge this, it needs some testing. Code looks fine though

I'm guessing no one will merge this a year later :)
Alternatively, I modified the same function to allow mouse events when the altKey is pressed. It didn't seem to be used anywhere else.
function onMouse(touchType) {
  return function(ev) {
    if (ev.altKey) {
      return;
    }
    // prevent mouse events
    preventMouseEvents(ev);
    // [...]
  }
}

This is useful @Joefreeman, thanks!

Ok, it's been four years. Closing...

Seven years on, the fix is still useful and works well.

Oh so sorry for the delay. I was a burned out by the whole project and never got myself to it. Thanks Blake for the nudge and Joe for the PR.


#22 - Update README to have explanation for the new methods of Client class

Merging since all comments are resolved.