Better deployment of dll for setup_dxvk.sh

To make setup_dxvk.sh more unified (i.e. one script for all scenarios), it can be useful to rearrange dlls deployment a bit. For example:
./bin
./bin/setup_dxvk.sh
./lib
./lib/win64/dxgi.dll
./lib/win64/d3d11.dll
./lib/win64/d3d10core.dll
./lib/win64/d3d10.dll
./lib/win64/d3d10_1.dll

This will allow cleaner placement of 32-bit dlls. While .so ones can be deployed cleanly now in the same parent location, dlls are not since they are placed in bin.
I.e. adding this would make it work:
./lib/win32/dxgi.dll
./lib/win32/d3d11.dll
./lib/win32/d3d10core.dll
./lib/win32/d3d10.dll
./lib/win32/d3d10_1.dll

If you think it's a good idea, I can update my PR to do that.

Why would you want to rearrange the files, and what's the fuss about something that's meant for development purposes? Remember that every change to this also changes my workflow.

If the debian package actually ships the .sh script like that then someone should tell them that this is a bad idea. If they want DXVK to be set up via symlinks, which is of course a good thing, they should probably put a small script in themselves that points to the correct locations, but this is distro-specific.
I can also see why the current script is less than ideal, but it's not an easy fix since it is being generated during the build process, i.e. once for the 64-bit build and once for the 32-bit build.

I can also see why the current script is less than ideal, but it's not an easy fix since it is being generated during the build process, i.e. once for the 64-bit build and once for the 32-bit build.

That can be changed by making the script static, and more generic without templatizing it. Kind of the idea I was going in the PR with external variables controlling the changing parts.
But sure. May be simply writing an alternative script will work as well. I can propose it to Debian maintainers or write one myself first.

That can be changed by making the script static (not generated), and more generic without templatizing it in the build.

Yes, but then you basically can't do ninja install and have a working script either.

By the way, why after building 32-bit / winelib variant, ninja install produces .a files in 64-bit subdirectory?
./lib/x86_64-linux-gnu
./lib/x86_64-linux-gnu/dxgi.dll.a
./lib/x86_64-linux-gnu/d3d11.dll.a
./lib/x86_64-linux-gnu/d3d10core.dll.a
./lib/x86_64-linux-gnu/d3d10.dll.a
./lib/x86_64-linux-gnu/d3d10_1.dll.a

@shmerl If debian is as bad as ubuntu (which is based on debian), then the winelib build script does not work without the meson build option for --libdir=, cos building it without manually moving the files will just build everything in the x86_64-linux-gnu folder (and overwrite 64-bit dll.so's with 32-bit ones..)
Not really sure why this happens, but ubuntu's crossbuild system kinda blows that way (debian probably better tho)
You can try with the "meson --libdir=lib" option when building and see if it is any better/logical.

@shmerl As the base version of dxvk is just a mingw build you could use the corresponding mingw prefix.
For example arch as a 32bit and 64bit mingw prefix:
https://wiki.archlinux.org/index.php/MinGW_package_guidelines#Packaging

btw, here is a small script to detect wine arch for a given prefix, in case someone needs it:
function get_wine_arch() {
   local prefix="${WINEPREFIX:-"${HOME}/.wine"}"
   local registry_winearch=$(perl -ne 'print $1 if /#arch=(win\d+)/' "${prefix}/system.reg" 2>/dev/null)
   wine_arch=${WINEARCH:-"$registry_winearch"}

   if [[ "$wine_arch" == "" ]]; then
     # default fallback if nothing came up
     wine_arch="win64"
   elif [[ "$wine_arch" != "win64" ]] && [[ "$wine_arch" != "win32" ]]; then
     echo "Unexpected Wine arch ${wine_arch} encountered. Aborting!"
     echo "WINEARCH='${WINEARCH}', registry_winearch='${registry_winearch}'"
     exit 1
   fi

   printf $wine_arch
}

OK, I tested. --libdir does affect where .so and .a files are deployed, but not the dll ones.

I can control dlls placement with --bindir, but that also relocates setup_dxvk.sh there. So splitting that into a separate option (keeping it default same as current layout) can probably help.

What determines, that dlls are placed in bindir now?

Yep, this worked. Added this to meson_options.txt
option('scriptdir', type: 'string', value : '')

And this to utils/meson.build
conf = configuration_data()
conf.set('bindir', get_option('bindir'))
conf.set('libdir', get_option('libdir'))
conf.set('arch', target_machine.cpu_family())
conf.set('winelib', dxvk_winelib)

scriptdir = get_option('scriptdir')
if scriptdir == ''
  scriptdir = get_option('bindir')
endif

configure_file(
  configuration : conf,
  input         : 'setup_dxvk.sh.in',
  output        : 'setup_dxvk.sh',
  install_dir   : scriptdir
)

Then invoking meson works something like this:
  cd "$dxvk_src"
  meson --cross-file $cross_file --libdir lib64 --bindir lib64 --prefix ${dest_dir} "$dxvk_build"
  cd "$dxvk_build"
  meson configure -Dbuildtype=release -Dscriptdir=bin

I can make a PR with this.

I dont think i have really grasped the purpose of this tbh. What is the goal? Create a system installable package that can set up the dll-overrides for a given WINEPREFIX running the setup_dxvk.sh script?
I'm kinda slow when understanding stuff tho, but are happy to take information on a spoon-fed-for-dummies approach :)

The purpose is simple, to be able to reduce clutter and place *.dll and *.so in the same directory, let's say dxvk/lin64 (and dxvk/lib32 for 32-bit variants). While placing just a single installation script in dxvk/bin, that could properly handle both 64-bit and 32-bit prefixes.

So the package_release.sh script should build both mingw-w64 and winelib in one go? Cos using dxvk/lib64 vs. todays dxvk/x64 (and lib32 vs x32) seems kind of moot point of changing scripts to me, unless you want to make a new script that builds both winelib and mingw-w64 at the same time.. in the same folder.. keeping both the .verb script for winetricks AND a separate installscript in dxvk/bin

I'm not using package_release.sh really, but yeah, I commonly simply build all 4 (mingw and winelib, each 64 and 32-bit), and then place them like above:
dxvk/lib64 - all 64 bit libs
dxvk/lib32 - all 32 bit libs
dxvk/bin - utils (dxvk install script).

The problem is not with lib / x, but with dlls ending in bin right now.

Building with the script is quite nice tbh, so i would recommend to do that. Don't see the point in messing with meson build options or stuff like that, if you can use the script to do what you want?
Tossed together a "multi-script" that would build both if no options given.
echo "Usage: package-release.sh version destdir [--no-dll] [--no-winelib] [--no-package]"
Take a look at it. Puts the dxvk_install.sh script in dxvk/bin folder.
The install script itself needs to be looked at to get it working ofc, but that should be equally doable i guess, so you can set options if you want winelib dll.so's symlinked or whatnot.
package-release.sh.gz

Thanks, I'll take a look. I got the impression there is no way to control where dlls are placed (they always go in bin) during the meson build phase itself.

Ah, then i misunderstood you, cos you mentioned winelib build earlier, so i thought you were messing with that. Most ppl use the included package-release.sh script i guess, and that just moves the files from the "prefix" folder.
So, if you use meson --cross-file build-win64.txt --buildtype release --strip --libdir=lib --prefix $HOME/dxvk build.w64 the dll's are being put in /bin, and the .a files are being put in /lib.
Yeah, that was unexpected. Using prefix $HOME/dxvk/lib64 and --lib=lib64 will put everything in the lib64 folder INCLUDING the setup_dxvk.sh script.
Yeah, as i said in an earlier post: I need to be spoon-fed-for-dummies what ppl are trying to do :+1:
I think mingw-w64 looks at .dll files as "bin", as they are not libraries perhaps? In the "windows world" the .dll files many times gets put in the same folder as the .exe, and thus MIGHT be considered as "bin".. dunno, but it would not surprise me if the logic behind dll's always being put in the --bindir folder is due to something like that.

Well, dlls are as much libraries as .so are. Same dynamic loading idea. But if you meant that package-release.sh can shuffle them in the final result from bin to libdir, that's good enough of course.

That is a script, so you can make that do whatever you like.
I wonder tho, if there might be some install_dir tinkering in meson.build file to make this happen perhaps? If not set, it will use "default behavior" and i guess that is to put dll's into /bin. But i dont really know much about meson or most things :)

Ah well.. You have to add:
install_dir         : get_option('libdir'),
to the meson.build files for d3d11, d3d10, dxgi , and then specify --libdir= like this:
meson --cross-file build-win64.txt --buildtype release --strip --libdir=lib64 --prefix $HOME/dxvk build.w64
meson --cross-file build-win32.txt --buildtype release --strip --libdir=lib32 --prefix $HOME/dxvk build.w32
That should put the dll's (and the .a files) in the --libdir= folder of your choosing.
The meson.build file in d3d10 need this for all the dll's sections, so should be 3 (d3d10, d3d10_1 and d3d10core).
@doitsujin This will break the current script tho, but is this something to be considered? Perhaps get away with the whole cp "$DXVK_BUILD_DIR/install.$1/bin/..... section of the script, as the files are put in the correct spot. Using --libdir=x$1 in the script would keep the current file placement intact for any winetricks verbs or whatnot in use, so it would not be a huge difference to the end-result.
If its something you would consider, i can put up a PR with changes, but if you deem its of no interest, @shmerl have gotten his answer for personal tinkering.

@shmerl If you want to fiddle with it, you can apply this patch in the dxvk folder:
dxvk_build.patch.gz
You can either use the above meson lines, or try out the "multi-build" script.

The current behavior can be kept, by introducing an optional parameter, for example dlldir. If it's set, install_dir can be assigned to that, and if not, it can be assigned to current default bindir. This way @doitsujin's workflow can be kept, and custom location can still be set during build with -Ddlldir=lib64 for example.

If the --libdir= is not used, the "default" behavior is to the /bin folder. No need to introduce a new parameter.
So i guess the easiest would be to set install_dir in the meson files, and not specify --libdir= when building to keep things as it is. So one would have the option to change if needed perhaps?
Took a quick look at the setup_dxvk.sh script, and it only has the option to install to either x86 or x86_64 by manual change. This could be optimized so it actually install both 32bit and 64bit when you have a 64-bit prefix.
The package-release.sh script does not keep the /bin folder with the setup_dxvk.sh script in its current form tho, as its not copied over. Probably oki, as its not working that well anyway.

It's working quite fine for me. To enhance it, it should autodetect the architecture from the registry in the prefix (or WINEARCH variable), and the also should allow setting winelib flag externally instead of hardcoding it. Plus it should know how to name both 64 and 32-bit libdirs. Doing that it would be able to handle all cases without modifications to the script itself.

Tried to look at creating a setup_dxvk.sh script suiting both 32 and 64-bit prefixes, but i dont have the l33t skillz enough to get it working properly...
The reason why it defaults to installing it in each /bin folder, is cos it creates 2 scripts, 1 for each of the arch's when creating overrides and symlinks. The ideal would be as outlined above - the dll's/dll.so's get put in the x32/x64 folders, and 1 dxvk_setup.sh script in the /bin folder.
There is ofc ways of detecting if its a 32 or 64 bit prefix by using winepath and distinguising between system32 and syswow64, but as i said, my scripting skills is lacking in the manner of making the symlinks point to their respective arch version of dll's was not trivial (for me).
In a 32-bit wineprefix, c:\windows\system32 is the folder for 32-bit symlinks to x32/*.dll.so, but in a 64-bit wineprefix, c:\windows\system32 should point to 64-bit x64/dll.so's, and c:\windows\syswow64 to x32/.dll.so. Combining this in a single script with detection is probably easy for someone but me...
#!/bin/bash

WINESYSDIR=$( winepath -u c:\\windows\\system32 )
if [[ ${WINESYSDIR} == *"/system32" ]]; then
  echo "Prefix is 32 bit"
  # do 32 bit stuff here...
elif [[ ${WINESYSDIR} == *"/syswow64"* ]]; then
  echo "Prefix is 64 bit"
  # do 64 bit stuff here...
else
  echo "Unknown wine architecture"
fi

WINEPREFIX=/yourprefix ./script_above.sh
will figure out if its a 32 or 64 bit prefix...

You don't need to wrangle paths, just check the explicit wine arch, and assume that's the set of libraries you need.
See how such detection is done here.

I'll get back to this a bit later.

Tinkered a bit with it.. with the little knowledge i have.. but came up with a working script that detects if the WINEPREFIX is a x86, or a x86_64 one, and create links accordingly.
Added option -winelib if you want to symlink to the dll.so's. If the option is omitted, normal symlinking to .dll happens.
eg.
WINEPREFIX="/your/wine/prefix" ./setup_dxvk.sh install -winelib
Assuming its run from the dxvk/bin folder, and the dll's and dll.so's are located in their respective x32 and x64 folders. (Ref. my previous patch above).
You can take a look at it.
setup_dxvk.sh.gz

I think using wow64 directories isn't always a good idea, since not every wine is WoW variant. I.e. you can have 64-bit prefix without wow64 I think. The best way is to read wine configuration from $PREFIX/system.reg. It would have either of these two:
For 64-bit:
#arch=win64

For 32-bit:
#arch=win32

Also, taking in account WINEARCH variable makes sense (if it's set). The function I linked above does exactly that.

No, you cannot have a x86_64 bit wineprefix without c:\windows\syswow64 This started when XP first came with 64-bit versions afaik.
So, if you create a 64-bit wineprefix with a recently modern wine (2.x+) this WILL happen.
The reason for fiddling with the syswow64 and system32 folders, is not to "detect wine arch", but to actually create 32 and 64 bit links in the correct place. You WILL run into problems if you put symlinks to 32-bit dll's in the c:\windows\system32 folder on a 64-bit WINEPREFIX.
Dont intermingle "WoW" with wow64 and syswow64 :) WoW = World of Warcraft, wow64 = ?, syswow64 = 32-bit in a 64-bit windows installation. (Although the logic behind that med me fumble my first dxvk install a wee bit back).
http://www.samlogic.net/articles/32-64-bit-windows-folder-x86-syswow64.htm

WOW64 stands for Windows on Windows 64-bit (a weird name, I know).
Anyway, presence of directory is not a good indicator, even if it was created. For instance, you can make a 64-bit prefix, and convert it to 32-bit prefix. The directory can still be lingering around. But the value in system.reg should be always correct.

Probably best to read it from registry for those cases where ppl do things they are not supposed to, but i would not choose to use a perl scrip to do that tho. Not sure how i get wine to output that through regedit?

That script you linked searches for win64 in the registry, and there are loads. And i guess if you convert from 64 -> 32 bit somehow, this may be lingering anyway.
However
WINEPREFIX="/your/wine/prefix" wine reg QUERY "HKLM\System\CurrentControlSet\Control\Session Manager\Environment" /v PROCESSOR_ARCHITECTURE
Will read out
PROCESSOR_ARCHITECTURE    REG_SZ    x86 on 32-bit wineprefix, and
PROCESSOR_ARCHITECTURE    REG_SZ    AMD64 on a 64-bit wineprefix.
Might be useful?

Test this
setup_dxvk.sh.gz

Probably best to read it from registry for those cases where ppl do things they are not supposed to, but i would not choose to use a perl scrip to do that tho. Not sure how i get wine to output that through regedit?

You can use it with pure bash. Bust read the file and catch regexes using something like
[[ "$line" =~ $regex ]]

Using perl is just neater for that case, because I like Perl regex syntax a lot more. At least it's not any worse than using sed which is also an external tool.

If you don't want to manually fish out special comments from the registry file, this also works interestingly:
WINEPREFIX=<prefix> wine reg query 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment' /v 'PROCESSOR_ARCHITECTURE'

That's what it gives me:
64-bit prefix:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment
    PROCESSOR_ARCHITECTURE    REG_SZ    AMD64

32-bit prefix:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Environment
    PROCESSOR_ARCHITECTURE    REG_SZ    x86

You can test my latest script updates on my github repo https://github.com/SveSop/dxvk.git
echo "Usage: package-release.sh version destdir [--winelib] [--no-package]"
eg
./package_release.sh git $HOME/winestuff --no-package
This will build dxvk as mingw-w64 dll's and put the dxvk_git folder in $HOME/winestuff
In dxvk_git/bin you have setup_dxvk.sh that will install or uninstall + create overrides for your WINEPREFIX. It detects arch by checking registry, and it does a wineboot -u to recreate any missing fake-dlls and so on.
eg.
WINEPREFIX="$HOME/.wine" ./setup_dxvk.sh install
If you build dxvk with eg:
./package_release.sh git $HOME/winestuff --winelib --no-package
It will create the same folder as above, but with the dll.so winelibs instead.
The script works in the same manner, as it will create symlinks for dll.so. (eg. d3d11.dll -> d3d11.dll.so symlink).
Result: We would have 1 buildscript that you can choose to build mingw-w64 dll's, or winelib dll.so AND it is 1 script that creates symlinks and dll-overrides depending on if its a winelib build or mingw-w64 build. The winetricks .verb is not changed.
@doitsujin Is this something to consider? Take a look if you have the time to it. Foldernames and everything is the same, and buildoptions is the same, exept if you choose to give it --winelib as an option to make it build winelib dll.so.

Result: We would have 1 buildscript that you can choose to build mingw-w64 dll's, or winelib dll.so AND it is 1 script that creates symlinks and dll-overrides depending on if its a winelib build or mingw-w64 build

Can it create it for both? My idea was to place both winelib and mingw libraries in once place, and use a single script to manage them all (depending on some set environment variable or script parameter).

It can be modified so it builds both versions - winelib and mingw-w64 and put them in the same place, and then the install script to take a parameter for what you want?
eg.
setup_dxvk.sh install winelib or setup_dxvk.sh install dll
Something like that?

Oki - https://github.com/SveSop/dxvk/commit/5b4c3b769942b3c178332065a2eef6298370d519
Buildscript with the following options:
Usage: package-release.sh version destdir [--no-winelib || --no-dll] [--no-package]
If nothing is specified eg:
./package-release.sh git $HOME/winestuff --no-package
Both mingw-w64 dll's and winelib dll.so's are being built and placed in their respective x32/x64 folders. You can then opt-out of building one of them if choosing --no-dll or --no-winelib
Installscript with the following option:
Usage: $0 [install|uninstall] [dll|winelib] [-q|--quiet] [-y|-n]
eg
./dxvk_setup.sh install dll will create symlinks + overrides for dll's
./dxvk_setup.sh install winelib will create symlinks + overrides for dll.so's
Installscript only gets built via meson.build to be placed in the /bin folder. No other arguments passed. If different 32/64 bit lib dirs are to be used - other than x32 and x64 it might hamper already used winetricks verb and other stuff, so i did not change this.... so far x32 and x64 will have to do.

It can be modified so it builds both versions - winelib and mingw-w64 and put them in the same place, and then the install script to take a parameter for what you want?
eg.
setup_dxvk.sh install winelib or setup_dxvk.sh install dll
Something like that?

Yes, something of the sort.

There are some issues with doing this tho. One is that changing the meson.build files will make ppl need to update buildscripts I think. PKGBUILD scripts that build without the --libdir= statement will face issues and needs updating.
The other problem is that I don't know any way to combine both x86 and x86_64 builds into making 1 setup_dxvk.sh script. As it is now, it builds the script twice, but since i don't import any settings really, it works fine, but it SHOULD use the build --libdir= statement, cos if you build manually and dont use the package-release.sh it will fail.
There is nothing stopping you from doing a manual meson build with --libdir=winedll_AMD64 or whatever, and the setup_dxvk.sh script will not pick this up cos its hard-coded to x32/x64. This is a problem.
Importing the libdir statement when building works, but you would need to have 2 install scripts (like before), due to the script being created depending on what is being built, and overwritten when building for another arch.
I dunno the best solution tho. Will see if there is any useful meson options to handle multi-arch builds and settings for this perhaps.

The problem is not standard names, cos in a way meson already uses that if not specified, and it seems distro related. Thats why on Ubuntu you end up with a libdir like x86_64-linux-gnu and i386-linux-gnu. However the latter is not used, cos you are not actually compiling under i386 when crosscompiling, so meson will just use x86_64-linux-gnu for both 32 and 64 bit lib/dll's. If you use chroot or other means of compiling under an ACTUAL i386 (32-bit) arch, it will be correct.
The problem is that we compile 2 times, and i dont know how to "import" other values, other than possibly reading some sort of variable from the "previous compile" or something.
Cross-compiling works like this atm:

Compile 64-bit cross-compile file: build-wine64.txt -> Uses variables to generate bin/setup_dxvk.sh.
Compile 32-bit cross-compile file: build-wine32.txt -> Uses variables to generate bin/setup_dxvk.sh (And overwrite the file).

The only way i can think of generating a setup script working for the settings used to compile the libs is to have meson build this after the others. Perhaps if the meson build would generate a file called "settings_$libarch" or some crap, and then the setup script could read that and use variables from that, such as $libdir and whatnot?

Should no longer be relevant due to the changes in 1.0.


Dependency issues / doesn't play nice with yeoman/bower

I've got a project with quite a few bower packages in it. When I run bower install skeuomorph -S, it injects some redundant stuff:
<script src="bower_components/skeuocard/javascripts/vendor/cssua.min.js"></script>
<script src="bower_components/skeuocard/javascripts/vendor/demo.fix.js"></script>
<script src="bower_components/skeuocard/javascripts/vendor/jquery-2.0.3.min.js"></script>
<script src="bower_components/skeuocard/javascripts/skeuocard.js"></script>
<script src="bower_components/skeuocard/javascripts/skeuocard.min.js"></script>

Not only does it inject the Skeuocard JS file twice (one minified), it also includes jQuery which I've already got in my project. I'm no expert at all with bower, but it seems there's a way to check to see if the project already has jQuery, and if it doesn't, to go ahead and install it.

I definitely agree that it would be ideal to just have one script tag for skeuocard.js. Most people will already have jquery included.

@cameronjroe this doesn't give you just one dependency, but here's what I used to fix the main files problem:
In your bower.json add the following :
  "overrides": {
    "skeuocard": {
      "main": [
          "styles/skeuocard.reset.css",
          "styles/skeuocard.css",
          "javascripts/vendor/cssua.min.js",
          "javascripts/skeuocard.js"
        ]
      }
    }

That said, I'm not planning on using this project but instead a different solution for providing card input as the owner has seemingly moved on.

Cool, thanks for the update.


Checking the updated teiHeader

Dear all,
Could you check the updated versions of the <teiHeader>that has been applied on some of the editions for <witness>, please?  It was mostly focused on providing a more detailed content for <msIdentifier>.
For instance, we started there
<witness xml:id="C">Gebang, Ciburuy, Kropak 22 peti 2c
                  <abbr type="siglum">C
                  </abbr>
</witness>

to go there
<witness xml:id="C">
                  <abbr type="siglum">C</abbr>
                  <msDesc>
                     <msIdentifier>
                        <settlement>Ciburuy</settlement>
                        <collection>Gebang</collection>
                        <idno>Kropak 22 peti 2c</idno>
                     </msIdentifier>
                  </msDesc>
               </witness>

I am not sure to have interpreted all the data correctly and when data were not available, i couldn't fill them.
List of the modified files:

[x] DHARMA_CritEdPurvadhigama
[ ] DHARMA_CritEdSangHyangHayu
[x] DHARMA_CritEdSarasamuccayaVararuci
[ ] DHARMA_CritEdSasanaMahaguru
[x] DHARMA_CritEdSvayambhu

Best,

@arlogriffiths @ajaniak
done!


Add link to contracts pallet

I would also remove the (SEAL) parenthesis, since I don't see any references to SEAL anywhere in the documentation or the pallet page. Is this an old/internal name? Is SEAL an acronym for something?

@hugopeixoto very true. Probably legacy issue.


feat: custom ibc logic

Description
Draft PR for the custom logic implementation for IBC transfers

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] added appropriate labels to the PR
[ ] targeted the correct branch
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Codecov Report

Merging #304 (27add54) into main (130a8d6) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@           Coverage Diff           @@
##             main     #304   +/-   ##
=======================================
  Coverage   17.03%   17.03%
=======================================
  Files          56       56
  Lines       16153    16153
=======================================
  Hits         2752     2752
  Misses      13272    13272
  Partials      129      129

:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!

The vulnerability here in the dependency review warning is a graphql part of the go-ethereum package:
Description
Geth (aka go-ethereum) through 1.13.4, when --http --graphql is used, allows remote attackers to cause a denial of service (memory consumption and daemon hang) via a crafted GraphQL query.

NOTE: the vendor's position is that the "graphql endpoint [is not] designed to withstand attacks by hostile clients, nor handle huge amounts of clients/traffic.

References
https://nvd.nist.gov/vuln/detail/CVE-2023-42319
https://blog.mevsec.com/posts/geth-dos-with-graphql/
https://geth.ethereum.org/docs/fundamentals/security

I don't recommend we wait for this to be fixed by ethereum to merge.


Dance Mode Data Record after interrupt

Hello Alberto,
I would like to recommend an implementation of a record of last seq ranges scanned in dance mode every time that for any reason keyhunt has to me stopped, before exiting it logs in a file last seq values scaned.
Thank you,
Ali G

You can also save the points of the scan module of a sequential range every 5 minutes in Dance mode, and other suitable scans. It will turn out that when it starts, it will rely on the initial file of the traversed path, and in the process, fix the traversed path in a new file in some modes (modules) of the program.


Cannot read property 'requestAd' of null

I want to show an interstitial add, but i'm always getting Cannot read property 'requestAd' of null.
The only thing I'm doing is this
const interstitialAd = useInterstitialAd(
    "ca-app-pub-3940256099942544/1033173712",
    {}
  );

I'm sorry if this is a dumb question. Can someone give me an example or something.

const interstitialAd = useInterstitialAd(null, {});

but if i place in any string for the ad id it will throw
null is not an object (evaluating 'this.nativeModule.requestAd')

+1

I updated changed the test app id in android manifest to my app id and now i get a Maximum Depth Loop.

I solved my problem by switching to this library: https://github.com/ammarahm-ed/react-native-admob-native-ads
You can implement any type of ad with the native ad format.

Try latest version and reopen issue if it does not work.


Added an option to allow fonts to not be packed in an flx file.

Fonts should never be bundled on Fuchsia.

/cc @kulakowski

/cc @jason-simmons

How will you do custom fonts on Fuchsia then?

This really applies only to default fonts that Flutter normally caches and adds. From the look of it adding a font in the manifest should still work.

How is this different from "includeRobotoFonts" then?

Previously we included roboto on iOS but not on Android.  We included the material design icons everywhere.  Perhaps we should have a flag that controls the material design icons specifically.

I changed the flag to be specifically about fonts that Flutter would normally cache itself - new patch coming up soon.

Presumably we do want to pack the Material Design Icons file. That file gets revved, and it's critical that the app run with the version it expects.
In fact honestly I'd say the same about Roboto. Why would the app want to rely on the system fonts?

Why would the app want to rely on the system fonts?

Because the system fonts have been arranged to correspond exactly with the app's needs because the app builds together with the system.

Ah, well, ok, in that one specific case... :-P


Ability to set viewport directly from canvas screen.

On the canvas/preview screen in storybook, users can select the viewport size.  It would be nice to have this feature in dashbook.  Here's an example:

The options provided are:

Reset (default)
Small mobile
Large mobile
Tablet

Selecting a viewport shrinks the canvas viewport size.  I think this helps usability because the developer no longer has to shrink the browser (if they are using chrome) or open devtools.

This is a great idea, and seems fairly easy to implement, gonna try to make it when I get some free time

This is a great idea, and seems fairly easy to implement, gonna try to make it when I get some free time

Just to understand better... We already have a device preview feature. Should this issue be a new button with similar functionality?

I think this issue is already done (and should be closed) in the device preview feature that you mention:

We I think the device preview is missing the ability to add a custom viewport, right now we can only select from a predefined list

We I think the device preview is missing the ability to add a custom viewport, right now we can only select from a predefined list

This issue only mentions a predefined list though?

We could close this if we open a new one then, and track the custom sizes there. Wdyt?

We could close this if we open a new one then, and track the custom sizes there. Wdyt?

Sounds good! And say that #64 fixed this.


Fix messenger i React.MVVM to only call the subscriber once

It now calls the subscriber multiple times. This could be linked to StrictMode in React.

This was related to the withViewModel() that had a missing check in its useEffect() to see if the view model was already instantiated. It now only creates one instance, meaning that subscriptions will only happen once.


Assembly add is being rather inefficient

...I think. I was looking at test coverage stats and noticed something odd in the database3 code. This is never getting executed:
# Re-assign names to assemblies and blocks based on the read-in assemnum. Should
# the name be a param?
for a in groupedComps[Assembly]:
    name = a.makeNameFromAssemNum(a.p.assemNum)
    a.name = name
    a.renameBlocksAccordingToAssemblyNum()

But the blocks have names. The right ones, to boot! Looking more closely, it turns out that their names are getting set in Assembly.reestablishBlockOrder(), which itself is getting called from:
def add(self, obj):
    """
    Add an object to this assembly.

    The simple act of adding a block to an assembly fully defines the location of
    the block in 3-D.
    """
    composites.Composite.add(self, obj)
    obj.spatialLocator = self.spatialGrid[0, 0, len(self) - 1]
    # assemblies have bounds-based 1-D spatial grids. Adjust it to have the right
    # value.
    if len(self.spatialGrid._bounds[2]) < len(self):
        self.spatialGrid._bounds[2][len(self)] = (
            self.spatialGrid._bounds[2][len(self) - 1] + obj.getHeight()
        )
    else:
        # more work is needed, make a new mesh
        self.reestablishBlockOrder()
        self.calculateZCoords()

So it would appear that the "more work" is happening every time we add a Block to an Assembly when composing the reactor from the database. I'm sure we could speed this up if we were to peek ahead, build a mesh, then add all of the blocks, or add all of the blocks without worrying about the mesh and reconcile the axial mesh at the end. Would want to measure to see if this is actually an issue. At the very least, its N^2.
We've toyed around with the idea of addressing things like this with creative use of context managers to permit cheap, repeated mutation of something, then rejigger everything to make sure everything is consistent when we are done. Perhaps this is a good place to put that idea into practice.

We have changed some things in the past ~2 years, and this ticket is no longer relevant.


error: failed to select a version for the requirement clap = "^4.0"

I got this error while trying to build iamb from source and updating the crates.io index:
$ cargo build --release
Updating crates.io index
error: failed to select a version for the requirement `clap = "^4.0"`
candidate versions found which didn't match: 3.2.23, 3.2.22, 3.2.21, ...
location searched: crates.io index
required by package `iamb v0.0.7 (/path/to/iamb)`

I'm running Pop!_OS 20.04 with cargo version 1.58.0
I tried editing cargo.toml and rewrote the clap = {version = "4.0", features = ["derive"]} line to clap = {version = "3.2.23", features = ["derive"]}, but that just gave a similar error to the matrix-sdk dependency. How can I install this program now?

You'll need at least Rust 1.66 to build from source, since I'm using some recently stabliized features of the standard library. You can use rustup to get a more recent, stable Rust release, or you can download a statically linked Linux binary from the v0.0.7 release page.


Process exit called explicitly to end the process

@cloderic I have found a way to kill the client js when having express.
I'm not sure it's the best way, but we can discuss it.

A little violent no? You'd like your dependencies to kil your program?
Maybe we can remove the destroy agent on stop feature instead.

There is another way to do it, we can handle it in the express side.
From the node js doc:
SIGTERM and SIGINT have default handlers on non-Windows platforms that resets the terminal mode before exiting with code 128 + signal number. If one of these signals has a listener installed, its default behavior will be removed (Node.js will no longer exit).
But we can remove this feature in a first time

#47 is the way

Need to update the readme and good


As a user, I should see a clear way to participate in a general discussion

Right now there is no link here:  https://midas.18f.us/projects/4
We could change the title / info on that page if it made sense to
eventually we want this to replace the LinkedIn group

@ultrasaurus is this still actionable? I haven't heard this come up recently.

@dhcole we definitely want a place for feedback -- not sure this is the right place.  I would leave this closed and prioritize having an email address that goes to a group or user voice or something

:+1: tracking that here: https://github.com/18F/midas/issues/920


[FEATURE] Allow listening to AtomReference even with Value or Const usage

Is your feature request related to a problem? Please describe.
The choice between using an AtomReference and AtomEventReference is always a bit difficult.
Usually it's something like

Reference
EventReference

Reading
Has a garanteed value
Doesn't have a garanteed value (but can replay previous one)

Reacting
Can be listened to through GetEvent/GetOrCreateEvent (except on Value/Const usage)
Made to be listened to

I've started to think of Variables simply as Events with base values. No data can guarantee that it will only has either the "reading a value when you need it" use-case or the "waiting for a value to change" use-case.
It can simply state "do I have a default value or not".
But right now if I want an reference that guarantees a default value AND can be listened to, I have a problem.
(current example, I want to set fmod parameter using an AtomReference. I need to update the parameter when it changes, but I also want to read that value when a new audio event starts)
Describe the solution you'd like
If this approach makes sense to you, then you should be able to get an event for any type of variable.
In the case of a "Value" usage, then it should do two things:

replay its value when subscribed to
if the user modified the value from the inspector, emit a value

The API would be harmonized, simply implementing IGetOrCreateEvent for AtomReference
This would cover the "gap" where you need to both read a variable and react to it.
Describe alternatives you've considered
    static E GetFakeEvent<T, E>(T replayValue)
      where E : AtomEvent<T>
    {
      E output = ScriptableObject.CreateInstance<E>();
      // Add replay value to buffer
      output.Raise(replayValue);
      return output;
    }

    public static E1 GetOrCreateEvent<T, P, C, TV, E1, E2, F, TVi>(this AtomReference<T, P, C, TV, E1, E2, F, TVi> reference)
      where P : struct, IPair<T>
      where C : AtomBaseVariable<T>
      where TV : AtomVariable<T, P, E1, E2, F>
      where E1 : AtomEvent<T>
      where E2 : AtomEvent<P>
      where F : AtomFunction<T, T>
      where TVi : AtomVariableInstancer<TV, P, T, E1, E2, F>
    {
      switch (reference.Usage)
      {
        case AtomReferenceUsage.VALUE :
        case AtomReferenceUsage.CONSTANT : return GetFakeEvent<T, E1>(reference.Value);
        default: return reference.GetEvent<E1>();
      }
    }

This does everything except the inspector stuff, and actually implementing the IGetOrCreateEvent interface.
This could only be done by extending or modifying AtomBaseReference (for example with an OnValidate function).
Additional context
Big problem with this idea, is if people expect that directly setting the value will trigger those events.
I'm not exactly sure if it shouldn't trigger them. It could be a lightweight alternative to instancers, but I don't feel comfortable with it.
We could have warning logs if someone modifies those values at runtime after fake events have been created, but that's obviously simply a band-aid.

current example, I want to set fmod parameter using an AtomReference. I need to update the parameter when it changes, but I also want to read that value when a new audio event starts

Why do you need the event? why not just reading the value from the AtomReference every time you need it?
Mixing those two concept does not feel really ideomatic to me.

Because the audio parameter can change at any point, and it feels like a waste to compare to a cached value every frame, before sending the value to the audio engine

it feels like a waste to compare to a cached value every frame, before sending the value to the audio engine

If dereferencing a single pointer is your actual performance concern in a project and not just a micro optimization, I kinda envy you.

My performance concern is with the LateUpdate unity reflection callback every frame, which is what your idiomatic solution implies. But yes, creating a SO for every event ref is not good, though it could maybe be a simple class instead?
TryGetEvent is not a bad idea either. Would be cleaner than checking usage.

My performance concern is with the LateUpdate unity reflection callback every frame, which is what your idiomatic solution implies.

It's not reflection. And in newer unity versions it's exceptionally fast. I was looking into creating a "MonoBehaviourSystem" approach like described here: https://youtu.be/RhU8NZtgYp0?t=551 but the performance gain from this was in my tests barely measurable and sometimes even negative.
Also, it's not what my approach suggests. That is way more dependent on your overall game architecture, but it might be enough to read the value when an adioclip starts playing. Maybe another time when the ingame menu is closed, ......

Notes for a PR: Adding a TryGetEvent method to AtomEventReference

Also, it's not what my approach suggests. That is way more dependent on your overall game architecture, but it might be enough to read the value when an adioclip starts playing. Maybe another time when the ingame menu is closed, ......

The parameter is not the volume, audio parameters in fmod can be anything from footstep material to gunfire distance.
There are still usecases when one may want to both listen to changes, and read a value. But 👍for trygetevent, it's as idiomatic as it gets

My Idea would be, that it will just use the IGetEvent interface if applicable

My Idea would be, that it will just use the IGetEvent interface if applicable

In that case, TryGetOrCreateEvent would be nice too

If we go with TryGetEvent then I don't see a reason to not have TryGetOrCreateEvent. GetOrCreateEvent is already implemented by underlying variable or variable instancer.
Postponing this change to v4.5.0 since it is an addition to the API and hence should be in a minor update.


Integrating with mobile apps

Hello. I'm trying to use this code in mobile app(flutter). My implementation is as following:

Get the voice from mic of the mobile.
Convert voice into udp datagram bytes(in the mobile app).
Make this package receives input as udp datagram bytes instead of audio files.
Process the datagram bytes and send the real time output file to the mobile app.
Any thoughts how to change the code here to make just step 3 happen?

Hi @RahmaYasser,
Yes this would be a nice feature to add and possibly related to torchaudio streams (see #27), which is still in beta.
I would suggest to implement your own audio source by subclassing diart.sources.AudioSource (see here) and use a network library to receive the udp packages and emit them using the stream property (i.e. self.stream.on_next(udp_audio_samples) like in here).
You should also probably overwrite the is_regular method to return False so that OnlineSpeakerDiarization regularizes the stream to 5s chunks and 500ms shift. In the case you're implementing your own pipeline you can do this by calling diart.operators.regularize_stream(duration, step, sample_rate).
You can take diart.sources.MicrophoneAudioSource (see here) as an example to implement this feature because I believe it should be rather similar.
If you're up for it, I would gladly merge a PR including this new audio source.


Implement promotion modals

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

Current dependencies on/for this PR:

main

PR #107

PR #108

PR #113

PR #119

PR #120

PR #121

PR #122   👈

This stack of pull requests is managed by Graphite.


Modifying glue.py to generate valid CloudFormation output for Glue Jo…

Modifying glue.py to generate valid CloudFormation output for Glue Jobs that need to work with an encrypted S3 Bucket. #1724

Thanks! Appreciate the reworked changes.


Some of the filters do not work in Direct API example

Describe the bug
Sepia2, removeWhite and Tint filters do not work in Direct API example.
To Reproduce
Steps to reproduce the behavior:

Go to http://nhn.github.io/tui.image-editor/latest/tutorial-example02-useApiDirect using Google Chrome and open developer console.
Click on Filter
Click on Sepia2
See error Uncaught (in promise) Invalid parameters

Expected behavior
Those filters should work or the API documentation could be updated, if that functionality is not supported anymore.
Screenshots

Desktop (please complete the following information):

OS: macOS catalina
Browser: chrome
Version: 81.0.4044.122

@samutamm I'll handle it. Thx for your report. :)


Candles drawn partially out of chart range

Hi,
I am creating candlestick charts for 6 months of data and sometimes the candles are partially or fully above or below of the chart area. Seems like the price range scaling does not work correctly.  I am using autoscale
priceScale: {
        position: 'right',
        // mode: 2,
        autoScale: true,
    },

Here are three examples:

Here are my other configurations:
 chart.applyOptions({
      handleScroll: {
        mouseWheel: false,
        pressedMouseMove: false,
        horzTouchDrag: false,
        vertTouchDrag: false,
      },
      handleScale: {
        axisPressedMouseMove: false,
        mouseWheel: false,
        pinch: false,
      },
    });

    let candleSeries = chart.addCandlestickSeries({
      upColor: up,
      borderUpColor: up,
      wickUpColor: up,
      downColor: down,
      borderDownColor: down,
      wickDownColor: down,
    });

    var volumeSeries = chart.addHistogramSeries({
      color: 'rgba(150, 150, 150, 0.3)',
      priceFormat: {
        type: 'volume',
      },
      priceLineVisible: false,

    overlay: true,
    scaleMargins: {
      top: 0.8,
      bottom: 0,
    },
  });

How could I prevent this?

Can you share the data you've passed to the library? Quite probably you passed strings instead of numbers in bar's data.

That is not the case as you can see from the data:

That is not the case as you can see from the data:

@epezon so can you please create a repro for that please? I'm afraid that without that we're unable to help with that.

@epezon so can you please create a repro for that please? I'm afraid that without that we're unable to help with that.

@epezon so can you please create a repro for that please? I'm afraid that without that we're unable to help with that.

And the data:

@epezon so can you please create a repro for that please? I'm afraid that without that we're unable to help with that.

And the data:

I can send you a link privately to the api which is called to populate the charts.

I can send you a link privately to the api which is called to populate the charts.


Track what people search for on the site

This is something we may do for all sites in the future but might be easier to do for WordPress as the WordPress site search is more standardized. Basically having a custom event called "Site Search" or something like that and sending all the different things people search for as custom props. Then site owners will have a list of keywords / topics people search for on the site. More details https://github.com/plausible/analytics/discussions/164

+1

We now have a feature that allows you to get search terms so perhaps we can integrate this somehow with the WordPress plugin in the future. See https://plausible.io/docs/custom-query-params

@metmarkosaric any ETA on this? Asking for the project we would like to kickoff end of the month. We're not allowed to use plausible if we dont have a native search integration

hi @masteradhoc! no ETA at the moment unfortunately. we're actively looking for some external help with our WP plugin as we'd like to speed up its development. at the moment, the best way to get search terms would be with this feature. it works very well with the native WordPress search: https://plausible.io/docs/custom-query-params

@metmarkosaric I've got an implementation ready with the custom query param above, will do a pull shortly. But I'm actually wondering if this is the right way to go. Wouldn't it make more sense to:

send a pageview to <example.com>/search/
send an event named "Search" with the value as props, so I'd do:

plausible('Search', {props: {keyword: 'test'}})

That'd make it a lot easier to look at those stats?

nice one @jdevalk, thanks again! @ukutaht is the best person to speak to in terms of how it should work technically. i can see Uku shared some details here on his thinking: https://github.com/plausible/analytics/discussions/164#discussioncomment-2366631

@ukutaht I think the biggest problem is that once I filter by one thing, for instance, resultCount, I can't see the other variables anymore. So I couldn't see keyword when filtering by resultCount == 0:

@ukutaht would be good to get some input on this before continuing with https://github.com/plausible/wordpress/pull/87?

Yes I think the custom event approach proposed by @jdevalk is the best. As he mentioned there's a limitation on filtering/displaying more than a single custom prop at a time. This is a known limitation on the backend that we are planning to address in the future.

Done in #119 above.

This is included in the latest beta of v2.1.0.

Update: Latest version of our WordPress plugin introduces site search tracking. You can see the popularity of different search terms and the number of search results for the individual terms. Special thanks to @jdevalk! Details at: https://plausible.io/wordpress-analytics-plugin


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/31250

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/94573

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/117305


BUG: Using _a/_r/_g/_b on an object with an advanced render class crashes the game

When modifying an object's color using self._a, self._r, self._g and self._b (but not self._color), LuaSTG crashes with no error and no information on the .log file.
Code in image below: (zclass is identical to Class, however, it sets the [".render"] key of the class to true automatically, tests done on the code packaged with the latest release in Github, v0.18.10.)

The engine.log:
engine.log

9534d9b1c55f0f519166b6090d34ab597d870d2b

No response for over 30 days, I will close it


[AIRFLOW-1297] add db name to RedshiftToS3Transfer operator

Dear Airflow maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA
https://issues.apache.org/jira/browse/AIRFLOW-1297
Description

In myredshift I have two different db_name and schema. code copy always schema into db_name which is not flexible.

Codecov Report

Merging #2357 into master will decrease coverage by <.01%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master    #2357      +/-   ##
==========================================
- Coverage   69.47%   69.47%   -0.01%
==========================================
  Files         145      145
  Lines       11070    11072       +2
==========================================
+ Hits         7691     7692       +1
- Misses       3379     3380       +1

Impacted Files
Coverage Δ

airflow/operators/redshift_to_s3_operator.py
0% <0%> (ø)
:arrow_up:

airflow/hooks/postgres_hook.py
90.47% <100%> (+0.47%)
:arrow_up:

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 8e23d28...5f6e5be. Read the comment docs.

@bolkedebruin any update on this?

@hamedhsn Is this still relevant?


Time picker prevents other components from being selected

Wave SDK Version, OS
wave server 0.25.1
h2o-wave 0.25.1
python 3.10.7
windows 10
Actual behavior
The last added ui.time_picker hogs the focus for the form. As long as it was not clicked once, other components cannot be used. One does not have to select a value, just clicking and dismissing the time picker releases the focus and other components become responsive again.
Elements like the dropdown menu flicker briefly, when clicked. So focus seems to go to the dropdown menu for a short time and is then put back on the time picker.
Expected behavior
No component should keep focus from others.
Steps To Reproduce

Run the app below
Try and click on the dropdown menu. It will not show up.
Try and click on the first time picker. It will not show up.
Try and click on the second time picker. It will show up. Select a value or dismiss it.
Now the other 2 components are responsive again.

Refresh the page to restore the flawed state.
from h2o_wave import main, app, Q, ui

@app('/demo')
async def serve(q: Q):
    items = [
        ui.dropdown(name='dropdown', label='Dropdown', value="", width='300px', choices=[
            ui.choice(name='choice1', label='choice1'),
            ui.choice(name='choice2', label='choice2'),
            ui.choice(name='choice3', label='choice3'),
        ]),
        ui.time_picker(name='timepicker', value="", label="Standard time picker"),
        ui.time_picker(name='timepicker2', value="", label="Standard time picker 2"),
    ]
    q.page['example'] = ui.form_card(box='1 1 4 8', items=items)
    await q.page.save()

@marek-mihok please have a look at this as a high prio.

Released 0.25.2 where this should be resolved. @aranvir can you please check it out and let me know if works for you? Thanks!

Works! Thanks for the quick fix, you guys are amazing!


Fix typo in CoC

Fixes #66.

Hi @bterlson, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Brian Terlson). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

lgtm

I'll merge this in once gates pass

Merged in 30afe7bff6737b04cf86234977fad51beeacfe70


ZARRAY data element is not present in library

Some classes and interfaces refers to a data element called ZARRAY that is not present.

Thanks René!


Update README.md to be more explicit that the sh script is not actually optional

Myself and another engineer who are using this plugin found the wording to be a bit confusing and made it seem as if you could just not use the shell script yet still use this plugin. Updated the wording to be a bit less ambiguous on what the purpose of the script is.

Hello @WowSuchRicky,
Thank you for the PR.
I understand how the statement could be misleading. What I meant is that even if you don't run the script to patch the index.html, your web app will still function. The environment values will simply be those present on the computer that ran vite build.
I included this line to inform users that everything will work as expected if they are using Vercel or any other provider that builds the app for you whenever your code changes, instead of using your Docker image. However, I acknowledge that very few people will want to use vite-envs in this context.
I noticed from your profile that you're a Googler. Is Vite-envs used at Google or is it for a side project? Also, how did you discover this project? I'm curious since I haven't promoted it yet. I'm waiting to add support for dynamic base URL (being able to dynamically overwrite BASE_URL).
Best regards,

@garronej thanks for taking a look super fast!
This PR is purely in a personal capacity, nothing to do with Google. I'm very new to react/vite and that whole space and I found this when searching for a way to be able to have environment variables update a vite static build at runtime instead of having to have custom builds for each environment.
Hopefully my wording helped while still keeping the intentions you and the team wanted to provide.


Not Recognizing Characters

Defining a newline string like so

and the printing it using the string syscall

results in this:

if you put the ascii values instead

then it works fine. It seems like Saturn doesn't automatically recognize characters

Woah! Yep \0 isn't considered a break character and instead gets encoded as an actual 0 for some reason.

Added a null terminator escape sequence in 0.1.6. After the build finishes in around ~20 you should be able to pull https://github.com/1whatleytay/saturn/releases/tag/app-v0.1.6 and this code should work. As for character literals though, I recommend using .asciiz!

Closing for the time being (until this feature rebels and decides to not work again).


Upgrade Celery to the latest version

Current Behavior
Celery was downgraded to <4.2.0 due to unstable Scans Upload in #447.
Expected Behavior
We should bring new version of Celery as soon as their maintainers fix this bug.
Tasks to do

[ ] Prepare easy reproduction of this Issue
[ ] Submit a bug/issue with above reproduction to Celery maintainers
[ ] Upgrade Celery to the latest version

New version of Celery seems to be very stable! 💪


UnicodeEncodeError: 'latin-1' codec can't encode character

Full traceback:
Traceback (most recent call last):
File "/home/pybokeh/miniconda3/envs/remi/lib/python3.4/socketserver.py", line 617, in process_request_thread
self.finish_request(request, client_address)
File "/home/pybokeh/miniconda3/envs/remi/lib/python3.4/socketserver.py", line 344, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "test.py", line 10, in init
super(MyApp, self).init(*args)
File "/home/pybokeh/miniconda3/envs/remi/lib/python3.4/socketserver.py", line 673, in init
self.handle()
File "/home/pybokeh/miniconda3/envs/remi/lib/python3.4/http/server.py", line 398, in handle
self.handle_one_request()
File "/home/pybokeh/miniconda3/envs/remi/lib/python3.4/http/server.py", line 386, in handle_one_request
method()
File "/home/pybokeh/miniconda3/envs/remi/lib/python3.4/site-packages/remi/server.py", line 552, in do_GET
self.process_all(path)
File "/home/pybokeh/miniconda3/envs/remi/lib/python3.4/site-packages/remi/server.py", line 572, in process_all
self.wfile.write(encodeIfPyGT3(html))
File "/home/pybokeh/miniconda3/envs/remi/lib/python3.4/site-packages/remi/server.py", line 90, in encodeIfPyGT3
data = data.encode('latin-1')
UnicodeEncodeError: 'latin-1' codec can't encode character '\u2020' in position 20239: ordinal not in range(256)
My code:
import remi.gui as gui
from remi import start, App
import pandas as pd
from db import DB

# import ipdb; ipdb.set_trace()

class MyApp(App):
    def __init__(self, *args):
        super(MyApp, self).__init__(*args)

    def main(self):
        wid = gui.Widget(1200, 800, gui.Widget.LAYOUT_HORIZONTAL, 10)

        db = DB(filename="/home/pybokeh/Dropbox/data_sets/nba", dbtype="sqlite")

        column_names = [column.name for column in db.tables.player_game_stats._columns]

        row_data = db.query("select * from player_game_stats where team_name like '%Cav%'").values

        self.table = gui.Table(600, 400)

        row = gui.TableRow()
        for column in column_names:
            item = gui.TableTitle()
            item.append(str(id(item)), str(column))
            row.append(str(id(item)), item)

        self.table.append(str(id(row)), row)

        for _row in row_data:
            row = gui.TableRow()
            for row_item in _row:
                item = gui.TableTitle()
                item.append(str(id(item)), str(row_item))
                row.append(str(id(item)), item)

                self.table.append(str(id(row)), row)

        wid.append('1', self.table)

        return wid

if __name__ == "__main__":
    start(MyApp)

If I limit my query to return just 5 rows, I do not get an error.   So it seems there is a character that it doesn't like somewhere in the other rows in my table.
Using virtual environment created with conda with python version 3.4.
My platform:
import platform
print(platform.platform())

Linux-3.13.0-68-generic-x86_64-with-debian-jessie-sid
Installed python libraries:
import pip
modules = pip.get_installed_distributions()
for m in modules:
    print(m)

setuptools 18.4
prettytable 0.7.2
ptyprocess 0.5
ipython 4.0.0
ipython-genutils 0.1.0
PyMeta3 0.5.1
numpy 1.10.1
traitlets 4.0.0
wheel 0.26.0
python-dateutil 2.4.2
pandas 0.17.0
pexpect 4.0.1
simplegeneric 0.8.1
pybars3 0.9.1
decorator 4.0.4
ipdb 0.8.1
pytz 2015.7
six 1.10.0
pickleshare 0.5
remi 0.1
db.py 0.4.4
pip 7.1.2
path.py 8.1.2
Regards,
Daniel

To make it work for me, I changed line 90 in server.py from:
data = data.encode('latin-1')

to
data = data.encode('utf-8')

I'm not a developer and only have intermediate Python knowledge.  So not sure if this is the proper solution or if it works with Python 2.X also.

Hi pybokeh. First of all thank you for your exhaustive report. I'm unable to reproduce the error and furthermore, the code line you changed applies only to python version less than 3. Considering you are working with 3.4, the encoding you changed should not take effect.
Maybe the detection of python version on your enviroment is faulty?
May I ask you to do this test?
import sys
sys.version_info < (3,)

@dddomodossola
import sys
sys.version_info < (3,)

It outputs "False"

@dddomodossola
My sample NBA sqlite3 database can be downloaded from here  There is a cross symbol † in the player name.  This cross symbol is apparently the character that is causing problems.

@pybokeh
Yeah, I've seen. Your solution to the problem works fine, but I'm trying to solve this also for version less than 3.

@pybokeh
Now should be fixed. Can you run your example with python2.7 ?
Thank you so much for your help.

Error: UnicodeEncodeError: 'ascii' codec can't encode character u'\u2020' in position 14: ordinal not in range(128)
full traceback:
Traceback (most recent call last):
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/SocketServer.py", line 599, in process_request_thread
self.finish_request(request, client_address)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/SocketServer.py", line 334, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "test.py", line 10, in init
super(MyApp, self).init(*args)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/SocketServer.py", line 655, in init
self.handle()
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/BaseHTTPServer.py", line 340, in handle
self.handle_one_request()
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/BaseHTTPServer.py", line 328, in handle_one_request
method()
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/server.py", line 552, in do_GET
self.process_all(path)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/server.py", line 562, in process_all
self.client.root = self.main(*self.server.userdata)
File "test.py", line 62, in main
item.append(str(id(item)), str(row_item))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2020' in position 14: ordinal not in range(128)
I installed remi via pip:
pip install git+https://github.com/dddomodossola/remi.git
So I'm assuming your latest patch was implement.
Python version 2.7.10 virtual environment installed with conda.

The problem seems to be the str() conversion you are doing. Should be:
item.append(str(id(item)), row_item)

My database query can return data that are of type int.  So herein lies the problem.  Your item.append() calls the html conversion code which calls s.repr() method.  An int doesn't have repr().  That is why I am forced to convert the table item to str.
Below is the traceback when I don't ensure the table item is of type str:
Traceback (most recent call last):
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/SocketServer.py", line 599, in process_request_thread
self.finish_request(request, client_address)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/SocketServer.py", line 334, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "test.py", line 10, in init
super(MyApp, self).init(*args)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/SocketServer.py", line 655, in init
self.handle()
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/BaseHTTPServer.py", line 340, in handle
self.handle_one_request()
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/BaseHTTPServer.py", line 328, in handle_one_request
method()
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/server.py", line 552, in do_GET
self.process_all(path)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/server.py", line 571, in process_all
html = self.client.root.repr(self.client)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 196, in repr
return super(Widget,self).repr(client, include_children)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 97, in repr
innerHTML = innerHTML + s.repr(client)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 196, in repr
return super(Widget,self).repr(client, include_children)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 97, in repr
innerHTML = innerHTML + s.repr(client)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 196, in repr
return super(Widget,self).repr(client, include_children)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 97, in repr
innerHTML = innerHTML + s.repr(client)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 196, in repr
return super(Widget,self).repr(client, include_children)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 97, in repr
innerHTML = innerHTML + s.repr(client)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 196, in repr
return super(Widget,self).repr(client, include_children)
File "/home/pybokeh/miniconda3/envs/remipy2/lib/python2.7/site-packages/remi/gui.py", line 97, in repr
innerHTML = innerHTML + s.repr(client)
AttributeError: 'int' object has no attribute 'repr'

You can do something like this:
item.append( str(id(item)), u"%s" % row_item )

Thanks that worked.  I'll have to do some studying on encodings.  :-)

It's the same for me ;-)
Thank you for the information you reported in this issue, you helped me a lot improving remi.


replace AgentType.sim_one_period with a generic Monte Carlo simulator that consumes equations

This can more explicitly take in equations, and be removed to a HARK.simulation.monte_carlo module
https://github.com/econ-ark/HARK/blob/master/HARK/core.py#L432-L479
This will help with the whiteboard problem #889
cf. #1292

The FrameAgentType was an attempt at this. The problem with it, noted by @mnwhite , is that the configuration of the FrameAgentType is too complex.
https://github.com/econ-ark/HARK/blob/master/examples/FrameAgentType/FrameModels.ipynb
Something simpler, like a dictionary of lambdas, would be easier to read and write.

Here's the off-the-top-of-my-head draft of a format to specify the mechanics of ConsIndShock:
inter = [aNrm, pLvl]
control = [cNrm]
discrete = []
exog = [psi, theta]
param = [gamma, omega, R, J]
dynamics = [
    G = gamma*psi,
    Rnrm = R / G,
    bNrm = aNrm / Rnrm,
    mNrm = bNrm + theta,
    cNrm = policy(mNrm),
    aNrm = mNrm - cNrm,
   die(omega),    old = j >= J,
   die(old)    ]`
auxiliary = [
    pLvl = G*pLvl,
    mLvl = mNrm*pLvl,
    cLvl = cNrm*pLvl,
    aLvl = aNrm*pLvl,
    MPC = policy.der(mNrm)
    ]
The simulator should be able to take a statement like this and implement it. The inter variables specify what must exist for an agent when it is initialized. The control variables specify the variables that the simulator should expect to exist, probably named like cNrmFunc or stored in policy['cNrm'].
The discrete variables are those that the code should expect to be whole numbers, not continuous values, which might matter for evaluating policy(d, mNrm) where d is discrete.
The exog variables name variables that come from some process exogenous to the agent-- maybe RVs, maybe chosen by someone else, maybe an aggregate. The code just needs to know to expect to be given some way to get or generate things named in exog, which will not be found within dynamics.
Variables named in param are parameters to be pulled from the agent's data, common to a "type". Whether or not each one is time/age-varying is irrelevant for the mechanics of the model. Each instance of an AgentType using this model can specify its own vary list to indicate how parameters should be looked up. In our standard ConsIndShock lifecycle model, omega and gamma would be in vary, while R and J would not.
Note what's not here: state variables. It might be that we need to name the variables that are used as "states" in the sense of "inputs to a policy function", but it might be enough to have them implicit in the dynamics statement.
The statements in dynamics should be self-explanatory. It's a start to finish description of what happens to each agent in one period. The parameter J is the maximum age beyond which an agent can't live.
The contents of auxiliary are optional variables that can be computed along the way, but don't need to be as a required part of simulating the model. Each of these lines would be executed if and only if the accompanying variable is requested in track, with dependencies automatically generated and handled.
There are some additional complications for things like jointly determined variables, but those don't appear in any of our models so far.

Oh, and j is used to mean "age". There would also be t for absolute time, if needed.

Ok, I think it's possible to move incrementally in this direction.
The hardest part is the Python object for equations, I think.
I've got a few aesthetic quibbles but let's start getting the functionality in.
I think I can get part of the way there with #1292 and refactoring the Frame code, as discussed.

I very much hope that @William Du @.***> 's implementation of the
"shuffling" method is included in the generic Monte Carlo simulator.
On Thu, Jun 29, 2023 at 1:07 AM Sebastian Benthall @.***>
wrote:

Ok, I think it's possible to move incrementally in this direction.
The hardest part is the Python object for equations, I think.
I've got a few aesthetic quibbles but let's start getting the
functionality in.
I think I can get part of the way there with #1292
https://github.com/econ-ark/HARK/pull/1292 and refactoring the Frame
code, as discussed.
—
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/issues/1295#issuecomment-1612223273,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKCK76WDRCLQDI4PIAIMMTXNS2K3ANCNFSM6AAAAAAZXOKJ5A
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

--

Chris Carroll

dynamics = [
 G = gamma * psi,
 Rnrm = R / G,
 bNrm = Rnrm * aNrm,
 mNrm = bNrm + theta,
 cNrm = policy(mNrm),
 aNrm = mNrm - cNrm,
 die(omega),
 old = j >= J,
 die(old)
 ]

As we've discussed, one tricky part about this proposal is the syntax for these sorts of 'equations'.
Without a symbolic library, it's hard to do this very cleanly in Python.
This commit is the most lightweight way I can think of doing this without a symbolic library:
https://github.com/econ-ark/HARK/pull/1292/commits/d09eb303ebc01d85cd8e5c00d875b4384830a6ee
It is possible to use inspect.signature to pull out the parameter names and bind them in simulation.
https://docs.python.org/3/library/inspect.html#inspect.signature

I'm not attached to anything about the notation, especially specifics. This
was more about specifying what is the kind of information specifies the
basic consumption saving model's mechanics, up to distributional and/or
functional assumptions (other than basic accounting arithmetic).
My general point was that it's a very "light" set of information, human
readable, and easy-ish to interpret. The programming of how that gets
passed into Python is a different question.
On Fri, Jun 30, 2023, 3:24 PM Sebastian Benthall @.***>
wrote:

dynamics = [
G = gamma * psi,
Rnrm = R / G,
bNrm = Rnrm * aNrm,
mNrm = bNrm + theta,
cNrm = policy(mNrm),
aNrm = mNrm - cNrm,
die(omega),
old = j >= J,
die(old)
]
As we've discussed, one tricky part about this proposal is the syntax for
these sorts of 'equations'.
Without a symbolic library, it's hard to do this very cleanly in Python.
This commit is the most lightweight way I can think of doing this without
a symbolic library:
d09eb30
https://github.com/econ-ark/HARK/commit/d09eb303ebc01d85cd8e5c00d875b4384830a6ee
It is possible to use inspect.signature to pull out the parameter names
and bind them in simulation.
https://docs.python.org/3/library/inspect.html#inspect.signature
—
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/issues/1295#issuecomment-1615104403,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKRAFMK7SSFNHZVDHAXDUTXN4RWBANCNFSM6AAAAAAZXOKJ5A
.
You are receiving this because you were mentioned.Message ID:
@.***>

Got it. Please see #1296 for an example implementation.

Passed --> parsed. Ducking autocorrect.
On Fri, Jun 30, 2023, 4:14 PM Sebastian Benthall @.***>
wrote:

Got it. Please see #1296 https://github.com/econ-ark/HARK/pull/1296 for
an example implementation.
—
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/issues/1295#issuecomment-1615150101,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADKRAFMP4ZMWCSV5AADWDK3XN4XSHANCNFSM6AAAAAAZXOKJ5A
.
You are receiving this because you were mentioned.Message ID:
@.***>


Run Arbitrary Flag (E.g., gulp --production)

Issue title pretty much says all I am requesting. Would love to be able to use my environment variables instead. I have a bunch:
gulp --production
gulp --staging
gulp --staging --force-all
gulp --whatever
Etc.
Can you loosen the pre-packaged "Run Arbitrary Task" command to simply "Run Arbitrary Command" or "Run Arbitrary Task/Flag" and allow flags in that as well?

Hi!
You mean picking up flags on the settings file for commands on Run Arbitrary Task?
(if I understood correctly) it's not a bad idea! the problem is that there's a lot of people using the package already and that type of change could get me a lot of hate :P. But, I like the idea of adding a Run Arbitrary Command (leaving Run Arbitrary Task be).
Let me think about it a bit more, I'm quite busy at the moment but I'll get to it as soon as I get some time.
Thanks!

No problem, I've also followed your steps to creating a custom item in the
Tools menu for the time being which works nicely as well for specific tasks
with flags that I've created.
On Wed, Jan 4, 2017 at 10:30 AM, Nicolás Santángelo <
<EMAIL_ADDRESS>wrote:

Hi!
You mean picking up flags on the settings file for commands on Run
Arbitrary Task?
(if I understood correctly) it's not a bad idea! the problem is that
there's a lot of people using the package already and that type of change
could get me a lot of hate :P. But, I like the idea of adding a Run
Arbitrary Command (leaving Run Arbitrary Task be).
Let me think about it a bit more, I'm quite busy at the moment but I'll
get to it as soon as I get some time.
Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NicoSantangelo/sublime-gulp/issues/77#issuecomment-270415829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABXv4_IKGj36_KnicNyclDtQF09wLkgFks5rO8lBgaJpZM4LZWc_
.


Implement stratification in SemiNaiveExecutionEngine

This PR is based on #27 and adds stratification to the SemiNaiveExecutionEngine. It includes the following changes:

[x] def solve(rId: RelationId) now uses the strongly connected components from the PrecedenceGraph to compute the relations.

(now in #29)


ARROW-15939: [Python] Add pickle support for JSON options classes

Use Scenario:
I was using ray.data.read_json to read json data source, in while i got error says that pyarrow.json.ReadOptions & pyarrow.json.ParseOptions does not support pickling so the task could not be passed between workers.
Goal:
Support pickling options class for json.

I think it was because the CSV options arguments are keyword-only, so it was easier to spell out __getstate__/__setstate__.


Next.js build fails because npm command is not found

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

App Id
d1patyqgasciau
Region
us-east-1
Amplify Console feature
Build settings
Describe the bug
When building the app, I'm getting an error that the app can't build
Expected behavior
I want to run npm install && npm run build:preview to build the next js app
Reproduction steps

npm install
npm run build:preview

Build Settings
version: 1
frontend:
  phases:
    preBuild:
      commands:
        - rm -f ./.npmrc
        - nvm use --delete-prefix v12.21.0 --silent
        - . /root/.nvm/nvm.sh
        - nvm install 14.15.1
        - echo "@**********:registry=https://npm.pkg.github.com/" > ./.npmrc
        - echo "registry=https://registry.npmjs.org" >> ./.npmrc
        - echo "//npm.pkg.github.com/:_authToken=***************************" >> ./.npmrc
        - npm install
        - export NODE_OPTIONS='--max_old_space_size=4096'
    build:
      commands:
        - npm uninstall eslint && npm install --save-dev<EMAIL_ADDRESS>        - export NODE_OPTIONS='--max_old_space_size=4096'
        - npm run build:preview
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

Additional information
No response

Excerpt of Build Log
2021-12-13T17:33:57.532Z [WARNING]: Failed to compile.
2021-12-13T17:33:57.536Z [WARNING]: ./src/pages/404.js
                                    4:5  Warning: Unexpected console statement.  no-console
                                    ./src/pages/_document.js
                                    27:1  Warning: Unexpected default export of anonymous class  import/no-anonymous-default-export
                                    61:21  Warning: External synchronous scripts are forbidden. See: https://nextjs.org/docs/messages/no-sync-scripts.  @next/next/no-sync-scripts
                                    62:21  Warning: External synchronous scripts are forbidden. See: https://nextjs.org/docs/messages/no-sync-scripts.  @next/next/no-sync-scripts
                                    63:21  Warning: External synchronous scripts are forbidden. See: https://nextjs.org/docs/messages/no-sync-scripts.  @next/next/no-sync-scripts
                                    64:21  Warning: External synchronous scripts are forbidden. See: https://nextjs.org/docs/messages/no-sync-scripts.  @next/next/no-sync-scripts
                                    ./src/pages/_error.js
                                    3:18  Warning: 'statusCode' is missing in props validation  react/prop-types
                                    4:5  Warning: Unexpected console statement.  no-console
                                    15:5  Warning: Unexpected console statement.  no-console
                                    ./src/components/AWSUploader/AWSUploader.test.js
                                    11:45  Error: Extra semicolon.  semi
                                    ./src/components/AWSUploader/index.js
                                    105:13  Warning: 'file' is missing

Hi @chase-pico is this also failing to build locally? I see this error: 11:45  Error: Extra semicolon.  Can you make sure to remove the extra semicolon?

Thanks for the reply! The same repo builds in production, that error on line 11 should be from the linter. Are there any other reasons the build could fail?

@chase-pico The only other error I see is 37:13  Error: Do not use setState in componentDidUpdate in ./src/components/DragIcon/index.js. Outside of that, I'm still investigating what the issue could be.

If you're still having this issue, please feel free to reopen.


Disable autoplay next song, if next song is in different playlist

Hi,
I am having two playlist on one page, I want to automatically play next song if next song is in same playlist.
I don't want to play next song, If it is in different playlist. Is there any way to do that.
I am listening to "'album_change" event and trying to pause it( Amplitude.pause()) but it is not working for me,
Thanks,

This was added in 3.3.


Request: Viber icon

There is no Viber icon somewhy. But Viber is popular messenger in a lot of countries.

Did you personally hit the need of having a viber icon on your website ?

Yes.

thanks


Easee: outdated OP_MODE at startup leads to incorrect charger status

Describe the bug
I have observed during initial negotiation on evcc startup, that the charger actually sends an outdated OP_MODE.
This left evcc with the false information, that the charger was waiting for the car, while the car was actually charging (charge was already ongoing, prior to restarting evcc).
I was able to manually fix this by requesting a poll of the OP_MODE from the charger via the API.
I suggest we put this into the startup sequence when we create the charger to ensure we get an up2date information about the charger's state.
Steps to reproduce
Not sure.
I have seen numerous restarts with charges in flight just work.
Configuration details
N/A

Log details
... this is the ProductUpdate received on evcc startup...
[easee ] TRACE 2023/09/26 17:19:59 ProductUpdate EHWHL6VE: (2023-09-26 12:07:30 +0000 UTC) CHARGER_OP_MODE 6

... and this is the LP date shown the very first interval...

[lp-1  ] DEBUG 2023/09/26 17:20:04 charge power: 1482W
[lp-1  ] DEBUG 2023/09/26 17:20:05 charge currents: [5.99 0.011 0.014]A
[lp-1  ] DEBUG 2023/09/26 17:20:07 charger status: B

... while car is (correctly) detetec as charging...
[lp-1  ] DEBUG 2023/09/26 17:20:08 vehicle status: C

What type of operating system are you running?
Docker container
Version
No response

@andig please assign

Maybe related to https://github.com/evcc-io/evcc/issues/10265#issuecomment-1756309102 (Theory: same underlying issue - wrong op_mode ?)

reopened.
The issue is actually not limited to restarts, but to re-negotiations.
So whenever the signalR connection breaks (which it tends to do from time to time, don't know why), we can get the same problem.
Caught this today. Charge started, evcc showed waiting for car, while 11kW charge was going.
Log shows renegotiation happening immediately after charge start, and then op_mode 7 (waiting for auth) is reported as most recent.
D*** Easse, I really liked this being stable....
@andig I never dove deep into the SignalR stack. Is there a simple way to hook into the negotiation phase somehow, so that I could move the change I introduced into the charger startup into there?

@GrimmiMeloni es wird der Connector aufgerufen:
	client, err := signalr.NewClient(context.Background(),
		signalr.WithConnector(c.connect(ts)),
		signalr.WithReceiver(c),
		signalr.Logger(easee.SignalrLogger(c.log.TRACE), false),
	)

Closing, as this was addressed again by #10907

Reopening this. Apparently the fix in #10907 does not suffice, because of wonky timing. Here's my car connecting yesterday evening. In this case, all the "goodness" comes together. Outdated status on SignalR (re)connect, plus conflicting op_mode state with identical timestamps. The effect was that the charge was happening, but the UI stated "waiting for vehicle".
[easee ] TRACE 2023/12/15 18:32:09 ProductUpdate EHWHL6VE: (2023-12-15 17:32:08 +0000 UTC) CHARGER_OP_MODE 2

--- SIGNALR reconnect

[easee ] TRACE 2023/12/15 18:32:11 ProductUpdate EHWHL6VE: (2023-12-15 17:32:01 +0000 UTC) CHARGER_OP_MODE 7
[easee ] TRACE 2023/12/15 18:32:11 ProductUpdate EHWHL6VE: (2023-12-15 17:32:09 +0000 UTC) CHARGER_OP_MODE 6
[easee ] TRACE 2023/12/15 18:32:12 ProductUpdate EHWHL6VE: (2023-12-15 17:32:10 +0000 UTC) CHARGER_OP_MODE 3
[easee ] TRACE 2023/12/15 18:32:12 ProductUpdate EHWHL6VE: (2023-12-15 17:32:10 +0000 UTC) CHARGER_OP_MODE 6

(Side note, the timestamps in the messages look strange. Ignoring the final update, the sequencing of the op_codes is correct, i.e. 2 -> 7 -> 6 -> 3. However, according to the timestamps, 7 (waiting for auth) happened 7s before the car was even connected.)
What this show is that we need to do the polling more proactively instead of just when the signalR connection is (re)established. The good news is, that we have enough status from the charger to detect inconsistencies. I will prepare a PR.


EasyPororoOCR Integration

Closes https://github.com/junhoyeo/BetterOCR/issues/2

[x] Make basic text detection using EasyOCR, Pororo (EasyPororoOCR), and Tesseract work
[x] Box detection
[x] Refactor structure
[x] Make it optional (i.e. Activate only if lang is en or ko)

TBD: Also support overriding activated engines though options
[x] Dependencies for EasyPororoOCR should also be optional via Poetry groups

[x] Cite original authors
TBD: Use pre-processing logic on other engines too? + Evaluation

Thanks. looks good.


Update "chart view" card

Keep single histogram fed by sample data (https://nercacuk.sharepoint.com/sites/BGSBMGFMAPS/Shared Documents/WP4 - Tool Development/household_histogram.json).

Update card title to "Household dietary supply"

Remove additional example charts

Add additional tab with tabular representation of the data

Add horizontal line across histogram bars to reflect the adequacy threshold value

I think this just needs the last task doing:

Add horizontal line across histogram bars to reflect the adequacy threshold value

I think this just needs the last task doing:

Add horizontal line across histogram bars to reflect the adequacy threshold value

Threshold was already there but the line has now been made more prominent :-)

Threshold was already there but the line has now been made more prominent :-)


Only run JavaScript tests if JavaScript/Vue files have changed

I'm thinking about deleting the JavaScript tests altogether. For now, though, this (running them only when JavaScript/Vue files have changed) should help, maybe enough that it'll be worth keeping the JavaScript unit tests.

This is our biggest speed improvement so far:
https://travis-ci.org/github/davidrunger/david_runger/builds

That's because when we don't run JavaScript tests, we can skip this step (which I've excerpted from the logs for a different branch's previous build):
'bin/webpack --silent' succeeded (exited with 0, took 38.217).
2020-06-11T05:22:08.7586Z pid=8694 wid=W1928 wfid=POTEF4A3B2D773 jid=JSJS5696254890 wf=OrchestrateTests tsk=SetupJs INFO: Done

That step is one of our two webpack compilation steps, the other compilation step being when we build the JavaScript assets for our Ruby tests. One webpack compilation is much faster than two. :)


[BUG] idpy-oidc can't handle as many signature alorythms as cryptojwt

Hello,
I'm currently working on a project wich consists of setting up the solution SATOSA (https://github.com/IdentityPython/SATOSA) to allow translation between SAML and OIDC. I'm using the module satosa_oidcop (https://github.com/UniversitaDellaCalabria/SATOSA-oidcop) which is based on idpy_oidc op features.
On start up, satosa crashed with the following logs :

[2024-05-27 11:18:19,399] [ERROR] [satosa.proxy_server.make_app] Failed to create WSGI app.
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/satosa/proxy_server.py", line 192, in make_app
res1 = WsgiApplication(satosa_config)
File "/usr/local/lib/python3.9/site-packages/satosa/proxy_server.py", line 118, in init
super().init(config)
File "/usr/local/lib/python3.9/site-packages/satosa/base.py", line 45, in init
frontends = load_frontends(self.config, self._auth_req_callback_func,
File "/usr/local/lib/python3.9/site-packages/satosa/plugin_loader.py", line 68, in load_frontends
frontend_modules = _load_plugins(config.get("CUSTOM_PLUGIN_MODULE_PATHS"), config["FRONTEND_MODULES"],
File "/usr/local/lib/python3.9/site-packages/satosa/plugin_loader.py", line 181, in _load_plugins
instance = module_class(callback, internal_attributes, module_config, base_url,
File "/usr/local/lib/python3.9/site-packages/satosa_oidcop/idpy_oidcop.py", line 594, in init
self.app = oidcop_app(conf)
File "/usr/local/lib/python3.9/site-packages/satosa_oidcop/core/application.py", line 23, in oidcop_application
app = oidc_provider_init_app(config)
File "/usr/local/lib/python3.9/site-packages/satosa_oidcop/core/application.py", line 16, in oidc_provider_init_app
app.server = Server(config, cwd=folder)
File "/usr/local/lib/python3.9/site-packages/idpyoidc/server/init.py", line 72, in init
self.context = EndpointContext(
File "/usr/local/lib/python3.9/site-packages/idpyoidc/server/endpoint_context.py", line 240, in init
_supports = self.supports()
File "/usr/local/lib/python3.9/site-packages/idpyoidc/server/endpoint_context.py", line 406, in supports
res.update(endpoint.supports())
File "/usr/local/lib/python3.9/site-packages/idpyoidc/server/endpoint.py", line 485, in supports
res[key] = val()
File "/usr/local/lib/python3.9/site-packages/idpyoidc/claims.py", line 252, in get_signing_algs
return sorted(_list, key=cmp_to_key(alg_cmp))
File "/usr/local/lib/python3.9/site-packages/idpyoidc/claims.py", line 235, in alg_cmp
_pos1 = SIGNING_ALGORITHM_SORT_ORDER.index(a[0:2])
ValueError: 'Ed' is not in list

I managed the make a correction as follow :

server/claims.py:

SIGNING_ALGORITHM_SORT_ORDER = ["RS", "ES", "PS", "HS"] -> SIGNING_ALGORITHM_SORT_ORDER = ["RS", "ES", "Ed","PS", "HS"]

server/construct.py:
ALG_SORT_ORDER = {"RS": 0, "ES": 1, "HS": 2, "PS": 3, "no": 4} -> ALG_SORT_ORDER = {"RS": 0, "ES": 1, "Ed": 2, "HS": 3, "PS": 4, "no": 5}

After that, all seems to work flawlessly
The issue comes from the module cryptojwt in cryptojwt/jws/jws.py :
SIGNER_ALGS = {     "HS256": HMACSigner("SHA256"),     "HS384": HMACSigner("SHA384"),     "HS512": HMACSigner("SHA512"),     "RS256": RSASigner("RS256"),     "RS384": RSASigner("RS384"),     "RS512": RSASigner("RS512"),     "ES256": ECDSASigner("ES256"),     "ES256K": ECDSASigner("ES256K"),     "ES384": ECDSASigner("ES384"),     "ES512": ECDSASigner("ES512"),     "PS256": PSSSigner("SHA256"),     "PS384": PSSSigner("SHA384"),     "PS512": PSSSigner("SHA512"),     "EdDSA": EDDSASigner(),     "Ed25519": EDDSASigner("Ed25519"),     "Ed448": EDDSASigner("Ed448"),     "none": None, }
Tbh i'm to lazy to make a PR right now so i'm writing the solution here.
Also any feedback on this workaround is welcome, as i am not sure that this issue is related to the project or if it is an issue to satosa_oidcop
Have a nice day

My mistake, satosa is using an outdated version of this module


Consider making jspm install part of npm install

I saw some apps installing jspm with npm postinstall hook in package.json.
Maybe we should do same thing? It seems to be kind of overkill to install all dependencies with each grunt default...

JSPM integration in Kotsu is far from perfect but I'm not sure what problem it will solve since for CI builds it literally have no impact and during development, you might want to reset/reinstall jspm modules. I would say we need more tests on this topic.

I think it's more related to the fact how logically it should be treated. Sometimes I get weird feeling when I launch grunt default, look into console and wonder, why the hell I'm re-downloading and installing all JSPM dependencies each time I launch dev environment? Maybe sometimes that's not what I want to do.
JSPM seems to be quite similar in concept to NPM and in NPM we don't pull dependencies unless we explicitly asked for it.

Nice point. I will think about it.

I think we should treat jspm modules just like npm's. So we want to install the once during install process for finished projects and for projects in development install them one by one but still - just once.


Move repository list into RTD.

@jasontiller3 I reorganized this content per your feedback.
Please take a look at and let me know if you have further suggestions, thanks!

https://github.com/googlegenomics/start-here/tree/staging
http://googlegenomics.readthedocs.org/en/staging/index.html
http://googlegenomics.readthedocs.org/en/staging/github_index.html

LGTM!


MGMT-14645: Change Power and z names in the UI

New official names:
IBM zSystems (s390x)
IBM Power (ppc64le)

backport to r/v2.20


add OPERATOR_NAME env var

otherwise operator-sdk up local fails.

LGTM

It won't technically fail but print out an error as is reported in #462
$ operator-sdk up local
INFO[0000] Go Version: go1.10.2
INFO[0000] Go OS/Arch: darwin/amd64
INFO[0000] operator-sdk Version: 0.0.6+git
ERRO[0000] failed to initialize service object for operator metrics: OPERATOR_NAME must be set
INFO[0000] Watching app.example.com/v1alpha1, AppService, default,<PHONE_NUMBER>

But this should help suppress that error.
LGTM
@LiliC We should move OPERATOR_NAME inside up local like you've suggested before
https://github.com/operator-framework/operator-sdk/issues/462#issuecomment-424717446


The lastestVersion of AzurePowerShell on this task is extremely outdated

WARNING: You're using Az version 9.3.0. The latest version of Az is 11.2.0.

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

ID: 5de2083f-ba71-fce1-ec99-91ee90d0d001
Version Independent ID: 5de2083f-ba71-fce1-ec99-91ee90d0d001
Content: AzurePowerShell@5 - Azure PowerShell v5 task
Content Source: task-reference/azure-powershell-v5.md
Service: azure-devops-pipelines
Sub-service: azure-devops-pipelines-tasks
GitHub Login: @steved0x
Microsoft Alias: sdanie

Thank you for your feedback. We are migrating this issue to our new documentation feedback system, and closing this issue.
As we phase out GitHub issues for this repository, we encourage you to propose changes using public PRs or submit feedback through our updated control at the top of the page. For more information on our feedback systems, see https://aka.ms/contentuserfeedback.


Sanitize the "+" for enum value generation

I noticed this when generation an OA3 spec with NSwag. I am generating a client from a spec that has a string value like "application/json+something".

The failing test doesn't seem relevant, and running locally passes. Is this test flaky?

I committed to confirm flakiness. Looks like my hunch was right.

Thanks for the pr


feat(apps/prod/tekton/configs/triggers): support build with pr

feature: support build with pull request for TiBuild dev-builds, also passing the different registry to avoid mixed in the product repositories.
Signed-off-by: wuhuizuo<EMAIL_ADDRESS>

/approve


Feature not to add some lines to history

Maybe something like HIST_IGNORE_SPACE in zsh because auto reverse history substring search with somebody looking over your shoulder can be a dangerous game 😅
e.g.

"oh let me show you how to connect to a port in ammonite, it's in my history somewhere"
types por and starts hitting up arrow
things seen that can't be unseen

(i guess the classic passwords exposed example works here too... but that one was more entertaining :) )

I think this is probably not common enough to be worth doing in Ammonite's core. If you want to, you can write your own helper function that goes through ~/.ammonite/history and filters it all you want, and any changes should immediately take effect in the REPL


Typo in the C++ NUL character

In this section: https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Developer/chapters/05_Type_System.html#arrays-and-strings

Ada strings, importantly, are not delimited with the special character '0' like they are in C++.

The special character that terminates C++ strings is '\0' The backslash there is important.

Also...

Unlike C++ and Java, Ada does not offer escape sequences such as 'n'.

That should be '\n' instead of 'n'.


Switches to default configuration for default serializer

Yep, but we anyway are going to remove this config property soon again


Update DiagonalAddition.c

since user is asked to define the number of rows and columns .Hence it is not necessary that the formed matrix will be a square matrix.
Describe this PR fixes which issue
Solves issue [issue link]
Eg: Solves issue #20
Describe the changes you made briefly

[ ] Change 1
[ ] Change 2
[ ] Change 3

Thank you for your contributions