router: inbound fees support for BuildRoute

Adapting BuildRoute for inbound fees is a bit complicated with the three passes that it does (backwards - forward - backward).
I've been experimenting with reducing the number of passes (https://github.com/lightningnetwork/lnd/pull/6920) and going one step further by re-routing buildroute to pathfinding (https://github.com/lightningnetwork/lnd/pull/6921).
This PR attempts to add inbound fees support without a major overhaul in how BuildRoute works.
Builds on #6934. Review first commits there.

@joostjager I think this can be closed because of #8886

I think so too. @joostjager feel free to re-open if there's functionality in this PR that wasn't included in #8886.


Ability to add jobs at run-time

Hi @c-rack, have you considered adding an API call to allow users to add jobs at runtime?
The reason I'm asking is I don't think specifying jobs through the config file will work with my production deployment model, where a sys.config file is generated from the mix config scripts.
I think it would be relatively easy to do this - just add an API function and a corresponding handle_call.  I would be glad to do this and make a pull request if it would help.

Yes, I have already implemented that and later removed because I did not see a use case for that, see https://github.com/c-rack/quantum-elixir/commit/bf3891391bc3bd4a1914f87c91627694281004d0 and https://github.com/c-rack/quantum-elixir/commit/d8ba861e43c8b36beb86a604dfa6a2eecd1fda67.
Feel free to send a PR to re-add this functionality.

Thanks! :+1:


CARP: Can not use the same link-local address for multiple CARP VIPs

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[ x ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[ x ] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
I'd like to use fe80::1/64 as CARP address on all of my networks, but there is a unique constraint on the field, so it fails to validate.
To Reproduce
Configure 2 CARP VIPs with fe80::1 as address (on different interfaces, of course).
Expected behavior
As a rule, a unique constraint is a good idea here, but it should exclude link-local addresses on different interfaces.
Describe alternatives you considered
Just omit the check, as it was in earlier versions.
Environment
Software version used and hardware type if relevant, e.g.:
OPNsense 23.4.1-amd64
FreeBSD 13.1-RELEASE-p7
OpenSSL 1.1.1u 30 May 2023

It's not that easy. The interface "@intX" is usually added for that reason to make then unique, but the model system is a little rigid here. But it's true that this worked before.

That was my workaround in the meantime, I removed the unique constraint from Vip.xml .

Which is fine as long as you don't add the same global address to multiple interfaces. :)

Sure, but maybe it is better to let the user make this mistake in this case.

It's never a good idea to let users run into these issues knowingly. It also prolongs support session time and effort spent on both ends.

So, what's the way forward here?

Patience. At the moment there are some other things that have priority.

Can we relabel this as a bug?

Not in my view.

So why is being unable to enter a valid IP address not a bug?

it's an unsupported feature, you want to make it supported..... doesn't sound too complicated.

That seems like a perfectly serviceable fix.

No, it’s more complicated than discussed before. Doing an exception would allow to add the same link-local IP to the same interface multiple times.

@bimbar https://github.com/opnsense/core/commit/0fbca34718 should work if you want to try it. if this one goes in I'm not so sure. Consider it a POC.

We're moving this to the model validation mid-term, but spent too much time on this already so it's going to take a while.

Not to self: I think the cleanup doesn't strip multiple LL addresses correctly. Need to fix this before closing.

Will ship in 23.7.7.

Ah ok cleanup issue still there... will fix for 23.7.7 then ;)

last bit via 16d0a071ad9da
In hindsight this was quite the effort for an obvious bugfix ;)


Redesign of Electrical.Analog.Basic.EMF (support)

Reported by AHaumer on 22 Nov 2007 14:28 UTC
Redesign of Electrical.Analog.Basic.EMF (support) according to new design of Rotational (55357acf3d50b529cdc3fd1c96b29c767d2fc796, 75553227fd2bf6556174178397cf8a7ff8c7d676) using a conditional support connector.

Migrated-From: https://trac.modelica.org/Modelica/ticket/23

Comment by AHaumer on 22 Nov 2007 17:01 UTC
fixed by 0a8b0b83ba0ef5f4257dd17118e833d9d07232ed, 4c3e97e5ca66cbd7bebc5a8212d6c49c609f58c2
redesign of Electrical.Analog.Basic.EMF with conditional support according to new design of Rotational (55357acf3d50b529cdc3fd1c96b29c767d2fc796, 75553227fd2bf6556174178397cf8a7ff8c7d676);
default value of useSupport = false (since this was the behavior up to now);
renamed flange_b to shaft (to be more concise).
adaption of MultiBody.Examples/Systems/RobotR3.mo
adaption of conversion script


A11y_Model Builder_Recommendation_Data_AI4D: (devenv/combo box '') The Name property of a focusable element must not be null.

GitHubTags
#WCAG4.2.1; #A11ySev2; #A11yTCS; #A11yWCAG2.1; #DesktopApp; #Win11; #Visual Studio Client; #SH_ModelBuilder_Win32_May2023; #Object Information; #Win32; #Benchmark; #AI4D; #A11yAuto;
Environment Details
Application Name: Microsoft Visual Studio Enterprise 2022 (64-bit) - Current
Version 17.6.1
Microsoft Windows 11 Enterprise 10.0.22621 Build 22621
Repro steps

Launch the Visual Studio with at least one of the .NET workload.
Tab till enable ML.NET Model Builder (Tools -> Options -> Environment -> Preview Features) and select it.
Create a new .NET project or open an existing .NET project.
Open context menu(Right-click) of the project in the solution explorer.
Tab till Add and then tab till Machine Learning Model and press enter.
Model Builder dialog will open. Tab till Scenario tab.
Select Scenario screen will appear.
Tab till "Recommendation" and press enter.
Setup environemnt screen will appear, Tab till Local CPU tile and select it.
Tab till Next button and press enter.
Data screen will appear.
Turn on AI4D
Verify whether we are getting AI bug like The Name property of a focusable element must not be null or not.

Similar issue observed for edit field aswell.
Issue observed throughout the application.
The following accessibility issue needs investigation.
App
devenv
Element path
combo box ''
Issue Details
The Name property of a focusable element must not be null. Section 508 502.3.1
How To Fix
Provide a UI Automation Name property that concisely identifies the element.
This accessibility issue was found using Accessibility Insights for Windows, a tool that helps debug and find accessibility issues earlier. Get more information and download this tool at https://aka.ms/AccessibilityInsights.
Attachment

we could not use  AutomationProperties.LabeledBy  b/c we do have a nearly by label control and we could not use AutomationProperties.Name too in LabelColumnComponentControl control it has conflict in parent control , hence we have to create the combo box for each control

@Samhitha66 , this  can be validated by a private build you can download from here.

@zewditu
We don't have access for the link which you provided in the above comment.
Please provide us the access. So that we will verify this bug.
#Regressed:07-13-23; #Pendinginput;

@zewditu
Regressed the issue in the below environment
Microsoft Visual Studio Enterprise 2022 (64-bit) - Preview
Version 17.8.0 Preview 1.0 [33912.440.main]
The issue is fixed. Hence closing the bug.
#Regressed:07-14-23; #Close;


license question

hi there, your README mentions that the data set is not available for commerical use as per:

The accompanying dataset is licensed under CC BY-NC-SA 4.0, which permits solely non-commercial usage.

but the license you quote in this repo and on huggingface does allow for commercial use. So my question is, did you mean to use another license or is this dataset indeed available for commercial use?

Hello,
Our dataset is licensed under CC BY 4.0, and we have updated the README accordingly. You are welcome to use the dataset in compliance with this license.

hi, do you have any further questions?

no, thanks a lot!


Add thread safety for glob initialization.

In a parallel build environment, it is possible for multiple projects
to request the version of the same exact key. In this scenario, both
could try to initialize the glob cache at the same time, and the first
one to finish then immediately tries to iterate over the globs while
the other one is still initializing, causing a concurrent modification
exception.
Targets #27.

Coverage increased (+0.1%) to 87.64% when pulling 2cb1bd57f344b0cfcb14f1d49ecbfd80d09c0470 on billbindi:glob-threading into 7e03c7ac2601601823b7e9bbda0ac9f8aa5e1281 on nebula-plugins:master.

@rspieldenner @DanielThomas I don't think I am able to add reviewers, so I figure it might be a good idea to ping you directly.

Coverage increased (+0.1%) to 87.64% when pulling a91068bcdd3e9993da3324d4309215a615a72312 on billbindi:glob-threading into 7e03c7ac2601601823b7e9bbda0ac9f8aa5e1281 on nebula-plugins:master.

This should fix #76


[Usage] Floating point exception when following fine-tuning example

Thanks for the awesome repo and the exciting progress on multimodal learning. Looking forward to trying out the model and building off of it, but having some issues getting started with fine-tuning my own to replicate the training process you describe in the repo.
When did you clone our code?
I cloned the code base after 5/1/23
Describe the issue
Issue: I am attempting to run the fine-tuning command given in the main repo here to verify my setup works before making some changes to the code for my own experiments.
I downloaded the training datasets from hugging face, along with the vicuna checkpoints.
I am attempting to train the model on a single A40 40GB GPU.
Training seems to almost work (the models are restored and data seems to load fine), but when the model begins training, it fails with simply Floating point exception. Any idea what the cause might be?
 The tail end of the output looks like:
[...]
You are using a model of type llama to instantiate a model of type llava. This is not supported for all configurations of models and can yield errors.
[...]
self_attn.v_proj.bias', 'text_model.encoder.layers.0.mlp.fc2.weight', 'text_model.encoder.layers.0.self_attn.q_proj.weight', 'text_model.embeddings.token_embedding.weight', 'text_model.encoder.layers.8.self_attn.k_proj.weight', 'text_model.encoder.layers.0.layer_norm2.weight', 'text_model.encoder.layers.7.self_attn.out_proj.weight', 'text_model.encoder.layers.3.mlp.fc1.bias', 'text_model.encoder.layers.10.layer_norm1.weight', 'text_model.encoder.layers.11.self_attn.v_proj.weight']
- This IS expected if you are initializing CLIPVisionModel from the checkpoint of a model trained on another task or with another architecture (e.g. initializing a BertForSequenceClassification model from a BertForPreTraining model).
- This IS NOT expected if you are initializing CLIPVisionModel from the checkpoint of a model that you expect to be exactly identical (initializing a BertForSequenceClassification model from a BertForSequenceClassification model).
WARNING:root:Loading data...
WARNING:root:Formatting inputs...Skip in lazy mode
  0%|                                                                 | 0/4651 [00:00<?, ?it/s]
Floating point exception

Additional details:

Using Conda environment, set up following the steps in the README (no additional packages installed)
Debian GNU/Linux 10 (buster)
CUDA Version: 11.6
transformers @ git+https://github.com/huggingface/transformers.git@cae78c46d658a8e496a815c2ee49b9b178fb9c9a
torch==2.0.1

I ran the script using gdb (as described here) and it also outputs the following on failure:
Thread 1 "python" received signal SIGFPE, Arithmetic exception.
0x00007ff70c1b6141 in cudnn::backend::Tensor::finalize_internal() ()
   from /usr/local/cuda/lib64/libcudnn_cnn_infer.so.8

also get the error when running in in non-distributed training

Hi @ManuelFay and @jpgard , I have not encountered this before. Two things we may try is to see reduce the batch size to 1, and disable flash attention (using train.py instead of train_mem.py). If any of these work, we can have more insight on what is happening.
You may also try the latest code base using the scripts here.
Please let me know if there are any updates that I can help with, thanks.

yes, I managed to make it work by disabling flash attention and using torch 1.12 instead of 2+. Works with batch sizes of 8 or 16 in LoRA, so probably just a flash attention problem or cuda problem on the A100.
Thanks for the response, I'll try looking into it more in depth at some point !
Thanks for the great work !

Glad to hear that you've made it work. Please feel free to re-open / open new issue if you encounter any other issues.


Made changes

@Ravirajan-com I don't know if these are real keys, but you should probably invalidate them since they are now public.


Fix linux build

@shenhavba,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Whether you plan to switch xclip to maim

I used this plugin on ubuntu Ubuntu 22.04.1 LTS, the window system is wayland, it was still available before, but recently it suddenly can't be used, because I used vscode-insides, I suspect that vscode-insides may be too new, and then I downloaded vscode and found that there are still problems, and then I went to look at xclip and found that only X11 is supported, but my window system defaults Wayland, when I switched to Xorg, the screen took place, because Wayland is the default windowing system for many new distributions, and it is recommended to replace Xclip with maim

Can maim get the local file path copied from the clipboard and the copied picture content?
Can you update this file to use maim and pull request? https://github.com/imlinhanchao/vsc-markdown-image/blob/master/asserts/linux.sh

Can maim get the local file path copied from the clipboard and the copied picture content?
Can you update this file to use maim and pull request? https://github.com/imlinhanchao/vsc-markdown-image/blob/master/asserts/linux.sh

Can maim get the local file path copied from the clipboard and the copied picture content?
Can you update this file to use maim and pull request? https://github.com/imlinhanchao/vsc-markdown-image/blob/master/asserts/linux.sh

ok，I'll do it when I have time


catkin_make failing, looking for argparse

Problem
A recent release of catkin_pkg comes with a change to remove argparse from the requirement list from catkin_pkg.
And this delta (compared to the ms-iot version) causes symptoms like argparse not found: http://answers.ros.org/question/319726/catkin_make-failing-looking-for-argsparse
Resolution
Since all the catkin_pkg changes are considered upstream'ed, we no longer need to patch the catkin_pkg for ROS on Windows installation. (See https://github.com/ms-iot/rosdistro-db/pull/16)
For who already installed the broken builds, please run choco install ros-catkin-tools -y --force.
Details
The ros-catkin-tool install the all the ROS tool from pypi.org and then patch it with the ms-iot version (for catkin_pkg). And since there is a while we haven't rebase to the latest upstream catkin_pkg, this delta mentioned above becomes an inconsistency on what catkin_pkg agrees the dependencies. And when rosdep runs, it calls the old version of catkin_pkg which still says "argparse" to check and it propagates back to cause dependency check errors in rosdep side.

The above quoted command to force the reinstall did not work in my situation. The version is/was apparently the most recent already:
choco install ros-catkin-tools -y --force
Chocolatey v0.10.13
Installing the following packages:
ros-catkin-tools
By installing you accept licenses for the packages.
ros-catkin-tools v<IP_ADDRESS>3221831 already installed. Forcing reinstall of version '<IP_ADDRESS>3221831'.
 Please use upgrade if you meant to upgrade to a new version.

I see that changes have been made and merged into the referenced issue in rosdistro so I suspect that I'm here before it's available?

@bakerhillpins What's your error when you run catkin_make or rosdep? One other workaround is to pip install -U argparse to get around the problem.

@seanyen Ok, so I went back and tried this again and then noticed I made the same mistake you did in the title, I put argSparse back into requires.txt before I tried your suggestion. So i corrected that and executed the catkin_make again.
It's now reporting the dependency PY_em missing: (I will go back to my issue on ROS Answers and update with this info as well.)
catkin_ws>catkin_make
Base path: C:\Users\xx\catkin_ws
Source space: C:\Users\xx\catkin_ws\src
Build space: C:\Users\xx\catkin_ws\build
Devel space: C:\Users\xx\catkin_ws\devel
Install space: C:\Users\xx\catkin_ws\install
####
#### Running command: "cmake C:\Users\xx\catkin_ws\src -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCATKIN_DEVEL_PREFIX=C:\Users\xx\catkin_ws\devel -DCMAKE_INSTALL_PREFIX=C:\Users\xx\catkin_ws\install -G NMake Makefiles" in "C:\Users\xx\catkin_ws\build"
####
-- Using CATKIN_DEVEL_PREFIX: C:/Users/xx/catkin_ws/devel
-- Using CMAKE_PREFIX_PATH: C:/opt/ros/melodic/x64
-- This workspace overlays: C:/opt/ros/melodic/x64
-- Using PYTHON_EXECUTABLE: C:/opt/python27amd64/python.exe
-- Using default Python package layout
-- Could NOT find PY_em (missing: PY_EM)
CMake Error at C:/opt/ros/melodic/x64/share/catkin/cmake/empy.cmake:29 (message):
  Unable to find either executable 'empy' or Python module 'em'...  try
  installing the package 'python-empy'
Call Stack (most recent call first):
  C:/opt/ros/melodic/x64/share/catkin/cmake/all.cmake:163 (include)
  C:/opt/ros/melodic/x64/share/catkin/cmake/catkinConfig.cmake:20 (include)
  CMakeLists.txt:56 (find_package)

-- Configuring incomplete, errors occurred!
See also "C:/Users/xx/catkin_ws/build/CMakeFiles/CMakeOutput.log".
Invoking "cmake" failed

[edit - you update just came through, I'll read that in a sec.]

@bakerhillpins
Good to hear that you found out the argparse typo thing. Btw, do you mind to share what's the requires.txt file location you touched?
For the problem of missing empy, it is most likely also caused by this argparse issue, which prevents rosdep to run correctly before. (I suspect there are lots of system dependencies not yet deployed to your machine too, empy is just one of them.)
In this case, can you do choco upgrade -y --force ros-melodic-desktop (or the ros-melodic-desktop_full, which depends on what the package you installed before.) to trigger rosdep again?

@seanyen requires.txt location is as follows:
C:\opt\python27amd64\Lib\site-packages\catkin_pkg-0.4.8-py2.7.egg-info
I just ran the following.
 C:\Windows\System32>choco upgrade -y --force ros-melodic-desktop
Chocolatey v0.10.13
Upgrading the following packages:
ros-melodic-desktop
By upgrading you accept licenses for the packages.
ros-melodic-desktop v20190325.1 is the latest version available based on your source(s).

The output of this upgrade is SUBSTANTIALLY different/longer from my initial install which I recorded previously. However, The version number, v20190325., hasn't changed.

@bakerhillpins Yes, and please be patient if it takes SUBSTANTIALLY longer time to finish. It sounds like rosdep is working on getting everything you need for ROS node development. Let me know how it goes.

@seanyen Well something happened during the time I stepped away from my desk and a network disturbance caused a fatal error:
Progress: Downloading qt5-sdk <IP_ADDRESS>3182340... 100%

qt5-sdk v<IP_ADDRESS>3182340
qt5-sdk package files upgrade completed. Performing other installation steps.
Extracting C:\ProgramData\chocolatey\lib\qt5-sdk\tools\qt5-sdk-5.10.1-msvc2017-64.zip to C:\opt\rosdeps\x64...
Chocolatey timed out waiting for the command to finish. The timeout
 specified (or the default value) was '2700' seconds. Perhaps try a
 higher `--execution-timeout`? See `choco -h` for details.
The upgrade of ros-melodic-desktop was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\ros-melodic-desktop\tools\chocolateyInstall.ps1'.
 See log for details.
C:\opt\rosdeps\x64
 The upgrade of qt5-sdk was successful.
  Software installed to 'C:\opt\rosdeps\x64'

Chocolatey upgraded 1/1 packages.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Chocolatey upgraded 0/2 packages. 2 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Failures
 - ros-melodic-desktop (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\ros-melodic-desktop\tools\chocolateyInstall.ps1'.
 See log for details.
 - vcredist140 (exited 1638) - Error while running 'C:\ProgramData\chocolatey\lib\vcredist140\tools\chocolateyInstall.ps1'.
 See log for details.

I'll retry the command and hopefully we don't have the same problem.

@seanyen  Score!  catkin_make was successful after the choco upgrade -y --force ros-melodic-desktop command executed successfully.
Thanks for your help! I'll update the ROS Answers question.
Can you help me understand what I may have missed with the initial depoy of ROS on Windows. I explicitly followed the instructions here.
Ah - After revisiting the page it seems that the command to install ROS for Windows under the Binary Package Installation section changed from:
choco upgrade ros-melodic-desktop -y
to
choco upgrade ros-melodic-desktop_full -y

Thank you for reporting this and working through the issue with us.
During ros-melodic-desktop install python scripts are pulled in from pip. There was a change we didn't have a match for in our distribution. Since we have upstreamed our work in that component, we were able to snap to the mainline.
Because chocolatey caches the files, --force was needed to purge the cache.
The only difference between desktop and desktop_full is that the latter contains gazebo and moveit.

@ooeygui  NP.  As I was going to pull down gazebo and moveit eventually that's a plus. Appreciate the quick attention and support.

Fixed.


Cannot use cache file for database

Hi,
I am using Python 3.7.3 and Cantools 36.2.0
I am having problems to create a cache file for the database (.dbc) I load.
If I load the file without a cache path then it works fine but it takes quite a lot to load the database (around 20s).
However, if I define a cache path, then I got the following error:
'can't pickle bitstruct.c.CompiledFormatDict objects'
I supose that if cache path is set as argument,the library tries to load the cache file. If not found then loads the database file and creates the cache file. Is it correct?
Can I have a brief example?
Thank you!

I am on that same version.
This works fine for me.
import cantools db = cantools.database.load_file('vehicle.dbc', cache_dir='./cache')
Doing it twice will trigger restauration from cache if dbc is unchanged.
What is the command you are issuing?

I am using the following line in a class I created:
self.dbCH1 = cantools.database.load_file(filename= self.dbPath + dbFileName, cache_dir= self.dbPath + dbCacheFolder)
It starts creating the cache file in the specified cache path but after a few seconds i receive the exception:
'can't pickle bitstruct.c.CompiledFormatDict objects'

It seems that the diskcache package has trouble serializing the database object. When you google your error, you find an SO question suggesting a  relation to type changes when Python went from version 2 to 3.
I assume this needs fixing upstream in diskcache (if it has not already been fixed). You could try to dig into that.

Sorry, I am not sure if I got what you mean.

The package that is used to store the database object to disk (into the cache) is called diskcache. And this package appears to choke on some dict type that cantools uses.
But since my trial did work, I think your dbc might contain just that bit of data that triggers diskcache to fail. It might be worth isolating what data it is. You could debug and step through the serialization (storage) process until it hits the error.
Unfortunately I do not have the time to dig into this. But it would be a nice exercise to troubleshoot and probably fix it ;).

Ok. thanks for that further explanation. What version of diskcache have you installed?

5.2.1, should be the most recent.

Ouch! It was not updated. I had 4.1.0. Now I have updated diskcache and its dependencies but the problem remains.
The strange thing is that some time ago I could create the cache file with another database.
I have tested again with that database and now I am not able to create the cache file.
I did a upgrade all some time ago. I cannot remember the versions installed previously.... :(

Maybe also update bitstruct.

Ok, I will update everything mentioned and I will be back with the results in some days.
I am using Raspian on a Raspberry Pi 3B+ if this has something to do.
Thanks

Concerning platform: I just mentioned Windows for completeness sake. I don't really expect the issue originating from there. Would be a different story if some fs access had errored out.
In your case, the issue seems to be specific to package/language/type features.

I have upgraded the packages to the mentioned versions except python which remains in version 3.7.3. The problem is still the same: I can load the DBC  and work perfectly (it takes up to 20 seconds), but I cannot create it's cache file.
I found this python update a little bit risky for the rest of applications. Do you think it is completely necessary?

Cannot be ruled out but not highly likely either (they are not far apart). I would probably first try the caching with some other dbcs, maybe the test dbcs from the cantools repo. If these work fine, try debugging (stepping through) cantools with your other dbcs to find the data that it chokes on...

Ok, I will check that as soon as possible. I will be a few days out.
Thanks a lot juleq

Hi, I have tested some of the dbc from the repo and still got the "can't pickle bitstruct.c.CompiledFormatDict objects" exception.
Same behaviour. It works fine if I don't use the cache's path.

since  eerimoq/bitstruct#24, should have addressed that issue, I'm closing it. feel free to re-open if the problem still persists...


Held-in validation set details

Were examples in the held-in validation set pre- and postprocessed exactly as the corresponding examples in the training set? If so, what were the mixture coefficients for the zero shot, template_mix, etc. tasks?

@gahdritz Yes, we used the training templates.py for the held-in evaluation tasks as well (usually the first template per task I believe). Evaluations were with zsopt or fsopt, depending on whether the evaluation setting reported Zero-Shot or Few-Shot.
If I understand your second question correctly, every training task within a submixture (e.g. flan_zsopt) was given a weighting in this line of code: https://github.com/google-research/FLAN/blob/main/flan/v2/mixtures_utils.py#L133.
Essentially, the rate is the minimum of the submixture cap (defined here) and the number of examples already in the task. So maybe 3 (task, rate) pairs are: [(A, 100), (B, 1000), (C, 10)], meaning we will sample 100 B examples for every 10 A examples and every 1 C example. And then the epoch finishes when any of these tasks run out of examples (it should be roughly a tie).

Thanks! What do you mean by "depending on whether the evaluation setting reported Zero-Shot or Few-Shot."? What is the "evaluation setting"? Did you run evals separately for both zero-shot and few-shot?

@gahdritz Sure! Yes, for some experiments we ran Zero-Shot eval and for some Few-shot eval, but that should be clearly noted in the Figure/Table caption in both papers. These choices were made often to show comparative performance in these settings.


Iron-Router support

Hi,
is there a way to use meteor-device-detection with iron router?
It does not seem to pick up "_phone" templates automatically.
Is there a way to get this working?
Thanks,
Gerwin

Just submitted a pull request. It was a pretty simple fix. It would be great if someone can test other devices other than phone and desktop/web.
Cheers!

Any chance this pull request is going to get... pulled?

:+1:


Backend service for mailing contact form information

Description
I would like to create a nodemailer service using node.js backend which will connect with frontend contact form and let user's send messages from the contact form to the project admin.
Screenshots
No response
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a GSSoC'24 contributor.
[X] I want to work on this issue.

Code of Conduct

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

@CSEdgeOff please assign this issue to me.

@atharvarekhawar We are using google services
so that would be not necessary


Terminal adding a space between characters

OS/Web Information

Web Browser: Chrome Version 93.0.4577.82 (Official Build) (x86_64)
Local OS: macOS 10.15.7
Remote OS: Linux 4.19.0-16-cloud-amd64  Debian 4.19.181-1
Remote Architecture: amd64
code-server --version: 3.12.0 b37ff28a0a582aee84a8f961755d0cb40a4081db

Steps to Reproduce
Couldn't find a way to reproduce yet, but it's happening at least once a day. After a terminal is open for a while, the terminal looks like the screenshot attached
Expected

Actual

Logs

Screenshot

Normal terminal

After some time (a few hours)

Notes

This issue can be reproduced in VS Code: No
Also this didn't happen on previous versions. Started happening after I upgraded to 3.12.0

Oh wow...I wonder if that's font rendering issue or something?
Are you using a custom font?

No, default chrome fonts. It didn't happen again since I open the ticket, I'll check if there's actually a space char there or is just rendering when it happens again.

No, default chrome fonts.

Sorry, I meant have you specified a font or changed anything related to fonts in settings.json inside code-server?

It didn't happen again since I open the ticket

Well, that's good! Okay, I'll let you close this then after checking again.

I meant have you specified a font or changed anything related to fonts in settings.json inside code-server?

default font as well.
I found a way to reproduce it:

open the editor and open a terminal
reload the page

resizing the page will fix it

I found a way to reproduce it:

Hmm...I'm on macOS + Brave and followed those instructions. I can't reproduce though.
https://user-images.githubusercontent.com/3806031/134388783-5dd92a78-9a8f-43c6-ad36-1a823cde7a87.mov
Tried Chrome as well. No luck. I wonder if it's a browser setting?
https://user-images.githubusercontent.com/3806031/134389029-b67b9b3b-654c-4b67-a7c6-87741df9ea25.mov

I think this bug was reported several times and it really needs to be investigated. The workaround is the set the font in the config and don't keep it empty ..
https://github.com/cdr/code-server/issues/3848#issuecomment-886882393

@rednaks unfortunately we can't investigate if we can't reproduce this issue.
In the past, it's usually custom font or browser-related. If you can provide specific instructions for reproducing in code-server, I'm happy to take a look!
Otherwise, it could be an issue with the browser, custom font, or xterm.js

@jsjoeio well that's interesting, I just opened xterm,js on my browser and got the same issue, I'm using firefox. on chromium it looks good. How can I investigate this further ?

Wow! Thanks for sharing @rednaks! Indeed, this looks to be an issue with xterm then.

How can I investigate this further

Great question! If I were you, I'd open an issue under their repo and see what they say. I took a brief look and didn't see anything already open (but I'd double-check).

And if you don't mind @rednaks, can you link it here? Then I can mark this upstream and close


Google service account credentials is actually a path to credentials json

Hi!
Context
Actually, when we add a LLM client in Typescript, we need to specify a path to the credentials json file.
Proposal
For an industrialisation of our project, it must be safier and easyier to pass directly the json to the client.
Code before
clientRegistry.addLlmClient(
  "GeminiFlash",
  "vertex-ai",
  {
    [...]
    credentials: "path/to/the/file"
  });

Code proposal
clientRegistry.addLlmClient(
  "GeminiFlash",
  "vertex-ai",
  {
    [...]
    credentials: {
      "type": "service_account",
      "project_id": "foo",
      [...]
    }
  });

This should already be supported!
Check out credentials_content on https://docs.boundaryml.com/docs/snippets/clients/providers/vertex
If that resolves your issue, feel free to close this out!

In the doc, there are credentials_content but for BAML Playground only. When I put my json in this field, it doesn't works.
The stacktrace say :
Error {
  context: "Failed to build request",
  source: "Service account not found"
}

I am not able to get credentials_content working with vertex-ai either. I get the same error as kevpogo

Update: we expect to fix this in 0.59.0, which will release #1009

Awesome to hear! FYI- you can also just pass it in as GOOGLE_APPLICATION_CREDENTIALS now; we'll detect if it's "JSON in a string" and parse it as JSON if so.
@kevpogo you should be able to pass in the contents of a credentials file as credentials when using clientRegistry now.

Yeah it works :) Thank you for your reactivity!

Yeah it works 🙂
Thank you for your reactivity!


KDP version
1.1.0
What did you do?
部署卡主了

What did you see happen?
如何解决

What did you expect to see?
如何解决

please use /root/.kdp/bin/vela status addon-plg-stack -n vela-system to check the installation status of components under the plg and see which component is abnormal during installation

You are advised to add the --set dnsService.name=kube-dns parameter during installation，If the loik-gateway dns is incorrectly configured, pod exceptions occur, causing plg installation failure

please use /root/.kdp/bin/vela status addon-plg-stack -n vela-system to check the installation status of components under the plg and see which component is abnormal during installation

You are advised to add the --set dnsService.name=kube-dns parameter during installation，If the loik-gateway dns is incorrectly configured, pod exceptions occur, causing plg installation failure

it's not work，vela is not installed successfully，Maybe is network problem，Emmm, but how can I deal with it?

is this problem?

please delete prometheusCRD.enabled=false parameter  to retry

/vela status addon-plg-stack -n vela-system

it's not work,

please delete prometheusCRD.enabled=false parameter to retry
it's not work

can you give me install command?

I have dealed with it， Thanks

The Prometheus CRD installed by KubeSphere is inconsistent with the Prometheus CRD installed by KDP (missing attachMetadata), causing an exception.

Refer to the provided link to uninstall KubeSphere's Prometheus and install KDP's Prometheus.
edit crd servicemonitors.monitoring.coreos.com  location at spec.versions.[0]schema.openAPIV3Schema.properties.spec add

spec:
  versions:
   - schema:
        openAPIV3Schema:
          ...
          properties:
            spec:
              attachMetadata:
                description: "`attachMetadata` defines additional metadata which is
                  added to the discovered targets. \n It requires Prometheus >= v2.37.0."
                properties:
                  node:
                    description: When set to true, Prometheus must have the `get`
                      permission on the `Nodes` objects.
                    type: boolean
                type: object
          ...


Early exit if program doesn't contain a main function

Resolves #1452

This looks good to me. Can you add a test to tests/ui/compile-fail to check this behaviour?

@bors r+
Thanks!

:pushpin: Commit d23e245f38f556e833ca7fc4f616b78e791b923b has been approved by oli-obk

:hourglass: Testing commit d23e245f38f556e833ca7fc4f616b78e791b923b with merge ade99c3bed390c88685d4971a83d20d18d8097bf...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: oli-obk
Pushing ade99c3bed390c88685d4971a83d20d18d8097bf to master...

Thanks a lot for the patch @Stupremee :)


team work?

Our company is how to help you quickly into team roles ?

@sundyxfan what do you mean, this repository has been deprecated :-(

@yorkie Should we mark this repo as obsolete as we have moved our docs to weflex/weflex?

Definitely yes, that would be helpful. Oh wait, you mean open the repo weflex/weflex?

Look at your Recruitment jobs


JS Improvements

Use babel
Extract some logic (User and Server)
User reactJS new syntax
Try Avoid global variables
Try follow JS standards/best practices

TODO:

Remove the CreateElements.

Great, let's merge this and continue from there. Thanks mate! :+1:


Update Spark 3.1.3 to be released

Is your feature request related to a problem? Please describe.
Once the Spark 3.1.3 rc passes, we should update our shim to have it be the released version instead of the SNAPSHOT version.

will update nightly test to cover released spark 313 test


Lazy rustc info

This is the first step towards https://github.com/rust-lang/cargo/issues/2848.

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

@bors: r+ 67367a65f1408d2fe645a915e60e25a4da215f96
Thanks!

:hourglass: Testing commit 67367a6 with merge 30272af...

:sunny: Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64
Approved by: alexcrichton
Pushing 30272afd92d3c2b24b3daac68690b93142cb51ad to master...


[Docs]: Documentation for multiple environments

Is there an existing issue for this?

[X] I have searched the existing issues

Engineering Ticket Link
https://github.com/appsmithorg/appsmith/issues/2836
Release Date
15 Dec 2022
First Draft
https://github.com/appsmithorg/appsmith-docs/pull/581/files
Loom video
Part1: https://www.loom.com/share/5f066bfa40ee4482a23a03ac77e7bb17
Part2: https://www.loom.com/share/d5de64b9c84d4a7fa3f82ebabe78ea2b
Discord/slack/intercom Link if needed
No response
PRD
https://www.notion.so/appsmith/Multiple-Environments-ebf42c8d5ef740c9980c6284003d2053
Test plan/cases
No response
Use cases or user requests
User 1
Some ways in which it helps us devs:

We can make dashboards while working on a feature in dev / staging environment, and those are then production-ready for content/product team automatically.
Debugging and replicating issues on dev/staging become much easier.

User 2
I think it would be great to have a hierarchy of special config variables that could get overridden at different levels. For example, it would be great if, like Hasura, you could define server-level environment variables which you could then use in an app in AppSmith. Then, it would be great if you could override those at the organization, and app levels.

Maybe that's overcomplicating things in some ways, but in others I think it would simplify them. If we just have "configuration variables" as a higher level system, then you wouldn't need to create a separate system specific to datasources for managing environments: servers, organizations, and apps can already be used to manage environments.

This would also help with another problem that we have, which is using weird workarounds to check the url to check if we're in staging or prod to change things in JS Objects to deal with API endpoints. If there was a special "config" object that could be modified at the server/org/app level that was usable in datasource configuration as well as elsewhere in apps, that would be so so helpful.

User 3
We have a sales funnel / CRM app with an Appsmith + Supabase stack.

We decided we wanted each company we sign up to have their data segregated, so they have a different Supabase instance.
Each instance has a different api url.

We could use multiple environments to create a dev, prod-company1, prod-company2 ... etc

@sribalajig hey just wanted to know when the first draft would be shared as we noticed that the release date here shows 15th Dec

@danciaclara We are going to share the first draft by end of today. cc @riteshkew @ayushpahwa @sondermanish

@riteshkew - Could you please share when the DP will be functional for us to progress with documentation?

Closing this as the feature didn't go out


Upgrade NullAway 0.10.19 -> 0.10.20

This PR contains the following updates:

Package
Type
Update
Change

NullAway
compile
patch
0.10.19 -> 0.10.20

Release Notes

uber/NullAway (NullAway)
v0.10.20
Compare Source

Fix JSpecify support on JDK 21 (#869)
Build / CI tooling upgrades for NullAway itself:

Update to WALA 1.6.3 (#887)
Update to Error Prone 2.24.1 (#888)

[ ] If you want to rebase/retry this PR, check this box

Suggested commit message:
Upgrade NullAway 0.10.19 -> 0.10.20

See:
- https://github.com/uber/NullAway/blob/master/CHANGELOG.md
- https://github.com/uber/NullAway/releases/tag/v0.10.20
- https://github.com/uber/NullAway/compare/v0.10.19...v0.10.20

This PR was replaced by #975.


[FIXED] Authorization Timeout and TLS

When TLS and authorization is enabled, the authorization timeout can
fire during the TLS handshake, causing the server to write the
authorization timeout error string into the client socket, injecting
what becomes bad data into the TLS handshake. This creates misleading
errors on the client such as tls: oversized record received with length
21024.

[x] Link to issue, e.g. Resolves #NNN
[x] Documentation added (if applicable)
[x] Tests added
[x] Branch rebased on top of current master (git pull --rebase origin master)
[x] Changes squashed to a single commit (described here)
[ ] Build is green in Travis CI
[x] You have certified that the contribution is your original work and that you license the work to the project under the MIT license

Resolves #432
Changes proposed in this pull request:
This moves the authorization timeout scheduling to after the TLS
handshake to avoid the race. Added a unit test that fails with the old
behavior and passes with the new. LMK if you can think of a better way
to test this.
/cc @nats-io/core

Re: failing build, seems like there's a hanging test in master. https://travis-ci.org/nats-io/gnatsd/jobs/232690030#L394 Haven't figured out where yet...

Yep noticed that. Deadlock or dangling lock maybe..

Running the tests locally with go test -race -v -p=1 ./... shows that the blocking test is TestAuthorizationTimeout in server/client_test.go. The problem is by moving the setting of the auth timer where it is now, there is a condition where we return if server is not running. This test is not starting a server, instead doing raw setups, so the "client" never times out and test blocks in cr.ReadString().
My approach would have been to leave the setting of the timer at the same place but have the callback use locking to check on the state of the possible TLS connection and issue the error message only if handshake is complete. I agree that this would lead to "unpredictable" outcome for the client (sometimes getting auth-timeout error, sometimes EOF), but would protect against clients that start TLS handshake but never complete.
Alternatively, you would need to fix that test ;-)


Correct typo in blog post prompt

I'm guessing this was a typo since you didn't mention it, as you have done with other spelling mistakes later in the file. If not, ignore me :)

i actually did get that verbatim from notion ai i think. but its minor so i'll merge :)

thanks for reading!


CORS error when talking to API

When viewing the frontend, the page stays on loading and the console says:
Access to fetch at 'https://api.dev.corpora.cziscience.com/v1/project' from origin 'https://dev.corpora.cziscience.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
api.dev.corpora.cziscience.com/v1/project:1 Failed to load resource: net::ERR_FAILED
component---src-pages-index-tsx-98b11e112c502198be7f.js:1 Uncaught (in promise) TypeError: Failed to fetch
(index):1 Error while trying to use the following icon from the Manifest: https://dev.corpora.cziscience.com/icons/icon-144x144.png (Download error or resource isn't a valid image)

This is an error with the backend not allowing api request due to a CORS permission issue.

Does this have a dependency on #497?

This issue is fixed https://github.com/chanzuckerberg/corpora-data-portal/commit/4aa7e4a6a355d8573f5164c63aac74127d6c7569


Update Text Style picker UI to match color picker UI

Hi @dabbott , this project is amazing idea 👍
To be honest,  I and designer/android team are struggling this exactly situation in every time you're facing. I love this idea so much.
I'm wondering if you're working on this issues or not ?
If not I'm willing to contribute my effort on my spare time 😃

@NghiaTranUIT I'm really glad you like the project. I have faced this problem so many times... but I think we can finally solve it!
I haven't started working on this issue. I would love if you could do it 😄 . Let me know if you run into any issues or want to discuss more.

Ok, Let me do it 👍

Closed with https://github.com/airbnb/Lona/pull/31!


Bug Report: Refresh timer failed

Is there an existing issue for this?

[X] I have searched the existing issues (both open and closed).

What happened or didn't happen?
Error message in application log file. (see below)
Appears to be a threading issue attempting to show a snackbar message.
Steps To Reproduce
Run Get My IP with automatic refresh enabled.
Error happens infrequently.  Error isn't reproducible on demand.
Version
0.12.2
Windows Version
Windows 11 24H2 build 26100.2454
Relevant log output
2024/12/01 16:16:58.73 ERROR  Refresh timer failed
System.InvalidOperationException: The calling thread cannot access this object because a different thread owns it.
   at System.Windows.Threading.Dispatcher.<VerifyAccess>g__ThrowVerifyAccess|7_0()
   at System.Windows.Application.get_MainWindow()
   at GetMyIP.Dialogs.SnackBarMsg.ClearAndQueueMessage(String message) in V:\Source\Repos\GetMyIP\GetMyIP\Dialogs\SnackBarMsg.cs:line 17
   at GetMyIP.ViewModels.NavigationViewModel.RefreshExternalAsync() in V:\Source\Repos\GetMyIP\GetMyIP\ViewModels\NavigationViewModel.cs:line 273
   at GetMyIP.Helpers.RefreshHelpers.TimerElapsed(Object sender, ElapsedEventArgs e) in V:\Source\Repos\GetMyIP\GetMyIP\Helpers\RefreshHelpers.cs:line 54

Anything else?
No response

My internet has been down until a few minutes ago. ☹ Kind of hard to work on this bug without internet. Not to mention all of the Cyber Monday deals that I missed.
Tim

Oh no!  Is the connection back again?

Connection is back. 🎉
I don't know what deals were missed. Probably better that I don't know anyway. 🤣

I managed to find the bug.
If automatic refresh is enabled AND the Get My IP window is not minimized, AND the refresh timer executes the refresh, then the error occurs!
The refresh actually happens. The exception came from trying to display the "refreshed" message after the refresh.
Will be fixed in the next release!
Tim

i have it:
2024/12/03 08:37:41.49 ERROR  Refresh timer failed
System.InvalidOperationException: The calling thread cannot access this object because a different thread owns it.
at System.Windows.Threading.Dispatcher.g__ThrowVerifyAccess|7_0()
at System.Windows.Application.get_MainWindow()
at GetMyIP.Dialogs.SnackBarMsg.ClearAndQueueMessage(String message)
at GetMyIP.ViewModels.NavigationViewModel.RefreshExternalAsync()
at GetMyIP.Helpers.RefreshHelpers.TimerElapsed(Object sender, ElapsedEventArgs e)
2024/12/03 08:37:49.50 DEBUG  Opening C:\Users\santa\AppData\Local\Temp\T_K\GetMyIP.20241203.log in default application

Thanks, that looks like the same exception that I got.
I missed one string in the last release. Would you translate "Error reading settings file." and send it in a reply. I'll update the file.
Thanks,
Tim

Error reading settings file.
Fout bij het lezen van het instellingenbestand.
Nice word for rummikub: instellingenbestand

Click here for amazing cybermonday deals!

Thanks. That link was extremely helpful. 😄


feat(ui): Added directory selector for snapshots and filesystem repository

Hi,
this PR comes with the following changes:

Rewrote the directory selector and added a required and optional directory selector
Added the directory selector to snapshot create and filesystem repository
Fixed a bug, where the deletion of the snapshot path result in a nullpointer reference

This pr will fix https://github.com/kopia/kopia/issues/3453
Feedback is welcomed,
Cheers

FYI @jkowalski


Add filter extension

Adding filter extension. Also making changes to other extensions to make it easier to dynamically build the conformance classes from the implemented extensions.

This also closes #159 by adding conformance classes to the landing page.

Thanks for checking! I realized later that my venv somehow had the
stac-fastapi packages installed in it, so I think those were being used
instead of the source.
On Thu, Jul 8, 2021 at 4:03 AM Richard Smith @.***>
wrote:

@.**** commented on this pull request.
In stac_fastapi/types/stac_fastapi/types/core.py
https://github.com/stac-utils/stac-fastapi/pull/165#discussion_r665963815
:

@@ -141,6 +157,7 @@ def landing_page(self, **kwargs) -> LandingPage:
id=self.landing_page_id,
title=self.title,
description=self.description,

       conformsTo=self.list_conformance_classes(),

yes:
[image: image]
https://user-images.githubusercontent.com/22395703/124885448-2c542800-dfcb-11eb-87d7-9f463f056c1d.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/stac-utils/stac-fastapi/pull/165#discussion_r665963815,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAA6QRFVJYK6TG4DHZFV2P3TWVLT7ANCNFSM47R4KB5Q
.

Making sure I understand - this PR adds a filter extension that implements the queryables routes, but does not implement any of CQL "filter" property on the Search object, correct? So it's up to backends to implement the actual CQL filtering, but this PR adds the necessary top level routes that are added by the extension? If I'm getting that correct, this seems like a good change that will set up the next stage of work which is to add CQL support to the pgstac and sqlalchemy backends.
@rsmith013  Can you merge in the latest master, and I'll take a closer look next week? Thanks!

@lossyrob Yes, that was the plan.

Looking good; going to leave this off of the 2.0.0 release because there's a TODO around implementing the Async core client.

@lossyrob I didn't realise you were that close to a release. Added the Async base and merged master. Should be good to go

Thanks! We decided to pop one off since it had been so long. Let use kick the tires for the CI-based publishing as well. There's a few issues so I'm sure we're going to have to fix up soon so I'm expecting a 2.1 release in the next week or so


fluffcon.js Errors?

I'm fairly new to the whole Bluetooth end of things but I think I have Node/Noble set it right since the test and examples in the Noble install seem to be working.
On Windows 10 when I go to run fluffd I get:
D:\Furby\bluefluff-master\fluffd\fluffcon.js:234
let characteristicUUIDs = Object.values(FURBY.CHARACTERISTIC);
^
TypeError: Object.values is not a function
at D:\Furby\bluefluff-master\fluffd\fluffcon.js:234:36
at Peripheral. (D:\Furby\bluefluff-master\fluffd\node_modules\noble\lib\peripheral.js:38:7)
at Peripheral.g (events.js:291:16)
at emitOne (events.js:96:13)
at Peripheral.emit (events.js:188:7)
at Noble.onConnect (D:\Furby\bluefluff-master\fluffd\node_modules\noble\lib\noble.js:148:16)
at emitTwo (events.js:106:13)
at NobleBindings.emit (events.js:191:7)
at NobleBindings.onLeConnComplete (D:\Furby\bluefluff-master\fluffd\node_modules\noble\lib\hci-socket\bindings.js:21
2:8)
at emitMany (events.js:127:13)
Any ideas or is this something on my end?

You have to update your node.js to v7.0 or later, I am using v7.4.0. Also see #1 where we had the same discussion. You can get the latest nodejs from https://nodejs.org/en/.

Oops. The closed issue tab is not very obvious, however that doesn't exactly cover what I'm running into.
I installed 7.4.0 initially and could not get Noble past a USB module error on it compiling. I switched to 6.9.4LTS and Noble worked just fine. I'll have to dig into Noble some more and see where the problem lies, or I'm wondering if I can compile Noble in 6.9.4 and then update to 7.4.0 and have Fluffd work.
Hopefully I can get Noble to cooperate and poke at this some too. This looks like a lot of fun.

I spent a good part of the afternoon poking at it and am having no luck with node.js 7.4.0 and Win10. Both Noble and Fluffd fail on install due to missing modules and a few other errors. I got past the USB module problem if I turn of any AV but then still has debug issues. Node.js 6.9.4lts outside of a few warnings works for Noble and just fine outside of the specific new calls you're using for Fluffd.
I still haven't tried installing Noble, updating and then installing Fluffd but I'm not having high hopes of that working because I'm assuming it does some version checking.
I'm am curious to see if I can get it working since it sounds like some people did already but it may just work better to set up a VM with linux...

This patch will apply cleanly. I'm not doing a pull request because values is better.
diff --git a/fluffd/fluffcon.js b/fluffd/fluffcon.js
index f32f6e0..8f675ac 100644
--- a/fluffd/fluffcon.js
+++ b/fluffd/fluffcon.js
@@ -231,7 +231,8 @@ module.exports.connect = function(furby, callback) {

                exitHandler(furby);

-               let characteristicUUIDs = Object.values(FURBY.CHARACTERISTIC);
+               //let characteristicUUIDs = Object.values(FURBY.CHARACTERISTIC);
+               let characteristicUUIDs = Object.keys(FURBY.CHARACTERISTIC).map(function(key) {return FURBY.CHARACTERISTIC[key];});
                getFurbyCharacteristics(furby, FURBY.SERVICE.FLUFF, characteristicUUIDs, function(characteristics) {
                        let gpWrite = characteristics[FURBY.CHARACTERISTIC.GENERALPLUS_WRITE];
                        let gpListen = characteristics[FURBY.CHARACTERISTIC.GENERALPLUS_LISTEN];


Adding IPv6 version of fvz resolvers

Please let me know if something is wrong (format, server unreachable, etc.), but everything should be fine from what I can see.

Fantastic!
I don't have IPv6 connectivity right now, but I will check this as soon as I get back home.

Hello,
Looks like none of them is useable. The reason might be that they don't respond to the certificate request. Or rather, they respond with NXDOMAIN instead of the certificates:
$ drill -p 443 txt dnscrypt-cert.fvz-rec-at-vie-02.dnsrec.meo.ws @2a03:f80:ed16:ca7:ea75:b12d:1b9:e6b9
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 2910

Hi,
you have the "2." missing there. It is "2.dnscrypt-cert.fvz-rec-at-vie-02.dnsrec.meo.ws", not "dnscrypt-cert.fvz-rec-at-vie-02.dnsrec.meo.ws" :-)

Good catch. Wondering who designed such as terrible protocol, haha.
The actual reason it doesn't work is that IPv6 addresses require the port number after the address.
It should be optional, and this is something I definitely need to fix. Meanwhile, I'm just gonna add :443 after the resolvers IPs and everything should magically work :)

Please let me know if you want me to add :443 to the end of the IPv4/IPv6 addresses. It's not a big deal, just 2 changes in the template file.

Don't worry, I'm gonna do it. But it doesn't hurt doing it on your side for the future resolvers :)

They all work except fvz-rec-de-fra-02-ipv6.

Hi,
hm, fvz-rec-de-fra-02-ipv6 doesn't seem to be in the database, I wonder why I added it there. You can just remove it from the file. I will delete the interface for it.

No worries, I'm gonna remove it, then.
Thanks for providing these IPv6 resolvers! Perfect timing now that the world just ran out of IPv4 addresses!

Merged! All of them are working fine!

Oh, just one details: it's better to have a unique name (second column) for each resolver (maybe just by adding "IPv6" at the end).
Because some user interfaces just display this name and not the id from the first column, so we see the same things twice.

Also, there was an extra space after the name and before the "," :)

All of these things should be fixed now in the exporter template. Mind taking a look at the recent export? https://scr.meo.ws/paste/2015-09-23-22-17-59-Xje2py0v.txt

Looks perfect! :+1:


[Linux] Improve triplet options

[triplets] Ideally, the default triplet for Linux should align with the Windows triplet (shared by default).
Added two new triplets to enable Linux users to explicitly set the library type.
[plib] Added support for shared libraries

Thanks for the PR!
The reason we do not currently ship a shared-linkage Linux triplet in the box is that we are not confident we can deliver a reasonable experience for novice users. Advanced users on linux will know about all the various tricks (LD_LIBRARY_PATH, rpath, etc), but advanced users can also read the docs and trivially create additional triplets locally.
The above said, we would be happy to see the fixes to geos and plib in separate PRs!


feat: support quantified captures

This commit also removes all uses of #make-range! as it is no longer necessary.

Good to see this change as I've been waiting for this for quite a while! I guess this requires nightly nvim (0.10)?

It does sadly, hopefully we can merge the main branch soon after 0.10 releases!

Maybe some people use custom captures or captures from other plugins. Should we deprecate the use of make-range! but remove the code a little later so it won't break any?

Good point: up to @clason I think. This branch is already pretty breaking so removing the directive might not matter (or maybe we should just add the fake function() end placeholder directive to prevent errors?) I don't mind either way

Since we are going to keep the queries in sync with the master, the main branch will likely have #make-range! directives for some time. And merging this will break this syncronisation.

It does sadly, hopefully we can merge the main branch soon after 0.10 releases!

No, we will definitely not do that! The main branch will become the default, but master will remain (possibly after renaming) as a legacy branch. This will happen together with the corresponding switch for nvim-treesitter (and nvim-treesitter-refactor) so people can upgrade to main + main or stay on master + master (but not get updates).

No, we will definitely not do that!

Right, sorry :sweat_smile: I remembered you saying that after I left that comment...

But now that @TheLeoP converted this into a proper directive, this is much less urgent.

I see: so should that directive code be kept around on main for a bit, like @kiyoon says?

I think so, yes. I do like the change, but keeping queries in sync (for now) makes developing both branches in parallel much easier.

In fact, I would make this change on master (in general, PRs should never target main unless they're related to the upstream refactor) as soon as we can require Nvim 0.10 (probably sometime after the first bugfix release, to give people time to update).
The "support matrix" for Nvim in the nvim-treesitter org is

latest release
latest commit on HEAD

(That doesn't mean that we'll aggressively drop support for older versions, but we don't make any long-term support guarantees. Delaying updates is just common courtesy.)

Although I'm not 100% sure quantified captures are fully equivalent to make-range? I think the latter could create a range that spans other captures as well, which might be useful?

I think it would be difficult to target master: or at least, the changes would have to be applied to the regular nvim-treesitter iterator utils which this repo uses, then we could apply just the query changes to this repo.

Although I'm not 100% sure quantified captures are fully equivalent to make-range?

Everything I have tested (which, granted, wasn't every single query change but was most unique types of queries that  query files use) has shown the behavior to be identical. Hopefully it just always works, but not 100% positive about some wacky edge cases

I think it would be difficult to target master: or at least, the changes would have to be applied to the regular nvim-treesitter iterator utils which this repo uses, then we could apply just the query changes to this repo.

If this would help the transition, I'd be willing to merge a PR iff 1. it only changes stuff that is dropped on main anyway and 2. is unlikely to be breaking for other users.

Everything I have tested (which, granted, wasn't every single query change but was most unique types of queries that query files use) has shown the behavior to be identical. Hopefully it just always works, but not 100% positive about some wacky edge cases

I was thinking more that make-range is (much?) more general, even if current queries don't use that (yet). I'm also not unsure if other plugins use it (but that's not necessarily a problem for changes in nvim-treesitter-textobjects).

Sounds good, I'll mark as draft and sit on it until 0.10 :+1:

I'm wondering if it is still better to target this on master. Doing some rebasing now and I'm realizing that the capture iteration logic resides in the nvim-treesitter utils that this repo inherits. I was able to change it easily on main since it was all standalone logic. For master, I think there would have to be some API changes on nvim-treesitter's end to allow for { all = true }. Does that sound possible? Or should this be left to target main?

From what I understand we would target that on master and rebase it on main when nvim-0.10.1 is out.

I think there are a number of possible simplifications by relying on Nvim core APIs rather than nvim-treesitter utils left on the table; these would be worthwhile in any case.
I see two options:

Merge this now to  main and essentially freeze the code on master to prevent rebase conflicts (any possible conflicts to queries are fairly easy to resolve manually); this is how I handle nvim-treesittter.
Change the logic in nvim-treesitter master and merge this to master (and make followup changes to main).

I am not averse to 2. in principle, but the decision would depend on the exact size of changes (conflicts when rebasing, dropping 0.9.x support or extensive comaptibility shims etc.)

I also don't mind freezing master and focusing on updating main which won't break much for the existing users and even encourage them to migrate.

I wouldn't encourage people to migrate ... yet.

I'll opt for solution 1. then?

That certainly works; if you want my opinion on option 2, I would need more details ;)

I think this is good to go now. I have removed the make-range predicate definition; I know we had a discussion that ended with deciding to keep it but I think if plugins use it that means they are also using the nvim-treesitter iteration utils which account for make-range. So I think the only backwards-compatibility this would break would be for user textobjects queries that have make-range. Should I still keep the make-range definition for this case?

My concern was that make-range seems strictly more powerful; whether that power is used currently I don't know.
(And whether the implementation actually works correctly...)

right now the range is calculated as . Same logic as make-range

Ok, then there's really no reason. I was thinking -- as has been requested a few times -- that it's $\overline{\mathrm{co}} (\textbf{first-captured-node} \cup \textbf{last-captured-node})$ (so includes everything between the two captured nodes).

Oops, sorry. That is how it works, everything in between the first and last. My (lack of) mathematical notation knowledge fails me :sweat_smile:

Ok, so there is worth in the directive; the question is whether we need it here.

make-range also included everything between ranges; the logic here is what I referenced for this PR. So I believe the behavior is identical and thus the directive is not needed here. But it may be worthwhile to add a make-range stub here that warns users that it is deprecated and they should use newer query methods.

The idea is that make-range could capture the range between different nodes (and not just for text objects -- which is out of scope for this repo, of course).

@ribru17 do we want to go through with this? if so, it needs a (big) rebase.
(I worry a bit about reusing make-range in an incompatible fashion, but maybe we can keep the "make range between" implementation compatible in some way. That would be a follow-up, though, and probably better discussed in core.)

Actually, now that Nvim 0.10 has been out a while and had its first bugfix release, I feel much more comfortable bumping the minimum version on master. So how about this:

on master, require Nvim 0.10 and update the queries but leave the directive untouched;
rebase main to pull in the new queries and then remove make-range (and other simplifications).

It's a bit more work but strikes me as the least painful approach? @ribru17 @kiyoon

This sounds good to me, I can rebase today. I was even going to ask your thoughts on using such a large PR to migrate queries to the main nvim-treesitter repo? Maybe this is breaking and should wait till 1.0 (or never :() but it seemed like a decent opportunity with this PR, and would help maintainability a lot imo (relating to CI)

We've discussed that a lot, but never came to a good conclusion. On the one hand, having the queries in nvim-treesitter makes it easier to prevent breakage when updating parsers (which is a big plus). On the other hand, it makes it harder to make bigger changes to the plugin itself that requires changing the captures. It also goes counter to the goal of making these plugins stand-alone and moving nvim-treesitter away from being a mandatory single point of failure...
I feel that if we do this, we should also (only!) move the query handling part into nvim-treesitter (similar to what locals.lua does) and leave only the user-facing parts (selection, movement, swap -- if that remains) here. It would essentially mean master is frozen, though, since I don't want to manually port updates between here and nvim-treesitter.
In any case, that would only affect main, and the move to quantified captures on master would still be good.

Pro tip: rebase -i main and then just drop the first commit(s).

(You might want to pull in the changes from my CI PR, at least the ones regarding the query file check -- I got the cache working again ;))

Do I understand this correctly that here quantified captures get extended (i.e., you get the convex hull of the union of the individual node ranges) -- differently from how they behave for highlights and injections? (And folds?)

I believe it is the same as folds, but yeah different from the other ones. If we think of the make-range functionality as a block box, it is identical to that. Only difference is instead of passing nodes via predicate arguments, nodes are passed by , , for a given quantified capture group

I think that's fine (although personally I always prefer explicitness over convenience), but I think this should then be documented. (Also for folds, but that's a separate upstream issue.)
(I do worry a bit about the potential issue showing a situation where you would want to have separate textobjects, but we can burn that bridge when we get to it.)

``

(I do worry a bit about the potential issue showing a situation where you would want to have separate textobjects, but we can burn that bridge when we get to it.)

Wdym? afaics the behavior is identical to make-range; yes the calling convention is more explicit but I don't think there are any cases where the predicate could solve something that the quantified style couldn't

I mean the opposite: a situation where you don't want a range, and previously could have just omitted the directive (but now can't since the behavior is builtin).

Ah I see what you mean. I thought about that as well. But I think this isn't an issue (it just might mandate slightly more explicit queries). E.g.:
(func
  ; this no longer works bc its combined
  (param) @parameter.outer
  (type_param) @parameter.outer)

We can get the original behavior with:
(func
  (param) @parameter.outer)

(func
  (type_param) @parameter.outer)

separate queries will not merge ranges. And of course, if we are dependent on the sibling interaction:
(func
  (param)
  (type_param) @parameter.outer)

(func
  (type) @parameter.outer
  (type_param))

So again, more verbose but at least the original functionality can still be achieved. And I think situations like these would be rare-ish anyway

Yes, I didn't think this was a blocker; just mentioned it for the sake of completeness.

Is make-range already not taking any effect? Is it safe to delete reading the metadata it created in the code?

Can we make this PR target master and move on it? If we keep plugin/query_predicates.lua, there should not be any breaking change on master. Users can still use #make-range in their custom queries. The cost should only be this plugin no longer supports nvim version under 0.10.

Would need to document the new requirement and a tag of the last version compatible with Nvim 0.9, but otherwise no opposition.

I think this was discussed before; even though I would love to target master (less rebases), it seems not as simple as that since as of now we iterate over captures with ts_utils instead of the core api. So that would have to be migrated as well... I wonder if we could do it easily and without breaking anything such that that change could also target master? And then we get a partial jump start on syncing master and main...

main removed some features such as lsp_interop, and there's a lot of refactoring after that, so I think we've lost the chance to partially migrate some of main's code into master already...except for queries, these two branches may have been completely forked, so we may have to develop master separately, or freeze it directly and switch to main.
The purpose of wanting this PR target master is to ensure that queries(which use these quantified captures) are still available to master in the future, as we'll drop #make-range! in main. I still think it is worth having a try, but I don't know whether it could be easily done too.

we may have to develop master separately

That is not the plan; we don't have the resources for that. Master is essentially frozen as a plugin, but it is still the primary target for query updates; that is what will change. (And since query updates are necessary to keep the plugin from working with current parsers, that means basically abandoning master.)
So, yes, the only goal here would be to keep the queries in sync for longer. If that is not feasible, we should just switch -- but then the mapping setup needs to be fixed first; that's a hard prerequisite (and the last one).

So that would have to be migrated as well... I wonder if we could do it easily and without breaking anything such that that change could also target master?

It's worth spending maybe twenty minutes looking into that and seeing if it's feasible (meaning, changing just that without triggering a bigger refactor that gets us halfway to main). The goal would be the minimal change to allow quantified queries with Nvim 0.10. If it doesn't look that way, we should just pull the trigger and start the switchover by decoupling the queries (and effectively freezing master completely).

It's worth spending maybe twenty minutes looking into that and seeing if it's feasible (meaning, changing just that without triggering a bigger refactor that gets us halfway to main). The goal would be the minimal change to allow quantified queries with Nvim 0.10. If it doesn't look that way, we should just pull the trigger and start the switchover by decoupling the queries (and effectively freezing master completely).GG

I spent a couple hours looking at this and the change seems pretty annoying :/. Also there would be several conflicts with main I'm sure.  Let's go all in on main.

Man main is still in a rough shape it looks like... seems like outer selections dont work for operator pending modes, and inners dont work for selections :laughing: After this commit, they still wont. But quantified captures will! :upside_down_face: I also fixed up a bit of the shared code, now range metadata is captured properly (it was not before). Let me know if anything else needs work, I want to try and get this merged this as soon as possible

Yeah, it's a mess; test coverage is... partial. (Most of the breakage is probably my fault.)
Feel free to merge; as long as things improve, no sense to hold back.

But please make a note of exactly what doesn't work in your tests (exact steps) so we can add them to the list for at least manual checking.

Is there a list for manual testing scenarios or would you like me to comment them here?

I noticed there's something wrong with the metadata after you pointed out we could not handle #offset!, so there is https://github.com/nvim-treesitter/nvim-treesitter-textobjects/pull/676, but it looks like your fix is more comprehensive.
If it doesn't work, please tell me the specific scenario and I will check what's going on. in #676?

Oh thanks! Sorry I didn't see your PR. Yours looks fine too, but I wonder if add_bytes is the better way to go about things because I don't know if e.g. offset! changes the byte section of the range as well?...

changes the byte section of the range as well?...

It does not, and I think it never does. The range (modified by #offset!) is separately stored in the past, only when functions do not need the bytes info, it will be used, otherwise will always use the range provided by node:range(true), which does not apply the offsets.


Call to a member function setContentType() on null - Responsetrait

Hi, I had a similar problem as described in the forum, but I didn't see any fix yet, so I decided to post the bug here for fixing in the future.
https://forum.codeigniter.com/thread-77516.html
The bug occurred on response API with this error:
Call to a member function setContentType() on null - on line 114 Responsetrait.php
Its also fixed as it described in the topic:
public function respond($data = null, int $status = null, string $message = '') { $this->response=service('response');

Web server Apache 2.4.46
PHP version 7.4

How are you using the ResponseTrait in your code? Can you a sample?

A class using a trait should be responsible for ensuring that the properties used by the trait is available when the trait will be using it. It is not the responsibility of trait to reinitialize a property that is of the class. Pending sample code, I see this as an implementation mistake on user's code.

Upgrade the framework to version 4.0.5 if you are using php 7.2, or to version 4.1.1 if you are using php >= 7.3
The response property of the controller is defined in the initialization method.
If it is null, then you have changed the initialization method.

I'm currently using CI 4.1.1 & PHP 7.4 as I mentioned before.
Here is my usage:
public function error($status,$msg,$data){
   return $this->setResponseFormat('json')->respond([
      'status'=>$status,
      'msg'=>$msg,
      'data'=>$data
   ]);
}

And it's the error:
CRITICAL - 2021-04-06 18:33:24 --> Call to a member function setContentType() on null
#0 F:\xampp\htdocs\recovermsg\vendor\codeigniter4\framework\system\API\ResponseTrait.php(114): App\Libraries\Api->format(Array)
#1 F:\xampp\htdocs\recovermsg\app\Libraries\Api.php(28): App\Libraries\Api->respond(Array)
#2 F:\xampp\htdocs\recovermsg\app\Controllers\ApiV1\Log.php(29): App\Libraries\Api->success('Activity succes...')
#3 F:\xampp\htdocs\recovermsg\vendor\codeigniter4\framework\system\CodeIgniter.php(936): App\Controllers\ApiV1\Log->index()
#4 F:\xampp\htdocs\recovermsg\vendor\codeigniter4\framework\system\CodeIgniter.php(432): CodeIgniter\CodeIgniter->runController(Object(App\Controllers\ApiV1\Log))
#5 F:\xampp\htdocs\recovermsg\vendor\codeigniter4\framework\system\CodeIgniter.php(333): CodeIgniter\CodeIgniter->handleRequest(NULL, Object(Config\Cache), false)
#6 F:\xampp\htdocs\recovermsg\public\index.php(45): CodeIgniter\CodeIgniter->run()
#7 {main}

Unfortunately, I don't get the initialization method solution. I'm just using "use ResponseTrait;" like the document.

ResponseTrait is used in controllers.
If you use it elsewhere, you must initialize the required components yourself.

Aha, got it, May I ask you to tell me how to initialize the required components in a Library?

If you are using the trait in the context of a library, you should be initializing the response in the constructor.
use Config\Services;
use CodeIgniter\API\ResponseTrait;

class MyLibrary
{
    use ResponseTrait;

    protected $response;

    public function __construct()
    {
        $this->response = Services::response();
    }

    // other code
}

Closing as not a bug.

Sorry to jump in the old thread. I believe this correlates with the error I experienced when I put ResponseTrait on a constructor. is it "illegal" if I put in a constructor?
use CodeIgniter\API\ResponseTrait;
use CodeIgniter\RESTful\ResourceController;

class Product extends ResourceController
{
    use ResponseTrait;

    public function __construct()
    {
        $this->respond(["status"=>TRUE,"message"=>"Passed"],200);
    }

    public function index()
    {
        echo 'blablabla';
    }
}

It is illegal. It won't work.

You cannot use return in __construct. Constructor always returns a new instance of the class.
$this->respond() uses $this->response inside, but $this->response is not set in the __construct() yet.
It will be set in initController().

It is illegal. It won't work.

You cannot use return in __construct. Constructor always returns a new instance of the class.
$this->respond() uses $this->response inside, but $this->response is not set in the __construct() yet.
It will be set in initController().

well noted.


Pin to httpbin 0.5.0.

The release of httpbin 0.6.0 seems to have broken pytest-httpbin in a surprising way. We want to pin that version out, and probably also alert @kevin1024 about the problem.
Resolves #4259.

Codecov Report

Merging #4261 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4261   +/-   ##
=======================================
  Coverage   88.66%   88.66%
=======================================
  Files          18       18
  Lines        2021     2021
=======================================
  Hits         1792     1792
  Misses        229      229

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 5dcbdb5...3a2ea9d. Read the comment docs.

OK, this is a really crazy rabbit hole - I think @Lukasa is actually more up what's going on than I.
I think the problem is caused by this commit to httpbin by @kennethreitz:
https://github.com/kennethreitz/httpbin/commit/2e94212886e4c9531b8ba7f55f4fb0b8134e10ac
which is an attempt to fix kennethreitz/httpbin#340
BUT I think it only fixes it on Gunicorn?  And pytest-httpbin uses werkzeug which has chunked encoding issues so it ends up causing problems: https://github.com/pallets/werkzeug/issues/1149

@kevin1024 we can remove that — I don't think it fixed anything.

@kennethreitz sweet, I think this problem should magically disappear in that case 🌟


v2.1.2: Can't connect to Windows7

With xfreerdp2 in openSUSE (Leap15.1) I get the following:
[06:59:59:191] [4137:4138] [INFO][com.freerdp.core] - freerdp_connect:freerdp_set_last_error_ex resetting error state
[06:59:59:192] [4137:4138] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpdr
[06:59:59:192] [4137:4138] [INFO][com.freerdp.client.common.cmdline] - loading channelEx rdpsnd
[06:59:59:192] [4137:4138] [INFO][com.freerdp.client.common.cmdline] - loading channelEx drdynvc
[06:59:59:556] [4137:4138] [INFO][com.freerdp.primitives] - primitives autodetect, using optimized
[06:59:59:599] [4137:4138] [INFO][com.freerdp.core] - freerdp_tcp_is_hostname_resolvable:freerdp_set_last_error_ex resetting error state
[06:59:59:599] [4137:4138] [INFO][com.freerdp.core] - freerdp_tcp_connect:freerdp_set_last_error_ex resetting error state
[07:00:00:959] [4137:4138] [WARN][com.freerdp.crypto] - Certificate verification failure 'unable to get local issuer certificate (20)' at stack position 0
[07:00:00:959] [4137:4138] [WARN][com.freerdp.crypto] - CN = my.windows.7.host
Password:
[07:00:05:824] [4137:4138] [INFO][com.freerdp.gdi] - Local framebuffer format  PIXEL_FORMAT_BGRX32
[07:00:05:824] [4137:4138] [INFO][com.freerdp.gdi] - Remote framebuffer format PIXEL_FORMAT_BGRA32
[07:00:05:848] [4137:4138] [INFO][com.winpr.clipboard] - initialized POSIX local file subsystem
[07:00:05:870] [4137:4138] [INFO][com.freerdp.channels.rdpsnd.client] - [static] Loaded fake backend for rdpsnd
[07:00:05:870] [4137:4138] [INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel rdpgfx
[07:00:06:091] [4137:4138] [INFO][com.freerdp.client.x11] - Logon Error Info SESSION_ID [LOGON_MSG_SESSION_CONTINUE]
[07:00:09:055] [4137:4138] [WARN][com.freerdp.core.orders] - Invalid bmf 129
[07:00:09:055] [4137:4138] [ERROR][com.freerdp.core.update] - [0x01] PatBlt - update_read_dstblt_order() failed
[07:00:09:055] [4137:4138] [ERROR][com.freerdp.core.update] - order flags 0d failed
[07:00:09:055] [4137:4138] [ERROR][com.freerdp.core.fastpath] - Fastpath update Orders [0] failed, status 0
[07:00:09:055] [4137:4138] [ERROR][com.freerdp.core.fastpath] - fastpath_recv_update() - -1
[07:00:09:055] [4137:4138] [ERROR][com.freerdp.core.fastpath] - fastpath_recv_update_data() fail
[07:00:09:055] [4137:4138] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -3
[07:00:09:055] [4137:4138] [ERROR][com.freerdp.core] - freerdp_check_fds() failed - 0
[07:00:09:055] [4137:4138] [INFO][com.freerdp.client.common] - Network disconnect!
[07:00:09:055] [4137:4138] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor
when connecting this way:
xfreerdp /u:username /d:domain /f -clipboard -wallpaper /v:my.windows.7.host /rfx  /network:auto +fonts /gdi:hw

@hendwolt thank you, already created #6300 that should address that.

#6300 fixes this problem. Applied on top of 2.1.2.

Installed latest git. Same error

@grosjo is the output all you got? There is a warning missing that should be printed if this specific issue occurs.
Please retest and add the specific command line you have used.

@akallabeth using remmina

@grosjo ok, and remmina is using the libraries you reference? Depending on installation method they ship their own copy of freerdp

it is all git based, recompiled by me

@grosjo could you check where exactly the thing is failing in a debugger? I see no place (apart from broken input data) this could fail in the way your log suggests unless you use the wrong version)
Can´t reproduce locally with current master, only with the version before the commit.

I cleanup all freerdp libraries and all remmina code and re-compile and re-install
It is working again now, still disconnecting times to times (but was working like a charm before recent update)

Initial reported issue is fixed on master and is staged for 2.2.0. @grosjo if you still observe this problem please open a new issue for tracking. Thank you.


use bytes

@arnodb, I reviewed https://github.com/Azure/azure-sdk-for-rust/pull/284. Let me know what you think of these changes.

@ctaggart I added 3 integration tests to the original branch so that we are sure we do not regress. If you rebase then you will see where the deserialization is broken.

The information about the const length is lost when the consumer needs to convert a digest to, e.g. a [u8; 8/16], which means the consumer will need to check the length once again.

I added an as_slice and implemented AsRef. We could also do a From in a similar way if needed.

Bytes are less easily manipulable than [u8]. In my case, instead of converting them back to a slice, I decided to convert my Digest to a Bytes and that requires a copy of the data, as far as I understand.

No copy, Bytes::from looks to be taking ownership. Also, FYI, Bytes is extremely cheap to clone if you want to you it. See https://docs.rs/bytes/1.0.1/bytes/struct.Bytes.html.

With as_slice it seems acceptable.


Fix global success variable in lapp process_default.

Coverage remained the same at 83.324% when pulling f85fc6e759a03d8b47a7f582c199a809f2615602 on IoriBranford:master into 0ba9c24000d3cad1d1d81a3dd233584b0bbd2950 on stevedonovan:master.


 However when I save the file it saves to the default directory rather than the .git directory.

Ahh, I should have read the instructions more carefully.
https://github.com/kemayo/sublime-text-git/wiki#commit

Honestly, this is something I've been meaning to handle more elegantly for years now. I keep getting hit by that trying-to-save thing myself, and I wrote this.


Accommodate FBxx for additional Exhaust Sensors

Accommodate FBxx for additional NOx Sensors.
In anticipation of request 21200507WW, https://www.sae.org/servlets/works/postDiscussion.do?comtID=TETES7Z&docID=&resourceID=840863&inputPage=showAll
Required to meet expectations of J1939-84 compliance test tool.
Applies to SPNs 3217, 3227, 3256, 3266, 7650, 7661, 7672, 7683
J1939DA will add the text below for the subject SPs
value of FB00h shall be provided when ambient or engine operating conditions do not permit the sensor to operate in data collection mode.
This may need to wait for the August committee meeting

The notes for Table A-1 are proposed to say:  (As shown in table A1 proposed additions draft)

Note
Table A1 Column Title
Comments

1
SPN (MY)
Entries in Table A1 represent a subset of those SPs which are expected in a DM24 message from an HD OBD ECU. Additional SPs from those listed here are expected in DM24 responses. Query support for individual SPs provided in a DM24 response that are not shown in Table A1 shall be assessed, but plausible values are not defined for the data returned. SPs which appear in DM24 and that indicate data stream support shall not provide FFh (not available/not supported) or FEh (error) indicators. They may provide FBh (special conditions) indicators.  The SPN column also identifies alternative content. Model years other than 2013 are shown in parentheses following SPN values.

Add
SP Data displays sent with the Special Conditions (FBh) indicators shall be accepted.
at the end of footnote [26]
[26] Missing SPN support, as compared to Table A1, shall be determined for the data presented by DM24 in test 6.1.4. Here only SPNs provided in the DM24 data from test 6.1.4 need be evaluated. As given in (d) data from non-OBD ECUs may be flagged with a warning or an informational message. Data that does not meet Table A1 plausibility limits, or that does not meet broadcast period requirements, may be counted as present (passing), without additional warning or failure messages than those generated for the plausibility limits, provided that it is not sent using the SAE J1939-71 Error (FEh) or Not Available (FFh) Indicators.

Please add PM sensor SPNs to it. SPN 7393 and SPN 5835 need to be added to this list.

As written it’s a general principle…. And should be accepted for any SP including the omitted PM mass sensors, SPN 7393 and SPN 5835

A more extensive list could include:
3216 3217 3221 3225 3226 3227 3231 3235
3255 3256 3260 3264 3265 3266 3270 3274
7649 7660 7661 7665 7670 7671 7682 7650
7654 7659 7672 7676 7681 7683 7687 7692
9177 9178
12754 12755 12750 12751

Implemented with Table A-1 content in 3.1.1.


Imported AKS clusters display controller/scheduler error

question/feature request:
Should I even be importing AKS clusters into Rancher or do I go to create cluster and fill in existing AKS cluster info?
When I import an existing AKS cluster, the controller/scheduler error issue comes up in the ui due the underlying kubernetes issue I wont get in to.
This does not happen when I create an AKS cluster via Rancher since that driver disables those settings/warnings.
Screenshot Imported AKS cluster:
https://screencast.com/t/p9cRYpAh
Rancher 2.2.4
Preferred solution for me would be to be able to import AKS clusters with the AKS driver if that is not already possible via create screen.
Less optimal but reasonable would be to give imported driver ability to disable the ui alert based on whether it is in Azure.
Many thanks, loving the ranch.

This is fixed here: https://github.com/rancher/rancher/issues/20066
v2.2.5 has the change

thanks @davidnuzik for looking into it. I upgraded to 2.2.5 and still seeing the issue on my previously (on 2.2.4) imported cluster.
https://screencast.com/t/RBSO1lCP8ZUa
Should I post to the other issue?

We can keep this issue @mikhail-arundo I reopened it; I was expecting fix to resolve this issue with imports but it doesn't seem to have covered that unfortunately.

Rancher 2.4.1  Kubernetes Version: v1.16.7 AKS still having the same problem.

CLosing in favor of https://github.com/rancher/rancher/issues/11496#issuecomment-727641496


When using OpenResty as a proxy for forwarding TCP traffic, how can I obtain the address of the backend server that the client wants to access from the captured traffic?

You need to self-parse your traffic data by ngx.req.socket, Or match your protocol in the preread buffer. It depends on your traffic data pattern.

您需要通过 自行解析您的流量数据ngx.req.socket，或者在预读缓冲区中匹配您的协议。这取决于您的流量数据模式。
Thank you very much for your response. I am a newcomer to OpenResty. Here is my configuration file, and I want to obtain the destination address from the raw data using ngx.req.socket, but it seems that I only get the request content without the desired destination address.

stream {
    lua_package_path "/usr/local/openresty/nginx/conf/lua/?.lua;;";
    preread_by_lua_no_postpone on;

    lua_add_variable $tcp_backend;

    upstream backend_tcp_server {
        server <IP_ADDRESS>:8888;
    }

    server {
        error_log "/usr/local/openresty/logs/TCP_error.log" debug;
        listen 8083;
        preread_by_lua_block {
            local sock = assert(ngx.req.socket(raw))
            local data, err = sock:receive("*a")
            if data then
                local data_str = tostring(data)
                ngx.log(ngx.INFO, "Raw data: ", data_str)
            else
                ngx.log(ngx.ERR, "Failed to receive data: ", err)
            end
        }

        # preread_by_lua_file "/usr/local/openresty/nginx/conf/lua/TCP_access.lua";
        # proxy_pass $tcp_backend;
        proxy_pass backend_tcp_server;
    }
}

I am hopeful to receive your guidance and insights on this matter.

No, I mean which have two approaches

using ngx.req.socket(raw) to hook the whole proxy_pass path, that means you can not using proxy_pass
using socket peek API in the preread phase to peek some traffic what do you use, that's can not break your proxy_pass https://github.com/openresty/stream-lua-nginx-module#reqsockpeek

No, I mean which have two approaches

using ngx.req.socket(raw) to hook the whole proxy_pass path, that means you can not using proxy_pass
using socket peek API in the preread phase to peek some traffic what do you use, that's can not break your proxy_pass https://github.com/openresty/stream-lua-nginx-module#reqsockpeek
My requirement is to obtain the destination address of TCP traffic redirected to OpenResty using iptables. I tried using 'peek' , as shown below, but I only received the transmitted content and did not retrieve the original destination IP.

        preread_by_lua_block{
            ngx.log(ngx.INFO,"coming in")
            local sock = assert(ngx.req.socket())
            local data = assert(sock:peek(1)) -- peek the first 1 byte that contains the length
            ngx.log(ngx.INFO, "1-----")
            data = string.byte(data)
            ngx.log(ngx.INFO, "2-----")
            ngx.log(ngx.INFO, "data："..data)
            data = assert(sock:peek(data+1)) -- peek the length + the size byte
            ngx.log(ngx.INFO, "3-----")
            local payload = data:sub(1) -- trim the length byte to get actual payload
            ngx.log(ngx.INFO, "payload is: ", payload)
        }

No, I mean which have two approaches

using ngx.req.socket(raw) to hook the whole proxy_pass path, that means you can not using proxy_pass
using socket peek API in the preread phase to peek some traffic what do you use, that's can not break your proxy_pass https://github.com/openresty/stream-lua-nginx-module#reqsockpeek
My requirement is to obtain the destination address of TCP traffic redirected to OpenResty using iptables. I tried using 'peek' , as shown below, but I only received the transmitted content and did not retrieve the original destination IP.

        preread_by_lua_block{
            ngx.log(ngx.INFO,"coming in")
            local sock = assert(ngx.req.socket())
            local data = assert(sock:peek(1)) -- peek the first 1 byte that contains the length
            ngx.log(ngx.INFO, "1-----")
            data = string.byte(data)
            ngx.log(ngx.INFO, "2-----")
            ngx.log(ngx.INFO, "data："..data)
            data = assert(sock:peek(data+1)) -- peek the length + the size byte
            ngx.log(ngx.INFO, "3-----")
            local payload = data:sub(1) -- trim the length byte to get actual payload
            ngx.log(ngx.INFO, "payload is: ", payload)
        }

sock:peek(1) not contains the length. why?

You need to write a Nginx module to get the original IP address.

不，我的意思是有两种方法

使用ngx.req.socket(raw)hook整个proxy_pass路径，这意味着你不能使用proxy_pass
在预读阶段使用socket peek API来查看一些流量你用什么，这不能破坏你的proxy_pass https://github.com/openresty/stream-lua-nginx-module#reqsockpeek
我的要求是使用iptables获取目标地址重定向到 OpenResty 的 TCP 流量。我尝试使用 'peek' ，如下所示，但我只收到了传输的内容，并没有搜索到原始的目标IP。

        preread_by_lua_block{
            ngx.log(ngx.INFO,"coming in")
            local sock = assert(ngx.req.socket())
            local data = assert(sock:peek(1)) -- peek the first 1 byte that contains the length
            ngx.log(ngx.INFO, "1-----")
            data = string.byte(data)
            ngx.log(ngx.INFO, "2-----")
            ngx.log(ngx.INFO, "data："..data)
            data = assert(sock:peek(data+1)) -- peek the length + the size byte
            ngx.log(ngx.INFO, "3-----")
            local payload = data:sub(1) -- trim the length byte to get actual payload
            ngx.log(ngx.INFO, "payload is: ", payload)
        }

sock:peek(1) 不包含长度。为什么？

The result I obtained using sock:peek(1) is a valid numerical value, representing the length of the message.

您需要编写一个Nginx模块来获取原始IP地址。

Could you please provide a more detailed explanation? thanks!

This module will not provide this function.
I think you can refer to
https://stackoverflow.com/questions/5615579/how-to-get-original-destination-port-of-redirected-udp-message.


Sniper Elite III

Meta-issue for Sniper Elite III.

[ ] Working?
[ ] ???

Tested on latest master. Doesn't work. Hangs on black screen at startup.
grvk.log
grvk trace.log
I think trace shows a shader failing to compile?

The game is trying to load an A2R10G10B10_UNORM value from an SRV. It's gonna take some work to handle that...


Extraction fixups, new table generation, allow reconstructing multiple files, etc.

multiple Retro events "root dirs" can be specified now at command line
command line arg --events-base / function arg events_base converted to --events-root and events_root, respectively
arg / command line arg angsens_model not required if not used (i.e., only used if a photon series is specified as hits)
command line args that can take multiple args now use nargs="+" rather than having to specify the command multiple times (action="append")
no longer have to specify --truth argument; if not specified, truth is extracted if truth.npy is found, or ignored if that is not found in the events root dir
reconstructions are forced to be stored in same directory structure as source files, avoiding issues / complexity with placing reco files somewhere else (and having to keep track if recos have been completed or not, etc.)
add updated ipython notebooks and data files used for clusters & definitions of how to produce dom tables: (cluster number, string, dom, random seed, number of events) for each table generated
add  notebooks/constants_for_spherical_coordinates_c_cl.ipynb which computes constants used in CLSim for specifying how to bin phi (azimuthal position of photon) and deltaphidir (relative direction of photon) dimensions
combining tables done more simply and generically; script renamed
generating tables assumes spice_3.2.1 ice model and angular sensitivity model as.flasher_p1_0.30_p2_-1; these things are hard-coded in various places, which needs to be fixed eventually...
set_explicit_dtype utility function moved to utils/misc.py as it's used by multiple modules now
retro/tables/clsim_tables.py:

step_size and t_is_residual_time are assumed to be 1 and True, respectively, if not found as keys in the table (all new tables have these as keys now, and only test tables that are now deleted or unused had different values, so no need to keep forcing these arguments to be passed around)
invalid docstrings are at least trimmed if not updated
add is_normed key so we can in the future handle both non-normalized and already-normalized tables (support still needs work in pexp function, etc.)
load_clsim_table_minimal now has include_overflow (default False) arg, and so by default removes overflow bins if loading from .fits file and hence the output is the same if loading from .fits or from our Retro table dirs (which contain .npy files)

 retro/tables/generate_clsim_table.py

set ftype to np.float32 to define bin edges; though must be converted to floats to pass to CLsim's Axis classes, the actual classes re-cast these as float32's internally, so this is the "roughly more correct" way to define binning now

add clean_recos.py util script to reset fit_status field on recos (might not be so useful now, though, that we have the option to force re-reconstructing events based on what fit_status is set to; see reco.py)
shell scripts updated with new arg names, utilize multiple args per arg (nargs="+" feature), and remove now unnecessary args

@philippeller this is the code I used for all the latest recos (both spicelea and spice3.2.1 tables)


Add Events

In this project I did the following

Add logic folder.
Add calculate.js file
Add operator.js file
Add README.md file

Thanks  @hiromataba 😎

Thanks @hiromataba sunglasses

You are welcome @KayLemba