Vim is unable to automatically detect my Python version

I installed Python 3.5 (tried with both 32- and 64-bit versions), but my Vim is unable to recognize the version.
Apparently I would have to recompile the whole Vim to work with any other version than Python 3.2.
Here are some of the errors I'm receiving, all of them basically leading up to Could not load library python32.dll, which I don't have because I'm using python35.dll.
This might not be a bug for you guys, but it's 2015 and every other text editor I've ever used automatically recognizes and can run any Python version I have installed.
I personally think it would be about time for Vim to upgrade its system a little, so it wouldn't be necessary for an everyday user to learn how to compile Vim and change its Python version.
If there's something I've missed, please elaborate, I'm just a beginner with Vim. But if this is the case and no change is going to be made, I feel like Vim is not too friendly for Python developers, and I will have to revert to an other editor. Which would be unfortunate, because Vim seems like an awesome text editor, but some of its features are still from 1990. Just my opinion.

2015-09-16 0:14 GMT+03:00 Markus Meskanen<EMAIL_ADDRESS>
I installed Python 3.5 (tried with both 32- and 64-bit versions), but my
Vim is unable to recognize the version.
Apparently I would have to recompile the whole Vim to work with any other
version than Python 3.2.
Here http://i.imgur.com/x1O5Sq9.png are some of the errors I'm
receiving, all of them basically leading up to Could not load library
python32.dll, which I don't have because I'm using python35.dll.
This might not be a bug for you guys, but it's 2015 and every other text
editor I've ever used automatically recognizes and can run any Python
version I have installed.

Which editors? Some of them use Python as an external executable and use
some IPC method for communication and thus do not require recompiling. Some
are written in Python (which has good backward compatibility inside one
major version) and do not require recompiling as well.
Vim on the other side is embedding Python using its C API. It cannot
possibly use any Python version, given that “backward compatibility” here
sometimes means that “we can replace C function with a C macros”. This is
rather unique: even NeoVim prefers to run python as a child process and
communicate with it using sockets, thus being version-independent as long
as neovim module runs on given Python version and implementation.

I personally think it would be about time for Vim to upgrade its system a
little, so it wouldn't be necessary for an everyday user to learn how to
compile Vim and change its Python version.

C API is the fastest way to work with Python. Everything else will be
slower. Also this code is already written.

If there's something I've missed, please elaborate, I'm just a beginner
with Vim. But if this is the case and no change is going to be made, I feel
like Vim is not too friendly for Python developers, and I will have to
revert to an other editor. Which would be unfortunate, because Vim seems
like an awesome text editor, but some of its features are still from 1990.
Just my opinion.
—
Reply to this email directly or view it on GitHub
https://github.com/vim/vim/issues/419.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to<EMAIL_ADDRESS>For more options, visit https://groups.google.com/d/optout.

Almost all editors afaik... Sublime, Emacs, Komodo Edit, even Notepad++. Sure most of them need some configurations, but usually it's just pointing the editor to your Python.exe or something similar.
I believe when you say that C API is the fastest way, but I can use Python just fine with all other editors without having to worry about too much. If I have to recompile the whole text editor just to change my Python version, it's not really intuitive and I'm not going to stick around with that editor for too long, regardless of how fast something is. You wouldn't drive a fast car with no wheel.

I am havin the same pleblem now. I have installed python27 (64 bit) and python35 (32 bit) in my computer, and they both work well. Recently, I start to use VIM. However, I unintentionally installed VIM 32 bit, and here came the tragedy: VIM 32 bit is NEITHER compatible with python27 64 bit which is now obvious, NOR with python35 32 bit since VIM seems to search python34.lib by default.
being frustrated......

you should be able to compile vim against python3.5 That should work then.

anyway, I think this issue can be closed

However, if the executable installer is used, the installer tries to find python34.lib by default. There seems to be no way of customizing it. :(
Still not smooth with open sources....

While I don't expect Vim to become an easy-to-use text editor for beginners or anything, the current Python support simply isn't enough for a standard coder. Vim doesn't support multiple Python versions, so you have to compile multiple versions of Vim. And every time you update your Python, you must recompile Vim. Other editors simply do Python better.

Well, I don't disagree with you. But please note that Vim can actually support python2X and python3X at the same time. I am still messing around with it.
No matter what you use, good luck !

@Weiming-Hu as I know vim can not use python2 and python3 at same time,it is different with neovim.
neovim use local python as executale.
so I have two ways to manager my neovim's python interface
let g:python_host_prog = '/usr/bin/python2.7'
let g:python3_host_prog = '/usr/bin/python3.5'

and
let g:python_host_prog = '/usr/bin/python2.7'
let g:python3_host_prog = '/usr/bin/python3.4'

To support multiple python versions, we need to change if_python drastically.
The linked python version is fixed at compile time, because the API of
pythonXX.dll will be changed between different versions.
Currently, (g)vim.exe is linked to pythonXX.dll directly, so we cannot support
automatic version detection. E.g.:
gvim.exe -+- python27.dll
          |
          `- python34.dll

To support automatic version detection, maybe we need different if_python DLL
for each version of python DLL.  E.g.:
gvim.exe -+- if_py26.dll -- python26.dll
          |- if_py27.dll -- python27.dll
          |
          |- if_py33.dll -- python33.dll
          |- if_py34.dll -- python34.dll
          `- if_py35.dll -- python35.dll

(I don't know how the other editors work around this.)

Vim can actually support python2X and python3X at the same time.

It doesn't mean Vim can easily support python 3.4 and 3.5 at the same time.
They are totally different things.

@k-takata Thank you for your comment. It is indeed what I mean. The linked python version is linked at compile time.
And could you, or anybody else, please help me with this? Below is part of the prints after I run :version in my vim.

Vim says it has suppport of python and python3.** I know I am using a 32 bit vim, and 64 bit python/python3, which aren't compatible.** Then, if I run :python print(1), I am supposed to get error like "unable to link ***.dll". However, my vim just crush and quit....... Anybody has an idea?
Thank you!

https://groups.google.com/d/msg/vim_dev/bg1MWfZfPAg/-PB3RXUSAwAJ explains the issue.
@Weiming-Hu looks like your Vim tried to load a wrong python dll, leading to a segfault. This is known to happen, when you compile your own vim with a different compiler than the python version, e.g. mingw versus visual studio.
I am closing this now.

2016-04-27 18:30 GMT+03:00 Jacky Liu<EMAIL_ADDRESS>
On Tuesday, April 26, 2016 at 4:29:07 PM UTC+8, Markus Meskanen wrote:

While I don't expect Vim to become an easy-to-use text editor for beginners or anything, the current Python support simply isn't enough for a standard coder. Vim doesn't support multiple Python versions, so you have to compile multiple versions of Vim. And every time you update your Python, you must recompile Vim. Other editors simply do Python better.
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

You can have the full power of Python from within your Vim only if Vim and Python can run in the same thread with the same memory space, this can only be achieved by embedding Python into Vim, not invoking it.
The dynamic run-time solution you mentioned is awfully slow and inefficient. Can you imagine an application's UI starts its back-end as an external process and then use a pipe or socket to communicate with it later? Its awful. UI and the back-end should be within the same process. Emacs even try to do data translation between Python and Elisp with its Pymacs, again, its awful, hopeless. Vim should never do that.

Both works well enough in Neovim. Though terminal UI is now part of
the same executable (will be different one later), Python communicates
through msgpack over a socket. This thing is obviously slower and in
some cases people need to do optimizations, but most of time this is
good enough. Also there are UIs other then terminal one and they all
use pipes or sockets. Unlike for Python support I did not hear about
problems with UI lags (though maybe because +python users are more
common here then GUI users; on the other side UI authors did not raise
issues regarding communication protocol speed so at least they think
that nothing can be done to speed up, at most they know how to write
their UI without it lagging).
Also this is how most web applications work. UI is in browser. Backend
is on server. And between them you have lots of routers which makes
the whole thing much slower then if UI communicates with Neovim
through msgpack. Still they work, using different hacks for different
situations (from having most of the code on the frontend, only sending
a few commands like “save {big blob}” to the backend once in a while,
to requiring client have his own server with controlled latency).

I suppose Python itself doesn't have good support for multiple versions within the same environment, try creating a Py2 list inside Py3. You can build a py3-enabled Vim and run py2 as an external process, or vice versa. You can have both Vims on your system and choose between them each time accordingly, I suppose you won't definitely need one project of yours half in Py2 and half in Py3.

Python itself (though not Python, but dynamic library loader,
ld-linux.so) has fine support here. Just distribution maintainers do
not bother compiling Python with --enable-shared, so python2 and
python3 effectively cannot be used together unless you go compile them
yourself.
On Gentoo --enable-shared is used, so no such problems here.
Note though that even if you have +python/dyn and +python3/dyn working
at the same time this does not mean that you can use single PyObject
in both interpreters. In this case :python environment is just as
isolated from :python3 as :lua is. So with vim.bindeval the fastest
way of transferring data is using Vim container objects (lists,
dictionaries, but not partials: last is read-only after creation but
still is a container (using list or dictionary should be faster
though)).

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to<EMAIL_ADDRESS>For more options, visit https://groups.google.com/d/optout.

Both works well enough in Neovim. Though terminal UI is now part of
the same executable (will be different one later), Python communicates
through msgpack over a socket. This thing is obviously slower and in
some cases people need to do optimizations, but most of time this is
good enough. Also there are UIs other then terminal one and they all
use pipes or sockets. Unlike for Python support I did not hear about
problems with UI lags (though maybe because +python users are more
common here then GUI users; on the other side UI authors did not raise
issues regarding communication protocol speed so at least they think
that nothing can be done to speed up, at most they know how to write
their UI without it lagging).
Also this is how most web applications work. UI is in browser. Backend
is on server. And between them you have lots of routers which makes
the whole thing much slower then if UI communicates with Neovim
through msgpack. Still they work, using different hacks for different
situations (from having most of the code on the frontend, only sending
a few commands like “save {big blob}” to the backend once in a while,
to requiring client have his own server with controlled latency).

Wait a minute ... I haven't tried neovim yet but I'm having my eye on it. If neovim runs Python as an external process, then does Python have the 'vim' module anymore ? Will Python be able to do 'import vim' and use its utilities within its environment?
Please elaborate, thanks.

2016-05-12 1:31 GMT+03:00 Jacky Liu<EMAIL_ADDRESS>

Both works well enough in Neovim. Though terminal UI is now part of
the same executable (will be different one later), Python communicates
through msgpack over a socket. This thing is obviously slower and in
some cases people need to do optimizations, but most of time this is
good enough. Also there are UIs other then terminal one and they all
use pipes or sockets. Unlike for Python support I did not hear about
problems with UI lags (though maybe because +python users are more
common here then GUI users; on the other side UI authors did not raise
issues regarding communication protocol speed so at least they think
that nothing can be done to speed up, at most they know how to write
their UI without it lagging).
Also this is how most web applications work. UI is in browser. Backend
is on server. And between them you have lots of routers which makes
the whole thing much slower then if UI communicates with Neovim
through msgpack. Still they work, using different hacks for different
situations (from having most of the code on the frontend, only sending
a few commands like “save {big blob}” to the backend once in a while,
to requiring client have his own server with controlled latency).

Wait a minute ... I haven't tried neovim yet but I'm having my eye on it. If neovim runs Python as an external process, then does Python have the 'vim' module anymore ? Will Python be able to do 'import vim' and use its utilities within its environment?
Please elaborate, thanks.

What makes you think there is something that may prevent import vim
from working? With python import hooks you may create any module you
like without actually having it on the filesystem, or having it in C
code like Vim. And really you do not even need import hooks to do
import sys; sys.modules['vim'] = my_vim_module, that can mock vim
module even in Vim itself if done before first import.
Of course, Neovim emulation of vim module has some different
behaviour (not fully compatible) and has completely different source
code. But yet many code written for Vim works.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to<EMAIL_ADDRESS>For more options, visit https://groups.google.com/d/optout.


Short solution needed: "golang or" (golang)

Please help us write most modern and shortest code solution for this issue:
golang or (technology: golang)
Fast way
Just write the code solution in the comments.
Prefered way

Create pull request with a new code file inside inbox folder.
Don't forget to use comments explain solution.
Link to this issue in comments of pull request.

golang or


wsconnect : Lost connection to node during wsconnect():

code:
nodList=["wss://bts.open.icowallet.net/ws", #鼓鼓节点
"wss://bitshares.dacplay.org/ws",
"wss://ws.gdex.top",
"wss://api.bts.ai"]
bitShares = BitShares(nodList)
error:
wsconnect : Lost connection to node during wsconnect(): wss://ws.gdex.top (3/-1) Retrying in 4 seconds
96 wsconnect : Lost connection to node during wsconnect(): wss://api.bts.ai (4/-1) Retrying in 6 seconds
96 wsconnect : Lost connection to node during wsconnect(): wss://bts.open.icowallet.net/ws (5/-1)

When I restarted the program, everything was all right, but there was an error message later.

are you 100% certain those nodes are working and can you connect with them using curl with the same machine?

On 12. Feb 2019, at 13:28, jackingyang<EMAIL_ADDRESS>wrote:
code:
nodList=["wss://bts.open.icowallet.net/ws", #鼓鼓节点
"wss://bitshares.dacplay.org/ws",
"wss://ws.gdex.top",
"wss://api.bts.ai"]
bitShares = BitShares(nodList)
error:
wsconnect : Lost connection to node during wsconnect(): wss://ws.gdex.top (3/-1) Retrying in 4 seconds
96 wsconnect : Lost connection to node during wsconnect(): wss://api.bts.ai (4/-1) Retrying in 6 seconds
96 wsconnect : Lost connection to node during wsconnect(): wss://bts.open.icowallet.net/ws (5/-1)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

yes i 100% certain those nodes are working

are you 100% certain those nodes are working and can you connect with them using curl with the same machine?
…
On 12. Feb 2019, at 13:28, jackingyang @.***> wrote: code: nodList=["wss://bts.open.icowallet.net/ws", #鼓鼓节点 "wss://bitshares.dacplay.org/ws", "wss://ws.gdex.top", "wss://api.bts.ai"] bitShares = BitShares(nodList) error: wsconnect : Lost connection to node during wsconnect(): wss://ws.gdex.top (3/-1) Retrying in 4 seconds 96 wsconnect : Lost connection to node during wsconnect(): wss://api.bts.ai (4/-1) Retrying in 6 seconds 96 wsconnect : Lost connection to node during wsconnect(): wss://bts.open.icowallet.net/ws (5/-1) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

how to solve this  problem ?

are you 100% certain those nodes are working and can you connect with them using curl with the same machine?
…
On 12. Feb 2019, at 13:28, jackingyang @.***> wrote: code: nodList=["wss://bts.open.icowallet.net/ws", #鼓鼓节点 "wss://bitshares.dacplay.org/ws", "wss://ws.gdex.top", "wss://api.bts.ai"] bitShares = BitShares(nodList) error: wsconnect : Lost connection to node during wsconnect(): wss://ws.gdex.top (3/-1) Retrying in 4 seconds 96 wsconnect : Lost connection to node during wsconnect(): wss://api.bts.ai (4/-1) Retrying in 6 seconds 96 wsconnect : Lost connection to node during wsconnect(): wss://bts.open.icowallet.net/ws (5/-1) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

how to solve this problem ?
thanks i have solve it

This most probably is the API server that isn't accepting your connections


Detect knope.toml in parent directories

I'd like to be able to run dobby without having to be in the exact directory containing the dobby.toml. I may make the last git commit from a child directory, and it would smooth out the workflow to not need to cd.
A couple thoughts:

This will include some sort of procdeural check through every parent directory
We may want to stop searching after checking the root of the current git repository (git rev-parse --show-toplevel).
What about git submodules where the submodule does not have a dobby.toml but the parent repo does?
Should there be support for a global dobby.toml, e.g. at ~/.dobby.toml or ~/.config/dobby/dobby.toml? I don't see a need for it, but I am sure someone will come up with something.
Related to the previous one: can settings cascade? Does it make sense for them to do so?

I'm looking into this and taking an initially naïve approach of recursively checking all parent directories until a knope.toml file is found. I think some of the questions/thoughts in the initial suggestion can be added later as an additional feature.
My questions with the above in mind;

Do we want to run the workflow commands from the same directory as the found knope.toml or from the current directory?
If there's appetite to support both, I assume we'll need some kind've configuration for the Command workflow step to be able to switch between the two, or perhaps a CLI argument to switch between the default and non-default option?


On "production" instances, createbuckets keeps waiting

From recent change in this file:
https://github.com/codalab/codabench/blob/develop/docker-compose.yml
The line 76 is stuck and returns this every five seconds:
createbuckets_1   | + echo ...waiting...
createbuckets_1   | ...waiting...
createbuckets_1   | + sleep 5

This happens when there is a MinIO associated to the instance (so the MinIO access key and secret key are defined) but the MinIO is external to the VM of the instance.
A simple fix is to cap to a maximum number of retries, or to add a condition depending on the configuration.
Warning: after changing this, it should be tested both in a "production" server and in a fresh local install

Strangely, we have this problem on the production server but not on the staging server

Strangely, we have this problem on the production server but not on the staging server

This was due to the config of the prod server (local minio keys were defined)


fix(region): vender update for vmware timeout

What this PR does / why we need it:

[x] Smoke testing completed

If yes, write the release branches name in the below format and submit the related cherry-pick PR:

release/3.10

/area esxi-agent

Close #15542


Fixing editable and non editable duplicate

For investigation based on https://github.com/jazzband/pip-tools/pull/1115#issuecomment-617468944

Superseded by https://github.com/jazzband/pip-tools/pull/1132


⚠ Bofrost.es has degraded performance

In e0644b7, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1762 ms

Resolved: Bofrost.es performance has improved in b94fb20 after 6 minutes.


Remove GDT from repo

GDT is moving to https://github.com/google/GoogleDataTransport
Three files are kept for now because of dependencies to the FirebasePerformance unit tests:

./GoogleDataTransport/GDTCORTests/Common/Fakes/GDTCORTransportFake.h
./GoogleDataTransport/GDTCORTests/Common/Fakes/GDTCORTransportFake.m
./GoogleDataTransport/GDTCORLibrary/Private/GDTCORTransport_Private.h

cc: @visumickey
#no-changelog

GDTCORTransport_Private.h is used. Without it:

GDTCORTransport_Private.h is used. Without it:

Agreed, but will defer the resolution of those three files to a subsequent PR.

Agreed, but will defer the resolution of those three files to a subsequent PR.


Question: Any considerations on ensuring this works on macOS and Linux?

Hi,
Very glad to see an open source cloud sync project in the works.  Any considerations on ensuring this works on macOS and Linux?

No, there are no plans for that because it relies on the API from Microsoft.


How do you obtain the data of ClimaX?

The RMSE data reported in your paper is:

However, the RMSE data in the original ClimaX paper is:

For instance, in our paper, the RMSE of u10 for a 72-hour lead time is stated as 3.70, whereas in the ClimaX paper, it is reported as 2.18. Could you provide clarification on this inconsistency?

Hi,
ClimaX training incorporates two parts: (i) Pre-training and (ii) Fine-tuning. The pre-training is done on historical CMIP6 data, and the resulting model is fine-tuned on the ERA5 dataset. Our study does not use any pertaining data, and we utilize a fixed number of observables (See Appendix B). Thus, for a fair comparison, direct comparison is not viable.
To obtain a fair comparison, we run the climax model without pre-training (with the exact set of hyper-parameters as provided in the official repo) and utilize the same data splits we use to train ClimODE.

In the fine-tuning phase, climaX uses more than 5 variables as input. climaX used 41 variables from era5 as input and 5 as output.  So, you train climaX from scratch (without fine-tuning) using only 5 variables as input the same as output and get results?

Due to academic computational constraints, we only utilize those 5 variables for all our experiments. To have a fair comparison, we train climax on these 5 variables (without any pre-training) and using the same set of hyper-parameters provided in their repo.

ok, tks

ClimaX was proposed as a foundation model for climate science. When we say ClimaX, we always refer to the pretrained model. The architecture itself without pretraining is not ClimaX, it is just a normal ViT. Moreover, the hyperparameters used for training ClimaX should not be the same as the ones used for finetuning a pretrained model. Please update your paper to clarify this, and the baseline you're comparing to should be pure ViT, not ClimaX.


Error when changing settings in Majestic.

Platform hi3516cv300
Sensor  ar0237_i2c
Here is the error log
Jul 23 14:33:52 openipc-hi3516cv300 kern.err kernel: [90823.849432] mmz_userdev:mmz_userdev_release: MMB LEAK(pid=837): 0x83380000, 77824 bytes, 'isp_stat_user'
Jul 23 14:33:52 openipc-hi3516cv300 kern.warn kernel: [90823.849475] mmz_userdev:mmz_userdev_release: mmz_userdev_release: mmb<0x83380000> mapped to userspace 0xb696d000 will be force unmaped!

It's warnings from vendor SDK. Nothing valuable is here.

After the error, the video disappears.
Example
Stream video codec changes.
Any change that reloads the sensor configuration.
Sometimes changes are applied without error.


38277 unable to rotate after rotating once

Issue: https://github.com/rancher/rancher/issues/38277

Problem

Encryption key rotation was failing, but looked like it was succeeding. This was caused by an issue where the follower controlplane nodes have the incorrect (previous) status post restart, and because we have already left the system-agent space, there was no way to run subsequent plans to ensure that the phase really was correct. Although this issue rights itself rather quickly (as in before the first status check) for specific cluster configurations (i.e. non split-role), for split-role configurations subsequent restarts would exacerbate the issue, creating a long enough gap that the time between verifying the follower nodes and running the next command was not long enough of an interval for all nodes to have the correct (identical) stage. Because failures are not very well reported, this was making the cluster appear as though encryption key rotation succeeded, when in reality encryption key rotation had failed at a previous step.
I'll update the rest of the description tomorrow.
Solution

Add a new instruction to verify the follower status if the same as the leader status post restart, and sleep until it is, or 10 seconds have passed (chosen at random, clusters could surpass this timeout but I haven't seen it happen with 1000s of secrets thus far).
Set the Ready condition on the controlplane to false, log a warning in the provisioning log, and return an error such that it is very noticeable and the intent is clear. This is also in parity with rke1 which states the following message: "encryption key rotation failed, please restore your cluster from backup".

At this point the planner is essentially blocked from moving onwards, however we generally want this to make as much noise as possible: a cluster in this state is NOT usable and any changes made after this point are effectively undefined behavior.
Testing

Engineering Testing
Manual Testing

I ran the automated tests in this PR for 3 node and 3 etcd, 2 controlplane, 3 workers configurations.
Automated Testing

The tests in this PR has been updated to test with a fresh cluster, then add 1000 secrets and rotate again, which should cover both cases.
QA Testing Considerations

Regressions Considerations

@Oats87 @jiaqiluo Recreated because drone/pr wasn't linking.


Support Android components in package.json

So at times plugin devs may need to extend  classes to be used for android services e.g Broadcast Receiver, Activities, Firebase Message Service.. etc .. it would be nice if we can do something like the following .... the key is used to name the .js output
"android": {
"components": {
"boot-receiver":  "relative/pathtofile"
}
}

Now we can throw any file we want hitting SBG in the components

Could you describe what would be better in this case instead of declaring your file in the appComponents section of the webpack config?

I was looking at making it simpler for the plugin creator and consumer .. so adding something like above into the package.json .. I'm sure a lot of devs might lose time after upgrading webpack only to realize they forgot to add the file into the webpack config ... if it's a no go I'll stick to slinging java 🙃

And how exactly would you benefit from this feature request? What exactly is the problem with the current way? Perhaps I'm missing your point and need additional info in order to understand everything.

Ok, I got your point :) I'll mark this as a feature request and currently, the workaround is to tell the plugin users to add the js/ts file with native extends into their appComponents section in the webpack config or to export the function which makes the extend in your plugin. The CLI team has some ideas about allowing plugins to create their own part of the webpack.config and at build time to merge plugins' configs and the app config but this is currently not planned and it's not known if or when will that happen.

Thanks for the update 😃


Doesn't support OSX 10.14

The documentation is not accurate; the current OSX download requires 10.15 or later, and unfortunately I am stuck with 10.14 because otherwise i lose the Adobe Create Suite which costs $1000.... and every other 32 bit app...  so please make an older version available for us poor 10.14 users.

Are you talking about the Mac App Store version, the .dmg download, or the .app download?

I tried both the .dmg download, and the .app download.
The Mac App Store will of course be 10.15 only as they are fairly mean in the store.

On May 29, 2024, at 11:45 AM, Terren @.***> wrote:
Are you talking about the Mac App Store version, the .dmg download, or the .app download?
—
Reply to this email directly, view it on GitHub https://github.com/terreng/simple-web-server/issues/202#issuecomment-2138048430, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ2FLG75UNFJW25XYTLZPDZEYO33AVCNFSM6AAAAABIPPW7VOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZYGA2DQNBTGA.
You are receiving this because you authored the thread.

It looks like Chromium no longer supports macOS 10.14 which is why we've also had to drop support.
Per the electron release notes:

Removed: macOS 10.13 / 10.14 support
macOS 10.13 (High Sierra) and macOS 10.14 (Mojave) are no longer supported by Chromium.
Older versions of Electron will continue to run on these operating systems, but macOS 10.15 (Catalina) or later will be required to run Electron v27.0.0 and higher.

I will update the documentation; thanks for pointing out the discrepancy.
To use Simple Web Server on older versions of macOS, you can just download one of the older versions on GitHub. I think 1.2.9 should work. The only thing that's changed since then is the addition of new languages and bug fixes.
Please let me know if it works and I'll update the documentation. Thanks!

yes, 1.2.9 did the trick and still runs.
Thanks for the help and for building this essential tool
Firefox allows the user to load JS files from their own hard drive, but Google is ridiculous.
e

On May 29, 2024, at 12:00 PM, Terren @.***> wrote:
It looks like Chromium no longer supports macOS 10.14 which is why we've also had to drop support.
Per the electron release notes https://www.electronjs.org/blog/electron-27-0:
Removed: macOS 10.13 / 10.14 support
macOS 10.13 (High Sierra) and macOS 10.14 (Mojave) are no longer supported by Chromium https://chromium-review.googlesource.com/c/chromium/src/+/4629466.
Older versions of Electron will continue to run on these operating systems, but macOS 10.15 (Catalina) or later will be required to run Electron v27.0.0 and higher.
I will update the documentation; thanks for pointing out the discrepancy.
To use Simple Web Server on older versions of macOS, you can just download one of the older versions https://github.com/terreng/simple-web-server/releases on GitHub. I think 1.2.9 should work. The only thing that's changed since then is the addition of new languages and bug fixes.
Please let me know if it works and I'll update the documentation. Thanks!
—
Reply to this email directly, view it on GitHub https://github.com/terreng/simple-web-server/issues/202#issuecomment-2138072291, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ2FLCQ2FYLKSFYHGJPI4TZEYQULAVCNFSM6AAAAABIPPW7VOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZYGA3TEMRZGE.
You are receiving this because you authored the thread.

Thanks for confirming that it works! I've updated the docs.


outerRangePadding property docs seems misleading

Right now the documentation  states that the xAxis outerRangePadding property works only on column visualizations, but it also works with bar visualizations (which are basically column visualizations with the axis inverted). I don't know if this is implied or something like that, but at least in my case I dismissed the property to not work with bar visualizations until I tried it out of curiosity.
This could be the case with innerRangePadding too, but I haven't tried.
I'm running version 1.0.1.

thank you for the feedback! we'll make sure to update in our next release.

Confirmed that both outerRangePadding and innerRangePadding work on both column and bar charts.


BigQuery and GCS e2e test scenarios

@itsankit-google @tivv @rmstar Please review.

Overall looks good, add cmek step in the BQ source related tests as well, it is used to encrypt data stored in temporary GCS bucket, can skip the verification step there as the temporary bucket gets cleaned up by the plugin at the end of the pipeline.

Added BQ source test case with cmek step.


Integration options with new CI build

Reviewing this as part of the larger CI project.
Ideally, Windows installers will be built automatically for new releases (starting with 10.9.0).
The CI in this repo seems sufficient to do so. The main question will be how to call it. I see 3 options:

Keep this repo entirely the same. Trigger a tag and, if needed(?), release build, manually from the main CI once the Windows installer completes.

This is a viable option but I'm not the biggest fan of the cross-repo dependency and full reliance on GitHubisms, if it even is possible (I've had a few people say it is but how to actually do this I'm not sure yet).

Ditch the idea of tagging this repo, use it as a submodule in packaging repo, call the CI directly from there.

I like this option a bit more, as then it could, in theory, all be run by a local runner or something. There would be no more tagged releases here though, unless they're added later by the process (maybe that's viable too?).

Move the CI entirely out of this repo and into the packaging repo, call CI as if it was a 3rd component.

I like this option the most, if only because then all the server CI is in one place. No tagging here at all really again unless really desired, the CI just exists in packaging, and a submodule provides the code for the CI to build.
So, putting it to the rest of the maintainers - which would you prefer.

Well as the maintainer is largely me, it's whatever you prefer. To keep with tradition, I'd like to have the release tag etc cut here as it has been done. I will defer to your preference though.

@joshuaboniface Feel free to link the workflow into the release process.
The current steps:

create a tag with the new version number
It downloads the prepared windows package with that number
it builds the tray app
it builds the installer

We should add a step where it uploads to the download repo as well.


script/build stops at random module / plugin (Arch Linux)

script/build seams to stop (nothing happens for at least 30min) at a random plugin / module. There are also no warnings / errors on the console.
This strange behavior occurred first 3 days ago.
What I have tried so far:

an old atom commit (which worked a month ago)
downgrading nodejs
removing $HOME/.atom and $HOME/.node-gyp
a different user account
rebooting
building manualy
building from the AUR

Neither of these steps helped.
I don't know what I have changed at my system since my last rebuild was a month ago.
My system:

Arch Linux x86_64
PYTHON=python2
npm version: 2.4.1
nodejs version: 0.10.36

I know this might sound silly, but have you checked that you have enough free disk space?

Jes. I have 500GB free disk space and 5GB free RAM.

I can confirm that. Sole solution yet is to repeat the building process very often until it works. (My setup is very similar to mensinda's.)

I did some further testing with a precompiled Atom version. I found out that the random stop problem also occurs when installing single plugins via the Atom GUI or apm (it either runs forever or is done in less than 30 seconds). It also does not matter if a plugin is or was already installed.
Using the --verbose option showed even stranger behavior: It is not even random if it stops, it is also random when the build process stops. There are basically 2 different points where it is stoping (as far as I know):

apm only prints Installing <x> to $HOME/.atom/packages
after an entry like REQUEST emitting complete <random path>

Also the number of REQUEST entries is random (from 0 to some to a lot).
Is there a way to increase the verbosity level even further? Or is there a specific function that is constantly called?

I've seen reports of that happening as well on arch. It just started happening with 0.176 I believe, but I'm not able to reproduce it.

With the last system update I get a timeout error when the build process has stopped for more than a minute (I do not know how big the timeout exactly is):
Unable to download https://www.atom.io/api/packages/<plugin>/versions/<version>/tarball: connect ETIMEDOUT

This error message replaces the run-until-ctrl-c behavior. Additionaly this happens ALSO in the 0.177.0 release, so it has nothing to do with the last atom commits.

how can I install random module in ubuntu 14.04 for ndnSIM?


ResponseTopic and CorrelationData don't seem to work

Hi, I was playing a little bit with mochi and it looks interesting. I did a test setting/sending ResponseTopic and CorrelationData when publishing a message using python paho mqtt client, but it doesn't look like it is working, i.e. subscriber didn't get ResponseTopic nor CorrelationData in received message. Same test with mosquitto broker worked, so the test should be ok.

Hi @UrsBisang!
The MQTTv5 spec: https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901052 talks about response information here. Now that I am reading it again, it seems like it refers to response information in the Connack packet only, rather than all response packets.
I will try to correct this later this evening - sorry for the oversight.

Hi, thanks! Here some more information that might be helpful: I tried to use ResponseTopic and CorrelationData to implement a request-response style messaging pattern.
Here the test code I used (Sorry, it's in Python):
pip install paho-mqtt
import paho.mqtt.client as mqtt
import paho.mqtt.packettypes as packettypes
def on_connect(client, userdata, message, tmp=None, properties=None):
client.subscribe("test/request")
properties = mqtt.Properties(packettypes.PacketTypes.PUBLISH)
properties.CorrelationData = "".encode('utf-8')
properties.ResponseTopic = "test/response"
client.publish("test/request", "test message", properties=properties)
def on_message( client, userdata, message, tmp=None):
print(f"message properties: {message.properties}, payload={message.payload}")
client = mqtt.Client("test_client", protocol=mqtt.MQTTv5)
client.on_message = on_message
client.on_connect = on_connect
client.connect("localhost")
client.loop_forever()

Running it against mochi broker gives the following output:
message properties: [MessageExpiryInterval : 86400], payload=b'test message'
Running it against mosquitto broker gives the following output which is what I would expect to get:
message properties: [ResponseTopic : test/response, CorrelationData : b''], payload=b'test message'

Fixed in v2.1.0 - Thank you @UrsBisang - your python example was very helpful in testing the solution!

Thanks a lot for fixing it!


Catalog Answers not allowing not-strings

I at trying to start a Helm chart (gitlab). I would like to add an answer with a boolean. I have added it in the ui like so:

The resulting json is a literal string "false". Here is a screenshot of this specific field. To make it more concise, I eliminated other fields from the result.

Is there any way to specify a non-string value in an answer?

Useful
Info

Versions
Rancher v2.0.6 UI: v2.0.61

Access
local admin

Route
catalog-tab.launch

Answers/helm variables are always strings.

@vincent99 I'm not sure that is true. According to Helm's site, Helm charts allow non-string values: https://docs.helm.sh/chart_best_practices/#make-types-clear. If Rancher answers doesn't allow non strings, it looks like this could make using some helm charts difficult. You are obviously more knowledgeable than me on this subject, but it looks like Helm allows non strings.

We use --set-string
https://github.com/rancher/rancher/blob/51d8300cf401825b3d06c3a7a8316d5909deac1b/pkg/controllers/user/helm/common.go#L181-L192
because it is predictable; --set does automatic type inference and causes seemingly (to the user) random problems depending on the value they provide (e.g. https://github.com/helm/helm/issues/1707)

Ok, fair enough. Is there any way to force a non-string? Right now, the Gitlab Helm chart has fields that require non string values: https://gitlab.com/charts/gitlab/blob/master/doc/installation/command-line-options.md
Configuring Gitlab seems to be impossible with Rancher 2 if there is no way to specify a non string value. Is that correct?

@vincent99 I opened a ticket for this on the Gitlab team, and they have expressed concerns about non string values across many charts. Is there any way to go around this?
https://gitlab.com/charts/gitlab/issues/616

Would creating a questions.yaml help with this issue? This ticket talks about quotes on boolean values #13843. Has that been changed to force booleans to be strings as well?

Having the same problem as @wyattjsmith1 I have just deployed the "master" Docker image. Unfortunately I don't see any difference. Value certmanager.install = false leads to "certmanager.install":"false" in answers.yaml (looks more like JSON btw) and also the same error message. Docker master was pushed yesterday - should it contain the fix already?

All that was done so far is reverting using set-string back to set, which was only in 2.0.7-rcX and never shipped in a release.
The input to helm is still all strings and they have to do type guessing, it doesn't matter whether the yaml says  false or "false"* because both result in heml … --set x=false. (And quoted keys are perfectly valid yaml, as is anything that's valid json because yaml is a strict superset of yaml. The  answers "file" isn't actually sent anthere anyway, it's just for display and the answers are sent with the JSON in the POST/PUT request.)
So it would seem boolean answers have never worked, and don't work in helm.  Answers/set isn't the same as editing values.yaml.

@vincent99 I am starting to think that this ticket and #14608 are the same bug with different symptoms. I have noticed that some parameters are not set for some reason, though there seems to be no logic to it. Here is a chart of working and not working parameters. I derived this by adding or removing these values to see if there is a change in the output:

Working

gitlab-runner.install (Boolean)

Not Working

global.ingress.configureCertmanager (Boolean)
certmanager-issuer.email (String)

If you look at the other ticket, people are posting other parameters that aren't working. I originally thought it had to do with subcharts, but it looks like gitlab-runner.install is working.

I'm going to close this as a duplicate of https://github.com/rancher/rancher/issues/13158


Ported Tomas Akenine-Moller's triangle-AABB implementation to javascript

Tomas Akenine-Moller's Reference C implementation can be found here.
Theory page here.
In preparation for uniform grid acceleration in Ambient Occlusion as well as future spatial datastructures.
Should this actually make its way into Cesium at some point?

Coverage decreased (-0.4%) to 93.632% when pulling 9d61bea90f52aa4db99803354be8989b30e2823d on triBoxOverlap into 7308cb0bc36a39853da24354febc2db45a29245c on ao-master.

Should this actually make its way into Cesium at some point?

Yes, something like a CesiumCore or CesiumGeometry module as part of the Cesium 2.0 effort, https://github.com/AnalyticalGraphicsInc/cesium/issues/2524.

Updated: addressed the style issues and added Cesium's AxisAlignedBoundingBox. I will add tests in another commit.

Looks good.  Thanks for updating LICENSE.md.

Coverage decreased (-0.02%) to 94.009% when pulling c3da1de7fce79b79b94df81f16ef27e8f132d87b on triBoxOverlap into 7308cb0bc36a39853da24354febc2db45a29245c on ao-master.

Coverage is only 93% for this file.  Can we get it to 100%?
https://coveralls.io/builds/6802561/source?filename=lib%2FtriangleAxisAlignedBoundingBoxOverlap.js

I got coverage to go up a little by fiddling with some of the specs, but as discussed offline getting coverage to 100% will be difficult as the algorithm is heavily optimized for early return.
I think we have enough specs to be pretty confident in this port of the algorithm, though.

Another thought: could we get in touch with Dr. Akenine-Möller about late return edge case triangles?

I'll merge this now, and will try to get you in touch offline.


bind: pass &v[0] in direct call to C

In Go 1.6, the cgo checking rules are more precise when they see an
address operation as an argument to the C function.  When you pass &v[0]
to a C function, the cgo check just verifies that v itself does not
contain any pointers.  When you write p := &v[0] and then pass p to
the C function, the cgo check is conservative: it verifies that the
entire memory block to which p points does not contain any pointers.
When the bind function is called by code that passes a slice that is
part of a larger struct, this means that the cgo check will look at the
entire larger struct, not just the slice.  This can cause a surprising
run time failure.
Avoid this problem by rewriting the code slightly to pass &v[0] in the
call to the C function itself.
In particular this fixes the tests of github.com/jmoiron/sqlx when using
Go 1.6.

I see. Thank you.


Windows install failing with ERR! Error: UNKNOWN, The operation completed successfully.

Attempting Windows 7 install with "node cli.js install npm -gf" fails during unpacking.
A known dependency/version problem?  Thanks for any clues!
Here is the tail of the log (starting just before the error):
...
silly chmod lru-cache.js 644
verbose gunzed C:\Users\Bernie\AppData\Local\Temp\npm-1318107600733\131810760073
3-0.32579671987332404\contents___package.npm\package
verbose rm'ed C:\Users\Bernie\AppData\Local\Temp\npm-1318107600733\1318107600733
-0.32579671987332404\contents\package
ERR! couldn't unpack C:\Users\Bernie\AppData\Local\Temp\npm-1318107600733\131810
7600733-0.32579671987332404\tmp.tgz to C:\Users\Bernie\AppData\Local\Temp\npm-13
18107600733\1318107600733-0.32579671987332404\contents
ERR! Error: UNKNOWN, The operation completed successfully.
ERR!  'C:/Users/Bernie/AppData/Local/Temp/npm-1318107600733/1318107600733-0.3257
9671987332404/contents/___package.npm/package'
ERR! Report this entire log at:
ERR!     http://github.com/isaacs/npm/issues
ERR! or email it to:
ERR<EMAIL_ADDRESS>ERR!
ERR! System Windows_NT 6.1.7601
ERR! command "node" "C:\Users\Bernie\npm\cli.js" "install" "npm" "-gf"
ERR! cwd C:\Users\Bernie\npm
ERR! node -v v0.5.8
ERR! npm -v 1.0.94
ERR! path C:/Users/Bernie/AppData/Local/Temp/npm-1318107600733/1318107600733-0.3
2579671987332404/contents/___package.npm/package
ERR! code UNKNOWN
verbose exit [ 1, true ]

In fact, it does not work on windows. Yes, it installs but install packages easily as on Linux, you can not. If you really want to install a check for the following:

you do not have cygwin
you have installed msysgit use this particular network because the installer if you install the full package you need to first upgrade.

Only after that I established npm, but when you install the modules facing new restrictions on windows:

Utility "basic-bsdtar.exe", which is used to extract the tgz-file is not able to copy the source file if it sees that used symbolic links (apparently you do not download this utility does not work just unzip the package, so I was also )
Windows has a limitation on the length of the command line and when npm repackages package file is created empty when tgz package multiple files.

Thanks for the tips, Sobic!  I will try again.
On Sun, Oct 9, 2011 at 9:01 AM, Sobic
<EMAIL_ADDRESS>wrote:

In fact, it does not work on windows. Yes, it installs but install packages easily as on Linux, you can not. If you really want to install a check for the following:

you do not have cygwin
you have installed msysgit use this particular network because the installer if you install the full package you need to first upgrade.

Only after that I established npm, but when you install the modules facing new restrictions on windows:

Utility "basic-bsdtar.exe", which is used to extract the tgz-file is not able to copy the source file if it sees that used symbolic links (apparently you do not download this utility does not work just unzip the package, so I was also )
Windows has a limitation on the length of the command line and when npm repackages package file is created empty when tgz package multiple files.

--
Reply to this email directly or view it on GitHub:
https://github.com/isaacs/npm/issues/1519#issuecomment-2337057

next version addresses this, already fixed in HEAD.


I strongly advise everyone here to consider what they would rather have -- no intersection or the option that they dislike. And take it from there.

While I would love to find a compromising middle ground or a consensus, it just seems unlikely at this point.
First of all, in the last few comments Mike is saying that " If [proposal 4] were accepted, I'd probably give up on trying to improve typing in python".  I think it's fair to say he's not willing to compromise.  (One compromise I suggested was to add a warning when T & Any has properties accessed.)
Second, if you go back to the very start of #1, there remains fundamental misapprehensions that motivate options 1, 3, 5, and 6.  Namely,

the idea that T & U is narrower than T, and
the rejection of the "any-substitution principle".

The first idea seems correct at first, but the issue is that a "type" as far as a type checker is concerned has to encode both the valid subtypes and the valid interface (OP(x)).   And therefore unions T | U produce subtypes that are broader than T and U and interfaces that are narrower than T and U; and intersections produce subtypes that are narrower than T and U and interfaces that are broader than T and U.  This is the central motivation for all of the alternative options. It is an attempt to have the narrowing behavior for intersection interfaces.  But this is literally the opposite of what intersections normally do!
The "any-substitution principle" is that a type expression involving a specified type T should not create any errors when T is replaced with Any.  All of the special-casing proposals presented so far break this.  And it's a huge problem if you have ever written any annotations for a project.  I have many, many type annotations pull requests.  I can say from experience that it's a fairly regular occurrence that things get swapped to Any fairly often.  And the idea that has been repeatedly suggested (just find concrete types) is not realistic.  Swapping to Any should not create any type errors.  That will just create a lot of work, and delay code reviews, for what should remain a simple task.
While I recognize that there is room for making things practical rather than pure, I think breaking these kind of basic rules is going to lead to more problems as typing evolves.  For example, if higher-kinded types are added, there may be many more synthetic types.  And with synthetic types, we may see synthetic intersections deep in synthesized where there may not be an opportunity to even stifle type errors (or that will produce very convoluted errors).
Finally, there have been some absolutely disrespectful comments, and I don't think that it makes sense to work with people that insist on that kind of behavior.
So, my preference is to simply write a PEP, and if the others want to write one or two more PEPs, I think they should do so.  If anything, maybe this exercise will produce the clarity that's been missing.

@NeilGirdhar

the idea that T & U is narrower than T, and

the rejection of the "any-substitution principle".

I think I see what you're getting at with these two points, but I'm not entirely convinced the first one is a hard requirement (I'll invert them for discussion)

T & U is wider than T

I see how if T is Any, this becomes Any & U is wider than Any, which doesn't make sense. It's been discussed that Any is the top and bottom type, which I think would mean Any & U is both wider and narrower than Any. I'm not sure I buy this one as a hard requirement.

any-substitution principle

This one I buy much more. If you replace a more specified type with Any, it shouldn't create errors - that would be very strange indeed! But I'm not convinced that option 5 is in violation of this. If T & U -> Any & U, all the properties of T just become Any, while the properties of U remain - I don't see any issues here.

I see how if T is Any, this becomes Any & U is wider than Any, which doesn't make sense. It's been discussed that Any is the top and bottom type, which I think would mean Any & U is both wider and narrower than Any. I'm not sure I'm convinced this tells us much in the Any case.

Sorry, I was just speaking loosely to give a feeling for the general principle.  For the exact rules, please see Eric's comment (you'll have to search for it, or wait until I write the PEP).  If I remember correctly, (T & Any).x is T.x & Any if T has x, and Any otherwise.  The key point being that it's wider than T.x.

But I'm not convinced that option 5 is in violation of this. If T & U -> Any & U, all the properties of T just become Any, while the properties of U remain - I don't see any issues here.

The problem is that if T and U contain x, then in the first case you have (T & U).x = T.x & U.x whereas in the second case you have—according to option 5—(T & Any).x = T.x.  If U.x is:

Any
a function with more overloads than T.x, etc.
then, the substitution causes type errors.

If I end up writing up a PEP, I'll add this principle as a general principle so that future typing proposals can make use of it.

Sorry, I was just speaking loosely to give a feeling for the general principle. For the exact rules, please see Eric's comment (you'll have to search for it). If I remember correctly, (T & Any).x is T.x & Any if T has x, and Any otherwise. The key point being that it's wider than T.x.

I think I found it again: https://github.com/CarliJoy/intersection_examples/issues/1#issuecomment-1657265867
So these rules come out of the symmetry with union? I follow your reasoning here, but I think there's still an open question about what T.x & Any might be interpreted as. You're right that this isn't what option 5 subscribes to but it might be there exists another interpretation of how this type gets used.

The problem is that if T and U contain x, then in the first case you have (T & U).x = T.x & U.x whereas in the second case you have—according to option 5—(T & Any).x = T.x.

Point taken on the substitution part as well. If we want to adhere to these principles option 5 would not work.
Let's assume for a moment that we go with (T & Any).x = T.x & Any (currently as presented by option 4 I believe). What does the type checker do with T.x & Any? I'm not sure I have an intuition about how this type would behave, which suggests that maybe there's some wiggle room here. Is it possible there exists an interpretation of this that has all the practicality of option 5?

To delve into the more practical, I'll put this thought into an example:
class T:
    x : int

inst: T & Any = T()

z = inst.x # So this is now type int & Any
z += 1 # Definately valid
z = z + 'test' # Now here we get the controversial bit.

My hunch is that (by some means) the final line should be invalid, but here's the problem. If we say it's valid, how is this any different from z just being Any? Similarly if we say it's invalid, how is this any different from just saying is type int? For int & Any to be a type in it's own right, surely it must behave differently to both Any and int?

Ok slightly radical idea: Intersections between two classes where the types are different on two of their attributes & methods are banned on access (as in option 6, but expanded to methods). I appreciate this might go further than LSP but it has some advantages:

mixing two classes together always produces the intersection (may not be a requirement, but it's handy!)
(Any & T).x must condense to T.x because for whatever Any is for it to be valid in an intersection it must subscribe to this rule.
Callable intersections go away (no longer valid)
By banning on access we allow classes to be merged that have attributes that clash, so long as they aren't used
It works with the any-substitution principle

It subscribes to this modified set of rules:
(A & B).x:
Invalid if x is missing from both A and B
A.x/B.x if x is present on A or on B (inclusive or)
Invalid if x is present on A and on B and the types are different.

The only real disadvantage I see is we lose the utility of combining methods of the same name into being overloads, but in comparison to all of the advantages this feels like a small loss. Thoughts?

Intersections between two classes where the types are different on two of their attributes & methods are banned on access

That's an interesting idea. That restriction makes many of the problems fall away.
Question to others on the thread: Does that restriction eliminate any important use cases that you've identified for intersections? It would preclude my BookMovie example above, but that was a toy example intended to demonstrate an inconsistency, not a real-world example that I think is important to support.
@DiscordLiz said "I would not want to use an intersection with non-disjoint types. It generally doesn't make sense to.". This proposal effectively takes advantage of this observation and codifies it into the rules.

The only real disadvantage I see is we lose the utility of combining methods of the same name into being overloads

I see this as more of an advantage than a disadvantage. Combining methods of the same name into overloads is problematic because overloads are ordered and intersections are not.  This proposal eliminates this problem entirely.
One issue that would need to be tightened up is the specification of what it means for two types to be "different". We've talked in the past about "bidirectionally compatible types" (type A is compatible with B and vice versa), but I'm not sure what it means for two types to be "different". Any is bidirectionally compatible with int; are these two types "different"? Is Literal[True, False] "different from" bool? What about two structural types with different names but the same definition? Would it make sense to replace "types are different" with "types are not bidirectionally compatible"?
Another issue to consider is related to method access and binding. If classes A and B both define def method(self) -> Self, how would (A & B).method work? Instance and class methods are bound and partially specialized at access time, so the type of A().method is () -> A and the type of B().method is () -> B. Does that mean the two are "different types" according to the proposed rule above? Or perhaps binding & partial specialization should be done with the intersection type, which would produce () -> A & B in both cases. (Note: Method binding and partial specialization is currently under-specified in the typing spec. It's one of the areas I hope to firm up in the upcoming months.)

@NeilGirdhar

While I would love to find consensus, it just seems unlikely at this point.

First of all, in the last few comments Mike is saying that " If [proposal 4] were accepted, I'd probably give up on trying to improve typing in python". I think it's fair to say he's not willing to compromise. Compromises I'd like to consider include:

adding an optional warning when T & Any has properties accessed in a way that violates proposal 5—this would essentially mean that users would optionally have proposal 5 at the discretion of type checker authors,
adding an additional operator SafeIntersection[T, U], and
adding additional constructs to declare that certain interfaces can't be broadened.

Some of those compromises are things I've already said I'm fine with, but re-raised a question about something where someone else said it would be a problem.  See here
I'm very much still wanting to work towards something that can work for everyone, but in unequivocal terms, if option 4 is accepted as-is, I'm personally done with python typing. There are enough issues with it for my real world use that this would kill typing usability for me long term as this started to be used in that fashion, and I've already explained how those would manifest.
The fact that I am opposed to one option, but still working towards finding others that meet multiple groups needs is not an unwillingness to find compromise at all, but an unwillingness to accept a solution which has major flaws for my own use when there is more to explore.

@mark-todd

Ok slightly radical idea: Intersections between two classes where the types are different on two of their attributes & methods are banned on access (as in option 6, but expanded to methods). I appreciate this might go further than LSP but it has some advantages:

I was viewing option 6 as also banning methods, properties, and functions with diferring types on access as well when I wrote it. The primary reason for allowing overlap at all is the unavoidable overlaps of things inherited from object, but the rule "just working" without special casing those methods was good.
@erictraut

One issue that would need to be tightened up is the specification of what it means for two types to be "different". We've talked in the past about "bidirectionally compatible types" (type A is compatible with B and vice versa), but I'm not sure what it means for two types to be "different". Any is bidirectionally compatible with int; are these two types "different"? Is Literal[True, False] "different from" bool? What about two structural types with different names but the same definition? Would it make sense to replace "types are different" with "types are not bidirectionally compatible"?

bidierectionally compatible is fine for what I was considering when proposing that, I can come up with more formal definitions as needed if this approach is viable for others here.

Another issue to consider is related to method access and binding. If classes A and B both define def method(self) -> Self, how would (A & B).method work? Instance and class methods are bound and partially specialized at access time, so the type of A().method is () -> A and the type of B().method is () -> B. Does that mean the two are "different types" according to the proposed rule above? Or perhaps binding & partial specialization should be done with the intersection type, which would produce () -> A & B in both cases. (Note: Method binding and partial specialization is currently under-specified in the typing spec. It's one of the areas I hope to firm up in the upcoming months.)

methods should be fine here with how I was considering the option when I proposed it, the type of (A & B).method would bind to (A & B), We can use type[T] / Self here to improve reasoning about this when considering unbound methods prior to binding. This may sneak a small bit of special casing into implementations that don't understand method binding or descriptors though, and is definitely worth making sure we spell out to avoid diverging implementations.

Callable intersections go away (no longer valid)

They only go away partially. Please do not ban callables from intersections entirely, we have a stated use case in this repo that still works with this option.
Callable[int, T] & type[T] where type[T] is callable with a single int plugs a type hole that exists to make subclassing easier, but LSP unsafe with __init__

@NeilGirdhar

Finally, there have been some absolutely disrespectful comments, and I don't think that it makes sense to work with people that insist on that kind of behavior.

You just accused another collaborator of not being willing to compromise in the same post when they are here still working on a compromise.  I don't think competing PEPs are the answer. We can make the PEP stronger by finding what issues people have with it, and that includes any issues you have with it.

@erictraut

Question to others on the thread: Does that restriction eliminate any important use cases that you've identified for intersections? It would preclude my BookMovie example https://github.com/CarliJoy/intersection_examples/issues/31#issuecomment-1866869547, but that was a toy example intended to demonstrate an inconsistency, not a real-world example that I think is important to support.

Sort of? I said an intersection would only make sense to me when I care about disjoint types, and that's true, but there are cases for extending base functionality beyond what this would support. However, the thing that @mark-todd  and @mikeshardmind went back and forth on in discord and here with type and object or Inherit allowing multiple type parameters in an ordered fashion can address this case without intersections needing to be the tool for this, so I think it's okay to directly state this in a "why this behavior" wasn't included section for the pep since we have a potential path for that behavior in a different mechanism that can be worked on in the future without intersections blocking it.

I want to remark again that it seems some of the recently posted examples are flawed, for example in https://github.com/CarliJoy/intersection_examples/issues/31#issuecomment-1885092808, inst.x should simply be int due to invariance, even under proposal ④. This was only recently fixed in type-checkers (https://github.com/microsoft/pyright/issues/5933, https://github.com/python/mypy/issues/3208, thanks @mikeshardmind for raising the issue).
I looked at the possible cases and arrived at the conclusion that the following inferences should hold:

X ≔ (A&B).foo
B.foo untyped
B.foo co (<:T)
B.foo inv (==T)
B.foo contra (:>T)

A.foo untyped
X==Any
X<:(Any&T)
X==T
X:>(Any&T)

A.foo co (<:S)
X<:(S&Any)
X<:(S&T)
X==T if T<:S else ↯
T<:X<:S if S:>T else ↯

A.foo inv (==S)
X==S
X==S if S<:T else ↯
X==S if S==T else ↯
X==S if S:>T else ↯

A.foo contra (:>S)
X:>(S&Any)
S<:X<:T if S<:T else ↯
X==T if S<:T else ↯
X:>(S&T)

In particular, a type-checker should be able to deduce that
class A:
    foo: int
    bar: ReadOnly[int]  # Not implemented, but proposed in typing channel.

class B:
    foo: Any
    bar: Any

(A & B).foo  # always int
(A & B).bar  # int & Any

@erictraut

I see this as more of an advantage than a disadvantage. Combining methods of the same name into overloads is problematic because overloads are ordered and intersections are not.  This proposal eliminates this problem entirely.

That's a good point - I hadn't considered it, but you're right it saves us from that issue.

One issue that would need to be tightened up is the specification of what it means for two types to be "different". We've talked in the past about "bidirectionally compatible types" (type A is compatible with B and vice versa), but I'm not sure what it means for two types to be "different". Any is bidirectionally compatible with int; are these two types "different"? Is Literal[True, False] "different from" bool? What about two structural types with different names but the same definition? Would it make sense to replace "types are different" with "types are not bidirectionally compatible"?

One property of the above description is I was trying to make A.x and B.x effectively interchangeable. If we consider Literal[True, False] to be identical to bool, it might matter which from A and B gets chosen.

Another issue to consider is related to method access and binding. If classes A and B both define def method(self) -> Self, how would (A & B).method work? Instance and class methods are bound and partially specialized at access time, so the type of A().method is () -> A and the type of B().method is () -> B. Does that mean the two are "different types" according to the proposed rule above? Or perhaps binding & partial specialization should be done with the intersection type, which would produce () -> A & B in both cases. (Note: Method binding and partial specialization is currently under-specified in the typing spec. It's one of the areas I hope to firm up in the upcoming months.)

Interesting edge case! I think these would be compatible, returning the new type (A & B) as Self, like you describe. If we found down the road though that this has to be banned I don't think that's the end of the world.
@mikeshardmind

I was viewing option 6 as also banning methods, properties, and functions with deferring types on access as well when I wrote it. The primary reason for allowing overlap at all is the unavoidable overlaps of things inherited from object, but the rule "just working" without special casing those things was good.

Oh ok, great! Apologies, I didn't realise this
@DiscordLiz

They only go away partially. Please do not ban callables from intersections entirely, we have a stated use case in this repo that still works with this option.

Yeah I was thinking about the case of combining two Callables - I see that so long as the other item in the intersection doesn't have a call method that should be find.

Sort of? I said an intersection would only make sense to me when I care about disjoint types, and that's true, but there are cases for extending base functionality beyond what this would support. However, the thing that @mark-todd and @mikeshardmind went back and forth on in discord and here with type and object or Inherit allowing multiple type parameters in an ordered fashion can address this case without intersections needing to be the tool for this, so I think it's okay to directly state this in a "why this behavior" wasn't included section for the pep since we have a potential path for that behavior in a different mechanism that can be worked on in the future without intersections blocking it.

Yeah I think separating that behaviour is a good plan - there's certainly a use case for it but I think it can go into a different PEP.

The Issue got too long again. Please continue discussing in https://github.com/CarliJoy/intersection_examples/issues/37.
Please open new Issues if you start discussing on new sub aspects.


how to run flannel with --ip-masq

I have 3 machines(vs01, vs02 and os2). vs01 nad vs02 are in local network and os2 is GCE. All are connected through bridge VPN.
vs01: (vm-1)
tap0 - <IP_ADDRESS>
eth0 - <IP_ADDRESS>

vs02: (vm-2)
tap0 -<IP_ADDRESS>
eth0 - <IP_ADDRESS>

os2: (gce)
tap0 - <IP_ADDRESS>
eth0 - <IP_ADDRESS>

After Running kubernetes cluster
vs01: (vm-1)
tap0 - <IP_ADDRESS>
eth0 - <IP_ADDRESS>
flannel0 - <IP_ADDRESS>
docker0 - <IP_ADDRESS>

vs02: (vm-2)
tap0 -<IP_ADDRESS>
eth0 - <IP_ADDRESS>
flannel0 - <IP_ADDRESS>
docker0 - <IP_ADDRESS>

os2: (gce)
tap0 - <IP_ADDRESS>
eth0 - <IP_ADDRESS>
flannel0 - <IP_ADDRESS>
docker0 - <IP_ADDRESS>

vs01 and vs02 docker containers are able to communicate with each other but we are unable to communicate with os2 conatiners.
# cat /run/flannel/subnet.env
FLANNEL_SUBNET=<IP_ADDRESS>/24
FLANNEL_MTU=1472
FLANNEL_IPMASQ=false

Kubernetes is starting docker and flannel services. Here is the configuration file:
export FLANNEL_NET=${FLANNEL_NET:-<IP_ADDRESS>/16}
echo "FLANNEL_NET"
echo $FLANNEL_NET
export FLANNEL_OPTS=${FLANNEL_OPTS:-"Network": <IP_ADDRESS>/16}

How can I edit this file so that flannel will run with --ip-masq?

I think export FLANNEL_OPTS=${FLANNEL_OPTS:-"Network": <IP_ADDRESS>/16} might be wrong. { "Network": "<IP_ADDRESS>/16" } is written into etcd but it looks like FLANNEL_NET is there for that. I am assuming you're on Ubuntu. Can you try placing FLANNELD_OPTS=--ip-masq into /etc/default/flanned?
However, --ip-masq controls whether or not flannel will install iptables rules on the host. The rules specify that traffic going from flannel net to the outside (i.e. from containers to the Internet) should be masqueraded. But it sounds like your instances are behind a NAT (IP Masquerade) and flannel is trying to communicate via RFC1918 addresses over the WAN (e.g. 10.x.x.x and 172.16.x.x). In that case, you can use newly added --public-ip option to specify the public (routable) IP.

@eyakubovich, As you said I changed the content of  /etc/default/flanneld to FLANNEL_OPTS="--public-ip=<IP_ADDRESS>"
Now flanneld is not running and log says:
flag provided but not defined: -public-ip
Usage of /opt/bin/flanneld:
  -alsologtostderr=false: log to standard error as well as files
  -etcd-cafile="": SSL Certificate Authority file used to secure etcd communication
  -etcd-certfile="": SSL certification file used to secure etcd communication
  -etcd-endpoints="http://<IP_ADDRESS>:4001,http://<IP_ADDRESS>:2379": a comma-delimited list of etcd endpoints
  -etcd-keyfile="": SSL key file used to secure etcd communication
  -etcd-prefix="/coreos.com/network": etcd prefix
  -help=false: print this message
  -iface="": interface to use (IP or name) for inter-host communication
  -ip-masq=false: setup IP masquerade rule for traffic destined outside of overlay network
  -log_backtrace_at=:0: when logging hits line file:N, emit a stack trace
  -log_dir="": If non-empty, write log files in this directory
  -logtostderr=false: log to standard error instead of files
  -stderrthreshold=0: logs at or above this threshold go to stderr
  -subnet-file="/run/flannel/subnet.env": filename where env variables (subnet and MTU values) will be written to
  -v=0: log level for V logs
  -version=false: print version and exit
  -vmodule=: comma-separated list of pattern=N settings for file-filtered logging

And also I tried with ./flanneld --public-ip=<IP_ADDRESS> and printing same error.
I'm using flannel version 0.4.0
How to run --public-ip option?

@gangadhars --public-ip has been added very recently and is only available in 0.5.2

Thanks @eyakubovich
Problem is flannel is using eth0 interface by default. When I run it with --iface=tap0 it's working good.

@eyakubovich  can you give a solution for this in coreos


Documenting FlexVolume Resize alpha feature.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please delete this note before submitting the pull request.
For 1.12 Features: set Milestone to 1.12 and Base Branch to release-1.12
Help editing and submitting pull requests:  https://deploy-preview-9510--kubernetes-io-master-staging.netlify.com/docs/contribute/start/#submit-a-pull-request.
Help choosing which branch to use, see
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

@aniket-s-kulkarni, @zparnold Please review.

@brahmaroutu can you please rebase against the 1.12-release branch? (See PR template for details.) Thanks!

Hi @brahmaroutu, could you please rebase on dev-1.13, fix any merge conflicts, and let us know when it's ready for review? The docs deadline is approaching soon so we want to start reviewing PRs ASAP.

/assign @gnufied

@brahmaroutu Please also update content/en/docs/reference/command-line-tools-reference/feature-gates.md where we consolidate all feature gates for users to reference. As gates come and go, it is very likely people will get confused.

@tengqm The feature gates I mentioned in the documentation are already existing ones, I see them already listed in the content/en/docs/reference/command-line-tools-reference/feature-gates.md

@brahmaroutu You are right. Just confirmed that these feature gates have been updated in the dev-1.13 branch. Thanks.

@gnufied hope I addressed all your review comments.

/lgtm

/approve


version 1.0.17 is broken

The lastest release of Chance with the change to Replaced es6 arrow function with function must have missed a change in pickset.  Our code started bombing this morning.  We are using an up carrotted chance dep which pulled in the latest version.  We noticed this issue while using this in webpacked code destined for the browser.
We are recieving a Unexpected token: punc ()) error in reference to
this code:
return this.n(() => {
                var index = this.natural({max: --end});
                var value = array[index];
                array[index] = array[end];
                return value;
            }, Math.min(end, count));

found in Chance.prototype.pickset
Here should be the line in your code base. https://github.com/chancejs/chancejs/blob/master/chance.js#L546
Please look to adjusting this code to be compatible.
Our temp solution:
pin the dep to v1.0.16 till this gets sorted out.
Also FWIW, it looks like your code was released to NPM with version 1.0.17 but v17 never got cut as a release tag in github so my digging is only hopeful that i have found the issue relative to the latest release.

Thank you for the fast turn around.


refactor inter burst gap

Why: The current structure of inter burst gap doesn't follow the choice model. The choice model allows for different defaults per choice while the original model does not. The choice model also removes the need to set units and a value.
View the proposed changes using the redocly API viewer
# the refactor allows for this snappi notation
flw.duration.burst.inter_burst_gap.microseconds = 1.5

@ashutshkumr i agree with you that delay and delay_unit have the same problem, I will make a change to address that and ask you for one more review - thanks for looking at this more closely.


add pull_request_target

Following the documentation at github it appears we should add the pull_request_target event in order to enable workflow automatically in forked repository.
Before

After

cool :D


Forever restarts even when not using -w option

I am starting forever with the following command:
sudo forever start -a -l /var/log/node/forever -o /var/log/node/out -e /var/log/node/err server.js

Before, the server was started with the -w option, but now, without using the option, the server keeps restarting on file changes in my main directory and the sub-directories. I also deleted my ~/.forever dir, without any results.

You could please check this again @conflagrator? We switched to chokidar in<EMAIL_ADDRESS>(specifically by upgrading to<EMAIL_ADDRESS>which is much more stable than what was used previously.
Given the age of this issue I'm going to close it.


Is this project still active?

I will create a repo if not

Yes @wxs77577, it's still active. I will be happy, if you fill repo with some useful resources. If you wish of course.


Update dburi format

High level description of this Pull-request
Include motivations, reasons, and background to add context to your contribution.
Include a description of changes associated with your commit(s)
Related Issues

List all related issues or NA

Reviewers

Use @Mentions to specify the reviewers for your PR.

CHECKLIST:
Make sure all items are marked when you submit the pull-request.

[ ] Relevant documentation for functions, tests, classes, the wiki, etc. have been made
[ ] Necessary unit tests in tests/ pass with no errors
[ ] Necessary integration tests in tests/ pass with no errors
[ ] Update the CHANGELOG.md with a summary of your changes if requested

Thanks


fix(packagediff): provide more descriptive error message when it is unable to compute diff

fixes #965
Checklist
All items have to be completed before a PR is merged

[x] Adhere to Contribution Guidelines
[x] Updates to Decision Records considered?
[x] Updates to documentation at DX@Scale Guide considered?
[x] Tested changes?
[x] Unit Tests new and existing passing locally?

Codecov Report

Merging #1057 (6489ac0) into develop (d0291e4) will decrease coverage by 0.15%.
The diff coverage is 37.50%.

@@             Coverage Diff             @@
##           develop    #1057      +/-   ##
===========================================
- Coverage    59.55%   59.40%   -0.16%
===========================================
  Files           52       52
  Lines         1674     1680       +6
  Branches       357      357
===========================================
+ Hits           997      998       +1
- Misses         634      639       +5
  Partials        43       43

Impacted Files
Coverage Δ

packages/core/src/package/PackageDiffImpl.ts
90.69% <37.50%> (-5.56%)
:arrow_down:

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 e8776d7...6489ac0. Read the comment docs.


Expose transactionInfo.checkoutOption configuration for GooglePay

Is your feature request related to a problem? Please describe.
The transactionInfo.checkoutOption property provides the ability to change the submit button in the GooglePay payment sheet as per GooglePay API documentation here.
The full transactionInfo object is exposed in the adyen-web GooglePay configuration so this would be aiming for feature parity across sdks.

Hey @danielschofield-adyen
This field was never requested before. Could you describe your business case?
Our Android team will add it to a backlog. Will keep you posted.

Hey @descorp ,
The business case here is that the default checkoutOption displays the GooglePay payment sheet button as "Continue" which is confusing to customers if they aren't required to complete any "additional steps" before completing the transaction.
By exposing this value, the merchant is able to overwrite the "Continue" button to display "Pay" instead which makes more sense in this situation. There are also additional configurable options under the "transactionInfo" object which will offer more customisation options for merchants.
Additionally, this feature is available in our web sdk and we should be aiming for feature parity across our sdk offerings.


ScriptToRun is jq based

jq might not be available , what then.
I tried with python instead like
$ScriptToRun = @"
/usr/bin/ubuntu-advantage security-status --format json 2>/dev/null | python3 -c "
import sys, json
data = json.load(sys.stdin)
print(json.dumps({
'updateSum': data['summary']['num_esm_apps_updates'] + data['summary']['num_esm_infra_updates'] + data['summary']['num_standard_security_updates'],
'upgradeAvailablePackages': [pkg['package'] for pkg in data['packages'] if pkg['status'] == 'upgrade_available'],
'pendingAttachPackages': [pkg['package'] for pkg in data['packages'] if pkg['status'] == 'pending_attach']
}, indent=4))"
"@
which works manually, but didn't work so far on azure.
The runner was stuck or something.
Need to look into it

should be solved with
https://github.com/lolwww/azure-ubuntu-assessment/commit/479e5fd5040aaa2818d67e208b5f01befc6f919c


Provide a new command kusion module init to help developers build a module from the root directory of this project

close due to #945


Issue with IQueryable mock setup

With the example implementation, calling .ToList() a second time returns 0 elements.
mockSet.As<IQueryable<Blog>>().Setup(m => m.GetEnumerator()).Returns(data.GetEnumerator());
Correct implementation:
mockSet.As<IQueryable<Blog>>().Setup(m => m.GetEnumerator()).Returns(() => data.GetEnumerator());
Credit: This stackoverflow answer by Wiktor Zychla: https://stackoverflow.com/a/23461278/5542555
Possibly better implementation (have not tested personally)
mockSet.As<IQueryable<Blog>>().Setup(m => m.GetEnumerator()).Returns(x => data.GetEnumerator());
Suggested by Andrew Monteith in the same SO topic: https://stackoverflow.com/a/34848711/5542555

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

ID: 1a04a5e4-3060-2331-f78d-8b45064b8983
Version Independent ID: 673d9406-3fa1-a9eb-f5cc-a431155e0260
Content: Testing with a mocking framework - EF6
Content Source: entity-framework/ef6/fundamentals/testing/mocking.md
Product: entity-framework
Technology: entity-framework-6
GitHub Login: @divega
Microsoft Alias: avickers

Thank you for requesting a change to the EF6 documentation. We are prioritizing improvements to the EF Core documentation and at this time we are not making changes to the EF6 documentation.
However, we will consider well-written community pull requests to improve the EF6 documentation. The documentation source is located in the EntityFramework.Docs repository on GitHub. To submit a pull request:

Find the file to update and click on it to open

Click on the edit button (✏) to edit in your web browser

When done, add a title and description, then use the "Create a new branch and start a pull request." option.

(Note that you can also clone the docs repo and do a GitHub PR in the normal way.)


LHN : The preview message changes when editing a message with multiple lines after coming back to the the same chat Action Performed:

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open the app
Go to any chat
Edit any message and add 2 or more lines & send
Chat's preview text will show all the lines in the sidebar
Now to go to any other chat and come back
Wait for few seconds
Chat's preview text will only show the first line

Expected Result:
The preview text should only show the first line of message
Actual Result:
It's showing all the lines of the edited message
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.2.43-1
Reproducible in staging?: y
Reproducible in production?: y
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/209684521-6be7de15-ccd3-4c0e-a869-6618108522e6.mp4
https://user-images.githubusercontent.com/43996225/209684556-aacfecfe-e7ce-4cd0-b51b-6d0667dd7e61.mp4
Expensify/Expensify Issue URL:
Issue reported by: @daraksha-dk
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1672144659281919?thread_ts=1671809729.708589&cid=C049HHMV9SM
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01cc2259f1a7d21978
Upwork Job ID:<PHONE_NUMBER>600440832
Last Price Increase: 2023-01-11

I can take a look at this one.

Before edit:

After edit:

So this will require an API change since that update is coming from there. We should only be setting the first line as the lastMessageText

This was deployed to production 3 days ago. Closing this out!

Ah seems we need to pay @daraksha-dk the bug reporting bonus. Let me jump in to help out here.

unvited you to a upwork job - https://www.upwork.com/jobs/~01461e91f626d53a67


How to get uploaded filename

Hi
I would like to use VuetifyImageInput with firebase(storage).
Upload image to filebase needs image filename,but no properties in plugin to get filename.
How to get uploaded image filename?
I appreciate you for using your plugin! thank you!!!

For now there is no way to get the file name using this component. What do you think, how should the API look like? Are there any examples with vue-uploader that do it?

Thank you for your reply.
For example,this component can Implement it.
https://www.npmjs.com/package/vue-upload-component
Probably, input files "value" contains a file path,and use it.
I am sorry but details are unknown me...

it's better to wait until vuetify releases its own uploader component. then i can build image-input around it.


terraform: Update terraform topic to follow the common template

terraform: Update terraform topic to follow the common template

terraform topic location: https://github.com/tungbq/devops-basic/blob/main/topics/terraform
Templated location https://github.com/tungbq/devops-basic/blob/main/templates/TOPIC_TEMPLATE.md
Similar task with  #440

Done via #482


iOS White screen when having places on camera view (location based)

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
When I open the AR screen, the code loads, the places are loaded, all permissions are given but when i look somewhere where a place is shown in the camera, it stops the camera and gives me a white screen (while the places still appear at the direction that they should) and when i turn the phone-camera at a direction where no places are shown, it returns back to normal (the camera shows again, whote screen is gone). It worked normally until a couple of days ago, with no issue and with no changes to my code.
If the current behavior is a bug, please provide the steps to reproduce.
Just load the code that i provide and you will see.
My app runs natively as well. An interesting thing is that on safari (web) it has the problem that I just describes but on the native app it works normally, as it should.
iPhone 11, latest iOS version
ar.txt

Unfortunately I do not have an iOS device to test, but is it just iOS only? Does Android have the same problem?
Have you tried looking at the console to see if any errors are reported?
What do you mean when you say the "native app"?

@nickw1 It's a PWA web app (Ionic, Vue) and I converted it to a native through PWA Builder. And when i run the native app, the AR works fine, but on safari i have the the problem that i described
No i haven't checked the console for any errors, but i probably will soon. And yes, the problem appears only on iOS

@antoniskamzel ah ok thanks. Would be great if you could report what the log is saying as it does appear to be a browser-specific problem.

I also have a similar problem.
The test device information is:
Device: Iphone IOS 15.4.1
Browser: Safari
I also tried on Pixel 3axl (Android 12 - Chrome) but not having this issue.

Do you still get this with the new location-based components?
Check out the dev branch and try the new-location-based components (to see how to use, there is an example in the new-location-based directory in examples).

@antoniskamzel are you using the new location-based components from 3.4.0? For A-Frame these are available under new-location-based; there is also an example in the examples/new-location-based directory. Does the example work? Do you have any output on the console?

This still happens for me, in general AR.js just seems to be incredibly buggy. I'll often have a white page, sometimes pins won't appear, true north is never in the correct direction. I have a poco F5 which is very new, but I can only assume that this must be somewhat specific to my device as the sheer number of issues I'm running into can't be normal

@Platform-Group could you try the examples included in the repo? Clone the repo and run a server in its root directory, and try out the examples on your device using port forwarding with Chrome developer tools.
Try both the A-Frame new-location-based and classic location-based examples. Do any work for you?
Unfortunately these kinds of bugs are rather difficult to diagnose as they seem to occur only on certain devices; all the examples work as expected on my own device (Pixel 3 currently running Lineage OS 19, formerly running stock Android 12, and before that 11 and 10).
They could be related to differences in the implementation of the underlying Device Orientation API on different browser versions or differing sensors but it's hard to know to be sure.
Are you able to do a little debugging yourself with the Chrome developer tools to see if a console error is printed when the white screen comes up? Does the position of the boxes depend on which direction the device is facing when the application starts up? (this has been reported before, but again, not on all devices).
Sorry I can't offer any more direct help but hope you can appreciate that it's tricky to debug these issues when they seem to be device-specific. What we'd really welcome for AR.js is more developers with a wider range of devices, particularly iOS devices.
@nicolocarpignoli not sure if you look at AR.js these days but one thing I am wondering about is the _calculateCompassHeading() method in the older location-based components, e.g.
https://github.com/AR-js-org/AR.js/blob/master/aframe/src/location-based/gps-camera.js
which seems to replicate the functionality provided by the device orientation API as used in A-Frame. Are you able to explain the rationale for this code and whether it solves device orientation issues? Thanks.

@nickw1 when my camera fails and I get either a white or black screen, I get nothing from the chrome developer tools. I can work around this by just restarting the browser though, so it's not a huge deal. My main problem at the moment is how inaccurate the compass/magnetometer is, my location's never show up in the correct position in AR as it always has north pointing in the wrong direction. I was just looking into how I could do some kind of manual calibration with a marker image to tell ar.js which way north is, but I'm not sure on that implementation yet.


[HOLD] - [$500] Violation - Expense violation message is missing from Employee's view and no amount

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 1.4.28-0
Reproducible in staging?: Y
Reproducible in production?: Y
Issue reported by: Applause - Internal Team
Issue found when executing PR https://github.com/Expensify/App/pull/31448
Action Performed:
Precondition:

Admin and employee are part of Control workspace in Old Dot
The Control workspace has set up Max Expense Amount violation

[Employee] Go to workspace chat
[Employee] Create a manual request that exceeds the maximum amount
[Employee] Submit the request
[Employee] Go to request details page
[Employee] Note that there is no "Expense exceeds auto approval limit of" message
[Admin] Go to the request details page

Expected Result:
~In Step 5, "Expense exceeds auto approval limit of" message will be present from Employee's view~
In Step 6, "Expense exceeds auto approval limit of" message will be complete with the maximum amount allowed for the violation
Actual Result:
✅ In Step 5, "Expense exceeds auto approval limit of" message is not present from Employee's view
In Step 6, "Expense exceeds auto approval limit of" message is missing maximum amount allowed for the violation
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/Expensify/App/assets/78819774/3d5b0364-4df1-43e3-b21d-6213f89d93e8
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~019aaa92dcff420820
Upwork Job ID:<PHONE_NUMBER>109818880
Last Price Increase: 2024-01-19

#wave6-collect-submitters

I'm taking this one, to check if the fix is on the backend first.

In Step 5, "Expense exceeds auto approval limit of" message will be present from Employee's view

For context: we don't show this to the person requesting money because they can't do anything about this violation

Planning on triaging this today

After testing this while on this branch https://github.com/Expensify/App/pull/34303/files, I think this issue will be fixed by that PR, so putting it on HOLD for now

On hold, not overdue

Linked issue still hasn't merged, though it looks very close.

PR got merged but hasn't been deployed yet


Add provisional upgrade notes for v0.11 & bump version strings

What this PR does / why we need it:
Adds provisional/first draft of upgrade notes for v0.11 as well as bumping version strings for alpha.0
Release note:
NONE

/milestone v0.11
/priority critical-urgent
/assign @JoshVanL

/lgtm

/retest

/retest

Dropped webhook? Perhaps GitHub are having issues today 🙄


NIFI-12557 Refactor components in kafka bundle using current API methods

Summary
Refactor tests and components in cipher bundle to use updated APIs from NIFI-12452.
Additionally, makes use of newer Java APIs, e.g. List.of and Set.of for declaration of relationships and properties.
NIFI-12557
This time I've deleted several methods and fields from the PublisherLease I couldn't find any use of.
Also I noticed, that the parameter maxConcurrentLeases in several constructors of ConsumerPool is not actually used. The value provided is always from ProcessContext::getMaxConcurrentTasks.
However, its use was removed as part of NIFI-8021. I removed this unused parameter as well.
All tests were still passing after the removal.
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[x] Apache NiFi Jira issue created

Pull Request Tracking

[x] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[x] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[x] Pull Request based on current revision of the main branch
[x] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[x] Build completed using mvn clean install -P contrib-check

[x] JDK 21

Licensing

[x] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[x] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[x] Documentation formatting appears as expected in rendered files

Thanks for taking a look at and merging this, @exceptionfactory. Happy new year. 🎆